CA2665725A1 - Group communication - Google Patents
Group communication Download PDFInfo
- Publication number
- CA2665725A1 CA2665725A1 CA002665725A CA2665725A CA2665725A1 CA 2665725 A1 CA2665725 A1 CA 2665725A1 CA 002665725 A CA002665725 A CA 002665725A CA 2665725 A CA2665725 A CA 2665725A CA 2665725 A1 CA2665725 A1 CA 2665725A1
- Authority
- CA
- Canada
- Prior art keywords
- message
- group communication
- private
- messages
- next node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
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
WO 2008/065245 ~ PCT/F12007/050625 GROUP COMMUNICATION
FIELD OF THE INVENTION
The present invention relates to session-based group communica-tion.
BACKGROUND ART
The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with dis-closures not known to the relevant art prior to the present invention but pro-vided by the invention. Some such contributions of the invention may be spe-lo cifically pointed out below, whereas other such contributions of the invention will 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 confer-encing, 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 appli-cation 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.
FIELD OF THE INVENTION
The present invention relates to session-based group communica-tion.
BACKGROUND ART
The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with dis-closures not known to the relevant art prior to the present invention but pro-vided by the invention. Some such contributions of the invention may be spe-lo cifically pointed out below, whereas other such contributions of the invention will 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 confer-encing, 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 appli-cation 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 prob-lem. 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 mes-sages 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 com-munication 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 ap-paratuses 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 specifica-tion 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 embodi-ment(s), or that the feature only applies to a single embodiment. Single fea-tures of different embodiments may also be combined to provide other em-bodiments.
The present invention is applicable to any user terminal, server, cor-responding components, and/or to any communication system or any combina-tion 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 utiliz-ing both fixed networks and wireless networks. The protocols used, the specifi-cations of communication systems and servers, especially in wireless commu-nication, 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 architec-ture, 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 ses-sion 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 ses-sion-based group communication is illustrated in Figure 1. Figure 1 is a simpli-fied 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 appre-ciated 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 termi-nals 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 note-book), 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 net-work of users using subscriptions of the operator. The chat room server pro-vides 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 C's 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 sub-scriber. 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 Alli-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 in-stant messaging service supports private messages within a group communi-cation 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 net-works and the servers 200, 200', 200" represent here one or more correspond-ing 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 em-bodiment 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 com-munication 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 in-vited, 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 ses-sion information maintenance unit 22 for taking care of storing the capability information on the next node, a detecting unit 23 for detecting a private mes-sage 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 de-cide 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 pro-vider 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 1o the actual invention and, therefore, they need not to be discussed in more de-tail here.
A user terminal may also comprise a corresponding structure or configuration for performing corresponding functionalities when a private mes-sage is sent within a group communication.
Apparatuses, such as servers, or corresponding server compo-nents, user terminals and/or other corresponding devices or apparatuses im-plementing 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 re-sult, and means for handling the private message according to the decision.
More precisely, they comprise means for implementing functionality of a corre-sponding 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 ap-plication, or a module, or a unit configured as an arithmetic operation, or as a program, executed by an operation processor. All modifications and configura-tions required for implementing functionality of an embodiment may be per-formed 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 pro-gram instructions to perform particular tasks. Software routines may be downloaded into an apparatus. The apparatus, such as a server, or a corre-sponding server component, or a module, or a user terminal may be config-ured as a computer or a microprocessor, such as single-chip computer ele-ment, induding 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 provid-ing group communication service may be configured to implement an embodi-1o 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 em-bodiment 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 com-munication. 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 in-vention.
Figures 3 to 6 show flowcharts of different embodiments of an appa-3o 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 mes-sages without restricting the invention to such a solution.
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 prob-lem. 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 mes-sages 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 com-munication 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 ap-paratuses 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 specifica-tion 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 embodi-ment(s), or that the feature only applies to a single embodiment. Single fea-tures of different embodiments may also be combined to provide other em-bodiments.
The present invention is applicable to any user terminal, server, cor-responding components, and/or to any communication system or any combina-tion 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 utiliz-ing both fixed networks and wireless networks. The protocols used, the specifi-cations of communication systems and servers, especially in wireless commu-nication, 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 architec-ture, 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 ses-sion 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 ses-sion-based group communication is illustrated in Figure 1. Figure 1 is a simpli-fied 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 appre-ciated 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 termi-nals 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 note-book), 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 net-work of users using subscriptions of the operator. The chat room server pro-vides 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 C's 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 sub-scriber. 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 Alli-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 in-stant messaging service supports private messages within a group communi-cation 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 net-works and the servers 200, 200', 200" represent here one or more correspond-ing 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 em-bodiment 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 com-munication 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 in-vited, 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 ses-sion information maintenance unit 22 for taking care of storing the capability information on the next node, a detecting unit 23 for detecting a private mes-sage 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 de-cide 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 pro-vider 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 1o the actual invention and, therefore, they need not to be discussed in more de-tail here.
A user terminal may also comprise a corresponding structure or configuration for performing corresponding functionalities when a private mes-sage is sent within a group communication.
Apparatuses, such as servers, or corresponding server compo-nents, user terminals and/or other corresponding devices or apparatuses im-plementing 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 re-sult, and means for handling the private message according to the decision.
More precisely, they comprise means for implementing functionality of a corre-sponding 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 ap-plication, or a module, or a unit configured as an arithmetic operation, or as a program, executed by an operation processor. All modifications and configura-tions required for implementing functionality of an embodiment may be per-formed 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 pro-gram instructions to perform particular tasks. Software routines may be downloaded into an apparatus. The apparatus, such as a server, or a corre-sponding server component, or a module, or a user terminal may be config-ured as a computer or a microprocessor, such as single-chip computer ele-ment, induding 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 provid-ing group communication service may be configured to implement an embodi-1o 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 em-bodiment 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 com-munication. 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 in-vention.
Figures 3 to 6 show flowcharts of different embodiments of an appa-3o 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 mes-sages 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 in-stant 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 mes-sages within the group communication in question using the capability informa-tion. In other words, it is checked, whether or not the next node supports pri-vacy. 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 han-dles 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 in-forming 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 em-bodiment.
The embodiment of Figure 4 utilizes a "mandatory-to-recognize indi-cator ' 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 mes-sage 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 pri-vate 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 mes-sage.
In other words, in the embodiment of Figure 4, the apparatus han-dles 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 con-tains 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 mes-sage is delivered only to recipients supporting private messages within a group communication but not to recipients not supporting private messages within a group oommunication 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 con-tent 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 com-munication. 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 han-dles 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 perform-ing 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 advan-tage 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 pre-fix 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 com-munication. 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 exam-ple 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 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 6, the apparatus han-dles 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 perform-ing 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 pri-vate 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 corrrnmunication.
In a further embodiment, the apparatus is configured to check, prior to modifying a message body, whether or not the message body already con-tains 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 re-sponse 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 ses-sion 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 commu-nication client according to the OMA instant messaging service thereby sup-porting private messages within the group communication, whereas UT-B
comprises a group communication client according to PoC thereby not sup-porting 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 mes-sages 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: fM-clien#IOMA1.0", i.e. a message indicating that a user agent in UT-A is an instant messaging client according to OMA specification 1Ø. In response to receiving the message 7-1, the server A stores, in point 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Ø 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Ø (Corresponding messages will be sent from the server C towards other group members but they are not shown for the sake of clarity.) In response to receiving the message 7-5, the server B
sends a message 7-6 to UT-B. The message may be a"S1P INVITE User-io 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Ø
In response to receiving the message 7-6, the user of UT-B is in-formed 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Ø 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Ø
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 mes-sages 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 Seiver: IM-serv/OMA'I.0", i.e. a message indicating that a server in the server C is an instant messaging server according to OMA specification 1Ø In response to receiving the mes-sage 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:
3o !M-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Ø
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 communi-cation", or "Private messages within a group communication cannot be deliv-ered 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 imple-ment the embodiment, the point 7-14 will be skipped, other points and signal-ling will remain the same in the example illustrated in Figure 7.
In another embodiment, the server B may be configured to store ca-pability 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 mes-sage 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 sup-ports private messages within the group communication.
Although in the above the embodiments have been disclosed as-suming 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 inter-face, to send a private message within a group communication are interpreted as receiving a message).
The steps/points, signaling messages and related functions de-scribed 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 dif-fering 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 corre-sponding 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 or to 506, or from step 604 to step 603 or to 606. The apparatus/server opera-tions 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 capa-bility information at least on next nodes, in an embodiment the apparatus may be configured to request the capability information from the next node in re-sponse 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 in-vention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
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 mes-sages within the group communication in question using the capability informa-tion. In other words, it is checked, whether or not the next node supports pri-vacy. 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 han-dles 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 in-forming 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 em-bodiment.
The embodiment of Figure 4 utilizes a "mandatory-to-recognize indi-cator ' 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 mes-sage 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 pri-vate 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 mes-sage.
In other words, in the embodiment of Figure 4, the apparatus han-dles 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 con-tains 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 mes-sage is delivered only to recipients supporting private messages within a group communication but not to recipients not supporting private messages within a group oommunication 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 con-tent 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 com-munication. 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 han-dles 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 perform-ing 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 advan-tage 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 pre-fix 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 com-munication. 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 exam-ple 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 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 6, the apparatus han-dles 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 perform-ing 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 pri-vate 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 corrrnmunication.
In a further embodiment, the apparatus is configured to check, prior to modifying a message body, whether or not the message body already con-tains 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 re-sponse 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 ses-sion 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 commu-nication client according to the OMA instant messaging service thereby sup-porting private messages within the group communication, whereas UT-B
comprises a group communication client according to PoC thereby not sup-porting 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 mes-sages 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: fM-clien#IOMA1.0", i.e. a message indicating that a user agent in UT-A is an instant messaging client according to OMA specification 1Ø. In response to receiving the message 7-1, the server A stores, in point 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Ø 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Ø (Corresponding messages will be sent from the server C towards other group members but they are not shown for the sake of clarity.) In response to receiving the message 7-5, the server B
sends a message 7-6 to UT-B. The message may be a"S1P INVITE User-io 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Ø
In response to receiving the message 7-6, the user of UT-B is in-formed 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Ø 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Ø
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 mes-sages 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 Seiver: IM-serv/OMA'I.0", i.e. a message indicating that a server in the server C is an instant messaging server according to OMA specification 1Ø In response to receiving the mes-sage 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:
3o !M-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Ø
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 communi-cation", or "Private messages within a group communication cannot be deliv-ered 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 imple-ment the embodiment, the point 7-14 will be skipped, other points and signal-ling will remain the same in the example illustrated in Figure 7.
In another embodiment, the server B may be configured to store ca-pability 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 mes-sage 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 sup-ports private messages within the group communication.
Although in the above the embodiments have been disclosed as-suming 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 inter-face, to send a private message within a group communication are interpreted as receiving a message).
The steps/points, signaling messages and related functions de-scribed 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 dif-fering 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 corre-sponding 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 or to 506, or from step 604 to step 603 or to 606. The apparatus/server opera-tions 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 capa-bility information at least on next nodes, in an embodiment the apparatus may be configured to request the capability information from the next node in re-sponse 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 in-vention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
Claims (34)
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.
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.
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 mes-sages within a group communication, to reject the message.
deciding, in response to the next node not supporting private mes-sages 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 mes-sages within a group communication, to forward the message with an indica-tion of support for private messages within a group communication as a man-datory-to-recognize feature.
deciding, in response to the next node not supporting private mes-sages within a group communication, to forward the message with an indica-tion 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 re-quire 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 mes-sages within a group communication, to forward the message with a subject header indicating that the message is a private message within a group com-munication.
deciding, in response to the next node not supporting private mes-sages within a group communication, to forward the message with a subject header indicating that the message is a private message within a group com-munication.
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 mes-sages within a group communication, to forward the message with a body indi-cating that the message is a private message within a group communication.
deciding, in response to the next node not supporting private mes-sages within a group communication, to forward the message with a body indi-cating 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 communica-tion 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.
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 communica-tion 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 estab-lishment.
obtaining capability information during group communication estab-lishment.
10, A method as claimed in claim 9, the method further comprising:
storing the capability information group communication-specifically.
storing the capability information group communication-specifically.
11. A computer program product comprising program code means adapted to perform any of steps of any of the preceding claims when the pro-gram 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 re-sult of the check to decide how to handle the message, and for handling the message according to the decision.
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 re-sult 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 infor-mation.
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 main-tenance unit configured to perform corresponding functions.
20. An apparatus as claimed in any of claims 13 to 19, the appara-tus 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 re-sponse 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 indicat-ing that the next node does not support private messages within a group com-munication, 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 com-munication, to a body of the private message an indication of the message be-ing a private message within a group communication, and to forward the mes-sage.
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 indi-cating 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 indi-cating 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 in-dication of the message being a private message within a group communica-tion, and to forward the message, and in response to the apparatus hosting the group communication not supporting private messages within a group commu-nication, 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.
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.
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 opera-tion 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.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20065756A FI20065756A0 (en) | 2006-11-28 | 2006-11-28 | group Communications |
| FI20065756 | 2006-11-28 | ||
| PCT/FI2007/050625 WO2008065245A1 (en) | 2006-11-28 | 2007-11-21 | Group communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2665725A1 true CA2665725A1 (en) | 2008-06-05 |
| CA2665725C CA2665725C (en) | 2014-07-08 |
Family
ID=37482568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2665725A Expired - Fee Related CA2665725C (en) | 2006-11-28 | 2007-11-21 | Group communication |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP2087670A4 (en) |
| KR (1) | KR101120656B1 (en) |
| CN (1) | CN101542989A (en) |
| CA (1) | CA2665725C (en) |
| FI (1) | FI20065756A0 (en) |
| WO (1) | WO2008065245A1 (en) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7353034B2 (en) | 2005-04-04 | 2008-04-01 | X One, Inc. | Location sharing and tracking using mobile phones or other wireless devices |
| US9500572B2 (en) | 2009-04-30 | 2016-11-22 | Purdue Research Foundation | Sample dispenser including an internal standard and methods of use thereof |
| CN101710881A (en) * | 2009-11-25 | 2010-05-19 | 中兴通讯股份有限公司 | Method and system for realizing private messages in chat room |
| CN102136919A (en) * | 2010-09-01 | 2011-07-27 | 华为技术有限公司 | Group session realization method and device |
| KR101378309B1 (en) * | 2011-11-22 | 2014-03-28 | 에스케이텔레콤 주식회사 | Apparatus and recording medium for file transfer using HyperText Transfer protocol while chatting |
| CA2888539C (en) | 2013-01-31 | 2021-07-27 | Purdue Research Foundation | Systems and methods for analyzing an extracted sample |
| US9733228B2 (en) | 2013-01-31 | 2017-08-15 | Purdue Research Foundation | Methods of analyzing crude oil |
| US9620344B2 (en) | 2013-06-25 | 2017-04-11 | Purdue Research Foundation | Mass spectrometry analysis of microorganisms in samples |
| US9786478B2 (en) | 2014-12-05 | 2017-10-10 | Purdue Research Foundation | Zero voltage mass spectrometry probes and systems |
| JP6948266B2 (en) | 2015-02-06 | 2021-10-13 | パーデュー・リサーチ・ファウンデーションＰｕｒｄｕｅ Ｒｅｓｅａｒｃｈ Ｆｏｕｎｄａｔｉｏｎ | Probes, systems, cartridges, and how to use them |
| WO2017088128A1 (en) | 2015-11-25 | 2017-06-01 | 华为技术有限公司 | Method, device and system for sending message |
| CN106027367A (en) * | 2016-04-25 | 2016-10-12 | 上海云睦网络科技有限公司 | Immediate messaging method, device and system |
| CN109921976B (en) * | 2017-12-12 | 2021-05-07 | 腾讯科技（深圳）有限公司 | Group-based communication control method, device and storage medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004111790A2 (en) * | 2003-06-11 | 2004-12-23 | Autouptodate Llc D/B/A Armorpost | Private messaging using independent and interoperating couriers |
| US20060239247A1 (en) * | 2005-04-26 | 2006-10-26 | Peter Postmus | Method and session initiation protocol (SIP) server with end-point capabilities check |
-
2006
- 2006-11-28 FI FI20065756A patent/FI20065756A0/en not_active Application Discontinuation
-
2007
- 2007-11-21 CN CNA2007800430031A patent/CN101542989A/en active Pending
- 2007-11-21 EP EP07848158A patent/EP2087670A4/en not_active Ceased
- 2007-11-21 CA CA2665725A patent/CA2665725C/en not_active Expired - Fee Related
- 2007-11-21 WO PCT/FI2007/050625 patent/WO2008065245A1/en active Application Filing
- 2007-11-21 KR KR1020097012965A patent/KR101120656B1/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| EP2087670A4 (en) | 2012-01-18 |
| CA2665725C (en) | 2014-07-08 |
| EP2087670A1 (en) | 2009-08-12 |
| CN101542989A (en) | 2009-09-23 |
| KR101120656B1 (en) | 2012-04-18 |
| WO2008065245A1 (en) | 2008-06-05 |
| KR20090084948A (en) | 2009-08-05 |
| FI20065756A0 (en) | 2006-11-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2665725C (en) | Group communication | |
| KR100899755B1 (en) | Instant messaging service method on mobile telecommunication network and therefor system | |
| EP2036388B1 (en) | Group communication | |
| AU2015315695B2 (en) | Establishing and maintaining a VOIP call | |
| US9204264B2 (en) | Exchange of messages and sessions | |
| EP3010184B1 (en) | Method and internet protocol short message gateway (ip-sm-gw) for providing an interworking service between converged ip messaging (cpm) and short message service (sms) | |
| US8054843B2 (en) | Method for securing privacy in automatic answer mode of push-to service | |
| KR20080057312A (en) | Group communication in communication system | |
| US20080091781A1 (en) | Group communication | |
| CN102130845B (en) | The sending method of return receipt report and processing system | |
| EP2560329B1 (en) | Method and processing system for routing a message request | |
| US20130282838A1 (en) | Group sms messaging | |
| US20140229557A1 (en) | Method and Apparatus for Intercarrier Chat Message Blacklist and Whitelist | |
| EP2453681A1 (en) | System and method for routing session initiation protocol conversation | |
| CN101909019A (en) | Method and system for processing request message | |
| CN1988546A (en) | Method and system for obtaining conversation start protocol news transmission path | |
| CN106161201A (en) | A kind of with Email Accounts for the mark participation method of group chat, equipment and system | |
| JP4959803B2 (en) | Distribution reports in communication systems | |
| WO2012013094A1 (en) | Session establishment method and system based on dialog correlation identifier | |
| US8738716B2 (en) | System and method for routing instant messages | |
| Camarillo | A service-enabling framework for the session initiation protocol (SIP) | |
| WO2016083961A1 (en) | Messaging and combined messaging interworking |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20210831 |
|
| MKLA | Lapsed |
Effective date: 20191121 |