WO2007118890A1

WO2007118890A1 - Method for extending applications for mobile devices

Info

Publication number: WO2007118890A1
Application number: PCT/EP2007/053790
Authority: WO
Inventors: Phillip Fitzsimmons
Original assignee: Phillip Fitzsimmons
Priority date: 2006-04-18
Filing date: 2007-04-18
Publication date: 2007-10-25

Abstract

The present invention is related to a method for extending the functionality of a handset, which is provided with a means for executing applications. The method comprises the steps of: describing an application in markup language, loading the application onto the handset, describing further functionality of the application or a new portion of the application to replace an existing portion in markup language, loading the further functionality of the application or replacing the old portion of the application with the new portion by using the means for executing applications.

Description

METHOD FOR EXTENDING APPLICATIONS FOR MOBILE DEVICES

Field of the invention [0001] The present invention relates to the field of software applications for small devices like mobile phones.

State of the art

[0002] Software for mobile applications is currently developed and delivered in one of two ways, both of which are analogous to the delivery of any other type of software, as either fat or thin clients.

Fat Client [0003] A fat client, or stand-alone application, is fully operational software with integral functionality. An illustration is given in Fig.l. Such applications are embedded on or delivered to mobile phones and PDAs as compiled code in an immutable package. Fig. 1 also shows an application embedded on the device at the factory or provisioned to the device over the air. Embedded applications, those installed directly on the hardware at the factory are typically written in ANSI-C. Provisioned applications, those installed ^Λover the air' (meaning that they are downloaded over a wireless network and installed on the phone) or downloaded to a host computer and synchronised to the device are overwhelmingly some variation of Java, such as J2ME (Sun's micro-edition specification), Doja (Java for i-mode devices) or BREW. Other contenders in this space are Microsoft's Mobile .NET and Symbian, both of which follow a similar model but provide for the remote provisioning of applications written in some variation of C. [0004] The chief characteristic of this approach to developing and delivering mobile applications for the purposes of this document is the lack of extensibility. Once an application has been installed on the handset it can only be changed by replacing the entire application.

Thin client

[0005] Thin client applications (as illustrated in Fig.2) have little or no integral functionality but instead interpret instructions from a remote server. Fig.2 shows pages being delivered to the device from a web server and rendered by a browser.

[0006] Certainly the most common approach to delivering thin client functionality is via a browser which interprets a markup language, almost always according to a standardised XML specification, such as WML (Wireless Markup Language) or xHTML (XML compliant Hypertext Markup Language), and interpreted by a browser.

[0007] WML and xHTML define the basic user interface, event and navigational components required to deliver rich client functionality and are often complemented by support for a high-level scripting language, such as WMLS (Wireless Markup Language Scripting) or Java script (a scripting language supported by modern desktop and many mobile web browsers) . [0008] Conceptually applications have been defined in XML for years. In so far as HTML is a clear progenitor of XML it can be said that XML has been used to define remote applications since the very first HTML browser, Mosaic, was introduced in November 1993. [0009] This approach provides maximum extensibility and is considerably less complex to develop than fat clients. Markup languages are by definition simpler to understand and maintain and, because all functionality is hosted in a server environment, changing the application for all clients is merely a matter of changing code of a single application instance.

[0010] The principal disadvantages of the thin client are that it requires expensive and time-consuming interaction with a server to provide even minimal functionality, such as navigating from one screen to another, and that it offers little of the functionality achieved with fat clients. [0011] Patent application US2005/197157-A1 relates to a system operable on a small mobile device (such as a smart phone) that uses descriptive languages with a similar style to markup languages used in a thin client but having features characteristic of a fat client. This approach is no appreciable improvement over the existing model of browser (thin client) applications in that remotely accessed markup is not stored locally and hence cannot enhance or alter the resident (local) markup. Any functionality not permanently embedded on the device would have to be reacquired from a server for each use.

Aims of the invention

[0012] The present invention aims to provide a convenient method for extending the functionality of a mobile device (like a handset) .

Summary of the invention

[0013] The present invention relates to a method for extending the functionality of a handset, said handset being provided with a means for executing applications. The method comprises the steps of

- describing an application in markup language,

- loading the application onto the handset, - describing in markup language further functionality of the application or a new portion that is to replace an existing portion of the application,

- loading the further functionality of the application or replacing the old portion of the application with the new portion by using the means for executing applications .

[0014] In a preferred embodiment the markup language is provided with extension elements for carrying information related to the further functionality or to said new portion. Advantageously said extension element is an import element to be imported in the application or in said new portion.

[0015] Preferably the extension element comprises an indication of how long the carried information is to be cached.

[0016] In an preferred embodiment the mobile device is a handset. The markup language is preferably Mobile Application Markup Language.

Short description of the drawings

[0017] Fig. 1 represents a fat client.

[0018] Fig. 2 represents a thin client.

[0019] Fig. 3 represents a MAML application, wherein pages are retrieved by the platform and stored and executed like compiled code.

[0020] Fig. 4 represents a TAG element.

[0021] Fig. 5 represents an IMPORT element combined with the Cache attribute. Detailed description of the invention

[0022] The present invention aims to provide a method for extending applications on a mobile device, wherein the advantages of fat and thin clients are combined by specifying markup and scripting languages. Markup language describes static visual elements, whereas a scripting language describes events and behaviour. [0023] The invention is an environment for interpreting and rendering this XML and for storing it for reuse and modification.

[0024] In a preferred embodiment of the present invention the markup language used is Mobile Application Markup Language (MAML) . MAML is an extended subset of Wireless Markup Language (WML) . It supports the entire WML specification and extra tags to support gaming and enterprise mobile business applications. Implementations of MAML are themselves mobile applications which interpret properly formatted MAML documents and render them according to the specification. MAML provides the standard browsing, user input and events of WML plus elements from which enriched user interfaces can be built, such as sprites, shapes, polygons, animations, visual clock and date elements, gauges, scroll bars and an extended event and scripting model for executing advanced business logic. Additionally the variable model described in WML is extended to provide for persistence across multiple sessions .

[0025] The value of MAML is not dissimilar to the value of any other rendering language - it provides non- technical content providers an environment in which to develop complex mobile applications without the need to create, compile and provision low-level code. It also allows for remotely extending applications. [0026] An application developed using some markup language (e.g. MAML as above described) is preferably provisioned to the handset with some minimum functionality, described e.g. in XML (MAML) files embedded in the application package. In a MIDP JAR file (whereby MIDP means Mobile Information Device Profile, a specification for the use of Java on e.g. mobile phones or PDAs and JAR stands for Java ARchive) , for instance, these would be treated as resources, just as most MIDP applications reference internal images or other resources. This could well be the end of the application life-cycle and at this point has already afforded the developer an accelerated time-to- market by allowing the application to be defined entirely in XML. [0027] Like any other application defined in XML, MAML applications can be hand-coded (a simple text file) , developed in a graphical environment which maps application elements to MAML tags and attributes, or generated from application code on a server, like dynamic web sites generated by J2EE, .NET, Perl, etc...

[0028] As shown in Fig.3, the application can connect to a remote server (which is like any other web site, except that it serves MAML rather than HTML or WML) and download more MAML/MAML Scripts. This process is exactly like that of any other browser except that the downloaded pages can replace those already embedded in the application, allowing any modification to the functionality of the application. However new pages need not replace existing functionality but can still be permanently persistent, resulting in extended functionality.

[0029] All or portions of these pages may be cached so that at the developer's discretion some functionality can remain dependent on the remote server. [0030] The platform which renders the markup language and executes scripts in that language, is an application that can run on a mobile phone or PDA and supports the entire specification. It could be developed and installed as any other fat client.

[0031] Several additional features like the TAG element and caching functionality can be provided in order to enhance the performance of the markup language. Said TAG element and caching functionality are then supported by the platform that renders the markup language.

[0032] The TAG element (see Fig.4) is of exceptional importance to the core ability of the markup language to provide extensible functionality because it defines a unique model for extending the existing specification itself. Current markup languages are agreed standards and browsers which implement them support the defined tags and no more. The TAG element is a model for extending the markup language on the fly, allowing developers - without writing or compiling low-level code - to create and combine elements with specific functionality which otherwise behave as though they are part of the specification. Fig.4 shows in step a TAG, wrapping executable MAML, that is downloaded by the platform. In step 2 the definition of the new tag is stored by the platform. Next (step 3) the TAG is referenced by entirely new MAML. In step 4 the platform employs the previously stored definition to render the TAG.

[0033] The concept of a compilation unit is universal to software engineering. Regardless of the language, environment or platform at some level an application is represented as isolated units of code which provide some or all functionality of an application. In Java and C these are Class files. The TAG element is functionally analogous to a compilation unit, like a Class file. It wraps other elements and script fragments and listens for specific system level events, like onCycle, onLoad, onExit and so on and passes its attributes along to instances of the tags it contains. Any script executed within a TAG operates on the attributes of the actual instance of the TAG. The name attribute of the TAG is introduced by the application as though it were part of the MAML language and can thenceforth be used like any other tag. [0034] An example of a TAG element is given for a case wherein MAML is used as markup language. The following MAML fragment

<scπpt> function getMail() {

Platform. setVar (this . inbox, Platform. post (this . smtpServer) ) ;

}

</scπpt> <table border="$ (this .border) " fg="$ (this .bg) ">

<tr>

<td>

$ (this . inbox) </td> </tr>

</table> </tag> could be referenced anywhere else in the same application to provide a fully-functioning email inbox: <inbox smtpServer="smtp: //inbox. microscopictopic . com: 1200" border="l" fg="blue"/>

The above code would display any mail returned by a post request to the smtp : //inbox .microscopictopic . com: 1200 within a blue border one pixel wide. The ^Λcache' attribute of the TAG element dictates the scope of the newly created element; 'permanent' indicates that it should always be available to all MAML executed in the host application. This example demonstrates that the TAG element is a fully realised compilation unit. [0035] An IMPORT element (see Fig.5) can be provided defining a URL that should be imported in its entirety into the parent page. The cache attribute of the IMPORT element indicates the scope against which to hold the page in cache. It is important to note that pages are cached independently - regardless of a page is imported or loaded directly it is cached as a separate entity. This also means that cached pages can import pages which are not cached, allowing maximum flexibility in combining static and dynamic content.

Fig.5 illustrates in step 1 how an MAML page is downloaded, displayed and cached. The key against which the page is cached is the URL of an existing resource. The next time the application renders the resource or executes scripts within that resource it uses the newly cached page in place of the original, hence extending or modifying the existing application (step 3) .

[0036] The CACHE attribute indicates whether and for how long fragment of markup code should be cached. The importance of the CACHE attribute to the extensibility of MAML applications cannot be understated. All functionality in MAML is defined in files which can be added, replaced or removed at any time after installation of the application by use of the CACHE attribute, making it core to the extensibility feature. It can be applied to pages (top- level MAML or WML tags), imports (IMPORT) and image (IMG) and has roughly the same effect on all three. Valid values for the CACHE attribute are 'session' , 'permanent' and 'replace' . 'Session' means the element should remain in cache until the application exits. 'Permanent' means that the element should always remain in cache. 'Replace' means that the current element should replace the element currently cached under the same key and take on the same scope . Note that the optional attribute CACHEKEY can be used in conjunction with CACHE and ^Λreplace' to remotely update applications by replacing MAML elements with new ones from a server. [0037] MAML is intended to describe most generic applications that can be deployed to mobile phones and PDAs, however the model could easily be applied to more specific functional requirements, such as:

- An investment banking application which implements specific markup tags for shares and market activities, such as buying, selling and reserving positions. The bulk of the functionality - such as login and data- entry screens - could reside locally on the device and market events could be executed remotely on the server.

- A remote patient monitoring markup language could describe download the static data of a particular patient once (name, age, sex, etc.) and the application could poll a remote server regularly for changes to the patient's condition.

- An online gambling markup language could describe fixed elements such as matches, players, spreads and odds which would reside locally to the application. Changes to the player's position - bets placed, won and lost - would be recorded to both the server and maintained locally as changes to the resident markup code .

Claims

1. A method for extending the functionality of a mobile device, said mobile device being provided with a means for executing applications, comprising the steps of - describing an application in markup language,

- loading said application onto said mobile device, describing in markup language further functionality of said application or a new portion of said application to replace an existing portion, - loading said further functionality of said application or replacing said old portion of said application with said new portion by using said means for executing applications .

2. Method for extending as in claim 1, wherein said markup language is provided with extension elements for carrying information related to said further functionality or said new portion.

3. Method for extending as in claim 2, wherein said extension element is an import element to be imported into said application or said new portion.

4. Method for extending as in claim 2 or 3, wherein said extension element comprises an indication of how long said carried information is to be cached.

5. Method for extending as in any of the previous claims, wherein said mobile device is a handset.

6. Method for extending as in any of the previous claims, wherein said markup language is Mobile Application Markup Language.