Title of Invention	RENDERING A USER INTERFACE
Abstract	There is provided a user interface which is defined by a plurality of actors and the attributes that are associated with the actors. A renderer is used to render the user interface in accordance with the attributes of the actors. Changes in actor attributes, for example in response to a keypress, cause the user interface to be updated.

Full Text

RENDERING A USER INTERFACE 'H- « *ii^i 0? THE IKFVENTION Tiie present invention relates to rendering user interfaces and in particular to rendering user interfaces for cotnmunications devices. BACKGROUND OF THE INVENTION Communications devices, such as, for example mobile telephones and PDAs incorporate display screens of "increasing s±ze and resolution. Given the limitations -in processing power of these devices it is desirable to provide users with an attractive user interface that facilitates the use of the device and provides a fast response to user inputs . For some devices, such as mobile telephones; there is significant interest in providing user interfaces that can be readily and easily updated by the user and/or the network operator so that content for updating user interfaces can be de'ployed to users. Known approaches tend to either lack the required flexibility or require significant and undesirable levels of processing power. SUMMARY OF THE INVENTION According to a first aspect of the present invention there is pr-ovided a method of rendering a user interface for a device, th.e method comprising the steps of providing a plurality of actors, each of the plurality of actors being associated with a user interface element and comprising one or more attributes defining the respective actor; providing a renderer to receive one or more attributes from one or more of the plurality of actors and rendering the user interface in accordance with the received attributes. 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 device comprising: a user interface, the user interface comprising one or more user interface elements; a plurality of actors, each of the plurality of actors being associated with a user interface element and comprising one or more attributes; and a renderer, the renderer.; Being configured, in use, to interpret the attributes associated with one or more of the plurality of actors and *to render the user interface accordingly. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows a schematic depiction of a • system incorporating the present invention; Figure 2 depicts in greater detail the structure and operation of server 100; Figure 3 shows a schematic depiction of the "software 400 for the mobile devices 300; Figure 4 shows a schematic depiction of the content toolset 200; and Figure 5 shows a schematic depiction of a device that comprises a user interface according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION !Eb5 invention will now be described by way of illustration only and with respect to the ac conpsaying drawings, in wh:Lch Figure I shows a schematic depiction of a system comprising server 100, content toolBet 200, mobile devices 3O0, operational support systems (OSSs) 700, content feeds 500 and user interface (UI) sources 6O0. In use, the server H00 comrrrurLicates content data and UI data to the mobile devices 300, 3 01, «., each of which comprise software package 4O0. The server 100 interfaces with OSSs 700, with the OSSs be±ng those conventionally used to operate mobile networks; for sxauple billing, account managsment, etc. The server HDD fTirthsr interfaces with the con_tent toolset 2 00: the apxaitr-ezit toolset receives data from TO sources 60 0, 6 01, .», and packages the UI data such that: the server can transmit "the packaged UI data to the software packages 40 0 cornpsri sed vrithin the mobile devices 300. The server receives data from a plurality of content feeds, a.nd this The system can be envisaged as being divided into th.ree separate domains: operator domain 50 comprises the systems and equipment operated by the "mobile network operator (MNTO) ; user domain 60 coitrprises 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. Figure 2 depicts in greater detail the structure and operation of server 100. Server 100 comprises publishing component 110 and content server oomponent 150. Publishing companex& comprises database 111 , import queue 112, content toolset interface 113 , user interface 114 & catalogue 115. In operation, the publishing component receives content from the content toolset at the content toolset interface. The content is presented in the form of a parcel 210a, 210b, etc, (see below) comprising one or more Trigs and one or more Triglete. A trig is a user interface for a mobile device, such as a mobile telephone and a triglet is a data file ttiat can be used to extend or alter a trig. If a parcel comprises more than one trig then one of the Trigs may be a master trig from which the other Trigs are derived. Figure 3 shows a schematic depiction of the software 400 for the mobile devices 3 00, which comprises a mark-up language renderer 410, update manager 420, network communication agent 425, resource manager 430, virtual file system 435, actor manager 440, a plurality of actors 445a, 445, «., native UI renderer 450, support manager 460, trig manager 465 and raa.rk~ up language parser 470. The software may operate 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 scrreen. 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 4 00 is provisioned and installed in a device specific manner. Similarly, software upgrades are bandied in a device specific manner. The software may be provisioned ±n 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 43 0 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 feizishier-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 up-date 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 i 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 Resource Manager is also responsible for ensuring the integrity of the resources stored in the persistent store, especially in the face of unpredictable interruptions such as loss of device power. The Resource Manager has no knowledge of the trig currently used. Its interface is thread safe (as it wsrf be used by both the trpdate Manager and the Renderer from different threads. The Dpdate 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; control 1 ing and irrrpl ementing the automati c 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 cjde^ce power. The -update packet format may be defined as a binary serialisation- 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 put up an error message popup 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, Any further use of XML in the software must use the binary XML encoding and therefore reuse 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 vsnt to emit an event (see below) . The software may comprises a rnulti -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 Acfceasnio . manage the inter-thread communication. ■ A light messaging framework may be used to avoid unnecessary code duplication where many actors require inter-thread communication. It will be understood that it is also possible to implement, the software using a single threaded operation. 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 memory allocation strategy of the .software is platform specific. On MIDP platforms, the software simply uses the system heap and garbage collector for all 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 pauses in operation. It is assumed that any memory allocation might fail r in which case the software will delete all its references to obj ects, garbage collect, and restart assuming that the software has already successfully started up and rendered the first page. On C++-based platforms, a mixture of pre-allocation and on-demand allocation will be made from the system heap. All memory required for start-up is allocated on-demand during start-up, with any failures here causing the exit f MLth message if possible) of the software. Following successful start-up, memory needed for rendering the content document model is pre-allocated. Provided content is authored to- use less than a defined limit, it is guaranteed to render. Additional use is made of RAM for various caches needed for fast operation of the software. Where memory conditions are low, these caches will be released resulting in slow rendering performance from the'software. Errors that are severe enough to disrupt the normal operation of the software must result in a pop-up dialog box. The dialog box contains one of a small number of internationalised error messages (internationalised versions of these strings may be compiled into the software at build-time with the version of an error string to display being determined by the relevant language setting on the device) . To keep the number of messages to a minimum, only a few generic problems are covered. To allow for support situations, error dialogs also display an error code as a 4-digit (15-bit) hex string. Each error code is associated with a description text that can be used by support staff to determine the nature of a problem with the software. Errors that occur in the software and that are not severe enough to halt its operation may be logged by the Support Manager component. The Support Manager can be queried by the user typing special key sequences- The Support Manager can also supply its error log to a server via an HTTP GET or POST method. The P.enderer receives information regarding the key press. If there is no behaviour configured at build time for a >?sy^:V:;it is s ent as a Tr i gML c ont enr event to the current f o GIIS element. The content event is then handled as defined by TrigML's normal event processing logic. For example, if a key is pressed down, a 'keypress' event is delivered to the Renderer with a parameter set to they relevant key. When the key is released, a ' !keypress'/ event is delivered to the Renderer. If a key is held down for a extended period of time, a 'longkeypress' event is delivered to the renderer. On release, both a x llongkeypress' and a M keypress' event are delivered to the Renderer. Whenever the software is started, it executes the following actions: • Check for, and continue with, interrupted Update processing; • Check for, and process, Updates residing in the file system (either pre-provisioned, or installed to the file system by some other means); • If known, start the current trig (which, may be the last run trig); • If a current trig is not set; a trig that has been flagged as a * default7 trig can be started. • Failing the presence of a default trig, the first valid trig by alphabetical order of name will be selected. A trig is started by loading the defined resource name, start-up/default. The TrigML defined in start-up/default is parsed as the new contents for the content root node. The first time a trig is run by the software following its installation, the trig is started by loading the resonance name startup/f irsttime. The software' may record whether a trig has been run or not in a file located in the top level folder for that trig. Dependent on the platform used by the mobile device, the automatic start-up of the software may be set as a build-time configuration option. Furthermore, placing the software in the background following an autostart may also be a build-time configuration option. __ . ...... . . # - A launcher may appear to the user as an appliqation icon and selecting it starts the software with a trig specified by that launcher (this trig may be indicated by a launcher icon and/or name) . When using a launcher to start a trig, it is possible to specify an 'entry point1 parameter. The parameter is a resource name of a file found in the 'start-up7 folder. This file is not used if the trig has never been run before, in which case the file called 'firsttime' is used instead. The software uses content resource files stored in a virtual file system on the device. The file system is described as virtus! as it may not be iirr? lamented as a classical file-system., however, all references to resources are file paths as if stored in a hierarchical system of folders and files. Details regarding the arrangement .of the file-system for an embodiment of the present invention are given below in Appendix A. Furthermore, the software stores some or all of the following information: usage statistics; active user counts; TrigManager state; TrigML fragments & update channel definition (serialised as binary XML) ; PNG images; plain text; encoded as UTF-B OTA and then stored in a platform specific encoding? . other platform specific resources, e.g. rinc tone files, background images, etc. *■ Files in the file system can be changed, either when an actor attribute value changes, or when a file ' is replaced by a triglet. When files in the /attrs directory change, the Renderer is immediately notified and the relevant branches of the content tree are updated and refreshed. When images and text resources are changed, the Renderer behaves as if the affected resources are immediately reloaded (either the whole content tree or just the affected branches may be refreshed) . When TrigML fragments are changed, the tenderer behaves as if i it is not notified and continues to display its current, possibly out of date, content. This is to avoid the software needing to persist elements and the history of the current content. 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 a^d 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 cotnmunicate with a thread external to the main thread of the Renderer. Actor attributes may be read as file references. Attributes axe one of four types: a single siirrple value; a vector of simple values; a single structure of fields, each field having a sitnple 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: When needed as a file, an attribute is accessed via the /attrs folder. An Actor can be messaged by sending it an event with the element. Events emitted by. actors can be delivered to the content tree as content events: these can be targeted at an element Id or 'top7 . 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 B gives an exemplary listing of some actors that may be used, along vith 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. Updates may be triggered by a number of means, which include • the software checking for interrupted Update processing on start-up • the software checking for pre-installed Update Packets on start-up • automatically as configured by an Update Channel • ■ user initiation • the device receiving a special SMS 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 iinpleinentable 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 Appendix C gives an overview of the elements and attributes that provide the desired functionality. It is desirable that the cost of re-branding UIs and producing a continual stream of updates is minimal. This is enabled by providing an efficient flow of information from the creative process through to the transmission of data to users. A containerr 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. Fr&gpcie 4 shows a schematic depiction of the content toolset 2 00, which comprises scripting environment 220, test and simulation environment 23 0 and maintenance environment 240 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 Apre-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. Marv different UIs can be derived from a common base. "yrri-allv tie 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. ^r^fe-ig ^r/- is not derived from ~^?-—©^fes^—trdrgX-? ox^e—03?—mor-a multiple Trigs derived from a base Trig, a plurality of triglets derived from any of the trigs and a plurality of trigiets derived from other triglets. Figure 5 shows a schematic depiction of a device 80 0 -that comprises a user interface according to an embodiment of the present invention. The device comprises .a display 810 that displays the user interface 815 and user interface means 820, that enable the user to interact with the user interface 815. A processor 830 executes the software that is stored within one or more storage means 840 and there may be provided one-or more wireless coinraunication interfaces 85 0, to enable 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 to receive electrical power and/or communication cables. 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 urusic 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, stetrhat 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 exarrrple second generation digital mobile telephone networks (i.e. GSM, D-AMPS) , so-called 2.5G networks (i.e. GPRS, HSCSD, EDGE), third generation WCDMft. or CDMk-2 00 0 networks and improvements to and derivatives of these and similar networks. Within buildings and campuses other technologies such as 31uetooth, IrDa or wireless LANs (whether based on radio or optical systems) may also be used. USB and/or PireWire connectivity may be supplied for data synchronisation with other devices and/or for battery . 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, nonvolatile memory cards, etc. This application claims the benefit of UK Patent Application —amber 0402709.9, filed February 19th 2 0 04, the contents of which are incorporated herein by reference.

Documents:

3419-CHENP-2006 CORRESPONDENCE OTHERS 12-08-2011.pdf

3419-CHENP-2006 AMENDED CLAIMS 11-07-2012.pdf

3419-CHENP-2006 CORRESPONDENCE OTHERS 30-07-2012.pdf

3419-CHENP-2006 EXAMINATION REPORT REPLY RECEIVED 11-07-2012.pdf

3419-CHENP-2006 FORM-3 11-07-2012.pdf

3419-CHENP-2006 OTHER PATENT DOCUMENT 11-07-2012.pdf

3419-CHENP-2006 POWER OF ATTORNEY 11-07-2012.pdf

3419-chenp-2006-abstract.pdf

3419-chenp-2006-claims.pdf

3419-chenp-2006-correspondnece-others.pdf

3419-chenp-2006-description(complete).pdf

3419-chenp-2006-drawings.pdf

3419-chenp-2006-form 1.pdf

3419-chenp-2006-form 3.pdf

3419-chenp-2006-form 5.pdf

3419-chenp-2006-pct.pdf