HK1121604B - A method and system of managing chat services - Google Patents

Description

Method and system for managing chat services

Technical Field

The present invention relates to multi-user services in a communication system, and in particular, but not exclusively, to SIP-based instant messaging.

Background

Instant Messaging (IM) is a communication service that allows users to communicate with each other using messages that are delivered to the users in a substantially real-time manner. When a user creates a message on the terminal, it is immediately delivered to other users participating in the instant messaging session, allowing them to reply later. An instant messaging session such as this is also known as a chat session.

Instant messaging services are well known over fixed line networks such as the internet, using, for example, desktop PCs and instant messaging software. However, they are also expected to become a continuously popular service for use in mobile communication systems.

Instant messaging services may be implemented using the Session Initiation Protocol (SIP) developed by the Internet Engineering Task Force (IETF). The session initiation protocol is an application-layer control protocol for creating, modifying and terminating sessions with one or more participants (endpoints). SIP was typically developed to allow a session to be initiated between one or more endpoints in the internet by making these endpoints aware of the session semantics. A user connected to a SIP-based communication system may communicate with various entities of the communication system based on standardized SIP messages. The IETF is currently operating under the heading "SIMPLE for instant messaging and presence leveraging extensions" (SIP) to provide IM and presence services based on SIP. The Open Mobile Alliance (OMA) is also working on SIP/SIMPLE IM and SIP/SIMPLE presence.

Instant messaging services should give users the ability to prevent other users from communicating with them. In particular, some users may be annoying to others. Thus, instant messaging services allow users to block certain other users from contacting them. Each user has a list of users that it blocks, and this is called their blocklist.

However, in scenarios where there are multiple participants in an instant messaging session (referred to as a chat room), problems may arise in managing situations where different users are invited to the chat room by a third party, but the invited users may be prevented from communicating with each other. To illustrate this situation, consider the following example. A user, called user C, creates a chat room and invites user a and user B to join the chat room. However, user a has blocked user B from communicating with him (i.e., user B is in user a's personal blocklist).

The instant messaging system faces the problem of preventing user B from communicating with user a (because user B is in user a's blocklist) without disclosing the contents of user a's personal blocklist to third parties (e.g., the creator of the chat room, i.e., user C). Furthermore, the blocked user may not know that he is on the blocked list of another user and is therefore blocked from communicating with them.

One possible solution to this problem is to allow user C (chat room creator) to invite any one of the users that it wants to invite, without knowing the blocklist preferences of any invitees. However, if a user appearing on another user's blocklist is invited (e.g., user B appears on user A's blocklist), the system should relinquish the invitation to the blocked user. So in this example the invitation will never reach user B. User C will not be notified that his invitation was abandoned.

However, from the point of view of the participants of the chat room, this solution has the drawback of showing that user B has ignored the invitation, or that there is a failure in the IM system or network, and that the invitation has not reached user B. Furthermore, even if user B is only blocked from communicating with one particular user (user a in this case), it also blocks user B from communicating with any other user in the chat room.

Another solution is to allow user C to invite any users to the chat room and these invited users can join the chat room regardless of whether they appear in the blocklist of any participant of the chat room. However, the system may filter any messages from a user who is blocked from communicating with another user so that the blocking user does not see any messages from the blocked user. In other words, in this example, user B may join the chat session, but user A will not see any messages sent by user B.

The problem with this solution is that all participants of the conversation are visible to each other, i.e. user a can see user B online, and vice versa. From the perspective of user B, it will appear that either his message is ignored by user a or there is a failure in the IM system or network. It is therefore fairly easy for user B (or indeed other users in the chat room) to conclude that it appears on user a's blocklist. It is therefore preferred that the decision on how to deal with blocked users is performed during the process of a user joining the chat room, or if they are blocked, all users will not be visible to each other.

There is therefore a need for a more flexible solution to deal with the indicated problems so that the user's personal blocklist is not disclosed to any other participants in the chat room.

Disclosure of Invention

According to an aspect of the present invention, there is provided a method for managing a chat service in a communication system, the method comprising the steps of: a first user terminal initiates a chat session with a session manager; the first user terminal inviting a second user terminal to join the chat session, wherein the second user terminal is associated with a blocklist of blocked users that are blocked from communicating with the second user terminal; checking whether a third user terminal invited to join the chat session by the first user terminal is listed in the blocklist; and if the third user terminal is in the blocklist, creating a notification message to notify the user of the second user terminal: the blocked user is joining the chat session.

According to one embodiment of the invention, the step of creating the notification message is carried out by a session manager.

According to another embodiment of the invention the blocklist is stored at the session manager and the session manager performs the step of checking.

According to another embodiment of the invention, the notification message is sent from the session manager to the second user terminal.

According to another embodiment of the invention, the blocklist is stored at a blocklist manager in a network separate from the network of the session manager, and the blocklist manager performs the step of checking.

According to another embodiment of the invention the blocklist is stored at a blocklist manager in the same network as the session manager and the blocklist manager performs the step of checking.

According to another embodiment of the invention, the notification message is modified by the blocklist manager and sent from the blocklist manager to the second user terminal.

According to another embodiment of the invention, the blocklist is stored at a blocklist manager located in the second user terminal, and the blocklist manager performs the step of checking.

According to another embodiment of the invention, the notification message is modified by the blocklist manager and sent from the blocklist manager to the user interface of the second user terminal.

According to another embodiment of the invention, the third user terminal is associated with a second blocklist, the method further comprising: checking whether the second user terminal is listed in the second blocklist; if the second user terminal is in the second blocklist, a notification message is created to notify the user of the third user terminal that the blocked user is in the chat session.

According to another aspect of the present invention, there is provided a method for managing a chat service in a communication system, the method comprising the steps of: a first user terminal initiates a chat session with a session controller; the first user terminal inviting a second user terminal to join the chat session, wherein the second user terminal is associated with a blocklist of blocked users that are blocked from communicating with the second user terminal, the blocklist being stored at the session controller; checking, at the session controller, whether a third user terminal invited to join the chat session by the first user terminal is listed in the blocklist; and if the third user terminal is in the blocklist, sending a notification message from the session controller to the second user terminal to notify the user of the second user terminal that the blocked user is joining the chat session.

According to another aspect of the present invention, there is provided a method for managing a chat service in a communication network, the method comprising the steps of: a first user terminal initiates a chat session with a session manager; the first user terminal inviting a second user terminal to join the chat session, wherein the second user terminal is associated with a blocklist of blocked users that are blocked from communicating with the second user terminal, the blocklist stored at a blocklist manager in the second user terminal; checking, at the blocklist manager, whether a third user terminal invited to join the chat session by the first user terminal is listed in the blocklist; if the third user terminal is in the blocklist, a notification message is sent from the blocklist manager to the user interface of the second user terminal to notify the user of the second user terminal that the blocked user is joining the chat session.

According to another aspect of the present invention, there is provided a communication system for providing a chat service, the system comprising: a first user terminal for initiating a chat session with a session manager; a second user terminal invited to join the chat session by the first user terminal, wherein the second user terminal is associated with a blocklist of blocked users that are blocked from communicating with the second user terminal; a third user terminal, invited to join the chat session by the first user terminal; means for checking whether a third user terminal is listed in the blocklist; and means for creating a notification message to notify the user of the second user terminal that the blocked user is joining the chat session if the third user terminal is in the blocklist.

Drawings

For a better understanding of the present invention and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which:

FIG. 1 illustrates a wireless communication system;

fig. 2 shows a network structure for the first embodiment of the present invention;

figure 3 shows a signalling message exchange for a first embodiment of the invention;

fig. 4 shows the structure of a known SIP NOTIFY message;

fig. 5 shows the structure of a modified SIP NOTIFY message;

fig. 6 shows a network structure for a second embodiment of the present invention;

figure 7 shows a signalling message exchange for a second embodiment of the present invention;

fig. 8 shows a network structure for a third embodiment of the present invention;

fig. 9 shows a signalling message exchange for a third embodiment of the present invention.

Detailed Description

Referring initially to fig. 1, a wireless communication system 100 is shown. The communication system 100 includes a network 102 that connects mobile entities (user terminals 106) that participate in chat sessions. The network 102 may be a network such as the internet, or it may be a private network such as a telephone core network or an ethernet network.

In the embodiment shown in fig. 1, connected to network 102 are a plurality of base stations 104. The base stations provide wireless connectivity between the user terminals 106 and the network 102. These base stations may have any known wireless standard. For example, they may be GSM/GPRS Base Stations (BS), UMTS node Bs, or WLAN access points. In alternative embodiments, the base station 104 may be replaced by an entity that allows a wired connection to the network, such as a modem or router.

The base station 104 may be directly connected to the network 102, or may be connected to a separate network, which may then be connected to the network 102 via an intermediate entity. In some embodiments, the base stations may all be connected to the same network and operate the same wireless standard. In other embodiments, different base stations may be connected to networks that are separate from one another, and the base stations may operate different wireless standards.

In the embodiment shown in fig. 1, the user terminal 106 is connected to the base station via a wireless link. The wireless link may be according to any known standard, based on the type of network the user is connecting to. For example, if the base station 104 and the user terminal 106 conform to the GSM/GPRS standard, the radio link uses a Time Division Multiple Access (TDMA) scheme. Alternatively, if the base station 104 and the user terminal 106 conform to the UMTS standard, the radio link uses a Wideband Code Division Multiple Access (WCDMA) scheme. Other possible wireless links include Frequency Division Multiple Access (FDMA), Carrier Sense Multiple Access (CSMA), and Orthogonal Frequency Division Multiplexing (OFDM).

The user terminal 106 is configured to enable the user to participate in a chat session. Multiple user terminals may be connected to each base station. Users participating in a chat session (hereinafter referred to as participants) may be connected to the same base station or to separate base stations. The user terminal 106 may be a wireless Mobile Station (MS) such as a mobile phone, a Personal Digital Assistant (PDA), or a laptop computer. In an alternative embodiment, the user terminal 106 may be a wired terminal such as a Personal Computer (PC).

Within network 102 is a conference server 108. The user terminals 106 are connected to a conference server 108 via the base station 104 for participating in a chat session, as will be described below.

Referring now to fig. 2, a network architecture 200 of a first embodiment of the present invention is shown. The exemplary scheme is used to demonstrate the operation of the embodiments of the present invention. In this scenario, three users, user a202, user B204, and user C206, are shown in fig. 2. Each of these users is capable of participating in a chat session and may be connected to a conference server 108 according to that depicted in fig. 1. The local IM server may also be within the user's network. In this scenario, user C creates a chat room. User C then invites user a and user B to the chat room. However, user a has prevented user B from participating in a chat session with user a. Thus, user B is in user a's personal list of blocked users, also called his blocklist. The network architecture should manage the situation so that user a does not have to talk to user B, but also does not have to expose his personal blocklist to the creator of the chat room (user C).

Fig. 3 shows how this embodiment solves this problem. Fig. 3 shows the exchange of signalling messages between the entities described in connection with fig. 2. The present embodiment is based on the SIP/SIMPLE technology.

As noted above, user C206 creates a chat room, and this is initiated by user C sending a SIP INVITE (SIP INVITE) message to the conference server 108 at step S1. The conference server then creates a conference control center (focus) instance and reserves mixer (mixer) resources at 302. User C then subscribes to the conference state notification. At step S2, the process involves communication between the conference server and user C.

User C then sends a SIP REFER message to the conference server indicating that user a and user B should be invited to the chat room. Next, at steps S4 and S5, the conference server sends SIP INVITE messages to user a and user B, respectively. Upon successful reception of the sip invite message, user a and user B respond with a 200OK message in steps S6 and S8. Meanwhile, the conference server needs to know the personal blocklist of each invitee to the chat room, and the conference server requests from the local IM server of user a (306) and from the local IM server of user B (308) (for users a and B, respectively) using SIP SUBSCRIBE messages at steps S7 and S9. These messages are responded to by the local IM servers of user a and user B (306 and 308) with 200OK messages in steps S10 and S11. The message exchange for the conference server to obtain the blocklist has been shown in dashed lines in fig. 3. The conference server maintains a blocklist for each invited user under the invited user's name.

When the conference server requests the blocklist from the invitees in the subscribe message (at the above steps S7 and S9), the conference server may make one-time subscription or continuous subscription. One subscription retrieves only the current content of the blocklist, while a continuous subscription allows the conference server to be informed of any further blocklist modifications. In the case of continuous subscription, if the invitee changes its blocklist, the conference server is notified and updates its blocklist accordingly. Another alternative for extracting the blocklist is to use the extensible markup language (XML) configuration management protocol (XCAP). This is an IETF standardized protocol used by clients to create and manage blocklists. The OMA SIP/SIMPLE IM service also uses XCAP for the same purpose.

Users a and B send sip subscribe messages to the conference server to subscribe to conference change notifications (e.g., new users have joined) at steps S12 and S13, and these are confirmed with 200OK messages from the conference server at steps S14 and S15. The conference server sends a SIP NOTIFY message to user C to NOTIFY user C that user a and user B have joined the chat room in steps S16 and S17.

At 304, the conference server performs a check of each user participating in the chat room to determine if they are included in the blocklist of any participating users. In the case of user a in this example, user B is in user a's blocklist. Thus, when user B joins the chat room immediately after user a, the conference server performs a check to determine if user B is present in the existing blocklist of participants, and the conference server finds a match in user a's blocklist. As a result of finding this match in the blocklist, the conference server sends a modified SIP NOTIFY message to user a, as will be described in more detail below, at step S18. Any other participant in the chat room (who does not have any joining users matching their blocklist) will be sent a regular, unmodified SIP NOTIFY message.

The basic structure of an unmodified notification message is shown in fig. 4. This is comparable to the basic structure of the modification notification message as described above, which is shown in fig. 5. The unmodified message in fig. 4 contains fields for "user" 402, "display-text" 404, "related-recorded address" 406, "role" 408, and "language" 410. The modification notification message in fig. 5 contains an additional field "in-your blocklist" 502, which indicates that the user specified in the chat room matches one of the users listed in the user's blocklist by containing the data "yes".

A more detailed representation of the modification notification message sent, for example, in step S18, can be seen below. The new "in your blocklist" field added as part of this embodiment is shown in bold.

<user entity＝″sip：UserB@example.com″state＝″full″>

<display-text>UserB</display-text>

<in-yotir-blocklst>yes</in-your-blocklist>

<associated-aors>

<entry>

<uri>mailto：UserB@example.com</uri>

<label>email</label>

</entry>

</associated-aors>

<roles>

<entry>

<label>participant</label>

</entry>

</roles>

<language>en</language>

<！--

Returning now to fig. 3, upon receiving the modified NOTIFY message, user a is notified that user B (in his blocklist) has been invited to join or already exists in the chat room. User a then has the following options: stay in the chat room but not view any text from user B, update his blocklist to allow user B's text to be seen temporarily; or user a may choose not to join and leave the chat room.

If user A chooses to stay in the chat room, but does not view any text from user B, the server may perform filtering of user B's text. Optionally, the user terminal may perform filtering. All other participants in the chat room can see the text of user B. No other participant will know that user a is filtering user B's messages.

The notification of the blocked user occurs only once and after that the message is sent to all participants. However, as described above, the conference server optionally performs further filtering of the messages.

If user B (as a new joining user) has any already participating users in its blocklist (e.g., if user B has user a in its blocklist), user B will be sent a modified NOTIFY message as described above and will have the same three options as user a summarized previously. However, in the example shown here, user B does not have any other participants in its blocklist, and is therefore sent an unmodified NOTIFY message at S19.

Reference will now be made to fig. 6, which illustrates a network architecture 600 of a second embodiment of the present invention. In this scenario, the same three users as shown in the first embodiment: user a202, user B204, and user C206. As in the first embodiment, user C creates a chat room and invites user a and user B. However, user B is in user A's blocklist. In a second embodiment of the invention, the conference server 602 architecture includes two logical units, a participating IM server 604 (or blocklist manager) and a controlling IM server 606 (or session manager).

The participating IM server is located within the home network of the user as a recipient of the message and acts as a receiving server and enforces the message delivery requirements of the respective recipient. The participating IM servers maintain blocklist of users associated with them and are responsible for performing blocklist matching processes. The control server is located within the network that hosts/owns the group conversation.

Fig. 7 shows the exchange of signalling messages between the entities described above with reference to fig. 6. As with the first embodiment, user C initiates a chat session by sending SIP INVITE a message to the controlling IM server 606 at step S20. The controlling IM server then creates a conference control center instance and reserves mixer resources at 702. User C then subscribes to the conference state notification. At step S21, the process involves controlling communication between the IM server and user C.

User C then sends a SIP REFER message to the controlling IM server indicating that user a and user B should be invited to the chat room at step S22. In step S23, the controlling IM server then sends SIP INVITE messages to the participating IM server for user a. At step S24, a SIP INVITE message is then further sent from the participating IM server to user a. In steps S25 and S26, a SIP INVITE message is also sent to user B via the participating IM server. Upon successful receipt of the SIP INVITE message, user A and user B respond with a 200OK message in steps S27 and S29, and then send back to the controlling IM server via the participating IM server in steps S28 and S30.

In contrast to the first embodiment of the present invention, the participating IM server of the present invention has maintained the blocklist of users and therefore does not need to control the IM server to subscribe to the blocklist information.

At S31 and S33, users A and B send SIP to the participating IM server

SUBSCRIBE message to SUBSCRIBE to conference change notifications (e.g., new users have joined) and these are forwarded to the controlling IM server at steps S32 and S34. These messages are confirmed with 200OK messages from the controlling IM server, which are delivered to user a and user B via the participating IM server in steps S35 and S36 and in steps S38 and S39. In steps S37 and S40, the IM server is controlled to send a SIP NOTIFY message to user C to NOTIFY user C that user a and user B have joined the chat room.

In step S41, the controlling IM server sends a SIP NOTIFY message to the participating IM server that the new user has joined the chat room. The message contains an "IM-tag" similar to the "PoC-tag" in OMA Push to Talk over Cellular (PoC), which is used to route the message to the participating IM server. The "im-tag" feature tag is added to the contact or accept-contact header in the SIP message.

At 704, the participating IM server performs a check of each user participating in the chat room to determine if they are included in the blocklist of any participating users. In the case of user a in this example, user B is in user a's blocklist. Thus, when user B joins the chat room immediately after user a, the participating IM server performs a check to determine if user B is present in the existing participant's blocklist, and the participating IM server finds a match in user a's blocklist. As a result of finding this match in the blocklist, the participating IM server modifies the SIP NOTIFY message from the controlling IM server to indicate that user B is in the blocklist, and at step S42, sends the modified SIP NOTIFY message to user a. The modified SIP NOTIFY message sent at step S42 may be the same as described above for the first embodiment of the present invention. Any other participant of the chat room (who does not have any joining users matching their blocklist) will be sent a regular, unmodified SIP NOTIFY message.

Upon receiving the modified NOTIFY message, user a has the following options: stay in the chat room but not view any text from user B, update his blocklist to allow user B's text to be seen temporarily; or user a may choose not to join and leave the chat room. If user A chooses to stay in the chat room but does not view any text from user B, the participating IM server may perform filtering of user B's text. All other participants in the chat room can see the text of user B. No other participant will know that user a is filtering user B's messages. The notification of the blocked user occurs only once and after that, the message is sent to all participants. However, as described above, the participating IM servers optionally perform further filtering of the messages.

If user B (as a new joining user) has any already participating users in its blocklist (e.g., if user B has user a in its blocklist), user B will be sent a modified NOTIFY message as described above and will have the same three options as user a summarized previously. However, in the example shown here, user B does not have any other participants in its blocklist, and is therefore sent an unmodified NOTIFY message at S43.

A third embodiment of the invention is seen with reference to fig. 8, which shows a network architecture 800 of this embodiment. In this scenario, the same three users as shown in the first and second embodiments: user a202, user B204, and user C206. As in the first and second embodiments, user C creates a chat room and invites user a and user B. However, user B is in the blocklist of user A. In a third embodiment of the invention, the user terminal comprises an IM client 804 and a User Interface (UI)806 (shown in this case only for user a). The network architecture includes a conference server 802, but it does not perform all of the same functions as in the first and second embodiments. In particular, the blocklist of participants is stored locally within the IM client. The IM client then performs a comparison between the joining user or participant in the chat room and the blocklist.

Fig. 9 shows the exchange of signalling messages between the entities described above with reference to fig. 8. As in the previous embodiment, user C initiates a chat session by sending SIP INVITE a message to the conference server 802 at step S44. The conference server then creates a conference control center instance and reserves mixer resources at 902. User C then subscribes to the conference state notification. At step S45, the process involves communication between the conference server and user C.

User C then sends a SIP REFER message to the conference server indicating that user a and user B should be invited to the chat room at step S46. The conference server sends SIP INVITE messages to user a and user B, respectively, at steps S47 and S48, and confirms them with 200OK messages from user a and user B, at steps S49 and S50. User a and user B subscribe to the chat room in sip subscribe messages sent to the conference server at steps S51 and S52. In steps S53 and S55, the conference server confirms with a 200OK message for user a and user B. Meanwhile, the conference server notifies the user C that the user a has joined the chat room at step S54, and performs the same operation on the user B at step S56.

In this embodiment of the invention, no comparison is performed at the conference server between users joining the chat room and those listed in the participant's blocklist. Alternatively, when a new user joins the chat room, a SIP NOTIFY message is sent to the participants. In the case of the example in fig. 9, a SIP NOTIFY message is sent to the user a in step S57. The IM client 804 at the user terminal then compares the user joining the chat room with the blocklist stored locally at the IM client at 904. In the case of user a, when user B joins the chat room, the IM client will find a match in the blocklist. After finding a match, the IM client notifies the user through the UI in step S58.

Upon receiving the notification from the IM client, user a has the same options as the previous embodiment. User a has the following options: stay in the chat room but not view any text from user B, update his blocklist to allow user B's text to be seen temporarily; or user a may choose not to join and leave the chat room. If user A chooses to stay in the chat room but does not view any text from user B, the IM client performs filtering of user B's text. All other participants in the chat room can see the text of user B. No other participant will know that user a is filtering user B's messages.

If user B (as a new joining user) has any already participating users in its blocklist (e.g., if user B has user a in its blocklist), then as described above, the IM client within user B's terminal will notify user B, and user B will have the same three options as user a summarized previously. However, in the example shown here, user B does not have any other participants in its blocklist, and therefore after being sent a SIP NOTIFY message at S43, the IM client does not find a match and does not need to NOTIFY user B.

This embodiment of the invention does not require a modified SIP notify message, as was required in the previous two embodiments. This is because the notifications come from an IM client, which is local to the participants, and the notifications sent depend on the UI used.

The three embodiments described above have the advantage that the creator of the chat room can invite anyone to participate without having to know any details of the invitee's preferences. Instead, an invitee to the chat room (e.g., user a) has given a choice as to how to handle the blocked user's online. Thus, the creator of the chat room need not be provided with the details of the invitee's private blocklist information. Further, unlike other known solutions, it does not show the presence of a fault in the IM system.

Claims (13)

1. A method for managing chat services in a communication system, the method comprising the steps of:

a first user terminal initiates a chat session with a session manager;

the first user terminal inviting a second user terminal to join the chat session, wherein the second user terminal is associated with a blocklist comprising blocked users that are blocked from communicating with the second user terminal;

checking whether a third user terminal invited to join the chat session by the first user terminal is listed in the blocklist;

if the third user terminal is in the blocklist, creating a notification message to notify the user of the second user terminal that the blocked user is joining the chat session; and

the user of the second user terminal selects one of the following three options: stay in the chat session but not view any text from the third user terminal, update his blocklist to allow temporary viewing of any text from the third user terminal, or choose not to join but leave the chat session.

2. The method of claim 1, wherein the step of creating the notification message is performed by a session manager.

3. The method of claim 2, wherein the blocklist is stored at the session manager and the session manager performs the step of checking.

4. A method according to claim 3, wherein the notification message is sent from the session manager to the second user terminal.

5. The method of claim 2, wherein the blocklist is stored at a blocklist manager in a network separate from the network of session managers and the blocklist manager performs the step of checking.

6. The method of claim 2, wherein the blocklist is stored at a blocklist manager in the same network as the session manager, and the blocklist manager performs the step of checking.

7. A method according to claim 5 or 6, wherein the notification message is modified by the blocklist manager and sent from the blocklist manager to the second user terminal.

8. The method according to claim 2, wherein the blocklist is stored at a blocklist manager located in the second user terminal and the blocklist manager performs the step of checking.

9. The method of claim 8, wherein the notification message is modified by the blocklist manager and sent from the blocklist manager to a user interface of the second user terminal.

10. The method of claim 1, wherein the third user terminal is associated with a second blocklist, the second blocklist including blocked users that are blocked from communicating with the third user terminal, the method further comprising:

checking whether said second user terminal is listed in said second blocklist;

if the second user terminal is in the second blocklist, creating a notification message to notify a user of the third user terminal: the blocked user is in the chat session.

11. A method for managing chat services in a communication system, the method comprising the steps of:

a first user terminal initiates a chat session with a session controller;

the first user terminal inviting a second user terminal to join the chat session, wherein the second user terminal is associated with a blocklist comprising blocked users that are blocked from communicating with the second user terminal, the blocklist being stored at a session controller;

checking at the session controller whether a third user terminal invited to join the chat session by the first user terminal is listed in a blocklist;

if a third user terminal is in the blocklist, sending a notification message from the session controller to a second user terminal to notify a user of the second user terminal that a blocked user is joining the chat session; and

the user of the second user terminal selects one of the following three options: stay in the chat session but not view any text from the third user terminal, update his blocklist to allow temporary viewing of any text from the third user terminal, or choose not to join but leave the chat session.

12. A method for managing chat services in a communication network, the method comprising the steps of:

a first user terminal initiates a chat session with a session manager;

the first user terminal inviting a second user terminal to join the chat session, wherein the second user terminal is associated with a blocklist comprising blocked users that are blocked from communicating with the second user terminal, the blocklist being stored at a blocklist manager in the second user terminal;

checking, at the blocklist manager, whether a third user terminal invited to join the chat session by the first user terminal is listed in the blocklist;

if the third user terminal is in the blocklist, sending a notification message from the blocklist manager to a user interface of the second user terminal to notify a user of the second user terminal that the blocked user is joining the chat session; and

the user of the second user terminal selects one of the following three options: stay in the chat session but not view any text from the third user terminal, update his blocklist to allow temporary viewing of any text from the third user terminal, or choose not to join but leave the chat session.

13. A communication system for providing a chat service, the system comprising:

a first user terminal for initiating a chat session with a session manager;

a second user terminal that is invited by the first user terminal to join the chat session, wherein the second user terminal is associated with a blocklist that includes blocked users that are blocked from communicating with the second user terminal;

a third user terminal, invited by the first user terminal to join the chat session;

means for checking whether the third user terminal is listed in the blocklist; and

means for creating a notification message to notify a user of a second user terminal that a blocked user is joining the chat session if the third user terminal is in the blocklist, and wherein the user of the second user terminal selects one of the following three options: stay in the chat session but not view any text from the third user terminal, update his blocklist to allow temporary viewing of any text from the third user terminal, or choose not to join but leave the chat session.