JP2012048708A - コミュニケーション支援装置およびプログラム - Google Patents

Abstract

【課題】ユーザー同士がコミュニケーションを行うに当たって、そのコミュニケーションを行う通信手段の調整を事前に行うことができるようにする。
【解決手段】日時および通信手段の１以上の候補に関する情報を含んだ、第１のユーザーからのコミュニケーションの要求（１５０４）を受信する受信手段と、合意可能な日時および通信手段に関する情報を含んだ、第２のユーザーからの返信（１５０６）を生成する返信生成手段と、前記返信を第１のユーザーに向けて送信する送信手段と、を有するコミュニケーション支援装置を提供する。
【選択図】図１５

Description

コミュニケーション支援装置およびプログラムに関する。

非特許文献１には、各種センサーで検出したユーザーの在不在情報を反映させたライブ電話帳について記載されている。

非特許文献２には、登録されたユーザーが、コンピュータを使用しているか、アウェアネスシステムにログインしているか、所在（家、オフィス、研究室等）、アクティビティ（ＩＭを使っている、電話中等）を一覧表示するコンタクトリストを携帯デバイスに表示させ、そのリストから選択することによって、他のユーザーとのコミュニケーションを可能とする技術が記載されている。

マッキンレー他（Ｍａｃｋｉｎｌａｙ ｅｔ ａｌ．）、「パースペクティブウォール：スムーズに統合される詳細と背景（Ｔｈｅ Ｐｅｒｓｐｅｃｔｉｖｅ Ｗａｌｌ： Ｄｅｔａｉｌｓ ａｎｄ ｃｏｎｔｅｘｔ ｓｍｏｏｔｈｌｙ ｉｎｔｅｇｒａｔｅｄ ）」、計算システムにおける人的要因に関するＡＣＭ会議予稿集（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ＡＣＭ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｈｕｍａｎ Ｆａｃｔｏｒｓ ｉｎ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ）、１９９１年、ｐ．１７３−１７９ エルムフィスト他（Ｅｌｍｑｖｉｓｔ ｅｔ ａｌ．）：、「メランジ：マルチフォーカス相互作用のための空間折り畳み（Ｍ´ｅｌａｎｇｅ： Ｓｐａｃｅ ｆｏｌｄｉｎｇ ｆｏｒ ｍｕｌｔｉ−ｆｏｃｕｓ ｉｎｔｅｒａｃｔｉｏｎ）」、計算システムにおける人的要因に関する第２６回年次ＳＩＧＣＨＩ会議予稿集（Ｐｒｏｃｅｅｄｉｎｇ ｏｆ ｔｈｅ ｔｗｅｎｔｙ−ｓｉｘｔｈ ａｎｎｕａｌ ＳＩＧＣＨＩ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｈｕｍａｎ ｆａｃｔｏｒｓ ｉｎ ｃｏｍｐｕｔｉｎｇ ｓｙｓｔｅｍｓ）、２００８年、ｐ．１３３３−１３４２

ユーザー同士がコミュニケーションを行うに当たって、そのコミュニケーションを行う通信手段の調整を事前に行うことができなかった。

本発明の第１の態様によれば、日時および通信手段の１以上の候補に関する情報を含んだ、第１のユーザーからのコミュニケーションの要求を受信する受信手段と、合意可能な日時および通信手段に関する情報を含んだ、第２のユーザーからの返信を生成する返信生成手段と、前記返信を第１のユーザーに向けて送信する送信手段と、を有するコミュニケーション支援装置が提供される。

本発明の第２の態様によれば、前記第１の態様において、第１のユーザーおよび第２のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段と、前記要求に含まれる日時および通信手段に関する条件の範囲内であって、且つ、取得した存在状態から許容される日時および通信手段の組み合わせの指定のみを、少なくとも警告無く、第２のユーザーの入力として受け付ける入力手段と、をさらに有し、前記返信生成手段は、前記入力手段への入力に応じて、前記返信を生成するように構成してもよい。

本発明の第３の態様によれば、前記第１の態様において、第１のユーザーおよび第２のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、前記返信生成手段は、取得した存在状態から、前記要求に含まれる日時および通信手段の候補に合意可能なものがないと判断した場合には、合意できない旨の返信を生成するように構成してもよい。

本発明の第４の態様によれば、第２のユーザーとコミュニケーションを行う日時および通信手段に関する、第１のユーザーによる指定を入力する入力手段と、前記入力に応じて、日時および通信手段の１以上の候補に関する情報を含んだ、第２のユーザーに対するコミュニケーションの要求を、第２のユーザーに向けて送信する送信手段と、前記要求に対する第２のユーザーからの第２のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信する受信手段と、前記返信に含まれた情報を第１のユーザーに通知する通知手段と、を有するコミュニケーション支援装置が提供される。

本発明の第５の態様によれば、前記第４の態様において、第１のユーザーおよび第２のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、前記入力手段は、指定された日時に対して、取得した存在状態から許容される通信手段の指定のみを、少なくとも警告無く、通信手段として受け付けるように構成されてもよい。

本発明の第６の態様によれば、日時および通信手段の１以上の候補に関する情報を含んだ、第１のユーザーからのコミュニケーションの要求を受信するステップと、合意可能な日時および通信手段に関する情報を含んだ、第２のユーザーからの返信を生成するステップと、前記返信を第１のユーザーに向けて送信するステップと、をコンピュータに実行させるプログラムが提供される。

本発明の第７の態様によれば、第２のユーザーとコミュニケーションを行う日時および通信手段に関する、第１のユーザーによる指定を入力するステップと、前記入力に応じて、日時および通信手段の１以上の候補に関する情報を含んだ、第２のユーザーに対するコミュニケーションの要求を、第２のユーザーに向けて送信するステップと、前記要求に対する第２のユーザーからの第２のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信するステップと、前記返信に含まれた情報を第１のユーザーに通知するステップと、をコンピュータに実行させるプログラムが提供される。

第１、４、６および７の態様による発明によれば、ユーザー同士がコミュニケーションを行うに当たって、そのコミュニケーションを行う通信手段の調整を行うことができる。

第２および５の態様による発明によれば、ユーザーの存在状態に合致する通信手段を容易に選択することができるようになる。

第３の態様による発明によれば、コミュニケーションの要求に対して、自動的に応答することができる。

対象人物の存在状態を特定するシステムを表すブロック図である。 サーバーの構成を示すブロック図である。 センサー統合部を示すブロック図である。 データソース統合部を示すブロック図である。 クライアントのコンピュータシステムを示すブロック図である。 対象人物の存在状態を伝えるアプリケーションプログラムのユーザーインターフェースを示すブロック図である。 自分の存在状態として通知するデータの選択を行うアプリケーションプログラムのユーザーインターフェースを示すブロック図である。 典型的なオフィスを写したカメラ画像を示す図である。 対象人物の存在状態を特定するフローチャートである。 対象人物の存在状態を監視するデータ送信統合部の設定手順を示すフローチャートである。 コミュニケーションの時間と媒体を交渉する際のフローチャート（前半）である。 コミュニケーションの時間と媒体を交渉する際のフローチャート（後半）である。 構造化されたやり取りによってコミュニケーションイベントを統合するシステムのブロック図である。 表示画面の遷移によって、ピングに関連するシステム操作の手順を示す図である。 表示画面の遷移によって、ナッジに関連するシステム操作の手順を示す図である。 ピング処理の流れを示すフローチャートである。 ナッジ処理の流れを示すフローチャートである。 サーバーを示すブロック図である。 クライアントを示すブロック図である。 表示画面の遷移によって、典型的なピングとナッジの処理を示す図である。 表示画面を用いて、典型的なナッジ処理を示す図である。 表示画面を用いて、ナッジ処理のステップ１を示す図である。 表示画面を用いて、ナッジ処理のステップ２を示す図である。 表示画面を用いて、典型的なピング処理を示す図である。 表示画面を用いて、ピング処理のステップ１を示す図である。

以下に示す実施例では、２つの構造モデル、すなわち、ピングとナッジを用いている。ピング（Ｐｉｎｇ）は、他の個人またはグループに対して、自分の存在状態（在・不在や活動状況などのその人物の現在の状態）を示す情報を含む短いプッシュ型のメッセージである。ナッジ（Ｎｕｄｇｅ）は、いつどの通信手段を使ってコミュニケーション、すなわち双方向の意思や情報のやり取りを行うかを合意するための交渉用の構造体を提供する。

本実施形態によるシステムは、各対象人物（存在状態を決定するために監視の対象となる者）の存在状態を監視した結果としての１以上のデータフィードを処理し、当該各対象人物の存在状態を、契約者（本システムにおいて、存在状態の配信を受ける者）のグループに通知する。一実施例において、契約者には、各対象人物の現在位置、コミュニケーションの可否、現在の仕事、好みの通信手段が通知される。なお、双方向のコミュニケーションを支援するという目的からは、契約者は、同時に対象人物でもあるのが好ましい。しかし、もちろん対象人物とならずに（自分の存在状態を知らせずに）、他者の監視のみを行う契約者がいてもよい。

図１は、各対象人物の物理的な存在状態を特定するシステム１００を示すブロック図である。システム１００は、サーバー１０２、センサー統合部１１０、データソース統合部１２０、およびクライアントコンピュータシステム１３０を含む。サーバー１０２、センサー統合部１１０、データソース統合部１２０およびクライアントコンピュータ１３０は、ネットワーク１５０を介して相互に接続されている。ネットワーク１５０は、計算機ノードを相互接続可能な各種の有線および無線通信チャンネルである。これには、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）およびこれらの組み合わせが含まれる。また、インターネットも含まれ得る。

センサー統合部１１０は、センサーネットワーク１１１から受信したセンサーデータを統合または集積する。センサーネットワーク１１１の個々のセンサーは、センサー統合部１１０に対して、データフィードを送信する。ここで、データフィードとは、データの供給源からネットワーク上の宛先に向けて送信される一連のデータのことである。

センサー統合部１１０は、そのデータフィードに含まれるデータを取りまとめ、場合によっては一時蓄積した上で、その統合したデータをサーバー１０２に送信する。この例においては、センサーネットワーク１１１は、無線センサー１１２、カメラ１１４およびキーカードセンサー１１６を含んでいる。

無線センサー１１２は、予め定められた場所に設置される（例えば、使用する無線センサーの通信可能範囲内において、建物の中または建物の外）。無線センサー１１２は、その検知可能な範囲内にある無線デバイスであって、対象人物に対応付けられて登録された無線デバイスのデータを含んだデータフィード（以下、無線データフィードとも言う）を供給する。ここで、無線センサー１１２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）センサー、Ｗｉ−Ｆｉ（登録商標）センサー、携帯電話センサー、ＲＦＩＤセンサー、ＲＦセンサーおよび超音波センサーを含む各種の無線によって対象物を検知するセンサーが用いられ得る。

カメラ１１４は、対象人物のオフィス内に設置される。この例においては、カメラは、少なくとも、そのオフィスに対象人物または訪問者が居るかどうかを判定するための情報を含むワークスペースのビデオデータフィードを供給する。この実施例においては、その対象人物がオフィスにおいて通常居るであろうワークスペースの領域の指定を予め行っておく。また、訪問者がそのオフィスに来た際に通常居ることになるであろうワークスペースの領域の指定も行う。例えば、図８は、対象者の典型的なワークスペースを示すカメラのデータフィードのフレーム８０２を表している。図８から分かるように、対象人物が自ら、または管理者が、オフィスを訪れた訪問者が通常占めるであろう空間的領域８０６に対応する領域境界８０４を定義する。また、その対象者がオフィスにおいて通常占めるスペースに当たる空間的領域８１０に対応する領域境界８０８を定義する。

もちろん、１つの部屋で複数人が働いていることもあるし、キュービクルで分割されている場合もある。このような場合には、１台のカメラが複数人分のワークスペースを含んだビデオカメラのデータフィードを送信することになる。この場合、その１台のビデオカメラの映像中において、一人一人の対象人物のワークスペースおよび訪問者用のワークスペースを定義する必要がある。

また、入館・入室の鍵の役割を果たすカードであるキーカードを検知するキーカードセンサー１１６が、施錠されているドアのところに設置されている場合がある。このような場合には、それぞれのキーカードセンサー１１６は、登録された対象人物がそのキーカードを使用して入館（入室）した日時または退館（退室）した日時に関するデータを含むキーカードのデータフィードを供給する。

もちろん、人の存在や活動を検知するために、他のセンサーを用いても良い。例えば、音のパターンから、対象人物の存否やその活動を検知するために、マイクを用いることもできる。同様に、電灯の点灯の有無により対象人物の存否を判断すべく、光センサーを用いることもできる。さらには、これらセンサーの組み合わせによって、その場所に何人の人物が存在するのかを検知することもできる（例えば、ビデオカメラのデータフィードと、マイクのデータフィードとを用いて、その物理空間に何人存在するかを検知することができる）。

そして、この実施例では、独立したセンサー統合部が、複数の種類のセンサー（例：無線センサー１１２、カメラ１１４、キーカードセンサー１１６）からのデータを統合する。

データソース統合部１２０は、外部のデータソース１２１から受信したデータを統合する。データソース１２１のそれぞれは、データソース統合部１２０に対してデータフィードを供給する。そのデータフィードを受信したデータソース統合部は、それらのデータを統合し、場合によっては一時蓄積した上で、その統合したデータのデータフィードをサーバー１０２に対して送信する。

データソース１２１は、カレンダー１２２、ソーシャルネットワークシステム１２４、インスタントメッセンジャーシステム１２６、ネットワーク活動を監視した結果としてのデータを供給するデータソース１２８、および携帯デバイス１２９を含む。ここで、データソースは、後の分析に用いるデータを供給する供給源の意味で用いている。

カレンダー１２２は、ユーザー（対象人物または契約者）のスケジュールを管理記憶しているものであり、そのユーザーの予定に関するデータフィードを供給する。個々のユーザーが複数のカレンダーを用いていることもあるが、その場合には、それらの全部のデータを供給してもよいし、そのサブセットを供給してもよい。カレンダーとしては、個人のカレンダー、グループのカレンダー、イベントのカレンダーおよび業務カレンダー等が利用可能である。

ソーシャルネットワーク１２４およびインスタントメッセンジャーシステム１２６は、通常、対象人物の状態に関する更新された情報を取得することができる。ソーシャルネットワークシステム１２６およびインスタントメッセンジャーシステム１２６の一方または両者は、対象人物本人によって更新された、その対象人物に関する最新の状態に関するデータフィードを供給する。

ネットワーク活動データソース１２８は、対象人物と関連付けられたデバイス（ネットワーク接続されたものに限る）のネットワーク活動を監視する。ここで、監視するネットワークとしては、オフィスのコンピュータネットワーク、オフィスの電話のネットワーク、公共のコンピュータネットワーク、および家庭内のコンピュータネットワーク等が考えられる。

ネットワークアドレスを分析することにより、ネットワーク接続されたデバイスの位置を特定することができる。例えば、ＩＰアドレスを分析することによって、そのＩＰアドレスと関連付けられた地理的な位置をそのデバイスの位置として特定することができる。ネットワーク接続されたデバイスを特定の場所（例：特定の建物内）における存否を決定する。

具体的には、ネットワーク活動データソース１２８は、対象人物のオフィスコンピュータが、例えば以下のどの状態であるかを示す。すなわち、オフライン（ネットワーク接続されていない）の状態、オンラインであって会社のＬＡＮに接続されている状態、または、オンラインであって会社のＶＰＮに接続されている状態のいずれであるか、また、そのコンピュータが使用されているか否か、さらには、オフィスの電話が使用されているか否かという状態などである。

この実施例では、デバイスの識別子（ＭＡＣアドレス等）とネットワークアドレス（ＩＰアドレス等）を分析に用い、建物内におけるデバイスの位置を特定する。例えば、ネットワークデバイスの登録情報のデータベースを、ネットワークアドレスを用いて検索することで、そのデバイスの位置を特定する。

多くの携帯端末は、測位システム（ＧＰＳや基地局による測位システム）を備えているので、これを用いて自デバイスの位置を特定し、特定した位置情報をサーバー１０２に送信することができる。すなわち、携帯端末データソース１２９は、対象人物の携帯端末によって特定されたその位置情報のデータフィードを供給する。

もちろん、他のデータソースを用いることも可能である。例えば、特定の対象人物に関する告知のＲＳＳフィードを、その対象人物の状態を特定するのに用いることができる。

同時に、これらの組み合わせが、対象人物の存在状態を特定するのに用いられる。例えば、特定の時間および場所での会議に関するＲＳＳフィードと、外部カレンダーから取得した対象人物の存在予定場所やイベントデータとを組み合わせて、その対象人物の存在状態を特定することができる。この実施例においては、独立したデータソース統合部が、前述した各種データソースからのデータを統合する。

サーバー１０２は、統合および要約エンジン１０４と、状態データベース１０６とを有している。ここで、統合および要約エンジン１０４は、センサー統合部１１０およびデータソース統合部１２０からデータフィードを受信し、これらに基づいて対象人物の存在状態を決定する。

統合および要約エンジン１０４は、例えば、最新の状態メッセージや建物内における現在の位置等の、取得した状態に関連するデータを要約する。この例においては、統合および要約エンジン１０４は、階層型ルールベースの構造を用いて、対象人物の存在状態を決定する。例えば、データフィードの階層の序列（考慮すべき優先順位）は以下のように決定される。（１）カメラのデータフィード、（２）無線のデータフィード、（３）キーカードのデータフィード、（４）対象人物が更新した状態情報のデータフィード、（５）カレンダーのデータフィードという序列である。もちろん、他の順番も採用し得る。

統合および要約エンジン１０４は、機械学習の手法（サポートベクターマシンやベイジアンネットワーク）を用いて統計的に対象人物の存在状態を決定する。対象人物の存在状態に関して最も高い特異性（ｓｐｅｃｉｆｉｃｉｔｙ）を有するデータフィードを供給する。この特異性のレベルは、例えば、階層型ルールベースの構造を有するデータフィードにおける階層と同様にして決定される。統合および要約エンジン１０４は、２つ以上のデータフィードを組み合わせ、個々の対象人物の存在状態に関し、より高い特異性を作り出す。

状態データベース１０６は、センサーネットワーク１１１から（例えばセンサー統合部１１０を介して）集めた情報、および外部のデータソース１２１から（例えばデータソース統合部１２０を介して）集めた情報を、それらの情報を取得した日時の情報と共に蓄積する。また、このデータベースは、対象人物の過去における存在状態のログを、それらの存在状態が決定された日時と共に蓄積する。状態データベース１０６はまた、ユーザーの使用履歴や、ユーザーの嗜好による設定情報を蓄積する。設定情報として、例えば、クライアントコンピュータシステム１３０のアプリケーション１３２に対して、他のコミュニケーションツールと連携することを許容する旨の情報を蓄積することが挙げられる。

クライアントコンピュータ１３０は、対象人物の存在状態へのアクセスを提供するアプリケーションプログラムであるアプリケーション１３２を含んでいる。アプリケーション１３２は、デバイス（クライアントコンピュータ１３０や携帯端末等）がどのようにしてネットワークに接続されているか、対象人物が現在マウスやキーボードを操作しているか等の詳細情報を通知する。この情報は、統合および要約エンジン１０４によって処理され、デバイスを使用しているという対象人物の存在状態が特定される。現在アクティブになっているアプリケーションプログラムは何か等の他の情報も同様に供給される。アプリケーション１３２は、組織に属する対象人物に関係するデータおよびその存在状態に関する、要約および詳細な視覚化情報の両者を供給してもよい。

例えば、図６は、組織（会社、職場、家庭等）に属する対象人物の存在状態を通知するアプリケーション１３２のユーザーインターフェース（ＵＩ）６０２を示したブロック図６００である。ＵＩ６０２は、組織に属する対象人物を表したタイル６０３の集合を表示する。個々のタイル６０３は、組織に属する対象人物の写真と名前を含む。また、タイルはその対象人物の存在状態を伝えるべく色分けされ、またその存在状態に対応したアイコンがそのタイルの上に表示される。例えば、タイル６０３−１は、そのタイルに関連付けられた対象人物に、何らかのイベント（会議、来客、休暇、セミナー出席等）が予定されていることを示すカレンダーオブジェクト６０４を含んでいる。同様に、タイル６０３−７は、その対象人物のオフィスに訪問者がいることを示す訪問者オブジェクト６０５を含んでいる。

さらに、グレイアウトされたタイルによって、対応する対象人物がオフィスに居ないこと、または、存在状態が特定できないことのいずれかを示してもよい。いずれかのタイルがクリックされる（またはポイントされる）と、そのタイルに対応付けられた対象人物の存在状態に関するより詳細な状態情報を表示する。例えば、タイル６０３−６がクリックされた場合、そのタイルに関連付けられた対象人物に関する状態ウィンドウ６２０を生成する。状態ウィンドウ６２０には、その対象人物の写真６２１、名前６２２、存在状態６２３、対象人物による更新メッセージ６２４およびその更新が行われた日時６２５、電話番号６２６、電子メールアドレス６２７、ならびに、その対象人物のデバイスを検出しているセンサー６２８およびそのセンサーの位置６２９を表示する。状態ウィンドウ６２０は、また、クリック可能なアイコン６３０乃至６３３を含んでいる。これらのアイコンは、それぞれが異なる通信手段（インスタントメッセンジャーや、ビデオ会議等）に対応しており、いずれかのアイコンをクリックすることによって、対応する通信手段が起動し、その対象人物とコミュニケーションをとることが可能となる。

ＵＩ６０２は、また、タイル６０３が新しい情報によって最後に更新された日時に関する情報６０６を含んでいる。「Ｍｙ Ｐａｌｓ」ツール６０７を起動すると、対象人物の組織への追加、削除およびグループ化を行うＵＩ画面が表示され、対象人物の指示に基づいてこれらの機能を実行する。ＵＩ６０２は、また、組織に属する各対象人物によって入力された現在の状態に関するメッセージおよびその入力日時を含んだデータフィード６０９を表示する。

また、ＵＩ６０２とサードパーティーのコミュニケーションツールを連携させて、特定の対象人物の認識情報を収集する段階から、その対象人物とのコンピュータを利用したコミュニケーションの段階へと移行することが可能である。

図２は、サーバー１０２を表すブロック図である。サーバー１０２は、１つ以上の処理装置（ＣＰＵ）２０２、１つ以上のネットワークまたは他の通信インターフェース２０４、メモリー２１０、およびこれらのコンポーネントと通信するための１つ以上の通信バス２０９を有する。通信バス２０９には、システムコンポーネント間を接続し、その間の通信を制御する回路（チップセットとも呼ばれる）を含む。サーバー１０２は、ディスプレイ装置２０６および入力装置２０８（キーボード、マウス、タッチスクリーン、キーパッド等）を含むユーザーインターフェース２０５を備えても良い。メモリー２１０は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー２１０は、また、ＣＰＵ２０２の遠隔地にある記憶装置であっても良い。

メモリー２１０は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。

（１）オペレーティングシステム２１２：基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。

（２） 通信モジュール２１４：通信インターフェース２０４を介して、サーバー１０２を他のコンピュータに接続する。

（３） ユーザーインターフェースモジュール２１６：入力装置２０８を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置２０６上に生成する。

（４） データベースモジュール２１８：サーバー１０２内のデータベースとのインターフェースとなる。

（５） 状態データベース１０６：対象人物の存在状態２２０、センサー統合部からのデータ２２２、データソース統合部からのデータ２２４、ユーザー設定２２６、対象人物に関連付けて登録されたデータソース２２８、対象人物に関連付けて登録されたデバイス２３０、カメラ領域２３２、およびユーザーの使用履歴２３４を保持する。

メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、１つまたは複数のＣＰＵ２０２によって実行される。これらのモジュールやプログラム（すなわち命令列）は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図２に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。

図３は、センサー統合部１１０を表すブロック図である。センサー統合部１１０は、１つ以上の処理装置（ＣＰＵ）３０２、１つ以上のネットワークまたは他の通信インターフェース３０４、メモリー３１０、およびこれらのコンポーネントと通信するための１つ以上の通信バス３０９を有する。通信バス３０９には、システムコンポーネント間を接続し、その間の通信を制御する回路（チップセットとも呼ばれる）を含む。

センサー統合部１１０は、ディスプレイ装置３０６および入力装置３０８（キーボード、マウス、タッチスクリーン、キーパッド等）を含むユーザーインターフェース３０５を備えても良い。メモリー３１０は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー３１０は、また、ＣＰＵ３０２の遠隔地にある記憶装置であっても良い。

メモリー３１０は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。

（１）オペレーティングシステム３１２：基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。

（２） 通信モジュール３１４：通信インターフェース３０４を介して、センサー統合部１１０を他のコンピュータに接続する。

（３） ユーザーインターフェースモジュール３１６：入力装置３０８を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置３０６上に生成する。

（４） 生のセンサーデータ３１８：センサーネットワーク１１１内のセンサーから受信したデータであり、無線センサーデータ３２０、カメラデータ３２２、キーカードセンサー３２４を含む。

（５）統合エンジン３２６：生のセンサーデータ３１８を統合し、サーバー１０２に対してこの統合したセンサーデータを送信する。統合エンジン３２６は、また、対象人物と関連付けて登録されたデバイスに関するデータ３２８、センサーの位置情報３３０、カメラ領域３３２を含む。

メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、１つまたは複数のＣＰＵ３０２によって実行される。これらのモジュールやプログラム（すなわち命令列）は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図３に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。

図４は、データソース統合部１２０を表すブロック図である。データソース統合部１２０は、１つ以上の処理装置（ＣＰＵ）４０２、１つ以上のネットワークまたは他の通信インターフェース４０４、メモリー４１０、およびこれらのコンポーネントと通信するための１つ以上の通信バス４０９を有する。通信バス４０９には、システムコンポーネント間を接続し、その間の通信を制御する回路（チップセットとも呼ばれる）を含む。

データソース統合部１２０は、ディスプレイ装置４０６および入力装置４０８（キーボード、マウス、タッチスクリーン、キーパッド等）を含むユーザーインターフェース４０５を備えても良い。メモリー４１０は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー４１０は、また、ＣＰＵ４０２の遠隔地にある記憶装置であっても良い。

メモリー４１０は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。

（１）オペレーティングシステム４１２：基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。

（２） 通信モジュール４１４：通信インターフェース４０４を介して、データソース統合部１２０を他のコンピュータに接続する。

（３） ユーザーインターフェースモジュール４１６：入力装置４０８を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置４０６上に生成する。

（４）生データ４１８：データソース１２１から受信したデータであり、このデータは、カレンダーデータ４２０、ソーシャルネットワークシステムデータ４２２、インスタントメッセンジャーデータ４２４、およびネットワーク活動データ４２６を含む。

（５）統合エンジン４２８：生データ４１８を統合し、サーバー１０２に対してこの統合したデータを送信する。統合エンジン４２８は、また、対象人物と関連付けて登録されたデータソース４３０の情報を含む。

メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、１つまたは複数のＣＰＵ４０２によって実行される。これらのモジュールやプログラム（すなわち命令列）は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図４に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。

図５は、クライアントコンピュータシステム１３０を表すブロック図である。クライアントコンピュータシステム１３０は、１つ以上の処理装置（ＣＰＵ）５０２、１つ以上のネットワークまたは他の通信インターフェース５０４、メモリー５１０、およびこれらのコンポーネントと通信するための１つ以上の通信バス５０９を有する。通信バス５０９には、システムコンポーネント間を接続し、その間の通信を制御する回路（チップセットとも呼ばれる）を含む。

クライアントコンピュータシステム１３０は、ディスプレイ装置５０６および入力装置５０８（キーボード、マウス、タッチスクリーン、キーパッド等）を含むユーザーインターフェース５０５を備えても良い。メモリー５１０は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭといった高速のランダムアクセスメモリーや、ソリッドステートメモリーを含む。また、磁気ディスクや光ディスク記憶装置等の不揮発性記憶装置であっても良い。メモリー５１０は、また、ＣＰＵ５０２の遠隔地にある記憶装置であっても良い。

メモリー５１０は、後述するプログラム、モジュールおよびデータ構造体を記憶し、また、以下を格納する。

（１）オペレーティングシステム５１２：基本的なシステムサービスを取り扱うための手続きや、ハードウェアに依存したタスクを実行するための手続きを統括する。

（２） 通信モジュール５１４：通信インターフェース５０４を介して、クライアントコンピュータシステム１３０を他のコンピュータに接続する。

（３） ユーザーインターフェースモジュール５１６：入力装置５０８を介してユーザーからのコマンドを受け付け、ユーザーインターフェースオブジェクトをディスプレイ装置５０６上に生成する。

メモリーに格納されたこれらの要素は、対応する機能を実行するために呼び出される。機能実行の命令は、１つまたは複数のＣＰＵ５０２によって実行される。これらのモジュールやプログラム（すなわち命令列）は、独立したプログラム、手続き、モジュールとして実装される必要は無い。図５に記載した各ブロックの要素は、必要に応じて、分割することも可能であるし、また結合することも可能である。

［存在状態の特定］
図９は、対象人物の存在状態を特定する方法９００を示すフローチャートである。統合および要約エンジン１０４が、対象人物の存在状態を示す各種データを含む複数のデータフィードを受信する（ステップ９０２）。この複数のデータフィードは、センサー統合部１１０およびデータソース統合部１２０のいずれか、または両者から送信されたものである。

統合および要約エンジン１０４は、対象人物の存在状態を特定するべく、複数のデータフィードに含まれるデータを処理する。なお、複数のデータフィードは、センサーネットワーク１１１内のセンサーから、または外部のデータソース１２１から、集積部を経ずに直接受信してもよい。この場合、統合および要約エンジン１０４は、受信した生データを、対象人物の存在状態を特定するために用いることになる。また、対象人物が自分の存在状態として監視することを許容したものに対応する状態情報だけが、データフィードとして送信されてくる。

次に、統合および要約エンジン１０４が、対象人物の存在状態に対応するデータを含む複数のデーフィードのサブセットを特定する（ステップ９０４）。その後、統合および要約エンジン１０４が、このサブセットを分析し、その対象人物の存在状態を決定する。
センサー統合部１１０は、カメラ１１４からのビデオデータを解析し、対象人物がそのオフィスにいるか否か、または、訪問者がそのオフィスにいるか否かを決定する。この決定を行うには、例えば、オフィス内において対象人物が通常居る位置として予め設定した領域に、何らかの動きを検出したか否かを判断する。その領域内において動きがある場合には、対象人物がオフィスに居ると判断するのである。また、何の動きも無い場合には、対象人物がオフィスに居ないと判断する。

また、訪問者の有無も同様に判断することができる。すなわち、通常訪問者が占めるであろう位置として予め設定された領域内に何らかの動きを検出した場合には、そのオフィスに訪問者が居ると判断し、検出できなかった場合には、居ないと判断するのである。
センサー統合部１１０は、対象人物または訪問者がオフィスにいるか否かというデータを含むデータを、必要に応じて複数取りまとめて、統合および要約エンジン１０４に対して送信する。また、センサー統合部１１０は、無線センサーからのデータを分析して、そのセンサーの検知可能な範囲において対象人物に関連付けられて登録されている無線デバイスが検出されたか否か、すなわちその範囲に対象人物が居るか否かという、存在状態を決定する。また、センサー統合部１１０は、キーカードセンサーからのデータを分析して、対象人物に関連付けられて登録されているキーカードがそのセンサーの場所で使用されたか否か、すなわち、そのキーカードセンサーがある場所に対象人物が居るか否かという存在状態を決定する。

データソース統合部１２０は、カレンダーデータを分析して、対象人物に何らかの予定があるか否かという存在状態を決定する。また、データソース統合部１２０は、対象人物によって更新された状態データを分析して、その状態データに対応する状態にあるという存在状態を決定する。データソース統合部１２０は、ネットワーク活動を監視したデータを分析して、対象人物に関連付けられて登録されたネットワークデバイスがそのネットワーク上において使用されているか否か、すなわち対象人物がそのデバイスを使用しているか否かという存在状態を決定する。また、当該データを分析し、ネットワークアドレス等のデバイスの接続位置と対応付けられる情報から、当該デバイスがどこで使用されているか（オフィスの建物内、自宅、公共の場所等）という存在状態も決定する。

図９に戻るが、統合および要約エンジン１０４は、決定した１以上の存在状態を、ネットワークを通じて契約者に通知する。ある対象人物の存在状態に関する２つのデータフィードを考慮する場合を例に挙げて説明する。第１のデータフィードが、その対象人物はコンピュータを使用中であるという存在状態を含んでおり、第２のデータフィードが、その対象人物は会社のネットワークにリモート（会社のＬＡＮの外側）から接続しているという存在状態を含んでいるとする。この場合、統合および要約エンジン１０４は、これら２つの情報を統合して、その対象人物に関し、より高いレベルの特異性を有する１つの存在状態、すなわち、社外から会社のＬＡＮに接続して、コンピュータを使用しているという存在状態を通知することになる。

統合および要約エンジン１０４が存在状態を通知する方法については、管理者がこれを設定する。例えば、管理者は、組み合わせられるべきデータフィードを指定する。また、これら組み合わせられる複数の存在状態のうち、１つの存在状態が他の存在状態を包含するなどして、その１つのみが通知されるべきである場合には、その優先順位を指定する。もちろん、エンドユーザーに通知法を設定することを許容するようにしても良い。

統合および要約エンジン１０４は、また、存在状態として、より特異性のレベルの高い、すなわち、そのユーザーの状態をより具体的または詳細に特定するであろう存在状態を１つ以上選択する。すなわち、複数の存在状態を通知する場合には、その存在状態は全て最大の特異性のレベルを有する（例えば、最も詳細な情報）ものである。この特異性のレベルの優先順位は、管理者またはユーザーが設定可能である。また、契約者が組織（会社、職場、家庭等）のメンバーであってもよい。

現在の存在状態および過去の存在状態のグループの中から、通知すべき存在状態を選択してもよい。現在の存在状態が通知する場合、統合および要約エンジン１０４は、複数のデータフィードの中からリアルタイムのデータを取り出して処理をする。一方で、過去の存在状態を通知する場合には、過去に決定して状態データベースに格納されている存在状態を取り出して用いる。また、最も特異性のレベルの高い１つの存在状態だけを通知するようにしてもよい。

対象人物の存在状態が予め定めてあるレベルの特異性に達しない場合には、統合および要約エンジン１０４は、そのレベルに達した中で最新の存在状態と、その状態であると決定した日時とを通知するようにしても良い。

対象人物の存在状態の一覧を、クライアントコンピュータシステム上のアプリケーション１３２のユーザーインターフェース６０２として表示する。存在状態は、対象人物の位置およびその活動を含んでいてもよい。位置は、その対象人物の物理的な存在位置を意味し、活動は、その対象人物が何を行っているか（例えば、会議中、特定のプロジェクトの仕事中、食事で外出中等）を示すものである。

統合および要約エンジン１０４は、複数のデータフィードに基づいて、対象人物の活動を決定し（ステップ９１０）、その活動を契約者に通知する（ステップ９１２）。統合および要約エンジン１０４は、カレンダー１２２から取得した対象人物の予定情報に基づいて、対象人物であり契約者でもある者がアプリケーション１３２を用いて更新した本人の状態情報に基づいて、または対象人物がインスタントメッセンジャーシステムやソーシャルネットワークシステムを使って自ら更新した状態情報に基づいて、その対象人物の活動を決定してもよい。

これらの存在状態の決定は、ルールベースのアルゴリズムや、統計的・確率的モデルアルゴリズムを用いて行うことができる。ところで、ここで説明しているシステムは、対象人物を追跡することが目的ではなく、対象人物の都合を確認できるようにするものである。したがって、対象人物本人に監視対象となる存在状態に関する情報を選択させるのが好ましい。

図１０は、存在状態を監視するためのデータ送信統合部を設定する方法１０００のフローチャートである。サーバー１０２は、監視を許可する存在状態のデータを特定してその登録を依頼する、対象人物本人からのリクエストを受信する（ステップ１００２）。サーバー１０２は、また、管理者からのリクエストを受信するようにしてもよい。

対象人物（または管理者）からのリクエストには、対象人物を監視しデータフィードを送信するセンサー（カメラ１１４等）の識別子が含まれる。サーバー１０２は、受信したリクエストに応じて、そのデバイス（センサー）の識別子とそのリクエストに関わる対象人物とを関連付けて、メモリ上の登録デバイス２３０の領域に記憶する。また、対象人物（または管理者）からのリクエストには、対象人物を監視しデータフィードを送信するデータソース（カレンダー１２２等）の識別子が含まれる。サーバー１０２は、受信したリクエストに応じて、そのデータソースの識別子とそのリクエストに関わる対象人物とを関連付けて、メモリ上の登録データソース２２８の領域に記憶する。

サーバー１０２は、続いて、データ送信統合部を、対応する存在状態の監視を行うように設定する（ステップ１００４）。例えば、サーバー１０２は、そのメモリー内の登録デバイス２３０にある情報を、センサー統合部１１０に対して転送し、そのメモリー内の登録デバイス３２８に記憶させるようにする。同様に、サーバー１０２は、登録データソース２２８の情報をデータソース統合部１２０に転送して、登録データソース４３０に記憶させるようにする。

図７は、監視対象の存在状態を特定しその監視を許可する操作を行う、アプリケーション１３２のユーザーインターフェース７０２を示すブロック図である。ユーザーインターフェース７０２は、対象人物の写真７０４、その名前７０６、その存在状態７０８、および、状態メッセージ７１０を含む。ここで、存在状態７０８は、統合および要約エンジン１０４によって決定され、状態メッセージ７１０は、ＵＩ６０２を用いて入力され、または、ＵＩ７０２の”Ｕｐｄａｔｅ Ｓｔａｔｕｓ”（状態更新）リンク７１２を用いて入力される。ユーザーインターフェース７０２は、ユーザー（対象人物本人または管理者）に対して、チェックボックス７１６（チェックされた場合、制限無しに許可）および７１８（チェックされた場合、特定のデバイスに対してのみ許可）へのチェックの有無によって、対象人物の監視（対応するデータ送信）を行うサービス７１４を有効化または無効化することを選択させる。ユーザーインターフェース７０２は、また、サービスによって収集された現在の情報を、”Ｃｕｒｒｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｅｉｎｇ Ｃｏｌｌｅｃｔｅｄ”（現在情報収集）欄７２０に表示する。”ｓｅｔｔｉｎｇｓ”（設定）リンク７２２が選択されると、オフィスにおいて対称人物や訪問者が通常占める領域を定義するツール（図８）を起動する。これは前述のとおり、対象人物本人か管理者が行う。

図９および図１０のフローチャートに記載した処理は、コンピュータによって読み取り可能な記憶媒体に記憶された命令を、コンピュータが解釈して実行する。

［ナッジ（Ｎｕｄｇｅ）およびピング（Ｐｉｎｇ）］
図１３は、ピング（Ｐｉｎｇ）とナッジ（Ｎｕｄｇｅ）を使ってコミュニケーションイベントを調整するシステムのブロック図である。システム１３００は、外部クラウドのプッシュ型メッセージサービス１３０２、中央サーバー１３０６および１以上のクライアント１３０８（それぞれ１３０８−１、１３０８−２等）を含む。クライアント１３０８は、ピングまたはナッジを実行できるようになっている任意のクライアント装置である。また、上述したアプリケーション１３２の機能の一部を備えていても良い。例えば、クライアント１３０８は、ノート型もしくはデスクトップ型のコンピュータ、スマートフォン、または同様の計算機である。

クライアント１３０８は、また、通知マネージャー１３１０、エンドユーザー向けユーザーインターフェースモジュール１３１２、および携帯端末状態通知統合部１３１４（これは、スマートフォン等の携帯端末において用いられる）を備える。

図１３に示すように、クライアント１３０８は、クライアント同士で、また、他のシステムコンポーネントと、プッシュ型の通信を行う。この際には、外部クラウドのプッシュ型メッセージサービス１３０２を介するが、このサービス１３０２としては、クライアントから送信されたメッセージを転送する一般的なメッセージサービスを用いることができる。また、サービス１３０２は、プル型で通信を行うこともできるが、この際には、中央サーバー１３０６を介する。さらには、このクライアント１３０８は、サーバー１３０６と、システムおよびクライアント操作に関してメッセージをやり取りするように構成されている。例えば、クライアント１３０８は、コミュニケーションを行う媒体に関する設定について、サーバー１３０６とやり取り可能である。

［エンドユーザーＵＩモジュール１３１２］
エンドユーザーＵＩモジュール１３１２は、ピングおよびナッジ処理に関するユーザーインターフェースを生成しこれを表示するとともに、表示されたユーザーインターフェースとユーザーの相互作用を可能とする。このユーザー相互作用は、例えば、キーボード、マウス等のポインティングデバイス、または接触感知式のインターフェースによってなされる。

［ピング］
ピング（Ｐｉｎｇ）は、１人のユーザーから、１人以上の他のユーザーに向けて送信される、構造化された通知である。本実施例の場合、ピングは、対象人物の存在情報、例えば、位置情報、活動状況または連絡可能情報（そのユーザーが現在コミュニケーションを取ることが可能か否かを示す情報）を、契約者に送信するために用いられる。ピングはまた、クライアント１３０８のユーザーである、送信者（存在状態の通知の場合には、対象人物）と受信者（存在状態の通知の場合には、契約者）とに関連付けられている。

［ピング送信者］
ピングの送信者に対しては、（１）予め定められたピングを送信する理由の一覧からいずれかを選択し、（２）緊急度を指定し、（３）自由形式のテキスト入力を可能とする、単純なインターフェースが提供される。

［ピング受信者］
ピングの受信者に対しては、通知生成時において送信者が入力・選択した内容を表示する。送信者の現在の存在状態の詳細が表示されるようにしても良い。

［ナッジ］
ナッジ（Ｎｕｄｇｅ）は、複数のユーザー間で日時と通信手段を交渉するためにやり取りされる、一連の構造化された通知である。ナッジは、ピングと異なり、その受信者に返信を求めることを前提としており、また、ナッジとは別のコミュニケーション（すなわち、合意した日時および通信手段によるコミュニケーション）が引き続き発生することを前提としている。ピングと同様に、ナッジも、送信者および受信者と関連付けられている。このナッジの送信者と受信者に対する機能としては、後述するように、基本機能とオプション機能とがある。

［ナッジ送信者（基本）］
ナッジの送信者に対しては、コミュニケーションを行うに当たって、そのコミュニケーションの態様に関する要望を指定するためのインターフェースが、基本機能として提供される。この態様に関する要望としては、例えば、（１）送信者にとって最も好ましい通信手段および許容可能な通信手段、（２）コミュニケーションの優先度（至急、いつでも可等）、（３）コミュニケーションを行う期限が挙げられる。ここで、通信手段としては、電話（携帯電話、固定電話、ＶＯＩＰソフトウェアを含む）、電子メール、ショートメッセージサービス（ＳＭＳ）、インスタントメッセンジャー（ＩＭ）、ビデオチャットが挙げられる。

［ナッジ受信者（基本）］
ナッジの受信者に対しては、その生成時に送信者が指定した内容から生成された、構造化された通知を表示する。送信者の存在状態を表示しても良い。ナッジの受信者の対応としては、（１）その送信者と直ちにコミュニケーションを開始する、（２）返信する、（３）無視するという選択肢がある。受信者が返信することを選択した場合、その返信には、受信者の許容可能な通信手段に関する情報、および、その通信手段でいつコミュニケーション可能であるかに関する情報が含まれる。受信者が許容可能な通信手段、またはコミュニケーション可能な日時を選択する際には、送信者が指定してきたものを一覧表示し、この中から選択させるようにするのが好ましい。

［ナッジ送信者（オプション）］
ナッジ受信者からの返信があった場合、送信者に対して、その返信の内容を表示するとともに、その返信において指定されている選択肢（通信手段や日時）の中からいずれかを選択させるようにする。ナッジ送信者は、自分の選択した内容に関して、リマインダー（指定日時の直前に発せられる確認のための通知）を受け取るように設定することができる。

［ナッジ受信者（オプション）］
ナッジ受信者が指定した選択肢の中からナッジ送信者が選んだコミュニケーションの態様を、ナッジ受信者に対して通知し、必要に応じてリマインダーの設定を行う。

［コミュニケーションリマインダー・アラート・カレンダーイベント］
コミュニケーションに関するリマインダーやアラートは、ユーザーが設定するようにしてもよいし、ナッジやピングの送信時に自動的に設定するようにしてもよい。

アラートは、ユーザー（典型的には契約者）に対して何らかの注意を喚起する通知であり、画面表示、音声、電子メール等でその注意すべき内容を知らせる。その通知の方法は、ユーザーに対して注意を喚起するものであれば良いが、そのアラートを受け取るユーザーに指定させるのが好ましい。

また、アラートは、その注意喚起の発生条件を定める必要があるが、予め定められた日時をその条件とするのが最も単純な方法である。より複雑な場合として、存在状態と時間との組み合わせでこの条件を設定しても良い。例えば、
・ 通知方法：「ジェーンに電話せよ」と表示する。
・ 発生条件：ジェーンの存在状態が「会議中」でなくなった後であって、且つ午後２時以降。
アラートが発生すると、そのアラートの内容とともに、その通知の対象となっている人物（典型的には対象人物）の存在状態が画面に表示される。

また、ピングやナッジを用いて、合意したコミュニケーションの態様を、その両者のカレンダーに登録するようにしてもよい。これらのリマインダーやアラートは、エンドユーザーＵＩモジュール１３１２の制御の下、クライアント１３０８の画面に表示される。

［予約設定］
ルールベースの方法または明示的な方法で、コミュニケーションの態様をユーザーが指定することができる。例えば、ユーザーが会議に行く際に、前もって通信手段を以下のように設定する。「会議中は、ＩＭまたは電子メールでの連絡が可能」や「会議中は、ナッジによるコミュニケーションのみ可能」や「２時以降に電話連絡可能」がその例である。

ナッジへの返信を、ユーザーの存在状態に応じて自動的に作成してもよい。例えば、カレンダーの情報に基づいて、会議の予定時刻であると判断し、且つカメラの情報に基づいてオフィスに対象人物が居ないと判断した場合に、「現在会議中」である旨の返信を行うことが考えられる。また、ユーザー自身による存在状態の入力内容に基づいて、これを行うこともできる。また、ユーザーが予め設定した規則を用いて返信を自動生成することもできる。例えば、会議中の場合には、ＩＭと電子メールのみ連絡可能である旨の返信すると決めておいた場合には、そのユーザーの存在状態が会議中であると判断したときに、その旨のメッセージを自動的に返信するのである。

また、その予め設定した規則（日時や通信手段）に合致しない条件を候補とするコミュニケーション交渉のためのナッジを受信した場合には、自動的に「合意不能」の旨のメッセージを送信するようにしてもよい。また、送信者の区分に基づいて、その規則を設定するようにしてもよい。たとえば、同僚からのリクエストと友人からのリクエストとを異なるように処理するのである。また、特定の区分のユーザーからのリクエストを拒絶するような規則を設定するようにしてもよい。例えば、重要な会議中は友人からのリクエストを拒絶するようにすることが考えられる。なお、これらの規則や設定は、ユーザー設定として中央サーバー１３０６に記憶される。

［音声・ボイスメールインターフェース］
本システムのユーザーと連絡を取ろうとする、ユーザー外の人に対しては、電話による音声メニューによって、ピングやナッジで通知する場合と同様のコミュニケーション態様を選択できるようにすることができる。または、ナッジやピングの送信を可能とするウェブインターフェースへのリンクを提供するようにしてもよい。

［ウェブインターフェース］
ウェブ（ＷＷＷ）フォーマットでナッジやピングの機能を提供するようにしてもよい。このウェブベースのインターフェースを用いて、ユーザーが、ナッジおよびピングを実行する。他の方法による連絡を試みた人に対して、このウェブインターフェースへのリンクを示すようにすると良い。

［スマートフォンへの入電］
ユーザー（契約者）が別のユーザー（対象人物）から電話を受けた場合に、その発呼者の存在状態が、「通話」「切断」ボタンと同じ画面に表示されるようにする。また、その入電に対する応答として、「ナッジを要求する」旨の選択肢を追加、すなわち「ナッジ要求」ボタンを画面に追加し、ユーザーの選択に応じてナッジを要求する旨のメッセージを発呼者に送信する。また、前述のように予め定めた規則に従って、自動的に「ナッジ要求」のメッセージを送信するようにしても良い。

［スマートフォンからの発信］
電話を掛ける場合、その相手方の存在状態が画面に表示されるようにする。これは、複数人の状態が一覧表示されていても良いし、相手を選んだ後にその存在状態が表示されるようにしても良い。また、その電話が繋がらなかった場合に、画面に表示されているナッジボタンまたはピングボタンの選択を受けて、ナッジまたはピングを送るようにしても良い。

［通知マネージャー１３１０］
登録されたエンドユーザーのデバイスは、サーバーから通知を受信する。その登録デバイスの装置の少なくとも一部に、通知が送信される。

その通知を受信したデバイスは、予め設定された態様でアラートを発生させてユーザーにその内容を知らせる。アラートの通知方法としては、音声、触覚、視覚のいずれかによることが可能である。その通知は、後で詳細に説明するが、やり取りされた通知の構造に依存させることができる。例えば、「待っています」は「話せます」よりも緊急度が高い。この構造は、上述のような状況に応じた設定を用いて自動的に設定するようにしてもよいし、または、ピングやナッジで明示的に指定された優先度を用いても良い。「音声・触覚による通知は不要」といった明示的な規則の表現でもよいし、「会議の終了後まで待てます」といったより適用範囲の広い文脈上の表現でもよい。受信者と送信者は共に、これらの通知をどのように扱うかを指定することができる。例えば、受信者は、「会議中に期限が到来するものでない限り、会議中の通知は不要」と指定することができる。

［携帯端末状態通知統合部１３１４］
このモジュールは、ユーザーの携帯端末と関係する存在状態を通知する。この存在情報には、通話状態（通話中、呼び出し中等）や、その携帯端末の位置情報を含む。この情報は、具体的なＧＰＳ座標でもよいし、構造的な意味論的解釈で予め設定した場所の名前（例えば、「職場」、「自宅」等）でもよい。また、ユーザーは、特定の位置や日時についてのみ、その存在状態を通知するように設定することができる。たとえば、会社の敷地内に居る場合のみ、「位置情報を送信する」等である。

［中央サーバー１３０６］
これは、一連の構造化された双方向の通知（ピングとナッジ）を仲介するネットワークアプリケーションサーバーである。コミュニケーションは、エンドユーザーのデバイス（携帯端末、ノートＰＣ、デスクトップＰＣ等）から送信される。通知は、各ユーザーおよび各デバイスに対してプッシュ型で、ユーザーの個人設定に基づいて配信される。一つのデバイスで配信された通知が消去されると、重複した送信を防ぐように、サーバーは、そのユーザーの他のデバイスに向けて、そのメッセージが削除された旨を知らせる。

［ナッジおよびピングのダイアログ］
上述のように、図１３は、各コンポーネント同士がどのようにやり取りを行うかを抽象的に表現した図である。図１４および１５は、エンドユーザーがクライアント１３０８から本システムを利用する際に表示されると共に、その操作に用いられる、ユーザーダイアログ（プログラムのユーザーインターフェース）の概要を示している。図１４は、ピングに関連したシステム操作の流れを示す、時系列の画面表示の例である。図１５は、ナッジの場合の例である。

図１４を参照すると、第１のユーザー（Ｊｏｈｎ Ｄｏｅ）が、そのユーザーに関連付けられたクライアント１３０８−１のディスプレイに表示され、構造化されたユーザーダイアログ１４０４を用いて、第２のユーザー（Ｊａｎｅ Ｄｏｅ）に対してピング１４０２を送信する。ダイアログ１４０４は、第１のユーザーＪｏｈｎ Ｄｏｅが、自分の状態を示す情報として「遅れます」を選択し、「５分後に到着予定」という付加的なメッセージを入力した結果としてのピングを表している。

第１のユーザーが、「Ｐｉｎｇ」ボタン１４０５を押すことで、クライアント１３０８−１は、中央サーバー１３０６を介してプッシュ型メッセージサービス１３０２に対して、当該メッセージを含んだピングを送信する。プッシュ型メッセージサービス１３０２は、そのピングを、第２のユーザーＪａｎｅ Ｄｏｅと関連付けられたクライアント装置１３０８−２に対してプッシュする。すなわち、第２のユーザーに対して即時に、視覚的、音声的または触覚的な通知すなわちピング１４０２を送信する。クライアント装置１３０８−２は、これを受けて、画面１４１０を表示する（または、対応する音声通知、触覚通知を行う）。ピングを受信すると、第２のユーザーの受信箱には、第１のユーザーからのピングが、その受信日時と共に、受信した通知の一つとして保持される。また、画面１４１８のように、第１のユーザーの存在状態１４２０と共に、そのメッセージ全文を表示してもよい。例えば、画面１４１８には、Ｊｏｈｎ Ｄｏｅの存在状態として「オフィス内」すなわちオフィスに居るという情報が表示される。

図１５を参照する。第１のユーザーＪｏｈｎ Ｄｏｅが、クライアント１３０８−１のディスプレイ画面に表示された、構造化されたユーザーダイアログ１５０４を用いて、ナッジ１５０２を第２のユーザーＪａｎｅ Ｄｏｅに向けて送信する。このダイアログ１５０４では、第１のユーザーＪｏｈｎ Ｄｏｅが、第２のユーザーＪａｎｅ Ｄｏｅとの「２０１０年７月２２日まで」という期限での電話によるコミュニケーションを設定するために、ナッジが用いられている。このナッジの画面は、電話が希望する通信手段であることと、利用可能な通信手段として、電話、電子メール、ＳＭＳ（テキストメッセージ）があることを示している。

第１のユーザーが、ダイアログ１５０４上の「Ｎｕｄｇｅ」ボタン１５０５を押すと、クライアント１３０８−１はナッジを、中央サーバー１３０６を介してプッシュ型メッセージサービス１３０２に送信する。これを受信した、プッシュ型メッセージサービス１３０２は、第２のユーザーに関連付けられたクライアント１３０８−２に対して、そのナッジをプッシュ送信する。クライアント１３０８−２は、第２のユーザーにそのプッシュ型メッセージが送信されてきたことを示すべく、ナッジの内容を返信ダイアログを表示した画面１５０６として表示する。第２のユーザーＪａｎｅ Ｄｏｅは、中央サーバー１３０６およびプッシュ型メッセージサーバー１３０２を介して、そのナッジに対して返信することができる。この例においては、第２のユーザーＪａｎｅ Ｄｏｅは、「今すぐ」に「電話」で連絡することと、２０１０年７月２２日７：３０ＰＭに電話で連絡することを希望しており、その旨が画面１５０６として示されている。この構造化された返信ダイアログ（を表示した画面）１５０６は、元のナッジに示された条件に合致する条件（日時および通信手段）のみを、第２のユーザーの希望として受け付けるようになっている。例えば、第２のユーザー（ナッジの受信者、Ｊａｎｅ Ｄｏｅ）は、第１のユーザー（ナッジの送信者、Ｊｏｈｎ Ｄｏｅ）が利用可能であるとして指定した通信手段の中からしか、通信手段を選択できないようになっている。第２のユーザーは、第１のユーザーの希望通信手段と異なる通信手段を選択することはできるが、第１のユーザーの利用可能な通信手段と異なるものを選択することはできないのである。また、返信ダイアログ１５０６は、第１のユーザーの指定した連絡日時の条件に合致する日時しか、第２のユーザーに指定できないようになっている。

引き続き、第１のユーザーは、第２のユーザーからの返信を受信する。そして、返信ダイアログ１５１２を用いて、さらなる返信を第２のユーザーに対して送信する。この返信ダイアログでは、第１のユーザーは、第２のユーザーから受信したメッセージに含まれる条件「今すぐ電話で」「７：３０に電話で」の中から、連絡日時および場所を選択することができる。この返信ダイアログでは、また、「コミュニケーションの設定を断念」という選択肢も選択可能である。また、第１のユーザーのカレンダーに、合意した日時等の条件、およびその所要時間の予想を登録することを選択することができる。

第１のユーザーは、中央サーバー１３０６およびプッシュ型メッセージサーバー１３０２を介して、第２のユーザーに返信１５１２を送信する。この例では、第１のユーザーからの返信には、第１のユーザーが第２のユーザーに電話ですぐに連絡することを示す情報が含まれている。

第２のユーザーは、その第１のユーザーからの返信を受信し、その内容を確認ダイアログ１５１６を用いて確認する。ここでは、第１のユーザーＪｏｈｎ Ｄｏｅが第２のユーザーＪａｎｅ Ｄｏｅに、すぐに電話で連絡する旨が確認できる。確認ダイアログ１５１６は、第２のユーザーが、その連絡の予定をカレンダーに登録するか否かを選択するためのＵＩ（チェックボックス）を含む。また、それが５分程度で終わるであろうことを表示する。

以上のように図１５を用いて説明したナッジの例は、構造化されたダイアログを用いて、ユーザーに対してコミュニケーションの日時および通信手段の設定を可能とする。これらの構造化ダイアログが、ユーザーに対して、ユーザーが受け容れ可能であるとして予め設定した、またはそのユーザーの存在状態から受け容れ可能であると判断できる、現実的な（少なくともそのユーザー側からは合意可能な）選択肢を提供する。

また、ナッジの受信者（第２のユーザー）に対しては、ナッジの送信者（第１のユーザー）によって設定された条件の範囲内でのみ、日時および通信手段の選択・設定を許容するようにしている。

図１６および１７は、本システムの各要素同士がどのように連携して、ナッジおよびピングの機能をサポートするかを示すフローチャートである。図１６は、ピングにおける処理のフローチャートである。ここでは、第１のユーザーは、ユーザーＡとも称することとする。ピングを用いて、ユーザーＡ（Ｊｏｈｎ Ｄｏｅ）は、どのユーザーにピングを送信するか、および、その送信の理由が何か、を指定することによって、ピングを送信する意図を指定する（ステップ１６０２）。ここでは、いずれの指定も、予め設定されたリストからの選択を行うことで行う。ピングは、通知を行うサーバー（例えば中央サーバー１３０６）に送信され、そのサーバーによって指定された受信者であるユーザーＢ（Ｊａｎｅ Ｄｏｅ）のクライアントに向けて送信される。これは、ユーザーＢのクライアント装置からの定期的なプル型のリクエスト（ＨＴＴＰであればＧＥＴ）に応じて行われてもよいし、プッシュ型で行われてもよい。ピングおよびナッジが受信者に届きさえすればよいのである。ユーザーＢが受信した通知（ピング）は、ユーザーＡによって選択されたその送信の理由と共に、ユーザーＡの所在や活動状況等の存在状態に関する付加的な情報を含んでいる。これは、図１乃至図１０を用いて説明したシステムを利用することで実施可能である。ユーザーＢは、その理由および付加的な情報を確認する（ステップ１６０４）。
ピング利用の具体的なシナリオとして、以下のようなものが考えられる。ユーザーＡ（Ｊｏｈｎ Ｄｏｅ）が、予め設定されている会議に遅れそうであるとする。その遅刻を知らせるために、ユーザーＡは、その会議の主催者であるユーザーＢ（Ｊａｎｅ Ｄｏｅ）に対して、遅刻の通知（「遅れます」）を理由とするピングを送信する。会議室にいるユーザーＢは、その通知を携帯端末で受信し、その端末の表示からユーザーＡが遅れるということ、およびその存在状態を知る。存在状態としては、例えば、外出中である旨や、前の会議が長引いている等の情報が考えられる。

図１７は、ナッジ送信の際のシステムの連携を示す図である。

ナッジを送信する際に、ユーザーＡ（Ｊｏｈｎ Ｄｏｅ）は、以下の２つの事項を指定する。すなわち、（１）時間的制限、（２）通信手段の２つである。ユーザーＡは、時間的制限に関しては、３つの選択肢の中から選択可能である。すなわち、（１）至急、（２）いつでも（期限が無い）、（３）期限あり（特定の日時を指定）の３つである。ユーザーＡは、また、希望する通信手段と共に利用可能な通信手段を指定する。

ユーザーＡがナッジを送信することを選択した場合、そのメッセージは、ＨＴＴＰコールを介して、通知サーバーに送信される。するとその通知サーバーは、ユーザーＢ（Ｊａｎｅ Ｄｏｅ）のデバイスに対してそのメッセージを送信する。ユーザーＡからの情報、すなわち、時間的制限および通信手段に関してユーザーＡが指定した条件が、ユーザーＢに対して通知される（ステップ１７０４）。これに対して、ユーザーＢに対しては、以下の３つの選択肢が示される。すなわち、（１）ユーザーＡによって指定された条件（提案）のいずれかに合意する、（２）ユーザーＡによって指定された条件（提案）の範囲内で、特定の条件（日時および通信手段）を提案する、（３）合意できる条件がない旨を通知する。

ユーザーＢが（１）を選択した場合（ステップ１７０６−１）、メッセージが通知サーバーに送信され、合意内容を確認するメッセージがユーザーＡおよびＢ両者のデバイスに送信される（ステップ１７０８、１７１０）。

ユーザーＢが（２）を選択した場合（ステップ１７０６−２）、ユーザーＡ指定の条件と整合する範囲で、特定の日時および通信手段を、ユーザーＢに選択させる。その後、その提案内容を含んだメッセージが、通知サーバーに送信され、その通知サーバーによってユーザーＡの装置に対して送信される。結果として、ユーザーＡに対して、ユーザーＢによって特定された日時および通信手段が通知される（ステップ１７１２）。このメッセージの受信したユーザーＡは、（１）その日時・通信手段に合意する、（２）合意できない旨を通知する、のいずれかを選択する。（１）の合意が選択された場合（ステップ１７１４−１）、ユーザーＡおよびＢの両者に対して確認のメッセージを送信する（ステップ１７０８および１７１０）。

ユーザーＡ側から（ステップ１７１４−２）、ユーザーＢ側から（ステップ１７０６−３）のいずれにせよ、合意不能である旨が選択された場合には、合意に至らなかった旨のメッセージを両者に対して送信し、終了する（ステップ１７１６）。ナッジ送信に際しては、これらのコミュニケーションの条件だけでなく、図１乃至図１０を用いて説明したシステムを用いて、ユーザーの存在状態を併せて送信することができる。相手方が「出張中」であるという情報が得られた場合には、その相手方に直接会うようなリクエストを行うことは無いであろう。

ナッジ利用の具体的なシナリオとして以下のようなものが考えられる。ユーザーＡ（Ｊｏｈｎ Ｄｏｅ）は、文書作成中であり、ユーザーＢ（Ｊａｎｅ Ｄｏｅ）が持っている情報をその中に加えたいと考えている。その情報を取得するためには、ユーザーＡは、ユーザーＢと会話する必要がある。そこで、ユーザーＡは、本システムによってユーザーＢの存在状態を確認する。ユーザーＢが外出中であることを知ったユーザーＡは、電話でコミュニケーションを行うことを決定し、その旨をナッジに含める情報として指定する。ユーザーＡはまた、文書の完成を遅らせないために、そのユーザーＢとのコミュニケーションが至急行われるべきことを、ナッジの情報として指定する。その後、これらの情報を含んだナッジを、ユーザーにＢに対して送信する（ステップ１７０２）。このナッジを受信した（ステップ１７０４）ユーザーＢは、すぐに電話をするという選択肢に合意できる旨、および、「明日」オフィスで「直接対話」するのがより好ましい（希望）旨のナッジを返信する（ステップ１７０６−２）。ユーザーＡは、その返信のナッジを受信し（１７１２）、明日直接対話という条件に合意する（１７１４−１）。

これまでは、１対１のやり取りについて説明してきたが、当業者が容易に理解できるように、多人数でのやり取りにおいても本システムは適用可能である。例えば、１人のユーザーが多人数のユーザーに一斉にピングを送信することもできる。また、多人数での会議の日程調整のために、１人のユーザーが多人数のユーザーに対して、ナッジを送信することも可能である。

図１８は、サーバー１３０６のブロック図である。これは、図２のサーバー１０２と共通する部分が多いので、同じ部分については、同じ符号で表している。図２のサーバー１０２との相違点は、ピングおよびナッジの送受信機能を有することに伴うものである。サーバー１３０６は、サーバー１０２に付加する形で、ピングの処理を行うピングモジュール１８０２、ナッジの処理を行うナッジモジュール１８０６を有する。例えば、これらのモジュールがそれぞれ、図１４に示す処理（１４００番台）および図１５に示す処理（１５００番台）を実行する。また、サーバー１３０６は、ピングモジュールの一部としてピングに関するユーザー設定を格納する領域１８０４を、ナッジモジュールの一部としてナッジに関するユーザー設定を格納する領域１８０８をそれぞれ有する。例えば、ナッジのユーザー設定１８０８は、それぞれのユーザーが特定の日時や状態（休暇中や電車移動中等）においてどのような通信手段を好むかを示す情報である。また、サーバー１３０６は、プッシュ型のメッセージ送信を行うプッシュ型メッセージサービス１３０２を備えてもよい。もちろん、このサービスは、サーバー１３０６とは独立したコンピュータによって実行されてもよい。

以下に、ナッジモジュール１８０６で実行されるナッジ処理の例を図１１および１２を用いて説明する。図１１および１２は、コミュニケーションの日時と通信手段を交渉する方法１１００および１２００に関するサーバー１３０６における処理のフローチャートである。以下では、説明の便宜のために、通信手段の交渉を主に例にとって説明を行う。

図１１を参照すると、サーバー１３０６は、第１のユーザーからの日時および通信手段に関する第２のユーザーに対するリクエストを受信する（１１０２）。そのリクエストには、利用可能な通信手段のリストが含まれている。ここで、利用可能な通信手段が指定されていれば、第１のユーザーの希望する通信手段（希望通信手段）を指定する必要は必ずしも無いことに留意すべきである。また、ただ１つの希望通信手段を指定して、他の利用可能な通信手段を指定しなくてもよい。さらには、希望通信手段を複数指定してもよい。

続いて、そのリクエストに基づいて、利用可能な通信手段のリストを含む第１の通知を生成する。そして、第１の通知を第２のユーザーに送信し（１１０６）、その通知に対する第２のユーザーからの返信を受信する（１１０８）。この第２のユーザーからの返信には、第１の通知において指定していた利用可能な通信手段のいずれかに、第２のユーザーが合意できたか否かを示す情報が含まれる。その第２のユーザーによる返信内容が、希望通信手段への合意ではなく、他の利用可能通信手段のいずれかの代替通信手段としての指定だった場合には、第１のユーザーに対する、その代替通信手段の指定情報を含んだ第２の通知を生成する（ステップ１１１０の（１））。なお、日時の調整の場合には、希望日時の指定範囲内であったとしても、第２のユーザーによって具体的な日時が特定された場合は、代替通信手段の指定があった場合と同様に扱うことができる。

第２の通知を第１のユーザーに対して送信する（ステップ１１１０の（２））。また、第２の通知に対する第１のユーザーからの返信を受信する（ステップ１１１０の（３））。この返信には、先に第２のユーザーが指定した代替通信手段に、第１のユーザーが合意したか否かの情報が含まれる。

続いて図１２を参照する。第１のユーザーからの返信が、代替通信手段に第１のユーザーが合意した旨を示している場合、確認のメッセージを第１のユーザーおよび第２のユーザーに送信する（ステップ１２０２）。この確認のメッセージには、第１のユーザーが代替通信手段に合意したことを示す情報が含まれる。

第１のユーザーからの返信が、代替通信手段に第１のユーザーが合意できない旨を示している場合、その合意できない旨を含む、第２のユーザーに対する第３の通知を生成する。そして、その第３の通知を第２のユーザーに送信する（１２０４）。

第２のユーザーからの返信が、希望通信手段に第２のユーザーが合意する旨を示している場合、その合意の旨を含む確認のメッセージを第１のユーザーおよび第２のユーザーに対して送信する（１２０６）。

第１のユーザーと第２のユーザーの間で通信手段（および日時）に対する合意ができた場合には、その合意した通信手段に対応するカレンダーに登録するイベント情報を、両者に対して送信する（１２０８）。なお、この合意内容は、第１のユーザーの希望する希望通信手段であるか、その利用可能通信手段の中から第２のユーザーが指定した代替通信手段であるかを問わない。

ここで、以上のようなナッジによるコミュニケーションの調整が行われるシナリオとして以下のようなものが考えられる。第１のユーザーが第２のユーザーへ電話したところ、第２のユーザーが「今は話せない」とその電話でのコミュニケーションを拒否し、改めて日時・通信手段の設定を依頼した場合、第１のユーザーがそのためのナッジを第２のユーザーに送信することが考えられる。また、その電話が、第２のユーザーの留守等の理由により繋がらなかった場合にも、同様のことが考えられる。

なお、第１のユーザーからの最初のリクエストには、複数の日時を希望日時として含んでもよい。また、日時は、「Ｘ月Ｘ日Ｘ時Ｘ分に」といった特定の日時の指定だけなく、時間範囲として指定されていても良い。例えば、以下のような指定が可能である。「至急」、「いつでも」といった抽象的な時間範囲の指定や、「Ｘ月Ｘ日Ｘ時Ｘ分より前に」、「Ｘ月Ｘ日Ｘ時Ｘ分より後に」、「Ｘ月Ｘ日のＸ時Ｘ分からＹ月Ｙ日のＹ時Ｙ分の間に」といった、具体的に始点または終点を指定した範囲指定が考えられる。

図１９は、クライアント１３０８のブロック図である。この図は図５のクライアント１３０と共通する部分が多いので、同じ部分については、同じ符号で表現している。

このクライアント１３０８は、ピングとナッジに関連した機能の実行を行うだけでなく、クライアント１３０または１３０８の複数のユーザーの統合された存在状態を受信し、また、存在状態を送信する機能を有する。クライアント１３０８（図１９）の、クライアント１３０（図５）との違いは、クライアント１３０８が、ピング／ナッジクライアントモジュール１９０２、これに関連するユーザー設定１９０４、および存在状態情報１９０６をさらに有しているところにある。これらのモジュールは、図１４および図１５に示したようなダイアログその他の画面を表示しつつ、前述したようなピングおよびナッジの処理を行う。ユーザー設定１９０４は、ユーザーごとのコミュニケーションに関する好みが予め登録されて記憶されている。これには、特定の日時における希望する通信手段等が含まれる。存在状態情報１９０６は、クライアント１３０８のユーザーの存在状態に関する情報、または、他のユーザーの存在状態に関する情報である。

［ナッジおよびピングと存在状態との統合］
図２０は、存在状態の表示から始まるナッジまたはピングの画面遷移の例を示している。ナッジおよびピングの処理自体は上述のとおりであるが、画面２０１０が表示されたクライアントから、コミュニケーションをしようとする相手の写真を縮小したサムネール画像（２０１２）が選択されると、ピングまたはナッジ処理を開始する。ここで、存在情報としては、図１乃至１０を用いて説明したものを用いることができる。また、第２のユーザーＪａｎｅ Ｄｏｅの、存在情報だけでなく、その連絡先を表示してもよい（図２０の画面２０２０）。また、ここで、第１のユーザーＪｏｎｅ Ｄｏｅがナッジ２０２２を選択すると、ナッジ画面２０８０が表示される。また、ピング２０２４を選択すると、ピング画面２０７０が表示される。

画面２０２０は、その他にも、その選択によって対応する処理を開始するユーザーインターフェースオブジェクトを含んでいる。例えば、オフィスの電話番号が選択されると、発呼画面２０３０が表示し、発呼を行うか否かを第１のユーザーに対して確認するダイアログを表示する。もちろん、このような確認をせずに発呼を行うようにしても良い。また、携帯電話番号が選択されると、発呼画面２０４０を表示する。また、電子メールアドレスが選択されると、電子メール画面２０５０を表示し、電子メールクライアントを第１のユーザーに選択させる。ここでは、電子メールを作成するためのクライアントＣｏｍｐｏｓｅと、電子メールを閲覧するためのクライアントＥｍａｉｌを選択する例を示している。また、電子メール画面２０５０として、クライアントの選択無しで、電子メール作成画面を表示するようにしてもよい。また、カレンダー表示が選択されると、カレンダー画面２０６０を表示する。これには、第２のユーザーの今後の予定が表示される。

図２１は、第１のユーザーが第２のユーザーに対してナッジ処理を行う際の流れを示している。この図から分かるように、まず、画面２１１０（図２０の画面２０２０に対応）が第１のユーザーのクライアントのディスプレイに表示される。第１のユーザーがナッジ処理を行う旨のＮｕｄｇｅボタン２１１２を選択すると、ナッジ画面２１２０（図２０の画面２０８０および図１５の１５０４に対応）が表示される（ステップ１）。さらに、この画面でナッジ送信を意味するＮｕｄｇｅボタン２１２２が選択されると、画面２１３０（図１５の画面１５０６に対応）が、第２のユーザーのクライアントのディスプレイに表示される（ステップ２）。ここで、画面２１３０に、第１のユーザーの存在状態が表示されるようにしてもよい。

第２のユーザーによってナッジの返信を行うことを意味するＮｕｄｇｅ Ｂａｃｋボタン２１３２が選択されると、画面２１４０（図１５の画面１５０８に対応）が、第１のユーザーのクライアントに表示される（ステップ３）。第１のユーザーが、日時と通信手段（例えば、「今すぐ」に「携帯電話で」）に合意する旨の選択を行うと、合意内容の確認のメッセージを含んだ画面２１５０（図１５の画面１５１６に対応）が第２のユーザーのクライアントに表示される（ステップ４）。この際に、第１のユーザーのクライアントにも確認のメッセージが表示されるようにしてもよい。

図２２と２３は、図２１に示したナッジ処理に関する画面を示す図である。

図２２は、ナッジ画面２２１０（図２０の画面２０８０、図２１の画面２１２０および図１５の画面１５０４に対応）を示している。

第２のユーザーのサムネール画像２２１３が、第１のユーザーによって選択されると、ユーザー情報画面２２２０が表示される。このユーザー情報画面２２２０には、第２のユーザーに関する情報、例えば存在状態や今後の予定等が表示される。

第１のユーザーが、コミュニケーションの希望日時がいつごろであるかの類型を選択するオブジェクト２２１４を選択すると、画面２２３０が表示される。この画面２２３０には、「至急」「いつでも」「・・・までに」等の、日時がいつごろであるかの類型を示す複数の選択肢が表示される。ここで、「・・・までに」が選択された場合には、その具体的な日時を指定する情報の入力を受け付ける。ここでは、「・・・までに」が選択されたことによって選択可能となった日時指定オブジェクトの選択によって表示された別画面２２４０および２２５０において、２０１０年８月２４日の午前８時４０分が、その希望日時の期限として指定された例を示している。もちろん、画面２２３０と同じ画面でこれらの指定を行っても良い。この期限となる日時は、現在の日時に基づいて自動的に設定されるようになっていても良い。例えば、現在時刻の３０分後を期限とするようにである。通常は、その自動的に設定された日時が、第１のユーザーによって変更されることを許容する。

第１のユーザーによって通信手段を指定するオブジェクト２２１７が選択された場合、通信手段選択画面２２６０が表示される。第１のユーザーは、ここで希望する通信手段の選択を行う。この画面２２６０では、電話、インスタントメッセンジャー（ＩＭ）、電子メール、ショートメッセージサービス（ＳＭＳ）および面談をその選択肢として表示している。第１のユーザーの存在状態や初期設定等、そのユーザーに関する情報に応じて、通信手段選択画面２２６０に表示される通信手段を異ならせても良い。例えば、外出中であることがその存在状態から分かる場合には、今すぐに面談を行うという選択肢を表示させることは無い。また、既に会議の予定が入っている日時に、面談や電話の選択肢を表示させないようにすることもできる。また、第２のユーザーの存在状態や初期設定に応じて異ならせても良い。例えば、第２のユーザーが国外に居れば、少なくとも国外に居る日時に「面談」という選択肢が表示されないようにする。ここで、存在状態には、そのユーザーの所在や活動内容を含む。ナッジ画面２２１０には、利用可能な通信手段を選択するユーザーインターフェースオブジェクト２２１８が含まれる。第１のユーザーによって、利用可能な通信手段が選択された場合、利用可能通信手段選択画面２２７０が表示される。この選択に関しては、通信手段選択画面２２６０と同様に、ユーザーの存在状態等に応じて選択肢の内容を変更することができる。もちろん、選択肢は変更せずに、存在状態と相容れない選択がなされた場合には、ユーザーに対して警告を発するようにしてもよい。

図２３は、ナッジの受信者にナッジの返信を可能とする画面２３１０（図２１の画面２１３０に対応）を示している。第２のユーザーによって、第１のユーザーのサムネール画像２３１２が選択されると、第１のユーザーに関する情報を示すユーザー画面２３２０が表示される。ユーザー情報画面２３２０は、第１のユーザーの存在状態や今後の予定等の情報を含む。

第２のユーザーには、第１のユーザーによって指定された日時および通信手段に関する条件の少なくとも一部が受け容れるか否かを入力することが求められる。これは、例えば、「合意できる日時・通信手段」を示すボタン２３１３を選択するか、「都合が合わない」ことを示すボタン２３１４を選択するかによって行われる。合意できる日時・通信手段がある場合、第２のユーザーは、１以上の日時を、合意可能な日時として指定する。図では、チェックボックス２３１５をチェックすることによって「今すぐ」が合意可能であることを、チェックボックス２３１６をチェックすることによって合意可能な日時を指定することを例示している。日時を指定する場合には、第１のユーザーが指定した日時に関する条件の範囲内（この場合は、８月２４日午前８時４０分まで）でのみ可能であるようにする。また、第２のユーザーは、合意可能であると指定した日時に対応させて、通信手段を指定する。具体的には、通信手段を指定するオブジェクト２３１７−１および２３１７−２を選択することによって、通信手段選択画面２３６０が表示される。この選択画面は、「携帯電話」、「電話（オフィス）」、「電話（自宅）」、「Ｓｋｙｐｅ（登録商標）」、「ビデオチャット」等の通信手段に関する選択肢が増えていること以外は、図２２の画面２２６０と同様である。

チェックボックス２３１６がチェックした場合には、第２のユーザーは、合意できる日時を指定・変更することができる。時刻指定のオブジェクト２２１５の選択によって、時刻選択画面２２４０が表示され、日付選択のオブジェクト２２１６の選択によって、日付選択画面２２５０が表示される。画面２３１０は、また、ナッジをサーバー（図１３のサーバー１３０６）に返信することを指示するＮｕｄｇｅ Ｂａｃｋオブジェクト２３１８を含んでいる。

図２１はナッジ処理であるが、図２４はピング処理の流れを示している。この場合、まず、画面２４１０（図２０の画面２０２０に対応）が、第１のユーザーのクライアントのディスプレイに表示される。第１のユーザーがピングの実行を指示するＰｉｎｇボタン２４１２を選択すると、ピング画面２４２０（図２０の画面２０７０および図１４の画面１４０４に対応）が表示される（ステップ１）。さらに、ピング送信を指示するＰｉｎｇボタン２４２２が選択されると、画面２４３２または２４３４のようなピング情報を表示する画面（図１４の画面１４１０に対応）が、第２のユーザーのクライアントに表示される（ステップ２）。画面２４３２は、ピング情報（第１のユーザーからのメッセージ）および第１のユーザーに関する情報の表示を含む。画面２４３２は、また、ナッジやピング処理を実行するユーザーインターフェースオブジェクト（図２０のオブジェクト２０２２や２０２４のようなもの）を含んでいても良い。

図２５は、ピング処理の図２４におけるステップ１に対応する表示画面を示している。図２５は、ピング画面２５１０（図２０の画面２０７０、図２４の画面２４２０および図１４の画面１４０４に対応）を含んでいる。送信するメッセージの概要を指定するメッセージユーザーインターフェース２５１２が選択されると、メッセージ選択画面２５２０が表示される。メッセージ選択画面２５２０には、予め定められたメッセージ、例えば「遅れます」「話せます」「予定通りに行けます」「忘れずに」「待っています」等、が選択肢とし表示され、ユーザーはこれらのうちのいずれかを選択可能である。

ピング画面２５１０は、また、その他に送信する追加コメントを入力するユーザーインターフェースを含んでいる。「その他コメント」チェックボックス２５１４がチェックされると、テキストフィールド２５１６が利用可能となり、ユーザーからの追加コメントの入力が可能となる。ピング画面２５１０は、ピング情報のサーバー（図１３のサーバー１３０６）への送信を指示するＰｉｎｇボタン２４２２を含んでいる。

Claims (7)

1. 日時および通信手段の１以上の候補に関する情報を含んだ、第１のユーザーからのコミュニケーションの要求を受信する受信手段と、
   合意可能な日時および通信手段に関する情報を含んだ、第２のユーザーからの返信を生成する返信生成手段と、
   前記返信を第１のユーザーに向けて送信する送信手段と、
   を有するコミュニケーション支援装置。
2. 第１のユーザーおよび第２のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段と、
   前記要求に含まれる日時および通信手段に関する条件の範囲内であって、且つ、取得した存在状態から許容される日時および通信手段の組み合わせの指定のみを、少なくとも警告無く、第２のユーザーの入力として受け付ける入力手段と、
   をさらに有し、
   前記返信生成手段は、前記入力手段への入力に応じて、前記返信を生成する、
   請求項１記載のコミュニケーション支援装置。
3. 第１のユーザーおよび第２のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、
   前記返信生成手段は、取得した存在状態から、前記要求に含まれる日時および通信手段の候補に合意可能なものがないと判断した場合には、合意できない旨の返信を生成する、
   請求項１記載のコミュニケーション支援装置。
4. 第２のユーザーとコミュニケーションを行う日時および通信手段に関する、第１のユーザーによる指定を入力する入力手段と、
   前記入力に応じて、日時および通信手段の１以上の候補に関する情報を含んだ、第２のユーザーに対するコミュニケーションの要求を、第２のユーザーに向けて送信する送信手段と、
   前記要求に対する第２のユーザーからの第２のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信する受信手段と、
   前記返信に含まれた情報を第１のユーザーに通知する通知手段と、
   を有するコミュニケーション支援装置。
5. 第１のユーザーおよび第２のユーザーの少なくとも一方の存在状態に関する情報を取得する存在情報取得手段をさらに有し、
   前記入力手段は、指定された日時に対して、取得した存在状態から許容される通信手段の指定のみを、少なくとも警告無く、通信手段として受け付ける、
   請求項４記載のコミュニケーション支援装置。
6. 日時および通信手段の１以上の候補に関する情報を含んだ、第１のユーザーからのコミュニケーションの要求を受信するステップと、
   合意可能な日時および通信手段に関する情報を含んだ、第２のユーザーからの返信を生成するステップと、
   前記返信を第１のユーザーに向けて送信するステップと、
   をコンピュータに実行させるコミュニケーション支援プログラム。
7. 第２のユーザーとコミュニケーションを行う日時および通信手段に関する、第１のユーザーによる指定を入力するステップと、
   前記入力に応じて、日時および通信手段の１以上の候補に関する情報を含んだ、第２のユーザーに対するコミュニケーションの要求を、第２のユーザーに向けて送信するステップと、
   前記要求に対する第２のユーザーからの第２のユーザーが双方向通信を行う際に合意可能な日時および通信手段に関する情報を含んだ返信を受信するステップと、
   前記返信に含まれた情報を第１のユーザーに通知するステップと、
   をコンピュータに実行させるコミュニケーション支援プログラム。