Database for use with a wireless information device

Description of equivalent WO 0217652 A2

DATABASE FOR USE WITH A WIRELESS INFORMATION DEVICE

BACKGROUND OF THE INVENTION 5

1. Field of the Invention

This invention relates to a database for use with a wireless information device. The term 'wireless information device' used in this patent specification should be expansively construed to cover any kind of device with one or two way wireless information capabilities ^" 10 and includes without limitation radio telephones, smart phones, communicators, personal computers, computers and application specific devices. It includes devices able to communicate in any manner over any kind of network, such as GSM or UMTS, CDMA and WCDMA mobile radio, Bluetooth, IrDA etc.

15 2. Description of the Prior Art

The convergence of communications and computing is delivering a new generation of wireless information devices, often referred to as smart phones or communicators. The most capable of these devices utilise operating systems and related applications such as the Symbian platform from Symbian Limited of the United Kingdom. Wireless information

20 devices based on the Symbian platform, are 'smarter' than current generation GSM phones in being able to offer multiple, advanced, robust client based applications. For example, current designs of communicators based on the Symbian platform include all of the applications found on a fully featured PDA, such as a contacts manager, messaging application, word processor, spreadsheet, synchronisation etc.

25

A large number of entirely new applications are also being developed to take advantage of the powerful conflux of personal communications, wireless information transfer and computing made possible by the Symbian platform. Many of these applications are client- server based (with the wireless information device itself constituting an advanced client),

30 transferring information to and from servers, which are often internet or WAP servers. Designing these applications (and the associated servers) is generally costly and time consuming since they often have to be constructed from the ground up for each new application.

An example of the kind of application that would conventionally have to be built from the ground up is an application that allows a call to be automatically routed to the desired recipient even though the caller does not know the recipient's current contact number. More specifically, prior and current communications systems use telephones, pagers and computer hosts as the addressable entities, rather than the people with whom contact is required. Some recent work suggests inverting that relation: for example the Mobile People Architecture (Mobile Computing and Communications Review, Volume 1 Number 2), teaches addressing a telephone call to a person, using a look-up to a database of possible devices used by that person to route the call to the device currently being used by that person. The Mobile People Architecture model has several strengths. For example, personal contact information is inherently transient and fragile: people move jobs, change address etc. The time and effort for individuals and for corporations in maintaining an up to date address book is considerable. Using the Mobile People Architecture approach, much of that overhead is alleviated; people are assigned a persistent unique identifier (a 'POID' or Personal Online ID); a caller enters the POID of the required call recipient into his device, which then sends a query to a central database. The call recipient informs the database of her current contact details, so that the database can send these to the caller for the caller to use automatically. Hence, even though the caller may have lost the required call recipient's current contact (or she may have temporarily changed them), the caller can still reach her so long as he has her unique POID.

As noted above, a major barrier to the fast and efficient design and deployment of applications needing access to shared content is the need to custom build the data sharing infrastructure for each new application. Conventional wireless applications invariably perpetuate the approach of custom building a proprietary data sharing infrastructure required for each new wireless data services application, rather than designing a flexible and open architecture which can provide the data sharing infrastructure for any number of such applications. SUMMARY OF THE PRESENT INVENTION

In a first aspect there is provided a database which is accessible by a wireless information device and is

(a) for entities and

(b) has attributes which are remotely extensible by an application author using a standard protocol over a network.

The present invention therefore relates to the use of an open, universal data infrastructure for wireless information devices which can be used by application developers to write new applications by extending the attributes of the database using a standard protocol, as opposed to a closed and proprietary protocol. It offers, in one implementation, an extensible and dynamic framework (i.e. it is a system that can be updated to include new services and functions) for the fast and efficient design, build and roll-out of client-based applications which involve an element of secure and reliable information distribution or content sharing. The present invention allows a huge range of new applications requiring access to shared content to be rapidly and cheaply constructed and rolled out since the data infrastructure which allows content to be shared is pre-fabricated. Table 4 and Appendix 1 list some of these new services and functions. It is particularly powerful in the context of applications which require entities (i.e. any addressable unit, including individuals, companies, positions within companies etc.) to share information about themselves. Access control may be provided by the feature that an arbitrary group of entities is be stored as an attribute which gives access permissions to data in the database.

The invention stands in contrast to the prior art approach of custom designing, for each new application, a wireless data infrastructure (e.g custom built WAP servers etc.) to allow content to be shared. Databases, such as Oracle, are in principle extensible, but only though the use of proprietary tools and protocols and are hence not equivalent to the open, extensible data sharing infrastructure envisaged by the present invention. Further, it differs from systems such as .Net from Microsoft Corporation since .Net also requires developers to custom build applications, albeit using pre-fabricated bunding blocks. .Net is not a content sharing infrastructure, but a system for bunding and delivering over the internet web-based applications.

The dynamic database itself comprises multiple features, including new server side and client side structures. In one implementation, the framework comprises a remote server to which data is posted by a data services provider using a self-describing meta-language, such as XML with a standardised schema. Because the remote server acts as a data repository open to any application which can structure data in conformance with a meta-language schema, it is capable of being used as the central resource which allows data sharing for any new application. Because an open standard is used for the data format, the framework can handle any type of well-formed data. The server may support a general purpose database capable of containing a wide variety of different kinds of information in tagged fields, such that a device requiring information in a field with a given data tag sends to the database a query including that data tag. Because the database is extensible, the data handling capabilities are also extensible; more particularly, application authors can extend it using open, standard protocols as opposed to proprietary protocols. The details of the protocol are not relevant; the skilled implementer will appreciate that there are a number of different approaches, from rudimentary to sophisticated, that may be appropriate; the important point is that the protocol is a standard one - i.e. one that has been formulated and agreed in a normal industry, standard setting process and is therefore open.

A particular entity can enter personal information onto a part of the data structure associated with that entity; it/he/she can also define the access rights available to different defined categories of entities who may wish to read or write to that part of the data structure associated with that particular entity. A preferred implementation of this personal information distribution system is called 'Identities' and uses a data transfer system called ServML. These are described in more detail in later sections of this specification, but can be summarised as follows. If we take the name 'Alice' as being used to refer to an entity with information to share and the name 'Bob' as being used to refer to an entity seeking Alice's information (where Alice and Bob are not necessarily people but can be any kind of entity), then in this system, Alice enters and maintains data relating to Alice on the web server and Bob simply reads in that information as and when needed and caches it. The Alice related data that Bob reads is therefore always up to date. Hence, Bob no longer has to maintain Alice's information, such as telephone numbers and addresses, even when those details change. Whilst this basic approach is shared with other initiatives in this area, such as the Stanford Mobile People Architecture, this system builds on and advances over this prior art in multiple areas, which are detailed in Section B ("The ADS System: Core Advantages") of this specification.

In one implementation, the database is defined by a schema; in many prior art systems for delivering information across wireless networks, hard-coded data structures are typically used and not flexible schemas. Hence, extending such an infrastructure typically requires either a proprietary extension by one software company, which other companies may not be able to interpret correctly, or else a consensus re- writing of the hard-coded data structures, which can be slow to achieve. With the present implementation, a data service provider can choose to enhance an a database with additional fields or attributes; because these are defined in a schema (which term includes a DTD - Document Type Definition), any application capable of using the additional fields or attributes can make immediate, full use of the enhanced database. An appHcation which cannot make use of the enhanced database, is simply unaffected by the enhancements. A data service provider can, perhaps responding to consumer suggestions, enhance an existing database with new attributes; the user can then download the enhancements to applications resident on its device, or entirely new applications, which are needed to make full use of the enhanced database.

As an example, take the database to be information relating to an individual (Table 1 gives an example of this). As new fields are thought of, the object can be readily extended. Hence, a user might choose to subscribe to a service which allowed others to track his or her location - location could be a new attribute. The user's friends or parents etc who wish to track the user's location might initially have appUcations resident on their devices which allow them to see the user's current telephone number and address (perhaps integrated into a contacts application). Once the user has subscribed to the location service, then the friends/parents could add a 'map' appHcation to their own devices, which could show their position on digital maps and also, by using the location attribute of the user's database, it could also show the position of the user. Objects can have many different attributes, although primarily it is Hkely that core attributes will faU under the general headings of personal information, time based information and location based information. As such, they can be handled by contacts, calendar and map type appHcations on devices. Many extensions beyond this core categorisation are possible; a strength of the present invention is that it can readily accommodate them as and when they are conceived. Hence, the present invention is flexible and extensible in a way that prior art systems cannot achieve.

Implementations of the present invention also includes a number of cHent side innovations as well. For example, the framework may comprise several appHcations resident on the wireless information device which each access the remote, extensible database.

Various specific implementations of the invention and additional aspects are further particularised in the claims.

DETAILED DESCRIPTION

A. Overview of the ADS System The present invention will be described with reference to an implementation from Symbian Limited of London, United Kingdom. This implementation is caUed the ADS™ system. The ADS system addresses the pervasive requirement for wireless appHcations to access and share information: the ADS system is an 'information distribution architecture', optimised for wireless computing, offering an extensible framework for the fast and efficient design, build and roU-out of appHcations which need to securely and reHably access and share information. The ADS system's flexible and extensible architecture supports a potentiaHy unlimited set of these kinds of cHent-based wireless appHcations. The term 'information distribution architecture' should be broadly construed to cover any system which enables information (including voice, text data, video etc.) to pass between entities.

The core structures of the ADS system information distribution architecture are (a) internet servers hosting extensible databases; (b) wireless information devices which can access information on these databases; and (c) appHcations resident on these devices which present a common set of APIs to plug-ins from commercial service providers. Hence, three modes of data access are possible in ADS:

1. An appHcation resident on the device queries and receives data from the remote, extensible database. No plug-in components are used and the appHcation is stand alone.

2. An appHcation resident on the device uses a plug-in to receive data from a commercial service provider, but the service provider does not use the extensible database, but a conventional, dedicated server.

3. A combination of the two above: an appHcation resident on the device uses a plug-in to receive data from a commercial service provider and that data service provider uses the extensible database. The present invention is concerned with options 1 and 3 since it is these which involve the extensible database. However, for completeness, the total ADS system description is presented.

Because of the quite complex structure of ADS, the Detailed Description of this specification is organised as follows:

Section A: Overview of the ADS system

Section B: The ADS System - core advantages Section C: CHent side aspects: data plug-ins which work across multiple appHcations to aUow data services to be deHvered directly into appHcations

Section D: Identities — user interaction aspects

Section E: Shared content - — user interaction aspects

Section F: ADS — server side aspects — general comments on the enabling technology Section G: ADS - server side architecture — ServML

Section H: An iUustration — how the ADS System framework is used in making a telephone call

Section I: An illustration - the ADS system database

Section J: New services and functions Appendix 1: More new services and functions

In more depth, the ADS system includes the foUowing:

(a) internet servers hosting extensible databases with attributes remotely extensible by appHcation authors using a standard protocol over a network. The database contains information from or relating to many different entities; it is organised into information fields which an entity can complete or have completed. Table 1 (Section I) includes examples of the kinds of information fields which are possible for an individual. Information is placed onto the database by an entity so that it can be readily shared with other entities: the database in effect represents a web page containing information specific to that entity. The information on the database can be thought of as a 'master' version of information. The database can be readily extended to include new tagged fields relevant to new appHcations. The database can define which entities can read different fields: Alice can therefore give Bob rights to read only certain fields in her database.

(b) wireless information devices running appHcations which access data by interacting with data component plug-ins suppHed by commercial data services providers using a standardised set of APIs to access data. Data may be (but does note have to) come from the extensible databases.

(c) wireless information devices running appHcations which access the information held on the extensible databases running on central servers and other wireless information devices without the plug-ins described above. A wireless information device (as weU as web browsers) can access an entity's database by sending to the server an unchanging pointer or key (an 'ADS Number') which is unique to that entity. The ADS number may include more attributes than just a number; further, an individual entity cold have multiple AADS numbers, each appropriate for a different circumstance. ADS numbers are typically constructed using text strings and can be though of as defining a namespace. When Bob's device sends Alice's ADS Number to the server, then the server recognises Bob's device and anows that device to read Alice's information held on the database which is specified as being accessible to Bob. The ADS system is an extensible framework which offers secure and persistent entity to entity information distribution. Each of these key terms can be expanded on as foHows:

Extensible — The ADS systems is designed so that new data service functionaHty can be dynamicaHy added to existing cHent resident appHcations using data component plug-ins. The ADS system is also designed so that a new appHcation can be created on a wireless information device with no new server-side appHcation by remote appHcation authors using a standard protocol to extend the database fields or (equivalently) attributes. AU that is needed is for the database (on the remote server or cHent resident) to be expandable to accommodate the new fields (if any) required by the new appHcation and for the new appHcation to be able to extract information from the required fields in the database. XML tags conforming to a standardised schema can be used to facilitate this.

Framework — The ADS system is a general purpose architecture which can be used by many different appHcations which require information sharing; it is in essence a framework.

Secure — As noted above, the ADS system ahows signed data objects to be directly inserted into a user's device resident appHcation; the data object can therefore be fuHy authenticated using an automated process. In ADS, a user can also specify the remote database access rights given to different people or groups: an arbitrary group of entities may be stored as an attribute which gives access permissions to data in the database. The ADS system includes additional access control mechanisms, such as checking the identity of the calling device at the server or the caHed device and assessing the access rights appropriate to that device. This protection is extended to the voice caU mechanism, providing a flexible caU-screening methodology.

Persistent — As also noted above, the framework borrows the concept of the computer software pointer. Consider AHce, who is pubHshing some information, and Bob who is accessing it. UsuaUy Bob would store a local copy of the information on his device, and this data would atrophy as time went by. Using the ADS system, AHce stores her data on a server on the Internet, and Bob merely stores a pointer to that data or a local copy of that data (or a subset of it) in conjunction with the pointer. Then as AHce changes her data, Bob's view of it can readily remain up-to-date as (i) the new data can be automaticaUy pushed to Bob or (ii) Bob can puU the new data into his device whenever he needs to make sure that any local copy he may have is up to date.

Entity to Entity — since the framework contains an indirection mechanism, it can be used to link two entities, and not merely 2 devices. Via a variety of mechanisms (programming by the owner, time and location information, information on device currently in use) the server transparently decides which device an entity should be contacted on at any particular time. B. The ADS System: Core Advantages

Core Advantage 1 : Extensible Framework There is currently no common infrastructure for wireless information devices which can be openyl used by appHcation authors for information distribution. Consequently, data appHcations for wireless information devices have to be built using bespoke solutions, often causing them to be slow to market, costly and complex. The ADS system offers an extensible framework for the fast and efficient design, build and roU-out of cHent-based appHcations which involve an element of secure and reHable information distribution. ADS provides the common, data infrastructure for wireless information exchange and aUows an appHcation author to create the data repository infrastructure required by a new appHcation by accessing a pre-fabricated database and, using standard protocols, adding, altering or removing the fields in that database so that the database can be the data repository required by the appHcation being authored.

Core Advantage 2: Reliable entity to entiyt communications

One important example of the class of appHcations which require information distribution is entity to entity communication via mobile cHents over wireless networks. The ADS system aUows entity to entity communication which is reliable. Currently, the contact information on a typical user's PDA or PIM will contain significant amounts of out of date information, with the remainder atrophying in a non-transparent way. Hence, communication using such information is inherently unreHable. Yet further, the burden of adding and maintaining contacts using many conventional systems is considerable, so that even up to date contact information can too easily not be entered into a user's PDA or PIM. ADS exempHfies a reHable communications system in that a communication channel can be opened even if the caUed entity, AHce, has changed her telephone number and has failed to notify the calHng entity, Bob. But unHke other proposed solutions to the problem of enabHng reHable communication, the ADS system is not directed merely to person to person communication, but acknowledges and accommodates the reahty that whilst much commercial communication is between persons (i.e. individuals), those persons are communicating on behalf of a larger entity, such as an employer. Hence, the ADS system enables entity to entity communications, where the term 'entity' embraces not only individuals, but also companies, organisations, and positions within an organisation (e.g. vice president, sales etc), and devices which may be associated with any entity.

ADS adds further to its inherent reHability by introducing the concept of indicating the freshness of data. This can be implemented through a date stamp indicating when particular data was obtained from the server, or a graphical icon representative of freshness. For example, if AHce updates her contact information on her device, that device informs AHce's server, which in turn informs Bob's server (if we are deaHng with a multiple server implementation). Bob's server might then do one of several things. It could send a SMS or similar to Bob's device stating that AHce's information was out of date and asking him if he wants to refresh it. Less obtrusively it could send a SMS to Bob's device which would result in an 'Out of Date' message or 'data staleness' icon appearing next to AHce's contact information when Bob chooses to view that information. Alternatively, it could actuaUy update Bob's device with AHce's new information. Each option would impose a different band of useage and Bob might therefore be charged differentiaky depending on which option he chooses.

Core Advantage 3: client device centric

The ADS system also advances over existing systems by accommodating the trend for wireless information devices to be an important repository of personal information (e.g. contact information, diary information etc.). The ADS system provides a mechanism for the often considerable and valuable amounts of information on these personal devices to be kept up to date, without imposing a significant data input or up-dating burden on their owners. In the ADS system, local copies of the master information held on the central server(s) can be automaticaHy created and maintained up to date. The ADS system signifier of data freshness (noted in Core Advantage 2 above) — a visual indication of how recently any locaUy stored data was obtained and how 'fresh' or reHable that data is - is also an important attribute to an effective cHent-centric approach. Certain user defined fields can be exempted from automatic server updating, aUowing a user to preserve information as required.

EarHer workers, such as the Stanford MPA team and the designers of the numerous web based PIMs, have treated the personal wireless information device as a mere conduit to information, rather than as an important information repository in its own right and as a consequence require a mobile phone to invariably contact a central server as part of a voice caU process. But for many kinds of information it is very useful to be able to store on a cHent wireless information device information relating to another entity, such as contact numbers, since doing so removes the need for the wireless information device to invariably poll a central resource to obtain an up-to date contact number prior to initiating a call. Instead a caH can be initiated using the number stored on the wireless information device; only where that number proves incorrect, is the central server accessed for the correct number. This approach significantly reduces network traffic and cHent device operations.

Further, ADS envisages commercial data service providers pushing relevant data (typicaUy Smart Message data objects) straight into appropriate parts of a user's existing appHcations (e.g. TV Hstings pushed from a news provider straight into a calendar appHcation, so that a user can read them whilst in the calendar appHcation and possibly even use the device as a remote controUer or to programme a video recorder). This reduces and may eHminate the need for the user to browse (typicaUy with a less than effective micro-browser) the internet. It acts in effect Hke a fuUy personaHsed web portal, yet with the information Hnks not consoHdated in one general area, but instead distributed to the domains in which they are most Hkely to be relevant to a user. A user can select a data object to obtain more detaUed information, or initiate other functions, such as an e-commerce transaction.

Core Advantage 4: Flexible and robust access control

As noted above, the ADS system is fundamentaUy an information distribution mechanism.

Access control is therefore a central requirement, which the ADS system implements through an easily operated security mechanism which aUows a user to define which entities have read/write access to any given field in a database of information relevant to that entity (e.g. which entities can see a home contact telephone number etc.).

Authentication (i.e. identifying an entity seeking information) can be achieved through the server recognising Bob's device and determining the database access rights which AHce has given him. Recognising Bob's device can be achieved in several ways; for example, Bob's device could have a unique, secret ID number which it transmits to the server; the server could be programmed to authenticate Bob only where the transmitted and secret ID was recognised by it. Likewise, the unique but not secret caUer line ID could be used as a lower or supplemental authentication check. This form of data transfer could be via SMS or packet deHvery in packet based systems. If the caUer Bob also has stored on the server his own personal information, then a far higher level of authentication can readily take place, with caUer Bob (as opposed merely to Bob's device) being authenticated by being asked by the server to state answers to personal information questions or select answers from a multiple choice (e.g. a PIN, or, more memorably, select your favourite colour /restaurant/recent film etc.), with the server only authenticating Bob when he answers correctly. Authentication of Bob the person, rather than Bob's device, is relevant not only where a high level security is needed but also where Bob borrows someone else's wireless information device or uses a pubHc device (unless Bob is able to personaHse a temporary device by placing his own SIM card etc. into it). Once authenticated, the server passes to Bob's device the information it requests. That is typicaUy done by Bob's device sending various data tags defining its enquiry and the server responding with the relevant information.

The access control methods described above relate to controlling access to information on the server. But as noted earHer, the ADS system also supports information exchange directly between wireless information devices, which therefore also requires some forms of access control. There are many situations where Bob does not need information on the server as such, but instead needs to communicate directly (peer to peer) with Alice. For example, Bob may wish to have a voice conversation with AHce. In this scenario, Bob can caU Alice directly. Authentication of Bob's calling device is performed not by the server, but by AHce's device. For example, AHce's device may allow the caU if Bob's device has a recognised unique ID or caUer line ID, namely one which is stored locaUy on AHce's device. If Bob caUs AHce using a private telephone number which AHce only gives out to her close friends, then that may itself be sufficient authentication.

Since AHce's wireless information device typicaUy includes a cached version of aU of her information which is on the central server, it remains possible for Bob's device to communicate directly with AHce's device without a prior exchange with the server in order to read her information. GeneraUy, AHce would prefer Bob's data requests to be routed to the server, rather than utilise the Hmited resources of her wireless information device. But there are situations where that does not necessarily apply: for example, as is shown in Table 1 (Section I), AHce can post a statement describing her mood; Bob can read that directly from her wireless information device. AdditionaUy, AHce can post the subject of a telephone caU she wishes to make to Bob (in Table 1; the subject is "Dinner tonight") into her wireless information device. When she caUs Bob, that subject Hne appears on Bob's wireless information device before Bob answers the caU, giving Bob an indication of what AHce is calling him about. AHce's device directly transfers this data to Bob using an appropriate mechanism (such as SMS or IPv6 data packet) without any server intervention. Information transfer which is direct between mobUe phones and does not involve a prior caU to the server is appropriate where a connection is being opened up between those devices anyway to support a voice caU.

Access rights can be associated with individual entities, and can also be associated with groups of entities. For example, one could categorise one's business contacts into a single 'Business Contacts' class, and then associate certain common access rights to aU members of that class.

OveraU, the ADS system offers a mechanism whereby confidential information can be securely maintained on a server, yet access aUowed to those with appropriate permissions using a variety of different authentication mechanisms, aU of which are easy to operate yet robust. As information distribution becomes a core inter-entity activity, the importance of estabHshing wireless information devices as trusted tools will become increasingly apparent: The ADS system provides a soHd justification for that trust.

Core Advantage 5: legacy compatible Telephone numbers have been fundamental to wireless person to person communication for many years; the ADS system builds upon the farniHarity, pervasiveness and usual reHabiUty of the telephone numbering system and does not seek to eHminate it. Hence, users of ADS system wireless information devices will stiU primarily use familiar (but potentiaUy not persistent) telephone numbers to make voice contact other telephone users, utiHsing persistent ADS Numbers only where the features and benefits of the ADS system are required (e.g. the caUed party's telephone number has changed). In one implementation, ADS Numbers are invisible to users: if Bob is given AHce's ordinary telephone number, but AHce is an ADS system user, then Bob can use the ordinary number to access a web database which can download AHce's ADS Number directly to Bob's device.

ADS Numbers will therefore supplement the telephone numbering system, offering the additional core advantages Hsted above. Hence, the ADS system architecture has been designed not to confront and replace the existing, familiar telephone number systems, but to work alongside it. The ADS system mobile phones will co-exist with conventional mobile phones, wlfrlst offering enhanced functions.

Section C

ADS: Client Side Aspects - data plug-ins which work across multiple applications to allow data services to be delivered directly into applicable applications

This section briefly describes the aims of some cHent side aspects of ADS, and gives examples of the sorts of scenarios it can enable. These scenarios chaUenge the prevailing beHef in the industry that 'nobody knows what services will be popular, so the best thing is to buUd for flexibiHty'. This means, normaUy, assuming services wiU be accessed through the browser, but the consequence of this is rigidity — 'one size fits none'. The main aims of the ADS project are to:

A. Explore the idea that we can anticipate many of the types of services that will be useful to users and build the infrastructure necessary to support those.

B. Propose a framework for these classes of service that enables a user experience more suited to each type; a framework into which new services can be added.

C. Create this 'framework of frameworks' such that services are tightly integrated in a way that the traditional browser model does not aUow. So that, for example, theatre Hstings services are avaUable from a calendar context, and aU directory services (Vodafone™ directory enquiries, YeUow Pages™, personal address book) are avaUable from a centraHsed location.

In ADS, there is far less of a distinction between services and 'local appHcations', and there is certainly not one paradigm of use for accessing data services and one for using local appHcations. For example, in the traditional model, data services offering directory capabiHties, such as a corporate address book or YeUow Pages, would be accessed via an entirely different route from the user's own on-device personal address book. SpecificaUy, they would probably be accessed through a browser, whereas the user's own personal address book items would be accessed via a local appHcation that was custom-designed for the cHent. The traditional browser model however would present the user with both an unnecessarily large amount of work, plus an iUogical and unhelpful gulf between sets of what are essentiaUy very similar capabiHties and tasks. The idea of ADS is to get around this by aUowing services to integrate into frameworks on the cHent.

Overview of client aspects of ADS

ADS proposes a set of 'service framework appHcations' whose functionaHty can be extended and enriched through the addition of services. For example, continuing the example above, one framework appHcation would be the Directory framework appHcation. This provides a user experience (optimised for the cHent) for accessing directory services, such as local and non-local address books, yeUow pages services etc.

InstaUation of new services may lead to new capabiHties being added to the Directory framework appHcation. For example, after subscribing to the YeUow Pages service, the user may have the option of submitting an address book query to the YeUow pages database as weU as to his/her personal address book and corporate address book.

Note on services vs. plug-ins

The above description makes the YeUow Pages service sound Hke a plug-in to the Contacts engine. WhUe there may be some architectural simUarities, one key difference needs to be highhghted: in ADS, services add capabiHties to the device, which are manifested in appropriate framework appHcations, rather than just adding capabiHties to a single appHcation. For example, if a user subscribes to a YeUow Pages service, this may give the option of submitting a search string to the YeUow Pages database in the Directory section of the device. But it might also add the abUity to browse for a certain category of Hstings (e.g. restaurants) based on the user's current location in a Location section of the device. So, from the above example it should be clear that subscribing to a service means adding a set of capabiHties to the device as a whole. AU or some of these capabilities (the 'verbs' of the service — e.g. 'find', 'buy' etc.) wiU be avaUable to the user is one or mote of the framework appHcations. A second example to clarify this point: by subscribing to the Amazon service, it is possible that a user can "Search for products containing these words" from anywhere in the device; "Search for this CD" from my Internet radio appHcation; and "Find books on this topic" from my News/content browsing appHcation. A diagram of the ADS device

Given the above, the ADS device could be conceptuaUy represented as shown in Figure 1.

The three types of framework appHcation shown in Figure 1 are just examples. The 'Radar framework' is short-hand for a framework appHcation that constitutes the interface between the user and the informational environment around them. AppHcation frameworks are contexts and sets of functionaHty (e.g. calendar functionaHty) that can be extended by services. For example, a YeUow Pages service might announce itself to the device as consisting of two main capabiHties: the ability, given a search string, to Hst entries in the YeUow Pages database with contact detaUs; and the abUity, given a location, to Hst entries in a YeUow Pages database (these could also be combined.) In this case, one could represent the augmentation of the functionaHty as something like that shown in Figure 2.

In this example the YeUow Pages service has added: (a) A search capability to the Directory framework appHcation

(b) A search 'for things in the area around me' capabiHty to the Radar framework.

(c) No new capabilities to the Calendar framework.

There could alternatively be just a single capabiHties framework into which aU services are instaUed; framework appHcations then use the capabiHties made avaUable by a given service via the capabilities framework.

The framework applications

Note on service installation and architecture

The kind of example above points towards certain architectural possibUities. In the YeUow pages example, one could imagine that part of the service subscription (or 'instaUation') process would consist of a negotiation as shown in Figure 3. That is:

1. The service announces its capabilities to the device

2. The device has a matrix that can determine which framework appHcations can make use of which capabiHties.

3. Those capabilities are then made avaUable in those framework appHcations.

4. Additional capabilities not yet included in the matrix can be looked up on the server, and the matrix values for them can be downloaded.

This approach presents one possible way of putting the control of the user experience in the hands of someone other than an individual service developer. That is, someone with a hoHstic view, such as the OS company, the network carrier or the user. It also raises the possibility of 'extensible extensibility': effectively what is happening is that, say, a Calendar framework appHcation can have new APIs added to it as new services are conceived.

Interaction between the device and services

A key element of this data services framework is the way data can go back and forth between the user's device and the elements of the service that are on the server (or on other cHents).

For example, in the case of a BBC service which aUows the weather to appear in the user's calendar, there is clearly a steady flow of data onto the user's device. But in cases Hke the YeUow Pages service, there is a two-way flow of information: the user is typicaUy sending a request consisting of a verb and some other data, in order to puU further data down to the device.

The ADS framework aUows this to function in a sophisticated way because tasks now take place in much more clearly-defined contexts. For example, in the old device model, if the user goes to a web site and starts searching for films, the service has no way of knowing the other parameters of interest to the user (times, prices, locations), and has to request them to be provided one-by-one.

However, the ADS framework in this case can naturaUy provide context information to enrich the service. For example, if the user has an Odeon™ film service instaUed, s/he could select 'Find films' from within a given day, or even timeslot, from within the calendar framework appHcation. This means the request for data from the service would automaticaUy include additional information about the time the user was interested in. Similarly, using the same Odeon service from the Radar framework appHcation, the service could return a set of films showing at nearby cinemas.

Stringing services together

In addition to being able to use services within the context of framework appHcations, the close integration of services that ADS aims at aUows services to be 'strung' together, so that the user may move smoothly from one service to another with a given chunk of data. (Instead, for example, of having to go to the Ebookers™ website to book a flight, then back to Outlook™ to insert the flight detaUs in the calendar etc.) This could greatly benefit from, though does not necessarily require, a common, e.g. XML, schema for describing data).

This kind of service integration enables scenarios which span several services in the course of a single task flow, e.g.:

1. The user selects Friday evening in the Calendar, and uses the Odeon service to get a Hst of theatre events that evening.

2. A number of possible options are returned. The user selects one of these, a play, and uses a ThisisLondon.com service to 'get reviews' for the play. 3. Having read the review, the user uses the Odeon service again to book tickets. In the course of this, the Visa service is invoked to provide secure payment.

4. Having seen the film, the user goes back to the booking in the calendar and uses the

Amazon service to 'find soundtrack' for the film. Section D

ADS: 'Identities' - User Interaction Aspects

This Section D discusses scenarios and user requirements concerning functionaHty based around 'Identity'. Identity aUows people to share information about themselves using their wireless information devices — i.e. it is a mechanism for estabHshing a virtual identity by posting information onto an extensible database. The framework needed to implement these scenarios is described in more detaU in Sections F, G and H. Section H in particular give a real world example of an Identities type system.

Requirements and issues for Identity

Terminology

Communicator - a person, appHcation or service that is interested in contacting (through voice, text etc.) a Target. Data Blocks - discrete pieces of data that can have a specific visibility level assigned to it.

Identity - the whole gamut of information held about the user, some of which is created by them and some of which may be assigned to them as a result of their actions.

Mood - a setting which aUows the user to provide an indication of their state of mind. This is Hkely to provide not only their state of mind but an indication of their avanability and a preference for how they want to be contacted, i.e. if angry and busy, the user may have specified that this means they are only avaUable for chatting in text form.

Target - a person that is the object of a communicators communication activity.

Creating An Identity

An identity constitutes a whole gamut of information some of which is created by the user and some of which may be assigned to them as a result of their actions. In order to create the identity in the first instance the user will however need to provide some information. The initial creation of an Identity must be a simple and logical process. Where possible as much data as possible should have been suppHed on the user's behalf or assigned using sensible defaults. The user must be able to easUy comprehend from the display of their Identity data exactly how their actions during creation and editing wiU affect the representation of themselves to other people. The user must be able to create more than one persona for their Identity and it must be possible for the data associated with that persona to be untraceable in relation to the overaU Identity. This is, for instance, where users wish to interact anonymously with a service or person. It must not be possible for data associated with an anonymous persona to form part of a communication with any of the contacts with access to the overaU Identity with which the anonymous persona is associated. It is important that Identity information does not hinder the interaction of a device. If, for whatever reason, a user does not wish to provide an Identity for themselves only the name field should be mandatory (ensuring that for the Targets the benefits of Identity continue to some degree).

The user should be able to enter the foUowing basic identity data about themselves: aU typical contact information including name, contact numbers and addresses etc. They should also be able to attach files and messages and make use of a variety of services that wiU provide Location, AvaUabiHty and Mood information, Identity avatars etc. (Messages may include not only those being made visible to the Communicator but messages that are purely for the benefit of the Identity. For example reminders and notes associated with a particular contact or group.) The devices themselves should also be able to provide some of this information i.e. whether or not the user is in coverage, or that the user is in a caU etc. The extent to which this is visible to a Communicator is dependent upon both their device and the visibUity rights that the Target has assigned to them.

Once an Identity has been created this data persists and is made avaUable to any new devices that a user adds to their retinue. They then manipulate that Identity in the future and aU devices display these changes.

In addition, it should be possible for one's friends to push 'cool' enhancements for Identity avatars and Moods to each other. It should not be possible to enforce these on the other person, rather that they have the option to choose to accept the enhancements. The Identity information must be extensible to include new formats and services as yet unidentified. For example it is highly Hkely that 3^rd parties wiU create plug-ins to Identity avatars, i.e. downloading accessories for an avatar such that when a person is participating in a group caU, users can signal to each other their views on comments with guns, halos or bunches of flowers etc. The Identity as a whole must be extensible to accommodate numerous 3^rd party- services and appHcations.

Specifying Data Visibility

It is Hkely that the data provided by or on behalf of the user wiU have varying levels of visibUity assigned to it. The view on what should be visible and what not will vary from user to user. WhUe sensible defaults will be assigned to aU data it is Hkely that some users wiU want to define this for themselves.

It is Hkely that Private data wiU faU into one of the foUowing categories:

1. Invisible at aU times. (i.e. account card passcodes). 2. Visible to specific people (or groups) at aU times. (i.e. home address or credit card detaUs).

3. Visible to specific people (or groups) for a specific period of time. (i.e. Location information).

When creating and manipulating an Identity the user must be able to categorise data clearly along the lines of PubHc and Private (taking account of private as defined above) should they choose to do so.

The user must be able to clearly identify data blocks when categorising them.

Specifying data visibility could easUy become an arduous task for users should they choose to specify visibUity levels for aU their data. It must not be necessary for users to view their data in terms of visibility if they do not wish to. Sensible defaults must be appHed to aU data blocks to accommodate those users who do not wish to bother or are interrupted during the setup activity.

The user must be able to determine who is viewing their PubHc data, although this functionaHty need not be avaUable at a high level simply as part of the Identity functionaHty. The user must be able to change their setting in Hne with the activity they are currently attempting. They must also be able to access their Identity directly to make such changes. It must be a simple step (preferably a single step) to change a visibUity setting, in particular location information.

At this time it is possible to specify that the visibUity of location information should default to off; user research has clearly identified this need.

It is Hkely that the user will want to change some information on an ad hoc basis (i.e. Location information) for a specific period of time, i.e. for the half hour that the group of friends are trying to locate each other in town.

The user must be able to switch location information on for a person or group of people and should not have to go to an Identity view in order to do this, i.e. being able to select the person and aUow access. Location information should only be visible for a pre-defined period of time. This period should be easUy extensible by the user. At the end of the pre- defined period the location information should again become invisible. (Users may be warned about the end of the timeout and be asked if they want to extend the visibUity period). It should of course still be possible to extend the visibility period to "forever" but this is something that the user must choose SpecificaUy. It must not be possible to easUy action this by mistake.

Creating Buddy Lists

Some users wiU be prepared to allow specific people access to more of their data than others. These specific people or groups of people with greater visibUity are referred to as Buddies. The user must be able, through a single action, to specify that a specific contact has buddy status. At its most basic level, data is categorised as PubHc and Private. Through research, appropriate defaults wiU be assigned to the data blocks such that the user can be confident that in assigning Buddy status to a contact the Buddy wiH have immediate access to a reasonable but not complete set of the Identities Private information. It is Hkely that some users will want to group their data according to specific buddy groups; parents and grandparents may constitute one Buddy group and wiU have access to some of the Private data, i.e. hoHday photographs, but a close circle of friends may constitute another Buddy group that has access to photographs from a night out at a party. The two groups of data both constitute Private data but their visibUity are each restricted to specific Buddy groups. SirnUarly a Buddy group of coUeagues may see one type of Mood but a group of close mates forming a specific Buddy group may see a completely different representation.

The user must be able to categorise their buddy Hst, i.e. they may group buddies together that have specific interests in common, such that they can assign an entire group access to specific data blocks and aU other Buddies and normal contacts wiU be unable to see that data.

Once a contact is assigned buddy status the user must be able to easUy access that Buddy's settings for the purpose of changing these. It must also be possible for the user to be able to look at their Buddy and determine exactly what that Buddy is currently viewing. This is because while the general Identity information may be displaying one view of the information in the pubHc domain, the buddy may have been assigned a different representation of that same data or setting, i.e. the Mood setting in the PubHc view may show one representation of the Identities avatar, but a buddy may see another. Issue: Users probably need to be able to specify different types of avaUabUity based on a specific contact, i.e. when a parent views their chUd's Presence they see that they are not avaUable because they are in the classroom, however their buddies may see that they are avaUable for chat. Location information, even for a buddy wiU be off as default.

Creating And Using Moods The user will have access to a default set of Moods when first creating their Identity. The Mood forms part of the data avaUable to a Communicator when determining whether or not they want to contact and indeed how they wiU contact the Target. In the first instance Moods are likely to offer generic poles of the most useful Mood indicators, i.e. Happy/Sad or Happy /Angry. It should be possible to add more Mood layers to an Identities avatar.

Moods should, when appHed to an Identities avatar, give clear signals as to the meaning of the Mood in both audio and visual formats. (Mood information should be meaningful in • both as it is Hkely that many communication activities will be increasingly initiated without the handset).

It must be possible to assign visibUity levels to Moods in the same way as aU other data blocks.

The ability to switch between Moods wiU only be used proactively if a) users perceive there to be significant user benefit to doing so, i.e. because it genuinely improves their phone experience or simply because it is seen to be "cool" b) it is extremely easy to do. Once created: The user must be able to switch between moods quickly, with a single action.

It is possible for a Mood to impact the way in which a communications are displayed to the Identity.

The user should be able to download new mood poles. These can replace the default Moods or be used in conjunction with the Moods. Buddies may therefore be able to see a different Mood representation from that being made PubHc generaUy.

It will be possible to add features to an Identity's avatar; Moods must be able to accommodate this.

Moods are not simply there to give a Communicator a view of the personaHty, state of mind and avaUabUity of a Target; it is also a tool for a Communicator so show the Target more about themselves prior to or during a communication. For example: When a Target receives a communication, be that a message or a caU request, the current Mood etc. of the Communicator will accompany the communication.

A Mood should by default accompany a communication or request for communication to commence.

A user must have the ab ity to stop a Mood being sent with a communication. If the communicator has specified that the Target is a Buddy and therefore has access to a specific Mood and Identity Avatar; this representation will automaticaUy accompany the communication instead.

It is highly Hkely that some users wUl, on occasions, forget to change their Mood/ AvaUabUity information.

On receipt of a new communication, be that voice or text, the user must be able to suddenly switch settings through a single button press. In the case of an mcoming caU the user should be able to use the Mood switching activity to divert the caU, simultaneously pushing the new Mood/ AvaUabUity information back to the Communicator.

Setting availability

When specifying availabiHty, the foUowing options are required, though the user may customise this Hst for ease of use: Available (aU communication forms get through), AvaUable for text only (TM and SMS formats are successful, Communicators are advised to use these, however the Identity can enforce this in which case non text based communications go straight to VoicemaU), AvaUable for SMS only, (UnavaUable for any form of communication).

It should be possible for a user to utiHse the calendar appHcation to supplement the avaUabUity information. However this should be an option (not a default) as accurate usage of calendar appHcations is sporadic. It is Hkely that some users wiU want the ability to use their Moods/AvaUabUity information to actively control the way in which they are contacted. Therefore for the Communicator looking at a Targets Identity they may see that the person is only avaUable for text chat and this will mean that if they attempt a caU it wUl be bumped to VoicemaU.

Moods and AvaUabUity settings should be extensible to aUow a user to specify that their settings actively control access of a Communicator. It should not be the default that a Text Me setting automaticaUy forwards aU caUs to VoicemaU. Viewing Identities

Own Identity

A user's Identity constitutes the fuU gamut of data held about them; this may include any or aU of the foUowing: basic contact information, credit card and health information, files (i.e. pictures, sounds, video, documents etc.), messages and preferences, Identity avatars and Moods etc. The extent to which this data is visible on any one device is dependent upon the devices capabiHties.

The user must be able to easUy access their fuU Identity at any point in time and view/edit their Identity immediately.

The user must be able to easUy determine at any one point in time, preferably without switching out of a current view into a specific Identity view, what Identity they are displaying PubHcly. This is particularly important for the Identity avatar and associated Moods as these are Hkely to be the most immediately visible elements of a persons Identity when being viewed by others. (Watermarks and various other mechanisms are under investigation).

The user should be able to view and manipulate their Identity regardless of the device from which they are accessing their Identity. If the device is unable to accommodate some of the data, the user should be clearly informed of this. Inability to display information must not restrict access to or disrupt the display of the remaining Identity data. If a user has aUowed Buddies to see specific Identity avatars and Mood information (and this differs from the current PubHc equivalent) the user should be able to easUy determine this through their Buddy view.

Another Person's Identity

When considering initiating a communication with another person, the use of Identities ensures that there is a variety of information avaUable to the Communicator. The extent and visibUity of this information is dependent upon the amount of information that has been created by the Target and the extent to which the Target has made it visible to the particular Communicator as weU as the viewing device's capabiHties. A Communicator looking at a Target must have access to the fuU set of data avaUable to them as dictated by the visibility settings defined for them by the Target. (The Communicators device should be the only factor determine the extent to which this is possible). When a Communicator actively chooses to 'look' at the Target they know that they are viewing the most up to date information, although a delay in such data being displayed should be negHgible.

If a Communicator is unable to accommodate some of an Identities data, the user should be clearly informed of this. InabUity to display information must not restrict access to or disrupt the display of the remaining Identity data.

The user must be able to restrict the amount of Identity data displayed on their device at a global level.

The user must also be able to restrict the amount of Identity information displayed in relation to a specific individual or group. The Communicator should be able to send a request for specific data to their Target. If the request is accepted the data will simply refresh in the Communicators view.

It wUl be possible for a Target to use their Mood and AvaUabUity to actively control the way in which they are contacted. It must be possible for a Communicator to override a Mood/ AvaUabUity setting i.e. with the use of a pre-agreed number or some other break through mechanism - under investigation is the Communicator holding down the caU button to indicate urgency - this would also provide the Target with a scale of the perceived urgency of a caU that was trying to break through their Mood barrier.

Security

It must be possible for a user to create a persona that is anonymous and which cannot be traced back to the overaU Identity.

It will be necessary to support mechanisms that enable a user to vaHdate that the Communicator is indeed who they say they are. It must be possible for an Identity to determine at any point in time who has access to each part of their data.

A user must be able to control which users (probably Buddies) can update their Identity. They must also be able to add the right to do this on an ad hoc basis. A user with access to an Identities data cannot share this with another user without the express wishes of the Identity.

Communication Goal

It is critical that in defining new communication paradigms the functionaHty of IM, voice telephony, SMS and the features of Identity etc. be integrated such that continuity, i.e. the sense of a conversation — be maintained. For example: textual data can be exchanged as an initial step in a communication and the users choose to 'step-up' to a voice caU, with the freedom to step back down to text if need be, i.e. a message with a sad mood may be sent with the words, "Can you talk?". The recipient may respond with voice communication and if someone else then walks into the room one of the parties can easUy return to text for the sake of discretion without breaking the communication.

Section E

ADS: Shared Content

Shared content This section discusses scenarios and user requirements concerning functionaHty related to 'shared content'. As with the preceding section on Identities, the technology implementing shared content is described in Sections F, G and H

User requirements and issues regarding shared content

Terminology for shared content

This section deals with shared content that is owned by an individual.

A sharing list is the Hst of people with whom the user chooses to share one or more pieces of content. Individuals on a sharing Hst are not aware who else is on the same sharing Hst.

The Hst of requirements below address both sharing of static content and the sharing of ongoing activities.

Key user requirements for content sharing

The foUowing user requirements regarding the sharing of content reflect the need for it to be easy:

Users must be able to share any of their content or activities with individuals and groups with ease. The user tasks involved should simply be selecting the content and selecting the individuals or groups with which it should be shared.

In some cases, such as online photo albums, there is a need to share content that is (at least initiaUy) local to the user's device. In these cases, it foUows that:

Users must be able to share content local to the device and have any uploading to a server handled automatically. That is, the user should not be required to perform an extra 'uploading' step in order to be able to share the data. Sharing lists

Users should be able to share their content and activities with: Individuals from an address book or buddy Hst,

Categories of individuals from an address book or buddy Hst, A private group from a previous activity,

Anyone who may be interested (i.e. make the content avaUable to everyone),

Or any combination of the above.

Further, because sharing of a current activity or object brings its own set of scenarios (e.g. sharing a document during a meeting), the foUowing user requirements are introduced: Users should be able to share with ad hoc classes of users, such as 'People within Bluetooth range', or for greater privacy 'Everyone in my contacts directory who is also within Bluetooth range'.

Sharing sessions

Sharing the current activity differs from sharing content objects in that: The user can share navigation and actions on that piece of content (e.g. of a document) while sharing is going on.

AdditionaUy, the user may want sharing of an object or activity to end as soon as that particular activity is over. It should be easy for the user to set this as an option.

Visibility of sharing status It is vital that users are aware (and in control) of which parts of their content and activities are being shared with whom. So users must be able to easUy and clearly see which individuals or classes of individuals have access to any given activity or piece of content. SimUarly, if the user is sharing a current activity, this fact must be visible at the top level of the user interface. Natural privacy

Some types of content, for example credit card detaUs, should not be shared regardless of the current context.

If the user is sharing an activity and that activity involves confidential information, it should be straightforward for the user to ensure that the confidential information itself is not shared with the other parties.

Notification of new shared content

Users should be able to optionaUy notify the members of the sharing Hst for some content when that content is updated.

Sharing content that is already stored in the user's part of the server

Users must be able to pubHsh content that is already stored (and conceivably shared) in their area on the server to specific groups.

Sharing of content types

It should be possible for the user to share content by type, rather than just set sharing options on a piecemeal basis. For example, a user could have a rule that aU data of 'HoHday photos' type is shared openly.

Also, in order to maximise usabUity and appeal, it should be possible for the user to associate 'templates' with designated content types, so that, for example, 'HoHday photos' are presented to viewers in an easUy navigable and personaHsed 'photo album' applet.

Permissions

The classes of access to content should be:

Owner: the owner(s) of the content. Owners can create, edit and delete content.

Guest: the viewers of the content. Guests may include 'everyone' in which case the content is whoUy pubHc. Guests can view content, and may be able to edit parts of it. Only individuals with Owner status can set permissions. Permissions cannot be transferred to other users. Privacy between content viewers

By default it should be the case that:

Any given viewer of a user's content should not be able to see who else has access to the content. That is, by default sharing Hsts themselves are confidential and not shared.

Privacy between content types

Individuals accessing part of a user's content should only be able to see the content that they have access to.

Storage of shared-content

Where content is pubHshed to a particular group (for communal ownership), that instance of the content becomes part of that group and deleted when it is deleted from that group. Therefore, pubHshing content to a group should not delete the user's copy in his/her private data store.

Deletion of content

Users should be able to delete any content they have shared, whether this is in a forum or in their own individual area.

Read-only vs. not read-only

Content pubHcation and sharing should not necessarUy be a one-way process, but should aUow discussion and dialog.

Users should be able to easUy provide the facUity for others to contribute and comment on their shared content, e.g. via a message board.

Section F Server side aspects - general comments on the enabling technology

Purpose and scope The purpose of this Section F is to demonstrate the suitabUity, or otherwise, of the facUities provided in the standard framework for implementing commerciaUy viable services. It looks at the usefulness of the services framework for implementing services that have been identified as being commerciaUy desirable. We shaU look at the suggested phase 1 services initiaUy, Group Games & Forums and then look at a phase 2 service, golden vCard. This section is merely intended at demonstrating the appHcations of conceptual facUities to commercial service requirements.

Group Games

Group Games Description Groups interacting between each other via games have two different models, the first is that they play a game on their own and simply submit their score to a shared highscore table, aUowing people to compete at being the best at a game without actuaUy playing against each other. The second model is that they actuaUy play against or cooperatively with someone else in their group.

Games in this second model can be broken down based on two characteristics, first whether or not they are turn based, turn based games aUow players to make their move which is sent to another player or to a server to be broadcast, after this it someone else's turn and so on until everyone in the group has had their turn, non-turn based players aUow everyone to play at once. The second characteristic is the turnaround of moves, a chess player may need to consider their move for longer than a tic-tac-toe player, so games can be defined based on the speed of turnaround. With these two characteristics we can spHt games into four categories each with its own functionaHty requirements, the foUowing table indicates this division and some of the games that faU into each category. <img file="WO0217652A2_D0001.tif" />

We now have five different group game types, first the shared high score table game and then the four categories defined in the above table, to investigate whether or not the proposed services framework supports each of these game types, apart from slow turnaround, non-turn based games which is covered later in Forums, we wUl look at a sample game and see what its facUities requirements are and how they can be supported by the services framework.

Solitaire

SoHtaire is a game played alone, the only way in which it can be made into a group experience is by having a shared high score table. An additional feature that could enhance this is that players automaticaUy pubHshed their high score tables so their friends can see them. Lets state the requirements in terms of a framework for creating this type of appHcation.

AppHcation must check to see whether or not the completed game is a new highscore. • AppHcation must update the highscore table if it is a new highscore.

• AppHcation must pubHsh its own highscore table if it has changed.

There are some flaws with this current implementation, first of aU someone could change the global highscore table with a score that was not a highscore. Next the person may not have coverage in their current location. FinaUy the person may not want to pubHsh their highscore table to everyone, for instance their boss may be a Httle worried that they have become a soHtaire expert over the course of their employment.

So with these flaws in mind we can change our Hst of requirements:

• AppHcation must be able to create an offline or onHne message stating their new highscore and send it to a server.

• Server must be able to manage its own highscore table. • AppHcation must be able to pubHsh its own highscore table.

• User must be able to restrict access to information on a user by user basis.

• AppHcation must be able to synchronise more than one highscore table.

• System must do authentication of data.

If we now change these requirements to a Hst of technical features for a framework, we get the foUowing.

• Flexible real-time and batched messaging

• Support for small server side message handling appHcations • Synchronisation of data between server and multiple devices

• Flexible server-side personal data storage

• Trust relationships

• Standard authentication

These are aU features that the services framework includes, so at least we now know that the proposed framework aUows people to play feature rich shared highscore games of soHtaire. Chess

We will now conduct the same style of exercise with chess. Chess is a typical slow turnaround, turn based game. Users should be able to start a game with a friend or perhaps even a stranger, and then play the game over the course of either minutes or months.

• Users must be able to find other people interested in playing

• Users must be able to record previous chess partners

• Users must be able to exchange moves both offline and online.

The first condition means that people have to be able to flag that they would Hke to play and people should be able to search for other players, but perhaps not know anything else about them. Also we know that moves can be handled by messages so we are going to restate a requirement that came up previously for the SoHtaire example, this shows that the framework has early signs of being reusable.

• Flexible server-side personal data storage

• Unique searchable naming system

• Fast pubHc data searching • Flexible real-time and batched messaging.

Again the framework supports aU these features and they are also reoccurring in more than one game appHcation, however this is not as important as the facUities being reused by non- game appHcations.

Tic-Tac-Toe

While Tic-tac-toe is unlikely to be a very popular game, it does compare and contrast weU to Chess, it will require almost exactly the same facUities as Chess, the one change wUl be that the messaging component wUl have to perform quickly enough for people to be able to play a game Hke tic-tac-toe. Prediction of the speed of the system is currently difficult, the major bottleneck is Hkely to be in the GSM/GPRS interface.

• Flexible server-side personal data storage • Unique searchable naming system

• Fast pubHc data searching

• High performance real-time messaging.

Multiplayer Doom The different between turn based fast response games and non-turn based fast response games is the amount of data and the processing required to keep up with it, it is unlikely with early bandwidth predictions that this sort of game wiU be easUy implemented and it is definitely not a candidate for the services framework.

Forums

Forums also known as chat rooms are Hkely to be very popular on wireless devices, especiaUy in Hght of the success of SMS. Simply put a forum aUows several people to be part of a "channel" or room, which is usuaUy hemed; for instance supporters of a footbaU team may meet in a channel devoted to that team to discuss the team. In this example the channel may only be in existence when a game is being played. These mechanics have been weU estabHshed in existing Internet based forums, but the question is what facUities are required to implement a forum service and how are they addressed by the proposed framework.

The use of the naming and data server can be appHed equaUy weU to both pubHc (e.g. IRC) and private services, however some bespoke development wUl be required for existing pubHc services.

Looking at the use case (shown schematicaUy in Figure 4), the user logs on to a forum, he or she wUl have a name associated with them, it may be a nickname instead of their real name. It is important that when they choose this nickname that someone else cannot steal it from them. Once they are logged on they can exchange and receive messages with those also on the channel.

Again we can go through the previous paragraph and generate some requirements for our framework

• Flexible server-side personal data storage.

• Authentication

• Real-time messaging

Again we are seeing as predicted that the facUities required for previous services are reoccurring, this is a clear indicator that a standard way of implementing services is desirable and that services can reuse "off the shelf components, namely parts of the services framework.

Golden vCard

A Golden vCard is a vCard that once given automaticaUy keeps itself up to date. If you give someone a Golden vCard you are reaUy giving them a vCard and a contract of trust that they may receive any changes to the fields of your vCard that you may implement later. The Figure 5 diagram Ulustrates the situation where BUI Jones has given his Golden vCard to Joe Douglas. Joe now has a copy of the Golden vCard in his onHne contact Hst however more importantly BUI has a contract set up to pubHsh changes to Joe.

Rather than analysing the problem this time, we wUl state aU the facUities that have been used up until this point, summarise them into one Hst and then see how each of them can be used to deHver golden vCards.

To recap, the foUowing facUities have been used so far Solitaire used ...

• Flexible real-time and batched messaging

• Support for smaU server side message handling appHcations

• Synchronisation of data between server and multiple devices • Flexible server-side personal data storage

• Trust relationships

• Standard authentication

Chess used ...

• Flexible server-side personal data storage • Unique searchable naming system

• Fast pubHc data searching

• Flexible real-time and batched messaging.

Tic-tac-toe used ...

• Flexible server-side personal data storage • Unique searchable naming system

• Fast pubHc data searching

• High performance real-time messaging.

Forums used ...

• Flexible server-side personal data storage. • Authentication

• Real-time messaging

Combining and summarising them to a single Hst we see a lot of commonaHty, we will now go through this Hst and see how these features could be used to implement a golden vCard service.

• Fast pubHc data searching

Fast pubHc data searching may be used as a way to find people before estabHshing a golden vCard • Flexible real-time and batched messaging This can be used to buUd lookup appHcations

• Flexible server-side personal data storage

This can be used to store the user's own vCards and the detaUs of others • High performance real-time messaging.

High performance messaging is not essential for this service • Support for smaU server side message handling appHcations It is not clear how this feature could be used for golden vCard

• Synchronisation of data between server and multiple devices This is essential for synchronising devices such as PDA with your set of golden vCards

• Trust relationships

This can be used to setup to pubHsh/subscribe relationship that is at the heart of the vCard • Unique searchable naming system

This could be used to find people on the system to request a vCard from them.

It seems clear from this analysis that again the facUities offered by the ADS framework are useful in deHvery of this service.

Conclusion

We have looked at a smaU number of appHcations and it is clear that the initial framework is capable of deHvering them. It is obvious that the framework wUl become more refined as services are implemented on them, however a module design based on open standards will aUow this. The framework wiU be useful outside of the wireless arena and it desirable and important that it is adopted elsewhere in order to avoid a closed proprietary framework being estabHshed.

The most important thing to come out of this brief analysis is the level of reuse in this services framework and that benefits not just the services but each of them becomes richer due to their shared heritage; the real strength may be that after exchanging a golden vCard a user can at sometime in the future estabUsh a game of chess based on that contact.

Section G

Server side architecture - ServML

Purpose and scope This section is intended to give an Overview of the 'ServML' Framework proposed for ADS. The section describes the requirements for a wireless services Framework, the facUities for such a Framework, and how the Framework would enable ServML Services.

The ServML Framework describes a means of storing, accessing, and interacting with data using a cHent-server architecture. It is optimised for access to data or services using Wireless Information Devices, whether these are hosted on Internet servers or other Wireless Information Devices. It takes advantage of the power of Symbian advanced cHents, providing a fit for purpose platform to deHver, maintain, and control the flow of information between the cHents and the server. ServML embraces existing standards and initiatives such as SyncML and XML and uses standard data transports such as WAP or http for data access.

Current Internet technology offers a set of services that are not very different to the dumb terminals of the 80's, where the main mode of operation is accessing read-only text with a browser with other capabiHties retro-fitted in a less than optimal way. This is powerful largely because of the abUity to hyperlink different pages together, creating the infrastructure between separate information sources.

Unfortunately, the current architecture of the Internet is not weU suited for the wireless device form factor, providing an inappropriate user experience (the browser/page metaphor) for mobUe devices with smaU displays. The screen requirements of the page metaphor are larger than can be easUy carried around and used on the move. Furthermore the browsing nature is not ideal for a busy person on the move.

To evolve this model to be more useful and enjoyable experience, a richer set of capabiHties needs to be provided. Not only has the need to access the information moved from the desktop to 'anywhere, anytime' with mobUe devices, we are also seeing increasing demand to move from 'hypertext' to 'hyperinformation' (i.e. data whose semantics are defined so that computers can manipulate that data in a content-sensitive way). Hyperinformation and the semantic web have been hot topics recently in the W3C with Extensible Markup Language (XML) being seen as the technology Hkely to deHver this next generation web. This move also means that we may move away from the browser as the primary and in many cases only tool for accessing information services and see the birth of a new paradigm, in which the Internet enables services. Although the server architecture is in many ways identical to the present Internet, the usage model is quite different. Instead of a passive data-viewing function, the Internet and its servers can be used by a mobUe device to deHver enchanting services that far surpass the present PC-Internet model.

The result wUl be the abUity of wireless information devices to interact closely with appHcations and data on the Internet to deHver high quaHty services. An open standard is needed to make this a reality and to prevent a proHferation of proprietary solutions that each serve only a smaU segment of the market.

Requirements for a Framework

Some of the foUowing requirements are appHcable to both wired and wireless Internet access, some are more specific to just wireless devices. It is important to note that users will want in the future to access data and services from a variety of terminals and devices. Therefore, ServML must be appHcable to the Internet user as weU as the WID user.

Perception of security

One problem with the current Internet, as with any infrastructure that grows in an evolutionary but to some extent uncontroUable way, is that infrastructure was not designed to provide perception of security. A systematic approach to security is therefore needed, one which aims to guarantee that transactions made cannot be compromised. Perceived security also gives rise to the chaUenge of identity, a person's identity on the Internet is currently represented by either proprietary ad-hoc data solutions or a homepage, neither is Hkely to suit a move to the next generation of services. Extensibility

Just as the IPv4 standard turned out to be too limited in space, requiring IPv6 with nearly infinite address base to be created. Anything that is designed to solve current and future problems needs to be designed with ample room to grow and expand.

Use of Open standards

Using a standardised way of working, rather than proprietary mechanisms, is a commonly accepted goal in modern development. Standards enable inter-operation, and leverage the existing work. Not only does it normaUy end up being a better product, it also provides economies of scale, the current GSM standard being a good example. Open standards such as XML and SyncML can provide a common set of tools across the industry, increasing uptake.

Ease of Deployment and use Any new technology wiU face an uphUl battle if it is difficult to adopt and deploy or if the end user needs to change their patterns of activity to accommodate the new technology. Particularly for the mass wireless markets, significant attention needs to be paid to the ease of deployment of these new approaches and to the issues of data representation and manipulation in order to enable mass take-up.

Enabling facilities for Framework

Our analysis and experimentation has led us to beHeve that there are a set of core facUities that are used again and again within services solutions. In this section we will look at these facUities and discuss at a high level the requirements for their provision.

Identification

A unique ID is the Holy GraU of governments, marketeers and web sites. However it is also one of the most feared concepts by freedom groups worldwide. It is unHkely that any solution will bring about a unique identification scheme, however there should be support for multiple identification schemes and there should be provision for a preferred naming scheme for wireless services. We need to address the concerns of the freedom groups in our security model &amp; framework generaUy, for instance users should also have the option to prevent access to even their pubHc information via a directory lookup.

Identification is very related to Identity and it is Hkely that some form of Personal Storage System will implement Identity.

Authentication

There is a need for authentication of the user when they access their data perhaps via their WID. This authentication should prevent access to their information both locaUy and on the server (for instance if their device is stolen). The authentication can use a number of different mechanisms: a basic WID and password/passphrase is Hkely to be first Hne of access. Once past this stage the WID may store private key(s) transparently to the user of the WID that wϋl aUow access to services. The private key effectively represents the ownership of the WID to the server side session. Once again, a number of emerging standards can be adopted directly to provide this functionaUy.

Contracts

The concept of a contract initiaUy may be a special case of aUowing access to information that the contract holder may not normaUy have access to and also perhaps govern how they can use this information. In order to govern this, there may need to be some level of legal framework surrounding contracts.

One of the key areas that needs to be considered here is how contracts can be estabHshed offline in a si Uar manner that electronic business cards are currently exchanged via IR.

Offline Contract Establishment

There is a need for contracts to be estabHshed between two Wireless Information Devices (WIDs) which, can communicate with each other (e.g. via Bluetooth or IR) but cannot or do not want to access a server. There are four mechanisms for this: 1. The parties estabUsh a contract and both parties later upload it to the main server in an authenticated session. We shaU caU this double upload unsigned contracting.

2. The parties enter into an initial negotiation and identify each other. As required, one or both parties sign a contract, that contains identities and this is then used by the other party as needed. We shaU caU this single upload signed contracting.

3. One of the parties as required signs a contract that does not contain identities. We shaU call this permission slip contracting. To understand this form of contracting more clearly and indeed aU of the forms, we can think of the three steps visuaUy ...

• Step 1

Mr White sends Mr Black, a contract that defines the terms under which Mr Black can interact with Mr Whites resources on the server, this contract is digitaUy signed by Mr White, probably via a private key on the WID.

• Step 2

Mr black presents his contract at a later date to a server representing Mr White in some way, perhaps it is Mr White's personal storage system. The server wUl vaUdate the contract, for instance by checking it against Mr White's pubHc key.

• Step 3 Once vaUdated in Step 2, Mr Black can interact with the representation of Mr White on the server under the terms of the contract (i.e. the data or services that are offered by Mr White's server to Mr Black).

4. The contract is estabHshed, signed by both parties and then doubly uploaded. We shaU caU this double upload signed contracting. Each of these contract estabHshment processes has different levels of resource use and almost always an inversely proportional level of security. What is still unclear is whether we need to simply have one standard way for estabHshing offline contracts or more than one. It is clear however that there is a need to reduce the scope of contracts to limit the complexity. IdeaUy contracts wiU grant access to only one party's resources and the recipient wUl use this contract as simply a permissions mechanism.

The last of the options, double upload signed contracting is without doubt the most secure option and it may be that this should be the only mechanism offered in order to provide a high integrity system at the expense of more resource (and possibly user) friendly solutions.

Options that involve signing require a private key to be stored on the device in order to perform the digital signature operation. This brings in the requirement for secure storage on the device, perhaps in some form on encrypted storage system so that if the phone is stolen, the key is not compromised (this is already possible using standard technology wherein the private key is held in the SIM and a session key is generated for aU transactions).

Naming There is the need for some form of lookup service in order for people to find others using services. Once found they can then store the unique ID in their contact manager (thus eliminating the need for multiple look-ups unless the link becomes invaUd). This is simUar to DNS except that names should probably only ever be resolved once and the unique ID should then be stored. However there is the need for the same caching/ resolving structure and a root registry system. Due to privacy concerns there is a requirement that the user can opt-out of name resolution. Personal Storage

XML Hierarchy

Extensible Markup Language (XML) is increasingly being used to get around the problems of proprietary ways of representing data on the Internet. Not only does it provide a better definition of data, it is also extensible through the use of Document Type Definitions (DTD) and therefore sharable with others. XML also provides a suitable hierarchical structure to represent data.

XML vs. pages

ServML is designed to use XML to store and transfer data. With XML the data can be presented in a way that aUows logical storage of personal information in the server. Unlike Hypertext Markup Language (HTML), which can only provide a crude layout of data, and often using proprietary mechanisms, XML is a standardized, platform independent and extremely robust way of describing the data. XML can therefore be optimized to handle many different types of data in a flexible, yet precise manner.

X-Folder

In order to buUd a functional hierarchy, we may need to define several sets of data by using XML schemas or DTDs. One of these suggested types is X-Folder, which aUows a standard representation of folders that contain only one type of data, e.g. contact information. This wiU aUow for better compression techniques and hence more efficient handling of data, given limited bandwidth of the wireless cHent.

XML Schema for standard data types

As mentioned above schemas may be needed to define certain types of information. SimUarly, certain types of data types should also be defined as schemas in a standardized manner. This enables sharing of schemas across the Internet making sharing of information much easier. XMLification of Vcard

An example of this 'XMLification' is work currently under way of defining VCard standard as a XML DTD. WhUe not yet standardized format, it demonstrates how information is increasingly being reformatted to XML.

Need for standards body / mechanism

In order to do this type of XMLification, a standards body will need to be involved to oversee the process and make sure it serves the best interests of the wireless industry. WhUe the Internet user community can often advance the standards, a standards body would accelerate and focus this process.

Searching

Having data stored in the server in an organized manner is not sufficient in itself. An efficient mechanism of searching the data is also required and XML is again more fit-for purpose than the alternatives. XML aUows data to pass through firewaUs and it is defined in a way to make searching much more efficient and precise than traditional HTML.

XML Query

W3C has formed the XML Query working group to standardise the querying of XML documents. They are Hkely to produce standards for the request and results of queries along with some form of query algebra. This wUl mean that they are Hkely to produce something akin to SQL but aimed at XML rather than tables and fields. This standard wUl give rise to XML Query Engines that wUl provide fast querying and hence rapid searching of XML material, based on indexes simUar to database queries. Linking, Pushing and Polling

With distributed information systems, there is an issue of how relationships between the information are presented and processed. With a page based system such as the World Wide Web (WWW) this is normaUy done with hyperlinks, that aUow the user of the system to cHck on a Hnk and move to the related information. CHent software can also automaticaUy foUow links and either cache them in advance to increase the speed of access to related information or present the related information within the current page view (this is done for images with most modern WWW cHent software where the image Hnk is foUowed and rendered if specified using the &lt;img&gt; tag).

Manual Hnk foUowing is not appropriate if there is a move to using information appHcations as opposed to page browsers. This means that if an information object that references remote information is used it can either be looked up at read time (automatic Hnk foUowing) every time the object is used and hence the remote information wiU always be as up to date as possible, it can be read once and then periodicaUy refreshed (poUing) or when the remote object is updated it can push the information out to aU the objects that reference it (pushing). Each of these strategies has strengths and weaknesses.

<img file="WO0217652A2_D0002.tif" /><img file="WO0217652A2_D0003.tif" />

As with everything, the choice depends on the specific problem. In this case the problem can be categorised by the frequency of updates. With personal information storage from periodicaUy connected devices, pushing is an attractive approach assuming the data does not change too regularly or that there are too many subscribers to a particular piece of information.

An ideal system should support aU 3 methods so that if the information other than personal information is stored it can be supported optimaUy. It is Hkely that in the future the distinction between the local information stored on a WID and the information stored on a server wUl blur further. More detailed information about the buUding blocks of these methods are described in the later sections.

Permissions

Permissions on the personal storage component are vitaUy important to give a feeHng of security to the owners of private and potentiaUy sensitive data.

Permission management

To provide this sense of control, the interface and mechanism through which users manage their information must be clear and simple. There is a risk that as the personal storage system grows the complexity of the permissions mechanism wUl increase, especiaUy as they develop privacy relationships with groups and a one to one relationships with web merchants. Groups

Group permission management is a way of simpHfying permissions and provides a sense of community within the overaU system. Groups should be managed by a more general contact manager system than those currently seen on the platform. WhUe the integration of group and permission management functionaHty into a contact manager is non-trivial, it is also highly desirable in order to provide an integrated feel to the experience of using services.

Contracts One mechanism to simpHfy the management of permissions for case by case scenarios is the use of a contract. A contract is simply a permission object that is signed by the owner of some information and aUows named individuals to access information in a manner prescribed. Someone holding a contract wUl effectively have limited access as if they were the signatory of the contract. This helps reduce the complexity of permission management, provides a workable way of implementing the system and constrains security into a smaUer area of the overaU system.

SyncML

SyncML is an industry standard that defines how two devices, cHent and server, handle synchronisation. Apart from the synchronisation protocols SyncML is also used to store the information on the server.

Overlap with schema usage

SirnUarities between SyncML and XML schemas exist to suggest that different variations of coexistence exist between the two. SyncML uses XML as a markup language to store the messages, which enables open, standardized way of coding SyncML data across ServML. SimUarly, many existing server storage systems are implemented using XML, which would make co-operation between the two types of storages relatively easy. Need for Open Standards

Just as with other implementations of personal storage, the possible designs that combine

SyncML and XML schemas need to be standardized. Without standard way of operation, the storages would never gain the level of acceptance that is required for a mass market solution.

Messaging

Communications

ServML requires a communications standard for the deHvery of services. After some research the Simple Object Access Protocol (SOAP) has been selected as an exceUent candidate.

SOAP Overview

SOAP is a protocol Hke Common Data Representation (CDR); it is rapidly emerging as a future standard for accessing services on top of the existing Hypertext Transport Protocol (HTTP) based structure of the Internet, along with other transport existing protocols such as Simple MaU Transport Protocol (SMTP). It has been caUed Remote Procedure CaUing (RPC) for the Internet and standardises what many people where already doing for advanced B2B and B2C services. Put simply it uses XML as a structure for the encoding of service request, response and error messages, which can ideaUy be used in a intermittently connected wireless devices.

The use of existing structures is essential in order for any standard to be adopted since corporate infrastructure and security facUities such as firewaUs are already tuned to these structures. Also the flexibUity offered by the choice of transport protocol — HTTP, SMTP or something else is ideal for the variable levels of connectivity that Wireless Information Devices (WIDs) need to handle. Indeed the abUity to use variable deHvery mechanisms and perhaps conceal this selection process to the developer wUl enable appHcations to be quickly developed that overcome the inherent difficulties for deHvery services to WIDs. Standardization

SOAP is an open standard and akeady many open source implementations of both cHent side and server side software have been released. WhUe there was initiaUy some fear that it would be hijacked by one of the initial vendors behind it who would add proprietary features in order to gain dominance, this is unlikely to happen as the user community involved with SOAP is akeady mature enough to deal with this problem.

Standardization is very important in this area, as more services become avaUable via the one protocol the more value supporting this protocol has. It is anticipated that supporting a non- SOAP method of service deHvery may be akin although not as severe a problem to supporting a non-HTTP hypertext transport protocol instead of going for HTTP.

Remote Procedure Calls (RPC) WhUe not intended as a specific RPC engine, SOAP is already developing a standard for the encoding of requests, responses and faults. It may also encode existing appHcation level protocol, an example could be SyncML's synchronization protocol, however the standard encoding for request, response and fault are Hkely to become dominant.

Language Independent

Due to the existing avaUabUity of XML Hbraries for many languages and the very nature of SOAP, dient software is either immediately avaUable or can be provided quickly for many languages. This wiU ensure that developers writing software for WIDs can do it in their language of choice.

Flexible Transports

One obvious requirement for a fit-for-purpose Framework is its abUity to use various transports in a flexible, optimised manner. Just as e.g. current WAP architecture has separated the transport layer from the protocol, simUar arrangement is needed for ServML. Several types of messaging are needed in order to cater for the extensible nature of the Framework. CHent to Client

Asynchronous

Majority of existing messaging is asynchronous in nature. Short Message Service (SMS), Enhanced Messaging Service (EMS), Bio Messaging (BIO) and Smart Messaging can aU use GSM's signalling channel, which provides relatively slow but Hghtweight transport for messages required by the ServML Framework. Similarly, the store and forward mechanism used provides flexibUity for the interaction. We see that SMS, EMS, BIO and Smart Messaging provide a good, functional transport solutions for ServML before Universal MobUe Telephony Standard (UMTS) and Multimedia Messaging Service (MMS) arrive.

Synchronous

Unstructured Supplementary Services Data (USSD), Wireless Access Protocol (WAP), Bluetooth (BT) and Infrared (IrDA) can aU be used as transports for ServML. WhUe USSD is functionaUy much closer to SMS and EMS than BT or IrDA, its session-oriented nature presents opportunities for more synchronous messaging. BT and IrDA on the other hand can, whUe limited in their current functionaHty, provide a user-friendly way for devices to exchange information when in close range from each other.

Client to Server

Just as important as providing separation of transport and protocol between two cHents, it is between the cHent and the server. Using existing transports such as Circuit Switched Data (CSD) or WAP to access the services on the server side gives ServML a choice to route the transactions. SimUarly, using standard IP formats such as MIME, SMTP and HTTP will enable compatibUity with Internet Messaging systems. SyncML

One of the most promising transports for ServML data is SyncML Sync protocol. It is an industry standard way of synchronising data between the server and the cHent, and is therefore natural candidate for carrying ServML payloads. SyncML Sync protocol is very suitable for transferring asynchronous data but if a more synchronous transport is needed the protocol is too heavyweight to set up and use. An investigation into how SOAP and SyncML could possibly co-exist is currently under way.

Best fit-for-purpose messaging ServML is designed in a way that aUows independence from the transport mechanism. This is useful for two reasons:

• As the transport mechanisms evolve and change they have less of an impact for ServML Services • ServML Services can pick and choose most appropriate transports for any given task

Isolating the payload by providing ServML wrappers is therefore an effective way to utilize various transport mechanisms in a flexible manner.

Sample Architecture Solution

Based on the investigations we envisage that a ServML Framework solution is Hkely to be using some form of communications standard, probably SOAP, some form of Identification System and some form of Personal Storage System. These are likely to be the key buUding blocks of the ServML Framework. This would naturaUy imply that there is a requirement for SOAP interfaces to both of these core systems. So it is Hkely we wiU have a general architecture simUar to Figure 6.

Currently data is stored either on the user's hard disk or on the server's hard disk. As these are less than ideal for the WIDs, there is a need for a centraHsed information area. This is described as a Personal Storage System (PSS) and it is Hkely to continue the trend of modern file systems and be hierarchical in nature. However unlike current file systems it is Hkely to store information in the form of XML as opposed to data in the form of proprietary data formats.

We need a trust/reputation mechanism alongside an authentication service, this is Hkely to allow services such as the PSS and misceUaneous SOAP based services to authorize transactions. This Security Service (SS) is most Hkely to be Hnked to the Identification services already described. While simUar in nature to the PSS it is important that any such system is independent from it, so that if vulnerabUities are discovered it can be upgraded independently of the PSS. To enable this upgrade both the PSS and the SS require APIs that are weU defined.

SOAP is Hke to become the standard transport for a number of diverse services. These services are Hkely to be diverse in nature; however most of them are Hkely to require the PSS and the SS parts already mentioned. Hence both the PSS and the SS should offer a SOAP interface which other SOAP services can make use of.

It is Hkely that there wiU be some form of world-wide directory service(s) with registration and resolution of general identities will start to appear soon. Such a directory service should be able to resolve to the Identification System for the ServML Framework, however the creation of such a system is outside the scope of this framework.

Keeping ServML Framework agnostic from the bearers is a key requirement, so that the solution can be deployed across geographical areas and therefore technologies.

Experimental work

In an attempt to learn more about some possible technology solutions to the requirements set out in this document, experimental work was carried out. GSM based proof of principle

A proof of principle study was carried out to discover how existing technologies, such as GSM, SMS and CSD could accommodate ServML type of activities. The setup included cHents running modified version of Symbian OS Contacts, and Network side handling the storage, updating and notification.

The main finding from the study was that without estabHshing standardised ways of creating, accessing and transmitting information across, the system wUl not be reHable or fast enough to provide a satisfactory user experience. A recommendation was therefore made to both explore better mechanisms for managing the information, and possibly rely on the packet based transfers such as GPRS.

SOAP based proof of principle

Extending on the GSM based proof of principle a further SOAP proof of principle was carried out utilising HTTP, TCP/IP and SOAP in order to develop a simple forums service. This forums service used SOAP over SMTP and a simulated maU deHvery mechanism (that in turn used HTTP) to overcome some of the difficulties with the quaUty of service of wireless.

The parsing of the XML based SOAP protocol on the cHent side was not carried out with a fuU XML parser at this time, instead a simple regular expression engine was used, further work on alternatives to parsing and the use of compressed forms of XML are Hkely to be research topics in the future.

The main finding from the study was that with the use of simple API's wireless services could be deHvered extremely quickly. Also the flexibUity of SOAP services on the server side of the architecture aUowed for services to be developed extremely quickly in a matter of days instead of weeks. Such services are also attractive for developers as they can be used by a number of different devices, however it is important that developers have guidance on the constraints of creating services that wUl be appHcable to the wireless platform. Conclusion

Symbian stands along with many others at the start of the road towards what has been named 2^nd generation Internet; this new Internet wiU no doubt provide greater support for wireless services. Symbian is ideaUy positioned to develop some of the standards and API's for the cHent/server technologies that wUl enable the wireless facUities of this new Internet.

It would be pointless to create new technologies for this as there are already several key buUding blocks, such as SyncML and XML, and basic candidate technologies such as PKI and SOAP that can be used for the framework. Standards and best practices for the use of the technologies and the development of the "glue" to combine them are the chaUenges for Symbian. A modular distributed framework is required with generaHsed API's that can support other standards if they emerge later.

Wireless services are Hkely to be communication based, hence some of the services that provide Identification and Identity are Hkely to be key in these new generation of services. Also the market for such services is much less technology Hterate and so another key chaUenge is to deHver the technologies in a user-friendly way.

Section H

An illustration: how the ADS System framework is used in making a telephone call

The ADS system enables Bob to reach AHce even when the telephone number for AHce is temporarUy or permanently not appHcable, so long as Bob has AHce's ADS Number. The approach is shown in Figure 7, which is a flow chart showing the possible events associated with making a telephone caU using the ADS system.

A brief walk through the flowchart foUows:

1. Bob's ADS system mobUe phone calls a phone number for AHce directly after looking it up in its local contacts database.

2. If the cached number for AHce is correct, and the caU passes the access control (i.e. caU-screening mechanism) described above, then the caU is put through.

3. If the cached number rings the wrong person, then Bob might apologise and hang up the caU (or the wrong person's device might automaticaUy teU Bob's phone that Bob is not known, saving Bob from having to speak with someone he does not know). He must then manuaUy choose to "refresh" the ADS Number of the person he is calling (i.e. go to the server and obtain up to date, replacement information). If he is calling a number with no associated ADS Number, he has to use traditional methods to trace AHce.

4. If the number is unobtainable, the ADS system phone automaticaUy makes a data caU to the ADS system server.

5. The ADS system server receives a data caU from Bob's ADS system phone. (Where both AHce and Bob have separate servers, then the data caU from Bob routes to Bob's server first, which in turn routes the data caU to AHce's server). The data caU includes the foUowing data: (i) AHce's ADS Number; (U) Bob's ADS Number and (Hi) an information "password" which is unique to AHce. The server tries to find AHce's ADS Number. If it cannot be found, the server returns an error "invaUd ADS Number". If AHce's ADS Number exists, the server searches the database for the information "password". If it does not find it, it returns only pubHcly avaUable information to Bob. If the "password" is found, then Bob's ADS Number is put in AHce's contact Hst (see Table 2) in a group associated with the password. If Bob's ADS Number does not exist, he is encouraged to create one to enable him to pass AHce's caU-screening. Bob's ADS Number is cached to pass to AHce's phone when it next accesses the server (or is sent immediately if AHce is addressable). The server looks up AHce's current telephone number, and gives Bob the number if Bob has the required access rights (e.g. depending on the group Bob has been placed in by AHce (e.g. friends, business etc.)) If Bob has no specific access rights, then he is returned just AHce's pubHc information.

6. Assuming Bob is given an up to date number by the server, that number replaces the out of date number held locaUy on Bob's device. Bob's device then automaticaUy caUs the updated number for AHce it has received from the server. Conventional switched telephony or VoIP networks are used for this.

7. AHce's phone rings, and screens Bob's caU, only aUowing the caU through if Bob's device is both authenticated (e.g. recognised as Bob's device by virtue of a unique and ideaUy secret feature of Bob's device, known to AHce's device) and also authorised (i.e. AHce is wUling to speak with Bob; for example, she is on vacation and is aUowing through only caUs from friends, a class to which Bob has been aUotted).

The ADS System: ADS Numbers An ADS Number is the most prominent and pubHc aspect of the ADS system. It is in one implementation an address on a web server — for example www.indirect.com/AHce. (Other less visible approaches are also possible). This address is in effect a pointer to entity specific data held on the web server, in this case, AHce's information. ADS Numbers can be included on printed business cards and handed it out at meetings, and included in vCards and beamed from one device to another. ADS Numbers can be any text or number string; multiple aHases are possible, aU relating to a single root ADS Number.

In addition to the ADS Number, an entity can also hand out a piece of data that is usuaUy restricted to entities in just one of that entities Groups. For example, AHce could hand out not only her ADS Number, but also her direct dial phone number. That information, although not persistent in the same way as an ADS Number, can fulfil a number of important roles: first, it can be used to reach AHce in the conventional way. Secondly, it can be used as the "password" described in the telephone caU example at point C.5 to aUow a first time caUer to be placed into an appropriate group.

Section I

An illustration: The ADS System Database

The database is at the heart of much of the ADS System's extensibUity. Each piece of data on the server (the "i-server") has an associated tag (or name) which defines its meaning. The tags ("i-tags") Hve under a unique category name that is aUocated by Symbian to ensure that the global namespace is not poUuted.

The database is divided into a set of categories. TypicaUy, each category is created and owned by a different appHcation. Within each category, each piece of data has an associated tag (or field/ attribute) and an associated Hst of groups ("i-Groups) aUowed to access the data. The appHcation owning the category is free to invent whatever tags it chooses and to extend the database remotely using a standard protocol, giving complete extensibUity, although it may have to pubHsh these attributes to ensure interoperation with other services outside the framework. Any constraints of a particular device (e.g. quantity and formatting of incoming data) can be handled by the cHent based appHcation, enabling the database to be generic.

The foUowing table, Table 1, is an example appHcation view of AHce's i-Data. This data is about AHce. Some information is entered by AHce (e.g. her name) . Other information is entered automaticaUy (e.g. location information from Bluetooth pods). A view of this database would be provided on AHce's mobUe device to aUow her to manage her data.

Table 1

<img file="WO0217652A2_D0004.tif" />

<img file="WO0217652A2_D0005.tif" />

Note that although there are many i-Groups, there are only two overaU dimensions to this information — pubHc and private. PubHc information (i-Group = "aU") is avaUable to anyone with a web browser. It is what AHce would write on a business card (or a home version of the same). When AHce gives her ADS Number out at meetings and parties, she does not have to add a phone number or any piece of data giving access to one of her i-Groups (earHer referred to as a "password"). The advantage of not doing so is that the people she gives her card to wUl not end up in her contacts database (although those she does give private access to will end up there eventuaUy, as described above). This is a good way to operate if AHce is providing a pubHc service — perhaps AHce is a plumber or buUder.

Some fields can contain multiple objects and can be thought of as container fields. For example, the 'Photos' field might contain aU of AHce's many hundreds of personal photographs. The server than presents a table to AHce, showing thumbnaUs of aU of the photographs and enabling AHce to aUocate viewing rights to particular groups or individuals. Each photograph is aUocated a unique number, aUowing it to be identified. The unique number can be thought of as an anonymous tag, aUowing AHce to restrict viewing rights of objects in a container field to appropriate groups or individuals. For example, say AHce only aUows a particular photo of herself on the server to be seen by Bob; Bob's browser enquires of the server which photos he can view and is returned this special image; anyone else enquiring as to which images they can view is not shown this image. Appointment Hsts wUl also contain multiple entries and can also be thought of as containers. Allocating anonymous tags to each entry, with associated viewing (and possibly writing) rights is therefore also required.

As noted, sensitive information is only avaUable to people in certain i-Groups; aUowing AHce to control what data they see. There are two methods of making contacts into members of a particular i-Group. The first way is that whenever AHce wishes to, she can change the level of access of a current contact - perhaps promoting Bob from "business" to "friend". AHce's device wiU report this to the server, and then Bob wUl be given this new information when he next contacts the server (or it wiU be pushed to his device if technology aUows). As described above, AHce can also hand out a piece of data to Bob that is usuaUy restricted to people in just one of her i-Groups (say her direct dial phone number). Then the server wUl vaUdate this information when Bob comes to use it together with AHce's ADS Number, and wUl add Bob's detaUs to AHce's Universe (see Table 2 below). Bob's detaUs will then be downloaded to AHce's mobUe device when AHce comes to re-fresh her ADS system wireless information device, or may be pushed to AHce's wireless information device. Alice need not have to hand out additional data. For example, if AHce gives Bob her ADS number, then Bob can send AHce a message stating that he would Hke her contact detaUs; AHce can then place Bob into the appropriate Group in her Universe on her local device; that device can then inform AHce's server, which in turn provides Bob's server with AHce's contact and other information appropriate to his group. Bob's server then teUs Bob's device(s).

The ADS System also includes an entire contacts database, referred to as a 'Universe'. It is the Hst of aU the entities known to an entity and to whom access to more private data is to be given. Table 2 below is an example view of AHce's Universe, which shows how contacts are assigned to one or more i-Group, thus defining the level of access they get to AHce's data. AHce can enter this data herself, importing the data from her current PDA or PIM. But the Hst also auto-updates: when someone who has AHce's ADS Number first caUs AHce or uses AHce's ADS Number to read her information, then that person's contact detaUs are automaticaUy placed into AHce's Universe, as explained at C.5 above.

Table 2

<img file="WO0217652A2_D0006.tif" /><img file="WO0217652A2_D0007.tif" />

When one of the people in the Hst above looks at AHce's ADS Number, (using an appHcation on their ADS system wireless information devices), they see a view onto AHce's personal data that is defined by AHce. For example, someone in the business 1 group might see the Table 3 information in their contacts appHcation:

Table 3

<img file="WO0217652A2_D0008.tif" />

AU of the fields except the 'Other Info' field, have come from the i-Server and cannot be altered locaUy. The 'Other Info' field is provided for the local user to keep his personal notes on each contact. This field is not updated when the contact is refreshed.

The user interface of the wireless information device wUl denote in some way the freshness of the data (whether it has recently been updated from the i-Server). For example, a fresh green icon could be used to denote freshness, graduaUy turner brown as the associated data ages. A 'Last Verified' date field could also be used, as shown in Table 3. Section J

The ADS System: Applications

A key strength of the ADS system is the very large range of new functions and appHcations it supports. Some of these are Hsted below. The Hst is not exhaustive and also references for convenience many of the features discussed earHer in this specification.

Some of these functions and appHcations can be implemented today using proprietary technologies. However, by using the ADS system framework with its standard and extensible XML (or simUar) tags, the appHcations can now be constructed simply and in a compatible way. New functions and appHcations can be sent over the air to ADS wireless information devices, making the roU-out of these new functions and appHcations fast and efficient. The net result is that developers can write appHcations using standard tools, can update the extensible database using standard protocols and their customers can be confident that their appHcations can be supported, maintained and extended by others. There is greater potential for economies of scale and reuse of system components than would otherwise be the case.

Table 4

<img file="WO0217652A2_D0009.tif" /><img file="WO0217652A2_D0010.tif" /><img file="WO0217652A2_D0011.tif" /><img file="WO0217652A2_D0012.tif" /><img file="WO0217652A2_D0013.tif" /><img file="WO0217652A2_D0014.tif" /><img file="WO0217652A2_D0015.tif" /><img file="WO0217652A2_D0016.tif" />

Appendix 1

The range and number of potential services and functions which can be efficiently implemented within ADS is very great. In this appendix, we provide a more extensive Hst.

Simple to Use FunctionaHty

<img file="WO0217652A2_D0017.tif" /> Richer Conversations

<img file="WO0217652A2_D0018.tif" />

New telephone etiquette

<img file="WO0217652A2_D0019.tif" /><img file="WO0217652A2_D0020.tif" />

Getting together

<img file="WO0217652A2_D0021.tif" /><img file="WO0217652A2_D0022.tif" />

The social mobile

<img file="WO0217652A2_D0023.tif" />

Filfing in time

<img file="WO0217652A2_D0024.tif" /><img file="WO0217652A2_D0025.tif" />

ou are here now

<img file="WO0217652A2_D0026.tif" /><img file="WO0217652A2_D0027.tif" />