GB2424546A - Scheduling transfer of data content to a mobile telephone - Google Patents

Abstract

A remote server communicates content to a mobile telephone at scheduled intervals over a mobile telecommunications network. A program on the mobile telephone initiates communication with the remote server and handles downloading of any new content to be delivered. The program downloads content to replace or supplement existing content on the mobile telephone. The content, once rendered by the program, defines an output of the mobile telephone, such as a screen display. The content of a mobile telephone is thus defined by a network operator and can be regularly updated and adapted depending on location or other circumstances. The content is preferably in XML format and is encrypted for transfer. The content may have a topic identifier to allow the program to identify if a corresponding topic is already stored on the mobile phone and update it.

Description

DATA CONTENT ON A MOBILE TELEPHONE

FIELD OF THE iNVENTION

The present invention relates to the field of data content stored on a mobile telephone and the communication of the data content to the telephone.

BACKGROUND OF THE iNVENTION

A promising new area for growth within the mobile telephone industry is the delivery of data to handsets in the form of services available alongside, and in addition to, traditional voice communication. The additional services are generally known as mobile data services.

Mobile data services include downloads, such as ring tones and screen savers, games, surfing of the Internet, and up-to-date information on subject areas such as entertainment, sports, news and business as well as practical information such as train times, taxi numbers, restaurants and shops, etc.. All of these types of data and information can be broadly referred to as content.

At present, mobile telephones offer a range of mobile data services through an Internet browser or other "on1ine portal. Often, these data services are provided to the mobile telephone as a diluted version, tailor-made to the limited (as compared to a personal computer, for example) graphical and processing capabilities of a mobile telephone. Nonetheless, a range of mobile data services are delivered to the user in a dynamic environment while the mobile telephone is online.

Since the user must be online in order to receive up-to-date data services, the price of connection to the network is incurred. Via GPRS or 3G the connection charge is accumulated for every kilobyte of data downloaded.. Much of this "data charge" involves paying for the receipt of information, which is not the specific information wanted by the user.

When the telephone is offline, the user is offered a static environment, which was set at the time of manufacture and is hIhardcodedu. It is only through an online connection that a dynamic environment can be created for conventional telephones.

The richness of the user interface offered by online mobile data service is often limited by practical issues such as the time a user would be willing to wait for download of a multimedia filled screen. Thus, the connection speed of the mobile telephone plays an important role in determining the quality of online displays for mobile telephones, at present.

The latest phones, such as Smart phones, offer high definition colour screens, relatively sophisticated operating systems and increasingly powerful processors.

This new breed of Smart phones is capable of realising the opportunities offered by improved network speed and capacity offered by GPRS connection and 2.5, 2.75 and 3 G communication channels. The user experience when accessing mobile data services is still, however, to some extent limited by download times.

Further, conventional telephones only offer a changing, non-static environment when the device is Internet connected. The standard displays are static and defined at manufacture.

SUMMARY OF THE iNVENTION

The present invention aims to overcome the above problems by offering a unique way of receiving content to the mobile telephone and a thus far unknown data format and structure to the content. The way of rendering the content to an output of the mobile telephone, as provided by the present invention, is also believed to be unique to mobile telephones.

The present invention provides a program stored on a mobile telephone. The program is capable of performing the following steps: scheduling intervals to receive content from a network; receiving content from the network at a scheduled interval; storing the received content on a nonvolatile memory of the mobile telephone; and rendering the stored content to an output of the mobile telephone. It also preferably executes various other functions, including launching features of the mobile telephone handset and allowing completion of forms by the user.

The present invention allows virtual "push" of content from the network at scheduled intervals defined by the program. The content pushing is achieved without the need for user input. The content, in this way, can be regularly updated and automatically stored on the memory of the mobile telephone. To the user, the mobile telephone will seem to have changing information available to it, which can be accessed and viewed quickly, without the need, and expense, of going online.

The content can be of any kind, but the program of the present invention is particularly advantageous in the provision of mobile data services and other such data content where updates are likely to be needed.

The prefened output of the content stored in a memory of the mobile telephone is to a graphical user interface, such as the mobile telephone display screen. Since the content is being received from the network and the program may be adapted to render it to the screen of the mobile telephone, the user environment thus rendered can be defined by the content provider and not by the mobile telephone. From a commercial perspective, this allows branding of the mobile telephone's output and, therefore, improved brand awareness by the user. For example, if the content is provided by a network provider, then the content could be in the form of services provided by the network, or information on these services, and will provide an interactive branded environment.

The intervals can be scheduled for times during which the mobile telephone is seldom used. Thus, speed of content provision is assured, since interference with the data transfer because of other uses of the phone is less likely at these times.

In a preferred form of the program of the present invention, the program is capable of identifying individual topics, which form part of the content. Thus, the content provided by the network (or other content provider) to the mobile telephone may be in the form of discrete topics and the topics may each form a separate file.

In another preferred embodiment, the application is capable of receiving a topic from the network, identifying the topic received, identifying a corresponding topic stored on the memory of the mobile telephone and updating the corresponding topic. In this way, as new content is received on the mobile telephone, the program will search the memory of the mobile telephone and update the relevant topic found with a later version received from the network. This update could involve the mere addition of extra information to the topic or the complete replacement of the old version of the topic with the new version received from the iletwork.

The identification of the topics received from the network and the topics stored on the memory of the mobile telephone is preferably achieved by using a topic identifier, which is unique to the topic it is associated with.

In another preferred embodiment, the scheduling, receiving, storing and rendering steps are performed using a separately launchable application. In this way, each major feature/function is separated and can be run individually.

In another preferred form, the program is capable of rendering a topic to an output of the mobile phone, where this rendering step requires the program to be capable of linking associated files of a different type to a file type of the topic when rendering the topic to the output of the mobile telephone. Preferably, the topic file consists of a topic descriptor file, which includes references to the associated files in the descriptor file. This allows the size of the topic file to be minimised, without compromising the potential variety of output offered to the user. For example, the linking step could involve incorporating any form of multimedia file. Preferably, the topic is provided as a mark-up language file, and the step of rendering involves interpreting a mark-up language file. The above- mentioned link files may comprise bitmap (BMP) files, executable files, dynamic link library files (DLL), MBM, GIF, JPG, and/or PNG files.

In a further preferred embodiment, the program is capable of receiving the topic file and associated files and storing the topic file within a content directory and storing the associated files within another directory or a sub-directory of the memory of the mobile telephone.

In a further preferred embodiment, the program is capable of receiving the topic file and the associated files and is further capable of performing the step of ensuring all associated files have been received and only performing the rendering step for the topic after all the associated files have been received. Particularly, the program is adapted to only store the topic file within the content directory and the associated files within the another directory or the sub-directory once all the files associated with the topic have been received. This functionality ensures that all content is complete and the users are not offered only partially updated information or a topic liable to crash.

In a preferred embodiment, the step of ensuring that all associated files have been received involves the program being adapted to read/interpret the topic file to find all associated files.

In a preferred embodiment, the program is capable of rendering a topic to the output in response to a user input. For example, a user navigating through the phone will launch a main application of the program when selecting an option to view the content. The main application is adapted to cause the content to be rendered to the screen of the mobile telephone.

The rendered topic will usually have actions associated with it and the program will preferably be capable of performing an action associated with the rendered topic in response to a user selection of the action. An example of an action would be skipping from one topic to another. - -6-

The program is further preferably adapted to identify an area of volatile memory of the mobile telephone for rendering a current topic and overwriting a previously rendered topic. This allows minimisation of the mobile telephone resources utilised by the program of the present invention by only having a single topic active within the reserved area of volatile memory of the mobile telephone at any one time.

The program of the present invention is further preferably capable of running an application for performing the scheduling step continuously, while the mobile telephone is on. In this way, the scheduling application is always active in the background of a processor of the mobile telephone, thereby ensuring that the content is regularly updated and the intervals are properly scheduled.

The program of the present invention is also capable of rendering bitmaps contained within the topic, storing the bitmap of the topic in a buffer and delivering the buffered bitmap to the output of the mobile telephone. In this way, the rendering of the bitmap is performed "off-screen" and is only delivered to the graphical user interface of the mobile telephone once the topic bitmap is formed. This serves to smoothen out the rendering process.

In another aspect, the present invention provides a mobile telephone having a memory with the above-described program stored on the memory and means for operating the program. The mobile telephone may preferably also comprise means for launching the program and means for running the program on the mobile telephone.

In yet another aspect of the present invention, a method of providing content to a mobile telephone is provided. The method comprises the steps of the mobile telephone communicating with a server at scheduled intervals over a mobile telephone network; and the server, in response to the communication from the mobile telephone, determining whether to send content to the mobile telephone. If the determination is positive, then the method comprises the step of sending the content to the mobile telephone. The method further comprises the step of the mobile telephone storing the sent content on a non-volatile memory of the mobile telephone.

The determining step of the method of the present invention may comprise the steps of comparing the version of the content of the mobile telephone to the content stored on a memory of the server. The method then further includes sending content to the mobile telephone based on the comparison step. In this way, the content stored in the mobile telephone is updated only when necessary at the scheduled intervals.

In yet another prefeffed embodiment of the method of the present invention, the method includes the step of creating a topic by compiling the topic designed on a graphical user interface and storing the topic on a memory of the server. The topic forms part of the content. Thus, the method allows content to be designed at a graphical user interface level, thereby ensuring simple design, and compiling the content into a computer readable language, without the need to design the content in a less intuitive, less visual way, such as a programming language. These topics, which are designed at top level, are then stored on the memory of the server, in a compiled computer lanuage file, for sending to the client.

Preferably, the creating step includes the step of including a unique topic identifier with the topic.

Having set out the present invention above, a preferred embodiment of the present invention will now be described.

DETAILED DESCRIPTION OF THE INVENTION

The system disclosed herein consists of a server and a mobile telephone communicating (over the air) via a network. The mobile telephone is programmed to log into the server at scheduled intervals in order to obtain content from the server. The content can be an update of content already contained in the memory of the mobile telephone or can be entirely new content. Example content to which the present invention pertains is data relating to the provision of mobile data services.

As described above, mobile data services encompass sport, news and business updates or information on local entertainment, music information, information on local restaurants, taxi services, or train timetables or even shopping facilities, and the like, as well as media items such as pictures, video, ringtones, sound files in various formats including WAY and MP3, and further applications.

The data services can be analogous to what one would expect to be able to obtain from the World Wide Web over a wired connection.

The content to which the present invention is concerned also extends further than content usually associated with mobile data services. The present invention also envisages the provision of content to the mobile telephone, which is specific to the current state of the network. For example, advertising content could be updated by the server depending on the location of the mobile telephone. Also, the current network provider could provide content concerning information about the services offered by the network. To be more specific, the content could be in the form of help information about the network service provider. It is important to appreciate that the content to which the present invention is concerned can be of any type.

Importantly, the content is transferred from a server device over the air to the mobile telephone.

Preferably, the content is designed remotely on a PC terminal, or the like.

The PC will include content editor software including compilation software to convert the graphical form of the content into a computer readable language. The computer readable language is one that the mobile telephone is programmed to interpret and is able to output. The present invention particularly envisages the use of a content editor, upon which the components of the screen are put together and can be viewed as they would be viewed by the user of the mobile telephone.

The content referred to in the present invention consists of a plurality of topics. A topic is designed separately on the content editor and saved under separate files. Each new topic designed on the content editor is then sent to the server for storing on the memory, or, if the content editor is a terminal of the server, is saved directly. Each topic file should be provided with a unique identifier. The topics are, generally, sent to the telephone one at a time and loaded from permanent storage and rendered to the screen one at a time.

The topics are, preferably, each provided with a topic identifier unique to a given topic. The content editor should provide the topics with their ID. The IDs are used to identify the topics in the memory of the telephone and equivalent topics in the memory of the server for the purposes of providing new content.

At any given time, the client may have one version of the content on its memory, and the server, because of modifications to its existing content by a content editor or because of new topics being added by a content editor, may have a different version of the content. The mobile telephone is programmed to check-in with the server every so often in order to obtain new files or updates related to new parts or the updated part of the content on the server.

The mobile telephone is also programmed to interpret the content data stored on its memory and to display the content on its graphical user interface. Typically, a user will scroll through the phone's menus and select an option associated with the content. For example, the user may select to enter the mobile data services option on the phone. This content is provided by the program of the present invention, and an application will be launched to interrogate the memory of the telephone and render the content associated with mobile data services onto the screen.

The phone is not required to enter into any form of Internet connection while displaying content, since the mobile data services content is already stored on the mobile telephone. Thus, in contrast to conventional provision of mobile data services, the receipt of content and display of content are, usually, performed at separate times. Further, the transfer from the mobile telephone's normal menus to a mobile data services option rendered by the program of the present invention is seamless. The user will not be aware of having to launch any separate applications and the telephone will not need to connect to the Internet as in conventional telephones.

After rendering of the content, the user may be, for example, confronted with a screen having an array of media rich options to select, all of which relate to a different aspect of mobile data services, again simply used as an example. The content will be up-to-date information, but does not require the telephone to be online at that time in order for it to be viewed. This means that the mobile phone's processing capabilities can be used entirely for rendering of the content to the screen.

The content may be written in a mark-up language, such as extended markup languange (XML), and each screen may define pictures, actions, bitmaps, splash screens, buttons, text boxes, scroll bars, form fields and the like to offer the user a rich dynamic environment of PC like quality, without irritating download times.

While the information content itself is provided offline, there may be actions associated with topics which require Internet connection and these can be seamlessly integrated into the offline content in the conventional way. For example, the user could be reviewing inforrnaion on the latest music news and decide to download a ringtone for a particular song mentioned in the music news. This action would involve a conventional Internet connection and online time. Finding the file did not, however, need an Internet connection.

Other actions can be associated with the content rendered on the screen, for example the user could skip from topic to topic, e. g. from news to sports, could start a browser with a specific URL, could jump to another page within the current topic, all of which are provided within an integrated framework of the mobile telephone allowing all the usual functions, such as receiving and making telephone calls, or SMSs.

The aspects of the preferred embodiments of the present invention will now be described more specifically.

The architecture of the software of the present invention consists of a series of applications, as described below, with each major feature or function of the software being associated with a separate application. The applications may be separately launchable and in the form of a dynamic link library file or an independent executable file. The software should comprise the following major applications: a core application, a downloader, a scheduler and a content interpretation application.

The data structure of the installed program will have a root folder, called the program root folder in the following, where the executable or DLL files for the various applications of the software are stored. The root directory or folder may also include a "data" sub-directory, within which the content will be stored. This data folder could be separated into a folder for all the content description files and a sub-folder for any associated files.

The content description files will be the files used to describe to the interpreter how the files should be output The content description files are preferably mark-up language files, and may be, in particular, extended mark-up language (XML) files. The associated data files can be bitmaps, for example, or other image file formats, such as jpg files, as one other example.

The program's root directory may also include a temporary storage folder, e. g. called "temp", for placement of all content files being downloaded over the network, which have not yet been fully downloaded. Once the download has been confirmed to have been successful, they are moved to the appropriate location, e. g.

all associated files, such as bitmaps, being placed in the associated file directory and the content description files, e. g. an XML file, being stored in the content directory.

The software of the present invention can be installed onto the phone at the point of sale, by the manufacturer or installed by the user via WAP/Internet download, Bluetooth, infrared or SD card. The content can also be installed when the software is installed, or it can be downloaded to the telephone at a later stage using the update application. The file structure will also usually be created upon installation of the software. The installation will include the provision of the supporting executables and the core application as well as the interpreter of the content descriptor files, and the setup.ini file (if this is needed dependent upon the platform of the device).

The software of the present invention is required to schedule intervals for connecting to a server in order to receive new content. The software is also required to store this content in the appropriate location on the telephone's memory and to load and render this content to an output of the mobile telephone, e. g. the graphical user interface, preferably in response to a user selecting to view this content. The software should also be allowed to communicate with the server using an appropriate protocol. Each of these functions of the software is handled with a separate application in the preferred embodiment of the present invention.

The important applications of the software of the present invention are described in detail below.

The core application is at the centre of most of the software's key functions.

The core application functions to store the data according to the abovedescribed data structure, with the XML files and associated data files stored in the appropriate - -13- directories. The core application also performs the rendering of the content onto the screen of the mobile telephone and handles interaction with the user, such as navigation through the various components of the content and cariying out any action files associated with the content that the user selects.

In contrast to how mobile telephone screens were defined in the past, the output to a graphical user interface of the content according to the present invention is not necessarily hard-coded. The core application creates a user interface at run time, using an interpreter and the content description files, e. g. an XtvIL parser and XML files.

XML files are the preferred file format for the content files as it allows the flexibility to create and adapt the content files and also allows the creation of advanced graphical user interfaces. Generally speaking, the preferred content files of the present invention are made up of XML files and associated files, such as image files. The associated files will comprise all files referred to in the XML file, as interpreted by the X1\41L parser.

The core application will determine that a user has selected to view some of the content and will locate the appropriate XML file. This XML file will be parsed by the XML parser under the instruction of the core application and the associated files, such as bitmaps, defined within the XML file will be retrieved. In this way, the objects defined by the XML file are created and rendered to the screen for viewing by the user.

Preferably, the XML files are parsed in a sequential manner such that only a single active page is created and stored in the telephone's volatile memory at one time.

The core application may make use of a buffered memory in order to create a bitmap of the display off-screen and then render the offscreen bitmap to the screen.

- 14 - This so-called Z-buffering is useful to smoothen the rendering of objects onto the screen.

All forms of user interaction for the mobile telephone should be compatible with the core application, whether the user interaction be the first selection to view a particular part of the telephone's content or user interaction within the content already rendered to the screen. Smartphones often have a five way navigation key and two soft keys and may even have touchscreens with stylus input. The core application should support all the user input methods of the mobile telephone device.

The interpreter, e. g. an XML parser, is preferably an external interpreter.

This external parser can be one already included with the operating system of the particular mobile telephone or else one is provided to the mobile telephone, for example by porting an Open Source XML parser to the device (for example Expat for Symbian, version 7). The software interpreter is used by the core application to aid in the rendering of content to the screen of the mobile telephone.

The present invention makes use of important data stored on the telephone's non-volatile memory. One form of important data is content data, which relates to information intended for a user and which defines an output to a graphical user interface of the device. Another form is data required by the telephone for the proper functioning of the core application and the other applications referred to before as supporting executables. A particularly important file of the second type is the system.ini file (or registry entry) and a content list file.

The system.ini file includes all important settings information for the software. For example, the intervals at which the scheduler should launch the downloader for updating the content, the information required to log onto the server, the files required for launching the core application and other important settings information are all stored here. In an alternative to using a settings.ini file, registry entries could store the information. This will depend upon the platform of the device.

The content list file keeps an updated list of all content descriptor files stored on the telephone. Each content descriptor file will be associated with a unique identifier and the content list file stores an identifier for each content description file stored on the telephone. The list is important as it allows the scheduler application to keep track of the content currently stored and is essential for ease of asking theserver, for each descriptor file, whether there have been updates.

The content referred to by the present invention comprises content descriptor files and associated files. The content descriptor files define the layout of screen objects and any functions performable by activation of the screen objects. The content descriptor files refer to the associated file, which are necessary for completion of an output of the content descriptor files. Preferably, the content descriptor files are XML files, while the associated files used to complete the design of the screen may be supporting bitmap files or other multiple image file formats such as MBM, GIF, JPG, BMP and PNG. Throughout the following description, XIvIL files will be referred to, but it should be appreciated that other forms of content description files, such as mark- up language files could also be used.

The program of the present invention does not have a predefined interface.

The graphical user interface is provided by parsing the XML files and linking-in the associated image files to render the user interface at run time. The parser used in the present invention supports XML files using unicode characters (UTF-16) which allows the display content in different languages.

The mobile telephone's content, used by the program of the present invention, is created, preferably, using a content editor. The content is created within a GUI environment on a PC. The telephone's interface is constructed on the PC, as it would be seen on the target telephone. This screen can be designed using text blocks, pictures, buttons, etc. to create a rich graphical environment as desired.

The content editor then creates an XML file describing the layout and function of each object within the screen/page.

The XML files will usually contain a combination of text and bitmap file references, which are parsed by the core application using the XML parser to render the screen objects on the telephone.

The present invention, therefore, allows the design, communication and display of any information. Thus, the supplier of the information can provide a unique branded environment for the user, which is continually updated and which can be graphically rich to capture the user's attention. Further, this information will be accessed by the user by scrolling through the menus of the telephone to the point where the information is rendered to the screen. The user does not have to wait for a network connection and there is no download time at the point of rendering. Thus, the transfer between normal telephone menus and the dynamic screen of the body program of the present invention is seamless. Furthermore, the content can be tailor-made for individual users based on location and/or the user's responsiveness to certain information.

Each content descriptor file, called topics, will need to be uniquely identifiable in order for the server to be able to locate any updates and for the mobile telephone to identify the topic stored on memory. Although any form of unique identifier may be used, a preferred identifier is a GUID (g_u_i_d), which is generated by windows' GUIDGEN.exe. The content editor always inserts a GUID upon creation of a topic. The GUID is a 128 bit number and is completely unique to that topic. An example would be: "ED6AE6E9-A2F3-40d9-BACC- 11 CEF5BOFEOF" In the preferred embodiment of the present invention, the content stored on the mobile telephone is made up of a plurality of topics. A topic is generally composed of more than one page and has common attributes for each page.

-. -17- Preferably, each topic is defined by one separate XML file, meaning that the content is downloaded to the phone, one topic at a time. The topics usually form natural divisions and separately cover differing subject matter, for example. Using the provision of an updatable help menu on a mobile telephone as an example, the content could be divided into topics such as the main heading menu listing the various subjects upon which help is available and then each of the subjects themselves forming a separate topic. Each of the topics defined in the heading topic would be selectable by a user input causing the separate subject topics to load up the detailed help available in that particular subject.

A particular topic will generally have common attributes such as a background image, topic title, etc. It is possible, however, that these common attributes will be overwritten for any particular page of the topic.

A page is defined as all of the information available to the user on the screen and any further information within the topic can only be accessed by the rendering of a new page to replace it. Any given topic must have at least one page and usually several. A page has attributes such as background image, title, menu, etc. and some of the possible attributes available to a particular page are described below. A page acts as a container for different screen objects usable in the page, such as buttons, text blocks, pictures, etc. The pages of a topic can be defined in any way at the content editor, but usually contain three subcomponents: a header, a menu and a layout.

The header contains parameters directed to the position of the header within the page, the background image and also contains a unique page ID. The first page in a topic may have a page ID of 1, for example.

The menu consists of the options within a page available to the user. The user may be able to select one of numerous options within the page by selecting an object associated with that option from the screen. At the very least, each page will - 18- usually have two softkeys, a left and a right softkey. Each of these softkeys can be set to have a text caption and perform certain actions, such as back to the previous page labelled "back" or exit topic labelled "exit". The text and actions assigned to the telephone softkeys may be changed on a page by page basis or on a topic by topic basis.

The XML file for the page will also define a page layout. The page layout will define the layout of objects embedded within it. For example, a page may contain one or more buttons, text boxes, pictures or other such screen objects defined later. In a specific embodiment, all objects within the page use the top left corner of the pages as the origin. Dependent on the screen layout and the alignment, margin and scalable properties of an object, its coordinate position on the screen will be calculated dynamically.

This dynamic piecewise construction and formatting allows the information defined in an XML file to have a landscape or a portrait layout. Since some devices offer both portrait and landscape screen layouts, it is important that a particular topic can be used in both layouts. The rendering of both of these orientations are supported by the program of the present invention. Each object on a screen may have at least the following three attributes, alignment (left/centre/right), margin (left, right, top, bottom) and scalable (true/false), which are used to position the object on the screen. These attributes are used with reference to the width and height of the screen to position each element at the appropriate place on the screen. The layout is constructed in a left to right, top to bottom fashion.

Full screen objects provided with the above-described at least three attributes, which could include a further wrap (true/false) attribute, will determine the alignment of the object and its scale by reference to the screen of the device. For example, an object is scaled vertically and horizontally in a ratio proportional to the screen height and width, while the alignment (left, centre, right) of the object is maintained and the required minimum margin space between one object to the next is adhered to. Margins may be useful when objects need to be wrapped next to each 19 - other. Alternatively, a wrapping attribute could be defined, which if enabled, aligns objects next to each other within the page dimensions. If enabled, the page dimensions are checked for space to the right of a preceding object, and if so, the object is positioned in appropriate relation to the right of that preceding object.

If the page size is bigger than the screen size, scrolling may be implemented within the page. Scrolling can be vertical, horizontal, or both. Menu bars and title bars are not scrolled along with the rest of the page, but all objects within the page are.

The XML file for a particular topic should define all attributes necessary to render to the screen a working display. The XML file should define each page within the topic and all of the information to be displayed by that page. These pages are intended to be user interactive and the result of a user action should be defined by the XML files. All of the pictures, background images, text boxes, input boxes and softkeys should be defined in the XML file. Examples of user actions compatible with an outputted XML file are as follows.

1. Exiting of the core application.

2. Rendering of a new topic (for example a user selecting the new topic by clicking on an appropriate button within the currently displayed screen).

3. Jumping to a different page within the current topic (for example the user clicking on a tab bar pointing to respective pages within the current topic).

4. Jumping to a specific page in a different topic.

5. Making a voice call to a telephone number defined by an object on the screen.

6. Launching another application of the device (e. g. camera, messaging applications, etc.).

7. Starting the handset's Internet browser with a URL defined button object on the screen.

8. Installing other applications associated with an object on the screen, using the handset's default installer.

- 20 - 9. Performing multiples of the above actions after a single user input.

10. Checking for the existence of a file.

11. Performing an IF, ELSE action sequence.

12. Running another executable file associated with a button on the screen.

13. Jumping to the current topic's homepage (as defined in the XML document).

14. Starting the browser with a specified URL address.

15. Copying a file from source to destination.

16. Playing amediafile(e. g. sound, video, etc.).

The above actions can be associated with numerous types of screen objects.

For example, a button, a softkey, a picture link or a text link.

Buttons are a screen object which perform the associated action when clicked or otherwise selected. The selection can be made using the telephone's joystick, or other navigation tool. Buttons may have two similar sized bitmaps, one for an unselected state and another for a selected state. Buttons can use all the image file formats supported by the software of the present invention. The buttons can be placed anywhere on the page and a page can have numerous buttons, normally up to a maximum of 16. The first button in a page may be set to be in the selected state by default. The selected state and unselected state should be different in some way, for example by expanding the button in the selected state or by highlighting its perimeter.

A picture link can be any type of picture supported by the program of the present invention, but it has an action associated with it. A text link, on the other hand, would be a text object with an action associated with it.

Other objects which may be defined within a given XML file are label objects, which allow a single line of text to be displayed, text box, which allows a -. -21- series of lines of text to be displayed, a rich text box, an input box, and other types of objects which may be useful in rendering a full display screen.

The textbox usually wraps the text in the box to the next line in order to fit within the text box. The rich textbox allows colour, bold, italic, underline, fonts, new line, tab, embedded text and image links to be supported within the text formatting. The user can scroll through text boxes, and scroll bars on the screen using the navigation tool provided by the telephone, such as ajoystick.

An input box provides means for the user to enter text or numerical information on the screen. An input box stores the value entered by the user in the memory. The user input boxes, navigation tools and softkeys allow a fully interactive user experience to be realised on the mobile telephone.

New or updated content is fed to the telephone over the air at predetermined intervals. These intervals are defined by a scheduler application and the downloading of the update content is controlled by a downloader application.

The downloader and scheduler applications are under the overall control of an update application. Content delivery to the mobile telephone is implemented using the update application. The content can be anything from XML files to image files to Binary files. The update application transfers data over the air to or from the mobile telephone using one of the telephone's data connections (for example GPRS).

The content is delivered to the mobile telephone using a "virtual push" method. While the server, in a preferred form, does not push the data to the mobile telephone without the mobile telephone first initialising contact, the delivery of content is provided to the telephone without the need for a user input and is, in this way, virtually pushed to the telephone. In fact, the delivery of content to the mobile telephone could, if desired, be provided without the user being informed of the existence of new or updated content at all.

- 22 - The downloader deals with the technical steps of the actual transfer of information from the server to the mobile telephone and vice versa. The below operations are performed by the downloader: establishing a network connection, implementing the server mobile telephone data push protocol, handling downloading of files, handling action types, alert message production and disconnection from the network.

The downloader application is launched automatically at fixed intervals via the scheduler or can be manually launched by the user as an option on a menu created by the software of the present invention from the content. As described above, a settings file (i. e. setup.ini) may be read upon launch of the downloader in order to obtain the server connection details. Alternatively, a registry entry may be read.

As an example of the settings required by the downloader to establish a connection with the server, an Internet access point (lAP) will be needed, an IP address for the server will be needed and the server port number will also be required. If the server details are stored on a settings file, it should be encrypted in order to prevent re-direction of the mobile telephone to a malicious server. Instead of the use of a settings file or registry entry, connection information could be hard - coded into the downloader application.

If no lAP is preset to be used by the downloader, the application should request, on first use, the user to select an lAP the downloader can use to connect to the server. The handle of the lAP should be stored in the settings file (or registry) to be used in the next connection.

If no lAP is set on the mobile telephone, the user should be informed of this and the downloader should exit. If the lAP used to connect is invalid, the user is to be informed of this and requested to select an alternative lAP or else the downloader will exit. -23 -

The downloader is programmed to fetch the mobile telephone's IMEI number and/or the telephone number of the mobile telephone from the appropriate location on the telephone's memory for authenticating the connection with the server.

In order to carry out the download procedure properly, the downloader will also need to fetch information relating to the program's data structure. The downloader also requires knowledge of the file paths where downloaded data should be stored. In particular, the location of the folder for the content description files, e.

g. the XML files, and the associated files folder for the supporting files, such as bitmaps, will be needed. The downloader will also need to know the relevant path for the temporary folder.

Once a connection is established between the server and the mobile telephone, the downloader will communicate with the server using a data push protocol, described below.

The transfer of content between the server and the mobile telephone will now be briefly summarised, but reference should be made to the description of the data push protocol below for a fuller understanding of the data transfer. The downloader reads a list of the content descriptor files, which are usually XML files, currently stored in the appropriate directory of the mobile telephone's memory. The list may also be stored in the content directory. The downloader makes a request to the server for updates on each file in the list sequentially. In doing this, the downloader will parse each XML file referred to in the list in order to request updates for the associated files, which may be referred to in any given XML file. In this way, the server can check for updates for all associated files and all XtvlL files, which in combination form the content stored on the mobile telephone.

In order to ensure against unauthorised interception of the data, the transferred content between the server and the downloader should preferably be encrypted, preferably in the form of a hash algorithm.

- 24 - All files downloaded from the server are first stored in the temporary data folder of the program's directory. It is only once all of the files associated with a particular XTvIIL file being updated are successfully transferred that the files can move to the appropriate content folder. If an XML file is being downloaded, the XML parser can be used to find all files associated with the XML file and it is only once the downloader has confirmed that all of these files have been fully downloaded that they will be transferred to permanent folders. If it is only the associated files which have been downloaded, the downloader will check that all associated files expected are received before transferring the data to permanent data folders. If the operation fails for some reason, the files being downloaded are not transferred to permanent folders. Instead, the incomplete content is deleted from the temporary data folder. This prevents the user being presented with incomplete content. The updating of the files associated with the unsuccessful download will be attempted again at the next connection of the downloader with the server.

As mentioned above, the downloader may also be required to handle certain action types. The server can request that the downloader perform actions such as changing the update frequency settings, changing server details, notifying the user of updates, deleting old content files or launching external applications. The downloader must be responsive to such requests.

The downloader may also provide alert messages to inform the user of content download. The form of these messages could be a displayed dialogue box with or without a link for viewing new data. This alert dialogue box will preferably appear for just a few seconds. A sound alert could be provided, or alternatively the telephone could vibrate. Another possibility is not to notify the user at all of the content downloads. Parameters in the settings file (or registry entry) can be used to define how or whether the user is alerted of updates.

Once all operations are completed, the downloader is programmed to disconnect from the network, releasing the server resources before exiting. In the event that the downloader cannot connect to the server in the first place or does not - -25- receive a response from the server after a fixed time period, the downloader is adapted to cancel all operations and disconnect from the server in order to perform a clear exit.

The scheduler application, which launches the downloader at set intervals, is a relatively simple application. The scheduler has no user interface and is constantly running in the background of the processor of the mobile telephone. The scheduler is separated from other applications, in particular the downloader, as it is running continuously and, therefore, a small memory footprint and a minimised use of other device resources is possible.

The scheduler uses a timer to schedule the update cycle. The scheduler should be loaded on device bootup either by the OS (o_sJ or by another application, so that it is constantly running in the background. The scheduler will read the settings file or a registry entry in order to determine the frequency at which to launch the downloader. The settings file or registry entry may also include an autoconnect flag. This is used to specify whether the downloader is automatically launched by the scheduler or whether the user should be asked first before connection. The downloader is only automatically launched if the status of the autoconnect flag is true.

The server and the mobile telephone preferably communicate with each other by following the data push protocol. This protocol will operate over a TCP/IP connection and consists of a group of messages, each of which encapsulates a specific operation. The protocol governs the behaviour of the handset and server during a download session. According to the protocol, the following basic principles are always applicable: 1. A message consists of two parts. A message header and a message body.

2. A message header is always the same length (11 bytes in the following

example).

3. A message header must precede all messages passed to and returned from the server.

4. The handset always initiates an operation. The server never volunteers an action.

5. All messages passed in the correct sequence to the server will receive a reply.

6. A handset may not send a new message to the server before a reply has been received to an outstanding message.

7. Any messages sent from the mobile telephone while a transaction is still pending will be discarded via the server.

The mobile telephone has a set of operations which, according to the above protocol, can only be initiated by the telephone. The server is required to reply to a message and cannot initiate an operation per Se. The server can, however, dictate the sequence of operations initiated by the telephone by passing instructions to the handset via return codes included in the reply messages. The server returns information about each operation by means of these return codes which could, for example, be in form of a 32 bit integer, which could dictate to the telephone which operation is called next by setting an appropriate return code.

Table A below lists an example set of operations which can be initiated by the mobile telephone. Table B shows an example set of return codes sendable by the server in response to one of the mobile telephone operations.

- 27 -

TABLE A

I Ordinal Description

5000 Initiahses connection and swaps data - cookie, server address, port 5030 Obtain a topic 5050 Obtain a single bitmap tile 5070 On failure called when an operation fails more than n times 5080 Sign off - sent by the handset before it disconnects 5090 Keep Alive - sent by handset to maintain connection 6000 Tells the server which topics it currently subscnbes to 6010 Obtains a new list of topics and settings 6020 Obtains a new topic ID to add to its list 6030 Asks the server which topic it should drop from its list 6040 Obtain timing data - (days of week, frequency, startlend times) 6050 Send value to server

TABLE B

Value (hex) Description

Informational values < 10000 hex 0 The operation was successful - handset is free to call whatever method it likes (probably 5030) 1 Handset's address/port has changed and will be updated 2 New cookie 4 Send topic list to server - handset must immediately do operation 8 Request topic list from server - handset must immediately do operation 6010 Add a topic to the handset's list (do operation 6020) Drop a topic from the handset's list (do operation 6030) Obtain new timing data (do operation 6040) - 28 etc...

Error messages ≥ 10000 hex...

10000 Handset has the latest version of the requested topic 20000 Failed cause unknown 40000 Bad checksum 80000 No topic found 100000 No bitmap found 200000 Server down - try later 400000 Server will now disconnect According to the protocol, the server and the network telephone communicate with each other using discrete messages. Each message will have a header which, in the following example, is 11 bytes long. To identify the message header, the first four bytes will consist of an identifier, for example byte 0 could be ASCII 67, "C", byte 1 could be ASCII 36, "$", byte 2 could be ASCII 82, "R", byte 3 could be ASCII 36, "$" and byte 4 could represent integer 1. Bytes 5 to 8 can be used to contain a 32 bit integer representing the number of bytes included in the body of the following message (including a checksum byte). The final bytes, bytes 9 and 10, contain a 16 bit integer representing the code of the operation (shown in Table A above) in progress.

The message body will contain the information associated with the operation being carried out. The message body will, therefore, vary in length depending upon the operation. A checksum byte is used to terminate the message body.

After establishing a connection with the server, the downloader will first initialise the communication using the initialisation operation 5000 (Table A).

The initialisation message will consist of the following components, with the number of bytes indicated in brackets. For example <address (40)> indicates that the "address" parameter is four bytes long. -29 -

C$R$0<length of body (4)><5000 (2)> <language (1)> <phone type (1)> <cookie (4)> <checksum (1)> The server will then send a reply message including one of the 32 bit long return codes and associated information. For example, the server could reply as follows to indicate that the connection was made to an address/port that is no longer in full current use and that the new address/port containing the message body should be used in future communications.

C$R$0<length of body (4)><5000 (2)> <Operation result (4)><address (4)><port (2)><cookie (4)><checksum (1)> In response to the above message, the downloader should immediately disconnect by sending a sign-off message (5080 from Table A) and connect (5000) via the new address/port given.

The server may return any of the return codes (Table B) to instruct the mobile telephone to perform any of the operations (Table A). Alternatively, the server may not wish to instruct the client in any way, and in which case a zero will be returned in the body of the reply message.

Having initialised the connection and received a reply indicating that the communication can proceed from the server, the downloader can start checking for updates to the content it currently has on its memory. To do this, the downloader will need to retrieve the list of XML files contained in memory. As explained above, the downloader will sequentially traverse each XMIL file listed in the XML file list contained in the program's memory folder. For each XML file, the mobile - 30 - telephone will send a message, including a reference to the operation 5030, for each XML file in the list. An example message would be: C$R$0<length of body (4)><5030 (2)> <argument (4)> <topic GUTD(36)> <checksum (1)> The argument of the above message should be the handset's latest version number of the topic. The topics are uniquely refened to by the client and uniquely identified by way of the topic GUTD associated with each topic.

The server will respond either by sending a new content summary for a specified topic if the server has a newer version in the mobile telephone, or if the handset already has the latest version of the topic, the server will inform the telephone of this. The message from the server containing a content summary for the later version of the topic will be as follows:C$R$0<length of body (4)><5030 (2)> <Operation result (4)> <topic GUID(36)> <version number(4)> <topic total on-disk size - xml + *bmp (4)> <number of bytes in xml_file file name(4)> <xml_file file name> <number of bytes in xml_file file(4)> <xml_file file contents> <number of bytes in signed hash of xml_file content(2)> <signed hash value (2)> <checksum (1)> The mobile telephone will, in this way, receive the updated xml file from the server. If no version of the topic newer than the version already stored on the telephone exists, the following message will be sent: C$R$0<length of body (4)> <5030 (2)> <Operation result (4)> <checksum (1)> The server will transmit to the client in the result portion the return code 10000 (Table B) indicating that the handset has the latest version of the requested topic.

Another possible response from the server to the topic sensed by the telephone is that the topic is no longer supported by the server and cannot be found (Operation result - return 80000) and that the topic should, therefore, be dropped from the handset's list of topics (return code 20).

The downloader will now have the latest version of the XML file stored in the program's temporary folder. The downloader will need to parse the XML file stored in the temporary folder, or if no updated version of the XML file existed, then the XML file stored in the content folder of the mobile telephone will be parsed, to find any associated files referred to in the XML document. For each of these associated files, the downloader is adapted to send a message 5050 to the server with arguments indicating the version number of the file the mobile telephone currently has, or if it does not have an associated file referred to in an XML document, then this should be indicated in the argument. The associated files could be bitmaps, media files, executables or the like. An example message that the handset would send is shown below.

C$R$0<length of body (4)> <5050 (2)> <argument (4)> <topic GUID (36)> <filename length (2)> - 32 - <filename> <checksum (1)> The server will then respond by either sending the file content as shown below or by sending a return code indicating that the mobile telephone already has the latest version.

C$R$0<length of body (4)> <5050 (2)> <Operation result (4)> <number of bytes in file (4)> <actual file content> <number of bytes in signed hash of file (2)> <signed hash value> <checksum (1)> The downloader will repeat this operation for each file referred to in the XML document. The download will not be considered to have been successfully completed by the downloader until an XML document and all associated files have been completely downloaded. It is only then that the files will be transferred from the temporary folder to the permanent content folder.

The downloader will continue to sequentially traverse through the list of topics until every topic in the list has been processed in the same way. The content of the mobile telephone will be fully updated once these operations have been completed.

It is possible that during the course of communicating with the server, the update process could be interrupted (usually as a result of a user action). Instead of disconnecting from the server each time this happens, a message could be sent to the server to keep the connection alive (operation 5090), as shown below. This message will need to be sent at regular intervals, for example every minute, for the server to assume that the connection is still intended to be kept open. The server will usually close the connection after a certain period of inactivity, but this can be prevented by regular keep alive messages.

C$R$0<length of body (4)><5090 (2)> The server may require a list of all the topics to which the mobile telephone currently subscribes. The server can request this by sending a return code 4 in response to a user operation, which is usually, and most conveniently, the initialisation operation 5000. The downloader will receive this message and reply with a list of all GUTDs in the mobile telephone's list of topics. The reply will be constructed as shown below.

C$R$O<length of body (4)><6000 (2)> <operation result (4)> <checksum (1)> The server could then, in response to the list of topics sent by the mobile telephone, dictate the next action which the telephone should do by setting a desired return code (Table B) in the below message.

C$R$0<length of body (4)><6000 (2)> <operation result (4)> <checksum (1)> Another example of the server dictating the operation requested by the mobile telephone would be if there has been a drastic reorganisation to the content at the server end, which requires a complete reorganisation of the content and the settings of the mobile telephone. In this situation, the server will send the mobile telephone a return code 8, in response to the initialisation operation 5000, for example, to which the downloader will send a message to the server requesting operation 6010, which directs the server to send a new list of topics and settings. An example of this message is shown below.

- 34 - C$R$0<length of body (4)><6010 (2)> <argument (4)><checksum (1)> The server will reply to this with the new settings list and the new list of topics, as follows: C$R$O<length of body (4)><60 10 (2)> <operation result (4)> <number of topics included in this message (2)> <interval (2)> <days of the week (1)> <start time (2)> <end time (2)> <guid 1 (36)> <guid 2 (36)> <guid n (36)> <checksum (1)> The downloader will then use this new list of topics for downloading the identified files by operations 5030 and 5050. The new settings will be stored in the settings file or the registry entry for use by the scheduler to determine when the downloader should be launched.

The server could also respond to a downloader operation, which again usually follows on from the initialise connection operation 5000, with a return code 10, which requests to the handset to request a new topic be added, i. e. it requests that the handset replies with an operation 6020 message, as shown below.

C$R$0<length of body (4)><6020 (2)> <argument (4)><checksum (1)> The server will then send the details of the topic to the telephone downloader detailing the new topic. The downloader will then need to send an obtain topic message 5030 and then obtain the associated files with a 5050 message in order to completely download the new topic.

The downloader also includes an operation for the dropping of a topic, which the server requests when it no longer provides a particular topic and needs to tell the handset to remove it from its list. Thus, the handset will send a message as follows, in response to the server sending a return code 20.

C$R$O<length of body (4)><6030 (2)> <argument (4)><checksum (1)> The server responds by identifying the topic to be dropped with a message as shown below.

C$R$0<length of body (4)><6030 (2)> <operation result (4)> <GUID of topic to be dropped (36)> <checksum (1)> The server may also respond to the mobile telephone's initialisation operation 5000, for example, by sending a return code 40 to request to the mobile telephone to send a message requesting new timing data. The handset will send the following.

C$R$0<length of body (4)><6040 (2) <argument (4)><checksum (1)> In this way, the server can have scheduler launch intervals adjusted. As previously mentioned, the times for launching the downloader could be times of low demand for the mobile telephone's network connection and it could specify a particular time of day, a set interval, or particular date of the year.

The server will reply to the operation 6040 message by sending a message specifying how the settings file or registry entry should be adapted, as below.

C$R$0<length of body (4)><6040 (2)> <operation result (4)> <days of the week (1)> <interval (2)> <start time (2)> <end time (2)> <checksum (1)> The settings should be immediately updated and adhered to upon receipt of the server's reply.

If attempts to obtain updated versions of the topics and/or the associated files are unsuccessful a certain number of times, or if any other operation has failed to be completed successfully, the handset will send a message referencing operation 5070, as below.

C$R$0<length of body (4)><5070 (2)> <argument (4)><failed message number (2)><checksum (1)> The argument included in the above message should be a code recognised by the server identifying the reason for the continual failure of the operation. The failed message number will identify the operation that failed.

Once the server and the mobile telephone have completed all the communications for this particular checking, the handset will send a signoff message. In fact, the handset always attempts this operation prior to breaking the connection to the server in order to ensure proper logging off. The handset sends the below message.

C$R$0<length of body (4)><5080 (2)> <argument (4)><checksum (1)> The server will reply as follows.

C$R$0<length of body (4)><5080 (2)> <Operation result (4)> <checksum (1)> The mobile telephone will not reply to this message and the handset may disconnect immediately.

When the mobile telephone is switched on, a boot-up process is entered into, in which a start-up application of the installed program is loaded and run. The start- up application is operable to load up the applications necessary for the software of the present invention to be active within the telephone. For example, upon telephone startup, the scheduler will need to be launched to ensure that the time for updates is monitored.

The content can be updated at the scheduled intervals without the core application having been launched and without the content necessarily having been viewed at any time since the last update. Usually, when the user does wish to view some of the content, a selection will need to be made which will cause the core application to launch.

For example, the user may need to navigate through the telephone's menus to locate an option necessary to launch the core application of the present invention.

For example, the user could navigate through the menu to a special menu and then select an option labelled "current", for example, which would launch the core application and render an opening screen, which could be a splash screen, displaying information defined by an opening topic, for example. This opening screen could list all the various subjects covered by the content stored on the phone presented using picture boxes, for example. The user could then select one of these picture boxes to launch the topic associated with it and to uncover the content under this subject. The information contained in the content could be a network defined help menu, for example, or branded mobile data services covering news, sport, music, entertainment, ring tones, videos, etc. The menu icon which launches the core application of the program of the present invention could be an icon on the desktop of the mobile telephone screen or a text menu as described above. Once the icon is selected by the user navigation tool, the setup.ini file (or the registry entry) is read. The setup.ini file will be used on platforms which do not support registry entries. The data read from the setup.ini file will be the autostart flag parameter (hereinbefore described), the content memory drive name, e. g. C if the content is stored on the telephone's memory or E if the content is installed on a memory card, for example, and also the name of the first XML file to start with, if launched from a menu icon, for example splash.xml.

The core application can also be launched by command-line. In this case, the name of the XML file to start the core application, if launched from a command- line, can also be found in the setup.ini file or registry entry. If the application is launched by a command line, as an argument passed by the one of the supporting executables, the argument should be in the form of a start XML file. If not, it reads the setup.ini file to get the default name of the file to render to the screen upon startup of the core application.

A default blank screen can be defined, which will be rendered to the screen if the core application is unable to find or read the setup.ini file (or registry entry details) or the XML file given in the setup.ini file (or registry entry) cannot be found. One of the softkeys for the default blank screen should be set to exit to ensure the user can return to the normal telephone functions.

Once the opening screen has been loaded, the user can navigate from here through the content stored on the mobile telephone using jump actions to move from topic to topic. Executables can be run, files can be downloaded, web pages can be loaded and other actions can be completed as the user orientates through the various screens. The user is provided with up-todate information, which loads quickly and which does not require Internet connection during the experience offered by the rendered content.

The content can be in the form of summary information with links to web pages or with the full information, with the summaries being updated at the scheduled intervals. Alternatively, the content can provide all the information the user would require, further Internet connection only being required for the downloading of special files, such as MP3 files, video clips or the like.

The content could also be in the form of advertisements being provided to the user with up-to-date products and offers being given in a branded and suitably styled interface.

The content may not necessarily involve the provision of mobile data services at all, and could be instead help information, with up-to-date information on the services offered by a network to which the phone is connected. This information will be designed by and provided by the network.

One of the major advantages of the present invention is the flexibility with which the screens can be tailored to the content provider's requirements and the user's needs. The software of the present invention will be useful where any information provided on the mobile telephone is subject to the possibility of change.

On conventional telephones, the information provided on the telephone's memory is specially selected to ensure that it is not subject to variation. The present invention, on the other hand, allows dynamic information to be included on the mobile telephone, with the advantage of being able to provide updates or supplements or both to this information at regularly scheduled intervals.

Claims (26)

1. A program for a mobile telephone, the program performing the following steps when run on the mobile telephone: scheduling intervals to receive content from a mobile telephone network; receiving content from the network at a scheduled interval; storing the received content on a nonvolatile memory of the mobile telephone; and rendering the stored content to an output of the mobile telephone.

2. The program of claim 1, wherein the stored content is rendered to a graphical user interface of the mobile telephone. I. S * S I * a.

3. The program of claim 1 or 2, performing, when run on the mobile telephone, : : :* the step of: identifying individual topics in the received content. ***

4. The program of claim 3, performing, when run on the mobile telephone, the * es's stepof: receiving at least one topic from the network, identifying the topic received, identifying if a corresponding topic stored on the memory of the mobile telephone exists and updating the content of the mobile telephone.

5. The program of claim 3 or 4, wherein the identification of the topic(s) received from the network and the topic(s) stored on the memory of the mobile telephone is performed by using a topic identifier associated with each topic, the topic identifier being unique to the topic it is associated with.

6. The program of claim 3, 4, or 5, performing, when run on the mobile telephone, the step of: receiving at least one discrete topic, wherein the or each discrete topic forms a separate file.

-. -42-

7. The program of any of claims 3 to 6, wherein the rendering step comprises reading a topic descriptor file and linking and rendering associated files referred to in the topic descriptor file.

8. The program of claim 7, performing, when run on the mobile telephone, the step of: receiving the topic descriptor file and associated files and storing the topic file within a content directory and storing the associated files within another directory or a sub-directory of the memory of the mobile telephone.

9. The program of claim 8, performing, when run on the mobile telephone, the: . stepof: : ensuring all associated files have been received and only performing the rendering or storing step for the topic after all the associated files have been received. . : *I$.

S S

10. The program of claim 8 or 9, performing, when run on the mobile telephone, the step of: only storing the topic file within the content directory and the associated files within the another directory or the sub-directory once all the files associated with the topic have been received.

11. The program of claim 9 or 10, performing, when run on the mobile telephone, the step of: reading the topic descriptor file to find all associated files.

12. The program of any of claims 3 to 11, performing, when run on the mobile telephone, the step of: identifying an area of volatile memory of the mobile telephone, wherein the rendering step comprises rendering a current topic to the area of memory by overwriting a previously rendered topic. -43 -

13. The program of any of claims 3 to 12, wherein the rendering step comprises rendering bitmaps contained within the topic, storing the bitmap of the topic in a buffer and delivering the buffered bitmap to the output of the mobile telephone.

14. The program of any preceding claim, wherein the scheduling, receiving, storing and rendering steps are performed using a respective separately launchable application.

15. The program of any preceding claim, performing, when run on the mobile telephone, the step of: running an application for performing the scheduling step continuously, *. : while the mobile telephone is on. : * : :

16. The program of any preceding claim, wherein the rendering step comprises interpreting a mark-up language file. a.,.

S S a...

17. A mobile telephone having a memory with the program of any preceding *: : :.

claim stored on the memory and means for operating the program.

18. The mobile telephone of claim 17, comprising means for launching the program and means for running the program on the mobile telephone.

19. A method of providing content to a mobile telephone, comprising the steps of: the mobile telephone and a server communicating at scheduled intervals over a mobile telephone network; and the server, in response to the communication from the mobile telephone, determining whether to send content to the mobile telephone; if the determination is positive, then the method comprises the step of sending the content to the mobile telephone; and storing the sent content on a non-volatile memory of the mobile telephone. -44 -

20. The method of claim 19, wherein the determining step comprises the steps of: comparing the version of the content of the mobile telephone to the content stored on a memory of the server; and sending the content to the mobile telephone based on the comparison step.

21. The method of claim 19 or 20, comprising the step of creating a topic by compiling the topic designed on a graphical user interface and storing the topic on a memory of the server. * Uk

22. The method of claim 21, wherein the creating step includes the step of including a unique topic identifier with the topic. * 1*

23. The method of claims 19, 20, 21 or 22, wherein the sending step comprises sending at least one topic to the mobile telephone, wherein said topic is associated with a unique identifier and the content is formed of a plurality of topics.

24. The method of claim 23, wherein the or each topic forms a separate file.

25. The method of claim 23 or 24, comprising the steps of: the mobile telephone receiving a topic from the network; identifying the topic received; identifying if a corresponding topic is stored on the mobile telephone using the unique identifier; and updating the content on the mobile telephone.

26. The method of claim 23, 24 or 25, wherein the step of sending at least one topic comprises sending a topic descriptor file and sending at least one associated file referred to in the descriptor file.