GB2440585A

GB2440585A - Receiving and displaying forecast data on a mobile device

Info

Publication number: GB2440585A
Application number: GB0615141A
Authority: GB
Inventors: Daniel John Eastley
Original assignee: KENNETH MASON PUBLICATIONS Ltd
Current assignee: KENNETH MASON PUBLICATIONS Ltd
Priority date: 2006-07-29
Filing date: 2006-07-29
Publication date: 2008-02-06
Also published as: GB0615141D0

Abstract

An application runs on a mobile device. The application is configured to access a predefined set of graphical data stored on said device. Data is received at the over a network, and the received data is processed by the application to generate an image. The image comprises at least some of the predefined set of graphical data, the received data defining how the predefined graphical data is arranged in the image. One possible application of the invention is the receipt of weather forecast data on for example a mobile phone.

Description

IMAGE GENERATION METHOD

The present invention relates to methods for rendering images on computing devices.

The invention also relates to methods for receiving user input data and to methods for implementing menus within computer applications.

Computers are ubiquitous in modern life. Desktop PCs are now routinely used for a wide variety of tasks both in professional and leisure environments. Many people now make regular use of computers at both home and work. Computers are often networked together so as to allow data to pass between them. For example, many businesses implement a local area network (LAN) to which a plurality of desktop PCs are connected so as to allow communications between the desktop PCs and one or more servers which are also connected to the LAN. In this way the desktop PCs can obtain services provided by the servers. For example, a server may act as a file server storing files which are to be accessed at a plurality of the desktop PCs.

Many computers are now connected to a worldwide network known as the Internet.

By connecting a computer to the Internet a wide range of services are made available.

These services include web-browsing using an appropriate web-browser application, where information available on the "worldwide web" is accessed. The popularity of the Internet has meant that web-browsing now allows users to access to a huge quantity of data which is genuinely useful in a wide range of contexts, both at home and work.

The popularity of the Internet has in recent times seen a move to making Internet services available using mobile devices, in addition to more conventional computing devices such as the desktop PCs described above. For example, mobile telephony devices are now ubiquitous. In addition to allowing conventional telephone communication, and the transmission of text based messages using the Short Message Service (SMS) protocol, many mobile telephony devices allow a user to access the Internet. This is usually achieved using the Wireless Application Protocol (WAP) which provides a set of communications protocols defining how mobile devices should provide access to the Internet.

Although the WAP is often used for communication, from a user's point of view web pages are simply displayed to a user within what appears to be a conventional web browser.

Although satisfactory for some purposes, the use of WA? in this way fails to take into account considerable differences between communication with fixed computers using hard-wired connections and connections with mobile devices over wireless communications links of the type used by mobile telephony devices. In particular such communications links typically provide considerably less bandwidth, and are far more susceptible to breaking down. Data transfer speeds are typically considerably slower where mobile devices of this type are used.

These problems often mean that some webpages are difficult, if not practically impossible to access using a mobile telephony device. The problem is particularly acute for graphically rich webpages, given that webpages including large numbers of graphics are typically larger than webpages comprising solely or mainly text. Given that many users now want to be able to access a wide range of information using mobile telephony devices, these problems are of considerable importance.

It is an object of some embodiments of the present invention to obviate or mitigate at least some of the problems outlined above.

According to the present invention, there is provided, a method and apparatus for generating an image at a client device. The method comprises running an application on the client device, the application being configured to access a predefined set of graphical data stored on the client device. Data is received at the client device over a network, and the received data is processed by the application to generate the image.

The image comprises at least some of the predefined set of graphical data, the received data defining how the predefined graphical data is arranged in the rendered image.

The term image is intended to be construed broadly such that it encompasses anything which can be displayed on a display screen. Thus, the contents of a mobile telephone screen or indeed part of that screen constitute an image in the way in which that term is used in this document.

The term client device is intended to be construed broadly to mean any suitable computing device. Some embodiments of the invention have particular applicability when used with mobile devices such as mobile telephones and Personal Digital Assistants (PDA).

The method provided by the invention allows images to be generated using a combination of data received over a network and a predefined set of graphical data stored on the client device. In this way, the need to transmit graphical data is obviated while allowing the client device to generate an image including graphical data.

The received data may be processed to select graphical data from the predefined set of graphical data for inclusion in the generated image. For example, the predefined set of graphical data may include a plurality of icons and one or more of these icons may be selected based upon the received data.

The received data may comprise a plurality of records, and each of the records may comprise a plurality of fields arranged in a predetermined order. Each field of each record may be processed by the application to determine graphical data to be included in the generated image. The image may take a tabular form. That is, data may be arranged in a plurality of rows, each comprising a plurality of columns. Each row of the image may be represented by one of the records, and each column may be

represented by a field of a respective record.

The data may define a plurality of records in a variety of ways. For example, the data may take the form of a CSV file where each line of the CSV file defines a record, and

each comma separated value defines a field.

The received data may include textual data, and the textual data may be intended for display as part of the image. The application may therefore add such textual data to the generated image. The application may format the textual data appropriately, for example by selecting a font, selecting a font colour, selecting a text size or selecting a

background colour.

The predefined set of graphical data stored on the client device may comprise a single file defining a plurality of predetermined parts, each of the parts representing a discretely displayable image. That is, the client may processes the single file so as to select part of that file to be included within the generated image. Such selection may be carried out on the basis of the received data.

Received data may be stored in a repository. Subsequently, user input may be received and stored data may be retrieved in response to the user input. The retrieved data may be processed to generate an image, the image comprising at least some graphical data from the predefined set of graphical data.

A request to generate an image may be received, and a message may be transmitted over the computer network in response to the input, the received data being received in response to that message.

Some embodiments of the invention are concerned with the generation of image in relation to particular geographic locations. In such embodiments, location data may be transmitted from the client device over a computer network, and received data may be based upon the specific location data. For example, a user may input a geographic location using at least one menu. Alternatively, the location of the client device my be automatically determined using a location system such as one based upon mobile telephony or one based upon the Global Positioning System.

The generated image may represent meteorological information and the meteorological information may be associated with a particular geographic location determined as explained above. The meteorological information may be displayed in a tabular form, indicating meteorological information for a plurality of different dates and times.

A further aspect of the present invention provides a method and apparatus for generating a menu within an application program. The method comprises defining a data file containing data defining at least part of the menu. A first computer program code representing the menu is defined, the first computer program code referencing the data file. The menu is then generated by running the first computer program code.

In this way, details associated with the menu can be stored within the data file meaning that changes to the menu can be implemented without requiring changes to the computer program code.

The menu may comprise a plurality of entries, and each entry may be defined by the data file. Definition of each entry may include a textual description of the entry.

Definition of each entry may include an action to be carried out upon selection of the entry. The action associated with each entry may comprise an associated parameter.

For example, each entry may be associated with a command and a parameter with which that command should be executed. A specified action may be processed so as to determine a function call that should be made. The function call can then be made using the associated parameter. For example computer program code providing an IF.. .THEN. . .ELSE or a switch statement can be provided to determine an action required based upon the action specified within the data file.

The user interface provided by a mobile device such as mobile telephone differs considerably from that provided by a desktop PC or laptop. Specifically, a desktop PC usually provides an accurately controllable pointing device which can be used to control a pointer shown on a display device. Many mobile devices do not provide such an accurately controllable pointing device primarily because considerable physical space is required on the mobile device to provide a touchpad or something similar. Where pointing devices are provided they are often difficult to control, making user interfaces requiring manipulation of the pointing device difficult and frustrating to use.

A further aspect of the present invention provides a method and apparatus for receiving geographical input data. The method comprises displaying a map, reading data indicating an ordered plurality of regions within the map, and receiving input data indicating user input. One of the regions on the map is indicated in response to the user input. The indicated region is selected based upon the ordering of the ordered plurality of regions.

In this way, a user can "scroll" through various regions of a map so as to indicate an area of interest. The user input may be generated using a user input device moveable in a plurality of directions. The user input may specify a direction which determines a direction in which the ordered plurality of regions is processed. Indicating a region may comprise displaying the indicated region in a different colour.

A further aspect of the present invention provides a method for displaying meteorological information at a client device, the method comprising: determining a location of said client device, transmitting said determined location to a server, receiving data from said server, and displaying meteorological information based upon said received data.

It will be appreciated that all aspects of the present invention can be implemented in a number of ways. Specifically, aspects of the invention can be implemented by way of methods, apparatus, systems and suitable computer programs. Such computer programs can be embodied on suitable carrier media. Suitable carrier media include both tangible carrier media (e.g. CD-ROMs, DVDs) as well as non-tangible carrier media such as communication lines.

References are made in this document to "metrological information". This term is intended to be construed broadly so as to cover both weather data and other atmospheric data including, for example, information relating to sea state, times of sunrise and sunset, and times of high and low tides.

Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 is a schematic illustration of a network of computing devices suitable for implementing embodiments of the present invention; Figure 2 is a schematic illustration of components of a mobile telephone shown in Figure 1; Figure 3 is an illustration of the mobile telephone of Figure 2; Figure 4 is a schematic illustration of software components used by the mobile telephone of Figures 2 and 3; Figure 5 is a sequence diagram showing communications between components of Figure 1; Figure 6 is a schematic illustration of an application used in embodiments of the present invention; Figure 7 is a class diagram showing classes using in the application of Figure 6; Figures 8 to 12 are screenshots showing screens configured to be displayed by the mobile telephone of Figures 2 and 3, and to receive user input data; Figures 13 to 16 are screenshots showing weather information accessible using the screens of Figures 8 to 12; Figure 1 7 is a screenshot showing a screen configured to retrieve previously stored information; Figure 18 is a screenshot showing an information screen accessible using the screens of Figures 8 to 12; Figure 19 is a sequence diagram showing communication between classes of Figure 7 to cause display of the screen of Figure 13; Figure 20 is a schematic illustration of a storage process; Figures 21 A and 21 B are flowcharts of a process for generating the screen of Figure 13; Figure 22 is a schematic illustration of an image file used in embodiments of the present invention; Figure 23 is a sequence diagram showing communications between classes of Figure 7 to cause display of screens such as those shown in Figures 14 to 16; Figure 24 is a sequence diagram showing communications between classes of Figures 7 to cause data to be retrieved from storage; Figure 25 is a schematic illustration of components used to implement menus shown in Figures 8,9,11 and 12; Figure 26 is a schematic illustration of components of a server shown in Figure 1; Figure 27 is a screenshot taken from an application configured to run on the desktop computer of Figure 1; Referring to Figure 1, there is illustrated a network of computing devices connected to the Internet 1. It can be seen that the computing devices take a variety of forms and include a server 2 configured to provide services (e.g. data and applications) to other computing devices connected to the Internet 1. Client devices taking the form of a desktop computer 3, a laptop computer 4 a personal digital assistant (PDA) 5 and a mobile telephone 6 are also connected to the Internet I and are configured for communication with the server 2. It will be appreciated that although particular client devices are illustrated in Figure 1, client devices can take any suitable form.

The connection between the client devices and the Internet I can take any suitable form. For example, the mobile telephone 6 and PDA 5 may include modems configured to connect to a server computer (not shown) which in turn provides a connection to the Internet, as is well known in the art. The desktop computer 3 and laptop computer 4 may also connect to the Internet through appropriate modems, or may instead connect to a local area network which in turn is connected to the Internet 1. The server 2 may also connect to the Internet I in any convenient manner, as will be known to one of ordinary skill in the art.

Figure 1 also shows a mobile gateway 7 which is connected to the internet 1. The mobile gateway is configured to communicate with mobile devices such as the mobile telephone 6 using conventional telecommunications protocols. The mobile gateway 7 has a telephone number associated with it, and communications such as short message service (SMS) messages can be directed to the mobile gateway 7 by the mobile telephone 6 specifying the associated telephone number. On receiving such communications the mobile gateway 7 is configured to provide various services, either by carrying out processing itself, or by communicating with other computing devices connected to the Internet I, such as the server 2. The mobile gateway 7 then transmits appropriate data to the mobile telephone 6 by establishing a telecommunications link using a telephone number associated with the mobile telephone 6. In this way, the mobile gateway 7 provides services which are accessible to the mobile telephone 6.

Figure 2 shows various components of the mobile telephone 6. It can be seen that these include a processor 8 which is configured to execute computer program code to provide functionality to a user of the mobile telephone 6. The mobile telephone 6 comprises non-volatile storage 9 configured to store both computer program code and appropriate data. Data can be read from and written to the non-volatile storage 9 by the processor 8. Volatile storage in the form of random access memory (RAM) 10 is also provided, and data can again be read from and written to RAM 10 by the processor 8. In order to communicate with other devices, a transmitter/receiver 11 is provided, providing communications via an antenna (not shown). A modem 12 is configured to encode data prior to transmission using the transmitter/receiver 11 and to decode data after reception by the transmitter/receiver 11. Both the transmitter/receiver 11 and the modem 12 are configured to communicate with the processor 8.

The mobile telephone 6 further comprises user input and output devices, which are shown both in Figure 2 and Figure 3. A keypad 13 comprises twelve alphanumeric keys 14 which operate in a conventional maimer to allow a user to input both numeric and textual data. The keypad 13 further comprises a navigation button 15 configured to receive directional information in one of four directions (up, down, left right) when an appropriate part of the button is pressed. Such directional information can be used to navigate through various menus provided by applications running on the mobile telephone 6. If a central part of the button is pressed, a selection command of a currently highlighted option is triggered. The keypad 13 further comprises two buttons 16, 17 usable respectively to answer and terminate telephone calls. Two buttons 18, 19 are so-called "softkeys", the operation of which is configurable by applications running on the mobile telephone 6. The keypad 13 further comprises a clear button 20.

The mobile telephone 6 further comprises a display device 21. The display device 21, in addition to displaying visual data output by applications running on the mobile telephone 6 displays data indicating configuration of the "softkeys" 18, 19.

Specifically areas 22, 23 respectively display information indicating commands associated with the "sofikeys" 18, 19.

Referring back to Figure 2, it can be seen that the mobile telephone 6 further comprises a microphone 21 configured to receive audio data, for example for transmission during a telephone call, and a speaker 22 configured to output audio data to a user, for example data received during a telephone call.

Although particular components of the mobile telephone 6 have been described with reference to Figures 2 and 3, it will be appreciated that other components may be provided, and that some components may be omitted.

The mobile telephone 6 is configured to run applications providing user services.

Many such applications, including example applications described herein, are written in the Java programming language. The Java programming language is favoured due to its device independence, and also because it provides tools specifically intended for the creation of applications for use on mobile devices. Mobile devices are in general, relatively speaking, resource constrained having limited processing capability and memory. Although specific examples of applications written using the Java programming language are provided, it will be appreciated that the invention is in no way limited to such applications.

Figure 4 shows software components used to run Java applications on the mobile telephone 6. It can be seen that these components include a Java runtime environment (RTE) 24 which is configured to run Java applications defined using one or more class files. In preferred embodiments the RTE is provided by Java 2 Micro Edition (J2ME), an RTE particularly designed for use on mobile devices.

It is preferred that the mobile telephone 6 provides a platform for the running of mobile Java applications in the form of the Mobile Information Device Profile (MIDP). Where the MIDP platform is provided, applications take the form of MIDlets, that is applications intended specifically to take advantage of the MIDP platform. In addition to the RTE 24, the MIDP platform provides an Application Management System (AMS) 25, which manages applications stored on the mobile telephone 6. A Record Management Store (RMS) 26 is also provided to store data for use by applications managed by the AMS 25 which run using the RTE 24.

A process for obtaining an application configured to provide meteorological information and suitable for running on the mobile telephone 6 is now described with reference to Figure 5. First, using the mobile telephone 6, a user transmits an SMS message to the mobile gateway 7 at step SI. The SMS message comprises predetermined text indicating a user's desire to obtain the application, and is transmitted to a telephone number associated with the mobile gateway 7. For example, the message may simply comprise the text "REQUEST WEATHER" indicating the user's requirements. The mobile telephone number is preferably a five digit abbreviated number, making it easier for a user to recall.

On receiving an SMS message of the type described above, the mobile gateway 7 processes the contents of the message and determines a server to which a request should be directed. In this case the request is passed to the server 2 at step S2, the server 2 being configured to provide an application providing meteorological information. The request passed to the server 2 takes the form of a hypertext transfer protocol (HTTP) request, and includes the telephone number of the mobile telephone 6, which was received by the mobile gateway 7 together with the SMS message.

Upon receiving the HTTP request, the server 2 generates a database record associating a unique identifier with the received telephone number of the mobile telephone 6. This unique identifier will be used in subsequent communications, as described below. Having created a database record, the server 2 generates appropriate data for inclusion in a Wireless Application protocol (WAP) encoded push message.

The appropriate data is transmitted from the server 2 to the mobile gateway 7 over the Internet I at step S3. The received data is then encoded as a WAP encoded push message at the mobile gateway 7 and is then transmitted from the mobile gateway 7 to the mobile telephone 6 at step S4 as an SMS message. The transmitted SMS message includes a WAP link which is selectable by a user of the mobile telephone 6 to cause communication with the server 2 over the Internet 1. The WAP link is configured such that the unique identifier associated with the telephone number from which the SMS message of step SI originated is encoded within the link.

When the SMS message transmitted at step S4 is received by the mobile telephone 6, the user selects the link within the SMS message which causes the mobile telephone to make a WAP request to the server 2 over the Internet I at step S5. The request is made to a URL associated with the server 2 and specified within the SMS message, and includes the unique identifier described above. When this request is received by the server 2, the server provides the application to the mobile telephone 6 over the Internet I at step S6. The application is provided as a Java Archive (JAR) file. The provided JAR file comprises a plurality of class files configured to implement the application, and data required by those class files when the application is run. The JAR file is received by the mobile telephone and stored in non-volatile storage, under the control of AMS 25 (Figure 4). The JAR file can subsequently be retrieved from storage and the application can be run using the RTE 24.

It should be noted that the provided JAR file is configured so as to include the unique identifier associated with the mobile telephone 6. The unique identifier is generated in response to the original SMS request message as described above, and is transmitted to the server 2 when the WAP link is selected, by virtue of it being encoded within the link. In this way, each copy of the JAR file which is downloaded is uniquely identified using the unique identifier, and subsequent communications between the application when installed on the mobile telephone 6 and the server 2 use the unique identifier such that the server 2 can identify the source of communications, by using the database mentioned above to retrieve the telephone number originally associated with the unique identifier upon its generation. In this way, there is no need for the mobile telephone number of the mobile telephone 6 to be used as an identifier in subsequent processing.

Figure 6 shows the structure of the downloaded JAR file. It can be seen that the JAR file includes a "IRES/" directory 27 and a "/SRC/" directory 28. The "IRES/" directory 27 stores comma separated value (CSV) files containing configuration data for use by various parts of the application, and images which are used by the application as described below. The "/SRC/" directory 28 stores class files which implement the application. The class files contained within the "/SRC/" directory 28 are shown in Figure 7, together with their relationships to standard classes provided by J2ME. Referring to Figure 7, it can be seen that a ForecastNow class 30 is a subclass of the MIDLET class 31 which is a super class for all midlets, that is applications intended to be run on the MIDP platform. The ForecastNow class 30 is the main class responsible for management of the application. The application is, in operation, multi-threaded, and two provided classes therefore extend a standard THREAD class 32: a Downloader class 33 and a ForecastRenderer class 34. The Downloader class 33 downloads appropriate data required by the application from the server 2 (Figure 1) while the ForecastRenderer class 34 renders meteorological data for display to a user.

Classes are also provided in the JAR file to appropriately format data to be provided to a user. These include an ImageScreen class 35 which is a subclass of a standard CANVAS class 36, and is used to display graphical data. A DocScreen class 37 is a subclass of a standard FORM class 38 and is used to display textual data, while a MenuScreen class 39 is a subclass of a standard LIST class 40 and is used to display menus. Using the standard CANVAS class 36, FORM class 38 and LIST class 40 in this way is advantageous, given that classes having these standard classes as their superclass can inherit methods to correctly format data in a predetermined style. In this way, all applications using these standard classes have a common "look and feel" aiding usability.

Having described how the application is downloaded, and its general structure, its operation as perceived by a user is now described with reference to the screenshots of Figures 8 to 16.

Figure 8 is a screenshot of a main menu provided by an applicationconfigured to display meteorological information. The main menu comprises four entries, a "Get Forecast" entry is selectable to obtain a meteorological forecast, as is described below. A "Saved Forecasts" entry is selectable to retrieve previously obtained forecasts, while "About" and "Help" entries are respectively selectable to obtain information about the application and to obtain user help. If the "Get Forecast" entry is selected, a Forecast menu shown in Figure 9 is displayed.

The menu of Figure 9 allows a type of forecast to be obtained to be selected. In general, a user can either obtain a general forecast in the form of a rainfall radar, satellite image or synoptic chart by selecting appropriate entries as described below, or obtain a forecast tailored to a particular location by choosing a "Select Location" entry. When the "Selection Location" entry is chosen, a map is displayed as shown in Figure IOA. The map of Figure IOA is a map of the United Kingdom.

Obtaining a forecast for a particular location is a hierarchical process, that is one first selects a region using the map of Figure 1 OA, and subsequently specifies more precise location data as described below. Various regions are defined within the map of Figure lOA, with Figure IOA highlighting a region known as The Midlands. A user can "scroll" through various regions by using upper and lower parts of the navigation button 15 (Figure 3). In this way each region within the map is highlighted in turn as shown in Figures 1 OA to I OM. When the region of interest to the user is highlighted, the central portion of the navigation button 15 is selected to cause selection of that region. In the described example the user is interested in obtaining a forecast for a location within the Midlands region, and when the Midlands region highlighted as shown in Figure 1 OA is selected, the central portion of the navigation button 15 is selected.

In this way, a method of specifying a region is provided in which a user can "scroll" through regions using upper and lower parts of the navigation button 15. Such "scrolling" will be familiar to users given its use in text based menus, but it is here used to navigate a graphical representation of data to allow a desired part of that data to be highlighted for selection. Although Figures 1 OA to I OM shown and have been described with reference to regions of land, it will be appreciated that similar techniques can be applied to regions of sea.

When the appropriate region has been selected using the map of Figures IOA to 1OM, a menu shown in Figure II is displayed containing entries which define sub-regions within the selected region. In the illustrated example, these sub-regions take the forms of counties which are within the Midlands region. Again, a user can scroll through the entries within the menu to select a county of interest, and then select the county of interest.

In the described example, a user selects the county "Hereford & Worcester" from the menu of Figure 11. This causes the menu of Figure 12 to be displayed, this menu comprising entries which are locations within the Hereford & Worcester county for which forecasts are available. In this case, these locations each correspond to towns within the Hereford & Worcester county. Again, a user can scroll through entries within the menu of Figure 12, and when an appropriate entry is highlighted cause selection of the location for which a forecast is desired. Upon selection of that location, a forecast is obtained (as described in further detail below) and presented in a form illustrated in Figure 13. in general, it can be seen that the screen of Figure 14 comprises three sections 50, 51, 52 each providing forecast data for a particular day.

By scrolling downwards, further forecast information can be obtained.

Taking the section 50 as an example, it can be seen that this comprises a date line 53 and forecast lines 54. The date line 53 provides a date with which forecast information within a particular section is associated, while each forecast line provides a forecast for a specified time on that day. It can be seen that each line provides a forecast comprising a plurality of information items: a general indication symbol, a temperature, a windspeed, a wind direction denoted by an arrow, a cloud cover indication, a pressure value and a pressure tendency (i.e. whether pressure is forecast to rise or fall). It can be seen that the sections 51, 52 comprise equivalent information for different dates. As will be described below, different information can be provided within the forecasts of the type shown in Figure 13.

Referring back to Figure 9, it can be seen that in addition to the "Select Location" option described above, the Get Forecast menu provides options for selecting different forecast types. Specifically a "Rainfall Radar" option may be selected to cause display of an image as shown in Figure 14, while a "Synoptic Chart" option may be selected to cause display of an image as shown in Figure 15. Similarly a "Satellite image" option may be selected to cause display of a satellite image as shown in Figure 16. It will be appreciated that when selecting these options general forecast information for a predefined area (generally Europe in the illustrated examples) is displayed without requesting particular location data from the user.

Referring back to Figure 8, if the "Saved Forecasts" option is selected, a list of previously requested forecasts is displayed as shown in Figure 17. Selection of a location entry from the list of previously requested forecasts results in the generation and display of a forecast of the type shown in Figure 13 using stored data. The generation of such a forecast from stored data is described in further detail below.

Selection of an entry such as "Satellite Image", "Synoptic Chart", or "Rainfall Radar" will result in the display of an image of the type shown in a respective one of Figures 14 to 16, using stored image data.

Referring again to Figure 8, if the "About" option is selected, general information about the application is displayed, as shown in Figure 18.

Having described operation of an application for presenting meteorological information in general terms, the implementation of the application is now described in further detail, particularly focusing upon. the way in which the application retrieves data from the server 2 (Figure 1) and processes that data so as to present a forecast of the type shown in Figure 13.

Referring first to Figure 19 objects being instances of classes shown in Figure 7 are illustrated and their interactions are shown. Processing is initiated by a user choosing to launch the ForecastNow application at step S7 resulting in a ForecastNow object 60 being instantiated, that object being a instance of the ForecastNow class 30 shown in Figure 7. As described above, the ForecastNow object 60 allows a user to navigate through the various menus described above so as to request a meteorological forecast which is required. When a user specifies a location with appropriate specificity by, for example, selecting one of the towns shown in Figure 12, various processing is carried out so as to generate a meteorological forecast of the type shown in Figure 13. First, upon selection of a particular location, the ForecastNow object 60 creates a Downloader object 61 which is an instance of the Downloader class 33. This Downloader object 61 is used to obtain data required to generate to the meteorological forecast. At step S8 the ForecastNow object 60 provides to the Downloader object 61 a URL from which appropriate data can be downloaded. This URL can take the form: http://servername/inland?lid=l00. That is, the URL specifies a particular server from which data should be downloaded and then specifies a query string which is to be processed by that server. In the example URL the query specifies that a forecast is requested for a inland location Id of "100". That is, each of the locations included within the menu of Figure 12 has a numeric location identifier associated with it and this location identifier is transmitted to the server to specify the location for which a meteorological forecast is required.

Upon receiving a URL of the type described above at step S8 the Downloader object 61 then communicates with the server 2 (Figure 1) over the Internet 1. This communication can suitably make use of the WAP. The Downloader object 61 then waits to receive appropriate data from the server 2. As indicated above, in order to allow the server 2 to identify the mobile telephone 6, the unique identifier associated with the mobile telephone 6 and stored by the application is transmitted to the server 2 along with the request.

In addition to instantiating the downloader object 61, the ForecastNow object 60 additionally instantiates a Status object 62 at step S9. This is an instance of a Status class which again has the THREAD class 32 (Figure 7) as its superclass. Thus, while data is being downloaded both the Downloader object 61 and the Status object 62 run concurrently, the Status object 62 providing status information to the user. When the Downloader object 61 receives the requested data from the server 2 the ForecastNow object 60 is informed accordingly at step Sb.

The Downloader object 61 passes data received from the server 2 to the ForecastNow object 60 at step SW. This data takes the form of a CSV file defining a meteorological forecast as is described in further detail below. The Downloader object 61 receives this CSV file as a byte array and it is passed to the ForecastNow object 60 in this form.

Upon receiving the byte array representing the CSV file, the ForecastNow object 60 first stores the received data within the RMS 26 described above at steps SI I as is now described. Before storing the received data in the RMS, processing of the type shown in Figure 20 is carried out. Specifically, a byte array 63 received by the ForecastNow object 60 is associated with information identifying a location to which the forecast relates. Specifically, the byte array 63 will have been received by the downloader object 61 in response to a request for a forecast relating to a specific location. Thus, the ForecastNow object 60 generates a byte array output stream 64 including a location name specified as a string, an integer location identifier and the received byte array. That is, the ForecastNow object 60 "wraps" the received byte array together with the string and integer data described above so as to create a byte array output stream. The creation of the byte array output stream 64 can be conveniently achieved by creating a byte array output stream object and using appropriate method calls to add data to the byte array output stream object such as writelnt() and writeStringO.

Having created the byte array output stream 64, this can be written to the RMS 26 using methods provided by the RMS. Specifically, a method RMS.write(BOS.getBytes ) is used, where BOS is the byte array output stream 64 generated by the ForecastNow object 60. The getBytes() method is a standard method associated with byte array output stream objects which results in bytes being obtained from such a stream. It is this form of data which is expected by the RMS.write() method. Thus, using the processing described above the ForecastNow object 60 is able to combine the CSV file obtained from the server 2 with appropriate location identifiing data to generate a byte array output stream suitable for writing to the RMS 26 using standard methods.

It should be noted that received location data is written to the RMS 26 so as to be retrievable in future if the same forecast is again required. The retrieval of data from the RMS 26 is described in further detail below.

Referring back to Figure 19, in the present case, it is desired to generate a meteorological forecast and the required data is already held by the ForecastNow object 60 given that it has been received from the downloader object 61. The received CSV data is now passed by the ForecastNow object 60 to a Rendererlhread object 65 at step SI 2. The RendererThread object 65 is an instance of the ForecastRenderer class 34 (Figure 7). The RendererThread object 65 processes the CSV data in a manner described below so as to generate an image which can be displayed on a display of the mobile telephone 6. The rendering process is described in further detail below, although it is to be noted that rendered image data is passed from the RendererThread object 65 to the ForecastNow object 60 at step S13.

It will be appreciated that the rendering carried out by the RendererThread object 65 may take sometime (of the order of a few seconds) and during this time it is desirable to display a status screen indicating that rendering operations are currently taking place. Thus, in addition to providing CSV data to the Rendererlhread object 65 at step SI 2, the ForecastNow object 60 additionally instantiates a Status object 66 at step S14, the Status object 66 being configured to display such status information.

Upon receiving the image data generated by the RendererThread object 65 and transmitted to the ForecastNow object 60 at step SI 3, the ForecasiNow object 60 instantiates an ImageScreen object 67 at step SI 5. This involves providing appropriate image data to the ImageScreen object 67 so as to allow appropriate forecast data to be displayed. It is to be noted that the ImageScreen object 67 is an instance of the ImageScreen class 35 (Figure 7) described above.

The description presented with reference to Figures 19 and 20 has explained, in general terms, how data is passed between various objects to allow a forecast of the type shown in Figure 13 to be generated and displayed. Further detail of operation of the RendererThread object 65 upon receipt of an appropriate CSV file is now described with reference to Figures 21 A and 21 B. Referring again to Figure 13 it can be observed that the displayed forecast essentially comprises data arranged in a plurality of lines, the lines being of one of two types: either a line displaying date information (e.g. the line 53) or a line displaying forecast information (e.g. one of the lines 54). This structure is mirrored in the CSV file as shown in the fragment below, which is an extract from a CSV file usable by the RendererThread object 65.

#DE, Tue 18 Jul #FE, 1500, 1, 33, 6,E, 0,1020, -2, #FE, 1800, 1, 31, 8,SE, 0, 1019, -1, #FE, 2100, 0, 24, 7,E, 0,1020, 0, #DE, Wed l9JuI #FE, 0, 0, 20, 7,E, 0, 1019, -1, #FE, 300, 0, 18, 7,E, 0, 1019, -1, #FE, 600, 1, 19, 6,E, 0, 1018, -1, #FE, 900, 1, 26, 7,E, 0, 1017, -1, #FE, 1200, 1, 32, 8,E, 0,1016, -2, #FE, 1500, 1, 37, 10,SE, 0, 1015, -1, #FE, 1800, 1, 33, bE, 0, 1014, -1, #FE, 2100, 0, 26. 9,E, 5,1014, 2, It can be seen that the CSV file represented by table I comprises some lines prefixed by "#DE" and some lines prefixed by "#FE". Lines of the CSV file prefixed with "#DE" represent date lines, while lines of the CSV tile prefixed with "#FE" represent forecast information. Each line prefixed by "#DE" comprises one other field being a date. Each line prefixed by "#FE" comprises eight other fields, each corresponding to one of the columns shown in Figure 13.

It should be noted that the image of Figure 13 is generated using various prestored graphical data. Such data is defined by an image file. This image file has a form illustrated in Figure 22. Specifically, it can be seen that the image file 70 is divided in to twelve regions shown by broken lines. Each of the regions of the image 70 define a distinct image in terms of the forecast to be rendered. The image 70 is provided as part of the application's JAR file shown in Figure 6, and is specifically included within the "/RES/" directory, as shown in Figure 6. Where the invention is implemented for use on J2ME, the image file is a Portable Network Graphics (PNG) file.

Referring now to Figure 21 A, at step S20, an image file of the type described above with reference to Figure 22 is loaded into a standard Java Image object. That is, an Image object called mylmage is instantiated using the method call mylmage.createlmage("/RES/image-file.png"). This Image object will be used to generate the image of Figure 13 as is described in further detail below.

At step S21a an array of column widths is created. That is, the maximum width of each of the columns shown in Figure 13 is calculated. This process involves determining the maximum number of characters which can be included in a particular colunm and multiplying this by the width of the widest character. For example, considering a pressure column 55 of the image of Figure 13, it can be seen that this column stores textual data comprising four numeric digits followed by "mb". Thus, the maximum character width is multiplied by four and the width of the characters "mb" is added to the calculated value. This calculation is necessary because fonts and font sizes may differ between mobile devices. Where columns show graphical data, such as the general descriptor symbol column 56, column width data can be pre-stored and no computation is required at step S2 I a.

At step S21b an array of column indents is created. That is, the x coordinate of the left hand edge of each column is calculated using the column widths determined at step S21a in combination with the predefined column widths for columns showing graphical data. Referring to Figure 13 it can be seen that the indent for the column showing time 57 will be zero while the indent for the column showing the general descriptor symbol 56 will be the width of the column showing time and so on.

At step S22 the CSV file described above is obtained and split into its constituent rows, based on a new line character ("\n"). This determines how many rows are held within the CSV file, and this number is referred to as N. At step S23 an off screen Image object is created which is to store the generated image. This image has dimensions which are calculated. The width of the image is calculated to be the indent of the final column of the image added to the width of that final column. The height of the image is computed to be the number of rows multiplied by the font height for the font being used on a particular device. Some padding for each row is also added to the height calculation.

Having created an appropriate image object at step S23, a standard Java Graphics object is retrieved from the Image object of step S23 at step S24. This standard graphics object is used to obtain drawing functions.

From step S24, processing moves to step S25 where column headings 58 are printed.

At step S25a a background is created by setting the background colour using the Graphics.setColor method with an appropriate parameter. A rectangle is drawn with dimensions being row height, and entire image width.

Processing then passes to step S25b where a contrasting colour is set and using the column indents calculated at step S21b, appropriate text is drawn using the Graphics.drawText method. It should be noted that column headings are centred within their respective column by appending half of the column width to the calculated indent and then setting the alignment parameter of the Graphics.drawText method to Graphics.Hcenter, meaning that the heading text will be centred upon the centre of the desired column.

Processing then passes to step S26 where the CSV file described above is processed so as to generate the remainder of the image of Figure 13. This processes is described below with reference to Figure 21B. When the processing of step S26 is complete, processing passes to step S27 where the rendered image is displayed.

Referring to Figure 21B, at step S28 an oddRow variable is set to true. The function of this variable is discussed below. A first row of the CSV file is then obtained. An array containing the contents of the CSV file is then initialised at step S29a. It should be noted that each row of the CSV file is split into array elements using comma separation. Where the invention is implemented using J2ME, the String.split method is not supported, and therefore a bespoke implementation will be required. Having generated an array at step S29a, a counter variable i is initialised at step S29b and the element of the array at index i is read at step S30a before the counter variable is incremented at step S30b.

At step S3 1 a check is carried out to determine whether a currently processed line of the CSV file is a date line or a forecast line. This determination is based upon whether the element of the array at index zero is set to "#DE" or "#FE" as discussed above. If the check at step S3 I determines that the processed line represents a date, processing passes to step S32 where an appropriate date line is generated to be included within the rendered image. At step S32a, a background for the date line is printed while at step S32b the text of the date line is printed. At step S32c the oddRow parameter is set to false (the purpose of which is discussed below) while at step S32d the next line of the CSV file is obtained. Processing then returns to step S29a. In general terms, the generation of a date line at step S32 involves reading data from the CSV file representing the date and processing it into a predetermined date format.

If the check of step S3 I determines that the currently processed line is a forecast line, processing passes from step S3 I to step S33a. The element of the array at index i is read at step S33a. At step S33b, a background colour for the forecast line being processed is set. It can be seen from, for example, the area 51 of Figure 13 that the forecast lines have alternating background colours so as to aid ledgeability. This alternating background colour effect is achieved using the oddRow parameter discussed above. That is, step S33b determines whether the oddRow parameter is set to true or false and based upon this determination determines the background colour.

On the basis of the processing of Figure 21B as a whole it will be appreciated that the oddRow variable will alternate between true and false for successive rows that are processed, so as to obtain the alternating background colour effect.

Having read an element from the array, a determination is made (based upon the array index) as to how the array element should be processed. In general terms, this processing can involve adding text or an image to the rendered image. This check is carried out at step S34a. If it is determined that text is to be added, processing passes from step S34a to step S34b. Here a determination is made as to whether the currently processed entry is a temperature entry. This is because temperature entries are processed differently, in that each temperature has associated with it a background colour indicative of temperature. That is, while very hot temperatures may be accompanied by a red background very cold temperatures may be accompanied by a blue background and so on. If the processed entry is a temperature entry processing passes from step S34b to step S34c where the temperature value is read, and based upon the read temperature value the background colour is set at step S34d, and appropriate rectangle is drawn at step S34e.

If the check of step S34b determines that the entry being processed is not a temperature entry processing passes directly to step S35. Similarly, processing passes from step S34e to step S35. Here, appropriate text is generated at step S35 and added to the rendered image. Adding text to the image again involves determining appropriate column indents so as to determine coordinates at which the text should be placed. Text is again placed centrally using the method described above. Having generated and formatted appropriate text and added this to the rendered image at step S35, processing then passes to step S36a where the counter variable i is incremented.

At step S36b the oddRow value is set to an appropriate value. That is, it is set to its logical inverse: if it currently has a value of true it is set to false, while if it currently has a value of false it is set to true. Processing then continues at step S36c where a check is made to determine whether the value of the counter variable i is still within the bounds of the array. If this is the case, processing returns to step S29a and continues as described above.

If the check of step S34a determines that an image is to be rendered (again based upon the index of the array) processing passes from step S34a to step S37a. Here, the image object created at step S20 is obtained.

Having obtained the image 70 at step S37a, at step S37b the image is indexed using information read from the CSV file. That is, where a particular forecast item takes one of twelve possible values (for example values from 1 to 12) the ForecastNow object determines the value stored at the element i of the array and based upon this value obtains coordinates which are used to read a particular image portion from the image 70. For example, if the read value is one, it may be that an image portion having its top left hand corner coincident with the top left hand corner of the image 70 is selected. Thus, the ForecastNow object 60 is able to determine coordinates for a corner of the image portion of interest, and on the basis that all image portions have equal dimensions, an appropriate image portion can then be extracted. The appropriate image portion is extracted from the image file 70 at step S37c and added to the rendered image. Adding the extracted image data to the image being rendered will involve determining appropriate coordinates based on the currently processed row and the calculated column indents.

It is to be noted that the generation of image data as described with reference to Figure 22 is carried out in the generation of the forecast shown in Figure 13 to obtain graphical data for the general descriptor symbols shown in the second column as well as wind direction arrows and pressure tendency arrows shown in the fifth and eighth column is respectively. Having obtained appropriate image data at step S37c, and added this to the image to be rendered, processing passes from step S37c to step S36a where the counter variable i is incremented as described above, the oddRow variable is updated at step S36b and a check is made to determine whether it was within the bounds of the array at step S36c.

If the check of step S36b determines that the counter variable i is not within the bounds of the array processing passes from step S36b to step S37 where a determination is made as to whether or not there is more data within the CSV file to be processed. If such data exists, processing passes from step S37 to step S29a where the processing continues as described above.

When the check of step S37 determines that all available data within the CSV tile has been processed, processing passes from step S33 to step S27 of Figure 21A where a rendered image is output to the ForecastNow object 60.

It is currently preferred to obtain particular graphical data for use in the processing of Figure 21 by extracting suitable data from a larger file storing a variety of graphical data, as described with reference to Figure 22. Such a method is efficient in terms of storage space requirements. However, graphical data can be obtained by selecting an appropriate one of a plurality of distinct files storing graphical data, without the need for extraction.

In general terms, referring again to Figure 19 it is to be noted that rendered image data is displayed using the ImageScreen object 67. As shown in Figure 7, the ImageScreen class 35 is a subclass of the provided CANVAS class 36 and therefore provided graphical manipulation methods can be used to manipulate the image.

It will be appreciated that some of the illustrated processingdescribed above is suitable for the display of forecasts such as those shown in Figures 14, 15 and 16.

This processing is now described further with reference to the illustration of Figure 23. A request for a forecast (for example, a satellite image such as that displayed in Figure 14) is received by the ForecastNow object 60 and this results in a request being made to a Downloader object 61a at step S40. Additionally, a status object 62a is also instantiated to display status information at step S41 as described above.

The Downloader object 61 a is provided with an appropriate request URL at step S40 and this URL is used by the Downloader object 61a for communication with the server 2 so as to download the appropriate image. When the appropriate image has been received, the Downloader object 61 a passes this image data to the ForecastNow object 60 at step S42. Given that such image data is already rendered for display, the ForecastNow object does not need to invoke a RendererThread object but can instead pass the received image data directly to an ImageScreen object 67a at step S43. In this way, the received image data is displayed to the user.

Although not illustrated in Figure 23, image data downloaded using the Downloader object 61 a and passed to the ForecastNow object 60 can be encoded as a byte array stream for storage in the RMS in the manner described above. This allows such images to be retrieved from storage for future display.

It was described with reference to Figure 19 that received data defining forecasts of the type shown in Figure 13 is stored in the RMS 26. By storing forecast data in this way obtained forecasts can be rendered from memory without requiring data to be fetched across the network. This process is carried out when a user selects a previously obtained forecast in the menu of Figure 17 by specifying a location (e.g. Hereford). When a user uses the menu of Figure 17 to make such a request, this request is processed by the ForecastNow object 60 as shown in Figure 24.

Specifically, the received request will include a location identifier derived from the menu selection, and this location identifier is used by the ForecastNow object to retrieve data from the RMS 26. At step S45 an appropriate request is made to the RMS 26 and the RMS returns appropriate data at step S46. It will be recalled that data was written to the RMS 26 in the process of Figure 19 using predefined methods operable on byte array streams. Similarly, the request of step S45 of Figure 20 takes the form of a method call to an appropriate read method. Data is returned to the ForecastNow object at step S46 in the form of a byte array stream and this byte array stream can be processed to generate an appropriate CSV file by the ForecastNow object 60.

When an appropriate CSV file has been generated, the ForecastNow object 60 instantiates a RendererTbread object 65b at step S47 and a Status object 66b at step S48. The generated CSV data is then passed to the RendererThread object 65b which renders an appropriate forecast image in the manner described above and returns appropriately generated image data to the ForecastNow object 60 at step S49. The Status object 66b is operable to display appropriate status information while the renderer thread object 65 is carrying out rendering operations, in the manner described above with reference to Figure 19.

Upon receiving appropriate image data from the renderer thread object 65b, the ForecastNow object 60 simply passes that image data to the ImageScreen object 6Th which is configured to receive rendered image data for display on a display device.

Where data such as that used to represent the images of Figures 14 to 16 is stored in the RMS, such data can be retrieved by selecting an appropriate option (e.g. Satellite Image) from the menu of Figure 17. In such a case the RMS will provide rendered image data to the ForecastNow object 60. Such rendered data can be passed directly to an Image Screen object without needing to create a RendererThread object.

Referring back to Figure 7, classes used to implement an application configured to provide meteorological forecast information are shown. Many of these classes have been described in use with reference to subsequent Figures. However, the description presented above does not describe the use of the DocScreen class 37 or the MenuScreen class 39.

Considering first the DocScreen class 37, this class is essentially used to display text (as opposed to image) data. It therefore takes appropriate textual information provided to it (in the form of a text file) by, for example, a ForecastNow object being an instance of the ForecastNow class 30 and generates an appropriate screen. The about screen shown in Figure 18 is an example of the use of the DocScreen class 37.

The MenuScreen class 39 is used to implement menus within the application, many of which have been described above. Use of the MenuScreen class is now described in further detail with reference to Figure 25. As shown above, and as will be appreciated by one of ordinary skill in the art, the menus essentially comprise a plurality of entries, each entry having associated with it an action performed when that entry is selected. Each menu is represented by a MenuScreen object 75. In order to define entries and functionality associated with a particular menu, the MenuScreen object 75 references an appropriate CSV data file 76. The format of the CSV data file is outlined in Figure 25. Ii can be seen that a first line of the CSV data file specifies a title for the menu together with data specifies the form of data included within the CSV file namely that each row of the CSV file will include a command name, that being the text to appear within the menu, and command action, that being an action to be carried out when a particular menu entry is selected, and a command parameter, that being a parameter to be associated with the action. As is shown in Figure 25, each subsequent row of the CSV file 76 includes three entries, a first to define a menu entry name, a second defining an action, and a third defining a parameter associated with that action.

Taking now the menus of Figures 11 and 12 as examples, the menu of Figure 11 will be defined by a MenuScreen object referencing an appropriate CSV file. The first menu entry will be defined by a row within that CSV file having a form: "Hereford & Worcester", showMenu, "Hereford & Worcester" That is, the entry "Hereford & Worcester" when selected requires that a menu entitled "Hereford & Worcester" is displayed.An appropriate method is invoked by processing the "showMenu" action. The method is invoked with a parameter "Hereford & Worcester". It will be appreciated that other entries within the menu of Figure 11 are defined by rows including a showMenu action with an appropriate parameter.

Considering the menu of Figure 12, here, the entry "Hereford" will be defined within an appropriate CSV file by an entry of the form: "Hereford", getData, 100 That is, when the "Hereford" menu entry is selected, the required action is to call a method determined by processing the "getData" action with a parameter 100. In this case, the parameter 100 is used as a location id within the appropriately formulated URL which is transmitted by the ForecastNow object to a Downloader object as described above.

It will therefore be appreciated that defining menus by the use of appropriate MenuScreen objects and appropriate CSV files provides a flexible method of defining menus within an application suitable to be executed on mobile devices. Specifically, specifics of menu operation need not be coded within particular objects or classes but are instead specified within appropriate CSV files. In this way, no code change is required if an application needs to be updated so as to provide different functionality in response to different menu selections, or if menu entries are to be added.

Appropriate CSV files for use in the implementation of menus as described above are included within the application's JAR file within the "/RES/" directory as shown in Figure 6.

It will be appreciated that the menu of Figure 17 needs to be created dynamically, and can therefore not be created using a static CSV file. Rather, appropriate data must be retrieved from the RMS by an appropriate MenuScreen object, and this retrieved data must then be displayed to the user. All entries within the menu 17 will have a common action, relating to the retrieval of appropriate data from the RMS.

The use of menus defined using MenuScreen objects as described above is managed by the ForecastNow object 60. The ForecastNow object 60 implements a command listener to "listen" for user interface events. When such an event occurs, the ForecastNow object takes appropriate action. Where menus are implemented as set out above, the action to be taken by the ForecastNow object in response to a particular user interface event is determined by locating an appropriate MenuScreen object and carrying out an action specified to be associated with a particular menu entry in a CSV file associated with that MenuScreen object. That is, the ForecastNow object "listens" for user interface events and then uses MenuScreen objects together with their associated CSV files to determine what action should be taken. Again, in this way a flexible user interface management system is provided which is both extensible and changeable without requiring amendments to code defining the application.

Referring back to Figure 1, it will be observed that the description presented above has been concerned primarily with operation of an application on the mobile telephone 6 and its interactions with the server 2. Further, the description presented above has not been concerned with operation of the server and the way in which the server provides various data to the mobile telephone 6. Operation of the server is now described in further detail, first with reference to Figure 26.

It can be seen that the server 2 comprises a data provider component 80 which communicates with a database 81 and an image store 82. The server 2 additionally comprises a data parser component 83 configured to receive and store data within the database 81. An image fetch component 84 is configured to retrieve image data and store retrieved image data within the image store 82. The components of the server 2 and their use in providing appropriate data to the mobile telephone 6 are now described in further detail.

As described above, when a meteorological forecast of the type shown in Figure 13 is required, an appropriate HT1'P request is made to the server 2 as denoted by an arrow 85. This request is processed by the data provider component 80. The data provider component makes a request using Java Database Connectivity (JDBC) to the database 81. This request includes a location identifier provided within the HTTP request 85 and results in the database 81 providing appropriate forecast data to the data provider component 80. The data received from the database 81 is formatted in to an appropriate CSV tile of the type described above, and is then provided by the server 2 to the mobile telephone 6 over the Internet 1, where it is received by a Downloader object in the manner described above.

The HTTP request 85 may be a request for a meteorological forecast taking the form of, for example, a satellite image or a rainfall radar. In such a case, the server 2 needs to download image data to the mobile telephone 6. In such a case, the data provider component 80 realises that image data is required and uses JDBC to obtain such image data from the image store 82. Again, the request made to the image store 82 by the data provider component 80 specifies the requisite image data as determined by the contents of the HTTP request 85. The image store 82 provides appropriate image data to the data provider component 80 which can then be downloaded to the mobile telephone 6.

The database 81 is populated with data retrieved from a remote data source by the data parser component 83. Specifically, the data parser component makes requests for data from a remote server using the File Transfer Protocol (FTP) at predetermined time intervals. This results in appropriate CSV data representing forecasts for all relevant locations being returned to the data parser component 83 and then written to the database 81 using JDBC. Once data has been stored within the database 81 it is accessible to the data provider component 80 as described above.

The image fetch component 84 again uses FTP requests made at predetermined time intervals to obtain appropriate image data from a remote data source. These FTP requests result in image data being provided to the image fetch component 84, the received image data then being stored within the image store 82 for subsequent retrieval by the data provider component 80 as described above.

Both the image data received by the image fetch component 84 and the CSV data received by the data parser component 83 is preferably provided by a centralised provided of meteorological information. For example, where the server 2 is concerned with providing meteorological information based around the United Kingdom the Meteorological Office provides an appropriate data source which can be accessed by the data parser component 83 and the image fetch component 84.

Data sources providing meteorological information may use location identifiers which vary from those used by applications operable on mobile telephones as described above, and identifiers received by the data provider component 80 from such applications. With this in mind, the data parser component 83 is configured to map location data specified within data received from a remote data source to location identifiers used by applications operable on the mobile telephone 6, which location identifiers are processed by the data provider 80 and are the subject of queries within the database 81. In this way, proper interoperability between applications operable on mobile telephone 6 and the remote data source providing data to the data parser component 83 is achieved.

The data provider component 80 can be implemented using Java Servlet technology using Java Server Pages (JSP). Alternatively, the data provider component 80 can be implemented using PHP scripts which run on the server 2 and which are configured to receive requests, access the database 81 and provide appropriate data in response to such requests. Where PHP scripts are used in this way it will be appreciated that connections between the data provider component 80 and the database 81 and the image store 82 are carried out using code specified within the PHP scripts rather than by using JDBC. Similarly, the Data Parser component 83 can be implemented using appropraite Java programs or PHP scripts.

The database 81 is implemented using any appropriate database platform, although in some embodiments of the invention the MySQL platform is used.

In general terms, the database 81 comprises two tables storing forecast data. A first (live) database table is used by the data provider component 80 to obtain appropriate data. A second (loading) database table is used by the data parser component 83 when new data is received from the remote data source. In this way, the "live" database need not be taken out of use while the FTP process to download data goes on. Rather, data can be placed in the "loading" table and transferred to the "live" table when download is complete.

In addition to tables storing forecast data as indicated above, the database 81 additionally includes a table defining locations for which forecast data is available, and this database table is useable by the data parser component 83 to perform mapping operations of the type described above.

Additionally, as was described above, upon receiving a request for an application from a mobile telephone the server 2 stores data mapping a unique identifier to a particular telephone number. An appropriate database table can be used to store this information within the database 81.

As is described in further detail below, the forecast of Figure 13 is merely exemplarily, and a variety of different forecasts presenting different information can be provided. With this in mind, each different forecast type will typically have two tables within the database 81, one "live" table and one "loading" table. For a particular forecast type, the respective "live" and "loading" table will include fields which are appropriate to data included within the respective forecast as is described below.

It has been indicated above that each mobile telephone on which an application configured to display meteorological data is installed has a unique identifier, the unique identifier being associated with a telephone number for that mobile telephone, and the identifier being transmitted to the server together with each request for data.

Transmitting the unique identifier in this way provides a useful revenue stream.

Specifically, by monitoring data transferred to a particular mobile telephone by monitoring unique identifiers, and by entering into agreements with mobile telephone operators, an operator of the server 2 may receive a proportion of charges associated with network traffic to their server. Alternatively and/or additionally, as was described above, the application to be installed on the mobile telephone was initially requested by a user transmitting an appropriate SMS message to a mobile gateway.

This message can be a premium rate message and the operator of the server 2 can receive a percentage of the charge associated with that premium rate message.

Although it has been described above that the application to display meteorological information is downloaded to the mobile telephone 6, it will be appreciated that in some embodiments of the invention, the application is installed on the mobile telephone 6 when the mobile telephone 6 is manufactured.

Referring again to Figure 1, it can be seen that in addition to the mobile telephone 6, a wide variety of different computing devices are connected to the Internet 1. Each of these different computing devices can be provided with an application configured to receive and display meteorological forecast data by obtaining appropriate data from the server 2. In particular, each of the computing devices can be provided with application software operable to receive a CSV data stream of the type described above and process that data stream together with stored image data so as to render a forecast for display, the forecast having a general form similar to that shown in Figure 13. While applications for the mobile telephone 6 and the PDA 5 are likely to take the form described above, applications intended for use on the laptop computer 4 and the desktop PC 3 are likely to take a different form. An interface for such an application is shown in Figure 27.

The interface shown in Figure 27 is associated with an application developed using the Java programming language. The displayed user interface was created using standard Java user interface development tools including the Abstract Windowing Toolkit (AWT) and the Swing libraries.

Referring to Figure 27, a map 90 can be navigated using a pointing device so as to select a region of interest. When the pointing device is within the region of interest that region can be selected so as to display a more detailed map for that region. In this way, a hierarchical selection process similar to that described above is provided.

When a location has been specified to the desired specificity, the application can make an appropriate request to the server 2 over the Internet I so as to receive appropriate forecast data which can then be rendered by the application. Specifically, the forecast data can take a form generally similar to (if not identical to) that described above and can be processed together with predetermined graphics so as to provide a forecast having a form as shown in the area 91 of Figure 27.

Both the example of the invention described with reference to Figure 27 and the example described for operation on the mobile telephone 6 have been concerned with providing forecast information for a particular location which is chosen using maps and or menus. It will be appreciated that alternatively forecast information can be selected by a user entering an appropriate location by typing the name of a town or area or alternatively by typing a postal or zip code. For example, in the interface of Figure 27, a textbox 92 is provided in to which location data can be entered and such location data can be used to obtain an appropriate meteorological forecast. Although such an input method may be convenient, it should be noted that in some embodiments of the invention, particularly those intended for use on mobile telephones it is currently preferred to allow selection using a combination of maps and menus given that the opportunity for a user to mistype a location is removed thereby rendering the system less prone to user error.

In some embodiments of the present invention intended for use on mobile telephones, users may obtain forecast information for a current location. Specifically, it is possible to locate a mobile telephone by reference to a "cell" in which the mobile telephone is located. By determining a mobile telephone's current cell location it is possible to determine a location identifier of the type described above and use this location identifier in a forecast request. In this way, a user is provided with a mechanism whereby they are able to obtain a forecast for their current location without needing to specify that location. Additionally, location systems other than those based upon mobile telephone cell can also be used to specify a location which is subsequently used as the basis for a forecast request. Such location systems include the Global Positioning System (GPS).

Parts of the description above have been concerned with the forecast shown in Figure 13. Using the general principles presented above for the generation of the forecast of Figure 13, a wide variety of different meteorological forecasts can be provided.

Referring again to Figure 13 it can be seen that the forecast shown there includes, for each time, a general descriptor symbol, a temperature, a wind speed, a wind direction (based upon a eight point compass), a cloud cover value expressed as a percentage, a pressure reading and a pressure tendency indicator. Therefore, the forecast shown in Figure, 13 is likely to be generally applicable fbr inland leisure use. However, if a forecast is to be provided to a sailor for nautical purposes different information will be required. Specifically, in addition to the information shown in Figure 13 information such as visibility and a sea state indicator would be of genuine use. The sea state indictor preferably takes the form of a graphical illustration of the roughness or calmness of the sea.

Similarly, if a forecast was to be provided for aviation purposes, it would be beneficial to provide wind speeds at differing heights and also information relating to the heights at which icing will occur in a particular location.

Furthermore, in general terms, it may well be useful to provide information relating to a maximum and minimum expected temperature at a particular time. From the outline presented above it will be appreciated that a variety of different forecasts for different purposes can be useful. Specific activities for which forecasts can be created incJuding information of particular use to that a particular activity include gardening and farming, aviation, astronomy, climbing and mountain walking, skiing and snowboarding, surfing, golf, cycling, cricket, football, rugby, horse racing, rambling, and fishing, concerts and events. Long range and city forecasts can also be provided.

It will be appreciated that each of these forecast types will include a variety of information appropriate to the particularly intended audience.

In general terms, although forecast information can include any appropriate meteorological information, information detailed in Table I is considered to be particularly useful for various of the forecasts outlined above.

Information Descriptor Information Descriptor % Probability of rain Rain 0 c Level Rain risk probability Beaufort scale Rainfall intensity of precipitation Cloud % Rainfall radar Cloud base Satellite pictures Cloud cover Sea State Cloud cover above 1 2,000ft Sea Temperature Cloud cover at all levels Severe weather warnings Cloud cover at the ground -mist/fog Snow Cloud cover from 100 to 4,000ft Snow cover Cloud cover from 4,000 to 12,000ft Soil temperature Current weather Storm risk Evaporation Surfing Flood alert rhunderstorms Forecast cover of convective clouds Tidal surge warnings Freezing level Time Frost alerts UV Indicator Gale warnings Visibility Gusts Nave direction Humidity Wave height Land temperature Wave period Max temperature Weather code/descriptor METARs (aviation forecasts) Wind chill Mm temperature Nind direction Pollen warnings Wind gusts Precipitation Wind speed Pressure Wind with tide Pressure Tendancy Wind over tide

Table I

By providing a variety of different forecasts for different purposes it will be appreciated that usefulness of forecasts provided using embodiments of the invention can be considerably enhanced.

It has been described above that a meteorological forecasts such as that shown in Figure 13 can be created by rendering an image based upon CSV data received from a server and using that CSV data to generate an image from pre-stored graphical data.

The invention is however not limited to the provision of' meteorological forecasts, and references to weather and meteorology in the preceding description are in no way intended to be limiting. Indeed, the rendering methods provided by embodiments of the invention are widely applicable and can be used to render images representing any information which can benefit from the combination a data stream and pre-stored graphical data. It will be appreciated that rendering images in this way is beneficial given that the data stream will occupy a far smaller bandwidth than image data.

Graphically rich data can therefore be presented without needing to download large quantities of graphical data. The general rendering method described for the image of Figure 13 can be used to render information relating to stock market listings, currency listings, cinema and TV listings, estate agency listings, role and flight timetables, restaurant and hotel information, and indeed any information which lends itself to a rendering method such as that described above.

In the preceding description the implementation of embodiments of the invention has been described in some detail. It will however be appreciated that the invention is not limited to such specified details but is instead widely applicable. Indeed, it will be appreciated that many variations can be made to the methods set out above without departing from the spirit and scope of the present invention. In particular, where reference has been made to implementation using the Java programming language, it will be appreciated that other programming languages can be used. Similarly, where reference has been made to particular file types such as CSV files and PNG files, it will be appreciated that the invention is not limited to the use of such files but is instead useable with any suitable data files. It will further be appreciated that the user interfaces presented above are merely exemplary, and different user interfaces could similarly be implemented.

Claims

CLAIMS

I. A method of generating an image at a client device, the method comprising: running an application on the client device, said application being configured to access a predefined set of graphical data stored on said client device; receiving data at the client device over a network; and processing said received data by the application to generate the image, said image comprising at least some of said predefined set of graphical data, said received data defining how said predefined graphical data is arranged in said image.

2. A method according to claim 1, further comprising processing said received data to select graphical data for inclusion in said image from said predefined set of graphical data.

3. A method according to claim 1 or 2, wherein said received data comprises a plurality of records each comprising a plurality of fields arranged in a predetermined order, and each field of each record is processed by said application to determine graphical data to be included in said image.

4. A method according to claim 3, wherein said image comprises data arranged in a plurality of rows, each row comprising a plurality of columns, and each row is represented by one of said records and each column is represented by one of said fieJds of a respective record.

5. A method according to claim 3 or 4, wherein processing is defined for each field of a record, said processing being defined with reference to a position of the field within the record.

6. A method according to any preceding claim, wherein said received data includes textual data, and said application adds such textual data to said generated image.

7. A method according to claim 6, wherein said application formats said textual data.

8. A method according to claim 7, wherein formatting said textual data comprises at least one of: selecting a font, selecting a font colour, selecting a text size

and selecting a background colour.

9. A method according to any preceding claim, wherein said predefined set of graphical data stored on said client device comprises a single tile defining a plurality of predetermined parts, each part representing graphical data suitable for discrete use.

10. A method according to claim 9, further comprising processing said received data to determine part of said single file to be included in said generated image.

11. A method according to claim 10, wherein a value of a field within said received data defines said part of said single file to be included in said generated image.

12. A method according to claim 11, wherein said field of said data takes values within a predetermined range of values, and each value is associated with a predetermined part of said single file.

13. A method according to any preceding claim, wherein said received data comprises a CSV file.

14. A method according to any preceding claim, further comprising: storing said data within a data repository.

15. A method according to claim 14, further comprising: receiving user input; retrieving stored data from said data repository in response to said user input; and processing said retrieved data to generate an image, said image comprising at least some graphical data from said predefined set of graphical data.

16. A method according to any preceding claim, further comprising: receiving user input representing a request to generate an image; and transmitting a message over said computer network in response to said user input; wherein said received data is received in response to said message.

17. A method according to claim 15 or 16, wherein said user input specifies a geographic location, and said received data is associated with said geographic location.

18. A method according to claim 17, wherein said geographic location is selected using at least one menu presenting a plurality of geographic locations to the user.

19. A method according to any one of claims 1 to 16, further comprising: determining a location of said client device; transmitting said location of said client device over said computer network; and receiving said received data in response to said transmitted location.

20. A method according to claim 19, wherein said location of said client device is determined at said client device.

21. A method according to claim 19 or 20, wherein said location of said client device is determined using one of a mobile telephony system and the global positioning system.

22. A method according to any preceding claim, wherein said image represents meteorological information.

23. A method according to claim 22 as dependent upon claim 17, 18, 19, 20 or 21 wherein said image represents meteorological information associated with said location.

24. A method according to claim 22 or 23, wherein said meteorological information comprises meteorological information for each of a plurality of times on each of a plurality of days.

25. A method according to claim 24, wherein said meteorological information comprises a plurality of rows, at least some of said rows presenting meteorological information associated with a particular time.

26. A method according to claim 25, wherein some of said rows present date information.

27. A computer readable medium carrying computer program code configured to control a computer to carry out a method according to any preceding claim.

28. A computer apparatus for generating an image, the apparatus comprising: a memory storing processor readable instructions; and a processor configured to read and execute instructions stored in said memory; wherein the processor readable instructions comprise instructions controlling the processor to carry out a method according to any one of claims I to 26.

29. A method of generating an image at a client device, the method comprising: receiving a request for data at a server; and transmitting data to said client device in response to said request; wherein the client runs an application configured to access a predefined Set of graphical data stored on said client device, the transmitted data is received at the client device over a network, and the client device processes said received data to generate the image, said image comprising at least some of said predefined set of graphical data, said received data defining how said predefined graphical data is arranged in said image.

30. A method according to claim 29, wherein said request for data specifies a geographic location, and data associated with the specified geographic location is transmitted.

31. A method according to claim 29 or 30, wherein said transmitted data comprises meteorological information.

32. A method according to any one of claims 29 to 31, further comprising: retrieving data from a database in response to said received request; wherein said transmitted data comprises said retrieved data.

33. A method according to claim 32, further comprising: formatting said retrieved data in a predetermined format prior to transmission.

34. A method according to claim 32 or 33, further comprising: requesting data from a remote data source at predetermined time intervals; and storing data received from said remote data source in said database.

35. A computer readable medium carrying computer program code configured to control a computer to carry out a method according to any one of claims 29 to 34.

36. A computer apparatus for generating an image, the apparatus comprising: a memory storing processor readable instructions; and a processor configured to read and execute instructions stored in said memory; wherein the processor readable instructions comprise instructions controlling the processor to carry out a method according to any one of claims 29 to 34.

37. A device for generating an image, the method comprising: means for running an application, said application being configured to access a predefined set of graphical data stored on the device; means for receiving data at the device over a network; and means for processing said received data by the application to generate the image, said image comprising at least some of said predefined set of graphical data, said received data defining how said predefined graphical data is arranged in said rendered image.

38. A mobile computing device configured to generate an image, the device comprising: a network interface configured to receive data from a computer network; a memory; and a processor, wherein the processor is adapted to run an application, said application being configured to access a predefined set of graphical data stored in said memory, and to process data by the application to generate the image, said image comprising at least some of said predefined set of graphical data, said received data defining how said predefined graphical data is arranged in said image.

39. A method of generating a menu within an application program, the method comprising: defining a data file containing data defining at least part of said menu; defining first computer program code representing said menu, said first computer program code comprising code which references said data file; and generating a said menu by running said first computer program code.

40. A method according to claim 39, wherein the menu comprises plurality of entries, and each entry of said menu is defined in said data file.

41. A method according to claim 40, wherein the definition of each entry in said data file includes a textual description of the entry.

42. A method according to claim 40 or 41, wherein the definition of each entry in said data file includes an action to be carried out upon selection of the entry.

43. A method according to claim 42, wherein the action associated with each entry comprises an associated parameter.

44. A method according to claim 43, wherein the action associated with each entry comprises a command and a parameter with which that command should be executed.

45. A method according to claim 43, wherein the action associated with each entry is processed to detennine a function to be called and said parameter is used in said function call.

46. A method according to any one of claims 39 to 45, wherein said computer program code is defined within an object.

47. A method according to claim 46, wherein said object is an instance of a class defining a menu.

48. A method according to claim 46 or 47 as dependent upon claim 45, wherein said function is a method associated with said object.

49. A method according to claim 46 or 47 as dependent upon claim 45, wherein said function is a method associated with a further object.

50. A method according to claim 49, wherein said further object defines a further menu, and said method causes said further menu to be displayed.

51. A computer readable medium carrying computer program code configured to control a computer to carry out a method according to any one of claims 39 to 50.

52. A computer apparatus for generating a menu, the apparatus comprising: a memory storing processor readable instructions; and a processor configured to read and execute instructions stored in said memory; wherein the processor readable instructions comprise instructions controlling the processor to carry out a method according to any one of claims 39 to 50.

53. A method of generating a menu within an application program, the method comprising: running first computer program code representing said menu, said first computer program code comprising code which references a data file; reading said data file; and generating said menu based upon data contained within said data file.

54. A method of receiving geographical input data, the method comprising: displaying a map; reading data indicating an ordered plurality of regions within that map; receiving input indicating user input; indicating one of said regions on said map in response to said user input, said indicated region being selected based upon ordering of said ordered plurality of regions.

55. A method according to claim 54, wherein said user input data is generated using a user input device moveable in a plurality of direction.

56. A method according to claim 55, wherein said input data specifies one of said plurality of directions.

57. A method according to claim 56, wherein said specified one of said plurality directions determines a direction in which said ordered plurality of regions is processed to determine said region to be indicated.

58. A method according to any one of claims 54 to 57, wherein said map shows land, and at least some of said plurality of regions are parts of said land.

59. A method according to any one of claims 54 to 58, wherein said map shows sea, and at least some of said plurality of regions are parts of said sea.

60. A method according to any one of claims 54 to 59, wherein indicating one of said regions comprises displaying said indicated region in a different colour on said map.

61. A method according to any one of claims 54 to 60 further comprising receiving user input data representing selection of said indicated region.

62. A computer readable medium carrying computer program code configured to control a computer to carry out a method according to any one of claims 54 to 61.

63. A computer apparatus for receiving geographical input data, the apparatus comprising: a memory storing processor readable instructions; and a processor configured to read and execute instructions stored in said memory; wherein the processor readable instructions comprise instructions controlling the processor to carry out a method according to any one of claims 54 to 61.

64. A method for displaying meteorological information at a client device, the method comprising: determining a location of said client device; transmitting said determined location to a server; receiving data from said server; and displaying meteorological information based upon said received data.

65. A method according to claim 64 wherein the location of said client device is determined at said client device.

66. A method according to claim 64 wherein said location of said client device is determined using one of the global positioning system and a mobile telephony system.

67. A computer readable medium carrying computer program code configured to control a computer to carry out a method according to any one of claims 64 to 66.

68. A computer apparatus for displaying meteorological information, the apparatus comprising: a memory storing processor readable instructions; and a processor configured to read and execute instructions stored in said program memory; wherein said processor readable instructions comprise instructions controlling the processor to carry out a method according to any one of claims 64 to 66.