(57)【要約】  通信グループ内のメンバシップ情報をクライアントが容易に利用できるようにする方法および装置。グループ管理サーバ（２０２Ａ）が、第１のクライアント（Ａ）から、少なくとも第２のクライアント（Ｂ）を含む新規グループのためのグループ創設要求（２．１）を受信する。次いで、グループ内のメンバのリスト（Ｌｉ）が保存され（２．２）、第２のクライアントが新規グループのメンバになったことをネットワークに知らせるため、グループイベント通知（２．３）が第２のクライアントのホームネットワーク（２００Ｂ）へ送信される。その後、クライアントは、自分がどのアクティブ通信グループのメンバなのかを、複雑な検索をしなくても見つけることができる。【特許請求の範囲】
【請求項１】
グループメンバが通信グループ情報を利用できるようにする方法であって、
第１のクライアントの第１のホームネットワーク内の第１のクライアントから、少なくとも第２のクライアントを含む新規グループのためのグループ創設要求を受信する工程と、
前記第２のクライアントを含む前記グループの内のメンバのリストを保存する工程とを備え、
前記第２のクライアントが前記新規グループのメンバであることを宣言するために、前記第１のホームネットワークから少なくとも前記第２のクライアントの第２のホームネットワークへ、グループイベント通知を送信する工程を更に備えることを特徴とする方法。
【請求項２】
前記グループが、異なるホームネットワークに属している複数のメンバを含み、前記グループイベント通知が、前記ネットワークにそれらの各クライアントが前記新規グループのメンバになったことを知らせるために、前記第１のホームネットワークから前記グループ内の前記メンバの前記ホームネットワークへ送信されることを特徴とする請求項１に記載の方法。
【請求項３】
前記メンバリストについて、それが有効であると考えられるＴＴＬ期間（有効期間）が設定され、前記グループが継続される場合には、新たなＴＴＬを持つリフレッシュメッセージを前記リストの中の前記メンバの前記ホームネットワークへ送信する工程によって、前記リストが、ＴＴＬの満了の直前にリフレッシュされることを特徴とする請求項２に記載の方法。
【請求項４】
グループＩＤが、前記グループに割当てられ、前記グループメンバリストと一緒に保存されることを特徴とし、前記グループイベント通知が前記グループＩＤを含むことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記受信し、保存し、送信する工程が、第１のホームネットワーク内のグループ管理サーバによって行われることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記第２のホームネットワーク内のグループ管理サーバが、前記第２のクライアントがそのメンバである複数の通信グループのグループＩＤを備えた、前記第２のクライアント用のグループリストを維持することを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
新規グループが、前記第２のクライアントが前記新規グループのメンバになる場合に、前記グループリストに追加されることを特徴とする請求項６に記載の方法。
【請求項８】
前記第２のクライアントが前記既存のグループからメンバとしては除外されるか、もしくは、前記グループが完全に終了する場合に、既存のグループが前記グループリストから削除されることを特徴とする請求項６または７に記載の方法。
【請求項９】
前記第２のホームネットワーク内の前記グループ管理サーバが、前記第２のクライアントからメンバシップ情報要求の受信に応じて、前記グループリストを有するグループメンバシップ通知を前記第２のクライアントへ送信することを特徴とする請求項６乃至８のいずれか１項に記載の方法。
【請求項１０】
前記第２のホームネットワーク内の前記グループ管理サーバは、前記グループリストが変更される度に、前記第２のクライアントへグループメンバシップ通知を自動的に送信することを特徴とする請求項６乃至９のいずれか１項に記載の方法。
【請求項１１】
新メンバを前記グループに追加するためのグループ修正要求を前記第１のクライアントから受信する工程と、
前記新メンバを前記グループメンバリストに保存する工程と、
前記新メンバが前記グループのメンバになったことを前記新メンバの前記ホームネットワークに知らせるために、前記第１のホームネットワークから前記新メンバの前記ホームネットワークへグループイベント通知を送信する工程と
をさらに備えることを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
あるメンバを前記グループから除外するためのグループ修正要求を前記第１のクライアントから受信する工程と、
前記除外されたメンバを前記グループメンバリストから削除する工程と、
前記除外されたメンバが前記グループから除外されたことを、前記除外されたメンバの前記ホームネットワークに知らせるために、前記第１のホームネットワークから前記除外されたメンバの前記ホームネットワークへ、メンバシップ無効メッセージを送信する工程と
をさらに備えることを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記メンバシップ無効メッセージは、前記ＴＴＬがゼロに設定され、それによって前記除外されたメンバのメンバシップが無効になったことを示すリフレッシュメッセージであることを特徴とする請求項３または１２に記載の方法。
【請求項１４】
前記第２のホームネットワーク内の前記グループ管理サーバによって、
前記グループのメンバシップを拒否するため、離脱しつつあるクライアントからグループ拒否メッセージを受信する工程と、
前記離脱しつつあるクライアント用の前記グループリストから前記拒否されたグループを削除する工程と、
前記離脱しつつあるクライアントが前記グループを離脱したことを宣言するため、前記第１のホームネットワークへメンバシップ拒否メッセージを送信する工程と
が行われることを特徴とする請求項６乃至１０のいずれか１項に記載の方法。
【請求項１５】
グループメンバが通信グループ情報を利用できるようにする装置であって、
第１のクライアントから、少なくとも第２のクライアントを含む新規グループのグループ創設要求を受信し、かつ、前記第２のクライアントを含む前記グループの中で、メンバのリストを保存するように構成されたグループ管理サーバを備えており、
前記グループ管理サーバが、さらに、前記第２のクライアントが前記新規グループのメンバとなったことを宣言するために、グループイベント通知を、第２のクライアントのホームネットワークへ送信するように構成されることを特徴とする装置。
【請求項１６】
前記グループが、異なるホームネットワークに属している複数のメンバを含み、
前記グループ管理サーバが、さらに、前記グループ内の前記メンバの前記ホームネットワークへ、それらの各クライアントが前記新規グループのメンバになったことを宣言するために、前記グループイベント通知を送信するように構成されることを特徴とする請求項１５に記載の装置。
【請求項１７】
前記グループ管理サーバが、前記メンバリストについて、それが有効であると考えられるＴＴＬ期間（有効期間）を設定し、前記グループが継続される場合には、新たなＴＴＬを持つリフレッシュメッセージを前記リストの中の前記メンバの前記ホームネットワークへ送信する工程によって、前記リストをＴＴＬの満了の直前にリフレッシュするように構成されることを特徴とする請求項１６に記載の装置。
【請求項１８】
グループＩＤが、前記グループに割当てられ、前記グループメンバリストと一緒に保存され、
前記グループイベント通知が前記グループＩＤを含むことを特徴とする請求項１５乃至１７のいずれか１項に記載の装置。
【請求項１９】
前記グループ管理サーバが、さらに、第３のクライアントがメンバである複数の通信グループのグループＩＤを含む、第３のクライアント用のグループリストを維持するように構成されることを特徴とする請求項１５乃至１８のいずれか１項に記載の装置。
【請求項２０】
前記グループ管理サーバが、前記第３のクライアントが前記新規グループのメンバになったときには新規グループを前記グループリストに追加するように構成されることを特徴とする請求項１９に記載の装置。
【請求項２１】
前記グループ管理サーバが、さらに、前記第３のクライアントが既存のグループからメンバを除外された場合、もしくは前記グループが完全に終了した場合には、前記既存のグループを前記グループリストから削除するように構成されることを特徴とする請求項１９または２０に記載の装置。
【請求項２２】
前記グループ管理サーバが、さらに、メンバシップ情報要求を前記第３のクライアントから受信する工程に応じて、前記グループリストを含むグループメンバシップ通知を前記第３のクライアントへ送信するように構成されることを特徴とする請求項１９乃至２１のいずれか１項に記載の装置。
【請求項２３】
前記グループ管理サーバが、さらに、前記グループリストが変更される度に、前記グループリストを含むグループメンバシップ通知を前記第３のクライアントへ自動的に送信するように構成されることを特徴とする請求項１９乃至２２のいずれか１項に記載の装置。
【請求項２４】
前記グループ管理サーバが、さらに、新メンバを前記グループに追加するため、グループ修正要求を前記第１のクライアントから受信し、前記グループメンバリストに前記新メンバを保存し、そして、新メンバが前記グループのメンバになったことを宣言するため、グループイベント通知を前記新メンバの前記ホームネットワークへ送信するように構成されることを特徴とする請求項１５乃至２３のいずれか１項に記載の装置。
【請求項２５】
前記グループ管理サーバが、さらに、メンバを前記グループから除外するためのグループ修正要求を前記第１のクライアントから受信し、前記除外されたメンバを前記グループメンバリストから削除し、除外されたメンバが前記グループから除外されたことを宣言するために、メンバシップ無効メッセージを前記除外されたメンバの前記ホームネットワークへ送信するように構成されることを特徴とする請求項１５乃至２４のいずれか１項に記載の装置。
【請求項２６】
前記メンバシップ無効メッセージは、前記ＴＴＬがゼロに設定された状態のリフレッシュメッセージであって、それによって、前記除外されたメンバのメンバシップが無効になることを表示することを特徴とする請求項１７または２５に記載の装置。
【請求項２７】
前記グループ管理サーバが、さらに、離脱しつつあるクライアントから、前記グループ内のメンバシップを拒否するため、グループ拒否メッセージを受信し、拒否されたグループを、前記離脱しつつあるクライアント用のグループリストから削除し、前記離脱しつつあるクライアントが前記グループから離脱したということを宣言するため、メンバシップ拒否メッセージを前記離脱しつつあるクライアントのホームネットワークへ送信するように構成されることを特徴とする請求項１５乃至２６のいずれか１項に記載の装置。
【請求項２８】
グループメンバが通信グループ情報を利用できるようにする通信システムであって、
第１のクライアントのホームネットワーク内の第１のグループ管理サーバと、
第２のクライアントのホームネットワーク内の第２のグループ管理サーバとを備え、
前記第１のグループ管理サーバが、前記第１のクライアントから、少なくとも前記第２のクライアントを含む新規グループのためのグループ創設要求を受信し、そして、前記第２のクライアントを含む前記グループの中で、メンバのリストを保存するように構成され、
前記第１のグループ管理サーバは、さらに、前記第２のクライアントが前記新規グループのメンバになったことを宣言するため、グループイベント通知を前記第２のグループ管理サーバへ送信するように構成され、
第２のグループ管理サーバは、前記第２のクライアントがメンバである複数の通信グループのグループＩＤを備えた、前記第２のクライアント用のグループリストを維持し、前記グループイベント通知を受信する工程に応じて、前記グループリストに前記新規グループを追加するように構成されることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、クライアントに通信グループ情報を提供する方法および装置に関するものである。詳細には、本発明は、アクティブな通信グループに関する情報の検索を、より簡単でより効率的にすることを目的としている。
【背景技術】
【０００２】
最近まで、移動通信端末は、音声通話の利用およびＳＭＳ（ショート・メッセージ・サービス）のような、限定的なテキストメッセージの通信に主に使用されてきた。これらは、主に回路交換による単一接続のための十分に確立した技術を用いる、非常に単純明快な通信サービスである。
【０００３】
しかし、多数の新しい電話サービスが今や急速に開発されており、それらは、ネットワーク容量の増大と伝送速度の高速化をもたらす新しい通信技術の導入によって可能となるものである。例えば、現在、ＧＰＲＳ（汎用パケット無線サービス）技術およびＷＣＤＭＡ（広帯域符号分割多元接続）技術が出現し、広範囲のデータ速度や異なるプロトコルを必要とする無線電話サービスをサポートしている。また現在の傾向として、より大容量とフレキシビリティを提供するパケット交換トランスポートへの流れがある。さらには、高解像度のカラーディスプレイや視覚情報を通信するための各種のコーデック（コーダ／デコーダ）を備えた、新しい高機能端末も市場に現れている。
【０００４】
動画情報および音声情報のリアルタイム送信を必要とするサービスもあり、さらに、多数の異なるフォーマットや組み合わせを含む画像、テキスト、文書、音声ファイル、画像ファイルを表すデータの送信を含むこともある。そのようなサービスは一般に「マルチメディア」サービスと呼ばれるが、その用語は、本明細書においては、普通の音声通話に加えて情報の転送を伴うようなあらゆる電話サービスを表すのに用いるであろう。
【０００５】
通信分野において現時点で有力な目標または抱負は、サービスのタイプ、アクセスネットワーク、技術に関わらず、すべてのサービスを単一のトランスポートメカニズムであるインターネットプロトコル（ＩＰ）に集中させることである。最近、「ＩＰマルチメディア・サブシステム」（ＩＭＳ）と呼ばれるサービスネットワーク・アーキテクチャが、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によってオープンスタンダードとして開発され、アクセスネットワークのオペレータにパケットドメインでマルチメディアサービスを提供する能力を提供している。
【０００６】
サービスを取り扱う各種の多様なネットワーク要素を含むＩＭＳネットワークは、アクセスネットワークが帯域幅、ＱｏＳ（サービス品質）などに関してサービス要件に合致する限り、いかなるタイプのアクセスネットワークと統合されてもよく、使用されるアクセス技術に依存しない。従って、ＩＭＳは、一部の特定の組のサービスに限定されず、ＩＰトランスポートに基づくサービスを可能にするプラットフォームである。「セッション開始プロトコル」（ＳＩＰ）と呼ばれる通信プロトコルが、ＩＥＴＦ（インターネット・エンジニアリング・タスクフォース）によって、広範なＩＰベースのサービスをサポートする一般的なセッション管理プロトコルとして定義された。ＳＩＰは、１人以上の参加者の通信セッションを開始し、修正し、終了するための純粋な信号プロトコルである。
【０００７】
例えばＩＭＳソリューションによって採用可能な一部のサービスは、「友達リスト」と呼ばれることもある、複数の参加者のグループ内の通信に関係する。クライアントは、グループに含めることになるメンバを選択することによって、そして、そのグループ内のメンバ間での何らかのタイプの通信のためのサービスを呼び出すことによって、グループを創設できる。サービスが呼び出され、グループが創設されると、通信がどのように行われるべきかを判断するため、一定の通信規則も定義される。サービスは、１つ以上のアプリケーションが、サービスネットワーク内で起動されることを必要とする。
【０００８】
例えば、音声チャットグループが創設されてもよいし、また、通信形態は、ＩＭＳコンセプトＰＯＣ（プッシュトゥトーク・オーバ・セルラー）のような、いわゆる「プッシュトゥトーク」メカニズムにすると判断されてもよい。グループ内のメンバは、次いで、自分の移動端末上の何らかのキーまたはキーの組み合わせを押して、自分が何か言いたいときにはいつでもグループ内の他の各メンバへの一方向の音声パスを起動でき、それは半二重と呼ばれることもある。別の例では、グループメンバを含む電子ゲームをリアルタイムで行うため、ゲームグループが創設されてもよい。さらに別の例では、テキストメッセージ、文書、または画像が、グループ内で交換されてもよいし、全二重での音声パスを用いた電話会議が行われてもよい。
【０００９】
図１は、先行技術に従って通信グループを創設するための通信シナリオを図解する。第１の移動クライアント「Ａ」は、例えばそのネットワークへの加入によって、ＩＭＳネットワークによって通信グループサービスを提供できるような、ホームネットワーク１００に属している。各種サービスが起動されるとき通信セッションを処理するため、サービス・コア（図示していない）、この場合ＩＭＳコアが、ネットワーク１００内に実装されていることが想定されている。
【００１０】
特にネットワーク１００は、具体的な通信グループ内のアクティブなサービスやアクティブなクライアント用のアプリケーション構成データを維持するための、サーバ１０２またはそれに似たものを含む。本明細書においては、この文脈におけるその機能に着目して、このサーバを「グループ管理サーバ」１０２と呼ぶ。このＩＭＳの場合、サーバ１０２は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ）フォーマット、および／または「ＸＤＭＳ」（ＸＭＬデータ管理サーバ）の中に保存された構成データを処理する、「ＸＣＡＰ」（ＸＭＬ構成アクセスプロトコル）サーバを含んでもよい。ネットワーク１００は、さらに、クライアントに具体的なサービスを提供するのに必要な、多様なアプリケーションを操作するための、複数のアプリケーションサーバ１０４を含み、そのうち、１つだけを図示する。この場合、アプリケーションサーバ１０４は、クライアントＡのためのグループサービスを処理するよう構成されている。
【００１１】
クライアントＡは、音声チャットを用いて、別の移動ネットワーク１０６に属する第２のクライアント「Ｂ」、および、図の中で点線で示されるように、他のホームネットワークに属する任意の数のさらなるクライアントＣ、Ｄ…を含めて、選択されたメンバと討論グループを創設したいと考えている。クライアントＡ、Ｂ、Ｃ、Ｄは必ずしも彼らの各々のホームネットワークをアクセスネットワークとして用いる必要はなく、他のネットワーク内でローミングしていてもよいだろう。さらには、クライアントＡ、Ｂ、Ｃ、Ｄのうちの一部は、同じホームネットワークなどに属していてもよい。
【００１２】
クライアントＡ、Ｂ、Ｃ、Ｄを含むチャットグループをネットワーク１００と共に構築するため、クライアントＡが、最初に、グループ設立要求１０８を、ネットワーク１００内のグループ管理サーバ１０２へ送信する。このメッセージ１０８は、一般に、各メンバのＩＤとネットワークアドレスと、呼び出されたサービスの表示とを含む。それに応じて、そのグループ用のグループＩＤが定義されるが、それは、ＨＳＳ（ホーム加入者サーバ）のような、ホームネットワーク１００内の図示しない加入者管理サーバのようなものによって構成されてもよい。グループＩＤは通常、グループを扱っているネットワーク資源にコンタクトするためにグループメンバによって使用されることになるネットワークアドレスである。例えば、グループが会議グループである場合、グループＩＤは、使用されるカンフェレンス・ブリッジのネットワークアドレスであろう。さらに、呼び出されたサービスは、関連するアプリケーションサーバ１０４において、一定のアプリケーションが起動されることを必要とする。従って、定義されたグループＩＤは、クライアントＡのために呼び出されたサービスを処理するための、特定のアプリケーションサーバ１０４を指し示すであろう。
【００１３】
ＩＭＳの文脈において、グループ設立要求１０８は、ＸＭＬデータベース内の正確な位置にグループを保存するのに使用される、特定のアドレスフィールドを持つＸＣＡＰメッセージである。さらに、グループＩＤはＰＳＩ（Ｐｕｂｌｉｃ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）であり、通常はＳＩＰ  ＵＲＩ（Ｕｎｉｆｉｅｄ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）である。
【００１４】
グループＩＤ、この場合ＰＳＩは、こうしてメンバリストＬ１によって概略的に表されるように、呼び出されたサービスに従って、グループメンバＩＤのリストおよび関連するアプリケーション構成データ（ＸＭＬフォーマットで）と共に、グループ管理サーバ１０２の中に保存される。上記のプロトコルＸＣＡＰによって、グループが存在するときにはいつでも、クライアントＡは、アプリケーション構成データを読み取り、書き込み、修正することができる。特に、クライアントＡは、新メンバをグループに追加することや、メンバをグループから除外することや、グループ全体を終了させることができる。
【００１５】
次いで、グループが設立された後、任意のメンバがグループサービスを起動することによって、グループ内の他のメンバ全員に情報、例えば音声を通信してもよい。ＩＭＳサービスでは、使用された端末はその後、まず自分が他者へ情報を送信したいときにはいつでも、ＳＩＰ  ＩＮＶＩＴＥ（ＰＳＩ）、または「ＩＮＶＩＴＥ  ＰＳＩ」と呼ばれるメッセージを、各メンバへの通信パスを確立するため、ＩＭＳネットワークへ発行するであろう。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
現時点では、グループに選択されたメンバに対して、彼らが創設されたグループのメンバになった事実を通知する自動メカニズムが存在しないことが問題である。従って、例えば電話をかけたり、電子メールやＳＭＳやそのようなものを各メンバに送信したりすることによって、他のクライアントに彼らのメンバシップを通知するのは、グループの創設者、すなわちクライアントＡの責任である。多くのメンバがグループに含まれている場合、これは厄介な仕事であろう。この情報が失われることもあるし、他者によって傍受される潜在的リスクもある。
【００１７】
もう１つの問題は、他のクライアントも選択されたメンバと共に自分達のグループを同様に創設する可能性があるため、また、対応するグループリストがそれぞれ、その創設者のホームＩＭＳネットワーク内に保存されるであろうから、特定のクライアントが複数のグループリスト内に存在し、それぞれが、グループの創設者によって異なるノードとネットワークとにローカルに保存された状態になることである。結果として、複数のグループに参加するとき、移動ユーザにとってはアクティブな通信グループを追跡することがますます難しくなる。従って、ユーザが、あるグループのメンバであることに気がつかないこともありうる。
【００１８】
そのうえ、グループが終了したことをメンバに知らせる自動メカニズムもないため、この場合もやはりグループ創設者は、この事実を彼らに通知しなければならない。基本的に、創設されたグループは、その創設者がグループを終了させるまで存在するであろう。
【００１９】
例えば、クライアントが、望まないグループのメンバシップを拒否したいかもしれないし、単純に、自分がどのグループのメンバであるか調べたいかもしれない。現在、グループのメンバシップの検索に利用できる唯一の方法は、各ネットワーク内の検索を実行することであるが、この方法は煩雑で信頼性に欠けており、複数のネットワークが探索された場合、多量のネットワークトラヒックを生成する。従って、自分がメンバとなっているのはどのアクティブな通信グループであるかをクライアントが容易に発見できるようにするため、グループのメンバシップに関する情報をクライアントに入手させる、単純かつ信頼性のあるソリューションが必要である。
【課題を解決するための手段】
【００２０】
本発明の目的は、上記で概説した問題を軽減または除去することである。特に、自分が現時点でメンバとなっているのはどのグループであるかをクライアントが発見できるようにするため、アクティブな通信グループ内のメンバシップ情報の検索または受信を可能にすることが、１つの目的である。
【００２１】
通信グループ情報をグループメンバが利用できるようにする方法および構成によって、この目的およびその他のことが可能になる。少なくとも１人の第２のクライアントを含む新規グループについてのグループ創設要求が、第１のクライアントの第１のホームネットワーク内の第１のクライアントから受信され、第２のクライアントを含むグループ内のメンバのリストが保存される。グループイベント通知が、第１のホームネットワークから、少なくとも、第２のクライアントの第２のホームネットワークへ送信され、第２のクライアントが新規グループのメンバであることが宣言される。グループが、さまざまなホームネットワークに属する複数のメンバを含む場合、グループイベント通知が、第１のホームネットワークから、そのグループ内のメンバのホームネットワークへ送信され、それらの各々のクライアントが新規グループのメンバになったことを前記ネットワークに知らせる。
【００２２】
メンバリストには、できれば、メンバリストが有効であると考えられるＴＴＬ期間（有効期間）が設定されることが望ましい。そしてその後、グループが継続される場合には、リストにあるメンバのホームネットワークに新規ＴＴＬを持つリフレッシュメッセージを送信することによって、ＴＴＬの満了の直前にリストがリフレッシュされる。
【００２３】
前記グループメンバリストと一緒に保存されるグループＩＤが、そのグループに割当てられる場合、グループイベント通知はグループＩＤを含むであろう。
【００２４】
受信、保存、送信の各ステップはできれば、第１のホームネットワーク内のグループ管理サーバによって実行されることが望ましい。さらに、第２のホームネットワーク内のグループ管理サーバは、できれば、第２のクライアントがメンバとなっている複数の通信グループのグループＩＤを含む、第２のクライアント用のグループリストを維持することが望ましい。第２のクライアントが前記新規グループのメンバになる場合、新規グループがグループリストに追加される。他方、第２のクライアントが既存のグループからメンバを除外されるか、もしくはグループが完全に終了される場合には、前記既存のグループはグループリストから削除される。
【００２５】
第２のホームネットワーク内のグループ管理サーバは、第２のクライアントからメンバシップ情報要求を受信するのに応じて、前記グループリストを含むグループメンバシップ通知を第２のクライアントへ送信してもよい。第２のホームネットワーク内のグループ管理サーバも、前記グループリストが変更される度に、自動的にグループメンバシップ通知を第２のクライアントへ送信してもよい。
【００２６】
一実施形態によれば、新メンバをグループに追加するため、第１のクライアントからグループ修正要求が受信されてもよい。新メンバは、次いで、前記グループメンバリストに保存され、そして、新メンバがグループのメンバになったことを新メンバの前記ホームネットワークに通知するため、第１のホームネットワークから新メンバのホームネットワークへグループイベント通知が送信される。
【００２７】
別の実施形態によれば、メンバをグループから除外するため、グループ修正要求が第１のクライアントから受信されてもよい。除外されたメンバは、次いで、前記グループメンバリストから削除され、除外されたメンバがグループから除外されたことを除外されたメンバの前記ホームネットワークに知らせるために、メンバシップ無効メッセージが、第１のホームネットワークから除外されたメンバのホームネットワークへ送信される。メンバシップ無効メッセージは、ＴＴＬがゼロに設定された状態のリフレッシュメッセージであってもよく、それによって、除外されたメンバのメンバシップが無効になることを表示する。
【００２８】
さらに別の実施形態によると、第２のホームネットワーク内のグループ管理サーバが、グループ内のメンバシップを拒否するため、離脱しつつあるクライアントからのグループ拒否メッセージを受信してもよい。その場合、拒否されたグループは、離脱しつつあるクライアント用のグループリストから削除され、そして、メンバシップ拒否メッセージが第１のホームネットワークへ送信され、離脱しつつあるクライアントがグループから離脱したということを宣言する。
【００２９】
本発明はさらに、少なくとも第２のクライアントを含む新規グループのグループ創設要求を第１のクライアントから受信するように構成され、そして、第２のクライアントを含めたメンバリストをグループ内に保存するように構成されたグループ管理サーバを含めて、グループメンバが通信グループ情報を利用できるようにする構成を含む。グループ管理サーバは、さらに、グループイベント通知を第２のクライアントのホームネットワークへ送信し、第２のクライアントが新規グループのメンバになったことを宣言するように構成される。
【００３０】
グループが、さまざまなホームネットワークに属している複数のメンバを含む場合、グループ管理サーバは、さらに、グループイベント通知をそのグループ内のメンバのホームネットワークへ送信し、それらの各クライアントが新規グループのメンバになったことを宣言するように構成される。
【００３１】
グループ管理サーバは、できればさらに、メンバリストにはメンバリストが有効であると考えられるＴＴＬ期間（有効期間）を設定し、グループが継続される場合には、リストにあるメンバのホームネットワークに新規ＴＴＬを持つリフレッシュメッセージを送信することによって、ＴＴＬの満了の直前にリストをリフレッシュするように構成されることが望ましい。
【００３２】
グループＩＤがグループに割当てられ、前記グループ・メンバ・リストと一緒に保存される場合、グループイベント通知はグループＩＤを含むであろう。
【００３３】
グループ管理サーバは、さらに、第３のクライアントがメンバである複数の通信グループのグループＩＤを含む、第３のクライアント用のグループリストを維持するように構成されてもよい。グループ管理サーバはまた、第３のクライアントが新規グループのメンバになったときには前記新規グループをグループリストに追加し、また、第３のクライアントが既存のグループからメンバを除外された場合、もしくはグループが完全に終了した場合には、前記既存のグループを削除するように構成されてもよい。
【００３４】
グループ管理サーバは、さらに、メンバシップ情報要求を第３のクライアントから受信することに応じて、前記グループリストを含むグループメンバシップ通知を第３のクライアントへ送信するように構成されてもよい。グループ管理サーバは、また、前記グループリストが変更される度に、前記グループリストを含むグループメンバシップ通知を第３のクライアントへ自動的に送信するように構成されてもよい。
【００３５】
さらなる実施形態によると、グループ管理サーバは、さらに、新メンバをグループに追加するため、グループ修正要求を第１のクライアントから受信し、前記グループメンバリストに新メンバを保存し、そして、新メンバがグループのメンバになったことを宣言するため、グループイベント通知を新メンバのホームネットワークへ送信するように構成されてもよい。
【００３６】
グループ管理サーバは、さらに、グループからメンバを除外するため、グループ修正要求を第１のクライアントから受信し、前記グループメンバリストから除外されたメンバを削除し、そして、除外されたメンバがグループから除外されたことを宣言するため、メンバシップ無効メッセージを除外されたメンバのホームネットワークへ送信するように構成されてもよい。メンバシップ無効メッセージは、できれば、ＴＴＬがゼロに設定された状態のリフレッシュメッセージであって、それによって、除外されたメンバのメンバシップが無効になったことを示すことが望ましい。
【００３７】
グループ管理サーバは、さらに、グループのメンバシップを拒否するため、離脱しつつあるクライアントからグループ拒否メッセージを受信し、離脱しつつあるクライアント用のグループリストから拒否されたグループを削除し、そして、離脱しつつあるクライアントがグループを離脱したことを宣言するため、離脱しつつあるクライアントのホームネットワークへメンバシップ拒否メッセージを送信するように構成されてもよい。
【００３８】
本発明はさらに、通信グループ情報がグループメンバに利用できるようにする通信システムを含んでおり、通信システムは、第１のクライアントのホームネットワーク内の第１のグループ管理サーバ、および、第２のクライアントのホームネットワーク内の第２のグループ管理サーバを含む。第１のグループ管理サーバは、少なくとも第２のクライアントを含む新規グループのためのグループ創設要求を第１のクライアントから受信し、第２のクライアントを含むグループのメンバのリストを保存するように構成される。第１のグループ管理サーバは、さらに、第２のクライアントが新規グループのメンバになったことを宣言するため、グループイベント通知を第２のグループ管理サーバへ送信するように構成される。第２のグループ管理サーバは、第２のクライアントがメンバである複数の通信グループのグループＩＤを含む、第２のクライアント用のグループリストを維持し、そして、前記グループイベント通知を受信することに応じて、新規グループをグループリストに追加するように構成される。
【００３９】
本発明のさらなる特徴と利点は、下記の詳細説明から明らかになるであろう。
【００４０】
次に、本発明について、好適実施形態によって、また、添付の図面を参照しながら、さらに詳細に説明する。
【発明を実施するための最良の形態】
【００４１】
留意すべきことだが、本発明は、どのタイプの通信サービスが用いられているかに関係なく、通信グループのメンバシップの管理に関するものである。それゆえ、本発明を理解するのに、グループサービス自体がどのように呼び出されるかもしくは使用されるかという説明は不要であり、従って、下記の詳細説明は、サービスそれ自体ではなく、グループのメンバシップに焦点を当てるであろう。
【００４２】
次に、本発明の好適実施形態について、最初に図２を参照しながら説明しよう。図に示すブロック図は、点線で表した中央の境界線によって論理的に２つの領域に分かれており、第１のクライアントＡのホームネットワーク領域２００Ａを左側に、第２のクライアントＢのホームネットワーク領域２００Ｂを右側に示す。図１のように、クライアントＡのホームネットワークは、通信グループの創設に関するサービスをそのクライアントに提供することができる。各ネットワーク領域２００Ａおよび２００Ｂは、それぞれ、グループ管理サーバ２０２Ａおよび２０２Ｂと、アプリケーションサーバ２０４Ａおよび２０４Ｂとを含む。グループ管理サーバ２０２Ａおよび２０２Ｂは互いに類似していてもよいであろうが、下記の説明から明らかなように、本ソリューションの文脈においては、それらは異なる動作をするであろう。従って、下記の機能に加えて、サーバ２０２Ａは、さらに、サーバ２０２Ｂと同じ機能を持つように構成されてもよく、逆も同様である。本発明は、一般に、サーバ２０２Ａおよび２０２Ｂが本ソリューションの基本的なステップを実行できる限り、特定のタイプのサーバ２０２Ａおよび２０２Ｂには限定されない。
【００４３】
上記で説明した既知の手順などで、クライアントＡは、例えば上記の何かの種類のグループサービスを用いて通信グループを確立しようとする。グループには、クライアントＢも含めて、クライアントＡが選択したメンバが含まれる。これまでの例と同様、クライアントＡおよびＢは、彼らのホームネットワーク以外のネットワークに同時に接続することもできるであろうが、もちろん、下記のとおり、彼らのホームネットワークともやはり通信できる。本ソリューションを理解する目的においては、この通信の詳細なメカニズムを説明する必要はない。
【００４４】
まず第１に、ステップ２．１において、クライアントＡが、ネットワーク２００Ａ内のグループ管理サーバ２０２Ａに対して、グループ内の選択された各メンバについてのＩＤおよびネットワークアドレスに関する情報と、呼び出されたサービスの表示とを含む、グループ創設要求を送信する。またグループ創設要求は、クライアントＡが任意で定義する自由な文章のかたちをしたグループ名を含んでもよく、これ以降、それを一般に「グループ名」と呼ぶことにするが、グループ名は、例えば、ニックネーム、説明、グループのタイプなどでもよく、例えば「Ａのサッカーチーム」であってもよい。さらにグループ創設要求は、例えば「ｓｉｐ：ｍｙｔｅａｍ＠ｌｅａｇｕｅ．ｃｏｍ」のようなネットワークアドレス形式のグループＩＤの提案を含む。次いで、サーバ２０２Ａは、例えば提案されたＩＤのようなＩＤをグループに割当てる。提案されたグループＩＤが占有されているか、何らかの理由で無効である場合、ネットワークは、提案されたグループＩＤを拒否し、別のＩＤを任意で提案するであろう。割当てられたグループＩＤ（および、もし受信するならばグループ名）は、その後、次のステップ２．２によって図解されるように、受信した全メンバのＩＤ／アドレスデータおよび呼び出されたサービスに関する構成データと一緒に、メンバリストＬ１内に保存される。これまでのところ、この手順は、図１に関して説明した既知の先行技術と基本的に同じである。
【００４５】
本ソリューションによると、サーバ２０２Ａは、さらに、ステップ２．３において、クライアントＢがメンバとして含まれるグループが創設されたことを宣言するために、「グループイベント通知」をクライアントＢのネットワーク２００Ｂ内のグループ管理サーバ２０２Ｂへ送信する。この通知は、イベントタイプ（例えば「グループメンバの追加」）、グループのＩＤ、例えばＰＳＩを含み、そしてできれば、上記のように受信したグループ名も含むことが望ましい。ＩＭＳネットワークが用いられる場合、グループイベント通知は、できればステップ２．３において、「ＳＩＰ  ＰＵＢＬＩＳＨ」と呼ばれるＳＩＰ公開メッセージとして送信されることが望ましい。
【００４６】
好適実施形態において、このメッセージは、クライアントＢのネットワークアドレスに向けられ、ネットワーク２００Ｂ（例えばＳＩＰネットワーク）は、イベントタイプとクライアントＢのアドレス（ＵＲＩ）の組み合わせを受信したとき、メッセージをクライアントＢの代わりにサーバ２０２Ｂへルーティングするよう構成される。そうすれば、サーバ２０２Ａは、サーバ２０２Ｂのアドレス（ＵＲＩ）を検索する必要がない。
【００４７】
事実、サーバ２０２Ａはまた、ステップ２．４で点線の矢印で概略的に図解するように、図示していないが、グループ内の選択された他のメンバのホーム領域にある、対応するグループ管理サーバへグループ通知を送信する。加えて、割当てられたグループＩＤ、例えばＰＳＩも、クライアントＡへ送信（図示されていない）されてもよい。クライアントＡは、メンバの追加や除外といったグループへの何らかの修正を行うために、それを参照として使用するであろう。
【００４８】
他方、ネットワーク２００Ｂ内のグループ管理サーバ２０２Ｂは、受信したグループＩＤ（および、受信した場合には、グループ名も）をステップ２．５で保存する。同様に、ステップ２．６で点線の矢印で概略的に図解するように、サーバ２０２Ｂは、クライアントＢがメンバとして含まれているグループが設立されるたびに、さらなる同様なグループ通知を、図示していないが、他のネットワーク内の他の対応するグループ管理サーバから、可能性の上では受信してもよい。そのようなグループ通知が受信されたとき、サーバ２０２Ｂは、付随するグループＩＤ（例えばＰＳＩ）を、この特定のクライアントＢのためのグループリストＬ２に保存する。クライアントＢのためのグループリストＬ２は、こうして時間と共に蓄積され、可能性の上では、各種のネットワーク内のグループ管理サーバから受信する複数のグループＩＤ（および対応するグループ名）を含んでもよい。
【００４９】
それによって、特定のクライアント、この場合Ｂであるが、そのクライアントについてのアクティブ・グループ・メンバシップに関する情報が、クライアントによって容易にアクセスされうる、サーバ２０２Ｂ内の１つの位置で集められる。従って、最後にステップ２．７によって、クライアントＢが、サーバ２０２Ｂへの適切なメンバシップ情報要求（例えば「ＧＥＴ  ＰＳＩ'ｓ」）を行うことによって、この情報をグループリストＬ２から取ってくることが図解される。実際には、リストＬ１およびＬ２は、適切であればいかなる方法で保存され維持されてもよく、例えば各サーバ内の記憶装置の中でもよいし、別個のデータベース・ノードの中でもよい。本発明は、このように、この点で限定されてはいない。
【００５０】
さらに、創設されたグループのメンバリストＬ１について、リストが有効であると考えられる限定された期間、例えばＴＴＬ（有効期間）が設定されてもよい。リストを取り扱っているグループ管理サーバが、ＴＴＬの満了の直前にリストを「リフレッシュ」するように構成されてもよいし、あるいは、グループが継続される場合には、変更がない場合でも、新たなＴＴＬを持つリフレッシュメッセージを定期的に（例えば週に一度）リストのメンバ全員に送信することによって、もしくは彼らのそれぞれのホームネットワークへ送信することによって、リストを「リフレッシュ」するように構成されてもよい。
【００５１】
一般にクライアントは、ホームネットワーク内のローカルなグループ管理サーバから、有効なグループリストをいつでも入手できる。さらにはクライアント、例えばクライアントＢが、自分のグループリスト上で不要なグループが発生することがあるが、適切な拒否メッセージをローカルなホームサーバ、例えばサーバ２０２Ｂへ送信することによって、その不要なグループのメンバシップを拒否することも可能である（下記に詳細を記述する）。拒否メッセージは、次いで、拒否されたグループが維持されるグループ管理サーバ、例えばサーバ２０２Ａへ通信され、そこで、離脱しつつあるクライアントは、グループのメンバリスト、例えばリストＬ１から削除されるであろう。オプションで、離脱しつつあるクライアントＢは、サーバ２０２Ａに関する宛先情報をローカルサーバ２０２Ｂから検索してもよく、サーバ２０２Ａに関する宛先情報は、拒否メッセージを直接サーバ２０２Ａに通信するのに使うことができる。
【００５２】
図２に、新規通信グループが創設されるときにメンバシップ情報が容易に入手できるようにする手順を図解した。上記のとおり、クライアントは、一定のグループのメンバであることを認識していないことがある。従って、いつでもクライアントＢは、自分がどのグループのメンバなのかを正確に知るために、適切なメンバシップ情報要求メッセージをグループ管理サーバ２０２Ｂへ送信することに応じてグループメンバシップ通知を受信することによって、グループリストＬ２をサーバ２０２Ｂから検索できる。別の実施形態によると、グループメンバシップ通知は、自分が通信グループのメンバになったらすぐにサーバ２０２ＢからクライアントＢへ自動的に送信されてもよいし、あるいはもっと一般的に、自分のグループリストが何らかの形で変更される度に送信されてもよい。従ってクライアントは、例えばＳＩＰメッセージ「ＳＩＰ  ＳＵＢＳＣＲＩＢＥ」によって、（ｅｖｅｎｔ＝ＳＩＰ−ｐｒｏｆｉｌｅ）のようなイベントに加入し、発生しているグループ・メンバシップ・イベントについての通知を自動的に受信してもよい。
【００５３】
同様にクライアントＡも、上記によって創設された、すでに存在しているメンバリストＬ１を、例えば新メンバＸをグループに追加することによって修正してもよく、それについては図３に示すブロック図に図解されている。この図において、対応する要素は図２と同じ参照番号を振ってあるが、ただし、「Ｂ］は「Ｘ」に変えてある。
【００５４】
クライアントＡは、最初にステップ３．１において、グループＩＤ（例えばＰＳＩ）およびクライアントＸをグループに追加するという指示を含むグループ修正要求を、自分のＩＤおよびネットワークアドレスを含めて、グループ管理サーバ２０２Ａへ送信する。それに応じて、サーバ２０２Ａは、ステップ３．２において、クライアントＸをグループのメンバリストＬ１に追加する。サーバ２０２Ａは、さらに、ステップ３．３において、クライアントＸが現在はグループのメンバであることを宣言するために、イベントタイプ（例えば「グループメンバの追加」）と、グループＩＤ（例えばＰＳＩ）と、任意で関連するグループ名とを含むグループイベント通知（例えばＳＩＰ  ＰＵＢＬＩＳＨ）を、グループ管理サーバ２０２Ｘへ送信する。ステップ３．３で送信されるメッセージは、前の例においてステップ２．３で送信されるメッセージと基本的に同じである。
【００５５】
現在の例において、グループ管理サーバ２０２Ｘは、クライアントＸが現在メンバである１つ以上のグループを含むグループリストＬ２を、クライアントＸに代わって維持すると想定されている。ステップ３．３においてグループイベント通知を受信するのに応じて、サーバ２０２Ｘは、ステップ３．４において、クライアントＡが保有する新規グループを含むエントリ３００をリストに追加する。それによって、クライアントＸは、ステップ３．５に図解するように、いつでもサーバ２０２Ｘからリストを取って来ることができ、自分がクライアントＡのグループのメンバになったことを知ることができる。
【００５６】
同様に、クライアントＡは、また、メンバリスト内のメンバをグループから除外することによって、グループについてのメンバリストＬ１を修正してもよく、それを図４のブロック図に図解する。この図においても、対応する要素は図２と同じ参照番号を振ってある。
【００５７】
クライアントＡは、最初にステップ４．１において、グループＩＤ（例えばＰＳＩ）と、クライアントＢをグループから除外するという指示とを含むグループ修正要求を、グループ管理サーバ２０２Ａへ送信する。それに応じて、サーバ２０２Ａは、ステップ４．２において、クライアントＢをメンバリストＬ１から削除する。サーバ２０２Ａは、また、ステップ４．３において、クライアントＢはもはやグループのメンバではないことを宣言するため、メンバシップ無効メッセージをサーバ２０２Ｂへ送信してもよい。サーバ２０２Ａは、Ｂのメンバシップが無効になったことを示すメンバシップ無効メッセージとして、メンバＢについてのＴＴＬをゼロに設定したリフレッシュメッセージを送信することによって、サーバ２０２ＢのグループリストＬ２から効率的にグループを除外することができる。リフレッシュされたイベント状態は、その後まもなく終わり、サーバ２０２Ｂは結果としてリストＬ２からグループを削除する。これまでの例と同様、ＴＴＬの変更は、クライアントＢを宛先にされてもよいが、イベントタイプもしくはクライアントＢの組み合わせに基づいて、サーバ２０２Ｂへルーティングされるであろう。
【００５８】
ステップ４．３において、例えばＴＴＬ＝０であるメンバシップ無効メッセージを受信するのに応じて、サーバ２０２Ｂは、ステップ４．４において、クライアントＡのグループについてのエントリ４００をリストから削除する。後の時点で、ステップ４．５において、リストを検索もしくは受信したとき、クライアントＢは、自分がもはやクライアントＡが創設したグループのメンバではないことを知るであろう。
【００５９】
あるいは、サーバ２０２Ａは、単純にクライアントＢにさらなるリフレッシュメッセージを送信するのをやめてもよく、そうすれば結果として、遅かれ早かれ現在のＴＴＬ値に応じて、リストＬ１の中のグループエントリが満了する。従って、ステップ４．３は省略することができるが、グループエントリは、満了まではしばらくの間、リスト内に残る。
【００６０】
あるグループが完全に終了する場合、以前の図４の例で記述したのと同様の手順が実行されてもよい。しかし、違うのは、サーバ２０２Ａが、その後リストＬ１全体を取り消し、そして、すべてのメンバのそれぞれのグループ管理サーバへ、上記のステップ４．３の場合のように、できれば、彼らのメンバシップが無効になったことを示す、すべてのメンバについてＴＴＬ＝０であるリフレッシュメッセージとして、メンバシップ無効メッセージを送信することである。このようにして、関連する各ネットワークは、それらのクライアントがもはやグループのメンバではないことを知らされ、そして、結果として、対応するグループリストからグループを削除する。
【００６１】
あるいは、それ以上のリフレッシュメッセージをどのクライアントにも送信することをやめれば、遅かれ早かれ、各ローカルサーバにおいてグループが満了する結果となるため、それで十分であろう。従って、以前のグループのすべてのクライアントが、リストを検索するとき自分達はもはやグループのメンバではないと分るように、ネットワークは、クライアントＡのグループのエントリをすべてのメンバのグループリストから削除する。
【００６２】
上述のように、クライアントは、自分のグループリスト上で発生する何らかの不要なグループのメンバシップを拒否するため、グループ情報を使用してもよい。従って、クライアントが特定のグループ内の通信への参加を希望しない場合、このクライアントを宛先としてグループ内で発生するすべてのトラヒックは、そのクライアントのサービスネットワークによってブロックされることができる。しかし、特定のクライアントへのグループ通信をブロックするメカニズムは、本発明の範囲外にあるので、ここではこれ以上説明しない。あるいは、下記のように、クライアントは積極的に自分のメンバシップを離脱してもよい。
【００６３】
クライアントＢが、クライアントＡによって創設されたグループのメンバシップを拒否するときの別の手順の詳細な例を、図５を参照しながら次に説明する。最初に、第１のステップ５．１において、離脱しつつあるクライアントＢが、グループ拒否メッセージを、自分のホームネットワーク２００Ｂ内のグループ管理サーバ２０２Ｂへ送信する。次いで、次のステップ５．２において、サーバ２０２Ｂは、このグループについてのエントリ４００をグループリストＬ２から削除する。サーバ２０２Ｂは、さらに、ステップ５．３において、離脱しつつあるクライアントＢがグループから離脱したことを宣言するため、対応するメンバシップ拒否メッセージを、拒否されたグループが維持されているグループ管理サーバ２０２Ａへ送信する。それに応じて、サーバ２０２Ａは、次のステップ５．４において、離脱しつつあるクライアントＢを、グループのメンバリストＬ１から削除する。さらに、サーバ２０２Ａは、最後のステップ５．５において、適切なメンバ離脱メッセージをグループ創設者であるクライアントＡに任意で送信し、クライアントＢがグループから離脱したことを宣言してもよい。
【００６４】
前述の図２乃至５に図解された手順において、各種のステップは、必ずしも所与の順序で実行されなくてもよいことを理解すべきである。例えば、サーバ２０２Ａは、ステップ２．２の前にステップ２．３を実行してもよいし、ステップ３．２の前にステップ３．３を、ステップ４．２の前にステップ４．３を、ステップ５．４の前にステップ５．５を実行してもよい。同様に、サーバ２０２Ｂは、ステップ５．２の前にステップ５．３を実行してもよく、以下同様である。
【００６５】
図６に示すフローチャートを参照しながら、本発明に従って、グループメンバシップ情報が通信グループのメンバに容易に入手できるようにする基本的な手順について次に記述する。
【００６６】
この手順は、グループ通信サービスをクライアントに提供することができるサービスネットワーク内の適切なサーバまたはその類似のもの、例えば図２、３、４の例にあるサーバ２０２Ａにおいて実行される。
【００６７】
第１のステップ６００において、例えば図２のステップ２．１の場合のように、複数のメンバを新規グループに組み込むように指定するグループ創設要求がクライアントから受信される。次のステップ６０２において、例えば図２のステップ２．２の場合のようにメンバリストが作成され、要求されたグループのために保存される。さらに、次のステップ６０４において、グループイベント通知が、グループ内の各メンバに送信されるか、もっと正確に言えば、各メンバのホームネットワーク内の対応するグループ管理サーバに送信され、例えば図２のステップ２．３で送信されるメッセージのように、各ネットワークに対して、それらのクライアントが新規グループのメンバになったことを知らせる。上述のとおり、グループイベント通知は、メンバもしくはクライアントにアドレス指定されたときでも、そのようなサーバへルーティングすることが可能である。
【００６８】
最も基本的な形態においては、グループに何の変更も施されない場合、手順はステップ６０４の後で終了してもよいだろう。しかし、次のステップ６０６の何時かにおいて、グループを創設したクライアントから、図３および４のステップ３．１および４．１でそれぞれ受信されたいずれかの要求のようなグループ修正要求が受信される。次いで、ステップ６０８において、その要求がどのタイプのイベントに関連しているのか、すなわち、クライアントが何の修正をしたいと思っているのかが判断される。例えば、図３の手順によって、要求の中で指定されるあるメンバがグループに追加されようとしている場合、ステップ６１０において、このメンバは対応するメンバリストに追加される。次いで、ステップ６１２において、新メンバがこのグループのメンバになったことを新メンバのホームネットワークに知らせるため、グループイベント通知が新メンバへ（もっと正確に言えば、そのメンバのホームネットワーク内のグループ管理サーバへ）送信される。
【００６９】
あるいは、あるメンバがグループから除外されようとしている場合、ステップ６１４において、このメンバは、図４のステップ４．２の場合のように、メンバリストから削除される。次いで、ステップ６１６において、このメンバがもはやグループのメンバではないことをこのメンバのネットワークに知らせるため、グループイベント通知、例えばステップ４．３のメンバシップ無効メッセージが、除外されたメンバへ（もっと正確に言えば、そのメンバのホームネットワーク内のグループ管理サーバへ）送信される。ステップ６１２もしくはステップ６１６のいずれかの後で、さらにグループ修正要求が受信された場合、プロセスはステップ６０６に戻ってもよい。留意すべきことだが、ステップ６１４および６１６は、グループが完全に終了する場合にも基本的に実行されることが可能であり、その場合、ステップ６１６ですべてのメンバにグループイベント通知を送信した後、プロセスは完了するであろう。
【００７０】
次に、図６の上記の手順について、図７に示すフローチャートを参照しながら、図２もしくは図４の例にあるサーバ２０２Ｂ、あるいは図３の例にあるサーバ２０２Ｘのような、グループのメンバの反対側のネットワーク内のグループ管理サーバ内で実行された場合を説明しよう。しかし、サーバ２０２Ａも、同様の状況でこの手順を実行するように構成されてもよい。
【００７１】
第１のステップ７００において、特定のクライアントについてのグループイベント通知は一般に、上記のステップ６０４において送信された通知のように、別のネットワーク内のサーバから受信される。次いで、ステップ７０２において、通知はどのタイプのイベントに関連しているのかが判断される。クライアントがグループのメンバになった場合、例えば、図２のステップ２．５もしくは図３のステップ３．４に従って、ステップ７０４において、このグループについての新たなエントリが、クライアントの関連グループリストに追加される。留意すべきだが、グループは、新規に創設されたグループであっても、すでに存在するものであっても、どちらでもよい。他方、例えば図４の手順におけるステップ４．３の場合のように、グループからメンバシップ無効メッセージを受信することによってクライアントが除外される場合、ステップ７０６において、このグループはメンバリストから削除される。ステップ７０４とステップ７０６のうちいずれかの後で、ステップ７０８において、サーバがそれを自動的に行うように構成されているならば、また、そうでない場合は要求があれば、オプションで通知がクライアントに送信されてもよい。いずれの場合も、さらなるグループイベント通知が受信された場合には、プロセスはステップ７００に戻ってもよい。
【００７２】
留意すべきだが、本ソリューションによるグループ管理サーバは、できれば、上記のサーバ２０２Ａ、２０２Ｂ、２０２Ｘのうち任意のものとして動作するように構成されることが望ましい。従って、本発明のグループ管理サーバはできれば、メンバリストを維持し、グループイベント通知を他の関係グループ管理サーバ（上述のサーバ２０２Ａのように）に送信することが可能であると同時に、グループリストを維持し、そのようなグループイベント通知を受信して、それに従って（上記サーバ２０２Ｂ、Ｘのように）クライアントに知らせることが可能であることが望ましい。
【００７３】
最後に、本発明のグループ管理サーバについて、複数の論理ユニット８０２乃至８１２を含むサーバ８００の概略ブロック図を図解する図８を参照しながら、ここで一般的に説明する。留意すべきだが、図中のさまざまなユニットは純粋に論理的であって、実際には、記述された機能は、適切なハードウェアおよびソフトウェアを用いて、多くの異なる方法で実装することができるが、但しそれは当業者の範囲内にあるので、従って、それをさらに詳細に記述する必要はない。
【００７４】
グループ創設要求およびグループ修正要求受信ユニット８０２は、上記のステップ２．１、３．１、４．１および５．１の場合のように、グループ創設要求およびグループ修正要求をクライアントから受信するように構成されている。メンバリスト管理ユニット８０４は、上記のステップ２．２、３．２、４．２および５．４の場合のように、クライアントのグループのメンバリストを維持するように構成されている。グループイベント通知ユニット８０６は、上記のステップ２．３、２．４、３．３、４．３および５．３の場合のように、グループイベント通知を他のグループ管理サーバへ送信するように構成されている。
【００７５】
グループイベント受信ユニット８０８は、上記のステップ２．３、２．６、３．３、４．３および５．３の場合のように、グループイベント通知を他のグループ管理サーバから受信するように構成されている。グループリスト管理ユニット８１０は、上記のステップ２．５、３．４、４．４および５．２の場合のように、クライアントについてのグループリストを維持するように構成されている。最後に、メンバシップ通知ユニット８１２は、上記のステップ２．７、３．５、４．５および５．５の場合のように、メンバシップ要求を受信してクライアントに自分のグループリストの現在のステータスについて知らせるように構成されている。
【００７６】
本発明は、クライアントが、自分はどのアクティブな通信グループのメンバなのかを、複雑な探索をしなくても見つけることができるように、通信グループのメンバシップ情報をクライアントが容易に利用できるようにする、単純だが効果的なソリューションを提供する。さらに、コンタクト先のサーバはわずか１台であるため、著しい遅延もなく、この情報を利用することができる。グループを創設するクライアントは、メンバに彼らのグループ内でのメンバシップについて知らせる手間が省けるが、それは、その情報が本ソリューションによって入手可能になるからであり、特に、彼らがメンバになるとすぐにメンバに自動的に通知されればなおさらそうである。電話をかけたり、電子メールで送信したりすると不正にインターセプトされる可能性があるが、そのようにしてこの情報を提供する必要がないため、プライバシも強化される。クライアントが彼ら自身の情報を彼らのグループリストとの関連で保存することも可能であり、例えば、将来彼らが参加する可能性があるオープングループのＩＤ（ＰＳＩ）などがそれに当る。
【００７７】
特定の典型的な実施形態を参照しながら、本発明について記述してきたけれども、記述は本発明の概念を例示することだけを意図したものであり、本発明の範囲を限定するものと解釈されるべきではなく、本発明の範囲は添付した請求項によって定義される。
【図面の簡単な説明】
【００７８】
【図１】先行技術によって、通信グループを創設する手順を図解するブロック図である。
【図２】本ソリューションによって、通信グループを創設する手順を図解するブロック図である。
【図３】一実施形態によって、メンバの追加によって通信グループを修正する手順を図解するブロック図である。
【図４】別の実施形態によって、メンバの除外によって通信グループを修正する手順を図解するブロック図である。
【図５】別の実施形態によって、通信グループのメンバシップを拒否する手順を図解するブロック図である。
【図６】本ソリューションの一態様によって、通信グループのメンバシップを管理する手順を図解するフローチャートである。
【図７】本ソリューションの別の態様によって、通信グループのメンバシップを管理する手順を図解するフローチャートである。
【図８】本ソリューションによるグループ管理サーバの概略ブロック図である。
【図１】
2008527767.tif 000002
【図２】
2008527767.tif 000003
【図３】
2008527767.tif 000004
【図４】
2008527767.tif 000005
【図５】
2008527767.tif 000006
【図６】
2008527767.tif 000007
【図７】
2008527767.tif 000008
【図８】
2008527767.tif 000009
【手続補正書】
【提出日】平成19年3月14日(2007.3.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
グループメンバが通信グループ情報を利用できるようにする方法であって、
第１のクライアントのホームネットワーク内の第１のグループ管理サーバ（２０２Ａ）内の第１のクライアント（Ａ）から、少なくとも第２のクライアント（Ｂ）を含む新規通信グループのためのグループ創設要求を受信する工程と、
前記第２のクライアントを含む前記グループ内のメンバのリスト（Ｌ1）を保存する工程とを備え、
前記第２のクライアントが前記新規通信グループのメンバであることを宣言するために、前記第１のグループ管理サーバから前記第２のクライアントのホームネットワーク内の第２のグループ管理サーバ（２０２Ｂ）へ、グループイベント通知を送信する工程を更に備え、
前記第２のグループ管理サーバは、前記第２のクライアントがメンバであるところの通信グループのグループＩＤを含む、第２のクライアントのグループリスト（Ｌ2）を維持し、該グループリストに、前記グループイベント通知の受信に応じて新規通信グループを追加することを特徴とする方法。
【請求項２】
前記グループが、異なるホームネットワークに属している複数のメンバを含み、前記グループイベント通知が、前記ネットワークにそれらの各クライアントが前記新規グループのメンバになったことを宣言するために、前記第１のグループ管理サーバから前記グループ内の前記メンバの前記ホームネットワークへ送信されることを特徴とする請求項１に記載の方法。
【請求項３】
前記メンバリストについて、それが有効であると考えられるＴＴＬ期間（有効期間）が設定され、前記グループが継続される場合には、新たなＴＴＬを持つリフレッシュメッセージを前記リストの中の前記メンバの前記ホームネットワークへ送信する工程によって、前記リストが、ＴＴＬの満了の直前にリフレッシュされることを特徴とする請求項２に記載の方法。
【請求項４】
グループＩＤが、前記グループに割当てられ、前記グループメンバリストと一緒に保存されることを特徴とし、前記グループイベント通知が前記グループＩＤを含むことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記第２のクライアントが前記既存のグループからメンバとしては除外されるか、もしくは、前記グループが完全に終了する場合に、既存のグループが前記グループリストから削除されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記第２のグループ管理サーバが、前記第２のクライアントからメンバシップ情報要求の受信に応じて、前記グループリストを有するグループメンバシップ通知を前記第２のクライアントへ送信することを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記第２のグループ管理サーバは、前記グループリストが変更される度に、前記第２のクライアントへグループメンバシップ通知を自動的に送信することを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記第１のグループ管理サーバにおいて、新メンバを前記新規グループに追加するためのグループ修正要求を前記第１のクライアントから受信する工程と、
前記新メンバを前記グループメンバリストに保存する工程と、
前記新メンバが前記グループのメンバになったことを前記新メンバの前記ホームネットワークに知らせるために、前記第１のグループ管理サーバから前記新メンバの前記ホームネットワークへグループイベント通知を送信する工程と
をさらに備えることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記第１のグループ管理サーバにおいて、あるメンバを前記グループから除外するためのグループ修正要求を前記第１のクライアントから受信する工程と、
前記除外されたメンバを前記グループメンバリストから削除する工程と、
前記除外されたメンバが前記グループから除外されたことを、前記除外されたメンバの前記ホームネットワークに知らせるために、前記第１のグループ管理サーバから前記除外されたメンバの前記ホームネットワークへ、メンバシップ無効メッセージを送信する工程と
をさらに備えることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記メンバシップ無効メッセージは、前記ＴＴＬがゼロに設定され、それによって前記除外されたメンバのメンバシップが無効になったことを示すリフレッシュメッセージであることを特徴とする請求項３または９に記載の方法。
【請求項１１】
前記第２のグループ管理サーバによって、
前記グループのメンバシップを拒否するため、離脱しつつあるクライアントからグループ拒否メッセージを受信する工程と、
前記離脱しつつあるクライアント用の前記グループリストから前記拒否されたグループを削除する工程と、
前記離脱しつつあるクライアントが前記グループを離脱したことを宣言するため、前記第１のグループ管理サーバへメンバシップ拒否メッセージを送信する工程と
が行われることを特徴とする請求項６乃至１０のいずれか１項に記載の方法。
【請求項１２】
通信グループのメンバが通信グループ情報を利用できるようにする装置であって、
第１のクライアント（Ａ）から、少なくとも第２のクライアント（Ｂ）を含む新規通信グループのグループ創設要求を受信し、かつ、前記第２のクライアントを含む前記グループの中で、メンバのリスト（Ｌ1）を保存するように構成された第１のグループ管理サーバを備えており、
前記第１のグループ管理サーバが、さらに、グループイベント通知を、第２のクライアントのホームネットワーク内の第２のグループ管理サーバ（２０２Ｂ）へ送信し、前記第２のクライアントが前記新規通信グループのメンバであることを宣言するように構成されることを特徴とする装置。
【請求項１３】
前記グループが、異なるホームネットワークに属している複数のメンバを含み、
前記第１のグループ管理サーバが、さらに、前記グループ内の前記メンバの前記ホームネットワークへ、それらの各クライアントが前記新規グループのメンバになったことを宣言するために、前記グループイベント通知を送信するように構成されることを特徴とする請求項１２に記載の装置。
【請求項１４】
前記グループ管理サーバが、前記メンバリストについて、それが有効であると考えられるＴＴＬ期間（有効期間）を設定し、前記グループが継続される場合には、新たなＴＴＬを持つリフレッシュメッセージを前記リストの中の前記メンバの前記ホームネットワークへ送信する工程によって、前記リストをＴＴＬの満了の直前にリフレッシュするように構成されることを特徴とする請求項１３に記載の装置。
【請求項１５】
グループＩＤが、前記グループに割当てられ、前記グループメンバリストと一緒に保存され、
前記グループイベント通知が前記グループＩＤを含むことを特徴とする請求項１２乃至１４のいずれか１項に記載の装置。
【請求項１６】
前記第１のグループ管理サーバが、さらに、第３のクライアントがメンバである複数の通信グループのグループＩＤを含む、第３のクライアント用のグループリストを維持するように構成されることを特徴とする請求項１２乃至１５のいずれか１項に記載の装置。
【請求項１７】
前記第１のグループ管理サーバが、前記第３のクライアントが前記新規グループのメンバになったときには新規グループを前記グループリストに追加するように構成されることを特徴とする請求項１６に記載の装置。
【請求項１８】
前記第１のグループ管理サーバが、さらに、前記第３のクライアントが既存のグループからメンバを除外された場合、もしくは前記グループが完全に終了した場合には、前記既存のグループを前記グループリストから削除するように構成されることを特徴とする請求項１６または１７に記載の装置。
【請求項１９】
前記第１のグループ管理サーバが、さらに、メンバシップ情報要求を前記第３のクライアントから受信する工程に応じて、前記グループリストを含むグループメンバシップ通知を前記第３のクライアントへ送信するように構成されることを特徴とする請求項１６乃至１８のいずれか１項に記載の装置。
【請求項２０】
前記第１のグループ管理サーバが、さらに、前記グループリストが変更される度に、前記グループリストを含むグループメンバシップ通知を前記第３のクライアントへ自動的に送信するように構成されることを特徴とする請求項１６乃至１９のいずれか１項に記載の装置。
【請求項２１】
前記第１のグループ管理サーバが、さらに、新メンバを前記グループに追加するため、グループ修正要求を前記第１のクライアントから受信し、前記グループメンバリストに前記新メンバを保存し、そして、新メンバが前記グループのメンバになったことを宣言するため、グループイベント通知を前記新メンバの前記ホームネットワークへ送信するように構成されることを特徴とする請求項１２乃至２０のいずれか１項に記載の装置。
【請求項２２】
前記第１のグループ管理サーバが、さらに、メンバを前記グループから除外するためのグループ修正要求を前記第１のクライアントから受信し、前記除外されたメンバを前記グループメンバリストから削除し、除外されたメンバが前記グループから除外されたことを宣言するために、メンバシップ無効メッセージを前記除外されたメンバの前記ホームネットワークへ送信するように構成されることを特徴とする請求項１２乃至２１のいずれか１項に記載の装置。
【請求項２３】
前記メンバシップ無効メッセージは、前記ＴＴＬがゼロに設定された状態のリフレッシュメッセージであって、それによって、前記除外されたメンバのメンバシップが無効になることを表示することを特徴とする請求項１４または１５に記載の装置。
【請求項２４】
前記第１のグループ管理サーバが、さらに、離脱しつつあるクライアントから、前記グループ内のメンバシップを拒否するため、グループ拒否メッセージを受信し、拒否されたグループを、前記離脱しつつあるクライアント用のグループリストから削除し、前記離脱しつつあるクライアントが前記グループから離脱したということを宣言するため、メンバシップ拒否メッセージを前記離脱しつつあるクライアントのホームネットワークへ送信するように構成されることを特徴とする請求項１２乃至２３のいずれか１項に記載の装置。
【請求項２５】
グループメンバが通信グループ情報を利用できるようにする通信システムであって、
第１のクライアントのホームネットワーク内の第１のグループ管理サーバと、
第２のクライアントのホームネットワーク内の第２のグループ管理サーバとを備え、
前記第１のグループ管理サーバが、前記第１のクライアントから、少なくとも前記第２のクライアントを含む新規グループのためのグループ創設要求を受信し、そして、前記第２のクライアントを含む前記グループの中で、メンバのリストを保存するように構成され、
前記第１のグループ管理サーバは、さらに、前記第２のクライアントが前記新規グループのメンバになったことを宣言するため、グループイベント通知を前記第２のグループ管理サーバへ送信するように構成され、
第２のグループ管理サーバは、前記第２のクライアントがメンバである複数の通信グループのグループＩＤを備えた、前記第２のクライアント用のグループリストを維持し、前記グループイベント通知を受信する工程に応じて、前記グループリストに前記新規グループを追加するように構成されることを特徴とする通信システム。
【国際調査報告】
2008527767.tif 000010
2008527767.tif 000011
2008527767.tif 000012