NZ546871A - Mobile device dynamic update - Google Patents

Abstract

A remote mobile device application maintenance system is disclosed. An application server retains at least one application including an application version indicator. The application is operable on a remote device and the application server retains incremental updates to the application and has an uploading facility capable of uploading the application to a remote device and of uploading incremental updates to a remote device reporting the attempted viewing of a version of the application. A remote device has a user display and means for interaction with the display. The remote device is capable of retaining at least the application. A version detector operates in the remote device and detects the application version when the application is instantiated on the remote device. A version reporter in the mobile device reports the detected version to an application server when the viewer attempts to view the application interface. In an application updater in the remote device capable of receiving from the application server incremental updates to an application and updating the application before the application instantiation is completed.

Description

546871 Patents Form # 5 IPONZ 3 8 ML 2007 NEW ZEALAND Patents Act 1953 COMPLETE SPECIFICATION AFTER PROVISIONAL # : 546871/555913 DATED : 1 May 2006/15 June 2007 TITLE : Mobile Device Dynamic Update I, MCGOVERN, Murray Address: 30 Jackson Road, Kaharoa. Rotorua, New Zealand Nationality: A New Zealand citizen/company do hereby declare the invention for which I pray that a patent may be granted to me and the method by which it is to be performed, to be particularly described in and by the following statement: 4003 52NZ_Cap_20070730_ 1258_PHC.doc "FEE CODE 1050 546871 400352NZ_CornpSpec_J01.doc - 2 - Mobile Device Dynamic Update Technical Field The invention generally relates to interfaces for mobile devices.

More particularly the invention relates to providing an interface for mobile devices to 5 various remote server applications which interface can be dynamically updated.

Background Art It is known to provide data to mobile telephones or other mobile devices which data includes an internet or WAP (Wireless Application Protocol) interface, however the bandwidth available to mobile telephones is such that the download speeds may be low 10 and data download costs may be high. Furthermore even where the band width is available the mobile telephone generally does not contain sufficient graphics and data handling facilities to provide an intelligent interface for users to view such data. This maybe provided by loading an application onto the mobile telephone or mobile device to provide both a data processing function and a data viewing interface, possibly with 15 provision for user interaction.

An example of the type of data normally requiring ail application and interface is that from a remote apparatus which can be monitored by cellular phone, the apparatus having an embedded cellular phone interface and the ability to call a known cellular phone number or numbers to report one or more conditions of the apparatus or 20 environment. Such apparatus is typically used for security, remote level metering, temperature monitoring and other such conditions. Such apparatus is referred to herein as a Remote Intelligent Mobile Device (RIMD). Data from an RIMD may be presented in an interface forming part of an application loaded into the mobile device.

Typically such an application will be retained on the mobile device for as long as 25 possible commensurate with whatever else is loaded into the device, but in doing so the application may become outdated, for instance where the application relates to purchasing items via an SMS interface, the prices may change. In situations where this may occur it is normal to force a download of the data for the whole application, resulting in a large amount of traffic over what may be a slow connection. 546871 400352NZ_CompSpec_I01.doc - 3 - It would be preferable to reduce the data download size as much as possible while retaining the flexibility to provide an acceptable user experience.

Hence a need exists for a solution to the problem of reducing the amount of data to be downloaded by a mobile telephone while still providing the required functions to the user.

The present invention provides a solution to this and other problems which offers advantages over the prior art or which will at least provide the public with a useful choice.

It is acknowledged that the term 'comprise' may, under varying jurisdictions, be attributed with either an exclusive or an inclusive meaning. For the purpose of this specification, and unless otherwise noted, the term 'comprise' shall have an inclusive meaning - i.e. that it will be taken to mean an inclusion of not only the listed components it directly references, but also other non-specified components or elements. This rationale will also be used when the term 'comprised' or 'comprising' is used in relation to one or more steps in a method or process.

Summary Of The Invention In one exemplification the invention relates to remote device application maintenance system comprising a server retaining at least one application operable on a remote mobile device having a user display and means for user interaction with the display, an uploading facility uploading the application to the remote mobile device when initially required and, an updating facility within the server providing incremental updates to the application in the remote mobile device when portions of the application in the remote mobile device are detected as requiring updates.

Preferably each portion of the application contains a version identifier and the version identifier is reported before each use by the remote device to the server and a version comparison interface within the server compares current and reported version identifiers to prompt the updating facility to upload an incremental update containing application differences when the version identifiers differ. 546871 400352NZ_CompSpec_lQl.doc - 4 - Preferably wherein the server retaining the remote mobile device operable application retains the interface data for each different screen in XML format and within each XML format includes a version identifier.

Preferably the at least one application is remotely editable and compileable into a compressed form on the server and each incremental portion is equally editable, compressible and compileable.

In an alternative embodiment the invention relates to a user interactive mobile device having a user display and means for interacting with the display when provided with an application and application interface downloaded from a server wherein the application or interface is updatable incrementally from the server at each use.

Preferably the user interactive device application is Java based.

Alternatively the invention may be said to relate to a method of providing an updateable user application and interface for a user interactive device having a viewer display and means for interacting with the display comprising: uploading to the user interactive device user applications and interfaces viewable on the viewer display, retaining the application and interfaces within the user interactive device, receiving data to be viewed in the downloaded application and interfaces, determining whether the application or an interface retained within the interactive device is outdated, updating as necessary the application or interface retained within the user interactive device by incrementally updating changed portions of the application or interface, invoking the application and interface and displaying the data on the user viewable display in the user interface.

In an alternative embodiment the invention relates to a method of updating a user interface for an application to a mobile device comprising : requesting from a mobile device application information from a remote server, the remote server storing the application user interface content at known historic configurations and a current user interface configuration; providing to the mobile device initial data containing at least a customer identification and login elements; requesting the mobile device user to provide valid login information for the application; 546871 400352NZ_CompSpec_101.doc - 5 - transmitting to the remote server the login information, the customer identification, and an indication of the configuration of the application interface on the mobile device; validating the customer identification and the login information at the remote server; retrieving from a server store an update containing data to return the configuration data stored on the mobile device to the current configuration state by amendment; amending the application data in the mobile device by downloading and applying the update.

Preferably the server can provide an update for the differences between any historic 10 configuration and the current configuration.

Preferably data for a full application interface is provided if none is present in the mobile device initially.

Preferably a binary script converting an update to amendments in the stored configuration is supplied with the login information.

Preferably the update data transferred between server and mobile device or vice versa is encoded.

Preferably wherein the encoding is encrypted XML.

Preferably the data is transferred between mobile device and remote server by HTTP.

These and other features of as well as advantages which characterise the present 20 invention will be apparent upon reading of the following detailed description and review of the associated drawings.

Brief Description of the Drawings FIG. 1 is a diagrammatic view of the component parts of the apparatus.

FIG. 2 is a sequence diagram of the instantiation of the invention in a mobile phone.

FIG. 3 is a flow diagram of the complete process of invoking and updating a data displaying application at the mobile phone.

FIG. 4 is sequence diagram of recognising the receipt of an application message at a mobile phone and viewing the message. 546871 400352NZ_CompSpec_101.doc - 6 - FIG. 5 is a sequence diagram of issuing data or a message to a remote location. FIG. 6 shows example display screens on mobile telephones for differing applications.

Description of the Invention Referring now to FIG. 1 the components of a typical system for providing an 5 application to a remote device such as a mobile phone are shown. These consist of the mobile phone 101 and the connection of the mobile phone in a data transfer mode via the telecommunications network 102 to an application server 103. An application is built on the application server 103, compiled and stored in a database 105 through a database server 104. When the mobile phone user requires the interface for the 10 application it may be instantiated from the phone 101, if previously downloaded from the application server 103, or downloaded from the application server 103 on demand. The application may be maintained remotely via internet 106 and a computer 107 connected to the internet.

The applications provided on the mobile phone may be used to receive data from or 15 provide data to a remote device, for instance the application may be concerned with monitoring a video camera 109 via a telephone access point 108, the video camera providing an image to a specified phone address when movement is detected. In response to receipt of the image in an application in the phone 101a command may be sent from the phone to the video camera control, for instance to rotate it or to turn an 20 illuminating light on. Equally the application interface may be used in conjunction with an item ordering application, the application issuing HTTP packets from the phone to a web server 110 at a known URL or IP address to provide ordering information to such as a fast food outlet at 111.

Some such item ordering applications require the entiy of keywords for an SMS 25 response, and some of these keywords are lengthy and cryptic in the extreme. Use of an appropriate menu structure overlay as part of a corresponding application can allow a user to navigate a sensible menu structure and make a choice which generates the appropriate keyword as a response.

Generally speaking the applications created are designed for devices which have little 30 or no remotely accessible screen functionality, but which are capable of having a 546871 400352NZ CompSpeo_101.doc -7- formatted screen placed on view and of interacting with that screen. Typically a mobile telephone having Java functionality meets these requirements, but devices with more functionality are capable of acting in the same manner.

Design of an application is then a question of designing the screens with which the 5 user will interact, defining the actions which will take place when the user interacts with the screen, and defining the results of those actions.

Typically each part of the application which is presented as or with a single user viewable screen is considered to be a separately versionable part of the application, and the version is tracked. Typically the screen data is presented as XML and the 10 version data is merely a tag in the XML. The invention includes ensuring that the application present on the mobile phone matches the current version present on the application server, and extends to providing uploads of only the data which has changed to bring the mobile phone application and server application into agreement. For this purpose the application produces a compilation of the interface configuration 15 data with each compilation having a version or identification number embedded within it. Each change to the output results in a new version number for the output, and the current version and all past versions are stored within the database. At each attempt by a cell phone user to view the interface a request is returned to the server with the version number of the stored interface (if present), and if the version number does not 20 match the most current version the different part of the content is updated from the server.

While the message received at the receiving device may be in many forms FIG. 2 shows the process at a mobile phone of receiving an SMS or HTTP message at 201, detecting whether the message is directed to a the port used by a particular application 25 at 202, and if it is not, passing it on to the user to view. If the message is directed to a port recognised as a known application, or has some other recognisable feature indicating it is an application message, the information in the message is detected at 204, the presence of the required application interfac e is checked at 205, and if the interface is not present it is downloaded from the relevant application server at 206. At 30 207 the application is checked for currency of the portion about to be viewed by the user and if this is not a current version the upgraded portion is downloaded at 208. At 209 the data in the application interface is presented to the user and any user input 546871 400352NZ CompSpec_10i.doc - 8 - awaited, If none is allowable or required the next message is awaited at 210. If some user output is required the output may be formatted into an SMS or HTTP message, or into some other data form at 211, and sent at 212.

FIG. 3 shows a more system oriented view of the process sequence concerned with 5 connecting the user to an application and creating or updating the interface in the phone as required. To this end a user viewing the phone interface 301 chooses to open an interface to a particular application which has either been initialised previously on that phone or for which a J2ME MIDlet has previously been downloaded to the phone but destroyed.

At 302 the interface initialises the required MIDlet in the application interface 303, and this in turn initiates a data connection at 304 to the remote application server 305. The server in turn at 306 retrieves from database server 307 the current accompaniments to the login screen (typically advertising) and returns this to the application server at 308, which returns this and a customer identification to the phone at 309. The MIDlet 15 passes the customer ID to the login response subroutine at 3II, and places on the interface screen at 310 the login dialog and any accompaniments downloaded.

The user responds by entering a password at 312 which is passed back through the J2ME interface, retrieving the customer ID and the current version of the interface stored at 313. and on at 314 to the remote application server.

Here the application server retrieves data from the database via 315, 316 to validate the login request, and also retrieves the password for verification of the user login and the phone interface version for information on what data is historically held on the phone. At 317 the login information is verified, at 318 the menu held on the phone is compared with the current menu and at 319 any changes between the stored version 25 and the current version prepared for uploading to the phone. At 320 other items relevant to the application are checked against the data currently held in the phone, for instance the sale specials if the application relates to an on-line store, and again prepares updates for these at 321. At 322 the full data for the response is assembled and the version numbers of the assembly stored in the database against the mobile 30 phone ID. The full data is also issued to the phone at 323 for updating of the new ...... .... . ^ 646871 400352NZ_CompSpec_l 01 .doc -9- information to the phone data store at 324 before the visible portion of the interface (menus, sale specials) is placed on the screen 326 at 325.

The information transferred between mobile phone and application server is preferably in the form of XML files, and preferably the file is transmitted between application 5 server and mobile phone as data on an HTTP port, though other ports may be used.

Where a request requires a partial update the portion or portions to be updated are identified within the version as held on the mobile phone and an XML file with the updates is created. This is supplied to the mobile phone which, in conjunction with the application code it is running, excerpts the changed portions from the update supplied ( 10 and applies them to the data already held in the phone before presenting this to the user. Since the downloaded portion is much smaller than that required if the complete interface were supplied to the mobile phone the response time perceived by the user is correspondingly reduced.

A sample part of the interface as held by the phone might be: <?xml version="1.0" encodiri.g="utf-8" ?> <menu code="156aal56-e39b-4d22-8523-b673f48e7095"> ■ <ingredientGroup> \ .... - * <ingredient'code="l" cost="300" nams="Chioken"></ingredient> </ingredieritGroup> . / > <productGroup name'=" Pizza" in)g="Pizza.png"> ■ <product. code="101" .descripti6n*t"Chipk.en pizza with Apricot -sauce" name="Apricot chicken" img-"Pizza.png"> ; Coption exclusivity="true" name="Pizza base"> • cingredient cocie="l" isSeXected="true"></ingredient> "25 • </opticm> . • - <./product> " </produc.tGroup> . . . ■ : . - </menu> , V Where a price has changed, this would result in an update of the form: . . 30 cingrsdient" ;cqde«"l" cost-7300"' name-''Chickeh"></ingr«cUent> • > To .•<ingredient; code-*1!" 'cost^"350-" n a me ~11 Ch i c k@ ri" > < / -i ng r ed i. § n t > This example shows an update at the lowest level normally allowed, that is, the replacement of the data within a single low level XML tag, although the menu version 546871 400352NZ_ConipSpec_101.doc -10- code within the XML will also require updating. Equally the update could be at any higher level within the interface, for instance the complete deletion of a "<menu>" entry and the replacement of it by a totally different menu entry.

Where memory space allows the mobile device or phone may include a database of 5 previous user responses, as well as the application, and may allow the user to select these rather than proceeding down what could be an extended menu navigation.

When the application is concerned with remote monitoring the remote monitoring unit is typically remotely or locally programmable if desired to set the basic parameters, such as the cellular phone number to call with the monitoring data, the format of the 10 monitoring report, the type of monitoring report (SMS, MMS, or some other data format) and, for any of these, the port on which the report should be sent. Once these parameters are set the unit may be remotely controlled for any additional parameters, such as the alarm level at which the measured parameters may trigger a call to the monitoring cellular phone, alternate cellular phone numbers to call if no response is 15 received, and time out parameters for various situations. Alarms may be audible alarms or they may equally be visible or vibration alarms or a combination of one or more of these.

While the invention is described using J2ME as the application foundation other code base origins are equally applicable and the code base chosen will depend on the device 20 used.

Fig 4 shows an example of the processing required to handle information received from an RIMD, describing the application processing required to handle the incoming messages in a MIDlet, and includes at 401 the detection by a users cellular phone of an incoming message, and at 402 the detection of the port 5000 (for example) in the 25 incoming message. The standard phone software tests for an association with special software for that port and at 403 attempts to handover to the application denoted as serving that port. If the application is not present it is downloaded, if present but not running it forces the invocation of the application at 404 via Java MIDlet standard Push technology and the message is then handed over to the application. Similarly if 30 the application Listener is already running the handover is made at 406. 546871 400352NZ_CompSpec_10I.doc -11- Once received by the application a check is made which typically checks that the handler for the port matches the handler requested in the message header, and that the sender is one who is allowed to receive the message. To do this for an SMS implementation the application may specify a string such as "MIDlet-Push-5 1 :sms://:5000, Sentinel, *" which may imply to the application that "MIDlet-Push-1" is expected to be invoked, that the URL (as used in a Sun Java implementation) of the calls to be handled by the application must be SMS with a port of 5000, that the MIDlet class name to be invoked is "Sentinel" and that any caller (*) may provide a message which will be processed.

Once verified the message payload is processed at 408. This may include detecting at 309 that the message contains an image and invoking the cellular phone image handler in user application software at 410, though this step may vary depending on the operating system.

Following this the type of message is checked at 411, and if an alarm the process 15 diverts to trigger the phone alarm by directly accessing phone alarm resources which include audio, visual or vibrator, at 416. The data contained in the message is then processed to the correct place in the menu for the application and presented in the correct context at 417 via application GUI for the user to view before exiting the application at 415.

Normal monitoring messages have data extracted at 412 to update the parameters for the particular RIMD sending the message at 412, the menu is then updated with the relevant values or images at 413 and presented to the user at 414 before opting out of the application.

To provide the outgoing messages or data a process such as that shown in the flow 25 diagrams of FIG 5 is used. The user initially selects at 501 the menus or templates relating to the particular type of RIMD, either on the basis of a list of types or on the basis of the location to be called. When the appropriate menu selection is enabled and the appropriate one of the possible RIMD's of the viewed type is chosen the menu for that particular RIMD is viewed at 502. Some of the menus relate to updates to be sent 30 to the RIMD and some to requests for information from the RIMD. The processing for these two types of operation are different so a choice is made at 503 of which 546871 400352NZ_CompSpec_101.doi: - 12 - processing path to follow and the menu or input choices to be made by the user. At 504 a value or menu choice to be sent to the RIMD as a control parameter value is selected or entered, while at 505 a choice is made of which type of response is to be returned from the RIMD as a monitored value. Such a request may be for a list of a set 5 of control values, or an image of the controlled area, or some other parameter related to the location or performance of the RIMD controlled equipment.

The available types of data connection to the RIMD are then automatically reviewed at 506, these being dependent on the type device the user is using, the facilities available from the provider between the users device and the RIMD device, and the capabilities 10 of the RIMD itself. The type of data connection chosen may be dictated by the availability of the connection type, and any particular application may have the ability to determine the preferred connection type based on cost, the fall back connection type if that is currently unavailable, and the emergency connection type if the application is considered urgent enough. The selected or entered information is then assembled into 15 either a message package at 507 or a data package at 508, a connection established with the provider at 509, and the message sent at 510.

The data handling process of the invention may be used to serve RIMDs carrying out any kind of remote asset monitoring or management, for instance for remote or autonomous control, image capture, parameter alarms, etc. The RIMD may be located 20 anywhere within reach of a cellular phone network or of some other connection which will ultimately be connectable to the required monitoring device. This may be a satellite phone network, a radio network, a landline, an Ethernet connection or some other data transfer method and may be used in a marine craft environment, a home security environment, a horticultural environment, for pump/irrigation control, in smart 25 buildings, in security and surveillance operations, in industry and farming, in GPS asset location, meter reading, etc.

While the description above implies that an alarm is presented instantly to the user it is possible to categorise alarms into urgent and non-urgent and to merely load non-urgent alarms into a database on the phone or user device for later action by the user. 30 Similarly other data may be merely loaded in for later action without notifying the user that information has been received. 546871 400352NZ_CompSpec_10I.doc - 13 - Since the menus for interacting with the RIMDs are particular to the RIMD from which a message was received or to which a message is being sent the appropriate related API to launch appropriate related menus is stored in the users cellular phone and called into use as required via headers embedded in the RIMD generated data 5 communication payload. Typically the menus are held as part of the particular application software and are updateable with that software, but they may be stored in the cellular phone memory, or as a file in the cellular phone where it is not expected that the interface will change with time. Similarly the values reported by an RIMD or sent to an RIMD may be held in temporary scratch memory, or they may be stored in 10 the appropriate phone memory segment or as files within the phone. Where this information is stored on the cellular phone it may be presented to the user as a history of the parameters recorded, preferably in a format in which it is easily intelligible to the user, as for instance by the use of graphing or charting functions applied to the particular application. Up to the available memory limit it is possible for the 15 application to store a full transactional record of all information received and commands sent.

Interaction with multiple RIMDs may be provided by a single application with different available menus and reply templates or by multiple applications, each differing in menu and reply template structure and particularly adapted to the 20 application.

The port on which the RIMD sends a message may be set at any value, preferably using one of the port values which is unallocated globally or a port which is dedicated to the service. Where the information is transferred by a data connection rather than as SMS text the data stream may itself identify the application and actual RIMD device, 25 and pre-processing of the data stream can invoke the correct application or application module.

The cellular phone used as the interface for the applications must necessarily have sufficient facilities to at least allow it to process an incoming SMS message and present it to the user in a special manner. Preferably the cellular phone is Java enabled 30 and has sufficient processing power and graphics capability to support the software application and an appropriate user operation interface. For easy use it is preferred that the cellular phone is capable of interfacing on a 2.5G plus system and cellular phones 546871 400352NZ_CompSpec_101.doc - 14 - with a 3G interface and good GUI capabilities are recommended if a data stream is the preferred information transfer method. Where the available memory and processing power allow, data from previous interactions may be stored for user access.

The application processing the incoming and outgoing messages may be implemented 5 in any form which is compatible with the users cellular phone or with any other device required to provide a user interface, though a preferred method is by using a cellular phone which includes the Mobile Information Device Profile (MIDP) APIs (Application Program Interfaces) running on a Java enabled operating system. The application may then be provided as Java MIDlets (applications complying with the 10 MIDP standards) to carry out the operations. Depending on the resources of the cellular phone applications running 011 other systems may be provided, for instance, applications based on the .Net framework. Similarly the applications may operate by transferring data via SMS, MMS or by any other available or usable protocol, such as TC/PIP, UDP or HTTP. The choice of protocol is dictated by the target device and its 15 capabilities.

FIG. 6 shows four examples of application screens in use on cellular phones. The upper two shown reporting screens which may also act as control screens where a radio button may be altered to a desired state. The lower two screens show the use of a graphics capable cellular phone to display historic information from memory or file 20 relating to the parameters as received from a specific RIMD.

The messages received from an RIMD may vary in complexity in dependence on the capabilities of the receiving cellular phone, for instance if the destination is available only by SMS the message may be such as "Playes Farm Tempi 18.3 Wind 13 WDir NW Rain 3.2 SoilMoist 24 Irrig OFF". String recognition on the SMS message may 25 be used to present the calling location, current temperature, wind strength, wind direction, rainfall over 24 hours, soil moisture and irrigation status, and from this to control whether to turn the irrigation on. If a more complex data medium is available the information may be more complex and may include attached images. Thus for instance sensors on board a vessel could report the vessels GPS location and provide 30 an image of the surroundings from a digital camera. 546871 400352NZ_CompSpec_101.doc - 15 - It is to be understood that even though numerous characteristics and advantages of the various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and functioning of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail so long as the functioning of the invention is not adversely affected. For example the particular elements of the download creation sequence may vary dependent on the particular application for which it is used without variation in the spirit and scope of the present invention.

In addition, although the preferred embodiments described herein are directed to an application relating to a store front in a purchase system, it will be appreciated by those skilled in the art that the teachings of the present invention can be applied to other systems such as general web sites, quizzes, educational applications, travel information, weather information, traffic information, etc without departing from the scope and spirit of the present invention. 400352NZ Claims20081118 PHC.doc 54^71

Claims (15)

Claims

1. A remote mobile device application maintenance system comprising; an application server retaining at least one application including an application version indicator, the application being operable on a remote device and the application server retaining incremental updates to the application and having an uploading facility capable of uploading the application to a remote device and of uploading incremental updates to a remote device reporting the attempted viewing of a version of the application; a remote device having a user display and means for interaction with the display the remote device being capable of retaining at least the application, a version detector operating in the remote device and detecting the application version when the application is instantiated on the remote device, a version reporter in the mobile device reporting the detected version to an application server when the viewer attempts to view the application interface; characterised in an application updater in the remote device capable of receiving from the application server incremental updates to an application and updating the application before the application instantiation is completed.

2. A remote mobile device application maintenance system as claimed in claim 1 wherein the application server uploading the remote mobile device operable application retains interface data for each different screen in XML format and within each XML format includes a version identifier.

3. A remote mobile device application maintenance system as claimed in claim 1 wherein the at least one application is remotely editable and compileable into a compressed form on the server and each incremental portion is equally editable, compressible and compileable.

4. A remote mobile device application maintenance system as claimed in claim 1 wherein a version match comparator within the server compares current and reported version identifiers of the at least one application to prompt the updating facility to upload an incremental update containing application differences when the version identifiers differ.

5. A user interactive mobile device having a user display and means for interaction with the display the mobile device including at least one loadable application and application interface wherein the application and interface are updateable from a 546871 remote application server, an application version detector detecting the version of an application before each instantiation of the application and being capable of transmitting the version to the remote application server, an updater receiving incremental application updates from the application server and, where an update is provided, of updating the application before it is used by the user.

6. A user interactive mobile device as claimed in claim 5 wherein the transmission to the server and the reception from the server are carried out using SMS messages.

7. A user interactive mobile device as claimed in claim 5 wherein the application interface includes provision for user input and transmission of commands to the source of the data displayed in the user interface.

8. A user interactive mobile device as claimed in claim 5 wherein the user interactive device application is Java based.

9. A user interactive mobile device as claimed in claim 5 wherein the uploading facility uploads application incremental changes via SMS messages.

10. A method of providing an updateable user application and interface for a user interactive device having a viewer display and means for interacting with the display comprising: uploading to the user interactive device user applications and interfaces viewable on the viewer display, the applications and interfaces including a version identifier, retaining the application and interfaces within the user interactive device, commencing instantiation of the application or interface, determining from the included version identifier when presented to a remote application server whether the application or an interface retained within the interactive device is outdated, updating from the remote application server as necessary the application or interface retained within the user interactive device by incrementally updating changed portions of the application or interface, completing instantiation of the application and interface and displaying the user interface on the user viewable display.

11. A method of providing an updateable user application and interface for a user interactive device as claimed in claim 10 wherein the remote application server can provide an update for the differences between any historic configuration and the current configuration. 546871

12. A method of providing an updateable user application and interface as claimed in claim 10 wherein the update data transferred between server and mobile device is encoded.

13. A method of providing an updateable user application and interface as claimed in claim 10 wherein the data is transferred between mobile device and remote application server by HTTP.

14. A method of providing an updateable user application and interface for an application to a mobile device as claimed in claim 10 wherein the remote server stores the application user interface content at known historic configurations and a current user interface configuration.

15. A method of updating a mobile user interactive device substantially as herein described with reference to FIGs 1, 2, 3, 4 and 5. Murray McGovern