インスタントメッセージング(IM)は、実質的にリアルタイムでユーザに配送されるメッセージを使用してユーザが互いに通信するのを許す通信サービスである。ユーザがターミナルにおいてメッセージを生成すると、それが、インスタントメッセージングセッションに参加している他のユーザへ直ちに配送され、このユーザが、その後、応答するのを許す。このようなインスタントメッセージングセッションは、チャットセッションとしても知られている。
インスタントメッセージングサービスは、例えば、デスクトップPCや、インスタントメッセージングソフトウェアを使用して、インターネットのような固定ラインネットワークを経て良く知られている。しかしながら、それらは、移動通信システムにおいて使用するための益々人気のあるサービスとなることも期待される。
インスタントメッセージングサービスは、インターネットエンジニアリングタスクフォース(IEFT)により開発されたセッションイニシエーションプロトコル(SIP)を使用して実施することができる。セッションイニシエーションプロトコルは、1人以上の参加者(エンドポイント)とのセッションを生成し、変更しそして終了するためのアプリケーションレイヤ制御プロトコルである。SIPは、一般的に、インターネットにおける2つ以上のエンドポイントがセッションのセマンティックに気付くようにすることによりそれらエンドポイント間でセッションを開始するのを許すために開発された。SIPベースの通信システムに接続されたユーザは、標準化されたSIPメッセージに基づく通信システムの種々のエンティティと通信することができる。IETFは、現在、“SIP for instant messaging and presence leveraging extensions”(SIMPLE)という表題のもとに、SIPに基づきIM及び存在サービスを提供することを研究している。オープンモバイルアリアンス(OMA)も、SIP/SIMPLE IM及びSIP/SIMPLE存在について研究している。
インスタントメッセージングサービスは、ユーザに、他のユーザが彼らと通信するのを防止する構成を与えねばならない。特に、あるユーザは、他の者にとって不快なことがある。それ故、インスタントメッセージングサービスでは、ユーザは、特定の他のユーザが彼らとコンタクトするのを阻止することが許される。各ユーザは、阻止したユーザのリストを有し、これは、阻止リストと称される。
しかしながら、インスタントメッセージングセッションに多数の参加者がいる場合には(チャットルームとして知られている)、異なるユーザが第三者によりチャットルームに招待されたが、それら招待されたユーザは互いに通信することが阻止されるかもしれない状況を管理する上で問題がある。この状況を説明するために、次の例を考える。ユーザCと称されるユーザは、チャットルームを生成し、ユーザA及びユーザBをチャットルームに加わるよう招待する。しかしながら、ユーザAは、ユーザBが彼と通信するのを阻止している(即ち、ユーザBは、ユーザAの個人的阻止リストに含まれている)。
インスタントメッセージングシステムは、ユーザBがユーザAと通信するのを阻止する(ユーザBがユーザAの阻止リストに含まれるので)という問題に直面するが、ユーザAの個人的阻止リストの内容を第三者(例えば、チャットルーム創設者、即ちユーザC)に開示しない。更に、阻止されたユーザは、彼が別のユーザの阻止リストにあり、それ故、彼との通信が阻止されることに気付かない。
この問題に対して考えられる1つの解決策は、ユーザC(チャットルーム創設者)が、招待客の阻止リストの選択を知らずに、彼が望む方のユーザを招待するのを許すことである。しかしながら、別のユーザの阻止リストに現われるユーザ(例えば、ユーザBはユーザAの阻止リストに現われる)が招待される場合には、システムは、阻止されたユーザへの招待を破棄すべきである。それ故、この例では、ユーザBには招待が届かない。ユーザCには、彼の招待が破棄されたことが通知されない。
しかしながら、この解決策は、チャットルームの参加者の観点から、ユーザBが招待を無視したか、或いはIMシステム又はネットワークに欠陥があって招待がユーザBに届かなかったと思われる、という欠点がある。更に、たとえユーザBが1人の特定のユーザ(このケースではユーザA)との通信が阻止されるだけであっても、ユーザBは、チャットにおける他のユーザとの通信も阻止される。
別の解決策は、ユーザCがいずれのユーザもチャットルームに招待し、そしてその招待されたユーザがチャットルームのいずれかの参加者の阻止リストに現われるかどうかに関らず、彼らの参加を許すことである。しかしながら、システムは、別のユーザとの通信が阻止されたユーザからのメッセージをフィルタし、その阻止されたユーザからのメッセージが、阻止する側のユーザには見えないようにすることができる。換言すれば、この例では、ユーザBはチャットセッションに参加できるが、ユーザBが送信するメッセージをユーザAが見ることはない。
この解決策に伴う問題は、セッションへの全ての参加者が互いに見え、即ちユーザAは、ユーザBが存在するのが見え、その逆もあることである。ユーザBの観点から、彼のメッセージは、ユーザAにより無視されるか、或いはIMシステム又はネットワークに欠陥があるかのいずれかと思われる。それ故、ユーザB(又は実際にはチャットルームの他のユーザ)が、彼がユーザAの阻止リストにあると結論付けることは極めて容易である。それ故、阻止されたユーザをいかに取り扱うかの判断を、ユーザをチャットルームに参加させるプロセス中に行うか、或いはユーザが阻止されている場合には全てのユーザが互いに見えないようにするのが好ましい。
本発明を良く理解すると共に、本発明をどのように実施するか示すために、添付図面を参照して本発明を一例として詳細に説明する。
先ず、ワイヤレス通信システム100が示された図1を参照する。この通信システム100は、チャットセッションに参加する移動エンティティ(ユーザターミナル106)を接続するネットワーク102を備えている。ネットワーク102は、インターネットのようなネットワークでもよいし、或いはテレコミュニケーションコアネットワーク又はイーサネット(登録商標)ネットワークのようなプライベートネットワークでもよい。
図1に示す実施形態において、ネットワーク102には複数のベースステーション104が接続される。これらベースステーションは、ユーザターミナル106とネットワーク102との間にワイヤレス接続を与える。これらベースステーションは、既知のワイヤレス規格のいずれかでよい。例えば、それらは、GSM/GPRSベースステーション(BS)でもよいし、UMTSノードBでもよいし、又はWLANアクセスポイントでもよい。別の実施形態では、ベースステーション104は、ネットワークへのワイヤード接続を許すエンティティ、例えば、モデム又はルーターに置き換えられる。
ベースステーション104は、ネットワーク102に直結されてもよいし、又は個別のネットワークに接続されて、これら個別のネットワークが中間エンティティを経てネットワーク102に接続されてもよい。ある実施形態では、ベースステーションが全て同じネットワークに接続され、そして同じワイヤレス規格で動作してもよい。他の実施形態では、異なるベースステーションが互いに個別のネットワークに接続されてもよいし、ベースステーションが異なるワイヤレス規格で動作してもよい。
図1に示す実施形態では、ユーザターミナル106は、ワイヤレスリンクを経てベースステーションに接続される。ワイヤレスリンクは、任意の既知の規格に基づき、又、ユーザターミナルが接続されるネットワークの形式に依存する。例えば、ベースステーション104及びユーザターミナル106がGSM/GPRS規格に適合する場合には、ワイヤレスリンクは、時分割多重アクセス(TDMA)機構を使用する。或いは又、ベースステーション104及びユーザターミナル106がUMTS規格に適合する場合には、ワイヤレスリンクは、ワイドバンドコード分割多重アクセス(WCDMA)機構を使用する。他の考えられるワイヤレスリンクは、周波数分割多重アクセス(FDMA)、搬送波感知多重アクセス(CSMA)、及び直交周波数分割マルチプレクシング(OFDM)を含む。
ユーザターミナル106は、ユーザがチャットセッションに参加できるように構成される。多数のユーザターミナルを各ベースステーションに接続することができる。チャットセッションに参加するユーザ(以下、参加者と称する)は、同じベースステーションに接続されてもよいし、個別のベースステーションに接続されてもよい。ユーザターミナル106は、ワイヤレス移動ステーション(MS)、例えば、移動電話、パーソナルデジタルアシスタント(PDA)、又はラップトップコンピュータでよい。別の実施形態では、ユーザターミナル106は、パーソナルコンピュータ(PC)のようなワイヤードターミナルである。
ネットワーク102内には、会議サーバー108がある。ユーザターミナル106は、以下に述べるように、ベースステーション104を経て会議サーバー108に接続され、チャットセッションに参加する。
次いで、本発明の第1の実施形態のネットワーク構造200を示した図2を参照する。本発明のこの実施形態の動作を示すために例示的シナリオを使用する。このシナリオでは、図2に示す3人のユーザ、即ちユーザA202、ユーザB204、及びユーザC206が存在する。これらユーザの各々は、チャットセッションに参加することができ、そして図1に関して概略を述べた会議サーバー108に接続することができる。又、ユーザのネットワークには、ローカルIMサーバーが存在してもよい。このシナリオでは、ユーザCがチャットルームを生成する。次いで、ユーザCは、ユーザA及びユーザBをチャットルームに招待する。しかしながら、ユーザAは、ユーザBがユーザAとのチャットセッションに参加するのを阻止している。それ故、ユーザBは、ユーザAの個人的な阻止ユーザリスト、阻止リストとして知られている、に載せられている。ネットワーク構造体は、ユーザAがユーザBと話をすることがなく、しかも、彼の個人的阻止リストをチャットルームの創設者、即ちユーザCに暴露しないように、この状況を管理しなければならない。
図3は、本発明の実施形態がこの問題をどのように解消するか示している。図3は、図2を参照して上述したエンティティ間でのシグナリングメッセージの交換を示す。この実施形態は、SIP/SIMPLE技術に基づいている。
上述したように、ユーザC 206は、チャットルームを生成し、これは、ステップS1において、ユーザCがSIP INVITEメッセージを会議サーバー108へ送信することにより開始される。会議サーバーは、302において、フォーカスインスタンスを生成し、そしてミクサリソースを予約する。次いで、ユーザCは、会議状態通知に契約する。このプロセスは、ステップS2において、会議サーバーとユーザCとの間の通信を含む。
ユーザCは、次いで、SIP REFERメッセージを会議サーバーへ送信し、ユーザA及びユーザBをチャットルームへ招待すべきであることを指示する。会議サーバーは、次いで、ステップS4及びS5において、SIP INVITEメッセージを各々ユーザA及びユーザBに送信する。SIP INVITEメッセージを首尾良く受け取ると、ユーザA及びユーザBは、ステップS6及びS8において200 OKメッセージで応答する。その間に、会議サーバーは、チャットルームへの各招待客の個人的阻止リストを知る必要があり、そして会議サーバーは、ステップS7及びS9において(各々ユーザA及びBに対して)SIP SUBSCRIBEメッセージでこれをローカルIMサーバーからユーザA(306)へそしてローカルIMサーバーからユーザB(308)へ要求する。これらのメッセージは、ステップS10及びS11においてローカルIMサーバーにより各々ユーザA及びユーザB(306及び308)へ200 OKメッセージで応答される。会議サーバーが阻止リストを得るためのメッセージ交換が図3に破線で示されている。会議サーバーは、招待ユーザの名前のもとで各招待ユーザの阻止リストを維持する。
会議サーバーが契約メッセージで招待客から阻止リストを要求すると(前記ステップS7及びS9)、会議サーバーは、一回だけの契約、又は連続的な契約を果たすことができる。一回だけの契約は、阻止リストの現在内容だけを検索し、一方、連続的な契約は、それ以降の阻止リスト変更を会議サーバーに通知することが許される。連続的な契約の場合には、招待客が自分の阻止リストを変更すると、会議サーバーに通知がなされ、その阻止リストを適宜に更新する。阻止リストをフェッチする別の仕方は、拡張性マークアップ言語(XML)コンフィギュレーションマネージメントプロトコル(XCAP)を使用することである。これは、阻止リストを生成して管理するためにクライアントにより使用されるIETF標準プロトコルである。OMA SIP/SIMPLE IMサービスも、同じ目的でXCAPを使用する。
ユーザA及びBは、S12及びS13において、SIP SUBSCRIBEメッセージを会議サーバーへ送信して、会議変更通知(例えば、新たなユーザが加わった)に契約し、これらは、ステップS14及びS15において会議サーバーからの200 OKメッセージで確認される。会議サーバーは、ステップS16及びS17において、SIP NOTIFYメッセージをユーザCへ送信して、ユーザCに、ユーザA及びユーザBがチャットルームに加わったことを通知する。
会議サーバーは、304において、チャットルームに加わった各ユーザのチェックを行って、参加ユーザの阻止リストのいずれかにユーザが含まれるかどうか調べる。この例では、ユーザAの場合に、ユーザBがユーザAの阻止リストに載せられている。それ故、ユーザBがユーザAの直後にチャットルームに加わったときに、会議サーバーは、ユーザBが既存の参加者の阻止リストに現われるか調べるチェックを遂行し、そして会議サーバーは、ユーザAの阻止リストに一致を見つける。阻止リストにこの一致を見つけた結果として、会議サーバーは、以下に詳細に述べるように、ステップS18において、変更されたSIP NOTIFYメッセージをユーザAに送信する。チャットルームへの他の参加者であって、阻止リストに一致する参加ユーザをもたない参加者には、通常の、変更されないSIP NOTIFYメッセージが送信される。
変更されない通知メッセージの基本的構造が図4に示されている。これに対して、上述した変更された通知メッセージの基本的構造が図5に示されている。図4の、変更されないメッセージは、「ユーザ」フィールド402、「表示テキスト」フィールド404、「関連aors」フィールド406、「役割」フィールド408、及び「言語」フィールド410を含む。図5の、変更された通知メッセージは、余計なフィールド「あなたの阻止リスト(in-your-blocklist)」502を含み、これは、データ「イエス」を含むことにより、チャットルーム内の特定ユーザがユーザの阻止リストに載せられた者に一致することを指示する。
ステップS18で送信されるような変更された通知メッセージの詳細な表現は、次の通りである。ここに示す実施形態の一部分として追加される新たな「あなたの阻止リスト」フィールドは、太字で示す。
図3を再び参照すれば、変更されたNOTIFYメッセージを受け取ると、ユーザAには、彼の阻止リストにあるユーザBがチャットルームに加わったか、招待されているか、又はそこに既に存在しているかが通知される。ユーザAは、このとき、チャットルームに留まるがユーザBからのテキストを見ないか、ユーザBのテキストを一時的に見るのを許すように自分の阻止リストを更新するか、或いはユーザAがチャットルームに加わらずに立ち去るよう選択するかの選択肢を有する。
ユーザAがチャットルームに留まるがユーザBからのテキストを見ないように選択する場合には、サーバーは、ユーザBのテキストのフィルタリングを遂行することができる。或いは又、ユーザターミナルがフィルタリングを遂行してもよい。チャットルーム内の他の全ての参加者は、ユーザBのテキストを見ることができる。他の参加者は、ユーザAがユーザBのメッセージをフィルタリングしたことを知らない。
阻止されたユーザの通知は、一度しか行なわれず、その後、メッセージは全ての参加者に送信される。しかしながら、会議サーバーは、上述したように、メッセージの更なるフィルタリングを遂行することができる。
ユーザBが、新たに加わるユーザとして、既に参加しているユーザのいずれかを自分の阻止リストに有する場合(例えば、ユーザBがユーザAをその阻止リストに有する場合)には、ユーザBに、上述したように、変更されたNOTIFYメッセージが送信され、そして上述したユーザAと同じ3つの選択肢を有することになる。しかしながら、ここに示す例では、ユーザBは、他の参加者のいずれも自分の阻止リストに有しておらず、それ故、S19において、変更されないNOTIFYメッセージが送信される。
次いで、本発明の第2の実施形態のネットワーク構造600を示す図6を参照する。このシナリオでは、第1の実施形態で示されたのと同じ3人のユーザ、即ちユーザA202、ユーザB204及びユーザC206が存在する。第1の実施形態と同様に、ユーザCがチャットルームを生成し、ユーザA及びユーザBを招待する。しかしながら、ユーザBがユーザAの阻止リストに存在する。本発明の第2の実施形態では、会議サーバー602のアーキテクチャーは、2つの論理的要素、即ち参加IMサーバー604(又は阻止リストマネージャー)、及び制御IMサーバー606(又はセッションマネージャー)を備えている。
参加IMサーバーは、メッセージの受信者であるユーザのホームネットワーク内にあり、これは、受信サーバーであって、個々の受信者のメッセージ配送要求を実行する。参加IMサーバーは、それに関連したユーザの阻止リストを維持し、そして阻止リスト一致プロセスを遂行する役割を果たす。制御サーバーは、グループ会話をホストし/所有するネットワークに位置される。
図7は、図6を参照して上述したエンティティ間でのシグナリングメッセージの交換を示す。第1の実施形態と共通であることに、ユーザCが、ステップS20において、制御IMサーバー606にSIP INVITEメッセージを送信することにより、チャットセッションを開始する。次いで、制御IMサーバーは、702において、フォーカスインスタンスを生成し、ミクサリソースを予約する。次いで、ユーザCは、会議状態通知に契約する。このプロセスは、ステップS21において、制御IMサーバーとユーザCとの間の通信を含む。
次いで、ユーザCは、ステップS22において制御IMサーバーへSIP REFERメッセージを送信し、これは、ユーザA及びユーザBをチャットルームへ招待すべきであることを指示する。制御IMサーバーは、次いで、ステップS23において、ユーザAに対する参加IMサーバーへSIP INVITEメッセージを送信する。SIP INVITEメッセージは、次いで、ステップS24において、参加IMサーバーからユーザAへ更に送信される。又、SIP INVITEメッセージは、ステップS25及びS26において、参加IMサーバーを経てユーザBへも送信される。SIP INVITEメッセージを首尾良く受け取ると、ユーザA及びユーザBは、ステップS27及びS29において、200 OKメッセージで応答し、これらは、ステップS28及びS30において参加IMサーバーを経て制御IMサーバーへ返送される。
本発明の第1の実施形態とは対照的に、この実施形態の参加IMサーバーは、ユーザの阻止リストを既に維持しており、それ故、制御IMサーバーが素子リスト情報に契約する必要はない。
ユーザA及びBは、S31及びS33において、参加IMサーバーへSIP SUBSCRIBEメッセージを送信して、会議変化通知(例えば、新たなユーザが加わった)に契約し、これらは、ステップS32及びS34において、制御IMサーバーへ転送される。これらメッセージは、制御IMサーバーからの200 OKメッセージで確認され、これらは、ステップS35及びS36において参加IMサーバーを経てユーザAへ通され、そしてステップS38及びS39においてユーザBへ通される。制御IMサーバーは、ステップS37及びS40において、SIP NOTIFYメッセージをユーザCへ送信し、ユーザA及びユーザBがチャットルームに加わったことをユーザCに通知する。
制御IMサーバーは、ステップS41において、新たなユーザがチャットルームに加わったというSIP NOTIFYメッセージを参加IMサーバーへ送信する。このメッセージは、OMAプッシュ・ツー・トークオーバーセルラー(PoC)における“poc−tag”と同様の“im−tag”を含み、これは、メッセージを参加IMサーバーへルーティングするのに使用される。“im−tag”特徴タグは、SIPメッセージにおける「コンタクト」又は「アクセプト−コンタクト」ヘッダに追加される。
参加IMサーバーは、704において、チャットルームに加わる各ユーザのチェックを遂行し、参加ユーザの阻止リストのいずれかにユーザが含まれているかどうか調べる。この例では、ユーザAの場合に、ユーザBがユーザAの阻止リストにある。それ故、ユーザBがユーザAの直後にチャットルームに加わったときに、参加IMサーバーは、ユーザBが既存の参加者の阻止リストに現われるか調べるチェックを遂行し、そして参加IMサーバーは、ユーザAの阻止リストに一致を見つける。阻止リストにこの一致を見つけた結果として、参加IMサーバーは、ユーザBが阻止リストにあることを指示するように制御IMサーバーからのSIP NOTIFYメッセージを変更し、そしてその変更されたSIP NOTIFYメッセージをステップS42においてユーザAへ送信する。ステップS42で送信される変更されたSIP NOTIFYメッセージは、本発明の第1の実施形態について上述したものと同じである。チャットルームへの他の参加者であって、阻止リストに一致する参加ユーザをもたない参加者には、通常の、変更されないSIP NOTIFYメッセージが送信される。
変更されたNOTIFYメッセージを受け取ると、ユーザAは、チャットルームに留まるがユーザBからのテキストを見ないか、ユーザBのテキストを一時的に見るのを許すように自分の阻止リストを更新するか、或いはユーザAがチャットルームに加わらずに立ち去るよう選択するかの選択肢を有する。ユーザAがチャットルームに留まるがユーザBからのテキストを見ないように選択する場合には、参加IMサーバーは、ユーザBのテキストのフィルタリングを遂行することができる。チャットルーム内の他の全ての参加者は、ユーザBのテキストを見ることができる。他の参加者は、ユーザAがユーザBのメッセージをフィルタリングしたことを知らない。阻止されたユーザの通知は、一度しか行なわれず、その後、メッセージは全ての参加者に送信される。しかしながら、参加IMサーバーは、上述したように、メッセージの更なるフィルタリングを任意に遂行してもよい。
ユーザBが、新たに加わるユーザとして、既に参加しているユーザのいずれかを自分の阻止リストに有する場合(例えば、ユーザBがユーザAをその阻止リストに有する場合)には、ユーザBに、上述したように、変更されたNOTIFYメッセージが送信され、そして上述したユーザAと同じ3つの選択肢を有することになる。しかしながら、ここに示す例では、ユーザBは、他の参加者のいずれも自分の阻止リストに有しておらず、それ故、S43において、変更されないNOTIFYメッセージが送信される。
本発明の第3の実施形態のネットワーク構造800が示された図8を参照する。このシナリオには、第1及び第2の実施形態に示された同じ3つのユーザ、即ちユーザA202、ユーザB204及びユーザC206が存在する。第1及び第2の実施形態と同様に、ユーザCは、チャットルームを生成し、そしてユーザA及びユーザBを招待する。しかしながら、ユーザBは、ユーザAの阻止リストに存在する。本発明の第3の実施形態では、ユーザターミナルは、IMクライアント804及びユーザインターフェイス(UI)806を備えている(この場合は、ユーザAについて示すだけである)。このネットワーク構造は、会議サーバー802を備えているが、これは、第1及び第2の実施形態の場合と同じ機能を全て遂行するものではない。特に、参加者の阻止リストは、IMクライアントにローカルに記憶されている。IMクライアントは、次いで、チャットルームに加わるユーザ又は参加者と阻止リストとの間の比較を行う。
図9は、図8を参照して上述したエンティティ間でのシグナリングメッセージの交換を示す。先の実施形態と共通なことに、ユーザCは、ステップS44において、会議サーバー802へSIP INVITEメッセージを送信することによりチャットセッションを開始する。会議サーバーは、902において、フォーカスインスタンスを生成し、そしてミクサリソースを予約する。次いで、ユーザCは、会議状態通知に契約する。このプロセスは、ステップS45において、会議サーバーとユーザCとの間の通信を含む。
ユーザCは、次いで、ステップS46において、会議サーバーへSIP REFERメッセージを送信し、これは、ユーザA及びユーザBをチャットルームに招待すべきであることを指示する。会議サーバーは、ステップS47及びS48において、ユーザA及びユーザBにSIP INVITEメッセージを各々送信し、これらは、ステップS49及びS50において、ユーザA及びユーザBからの200 OKメッセージで確認される。ユーザA及びユーザBは、ステップS51及びS52において、会議サーバーへ送信されるSIP SUBSCRIBEメッセージでチャットルームに契約する。会議サーバーは、ステップS53及びS55において、ユーザA及びユーザBに対し200 OKメッセージで確認する。その間に、会議サーバーは、ステップS54において、ユーザAがチャットルームに加わったことをユーザCに通知し、そしてS56において、ユーザBに対して同じことを行なう。
本発明のこの実施形態では、チャットルームに加わるユーザと、参加者の阻止リストに載せられたユーザとの比較が会議サーバーにおいて行われない。むしろ、新たなユーザがチャットルームに加わると、SIP NOTIFYメッセージが参加者へ送信される。図9に示す例では、ステップS57において、ユーザAにSIP NOTIFYメッセージが送信される。次いで、ユーザターミナルのIMクライアント804は、チャットルームに加わるユーザを、904において、IMクライアントにローカル記憶された阻止リストと比較する。ユーザAの場合に、IMクライアントは、ユーザBがチャットルームに加わるときに阻止リストにおいて一致を見出す。一致が見つかると、IMクライアントは、ステップS58において、UIを経てユーザに通知する。
ユーザAは、IMクライアントから通知を受け取ると、先の実施形態と同じ選択肢を有する。ユーザAは、チャットルームに留まるがユーザBからのテキストを見ないか、ユーザBのテキストを一時的に見るのを許すように自分の阻止リストを更新するか、或いはユーザAがチャットルームに加わらずに立ち去るよう選択できるかの選択肢を有する。ユーザAがチャットルームに留まるがユーザBからのテキストを見ないように選択する場合には、IMクライアントは、ユーザBのテキストのフィルタリングを遂行する。チャットルーム内の他の全ての参加者は、ユーザBのテキストを見ることができる。他の参加者は、ユーザAがユーザBのメッセージをフィルタリングしたことを知らない。
ユーザBが、新たに加わるユーザとして、既に参加しているユーザのいずれかを自分の阻止リストに有する場合(例えば、ユーザBがユーザAをその阻止リストに有する場合)には、ユーザBのターミナルのIMクライアントが、上述したように、ユーザBに通知し、そしてユーザBは、上述したユーザAと同じ3つの選択肢を有することになる。しかしながら、ここに示す例では、ユーザBは、他の参加者のいずれも自分の阻止リストに有しておらず、それ故、S43においてSIP NOTIFYメッセージが送信された後に、IMクライアントは、一致を見出さず、ユーザBに通知する必要はない。
本発明のこの実施形態は、先の2つの実施形態の場合のように、変更されたSIP通知メッセージを必要としない。これは、参加者に対してローカルであるIMクライアントから通知が到来し、そして送信される通知が、使用されるUIに依存するからである。
以上に述べた3つの実施形態は、チャットルームの創設者が、招待客の好みの詳細を知る必要なく、誰でも参加するよう招待できるという効果を有する。むしろ、チャットルームへの招待客(例えば、ユーザA)には、阻止されたユーザの存在をいかに取り扱うかの選択肢が与えられる。それ故、チャットルームの創設者は、招待客のプライベートな阻止リスト情報の詳細を与える必要がない。更に、他の既知の解決策とは異なり、IMシステムに欠陥が生じるとは思われない。