NO318166B1 - Communication system - Google Patents

Description

An arrangement in a communication system

Technical area

The invention can be used in information and communication systems and in particular to personalize terminals and services.

Technical background

The success of mobile communication is expressed in the explosion both in the number of mobile subscribers and the number of mobile phones. This success is expected to expand to include services other than traditional voice telephony calls, and the rapid development of mobile terminals and other electronic devices will allow future mobile users to operate a number of different services. Future mobile communication systems will provide global availability so that mobile services will be available everywhere. The advent of packet-switched mobile systems will contribute with the "always-on" property, i.e. that users will be connected to the network at all times. Together, these technologies will provide "always-on" access to future services everywhere. However, the users' freedom will still be limited by the limitations dictated by the limited capabilities of the mobile device that one carries with them. It will therefore be very valuable to extend the "always-on, everywhere" concept to multiple autonomous devices, i.e. "always on", everywhere and on heterogeneous devices.

One possible development path is that the mobile terminals in the future will be more and more integrated devices. That is that the users want a mobile device that includes all the functionality the user will need, for example voice-lef oni functionality, multimedia communication functionality, personal computer functionality, web browser, radio/TV receiver, camera for still images, personal stereo , calendar, e-mail, e-wallet, address book, speakers, screen displays, etc. There are many reasons why this development is not the best. Firstly, such a terminal will necessarily be unsuitable when it comes to size and handling. Secondly, not all conceivable functionalities are desirable at any given time from the user's perspective. In most situations, only a subset of all functionality will be needed, and it would be desirable to be able to add and remove available functionality dynamically, for example to borrow certain functionalities at certain times. Finally, such a terminal will be static, and it can only be replaced completely or not at all. It is likely that the different components representing the different functionalities will be out of date and in need of replacement at different times. These are all indicators of an alternative development path regarding future mobile terminals.

The alternative development path is a development towards more communication and other electronic devices that will surround the future user. Instead of a terminal that offers each desired function, there are several devices that offer distinct functionality and services. In this way, the terminals, although they will grow in number, will be smaller, easier to operate and much better suited to perform specific limited tasks. This development is already evident today, and the modern communication user is confronted with many devices, for example mobile phones, landline at home, landline at work, laptop computer, PDA, electronic camera, wireless headset, microphone, etc. This trend can be expected to continue in the near future and the user will have to deal with even more terminals, devices and other electronic devices.

With this development path for mobile terminals, the user will have a formidable task in managing all his different terminals and making them work together. The following list shows some examples of how different devices can work together: • Transmission of a voice session. For example, if the user has to leave the office while talking on the landline in the office. If the office phone and his mobile could work together, it would be possible to transfer the session from the landline to the mobile and

continue the conversation while leaving the office.

• Use of several devices together. For example, when participating in a multimedia session, it should be possible to direct the video stream to a nearby screen and the audio to a nearby set of speakers, rather than just using the limited display and audio capabilities of a mobile device. • Utilization of supplementary services offered by other facilities. For example, sending received e-mail or attachments to a printer close to or to a screen. • Loan and use of stationary devices at visited places. • Exchange of notes and sketches on an electronic whiteboard while communicating over the phone. • Updating the address book, calendar or other elements in the user profile on a laptop or PDA and at the same time also updating information contained in the mobile phone or any other device that the user has. That is to set up and modify preferences for all devices in one place. • Your mobile phone knows you are busy if you receive an incoming call while you are talking on another phone.

fon, for example your landline, as you are not able to participate in more than one phone call at the same time.

A complete list of examples would be long, and will continue to grow as terminals evolve and new services and functionalities are introduced.

To help the user manage all their different terminals and devices and make them work together to provide a unified service, a coordination and management service is needed. This need will grow and be more prominent in the future, as the number of different devices will grow.

Known solutions

Only one solution to the described problems is known today: the virtual terminal. With this concept, all devices are seen as different components of a "virtual terminal" that the user must deal with. This virtual terminal will be dynamic in that different components, which for example offer input and output services, can be added, deleted or replaced along the way, and will be able to offer the end user the optimal services at any given time.

The concept for The Virtual Terminal is illustrated in Figure 1: The switching and handling of the various devices is carried out on a standard IP-based network connected to other networks (such as PSTN/ISDN/GSM/Internet) via gateways. In this way, the service can handle and integrate different devices from different technological areas. The service is offered over the Internet via a website or over the mobile network (eg GSM) via WAP. Users with valid subscriptions can log in and operate the service. This architecture is illustrated in Figure 2. The implementation of a Virtual Terminal service consists of different components, all of which are located on the local IP network:

• The VT server where the actual service is located.

• An MCU server that mixes media streams and delivers to different devices. • A user profile server with a database where the user profiles are stored. • A web/WAP server that provides access to the service for its customers over the Internet. • A development environment where the service can be developed, tested and modified before it is put into use. • Signaling and media gateways that connect the Virtual Terminal Service to other networks such as

ISDN/PSDN/GSM.

This is illustrated in Figure 3.

A prototype of the Virtual Terminal Service has already been implemented as a proof of concept. This prototype service allows the user to coordinate their different devices and offers the following functionality: • Session transfer between two devices, for example landline-to-mobile, mobile-to-landline, mobile-to-IP telephony, IP telephony -to-fixed etc. • Inclusion of several different devices in the same session, for example different input and output devices from different technological areas. • Transfer of data sessions, for example web session, e-mail session, etc. between different devices, for example. PC to laptop, PDA to PC, etc. • A common user profile available for all devices including address book, surroundings, schedule, list of devices, etc. • Reception of incoming services in the most appropriate device, for example depending on time of day the day, the user's location, available devices, service requirements, the device's capabilities, etc. • Other devices know whether the user is busy in a session on another device, i.e. the service keeps an eye on active sessions, both communication sessions and data sessions.

The solution is available to users who subscribe to the service directly from the service provider and are therefore given a username and password to log into the provider's website as well as a virtual terminal ID that services can use to communicate with the user.

Problems with known solutions

Although the Virtual Terminal will offer a solution to the initial problem area, it is subject to some serious problems and drawbacks.

A main problem with the known solution is its availability. This service will only be available to users who have a valid subscription directly with the provider of the Virtual Terminal service. This will impose major restrictions on the number of users who can benefit from the service. This is a problem for a. All users who will not be able to subscribe to the service.

b. The provider of the Virtual Terminal Service who will not be able to reach as many subscribers as possible.

c. 3rd parties who could otherwise re-negotiate the service

to their own customers.

Another disadvantage of the Virtual Service is that it currently seems to lack the ability to customize the service and the customer interface. For example, all subscribers will experience the same interface to the service, and this will create problems in the following contexts: a. Subscribers from different countries will require different languages in the user interface, i.e. the website. b. Resellers would like to apply their look-and-feel to the customer interface and present it with their trademark, branding, colors, etc. c. Companies may wish to offer the Virtual Terminal service to their employees as a corporate service available and compatible with the company's intra-net sites.

It would also be desirable to customize the service beyond pure customer interfaces. Some 3rd parties may wish to offer the Virtual Terminal service in combination with other services that they have. Others may wish to offer only a subset of the Virtual Terminal functionality to their customer base.

As the service currently stands, the only way to subscribe and use the service is to subscribe directly to the service delivery gateway that handles the web/WAP server where the Virtual Terminal Service is located. The Service will be offered as it appears on this server in an "all or nothing" offering. If different customized versions of the Service are to be available to different groups of customers, the entire Service must be re-implemented on a different server and with all supporting components.

Concise summary of the invention

It is an aim of the present invention to provide a virtual terminal service system which overcomes the problem with the prior art listed above.

It is particularly intended to make the virtual Terminal service more accessible both to third parties and to end users.

Another purpose is to allow customer customization of the service itself and the customer interface.

These purposes are achieved in an arrangement in a communication system as is apparent from the subsequent patent claims.

Brief description of the drawings

The invention will now be described in detail with reference to the attached drawings where

Figure 1 shows the functionality offered in the ideal virtual terminal. Figure 2 shows how the Virtual Terminal service connects to different networks and is offered via a website or a WAP interface. Figure 3 shows the components of the virtual terminal service. Figure 4 illustrates the basic architecture of the invention. Figure 5 illustrates the concept of re-negotiating customized Virtual Terminal Services. Figure 6 is a diagram illustrating the Virtual Terminal as an XML web service. Figure 7 shows 3rd party administration of Virtual Terminal Users in a system according to the present invention. Figure 8 shows Virtual Terminal functionality exposed as an XML web service to offer customer-customized Virtual Terminal services. Figure 9 is a diagram illustrating the relationship between Virtual Terminal users and user profiles. Figure 10 is a diagram illustrating the structure of the user profiles in the Virtual Terminal.

Figure 11 illustrates a first service scenario.

Figure 12 illustrates a second service scenario.

Figure 13 shows how customized Virtual Terminal services are offered to different customer groups.

Detailed description of the invention

The proposed solution is to offer the Virtual Terminal service as an XML web service to 3rd parties. The 3rd parties may in turn integrate Virtual Terminal functionality into their own products offered to their customer base, or they may appear as dedicated providers of Virtual Terminal services offering the Virtual Terminal service only to a wider range of customers. The fact that 3rd parties can utilize Virtual Terminal functionality can also open up valuable improvements to the service and synergies when combined with other services.

In order to offer the virtual terminal service as an XML web service, it can be utilized in different ways: a. The entire Virtual Terminal service with all its functionality can be offered as an XML web service to 3rd parties who in turn can introduce them to new market segments b. The administration interface of the Virtual Terminal can only be offered as an XML web service. Procedures for adding new users, removing users, editing customer information about existing users can be exposed as XML web service so that the original implementation of the Virtual Terminal service can handle the actual service for 3rd party customers. c. Distinct Virtual Terminal functionality such as transferring a voice session, handling environments, etc. will be exposed as distinct SML web services. 3rd parties can use these as components when composing and introducing new services to end users.

Basic architecture

The basic architectures for all the use cases described above are quite similar. They are illustrated in figure 4. Exposure of Virtual Terminal methods as an XML web service for use by 3rd parties represents the new invention. These methods will be called by SOAP messages from a web service client belonging to the 3rd party, and can be used as components to develop other applications and services of the 3rd party.

In the original version of the service, end users can communicate with the Virtual Terminal web server over http and thus have access to the service. The invention includes an additional component that translates the service into an XML web service, and can send and respond to SOAP messages. By using this interface, third parties can access the service logic in the original Virtual Terminal service and offer their own customized Virtual Terminal service to their own customers through their own web server. This is illustrated in figure 5.

Figure 6 illustrates the invented system. There will be a Virtual Terminal Service in the system. This will contain various Virtual Terminal functionalities such as transferring a session between devices, initiating calls from the Virtual Terminal, adding devices to a session, registering devices in the Virtual Terminal, receiving calls to the Virtual Terminal, removing devices from an active session, removal of devices from the Virtual Terminal and modification of profile. Editing the profile can be editing or creating new entries in an address book, a device list, an environment or terminal preferences.

The Virtual Terminal Service offers its services to no or several third parties. The 3rd party will again have its own customer base containing one or more customers. Each Virtual Terminal customer will again have a Virtual Terminal with one or more Virtual Terminal components (for example, mobile phone, landline, PC, laptop, screen display, speakers, etc.). Each such Virtual Terminal component will again have different terminal capabilities.

The Virtual Terminal Service will help customers to manage and manage these Virtual Terminals.

Interface for administration of a Virtual Terminal as an XML web tenet.

An administration interface to the Virtual Terminal service can be provided as an XML web service. By doing this, 3rd parties can add and remove customers to the Virtual Terminal Service without the need to operate their own Virtual Terminal System. The users will be included in the original Virtual Terminal service database and therefore be part of the same Virtual Terminal system. They will also be offered the same service and the same user interface that the original service offers. However, they do not need to communicate with the original Virtual Terminal service operator, and the 3rd party can handle subscriptions, billing, etc. {see Figure 7). To achieve this, at least two methods must be exposed as XML web services:

• AddNewUser

• RemoveUser

These methods should be available through SOAP interfaces and be able to be invoked by SOAP messages. Note that authentication and authorization should be performed before granting permission to access these interfaces.

The method addNewUser

When this method is invoked, a new user will be added to the Virtual Terminal service system, i.e. added to the system database. The procedure should take the following parameters: integer userlD, String userName, String password, String firstName, String lastName, and String userAddress, String thirdPartylD. Each 3rd party that has access to the system will have a range of unique user IDs and user addresses that they can assign to their customers. After successful user creation, a confirmation message should be returned. Otherwise, an error message should be returned.

The SOAP message that invokes the addNewUser method should look like this

like this:

y-: ÆaVerNamé yTthe4^^ .v; .y^^rS::. Jsåj^E^^^^^^s^m

=^<pas«wrørd>Thffrpassword^oMhl3,userv</password^^^ '.■ gfMI -. v ^ '•' - ia^B

<u ser ^ W ^ s^ An adders£that cgrijje to ad.d res s, t h ey ser^s virfual f érr^l^l En^rAdclres^aW

The response SOAP message should indicate whether a new user was created

successfully added to the system or not:

<?XML>v%sjor^

<soap:ep^lpRe. •:_- JÉ | > ' - •

When this SOAP message is received from an authorized third party

party, it will be translated into a command that the Virtual Terminal Service System understands and a new record will be added

to the database containing the users of the Virtual Terminal.

The method removeUser

This method can be called to remove a current user from the Virtual Terminal Services system. If called with a valid userlD and a valid corresponding thirdPartylD (it should only be possible for a third party to remove users that have been added by them, i.e. belong to them). This method only takes two parameters, integer UserlD and String thirdPartylD. A message should be returned to indicate the success or failure of removing the desired user. The SOAP requests and response messages that invoke the removeUser method might look like this:

Invoking this method will result in the corresponding user being removed from the Virtual Terminal system and thus terminating this user's subscription to the service.

Virtual Terminal functionality such as XML web tie nesters

In addition to opening up the Virtual Terminal Services system to allow 3rd parties to add and remove their own customers to the system, the Virtual Terminal functionalities as such can be offered as XML web services. Other 3rd parties can use these interfaces and build their own customized Virtual Terminal services. A third party can use some or all of the offered functionality and supplement it with functionality that they have implemented in their own domain. It should again be noted that authentication and authorization should be performed before granting permissions to access these interfaces.

Figure 8 illustrates how these methods can be used by a 3rd party operator who wants to offer its own customized Virtual Terminal service to its customers. Users must have a subscription with the third party and will access the service via the third party's own web server.

The following methods should be exposed as XML web services: 1. About call control • transferActiveSession

• initiateCallFromVirtualTerminal

• addDeviceToActiveSession

• removeDevi ce FromAc tivesession

• endSession

2. About handling Virtual Terminal

• getDeviceList

• saveDeviceList

• registerDevicelnVirtualTerminal

• reraoveDeviceFromVirtua1Terminal

• getAddressBook

• saveAddressBook

• addContactToAddressBook

• removeContactFromAddressBook

• getEnvironmentList

• saveEnvironmentList

• addEnvironment

• removeEnvironment

• getSchedule

• saveSchedule

• getTerminalPreferences

• saveTerminalPreferences

As indicated above, the methods can be divided into two types of methods. The first five in the list above are the methods related to call control and session management. The rest of the methods relate to handling the Virtual Terminal user profile.

Virtual Terminal call control methods such as XML web in one ter

The methods related to call control allow the user to dynamically change the active components of the Virtual Terminal during sessions. They can be used for both traditional voice sessions, multimedia communication sessions and for computer sessions such as web browsing.

The method transferActiveSession

This method takes four parameters; an integer userlD to identify the user, an integer sessionID that identifies the session to be transferred, a string fromDeviceAddress (can be E-164 number, IP address, or other type of address) that identifies the device from which the session is to be removed and a toDeviceAddress that declares which device the session is to be transferred to. The SOAP request and response messages that call this method will look like this:

Invocation of this method will transfer the session with the corresponding sessionID from one terminal or device to another without losing the session or terminating the call, if userlD corresponds to the user who owns the session.

The method initiateCallFromvirtualTenninal

This method takes three parameters: userlD to identify the user, a fromDeviceAddress that identifies the device from which the call is to be made and a toDeviceAddress that indicates the address of the device being called (belonging to the B party). Calling this method will also produce a response that returns the sessionID of the newly established session. SOAP request and response messages will look like this:

When this method is invoked, a new session will be established between the Virtual Terminal of the user and the addressed B-Party. A sessionID will be returned which will identify the specific session within the Virtual Terminal.

The addDeviceToActiveSession method

This method takes three parameters; a userlD that identifies the user, a sessionID that identifies which session a device is to be added to and the address of the device that is to be added to the session, addDeviceAddress. SOAP request and response messages will look like this: This method will add a device to the active Virtual Terminal session. If the device was added successfully, a confirmation message will be returned, otherwise an error message indicating what went wrong will be returned.

The removeDeviceFromActiveSession method

This method takes three parameters; a userlD that identifies the user, a sessionID that identifies the session from which a device is to be removed and a removeDeviceAddress that identifies the device that is to be removed from the session. The SOAP messages will be:

Calling this method will remove the indicated device from the Virtual Terminal session if userlD, sessionID and fromDeviceAddress are correct. A response message will state whether the device was successfully removed or not. If the device being removed is the only device in the Virtual Terminal taking part in the session, the session will be terminated.

The method endSession

This method takes two parameters; a userlD to identify the user and a sessionID to identify the session to be terminated. If userlD corresponds to the user who owns the session corresponding to sessionID, this session will be terminated by calling this method. The SOAP messages will be:

Handling of Virtual Terminal user profile as XML web in one place

These methods will provide Virtual Terminal user profile management as an XML web service. Before considering the specific methods that will be uncovered, it is useful to consider the structure of the user profiles. A number of Virtual Terminal users will be registered in the Virtual Terminal System. The users will be identified by unique userIDs and a Virtual Terminal address that others can use to address the Virtual Terminal belonging to this user, and there will be subscriber and billing information, etc. Each user will also have a Virtual Terminal user profile. This is illustrated in Figure 9.

The Virtual Terminal user profiles are divided into different parts; address book, environment, facility list, timetable, etc. The functions for handling the Virtual Terminal user profile will be offered as XML web services that allow the addition, deletion and editing of records in these user profiles. Figure 10 shows the structure of the Virtual Terminal user profiles. Each profile can contain an address book, a facilities list, a number of environments and a timetable. The address book can contain contacts, which in turn can have one or more devices. The device list is a list of all the user's registered devices and this contains zero or more devices with addresses and terminal capabilities. In the profile, one or more environments can be defined (a standard environment will always be defined), and each environment contains a list of devices available within this environment, for example a fixed office telephone within a work environment. Of all the different environments, one will always be the active environment. This is contained in a time table within the timetable which dictates which environment should be active at different times.

As listed on page 15, there are several methods for handling the Virtual Terminal user profile that will be exposed as XML web services. However, the procedures are quite similar, and only the first four of the list will be described in more detail, regarding registered devices and the list of devices.

The method getDeviceList

This method will find the list of registered devices for a user. The request message will only take one parameter, userlD, and the response message will contain the device list. Each device will be identified by its device address which can be an E-164 number, an IP address or any other device address. The SOAP messages exchanged will look like this:

The method saveDeviceList

This method is called when the configuration file should be saved after modification. A device list containing a list of devices in addition to userlD is sent as parameters to the request message. The response message should indicate success or failure when saving the device list. The SOAP messages will look like this:

The method registerDevicelnVirtualTermlnal

This method takes two parameters: userlD and a device. UserlD will identify the user who wants to register a device in their Virtual Terminal and thus identify which device list the device should be added to. The device will contain information about the device such as device name, address, type, capabilities etc. The response message will indicate success or failure. The SOAP messages used to invoke this XML web service are shown below:

The method removeDevicePromVirtua1Terminal

This method takes two parameters; a userlD to identify the user and a deviceAddress that uniquely identifies the device to be removed from the user's device list. The SOAP request and response messages are given below: The other methods that provide handling of the Virtual Terminal user profile will be very similar to the methods described above and will therefore not be given in detail. However, it should be noted that the invention includes the ability to handle an address book, environment and a schedule specific to the Virtual Terminal as XML web services.

Usage scenarios

Administration of the Virtual Terminal using the only administration interface

The Virtual Terminal XML web service will provide an interface that allows 3rd parties to include their own users in the Virtual Terminal system. One scenario could be a 3rd party service provider who has an agreement with a provider of a Virtual Terminal service that allows him to add a certain number of users to the system. 1. The 3rd party service provider will receive a pool of user IDs and corresponding Virtual Terminal addresses that can be issued to their customers. 2. A user will subscribe to the Virtual Terminal server from the 3rd party service provider. 3. The 3rd party service provider will add the user to the Virtual Terminal System through XML webt j the only one for handling the Virtual Terminaltj only offered by the provider of the Virtual Terminal service. A username, password and a Virtual Terminal address will be assigned to the user. 4. the user will receive his username, password and Virtual Terminal address from the 3rd party service provider. 5. From this point the user can use his userlD and password to log on to the original Virtual Terminal Service system over the Internet with a standard web browser. He will be able to operate his Virtual Terminal services such as session management and Virtual Terminal user profile management.

This is illustrated in Figure 11.

Customer-tailored Virtual Terminal service

Another scenario for a company is to offer its own Virtual Terminal service to its employees. This can be done by utilizing the Virtual Terminal Services exposed as XML web services without having to implement a new Virtual Terminal System. Employees can, for example, use this service to transfer a telephone session from their fixed office telephone to their mobile phone when they leave the office. The scenario will involve the following steps: 1. The user has an ongoing Virtual Terminal voice session on his fixed office telephone and is logged on to the Virtual Terminal service on his PC. 2. Via his reader on his PC, he sends a request for the transfer of the session to the 3rd party web server, including information about userlD, sessionID, the number of the fixed office telephone and the number of the mobile phone. 3. the web server runs an XML web service client upon receiving the request from the user. This client sends a SOAP message to the Virtual Terminal System that invokes the transferActiveSession method. 4. The Virtual Terminal System performs the actual call control that transfers the session, i.e. adds the mobile phone to the session and tears down the connection with the landline. 5. The user can continue the session on his mobile phone when he leaves the office.

This is illustrated in figure 12.

With this type of scenario, the user will experience a customized version of the Virtual Terminal Service. Other customized versions can also be offered to other customers at the same time using the same original terminal service (see figure 13). In Figure 13, each of the Virtual Terminal services (1-4) has a different design, for example different user interface, different invoicing system, different additional services, different Virtual Terminal j single component etc. This scenario will be clarified by the invention of the Virtual Terminal as a XML web service.

Claims (9)

1. System for delivering a virtual terminal service to an end user, comprising a first web server that hosts the virtual terminal service, characterized by a first SOAP interface on said first web server, a third party web server arranged to accessing said first web server through said SOAP interface and offering a customized virtual terminal service for the end user through a customer interface. 2. System according to claim 1, characterized in that said first web server is equipped with a second SOAP interface for administration of the virtual terminal service. 3. System according to claim 2, characterized in that said first web server contains a database for end user identity and profile information, and a third party can add end users and remove end users from said database through said second SOAP interface. 4. System according to claim 1, characterized in that said first web server offers the following services to said third party web server: - initiate calls from virtual terminal and establish session, - transfer active session, - add device to active session, - remove device from active session, - end session, - register device in virtual terminal, - remove device from virtual terminal, - retrieve device list, - save device list, - retrieve address book, - save address book, - add contact to address book, - remove contact from address book, - retrieve environment list, - save environment list, - add environment, - remove environment, - retrieve schedule, - save schedule, - retrieve terminal preferences, - save terminal preferences. 5. Web server designed to deliver a virtual terminal only to an end user, characterized in that said web server is arranged to retrieve its functionality from a virtual terminal service located on a first web server through a first SOAP interface on said first web server, and deliver a customized virtual terminal service to said end user through a customer interface. 6. First web server designed to deliver a virtual terminal tj only, characterized by a first SOAP interface on said first web server, the first web server being arranged to deliver a virtual terminal service functionality to a third party web server through said SOAP interface, so that said third party web server can deliver a customized virtual terminal only to the end user. 7. First web server according to claim 6, characterized in that said first web server is equipped with a second SOAP interface for administration of the virtual terminal service. 8. System according to claim 7, characterized in that said first web server contains a database for end user identity and profile information, and a third party can add end users and remove end users from said database through said second SOAP interface. 9. System according to claim 6, characterized in that said first web server offers the following services to said third party web server: - initiate calls from virtual terminal and establish session, - transfer active session, - add device to active session, - remove device from active session, - end session, - register device in virtual terminal, - remove device from virtual terminal, - retrieve device list, - save device list, - retrieve address book, - save address book, - add contact to address book, - remove contact from address book, - retrieve environment list, - save environment list, - add environment, - remove environment, - retrieve schedule, - save schedule, - retrieve terminal preferences, - save terminal preferences.