(57)【特許請求の範囲】
【請求項１】
他のユーザとの通信を確立することをそれぞれのユーザに可能にするサーバネットワークシステムであって、
第１クラスタと第２クラスタとを備え、
前記第１クラスタと前記第２クラスタそれぞれは、
ユーザサービスを実行するための少なくとも１つのユーザサーバと、
他のクラスタ内にある、遠隔のクラスタ内サーバと接続を行うためのクラスタ内サーバと、
少なくとも１つのデータベースとを備え、
前記第１クラスタ内の前記ユーザサーバは、該第１クラスタに割当られている第１ユーザに対する転送サービスを提供し、
前記第２クラスタ内の前記ユーザサーバは、該第２クラスタに割当られている第２ユーザに対する転送サービスを提供し、
前記サーバネットワークシステムは、前記転送サービスによって使用されるサーバネットワークシステム内でグローバルな固有ユーザ識別子を前記ユーザのクライアントに提供する手段を備え、
前記第２クラスタ内の前記ユーザサーバは、前記第１クラスタ内の前記ユーザサーバ、前記第１クラスタ内の前記クラスタ内サーバ、前記第２クラスタ内の前記クラスタ内サーバを介して、第１ユーザのクライアントから、通信インビテーションメッセージ／リクエストを受信するように構成され、
前記第２クラスタの前記ユーザサーバが提供する前記転送サービスは、前記第２ユーザのクライアントによって特定されているロジックに従って、前記通信インビテーションメッセージ／リクエストがどのように処理されるかを判定し、及び、前記通信インビテーションメッセージ／リクエストを処理するためにどのサービスが利用可能であるかを判定するように構成されている
ことを特徴とするサーバネットワークシステム。
【請求項２】
前記第２ユーザのクライアントは、パーソナルコンピュータ、移動電話及びページャの内の１つである
ことを特徴とする請求項１に記載のサーバネットワークシステム。
【請求項３】
前記第１クラスタと前記第２クラスタそれぞれは、それぞれのユーザのクライアントと当該クラスタを接続するための少なくとも１つの接続サーバを有し、かつ前記ユーザサーバがユーザ情報をアクセスすることができる前記データベースを有する
ことを特徴とする請求項１に記載のサーバネットワークシステム。
【請求項４】
前記第１クラスタと前記第２クラスタそれぞれは、更に、前記ユーザサーバ、前記クラスタ内サーバ、前記接続サーバをそれぞれ複数有している
ことを特徴とする請求項３に記載のサーバネットワークシステム。
【請求項５】
前記第１クラスタと前記第２クラスタそれぞれにおいて、前記ユーザサーバは、それぞれのユーザに対する転送サービスを実行し、かつそれぞれのユーザのクライアントに前記サーバネットワークシステム内の他の予め選択されているユーザのクライアントのオンラインステータスを監視することを可能にする
ことを特徴とする請求項１に記載のサーバネットワークシステム。
【請求項６】
前記第１ユーザは、前記第１クラスタで登録され、かつ該第１クラスタだけを識別するクラスタ識別子を含む前記固有ユーザ識別子が与えられ、そうすることで、前記第１ユーザの前記固有ユーザ識別子は、前記サーバネットワークシステム内のグローバルな固有識別子として使用され、
前記第２ユーザは、前記第２クラスタで登録され、かつ該第２クラスタだけを識別するクラスタ識別子を含む前記固有ユーザ識別子が与えられ、そうすることで、前記第２ユーザの前記固有ユーザ識別子は、前記サーバネットワークシステム内のグローバルな固有識別子として使用される
ことを特徴とする請求項１に記載のサーバネットワークシステム。
【請求項７】
前記第１ユーザのクライアントとしてパーソナルコンピュータを使用する場合、前記第１クラスタ及び前記第２クラスタは、前記第１ユーザと前記第２ユーザに、
１）パーソナルコンピュータとパーソナルコンピュータとの通信を使用するテキストチャット、
２）パーソナルコンピュータとＰＳＴＮ電話との通信を使用する音声チャット、及び
３）パーソナルコンピュータと移動電話との通信を使用する音声チャット
それぞれによる通信方法で、該第１ユーザと該第２ユーザとの間で通信することを可能にする
ことを特徴とする請求項１に記載のサーバネットワークシステム。
【請求項８】
前記第１ユーザのクライアントとしてパーソナルコンピュータを使用する場合、前記第１クラスタ及び前記第２クラスタは、更に、前記第１ユーザ及び前記第２ユーザに、
４）パーソナルコンピュータとパーソナルコンピュータとの通信を使用するページャによるページング、
５）パーソナルコンピュータとショートメッセージサービスとの通信を使用するページャによるページング、及び
６）ウェブ会議
それぞれによる通信方法で、該第１ユーザと該第２ユーザとの間で通信することを可能にする
ことを特徴とする請求項７に記載のサーバネットワークシステム。
【発明の詳細な説明】
【０００１】
本発明の技術分野
本発明は、ユーザが利用できる機能かつ／あるいは通信装置（群）の機能として、ユーザ間の通信セッション（群）を確立するシステム及びその方法に関するものである。
【０００２】
本発明の背景
典型的には、ユーザの通信ツール（例えば、移動電話、ＰＣ、電子メール等）は、２つの本質的なタスクに直面しており、１つは他のユーザとの通信のためにその他のユーザの装置アドレスの位置決めと、もう１つはその通信装置との通信セッションとの確立である。これらのタスクは、典型的には、ユーザ（群）がどのような装置を使用するかに依存して異なってくる。例えば、メッセージ機能を有する移動電話では、ユーザは、通常、自身のローカルアドレス帳から他のユーザを検索することによってその他のユーザの位置決めを行い、そのユーザの電話番号に電話をかけることによってそのユーザとの音声セッションを確立する、あるいはショートテキストメッセージ（ＳＴＭ）を入力して、それを他のユーザあるいは移動電話あるいは電子メールを送信する。被呼者の電話オペレータに依存して、その被呼者は、これらの発呼を受信することができる、あるいは受信することができない。
【０００３】
別の例として、テキストチャットソフトウェアを搭載するＰＣのユーザは、他のユーザとのチャットセッションを初期化することができるユーザリストを持つことができる。しかしながら、これは、他の人間がログオンしている時に限り実行できる。ログオフされていると、その人間とどのようにして交信するかを判定する方法を持ちえず、あるいはだれかが他のユーザと交信することを試行していることをそのユーザが気づくことができない。
【０００４】
つまり、解決すべき問題は、以下のすべてあるいはその一部を含み得る。装置とは独立し、利用可能かつ集中的に構成可能な情報とどのように交信するか、かつすべての通信を使用するためにどのように単一アドレスをユーザに与えるかである。ある種の通信セッションに参加させるためにユーザ有用性をどのように宣伝するかである。通信装置とは独立して、つまり、交信する装置アドレスを質問しないで、他のユーザとの通信セッション（即ち、コンタクト（交信））をどのようにして初期化するかである。直接介入の有無でユーザが意図する発呼がどのようにして処理されるべきかを集中制御することをユーザにどのように実現させるかである。発呼者と被呼者が専用ネットワーク上で異なるサービスプロバイダによって操作可能である場合に、これらの機能の相互作用をどのように保証するかである。別のユーザからの、ユーザのコンタクト情報の変更あるいは転送設定の変更あるいはなんらかの方法での他の人間のなりすましをどのように保護するかである。中央位置でのユーザとのコンタクトを妨害する人間を阻止することをどのようにしてユーザに実現させるかである。有効でかつ相互に作用できる方法で本明細書で説明されるサービスを提供させることを組織／企業／オペレータの１つ以上にどのようにして実現させるかである。
【０００５】
ＳＳ７システムは、電話発呼（例えば、ベル通信リサーチで示されるインテリジェントネットワーク（ＩＮ）アーキテクチャを参照）の設定で行う転送決定をインテリジェントに行うことができ、これは、発呼に対するサービスロジックがスイッチング機能とは独立して構成され、スイッチング装置の再設計を行うことなくサービスの追加あるいは変更が可能である。日時、発呼者識別子、発呼のタイプのような要素に依存する様々なサービスによって様々に解釈されるが、電話番号の一部がサービス独立アーキテクチャの概念を導入している。高度インテリジェントネットワーク（ＡＩＮ）と呼ばれる更新バージョンのＩＮは、ＡＩＮは、新規に電話装置を導入することなく新規なサービスの追加を容易に行える。
【０００６】
統一メッセージ転送システムは、典型的には、電話発呼、音声メールボックス、ファックス、電子メールを含む様々な通信オプションに対して本質的に１つのアドレスを提供することをユーザに許容する。典型的には、すべてのメッセージは、１つの集中化受信ボックスに記憶され、そこで、ユーザは、時には、媒体変換（例えば、テキストメッセージから音声への変換）を使用して、様々な装置にアクセスできる。これは、効果的に、ユーザに与える必要な装置アドレス数を削減する。統一メッセージ転送製品を使用する企業は多く存在する。
【０００７】
様々な企業が、インターネットの末端で動作するネットワークを構築し、互いにショートテキストメッセージを送信したり、他のユーザのステータスを監視することをユーザに許容しており、このステータスとは、通常、ユーザが現在ネットワークに接続されているかどうかで定義される。この種の機能は、現在、ＩＭＰＰ（インスタントメッセージ転送及び存在プロトコル）と呼ばれるＩＥＴＦ標準で議論されている。
【０００８】
セッション初期化プロトコル（ＳＩＰ）は、ＩＥＴＦ標準で行われるプロセス内に存在し、ＩＰベースのネットワークのＳＳ７の後継者に位置づけられている。このプロトコルは、基本的には、インターネットを介して他のユーザとの任意の通信セッションに他のユーザを招待することをユーザに可能にさせ、同時に、これらのインビテーション（招待：inbitation）の任意の転送を可能にする。
【０００９】
ＳＳ７で使用される上述のＩＮ及びＡＩＮの方法は電話ネットワークに制限され、インターネットのような他のネットワークに容易に拡張することができない。つまり、通信のためのユーザの有用性を宣伝することを容易に行う方法はない。また、制限されたインタフェースを介する以外に、ユーザに対してその転送の構成を容易に行う方法はない。インスタントメッセージ転送システムは、典型的には、ＩＰベースのみであり、通常、異なるネットワークに渡る通信は許容されない。このようなシステムの多くは、転送を機能させるためにそのシステムに接続されるユーザに依存し、ユーザは他のユーザにネットワークアドレスを公開する、これは、末端のセキュリティが潜在的に考慮される。また、多くのシステムは、集中化アーキテクチャに依存し、これは、ユーザデータベースを分散し、多くのプロバイダ間のトラフィックを分散することを困難にする可能性がある。
【００１０】
一般的には、様々なシステムが上述の問題の一部について取り組んでいる。しかしながら、より広範囲に上述の１つ以上の問題を処理するシステム／ネットワーク及びその方法の要望が従来より存在している。
本発明の要約
システムは、クラスタに接続する任意数のクライアント端末（即ち、クライアント）に従って、サーバクラスタの疎結合ネットワークを含んでいる。端末／クライアントは、いくつかのオペレーティングシステム下で動作するソフトウェアエンティティであり得り、あるいはクラスタへのアクセスを有することができるいくつかの通信ネットワーク上で動作する任意の他のデバイスであり得る。ユーザは、いくつかの特定クラスタに登録され、固有のユーザＩＤが与えられる。クラスタのＩＤ（ＣＩＤ）に従うこのユーザＩＤは、システム全体におけるグローバルな固有ユーザＩＤ（ＵＩＤ）を構成する。ユーザは、いくつかのクライアント端末あるいはいくつかの他の方法／システムを介してクラスタと接続する人間あるいは任意の他のエンティティであり得る。端末は、クラスタ内で動作する任意数のサービス、あるいは他のクラスタ内で動作するサービスとのアクセスを得ることができる（「サービス」は、任意の機能を有することができるソフトウェアエンティティである）。端末とクラスタ間の接続は安全が確保され、一実施形態では暗号技術を使用している。
【００１１】
各クラスタ内で提供される基本サービスは、例えば、１）オンラインステータスあるいはユーザの「存在」と呼ばれる動的ユーザプロパティは、ユーザ及びクライアントに、ユーザにリンクされているデータポイントを集中定義かつ変更を可能とする、これらの変更は（ユーザによって明示的に行われる）手動あるいは（いくつかのクライアントあるいはサーバ側ロジックによって）自動で行うことができる、２）コンタクト（交信）リスト及びコンタクト通知、これは、ユーザに、加入及びオンラインステータスを他のユーザへ通知することを可能にし、かつ／あるいは変更を他のユーザへ通知することを可能にする、３）転送サービス、これは、ユーザに、通信セッションに対するリクエスト（即ち、インビテーション）を他のユーザに送信することを可能にする、また、ユーザの現在の存在情報に依存して、これらのインビテーションがどのようにして処理されるかを構成することを可能にする。
【００１２】
転送サービスは、任意のネットワークを介する任意の通信セッション（例えば、テキストチャットセッション、音声チャットセッション、ｗｅｂ会議等）を確立するために、ユーザにインビテーションを他のユーザへ送信することを可能にする。リクエストは、ユーザ間では直接送信されない。その代り、送信／招待ユーザに対する転送サービスは、インビテーションを受信ユーザに対する転送サービスへ送信する。受信ユーザに対する転送サービスは、同一受信ユーザによって特定されるロジックに従って、リクエストがどのようにして処理され、かつリクエストを処理するためにどのサービスが利用可能であるかを判定する。例えば、受信ユーザに対する転送サービスは、インビテーションを受信ユーザのクライアントへ送信することができる、あるいはインビテーションを無視することができる、あるいはインビテーションを受信ユーザの移動電話へ送信することができる、あるいはユーザが後でインビテーションを読むことができるようにするために受信ユーザの受信ボックスへインビテーションを送信することができる。
【００１３】
クラスタ及びその内部のサービスは、確立対象のセッションに対して必要最小限の設定を行う、つまり、ユーザ間でのネットワークアドレスの交換は必要がなく、このため、ユーザの匿名性が維持される。ユーザがソフトウェアエンティティかつ人間であり得るので、システムは、ユーザ間の通信セッション及び任意のデータサービスが可能である。一実施形態では、システムはすべてのユーザに機能する中央データベースは必要がないが、クラスタはリクエストを他のクラスタへ送信でき、つまり、システム内のすべてのクラスタの接続性を保証する。
【００１４】
アプリケーションは、バディリスト（即ち、コンタクトリスト）をユーザに提供する。ユーザは、他のユーザをこのリストに追加でき、かつこれらをグループにまとめることができる。アプリケーションを使用して、ユーザは、自身のバディリスト（即ち、コンタクトリスト）内のユーザのオンラインステータスを知ることができ、これらのユーザのステータス（群）が変更する場合の通知を取得することができる。また、ユーザは、自身のオンラインステータスを設定でき、匿名ユーザに自身を不可視にすることができ、更に、簡単なダブルクリックによって、自身のバディリストのユーザに任意の種類のメッセージを送信することができる。
【００１５】
一実施形態では、メッセージは、ユーザ間で直接送信されない、その代わり、ユーザの１つのサーバ上で提供される少なくとも１つの中間転送サービス（ＲＳ）を介して送信される。つまり、一実施形態では、ユーザは、他のユーザと通信している場合でさえも、他のユーザから自身のパーソナル情報を隠すあるいはマスクすることができる。一実施形態では、ユーザは、他のユーザによって使用されるクライアントデバイス（例えば、ＰＣ、移動電話等）の情報なしで、別のユーザとの通信セッションを確立することができ、このようにして、ネットワークは、ユーザによって発呼されるクライアントデバイスに関係なくユーザ間の通信（例えば、テキストチャットセッション、音声チャットセッション（ＰＣとＰＣ、ＰＣとＰＳＴＮ、あるいはＰＣと移動電話）、ｗｅｂ会議あるいはページ（ＰＣとＰＣ、ＰＣとＳＭＳ））を構成する。つまり、ネットワークは、ユーザ間の上述の任意の通信サービスを可能にし、初期化を行うユーザは、自身のＰＣを介して他のユーザが現在オンラインであるかどうかを知る必要がなく、あるいはページャあるいは移動電話を介して他のユーザと交信することができる。
【００１６】
本発明の実施形態の詳細説明
以下の説明は、説明の目的のためで、限定を目的とするものではなく、特定詳細は、本発明を理解するために、例えば、特定実施形態、ネットワークアーキテクチャ、信号フロー、プロトコル、技術等を説明するものである。しかしながら、本発明がこれらの特定詳細から逸脱しない他の実施形態で実施可能なことは当業者には明らかであろう。ある例では、周知の方法、インタフェース、装置、プロトコル及び信号技術の説明は、本発明の詳細をあいまいにしないために不必要な詳細は省略する。
【００１７】
まず、ソフトウェア設計ダイアグラムの表記は、多くの場合、ＵＭＬ標準（統一モデル化言語）に従うことに注意する。データダイアグラムに対して使用される同一の表記は、クラスダイアグラムに対するものとして使用される。それゆえ、本明細書で、データ構造が説明されているのか、従来のクラスが説明されているかに注意する。高レベルのシーケンスダイアグラムでは、リプライを必要としないメッセージに対しては、片方向矢印が使用される。両方向矢印は、このような場合におけるリクエスト−リプライメッセージに対して使用され、ここで、逆及び順方向通信の正確な記述は重要ではない。
【００１８】
図面及び表現の簡単化のために、本願のコンテキストが役に立つ。つまり、以下の説明を、本願に適用し、かつそれから得られる特許に適用する複数の定義を示すものである。
【００１９】
本明細書で使用される用語の定義／解説
「コミュニティ」は、自身のアプリケーションを通してユーザと対話できるユーザ群である。多くの異なるコミュニティが存在し、あるいは単一のグローバルコミュニティが存在する。これは、どのようなサービスがグループされるかかつどのサービスにユーザが接続しているかによって定義される。
【００２０】
「アプリケーション」は、本発明のシステム／ネットワーク全体を示しており、これは、クライアント側ソフトウェア、サーバ側ソフトウェア、記憶されるデータ、システム全体の機能を含んでいる。
【００２１】
「クライアント」は、クライアントあるいはユーザ側からアプリケーションへアクセスするために使用されるソフトウェアである。
【００２２】
「バックエンド」は、クライアントに直接あるいは間接的に接続されるサーバ、ネットワーク及びソフトウェア群である（即ち、クライアントに接続される、そのクライアント自身のローカルクラスタ、そのローカルクラスタに加える任意のクラスタである）。
【００２３】
「クラスタ」は、高速で、信頼があり、安全なネットワークに接続されるサーバ及びデータベースの集合である。バックエンドは、相互接続クラスタ群である。
【００２４】
「ローカルクラスタ」は、クライアントに直接接続されるクラスタである。
【００２５】
「ユーザ」は、クライアントを介してアプリケーションにアクセスするエンティティ、人間あるいはソフトウェアである。
【００２６】
「フレームワーク」は、バックエンドサーバと共通なアプリケーション構造である。
【００２７】
「サービス」は、例えば、サーバ上に存在し、サーバのクライアントに対し機能群を提供するソフトウェアエンティティである。この機能群は、サービスの使用方法に多義性を定義しないプロトコル記述によって特定される。
【００２８】
「サービスクリエータ」は、サービスを記述するプログラマである。
【００２９】
「クライアントインプリメンタ」は、バックエンドシステムに対するクライアントを生成するプログラマに対して使用される。
【００３０】
「メッセージ」は、あるユーザから別のユーザへ送信される情報の一部である。
【００３１】
「制御メッセージ」は、クライアントからサーバあるいはサーバからクライアントあるいはサーバ間で送信される情報の一部である。制御メッセージは、システムの他の構成要素の機能にアクセスするために使用される。
【００３２】
「リクエスト」は、クライアントによって初期化され、サーバへ送信される制御メッセージである。
【００３３】
「リプライ」は、リクエストに対するリプライとしてサーバからクライアントへ送信される制御メッセージである。
【００３４】
「通知」は、サーバによって初期化され、クライアントへ送信される制御メッセージである。
【００３５】
「応答」は、通知に対する応答としてクライアントからサーバへ送信される制御メッセージである。
【００３６】
「通信モード」は、リアルタイム通信に対して使用される方法であり、本明細書では、例えば、音声モードがある。
【００３７】
「会話」は、リアルタイムで実行される２つ以上のユーザ間の対話である。
【００３８】
「メッセージタイプ」は、メッセージで送信される情報のタイプであり、例えば、ショートテキストメッセージがある。
【００３９】
「ＣＳ」は、接続サーバである。これは、サーバソフトウェアかつ／あるいはそれを実行する装置として参照することができる。どちらを参照するかは、状況に応じて明らかである。
【００４０】
「ＤＢ」は、リレーショナルデータベースであり、好ましくは、それを実行する装置を含む。
【００４１】
「ＵＭＦ」は、ユーザマッピング機能である。これは、概念的には単一のエンティティであるが、実際には、ＣＳ、ＵＳ及びＩＣＳそれぞれで実現され、マルチエンティティであり得る。ＵＭＦは、好ましくは、ＤＢに記憶されるが、他の実施形態ではそれ以外のものに記憶することもできる。
【００４２】
「ＧＲＩＤ」は、コンタクトリスト内のコンタクトに対するグループ識別子である。
【００４３】
「ＣＩＤ」は、クラスタ識別子である。
【００４４】
「ＩＣＳ」は、クラスタ内サーバである。これは、サーバソフトウェアかつ／あるいはそれを実行する装置として参照することができる。どちらを参照するかは、状況に応じて明らかである。
【００４５】
「ＩＣＳＩＤ」は、クラスタ内サーバ識別子である。
【００４６】
「ＵＩＤ」は、ユーザ識別子である。
【００４７】
「ＵＳ」は、ユーザサーバである。これは、サーバソフトウェアかつ／あるいはそれを実行する装置として参照することができる。どちらを参照するかは、状況に応じて明らかである。
【００４８】
「ＵＳＩＤ」は、ユーザサーバ識別子である。
【００４９】
「メッセージリポジトリ」は、ユーザに対する１つ以上のタイプのメッセージを受信でき、かつユーザがそのメッセージを検索するまで少なくともそれを記憶するエンティティであり、例えば、ファクス装置がある。
【００５０】
「デバイス」は、１つ以上の会話エンドポイントとして、あるいは１つ以上のメッセージタイプに対するメッセージリポジトリとして、あるいはその両方として機能することができるエンティティである。また、デバイスは、１つ以上のタイプのメッセージを送信することができる。この例としては、ＧＳＭ電話があり、これは、ショートテキストメッセージリポジトリであり、かつ音声会話に対応する会話エンドポイントである。
【００５１】
「プロファイル」は、バディ（buddy）／コンタクトリストで定義されるユーザあるいはユーザグループに対して有効な経路からなる経路群である。プロファイルは、各ユーザに対して、通信モードそれぞれに対する経路が存在するという意味では完全である。
【００５２】
本発明の実施形態の詳細
本発明の実施形態に従うシステム／ネットワークは、複数のクライアントアプリケーション（例えば、ユーザによって操作可能なＷｉｎ３２）と、（例えば、ＷｉｎｄｏｗｓＮＴ上で動作する）複数のクラスタを有するバックエンドサーバシステムとを含んでいる。メイン機能は、単純でかつ安全な方法で他のユーザあるいはサービスとの任意の通信セッションの確立や、オーバＩＰネットワークあるいは他のネットワーク、例えば、ＰＳＴＮの実行をユーザに提供する。また、これは、付加価値サービス（例えば、サーチエンジンサービス、データベースサービス、ショッピングサービス、ストック価格のようなストック情報をユーザに送信するサービス、アプリケーションの外部にあるビデオ会議サーバを介してビデオ会議の設定をユーザ（群）に可能にするビデオ会議サービス等）をユーザに提供し、かつその使用に対する課金を可能にする様々な環境をオペレータ（オペレータは、少なくとも１つのクラスタを操作あるいは管理するものである）に提供し、また、オペレータに、ＩＰネットワークを介して自身にインストールされた基本サービスへリンクする方法を提供する。基本表現においては、システム／ネットワークの構成はブローカ（群）として動作し、２人以上のユーザ（あるいはそれぞれのクライアント／ＰＣ／電話）間で通信サービスを仲介でき、また、付加価値サービス、それ以外に基づくいくつかの通信に対するアクセスを仲介できる。サービスへのアクセスは、様々な操作プラットホーム上あるいはＷＡＰ（無線アプリケーションプロトコル）のようなブラウザベースのシステムを介して動作する処理負荷が軽いクライアントによって提供される。システム／ネットワークは、付加価値サービス（ＶＡＳ）を容易に構築しかつ動作させ、ユーザ管理機能、セキュリティ、認証を使用し、それらの基礎としてシステム／ネットワークの特徴を果たすことを可能にするように設計されている。システム／ネットワークがアクセス性及び移動性を提供するように設計されているので、ユーザは、システム／ネットワークの広範囲な付加価値サービスを補償する仮想的な任意の通信装置、コンピュータ、移動電話、携帯装置等から自身のデータやサービスにアクセスすることができる。
【００５３】
図１は互いに通信が可能なシステム／ネットワークの複数のクラスタ１を示し、一方、図２は図１の実施形態のクラスタ１の例を示している。図２を参照すると、システム／ネットワークの基本構成は、相互接続しているいくつかのサーバ３、そのサーバ３それぞれが実行するいくつかのサービス５を含んでいる。このようなサーバの集合は、図２に示されるようなクラスタ１と呼ばれる。クラスタ１は、サービス５のアドレス空間を定義し、かつ相互接続するためにサービスに対するかつ外部サーバとの接続に対するローレベル接続性を提供する。各サービスは、いくつかの周知のプロトコル（群）を介して自身の機能へのアクセスを提供でき、これは、汎用的なストリームモデルの先頭に再度構成される。つまり、サービスは、名前によって別のサービスをリクエストでき、また、サービス特定プロトコルを使用してその別のサービスとの接続を確立できる。
【００５４】
外部ユーザ７とそのクライアント１１（例えば、ユーザのＰＣ、移動電話かつ／あるいはＰＤＡ）は、特定接続サービスを介してクラスタ内のサービスと接続することができ、これは、通常、クラスタのファイヤウォール９の境界のサーバ（群）（接続サーバ）上で動作し、特定ポート上での接続を監視する。このサービスを介して確立されるストリームは、一実施形態では、例えば、Ｗｉｎ３２クライアントの場合ではＳＳＨ２．０プロトコルを使用して、安全が確保されかつ暗号化される。このように、すべての接続されるユーザ７及びクライアント１１に従うクラスタ１は、内部でサービス間の接続を自由に確立することができる仮想プライベートネットワークを形成することができる。また、接続は、図１に示されるように、異なるクラスタ１のサービスかつ／あるいはユーザ７間で構成することができる。このような接続は、どのサービスを実際に利用可能にするかを制限できる特別なクラスタ空間内サービスを使用する。また、本発明の実施形態でクラスタ間の接続は、安全が確保され、かつ暗号化されても良い。
【００５５】
また、本アーキテクチャから外れる追加サーバとソフトウェアが、装置（群）の必須構成を形成しても良い。このように、これらがクラスタの一部と考慮すると、これらには、耐性データベース（群）１３（例えば、Ｏｒａｃｌｅ８）や、サーバ３、ユーザ７かつ／あるいはクライアント１１と通信可能な様々な操作及びメンテナンスツールが例に挙げられる。
【００５６】
典型的には、あるサーバ３は与えられた構成のサービスで設定され、これらは、時には、与えられた名前によって参照されることがある、例えば、外部クライアントに対する接続サービスを実行するサーバは、以下の説明では接続サーバと呼ぶが、これは、他のサーバと構造的に異なるものではない。
【００５７】
本発明の一実施形態では、デフォルトでは、クラスタ１は基本サービス群を実行する。本実施形態では、基本サービス群は、以下の機能を提供する：１）各ユーザ（あるいはユーザのクライアント）７にすべてのクラスタ内での固有識別子を有することを可能にする、２）各ユーザ７に接続する機能と識別子を使用してクラスタ１による安全な認証を行う機能を提供する、３）各ユーザ７に識別子に関連する任意のデータ群（このデータは、データベース１３に存在するあるいは記憶されており、このデータは、本明細書ではユーザの「存在」データとして参照する）を定義する機能を提供する、４）各ユーザ７に識別子に関連する動的ステータス情報かつ／あるいは存在情報を発行する機能を提供する（簡単な例では、このステータスあるいは存在は、ユーザが現在自身のＰＣ上でオンラインになっているかどうかを示すものである）、５）各ユーザ７に（同一あるいは他のクラスタ（群）内の）他のユーザ７群のステータス／存在を監視する機能とそれらの変更を通知する機能を提供する、６）各ユーザ７に名前あるいは他の利用可能な条件による質問を使用して他のユーザの識別子（群）を検索する機能を提供する。
【００５８】
図３〜図６を参照すると、システム／ネットワークの機能は、他のユーザ７と任意の通信セッションを確立するためにユーザ７に対する可能事項を提供することである。異なるタイプ（例えば、音声あるいはテキスト）の通信は、異なる実施形態で確立される可能性がある。システム／ネットワークは、「インビテーション」を使用して、相互通信チャネルの初期検出を行う。また、「インビテーション」は、説明の簡略化のために、本明細書では、インビテーションメッセージあるいはＩＮＶＩＴＥ（群）とも参照する。
【００５９】
インビテーションは、基本的には、ある与えられたタイプの通信であるユーザ７と別のユーザとを結びつけるためのリクエストである。これらのフォーマットは、一実施形態では、ＳＩＰ（セッション初期化プロトコル）と呼ばれるＩＥＴＦ標準に従うことが可能である。典型的には、クライアント１１は、いくつかの与えられた通信タイプ群をサポートし、各タイプに対してＳＩＰインビテーションをどのように生成するかを把握している。ユーザ７が他のユーザとの通信を確立したい場合、そのユーザは、自身のクライアント１１内のいくつかの機能を呼び出して、選択されたユーザへ与えられたタイプのインビテーションを送信することをクライアントにリクエストする。次に、ユーザのクライアント１１は、正確なＳＩＰメッセージを生成し、それをクラスタ内の転送サービス（ＲＳ）と呼ばれる専用サービスへ送信する。一実施形態では、各ユーザは、ユーザのユーザサーバ（ＵＳ）上で提供される特定転送サービスを有している。
【００６０】
一実施形態では、転送サービス（ＲＳ）は、メッセージの受信者の内容で呼び出されているが、送信ユーザの内容で呼び出されても呼び出されなくても良い。ＲＳの機能は、どのようなインビテーションメッセージで動作するかを決定することである。このように、メッセージは、ユーザ間で直接送信されることはなく、常に、ユーザから別のユーザの転送サービス（ＲＳ）へ送信される。転送サービスの決定ロジックはユーザに対しては局所的であり、ユーザの要望に従ってユーザ７によってプログラムされても良く、かつ必要に応じて複雑にすることができるが、いくつかの単純な方法でそれを制御を可能にするためにユーザの必要要素によって通常制限される。このロジックがどのようなものにしろ、転送サービスは２つの処理の実行を終了することができる、インビテーションを無視すること、あるいはインビテーションをその与えられた通信タイプのインビテーションを受け入れる他のサービスへ送信することである。インビテーションを受け入れるサービスは、デバイスハンドラと呼ばれている。クライアント１１は、本発明の実施形態におけるデバイスハンドラのタイプ例である。
【００６１】
デバイスハンドラは、転送サービスがインビテーションをディスパッチできる通信エンドポイントである。デバイスハンドラは、特に、他のネットワークとのインタフェースのために使用される。例えば、テキストページを移動セルラー通信ネットワークへディスパッチするために、デバイスハンドラは、テキストページを受信し、受信機の移動番号を参照して、ＳＭＳゲートウェイのようないくつかの標準ページングゲートウェイへすべての関連情報を送信するように設定される。選択的には、デバイスハンドラは、電話発呼も可能である。ここでは、２つのデバイスハンドラが利用可能であり、１つはエリクソンＩＰテレフォニーシステムとのインタフェースを提供するデバイスハンドラであり、これは、ＰＳＴＮネットワークで音声チャットインビテーションを終了することが可能である。もう１つのデバイスハンドラは、テキストページのＧＳＭネットワークへの転送を可能にする。すべてのサービス及びデバイスハンドラがデータベースの管理情報へアクセスでき、例えば、ユーザアカウントのチェックや特定サービスを使用するための許可のためのアクセスを行うことができる。これは、データベースで課金するサービスを集中化することを可能にする。サービスは、サービスＳＤＫを使用して、システム内で容易に生成し配置することができる。この方法では、新規なネットワークあるいは既存ネットワークへの転送に対するサポートを、システムに容易に追加することができる。
【００６２】
図３において、（クライアントＡを有する）第１ユーザＡは、インビテーションメッセージの（クライアントＢを有する）ユーザＢへの送信を要求する。図示のデバイスハンドラのように、接続クライアント１１は、あるタイプのインビテーションに対する適切なエンドポイントとしてユーザＢのＲＳに存在することができる。例えば、図３のように、ユーザＡはテキストチャットに対するインビテーションをユーザＢへ送信すると、ユーザＢは、自身がクラスタに接続する場合に構成されるＲＳを有し、すべてのインビテーションが自身のクライアント１１へ送信され、ユーザＢのＲＳはそれに従ってインビテーションメッセージを送信し、そのインビテーションは、ユーザＢのアクセスのためにユーザＢのクライアント１１で終了する。この場合、ユーザＢのクライアント１１上で、この特定インビテーションを受信し処理するいくつかの符号が存在していると仮定する。
【００６３】
図４に示されるように、別の場合では、デバイスハンドラはユーザのクライアント１１ではなく、クラスタ内（例えば、サーバあるいは他のデバイス上）で実行する実際のサービス１０となる。これらのサービス１０は、典型的には、いくつかの外部デバイスあるいはネットワーク１２（例えば、電話あるいは他のネットワーク）とのインタフェースを提供し、その外部デバイスあるいはネットワーク１２に対して信号プロトコルがどのようなものでもインビテーションを適切に変換する。図４では、ユーザＢがオンラインでない場合に、ユーザＢは自身のＲＳへインビテーションメッセージを自身の移動電話１４へ送信することを指示している。つまり、ユーザＢのＲＳは、外部セルラー電気通信ネットワーク（例えば、ＧＳＭ）とのインタフェースを提供するサービス１０へインビテーションメッセージを送信し、これは、一方で、そのインビテーションメッセージをネットワークへ送信し、最終的にユーザＢの移動電話１４へ送信することを可能にする。この方法では、デバイスハンドラ１０は、インビテーションを実際のユーザへの電話発呼に変換することができる。
【００６４】
上述したように、インビテーションメカニズムは、転送サービス（ＲＳ）によって仲介される通信タイプがどのようなものでも制限されない。実際の通信タイプは、それを処理するために利用可能なデバイスハンドラ１０（かつ／あるいはクライアントデバイス１１）によって制限されるだけであり、他のユーザもそのことを望んでいる。一実施形態では、セッションネゴシエーションは、ＩＰ番号あるいは電話番号のようなユーザのネットワークアドレスの交換を全く必要としない。この方法の効果は、プライバシを保て、ユーザが他のユーザへどのようにして到達したかについては気にする必要がないことである。ユーザ７からインビテーションが与えられると、発呼されるユーザ７（即ち、被呼者）の転送サービス（ＲＳ）は、ユーザ間の通信チャネルがどのようにした設定されたかあるいはどのネットワークであるかを発呼ユーザ７（即ち、発呼者）を知ることを必要としないで、インビテーションがどのようにして処理されるべきかを決定する。つまり、例えば、音声セッションは、発呼者がその音声セッションを知ることなく電話システムを終了することができる。しかしながら、ネットワークアドレスが実際に交換されて終了するかどうかで行われる実際の通信ロジックが発生し、転送プロトコルかつ／あるいはアプリケーション構造の制御外となる。すべてのタイプの通信に対するユーザ匿名性が維持されるべきかの決定は、本発明の実施形態のクラスタを操作するオペレータによって行われる。
【００６５】
上述したように、クラスタ１の機能は、特定タイプのサービスであるデバイスハンドラを使用して拡張することができる。これは、クラスタに追加できる付加サービスの簡単な例である。構造的な観点からは、どのような種類のサービスが適切なＳＤＫが与えられるクラスタに付加できるかについての制限はない。これは、いくつかの対応クライアントモジュールとのインタフェースを提供できる複雑な付加価値差サービスの生成方法を公開し、上述の基本的な方法以外の方法を実行する機能を提供するものである。
【００６６】
図５において、付加サービス１６に対する別のエントリポイントは、特定クライアント１０に使用される。これは、システム内の別のユーザとして自身が存在するためにクライアント／サーバプロトコルを実際に使用するサービス１６である。このような「擬似」ユーザ１６は、エージェントと呼ばれる。ユーザの観点からは、エージェントは別のユーザのように振る舞い、即ち、そのユーザは、自身のステータスを監視し、インビテーションを送信することができる。ユーザ７とエージェント１６間で通信が確立した場合の違いは、ユーザといくつかのソフトウェアエンティティ間の対話形態にある。通信のタイプは音声あるいはテキストであり得るが、より好ましくは、エージェントとユーザの端末にインストールされているいくつかの特定クライアントソフトウェア間には、いくつかのカスタムデータ通信がある。このタイプの通信の拡張性は、新規でかつ興味深いサービスを可能にする。
【００６７】
上述したように、多くのサービスは、電話システム、セルラー電気通信ネットワーク、オンラインショッピングネットワークの類のような課金可能なリソースへのアクセスを提供することができる。これは、これらのリソースへのユーザ７のアクセスを制御し、その使用を監視するために発呼を行う。一実施形態では、本発明に従うシステム／ネットワークは、ユーザに対するアカウントタイプの概念をサポートでき、ここで、各アカウントタイプはいくつかのサービス群へのアクセスを与える。この方法では、サービスの使用の制御は容易に管理することができる。より詳細な課金を行う場合には、各サービスは自身の課金規則を定義し、それに従って実行することができる。いくつかのサービスは、後のアカウント取得のためにすべての動作のログを簡略することができ、一方、他のサービスは、ユーザ及びそれらの現在のアカウント状況を動的に監視することができ、可能であれば、課金がゼロになる場合にセッションを終了する。
【００６８】
図６において、ユーザ７はグローバルな固有識別子を有しているので、ユーザ間の接続はクラスタ１を介して送信することができる（即ち、あるクラスタ１から別のクラスタ１へ）。これは特定サービス、即ち、クラスタ内サービスを介して実行されても良く、これは、異なるクラスタのサービス間のプロキシとして動作する。起動されるサービスの観点からは、プロキシは透過あるいは実質的に透過であることが好ましい。唯一の制限は、クラスタオペレータが制限されたサービス群へのリモートアクセスだけを可能にするようにクラスタ内サービスを構成することである。つまり、オペレータ特定付加価値サービスが、与えられるクラスタに対して排他的に実現される。
【００６９】
ユーザ７の観点からは、クライアント１１は目立たないアプリケーションとしてユーザに対し振る舞い、ユーザのＰＣの閉空間では、デスクトップ上に小いさなボールとして現れる。図７に示されるように、ユーザ７がアプリケーションを開始すると、そのユーザにユーザ識別子が提示され、これには、ユーザのオペレータに対するアドレス、安全が確保されて認証されているパスワードが含んでいる。この時点で、クライアント１１は対応するサーバ３へ接続し、サーバ３とで安全が確保された接続を確立する。この接続は、当業者に周知な暗号技術を使用して、強力な認証と暗号化を行うことができ、これにより、第三者からクラックされないようにすることができる。
【００７０】
ログオンが成功すると、小さなボールが開かれ、ユーザ／クライアントが利用可能な様々な機能及び表示が提示される。ある機能は、コンタクトリスト（例えば、図８に示されるリスト部分）として知られている。このリストはユーザによって維持され、例えば、ユーザが把握し、かつコンタクトを行う他の個人や、オプションとしては他のユーザのアドレスあるいはＩＤを含めることができる。一実施形態では、このリストはこれらの他のユーザのオンラインステータスを示すことができる。このステータスは、与えられるユーザが現在システムにログインしているかどうかを反映するものであり、つまり、ユーザ７が直ちに交信可能であるかどうかの情報を与えるものである。実際には、ユーザは、取り得る範囲のスタースを有しており、これらは、例えば、完全にオンラインであることを他のユーザに通知するばかりでなく、一時的に閉ざされるあるいは利用不可能にならないことを要求することを決定することができる。このリストはフォルダを定義することによって容易に構成でき、また、様々なディスプレイモードで選択することができる。ユーザは、（知っている場合には）自身のシステム／ネットワーク識別子（ユーザＩＤあるいはＵＩＤ）を入力することによって、あるいはディレクトリサービスのサーチを初期化することによって、新たなコンタクトを行うことができ、ここでディレクトリサービスは、名前や、電話メール等の様々な条件に従ってサーチを行うことができる。ユーザに割り当てられるＵＩＤの例を図１２（ｂ）に示す。
【００７１】
クライアント１１のアーキテクチャは、アドオンＳＤＫの使用によって公開することができる。これは、開発者にクライアントへ新規のタイプ（群）の通信モジュールを追加することを可能にし、例えば、いくつかのリモートサービスでデータ通信セッションを確立することを可能にする。この方法では、クライアントは、より複雑なアプリケーションの基礎として使用することでき、なおかつ、基本的なユーザ全体、かつ基本クライアントによって提供されるセキュリティモデルに対して有益である。また、クライアント／サーバプロトコルは、完全に新規なタイプのクライアントを生成するために使用することができ、これは、開発者に他から自身をユーザとして明示するサービスを統合することを可能にする。クライアントに使用されるセキュリティプロトコルはＳＳＨ（セキュリティ強化版シェルプロトコル）であることが好ましく、これは、通常、今日で最も高度なプロトコルと考えられている。これは専用ポート番号２２を使用し、これは、通常、多くのファイヤウォール上で公開されている。アドオンによって確立された通信セッションに対しては、セキュリティはアドオン開発者と使用される通信プロトコルによって行われる。すべての情報はログインユーザを特定し、例えば、ユーザのコンタクトリストと受信ボックスがクライアント装置上にキャッシュされて暗号化される、これにより、常連のユーザに対するネットワークトラフィックを最小化する。クライアントは完全にローカル化され、かつ特定オペレータに対して印象付けることができる。
【００７２】
サーバ３に対しては、本発明の実施形態に従うサーバ構成例では、サーバ３と１つのデータベース１３のネットワークを含んでいる。このような最小構成はクラスタと呼ばれ、システム／ネットワークの小管理構造を表している。各サーバ３は、ある構成のサービスを実行するように構成することができる。このようなサービスのそれぞれは、本発明のシステム／ネットワークのいくつかの部分の統合構成あるいはオペレータによってインストールされる付加サービスである。利用可能な基本サービスの１つは、クラスタ１へのクライアントのアクセス（群）を処理する接続及び認証サービスである。これは、ＩＰネットワークのクラスタへのアクセスのシングルポイントであり、そうでなければ、クラスタは信頼のあるあるいは安全が確保されたＬＡＮ内で実行するものとして想定されるべきである。このサービスを実行するサーバ３をより多く追加することによって、潜在的に多数の同時接続を処理するためにクラスタ全体を変更することができる。別のサービス群はユーザ７に関連し、情報リクエスト、オンラインステータスの伝搬及びインビテーションの転送を処理する。また、これらの機能もこれらのサービスを実行するサーバ３をより多く追加することによって変更することができる。そして、特定サービスは他のクラスタとの接続を処理し、これは、異なるクラスタかつプロバイダからの通信をユーザに可能にする。サーバ３のリンクは、その詳細を以下で説明する。
【００７３】
クラスタ１のこれらのサービスのすべてがデータベース１３と対話でき、このデータベース１３はすべての永続的なデータのリポジトリである。これは、ユーザ特定データ、サービス特定データ及び管理データを含んでいる。データベースは変更することができ、冗長性を持たせ、オペレータが要望する条件をすべてを満足する耐性を持たせることができる。オラクル（Oracle）データベースを使用することもでき、システム／ネットワークは他のタイプのデータベースに適合させることができる。つまり、本発明の一実施形態では、すべての情報がユーザのクラスタ１のサーバ側のデータベース１３に集中して記憶され、ユーザ７がログインするとユーザのクライアント１１へダウンロードされる。これは、予備カスタム化をすることなくシステム／ネットワークと互換性のあるインストールされた任意のクライアントを使用することを可能にする。
【００７４】
コンタクトリストからユーザを選択することによって、様々な機能が選択ユーザ７に対し利用可能になる。これを開始すると、選択ユーザ７は、与えられるコンタクトに関する情報（例えば、リスト上の選択ユーザ）を表示することができる。この情報は、自身に実際に定義されるコンタクト、例えば、好みのニックネームや他のパブリック情報である項目の組み合わせとなり得る。加えて、選択ユーザ７に利用可能となる機能は、リスト上の選択コンタクトへインビテーションを送信する機能がある。本明細書では、インビテーションの概念はかなり一般的なものであり、ＳＩＰ（セッションインビテーションプロトコル）と呼ばれる受信標準プロトコルを使用することができる。先に上述したように、インビテーションはあるユーザ７から別のユーザ７へ送信されるリクエストであっても良く、このリクエストは、与えられるタイプの通信セッションで呼出ユーザ７と接続するための質問を他のユーザ７へ行う。これに対して、電話である人の電話番号をダイヤルすることは、本質的に（電話呼出の形態で）インビテーションをその人の電話番号へ送信することである。
【００７５】
どのようなインビテーションが送信できるかには制限はない。送信ユーザ７は、少なくとのいくつかの基本的なタイプのインビテーションが提供され、また、対応する通信セッションが確立する場合にそれを処理するために必要なロジックが提供される。図９では、以下のような、これらの基本的なタイプが含まれており、１）ページ：これはショートテキストメッセージからなる（これは最も単純なタイプのインビテーションであるが、受信先からの応答確認を含まない）、２）テキストチャット：これはユーザ間のリアルタイムのテキストチャットセッションを確立できるインビテーションである、３）音声チャット：これはユーザ間のリアルタイムの音声セッションを確立できるインビテーションである、４）Ｗｅｂ会議：これはＷｅｂ上でユーザにナビゲーションを共有することを可能にするインビテーションであり、こうすることで、あるユーザのＷｅｂナビゲーションは他のユーザのブラウザに反映される。
【００７６】
本発明の実施形態に従えば、注目すべき構成はインビテーションが受信先でどのように処理されるかである。実施形態では、インビテーションは送信ユーザ７から直接受信ユーザ７あるいは受信ユーザのクライアント１１へ決して送信されない。これに対し、上述したように、少なくとも１つのＲＳが利用される。確かに、インビテーションはオンラインステータスに関係なく、つまり、受信側がオンラインでなくても送信することができる。インビテーションは、受信ユーザのユーザサーバ（ＵＳ）上で継続的に動作する受信ユーザのＲＳへ提供される。受信ＲＳは、ユーザ特定ロジック及び利用可能なバックエンドサービスに従ってインビテーションで何を実行するかを決定する。簡単な例として、シンプルテキストページは、プリファレンスに従って、３つの異なる方法で処理される：ユーザは、自身がオンラインである場合にそのページを直ちに通知することを選択することができる（例えば、図３）。また、ユーザは、「干渉無用」の状態でオンラインの場合に、メッセージを後で読むために自身のインボックスに入れることを指定することができる。そして、ユーザは、自身がオンラインでない場合に、テキストページをＳＭＳメッセージとして自身の移動電話（あるいはいくつかの他のページングネットワーク）へ送信することを決定することができる（例えば、図４）。他のタイプのインビテーションすべてに対して、同じことを適用する。つまり、サービスがオペレータによるバックエンドで提供される場合は、音声チャットインビテーションは実際には電話発呼として終了することができる、あるいはユーザ間がオンラインである場合は、音声チャットインビテーションは真のＩＰ発呼として実行することができる。
【００７７】
この機能は、本発明のシステム／ネットワークにより多くのサービス及びネットワークが関わるにつれて、ますます便利になる。また、携帯電話やＰＤＡのような他のタイプ（群）の端末へクライアント１１を拡張することの基礎となる。複雑になると、転送サービスは、発呼者（招待者）と被呼者（招待客）の両方に対する利益をもたらす。被呼者に対しては、与えられる時間でどのようにして人間／ユーザ７を位置決めし交信したかについての複雑な詳細は隠蔽される。つまり、本発明の一実施形態は、本質的にユーザ７に対して固有識別子を定義し、これは、利用可能なすべての通信プロトコル／タイプを使用しながら、かつ高レベルな安全性及び匿名性を維持しながら、他のユーザかつ／あるいはサービスと通信するために使用することができる。
【００７８】
最小構成は、必要なサービスをすべて実行する単一のサーバ装置と、データベースを実行する１つの装置とで構成することができる。しかしながら、実施形態では、複数のサーバ３が、本願の図面で示されるように各クラスタ１で提供される。
【００７９】
クラスタ１の管理は、特定管理クライアントによって処理されるのが好ましく、この特定管理クライアントはデータベースレコードを操作して、クラスタから発行されたアラートやログを表示する。
【００８０】
つまり、上述の内容からわかるように、本発明のシステム／ネットワークは負荷が軽いサーバ構造であり、単純でかつ安全が確保されたユーザモデルを提供し、外部サービスへインビテーションを転送する。このように、どのようなサービスがシステム／ネットワークに接続するかについて、厳しい制限（群）はどれも課されないままで、ユーザとの統一インタフェース及び課金を可能にする。異なるクラスタのユーザは互いに通信することができるが、実際のパーソナルユーザ情報は、ユーザが登録されているクラスタの管理範囲内で安全に保持される。
【００８１】
本発明の構成のより詳細説明を以下に説明する。
【００８２】
スケラービリティに関しては、本発明の一実施形態では、数百万の同時オンラインユーザに対し、バックエンドは、１０００万ユーザ単位でユーザをサポートすることができる。実際には、これは、バックエンドが、装置、プロセッサ、プロセス、スレッド等の間の各クラスタ内で、負荷を複数のクラスタに分散して負荷を均一にして、仮想的に無制限のスケラービリティを持てることを意味する。自身の単一クラスタ１は、自身のスケーラビリティに上限を持たせることができるが、分割された多くのクラスタ１の相互接続を行うバックエンド全体は、実際の制限なしで変更することができる。本明細書では、クラスタは、使用されるデータベース１３のスケーラビリティによってそのスケーラビリティが制限され、スケラービリティにおけるそれ以外の制限は存在しない。今日、データベース１３は、お金を投資することによってかなり柔軟に（但し、制限がないわけではない）変更することができ、これは、良好な設計事項として理解される。
【００８３】
耐性に関しては、ハードウエアの実行エラーから解放され、一実施形態では、各サーバの実働時間は約９９．９％となり、ネットワークの実働時間は約９９．９９％となることが好ましい。ハードウエアエラーのような例外エラーが発生した場合、最大３〜５分間の遅延は許容される。本質的には、これは、サーバ３が壊れる場合あるいは中断される場合には、別のサーバが自動的にそのサーバの役割を引き継がなければならないことを意味する。また、データベースあるいは（ネットワークのような）ハードウエア部分のようなシングルポイントの故障は耐性があるのが好ましく、それらが故障の場合は、自動的に他の部分が引き継ぐことが好ましい。
【００８４】
実用面からは、クライアントとバックエンド間の通信はできる限り安全が確保されていることがしばしば要求される。これに対する最良の方法は、クライアントへ接続する場合には認証を使用することであり、かつ強力な暗号技術を使用してクライアントとバックエンド間のすべてのメッセージを符号化することである。
【００８５】
本発明の一実施形態では、各オペレータは、自身のユーザグループにサービスを提供するためにサーバのクラスタ（あるいはクラスタ群）を動作することができる。これらの分散サーバクラスタは、コミュニティ全体を維持するために内部操作できることが好ましい。加えて、予備観測及び対策の両方を使用して、可能であれば、スパミングが防止されることが好ましい。
【００８６】
アーキテクチャ全体に対しては、アプリケーション設計の要求が標準に適していようとなかろうと、これらは使用されるべきである。また、バックエンドの基本サービスと統合する必要がある任意のアドオンサービスは、「プラグイン」の形態でその基本サービスと連結することが好ましい。
【００８７】
図１０を参照して、サーバ構造の全体に説明に戻る。各オペレータは、サーバ３の１つ以上のクラスタ１を動作させる。各クラスタ１は、高速で信頼性があり、かつ安全が確保されたＬＡＮ上で動作する。信頼性は、２つ（あるいはそれ以上の）の複製ＬＡＮを構成することによって向上することができる、つまり、複製ＬＡＮの数をｎとすると、ｎ−１／ｎの冗長性が得られる。セキュリティは、鍵付きの部屋の中でＬＡＮを維持することによって向上することができる。クラスタ１は、ネットワーク接続１７を介して相互に接続され、このネットワーク接続１７は高速であることが好ましいが、信頼性がなくかつ安全が確保されていない可能性がある。これは、本発明の一構成に従うネットワーク１７を介する通信が安全が確保されていないことを意味しているものではなく、ネットワーク１７（例えば、パケット交換デジタルネットワーク）がセキュリティを提供していないので、本発明の一構成がこれを提供することが好ましいことを意味していることに注意する。信頼性がないクラスタ内ネットワークに関わる理由は、クラスタ間の信頼性のあるネットワークに対する条件を必要としないことを意図するものであり、これは、オペレータが、ユーザが要求する場合に信頼性のあるネットワーク１９を設定できないことを意味するものではない。バックエンドに対する条件を考慮すると、図１０は、各クラスタ１のサーバ３の再分割を示している。更なる説明を以下に示す。
【００８８】
図１１は、複数のサーバ３とその中のデータベース１３を含むクラスタ１の例を示している。いくつかのクライアント１１は、クラスタ１に接続されている。クラスタ内のサーバ３は、ユーザサーバ（ＵＳ）１９、接続サーバ（ＣＳ）２１及びクラスタ内サーバ（ＩＣＳ）２３を含んでいる。以下に示す表１は、図１１のクラスタ１内のサーバ３が本実施形態で有する役割のリストである。
【００８９】
【表１】
0004444518.tif 000002
【００９０】
本発明の一実施形態では、サーバ３間の接続は静的である必要はない、ある意味では、２つのサーバ３内のソフトウェアエンティティが通信しない限り２つのサーバ間で接続は維持されない。しかしながら、サーバ３間の接続は共有されても良く、そうすることで、２つのサーバ間で接続が既に公開されている場合は、サーバ上の２つの付加ソフトウェアエンティティが対話しようとする場合の新規な接続を公開する以外は、既に公開されている接続の１つが共有される。
【００９１】
ユーザ識別及びマッピングに関しては、各ユーザ７はユーザＩＤ（ＵＩＤ）が与えられ、これは、アプリケーション全体を通して利用可能である。各クラスタ１はクラスタＩＤ（ＣＩＤ）が割り当てられる。ＣＩＤは、図１２（ｂ）に示されるように、周知の方法で各ＵＩＤに符号化される。各ユーザサーバ（ＵＳ）１９は、ユーザサーバＩＤ（ＵＳＩＤ）が与えられる。ユーザマッピング機能（ＵＭＦ）２５の役割は、ローカルＵＩＤ（ローカルは、それらのＣＩＤがローカルクラスタ識別子であるという事実によるものである）をＵＳＩＤにマッピングすることである。図１２（ａ）は、本発明の一実施形態でどのようにしてマッピング機能が動作するかの例を示している。このマッピングは動的であり、これは、ユーザサーバがクラスシュしたり、削除されたり、あるいはユーザサーバが追加された場合に変更することができるからである。
【００９２】
クラスタ内サーバ２３は、クラスタサーバＩＤであるＩＣＳＩＤが与えられる。各ＩＣＳは、ＣＩＤ群へマッピングするＵＩＤを有するすべてのリモートユーザ７を処理する。ＵＭＦ２５の役割は、リモートユーザのＵＩＤをＩＣＳＩＤへマッピングすることである。同様に、このマッピングは動的であり、同じ理由で、ローカルＵＩＤからＵＳＩＤへのマッピングに対しても当てはまる。識別ＩＣＳＩＤを有する各クラスタ内サーバ２３は、リモートＣＩＤ群（あるいはＣＩＤの一部）を処理する。ＵＮＦの役割はリモートクラスタ（即ち、リモートＣＩＤを有する）に属するＵＩＤをＩＣＳＩＤへマッピングすることである。同様に、このマッピングは動的であり、同じ理由で、ＲＩＤからＵＳＩＤへのマッピングに対しても当てはまる。
【００９３】
【表２】
0004444518.tif 000003
【００９４】
ＵＩＤはＵＲＩであり、例えば、joe@net.comの形態をとる。＠符号以降の部分は、ＣＩＤである。ＵＩＤの選択は、他のシステム、即ち、（セッション初期化のために使用される）ＳＩＰとの相互利用性及び互換性を達成する。
【００９５】
バックエンドと適切な耐性の性質は、一実施形態では、信頼性のあるネットワークプロトコルに対して発呼を行うことができる。また、システム条件は、認証されたかつ／あるいは暗号化され、安全が確保された通信媒体に対して発呼することができる。つまり、ＴＣＰ／ＩＰを介して動作するＳＳＨプロトコルは、一実施形態ではすべてのサーバ内通信に対して選択することができ、また、クライアントと接続サーバ間の通信に対して選択することができる。他のプロトコルが別実施形態で使用されても良いことが当業者に認識されるであろう。ＳＳＨは、「接続」と「ストリーム」と呼ばれる抽象化におかれる。接続は２つのコンピュータ間のエンドツーエンドの接続であり、この２つのコンピュータは認証かつ暗号化することができ、かつデータ完全性を提供することができる。ストリームはいわゆる、異なるコンピュータ上の２つのソフトウェアエンティティ間の双方向のフロー制御ストリームである。多くのストリームは、与えられる接続上で公開することができ、その接続において、ストリームは多重され別々にフロー制御される。共通点としては、接続を電気ケーブル、ストリームを電気ケーブル内の複層絶縁銅線とすることができる。
【００９６】
図１３は、本発明のシステム／ネットワークを示しており、このシステム／ネットワークは、いくつかの構成要素に分けることができ、また、構成要素間の従属関係がいくつか存在する。各構成要素は、システム／ネットワーク全体で様々な義務（群）を有している。
【００９７】
図示されるように、ユーザサーバ（ＵＳ）１９は、オンラインステータスサービス３１、ユーザ転送サービス（群）（ＲＳ）３３、デバイスハンドラ３５、セッションサービス３７、ユーザプロパティサービス３９、負荷分散サービス４１及びコンタクトリストサービス４３を含んでいる。接続サーバ（ＣＳ）２１は、オンラインステータスサービスプロキシ５１、コンタクトステータスサービス５３、いくつかの汎用プロキシ５４を含んでいる。クラスタ内サーバ（ＩＣＳ）２３は、いくつかの汎用プロキシ５５を含んでいる。これらのサーバそれぞれの下にあるフレームワークは、ＵＭＦ２５、ブロードキャスト通知５７、認証５９、Ｉ／Ｏモデル６１、プロトコルコンパイラ６３、リソース及び故障検出６５を含んでいる。運営及び管理（Ｏ＆Ｍ）サーバ（群）６４は、一実施形態では、システム構成（例えば、ユーザの提供／割当）かつ／あるいはサーバ／クライアントの監視を行う。
【００９８】
更に、図１３において、オンラインステータスサービス３１は、ユーザのオンラインステータスを記憶し、その変更をそのユーザに加入されているコンタクトステータスサービスへブロードキャストし、オンラインステータスサービスプロキシ５１はクライアント１１とＵＳ１９間に位置し、クライアントのユーザのオンラインステータスを変更するためのリクエストを送信する、また、クライアントのＵＳが故障している場合の故障トレーランスを行う。ＵＳが故障している場合、プロキシ５１はＵＳ１９へのコンタクトを試行し、ＵＳがクラッシュした後にユーザに対してＵＭＦ２５が割り当てられ、そのサーバ上でユーザのオンラインステータスを確立する。コンタクトステータスサービス５３は、自身のクライアントのコンタクトリストからユーザ毎のオンラインステータスに加入する。コンタクトリストサービス４３は、各ユーザのコンタクトリストを記憶し、ユーザ７へそれへのアクセスかつ管理を可能にし、更に、他のサービスにそれを読み出すことを可能にする（遮蔽リストがコンタクトリスト中の１グループであっても良い）。転送サービス（ＲＳ）３３はユーザからメッセージを受信し、それを転送ロジックに従って正しいデバイスへ送信する、この正しいデバイスとは、送信ユーザ及び受信ユーザの両方に位置しているものであり、ユーザによって設定される。ＲＳ３３は、ユーザにこれらの転送テーブルへのアクセス及び管理を可能にする。
【００９９】
汎用プロキシ（群）５４、５５は、ＣＳ２１あるいはＩＣＳ２３上に位置している。この構成要素の義務は、ＵＳ１９上に存在する多くの様々なサービスに対し無応答のバイト送信プロキシとして動作することである。サーバの各デバイスハンドラ３５はメッセージを受信でき、それをユーザあるいは外部システム（例えば、ＳＭＳ）へ送信し、そこに記憶し、そこで動作する等ができる。つまりデバイスハンドラ３５は外部システムへのブリッジとして動作することができる。ユーザプロパティサービス３９は、ユーザ７に自身のユーザプロファイルを読み出し変更することを可能にし、かつユーザがアクセスした他のユーザ７のプロファイルの部分を読み出すことを可能にする。
【０１００】
認証５９は、最初にクライアント１１がバックエンドと接続する場合にそのクライアント１１の認証を行う、また、この認証５９はフレームワーク構成要素６７の一部である。ブロードキャスト通知５７は、バックエンド構成要素に、クラスタ内の他の構成要素へいくつかのチャネル上でのメッセージのブロードキャストを可能にし、かつあるチャネル上のメッセージを確認することを可能にする。また、ブロードキャスト通知５７は、図１３に示されるように、フレームワーク構成要素６７の一部である。プロトコルコンパイラ６３はそれ自身がシステムの一部である必要はないが、それによって生成されるコードはシステムの一部となる（システムに対して生成される各サービスの一部）。プロトコルコンパイラ６３はＰＤＬ（プロトコル記述言語）ファイルをコンパイルし、これは、クライアントとサーバ間あるいはサーバ間でのプロトコルの抽象化定義をクライアントとサーバの両方に対するコードにしたものであり、このコードは、これらのプロトコルの転送を実行し、かつプロトコルメッセージがどのようにしてクライアントとサーバ間で返信され送信されるかの複雑性を遮蔽する。Ｉ／Ｏモデル６１はスレッドの記憶及び同期、データベース接続の記憶、Ｉ／Ｏ処理、時限アラーム等を行い、かつ他のサービスに対してこれらの処理を取り除く。リソース及び故障検出機能６５は、ＵＳ１９、ＩＣＳ２３及びＣＳ２１の故障を監視し、それらの１つが故障した場合にはブロードキャスト通知機構を介してメッセージをブロードキャストする。ここで、これは、ＣＳ、ＵＳ、ＩＣＳ及びＯ＆Ｍサーバ下のフレームワーク構成要素の一部である。ユーザマッピング機能２５はユーザＩＤをユーザサーバへマッピングする。この機能は、必要とされる場合にのみ定義されて取得する部分関数で、区分的に定義される。また、ある時点で使用されない部分関数を回収しかつ不定とする機構も存在する。この機能は、ＤＢ１３に対して行われる。この機能は、ＣＳ、ＩＣＳ（ユーザサーバＩＤ（ＵＩＤ）とクラスタ内サーバＩＤ（ＵＩＤ））に対するサーバへのユーザＩＤのマッピングを維持する。つまり、フレームワーク６７は、サービスを記述するための適正環境を提供する義務があり、これは、スケ−ラビリティ及び耐性を（サービスに対し）透過的に補償する。
【０１０１】
負荷分散サービス４１は、リソースの使用を負荷分散する形式で外部にあるリソースをクラスタへ割り当てる。本明細書でのこの概念は、クライアント１１が、アプリケーションの必須部分を形成し、かつ抽象化上クラスタの一部として割り当てられる（管理される）べきクラスタ内で実現されないサーバのサービスを使用とすることができることである。セッションサービス３７は、セッション生成、設定及び管理、更に、セッションのメンバー間のデータ転送を行う。
【０１０２】
管理ツールは、システム管理者に、システムの設定、新規ユーザの追加等の変更を可能にする。管理ツールは、システムに影響を及ぼす設定に対する変更をクラスタ内のすべての構成要素へ通知する義務がある。
【０１０３】
データベース抽象化層６９は、クラスタ内で使用されるデータベース１３への統一アクセス方法を提供する。データベース抽象化層６９は、ＤＢ１３内のユーザ定義（即ち、サービスクリエータによって定義される）オブジェクトであるいくつかのＬＤＯ（論理データオブジェクト）へのアクセスを提供し、これは、データベースに記憶されるいくつかのデータ構造に対する抽象化を提供する。
【０１０４】
フレームワーク６７の義務は、以下のものを含んでいる。
【０１０５】
Ａ．Ｉ／Ｏ、時限アラーム、スレッド記憶、メッセージブロードキャスト、データベース接続保存及びログ記録、サービスクリエータの複雑性の遮蔽のような事象を効果的に処理する環境を提供する。
【０１０６】
Ｂ．自身の存続を容易にするサービスクリエータへ抽象化を公開する。これらは、Ｉ／Ｏ、データベース及びそれに記憶されるデータ、アラーム、メッセージブロードキャスト（通知）及びログ記録に関連する抽象化を含んでいる。
【０１０７】
Ｃ．供給されるデータ抽象化内のデータキャッシュを実行する。
【０１０８】
Ｄ．有効である場合に既存データ抽象化オブジェクトインスタンスを再使用する。
【０１０９】
Ｅ．プロトコル記述を特定する非多義性方法を供給する。
【０１１０】
Ｆ．与えられるプロトコル記述であるコードを出力できる処理を実現し、このコードは回線を介してその符号を送信するためのプロトコルリクエストをどのようにして符号化するかの詳細及びフレームワークで供給されるＩ／Ｏプリミティブをどのようにして使用するかの詳細を提供する。本質的には、この処理は、サービスクリエータかつクライアント実行者からは遮蔽され、事実、サービスを使用するクライアントは同一コンピュータ上で動作しない。
【０１１１】
Ｇ．サービスのインスタンスを固有に識別し、かつこれらのレジストリを供給することで、接続は予め存在するインスタンスを実行することができる。
【０１１２】
Ｈ．サービスが同一サービスの他のインスタンスあるいは異なるサービスのインスタンスといつ通信するかという事実をサービスクリエータから遮蔽する、これらのインスタンスは、同一クラスタ内の異なるコンピュータ上あるいはリモートクラスタ内のコンピュータ上でさえにも存在することができる。
【０１１３】
Ｉ．通信における認証、セキュリティ及び完全性を補償することで、サービスクリエータはこれらについて常に気にする必要がなくなる。
【０１１４】
フレームワーク６７内のサービスに公開されるスレッドモデルは、時には、レンタルアパートと表現されるものである。アパートは、「その中では、テナントと呼ばれるコンテキスト」として定義される。テナントがアパートだけをレンタルするということは、テナントが同一コンテキスト（即ち、同一スレッド上で）で常に呼び出されないことを意味するが、これは、テナントがある時点では１つのアパートだけにしか存在しないからであり、同時に１つ以上のコンテキストでテナントが決して呼び出されないことを説明することに、これを拡張することができる（即ち、テナントによって所有されるコードで常にアクティブとなるスレッドは１つもない）。サービスは「所有されたテナント」である。これが意味することは、あるサービスのあるインスタンスに対するコードがテナントに付加されることである。それゆえ、サービスクリエータは、サービスを記述している場合にレンタルアパートモデルを想定でき、スレッドの発行を全く気にする必要がない。フレームワークは、最大値以上に必要とされるまでスレッドに付加されるスレッドの記憶を維持する。次に、これらのスレッドは、動作が必要とされる場合に再使用される。各スレッドは、単独で、かつある時点での１つのテナントの符号のみでアクティブとなる。動作が必要とされる場合に、フレームワークは、スレッドが利用可能になるまで待機し、そのスレッドに割当（処理を必要とするイベントの詳細）を渡し、その期間は利用不可能にする。スレッドが終了すると、そのことをフレームワークに通知する、フレームワークは、スレッド記憶で利用可能状態をスレッドに返答する。スレッド記憶を使用する理由は、多くのスレッドをいくつかの実行ジョブに分散することでパフォーマンスを最大限（システム依存）に向上するためである。これは、ある時点では最大数で動作するスレッドを持つことができることを意味するが、同期を必要とするいくつかのジョブを持ち、かつ利用可能な処理電力を公平に共有する必要が生じる。スレッド記憶方法は、これらの問題のすべてを解決する。
【０１１５】
Ｉ／Ｏ６１に対し、フレームワーク６７は、クライアントとサーバ間、クラスタ内のサーバ間及び異なるクラスタ内のサーバ間のすべての通信に対するＳＳＨ標準プロトコルの実現に使用することが好ましい。ＳＳＨは、すべての通信に対する認証、暗号化及び完全性を提供する。また、これは、接続及びストリームで呼び出される抽象化を供給する。ストリームは、フレームワークで使用されるメインＩ／Ｏ抽象化である。フレームワークは、ＳＳＨストリームと等価な抽象化をサービスに公開する。
【０１１６】
接続リクエストに関しては、フレームワーク内のサービスのインスタンスは、それに付加されるストリームだけに存在する。ストリームをサービスに付加する処理を以下に説明する。ストリームは２つの陽変数と１つの陰変数で公開される。この陽変数は、ストリームを公開するユーザのＵＩＤであり、これをソースＵＩＤと呼ぶことにする。陽変数はストリーム名であり、これを「ストリームタイプ」と呼ぶことにし、ＵＩＤは宛先ＵＩＤと呼ぶことにする。このＵＩＤは、異なるユーザのストリームあるいはＵＩＤを公開するユーザのＵＩＤであっても良い。上述したように、フレームワークの義務の１つはサービスのインスタンスを固有に識別することである。ここで、この固有の識別をどのように構成するかについて定義し、これは、上述したように、サービスと宛先ＵＩＤに接続されるストリームのタイプである。
【０１１７】
サービスを生成する場合、２つの主要部が生成され、１つは、ストリームに付加できるオブジェクトであり、これをストリームコネクタと呼び、もう１つは、接続リクエストとどこで接続するかを知っているオブジェクトであり、これをロケータと呼ぶ。サービスの実際の機能を実行する部分が生成されても良い。初期化時には、フレームワークレジスタに基づくサーバは、ストリームタイプ（群）の名前の下で、これを処理することを知っているすべてのロケータを登録する。任意のロケータは、あるタイプあるいはタイプ群のストリームに対する接続リクエストをどこで接続するかを知っているオブジェクトとして登録される。
【０１１８】
ここで、接続リクエストがどのように処理されるかについて説明する。フレームワークがストリームタイプＸ及び宛先ＵＩＤ  Ｙに対するＳＳＨからの接続リクエストを受信すると、フレームワークはストリームタイプＸに対して登録されているロケータを検出し、それを接続リクエストに渡す。ロケータは宛先ＵＩＤが何であるかに基づいて、その宛先ＵＩＤをチェックし、次のいずれか１つを実行する、１）新規テナント及び新規ストリームコネクタを生成し、その新規テナントにストリームコネクタを付加し、かつその新規ストリームと新規ストリームコネクタとを接続し、新規テナントを「ストリームタイプＸ及び宛先ＵＩＤ  Ｙに対するサービスに付加されるテナント」として登録することである（テナントを取得しなかった場合、サービスのインスタンスをどのようにして識別するかについて説明したことを思い出すことが重要である）、あるいは２）ストリームタイプＸ及び宛先ＵＩＤ  Ｙに対して既に登録されてた既存テナントを検出し、ストリームと、そのテキストに既に付加されたストリームコネクタとを接続することである、あるいは３）同一の（Ｘ，Ｙ）に対するテナントが既に存在しているかどうかに関わらず（上述の）新規テナントを生成することである。これは、ステータスを共有するためにサービスの「同一」インスタンスへの異なる接続が必要とされない場合に最適である。
【０１１９】
ストリームコネクタは、接続リクエストのソースＵＩＤを参照し、接続する人に基づいて接続を受け入れるかどうかを決定する。この点では、様々なサービスが別々のように振る舞う。実際には、単一のロケータは１つ以上のストリームタイプに対するロケータとして登録することができる。これは、単一のサービスが実際には１つ以上のストリームタイプからの接続を受け入れることができることを意味している。プロトコル記述で特定される別々のプロトコルが各ストリームを介して伝えられる事実を付け加える場合、１つ以上の真の抽象ベースクラスを引き継ぐＣ＋＋クラスを実現するようなビットを参照するために、このモデルが開始することが理解される。
【０１２０】
ここで、詳細を補償し、全体像を距離をおいて確認する。各サービスは「タイプ」（あるいはタイプ群）を有しており、このタイプは、サービスが接続を受け入れるストリームのタイプ（あるいはタイプ群）である。サービスの各インスタンスは、単一のユーザ（宛先ＵＩＤ）によって「所有」される。サービスクリエータは、ユーザが接続対象の（サービスタイプと宛先ＵＩＤ）ペアとサービスの単一インスタンスとのすべての接続を要求するかあるいは新規インスタンスを常に要求するかを決定することができる。
【０１２１】
ここまでは、接続対象のストリームを要求するエンティティがクライアントであることを想定している。サービスは、接続を要求するサービスのソースＵＩＤ、宛先ＵＩＤ及びタイプを特定することで、サービス自身でストリームと、同一のサービスの他のインスタンスあるいは異なるサービスのインスタンスと接続することができるという事実がある。これは、クライアントとサービス間及びサーバ間で抽象ストリームＩ／Ｏをサポートするフレームワークを有していることを意味している。
【０１２２】
「すべての処理対象のパーティ」がだれであるかを知ることなく、「すべての処理対象のパーティ」へブロードキャストメッセージ（通知として呼ばれる）を送信することを、サービスのインスタンスに対して必要とされることがしばしばある。フレームワークは、これを行うための、かつ処理対象となる通知を監視するための方法及び機能５７を供給する。フレームワークがサービスへ供給する抽象化は以下のようになる。サービスは、特定名のチャネル上で通知（これは、任意のデータの単なるバイナリパケットである）を送信できる。サービスは、チャネル名を特定するために監視することができ、かつこれらのチャネルの１つのチャネル上で通知を受信する場合にその符号への発呼を受信する。
【０１２３】
ＰＤＬはプロトコル記述言語の短縮形である。これは、クライアントとサービス間の非多義性定義プロトコルに対するフレームワークソリューションである（このコンテキスト内のクライアントについて説明する場合、ストリームが公開されているサービスについても説明する）。ＰＤＬコンパイラ６３は、ＰＤＬを入力として取得するソフトウェアツールであり、クライアント側及びサーバ側の両方へ多くのコードを出力する。クライアント側では、ＣＯＭ  ＤＬＬを出力し、これは、ＰＤＬが通常のＣＯＭオブジェクトである場合にプロトコルを使用することをクライアントアプリケーションへ可能にするプロトコルを特定するＣＯＭインタフェースを実現する。サーバ側では、２つのものを生成し、１つは、プロトコルに対しクライアントとして動作するためのサービスコードと、もう１つは、プロトコルを実現するサービスコードである。サービスを実現するコードは２つに分けられ、１つは、クライアントが、サービスとして同一処理空間に存在するＣ＋＋クラスである場合にクライアントへのコールバックをサービスクリエータに可能にするオブジェクトであり、もう１つは、サービスクリエータがプロトコルで定義される方法を実現することを引き出さなければならない真の抽象化であるＣ＋＋クラスである。これらの２つの部分は、配下のＩ／Ｏ抽象化がストリームであるという事実をサービスクリエータが無視できる（ユーザが、任意のＩ／Ｏが動作中であるという事実を完全に無視できる）ことをユーザが選択する場合のハイレベルの抽象化である。サービスクリエータが行わなければならない複雑性に対する唯一の容認事項は、すべての発呼が非同期であること、即ち、ユーザがクライアントへ「戻り値」を返信したい場合に、ユーザが新規な別の発呼方法を通してそれを実行しなければならないことである。プロトコルスタックを記述する労力を減らすためにＰＤＬとＰＤＬコンパイラ６３がフレームワークによって供給されるが、配下のストリーム抽象化がユーザがそれを使用することを選択する場合のサービスクリエータに対するものであることに注意する。また、ＰＤＬ生成コードは、その動作を変更するためにその内部のビットをプログラマに操作させることを可能にする。
【０１２４】
データベース抽象化レイヤ６９のジョブは、サービスクリエータにデータへのアクセスを容易にし、データをキャッシュし、データベース接続を記憶し、かつデータオブジェクトを再使用することである。サービスクリエータに対して見えるデータベース抽象化レイヤの主要部は、レジストリといくつかのＬＤＯ（論理データオブジェクト）である。ＬＤＯは、いくつかの特定タイプのデータに対して、即ち、リレーショナルデータベースの特定テーブルあるいはテーブル群に対する抽象化である。通常、これは、サービスクリエータ自身あるいは別のＬＤＯクリエータによって、サービスの生成と併せて生成される。ＬＤＯはデータのキャッシュを行うことができ、これはそれを実行することを選択する場合を示すものである。レジストリは、既存ＬＤＯが登録されている場所に存在する。サービスの類のＬＤＯは、タイプ、かつそれを「所有する」ＵＩＤによって登録される。サービスがＬＤＯを必要とする場合、サービスは特定ユーザによって所有される特定タイプのＬＤＯに対するレジストリを要求する。次に、レジストリはロケータが接続リクエスト上で動作する方法と同様な方法で動作する、即ち、リクエストされたタイプの新規ＬＤＯを生成するあるいは既存のＬＤＯを再使用する。データベース接続の記憶は、データベース抽象化レイヤによって維持される。これは、フレームワークによって維持されるスレッド記憶に対する機能及び設計に類似している。
【０１２５】
ＵＭＦ２５に対し、どのサーバ上でサービスの特定インスタンスが存在するかをフレームワークがどのように知るかを以下に説明する。サービスは、タイプ及び宛先ＵＩＤによって識別される。ユーザマッピング機能（ＵＭＦ）２５は不連続定義関数であり、これは、与えられるＵＩＤに対するサービスインスタンスが位置しているＵＳ上で特定する。サーバがダウンする場合、ＵＭＦはそのマッピングを変更し、そうすることで、そのサーバ上に存在したユーザは、ダウンしないクラスタ内のＵＳからのサービスを再接続しかつ受信することを直ちに可能にすべきである。サーバがクラスタに追加される場合、ＵＭＦは、クラスタの容量が一杯になるまで、新規接続のためのそのサーバを使用して開始する。ユーザマッピング機能（ＵＭＦ）２５自身はデータベースに記憶されるのが好ましいが、機能を正常に維持する処理を行うコードは、フレームワークに基づいて各サーバ３（１９、２１、２３）上で実現される。他のクラスタと接続されているクラスタ１では、２つのＵＭＦとして、内部ＵＭＦ及び外部ＵＭＦが存在するのが好ましい。内部ＵＭＦは、ＵＳ及びＩＣＳを配置するためにＣＳ及びＵＳによって使用され、また、ローカルクラスタＵＩＤに対するＵＳを配置するためにＩＣＳによって使用される。外部ＵＭＦは、外部ＵＩＤに対するＩＣＳを配置するためにＩＣＳによって使用される。
【０１２６】
フレームワークには論理部分（つまり、サービス）はないが、汎用プロキシ５４、５５はフレームワークで供給されるコアサービスの１つである。汎用プロキシは、あるストリームから別のストリームへバイト単位送信プロキシとして動作する。ＣＳ２１では、汎用プロキシ５４が、以下のように使用される。汎用プロキシは、バックエンドでアクセスを行うことをクライアントが要求する各プロトコルに対して登録される。汎用プロキシは、接続リクエスト（ｔｙｐｅ＝ｘ、ｓｒｃＵＩＤ＝ｙ、ｄｓｔＵＩＤ＝ｚ）を取得し、これを受け入れ、自身のフレームワークへ変数（ｘ，ｙ，ｚ）でストリームを公開することを要求する。内部ＵＭＦはＣＳ２１上で使用されるので、これは、宛先ＵＩＤｚを提供するＵＳ１９へストリームを公開する、あるいは存在するクラスタユーザｚのブリッジとして動作するＩＣＳ２３へストリームを公開する。他のタイプ（例えば、ＵＳかつ／あるいはＩＣＳ）のサーバ上では、汎用プロキシ５５が同様にして使用される。ここでの違いは、外部クラスタから受信する接続リクエストに対しては、内部マッピング機能が使用され、ローカルクラスタ内から受信する接続リクエストに対しては、外部マッピング機能が使用されることである。上述の説明から明らかなように、ＩＣＳ上のフレームワークストリームモデル、ＵＭＦ及び汎用プロキシは、サービスに、接続対象のサービスのタイプと接続対象のユーザのＵＩＤ以外の詳細を知ることなく、ネットワークに接続できる任意のユーザに対するサービスとの接続を可能する。
【０１２７】
転送は、ＵＭＦ２５によって指示される転送サービス（ＲＳ）３３によって行われ、これは、与えられるユーザに対するＵＳ上に存在する。例えば、ユーザＡはユーザＢへ図３のようなメッセージを送信し、以下のことを行う：１）ユーザＡのクライアントは、ユーザＡの転送サービスへメッセージを送信する、２）ユーザＡのＵＳ１９上のユーザＡの転送サービス３３は、そのメッセージと入力であるいくつかの変数で自身の「発信転送ロジック」を実行する（発信転送ロジックは、メッセージをユーザＢのＵＳ上のユーザＢの転送サービスへ送信することによって終了することになる）、３）ユーザＢの転送サービス３３は、ユーザＡの転送サービスからのメッセージを受信し、そこで自身の「着信転送ロジック」を実行する（着信転送ロジックは、（接続されている場合）ユーザＢのクライアントへメッセージを送信し、そのメッセージを記憶することによって終了することになる）。任意で、ユーザＡのクライアントはメッセージとその新規メッセージのポップアップウインドウを受信することができる。（転送サービスが適用される）メッセージはストリングであり、これは、例えば、ＳＩＰ標準に従ってフォーマット化されても良い。メッセージ本体のフォーマットは、メッセージタイプに依存する。与えられるユーザに対するＲＳ３３では、発信転送ロジック及び着信転送ロジックはメッセージをデバイスハンドラへ送信することを決定でき（かつデバイスハンドラがメッセージを処理すると、任意で、更にメッセージを処理する）、ユーザのメッセージボックスにメッセージを記憶でき、そのメッセージを異なるユーザの転送サービスへ送信することができるあるいはユーザのクライアントへメッセージを送信することができる。ユーザは、ａ）送信メッセージが受信者のメッセージボックスに記憶される場合に、ｂ）送信メッセージが受信ユーザのクライアントへ送信される場合に、送信の受領を送信することをリクエストすることができる。
【０１２８】
スパミング及びサービス拒否アタックを防止するために、複数の受信メッセージの送信は一実施形態では許容しないことがある。これは、クライアントが同一メッセージを１５のユーザへ送信したい場合に、つまり、クライアントが行うことは、即ち、同一メッセージを１５回送信することを意味する。これは、この実施形態では、サーバはユーザへのメッセージを多重するために使用することができないことを意味し、これによって、サービス拒否アタックの実行を困難にし、かつ複数の受取人へのメッセージの送信するための時間を節約する。
【０１２９】
本明細書では、デバイスはメッセージを受信できるものであればどのようなものでも良い。各デバイスは、（例えば、ＲＳ３３からの）特定メッセージタイプあるいはメッセージタイプ群を受信できる。また、各デバイスは特定タイプ、デバイスタイプを有している。これに関係するタイプはメッセージタイプ群があり、これは、任意で、デバイス（例えば、電話端末に対する電話番号）を識別するために使用する識別子タイプが何であるかを受信することができる。「デバイスハンドラ」と呼ばれるソフトウェア構成要素は、システム内のデバイスを示している。いくつかの場合、デバイスは完全な概念であり、かつデバイスハンドラ自身は、実際には、デバイスとしてみなされることができる。デバイスハンドラは、すべてのデバイスハンドラが同一プロトコルを処理できるという事実以外は、通常のサービスである。このプロトコルは、転送サービス３３にメッセージを処理用デバイスハンドラへ転送させ、かつそれをデバイスハンドラへ返送させることを可能にする。
【０１３０】
転送ロジック（即ち、メッセージで何を処理するかを決定するための選択を行う）は、転送ツリーと呼ばれる特定用途擬似プログラミング言語で、例えば、ＲＳ３３によって実現することができ、この転送ツリーは、本質的には、枝葉がないノードのすべてが決定ポイントであり、かつ枝葉ノードが動作ノードであるノード群のツリーである。決定ノードでの決定は、転送メッセージの内容、日時、データベースの一部の状態等を含むいくつかの変数に基づいて実行できる。各ユーザに対しては、いくつかの異なる名前の転送プロファイルが特定されても良い。各転送プロファイルは、転送ツリー特定転送ロジックを含んでいる。転送プロファイルは、クライアントによって定義されても良い。ある転送プロファイルが、受信メッセージを使用するための転送プロファイルとして常に動作する（使用するためのメッセージはクライアントによって定義されても良い）、また、クライアントがメッセージを送信するたびに、クライアントは、送信メッセージを使用するための転送プロファイルを特定する。このようにして、異なる転送プロファイルは、様々な状況に対して使用することができ、即ち、ある転送プロファイルはユーザの仕事中にある場合に対して、別の転送プロファイルはユーザが在宅中である場合に対して、また別の転送ファイルはユーザがオンラインである場合に対して等である。
【０１３１】
セッション初期化に対しては（即ち、セッションへ別のユーザを招待する、インビテーションを受諾する等）、一実施形態では、セッション初期化プロトコル（ＳＩＰ［１］）のサブセットを使用することができる。使用されるＳＩＰ方法は、例えば、ＩＮＶＩＴＥ、ＡＣＫ及びＣＡＮＥＬ方法を含んでいる。ＳＩＰは、例えば、インターネット技術特別委員会のインターネット草案のHandley／Schulzrinne／Schooler／Rosenbergによる「ＳＩＰ：セッション初期化プロトコル」で説明されている。１９９８年の８月に、これの開示があり、これは参照することによって本明細書に組込まれる。これらは、ユーザに対して、会議の初期化やや他のユーザの招待を行うことを満足し、あるいは２人のユーザに対して、ポイントツーポイント会議の初期化を行うことを満足する。セッションの記述に対しては、セッション記述プロトコルが使用される。セッション記述プロトコルは、例えば、インターネット技術特別委員会のＲＦＣ２３２７のM.Handley及びV. Jacobsonによる「ＳＤＰ：セッション記述プロトコル」で説明され、１９９８年の４月に、これの開示があり、これは参照することで本明細書に組込まれる。
【０１３２】
様々なタイプの転送スキームが、本発明で使用することができる。一実施形態では、システムプラグインが自身の転送スキームを定義でき、この転送スキームは、以下に説明される好適なスキームを同時に使用することになる。一実施形態では、以下の表３は好適な転送スキームのメッセージタイプ（例えば、ページ、自動リプライ、インビテーションリクエスト、インビテーションリプライ等）となる。
【０１３３】
【表３】
0004444518.tif 000004
【０１３４】
ユーザの「受信ボックス」は、ユーザの転送サービス３３の一部である。受信ボックスは、ユーザへの任意の種類のメッセージを受信する。受信が発生すると、受信ボックスは、ユーザがオンラインである場合にメッセージの通知をユーザ（あるいはユーザのクライアント）へ送信する。ユーザは、受信ボックスに記憶されているメッセージ識別子を列挙することができ、かつメッセージのそれぞれが既読あるいは未読であるかを列挙することができる。ユーザは受信ボックスからメッセージを検索し、そのメッセージに未読あるいは既読をマークしたり、そのメッセージを削除することができる。ユーザは受信ボックスにメッセージを記憶することもできる。一実施形態では、コミュニティオペレータはかなりの量の受信ボックス（即ち、大量のボリューム）を定期的にチェックして、ユーザがその受信ボックスを整理しない場合に、ユーザへ（そのユーザへのページングによって）その受信ボックス内の最も古いＸメッセージを削除することを通知し、整理が終了するまでの期限をユーザに与える。これは、管理ツール及びデータベーススキームの機能である。また、受信ボックスは、メッセージがマークされている場合に記憶中の受信メッセージの送信を行うことができる。
【０１３５】
図１４は、ネットワークの１つ以上のクラスタを使用して、第１ユーザ（例えば、ユーザ＃１）がどのようにして第２ユーザ（例えば、ユーザ＃２）と通信セッション（例えば、音声チャット、テキストチャット等）を確立できるかを示すフローチャートである。第１及び第２ユーザは、ネットワークの同一クラスタあるいは別クラスタに割り当てることができる。また、第１及び第２ユーザは、同一ユーザサーバ（ＵＳ）１９へ割り当てることもできるが、異なるユーザサーバ１９に割り当てることがより好ましい。開始すると、第１ユーザは第２ユーザへセッションに関するインビテーションメッセージ（即ち、ＩＮＶＩＴＥメッセージ）を送信する［ステップ１５１］。第１ユーザは、第１ユーザのコンタクトリスト上で第２ユーザのＵＩＤを参照することができる（ここで、ＵＩＤは、第２ユーザのネットワークアドレス、例えば、第２ユーザの電話番号あるいはＩＰアドレスを含んでいる必要はなく、これによって、通信セッションに関係する匿名性の度合を維持することに注意する）。第１ユーザのリクエストで、第１ユーザのクライアント（例えば、ＰＣあるいは電話）はＩＮＶＩＴＥメッセージを生成し、第１ユーザのＵＳ１９へ送信し、かつそのＵＳで第１ユーザのＲＳ３３へ送信する［ステップ１５３］。第１ユーザのＵＳ上の第１ユーザのＲＳ３３は、自身の発信転送ロジックを実行し、かつメッセージで何を処理するかを判定する［ステップ１５５］。ＲＳは、例えば、メッセージを無視することができるが［ステップ１５７］、（同一あるいは異なるクラスタでの）第２ユーザのＵＳ１９でメッセージを第２ユーザのＲＳ３３へ送信することを決定することが好ましい［ステップ１５９］。第２ユーザのＲＳ３３は、ＩＮＶＩＴＥメッセージを受信し、そのＩＮＶＩＴＥメッセージで何を処理するかを判定するために、第２ユーザによってプログラムされた自身の受信転送ロジックを実行する［ステップ１６１］。例えば、第２ユーザのＲＳ３３の転送ロジックは、以下のことをＲＳへ行うことができる、１）ＳＭＳメッセージとしてＩＮＶＩＴＥメッセージを第２ユーザの移動電話あるいはページャのようないくつかの他のページングネットワークデバイスへ送信すること（例えば、第２ユーザが現在オンラインでない場合）［ステップ１６３］、２）ＩＮＶＩＴＥメッセージを第２ユーザの受信ボックスへ送信すること［ステップ１６５］、３）ＩＮＶＩＴＥメッセージを第２ユーザの現在のオンラインクライアント（例えば、ＰＣ）へ直接送信すること［ステップ１６７］、かつ／あるいは４）ＩＮＶＩＴＥメッセージを別のユーザＲＳ３３へ送信すること［ステップ１６９］。４）の場合、別のユーザは、インビテーションを無視、辞退あるいは受け入れることができる［ステップ１７１］。そうでなければ、第２ユーザは、上述したように、ＩＮＶＩＴＥメッセージのインビテーションを無視、辞退あるいは受け入れることができる［ステップ１７３］。
【０１３６】
ページの送信とは別に、転送サービス３３の機能は、任意の種類のセッションでユーザと待ち合わせすることができるツールとして動作することであり、任意の種類のセッションは、電話発呼、テキストチャット、ビデオ会議あるいはその類がある。待ち合わせがどのようにして動作するかを示すために、いくつかの例を挙げることが最適であり、１つは両ユーザがそれらのコンピュータで存在している場合、別の１つはあるユーザが自身のコンピュータであり、かつ別のユーザ自身の電話を使用している場合、更に別の１つは両ユーザが自身の電話である場合である。どの場合でも、実行する発呼パーティは、発呼パーティの識別子（ＵＩＤ及びシステム／ネットワーク電話番号）以外の発呼パーティについての識別情報を知る必要がないことに注意する。実際には、発呼パーティは、発呼パーティが明確に許可されない限り、システム／ネットワークを介して発呼パーティのコンタクト情報を発見することは決してない。
【０１３７】
ＰＣとＰＣとの待ち合わせに対しては、例えば、図１５を参照すると、カール（Carl）がアン（Anne）とウイリアム（William）に問い合わせて、自身のテキストチャット会議に参加させることを想定する。カールは、自身のクライアント１１を使用してアンの招待を開始する。カールのクライアント１１は、（カールのＵＳ１９を実行する）カールのセッションサービスでセッションを生成することによって開始し［ステップ７１］、次に、セッションのアドレス（例えば、carl@phonecompany.com, session name）をＳＩＰ  ＩＮＶＩＴＥメッセージに符号化し［ステップ７３］、それをアンへ送信する［ステップ７５］。それぞれのユーザが自身のＲＳをどのようにプログラムしたかに従って、ＩＮＶＩＴＥメッセージはカールのＲＳ３３及びアンのＲＳ３３によって管理される。通常の場合、アンがオンラインであると、ＩＮＶＩＴＥメッセージはアンのクライアント（アンのＰＣ）へ送信される。次に、アンは、インビテーションの辞退を受け入れるかどうかを判定する［ステップ７７］。アンがインビテーションを受け入れる場合、彼女のクライアント１１はＩＮＶＩＴＥメッセージで符号化されたセッションとの接続が行われる［ステップ７９］。アンが辞退することを決定する場合、彼女はＩＮＶＩＴＥメッセージを無視することができる［ステップ８１］、あるいは辞退メッセージをカールのクライアントへ送信することができる［ステップ８３］。Ｗｉｌｌｉａｍを招待するために、カールはセッションへ追加するために自身のクライアントを使用する。ＷｉｌｌｉａｍはＩＮＶＩＴＥを受信し、それを同様の方法で受け入れ、そしてセッションに参加する。
【０１３８】
別の例を説明するために、ＰＣと電話との待ち合わせについて考える（例えば、図４参照）。カール（ユーザＡ）は自身のコンピュータ（例えば、ＰＣ）のところに存在し、アン（ユーザＢ）との音声チャットを要求する。カールは、自身のクライアント１１でこのオプションを選択し、上述のようにして、ＳＩＰ  ＩＮＶＩＴＥメッセージをアンへ送信する。しかしながら、アンは、自身のコンピュータのところに存在していない（即ち、アンのクライアント１１はオンラインではない）。メッセージを受信すると、アンの転送サービス３３は、彼女がオフラインであるが、カールからの音声チャットを彼女のＧＳＭ電話へ送信する彼女が要求していることを通知する。つまり、アンのＲＳ３３は、この種のＩＮＶＩＴＥメッセージを処理するために生成されるデバイスハンドラ１０を発呼するために、電話番号を使ってそのメッセージを送信する。デバイスハンドラ１０は、発呼中継局を自身に加える外部音声ゲートウェイでアンへの発呼中継局を設定し、彼が発呼する場合にアンに対して既に設定されている発呼中継局とカールとを接続する外部音声ゲートウェイにテンポラリ番号を設定し、そして、テンポラリ番号を設定するためにアンが一時的に移動されていることをカールのクライアント１１へ通知するＳＩＰ  ＩＮＶＩＴＥメッセージに対するリプライを返信する。カールのクライアント１１は、（いくつかのＩＰ電話システムを使用して）番号を発呼し、呼出を聞くと、アンが待ち合わせを完成するために応答する。
【０１３９】
別の例では、電話とＰＣとの待ち合わせについて考える。アンが、ウイリアムを呼び出すために、自身のＧＳＭ電話（即ち、アンのクライアント）を使用する。彼女は、彼の電話番号へかける（電話システムはアドレスとして電話番号だけをサポートし、システム／ネットワークＵＩＤをサポートしないので、この種のダブルマッピングが必要である）。音声ゲートウェイは、その電話番号に対し、アンの発呼設定リクエストを含む任意の発呼設定リクエストを受信する。音声ゲートウェイは、自身に加入するデバイスハンドラを呼び出し、発呼をどこに転送するかを質問する。デバイスハンドラは、ウイリアムのＵＳサーバ及びＲＳ３３を介して、ＳＩＰ  ＩＮＶＩＴＥメッセージをウイリアムへ送信する。ウイリアムは着信音声チャットを受け入れ、自身のクライアント（即ち、ウイリアムのＰＣ）に、電話番号を含むＳＩＰ  ＩＮＶＩＴＥに対する「受諾応答」を返信させ、彼のクライアントは、その待ち合わせに対して、彼が使用するＩＰ電話システムに登録される。ＲＳ３３のウイリアムの転送ロジックは、メッセージバックをかなり類似しているデバイスハンドラへ転送し、このデバイスハンドラはオリジナルのＳＩＰ  ＩＮＶＩＴＥを送信する。メッセージの受信においては、デバイスハンドラは、メッセージバックからの電話番号を音声ゲートウェイへ送信し、音声ゲートウェイはそれに従う発呼をウイリアムへ送信する。ウイリアムのクライアントは、ウイリアムが応答を決定する「着呼」ダイアログをポップアップする。
【０１４０】
更に別の例では、電話と電話との待ち合わせについて考える。ウイリアムがカールへ発呼することを想定する。彼は、自分の電話（ウイリアムのクライアント）を取り上げ、カールの電話番号へダイヤルする。この場合は、上述のカールのＲＳ３３の自身の転送ロジックが彼がオフラインであることを通知する以外は上述の電話とＯＣとの待ち合わせの場合と同じであり、つまり、カールによる指示／プログラミングは、ＩＮＶＩＴＥメッセージ及び電話番号を送信し、彼がオフラインである場合に対して、彼は、「一時的に移動された」メッセージでＩＮＶＩＴＥへのリプライを行うデバイスハンドラを特定し、これは、ＩＮＶＩＴＥを生成したデバイスハンドラへそのメッセージへの返信を行い、更に、特定番号へ発呼を送信する音声ゲートウェイへ返信する。
【０１４１】
上述したように、他のユーザのオンラインステータス、自身（ユーザ７が自身である場合）の設定オンラインステータスを把握したり、自身のコンタクトを階層リストに記憶するようなことを容易にするサービスも利用可能である。これらのサービスは、以下の構成要素によって提供され、：オンラインステータスサービス３１、オンラインステータスサービスプロキシ５１、コンタクトステータスサービス５３、コンタクトリストサービス４３である。
【０１４２】
図１６は、ユーザサービスによって各ユーザサーバ（ＵＳ）１９上で維持されるデータ構造を示している。これは、最も重要なデータ要素を示す大まかな部分だけを示している。図１７は、同様にして、各接続サーバ上のコンタクトステータスサービスに対するデータ構造を示している。これらの両データ構造は揮発性であることが想定され、かつ効率性のためにメモリに保存することができる。ユーザのオンラインステータスは、ユーザをあるコンタクトとして監視するＣＳ（群）２１によって信頼のあるＵＳ１９から得られる。ユーザのクライアントに接続されているＣＳは、（ユーザサービス／ユーザサービスプロキシを介して）ユーザのオンラインステータス及びそのコンタクトリストを更新できる。ＵＳ１９は、ロードされていないユーザ上のコンタクトリストリクエストを取得すると、データベースからユーザデータをロードする。ユーザデータは、ＣＳ２１がそれを使用している間、ロードが維持される。すべてのＣＳがデータを解放すると、メモリからのアンロードが可能となる。データは、わずかな時間でロードを早急に可能にするキャッシュ形式で保持されていても良い。リストのバージョン属性は、ＣＳに記憶されているデータのバージョン番号をチェックし、かつＵＳに記憶されているデータのバージョン番号と比較することによって、ＣＳのキャッシュをいつ更新するかを知ることを可能にするためのものである。
【０１４３】
ＣＳ２１上のコンタクトステータスサービス５３では、各接続ユーザは、コンタクトリストを有している。コンタクトステータスサービスは、各コンタクトのオンラインステータスへ加入し、これは、ＵＳ上の対応するユーザサービスを監視している。ユーザサービスの義務は、送信ステータスが更新される場合の遮蔽ユーザをフィルタアウトすることである。図１８ａは、コンタクトリストサービス４３に対して記憶されるデータ構造を示している。この情報はデータベース１３に記憶され、必要に応じて検索される。各ユーザは遮蔽リストを１つ及び可視リストを１つ有し、ある時点ではどちらか１つがアクティブとなっている。遮蔽リストがアクティブである場合、その遮蔽リスト中のユーザ以外のすべてのユーザは、そのユーザのオンラインステータスを確認することができる。一方、可視リストがアクティブである場合、可視リスト上のユーザだけがそのユーザのオンラインステータスを確認することができる。
【０１４４】
図１９では、本発明のシステム／ネットワークへのアクセスのために、ユーザ７は、まずログオンしなければならない。図１９は、ユーザＵ1がシステムにログオンしている場合のメッセージシーケンスの例を示している。ＣＳ２１が認証リクエストを受信して、有効性のためのパスワードをまずチェックする。ユーザは、未登録等であることがある。次に、認証が実行される。この例では、ユーザのＵＩＤは以前に使用されていないものとする。そのため、ＣＳは、ＵＳＩＤに対するＵＭＦを質問しなければならない。ＵＭＦ２５は、そのＵＩＤによって生じる負荷を少なくとも伴いながら、利用可能なＵＳ１９を選択する。ここで、ＣＳは、信頼性のあるＵＳ１９上のＵ1に対するオンラインステータスを設定し、コンタクトリストを検索する。この例では、Ｕ1は１つのコンタクト、即ち、Ｂ1とのコンタクトがある。このコンタクトに対するステータスは、そのコンタクトの対応するＵＳからフェッチされなければならない。その後、ＣＳはＢ1のオンラインステータスへ加入する。コンタクトユーザＢ1のＵＳ１９は、Ｂ1がオンラインである場合のみリプライを行う。ＣＳ及びクライアントは、それらがステータスメッセージを受信するまでコンタクトがオフラインであるデフォルト状態であると仮定する。
【０１４５】
図２０は、ユーザＵ1がバックエンドをログオフする場合のメッセージシーケンスの例を示している。ここで、ＣＳ２１は、Ｕ1に対して応答可能なＵＳ１９へログオフメッセージを送信する。ＵＳは、ステータスメッセージをすべての加入者へ送信し、ユーザデータを保存し、かつそれをアンロードする。
【０１４６】
図２１は、コンタクトＢ1がログオン及びログオフする場合のメッセージシーケンスの例を示している。ユーザＵ1は、ユーザＵ1のコンタクトステータスサービスを介してＢ1を監視している。コンタクトユーザＢ1がオンラインになると、ユーザＢ1のＵＳはＢ1のオンラインステータスを加入しているすべてのＣＳ２１へ送信する。同様にして、ユーザは、ステータスが監視されていることを知っているコンタクトユーザＢなしで、システム／ネットワークを通して異なるコンタクトユーザＢのステータスを監視できる。
【０１４７】
図２２は、ユーザ７が自身のコンタクトリストへコンタクトを追加し、それを削除する場合のメッセージシーケンスの例を示している。ＵＳの義務は、データベース１３で更新されるコンタクトリストを維持することである。ユーザが、別のユーザのコンタクトリスト上のコンタクトとして追加あるいは削除される場合、一実施形態では、図２２に示されるように、別のユーザのコンタクトリストに追加されたユーザは通知を受信する。ユーザ７は、同一クラスタに割り当てられているあるいは割り当てられていない他のユーザをそのユーザ７のコンタクトリストへ追加することができる。
【０１４８】
図２３は、ユーザがシステム／ネットワークの別のユーザを自身の遮蔽リストへ追加し、削除する場合のメッセージシーケンスの例を示している。ＵＳの義務（即ち、追加するユーザ７のＵＳ１９の義務）は、一実施形態では、データベース１３で更新される遮蔽リストを維持することである。ユーザＡがユーザＢを自身の遮蔽リストへ追加する場合、ユーザＢはそれが実行されたことの何らかの通知を受信しないことに注意する。これは、ユーザＢが自身がユーザＡの遮蔽リスト上にあることを知るべきでないという思想である。図２４は、ユーザが自身の遮蔽ユーザリストを反転する場合のメッセージシーケンスの例を示している。このシーケンスは、ユーザが遮蔽リストに追加される場合のシーケンスと同様である。
【０１４９】
図２５の説明は、コンタクトリスト機能に対して必要とされるデータベース１３操作の概要である。図示されるように、一実施形態では、与えられるユーザ７のユーザサーバは、特定ユーザのコンタクトリスト機能に関するほとんどの動作に対して応答可能である。
【０１５０】
セッションサーバ３７は、セッション管理を行う。セッションを初期化する（即ち、会議を生成するあるいはファイル転送を初期化する）ユーザは、セッションを所有している。他のユーザ７は、セッションとどのように接続するかについての指示を含むセッションへのインビテーションを取得する。セッションの主催者は（通常のメッセージ転送機構を介して）他のユーザを招待でき、あるいは、グループからユーザを排除でき、あるいはユーザがオブザーバとなるようにユーザをミュートでき、かつ／あるいはセッションを退出するためにすべてのユーザから生じるセッションを終了することができる。セッションへのエントリは、インビテーションだけによるものであり、これは、会議へ参加するユーザのリストを維持するセッション管理サーバによって処理されることが好ましい。セッションの主催者は、自身が他のユーザを招待する場合にそのリストへ追加する。
【０１５１】
各ユーザ７に対しては、あるデータ群が記憶される。このデータは、プロパティと呼ばれるキー／値ペアで保持される。これらは、参照するために、すべてのユーザに対してグローバルにすることができ、あるいはユーザ自身だけがアクセス可能にプライベートにすることができ、あるいはアクセス制御することができる。図１８ｂは、本発明の実施形態に従うユーザプロファイルに対するデータ構造を示している。与えられるユーザのユーザプロパティサービス３９は、これに関する機能及び記憶を制御する。また、「ユーザ検出」サービスが、一実施形態では、ユーザプロパティ（ユーザプロパティサービス３９と同じプロパティ）をサーチすることによって、クライアントに他のローカルクラスタユーザのユーザＩＤを検出することを可能にするために提供されても良い。
【０１５２】
各クラスタに対しては、単一のスケーラブルで、耐性のあるリレーショナルデータベース１３が存在し、このリレーショナルデータベース１３は、永続的であるべきシステムで使用されるデータのすべてを含んでいる。小規模の構成では、これは、ＯｒａｃｌｅやＩｎｆｏｒｍｉｘのようなデータベースを実行する単一のコンピュータであっても良い。かなり多数のユーザとより強い安定性が要求される大規模の構成では、同一データベースへの読み書きを行う高パフォーマンスコンピュータのクラスタが使用され、このデータベースは、例えば、ミラー化されたホットスワップ可能なＲＡＩＤ機構上に配置される。このようにして、小さくかつ安価な構成を実行するオプションを失うことなく、任意のレベルの冗長性が達成でき、かつ任意数のユーザを実際に扱うことが可能になる。データベース１３は、各ユーザに対して維持されるプロファイル情報を含むことが好ましい。また、データベースは、各ユーザに対するコンタクトリスト及び遮蔽リストを含んでいる。コンタクトリストは、ユーザが１つ以上のグループに所属することができ、かつグループはそれに含まれるすべてのユーザ及びそれに含まれるグループでの繰り返し使用できるすべてのユーザを含む階層グループである。また、データベースに記憶されるものは、どのプロファイルが現在アクティブであるか等を説明するデータに従う、各ユーザの異なる転送プロファイルに対するデータである。各ユーザの受信ボックスは、データベースに記憶されているのが好ましい。これは、情報が既読であるか未読であるかの情報に従うメッセージのリストであり、記憶時間によって配置されている。また、リストに記憶されているものは、メッセージに対するトランザクション履歴がある。トランザクションは、ＡＤＤＥＤ（追加）、ＤＥＬＥＴＥＤ（削除）、ＤＥＳＴＲＯＹＥＤ（破壊）、ＭＡＲＫＥＤ  ＲＥＡＤ（既読マーク）及びＭＡＲＫＥＤ  ＵＮＲＥＡＤ（未読マーク）が含まれる。ＤＥＬＥＴＥＤ及びＤＥＳＴＲＯＹＥＤトランザクションは、サーバシステムに関しては同じであるが（即ち、これらのトランザクションはデータベースからメッセージを削除する）、クライアント内での柔軟性を向上するために２つの別トランザクションとして維持される（例えば、クライアントがローカルキャッシュかつサーバからのメッセージを削除したい場合にクライアントはＤＥＬＥＴＥＤを使用でき、サーバからのみメッセージを削除したい場合にはクライアントはＤＥＳＴＲＯＹＥＤを使用できる、異なるトランザクションは、クライアントの他のインスタンスに、同一のエンドユーザ処理を提供させることを可能にする）。また、バックエンドサーバに対するすべての設定は、一実施形態では、システムのログとして、データベースに記憶され、このログは、管理用及び構築用のログの両方である。また、各ユーザのクライアントの設定も、一実施形態では、例えば、ファイヤウォール設定のようなクライアントの位置を処理しなければならない設定以外は、データベースに記憶される。
【０１５３】
スケラービリティについては、そのスケラービリティの判定で使用する数学的モデルを定義する。ここで、以下の表４で参照される。
【０１５４】
【表４】
0004444518.tif 000005
【０１５５】
ＵＳ（ＣＳは転送に関与していない）上でどれくらいの転送サービスの負荷が生じるかについてのＮ及びｎに影響を与えるものが何であるかを考える。ここでは、以下の簡略化を仮定する、１）オンラインユーザはすべてのＣＳ上で等価的に分散される。各ＣＳ上の接続ユーザ数は、ｎ／Ｎcsである。２）転送ロジックλに基づく単一のメッセージに対する転送を決定することを、処理が要求する。３）メッセージをその宛先へ送信することを、処理が要求し、それに対し一旦判定される転送は定数μである。４）タイムユニット単位でユーザ毎に転送される必要があるメッセージ数は定数Ωである。これらの仮定が与えられると、転送サービスは、以下の関係で各ＵＳ上で負荷を発生する。
【０１５６】
【数１】
0004444518.tif 000006
【０１５７】
（λ＋μ）・Ωは定数であるので、ここで、Ｎcsを増加させることによって、各ＵＳ上のサービスで生じる負荷をｎの増分を一定に維持することができる。
【０１５８】
接続サーバ２１に関して、各ＣＳ上のコンタクトリストサービスによって誘引される負荷についてＮ及びｎに影響を与えるものが何であるかを考える。ここでは、以下の簡略化を仮定する。
【０１５９】
・オンラインユーザは、等価的にすべてのＣＳに分配される。各ＣＳ上の接続ユーザ数は、ｎ／Ｎcsである。
【０１６０】
・すべてのコンタクトリストのサイズはｆである。
【０１６１】
・タイムユニット単位でユーザ毎のクライアントからのイベント数は一定である。このようなイベントは、ログオン、ログオフ、ユーザステータスの変更、ユーザのＢ（ｕ）への追加、Ｂ（ｕ）からのユーザの削除等を含んでいる。その結果、タイムユニット単位の加入コンタクト毎のＵＳからの加入メッセージ数も一定である。
【０１６２】
・以下の最終的な仮定として、単一の接続クライアントからのイベントによって生じるＣＳ上の負荷は、αで示される定数であることを仮定する。加えて、単一のコンタクトからの加入イベントによって生じるＣＳ上の負荷は、βで示される定数であることを仮定する。
【０１６３】
・各ＣＳ上の接続ユーザは、同一ＣＳ上の他の接続ユーザとの共通のコンタクトは持たない。また、接続ユーザは同一ＣＳと接続するコンタクトを持たない。これは最悪の場合であり、通常は、接続ユーザはいくつかのコンタクトを共有する、即ち、２つの接続ユーザｘ及びｙは、同一のコンタクトｚの以下のオンラインステータスで処理される、つまり、ユーザｘ及びｙはコンタクトｚを共有する。これが与えられると、任意のＣＳは、ｆｎ／Ｎcsユーザに加入しなければならない。
【０１６４】
これらの仮定が与えられることによって、任意のＣＳ上のサービスによって生じる負荷は、以下のような関係と見ることができる。
【０１６５】
【数２】
0004444518.tif 000007
【０１６６】
α＋ｆβは定数であるので、より多くのＣＳをネットワークへ追加することによってｎが増加することは明らかであり、各ＣＳ上の負荷は一定を維持できる。ここで、ネットワークのＣＳ部分はスケーラブルである。
【０１６７】
ほとんどのコンタクト共有は各ＣＳ上で発生するので、その負荷は軽減する。しかしながら、コンタクト共有はｎが増えるにつれて減ってくる。これは、接続ユーザがユーザ空間Ａのどの場所でもコンタクトを持つことができ、かつＡが増えるにつれて減少するｆコンタクトを任意の２つのユーザが共有する機会があることから明らかである。本発明のようなシステムでは、ユーザは小集団のグループになることが理解される。小集団では、各ユーザは、それぞれの他のユーザのコンタクトリストで他のユーザのほとんどを有することになる。（小集団の数学的定義はより強固になることに注意する。数学的集団では、各ユーザは、自身のコンタクトリストのすべての他のユーザを有することになる。）コンタクト共有の機会は、ユーザがＣＳ上の他の接続ユーザで小集団内に存在することを想定しているようなユーザがＣＳと接続している場合に増える可能性がある。この可能性は、例えば、ユーザの地理的位置でユーザとＣＳとを接続することによっておそらく増加することになる。
【０１６８】
接続サーバ上の上述の説明と同様に、各ＵＳ１９上のコンタクトリストサービスによって誘引される負荷についてＮ及びｎに影響を与えるものが何であるかを考える。ここでは、以下の簡略化を仮定する。
【０１６９】
・オンラインユーザのコンタクトリスト上のオンラインユーザ及びユーザは、等価的にすべてのＵＳへ分散される。各ＵＳ上のユーザ数は、ｎ／Ｎusである。
【０１７０】
・すべてのコンタクトリストのサイズは、ｆである。
【０１７１】
・タイムユニット単位でユーザ毎のＣＳからのイベント数は、一定である。その結果、タイムユニット単位でユーザ毎にＣＳへ送信することが必要な加入に対する更新数も一定である。
【０１７２】
・単一のオンラインクライアントからのイベントによって生じるＵＳ上の負荷は、θで示される定数である。単一のＣＳへ送信することが必要な単一のユーザ上の加入更新によって生じる負荷は、ωで示される定数である。
【０１７３】
・ネットワークは、Ｎus＞＝ｆとなるように十分に大きい。コンタクト共有は、ＣＳ内では発生しない。つまり、単一のユーザに対する加入更新は、ｆＵＳへ送信されなければならない。これは、最悪の場合である。
【０１７４】
これらの仮定が与えられることによって、サービスが任意のＵＳ上に与える負荷は、以下のような関係となる。
【０１７５】
【数３】
0004444518.tif 000008
【０１７６】
接続サーバに関し、より多くのＵＳをネットワークへ追加することによってｎが増加すると、各ＵＳ上の負荷は一定を維持できる。ここで、ネットワークのＵＳ部分はスケーラブルである。
【０１７７】
信頼性を出すために、クラスタ１は、以下の離散構成要素を含む非同期分散システムとなる、１）接続サーバ、２）ユーザサーバ、３）ユーザマッピング機能、４）データベース、５）内部ネットワーク、６）外部ネットワーク、７）クライアント、８）クラスタ内サーバである。内部ネットワークとデータベースは、自身の冗長性を実現し、１００％以上に近いものを達成するものとする。その信頼性の条件に合わせるために、コミュニティサーバネットワークは、以下のタイプのエラーを処理できるべきである、１）クライアント故障、これはＣＳによって検出され、故障したクライアントのみに影響を与える、２）１つ以上のクライアントとの接続性を切断する外部ネットワーク故障、これは、接続サーバ２１及びクライアントによって検出され、サーバ上のセッションステータスを見放し、かつクライアントから新規接続を確立することによって復旧される、３）接続サーバ故障、ＣＳの損失を招くハードウエアあるいはソフトウェア故障、これらは接続クライアントによって検出され、クライアントによる再接続によって復旧される、４）ユーザサーバ故障、ユーザサーバの損失を招くハードウエアあるいはソフトウェア故障、これらは接続ＣＳかつ／あるいはＵＭＦによって検出され、ＵＭＦから影響を受けるＵＳへのマッピングのすべてを削除し、かつ選択的にＵＭＦキャッシュを消去するリクエストをすべてのＣＳへブロードキャストすることによって復旧される（影響を受けるＣＳは、損失したＵＳ１９に関係するセッション状態を見放し、他の新規に割り当てられたＵＳと再接続する）、５）ＵＳ故障と同様な、クラスタ内サーバ故障、６）ユーザマッピング機能故障、これは、ＵＳ１９によって検出され、ＵＭＦ２５をリスタートするＵＳによって復旧される。
【０１７８】
ログ処理、審査処理かつ／あるいは追跡性に関しては、システム内のすべての関連イベントをデータベース１３にログとしてとることができる。これは、２つの主要カテゴリに分類され、１つは管理者の処理対象となるイベント、もう１つは構築用に使用できるイベントである。各イベントに対し、イベントの日時が記憶され、またどのユーザがイベントに対して応答可能であったかが記憶される。各イベントは１つのタイプを有し、これは、いくつかの付加データを持つことが可能である。ＣＳに対するユーザによるクライアントサーバプロトコルを介して行われるリクエストのログ処理の場合、ユーザのＩＰアドレスも記憶される。管理者は、管理タスクを実行するために、特定管理ツールあるいは単純なＳＱＬ質問を使用することができ、この管理タスクは、例えば、２回以上連続して認証（ハッキングの試行を検出するために）の試行が失敗しているユーザアカウントを監視し、ある時間あるいは一日全体を通してログインしたユーザ数をカウントするあるいはシステムがクラッシュした直前にどんなイベントが発生していたかを監視する（クラッシュの理由を理解するための試行を行う）。コミュニティオペレータは、どのような場合でも、構築用にサーバからデータを収集する手段を使用することができる。
【０１７９】
セキュリティ及びユーザ認証に関して、各登録ユーザ７は、本発明の実施形態では、ローカルクラスタ１の割当ユーザＩＤを有している。登録処理の一部として、ユーザは、自身のアカウントにアクセスするためのパスワードを選択する。ユーザは、自身が接続する毎に、自身のユーザＩＤ及びパスワードをクラスタ１に提示する。サーバ認証に対しては、各ＣＳ２１にはパブリック／プライベートキーペアが提供される。このペアの内のパブリックキーは、いくつかの認証局（ＣＡ）によって認証されている。クライアントがＣＳへ接続する毎に、サーバのパブリックキーのコピーとそれに関係する認証を取得する。クライアントは、認証をチェックし、認証が無効になっていることをＣＡを用いて検証することによって、パブリックキーの信頼性を検証することができる。サーバのパブリックキーの受信及びその信頼性を検証した後、クライアントは、ユーザ認証と同様の形態で、暗号化要求応答によってサーバと認証する。
【０１８０】
通信セキュリティ及びクライアント−サーバ通信に関しては、本発明の実施形態では、クライアントとＣＳ間の通信はすべて安全が確保されている。すべてのクライアント−サーバ通信では、ＳＳＨ２．０プロトコルが使用される。ＳＳＨ２．０は、サーバ認証、クライアント認証、データ完全性有効化及びデータ暗号化を行う。クライアントは、複数のＳＳＨチャネルを開放することによって、サーバクラスタ上の様々なサービスと通信し、このＳＳＨチャネルはそれぞれ別の仮想ストリームである。サーバ間通信に対しては、ユーザサーバ１９、ＵＭＦ２５及び接続サーバ２１間の通信を行うネットワークは、安全が確保されていると仮定され、かつ未認証アクセスから保護されていると仮定されている。認証あるいは暗号化のいずれも、本発明の実施形態では、ＵＳ間及びＵＭＦ及びＣＳ間の通信では実行されない。ＣＳ２１及びＵＳ１９間の通信は、ＳＳＨ２．０プロトコルを使用することができる。サーバ認証、ユーザ認証、データ完全性有効化及びデータ暗号化は、このような通信に対しては使用できず、そのため、ＳＳＨのストリーム多重だけは使用することが必要とされる。コミュニティオペレータ間の通信は暗号化されるのが好ましく、かつ両方の終端で認証するためにパブリックキー暗号技術が使用されることが好ましい。ＳＳＨプロトコル２．０は、このような通信、パブリック／プライベート暗号技術及びキー認証によって実行されるサーバ相互認証に対して使用されても良い。物理的なセキュリティに関しては、データベース１３、ＣＳ２１、ＵＳ１９、ＵＭＦ２５、ネットワークルータ、ブリッジ、ネットワーク線及びクラスタの任意の部分を実行するホストを含むハードウエアは、未認証アクセス及びコミュニティオペレータによる干渉から物理的に安全が確保されることが必要である。クラスタが物理的に壊されると、システム全体のセキュリティは破壊され、これは、クラスタの任意の部分が、ＣＳのプライベートキー、ユーザのプライベート情報及び通信等の影響のある情報を含むあるいは搬送している可能性があるからである。
【０１８１】
また、接続サーバは、安全が確保されていないインターネットとクラスタ１のホストである安全が確保されているインターネット間の境界に位置していることに注意する。接続サーバは、クリアテキストで接続クライアントすべてのトラフィックを確認することができ、また、クリアテキストにクライアント自身のプライベートキーを含ませることができる。接続サーバは、安全が確保されていないインターネットからの接続に開放され、かつすべてのクライアント通信を処理するので、ある種のファイヤウォールとして機能する。各ＣＳ２１は２つのネットワークインタフェースを有し、１つは安全が確保されていないインターネットとのインタフェースであり、もう１つは安全が確保されているインターネットとのインタフェースである。２つのネットワーク間で実行される転送は存在しない。一実施形態では、接続サーバは、接続及び接続試行毎にログをとることができる。ログエントリは、接続試行日の日時、ソースＩＰ番号、任意の認証試行及び認証失敗理由に対して使用されるユーザＩＤのような情報を含んでいる。接続が成功すると、接続サーバは、切断時間と各指示で転送されるデータ量のログを追加する。一実施形態では、コミュニティオペレータは、ハッキングを防止し、かつハッキング試行の追跡を維持するために、インターネットから接続サーバへのトラフィックをフィルタにかけ、検査することが好ましい。
【０１８２】
バックエンドの各構成要素の設定は、構成要素がスタートアップ時に読み出すＤＢに記憶されるのが好ましい。これらの設定は、管理ツールで構成可能であることが好ましく、この管理ツールは、各バックエンド構成要素との接続を有し、かつ必要に応じて設定時の構成要素の変更を通知する。図２６は、クラスタ１での管理ツールの位置を示している。アプリケーションへのユーザの追加かつアプリケーションからのユーザの削除は、基本的には新規ＵＩＤを発行し、データベースにユーザ情報を書き込む別々の管理ツールによって処理される。ＣＧＩプログラム等で使用するために、コマンドラインでこの管理ツールを実行することができるべきである。
【０１８３】
上述の説明から理解できるように、ユーザ７は新規プロファイルの生成、プロファイルの削除、プロファイルの編集等を実行することができ、また、現在どのプロファイルがアクティブであるかの設定を実行することもできる。コンピュータ制御の転送は、現在アクティブなユーザのプロファイルに基づいており、また、これは、特定通信モードを使用して特定ユーザが別のユーザとのコンタクトをするかしないかに関わらず、ユーザはその通信モードを処理できる会話エンドポイントあるいはメッセージリポジトリへ転送されることを基本的には意味する。プロファイルの設定に基づいて、他のユーザは、あるユーザが彼を嫌いで彼の発呼にでたくないこと、あるいはユーザのＧＳＭ等で呼び出すことを応答する自動リプライヤへ転送することができる。
【０１８４】
これらの通信／会話方法のタイプは、テキスト、音声及び画像を利用することが可能である。これらのメッセージのタイプは、音声（ＶＭ）、ショートテキストメッセージ（ＳＴＭ）、電子メール（ＥＭ）、（ＳＴＭ以外のメッセージの搬送を通知するために送信される）通知（ＮＭ）が利用可能である。以下のデバイスでサポートすることができる。ここで、どのタイプのメッセージがリポジトリ対象であり、どの会話のタイプが参加することができ、どのタイプのメッセージが送信できるかをリストに示す。
【０１８５】
【表５】
0004444518.tif 000009
【０１８６】
必要に応じて追加デバイスを生成することができる（例えば、会話エージェント）。上述のデバイスに対し、自動リプライヤデバイスは基本的なデバイスであり、これは、ユーザ７が、音声及び／あるいはテキストを使用して、様々なユーザと別々にリプライすることを設定できる。このデバイスは、現在のシステム／ネットワークの必須部分である。音声会話の場合、クライアント１１だけが、２つ以上のユーザ間の音声会議を初期化することが可能である。受信ボックスは、ユーザへ送信されるすべてのＳＴＭを受信し、また、メッセージの搬送の通知を受信する（例えば、システムが電子メールをユーザのファックスへ転送する場合）。ユーザは、どのタイプのメッセージの通知をユーザが望んでいるかを特定することができる。クライアントは、受信ボックスへのアクセスを与えることができ、受信ボックスに到来する新規メッセージをユーザに通知する。この場合、ユーザＡは、通信モードあるいはメッセージタイプを使用してユーザＢへのコンタクトを試行し、この通信モードあるいはメッセージタイプはユーザＢがこの旨をユーザＡへ通知するシステムをサポートしない（即ち、ユーザＢは、通信モードへの関与あるいはメッセージタイプの受信をできるデバイスは持たない）。
【０１８７】
テキスト会議に対しては、このような会議は、会議単位では１０人のユーザを処理することができる。会議を初期化するユーザは、その会議の主催権を有することが好ましく、これは、会議へユーザを招待するための機能をそのユーザへ与え、ユーザの会議への参加を断ったり、ユーザを無音にする。音声会議に関しては、このような会議は、アプリケーションが依存するＭＣＵあるいはその等価構成が処理できるユーザ数より少ないユーザ数を処理できることが好ましい。会議を初期化するユーザ７は会議の所有権を有することが好ましく、これは、会議へユーザを招待するための機能をユーザへ与え、ユーザの会議への参加を断ったり、ユーザを無音にする。Ｗｅｂ会議に対しては、これは、同一Ｗｅｂページを閲覧するすべてのユーザとでテキスト会議あるいは音声会議へユーザ７が参加することができる機能に与えられる名称である。Ｗｅｂ会議では、ユーザは所有権を有していない。Ｗｅｂ会議グループは、最大サイズがＸユーザである（これは、アプリケーションの管理者によって設定できる）。同一Ｗｅｂページを閲覧するより多くの複数のユーザが存在する場合、そのユーザは、Ｘユーザより少ないグループに分割される。Ｗｅｂ会議用のユーザインタフェースは、自身のテキスト、音声あるいはビデオ会議を生成し、かつこの会議へユーザを招待することをユーザに容易にさせることができる。また、音声会議あるいはビデオ会議へ参加する機能をその会議でどのユーザに持たせるかをユーザに確認することを容易にする。
【０１８８】
音声メール統合に関しては、ユーザ７は、アプリケーションを介してユーザの音声メールボックスの内容を列挙することができ（即ち、メッセージを受信した等の場合に、どれくらいの数のメッセージがあるかを見る）、そのユーザの音声メールボックスを管理することができる（即ち、メッセージの削除等）。また、ユーザ７は、アプリケーションを使用して、自身のメールボックスの任意のメッセージを受信することができる。また、ユーザ７は、（例えば、コンタクトの電子メールアドレス上でクリックすることによって）アプリケーションから自身の標準電子メールプログラムを使用してメッセージを送信することができる。（Ｘ分毎に）ユーザが新規の電子メールを受信している場合の通知をユーザに取得させることが可能である。新規の電子メールが存在する場合、ユーザは、そのメッセージを読むためにシステム／ネットワークに自身の電子メールプログラムを起動させることを容易に実行することができる。この機能とは別に、アプリケーションは、別のタイプのメッセージをユーザの電子メールボックスへ送信することができる。ユーザは、本発明のシステム／ネットワークを特定する電子メールアドレスを持つことができ、こうすることで、システム／ネットワークは電子メールを転送でき、かつ匿名性がある。
【０１８９】
本発明のシステム／ネットワークは、複数種類のクライアント／ユーザを介してアクセス可能になるように設計されていることが好ましい。アプリケーションバックエンドの機能は、任意のクライアントからアクセス可能にすることができる（但し、ブリッジ動作が必要とされる可能性がある）。いくつかのクライアントは、アプリケーションの範疇にある。「フルクライアント（full client）」は、テキスト及び音声機能の役目を果たし、かつサーバとの永続的な接続を有する標準ＧＵＩプログラムである。このタイプのクライアントは、「ユーザがＸを実行することを可能である」ことを説明する場合を通常示すクライアントであり、即ち、このタイプのクライアントは、ユーザにＸを実行させることを可能にするクライアントである。別のクライアントは、このクライアントのバージョンをおとしたクライアント、あるいはかなりの制限があるクライアントである。「シンクライアント（thin client）」は、フルクライアントの１つ以上の機能（例えば、音声チャット）を外したフルクライアントのバージョンをおとしたクライアントである。「ウェブクライアント」は、有効なフォームのブラウザへアクセスすること以外は禁止した状態で、ユーザにコミュニティ内のだれかにページを送信することを可能にするアプリケーションに対するかなり基本的なクライアントである。Ｗｅｂ等を介してページを受信することを可能にするための条件は何もない。ウェブクライアントは、選択的に、現在使用されているプロファイルを切り換えることをユーザに可能にすることができる。選択的には、ウェブクライアントは、ユーザの受信ボックスを閲覧したり、受信メッセージを読むことをユーザに可能にすることができる。「電話クライアント」は、（音声メールから）与えられる番号に電話をかけたり、現在使用されているプロファイルを切り換えることをユーザに可能にするクライアントである。
【０１９０】
アプリケーションをアクセスするユーザのカテゴリは、例えば、２つ存在し得る。支払カスタマ（即ち、電話会社のエンドユーザ）に対しては、彼らがどこでアプリケーションにログオンしたかについては問題にならないことが条件とされ、ユーザが行うことは全く同じである（即ち、クライアント側にデータは記憶されない）。これは、インターネットエンドユーザに対しては条件とされない。
【０１９１】
バックエンド管理は、コマンドラインツールあるいはそれと同等なものを少なくとも介して、また、選択的には、ユーザインタフェースツールを介して管理可能にすることができる。ユーザ登録がどのようにして処理されるかは、電話会社単位で決定され、ある場合では、電話会社の従業員による明快なデータ入力及び管理ツールの実行を通して実現され、別の場合では、ユーザから直接収集したデータでＣＧＩスクリプトあるいは管理ツールを実行する同等のものを介して実現される。
【０１９２】
管理に係るバックエンド上の構成は、情報のログをとることである。これは、オペレータに関係のあるシステムの動作に関する詳細毎にログをとることを可能にする。どの詳細のログがとられるかは、管理ツールを介して構成可能である。解析及びアーカイブに対する他のソフトウェアパッケージへ、システムからのログデータを容易にインポートすることが可能である。
【０１９３】
本発明の実施形態では、システムの多くの部分は、できる限り、そのシステムの残りの部分とのインターフェスを好適に定義することができ、かつ自身に内包することができる、つまり、システムの実現におけるプラグイン方法を容易にする。これは、例えば、電話統合部分の様々な部分の実現であり、これは、いくつかの別々のグループに分けることができる。また、現在のシステムに関係のない例えば、従来のエージェント技術との互換性を将来実現する。
【０１９４】
アプリケーションは、単一の集中化アドレスブックをユーザに提供でき、この集中化アドレスブックは、コミュニティ内の各ユーザ上でユーザ情報を記憶する。このアドレスブックは、例えば、各ユーザのフルネーム及び電子メール、コミュニティ名、ユーザＩＤを記憶しても良い。選択的には、お気に入り、ホームページのＵＲＬ、電話番号のような他のものを記憶することができる。コミュニティ名及び電子メールは、パブリック情報とすることができる。情報の停止に対しては、ユーザは、グループあるいはそれ以外のグループを特定し、かつこれらのグループとブール演算子とを掛け合わせることによって、ユーザがどの情報を見ることができ、どの情報を見ることができないということを定義することができる。一実施形態では、ユーザは、アドレスブック（即ち、アドレスブックに通じるページ）を閲覧することをできないようにしなければならない。しかしながら、ユーザは、ネーム、電子メール及びコミュニティ名フィールド中の全ストリングあるいはそのストリングの一部に対するサーチに基づいてアドレスブック中のユーザを検索することができる。また、自身のユーザＩＤに基づいてユーザを検索することも可能である。アドレスブック中の多くのユーザがサーチ条件に合致すると、そのサーチを開始したユーザには、その合致したユーザのすべてが提示され、与えられる各ユーザ上の多くの付加情報に基づいて、合致したユーザを選択することが要求される。例えば、ユーザであるスヌーグルポップス（Snooglepops）がアドレスブック中のユーザであるマフィン（Muffin）を一旦検出すると、スヌーグルポップスは、マフィンを自身の個人バディリスト（即ち、コンタクトリスト）に追加でき、かつマフィンをバディリストに追加することなくマフィンにページを送信することができ、更に、マフィンが会議に参加することを要求することができる。
【０１９５】
バディリスト（別名、コンタクトリスト）は、ユーザ群である。これらのユーザは、ユーザによる階層グループを構成することができる。ユーザは、１つ以上のグループに存在しても良い。ユーザは、グループを生成したり削除することができ、かつグループへユーザを追加したりあるいはグループからユーザを削除することができ、更に、グループ間でユーザを移動するあるいはコピーする、かつある位置のグループを別の階層へ移動することができる。グループは、ユーザ及びグループに対するコンテナである。以下のグループがデフォルトとして存在する。
【０１９６】
【表６】
0004444518.tif 000010
【０１９７】
ユーザは、別のユーザが自身を他のユーザのバディ／コンタクトリストへ追加しようとなかろうと、通知を取得するオプションを選択することができる。また、バディリストに目を通すことによって、ユーザは、自身のバディのオンラインステータスを見ることができる。バディリストは、バディのオンラインステータス内の変更の視覚的な通知を提供でき、また、ユーザが設定可能な音声通知のオプションを提供することができる。ユーザは、自身のバディリストの任意のユーザに対するグローバルアドレスブックに記憶される情報を見ることができる。
【０１９８】
ページングに対しては、ユーザは、ショートテキストメッセージ（ＳＴＭ）を、自身のバディリスト上の任意のユーザへ送信することができ、かつアドレスブックを使用して自身が検出する任意へのユーザへ送信することができる。これらのメッセージが受信ユーザによって見えるかどうかは、受信者のオンラインステータスに依存し、かつ送信ユーザに自身を不可視にしているかどうかに依存する。メッセージのデフォルトの受信方法は、クライアントを介する。これ以外に、ユーザは、以下の方法（ユーザ設定可能）のどちらかを使用することができるＳＭＳメッセージを受信することが可能なＧＳＭ電話番号を特定できる、１）ユーザは、ＧＳＭ番号に発信されるべきユーザのＲＳ３３によってクライアントを介することを行わせるメッセージのすべてを特定することができる。２）ユーザは、ユーザが常に自身の端末あるいはオフラインである間に到達するＧＳＭ番号に発信されるべきメッセージのすべてを特定することができる。
【０１９９】
ショートテキストメッセージには最大サイズが存在しても良く、あるいはＳＭＳを介してＧＳＭ番号へ送信される場合は、ショートテキストメッセージは切り捨てられても良い。どちらかを実行するかは、設計事項である。ショートテキストメッセージを送信する場合、別のユーザによって送信されるメッセージへのリプライを行うかどうかについては、ユーザは、メッセージの本文として使用するために事前に作成したストックメッセージの１つを選択することができる。ユーザが、自身のバディリストに存在しないユーザによってページが送信される場合、ページが送信されたユーザに対して、自身のバディリストへページを送信したユーザを追加させることができ、かつそのページを送信したユーザを自身のバディリストへ追加することなく容易にそのメッセージに対するリプライを行わせることができる。ユーザがページを送信する場合には、そのユーザに対してそのページの送信者をテキストあるいは音声会議へ容易に招待する手段を持つことができる。一実施形態では、メッセージは緊急として示されてもよい。一実施形態では、ユーザのグループ及び個々のユーザに基づいて、メッセージに対する複数の受信者を選択することをユーザに可能にすることができる。メッセージを送信することを可能にするユーザの総数は、スパミングとしてこの機能を使用することを防止するためにその機能を制限することができる。
【０２００】
会議への招待あるいはメッセージの別ユーザへの送信用のユーザインタフェースは２つ存在し得り、１つは未経験ユーザに対するものであり、もう１つは経験ユーザに対するものである。未経験ユーザに対するものは、操作時間をより多く要するが、ユーザに従って支援するために、動作のより親切な詳細及び図式等でより容易に使用することができるようにしてある。
【０２０１】
ユーザのクライアントは、どのような日時に、誰宛て／誰から、かつどのような内容であったかに従って、過去の発信及び受信メッセージのすべてのリストを表示できることが好ましい。ユーザは、記憶領域を節約するためにログからメッセージを削除することができる。ユーザは、２つの条件の１つあるいはそれらの組み合わせによって表示されるメッセージを制限することができ、この２つの条件とは、メッセージが発信あるいは受信であるか、メッセージが誰宛て／誰からのものであるかである。また、実際のメッセージ（通知なし）だけを表示することをできるようにしても良い。
【０２０２】
ユーザの受信ボックスへ送信されるショートテキストメッセージ（ＳＴＭ）は、受信ボックスから直接読み出すことができる。いくつかのメッセージリポジトリへのメッセージの搬送を通知する通知メッセージの場合、ユーザにそのメッセージを検索するためのアプリケーションを要求させることを可能にしても良い。次に、このアプリケーションは、メッセージがまだ存在するかについてメッセージリポジトリをチェックすることができ、可能であればメッセージを検索することができる。これは、音声メール及び電子メールのような場合に対して可能であるが、ファックメッセージに対しては可能ではない。
【０２０３】
ユーザは、ストックメッセージの分類を設定することができる（「不在」、「ビジー」等）。自動リプライは、これらのストックメッセージの１つがユーザに代わるアプリケーションによって自動的に使用される場合に行われる。各ユーザは、ユーザへ到達しているかどうか、かつ別のユーザが自身へページを送信する場合にどの自動リプライが使用されているか（自動リプライは使用されず、かつユーザは自身に対する返答から解放されている場合もある）を定義するオンラインステータスを持つことができる。このバージョンのアプリケーションに対しては、以下の表７に示される関係を選択するために、ユーザに対する固定オンラインステータス群を持たせることができる。
【０２０４】
【表７】
0004444518.tif 000011
【０２０５】
ユーザは、自身のオンラインステータスが遮断中でないとしても、自身へ送信できるユーザあるいはユーザグループを特定することができる。バディリストで定義される任意のグループは、それらのグループの反転（そのグループ以外のすべて）は、これを特定するために使用されても良い。利用可能な各オンラインステータスに対してある一般的な既成ストックリプライを持たせることができる。また、メッセージがＳＭＳを介するユーザのＧＳＭ番号へ送信されているあるいは複製されていることを示す各オンラインステータスに対してある既成ストックリプライを持たせることができる。ユーザは、メッセージが自身のＧＳＭ電話へ転送されたことをそのメッセージの送信者へ知らせるかどうかを選択することができる。ＳＭＳを使用してメッセージに応答することを可能にすること、あるいはＳＭＳシステムからユーザへメッセージを送信することを可能にすることに条件はない。
【０２０６】
テキスト会議に関しては、ユーザ７は、主催者ユーザによって制御されるテキストチャット会議へ参加するためのリクエストを、バディリスト上の任意のユーザへ送信できる、あるいはアドレスブックを使用してユーザが見つける任意のユーザへ送信できる。このリクエストは、この会議を行う理由のユーザの説明に伴って発生しても良い。チャット会議へ参加するためのリクエストを受信すると、受信ユーザはその会議へ参加するかあるいはその会議へ参加しないかを選択することができ、あるいはそのリクエストを無視することができる（つまり、自身がユーザに対して不可視としている場合に生じていて、かつユーザが自身を会議へ招待している）。ユーザの応答は、自身が実行するものとする応答の理由に伴って発生しても良い。会議が一旦開始すると、主催者ユーザは会議内で特権を有しており、かつ会議へ追加ユーザを招待することができ（説明に伴って発生しても良い）、かつ会議からユーザを辞退させることができ（説明に伴って発生しても良い）、かつ／あるいは会議への発言権を与えるあるいは拒否することができる。会議中のすべてのユーザはチャットのためにテキストを使用することができ、かつ会議は様々なユーザによって送信されるメッセージの履歴を表示する（例えば、ＩＲＣ等）。すべてのユーザは、自身の感情を簡単な方法で（ＩＲＣ内で）表現することがでる、即ち、ユーザが晴れやかであることを他のユーザへ知らせることができる。テキスト会議は、少なくとも２０〜３０ユーザを扱うことができる。特権ユーザが会議を終了する場合、一実施形態では、会議は解散されることが好ましい。
【０２０７】
音声会議の実施形態において、音声会議は、音声を使用するチャット機能を追加したテキスト会議である。複数のユーザが同時に発言する場合、これらの別々の入力は統合されて出力が得られる。音声品質は、使用する符号化に依存し、かつ利用可能な帯域幅に依存する可能性がある。ＧＳＭ符号化が使用される条件はないと推定される。音声信号を受信しかつ送信する機能を有するユーザだけが、音声会議へ参加することができる。
【０２０８】
ユーザ７間のビデオ会議に対して、ビデオ会議は現在発言しているユーザを見る機能を追加した音声会議である。音声及びビデオ信号を受信しかつ送信する機能を有するユーザだけがビデオ会議に参加することができる。別のオプションでは、ユーザ７間でＷｅｂ会議を実現することができる。
【０２０９】
本願は、インターネット及び電話会社のアカウントへのアクセスを有するユーザ、かつ電話会社からの自身のアプリケーションを受信するユーザを対象とするものである。これらのユーザは、初心者からインターネット通信を使用することを要求する熟練者までのどのようなユーザでも良い。また、本願は、インターネットへのアクセスを有し、かつ（電話会社を介さずに）インターネットを介して自身のアプリケーションを受信するユーザを対象とするものである。これらユーザは、初心者からインターネット通信を使用することを要求する熟練者までのどのようなユーザでも良い。
【０２１０】
実際には、コミュニティオペレータは、電話会社の技術者である。これらは、システムを管理するためにコマンドラインツールを使用し、かつサポートするゲートウェイやサーバ等を設定することが予想され、かつこの種の業務を行うことを訓練される。
【０２１１】
一実施形態では、ユーザ７のクライアントに対するエンドユーザの条件は、以下のようになる。
【０２１２】
・２８．８モデム接続、符号化音声用帯域幅以上
・Ｗｉｎｄｏｗｓ９５以上、ＷｉｎｄｏｗｓＮＴ以上、ＷｉｎｄｏｗｓＣＥ以上あるいはＭａｃＯＳオペレーティングシステム
・１６Ｍバイトのメモリ（ＷｉｎｄｏｗｓＣＥの場合は４Ｍｂ）
バックエンドソフトウェアは、ＷｉｎｄｏｗｓＮＴかついくつかのメインストリームＵｎｉｘオペレーティングシステム（少なくＳｏｌａｒｉｓ）上で動作することができる。サーバ装置（プロセッサ数／速度、メモリ量、帯域幅量、Ｉ／Ｏの速度）により多くお金を投資することで、動作をより良く変更することができる。
【０２１３】
一実施形態では、クライアント側アプリケーションは、特別な設定を行うことを必要とするシステム管理者を必要としないでＳＯＣＫＳファイヤウォールを介して動作でき、かつかなり制限されたポート数を開放するシステム管理者を持つことによって他のファイヤウォールを介して動作できる。クライアント側アプリケーションは、小アプリケーションであっても良い。ここで、機能が豊富な（全機能である必要はない）のバージョンのプログラムのインストールは、標準フロッピーディスク（１．４４Ｍｂ）に適合しているものと仮定する。このアプリケーションは著しく高速な起動時間を持つことができ、そのＵＩはあらゆる環境下で使用可能である。
【０２１４】
クライアント側アプリケーションの全体の耐性は、他のエンドユーザソフトウェアに匹敵するものである。具体的には、この耐性は次のようになる、１）ユーザへ、ユーザに関連する任意のエラーメッセージを自然言語で通知する。接続が切断した場合に自動的に再接続の試行をユーザへ促す。２）アプリケーションのバックエンドソフトウェアが更新される場合にユーザに通知し、新バージョンのクライアントソフトウェアをダウンロードする場所をユーザに示す。かつ／あるいは、３）接続中で、かつアプリケーションのバックエンドが更新されたことを検出した場合に、クライアントソフトウェアは、新バージョンのクライアントソフトウェアを自動的にダウンロードしかつインストールすることができる。
【０２１５】
以上のように、本発明は実施形態で説明されているが、この開示は単なる本発明の例示及び説明であることが理解されるべきである。従って、本発明が本明細書の請求項の範囲によってのみ制限されることが意図されるものである。
【図面の簡単な説明】
【図１】  本発明の実施形態に従う相互に接続された複数のサーバクラスタの概要図である。
【図２】  本発明の実施形態に従う図１のクラスタの１つの概要図である。
【図３】  本発明の実施形態に従って、（ＰＣのようなクライアントＡを有する）第１ユーザがどのようにしてインビテーションメッセージを（ＰＣのようなクライアントＢを有する）別のユーザへ送信するかを示し、ここで、クライアントＢの転送サービスはインビテーションメッセージをクライアントＢへ転送する場合の機能図である。
【図４】  本発明の実施形態に従って、第１ユーザ（クライアントＡ）がどのようにしてインビテーションメッセージを別のユーザ（クライアントＢ）へ送信するかを示し、ここで、クライアントＢのクライアントがオンラインでないので、クライアントＢの転送サービスがインビテーションメッセージをクライアントＢの移動電話へ送信する場合の機能図である。
【図５】  本発明の実施形態に従って、第１ユーザ（クライアントＡ）がどのようにしてインビテーションメッセージをソフトウェアエンティティのようなサービスである別のユーザへ送信するかを示し、ここで、ソフトウェアエンティティのエージェントあるいは転送サービスは、第１ユーザとソフトウェアエンティティ間で通信を設定可能にするために、メッセージをソフトウェアエンティティへ送信する場合の機能図である。
【図６】  本発明の実施形態に従って、ユーザ間の接続がクラスタ間を送信できることを示す機能図である。
【図７】  本発明の実施形態に従うユーザのディスプレイスクリーン（例えば、ＰＣのディスプレイ）上で表示するクライアントの構成例を示し、ここで、起動されると、クライアントアプリケーションは、ユーザ名、パスワードかつ／あるいはサーバアドレスをユーザに提示し、その後、クライアントは適切なユーザサーバと接続でき、かつそのユーザサーバとの安全が確保された通信が確立できる場合の図である。
【図８】  本発明の実施形態に従うユーザの端末／クライアントのディスプレイスクリーン上で表示するユーザのコンタクトリストの例を示す図である。
【図９】  ユーザが別のユーザへ送信することが可能な複数種類のタイプのインビテーションメッセージのメニューリストを示し、これは、本発明の実施形態に従うユーザの端末／クライアントのディスプレイ上でメニューリストをどのように表示するかを示す図である。
【図１０】  本発明の実施形態に従って、各オペレータが１つ以上のクラスタをどのようにして動作させるかを示し、ここで、インビテーション／メッセージ／データがあるクラスタ上のユーザから別のクラスタ上のユーザ（群）へ送信できるようにするために、各クラスタは、別の１つのクラスタと通信できる場合の機能図である。
【図１１】  サーバ構成（例えば、サーバ間、かつサーバとクライアントとデータベース（群）間の通信リンク）を示す機能図である。
【図１２（ａ）】  本発明の実施形態に従って、図１１のマッピング機能例がどのようにして動作するかを示す図である。
【図１２（ｂ）】  本発明の実施形態に従うアプリケーションあるいはシステム／ネットワーク全体を通して利用可能であり、かつユーザに与えられるユーザ識別（ＵＩＤ）を示す図である。
【図１３】  本発明の実施形態に従う図１１のクラスタの構成要素例を示し、かつクライアント、他のクラスタ（群）、かつ／あるいはインターネットのような他のエンティティとクラスタどのようにして通信できるかを示す機能図である。
【図１４】  本発明の実施形態に従ってユーザがインビテーションメッセージを他のユーザへ送信する場合に行われる工程を示すフローチャートである。
【図１５】  本発明の実施形態に従って、ユーザ（例えば、カール）が少なくとも１つの他のクライアント（例えば、アン）とのチャットセッションを設定する場合に行われる工程を示すフローチャートである。
【図１６】  本発明の実施形態に従うユーザサービスを介するユーザサーバ上のデータ構造（群）例を示す図である。
【図１７】  本発明の実施形態に従う接続サーバ例上のコンタクトステータスサービスに対するデータ構造（群）を示す図である。
【図１８（ａ）】  本発明の実施形態に従って、データベースに記憶され、かつ要求に応じて検索される、コンタクトリストサービスに対して記憶されるデータ構造（群）を示す図である。
【図１８（ｂ）】  本発明の実施形態に従うユーザプロファイルに対するデータ構造を示す図である。
【図１９】  本発明の実施形態に従うユーザ（あるいはユーザのクライアント）に対するログオン処理あるいはシーケンスを示す概要図である。
【図２０】  本発明の実施形態に従うユーザ（あるいはユーザのクライアント）に対するログオフ処理あるいはシーケンスを示す概要図である。
【図２１】  本発明の実施形態に従うコンタクトＢ１のログオン／ログオフ処理、あるいはシーケンスを示し、ここで、ユーザあるいはユーザのクライアントはコンタクトＢ１を監視でき、かつコンタクトがいつオンラインになり、コンタクトがいつログオフになるかを知っている場合を示す機能図である。
【図２２】  コンタクトをユーザのコンタクトリストへ追加する／から削除する、ユーザのあるいはクライアントの処理中に行われる工程を示す概要図である。
【図２３】  別のユーザをユーザの遮蔽リストへ追加する／から削除する、ユーザのあるいはクライアントの処理中に行われる工程を示す概要図である。
【図２４】  本発明の実施形態に従ってユーザが自身の遮蔽リストを判定する場合に行われる工程（即ち、メッセージシーケンス）を示す（このシーケンスは、ユーザ遮蔽リストへ追加される場合のシーケンスと類似している）概要図である。
【図２５】  本発明の実施形態に従うコンタクトリスト機能に対するデータベース操作、（例えば、データベースへの質問）のすべてを示すチャートである。
【図２６】  本発明の実施形態に従う管理ツール／サービスの位置かつ／あるいは機能を示す図である。
【図１】
0004444518.tif 000012
【図２】
0004444518.tif 000013
【図３】
0004444518.tif 000014
【図４】
0004444518.tif 000015
【図５】
0004444518.tif 000016
【図６】
0004444518.tif 000017
【図７】
0004444518.tif 000018
【図８】
0004444518.tif 000019
【図９】
0004444518.tif 000020
【図１０】
0004444518.tif 000021
【図１１】
0004444518.tif 000022
【図１２（ａ）】
0004444518.tif 000023
【図１２（ｂ）】
0004444518.tif 000024
【図１３】
0004444518.tif 000025
【図１４】
0004444518.tif 000026
【図１５】
0004444518.tif 000027
【図１６】
0004444518.tif 000028
【図１７】
0004444518.tif 000029
【図１８（ａ）】
0004444518.tif 000030
【図１８（ｂ）】
0004444518.tif 000031
【図１９】
0004444518.tif 000032
【図２０】
0004444518.tif 000033
【図２１】
0004444518.tif 000034
【図２２】
0004444518.tif 000035
【図２３】
0004444518.tif 000036
【図２４】
0004444518.tif 000037
【図２５】
0004444518.tif 000038
【図２６】
0004444518.tif 000039