U.S. patent application number 11/720894 was filed with the patent office on 2008-05-08 for method of providing content to a wireless computing device.
This patent application is currently assigned to OMNIFONE LIMITED. Invention is credited to Mark Stephen Knight, Michael Ian Lamb, Robert John Lewis, Stephen William Pocock, Philip Anthony Sant, Mark Peter Sullivan.
Application Number | 20080109528 11/720894 |
Document ID | / |
Family ID | 34073237 |
Filed Date | 2008-05-08 |
United States Patent
Application |
20080109528 |
Kind Code |
A1 |
Knight; Mark Stephen ; et
al. |
May 8, 2008 |
Method of Providing Content to a Wireless Computing Device
Abstract
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 Metadata; attributes for various
different kinds of mobile content are also defined as Metadata; the
Server then determines what content is compatible with the Wireless
Computing Device by comparing the Metadata of the content and the
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.
Inventors: |
Knight; Mark Stephen;
(London, GB) ; Lamb; Michael Ian; (London, GB)
; Lewis; Robert John; (London, GB) ; Pocock;
Stephen William; (Egham, GB) ; Sant; Philip
Anthony; (London, GB) ; Sullivan; Mark Peter;
(Birmingham, GB) |
Correspondence
Address: |
SYNNESTVEDT LECHNER & WOODBRIDGE LLP
P O BOX 592, 112 NASSAU STREET
PRINCETON
NJ
08542-0592
US
|
Assignee: |
OMNIFONE LIMITED
London
GB
|
Family ID: |
34073237 |
Appl. No.: |
11/720894 |
Filed: |
December 6, 2005 |
PCT Filed: |
December 6, 2005 |
PCT NO: |
PCT/GB05/04662 |
371 Date: |
July 10, 2007 |
Current U.S.
Class: |
709/217 |
Current CPC
Class: |
G06F 8/71 20130101 |
Class at
Publication: |
709/217 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Foreign Application Data
Date |
Code |
Application Number |
Dec 6, 2004 |
GB |
0426736.5 |
Claims
1. A method of providing content to a Wireless Computing Device,
comprising the steps of: (a) automatically generating a customised
Network Application suitable for that type of Wireless Computing
Device; (b) deploying that Network Application on that Wireless
Computing Device; (c) the Network Application downloading a preview
of content on demand by an end-user from a Server, the Server
storing the content; (d) the Network Application playing the
preview of the content; (e) the Network Application displaying an
option or function that enables the end-user to download and buy
that content from the Server.
2. The method of claim 1 in which the mobile content is selected
from the following list: ringtones, wallpapers/pictures,
screensavers, realtones/truetones, full music downloads, video, SMS
& MMS alerts, and mobile games.
3. The method of claim 1 in which 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
meta-data; and the Server determines what content is compatible
with the Wireless Computing Device by comparing the meta-data of
the content and the Wireless Computing Device.
4. The method of claim 3 in which the Server downloads to the
Wireless Computing Device only content, or previews of content,
that is compatible with the Wireless Computing Device.
5. The method of claim 1 in which the step of automatically
generating the customised Network Application involves the
following steps: (a) automatically determining attributes of that
type of Wireless Computing Device; (b) automatically determining
which Software Components from a library of Software Components are
compatible with that type of Wireless Computing Device based on
values of the attributes determined in (a); (c) automatically
combining the compatible Software Components together to generate a
customised build of the Network Application, compatible for that
type of Wireless Computing Device.
6. The method of claim 5 in which the attributes of the Software
Components are also determined and the step of determining which
Software Components are compatible includes the step of comparing
the values of the attributes of that type of Wireless Computing
Device to the values of the attributes of the Software
Components.
7. The method of claim 5 in which attributes for that type of
Wireless Computing Device are defined as Metadata.
8. The method of claim 5 in which the attributes for different
types of Wireless Computing Device are also defined as
Metadata.
9. The method of claim 8 in which the method includes the further
step of determining attributes of a Wireless Network, to which the
Wireless Computing Device is connected, as Metadata.
10. The method of claim 9 in which the method includes the further
step of determining attributes of combinations of different
Wireless Networks and different types of Wireless Computing Devices
as Metadata.
11. The method of claim 7 in which the Metadata attributes for
different types of Wireless Computing Device define one or more of:
Wireless Computing Device identification; market information;
network configuration; physical characteristics; network
configuration; media/content capabilities; HTTP connection; SMS
communications; Java APIs and libraries; Java application security;
user interface capabilities; user assistance properties.
12. The method of claim 9 in which the Metadata attributes for the
Wireless Network include one or more of the following:
identification; openness; SMS system reliability; parent operator
ID; contract types offered; data connectivity offered; customer
contact details; typical network names.
13. The method of claim 5 in which the Software Components in the
library are restricted in functionality so that appropriate
components can be matched to any variant of any attribute of that
type of Wireless Computing Device or Wireless Network to which that
type of Wireless Computing Device can be connected or combination
of the two.
14. The method of claim 1 in which the downloaded Network
Application includes data defining the user interface and user
interaction processes for that Network application, the data being
updatable over the wireless network.
15. The method of claim 1 in which the downloaded Network
Application downloads from the Server updatable menu lists defining
available content.
16. The method of claim 15 in which the lists include lists of best
selling items or charts.
17. The method of claim 16 in which these lists have an expiration
date and, should a user enter such a list and the menu list is
found to have expired, the Network Application will connect to the
Server over the network and request an update of the latest menu
list from the Server.
18. The method of claim 1 in which the downloaded Network
Application displays an option or function that enables the end
user to buy a CD corresponding to the content.
19. The method of claim 1 in which the Network Application is
provided with the mobile MSISDN telephone number of the Wireless
Computing Device by the Server, enabling the application to
undertake mobile terminated billing.
20. The method of claim 1 in which the Server records the MSISDN of
the user's Wireless Computing Device in the Server's database and
undertakes mobile terminated billing using that MSISDN.
21. The method of claim 20 in which the Server builds into the
Network Application a unique reference number which is related at
the Server to the actual MSISDN, such that, when the Network
Application requests the purchase of an item of content by the
user, the Network Application forwards the unique reference to the
Server, the Server receives the reference and uses it to look up
the MSISDN and then uses the MSISDN for mobile terminated SMS
billing.
22. The method of claim 1 in which automated engines, responsible
for taking libraries of content from a content provider, confirm
the quality and consistency of the incoming content data and
automatically map the incoming content to the Wireless Computing
Devices with which it is compatible.
23. The method of claim 1 in which the Server understands the best
quality preview that can be delivered to the Wireless Computing
Device due to a mapping between the content types which can be
previewed on the Wireless Computing Device and a ranking of which
types have the best quality.
24. The method of claim 1 in which, when the Network Application is
connected to the network for the purposes of downloading a preview
or getting a menu (chart) update, then any element of the Network
Application can also be updated by the Server.
25. The method of claim 1 in which, when a Network Application
connects to the Server it presents a unique instance ID that was
embedded at time of dynamic build and download to this particular
Wireless Computing Device and the Server looks-up the version of
this Network Application.
26. A Network Application that is customised for a specific type of
Wireless Computing Device, the Network Application being downloaded
from a Server to that Wireless Computing Device and, when running
on the Wireless Computing Device, is operable to: (a) download a
preview of content on demand by an end-user from the Server; (b)
play the downloaded preview of the content; (c) display an option
or function that enables the end-user to download and buy that
content from the Server.
27. A content portal programmed to be able to download the Network
Application of claim 26 to a Wireless Computing Device and to
provide content on demand to the Wireless Computing Device.
28. Mobile content when provided to a Wireless Computing Device
using the method of claim 1.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] 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.
[0003] 2. Definitions
[0004] The definitions used in this specification are as
follows:
[0005] 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.
[0006] Mobile Phone, Phone, Mobile, Mobile Handset or Handset: A
type of Mobile Telephone.
[0007] 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.
[0008] 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.
[0009] Global Mobile Network or Mobile Phone Network: The sum of
all Mobile Networks operated by Mobile Network Operators in the
world.
[0010] Wireless Network: A network which provides wireless
connectivity to client computing devices. Such a network includes
Wi-Fi WiMAX and the Global Mobile Network.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] Wireless Device or Wireless Client: A type of Wireless
Computing Device.
[0017] Software Application The Client software application which
is to be delivered over-the-air to, or pre-installed on, the
Wireless Computing Device.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 3. Description of the Prior Art
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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:
1. `Custom Built Applications`
[0027] 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).
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
2. `World Wide Web Applications`
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
3. `Write Once, Run Anywhere Applications`
[0038] 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'
[0039] 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.
[0040] 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.
[0041] 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`
[0042] 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.
[0043] 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).
[0044] 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.
[0045] In summary of these three methods, PC Network Applications
can be developed as: [0046] Custom Built Applications if you want
rich features and functions but only want it to run on a small
number of types of Client platform, or [0047] WWW Applications if
you want to define them once, have them run everywhere but are
happy to live with a limited user experience, or [0048] Write Once,
Run Anywhere Applications if you want to define them once and have
them run on many platforms.
[0049] In the world of Mobile Phones the environment is
significantly different. The major differences are as follows:
[0050] There are many more Mobile Devices in use connected to many
different Mobile Networks. [0051] There are significantly more
manufacturers of Mobile Phones each with potentially multiple
Client platforms resulting in many more varieties of Client
platforms on which applications need to run. [0052] The
capabilities of Mobile Phones change very rapidly as more and more
features are added. The end result is that two different Mobile
Phones can have very different capabilities, quite unlike PC
Clients which tend to be very similar.
[0053] In order to maximise the financial potential of a Network
Application delivered using Mobile Phone technology the
requirements are: [0054] Enable the application to run on as many
Mobile Devices as possible; [0055] Enable the application to be
rapidly commissioned onto new Phones as they are released; [0056]
Enable the application to take advantage of the best and most
appropriate features of each Mobile Device, as opposed to just
running the same application definition everywhere.
[0057] 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.
[0058] 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: [0059] Different Phones have different versions
of Java. [0060] Different Phones have different Java bugs. [0061]
Different Phones have different parts of the Java platform
implemented. [0062] Every Phone has many different releases of
operating system and firmware which means there are behavioural
differences on Phones of the same type of a different age. [0063]
The same Phone can exist with several identities (for example, MNO
branded version of Phones). [0064] Every Phone has different
physical characteristics like screen size, number of pixels, colour
depth, keyboard controls, soft-key characteristics etc. [0065]
Every Phone has different computing capabilities like processor
speed and memory size. [0066] Every Phone has a different set of
media files and formats that can be shown via Java (e.g. audio,
pictures, video, animations, etc). Sometimes these are different
from the formats that the Phone lets the user use in native Phone
applications, such as setting a screen wallpaper. [0067] Every
Phone has different software limitations (two Phones may have the
same amount of memory but they allow an application to use
different amounts). [0068] Every Phone has a different set of media
files and formats that the Phone's operating system can handle and
these are potentially different from those that can be handled by
Java or the platform which runs the application on the Phone.
[0069] Phones handle their network connection in many different
ways, the technologies are different, the settings are different,
the user prompts are different, the way settings are sent and
handled by the Phone are different, the way connections are managed
can be different. [0070] Different Phones have different networking
capabilities and handling (e.g. CSD, GPRS, 2G, 2.5G, 3G, WAP, SMS,
Bluetooth, Infrared, Wi-Fi, WiMAX etc)
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
SUMMARY OF THE INVENTION
[0075] 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.
[0076] 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.
[0077] 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.
[0078] Further details and aspects are defined in the appended
Claims.
DETAILED DESCRIPTION
[0079] 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.
Section 1 Device Adaptive Architecture
[0080] 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: [0081] Every Handset
needs a unique application to maximise the user experience. [0082]
The differences between Phones capabilities and features are
described and hence represented predominantly in Metadata, not in
software. Examples of the Metadata collected for each Handset
during the Handset commissioning process can be found in Appendix
1--Handset Metadata. Examples are also provided of how this
Metadata varies from device to device. [0083] The reference point
for the differences between each phone is the Metadata used to
represent that Phone (see Appendix 1--Handset Metadata). Even
though this Metadata is eventually utilised to choose individual
Software Components which are used to form the Software
Application, the reference point is the Metadata for that Phone as
the Software Application can be deleted and rebuilt. [0084] The
Software Application for a particular Handset is built
automatically by the Device Adaptive Architecture software using on
the one hand the Metadata used to describe the unique capabilities
and idiosyncrasies of the device (see Appendix 1--Handset
Metadata), and on the other hand the Metadata used to describe a
library of Software Components that can be compiled dynamically
into an application suitable for that device (see Appendix
2--Handset Software Component Library). The Software Component
library is full of small software components, as opposed to larger
less granular units. Each Software Component could be selected to
form part of the Software Application based on the Metadata
describing the function and method of configuring each Software
Component and the Metadata describing the attributes of the device.
See Appendix 3--Examples of Mapping Handset Metadata to Software
Components. [0085] A rapid method by which the Metadata describing
the unique nature of each Handset, used to build the customised
Software Application for that Handset, can be added to the
platform. If a Handset is commissioned using a combination of
existing Software Components without any modification required then
that is achieved by configuring the Handset Metadata alone. If new
or existing software code needs engineering then new or existing
Software Components with associated descriptive Metadata will be
added or altered in the library. [0086] A rapid method by which new
or existing Software Components can be added to or modified in the
library when a Handset is discovered which implements functionality
using methods and technologies which are not yet available in the
library. A new or modified Software Component can be quickly added
by placing the new file containing the software in the file system
of the library. This is supplemented by Metadata describing the
conditions in which the Software Component is used or the way in
which it is configured for use inside the build of a Software
Application. [0087] An additional Metadata and mark-up syntax on
top of this which allows many different Network Applications to be
deployed to this newly supported Handset with the minimum amount of
Handset specific software developed. See Appendix 4--End User
Application Metadata and Mark-up. [0088] The ability to update the
Software Application dynamically on the Phone after install. [0089]
The ability for the Client to report its status and key parameters
to the Server to allow for further user specific tuning. For
example the Software Application can run tests to determine the
Client's current available persistent and dynamic heap memory space
available which could influence the size of any deck updates made
to the Client's Software Application so as to avoid overrunning
maximum memory size permitted. [0090] The archiving of every unique
instance of the Software Application.
[0091] 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).
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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).
[0104] 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.
[0105] 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: [0106] 1. The
Software Application specific to the Mobile Phone/Network
combination is pre-installed on the Phone by interfacing with the
Mobile Telephone provisioning equipment and supplying it with all
the Software Application builds it needs and the
vendor/model/firmware/network information relating to each Software
Application version so that the correct one can be chosen and
installed; [0107] 2. The Mobile Phone is acquired by an end user;
[0108] 3. The end user turns on the device, discovers the Software
Application and starts it; [0109] 4. When the Software Application
connects to the Server it describes itself as a pre-installed
application (by making a request with no associated application
instance ID) and presents the information relating to the
attributes which were used in the selection of this Software
Application for this device (e.g. phone
vendor/model/firmware/network). [0110] 5. This information is
enough to allow the Server to create an instance record, with an
associated unique ID, for this Software Application and to assign
this unique reference to this instance of the Software Application.
The unique ID is passed back to the Software Application over the
network and the application stores this ID locally and presents it
on all subsequent Server Service requests (just as if it had been
built into the Software Application in the first place). [0111] 6.
The Server is also able to determine, from the data initially
presented above, what the appropriate content types are for this
device so that content applications can deliver the correct type
and format of Mobile Content for the Handset. [0112] 7. The end
user can thus use all parts of the Software Application that are
available without the system requiring the phone's MSISDN. [0113]
8. If the user accesses part of a Software Application that
requires the MSISDN and the MSISDN is accessible to the Software
Application, then it is read and sent to the Server as part of the
request for the Service. It will then be written into the database
of the Server where it will be related to the application reference
ID. It will therefore not be required to be sent from the Software
Application again. [0114] 9. If the user accesses part of a
Software Application that requires the MSISDN and the MSISDN is not
accessible to the Software Application then depending on the
capabilities of the Software Application in combination with the
Handset the following will happen: [0115] a) If the Handset
provides the Software Application with the ability to send an SMS,
then an SMS will be sent to the Server containing the unique
instance ID of the Software Application. This SMS is received by
the Server and enables the Server to associate the unique
application instance ID with the MSISDN it determined from the
incoming SMS. [0116] b) If the method the Software Application uses
to connect to the Mobile Network allows the forwarding of the
MSISDN to the Server (e.g. via special modems which place the
connecting MSISDN on the request headers, or via MNO communications
gateways which can provide the MSISDN in the header of the
communication) then this can be used by the Server to detect the
MSISDN and have the association made between the MSISDN and the
application instance ID in the Server's database. [0117] c) If
neither a) nor b) is available then the Software Application has to
ask the user to manually enter their MSISDN into the application's
user interface. This is then done and sent to the Server. The
Server can then associate this Software Application's MSISDN with
the application's unique instance ID. If this method is used there
might be an extra step taken by the Server to ensure security or
MSISDN accuracy such as sending back to the entered MSISDN a PIN
number which the user needs to enter into the Software Application
to unlock any purchasing features.
[0118] 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.
[0119] 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.
[0120] 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.
[0121] 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.
[0122] 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.
[0123] 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).
[0124] 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.
[0125] 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.
[0126] 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.
[0127] 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.
[0128] 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.
[0129] 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.
[0130] 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.
[0131] 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.
[0132] 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.
[0133] 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.
[0134] 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.
[0135] 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:
[0136] The application required is similar for all devices; [0137]
There are many differences between many of the devices but they are
fundamentally similar and the differences between the Clients can
be described in Metadata and used by the Device Adaptive
Architecture to build the application; [0138] The application to be
deployed benefits from being able to understand the differences
between devices and provides the best possible functionality and
features for the each device; [0139] The application should be
described/represented once or as few times as possible and the
Metadata representing the device characteristics is used to build
the custom applications required by each device rather than the
differences required by the application for each device being
described in each version of the application arrived at by a
traditional porting exercise.
Section 2 Mobile Content Portal Overview
[0140] 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.
[0141] 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.
[0142] The features of the Mobile Content Portal Software
Application include the following: [0143] It is a fast reacting
Software Application which is quick to navigate and browse through
categories of Mobile Content and editorial information. [0144] The
downloaded Software Application contains a Metadata package which
defines the look & feel of the application, the menu structures
for the content on offer, the branding, the hierarchy and flow of
the screens shown to users, content hierarchy, content in menus,
animations, etc. The Metadata is a full data description of the
application, it's features and it's behaviour. [0145] This
definition of the end user Software Application is converted to
binary and compressed to ensure smallest size. [0146] For the
fastest access to Mobile Content and the fastest perceived system
the application contains a default set of Mobile Content and
associated content structure cached as part of the end user
Software Application definition inside of the Software Application.
This can be navigated by the Software Application quickly as it is
local to the Client. [0147] To provide access to a wider selection
of Mobile Content a network based browse function is provided which
allows the Client to show lists and groups of Mobile Content stored
on the Server by accessing the much larger library available over
the Mobile Network connection to the Server. [0148] A search
function is also provided where the user can type any phrase into a
form in the Software Application and that is then submitted to the
Server over the network where a search will then be performed over
the Mobile Content stored at the Server and the matching records
returned to the Client application.
Content Related Features
[0148] [0149] The Handset Metadata enables the system to make sure
that each Software Application for each different Handset type has
the maximum amount of Mobile Content cached on the device without
going too far and consuming too much of the Handsets resources.
[0150] The Mobile Content database on the Server is rich in
Metadata such that only the correct and most appropriate Mobile
Content compatible with the Mobile Device is offered to the user
for preview and purchase. [0151] The application offers users the
option to preview Mobile Content on their Phone before they buy to
enable the user to assess the quality of the Mobile Content before
purchase. [0152] Where the programming language used to provide the
Mobile Content Portal on the Client (e.g. Java) cannot preview the
same quality Mobile Content preview as the Phone itself can support
(when the Mobile Content is purchased) then the system will
understand the best quality preview that can be delivered due to a
mapping between the content types which can be previewed on the
Phone and a ranking of which types have the best quality. Examples
of lower quality previews are: a different (though similar) content
type, an image dynamically reduced in dimensions to fit within the
device's physical constraints, an equivalent content file but with
greater compression, or simply a description of the content. [0153]
Where the system connects to the network for downloading a preview
and there is a wait while that file is downloaded, the client
application provides 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 for providing
some indication of the amount of total time elapsed or the amount
of progress. [0154] Where animations are not natively provided by
the client programming language platform then the Software
Application enables this facility by using a number of images which
can overlap partially or fully replace each other controlled by an
x/y placement system and an associated set of timing information.
[0155] The application provides clear pricing of each element of
the Mobile Content so the user is clear exactly what the price
might be before purchasing. [0156] A "locker" based system where
anything that has been previously purchased is recorded at the
Server and subsequently viewable from within the Client
application. The status of each previous purchase can be seen,
where and how much it cost and the status of the billing. Also a
facility to request download of the Mobile Content again if the
Phone has been changed or the Mobile Content item has been lost.
This also includes the ability to get back a different format of
the same Mobile Content item if the user has upgraded to a
different Phone manufacturer which supports a different format of
Mobile Content. This is facilitated by the extensive Mobile Content
and Handset Metadata on the server where there is an understanding
of all the content types available for each Mobile Content product
and an understanding of which Handsets support which Mobile Content
types. [0157] The system monitors the previews and purchases of
content by the user base by recording such events in the Server's
audit trail. The system can then implement a `Darwinian survival of
the fittest` content regime where the Mobile Content items that
have a high sales preview to purchase conversion rate move up the
menus whereas items which are previewed a lot but are rarely bought
move down the menu. This algorithm can also include a weighting for
the depth in the menu that a Mobile Content item appeared. [0158]
Information is collected on the handset to understand the best
possible Mobile Content that a handset can display and render.
Given that the content system has detailed knowledge of the content
types available for the user, this allows the system only to show
content to a user that is known to work on that handset and also is
the best type of content which will work on that handset. [0159]
Automated engines responsible for taking libraries of content from
a content provider which electronically inspect the incoming
content. The inspection is done through mechanisms such as
introspection where the files which represent each element of
content are electronically opened and inspected. These media file
types generally have information embedded in them which describe
the format and nature of these files. This information is used to
confirm the quality and consistency of the incoming content data.
It is also used to automatically map the incoming content to the
Mobile Devices with which it is compatible. [0160] Content menus
and the content within them are given a priority such that Handsets
with the smallest capacity get the best menus and the best content
in those menus, even if they have fewer menus and content items
without any menu cached on the Phone. [0161] If a menu does not
have any items appropriate for a particular Phone then that menu
will not be shown.
White Labeling and Ability to Update
[0161] [0162] Such a Mobile Content Portal where all the elements
which form part of the brand of the end user application (e.g.
application name, application icon, splash/startup screen, contents
of help and about pages, branding on application acquisition
screens, references to itself as a named application, etc) are
abstracted to Metadata from the actual application such that they
are independently changeable and thus the system becomes easy to
immediately produced a branded version of the application for
partners. This is otherwise known as white-labeling. [0163] The
application can provide regularly changing charts, such as top
selling lists and pop charts. These content menus are present on
the Client and have an expiration date. Should a user enter such a
menu and the menu is found to have expired, the application will
connect to the network and request an update of the latest menu
from the Server. [0164] When the application is connected to the
network for the purposes of downloading a preview or getting a menu
(chart) update then any element of the end user application can
also be updated by the Server. The Server will provide an update to
the element by referencing the element on the Client and providing
the new element. It can also provide a new element for download to
the Client for incorporation into the end-user application. This
way any element such as branding, content, structure, screen
layout, etc can be changed over-the-air after the application is
installed.
Products in the Portal
[0165] 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. [0166] The system lets
the user order full versions of music downloads for MP3. [0167] The
system lets the user browse and order CDs and other physical media
entertainment products. [0168] The application allows users to see
SMS & MMS alerts services and to subscribe to one-off and
regularly alerts services. [0169] The system lets the user view
news, stories and events listings relating to the Mobile Content
which can be updated regularly. [0170] The system lets the user
enter competitions relating to the content by the filling in of
simple forms implanted in screens by the Software Application, the
data entered being passed over the network to the Server for
consolidated reporting. [0171] The system can push news and
competitions to the customer base, helping to build a community of
interacting users around the Mobile Content Portal.
Billing Features
[0172] 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: [0173] 1. At the point of delivering the
application to the end user, record the MSISDN of the user's device
in the server's database. The MSISDN is either detected from the
method of request for the application (e.g. SMS, IVR, etc) or it is
requested from the user in the interface which is collecting the
information to allow application delivery to be performed (e.g.
web). [0174] 2. Dynamically build into the application a unique
reference number (or the MSISDN itself but an indirect reference to
the MSISDN is safer for the user) which is related at the server to
the actual MSISDN. [0175] 3. The user downloads the application to
their Mobile Telephone which includes this unique reference. [0176]
4. The Server takes steps (such as deletion) to ensure that this
same application cannot be downloaded again. [0177] 5. When the
application requests the purchase of an item by the user, the
application forwards the reference. [0178] 6. The Server receives
the reference and uses it to determine the MSISDN. [0179] 7. Now in
possession of the MSISDN the server can perform the MT SMS
billing.
[0180] Other billing features include: [0181] a Intelligent
billing: the Server knows if a particular billing gateway needs to
be used in conjunction with the specific Mobile Content item sold.
[0182] Mobile Content can flexibly be delivered asynchronously to
the billing, before the billing or after the billing. Billing
delivery receipts received back from the Mobile Network (generally
by asynchronous SMPP) are used for this purpose. [0183] Credit
limits can be configured such that if the content is delivered
before the billing is performed then a maximum credit on the system
can be achieved. [0184] Ability to effect the billing using the
client application's capability to send a SMS (short message
service) from the application to a premium billed number. [0185]
Ability to effect the billing using the client application's
capability to send a SMS from the Client application to the Server
via the Mobile Network, where the message is received by the Server
and the Server then initiates billing on behalf of that user either
by a method of premium SMS (mobile terminated/MT), direct Mobile
Network operator billing (via messaging into the MNO's core
network), bills to credit or debit card or some other method of
billing possible by a networked Server computer. [0186] Ability to
effect billing by having the Mobile Telephone make a telephone call
(automatically or user initiated) to a premium IVR (interactive
voice response) system of the appropriate cost denomination or such
a line where the total costs can be implemented by having the user
hold on the line for a period of time. [0187] Ability to effect
billing by sending an SMS to the user which acts as a voucher for
the purchase they have made with an explanation to forward this
voucher to a number. The number to which they forward this SMS
voucher is a premium SMS number which performs the billing. The
contents of the SMS voucher are then forwarded to the Server which
pulls out the voucher number and then combines it with the MSISDN
of the incoming SMS and confirms which user has fulfilled the
payment for which piece of ordered Mobile Content. [0188] Ability
to effect billing by sending an SMS to the user where the sending
number of the SMS is set to the same number as is presented in the
SMS, which is a premium rate number, which when called will
implement the billing required for a purchased product. The billing
will be either a particular number which when called achieves a
specific denomination of bill or a line where the amount deducted
from the user increases over time and the call is terminated by the
IVR system when the amount to be billed has been achieved. [0189]
Ability to bill customers where a credit system is provided. Users
either call an IVR number and build up credit or send in SMS to a
premium SMS number where the result is a build up credit for that
user which can then be used against purchases of Mobile Content
from the portal. [0190] A total purchasing limit enforced over a
period of time. This is implemented by recording all purchases made
by a user and only allowing a purchase to occur if the user has not
reached and will not reach the purchasing limit in the specified
period of time. For example children having a .English Pound.20 per
month spending limit. [0191] A spending limit per individual item
of Mobile Content. For example in the UK children under 16 are not
allowed to purchase items using premium rate services where the
cost of the item is over .English Pound.3. This can be effected by
the Mobile Content selected for a children's service being
controlled by a content management application aware of this limit.
[0192] The system is configurable so that particular payment
methods can be used in a country or be flexible enough to change
the nature of part of the application due to local legislation.
[0193] For a user who doesn't have a compatible Phone, the facility
to use the system on a friend's compatible Phone where they can use
the friend's Phone to locate the Mobile Content they want and when
selected the Mobile Content will be delivered to and charged to (by
way of mobile billing mechanisms such as premium messaging) to that
first user's Phone, and not the friend's Phone. [0194] The service
allows one user to buy a gift through the system and have it
delivered to a contact for the purposes of gifting.
Extended Features
[0194] [0195] The system implements a customer loyalty mechanism
and points system. Points can be collected for actions such as
purchasing and sending the application to a friend. Points can be
redeemed for Mobile Content or sent to a friend. [0196] Send to a
Friend--the ability to send the entire application to a friend. The
Software Application collects the friend's MSISDN in a form and
then submits this to a Service on the Server which sends a WAP push
(or similar) invitation to the friend. [0197] A feature such as
recommend a tone to a friend. This sends a sample of the content
(could be a tone or other item of Mobile Content) to the specified
friend by way of a form on the Software Application collecting the
friend's details and then sending the preview via the Server. If
the friend is a user of the Mobile Content Portal then the preview
is highlighted to them the next time they use it. If they are not
already a user then the Server will send them a link to download
the Mobile Content Portal. When they access it they will immediate
see the recommended Mobile Content Item. [0198] The application can
promote new MNO upgrade network and handset deals using customised
pages to promote MNO packages and phone/network offers. [0199]
Application can support embedded links to partners WAP and xHTML
sites selling other content. [0200] The system stores phone
specific data which provides guidance on how to find the Mobile
Content purchased and downloaded on all types of Phones. [0201]
System supports international character sets & currencies by
abstracting all text and currencies out to data-driven country
sensitive messages pricing Metadata elements. [0202] The content
and services offered through the portal can be location specific.
For example at the right time of day for the football match in the
cells near a football ground where team A is scheduled to play team
B, then team A & B focused content can be prevalent on the
portal. This is achieved by combining the Content Portal's ability
to dynamically update the content and location based services
acquired by the Server from the MNO or MNO aggregator. [0203] The
application integrates with existing content platforms easily.
[0204] The application tracks purchasing of content for the
purposes of paying royalties & licensing rights. These rights
are stored against the Mobile Content records as the amounts
(absolute, percentage or calculated) to be paid to the identified
party on purchase of the Mobile Content item. Combining this data
with the purchase audit trail provides the required royalty payment
details. [0205] The application has integrated Digital Rights
Management DRM) to support the fight against content and copyright
theft. The system can be configured only to show certain types of
content to phones supporting a comfortable level of DRM. DRM is a
standard by which content can be easily package when delivered to
the Phone to prevent forwarding from the purchasing device to
another device or to support, for example temporary use for
promotional purposes, by a device. [0206] The system has an
on-board game called `Name that Tone`. The game presents a number
of ringtones whilst one ringtone is played. The user has to guess
which ringtone is playing. It allows the user the challenge a
friend.
APPENDIX 1
Handset Metadata
[0207] 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.
[0208] 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.
Device Identification
TABLE-US-00001 [0209] manufacturer Which company designs and
manufacturers the device. E.g. Nokia, Sony Ericsson, etc name Name
of the device e.g. 6600, K700i display_name How customers know the
phone e.g. Nokia 6600, Sony Ericsson K700i. user_agent_expression
User Agent Profile (UA Prof) presented during a WPA or xHTML
session during application download used to recognise a phone.
user_agent_evaluation_priority Handling conflicts between UA
Profiles. group_membership Used to group handsets which have a
similar platform together. 3.sup.rd party handset identifiers How
others might refer to handsets e.g. content suppliers or MNOs.
phone image A picture of the phone.
Market Information
TABLE-US-00002 [0210] popularity rating A sliding scale of
popularity used to determine which handsets to commission. launch
date The date that the handset became available in the market.
announcement date The date that the handset was announced to the
world.
Network Configuration
TABLE-US-00003 [0211] notification_method Available methods for
delivering URLs to the phone e.g. plain text, WAP push
network_settings_type Protocol for sending settings to phone e.g.
OMA, OTA can_send_browser_settings Supports receiving browser
settings (Y/N) can_send_java_settings Supports receiving Java
midlet settings (Y/N) device.properties.network.settings.named.
Ability to control name of java.session settings sent to phone
device.properties.settings.additional. Additional manual
config.required configuration required from user to set up network
settings (Y/N) device.properties.settings.can.configure. Network
settings can be manually manually configured by the user
device.properties.wap.browser.content- Protocol used by WAP type
browser (xHTML/WML)
Physical Characteristics
TABLE-US-00004 [0212] Screen size (characters) Number of characters
displayable on screen. Midlet screen size (pixels) Java addressable
screen size. Full screen size (pixels) X & Y pixels for screen
size Dynamic memory available (Y/N) Application size limitations
Limitatiosn to the size of the application.
device.properties.recordstore.max-record- Persistent memory size
(Recordstore) record size device.properties.recordstore.max-size
Persistent memory (Recordstore) maximum available
Network Configuration
TABLE-US-00005 [0213] explicit_java_settings Separate Java settings
required (Y/N) defaults_to_wap Java will use browser's settings
configuration_complexity User interaction complexity rating
Media/Content Capabilities
TABLE-US-00006 [0214] Media content types supported by Java e.g.
audio types, pictures types and size, etc. Media content types
supported by phone e.g. audio types, pictures types and size, etc.
Media content type limitations for Java (image size, max number of
channels, max file size, specific form of content type, such as MMF
version, image file type, etc) Media content type limitations for
phone (image size, max number of channels, max file size, specific
form of content type, such as MMF version, image file type,
etc)
HTTP Connection
TABLE-US-00007 [0215] browser_protocol WAP browser protocol for
HTTP communications java_protocol Java midlet protocol for HTTP
communications device.build.properties.connection.concurrent
Handles concurrent connections
device.build.properties.connection.primer Connection needs priming
device.build.properties.connection.primer. Type of connection
reverse.first.connection priming required
device.properties.http.primer.delay.after Delay to user after first
priming connection device.properties.http.primer.delay.before Delay
to use before first priming connection
device.properties.connection.apn-choice Prompts user to select from
a list of APNs on connection
device.properties.connection.max-threads Maximum threads supporting
concurrent connections device.properties.connection.one-wap-
profile device.properties.connection.platform- Browser launched
from request.http.fails.after midlet will fail to connect if
attempted after Java connection
device.properties.connection.platform- Browser launched from
request.http.fails.before midlet will fail to connect
device.properties.connection.platform- Gateway used to open
request.http.gateway browser from Java. Will either be the
browser's gateway or the Java gateway
device.properties.connection.refuse.session Whether midlet can
reconnect after user has refused the connection.
device.properties.connection.timeout Force timeout on connection
(don't rely on phone to do it reliably)
device.build.http.headers.no-cookies Whether phone supports
cookies
SMS Communications
TABLE-US-00008 [0216] device.build.properties.sms.port.required
Phone requires specific configuration for outbound SMS
communication device.build.sms.truncated Handle handset specific
bug that some phones have with sending truncated SMS.
Java APIs & Libraries
TABLE-US-00009 [0217] device.packages.btapi.1.0 BTAPI version
device.packages.cldc.1.0 CLDC version device.packages.cldc.1.1 CLDC
version device.packages.com.samsung.util.audioclip Samsung audio
library available device.packages.com.vodafone.v10 Vodafone audio
library available device.packages.midp.1.0 MIDP 1.0
device.packages.midp.2.0 MIDP 2.0 device.packages.mmapi.1.0 MMAPI
version device.packages.wma.1.0 WMA version
device.build.properties.audio.incapable No audio library available
device.properties.jad.attribute.midxlet.api Vendor specific control
of JAD contents device.properties.jad.attribute.midxlet.network
Vendor specific control of JAD contents
device.properties.jad.attribute.rms.size Vendor specific control of
JAD contents
Java Application Security
TABLE-US-00010 [0218]
device.properties.jad.attribute.signed.required Application signing
device.properties.jad.attribute.signing.keystore. Application
signing name authority and mechanism required
User Interface Capabilities
TABLE-US-00011 [0219] device.build.screen.canvas.limitation Manage
memory limitation on some phones device.build.screen.canvas.refresh
Handle problems with refresh parts of the screen on some phones
device.build.screen.command.select device.build.screen.items.pool
Handle memory management problems some phones have with creating
and clearing up display objects.
device.properties.progress.connect.range Gauge behaviour
device.properties.progress.download.range Gauge behaviour
Miscellaneous Capabilities
TABLE-US-00012 [0220]
device.build.system.explicit.garbage.collection Give hints to JVM
to help it with memory management. Used on lower memory phones.
device.build.history.reference Manage memory limitation on some
phones device.build.image.unreliable.creation Phone-specific
runtime bug workaround device.properties.jad.static Handle JAD
naming restrictions on some phones
device.properties.preview.png.dimensions Handle handset specific
bug with displaying some images
User Assistance Properties
[0221] Properties used for providing user assistance throughout the
platform.
TABLE-US-00013 help.install.bookmark.create.how How to bookmark a
WAP page help.install.java.how How to install a Java midlet
help.install.java.location.how How to find a Java midlet
help.install.java.location.where Where to find a Java midlet
help.install.java.outmemory.how How to deal with out of memory
errors help.install.java.upgrade.how How to upgrade a Java midlet
help.install.sms.location.how How to find a plain text SMS
help.install.sms.location.where Where to find a plain text SMS
help.install.sms.use.how How to use a URL in a plain text SMS
help.install.smsbookmark.create.how How to create a bookmark from a
SMS URL help.install.wsi.location.how How to find a WAP Push
help.install.wsi.location.where Where to find a WAP Push
help.install.wsi.use.how How to use a WAP Push
help.settings.gprs.enable.how How to enable GPRS
help.settings.java.activate.how How to active sent Java network
settings help.settings.java.save.how How to save sent network
settings help.settings.wap.activate.how How to activate sent WAP
network settings help.settings.wap.overwrite.how How to overwrite
existing WAP settings help.settings.wap.save.how How to save sent
WAP network settings help.usage.bookmark.find.how How to find a
bookmark help.usage.content.game.how How to use a game
help.usage.content.game.location.how How to find a game
help.usage.content.game.location.where Where to find a game
help.usage.content.realtone.how How to use a realtone
help.usage.content.realtone.location.how How to find a realtone
help.usage.content.realtone.location.where Where to find a realtone
help.usage.content.ringtone.how How to use a ringtone
help.usage.content.ringtone.location.how How to find a ringtone
help.usage.content.ringtone.location.where Where to find a ringtone
help.usage.content.texttone.how How to use a texttone
help.usage.content.texttone.location.how How to find a texttone
help.usage.content.wallpaper.how Where to find a texttone
help.usage.content.wallpaper.location.how How to use a wallpaper
help.usage.content.wallpaper.location.where How to find a wallpaper
help.usage.java.browser.how Where to find a wallpaper
help.usage.java.easy.location.how How to make it easy to find a
midlet help.usage.wap.easy.location.how How to make it easy to find
a WAP bookmark
APPENDIX 2
Handset Software Component Library
[0222] 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 Components
[0223] Core handset components are listed below: [0224] Audio
Player Component [0225] Animation Component [0226] String Display
Component [0227] Image Display Component [0228] List Display
Component [0229] Gauge Component [0230] TextField Component [0231]
HTTP Communication Component [0232] Browser opening Component
[0233] SMS Sending Component [0234] Command (soft key) options
Component [0235] GZIP Component [0236] Memory Persistence (RMS)
Component [0237] Video Player Component [0238] File Persistence
Component [0239] Checkbox Component [0240] Radio button Component
[0241] SMS Receiving Component [0242] Bluetooth Communications
Component
Component Variants
[0243] Each component has several variants. Typical examples are
shown below: [0244] Audio Player Component Variants--Always one of
the following [0245] No Audio Player [0246] "Standard" MMAPI Audio
Player [0247] Samsung Audio Player [0248] VSCL (Vodafone) Audio
Player [0249] Siemens Audio Player [0250] HTTP Communications
Variants--Any combination of the following: [0251] "Standard"
[0252] User Identifier in Cookie/User Identifier in URL [0253]
Expected unreliable connection [0254] Handle concurrent connections
[0255] SMS Sender Variants: [0256] With port number/Without port
number on request [0257] "Standard" WMA [0258] Siemens SMS Variant
[0259] Samsung SMS Variant [0260] With message padding/Without
message padding (handling device specific bugs) [0261] Browser open
Variants: [0262] Can't open WAP from Java [0263] Can only open wap
from java if we haven't tested the java http connection [0264] Can
open wap from java but requires java http settings [0265] Can open
wap from java using the wap settings
Sub-Components
[0266] Each component/component variant has several Sub-Components
which can be controlled by different properties. Examples are shown
below: [0267] Audio Player Component [0268] Create Audio Player
with suitable content/content-type component [0269] Start Audio
Player component [0270] Stop Audio Player component [0271] Detect
End of Playing Audio component [0272] Destroy Audio Player
component [0273] HTTP Communications Component [0274] Create URL
component [0275] Create HTTP headers component [0276] Create
connection component [0277] Make HTTP request component [0278]
Detect HTTP status component [0279] Retry HTTP component [0280] SMS
Sender Component [0281] Create SMS object component [0282] Create
SMS connection component [0283] Send SMS component [0284] Memory
Persistence (RMS) [0285] Create record [0286] Read record [0287]
Update record [0288] Delete record [0289] Split record [0290] Join
record [0291] Animation Component [0292] Display animation [0293]
Size animation [0294] Prioritise animation [0295] Animation rate
[0296] Command (soft key) Sub-Components [0297] Open screen in JAR
[0298] Open screen stored in RMS [0299] Open screen in current deck
[0300] Download deck over HTTP and open screen [0301] Send SMS
[0302] Open URL in WAP browser
APPENDIX 3
Examples of Mapping of Handset Metadata to Software Components
[0303] 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: [0304]
A direct property existence test (e.g. property A must exist for
this Software Component to be compatible or used). [0305] A
comparative property value test (e.g. property B must have a value
greater than X for this Software Component to be used) [0306] A
comparative test of a device property value against a Software
Component property value. (e.g. device property C must have a value
less than Software Component property SC for this Software
Component to be used) [0307] Ratings mechanisms which allow the
most suitable of a set of compatible Software Component to be
selected (e.g. where more than one Software Component is
compatible, select which is the best fit for purpose by selecting
that Software Component where the component attribute SC has the
greatest value) [0308] Any combination of the above
[0309] Some examples of how these properties are mapped to library
Software Component are given in this section.
Build
Audio Player Component
[0310] Select audio package to include and use based on setting of
the device's properties whose names match the wildcard
"device.package.*" [0311] If more than one audio package is
supported by the device, then the package which offers support for
the widest selection of audio types will be automatically selected.
This decision is made by comparing the list of supported packages
described by "device.packages.*" against the capabilities of each
of the supported Audio Player Component Variants. [0312] Exclude
audio player component if phone does not support audio indicated by
the device.build.properties.audio.incapable property [0313] Include
"No preview available" components if no audio available
HTTP Communication Component (Create Connection Sub-Component)
[0313] [0314] Include additional connection (primer) request
according to setting of device.build.properties.connection.primer
property
SMS Sender Component
[0314] [0315] Construct SMS request according to
device.build.properties.sms.port.required and
device.build.sms.truncated properties
Animation Component
[0315] [0316] Use a form instead of canvas when resources are
limited based on device properties: handset grouping, available
dynamic memory.
Browser Opening Component
[0316] [0317] Include platform request sub-component only if
functionality is supported on handset, indicated by existence of
device.packages.midp.2.0 for device. [0318] But exclude component
if either
device.properties.connection.platform-request.http.fails.after or
device.properties.connection.platform-request.http.fails.before is
set.
Tuning
[0319] Some Software Components, once included, are further tuned
according to the value of device Metadata properties. For
example:
HTTP Communication Component (Create Connection Sub-Component)
[0320] Control sequence of primer connection attempt and main
connection based on the values of
device.properties.http.primer.delay.before and
device.properties.http.primer.delay.after properties. [0321]
Control time delay between primer connection attempt and main
connection attempt based on the values of
device.properties.http.primer.delay.before and
device.properties.http.primer.delay.after properties. [0322] Switch
the order of these according to
device.build.properties.connection.primer.reverse.first.connection
Animation Component
[0322] [0323] Select correct sized animation according to which of
a set of ranges the device's screen dimensions and available memory
lie within. [0324] Tune animation frame rate according to available
resources described in properties: group membership, screen
dimensions, available dynamic memory [0325] Tune animation thread
priority according to available resources to balance animation
smoothness against other processing happening on the handset.
Controlled by examining properties: group membership, available
dynamic memory.
Memory Persistence (RMS) Component
[0325] [0326] This component is tuned for the particular device by
controlling the maximum size of individual records and also the
number of records. This is controlled by handset properties
device.properties.recordstore.max-record-size and
device.properties.recordstore.max-size [0327] This allows data to
be persisted via this Software Component without the application
needing to know how the data is fragmented in the underlying
storage. Data can be split over several records.
APPENDIX 4
End User Application Metadata and Mark-Up
[0328] 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.
[0329] Some of the specific features shown in these examples are:
[0330] Display and user interaction objects can be included [0331]
More sophisticated objects like Player and Images can be included
and controlled [0332] Variables can be set and read. [0333] Test
conditions can be checked against variables [0334] Full access is
given to all attributes of the standard MIDP objects [0335] Command
buttons refer to other screens. Those screens will be already
present on the client, or may have to be automatically loaded from
the server.
Form Example
TABLE-US-00014 [0336]<form id="SearchFailure"
title="Problem"> <command label="OK" type="ok" priority="0"
go="Index.do" /> <command label="Back" go="${previous}"
type="back" priority="1" /> <string-item text="An error has
occurred and the search can't be performed - the network might be
busy. Please try again later." /> </form> <canvas
id="LoadingFriend" title="" interval="400"> <commend
label="Cancel" go="${previous}" type="stop" priority="0" />
<image-item key="midp.system.loading.image" src-deck="system"
x="7" y="7" /> <gauge x="64" y="98" size="small" />
<string-item if="connect" since="1.3.1" text="Connecting."
x="64" y="7" width="64" size="small" /> <string-item
unless="connect" text="Sending MyFone..." x="64" y="7" width="64"
size="small" /> </canvas>
Canvas Example
TABLE-US-00015 [0337]<canvas id="Preview" title="Free Preview"
interval="400" loopcount="1"> <player src="/previews/17651"
loopcount="1" contentType="audio/midi" /> <image-item
key="midp.system.loading.image" src-deck="system" x="7" y="7" />
<string-item text="Free preview! Select the Buy option to buy
this ringtone for GBP3.00." x="64" y="7" width="64" size="small"
/> <string-item text="Friends by TV Theme" x="7" y="98"
width="114" size="small" /> <command label="Back"
go="${previous}" type="back" priority="1" /> <command
label="Buy" go="#Buy" type="ok" back="false" priority="0" />
<command label="Play" go="#Preview" type="screen" back="false"
priority="1" /> - <command label="Terms" go="Index.do#Terms"
type="screen" priority="9" back="false"> <set var="last.card"
val="Preview.do?id=2038#Preview" /> </command>
</canvas>
List Example
TABLE-US-00016 [0338]<list id="Cat61" title="Music Celebs">
<include id="#ProductList" /> <set var="category.id"
value="61" /> <set var="category.name" value="Music Celebs"
/> <set var="topCategory.id" value="2" /> <set
var="topCategory.name" value="Wallpapers" /> <append
id="5496" text="Atomic Kitten 2"
image="myfone/shared/icons/wallpaper.png" src-deck="system" />
<append id="5500" text="Sugababes 1"
image="myfone/shared/icons/wallpaper.png" src- deck="system" />
<append id="5506" text="Ronan Keating 5"
image="myfone/shared/icons/wallpaper.png" src-deck="system" />
<append id="5520" text="Busted 1"
image="myfone/shared/icons/wallpaper.png" src- deck="system" />
</list>
XML DTD
[0339] The following is a XML DTD (Document Type Definition) which
describes the mark-up syntax available to use when building
end-user applications.
TABLE-US-00017 <!--- Collection of related screens. -->
<!ELEMENT collection (list|form|canvas|template|initialize)*>
<!ATTLIST collection id CDATA #REQUIRED default CDATA #IMPLIED
onConnectRefused CDATA #IMPLIED onConnectError CDATA #IMPLIED
onLoad CDATA #IMPLIED onError CDATA #IMPLIED > <!---
Variables to set on initialization. --> <!ELEMENT initialize
(set)*> <!--- A variable to set. --> <!ELEMENT set
EMPTY> <!ATTLIST set var CDATA #REQUIRED val CDATA #REQUIRED
scope (card|deck|session|rms) session > <!--- Template to
include on other screens. --> <!ELEMENT template
(timer|string-item|gauge|image-item|command)*> <!ATTLIST
template id CDATA #REQUIRED > <!--- Command to run on user
selection. --> <!ELEMENT command (set|go)*> <!ATTLIST
command go CDATA #IMPLIED label CDATA #IMPLIED back (back) #IMPLIED
priority NUMBER #IMPLIED type CDATA #IMPLIED onConnectRefused CDATA
#IMPLIED onConnectError CDATA #IMPLIED onLoad CDATA #IMPLIED
onError CDATA #IMPLIED > <!--- Screen to open. -->
<!ELEMENT go EMPTY> <!ATTLIST go location CDATA #REQUIRED
if CDATA #IMPLIED unless CDATA #IMPLIED refresh (refresh) #IMPLIED
onConnectRefused CDATA #IMPLIED onLoad CDATA #IMPLIED
onConnectError CDATA #IMPLIED onError CDATA #IMPLIED > <!---
Canvas screen. --> <!ELEMENT canvas
(timer|string-item|gauge|image-item|command)*> <#ATTLIST
canvas id CDATA #REQUIRED loopcount NUMBER #IMPLIED interval NUMBER
#IMPLIED > <!--- Image to display. --> <!ELEMENT
image-item EMPTY> <!ATTLIST image-item layout
(default|left|right|center) default newline (before|after|none)
none y CDATA #IMPLIED x CDATA #IMPLIED height CDATA #IMPLIED width
CDATA #IMPLIED src-deck CDATA #IMPLIED key CDATA #IMPLIED >
<!--- Player to initialize. --> <!ELEMENT player EMPTY>
<!ATTLIST player src %URI; #REQUIRED contentType CDATA #IMPLIED
loopcount NUMBER #IMPLIED > <!--- Connection gauge to
display. --> <!ELEMENT gauge EMPTY> <!ATTLIST gauge
size (default|small|large) default y CDATA #IMPLIED x CDATA
#IMPLIED if CDATA #IMPLIED unless CDATA #IMPLIED > <!---
String to display. --> <!ELEMENT string-item EMPTY>
<!ATTLIST string-item text CDATA #REQUIRED if CDATA #IMPLIED
unless CDATA #IMPLIED frames NUMBER #IMPLIED frame NUMBER #IMPLIED
align (default|left|right|center) #IMPLIED size
(default|small|large) default width CDATA #IMPLIED y CDATA #IMPLIED
x CDATA #IMPLIED since CDATA #IMPLIED > <!--- Form screen.
--> <!ELEMENT form
(image-item|text-field|command|string-item|include)*>
<!ATTLIST form title CDATA #REQUIRED > <!--- Textfield for
user to enter data. --> <!ELEMENT text-field EMPTY>
<!ATTLIST text-field id CDATA #REQUIRED maxsize NUMBER #IMPLIED
constraints (any|emailaddr|numeric|phonenumber|url|password) any
label CDATA #IMPLIED > <!--- List screen. --> <!ELEMENT
list (set|include|append|itemCommand|command)*> <!ATTLIST
list title CDATA #REQUIRED id CDATA #REQUIRED > <!--- Item on
a list that runs a command when selected. --> <!ELEMENT
itemCommand EMPTY> <!ATTLIST itemCommand go CDATA #REQUIRED
image CDATA #IMPLIED text CDATA #REQUIRED back (back) #IMPLIED
onLoad CDATA #IMPLIED expires CDATA #IMPLIED src-deck CDATA
#IMPLIED > <!--- Item on a list. --> <!ELEMENT append
EMPTY> <!ATTLIST append id CDATA #REQUIRED text CDATA
#REQUIRED src-deck CDATA #IMPLIED image CDATA #IMPLIED >
<!--- Include a template on this screen. --> <!ELEMENT
include EMPTY> <!ATTLIST include id CDATA #IMPLIED >
<!--- Run command after time interval. --> <!ELEMENT timer
(go)*> <!ATTLIST timer delay NUMBER #IMPLIED go CDATA
#IMPLIED >
APPENDIX 5
Network Operator Metadata
[0340] 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.
TABLE-US-00018 name Identification display_name Identification
operator_code Identification country Identification Company
Identification walled_garden GPRS openness
reliable_delivery_receipts SMS system reliability on operator
parent_operator_id For managing virtual operators (MVNOs)
supports_contract Contract types offered supports_payg Contract
types offered supports_gprs_on_contract Offers data connectivity
supports_gprs_on_payg Offers data connectivity
contact_number_payg_from_mobile Operator customer contact details
contact_number_contract_from_mobile Operator customer contact
details contact_number_payg_from_other Operator customer contact
details contact_number_contract_from_other Operator customer
contact details typical_apn_names Network typical names
[0341] 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:
TABLE-US-00019 name Identification proxy_ip Gateway connection
parameters proxy_port Proxy port access_point Access point naming
login_type Type of login required username APN username password
APN password homepage Homepage definition protocol Gateway
communication protocol contract_type Contract types this gateway is
used with
* * * * *