Data Container for User Interface Content Data
A data container is provided 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.
The present invention relates to a data container and in particular to data containers for use with user interface content data for mobile devices for use with a mobile communications network.
BACKGROUND OF THE INVENTIONOne of the growth areas for mobile network operators and content providers is the provision of ringtones, wallpapers and other multimedia content for mobile telephones and devices. There is a tension between the needs of mobile network operators and device manufacturers to retain control over some aspects of the device user interfaces for branding purposes and the needs of users to customise and modify the appearance of their devices to suit their own needs. The sophisticated software required to provide the desired flexibility and customisation is also in tension with the limited processing power and data storage capacity of typical mobile devices. The present invention seeks to mitigate these problems.
SUMMARY OF THE INVENTIONAccording to a first aspect of the present invention there is provided a method of provisioning a user interface to a device, the method comprising the steps of a) creating a container, the container comprising: executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the container; b) transmitting the container to one or more devices; c) extracting the contents of the container at the or each device; and d) executing the code to generate a user interface for the device.
According to a second aspect of the present invention there is provided a data carrier comprising computer executable code for performing the above described method
According to a third aspect of the present invention there is provided a server for provisioning a user interface to one or more devices, the server comprising: storage means to receive a data container; editing means to enable the data container to be edited, in use the data container comprising executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the data container; and transmission means for transmitting a data container to one or more devices.
According to a fourth aspect of the present invention there is provided a method of installing a user interface in a device, the method comprising the steps of: a) receiving at a device a container over a communications network, the container comprising: executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the container; b) extracting the contents of the container at the device; and c) executing the code to generate a user interface for the device.
According to a fifth aspect of the present invention there is provided a data carrier comprising computer executable code for performing the above described method.
According to a sixth aspect of the present invention there is provided device comprising a display, a user interface, storage means, processing means and a communication interface, the device being configured, in use, to receive a data container from a communications network via the communications interface; store the data container in the storage means; process the data container using the processing means to extract the contents of the data container, the data container comprising executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the data container; form a user interface in accordance with the extracted contents of the data container; and display the user interface in the device display.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will now be described by way of illustration only and with respect to the accompanying drawings, in which
The system can be envisaged as being divided into three separate domains: 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 the content feeds and UI feeds that may be controlled or operated by a number of different entities.
The publishing component user interface 114 can be used to import a parcel into the database 111, and this process causes references to each trig and triglet to be loaded into the import queue 114, which may comprise references to a plurality of parcels 210a, 210b, . . . . The contents of the parcel may be examined using the user interface and the contents of the parcel can be passed to the catalogue.
The MNO may have several publishing 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 publishing scheme describing how objects are to be published onto content servers in both live and staging environments. The publishing component GUI provides several different views to each domain, enabling operators to completely manage the publishing of content. The catalogue comprises references to the Trigs stored in the catalogue and the update channels and feed channels used to transfer content to the various domains. For each domain, the operator uses the publishing component GUI to set up the domain structure and allocate trigs from the catalogue to each domain node. To aid the operator in selecting trigs efficiently, a filter is provided in the catalogue so that only relevant items are shown.
A trig may be allocated to several nodes within a domain. In each case the packaging of the trig on the target server may need to be different e.g. a SIS or CAB file, dependent on the handsets that will be accessing the trigs. The packaging can be controlled using the publishing component GUI.
The update channels may be referenced by trigs to control the delivery of the content. An update channel comprises a URL which is a link to a resource on the associated domain that comprises a triglet update package. The URL can be polled at predefined intervals and the HTTP GET function used to access the package (it will be readily appreciated that other transport schemes may be used, for example SyncML or SMS or cell broadcast for small updates). The triglet update package describes how the trig can be modified, e.g. replacing one or more images or text files used by the trig. The publishing component GUI enables an operator to define and control the update channels that exist for a domain, the URLs associated with each triglet on the update channel and the association of triglets with the update channels for a domain. As each triglet is associated with an update channel, an operator may enter the date and time that the update should be published, enabling a schedule to be set.
A content feed is similar to an update channel for which the content updates are automatically generated on a regular basis. A content feed is accessed by polling a URL, retrieving the update packet and applying it to the trig. However because of the different nature of manually constructed triglet updates and automatically generated content, update channels and content feeds are managed separately. Again, other transport schemes may be used such as SyncML or OMA-DM (Open Mobile Alliance Device Management).
The content server component 150 is a standard implementation of a web server and as such the scaling model is well understood. The capabilities of a server can be rated using a “SPECweb99” number indicating the number of concurrent sessions that the web server can handle under benchmark conditions. Published SPECweb99 numbers range from 404 to 21,000 with typical commercial web servers having SPECweb99 numbers in the order of 5,000. A typical deployment scenario for 1 m subscribers with hourly updating content requires a web server with a SPECweb99 rating of only 1,112. A successful deployment will lead to increased service use which can be provided for by enabling additional servers to create an infrastructure that can be both scalable and highly resilient to failure.
A connection may be made to the server from a mobile device via a WAP Gateway. In this case the web server session exists between the WAP gateway and the web server, rather than the mobile phone and web server. When a request is made for a file via the WAP gateway, the session with the web server lasts only as long as it takes to transfer the file from the web server to the WAP gateway—i.e. the session is extremely short since the connection bandwidth will be very high and latency extremely low.
Alternatively a direct connection may be established between the mobile phone and the web server. In this case, the web server will need to keep the session open for as long as it takes to download the data to the phone.
There are two types of content that are delivered by the content server component: trigs, typically of the order of 100 KB and regularly updating triglets which are typically of the order of 1 KB. The traffic created by trig downloads is very similar to the traffic generated by existing content downloads. And thus the related issues are well understood. Downloads of regular triglet updates are a new feature in an MNO's traffic model but because of the small size of the updates, which typically fit within one data packet, it is possible to show that the traffic can still be handled by typical web servers.
It is preferred that the software operates using TrigML, which is an XML application and that mark-up language renderer 410 renders the TrigXML code for display on the mobile device 300. The mark-up language renderer also uses the TrigML Parser to parse TrigML resources, display content on the device screen and controlling the replacement and viewing of content on the handset. The native UI renderer is used to display UI components that can be displayed without the use of TrigML, and for displaying error messages.
The software 400 is provisioned and installed in a device specific manner. For example for a Nokia Series 60 device the software is installed using a SIS file, whereas for a MS Smartphone device the software is installed using a CAB file. Similarly, software upgrades are handled in a device specific manner. The software may be provisioned in a more limited format, as a self-contained application that renders its built in content only: i.e. the software is provisioned with a built-in trig but additional trigs cannot be added later. The supplied trig may be upgraded over the air.
The trig manager 465 presents an interface to the resource manager 430 and the mark-up language renderer. It is responsible for trig management in general. This includes: persisting knowledge of the trig in use, changing the current trig, selection of a trig on start-up, selection of a further trig as a fall back for a corrupt trig, maintaining the set of installed trigs, identifying where a particular trig is installed to the resource manager and reading the update channel definitions of a trig and configuring the update manager appropriately.
The resource manager provides an abstraction of the persistent store on device, i.e. storing the files as real files, or as records in a database. The resource manager presents a file system interface to the mark-up language renderer and the update manager. It is responsible for handling file path logic, distinguishing between real resource files and actor attributes, mapping trig-relative paths onto absolute paths, interfacing with the trig manager and providing a modification interface to the update manager.
The Update Manager handles the reception and application of Trigs and Triglets. The Update Manager presents an interface to the Renderer and the trig Manager and is responsible for: the initiation of manual updates when instructed to by the Renderer; controlling and implementing the automatic update channel when so configured by the trig manager; indicating the progress of a manual update and recovering an Update following unexpected loss of network connection and/or device power. The update packet format may be defined as a binary serialisation of an XML schema.
XML is a convenient data formatting language that is used to define the update packet format as well as TrigML content. For bandwidth and storage efficiency reasons, text XML is serialised into a binary representation. Both update packets and TrigML fragments are parsed by the same component, the MARK-UP LANGUAGE PARSER parser. Any further use of XML in the software must use the binary XML encoding and therefore re-use the parser.
The Actor Manager 440 looks after the set of actors 445 present in the software. It is used by: the renderer when content is sending events to an actor; actors that want to notify that an attribute value has changed and actors that want to emit an event (see below).
The software preferably comprises a multi-threaded application running a minimum of two threads, with more possible depending on how many and what sort of actors are included. The software runs mostly in one thread, referred to as the main thread. The main thread is used to run the renderer which communicates synchronously with other components. Actors always have a synchronous interface to the Renderer. If an actor requires additional threads for its functionality, then it is the responsibility of the Actor to manage the inter-thread communication. It is preferred that a light messaging framework is used to avoid unnecessary code duplication 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 packets and is separate from the main thread to allow the renderer to continue unaffected until the packet has arrived. The Update Manager is responsible for handling inter-thread messaging such that the Update Manager communicates synchronously with the Renderer and Resource Manager when applying the changes defined in an Update Packet.
The software 400 is provisioned to mobile devices in a device specific method. One or more Trigs can be provisioned as part of the installation, for example, stored as an uncompressed update packet. On start-up, the packet can be expanded and installed to the file-system.
The Actors 445 are components that publish attribute values and handle and emit events. Actors communicate with the Renderer synchronously. If an actor needs asynchronous behaviour, then it is the responsibility of the actor to manage and communicate with a thread external to the main thread of the Renderer.
Actor attributes may 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 having a simple value; or a vector of structures. Attributes may be referenced by an expression using an object.member notation similar to many object-orientated programming languages:
-
- <image res=“signallevels/{protocol.signalstrength}”/>
When needed as a file, an attribute is accessed via the /attrs folder.
-
- <text res=“/attr/network/name”>
An Actor can be messaged by sending it an event with the <throw> element. Events emitted by actors can be delivered to the content tree as content events: these can be targeted at an element Id or ‘top’. The interface to an actor is defined by an Actor Interface Definition file. This is an XML document that defines the attributes, types, fieldnames, events-in and parameters, and events out. The set of actors is configurable at build-time for the software. Appendix A gives an exemplary listing of some actors that may be used, along with the associated functions or variables.
Updates comprise a new trig (a new or replacement UI) or a triglet (a modification to an existing trig) and may be regarded as modifications to the software file-system. The Update Manager to determine what needs changing in the file-system by reading a packet. Update Packets may be downloaded over the air by the software 400 using HTTP, or other suitable transport mechanisms, wrapped in a device-specific package format or pre-provisioned with the installation of the software itself.
There are other failure modes to consider: if an HTTP-GET cannot be initiated, or is met with an HTTP error response code, then this attempt at an Update is abandoned and the retry strategy is used to begin a new update attempt at a later date. Where an HTTP response is interrupted by 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 great 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 header data file is deleted and the Update attempt and any subsequent retries are cancelled.
The content format is common across all platforms implementing the software. The Content Compiler is a content authoring tool to transform a collection of raw resources (text TrigML, PNG images, text string definitions) into an over the air Update Packet that can be written to the file system of the device.
TrigML fragments are files containing text TrigML and resource references inside these fragments are virtual file paths. The mapping of these virtual file paths to real file paths is defined by a TrigDefinition file. This file also defines other properties of the trig. When used for compiling a triglet, this file also defines how the input TrigML/PNG/Text resources map onto modifications of the virtual file-system of a trig.
For PNG and Text Resources the trig Definition file points at a list of real files on the host file-system and the resources are copied to the outputs.
TrigML can use constant variables instead of attribute values. Constant variables are accessed with the same syntax as <include> parameters, e.g. $background_colour. Constants are treated as global variables in a trig and are defined in the reserved folder, constants/. The variable definitions contained in the files in the constants/ folder may be resolved at compile time with direct substitution of their values. In an alternative embodiment the variable definitions in constants/ are compiled as global variables and resolved at content parse time by the software. This allows the trig to be updated by a simple replacement of one or all of its constants files.
In order to successfully render the user interface of a mobile device, the mark-up language must have the following qualities: concise page definitions, consistent layout rules, be implementable in a compact renderer, provide multiple layering and arbitrary overlapping content, event model, require the repaint of only the areas of the display that have to change between pages of the UI, include hooks to the platform for reading property values receiving events and sending events, extensible, and be graphically flexible. TrigML provides these features and an overview of the elements and attributes that provide the desired functionality is given in our co-pending application GB0403709.9, filed Feb. 19, 2004.
It is desirable that the cost of re-branding UIs and producing a continual stream of updates is minimal. This is enabled this by providing an efficient flow of information from the creative process through to the transmission of data to users.
A container, referred to as a parcel, is used for UIs, UI updates, and templates for 3rd party involvement. Parcels contain all the information necessary for a 3rd party to produce, test and deliver branded UIs and updates.
The parcel process comprise five processing stages:
1) The scripting environment 220 provides the means to design the template for one or more UIs and the update strategy for UIs based on that template.
2) The maintenance environment 240 provides for rapid UI and update production in a well-controlled and guided environment that can be outsourced to content providers.
3) The maintenance environment 240 ‘pre-flight’ functionality allows the deployment administrator to check and tune the UIs and updates that they receive from 3rd parties.
4) The publishing component 110 provides management of UIs and updates at the deployment point, including the staging of new releases.
5) The publishing component 110 enables the automatic generation of updates from live content feeds.
In a typical project, parcels are created within the scripting environment 220 for: a content provider to create re-branded UIs from a template, incorporating the same ‘feel’ but a different ‘look’; a content provider to create updates from a template, that provide a periodic, or user selected variation to UI content; or an ad agency to create updates from a template that promote new services on a periodic basis.
For all of these use cases, maintenance environment 240 is used to import the parcel, re-brand and reconfigure the content and create a new parcel for submission to the publishing component 110. In the design of the UI template, the following issues should be considered: which part of the UI can be re-banded; which features of a UI need to be reconfigured at re-branding or remotely; which part of the UI content may be updated; and if the UI is re-branded then can user select content feeds in use. The scripting environment 220 allows these strategies to be defined, and enables the maintenance environment 240 as the implementer of each instance of each strategy.
The main functions of the scripting environment 220 may comprise:
-
- Defines menu structure and page map.
- Defines the framework into which branding content is placed.
- Defines the parts of the UI that are updateable.
- Defines the parts of updates that are replaceable for re-branding.
- Provides an interactive preview to assist editors
- Provides a graphical code view of each UI layer
- Allows drag and drop of resources into the interactive preview and code view.
- Exports templates for specific re-branding or update construction tasks
- Simulates UIs and updates on handset simulator.
- Builds UIs and updates for testing on the real device.
- Provides extended debugging tools to aid development.
Furthermore, the purpose of the maintenance environment 240 is to provide a designer and administrator's UI for the re-branding and maintenance of skins and updates, with the main functions comprising:
-
- Re-branding UI templates
- Populate updates with new content
- Manage UI menu entries via updates
- Translate UIs and updates for additional languages
- Purpose strings and content for additional devices
- Simulation of UIs deployed on handset simulator.
- Build of UIs and updates for testing on a real device Rebranded UI
A parcel is generated by the scripting environment 220 which comprises a template UI or update for editing. Once editing is complete the parcel is saved in an ‘outbox’ ready for despatch to the maintenance environment 240 for publishing to the content server. The following ‘parcel’ functions are provided. The maintenance environment 240 can be used to edit/replace resources held within the parcel. Parcels can be exported to the simulation environment to test the performance of the UI or UI update on a mobile device.
An explorer is provided for the user to access these categories, with the user being able to change: any UIs or updates marked as visible or the resources within a UI or update that are marked as ‘replaceable’. When saved, a thumbnail of the ‘visible’ object is saved in the parcel, for identification use in the maintenance environment and for other services.
A parcel entry may be double clicked to launch an appropriate editor. (for example, an image resource would launch an image editor). All resources may have a text description/note inserted in the maintenance environment and displayed in the appropriate context in the maintenance environment. Lists of menu entries are handled as a special resource type with each entry presenting its own sub-catalogue of resources (for example—title, help string, image, roll-over image, URL and ringtone preview).
Many different UIs can be derived from a common base. Typically the common base would implement most of the interface itself, and Trigs derived from it would implement small variations on it, such as branding. A Triglet can be derived from a Trig, and it can override any of the resources from the parent Trig that it chooses to (optionally it may introduce its own resources). Note that “resources” here also refers to TrigML, so the behaviour and layout of a Trig can be modified by a Triglet just as easily as it replacing a single image or piece of text.
A Parcel may comprise one or more base Trigs (i.e. a Trig that is not derived from any other trig), one or more multiple Trigs derived from a base Trig, a plurality of triglets derived from any of the trigs and a plurality of triglets derived from other triglets.
The parcel format is an opaque binary format that stores all this information as serialized objects. The parcel may comprise a number of resources, such as images, text, URLs, update channels, ringtone files, wallpapers, native applications, etc. Each resource contains permission information as to how to view, edit, or delete the resource. Each resource furthermore contains meta information such as documentation and instructions that are relevant to that resource. Each Parcel tool either assumes a relevant role, or requires users to login as a particular role.
The nature of developing trigs is such that a number of people and/or groups of people could be involved in contributing to the final design and implementation of a Trig. Furthermore, the skill sets of these people require that a very simplified and controlled scheme be used to minimize the risk of unwitting damage to the Trig. A typical development workflow for a reasonably complex Trig could comprise:
-
- UI Designers create the original UI structure. This design may be built using the maintenance environment to create the first versions of this UI.
- A graphics designer creates the final graphics, and adds them to the design.
- The areas of the UI dedicated to dynamic content that were identified in the original design need to be fleshed out.
- Graphics for the dynamic update need to be finalised by a graphics designer.
- Personalisation areas of the UI are then designed and implemented. This might be handled by a number of third-party content providers.
Parcels assist in the workflow described above because they contain the entire project in the single file, and this makes it easy to pass from one member of the team to the next. The Parcel can be re-targeted for the next stage of development by adding comments and instructions on the resources that need to be modified, and even setting the editability of other resources to restrict what can be changed. More complicated workflows can be supported by allowing Parcels to be forked, and separate development to happen in each fork of the Parcel. Merge tools allow the individual changes to be combined back into a single Parcel. A parcel may be implemented using the pickle module for the Python programming language.
The parcels may be used to develop trigs and/or triglets for mobile devices having different capabilities such as display size, RAM capacity. To simplify this, a number of hierarchies may be defined and the data resource or TrigML element classified within the hierarchies. When a trig or triglet is compiled from a parcel, the most appropriate resources or TrigML elements can be selected and complied for a particular device.
The nature of these components and interfaces will depend upon the nature of the device. It will be understood that such a user interface can be implemented within a mobile or cellular telephone handset, but it is also applicable to other portable devices such as digital cameras, personal digital organisers, digital music players, GPS navigators, portable gaming consoles, etc. Furthermore, it is also applicable to other devices that comprise a user interface, such as laptop or desktop computers.
The user interface means may comprise a plurality of buttons, such as a numerical or alpha-numerical keyboard, or a touch screen or similar. 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 if power is lost. ROM storage means may be provided to store data which does not need updating or changing. Some RAM may be provided for temporary storage as the faster response times support the caching of frequently accessed data. The device may also accept user removable memory cards and optionally hard disk drives may be used as a storage means. The storage means used will be determined by balancing the different requirements of device size, power consumption, the volume of storage required, etc.
Such a device may be implemented in conjunction with virtually any wireless communications network, for example second generation digital mobile telephone networks (i.e. GSM, D-AMPS), so-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 campuses other technologies such as Bluetooth, IrDa or wireless LANs (whether based on radio or optical systems) may also be used. USB and/or FireWire connectivity may be supplied for data synchronisation with other devices and/or for battery charging.
Computer software for implementing the methods and/or for configuring a device as described above may 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 number 0403709.9, filed Feb. 19, 2004, the contents of which are incorporated herein by reference.
Claims
1. A method of provisioning a user interface to a device, the method comprising the steps of
- a) creating a container, the container comprising: executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the container;
- b) transmitting the container to one or more devices;
- c) extracting the contents of the container at the or each device; and
- d) executing the code to generate a user interface for the device.
2. A method according to claim 1, wherein the metadata comprise data determining access to the executable code and/or the or each content resource to prevent unauthorised access to the executable code and/or the or each content resource during step (a).
3. A method according to claim 1 or claim 2, wherein if during step a) the executable code and/or a content resource is altered, the metadata is updated accordingly.
4. A method according to any preceding claim wherein, the metadata relating to the or each content resources relates to one or more hierarchical classifications, the hierarchical classification(s) relating to the capabilities of a device.
5. A method according to any preceding claim, further comprising the step of
- e) processing the container contents into a format for transmission to a device, step e) being performed subsequent to step a) and prior to step b).
6. A server for provisioning a user interface to one or more devices, the server comprising:
- storage means to receive a data container;
- editing means to enable the data container to be edited, in use the data container comprising executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the data container; and
- transmission means for transmitting a data container to one or more devices.
7. A server according to claim 6, wherein the server further comprises a processing means configure, in use, to process a data container prior to transmission of a data container to one or more devices.
8. A data container comprising computer executable code for performing the method of any of claims 1 to 5.
9. A method of installing a user interface in a device, the method comprising the steps of:
- a) receiving at a device a container over a communications network, the container comprising: executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the container;
- b) extracting the contents of the container at the device; and
- c) executing the code to generate a user interface for the device.
10. A method according to claim 9, wherein the metadata comprises data determining access to the executable code and/or the or each content resource to control access to the executable code and/or the or each content resource during step (b).
11. A method according to claim 10, wherein the access-determining metadata can be updated in response to receiving a control message from the communications network.
12. A data container comprising computer executable code for performing the method of any of claims 9 to 11.
13. A device comprising a display, a user interface, storage means, processing means and a communication interface, the device being configured, in use, to
- receive a data container from a communications network via the communications interface;
- store the data container in the storage means;
- process the data container using the processing means to extract the contents of the data container, the data container comprising executable code for a user interface; one or more content resources for use in the user interface; and metadata relating to the or each content resource, the executable code, the or each content resource and the metadata being stored as serialised objects within the data container;
- form a user interface in accordance with the extracted contents of the data container; and
- display the user interface in the device display.
14. A device according to claim 13, wherein the metadata stored in the storage means comprises data determining access to the executable code and/or the or each content resource to control access to the executable code and/or the or each content resource.
15. A device according to claim 14, wherein the device is further configure, in use, to receive control commands from the communications network via the communications interface, the control commands updating the metadata that determines access to the code and/or content resource(s).
Type: Application
Filed: Feb 18, 2005
Publication Date: Dec 27, 2007
Inventors: Michael Tunmer (Cambridge), Martin Dickens (Peterborough)
Application Number: 10/598,167
International Classification: G06F 9/445 (20060101); G06F 9/44 (20060101);
