WO2002096056A2

WO2002096056A2 - Mobile community communication

Info

Publication number: WO2002096056A2
Application number: PCT/GB2002/002209
Authority: WO
Inventors: James Edward Lovelace; Martin Christopher Hall; Charles Stuart Malcolm; Michael John Gough; Graham Stirling; Paul Andrew Hodgson
Original assignee: Yakara Plc
Priority date: 2001-05-22
Filing date: 2002-05-22
Publication date: 2002-11-28
Also published as: WO2002096056A3; GB2393882A; AU2002257916A1; GB0112435D0; GB0326970D0

Abstract

A system and method for providing community services to mobile user terminals (14) including routing and translating messages. The service provision is performed by an application/server (10, 16) dependant on group context attributes (11) that may relate to group membership and availability of service features. The context attributes including the service features can be configured by users by sending messages to the application/server and by selecting templates. A cross-network subsystem (18) links instances of the application/server to a plurality of telecommunication networks (19) that route messages to mobile terminals.

Description

Mobile Community Communication

The present invention relates to telecommunications and, in particular, to communication within mobile communities.

In the field of communication, people naturally organise themselves into groups. For instance, office co-workers, other company members, family, close friends, college friends, people at the rowing club, etc. This has been exploited by news groups, chat rooms and instant messaging services.

The group context is an important criterion in determining the subject and language of discourse amongst the group members. For example, John works with Jack, however John and Jack are also friends who regularly meet for a drink in their local pub. Their communications in the context of the "work group' and their communications in the context of the ^λpub group' differ both in subject and dialogue, despite the fact that in both cases it is still both John and Jack communicating. The contextual nature of group discourse is very advantageous for the people involved. It allows the terminology to be very context dependent and therefore brief. People often use nicknames, and acronyms for people, places, activities and event. For instance "Who's going down the pub tonight, I hear FYC are playing?" reguires the other group members to know which pub is ^Λthe pub' and what sort of music FYC play and what the acronym stands for.

An instance of group context based discourse is where one person is describing their own or other group member' s locations. People describe locations in a group contextual terminology. One can use the term "place" as opposed to "location" to distinguish this usage. A location is a fixed point determined by geographical survey, an absolute description usually expressed in systematic manner such as lat/long, ordinance survey grid reference. Places are group contextual descriptions of locations. Some are translations to other systematic descriptions such as a postal address. For instance John might refer to his place of work as ^λ35 Water Street, Leith' . However most groups for familiar places may abbreviate or use entirely group contextual place names. For instance John might refer to his place of work as 'Yakara' , or simply 'work' . All these place descriptions have meaning within the scope of the group (possibly only that group) and carries with it as a description a heavy dependence on the properties of the group members and, more specifically, the subject speaker.

Linguistics is the study of the structure of speech and language. Linguistics covers many study areas such as syntax analysis, language parsing/semantic analysis. The study of the two or more speakers (inter-locutors) communicating is referred to as discourse analysis. The character of a discourse is that it consists of a series of short context dependent phrases passed back and forth between the speakers. Discourse requires an agreed context between the speakers, as most of the discourse is brief and refers (or even assumes reference) to a common context. This kind of communication is very different to that of "email or news' where the software reflects all of the information in the sender' s submission to the recipients, without applying any semantic analysis. If a discourse is held via email, news group, chat room or an instant messenger, the discourse context is applied purely by the people using the software. The software dumbly transports their messages without applying any semantic analysis or holding any contextual information about the nature of the discourse.

Systems are known in the field of group messaging, location services, chat services and personalised services. Protocols and methods of establishing group calls and managing group calls are known. The use of a database configured with user profiles for maintaining a group call is known, and the use of location as an attribute to control group calls is known.

United States Patent No US5,930,723 to Nokia relates to establishing an expanded group call in a mobile communication system. The network infrastructure receives a group call set-up request, checks whether an expanded group call set-up facility has been activated and initiates the call. United States Patent No US6,032,051 to Ericsson relates to a wireless mobile communication device for group use. Mobile devices share information about their status. The system permits a group member to automatically monitor the status of any other group member, without manually establishing a call with other group members.

International Patent Application No WO01/31964 to Ericsson relates to dynamically controlled group call services to mobile subscribers. Mobile users can establish group call immediately when needed, and the group call area is dynamically modified during the call to accommodate location changes of group members. Mobile users can initiate and participate in group calls without having previous group call subscription and users or software can dynamically and on demand establish, modify group call attributes.

The known systems do not elaborate on further contextual information which is used for configuring and routing group calls. Such systems suffer from a variety of problems related to the narrow scope of their solutions, and the complexity of their set-up and configuration maintenance. In such systems, much of the information relating to the context of communication is lost, resulting in the recipients of communication losing visibility of that contextual information. Both senders and recipients of communications using such systems also lose control of the flow of information.

It would be advantageous to provide a more efficient and 'natural' means for people to conduct their communications, collaboration and co-ordination that preserves and uses the context of the communication, collaboration and co-ordination to enhance the utility of the communication, collaboration and co-ordination.

It would be further advantageous to provide a system that gives users control over the flow of information.

It would be further advantageous to provide a system that self-provisions and can be configured for the user by the user.

It would be further advantageous to provide group communication, collaboration and co-ordination accessible via a range of different input/output devices carried across a range of different communication networks.

It would be further advantageous to provide a system that allows service providers to deploy a range of services and to add and remove services without interrupting existing service provision.

In this document and claims, the term 'translate' is defined as acting on a message by one or a combination of: • Leaving the information in the message as it is; or • Replacing information in the message; or • Tagging information in a message; or • Adding new information to the message; or • Re-formatting information in a message; or • Formatting information in a message for presentation; or • Deleting information from a message; or • Screening information from a message.

In this document and claims, the term 'group game service' is defined as a group available game or suite of games services, including the management within the context of the group of game score history, or re-useable points accrual.

It is an object of the present invention to provide group related services within communities while preserving and using the context of the group.

It is an object of the present invention to provide self- provisioned group related services within communities.

It is a further object of the present invention to provide group related services within communities accessed from a range of telecommunication networks.

According to a first aspect of the present invention, there is provided a mobile community system comprising:

• a plurality of mobile terminals;

• means for storing a group context attribute;

• a configuration means for configuring said group context attribute;

• an application server means for providing a plurality of group related services, wherein at least two of the services are different, in co- operation with said mobile terminals responsive to said group context attribute;

• a communication means for connecting each of said terminals to the application server means.

Preferably said application server means further comprises:

• a means for translating a message responsive to a stored group context attribute; and

• a means for routing a message responsive to a stored group context attribute.

Preferably said configuration means is responsive to the selection of a template.

Preferably said configuration means is adapted to co- operate with a mobile terminal to configure a group context attribute.

Preferably said configuration means is responsive to the content of a message from a terminal.

Optionally said application server means is adapted to record system usage data and configure a group context attribute responsive to said stored system usage data.

According to a second aspect of the present invention, there is provided a cross-network system for connecting the application server means to a plurality of telecommunication networks, the cross-network system comprising:

• a means for storing routing rules; • an in-bound message queue connected to said application server means;

• a connection agent means connected to each telecommunication network for:

selecting and routing messages to said in-bound message queue responsive to said stored routing rules; and

routing messages to a telecommunication network responsive to receiving a message from said application server means.

According to a third aspect of the present invention, there is provided a method for community communication from and to a plurality of mobile terminals comprising the steps of:

• storing a group context attribute;

• configuring said group context attribute;

• providing a plurality of group related services, wherein at least two of the services are different, in co-operation with said mobile terminals responsive to said group context attribute;

Preferably said method further comprises the steps of:

• translating a message responsive to a stored group context attribute; and

• routing a message responsive to a stored group context attribute. Preferably said step of configuring is responsive to the selection of a template.

Preferably said step of configuring further comprises the step of co-operating with a mobile terminal to configure a group context attribute.

Preferably said step of configuring is responsive to the content of a message from a terminal.

Preferably said method further comprising the steps of recording method usage data and configuring a group context attribute responsive to said stored method usage data.

Typically said group context attribute relates to the availability of group related services to members of a group.

Alternatively said group context attribute relates to a user's membership of a group.

Alternatively said group context attribute relates to a user's role within a group.

Alternatively said group context attribute relates to a place.

Alternatively said group context attribute relates to a group related event.

Alternatively said group context attribute relates to a terminal status.

Alternatively said group context attribute relates to a terminal identifier. Alternatively said group context attribute relates to a user account identifier.

Alternatively said group context attribute relates to a preferred network connection.

Typically said group related service is a chat service.

Optionally said group related service is a group decision making service.

Optionally said group related service is a group member finder service.

Optionally said group related service is a group event reminder service.

Optionally said group related service is a group content sharing service.

Optionally said group related service is a group game service.

According to a fourth aspect of the present invention, there is provided a method for connecting said application server means to a plurality of telecommunication networks, the method comprising the steps of:

• storing routing rules;

• selecting and routing messages to an in-bound message queue connected to said application server means responsive to said stored routing rules; and • routing messages to a telecommunication network responsive to receiving a message from said application server means.

According to a fifth aspect of the present invention, there is provided a computer program comprising program instructions which when run on a computer constitute the system of the first aspect of the present invention.

According to a sixth aspect of the present invention, there is provided a computer program comprising program instructions which when run on a computer constitute the system of the second aspect of the present invention.

According to a seventh aspect of the present invention, there is provided a computer program comprising program instructions for causing a computer to perform the method of the third aspect of the present invention.

According to a eighth aspect of the present invention, there is provided a computer program comprising program instructions for causing a computer to perform the method of the fourth aspect of the present invention.

In order to provide a better understanding of the present invention, an embodiment will now be described by way of example only and with reference to the accompanying Figures, in which:

Figure 1 illustrates in schematic form a mobile community system, a cross-network sub-system and user terminals connected through telecommunication networks to the system, in accordance with a preferred embodiment of the present invention. Figure 2 illustrates in schematic form stored group context attributes in accordance with a preferred embodiment of the present invention.

Figure 3 illustrates a flow chart representing the method of sending a message between terminals.

Figure 4 illustrates in schematic form several instances of the community communication system connected through a cross-network subsystem to multiple telecommunication networks.

Figure 5 illustrates the in-bound message flow to instances of the community communication system from telecommunication networks via connection agents.

Figure 6 illustrates a flow chart representing a method for connecting the community communication system with telecommunication networks while handling an in-bound message.

Figure 7 illustrates the out-bound message flow from instances of the community communication system to telecommunication networks via connection agents.

Figure 8 illustrates a flow chart representing a method for connecting a community communication system with telecommunication networks while handling an out-bound message.

Figure 9 illustrates in schematic form XML (extensible Markup Language) Parser technology used for message translation. Table 1 illustrates XML document definitions.

Table 2 illustrates document translation definitions.

Table 3 illustrates service features available to each template.

The invention is a system that translates and routes messages according to context attributes associated with groups and users. A cross-network subsystem connects instances of the system to multiple telecommunication networks.

The preferred embodiment is a suite of mobile lifestyle applications that provide fun, easy and compelling ways to communicate with groups of friends, family and co- workers.

The preferred embodiment's applications enable private groups of people to vote, share, send reminders, chat, play games or find each other. Anyone can create a group and invite people they know to join their groups.

The preferred embodiment supports access via GSM (Global System for Mobile communications) / GPRS (General Packet Radio Service) and GPRS/EDGE (Enhanced Data-rate for Gsm Evolution) networks and handsets, and can provide a consistent service to users throughout migration to third-generation UMTS (Universal Mobile Telecommunications System) technologies. The preferred embodiment is a white-label product. This means that a service operator can overlay their preferred branding on top of the functionality of the services.

The preferred embodiment is designed as a carrier-class solution, and supports a wide range of user-access means including messaging technologies such as GSM SMS (Short Messaging Service, MMS (Multimedia Messaging Service) and Email, as well as mobile browser technologies such as WAP (Wireless Application Protocol) and cHTML (compact Hypertext Mark-up language) and fixed line access via Internet browser and instant messenger technologies.

The preferred embodiment interfaces with operational support systems (OSS) such as Billing and CRM (Customer Relationship Management) systems.

The following parts of the preferred embodiment are described herein.

1. Message routing and translation.

2. Self-provisioning of multiple interactive group services.

3. Text expansion.

Although the embodiments of the invention described with reference to the drawings comprise computer apparatus and processes performed in computer apparatus, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code of intermediate source and object code such as in partially compiled form suitable for use in the implementation of the processes according to the invention. The carrier may be any entity or device capable of carrying the program.

For example, the carrier may comprise a storage medium, such as ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example, floppy disc or hard disc. Further, the carrier may be a transmissible carrier such as an electrical or optical signal that may be conveyed via electrical or optical cable or by radio or other means.

When the program is embodied in a signal that may be conveyed directly by a cable or other device or means, the carrier may be constituted by such cable or other device or means.

Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant processes.

With reference to Figure 1, software stored and executed on a server is shown. The storage 10, which may be a hard disk, RAM or a network storage device, stores program modules and data. The data structures include group context attributes 11. The program modules include a service provision module 12 for providing a range of different services (including multiple copies of the same service), a configuration module 13 configuring the group context attributes, a translation module 14 that has access to the group context attributes and a routing module 15 that also has access to the group context attributes.

A central processing unit (CPU) 16 accesses the storage and executes the program modules. The CPU can communicate through a communication unit 17 to a cross- network subsystem 18 that is further connected to several telecommunication networks 19 which in turn connect to user terminals 20. The terminals are typically mobile terminals, but may also be terminals at a fixed location.

Although in Figure 1 the server is shown as being in one CPU/Storage unit, it may be distributed across more than one platform, over more than one processor and storage medium.

With reference to Figure 2, the stored group context attributes 11 are shown. The group context attributes may be a data structure for storing such attributes that is empty.

With reference to Figure 3 that shows the flow chart 30 of steps performed by the system, a group context attribute is stored 31, and the configuration module configures the group context attribute 32. On receiving a message 33 through the communication unit from a user terminal, the translation module translates the message 34 using the stored group context attributes. Next the routing module routes the message 35 (using group context attributes) and the message is further transmitted 36 to the recipient terminal. In configuring the group context attribute, the configuration module can be triggered and controlled by the content of a message from a terminal. The content of the message can indicate the selection of a template and the group context attributes can include a set of service features defined by the template.

Message routing and translation

Effective message translation and routing are critical to the success of a mass-market message driven community service. The preferred embodiment is a system that hosts personal communities and supplies them with services. The system has two components associated with providing message translation and routing. These are the 'cross- network subsystem' and the 'content translation support components' .

Routing overview

The system requires its services to be available to mobile telephone handset owners on a widespread easy access basis. To achieve this the routing of messages to and from various networks needs to be handled effectively. This is the role of the cross-network subsystem component. This level of accessibility is integral to the success of a mass-market message oriented product.

Furthermore the cross-network subsystem allows operators to easily introduce new or remove existing links to mobile telephone networks without interrupting the service to existing users. This feature is necessary also, as the users expect a very high level of service availability and the service operators need a quick and cost effective means to increase or modify service connectivity.

Translation overview

The system requires its services to be easy to use. The users must be able to interact with their personal communities and use the associated services without learning jargon, reading user literature, or memorising complex menu systems and usage practices.

The system needs to support a wide range of interaction terminals to achieve the level of accessibility necessary. Typically this includes: -

• Internet accessibility to/from both personal computer and interactive television Web browser. • Mobile accessibility to/from mobile telephones and wired or wireless personal digital assistants (PDAs) . • Mobile telephone handset access can be sub-divided into messaging access, browser access and voice access. • Messaging access can be via SMS messaging, and its successor technologies EMS (Electronic Messaging Service)/ MMS (Multimedia Messaging Service). • Mobile telephone browser access via WAP/XHTML (extensible HyperText Markup Language) or i-mode™ by NTT DoCoMo (cHTML) enabled browsers. • Mobile telephone voice access, using mixed audio and DTMF (Dual Tone MultiFrequency) key driven interaction via a computer telephony interface. The above technologies are 2G (2^nd Generation) and 2.5G service access mechanisms. The advent of 3G (3^rd Generation) UMTS mobile telephone services will further expand the service access mechanisms required by users of the system.

These varied access mechanisms provide a challenge to achieving intuitive user interfaces, as information entered in an intuitive manner by one access mechanism such as SMS messaging can be viewed as garbled, low quality and even unintelligible when viewed via another access mechanism, such as Web browser access.

The system' s content translation support components work to bridge this gap. They provide a means to expand user brevity or contract user verbosity to suit the target device the user is using to access the preferred embodiment.

Design of the cross-network subsystem

The cross-network access subsystem gives personal communities the ability to communicate in both directions with the handsets registered and active on multiple networks. Each of the networks must be connected to the cross-network access subsystem either via a fixed link for instanced to a network' s SMS message centre or via a mobile terminal registered on the network, such as a GSM modem.

The preferred embodiment can be viewed through the standard 4-layer application server provision (ASP) service model. This comprises of the service, application, platform and integration layers of an ASP service. The cross-network subsystem is an integration layer component. It is one of several subsystems that link the first and second aspects of the present invention to peripheral systems that are necessary to support its function.

The design of the cross-network subsystem specifically allows multiple SMS links from many network operators to connect to a server farm. The server farm can host multiple unique instances of the preferred embodiment's application software. Each unique application software instance usually has a distinct brand and service specialisation and is operated by or on behalf of a distinct customer (service owner) . It is usual for each service to be made available on distinct contact numbers (both standard telephone long codes or short codes) synonymous with the service, for messaging (SMS/EMS/MMS) and voice access. Similarly distinct URL (Uniform Resource Locator) / URI (Uniform Resource Identifier) are normally offered on a per service basis.

The diagram shown in Figure 4 illustrates the role played by the cross network subsystem 41 in linking heterogeneous 3rd party network messaging subsystems 42 with specific link technologies 43 to multiple server installations 44 of the application software hosting in turn multiple branded services 45 for specific customers. There is a standard interface 46 between the platform/application layer 44 and the interface layer 41.

The internal structure of the cross network subsystem consists of three elements. A standard messaging plug, a standard messaging socket (to accept the plug) , and link in turn to the platform' s hosted application software and the accompanying watcher component.

The standard messaging plug consists of a code base that can be easily modified by application developers to cater for each new network-messaging link that must be connected. The code base has been set up to cater for the four European Telecommunication Standards Institute (ETSI) approved SMSC protocols, SMPP (by Logica), CIMD (by Nokia) , UCP/EMI (by CMG) and SMS2000 (by SEMA) . The plug maintains a generic interface to the cross network subsystem socket code. This interface remains unchanged and together a customised plug and socket form and connection agent task. The connection agent task can read and write to Java Messaging Service (JMS) queues and thereby send and receive messages for transport to and from the SMSC link serviced by a specific connection agent task. The JMS queues link to the preferred embodiment's core and provide orderly transport between each connection agent task and each customer's application/server installation.

Connection agents and queues

The cross network subsystem is a distinct integration layer component separated from the platform and application layer components by the JMS queues. Each customer application/server installation maintains an in- bound and out-bound JMS queue for that installation.

Figure 5 shows in-bound message flow from networks to applications via connection agents. With reference to Figure 5, when a connection agent task 51 receives an in- bound message from the network 52 that it serves, it examines the called party number set by the sender (long code or short code) and thereby determines the customer application/server 53 that should receive that message and therefore which JMS queue 54 to write to. This is done by reference to routing rules 55 made available to the connection agent.

Figure 6 shows the flowchart 60 of the steps performed during the in-bound message flow. The routing rules are initially stored 61. On receiving 62 an in-bound message, the connection agent accesses the routing rules 63 and selects an in-bound message queue 64. It then routes the message to the in-bound message queue 65.

Figure 7 shows out-bound message flow from networks to applications via connection agents. With reference to Figure 7, when a customer's application/server installation 71 prepares to send a message to a particular user, it resolves the appropriate connection agent 72 to send to by referencing routing rules 73. This establishes the JMS queue 74 the message must be written to in order to reach the connection agent for the network 75 the user is a member of.

Figure 8 shows the flow chart 80 of the steps in the out- bound message flow. The customer application/server installation accesses routing rules 81 in order to select the connection agent 82 and send a message to the appropriate connection agent queue 83. The connection agent receives 84 the out-bound message and sends 85 the message to its linked telecommunication network. Neither the core nor the cross-network subsystem has hard coded routing logic. Instead, the core and the cross network subsystem are made to be configurable so that administrators can instruct them to route messages according to an installation specific routing policy.

The following are two possible routing policies.

1. An administrator may decide on a per-customer perservice and least-cost basis which network a message should be routed through, trying to send messages out through the network that the recipient belongs to (in order to avoid charges for inter-network SMS transfer) .

2. A customer may come to the provider of the system with a special commercial relationship with a Telecoms network operator already in place, and may wish to configure their system to route all out- bound messages through the one operator.

Message routing

A routing table holds all configuration data that allows an administrator to apply the message routing policies for a customer.

Sometimes a particular customer may have a special billing and charging relationship with a particular telecommunications network operator. In this case, the system must allow a routing override so that SMS messages for all networks can be transmitted through the preferred operator. The routing table in the application/server installation customer database allows this. The table has five columns, and has an entity for each telecommunications network operator currently connected to.

The columns are defined as follows: GSM Country Code; GSM Network Code; Network ID; Link ID; and Reply-To Short Code.

The GSM Country Code and the GSM Network Code form the primary key.

When the application/server installation sends an SMS to a user, for instance as a response to a user submitted command such as 'WHO', it performs the following steps. The software looks up the user details in the member table in the customer database and identifies the network operator the user is contracted to. The value in the member table is a GSM Country and Network Code tuple. The software then runs a query on the routing table using the GSM Country and Network Code tuple. The query returns a Network Identifier and a Link Identifier. These are used to form a selector to place the message in the correct out-bound JMS queue to reach the network identified by the routing rule.

This mechanism is configured for 'normal' operation when each telecommunications network operator has its own Network Identifier against its own GSM Network Code and an appropriate Link Identifier. The Link Identifier must be a connection agent link that goes to the network in question. To achieve a policy override (that is when the customer has a special relationship with a particular telecommunications network operator) , all Network Identifiers and Link Identifiers are stripped out and replaced with the details of the telecommunications network operator with whom the customer has a special relationship. In this way, the lookup always returns the same Network Identifier and Link Identifier, regardless of the user's contracted network. No special logic is required to achieve a policy override. Under this design it is a data-driven feature.

Design of the translation support components

The translation support components consist of a set of XML document translation definitions. These define the valid form of an in-bound XML document to an XML parser and how the parser can translate a document provided in that formed into a different out-bound well-formed document. This mechanism is public domain functionality of XML parser technology. The specifications of the XML document translation definitions are unique to the design of the preferred embodiment.

Figure 9 shows the application of XML parser technology to the preferred embodiment using document definitions.

The document definitions are described in Table 1.

With reference to Figure 9, when a user interacts with the system their in-bound command/message is converted to the appropriate document associated with their current client access device type. Interaction by the system and others is subject to translation into a document 91 associated with their current access device type, e.g. SMS. Information sent to other users 92 or retrieved by them is translated in accordance with their access device type, e.g. MMS, by the system.

For instance, consider an SMS message user might send to his family group the message "Lets meet at the dead cow burger bar for lunch". Sending this as an in-bound chat message with the following SMS message "Chat Lets meet at the dead cow burger bar for lunch". If his wife received the message as a pushed MMS message, the message may well appear with her husband's avatar (appropriate to that family group alone) , the text of the message, and perhaps a link to the map of the shopping mall in which the dead cow burger bar in question was situated.

The translation definitions listed m Table 2 are developed as part of the Translation Service Components. These allow the system to convert information internally between any of the above document forms.

Responding to sender/recipient attributes

The system discussed above applies translations to messages between users to make best use of the capabilities of the access mode they are using. Therefore for example, an SMS text originated vote set up by a group member will be sent to another group member with a WAP-Push capable handset as a WAP screen containing the voting options. Each group member has a number of context attributes that are pertinent to their user profile, as well as further attributes relating to their membership of each group. Therefore, for a given group member there are attributes that are the group specific and user profile derived. Group attributes can be static, such as 'role' (for instance rowing club treasurer) and dynamic such as current place, presence (active recent communication/not recently communicated) , group oriented state (not rowing, rowing) etc.

The translators make use of content from the message and content from the group context to create out-bound messages. These are passed through a filter so that the out-bound content is appropriate to the recipient's device.

Typical group context attributes are:

Place attributes: - Each group allows places to be registered and named (or names imported into the group from 3rd party data sources/databases) . User locations provided to the system from a 3rd party location derivation technology can be imported and translated into the context of the group and published only to other group members as a group related place name. A group member' s place is only released to other group members under the location conditions they have agreed to for that group. A place attribute may be a group member place name, derived from combination of group place context attributes held in a group and a group member location update. If the user is a member of several groups each of which supports a different definition for a place that is geographically the same location, then each group will report the 'place' related to specifically that group for the same location.

The system supports place-oriented alerts, proximity alerts, non-proximity alerts, time-oriented alerts, and time-place-combined alerts. It can provide a sequence of place transit reports in real-time or captured and later reported.

Time based attributes:- The system can support time-based events such as timed alerts. It can integrate with client and Internet based diary applications, generating and importing definitions of alerts, meetings, and appointments between the system and 3rd party applications (such as PDA organisers or diary managers such as that built into Microsoft® Exchange™) .

Communication and peer-action events: - The system supports events triggered from group peers performing an action, such as chatting, voting or using any of the services. For instance the user could register an event to notify them if another group member enters the group and downloads a ring-tone. The system as in this example allows the user to combine a response with the event to be triggered when the conditions that raise the event become true. These can be quite specific. For instance the event/action for a family group might be to let a parent group member know if a child group member leaves school premises within the hours of school by more than 200 yards and if true to open a voice call between the parent and the child, predicted with the alert text to the parent explaining to them the purpose of the spontaneous call.

Self-provisioning of multiple interactive group services

Two important aspects in establishing a successful community service are earning the trust of the user, and empowering them. For a user to use a personal community service they need to feel their communication space and activities are private to them and their co-group members. It is also important that they can rely on the service being accessible, highly available and reliable in doing what it has been instructed to do. In short the system must protect their privacy and provide a high quality of service. Without the trust of the user, the service will either not be used or infrequently used. The system has several design features to provide privacy control and ensure a high quality of service.

With trust established, the next important aspect of the system is the empowerment of the user. This involves receiving commands from the user (including commands in the content of messages to the system) to allow them to control the creation or removal of their groups, control group membership and direct the groups to their purpose. Furthermore, to control the services that are available to themselves and other group members, and to evict unruly members, or disband groups they own. These are important features of the design of a personal community service that differentiate a personal community system such as the preferred embodiment from a mediated public chat forums. In the later the user is not empowered to a similar degree.

Self-provisioning, is an important aspect of the user empowerment. It allows users to create groups (including by sending messages) for their own purpose and invite users of their choice and control the membership during the group lifetime. Self-provisioning is also important to the operators of the system, as it removes the need to create groups, mediate, or control their membership on behalf of the users. Self-provisioning is also important as it by this means that the number of groups increase and the use of the system develops.

The system incorporates in its design user oriented privacy control, high quality of service features, and user empowerment features such as self-provisioning .

Setting up a group

The objective is to make setting up a group as simple as possible for a user, and yet to also make the group as useful as possible by capturing attributes of the group and its members. The user can create a group by clicking a 'create group' button on the Web/WAP (or cHTML) site pages. The user can also create a group by sending a message (SMS/MMS) containing the group creation command syntax. Although this description focuses on creating a group, it applies with little change to configuration of an existing group.

Any and all of the above user activities are translated from the specifics of the user input device into an internal generic XML command for creating a group. This command captures the intent of creating a group, the name of the group to be created, and the identity of the group creator. The command also allows for an optional group template to be specified. The characteristics of the new group are based on properties specified at the time of the group creation. These are held as parameters associated with the group creator, in their personal profile, and in the group template if one was specified. For instance: Jack may be a user using the system as a facility made available to him via his employer. As such the employer may have specified that no location updates will be available in groups outside working hours, for any groups created by members of their staff through this facility. This restrictive parameter will pass through to Jack's personal profile and be a constraint on the properties of the groups he can create. The company may also have applied some positive parameters. For instance each person' s employee contact details may be available in their personal profile. This allows Jack to create groups that use this information. If Jack specified a template for his group, he can further define the scope of use of his group. For instance, the template selected may restrict other members from deleting group assets, such as shared reports. The template may however allow group members to get work-time only place information to help colleagues find each other.

Processing the device access button click or in-bound message generates an internal generic XML command for group creation. This is received by the XML command processor and parsed by an XML parser such as Xalan-Java XSLT (an XSLT translator developed by the Apache Software Foundation project of the same name, under the Apache XML initiative). The parsing triggers the group creation actions such as extracting personal profile parameters, and template related parameters. These parameters characterise the instance of the new group created. The new group is added to the groups owned by the creator (in this instance owned by Jack) . Once the group is created, Jack can proceed to invite some colleagues. Some groups may be open, and not require an explicit invite/invitation response to join. These "open" groups simply allow people to join without an invite. This is an example of another parameter that can be specified by selecting the appropriate template for the style of group the creator intends. The template mechanism is a short hand. It allows a series of parameters to be collected that create a useful distinctive group type under a single template name. This makes creating groups with many detailed properties a simple matter of selecting the desired template by name. If no template is specified a default group template is assumed.

By processing the user interaction with the access device into an abstract command, expressed in XML (a World Wide Web Consortium (W3C) standard) , the system can be further developed allowing modification of the user interaction/presentation layer without causing core system functionality update work. By using XML to express the command and its parameters, the system can make use of a flexible data description language to define all existing (and any future) commands, and readily available parsers to process the commands. Modifying core functionality similarly does not affect access device handling code. This internal structure improves the ease of evolution of the system's services.

Privacy control and high quality of service

Whilst the accessibility, availability and reliability aspects of a high quality of service are necessary along with privacy control to gaining user trust, the high quality of services features of the design of the system are aspects that are implemented using recognised industry standard techniques of system structure and software design to achieve the high quality of service goals.

Privacy control, and self-provisioning

The user can interact with two different types of groups, public groups that are open to all to join and personal groups. A public group is generally not a forum in which you meet friends or work colleagues. The membership of a public group is generally strangers who have a common interest, such as a pop idol fanzine. The membership of a personal group is generally people you actually know. As a result the type of conversation and the frequency differ between public and personal groups. As public groups are open to anyone to join, the main privacy protection involved is protecting the users phone number from the group and allowing them to use a pseudonym. A user can leave a public group at anytime and if the owner of the group could disband the public group at anytime. The users of public groups apply their own filter to their dialogue and use of group services, as this is a public context. A user can only join a personal group if either they have created the group themselves and are therefore the group owner, or if they have received and responded to an invite to join another person's group. Therefore if a user creates a group they can control to whom invites are sent and whether or not anyone else in the group can also issue invites. The system also states in the invite, the identity of who is inviting you to join their group, the purpose (if appropriate) of the group, and the information the group needs from you (from your personal profile). A user, receiving an invite to join another's group, can therefore review the terms of joining the group and if satisfied can proceed and respond to the invite. Once they have joined the group, only the information stated in the invite will be open to that group. A user can maintain different nicknames for different groups if they wish.

User empowerment

To empower the user a balance must be struck between power and easy of use. The design of the system supports features that provide the user great flexibility to control the types and features of the groups they create, without taxing them with too much detail.

The two key mechanisms that support user empowerment within the system are the service generation wizard and rapid service development.

Service generation wizard To set up a group and join a group must be easy for the system's usage to widespread. The system expedites the process of setting up groups by giving users template groups to create their own instances of. Each template has a set of group access and usage parameters and associated services. By selecting a template (including by sending a message to the system) the user can select a whole set of features by making a single option choice.

Table 3 shows examples of template selected service features. In Table 3, 'X' indicates the service feature is present in an instance of a group built from this template. The user can create a group of any of the types shown in the columns by selecting the optional group type in the 'create group' command. If the parameter is omitted, then the same group type as created last by that user is inherited. If this is the first group they have ever created then the system default group type is assumed.

The self-provisioning aspects of the system allows users to create their own groups of a specific type that inherit the properties related to that type, or fall through to a default group type.

The 'Chat' service feature enables group members to participate in group messaging. Chat relies on the concept of "presence" - defined as whether a given member has been active in a group. If a user is present when a chat message is sent to a group, they automatically receive the message. If a user isn't present when a chat message is sent to a group, they receive a one-off 'new chat in ur group' notification that details how they can start chatting. This ensures that only those group members who are actively using the service receive group messages.

Users who have already received a chat notification (and not participated) will only receive a further notification after a minimum of 24 hours. The Service Manager can control the "presence" timeout (i.e. the length of time that a user is considered present), and the notification period if required.

The service features give the group tools for communication, collaboration and co-ordination.

The 'Vote' service feature acts as an enabler for making group decisions. Members can issue a time-limited vote that consists of a question and a series of options. Responses are automatically tallied by the system and the outcome is relayed to group members. Furthermore, members can track who's voted for what and monitor progress.

The 'Remind' service feature provides a simple calendar mechanism for group related events. When a reminder is triggered, group members receive a one-off "ur missing out" notification that details how they can check their reminders. Users who have already received a reminder notification (and haven't checked them) will only receive a further notification after a minimum of 24 hours.

The 'Play' service feature enables a group member to initiate a game with other members of a group. Each group member receives a message that asks whether or not they wish to play. Those members that respond within a time window are considered participants and their details are forwarded to a 3rd party game. The 3rd party game now assumes control of the user dialog and initiates the game .

Draw is a simple game based on the notion of a 'Wild West' gunfight whereby participants draw by sending an SMS with the text 'draw' . The game is carried over three rounds and at the end of each round, players are awarded a point for each player that was slower to respond.

The 'Find' service feature provides the ability to discover the location of members within a group. Without a location feed, 'Find' operates a manual policy where group members are prompted to set their current location.

The 'Share' service feature enables group members to download shared items (e.g. operator logos, ring tones, pictures) onto their own, or another group member's compatible handset.

Rapid service development

The design of the system allows for rapid service development. It allows the service operator to introduce and brand new services into a deployed system. Rapid service development consists of the ability of operators of the system to easily introduce, modify or remove service definitions and the ability to easily add, or modify the branding of the service experience.

The structure of the system consists of a set of atomic service features that are linked to form the suite of services that form the user experience. The user can select services available to their group at group creation time by selecting a template that incorporates the combination of desired service features. Some groups may allow the owner the power to make subsequent modifications of the service definition and add or remove services from the group.

The service operator can introduce new services to the users of the system by introducing new service features into the system. To add new services the operator:

1. Loads the new service features. This adds new entries in the service feature table (see Table 3) .

2. Publish new template definitions that make use of the new service features.

3. User can create groups from this point of the new template type that make use of the new services.

The service operator can apply branding to the user experience of the system. This will then be made available via all supported access devices, SMS, WAP and Web etc. The second component of rapid service development is the support by the system of easy brand of services. The ability to add or modify service branding is called 'white labelling' .

The system has an XML based design for separation of service content and core functionality from presentation (i.e. branding). The design consists of XML translators to apply branding to message oriented clients and XHTML support for browser based clients (Web/WAP/PDA) .

Text expansion

Currently the text messaging service is the major part of the data services revenue earned by mobile operators. Text messaging at the moment consists of the SMS service. This is being augmented by both EMS and MMS services within the year in many European countries. Each of these messaging services will be interoperable. EMS and MMS services can transport a richer content and therefore between compatible handsets will provide a higher quality messaging service.

The system supports personal communities and provides them with a range of lifestyle assisting services. An expected component of any community is the basic chat service. The young have adopted SMS as an effective and entertaining communication medium. Their use of the service has led to the evolution of a slang/phonetics based language. This achieves two goals, that of increasing the level of expression between the interlocutors and reducing the amount of typing. The later is important as the handsets are small and restrict the speed that the user can type.

As part of the translation capabilities of the system supporting the expansion or contraction of text and other content to reflect the access device capabilities, the 'Text Expander' component provides the system with a translator between the SMS chat vernacular and full English, as might appear on a Web page. Design of the Text Expander

Once again the system makes use of XML parser technology to achieve the translation of an input document and an output document. In this case the system uses a SMS Chat XML document that consists of a series of free text components interspersed with well know SMS chat contracted phrases and 'smilies'. This well formed document is constructed by the SMS client access component of the system that processes the in bound text message and converts it into an internal SMS XML document. This document can be translated using an XML parser to plain English, for use in the free text component of any of the documents supporting the various client access modes. The XML parser translation is applied to achieve this transformation.

The XML SMS Chat document is a definition for supporting SMS Chat messages alone, the XML SMS document supports the wider SMS mobile community messaging and includes all the commands a user can instruct the system with. An XML SMS Chat document is typically referred to from within and XML SMS document. The XML SMS Chat document describes the chat text being submitted. The XML SMS document describes the 'chat' command that and refers to the XML SMS Chat document for the submitted text from the user.

As with the Translation support components, the Text Expander consists of a set of an XML Char document translation definition. This defines the valid form of an in-bound XML Chat document to an XML parser and how the parser can translate a document provided in that formed into a plain English or back again. This mechanism is public domain functionality of XML parser technology. The specifications of the XML Chat document translation definitions are unique to the design of the system.

Further modifications and improvements may be added without departing from the scope of the invention herein described.

Claims

1. A mobile community system comprising:

• a plurality of mobile terminals;

• means for storing a group context attribute;

• a configuration means for configuring said group context attribute;

• an application server means for providing a plurality of group related services, wherein at least two of the services are different, in cooperation with said mobile terminals responsive to said group context attribute;

2. The system of Claim 1 wherein said application server means further comprises:

3. The system of any previous Claim wherein said configuration means is responsive to the selection of a template.

4. The system of any previous Claim wherein said configuration means is adapted to co-operate with a mobile terminal to configure a group context attribute.

5. The system of any previous Claim wherein said configuration means is responsive to the content of a message from a terminal.

6. The system of any previous Claim wherein said application server means is adapted to record system usage data and configure a group context attribute responsive to said stored system usage data.

7. The system of any previous Claim wherein said group context attribute relates to the availability of group related services to members of a group.

8. The system of any previous Claim wherein said group context attribute relates to a user's membership of a group.

9. The system of any previous Claim wherein said group context attribute relates to a user's role within a group.

10. The system of any previous Claim wherein said group context attribute relates to a place.

11. The system of any previous Claim wherein said group context attribute relates to a group related event.

12. The system of any previous Claim wherein said group context attribute relates to a terminal status.

13. The system of any previous Claim wherein said group context attribute relates to a terminal identifier.

14. The system of any previous Claim wherein said group context attribute relates to a user account identifier.

15. The system of any previous Claim wherein said group context attribute relates to a preferred network connection.

16. The system of any previous Claim wherein said group related service is a chat service.

17. The system of any previous Claim wherein said group related service is a group decision making service.

18. The system of any previous Claim wherein said group related service is a group member finder service.

19. The system of any previous Claim wherein said group related service is a group event reminder service.

20. The system of any previous Claim wherein said group related service is a group content sharing service.

21. The system of any previous Claim wherein said group related service is a group game service.

22. A cross-network system for connecting an application server means of any previous Claim to a plurality of telecommunication networks, the cross-network system comprising:

• a means for storing routing rules;

• an in-bound message queue connected to said application server means; • a connection agent means connected to each telecommunication network for:

23. A method for facilitating mobile communities using a plurality of mobile terminals comprising the steps of:

• storing a group context attribute;

• configuring said group context attribute;

24. The method of Claim 23 further comprising the steps of:

• translating a message responsive to a stored group context attribute; and

• routing a message responsive to a stored group context attribute.

25. The method of any previous Claim wherein step of configuring is responsive to the selection of a template.

26. The method of any previous Claim wherein said step of configuring further comprises the step of co- operating with a mobile terminal to configure a group context attribute.

27. The method of any previous Claim wherein said step of configuring is responsive to the content of a message from a terminal.

28. The method of any previous Claim further comprising the steps of recording method usage data and configuring a group context attribute responsive to said stored method usage data.

29. The method of any previous Claim wherein said group context attribute relates to the availability of group related services to members of a group.

30. The method of any previous Claim wherein said group context attribute relates to a user's membership of a group.

31. The method of any previous Claim wherein said group context attribute relates to a user's role within a group.

32. The method of any previous Claim wherein said group context attribute relates to a place.

33. The method of any previous Claim wherein said group context attribute relates to a group related event.

34. The method of any previous Claim wherein said group context attribute relates to a terminal status.

35. The method of any previous Claim wherein said group context attribute relates to a terminal identifier.

36. The method of any previous Claim wherein said group context attribute relates to a user account identifier.

37. The method of any previous Claim wherein said group context attribute relates to a preferred network connection.

38. The method of any previous Claim wherein said group related service is a chat service.

39. The method of any previous Claim wherein said group related service is a group decision making service.

40. The method of any previous Claim wherein said group related service is a group member finder service.

41. The method of any previous Claim wherein said group related service is a group event reminder service.

42. The method of any previous Claim wherein said group related service is a group content sharing service.

43. The method of any previous Claim wherein said group related service is a group game service.

44. A method for connecting an application server means of any previous Claim to a plurality of telecommunication networks, the method comprising the steps of: • storing routing rules;

• selecting and routing messages to an in-bound message queue connected to said application server means responsive to said stored routing rules; and

• routing messages to a telecommunication network responsive to receiving a message from said application server means.

45. A computer program comprising program instructions which when run on a computer constitute the system of Claims 1 to 21.

46. A computer program comprising program instructions which when run on a computer constitute the system of Claim 22.

47. A computer program comprising program instructions for causing a computer to perform the method of Claims 23 to 43.

48. A computer program comprising program instructions for causing a computer to perform the method of Claim 44.