JP2006246065A - 通知装置、被通知装置および状態通知方法 - Google Patents

Abstract

【課題】 ネットワークに接続された機器またはユーザの状態通知を行う際に、不要な通知を減らし、サーバの処理負荷を軽減することを可能とする通知装置、被通知装置および状態通知方法を提供すること。
【解決手段】 管理者端末１０３がプレゼンスサーバ装置１００に通知要求をする際に、装置の状態の継続時間、または状態が変化した時刻、状態の変化履歴で示された状態変化条件を指定する。プレゼンスサーバ装置１００は状態変化条件を満たす場合にだけ通知を行う。
【選択図】 図１

Description

本発明は、装置またはユーザの状態を通知する装置および方法に関し、特に装置またはユーザの状態の状態継続時間、状態変化時刻、状態変化履歴が所定の条件を満たすときに限り状態の通知を行う通知装置、被通知装置および状態通知方法に関する。

近年、通信相手の接続状態(オンライン/オフライン)を知ることができるプレゼンスサービスがＩＭ(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メッセージを送信する際に実行する動作を示すフロー図 従来のＳＩＰイベント通知機能を使ったプレゼンスサービスにおけるネットワーク構成の一例を示す図 従来のＳＩＰプロトコルに準拠したプレゼンスサービスにおけるメッセージフローの一例を示す図 従来のイベントフィルタのメッセージフローの一例を示す図

符号の説明

１００、４００、７００ プレゼンスサーバ装置
１０１、６０２ 外勤者端末
１０２、６０１ 内勤者端末
１０３、１１３、６０３ 管理者端末
７０１、７０２、７０３、７０４ パーソナルコンピュータ
１１０、６１０、７１０ ネットワーク（ＬＡＮ）
１２１、１２２、１３０、６２１、６２２、６３０ ユーザ
２０１ プレゼンスサーバ装置の制御部
２０２ プレゼンスサーバ装置の状態管理データベース
２０３ プレゼンスサーバ装置の状態変化条件保持部
２０４ プレゼンスサーバ装置のメッセージ生成部
２０５ プレゼンスサーバ装置の通信部
２０６ プレゼンスサーバ装置の画面出力部
２０７ プレゼンスサーバ装置の入力受信部
３０１ 管理者端末の制御部
３０２ 管理者端末の画面出力部
３０３ 管理者端末の通信部
４０１ 管理者端末の制御部
４０２ 管理者端末の画面出力部
４０３ 管理者端末の入力受信部
４０４ 管理者端末のメッセージ生成部
４０５ 管理者端末の通信部
５０１ プレゼンスサーバ装置の制御部
５０２ プレゼンスサーバ装置の状態管理データベース
５０３ プレゼンスサーバ装置の状態変化条件保持部
５０４ プレゼンスサーバ装置のメッセージ生成部
５０５ プレゼンスサーバ装置の通信部

Claims (26)

1. 時間の経過に応じて様々な状態をとりうる状態発行体が同一の状態を継続している時間を表す状態継続時間情報、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻情報、および前記状態発行体の変化の履歴を表す変化履歴情報の少なくとも一つを含む状態変化情報を保存する状態変化情報保存手段と、
   状態変化条件を設定する状態変化条件設定手段と、
   前記状態変化情報保存手段に保存された前記状態変化情報と前記状態変化条件設定手段により設定された前記状態変化条件とに基づいて前記発行体の状態が変化したか否かを判定する状態変化判定手段と、
   前記状態変化判定手段によって前記発行体の状態が変化したと判定した場合に、状態変化を通知する状態変化通知パケットを送信する状態変化通知情報送信手段とを備えた通知装置。
2. 前記状態変化情報保存手段は、前記状態継続時間を保存し、
   前記状態変化条件設定手段は、前記状態継続時間を指定する状態継続時間条件を設定し、
   前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態継続時間情報と前記状態変化条件設定手段により設定された前記状態継続時間条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１に記載の通知装置。
3. 前記状態変化情報保存手段は、前記状態変化時刻を保存し、
   前記状態変化条件設定手段は、前記状態変化時刻の範囲を指定する状態変化時刻条件を設定し、
   前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態変化時刻情報と前記状態変化条件設定手段により設定された前記状態変化時刻条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１に記載の通知装置。
4. 前記状態変化情報保存手段はさらに、少なくとも１つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を保存し、
   前記状態変化条件設定手段はさらに、前記状態項目と前記状態項目の前記状態値を指定する前記状態項目の状態値条件を設定し、前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態項目と前記状態項目の前記状態値情報と前記状態変化条件設定手段により設定された前記状態項目と前記状態項目の前記状態値条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項２または請求項３に記載の通知装置。
5. 前記状態変化情報保存手段は、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化の履歴を表す変化履歴情報を保存し、
   前記状態変化条件設定手段は、前記状態項目と前記状態項目の前記状態値の変化を指定する履歴条件を設定し、
   前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記状態項目と前記状態項目の前記状態値の変化の履歴を表す前記変化履歴情報と前記状態変化条件設定手段により設定された前記状態項目と前記状態項目の前記状態値の前記変化履歴条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１に記載の通知装置。
6. 前記状態変化情報保存手段は、複数の状態発行体それぞれの複数の状態変化情報を保存し、
   前記状態変化条件設定手段は、前記複数の状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を設定し、
   前記状態変化判定手段は、前記状態変化情報保存手段に保存された前記複数の状態変化情報と、前記状態変化条件設定手段により設定された前記複数の状態変化条件間の論理条件とに基づいて前記複数の状態発行体の前記発行体の状態が変化したか否かを判定することを特徴とする請求項１から請求項５までの何れかに記載の通知装置。
7. さらに、前記状態変化条件を示す変化条件情報パケットを受信する変化条件情報受信手段を備え、前記状態変化条件設定手段は、前記変化条件情報受信手段により受信された前記変化条件情報パケットに基づいて前記状態変化条件を設定することを特徴とする請求項１から請求項６までの何れかに記載の通知装置。
8. 前記状態発行体は前記通知装置を含み、前記状態変化条件設定手段は、少なくとも前記通知装置自体の状態変化情報を設定することを特徴とする請求項１から請求項７までの何れかに記載の通知装置。
9. 前記状態変化通知情報送信手段は、前記状態変化通知パケットをＳＩＰ(Session Initiation Protocol)プロトコルに準拠して送信することを特徴とする請求項１から請求項８までの何れかに記載の通知装置。
10. 時間の経過に応じて様々な状態をとりうる状態発行体の前記状態を通知する通知装置とネットワークを介して接続され、前記通知装置から前記状態発行体の前記状態を示す状態通知パケットを受信する状態情報受信手段と、
    前記状態発行体が同一の状態を継続している時間を表す状態継続時間、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻、および前記状態発行体の変化の履歴を表す変化履歴の少なくとも一つを設定する状態変化条件を通知する変化条件情報パケットを送信する変化条件送信手段とを備えた被通知装置。
11. 前記変化条件送信手段は、前記状態継続時間を指定する変化条件情報パケットを送信することを特徴とする請求項１０に記載の被通知装置。
12. 前記変化条件送信手段は、前記状態変化時刻を指定する変化条件情報パケットを送信することを特徴とする請求項１０に記載の被通知装置。
13. 前記変化条件送信手段はさらに、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を指定する変化条件情報パケットを送信することを特徴とする請求項１１または請求項１２に記載の被通知装置。
14. 前記変化条件送信手段は、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化を指定する変化条件情報パケットを送信することを特徴とする請求項１０に記載の被通知装置。
15. 前記変化条件送信手段は、複数状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を指定する変化条件情報パケットを送信することを特徴とする請求項１０から請求項１４までの何れかに記載の被通知装置。
16. 前記変化条件送信手段は、少なくとも前記通知装置の状態変化条件を指定する変化条件情報パケットを送信することを特徴とする請求項１０から請求項１５までの何れかに記載の被通知装置。
17. 前記変化条件送信手段は、前記変化条件情報パケットをＳＩＰプロトコルに準拠して送信することを特徴とする請求項１０から請求項１６までの何れかに記載の被通知装置。
18. 時間の経過に応じて様々な状態をとりうる状態発行体が同一の状態を継続している時間を表す状態継続時間情報、前記状態発行体が前記状態を変化させた時刻を表す状態変化時刻情報、および前記状態発行体の変化の履歴を表す変化履歴情報の少なくとも一つを含む状態変化情報を保存する状態変化情報保存ステップと、
    状態変化条件を設定する状態変化条件設定ステップと、
    前記状態変化情報保存ステップで保存された前記状態変化情報と前記状態変化条件設定ステップにより設定された前記状態変化条件とに基づいて前記発行体の状態が変化したか否かを判定する状態変化判定ステップと、
    前記状態変化判定ステップが前記発行体の状態が変化したと判定した場合に、状態変化を通知する状態変化通知パケットを送信する状態変化通知パケット送信ステップとを備えた状態通知方法。
19. 前記状態変化情報保存ステップは、前記状態継続時間を保存し、
    前記状態変化条件設定ステップは、前記状態継続時間を指定する状態継続時間条件を設定し、
    前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態継続時間情報と前記状態変化条件設定ステップにより設定された前記状態継続時間条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８に記載の状態通知方法。
20. 前記状態変化情報保存ステップは、前記状態変化時刻を保存し、
    前記状態変化条件設定ステップは、前記状態変化時刻の範囲を指定する状態変化時刻条件を設定し、
    前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態変化時刻情報と前記状態変化条件設定ステップにより設定された前記状態変化時刻条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８に記載の状態通知方法。
21. 前記状態変化情報保存ステップは、少なくとも一つの前記状態発行体の状態を表す状態項目と前記状態項目の状態値を保存し、
    前記状態変化条件設定ステップは、前記状態項目と前記状態項目の前記状態値を指定する前記状態項目の状態値条件を設定し、前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態項目と前記状態項目の前記状態値情報と前記状態変化条件設定ステップにより設定された前記状態項目と前記状態項目の前記状態値条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項２０または請求項２１に記載の状態通知方法。
22. 前記状態変化情報保存ステップは、前記状態発行体の少なくとも一つの前記状態項目と前記状態項目の前記状態値の変化の履歴を表す変化履歴情報を保存し、
    前記状態変化条件設定ステップは、前記状態項目と前記状態項目の前記状態値の変化を指定する履歴条件を設定し、
    前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記状態項目と前記状態項目の前記状態値の変化の履歴を表す前記変化履歴情報と前記状態変化条件設定ステップにより設定された前記状態項目と前記状態項目の前記状態値の前記変化履歴条件とに基づいて前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８に記載の状態通知方法。
23. 前記状態変化情報保存ステップは、複数の状態発行体それぞれの複数の状態変化情報を保存し、
    前記状態変化条件設定ステップは、前記複数の状態発行体それぞれの複数の状態変化条件と、前記複数の状態変化条件間の論理条件を設定し、
    前記状態変化判定ステップは、前記状態変化情報保存ステップで保存された前記複数の状態変化情報と、前記状態変化条件設定ステップにより設定された前記複数の状態変化条件間の論理条件とに基づいて前記複数の状態発行体の前記発行体の状態が変化したか否かを判定することを特徴とする請求項１８から請求項２２までの何れかに記載の状態通知方法。
24. さらに、前記状態変化条件を示す変化条件情報パケットを受信する変化条件情報パケット受信ステップを備え、前記状態変化条件設定ステップは、前記変化条件情報パケット受信ステップにより受信された前記変化条件情報パケットに基づいて前記状態変化条件を設定することを特徴とする請求項１８から請求項２３までの何れかに記載の状態通知方法。
25. 前記状態発行体は状態を通知する通知装置前記状態通知方法をを含み、前記状態変化条件設定ステップは、少なくとも前記状態通知装置方法自体の状態変化情報を設定することを特徴とする請求項１８から請求項２４までの何れかに記載の状態通知方法。
26. 前記状態変化通知パケット送信ステップは、前記状態変化通知パケットをＳＩＰプロトコルに準拠して送信することを特徴とする請求項１８から請求項２５までの何れかに記載の状態通知方法。

Images