Computing system for providing software components on demand to a mobile device

A computing system includes a computer network, a server connected thereto, and a client device for communicating with the server over the computer network. The client device runs an application shell software module providing a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components that are individually stored on the computer network and downloaded/run when needed. The server receives a request for available software components from the application shell software module, controls a search of an index for available software components and transmits a response to the application shell software module providing details of available software components. The application shell software module receives details of available software components from the server, retrieves a selected software component from the location identified by location data for the selected software component, and starts and stops the selected software component within the application shell software module in accordance with received data.

BACKGROUND

The present invention relates to the provision of software components to client devices such as mobile telephones, personal digital assistants, laptop computers and the like. The invention has particular, although not exclusive relevance to the dynamic component-based delivery, assembly and disposal, in real-time, of software application modules on such mobile computing devices.

There is currently great interest in so-called ‘smart phones’, mobile electronic devices that offer combinations of once separate and distinct functionalities, such as telephony, email, electronic diary etc, combined within a single device. The need for such devices to be portable requires them to be light weight, relatively small and battery powered. This places stringent limits on both the device itself, for example in terms of processing power and data storage capacity, and on its connectivity, as in network speed and capacity.

One of the inventors has previously proposed (in GB 2370658) to provide Java based components that are instantiated in the memory of a server, serialised and then sent across the network as a serialised in-memory object directly into the memory of the mobile computing device to be run by a Java Virtual Machine on the device. This system offers the advantage that components for software applications do not need to be stored in the mobile device and instead can be downloaded and used when needed. However, this earlier system suffered from a number of problems that made the system unsuitable for a practical implementation. These problems include:

1. the component objects had to be instantiated in memory and then transferred to the client device via a Remote Method Invocation (RMI), which is not secure and exposes the server/mobile computing device to attack as it allows direct access to the memory in the server/mobile computing device;

2. the data transmitted between the mobile device and the server is relatively large due to the need to transmit memory instantiated objects. In particular, the serialisation process not only serialises the given in-memory object but also copies and serialises any other in-memory objects that are used by the target component. For example, a visual component will not only have its own logic serialised, but also the logic that displays and handles its GUI, as well as any other objects it was using at the moment of serialisation. The result in an object that is in fact many times bigger than the original component, and this object now has to be transported across a network to the calling client;

3. the system did not scale as components had to be one of four different types, with each type being described by a single fixed size descriptor object specific to that type; and

4. additionally, instantiation of any object is a CPU-intensive and memory-intensive process. A server receiving 1000 requests per minute would very quickly run out of memory and grind to a halt.

BRIEF SUMMARY

The present invention therefore aims to provide a system which uses an alternative process for the discovery, delivery and activation of software application components. Different aspects of the invention relate to: the description of the components, including their location; the method(s) required to load and activate them; searching for a particular component within one or more repositories according to specific criteria; downloading the particular component; and controlling the lifecycle of the particular component, including loading it dynamically into an already running application and stopping and disposing of the component afterwards.

According to one aspect, the invention provides a component based system in which location and start and stop data for each component found in a search are downloaded to the client and the client downloads a selected component from the corresponding location and starts and stops it using the start and stop data.

According to this aspect, one embodiment provides a mobile computing system comprising: a computer network; a server connected to the computer network; and a portable client device operable for communicating with said server over said computer network; wherein said portable client device is operable to run an application shell software module that provides a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components, each software component being individually stored on the computer network and being downloaded and run when needed; wherein said server is operable to receive requests for available software components from the application shell software module, to control a search of an index for available software components and to transmit a response to said application shell software module providing details of available software components, including, for each software component: i) identification data identifying the software component; ii) location data identifying a location from which the software component can be obtained; and iii) start and stop data identifying how to instantiate the software component; wherein said application shell software module is operable: i) to receive said details of available software components from said server; ii) to retrieve a selected software component from the location identified by said location data for the selected software component; iii) and to start and stop the selected software component within the application shell software module in accordance with the received start and stop data.

In one embodiment the application shell software module is operable: iv) to start the component and, once the component is no longer required, to stop the component in accordance with the start and stop data. Preferably the start and stop data cause the application shell software module to remove the software component from the memory of the client device.

According to this aspect, another embodiment provides a computing system comprising: a computer network; a server connected to the computer network; and a client device operable for communicating with said server over said computer network; wherein said client device is operable to run an application shell software module that provides a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components, each software component for implementing a substantially different part of the dynamically configurable application's functionality, that part being small in relation to the overall size of the dynamically configurable application; wherein said server is operable to receive a request for available software components from the application shell software module, to control a search of an index for available software components and to transmit a response to said application shell software module providing details of available software components, including, for each software component: i) identification data identifying the software component; ii) location data identifying a location from which the software component can be obtained; and iii) start and stop data identifying how to instantiate the software component; wherein said application shell software module is operable: i) to receive said details of available software components from said server; ii) to retrieve a selected software component from the location identified by said location data for the selected software component; and iii) to start and stop the selected software component within the application shell software module in accordance with the received start and stop data.

According to another aspect, the invention provides a component based system in which the client transmits a text string request to the server and the server parses the text string and controls a search for components using the parsing results.

According to this aspect, one embodiment provides a mobile computing system comprising: a computer network; a server connected to the computer network; and a portable client device operable for communicating with said server over said computer network; wherein said portable client device is operable to run an application shell software module that provides a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components, each software component being individually stored on the computer network and being downloaded and run when needed; wherein said application shell is operable to transmit text string requests for available software components, each request comprising text identifying: i) software running on the client device; and ii) hardware of the client device; wherein said server is operable: i) to receive said text string requests for available software components from the application shell software module; ii) to parse the text string request and to generate a query using the text in the request; iii) to control a search of an index for available software components using the query; and iv) to transmit a response to said application shell software module providing details of available software components and where they are located on the computer network; wherein said application shell software module is operable to receive said details of available software components from said server and to retrieve and run a selected software component from the location identified by said server for the selected software component.

According to another aspect, the invention provides a component based system in which the server transmits a text string response to the client and the client parses the text string to get the component location for retrieval of the component.

According to this aspect, one embodiment provides a mobile computing system comprising: a computer network; a server connected to the computer network; and a portable client device operable for communicating with said server over said computer network; wherein said portable client device is operable to run an application shell software module that provides a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components, each software component being individually stored on the computer network and being downloaded and run when needed; wherein said server is operable to receive requests for available software components from the application shell software module, to control a search of an index for available software components and to transmit a text string response to said application shell software module providing details of available software components, including, for each software component: i) text identifying the software component; and ii) text identifying a location from which the software component can be obtained; wherein said application shell software module is operable: i) to receive said text string response; ii) to parse the received text string response to obtain the text identifying the available software components and the text identifying the locations of the available software components; and iii) to retrieve and run a selected software component using the text identifying the location of the selected software component.

According to another aspect, the invention provides a component based system in which an index comprises a descriptor for each component having a plurality of descriptor nodes, each having a plurality of associated attribute key-value pairs and in which a search is performed by matching attribute key-value pairs in the request with those in the descriptors.

According to this aspect, one embodiment provides a mobile computing system comprising: a computer network; a server connected to the computer network; and a portable client device operable for communicating with said server over said computer network; wherein said portable client device is operable to run an application shell software module that provides a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components, each software component being individually stored on the computer network and being downloaded and run when needed; wherein said server is operable to receive requests for available software components from the application shell software module, to control a search of an index for available software components and to transmit a response to said application shell software module providing details of available software components; wherein said index comprises a plurality of descriptors, each descriptor being associated with a respective one of a plurality of software components and comprising a plurality of descriptor nodes each having a plurality of attribute key-value pairs relating to the associated software component; wherein said searching of the index comprises matching attribute key-value pairs defined within said received request with the attribute key-value pairs of each descriptor; and wherein the server is operable to provide, in said response, details of software components for which a match is found between the attribute key-value pairs of the request and the attribute key-value pairs of the associated descriptor; wherein said application shell software module is operable to receive said details of available software components from said server and to retrieve and run a selected software component.

According to another aspect, the invention provides a component based system in which an index comprises a Java descriptor object for each component having a plurality of associated Java attribute objects and in which the search is performed by matching attribute key-value pairs in the request with the Java attribute objects.

According to this aspect, one embodiment provides a mobile computing system comprising: a computer network; a server connected to the computer network; and a portable client device operable for communicating with said server over said computer network; wherein said portable client device is operable to run an application shell software module that provides a dynamically configurable application in a piecemeal manner by individually downloading and running a plurality of software components, each software component being individually stored on the computer network and being downloaded and run when needed; wherein said server is operable to receive requests for available software components from the application shell software module, to control a search of an index for available software components and to transmit a response to said application shell software module providing details of available software components; wherein said index comprises a plurality of descriptor Java objects, each descriptor object being associated with a respective one of a plurality of software components and having a plurality of associated attribute Java objects each defining an attribute key-value pair relating to the associated software component; wherein said searching of the index comprises matching attribute key-value pairs defined within said received request with the attribute Java objects associated with each descriptor Java object; and wherein the server is operable to provide, in said response, details of software components for which a match is found between the attribute key-value pairs of the request and the attribute Java objects of the associated descriptor Java object; wherein said application shell software module is operable to receive said details of available software components from said server and to retrieve and run a selected software component.

As a result of the system described above, the application is deployed piecemeal to the client device, with only the parts that are needed by the user at any particular instant being activated at that time. It is the responsibility of the application container loaded in the client device to load the components that the user currently wants to use and assemble them for use by the user. The components are loaded directly into the client device's memory, assembled and made available for use, thereby having no impact on the local storage of the client device. In this way, the application becomes ‘virtualised’ and can be expanded and contracted as required.

Preferably the components are ‘fine-grained’ components that are single purpose units of software as these can be delivered quickly even over slow networks such as GPRS. The use of such fine grained components also reduces delays caused by lengthy testing processes, as each component does not impact on any of the other components in the application. Further, by building an application as a set of fine-grained components, the core application components can be delivered to market whilst additional application features can be created and added later. Further still, with the above system, it is also possible to share or re-use common components among a number of core applications thereby reducing development cost per application. The above system allows for the immediate deployment and availability of components, unlike traditional component-based application platforms. The above system also provides for performance enhancements. In particular, with the new system the server delivers the components to the calling client in stored form, leaving the calling client to handle instantiation. The stored form is much smaller than in-memory form, since it has not loaded any dependencies, and therefore will travel much more quickly across a network. Additionally, the server does not have the burden of handling component Instantiation.

DETAILED DESCRIPTION

Overview

FIG. 1illustrates a mobile computing system having a number of client devices1-1,1-2and1-3(which in this embodiment are mobile telephones) that communicate with a server3over a network such as the Internet5. The server3provides the clients1with access to a number of software components that are held in a repository7and which each implement a substantially different part of a dynamically configurable application. Each software component is a small single purpose unit of code that performs a small part of the overall functionality of the dynamically configurable application. Typically, a banking application may comprise four components, with each component approximately five kilobytes in size, for an overall application size of approximately twenty kilobytes. A graphically or multimedia intensive application, such as a casino application, may be approximately eighty kilobytes in size, with the majority being the multimedia data as opposed to executable logic.

In operation, when a user of a client device1initiates a software application on the device1, the client device1creates and sends a text string request to the server3over the Internet5requesting details of software components that are currently available. The text string includes details of the client device1, such as device make and model, screen size and resolution, operating platform etc as well as user subscription details and user interests. The server3parses the received text string and forms a database query for querying the repository7to locate details of software components that are relevant for the particular client device1, user subscription and user interests. The server3then generates a text string response that includes details of the available software components and where they are stored; details of how each component should be loaded and started in memory; and details of how each component should be stopped and removed from memory. The client device1then uses the response to populate a component data table for each software component and displays the available components to the user. In response to the user selecting one of the software components, the client device1uses a standard file transfer protocol to retrieve the software component from the storage location defined in the component data table for the selected component. The client device1then loads and starts the software component in accordance with the load and start data stored in the component data table for the selected software component and, once the user has finished using the component or requests use of another component, stops and removes the component from memory in accordance with the stop and remove data stored in the component table for the selected software component.

In this way, the individual software components do not need to be stored on the client device1before being selected to be run by the user. This reduces the storage and processing burden on the client device1and allows components to be updated centrally within the repository7, without the need to update any software on the client devices1. Further, since the client device1requests details of the components that are currently available before displaying selectable components to the user, the system can be updated to include new components (ie new or improved functionality) which can be offered to the client device1when the user next uses the system.

Client Device

FIG. 2is a block diagram illustrating the main parts of one of the client devices1of the system shown inFIG. 1. As shown, the client device1comprises: a processor21for controlling the operation of the client device1; non-volatile memory (NVM)23for permanent storage of user data and software such as the operating system and user applications; volatile random access memory (RAM)25in which software to be run is loaded from the NVM23; a keyboard27for allowing the user to interact with the software running on the client device1; a display29for displaying information and prompting the user for user input to control the software running on the client device1; and a transceiver31, such as a wireless network card, for controlling the transmission and reception of data to and from the network5.FIG. 2illustrates the state of the client device1when the operating system33and an application container35that operates in accordance with the present invention have been loaded into the RAM25.FIG. 2also shows a number of other software modules and data files that are loaded into RAM25when needed by the application container35. A brief description of what each software module (except the operating system33) does and what each data file holds will now be given:Application container35—is a software program which provides some basic functionality and whose functionality can be extended by software components downloaded from the network7.Config file37—this is a text file, containing configuration information for or about the client, including:details of the client hardware, software platform and version etc;user ‘interests’, such as ‘banking’;user subscription data;the uniform resource locator (URL) of a component server;details of what component information will be required in order to complete fields in a component data table, described belowRequest generator39—is a software module which constructs and sends client requests to the component server3identified in the config file.Response receiver41—is a software module which receives the server's response to the client request sent by the request generator39and which populates a component data table for each component.Component data table43—is a data structure which contains key-value pairs, received from the server3, relating to a component. In particular, it details where a component is located, how is to be activated, stopped and disposed of.Code provider45—is a software module which retrieves specific components from the network7when instructed to do so by the application container35.
Server

FIG. 3is a block diagram illustrating the main parts of the server3of the system shown inFIG. 1. As shown, the server3comprises: a processor51for controlling the operation of the server3; non-volatile memory (NVM)53for permanent storage of user data and software such as the operating system53and server applications; a random access memory (RAM)55in which software to be run is loaded from the NVM53; a keyboard57for allowing an administrator to interact with the software running on the server3; a display59for displaying information; and a transceiver61, such as an Ethernet network card, for controlling the transmission and reception of data to and from the network5.FIG. 3also illustrates the main software modules run by the server3during use. These software modules include:Request receiver63, which receives requests transmitted from the clients and parses them to extract the client device information, the user subscription information and the user interests information contained in each request.Query generator65—which uses the information extracted by the request receiver63to determine suitable query terms which it assembles into a suitable query for identifying appropriate components.Application Program Interface (API)67, which comprises two relevant sub-modules, a repository provider module69and a repository admin provider71. The repository provider module69accepts the query supplied by the query generator65, and uses it to interrogate an index stored in the repository7(which may be local to the server or stored at some other location on the network5). The repository admin provider module71maintains the index stored in the repository7, keeping it updated with details of new components as they are added to the system and to remove old components as they are removed from the system.Response generator73—which generates the responses to the client requests from the results of the interrogation of the index in the repository7and returns the responses to the corresponding client device.
Respository

In this embodiment the repository7comprises a set of XML files64, one for each component70, and an index62for the XML files64. The index62includes a list66identifying the XML files64associated with each of the different application packages (user interests). When a request from a client device1is received it will include the name of the package to which the request relates. This package information is used to identify, from the list66of the index62, the component descriptors against which the received request will be compared. In this embodiment the received request is not compared directly with the XML files64but instead with an in-memory internalised version of these XML files (i.e. the descriptors68) which are also stored as part of the index62. The XML file64for a particular component70is internalised once and a Boolean flag is associated with the XML file to indicate that is has already been internalised and does not need to be internalised again for later searches. Newly-added components70will have their associated XML files64internalised as required.

A particular component70can potentially belong to multiple applications. For example, a component to implement a custom secure network protocol could have package_name values of “Banking”, “Casino” and “Messaging”.

Information on which components70belong to which package or packages is determined at start-up of the repository7. All the component XML files64are text searched for the package_name field, and grouped according to package_name within a two-dimensional data table that defines the above list66.

A brief description has been given above of the main parts of the mobile computing system embodying the present invention. A more detailed description will now be given of the way in which the system operates, with reference toFIG. 5. This description will be given in relation to a specific “Banking” application. As those skilled in the art will appreciate, the system can be used for many other applications.

System Operation

Upon the user selecting the Banking application on the client device1, the Banking application container35is loaded from NVM23to RAM25and run. When run, the Banking application container35loads the Banking client config file37into the RAM25and updates the client device information in the config file as necessary.

For applications where it is deemed important to confirm the identity of the user, such as the Banking application, the application container35will perform an authentication stage in which the user is requested to input a user name and password. The information provided by the user via the keyboard27can then be verified by the Banking application container35, for example by comparing it with pre-stored data held by the server3.

Once the identity of the user has been verified, the Banking application container35loads the request generator module39into RAM25and passes it the updated config file37. The request generator module39uses the information in the config file37to generate a request which it sends to the server3identified in the config file37. In this embodiment, the request is sent as a plain text string as part of an Hyper Text Transfer Protocol (HTTP) command string, and comprises details of the client device1, such as the hardware and software; details of the client interest (package), such as Banking and a request for lifecycle control information, ie. details of what component information is required by the client device1to run the component, such as the name of the component, where it is stored (its URL), how it should be initialised and started and how it should be stopped and removed from memory. For the Banking application of the present embodiment, the generated request will have the following form:

The resulting attribute key-value pairs obtained from the request receiver63are passed to the query generator65which uses them to assemble a suitable query (comprising a query term for each attribute key-value pair) for application to the index stored in the repository7.FIG. 6illustrates the process of building a query from the attribute key-value pairs. As shown, in step S1, the query generator65obtains the first attribute key-value pair. In step S3it extracts the attribute key and, in step S5adds it to the database query, which is built in a text buffer (not shown). Then, in step S7the query generator65extracts the attribute value of the key-value pair and adds it, in step S9, to the query. This processing is then repeated for each attribute key-value pair obtained from the received client request. The resultant query is then forwarded, in step S15to the API67.

In addition to adding the attribute keys and values, the query generator65adds appropriate database delimiters used by the repository7, which will depend on the type of database used. These database delimiters will be known to those skilled in the art of databases and a further description thereof will be omitted.

The server API67uses the received query to find component descriptors68that match the query terms in the index62stored in the repository7. The API67uses the repository provider69to carry out this matching operation. As discussed above, the user's query is not searched against all of the component descriptors68contained within the repository7. The value of the package_name attribute contained in the received request is used to address a list66stored in the index62. This identifies the subset of the components70within the repository7that can be called by the application container. A check is then made to determine if an in-memory internalisation of the XML file64(i.e. a descriptor68) for each of those components70is already within the index62(with reference to the above described Boolean flags associated with the XML files64). Any XML files64that have not yet been internalised are internalised at this point and then the attribute key-value pairs in the received query are compared with attribute-key value pairs defined by these in-memory internalised component descriptors68.

In this embodiment, generic in-memory internalised Java descriptor objects are used to describe each software component70. These descriptor objects68are programmatic representations of the metadata used to describe a component, with each descriptor68containing a number of Java attribute objects, each associated with one of the above attribute key-value pairs. In this embodiment, the in-memory internalised descriptors68are arranged in a tree structure to facilitate the comparison between the query terms of the query and the attribute objects associated with the descriptor68for each component70.

FIG. 7illustrates the internalised, in-memory form of a descriptor object68for a component70, and the way in which it is arranged in a tree structure. The illustrated descriptor object68is for the component70named “Money Transfer” that will allow the user of the client device1to transfer money from his account to another account. As shown, the attribute objects associated with this Money Transfer component include:attribute objects81identifying the name, short and long descriptions, version and Java class name, which are associated with the root descriptor82for the component;attribute objects83relating to the platform on which the component is intended to run, such as Java version 2 and ME edition version 1.0;attribute objects85relating to any restrictions on user subscription levels.attribute objects89relating to the lifecycle of the component, in other words how to initialise, start and stop the component, and how to remove the component from memory;attribute objects91relating to where the object is stored (its URL) and how it should be installed attribute objects93relating to the vendor, identifying the owner and author of the component and how to contact them.

A similar descriptor68is provided for each of the different versions of the same component and for all the different components offering different functionality and the different descriptors68each have their own root descriptor82. There is no limit to the number of descriptors and attributes associated with a particular component, thereby allowing for an arbitrarily fine granularity of description for each component. Comparing a query against this index62of descriptors68effectively involves finding the root descriptors82(and dependent descriptors) that have attribute objects that match with all the query terms in the query.

As will be apparent fromFIG. 7, descriptors are primarily used to group attributes, although descriptor objects programmatically inherit from attribute objects and can therefore also be treated as attribute objects. This can be used, for example, by a management tool to find all components70that have or do not have a certain descriptor68.

In this embodiment, the descriptors and the attributes are all Java objects that perform the appropriate comparison and return a match or no match response. The repository provider69then passes the details of the components70that return a positive match with the input query to the response generator73, which reformats the search results into a client response. In particular, for each matching component descriptor68, the unknown attribute values in the client request are obtained from the attribute objects in the component's descriptor68.

FIG. 8illustrates this process of building the response to the client query. As shown, in step S31, the response generator73obtains the descriptor68of the first matching component70identified by the repository provider69. Then, in step S33the response generator73obtains the first unknown attribute (ie the first attribute key for which the value is not known) from the original client request, as identified by the request receiver63when it parsed the client request. In step S35the text of the attribute key is appended to the response. The processing then proceeds to step S37where the value of the current attribute is obtained from the descriptor68of the current component70. This text value is then appended, in step S39, to the response. The processing then proceeds to step S41, where a check is made to see if there are any more attributes in the client request for which the attribute value is unknown. If there are then the processing proceeds to step S43, where the next unknown attribute is obtained from the request receiver. The processing then returns to step S35as before. Once all the unknown attribute values have been found from the current component descriptor68, the processing proceeds to step S45, where the response generator73determines if there are any more matching components70. If there are, then the processing proceeds to step S47, where the descriptor68for the next matching component70is obtained. The processing then returns to step S33where the same processing is carried out to find the unknown attribute values from this new descriptor68. Once all the matching components70have been processed in the above manner, the response will have been generated and it is sent back to the client device1in step S49.

When generating the response, the response generator73will tailor the response to the particular client device1that made the request, according to details of the client device1hardware and software capabilities, either determined from the received client request, or as deduced from the characteristics of the client request.

The results of requests are returned to the client device1as individual lines of text, one generated for each matching component70, with each line being delimited by a ‘!’ delimiter. A search request that finds four components will therefore result in four lines of text being returned to the client device.

For the client request transmitted above, a typical response generated by the response generator73will include the following text for a “Money Transfer component:

As can be seen from the above response text for the component begins with an initial ‘!’ delimeter, followed by the attribute key-value pairs associated with that component being delimited from each other by the ‘&’ delimiter. The response will also include routing information (not shown) to ensure the response is correctly forwarded from the server3across the network5to the client device1.

The response transmitted from the server3is received by the response receiver41in the client device1. The response receiver41parses the response using the delimiters ‘!’ and ‘&’ to separate out the attribute key-value pairs for each component. The response receiver41then uses the parsed data to create and fill in the entries of a component data table43for each matching component. The component data table43for the Money Transfer component is shown below:

Once the response receiver has processed the response and generated the component tables43, it informs the application container35, which uses the component name fields in each table43to generate a display of the available components70for display to the user on the display29. The list of available components may be presented in the form of a menu on the display29from which the user can select the desired component70to run.

Upon user selection of a component70(for example via the keyboard27), the application container35instantiates the code provider module45into RAM25and informs it of the component70that has been selected by the user. The code provider module45then retrieves the URL of the selected component from the component data table43for the selected component. The code provider module45then retrieves the selected component from the Internet5using the retrieved URL. This may be achieved using conventional Internet protocols such as FTP. In this embodiment, components are retrieved in ‘stored’ form rather than as ‘serialised’ memory objects. This significantly reduces the amount of data that has to be downloaded over the Internet5as memory instantiated objects are always larger than their stored counterpart. Furthermore, sending the components70in ‘stored’ form avoids a potential security risk of using RMI, in which an in-memory object on one computer can be directly accessed and manipulated by an in-memory object on another computer.

The retrieved component is then passed to the application container35, which instantiates the component in the RAM25. Once instantiated, the component is initialised and started in accordance with it's initialise and start methods defined in its component data table43and the functionality provided by the downloaded component is provided to the user. In this example, the functionality allows the user to transfer money from one account to another.

In this embodiment, the downloaded component may allow the user to download other components. In particular, a component can itself search for other components that it needs, by making a distinct search request to the server3, independently from the application container35. In order to provide scalability, these requests are not hard-coded into the component's logic, but instead are of a similar form to those described above. For example, if the Money Transfer component can call other components then it first makes a configuration request to the server3, of the form:

The search config file includes general configuration data for the component (such as server details) and configuration data that determines the type of components that the Money Transfer component is permitted to search for. For example the search config file may include:

!config&host=www.testserver.com&port=80!search_config&package_name=MoneyTransfer_Support,Banking_Support
In this example, the MoneyTransfer component is told by the server3that it can search for components70that belong to the “MoneyTransfer Support” and “Banking_Support” application package.

The Money Transfer component then uses this information in the received search config file to format a suitable request for the server, to find available components that it can call. Such a subsequent request may have the following form:

Any components70downloaded and activated by the MoneyTransfer component are then instantiated within the memory space of the MoneyTransfer component and are controlled by it. Having a hierarchical system of components contained within the calling components in this way provides for significantly easier management than having all the components70coexist in the application container35independently.

Once the user has finished using the downloaded component, the application container35(or the calling component) terminates or stops the downloaded component in accordance with the stop method defined in the component data table43for the downloaded component and the memory is freed for use by other processes. More specifically, the application container35(or the calling component) has the downloaded component implement the appropriate dispose method (as defined in its component data table43), which frees all resources used by that component, such as network channels or references to other components70that the component in question has activated. Once the dispose method has completed, the application container35(or the calling component) deletes any references it has to that component. Once a component has no active references pointing to it, the system garbage collector (as implemented by the underlying platform, such as Java or .NET) will remove the component from memory.

As will be apparent to those skilled in the art, the above system offers a number of significant advantages over more conventional systems where the software is stored and run on the client device1. For example, by downloading the available software components70at run-time, it is not necessary to store all components70for the software that the user might want to use. Instead, only the components70that the user wants to use are downloaded and run on the client device1.

This frees up valuable storage space for user data such as music, images and video. Additionally, as the software components70are stored in a repository7, which may be stored on the server3(or in some other server on the Internet5), it is easier to update the components70if they have bugs and need to be replaced or to add new functionality to existing components70. In particular, as the components70are not permanently stored on each client device1, it is not necessary to update each client device1each time a modification is made to a component. The software component only has to be modified once in the repository7.

In addition to the ability to modify and update existing components70, the system described above offers the advantage that software developers can develop new components70and these can be made available to the client devices1simply by adding a new descriptor68to the index62that is searched by the repository provider69. Similarly, if functionality is to be removed from users, then the components70that provided that functionality can be made unavailable simply by removing the descriptor68for that component70from the index62that is searched by the repository provider69in this embodiment, the repository admin provider71maintains the index62stored in the repository7, keeping it updated with details of new components70as they are added to the local and/or remote repositories7.

One of the advantages of using the tree structure for the descriptor68for each component70(as illustrated inFIG. 7) is that it allows the object based descriptor68to be generated automatically by the repository admin provider71from an XML file64that describes the component70. For example, the following is an XML file64for the Money Transfer component descriptor68illustrated in internalised, in-memory form inFIG. 7:

To generate the in-memory object descriptor68illustrated inFIG. 7, the repository admin provider71parses the above XML file64to identify the descriptor labels and for each descriptor label, the attribute labels associated therewith. The repository admin provider71then creates attribute objects for each attribute found in the XML file64and associates it with the appropriate descriptor object68. Once the descriptor object68for the component has been generated, the repository admin provider71adds it to the existing index62stored in the repository7.

Modifications and Alternatives

In the above embodiment, the index62and the software components70were stored in the repository7provided locally to the server3. As those skilled in the art will appreciate, the software components70can be stored in any location, provided their locations are known and can be provided to the client device1.

Similarly, the index62of descriptors68can be provided remotely from the server3. These remote repositories may be hosted in various types of databases such as Oracle 10i, IBM DB2, InterSystems Cache or as XML. If so, the query generated by the query generator65will have to be reformatted into a suitable format for querying the remote repository and similarly, the response from the remote repository will have to be reformatted before being passed to the response generator73. Nevertheless, as the search results returned from the database will be fielded by the repository provider69and be internalised as descriptors and attributes, the internal workings of these remote databases will be irrelevant to the operation of the server.

The above embodiment makes use of Sun Microsystems' Java programming language, and in particular the client software is based on the Connected Device Configuration (CDC) of Java 2 Micro Edition (J2ME), the server on J2EE Java Servlet technology. However, as those skilled in the art will appreciate, this invention can also be implemented in, for example, Microsoft's C# language or .NET/.NET Compact platforms or others.

In the above embodiment, communications between client device1and server3were sent as plain text. An alternative would be to encrypt the parts of the client device request relating to the client device/interests using any suitable encryption techniques.

In the above embodiment, the client device1included a single application container35that operated in the above described manner. In an alternative embodiment multiple application containers may be provided on the client device1. For example, one application container may be provided that relates to a gambling application, another application container may relate to an entertainment application. Each application container35preferably operates with its own server3and repository7of software components70.

A further alternative is to provide a ‘lobby’ facility, wherein access to a number of component servers is provided from a single application container35running on the client device1, with each component server providing access to applications particular to a specific set of services, perhaps from distinct service providers, much as a real-world lobby might offer access to a number of services and service providers from a common space. This may be implemented by including multiple ‘interests’ in the client config file37, each one identifying an application that can be called and to which the user has subscribed.

In the above embodiment, the responses of the server3to the client device1were tailored to the client device according to known details of the client device hardware and software capabilities as defined in the received client request. Alternatively, the details of the client device hardware and software capabilities may be deduced from the characteristics of the client communication.

In the above embodiment, the client device1made a request of the server3from values stored in its config file37, and received a response from the server3detailing matching components70. Alternatively, the server3may first respond by updating the config file37. For example, in the banking application embodiment presented above, the first request from the client device1specified profile_version=1.0. In response to the first query from the client device1, the server3response could, according to policy, be to update the config file37in order to downgrade the profile version of the components70the client device1will search for, from profile_version=1.1 as in the original query, to profile_version=1.0. This could be done because, for example, a security flaw had been found in components70matching profile_version=1.1, and it was found necessary to use alternative components70. In this case the response from the server3would take the form:

In the above embodiment, one example was given of a ‘banking’ component, MoneyTransfer, searching for other components70. As an alternative, a further example is now presented involving an image viewer component, which needs to call on other components70to help it decode a particular image file. Upon sending the configuration request to the server3, the config file sent in response by the server3will contain “package_name=Imaging_Formats”, informing the image viewer component that it can search for components70in the “Imaging_Formats” application package. When the image viewer component interrogates the image file, it may, for example obtain the filename suffix, and therefore the subsequent request it sends to the server3, in order to find a suitable decoder component, will include this filename suffix information (e.g. JPEG), and therefore be of the form:

!config&host=www.testserver.com&port=80&GUID=mj1d2b3h4f4455h5n67jb4g48i4h
When sending further requests back to the server3, the calling component would append this GUID to its request. This could be done for reasons of security or for auditing purposes. For example, the GUID could be used to allow a user to run a restricted application. The user would have to undergo an authentication process in order to be permitted to download and run a particular component of the restricted application. This component would then be assigned a GUID for use in subsequent component requests.

For additional security, for example in financial services, a component such as MoneyTransfer could be programmed to download a user security component, which provides a further level of authentication, such as at the point where the user is asked to confirm the details of the money transfer.

In the above embodiment, the component data table43was populated from details contained in a response from the server3to an initial request from the client1. In an alternative embodiment, the application container35may periodically update the component data table43by generating additional queries at later times. This allows the application container35or the calling component to be kept up to date with any changes that are made in the server3.

In the above embodiment, data stored in the component data table43included details of the method_init attribute, used for initialising the associated component i.e. setting the component to its default configuration, in readiness for being started according to the method_start attribute. A discrete initialisation method, as described by the method_init attribute, can also be used to reset an already-started component.

In the above embodiment, the code provider45on the client device1used the HTTP protocol to fetch the required component from the repository7on the server3. Alternatively, any other suitable communications protocol could be used, such as, for example, the file transfer protocol (FTP).

In the above embodiment, the descriptors68for each component70were stored in the index62as a set of Java objects. Similarly, the attribute objects associated with each descriptor were also stored as Java objects. In an alternative embodiment, the descriptors68and associated attributes for each component70may be defined by XML documents or even as text. In this case, the search of the index would comprise a text based search of the query terms against the text in the index.

In the above embodiment, the client devices1were mobile telephones. As those skilled in the art will appreciate, the client devices1can be other networked portable computing devices such as (but not limited to) personal digital assistants, gaming handhelds, digital set-top boxes, and in-car entertainment systems.