(57)【要約】  【課題】  ネットワークに接続された機器またはユーザの状態通知を行う際に、不要な通知を減らし、サーバの処理負荷を軽減することを可能とする通知装置、被通知装置および状態通知方法を提供すること。  【解決手段】  管理者端末１０３がプレゼンスサーバ装置１００に通知要求をする際に、装置の状態の継続時間、または状態が変化した時刻、状態の変化履歴で示された状態変化条件を指定する。プレゼンスサーバ装置１００は状態変化条件を満たす場合にだけ通知を行う。【選択図】 図１
2006246065.tif 000002
【特許請求の範囲】
【請求項１】
時間の経過に応じて様々な状態をとりうる状態発行体が同一の状態を継続している時間を表す状態継続時間情報、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻情報、および前記状態発行体の変化の履歴を表す変化履歴情報の少なくとも一つを含む状態変化情報を保存する状態変化情報保存手段と、
状態変化条件を設定する状態変化条件設定手段と、
前記状態変化情報保存手段に保存された前記状態変化情報と前記状態変化条件設定手段により設定された前記状態変化条件とに基づいて前記発行体の状態が変化したか否かを判定する状態変化判定手段と、
前記状態変化判定手段によって前記発行体の状態が変化したと判定した場合に、状態変化を通知する状態変化通知パケットを送信する状態変化通知情報送信手段とを備えた通知装置。
【請求項２】
前記状態変化情報保存手段は、前記状態継続時間を保存し、
前記状態変化条件設定手段は、前記状態継続時間を指定する状態継続時間条件を設定し、
前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態継続時間情報と前記状態変化条件設定手段により設定された前記状態継続時間条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１に記載の通知装置。
【請求項３】
前記状態変化情報保存手段は、前記状態変化時刻を保存し、
前記状態変化条件設定手段は、前記状態変化時刻の範囲を指定する状態変化時刻条件を設定し、
前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態変化時刻情報と前記状態変化条件設定手段により設定された前記状態変化時刻条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１に記載の通知装置。
【請求項４】
前記状態変化情報保存手段はさらに、少なくとも１つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を保存し、
前記状態変化条件設定手段はさらに、前記状態項目と前記状態項目の前記状態値を指定する前記状態項目の状態値条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態項目と前記状態項目の前記状態値情報と前記状態変化条件設定手段により設定された前記状態項目と前記状態項目の前記状態値条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項２または請求項３に記載の通知装置。
【請求項５】
前記状態変化情報保存手段は、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化の履歴を表す変化履歴情報を保存し、
前記状態変化条件設定手段は、前記状態項目と前記状態項目の前記状態値の変化を指定する履歴条件を設定し、
前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態項目と前記状態項目の前記状態値の変化の履歴を表す前記変化履歴情報と前記状態変化条件設定手段により設定された前記状態項目と前記状態項目の前記状態値の前記変化履歴条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１に記載の通知装置。
【請求項６】
前記状態変化情報保存手段は、複数の状態発行体それぞれの複数の状態変化情報を保存し、
前記状態変化条件設定手段は、前記複数の状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を設定し、
前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記複数の状態変化情報と、前記状態変化条件設定手段により設定された前記複数の状態変化条件間の論理条件とに基づいて前記複数の状態発行体の前記発行体の状態が変化したか否かを判定することを特徴とする請求項１から請求項５までの何れかに記載の通知装置。
【請求項７】
さらに、前記状態変化条件を示す変化条件情報パケットを受信する変化条件情報受信手段を備え、前記状態変化条件設定手段は、前記変化条件情報受信手段により受信された前記変化条件情報パケットに基づいて前記状態変化条件を設定することを特徴とする請求項１から請求項６までの何れかに記載の通知装置。
【請求項８】
前記状態発行体は前記通知装置を含み、前記状態変化条件設定手段は、少なくとも前記通知装置自体の状態変化情報を設定することを特徴とする請求項１から請求項７までの何れかに記載の通知装置。
【請求項９】
前記状態変化通知情報送信手段は、前記状態変化通知パケットをＳＩＰ(Session Initiation Protocol)プロトコルに準拠して送信することを特徴とする請求項１から請求項８までの何れかに記載の通知装置。
【請求項１０】
時間の経過に応じて様々な状態をとりうる状態発行体の前記状態を通知する通知装置とネットワークを介して接続され、前記通知装置から前記状態発行体の前記状態を示す状態通知パケットを受信する状態情報受信手段と、
前記状態発行体が同一の状態を継続している時間を表す状態継続時間、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻、および前記状態発行体の変化の履歴を表す変化履歴の少なくとも一つを設定する状態変化条件を通知する変化条件情報パケットを送信する変化条件送信手段とを備えた被通知装置。
【請求項１１】
前記変化条件送信手段は、前記状態継続時間を指定する変化条件情報パケットを送信することを特徴とする請求項１０に記載の被通知装置。
【請求項１２】
前記変化条件送信手段は、前記状態変化時刻を指定する変化条件情報パケットを送信することを特徴とする請求項１０に記載の被通知装置。
【請求項１３】
前記変化条件送信手段はさらに、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を指定する変化条件情報パケットを送信することを特徴とする請求項１１または請求項１２に記載の被通知装置。
【請求項１４】
前記変化条件送信手段は、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化を指定する変化条件情報パケットを送信することを特徴とする請求項１０に記載の被通知装置。
【請求項１５】
前記変化条件送信手段は、複数状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を指定する変化条件情報パケットを送信することを特徴とする請求項１０から請求項１４までの何れかに記載の被通知装置。
【請求項１６】
前記変化条件送信手段は、少なくとも前記通知装置の状態変化条件を指定する変化条件情報パケットを送信することを特徴とする請求項１０から請求項１５までの何れかに記載の被通知装置。
【請求項１７】
前記変化条件送信手段は、前記変化条件情報パケットをＳＩＰプロトコルに準拠して送信することを特徴とする請求項１０から請求項１６までの何れかに記載の被通知装置。
【請求項１８】
時間の経過に応じて様々な状態をとりうる状態発行体が同一の状態を継続している時間を表す状態継続時間情報、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻情報、および前記状態発行体の変化の履歴を表す変化履歴情報の少なくとも一つを含む状態変化情報を保存する状態変化情報保存ステップと、
状態変化条件を設定する状態変化条件設定ステップと、
前記状態変化情報保存ステップで保存された前記状態変化情報と前記状態変化条件設定ステップにより設定された前記状態変化条件とに基づいて前記発行体の状態が変化したか否かを判定する状態変化判定ステップと、
前記状態変化判定ステップが前記発行体の状態が変化したと判定した場合に、状態変化を通知する状態変化通知パケットを送信する状態変化通知パケット送信ステップとを備えた状態通知方法。
【請求項１９】
前記状態変化情報保存ステップは、前記状態継続時間を保存し、
前記状態変化条件設定ステップは、前記状態継続時間を指定する状態継続時間条件を設定し、
前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態継続時間情報と前記状態変化条件設定ステップにより設定された前記状態継続時間条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８に記載の状態通知方法。
【請求項２０】
前記状態変化情報保存ステップは、前記状態変化時刻を保存し、
前記状態変化条件設定ステップは、前記状態変化時刻の範囲を指定する状態変化時刻条件を設定し、
前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態変化時刻情報と前記状態変化条件設定ステップにより設定された前記状態変化時刻条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８に記載の状態通知方法。
【請求項２１】
前記状態変化情報保存ステップは、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を保存し、
前記状態変化条件設定ステップは、前記状態項目と前記状態項目の前記状態値を指定する前記状態項目の状態値条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態項目と前記状態項目の前記状態値情報と前記状態変化条件設定ステップにより設定された前記状態項目と前記状態項目の前記状態値条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項２０または請求項２１に記載の状態通知方法。
【請求項２２】
前記状態変化情報保存ステップは、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化の履歴を表す変化履歴情報を保存し、
前記状態変化条件設定ステップは、前記状態項目と前記状態項目の前記状態値の変化を指定する履歴条件を設定し、
前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態項目と前記状態項目の前記状態値の変化の履歴を表す前記変化履歴情報と前記状態変化条件設定ステップにより設定された前記状態項目と前記状態項目の前記状態値の前記変化履歴条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８に記載の状態通知方法。
【請求項２３】
前記状態変化情報保存ステップは、複数の状態発行体それぞれの複数の状態変化情報を保存し、
前記状態変化条件設定ステップは、前記複数の状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を設定し、
前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記複数の状態変化情報と、前記状態変化条件設定ステップにより設定された前記複数の状態変化条件間の論理条件とに基づいて前記複数の状態発行体の前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８から請求項２２までの何れかに記載の状態通知方法。
【請求項２４】
さらに、前記状態変化条件を示す変化条件情報パケットを受信する変化条件情報パケット受信ステップを備え、前記状態変化条件設定ステップは、前記変化条件情報パケット受信ステップにより受信された前記変化条件情報パケットに基づいて前記状態変化条件を設定することを特徴とする請求項１８から請求項２３までの何れかに記載の状態通知方法。
【請求項２５】
前記状態発行体は状態を通知する通知装置前記状態通知方法をを含み、前記状態変化条件設定ステップは、少なくとも前記状態通知装置方法自体の状態変化情報を設定することを特徴とする請求項１８から請求項２４までの何れかに記載の状態通知方法。
【請求項２６】
前記状態変化通知パケット送信ステップは、前記状態変化通知パケットをＳＩＰプロトコルに準拠して送信することを特徴とする請求項１８から請求項２５までの何れかに記載の状態通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置またはユーザの状態を通知する装置および方法に関し、特に装置またはユーザの状態の状態継続時間、状態変化時刻、状態変化履歴が所定の条件を満たすときに限り状態の通知を行う通知装置、被通知装置および状態通知方法に関する。
【背景技術】
【０００２】
近年、通信相手の接続状態(オンライン/オフライン)を知ることができるプレゼンスサービスがＩＭ(Instant Message)などで実用化されている。また、企業におけるプレゼンスサービスとしては、通信相手の在席状態(在席/不在)をネットワーク経由で通知するサービスが普及しつつある。
【０００３】
このようなサービスを提供するための一つの方法として、ＳＩＰ(Session Initiation Protocol)プロトコルに準拠したＳＩＰイベント通知機能がある（非特許文献１参照）。ＳＩＰイベント通知機能を使って企業におけるプレゼンスサービスを実現する場合は、社員の状態を管理するプレゼンスサーバを設置し、社員の状態が変化したら、状態通知要求をしている機器に向けて状態変化通知を送信する。
【０００４】
図３４は従来のＳＩＰイベント通知機能を使ったプレゼンスサービスにおけるネットワーク構成の一例を示す図である。パーソナルコンピュータ（以後、「ＰＣ」という）７０１〜７０４は社内ＬＡＮ（Local Area Network）７１０を介して接続されており、ＰＣを使用するユーザのプレゼンス状態(在席/不在)の状態を取得している。プレゼンスサーバ装置７００はＰＣ７０１〜７０４を使用するユーザの状態を管理し、ユーザの状態に変化があった場合は状態通知要求をしている機器に向けて状態変化を通知する。例えばＰＣ７０１の状態が「在席」から「不在」に変化した場合は、ＰＣ７０１はプレゼンスサーバ装置７００に「不在」という状態を登録する。ＰＣ７０４がＰＣ７０１の状態通知要求をしていると、プレゼンスサーバ装置１００はＰＣ７０１の状態を「在席」から「不在」に更新した後、ＰＣ７０１の状態通知要求をしているＰＣ７０４に対して状態変化を通知する。
【０００５】
このような状態変化の通知に使われるＳＩＰプロトコルに準拠したメッセージについて図３５を参照して説明する。図３５はＳＩＰプロトコルに準拠したプレゼンスサービスにおけるメッセージフローの一例を示す図である。ＰＣ７０１は自装置のユーザの状態を記述したPUBLISHメッセージをプレゼンスサーバに送信し、現在のユーザの状態をプレゼンスサーバ７０１に登録する。プレゼンスサーバ装置７００はPUBLISHメッセージを受信してＰＣ７０１のユーザの状態を登録すると200 OK応答を返す。ＰＣ７０４はＰＣ７０１の状態通知を要求するために、ＰＣ７０１のＵＲＩを記述したSUBSCRIBEメッセージをプレゼンスサーバ装置７００に送信する。プレゼンスサーバ装置７００はSUBSCRIBEメッセージを受信し通知要求を受け入れると、200 OK応答を返す。その後、プレゼンスサーバ装置７００はＰＣ７０１のユーザの状態を記述したNOTIFYメッセージをＰＣ７０４に送信する。ＰＣ７０４はNOTIFYメッセージを受信し、ＰＣ７０１のユーザの状態を取得するとプレゼンスサーバ装置７００に対して200 OK応答を返す。その後、ＰＣ７０１は自装置のユーザの状態が変化するたびにプレゼンスサーバ装置７００にPUBLISHメッセージを送信する。プレゼンスサーバ装置７００はＰＣ７０１からのPUBLISHメッセージを受信すると、ＰＣ７０１の状態を記述したNOTIFYメッセージをＰＣ７０４に送信する。
【０００６】
このようにＳＩＰイベント通知機能を使うことによって、プレゼンスサービスに代表される状態通知サービスを実現できる。さらに今後はネットワークに接続された全ての機器の状態を通知するサービスの実用化も予想される。ところが通知する状態や機器が増えることで状態を管理するサーバにおける処理負荷の増大が問題となり、負荷軽減を図る必要が生じる。
【０００７】
従来の処理負荷の軽減方法としては、例えばＩＥＴＦ(Internet Engineering Task Force)のＳＩＭＰＬＥ(ＳＩＰ for Instant Messaging and Presence Leveraging Extensions)ワーキンググループで提案されているイベントフィルタがある。イベントフィルタについて図３６を参照して説明する。図３６はイベントフィルタのメッセージフローの一例を示す図である。
【０００８】
イベントフィルタでは機器を使用するユーザが指定された状態になったときだけNOTIFYメッセージを送信することが可能となる。ＰＣ７０４はSUBSCRIBEメッセージを送信する際に、NOTIFYメッセージを生成する条件をSUBSCRIBEメッセージのボディ部に記述する。この例では「ＰＣ７０１を使用するユーザが不在になったときだけ通知」という条件を記述しておく。なお、実際の条件の記述はＸＭＬ (Extensible Markup Ｌanguage)が使われるが、ここでは詳細な説明を省略する。プレゼンスサーバ装置７００はSUBSCRIBEメッセージを受信すると、ＰＣ７０１を使用するユーザの状態を記述したNOTIFYメッセージをＰＣ７０４に送信する。SUBSCRIBEメッセージ受信後、最初に送信されるNOTIFYメッセージについては、SUBSCRIBEメッセージに記述された条件を満たさないに場合でも送信される。
【０００９】
その後プレゼンスサーバ装置７００は、「在席」という状態を登録するPUBLISHメッセージを受信した場合はNOTIFYメッセージを送信せず、「不在」という状態を登録するPUBLISHメッセージを受信した場合にのみＰＣ７０４にNOTIFYメッセージを送信する。
【００１０】
このようにイベントフィルタはＰＣ７０４が指定した条件を満たすときだけNOTIFYメッセージを送信するので不要なNOTIFYメッセージトラヒックが減り、ネットワークリソースを有効に利用できるとともにプレゼンスサーバ装置７００のNOTIFYメッセージ送信に関わる処理負荷を軽減することができる。
【非特許文献１】Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ｓｉｐ）、２００５年２月２４日、〔平成１７年２月２４日検索〕、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｓｉｐ−ｃｈａｒｔｅｒ．ｈｔｍｌ＞
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら上述した従来のイベントフィルタでは、装置または装置を使用するユーザの現在の状態だけが指定可能であり、状態が継続した時間や、状態が変化した時刻を指定することが不可能であった。このため、例えばユーザが１０分以上「不在」状態となった場合にだけ通知、というような指定ができず、不要なNOTIFYメッセージが送信されていた。また、指定可能な条件として装置またはユーザの状態変化履歴を指定することも従来のイベントフィルタでは不可能であった。例えば、ユーザの居場所を示す状態が「休憩室→喫煙室→休憩室」と変化した場合にだけ通知、というような指定もイベントフィルタは不可能であり、不要なNOTIFYメッセージが送信されていた。
【００１２】
本発明は係る点に鑑みてなされたものであり、ネットワークに接続された装置の状態を通知する際に、不要な通知を減らすことにより、ネットワークリソースを有効に利用できるとともにプレゼンスサーバの処理負担を軽減することができる通知装置、被通知装置および状態通知方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
第１の発明の通知装置は、時間の経過に応じて様々な状態をとりうる状態発行体が同一の状態を継続している時間を表す状態継続時間情報、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻情報、および前記状態発行体の変化の履歴を表す変化履歴情報の少なくとも一つを含む状態変化情報を保存する状態変化情報保存手段と、状態変化条件を設定する状態変化条件設定手段と、前記状態変化情報保存手段に保存された前記状態変化情報と前記状態変化条件設定手段により設定された前記状態変化条件とに基づいて前記発行体の状態が変化したか否かを判定する状態変化判定手段と、前記状態変化判定手段によって前記発行体の状態が変化したと判定した場合に、状態変化を通知する状態変化通知パケットを送信する状態変化通知情報送信手段とを備える構成を有している。
【００１４】
この構成により、本発明の通知装置は、指定された状態の継続時間、状態の変化時刻、または変化の履歴の少なくとも一つにより表される状態の変化に応じて状態を通知するか否かをより詳細に判定することができるため、不要な通知を減らし、ネットワークリソースを有効に利用できるとともに通知装置および被通知装置の送受信に関わる処理負担を軽減できる。
【００１５】
また、本発明の通知装置において、前記状態変化情報保存手段は、前記状態継続時間を保存し、前記状態変化条件設定手段は、前記状態継続時間を指定する状態継続時間条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態継続時間情報と前記状態変化条件設定手段により設定された前記状態継続時間条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００１６】
この構成により、本発明の通知装置は、状態変化条件として状態が継続した時間を指定することが可能となる。例えば「１分以上同一の継続した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００１７】
また、本発明の通知装置において、前記状態変化情報保存手段は、前記状態変化時刻を保存し、前記状態変化条件設定手段は、前記状態変化時刻の範囲を指定する状態変化時刻条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態変化時刻情報と前記状態変化条件設定手段により設定された前記状態変化時刻条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００１８】
この構成により、本発明の通知装置は、状態変化条件として状態変化した時刻を指定することが可能となる。例えば「状態が８時から１０時に変化した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した時刻の状態変化のみ通知することが可能となり、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００１９】
また、上述の本発明の通知装置において、前記状態変化情報保存手段はさらに、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を保存し、前記状態変化条件設定手段はさらに、前記状態項目と前記状態項目の前記状態値を指定する前記状態項目の状態値条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態項目と前記状態項目の前記状態値情報と前記状態変化条件設定手段により設定された前記状態項目と前記状態項目の前記状態値条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００２０】
この構成により、本発明の通知装置は、状態変化条件として状態が継続した状態継続時間または状態が変化した状態変化時刻に加えて、少なくとも１つの状態項目およびその状態項目の状態値を指定することが可能となる。例えば「８時から１０時にユーザが出社した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した状態継続時間または状態変化時刻における特定の状態の変化のみ通知することが可能となり、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００２１】
また、本発明の通知装置において、前記状態変化情報保存手段は、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化の履歴を表す変化履歴情報を保存し、前記状態変化条件設定手段は、前記状態項目と前記状態項目の前記状態値の変化を指定する履歴条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態項目と前記状態項目の前記状態値の変化の履歴を表す前記変化履歴情報と前記状態変化条件設定手段により設定された前記状態項目と前記状態項目の前記状態値の前記変化履歴条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００２２】
この構成により、本発明の通知装置は、状態変化条件として状態項目とその状態項目の状態値の変化パターンを指定することが可能となる。例えば「ユーザの居場所が休憩室→喫煙室→休憩室と変化した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した状態項目とその状態項目の状態値の変化パターンの変化のみ通知することが可能となり、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００２３】
また、本発明の通知装置において、前記状態変化情報保存手段は、複数の状態発行体それぞれの複数の状態変化情報を保存し、前記状態変化条件設定手段は、前記複数の状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記複数の状態変化情報と、前記状態変化条件設定手段により設定された前記複数の状態変化条件間の論理条件とに基づいて前記複数の状態発行体の前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００２４】
この構成により、本発明の通知装置は、状態変化条件として複数の状態発行体の個別の状態変化条件間の論理条件を指定することが可能となる。例えば「ユーザＡの居場所が１０分以上居室であり、ユーザＢの居場所も１０分以上居室である場合だけ通知」といった個別の状態変化条件間の論理条件の指定をして、個別の状態変化条件の論理条件を満たす場合のみ通知を行うように設定すると、それぞれの状態発行体の状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００２５】
また、本発明の通知装置において、前記状態変化条件を示す変化条件情報パケットを受信する変化条件情報受信手段を備え、前記状態変化条件設定手段は、前記変化条件情報受信手段により受信された前記変化条件情報パケットに基づいて前記状態変化条件を設定する構成を有してもよい。
【００２６】
この構成により、本発明の通知装置は、外部機器から状態変化条件を設定することが可能となるため、より適切な状態変化条件の指定が可能となる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信処理に関わる負荷が軽減される。
【００２７】
また、本発明の通知装置において、前記状態発行体は前記通知装置を含み、前記状態変化条件設定手段は、少なくとも前記通知装置自体の状態変化情報を設定する構成を有してもよい。
【００２８】
この構成により、本発明の通知装置は、通知装置自身の状態を状態変化条件として指定することが可能となり、より複雑な状態変化条件の指定が可能となる。これにより適切なタイミングで通知することが可能となり、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信処理に関わる負荷が軽減される。
【００２９】
また、本発明の通知装置において、前記状態変化通知情報送信手段は、前記状態変化通知パケットをＳＩＰ（Session Initiation Protocol）プロトコルに準拠して送信する構成を有してもよい。
【００３０】
この構成により、本発明の通知装置は、ＳＩＰプロトコルに準拠したイベント通知機能を使用した場合でも状態変化条件の指定が可能となるため、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信処理に関わる負荷が軽減される。
【００３１】
第２の発明の被通知装置は、時間の経過に応じて様々な状態をとりうる状態発行体の前記状態を通知する通知装置とネットワークを介して接続され、前記通知装置から前記状態発行体の前記状態を示す状態通知パケットを受信する状態情報受信手段と、前記状態発行体が同一の状態を継続している時間を表す状態継続時間、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻、および前記状態発行体の変化の履歴を表す変化履歴の少なくとも一つを設定する状態変化条件を通知する変化条件情報パケットを送信する変化条件送信手段とを備えることを特徴とする前記状態発行体の前記状態を受信する構成を有している。
【００３２】
この構成により、本発明の被通知装置は、状態の継続時間、または状態が変化した時刻、または状態の変化履歴の少なくとも一つによる状態変化条件の指定が可能となるため、被通知装置が必要としていない状態の通知を除去することができるとともに、通知パケットを受信する被通知装置はユーザが望むタイミングで状態の通知を受けることができ、被通知装置のアプリケーションが容易に開発できる。
【００３３】
また、本発明の被通知装置において、前記変化条件送信手段は、前記状態継続時間を指定する変化条件情報パケットを送信する構成を有してもよい。
【００３４】
この構成により、本発明の被通知装置は、状態変化条件として状態が継続した時間を指定することが可能となる。例えば「１分以上同一の継続した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、状態が変化するごとに状態の変化を通知を受ける必要がなくなるため、被通知装置が必要としていない状態の通知を除去することができるとともに、通知パケットを受信する被通知装置はユーザが望むタイミングで状態の通知を受けることができ、被通知装置のアプリケーションが容易に開発できる。
【００３５】
また、本発明の被通知装置において、前記変化条件送信手段は、前記状態変化時刻を指定する変化条件情報パケットを送信する構成を有してもよい。
【００３６】
この構成により、本発明の被通知装置は、状態変化条件として状態変化した時刻を指定することが可能となる。例えば「状態が８時から１０時に変化した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、状態が変化するごとに状態の変化を通知を受ける必要がなくなるため、被通知装置が必要としていない状態の通知を除去することができるとともに、通知パケットを受信する被通知装置はユーザが望むタイミングで状態の通知を受けることができ、被通知装置のアプリケーションが容易に開発できる。
【００３７】
また、本発明の被通知装置において、前記変化条件送信手段はさらに、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を指定する変化条件情報パケットを送信する構成を有してもよい。
【００３８】
この構成により、本発明の被通知装置は、状態変化条件として状態が継続した状態継続時間または状態が変化した状態変化時刻に加えて、少なくとも１つの状態項目およびその状態項目の状態値を指定することが可能となる。例えば「８時から１０時にユーザが出社した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した状態継続時間または状態変化時刻における特定の状態の変化のみ通知を受けることが可能となり、状態が変化するごとに状態の変化を通知を受ける必要がなくなるため、被通知装置が必要としていない状態の通知を除去することができるとともに、通知パケットを受信する被通知装置はユーザが望むタイミングで状態の通知を受けることができ、被通知装置のアプリケーションが容易に開発できる。
【００３９】
また、本発明の被通知装置において、前記変化条件送信手段は、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化を指定する変化条件情報パケットを送信する構成を有してもよい。
【００４０】
この構成により、本発明の被通知装置は、状態変化条件として状態項目とその状態項目の状態値の変化パターンを指定することが可能となる。例えば「ユーザの居場所が休憩室→喫煙室→休憩室と変化した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した状態項目とその状態項目の状態値の変化パターンの変化のみ通知を受けることが可能となり、状態が変化するごとに状態の変化を通知を受ける必要がなくなるため、被通知装置が必要としていない状態の通知を除去することができるとともに、通知パケットを受信する被通知装置はユーザが望むタイミングで状態の通知を受けることができ、被通知装置のアプリケーションが容易に開発できる。
【００４１】
また、本発明の被通知装置において、前記変化条件送信手段は、複数状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を指定する変化条件情報パケットを送信する構成を有してもよい。
【００４２】
この構成により、本発明の被通知装置は、状態変化条件として複数の状態発行体の個別の状態変化条件間の論理条件を指定することが可能となる。例えば「ユーザＡの居場所が１０分以上居室であり、ユーザＢの居場所も１０分以上居室である場合だけ通知」といった個別の状態変化条件間の論理条件の指定をして、個別の状態変化条件の論理条件を満たす場合のみ通知を受けるように設定すると、それぞれの状態発行体の状態が変化するごとに状態の変化の通知を受ける必要がなくなるため、被通知装置が必要としていない状態の通知を除去することができるとともに、通知パケットを受信する被通知装置はユーザが望むタイミングで状態の通知を受けることができ、被通知装置のアプリケーションが容易に開発できる。
【００４３】
また、本発明の被通知装置において、前記変化条件送信手段は、少なくとも前記通知装置の状態変化条件を指定する変化条件情報パケットを送信する構成を有してもよい。
【００４４】
この構成により、本発明の被通知装置は、通知装置自身の状態を状態変化条件として指定することが可能となり、より複雑な状態変化条件の指定が可能となる。これにより適切なタイミングで通知することが可能となり、ネットワークリソースを有効に使えるとともに、通知パケットの送受信処理に関わる負荷が軽減される。
【００４５】
また、本発明の被通知装置において、前記変化条件送信手段は、前記変化条件情報パケットをＳＩＰ（Session Initiation Protocol）プロトコルに準拠して送信する構成を有してもよい。
【００４６】
この構成により、本発明の被通知装置は、ＳＩＰプロトコルに準拠したイベント通知機能を使用した場合でも状態変化条件の指定が可能となるため、ネットワークリソースを有効に使えるとともに、通知パケットの送受信処理に関わる負荷が軽減される。
【００４７】
第３の発明の通知方法は、時間の経過に応じて様々な状態をとりうる状態発行体が同一の状態を継続している時間を表す状態継続時間情報、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻情報、および前記状態発行体の変化の履歴を表す変化履歴情報の少なくとも一つを含む状態変化情報を保存する状態変化情報保存ステップと、
【００４８】
状態変化条件を設定する状態変化条件設定ステップと、前記状態変化情報保存ステップで保存された前記状態変化情報と前記状態変化条件設定ステップにより設定された前記状態変化条件とに基づいて前記発行体の状態が変化したか否かを判定する状態変化判定ステップと、前記状態変化判定ステップが前記発行体の状態が変化したと判定した場合に、状態変化を通知する状態変化通知パケットを送信する状態変化通知パケット送信ステップとを備える構成を有している。
【００４９】
この構成により、本発明の通知方法は、指定された状態の継続時間、状態の変化時刻、または状態の変化の履歴の少なくとも一つにより表される状態の変化に応じて状態を通知するか否かを詳細に判定することができるため、不要な通知を減らし、ネットワークリソースを有効に利用できるとともに通知装置および被通知装置の送受信に関わる処理負担を軽減できる。
【００５０】
また、本発明の通知方法において、前記状態変化情報保存ステップは、前記状態継続時間を保存し、前記状態変化条件設定ステップは、前記状態継続時間を指定する状態継続時間条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態継続時間情報と前記状態変化条件設定ステップにより設定された前記状態継続時間条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００５１】
この構成により、本発明の通知方法は、状態変化条件として状態が継続した時間を指定することが可能となる。例えば「１分以上同一の継続した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００５２】
また、本発明の通知方法において、前記状態変化情報保存ステップは、前記状態変化時刻を保存し、前記状態変化条件設定ステップは、前記状態変化時刻の範囲を指定する状態変化時刻条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態変化時刻情報と前記状態変化条件設定ステップにより設定された前記状態変化時刻条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００５３】
この構成により、本発明の通知方法は、状態変化条件として状態変化した時刻を指定することが可能となる。例えば「状態が８時から１０時に変化した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した時刻の状態変化のみ通知することが可能となり、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００５４】
また、本発明の通知方法において、前記状態変化情報保存ステップはさらに、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を保存し、前記状態変化条件設定ステップはさらに、前記状態項目と前記状態項目の前記状態値を指定する前記状態項目の状態値条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態項目と前記状態項目の前記状態値情報と前記状態変化条件設定ステップにより設定された前記状態項目と前記状態項目の前記状態値条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００５５】
この構成により、本発明の通知方法は、状態変化条件として状態が継続した状態継続時間または状態が変化した状態変化時刻に加えて、少なくとも１つの状態項目およびその状態項目の状態値を指定することが可能となる。例えば「８時から１０時にユーザが出社した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した状態継続時間または状態変化時刻における特定の状態の変化のみ通知することが可能となり、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００５６】
また、本発明の通知方法において、前記状態変化情報保存ステップは、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化の履歴を表す変化履歴情報を保存し、前記状態変化条件設定ステップは、前記状態項目と前記状態項目の前記状態値の変化を指定する履歴条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態項目と前記状態項目の前記状態値の変化の履歴を表す前記変化履歴情報と前記状態変化条件設定ステップにより設定された前記状態項目と前記状態項目の前記状態値の前記変化履歴条件とに基づいて前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００５７】
この構成により、本発明の通知方法は、状態変化条件として状態項目とその状態項目の状態値の変化パターンを指定することが可能となる。例えば「ユーザの居場所が休憩室→喫煙室→休憩室と変化した場合だけ通知」といった状態変化条件の指定をして、状態変化条件を満たす場合のみ通知を行うように設定すると、指定した状態項目とその状態項目の状態値の変化パターンの変化のみ通知することが可能となり、状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００５８】
また、本発明の通知方法において、前記状態変化情報保存ステップは、複数の状態発行体それぞれの複数の状態変化情報を保存し、前記状態変化条件設定ステップは、前記複数の状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記複数の状態変化情報と、前記状態変化条件設定ステップにより設定された前記複数の状態変化条件間の論理条件とに基づいて前記複数の状態発行体の前記発行体の状態が変化したか否かを判定する構成を有してもよい。
【００５９】
この構成により、本発明の通知方法は、状態変化条件として複数の状態発行体の個別の状態変化条件間の論理条件を指定することが可能となる。例えば「ユーザＡの居場所が１０分以上居室であり、ユーザＢの居場所も１０分以上居室である場合だけ通知」といった個別の状態変化条件間の論理条件の指定をして、個別の状態変化条件の論理条件を満たす場合のみ通知を行うように設定すると、それぞれの状態発行体の状態が変化するごとに状態の変化を通知する必要がなくなる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信に関わる処理負荷を軽減できる。
【００６０】
また、本発明の通知方法において、前記状態変化条件を示す変化条件情報パケットを受信する変化条件情報パケット受信ステップを備え、前記状態変化条件設定ステップは、前記変化条件情報パケット受信ステップにより受信された前記変化条件情報パケットに基づいて前記状態変化条件を設定する構成を有してもよい。
【００６１】
この構成により、本発明の通知方法は、外部機器から状態変化条件を設定することが可能となるため、より適切な状態変化条件の指定が可能となる。これにより不要な通知が減少し、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信処理に関わる負荷が軽減される。
【００６２】
また、本発明の通知方法において、前記状態発行体は状態通知装置を含み、前記状態変化条件設定ステップは、少なくとも前記状態通知装置自体の状態変化情報を設定する構成を有してもよい。
【００６３】
この構成により、本発明の通知方法は、通知装置自身の状態を状態変化条件として指定することが可能となり、より複雑な状態変化条件の指定が可能となる。これにより適切なタイミングで通知することが可能となり、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信処理に関わる負荷が軽減される。
【００６４】
また、本発明の通知方法において、前記状態変化通知パケット送信ステップは、前記状態変化通知パケットをＳＩＰプロトコルに準拠して送信する構成を有してもよい。
【００６５】
この構成により、本発明の通知方法は、ＳＩＰプロトコルに準拠したイベント通知機能を使用した場合でも状態変化条件の指定が可能となるため、ネットワークリソースを有効に使えるとともに、通知装置および被通知装置の通知パケットの送受信処理に関わる負荷が軽減される。
【発明の効果】
【００６６】
本発明は、ネットワークに接続された装置の状態を通知する際に、不要な通知を減らすことにより、ネットワークリソースを有効に利用できるとともに通知装置および被通知装置の処理負担を軽減することができる通知装置、被通知装置および状態通知方法を提供することができる。
【発明を実施するための最良の形態】
【００６７】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
（第１の実施の形態）
【００６８】
図１は、第１の実施の形態の通知装置および被通知装置を適用したネットワークシステムの構成を示すブロック図である。
【００６９】
図１においてネットワークシステムは、プレゼンスサーバ装置１００と、外勤者端末１０１と、内勤者端末１０２と、管理者端末１０３とを備え、プレゼンスサーバ装置１００と、外勤者端末１０１と、内勤者端末１０２と、管理者端末１０３とはネットワーク１１０を介して相互に接続されている。外勤者端末１０１はユーザ１２１が操作する、例えば携帯電話、Personal Digital Assistance（以後、「ＰＤＡ」という）などの機器であり、内勤者端末１０２はユーザ１２２が操作する、例えばＰＣなどの機器であり、外勤者端末１０１はユーザ１２１の状態が変化するたびに、内勤者端末１０２はユーザ１２２の状態が変化するたびにプレゼンスサーバ装置１００に状態情報を通知してそれぞれのユーザの状態の登録を行う。管理者端末１０３はユーザ１３０が操作するＰＣなどの機器であり、事前にプレゼンスサーバ装置１００に対して状態通知要求をしており、プレゼンスサーバ装置１００から外勤者端末１０１および内勤者端末１０２のユーザ１２１およびユーザ１２２の状態通知を受けるようになっている。プレゼンスサーバ装置１００は外勤者端末１０１と内勤者端末１０２から受信した状態情報に基づいて外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態を保持し、管理者端末１０３に対して外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態を通知する。
【００７０】
本実施の形態では、プレゼンスサーバ装置１００に対してユーザ１３０は状態通知要求を行う際に状態継続時間を指定する状態変化条件を入力し設定しているものとする。一例として、「１分以上同一の状態が継続した場合だけ通知」という状態変化条件が設定され、プレゼンスサーバ装置１００は外勤者端末１０１または内勤者端末１０２のユーザの状態が１分以上同一の状態を継続したときだけ管理者端末１０３に対して状態通知を行う場合について説明する。
【００７１】
まず、図２を参照して、本実施の形態のメッセージフローを説明する。なお、本実施の形態では、一例としてＳＩＰプロトコルを適用して通信を行っており、信号はすべてパケットにて送受信されるが、ＨＴＴＰ(Hyper Text Transfer Protocol)プロトコルやその他のプロトコルを適用して通信を行ってもよく、適用するプロトコルに応じて信号のフォーマットも異なってもよいことは明かである。これは第２の実施の形態以降の説明についても同様である。また、図２では簡略化のためPUBLISHメッセージやNOTIFYメッセージに対する200 OK応答の記述を省略しているが、実際は各メッセージに対して200 OK応答が返る。これは図２以降のメッセージフローを表す図についても同様であることは言うまでもない。外勤者端末１０１、内勤者端末１０２はプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信し、ユーザ１２１、１２２の状態をそれぞれ予め通知して登録しておく。
【００７２】
ユーザ１３０はプレゼンスサーバ装置１００に対して、「１分以上同一の状態が継続した場合だけ通知」という状態変化条件を設定し、通知先ＵＲＩとして管理者端末１０３のＵＲＩである「sip:103@example.com」を設定しておく。
【００７３】
外勤者端末１０１、内勤者端末１０２はそれぞれのユーザ１２１、１２２の状態が変化するたびにプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信する。プレゼンスサーバ装置１００はPUBLISHメッセージを受信すると、状態変化条件に記述された状態継続時間に相当する時間分のタイマーを始動し、指定された状態継続時間に相当する時間分が経過してタイマー終了した後に状態が変化していない場合は状態変化条件で指定された状態継続時間を超えたと判定し、管理者端末１０３に対してNOTIFYメッセージを送信する。
【００７４】
ここで図１に戻り本実施の形態の詳細な説明をする。
【００７５】
外勤者端末１０１、内勤者端末１０２はユーザの状態を表す少なくとも一つの状態項目とその状態項目の状態値を通知するようになっている。
【００７６】
外勤者端末１０１は、ユーザ１０１の状態を、例えば、"place"という現在位置を意味する状態項目で表す。この状態項目"place"は、例えば、居室や１階会議室を表す"desk"や"1F_meeting"、移動中を表す"moving"といった状態値を有している。現在位置、すなわち状態項目"place"の検出方法としては外勤者端末１０１にＲＦＩＤ(Radio Frequency Identification)タグを搭載して、居室や会議室にＲＦＩＤ受信機を設置することにより、外勤者端末１０１の場所の状態を検出する方法、外勤者端末１０１の電源が切られたときには移動中とするなど、様々な方法が考えられる。
【００７７】
内勤者端末１０２は、ユーザ１２２の居室に設置されたＰＣなどの機器で、ユーザ１２２の状態を、例えば、現在内勤者端末１０２を使用しているかを表す"presence"というプレゼンス状態を意味する状態項目で表す。この状態項目"presence"は「在席/不在」を表す"open/closed"という二つの状態値を有している。プレゼンス状態、すなわち状態項目"presence"の検出には、内勤者端末１０２のスクリーンセーバが起動したら「不在」、それ以外は「在席」とするなど、様々な方法が想定できる。
【００７８】
なお、ここで記載した状態項目とその状態値は一例であり、この他にも電波強度状態やネットワーク接続状態など、その他の状態項目や状態値を持っていてもよい。
【００７９】
外勤者端末１０１、内勤者端末１０２はそれぞれのユーザの状態が変化すると、プレゼンスサーバ装置１００にPUBLISHメッセージを送信して状態を登録する。なお、プレゼンスサーバ装置１００のアドレスは各機器に予め設定されていてもよいし、その他の方法を使って取得してもよい。状態の登録方法としては、例えば内勤者端末１０２のプレゼンスが在席という状態を登録する場合は「 sip:102@example.com;presence="open"」というテキストをPUBLISHメッセージのボディ部に記述することが考えられる。なお、状態を表すテキストはXMLやその他のフォーマットでもよく、ボディ部ではなくヘッダ部に記述してもよい。また、状態の登録についてはPUBLISHメッセージを使わずに他のメッセージやＳＩＰ以外のプロトコルを使ってもよい。
【００８０】
管理者端末１０３はプレゼンスサーバ装置１００からNOTIFYメッセージを受信するとその情報を画面に表示し、ユーザ１２１およびユーザ１２２の状態をユーザ１３０に対して知らせるようになっている。
【００８１】
プレゼンスサーバ装置１００はユーザ１３０から入力された状態変化条件を保持し、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態が設定された状態変化条件を満たした場合にだけ管理者端末１０３に対してNOTIFYメッセージを送信する。プレゼンスサーバ装置１００の装置構成と動作の詳細については後述する。
【００８２】
なお、ネットワーク１１０としては社内ＬＡＮが考えられるが、社内ＬＡＮ以外にも宅内ネットワークやインターネットなど、その他のネットワークであってもよい。
【００８３】
次にプレゼンスサーバ装置１００の構成と動作について図３および図４を参照して詳細に説明する。プレゼンスサーバ装置１００は通知装置を構成している。なお、簡略化のため以後各メッセージに対する200 OK応答の動作については説明を省略するが、全てのメッセージに対して200 OK応答の送受信動作があるものとする。
【００８４】
まず、プレゼンスサーバ装置１００の構成について説明する。図３は本実施の形態におけるプレゼンスサーバ装置１００の構成を示すブロック図である。プレゼンスサーバ装置１００は、図３に示されるように、プレゼンスサーバ装置１００を構成する全ての構成部品の動作を制御する制御部２０１と、プレゼンスサーバ装置１００が管理する全ての機器のＵＲＩと状態を保存する状態管理データベース２０２と、状態変化条件と通知先ＵＲＩを保存する状態変化条件保持部２０３と、通知先ＵＲＩおよび状態情報を含む信号を生成するメッセージ生成部２０４と、外勤者端末１０１、内勤者端末１０２、管理者端末１０３など外部の機器と信号の送受信を行う通信部２０５と、プレゼンスサーバ装置１００の図示されていない画面に情報を出力する画面出力部２０６と、画面から入力された情報を入力する入力受信部２０７とを備えている。画面出力部２０６と入力受信部２０７は、例えば、タッチパネルなどで構成されてもよい。
【００８５】
本実施の形態では、入力受信部２０７が状態変化条件と通知先ＵＲＩを入力するようになっている。状態変化条件保持部２０３は、入力された状態変化条件を保存するようになっている。入力受信部２０７と状態変化条件保持部２０３は状態変化条件設定手段を構成する。
【００８６】
状態管理データベース２０２は、通信部２０５を介して受信する外勤者端末１０１と内勤者端末１０２からユーザ１２１とユーザ１２２の状態情報に基づいてユーザ１２１とユーザ１２２の状態変化情報を保存するようになっており、状態変化情報保存手段を構成する。
【００８７】
制御部２０１は、状態管理データベース２０２に保存された外勤者端末１０１のユーザ１２１と内勤者端末１０２のユーザ１２２の状態変化情報と状態変化条件保持部２０３に保存された状態変化条件を比較して、ユーザ１２１とユーザ１２２の状態が所定の程度を超えて変化したか否かを判定するようになっており、状態変化判定手段を構成している。
【００８８】
さらに通信部２０５は、ユーザの状態が所定の程度を超えて変化したと制御部２０１により判定された場合に、管理者端末１０３に状態情報を含むNOTIFYメッセージを送信するようになっており、状態変化通知情報送信手段を構成している。
【００８９】
次に、プレゼンスサーバ装置１００が状態変化条件を設定する際に実行する動作について図３および図４を参照して説明する。図４は本実施の形態におけるプレゼンスサーバ装置１００が状態変化条件を設定する際に実行する動作を示すフロー図である。
【００９０】
最初に、制御部２０１は状態変化条件と通知先ＵＲＩを入力する画面を表示する命令を画面出力部２０６に送り入力画面を表示させ（Ｓ１）、ユーザ１３０からの入力を待つ（Ｓ２）。ユーザ１３０から入力受信部２０７を介して状態変化条件と通知先ＵＲＩが入力されるとその情報が入力受信部２０７から制御部２０１へ送られる（Ｓ３）。ここでは状態変化条件として状態継続時間が設定されるものとする。具体的には「１分以上同一の状態が継続した場合だけ通知」という条件が入力され、通知先ＵＲＩとして管理者端末１０３のＵＲＩが入力されたものとする。状態変化条件と通知先ＵＲＩの入力方法としては、予め設定された複数の状態変化条件や通知先ＵＲＩの中から適当な条件やＵＲＩを選択するなど、様々な方法が想定できる。
【００９１】
制御部２０１は入力された状態変化条件を所定のフォーマットに変換する（Ｓ４）。ここでは「Continuing_time>=1min」というフォーマットに変換する。なお、状態変化条件のフォーマットについてはXMLなど、その他のフォーマットでもよい。
【００９２】
制御部２０１は状態変化条件と通知先ＵＲＩを状態変化条件保持部２０３に保存する（Ｓ５）。ここでは状態変化条件として「Continuing_time>=1min」を保存し、通知先ＵＲＩとしては管理者端末１０３のＵＲＩである「sip:103@examle.com」を保存する。なお、状態変化条件保持部２０３は複数の状態変化条件と通知先ＵＲＩを保存することが可能である。状態変化条件保持部２０３で保存されるデータ構造の詳細については後述する。また、本実施の形態では、状態変化条件は入力受信部２０７を介して設定されたが、ユーザ１３０は入力受信部２０７を介せずに、管理者端末１０３を操作して、プレゼンスサーバ装置１００の通信部２０５に状態変化条件と通知先ＵＲＩの情報を有した変化条件情報パケットを送信して設定してもよいことは言うまでもない。管理者端末１０３が通信部２０５を介してプレゼンスサーバ装置１００と通信して状態変化条件と通知先ＵＲＩを入力して設定する方法については第６の実施の形態で後述する。
【００９３】
プレゼンスサーバ装置１００がPUBLISHメッセージを受信後に実行する動作について図３と図５を参照して説明する。図５は本実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図である。
【００９４】
最初に、通信部２０５が外勤者端末１０１または内勤者端末１０２からPUBLISHメッセージを受信し（Ｓ１０１）、受信したPUBLISHメッセージを制御部２０１に送る（Ｓ１０２）。制御部２０１はPUBLISHメッセージに記述されたユーザの状態情報を状態管理データベース２０２に保存する（Ｓ１０３）。例えばPUBLISHメッセージに内勤者端末１０２のユーザ１２２が在席していることを表す「sip:102@example.com:presence="open"」という状態が記述されていた場合は、内勤者端末１０２を指定する「sip:102@example.com」というＵＲＩの状態項目"presence"の状態値を"open"に変更する。なお、状態管理データベース２０２で保存されるデータの構造の詳細については後述する。
【００９５】
制御部２０１は状態変化条件保持部２０３に保存されている状態変化条件と通知先ＵＲＩを取得する（Ｓ１０４）。状態変化条件は「１分以上同一の状態が継続した場合だけ通知」という条件を意味する「Continuing_time>=1min」を取得するので、制御部２０１は状態変化条件で指定された状態継続時間に相当する時間分、すなわち１分のタイマーを始動する（Ｓ１０５）。タイマーが終了すると（Ｓ１０６）、状態管理データベース２０２からPUBLISHメッセージで通知された機器の現在の状態を取得する（Ｓ１０７）。ここで、PUBLISHメッセージ受信時の状態と、取得した現在の状態を比較する（Ｓ１０８）。状態が変化した場合はNOTIFYメッセージを生成せずに終了し、状態が変化していない場合は、同一の状態が状態変化条件で指定された状態継続時間を超えて継続されたと判断し、状態管理データベース２０２から取得した内勤者端末１０２のユーザ１２２の状態情報と通知先ＵＲＩをメッセージ生成部２０４に送り（Ｓ１０９）、メッセージ生成部２０４は通知先ＵＲＩをRequest-ＵＲＩに記述し、ユーザ１２２の状態をボディ部に記述したNOTIFYメッセージを生成する（Ｓ１１０）。メッセージ生成部２０４は生成したNOTIFYメッセージを通信部２０５に送り（Ｓ１１１）、通信部２０５はNOTIFYメッセージを管理者端末１０３へ送信する（Ｓ１１２）。
【００９６】
次に、管理者端末１０３の構成と動作について図６および図７を参照して説明する。管理者端末１０３は被通知装置を構成している。
【００９７】
管理者端末１０３の構成について説明する。図６は本実施の形態における管理者端末１０３の構成を示すブロック図である。管理者端末１０３は、図６に示されるように、管理者端末１０３を構成する全ての構成部品の動作を制御する制御部３０１と、管理者端末１０３の図示されていない画面に情報を出力する画面出力部３０２と、プレゼンスサーバ装置１００、外勤者端末１０１、内勤者端末１０２など外部の機器と信号の送受信を行う通信部３０３とから構成されている。
【００９８】
本実施の形態では、通信部３０３がプレゼンスサーバ装置１００から外勤者端末１０１のユーザ１２１、内勤者端末１０２のユーザ１２２の状態を示す信号を受信する状態情報受信手段を構成している。
【００９９】
管理者端末１０３により実行されるNOTIFYメッセージ受信動作について図６と図７を参照して説明する。図７は本実施の形態における管理者端末１０３がNOTIFYメッセージ受信後に実行する動作のフロー図である。
【０１００】
まず、通信部３０３がNOTIFYメッセージを受信し（Ｓ２０１）、受信したNOTIFYメッセージを制御部３０１に送る（Ｓ２０２）。制御部３０１はNOTIFYメッセージに記述された状態を画面出力部３０２に表示する命令を送り、画面に状態を表示する（Ｓ２０３）。例えばNOTIFYメッセージに記述された状態が「sip:101@example.com:place="1F_meeting"」である場合は、画面に「外勤者端末１０１：場所１階会議室」というテキストメッセージを画面に表示させる。なお、画面に情報を表示する形態はアイコン表示やその他の形態であってもよい。さらには、本実施の形態では画面に表示して状態を通知しているが、画面に表示せずに音やその他の方法を使って状態を通知してもよいことは言うまでもない。
【０１０１】
次に本実施の形態におけるNOTIFYメッセージに含まれるメッセージについて説明する。図８は本実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図である。なお、PUBLISHメッセージに含まれるメッセージについては通常のＳＩＰにおいて使用されるメッセージと同様なので説明を省略する。また、図８に示すメッセージは説明に必要な部分以外については省略しており、実際のメッセージでは例えば他にヘッダが存在する。これは本明細書で図９以降に説明されるメッセージのデータの構造を示すブロック図についても同様である。
【０１０２】
図８に示されるように、Request−ＵＲＩとして状態変化条件保持部２０３の通知先ＵＲＩに保持された管理者端末１０３のＵＲＩが記述される。Eventヘッダには、プレゼンスイベントを表す"presence"が記述される。ボディ部には状態管理データベース２０２から取得した例えば「外勤者端末１０１が１階会議室にいる」というユーザの状態が記述される。なお、ユーザの状態は拡張ヘッダを使ってヘッダ部に記述してもよい。
【０１０３】
次に、状態管理データベース２０２および状態変化条件保持部２０３で保存されるデータの構造について説明する。
【０１０４】
最初に、状態管理データベース２０２で保存されるデータの構造について図９を参照して説明する。図９は本実施の形態における状態管理データベース２０２で保存されるデータの構造を示すブロック図である。
【０１０５】
状態管理データベース２０２はプレゼンスサーバ装置１００が管理する全ての機器のＵＲＩと状態を保持するデータベースであり、機器のＵＲＩと、それぞれの機器について1つ以上の状態項目とその状態項目の状態値が保存されている。
【０１０６】
図９に示された例では、「sip:101@example.com」というＵＲＩを持つ機器は、状態項目"place"に対して、エレベータを示す"elevator"という状態値を持つということを示す。これは外勤者端末１０１が現在位置、エレベータという状態であるというメッセージであり、すなわち外勤者端末１０１、または外勤者端末１０１のユーザ１２１が現在エレベータの場所にいることを意味している。保持する状態項目としては、図９に記述した例以外にネットワークへの接続状態を示す"network"など様々なものが考えられる。
【０１０７】
次に、状態変化条件保持部２０３で保存されるデータの構造について図１０を参照して説明する。図１０は本実施の形態における状態変化条件保持部２０３で保存されるデータ構造を示すブロック図である。
【０１０８】
状態変化条件保持部２０３はユーザによって設定された状態変化条件と、通知先ＵＲＩを保存する。状態変化条件と通知先ＵＲＩについては複数保持することが可能である。
【０１０９】
図１０に示された例では、「Continuing_time>=1min」で表される「１分以上同一の状態が継続した場合だけ通知」という状態変化条件を満たした場合は「sip:103@example.com」という通知先ＵＲＩで表される管理者端末１０３に対して通知するということを示す。
【０１１０】
以上説明したように本実施の形態では、ユーザ１３０がプレゼンスサーバ装置１００に対して「１分以上同一の状態が継続した場合だけ通知」という状態変化条件を設定し、プレゼンスサーバ装置１００は状態変化条件を満たすときだけ管理者端末１０３に対してNOTIFYメッセージを送信する例を示した。これによって、不要なNOTIFYメッセージが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ装置１００と管理者端末１０３のNOTIFYメッセージの送受信に関わる負荷が軽減される。
【０１１１】
また、管理者端末１０３は所望のタイミングで状態通知を受けることができ、ユーザは必要なタイミングでの状態通知を受けることが可能となる。
【０１１２】
なお、本実施の形態ではプレゼンスサーバ装置１００が外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態継続時間を計測し、それが状態変化条件で示された状態継続時間を超えた以上と判定された場合にNOTIFYメッセージを送信していたが、状態継続時間の計測および判定の機能を管理者端末１０３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置１００は外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態が変化するたびに管理者端末１０３にNOTIFYメッセージを送信する。管理者端末１０３は受信したNOTIFYメッセージから状態継続時間を計測し、それが管理者端末１０３に予め設定された状態変化条件で示された状態継続時間以上と判定された場合にユーザ１３０に対して状態の通知を行うことにより、ユーザ１３０は必要なタイミングでの状態通知を受けることができる。また、本実施の形態では、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２が状態発行体を構成し、ユーザ１２１、１２２の状態の変化を通知の対象としているが、外勤者端末１０１、内勤者端末１０２が状態発行体を構成し、外勤者端末１０１、内勤者端末１０２自体の状態の変化を通知の対象とするなど、様々な人やものの状態を通知の対象としてもよいことは言うまでもない。
（第２の実施の形態）
【０１１３】
本発明の第２の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成は第１の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成と同様であるため同一の符号を付して説明を省略する。
【０１１４】
本実施の形態では、ユーザ１３０はプレゼンスサーバ装置１００に対して状態通知要求を行う際に状態が変化した状態変化時刻の範囲を指定する状態変化条件を入力して設定しているものとする。一例として、「状態が１０時から１１時の間に変化した場合だけ通知」という状態変化条件が設定され、プレゼンスサーバ装置１００は外勤者端末１０１または内勤者端末１０２のユーザの状態が１０時から１１時の間に変化したときだけ管理者端末１０３に対して状態通知を行う場合について説明する。
【０１１５】
まず、図１１を参照して本実施の形態のメッセージフローを説明する。
【０１１６】
外勤者端末１０１、内勤者端末１０２はプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信し、それぞれユーザ１２１、１２２の状態を予め通知して登録しておく。
【０１１７】
ユーザ１３０はプレゼンスサーバ装置１００に対して、状態変化条件として状態変化時刻の範囲、具体的には「状態が１０時から１１時の間に変化した場合だけ通知」を設定し、通知先ＵＲＩとして管理者端末１０３のＵＲＩである「sip:103@example.com」を設定しておく。
【０１１８】
外勤者端末１０１、内勤者端末１０２はそれぞれユーザ１２１、１２２の状態が変化するたびにプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信する。プレゼンスサーバ装置１００はPUBLISHメッセージを受信すると、状態変化時刻として現在時刻を保持し、状態変化時刻が状態変化条件を満たす場合だけ管理者端末１０３に対してNOTIFYメッセージを送信する。
【０１１９】
次にプレゼンスサーバ装置１００で実行される動作について詳細を説明する。なお、プレゼンスサーバ装置１００の装置構成および状態変化条件設定動作については第１の実施の形態と同様であるため説明を省略する。また、管理者端末１０３の装置構成および動作についても第１の実施の形態と同様であるため説明を省略する。
【０１２０】
まず、プレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作について図３と図１２を参照して説明する。図１２は本実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図である。
【０１２１】
最初に、通信部２０５がPUBLISHメッセージを受信し（Ｓ３０１）、受信したPUBLISHメッセージを制御部２０１に送る（Ｓ３０２）。制御部２０１はPUBLISHメッセージに記述された状態と現在時刻を状態管理データベース２０２に保存する（Ｓ３０３）。
【０１２２】
例えばPUBLISHメッセージに内勤者端末１０２のユーザ１２２が在席していることを表す「sip:102@example.com:presence="open"」という状態が記述されていた場合は、内勤者端末１０２を指定する「sip:102@example.com」というＵＲＩが持つ状態項目"presence"の状態値を"open"に変更する。さらに、状態変化時刻として現在時刻を状態管理データベース２０２に保存する。なお、状態管理データベース２０２で保存されるデータ構造の詳細については後述する。
【０１２３】
制御部２０１は状態変化条件保持部２０３に保存されている状態変化条件と通知先ＵＲＩを取得する（Ｓ３０４）。状態変化条件として「状態が１０時から１１時の間に変化した場合だけ通知」という条件を意味する「10:00:00<=Changed_time<=11:00:00」を取得するので、制御部２０１は、状態管理データベース２０２に保存した内勤者端末１０２のユーザ１２２が状態を変化させた時刻が、ステップＳ３０４で取得した状態変化条件で指定された時刻の範囲に入っているか判定する（S３０５）。ここで、状態変化時刻が状態変化条件で指定された時刻の範囲に入っていない場合は、NOTIFYメッセージを生成せずに終了する。状態が変化した時刻が状態変化条件で指定された時刻の範囲に入っている場合は、PUBLISHメッセージに記述され、状態管理データベース２０２に保存された内勤者端末１０２のユーザ１２２の状態情報と通知先ＵＲＩをメッセージ生成部２０４に送る（Ｓ３０６）。なお、ステップＳ３０７からＳ３０９までの工程については第１の実施の形態のステップＳ１１０からＳ１１２までの工程と同様であるため説明を省略する。
【０１２４】
次に本実施の形態におけるNOTIFYメッセージに含まれるメッセージについて説明する。図１３は本実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図である。
【０１２５】
図１３に示されるように、Request-ＵＲＩとして状態変化条件保持部の通知先ＵＲＩに保持された管理者端末１０３のＵＲＩが記述される。Eventヘッダには、プレゼンスイベントを表す"presence"が記述される。ボディ部には状態管理データベース２０２から取得した例えば「外勤者端末１０１が日本時間で１０時５９分３３秒に１階ホールにいた」というユーザの状態と、状態が変化した時刻が記述される。なお、状態および状態が変化した時刻は拡張ヘッダを使ってヘッダ部に記述してもよい。
【０１２６】
次に、状態管理データベース２０２で保存されるデータ構造について図１４を参照して説明する。なお、状態変化条件保持部２０３で保存されるデータの構造については第１の実施の形態と同様であるため省略する。
【０１２７】
図１４は本実施の形態における状態管理データベース２０２で保存されるデータの構造を示すブロック図である。
【０１２８】
状態管理データベース２０２はプレゼンスサーバ装置１００が管理する全ての機器のＵＲＩと状態を保持するデータベースであり、機器のＵＲＩと、それぞれの機器について1つ以上の状態項目、状態値および状態が変化した時刻が保持されている。
【０１２９】
図１４に記述された例では、「sip:101@example.com」というＵＲＩを持つ機器は、状態項目"place"に対して、エレベータを示す"elevator"という状態値を持ち、状態が変化した時刻は日本時間で１０時５８分５１秒であるということを示す"10:58:51 +900"という値を持つことを示す。これは外勤者端末１０１が日本時間で１０時５８分５１秒にエレベータへと現在位置を変化させたというメッセージであり、すなわち外勤者端末１０１、または外勤者端末１０１のユーザ１２１が日本時間で１０時５８分５１秒にエレベータの場所へ移動したことを意味している。なお、保持する状態項目と状態値の組としては、図１４に記述した例以外にもネットワークへの接続状態を示す"network"など様々なものが考えられる。
【０１３０】
以上説明したように本実施の形態では、ユーザ１３０がプレゼンスサーバ装置１００に対して「状態が１０時から１１時の間に変化した場合だけ通知」という状態変化条件を設定し、プレゼンスサーバ装置１００は状態変化条件を満たすときだけ管理者端末１０３に対してNOTIFYメッセージを送信する例を示した。これによって、不要なNOTIFYメッセージが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ装置１００と管理者端末１０３のNOTIFYメッセージの送受信に関わる負荷が軽減される。
【０１３１】
なお、本実施の形態ではプレゼンスサーバ装置１００が外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態変化時刻を保持し、それが状態変化条件で示された時刻の範囲に入っていると判定された場合にNOTIFYメッセージを送信していたが、状態変化時刻の保持および状態変化条件の判定の機能を管理者端末１０３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置１００は外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態が変化するたびに管理者端末１０３にNOTIFYメッセージを送信する。管理者端末１０３は受信したNOTIFYメッセージの状態変化時刻を保持し、それが管理者端末１０３に予め設定された状態変化条件で示された時刻の範囲に入っていると判定された場合にユーザに対して状態の通知を行うことにより、ユーザは必要なタイミングでの状態通知を受けることができる。また、本実施の形態では、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２が状態発行体を構成し、ユーザ１２１、１２２の状態の変化を通知の対象としているが、外勤者端末１０１、内勤者端末１０２が状態発行体を構成し、外勤者端末１０１、内勤者端末１０２自体の状態の変化を通知の対象とするなど、様々な人やものの状態を通知の対象としてもよいことは言うまでもない。
（第３の実施の形態）
【０１３２】
本発明の第３の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成は第１の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成と同様であるため同一の符号を付して説明を省略する。
【０１３３】
本実施の形態では、ユーザ１３０はプレゼンスサーバ装置１００に対して状態通知要求を行う際に少なくとも一つの状態項目とその状態項目の状態値と、状態変化時刻の範囲を指定する状態変化条件を入力して設定しているものとする。一例として、「外勤者端末１０１の場所が１０時から１２時の間に１階会議室となった場合だけ通知」という状態変化条件が設定され、プレゼンスサーバ装置１００は外勤者端末１０１のユーザ１２１の状態が場所が１０時から１２時の間に１階会議室となった場合だけ状態通知を行う場合について説明する。
【０１３４】
まず、図１５を参照して本実施の形態のメッセージフローを説明する。
【０１３５】
外勤者端末１０１、内勤者端末１０２はプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信し、それぞれがユーザ１２１、１２２の状態を予め通知して登録しておく。
【０１３６】
ユーザ１３０はプレゼンスサーバ装置１００に対して、状態変化条件として機器の少なくとも一つの状態項目とその状態項目の状態値と、状態変化時刻の範囲、具体的には「外勤者端末１０１の場所が１０時から１２時の間にＩＦ会議室となった場合だけ通知」を設定し、通知先ＵＲＩとして管理者端末１０３のＵＲＩである「sip:103@example.com」を設定しておく。
【０１３７】
外勤者端末１０１、内勤者端末１０２はそれぞれユーザ１２１、１２２の状態が変化するたびにプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信する。プレゼンスサーバ装置１００はPUBLISHメッセージを受信すると、機器またはユーザの状態項目、状態値および状態変化時刻を保持し、状態項目、状態値および状態変化時刻が状態変化条件を満たす場合だけ管理者端末１０３に対してNOTIFYメッセージを送信する。
【０１３８】
次にプレゼンスサーバ装置１００で実行される動作について詳細を説明する。なお、プレゼンスサーバ装置１００の装置構成および状態変化条件設定動作については第１の実施の形態と同様であるため説明を省略する。また、管理者端末１０３の装置構成および動作についても第１の実施の形態と同様であるため説明を省略する。また、送信されるNOTIFYメッセージメッセージのデータ構造については第２の実施の形態と同様であるため説明を省略する。
【０１３９】
まず、プレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作について図３と図１６を参照して説明する。図１６は本実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図である。
【０１４０】
ここで、ステップＳ４０１からＳ４０５までの工程については第２の実施の形態のステップＳ３０１からＳ３０５までの工程と同様のため説明を省略する。
【０１４１】
ステップＳ３０５で、状態変化時刻が状態変化条件に記述された時刻の範囲に入っている場合、PUBLISHメッセージに記述され、状態管理データベース２０２に保存された外勤者端末１０１の状態項目とその状態項目の状態値が状態変化条件に記述された状態項目とその状態項目の状態値と合致するか判定する（Ｓ４０６）。合致しない場合はNOTIFYメッセージを生成せずに終了する。合致する場合は、ステップＳ４０７に進み、NOTIFYメッセージを生成して送信する。なお、ステップＳ４０７からＳ４１０までの工程については第２の実施の形態のステップＳ３０６からＳ３０９までの工程と同様であるため説明を省略する。
【０１４２】
以上説明したように本実施の形態では、ユーザ１３０がプレゼンスサーバ装置１００に対して「外勤者端末１０１の場所が１０時から１２時の間にＩＦ会議室となった場合だけ通知」という状態変化条件を設定し、プレゼンスサーバ装置１００は状態変化条件を満たすときだけ管理者端末１０３に対してNOTIFYメッセージを送信する例を示した。これによって、不要なNOTIFYメッセージが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ装置１００と管理者端末１０３のNOTIFYメッセージの送受信に関わる負荷が軽減される。
【０１４３】
なお、本実施の形態ではプレゼンスサーバ装置１００が外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態変化時刻、状態項目とその状態項目の状態値を保持し、それが状態変化条件を満たしていると判定された場合にNOTIFYメッセージを送信していたが、状態変化時刻、状態項目とその状態項目の状態値の保持および状態変化条件の判定の機能を管理者端末１０３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置１００は外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態が変化するたびに管理者端末１０３にNOTIFYメッセージを送信する。管理者端末１０３は受信したNOTIFYメッセージの状態変化時刻、状態項目とその状態項目の状態値を保持し、それが管理者端末１０３に予め設定された状態変化条件を満たしていると判定された場合にユーザに対して状態の通知を行うことにより、ユーザは必要なタイミングでの状態通知を受けることができる。さらに本実施の形態では、状態変化条件として状態変化時刻、状態項目とその状態項目の状態値を指定しているがこれに限定されることはない。状態継続時間、一つ以上の状態項目とその状態項目の状態値、あるいは状態継続時間、状態変化時間、一つ以上の状態項目とその状態項目の組み合わせなど様々な状態変化条件を指定することが可能である。また、本実施の形態では、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２が状態発行体を構成し、ユーザ１２１、１２２の状態の変化を通知の対象としているが、外勤者端末１０１、内勤者端末１０２が状態発行体を構成し、外勤者端末１０１、内勤者端末１０２自体の状態の変化を通知の対象にするなど、様々な人やものの状態を通知の対象としてもよいことは言うまでもない。
（第４の実施の形態）
【０１４４】
本発明の第４の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成は第１の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成と同様であるため同一の符号を付して説明を省略する。
【０１４５】
本実施の形態では、ユーザ１３０はプレゼンスサーバ装置１００に対して状態通知要求を行う際に少なくとも一つの状態項目とその状態項目の状態値の変化履歴を指定する状態変化条件を入力して設定しているものとする。一例として、「外勤者端末１０１のユーザ１２１の場所が休憩室→喫煙室→休憩室と状態変化した場合だけ通知」という状態変化条件が設定され、プレゼンスサーバ装置１００は状態変化条件を満たすときのみ状態通知を行う例を示す。
【０１４６】
まず、図１７を参照して本実施の形態のメッセージフローを説明する。
【０１４７】
外勤者端末１０１、内勤者端末１０２はプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信し、それぞれユーザ１２１、１２２の状態を予め通知して登録しておく。プレゼンスサーバ装置１００はPUBLISHメッセージを受信するごとに、保持している状態変化の履歴を更新する。
【０１４８】
ユーザ１３０はプレゼンスサーバ装置１００に対して、状態変化条件として「外勤者端末１０１の場所が休憩室→喫煙室→休憩室と状態変化した場合だけ通知」を設定し、通知先ＵＲＩとして管理者端末１０３のＵＲＩである「sip:103@example.com」を設定しておく。
【０１４９】
外勤者端末１０１、内勤者端末１０２はそれぞれユーザ１２１、１２２の状態が変化するたびにプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信する。プレゼンスサーバ装置１００はPUBLISHメッセージを受信するごとに、状態と状態変化時刻の履歴を更新し、ユーザ１２１の状態変化履歴が状態変化条件を満たす場合だけ管理者端末１０３に対してNOTIFYメッセージを送信する。
【０１５０】
次にプレゼンスサーバ装置１００で実行される動作について詳細を説明する。なお、プレゼンスサーバ装置１００の装置構成および状態変化条件設定動作については第１の実施の形態と同様であるため説明を省略する。また、管理者端末１０３の装置構成および動作についても第１の実施の形態と同様であるため説明を省略する。
【０１５１】
まず、プレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作について図３と図１８を参照して説明する。図１８は本実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図である。
【０１５２】
最初に、通信部２０５がPUBLISHメッセージを受信し（Ｓ５０１）、受信したPUBLISHメッセージを制御部２０１に送る（Ｓ５０２）。制御部２０１はPUBLISHメッセージに記述された状態を状態管理データベース２０２に保存する（Ｓ５０３）。このとき状態管理データベース２０２は少なくとも一つの状態項目とその状態項目の状態値の変化履歴を保持しており、PUBLISHメッセージに記述された状態を最新状態値として変化履歴を更新する。
【０１５３】
例えばPUBLISHメッセージに内勤者端末１０２のユーザ１２２が在席していることを表す「sip:102@example.com:presence="open"」という状態が記述されていた場合は、それを最新の状態として保持し、すでに保持してあった状態を過去の状態として更新する。なお、状態管理データベース２０２で保存されるデータ構造については後述する。
【０１５４】
制御部２０１は状態変化条件保持部２０３に保存されている状態変化条件と通知先ＵＲＩを取得し（Ｓ５０４）、状態変化条件により指定されたユーザ１２１の状態の履歴を状態管理データベース２０２から取得する（Ｓ５０５）。ここで、取得したユーザ１２１の変化履歴が、状態変化条件により指定された変化履歴の条件を満たすか判定する（Ｓ５０６）。変化履歴の条件を満たさない場合はNOTIFYメッセージを生成せずに終了する。変化履歴の条件を満たす場合は、ステップＳ５０７に進み、NOTIFYメッセージを生成して送信する。なお、ステップＳ５０７からＳ５１０までの工程は第２の実施の形態のステップＳ３０６からＳ３０９までの工程と同様であるため説明を省略する。
【０１５５】
次に本実施の形態におけるNOTIFYメッセージについて説明する。
【０１５６】
図１９は本実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図である。
【０１５７】
Request-ＵＲＩとして状態変化条件保持部の通知先ＵＲＩに保持された管理者端末１０３のＵＲＩが記述される。Eventヘッダには、時間変化に関するイベントを表す"Time-Filter"と記述する。ボディ部には状態管理データベース２０２から取得した状態と、状態が変化した時刻の履歴が記述される。なお、状態および状態が変化した時刻の履歴は拡張ヘッダを使ってヘッダ部に記述してもよい。
【０１５８】
次に、状態管理データベース２０２で保存されるデータの構造について説明する。なお、状態変化条件保持部２０３で保存されるデータの構造については図１０で示された説明した第１の実施の形態における状態変化条件保持部２０３で保存されるデータの構造と同様であるため説明を省略する。
【０１５９】
図２０は本実施の形態における状態管理データベース２０２で保存されるデータの構造を示すブロック図である。
【０１６０】
状態管理データベース２０２はプレゼンスサーバ装置１００が管理する全ての機器のＵＲＩと状態を保持するデータベースであり、機器のＵＲＩと、それぞれの機器について1つ以上の状態項目とその状態項目の状態値および状態が変化した時刻についてそれぞれ変化履歴が保存されている。
【０１６１】
図２０に示された例では、「sip:101@example.com」というＵＲＩを持つ機器は、状態項目"place"に対して、休憩室を示す"rest_room"という状態値を持ち、状態変化時刻は日本時間で１０時５８分５１秒であるということを示す"10:58:51 +900"という値を持つことを示し、状態項目とその状態項目の状態値および状態変化時刻の履歴を複数保持する。なお、図１９では変化履歴として３つの状態の変化の履歴の履歴変化情報が保存されているが、保存する履歴変化情報の状態の変化の履歴の数はそれより多くても少なくてもよいし、一定時間内に変化した状態の変化の履歴の履歴変化情報だけを保存してもよい。
【０１６２】
以上説明したように本実施の形態では、ユーザ１３０がプレゼンスサーバ装置１００に対して「外勤者端末１０１の場所が休憩室→喫煙室→休憩室と状態変化した場合だけ通知」という状態変化条件を設定し、プレゼンスサーバ装置１００は外勤者端末１０１のユーザ１２１の状態の変化の履歴が状態変化条件を満たすときだけ管理者端末１０３に対してNOTIFYメッセージを送信する例を示した。これによって、不要なNOTIFYメッセージが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ装置１００と管理者端末１０３のNOTIFYメッセージの送受信に関わる負荷が軽減される。
【０１６３】
なお、本実施の形態ではプレゼンスサーバ装置１００が外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態変化履歴を保持し、それが状態変化条件を満たしていると判定された場合にNOTIFYメッセージを送信していたが、状態変化履歴の保持および状態変化条件の判定の機能を管理者端末１０３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置１００は外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態が変化するたびに管理者端末１０３にNOTIFYメッセージを送信する。管理者端末１０３は受信したNOTIFYメッセージの状態変化履歴を保持し、それが管理者端末１０３に予め設定された状態変化条件を満たしていると判定された場合にユーザに対して状態の通知を行うことにより、ユーザは必要なタイミングでの状態通知を受けることができる。さらに本実施の形態では、状態変化条件として状態変化時刻、状態項目とその状態項目の状態値の履歴情報を指定しているがこれに限定されることはない。状態継続時間、一つ以上の状態項目とその状態項目の状態値の履歴情報、あるいは状態継続時間、状態変化時間、一つ以上の状態項目とその状態項目の履歴情報の組み合わせなど様々な状態変化条件を指定することが可能である。また、本実施の形態では、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２が状態発行体を構成し、ユーザ１２１、１２２の状態の変化を通知の対象としているが外勤者端末１０１、内勤者端末１０２が状態発行体を構成し、外勤者端末１０１、内勤者端末１０２自体の状態の状態を通知の対象とするなど、様々な人やものの状態を通知の対象としてもよいことは言うまでもない。
（第５の実施の形態）
【０１６４】
本発明の第５の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成は第１の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成と同様であるため同一の符号を付して説明を省略する。
【０１６５】
本実施の形態では、ユーザ１３０はプレゼンスサーバ装置１００に対して状態通知要求を行う際に複数の機器またはユーザに個別に対応する複数の個別の状態変化条件と、それら複数の個別の状態変化条件間の論理条件を指定する全体の状態変化条件を入力して設定しているものとする。一例として、外勤者端末１０１のユーザ１２１の個別の状態変化条件と内勤者端末１０２のユーザ１２２の個別の状態変化条件間の論理積である、「外勤者端末１０１のユーザ１２１の場所が居室である状態が１０分以上継続し、かつ、内勤者端末１０２のユーザ１２２のプレゼンス状態が在席である状態が１０分以上継続した場合にだけ通知」という論理条件が全体の状態変化条件として設定され、プレゼンスサーバ装置１００は外勤者端末１０１のユーザ１２１の場所が居室である状態が１０分以上継続し、かつ、内勤者端末１０２のユーザ１２２のプレゼンス状態が在席である状態が１０分以上継続した場合にだけ状態通知を行う場合について説明する。
【０１６６】
まず、図２１を参照して本実施の形態のメッセージフローを説明する。
【０１６７】
外勤者端末１０１、内勤者端末１０２はプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信し、それぞれユーザ１２１、１２２の状態を予め登録しておく。
【０１６８】
ユーザ１３０はプレゼンスサーバ装置１００に対して、状態変化条件として「外勤者端末１０１のユーザ１２１の場所が居室である状態が１０分以上継続し、かつ、内勤者端末１０２のユーザ１２２のプレゼンス状態が在席である状態が１０分以上継続した場合にだけ通知」を設定し、通知先ＵＲＩとして管理者端末１０３のＵＲＩである「sip:103@example.com」を設定しておく。
【０１６９】
外勤者端末１０１、内勤者端末１０２はそれぞれユーザ１２１、１２２の状態が変化するたびにプレゼンスサーバ装置１００に対してPUBLISHメッセージを送信する。プレゼンスサーバ装置１００はPUBLISHメッセージを受信すると、それぞれの個別の状態変化条件に記述された時間分のタイマーを設定し、タイマー終了後に一方の機器またはユーザの状態が変化していない場合、他方の機器またはユーザの状態の履歴を参照し、他方の機器またはユーザの状態も該当する個別の状態変化条件を満たす場合だけ管理者端末１０３に対してNOTIFYメッセージを送信する。
【０１７０】
次にプレゼンスサーバ装置１００で実行される動作について詳細を説明する。なお、プレゼンスサーバ装置１００の装置構成および状態変化条件設定動作については第４の実施の形態と同様であるため説明を省略する。また、管理者端末１０３の装置構成および動作については第１の実施の形態と同様であるため説明を省略する。
【０１７１】
まず、プレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作について図３と図２２を参照して説明する。図２２は本実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図である。
【０１７２】
ここで、ステップＳ６０１からＳ６０４までの工程については第４の実施の形態のステップＳ５０１からＳ５０４までの工程と同様であるため説明を省略する。制御部２０１はステップＳ６０４で取得したそれぞれの個別の状態変化条件に記述された状態継続時間分のタイマーを開始する（Ｓ６０５）。タイマーが終了すると（Ｓ６０６）、PUBLISHメッセージに記述された一方の機器またはユーザの状態を状態管理データベース２０２から取得し（Ｓ６０７）、状態が変化したか判定する（Ｓ６０８）。状態が変化した場合はNOTIFYメッセージを生成せずに終了する。状態が変化しなかった場合はその機器またはユーザに関する個別の状態変化条件で指定された状態継続時間を超えたと判断し、ステップＳ６０９に進む。その後、状態管理データベース２０２から状態変化条件に記述されている他方の機器またはユーザの状態の履歴を取得して（Ｓ６０９）、取得した状態の履歴から状態継続時間を計算し、他方の機器またはユーザの状態に関する個別の状態変化条件が指定した状態継続時間を超えているか判定する（Ｓ６１０）。超えていない場合はNOTIFYメッセージを生成せずに終了する。超えている場合は、全ての状態変化条件、すなわち指定された個別の状態変化条件間の論理条件を満たしていると判断してステップＳ６１１に進み、NOTIFYメッセージを生成して送信する。なお、本実施の形態では、複数の個別の状態変化条件間の論理条件として全ての個別の状態変化条件を満たす場合(AND条件)のみNOTIFYメッセージを送信する例を挙げたが、複数の個別の状態変化条件間の論理条件として、一つ以上の個別の状態変化条件を満たす場合(OR条件)、もしくは満たさない場合(NOT条件)のみNOTIFYメッセージを送信する場合も可能であり、論理積以外のその他の論理条件であってもよいこと言うまでもない。また、ステップＳ６１１からＳ６１４までの工程については第２の実施の形態のステップＳ３０６からＳ３０９までの工程と同様であるため説明を省略する。
【０１７３】
次に本実施の形態におけるNOTIFYメッセージメッセージについて説明する。
【０１７４】
図２３は本実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図である
【０１７５】
Request-ＵＲＩとして状態変化条件保持部の通知先ＵＲＩに保持された管理者端末１０３のＵＲＩが記述される。Eventヘッダには、状態の時間状態変化に関するイベントを表す"Time-Filter"と記述する。ボディ部には状態管理データベース２０２から取得した複数の機器またはユーザの状態、すなわち外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態と、状態が変化した時刻が記述される。なお、状態および状態が変化した時刻は拡張ヘッダを使ってヘッダ部に記述してもよい。
【０１７６】
以上説明したように本実施の形態では、ユーザ１３０がプレゼンスサーバ装置１００に対して「外勤者端末１０１のユーザ１２１の場所が居室である状態が１０分以上継続し、かつ、内勤者端末１０２のユーザ１２２のプレゼンス状態が在席である状態が１０分以上継続した場合にだけ通知」という個別の状態変化条件間の論理条件を設定し、プレゼンスサーバ装置１００は上述の個別の状態変化条件間の論理条件が満たされるときだけ管理者端末１０３に対してNOTIFYメッセージを送信する例を示した。これによって、不要なNOTIFYメッセージが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ装置１００と管理者端末１０３のNOTIFYメッセージの送受信に関わる負荷が軽減される。
【０１７７】
なお、本実施の形態ではプレゼンスサーバ装置１００が外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態変化履歴および状態継続時間を保持し、それが状態変化条件を満たしていると判定された場合にNOTIFYメッセージを送信していたが、状態変化履歴および状態継続時間の保持と状態変化条件の判定の機能を管理者端末１０３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置１００は外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態が変化するたびに管理者端末１０３にNOTIFYメッセージを送信する。管理者端末１０３は受信したNOTIFYメッセージの状態変化履歴と状態継続時間を保持し、それが管理者端末１０３に予め設定された状態変化条件を満たしていると判定された場合にユーザに対して状態の通知を行うことにより、ユーザは必要なタイミングでの状態通知を受けることができる。また、本実施の形態では、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２が状態発行体を構成し、ユーザ１２１、１２２の状態の変化を通知の対象としているが、外勤者端末１０１、内勤者端末１０２が状態発行体を構成し、外勤者端末１０１、内勤者端末１０２自体の状態の変化を通知の対象とするなど、様々な人やものの状態を対象としてもよいことは言うまでもない。
（第６の実施の形態）
【０１７８】
本発明の第６の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成は管理者端末１０３およびプレゼンスサーバ装置１００に代わり管理者端末１１３およびプレゼンスサーバ装置４００を備えている。同一の構成および同一の処理については説明を省略する。
【０１７９】
本実施の形態では、管理者端末１１３はプレゼンスサーバ装置４００に対して状態通知要求を行う際に、プレゼンスサーバ装置４００の画面から入力を行うのではなく、状態変化条件を記述したSUBSCRIBEメッセージを送信するものとする。一例として管理者端末１１３は、「１分以上同一の状態が継続した場合だけ通知」という状態変化条件を記述したSUBSCRIBEメッセージを送信し、プレゼンスサーバ装置４００は受信したSUBSCRIBEメッセージに記述された状態変化条件を設定して、状態変化条件を満たすときのみ状態通知を行う場合について説明する。
【０１８０】
最初に図２４を用いて本実施の形態のメッセージフローを説明する。外勤者端末１０１、内勤者端末１０２はプレゼンスサーバ装置４００に対してPUBLISHメッセージを送信し、それぞれユーザ１２１、１２２の状態を予め登録しておく。管理者端末１１３はプレゼンスサーバ装置４００に対して、状態変化条件と通知先ＵＲＩを記述したSUBSCRIBEメッセージを送信する。ここでは状態変化条件として「１分以上同一の状態が継続した場合だけ通知」を記述し、通知先ＵＲＩとして管理者端末１１３のＵＲＩである「sip:103@example.com」を記述しておく。プレゼンスサーバ装置４００はSUBSCRIBEメッセージを受信すると、そこに記述された状態変化条件と通知先ＵＲＩを保持しておく。
【０１８１】
外勤者端末１０１、内勤者端末１０２はそれぞれユーザ１２１、１２２の状態が変化するたびにプレゼンスサーバ装置４００に対してPUBLISHメッセージを送信する。プレゼンスサーバ装置４００はPUBLISHメッセージを受信すると、状態変化条件に記述された時間分のタイマーを設定し、タイマー終了後に状態が変化していない場合だけ管理者端末１１３に対してNOTIFYメッセージを送信する。
【０１８２】
最初に管理者端末１１３の構成と管理者端末１１３がSUBSCRIBEメッセージを送信する際に実行する動作について、図２５と図２６を参照して説明する。図２５は本実施の形態における管理者端末１１３の構成を示すブロック図であり、図２６は本実施の形態における管理者端末１１３がSUBSCRIBEメッセージを送信する際に実行する動作を示すフロー図である。
【０１８３】
管理者端末１１３の構成について説明する。管理者端末１１３は、図２５に示されるように、管理者端末１１３を構成する全ての構成部品の動作を制御する制御部４０１と、管理者端末１１３の図示されていない画面に情報を出力する画面出力部４０２と、画面から入力された情報を入力する入力受信部４０３、通知先ＵＲＩおよび状態情報を含む信号を生成するメッセージ生成部４０４、プレゼンスサーバ装置４００、外勤者端末１０１、内勤者端末１０２など外部の機器と信号の送受信を行う通信部４０５とから構成されている。画面出力部４０２と入力受信部４０３は、例えば、タッチパネルなどで構成されてもよい。
【０１８４】
最初に、制御部４０１は状態変化条件を入力する画面を表示する命令を画面出力部４０２に送り（Ｓ７０１）、ユーザ１３０からの入力を待つ（Ｓ７０２）。ユーザ１３０から状態変化条件が入力されるとその情報が入力受信部４０３から制御部４０１へ送られる（Ｓ７０３）。ここでは状態変化条件として「１分以上同一の状態が継続した場合だけ通知」という条件が入力されたものとする。
【０１８５】
制御部４０１は入力された条件を状態変化条件のフォーマットに変換する（Ｓ７０４）。ここでは「Continuing_time>=1min」という状態変化条件に変換する。
【０１８６】
制御部４０１は変換した状態変化条件をメッセージ生成部４０４に送り（Ｓ７０５）、メッセージ生成部４０４は状態変化条件を記述したSUBSCRIBEメッセージを生成する（Ｓ７０６）。メッセージ生成部４０４は生成したSUBSCRIBEメッセージを通信部４０５に送り（Ｓ７０７）、通信部４０５は受け取ったSUBSCRIBEメッセージをプレゼンスサーバ装置４００に向けて送信する（Ｓ７０８）。ここでプレゼンスサーバ４００のアドレスは管理者端末１１３に予め設定されていてもよいし、ユーザが入力画面から入力してもよい。SUBSCRIBEメッセージのデータに関する詳細は後述する。
【０１８７】
次にプレゼンスサーバ装置４００の構成とSUBSCRIBEメッセージ受信動作について図２７と図２８を参照して説明する。図２７は本実施の形態におけるプレゼンスサーバ装置４００の構成を示すブロック図であり、図２８は本実施の形態におけるプレゼンスサーバ装置４００がSUBSCRIBEメッセージを受信する際に実行する動作を示すフロー図である。なお、プレゼンスサーバ装置４００がPUBLISHメッセージ受信後に実行する動作については第１の実施の形態と同様であるため説明を省略する。また、状態管理データベース５０２と状態変化条件保持部５０３のデータ構造についても第１の実施の形態と同様であるため説明を省略する。
【０１８８】
まず、プレゼンスサーバ装置４００の構成について説明する。プレゼンスサーバ装置４００は、図２７に示されるように、プレゼンスサーバ装置４００を構成する全ての構成部品の動作を制御する制御部５０１と、プレゼンスサーバ装置４００が管理する全ての機器のＵＲＩと状態を保存する状態管理データベース５０２と、状態変化条件と通知先ＵＲＩを保存する状態変化条件保持部５０３と、通知先ＵＲＩおよび状態情報を含む信号を生成するメッセージ生成部５０４と、外勤者端末１０１、内勤者端末１０２、管理者端末１１３など外部の機器と信号の送受信を行う通信部５０５とを備えている。
【０１８９】
図２８は本実施の形態におけるプレゼンスサーバ装置４００がSUBSCRIBEメッセージを受信する際に実行する動作を示すフロー図である。
【０１９０】
最初に、通信部５０５がSUBSCRIBEメッセージを受信し（Ｓ７１０）、受信したSUBSCRIBEメッセージを制御部５０１に送る（Ｓ７１１）。制御部５０１はSUBSCRIBEメッセージに記述された状態変化条件と通知先ＵＲＩを状態変化条件保持部５０３に保存する（Ｓ７１２）。ここでは状態変化条件として「Continuing_time>=1min」が記述されているのでこれを保存する。通知先ＵＲＩとしてはSUBSCRIBEメッセージのContactヘッダに記述されたＵＲＩを保存する。
【０１９１】
その後、プレゼンスサーバ装置４００はSUBSCRIBEメッセージに対する最初のNOTIFYメッセージを送信してもよい。最初のNOTIFYメッセージ送信については通常のＳＩＰ手順と同様であるため説明を省略する。
【０１９２】
次に本実施の形態におけるSUBSCRIBEメッセージメッセージについて説明する。なお、NOTIFYメッセージに含まれるメッセージの詳細は第１の実施の形態と同様のため省略する。
【０１９３】
SUBSCRIBEメッセージについて図２９を参照して説明する。図２９は本実施の形態における管理者端末１１３からプレゼンスサーバ装置４００に送信されるSUBSCRIBEメッセージのデータの構造を示す図である。
【０１９４】
Contactヘッダには、通知先ＵＲＩ、Request-ＵＲＩとして、管理者端末１１３に予め設定された任意のアドレス（anonymous@anywhereなど）が記述される。Eventヘッダには、機器の時間変化状態を指定したフィルタを示す"Time-Filter"と記述する。ボディ部には状態変化条件を記述する。なお、状態変化条件は拡張ヘッダを使ってヘッダ部に記述してもよい。
【０１９５】
本実施の形態では、通信部４０５がプレゼンスサーバ装置４００から外勤者端末１０１のユーザ１２１、内勤者端末１０２のユーザ１２２の状態を示す信号を受信する状態情報受信手段、および状態変化条件を設定する変化条件情報パケットをプレゼンスサーバ装置４００へ送信する変化条件送信手段を構成している。
【０１９６】
通信部５０５は、管理者端末１１３から送信される変化条件情報パケットを受信する変化条件情報受信手段を構成し、状態変化条件保持部５０３は通信部５０５により受信された変化条件情報パケットに基づいて状態変化条件を保存する状態変化条件設定手段を構成する。
【０１９７】
状態管理データベース５０２は、通信部５０５を介して受信する外勤者端末１０１と内勤者端末１０２からユーザ１２１とユーザ１２２の状態情報に基づいてユーザ１２１とユーザ１２２の状態変化情報を保存するようになっており、状態変化情報保存手段を構成する。
【０１９８】
制御部５０１は、状態管理データベース５０２に保存された外勤者端末１０１のユーザ１２１と内勤者端末１０２のユーザ１２２の状態変化情報と状態変化条件保持部５０３に保存された状態変化条件を比較して、ユーザ１２１とユーザ１２２の状態が所定の程度を超えて変化したか否かを判定するようになっており、状態変化判定手段を構成している。
【０１９９】
さらに通信部５０５は、ユーザの状態が所定の程度を超えて変化したと制御部５０１により判定された場合に、管理者端末１１３に状態情報を含むNOTIFYメッセージを送信するようになっており、状態変化通知情報送信手段を構成している。
【０２００】
以上説明したように本実施の形態では、管理者端末１１３がプレゼンスサーバ装置４００に対して状態変化条件を記述したSUBSCRIBEメッセージを送信し、プレゼンスサーバ装置４００は状態変化条件を満たすときだけNOTIFYメッセージを送信する例を示した。これによって、状態変化条件を管理者端末１１３が指定することが可能となり、より適切なタイミングでNOTIFYメッセージが送信され、不要なNOTIFYメッセージが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ装置４００と管理者端末１１３のNOTIFYメッセージの送受信に関わる負荷が軽減される。
【０２０１】
なお、本実施の形態ではプレゼンスサーバ装置４００が外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２の状態継続時間を計測し、それが状態変化条件で示された状態継続時間以上と判定された場合にNOTIFYメッセージを送信していたが、状態継続時間の計測および判定の機能を管理者端末１１３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置４００は外勤者端末１０１と内勤者端末１０２のユーザ１２１、１２２の状態が変化するたびに管理者端末１１３にNOTIFYメッセージを送信する。管理者端末１１３は受信したNOTIFYメッセージから状態継続時間を計測し、それが管理者端末１１３に予め設定された状態変化条件で示された状態継続時間以上と判定された場合にユーザに対して状態の通知を行うことにより、ユーザは必要なタイミングでの状態通知を受けることができる。また、本実施の形態では、外勤者端末１０１、内勤者端末１０２のユーザ１２１、１２２が状態発行体を構成し、ユーザ１２１、１２２の状態の変化を通知の対象としているが、外勤者端末１０１、内勤者端末１０２が状態発行体を構成し、外勤者端末１０１、内勤者端末１０２自体の状態の変化を通知の対象とするなど、様々な人やものの状態を対象としてもよいことは言うまでもない。
（第７の実施の形態）
【０２０２】
図３０は第７の実施の形態のプレゼンスサーバ装置、管理者端末およびネットワークシステムの構成を示すブロック図である。
【０２０３】
図３０においてネットワークシステムは、内勤者端末６０１、外勤者端末６０２、管理者端末６０３とを備え、内勤者端末６０１、外勤者端末６０２、管理者端末６０３はネットワーク６１０を介して相互に接続されている。内勤者端末６０１はユーザ６２１が操作する、例えばＰＣなどの機器であり、外勤者端末６０２はユーザ６２２が操作する、例えば携帯電話、ＰＤＡなどの機器である。ここで内勤者端末６０１は第６の実施の形態のプレゼンスサーバ装置４００と同様の構成を有し、さらに内勤者端末６０１自体の状態変化情報を設定するようになっている。すなわち、内勤者端末６０１を構成する状態管理データベースは、他の機器のＵＲＩと状態とともに内勤者端末６０１自体または内勤者端末６０１を操作するユーザ６２１の状態も保存し、内勤者端末６０１を構成する状態変化条件保持部は内勤者端末６０１自体またはユーザ６２１の状態変化条件も保存し、内勤者端末６０１を構成する制御部は、状態管理データベースに保存された内勤者端末６０１自体またはユーザ６２１の状態変化情報も状態変化条件保持部に保存された状態変化条件と比較して、状態が所定の程度を超えて変化したか否かを判定するようになっている。管理者端末６０３はユーザ６３０が操作する、例えばＰＣなどの機器である。さらに管理者端末６０３は第６の実施の形態の管理者端末１０３と同様の構成を有しているものとする。管理者端末６０３は内勤者端末６０１、外勤者端末６０２のユーザ６２１、６２２の状態の通知を望み、内勤者端末６０１または外勤者端末６０２のいずれかに状態通知要求を送る。ここでは内勤者端末６０１に対して、「外勤者端末６０２のユーザ６２２の場所が居室である状態が１０分以上継続し、かつ、内勤者端末６０１のユーザ６２１のプレゼンス状態が在席である状態が１０分以上継続した場合にだけ通知」という状態変化条件を指定した状態通知要求を送り、内勤者端末６０１は外勤者端末６０２に対して状態通知要求を送って外勤者端末６０２のユーザ６２２の状態を取得し、状態変化条件を満たすときのみ状態通知を行う例を示す。
【０２０４】
最初に、図３１を用いて本実施の形態のメッセージフローを説明する。
【０２０５】
管理者端末６０３は内勤者端末６０１に対して状態変化条件を記述したSUBSCRIBEメッセージを送信する。このとき状態変化条件としては「外勤者端末６０２のユーザ６２２の場所が居室である状態が１０分以上継続し、かつ、内勤者端末６０１のユーザ６２１のプレゼンス状態がopenである状態が１０分以上継続した場合にだけ通知」という条件を表す以下のメッセージをＳＩＰボディ部に記述する。
【０２０６】
「sip:602@example.com;place="desk"; Continuing_time>=10min AND 
sip:601@example.com;presence="open"; Continuing_time>=10min」
【０２０７】
内勤者端末６０１はSUBSCRIBEメッセージを受信すると、外勤者端末６０２に対して場所状態の通知要求を行うSUBSCRIBEメッセージを送信する。外勤者端末６０２はSUBSCRIBEメッセージを受信すると場所状態を記述したNOTIFYメッセージを内勤者端末６０１に送信する。内勤者端末６０１は外勤者端末６０２からNOTIFYメッセージを受信した場合、または内勤者端末６０１のユーザ６２１自身の場所状態が変化した場合に状態変化条件に記述された時間分のタイマーを設定し、タイマー終了後にユーザ６２１の状態が変化していない場合、状態変化条件に記述された他の機器またはユーザの状態の履歴を参照し、他の機器またはユーザの状態も状態変化条件を満たす場合だけ管理者端末６０３に対してNOTIFYメッセージを送信する。
【０２０８】
次に内勤者端末６０１の動作について詳細を説明する。なお、内勤者端末６０１の構成については、内勤者端末６０１を構成する状態管理データベースは、他の機器のＵＲＩと状態とともに内勤者端末６０１自体または内勤者端末６０１を操作するユーザ６２１の状態も保存し、内勤者端末６０１を構成する状態変化条件保持部は内勤者端末６０１自体またはユーザ６２１の状態変化条件も保存し、内勤者端末６０１を構成する制御部は、状態管理データベースに保存された内勤者端末６０１自体またはユーザ６２１の状態変化情報も状態変化条件保持部に保存された状態変化条件と比較して、状態が所定の程度を超えて変化したか否かを判定するようになっている点以外は第６の実施の形態のプレゼンスサーバ装置４００と同様であるため同一の符号を付して説明を省略する。また、管理者端末６０３の構成と動作については第６の実施の形態の管理者端末１０３と同様であるため同一の符号を付して説明を省略する。  
【０２０９】
最初に内勤者端末６０１がSUBSCRIBEメッセージを受信する際に実行する動作について図２７と図３２を参照して説明する。図３２は本実施の形態における内勤者端末６０１がSUBSCRIBEメッセージを受信する際に実行する動作を示すフロー図である。
【０２１０】
最初に通信部５０５がSUBSCRIBEメッセージを受信し（Ｓ８０１）、受信したSUBSCRIBEメッセージを制御部５０１に送る（Ｓ８０２）。制御部５０１はSUBSCRIBEメッセージに記述された状態変化条件と通知先ＵＲＩを状態変化条件保持部５０３に保存する（Ｓ８０３）。ここでは状態変化条件が以下のように記述され、通知先ＵＲＩとして管理者端末６０３のＵＲＩがContactヘッダに記述されているものとする。
「sip:602@example.com;place="desk"; Continuing_time>=10min AND 
sip:601@example.com;presence="open"; Continuing_time>=10min」
【０２１１】
その後、状態変化条件に記述された外勤者端末６０２のＵＲＩおよび状態変化条件をメッセージ生成部５０４に送る（Ｓ８０４）。メッセージ生成部５０４は受け取ったＵＲＩをRequest-ＵＲＩに記述したSUBSCRIBEメッセージを生成し（Ｓ８０５）、それを通信部５０５に送る（Ｓ８０６）。通信部５０５はSUBSCRIBEメッセージを外勤者端末６０２に送信し（Ｓ８０７）、SUBSCRIBEメッセージに対するNOTIFYメッセージの受信を待つ（Ｓ８０８）。
【０２１２】
外勤者端末６０２からのNOTIFYメッセージを通信部５０５が受信すると（Ｓ８０９）、通信部５０５は受信したNOTIFYメッセージを制御部５０１に送る（Ｓ８１０）。制御部５０１はNOTIFYメッセージに記述された状態を状態管理データベース５０２に保存する（Ｓ８１１）。その後、外勤者端末６０２はSUBSCRIBEメッセージに対する最初のNOTIFYメッセージを送信してもよい。
【０２１３】
次に内勤者端末６０１がNOTIFYメッセージを送信する際に実行する動作について図２７と図３３を参照して説明する。図３３は本実施の形態における内勤者端末６０１がNOTIFYメッセージを送信する際に実行する動作を示すフロー図である。
【０２１４】
通信部５０５は最初に外勤者端末６０２からのNOTIFYメッセージを受信するか、または内勤者端末６０１自身の状態が変化するのを待つ（Ｓ９０１）、外勤者端末６０２からNOTIFYメッセージを受信するか、内勤者端末６０１自身の状態が変化すると（Ｓ９０２）、受信したNOTIFYメッセージに記述された状態か、または内勤者端末６０１自身の変化した状態を状態管理データベース５０２に保存する（Ｓ９０３）。ここで、Ｓ９０４からＳ９１４までの工程については第６の実施の形態のＳ６０４からＳ６１４までの工程と同様であるため説明を省略する。
【０２１５】
なお、Ｓ９０４からＳ９１４までのステップは内勤者端末６０１自身の状態が変化し、状態管理データベース５０２に保存されている状態を変更した場合にも実行され、必要に応じてNOTIFYメッセージが生成される。
【０２１６】
以上説明したように本実施の形態では、管理者端末６０３が内勤者端末６０１に対して状態変化条件を記述したSUBSCRIBEメッセージを送信し、内勤者端末６０１は状態変化条件に記述された状態を取得するために外勤者端末６０２にSUBSCRIBEメッセージを送信し状態を取得し、状態変化条件を満たすときだけNOTIFYメッセージを送信する例を示した。これによって、プレゼンスサーバ装置が無い場合でも状態変化条件を指定することができ、ネットワークリソースを有効に使用できるとともに、内勤者端末６０１と管理者端末６０３のNOTIFYメッセージの送受信に関わる負荷が軽減される。また、本実施の形態のような構成をとることにより、サーバメンテナンスの必要がなくなる。
【０２１７】
なお、本実施の形態ではプレゼンスサーバ装置の機能を実行する内勤者端末６０１が内勤者端末６０１、外勤者端末６０２の状態変化履歴および状態継続時間を保持し、それが状態変化条件を満たしていると判定された場合にNOTIFYメッセージを管理者端末６０３に送信していたが、状態変化履歴および状態継続時間の保持と状態変化条件の判定の機能を管理者端末６０３に持たせても、ユーザが必要なタイミングでの状態通知が可能となる。例えばプレゼンスサーバ装置の機能を実行する内勤者端末６０１が内勤者端末６０１、外勤者端末６０２の状態が変化するたびに管理者端末６０３にNOTIFYメッセージを送信する。管理者端末６０３は受信したNOTIFYメッセージの状態変化履歴と状態継続時間を保持し、それが管理者端末６０３に予め設定された状態変化条件を満たしていると判定された場合にユーザ６３０に対して状態の通知を行うことにより、ユーザ６３０は必要なタイミングでの状態通知を受けることができる。本実施の形態では、内勤者端末６０１、外勤者端末６０２のユーザ６２１、６２２が状態発行体を構成し、ユーザ６２１、６２２の状態の変化を通知の対象としているが、内勤者端末６０１、外勤者端末６０２が状態発行体を構成し、内勤者端末６０１、外勤者端末６０２自体の状態の変化を通知の対象とするなど、様々な人やものの状態を通知の対象としてもよいことは言うまでもない。
【産業上の利用可能性】
【０２１８】
以上のように、本発明に係る通知装置、被通知装置および通知方法は、ネットワークに接続された装置の状態を通知する際に、不要な通知を減らすことにより、ネットワークリソースを有効に利用できるとともにプレゼンスサーバの処理負担を軽減することができるという効果を有し、プレゼンスサービスや機器またはユーザの状態管理サービスにおけるサーバの負荷軽減方法等として有用である。
【図面の簡単な説明】
【０２１９】
【図１】第１の実施の形態の通知装置および被通知装置を適用したネットワークシステムの構成を示すブロック図
【図２】図１に示すネットワークシステムのメッセージフローを示すシーケンス図
【図３】第１の実施の形態におけるプレゼンスサーバ装置の構成を示すブロック図
【図４】第１の実施の形態におけるプレゼンスサーバ装置が状態変化条件を設定する際に実行する動作を示すフロー図
【図５】第１の実施の形態におけるプレゼンスサーバ装置がPUBLISHメッセージ受信後に実行する動作を示すフロー図
【図６】第１の実施の形態における管理者端末１０３の構成を示すブロック図
【図７】第１の実施の形態における管理者端末１０３がNOTIFYメッセージの受信後に実行する動作を示すフロー図
【図８】第１の実施の形態におけるプレゼンスサーバ１００装置から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図
【図９】第１の実施の形態におけるプレゼンスサーバ装置１００の状態管理データベース２０２で保存されるデータの構造を示すブロック図
【図１０】第１の実施の形態におけるプレゼンスサーバ装置１００の状態変化条件保持部２０３で保存されるデータの構造を示すブロック図
【図１１】第２の実施の形態におけるネットワークシステムのメッセージフローを示すシーケンス図
【図１２】第２の実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図
【図１３】第２の実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図
【図１４】第２の実施の形態におけるプレゼンスサーバ装置１００の状態管理データベース２０２で保存されるデータの構造を示すブロック図
【図１５】第３の実施の形態におけるネットワークシステムのメッセージフローを示すシーケンス図
【図１６】第３の実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図
【図１７】第４の実施の形態におけるネットワークシステムのメッセージフローを示すシーケンス図
【図１８】第４の実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図
【図１９】第４の実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図
【図２０】第４の実施の形態におけるプレゼンスサーバ装置１００の状態管理データベース２０２で保存されるデータの構造を示すブロック図
【図２１】第５の実施の形態におけるネットワークシステムのメッセージフローを示すシーケンス図
【図２２】第５の実施の形態におけるプレゼンスサーバ装置１００がPUBLISHメッセージ受信後に実行する動作を示すフロー図
【図２３】第５の実施の形態におけるプレゼンスサーバ装置１００から管理者端末１０３に送信されるNOTIFYメッセージのデータの構造を示すブロック図
【図２４】第６の実施の形態におけるネットワークシステムのメッセージフローを示すシーケンス図
【図２５】第６の実施の形態における管理者端末１１３の構成を示すブロック図
【図２６】第６の実施の形態における管理者端末１１３がSUBSCRIBEメッセージを送信する際に実行する動作を示すフロー図
【図２７】第６の実施の形態におけるプレゼンスサーバ装置４００の構成を示すブロック図
【図２８】第６の実施の形態におけるプレゼンスサーバ装置４００がSUBSCRIBEメッセージを受信する際に実行する動作を示すフロー図
【図２９】第６の実施の形態における管理者端末１１３からプレゼンスサーバ装置４００に送信されるSUBSCRIBEメッセージのデータの構造を示す図
【図３０】第７の実施の形態の通知装置および被通知装置を適用したネットワークシステムの構成を示すブロック図
【図３１】第７の実施の形態におけるネットワークシステムのメッセージフローを示すシーケンス図
【図３２】第７の実施の形態における内勤者端末６０１がSUBSCRIBEメッセージを受信する際に実行する動作を示すフロー図
【図３３】第７の実施の形態における内勤者端末６０１がNOTIFYメッセージを送信する際に実行する動作を示すフロー図
【図３４】従来のＳＩＰイベント通知機能を使ったプレゼンスサービスにおけるネットワーク構成の一例を示す図
【図３５】従来のＳＩＰプロトコルに準拠したプレゼンスサービスにおけるメッセージフローの一例を示す図
【図３６】従来のイベントフィルタのメッセージフローの一例を示す図
【符号の説明】
【０２２０】
１００、４００、７００  プレゼンスサーバ装置
１０１、６０２  外勤者端末
１０２、６０１  内勤者端末
１０３、１１３、６０３  管理者端末
７０１、７０２、７０３、７０４  パーソナルコンピュータ
１１０、６１０、７１０ ネットワーク（ＬＡＮ）
１２１、１２２、１３０、６２１、６２２、６３０ ユーザ
２０１  プレゼンスサーバ装置の制御部
２０２  プレゼンスサーバ装置の状態管理データベース
２０３  プレゼンスサーバ装置の状態変化条件保持部
２０４  プレゼンスサーバ装置のメッセージ生成部
２０５  プレゼンスサーバ装置の通信部
２０６  プレゼンスサーバ装置の画面出力部 
２０７  プレゼンスサーバ装置の入力受信部
３０１  管理者端末の制御部
３０２  管理者端末の画面出力部
３０３  管理者端末の通信部
４０１  管理者端末の制御部
４０２  管理者端末の画面出力部
４０３  管理者端末の入力受信部
４０４  管理者端末のメッセージ生成部
４０５  管理者端末の通信部
５０１  プレゼンスサーバ装置の制御部
５０２  プレゼンスサーバ装置の状態管理データベース
５０３  プレゼンスサーバ装置の状態変化条件保持部
５０４  プレゼンスサーバ装置のメッセージ生成部
５０５  プレゼンスサーバ装置の通信部
【図１】
2006246065.tif 000003
【図２】
2006246065.tif 000004
【図３】
2006246065.tif 000005
【図４】
2006246065.tif 000006
【図５】
2006246065.tif 000007
【図６】
2006246065.tif 000008
【図７】
2006246065.tif 000009
【図８】
2006246065.tif 000010
【図９】
2006246065.tif 000011
【図１０】
2006246065.tif 000012
【図１１】
2006246065.tif 000013
【図１２】
2006246065.tif 000014
【図１３】
2006246065.tif 000015
【図１４】
2006246065.tif 000016
【図１５】
2006246065.tif 000017
【図１６】
2006246065.tif 000018
【図１７】
2006246065.tif 000019
【図１８】
2006246065.tif 000020
【図１９】
2006246065.tif 000021
【図２０】
2006246065.tif 000022
【図２１】
2006246065.tif 000023
【図２２】
2006246065.tif 000024
【図２３】
2006246065.tif 000025
【図２４】
2006246065.tif 000026
【図２５】
2006246065.tif 000027
【図２６】
2006246065.tif 000028
【図２７】
2006246065.tif 000029
【図２８】
2006246065.tif 000030
【図２９】
2006246065.tif 000031
【図３０】
2006246065.tif 000032
【図３１】
2006246065.tif 000033
【図３２】
2006246065.tif 000034
【図３３】
2006246065.tif 000035
【図３４】
2006246065.tif 000036
【図３５】
2006246065.tif 000037
【図３６】
2006246065.tif 000038