WO2000079826A1

WO2000079826A1 - A method and an arrangement relating to groups of communicating users

Info

Publication number: WO2000079826A1
Application number: PCT/SE2000/001255
Authority: WO
Inventors: Jörgen ANDERSSON
Original assignee: Incirco Ab
Priority date: 1999-06-21
Filing date: 2000-06-15
Publication date: 2000-12-28
Also published as: WO2000079826A8; SE0001387D0; AU5861200A

Abstract

Services obtained include group voice messaging and group talk. Private voice mailboxes can be accessed and used by groups of people. When a new message is added or a user wants to initiate a group talk session, an SMS is sent to group members to inform them that they should check the group voice mailbox or inform them that they should call in to join the group talk.

Description

A METHOD AND AN ARRANGEMENT RELATING TO GROUPS OF

COMMUNICATING USERS

TECHNICAL FIELD

The present invention relates to a method and a digital telecommunication system where groups of users of communication devices exchange information between each other.

BACKGROUND OF THE INVENTION

Present day telephone systems for conveying messages to groups of people and systems for performing simultaneous conversations with several people have many disadvantages .

In order to get in touch with, and convey a message to a group of people, it is necessary to get in touch by making several telephone calls, one to each designated person. This is, needless to say, both time-consuming and expensive .

Setting up of so-called conference calls is, in addition to being time consuming and costly, also very complex and usually calls for a large measure of planning ahead for the participants.

SUMMARY OF THE INVENTION

It is an object of the present invention to overcome the problems as discussed above. This object is achieved by inventive systems, methods and computer software according to the appended claims.

The system, which in the following will be denoted as the mobile community, offers mobile group communication services, enabling groups of people to stay in touch, coordinate events and share information anywhere and anytime via mobile devices such as mobile phones and mobile internet devices. anytime via mobile devices such as mobile phones and mobile internet devices.

The services offered include group voice messaging which offers private voice mailboxes that can be accessed and used by groups of people. When a new message is added, an SMS is sent to group members to inform them that they should check the group voice mailbox. An e-mail is sent to users who do not have a mobile phone.

Another service offered is group talk which allows users to talk to each other simultaneously on mobile phones and fixed-line phones. When a user wants to initiate a group talk session, an SMS is sent to group members to inform them that they should call in to join the group talk.

Another service offered is group text messaging which allows group messaging via SMS. The sender only needs to send a single SMS which is sent to the group members.

Also a group web service is provided, which includes text chat, group contact lists, calendar and information lists, such as e.g. recommendations regarding restaurants, cinemas etc. The group web services are accessible via mobile and stationary internet devices such as WAP-phones and desktop PC's.

Groups are created and managed via a web site, and users may create and participate in any number of groups with friends, business colleagues, project team members, family members, sports club members etc.

Privacy is obtained through authorization, where each member is identified through a user ID and an access code. Typically, for mobile phone users, their mobile phone number acts as user ID.

Groups of users may be either static or dynamic. Static groups are preferably used when a user wants to leave messages to, or communicate with, the same people regularly. Dynamic groups are used when recipients are unique for each message or call. Dynamic groups exist for one message or call, and are created by selecting recipients via the WWW or via telephone.

Broadcast groups are used for one-to-many communication, where one single member, the messenger, is allowed to leave messages in the group mailbox. Other members can read messages and leave responses to the messenger only.

Advantages obtained with the present invention, Mobile Community, include access at any time and anywhere, convenience in that a user may communicate with several people simultaneously via a single phone call.

Furthermore, cost is reduced, as compared with previously known systems, in that the caller only need to pay for a single call since recipients call in to the system and pay for their calls themselves. The ease of use is also an advantage, since administration of groups is handled via World Wide Web (WWW) pages on a server accessible from anywhere via the internet .

BRIEF DESCRIPTION OF THE FIGURES

Figure la shows a schematic view of a system according to the invention.

Figure lb shows a schematic end-user view of a system according to the invention.

Figure lc shows a schematic administrator view of a system according to the invention. Figure Id shows a schematic view of an application server included in a system according to the invention. Figure le shows a schematic view of a SM server included in a system according to the invention. Figure If shows a schematic view of a group talk service included in a system according to the invention.

Figure lg shows a schematic view of a group message service included in a system according to the invention. Figure 2a shows a schematic process view of a system according to the invention. Figure 2b shows a schematic view of SM server processes in a system according to the invention.

Figure 3a shows a schematic hardware deployment view of a system according to the invention. Figure 3b shows a schematic node configuration view of a system according to the invention.

Figure 3c shows a schematic multiple node configuration view of a system according to the invention.

Figure 4 shows a schematic view of service application layers in a system according to the invention.

Figure 5a shows a schematic view of load balancing in a system according to the invention.

Figure 5b shows a schematic view of load balancing in a system according to the invention. Figure 6 shows a schematic view of system interfaces.

PREFERRED EMBODIMENTS

For illustrative purposes, the detailed description of the present invention is separated into a number of different parts. To begin with, the system architecture of the Mobile Community system will be described.

Following that, a description of the system interfaces with telecommunication networks and service providers. Then follows a detailed description of the functions performed by the system in use. The embodiment of the invention will be exemplified in connection with cellular telecommunication systems adhering to the GSM standard, and hence a number of abbreviations will be used that are known to the skilled person, and will not be explained in detail. Nevertheless, some vocabulary, terms, definitions, and abbreviations used in this description are as follows :

Abbreviation Description

CORBA Common object request broker architecture

EJB Enterprise Java beans HTML Hypertext mark-up language

HTTP Hypertext transport protocol HTTPS Secure hypertext transport protocol

JDBC Java database connectivity

JSP JavaScript pages

MS Mobile station, i.e. a cellular phone. MSC Mobile switching center.

ORB Object request broker.

RDBMS Relational database management system.

RUP Rational unified process.

SM Short messages . SMS Short message services.

SQL Standard query language.

SSL Secure sockets layer.

WRB Web request broker.

WWW World-wide web, the Internet. XML Extended mark-up language.

The architecture is most easily described using five views, which represent different ways of observing the system: a logical view, a process view, a deployment view, an implementation view and a use-case view. The logical view describes the architecturally significant parts of the design model, such as its decomposition into subsystems, service packages, and classes. The process view describes the system's decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes) . The deployment view illustrates the configuration and a mapping of processes to each processor. The implementation view describes the decomposition of the software into layers and subsystems in the implementation model. Sometimes referred to as component view. The use-case view illustrates how the software actually works by giving a few selected use cases or scenarios. The view also explains how the various model elements contribute to the functionality. The use cases or scenarios given here are chosen because they represent some significant, central functionality of the final system, or for their architectural coverage (they exercise many architectural elements) or to stress or illustrate a specific, delicate point of the architecture . The logical view

Figure la illustrates the architecturally significant parts of the design model, such as its decomposition into subsystems and service packages. For each significant package, its decomposition into classes and class utilities is described.

Architecturally significant classes are introduced and their responsibilities described, as well as a few very important relationships, operations, and attributes.

Figure 1 shows the major components of the system: End User interface components, Administrator interface components, Mobile Community services (with web services for end users and administrators and community services like group talk and group messages) , Network provider for SMS services, and SMPT provider, for sending e-mail. End user

As figure lb illustrates, there are four different methods of end user - system interaction: WWW browser, Mail client, Phone, and Mobile phone. The user uses the WWW browser to connect to the system to set up and manage his/her profile and communities and the mail client is used for different notifications sent from the system.

A mobile station may receive notification messages (SM) from the system via the network providers switching center. A mobile phone is used to manage the community services like group talks and group messages. A normal phone can also be used, like the mobile station, to manage the community services .

Administrator As figure lc illustrates, there are three different methods of administrator - system interaction: WWW browser, Mail client, and Mobile phone. The administrator uses the WWW browser to connect to the system to perform system administrative tasks. The mail client and the mobile phone are used for different notifications sent from the system.

It shall be noted that the Mobile Community Services system will interact with the network provider and the SMSC using a secure protocol.

SMTP provider

The SMTP provider is a mail server that route mail sent from the mail services to users mailboxes on the Internet . Mobile Community Services (MC services) :

Web server/Java Server Pages

The web server handles incoming HTTP requests; retrieves information, and sends it back to the client. If the HTTP-request is targeted at a JSP (Java Server Page) , the request is handed over to the JSP-engine.

Application server

As figure Id illustrates, the system runs in an application server but no business or data logic is implemented as Enterprise Java Beans. The application server is used as execution environment for Java Server Pages and for the Connection Pool only.

The application server comprises of the following three major components (access layers) : JSP engine (compiler/ - executioner) , Business services, Data services, and Connection Pool.

JSP engine

The JSP engine is a Java class that creates a Java servlet code out of the jsp-code and then compiles it into a Java servlet class. The class code is cached for performance .

The Business services

Design packets in the business services layer contain most of the service logic of the system. All access of data services from the user services layer is handled through the business services layer.

The following design packets are developed within the Mobile Community Services system: crypto, sms, mail, administrator, alarm, broadcast, community, event, grouptalk, invitation, message, news, statistics, trafficdata, user, and util .

Data services

The data services design packets consists mainly of components and classes to access entity objects from the database. This includes creating new, modifying, and removing existing entities as well as searching and listing functionality. The packets are not listed here. For a complete list of available packets, consult the database design. Examples are: User, Event and Invitation.

Mail services

The mail services include services for sending email (SMTP) . The mail is sent through the SMTP provider. SM services

As figure le illustrates, the SM server provides functionality to send SM to mobile phones from a client application in a LAN. The system consists of an SMS server that acts as an interface to the network operator's SMS gateway and a number of SMS clients that serve applications with the possibility to send SM requests to the SMS server.

Group talk system As figure If illustrates, the Group Talk System provides a service for community groups to join specific group calls. The service is available from a mobile phone or a normal fixed phone. The group talk services does not use any of the application server functions. The business and data logic is called directly from the CT run-time environment through a DLL .

The following functionality is provided within the Group Talk services: Group call capabilities, Recording voice messages, Pre-recorded audio messages for information from the system to the user, Touch-tone input for login to system, setting up and joining a group call, and Dial out enabling the system to make calls to users and play pre-recorded messages.

Group message system

As figure lg illustrates, the Group Message System provides a service for community groups to record and listen to voice messages located in a message store. The service is available from a mobile phone or a normal fixed phone.

The group message services does not use any of the application server functions. The business and data logic is called directly from the CT run-time environment through a DLL.

All voice messages is stored as flat binary files in the file system of the OS of choice. META- information about recorded messages is stored in the RDBMS . The realisation and implementation of this message is store is TBD . The following functionality will be provided within the

Group Message services: Recording voice messages, Listening to voice messages, Pre-recorded audio messages for information from the system to the user, Touch-tone input for login to system, recording messages and navigation through system functions, and Dial out enabling the system to make calls to users and play prerecorded messages

RDBMS

All system information, except the recorded voice messages for the Group Message Services, is stored in a relational database (IBM DB2) . Any META information about recorded voice messages is also stored in the RDBMS.

Message store

All voice messages for the Group Message Services are stored as flat binary files in the file system of the OS of choice. META-information about recorded messages is stored in the RDBMS .

Process view

This section describes the systems decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes) . Figure 2a shows the major processes and groupings thereof in the system.

Processes This section describes of the heavyweight processes in the system, shown in figure 2a.

Web server and application server

The web server and application server is described elsewhere . SM Server

As figure 2b illustrates, the SM server application consists of one permanent lightweight process running the administration interface. From the GUI thread a server thread is started and stopped. The server thread handles new client connections and administrates the requests.

The GUI and server threads exchange data mainly by using a common instance of a class containing the server characteristics . Beside these single threads, there are an arbitrary number (upper limit controlled by the server administrator) of session threads that are started and stopped as clients connect and disconnect. The server thread creates the session threads, one for each client connection. The session threads take over the client connections and execute the requests . As response is received from the SMS Gateway and forwarded to the client, the session thread stops. RDBMS

All system information, except the recorded voice messages for the Group Message Services, is stored in a relational database (probably Oracle) .

Any META information about recorded voice messages is also stored in the RDBMS.

CT Services

These are the group message and group talk systems.

The server (or rather, service) is build on the run-time engine of the selected CT-platform and uses the same business and data logic as the web application.

Deployment view

Figure 3a shows the system's physical network (hardware) configuration on which the software is deployed and run. The configurations indicate the physical nodes (computers, CPUs) that execute the software, and their interconnections (bus, LAN, point-to-point, and so on.) Included is also a mapping of processes from the process view onto physical nodes.

In detail, the system is described with different configurations, called minimum configuration and multiple node configuration.

Figure 3b illustrates a "minimum" configuration, which is in reality not a single node due to the two parallel systems and the Data server and SMS server. All telephony related services execute in one node and the web services, the application server and the SMS server execute in the other. Depending on the type of toolkit/api used in the phone-related applications, the phone services may be able to use the application server for distributed business objects and access to the RDBMS.

Phone services server

The telephony server is equipped with several PRI -cards and DCB-cards (for conferencing) . These cards are connected through a SC-bus for internal communication between CT-resources .

Web services server

All presentation logic is implemented as Java Server Pages (JSP) , handled by the JSP engine installed in the web server.

All business and data logic for the web-services is implemented as normal Java classes, not EJB .

In a single node configuration, this node is configured with a web server and the application server of choice. The SMS service may also execute in this server, but there is a choice to install and execute this application on a separate server.

Data server

In the Data server executes the RDBMS. This is also the server where all messages are stored.

Multiple-node configuration

Figure 3c shows a "multiple-node" configuration, where the amount of concurrent and registered users demands multiple web servers and phone servers. The servers in the multiple node configuration is explained below.

Phone services server Adding another server scales the Phone Services . The problem with adding another external node is to expand the SC-bus, which connects the PRI and DCB resources. Connecting the different computer nodes with an external ATM-bus solves this.

Two computers can be connected directly via ATM, but if three or more computers are to be connected, this is best done through an ATM- switch.

Application server All business and data logic for the web-services is implemented as normal Java classes, not EJB .

In a multiple node configuration, separate servers are used for the application servers. Adding another physical server with yet another application server running on it scales the business and data logic. The application servers handle the scaling and load balancing through AS to AS communication.

Web server

Adding yet another physical web server scales the web servers. The incoming requests for web resources are distributed between the web servers through round-robin configuration of the DNS , or by doing a sequentially redirecting of the requests through a front -door web application.

All web servers have the same host name, but different IP-addresses. The DNS-server that resolves a host name to an IP-address does this in "round-robin" order so that the requests are distributed to all available web servers .

Database server In the Mobile Community system, adding another server does not scale the database. The database should run on such hardware that it could be upgraded with more CPU, disks and memory when needed, preferably from the beginning to avoid minimum downtime because of hardware upgrades .

Message store server

To scale the message store (where all voice messages are stored as files) , more disk space is achieved by adding yet another physical computer with RAID-disks.

The MC-system must be aware that more disks have been added for the voice files. Changing the system parameters (configuration) for the MC-system does this.

SMS server This is the node where the SMS server executes. This server is able to handle thousands of SMS-requests and does not need to be scaled into multiple nodes for the MC-system. The SMS server may very well execute in one of the application server computers, because of the low impact on the system resources.

Implementation view

Figure 4 shows the decomposition of the software into layers and subsystems in the implementation model.

A number of different layers exist within this project. All layers will be described below. The picture below shows how the different applications are built on top of different layers.

Layer descriptions

Description of the application layers in the system. Phone users IVR

The mobile and fixed phone users use an IVR (Interactive Voice Response) system to navigate through the different applications and functions available through the phone interface .

CT applications

The CT applications are running on top of the selected CT runtime engine.

HTML GUI

The GUI (Graphical User Interface) for web browsers is built with HTML (Hypertext Mark-up Language) and served through a web server. JSP

The JSP (Java Server Pages) handles the presentation logic (servmg/buildmg HTML) and is responsible for instantiating and executing the business logic objects.

Business and data logic The business and data logic is implemented as normal Java classes and not as EJB, because of performance and because the CT application has problems accessing EJB from their run-time environment.

Size and performance Below is a summary of target performance such as throughput and response times.

Scalability

The Application server should be scalable by hardware. For detailed description of scaling, see "Deployment view" above.

Load balancing

Load balancing can be configured for three services in the system: Web servers, Phone servers, and Application servers . Load balancing of web servers

As illustrated in figures 5a and 5b, the incoming requests for web resources are distributed between the web servers through round-robin configuration of the DNS, or by doing a sequentially redirecting of the requests through a front -door web application.

All web servers have the same host name but different IP- addresses. The DNS-server that resolves a host name to an IP-address does this in "round-robin" order so that the requests are distributed to all available web servers.

All first web requests from a web user goes to one web server and is handled by a "front door" application. The "front door" redirects the user sequentially to the next available web server in the system. All following web requests from the user is handled by that server. The web servers in this solution must be configured with different host names as well as different IP-addresses. Load balancing of phone services

The incoming phone lines are configured according to the standard "Line hunting" procedure that distributes the incoming calls sequentially to the available PRIs.

A conference resource handler in the CT-application will allocate the conference resources. The conference handler will store status information about all conference resources in RDBMS. Analysing which device that for the moment has most idle conference resources makes the selection of conference device. Load balancing of application server

Load balancing is built into the application server software. If another application server is installed, this is initially configured to be aware of the other existing application servers. The load balancing is then handled by the software through AS to AS communication.

Fault Management

Software and hardware will be monitored by an SNMP fault management system. SNMP-agents will be installed for each server and hardware device. The agents will monitor the devices for errors and report to an SNMP management application if errors occur. Overload and congestion is also to be considered as an error.

The following hardware devices and software can be monitored over SNMP. Monitored Hardware includes: PRI- boards , Audio Conference boards, Network controller boards, CPU-boards and ATM-switch. Monitored Software includes: CT-application, Webserver, Application server, SM server, RDBMS, and Windows NT. Failure recovery

The system is not configured with any fail -over functionality. For maximum safety and minimum down-time: install multiple network adapters, use double power supply units in the servers, all disks should be RAID- configured for safety (1, 5 or combination) , and CT- servers shall continue to execute Group Talk and Group Message calls even though another CT- server is out of service .

System interfaces Figure 6 illustrates how the system according to the present invention interfaces other network elements such as an MSC, a local exchange, an SMS-C and the Internet.

The system connects with the MSC(s) of one GSM operator through a number of EURO-ISDN devices (30B+D.) Telephony interfaces

The Mobile Community service is accessed via one GSM number. This number is routed to a number of ISDN PRA interfaces (2 Mb, 30 B+D) residing in one or several MSCs. The MSC(s) must support line hunting over the full set of PRA lines. The normal initial configuration is with 6 PRA.

Preferably, both incoming calls (to access the Mobile Community service) and outgoing calls (to make dial-up notifications for Group Talk from the Mobile Community system) are used. If outgoing calls are not possible via this PRA interface, an alternative is to use ISDN PRA lines to the fixed network.

For outgoing calls, a feature called "time distribution of dial-out notifications" is available with the Mobile Community system. This feature distributes dial -out notification calls within a certain group. The time difference between calls within a group is 0.5 seconds. This is done in order to avoid congestion on the GSM paging channel within one cell.

The specification of the interface includes: Euro- ISDN, CRC4 activation and no ecco cancellation equipment between the MSC and the Mobile Community system.

This interface is carried between the operators MSC switch site(s) and the Mobile Community operation center via G.703 lines.

SMS interface

The Mobile Community system interfaces a Short Message service provider via the interface "UCP over TCP/IP" . This interface has SSL encryption. The Short Message service provider could be the GSM partner, but it is also possible to use other service providers in case cross- network SMS are not available within the country where the system is set up. The SMS originates from a specific server located inside the Mobile Community system firewall. A port must be opened in the firewall for this communication. The port number is configurable.

The Internet or any leased TCP/IP connection can be used for the communication between Mobile Community system and the SMS-C. "SMS queuing" is used to handle SMS load peaks .

Internet interface Internet (WWW) can be used by the Mobile Community system users to configure their groups, invite more members, create new groups etc.

Hypertext Transfer Protocol (HTTP) as defined in RFC 2616 and RFC 2068 is used.

System functions

Following is a description of preferred functions of the Mobile Community system. The description will use the so- called Rational Unified Process (RUP) . RUP is a project work model by Rational Corporation. Quality and a secured delivery plan are major concerns of the work model. Two basic elements of this use case driven work model are the actor and the use case.

Definition of Actor An actor instance is someone or something outside the system that interacts with the system. An actor type defines a set of actor instances, in which each actor instance plays the same role in relation to the system.

Definition of Use case A use-case instance is a sequence of transactions a system performs that yields an observable result of value to a particular actor. A use-case class defines a set of use-case instances.

The following actors have been identified: Administrator, Guest, User, and Instant user.

Administrator

An administrator is a registered and authenticated person that has the privilege to administrate the Mobile Community system, or specific parts of the system. Use cases involving administrators almost always require strong authentication. The preferred method of administrator - system interaction IS via a WWW browser.

Guest A guest is a person who accidentally or determined surfs ' the Mobile Community web site or calls the system for registration. Being a guest seldom requires authentication. As a guest registers for member services he is upgraded to user actor. There are three different preferred methods of guest - system interaction: WWW browser, and Mobile or stationary phone User.

A user is a registered and authenticated person who actively uses the member services provided by the Mobile Community system. Use cases involving users most often requires authentication. There are three different preferred methods of user - system interaction: WWW browser, and Mobile or stationary phone User.

Instant user An Instant user is a person that is invited to a group talk but that is not registered with the system. Typically, an instant user is a person that is temporarily invited by a user to participate in a group talk. Instant users can never initiate their own group talks. There is one preferred method of instant user - system interaction, that is via a Mobile or stationary phone .

USE CASES

In this section the required system is identified and described. Defining the actors and use cases in the system does this.

Web use cases

These web use cases are use cases related to functions and operations performed at the Internet web site. Web Demo

Actors: Guest.

Purpose : Demonstrate the member services .

Web Company Information Actors : Guest .

Purpose: View company information.

Web Help

Actors: Guest, User. Purpose: Get helpful information and tips.

Description: It shall be possible to obtain help text on most web pages. However, advanced help texts are not required.

Web Register Actors: Guest.

Purpose: Register for member services.

Description: By registering a new user account is created within the system. The guest has the possibilities to register the following data: • Name/alias (mandatory)

• Phone number (not mandatory)

• Email address (not mandatory)

• Anonymity (mandatory. The guest has to specify whether he shall be "visible" or "invisible" in the public functions of the system. Default value is visible.)

• User description (not mandatory, the user may add a short description of himself that is shown in other users contact lists if the user has chosen to be visible as described above) . The guest is not allowed to register an email address or a phone number that already is used in the system by another user.

If he registers a mobile phone number, the system will verify, using a random generated access code sent to that specific phone as SMS, that he at least actually has access to the mobile phone he registers.

If an email address is registered a notification will also be sent to that address i.e. this is the only possibility for a user with a non-SMS capable phone to get a notification.

The new user is given a unique member number, which in normal cases is the phone number registered. If he elects not to register phone number, a unique member number is to be generated by the system. This is also the case if the new user registers a non-SMS capable phone. A personal user profile is created describing the provided information, privileges, etc of the new user. If he have received invitations for any communities, he is immediately prompted to join them.

Web Welcome

Actors: Guest, User.

Purpose: To gain access to the member services. Description: This is the web site entry point. Here the user may choose to access either register, login, or view any of the public information web pages like service introduction, demo, or company information.

For example; http://www.incirco.se If the user have received invitations for a community by email and accessed the web site via an invitation URL, the web page is to show a welcome greeting for the invitation.

Web Login Actors: User.

Purpose: User authentication.

Description: Used to authenticate that only registered users gain access to the web site member services. User states unique member number and access code. The user will only be permitted to make a limited number of login trials, then the account will be temporarily blocked. The user is upon success transferred to his start page. If the user was registered from the TUI he is forced to enter missing data (see section 5.1.8) before he is transferred to his start page.

If the user has created any new communities from the TUI he is forced to enter a community name (see below) before he is transferred to his start page. This is also the case if the user has changed name from the TUI since last web login.

My Communities Actors: User.

Purpose: A users personal start page. Description:

• Gives the user an overview of the communities in which he is a member. • Informs of new invitations: A list of the user's pending invitations will be shown. Next to each community there will be a link to click to see more details about the invitation, see section 5.1.19.

• Gives a summation of all community news. For each community the user is member of the degree of anonymity is shown (i.e. if details of the personal profile are hidden for other members or not) . The anonymity degree can be changed using the radio button that is assigned to each community. The "My communities" page contains a string that informs the user when he used the system last time. In this information it is included whether he used the TUI or web interface .

The user's name is displayed on the web interface. Web Complete User profile

Actors: User.

Purpose: To enter missing data if user was registered from TUI . Description: If the user was registered from a phone (fixed or mobile) and it is the first web login after registration, a new web page is opened where he is asked to give additional missing user data. At a minimum he should enter his name or alias. The user is not transferred to his start page until at least his name or alias is given.

Web Enter Community Name

Actors: User. Purpose: To enter the name of a community created via TUI.

Description: If the user has created one or more communities since last web login (i.e. community creation from the TUI) a new web page is opened where he is asked to type the names for those communities. This is done at first login after the creation and is mandatory. The user is not transferred to his start page until a name is given. The system does not perform any checks whether the community name, entered at web interface, matches the spoken community name.

Community Administration

Actors: User.

Purpose: Enable community administration.

Description: A web page containing information and access to community administration functions and operations as invitations, community owner, remove the community, leave the community, modify description of the community, change category of the community and to change name of the community. If the community owner chooses to change the name of a community all members of the community is notified. The notification is performed in the same way as the invitation to the group (but telling the members that the current community name is changed) . All the above mentioned functions and operations are available only to the community owner but to leave the community, which is open to all members.

Note. Preferably, a user can only see the interface for the functions and operations that the user is allowed to perform. I.e. the functions and operations that are assigned to the community owner can only bee seen by the community owner.

My Settings Actors: User.

Purpose: View ones own personal profile. Description: All user data are shown.

From this use case it is possible to

• change anonymity (start of use case Change anonymity) • change access code (start of use case Web change PIN code)

• update personal data (start of use case Personal data)

• quit membership (start of use case Quit membership) . Change Anonymity Actors: User.

Purpose: To change the user's anonymity setting. Description: The user gives the possibility to change the anonymity setting, i.e. whether he shall be visible or invisible to other users when these are using the public functions of the system.

News

Actors: User.

Purpose : Gives the user a summary of community news and updates . Description: For each community the user can view new messages, new members or members who left the community, new community owner, if any members have updated their contact info, etc. Each new Group Message or Group Talk recording notification is attached with a time stamp.

Web Create Community

Actors: User, Guest. Purpose: Create a new community.

Description: The user creates a new community by naming the community. The person may also choose to assign a category to the community and a description of the community. The user may invite members by selecting people from his existing contact list (not possible for a guest) or by entering them manually. The invitation shall contain the names/alias of other invited persons (users or guests) . This is applicable both to the e-mail invitation sent out and on the "New invitation" page on the WEB.

Another way of inviting members is to send them an invitation URL.

If an invited person (user or guest) hasn't replied to the invitation within a predefined number of days (a system parameter configurable by the system administrator) an alert might be sent to the community owner. An alert might also be sent to the invited person. It is possible to configure these alerts independent of each other, e.g. in one implementation of the system both kinds of alerts might be used, but in another implementation, only the alert directed to the community owner might be used.

If the user invites a person with a forbidden number (i.e. the user states a number stored in the "Dialing Rules File") the user shall be notified and that invitation is cancelled.

The creating user becomes the "community owner" .

Note. If a guest sets up a group, no invitations will be performed until the guest has registered. If the guest leaves the system without having registered the group will be removed.

Invite Members

Actors: User. Purpose: Invite others as members of a community.

Description: The community owner may invite additional members to his community by selecting people from his contact list or by entering them manually. The invitation shall contain the names (or alias) of other invited persons (users or guests) and the users that already are members of the group (these are listed as "member" in the invitation) . This is applicable both to the e-mail invitation sent out and on the "New invitation" page on the WEB. Another way of inviting members is to send them an invitation URL.

Mass Invitation

Actor: User

Purpose: Allow the user to invite many members to a group in an efficient way Description: The use case starts when the user select to invoke the user interface for "Mass invitation"

The user selects which persons to invite to the group by specifying their e-mail addresses separated by comma or semicolon (to allow "copy and paste" from e-mail clients) in the in built mail function of the system.

The user can write a message to the recipients of the invitation that will be displayed first in the invitation e-mail (followed by a standard description of the service) .

The user submits the invitation to the system and all recipients will receive the e-mail invitation.

Web Instant Group

Actors: User. Purpose: Allow a user to quickly set up group

Description: From the web, the user can select from his contact list or enter new persons, i.e. instant users, to invite them to the group talk. If the user invites a person with a forbidden number (i.e. the user states a number stored in the "Dialing Rules File") the user shall be notified and that invitation is cancelled.

The instant group that is created shall be saved in the system and the user can initiate a group talk and group messages with the participants in the instant group without having to enter their numbers again. The instant group is replaced the next time the user creates a new instant group. A user can only have one instant group.

Web Join Community

Actors : User Purpose: Allows a user to join a community.

Description: The system prompts the user with new invitations. The user can then choose to

• Join (accept) . • Join (accept) but hide details in the personal profile to other users in the group (only the first name/alias is shown) .

• Not join (reject) . The default value is Join.

For each invitation there is a link to further invitation details, see below regarding invitation details.

Web Invitation Details

Actors : User Purpose: Allows a user to view details of an invitation to which he is invited.

Description: For each invitation the names (or alias) of other invited users and guests that also is invited to that particular community are displayed. If the user is invited to an existing community, the users that already are members are listed as "member" . It is also displayed which of the invited persons that has joined the community and which that haven't.

Web Contact List Actors: User.

Purpose: Allows the user to create and maintain a list of other users .

Description: A user is given the possibility to store contacts in a contact list. The contact list contains other users in the system that manually are added by the user according to the Add contact use case, see below.

For each contact, the contact list consists of the following fields:

• Short Code [digits 1-99] • Note [text field of 160 characters that are defined by the user to describe the contact] Description (the contacts own description of himself) • First Name/alias (used to sort the list alphabetically)

• Last Name

• MSISDN/Member no (Member no if no MSISDN is present) • email address

Only the "Short Code" and the "Note" fields are editable by the user.

Note. Whether the data in the fields of a contact are visible or not is dependent of what the contact has specified when registered (or when modified the personal profile) .

What actually are shown is specified in the UCR of the use case.

The system is able to maintain a list of up to 999 contacts per user. The short codes (1-99) can be assigned to any of the 999 entries in the contact list. The short codes are used to address other users when setting up instant groups on the TUI .

From this use case it is possible to invoke the use cases:

• Add contact

• Delete contact

• Generate short code

• Manually enter short code • Delete short code

• Search contact

• Modify note

Add Contact

Actors: User. Purpose: Add someone to be part of my personal contact list. Contacts can be used to setting up communities as well as "Instant groups".

Description: When a user chooses to add a person to his contact list the first thing the system does is to ask for the telephone number or member number of the person he wants to add. The system then checks whether the corresponding contact is already in the list. If not, the system searches the database for a matching entry for the given number (This is done according to the search contact use case) . If an entry is found that matches the number the user is asked if he wants to add this user to the contact list. In case the found contact has chosen to hide details the user is informed that some fields of the contact are invisible.

If no entry is found for the given number the use case Invite Friend To The System Via SMS, see below or Invite Friend To The System via Email, see below, (depending on if the system searched for a mobile phone number or a member number) is invoked.

The user can also add contacts by selecting other users that are members of the same communities.

Invite Friend To The System Via SMS

Actors: User.

Purpose: To invite a non-registered person to the system. Description: This use case is invoked by the Add contact use case. The user can invite a person to the system without inviting the person to a specific group.

The system informs that an SMS will be sent to the current mobile phone number inviting the receiver of the message to the system. The user is further given the possibility to enter an email address in order to additionally send an email invitation. The email is sent out (with the user's e-mail address as sender. If the user has not specified an email address in his profile he can not use this function) . To become a user the invited person need to register using the TUI or WEB interface as in the normal case.

Invite Friend To The System Using Email

Actors: User. Purpose: To invite a non-registered person to the system. Description: This use case is invoked by the Add contact use case . The user can invite a person to the system without inviting the person to a specific group.

This use case is similar to the use case Invite Friend To The System Via SMS. The difference is that an SMS will not be sent and that the user is informed that he must specify an email address in order to send the invitation. The email invitation is identical to the corresponding part in use case Invite Friend To The System Via SMS. Only users with a registered email address can use this function.

Delete Contact

Actors: User.

Purpose: Remove a person from ones contact list. Description: Removing a user from ones personal contact list is a permanent action; there is no "wastebasket " . The user cannot undo this action.

Generate Short Code

Actors: User. Purpose: To assign a short code for a contact in the contact list.

Description: The user can generate a short code to any of the contacts in his list by using the function for automatic generation of short codes. Lowest available number is assigned.

Manually Enter Short Code

Actors: User.

Purpose: To enter a short code for a contact in the contact list. Description: The user can change short codes manually by entering a new short code in the field for "Short Code". If the user enters a code that is already used for another contact he will be informed by the system that will give him another recommended number (the lowest available number) and show him which contact that is currently owning the short code. The user is informed that if he still wishes to add the selected short code he needs to delete the short code from the existing contact. Delete Short Code

Actors: User.

Purpose: To delete a short code for a contact in the contact list.

Description: If the user chooses to delete a short code the "Short Code" filed is left empty. The deleted short code is then available to assign to another contact.

Send Group Email

Actors: User.

Purpose: Sending Group Email to a community. Description: The user shall be able to send an e-mail from the web when he is logged in to the service.

The e-mail should be sent to all members of the community that have registered to the system with an e-mail address, Only users that have chosen to have their profile visible to other users in that community should have their addresses displayed to others. The sender's name and e-mail address displayed on the sent e-mail should be the community member performing the action.

The user must have an email address registered in order to be able to send a mail, otherwise this function can not be used.

Register On Another Website

Actors : Guest .

Purpose: Register and login to the system from another web site .

Description: The system supports the use of an adaptable area with text fields to be filled out by the guest (name, e-mail address and mobile number) . The adaptable area will be placed on partner sites and integrated with the content shown on that site.

Once the fields are filled out and the guest click on the "log-in button" the guest is forwarded to the login page of the MC system and the user information shall appear in the correct fields. The guest has to review the conditions of membership (or accept without reviewing) and submits the registration request to the system.

International Access

Actor: User, Guest Purpose: To get access to all Incirco country specific sites .

Description: The system (in Sweden) contains a .com page with links to all other Mobile Community system "Web Welcome" sites (see above) in different countries. The guest/user will be directed to the country specific "Web Welcome" site by clicking on the link.

Personal data

Actors: User.

Purpose: Modify ones own personal data. Description: A user may modify his own personal profile.

The user may for example elect to change his phone number. If the mobile phone number is changed, the user will be asked to confirm the new number also as his new member number. However, both these changes require an SMS validation using a temporary code in accordance with the registration procedure. If the user is a community owner and chooses to un-register his mobile phone number he must hand over the owner ship to someone else in that community. Otherwise the phone number can not be un- registered. Change Community Owner

Actors: User.

Purpose: Change to a new community owner. Description: The existing community owner assigns new community owner. All community members are then notified via the "Member news". Only the users that are registered with an SMS capable phone are selectable for taking over the community ownership.

Search Contact Actors: User.

Purpose: To search for a user to add to the contact list.

Description: The user enters phone number or member number of the user he wishes to add to the contact list.

The system searches in the database for a matching entry. If the system finds a corresponding user he is added to the contact list.

Modify Note

Actors: User.

Purpose: To update a description of a contact in the contact list.

Description: The user may add an own description to each contact in his contact list. This use case addresses how a user can add and modify a description of a contact .

Web Introduction Actors: Guest.

Purpose: Introduce and interest a new user to the member services .

Web Logout

Actors: User. Purpose: Logout from the web site member services.

Description: Logout is a permanent action; there is no "wastebasket " . The user cannot undo this action and is transferred to the welcome page.

Web change PIN code Actors: User.

Purpose : To change PIN code

Description: The user may change the PIN code (four digit PIN code) after successful login. The user must first enter the old PIN code, then the new PIN code and finally a confirmation of the new PIN code.

Quit Membership

Actors: User.

Purpose : Enables the user to quit the member services . Description: Quitting is a permanent action; there is no "wastebasket". The user cannot undo this action.

Mailbox

Actors: User.

Purpose: To enable users to view community activities. Description: The system will log messages and member activities. Any user in a community can view the message log to see who have sent a message and when, and also when other members last time accessed the member services and this community. Member List

Actors: User.

Purpose: View list of members in a community. Description: The user can view name, email and mobile phone number of all members in a community. In addition to this information, the user can view all rejected invitations. The user, in the role of community owner, may choose to invite new members or remove members from the community.

Remove Members Actors: User.

Purpose: Remove members from a community. Description: The community owner may remove any member from "his" community. A message is send to the removed members by email (preferred) or SMS. All community members are notified via "Member news". Removing a member is a permanent action; there is no "wastebasket". The user cannot undo this action.

Delete Community Actors: User.

Purpose: To permanently delete a community. Description: The community owner may permanently delete the whole community. A message is sent to all members by email (preferred) or SMS. A recall function is not needed.

Leave Community

Actors: User.

Purpose: Remove oneself from a community.

Description: Any member can remove himself as a member of a community. A message is sent to that member by email

(if he has an email address) and to the community owner. All group members are notified via the "Member news".

Telephony use cases

The telephony use cases are use cases related to functions and operations performed from a mobile or stationary phone.

Phone Register

Actors: Guest, Instant user.

Purpose: To gain access to the service from a phone (fixed or mobile) .

Description: A guest or instant user has the possibility to join the service without having internet access. This use case addresses the case when a guest or instant user wants to register from a phone. A guest will get to this use case from the Phone login use case. An instant user will get to this use case from the Phone welcome instant user use case. Then follows a telephone dialog helping the person to register. Authentication is performed in the same way as in the web register use case. Phone Login

Actors: User, instant user, guest.

Purpose: User: To gain access to the telephony member services and authenticate user. This will be the entry point for telephony services. Instant user: To detect the A-number and route the instant user welcome use case. Guest : To route the guest to the Phone register use case Description: Whenever possible, A-number detection is used to identify the user (or instant user) and the access code is then not required. If A-number is unknown, the user is asked to provide his member number and access code, e.g. using a borrowed (not registered) mobile phone is also handled by this use case.

In case an instant user is detected the use case Phone welcome instant user is activated, see below.

In case the user calls from a non-SMS capable phone the member number and the access code must be given.

In case A-number detection failed the person might be a guest calling to the system for registration. In that case the person is given the possibility to register, and the Phone register use case is then activated.

If the user is asked to enter the access code he is allowed to make only a limited number of trials if wrong access code is given. This holds for both mobile and fixed phones. If wrong access code is given too many times the account is temporarily blocked.

When the user is logged in, the system will perform a check to see whether there are any ongoing group talks . The system also checks if the user has a recorded spoken name or not. If the system determine that the user do not have a spoken name he should be asked to record one. The name is later used in services using spoken names. If the user has any invitations to communities that he hasn't joined or declined the system informs about this. The first time the community owner logs on via telephony services after having created a new community, he is asked to voice record the community name. This is also the case if the user has changed the name of the community on the web user interface.

If there are any new system messages, these will be played.

The user is also informed if he has been removed from any communities . The use case addresses the case where too many users are trying to access the telephony services at the same time thus consuming all system hardware and software resources .

Phone Welcome Actors: User.

Purpose: Main menu of telephony services. Description: The system

• checks if there are any ongoing group talks

• checks if there are any new group messages • tells if there is member news

• guides amongst all telephony functions and operations.

Phone Welcome Instant User

Actors: Instant user.

Purpose: Main menu for an instant user. Description: The system welcomes the instant user to the system. If there is an ongoing instant group talk the instant user will be directed to this. If there are instant group messages the instant user is given the possibility to listen to them. The system will also give the instant user the possibility to register.

Phone Change PIN code

Actors: User.

Purpose : To change PIN code Description: The user may change the PIN code (four digits) after successful login. The user must first enter the old PIN code, then the new PIN code and finally a confirmation of the new PIN code. Phone Join Community

Actors: User.

Purpose: Accepting community invitations via phone. Description: The system checks whether the user has new community invitations that are unanswered. If there exist such unanswered invitations the user is given the choice to join the communities or to decline the invitations. The name of the user that has sent the invitation and the group name are read out (spoken name) for each invitation. If the user chooses to join the community he is asked to specify whether he shall be visible or invisible to other users of the community

If the user neither join nor decline the invitation an alert notification is sent to the user reminding him/her that the invitation isn't replied to. The time delay for the alert is configurable by the system administrator.

Phone Set Up Instant Group

Actors: User.

Purpose: Allow a user to quickly set up a non-defined Group Talk (or Group Message) community.

Description: From the TUI, the user enters phone number/member number of other users and/or phone number of instant users to invite them to a group talk, or group message. If the user invites any person from the contact list with a two-digit code assigned the user can enter the code instead of the whole telephone number/member number.

The system guides the user through a number of prompts and the user interacts with the system using DTMF commands. If the user invites a person with a forbidden number (i.e. the user states a number stored in the "Dialing Rules File") the user shall be notified and that invitation is cancelled. The user is given the possibility to review the instant group, i.e. the names of the members of the instant group are read out, using spoken name. If the group contains instant users or if no spoken name is assigned to a user the corresponding phone number will be read out instead. The instant group that is created shall be saved in the system and the user can initiate a group talk with the participants in the instant group without having to enter their numbers again. The instant group created is saved in the system and replaced the next time the user create a new instant group. A user can only have one instant group defined.

Phone Create Community

Actors: User.

Purpose: Creating a community from the Telephone User Interface.

Description: Users shall be able to set up new static communities via the telephony user interface. This is done in the same way as setting up instant groups via the telephony user interface. If the user invites a person with a forbidden number (i.e. the user states a number stored in the "Dialing Rules File") the user shall be notified and that invitation is cancelled.

The user will be asked to make a recording of the group name, and the group will be given a temporary name, typically a time stamp, that will be displayed on the web interface until the name is updated by the user, see above .

If an invited person (user or guest) hasn't replied to the invitation within a predefined number of days (a system parameter configurable by the system administrator) an alert might be sent to the community owner. An alert might also be sent to the invited person. It is possible to configure these alerts independent of each other, e.g. in one implementation if the system both kinds of alerts might be used, but in another implementation, only the alert directed to the community owner might be used.

Phone Initiate Group Talk

Actors: User. Purpose: Allow a user to use Group Talk.

Description: The user selects any community (or the instant group) to invite for Group Talk. The system will then initiate an outgoing call to all invited users (or instant users) leaving a short message and an email notification. The out dial message will be at least 25 sec long, consisting of a repeated message of an approximate length of 7-10 seconds repeated continuously until the called party hangs up or the time limit (25 sec) is reached. The out dial message might contain the name of the user initiating the Group Talk and the name of the community ("spoken name" usage) . What actually is included in the message is configurable. If no spoken name is recorded for the user the system is "silent" instead of reading the user's spoken name. For line busy calls a SMS will be sent .

Note! Out dial notifications are not performed to non-SMS capable phones !

Then the Group Talk continues, and while waiting for the first person to join the call, for example advertisements can be played.

A Group Talk is automatically recorded by the system during a limited time. The Group Talk recording may be accessed as a standard message later on. The recorded message is automatically deleted after a system set predefined time.

The use case addresses the case where too many users are trying to access the Group Talk service at the same time thus consuming all system hardware and software Group Talk resources .

The use case also addresses the case when the receiving part of the out dial is an answering machine. In this case the out dial shall be aborted. Note! An out dial notification is initiated according to a special sequence. This scheme is given in the UCR.

Leave message

Actors: User.

Purpose : Send a voice message to group members . Description: The user selects which group to address. He then records the message and ends by pressing the # sign. The message is recorded in the Group Message store. An SMS notification and an email notification (if the member has registered the email address) are automatically sent to all group members, urging them to call in and listen to the message. SMS is however not sent to members that still have unchecked messages in that that group. SMS is neither sent to users using a non-SMS capable phone. These users shall receive an email notification if an email address is registered. If no email address is registered the non-SMS capable phone user will not get any notification at all for Group Messages.

Instant user will not receive any notifications.

For community messages, the name of the person doing the recording, and the time, is registered in a message log that is accessible from the web site member services.

Listen To Message

Actors: User, Instant user.

Purpose: Listen to Group Message or Group Talk recordings .

Description: When the user calls m to the service, he is notified that there are new group messages and/or group talk recordings (the system distinguishes between group messages and group talk recordings, i.e. the system informs how many recordings of each type that are available) . For each recording the corresponding group name is read out (this is not the case for Instant group messages and recordings of instant group talks . In that case the spoken name of the user that set up the instant group is read out) . The user/mstant user is asked if he wants to listen immediately or later. If the user chooses to listen immediately he will before the message hear information on when it was created (date and time) . If the user do not want to listen to the timestamp he can press the "#" button and then be directed to the message.

Having listened to the message, the system will give the user the possibility to listen to the status of the message, i.e. what other users have listened to the message (using spoken name) . Note that this is an option. Further, the user has the choice of appending an own message to the previous one (note that this is not possible to instant group messages and instant group talk recordings) . If so, he records the Group Message. An SMS notification and an email notification (if the member has registered the email address) are automatically sent to all group members, urging them to call m and listen to the message.

Each user shall start listening to the first recorded message that he hasn't listened to before. The user can skip messages and jump to the next recorded message.

As a person has listened to a message, this is notified in the message log so that the initiator of the message can see on the web, or listen to on the TUI that the message has reached its intended audience.

Phone Change Name Of Community Actors: User.

Purpose: Change name of an existing community. Description: The user has the possibility to change name of any community he has created. The user can not change name of communities for which he is not the community owner. All members of the community are notified. The notification is performed in the same way as the invitation to the group (but telling the members that the current community name is changed) . Phone Record Spoken Name

Actors: User.

Purpose : Record spoken name .

Description: After having registered the user is prompted to record a spoken name. This recording is used later, when the system needs to present the name of the user over the phone interface.

Phone Personal Settings

Actors: User.

Purpose: To change personal settings from the TUI Description: The user can from this use case change some of the personal settings. These are:

• The spoken name

• The PIN code.

Phone Quit Membership Actors: User.

Purpose : To quit membership from the TUI

Description: The quitting is permanent. The user cannot undo this action.

Phone Change Anonymity Actors: User.

Purpose: To change the user's anonymity setting from TUI. Description: The user gives the possibility to change the anonymity setting, i.e. whether he shall be visible or invisible to other users when these are using the public functions of the system.

Phone Community Administration

Actors: User. Purpose: To administrate communities from the TUI.

Description: The user can administrate communities from this use case. The functions that can be performed is:

• Change the spoken community names

• Create community • Set up instant group

• Invite members

• Leave a community Phone Invite Members

Actors: User. Purpose: To invite additional members to a community from the TUI.

Description: The user can invite additional members to an existing community. The user must be owner of the community. If a user hasn't replied to an invitation alerts are sent according to above section regarding invitation of members.

Phone Leave Community

Actors: User.

Purpose : To leave a community from the TUI Description: The user can leave a community from the TUI. If the user is the community owner he must assign a new community owner or delete the community. Members of the community are informed that the user has left the community. Join Group Talk

Actors: User, Instant user.

Purpose: To join a Group Talk session or an instant group talk session. Description: The user may join a Group Talk either directly after he has logged in using a phone of from the main menu. The instant user may join an instant user group talk from the Phone welcome instant user use case if there are an instant user group talks for that instant user.

If the user is invited to more than one simultaneously ongoing Group Talk sessions, the system will ask which one he'd like to join, i.e. "For Footballers, press 1 ; for Dart buddies, press 2." If the user/instant user is invited to one or more instant group talk sessions the system will read the name of the user that set up the current instant group.

Phone Settings Actors: User.

Purpose : Record group names .

Description: When the user calls in after having created a new community, he is prompted to record the community name. This recording is used later, when the system needs to present the community name over the phone interface.

Phone Help

Actors: User.

Purpose: Get helpful information and tips. Description: It shall be possible to have support and guidance read in the phone by entering a certain phone key from most phone menus .

Administrative use cases

Administrative use cases are functions performed by the administrator actor in order to maintain and modify the Mobile Community system.

Admin Welcome

Actors: Administrator.

Purpose: To navigate the administrative services.

Description: This is the administrative web site start page. From here the administrator access the administrative functions and operations of the system. The administrator can here view a log of administrator activities. This log is "read only". In this log it is displayed who logged m as administrator and when.

Update Email addresses Rules

Actors: Administrator.

Purpose: To update the file containing forbidden email addresses . Description: This use case describes how to update the file that contains email addresses that are forbidden to send messages to. The administrator can specify specific addresses, domain or sub domain names.

Update Dialing Rules Actors: Administrator.

Purpose: To update the file containing forbidden outdial numbers .

Description: This use case describes how to update the file that contains telephone numbers that are forbidden to dial. Such numbers are for example international numbers, premium rate numbers, emergency numbers etc. The administrator can specify numbers as well as number series using wildcards: E.g. 112; 90 000; 071*; 00*.

Add User Actors: Administrator.

Purpose: Add new user.

Description: This use case describes how to add a new user to the system.

Search Users Actors: Administrator.

Purpose: To view all or defined part of registered users. Description: The search may be performed using some basic search criteria as for example name, email, member number, mobile phone number, registration date and reason for blocking. It is possible to sort the output alphabetically using system-predefined columns.

Delete User

Actors: Administrator. Purpose: Delete an existing user.

Description: This use case describes how an existing user may be deleted from the system. When a user that is deleted is a community owner the community shall be terminated and the other users in the community shall be notified via e-mail.

Modify User

Actors: Administrator.

Purpose: Change the properties and settings of a user account . Description: This use case describes how user details may be modified within the system.

Any user can be blocked from accessing the member services. Once a user with a certain phone number is blocked, he will need to apply to the administrator by email to be able to register a new membership using the same phone number. Reasons for blocking can be:

• Too many login attempts on web

• Too many login attempts on TUI

• Blocked by administrator ( and that case which administrator)

For blocked users it is also displayed when the user was blocked.

System Parameters

Actors: Administrator. Purpose: Manage system parameters.

Description: Administrators may set and change system parameters. Among those parameters are "Max simultaneous users in Group Talk", "How long time a recorded messages will be saved" .

Usage Pattern Statistics

Actors: Administrator. Purpose: Evaluating system usage.

Description: The administrator can see key data concerning the usage pattern of the system services, e.g. how many groups different persons initiate, group sizes, number of SMS sent compared to traffic generated etc. The system logs all logins at the TUI and WEB. For TUI accesses it is possible to see the length of each session as well as initiated SM and out dials during a session. For WEB the length of each session (until logout) is logged- if the user leave the site without doing a proper log-out it is possible to distinguish that session from other sessions.

Traffic Volume Statistics

Actors: Administrator. Purpose: Billing of operators. Description: Total voice traffic as well as total SMS traffic during a specified period is presented per operator. The administrator is further allowed to access and upload the traffic log file from the system. The traffic log file contains MSISDN/member number and start/stop/duration for each call.

Administrator Rights

Actors: Administrator.

Purpose: Specifying rights to other administrators. Description: The "master" administrator can specify what rights the other administrators of the system will have.

Administrator Update WEB

Actors: Administrator.

Purpose: To change and update WEB sites, strings in SMS, email etc. when the system is running. Description: The administrator with access rights (according to what has been set for him in use case regarding administrator rights) to update web pages is able to change all text content of the site's pages without interrupting the service. The administrator (according to what has been set for him in use case regarding administrator rights) can also update the text used in Short Messages sent from the system as well as standardized e-mail texts sent from the system. Admin Login

Actors: Administrator.

Purpose: To gain access to the administrative services and administrator authentication.

Description: This is the administrative web site entry point. From here the administrator access the administrative functions and operations of the system. The administrator is required to enter his/her username and password. After successful authentication the administrator is transferred to the Admin Welcome page. For example, http://admin.incirco.com

Admin Logout

Actors: Administrator.

Purpose: To exit the administrative services. Description: The actor activates logout function or an automatic logout by a time-out. After logout the actor is redirected to the start page of the administrative web, the Admin welcome.

Admin Help

Actors: Administrator. Purpose: Get helpful information and tips.

Description: It shall be possible to obtain help text on most administrative web pages. However, advanced help texts are not required. It shall also be possible to print a quick guide from the web. Add Administrator

Actors: Administrator. Purpose: Add new administrator.

Description: This use case describes how to add a new administrator to the system.

Search Administrators

Actors: Administrator.

Purpose: To view all or defined part of registered administrators . Description: The search may be performed using some basic search criteria as for example name, email, member number, mobile phone number, and registration date. It is possible to sort the output alphabetically using system- predefined columns. Delete Administrator

Actors: Administrator.

Purpose: Delete an existing administrator. Description: This use case describes how an existing administrator may be deleted from the system. Modify Administrator

Actors: Administrator.

Purpose: Change the properties and settings of an administrator account.

Description: This use case describes how administrator details, as password, may be modified within the system.

Add Community

Actors: Administrator.

Purpose: Add new community.

Description: This use case describes how an administrator may add a new community to the system for an arbitrary user.

Search Community Actors: Administrator.

Purpose: To view all or defined part of registered communities .

Description: The search may be performed using some basic search criteria as for example name, symbol, and registration date. It is possible to sort the output alphabetically using system-predefined columns.

Delete Community

Actors: Administrator. Purpose: Delete an existing community.

Description: This use case describes how an administrator may delete an existing community from the system.

Modify Community

Actors: Administrator. Purpose: Change the properties and settings of a community.

Description: This use case describes how an administrator may modify arbitrary community details within the system.

An administrator can block any community. Once a community is blocked, the community owner will need to apply to the administrator by email to be able to reopen the community.

Broadcast Message

Actors: Administrator. Purpose: Inform users of needful things, like system updates etc.

Description: The administrator can send email or voice message to all users or to a selected part thereof.

Alarm Settings Actors: Administrator.

Purpose: Configure alarms.

Fault Management Actors: Administrator.

Purpose: Detect errors and inform the system administrator .

Description: A function monitors the hardware and software and reports errors to a fault management application.

Further functions

The following will describe functions that cannot easily and understandably be analyzed or described as a use case.

Spoken name

The system supports the use of spoken name for all users. The spoken name is recorded from the TUI at the first login to the system using the TUI . Detect answering machine

The system is able to detect an answering machine when performing out dials.

Support for users with a fixed phone only

The system accepts users without SMS capable phone. For members that are users of the system using such a phone SM notification is not available as an option. When logging in to the system from such a phone A-number detection should not be used, i.e. the user have to state the member number and the access code . Automatic configuration of notifications

In some countries, it is foreseen that out dial notifications might be forbidden or restricted to a certain group of users. The system shall be able to configure on a per user basis what notification method that should be used when a Group Talk is initiated. The notification schema per user should be set to a default value and can be controlled by the application (i.e. can differ per country) . The configuration is determined by what user data are given when registering, and by the country setting.

Support for instant users a) The system supports participation of non-registered users in Group Talks . The system remembers numbers of instant users that has been invited to an instant group so that they can be given a separate dialogue when entering the system. This feature allows users to invite persons that have never heard about the MC system to join an instant group talk. Out dial notification is performed in the same way as for a regular user, the instant user will get another notification message though. b) When an instant user has participated in a Group Talk (and the group talk has been terminated) he should receive a short message with information about the service .

Access to external directories/use of LDAP directory

The system supports LDAP for access to external directory information. This can be used to synchronize data with other directories and to import data from another user directory via LDAP. It is also possible to export data to another user directory. An external system is allowed to query the MC system for certain information via LDAP. In the same way - the MC system is able to query an LDAP directory for user information. The queries are done "online" .

By allowing LDAP access directly to the MC system (the MC user register/directory - or even using LDAP for lookups internally in the system) other applications are allowed to integrate into the MC system and benefit from the user information that already exists there. Many new applications are built around a LDAP directory and using a directory within the MC system means that it is possible to load those applications schemas into the MC directory. Statistics from WEB access

The system delivers reports on WEB usage. It is possible to detect individual users so that the number of unique users can be determined, not only the total number of hits.

SMS-C Interface a) The system supports an interface to external SMS-Cs in a modular way so that adaptation can be made to interface new SMS-Cs without having to redesign the service. At least the following interfaces are supported

• SMPP ver 3.3 over TCP/IP

• SMPP ver 3.3 over X.25

• UCP over TCP/IP

• UCP over X.25 b) The system routes the call to the correct SMS-C by identify which operator that is assigned to the current user (the operator is stored in the user's record) . Hence, several protocols are supported in parallel in one installation. The information of operator is determined by the system by analyzing the phone number entered at registration. The system is able to analyze the six first digits in the telephone number. At least 16 operators are able to be determined.

This feature allows the system to use multiple SMS-Cs for notification

Support for international versions a) The system is built in such as way that it can be adapted to the local market without the need for system modifications. This is attached to the following issues: • Language used on WEB pages

• Voice prompts • Language/Text used in SM sent out for notification purposes

• Language/Text used in e-mails sent out for notification and information purposes • Language used in out dial notification.

• Set up of dialing rules (non-allowed out-dial numbers) .

• ISDN parameters

• b) Other partners (local) can used to translate the system into any language.

Dialling rules

The system allows out dial to different number series specified in a "Dialing rules" file. If the user with a forbidden out dial number has SM capabilities a SM should be sent to notify that user. The group talk owner shall be notified if all invited users can not be notified.

Email rules

The system allows for not sending email to certain addresses or domain/subdomain series which are specified in a "Email rules" file.

Secure access for system administrators a) The system supports a secure connection for remote login by the administrator. The system requires preferably a certificate from the administrator's terminal. b) In order to keep track of possible unauthorized access to the system administrator account, all logins should be logged with time and IP address of the person logging in as system administrator. Alarm handling and monitoring

The system supports alarm handling via SNMP to a SNMP manager (not part of the system) . Protection against misuse

All communication systems can be subject to spam and misuse by users or guests. a) The system supports a function to limit the amount of out dials that are initiated by a certain user (i.e. through set up of group talks) and block users that exceed such value. The system supports an alarm function that will be triggered if a user exceeds a certain number of initiated out dials during a 24 hour period. The parameters is administered through the system administration interface (web) . b) The system supports a function to limit the amount of SM that are initiated by a certain user (i.e. through leaving group messages and by inviting new users) and block users that exceed such value. The system supports an alarm function that will be triggered if a user exceeds a certain number of initiated SM during a 24 -hour period. The parameters are administered through the system administration interface (web) . Safety aspects a) The system preferably uses a PIN code for authentication on the WEB interface and on the TUI interface . b) The system keeps a log of all accounts temporary blocked due to failed logon, and shall send an alarm upon high volumes of temporary blocked accounts . The system shall also send an alarm if an account is blocked more than 20 times during a period of 1 week. c) When logging out from the system, the webpages should preferably not be allowed to be cached in the browser d) UserlD and password shall preferably not be allowed to be handled as part of an URL. e) All entry fields on the website must have "Boundary checks" to ensure that the indata is of desired type. This checking should be done in the browser. (Otherwise there is a risk for e.g. : one can append a 20 MB file in one entry field, making the system crash etc.) Boundary checks must be done on entries between the webserver and the application server in order to prevent unwanted database accesses. f) The password is preferably encrypted in the browser using MD5 or SHA-1.0 before it is sent from the browser to the system. Max Group Size per User Basis.

The system is prepared for future assignment of a maximum size of community on a user basis.

Dynamic text usage a) It is possible to change web texts without service interruption. The content of the WEB pages is stored so that the text in the pages can be updated separated from the Java Server Pages (jsp) . Access to the text is an attribute in the administrator's access rights, i.e. it is possible to restrict access to changing the texts to certain administrators. b) It is possible to change text used in SMs without service interruption. c) It is possible to change text used in e-mails without service interruption. Browser compatibility

The system supports at least America Online' s Netscape Navigator 4.05 and later versions and MS Explorer 4.01 and later versions.

Multiple message stores and user registers The scale the system, the system is designed to allow configurations with multiple messages stores distributed on several physical servers, and user registers (DB2) distributed on several physical servers.. Speech Recognition and Text to Speech a) The system is prepared for supporting speech recognition. Preferably, it shall be possible for the user to assign a spoken name for the persons that the user has put in the contact list. b) The system is prepared for Text to Speech translation. It is preferably be possible to e.g. read incoming emails in the TUI .

Security on ISDN lines Should the ISDN lines to the CT-servers happen to carry

Incoming TCP/IP traffic, the CT-servers shall reject this call.

Auto-maintenance of log-files, user register and message store a) The database should preferably be cleaned regularly to ensure that all obsolete data is removed. b) Saved data on system usage (e.g. traffic logs etc.) should preferably be automatically archived after e.g. three months storage [system parameter] (and thus removed from the system) . c) It is possible to automatically remove users that have been inactive for more than x months (x is a system parameter - default value 12 months) .

Supervision of CT resources The system generates SNMP traps if there is any degradation in the capacity of the telephony interface. The CT resources (SW processes and HW (Line cards, ATM cards, Conference cards and servers)) should be possible to poll for status information. The system monitors activity on the line cards to ensure that they are working properly. If no activity has been detected during a certain time (system parameter) the system generates an alarm. Capacity - typical numbers without restricting the scope of the invention: a. The system is capable of meeting a subscriber load of 2 000 000 subscribers. b. The system supports 1000 simultaneous users on the web. c. The system supports 2000 simultaneous users on the TUI . d. The system supports full load on 120 ISDN channels and one DCB960 conference board in one NT server with the following configuration:

IBM Netfinity 5000 with 1 PHI 677 MHz processor, 256 MB RAM.

Database possible to update The database isdesigned in a way so that it is possible to update the attributes connected to each user record (i.e. it is be possible to add information such as address and other user-unique data to each user record) .

Acoustic profile The system uses an acoustic profile. This means that different signals will be used to inform the user about different events. The following different sounds may be used:

• Group talk has started • New Group message

• Group message (old)

• Group Talk (recorded)

• Waiting signal (while group talk is initiated)

• User enters the group talk' • User leaves the group talk

Latency As a measurement for the quality of service the system is designed in such a way that the user never need to wait more than 1 second after he has initiate a comment until the system answers back. The system is equipped with a time-out prompt that is played in case the 1 second threshold is exceeded during moments of extreme load "The system is retrieving data, please wait" or equivalent.

Sound quality

There is no "distorted sounds" when playing any speech prompt.

Background: GSM uses inband signalling to send DTFM signals. This makes the speech channel sound corrupted during about one second after a key is pressed.

Audio codec use The system is capable of being configured to use different audio codecs (supported by the dialogic boards) . It shall be possible to use different codecs for recording of group talk and group message (which implies that the system is able to switch audio codec during a call.

Key ahead on TUI

All menus that allows the user to make a choice support key-ahead, i.e. it is possible to choose action without having to listen to the prompt to be completed.

Claims

1. A communication system comprising means for enabling exchange information between users of communication devices in at least one digital communication network, the devices comprising mobile communication stations, the system comprising:

- means for creating a group with members comprising a plurality of the users,

- means for storing an incoming information message from a user of a communication device,

- means for alerting at least a subset of the members that an information message is available.

2. A system according to claim 1, comprising:

- means for enabling alerted users to access a stored message.

3. A system according to any one of claims 1-2, where the means for creating a group comprises WWW-interface means.

4. A system according to any one of claims 1-3, where the means for creating a group comprises means for creating a group of users originating from different communication networks .

5. A method for enabling exchange information between users of communication devices in at least one digital communication network, the devices comprising mobile communication stations, the system comprising steps of:

- creating a group with members comprising a plurality of the users,

- storing an incoming information message from a user of a communication device, - alerting at least a subset of the members that an information message is available.

6. A method according to claim 5, comprising:

- enabling alerted users to access a stored message.

7. A method according to any one of claims 5-6, where creating a group comprises interaction via WWW-interface means .

8. A method according to any one of claims 5-7, where creating a group comprises creating a group of users originating from different communication networks.

9. A computer software product comprising instructions for a computer system to perform the steps according to any one of claims 5-8.

10. A method of enabling exchange information between users of communication devices in a digital communication network, the devices comprising mobile communication stations, the method comprising steps of:

- creating a group with members comprising a plurality of the users,

- distributing information messages originating from at least one member of the group to other members of the group,

- providing simultaneous connections between members of the group.

11. A computer software product comprising instructions for a computer system to perform the steps according to claim 10.

12. A communication system comprising means for enabling exchange information between users of communication devices in a digital communication network, the devices comprising mobile communication stations, comprising:

- means for creating a group with members comprising a plurality of the users, - means for distributing information messages originating from at least one member of the group to other members of the group,

- means for providing simultaneous connections between members of the group .