(57)【要約】ユーザが複数のデバイスを用いて接続している通信システムにおける当該ユーザの総合的プレゼンス状態を求める方法。本方法は、上記複数のデバイスがそのデバイスメモリに該デバイスについてのプレゼンス状態を格納するステップと、上記複数のデバイスの少なくとも１つにおけるプレゼンス状態の変化を検出するステップと、上記複数のデバイスの各デバイスが、プレゼンス状態が含まれたメッセージを、上記通信システムを介して上記複数のデバイスの残りのデバイスに対して送信するステップと、上記複数のデバイスの上記残りのデバイスにおいて当該メッセージを受信するステップと、上記複数のデバイスの上記残りのデバイスのそれぞれのプロセッサにおいて決定用コード・シークエンス（デシジョン−メーキング・コード・シークエンス）を実行することにより、上記複数のデバイスの少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因（オリジン（origin））に基づいて、該デバイスのプレゼンス状態を、上記メッセージの１つが示すプレゼンス状態と同期させるかを決定するステップと、を有する。
2010523035.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが複数のデバイスを用いて接続する通信システムにおける当該ユーザの総合的プレゼンス状態を求める方法であって、
前記複数のデバイスがそれぞれ、デバイスメモリに該デバイスについてのプレゼンス状態を格納するステップと、
前記複数のデバイスの少なくとも１つにおけるプレゼンス状態の変化を検出するステップと、
前記複数のデバイスの各デバイスが、前記プレゼンス状態が含まれたメッセージを、前記通信システムを介して前記複数のデバイスの残りのデバイスに対して送信するステップと、
前記複数のデバイスの前記残りのデバイスにおいて前記メッセージを受信するステップと、
前記複数のデバイスの前記残りのデバイスのそれぞれのプロセッサにおいて決定用コード・シークエンスを実行することにより、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因に基づいて、該デバイスの前記プレゼンス状態を、前記メッセージの１つが示すプレゼンス状態と同期させるかを決定するステップと、を有する方法。
【請求項２】
前記メッセージは、さらに、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させる前記イベントの前記原因を含む、請求項１に記載の方法。
【請求項３】
さらに、前記通信システムの少なくとも一人の他ユーザの端末が、前記複数のデバイスが示すプレゼンス状態のリストを照合し、前記リストの前記プレゼンス状態を所定の序列と比較し、最高位に格付けされたプレゼンス状態を前記ユーザが示す総合的プレゼンス状態として選択するステップを有する、請求項１または２に記載の方法。
【請求項４】
さらに、前記少なくとも一人の他ユーザの前記端末のメモリに、前記総合的プレゼンス状態を格納するステップを有する、請求項３に記載の方法。
【請求項５】
さらに、前記ユーザの前記総合的プレゼンス状態を、前記通信システムの少なくとも一人の他ユーザの前記端末において実行されるクライアント・プログラムのユーザ・インタフェースに示されるコンタクト・リストに表示するステップを有する、請求項３または４に記載の方法。
【請求項６】
前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させる前記イベントの前記原因は、
プレゼンス状態の自動変更、
プレゼンス状態の手動変更、
前記通信システムからの手動によるログオフ、
前記通信システムへの新たなログイン、および、
保存されたプレゼンス状態の取得、
のいずれか１つである、請求項１ないし５のいずれかに記載の方法。
【請求項７】
前記決定用コード・シークエンスは、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更であり当該手動変更が該デバイスにおける手動変更よりも最近である場合に、該デバイスの前記プレゼンス状態を前記メッセージが示す前記プレゼンス状態と同期させる、請求項６に記載の方法。
【請求項８】
さらに、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更である場合、プレゼンス状態の前記手動変更を示すビットを前記デバイスメモリに格納するステップを有する、請求項７に記載の方法。
【請求項９】
前記メッセージは、前記ビットを含む、請求項８に記載の方法。
【請求項１０】
前記決定用コード・シークエンスは、前記ビットを読み取って、前記メッセージが示す前記プレゼンスがプレゼンス状態の手動変更であるかを判断する、請求項９に記載の方法。
【請求項１１】
さらに、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更である場合、プレゼンス状態の前記手動変更の時刻を記録するタイムスタンプを前記デバイスメモリに格納するステップを有する、請求項７ないし１０のいずれかに記載の方法。
【請求項１２】
さらに、前記メッセージは、前記タイムスタンプを含む、請求項１１に記載の方法。
【請求項１３】
前記決定用コード・シークエンスは、前記タイムスタンプを読み取って、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更であり当該手動変更が該デバイスにおける手動変更よりも最近であるかを判断する、請求項１２に記載の方法。
【請求項１４】
前記決定用コード・シークエンスは、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因が、
プレゼンス状態の自動変更、
前記通信システムからの手動ログオフ、
前記通信システムへの新たなログイン、または、
保存されたプレゼンス状態の取得、
である場合に、該デバイスの前記プレゼンス状態を前記メッセージが示す前記プレゼンス状態と同期させない、請求項６ないし１３のいずれかに記載の方法。
【請求項１５】
前記プレゼンス状態の自動変更は、前記複数のデバイスの前記少なくとも１つのデバイスがアイドル状態に移行することで実行された変更である、請求項６ないし１４のいずれかに記載の方法。
【請求項１６】
前記プレゼンス状態の手動変更は、前記複数のデバイスの前記少なくとも１つのデバイスにて実行されるクライアント・プログラムのユーザ・インタフェースにおいて前記ユーザが特定のプレゼンス状態を選択することで実行された変更である、請求項６ないし１５のいずれかに記載の方法。
【請求項１７】
前記保存されたプレゼンス状態の取得は、前記ユーザが前記複数のデバイスの前記少なくとも１つのデバイスを用いて前記通信システムへログインすることで実行され、
前記複数のデバイスの前記少なくとも１つのデバイスは、以前に前記ユーザが選択した手動プレゼンス設定に対応し、前記デバイスメモリに格納されている、保存されたプレゼンスを備える、請求項６ないし１６のいずれかに記載の方法。
【請求項１８】
前記表示するステップは、さらに、
前記最高位に格付けされたプレゼンス状態と関係するデバイスから、前記最高位に格付けされたプレゼンス状態と関係するデバイスの有する特性の少なくとも１つに関する情報を受信するステップと、
前記少なくとも１つの特性に関する情報を示すプレゼンス標識を表示するステップと、を含む、請求項５に記載の方法。
【請求項１９】
前記通信システムは、ボイス・オーバー・インターネット・プロトコル通信システムである、請求項１ないし１８のいずれかに記載の方法。
【請求項２０】
前記ボイス・オーバー・インターネット・プロトコル通信システムは、ピア・ツー・ピア通信システムである、請求項１４に記載の方法。
【請求項２１】
ユーザが複数のデバイスを用いて接続する通信システムにおける当該ユーザの総合的プレゼンス状態を求めるシステムであって、
前記複数のデバイスそれぞれのデバイスメモリに該デバイスについてのプレゼンス状態を格納する手段と、
前記複数のデバイスの少なくとも１つにおけるプレゼンス状態の変化を検出する手段と、
前記複数のデバイスの各デバイスから、前記プレゼンス状態が含まれたメッセージを、前記通信システムを介して前記複数のデバイスの残りのデバイスに対して送信する手段と、
前記複数のデバイスの前記残りのデバイスにおいて前記メッセージを受信する手段と、
前記複数のデバイスの前記残りのデバイスのそれぞれのプロセッサにおいて決定用コード・シークエンスを実行することにより、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因に基づいて、該デバイスの前記プレゼンス状態を、前記メッセージの１つが示すプレゼンス状態と同期させるかを決定する手段と、を有するシステム。
【請求項２２】
前記メッセージは、さらに、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させる前記イベントの前記原因を含む、請求項２１に記載のシステム。
【請求項２３】
さらに、前記通信システムの少なくとも一人の他ユーザの端末を有し、
前記端末が、前記複数のデバイスが示すプレゼンス状態のリストを照合する手段と、前記リストの前記プレゼンス状態を所定の序列と比較し、最高位に格付けされたプレゼンス状態を前記ユーザが示す総合的プレゼンス状態として選択する手段とを含む、請求項２１または２２に記載のシステム。
【請求項２４】
さらに、前記少なくとも一人の他ユーザの前記端末のメモリに、前記総合的プレゼンス状態を格納する手段を有する、請求項２３に記載のシステム。
【請求項２５】
さらに、前記ユーザの前記総合的プレゼンス状態を、前記通信システムの少なくとも一人の他ユーザの前記端末において実行されるクライアント・プログラムのユーザ・インタフェースに示されるコンタクト・リストに表示する手段を有する、請求項２３または２４に記載のシステム。
【請求項２６】
前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させる前記イベントの前記原因は、
プレゼンス状態の自動変更、
プレゼンス状態の手動変更、
前記通信システムからの手動によるログオフ、
前記通信システムへの新たなログイン、および、
保存されたプレゼンス状態の取得、
のいずれか１つである、請求項２１ないし２５のいずれかに記載のシステム。
【請求項２７】
前記決定用コード・シークエンスは、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更であり当該手動変更が該デバイスにおける手動変更よりも最近である場合に、該デバイスの前記プレゼンス状態を前記メッセージが示す前記プレゼンス状態と同期させる、請求項２６に記載のシステム。
【請求項２８】
さらに、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更である場合、プレゼンス状態の前記手動変更を示すビットを前記デバイスメモリに格納する手段を有する、請求項２７に記載のシステム。
【請求項２９】
前記メッセージは、前記ビットを含む、請求項２８に記載のシステム。
【請求項３０】
前記決定用コード・シークエンスは、前記ビットを読み取って、前記メッセージが示す前記プレゼンスがプレゼンス状態の手動変更であるかを判断する、請求項２９に記載のシステム。
【請求項３１】
さらに、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更である場合、プレゼンス状態の前記手動変更の時刻を記録するタイムスタンプを前記デバイスメモリに格納する手段を有する、請求項２７ないし３０のいずれかに記載のシステム。
【請求項３２】
さらに、前記メッセージは、前記タイムスタンプを含む、請求項３１に記載のシステム。
【請求項３３】
前記決定用コード・シークエンスは、前記タイムスタンプを読み取って、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因がプレゼンス状態の手動変更であり当該手動変更が該デバイスにおける手動変更よりも最近であるかを判断する、請求項３２に記載のシステム。
【請求項３４】
前記決定用コード・シークエンスは、前記複数のデバイスの前記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因が、
プレゼンス状態の自動変更、
前記通信システムからの手動ログオフ、
前記通信システムへの新たなログイン、または、
保存されたプレゼンス状態の取得、
である場合に、該デバイスの前記プレゼンス状態を前記メッセージが示す前記プレゼンス状態と同期させない、請求項２６ないし３３のいずれかに記載のシステム。
【請求項３５】
前記プレゼンス状態の自動変更は、前記複数のデバイスの前記少なくとも１つのデバイスがアイドル状態に移行することで実行された変更である、請求項２６ないし３４のいずれかに記載のシステム。
【請求項３６】
前記プレゼンス状態の手動変更は、前記複数のデバイスの前記少なくとも１つのデバイスにて実行されるクライアント・プログラムのユーザ・インタフェースにおいて前記ユーザが特定のプレゼンス状態を選択することで実行された変更である、請求項２６ないし３５のいずれかに記載のシステム。
【請求項３７】
前記保存されたプレゼンス状態の取得は、前記ユーザが前記複数のデバイスの前記少なくとも１つのデバイスを用いて前記通信システムへログインすることで実行され、
前記複数のデバイスの前記少なくとも１つのデバイスは、以前に前記ユーザが選択した手動プレゼンス設定に対応し、前記デバイスメモリに格納されている、保存されたプレゼンスを備える、請求項２６ないし３６のいずれかに記載のシステム。
【請求項３８】
前記表示する手段は、さらに、
前記最高位に格付けされたプレゼンス状態と関係するデバイスから、前記最高位に格付けされたプレゼンス状態と関係するデバイスの有する特性の少なくとも１つに関する情報を受信する手段と、
前記少なくとも１つの特性に関する情報を示すプレゼンス標識を表示する手段と、を含む、請求項２５に記載のシステム。
【請求項３９】
前記通信システムは、ボイス・オーバー・インターネット・プロトコル通信システムである、請求項２１ないし３８のいずれかに記載のシステム。
【請求項４０】
前記ボイス・オーバー・インターネット・プロトコル通信システムは、ピア・ツー・ピア通信システムである、請求項１４に記載のシステム。
【請求項４１】
コンピュータによって実行されることで、請求項１ないし２０のいずれかに記載の方法のステップを実施するプログラム・コード手段を有する、コンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信状態の検出に関し、特に、例えば、パケット・ベースの通信システムにおいて利用する通信状態検出に関する。
【背景技術】
【０００２】
ボイス・オーバー・インターネット・プロトコル（「ＶｏＩＰ」）通信システムによって、パーソナル・コンピュータといったデバイスのユーザがインターネットといったコンピュータ・ネットワークを通じて電話をかけることが可能である。このようなシステムはユーザにとって有益である。なぜなら、固定電話線や移動ネットワークといった従来型の電話網に較べ、しばしば著しくコストが低く抑えられる。このことは、特に長距離電話において顕著である。ＶｏＩＰサービスを利用するには、ユーザは、デバイスにクライアント・ソフトウェアをインストールして実行させる必要がある。クライアント・ソフトウェアは、登録および認証といった他の機能とあわせてＶｏＩＰ接続を提供する。音声通信に加え、クライアントは、ビデオ通話やインスタント・メッセージング（「ＩＭ」）を提供することも可能である。
【０００３】
ＶｏＩＰ通信システムの一形態においては、独自仕様のプロトコル（proprietary protocols）を用いて構築されるピア・ツー・ピア（「Ｐ２Ｐ」）ネットワーク・トポロジが用いられる。スカイプ（商標）・システム（Skype(TM) system）は、この種の通信システムの一例である。ピア・ツー・ピア・ネットワークにアクセスするには、ユーザはユーザ端末上の当該Ｐ２Ｐシステムのオペレータから供されるＰ２Ｐクライアント・ソフトウェアを実行させ、そして、当該Ｐ２Ｐシステムに登録しなければならない。ユーザがＰ２Ｐシステムへ登録すると、クライアント・ソフトウェアがセントラル・サーバからデジタル証明書を受ける。ひとたびクライアント・ソフトウェアが当該証明書を備えれば、セントラル・サーバを用いることなしに以降のセットアップが実行され、Ｐ２Ｐシステムのユーザ間のルーティングが可能である。具体的には、ユーザは、１つまたは複数のデジタル証明書（あるいはユーザＩＤ証明書（user identity certificates 「ＵＩＣ」）を交換することによって、自身の、Ｐ２Ｐシステムを介した通信ルートを確立してＰ２Ｐシステムへアクセスする。ユーザ間におけるデジタル証明書の交換によりユーザの身元が証明され、適切にＰ２Ｐシステムにおける権限付与および認証がなされる。したがい、デジタル証明書の提示は、ユーザの身元に信用を与える。よって、中央サーバを使用せずにエンド・ユーザからエンド・ユーザへ直接的に通信ルートが設定されることこそが、ピア・ツー・ピア通信の特徴である。Ｐ２Ｐシステムについてのさらなる詳細については、ＷＯ２００５／００９０１９に開示されている。
【０００４】
公衆交換電話網を用いた従来の電話サービスとの比較におけるＶｏＩＰ通信システムの利点の一つは、プレゼンス情報（presence information）をユーザに提供できることである。プレゼンス情報は、システムのユーザに関する現在状態（current status）の示唆（indication）である。より具体的には、プレゼンス情報は、ユーザが蓄積した各コンタクトについて、クライアントのユーザインタフェースに表示される。表示可能なプレゼンス状態の例として、「オンライン」（"online"）、「オフライン」（"offline"）、「退席中」（"away"）、「利用不可」（"not available"）、「着信拒否」（"do not disturb"）が挙げられる。
【０００５】
プレゼンス状態を利用することによって、ユーザはコンタクトに対する通信を試みるよりも前に当該コンタクトの現在の状態に関する予備的知識を得ることができる。例えば、ユーザがオンラインでなく、よって連絡を取ることができない場合、ユーザは通話を試みるよりも前にその事を知ることができる。同様、コンタクトが多忙（ビジー（busy））であって返答できなさそうな場合、この事もプレゼンス状態から事前に承知される。この点は、ＰＳＴＮ電話システムに対する顕著な利点である。ＰＳＴＮ電話においては、番号をダイヤルしてから待機し、返答があるどうか様子を見ることしかできない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、ＶｏＩＰ通信システムのユーザが複数の相異なるデバイスを使用してＶｏＩＰ通信システムにアクセスする状況（シナリオ（scenario））において問題が生じている。例えば、ユーザは、パーソナル・コンピュータ（「ＰＣ」）、パーソナル・デジタル・アシスタント（「ＰＤＡ」）、移動電話、ゲーム機、その他の組み込みデバイスを併用してＶｏＩＰに接続することができる。ユーザは、上述のデバイスを複数用い、同時的にＶｏＩＰ通信システムと接続することができる。また、ユーザは、これら複数のデバイスを用いて相異なる複数の場所からＶｏＩＰ通信システムと接続することもでき、これらデバイスの接続は、ユーザがこれらデバイスの使用を終えた後も維持できる。例えば、ユーザは、家のＰＣ（home PC）からＶｏＩＰ通信システムに接続し、続けて、先ず家のＰＣの接続を切断したりすることなしに、オフィスのＰＣ（office PC）からＶｏＩＰ通信システムに接続することもできる。
【０００７】
問題は、これらデバイスが、ユーザについて、異なるプレゼンスを表示することである。したがって、ＶｏＩＰシステムの他ユーザに対して表示される該ユーザのプレゼンスは、該ユーザの実際の状態を反映するというよりは、むしろプレゼンスをレポートする複数のデバイスの１つに大きく依存している。
【０００８】
故に、複数のデバイスからのプレゼンス情報にかかる上述の問題に対処するための技術が必要となっている。
【課題を解決するための手段】
【０００９】
本発明の一態様により、ユーザが複数のデバイスを用いて接続する通信システムにおける当該ユーザの総合的プレゼンス状態を求める方法が供される。該方法は、上記複数のデバイスがそのデバイスメモリに該デバイスについてのプレゼンス状態を格納するステップと、上記複数のデバイスの少なくとも１つにおけるプレゼンス状態の変化を検出するステップと、上記複数のデバイスの各デバイスが、プレゼンス状態が含まれたメッセージを、上記通信システムを介して上記複数のデバイスの残りのデバイスに対して送信するステップと、上記複数のデバイスの上記残りのデバイスにおいて当該メッセージを受信するステップと、上記複数のデバイスの上記残りのデバイスのそれぞれのプロセッサにおいて決定用コード・シークエンス（デシジョン−メーキング・コード・シークエンス）を実行することにより、上記複数のデバイスの少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因（オリジン（origin））に基づいて、該デバイスのプレゼンス状態を、上記メッセージの１つが示すプレゼンス状態と同期させるかを決定するステップと、を有する。
【００１０】
本発明の別の一態様により、ユーザが複数のデバイスを用いて接続する通信システムにおける当該ユーザの総合的プレゼンス状態を求めるシステムが供される。該システムは、上記複数のデバイスのそれぞれのデバイスメモリに該デバイスについてのプレゼンス状態を格納する手段と、上記複数のデバイスの少なくとも１つにおけるプレゼンス状態の変化を検出する手段と、上記複数のデバイスの各デバイスから、プレゼンス状態が含まれたメッセージを、上記通信システムを介して上記複数のデバイスの残りのデバイスに対して送信する手段と、上記複数のデバイスの上記残りのデバイスにおいて当該メッセージを受信する手段と、上記複数のデバイスの上記残りのデバイスのそれぞれのプロセッサにおいて決定用コード・シークエンス（デシジョン−メーキング・コード・シークエンス）を実行することにより、上記複数のデバイスの上記少なくとも１つのデバイスにおけるプレゼンス状態を変化させるイベントの原因（オリジン（origin））に基づいて、該デバイスのプレゼンス状態を、上記メッセージの１つが示すプレゼンス状態と同期させるかを決定する手段と、を有する。
本発明のさらなる理解および本発明を実施する手法を示すため、その一例として下記の図面が参照される。
【図面の簡単な説明】
【００１１】
【図１】ユーザが複数のデバイスを操作するＶｏＩＰシステムの図
【図２】ＶｏＩＰクライアントのユーザ・インタフェースの例図
【図３】ユーザ端末の詳細図
【図４】３機のユーザ・デバイスが相異なるプレゼンス状態を保持する状況の例図
【図５】複数のデバイスを有するユーザについて単一のプレゼンス状態を決定するためのフローチャート
【図６Ａ】ログインにおけるプレゼンス状態を維持するためのフローチャート
【図６Ｂ】プレゼンス変更後のプレゼンス情報を維持するためのフローチャート
【図６Ｃ】手動ログオフ（マニュアル・ログオフ）後のプレゼンス情報を維持するためのフローチャート
【図７Ａ】プレゼンス情報が含まれるメッセージの構成図
【図７Ｂ】デバイスのプレゼンス状態を他のデバイスと同期化させるかを決定するためのフローチャート
【図８】表示すべき、ユーザについての総合的プレゼンス状態を決定するためのフローチャート
【図９】図４に例示した状況と複数のプレゼンス状態に対処する手法と合わせた図
【図１０】プレゼンス・インジケータ・アイコンの図
【発明を実施するための形態】
【００１２】
図１を参照する。本図は、ユーザが複数のデバイスを用いて通信を行うＶｏＩＰ通信システム１００を例示する。図１に示す実施形態においては、Ｐ２Ｐ通信システムが例示されるが、別の形式による通信形態を利用することも可能である。
【００１３】
Ｐ２Ｐ通信システムの第１ユーザ（「ユーザＡ」１０２と示す。）は複数のユーザ・デバイスを操作する。これらを１０４として示す。これらユーザ・デバイスは全て、インターネットといったネットワーク１０６に接続される。ユーザ・デバイス１０４は、例えば、パーソナル・コンピュータ（「ＰＣ」）（デスクトップもしくはラップトップ）、パーソナル・デジタル・アシスタント（「ＰＤＡ」）、移動電話、（無線式もしくは有線式の）内蔵型ＶｏＩＰデバイス、ゲーム機、または、その他ネットワーク１０６に接続可能な適当なデバイス、を含む。
【００１４】
図１に示す例においては、ユーザＡ１０２は３機のデバイスを有する。第１はデスクトップＰＣ１０８である。ユーザＡは、ディスプレイ画面ならびにキーボードおよびマウスを利用してデスクトップＰＣ１０８と相互に情報をやりとりする。デスクトップＰＣ１０８はモデムといったネットワーク・インタフェース１１０を介してネットワーク１０６と接続されており、デスクトップＰＣ１０８とネットワーク・インタフェース１１０との間の接続はケーブル式（有線式）接続または無線式接続であってよい。
【００１５】
デスクトップＰＣ１０８はクライアント１１２を実行中である。クライアント１１２はピア・ツー・ピア通信システムのオペレータから供される。クライアント１１２は、デスクトップＰＣ１０８に内在するプロセッサにおいて実行可能なソフトウェア・プログラムである。デスクトップＰＣ１０８はハンドセット１１４とも接続される。ハンドセット１１４はスピーカおよびマイクを備え、もってユーザは従来の固定回線電話と同じ方法で音声通話における聴取および発話が可能である。ハンドセット１１４は従来型の電話の送受話器の形態を有する必要はなく、ヘッドフォンもしくはイヤフォンの形態、または、デスクトップＰＣ１０８と接続された別個のラウドスピーカおよびマイクロフォンでもよい。
【００１６】
ユーザＡの第２のデバイス例は、移動電話１１６をＶｏＩＰシステムと接続可能にする内蔵（埋込）型クライアント１１８を備える移動電話１１６である。移動電話１１６はワイファイ・フォン（wifi phone）でもよい。ワイファイ・フォンは、ワイファイ無線ローカル・エリア・ネットワーク（ＩＥＥＥ８０２．１１）接続を用いてアクセス・ポイント（「ＡＰ」）１２０に接続される。ＡＰ１２０は、モデムといったネットワーク・インタフェース１２２を介してネットワーク１０６に接続される。複数の実施の形態において、ＡＰ１２０およびネットワーク・インタフェース１２２は単一のデバイス１２４に統合されてよい。代替の実施の形態においては、移動電話は、内蔵されたかまたはダウンロードされたクライアント・アプリケーションを実行するセル方式携帯無線電話（cellular phone）でもよい。
【００１７】
ワイファイ・フォン１１６は、ＶｏＩＰと接続して通話を行うためのスタンドアロンのデバイスとして動作する。デバイスに内在するプロセッサにおいて実行される内蔵型クライアント・ソフトウェア１１８と同様、ワイファイ・フォン１１６は、デバイスに統合されたディスプレイ、キーボード、マイク、および、スピーカを有し、ＶｏＩＰシステムを介した通話が可能である。
【００１８】
ユーザＡの第３のデバイス例はラップトップ１２６である。図１に示した本例においては、ラップトップ１２６は、ＡＰ１２０を利用してワイファイによる通信を行ってネットワーク・インタフェース１２２を介しネットワーク１０６と接続される。代替的実施形態において、ラップトップ１２６は有線接続によりネットワーク・インタフェースと接続可能である。ラップトップに内在するプロセッサにおいて実行されるものは、クライアント１２８である。クライアント１２８は、上述したデスクトップＰＣ１０８において実行されるクライアント１１２に類似する。ラップトップ１２６は一体型ディスプレイを備え、さらには、統合型のマイクおよびスピーカを備えてもよい（あるいは、これらはラップトップ１２６と別個であってもよい）。
【００１９】
ユーザＡ１０２が使用するデバイス１０４は、全て同一の敷地内にあっても、地理的に離れてあってもよい。例えば、デスクトップＰＣ１０８は（彼のオフィスに配された）ユーザＡの仕事用コンピュータでよく、ワイファイ・フォン１１６およびラップトップ１２６は、ユーザＡの家に配されてもよい。
【００２０】
図２は、ユーザＡ１０２の各デバイス１０４上で実行されるクライアント（１１２、１１８、１２８）のユーザ・インタフェース２００の例である。ただし、ユーザ・インタフェース２００の正確な見た目およびレイアウトは、画面サイズやデバイスの性能等に応じてデバイスに従うように変更されてよい。いずれにせよ、ユーザ・インタフェースに表示される情報は、あらゆるデバイスにおいておおよそ同等である。
【００２１】
クライアント・ユーザ・インタフェース２００はユーザＡ１０２のＰ２Ｐシステムにおけるユーザ名２０２を表示し、ユーザＡは手動で（マニュアルで）そのデバイスについての自身のプレゼンス状態を、アイコン２０４を選択することによりドロップ・ダウン・リストを用いて設定することができる。
【００２２】
クライアント・ユーザ・インタフェース２００は、「コンタクト」と名付けられたタブ２０６を備える。そしてこのタブが選択された場合には、ユーザがコンタクト・リストに格納したコンタクトが表示される。図２に示したユーザ・インタフェース例においては、Ｐ２Ｐシステムにおける別ユーザについての５つのコンタクト（ユーザＢないしＦ）がコンタクト・リスト２０８にリスト表示される。これらコンタクトはそれぞれ、コンタクトの詳細ならびにオンライン・プレゼンスおよびムード・メッセージの情報を表示させる権限をクライアント１０６のユーザに与えている。コンタクト・リストの各コンタクトは、各コンタクトに関連付けされたプレゼンス・ステータス・アイコンを備えている。例えば、ユーザＢに対するプレゼンス・ステータス・アイコン２１０は、ユーザＢが「オンライン」であることを示し、ユーザＣに対するプレゼンス・ステータス・アイコン２１２は、ユーザＣが「利用不可」（not available, NA）であることを示し、ユーザＤに対するプレゼンス・ステータス・アイコン２１４は、ユーザＤの状態が「着信拒否」（do not disturb, DND）であることを示し、ユーザＥに対するプレゼンス・ステータス・アイコン２１６は、ユーザＥが「退席中」（away）であることを示し、ユーザＦに対するプレゼンス・ステータス・アイコン２１８は、ユーザＦが「オフライン」であることを示す。また、この他のプレゼンス表示が含まれてもよい。これについては後でより詳細な説明を加える。コンタクト・リスト２０８におけるコンタクトの名前のとなりは、コンタクトについてのムード・メッセージ２２０である。
【００２３】
図３はクライアント（１１２、１１８、１２８）が実行される典型的なユーザ・デバイス（デスクトップＰＣ１０８、ワイファイ・フォン１１６、ラップトップ１２６等）の詳細図である。ユーザ・デバイスは中央処理装置（「ＣＰＵ」）３０２を有する。ＣＰＵ３０２は、画面（スクリーン）といったディスプレイ３０４、キーボード３０６およびポインティング・デバイス３０８（マウス、ジョイスティック、方向性パッド（directional pad）等）といった入力デバイス、スピーカ３１０、ならびに、マイク３１２と接続される。ＣＰＵ３０２は通信インタフェース３１３と接続される。通信インタフェース３１３は、デバイスをネットワーク１０６と接続可能にする。通信インタフェース３１３は無線式または有線式の接続を供する。
【００２４】
図３も、ＣＰＵ３０２上で実行されるオペレーティング・システム（「ＯＳ」）３１４を例示する。ＯＳ３１４の上層において実行されるものがクライアント（１１２、１１８、１２８）にかかるソフトウェア・スタック３１６である。ソフトウェア・スタックは、クライアント・ユーザ・インタフェース（「ＵＩ」）層３１８、クライアント・エンジン層３２０、および、プロトコル層３２２を表す。各層（レイヤー）は、特定の機能を表している。各層は通常、他の２層とのみ通信を行うため、図３のようなスタック構成とみなされる。オペレーティング・システム３１４は、デバイスのハードウェア・リソースを管理し、通信インタフェース３１３を介したネットワークとのデータの送受を処理する。クライアント・ソフトウェアのクライアント・プロトコル層３２２は、オペレーティング・システム３１４と通信し、Ｐ２Ｐシステムでのネットワーク接続を管理する。高度な処理が要求される処理はクライアント・エンジン層３２０へ送られ、クライアント・エンジン層３２０は、ユーザがＰ２Ｐシステムで通話を行ったり、通話を受けたりするために必要な処理を行う。クライアント・エンジン３２０もまた、ユーザのクライアント・ユーザ・インタフェース層３１８と通信する。クライアント・エンジン３２０がクライアント・ユーザ・インタフェース層３１８を制御して（図２に示されたような）クライアントのユーザ・インタフェースを介してユーザに情報を提示したり、ユーザ・インタフェースを介してユーザから情報を受け取ったりするように構成されてよい。
【００２５】
クライアント・エンジン層３２０は２つの機能ブロックを備える。これら機能ブロックは複数のデバイスの間におけるプレゼンス情報の管理に用いられる。第１のブロックは同期化マネージャ３２４であり、第２のブロックはプレゼンス・エンジン３２６である。これらの機能ブロックについては後でさらに詳細に説明する。
【００２６】
再び図１を参照し、ユーザＡがＰ２Ｐシステムで認証され、他ユーザ（ユーザＢとする。）との通話を開始するための処理について説明する。本例においては、ユーザＡはデスクトップＰＣ１０８を用いてユーザ１３２へ電話をかける。
【００２７】
上述したように、ユーザＡのデバイスのクライアントは、ユーザＡがＰ２Ｐシステムに登録されると、デジタル証明書（「ＵＩＣ」）を受け、続いて、セントラル・サーバを用いることなくＰ２Ｐのユーザ間の通信がセットアップされてルーティングが行われる。さらには、Ｐ２Ｐシステムへの初期の登録の後、ユーザＡはＰ２Ｐシステムにログインしてコンタクト・リストを表示させて電話をかけるためにユーザ名およびパスワードを入力する必要もある。本例におけるデスクトップＰＣ１０８の場合、この処理は、ユーザＡがデスクトップＰＣ１０８上で実行中のクライアント１１２にユーザ名およびパスワードを入力することで実行される。あるいは、認証の詳細事項についてクライアントに保存させておき、クライアントが実行されるたびにユーザが手動で毎回入力する必要を廃してもよいが、保存された詳細事項は認証サーバへ送られ認証の用に供せられる。
【００２８】
ユーザのためのコンタクト・リスト（例えばユーザＡ用のコンタクト・リスト２０８）は、図１におけるコンタクト・サーバ１３０に保存される。クライアント（１１２）がＰ２Ｐネットワークにログインすると、コンタクト・サーバ１３０との連絡が形成され、コンタクト・リストがデスクトップＰＣ１０８にダウンロードされる。これによってユーザがどのようなデバイスからＰ２Ｐネットワークにログインしても同一のコンタクト・リストにアクセスすることが可能になる。クライアントはさらに、定期的にコンタクト・サーバ１３０と通信を行い、コンタクト・リスト内のコンタクトに関する情報の変更を取得、あるいは、追加された新しいコンタクトを用いて保存されているコンタクト・リストを更新する。プレゼンス情報は、コンタクト・サーバにおいて一元的に格納されるものではない。クライアントは定期的にコンタクト・リスト２０８内の各コンタクトに対し、Ｐ２Ｐネットワークを介して直接的にプレゼンス情報をリクエストする。
【００２９】
ポインティング・デバイス３０８を用いてクライアント・ユーザ・インタフェース２００内にリスト表示されるコンタクトを選択して「通話」ボタン２２２（図２に図示。）をクリックすることで、Ｐ２Ｐシステムを通してコンタクト・リスト内のＰ２Ｐユーザへの通話が開始されてよい。あるいは、フィールド２２４内にコンタクトのＰ２Ｐアイデンティティ（ＩＤ）をタイプすることで、通話が開始されてもよい。通話のセットアップは独自仕様のプロトコルを用いて行われ、電話をかけたユーザと電話をかけられたユーザとの間のネットワーク１０６上のルート（経路）は、セントラル・サーバを用いることなしにピア・ツー・ピア・システムによって決定される。図１においては、電話をかける者、ユーザＡ（１０２）、と、電話をかけられた者、ユーザＢ（１３２）、との間のルートは、例示的に、Ｐ２Ｐシステムの他のピア（１３４、１３６、１３８、１４０）を介しているようにして示される。当然の事ながら、これらのピアは単なる例示目的であり、通話は、より少数またはより多数のピアを経由したルートを有してもよい。
【００３０】
デジタル証明書を提示して行われる（ユーザがＰ２Ｐシステムの真正の加入者であることを証明するための−−−ＷＯ２００５／００９０１９により詳細な説明がある−−−）認証の後で、ＶｏＩＰを用いて電話をかけることが可能になる。クライアント１１２は、ＶｏＩＰパケットのエンコードおよびデコードを行う。デスクトップＰＣ１０８からのＶｏＩＰパケットは、ネットワーク・インタフェース１１０を介してインターネット１０６へ送られ、Ｐ２Ｐシステムによって、ユーザＢがログインに用いている全てのデバイスに対してルーティングが行われる。例えば、ユーザＢ１３２が単一のデバイス、デスクトップＰＣ１４２でＰ２Ｐシステムにログインしているのみであれば、発呼は、ネットワーク・インタフェース１４４を介してユーザＢ１３２のデスクトップＰＣ１４２へルーティングされる。ユーザＢ１３２のデスクトップＰＣ１４２上で実行中の（クライアント１１２に類似した）クライアント１４６は、ＶｏＩＰパケットをデコードすることによりユーザＢ１３２がハンドセット１４８を用いて聴取可能な音声信号を生成する。逆に、ユーザＢ１３２がハンドセット１４８へ発声すると、デスクトップＰＣ１４２上で実行中のクライアント１４６は、音声信号をエンコードしてＶｏＩＰパケットを生成しインターネット１０６を通してユーザＡ１０２のデスクトップＰＣ１０８へこれらのパケットを送信する。デスクトップＰＣ１０８上で実行中のクライアント１１２は、ユーザＢ１３２からのＶｏＩＰパケットをデコードしてユーザＡ１０２がハンドセット１１４を用いて聴取可能な音声信号を生成する。
【００３１】
上述のＰ２Ｐ通話のためのＶｏＩＰパケットはインターネット１０６のみを経由し、公衆交換電話網（「ＰＳＴＮ」）は含まれない。また、ネットワークにかかるＰ２Ｐの性質上、Ｐ２Ｐネットワークのユーザ間の実際の音声通話はセントラル・サーバを用いずに行われる。（セントラル・サーバは初期の登録および認証、ならびに、一元的コンタクト・リスト保持にのみ必要である。）このことは、ネットワークの縮小拡大を容易とし、音声品質を高品質に保ち、かつ、ユーザが思うままに通話することを可能にする。
【００３２】
ユーザＡ１０２、ユーザＢ１３２は共に、複数のデバイスを用いてＰ２Ｐシステムにログインすることができる。例えば、ユーザＢ１３２は、内蔵クライアント１５２を備えるコード電話機１５０を用いてよい。コード電話機１５０は、同一のネットワーク・インタフェース１４４に接続されるように図示されている。また、図１に示す例においては、ユーザＢ１３２は、ラップトップ１５４も使用する。ラップトップ１５４ではクライアント１５６が実行されており、ネットワーク・インタフェース１５８を介してネットワーク１０６に接続される。これらの幾つかあるいは全てのデバイスがＰ２Ｐシステムにログインした場合において、ユーザＡ１０２からの電話の呼び出しがあると、ログインしている全てのデバイスが、そのうちの１つでユーザＢ１３２が応答するまで、鳴動する。
【００３３】
当然の事ながら、図１に示した個々のデバイスおよび構成は状況例であり、ユーザは、より多数もしくはより少数のデバイスを、ことなる構成において使用してよい。
【００３４】
Ｐ２Ｐシステムにログインしている複数のデバイスが存在する場合、各デバイスにおいて実行中のクライアントが相異なるプレゼンス・ステータスを有するという問題が生じる。したがい、ユーザＡのプレゼンスを見ようとするリモート・ユーザに表示するべき、単一で、統一されたプレゼンス状態がない。図４は、この問題を例示する。図４は、例示的状況である。本状況例は、ユーザＡ１０２の３つのデバイス−−−デスクトップＰＣ１０８、ワイファイ・フォン１１６、および、ラップトップ１２６−−−に関する。先ず、時刻ｔ＝０において、全てのデバイスはオフラインである（つまり、Ｐ２Ｐシステムにログインしていない）。次に、ｔ＝１において、ユーザＡはデスクトップＰＣ１０８を用いてＰ２Ｐシステムにログインする。よって、デスクトップＰＣ１０８のクライアント１１２のプレゼンス状態は「オンライン」である。この時点において、デスクトップＰＣ１０８はＰ２Ｐシステムにログインしている、ユーザＡの唯一のデバイスである。（故にただ一つのプレゼンス状態でもある。）したがい、リモート・ユーザ（例えばユーザＢ１３２）がユーザＡのプレゼンスを見るのに何ら問題は生じていない。
【００３５】
時刻ｔ＝２において、ユーザＡはワイファイ・フォン１１６を用いてＰ２Ｐシステムへログインし、ワイファイ・フォンにおいて実行されるクライアント１１８もまた「オンライン」のプレゼンスを有する。したがってｔ＝２において、ユーザＡに関し、２つのデバイスがＰ２Ｐシステムへログインしており、両者は共に「オンライン」ステータスを示す。ｔ＝３において、デスクトップＰＣ１０８は暫くの間アイドル状態となり、クライアント１１２の自動タイマがこれを検知し自動的にプレゼンス状態を「退席中」にする。この時点において、ワイファイ・フォン１１６は「オンライン」を示し、デスクトップＰＣ１０８は「退席中」を示すこととなり、デバイス間においてプレゼンス状態に衝突（コンフリクト、conflict）が生じる。この状況において、リモート・ユーザに対していずれのプレゼンス状態を表示するべきか不確定となる。
【００３６】
例えば、ユーザＢ１３２が、彼のコンタクト・リストにユーザＡ１０２を備えている場合、ユーザＢのデバイスのクライアントは、定期的にユーザＡ１０２をポーリングして彼のプレゼンス状態を求めることになる。もし、ユーザＢに対して最も新しく報告されたプレゼンス状態が表示されるなら、ユーザＡのデバイスのいずれが先に応答したかによって「退席中」とも「オンライン」ともなり得る。また、毎回異なるデバイスが報告をするようなことがあると、ポーリングのたびにプレゼンス状態が交代することもあり得る。このような挙動は望ましいものではない。
【００３７】
図４において、ｔ＝５で状況はさらに複雑になる。ユーザＡは手動で（マニュアルで）彼のワイファイ・フォン１１６に「着信拒否」（「ＤＮＤ」（do not disturb））をセットする（ｔ＝４）、その後、ラップトップ１２６上でログインする。この時点において、互いに異なるプレゼンス状態を有する３つのデバイスが存在する。異なるデバイス間で異なるプレゼンス状態が存在する状況は、ユーザＡが手動で全てのデバイスに同一のプレゼンス状態をセットするか、１つを残して他の全てのデバイスでログアウトするまで存続する。
【００３８】
上述した問題は、図３に関して説明した２つの機能ブロック−−−同期化マネージャ３２４およびプレゼンス・エンジン３２６−−−を用いれば解消される。
【００３９】
同期化マネージャ３２４は、（図３に示されるように）各デバイス上で動作するクライアントそれぞれに存在する機能ブロックである。同期化マネージャ３２４の目的は、同一のユーザ名を用いてＰ２Ｐシステムにログイン中の、他デバイス上で動作するクライアントの有無を求めることである。換言すれば、ある特定のユーザがログインに用いた所与のクライアントについて同期化マネージャ３２４は、Ｐ２Ｐシステム内において同一のユーザ名で動作しているクライアントのインスタンスがあるかどうかを求める。したがって、図１の例においては、デスクトップＰＣ１０８のクライアント１１２の同期化マネージャは、ユーザＡについて動作中の他の２つのインスタンス（ワイファイ・フォン１１６およびラップトップ１２６）が存在することを求める。同様、ワイファイ・フォン１１６のクライアント１１８の同期化マネージャは、ユーザＡがデスクトップＰＣ１０８およびラップトップ１２６をも用いてログインしていることを求める。同様、ラップトップ１２６のクライアント１２８の同期化マネージャは、ユーザＡ１０２がデスクトップＰＣ１０８およびワイファイ・フォン１１６をも用いてログインしていることを求める。
【００４０】
同一のユーザ名でログインしているクライアントのインスタンスが存在するかどうかを求めることに加え、望ましくは、同期化マネージャ３２４は他のインスタンスの性能（capabilities）を求める。
【００４１】
同期化マネージャ３２４は、問題にしている特定のユーザ名に関する情報についてＰ２Ｐシステムに対して定期的にポーリングを行い、他のインスタンスに関する情報を特定する。
【００４２】
同期化マネージャ３２４が他のインスタンスに関する情報を発見すると、当該インスタンスとの間の通信が確立され情報を共有する。具体的には、プレゼンス状態に関する情報は、特定のユーザ名としてログインしている全てのクライアントのインスタンスへ配信される。特に、同期化マネージャは発見した全ての他のインスタンスに対し定期的にプレゼンス情報を送信する。これについては後でより詳細に説明する。
【００４３】
プレゼンス・エンジン３２６の機能とは、クライアントのプレゼンス状態を監視して該デバイスのプレゼンスが何であるか、および、当該プレゼンスの出自（原因、オリジン（origin））が何であるか、についての正確な記録（レコード）を維持することである。また、プレゼンス・エンジン３２６は他のインスタンスからの更新（アップデート（update））を受け取り、それに対してどのような反応をするかを決定する。
【００４４】
より具体的には、プレゼンス・エンジン３２６および同期化マネージャ３２４の機能は、４つの工程でなる処理に要約可能である。これらについて、図５にフローチャートとして示す。ステップＳ５０２において、プレゼンス・エンジン３２６はクライアントのプレゼンス状態の記録を維持する。当該記録はプレゼンスの変更に関する理由または源（ソース（source））を含む。変更には手動的な（マニュアルによる）プレゼンスの変更、自動的な（オートマチックによる）プレゼンスの変更、あるいは、保存され取得されたプレゼンスが含まれてよい。これについては、図６ＡないしＣを参照し、後でより詳細に説明する。
【００４５】
プレゼンス状態情報は、同期化マネージャ３２４がステップＳ５０４において発見した全てのインスタンスに対して配信される。これについては図７Ａにより詳細に示されている。
【００４６】
ステップＳ５０６において、全ての他のインスタンスにおけるプレゼンス・エンジン３２６が、ステップＳ５０４において配信されたプレゼンスの変更に関する情報を受け取る。（Ｓ５０４より）他のインスタンスにおけるプレゼンスの変更に関する情報を受け取ると、（それぞれに異なるデバイスに関連した）残りのプレゼンス・エンジン３２６はそれぞれ、当該情報を解析して自身のプレゼンス状態を、別のインスタンスにおいて変更された新しいプレゼンス状態と同期させるかどうかを決定する。本プロセスについては、図７Ｂを参照して以下にて詳細に説明する。特にステップＳ５０６においてはプレゼンスの変更の源（ソース）を用いてプレゼンス状態を同期化させるかどうかが決定される。
【００４７】
最後に、ステップＳ５０８においては、（Ｐ２Ｐシステムの別のユーザの、例えばユーザＢ１３２の）リモート・デバイスにおけるプレゼンス・エンジン３２６が、複数デバイスを有するユーザ（例えばユーザＡ１０２）に対して表示するべき単一の統一された見えるプレゼンス状態を決定する。このプロセスは、後で図８を参照してより詳細に説明する。
【００４８】
次に図６Ａないし６Ｃを参照する。これら図は図５のステップＳ５０２のさらなる詳細を示す。上述のように、本プロセスの目的はあらゆる変更に対してプレゼンスおよび理由を保持することである。
【００４９】
プレゼンス状態情報は４項目のデータを格納することで保持される。プレゼンス・エンジン３２６は２つの別個のプレゼンス状態変数を保持する。これらの第１は「設定アベイラビリティ」状態と称される。これは、デバイスのユーザによって設定されているプレゼンス状態を格納する。第２は、「フィードバック・アベイラビリティ」状態と称される。これは、デバイスのユーザに対して実際に表示されるプレゼンス状態を格納する。これは、クライアントのＵＩに表示されるプレゼンス状態がユーザによって設定されたプレゼンス状態と異なるような場合に役立つ。このような場合の簡単な例として、ユーザがプレゼンス状態を選択した場合でありかつクライアントがまだなおＰ２Ｐシステムへの接続を試みているような場合が挙げられ、この場合、「設定アベイラビリティ」はユーザが選択したプレゼンス状態であるが、「フィードバック・アベイラビリティ」は「接続中」なるステータスをクライアントのＵＩにおいて示す。格納される第３のデータ項目は単一のビットであって、当該単一のビットは、「設定アベイラビリティ」に格納されているプレゼンスが現在のセッションの間にユーザによって変更されたものであるかどうか、つまり、当該プレゼンスがユーザによって手動で（マニュアルで）設定されたものかあるいは以前のセッションで保存されたプレゼンス状態から取得したものであるか、を示す。第４のデータ項目は、「設定アベイラビリティ」にかかるプレゼンス状態が記録された時刻についてのタイムスタンプである。
【００５０】
プレゼンス・エンジンは上述の情報を用いてプレゼンス状態の原因（オリジン（origin））もしくは源（ソース（source））を求める。例えば、変更がユーザによる（例えば、図２におけるドロップ・ダウン・リスト２０４を用いた）手動的なプレゼンスの変更の結果である場合には、これは手動的な（マニュアルでの）プレゼンスの変更であると言える。プレゼンスの変更が自身のプレゼンスを変更すると決定した結果（例えば、デバイスの非アクティブ（inactive）に起因した「退席中」もしくは「利用不可」へのプレゼンスの変更）である場合には、これは自動的な変更であると言える。
【００５１】
先ず、図６Ａを参照する。図６Ａは、ユーザがデバイスを用いてＰ２Ｐシステムにログインする際にプレゼンスを設定するための処理を例示する。ステップＳ６０２において、ユーザはデバイス（例えば、ユーザＡ１０２のデバイス１０４のいずれか１つ）を用いてＰ２Ｐシステムにログインする。ステップＳ６０４において、プレゼンス・エンジン３２６は、当該デバイスについて、以前に保存したプレゼンス状態があるかどうかをチェックする。
【００５２】
ユーザは故意に特定の状態（例えば「着信拒否」（"do not disturb"））を設定してからその後で（例えば、ワイファイ接続の喪失で）ネットワークから切断されるような場合もあるため、保存されたプレゼンス状態を利用することは有利である。手動的に設定されたプレゼンス状態を保存することで、ユーザがオンラインに復帰したときにその状態を回復させることが可能になる。もしプレゼンス状態が保存されないならば、ユーザは、「着信拒否」ではなく「オンライン」状態で復帰することになり、彼は以前に明示的に彼のプレゼンスを「着信拒否」に設定したにもかかわらず、別のユーザからの連絡を受けることになってしまう。
【００５３】
ステップＳ６０４において、以前に保存した手動的プレゼンス状態が存在しないと判断されたならば、ユーザはデフォルトのプレゼンス（例えば、「オンライン」）でネットワークにログオンし、当該プレゼンス状態が、ステップＳ６０６において、「設定アベイラビリティ」および「フィードバック・アベイラビリティ」の両変数として格納される。
【００５４】
もし、ステップＳ６０４において、以前に保存した手動的プレゼンス状態が存在すると判断されれば、ステップＳ６０８において、プレゼンス格納部６００からこれが取得され、当該保存されたプレゼンス状態が該デバイスについての新しいプレゼンスとして設定される。具体的には、取得されたプレゼンス状態は、ステップＳ６１０において、「設定アベイラビリティ」および「フィードバック・アベイラビリティ」の両方の変数に格納される。
【００５５】
次に図６Ｂを参照する。図６Ｂはデバイスのプレゼンス状態に変化が生じた場合におけるプレゼンス情報更新のための処理のフローチャートである。
【００５６】
ステップＳ６１２において、ある特定のクライアントについてのプレゼンス・エンジン３２６が当該デバイスに関するプレゼンス状態の変化を検出する。例えば、図１を参照すれば、デスクトップＰＣ１０８のクライアント１１２におけるプレゼンス・エンジンは、デスクトップＰＣ１０８上のプレゼンス状態が変化したことを検出すればよい。
【００５７】
ステップＳ６１４において、プレゼンス・エンジン３２６は、変更（変化）の源（ソース）が自動変更か手動変更かを判断する。自動変更であると判断すれば、ステップＳ６１６において新しいプレゼンスを（「設定アベイラビリティ」ではなく）「フィードバック・アベイラビリティ」の変数のみに記録する。この理由は、ユーザが能動的に彼のプレゼンス状態を設定したのではないからである（故に「設定アベイラビリティ」には格納されない。）。だが、この新しいプレゼンス状態は、当該クライアントのＵＩにおいて当該ユーザに対して表示される。（故に「フィードバック・アベイラビリティ」を設定する。）この時点において「設定アベイラビリティ」と「フィードバック・アベイラビリティ」とに異なる値が設定されていることを用いてプレゼンス変更の原因（オリジン（origin））を自動（オートマチック）であると判断することができる。これについては後で説明する。
【００５８】
ステップＳ６１４が手動変更であると判断すれば、ステップＳ６１８においてプレゼンス・エンジンは、プレゼンス状態における当該手動変更を「設定アベイラビリティ」および「フィードバック・アベイラビリティ」の両方の変数に格納する。ステップＳ６２０において、プレゼンス状態における当該手動変更もプレゼンス格納部６００に格納される。プレゼンス格納部６００は永続的なストレージであり、よって、もしユーザがＰ２Ｐシステムから切断されるかあるいはログオフすれば、（図６ＡのステップＳ６０８に示したように）当該手動的設定によるプレゼンス状態が回復可能である。ステップＳ６２２においてビットを設定することにより、当該ビットが、「設定アベイラビリティ」の変数に格納された値は現セッション中にユーザによって手動的に変更された値であることを示すようになる。このビットの使用法については後でより詳細に説明する。最後にステップＳ６２４において、プレゼンスにおける手動変更についてのタイムスタンプが記録される。
【００５９】
次に図６Ｃを参照する。図６Ｃはシステムからの手動（マニュアル）サイン・アウトの後においてプレゼンスを維持するためのフローチャートである。ステップＳ６２６においてユーザは、システムからのサイン・アウトを手動的に選択する。ステップＳ６２８において、「設定アベイラビリティ」および「フィードバック・アベイラビリティ」の両者の変数に新しいプレゼンス状態（「オフライン」）が記録される。
【００６０】
他の実施形態において、図６Ｃの処理は、別の工程（図示せず。）を含んでもよく、そうすることで、ユーザが１つのデバイスについて手動的にサイン・アウトを行った場合に彼が有するその他全てのアクティブなデバイスについてサイン・アウトを行うことを望むかどうかを彼に問いただしてもよい。彼がそうすることを選んだ場合には、同期化マネージャから当該全てのデバイスに対してメッセージが発せられ、デバイスにＰ２Ｐシステムからログオフすることを指示する。
【００６１】
図６Ａないし図６Ｃのフローチャートにおいて情報が維持されることにより、プレゼンス状態の原因（オリジン）もしくは源（ソース）を容易に求めることが可能となる。例えば、「フィードバック・アベイラビリティ」と「設定アベイラビリティ」の変数が異なる場合にはプレゼンスの原因（オリジン）は「自動（オートマチック）」変更である。セッション中におけるプレゼンス変更を示すビットがセットされていない場合、これは、当該セッション中に「設定アベイラビリティ」が変更されたことがないことを意味し、これにより、原因（オリジン）は、「保存された」プレゼンス状態（つまり、以前のセッションからの持ち越し）、または、新しいログイン（なぜなら、当該ビットは図６ＢのステップＳ６２２においてのみセットされ、図＆Ａにおいてはセットされない。）であることを意味する。あるいは、上述の状況に合致しない場合には、原因（オリジン）は、プレゼンスにおける「手動」変更である。
【００６２】
次に図７Ａを参照する。図７Ａは、同期化マネージャ３２４によってあるデバイスから他のインスタンスに対して定期的に送信されるメッセージの内容の例を示す図である。本例は、あくまで例である。メッセージの精緻な構成および内容は実施形態によって異なることがある。
【００６３】
メッセージの第１部分７０２は、「設定アベイラビリティ」の変数に格納されたプレゼンスの値を含む。メッセージの第２部分７０４は、現セッション中にプレゼンスの変更がなされたことがあるかどうかを示すビットの値を含む。メッセージの第３部分７０６は、（存在する場合に）プレゼンスの手動変更のタイムスタンプを含む（Ｓ６２４においてセットされる。）。
【００６４】
メッセージに含まれる情報は、他のインスタンスが当該デバイスにおけるプレゼンス状態の変更にどのように応じればよいかを決定するのに十分な情報を含んでいる。
【００６５】
「フィードバック・アベイラビリティ」は他のインスタンスに対して送信される必要がないことを注記しておく。なぜなら、「フィードバック・アベイラビリティ」および「設定アベイラビリティ」は、自動変更の結果として異なるのみだからである。プレゼンスにおける自動変更は全てのデバイスで同期化されない。（例えば、アイドルにあるためにデスクトップＰＣ１０８が「退席中」状態に変化したとしても、ワイファイ・フォン１１６およびラップトップ１２６のプレゼンス状態は変更されない。）したがって、他のインスタンスが自動変更の通知を受け取る必要性はない。故に「フィードバック・アベイラビリティ」を他のインスタンスへ送る必要はない。
【００６６】
次に、図７Ｂを参照する。図７Ｂは、図５のＳ５０６の処理をより詳細に示す図である。本プロセスはクライアントのプレゼンス・エンジン３２６が、（図７Ａのメッセージに含まれる）他のインスタンスからのプレゼンス情報の受信に応じ、実行する。例えば図１を参照すれば、デスクトップＰＣ１０８上においてプレゼンスが変更されると、当該変更は、図７Ａのメッセージと類似したメッセージで他のインスタンス（ワイファイ・フォン１１６およびラップトップ１２６）へ報告される。すると、図７Ｂを参照しながら以下で説明する処理が、当該プレゼンス情報を受信するインスタンス、つまりワイファイ・フォン１１６およびラップトップ１２６、のそれぞれにおいて実行される。
【００６７】
ステップＳ７０８において、クライアントのプレゼンス・エンジン３２６は他のインスタンスからプレゼンス情報メッセージを受信し、比較のためにそれらをまとめる（コンパイルする（compile））。ステップＳ７１０において、プレゼンス・エンジン３２６は第１インスタンスについてのプレゼンス情報を読み取る。
【００６８】
ステップＳ７１２において、現セッション中における変更を示すビット（７０４）を読み取る。もしこのビットがセットされていなければ、このことは「設定アベイラビリティ」が保存されたプレゼンスあるいは新たなログインに由来することを意味する。これらのプレゼンス状態はデバイス間で同期化されない。この場合、Ｓ７１４においてプレゼンス・エンジン３２６は、読み取るべき他のインスタンスからの情報があるかをチェックし、もし存在するならばステップＳ７１６において次のインスタンスからの情報を読み取る。
【００６９】
Ｓ７１２に戻り、もしビットがセットされていれば、このことは現セッションにおいてプレゼンスの手動変更を意味する。この場合、ステップＳ７１８において当該手動変更にかかるタイムスタンプ（７０６）が読み出される。ステップＳ７２０において、これを既知の最新の手動変更と比較する。該既知の最新の手動変更は、格納部７２２に格納されている。（当然のことだが、この既知の最新の手動変更は、本アルゴリズムが実行される前に時刻ヌル値に初期化される。）
【００７０】
手動変更にかかるタイムスタンプがこれまでに読み出されたもののうちで最新のもので無い場合、ステップＳ７１４においてプレゼンス・エンジンは、読み出すべき、他のインスタンスからの情報があるかどうかチェックする。もし存在するならばステップＳ７１６において次のインスタンスからの情報を読み出す。しかしながら、もし手動変更にかかるタイムスタンプがこれまでに読み出されたもののうちで最新のものであれば、ステップＳ７２４において、当該最新の値が格納部に書き込まれる（以前の値に上書きされる）。そしてステップＳ７１４に戻り、プレゼンス・エンジンは、読み出すべき、他のインスタンスからの情報があるかどうかをチェックする。もし存在するならばステップＳ７１６において次のインスタンスからの情報を読み出す。
【００７１】
全てのインスタンスからの全ての情報を読み出すと、処理はステップＳ７１４に戻る。そしてプレゼンス・エンジンは、考慮すべき、他のインスタンスからの情報はもう残っていないと判断する。そして処理はステップＳ７２６に進む。該ステップでは、（７２２に格納された）全てのインスタンスからの最新の手動変更が読み出され、現デバイス（つまり本アルゴリズムを実行しているデバイス）上における手動変更のタイムスタンプと比較される。
【００７２】
ステップＳ７２６において、他のインスタンス上における手動変更が、現デバイス上よりも最近のものであることが判明すれば、（ステップＳ７２８において）現デバイスのプレゼンスが、より最近の手動設定によるプレゼンスを有するインスタンスのプレゼンスと同期化される。
【００７３】
逆に、ステップＳ７２６において、現デバイスにおける手動変更が、あらゆる他のインスタンス上よりも最近のものであることが判明すれば、ステップＳ７３０においてプレゼンスは同期化されない。
【００７４】
デバイスが、（Ｓ７２６に示すように）他のインスタンスのプレゼンス状態と同期する場合、これは原デバイスの「設定アベイラビリティ」および「フィードバック・アベイラビリティ」の変数に格納される。
【００７５】
図７Ｂに示す処理が実行された後、アクティブなインスタンスのそれぞれは、１つのデバイス上のプレゼンスにおける変更の通知を受ける。そして個々のインスタンスは、当該変更に応答して自身のプレゼンスを同期化させるか否かを決定する。しかしながら、異なるインスタンスが異なるプレゼンスを有し得るという問題が残る。したがって、Ｐ２Ｐシステムの他のユーザに対して示すべき単一のプレゼンス状態をどのようなものにするかを算定する必要がある。当該プレゼンスの決定のための処理を図８に例示する。
【００７６】
図８は、図５のステップＳ５０８における処理をより詳細に示す図である。図８の処理は、リモート・ユーザ（遠隔ユーザ）のプレゼンス・エンジン３２６において実行される。例えば、再度図１を参照すれば、ユーザＡ１０２の３機のデバイス（１１２、１１６、１２６）はそれぞれ、図７Ｂに示した処理の後において相異なるプレゼンス状態を有し得る。したがって、（コンタクト・リストにユーザＡ１０２を備えた）ユーザＢ１３２のクライアント１４６は、これらプレゼンス状態のいずれをユーザＢのクライアント１４６のＵＩに表示させるべきかを求めなければならない。
【００７７】
図８のステップＳ８０２において、リモート・ユーザのクライアント（例えば、ユーザＢのクライアント１４６）のプレゼンス・エンジン３２６は、彼のコンタクトについての全てのインスタンスのプレゼンス状態を（例えば、ユーザＡ１０２の全てのデバイス１０４をポーリングすることによって）読み出す。ポーリングを受けたデバイスは自身の「フィードバック・アベイラビリティ」の値をリモート・ユーザに対して報告する。ここで、自身の「設定アベイラビリティ」ではない理由は、図８のアルゴリズムが自動的に設定されたプレゼンス状態を知る必要があるからである。
【００７８】
全てのインスタンスについての「フィードバック・アベイラビリティ」のプレゼンス状態が読み出されると、ステップＳ８０４において、これらプレゼンス状態が全て同一であるかどうかがチェックされる。このような状況は、ユーザが手動でプレゼンス状態を設定してこれが全てのデバイスにおいて同期化されることで、しばしば生じ得る。（図７ＢステップＳ７２８参照。）もし、各インスタンスのプレゼンス状態が全て同一であれば、ステップＳ８０６において当該ユーザについての（リモート・ユーザのクライアントに表示されることになる）プレゼンス状態は、全てのインスタンスが共通に備えるプレゼンス状態に設定される。
【００７９】
全てのインスタンスにおけるプレゼンス状態が同一ではないことがステップＳ８０４において判明すれば、ステップＳ８０８において、当該デバイス群の複数のプレゼンス状態は、テーブル８００に記憶された優先度リストと比較される。好適な実施形態においては、リストは「アベイラビリティ優先度」の順でリスト化されている。例えば、以下のアベイラビリティ優先度の例では、７つのプレゼンス状態が示されている。
１．着信拒否
２．ＳｋｙｐｅＭｅ（ＴＭ）スカイプ・ミー（商標）
３．オンライン
４．退席中
５．利用不可
６．不可視（インビジブル（invisible））
７．オフライン
【００８０】
明らかだが、別の実施形態においては、本優先度リストにおけるプレゼンス状態の順の詳細な選定が異なっていてよく、また、異なる数のプレゼンス状態が含まれてもよい。
【００８１】
全てのインタンスにおけるプレゼンス状態が優先度テーブルと比較された後、ステップＳ８１０において、当該リストにおける最高位のプレゼンス状態が、ユーザに見えるプレゼンス状態として選択される。このプレゼンス状態がリモート・ユーザのクライアントに表示される。
【００８２】
次に図９を参照する。図９は、既に図４を参照して説明した状況と同一の状況例を示す図である。ただし、ここでは図５ないし８に示した処理が用いられて複数のデバイスのプレゼンスが管理されている。時刻ｔ＝０において、全てのデバイスはオフラインである（つまり、Ｐ２Ｐシステムにログインしていない）。したがって、ユーザＡ１０２について外側に（リモート・ユーザに）見えるプレゼンスは（軸９０２に示すように）「オフライン」である。時刻ｔ＝１において、ユーザＡは、デスクトップＰＣ１０８を用いてＰ２Ｐシステムにログインする。よって、デスクトップＰＣ１０８のクライアント１１２におけるプレゼンス状態は「オンライン」である。この時点において、Ｐ２ＰシステムにログインしているユーザＡ１０２の唯一のデバイスである（故に、ただ１つのプレゼンス状態）。したがって、リモート・ユーザ（たとえば、ユーザＢ１３２）にとって、外側に見えるプレゼンス９０２は「オンライン」である。
【００８３】
時刻ｔ＝２において、ユーザＡ１０２はワイファイ・フォン１１６でＰ２Ｐシステムにログインする。ワイファイ・フォンで実行されるクライアント１１８もプレゼンス「オンライン」を有する。同一のプレゼンス状態を有するワイファイ・フォン１１６がオンラインに現れることでデスクトップＰＣ１０８のステータスは変更されない。外側に見えるプレゼンスは「オンライン」のままである。（図８、Ｓ８０４およびＳ８０６を参照。）
【００８４】
ｔ＝３において、デスクトップＰＣ１０８はしばらくの間のアイドルが続いている。そしてクライアント１１２の自動タイマがこれを検知し自動的にプレゼンス状態を「退席中」にする。自動的なプレゼンス変更は、ワイファイ・フォン１１６へ報告されない。（「フィードバック・アベイラビリティ」に記録される。）よって、ワイファイ・フォンは、自身のプレゼンスを「退席中」ステータスに同期化することはない。なぜなら、これは自動変更の結果だからである。外側に見えるプレゼンスは、図８にしたがって決定される。この場合、デスクトップＰＣ１０８は「退席中」のプレゼンスを有し、ワイファイ・フォンは「オンライン」である。上述の（本例で用いられる）アベイラビリティ優先度リストに従えば、これらデバイスについて最高位に格付けされたプレゼンスはワイファイ・フォン１１６の「オンライン」ステータスである。よって、外側に見えるプレゼンス９０２は保たれる。
【００８５】
ｔ＝４において、ユーザＡ１０２はワイファイ・フォン１１６のステータスを手動でＤＮＤ（着信拒否）に設定する。この手動変更にしたがい、デスクトップＰＣ１０８へのメッセージ（図７Ａ）にはこの変更が反映され、デスクトップＰＣは、当該手動変更がデスクトップＰＣ１０８上における手動変更のいずれよりも新しいので、自身のプレゼンスをこの手動変更された設定に同期化する。したがって、デスクトップＰＣのプレゼンスは、この時点ではＤＮＤを示す。結果として、アクティブなデバイスのプレゼンスの設定は同一となり、外部に見えるプレゼンス９０２もＤＮＤとなる。
【００８６】
図４の時刻ｔ＝５においては、ユーザＡはラップトップ１２６にログイン１２６し、今度は、３機がアクティブなデバイスとなる。この、新たなログインによりラップトップのプレゼンスは当初「オンライン」となる。このことはワイファイ・フォン１１６およびデスクトップＰＣ１０８へ報告される。しかしながら、この新たなログインがデスクトップおよびワイファイ・フォン１１６のプレゼンスを覆すことはない。なぜなら、ビット（７０４）がセットされていない（故に、図７ＢのＳ７１２における手動変更ではない）からである。したがって、デスクトップＰＣ１０８およびワイファイ・フォン１１６におけるプレゼンス状態は変更されないで残る。さらに、ラップトップ１２６は、ワイファイ・フォン１１６およびデスクトップＰＣ１０８からプレゼンス情報を受け取ることになる。これには、手動的にＤＮＤプレゼンスが設定されたことが示されている。これにより、ラップトップ１２６がＤＮＤプレゼンスに同期化される。したがって、全てのデバイスに対するプレゼンスはＤＮＤとなり、リモート・ユーザにおいて表示されるプレゼンスはＤＮＤのままである。
【００８７】
ｔ＝６において、ラップトップ１２６はアイドル状態にあり、自動的に「利用不可」に変更される。この変更は自動変更であるため、ワイファイ・フォン１１６およびデスクトップＰＣ１０８においてこの変更に同期化されることはない。外側に見えるプレゼンス９０２はＤＮＤのままに残る。なぜなら、ＤＮＤは「利用不可」よりも高位に格付けされているからである。
【００８８】
時刻ｔ＝７において、ワイファイ・フォン１１６はオフラインになる。例えば、ユーザＡが、ワイファイ接続が喪失されるような移動を行えばよい。外側に見えるプレゼンスは変更されない。（なぜなら、ＤＮＤはオフラインよりも高い優先度を有するからである。）しかしながら、ｔ＝８においてワイファイ・フォン１１６が接続を回復してオンラインに復帰すれば（例えば、ユーザＡ１０２がワイファイ対象領域に移動すると）、以前に保存したプレゼンス設定ＤＮＤが復元される。全てのインスタンスが同一のプレゼンス状態を有するので、外側に見えるプレゼンスはＤＮＤのままに残る。
【００８９】
ｔ＝９において、デスクトップＰＣ１０８でユーザＡ１０２によって手動的にＤＮＤから「オンライン」に変更される。この変更は手動であるから、全てのインスタンスへ報告される（Ｓ６１４）。ワイファイ・フォン１１６およびラップトップ１２６の両方は、この新しく手動的に設定されたプレゼンスに同期する（Ｓ７２２）。そして、リモート・ユーザに対して表示される、外側に見えるプレゼンス９０２は、全てのインスタンスがこの新しいプレゼンス設定を共有するので（Ｓ８０６）、「オンライン」に変更される。
【００９０】
したがって、上述した手法によって、ユーザが複数のデバイスからログインしている場合において単一の統一されたプレゼンス設定を提供するという課題が解決される。特に、プレゼンスの源（ソース）およびアベイラビリティ優先度の両者を考慮することにより、本手法は、リモート・ユーザに対して表示されるプレゼンスに、ユーザの意図した振るまい（behaviour）が可能な限り正確に反映されるようにする。
【００９１】
加えて、別の実施形態においては、Ｐ２Ｐシステムの他のユーザに対して表示されるプレゼンス状態が、ユーザが使用しているデバイスのタイプに関する情報を提供可能である。この機能について、図１０を参照して説明する。１００２は、標準的なプレゼンス・アイコンである。このアイコンは、図２におけるアイコン２０４および２１０と同じである。（図２を参照して説明したように、）類似のアイコンが他のプレゼンス状態について示されている。しかしながら、これらのアイコンは、使用されているデバイスのタイプについての示唆を一切与えない。この課題は、図１０に１００４として示されるようなアイコンを使用することで解決される。これはデバイス標識アイコン（デバイス・インジケータ・アイコン（device indicator icon））である。このアイコンを用いることで、プレゼンス状態において、ユーザが特定のタイプのデバイスを用いていることを示すことができる。図１０に示したデバイス標識アイコンは、移動デバイスについて「オンライン」プレゼンスを表すアイコンである。同様のアイコンを用いることで他のタイプのデバイスを示すことも可能であり、これらのデバイスについて異なるプレゼンス状態を示すことも可能である。
【００９２】
デバイス標識アイコンを利用可能である場合には、どのような場合にこれらのアイコンがＰ２Ｐシステムの他ユーザに対して表示されるべきかを決定するための決定過程が必要である。それについて以下に説明する。以下の例においては、デバイス標識は、図１０に示すような移動デバイスのユーザを示している。デバイス標識は、別の実施形態においては別のタイプのデバイスを示すことが可能である。
【００９３】
ユーザが単一の移動デバイス上でＰ２Ｐシステムにログインすれば、このタイプのデバイスにおけるユーザのプレゼンスを示すためにデバイス標識が使用される。例えば、ユーザＡ１０２がワイファイ・フォン１１６のみを用いてログインすれば、他ユーザに対して示されるプレゼンス状態は、１００４として示すような移動デバイス標識プレゼンス・アイコンを用いて表示される。同様、ユーザが複数のデバイスでログインし、全てのデバイスが、同一のデバイス標識をサポートしている移動デバイスであれば、プレゼンスはこれらのデバイス標識アイコンを用いて表示可能である。
【００９４】
しかしながら、ユーザが複数のデバイスを用いてログインし、少なくとも１つのデバイスが移動デバイスでなければ、デバイス標識プレゼンス・アイコンは必ずしも表示されるべきではない。デバイス標識プレゼンス・アイコンが表示されるか否かは、どのデバイスが、アベイラビリティ優先度テーブルにおいて最高位に格付けされたプレゼンスを供するかによる。例えば、ユーザＡが、デスクトップＰＣ１０８およびワイファイ・フォン１１６を用いてログインし、両デバイスが「オンライン」であれば、プレゼンスは、標準的な（モバイル用ではない）アイコン（図１０における１００２）で示される。しかしながら、非移動デバイス（すなわちデスクトップＰＣ１０８）のステータスが「退席中」または「利用不可」へ自動的に降下すれば、外側に見えるプレゼンスは（なお「オンライン」である）ワイファイ・フォンに由来することになる。なぜならこれがアベイラビリティ優先度において高位に格付けされているからである。外側に見えるプレゼンスが移動デバイス（ワイファイ・フォン１１６）に由来するので、プレゼンスは移動デバイス標識アイコン１００４を用いて表示される。
【００９５】
好適な実施形態を参照して本発明を具体的に示しまた説明した。しかし、当然の事ながら当業者であれば添付の特許請求の範囲に規定する本発明の範囲を逸脱することなく形態および細部において様々な変更をすることが可能である。
【符号の説明】
【００９６】
１０２  ・・・  ユーザＡ
１３２  ・・・  ユーザＢ
１０６  ・・・  ネットワーク
１０４  ・・・  ユーザＡのデバイス
３１６  ・・・  ソフトウェア・スタック
３１８  ・・・  クライアント・ユーザ・インタフェース層
３２０  ・・・  クライアント・エンジン層
３２２  ・・・  クライアント・プロトコル層
３２６  ・・・  プレゼンス・エンジン
３２４  ・・・  同期化マネージャ
７０２  ・・・  設定アベイラビリティ
７０４  ・・・  ビット
７０６  ・・・  タイムスタンプ
１００２  ・・・  標準プレゼンス・アイコン
１００４  ・・・  デバイス標識アイコン
【図１】
2010523035.tif 000003
【図２】
2010523035.tif 000004
【図３】
2010523035.tif 000005
【図４】
2010523035.tif 000006
【図５】
2010523035.tif 000007
【図６Ａ】
2010523035.tif 000008
【図６Ｂ】
2010523035.tif 000009
【図６Ｃ】
2010523035.tif 000010
【図７Ａ】
2010523035.tif 000011
【図７Ｂ】
2010523035.tif 000012
【図８】
2010523035.tif 000013
【図９】
2010523035.tif 000014
【図１０】
2010523035.tif 000015
【国際調査報告】
2010523035.tif 000016
2010523035.tif 000017