(57)【要約】【課題】複数の機器若しくは機器のユーザの状態により通知条件を指定でき、不要な通知情報を減らすことを可能とする通知装置、被通知装置および状態通知方法を提供する。【解決手段】ユーザ１３０はキー入力部より、通知条件に「携帯電話が通話可能、もしくはＰＣ１０２が現在ユーザに使用され固定電話が通話可能」と、通知先ＵＲＩにＰＣ１０４のＵＲＩとを設定する。携帯電話、ＰＣ１０２、固定電話は状態が変化するたびに通知装置にＰＵＢＬＩＳＨを送信する。通知装置はＰＵＢＬＩＳＨを受信すると、携帯電話、ＰＣ１０２、固定電話の状態が設定された通知条件を満たすか確認し、通知条件を満たさない場合は通知情報を送信せず、通知条件を満たすときのみ通知情報を送信する。被通知装置であるＰＣ１０４は、通知情報を受信するとその情報を画面に表示し、ユーザ１２０の状態をユーザ１３０に対して知らせる。【選択図】図２
2006238112.tif 000002
【特許請求の範囲】
【請求項１】
被通知装置に通知する条件である通知条件を記憶する通知条件記憶手段と、個々の機器あるいは前記機器のユーザである状態情報提供者が提供する状態情報を取得する状態情報取得手段と、前記状態情報取得手段で取得した複数の状態情報が前記通知条件を満たす場合に通知情報を前記被通知装置に送信する送信手段と、を含む通知装置であって、前記通知条件は、複数の状態条件からなる論理条件で示され、前記複数の状態条件を構成する個々の状態条件は、前記個々の状態条件に対応する状態情報発行者の状態項目と状態値との組を含むことを特徴とする通知装置。
【請求項２】
前記送信手段は、前記状態情報取得手段で取得した複数の状態情報からなる論理条件が前記通知条件を満たさない場合には前記通知情報を前記被通知装置に送信しない請求項１記載の通知装置。
【請求項３】
前記状態情報発行者の少なくとも１つが通知装置である請求項１または請求項２記載の通知装置。
【請求項４】
前記通知条件を受信する通知条件受信手段を更に含み、前記通知条件受信手段で受信した通知条件を前記通知条件記憶手段に記憶する請求項１乃至請求項３のいずれかに記載の通知装置。
【請求項５】
前記論理条件は、ＡＮＤ（かつ）と、ＯＲ（または）と、ＮＯＴ（否定）の少なくとも一つを含む請求項１乃至請求項４のいずれかに記載の通知装置。
【請求項６】
前記送信手段は、前記通知情報の送信にＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使用する請求項１乃至請求項５のいずれかに記載の通知装置。
【請求項７】
通知装置が通知情報を被通知装置に送信する条件である通知条件を取得する通知条件取得手段と、前記通知条件取得手段で取得した通知条件を前記通知装置に送信する通知条件送信手段と、を含む通知条件指定装置であって、前記通知条件は、複数の状態条件からなる論理条件で示され、前記複数の状態条件を構成する個々の状態条件は、前記個々の状態条件に対応する状態情報発行者の状態項目と状態値との組を含み、前記状態情報発行者は、個々の機器あるいは前記機器のユーザであることを特徴とする通知条件指定装置。
【請求項８】
前記論理条件は、ＡＮＤ（かつ）と、ＯＲ（または）と、ＮＯＴ（否定）の少なくとも一つを含む請求項７記載の通知条件指定装置。
【請求項９】
前記通知条件送信手段は、前記通知条件の送信にＳＩＰを使用する請求項７または請求項８記載の通知条件指定装置。
【請求項１０】
通知条件指定装置は、前記被通知装置である請求項７乃至請求項９のいずれかに記載の通知条件指定装置。
【請求項１１】
被通知装置に通知する条件である通知条件を記憶する通知条件記憶ステップと、個々の機器あるいは前記機器のユーザである状態情報提供者が提供する状態情報を取得する状態情報取得ステップと、前記状態情報取得ステップで取得した複数の状態情報が前記通知条件を満たす場合に通知情報を前記被通知装置に送信する送信ステップと、を含む状態通知方法であって、前記通知条件は、複数の状態条件からなる論理条件で示され、前記複数の状態条件を構成する個々の状態条件は、前記個々の状態条件に対応する状態情報発行者の状態項目と状態値との組を含むことを特徴とする状態通知方法。
【請求項１２】
前記通知条件を受信する通知条件受信ステップを更に含み、前記通知条件受信ステップで受信した通知条件を前記通知条件記憶ステップで記憶する請求項１１記載の状態通知方法。
【請求項１３】
前記論理条件は、ＡＮＤ（かつ）と、ＯＲ（または）と、ＮＯＴ（否定）の少なくとも一つを含む請求項１１または請求項１２に記載の状態通知方法。
【請求項１４】
前記送信ステップは、前記通知情報の送信にＳＩＰを使用することを特徴とする請求項１１乃至請求項１３のいずれかに記載の状態通知方法。
【請求項１５】
前記通知条件受信ステップは、前記通知条件の受信にＳＩＰを使用することを特徴とする請求項１２乃至請求項１４のいずれかに記載の状態通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器もしくは機器のユーザの状態を通知する通知装置、通知条件指定装置および状態通知方法に関する。
【背景技術】
【０００２】
近年、通信相手の接続状態（オンライン／オフライン）を知ることができるプレゼンスサービスが簡易テキストメール交換サービス（ＩＭ：Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｅ）などで使われてきている。また、企業におけるプレゼンスサービスとしては、通信相手の在席状態（在席／不在）をネットワーク経由で通知するサービスが普及しつつある。
【０００３】
このようなサービスを提供するための一つの方法として、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）のＲＦＣ３２６１（発行：２００２．６）及びＲＦＣ３２６５（発行：２００２．６）に示されるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）のイベント通知機能がある。ＳＩＰイベント通知機能を使って企業におけるプレゼンスサービスを実現する場合としては、例えば、社員の状態を管理するプレゼンスサーバを設置し、社員の状態が変化したら、状態通知要求をしている人に向けて状態変化通知を送信する。
【０００４】
図２２は、従来の通知装置と通知条件指定装置兼被通知装置の例であるＳＩＰイベント通知機能を使ったプレゼンスサービスにおけるネットワーク構成を示す図である。コンピュータ（ＰＣとも記す）７０１〜７０４は、社内ＬＡＮ７１０に接続されており、ＰＣを使用するユーザのプレゼンス状態（在席／不在）の状態を持つ。通知装置であるプレゼンスサーバ７００は、ＰＣ７０１〜７０４の状態を管理し、状態通知の要求があり、状態に変化があった場合は状態通知要求をしている機器、すなわち被通知装置に向けて状態変化を通知する。
【０００５】
例えば、ＰＣ７０１の状態が「在席」であり、通知条件指定装置でもあり、被通知装置であるＰＣ７０４が、ＰＣ７０１の状態通知をＰＣ７０４に行なうように要求したら、プレゼンスサーバ７００は、ＰＣ７０１が「在席」であることをＰＣ７０４に通知する。次に、ＰＣ７０１が「在席」から「不在」に変化した場合は、プレゼンスサーバ７００に「不在」という状態を登録する。プレゼンスサーバはＰＣ７０１の状態を「在席」から「不在」に更新し、ＰＣ７０１の状態通知要求をしているＰＣ７０４に対して状態変化を通知する。
【０００６】
このような状態通知に使われるＳＩＰのメッセージについて図２３を用いて説明する。図２３は、従来の通知装置及び被通知装置におけるＳＩＰを使ったプレゼンスサービスのメッセージフローを示す図である。ＰＣ７０１は自装置の状態を記述した発行メッセージ（以下、ＰＵＢＬＩＳＨとも記す）をプレゼンスサーバ７００に送信し、現在の状態をプレゼンスサーバ７００に登録する。プレゼンスサーバ７００はＰＵＢＬＩＳＨを受信してＰＣ７０１の状態を登録すると、ＳＩＰで規定された「２００  ＯＫ応答」を返す。
【０００７】
通知条件指定装置でもあり、被通知装置であるＰＣ７０４はＰＣ７０１の状態通知を要求するために、ＰＣ７０１のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）と通知を要求する状態の種類（ここではプレゼンス）を記述した状態講読メッセージ（以下、ＳＵＢＳＣＲＩＢＥとも記す）をプレゼンスサーバ７００に送信する。プレゼンスサーバ７００はＳＵＢＳＣＲＩＢＥを受信し通知要求を受け入れると、「２００  ＯＫ応答」を返す。その後、プレゼンスサーバ７００はＰＣ７０１の状態を記述した通知メッセージ（以下、ＮＯＴＩＦＹとも記す）をＰＣ７０４に送信する。
【０００８】
ＰＣ７０４はＮＯＴＩＦＹを受信し、ＰＣ７０１の状態を取得するとプレゼンスサーバ７００に対して「２００  ＯＫ応答」を返す。その後、ＰＣ７０１は自装置の状態が変化するたびにプレゼンスサーバ７００にＰＵＢＬＩＳＨを送信する。プレゼンスサーバ７００はＰＣ７０１からのＰＵＢＬＩＳＨを受信すると、ＰＣ７０１の状態を記述したＮＯＴＩＦＹをＰＣ７０４に送信する。
【０００９】
以上のようにＳＩＰイベント通知機能を使うことによって、プレゼンスサービスを代表とする状態通知サービスを実現できる。現在、通知できる状態は社員の居場所や行動状態などに限られているが、今後はそれだけに限らずネットワークに接続された全ての機器の状態を通知するサービスの出現が予想される。ところが通知する状態や機器が増えることで状態を管理するサーバでの処理負荷増大が問題となり、負荷軽減を図る必要がでてくる。
【００１０】
この負荷軽減方法としては、例えばＩＥＴＦのＳＩＭＰＬＥ（ＳＩＰ  ｆｏｒ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｌｅｖｅｒａｇｉｎｇ  Ｅｘｔｅｎｓｉｏｎｓ）ワーキンググループで提案されているイベントフィルタがある。イベントフィルタについて図２４を用いて説明する。図２４は、従来の通知装置及び通知条件指定装置におけるイベントフィルタのメッセージフローを示す図である。
【００１１】
イベントフィルタによれば、通知装置において、ある機器が指定された状態になったときだけＮＯＴＩＦＹを送信することが可能となる。ＰＣ７０４はＳＵＢＳＣＲＩＢＥを送信する際に、ＮＯＴＩＦＹを生成する条件をＳＵＢＳＣＲＩＢＥのボディ部に記述する。この例では「ＰＣ７０１が不在になったときだけ通知」という条件を記述しておく。なお、実際の条件の記述はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）が使われるが、ここでは詳細な説明を省略する。プレゼンスサーバ７００はＳＵＢＳＣＲＩＢＥを受信すると、ＰＣ７０１の状態を記述したＮＯＴＩＦＹをＰＣ７０４に送信する。ＳＵＢＳＣＲＩＢＥ受信後、最初に送信されるＮＯＴＩＦＹについては、ＳＵＢＳＣＲＩＢＥに記述された条件を満たさない場合でも送信される。
【００１２】
その後、従来の通知装置であるプレゼンスサーバ７００は、「在席」という状態を登録するＰＵＢＬＩＳＨを受信した場合はＮＯＴＩＦＹを送信せず、「不在」という状態を登録するＰＵＢＬＩＳＨを受信した場合にのみ、従来の被通知装置であるＰＣ７０４にＮＯＴＩＦＹを送信する。
【００１３】
このようにイベントフィルタはＰＣ７０４が指定した条件を満たすときだけＮＯＴＩＦＹを送信するので不要なＮＯＴＩＦＹトラヒックが減り、ネットワークリソースを有効に利用できるとともにプレゼンスサーバ７００のＮＯＴＩＦＹ送信処理負荷を軽減することができる（例えば、非特許文献１参照）。
【非特許文献１】「Functional Description of Event Notification Filtering」、IETF draft-ietf-simple-event-filter-funct-04、発行者: H.Khartabil, E.Leppanen, M.Lonnfors, J.Costa-Requena、2005/1/14発効、３〜５章(5-14ページ)
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、前記従来の通知装置及び通知条件指定装置では、指定可能な条件が単一の機器の状態のみであり、複数の機器の状態を指定することについては開示されていなかった。このため、例えば「ユーザＡもしくはユーザＢが在席であり、ユーザＣが在席でない」状態となった場合にだけ通知、というような指定ができず、不要なＮＯＴＩＦＹが送信されるという問題があった。
【００１５】
本発明は、従来の問題を解決するためになされたもので、複数の機器若しくは機器のユーザの状態により通知条件を指定でき、不要な通知情報を減らすことを可能とする通知装置、被通知装置および状態通知方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明の通知装置は、被通知装置に通知する条件である通知条件を記憶する通知条件記憶手段と、個々の機器あるいは機器のユーザである状態情報提供者が提供する状態情報を取得する状態情報取得手段と、状態情報取得手段で取得した複数の状態情報が通知条件を満たす場合に通知情報を被通知装置に送信する送信手段と、を含む通知装置であって、通知条件が、複数の状態条件からなる論理条件で示され、複数の状態条件を構成する個々の状態条件が、個々の状態条件に対応する状態情報発行者の状態項目と状態値との組を含む構成を有している。
【００１７】
この構成により、複数の機器若しくは機器のユーザの状態による論理条件により通知条件を指定でき、不要な通知情報を減らすことが可能となる。
【００１８】
また本発明の通知装置は、送信手段が、状態情報取得手段で取得した複数の状態情報からなる論理条件が通知条件を満たさない場合には通知情報を被通知装置に送信しない構成を有している。この構成により、これによって不要な通知情報の送信が抑えられ、通信リソースを有効に使えるとともに、送信手段の送信処理負荷を軽減できる。
【００１９】
また、本発明の通知装置は、状態情報発行者の少なくとも１つが通知装置である構成を有している。この構成により、通知装置自身の状態を通知条件として指定することが可能となり、より複雑な通知条件の指定が可能となる。
【００２０】
また、本発明の通知装置は、通知条件を受信する通知条件受信手段を更に含み、通知条件受信手段で受信した通知条件を通知条件記憶手段に記憶する構成を有している。この構成により、他の装置が通知条件を指定することが可能となる。例えば通知情報を受信する被通知装置が通知条件を指定することにより、被通知装置が所望のタイミングで通知を受けることができる。さらに被通知装置が必要としないタイミングでの通知が無くなるため、ネットワークリソースを有効に使えるとともに、通知パケットの送受信処理負荷が軽減される。
【００２１】
また、本発明の通知装置は、論理条件が、ＡＮＤ（かつ）と、ＯＲ（または）と、ＮＯＴ（否定）の少なくとも一つを含む構成を有している。複数の状態条件を簡単なＡＮＤ／ＯＲ／ＮＯＴで結ぶような条件指定が可能となる。例えば「（ユーザＡが会議室に居る ＯＲ ユーザＢが会議室にいる） ＡＮＤ ユーザＣは会議室に居ない」といった通知条件の指定が可能となり、より適切なタイミングで通知することが可能となる。
【００２２】
また、本発明の通知装置は、送信手段が、通知情報の送信にＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使用する構成を有している。ＳＩＰのイベント通知機能を使用した場合でも通知条件の指定が可能となり、通信リソースを有効に使えるとともに、通知情報の送信処理負荷が軽減される。
【００２３】
さらに、本発明の通知条件指定装置は、通知装置が通知情報を被通知装置に送信する条件である通知条件を取得する通知条件取得手段と、通知条件取得手段で取得した通知条件を通知装置に送信する通知条件送信手段と、を含む通知条件指定装置であって、通知条件は、複数の状態条件からなる論理条件で示され、複数の状態条件を構成する個々の状態条件は、個々の状態条件に対応する状態情報発行者の状態項目と状態値との組を含み、状態情報発行者は、個々の機器あるいは機器のユーザである構成を有している。
【００２４】
この構成により、通知装置に対し、任意に通知条件を指定することができる。
【発明の効果】
【００２５】
本発明は、被通知装置に通知する条件である通知条件を記憶する通知条件記憶手段と、個々の機器あるいは機器のユーザである状態情報提供者が提供する状態情報を取得する状態情報取得手段と、状態情報取得手段で取得した複数の状態情報が通知条件を満たす場合に通知情報を被通知装置に送信する送信手段とを含み、通知条件が、複数の状態条件からなる論理条件で示され、複数の状態条件を構成する個々の状態条件が、個々の状態条件に対応する状態情報発行者の状態項目と状態値との組を含むことにより、複数の機器若しくは機器のユーザの状態により通知条件を指定でき、不要な通知情報を減らすことが可能となるという効果を有する通知装置を提供することができる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態の通知装置および通知条件指定装置について、図面を参照しながら説明する。
【００２７】
（実施の形態１）
図１は、本発明の実施の形態１における通知装置を含むネットワーク構成図である。
【００２８】
図１において、通知装置（以下、プレゼンスサーバとも記す）１００は、携帯電話１０１、ＰＣ１０２、固定電話１０３、ＰＣ１０４とネットワーク１１０によって接続されている。携帯電話１０１、ＰＣ１０２、固定電話１０３はユーザ１２０が所有する機器であり、それぞれが持つ状態が変化するたびにプレゼンスサーバ１００に状態登録を行う。ＰＣ１０４はユーザ１３０が所有する機器であり、プレゼンスサーバ１００からの状態通知を受ける被通知装置である。
【００２９】
プレゼンスサーバ１００は各機器の状態を保持・管理し、ＰＣ１０４に対して状態通知を行う。実施の形態１では、プレゼンスサーバ１００のキー入力部からのキー入力により、「携帯電話１０１が通話可能、もしくはＰＣ１０２が現在ユーザに使用されており固定電話が通話可能」という通知条件を設定し、プレゼンスサーバ１００は通知条件を満たすときのみ、被通知装置であるＰＣ１０４に状態通知を行う例を示す。なお、本実施の形態で、通知条件の設定はキー入力部からのキー入力により行なう場合で説明するが、本発明はこれに限定することなく、タッチパネルやマウスといったポインティングデバイスや音声認識入力手段他でも実施可能である。
【００３０】
まず、図２を用いて、本発明の実施の形態１における通知装置の動作を示すメッセージフローを説明する。なお、実施の形態１ではＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いた通信の例を示すが、通信プロトコルとしてはＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やその他のプロトコルでもよい。ＳＩＰは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）のＲＦＣ３２６１（発行：２００２．６）及びＲＦＣ３２６５（発行：２００２．６）に示される。
【００３１】
また、図２では簡単化のためＰＵＢＬＩＳＨメッセージやＳＵＢＳＣＲＩＢＥメッセージ、ＮＯＴＩＦＹメッセージに対する「２００  ＯＫ」応答の記述を省略しているが、実際は各メッセージに対して「２００  ＯＫ」応答が返る。
【００３２】
携帯電話１０１、ＰＣ１０２、固定電話１０３はプレゼンスサーバ１００に対してＰＵＢＬＩＳＨを送信し、それぞれが持つ状態を予め登録しておく。ユーザ１３０は後述するキー入力部３０７により、プレゼンスサーバ１００に対して、通知条件として「携帯電話１０１が通話可能、もしくはＰＣ１０２が現在ユーザに使用されており固定電話が通話可能」を設定し、通知先ＵＲＩとしてＰＣ１０４のＵＲＩである「ｓｉｐ：１０４＠ｅｘａｍｐｌｅ．ｃｏｍ」を設定しておく。
【００３３】
携帯電話１０１、ＰＣ１０２、固定電話１０３はそれぞれが持つ状態が変化するたびにプレゼンスサーバ１００に対してＰＵＢＬＩＳＨを送信する。プレゼンスサーバ１００はＰＵＢＬＩＳＨを受信すると、携帯電話１０１、ＰＣ１０２、固定電話１０３の状態が設定された通知条件を満たしているか確認し、通知条件を満たさない場合はＮＯＴＩＦＹを送信せず、通知条件を満たすときのみＰＣ１０４に対してＮＯＴＩＦＹを送信する。
【００３４】
ここで図１に戻り実施の形態１の詳細な説明をする。
【００３５】
携帯電話１０１は、基本的な状態を表す”ｓｔａｔｅ”という状態項目を持ち、ｓｔａｔｅは「スタンバイ／電源オフ／通話中」を表す”ｓｔａｎｄｂｙ／ｏｆｆ／ｂｕｓｙ”という３つの状態値を持つ。
【００３６】
ＰＣ１０２は、ユーザ１２０の居室に設置されたＰＣで、ユーザ１２０が現在ＰＣ１０２を使用しているかを表す”ｐｒｅｓｅｎｃｅ”という状態項目を持ち、ｐｒｅｓｅｎｃｅは「在席／不在」を表す”ｏｐｅｎ／ｃｌｏｓｅｄ”という２つの状態値を持つ。プレゼンス状態の検出には、ＰＣ１０２のスクリーンセーバが起動したら「不在」、それ以外は「在席」とするなど、様々な方法が判断できる。
【００３７】
固定電話１０３も居室に設置されており、携帯電話１０１と同様に”ｓｔａｔｅ”という状態項目を持ち、”ｓｔａｎｄｂｙ／ｏｆｆ／ｂｕｓｙ”という状態値を持つ。
【００３８】
なお、状態項目と状態値については、上記以外にも電波強度状態やネットワーク接続状態など、その他の状態項目や状態値を持っていてもよい。
【００３９】
携帯電話１０１、ＰＣ１０２、固定電話１０３はそれぞれが持つ状態が変化すると、プレゼンスサーバにＰＵＢＬＩＳＨを送信して状態を登録する。なお、プレゼンスサーバのアドレスは各機器に予め設定されていてもよいし、その他の方法を使って取得してもよい。状態の登録方法としては、例えばＰＣ１０２のプレゼンスが在席という状態を登録する場合は「ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝ｏｐｅｎ”」というテキストをＰＵＢＬＩＳＨのボディ部に記述することが考えられる。なお、状態を表すテキストはＸＭＬやその他のフォーマットでもよく、ボディ部ではなくヘッダ部に記述してもよい。また、状態の登録についてはＰＵＢＬＩＳＨを使わずに他のメッセージやＳＩＰ以外のプロトコルを使ってもよい。
【００４０】
被通知装置であるＰＣ１０４は、プレゼンスサーバ１００からのＮＯＴＩＦＹを受信するとその情報を画面に表示し、ユーザ１２０の状態をユーザ１３０に対して知らせる。プレゼンスサーバ１００はユーザ１３０から入力された通知条件を保持し、携帯電話１０１、ＰＣ１０２、固定電話１０３の状態が通知条件を満たした場合にだけＰＣ１０４に対してＮＯＴＩＦＹを送信する。プレゼンスサーバ１００の装置構成と動作の詳細については後述する。
【００４１】
なお、ネットワーク１１０が想定するものは社内ＬＡＮが考えられるが、社内ＬＡＮ以外にも宅内ネットワークやインターネットなど、その他のネットワークであってもよい。さらに、個々の機器間が何らかの通信媒体を介して通信できれば、ネットワークに限定されることはない。
【００４２】
次にプレゼンスサーバ１００の装置構成と動作について詳細を説明する。なお、簡単化のため各メッセージに対する「２００  ＯＫ」応答の動作については説明を省略するが、全てのメッセージに対して「２００  ＯＫ」応答の送受信動作があるものとする。
【００４３】
本実施の形態における通知装置であるプレゼンスサーバ１００の通知条件設定動作について図３と図４を用いて説明する。図３は、本実施の形態における通知装置（プレゼンスサーバ１００）の装置構成図であり、図４は、本実施の形態におけるプレゼンスサーバ１００の通知条件設定フローチャートである。
【００４４】
まず、制御部３０１は通知条件と通知先ＵＲＩを入力する画面を表示する命令を画面出力部３０６に送り（Ｓ１０１）、ユーザ１３０からの入力を待つ（Ｓ１０２）。ユーザ１３０から通知条件と通知先ＵＲＩがキー入力部３０７に入力されるとその情報が制御部３０１へ送られる（Ｓ１０３）。ここでは通知条件として「携帯電話１０１が通話可能、もしくはＰＣ１０２が現在ユーザに使用されており固定電話１０３が通話可能」という条件が入力され、通知先ＵＲＩとしてＰＣ１０４のＵＲＩが入力されたとする。通知条件と通知先ＵＲＩの入力方法としては、予め設定された複数の通知条件や通知先ＵＲＩの中から適当な条件やＵＲＩを選択するなど、様々な方法で実現可能である。
【００４５】
制御部３０１は入力された条件を通知条件のフォーマットに変換する（Ｓ１０４）。ここでは「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」という通知条件に変換する。なお、通知条件のフォーマットについてはＸＭＬなど、その他のフォーマットでもよい。
【００４６】
制御部３０１は通知条件と通知先ＵＲＩを通知条件保持部３０３に保存する（Ｓ１０５）。ここでは通知条件として「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」を保存し、通知先ＵＲＩとしてはＰＣ１０４のＵＲＩである「ｓｉｐ：１０４＠ｅｘａｍｐｌｅ．ｃｏｍ」を保存する。なお、通知条件保持部３０３は複数の通知条件と通知先ＵＲＩを保持可能である。通知条件保持部３０３のデータ構造の詳細については後述の図１０で説明する。
【００４７】
次にプレゼンスサーバ１００のＰＵＢＬＩＳＨ受信動作について図３と図５を用いて説明する。図５は、本発明の実施の形態１における通知装置（プレゼンスサーバ１００）のＰＵＢＬＩＳＨ受信フローチャートである。
【００４８】
まず、通信部３０５がＰＵＢＬＩＳＨを受信し（Ｓ２０１）、受信したＰＵＢＬＩＳＨを制御部３０１に送る（Ｓ２０２）。制御部３０１はＰＵＢＬＩＳＨに記述された状態を状態管理データベース３０２に保存する（Ｓ２０３）。例えばＰＵＢＬＩＳＨに「ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝ｂｕｓｙ」という状態が記述されていた場合は、ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍというＵＲＩが持つ状態項目”ｓｔａｔｅ”の状態値を”ｂｕｓｙ”に変更する。なお、状態管理データベースのデータ構造の詳細については、後述の図９で説明する。
【００４９】
制御部３０１は通知条件保持部３０３に保存されている最初の通知条件と通知先ＵＲＩを取得する（Ｓ２０４）。ここで、ＰＵＢＬＩＳＨによって更新された状態項目が通知条件に含まれていない場合は後述のＳ２１２ステップに進む（Ｓ２０５）。これは更新された状態項目が通知条件と関連が無い場合、ＮＯＴＩＦＹを生成しないことを意味する。例えば取得した通知条件が「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」であり、ＰＵＢＬＩＳＨに記述された状態が「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｂｕｓｙ”」である場合は、更新された状態項目が通知条件に含まれるので、Ｓ２１２ステップには進まない。
【００５０】
更新された状態項目が通知条件に含まれる場合、通知条件に記述された状態を状態管理データベース３０２から取得する（Ｓ２０６）。取得した状態が通知条件を満たさない場合は後述のＳ２１２ステップに進む（Ｓ２０７）。これは現在の状態が通知条件を満たさない場合はＮＯＴＩＦＹを生成しないことを意味する。
【００５１】
例えば取得した状態が「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｏｆｆ”  ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｃｌｏｓｅｄ”  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｂｕｓｙ”」であり、通知条件が「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」である場合は通知条件を満たさないのでＳ２１２ステップに進む。
【００５２】
一方、取得した状態が通知条件を満たす場合は、取得した状態と通知先ＵＲＩをメッセージ生成部３０４に送り（Ｓ２０８）、メッセージ生成部３０４は通知先ＵＲＩをＲｅｑｕｅｓｔ−ＵＲＩに記述し、状態をボディ部に記述したＮＯＴＩＦＹを生成する（Ｓ２０９）。メッセージ生成部３０４は生成したＮＯＴＩＦＹを通信部３０５に送り（Ｓ２１０）、通信部３０５はＮＯＴＩＦＹを送信する（Ｓ２１１）。
【００５３】
その後、制御部３０１は通知条件保持部３０３に保存されている通知条件をすべて処理したかを確認し、保持してある全ての通知条件について処理を行った場合は終了となる（Ｓ２１２）。まだ処理していない通知条件がある場合は、制御部３０１は通知条件保持部３０３から次の通知条件と通知先ＵＲＩを取得し（Ｓ２１３）、Ｓ２０５ステップに戻って処理を継続する。
【００５４】
次に、ＰＣ１０４のＮＯＴＩＦＹ受信動作について図６と図７を用いて説明する。図６は、本発明の実施の形態１における通知装置から通知を受ける被通知装置であるＰＣ１０４の装置構成図であり、図７は同ＰＣ１０４のＮＯＴＩＦＹ受信フローチャートである。
【００５５】
通信部２０３がＮＯＴＩＦＹを受信し（Ｓ３０１）、受信したＮＯＴＩＦＹを制御部２０１に送る（Ｓ３０２）。制御部２０１はＮＯＴＩＦＹに記述された状態を画面出力部２０２に表示する命令を送り、画面に状態を表示する（Ｓ３０３）。例えばＮＯＴＩＦＹに記述された状態が「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｏｆｆ”  ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｃｌｏｓｅｄ”  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”」である場合は、画面に「携帯電話：電源OFF、ユーザ：不在、居室電話：通話可能」というテキストメッセージを画面に表示させる。なお、画面表示形態はアイコン表示やその他の形態であってもよいし、画面に表示せずに音やその他の方法を使った通知方法であってもよい。
【００５６】
次に実施の形態１におけるＮＯＴＩＦＹメッセージの中身の詳細について説明する。なお、ＰＵＢＬＩＳＨについては通常のＳＩＰにおいて使用されるメッセージと同様なので説明を省略する。なお、図に記述したメッセージは説明に必要な部分以外については省略しているが、実際のメッセージには他のヘッダが存在する。
【００５７】
図８は、本発明の実施の形態１における通知装置（プレゼンスサーバ１００）から被通知装置（ＰＣ１０４）に送信されるＮＯＴＩＦＹのデータ構造図である。
【００５８】
ＮＯＴＩＦＹのＲｅｑｕｅｓｔ−ＵＲＩには、通知条件保持部の通知先ＵＲＩに保持されたＰＣ１０４のＵＲＩが記述される。Ｅｖｅｎｔヘッダには、複数の状態の通知条件に関するイベントを表す”Ｍｕｌｔｉ−Ｆｉｌｔｅｒ”と記述する。ボディ部には状態管理データベース３０２から取得した状態が記述される。なお、状態は拡張ヘッダを使ってヘッダ部に記述してもよい。
【００５９】
次に、状態管理データベース３０２および通知条件保持部３０３のデータ構造について説明する。
【００６０】
最初に、状態管理データベース３０２の詳細について図９を用いて説明する。図９は、本発明の実施の形態１における通知装置の状態管理データベース３０２のデータ構造図である。状態管理データベース３０２は配下の機器のＵＲＩと状態を保持するデータベースであり、機器のＵＲＩと、それぞれの機器について１つ以上の状態項目、状態値の組を保持する。
【００６１】
図９に記述された例では、”ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ”というＵＲＩを持つ機器は、状態項目”ｓｔａｔｅ”に対して、電源ＯＦＦ状態を示す”ｏｆｆ”という状態値を持ち、電波強度を表す”ｒａｄｉｏ＿ｉｎｔｅｎｓｉｔｙ”という状態項目に対して、電波強度レベル３を示す”３”という状態値を持つということを示す。なお、保持する状態項目と状態値の組としてはネットワークへの接続状態を示す”ｎｅｔｗｏｒｋ”など様々なものが考えられる。
【００６２】
次に、通知条件保持部３０３の詳細について図１０を用いて説明する。図１０は、本発明の実施の形態１における通知装置の通知条件保持部３０３のデータ構造図である。通知条件保持部３０３はユーザによって設定された通知条件と、通知先ＵＲＩを保持する。通知条件と通知先ＵＲＩについては複数保持することが可能である。
【００６３】
図１０に記述された例では、「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」という通知条件を満たした場合は「ｓｉｐ：１０４＠ｅｘａｍｐｌｅ．ｃｏｍ」に対して通知するということを示す。
【００６４】
以上のように、実施の形態１では、ユーザ１３０がプレゼンスサーバ１００に対して複数の機器の状態を論理条件で結んだ条件を通知条件として設定し、プレゼンスサーバ１００は通知条件を満たすときだけＰＣ１０４に対してＮＯＴＩＦＹを送信する例を示した。これによって、不要なＮＯＴＩＦＹが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ１００とＰＣ１０４のＮＯＴＩＦＹ送受信負荷が軽減される。
【００６５】
（実施の形態２）
本発明の実施の形態２における通知装置および通知条件指定装置を含むネットワーク構成は、実施の形態１と、被通知装置であるＰＣ１０４が本実施の形態の通知条件指定装置を兼ね、通知装置であるプレゼンスサーバ１００に対し通知要求を出す点が異なる。本発明の実施の形態２では、ＰＣ１０４がプレゼンスサーバ１００に対して「携帯電話１０１が通話可能、もしくはＰＣ１０２が現在ユーザに使用されており固定電話が通話可能」という通知条件を指定した状態通知要求としてＳＵＢＳＣＲＩＢＥを送り、プレゼンスサーバ１００はＳＵＢＳＣＲＩＢＥに記述された通知条件を満たすときのみ状態通知を行う例を示す。
【００６６】
まず、図１１を用いて、本発明の実施の形態２の通知装置と通知条件指定装置におけるメッセージフローを説明する。なお、図１１では図２と同様に「２００  ＯＫ」応答の記述を省略している。
【００６７】
携帯電話１０１、ＰＣ１０２、固定電話１０３はプレゼンスサーバ１００に対してＰＵＢＬＩＳＨを送信し、それぞれが持つ状態を予め登録しておく。ＰＣ１０４はプレゼンスサーバ１００に対して通知条件を記述したＳＵＢＳＣＲＩＢＥを送信する。このとき通知条件としては「携帯電話１０１が通話可能、もしくはＰＣ１０２が現在ユーザに使用されており固定電話が通話可能」という条件を表す「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」をＳＵＢＳＣＲＩＢＥのＳＩＰボディ部に記述しておく。プレゼンスサーバ１００はＳＵＢＳＣＲＩＢＥを受信すると、携帯電話１０１、ＰＣ１０２、固定電話１０３の現在の状態を記述したＮＯＴＩＦＹをＰＣ１０４に対して送信する。
【００６８】
その後、携帯電話１０１、ＰＣ１０２、固定電話１０３はそれぞれが持つ状態が変化するたびにプレゼンスサーバ１００に対してＰＵＢＬＩＳＨを送信する。プレゼンスサーバ１００はＰＵＢＬＩＳＨを受信すると、携帯電話１０１、ＰＣ１０２、固定電話１０３の状態がＳＵＢＳＣＲＩＢＥで指定された通知条件を満たしているか確認し、通知条件を満たさない場合はＮＯＴＩＦＹを送信せず、通知条件を満たすときのみＰＣ１０４に対してＮＯＴＩＦＹを送信する。
【００６９】
次にＰＣ１０４およびプレゼンスサーバ１００の装置構成と動作について詳細を説明する。なお、実施の形態１と同様に簡単化のため各メッセージに対する「２００  ＯＫ」応答の動作については説明を省略する。また、ＰＣ１０４のＮＯＴＩＦＹ受信動作およびプレゼンスサーバ１００のＰＵＢＬＩＳＨ受信動作については実施の形態１と同様であるため、省略する。ＰＣ１０４のＳＵＢＳＣＲＩＢＥの送信動作について、図１２と図１３を用いて説明する。図１２は、本発明の実施の形態２における通知条件指定装置であり被通知装置でもあるＰＣ１０４の装置構成図であり、図１３は、同ＰＣ１０４のＳＵＢＳＣＲＩＢＥ送信フローチャートである。
【００７０】
図１３において、制御部４０１は通知条件を入力する画面を表示する命令を画面出力部４０２に送り（Ｓ４０１）、ユーザ１３０からの入力を待つ（Ｓ４０２）。ユーザ１３０から通知条件が入力されるとその情報がキー入力部４０３から制御部４０１へ送られる（Ｓ４０３）。ここでは通知条件として「携帯電話１０１が通話可能、もしくはＰＣ１０２が現在ユーザに使用されており固定電話１０３が通話可能」という条件が入力されたものとする。
【００７１】
制御部４０１は入力された条件を通知条件のフォーマットに変換する（Ｓ４０４）。ここでは「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」という通知条件に変換する。
【００７２】
制御部４０１は、変換した通知条件をメッセージ生成部４０４に送り（Ｓ４０５）、メッセージ生成部４０４は通知条件を記述したＳＵＢＳＣＲＩＢＥを生成する（Ｓ４０６）。メッセージ生成部４０４は生成したＳＵＢＳＣＲＩＢＥを通信部４０５に送り（Ｓ４０７）、通信部４０５は受け取ったＳＵＢＳＣＲＩＢＥをプレゼンスサーバ１００に向けて送信する（Ｓ４０８）。ここでプレゼンスサーバのアドレスはＰＣ１０４に予め設定されていてもよいし、ユーザが入力画面から入力してもよい。ＳＵＢＳＣＲＩＢＥメッセージの中身に関する詳細は後述の図１６で説明する。
【００７３】
次に、本実施の形態の通知装置であるプレゼンスサーバ１００のＳＵＢＳＣＲＩＢＥ受信動作について図１４と図１５を用いて説明する。図１４は、本発明の実施の形態２における通知装置（プレゼンスサーバ１００）の装置構成図であり、図１５は、同プレゼンスサーバ１００のＳＵＢＳＣＲＩＢＥ受信フローチャートである。
【００７４】
図１５において、通信部５０５が通知条件指定装置から送信されたＳＵＢＳＣＲＩＢＥを受信し（Ｓ５０１）、受信したＳＵＢＳＣＲＩＢＥを制御部５０１に送る（Ｓ５０２）。制御部５０１はＳＵＢＳＣＲＩＢＥに記述された通知条件と通知先ＵＲＩを通知条件保持部５０３に保存する（Ｓ５０３）。ここでは通知条件として「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”  ＯＲ  （ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”  ＡＮＤ  ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”）」が記述されているのでこれを保存する。通知先ＵＲＩとしてはＳＵＢＳＣＲＩＢＥのＣｏｎｔａｃｔヘッダに記述されたＵＲＩを保存する。通知条件保持部５０３のデータ構造の詳細については実施の形態１の通知条件保持部３０３と同様のため省略する。
【００７５】
その後、制御部５０１は状態管理データベース５０２から、通知条件に記述された機器の状態を取得する（Ｓ５０４）。ここではｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍのｓｔａｔｅと、ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍのｐｒｅｓｅｎｃｅと、ｓｉｐ：１０３＠ｅｘａｍｐｌｅ．ｃｏｍのｓｔａｔｅの各状態を取得する。制御部５０１は取得した状態をメッセージ生成部５０４に送り（Ｓ５０５）、メッセージ生成部５０４は受け取った状態を記述したＮＯＴＩＦＹを生成する（Ｓ５０６）。メッセージ生成部５０４は生成したＮＯＴＩＦＹを通信部５０５に送り（Ｓ５０７）、通信部５０５はＮＯＴＩＦＹをＰＣ１０４に送信する（Ｓ５０８）。
【００７６】
次に本発明の実施の形態２におけるＳＵＢＳＣＲＩＢＥメッセージの中身の詳細について説明する。なお、ＰＵＢＬＩＳＨについては実施の形態１と同様に通常のＳＩＰにおいて使用されるメッセージと同様なので説明を省略する。また、ＮＯＴＩＦＹメッセージの中身に関する詳細は実施の形態１と同様のため省略する。
【００７７】
ＳＵＢＳＣＲＩＢＥの中身の詳細について図１６を用いて説明する。図１６は、本発明の実施の形態２における通知条件指定装置（ＰＣ１０４）から通知装置（プレゼンスサーバ１００）に送信される通知条件を示すＳＵＢＳＣＲＩＢＥのデータフォーマット図である。なお、図８と同様に図に記述したメッセージは説明に必要な部分以外については省略している。
【００７８】
ＳＵＢＳＣＲＩＢＥのＲｅｑｕｅｓｔ−ＵＲＩには、携帯電話１０１、ＰＣ１０２、固定電話１０３のいずれかのＵＲＩが記述されてもよいし、ＰＣ１０４に予め設定された任意のアドレス（ａｎｏｎｙｍｏｕｓ＠ａｎｙｗｈｅｒｅなど）が記述されてもよい。Ｅｖｅｎｔヘッダには、複数の機器の状態を指定したフィルタを示す”Ｍｕｌｔｙ−Ｆｉｌｔｅｒ”と記述する。ボディ部には通知条件を記述する。なお、通知条件は拡張ヘッダを使ってヘッダ部に記述してもよい。
【００７９】
以上のように、実施の形態２では、通知条件指定装置として動作するＰＣ１０４が通知装置であるプレゼンスサーバ１００に対して複数の機器の状態を論理条件で結んだ条件を通知条件として記述したＳＵＢＳＣＲＩＢＥを送信し、プレゼンスサーバ１００は通知条件を満たすときだけＮＯＴＩＦＹを送信する例を示した。これによって、通知条件を通知条件指定装置であるＰＣ１０４が指定することが可能となり、より適切なタイミングでＮＯＴＩＦＹが送信され、不要なＮＯＴＩＦＹが送信されることがなくなり、ネットワークリソースを有効に使用できるとともに、プレゼンスサーバ１００とＰＣ１０４のＮＯＴＩＦＹ送受信負荷が軽減される。
【００８０】
なお、本実施の形態では、被通知装置が本発明の通知条件指定装置の機能を有する場合で説明したが、本発明はこれに限定されることはなく、個別に設置可能であることは言うまでもない。さらに、本発明は、例えば、図１７に示すように、通知条件が「携帯電話１０１の電波強度が１以上で、ＰＣ１０２が現在ユーザに使用されている」というように、「以上」や「以下」といった不等号であっても実施可能である。
【００８１】
図１７は、本発明の実施の形態２における通知条件指定装置から通知装置に送信される通知条件のデータフォーマット図である。ＳＵＢＳＣＲＩＢＥのヘッダ部については本実施の形態の先の場合と同様であるため説明を省略する。ＳＵＢＳＣＲＩＢＥのボディ部には通知条件が指定される。ここでは「携帯電話１０１の電波強度が1以上で、ＰＣ１０２が現在ユーザに使用されている」という通知条件を示す「ｓｉｐ：１０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｒａｄｉｏ＿ｉｎｔｅｎｓｉｔｙ＞＝”１”  ＡＮＤ  ｓｉｐ：１０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｒｅｓｅｎｃｅ＝”ｏｐｅｎ”」というテキストが記述される。
【００８２】
プレゼンスサーバ１００はＳＵＢＳＣＲＩＢＥを受信すると、本実施の形態の先の例と同様の動作をし、ＳＵＢＳＣＲＩＢＥに記述された通知条件を満たすときのみＮＯＴＩＦＹを送信する。
【００８３】
以上のように、ＰＣ１０４がプレゼンスサーバ１００に対して「携帯電話１０１の電波強度が１以上で、ＰＣ１０２が現在ユーザに使用されている」という通知条件を指定した状態通知要求を送り、プレゼンスサーバ１００はＳＵＢＳＣＲＩＢＥに記述された通知条件を満たすときのみ状態通知を行う例を示した。以上のように、通知条件に状態項目と状態値の関係条件として不等号を使うことが可能である。
【００８４】
（実施の形態３）
図１８は、本発明の実施の形態３における通知装置および通知条件指定装置を含むネットワーク構成図である。通知装置として動作するＰＣ６０１、携帯電話６０２、通知条件指定装置および被通知装置として動作するＰＣ６０３はネットワーク６１０に接続されている。ＰＣ６０１、携帯電話６０２はユーザ６２０が所有する機器である。ＰＣ６０３はユーザ６３０が所有する機器である。ＰＣ６０３はＰＣ６０１、携帯電話６０２の状態の通知を望み、ＰＣ６０１もしくは携帯電話６０２のいずれかに状態通知要求を送る。ここではＰＣ６０１に対して、「ＰＣ６０１の場所が会議室以外であり、携帯電話６０２が通話可能」という通知条件を指定した状態通知要求を送り、ＰＣ６０１は携帯電話６０２に対して状態通知要求を送って携帯電話６０２の状態を取得し、通知条件を満たすときのみ状態通知を行う例を示す。
【００８５】
図１９を用いて実施の形態３における通知装置および通知条件指定装置のメッセージフローを説明する。なお、図１９では図２と同様に簡単化のため「２００  ＯＫ」応答の記述を省略している。
【００８６】
図１９において、通知条件指定装置として動作するＰＣ６０３は、通知装置として動作するＰＣ６０１に対して通知条件を記述したＳＵＢＳＣＲＩＢＥを送信する。このとき通知条件としては「ＰＣ６０１の場所が会議室以外であり、携帯電話６０２が通話可能」という条件を表す「ＮＯＴ（ｓｉｐ：６０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｌａｃｅ＝”ｍｅｅｔｉｎｇ”）  ＡＮＤ  ｓｉｐ：６０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”」というメッセージをＳＩＰボディ部に記述する。ＰＣ６０１は、ＳＵＢＳＣＲＩＢＥを受信すると、携帯電話６０２に対して基本状態の通知要求を行うＳＵＢＳＣＲＩＢＥを送信する。
【００８７】
携帯電話６０２は、ＳＵＢＳＣＲＩＢＥを受信すると基本状態を記述したＮＯＴＩＦＹをＰＣ６０１に送信する。ＰＣ６０１はＮＯＴＩＦＹを受信すると、取得した携帯電話６０２の基本状態とＰＣ６０１自身が持つ場所状態を記述したＮＯＴＩＦＹをＰＣ６０３に送信する。その後、携帯電話６０３は状態が変化するたびにＰＣ６０１に対してＮＯＴＩＦＹを送信する。ＰＣ６０１は携帯電話６０３からＮＯＴＩＦＹを受信した場合、もしくはＰＣ６０１自身の場所状態が変化した場合に通知条件を満たしているか確認し、通知条件を満たさない場合はＮＯＴＩＦＹを送信せず、通知条件を満たすときのみ被通知装置として動作するＰＣ６０３に対してＮＯＴＩＦＹを送信する。
【００８８】
ここで図１８に戻り実施の形態３の詳細な説明をする。
【００８９】
ＰＣ６０１は場所の状態を表す”ｐｌａｃｅ”という状態項目を持ち、ｐｌａｃｅは「居室／会議室／その他」を表す”Ｄｅｓｋ／ｍｅｅｔｉｎｇ／ｏｔｈｅｒ”という３つの状態値を持つ。場所状態の検出方法としてはＰＣ６０１にＲＦＩＤ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）タグを搭載して、居室と会議室にＲＦＩＤ受信機を設置することにより、ＰＣ６０１の場所の状態を検出する方法など、様々な方法が考えられる。
【００９０】
携帯電話６０２は、実施の形態１の携帯電話１０１と同様に基本的な状態を表す”ｓｔａｔｅ”という状態項目を持ち、ｓｔａｔｅは「スタンバイ／電源オフ／通話中」を表す”ｓｔａｎｄｂｙ／ｏｆｆ／ｂｕｓｙ”という３つの状態値を持つ。ユーザ６３０はユーザ６２０の携帯電話に連絡することを望んでおり、ユーザ６２０が電話可能状態になったらＰＣ６０３の画面に状態を表示することを望む。ここで電話可能状態とは「ユーザ６２０が会議室中以外で、携帯電話６０２が通話可能」という状態を示す。
【００９１】
ユーザ６２０の状態については所有するＰＣ６０１の場所状態を「会議室以外」と指定し、携帯電話６０２については基本状態を「通話可能」と指定する。ユーザはＰＣ６０３に通知条件を入力し、ＰＣ６０３は入力された条件を通知条件として記述したＳＵＢＳＣＲＩＢＥをＰＣ６０１に送信する。ここで通知条件としては「ＰＣ６０１の場所が会議室以外であり、携帯電話６０２の電波強度が１以上」という条件を指定する。ＰＣ６０３はＰＣ６０１からのＮＯＴＩＦＹを受信するとその情報を画面に表示し、ユーザ６２０の状態をユーザ６３０に対して知らせる。なお、ＰＣ６０３の装置構成と動作については実施の形態２のＰＣ１０４と同様であるため詳細な説明は省略する。
【００９２】
ＰＣ６０１はＰＣ６０３が送信したＳＵＢＳＣＲＩＢＥを受信すると、そこに記述された通知条件を保持する。そして携帯電話６０２に対してＳＵＢＳＣＲＩＢＥを送信して基本状態を取得する。携帯電話６０２の基本状態とＰＣ６０１の場所状態が通知条件を満たさない場合はＮＯＴＩＦＹを送信せず、通知条件を満たす場合にはＰＣ６０３に対してＮＯＴＩＦＹを送信する。ＰＣ６０１の動作の詳細については後述する。携帯電話６０２はＰＣ６０１からのＳＵＢＳＣＲＩＢＥを受信すると基本状態を記述したＮＯＴＩＦＹをＰＣ６０１に送信する。
【００９３】
次にＰＣ６０１の動作について詳細を説明する。なお、ＰＣ６０１の装置構成については実施の形態２のプレゼンスサーバ１００と同様である。また、実施の形態１、実施の形態２と同様に、簡単化のため各メッセージに対する「２００  ＯＫ」応答の動作については説明を省略する。最初にＰＣ６０１のＳＵＢＳＣＲＩＢＥ受信動作について図１４と図２０を用いて説明する。図２０は、本発明の実施の形態４における通知装置であるＰＣ６０１のＳＵＢＳＣＲＩＢＥ受信フローチャートである。本実施の形態の通知装置であるＰＣ６０１の構成は、図１４に示す本発明の実施の形態２における通知装置であるプレゼンスサーバ１００の構成と同じである。
【００９４】
図２０において、通信部５０５が通知条件指定装置であるＰＣ６０３から送信されたＳＵＢＳＣＲＩＢＥを受信し（Ｓ６０１）、受信したＳＵＢＳＣＲＩＢＥを制御部５０１に送る（Ｓ６０２）。制御部５０１はＳＵＢＳＣＲＩＢＥに記述された通知条件と通知先ＵＲＩを通知条件保持部５０３に保存する（Ｓ６０３）。ここでは通知条件が「ＮＯＴ（ｓｉｐ：６０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｌａｃｅ＝”ｍｅｅｔｉｎｇ”）  ＡＮＤ  ｓｉｐ：６０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”」と記述されているものとし、これを保存する。通知先ＵＲＩとしてはＣｏｎｔａｃｔヘッダに記述されたＵＲＩを保存する。
【００９５】
その後、通知条件に記述された携帯電話６０２のＵＲＩをメッセージ生成部５０４に送る（Ｓ６０４）。メッセージ生成部５０４は受け取ったＵＲＩをＲｅｑｕｅｓｔ−ＵＲＩに記述したＳＵＢＳＣＲＩＢＥを生成し（Ｓ６０５）、それを通信部５０５に送る（Ｓ６０６）。通信部５０５はＳＵＢＳＣＲＩＢＥを携帯電話６０２に送信し（Ｓ６０７）、ＳＵＢＳＣＲＩＢＥに対するＮＯＴＩＦＹの受信を待つ（Ｓ６０８）。
【００９６】
携帯電話６０２からのＮＯＴＩＦＹを通信部５０５が受信すると（Ｓ６０９）、通信部５０５は受信したＮＯＴＩＦＹを制御部５０１に送る（Ｓ６１０）。制御部５０１はＮＯＴＩＦＹに記述された状態を状態管理データベース５０２に保存する（Ｓ６１１）。例えばＮＯＴＩＦＹに「ｓｉｐ：６０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｂｕｓｙ」という状態が記述されていた場合は、情報管理データベース５０２のｓｉｐ：６０２＠ｅｘａｍｐｌｅ．ｃｏｍというＵＲＩが持つ状態項目”ｓｔａｔｅ”の状態値を”ｂｕｓｙ”に変更する。
【００９７】
その後、制御部５０１はＰＣ６０３から送信されたＮＯＴＩＦＹの通知条件に記述された機器の状態を状態管理データベース５０２から取得する（Ｓ６１２）。例えば、状態条件が「ＮＯＴ（ｓｉｐ：６０１＠ｅｘａｍｐｌｅ．ｃｏｍ：ｐｌａｃｅ＝”ｍｅｅｔｉｎｇ”）  ＡＮＤ  ｓｉｐ：６０２＠ｅｘａｍｐｌｅ．ｃｏｍ：ｓｔａｔｅ＝”ｓｔａｎｄｂｙ”」である場合はｓｉｐ：６０１＠ｅｘａｍｐｌｅ．ｃｏｍのｐｌａｃｅとｓｉｐ：６０２＠ｅｘａｍｐｌｅ．ｃｏｍのｓｔａｔｅの各状態を取得する。なお、ＰＣ６０１自身の状態については状態が変化するたびに状態管理データベース５０２に保存されるものとする。
【００９８】
制御部５０１は取得した状態をメッセージ生成部５０４に送り（Ｓ６１３）、メッセージ生成部５０４は状態を記述したＮＯＴＩＦＹを生成する（Ｓ６１４）。メッセージ生成部５０４は生成したＮＯＴＩＦＹを通信部５０５に送り（Ｓ６１５）、通信部５０５はＮＯＴＩＦＹを被通知装置であるＰＣ６０３に送信する（Ｓ６１６）。
【００９９】
次にＰＣ６０１のＮＯＴＩＦＹ受信動作について図１４と図２１を用いて説明する。図２１は、本発明の実施の形態３における通知装置であるＰＣ６０１のＮＯＴＩＦＹ受信フローチャートである。なお、図２１が示す動作は携帯電話６０２からの最初のＮＯＴＩＦＹ（ＳＵＢＳＣＲＩＢＥに対するＮＯＴＩＦＹ）の動作とは異なる。最初のＮＯＴＩＦＹについては図２０のフローチャートに示された動作を行う。
【０１００】
図２１にて、通信部５０５が携帯電話６０２からのＮＯＴＩＦＹを受信し（Ｓ７０１）、受信したＮＯＴＩＦＹを制御部５０１に送る（Ｓ７０２）。制御部５０１はＮＯＴＩＦＹに記述された状態を状態管理データベース５０２に保存する（Ｓ７０３）。ここで、Ｓ７０４からＳ７１３までのステップは、実施の形態１におけるＳ２０４からＳ２１３までのステップと同様であるため説明を省略する。なお、Ｓ７０４からＳ７１３までのステップは、通知装置であるＰＣ６０１自身の状態が変化し、状態管理データベース５０２に保存されている状態を変更した場合にも実行され、必要に応じてＮＯＴＩＦＹが生成される。
【０１０１】
以上のように実施の形態３では、通知条件指定装置であるＰＣ６０３が、通知装置であるＰＣ６０１に対して通知条件を記述したＳＵＢＳＣＲＩＢＥを送信し、ＰＣ６０１は通知条件に記述された状態を取得するために携帯電話６０２にＳＵＢＳＣＲＩＢＥを送信し状態を取得し、通知条件を満たすときだけ被通知装置であるＰＣ６０３にＮＯＴＩＦＹを送信する例を示した。これによって、プレゼンスサーバが無い場合でも通知条件を指定することができ、ネットワークリソースを有効に使用できるとともに、通知装置であるＰＣ６０１と被通知装置であるＰＣ６０３のＮＯＴＩＦＹ送受信負荷が軽減される。また、実施の形態３のような構成をとることにより、サーバメンテナンスの必要がなくなる。
【産業上の利用可能性】
【０１０２】
以上のように、本発明にかかる通知装置、通知条件指定装置および状態通知方法は、複数の状態条件および状態条件間の論理条件で通知タイミングを指定することによって、不要な通知情報が送信されることが無くなり、通信媒体を有効に使用できるとともに、通知情報送受信負荷が軽減されるという効果を有し、機器もしくは機器のユーザの状態を通知する通知装置、通知条件指定装置として、特にプレゼンスサービスや機器の状態管理サービスにおけるサーバ等として有用である。
【図面の簡単な説明】
【０１０３】
【図１】本発明の実施の形態１における通知装置を含むネットワーク構成図
【図２】本発明の実施の形態１における通知装置の動作を示すメッセージフロー図
【図３】本発明の実施の形態１における通知装置の構成図
【図４】本発明の実施の形態１における通知装置の通知条件設定動作を示すフローチャート
【図５】本発明の実施の形態１における通知装置のＰＵＢＬＩＳＨ受信動作を示すフローチャート
【図６】本発明の実施の形態１における通知装置から通知を受ける被通知装置の構成図
【図７】本発明の実施の形態１における通知装置から通知を受ける被通知装置のＮＯＴＩＦＹ受信動作を示すフローチャート
【図８】本発明の実施の形態１における通知装置から被通知装置に送信されるＮＯＴＩＦＹのデータ構造を示す図
【図９】本発明の実施の形態１における通知装置の状態管理データベースのデータ構造を示す図
【図１０】本発明の実施の形態１における通知装置の通知条件保持部のデータ構造を示す図
【図１１】本発明の実施の形態２における通知装置と通知条件指定装置のメッセージフロー図
【図１２】本発明の実施の形態２における通知条件指定装置であり被通知装置でもあるＰＣ１０４の構成図
【図１３】本発明の実施の形態２における通知条件指定装置であり被通知装置でもあるＰＣ１０４のＳＵＢＳＣＲＩＢＥ送信動作を示すフローチャート
【図１４】本発明の実施の形態２およびに実施の形態３おける通知装置の構成図
【図１５】本発明の実施の形態２における通知装置のＳＵＢＳＣＲＩＢＥ受信動作を示すフローチャート
【図１６】本発明の実施の形態２における通知条件指定装置から送信される通知条件を示すＳＵＢＳＣＲＩＢＥのデータフォーマット図
【図１７】本発明の実施の形態２における通知条件指定装置から送信される通知条件のデータフォーマット図
【図１８】本発明の実施の形態３における通知装置および通知条件指定装置を含むネットワーク構成図
【図１９】実施の形態３における通知装置および通知条件指定装置のメッセージフロー図
【図２０】本発明の実施の形態４における通知装置のＳＵＢＳＣＲＩＢＥ受信動作を示すフローチャート
【図２１】本発明の実施の形態３における通知装置のＮＯＴＩＦＹ受信動作を示すフローチャート
【図２２】従来の通知装置及び通知条件指定装置兼被通知装置を含むＳＩＰイベント通知機能を使ったプレゼンスサービスにおけるネットワーク構成を示す図
【図２３】従来の通知装置及び被通知装置におけるＳＩＰを使ったプレゼンスサービスのメッセージフロー図
【図２４】従来の通知装置及び通知条件指定装置におけるイベントフィルタのメッセージフロー図
【符号の説明】
【０１０４】
１００  プレゼンスサーバ
１０１、６０３  携帯電話
１０２、１０４、６０１、６０３  ＰＣ
１０３  固定電話
１１０、６１０  ネットワーク
１２０、１３０、６２０、６３０  ユーザ
２０１、３０１、４０１、５０１  制御部
２０２、３０６、４０２  画面出力部
３０７、４０３  キー入力部
３０４、４０４、５０４  メッセージ生成部
２０３、３０５、４０５、５０５  通信部
３０２、５０２  状態管理データベース
３０３、５０３  通知条件保持部
【図１】
2006238112.tif 000003
【図２】
2006238112.tif 000004
【図３】
2006238112.tif 000005
【図４】
2006238112.tif 000006
【図５】
2006238112.tif 000007
【図６】
2006238112.tif 000008
【図７】
2006238112.tif 000009
【図８】
2006238112.tif 000010
【図９】
2006238112.tif 000011
【図１０】
2006238112.tif 000012
【図１１】
2006238112.tif 000013
【図１２】
2006238112.tif 000014
【図１３】
2006238112.tif 000015
【図１４】
2006238112.tif 000016
【図１５】
2006238112.tif 000017
【図１６】
2006238112.tif 000018
【図１７】
2006238112.tif 000019
【図１８】
2006238112.tif 000020
【図１９】
2006238112.tif 000021
【図２０】
2006238112.tif 000022
【図２１】
2006238112.tif 000023
【図２２】
2006238112.tif 000024
【図２３】
2006238112.tif 000025
【図２４】
2006238112.tif 000026