MXPA06009487A - Data container for user interface content data - Google Patents

Abstract

A data container is prodded for use in provisioning content data fore the user interface of a device, such as mobile telephone. The container comprises content data and metadata relating to the content data, the metadata limiting access to the content data and/or providing a contest for the use of the content data within the user interface.

Description

DATA DEPOSIT FOR USER INTERFACE CONTENT DATA FIELD OF THE INVENTION The present invention relates to a data warehouse and in particular to data repositories for use with user interface content data for mobile devices for use with a mobile communication network.

BACKGROUND OF THE INVENTION One of the growing areas for mobile network operators and content providers is the provisioning of ringtones, wallpaper backgrounds, and other multimedia content for phones and mobile devices. There is a tension between the needs of mobile network operators and device manufacturers to retain control over some aspects of the user interfaces of the devices for marking purposes and the needs of users to customize and modify the appearance of their devices. devices that fit your own needs. The sophisticated software that is required to provide the desired flexibility and customization is also in tension with the processing power and limited data storage capacity of typical mobile devices. The present invention seeks to mitigate these problems.

SUMMARY OF THE INVENTION According to a first aspect of the invention, a method for providing a user interface to a device is provided, the method comprises the steps for a) creating a repository, the repository comprising: an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the repository; b) transmit the deposit to one or more devices; c) extract the content of the deposit in the device or in each device; and d) execute the code to generate a user interface for the device. According to a second aspect of the present invention, a data carrier is provided comprising a computer executable code to execute the method described above. According to a third aspect of the present invention, a server is provided to provide a user interface to one or more devices, the server comprises: storage means for receiving a data warehouse; editing means for allowing the data repository to be edited, in use, the data repository comprises an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the data warehouse; and transmission means for transmitting a data warehouse to one or more devices. According to a fourth aspect of the present invention, a method for installing a user interface in a device is provided, the method comprises the steps to: a) receive in a device a deposit on a communications network, the deposit comprises: an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the repository; b) extract the content of the deposit in the device; and c) execute the code to generate a user interface for the device. According to a fifth aspect of the present invention, a data carrier is provided comprising a computer executable code for executing the method described above. According to a sixth aspect of the present invention, a device comprising a screen, a user interface, storage means, processing means and a communication interface is provided, the device is configured, in use, to receive a deposit of data from a communications network through the communications interface; store the data warehouse in the storage media; processing the data warehouse using processing means to extract the content from the data warehouse; the data warehouse comprises an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the data warehouse; forming a user interface according to the content extracted from the data warehouse; and display the user interface on the device screen.

BRIEF DESCRIPTION OF THE FIGURES Figure 1 shows a schematic representation of a system embodying the present invention; Figure 2 shows in more detail the structure and operation of the server; Figure 3 shows a schematic representation of software 400 for mobile devices; Figure 4 shows a schematic representation of the set of content tools; and Figure 5 shows a schematic representation of a device comprising a user interface according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION The invention will now be described by way of illustration only and with respect to the appended figures, wherein Figure 1 shows a schematic representation of a system embodying the present invention. The system comprises the server 100, the set of content tools 200, the mobile devices 300, Operational Support Systems (OSS) 700, content feeds 500, and user interface sources (Ul) 600. In use, server 100 communicates content and data data Ul to mobile devices 300, 301, ..., each of which comprises the software package 400. The server 100 is interfaced with OSS 700, where the OSS are those conventionally used to operate mobile networks, for example, billing, account management , etc. The server 100 also connects in interface with the set of content tools 200: the set of content tools receives the data from the sources Ul 600, 601, ..., and packages the Ul data so that the server can transmit the Ul data packaged to the software packages 400 comprised within the mobile devices 300. The server receives the data from a plurality of content feeds, and this data is processed and packaged so that it can be sent to the software packages 400 or for that the mobile devices 300 can access the data using the software package 400. The system can be contemplated as divided into three separate domains: the operator domain 50 comprises the systems and equipment operated by the mobile network operator (MNO); user domain 60 comprises a plurality of mobile devices and third-party domain 70 comprises content feeds and feeds Ul which can be controlled or operated by a number of different entities. Figure 2 shows in more detail the structure and operation of the server 100. The server 100 comprises the publishing component 110 and the content server component 150. The publishing component comprises the database 111, the import queue. 112, the interface of the content toolset 113, the user interface 114 and the catalog 115. In operation, the editorial component receives content from the content toolset in the interface of the content toolset. The content is presented in the form of a pack 210a, 210b, ..., (see below) comprising one or more Trigs and one or more Triglets. A Trig is a user interface for a mobile device, such as a mobile phone and a Triglet is a data file that can be used to extend or alter a Trig. If a packet comprises more than one Trig interface, then one of the Trig interfaces can be a master Trig interface from which other Trig interfaces are derived. The user interface of the editorial component 114 can be used to import a packet into the database 111, and this procedure causes the references to each Trig and Triglet to be loaded to the import queue 114, which may comprise references to a plurality of packets 210a, 210b, ... The content of the package can be examined using the user interface and the contents of the package can be passed to the catalog. The MNO can have several editorial domains, for example one for each target server in a number of countries or regions. Each domain is treated in isolation from other domains and has its own editorial scheme that describes the way in which the objects are going to be published on the content servers in both live environments and in immigration environments. The GUI editorial component provides several different views for each domain, allowing operators to fully manage the publication of the content. The catalog includes references to the Trig interfaces stored in the catalog and the update channels and feed channels used to transfer content to the various domains. For each domain, the operator uses the GUI editorial component to establish the domain structure and assign the Trig interfaces from the catalog to each domain node. To help the operator in the selection of Trig interfaces efficiently, a filter is provided in the catalog so that only the relevant sections are shown. A Trig interface can be assigned to several nodes within a domain. In each case, the packaging of the Trig interface on the target server may need to be different, for example, a SIS or CAB file, depending on the computers to which the Trig interfaces will have access. The packaging can be controlled using the GUI editorial component. The update channels can be referenced by the Trig interfaces to control the delivery of the content. An update channel comprises a URL, which is a link to a resource in the associated domain that comprises a Triglet file update package. The URL can be registered at predefined intervals and the HTTP GET function can be used to access the package (it will be easily appreciated that other transport schemes can be used, for example SyncML or SMS or cellular broadcast for small updates). The Triglet file update package describes how the Trig interface can be modified, for example, by replacing one or more images or text files used by the Trig interface. The GUI editorial component allows an operator to define and control the update channels that exist for a domain, the URLs associated with each Triglet file in the update channel, and the association of the Triglet files with the update channels for a domain. Because each Triglet file is associated with an update channel, an operator can enter the date and time the update should be published, allowing a program to be established. A content feed is similar to an update channel for which content updates are automatically generated on a regular basis. You have access to a content feed by registering a URL, retrieving the updated package and applying it to the Trig interface. However, due to the different nature of manually constructed Triglet file updates and automatically generated content, the update channels and content feeds are managed separately. Again, other transport schemes such as SyncML or OMA-DM (Open Mobile Alliance Device Management) can be used. The content server component 150 is a standard execution of a Web server and, because of this, the escalation model is well understood. The capabilities of a server can be classified using a number "SPECweb99" that indicates the number of simultaneous sessions that the web server can handle under reference conditions. The range of SPECweb99 numbers published ranges from 404 to 21,000 with typical commercial web servers that have SPECweb99 numbers in the order of 5,000. A typical deployment scenario of 1 million subscribers with update content every hour requires a web server with a SPECweb99 ranking of only 1, 112. A successful deployment will lead to an increased use of the service which can be provided by additional enabling servers to create an infrastructure that can be scaled and has a high capacity to recover from failures. A connection to the server can be established from a mobile device through a WAP gate. In this case, the web server session exists between the WAP gateway and the Web server, instead of the mobile phone and the web server. When a request for a file is made through the WAP gate, the session with the web server lasts only what it takes to transfer the file from the web server to the WAP gate, that is, the session is extremely short because The connection bandwidth will be very high and the latency extremely low.

Alternatively, a direct connection can be established between the mobile phone and the web server.

In this case, the web server will need to keep the session open for the entire duration of the download of the data to the phone. There are two types of content that are delivered by the content server component: Trig interfaces, typically of the order of 100KB and regular update Triglet files, which are typically of the order of 1KB. The traffic created by the Trig interface downloads is very similar to the traffic generated by existing content downloads. And, therefore, the related problems are well understood. The downloads of regular Triglet file updates are a new feature in an MNO traffic model but due to the small size of the updates, which typically fits within a data packet, it is possible to show that traffic can still be managed by typical web servers. Figure 3 shows a schematic representation of the software 400 for the mobile devices 300, which comprises a marking language provider 410, an update manager 420, a network communication agent 425, a resource manager 430, a system virtual files 435, an actor manager 440, a plurality of actors 445a, 445, ..., a native U 450 provider, a support manager 460, a Trig 465 interface manager, and a language parser marked 470. It is preferred that the software operate using TrigML, which is an XML application and that the markup language provider 410 supplies the TrigXML code for deployment on the mobile device 300. The markup language provider also uses the TrigML Syntactic Analyzer to syntactically analyze the TrigML resources, display the content on the screen of the device and control the replacement and visualization of the content on the device. The native Ul provider is used to deploy Ul components that can be deployed without the use of TrigML, and to display error messages. Software 400 is provisioned and installed on a device in a specific way. For example, for a Nokia Series 60 device, the software is installed using an SIS file, while for an MS S artphone device, the software is installed using a CAB file. Similarly, software updates are handled on a device in a specific way. The software can be provisioned in a more limited format, such as a self-contained application that supplies its integrated content only: that is, the software is provisioned with an integrated Trig interface but no Trig interfaces can be added later. The supplied Trig interface can be updated in the air. The Trig 465 interface manager presents an interface to the resource manager 430 and the marking language provider. This is responsible for the management of the Trig interface in general. This includes: having a persistent knowledge of the Trig interface in use, changing the current Trig interface, selecting a Trig interface at startup time, selecting an additional Trig interface as a degraded operation for a corrupted Trig interface, maintaining the set of interfaces Trig installed, identify the place where a particular Trig interface is installed for the resource manager and read the definitions of the update channel of a Trig interface and configure the update manager appropriately. The resource manager provides an abstraction of the persistent storage in the device, that is, the storage of the files as real files, or as records in a database. The resource manager presents a file system interface to the markup language provider and the update manager. This is responsible for handling the path logic of the file, distinguish between real resource files and actor attributes, map trajectories related to the Trig interface over absolute trajectories, connect in interface with the Trig interface manager and provide a modification interface to the update manager. The Update Manager handles the reception and application of Trigs and Triglets (interfaces and files). The Update Manager presents an interface to the Supplier and the Trig Interface Manager and is responsible for: the initiation of manual updates when so ordered by the Supplier; control and execute the automatic update channel when it is configured by the manager of the Trig interface; indicate the progress of a manual update and retrieve an Update after the unexpected loss of the network connection and / or power of the device. The update package format can be defined as a binary serialization of an XML schema. XML is a convenient data formatting language that is used to define the updated package format as well as the TrigML content. For reasons of storage efficiency and bandwidth, XML text is serialized in a binary representation. Both the updated packages and the TrigML fragments are analyzed syntactically by the same component, the SIGN CINCO ANALYZER OF MARKED LANGUAGE. Any additional use of XML in the software, you must use binary XML encoding and, therefore, reuse the parser. The Actors Manager 440 searches for the set of actors 445 present in the software. This is used by: the supplier when the content is sending events to an actor; actors who want to notify that an attribute value has changed and actors who wish to broadcast an event (see below). The software preferably includes a multi-threaded application that runs a minimum of two threads, with possibilities for more threads, depending on how many and what kind of actors are included. The software runs mostly in a thread, which is referred to as the main thread. The main thread is used to run the supplier, which communicates synchronously with other components. The actors always have a synchronous interface with the Supplier. If an actor requires additional threads for its functionality, then it is the responsibility of the Actor to manage inter-thread communication. The use of a luminous message sending scheme is preferred to avoid unnecessary duplication of codes in cases where many actors require inter-thread communication. In addition to the main thread, the update manager runs a network thread. The network thread is used to download update packages and is separated from the main thread to allow the supplier to remain unaffected until the package has arrived. The Update Manager is responsible for handling the sending of inter-thread messages so that the Update Manager communicates synchronously with the Supplier and the Resource Manager when applying the changes defined in an Update Package. Software 400 is provisioned to mobile devices in a specific device method. One or more Trig interfaces can be provisioned as part of the installation, for example, they can be stored as an updated uncompressed package. At the time of startup, the package can be expanded and installed in the file system. Actors 445 are components that publish attribute values and handle and issue events. The actors communicate with the Supplier synchronously. If an actor needs asynchronous behavior, then it is the responsibility of the actor to manage and communicate with a thread external to the main thread of the Supplier.

Actor attributes can be read as file references. Attributes are one of four types: a single simple value; a vector of simple values; a single structure of fields, each field with a simple value; or a vector of structures. Attributes can be referenced by an expression that uses an object annotation. element similar to many programming languages oriented to the object. < image res = "signallevels / { protocol. signalstrength.}." / > When needed as a file, an attribute is accessed through the / attrs folder. < text res = "/ attr / network / name" > An Actor can handle messages by sending an event with the < throw > (< launch >). The events emitted by the actors can be delivered to the content tree as content events: these can be addressed in an element ID or "top part". The connection in interface with an actor is defined by the Actor Interface Definition file. This is an XML document that defines the attributes, types, field names, input events and parameters, and output events. The set of actors can be configured, at the time of its construction, for the software. Appendix B provides an exemplary list of some actors that can be used, along with associated functions or variables. Updates include a new Trig interface (a new or replacement Ul) or a Triglet file (a modification to an existing Trig interface). and can be seen as modifications to the software's file system. The Update Manager to determine what needs to be changed in the file system by reading a package. The update packages can be downloaded on the air through the software 400 using http, or other convenient transport mechanisms, wrapped in a specific device package format or pre-provisioned with the software installation itself. There are other failure modes to consider: if you can not start an HTTP-GET, or you encounter an HTTP error response code, then this attempt on an Update is abandoned and the retry strategy is used to start a new attempt of update at a later date. When an HTTP response is interrupted by the loss of network signal, any temporary files are deleted and the retry strategy is used to restart the Update attempt at a later date. If an update header indicates that the update payload size may be too large to fit on the device, if the update requires an incompatible version of the software, or if the Update already resides on the device, then the data file Header is deleted and the Update attempt and any subsequent retries are canceled. The content format is common on all platforms that run the software. The Content Compiler is a content writing tool to transform a collection of raw resources (text, TrigML, PNG images, definitions of text sequences) in an Update Package on air that can be written in the device file system. TrigML fragments are files that contain TrigML of text, and the resource references within these fragments are virtual file paths. The mapping of these trajectories from virtual files to real file paths is defined by a TrigDefinition file. This file also defines other properties of the Trig interface. When used to compile a Triglet file, this file also defines how input TrigML / PNG / Text resources are mapped on modifications to the virtual file system of a Trig interface.

For PNG and Text Resources, the Trig definition file points to a list of actual files in the guest file system and the resources are copied to the outputs. TrigML can use constant variables instead of attribute values. You have access to constant variables with the same syntax as the parameters <; include > , for example $ background_colour. The constants are treated as global variables in a Trig interface and are defined in the reserved folder, constants /. The definitions of variables contained in the files in the constants / folder can be resolved at the time of compilation with the direct substitution of their values. In an alternative modality, the definitions of variables in constants / are compiled as global variables and are solved at the moment of the syntactic analysis of the content by means of the software. This allows the Trig interface to be updated through a simple replacement of one or all of its constant files. In order to successfully deliver the user interface of a mobile device, the markup language must have the following qualities: concise page definitions, consistent deployment rules, it must be able to run on a compact supplier, provide multiple content of arbitrary overlap and layer, event model, requiring the readjustment of color only of the areas of the screen that have to change between pages of the Ul, include hooks for the platform to read property values that receive events and send events, must be extendable and graphically flexible. TrigML provides these features and an overview of the elements and attributes that provide the desired functionality is provided in our co-pending application GB0403709.9, submitted on February 19, 2004. It is desirable that the cost of re-marking the UIs and The production of a continuous stream of updates is minimal. This is enabled by the provision of an efficient flow of information from creative processing through the transmission of data to users. A deposit, which is called a package, is used for the Ul, the updates of the Ul and the templates for the participation of third parties. The packages contain all the necessary information for a third party to produce, test and deliver UI and marked updates. Figure 4 shows a schematic representation of the set of content tools 200, which comprises the writing environment 220, the test and simulation environment 230 and the maintenance environment 240.

The package procedure comprises five processing steps: 1) The write environment 220 provides the means to design the template for one or more Ul and the update strategy for the Ul based on that template. 2) The maintenance environment 240 provides a rapid production of Ul and updates in a well-controlled and guided environment that can be assigned to content providers. 3) The maintenance environment 240, the "pre-flight" functionality allows the deployment administrator to review and tune the Ul and updates received from third parties. 4) Editorial component 110 provides Ul management and updates at the deployment point, including the assembly of new versions. 5) The editorial component 110 enables the automatic generation of updates of the maintenance content feeds. In a typical project, packages are created within the 220 writing environment so that: a content provider creates Ul highlighted from a template, incorporating the same "feel" but a different "appearance"; a content provider creates updates of a template, which provide a periodic variation or selected by the user for the content of the Ul; or an advertising agency creates updates to a template that promotes new services on a periodic basis. For all these use cases, the maintenance environment 240 is used to import the package, highlight and reconfigure the content and create a new package for delivery to the editorial component 110. In the design of the Ul template, the following points: which part of the Ul can be highlighted; which characteristics of the Ul need to be reconfigured at the time of the remark or remotely; which part of the content of the Ul can be updated; and if the Ul is highlighted, then know if the user can select the content feeds in use. The writing environment 220 allows defining these strategies, and enables the maintenance environment 240 as the executor of each case of each strategy. The main functions of the writing environment 220 may include: • Defining the structure of the menu and the mapping of the page. • Define the scheme in which the marking content will be placed. • Define the parts of the Ul that can be updated.

• Define the parts of the updates that can be replaced for re-dialing. • Provide an interactive preview to help publishers. • Provide a graphic code view of each Ul layer.

• Allow drag and drop of resources in the interactive preview and code view. • Export templates for specific re-marking or update construction tasks. • Simulate Ul and updates in the equipment simulator. • Build Ul and updates for testing on the actual device. • Provide extended debugging tools to assist in development. In addition, the purpose of maintenance environment 240 is to provide a designer and administrator Ul for the re-marking and maintenance of clichés and updates, where the main functions include: • Re-marking Ul templates • Populating updates with new content • Manage the Ul menu entries through updates • Translate the Ul and updates for additional languages • Sequences of purpose and content for additional devices • Simulation of the ül displayed in the equipment simulator • Build the Ul and updates for test in an Ul highlighted by a real device. A package is generated by the writing environment 220 which comprises an Ul template or update for editing. Once the edition is complete, the package is saved in an "outgoing mailbox" ready for dispatch to the maintenance environment 240 for publication to the content server. The functions of the following "package" are provided. The maintenance environment 240 can be used to edit / replace resources that remain within the package. Packages can be exported to the simulation environment to test the performance of the Ul or update it on a mobile device. An explorer is provided so that the user has access to these categories, where the user can change: any Ul or update marked as visible or resources within an Ul or update that is marked as "replaceable". When saved, a brief review of the "visible" object in the package is also saved, for identification use in the maintenance environment and for other services. You can double click on a package entry to launch an appropriate editor. (For example, an image resource would launch an image editor). All resources can have a text / note description inserted in the maintenance environment and displayed in the appropriate context in the maintenance environment. Lists of menu entries are handled as a special type of resource where each entry presents its own sub-category of resources (for example, title preview, help sequence, image, moving image, URL and tone). Many different Ul can be derived from a common base. Typically, the common base would execute most of the interface itself, and the Trig interfaces derived from it would execute small variations on it, such as dialing, a Triglet text can be derived from a Trig interface, and it can override any of the resources of the matrix Trig interface you choose (optionally you can enter your own resources). It should be noted that "resources" here also refers to TrigML, so that the behavior and deployment of a Trig interface can be modified through a Triglet text as easily as replacing a single image or piece of text. A packet may comprise one or more Trig base interfaces (i.e., a Trig interface that does not derive from any other Trig interface), one or more multiple Trig interfaces derived from a Trig base interface, a plurality of Triglets files derived from any of the Trig interfaces and a plurality of Triglets files derived from other Triglets files. The package format is an opaque binary format that stores all this information as serialized objects. The package may comprise a number of resources, such as images, text, URLs, update channels, tone files, wallpaper backgrounds, native applications, etc. Each resource contains authorization information regarding how to view, edit or delete the resource. Each resource also contains meta information such as documentation and instructions that are relevant to that resource. Each package tool assumes a relevant function or requires users to register as a particular function. The nature of the Trig interface development is such that a number of people and / or groups of people could be involved in the final design and execution of a Trig interface. In addition, the skill sets of these people require that a very simplified and controlled scheme be used to minimize the risk of unintentional damage to the Trig interface. A typical development workflow for a reasonably complex Trig interface could include: • That the designers of the Ul believe the original Ul structure. This design can be built using the maintenance environment to create the first - versions of this Ul. • That a graphics designer create the final graphics and add them to the design. • That the areas of the Ul dedicated to the dynamic content that were identified in the original design be developed. • That the graphics for the dynamic update are finished by a graphics designer. • That the areas of personalization of the Ul be designed and executed later. This could be handled by a number of third-party content providers. The packages help in the workflow described above because they contain the entire project in a single file, and this facilitates its passage from one member of the team to the next. The package can be reoriented for the next stage of development by adding comments and instructions on the resources that have to be modified, and even establishing the ability to edit other resources to restrict what can be changed. More complicated workflows can be supported by allowing packets to be bifurcated, and in each bifurcation of the packet a separate development occurs. Fusion tools allow individual changes to be combined together in a single package. A package can be run using the preserving module for the Python programming language. The packages can be used to develop Trig interfaces and / or Triglet files for mobile devices that have different capabilities such as screen size, RAM capacity. To simplify this, you can define a number of hierarchies and the data resource or TrigML element can be classified within the hierarchies. When you compile a Trig interface or Triglet file from a package, the most appropriate resources or TrigML elements can be selected and compiled for a particular device. Figure 5 shows a schematic representation of a device 800 comprising a user interface according to an embodiment of the present invention. The device comprises a screen 810 that displays the user interface 815 and the user interface means 820, which allow the user to interact with the user interface 815. A processor 830 executes the software that is stored within one or more media of storage 840 and one or more wireless communication interfaces 850 may be provided to allow communication with other devices and / or communication networks. One or more batteries 860 may be received to power the device, which may also comprise interfaces for receiving electrical power and / or communication cables. The nature of these components and the interfaces will depend on the nature of the device. It will be understood that said user interface can be executed within a mobile or cell phone equipment, but also applies to other portable devices such as digital cameras, personal digital organizers, digital music players, GPS navigators, portable gaming consoles, etc. . In addition, it also applies to other devices that comprise a user interface, such as a laptop or desktop. The user interface means may comprise a plurality of buttons, such as a numeric or alphanumeric keypad, or a touch screen or the like. One or more storage devices may comprise a form of non-volatile memory, such as a memory card, so that the stored data is not lost in the event of a loss of power. The ROM storage media can be provisioned to store data that does not need updating or change. Some RAM can be provided for temporary storage since faster response times support frequently used data caching. The device can also accept user removable memory cards and, optionally, hard disk drives can be used as a storage medium. The storage medium used will be determined by taking stock of the different requirements of device size, energy consumption, the volume of storage required, etc. Said device can be executed together with virtually any wireless communication network, for example, second generation digital mobile telephony networks (ie GSM, D-AMPS) called 2.5G networks (i.e., GPRS, HSCSD, EDGE), Third-generation WCDMA or CDMA-2000 networks and improvements to, and derivatives of, these and similar networks. Within buildings and enclosures, other technologies such as Bluetooth, IrDA or wireless LAN (either based on optical or radio systems) can also be used. USB connectivity and / or firewall can be provided to synchronize the data with other devices and / or to charge the battery. The computer software for executing the methods and / or for configuring a device, as described above, can be provided on data carriers such as floppy disks, CD-ROMS, DVDs, non-volatile memory cards, etc. This application claims the benefit of UK Patent Application No. 0403709.9, filed on February 19, 2004, the content of which is incorporated in the present invention by reference.

APPENDIX A

Claims (6)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS

1. - A method for provisioning a user interface to a mobile device, the method comprises the steps of: a) creating a deposit, the deposit comprises: an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the repository; b) transmit the deposit to one or more mobile devices; c) extract the content of the deposit in the mobile device or in each mobile device; and d) execute the code to generate a user interface for the device.

2. - The method according to claim 1, characterized in that the metadata comprises data that determines access to the executable code and / or the content resource or each content resource to prevent unauthorized access to the executable code and / or the resource of content or each content resource during step (a).

3. - The method according to claim 1 or 2, characterized in that if during step a) the executable code and / or a content resource is altered, the metadata is updated accordingly.

4. - The method according to any of the preceding claims, characterized in that the metadata that relate to the content resources or with each of the content resources are related to one or more hierarchical classifications, the hierarchical classifications are related to the capabilities of a mobile device.

5. - The method according to any of the preceding claims, which further comprises the step of: e) processing the content of the deposit in a format for transmission to a mobile device, step e) is executed after step a) and before step b).

6. A server to provide a user interface to one or more mobile devices, the server comprises: storage means to receive a data warehouse; editing means for allowing the data repository to be edited, in use, the data repository comprises an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the data warehouse; and transmission means for transmitting a data warehouse to one or more devices. 1 . - The server according to claim 6, characterized in that the server further comprises a processing means configured, in use, to process a data warehouse before the transmission of a data warehouse to one or more mobile devices. 8. - A data carrier comprising a computer executable code to execute the method of any of claims 1 to 5. 9. A method for installing a user interface in a device, the method comprises the steps of: a ) receiving in a device a deposit on a communication network, the deposit comprises: an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the repository; b) extract the content of the deposit in the mobile device; and c) execute the code to generate a user interface for the device. 10. The method according to claim 9, characterized in that the metadata comprises data that determines access to the executable code and / or the content resource or each content resource to control access to the executable code and / or the content resource or each content resource during the step (b) ). 11. The method according to claim 10, characterized in that the metadata for determining the access can be updated in response to the reception of a control message from the communication network. 12. A data carrier comprising a computer executable code for executing the method of any of claims 9 to 11. 13.- A mobile device comprising a screen, a user interface, storage means, processing means and a user interface, the mobile device is configured, in use, to: receive a data warehouse from a communications network through the communications interface; store the data warehouse in the storage media; processing the data warehouse using processing means to extract the content from the data warehouse; the data warehouse comprises an executable code for a user interface; one or more content resources for use in the user interface; and metadata related to the content resource or to each content resource, the executable code, the content resource or each content resource and the metadata are stored as serialized objects within the data warehouse; forming a user interface according to the content extracted from the data warehouse; and display the user interface on the device screen. 14. The mobile device according to claim 13, characterized in that the metadata stored in the storage means comprise data that determines access to the executable code and / or the content resource or each content resource to control access to the code executable and / or the content resource or each content resource. 15. The mobile device according to claim 14, characterized in that the device is also configured, in use, to receive control commands from the communications network through the communications interface, the control commands update the metadata that determine access to the code and / or content resources.