WO2004047404A1 - Arrangement for personalization of services using several web servers and a virtual terminal service - Google Patents

Abstract

An arrangement is disclosed, which allows the customization of a virtual terminal service system and its custom interface through SOAP interfaces on the web server hosting said virtual terminal service.

Description

INTERNATIONAL SEARCH REPORT

(PCT Article 18 and Rules 43 and 44)

Applicant's or agent's file reference FOR FURTHER see Form PCT/ISA/220

156544/0S/BF ACTION as well as, where applicable, item 5 below.

International application No. International filing date (dayjmonth)year) (Earliest) Priority Date (dayjmonthjyear)

PCT/NO 2003/000386 14 November 2003 15 November 2002

Applicant

Telenor ASA et al

This international search report has been prepared by this International Searching Authority and is transmitted to the applicant according to Article 18. A copy is being transmitted to the International Bureau.

This international search report consists of a total of _ sheets.

X~| It is also accompanied by a copy of each prior art document cited in this report.

1. Basis of the report a. With regard to the language, the international search was carried out on the basis of the international application in the language in which it was filed, unless otherwise indicated under this item.

□ The international search was carried out on the basis of a translation of the international application furnished to this Authority (Rule 23.1(b)). b. I I With regard to any πucleotide and/or amino acid sequence disclosed in the international application, see Box ¹ — ' No. I.

2. j j Certain claims were found unsearchable (see Box No. II)

3. j I Unity of invention is lacking (see Box No. Ill)

4. With regard to the title,

I j the text is approved as submitted by the applicant.

I χ | the text has been established by this Authority to read as follows:

ARRANGEMENT FOR PERSONALIZATION OP SERVICES USING SEVERAL WEB SERVERS AND A VIRTUAL TERMINAL SERVICE

5. With regard to the abstract,

I χ [ the text is approved as submitted by the applicant.

I I the text has been established, according to Rule 38.2(b), by this Authority as it appears in Box No. IV. The ^■ — ' applicant may, within one month from the date of mailing of this international search report, submit comments to this Authority.

6. With regard to the drawings, a. the figure of the drawings to be published with the abstract is Figure No. 5 I as suggested by the applicant.

I - I as selected by this Authority, because the applicant failed to suggest a figure. I as selected by this Authority, because this figure better characterizes the invention. b. j j none of the figures is to be published with the abstract. 1

AN ARRANGEMENT IN A COMMUNICATION SYSTEM

Technical field

This invention is applicable in information and communication systems and in particular for the personalization of terminals and services .

Technical background

The success of mobile communications is expressed in the explosion both in the number of mobile subscriptions and the number of mobile phones. This success is expected to extend to include services other than traditional voice telephony calls and the rapid evolution 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 emergence of packet-switched mobile systems will add the feature of "always-on", i.e. the users will be connected to the network at any time. Together these technologies will provide always-on access to future services everywhere. However, the user's freedom will still be restricted by the limitations dictated by the limited capabilities of the mobile device carried along. It would therefore be very valuable to extend the always-on, everywhere concept onto multiple autonomous devices, i.e. always-on, everywhere and on heterogeneous devices.

One possible evolution path is that the mobile terminals in the future will be more and more integrated devices. I.e. the users will have one mobile device that embrace all the functionality the user will need, e.g. voice telephone functionality, multimedia communications functionality, personal computer functionality, Web browser, radio/TV receiver, camera for still pictures, personal stereo, calendar, e-mail, e-pocketbook, address book, speakers, screen displays etc. There are many reasons why this evolution is not the best one. Firstly, such a terminal will necessarily have to be inconvenient when it comes to size and manageability. Secondly, all thinkable functionalities are not desired at any given time seen 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, e.g. to borrow certain functionalities at certain times. Finally, such a terminal would be static, and it can only be replaced completely or not at all. Most likely, the different components representing the different functionalities will be outdated and in need of replacement at different times. These are all indicators of an alternative evolution path regarding future mobile terminals.

The alternative evolution path is an evolution towards several communication and computing terminals and other electronic devices that will surround the future user. Instead of one terminal offering every desired function, multiple devices are offering distinct functionality and services. In this way the terminals, even though they will grow many in numbers, will be smaller, easier to operate and much better suited to perform specific limited tasks. Already today, this evolution is manifesting itself, and the modern communication user is confronted with numerous devices, e.g. mobile phone, fixed phone at home, fixed phone at work, laptop, PDA, electronic camera, wireless headset, microphone etc. This trend can be expected to continue in the near future and the user will have to relate to even more terminals, devices and other electronic devices.

With this evolution path for mobile terminals, the user will have a formidable task in managing all his different terminals and to get them to work together. The following list some examples of how different devices can work to- gether: • Transfer a voice session. For example if the user has to leave the office while talking in the fixed phone at the office. If the office phone and his mobile phone could cooperate, it would be possible to trans- fer the session from the fixed phone to the mobile phone and continue the conversation while leaving the office.

• Using multiple devices together. For example when participating in a multimedia session, it should be pos- sible to direct the video stream to a nearby screen display and the audio to a nearby set of speakers instead of only using the limited display and sound capabilities on a mobile device.

• Utilizing supplementary services offered by other de- vices. For example sending received e-mails or attachments to a nearby printer or on a screen.

• Borrowing and using stationary devices on visiting sites.

• Exchanging notes and sketches on an electronic white- board while communicating over the phone.

• Updating address book, calendar or other elements in the user profile on a laptop or PDA and at the same time also update information contained in the mobile phone and any other device at the user's disposal. I.e. setting up and modifying preferences for all devices at one place.

• Your mobile phone knows that you are busy if you receive an incoming call while talking in another phone, e.g. your fixed phone, since you are not able to par- ticipate in more than one phone call at the time. A complete list of examples would be long, and will continue to grow as terminals are evolving and new services and functionalities are introduced.

In order to help the user cope with all his different terminals and devices and to make them cooperate to offer a unified service, there is a demand for a coordination and management service. This need will grow and be more evident 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 one "virtual terminal" which the user will have to relate to. This virtual termi- nal will be dynamic in that the different components, offering e.g. input and output services, can be added, deleted and replaced on-the-fly, and will be able to offer the end-user the optimal services at any given time.

The concept of the Virtual Terminal is illustrated in Fig. 1:

The switching and management of the different devices is performed 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 de- vices from different technological domains. The service is offered over the Internet via a WEB page or over the mobile network (e.g. GSM) via WAP. Users with valid subscriptions can log on to these and operate the service. This architecture is illustrated in Fig. 2.

A Virtual Terminal service implementation consists of different components, all residing on the local IP network: • The VT server where the actual service is deployed.

• 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 prior to deployment.

• Signalling and media gateways that connect the Virtual Terminal service to other networks like ISDN/PSTN/GSM.

This is illustrated in Fig. 3.

A prototype of the Virtual Terminal service is already implemented as a proof-of-concept. This prototype service allows the user to coordinate his different devices and offers the following functionality:

• Session transfer between two devices, e.g. fixed-to- mobile, mobile-to-fixed, mobile-to-lP telephony, IP telephony-to-fixed etc.

• Including several different devices in the same session, e.g. different input and output devices from different technological domains.

• Transferring data sessions, e.g. web session, e-mail session etc, between different devices, e.g. PC to laptop, PDA to PC, etc. • One common user profile available on all devices including, address book, environments, schedule, list of devices etc.

• Receiving incoming services on most appropriate device, e.g. depending on time of day, location of the user, available devices, service requirements, device capabilities etc.

• Other devices know if the user is busy in a session on another device, i.e. the service keeps track of active sessions, both communication sessions and data sessions .

The solution is available to users that subscribe to the service directly from the service provider and hence are given a username and password to log in to the provider's WEB page as well as a Virtual Terminal ID that services can use to communicate with the user.

Such a solution is disclosed in International patent application WO 02/082841 to OY Datatie AB.

Problems with known solutions

Even though the Virtual Terminal will offer a solution to the initial problem area, it suffers from some serious problems and shortcomings .

A major problem with the known solution is its availability. This service will only be available to users that have a valid subscription directly with the Virtual Terminal service provider. This will imply great restrictions to the number of users that can benefit from the service. This is a problem for

a. All the users that will not get the opportunity to subscribe to the service b. The Vxrtual Terminal service provider that will not be able to reach as many subscribers as possible.

c.3^rd parties that could otherwise resell the service to its own customers .

Another shortcoming of the Virtual Service as it appears today is the lack of possibilities for customizing the service and the customer interface. For example, all subscribers will experience the same interface to the service, and this will cause problems in the following contexts:

a. Subscribers from different countries will require different language of the user interface, i.e. web page.

b. Resellers would like to use their look-and-feel on the customer interface and present it with their trademark, brand image, colours, etc.

c. Companies might want to offer the Virtual Terminal service to their employees as an enterprise service available and compatible within the company's intranet pages .

Also, customisation of the service will be desirable beyond mere customer interface. Some 3^rd parties might want to offer the Virtual Terminal service in combination with other services of their own. Others might want to offer only a subset of the Virtual Terminal functionality to its cus- tomer base.

As the service appears today, the only way to subscribe and use the service is to subscribe directly to the service provider that manages the WEB/WAP server where the Virtual Terminal service is deployed. The service will be offered as it appears on that server in an "all or nothing" offer. If different customised versions of the service are to be available to different groups of customers, the whole service must be implemented anew on a different server and with all supporting components.

Brief summary of the invention

It is an object of the present invention to provide a virtual terminal service system that amend the problems with the prior art enumerated above.

In particular it is an object to make the Virtual Terminal service more available both to 3^rd parties and the end cus- tomer.

Another object is to allow customisation of the service itself and the customer interface.

These objects are achieved in an arrangement in a communication system as it appears from the appended patent claims .

The inventive arrangement includes a first web server hosting a virtual terminal service, a 3^rd party web server with an interface offering a customized virtual terminal service for end users, said customized virtual terminal service fetching its functionality from the virtual terminal service located on said first web server through a first SOAP interface on said first web server.

Brief description of the drawings

The invention will now be described in details in reference to the appended drawings, in which

Figure 1 shows the functionality offered in the ideal virtual terminal 9

Figure 2 shows how the Virtual Terminal service connects different networks and is offered via a WEB page or a WAP interf ce.

Figure 3 shows the virtual terminal service components

Figure 4 illustrates the basic architecture of the invention

Figure 5 illustrates the concept of reselling customised 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 XML Web Services to offer customised Virtual Terminal ser- vice

Figure 9 is a diagram illustrating the relationship between Virtual Terminal users and user profiles

Figure 10 is a diagram illustrating the Virtual Terminal user profile structure

Figure 11 illustrates a first service scenario

Figure 12 illustrates a second service scenario

Figure 13 illustrates how customised Virtual Terminal services are offered to different customer groups 10

Detailed description of the invention

The proposed solution is to offer the Virtual Terminal service as an XML Web Service to 3^rd parties. The 3^rd parties can in turn integrate Virtual Terminal functionality in their own products offered to their customer base or they can emerge as dedicated Virtual Terminal service providers offering the Virtual Terminal service to a wider range of customers . The fact that 3^rd parties can utilise Virtual Terminal functionality will also open for valuable improve- ments of the service and synergies when combining with other services .

To offer the Virtual Terminal service as an XML Web Service can be exploited in different ways:

a. The whole Virtual Terminal service with all its functionality can be offered as an XML Web Service to 3^rd parties that again can introduce it to new market segments .

b. The administration interface of the Virtual Terminal service can be offered as an XML Web Service. Methods for adding new users, removing users, edit customer info on existing users will be exposed as XML Web Services so that the original Virtual Terminal service implementation can take care of the actual service for 3^rd parties' customers.

c. Distinct Virtual Terminal functionality such as transferring a voice session, environment management etc. will be exposed as distinct XML Web Services. 3^rd parties can use these as components in assembling and introducing new services to the end user.

The basic architecture 11

_The basic architectures for all the usage examples described above are quite similar. It is illustrated in Fig. ₄. _Exposing Virtual Terminal methods as an XML Web Service for 3^rd parties to utilize represents the novel invention. 5 These methods will be invoked by SOAP messages from a Web Services client belonging to the 3^rd party, and can be used as components in order to develop other applications and services by the 3^rd party.

In the original version of the service, the end users can o communicate with the Virtual Terminal Web server over http and hence 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. Using this interface, 3^rd parties can access the s service logic in the original Virtual Terminal service and offer their own customised Virtual Terminal service to their own customers through their own Web Server. This is illustrated in Fig. 5.

Fig. 6 illustrates the invented system. There will be one 0 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 5 Virtual Terminal, removing devices from an active session, removing devices from the Virtual Terminal and modify profile. To edit the profile can be to edit or create new entries in an address book, a device list, an environment or terminal preferences .

o The Virtual Terminal service offers its service to zero or more 3^rd parties. A 3^rd party will again have its own customer base containing one or more customers. Each Virtual Terminal customer will again have one Virtual Terminal with one or more Virtual Terminal components (e.g. mobile phone, 5 fixed phone, PC, laptop, screen display, speakers etc.). 12

Every such Virtual Terminal component will again have different terminal capabilities .

The Virtual Terminal service will help the customers to handle and manage these Virtual Terminals .

Virtual Terminal administration interface as an XML Web Service

An administration interface to the Virtual Terminal service can be offered as an XML Web Service. In doing this, 3^rd parties can add and remove customers to the Virtual Termi- nal service without a need to operate their own Virtual

Terminal system. The users will be included in the original Virtual Terminal service database and hence be a part of the same Virtual Terminal system. They will also be offered the same service and the same user interface as the origi- nal service is offering. However, they do not need to communicate with the original Virtual Terminal service operator, and the 3rd party can handle subscription, billing etc. (see Fig. 7) . In order to achieve this, at least two methods must be exposed as XML Web Services:

• addNewUser

• removeUser

These methods should be accessible through SOAP interfaces and possible to invoke by SOAP messages. It should be noted that authentication and authorisation should be per- formed before permission to access this interfaces is grante .

- The addNewUser method

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

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

The response SOAP message should indicate whether a new user was successfully added to the system or not:

when this SOAP message is received from an authorised third party, it will be translated into a command that the Virtual Terminal service system understands and a new entry 14 will be added to the database containing the Virtual Terminal users.

- The removeUser method

This method can be invoked to remove a current user from the Virtual Terminal service system. If it is 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. that belong to them. This method only takes two parameters, integer userlD and String thirdPartylD. A notification should be sent back to indicate success or failure in removing the desired user. The SOAP request and response messages that invoke the removeUser method should look like this:

<?XML version^LO" eneoding="utf-8"?> soap:envefope xmlns:xs http /www.w3.θfg/2001/XMLSche a**instancβ xmlns:xsd=http://vww.w3.org/2001 XMLSchβma x lns:soap=-"httρ://schemas.xm(soap .org/soap7envelopβ?^M> <soaρ;βpdy>

<removeUserx lr)S="http://operatora,unlque.namespaceJdentiRer"> <userlD> ID identifing the user </userfD> thirdPartylD> Identification to identify third party that "owns" the user </thirdPartylD> i </removeUser>

<tsoap;Body> </soap:βnvelope>

Invoking this method will result in the corresponding user being removed from the Virtual Terminal service system and hence terminate that user's subscription to the service. 15

Virtual Terminal functionality as XML Web Services

In addition to opening up the Virtual Terminal service system to allow 3^rd parties add and remove their own customers to the system, the Vxrtual Terminal functionalities them- 5 selves can be offered as XML Web Services. Other 3^rd parties can use these interfaces and build their own customised Virtual Terminal service. A third party can use some or all of the offered functionality and supplement with functionality they have implemented on their own domain. It ιo should again be noted that authentication and authorisation should be performed before permission to access this interfaces is granted.

Fig. 8 illustrates how these methods can be used by a 3rd party operator that wants to offer its own customised ir- i5 tual Terminal service to its customers . The users will have a subscription with the 3^rd party and will access the service via the 3^rd party's own Web server.

The following methods should be exposed as XML web services :

20 l. About Call control

• transferActiveSession

• initiateCallFromVirtualTerminal

• addDeviceToActiveSession

• removeDeviceFromActiveSession

5 • endSession

2. About managing Virtual Terminal

• getDeviceList 16 saveDeviceList

registerDevicelnVirtualTerminal

removeDeviceFromVirtualTer inal

getAddressBook

saveAddressBook

addContactToAddressBook

removeContactFromAddressBook

getEnvi onmentList

saveEnvironmentList

addEnvironment

removeEnvironment

getSchedule

saveSchedule

getTerminalPreferences

saveTerminalPreferences

As stated above the methods can be divided into two types of methods. The first five in the list above are methods related to call control and session management. The rest of the methods are about managing the Virtual Terminal user profile. 17 virtual Terminal call control methods as XML Web Services

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

- The transferActiveSession method

This method takes four parameters; an integer userlD to identify the user, an integer sessionID that identifies the session that is to be transferred, a String fromDeviceAd- dress (could be E-164 number, IP address or other type of address) that identifies the device to move the session from and a toDeviceAddress that declare which device to transfer the session to. The SOAP request and response mes- sages that invoke this method will look like this:

<?XML version="1.0" ©ncoding=^,,utf-8"?> <soap:envθlope xmlns;χsl- ttp://www.w3.orgt200l/XMLSche a-instanøe χ !ns:xsdβ tp;//w w. θ.org/2001/χyLSchema xmIrts.soaρ="rιttp;//schemas.xmlsoaρ.org/soap/enveiopθ/"> _t , <soap:Body> ransferActfveSess n xmlns»''http,//operators.un(que_<narnespace.identlfler^B > <useriD> ID identifying the user that will transfer the session </userJD> <$øssiortlD> ID identifying the session to be transferred </sessi r'lD> frortιDeviceAddrβss> Address of device to transfer the session from <j romDevioøAddress> <toDevtceAddress> Address of device to transfer the session to </toOevJceAddress> </tra nsferActi veSessIon> </soap;Body> </soap;enveioρe> <

18

Invoking this method will transfer the session with the corresponding sessionID from one terminal or device to another one without loosing the session or terminating the call, if the userlD corresponds to the user that owns the session.

- The initiateCallFromVirtualTerminal method

This method takes three parameters: The userlD to identify the user, a fromDeviceAddress that identifies the device to make the call from and a toDeviceAddress that states the address of the device to call (belonging to the B-party) . Invoking this method will also produce a response that returns the sessionID for the newly established session. The SOAP request and response messages will look like this-.

<?XUl venMor LO" encodinga"utf-8"?> <soap;enveiope x ins"Λsi-=http^/ ww. 3.org/2001β<MLSche a-insten<ϊe x lns:xs l^βh^AΛW .w3.org/2001 XM!-,Scherna x lns:soap^a-''http'//sche asj( isoap.org/soap/enveIopθf> <soap;Body

<initiateCaiiFfømVirtualTerminal ^ <userlD> H> identifying the user that will initiate a call </userlD> <fromDevi eAddress> Address of device to call from </frotnDevfceAddress> <toDβviceAddress> Address f the device of the recipient

</inttiateCalFroraVirtualTer inal> </sαap:Bαdy> </soap:enveϊope>

<?X L version="1.0" encodmg-=^!,utf-8^M?> <soap:envelope x ins s http^Λw w. S.org^OOI/XMLSchema-instance xmlns:xsd^βhttp:/Λvw . 3.org/2001 /XMLSchema xmlns:soap="http://schemas.xmlsoaρ.org/soap/βnvelαpe > soapf;βody>

<initiateCallFrømV«tualTerminalResponsβ> <iniWateCaliFrømVlrtualTermirta^{Re^^ sessiort|f a new session identifier that identifies the es abli hed session </sesstortlD> <ΛraitiateCallFromVirtua|TerminalResule < initiateCallFromVirtMalTerminaIResponse> </soaρ:Body /soap;envelope>

When this method is invoked, a new session will be established between the Virtual Terminal of the user and the B- 19 party addressed. A session ID will be returned that will identify that 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 to add a device to and the address of the device to add to the session, addDevice ddress . The SOAP request and response messages will look like this :

This method will add a device to an active Virtual Terminal session. If the device was successfully added, a notification message is returned, otherwise an error message indicating what went wrong will be sent back.

- The removeDeviceFromActiveSession method 20

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

<?XMLVersιon ^r

..

<soap:enveloρe, xrnlns-χsi=http://wnftwtø3.org/20G $

^" χrnlns^xsd^ttp;/tv *.w3.org2θ01XMLSofenτa ^{" i} _k H

, , χtnlnsrsoap?="nttpJ/scHernas.X(jlsoap.orgtsθap/eήyelόp > ₇

<soap:Body ⁱ : ^* '^* ~ _{\ f} ^" ' ^{" '}' ^'' ^f

< <rerhoveDeviceFromActtveSessϊon rnfns^^,htt operώorsi⁵Unique.iιarne5 ace enJle * ^•• ;<ϋs4rlD>lDld^'ehtϊfing he_iuser</usertD - .„_* \, * ^{* * ' '}'-

- <sessionlD> ID i e tif i g the session </sesior»ID>, * > . , ,„ -^■'

, <ι:erήoveDevlceAddress _^A re s of_kde₄vice.tό reήptfe /ζerrιφveDevrcέeAddress> </reri -γepe ceFro Arfivøέeέsfon X *% \ - ^" ]* , ' ' ⁵

; øap;Body> \ -.. ^ ». _, '.' ^{*' '*} , - ., „ ' _.

^/soap;envelope> ^{* !} -. ^"___, p ^> __« ^*_'* ^'* "J '•

<?XML vereion-="1.{f encodmg^'utf-S'^ <soap:enveIopβ xmlns:xsϊ«ht :/w w.w3.org/2001X LSche a-insfance x ins:χsd=httpfΛv .w3,org/2001XMLSchema xmins:soap="http://schemas.xmteoap.org/soap/envόlop > <soaρ:Body

<removeDeviceFromActiveSessionResponse> <remGVeDeviceFrørrιActiveSessionRes^^

<acknowledgement success or failure </ackno tedgernent> </removeDev)ceF rørnActiveSessionResutø* </removeDevlceFrornActiveSessionResponse> </soap;Body </soap;envelope>

Invoking this method will remove the indicated device from the Virtual Terminal session if the userlD, sessionID and fromDeviceAddress are correct. A response message will notify if the device was successfully removed or not. If the device that is removed is the only device in the Virtual Terminal participating in the session, the session will be terminated.

- The endSession method

This method takes two parameters; a userlD to identify the user and a sessionID to identify the session that is to be 21 ended. If the userlD corresponds to the user that owns the session corresponding to sessionID, that session will be terminated upon invoking this method. The SOAP messages will be:

<?XML version«^B1.0" encoding="utf**8"?> <soap:envelope xmlns:xsi=http.VΛvww.w3.org/2001 XiyiLSchema-instance xmIns:xsd=http;/ www. 3.oιg/2001 X L,Schema xmins:soap='^,http://schemas.xmisoap.oηg/soap/envelope/"> I <soapBody> <endSessionResponse> <endSessϊon e uftxmlns=^,lhttpJ/o erators.unique.narnβs ace.l θn1ϊiier^,'^

<ackno Iθdgement> success or failure </ackno ledge ent </endSessionResutt </ettdSessιonRθspoπse> </soap:Body> </soap^enveiope>

Virtual Terminal user profile management as XML Web Services

These methods will offer Virtual Terminal user profile management as an XML Web Service. Before considering the specific methods that will be exposed, it is useful to consider the structure of the user profiles. In the Virtual Terminal system there will be registered a number of Virtual Terminal users. The users will be identified by unique userlDs and a Virtual Terminal address that others can use to address the Virtual Terminal belonging to that user, and there will be subscription and billing info etc. Each user will also have a Virtual Terminal user profile. This is illustrated in Fig. 9. 22

The virtual Terminal user profiles are divided into different parts; address book, environments, device list, schedule etc. The Virtual Terminal user profile management functions that will be offered as XML Web Services will allow 5 for adding, deleting and editing entries in these user profiles. Fig. 10 shows the structure of the Virtual Terminal user profiles. Each profile can contain an address book, a device list, a number of environments and a schedule. The address book may contain contacts, which again can have one ιo or more devices. The device list is a list with 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 (there will always exist a default environment) , and each environ- i5 ment contains a list of devices available within that environment, e.g. fixed office phone within at work environment. Of all the different environments, one will always be the active environment. This is contained in a timetable within the schedule that dictates which environment to be

20 active at different times.

As listed at page 15 there are several methods for managing the Virtual Terminal user profile that will be exposed as XML Web Services. However, the procedure is quite similar, and only the first four of the list will be described 25 in more details, dealing with registered devices and the device list.

- The getDeviceList method

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

- The saveDeviceList method

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

<device> <dθvic©Na e> Name of first device </devJceName> ' <devicøAddress> address of first device </deviceAddress>

<devicβTyp©> Type of first device </dβvte©Typ©> <t©rminalCapabiJities> Capabilities of first device ξftβr inalCapabilitiβs> etc, </devioe> <device> <devic©Namø> Name of second device </d©viqeName> ¹ <devic©Address> address of second device < d©vieβAddrβss

<devic©Typ©> Type of second device </devic©Type> <t©rminaiCapabi|ities> Capabilities of second device </terminalCapabilities> etc... </device> ©tc.„ </devϊc©Ust> r </saveDevic©Ust> ^! </soap:Body> </soap;©nvβlop©>

- The registerDevicelnVirtualTerminal method

This method takes two parameters; a userlD and a device. The userlD will identify the user that wants to register a device in his Virtual Terminal and hence identify which device list to add the device to. The device will contain information about the device such as device name, address, type, capabilities etc. The response message will indicate 25 success or failure. The SOAP messages used to invoke this XML Web Service is shown below:

<?X L , version-^ .0" encoding="utf-8'?> <soap:©nveioρe xmIns.'Xsi-*-http Λιtww.w3.otg/2001/XMLScheiτιa*'ir(stance x lns:xsd«h%ι/Λvww.w3.oιg/2001/XMLSchβroa xm(ns soap~ 'http://schemas.xnilspap.org/soap/envelope ">

<soap;Bαdy> <registerDevieelnVirtuaJTerminalxmirø <qserlD> iD identifying the user </user(D> <device> <devic©Name> Name of device </d©vϊceName> <deviceAddress> address of device </d©viceAddress> <deviceTyp© Type of device </dθviceType> <tβrminaiCapabiifflβs> Capabilities of device <ΛerminaJCapabiHtϊes> etc... </device> </registerDevicelnVirtualTerm!nal> </soap:8ody> </soap:envelope>

</soap:enyejjαpe> ^*

- The removeDeviceFromVirtualTerminal method

This method takes two parameters; a userlD to identify the user and a deviceAddress that uniquely identifies the device that is to be removed from the user's device list. The SOAP request and response messages are given below: 26

The other methods providing management of the Virtual Ter- 5 minal 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 possibilities to manage an address book, environments and a schedule that is specific to the Virtual Terminal as XML ιo Web Services.

Use Scenarios

Administering the Virtual Terminal service through the administration interface

The Virtual Terminal XML Web Service will provide an inter- i5 face that allows 3^rd parties to include their own users in the Virtual Terminal system. A scenario can be a 3^rd party service provider that has an agreement with a Virtual Ter- 27 minal service provider that allows him to add a certain number of users to the system.

1. The 3^rd party service provider will receive a pool of userlDs and corresponding Virtual Terminal addresses that can be given out to their customers.

2. A user will subscribe to the Virtual Terminal server from the 3^rd party service provider.

3. The 3^rd party service provider will add the user to the Virtual Terminal system through the Virtual Terminal service management XML Web Service offered by the Virtual Terminal service provider. A userlD, password and a Virtual Terminal address will be assigned to the user.

4. The user will receive his userlD, password and Virtual Terminal address from the 3^rd party service provider.

5. From this point on, 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 Fig. 11.

Customised Virtual Terminal service

Another scenario is for an enterprise to offer its own Virtual Terminal service to its employees. This can be done by exploiting the Virtual Terminal services exposed as XML Web Services without having to implement a new Virtual Terminal system. The employees can for example use this service to transfer a telephone session from his fixed office phone to his mobile phone when leaving the office. This scenario will involve the following steps : 28

₁. _A user has an ongoing Virtual Terminal voice session on his fixed office phone and is logged in to the Virtual Terminal service on his PC.

2. Via his browser on his PC, he sends a request to trans¬

5 fer the session to the 3^rd party's Web Server, including information about userlD, sessionID, number of the fixed office phone and the number of the mobile phone.

3. The Web Server runs an XML Web Services client upon receipt of the request from the user. This client sends a

10 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. adding the mobile phone to the session and tearing down the connec- i5 tion with the fixed phone.

5. The user can continue the session on his mobile phone as he leaves his office .

This is illustrated in Fig. 12.

ith this type of scenario, the user will experience a cus- 20 tomised version of the Virtual Terminal service. Other customised version can also be offered to other customers at the same time using the same original Virtual Terminal service (see Fig. 13) . In Fig. 13 each of the Virtual Terminal services (1 - 4) has a different flavour, e.g. different 25 user interface, different billing system, different additional services, different Virtual Terminal service components etc. This scenario will be enabled by the invention of Virtual Terminal as an XML Web Service.

Claims

29P a t e n t c l a i m s

1. _An arrangement in a communication system including a first web server hosting a virtual terminal service, c h a r a c t e r x z e d x n a 3 party web server with an interface offering a customized virtual terminal service for end users, said customized virtual terminal service fetching its functionality from the virtual terminal service located on said first web server through a first SOAP interface on said first web server.

2. An arrangement as claimed in claim 1, c h a r a c t e r i z e d i n that said first web server is provided with a second SOAP interface for administration of the virtual terminal service.

3. An arrangement as claimed in claim 2 , c h a r a c t e r i z e d i n that said first web server is holding a database of end user identity and profile information, and said 3^rd party can add end users to and remove end users from said database through said second SOAP interface.

4. An arrangement as claimed in claim 1, c h a r a c t e r i z e d i n that said first web server is offering the following services to clients : initiate call 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 get device list save device list get address book save address book 30 add contact to address book remove contact from address book get environment list save environment list add environment remove environment get schedule save schedule get terminal preferences save terminal preferences .