MXPA06009485A - Virtual file system - Google Patents

Abstract

The virtual file system is described that enables both real data resources, such as a content file, and virtual data resources, such as a field within a database or a state determined by a mark-up language element, to be accessed through a single root.

Description

VIRTUAL FILE SYSTEM FIELD OF THE INVENTION The present invention relates to a virtual file system and in particular to a virtual file system 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 present invention, there is provided a mobile device comprising: a storage means for storing a plurality of data resources; a file system for organizing the plurality of data resources stored in the storage means of the mobile device; and a user interface for providing access to the user to the plurality of data resources, wherein: i) the file system comprises one or more locations comprising directly dirigible data resources and one or more locations comprising data resources Indirectly dirigible, indirectly dirigible data resources are accessible through a data provider; and ii) the archiving system is configured, in use, to provide a single interface of the user interface, both directly augmented data resources and indirectly steerable data resources. Directly augmented data resources can comprise data content files that, in use, are deployed within the user interface. Indirectly blinking data resources may comprise a database and, in use, the result of one or more questions is displayed within the user interface. In addition, the indirectly steerable data resources comprise a markup language element and, in use, the markup language element is delivered and the associated result is displayed within the user interface. According to a second aspect of the present invention, a method is provided for storing a plurality of data resources within a file system of a mobile device, the method comprising the steps for: defining one or more locations comprising resources of directly dirigible data; defining one or more locations that comprise indirectly steerable data resources, indirectly steerable data resources are accessible through a data provider; where the filing system provides a single interface of the user interface to access both directly augmented data resources and indirectly steerable data resources. According to a third aspect of the present invention, a data carrier comprising a computer executable code for executing the methods described above is provided.

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 100; Figure 3 shows a schematic representation of software 400 for mobile devices 300; I, FIG. 4 shows a schematic representation of the set of content tools 200; Figure 5 shows a schematic representation of four hierarchical planes; and Figure 6 shows a schematic representation of a device 800 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 content toolset 200, the mobile devices 300, the operational support systems (OSS) 700, the content feeds 500 and the user interface sources (Ul) 600. In use, the server 100 communicates content data and data Ul to the 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 set of content tools 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. Figure 3 shows a schematic representation of the software 400 for the mobile devices 300, which comprises a markup 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 supply the TrigXML code for deployment on the mobile device 300. The markup language provider also uses the TrigML Syntactic Analyzer for syntactically analyze the resources of TrigML, display the content on the device screen 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 a MS Smartphone 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. It is responsible for managing the path logic of the file, distinguishing between real resource files and actor attributes, mapping trajectories related to the Trig interface over absolute paths, connecting in interface with the Trig interface manager and providing a modification interface to the update manager. The Resource Manager is also responsible for ensuring the integrity of resources stored in persistent storage, especially in the face of unpredictable interruptions such as the loss of device power. The Resource Manager is not aware of the Trig interface currently used. Its interface is secure to the threads (since it can be used by both the Update Manager and the Supplier from different threads). 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. The Support Manager provides an interface for other components to report the occurrence of an event or error. Depending on the severity of the error, the Support Manager will log the event and / or cause an error message to appear.

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 parser of dialed 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 can comprise 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 the 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. The memory allocation strategy of the software is platform-specific. On MIDP platforms, the software simply uses the system's stack and garbage collector for all of its memory requirements. Garbage collection is forced whenever a content replacement event occurs in an attempt to keep the garbage collection predictable and not suffer unexpected breaks in the operation. It is assumed that any memory allocation could fail, in which case the software will remove all references to objects, garbage collection, and restart, assuming that the software has already been successfully started and has provided the first page. On platforms based on C ++ -, a mix of pre-assignment and assignment-on-order will be made from the system's stack. All the memory required for the start is assigned over-order during startup, where any failure here causes the output (with message, if possible) of the software. After the successful start, the memory required to deliver the content document model is pre-assigned. The content provided is written to use less than a defined limit that is guaranteed to deliver. Additional use is made of RAM for several caches required for fast software operation. In cases where memory conditions are low, these caches will be released resulting in slow delivery performance from the software. Errors that are severe enough to disrupt the normal operation of the software should result in the appearance of a dialog box. The dialog box contains one of a small number of internationalized error messages (internationalized versions of these sequences can be collected in the software at the time of their construction, where the version of a sequence of errors for deployment is determined by the configuration of the relevant language in the device). To keep the number of messages to a minimum, only a few generic problems are covered. To allow support situations, the error dialog boxes also display an error code such as a 4-digit (16-bit) hexagonal sequence. Each error code is associated with a description text that can be used by support personnel to determine the nature of a problem with the software. Errors that occur in the software and that are not severe enough to stop their operation can be registered by the Support Manager component. The Support Manager can be questioned by the user by typing special key sequences. The Support Manager can also provide its error log to a server through an http GET or POST method. The Supplier receives information regarding the key pressure. If there is no configured behavior, at the time of construction, for a key, it is sent as a TrigML content event to the current focused element. The content event is then handled as defined by the normal event processing logic of the TrigML. For example, if a key is pressed, a "key pressure" event is delivered to the Supplier with a parameter set for the relevant key. When the key is released, a "key pressure" event is delivered to the Supplier. If a key is held down for an extended period of time, a "long key pressure" event is delivered to the Supplier. At the time of release, both the "prolonged key pressure" and "key pressure" events are delivered to the Supplier. Whenever the software starts, it executes the following actions: • It checks and continues with the interrupted Update processing; • Reviews and processes the Updates that reside in the file system (either previously provisioned or installed in the file system through some other means); • If you know it, start the current Trig interface (which may be the last Trig interface that was run); • If a current Trig interface is not established, then a Trig interface that has been tagged as a Trig interface "by default" can be started. • In the absence of a default Trig interface, the first valid Trig interface will be selected in alphabetical order of name. A Trig interface is started by loading the name of the defined resource, start / default. The TrigML defined in start / default is analyzed syntactically as the new content for the content source node. The first time a Trig interface is run by the software after its installation, the Trig interface is started by loading the "name of the start / first time resource." The software can register whether a Trig interface has been run or not in a file located in the top-level folder for that Trig interface Depending on the platform used by the mobile device, you can set the automatic start of the software as a configuration option at the time of construction, in addition, the placement of the software in the background, After a self-start, it can also be a configuration option at the time of construction.The user can be presented with a launcher as an application icon and by selecting it the software starts with a Trig interface specified by that launcher (this interface Trig can be indicated by an insole and / or launcher name.) When a launcher is used to initiate a Trig interface, it is possible to specify a "entry point" parameter. The parameter is a resource name of a file found in the "start" folder. This file is not used if the Trig interface has never been run before, in which case the file called "first time" is used. The software uses the content resource files stored in a virtual file system on the device. The file system is described as virtual since it can not be executed as a classic file system; however, all references to resources are file paths as if they were stored in a hierarchical folder and file system. Appendix A provides details regarding the arrangement of the filing system. In addition, the software stores part or all of the following information: usage statistics; active user counts; state of the Trig Interface Manager; fragments of TrigLM and update channel definition (serialized as binary XML); PNG images; flat text, encoded as UTF-8 OTA and then stored in a specific platform encoding; other platform-specific resources, for example, tone files, background images, etc.

The files in the file system can be changed, either when changing an actor attribute value, or when a file is replaced by a Triglet file. When the files in the / attrs directory change, the Supplier is notified immediately and the relevant branches of the content tree are updated and renewed. When images and text resources are changed, the Supplier behaves as if the affected resources are immediately recharged (it can be renewed either the entire content tree or just the affected branches). When TrigML fragments are changed, the Supplier behaves as if it were not notified and continues to display its current content, possibly outdated. This is to avoid the need for the software to persist in < include > (< include >) and history < load > (< load >) of the current content. 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. One of the limitations that is common in most mobile devices is that the display screen is quite small and when a menu is displayed, it is not always possible to display all the menu sections on the screen at the same time. Conventional approaches tend to load all menu sections in memory, along with associated icons or graphics, and then deploy them appropriately as the user moves the menu forward or backward. A technique is provided that limits the number of menu sections that will be loaded into the memory to the number of sections that can be displayed on the screen at the same time. When the user goes through the menu, the sections that are no longer displayed are discarded and the sections that are currently displayed are loaded into the memory. Preferably, this can be executed using an < griddata > in TrigLM to define a list view of some data, where the data is stored in a folder in the file system, and the appearance of the list has the same structure for each section. The < griddata > It includes a "repeat again" attribute that specifies the folder in which the data is found. The unique element of < griddata > It is a template for the appearance of each section in the list. The template uses a special symbol, for example "$$" to refer to the iterator. This is the variable template that changes every time the template is exemplified: for example < griddata repeatover = "news / headlines" > < text res = "news / headlines / $$ / title.txt" / > < / griddata > Where, the folder news / headlines / contains: 0 / title.txt 1 / title. txt 2 / title.txt 3 / title. txt This would display a list of 4 sections, each described by an element < text > simple by pointing to the resource "title.txt" in the folder "news / headlines / $$". In cases where the source data has more sections in them than the available space of the < griddata > for the screen, the < griddata > it only displays those sections that can be displayed. When the user goes through the list, the < griddata > change the "data window" accordingly. The advantage of this technique is that, in reality, only the resources required by the current screen are loaded into the memory, which reduces memory utilization and reduces the amount of time it takes to present the list of sections. A similar scheme can be used to define the order in which a list is displayed. If the objective of the "repeat again" attribute is a file instead of a folder, then it can be assumed that the file contains a list of resource names to use in the iteration. For example, < griddata repeatover = "football / league" > < text res = "football / teams / $$ / name. txt" / > < / griddata > Where, the football / league file contains: Manchester Arsenal Chelsea The football / teams / folder contains: Manchester / name. text Arsenal / name. text Chelsea / name. text and each yam. txt is a text file that has the name of the computer. The result of this is that the test files associated with the equipment would be displayed in the defined order and within the defined area of the device's screen. The software uses a virtual file system 435, which allows a conventional file system to be incorporated with other forms of data so that data stored in any part of the virtual file system can be accessed in a common way. Examples of non-conventional data storage that can be integrated into said virtual file system include data stored within a database or data that was generated upon request by an additional software component. For example, in conventional mobile devices, information regarding battery power, signal strength, new text messages, etc. The user is shown and this information is typically obtained when the operating system sends a call to the relevant hardware or software entity and the Ul interprets the received response and displays it. This information can be displayed in the Ul using a TrigML tag (see below), such as < phonestatus > (or < signalstrength >). Provisioning of this tag triggers an auditory question to the relevant hardware or software entity. If a change of state occurs, then the supplier of the Ul is notified and the supplier of the Ul loads the relevant icon or graphic to communicate the change of state to the user. If the user changes the view within the Ul, the tag can be removed and the auditory question ends. This approach is more resource efficient since the auditory question is only activated when the label is in use. The virtual file system comprises a single source that contains directly dirigible data resources, such as content files (eg, text, graphics, video, audio, etc.), and indirectly steerable data resources, such as TrigML tags or data stored within a database. This provides a user with a unified view through the user interface which allows the user to access the different types of data that are maintained within the virtual file system. At the same time that the different types of data are presented to the user in this way, the data can remain stored in a method that enables the efficient storage and retrieval of data.

For commercial reasons, it is desirable that the MNOs and / or content providers can have some control over the user interface that will be displayed on the screen of a mobile device. It is also important that there is a degree of flexibility that allows users to download Triglets files or new Trig interfaces to modify the appearance of their device and also to make additional changes to the displayed image that is determined by the Trig interface or the Triglet file in use. This problem can be corrected by considering the Ul to be formed from a number of hierarchical levels, each of the levels comprising one or more entities of the Ul. By assigning a hierarchy to the MNO, to the manufacturer of the device, to the provider of the Trig interface and the user of the device, it is possible to provide the required levels of authorization. Figure 5 shows a schematic representation of four hierarchical levels 405a-d: the level 405a comprises Ul elements defined by the MNO; level 405b comprises Ul elements defined by the device manufacturer; the level 405c comprises Ul elements defined by a Trig interface; and level 405d comprises Ul elements defined by the user. Level 405a has the highest position in the hierarchy and level 405d has the lowest position in the hierarchy. For example, the mno_logo element, at level 405a, defines the graphic element used and its position on the device's display screen. Because it is located at the highest level of the hierarchy, it will always appear and take precedence over any other element Ul in a minor hierarchy element that attempts to use the pixels used by mno_logo. The level 405d comprises the background color element, which is not defined in any of the other levels and, therefore, the color defined in the background color will be used in the Ul. Level 405c comprises the windowtitle.txt element that defines the attributes for the text used in the title of a window. This can be overwritten by adding a windowtitle.txt element to level 405a or 405b to define the text attributes, or by adding a windowtitle element. txt_deleted either for level 405a or 405b, to instruct the supplier of the Ul to ignore any subsequent windowtitle.txt element. The user can establish a preference within the software 300 to control the content that is displayed within the Ul. For example, the content related to a number of soccer teams can be stored on a server with a trajectory that has a form similar to /demoUI/football/team_xxxx/team_menu.png where the variable team_xxxx is selected by the user of a list of equipment (manu, chel, leed, mane, etc.) and inserted in the path for the Ul to display the content related to the selected equipment. A change in the variable team_xxxx will cause the displayed content to be modified accordingly. It should be appreciated that the selection of a preference controls the display of content that is selected from content stored on a remote server, as opposed to the selection of content that is stored in local storage. This approach is preferred to having to send a request in the form: http: // ti. trigenix. com / triglets / football / triglet & pn = "077665 5443322" as in the case where the server needs to run a database questionnaire to identify the content that is to be deployed, and this will significantly increase the resources required of the server to provide the requested content. Another known technique through which the same result can be obtained is to send a request in the form: http: // ti. trigenix. com / triglets / football / triglet & fc "ManU" but one disadvantage of this approach is that every time a new team is added, then the server logic must be updated to include the new team. By contrast, this method requires that the content be added to the server in a new location, which is a simpler procedure and requires fewer resources for its execution. 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. Updates can be activated through a number of means, which include: • That the software checks the update processing interrupted at startup time • That the software checks the update packages pre-installed at startup • Automatically as required configured by an Update Channel • User initiation • The device receives a special SMS. The algorithm used to unpack and install an update is device specific. However, it is important that the algorithm be safe against unexpected interruption (for example, loss of power), so that it does not reach a state of corruption or that it is not possible to recover in the file system. This can be achieved by using two threads (one network thread and one thread from the supplier) in order to have as much processing as possible executed by the network thread to interrupt the supplier's thread as little as possible. 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 the 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. Alternatively, 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. A System Sequence Dictionary defines the integer values to be used for all well-known sequences, that is, reserved words. These have several types, including: attribute names and TrigML element ("group", "res", "layer", "image", "x"), TrigML attribute values (for example: "left", "activate") , "focus") and common resource trajectories (for example, "attr", "start-up", "default"). As an entry, the Sequence Dictionary is optional. The first time a Trig interface is compiled, it will not have a Sequence Dictionary. This first compilation creates the Sequence Dictionary, which is subsequently used for all future compilations of that Trig interface. The compilation of the Triglet file must have a Sequence Dictionary that defines all the mappings of the sequence used by the Trig interface that it is modifying. 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 provider, 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 our co-pending application GB0403709.9, submitted on February 19, 2004, provides an overview of the elements and attributes that provide the desired functionality. It is desirable that the cost of the re-marking of the Ul and the production of a continuous stream of updates be 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 environment test and simulation 230 and the maintenance environment 240. The package procedure comprises five processing steps: 1) The writing environment 220 provides the means to design the template for one or more Ul and the updating strategy for the Ul based in 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 they receive 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 stresses 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. 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 stored in an "outgoing mailbox" ready for dispatch to the maintenance environment 240 for posting to the content server. The functions of the following "package" are provided. The maintenance environment 240 can be used to edit / replace resources maintained within the package. Packages can be exported to the simulation environment to test the performance of the Ul or update the Ul on a mobile device. Many different Ul can be derived from a common base. Typically, the common base would execute most of the interface itself, and 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 Trig matrix interface it chooses (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. Figure 6 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 860 batteries can be received to power the device, which may also comprise interfaces for receiving electric 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 (ie, 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 For file paths that begin with a File paths without a V are treated as relative to the current Trig interface, that is, each Trig interface is stored in its own folder hierarchy originating in a single folder.

APPENDIX B

Claims (9)

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 mobile device comprising: a storage means for storing a plurality of data resources; a file system for organizing the plurality of data resources in the storage medium of the mobile device; and a user interface for providing the user with access to the plurality of data resources, wherein: i) the file system comprises one or more locations comprising directly dirigible data resources and one or more locations that comprise data resources indirectly dirigibles, you can have access to data resources directly dirigibles through a data provider; and ii) the archiving system is configured, in use, to provide a single interface of the user interface to both directly augmented data resources and indirectly steerable data resources.

2. The mobile device according to claim 1, characterized in that the directly dirigible data resources comprise data content files that, in use, are deployed within the user interface.

3. The mobile device according to claim 1 or 2, characterized in that the indirectly dirigible data resources comprise a database and, in use, the result of one or more requests is displayed within the user interface.

4. The mobile device according to claim 1 or 2, characterized in that the indirectly dirigible data resources comprise a marking language element and, in use, the marking language element is delivered and the associated result is displayed inside. of the user interface.

5. A method for storing a plurality of data resources within a file system of a mobile device, the method comprising the steps for: defining one or more locations comprising directly dirigible data resources; defining one or more locations that comprise indirectly steerable data resources, you can have access to indirectly dirigible data resources through a data provider; where the filing system provides a single interface of the user interface to access both directly augmented data resources and indirectly steerable data resources.

6. The method according to claim 5, characterized in that the method comprises the additional step of having access to a directly dirigible data resource so that the content of the data resource is displayed within the user interface.

7. - The method according to claim 5, characterized in that the method comprises the additional step of having access to an indirectly steerable data resource, the data resource comprises a database so that the result or results of a request of the database is deployed within the user interface.

8. - The method according to claim 5, characterized in that the method comprises the additional step of having access to an indirectly steerable data resource, the data resource comprises a marking language element so that the marking language element is delivered and the associated result is displayed within the user interface.

9. - A data carrier comprising a computer executable code for executing the method of any of claims 5 to 8.