WO2009130390A1

WO2009130390A1 - Presenting and updating presence state in community networks

Info

Publication number: WO2009130390A1
Application number: PCT/FI2009/050321
Authority: WO
Inventors: Markku Rautiola
Original assignee: CONCILIO NETWORKS Oy
Current assignee: CONCILIO NETWORKS Oy
Priority date: 2008-04-25
Filing date: 2009-04-24
Publication date: 2009-10-29
Anticipated expiration: 2010-10-25
Also published as: FI20085380A0

Abstract

A method for making a presence state of a client of a community network accessible via a public mobile telephone system, said a community network including a community network server and a plurality of community network clients. The community network is connected to a core network of a public mobile telephone system via a community gateway operating as a gateway between the core network of the public mobile telephone system and the community network. The method comprises: receiving, in a presence user agent unit comprised by the community gateway, presence information of a community network client either from the community network server or from a mobile terminal of said community network client; and storing, by the presence user agent, said presence information as an attribute in v Card format, said v Card representing a user profile of said community network client.

Description

PRESENTING AND UPDATING PRESENCE STATE IN COMMUNITY NETWORKS

Field of the invention

The present invention relates to community networks, and more particularly to presenting and updating presence state of a contact in contact list of community network client.

Background of the invention

A social network a.k.a. a community network is a social structure generally made of individuals or organizations that are tied by one or more specific types of interdependency, such as values, visions, idea, friends, or favored airline routes. Social networking focuses on the building and verifying of online social networks for communities of people who share interests and activities, or who are interested in exploring the interests and activities of others. It is mostly and primarily a web based service, and it provides a collection of various ways for users to interact, such as chat, messaging, email, video, voice chat, file sharing, blogging, discussion groups, and so on. In general, social networking services allow users to create a profile for themselves. Users can upload a picture of themselves and can often be 'friends' with other users. In most social networking services, both users must confirm that they are friends before they are linked, however, some social networking sites have a 'favorites' feature that does not need approval from the other user. Social networks usually have privacy control that allows the user to choose who can view their profile or contact them, etc.

People in their social networks primarily interact via communication media such as chat, voice chat, video, email, or blogging rather than face to face. Chat often refers to online chat in an internet chat room or instant messaging system. Instant messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not necessarily, short. Instant messages are often used in a conversational mode, wherein the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.

Voice chat is a modern form of communication used on the instant messaging systems. The means of communicating with voice chat is through any of the messengers, mainly Yahoo! Messenger, AOL Instant Messenger or Windows Live Messenger. Voice chat has led to a significant increase in distant communications where two or more people from opposite ends of the world can talk almost free of cost. Voice chat systems use Voice over Internet Protocol (VoIP) protocol for the transmission of voice through the Internet or other packet switched networks. VoIP is often used abstractly to refer to the actual transmission of voice rather than the protocol implementing it. VoIP is also known as IP Telephony and Internet telephony.

Presence information is a status indicator that conveys ability and willingness of a potential communication party to communicate. A user's client provides presence information (presence state) via a network connection to a presence service, which is stored in what constitutes his personal availability record (called a presentity) and can be made available for distribution to other users (called watchers) to convey his availability for communication. Presence information has wide application in many communication services and is one of the innovations driving the popularity of instant messaging or recent implementations of voice over IP clients. A user client may publish a presence state to indicate its current communication status. This published state informs others who wish to contact the user of his availability and willingness to communicate.

People in social networking sites using instant messaging systems can be reached also from basic telephony networks, i.e. from PSTN (Public Switched Telephone Network) or PLMN (Public Land Mobile Network), by just calling them normally e.g. from a mobile handset. The call in this case is routed, for example, through the PLMN to the instant messaging system via an appropriate gateway which converts the PLMN call into an instant messaging session and vice versa. Ordinary mobile handsets' contacts applications typically support for importing and exporting contact data in vCard format. vCard defined electronic business card forms the profile, which is defined for representing and exchanging a variety of information about an individual (e.g. formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). However, vCard profile attributes do not include any attribute that would describe presence status or state of the particular object (i.e. the user) associated with the vCard. Summary of the invention

Now there has been invented an improved telecommunication system, by which the drawbacks of the prior systems are alleviated. Various aspects of the invention include methods, a telecommunication system and a gateway element, which are characterized by what is stated in the independent claims. Various embodiments of the invention are disclosed in the dependent claims.

According to a first aspect, a method according to the invention is based on the idea of making a presence state of a client of a community network accessible via a public mobile telephone system, said a community network including a community network server and a plurality of community network clients. The community network is connected to a core network of a public mobile telephone system via a community gateway operating as a gateway between the core network of the public mobile telephone system and the community network. The method comprises: receiving, in a presence user agent unit comprised by the community gateway, presence information of a community network client either from the community network server or from a mobile terminal of said community network client; and storing, by the presence user agent, said presence information as an attribute in vCard format, said vCard representing a user profile of said community network client.

According to an embodiment, said presence information is stored as one of the following attributes in vCard format: an information component in the name field of the vCard of the user, said information component being a character string in the family or first name contact field of the vCard; a parameter value for a preferred type of a telephone number to be used to contact the user; or an additional telephone number of the user.

According to an embodiment, the community network is connected to a core network of a public mobile telephone system via a SIP network; the SIP network comprising the community gateway operating as a gateway between the SIP network and the community network; a roaming gateway operating as a serving mobile switching center MSC towards the core network of the public mobile telephone system for short message transfer; and a SIP server for providing SIP message- based communication between the roaming gateway and the community gateway.

According to an embodiment, the method further comprises: receiving, in the roaming gateway, an SMS message from the mobile terminal of said community network client, the SMS message indicating a change in the presence information of the client; converting the information content of the SMS message into a SIP message; sending the SIP message to the community gateway; storing, by the community gateway, the changed presence information as an attribute in vCard format; and transferring the changed presence information of a community network client to the community network server.

The arrangement according to the invention provides significant advantages. The invention provides the necessary means for updating the presence state of a community network client through a public mobile telephone system. Likewise, the presence state information of community network clients included in a contact list of user are easily and intuitively seen on the mobile terminal of the user. Thus, it is no longer necessary to login the community network to access the presence state information, but the presence state information can updated and retrieved by the mobile terminal of the user. According to an embodiment, this is simply carried out by an SMS message. Further aspects of the invention include a telecommunication system and a gateway element arranged to operate in accordance with the above-described method. These and other aspects of the invention and the embodiments related thereto will become apparent in view of the detailed disclosure of the embodiments further below.

List of drawings

In the following, various embodiments of the invention will be described in more detail with reference to the appended drawings, in which

Fig. 1 shows an overall view of the system according to a first embodiment of the invention;

Fig. 2 shows an overall view of the system according to a second embodiment of the invention;

Fig. 3 shows a signalling chart of a presence state updating method according to the first embodiment of the invention; and

Fig. 4 shows a signalling chart of a presence state updating method according to the second embodiment of the invention.

Description of embodiments The more specific structures, operations and functions of the embodiments of the overall system utilizing the invention is described for the part of the public mobile telephone network with terms, interfaces and protocols known from the GSM and the UMTS and specified by the 3GPP. For the part of the generic IP based multimedia network the operation is described with terms, interfaces and protocols specified by IETF.

In the overall system according to a first embodiment shown in Fig. 1 , a public land mobile network (PLMN) consists of a radio access network (100) and a core network (101 ). In GSM, the core network (101 ) includes in turn core network elements (not shown) such as a mobile services switching center/visitor location register server (MSC/VLR), a home location register (HLR), an equipment identity register (EIR), and service and gateway nodes (SGSN and GGSN) of a packet radio network. The core network (101 ) provides basic telephony and supplementary services as well as data services for mobile stations (10), (1 1 ) and (12), which get access to those services using the services of radio access network (100). A community network (104) includes a community gateway (CGW) (2), an XMPP (Extensible Messaging and Presence Protocol) Server (5) and an XMPP Client (6). The CGW (2) constitutes now the gateway functionalities primarily applied in the following embodiments.

The CGW (2) represents core network's (101 ) VLR (20) towards the core network (101 ) for circuit-switched mobile network services used to make location updates to the core network's (101 ) HLR. It represents also core network's (101 ) serving MSC (ServMSC) (21 ) towards the core network (101 ) for short message transfer in PLMN between SMSC (not shown) and the mobile stations (10), (1 1 ) and (12). The CGW (2) includes an ISUP/SIP GW (25), which communicates with core network (101 ) and PSTN network (102) telecom switches. It maps signaling from various telecom switches, e.g. ISUP signaling, to XMPP messages and controls media GWs (not shown) thus allowing the community network (104) and the core network (101 ) and PSTN (102) to be interconnected both on signaling and media streaming. The CGW (2) is aware of the presence information of the presentity because it includes the entity that manipulates this presence information. That entity is a presence user agent (PUA) (24) towards the XMPP Server (5) and may be, for example, a generic libjingle application acting as an XMPP Client (6) to the XMPP Server (5) services.

The XMPP Server (5) provides the community network (104) services such as presence, chat, voice chat and contact management services. Chatting and voice chatting are preferably provided using instant messaging, which offers real-time communication for short messages and voice and allows easy collaboration between parties, i.e. XMPP Clients (6). In a system according to a second embodiment shown in Fig. 2, the system according to Fig. 1 has been extended with a SIP network, wherein the gateway functionalities described above are implemented. In practical applications, a SIP network-based implementation interconnecting the PLMN (101 ) and the community network (104) may provide advantages e.g. in client location update procedures and further by offering advanced telephony features. Accordingly, the SIP network (103) in Fig. 2 includes a roaming gateway (RGW) (1 ), the community gateway (CGW) (2), the telecommunication network gateway (ISUP/SIP GW) (3) and a SIP Server (4). The community network (104) includes the XMPP Server (5) and the XMPP Client (6), but the community gateway (CGW) (2) is functionally implemented in the SIP network (103). The RGW (1 ) and the CGW (2) constitute now the gateway suite primarily applied in the following embodiments.

Now the RGW (1 ) represents core network's (101 ) VLR (20) towards the core network (101 ) for circuit-switched mobile network services used to make location updates to the core network's (101 ) HLR, as well as the core network's (101 ) serving MSC (ServMSC) (21 ) towards the core network (101 ) for short message transfer in PLMN between SMSC (not shown) and the mobile stations (10), (11 ) and (12). The RGW (1 ) includes also a SIP user agent (SIP UA) (22) functionality towards the SIP Server (4) in order to act as a client to the SIP Server (4) on the behalf of the MS (10), (11 ) and (12) and the MS's (10), (1 1 ) and (12) users, one SIP user agent instance for each mobile station. The SIP UA (22) includes also functionality to route the SIP registration and SIP session dialog to and from the SIP Server (4) as well as the downstream SIP session dialog creation request to the right ISUP/SIP GW (3) and further to the right destination core network (101 ) based on the location of the target mobile station (10), (11 ) or (12).

The CGW (2) includes a SIP UA functionality (23) towards the SIP Server (4) in order to act as a client to the SIP Server (4) and as a presence agent. The CGW (2) further includes the presence user agent (PUA) (24) for manipulating the presence information of the presentity towards the XMPP Server (5) and for receiving the presence information from other presentites in the community network (104) through the XMPP Server (5).

The ISUP/SIP GW (3), now depicted as an element separate to the RGW and the CGW, communicates with core network (101 ) and PSTN network (102) telecom switches. It maps signaling from various telecom switches, e.g. ISUP signaling, to SIP messages and controls media GWs (not shown) thus allowing the SIP network (103) and the core network (101 ) and PSTN (102) to be interconnected both on signaling and media streaming.

The SIP Server (4) provides services for users, i.e. SIP UAs, of the SIP network (103). The SIP Server (4) is responsible for e.g. more advanced telephony features such as CLIP and CLIR, call forward on busy/no answer/unconditional, call hold/waiting, denied origination/- termination, find me/follow me, three-way calling, conferencing etc. The SIP Server (4) may also include a SIP registrar to keep track of the SIP UAs registered into the SIP network (103).

The XMPP Server (5) again provides the community network (104) services, but it should be noted that also the SIP Server (4) may provide presence, chat, voice chat and contact management services.

According to the first and second embodiments, the presence service in the community network (104) is a service which accepts, stores and distributes presence information. The XMPP Client (6) provides its user's presence state via a network connection to the XMPP Server

(5), which presence state is stored in what constitutes said user's personal availability record (called a presentity) and can be made available for distribution to other users (called watchers) to convey his/her availability for communication. The XMPP Client (6) may publish a presence state to indicate its current communication status.

The most common use of the presence today is to display an indicator icon on instant messaging clients, typically from a choice of graphic symbol with an easy-to-convey meaning, and a list of corresponding text descriptions of each of the states. Common states on the user's availability are 'free', 'busy', 'away', 'do not disturb', 'out to lunch'. Such states exist in many variations across different modern instant messaging clients. Current standards support a rich choice of additional presence attributes that can be used for presence information, such as user mood, location, or free text status.

The analogy with free/busy tone on PSTN is inexact, as the 'on-hook' telephone status really shows the availability of network connectivity for reaching the called number, not really with the availability of the device or its user. But when we compare the scenario of only one line and can indicate availability and unavailability status (free/busy tone), the benefit for the calling party is very similar: They can decide if they want to start commu nication i n a d ifferent way (try usi ng another communication method or postpone the call). Presence goes insofar further as it allows to know if the state is free or busy even before trying to begin a conversation.

Instant messaging allows instantaneous communication between a number of parties simultaneously, by transmitting information quickly and efficiently, featuring immediate receipt of acknowledgment or reply. In certain cases instant messaging involves additional features, which make it even more popular, i.e. to see the other party, e.g. by using web-cams, or to talk directly for free over the internet.

Contact management services in the following examples are based on the services provided by the community network (104) to the XMPP Clients (6). Those services may be provided by any suitable voice chat system. As is generally known, Rocket Messenger and AOL were among the first to offer voice chat facilities. Later Yahoo! Messenger became the most dominant voice chat service as it provided unique features. These included individual voice chat with another person, as well as conference call type voice chat facilities categorized in Yahoo! Rooms. Other well-known voice chat systems and services are Skype, YahoolVoice and Google Talk.

However, for the sake of illustration, the contact management services in the following examples are described as provided by Google Talk and Gmail. Google Talk is a Windows application for Voice over IP and instant messaging, offered by Google. Presence events and instant messaging between the Google Talk servers and its clients uses an open protocol, XMPP, allowing users of other XMPP clients to communicate with Google Talk users. VoIP in Google Talk is based around the Jingle protocol. However, the technology used within the Google server network is not publicly known. In order to be able to use Google Talk a Google (i.e. Gmail) account is needed for the service. When signing into Google Talk (and Gmail at the same time), user's Gmail contacts are preloaded into the Google Talk client. To add a Google Talk user to the contacts list, acceptance to a separate invitation is required from that Google Talk user. Google Talk contacts need to have mobile numbers (i.e. MSISDNs) defined in the contact information. In practice, adding of a mobile number to a contact needs to be done in the Gmail service, since it is impossible to give telephone numbers to the contacts in the Google Talk client. The Gmail can be launched directly from the Google Talk client, which is convenient also for the user because both Google Talk and Gmail share the same contacts and sign in to the Gmail account takes place simultaneously with the sign in to the Google Talk. When the user makes modifications to his/her Google Talk/Gmail contacts list, those changes will be retrieved from Google Talk/Gmail by the CGW (2). The used Google Talk server is in this example is the XMPP Server (5).

The CGW (2) retrieves and stores the Google Talk/Gmail contacts preferably in vCard format because ordinary mobile handsets' contacts applications typically support for importing and exporting contact data in vCard format. vCard defines a format for an electronic business card, which format is suitable as a personal data interchange format between applications or systems. vCard defined electronic business card forms now the profile for directory information for a white-pages person object. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g. formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). A user can set his/her availability status or customize a message that appears on the contacts list indicating his/her presence status. Presence status in turn conveys ability and willingness of a user to communicate with his/her contacts. However, vCard profile attributes do not include any attribute that would describe presence status or state of the particular object (i.e. the user) associated with the vCard.

Thus, according to the first and second embodiments the presence state of the user is presented as a 'component' of the name of the user the vCard represents, and/or either in the telephone number's preferred type parameter value of the user the vCard represents or as an additional telephone number of the user, or in both ways. Said 'component' is preferably a string in the family or first name contact field of the vCard and shows now the presence state of the user.

According to the first and second embodiments, the string component of the name can be used also to inform the contacts of the user of something which is relevant e.g. for the businesses of the user or service provider, such as advertisements. In that particular case, the service provider may add its name as a part of the users' default presence states, or the service provider may send advertisements to those contacts of the users who are not yet CMS customers of the service provider. Advertisements may be sent to those contacts' Gmail inboxes as emails or in the similar manner as above as a part of the users' default presence states. Still one option to inform users is to use flash-SMS, which is a class 0 text message which will appear on the screen immediately upon arrival, without the need to press any buttons on the phone.

In the following, the operation of the gateway solution according to the embodiments is described more in detail by referring to the signaling charts of Figs. 3 and 4. The description of the operation is based on the terms and functions according to the 3GPP and IETF specifications.

According to the first embodiment, during the start-up, the VLR in the CGW makes the location updates (300) to the core network HLR for the telephone numbers, i.e. virtual mobile subscriber numbers, to be allocated to the community network contacts of the users of the core network. The VLR in the CGW makes the location updates for these virtual mobile subscriber numbers 'roleplaying' location updating procedure of a mobile station of the core network, however without authentication and identification, because there are no SI M cards allocated for the virtual mobile service numbers and because a single virtual mobile subscriber number is not dedicated to a single user, i.e. one and the same virtual mobile subscriber number can be allocated to different contacts of different users. Location updates are done by the VLR in the CGW for all the virtual mobile subscriber numbers in the CGW database.

In the case, where a virtual mobile subscriber number is not a 'non- SIM' one but is, for example, a PSTN number, the VLR in the CGW shall not perform location update for that particular subscriber number.

During the start-up, or whenever a user add a new contact to his/her community network contacts, or whenever the presence state of a contact of the user has changed, the PUA in the CGW retrieves (302) the community network contacts of the user with their presence states from the XMPP Server or updates (302) the user's own presence state to the XMPP Server. Presence state of the user to be updated by the PUA in the CGW is the default presence state of the user in his/her service profile. The PUA in the CGW creates (304) a new vCard for every new contact and updates the new presence states to the existing vCards, for example, as follows:

VCARD:BEGIN

VERSIONS.1

N:Lassila(Available on Google Talk);Ari;Ari

TEL;MOBILE: EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com END:VCARD VCARD:BEGIN VERSIONS.1 N:Oukka(away);Heikki;Heikki TEL;MOBILE: 045 444 5555

EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi END:VCARD After that the PUA in the CGW informs (306) the VLR in the CGW of this. Upon receipt of the indication, the VLR in the CGW shall allocate (308) the virtual mobile subscriber numbers for the new contacts of the user in concern and store them into the TEL contact field of the VCards, for example:

VCARD:BEGIN

VERSIONS.1 N:Lassila(available);Ari;Ari

TEL;MOBILE:045 333 4444

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com

END:VCARD

VCARD:BEGIN VERSIONS.1

N:Oukka(away);Heikki;Heikki

TEL;MOBILE:045 444 5555

EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi

END:VCARD

Allocated virtual mobile subscriber numbers are re-used so that e.g. only 1 ,000 telephone numbers are needed for e.g. 1 million users community. Each contact of a user must have a separate virtual mobile subscriber number, however, different contacts of different users may have the same virtual mobile subscriber numbers.

After this, the VLR in the CGW shall inform (310) the PUA in the CGW of the modified vCards. The PUA in the CGW needs the virtual mobile subscriber numbers in order to be able to route the calls and messages to the right contacts in the community network, and therefore the PUA stores (312) the updated information in the modified vCards. Incoming calls and messages to the same virtual mobile subscriber number are separated by the PUA in the CGW based on the calling/sending party, i.e. depending on the calling/sending party an incoming call/text message to the same virtual mobile subscriber number is routed to the different XMPP Client in the community network. Virtual mobile subscriber numbers may be normal E.164 numbers and may be stored into the mobile stations MS contacts databases preferably without country codes. Thus, unexpected expensive international mobile calls and text messages to community network contacts can advantageously be avoided, when roaming abroad.

As stated already, to add a Google Talk user to the contacts list, acceptance to a separate invitation is required from that Google Talk user. In the case, where that user is using his/her mobile station MS and not signed in to the community network from an XMPP client, the separate invitation is sent preferably as a text message to the mobile station MS. First the XMPP Server sends (314) the acceptance request to the PUA in the CGW, which informs (316) the ServMSC in the CGW of that. After that the ServMSC in the CGW shall send a text message (318) to the mobile station MS as the acceptance request. When the ServMSC in the CGW receives a text message (320) from the mobile station MS indicating e.g. acceptance from the user, it informs (322) the PUA in the CGW of that. The PUA in the CGW shall then send the acceptance (324) to the XMPP Server.

The presence state of a Google Talk user can be changed by the user from his/her mobile handset by sending a text message to the community network (104). When the text message is received by the ServMSC (21 ) in the CGW (2), it informs the PUA (24) in the CGW (2) of the presence state change. The PUA (24) in the CGW (2) shall then send the text string received in the text message to the XMPP Server (5) as a new presence state of the user in the community network (104).

According to the second embodiment, the same basic messages and actions are performed as in the first embodiment, but routing the communication via the SIP network creates some further steps to be carried out. Thus, during the start-up, the VLR in the RGW makes the location updates (400, 402) to the core network HLR for the telephone numbers, i.e. virtual mobile subscriber numbers, to be allocated to the community network contacts of the users of the core network and also to the SIP network. Location updates are done by the VLR in the RGW for all the virtual mobile subscriber numbers in the RGW database. In the case, where a virtual mobile subscriber number is not a 'non- SIM' one but is, for example, a PSTN number, the VLR in the RGW shall not perform location update for that particular subscriber number. The VLR in the RGW performs also the SIP UA registration (404) to the SIP Server on the behalf of the mobile stations MS using the RGWs own fully-qualified domain name (FQDN) as the contact address for the public identity to be registered to the SIP Server. The public identity to be registered in this case is the actual MSISDN of the user. This registration is done for all the actual MSISDNs in the RGW. The virtual mobile subscriber numbers are configured permanently to point to the CGW, they are not registered to the SIP Server at all.

During the start-up, or whenever a user add a new contact to his/her community network contacts, or whenever the presence state of a contact of the user has changed, the PUA in the CGW retrieves (406) the community network contacts of the user with their presence states from the XMPP Server or updates (406) the user's own presence state to the XMPP Server. Presence state of the user to be updated by the PUA in the CGW is the default presence state of the user in his/her service profile. The PUA in the CGW informs (408) the SIP UA in the

CGW of the new contacts and changed presence states, and the SIP

UA creates (410) a new vCard for every new contact and updates the new presence states to the existing vCards, for example, as described above:

VCARD:BEGIN

VERSIONS.1

N:Lassila(Available on Google Talk);Ari;Ari TEL;MOBILE:

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com

END:VCARD

VCARD:BEGIN

VERSIONS.1 N:Oukka(away);Heikki;Heikki

TEL;MOBILE: 045 444 5555

EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi END:VCARD

After that the SIP UA in the CGW informs (412) the SIP UA in the RGW of this, which forwards (414) the indication to the VLR in the RGW. Upon receipt of the indication, the VLR in the RGW shall allocate (416) the virtual mobile subscriber numbers for the new contacts of the user in concern and store them into the TEL contact field of the VCards, for example as described above:

VCARD:BEGIN

VERSIONS.1

N:Lassila(available);Ari;Ari

TEL;MOBILE:045 333 4444

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com ENDΛ/CARD

VCARD:BEGIN

VERSIONS.1

N:Oukka(away);Heikki;Heikki

TEL;MOBILE:045 444 5555 EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi

END:VCARD

After this, the VLR in the RGW shall inform (418) the SIP UA in the RGW of the modified vCards, and the SIP UA in turn sends (420) the vCards to the SIP UA in the CGW. The SIP UA in the CGW needs the virtual mobile subscriber numbers in order to be able to route the calls and messages to the right contacts in the community network, and therefore the SIP UA stores (422) the updated information in the modified vCards. Incoming calls and messages to the same virtual mobile subscriber number are separated by the SIP UA in the CGW based on the calling/sending party, i.e. depending on the calling/sending party an incoming call/text message to the same virtual mobile subscriber number is routed to the different XMPP Client in the community network.

Then a separate invitation to add a Google Talk user to the contacts list is sent preferably as a text message to the mobile station MS. First the XMPP Server sends (424) the acceptance request to the PUA in the CGW, which informs (426) the SIP UA in the CGW of that. The SIP UA in the CGW shall send the acceptance request (428) to the SIP UA in the RGW, which in turn informs (430) the ServMSC in the RGW of that. After that the ServMSC in the RGW shall send a text message (432) to the mobile station MS as the acceptance request. When the ServMSC in the RGW receives a text message (434) from the mobile station MS indicating e.g. acceptance from the user, it informs (436) the SIP UA in the RGW of that. The SIP UA in the RGW in turn sends a SIP MESSAGE (438) consisting of the received text message to the SIP UA in the CGW. Upon receipt of the SIP MESSAGE, the SIP UA in the CGW shall inform (440) the PUA in the CGW of the acceptance. The PUA in the CGW shall then send the acceptance (442) to the XMPP Server.

The presence state of a Google Talk user can be changed by the user from his/her mobile handset by sending a text message to the community network (104). When the text message is received by the ServMSC (21 ) in the RGW (1 ), it informs the SIP UA (22) in the RGW (1 ) of that. The SIP UA (22) in the RGW (1 ) shall then send a SIP MESSAGE consisting of the received text message to the SIP UA (23) in the CGW (2). Upon receipt of the SIP MESSAGE, the SIP UA (23) in the CGW (2) shall inform the PUA (24) in the CGW (2) of the presence state change. The PUA (24) in the CGW (2) shall then send the text string received in the text message to the XMPP Server (5) as a new presence state of the user in the community network (104).

A skilled man appreciates that any of the embodiments described above may be implemented as a combination with one or more of the other embodiments, unless there is explicitly or implicitly stated that certain embodiments are only alternatives to each other.

It is obvious that the present invention is not limited solely to the above- presented embodiments, but it can be modified within the scope of the appended claims.

Claims

Claims:

1. A method for making a presence state of a client (6) of a community network (104) accessible via a public mobile telephone system, said a community network (104) including a community network server (5) and a plurality of community network clients (6), characterized in that the community network (104) is connected to a core network (101 ) of a public mobile telephone system via a community gateway (2) operating as a gateway between the core network (101 ) of the public mobile telephone system and the community network (104); the method comprising

- receiving, in a presence user agent unit (24) comprised by the community gateway (2), presence information of a community network client (6) either from the community network server (5) or from a mobile terminal of said community network client (6); and

- storing, by the presence user agent (24), said presence information as an attribute in vCard format, said vCard representing a user profile of said community network client

(6).

2. The method according to claim 1 , characterized by further comprising: storing said presence information as one of the following attributes in vCard format:

- an information component in the name field of the vCard of the user, said information component being a character string in the family or first name contact field of the vCard; - a parameter value for a preferred type of a telephone number to be used to contact the user; or

- an additional telephone number of the user.

3. The method according to claim 1 or 2, characterized in that the community network (104) is connected to a core network (101 ) of a public mobile telephone system via a SIP network

(103); the SIP network (103) comprising the community gateway (2) operating as a gateway between the SIP network (103) and the community network (104); a roaming gateway (1 ) operating as a serving mobile switching center MSC towards the core network (101 ) of the public mobile telephone system for short message transfer;; and a

SIP server (4) for providing SIP message-based communication between the roaming gateway (1 ) and the community gateway (2).

4. The method according to claim 3, characterized by further comprising: receiving, in the roaming gateway (1 ), an SMS message from the mobile terminal of said community network client (6), the SMS message indicating a change in the presence information of the client; converting the information content of the SMS message into a SIP message; sending the SIP message to the community gateway (2); storing, by the community gateway (2), the changed presence information as an attribute in vCard format; and transferring the changed presence information of a community network client (6) to the community network server (5).

5. A telecommunication system, comprising: a community network (104) including a community network server (5) and a plurality of community network clients (6); characterized in that the community network (104) is connected to a core network (101 ) of a public mobile telephone system via a community gateway (2) operating as a gateway between the core network (101 ) of the public mobile telephone system and the community network (104); the community gateway (2) further comprising - a presence user agent unit (24) arranged to transfer presence information of a community network client (6) to and from the community network server (5); and arranged to store said presence information as an attribute in vCard format, said vCard representing a user profile of said community network client (6).

6. The telecommunication system according to claim 5, characterized in that the presence user agent (24) is arranged to store said presence information as one of the following attributes in vCard format:

- an information component in the name field of the vCard of the user; - a parameter value for a preferred type of a telephone number to be used to contact the user; or

- an additional telephone number of the user.

7. The telecommunication system according to claim 6, characterized in that said information component is a character string in the family or first name contact field of the vCard.

8. The telecommunication system according to any of the claims 5 - 7, characterized in that the community network (1 04) is connected to a core network (101 ) of a public mobile telephone system via a SIP network (103); the SIP network (103) comprising the community gateway (2) operating as a gateway between the SIP network (103) and the community network (104); a roaming gateway (1 ) operating as a serving mobile switching center MSC towards the core network (101 ) of the public mobile telephone system for short message transfer; and a SIP server (4) for providing SIP message-based communication between the roaming gateway (1 ) and the community gateway (2).

9. The telecommunication system according to claim 8, characterized in that the roaming gateway (1 ) is arranged, upon receiving an

SMS message from a mobile terminal of said community network client

(6), the SMS message indicating a change in the presence information of the client, to convert the information content of the SMS message into a SIP message and to send the SIP message to the community gateway (2); and the community gateway (2) is arranged to store the changed presence information as an attribute in vCard format and to transfer the changed presence information of a community network client (6) to the community network server (5).

10. A gateway element arranged to interconnect a community network (104) and a core network (101 ) of a public mobile telephone system, characterized in that the gateway element is a community gateway (2) comprising:

- a presence user agent unit (24) arranged to transfer presence information of a community network client (6) to and from a community network server (5); and arranged to store said presence information as an attribute in vCard format, said vCard representing a user profile of said community network client (6).

11. The gateway element according to claim 10, characterized in that the presence user agent (24) is arranged to store said presence information as one of the following attributes in vCard format:

- an information component in the name field of the vCard of the user;

- a parameter value for a preferred type of a telephone number to be used to contact the user; or

- an additional telephone number of the user.

12. The gateway element according to claim 11 , characterized in that said information component is a character string in the family or first name contact field of the vCard.