WO2008065245A1

WO2008065245A1 - Group communication

Info

Publication number: WO2008065245A1
Application number: PCT/FI2007/050625
Authority: WO
Inventors: Miikka POIKSELKÄ; Eva-Maria LEPPÄNEN; Arto Leppisaari; Tapio Paavonen
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 2006-11-28
Filing date: 2007-11-21
Publication date: 2008-06-05
Anticipated expiration: 2009-05-28
Also published as: EP2087670A4; KR20090084948A; FI20065756A0; CA2665725A1; EP2087670A1; CN101542989A; CA2665725C; KR101120656B1

Abstract

In order to ensure a privacy of a private message within a group communication to which participants supporting private messages within a group communication and participants not supporting private messages may join, it is checked, in response to detecting a private message within a group communication, whether or not a next node supports private messages within a group communication, and to use a result of the check to decide how to handle the message.

Description

GROUP COMMUNICATION

FIELD OF THE INVENTION

The present invention relates to session-based group communication.

BACKGROUND ART

The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but provided by the invention. Some such contributions of the invention may be spe- cifically pointed out below, whereas other such contributions of the invention wifl be apparent from their context.

One special feature offered in communication systems is group communication. The term "group", as used herein, refers to any logical group of two or more users intended to participate in the same group communication. Examples of group communication include conferencing, multimedia conferencing, and chatting. For a chat, participants may set up a chat room, which is a virtual place to exchange instant messages and corresponds to a session- based instant messaging conference. Chat rooms may be public, i.e. open to all, or they may be private, i.e. the participation is restricted to given users. The basic principle of a chat is that a participant in the chat may send a message (an instant message) to all participants who have joined the chat room so that they receive the message substantially simultaneously and each participant may respond to the message.

Some of the chat applications support sending private messages within a chat group session, a private message being a message sent for a restricted number of participants instead of all participants, but some of the session-based chat applications do not support private messages within a chat group session. Thus, a chat room session may have participants whose application supports private messages within the session and participants whose application does not support private messages within the session and a server hosting the chat room may or may not be based on an application supporting private messages within a chat room session. One of the problems associated with the above arrangement is that if a participant whose application supports private messages tries to send a private message, the privacy of the message cannot be ensured. SUMMARY

An object of the present invention is thus to provide a method and an apparatus for implementing the method so as to overcome the above problem. The object of the invention is achieved by a method, apparatuses, a mod- ule, a system and a computer program product which are characterized by what is stated in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

The invention is based on utilizing in delivery of a private message capability information on a next node to check whether or not the next node supports private messages within a group communication, and to decide how to continue on the basis of whether or not the next node supports private messages within a group communication session.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, embodiments will be described in greater detail with reference to the accompanying drawings, in which

Figure 1 illustrates an example of a general architecture of a communication system providing a group communication service;

Figure 2 is a simplified block diagram of an apparatus according to an embodiment of the invention; Figures 3, 4, 5 and 6 are flow charts illustrating functionalities of apparatuses according to embodiments of the invention; and

Figure 7 is a signalling diagram illustrating signalling according to an embodiment of the invention.

DETAILED DESCRIPTION OF SOME EMBODIMENTS The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiments), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other em- bodiments.

The present invention is applicable to any user terminal, server, corresponding components, and/or to any communication system or any combination of different communication systems that support session-based group communication. 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 servers, especially in wireless communication, develop rapidly. Such development may require extra changes to an embodiment. Therefore, all terms and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.

In the following, the present invention will be described using, as an example of the group communication, a chat using instant messages and, as an example of a system architecture whereto the present invention may be applied, an architecture based on SIP (session initiation protocol) for signaling and session establishment, i.e. providing a tool to build a multimedia architecture, and MSRP (message session relay protocol) for group communication without restricting the invention to such a group communication and to such an architecture, however. SIP and MSRP are defined by Internet Engineering Task Force (IETF). SIP is an application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. MSRP is an application layer protocol for carrying a series of instant messages between two points, as one-to-one or one-to-many communication, after a session has been established. In other words, SIP and MSRP are not vertically integrated into a communication system. IETF specifications and Internet Drafts can be found at http://www.ietf.org.

A general architecture of a communication system providing session-based group communication is illustrated in Figure 1. Figure 1 is a simplified system architecture only showing some elements and functional entities, all being logical units whose implementation may differ from what is shown, The connections shown in Figure 1 are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the systems also comprise other functions and structures. It should be appreciated that the functions, structures, elements and the protocols used in or for group communication, are irrelevant to the actual invention. Therefore, they need not to be discussed in more detail here.

The communication system 100 in Figure 1 comprises user terminals 300, 300', 300" each connectable via an operator network to a server 200, 200', 200" of its own network operator, each operator network including preferably an access network and a core network and possibly being con- nected to other operator networks via a routing network (not shown in Figure 1), such as the Internet.

A user terminal 300, 300', 300" is a piece of equipment or a device that associates, or is arranged to associate, the user terminal and its user with a subscription and allows a user to interact with a communications system. The user terminal presents information to the user and allows the user to input information. In other words, the user terminal may be any terminal capable of receiving information from and/or transmitting information to the network, con- nectable to the network wirelessly or via a fixed connection. Examples of the user terminal include a personal computer, a game console, a laptop (a notebook), a personal digital assistant, a mobile station (mobile phone), and a line telephone.

A server 200, 200', 200" may be a server providing access to a chat room server or the chat room server or acting as both servers. A server provid- ing access to a chat room server is a server accessible via an operator network of users using subscriptions of the operator. The chat room server provides chat room services for one or more sessions, such as delivering instant messages to other participants of the chat room, maintaining a SIP signaling relationship with each participant in the chat, being responsible for ensuring that each participant receives media that make up the chat, and implementing chat policies. For example, an operator Cs server C 200' may be the chat room server for user terminals 300, 300' and 300" and provide access to chat room services to a user terminal 300' using subscription of the operator C. A chat room server covers here also a focus, a server hosting the session, and/or a controlling server. A server providing access to a chat room may be called a participating server.

The server 200, 200', 200" providing access to a chat room and/or being a chat room server provides group communication service according to an application. The server may also comprise several applications but for a chat, or a session, it provides the group communication service to a subscriber according to one application, although another application may be used for another chat of the same subscriber or for the same chat but to another subscriber. The application providing the group communication service may be any application providing session-based group communication. Examples of applications based on SIP and providing at least instant messaging service to groups include PoC (push-to-talk over cellular, defined by Open Mobile AIIi- ance, OMA), or IETF SIMPLE (i.e. SIP for instant messaging and presence leveraging extensions defined by IETF) or an OMA instant messaging service (i.e. instant messaging enabler based on SIP/SIMPLE protocols and defined by OMA). OMA specifications can be found at http://www.openmobilealliance.org. At the time of the invention, the OMA instant messaging service supports private messages within a group communication but PoC and IETF SIMPLE do not support it. Thus, the server 200, 200', 200" may be, for example, a PoC server or an OMA instant messaging server, or an IETF SIMPLE instant messaging server. It should be appreciated that a chat room in a server may provide access to chat room services to any number of different operators, or more precisely, to users using their subscriptions. In other words, the operator networks and the servers 200, 200', 200" represent here one or more corresponding operator networks and intermediate servers. It should also be appreciated that access to different chat rooms may be provided by different chat servers of different operators.

Figure 2 is a block diagram of an apparatus according to an embodiment of the invention and representing one or more servers, or server components, such as modules, providing group communication service. Al- though the apparatus has been depicted as one entity, different modules and memory may be implemented in one or more physical or logical entities. The apparatus 200 is configured to detect a private message within a group communication message, to check whether or not a next node supports private messages within a group communication using capability information on the next node, the capability information being received when participants are invited, for example, to join the group communication, and to determine how to handle the private message on the basis of the check result. For this purpose, the apparatus comprises data storage 20 for storing capability information on the next node preferably session-specifically and at least temporarily, a re- ceiver unit 21 for receiving different inputs, information and messages, a session information maintenance unit 22 for taking care of storing the capability information on the next node, a detecting unit 23 for detecting a private message within a group communication, a privacy provider unit 24 for using the capability information to check whether or not the next node supports private messages within a group communication, for using a result of the check to decide how to handle the message and for handling the message according to the decision, and a sending unit 25 for sending different outputs, information and messages, the sending unit being responsive at least to the privacy provider unit 24.

The apparatus 200 may be any node or a host which is able to pro- vide group communication services or acts as an intermediate node in group communication. The functionalities of the units, especially the privacy provider unit 24, are described in more detail below with Figures 3 to 7. It should be appreciated that the apparatus may comprise other units used in or for group communication or one-to-one communication. However, they are irrelevant to the actual invention and, therefore, they need not to be discussed in more detail here.

A user terminal may also comprise a corresponding structure or configuration for performing corresponding functionalities when a private message is sent within a group communication. Apparatuses, such as servers, or corresponding server components, user terminals and/or other corresponding devices or apparatuses implementing the functionality of a corresponding apparatus described with an embodiment comprise not only prior art means, but also means for checking, in response to a private message sent in a group communication, whether or not a next node supports private messages within a group communication, means for deciding how to handle the private message on the basis of the check result, and means for handling the private message according to the decision. More precisely, they comprise means for implementing functionality of a corresponding apparatus described with an embodiment and they may comprise separate means for each separate function, or means may be configured to perform two or more functions. Present apparatuses comprise processors and memory that can be utilized in an embodiment. For example, the detecting unit 23, or the privacy provider unit 24, or their combination, may be a software application, or a module, or a unit configured as an arithmetic operation, or as a program, executed by an operation processor. All modifications and configurations required for implementing functionality of an embodiment may be performed as routines, which may be implemented as added or updated software routines, application circuits (ASIC) and/or programmable circuits. Software routines, also called program products, including applets and macros, can be stored in any apparatus-readable data storage medium and they include program instructions to perform particular tasks. Software routines may be downloaded into an apparatus. The apparatus, such as a server, or a corresponding server component, or a module, or a user terminal may be configured as a computer or a microprocessor, such as single-chip computer element, including at least a memory for providing storage area used for arithme- tic operation and an operation processor for executing the arithmetic operation. An example of the operation processor includes a central processing unit. The memory may be removable memory detachably connected to the apparatus.

An apparatus, i.e. a node, in a delivery chain of a message providing group communication service may be configured to implement an embodi- ment of the invention regardless of whether or not the apparatus is providing access to a chat room or is a chat room server or a user terminal. Preferably apparatuses in a delivery chain are configured to implement the same embodiment but that is, however, not necessary. The apparatuses in a delivery chain may be configured to implement different embodiments, and/or one or more of the apparatuses in the delivery chain may be an apparatus which is not configured to implement an embodiment of the invention. It is also possible that only the chat room server node is configured to implement an embodiment of the invention. A next node in a delivery chain covers here a node to whose address the message is forwarded, thus covering a user terminal and a server, the intermediate nodes through which the message may pass are not nodes in a delivery chain. Forwarding covers here also generating a copy of the original message, and sending the copy, wherein the copy and the original message may have different "next node addresses".

In the following, different embodiments are illustrated using mes- sages as a way to communicate with the other participants of the group communication. However, a delivery of a message is not disclosed in detail for the sake of clarity and since the delivery details are not relevant to the present invention.

Figures 3 to 6 show flowcharts of different embodiments of an appa- ratus, such as a server or server component. In the embodiments illustrated it is assumed, for the sake of clarity, that a group communication session has been established, a sender is allowed to send private messages within a group communication, and that the apparatus has capability information on the next node, the capability information relating at least to this particular session. Fur- ther, it is assumed that the group communication is based on instant messages without restricting the invention to such a solution. Referring to Figure 3, the apparatus receives, in step 301 , an instant message sent within a session formed for group communication. In response to receiving the instant message, the apparatus checks, whether or not the message is a private message. For example, if the message contains, instead of the group identity or a session identity, one or more recipient addresses or identities, the message may be interpreted as a private message. If the instant message is not a private message, the apparatus forwards in step 303 the instant message to the next node.

If the instant message is a private message (step 302), the appara- tus checks, in step 304, whether or not the next node supports private messages within the group communication in question using the capability information. In other words, it is checked, whether or not the next node supports privacy. If the next node supports privacy, the apparatus forwards in step 303 the instant message to the next node. If the next node does not support privacy (step 304), the apparatus rejects, in step 305, the instant message and informs, in step 306, the sender of the message by sending, for example, an error message, preferably with an explanation, such as "private messages not allowed to the intended recipient" to the sender of the instant message, or actually to the previous node, where- from the message was received.

In other words, in the embodiment of Figure 3, the apparatus handles a detected private message, on the basis of the check result using next node's capability information, either by forwarding it or by rejecting it and informing the sender on the rejection. An advantage of the embodiment is that it ensures that a message is not forwarded to a server not supporting private messages within a group communication thereby ensuring that if such a server provides the chat room, it will not receive the private message and therefore will not expose the private message to all participants. A further advantage of the embodiment is that if the recipient's user terminal is the first node in the delivery chain that does not support private messages within a group communication, the message is not sent to the user terminal thereby ensuring that a private message will never be interpreted as a group message. If the private message is received as a group message, the recipient may not understand sensitivity of the message and may reply back, the reply being sent to other participants of the group commu- nication as well, thereby destroying the privacy. This is avoided by the embodiment.

The embodiment of Figure 4 utilizes a "mandatory-to-recognize indicator" with which a sender of a message notifies a recipient that it has to un- derstand the indicator in order to properly understand the message. Common presence and instant messaging (CPIM), supported by the above-mentioned examples of group communication, defines a require header to be a "manda- tory-to-recognize indicator" indicating a feature that has to be understood by the receiver, and the embodiment of Figure 4 uses this require header. How- ever, corresponding embodiments may be implemented with other types of "mandatory-to-recognize indicators".

Referring to Figure 4, steps 401 to 404 correspond to steps 301 to 304 described above with Figure 3 and are not repeated here.

In the embodiment of Figure 4, if the next node does not support privacy (step 404), the apparatus checks, in step 405, whether or not the message contains a require header indicating support for private messages within a group communication as a mandatory-to-recognize feature. For example, some user terminals may be configured to add such a require header to a private message within a group communication, or the header has been added by another previous node. The require header indicating the support may be as simple as "Require:Private". If the message does not contain such a require header, the apparatus adds, in step 406, to the message such a require header, and forwards, in step 407, the message with the require header to the next node. In other words, the require header is set to indicate that support for private messages within a group communication is required.

If the message already contained a require header requiring support for private messages within a group communication as a mandatory-to- recognize feature (step 405), the apparatus forwards, in step 407, the message. In other words, in the embodiment of Figure 4, the apparatus handles a detected private message, on the basis of the check result using next node's capability information, either by forwarding it or by ensuring that it contains a require header indicating support for private messages within a group communication as a mandatory-to-recognize feature, or a corresponding indi- cator. An advantage of the embodiment of Figure 4 is that a private message is delivered only to recipients supporting private messages within a group communication but not to recipients not supporting private messages within a group communication thereby ensuring privacy. This is due to a fact that a node, either a server or a user terminal, not supporting private messages within a group communication, rejects a message requiring support for private messages within a group communication.

In a further embodiment, the apparatus does not check, whether or not the message contains a require header indicating support for private mes- sages within a group communication as a mandatory-to-recognize feature, but simply adds such a require header to the message. In other words, step 405 is skipped and after step 404 either step 403 or step 406 is performed.

Apparatuses implementing embodiments illustrated in Figures 5 and 6 are configured to maintain capability information on a chat room server. The capability information on a chat room server may be obtained during session establishment. For example, an "isfocus" parameter delivered in messages during session establishment, may be used to obtain the capability information on the chat room server.

The embodiment of Figure 5 utilizes a fact that each message com- prises a subject header which contains a sender's description of a topic or content of the message.

Referring to Figure 5, steps 501 to 504 correspond to steps 301 to 304 described above with Figure 3 and are not repeated here.

In the embodiment of Figure 5, if the next node does not support privacy (step 504), the apparatus checks, in step 505, whether or not the chat room server supports the privacy, i.e. private messages within a group communication. If yes, the apparatus adds, in step 506, a prefix, such as "private" to a subject header of the instant message to indicate that the instant message is a private message sent within a group communication, and then forwards, in step 507, the instant message with the amended subject header to the next node.

If the chat room server does not support the privacy (step 505), the apparatus rejects, in step 508, the instant message and preferably informs, in step 509, the sender of the message by sending, for example, an error mes- sage, preferably with an explanation, such as "private messages not allowed in this chat" to the sender of the instant message, or actually to the previous node, wherefrom the message was received.

In other words, in the embodiment of Figure 5, the apparatus handles a detected private message, on the basis of the check result using next node's capability information, either by forwarding it as received or by performing a further check on the capabilities of the chat room server, and on the basis of the latter check result using chat room server's capability information, either by adding prior to forwarding the message to a subject header of the message an indication of the message being a private message within a group commu- nication or by rejecting the instant message and informing the sender on the rejection.

An advantage of the embodiment of Figure 5 is that the recipient becomes aware of the privacy and sensitivity of the message. A further advantage is that a chat room server receives the private message only if the chat room server supports private messages within a group communication thereby ensuring that the private message is not sent by the chat room server to all participants. A still further advantage is that if the chat room server supports private messages within a group communication, the private message will be delivered to an intended recipient regardless of whether or not the recipient's user terminal supports private messaging within a group communication.

In a further embodiment, the apparatus is configured to check, prior to adding the prefix, whether or not the subject header already contains a prefix indicating a private message, and to add the prefix only if the subject header does not contain such a prefix. Figure 6 illustrates a further embodiment of an apparatus. Referring to Figure 6, steps 601 to 604 correspond to steps 301 to 304 described above with Figure 3 and are not repeated here.

In the embodiment of Figure 6, if the next node does not support privacy (step 604), the apparatus checks, in step 605, whether or not the chat room server supports the privacy, i.e. private messages within a group communication. If yes, the apparatus modifies, in step 606, a message body, i.e. the actual content of the instant message, to indicate that the instant message is a private message sent within a group communication, by adding, for example a prefix, such as "private message from user NN" (NN means the sender of the message) to the beginning of the message body, and then forwards, in step 607, the instant message containing the modified message body to the next node.

If the chat room server does not support the privacy (step 605), the apparatus rejects, in step 608, the instant message and preferably informs, in step 609, the sender of the message by sending, for example, an error message, preferably with an explanation, such as "private messages not allowed in this chat" to the sender of the instant message, or actually to the previous node, wherefrom the message was received.

In other words, in the embodiment of Figure 6, the apparatus han- dies a detected private message, on the basis of the check result using next node's capability information, either by forwarding it as received or by performing a further check on the capabilities of the chat room server, and on the basis of the latter check result using chat room server's capability information, either by modifying prior to forwarding the message, the message body to contain an indication of the message being a private message or by rejecting the instant message and informing the sender on the rejection.

An advantage of the embodiment of Figure 6 is that a chat room server receives the private message only if the chat room server supports private messages within a group communication thereby ensuring that the private message is not sent by the chat room server to all participants. A still further advantage is that if the chat room server supports private messages within a group communication, the private message will be delivered to an intended recipient and the recipient becomes aware of the privacy and sensitivity of the message regardless of whether or not the recipient's user terminal supports private messaging within a group communication.

In a further embodiment, the apparatus is configured to check, prior to modifying a message body, whether or not the message body already contains an indication of a private message, and to modify the message body only if it does not contain such an indication. In a yet further embodiment, the apparatus is configured to, in response to ensuring that a message body contains an indication of a private message, to ensure that a subject header also indicates a private message.

In further embodiments, the apparatus may be configured to ensure that a private message contains in addition to a require header indicating sup- port for private messages within a group communication as a mandatory-to- recognize feature, a subject header indicating private and/or a message body indicating private.

Figure 7 is a signalling flow chart illustrating a signalling example in a system configured according to an embodiment. The example illustrates a situation in which, after a group communication session has been set up, a user of a user terminal UT-A wants to send a private message within the session to a user of a user terminal UT-B. Therefore, and for the sake of clarity, the signalling to other participants of the group communication, for example during the session establishment, is not shown in Figure 7. In the example it is assumed that UT-A comprises a group communication client according to the OMA instant messaging service thereby supporting private messages within the group communication, whereas UT-B comprises a group communication client according to PoC thereby not supporting private messages within the group communication. Further it is as- sumed that a server A and a server C provides group communication services according to the OMA instant messaging service thereby supporting private messages within the group communication, whereas a server B provides group communication services according to PoC thereby not supporting private messages within the group communication. The server A and the server B are servers providing access to a chat room server, the server A to UT-A and the server B to UT-B₁ and that server C is the actual chat room server. It should be noted that below, in the examples of message contents, an instant messaging application is a "user agent" when it sends a request, and a "server" when it sends a response regardless of where the instant messaging application lo- cates.

Referring to Figure 7, the user of UT-A wants to establish a group communication session with a group comprising the user of UT-B. Therefore UT-A sends a message 7-1 to the server A. The message 7-1 may be a "SIP INVITE User-Agent: IM-client/OMA1.0", i.e. a message indicating that a user agent in UT-A is an instant messaging client according to OMA specification 1.O.. In response to receiving the message 7-1 , the server A stores, in point 7- 2, as capability information on UT-A that it supports private messages within group communication, and sends a message 7-3 to the corresponding chat room server, the server C. The message 7-3 may be a "SIP INVITE User- Agent: IM-serv/OMA1.0 ", i.e. a message indicating that a user agent in the server A is an instant messaging server according to OMA specification 1.0. In response to receiving the message 7-3, the server C stores, in point 7-4, as capability information on the server A that it supports private messages within group communication, and sends a message 7-5 to the server B serving UT-B. The message 7-5 may be a "SIP INVITE User-Agent: IM-serv/OMA1.0", i.e. a message indicating that a user agent in the server C is an instant messaging server according to OMA specification 1.0. (Corresponding messages will be sent from the server C towards other group members but they are not shown for the sake of cfarity.) In response to receiving the message 7-5, the server B sends a message 7-6 to UT-B. The message may be a "SIP INVITE User- Agent: PoC-serv/OMA2.0", i.e. a message indicating that a user agent in the server B is a PoC server according to OMA PoC specification 2.0.

In response to receiving the message 7-6, the user of UT-B is informed on the invitation, and in this example the user wants to join the group communication. Therefore UT-B sends a message 7-7 to the server B. The message 7-7 may be a "200 OK Server: PoC-client/OMA2.0", i.e. a message indicating that a server in the UT-B is a PoC client according to OMA PoC specification 2.0. In response to receiving the message 7-7, the server B sends a message 7-8 to the chat room server, the server C. The message 7-8 may be a "200 OK Server: PoC-server/OMA2.0", i.e. a message indicating that a server in the server C is a PoC server according to OMA PoC specification 2.0. In response to receiving the message 7-8, the server C stores, in point 7-9, as capability information on the server B that it does not support private messages within group communication, and sends a message 7-10 to the server A serving UT-A. The message 7-7 may be a "200 OK Server: IM-serv/OMA1.0", i.e. a message indicating that a server in the server C is an instant messaging server according to OMA specification 1.0. In response to receiving the message 7-10, the server A stores, in point 7-11 , as capability information on the server C that it supports private messages within group communication, and sends a message 7-12 to UT-A. The message 7-12 may be a "200 OK Server: IM-serv/OMA1.0", i.e. a message indicating that a server in the server A is an instant messaging server according to OMA specification 1.0.

At some phase of the group communication the user of UT-A wants to send a private message 7-13 to the user of UT-B. The message may be an MSRP message containing instead of a group URI (uniform resource identifier) an URI of UT-B, for example. In response to receiving the message 7-13, the server A detects, in point 7-14 that the message is private, and checks, in point 7-14, whether or not the server C supports private messages within the group communication, the checking result being "yes, it supports" in the example. Therefore the server A forwards the message 7-13. In response to receiving the message 7-13, the server C detects, in point 7-15 that the message is pri- vate, and checks, in point 7-15, whether or not the server B supports private messages within the group communication, the checking result being "no, it does not support" in the example. Therefore the server C rejects the message 7-13 and sends a message 7-16 informing the rejection to the server A. The message 7-16 may be a "403 Forbidden" containing a reason for the rejection, such as "Network node in the path does not support private messages", or "Target recipient does not support private messages within a group communication", or "Private messages within a group communication cannot be delivered to the target recipient". The server A forwards the message 7-16 to the UT-A which may show the rejection and the reason to the user. If the system is implemented so that only chat room servers implement the embodiment, the point 7-14 will be skipped, other points and signalling will remain the same in the example illustrated in Figure 7.

In another embodiment, the server B may be configured to store capability information. For example, the server B may be configured to store, in response to message 7-5, as capability information on the server C that it sup- ports private messages within group communication, and, in response to message 7-7, as capability information on UT-B that it does not support private messages within a group communication.

In an embodiment of the invention, a user terminal may be config- ured to store capability information on the next node. For example, UT-A may be configured to store, in response to message 7-12, that the server A supports private messages within the group communication.

Although in the above the embodiments have been disclosed assuming that a server detects the private message within a group communica- tion, a sending user terminal may be configured to detect a private message within a group communication, and to perform other steps of an embodiment than the receiving step (unless user's instructions, received via the user interface, to send a private message within a group communication are interpreted as receiving a message). The steps/points, signaling messages and related functions described above in Figures 3 to 7 are in no absolute chronological order, and some of the steps/points may be performed simultaneously or in an order differing from the given one. For example, step 504 may be performed after step 505 but before step 506 in Figure 5, or step 604 may be performed after step 605 but before step 606 in Figure 6. Other functions can also be executed be- tween the steps/points or within the steps/points and other signaling messages sent between the illustrated messages. For example, a step corresponding to step 505 in Figure 5 may be added between steps 404 and 405 in Figure 4 so that if the answer to the step corresponding to step 505 is no, steps corresponding to steps 508 and 509 are performed, and if the answer is "yes", the process will continue from step 405. Some of the steps/points or part of the steps/points can also be left out or replaced by a corresponding step/point or part of the step/point. For example, a step in which the sender is informed, may be omitted, or steps 505, 508 and 509 in Figure 5, or steps 605, 608 and 609 in Figure 6 may be left out so that from step 504 it is proceed to step 503 or to 506, or from step 604 to step 603 or to 606. The apparatus/server 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. In addition, the messages may also contain other information. Although in the above it is assumed that the apparatus stores capability information at least on next nodes, in an embodiment the apparatus may be configured to request the capability information from the next node in response to detecting a private message within a group communication. Also capability information on a chat room server may be requested in response to detecting a private message within a group communication.

It will be obvious to a person skilled in the art that, as 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 comprising: detecting a private message within a group communication; checking whether or not a next node to which the message should be forwarded supports private messages within a group communication; using a result of the checking to decide how to handle the message; and handling the message according to the decision.

2. A method as claimed in claim 1 , further comprising: deciding, in response to the next node supporting private messages within a group communication, to forward the message.

3. A method as claimed in claim 1 or 2, further comprising: deciding, in response to the next node not supporting private messages within a group communication, to reject the message.

4. A method as claimed in claim 1 or 2, further comprising: deciding, in response to the next node not supporting private messages within a group communication, to forward the message with an indication of support for private messages within a group communication as a man- datory-to-recognize feature.

5. A method as claimed in claim 4, wherein the indication is a require header.

6. A method as claimed in claim 1 , 2, 4 or 5, further comprising: deciding, in response to the next node not supporting private messages within a group communication, to forward the message with a subject header indicating that the message is a private message within a group communication.

7. A method as claimed in claim 1 , 2, 4, 5 or 6, further comprising: deciding, in response to the next node not supporting private messages within a group communication, to forward the message with a body indi- eating that the message is a private message within a group communication.

8. A method as claimed in claim 4, 5, 6 or 7, the method further comprising, in response to the next node not supporting private messages within a group communication: checking prior forwarding whether or not a node hosting the group communication supports private messages within a group communication, performing the forwarding if the node hosting the group communication supports private messages within a group communication, and rejecting the message if the node hosting the group communication does not support private messages within a group communication.

9. A method as claimed in any of the preceding claims, the method further comprising: obtaining capability information during group communication establishment.

10. A method as claimed in claim 9, the method further comprising: storing the capability information group communication-specifically.

1 1. A computer program product comprising program code means adapted to perform any of steps of any of the preceding claims when the program is run on a computer or on a processor.

12. A module comprising a processor configured to implement a method as claimed in any of claims 1 to 10.

13. An apparatus comprising: detecting means for detecting a private message within a group communication; and privacy provider means, responsive to the detecting means, for us- ing capability information on a next node to check whether or not the next node supports private messages within a group communication, and for using a result of the check to decide how to handle the message, and for handling the message according to the decision.

14. An apparatus as claimed in claim 13, the apparatus further comprising receiving means for receiving messages, wherein the detecting means is configured to be responsive to the receiver means.

15. An apparatus as claimed in claim 14, wherein the receiving means is implemented as a receiver unit configured to perform corresponding functions, the detecting means is implemented as a detecting unit configured to perform corresponding functions, and the privacy provider means is implemented as a privacy provider unit configured to perform corresponding functions.

16. An apparatus as claimed in claim 13, 14 or 15, further compris- ing memory for storing at least capability information on the next node.

17. An apparatus as claimed in claim 16, further comprising session information maintenance means for taking care of storing the capability information.

18. An apparatus as claimed in claim 17, wherein the session infor- mation maintenance means is configured to obtain the capability information during establishment of the group communication.

19. An apparatus as claimed in claim 17 or 18, wherein the session information maintenance means is configured as a session information maintenance unit configured to perform corresponding functions.

20. An apparatus as claimed in any of claims 13 to 19, the apparatus further comprising a sending means for sending messages, the sending means being responsive at least to the privacy provider means, wherein the privacy provider means is configured to forward the private message in response to the result indicating that the next node supports private messages within a group communication.

21. An apparatus as claimed in any of claims 13 to 20, wherein the privacy provider means is configured to add, in response to the result indicating that the next node does not support private messages within a group communication, to the private message an indication of support for private mes- sages within a group communication as a mandatory-to-recognize feature, and to forward the message.

22. An apparatus as claimed in any of claims claims 13 to 21 , wherein the privacy provider means is configured to add, in response to the result indicating that the next node does not support private messages within a group communication, to a subject header of the private message an indication of the message being a private message within a group communication, and to forward the message.

23. An apparatus as claimed in any of claims 13 to 22, wherein the privacy provider means is configured to add, in response to the result indicat- ing that the next node does not support private messages within a group communication, to a body of the private message an indication of the message being a private message within a group communication, and to forward the message.

24. An apparatus as claimed in any of claims 13 to 23, wherein the privacy provider means is configured to check, in response to the result indicating that the next node does not support private messages within a group communication, whether or not an apparatus hosting the group communication supports private messages within a group communication, and, in response to the apparatus hosting the group communication supporting private messages within a group communication, to add to a subject header of the private mes- sage an indication of the message being a private message within a group communication, and to forward the message, and in response to the apparatus hosting the group communication not supporting private messages within a group communication, to reject the message.

25. An apparatus as claimed in any of claims 13 to 24, wherein the privacy provider means is configured to check, in response to the result indicating that the next node does not support private messages within a group communication, whether or not an apparatus hosting the group communication supports private messages within a group communication, and, in response to the apparatus hosting the group communication supporting private messages within a group communication, to add to a body of the private message an indication of the message being a private message within a group communication, and to forward the message, and in response to the apparatus hosting the group communication not supporting private messages within a group communication, to reject the message.

26. An apparatus as claimed in any of claims 13 to 20, wherein the privacy provider means is configured to reject the private message in response to the result indicating that the next node does not support private messages within a group communication.

27. An apparatus as claimed in any of the claims 20 to 26, wherein the sending means is implemented as a sending unit configured to perform corresponding functions.

28. An apparatus as claimed in any of the claims 13 to 27, wherein one or more of the means is configured as an arithmetic operation, and the apparatus comprises memory for storing the arithmetic operation and an op- eration processor or a microprocessor configured to execute the arithmetic operation,

29. An apparatus comprising: a detecting unit configured to detect a private message within a group communication; and a privacy provider unit configured to use capability information on a next node to check whether or not the next node supports private messages within a group communication, and to use a result of the check to decide how to handle the message, and to handle the message according to the decision.

30. An apparatus as claimed in claim 29, the apparatus further comprising a receiver unit configured to receive messages, wherein the detect- ing unit is configured to be responsive to the receiver unit.

31. An apparatus comprising: an operation processor configured to detect a private message within a group communication, to use capability information on a next node to check whether or not the next node supports private messages within a group communication, and to use a result of the check to decide how to handle the message, and to handle the message according to the decision.

32. An apparatus as claimed in claim 31 , the apparatus further comprising a receiver unit configured to receive messages, wherein the operation processor is configured to be responsive to the receiver unit.

33. An apparatus as claimed in any of the claims 13 to 32, wherein the apparatus is a server, a server component or a user terminal configured to support group communication.

34. A system comprising one or more apparatuses as claimed in any of the claims 13 to 33.