Patent Application
20080109528
1. Field of the Invention
This invention relates to a method of providing content to a Wireless Computing Device. The kind of content that can be provided includes ringtones, wallpapers/pictures, screensavers, realtones/truetones, full music downloads, video, SMS & MMS alerts, and mobile games.
2. Definitions
The definitions used in this specification are as follows:
Mobile Telephone: A type of telephone which is connected to the telephone network via wireless technology through the air rather than through a physical wire or other physical connection or form of cable.
Mobile Phone, Phone, Mobile, Mobile Handset or Handset: A type of Mobile Telephone.
Mobile Network: A network which provides wireless connectivity for Mobile Telephones so that they can operate and provide functions such as making telephone calls or accessing network-resident data or services.
Mobile Network Operator (MNO): A company or organisation which operates a Mobile Network and the subscribers or users who use Mobile Telephones on that network.
Global Mobile Network or Mobile Phone Network: The sum of all Mobile Networks operated by Mobile Network Operators in the world.
Wireless Network: A network which provides wireless connectivity to client computing devices. Such a network includes Wi-Fi WiMAX and the Global Mobile Network.
Server: A networked computing device which exists to provide networked application services, features and functions such as information supply, database search and transactions to one or more client computing devices which make connection to it and make requests for services from it. There are generally many clients to each server and each client is usually of a smaller size and of smaller computing capability than the server.
Services: The networked computing services, features and functions which are typically provided by a Server to one or more network connected client computing devices. Services include information supply, database search and transactions. Such services are architecturally practical to deploy centrally in the network and typically impractical to deploy on a client computer due to the client's size and power.
Client: A computing device connected to a network delivering the features and functions of a network-centric application to the user or consumer of the application. The Client typically connects to a Server and requests Services.
Network Application: A type of application or service that is network-centric, in that it is delivered by a combination of software running on a Client performing the function of the application's interface to the end user or consumer, supported and complemented by Services provided by software on a Server which are accessed by the Client over a network.
Wireless Computing Device: A type of Client which connects to the network via a Wireless Network. Such devices include Mobile Telephones, Personal Digital Assistants (PDAs), Games Consoles (e.g. Sony PSP) or other wirelessly network connected client computing devices. The type of the Wireless Computing Device is further defined by it's Manufacturer, Make, Version, Operating System, Firmware Version.
Wireless Device or Wireless Client: A type of Wireless Computing Device.
Software Application The Client software application which is to be delivered over-the-air to, or pre-installed on, the Wireless Computing Device.
Software Components Individual units of software which form the components of the Software Application which is being customised for the Wireless Computer Device and part of the Device Adaptive Architecture (DAA) software library.
Mobile Content: Digital files and data representing electronic products used by, consumed, played, viewed or rendered on Mobile Phones. Examples include ringtones/ring tunes, wallpapers/pictures, screensavers/animations, realtones/truetones, full music downloads, video, SMS & MMS alerts, mobile games, and many other current and emerging Mobile Phone consumable entertainment and information products.
Metadata: Individual items of data or collections of data, potentially hierarchically related, which describe the attributes or behaviour of Wireless Computing Devices, Wireless Networks, Software Components, Network Applications or Mobile Content.
3. Description of the Prior Art
At the time of writing there are more Mobile Telephones in the world than there are personal computers (PCs). The nature of a Mobile Telephone is that it generally spends more time switched on and in it's owner's presence than a PC. These Handsets are increasingly powerful computers with rich functions and capable hardware which, given that they are connected to the world's vast Mobile Networks and through these to the Internet, provide a very compelling platform to deliver a significant number of Network Applications to their users.
The Global Mobile Network is one of the first examples of a network where a vast number of Wireless Computing Devices with widely different operating systems and platforms are connected to the network and can deliver Network Applications. The PC dominated Internet network differs significantly from the Global Mobile Network because there are a much smaller number of Client operating systems and platform variants. Even though the Clients on the Internet are extremely powerful computing devices they are predominantly similar to each other given the dominance of a small number of operating systems from companies such as Microsoft and Apple. The effect of this is that if one builds the Client component of a Network Application for the PC Internet on just Microsoft Windows, or perhaps the next one or two most prevalent Client architectures, then one can deploy a similarly behaving Network Application across a very high percentage of existing devices and therefore have a technically and potentially commercially viable product. Moreover in the PC Internet world it is possible to target similar groups of users very effectively by choosing to build the Client part of a Network Application using a particular operating system or platform. For example if one were to build a Network Application for Financial Directors of companies the vast majority of these could be supported by building Client software compatible with Microsoft Windows.
The same is not true of the Global Mobile Network. There are very many more Wireless Client operating systems and platform variants than exist on the PC Internet. As a consequence of this and also because of the extremely fast rate of development of functional enhancements and feature additions to Mobile Phones, the devices vary a lot more in their behaviour as do the operating systems and platforms used to access and control this behaviour. In addition to this it is not feasible to identify and target a group of users by their role who use the same or very similar Wireless Devices.
Generally speaking, the more Wireless Clients a Network Application can operate on, the greater the financial opportunity for the provider of the application as more customers can be reached. For this reason it is particularly interesting to providers of such Network Applications to be able to deploy software on the most Clients possible.
Network Applications and services are commonplace in the networked PC world, and represent very big business opportunities due to the size of the Internet and thus the potential number of users. There are a small number of ways in which the software implementing the Client part of an application is currently architected. These are as follows:
End user computer devices (e.g. PCs) which can act as Clients to a Network Application generally provide a platform on which software programs can be run. These platforms are typically the computer's operating system (e.g. Microsoft Windows, Linux, Mac OS, Unix, etc) or a platform layer on top of the operating system which allows software programs to be run (e.g. Java). Custom Built Applications are built from software which can be run on one of these platforms. The software in the application makes calls to the platform and the platform in turn performs a service for the application (e.g. drawing a window or sending information across the network).
These platforms typically have a very rich set of features which are available to the Custom Built Application, in fact they normally offer all the features and facilities of the computer. As such Custom Built Applications can provide very rich user interfaces, wide-ranging functionality and can normally do anything that the Client is capable of. Examples of such applications (though not so network focused) are the well known Microsoft Office tools such as Word, Excel and PowerPoint.
Due to the dominance of PC platforms, such as Microsoft Windows, it is possible to develop a Custom Built Application and have it run successfully on many of the world's PCs. However, if the application is required to run on more than one platform a port of the application is required to that platform or if the platform is significantly different a full rewrite of the application is required. Porting and rewriting applications is a very significant and costly engineering exercise, the effort required increases with each additional feature in the application.
In summary, Custom Built Applications provide the richest possible feature set and best interface for the end user experience but these applications are only viable on a relatively small number of platforms due to the engineering effort required to port from one platform to another.
The problem with this approach is that it cannot run on a new Client platform unless the Client part of the Network Application has been fully ported to the new Client platform. This is fine in the PC world where there is little requirement to port applications and in any case there are few Client platforms and very few new Client platforms, but the Global Mobile Network presents an problem of immense complexity by comparison with its myriad existing operating systems and types of Wireless Device and a constant flow of new Client devices coming into the market at an unprecedented rate.
The World Wide Web (WWW) was originally designed as a network-based inter-document referencing and navigation system which allowed users to browse between links from one document to another potentially on different machines, potentially on different sides of the world. This technology was facilitated by a standard mark-up language in which documents were written, called hyper-text mark-up language (HTML), and the HTML browser. HTML browsers are software applications which run on a user's Client displaying HTML documents and allowing navigation between documents using HTML hyper-text links.
The technology became very popular because HTML browsers were soon written for most client computers. This meant that all networked computer users had access to the same ever extending world-wide library of information and documents. It also meant that people who wished to publish information need only mark-up the document once in HTML to have it accessible by the vast majority of networked computers in the world.
As time went on, users demanded more and more from this WWW technology and many more features were added. New features included the ability to add small amounts of software embedded into the pages being displayed (applets and scripts) which in turn allowed more functional applications to be built taking advantage of more of the Client's capabilities. Other features included forms for data collection and submission across the network of data collected to software Services resident on Servers.
The end result was that quite capable Network Applications could be deployed on a WWW Server and the vast majority of the world's Client computers using browsers were able to access and operate the application. This represented an opposite extreme to the Custom Built Application in that although WWW Applications could not be used to build an application as functionality rich on the Client, it would however run on the majority of the world's PC Client computers without having to be ported to each different platform.
The compromise inherent in this type of WWW Application is that the HTML browser is the platform through which the Client part of the Network Application accesses the capabilities of the Client. However the HTML browser has access to significantly less features and commonly significantly less powerful features of the Client operating system. In consequence the range of features which can be implemented in a WWW Application are fewer and less rich than a Custom Built Application. In addition because HTML is a standard to be commonly interpreted by all HTML browsers, the features available to a WWW Application are the features which are common to all Client platforms. This presents a problem in the Wireless Mobile Network where the features of Mobile Clients are evolving so rapidly that not only are they not common but it is desirable to deploy Network Applications which use features that are not common across different Wireless Devices including the newest features.
There are methods by which WWW Applications can deploy richer features and more advanced Client specific application code, for example by embedding Microsoft ActiveX or Java code. This has the effect of making the application a combination of a WWW Application and a Custom Built Application or a WWW Application and a Write Once, Run Anywhere Application (depending on the nature of the embedded code) and have the combined issues and limitations of two of these types of application.
Write Once, Run Anywhere Applications are meant to provide the best features from the worlds of Custom Built Applications and WWW Applications. As their name suggests, the application is defined only once yet the same consistent and functionally rich application will run on many platforms without having to port the application. This is achieved in one of two ways:
i) Virtual Machines'
A Virtual Machine is an intermediary software platform which sits on a Client's own platform (e.g. operating system) and runs the Write Once, Run Anywhere Application. This is achieved because the application software is able to be read line by line by the Virtual Machine and the instructions are interpreted on-the-fly into corresponding native calls to the Client's platform.
The end result of this approach is that if a Virtual Machine is written for every significant Client platform then one is able to develop a single computer program compatible with the Virtual Machine which can produce a user experience much functionally richer than a WWW Application (as there is access to more of the Client's platform features) without having to port the application to each Client platform. An example of this technology is Sun Microsystems Java.
The problem with this approach is that if the Client software has any internal complexity (e.g. is scientific in nature, makes use of software threads, has near-real-time graphics or any other real-time properties) then a like performance of the application becomes much more difficult to ensure across multiple different types of Clients. This is the reason that a mobile Java Game never runs on all Java Clients but only a small subset which has been specifically tested by the originator of the game to ensure that the user experience remains the same. This is why programmers often say “Write Once, Debug Everywhere”. This problem can never be obviated using the Virtual Machine technique.
ii) ‘Pseudo Code Compilers’
Pseudo Code Compilers achieve a similar outcome using a different method. Similar to Virtual Machines, the software representing the application is written once and is represented in a high level form which can be interpreted by other software. However rather than deploying a Virtual Machine platform on every target Client which interprets the application code on-the-fly, before the application code is sent to the Client a compiler reads through the application and builds (compiles) a native application which will run directly on the Client's operating system platform.
This way a single representation of a rich featured application can be developed and it can be run on any Client for which a compiler exists. An example of such a system is Sybase's PowerBuilder (which incidentally can also implement a version of the Virtual Machine architecture using it's ‘P-Code’ technology).
The problem with both these approaches are identical to that of Custom Built Applications, except that in these cases it is the compiler or the interpreter which must be re-written for every target Client platform. Similarly, that presents no great problem in the PC world where there are few operating systems but it presents an almost insurmountable hurdle in the Mobile Network world where you cannot deliver an application unless you can first deliver the compiler or the interpreter. It's an inescapable catch-22.
In summary of these three methods, PC Network Applications can be developed as:
In the world of Mobile Phones the environment is significantly different. The major differences are as follows:
In order to maximise the financial potential of a Network Application delivered using Mobile Phone technology the requirements are:
Most of the world's Mobile Phones do have a Wireless Application Protocol (WAP) or eXtended HTML (xHTML) browser installed. These browsers and associated document based mark-up languages are directly comparable to the architecture of the WWW Application. Using this Mobile Phone technology it is possible to develop a Network Application which will run on neatly all the world's Handsets. The problem is that, similar to the restrictions of WWW Applications, WAP & xHTML can only utilise a very small subset of each Mobile Phone's capabilities. It is not possible to develop the most functionally rich user experience using these technologies as they don't have access to the most advanced features of the Phone.
A significant proportion of Mobile Phones now come with a Client platform onto which applications can be deployed. Most significantly these include Java (or Java 2 Mobile Edition—J2ME), Symbian and Brew. Java is the most widely adopted of these technologies but, like Symbian and Brew, applications built with the technology still have serious issues and limitations. There are nearly two billion instances of thousands of different types of Phones on hundreds of different Mobile Networks. This presents the Java platform and Client application building in general with the following problems:
This means that although software language consolidation platforms like Java can be available on a very large proportion of the world's Phones and provide a useful programming language for deploying applications that can use the advanced features of a Phone to produce a rich user experience, in practice every different Phone requires a custom built application to navigate and alleviate their many differences.
There is no previously existing technology, platform or method that has ever had to meet the challenge of rapidly and efficiently delivering the most functionally rich applications to the most Wireless Computing Devices optimised for each device.
Because all Phones differ in these ways to some degree the only way to deliver an application using the most advanced features of each Phone to the most Phones is to deliver a custom built application for each different Handset. If one used a traditional approach to this problem, whichever approach was used, the net result would be an inordinate and unmanageable amount of porting. This would end up with a new “stream” of code used to build the application for each new Phone. This is very expensive and maintenance becomes more and more difficult the more streams of source code you add. The net result is that it is prohibitively expensive to build an application where the source code for the application has been tuned for each device. It's clear that a new approach is needed.
A feature of current Mobile Content distribution is that users are generally just given a list of that Mobile Content on their Handsets (e.g. a list of downloadable items, such as the names of different ringtones, wallpapers etc.); from this menu list, a user can select the item he wishes to download, causing a message to be sent to the Server that hosts the Mobile Content. The Server then returns the requested item. This limited model is dictated in large part by the fact that the Content distribution model typically relies on WAP sites and the kind of interactions possible between a WAP browser on a Handset and the Server hosting the Mobile Content. The present invention enables more complex interactions relating to Mobile Content to occur.
A customised Network Application suitable for a specific type of Wireless Computing Device is automatically generated and sent to that Device. The Application is able to download a preview of content on demand by an end-user from a Server that stores the content and to play the preview of the content. It can also display an option or function that enables the end-user to download and buy that content from the Server. Attributes for that type of Wireless Computing Device are defined as meta-data; attributes for various different kinds of Mobile Content are also defined as Metadata; the Server then determines what Mobile Content is compatible with the Wireless Computing Device by comparing the Metadata of the Mobile Content and the Wireless Computing Device.
The kind of Mobile Content that can be provided includes ringtones, wallpapers/pictures, screensavers, realtones/truetones, full music downloads, video, SMS & MMS alerts, and mobile games.
The present invention is predicated on being able to deploy a customised Network Application, as opposed to, for example, a simple WAP browser with limited functionality. Building that customised Network Application can be achieved in one implementation by using a Device Adaptive Architecture (DAA), which will be described in detail.
Further details and aspects are defined in the appended Claims.
This Detailed Description is divided into 2 sections. Section 1 deals with the Device Adaptive Architecture (DAA). Section 2 deals with the Mobile Content Portal; it is the latter that is the specific subject matter of this invention. However, an optimal implementation relies on the Device Adaptive Architecture.
The principles of the DAA solution to the challenge of building a platform for deploying the most functionally rich Network Applications to the largest number of Wireless Client Devices in the most efficient manner are:
The first thing to do to support a new Handset is to acquire the Handset for the purposes of commissioning. A simple generic test application is downloaded to the Handset which identifies the core packages available on the Handset platform. Using this information a test application aligned with the Handset's capabilities is dynamically selected. This test application is downloaded to the Handset to electronically investigate the capabilities and features of the Handset and also include tests of historic bugs which were found on other Phones. This test application accumulates the results of it's tests as a set of Metadata representing many of the Phone's attributes and idiosyncrasies. This Metadata is then written into a data store and related to that type and build of Phone (see Appendix 1—Handset Metadata).
Manual inspection and testing of the various Handset capabilities and idiosyncrasies is then carried out, the results of which are similarly stored in the data store against the Handset supplementing the initial data set from the test application. Once all information has been retrieved and all initial tests completed there is enough data to potentially use the platform to build a custom built Software Application for this new Handset.
Various other Handset specific information which is not used in the build of the Software Application for that Handset is also collected. This information is collected for use in systems supporting the operation of Software Applications built for this Handset. For example the location of where network settings are stored on a particular Handset is recorded so that the user can be helped with Handset specific guidance at the appropriate point in the application. See ‘User Assistance Properties’ in Appendix 1-Handset Metadata.
At the heart of the Device Adaptive Architecture (DAA) is the engine which dynamically builds a Software Application for each Handset, or potentially Handset/Mobile Network combination. The DAA reads the Metadata representing the capabilities of a Handset then cross-references these capabilities with the Metadata describing the capabilities and configuration options of the Software Components in the library, see Appendix 3—Examples of Mapping Handset Metadata to Software Components. The DAA then combines the selected Software Components configured in the manner required into a Client Software Application custom generated for that Handset and potentially Mobile Network combination.
This then represents a Software Application customised for this particular Handset which is actually a platform for executing applications rather than a functional end user application itself. In other words this exercise has dynamically and automatically built an application execution platform which is downloaded to the Handset and requires an application, itself defined in Metadata, to actually implement an end user application or service, see Appendix 4—End User Application Metadata and Mark-up. This Metadata describing the application is then added to the generated application execution platform software and the end result is a software program which when installed and run on the Handset implements the end user application.
Each time an Software Application is built for a particular Handset an instance of this application is stored in the archive of builds. The archive contains 100s of different builds for each version of the Software Application as an historic record. Historical builds can also be reproduced at anytime by simply re-running the DAA's dynamic build process using the Handset Metadata and the Software Component versions and associated Metadata valid at that time.
This candidate Software Application build then goes through a human based system testing process to confirm that the application operates correctly on the new Handset. This sometimes results in full success, sometimes it results in a requirement to change the Handset Metadata, rebuild the application and retest and sometimes it results in some of the Software Components having to go into engineering for maintenance or new Software Components to be built followed by rebuild of the application and subsequent retest. Ultimately a fully functioning Software Application is available for this Handset and when it has passed the system test it is then promoted to the production system for live use by end users.
The particular Mobile Network to which a Handset is connected can also influence the build of the application for that Handset. Understanding MNOs and their network configurations in detail is just as important to the DAA as understanding the Handsets in detail, so that the correct build for an MNO can be delivered to the Handset if required. See Appendix 5—Network Operator Metadata for details.
When a user's device connects to the system to request the download of a Software Application over the network the Handset informs the system of its User Agent Profile (UAProf). This describes the phone manufacturer, model and firmware. Sometimes the Software Application required by a Handset has to also be customised to the Mobile Network on which the user is connected, sometimes even the payment contract they have with the MNO (e.g. pre-pay or monthly contract). In this situation the Mobile Network on which the Handset is connected is detected either by the MNO information found inside the requesting SMS, the route the SMS came through, the IP address of the MNO gateway through which the request is being made, via an MNO core network lookup (e.g. SS7/HLR if available), Phone number (MSISDN) lookup against MNO number range assignations and ported number databases or by simply asking the user in the screens prior to download. The system uses the most reliable method made available to it. The UAProf, potentially combined with details of the MNO and payment contract type, is the key to choosing the correct, previously generated application to be presented for download by the connected Handset.
For the purposes of implementing end user billing or end user tracking, and potentially end user support, it is important to be able to uniquely and separately identify every instance of a Software Application downloaded by every Handset and the Mobile Telephone Number (MSISDN) of the Handset which that Software Application instance is installed on. In order to do this the DAA builds a unique reference number into the Software Application before or at the time of the download. This reference number is related in the Server data store to the user's MSISDN which was acquired from the end user whilst they were requesting the Software Application (e.g. from the SMS requesting the application or the MSISDN collected on the web form, etc). When the now Client-resident Software Application subsequently makes a request for Services from the Server it automatically provides the unique Software Application instance ID. Should the MSISDN be required then the unique instance ID can be used to look it up.
We have discussed how a Software Application automatically generated by the DAA is custom built for each Mobile Telephone as identified by manufacturer, device type and potentially firmware (embedded device software) version or Mobile Network to which the device is connected. When a device connects to the Server for the purpose of acquiring a Software Application the Server determines these variable attributes and selects the application appropriate for this Phone.
However there are significant commercial opportunities associated with having such Software Applications pre-installed on users' Phones such that they are present on the Mobile Device at the time users acquire their Handset.
There are typically two places where applications can be pre-installed on a Mobile Phone before the user acquires the Phone. The first is in the manufacturing of the device by its vendor (or manufacturing subcontractors). The second is at a device configuring/provisioning facility in the supply chain to the end user (either a Mobile Phone distributor or retailer).
In either of these situations the Mobile Phone is, or can be, at some point connected to equipment which provisions (controls the setup of) the Mobile Telephone. At this point our systems interface with that provisioning equipment such that it has access to versions of any Software Application which is to be pre-installed on the Handset.
In this way the appropriate Software Application will be made available to the provisioning equipment to enable it to be placed on the Mobile Device. However since the application installed on the Handset might not be able to access the MSISDN of the Mobile Phone, this is different to providing an unique Software Application to every single device with an inbuilt unique instance ID reference inside the application which can be transmitted back to the server and there related to the user's MSISDN for the purpose of billing (for example). Instead the application will be common to all Mobile Phones which share the same vendor, model, firmware and potentially Mobile Network to which they are/will be connected. Therefore this relationship to MSISDN needs to be made retrospectively after the Software Application has been installed on the Mobile Phone. This is done as follows:
Software Applications built using this Device Adaptive Architecture appear very responsive to the end user. The reason for this is that the Metadata and mark-up language used to define the end user application (see Appendix 4—End User Application Metadata and Mark-up) is stored locally on the Client in the Software Application as data. This means that the application execution platform generated for this Client by the DAA uses this local resource to run the end user application and thus the speedy appearance.
Software Applications which display lists of content such as news or ringtones can utilise this facility to cache their content structures inside the end user application Metadata definition. This means that when the application is run by the end user it will appear very fast because it doesn't need to connect to the Server to access the list of content.
The Client Software Application is able to request an update to any element of the Metadata representing the end user application, meaning that the application is completely updatable over-the-air. This ranges from a simple request to update a list of content in one menu, a request to update all the content in the end user application or to update the entire definition of the end user application itself, effectively potentially changing the entire nature of the Software Application.
The end user application is packaged in data files or decks that define the menus, sub-menus, look & feel elements, screens layouts and any content references in the application. Screens are defined in XML using XML references to resources and content in those screens. The screen definitions are stored with the content and presentation resources and converted to binary for packing with the Software Application. Decks can be referred to from other decks. If the deck referred to is required but is not on the Client it will be requested from the Server. Each deck is loaded from a data stream that is either a file stored in the Software Application, a record stored in local memory or a file streamed from the Server.
Each deck or item in a deck has an optional expiry date such that it can be expired and a fresh version downloaded from the Server instead of the local deck being used. This is effective for implementing features like charts or daily changing news. Whenever a user uses part of an end user application that utilises a deck where an expiration date is set and passed, the update mechanism from the Server runs.
There are different types of deck used to store different data depending on the frequency of expected update, and the space available in each location on the Handset. Items in a more dynamic deck can override those in a less dynamic deck. (For example configuration in the system deck stored in the application can be superseded by later changes applied to the deck streamed from the Server).
The Server also has the ability to override any deck in the application, this can be performed when a Software Application makes a connection to the Server. This effects Server push end user application refreshing or updating. The Server will provide an update to the element by referencing the element on the Client and providing the new element.
Where a Software Application connects to the Server via the network to download a resource and there is a wait whilst that resource is downloaded, the Client application can display animations and progress bars. The animations are for the purpose of providing some entertainment for the eyes and reducing the perceived wait. The progress bar provides some indication of the progress. Where there are no animation libraries on the Client platform these libraries are provided in the Software Application. They are built using the ability of the Client platform to deploy using X/Y coordinates full or partial pictures to parts of the Client's screen. When combined with timing between these image plots the affect is one of animation.
Included as part of the Metadata recorded against Handsets and Mobile Networks is information pertaining to the appropriate network connection settings for a particular Mobile Network, the mechanism for delivering these network settings over-the-air to a Handset and the likelihood of whether that Handset/MNO combination is likely to require settings.
Using this information the platform is able to automatically attempt to provision communications settings to the Handset when it appears that they are not present or offer the end user to opportunity to initiate sending settings to themselves. It can also provide instructions on any additional manual configuration that the settings require from the end user once they have been delivered.
All requests made by the Client Software Application to the Server are recorded in an audit trail on the Server. All actions on the Client Software Application marked in the end user application Metadata definition as requiring tracking are communicated to the Server for the similar purposes of recording in the audit trail. This means that very sophisticated customer relationship management can be effected because of the rich data collected about customer usage. For example this very rich usage data can be viewed as a set of system operations key performance indicators.
All errors in the Client application are recorded by the Client Software Application and passed to the Server at the next opportunity when the Client successfully communicates with the Server. This allows for a detailed picture to be built up of how the Client Software Application is performing in the general Handset populace, and can be used to look for trends in any sensitivities Handsets present. This information can also be used to identify specific newly released Handset firmware versions which have introduced a bug which needs handling with an adjustment of the Handset Metadata.
The system includes a full service management suite of graphical tools which allows Omnifone's partners to manage their own systems. These tools are windows on the various configurable Metadata controlling an end user application. Simply by changing the Metadata elements of the service, e.g. application flow or content structure, the nature of the application can be changed.
All interaction between the Client and the Server are recorded and the system therefore knows the entire volume of data traffic passing between the Client and Server. This is relevant when network data usage has a cost associated and we can work out what the usage level has been and subsequently what the costs should be given that we have a total number of bytes transmitted to and from the Server by any Software Application.
The Server monitors for the use of new Phones against the system that have not yet been seen by the system. If a new Handset attempts to download a Software Application but the platform cannot find a match, the system will notify the System Administrator. In addition a count will be kept of requests from each device like this so that the System Administrator can see which devices are the most important to commission next based on number of potential users.
The Server implements a ‘Send to a Friend’ feature that can be easily added to a Client Software Application. When used, it displays a Send to a Friend option on the Handset's menu. When selected the user can enter a friend's MSISDN, sometimes via their Phone's address book if allowed, and an optional greeting. The utility tells the Server to send the application to the specified friend. This is done using a technique like WAP push or MMS.
The Software Application allows the display of advertising messages broadcast to the user base of an existing end user application allowing all or a subset of users to be targeted for receiving advertising messages via the Software Application. The advertising message is a message which is delivered as a Server push and is splashed on the appropriate screens. This is facilitated by the flexibility described as available to the Server for changing the end user application by effecting a Server push.
DAA is not just appropriate to delivering applications to Mobile Phones (or indeed Wireless Computing Devices). It is appropriate to situations where an application is required to be built for and delivered to a large number of Client computing devices (including non-Wireless Client computing devices), where:
Given that the Device Adaptive Architecture is available and the Metadata is present which allows Software Applications to be built for a large proportion of the world's Mobile Handsets, then some very appealing mass consumer Network Applications become possible to build. We describe here one such Network Application which contains many unique and inventive steps and becomes commercially viable only when it can be built for and distributed to a large proportion of the world's Mobile Phones.
This implementation of the invention is a Network Application for the Mobile Phone Network that allows users to browse, preview, buy and enjoy Mobile Content through a Client Software Application which provides a rich user experience able to utilised the advanced features of each Mobile Phone and run on the most Mobile Phones. The Mobile Content is stored on the Server and is accessed from the Wireless Computing Device by using the Network Application. The server itself is a portal of that Mobile Content. We shall refer to this Network Application as the Mobile Content Portal Software Application.
The features of the Mobile Content Portal Software Application include the following:
In addition to a full range of Mobile Content appropriate for a given Handset, the Mobile Content Portal also supports the sale of the following products and services.
A convenient method of billing a user is to have the server send the user one or more premium SMS messages which terminate at the mobile device (mobile terminated, or MT) which amount to the total of the bill required to purchase an item of content purchased through the Mobile Content Portal. Whilst this is convenient, in order to effect it, the MSISDN of the Mobile Telephone is required but some methods of delivering a Software Application to the Phone do not allow the MSISDN to be accessed by the Client application—e.g. Java. In this situation our Mobile Content Portal does the following:
Other billing features include:
This section contains details of the type of Metadata collected for each Handset during the Handset commissioning phase. The Metadata is grouped logically and described. Various examples are provided of how the values of the Metadata can vary from device to device.
The Metadata collected to enable the commissioning of a Handset and the subsequent delivery of a rich application to Handsets is subject to constant change. This is due to new features and functions being released in Handsets and the consequential need to continually evolve the Metadata collected from the Handsets.
Properties used for providing user assistance throughout the platform.
This appendix lists the type and nature of Software Components in the library which are utilised by the Device Adaptive Architecture to select from in the build of an application for a handset. These components are constantly changing due to the constant evolution of Handsets and the subsequent requirement for new and modified Software Components.
Core handset components are listed below:
Each component has several variants. Typical examples are shown below:
Each component/component variant has several Sub-Components which can be controlled by different properties. Examples are shown below:
Any of the Software Components in the library can be associated with any number of device properties. The association with a property may be based on any of the following tests:
Some examples of how these properties are mapped to library Software Component are given in this section.
Some Software Components, once included, are further tuned according to the value of device Metadata properties. For example:
Provided below are examples of screen definitions for end-user applications built on top of the Device Adaptive Architecture. These examples show the three core types of screen—the form, the canvas and the list. These eXtended Mark-up Language XML) descriptions describe the application screen in full, and show how the definition is used to control the presentation aspects of the screen, and control command-flow through the application. This is effectively the mechanism by which the Client part of a Wireless Client Network Application can be defined and built without writing software code.
Some of the specific features shown in these examples are:
The following is a XML DTD (Document Type Definition) which describes the mark-up syntax available to use when building end-user applications.
The key Metadata used within the system for adjusting behaviour and builds according to the capabilities of a particular user's MNO are listed below.
System behaviour must be adjusted to the capabilities of the Mobile Network gateway that the Handset application is communicating with. The DAA understands each MNO gateway through Metadata as set out below:
| Number | Date | Country | Kind |
|---|---|---|---|
| 0426736.5 | Dec 2004 | GB | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/GB05/04662 | 12/6/2005 | WO | 00 | 7/10/2007 |
