日時および通信手段の1以上の候補に関する情報を含んだ、第1のユーザーからのコミュニケーションの要求を受信する受信手段と、合意可能な日時および通信手段に関する情報を含んだ、第2のユーザーからの返信を生成する返信生成手段と、前記返信を第1のユーザーに向けて送信する送信手段と、を有するコミュニケーション支援装置。第1のユーザーおよび第2のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段と、前記要求に含まれる日時および通信手段に関する条件の範囲内であって、且つ、取得した存在状態から許容される日時および通信手段の組み合わせの指定のみを、少なくとも警告無く、第2のユーザーの入力として受け付ける入力手段と、をさらに有し、前記返信生成手段は、前記入力手段への入力に応じて、前記返信を生成する、請求項1記載のコミュニケーション支援装置。第1のユーザーおよび第2のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、前記返信生成手段は、取得した存在状態から、前記要求に含まれる日時および通信手段の候補に合意可能なものがないと判断した場合には、合意できない旨の返信を生成する、請求項1記載のコミュニケーション支援装置。第2のユーザーとコミュニケーションを行う日時および通信手段に関する、第1のユーザーによる指定を入力する入力手段と、前記入力に応じて、日時および通信手段の1以上の候補に関する情報を含んだ、第2のユーザーに対するコミュニケーションの要求を、第2のユーザーに向けて送信する送信手段と、前記要求に対する第2のユーザーからの第2のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信する受信手段と、前記返信に含まれた情報を第1のユーザーに通知する通知手段と、を有するコミュニケーション支援装置。第1のユーザーおよび第2のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、前記入力手段は、指定された日時に対して、取得した存在状態から許容される通信手段の指定のみを、少なくとも警告無く、通信手段として受け付ける、請求項4記載のコミュニケーション支援装置。日時および通信手段の1以上の候補に関する情報を含んだ、第1のユーザーからのコミュニケーションの要求を受信するステップと、合意可能な日時および通信手段に関する情報を含んだ、第2のユーザーからの返信を生成するステップと、前記返信を第1のユーザーに向けて送信するステップと、をコンピュータに実行させるコミュニケーション支援プログラム。第2のユーザーとコミュニケーションを行う日時および通信手段に関する、第1のユーザーによる指定を入力するステップと、前記入力に応じて、日時および通信手段の1以上の候補に関する情報を含んだ、第2のユーザーに対するコミュニケーションの要求を、第2のユーザーに向けて送信するステップと、前記要求に対する第2のユーザーからの第2のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信するステップと、前記返信に含まれた情報を第1のユーザーに通知するステップと、をコンピュータに実行させるコミュニケーション支援プログラム。ユーザー同士がコミュニケーションを行うに当たって、そのコミュニケーションを行う通信手段の調整を事前に行うことができなかった。本発明の第1の態様によれば、日時および通信手段の1以上の候補に関する情報を含んだ、第1のユーザーからのコミュニケーションの要求を受信する受信手段と、合意可能な日時および通信手段に関する情報を含んだ、第2のユーザーからの返信を生成する返信生成手段と、前記返信を第1のユーザーに向けて送信する送信手段と、を有するコミュニケーション支援装置が提供される。本発明の第2の態様によれば、前記第1の態様において、第1のユーザーおよび第2のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段と、前記要求に含まれる日時および通信手段に関する条件の範囲内であって、且つ、取得した存在状態から許容される日時および通信手段の組み合わせの指定のみを、少なくとも警告無く、第2のユーザーの入力として受け付ける入力手段と、をさらに有し、前記返信生成手段は、前記入力手段への入力に応じて、前記返信を生成するように構成してもよい。本発明の第3の態様によれば、前記第1の態様において、第1のユーザーおよび第2のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、前記返信生成手段は、取得した存在状態から、前記要求に含まれる日時および通信手段の候補に合意可能なものがないと判断した場合には、合意できない旨の返信を生成するように構成してもよい。本発明の第4の態様によれば、第2のユーザーとコミュニケーションを行う日時および通信手段に関する、第1のユーザーによる指定を入力する入力手段と、前記入力に応じて、日時および通信手段の1以上の候補に関する情報を含んだ、第2のユーザーに対するコミュニケーションの要求を、第2のユーザーに向けて送信する送信手段と、前記要求に対する第2のユーザーからの第2のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信する受信手段と、前記返信に含まれた情報を第1のユーザーに通知する通知手段と、を有するコミュニケーション支援装置が提供される。本発明の第5の態様によれば、前記第4の態様において、第1のユーザーおよび第2のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、前記入力手段は、指定された日時に対して、取得した存在状態から許容される通信手段の指定のみを、少なくとも警告無く、通信手段として受け付けるように構成されてもよい。本発明の第6の態様によれば、日時および通信手段の1以上の候補に関する情報を含んだ、第1のユーザーからのコミュニケーションの要求を受信するステップと、合意可能な日時および通信手段に関する情報を含んだ、第2のユーザーからの返信を生成するステップと、前記返信を第1のユーザーに向けて送信するステップと、をコンピュータに実行させるプログラムが提供される。本発明の第7の態様によれば、第2のユーザーとコミュニケーションを行う日時および通信手段に関する、第1のユーザーによる指定を入力するステップと、前記入力に応じて、日時および通信手段の1以上の候補に関する情報を含んだ、第2のユーザーに対するコミュニケーションの要求を、第2のユーザーに向けて送信するステップと、前記要求に対する第2のユーザーからの第2のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信するステップと、前記返信に含まれた情報を第1のユーザーに通知するステップと、をコンピュータに実行させるプログラムが提供される。第1、4、6および7の態様による発明によれば、ユーザー同士がコミュニケーションを行うに当たって、そのコミュニケーションを行う通信手段の調整を行うことができる。第2および5の態様による発明によれば、ユーザーの存在状態に合致する通信手段を容易に選択することができるようになる。第3の態様による発明によれば、コミュニケーションの要求に対して、自動的に応答することができる。以下に示す実施例では、2つの構造モデル、すなわち、ピングとナッジを用いている。ピングPingは、他の個人またはグループに対して、自分の存在状態在不在や活動状況などのその人物の現在の状態を示す情報を含む短いプッシュ型のメッセージである。ナッジNudgeは、いつどの通信手段を使ってコミュニケーション、すなわち双方向の意思や情報のやり取りを行うかを合意するための交渉用の構造体を提供する。本実施形態によるシステムは、各対象人物存在状態を決定するために監視の対象となる者の存在状態を監視した結果としての1以上のデータフィードを処理し、当該各対象人物の存在状態を、契約者本システムにおいて、存在状態の配信を受ける者のグループに通知する。一実施例において、契約者には、各対象人物の現在位置、コミュニケーションの可否、現在の仕事、好みの通信手段が通知される。なお、双方向のコミュニケーションを支援するという目的からは、契約者は、同時に対象人物でもあるのが好ましい。しかし、もちろん対象人物とならずに自分の存在状態を知らせずに、他者の監視のみを行う契約者がいてもよい。図1は、各対象人物の物理的な存在状態を特定するシステム100を示すブロック図である。システム100は、サーバー102、センサー統合部110、データソース統合部120、およびクライアントコンピュータシステム130を含む。サーバー102、センサー統合部110、データソース統合部120およびクライアントコンピュータ130は、ネットワーク150を介して相互に接続されている。ネットワーク150は、計算機ノードを相互接続可能な各種の有線および無線通信チャンネルである。これには、ローカルエリアネットワークLAN、ワイドエリアネットワークWANおよびこれらの組み合わせが含まれる。また、インターネットも含まれ得る。センサー統合部110は、センサーネットワーク111から受信したセンサーデータを統合または集積する。センサーネットワーク111の個々のセンサーは、センサー統合部110に対して、データフィードを送信する。ここで、データフィードとは、データの供給源からネットワーク上の宛先に向けて送信される一連のデータのことである。センサー統合部110は、そのデータフィードに含まれるデータを取りまとめ、場合によっては一時蓄積した上で、その統合したデータをサーバー102に送信する。この例においては、センサーネットワーク111は、無線センサー112、カメラ114およびキーカードセンサー116を含んでいる。無線センサー112は、予め定められた場所に設置される例えば、使用する無線センサーの通信可能範囲内において、建物の中または建物の外。無線センサー112は、その検知可能な範囲内にある無線デバイスであって、対象人物に対応付けられて登録された無線デバイスのデータを含んだデータフィード以下、無線データフィードとも言うを供給する。ここで、無線センサー112は、Bluetooth登録商標センサー、Wi-Fi登録商標センサー、携帯電話センサー、RFIDセンサー、RFセンサーおよび超音波センサーを含む各種の無線によって対象物を検知するセンサーが用いられ得る。カメラ114は、対象人物のオフィス内に設置される。この例においては、カメラは、少なくとも、そのオフィスに対象人物または訪問者が居るかどうかを判定するための情報を含むワークスペースのビデオデータフィードを供給する。この実施例においては、その対象人物がオフィスにおいて通常居るであろうワークスペースの領域の指定を予め行っておく。また、訪問者がそのオフィスに来た際に通常居ることになるであろうワークスペースの領域の指定も行う。例えば、図8は、対象者の典型的なワークスペースを示すカメラのデータフィードのフレーム802を表している。図8から分かるように、対象人物が自ら、または管理者が、オフィスを訪れた訪問者が通常占めるであろう空間的領域806に対応する領域境界804を定義する。また、その対象者がオフィスにおいて通常占めるスペースに当たる空間的領域810に対応する領域境界808を定義する。もちろん、1つの部屋で複数人が働いていることもあるし、キュービクルで分割されている場合もある。このような場合には、1台のカメラが複数人分のワークスペースを含んだビデオカメラのデータフィードを送信することになる。この場合、その1台のビデオカメラの映像中において、一人一人の対象人物のワークスペースおよび訪問者用のワークスペースを定義する必要がある。また、入館入室の鍵の役割を果たすカードであるキーカードを検知するキーカードセンサー116が、施錠されているドアのところに設置されている場合がある。このような場合には、それぞれのキーカードセンサー116は、登録された対象人物がそのキーカードを使用して入館入室した日時または退館退室した日時に関するデータを含むキーカードのデータフィードを供給する。もちろん、人の存在や活動を検知するために、他のセンサーを用いても良い。例えば、音のパターンから、対象人物の存否やその活動を検知するために、マイクを用いることもできる。同様に、電灯の点灯の有無により対象人物の存否を判断すべく、光センサーを用いることもできる。さらには、これらセンサーの組み合わせによって、その場所に何人の人物が存在するのかを検知することもできる例えば、ビデオカメラのデータフィードと、マイクのデータフィードとを用いて、その物理空間に何人存在するかを検知することができる。そして、この実施例では、独立したセンサー統合部が、複数の種類のセンサー例:無線センサー112、カメラ114、キーカードセンサー116からのデータを統合する。データソース統合部120は、外部のデータソース121から受信したデータを統合する。データソース121のそれぞれは、データソース統合部120に対してデータフィードを供給する。そのデータフィードを受信したデータソース統合部は、それらのデータを統合し、場合によっては一時蓄積した上で、その統合したデータのデータフィードをサーバー102に対して送信する。データソース121は、カレンダー122、ソーシャルネットワークシステム124、インスタントメッセンジャーシステム126、ネットワーク活動を監視した結果としてのデータを供給するデータソース128、および携帯デバイス129を含む。ここで、データソースは、後の分析に用いるデータを供給する供給源の意味で用いている。カレンダー122は、ユーザー対象人物または契約者のスケジュールを管理記憶しているものであり、そのユーザーの予定に関するデータフィードを供給する。個々のユーザーが複数のカレンダーを用いていることもあるが、その場合には、それらの全部のデータを供給してもよいし、そのサブセットを供給してもよい。カレンダーとしては、個人のカレンダー、グループのカレンダー、イベントのカレンダーおよび業務カレンダー等が利用可能である。ソーシャルネットワーク124およびインスタントメッセンジャーシステム126は、通常、対象人物の状態に関する更新された情報を取得することができる。ソーシャルネットワークシステム126およびインスタントメッセンジャーシステム126の一方または両者は、対象人物本人によって更新された、その対象人物に関する最新の状態に関するデータフィードを供給する。ネットワーク活動データソース128は、対象人物と関連付けられたデバイスネットワーク接続されたものに限るのネットワーク活動を監視する。ここで、監視するネットワークとしては、オフィスのコンピュータネットワーク、オフィスの電話のネットワーク、公共のコンピュータネットワーク、および家庭内のコンピュータネットワーク等が考えられる。ネットワークアドレスを分析することにより、ネットワーク接続されたデバイスの位置を特定することができる。例えば、IPアドレスを分析することによって、そのIPアドレスと関連付けられた地理的な位置をそのデバイスの位置として特定することができる。ネットワーク接続されたデバイスを特定の場所例:特定の建物内における存否を決定する。具体的には、ネットワーク活動データソース128は、対象人物のオフィスコンピュータが、例えば以下のどの状態であるかを示す。すなわち、オフラインネットワーク接続されていないの状態、オンラインであって会社のLANに接続されている状態、または、オンラインであって会社のVPNに接続されている状態のいずれであるか、また、そのコンピュータが使用されているか否か、さらには、オフィスの電話が使用されているか否かという状態などである。この実施例では、デバイスの識別子MACアドレス等とネットワークアドレスIPアドレス等を分析に用い、建物内におけるデバイスの位置を特定する。例えば、ネットワークデバイスの登録情報のデータベースを、ネットワークアドレスを用いて検索することで、そのデバイスの位置を特定する。多くの携帯端末は、測位システムGPSや基地局による測位システムを備えているので、これを用いて自デバイスの位置を特定し、特定した位置情報をサーバー102に送信することができる。すなわち、携帯端末データソース129は、対象人物の携帯端末によって特定されたその位置情報のデータフィードを供給する。もちろん、他のデータソースを用いることも可能である。例えば、特定の対象人物に関する告知のRSSフィードを、その対象人物の状態を特定するのに用いることができる。同時に、これらの組み合わせが、対象人物の存在状態を特定するのに用いられる。例えば、特定の時間および場所での会議に関するRSSフィードと、外部カレンダーから取得した対象人物の存在予定場所やイベントデータとを組み合わせて、その対象人物の存在状態を特定することができる。この実施例においては、独立したデータソース統合部が、前述した各種データソースからのデータを統合する。サーバー102は、統合および要約エンジン104と、状態データベース106とを有している。ここで、統合および要約エンジン104は、センサー統合部110およびデータソース統合部120からデータフィードを受信し、これらに基づいて対象人物の存在状態を決定する。統合および要約エンジン104は、例えば、最新の状態メッセージや建物内における現在の位置等の、取得した状態に関連するデータを要約する。この例においては、統合および要約エンジン104は、階層型ルールベースの構造を用いて、対象人物の存在状態を決定する。例えば、データフィードの階層の序列考慮すべき優先順位は以下のように決定される。1カメラのデータフィード、2無線のデータフィード、3キーカードのデータフィード、4対象人物が更新した状態情報のデータフィード、5カレンダーのデータフィードという序列である。もちろん、他の順番も採用し得る。統合および要約エンジン104は、機械学習の手法サポートベクターマシンやベイジアンネットワークを用いて統計的に対象人物の存在状態を決定する。対象人物の存在状態に関して最も高い特異性specificityを有するデータフィードを供給する。この特異性のレベルは、例えば、階層型ルールベースの構造を有するデータフィードにおける階層と同様にして決定される。統合および要約エンジン104は、2つ以上のデータフィードを組み合わせ、個々の対象人物の存在状態に関し、より高い特異性を作り出す。状態データベース106は、センサーネットワーク111から例えばセンサー統合部110を介して集めた情報、および外部のデータソース121から例えばデータソース統合部120を介して集めた情報を、それらの情報を取得した日時の情報と共に蓄積する。また、このデータベースは、対象人物の過去における存在状態のログを、それらの存在状態が決定された日時と共に蓄積する。状態データベース106はまた、ユーザーの使用履歴や、ユーザーの嗜好による設定情報を蓄積する。設定情報として、例えば、クライアントコンピュータシステム130のアプリケーション132に対して、他のコミュニケーションツールと連携することを許容する旨の情報を蓄積することが挙げられる。クライアントコンピュータ130は、対象人物の存在状態へのアクセスを提供するアプリケーションプログラムであるアプリケーション132を含んでいる。アプリケーション132は、デバイスクライアントコンピュータ130や携帯端末等がどのようにしてネットワークに接続されているか、対象人物が現在マウスやキーボードを操作しているか等の詳細情報を通知する。この情報は、統合および要約エンジン104によって処理され、デバイスを使用しているという対象人物の存在状態が特定される。現在アクティブになっているアプリケーションプログラムは何か等の他の情報も同様に供給される。アプリケーション132は、組織に属する対象人物に関係するデータおよびその存在状態に関する、要約および詳細な視覚化情報の両者を供給してもよい。例えば、図6は、組織会社、職場、家庭等に属する対象人物の存在状態を通知するアプリケーション132のユーザーインターフェースUI602を示したブロック図600である。UI602は、組織に属する対象人物を表したタイル603の集合を表示する。個々のタイル603は、組織に属する対象人物の写真と名前を含む。また、タイルはその対象人物の存在状態を伝えるべく色分けされ、またその存在状態に対応したアイコンがそのタイルの上に表示される。例えば、タイル603-1は、そのタイルに関連付けられた対象人物に、何らかのイベント会議、来客、休暇、セミナー出席等が予定されていることを示すカレンダーオブジェクト604を含んでいる。同様に、タイル603-7は、その対象人物のオフィスに訪問者がいることを示す訪問者オブジェクト605を含んでいる。さらに、グレイアウトされたタイルによって、対応する対象人物がオフィスに居ないこと、または、存在状態が特定できないことのいずれかを示してもよい。いずれかのタイルがクリックされるまたはポイントされると、そのタイルに対応付けられた対象人物の存在状態に関するより詳細な状態情報を表示する。例えば、タイル603-6がクリックされた場合、そのタイルに関連付けられた対象人物に関する状態ウィンドウ620を生成する。状態ウィンドウ620には、その対象人物の写真621、名前622、存在状態623、対象人物による更新メッセージ624およびその更新が行われた日時625、電話番号626、電子メールアドレス627、ならびに、その対象人物のデバイスを検出しているセンサー628およびそのセンサーの位置629を表示する。状態ウィンドウ620は、また、クリック可能なアイコン630乃至633を含んでいる。これらのアイコンは、それぞれが異なる通信手段インスタントメッセンジャーや、ビデオ会議等に対応しており、いずれかのアイコンをクリックすることによって、対応する通信手段が起動し、その対象人物とコミュニケーションをとることが可能となる。UI602は、また、タイル603が新しい情報によって最後に更新された日時に関する情報606を含んでいる。MyPalsツール607を起動すると、対象人物の組織への追加、削除およびグループ化を行うUI画面が表示され、対象人物の指示に基づいてこれらの機能を実行する。UI602は、また、組織に属する各対象人物によって入力された現在の状態に関するメッセージおよびその入力日時を含んだデータフィード609を表示する。また、UI602とサードパーティーのコミュニケーションツールを連携させて、特定の対象人物の認識情報を収集する段階から、その対象人物とのコンピュータを利用したコミュニケーションの段階へと移行することが可能である。図2は、サーバー102を表すブロック図である。サーバー102は、1つ以上の処理装置CPU202、1つ以上のネットワークまたは他の通信インターフェース204、メモリー210、およびこれらのコンポーネントと通信するための1つ以上の通信バス209を有する。通信バス209には、システムコンポーネント間を接続し、その間の通信を制御する回路チップセットとも呼ばれるを含む。サーバー102は、ディスプレイ装置206および入力装置208キーボード、マウス、タッチスクリーン、キーパッド等を含むユーザーインターフェース205を備えても良い。メモリー210は、DRAM、SRAM、DDRRAMといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー210は、また、CPU202の遠隔地にある記憶装置であっても良い。メモリー210は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。1オペレーティングシステム212:基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。2通信モジュール214:通信インターフェース204を介して、サーバー102を他のコンピュータに接続する。3ユーザーインターフェースモジュール216:入力装置208を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置206上に生成する。4データベースモジュール218:サーバー102内のデータベースとのインターフェースとなる。5状態データベース106:対象人物の存在状態220、センサー統合部からのデータ222、データソース統合部からのデータ224、ユーザー設定226、対象人物に関連付けて登録されたデータソース228、対象人物に関連付けて登録されたデバイス230、カメラ領域232、およびユーザーの使用履歴234を保持する。メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、1つまたは複数のCPU202によって実行される。これらのモジュールやプログラムすなわち命令列は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図2に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。図3は、センサー統合部110を表すブロック図である。センサー統合部110は、1つ以上の処理装置CPU302、1つ以上のネットワークまたは他の通信インターフェース304、メモリー310、およびこれらのコンポーネントと通信するための1つ以上の通信バス309を有する。通信バス309には、システムコンポーネント間を接続し、その間の通信を制御する回路チップセットとも呼ばれるを含む。センサー統合部110は、ディスプレイ装置306および入力装置308キーボード、マウス、タッチスクリーン、キーパッド等を含むユーザーインターフェース305を備えても良い。メモリー310は、DRAM、SRAM、DDRRAMといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー310は、また、CPU302の遠隔地にある記憶装置であっても良い。メモリー310は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。1オペレーティングシステム312:基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。2通信モジュール314:通信インターフェース304を介して、センサー統合部110を他のコンピュータに接続する。3ユーザーインターフェースモジュール316:入力装置308を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置306上に生成する。4生のセンサーデータ318:センサーネットワーク111内のセンサーから受信したデータであり、無線センサーデータ320、カメラデータ322、キーカードセンサー324を含む。5統合エンジン326:生のセンサーデータ318を統合し、サーバー102に対してこの統合したセンサーデータを送信する。統合エンジン326は、また、対象人物と関連付けて登録されたデバイスに関するデータ328、センサーの位置情報330、カメラ領域332を含む。メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、1つまたは複数のCPU302によって実行される。これらのモジュールやプログラムすなわち命令列は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図3に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。図4は、データソース統合部120を表すブロック図である。データソース統合部120は、1つ以上の処理装置CPU402、1つ以上のネットワークまたは他の通信インターフェース404、メモリー410、およびこれらのコンポーネントと通信するための1つ以上の通信バス409を有する。通信バス409には、システムコンポーネント間を接続し、その間の通信を制御する回路チップセットとも呼ばれるを含む。データソース統合部120は、ディスプレイ装置406および入力装置408キーボード、マウス、タッチスクリーン、キーパッド等を含むユーザーインターフェース405を備えても良い。メモリー410は、DRAM、SRAM、DDRRAMといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー410は、また、CPU402の遠隔地にある記憶装置であっても良い。メモリー410は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。1オペレーティングシステム412:基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。2通信モジュール414:通信インターフェース404を介して、データソース統合部120を他のコンピュータに接続する。3ユーザーインターフェースモジュール416:入力装置408を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置406上に生成する。4生データ418:データソース121から受信したデータであり、このデータは、カレンダーデータ420、ソーシャルネットワークシステムデータ422、インスタントメッセンジャーデータ424、およびネットワーク活動データ426を含む。5統合エンジン428:生データ418を統合し、サーバー102に対してこの統合したデータを送信する。統合エンジン428は、また、対象人物と関連付けて登録されたデータソース430の情報を含む。メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、1つまたは複数のCPU402によって実行される。これらのモジュールやプログラムすなわち命令列は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図4に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。図5は、クライアントコンピュータシステム130を表すブロック図である。クライアントコンピュータシステム130は、1つ以上の処理装置CPU502、1つ以上のネットワークまたは他の通信インターフェース504、メモリー510、およびこれらのコンポーネントと通信するための1つ以上の通信バス509を有する。通信バス509には、システムコンポーネント間を接続し、その間の通信を制御する回路チップセットとも呼ばれるを含む。クライアントコンピュータシステム130は、ディスプレイ装置506および入力装置508キーボード、マウス、タッチスクリーン、キーパッド等を含むユーザーインターフェース505を備えても良い。メモリー510は、DRAM、SRAM、DDRRAMといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー510は、また、CPU502の遠隔地にある記憶装置であっても良い。メモリー510は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。1オペレーティングシステム512:基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。2通信モジュール514:通信インターフェース504を介して、クライアントコンピュータシステム130を他のコンピュータに接続する。3ユーザーインターフェースモジュール516:入力装置508を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置506上に生成する。メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、1つまたは複数のCPU502によって実行される。これらのモジュールやプログラムすなわち命令列は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図5に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。[存在状態の特定]図9は、対象人物の存在状態を特定する方法900を示すフローチャートである。統合および要約エンジン104が、対象人物の存在状態を示す各種データを含む複数のデータフィードを受信するステップ902。この複数のデータフィードは、センサー統合部110およびデータソース統合部120のいずれか、または両者から送信されたものである。統合および要約エンジン104は、対象人物の存在状態を特定するべく、複数のデータフィードに含まれるデータを処理する。なお、複数のデータフィードは、センサーネットワーク111内のセンサーから、または外部のデータソース121から、集積部を経ずに直接受信してもよい。この場合、統合および要約エンジン104は、受信した生データを、対象人物の存在状態を特定するために用いることになる。また、対象人物が自分の存在状態として監視することを許容したものに対応する状態情報だけが、データフィードとして送信されてくる。次に、統合および要約エンジン104が、対象人物の存在状態に対応するデータを含む複数のデーフィードのサブセットを特定するステップ904。その後、統合および要約エンジン104が、このサブセットを分析し、その対象人物の存在状態を決定する。センサー統合部110は、カメラ114からのビデオデータを解析し、対象人物がそのオフィスにいるか否か、または、訪問者がそのオフィスにいるか否かを決定する。この決定を行うには、例えば、オフィス内において対象人物が通常居る位置として予め設定した領域に、何らかの動きを検出したか否かを判断する。その領域内において動きがある場合には、対象人物がオフィスに居ると判断するのである。また、何の動きも無い場合には、対象人物がオフィスに居ないと判断する。また、訪問者の有無も同様に判断することができる。すなわち、通常訪問者が占めるであろう位置として予め設定された領域内に何らかの動きを検出した場合には、そのオフィスに訪問者が居ると判断し、検出できなかった場合には、居ないと判断するのである。センサー統合部110は、対象人物または訪問者がオフィスにいるか否かというデータを含むデータを、必要に応じて複数取りまとめて、統合および要約エンジン104に対して送信する。また、センサー統合部110は、無線センサーからのデータを分析して、そのセンサーの検知可能な範囲において対象人物に関連付けられて登録されている無線デバイスが検出されたか否か、すなわちその範囲に対象人物が居るか否かという、存在状態を決定する。また、センサー統合部110は、キーカードセンサーからのデータを分析して、対象人物に関連付けられて登録されているキーカードがそのセンサーの場所で使用されたか否か、すなわち、そのキーカードセンサーがある場所に対象人物が居るか否かという存在状態を決定する。データソース統合部120は、カレンダーデータを分析して、対象人物に何らかの予定があるか否かという存在状態を決定する。また、データソース統合部120は、対象人物によって更新された状態データを分析して、その状態データに対応する状態にあるという存在状態を決定する。データソース統合部120は、ネットワーク活動を監視したデータを分析して、対象人物に関連付けられて登録されたネットワークデバイスがそのネットワーク上において使用されているか否か、すなわち対象人物がそのデバイスを使用しているか否かという存在状態を決定する。また、当該データを分析し、ネットワークアドレス等のデバイスの接続位置と対応付けられる情報から、当該デバイスがどこで使用されているかオフィスの建物内、自宅、公共の場所等という存在状態も決定する。図9に戻るが、統合および要約エンジン104は、決定した1以上の存在状態を、ネットワークを通じて契約者に通知する。ある対象人物の存在状態に関する2つのデータフィードを考慮する場合を例に挙げて説明する。第1のデータフィードが、その対象人物はコンピュータを使用中であるという存在状態を含んでおり、第2のデータフィードが、その対象人物は会社のネットワークにリモート会社のLANの外側から接続しているという存在状態を含んでいるとする。この場合、統合および要約エンジン104は、これら2つの情報を統合して、その対象人物に関し、より高いレベルの特異性を有する1つの存在状態、すなわち、社外から会社のLANに接続して、コンピュータを使用しているという存在状態を通知することになる。統合および要約エンジン104が存在状態を通知する方法については、管理者がこれを設定する。例えば、管理者は、組み合わせられるべきデータフィードを指定する。また、これら組み合わせられる複数の存在状態のうち、1つの存在状態が他の存在状態を包含するなどして、その1つのみが通知されるべきである場合には、その優先順位を指定する。もちろん、エンドユーザーに通知法を設定することを許容するようにしても良い。統合および要約エンジン104は、また、存在状態として、より特異性のレベルの高い、すなわち、そのユーザーの状態をより具体的または詳細に特定するであろう存在状態を1つ以上選択する。すなわち、複数の存在状態を通知する場合には、その存在状態は全て最大の特異性のレベルを有する例えば、最も詳細な情報ものである。この特異性のレベルの優先順位は、管理者またはユーザーが設定可能である。また、契約者が組織会社、職場、家庭等のメンバーであってもよい。現在の存在状態および過去の存在状態のグループの中から、通知すべき存在状態を選択してもよい。現在の存在状態が通知する場合、統合および要約エンジン104は、複数のデータフィードの中からリアルタイムのデータを取り出して処理をする。一方で、過去の存在状態を通知する場合には、過去に決定して状態データベースに格納されている存在状態を取り出して用いる。また、最も特異性のレベルの高い1つの存在状態だけを通知するようにしてもよい。対象人物の存在状態が予め定めてあるレベルの特異性に達しない場合には、統合および要約エンジン104は、そのレベルに達した中で最新の存在状態と、その状態であると決定した日時とを通知するようにしても良い。対象人物の存在状態の一覧を、クライアントコンピュータシステム上のアプリケーション132のユーザーインターフェース602として表示する。存在状態は、対象人物の位置およびその活動を含んでいてもよい。位置は、その対象人物の物理的な存在位置を意味し、活動は、その対象人物が何を行っているか例えば、会議中、特定のプロジェクトの仕事中、食事で外出中等を示すものである。統合および要約エンジン104は、複数のデータフィードに基づいて、対象人物の活動を決定しステップ910、その活動を契約者に通知するステップ912。統合および要約エンジン104は、カレンダー122から取得した対象人物の予定情報に基づいて、対象人物であり契約者でもある者がアプリケーション132を用いて更新した本人の状態情報に基づいて、または対象人物がインスタントメッセンジャーシステムやソーシャルネットワークシステムを使って自ら更新した状態情報に基づいて、その対象人物の活動を決定してもよい。これらの存在状態の決定は、ルールベースのアルゴリズムや、統計的確率的モデルアルゴリズムを用いて行うことができる。ところで、ここで説明しているシステムは、対象人物を追跡することが目的ではなく、対象人物の都合を確認できるようにするものである。したがって、対象人物本人に監視対象となる存在状態に関する情報を選択させるのが好ましい。図10は、存在状態を監視するためのデータ送信統合部を設定する方法1000のフローチャートである。サーバー102は、監視を許可する存在状態のデータを特定してその登録を依頼する、対象人物本人からのリクエストを受信するステップ1002。サーバー102は、また、管理者からのリクエストを受信するようにしてもよい。対象人物または管理者からのリクエストには、対象人物を監視しデータフィードを送信するセンサーカメラ114等の識別子が含まれる。サーバー102は、受信したリクエストに応じて、そのデバイスセンサーの識別子とそのリクエストに関わる対象人物とを関連付けて、メモリ上の登録デバイス230の領域に記憶する。また、対象人物または管理者からのリクエストには、対象人物を監視しデータフィードを送信するデータソースカレンダー122等の識別子が含まれる。サーバー102は、受信したリクエストに応じて、そのデータソースの識別子とそのリクエストに関わる対象人物とを関連付けて、メモリ上の登録データソース228の領域に記憶する。サーバー102は、続いて、データ送信統合部を、対応する存在状態の監視を行うように設定するステップ1004。例えば、サーバー102は、そのメモリー内の登録デバイス230にある情報を、センサー統合部110に対して転送し、そのメモリー内の登録デバイス328に記憶させるようにする。同様に、サーバー102は、登録データソース228の情報をデータソース統合部120に転送して、登録データソース430に記憶させるようにする。図7は、監視対象の存在状態を特定しその監視を許可する操作を行う、アプリケーション132のユーザーインターフェース702を示すブロック図である。ユーザーインターフェース702は、対象人物の写真704、その名前706、その存在状態708、および、状態メッセージ710を含む。ここで、存在状態708は、統合および要約エンジン104によって決定され、状態メッセージ710は、UI602を用いて入力され、または、UI702のUpdateStatus状態更新リンク712を用いて入力される。ユーザーインターフェース702は、ユーザー対象人物本人または管理者に対して、チェックボックス716チェックされた場合、制限無しに許可および718チェックされた場合、特定のデバイスに対してのみ許可へのチェックの有無によって、対象人物の監視対応するデータ送信を行うサービス714を有効化または無効化することを選択させる。ユーザーインターフェース702は、また、サービスによって収集された現在の情報を、CurrentInformationBeingCollected現在情報収集欄720に表示する。settings設定リンク722が選択されると、オフィスにおいて対称人物や訪問者が通常占める領域を定義するツール図8を起動する。これは前述のとおり、対象人物本人か管理者が行う。図9および図10のフローチャートに記載した処理は、コンピュータによって読み取り可能な記憶媒体に記憶された命令を、コンピュータが解釈して実行する。[ナッジNudgeおよびピングPing]図13は、ピングPingとナッジNudgeを使ってコミュニケーションイベントを調整するシステムのブロック図である。システム1300は、外部クラウドのプッシュ型メッセージサービス1302、中央サーバー1306および1以上のクライアント1308それぞれ1308-1、1308-2等を含む。クライアント1308は、ピングまたはナッジを実行できるようになっている任意のクライアント装置である。また、上述したアプリケーション132の機能の一部を備えていても良い。例えば、クライアント1308は、ノート型もしくはデスクトップ型のコンピュータ、スマートフォン、または同様の計算機である。クライアント1308は、また、通知マネージャー1310、エンドユーザー向けユーザーインターフェースモジュール1312、および携帯端末状態通知統合部1314これは、スマートフォン等の携帯端末において用いられるを備える。図13に示すように、クライアント1308は、クライアント同士で、また、他のシステムコンポーネントと、プッシュ型の通信を行う。この際には、外部クラウドのプッシュ型メッセージサービス1302を介するが、このサービス1302としては、クライアントから送信されたメッセージを転送する一般的なメッセージサービスを用いることができる。また、サービス1302は、プル型で通信を行うこともできるが、この際には、中央サーバー1306を介する。さらには、このクライアント1308は、サーバー1306と、システムおよびクライアント操作に関してメッセージをやり取りするように構成されている。例えば、クライアント1308は、コミュニケーションを行う媒体に関する設定について、サーバー1306とやり取り可能である。[エンドユーザーUIモジュール1312]エンドユーザーUIモジュール1312は、ピングおよびナッジ処理に関するユーザーインターフェースを生成しこれを表示するとともに、表示されたユーザーインターフェースとユーザーの相互作用を可能とする。このユーザー相互作用は、例えば、キーボード、マウス等のポインティングデバイス、または接触感知式のインターフェースによってなされる。[ピング]ピングPingは、1人のユーザーから、1人以上の他のユーザーに向けて送信される、構造化された通知である。本実施例の場合、ピングは、対象人物の存在情報、例えば、位置情報、活動状況または連絡可能情報そのユーザーが現在コミュニケーションを取ることが可能か否かを示す情報を、契約者に送信するために用いられる。ピングはまた、クライアント1308のユーザーである、送信者存在状態の通知の場合には、対象人物と受信者存在状態の通知の場合には、契約者とに関連付けられている。[ピング送信者]ピングの送信者に対しては、1予め定められたピングを送信する理由の一覧からいずれかを選択し、2緊急度を指定し、3自由形式のテキスト入力を可能とする、単純なインターフェースが提供される。[ピング受信者]ピングの受信者に対しては、通知生成時において送信者が入力選択した内容を表示する。送信者の現在の存在状態の詳細が表示されるようにしても良い。[ナッジ]ナッジNudgeは、複数のユーザー間で日時と通信手段を交渉するためにやり取りされる、一連の構造化された通知である。ナッジは、ピングと異なり、その受信者に返信を求めることを前提としており、また、ナッジとは別のコミュニケーションすなわち、合意した日時および通信手段によるコミュニケーションが引き続き発生することを前提としている。ピングと同様に、ナッジも、送信者および受信者と関連付けられている。このナッジの送信者と受信者に対する機能としては、後述するように、基本機能とオプション機能とがある。[ナッジ送信者基本]ナッジの送信者に対しては、コミュニケーションを行うに当たって、そのコミュニケーションの態様に関する要望を指定するためのインターフェースが、基本機能として提供される。この態様に関する要望としては、例えば、1送信者にとって最も好ましい通信手段および許容可能な通信手段、2コミュニケーションの優先度至急、いつでも可等、3コミュニケーションを行う期限が挙げられる。ここで、通信手段としては、電話携帯電話、固定電話、VOIPソフトウェアを含む、電子メール、ショートメッセージサービスSMS、インスタントメッセンジャーIM、ビデオチャットが挙げられる。[ナッジ受信者基本]ナッジの受信者に対しては、その生成時に送信者が指定した内容から生成された、構造化された通知を表示する。送信者の存在状態を表示しても良い。ナッジの受信者の対応としては、1その送信者と直ちにコミュニケーションを開始する、2返信する、3無視するという選択肢がある。受信者が返信することを選択した場合、その返信には、受信者の許容可能な通信手段に関する情報、および、その通信手段でいつコミュニケーション可能であるかに関する情報が含まれる。受信者が許容可能な通信手段、またはコミュニケーション可能な日時を選択する際には、送信者が指定してきたものを一覧表示し、この中から選択させるようにするのが好ましい。[ナッジ送信者オプション]ナッジ受信者からの返信があった場合、送信者に対して、その返信の内容を表示するとともに、その返信において指定されている選択肢通信手段や日時の中からいずれかを選択させるようにする。ナッジ送信者は、自分の選択した内容に関して、リマインダー指定日時の直前に発せられる確認のための通知を受け取るように設定することができる。[ナッジ受信者オプション]ナッジ受信者が指定した選択肢の中からナッジ送信者が選んだコミュニケーションの態様を、ナッジ受信者に対して通知し、必要に応じてリマインダーの設定を行う。[コミュニケーションリマインダーアラートカレンダーイベント]コミュニケーションに関するリマインダーやアラートは、ユーザーが設定するようにしてもよいし、ナッジやピングの送信時に自動的に設定するようにしてもよい。アラートは、ユーザー典型的には契約者に対して何らかの注意を喚起する通知であり、画面表示、音声、電子メール等でその注意すべき内容を知らせる。その通知の方法は、ユーザーに対して注意を喚起するものであれば良いが、そのアラートを受け取るユーザーに指定させるのが好ましい。また、アラートは、その注意喚起の発生条件を定める必要があるが、予め定められた日時をその条件とするのが最も単純な方法である。より複雑な場合として、存在状態と時間との組み合わせでこの条件を設定しても良い。例えば、通知方法:ジェーンに電話せよと表示する。発生条件:ジェーンの存在状態が会議中でなくなった後であって、且つ午後2時以降。アラートが発生すると、そのアラートの内容とともに、その通知の対象となっている人物典型的には対象人物の存在状態が画面に表示される。また、ピングやナッジを用いて、合意したコミュニケーションの態様を、その両者のカレンダーに登録するようにしてもよい。これらのリマインダーやアラートは、エンドユーザーUIモジュール1312の制御の下、クライアント1308の画面に表示される。[予約設定]ルールベースの方法または明示的な方法で、コミュニケーションの態様をユーザーが指定することができる。例えば、ユーザーが会議に行く際に、前もって通信手段を以下のように設定する。会議中は、IMまたは電子メールでの連絡が可能や会議中は、ナッジによるコミュニケーションのみ可能や2時以降に電話連絡可能がその例である。ナッジへの返信を、ユーザーの存在状態に応じて自動的に作成してもよい。例えば、カレンダーの情報に基づいて、会議の予定時刻であると判断し、且つカメラの情報に基づいてオフィスに対象人物が居ないと判断した場合に、現在会議中である旨の返信を行うことが考えられる。また、ユーザー自身による存在状態の入力内容に基づいて、これを行うこともできる。また、ユーザーが予め設定した規則を用いて返信を自動生成することもできる。例えば、会議中の場合には、IMと電子メールのみ連絡可能である旨の返信すると決めておいた場合には、そのユーザーの存在状態が会議中であると判断したときに、その旨のメッセージを自動的に返信するのである。また、その予め設定した規則日時や通信手段に合致しない条件を候補とするコミュニケーション交渉のためのナッジを受信した場合には、自動的に合意不能の旨のメッセージを送信するようにしてもよい。また、送信者の区分に基づいて、その規則を設定するようにしてもよい。たとえば、同僚からのリクエストと友人からのリクエストとを異なるように処理するのである。また、特定の区分のユーザーからのリクエストを拒絶するような規則を設定するようにしてもよい。例えば、重要な会議中は友人からのリクエストを拒絶するようにすることが考えられる。なお、これらの規則や設定は、ユーザー設定として中央サーバー1306に記憶される。[音声ボイスメールインターフェース]本システムのユーザーと連絡を取ろうとする、ユーザー外の人に対しては、電話による音声メニューによって、ピングやナッジで通知する場合と同様のコミュニケーション態様を選択できるようにすることができる。または、ナッジやピングの送信を可能とするウェブインターフェースへのリンクを提供するようにしてもよい。[ウェブインターフェース]ウェブWWWフォーマットでナッジやピングの機能を提供するようにしてもよい。このウェブベースのインターフェースを用いて、ユーザーが、ナッジおよびピングを実行する。他の方法による連絡を試みた人に対して、このウェブインターフェースへのリンクを示すようにすると良い。[スマートフォンへの入電]ユーザー契約者が別のユーザー対象人物から電話を受けた場合に、その発呼者の存在状態が、通話切断ボタンと同じ画面に表示されるようにする。また、その入電に対する応答として、ナッジを要求する旨の選択肢を追加、すなわちナッジ要求ボタンを画面に追加し、ユーザーの選択に応じてナッジを要求する旨のメッセージを発呼者に送信する。また、前述のように予め定めた規則に従って、自動的にナッジ要求のメッセージを送信するようにしても良い。[スマートフォンからの発信]電話を掛ける場合、その相手方の存在状態が画面に表示されるようにする。これは、複数人の状態が一覧表示されていても良いし、相手を選んだ後にその存在状態が表示されるようにしても良い。また、その電話が繋がらなかった場合に、画面に表示されているナッジボタンまたはピングボタンの選択を受けて、ナッジまたはピングを送るようにしても良い。[通知マネージャー1310]登録されたエンドユーザーのデバイスは、サーバーから通知を受信する。その登録デバイスの装置の少なくとも一部に、通知が送信される。その通知を受信したデバイスは、予め設定された態様でアラートを発生させてユーザーにその内容を知らせる。アラートの通知方法としては、音声、触覚、視覚のいずれかによることが可能である。その通知は、後で詳細に説明するが、やり取りされた通知の構造に依存させることができる。例えば、待っていますは話せますよりも緊急度が高い。この構造は、上述のような状況に応じた設定を用いて自動的に設定するようにしてもよいし、または、ピングやナッジで明示的に指定された優先度を用いても良い。音声触覚による通知は不要といった明示的な規則の表現でもよいし、会議の終了後まで待てますといったより適用範囲の広い文脈上の表現でもよい。受信者と送信者は共に、これらの通知をどのように扱うかを指定することができる。例えば、受信者は、会議中に期限が到来するものでない限り、会議中の通知は不要と指定することができる。[携帯端末状態通知統合部1314]このモジュールは、ユーザーの携帯端末と関係する存在状態を通知する。この存在情報には、通話状態通話中、呼び出し中等や、その携帯端末の位置情報を含む。この情報は、具体的なGPS座標でもよいし、構造的な意味論的解釈で予め設定した場所の名前例えば、職場、自宅等でもよい。また、ユーザーは、特定の位置や日時についてのみ、その存在状態を通知するように設定することができる。たとえば、会社の敷地内に居る場合のみ、位置情報を送信する等である。[中央サーバー1306]これは、一連の構造化された双方向の通知ピングとナッジを仲介するネットワークアプリケーションサーバーである。コミュニケーションは、エンドユーザーのデバイス携帯端末、ノートPC、デスクトップPC等から送信される。通知は、各ユーザーおよび各デバイスに対してプッシュ型で、ユーザーの個人設定に基づいて配信される。一つのデバイスで配信された通知が消去されると、重複した送信を防ぐように、サーバーは、そのユーザーの他のデバイスに向けて、そのメッセージが削除された旨を知らせる。[ナッジおよびピングのダイアログ]上述のように、図13は、各コンポーネント同士がどのようにやり取りを行うかを抽象的に表現した図である。図14および15は、エンドユーザーがクライアント1308から本システムを利用する際に表示されると共に、その操作に用いられる、ユーザーダイアログプログラムのユーザーインターフェースの概要を示している。図14は、ピングに関連したシステム操作の流れを示す、時系列の画面表示の例である。図15は、ナッジの場合の例である。図14を参照すると、第1のユーザーJohnDoeが、そのユーザーに関連付けられたクライアント1308-1のディスプレイに表示され、構造化されたユーザーダイアログ1404を用いて、第2のユーザーJaneDoeに対してピング1402を送信する。ダイアログ1404は、第1のユーザーJohnDoeが、自分の状態を示す情報として遅れますを選択し、5分後に到着予定という付加的なメッセージを入力した結果としてのピングを表している。第1のユーザーが、Pingボタン1405を押すことで、クライアント1308-1は、中央サーバー1306を介してプッシュ型メッセージサービス1302に対して、当該メッセージを含んだピングを送信する。プッシュ型メッセージサービス1302は、そのピングを、第2のユーザーJaneDoeと関連付けられたクライアント装置1308-2に対してプッシュする。すなわち、第2のユーザーに対して即時に、視覚的、音声的または触覚的な通知すなわちピング1402を送信する。クライアント装置1308-2は、これを受けて、画面1410を表示するまたは、対応する音声通知、触覚通知を行う。ピングを受信すると、第2のユーザーの受信箱には、第1のユーザーからのピングが、その受信日時と共に、受信した通知の一つとして保持される。また、画面1418のように、第1のユーザーの存在状態1420と共に、そのメッセージ全文を表示してもよい。例えば、画面1418には、JohnDoeの存在状態としてオフィス内すなわちオフィスに居るという情報が表示される。図15を参照する。第1のユーザーJohnDoeが、クライアント1308-1のディスプレイ画面に表示された、構造化されたユーザーダイアログ1504を用いて、ナッジ1502を第2のユーザーJaneDoeに向けて送信する。このダイアログ1504では、第1のユーザーJohnDoeが、第2のユーザーJaneDoeとの2010年7月22日までという期限での電話によるコミュニケーションを設定するために、ナッジが用いられている。このナッジの画面は、電話が希望する通信手段であることと、利用可能な通信手段として、電話、電子メール、SMSテキストメッセージがあることを示している。第1のユーザーが、ダイアログ1504上のNudgeボタン1505を押すと、クライアント1308-1はナッジを、中央サーバー1306を介してプッシュ型メッセージサービス1302に送信する。これを受信した、プッシュ型メッセージサービス1302は、第2のユーザーに関連付けられたクライアント1308-2に対して、そのナッジをプッシュ送信する。クライアント1308-2は、第2のユーザーにそのプッシュ型メッセージが送信されてきたことを示すべく、ナッジの内容を返信ダイアログを表示した画面1506として表示する。第2のユーザーJaneDoeは、中央サーバー1306およびプッシュ型メッセージサーバー1302を介して、そのナッジに対して返信することができる。この例においては、第2のユーザーJaneDoeは、今すぐに電話で連絡することと、2010年7月22日7:30PMに電話で連絡することを希望しており、その旨が画面1506として示されている。この構造化された返信ダイアログを表示した画面1506は、元のナッジに示された条件に合致する条件日時および通信手段のみを、第2のユーザーの希望として受け付けるようになっている。例えば、第2のユーザーナッジの受信者、JaneDoeは、第1のユーザーナッジの送信者、JohnDoeが利用可能であるとして指定した通信手段の中からしか、通信手段を選択できないようになっている。第2のユーザーは、第1のユーザーの希望通信手段と異なる通信手段を選択することはできるが、第1のユーザーの利用可能な通信手段と異なるものを選択することはできないのである。また、返信ダイアログ1506は、第1のユーザーの指定した連絡日時の条件に合致する日時しか、第2のユーザーに指定できないようになっている。引き続き、第1のユーザーは、第2のユーザーからの返信を受信する。そして、返信ダイアログ1512を用いて、さらなる返信を第2のユーザーに対して送信する。この返信ダイアログでは、第1のユーザーは、第2のユーザーから受信したメッセージに含まれる条件今すぐ電話で7:30に電話での中から、連絡日時および場所を選択することができる。この返信ダイアログでは、また、コミュニケーションの設定を断念という選択肢も選択可能である。また、第1のユーザーのカレンダーに、合意した日時等の条件、およびその所要時間の予想を登録することを選択することができる。第1のユーザーは、中央サーバー1306およびプッシュ型メッセージサーバー1302を介して、第2のユーザーに返信1512を送信する。この例では、第1のユーザーからの返信には、第1のユーザーが第2のユーザーに電話ですぐに連絡することを示す情報が含まれている。第2のユーザーは、その第1のユーザーからの返信を受信し、その内容を確認ダイアログ1516を用いて確認する。ここでは、第1のユーザーJohnDoeが第2のユーザーJaneDoeに、すぐに電話で連絡する旨が確認できる。確認ダイアログ1516は、第2のユーザーが、その連絡の予定をカレンダーに登録するか否かを選択するためのUIチェックボックスを含む。また、それが5分程度で終わるであろうことを表示する。以上のように図15を用いて説明したナッジの例は、構造化されたダイアログを用いて、ユーザーに対してコミュニケーションの日時および通信手段の設定を可能とする。これらの構造化ダイアログが、ユーザーに対して、ユーザーが受け容れ可能であるとして予め設定した、またはそのユーザーの存在状態から受け容れ可能であると判断できる、現実的な少なくともそのユーザー側からは合意可能な選択肢を提供する。また、ナッジの受信者第2のユーザーに対しては、ナッジの送信者第1のユーザーによって設定された条件の範囲内でのみ、日時および通信手段の選択設定を許容するようにしている。図16および17は、本システムの各要素同士がどのように連携して、ナッジおよびピングの機能をサポートするかを示すフローチャートである。図16は、ピングにおける処理のフローチャートである。ここでは、第1のユーザーは、ユーザーAとも称することとする。ピングを用いて、ユーザーAJohnDoeは、どのユーザーにピングを送信するか、および、その送信の理由が何か、を指定することによって、ピングを送信する意図を指定するステップ1602。ここでは、いずれの指定も、予め設定されたリストからの選択を行うことで行う。ピングは、通知を行うサーバー例えば中央サーバー1306に送信され、そのサーバーによって指定された受信者であるユーザーBJaneDoeのクライアントに向けて送信される。これは、ユーザーBのクライアント装置からの定期的なプル型のリクエストHTTPであればGETに応じて行われてもよいし、プッシュ型で行われてもよい。ピングおよびナッジが受信者に届きさえすればよいのである。ユーザーBが受信した通知ピングは、ユーザーAによって選択されたその送信の理由と共に、ユーザーAの所在や活動状況等の存在状態に関する付加的な情報を含んでいる。これは、図1乃至図10を用いて説明したシステムを利用することで実施可能である。ユーザーBは、その理由および付加的な情報を確認するステップ1604。ピング利用の具体的なシナリオとして、以下のようなものが考えられる。ユーザーAJohnDoeが、予め設定されている会議に遅れそうであるとする。その遅刻を知らせるために、ユーザーAは、その会議の主催者であるユーザーBJaneDoeに対して、遅刻の通知遅れますを理由とするピングを送信する。会議室にいるユーザーBは、その通知を携帯端末で受信し、その端末の表示からユーザーAが遅れるということ、およびその存在状態を知る。存在状態としては、例えば、外出中である旨や、前の会議が長引いている等の情報が考えられる。図17は、ナッジ送信の際のシステムの連携を示す図である。ナッジを送信する際に、ユーザーAJohnDoeは、以下の2つの事項を指定する。すなわち、1時間的制限、2通信手段の2つである。ユーザーAは、時間的制限に関しては、3つの選択肢の中から選択可能である。すなわち、1至急、2いつでも期限が無い、3期限あり特定の日時を指定の3つである。ユーザーAは、また、希望する通信手段と共に利用可能な通信手段を指定する。ユーザーAがナッジを送信することを選択した場合、そのメッセージは、HTTPコールを介して、通知サーバーに送信される。するとその通知サーバーは、ユーザーBJaneDoeのデバイスに対してそのメッセージを送信する。ユーザーAからの情報、すなわち、時間的制限および通信手段に関してユーザーAが指定した条件が、ユーザーBに対して通知されるステップ1704。これに対して、ユーザーBに対しては、以下の3つの選択肢が示される。すなわち、1ユーザーAによって指定された条件提案のいずれかに合意する、2ユーザーAによって指定された条件提案の範囲内で、特定の条件日時および通信手段を提案する、3合意できる条件がない旨を通知する。ユーザーBが1を選択した場合ステップ1706-1、メッセージが通知サーバーに送信され、合意内容を確認するメッセージがユーザーAおよびB両者のデバイスに送信されるステップ1708、1710。ユーザーBが2を選択した場合ステップ1706-2、ユーザーA指定の条件と整合する範囲で、特定の日時および通信手段を、ユーザーBに選択させる。その後、その提案内容を含んだメッセージが、通知サーバーに送信され、その通知サーバーによってユーザーAの装置に対して送信される。結果として、ユーザーAに対して、ユーザーBによって特定された日時および通信手段が通知されるステップ1712。このメッセージの受信したユーザーAは、1その日時通信手段に合意する、2合意できない旨を通知する、のいずれかを選択する。1の合意が選択された場合ステップ1714-1、ユーザーAおよびBの両者に対して確認のメッセージを送信するステップ1708および1710。ユーザーA側からステップ1714-2、ユーザーB側からステップ1706-3のいずれにせよ、合意不能である旨が選択された場合には、合意に至らなかった旨のメッセージを両者に対して送信し、終了するステップ1716。ナッジ送信に際しては、これらのコミュニケーションの条件だけでなく、図1乃至図10を用いて説明したシステムを用いて、ユーザーの存在状態を併せて送信することができる。相手方が出張中であるという情報が得られた場合には、その相手方に直接会うようなリクエストを行うことは無いであろう。ナッジ利用の具体的なシナリオとして以下のようなものが考えられる。ユーザーAJohnDoeは、文書作成中であり、ユーザーBJaneDoeが持っている情報をその中に加えたいと考えている。その情報を取得するためには、ユーザーAは、ユーザーBと会話する必要がある。そこで、ユーザーAは、本システムによってユーザーBの存在状態を確認する。ユーザーBが外出中であることを知ったユーザーAは、電話でコミュニケーションを行うことを決定し、その旨をナッジに含める情報として指定する。ユーザーAはまた、文書の完成を遅らせないために、そのユーザーBとのコミュニケーションが至急行われるべきことを、ナッジの情報として指定する。その後、これらの情報を含んだナッジを、ユーザーにBに対して送信するステップ1702。このナッジを受信したステップ1704ユーザーBは、すぐに電話をするという選択肢に合意できる旨、および、明日オフィスで直接対話するのがより好ましい希望旨のナッジを返信するステップ1706-2。ユーザーAは、その返信のナッジを受信し1712、明日直接対話という条件に合意する1714-1。これまでは、1対1のやり取りについて説明してきたが、当業者が容易に理解できるように、多人数でのやり取りにおいても本システムは適用可能である。例えば、1人のユーザーが多人数のユーザーに一斉にピングを送信することもできる。また、多人数での会議の日程調整のために、1人のユーザーが多人数のユーザーに対して、ナッジを送信することも可能である。図18は、サーバー1306のブロック図である。これは、図2のサーバー102と共通する部分が多いので、同じ部分については、同じ符号で表している。図2のサーバー102との相違点は、ピングおよびナッジの送受信機能を有することに伴うものである。サーバー1306は、サーバー102に付加する形で、ピングの処理を行うピングモジュール1802、ナッジの処理を行うナッジモジュール1806を有する。例えば、これらのモジュールがそれぞれ、図14に示す処理1400番台および図15に示す処理1500番台を実行する。また、サーバー1306は、ピングモジュールの一部としてピングに関するユーザー設定を格納する領域1804を、ナッジモジュールの一部としてナッジに関するユーザー設定を格納する領域1808をそれぞれ有する。例えば、ナッジのユーザー設定1808は、それぞれのユーザーが特定の日時や状態休暇中や電車移動中等においてどのような通信手段を好むかを示す情報である。また、サーバー1306は、プッシュ型のメッセージ送信を行うプッシュ型メッセージサービス1302を備えてもよい。もちろん、このサービスは、サーバー1306とは独立したコンピュータによって実行されてもよい。以下に、ナッジモジュール1806で実行されるナッジ処理の例を図11および12を用いて説明する。図11および12は、コミュニケーションの日時と通信手段を交渉する方法1100および1200に関するサーバー1306における処理のフローチャートである。以下では、説明の便宜のために、通信手段の交渉を主に例にとって説明を行う。図11を参照すると、サーバー1306は、第1のユーザーからの日時および通信手段に関する第2のユーザーに対するリクエストを受信する1102。そのリクエストには、利用可能な通信手段のリストが含まれている。ここで、利用可能な通信手段が指定されていれば、第1のユーザーの希望する通信手段希望通信手段を指定する必要は必ずしも無いことに留意すべきである。また、ただ1つの希望通信手段を指定して、他の利用可能な通信手段を指定しなくてもよい。さらには、希望通信手段を複数指定してもよい。続いて、そのリクエストに基づいて、利用可能な通信手段のリストを含む第1の通知を生成する。そして、第1の通知を第2のユーザーに送信し1106、その通知に対する第2のユーザーからの返信を受信する1108。この第2のユーザーからの返信には、第1の通知において指定していた利用可能な通信手段のいずれかに、第2のユーザーが合意できたか否かを示す情報が含まれる。その第2のユーザーによる返信内容が、希望通信手段への合意ではなく、他の利用可能通信手段のいずれかの代替通信手段としての指定だった場合には、第1のユーザーに対する、その代替通信手段の指定情報を含んだ第2の通知を生成するステップ1110の1。なお、日時の調整の場合には、希望日時の指定範囲内であったとしても、第2のユーザーによって具体的な日時が特定された場合は、代替通信手段の指定があった場合と同様に扱うことができる。第2の通知を第1のユーザーに対して送信するステップ1110の2。また、第2の通知に対する第1のユーザーからの返信を受信するステップ1110の3。この返信には、先に第2のユーザーが指定した代替通信手段に、第1のユーザーが合意したか否かの情報が含まれる。続いて図12を参照する。第1のユーザーからの返信が、代替通信手段に第1のユーザーが合意した旨を示している場合、確認のメッセージを第1のユーザーおよび第2のユーザーに送信するステップ1202。この確認のメッセージには、第1のユーザーが代替通信手段に合意したことを示す情報が含まれる。第1のユーザーからの返信が、代替通信手段に第1のユーザーが合意できない旨を示している場合、その合意できない旨を含む、第2のユーザーに対する第3の通知を生成する。そして、その第3の通知を第2のユーザーに送信する1204。第2のユーザーからの返信が、希望通信手段に第2のユーザーが合意する旨を示している場合、その合意の旨を含む確認のメッセージを第1のユーザーおよび第2のユーザーに対して送信する1206。第1のユーザーと第2のユーザーの間で通信手段および日時に対する合意ができた場合には、その合意した通信手段に対応するカレンダーに登録するイベント情報を、両者に対して送信する1208。なお、この合意内容は、第1のユーザーの希望する希望通信手段であるか、その利用可能通信手段の中から第2のユーザーが指定した代替通信手段であるかを問わない。ここで、以上のようなナッジによるコミュニケーションの調整が行われるシナリオとして以下のようなものが考えられる。第1のユーザーが第2のユーザーへ電話したところ、第2のユーザーが今は話せないとその電話でのコミュニケーションを拒否し、改めて日時通信手段の設定を依頼した場合、第1のユーザーがそのためのナッジを第2のユーザーに送信することが考えられる。また、その電話が、第2のユーザーの留守等の理由により繋がらなかった場合にも、同様のことが考えられる。なお、第1のユーザーからの最初のリクエストには、複数の日時を希望日時として含んでもよい。また、日時は、X月X日X時X分にといった特定の日時の指定だけなく、時間範囲として指定されていても良い。例えば、以下のような指定が可能である。至急、いつでもといった抽象的な時間範囲の指定や、X月X日X時X分より前に、X月X日X時X分より後に、X月X日のX時X分からY月Y日のY時Y分の間にといった、具体的に始点または終点を指定した範囲指定が考えられる。図19は、クライアント1308のブロック図である。この図は図5のクライアント130と共通する部分が多いので、同じ部分については、同じ符号で表現している。このクライアント1308は、ピングとナッジに関連した機能の実行を行うだけでなく、クライアント130または1308の複数のユーザーの統合された存在状態を受信し、また、存在状態を送信する機能を有する。クライアント1308図19の、クライアント130図5との違いは、クライアント1308が、ピング/ナッジクライアントモジュール1902、これに関連するユーザー設定1904、および存在状態情報1906をさらに有しているところにある。これらのモジュールは、図14および図15に示したようなダイアログその他の画面を表示しつつ、前述したようなピングおよびナッジの処理を行う。ユーザー設定1904は、ユーザーごとのコミュニケーションに関する好みが予め登録されて記憶されている。これには、特定の日時における希望する通信手段等が含まれる。存在状態情報1906は、クライアント1308のユーザーの存在状態に関する情報、または、他のユーザーの存在状態に関する情報である。[ナッジおよびピングと存在状態との統合]図20は、存在状態の表示から始まるナッジまたはピングの画面遷移の例を示している。ナッジおよびピングの処理自体は上述のとおりであるが、画面2010が表示されたクライアントから、コミュニケーションをしようとする相手の写真を縮小したサムネール画像2012が選択されると、ピングまたはナッジ処理を開始する。ここで、存在情報としては、図1乃至10を用いて説明したものを用いることができる。また、第2のユーザーJaneDoeの、存在情報だけでなく、その連絡先を表示してもよい図20の画面2020。また、ここで、第1のユーザーJoneDoeがナッジ2022を選択すると、ナッジ画面2080が表示される。また、ピング2024を選択すると、ピング画面2070が表示される。画面2020は、その他にも、その選択によって対応する処理を開始するユーザーインターフェースオブジェクトを含んでいる。例えば、オフィスの電話番号が選択されると、発呼画面2030が表示し、発呼を行うか否かを第1のユーザーに対して確認するダイアログを表示する。もちろん、このような確認をせずに発呼を行うようにしても良い。また、携帯電話番号が選択されると、発呼画面2040を表示する。また、電子メールアドレスが選択されると、電子メール画面2050を表示し、電子メールクライアントを第1のユーザーに選択させる。ここでは、電子メールを作成するためのクライアントComposeと、電子メールを閲覧するためのクライアントEmailを選択する例を示している。また、電子メール画面2050として、クライアントの選択無しで、電子メール作成画面を表示するようにしてもよい。また、カレンダー表示が選択されると、カレンダー画面2060を表示する。これには、第2のユーザーの今後の予定が表示される。図21は、第1のユーザーが第2のユーザーに対してナッジ処理を行う際の流れを示している。この図から分かるように、まず、画面2110図20の画面2020に対応が第1のユーザーのクライアントのディスプレイに表示される。第1のユーザーがナッジ処理を行う旨のNudgeボタン2112を選択すると、ナッジ画面2120図20の画面2080および図15の1504に対応が表示されるステップ1。さらに、この画面でナッジ送信を意味するNudgeボタン2122が選択されると、画面2130図15の画面1506に対応が、第2のユーザーのクライアントのディスプレイに表示されるステップ2。ここで、画面2130に、第1のユーザーの存在状態が表示されるようにしてもよい。第2のユーザーによってナッジの返信を行うことを意味するNudgeBackボタン2132が選択されると、画面2140図15の画面1508に対応が、第1のユーザーのクライアントに表示されるステップ3。第1のユーザーが、日時と通信手段例えば、今すぐに携帯電話でに合意する旨の選択を行うと、合意内容の確認のメッセージを含んだ画面2150図15の画面1516に対応が第2のユーザーのクライアントに表示されるステップ4。この際に、第1のユーザーのクライアントにも確認のメッセージが表示されるようにしてもよい。図22と23は、図21に示したナッジ処理に関する画面を示す図である。図22は、ナッジ画面2210図20の画面2080、図21の画面2120および図15の画面1504に対応を示している。第2のユーザーのサムネール画像2213が、第1のユーザーによって選択されると、ユーザー情報画面2220が表示される。このユーザー情報画面2220には、第2のユーザーに関する情報、例えば存在状態や今後の予定等が表示される。第1のユーザーが、コミュニケーションの希望日時がいつごろであるかの類型を選択するオブジェクト2214を選択すると、画面2230が表示される。この画面2230には、至急いつでもまでに等の、日時がいつごろであるかの類型を示す複数の選択肢が表示される。ここで、までにが選択された場合には、その具体的な日時を指定する情報の入力を受け付ける。ここでは、までにが選択されたことによって選択可能となった日時指定オブジェクトの選択によって表示された別画面2240および2250において、2010年8月24日の午前8時40分が、その希望日時の期限として指定された例を示している。もちろん、画面2230と同じ画面でこれらの指定を行っても良い。この期限となる日時は、現在の日時に基づいて自動的に設定されるようになっていても良い。例えば、現在時刻の30分後を期限とするようにである。通常は、その自動的に設定された日時が、第1のユーザーによって変更されることを許容する。第1のユーザーによって通信手段を指定するオブジェクト2217が選択された場合、通信手段選択画面2260が表示される。第1のユーザーは、ここで希望する通信手段の選択を行う。この画面2260では、電話、インスタントメッセンジャーIM、電子メール、ショートメッセージサービスSMSおよび面談をその選択肢として表示している。第1のユーザーの存在状態や初期設定等、そのユーザーに関する情報に応じて、通信手段選択画面2260に表示される通信手段を異ならせても良い。例えば、外出中であることがその存在状態から分かる場合には、今すぐに面談を行うという選択肢を表示させることは無い。また、既に会議の予定が入っている日時に、面談や電話の選択肢を表示させないようにすることもできる。また、第2のユーザーの存在状態や初期設定に応じて異ならせても良い。例えば、第2のユーザーが国外に居れば、少なくとも国外に居る日時に面談という選択肢が表示されないようにする。ここで、存在状態には、そのユーザーの所在や活動内容を含む。ナッジ画面2210には、利用可能な通信手段を選択するユーザーインターフェースオブジェクト2218が含まれる。第1のユーザーによって、利用可能な通信手段が選択された場合、利用可能通信手段選択画面2270が表示される。この選択に関しては、通信手段選択画面2260と同様に、ユーザーの存在状態等に応じて選択肢の内容を変更することができる。もちろん、選択肢は変更せずに、存在状態と相容れない選択がなされた場合には、ユーザーに対して警告を発するようにしてもよい。図23は、ナッジの受信者にナッジの返信を可能とする画面2310図21の画面2130に対応を示している。第2のユーザーによって、第1のユーザーのサムネール画像2312が選択されると、第1のユーザーに関する情報を示すユーザー画面2320が表示される。ユーザー情報画面2320は、第1のユーザーの存在状態や今後の予定等の情報を含む。第2のユーザーには、第1のユーザーによって指定された日時および通信手段に関する条件の少なくとも一部が受け容れるか否かを入力することが求められる。これは、例えば、合意できる日時通信手段を示すボタン2313を選択するか、都合が合わないことを示すボタン2314を選択するかによって行われる。合意できる日時通信手段がある場合、第2のユーザーは、1以上の日時を、合意可能な日時として指定する。図では、チェックボックス2315をチェックすることによって今すぐが合意可能であることを、チェックボックス2316をチェックすることによって合意可能な日時を指定することを例示している。日時を指定する場合には、第1のユーザーが指定した日時に関する条件の範囲内この場合は、8月24日午前8時40分まででのみ可能であるようにする。また、第2のユーザーは、合意可能であると指定した日時に対応させて、通信手段を指定する。具体的には、通信手段を指定するオブジェクト2317-1および2317-2を選択することによって、通信手段選択画面2360が表示される。この選択画面は、携帯電話、電話オフィス、電話自宅、Skype登録商標、ビデオチャット等の通信手段に関する選択肢が増えていること以外は、図22の画面2260と同様である。チェックボックス2316がチェックした場合には、第2のユーザーは、合意できる日時を指定変更することができる。時刻指定のオブジェクト2215の選択によって、時刻選択画面2240が表示され、日付選択のオブジェクト2216の選択によって、日付選択画面2250が表示される。画面2310は、また、ナッジをサーバー図13のサーバー1306に返信することを指示するNudgeBackオブジェクト2318を含んでいる。図21はナッジ処理であるが、図24はピング処理の流れを示している。この場合、まず、画面2410図20の画面2020に対応が、第1のユーザーのクライアントのディスプレイに表示される。第1のユーザーがピングの実行を指示するPingボタン2412を選択すると、ピング画面2420図20の画面2070および図14の画面1404に対応が表示されるステップ1。さらに、ピング送信を指示するPingボタン2422が選択されると、画面2432または2434のようなピング情報を表示する画面図14の画面1410に対応が、第2のユーザーのクライアントに表示されるステップ2。画面2432は、ピング情報第1のユーザーからのメッセージおよび第1のユーザーに関する情報の表示を含む。画面2432は、また、ナッジやピング処理を実行するユーザーインターフェースオブジェクト図20のオブジェクト2022や2024のようなものを含んでいても良い。図25は、ピング処理の図24におけるステップ1に対応する表示画面を示している。図25は、ピング画面2510図20の画面2070、図24の画面2420および図14の画面1404に対応を含んでいる。送信するメッセージの概要を指定するメッセージユーザーインターフェース2512が選択されると、メッセージ選択画面2520が表示される。メッセージ選択画面2520には、予め定められたメッセージ、例えば遅れます話せます予定通りに行けます忘れずに待っています等、が選択肢とし表示され、ユーザーはこれらのうちのいずれかを選択可能である。ピング画面2510は、また、その他に送信する追加コメントを入力するユーザーインターフェースを含んでいる。その他コメントチェックボックス2514がチェックされると、テキストフィールド2516が利用可能となり、ユーザーからの追加コメントの入力が可能となる。ピング画面2510は、ピング情報のサーバー図13のサーバー1306への送信を指示するPingボタン2422を含んでいる。