JP6201432B2 - 情報処理装置、情報処理システム及び情報処理プログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システム及び情報処理プログラムに関する。

特許文献１には、ユーザの現状況を考慮した適切な形でユーザにイベントを通知する方法、システム、及びコンピュータ・プログラム製品を提供することを課題とし、通知が望まれるイベントが発生したことを検出した後、通知サービスが、ユーザの現状況を考えた場合のユーザへの適切な通知方法を決定し、通知サービスは、ユーザに関するコンテキスト情報（例えばユーザの電話機がオンか、話し中か、ハンズフリーモードか、会議中モードかなど）にアクセスすることにより、適切な通知方法を決定し、次いで通知サービスは、ユーザの現状況に基づいて適切な通知方法の決定を導き出すことのできる１組の規則にアクセスし、例えばこれらの規則は、デフォルト規則でもよく、ユーザによって設定された規則でもよく、次いで通知サービスは、適切な通知方法を用いてユーザに通知が送信されるようにし、通知方法には音声通知が含まれ、その場合は通知がユーザに読み上げられることが開示されている。

特許文献２には、無駄なプレゼンス情報の登録処理を防止しつつ、プレゼンス情報の登録処理を好適に行うことができるようにすることを課題とし、情報処理装置に適用可能な携帯端末においては、プレゼンス管理部は、プレゼンス利用者確認要求を生成し、プレゼンス通信部は、プレゼンス利用者確認要求をプレゼンスサーバに送信し、プレゼンスサーバから送信されてきたプレゼンス利用者確認要求に対する応答であるプレゼンス利用者確認応答を受信し、プレゼンス管理部は、プレゼンス利用者確認応答に含まれるプレゼンス利用者に関する情報に基づいて、プレゼンス利用状態管理情報を更新し、プレゼンス利用状態管理情報に基づいて、携帯端末のプレゼンスを利用する他の携帯端末が存在するか否かを判定し、判定結果に基づいて、プレゼンスの通知に関するモードを決定することが開示されている。

特開２００３−２４４３１７号公報 特開２００８−１９７８４３号公報

本発明は、情報処理装置の利用者における状態の問い合わせに対して、連絡可能でないにもかかわらず、利用者における状態の送信を防止するようにした情報処理装置、情報処理システム及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知とともに連絡方法を送信する第１の送信手段と、本情報処理装置の利用者の状態を取得する取得手段と、前記第１の送信手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記連絡方法を行うことができない状態であるか否かを判断する判断手段と、前記判断手段によって前記連絡方法を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を送信する第２の送信手段を具備することを特徴とする情報処理装置である。

請求項２の発明は、請求項１に記載の情報処理装置と、請求項１に記載の情報処理装置を他の情報処理装置とし、該他の情報処理装置から本第２の情報処理装置の利用者における状態を問い合わせる通知を受け付ける受付手段と、前記受付手段によって通知が受け付けられた場合は、前記利用者における状態が、前記他の情報処理装置からの連絡に対応可能であるか否かを判断する第２の判断手段と、前記第２の判断手段によって対応可能でないと判断された場合は、前記利用者における状態を送信しないように制御する送信制御手段を具備する第２の情報処理装置を具備することを特徴とする情報処理システムである。

請求項３の発明は、前記送信制御手段は、前記第２の判断手段によって対応可能であると判断された場合にのみ、前記受付手段によって受け付けられた通知の返信として、前記利用者における状態を送信するように制御することを特徴とする請求項２に記載の情報処理システムである。

請求項４の発明は、前記受付手段は、前記他の情報処理装置からの連絡方法を受信し、前記第２の判断手段は、前記受付手段によって通知が受け付けられた場合は、前記利用者における状態が、該受付手段によって受け付けられた前記連絡方法に対応可能であるか否かを判断することを特徴とする請求項２又は３に記載の情報処理システムである。

請求項５の発明は、前記受付手段は、前記通知を受け付けた後に、前記他の情報処理装置から該通知の取消要求を受け付け、前記送信制御手段は、前記受付手段によって取消要求が受け付けられた場合は、前記利用者における状態を送信しないように制御することを特徴とする請求項２から４のいずれか一項に記載の情報処理システムである。

請求項６の発明は、前記送信制御手段は、前記第２の判断手段による判断結果が、対応可能でないとの判断から対応可能であるとの判断に変更された場合は、前記利用者における状態を送信するように制御することを特徴とする請求項２から４のいずれか一項に記載の情報処理システムである。

請求項７の発明は、請求項１に記載の情報処理装置と、請求項２から６のいずれか一項に記載の情報処理システムにおける第２の情報処理装置と、請求項１に記載の情報処理装置を第１の情報処理装置とし、該第１の情報処理装置から前記第２の情報処理装置の利用者における状態を問い合わせる通知を受け付ける第２の受付手段と、前記第２の受付手段によって通知が受け付けられた場合は、前記第２の情報処理装置に対して該通知を送信する第３の送信手段と、前記第３の送信手段によって送信した通知の応答として、前記第２の情報処理装置の利用者における状態を受け付ける第３の受付手段と、前記第３の受付手段によって受け付けられた前記利用者における状態が、前記第１の情報処理装置からの要求に対応可能であるか否かを判断する第３の判断手段と、前記第３の判断手段によって対応可能でないと判断された場合は、前記利用者における状態を前記第１の情報処理装置に送信しないように制御する第２の送信制御手段を具備する第３の情報処理装置を具備することを特徴とする情報処理システムである。
請求項８の発明は、前記第２の送信制御手段は、前記第３の判断手段によって対応可能であると判断された場合にのみ、前記第２の受付手段によって受け付けられた通知の返信として、前記利用者における状態を前記第１の情報処理装置に送信するように制御することを特徴とする請求項７に記載の情報処理システムである。
請求項９の発明は、前記第２の受付手段は、前記第１の情報処理装置からの連絡方法を受信し、前記第２の受付手段によって通知が受け付けられた場合は、前記第２の情報処理装置の利用者における状態が、該第２の受付手段によって受け付けられた前記連絡方法に対応可能であるか否かを判断する第４の判断手段と、前記第４の判断手段によって対応可能でないと判断された場合は、前記利用者における状態を前記第１の情報処理装置には送信しないように制御する、又は、前記第２の情報処理装置に対しては前記通知を送信しないように制御する第３の送信制御手段を前記第３の情報処理装置が具備することを特徴とする請求項７又は８に記載の情報処理システムである。
請求項１０の発明は、情報処理装置であるコンピュータを、他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知とともに連絡方法を送信する第１の送信手段と、本情報処理装置の利用者の状態を取得する取得手段と、前記第１の送信手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記連絡方法を行うことができない状態であるか否かを判断する判断手段と、前記判断手段によって前記連絡方法を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を送信する第２の送信手段として機能させるための情報処理プログラムである。
請求項１１の発明は、他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知を行う第１の通知手段と、本情報処理装置の利用者の状態を取得する取得手段と、前記第１の通知手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記他の情報処理装置に対して連絡を行うことができない状態であるか否かを判断する判断手段と、前記判断手段によって前記連絡を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を行う第２の通知手段を具備することを特徴とする情報処理装置である。
請求項１２の発明は、情報処理装置であるコンピュータを、他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知を行う第１の通知手段と、本情報処理装置の利用者の状態を取得する取得手段と、前記第１の通知手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記他の情報処理装置に対して連絡を行うことができない状態であるか否かを判断する判断手段と、前記判断手段によって前記連絡を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を行う第２の通知手段として機能させるための情報処理プログラムである。

請求項１の情報処理装置によれば、通知が送信された後に、連絡できない状態になった場合は、問い合わせを取りやめる通知を送信することができる。

請求項２の情報処理システムによれば、情報処理装置の利用者における状態の問い合わせに対して、連絡可能でないにもかかわらず、利用者における状態の送信を防止することができる。

請求項３の情報処理システムによれば、連絡に対応可能な場合にのみ利用者における状態を送信することができる。

請求項４の情報処理システムによれば、相手の連絡方法に対応可能でないにもかかわらず、利用者における状態を送信することを防止することができる。

請求項５の情報処理システムによれば、通知の取消要求を受け付けた場合は、利用者における状態の送信を防止することができる。

請求項６の情報処理システムによれば、対応可能でないとの判断から対応可能であるとの判断に変更された場合は、利用者における状態を送信することができる。

請求項７の情報処理システムによれば、第２の情報処理装置の利用者における状態の問い合わせに対して、連絡可能でないにもかかわらず、利用者における状態を第１の情報処理装置に送信することを防止することができる。
請求項８の情報処理システムによれば、連絡に対応可能な場合にのみ利用者における状態を送信することができる。
請求項９の情報処理システムによれば、第１の情報処理装置からの連絡方法に対応可能でないにもかかわらず、第２の情報処理装置の利用者における状態を送信することを防止することができる。
請求項１０の情報処理プログラムによれば、通知が送信された後に、連絡できない状態になった場合は、問い合わせを取りやめる通知を送信することができる。
請求項１１の情報処理装置によれば、通知が送信された後に、連絡できない状態になった場合は、問い合わせを取りやめる通知を送信することができる。
請求項１２の情報処理プログラムによれば、通知が送信された後に、連絡できない状態になった場合は、問い合わせを取りやめる通知を送信することができる。

第１の実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を実現する場合におけるシステム構成例を示す説明図である。 一般的なプレゼンス処理例を示すフローチャートである。 一般的なプレゼンス処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 第２の実施の形態の構成例についての概念的なモジュール構成図である。 第２の実施の形態による処理例を示すフローチャートである。 第３の実施の形態の構成例についての概念的なモジュール構成図である。 第３の実施の形態による処理例を示すフローチャートである。 第３の実施の形態による処理例を示すフローチャートである。 対応不可能状態リストのデータ構造例を示す説明図である。 連絡方法別対応不可能状態テーブルのデータ構造例を示す説明図である。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

以下、図面に基づき本発明を実現するにあたっての好適な各種の実施の形態の例を説明する。
図１は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するの意である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態に応じて、又はそれまでの状況・状態に応じて定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、全ての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。

本実施の形態である情報処理装置（端末１００）は、端末１００と端末１８０間で連絡をするためのものであって、図１の例に示すように、端末１００とプレゼンスサーバ１５０と端末１８０が通信回線１９９ａ、通信回線１９９ｂを介して接続されている。ここで、「連絡」とは、端末１８０の利用者から端末１００の利用者への連絡であって、具体的には、利用者の操作によって端末１８０から本端末１００宛ての通信（テレビ電話、ＩＰ電話等を含む電話等）である。なお、通信回線１９９ａ、通信回線１９９ｂは、一般的には無線通信であるが、有線通信であってもよい。

端末１００は、通信モジュール１０５、利用者状態取得モジュール１１０、判断モジュール１１５、通信制御モジュール１２０を有している。
通信モジュール１０５は、通信回線１９９ａを介してプレゼンスサーバ１５０の通信モジュール１５５と接続されている。通信回線１９９ａ、プレゼンスサーバ１５０、通信回線１９９ｂを介して、端末１８０と通信を行うものである。通信モジュール１０５は、携帯可能な他の端末１８０から携帯可能な本端末１００の利用者における状態を問い合わせる通知を受け付ける。この問い合わせ通知をプレゼンス利用要求ともいう。端末１８０からの通知の受け付けは、端末１８０から直接送信されてくるものであってもよいし、プレゼンスサーバ１５０を経由して端末１８０から送信されてくるものであってもよい。また、端末１８０への状態の送信は、端末１８０へ直接送信するものであってもよいし、プレゼンスサーバ１５０を経由して端末１８０へ送信するものであってもよい。
また、通信モジュール１０５は、プレゼンス利用要求とともに、端末１８０からの連絡方法を受信するようにしてもよい。ここで「連絡方法」とは、プレゼンス利用要求に対して端末１００から対応可能であることの返信を端末１８０に対して行った後に、端末１８０の利用者から端末１００の利用者への連絡の方法である。具体的には、電話、実際に面談（「面と向かって」「直接会って」、以下、Ｆ２Ｆ（Ｆａｃｅ ｔｏ Ｆａｃｅ）ともいう）等がある。
また、通信モジュール１０５は、連絡方法がＦ２Ｆの場合は、端末１８０の位置（端末１８０の利用者）を受信するようにしてもよい。
また、通信モジュール１０５は、プレゼンス利用要求の通知を受け付けた後に、端末１８０からその通知の取消要求を受け付けるようにしてもよい。

利用者状態取得モジュール１１０は、端末１００の利用者の状態を取得する。例えば、端末１００の表示装置に端末１８０の利用者からプレゼンス利用要求があったことを表示し、端末１００のキーボード、タッチパネル等に対する操作によって、端末１００の利用者に現在の状態を入力させるようにしてもよい。また、端末１００の利用者の電子的なスケジュール帳を参照して、現在のそのスケジュール帳内の予定を取得するようにしてもよい。また、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ：汎地球測位システム）、加速度センサー、音圧（音声）センサー（例えば、マイク等）、光センサー、地磁気センサー等を用いて、端末１００の利用者の状態を取得してもよい。これらのセンサーは、端末１００に内蔵されていてもよいし、利用者が所持しており、利用者状態取得モジュール１１０がセンサーとの通信によってセンサーの検知結果を取得してもよい。例えば、ＧＰＳの出力によって、端末１００の利用者がいる場所を検知するようにしてもよい。加速度センサーの出力によって移動中又は静止中であることを検知してもよいし、音圧センサーの出力によって会話中であることを検知してもよい。また、端末１００の電話モジュールの状態を検知して電話中であることを検知してもよい。また、会議室等に設置されている通信装置（通信中継装置）と通信を行い、その通信装置がどこにあるかを検知することによって、端末１００の場所（端末１００の利用者がいる場所）を検知するようにしてもよい。また、前述した検知方法の複数を組み合わせてもよい。例えば、ＧＰＳの出力によって外出中であること、加速度センサーの出力によって徒歩中であることを認識してもよい。なお、ＧＰＳの出力による外出中であるか否かの認識は、端末１００の利用者が普段いる場所（勤務先のビル等）の範囲を予め登録しておき、その範囲内にいる場合は外出中ではないと認識し、その範囲外になった場合は外出中であると認識してもよい。

判断モジュール１１５は、通信モジュール１０５によって通知が受け付けられた場合は、端末１００の利用者における状態が、端末１８０からの連絡に対応可能であるか否かを判断する。判断は、対応不可能である状態のリストを用意しておき、現在の状態がそのリスト内にある場合は、対応可能ではないと判断する。例えば、そのリストとして対応不可能状態リスト１４００を用いる。図１４は、対応不可能状態リスト１４００のデータ構造例を示す説明図である。対応不可能状態リスト１４００内には、例えば、会議中、電話中、帰宅、休日が記憶されている。つまり、端末１００の利用者における状態が対応不可能状態リスト１４００内にある場合は、対応不可能であると判断する。端末１００の利用者における状態が、対応不可能状態リスト１４００に含まれていない場合は、端末１８０からの連絡に対応可能であると判断する。

また、判断モジュール１１５は、通信モジュール１０５によって通知が受け付けられた場合は、端末１００の利用者における状態が、通信モジュール１０５によって受け付けられた連絡方法に対応可能であるか否かを判断するようにしてもよい。状態が連絡方法に対応可能であるか否かの判断は、「連絡方法」と少なくとも「状態」を対応させて記憶しているテーブルを用意しておき、検知した利用者における状態と相手先の要求に対応するテーブル内の「対応可能であるか否かを示す情報」を抽出することによって判断するようにしてもよい。例えば、そのテーブルとして連絡方法別対応不可能状態テーブル１５００を用いる。図１５は、連絡方法別対応不可能状態テーブル１５００のデータ構造例を示す説明図である。連絡方法別対応不可能状態テーブル１５００は、連絡方法欄１５１０、場所欄１５２０、状態欄１５３０を有している。連絡方法欄１５１０は、端末１８０の利用者からの連絡方法を記憶している。場所欄１５２０は、その連絡方法で連絡を行うにあたっては、状態欄１５３０に記憶されている状態との組み合わせにおいて、場所として不適合（連絡不可能）である場所を記憶している。なお、「ＮＵＬＬ」の場合は、状態欄１５３０に記憶されている状態に一致すれば、いずれの場所であっても連絡不可能であるとする。状態欄１５３０は、その連絡方法で連絡を行うにあたっては、場所欄１５２０に記憶されている場所との組み合わせにおいて、状態として不適合（連絡不可能）である状態を記憶している。なお、「ＮＵＬＬ」の場合は、場所欄１５２０に記憶されている場所に一致すれば、いずれの状態であっても連絡不可能であるとする。
通信モジュール１０５が受信した連絡方法（端末１８０が送信した連絡方法）が連絡方法欄１５１０にあり、それに対応する端末１００の利用者の状態が場所欄１５２０と状態欄１５３０にある場合は、対応不可能であると判断する。端末１００の利用者における状態が、場所欄１５２０と状態欄１５３０に含まれていない場合は、端末１８０からの連絡に対応可能であると判断する。
連絡方法別対応不可能状態テーブル１５００内には、例えば、連絡方法欄１５１０が「電話」、場所欄１５２０が「ＮＵＬＬ」、状態欄１５３０が「電話中」を記憶しており、これは、連絡方法が電話である場合に、状態が電話中であるとき（場所は問わない）は対応不可能であることを示しており、連絡方法欄１５１０が「電話」、場所欄１５２０が「ＮＵＬＬ」、状態欄１５３０が「会議中」を記憶しており、これは、連絡方法が電話である場合に、状態が会議中であるとき（場所は問わない）は対応不可能であることを示しており、連絡方法欄１５１０が「Ｆ２Ｆ」、場所欄１５２０が「プレゼンス利用要求者とは異なる場所」、状態欄１５３０が「ＮＵＬＬ」を記憶しており、これは、連絡方法がＦ２Ｆである場合に、場所がプレゼンス利用要求者とは異なる場所であるとき（状態は問わない）は対応不可能であることを示しており、連絡方法欄１５１０が「Ｆ２Ｆ」、場所欄１５２０が「ＮＵＬＬ」、状態欄１５３０が「電話中」を記憶しており、これは、連絡方法がＦ２Ｆである場合に、状態が電話中であるとき（場所は問わない）は対応不可能であることを示しており、連絡方法欄１５１０が「Ｆ２Ｆ」、場所欄１５２０が「ＮＵＬＬ」、状態欄１５３０が「会議中」を記憶しており、これは、連絡方法がＦ２Ｆである場合に、状態が会議中であるとき（場所は問わない）は対応不可能であることを示している。
なお、判断モジュール１１５は、連絡方法別対応不可能状態テーブル１５００内の連絡方法欄１５１０に対して場所欄１５２０と状態欄１５３０の組み合わせで判断しているが、連絡方法欄１５１０に対して状態欄１５３０だけで判断してもよい。その場合は、もちろんのことながら、連絡方法別対応不可能状態テーブル１５００は、連絡方法欄１５１０と状態欄１５３０の組み合わせがあればよい。また、図１５の例では、場所欄１５２０、状態欄１５３０のいずれかが「ＮＵＬＬ」の例を示しているが、両方に条件が記憶されていてもよい。例えば、場所が「お客様先」、状態が「会議中」の場合は、「電話」の対応不可能としてもよい。

通信制御モジュール１２０は、判断モジュール１１５によって対応可能でないと判断された場合は、端末１００の利用者における状態を端末１８０へ送信しないように、通信モジュール１０５を制御する。
また、通信制御モジュール１２０は、判断モジュール１１５によって対応可能であると判断された場合にのみ、通信モジュール１０５によって受け付けられた通知の返信として、端末１００の利用者における状態を端末１８０へ送信するように、通信モジュール１０５を制御するようにしてもよい。
また、通信制御モジュール１２０は、通信モジュール１０５によって取消要求が受け付けられた場合は、端末１００の利用者における状態を端末１８０へ送信しないように、通信モジュール１０５を制御するようにしてもよい。
また、通信制御モジュール１２０は、判断モジュール１１５による判断結果が、対応可能でないとの判断から対応可能であるとの判断に変更された場合は、端末１００の利用者における状態を端末１８０へ送信するように、通信モジュール１０５を制御するようにしてもよい。

プレゼンスサーバ１５０は、通信モジュール１５５、プレゼンス制御モジュール１６０、利用者管理モジュール１６５、プレゼンス状態管理モジュール１７０、プレゼンス状態記憶モジュール１７５を有している。プレゼンスサーバ１５０は、端末１８０と端末１００間のプレゼンスに関する通信を制御し、プレゼンス情報を管理する。
通信モジュール１５５は、通信回線１９９ａを介して端末１００の通信モジュール１０５と接続されており、また通信回線１９９ｂを介して端末１８０の通信モジュール１８５と接続されている。端末１００と端末１８０のプレゼンスに関する通信を管理するために、その通信を中継する。
プレゼンス制御モジュール１６０は、端末１００と端末１８０の間で行われたプレゼンス利用要求に応じて、相手側への送信を制御する。ただし、第１の実施の形態では、端末１８０からの通信を通信先である端末１００へ送信し、端末１００からの通信を通信先である端末１８０へ送信することを行う。
利用者管理モジュール１６５は、端末１００、端末１８０のそれぞれの利用者を管理する。
プレゼンス状態管理モジュール１７０に、端末１００と端末１８０間のプレゼンス利用要求に関する通信に応じてプレゼンス状態記憶モジュール１７５を管理する。また、プレゼンス状態管理モジュール１７０は、端末１８０以外の端末からプレゼンス利用要求を受信した場合、プレゼンス状態記憶モジュール１７５に管理されているプレゼンス利用状態を更新する。
プレゼンス状態記憶モジュール１７５には、端末１００に対してプレゼンス情報を利用する端末１８０の利用状態（例えば利用する端末１８０の有無や利用数など）が対応付けられて登録されている。

端末１８０は、通信モジュール１８５、プレゼンス確認モジュール１９０を有している。
通信モジュール１８５は、通信回線１９９ｂを介してプレゼンスサーバ１５０の通信モジュール１５５と接続されている。通信モジュール１８５は、端末１００に対して、端末１００の利用者における状態を問い合わせる通知を、プレゼンスサーバ１５０を介して送信する。つまり、前述した通り、通信モジュール１０５が受信するプレゼンス利用要求を送信する。さらに、その問い合わせ通知内に、端末１８０からの連絡方法（端末１８０の利用者からの連絡方法）を含めて送信してもよい。つまり、前述した通り、通信モジュール１０５が受信する連絡方法を送信する。また、通信モジュール１８５は、連絡方法がＦ２Ｆの場合は、端末１８０の位置（端末１８０の利用者）を送信するようにしてもよい。つまり、前述した通り、通信モジュール１０５が受信する位置を送信する。例えば、端末１８０に内蔵されているＧＰＳが出力する座標等である。
また、通信モジュール１８５は、端末１００に対してプレゼンス利用要求の通知を送信した後に、そのプレゼンス利用要求の通知の取消要求を端末１００へ送信するようにしてもよい。
プレゼンス確認モジュール１９０は、端末１００の利用者に対して連絡をするにあたって、その前に端末１００の利用者の状態を問い合わせる（プレゼンス利用要求）。対応可能である旨の返信があった場合は、端末１００の利用者に対して連絡を行う。例えば端末１００の操作キー、タッチパネル等に対する操作が行われることにより、プレゼンス利用要求を生成し、通信モジュール１８５、通信回線１９９ｂを介してプレゼンスサーバ１５０に送信する。

図２は、本実施の形態を実現する場合におけるシステム構成例を示す説明図である。
端末２００Ａ、端末２００Ｂ、端末２００Ｃ、端末２００Ｄ、端末２００Ｅ、プレゼンスサーバ２５０は、通信回線２９９を介してそれぞれ接続されている。図１に例示したプレゼンスサーバ１５０はプレゼンスサーバ２５０に該当し、図１に例示した端末１００、端末１８０は端末２００Ａ〜２００Ｅのいずれかに該当し、図１に例示した通信回線１９９ａ、通信回線１９９ｂは通信回線２９９に該当する。
図２では、端末が５つの例を示したが、端末は複数台あればよい。また、プレゼンスサーバ２５０は複数あってもよい。

図３は、一般的なプレゼンス処理例を示すフローチャートである。このフローチャートによる処理例は、本実施の形態による処理ではない。
ステップＳ３０２では、端末Ａ３００がプレゼンスサーバ３５０に対して、利用者確認要求を行う。端末Ａ３００は、利用者による操作に応じて、端末Ａ３００の利用者の確認を要求するメッセージである利用者確認要求メッセージを生成し、プレゼンスサーバ３５０に送信する。
ステップＳ３０４では、プレゼンスサーバ３５０が端末Ａ３００に対して応答する。プレゼンスサーバ３５０は、利用者確認要求メッセージを受信すると、それに対する応答であるプレゼンス利用者確認応答メッセージを生成して端末Ａ３００に送信する。そして、端末Ａ３００は、プレゼンス確認応答メッセージに含まれる、端末Ａ３００に対してそのプレゼンス情報を利用する他の端末Ｂ３８０の利用状態（例えば、端末Ａ３００のプレゼンス情報を利用する端末Ｂ３８０の有無や利用数など）に関する情報を取得し、取得されたこれらの情報に基づいて端末Ａ３００に対してそのプレゼンス情報を利用する他の端末Ｂ３８０の有無を判定する（換言すれば、取得されたこれらの情報に基づいて端末Ｂ３８０に対してそのプレゼンス情報を利用する他の端末Ｂ３８０が少なくとも１つ以上存在するか否かを判定する）。

ステップＳ３０６では、端末Ｂ３８０がプレゼンスサーバ３５０に対して、プレゼンス利用要求を行う。
ステップＳ３０８では、プレゼンスサーバ３５０が端末Ａ３００に対してプレゼンス利用要求を通知する。
ステップＳ３１０では、端末Ａ３００がプレゼンスサーバ３５０に対して、プレゼンス登録要求を行う。
ステップＳ３１２では、プレゼンスサーバ３５０が端末Ｂ３８０に対して、プレゼンス通知を行う。
このように、本実施の形態以外による処理では、プレゼンス利用要求に対して返信が必ず行われることになり、端末Ａ３００の利用者が対応不可能である場合は、無駄な通信（ステップＳ３１０、ステップＳ３１２）が発生することになる。

図４は、一般的なプレゼンス処理例を示すフローチャートである。このフローチャートによる処理例は、本実施の形態による処理ではない。図４に示した処理例は、図３に示した処理例に、端末Ａ３００からのプレゼンス登録要求として、端末Ａ３００の利用者の状態を付加し、端末Ｂ３８０へのプレゼンス通知として、その利用者の状態を付加したものである。
ステップＳ４０２では、端末Ａ３００がプレゼンスサーバ３５０に対して、利用者確認要求を行う。図３に例示したステップＳ３０２と同等の処理である。
ステップＳ４０４では、プレゼンスサーバ３５０が端末Ａ３００に対して応答する。図３に例示したステップＳ３０４と同等の処理である。
ステップＳ４０６では、端末Ｂ３８０がプレゼンスサーバ３５０に対して、プレゼンス利用要求を行う。
ステップＳ４０８では、プレゼンスサーバ３５０が端末Ａ３００に対して通知する。
ステップＳ４１０では、端末Ａ３００がプレゼンスサーバ３５０に対して、プレゼンス登録要求を行うとともに、端末Ａ３００の利用者の状態として会議中４１０ａを送信する。
ステップＳ４１２では、プレゼンスサーバ３５０が端末Ｂ３８０に対して、プレゼンス通知を行うとともに、端末Ａ３００の利用者の状態として会議中４１２ａを送信する。

ステップＳ４１４では、端末Ｂ３８０がプレゼンスサーバ３５０に対して、プレゼンス利用要求を行う。
ステップＳ４１６では、プレゼンスサーバ３５０が端末Ａ３００に対して通知する。
ステップＳ４１８では、端末Ａ３００がプレゼンスサーバ３５０に対してプレゼンス登録要求を行うとともに、端末Ａ３００の利用者の状態として電話対応可能４１８ａを送信する。
ステップＳ４２０では、プレゼンスサーバ３５０が端末Ｂ３８０に対して、プレゼンス通知を行うとともに、端末Ａ３００の利用者の状態として電話対応可能４２０ａを送信する。

ステップＳ４２２では、端末Ｂ３８０がプレゼンスサーバ３５０に対して、プレゼンス利用要求を行う。
ステップＳ４２４では、プレゼンスサーバ３５０が端末Ａ３００に対して通知する。
ステップＳ４２６では、端末Ａ３００がプレゼンスサーバ３５０に対してプレゼンス登録要求を行うとともに、端末Ａ３００の利用者の状態として会議中４２６ａを送信する。
ステップＳ４２８では、プレゼンスサーバ３５０が端末Ｂ３８０に対してプレゼンス通知を行うとともに、端末Ａ３００の利用者の状態として会議中４２８ａを送信する。
このように、本実施の形態以外による処理では、端末Ｂ３８０の利用者がＦ２Ｆの連絡を希望している場合、プレゼンス利用要求が複数回行われることになり、端末Ｂ３８０の利用者がＦ２Ｆでの対応可能となるまで、無駄な通信（ステップＳ４１０以下の通信）が発生することになる。

図５は、第１の実施の形態による処理例を示すフローチャートである。
ステップＳ５０２では、端末１００がプレゼンスサーバ１５０に対して、利用者確認要求を行う。図３に例示したステップＳ３０２と同等の処理である。
ステップＳ５０４では、プレゼンスサーバ１５０が端末１００に対して応答する。図３に例示したステップＳ３０４と同等の処理である。なお、図６以降の例に示しているフローチャートでは、ステップＳ５０２、ステップＳ５０４に相当する処理は記載していないが、前処理としてこれらの処理を行うようにしてもよい。
ステップＳ５０６では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行う。
ステップＳ５０８では、プレゼンスサーバ１５０が端末１００に対して通知する。
ステップＳ５１０では、＜休止＞：端末１００の利用者の状態は会議中であるため、プレゼンスを送信しない。例えば、利用者状態取得モジュール１１０が、端末１００の利用者の現在の状態として、電子的なスケジュール帳から会議中であることを抽出し、判断モジュール１１５が、会議中は対応不可能であると判断し、通信制御モジュール１２０が、プレゼンス登録要求は送信しないように通信モジュール１０５を制御する。

ステップＳ５１２では、端末１００がプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００の利用者の状態として電話対応可能５１２ａを送信する。例えば、利用者状態取得モジュール１１０が、端末１００の利用者の現在の状態として、会議中の状態から会議終了（電話対応可能）であることを抽出し、判断モジュール１１５が、会議終了（電話対応可能）は対応可であると判断し、通信制御モジュール１２０が、プレゼンス登録要求を送信するように通信モジュール１０５を制御する。
ステップＳ５１４では、プレゼンスサーバ１５０が端末１８０に対して、プレゼンス通知を行うとともに、端末１００の利用者の状態として電話対応可能５１４ａを送信する。
ステップＳ５１６では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行う。
ステップＳ５１８では、プレゼンスサーバ１５０が端末１００に対して通知する。
ステップＳ５２０では、＜休止＞：端末１００の利用者の状態は会議中であるため、プレゼンスを送信しない。

図６は、第１の実施の形態による処理例を示すフローチャートである。このフローチャートは、端末１８０の利用者が端末１００の利用者に対して行う連絡方法（ここでは「Ｆ２Ｆ」）がプレゼンス利用要求に含まれている場合の処理例を示している。つまり、連絡方法に応じて対応可能であるか否かが判断される場合の処理例である。
ステップＳ６０２では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行うとともに、端末１８０の利用者が端末１００の利用者との連絡方法として望んでいるＦ２Ｆ６０２ａを送信する。
ステップＳ６０４では、プレゼンスサーバ１５０が端末１００に対して通知するとともに、端末１８０の利用者が端末１００の利用者との連絡方法として望んでいるＦ２Ｆ６０４ａを送信する。
ステップＳ６０６では、＜休止＞：端末１００の利用者の状態は「お客様先での会議中」であり、Ｆ２Ｆ６０２ａは不可能なため、プレゼンスを送信しない。
ステップＳ６０８では、＜休止＞：端末１００の利用者の状態変更を検知する。端末１００の利用者の状態が「外出先で徒歩移動中」と変化したとしても、その状態ではＦ２Ｆ６０２ａは不可能なため、プレゼンスを送信しない。
ステップＳ６１０では、＜実行＞：端末１００の利用者の状態が「拠点内自席６１２ａ」と変化したことを検知し、Ｆ２Ｆ６０２ａが可能となったため、プレゼンスを送信する。
ステップＳ６１２では、端末１００がプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００の利用者の状態として拠点内自席６１２ａを送信する。
ステップＳ６１４では、プレゼンスサーバ１５０が端末１８０に対して、プレゼンス通知を行うとともに、端末１００の利用者の状態として拠点内自席６１４ａを送信する。

図７は、第１の実施の形態による処理例を示すフローチャートである。このフローチャートは、端末１８０の利用者が端末１００の利用者に対して行う連絡方法（ここでは「電話」）がプレゼンス利用要求に含まれている場合の処理例を示している。つまり、連絡方法に応じて対応可能であるか否かが判断される場合の処理例である。
ステップＳ７０２では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行うとともに、端末１８０の利用者が端末１００の利用者との連絡方法として望んでいる電話７０２ａを送信する。
ステップＳ７０４では、プレゼンスサーバ１５０が端末１００に対して通知するとともに、端末１８０の利用者が端末１００の利用者との連絡方法として望んでいる電話７０４ａを送信する。
ステップＳ７０６では、＜休止＞：端末１００の利用者の状態は「お客様先での会議中」であり、電話７０２ａは不可能なため、プレゼンスを送信しない。

ステップＳ７０８では、＜実行＞：端末１００の利用者の状態が「外出先で徒歩移動中７１０ａ」と変化したことを検知し、電話７０２ａが可能となったため、プレゼンスを送信する。つまり、連絡方法が電話である場合は、「お客様先での会議中」は対応不可能であるが、「外出先で徒歩移動中７１０ａ」である場合は対応可であると判断する。
ステップＳ７１０では、端末１００がプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００の利用者の状態として外出先で徒歩移動中７１０ａを送信する。
ステップＳ７１２では、プレゼンスサーバ１５０が端末１８０に対して、プレゼンス通知を行うとともに、端末１００の利用者の状態として外出先で徒歩移動中７１２ａを送信する。

図８は、第１の実施の形態による処理例を示すフローチャートである。プレゼンス利用要求を受信する端末が複数ある場合の例を示したものである。つまり、端末１８０の利用者は、端末１００Ａ、端末１００Ｃ、端末１００Ｄの利用者に対してＦ２Ｆの連絡を行いたいと望んでいる場合である。
ステップＳ８０２では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行うとともに、端末１８０の利用者が端末１００Ａ、端末１００Ｃ、端末１００Ｄの利用者との連絡方法として望んでいるＦ２Ｆ８０２ａを送信する。

ステップＳ８０４では、プレゼンスサーバ１５０が端末１００Ａに対して通知するとともに、端末１８０の利用者が端末１００Ａの利用者との連絡方法として望んでいるＦ２Ｆ８０４ａを送信する。
ステップＳ８０６では、プレゼンスサーバ１５０が端末１００Ｃに対して通知するとともに、端末１８０の利用者が端末１００Ｃの利用者との連絡方法として望んでいるＦ２Ｆ８０６ａを送信する。
ステップＳ８０８では、プレゼンスサーバ１５０が端末１００Ｄに対して通知するとともに、端末１８０の利用者が端末１００Ｄの利用者との連絡方法として望んでいるＦ２Ｆ８０８ａを送信する。ステップＳ８０４からステップＳ８０８までの処理は、一斉同報（ブロードキャスト）してもよい。

ステップＳ８１０では、＜休止＞：端末１００Ａの利用者の状態は「お客様先での会議中」であり、Ｆ２Ｆ８０２ａは不可能なため、プレゼンスを送信しない。例えば、端末１００Ａ内の利用者状態取得モジュール１１０が、端末１００Ａの利用者の状態として「お客様先での会議中」を抽出し、判断モジュール１１５がＦ２Ｆに対応不可能であると判断し、通信制御モジュール１２０がプレゼンス登録要求を送信しないように制御したものである。
ステップＳ８１２では、＜休止＞：端末１００Ｃの利用者の状態は「外出先で徒歩移動中」であり、Ｆ２Ｆ８０２ａは不可能なため、プレゼンスを送信しない。例えば、端末１００Ｃ内の利用者状態取得モジュール１１０が、端末１００Ｃの利用者の状態として「外出先で徒歩移動中」を抽出し、判断モジュール１１５がＦ２Ｆに対応不可能であると判断し、通信制御モジュール１２０がプレゼンス登録要求を送信しないように制御したものである。

ステップＳ８１４では、端末１００Ｄがプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００Ｄの利用者の状態として拠点内自席８１４ａを送信する。例えば、端末１００Ｄ内の利用者状態取得モジュール１１０が、端末１００Ｄの利用者の状態として拠点内自席８１４ａを抽出し、判断モジュール１１５がＦ２Ｆに対応可であると判断し、通信制御モジュール１２０がプレゼンス登録要求を送信するように制御したものである。
ステップＳ８１６では、プレゼンスサーバ１５０が端末１８０に対して、プレゼンス通知を行うとともに、端末１００Ｄの利用者の状態として拠点内自席８１６ａを送信する。
この例では、Ｆ２Ｆが成立する利用者の端末（端末１００Ｄ）のみプレゼンス登録要求の通信が行われ、通信回数が抑制されている。

図９は、第２の実施の形態の構成例についての概念的なモジュール構成図である。図９に例示の第２の実施の形態は、図１に例示の第１の実施の形態の端末１８０に利用者状態取得モジュール１９２、判断モジュール１９４を付加したものである。なお、第１の実施の形態と同種の部位には同一符号を付し重複した説明を省略する（以下、同様）。端末１８０の利用者の状態も取得して、連絡方法を伴ったプレゼンス利用要求を行った後に、端末１８０の利用者がその連絡方法に対応不可能の状態になった場合は、プレゼンス利用要求を取りやめるようにしたものである。
端末１８０は、通信モジュール１８５、プレゼンス確認モジュール１９０、利用者状態取得モジュール１９２、判断モジュール１９４を有している。
通信モジュール１８５は、携帯可能な端末１００に対して、端末１００の利用者における状態を問い合わせる通知とともに連絡方法を送信する。
利用者状態取得モジュール１９２は、携帯可能な本端末１８０の利用者の状態を取得する。端末１００の利用者状態取得モジュール１１０と同等の処理を行い、端末１８０の利用者の状態を取得する。
判断モジュール１９４は、通信モジュール１８５によって通知が送信された後に、利用者状態取得モジュール１９２によって取得された状態が、連絡方法を行うことができない状態であるか否かを判断する。端末１００の判断モジュール１１５と同等の処理を行い、端末１８０の利用者の状態は連絡方法に対応可能であるか否かを判断する。
通信モジュール１８５は、判断モジュール１９４によって連絡方法を行うことができない状態であると判断された場合は、問い合わせを取りやめる通知を端末１００へ送信する。

図１０は、第２の実施の形態による処理例を示すフローチャートである。
ステップＳ１００２では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行うとともに、端末１８０の利用者が端末１００の利用者との連絡方法として望んでいるＦ２Ｆ１００２ａを送信する。
ステップＳ１００４では、プレゼンスサーバ１５０が端末１００に対して通知するとともに、端末１８０の利用者が端末１００の利用者との連絡方法として望んでいるＦ２Ｆ１００４ａを送信する。
ステップＳ１００６では、＜休止＞：端末１００の利用者の状態は「お客様先での会議中」であり、Ｆ２Ｆ１００２ａは不可能なため、プレゼンスを送信しない。ここまでの処理は、第１の実施の形態による処理と同等である。

ステップＳ１００８では、端末１８０の利用者の状態が「外出先で徒歩移動中」に変化したため、Ｆ２Ｆ１００２ａの連絡は不可と判断する。例えば、端末１８０内の利用者状態取得モジュール１９２が、端末１８０の利用者の状態として「外出先で徒歩移動中」を抽出し、判断モジュール１９４がＦ２Ｆに対応不可能であると判断したものである。
ステップＳ１０１０では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用の取り消し要求を行う。
ステップＳ１０１２では、プレゼンスサーバ１５０が端末１００に対して、プレゼンス利用の取り消しを通知する。
ステップＳ１０１４では、端末１００側の利用者はＦ２Ｆ可能になったが、端末１８０側の状態が変わり、プレゼンス利用の取り消しとなり、プレゼンス登録要求の通信は不要となる。

図１１は、第３の実施の形態の構成例についての概念的なモジュール構成図である。図１１に例示の第３の実施の形態は、図１に例示の第１の実施の形態の端末１００から判断モジュール１１５、通信制御モジュール１２０を不要とし、プレゼンスサーバ１５０に通知先利用者状態取得モジュール１７２、判断モジュール１７４を付加したものである。前述の端末１００、端末１８０で行われていた判断処理等をプレゼンスサーバ１５０で行うようにしたものである。これによって、端末１００、端末１８０が対応不可能の場合であってもプレゼンスサーバ１５０に対してプレゼンス登録要求等の通信は行われるが、プレゼンスサーバ１５０によって対応不可能と判断された場合の不要なプレゼンス通知の通信は行われないことになる。

端末１００は、通信モジュール１０５、利用者状態取得モジュール１１０を有している。
端末１８０は、通信モジュール１８５、プレゼンス確認モジュール１９０を有している。
プレゼンスサーバ１５０は、通信モジュール１５５、プレゼンス制御モジュール１６０、利用者管理モジュール１６５、プレゼンス状態管理モジュール１７０、通知先利用者状態取得モジュール１７２、判断モジュール１７４、プレゼンス状態記憶モジュール１７５を有している。
通信モジュール１５５は、携帯可能な端末１８０から携帯可能な端末１００の利用者における状態を問い合わせる通知を受け付ける。そして、その通知が受け付けられた場合は、端末１００に対して、その通知を送信する。通信モジュール１５５は、端末１００へ送信した通知の応答として、端末１００の利用者における状態を受け付ける。
また通信モジュール１５５は、端末１８０からの連絡方法を受信するようにしてもよい。

通知先利用者状態取得モジュール１７２は、端末１００又は端末１８０の利用者の状態を取得する。前述の利用者状態取得モジュール１１０と同等の処理を行う。ただし、端末１００内の各種センサーの出力を受け取り、通知先利用者状態取得モジュール１７２が端末１００の利用者の状態を認識してもよい。
判断モジュール１７４は、通信モジュール１５５によって受け付けられた端末１００の利用者における状態が、端末１８０からの要求に対応可能であるか否かを判断する。
また判断モジュール１７４は、通信モジュール１５５によって通知が受け付けられた場合は、端末１００の利用者における状態が、通信モジュール１５５によって受け付けられた連絡方法に対応可能であるか否かを判断するようにしてもよい。
プレゼンス制御モジュール１６０は、判断モジュール１７４によって対応可能でないと判断された場合は、端末１００の利用者における状態を端末１８０に送信しないように、通信モジュール１５５を制御する。また、プレゼンス制御モジュール１６０は、判断モジュール１７４によって対応可能であると判断された場合にのみ、通信モジュール１５５によって受け付けられた通知の返信として、端末１００の利用者における状態を端末１８０に送信するように、通信モジュール１５５を制御するようにしてもよい。
また、プレゼンス制御モジュール１６０は、判断モジュール１７４によって対応可能でないと判断された場合は、端末１００の利用者における状態を端末１８０には送信しないように制御するようにしてもよい。又は、プレゼンス制御モジュール１６０は、判断モジュール１７４によって対応可能でないと判断された場合は、端末１００に対しては通知を送信しないように制御するようにしてもよい。

図１２は、第３の実施の形態による処理例を示すフローチャートである。
ステップＳ１２０２では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行うとともに、端末１８０の利用者が端末１００Ａ、端末１００Ｃ、端末１００Ｄの利用者との連絡方法として望んでいるＦ２Ｆ１２０２ａを送信する。
ステップＳ１２０４では、プレゼンスサーバ１５０が端末１００Ａに対して通知するとともに、端末１８０の利用者が端末１００Ａの利用者との連絡方法として望んでいるＦ２Ｆ１２０４ａを送信する。
ステップＳ１２０６では、プレゼンスサーバ１５０が端末１００Ｃに対して通知するとともに、端末１８０の利用者が端末１００Ｃの利用者との連絡方法として望んでいるＦ２Ｆ１２０６ａを送信する。
ステップＳ１２０８では、プレゼンスサーバ１５０が端末１００Ｄに対して通知するとともに、端末１８０の利用者が端末１００Ｄの利用者との連絡方法として望んでいるＦ２Ｆ１２０８ａを送信する。ステップＳ１２０４からステップＳ１２０８までの処理は、一斉同報（ブロードキャスト）してもよい。

ステップＳ１２１０では、端末１００Ａがプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００Ａの利用者の状態としてお客様先で会議中１２１０ａを送信する。
ステップＳ１２１２では、端末１００Ｃがプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００Ｃの利用者の状態として外出先で徒歩移動中１２１２ａを送信する。
ステップＳ１２１４では、端末１００Ｄがプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００Ｄの利用者の状態として拠点内自席１２１４ａを送信する。
ステップＳ１２１６では、プレゼンスサーバ１５０が端末１８０に対して、プレゼンス通知を行うとともに、端末１００Ｄの利用者の状態として拠点内自席１２１６ａを送信する。つまり、通知先利用者状態取得モジュール１７２が、ステップＳ１２１０からステップＳ１２１４で取得した端末１００Ａ、端末１００Ｃ、端末１００Ｄの利用者における状態を取得し、連絡方法別対応不可能状態テーブル１５００を用いて、Ｆ２Ｆ１２０２ａに対応可能である端末１００Ｄが選択されて、端末１８０に送信する。
この処理例では、端末１００Ａ、端末１００Ｃ、端末１００Ｄのそれぞれからプレゼンス利用要求の返信であるプレゼンス登録要求の通信が行われるが、端末１８０からの連絡方法「Ｆ２Ｆ」に対応可能である利用者の端末１００Ｄだけが、プレゼンスサーバ１５０から端末１８０へ送信されている。

図１３は、第３の実施の形態による処理例を示すフローチャートである。
ステップＳ１３０２では、端末１８０がプレゼンスサーバ１５０に対して、プレゼンス利用要求を行うとともに、端末１８０の利用者が端末１００Ａ、端末１００Ｃ、端末１００Ｄの利用者との連絡方法として望んでいるＦ２Ｆ１３０２ａを送信する。プレゼンスサーバ１５０の通知先利用者状態取得モジュール１７２は、端末１００Ａ、端末１００Ｃ、端末１００Ｄの各利用者における状態を取得する。例えば、各利用者の電子的なスケジュール帳から現在の予定を取得する。判断モジュール１７４は、連絡方法別対応不可能状態テーブル１５００を用いて、端末１００Ｃ、端末１００Ｄの利用者はＦ２Ｆ１３０２ａに対応可能であると判断する。したがって、プレゼンス制御モジュール１６０は、端末１００Ｃ、端末１００Ｄに対しては通知を行うように通信モジュール１５５を制御するが、端末１００Ａに対しては通知を行わないように通信モジュール１５５を制御する。
ステップＳ１３０４では、プレゼンスサーバ１５０が端末１００Ｃに対して通知するとともに、端末１８０の利用者が端末１００Ｃの利用者との連絡方法として望んでいるＦ２Ｆ１３０４ａを送信する。
ステップＳ１３０６では、プレゼンスサーバ１５０が端末１００Ｄに対して通知するとともに、端末１８０の利用者が端末１００Ｄの利用者との連絡方法として望んでいるＦ２Ｆ１３０６ａを送信する。

ステップＳ１３０８では、端末１００Ｃがプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００Ｃの利用者の状態として外出先で徒歩移動中１３０８ａを送信する。
ステップＳ１３１０では、端末１００Ｄがプレゼンスサーバ１５０に対して、プレゼンス登録要求を行うとともに、端末１００Ｄの利用者の状態として拠点内自席１３１０ａを送信する。
ステップＳ１３１２では、プレゼンスサーバ１５０が端末１８０に対して、プレゼンス通知を行うとともに、端末１００Ｄの利用者の状態として拠点内自席１３１２ａを送信する。つまり、通知先利用者状態取得モジュール１７２が、ステップＳ１３０８からステップＳ１３１０で取得した端末１００Ｃ、端末１００Ｄの利用者における状態を取得し、連絡方法別対応不可能状態テーブル１５００を用いて、Ｆ２Ｆ１３０２ａに対応可能である端末１００Ｄが選択されて、端末１８０に送信する。
この処理例では、端末１００Ａには通知も行われない。そして、端末１００Ｃ、端末１００Ｄのそれぞれからプレゼンス利用要求の返信であるプレゼンス登録要求の通信が行われるが、端末１８０からの連絡方法「Ｆ２Ｆ」に対応可能である利用者の端末１００Ｄだけが、プレゼンスサーバ１５０から端末１８０へ送信されている。

なお、本実施の形態（端末１００、プレゼンスサーバ１５０、端末１８０）としてのプログラムが実行されるコンピュータのハードウェア構成は、図１６に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ１６０１を用い、記憶装置としてＲＡＭ１６０２、ＲＯＭ１６０３、ＨＤ１６０４を用いている。ＨＤ１６０４として、例えばハードディスクを用いてもよい。通信モジュール１０５、利用者状態取得モジュール１１０、判断モジュール１１５、通信制御モジュール１２０、通信モジュール１５５、プレゼンス制御モジュール１６０、プレゼンス状態管理モジュール１７０、通信モジュール１８５、プレゼンス確認モジュール１９０、利用者状態取得モジュール１９２、判断モジュール１９４、通知先利用者状態取得モジュール１７２、判断モジュール１７４等のプログラムを実行するＣＰＵ１６０１と、そのプログラムやデータを記憶するＲＡＭ１６０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ１６０３と、補助記憶装置であるＨＤ１６０４と、キーボード、マウス、タッチパネル等に対する利用者の操作に基づいてデータを受け付ける受付装置１６０６と、ＣＲＴ、液晶ディスプレイ等の出力装置１６０５と、ネットワークインタフェースカード等の通信ネットワークと接続するための通信回線インタフェース１６０７、そして、それらをつないでデータのやりとりをするためのバス１６０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。

前述の実施の形態では、端末１００、端末１８０のいずれも携帯可能な端末の例を示したが、依頼受け側である端末１００、又は依頼側である端末１８０の少なくとも一方が携帯可能な情報処理装置であればよい。一方が携帯可能な情報処理装置であり、他方が携帯可能でない情報処理装置である場合（端末１００が携帯可能である場合は端末１８０、端末１８０が携帯可能である場合は端末１００）、携帯可能でない情報処理装置として、例えば、デスクトップＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）のような据え置き型の情報処理装置としてもよい。例えば、前述の実施の形態で、端末内のセンサーを用いて利用者の状態を取得する場合は、その端末側が携帯可能であれば、他方の端末は携帯可能でなくてもよい。

前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図１６に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図１６に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えばＡＳＩＣ等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続しているような形態でもよく、さらに図１６に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、情報家電、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。

前述の実施の形態においては、図１４に例示した対応不可能状態リスト１４００、図１５に例示した連絡方法別対応不可能状態テーブル１５００は、対応不可能の場合の条件を記憶しているが、対応可能な条件を記憶していてもよい。その場合は、対応可能か否かの判断は、前述の場合と逆になる。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通などのために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラム又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、あるいは無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して
記録されていてもよい。また、圧縮や暗号化など、復元可能であればどのような態様で記録されていてもよい。

１００…端末
１０５…通信モジュール
１１０…利用者状態取得モジュール
１１５…判断モジュール
１２０…通信制御モジュール
１５０…プレゼンスサーバ
１５５…通信モジュール
１６０…プレゼンス制御モジュール
１６５…利用者管理モジュール
１７０…プレゼンス状態管理モジュール
１７２…通知先利用者状態取得モジュール
１７４…判断モジュール
１７５…プレゼンス状態記憶モジュール
１８０…端末
１８５…通信モジュール
１９０…プレゼンス確認モジュール
１９２…利用者状態取得モジュール
１９４…判断モジュール
１９９…通信回線
２００…端末
２５０…プレゼンスサーバ
２９９…通信回線

Claims (12)

1. 他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知とともに連絡方法を送信する第１の送信手段と、
   本情報処理装置の利用者の状態を取得する取得手段と、
   前記第１の送信手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記連絡方法を行うことができない状態であるか否かを判断する判断手段と、
   前記判断手段によって前記連絡方法を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を送信する第２の送信手段
   を具備することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置と、
   請求項１に記載の情報処理装置を他の情報処理装置とし、該他の情報処理装置から本第２の情報処理装置の利用者における状態を問い合わせる通知を受け付ける受付手段と、
   前記受付手段によって通知が受け付けられた場合は、前記利用者における状態が、前記他の情報処理装置からの連絡に対応可能であるか否かを判断する第２の判断手段と、
   前記第２の判断手段によって対応可能でないと判断された場合は、前記利用者における状態を送信しないように制御する送信制御手段
   を具備する第２の情報処理装置
   を具備することを特徴とする情報処理システム。
3. 前記送信制御手段は、前記第２の判断手段によって対応可能であると判断された場合にのみ、前記受付手段によって受け付けられた通知の返信として、前記利用者における状態を送信するように制御する
   ことを特徴とする請求項２に記載の情報処理システム。
4. 前記受付手段は、前記他の情報処理装置からの連絡方法を受信し、
   前記第２の判断手段は、前記受付手段によって通知が受け付けられた場合は、前記利用者における状態が、該受付手段によって受け付けられた前記連絡方法に対応可能であるか否かを判断する
   ことを特徴とする請求項２又は３に記載の情報処理システム。
5. 前記受付手段は、前記通知を受け付けた後に、前記他の情報処理装置から該通知の取消要求を受け付け、
   前記送信制御手段は、前記受付手段によって取消要求が受け付けられた場合は、前記利用者における状態を送信しないように制御する
   ことを特徴とする請求項２から４のいずれか一項に記載の情報処理システム。
6. 前記送信制御手段は、前記第２の判断手段による判断結果が、対応可能でないとの判断から対応可能であるとの判断に変更された場合は、前記利用者における状態を送信するように制御する
   ことを特徴とする請求項２から４のいずれか一項に記載の情報処理システム。
7. 請求項１に記載の情報処理装置と、
   請求項２から６のいずれか一項に記載の情報処理システムにおける第２の情報処理装置と、
   請求項１に記載の情報処理装置を第１の情報処理装置とし、該第１の情報処理装置から前記第２の情報処理装置の利用者における状態を問い合わせる通知を受け付ける第２の受付手段と、
   前記第２の受付手段によって通知が受け付けられた場合は、前記第２の情報処理装置に対して該通知を送信する第３の送信手段と、
   前記第３の送信手段によって送信した通知の応答として、前記第２の情報処理装置の利用者における状態を受け付ける第３の受付手段と、
   前記第３の受付手段によって受け付けられた前記利用者における状態が、前記第１の情報処理装置からの要求に対応可能であるか否かを判断する第３の判断手段と、
   前記第３の判断手段によって対応可能でないと判断された場合は、前記利用者における状態を前記第１の情報処理装置に送信しないように制御する第２の送信制御手段
   を具備する第３の情報処理装置
   を具備することを特徴とする情報処理システム。
8. 前記第２の送信制御手段は、前記第３の判断手段によって対応可能であると判断された場合にのみ、前記第２の受付手段によって受け付けられた通知の返信として、前記利用者における状態を前記第１の情報処理装置に送信するように制御する
   ことを特徴とする請求項７に記載の情報処理システム。
9. 前記第２の受付手段は、前記第１の情報処理装置からの連絡方法を受信し、
   前記第２の受付手段によって通知が受け付けられた場合は、前記第２の情報処理装置の利用者における状態が、該第２の受付手段によって受け付けられた前記連絡方法に対応可能であるか否かを判断する第４の判断手段と、
   前記第４の判断手段によって対応可能でないと判断された場合は、前記利用者における状態を前記第１の情報処理装置には送信しないように制御する、又は、前記第２の情報処理装置に対しては前記通知を送信しないように制御する第３の送信制御手段
   を前記第３の情報処理装置が具備する
   ことを特徴とする請求項７又は８に記載の情報処理システム。
10. 情報処理装置であるコンピュータを、
    他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知とともに連絡方法を送信する第１の送信手段と、
    本情報処理装置の利用者の状態を取得する取得手段と、
    前記第１の送信手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記連絡方法を行うことができない状態であるか否かを判断する判断手段と、
    前記判断手段によって前記連絡方法を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を送信する第２の送信手段
    として機能させるための情報処理プログラム。
11. 他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知を行う第１の通知手段と、
    本情報処理装置の利用者の状態を取得する取得手段と、
    前記第１の通知手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記他の情報処理装置に対して連絡を行うことができない状態であるか否かを判断する判断手段と、
    前記判断手段によって前記連絡を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を行う第２の通知手段
    を具備することを特徴とする情報処理装置。
12. 情報処理装置であるコンピュータを、
    他の情報処理装置に対して、該他の情報処理装置の利用者における状態を問い合わせる通知を行う第１の通知手段と、
    本情報処理装置の利用者の状態を取得する取得手段と、
    前記第１の通知手段によって通知が送信された後に、前記取得手段によって取得された状態が、前記他の情報処理装置に対して連絡を行うことができない状態であるか否かを判断する判断手段と、
    前記判断手段によって前記連絡を行うことができない状態であると判断された場合は、前記問い合わせを取りやめる通知を行う第２の通知手段
    として機能させるための情報処理プログラム。

Images