WO2009087271A1

WO2009087271A1 - Providing internet services in communications system

Info

Publication number: WO2009087271A1
Application number: PCT/FI2009/050004
Authority: WO
Inventors: Juho Seppänen
Original assignee: Teliasonera Ab
Priority date: 2008-01-08
Filing date: 2009-01-07
Publication date: 2009-07-16
Also published as: FI20085011L; FI20085011A0

Abstract

The present solution relates to providing an IP service to a user terminal (UE 1, UE2). A first buddy list is obtained, including information on user terminals registered as a buddy of a first user terminal (UE1 ) for a first IP service (X, Y). Also a second buddy list is obtained, including information on user terminals registered as a buddy of the second user terminal (UE2) for the first IP service (X, Y). If the first and second user terminals (UE1, UE2) are registered in a second IP service (TS)1 and if the first buddy list includes information on the second user terminal (UE2) and vice versa, information on the second user terminal (UE2) registered is provided to the first user terminal (UE1), and information on the first user terminal (UE1) is provided to the second user terminal (UE2).

Description

PROVIDING INTERNET SERVICES IN COMMUNICATIONS SYSTEM FIELD OF THE INVENTION

The present invention relates to providing an IP service to a user terminal. BACKGROUND OF THE INVENTION

Voice over Internet protocol (IP) to a technique using the Internet protocol to carry and route two-way voice communications. Voice information is sent in discrete packets in a digital form. Voice over IP may support telephone-to-telephone links via suitable adapters and/or voice communications from a telephone to an IP terminal (such as a PC with a sound card) or from IP terminal to IP terminal.

Instant messaging (IM) refers to a service that enables users who subscribe to the service and who are online at the same time, to exchange messages via the Internet. Skype is an Internet service that enables a user to make calls from a computer. Typically, calling to other people on Skype is free, and calling to phones and mobiles around the world is fairly cheap. This goes both for voice and video calls. The user is also able to have group chats, conference calls with up to nine people and forward calls to other Skype contacts, MSN Messenger service enables the user to communicate in the network by utilizing instant messaging, voice or video. It also enables transmitting files and pictures, playing games, introducing music to friends, and selecting and personalizing icons and wallpapers.

However, the use of Internet services like Skype and MSN Messen- ger is mainly limited to computer users.

Fring is a free mobile voice over Internet protocol (VoIP) application that enables the user to make voice calls, chat and check out who is online before dialing (real-time presence). Fring utilizes wireless fidelity (WiFi) or a mobile Internet data plan to enable a user to make mobile Internet calls and live chat to other Fring users and other netwoks including Skype and MSN Messenger.

One of the problems associated with the above arrangement is that e.g. in Fring, the service does not know if the user's friend is using Fring. BRIEF DESCRIPTION OF THE INVENTION

An object of the present invention is thus to provide a method, system, server, user terminal and a computer program product for implementing the method so as to solve above problems. The objects of the invention are achieved by a method and an arrangement which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.

The invention is based on the idea of providing an IP service to a user terminal, where a first buddy list is obtained, including information on user terminals registered as a buddy of a first user terminal for a first IP service. Also a second buddy list is obtained, including information on user terminals registered as a buddy of the second user terminal for the first IP service. The system is configured to recognise if the first and second user terminals are registered in a second IP service. As a response to the recognising, the system is configured to check the first and the second buddy list. If the first buddy list includes information on the second user terminal and if the second buddy list includes information on the first user terminal, the system is configured to provide information (e.g. a username or email address) on the second user terminal registered in the second IP service, to the first user terminal, and informa- tion on the first user terminal registered in the second IP service, to the second user terminal.

An advantage of the method and arrangement of the invention is that it provides an IP service operator with a way to facilitate users to start using the IP service operator's network for mutual communication instead of an Internet operator's network.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of preferred embodiments with reference to the attached drawings, in which Figure 1 illustrates a communications system according to a first embodiment of the present solution;

Figure 2 illustrates signalling according to an embodiment of the present solution;

Figure 3 illustrates operation of an access server according to an embodiment of the present solution; Figure 4 illustrates operation of a user terminal according to an embodiment of the present solution;

Figure 5 illustrates a communications system according to a second embodiment of the present solution. DETAILED DESCRIPTION OF THE INVENTION

In the following, embodiments of the present solution will be described with reference to a cellular or wireless communications system, such as a third generation (or beyond 3G) mobile communications system or WLAN (wireless local area network). However, the solution is not meant to be re- stricted to these embodiments. The present solution is applicable to any user terminal, network node, corresponding components), and/or to any communication system or any combination of different communication systems capable of providing or supporting IP services, such as voice over IP (VoIP) and/or instant messaging (IM) services. The communication system may be a fixed communication system or a wireless communication system or a communication system utilizing both fixed networks and wireless networks. The protocols used, the specifications of communication systems and network nodes, especially in mobile and wireless communication, develop rapidly. Such development may require extra changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. The relevant inventive aspect is the functionality concerned, not the network element or equipment where it is executed.

The present solution allows a mobile service operator to exploit Internet operator networks such as Skype, MSN Messenger and/or Fring, in order to introduce its own IP services. The present solution enables a fast way to increase the popularity of the service operator's VoIP and/or instant messaging network. This quick mushrooming is useful when a service operator's service is being introduced. The present solution can bind users effectively to the service operator's services instead of services provided by Internet opera- tors (such as Skype etc.). By means of the present solution, the user can be motivated to use the mobile service operator's network for local communication with services similar to those of the Internet operator, but with a better reliability and quality. The present solution reduces a risk of the service operator being merely a bit pipe, especially if many of its subscribers are fundamentally users of the service provided by an Internet operator. The solution may also give a better base of usage of other services provided by the cellular operator, used with the same VolP/IM identity. Even though the services provided by the Internet operators are emerging to mobile phones, they are mainly used in personal computers (PC). The present solution enables an effective and wide- spread use both mobile terminals and in PC's (with a PC client for PC users).

The present solution is applicable to a service operator-run Vo IP/I M service with connections to other networks such as Skype and MSN Messenger. In the solution, a client is primarily providing the service operator VoIP service, but access to Internet operator networks such as Skype and MSN Messenger is also provided. That does not need to be done with interworking, but by giving the access to the Internet operator network via the same client. (A partnership agreement may or may not be required between the service operator and the Internet operator). A server (such as an access server) operated by the service operator may be used as a proxy to the Internet operator network in order to make identification (ID) detection possible (the client may assist in the identification detection, if necessary). This may implemented by running a back-end at the server (where the service operator IP service runs) and a front-end at the client (software on the user terminal, controlling a profile running on the server), thus enabling a more lightweight client. The access to the VolP/IM service may or may not be limited to the service operator subscribers.

The present solution is applicable e.g. to a situation where at least two user terminals are users of an Internet operator network, and where they are each other's "buddies", i.e. "friends", in the Internet operator network. In prior art systems, the user terminals do not know if they both also are users of a service operator IP service. The present solution provides a client for accessing to the Internet operator network via the client. If the at least two user terminals have the same client, i.e. they use the same IP service provided by the service operator (but are not aware of that), the access server is able to recog- nise this. After the recognition, the server is able to inform the user terminals in that they both are also subscribers of the service operator network. Here, the term client may refer to software running in the user terminal (such as a mobile phone and/or a PC).

A first user terminal is provided with information on a buddy list, in- eluding information (e.g. username, user identification, nickname, and/or email address) on at least one second user terminal (or user) that the first user ter- minal is able to communicate with by using the Internet operator service (i.e. the first and second user terminals are each other's "buddies"). According to the present solution, the user terminal is provided with information on a modified buddy list, including information on user terminals (or users) that are also buddies of the user terminal in the service operator network (in addition to being buddies in the Internet operator network).

Before adding the user terminal onto a modified buddy list, the server may be arranged to request the user terminal's permission whether the user wishes to be a buddy of the other user also for the service operator net- work.

By means of the modified buddy list, the user can be provided with information on those of his/her buddies of that are also able to use of the service operator IP service (in addition to using the Internet operator service).

The server may be arranged to add a username and password for the buddy into the service operator service profile.

The buddy list may be used to provide information on the buddy's presence (online, busy etc.).

Figure 1 illustrates a communications system S according to a first embodiment of the present solution. The system S comprises at least one user terminal UE1, UE2 that may be e.g. a mobile, wireless or fixed terminal, such as a mobile phone (mobile station), a personal digital assistant (PDA), a laptop or the like, capable of using VoIP and/or instant messaging services. The user terminal UE1, UE2 is connected to an IP core network, via an access network AN, such as a third generation radio access network (3G RAN) or wireless lo- cal area network (WLAN) operated by a mobile and/or wireless network operator. The system S further includes an access server AS such as a VoIP access server operated by a service operator, for providing the user terminal UE, UE2 with access to a corresponding service operator service domain TS. Another option is that the user terminal is connected "directly" to the service operator service via e.g. the Internet. Connections with Internet operator networks X, Y (such as Skype and/or MSN Messenger) may be implemented either via IMS (IP multimedia subsystem) and/or IPX (Internet packet exchange) or without them, over the network operator IP core network to the Internet. Figure 1 shows a simplified version of a cellular or wireless network structure, which only illustrate the components necessary for illustrating the present solution, even though those skilled in the art naturally know that a general communica- tions system also comprises other functions and structures, which do not have to be described in more detail herein. Although each network node or function UE1, UE2, AN, TS, AS, X, Y has been depicted as one entity, different modules and memory may be implemented in one or more physical or logical entities.

A possible use case may be as follows. Both user terminals UE1, UE2 have recently registered in a service operator VoIP network TS (for example, chatting). The user terminals are initially buddies "only" in an internet operator network X, Y. They do not know that they both are also members of the service operator VoIP network TS. However, in the present solution the server is able to detect the case and to introduce the user terminals UE1, UE2 to each other within the TS network. The present solution facilitates the users to start using the service operator network for mutual communication instead of the Internet operator network. This possibly gives option to check also GSM contacts, whether or not they are using also the same service. User identity for TS may be linked e.g. to an IMSI (international mobile subscriber identity) number of the respective user terminal UE1, UE2. The solution may also enable inviting contacts that are not yet using the IP service. The solution may or may not be limited to subscribers of the same service operator only. By means of the solution, buddy lists can be gathered in one common list in the client. The buddy lists are stored and/or cached (they may be hashed if required e.g. for privacy purposes) in AS.

Figure 2 illustrates signalling between network entities according to an embodiment of the present solution. At first, buddy lists maintained in the access server AS may look like as follows:

After that the first user terminal UE1 (i.e. "John") logins to TS by transmitting a message 2-1 to AS. The first user terminal UE1 further logins to X, Y by transmitting a message 2-1 , 2-2 via AS to X, Y. After receiving message 2-2 in X, Y, buddy lists for UE1 for the first IP service X₁ Y is provided 2- 3, 2-4 via AS to UE1. AS may modify the messages 2-1 , 2-2, 2-3, 2-4, if nee- essary, as different protocols may be used between UE and AS, and between AS and X, Y (it should be noted that if there are more than one Internet operators X, Y the services of which UE1 logins, a separate message 2-2 is needed for each Internet operator service, one that is transmitted from AS to X, and another that is transmitted from AS to Y (the same applies for message 2-3)). After that, buddy lists maintained in the access server AS may look like as follows (John is online in TS, X and Y):

Then the second user terminal UE2 (i.e. "Mike") logins to TS by transmitting a message 2-5 to AS to TS. The second user terminal UE2 further logins to X by transmitting a message 2-5, 2-6 via AS to X. After receiving message 2-6 in X, buddy lists for UE2 for the first IP service is provided 2-7, 2- 8 via AS to UE2. After that, buddy lists maintained in the access server AS may look like as follows (Mike is online in TS and X):

In step 2-9, TS VoIP AS is arranged to check the buddy lists, wherein it is detected that John and Mike are friends in X but not yet in TS VoIP. Therefore, buddy requests 2-10, 1-11 are transmitted from AS to UE1 and UE2, in order to inform John and Mike that they both are also users of TS VoIP. After receiving the buddy request, the respective user terminal UE1 may be arranged to display an introduction text such as: "Your friend Mike@X is also using TS VoIP. Would you like to add him to your contacts in order to communicate via TS VoIP network?" (UE1 may be arranged to display: "Your friend John@X is also using TS VoIP. Would you like to add him to your contacts in order to communicate via TS VoIP network?"). The user terminal UE1, UE2 responds by transmitting 2-12, 2-13 a buddy response, wherein the user terminal UEI₁ UE2 agrees or disagrees with the buddy request. If the user terminals UE1, UE2 agree with the buddy request (i.e. a positive buddy response 2-12, 2-13 is received in AS from both (or at least two) of the terminals UE1, UE2), AS is arranged to create 2-14 modified buddy lists for UE1 and UE2 for the second IP service TS. The modified buddy lists may be as follows (right column):

After that information on the modified buddy list (or only an update to the respective buddy lists (i.e. "new buddy" information), depending on the implementation of handling buddy list updates) may be provided 2-15, 2-16 to the respective user terminal UE1, UE2. After that UE1 and UE2 may start to use TS for mutual communication (instead of X (or Y)). If both (or all) of the user terminals UE1, UE2 disagree with the buddy request, the buddy lists are not modified in step 2-14, and UE1, UE2 can continue communicating as before. If only one of the users UE1, UE2 agrees with the request, the system may form an asymmetric buddy list connection (depending on the system implementation) so that the one that disagreed is able to see the one that agreed, in his buddy list, but not vice versa.

Figure 3 is a flow chart illustrating the operation of a server node AS according to an embodiment of the present solution. A login message from the first user terminal UE1 (i.e. "John") to X, Y, TS, is received 3-1 in AS. After that, the login message regarding X and Y is forwarded 3-2 to X, Y. In step 3-3, a buddy list for UE1 for the first IP service X, Y is received from X, Y, and it is forwarded 3-4 to UE1. A login message from the second user terminal UE2 (i.e. "Mike") to X, TS, is received 3-5 in AS. After that, the login message re- garding X and Y is forwarded 3-6 to X. In step 3-7, a buddy list for UE2 for the first IP service X is received from X, and it is forwarded 3-8 to UE2. In step 3-9, TS VoIP AS is arranged to check the buddy lists, wherein it is detected that John and Mike are friends in the first IP service X but not yet in the TS service. Therefore, buddy requests are transmitted 3-10 from AS to UE1 and UE2, in order to inform John and Mike that they both are also users of the TS service, but not yet friends via it. If the user terminals UE1, UE2 agree with the buddy requests, positive buddy responses 3-11 are received from UE1 , UE2, and AS is arranged to create 3-12 modified buddy lists for UE1, UE2 for the second IP service TS. After that, information on the modified buddy lists may be provided 3-13 to the user terminals UE1, UE2. If both of the user terminals UE1, UE2 disagree with the buddy request, the buddy lists are not modified in step 3-12.

Figure 4 is a flow chart illustrating the operation of a first user terminal UE1 according to an embodiment of the present solution. In step 4-1 , the first user terminal UE1 (i.e. "John") logins to X, Y, TS by transmitting a login message towards AS. Then a buddy list for UE1 for the first IP service X, Y is received 4-2 from AS. In step 4-3, a buddy request is received from AS, informing John that "Mike" (i.e. UE2) is also a user of TS VoIP. After receiving the buddy request, UE1 is arranged to display 4-3 an introduction text such as: "Your friend Mike@X is also using TS VoIP. Would you like to add him to your contacts in order to communicate via TS VoIP network?". UE1 may respond by transmitting 4-4 a buddy response, informing that the user of the user terminal UE1 agrees (or disagrees) with the buddy request. After that, information on a modified buddy list for TS may be received 4-5 from AS (indicating that Mike has agreed to be John's buddy for TS and that John has agreed to be Mike's buddy for TS). If Mike does not want to be John's buddy, a respective notification may (or may not) be received 4-5 in UE1.

The present solution enables the service operator IP service subscribers to find each other. An advantage of that is that if they start to use the service operator IP service, the traffic does not necessarily have to travel as long distances as when using the Internet operator service. This is because the access server of the service operator is usually located in the home country of the user terminal and the Internet operator server is often located abroad.

According to the present solution, the user terminal may use the service operator IP service as the basic service, wherein the Internet operator IP service is used as a supplement to the basic service.

The identity of the buddy for TS, X and/or Y, may appear (i.e. displayed to the user) on the buddy list e.g. as a username, as a user ID, as a nickname, as an email address (which may be changed to a "user-friendly" form by the user), and/or as a combination these. For example, the buddy's phone number may be identified, and the user may add the name of the buddy (as in a phone book of a mobile phone).

According to an embodiment, the present solution comprises maintaining Internet operator specific buddy lists for registered user terminals.

According to an embodiment, the present solution comprises main- taining service operator specific buddy lists for registered user terminals.

According to an embodiment, the present solution comprises updating the buddy lists for X, Y, TS, maintained in AS, wherein information on the updated buddy lists may be provided to the respective user terminal UE1, UE2.

The access server may be arranged to transmit a unified buddy list to UE1, LJE2, where the user terminals registered as a buddy of UE1, UE2 for the first and second IP service TS, X, Y are included. Another option is that only updated buddy list information is transmitted to UE1, UE2, for example, only the user terminals registered as a buddy of UE1, UE2 for TS may be included. Thus the buddy list or the modified buddy list may include information on e.g. all of the user terminal's buddies or only the latest registrations as a buddy.

Figure 5 illustrates a communications system S according to a second embodiment of the present solution, illustrating a further environment of use of ID detection. As shown in Figure 5, the second embodiment resembles the first embodiment. In the second embodiment, a rich communication environment enables users with mobile devices (and possibly also PCs) UE1 to combine existing mobile services (e.g. IM, voice, and video) such that e.g. in a mobile phone, contact information on the phone's address book shows a contact's presence and available services (that the contact is able to support). Thus the environment involves a rich communication platform for gathering services together, enabling users to see which services other users are able to use in order to communicate with them. The platform enables different services to use the same address book and show users' abilities for different kinds of services. For ID detection, the environment facilitates a TS client (the client of the service operator's service TS) to detect whether the user has logged in e.g. in Skype X, and to detect who are the user's buddies in that network X. Thereby, the TS client may be arranged to send information on the user's Skype etc. friends to the TS server AS. Then, as the TS client of the user's friend sends its Skype etc. contact information to the server AS, the TS server AS is able to detect their availability (and that they are not yet friends in the TS service) in the TS service. Thus, the TS client may be equal to Skype and other clients running on the phone UE1, UE2 (and not at the server), but could see the user information of the services (including Skype) from the address book of the user device UE1 The second IP service TS and each of the first IP services involve their own clients on the user terminal UE1. The TS client is able to read the buddy lists for X, Y, and to provide them to the server AS. Thus the buddy lists for X, Y are included on a common contact list of the platform, and they can be utilized by various applications.

The items and steps shown in the figures are simplified and only aim at describing the idea of the present solution. The steps/points, signaling messages and related functions described above in Figures 1 to 5 are in no absolute chronological order, and some of the steps/points may be performed simultaneously or in an order different from the given one. Other functions may also be executed between the steps/points or within the steps/points and other signaling messages sent between the illustrated messages. Some of the steps/points or part of the steps/points can also be left out or integrated together or replaced by a corresponding step/point or part of the step/point. The apparatus operations illustrate a procedure that may be implemented in one or more physical or logical entities. The signaling messages are only exemplary and may even comprise several separate messages for transmitting the same information. The messages serve only as examples and they may contain only some of the information mentioned above. In addition, the messages may also contain other information, and the titles may deviate from those given above. Instead of or in addition to an access server, and/or user terminal, the above- described operations may be performed in any other element of a communica- tions system. In addition to prior art means, a system or system network nodes that implement the functionality of the present solution comprise means for managing buddy lists in a manner described above. Existing network nodes and user terminals comprise processors and memory that may be utilized in the operations of the present solution. Any changes necessary in implementing the present solution may be carried out using supplements or updates of software routines and/or routines included in application-specific integrated circuits (ASIC) and/or programmable circuits, such as EPLDs (electrically programmable logic device) or FPGAs (field programmable gate array). It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1. A method of providing an IP service to a user terminal in a communications system (S), the system (S) comprising a first user terminal {UE1 ) registered in a first IP service (X, Y), and a second user terminal (UE2) registered in the first IP service (X, Y), the method comprising obtaining (2-3, 2-4) a first buddy list, the first buddy list including information on one or more user terminals registered as a buddy of the first user terminal (UE1) for the first IP service, obtaining (2-7, 2-8) a second buddy list, the second buddy list including information on one or more user terminals registered as a buddy of the second user terminal (UE2) for the first IP service, recognising (2-9, 3-9) if the first user terminal (UE1) is registered in a second IP service (TS) and if the second user terminal (UE2) is registered in the second IP service (TS)₁ as a response to said recognising, checking (2-9, 3-9) the first buddy list and the second buddy list, wherein, if the first buddy list includes information on the second user terminal (UE2) and if the second buddy list includes information on the first user terminal (UE1 ), the method comprises providing (2-10, 3-10), to the first user terminal (UE1 ), information on the second user terminal (UE2) registered in the second IP service (TS), providing (2-11, 3-10), to the second user terminal (UE2), information on the first user terminal (UE1) registered in the second IP service (TS), c h a r a c t e r i z e d in that the method comprises transmitting (2-10), from a server node (AS) to the first user terminal

(UE1), a first buddy request (2-10) for requesting whether the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS); transmitting (2-11 ), from the server node (AS) to the second user terminal (UE2), a second buddy request (2-11) for requesting whether the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1) for the second IP service (TS); receiving the first buddy request in the first user terminal (UE1); and receiving the second buddy request in the second user terminal (UE2).

2. A method as claimed in claim 1, characterized in that the method comprises obtaining, in the first user terminal (UE1), information on whether the user of the first user terminal wishes to be a buddy of the second user ter- minal (UE2) for the second IP service; wherein if the obtained information indicates that the user of the first user terminal wishes to be a buddy of the second user terminal (UE2) for the second IP service, the method comprises transmitting (2-12, 4-4), from first the user terminal (UE1) to the server node (AS), a first buddy response indicating that the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS).

3. A method as claimed in claim 1 or 2, characterized in that, if information indicating that the user of the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS) and if information indicating that the user of the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1) for the second IP service (TS) is received in the server node (AS) from the first user terminal (UE1) and the second user terminal (UE2) respectively, the method comprises establishing (2-14, 3-12) modified buddy lists, wherein a first modified buddy list includes information on the second user terminal (UE2) registered as a buddy of the first user terminal (UE1) for the second IP service, and a second modified buddy list includes information on the first user terminal (UE1 ) registered as a buddy of the second user terminal (UE2) for the second IP service.

4. A method as claimed in claim 1,2 or 3, characterized by providing (2-15, 3-13), to the first user terminal (UE1), information on the second user terminal (UE2) registered as a buddy of the first user ter- minal (UE1) for the second IP service (TS), and providing (2-16, 3-13), to the second user terminal (UE2), information on the first user terminal (UE1) registered as a buddy of the second user terminal (UE2) for the second IP service (TS).

5. A method as claimed in any one of the preceding claims, characterized by conducting communication between the first user terminal (UE 1) and the second user terminal (UE2) by utilizing the second IP service.

6. A method as claimed in any one of the preceding claims, characterized by combining the first buddy list and the first modified buddy list and providing information on the combined buddy list to the first user terminal (UE1).

7. A method as claimed in any one of the preceding claims, characterized in that the first IP service is a service offered by an Internet service opera- tor, and the second IP service is a service offered by a service operator.

8. A method as claimed in any one of the preceding claims, characterized in that the first IP service is at least one of Skype, MSN Messenger, and Fring.

9. A method as claimed in any one of the preceding claims, characterized in that the second IP service is a VoIP and/or IM service offered by a mobile service operator.

10. A method as claimed in any one of the preceding claims, characterized by maintaining Internet operator specific buddy lists and/or service operator specific buddy lists.

11. A method as claimed in any one of the preceding claims, characterized by displaying the identity of the buddy as at least one of a username, email address, phone number, and user-defined name.

12. A communications system (S) comprising a first user terminal (UE1 ) registered in a first IP service (X₁ Y), and a second user terminal (UE2) registered in the first IP service (X, Y), wherein the system (S) is configured to obtain a first buddy list, the first buddy list including information on one or more user terminals registered as a buddy of the first user terminal (UE 1 ) for the first IP service, obtain a second buddy list, the second buddy list including information on one or more user terminals registered as a buddy of the second user terminal (UE2) for the first IP service, recognise if the first user terminal (UE1) is registered in a second IP service (TS) and if the second user terminal (UE2) is registered in the second IP service (TS); wherein if the first and the second user terminal (UE1 , UE2) are registered in the second IP service (TS), the system (S) is configured to check the first buddy list and the second buddy list; wherein if the first buddy list includes information on the second user terminal (UE2) and if the second buddy list includes information on the first user terminal (UE1 ), the system is further configured to provide, to the first user terminal (UE1), information on the second user terminal (UE2) registered in the second IP service (TS); provide, to the second user terminal (UE2), information on the first user terminal (UE1 ) registered in the second IP service (TS), c h a r a ct e r i z e d by the system (S) being configured to transmit, from a server node (AS) to the first user terminal (UE1), a first buddy request for requesting whether the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS); transmit, from the server node (AS) to the second user terminal (UE2), a second buddy request for requesting whether the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1) for the second IP service (TS); receive the first buddy request in the first user terminal (UE1 ); and receive the second buddy request in the second user terminal (UE2).

13. A system as claimed in claim 12, c h a r a c t e r i z e d in that the system (S) is configured to obtain, in the first user terminal (UE1), information on whether the user of the first user terminal wishes to be a buddy of the second user terminal (U E2) for the second IP service; wherein if the obtained information indicates that the user of the first user terminal wishes to be a buddy of the second user terminal (UE2) for the second IP service, the system (S) is configured to transmit, from first the user terminal (UE1) to the server node (AS), a first buddy response indicating that the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS).

14. A system as cf aimed in claim 12 or 13, c h a r a c t e r i z e d in that, if information indicating that the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS) and if information indicating that the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1) for the second IP service (TS) is received in the server node (AS) from the first user terminal (UE1) and the second user terminal (UE2) respectively, the system (S) is configured to establish modified buddy lists, wherein a first modified buddy list includes information on the second user terminal (UE2) registered as a buddy of the first user terminal (UE1) for the second IP service, and a second modified buddy list includes information on the first user terminal (UE1) registered as a buddy of the second user terminal (UE2) for the second IP service.

15. A system as claimed in claim 12, 13 or 14, c h a ra cte r i z e d in that it is configured to provide, to the first user terminal (UE1), information on the second user terminal (UE2) registered as a buddy of the first user terminal (UE1) for the second IP service (TS), and provide, to the second user terminal (UE2), information on the first user terminal (UE1) registered as a buddy of the second user terminal (UE2) for the second IP service (TS).

16. A system as claimed in any one of the preceding claims 12 to

15, c h a ra c t e r i z e d in that it is configured to conduct communication between the first user terminal (UE1) and the second user terminal (UE2) by utilizing the second IP service.

17. A system as claimed in any one of the preceding claims 12 to 16, c h a r a c t e r i z e d in that the first IP service is a service offered by an

Internet operator, and the second IP service is a service offered by a service operator.

18. An access server (AS) of a communications system (S), the system (S) comprising a first user terminal (UE1 ) registered in a first IP service (X, Y), and a second user terminal (UE2) registered in the first IP service (X, Y), wherein the access server (AS) is configured to obtain a first buddy list, the first buddy list including information on one or more user terminals registered as a buddy of the first user terminal (UE1 ) for the first IP service, obtain a second buddy list, the second buddy list including information on one or more user terminals registered as a buddy of the second user terminal (UE2) for the first IP service, recognise if the first user terminal (UE1 ) is registered in a second IP service (TS) and if the second user terminal (UE2) is registered in the second IP service (TS); wherein if the first and the second user terminal (UE1 , UE2) are registered in the second IP service (TS), the access server (AS) is configured to check the first buddy list and the second buddy list; wherein if the first buddy list includes information on the second user terminal (UE2) and if the second buddy list includes information on the first user terminal (UE1), the access server (AS) is further configured to provide, to the first user terminal (UE1), information on the second user terminal (UE2) registered in the second IP service (TS); provide, to the second user terminal (UE2), information on the first user terminal (UE1 ) registered in the second IP service (TS), c h a ra c t e r i z e d in that it is configured to transmit to the first user terminal (UE1), a first buddy request (2-10) for requesting whether the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS); and transmit to the second user terminal (UE2), a second buddy request for requesting whether the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1 ) for the second IP service (TS).

19. An access server (AS) as claimed in claim 18, c h a ra cte r- i z e d in that as a response to receiving, from the first user terminal (UE1) and the second user terminal (UE2), information indicating that the first user terminal (UE1 ) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS) and information indicating that the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1) for the second IP service (TS), respectively, the access server (AS) is configured to establish modified buddy lists, wherein a first modified buddy list includes information on the second user terminal (UE2) registered as a buddy of the first user terminal (UE1) for the second IP service, and a second modified buddy list includes information on the first user terminal (UE1 ) registered as a buddy of the second user terminal (UE2) for the second IP service.

20. An access server (AS) as claimed in claim 18or19, charac- terized in that it is configured to provide, to the first user terminal (UE1), information on the second user terminal (UE2) registered as a buddy of the first user terminal (UE1) for the second IP service (TS)₁ and provide, to the second user terminal (UE2), information on the first user terminal (UE1) registered as a buddy of the second user terminal (UE2) for the second IP service (TS).

21. An access server (AS) as claimed in claim 18, 19 or 20, characterized in that it is configured to conduct communication between the first user terminal (UE1) and the second user terminal (UE2) by util- izing the second IP service (TS).

22. An access server (AS) as claimed in any one of the preceding claims 18 to 21, characterized in that the second IP service is a VoIP and/or IM service offered by a mobile service operator.

23. An access server (AS) as claimed in any one of the preceding claims 18 to 22, characterized in that it is configured to maintain Internet operator specific buddy lists and/or service operator specific buddy lists.

24. A first user terminal (UE1) for a communications system (S), wherein the first user terminal (UE1) is configured to register in a first IP service (X, Y), receive information on one or more user terminals registered as a buddy of the first user terminal (UE1 ) for a first IP service, register in a second IP service (TS); wherein, if the first user terminal (UE1 ) is registered as a buddy of a second user terminal (UE2) for the first IP service (X, Y) and if the second user terminal (UE2) is registered as a buddy of the first user terminal (UE1) for the first IP service (X, Y), the first user terminal (UE1 ) is configured to receive, information on the second user terminal (UE2) registered in the second first IP service (TS)₁ characterized in that it is configured to receive a first buddy request from a server node (AS) a first buddy request, the first buddy request requesting whether the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the seoond IP service (TS).

25. A first user terminal (UE 1 ) as claimed in claim 24, c h a r a c t e r i z e d in that it is configured to obtain information on whether the user of the first user terminal wishes to be a buddy of the second user terminal (UE2) for the second IP service; wherein if the obtained information indicates that the user of the first user terminal wishes to be a buddy of the second user terminal (UE2) for the second IP service, the first user terminal (UE1) is configured to transmit to the server node (AS), a first buddy response indicating that the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS).

26. A first user terminal (UE1) as claimed in claim 24 or 25, c h a r a c t e r i z e d in that it is configured to receive information on the sec- ond user terminal (UE2) registered as a buddy of the first user terminal (UE1) for the second IP service (TS).

27. A first user terminal (UE1) as claimed in claim 24, 25 or 26, c h a r a c t e r i z e d in that it is configured to conduct communication with the second user terminal (UE2) by utilizing the second IP service.

28. A first user terminal (UE1 ) as claimed in any one of the preceding claims 24 to 27, c h a r a c t e r i z e d in that it is configured to display the identity of the buddy as at least one of a username, email address, phone number, and user-defined name.

29. A computer program product for a communications system (S) comprising a first user terminal (UE1) registered in a first IP service (X, Y), and a second user terminal (UE2) registered in the first IP service (X, Y), the computer program product comprising program code means stored on a computer readable medium, wherein the computer program prod- uct further comprises a first routine for obtaining a first buddy list, the first buddy list including information on one or more user terminals registered as a buddy of the first user terminal (UE1) for the first IP service, and a second routine for obtaining a second buddy list, the second buddy list including information on one or more user terminals registered as a buddy of the second user terminal (UE2) for the first IP service, a third routine for recognising if the first user terminal (UE1 ) is registered in a second IP service (TS) and if the second user terminal (UE2) is registered in the second IP service (TS)₁ and as a response to said recognising, a fourth routine for checking the first buddy list and the second buddy list, wherein, if the first buddy list includes information on the second user terminal (UE2) and if the second buddy list includes information on the first user terminal (UE1), the computer program product comprises a fifth routine for providing, to the first user terminai (UE1), informa- tion on the second user terminal (UE2) registered in the second IP service (TS), a sixth routine for providing, to the second user terminal (UE2), information on the first user terminai (UE1 ) registered in the second IP service (TS), a seventh routine for transmitting, from a server node (AS) to the first user terminal (UE 1 ), a first buddy request for requesting whether the first user terminal (UE1) wishes to be a buddy of the second user terminal (UE2) for the second IP service (TS); a eighth routine for transmitting, from the server node (AS) to the second user terminal (UE2), a second buddy request for requesting whether the second user terminal (UE2) wishes to be a buddy of the first user terminal (UE1) for the second IP service (TS); a ninth routine for receiving the first buddy request in the first user terminal (U E 1 ); and a tenth routine for receiving the second buddy request in the second user terminal (UE2).