Note: Descriptions are shown in the official language in which they were submitted.
CA 02665725 2009-04-06
WO 2008/065245 1 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-
ll] 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.
CA 02665725 2012-08-03
2
SUMMARY
An object of the present invention is thus to provide a method and
an apparatus for implementing the method so as to overcome the above problem.
The object of the invention is achieved by a method, apparatuses, a module, a
system and a computer program product which are characterized by what is
stated in the independent claims. The preferred embodiments of the invention
are
disclosed in the dependent claims.
The invention is based on utilizing in delivery of a private message
capability information on a next node to check whether or not the next node
supports private messages within a group communication, and to decide how to
continue on the basis of whether or not the next node supports private
messages
within a group communication session.
Accordingly, in one aspect there is provided 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.
According to another aspect there is provided an apparatus
comprising: detecting means for detecting a private message within a group
communication; and privacy provider means, responsive to the detecting means,
for using capability information on a next node to check whether or not the
next
node supports private messages within a group communication, and for using a
result of the check to decide how to handle the message, and for handling the
message according to the decision.
According to yet another aspect there is provided 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.
According to still yet another aspect there is provided 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.
CA 02665725 2012-08-03
2a
BRIEF DESCRIPTION OF THE DRAWINGS
In the following, embodiments will be described in greater detail
with reference to the accompanying drawings, in which
Figure 1 illustrates an example of a general architecture of a
communication system providing a group communication service;
Figure 2 is a simplified block diagram of an apparatus according to
an embodiment of the invention;
Figures 3, 4, 5 and 6 are flow charts illustrating
functionalities of apparatuses according to embodiments of the invention; and
Figure 7 is a signalling diagram illustrating signalling according to
an embodiment of the invention.
DETAILED DESCRIPTION OF SOME EMBODIMENTS
The following embodiments are exemplary.
Although the
specification may refer to "an", "one", or "some" embodiments) in several
locations, this does not necessarily mean that each such reference is to the
same
embodiment(s), or that the feature only applies to a single embodiment. Single
features of different embodiments may also be combined to provide other
embodiments.
The present invention is applicable to any user terminal, server,
corresponding components, and/or to any communication system or any
combination of different communication systems that support session-based
group communication. The communication system may be a fixed communication
CA 02665725 2009-04-06
WO 2008/065245 3 PCT/F12007/050625
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.ieff.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-
CA 02665725 2009-04-06
WO 2008/065245 4 PCT/F12007/050625
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 AIli-
CA 02665725 2009-04-06
WO 2008/065245 5 PCT/F12007/050625
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://vvww.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-
ai 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
CA 02665725 2009-04-06
WO 2008/065245 6 PCT/F12007/050625
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
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
CA 02665725 2009-04-06
WO 2008/065245 7 PCT/F12007/050625
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, including at least a memory for providing storage area used for arithme-
tic operation and an operation processor for executing the arithmetic
operation.
An example of the operation processor includes a central processing unit. The
memory may be removable memory detachably connected to the apparatus.
An apparatus, i.e. a node, in a delivery chain of a message provid-
ing group communication service may be configured to implement an embodi-
ment of the invention regardless of whether or not the apparatus is providing
access to a chat room or is a chat room server or a user terminal. Preferably
apparatuses in a delivery chain are configured to implement the same 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-
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.
CA 02665725 2009-04-06
WO 2008/065245 8 PCT/F12007/050625
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-
CA 02665725 2009-04-06
WO 2008/065245 9 PCT/F12007/050625
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.
CA 02665725 2009-04-06
WO 2008/065245 10 PCT/F12007/050625
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 communication thereby ensuring privacy. This is due to a fact that a
node, either a server or a user terminal, not supporting private messages
within a group communication, rejects a message requiring support for private
messages within a group communication.
In a further embodiment, the apparatus does not check, whether or
not the message contains a require header indicating support for private nnes-
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-
a) 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
CA 02665725 2009-04-06
WO 2008/065245 11 PCT/F12007/050625
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-
w 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
CA 02665725 2009-04-06
WO 2008/065245 12 PCT/F12007/050625
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-
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 communication.
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-
CA 02665725 2009-04-06
WO 2008/065245 13 PC T/FI2007/050625
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: IM-client/OMA1.0", i.e. a message indicating that a user
agent in UT-A is an instant messaging client according to OMA specification
1Ø. In response to receiving the message 7-1, the server A stores, in point
7-
2, as capability information on UT-A that it supports private messages within
group communication, and sends a message 7-3 to the corresponding chat
room server, the server C. The message 7-3 may be a "SIP INVITE User-
Agent: IM-serv/OMA1.0 ", i.e. a message indicating that a user agent in the
server A is an instant messaging server according to OMA specification 1Ø In
CA 02665725 2009-04-06
WO 2008/065245 14 PCT/F12007/050625
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 "SIP INVITE User-
Agent: PoC-serv/OMA2.0", i.e. a message indicating that a user agent in the
server B is a PoC server according to OMA PoC specification 2Ø
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 Server: IM-serv/OMA1.0",
i.e. a message indicating that a server in the server C is an instant
messaging
server according to OMA specification 1Ø 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:
IM-serv/OMA1.0", i.e. a message indicating that a server in the server A is an
instant messaging server according to OMA specification 1Ø
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
CA 02665725 2009-04-06
WO 2008/065245 15 PCT/F12007/050625
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
CA 02665725 2009-04-06
WO 2008/065245 16 PCT/F12007/050625
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
503
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.
