情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラム
【課題】 リソースのノーティファイアからサブスクライバに送信されるＮＯＴＩＦＹによるネットワーク負荷を軽減可能な情報交換システムを提供する。
【解決手段】 リソースリストサーバ２はリストに対するＳＵＢＳＣＲＩＢＥ要求を受信すると、リストに含まれるリソースの各々に対してＳＵＢＳＣＲＩＢＥ要求を発行し、リソースのノーティファイア３からリソースの状態のＮＯＴＩＦＹを受信すると、そのリソースが含まれるリストに対するサブスクリプションを持つサブスクライバ１に対してＮＯＴＩＦＹを送信する。ノーティファイア３がすでに存在するサブスクリプションに対する更新要求を受けた場合、内容が空のＮＯＴＩＦＹをリソースリストサーバ２からサブスクライバ１に送信する。
【解決手段】 リソースリストサーバ２はリストに対するＳＵＢＳＣＲＩＢＥ要求を受信すると、リストに含まれるリソースの各々に対してＳＵＢＳＣＲＩＢＥ要求を発行し、リソースのノーティファイア３からリソースの状態のＮＯＴＩＦＹを受信すると、そのリソースが含まれるリストに対するサブスクリプションを持つサブスクライバ１に対してＮＯＴＩＦＹを送信する。ノーティファイア３がすでに存在するサブスクリプションに対する更新要求を受けた場合、内容が空のＮＯＴＩＦＹをリソースリストサーバ２からサブスクライバ１に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラムに関し、特にサブスクライバとノーティファイアとの間のネットワーク負荷軽減に関する。
【背景技術】
【０００２】
リソースの状態を一定期間観察するサブスクライバと、リソースの状態をサブスクライバに通知するノーティファイアとの間のフレームワークとして、非特許文献１に示されるものがある。このフレームワークを応用した例としては、プレゼンスサービスに適用した例がある（例えば、非特許文献２参照）。ここで、プレゼンスサービスとは、各リソースの状態を管理するシステム一般を指し、その基本的なアーキテクチャは、非特許文献３に示されている。尚、リソースとはサブスクライバがその状態を観察する観察対象を示している。
【０００３】
上記のサブスクライバは、一つのリソースだけを観察しているわけではなく、複数のリソースの状態を観察している場合、一般には、それぞれのリソースに対し、個別にＳＵＢＳＣＲＩＢＥ（登録、購読）要求（リクエスト）をノーティファイアに送り、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ：契約、購読）を管理する必要がある。ここで、サブスクリプションはサブスクライバとノーティファイアとの関係や使用するイベントパッケージ等をまとめたものである。
【０００４】
しかしながら、（１）複数のリソースへのサブスクリプションの開始、更新が同時に行われると、ネットワークを流れる一時的なトラフィックが増大する、（２）サブスクライバが要求したサブスクリプションの更新間隔をノーティファイアが受け入れず、頻繁な更新を要求してきた場合、サブスクライバは頻繁なＳＵＢＳＣＲＩＢＥ要求を発行しなければならない、（３）ノーティファイアが、サブスクライバのＳＵＢＳＣＲＩＢＥ要求によって頻繁にリソースの状態通知を行う場合、不必要なＮＯＴＩＦＹ（通知）によってネットワークトラフィックが増大するという問題がある。
【０００５】
これらの問題を解決するため、図１４に示すように、複数のリソースへのＳＵＢＳＣＲＩＢＥ要求を受け付け、複数のリソースの状態を内容に含むひとつのＮＯＴＩＦＹを発行するリソースリストサーバが提案されている（例えば、非特許文献４，５参照）。しかしながら、この方法では、ＳＵＢＳＣＲＩＢＥ要求によるネットワーク負荷の軽減を図ることができるが、ＮＯＴＩＦＹによるネットワーク負荷及びサブスクライバの処理の負荷については、かえって増大してしまう可能性もある。
【０００６】
一方、状態通知をフィルタすることによって、ＮＯＴＩＦＹによるネットワーク負荷を軽減する方法についても提案されているが（例えば、非特許文献６，７参照）、リソースリストサーバからリソースへのバックエンドサブスクリプションの負荷を軽減するもので、リソースリストサーバからサブスクライバへ通知されるＮＯＴＩＦＹの内容を直接フィルタするものではない。
【０００７】
【非特許文献１】“Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）−Ｓｐｅｃｉｆｉｃ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ ３．Ｎｏｄｅ Ｂｅｈａｖｉｏｒ”［ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）３２６５，Ｊｕｎｅ ２００２］
【非特許文献２】“Ａ Ｐｒｅｓｅｎｃｅ Ｅｖｅｎｔ Ｐａｃｋａｇｅ ｆｏｒ ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ） Ｓｔａｔｕｓ ｏｆ ｔｈｉｓ Ｍｅｍｏ”（ＲＦＣ３８５６，Ａｕｇｕｓｔ ２００４）
【非特許文献３】“Ａ Ｍｏｄｅｌ ｆｏｒ Ｐｒｅｓｅｎｃｅ ａｎｄ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ”（ＲＦＣ２７７８，Ｆｅｂｒｕａｒｙ ２０００）
【非特許文献４】“Ａ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ） Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ Ｒｅｓｏｕｒｃｅ Ｌｉｓｔｓ ４．Ｏｐｅｒａｔｉｏｎ ｏｆ Ｌｉｓｔ Ｓｕｂｓｃｒｉｐｔｉｏｎｓ，５．Ｕｓｉｎｇ ｍｕｌｔｉｐａｒｔ／ｒｅｌａｔｅｄ ｔｏ Ｃｏｎｖｅｙ Ａｇｇｒｅｇａｔｅ Ｓｔａｔｅ”［ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ） Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｄｅｃｅｍｂｅｒ １５，２００４（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７．ｔｘｔ）］
【非特許文献５】“Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ） Ｆｏｒｍａｔｓ ｆｏｒ Ｒｅｐｒｅｓｅｎｔｉｎｇ Ｒｅｓｏｕｒｃｅ Ｌｉｓｔｓ”［ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｆｅｂｒｕａｒｙ ７，２００５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｘｃａｐ−ｌｉｓｔ−ｕｓａｇｅ−０５．ｔｘｔ）］
【非特許文献６】“Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ） Ｂａｓｅｄ Ｆｏｒｍａｔ ｆｏｒ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｆｉｌｔｅｒｉｎｇ”［ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｍａｒｃｈ １５，２００５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｆｉｌｔｅｒ−ｆｏｒｍａｔ−０５．ｔｘｔ）］
【非特許文献７】“”［ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｍａｒｃｈ １５，２００５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｆｉｌｔｅｒ−ｆｕｎｃｔ−０５．ｔｘｔ）］
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上述した従来のリソースリストサーバでは、上記の非特許文献４に記載の方法の場合、サブスクライバがサブスクリプションの更新を行うと、リソースのノーティファイアは、リソースの状態を内容に含むＮＯＴＩＦＹを送信する。これによって、サブスクライバはサブスクリプションの更新要求が受理されたことを知ることができる。しかしながら、サブスクライバがすでに知っているリソースの状態が再度送信されることになるため、ネットワーク上を無駄なデータが流れることになる。
【０００９】
また、あるサブスクライバから複数のリソースへのサブスクリプションの有効期間が同一の場合、サブスクリプションの更新が一度に行われ、無駄なデータが一度に流れることになるため、ネットワークの負荷がバースト的に増大する。この問題はサブスクライバにとってのノーティファイアが、リソースリストサーバである場合にも、同様である。
【００１０】
そこで、本発明の目的は上記の問題点を解消し、サブスクリプションの更新によってネットワーク上を無駄なデータが流れるのを防止することができる情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明による情報交換システムは、第１の端末装置と、第２の端末装置と、管理サーバとから構成され、
前記第１の端末装置は、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を前記管理サーバに通知する通知手段とを備え、
前記第２の端末装置は、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を前記管理サーバに送信する状態通知要求送信手段を備え、
前記管理サーバは、前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を備えている。
【００１２】
本発明による他の情報交換システムは、ノーティファイアと、サブスクライバと、管理サーバとから構成され、
前記ノーティファイアは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて前記管理サーバに通知する通知手段とを備え、
前記サブスクライバは、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を前記管理サーバに送信するＳＵＢＳＣＲＩＢＥ要求送信手段を備え、
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を備えている。
【００１３】
本発明による管理サーバは、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成し、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を備えている。
【００１４】
本発明による他の管理サーバは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成し、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を備えている。
【００１５】
本発明によるネットワーク負荷軽減方法は、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバが、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行している。
【００１６】
本発明による他のネットワーク負荷軽減方法は、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバが、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行している。
【００１７】
本発明によるネットワーク負荷軽減方法のプログラムは、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバのコンピュータに、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行させている。
【００１８】
本発明による他のネットワーク負荷軽減方法のプログラムは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバのコンピュータに、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行させている。
【００１９】
すなわち、本発明の情報交換システムは、リソースの状態を一定期間観察するサブスクライバと、リソースの状態をサブスクライバに通知するノーティファイアと、リソースのリストを管理するリソースリストサーバとを含むシステムにおいて、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ：契約、購読）の更新時に、リソースの状態を含むＮＯＴＩＦＹ（通知）を送る代わりに、内容が空のＮＯＴＩＦＹを送信している。ここで、サブスクリプションはサブスクライバとノーティファイアとの関係や使用するイベントパッケージ等をまとめたものである。
【００２０】
より具体的に説明すると、本発明の情報交換システムでは、ノーティファイアがすでに存在するサブスクリプションに対する更新要求を受けた場合、内容が空のＮＯＴＩＦＹをサブスクライバに送信している。リソースリストサーバが、リソース毎に個別のＮＯＴＩＦＹを送信する場合でも、リソースリストに対するサブスクリプションが更新された場合には、空のＮＯＴＩＦＹをただ一つ送信している。但し、リソースの状態に変更があった時点で送信されるＮＯＴＩＦＹが未達の場合には、空のＮＯＴＩＦＹではなく、そのリソース内容のＮＯＴＩＦＹを送信する。
【００２１】
これによって、本発明の情報交換システムでは、サブスクリプション更新時に送信されるＮＯＴＩＦＹの内容を空にすることで、ネットワークの負荷が軽減可能となり、サブスクリプション更新時に送信される空のＮＯＴＩＦＹを一つにまとめることで、ネットワークの負荷が軽減可能となる。
【発明の効果】
【００２２】
本発明は、以下に述べるような構成及び動作とすることで、サブスクリプションの更新によってネットワーク上を無駄なデータが流れるのを防止することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２３】
次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の実施の形態による情報交換システムの構成を示すブロック図である。図１において、本発明の実施の形態による情報交換システムはサブスクライバ１と、リソースリストサーバ２と、ノーティファイア３とから構成されている。サブスクライバ１はリソース（サブスクライバ１がその状態を観察する観察対象）の状態を一定期間観察し、ノーティファイア３はリソースの状態をサブスクライバ１に通知する。
【００２４】
リソースリストサーバ２はサブスクライバ１とノーティファイア３との間で状態の情報が交換されるリソースのリストを管理しており、ＳＵＢＳＣＲＩＢＥ（登録、購読）要求受信部２１と、ＮＯＴＩＦＹ（通知）送信部２２と、ＳＵＢＳＣＲＩＢＥ要求送信部２５と、ＮＯＴＩＦＹ受信部２６と、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ：契約、購読）制御部２４と、リスト管理部２３とから構成されている。尚、図１では、本実施例における動作説明に必要なものだけを図示している。
【００２５】
サブスクリプション制御部２４はサブスクリプション管理部２４１と、リスト−サブスクライバ関連管理部２４２と、バックエンドサブスクリプション−リスト関連管理部２４３と、リソース状態管理部２４４とから構成されている。
【００２６】
リスト管理部２３は各リソースリストに含まれるリソースの識別子を管理する。ＳＵＢＳＣＲＩＢＥ要求受信部２１及びＮＯＴＩＦＹ送信部２２はサブスクライバ１とのインタフェースを提供する。ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からリスト管理部２３で管理しているリソースリストに対するＳＵＢＳＣＲＩＢＥ要求あるいはＵＮＳＵＢＳＣＲＩＢＥ要求を受信すると、これをサブスクリプション管理部２４１に伝える。ＮＯＴＩＦＹ送信部２２はリソースの状態を、そのリソースが含まれるリストにサブスクライブしているサブスクライバ１に対してＮＯＴＩＦＹの内容として送信する。
【００２７】
ＳＵＢＳＣＲＩＢＥ要求送信部２５及びＮＯＴＩＦＹ受信部２６はリソースのノーティファイア３とのインタフェースを提供する。ＳＵＢＳＣＲＩＢＥ要求送信部２５はサブスクライバ１に代行し、リソースリストサーバ２からリソースに対するＳＵＢＳＣＲＩＢＥ要求及びＵＮＳＵＢＳＣＲＩＢＥ要求を送信する。ＮＯＴＩＦＹ受信部２６はリソースの状態を、ＮＯＴＩＦＹの内容としてリソースのノーティファイア３から受信する。
【００２８】
尚、リソースのノーティファイア３は各リソースに付随するものであっても、また、プレゼンスサーバのように、複数のリソースの状態をとりまとめるものであってもよい。ここで、プレゼンスサーバとは物理的なエンティティ（機能）であり、ＳＵＢＳＣＲＩＢＥ要求に対してプレゼンスエージェントあるいはプロキシサーバとして動作する。プレゼンスエージェントとして動作する場合には、プレゼンティティのプレゼンス情報［あらゆるものの存在やその状態（例えば、在席中や外出中等の状態）］を把握しており、プロキシサーバとして動作する場合にはプレゼンスエージェントとして動作する他のエンティティにＳＵＢＳＣＲＩＢＥ要求を転送する。
【００２９】
サブスクリプション制御部２４はサブスクライバ１からリストに対するＳＵＢＳＣＲＩＢＥ要求に基づき、バックエンドサブスクリプションを生成する。バックエンドサブスクリプションとは、リソースリストサーバ２からリソースに対するサブスクリプションである。ここで、サブスクリプションはサブスクライバ１とノーティファイア３との関係や使用するイベントパッケージ等をまとめたものである。
【００３０】
サブスクリプション管理部２４１はサブスクライバ１からリストに対するサブスクリプション及びバックエンドサブスクリプションを管理する。サブスクライバ１からＳＵＢＳＣＲＩＢＥ要求やＵＮＳＵＢＳＣＲＩＢＥ要求を受信した場合、サブスクリプション管理部２４１はサブスクリプションの生成・更新・終了を行う。
【００３１】
リスト−サブスクライバ関連管理部２４２は各リストに対するサブスクライバ群を保持する。リスト−サブスクライバ関連管理部２４２はリストに最初にサブスクライバ１が関連付けられると、バックエンドサブスクリプション−リスト関連管理部２４３にリストの追加を依頼し、また、リストに関連付けられたサブスクライバがなくなると、バックエンドサブスクリプション−リスト関連管理部２４３にリストの削除を依頼する。
【００３２】
バックエンドサブスクリプション−リスト関連管理部２４３はリソースリストサーバ２からリソースに対するサブスクリプションと、その契機となったリストとの関連を保持する。リソース状態管理部２４４はバックエンドサブスクリプションに対するＮＯＴＩＦＹによって取得したリソースの状態を保持する。
【００３３】
バックエンドサブスクリプションは、関連付けられた１つ以上のリストが存在する間、有効である。バックエンドサブスクリプションはそのバックエンドサブスクリプションに関連付けられたリストがなくなると消滅し、ＳＵＢＳＣＲＩＢＥ要求送信部２５からＵＮＳＵＢＳＣＲＩＢＥ要求が送られ、またリソース状態管理部２４４で管理されるリソース状態が無効になる。
【００３４】
尚、図１では、リソースリストサーバ２とノーティファイア３とを分けて図示しているが、ノーティファイア３がプレゼンスサーバの場合、これらは一つのサーバとして実装されてもよい。
【００３５】
本発明の実施の形態による情報交換システムでは、リソースリストサーバ２が、リストに対するＳＵＢＳＣＲＩＢＥ要求を受信すると、リストに含まれるリソースの各々に対してＳＵＢＳＣＲＩＢＥ要求を発行し、リソースのノーティファイア３からリソースの状態のＮＯＴＩＦＹを受信すると、そのリソースが含まれるリストに対するサブスクリプションを持つサブスクライバ１に対してＮＯＴＩＦＹを送信する。
【００３６】
これによって、本発明の実施の形態による情報交換システムでは、各リソースから個別に状態通知を受信したい場合に、複数のリソースへのＳＵＢＳＣＲＩＢＥ要求を一つにまとめることが可能となるため、サブスクリプション開始のためのＳＵＢＳＣＲＩＢＥ要求送信時及びサブスクリプション更新のためのＳＵＢＳＣＲＩＢＥ要求送信時のネットワークの負荷を軽減することができる。
【００３７】
また、本発明の実施の形態による情報交換システムでは、内容が大きなＮＯＴＩＦＹを一つ送る代わりに、内容が小さなＮＯＴＩＦＹを複数送ることで、ネットワークの負荷を軽減することができる。さらに、本発明の実施の形態による情報交換システムでは、一つのＮＯＴＩＦＹの内容を小さくすることによって、サブスクライバ１がＮＯＴＩＦＹの内容を解釈する処理の負荷を軽減することができる。さらにまた、本発明の実施の形態による情報交換システムでは、ＮＯＴＩＦＹの送信のタイミングを分散させることで、ネットワークの負荷を軽減することができる。
【実施例１】
【００３８】
図２は本発明の第１の実施例によるリスト管理部のリストテーブル例を示す図である。ここで、本発明の第１の実施例による情報交換システムの構成は図１に示す本発明の実施の形態による情報交換システムと同様の構成となっており、図２に示すリスト管理部はリソースリストサーバ２のリスト管理部２３の構成を表している。
【００３９】
図２において、リスト管理部２３にはリストＡ〜Ｎのリストテーブルが格納されており、リストＡ〜Ｎのリストテーブル各々にはリソース識別子が登録されている。例えば、リストＡのリストテーブルにはリソース識別子ａ〜ｃが登録されている。
【００４０】
図３は本発明の第１の実施例による情報交換システムの動作を示すシーケンスチャートであり、図４〜図６は本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートであり、図７及び図８は本発明の第１の実施例によるＵＮＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートであり、図９は本発明の第１の実施例によるＮＯＴＩＦＹ受信処理を示すフローチャートである。これら図１〜図９を参照して本発明の第１の実施例による情報交換システムの動作について説明する。尚、図１に示すリソースリストサーバ２の処理は図示せぬコンピュータがプログラムを実行することでも実現可能であり、図４〜図９に示す処理はこのコンピュータがプログラムを実行することで実現される。
【００４１】
ＳＵＢＳＣＲＩＢＥ受信処理を行う場合、ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からＳＵＢＳＣＲＩＢＥ要求を受信すると（図４ステップＳ１）、指定されたリストがリスト管理部２３で管理しているリストかどうかを調べ（図４ステップＳ２）、リスト管理部２３で管理していなければ、サブスクライバ１に対してエラー送信を行う（図４ステップＳ３）。また、ＳＵＢＳＣＲＩＢＥ要求受信部２１は管理しているリストであれば、ＳＵＢＳＣＲＩＢＥ要求をサブスクリプション管理部２４１に渡す。
【００４２】
サブスクリプション管理部２４１はそのリストに対するサブスクリプションがすでにあるかを調べ（図４ステップＳ４）、サブスクリプションがなければ、サブスクリプションを新規作成し（図４ステップＳ５）、サブスクライバ１に対して正常応答を返す（図４ステップＳ６）。サブスクリプション管理部２４１で新たにサブスクリプションが生成されると、サブスクリプション制御部２４はリスト管理部２３からＳＵＢＳＣＲＩＢＥ要求で指定されたリストに含まれるリソースの識別子を取得し（図４ステップＳ７）、取得したすべてのリソースに対して以下の処理を繰り返し行う。
【００４３】
バックエンドサブスクリプション−リスト関連管理部２４２はバックエンドサブスクリプションが存在しない場合（図５ステップＳ１０）、バックエンドサブスクリプションを作成し（図５ステップＳ１１）、ＳＵＢＳＣＲＩＢＥ要求送信部２５からリソースに対するＳＵＢＳＣＲＩＢＥ要求をノーティファイア３に送信する（図５ステップＳ１２）。
【００４４】
バックエンドサブスクリプション−リスト関連管理部２４２は注目するリソースに対するバックエンドサブスクリプションとリストとの関連が保持されていない場合（図５ステップＳ１３）、そのリソースに対するバックエンドサブスクリプションとリストとの関連を追加する（図５ステップＳ１４）。リスト−サブスクライバ関連管理部２４２はリストとサブスクライバとの関連が保持されていない場合（図５ステップＳ１５）、リストとサブスクライバとの関連を追加する（図５ステップＳ１６）。
【００４５】
サブスクリプション制御部２４はリスト管理部２３から取得したリソースの識別子を基にリソースの状態をリソース状態管理部２４４から取得し、これらの内容に含む個別のＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２からサブスクライバ１に対して送信する（図５ステップＳ１７）。リソースリストサーバ２は上記の処理を取得した全てのリソースに対する処理が終了するまで繰り返し行う（図５ステップＳ１０〜Ｓ１８）。
【００４６】
一方、サブスクリプション管理部２４１はサブスクリプションがすでにあれば、サブスクリプションを更新し（図４ステップＳ８）、サブスクライバ１に対して正常応答を返す（図４ステップＳ９）。サブスクリプション制御部２４はサブスクリプションが更新されると、リスト管理部２３からリストに含まれるリソースの識別子を取得し（図６ステップＳ１９）、これらに対する個別のＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２からサブスクライバ１に対して送信する（図６ステップＳ２０，Ｓ２１）。送信するＮＯＴＩＦＹは空のＮＯＴＩＦＹが送信される。但し、リソースの状態に変更があった時点で送信されるＮＯＴＩＦＹが未達の場合には（図６ステップＳ２０）、空のＮＯＴＩＦＹではなく、そのリソースの状態を内容として含むＮＯＴＩＦＹが送信される（図６ステップＳ２２）。
【００４７】
ＵＮＳＵＢＳＣＲＩＢＥ受信処理を行う場合、ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からＵＮＳＵＢＳＣＲＩＢＥ要求を受信すると（図７ステップＳ３１）、指定されたリストがリスト管理部２３で管理しているリストかどうかを調べ（図７ステップＳ３２）、管理しているリストでなければ、サブスクライバ１に対してエラー送信を行う（図７ステップＳ３３）。また、ＳＵＢＳＣＲＩＢＥ要求受信部２１は管理しているリストであれば、ＳＵＢＳＣＲＩＢＥ要求をサブスクリプション管理部２４１に渡す。
【００４８】
サブスクリプション管理部２４１はＵＮＳＵＢＳＣＲＩＢＥ要求を受信すると、そのリストに対するサブスクリプションがすでにある場合（図７ステップＳ３４）、サブスクリプションを終了し（図７ステップＳ３５）、サブスクライバ１に対して正常応答を返す（図７ステップＳ３６）。サブスクリプション管理部２４１はそのリストに対するサブスクリプションがない場合（図７ステップＳ３４）、サブスクライバ１に対してエラー送信を行う（図７ステップＳ３３）。
【００４９】
サブスクリプション制御部２４はサブスクリプションが終了されると、リスト管理部２３からリストに含まれるリソースの識別子を取得し（図７ステップＳ３７）、それぞれのリソースの状態をリソース状態管理部２４４から取得し（図７ステップＳ３８）、これらを内容に含む個別のＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２からサブスクライブ１に対して送信する（図７ステップＳ３９）。また、サブスクリプション制御部２４はリスト−サブスクライバ関連管理部２４２からリストに対するサブスクライバ１の関連付けを削除する（図７ステップＳ４０）。
【００５０】
サブスクリプション制御部２４はそのリストに関連付けられたサブスクライバが一つもなくなった場合（図７ステップＳ４１）、バックエンドサブスクリプション−リスト関連管理部２４３で管理される各リソースに対するバックエンドサブスクリプションについて以下の処理を行う。
【００５１】
サブスクリプション制御部２４はリソースに対するバックエンドサブスクリプションとリストとの関連を削除し（図８ステップＳ４２）、リソースのバックエンドサブスクリプションに関連付けられたリストが一つもなくなった場合（図８ステップＳ４３）、バックエンドサブスクリプションを終了する（図８ステップＳ４４）。その後に、サブスクリプション制御部２４はＳＵＢＳＣＲＩＢＥ要求送信部２５からリソースに対してＵＮＳＵＢＳＣＲＩＢＥ要求を送信する（図８ステップＳ４５）。
【００５２】
ＮＯＴＩＦＹ受信処理を行う場合、ＮＯＴＩＦＹ受信部２６はリソースのノーティファイア（例えば、プレゼンスサーバ）３からリソースの状態を内容に含むＮＯＴＩＦＹを受信すると（図９ステップＳ５１）、このＮＯＴＩＦＹをサブスクリプション管理部２４１に渡す。サブスクリプション管理部２４１は受信したリソースの状態をリソース状態管理部２４４に保持されたリソースの状態と比較し（図９ステップＳ５２）、その比較結果が異なる場合（図９ステップＳ５３）、以下の処理を繰り返し行う。
【００５３】
サブスクリプション管理部２４１はリソース状態管理部２４４で管理されるリソースの状態を受信したリソースの状態で更新する（図９ステップＳ５４）。サブスクリプション管理部２４１はバックエンドサブスクリプション−リスト関連管理部２４３からそのリソースのバックエンドサブスクリプションと関連付けられたリストを選択する（図９ステップＳ５５）。
【００５４】
サブスクリプション管理部２４１は選択した全てのリストについて、リスト−サブスクライバ関連管理部２４２で管理されるサブスクライバを決定し（図９ステップＳ５６）、選択されたサブスクライバ１に対し、リソースの状態を内容に含むＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２から送信する（図９ステップＳ５７）。
【００５５】
図１０は本発明の第１の実施例によるサブスクライバ１の構成を示すブロック図である。図１０において、サブスクライバ（端末装置）１はＣＰＵ（中央処理装置）１１と、ＣＰＵ１１が実行する制御プログラム１２ａを格納するメインメモリ１２と、ＣＰＵ１１が制御プログラム１２ａを実行する際に作業領域として使用する記憶装置１３と、リソースリストサーバ２との通信を制御する通信制御部１４とから構成されており、ＣＰＵ１１とメインメモリ１２と記憶装置１３と通信制御部１４とが内部バス１１０にて相互に接続されている。また、記憶装置１３はリソースリストサーバ２から取得したリソースリストを保持するリソースリスト保持部１３１を備えている。
【００５６】
図１１は本発明の第１の実施例によるサブスクライバ１の動作例を示すフローチャートである。これら図１０及び図１１を参照してサブスクライバ１の動作例について説明する。尚、図１１に示す処理はＣＰＵ１１が制御プログラム１２ａを実行することで実現される。
【００５７】
サブスクライバ１はリスト指定及びサポート通知を含むＳＵＢＳＣＲＩＢＥ要求をリソースリストサーバ２に送信し（図１１ステップＳ６１）、リソースリストサーバ２からサポート通知に対するリソースリストを受信すると（図１１ステップＳ６２）、そのリソースリストを記憶装置１３のリソースリスト保持部１３１に保持する（図１１ステップＳ６３）。
【００５８】
その後に、サブスクライバ１はリソースリストサーバ２からＳＵＢＳＣＲＩＢＥ要求に対するＮＯＴＩＦＹを受信すると（図１１ステップＳ６４）、そのＮＯＴＩＦＹをリソースリスト保持部１３１に保持するリソースリストと照合する（図１１ステップＳ６５）。
【００５９】
サブスクライバ１はその照合で受信対象のＮＯＴＩＦＹと判定すると（図１１ステップＳ６６）、そのＮＯＴＩＦＹの内容を解釈する（図１１ステップＳ６７）。また、サブスクライバ１はその照合で受信対象のＮＯＴＩＦＹと判定しなければ（図１１ステップＳ６６）、そのＮＯＴＩＦＹを廃棄する（図１１ステップＳ６８）。サブスクライバ１は上記のＳＵＢＳＣＲＩＢＥ要求にて指定したリストに含まれるリソースに対するＮＯＴＩＦＹ（受信対象）を全て受信するまで（図１１ステップＳ６９）、上記の処理を繰り返し行う。
【００６０】
このように、本実施例では、各リソースから個別に状態通知を受信したい場合、複数のリソースへのＳＵＢＳＣＲＩＢＥ要求を一つにまとめることができるため、サブスクリプション開始のためのＳＵＢＳＣＲＩＢＥ要求送信時及びサブスクリプション更新のためのＳＵＢＳＣＲＩＢＥ要求送信時のネットワークの負荷を軽減することができる。
【００６１】
また、本実施例では、内容が大きなＮＯＴＩＦＹを一つ送る代わりに、内容が小さなＮＯＴＩＦＹを複数送ることで、ネットワークの負荷を軽減することができる。さらに、本実施例では、一つのＮＯＴＩＦＹの内容を小さくすることによって、サブスクライバ１がＮＯＴＩＦＹの内容を解釈する処理の負荷を軽減することができる。尚、本実施例では、サブスクライバ１からのＳＵＢＳＣＲＩＢＥ要求をリソースリストサーバ２で処理してノーティファイア３に渡しているが、ノーティファイア３にリスト管理部を設けることで、サブスクライバ１からのＳＵＢＳＣＲＩＢＥ要求をそのままノーティファイア３に渡しても、上記と同様の効果を得ることができ、これに限定されない。
【実施例２】
【００６２】
図１２は本発明の第２の実施例による情報交換システムの構成を示すブロック図である。図１２において、本発明の第２の実施例による情報交換システムは、リソースリストサーバ４のＮＯＴＩＦＹ送信部４１にネットワーク負荷分散部４１１を設けた以外は図１に示す本発明の実施の形態による情報交換システムと同様の構成となっており、同一構成要素には同一符号を付してある。また、同一構成要素の動作は上述した本発明の実施の形態と同様である。
【００６３】
ネットワーク負荷分散部４１１はサブスクライバ１に対するＮＯＴＩＦＹの送信のタイミングを分散させることで、ネットワークの負荷を軽減することができる。また、本実施例では、サブスクライバ１の処理の負荷を軽減することができる。
【００６４】
ネットワーク負荷分散部４１１は、（１）同一のサブスクライバに対するＮＯＴＩＦＹの送信タイミングを分散させるもの、（２）複数のサブスクライバ間でＮＯＴＩＦＹの送信タイミングを分散させるもの（サブスクライバが選択されるが、同一サブスクライバに対するＮＯＴＩＦＹはそのまま送られる）、（３）サブスクライバの区別なく、ＮＯＴＩＦＹの送信タイミングを分散させるもの、等がある。
【００６５】
ネットワーク負荷分散部４１１の例としては、各ＮＯＴＩＦＹを送信する前に、「基準送信待ち時間×乱数」期間待つという方式がある。基準送信待ち時間は固定的な値でもよいし、ネットワーク負荷に応じて変動する値であってもよい。ネットワーク負荷に応じて変動する場合、負荷が高いほど、基準送信待ち時間は長くなる。
【００６６】
このように、本実施例では、リソースリストサーバ４のＮＯＴＩＦＹ送信部４１にネットワーク負荷分散部４１１を設け、ＮＯＴＩＦＹの送信のタイミングを分散させることで、ネットワークの負荷を軽減することができる。
【実施例３】
【００６７】
図１３は本発明の第３の実施例によるＳＵＢＳＣＲＩＢＥ受信処理（更新）を示すフローチャートである。本発明の第３の実施例による情報交換システムは図１に示す本発明の実施の形態による情報交換システムと同様の構成となっている。これら図１と図１３とを参照して本発明の第３の実施例による情報交換システムの動作について説明する。尚、図１３に示す処理は上記の本発明の第１の実施例と同様に、コンピュータがプログラムを実行することで実現される。また、本発明の第３の実施例による情報交換システムは図１２に示す本発明の第２の実施例による情報交換システムと同様の構成としてもよい。
【００６８】
本実施例は、本発明の第３の実施例に加え、サブスクリプション更新時にＮＯＴＩＦＹ送信部２２から送信される空のＮＯＴＩＦＹが、リソース毎ではなく、リストに対するものである点が異なる。
【００６９】
ＳＵＢＳＣＲＩＢＥ受信処理（更新）を行う場合、ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からＳＵＢＳＣＲＩＢＥ要求を受信すると（図１３ステップＳ７１）、指定されたリストがリスト管理部２３で管理しているリストかどうかを調べ（図１３ステップＳ７２）、リスト管理部２３で管理していなければ、サブスクライバ１に対してエラー送信を行う（図１３ステップＳ７３）。また、ＳＵＢＳＣＲＩＢＥ要求受信部２１は管理しているリストであれば、ＳＵＢＳＣＲＩＢＥ要求をサブスクリプション管理部２４１に渡す。
【００７０】
サブスクリプション管理部２４１はそのリストに対するサブスクリプションがすでにあるかを調べ（図１３ステップＳ７４）、サブスクリプションがなければ、サブスクリプションを新規作成し（図１３ステップＳ７５）、サブスクライバ１に対して正常応答を返す（図１３ステップＳ７６）。サブスクリプション管理部２４１で新たにサブスクリプションが生成されると、サブスクリプション制御部２４はリスト管理部２３からＳＵＢＳＣＲＩＢＥ要求で指定されたリストに含まれるリソースの識別子を取得し（図１３ステップＳ７７）、取得したすべてのリソースに対して上述した本発明の第１の実施例におけるステップＳ１０以下の処理を繰り返し行う。
【００７１】
サブスクリプション管理部２４１はＳＵＢＳＣＲＩＢＥ要求を受信すると、そのリストに対するサブスクリプションがすでにある場合（図１３ステップＳ７４）、サブスクリプションを更新し（図１３ステップＳ７８）、サブスクライバ１に対して正常応答を返す（図１３ステップＳ７９）。
【００７２】
サブスクリプション制御部２４はサブスクリプションが更新されると、内容が空のＮＯＴＩＦＹを一つ送信する（図１３ステップＳ８０，Ｓ８１）。但し、リソースの状態に変更があった時点で送信されるＮＯＴＩＦＹが未達の場合には（図１３ステップＳ８０）、空のＮＯＴＩＦＹではなく、そのリソースの状態を内容として含むＮＯＴＩＦＹが送信される（図１３ステップＳ８２）。
【００７３】
このように、本実施例では、サブスクリプション更新時にサブスクライバ１に対して送信される空のＮＯＴＩＦＹを一つにまとめることで、ネットワークの負荷を軽減することができる。
【産業上の利用可能性】
【００７４】
本発明は、インタネットに限らず、あらゆるものの存在やその状態（例えば、在席中や外出中等の状態）を通知するプレゼンスサービス、特にモバイル環境におけるプレゼンスサービスに適用可能である。
【図面の簡単な説明】
【００７５】
【図１】本発明の実施の形態による情報交換システムの構成を示すブロック図である。
【図２】本発明の第１の実施例によるリスト管理部のリストテーブル例を示す図である。
【図３】本発明の第１の実施例による情報交換システムの動作を示すシーケンスチャートである。
【図４】本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図５】本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図６】本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図７】本発明の第１の実施例によるＵＮＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図８】本発明の第１の実施例によるＵＮＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図９】本発明の第１の実施例によるＮＯＴＩＦＹ受信処理を示すフローチャートである。
【図１０】本発明の第１の実施例によるサブスクライバの構成を示すブロック図である。
【図１１】本発明の第１の実施例によるサブスクライバの動作例を示すフローチャートである。
【図１２】本発明の第２の実施例による情報交換システムの構成を示すブロック図である。
【図１３】本発明の第３の実施例によるＳＵＢＳＣＲＩＢＥ受信処理（更新）を示すフローチャートである。
【図１４】従来例による情報交換システムの動作を示すシーケンスチャートである。
【符号の説明】
【００７６】
１ サブスクライバ
２，４ リソースリストサーバ
３ ノーティファイア
１１ ＣＰＵ
１２ メインメモリ
１２ａ 制御プログラム
１３ 記憶装置
１４ 通信制御部
２１ ＳＵＢＳＣＲＩＢＥ要求受信部
２２，４１ ＮＯＴＩＦＹ送信部
２３ リスト管理部
２４ サブスクリプション制御部
２５ ＳＵＢＳＣＲＩＢＥ要求送信部
２６ ＮＯＴＩＦＹ受信部
１１０ 内部バス
２４１ サブスクリプション管理部
２４２ リスト−サブスクライバ関連管理部
２４３ バックエンドサブスクリプション−リスト関連管理部
２４４ リソース状態管理部
４１１ ネットワーク負荷分散部
【技術分野】
【０００１】
本発明は情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラムに関し、特にサブスクライバとノーティファイアとの間のネットワーク負荷軽減に関する。
【背景技術】
【０００２】
リソースの状態を一定期間観察するサブスクライバと、リソースの状態をサブスクライバに通知するノーティファイアとの間のフレームワークとして、非特許文献１に示されるものがある。このフレームワークを応用した例としては、プレゼンスサービスに適用した例がある（例えば、非特許文献２参照）。ここで、プレゼンスサービスとは、各リソースの状態を管理するシステム一般を指し、その基本的なアーキテクチャは、非特許文献３に示されている。尚、リソースとはサブスクライバがその状態を観察する観察対象を示している。
【０００３】
上記のサブスクライバは、一つのリソースだけを観察しているわけではなく、複数のリソースの状態を観察している場合、一般には、それぞれのリソースに対し、個別にＳＵＢＳＣＲＩＢＥ（登録、購読）要求（リクエスト）をノーティファイアに送り、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ：契約、購読）を管理する必要がある。ここで、サブスクリプションはサブスクライバとノーティファイアとの関係や使用するイベントパッケージ等をまとめたものである。
【０００４】
しかしながら、（１）複数のリソースへのサブスクリプションの開始、更新が同時に行われると、ネットワークを流れる一時的なトラフィックが増大する、（２）サブスクライバが要求したサブスクリプションの更新間隔をノーティファイアが受け入れず、頻繁な更新を要求してきた場合、サブスクライバは頻繁なＳＵＢＳＣＲＩＢＥ要求を発行しなければならない、（３）ノーティファイアが、サブスクライバのＳＵＢＳＣＲＩＢＥ要求によって頻繁にリソースの状態通知を行う場合、不必要なＮＯＴＩＦＹ（通知）によってネットワークトラフィックが増大するという問題がある。
【０００５】
これらの問題を解決するため、図１４に示すように、複数のリソースへのＳＵＢＳＣＲＩＢＥ要求を受け付け、複数のリソースの状態を内容に含むひとつのＮＯＴＩＦＹを発行するリソースリストサーバが提案されている（例えば、非特許文献４，５参照）。しかしながら、この方法では、ＳＵＢＳＣＲＩＢＥ要求によるネットワーク負荷の軽減を図ることができるが、ＮＯＴＩＦＹによるネットワーク負荷及びサブスクライバの処理の負荷については、かえって増大してしまう可能性もある。
【０００６】
一方、状態通知をフィルタすることによって、ＮＯＴＩＦＹによるネットワーク負荷を軽減する方法についても提案されているが（例えば、非特許文献６，７参照）、リソースリストサーバからリソースへのバックエンドサブスクリプションの負荷を軽減するもので、リソースリストサーバからサブスクライバへ通知されるＮＯＴＩＦＹの内容を直接フィルタするものではない。
【０００７】
【非特許文献１】“Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）−Ｓｐｅｃｉｆｉｃ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ ３．Ｎｏｄｅ Ｂｅｈａｖｉｏｒ”［ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）３２６５，Ｊｕｎｅ ２００２］
【非特許文献２】“Ａ Ｐｒｅｓｅｎｃｅ Ｅｖｅｎｔ Ｐａｃｋａｇｅ ｆｏｒ ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ） Ｓｔａｔｕｓ ｏｆ ｔｈｉｓ Ｍｅｍｏ”（ＲＦＣ３８５６，Ａｕｇｕｓｔ ２００４）
【非特許文献３】“Ａ Ｍｏｄｅｌ ｆｏｒ Ｐｒｅｓｅｎｃｅ ａｎｄ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ”（ＲＦＣ２７７８，Ｆｅｂｒｕａｒｙ ２０００）
【非特許文献４】“Ａ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ） Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ Ｒｅｓｏｕｒｃｅ Ｌｉｓｔｓ ４．Ｏｐｅｒａｔｉｏｎ ｏｆ Ｌｉｓｔ Ｓｕｂｓｃｒｉｐｔｉｏｎｓ，５．Ｕｓｉｎｇ ｍｕｌｔｉｐａｒｔ／ｒｅｌａｔｅｄ ｔｏ Ｃｏｎｖｅｙ Ａｇｇｒｅｇａｔｅ Ｓｔａｔｅ”［ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ） Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｄｅｃｅｍｂｅｒ １５，２００４（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７．ｔｘｔ）］
【非特許文献５】“Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ） Ｆｏｒｍａｔｓ ｆｏｒ Ｒｅｐｒｅｓｅｎｔｉｎｇ Ｒｅｓｏｕｒｃｅ Ｌｉｓｔｓ”［ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｆｅｂｒｕａｒｙ ７，２００５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｘｃａｐ−ｌｉｓｔ−ｕｓａｇｅ−０５．ｔｘｔ）］
【非特許文献６】“Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ） Ｂａｓｅｄ Ｆｏｒｍａｔ ｆｏｒ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｆｉｌｔｅｒｉｎｇ”［ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｍａｒｃｈ １５，２００５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｆｉｌｔｅｒ−ｆｏｒｍａｔ−０５．ｔｘｔ）］
【非特許文献７】“”［ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｍａｒｃｈ １５，２００５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｆｉｌｔｅｒ−ｆｕｎｃｔ−０５．ｔｘｔ）］
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上述した従来のリソースリストサーバでは、上記の非特許文献４に記載の方法の場合、サブスクライバがサブスクリプションの更新を行うと、リソースのノーティファイアは、リソースの状態を内容に含むＮＯＴＩＦＹを送信する。これによって、サブスクライバはサブスクリプションの更新要求が受理されたことを知ることができる。しかしながら、サブスクライバがすでに知っているリソースの状態が再度送信されることになるため、ネットワーク上を無駄なデータが流れることになる。
【０００９】
また、あるサブスクライバから複数のリソースへのサブスクリプションの有効期間が同一の場合、サブスクリプションの更新が一度に行われ、無駄なデータが一度に流れることになるため、ネットワークの負荷がバースト的に増大する。この問題はサブスクライバにとってのノーティファイアが、リソースリストサーバである場合にも、同様である。
【００１０】
そこで、本発明の目的は上記の問題点を解消し、サブスクリプションの更新によってネットワーク上を無駄なデータが流れるのを防止することができる情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明による情報交換システムは、第１の端末装置と、第２の端末装置と、管理サーバとから構成され、
前記第１の端末装置は、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を前記管理サーバに通知する通知手段とを備え、
前記第２の端末装置は、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を前記管理サーバに送信する状態通知要求送信手段を備え、
前記管理サーバは、前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を備えている。
【００１２】
本発明による他の情報交換システムは、ノーティファイアと、サブスクライバと、管理サーバとから構成され、
前記ノーティファイアは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて前記管理サーバに通知する通知手段とを備え、
前記サブスクライバは、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を前記管理サーバに送信するＳＵＢＳＣＲＩＢＥ要求送信手段を備え、
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を備えている。
【００１３】
本発明による管理サーバは、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成し、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を備えている。
【００１４】
本発明による他の管理サーバは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成し、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を備えている。
【００１５】
本発明によるネットワーク負荷軽減方法は、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバが、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行している。
【００１６】
本発明による他のネットワーク負荷軽減方法は、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバが、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行している。
【００１７】
本発明によるネットワーク負荷軽減方法のプログラムは、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバのコンピュータに、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行させている。
【００１８】
本発明による他のネットワーク負荷軽減方法のプログラムは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバのコンピュータに、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行させている。
【００１９】
すなわち、本発明の情報交換システムは、リソースの状態を一定期間観察するサブスクライバと、リソースの状態をサブスクライバに通知するノーティファイアと、リソースのリストを管理するリソースリストサーバとを含むシステムにおいて、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ：契約、購読）の更新時に、リソースの状態を含むＮＯＴＩＦＹ（通知）を送る代わりに、内容が空のＮＯＴＩＦＹを送信している。ここで、サブスクリプションはサブスクライバとノーティファイアとの関係や使用するイベントパッケージ等をまとめたものである。
【００２０】
より具体的に説明すると、本発明の情報交換システムでは、ノーティファイアがすでに存在するサブスクリプションに対する更新要求を受けた場合、内容が空のＮＯＴＩＦＹをサブスクライバに送信している。リソースリストサーバが、リソース毎に個別のＮＯＴＩＦＹを送信する場合でも、リソースリストに対するサブスクリプションが更新された場合には、空のＮＯＴＩＦＹをただ一つ送信している。但し、リソースの状態に変更があった時点で送信されるＮＯＴＩＦＹが未達の場合には、空のＮＯＴＩＦＹではなく、そのリソース内容のＮＯＴＩＦＹを送信する。
【００２１】
これによって、本発明の情報交換システムでは、サブスクリプション更新時に送信されるＮＯＴＩＦＹの内容を空にすることで、ネットワークの負荷が軽減可能となり、サブスクリプション更新時に送信される空のＮＯＴＩＦＹを一つにまとめることで、ネットワークの負荷が軽減可能となる。
【発明の効果】
【００２２】
本発明は、以下に述べるような構成及び動作とすることで、サブスクリプションの更新によってネットワーク上を無駄なデータが流れるのを防止することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２３】
次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の実施の形態による情報交換システムの構成を示すブロック図である。図１において、本発明の実施の形態による情報交換システムはサブスクライバ１と、リソースリストサーバ２と、ノーティファイア３とから構成されている。サブスクライバ１はリソース（サブスクライバ１がその状態を観察する観察対象）の状態を一定期間観察し、ノーティファイア３はリソースの状態をサブスクライバ１に通知する。
【００２４】
リソースリストサーバ２はサブスクライバ１とノーティファイア３との間で状態の情報が交換されるリソースのリストを管理しており、ＳＵＢＳＣＲＩＢＥ（登録、購読）要求受信部２１と、ＮＯＴＩＦＹ（通知）送信部２２と、ＳＵＢＳＣＲＩＢＥ要求送信部２５と、ＮＯＴＩＦＹ受信部２６と、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ：契約、購読）制御部２４と、リスト管理部２３とから構成されている。尚、図１では、本実施例における動作説明に必要なものだけを図示している。
【００２５】
サブスクリプション制御部２４はサブスクリプション管理部２４１と、リスト−サブスクライバ関連管理部２４２と、バックエンドサブスクリプション−リスト関連管理部２４３と、リソース状態管理部２４４とから構成されている。
【００２６】
リスト管理部２３は各リソースリストに含まれるリソースの識別子を管理する。ＳＵＢＳＣＲＩＢＥ要求受信部２１及びＮＯＴＩＦＹ送信部２２はサブスクライバ１とのインタフェースを提供する。ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からリスト管理部２３で管理しているリソースリストに対するＳＵＢＳＣＲＩＢＥ要求あるいはＵＮＳＵＢＳＣＲＩＢＥ要求を受信すると、これをサブスクリプション管理部２４１に伝える。ＮＯＴＩＦＹ送信部２２はリソースの状態を、そのリソースが含まれるリストにサブスクライブしているサブスクライバ１に対してＮＯＴＩＦＹの内容として送信する。
【００２７】
ＳＵＢＳＣＲＩＢＥ要求送信部２５及びＮＯＴＩＦＹ受信部２６はリソースのノーティファイア３とのインタフェースを提供する。ＳＵＢＳＣＲＩＢＥ要求送信部２５はサブスクライバ１に代行し、リソースリストサーバ２からリソースに対するＳＵＢＳＣＲＩＢＥ要求及びＵＮＳＵＢＳＣＲＩＢＥ要求を送信する。ＮＯＴＩＦＹ受信部２６はリソースの状態を、ＮＯＴＩＦＹの内容としてリソースのノーティファイア３から受信する。
【００２８】
尚、リソースのノーティファイア３は各リソースに付随するものであっても、また、プレゼンスサーバのように、複数のリソースの状態をとりまとめるものであってもよい。ここで、プレゼンスサーバとは物理的なエンティティ（機能）であり、ＳＵＢＳＣＲＩＢＥ要求に対してプレゼンスエージェントあるいはプロキシサーバとして動作する。プレゼンスエージェントとして動作する場合には、プレゼンティティのプレゼンス情報［あらゆるものの存在やその状態（例えば、在席中や外出中等の状態）］を把握しており、プロキシサーバとして動作する場合にはプレゼンスエージェントとして動作する他のエンティティにＳＵＢＳＣＲＩＢＥ要求を転送する。
【００２９】
サブスクリプション制御部２４はサブスクライバ１からリストに対するＳＵＢＳＣＲＩＢＥ要求に基づき、バックエンドサブスクリプションを生成する。バックエンドサブスクリプションとは、リソースリストサーバ２からリソースに対するサブスクリプションである。ここで、サブスクリプションはサブスクライバ１とノーティファイア３との関係や使用するイベントパッケージ等をまとめたものである。
【００３０】
サブスクリプション管理部２４１はサブスクライバ１からリストに対するサブスクリプション及びバックエンドサブスクリプションを管理する。サブスクライバ１からＳＵＢＳＣＲＩＢＥ要求やＵＮＳＵＢＳＣＲＩＢＥ要求を受信した場合、サブスクリプション管理部２４１はサブスクリプションの生成・更新・終了を行う。
【００３１】
リスト−サブスクライバ関連管理部２４２は各リストに対するサブスクライバ群を保持する。リスト−サブスクライバ関連管理部２４２はリストに最初にサブスクライバ１が関連付けられると、バックエンドサブスクリプション−リスト関連管理部２４３にリストの追加を依頼し、また、リストに関連付けられたサブスクライバがなくなると、バックエンドサブスクリプション−リスト関連管理部２４３にリストの削除を依頼する。
【００３２】
バックエンドサブスクリプション−リスト関連管理部２４３はリソースリストサーバ２からリソースに対するサブスクリプションと、その契機となったリストとの関連を保持する。リソース状態管理部２４４はバックエンドサブスクリプションに対するＮＯＴＩＦＹによって取得したリソースの状態を保持する。
【００３３】
バックエンドサブスクリプションは、関連付けられた１つ以上のリストが存在する間、有効である。バックエンドサブスクリプションはそのバックエンドサブスクリプションに関連付けられたリストがなくなると消滅し、ＳＵＢＳＣＲＩＢＥ要求送信部２５からＵＮＳＵＢＳＣＲＩＢＥ要求が送られ、またリソース状態管理部２４４で管理されるリソース状態が無効になる。
【００３４】
尚、図１では、リソースリストサーバ２とノーティファイア３とを分けて図示しているが、ノーティファイア３がプレゼンスサーバの場合、これらは一つのサーバとして実装されてもよい。
【００３５】
本発明の実施の形態による情報交換システムでは、リソースリストサーバ２が、リストに対するＳＵＢＳＣＲＩＢＥ要求を受信すると、リストに含まれるリソースの各々に対してＳＵＢＳＣＲＩＢＥ要求を発行し、リソースのノーティファイア３からリソースの状態のＮＯＴＩＦＹを受信すると、そのリソースが含まれるリストに対するサブスクリプションを持つサブスクライバ１に対してＮＯＴＩＦＹを送信する。
【００３６】
これによって、本発明の実施の形態による情報交換システムでは、各リソースから個別に状態通知を受信したい場合に、複数のリソースへのＳＵＢＳＣＲＩＢＥ要求を一つにまとめることが可能となるため、サブスクリプション開始のためのＳＵＢＳＣＲＩＢＥ要求送信時及びサブスクリプション更新のためのＳＵＢＳＣＲＩＢＥ要求送信時のネットワークの負荷を軽減することができる。
【００３７】
また、本発明の実施の形態による情報交換システムでは、内容が大きなＮＯＴＩＦＹを一つ送る代わりに、内容が小さなＮＯＴＩＦＹを複数送ることで、ネットワークの負荷を軽減することができる。さらに、本発明の実施の形態による情報交換システムでは、一つのＮＯＴＩＦＹの内容を小さくすることによって、サブスクライバ１がＮＯＴＩＦＹの内容を解釈する処理の負荷を軽減することができる。さらにまた、本発明の実施の形態による情報交換システムでは、ＮＯＴＩＦＹの送信のタイミングを分散させることで、ネットワークの負荷を軽減することができる。
【実施例１】
【００３８】
図２は本発明の第１の実施例によるリスト管理部のリストテーブル例を示す図である。ここで、本発明の第１の実施例による情報交換システムの構成は図１に示す本発明の実施の形態による情報交換システムと同様の構成となっており、図２に示すリスト管理部はリソースリストサーバ２のリスト管理部２３の構成を表している。
【００３９】
図２において、リスト管理部２３にはリストＡ〜Ｎのリストテーブルが格納されており、リストＡ〜Ｎのリストテーブル各々にはリソース識別子が登録されている。例えば、リストＡのリストテーブルにはリソース識別子ａ〜ｃが登録されている。
【００４０】
図３は本発明の第１の実施例による情報交換システムの動作を示すシーケンスチャートであり、図４〜図６は本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートであり、図７及び図８は本発明の第１の実施例によるＵＮＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートであり、図９は本発明の第１の実施例によるＮＯＴＩＦＹ受信処理を示すフローチャートである。これら図１〜図９を参照して本発明の第１の実施例による情報交換システムの動作について説明する。尚、図１に示すリソースリストサーバ２の処理は図示せぬコンピュータがプログラムを実行することでも実現可能であり、図４〜図９に示す処理はこのコンピュータがプログラムを実行することで実現される。
【００４１】
ＳＵＢＳＣＲＩＢＥ受信処理を行う場合、ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からＳＵＢＳＣＲＩＢＥ要求を受信すると（図４ステップＳ１）、指定されたリストがリスト管理部２３で管理しているリストかどうかを調べ（図４ステップＳ２）、リスト管理部２３で管理していなければ、サブスクライバ１に対してエラー送信を行う（図４ステップＳ３）。また、ＳＵＢＳＣＲＩＢＥ要求受信部２１は管理しているリストであれば、ＳＵＢＳＣＲＩＢＥ要求をサブスクリプション管理部２４１に渡す。
【００４２】
サブスクリプション管理部２４１はそのリストに対するサブスクリプションがすでにあるかを調べ（図４ステップＳ４）、サブスクリプションがなければ、サブスクリプションを新規作成し（図４ステップＳ５）、サブスクライバ１に対して正常応答を返す（図４ステップＳ６）。サブスクリプション管理部２４１で新たにサブスクリプションが生成されると、サブスクリプション制御部２４はリスト管理部２３からＳＵＢＳＣＲＩＢＥ要求で指定されたリストに含まれるリソースの識別子を取得し（図４ステップＳ７）、取得したすべてのリソースに対して以下の処理を繰り返し行う。
【００４３】
バックエンドサブスクリプション−リスト関連管理部２４２はバックエンドサブスクリプションが存在しない場合（図５ステップＳ１０）、バックエンドサブスクリプションを作成し（図５ステップＳ１１）、ＳＵＢＳＣＲＩＢＥ要求送信部２５からリソースに対するＳＵＢＳＣＲＩＢＥ要求をノーティファイア３に送信する（図５ステップＳ１２）。
【００４４】
バックエンドサブスクリプション−リスト関連管理部２４２は注目するリソースに対するバックエンドサブスクリプションとリストとの関連が保持されていない場合（図５ステップＳ１３）、そのリソースに対するバックエンドサブスクリプションとリストとの関連を追加する（図５ステップＳ１４）。リスト−サブスクライバ関連管理部２４２はリストとサブスクライバとの関連が保持されていない場合（図５ステップＳ１５）、リストとサブスクライバとの関連を追加する（図５ステップＳ１６）。
【００４５】
サブスクリプション制御部２４はリスト管理部２３から取得したリソースの識別子を基にリソースの状態をリソース状態管理部２４４から取得し、これらの内容に含む個別のＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２からサブスクライバ１に対して送信する（図５ステップＳ１７）。リソースリストサーバ２は上記の処理を取得した全てのリソースに対する処理が終了するまで繰り返し行う（図５ステップＳ１０〜Ｓ１８）。
【００４６】
一方、サブスクリプション管理部２４１はサブスクリプションがすでにあれば、サブスクリプションを更新し（図４ステップＳ８）、サブスクライバ１に対して正常応答を返す（図４ステップＳ９）。サブスクリプション制御部２４はサブスクリプションが更新されると、リスト管理部２３からリストに含まれるリソースの識別子を取得し（図６ステップＳ１９）、これらに対する個別のＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２からサブスクライバ１に対して送信する（図６ステップＳ２０，Ｓ２１）。送信するＮＯＴＩＦＹは空のＮＯＴＩＦＹが送信される。但し、リソースの状態に変更があった時点で送信されるＮＯＴＩＦＹが未達の場合には（図６ステップＳ２０）、空のＮＯＴＩＦＹではなく、そのリソースの状態を内容として含むＮＯＴＩＦＹが送信される（図６ステップＳ２２）。
【００４７】
ＵＮＳＵＢＳＣＲＩＢＥ受信処理を行う場合、ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からＵＮＳＵＢＳＣＲＩＢＥ要求を受信すると（図７ステップＳ３１）、指定されたリストがリスト管理部２３で管理しているリストかどうかを調べ（図７ステップＳ３２）、管理しているリストでなければ、サブスクライバ１に対してエラー送信を行う（図７ステップＳ３３）。また、ＳＵＢＳＣＲＩＢＥ要求受信部２１は管理しているリストであれば、ＳＵＢＳＣＲＩＢＥ要求をサブスクリプション管理部２４１に渡す。
【００４８】
サブスクリプション管理部２４１はＵＮＳＵＢＳＣＲＩＢＥ要求を受信すると、そのリストに対するサブスクリプションがすでにある場合（図７ステップＳ３４）、サブスクリプションを終了し（図７ステップＳ３５）、サブスクライバ１に対して正常応答を返す（図７ステップＳ３６）。サブスクリプション管理部２４１はそのリストに対するサブスクリプションがない場合（図７ステップＳ３４）、サブスクライバ１に対してエラー送信を行う（図７ステップＳ３３）。
【００４９】
サブスクリプション制御部２４はサブスクリプションが終了されると、リスト管理部２３からリストに含まれるリソースの識別子を取得し（図７ステップＳ３７）、それぞれのリソースの状態をリソース状態管理部２４４から取得し（図７ステップＳ３８）、これらを内容に含む個別のＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２からサブスクライブ１に対して送信する（図７ステップＳ３９）。また、サブスクリプション制御部２４はリスト−サブスクライバ関連管理部２４２からリストに対するサブスクライバ１の関連付けを削除する（図７ステップＳ４０）。
【００５０】
サブスクリプション制御部２４はそのリストに関連付けられたサブスクライバが一つもなくなった場合（図７ステップＳ４１）、バックエンドサブスクリプション−リスト関連管理部２４３で管理される各リソースに対するバックエンドサブスクリプションについて以下の処理を行う。
【００５１】
サブスクリプション制御部２４はリソースに対するバックエンドサブスクリプションとリストとの関連を削除し（図８ステップＳ４２）、リソースのバックエンドサブスクリプションに関連付けられたリストが一つもなくなった場合（図８ステップＳ４３）、バックエンドサブスクリプションを終了する（図８ステップＳ４４）。その後に、サブスクリプション制御部２４はＳＵＢＳＣＲＩＢＥ要求送信部２５からリソースに対してＵＮＳＵＢＳＣＲＩＢＥ要求を送信する（図８ステップＳ４５）。
【００５２】
ＮＯＴＩＦＹ受信処理を行う場合、ＮＯＴＩＦＹ受信部２６はリソースのノーティファイア（例えば、プレゼンスサーバ）３からリソースの状態を内容に含むＮＯＴＩＦＹを受信すると（図９ステップＳ５１）、このＮＯＴＩＦＹをサブスクリプション管理部２４１に渡す。サブスクリプション管理部２４１は受信したリソースの状態をリソース状態管理部２４４に保持されたリソースの状態と比較し（図９ステップＳ５２）、その比較結果が異なる場合（図９ステップＳ５３）、以下の処理を繰り返し行う。
【００５３】
サブスクリプション管理部２４１はリソース状態管理部２４４で管理されるリソースの状態を受信したリソースの状態で更新する（図９ステップＳ５４）。サブスクリプション管理部２４１はバックエンドサブスクリプション−リスト関連管理部２４３からそのリソースのバックエンドサブスクリプションと関連付けられたリストを選択する（図９ステップＳ５５）。
【００５４】
サブスクリプション管理部２４１は選択した全てのリストについて、リスト−サブスクライバ関連管理部２４２で管理されるサブスクライバを決定し（図９ステップＳ５６）、選択されたサブスクライバ１に対し、リソースの状態を内容に含むＮＯＴＩＦＹをＮＯＴＩＦＹ送信部２２から送信する（図９ステップＳ５７）。
【００５５】
図１０は本発明の第１の実施例によるサブスクライバ１の構成を示すブロック図である。図１０において、サブスクライバ（端末装置）１はＣＰＵ（中央処理装置）１１と、ＣＰＵ１１が実行する制御プログラム１２ａを格納するメインメモリ１２と、ＣＰＵ１１が制御プログラム１２ａを実行する際に作業領域として使用する記憶装置１３と、リソースリストサーバ２との通信を制御する通信制御部１４とから構成されており、ＣＰＵ１１とメインメモリ１２と記憶装置１３と通信制御部１４とが内部バス１１０にて相互に接続されている。また、記憶装置１３はリソースリストサーバ２から取得したリソースリストを保持するリソースリスト保持部１３１を備えている。
【００５６】
図１１は本発明の第１の実施例によるサブスクライバ１の動作例を示すフローチャートである。これら図１０及び図１１を参照してサブスクライバ１の動作例について説明する。尚、図１１に示す処理はＣＰＵ１１が制御プログラム１２ａを実行することで実現される。
【００５７】
サブスクライバ１はリスト指定及びサポート通知を含むＳＵＢＳＣＲＩＢＥ要求をリソースリストサーバ２に送信し（図１１ステップＳ６１）、リソースリストサーバ２からサポート通知に対するリソースリストを受信すると（図１１ステップＳ６２）、そのリソースリストを記憶装置１３のリソースリスト保持部１３１に保持する（図１１ステップＳ６３）。
【００５８】
その後に、サブスクライバ１はリソースリストサーバ２からＳＵＢＳＣＲＩＢＥ要求に対するＮＯＴＩＦＹを受信すると（図１１ステップＳ６４）、そのＮＯＴＩＦＹをリソースリスト保持部１３１に保持するリソースリストと照合する（図１１ステップＳ６５）。
【００５９】
サブスクライバ１はその照合で受信対象のＮＯＴＩＦＹと判定すると（図１１ステップＳ６６）、そのＮＯＴＩＦＹの内容を解釈する（図１１ステップＳ６７）。また、サブスクライバ１はその照合で受信対象のＮＯＴＩＦＹと判定しなければ（図１１ステップＳ６６）、そのＮＯＴＩＦＹを廃棄する（図１１ステップＳ６８）。サブスクライバ１は上記のＳＵＢＳＣＲＩＢＥ要求にて指定したリストに含まれるリソースに対するＮＯＴＩＦＹ（受信対象）を全て受信するまで（図１１ステップＳ６９）、上記の処理を繰り返し行う。
【００６０】
このように、本実施例では、各リソースから個別に状態通知を受信したい場合、複数のリソースへのＳＵＢＳＣＲＩＢＥ要求を一つにまとめることができるため、サブスクリプション開始のためのＳＵＢＳＣＲＩＢＥ要求送信時及びサブスクリプション更新のためのＳＵＢＳＣＲＩＢＥ要求送信時のネットワークの負荷を軽減することができる。
【００６１】
また、本実施例では、内容が大きなＮＯＴＩＦＹを一つ送る代わりに、内容が小さなＮＯＴＩＦＹを複数送ることで、ネットワークの負荷を軽減することができる。さらに、本実施例では、一つのＮＯＴＩＦＹの内容を小さくすることによって、サブスクライバ１がＮＯＴＩＦＹの内容を解釈する処理の負荷を軽減することができる。尚、本実施例では、サブスクライバ１からのＳＵＢＳＣＲＩＢＥ要求をリソースリストサーバ２で処理してノーティファイア３に渡しているが、ノーティファイア３にリスト管理部を設けることで、サブスクライバ１からのＳＵＢＳＣＲＩＢＥ要求をそのままノーティファイア３に渡しても、上記と同様の効果を得ることができ、これに限定されない。
【実施例２】
【００６２】
図１２は本発明の第２の実施例による情報交換システムの構成を示すブロック図である。図１２において、本発明の第２の実施例による情報交換システムは、リソースリストサーバ４のＮＯＴＩＦＹ送信部４１にネットワーク負荷分散部４１１を設けた以外は図１に示す本発明の実施の形態による情報交換システムと同様の構成となっており、同一構成要素には同一符号を付してある。また、同一構成要素の動作は上述した本発明の実施の形態と同様である。
【００６３】
ネットワーク負荷分散部４１１はサブスクライバ１に対するＮＯＴＩＦＹの送信のタイミングを分散させることで、ネットワークの負荷を軽減することができる。また、本実施例では、サブスクライバ１の処理の負荷を軽減することができる。
【００６４】
ネットワーク負荷分散部４１１は、（１）同一のサブスクライバに対するＮＯＴＩＦＹの送信タイミングを分散させるもの、（２）複数のサブスクライバ間でＮＯＴＩＦＹの送信タイミングを分散させるもの（サブスクライバが選択されるが、同一サブスクライバに対するＮＯＴＩＦＹはそのまま送られる）、（３）サブスクライバの区別なく、ＮＯＴＩＦＹの送信タイミングを分散させるもの、等がある。
【００６５】
ネットワーク負荷分散部４１１の例としては、各ＮＯＴＩＦＹを送信する前に、「基準送信待ち時間×乱数」期間待つという方式がある。基準送信待ち時間は固定的な値でもよいし、ネットワーク負荷に応じて変動する値であってもよい。ネットワーク負荷に応じて変動する場合、負荷が高いほど、基準送信待ち時間は長くなる。
【００６６】
このように、本実施例では、リソースリストサーバ４のＮＯＴＩＦＹ送信部４１にネットワーク負荷分散部４１１を設け、ＮＯＴＩＦＹの送信のタイミングを分散させることで、ネットワークの負荷を軽減することができる。
【実施例３】
【００６７】
図１３は本発明の第３の実施例によるＳＵＢＳＣＲＩＢＥ受信処理（更新）を示すフローチャートである。本発明の第３の実施例による情報交換システムは図１に示す本発明の実施の形態による情報交換システムと同様の構成となっている。これら図１と図１３とを参照して本発明の第３の実施例による情報交換システムの動作について説明する。尚、図１３に示す処理は上記の本発明の第１の実施例と同様に、コンピュータがプログラムを実行することで実現される。また、本発明の第３の実施例による情報交換システムは図１２に示す本発明の第２の実施例による情報交換システムと同様の構成としてもよい。
【００６８】
本実施例は、本発明の第３の実施例に加え、サブスクリプション更新時にＮＯＴＩＦＹ送信部２２から送信される空のＮＯＴＩＦＹが、リソース毎ではなく、リストに対するものである点が異なる。
【００６９】
ＳＵＢＳＣＲＩＢＥ受信処理（更新）を行う場合、ＳＵＢＳＣＲＩＢＥ要求受信部２１はサブスクライバ１からＳＵＢＳＣＲＩＢＥ要求を受信すると（図１３ステップＳ７１）、指定されたリストがリスト管理部２３で管理しているリストかどうかを調べ（図１３ステップＳ７２）、リスト管理部２３で管理していなければ、サブスクライバ１に対してエラー送信を行う（図１３ステップＳ７３）。また、ＳＵＢＳＣＲＩＢＥ要求受信部２１は管理しているリストであれば、ＳＵＢＳＣＲＩＢＥ要求をサブスクリプション管理部２４１に渡す。
【００７０】
サブスクリプション管理部２４１はそのリストに対するサブスクリプションがすでにあるかを調べ（図１３ステップＳ７４）、サブスクリプションがなければ、サブスクリプションを新規作成し（図１３ステップＳ７５）、サブスクライバ１に対して正常応答を返す（図１３ステップＳ７６）。サブスクリプション管理部２４１で新たにサブスクリプションが生成されると、サブスクリプション制御部２４はリスト管理部２３からＳＵＢＳＣＲＩＢＥ要求で指定されたリストに含まれるリソースの識別子を取得し（図１３ステップＳ７７）、取得したすべてのリソースに対して上述した本発明の第１の実施例におけるステップＳ１０以下の処理を繰り返し行う。
【００７１】
サブスクリプション管理部２４１はＳＵＢＳＣＲＩＢＥ要求を受信すると、そのリストに対するサブスクリプションがすでにある場合（図１３ステップＳ７４）、サブスクリプションを更新し（図１３ステップＳ７８）、サブスクライバ１に対して正常応答を返す（図１３ステップＳ７９）。
【００７２】
サブスクリプション制御部２４はサブスクリプションが更新されると、内容が空のＮＯＴＩＦＹを一つ送信する（図１３ステップＳ８０，Ｓ８１）。但し、リソースの状態に変更があった時点で送信されるＮＯＴＩＦＹが未達の場合には（図１３ステップＳ８０）、空のＮＯＴＩＦＹではなく、そのリソースの状態を内容として含むＮＯＴＩＦＹが送信される（図１３ステップＳ８２）。
【００７３】
このように、本実施例では、サブスクリプション更新時にサブスクライバ１に対して送信される空のＮＯＴＩＦＹを一つにまとめることで、ネットワークの負荷を軽減することができる。
【産業上の利用可能性】
【００７４】
本発明は、インタネットに限らず、あらゆるものの存在やその状態（例えば、在席中や外出中等の状態）を通知するプレゼンスサービス、特にモバイル環境におけるプレゼンスサービスに適用可能である。
【図面の簡単な説明】
【００７５】
【図１】本発明の実施の形態による情報交換システムの構成を示すブロック図である。
【図２】本発明の第１の実施例によるリスト管理部のリストテーブル例を示す図である。
【図３】本発明の第１の実施例による情報交換システムの動作を示すシーケンスチャートである。
【図４】本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図５】本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図６】本発明の第１の実施例によるＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図７】本発明の第１の実施例によるＵＮＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図８】本発明の第１の実施例によるＵＮＳＵＢＳＣＲＩＢＥ受信処理を示すフローチャートである。
【図９】本発明の第１の実施例によるＮＯＴＩＦＹ受信処理を示すフローチャートである。
【図１０】本発明の第１の実施例によるサブスクライバの構成を示すブロック図である。
【図１１】本発明の第１の実施例によるサブスクライバの動作例を示すフローチャートである。
【図１２】本発明の第２の実施例による情報交換システムの構成を示すブロック図である。
【図１３】本発明の第３の実施例によるＳＵＢＳＣＲＩＢＥ受信処理（更新）を示すフローチャートである。
【図１４】従来例による情報交換システムの動作を示すシーケンスチャートである。
【符号の説明】
【００７６】
１ サブスクライバ
２，４ リソースリストサーバ
３ ノーティファイア
１１ ＣＰＵ
１２ メインメモリ
１２ａ 制御プログラム
１３ 記憶装置
１４ 通信制御部
２１ ＳＵＢＳＣＲＩＢＥ要求受信部
２２，４１ ＮＯＴＩＦＹ送信部
２３ リスト管理部
２４ サブスクリプション制御部
２５ ＳＵＢＳＣＲＩＢＥ要求送信部
２６ ＮＯＴＩＦＹ受信部
１１０ 内部バス
２４１ サブスクリプション管理部
２４２ リスト−サブスクライバ関連管理部
２４３ バックエンドサブスクリプション−リスト関連管理部
２４４ リソース状態管理部
４１１ ネットワーク負荷分散部
【特許請求の範囲】
【請求項１】
第１の端末装置と、第２の端末装置と、管理サーバとから構成され、
前記第１の端末装置は、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を前記管理サーバに通知する通知手段とを有し、
前記第２の端末装置は、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を前記管理サーバに送信する状態通知要求送信手段を有し、
前記管理サーバは、前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を有することを特徴とする情報交換システム。
【請求項２】
前記管理サーバは、前記状態通知要求の更新時に前記内容が空の通知信号を一つにまとめて送信することを特徴とする請求項１記載の情報交換システム。
【請求項３】
前記管理サーバは、前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする通知信号を前記監視対象毎に前記第２の端末装置に対して個別に送信する手段とを含むことを特徴とする請求項１または請求項２記載の情報交換システム。
【請求項４】
前記管理サーバは、前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する手段とを含むことを特徴とする請求項１または請求項２記載の情報交換システム。
【請求項５】
前記管理サーバは、前記第２の端末装置に対する前記通知信号の送信タイミングを分散させる手段を含むことを特徴とする請求項１から請求項４のいずれか記載の情報交換システム。
【請求項６】
前記第２の端末装置は、前記状態通知要求をキャンセルするまでの間、前記監視対象の状態を監視することを特徴とする請求項１から請求項５のいずれか記載の情報交換システム。
【請求項７】
前記第２の端末装置は、前記状態通知要求にて指定した一定期間、前記監視対象の状態を監視することを特徴とする請求項１から請求項６のいずれか記載の情報交換システム。
【請求項８】
前記第２の端末装置は、前記管理サーバから前記監視対象群の情報を取得する手段と、前記監視対象群の情報を解釈する手段とを含むことを特徴とする請求項１から請求項７のいずれか記載の情報交換システム。
【請求項９】
前記第２の端末装置は、前記管理サーバから前記監視対象群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項８記載の情報交換システム。
【請求項１０】
前記状態通知要求に含まれる指定情報は、前記管理サーバで管理する前記監視対象のサブセットの識別情報であることを特徴とする請求項１から請求項９のいずれか記載の情報交換システム。
【請求項１１】
前記状態通知要求に含まれる指定情報は、前記監視対象の１以上のリストであることを特徴とする請求項１から請求項９のいずれか記載の情報交換システム。
【請求項１２】
ノーティファイアと、サブスクライバと、管理サーバとから構成され、
前記ノーティファイアは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて前記管理サーバに通知する通知手段とを有し、
前記サブスクライバは、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を前記管理サーバに送信するＳＵＢＳＣＲＩＢＥ要求送信手段を有し、
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を有することを特徴とする情報交換システム。
【請求項１３】
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に前記内容が空のＮＯＴＩＦＹを一つにまとめて送信することを特徴とする請求項１２記載の情報交換システム。
【請求項１４】
前記管理サーバは、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とするＮＯＴＩＦＹを前記リソース毎に前記サブスクライバに対して個別に送信する手段とを含むことを特徴とする請求項１２または請求項１３記載の情報交換システム。
【請求項１５】
前記管理サーバは、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とする複数のＮＯＴＩＦＹを前記サブスクライバに対して送信する手段とを含むことを特徴とする請求項１２または請求項１３記載の情報交換システム。
【請求項１６】
前記管理サーバは、前記サブスクライバに対する前記ＮＯＴＩＦＹの送信タイミングを分散させる手段を含むことを特徴とする請求項１２から請求項１５のいずれか記載の情報交換システム。
【請求項１７】
前記サブスクライバは、前記ＳＵＢＳＣＲＩＢＥ要求をキャンセルするまでの間、前記リソースの状態を監視することを特徴とする請求項１２から請求項１６のいずれか記載の情報交換システム。
【請求項１８】
前記サブスクライバは、前記ＳＵＢＳＣＲＩＢＥ要求にて指定した一定期間、前記リソースの状態を監視することを特徴とする請求項１２から請求項１７のいずれか記載の情報交換システム。
【請求項１９】
前記サブスクライバは、前記管理サーバから前記リソース群の情報を取得する手段と、前記リソース群の情報を解釈する手段とを含むことを特徴とする請求項１２から請求項１８のいずれか記載の情報交換システム。
【請求項２０】
前記サブスクライバは、前記管理サーバから前記リソース群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項１９記載の情報交換システム。
【請求項２１】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記管理サーバで管理する前記リソースのサブセットの識別情報であることを特徴とする請求項１２から請求項２０のいずれか記載の情報交換システム。
【請求項２２】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記リソースの１以上のリストであることを特徴とする請求項１２から請求項２０のいずれか記載の情報交換システム。
【請求項２３】
１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成し、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を有することを特徴とする管理サーバ。
【請求項２４】
前記状態通知要求の更新時に前記内容が空の通知信号を一つにまとめて送信することを特徴とする請求項２３記載の管理サーバ。
【請求項２５】
前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する手段とを含むことを特徴とする請求項２３または請求項２４記載の管理サーバ。
【請求項２６】
前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する手段とを含むことを特徴とする請求項２３または請求項２４記載の管理サーバ。
【請求項２７】
前記第２の端末装置に対する前記通知信号の送信タイミングを分散させる手段を含むことを特徴とする請求項２３から請求項２６のいずれか記載の管理サーバ。
【請求項２８】
前記状態通知要求に含まれる指定情報は、自装置で管理する前記監視対象のサブセットの識別情報であることを特徴とする請求項２３から請求項２７のいずれか記載の管理サーバ。
【請求項２９】
前記状態通知要求に含まれる指定情報は、前記監視対象の１以上のリストであることを特徴とする請求項２３から請求項２７のいずれか記載の管理サーバ。
【請求項３０】
１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成し、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を有することを特徴とする管理サーバ。
【請求項３１】
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に前記内容が空のＮＯＴＩＦＹを一つにまとめて送信することを特徴とする請求項３０記載の管理サーバ。
【請求項３２】
前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とするＮＯＴＩＦＹを前記リソース毎に前記サブスクライバに対して個別に送信する手段とを含むことを特徴とする請求項３０または請求項３１記載の管理サーバ。
【請求項３３】
前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とする複数のＮＯＴＩＦＹを前記サブスクライバに対して送信する手段とを含むことを特徴とする請求項３０または請求項３１記載の管理サーバ。
【請求項３４】
前記サブスクライバに対する前記ＮＯＴＩＦＹの送信タイミングを分散させる手段を含むことを特徴とする請求項３０から請求項３３のいずれか記載の管理サーバ。
【請求項３５】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記管理サーバで管理する前記リソースのサブセットの識別情報であることを特徴とする請求項３０から請求項３４のいずれか記載の管理サーバ。
【請求項３６】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記リソースの１以上のリストであることを特徴とする請求項３０から請求項３４のいずれか記載の管理サーバ。
【請求項３７】
１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバが、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行することを特徴とするネットワーク負荷軽減方法。
【請求項３８】
前記管理サーバは、前記状態通知要求の更新時に前記内容が空の通知信号を一つにまとめて送信することを特徴とする請求項３７記載のネットワーク負荷軽減方法。
【請求項３９】
前記管理サーバが、前記第１の端末装置から通知された前記監視対象の状態を受信して監視対象状態保持手段に保持する処理と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする通知信号を前記監視対象毎に前記第２の端末装置に対して個別に送信する処理とを実行することを特徴とする請求項３７または請求項３８記載のネットワーク負荷軽減方法。
【請求項４０】
前記管理サーバが、前記第１の端末装置から通知された前記監視対象の状態を受信して監視対象状態保持手段に保持する処理と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する処理とを実行することを特徴とする請求項３７または請求項３８記載のネットワーク負荷軽減方法。
【請求項４１】
前記管理サーバが、前記第２の端末装置に対する前記通知信号の送信タイミングを分散させる処理を実行することを特徴とする請求項３７から請求項４０のいずれか記載のネットワーク負荷軽減方法。
【請求項４２】
前記第２の端末装置が、前記状態通知要求をキャンセルするまでの間、前記監視対象の状態を監視することを特徴とする請求項３７から請求項４１のいずれか記載のネットワーク負荷軽減方法。
【請求項４３】
前記第２の端末装置が、前記状態通知要求にて指定した一定期間、前記監視対象の状態を監視することを特徴とする請求項３７から請求項４２のいずれか記載のネットワーク負荷軽減方法。
【請求項４４】
前記第２の端末装置が、前記管理サーバから前記監視対象群の情報を取得する処理と、前記監視対象群の情報を解釈する処理とを実行することを特徴とする請求項３７から請求項４３のいずれか記載のネットワーク負荷軽減方法。
【請求項４５】
前記第２の端末装置が、前記管理サーバから前記監視対象群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項４４記載のネットワーク負荷軽減方法。
【請求項４６】
前記状態通知要求に含まれる指定情報が、前記管理サーバで管理する前記監視対象のサブセットの識別情報であることを特徴とする請求項３７から請求項４５のいずれか記載のネットワーク負荷軽減方法。
【請求項４７】
前記状態通知要求に含まれる指定情報が、前記監視対象の１以上のリストであることを特徴とする請求項３７から請求項４５のいずれか記載のネットワーク負荷軽減方法。
【請求項４８】
１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバが、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行することを特徴とするネットワーク負荷軽減方法。
【請求項４９】
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に前記内容が空のＮＯＴＩＦＹを一つにまとめて送信することを特徴とする請求項４８記載のネットワーク負荷軽減方法。
【請求項５０】
前記管理サーバが、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信してリソース状態保持手段に保持する処理と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とするＮＯＴＩＦＹを前記リソース毎に前記サブスクライバに対して個別に送信する処理とを実行することを特徴とする請求項４８または請求項４９記載のネットワーク負荷軽減方法。
【請求項５１】
前記管理サーバが、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信してリソース状態保持手段に保持する処理と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とする複数のＮＯＴＩＦＹを前記サブスクライバに対して送信する処理とを実行することを特徴とする請求項４８または請求項４９記載のネットワーク負荷軽減方法。
【請求項５２】
前記管理サーバが、前記サブスクライバに対する前記ＮＯＴＩＦＹの送信タイミングを分散させる処理を実行することを特徴とする請求項４８から請求項５１のいずれか記載のネットワーク負荷軽減方法。
【請求項５３】
前記サブスクライバが、前記ＳＵＢＳＣＲＩＢＥ要求をキャンセルするまでの間、前記リソースの状態を監視することを特徴とする請求項４８から請求項５２のいずれか記載のネットワーク負荷軽減方法。
【請求項５４】
前記サブスクライバが、前記ＳＵＢＳＣＲＩＢＥ要求にて指定した一定期間、前記リソースの状態を監視することを特徴とする請求項４８から請求項５３のいずれか記載のネットワーク負荷軽減方法。
【請求項５５】
前記サブスクライバが、前記管理サーバから前記リソース群の情報を取得する処理と、前記リソース群の情報を解釈する処理とを実行することを特徴とする請求項４８から請求項５４のいずれか記載のネットワーク負荷軽減方法。
【請求項５６】
前記サブスクライバが、前記管理サーバから前記リソース群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項５５記載のネットワーク負荷軽減方法。
【請求項５７】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報が、前記管理サーバで管理する前記リソースのサブセットの識別情報であることを特徴とする請求項４８から請求項５６のいずれか記載のネットワーク負荷軽減方法。
【請求項５８】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報が、前記リソースの１以上のリストであることを特徴とする請求項４８から請求項５６のいずれか記載のネットワーク負荷軽減方法。
【請求項５９】
１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバのコンピュータに、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行させるためのプログラム。
【請求項６０】
１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバのコンピュータに、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行させるためのプログラム。
【請求項１】
第１の端末装置と、第２の端末装置と、管理サーバとから構成され、
前記第１の端末装置は、１以上の監視対象の状態を監視する手段と、前記監視対象の状態を前記管理サーバに通知する通知手段とを有し、
前記第２の端末装置は、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を前記管理サーバに送信する状態通知要求送信手段を有し、
前記管理サーバは、前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を有することを特徴とする情報交換システム。
【請求項２】
前記管理サーバは、前記状態通知要求の更新時に前記内容が空の通知信号を一つにまとめて送信することを特徴とする請求項１記載の情報交換システム。
【請求項３】
前記管理サーバは、前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする通知信号を前記監視対象毎に前記第２の端末装置に対して個別に送信する手段とを含むことを特徴とする請求項１または請求項２記載の情報交換システム。
【請求項４】
前記管理サーバは、前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する手段とを含むことを特徴とする請求項１または請求項２記載の情報交換システム。
【請求項５】
前記管理サーバは、前記第２の端末装置に対する前記通知信号の送信タイミングを分散させる手段を含むことを特徴とする請求項１から請求項４のいずれか記載の情報交換システム。
【請求項６】
前記第２の端末装置は、前記状態通知要求をキャンセルするまでの間、前記監視対象の状態を監視することを特徴とする請求項１から請求項５のいずれか記載の情報交換システム。
【請求項７】
前記第２の端末装置は、前記状態通知要求にて指定した一定期間、前記監視対象の状態を監視することを特徴とする請求項１から請求項６のいずれか記載の情報交換システム。
【請求項８】
前記第２の端末装置は、前記管理サーバから前記監視対象群の情報を取得する手段と、前記監視対象群の情報を解釈する手段とを含むことを特徴とする請求項１から請求項７のいずれか記載の情報交換システム。
【請求項９】
前記第２の端末装置は、前記管理サーバから前記監視対象群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項８記載の情報交換システム。
【請求項１０】
前記状態通知要求に含まれる指定情報は、前記管理サーバで管理する前記監視対象のサブセットの識別情報であることを特徴とする請求項１から請求項９のいずれか記載の情報交換システム。
【請求項１１】
前記状態通知要求に含まれる指定情報は、前記監視対象の１以上のリストであることを特徴とする請求項１から請求項９のいずれか記載の情報交換システム。
【請求項１２】
ノーティファイアと、サブスクライバと、管理サーバとから構成され、
前記ノーティファイアは、１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて前記管理サーバに通知する通知手段とを有し、
前記サブスクライバは、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を前記管理サーバに送信するＳＵＢＳＣＲＩＢＥ要求送信手段を有し、
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を有することを特徴とする情報交換システム。
【請求項１３】
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に前記内容が空のＮＯＴＩＦＹを一つにまとめて送信することを特徴とする請求項１２記載の情報交換システム。
【請求項１４】
前記管理サーバは、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とするＮＯＴＩＦＹを前記リソース毎に前記サブスクライバに対して個別に送信する手段とを含むことを特徴とする請求項１２または請求項１３記載の情報交換システム。
【請求項１５】
前記管理サーバは、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とする複数のＮＯＴＩＦＹを前記サブスクライバに対して送信する手段とを含むことを特徴とする請求項１２または請求項１３記載の情報交換システム。
【請求項１６】
前記管理サーバは、前記サブスクライバに対する前記ＮＯＴＩＦＹの送信タイミングを分散させる手段を含むことを特徴とする請求項１２から請求項１５のいずれか記載の情報交換システム。
【請求項１７】
前記サブスクライバは、前記ＳＵＢＳＣＲＩＢＥ要求をキャンセルするまでの間、前記リソースの状態を監視することを特徴とする請求項１２から請求項１６のいずれか記載の情報交換システム。
【請求項１８】
前記サブスクライバは、前記ＳＵＢＳＣＲＩＢＥ要求にて指定した一定期間、前記リソースの状態を監視することを特徴とする請求項１２から請求項１７のいずれか記載の情報交換システム。
【請求項１９】
前記サブスクライバは、前記管理サーバから前記リソース群の情報を取得する手段と、前記リソース群の情報を解釈する手段とを含むことを特徴とする請求項１２から請求項１８のいずれか記載の情報交換システム。
【請求項２０】
前記サブスクライバは、前記管理サーバから前記リソース群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項１９記載の情報交換システム。
【請求項２１】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記管理サーバで管理する前記リソースのサブセットの識別情報であることを特徴とする請求項１２から請求項２０のいずれか記載の情報交換システム。
【請求項２２】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記リソースの１以上のリストであることを特徴とする請求項１２から請求項２０のいずれか記載の情報交換システム。
【請求項２３】
１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成し、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する手段を有することを特徴とする管理サーバ。
【請求項２４】
前記状態通知要求の更新時に前記内容が空の通知信号を一つにまとめて送信することを特徴とする請求項２３記載の管理サーバ。
【請求項２５】
前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する手段とを含むことを特徴とする請求項２３または請求項２４記載の管理サーバ。
【請求項２６】
前記第１の端末装置から通知された前記監視対象の状態を受信して保持する監視対象状態保持手段と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する手段とを含むことを特徴とする請求項２３または請求項２４記載の管理サーバ。
【請求項２７】
前記第２の端末装置に対する前記通知信号の送信タイミングを分散させる手段を含むことを特徴とする請求項２３から請求項２６のいずれか記載の管理サーバ。
【請求項２８】
前記状態通知要求に含まれる指定情報は、自装置で管理する前記監視対象のサブセットの識別情報であることを特徴とする請求項２３から請求項２７のいずれか記載の管理サーバ。
【請求項２９】
前記状態通知要求に含まれる指定情報は、前記監視対象の１以上のリストであることを特徴とする請求項２３から請求項２７のいずれか記載の管理サーバ。
【請求項３０】
１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成し、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する手段を有することを特徴とする管理サーバ。
【請求項３１】
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に前記内容が空のＮＯＴＩＦＹを一つにまとめて送信することを特徴とする請求項３０記載の管理サーバ。
【請求項３２】
前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とするＮＯＴＩＦＹを前記リソース毎に前記サブスクライバに対して個別に送信する手段とを含むことを特徴とする請求項３０または請求項３１記載の管理サーバ。
【請求項３３】
前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信して保持するリソース状態保持手段と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とする複数のＮＯＴＩＦＹを前記サブスクライバに対して送信する手段とを含むことを特徴とする請求項３０または請求項３１記載の管理サーバ。
【請求項３４】
前記サブスクライバに対する前記ＮＯＴＩＦＹの送信タイミングを分散させる手段を含むことを特徴とする請求項３０から請求項３３のいずれか記載の管理サーバ。
【請求項３５】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記管理サーバで管理する前記リソースのサブセットの識別情報であることを特徴とする請求項３０から請求項３４のいずれか記載の管理サーバ。
【請求項３６】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報は、前記リソースの１以上のリストであることを特徴とする請求項３０から請求項３４のいずれか記載の管理サーバ。
【請求項３７】
１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバが、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行することを特徴とするネットワーク負荷軽減方法。
【請求項３８】
前記管理サーバは、前記状態通知要求の更新時に前記内容が空の通知信号を一つにまとめて送信することを特徴とする請求項３７記載のネットワーク負荷軽減方法。
【請求項３９】
前記管理サーバが、前記第１の端末装置から通知された前記監視対象の状態を受信して監視対象状態保持手段に保持する処理と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする通知信号を前記監視対象毎に前記第２の端末装置に対して個別に送信する処理とを実行することを特徴とする請求項３７または請求項３８記載のネットワーク負荷軽減方法。
【請求項４０】
前記管理サーバが、前記第１の端末装置から通知された前記監視対象の状態を受信して監視対象状態保持手段に保持する処理と、前記第２の端末装置から受信した状態通知要求に含まれる指定情報にて指定される監視対象群に含まれる監視対象の状態を内容とする複数の通知信号を前記第２の端末装置に送信する処理とを実行することを特徴とする請求項３７または請求項３８記載のネットワーク負荷軽減方法。
【請求項４１】
前記管理サーバが、前記第２の端末装置に対する前記通知信号の送信タイミングを分散させる処理を実行することを特徴とする請求項３７から請求項４０のいずれか記載のネットワーク負荷軽減方法。
【請求項４２】
前記第２の端末装置が、前記状態通知要求をキャンセルするまでの間、前記監視対象の状態を監視することを特徴とする請求項３７から請求項４１のいずれか記載のネットワーク負荷軽減方法。
【請求項４３】
前記第２の端末装置が、前記状態通知要求にて指定した一定期間、前記監視対象の状態を監視することを特徴とする請求項３７から請求項４２のいずれか記載のネットワーク負荷軽減方法。
【請求項４４】
前記第２の端末装置が、前記管理サーバから前記監視対象群の情報を取得する処理と、前記監視対象群の情報を解釈する処理とを実行することを特徴とする請求項３７から請求項４３のいずれか記載のネットワーク負荷軽減方法。
【請求項４５】
前記第２の端末装置が、前記管理サーバから前記監視対象群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項４４記載のネットワーク負荷軽減方法。
【請求項４６】
前記状態通知要求に含まれる指定情報が、前記管理サーバで管理する前記監視対象のサブセットの識別情報であることを特徴とする請求項３７から請求項４５のいずれか記載のネットワーク負荷軽減方法。
【請求項４７】
前記状態通知要求に含まれる指定情報が、前記監視対象の１以上のリストであることを特徴とする請求項３７から請求項４５のいずれか記載のネットワーク負荷軽減方法。
【請求項４８】
１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバが、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行することを特徴とするネットワーク負荷軽減方法。
【請求項４９】
前記管理サーバは、前記ＳＵＢＳＣＲＩＢＥ要求の更新時に前記内容が空のＮＯＴＩＦＹを一つにまとめて送信することを特徴とする請求項４８記載のネットワーク負荷軽減方法。
【請求項５０】
前記管理サーバが、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信してリソース状態保持手段に保持する処理と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とするＮＯＴＩＦＹを前記リソース毎に前記サブスクライバに対して個別に送信する処理とを実行することを特徴とする請求項４８または請求項４９記載のネットワーク負荷軽減方法。
【請求項５１】
前記管理サーバが、前記ノーティファイアから前記ＮＯＴＩＦＹにて通知された前記リソースの状態を受信してリソース状態保持手段に保持する処理と、前記サブスクライバから受信したＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報にて指定されるリソース群に含まれるリソースの状態を内容とする複数のＮＯＴＩＦＹを前記サブスクライバに対して送信する処理とを実行することを特徴とする請求項４８または請求項４９記載のネットワーク負荷軽減方法。
【請求項５２】
前記管理サーバが、前記サブスクライバに対する前記ＮＯＴＩＦＹの送信タイミングを分散させる処理を実行することを特徴とする請求項４８から請求項５１のいずれか記載のネットワーク負荷軽減方法。
【請求項５３】
前記サブスクライバが、前記ＳＵＢＳＣＲＩＢＥ要求をキャンセルするまでの間、前記リソースの状態を監視することを特徴とする請求項４８から請求項５２のいずれか記載のネットワーク負荷軽減方法。
【請求項５４】
前記サブスクライバが、前記ＳＵＢＳＣＲＩＢＥ要求にて指定した一定期間、前記リソースの状態を監視することを特徴とする請求項４８から請求項５３のいずれか記載のネットワーク負荷軽減方法。
【請求項５５】
前記サブスクライバが、前記管理サーバから前記リソース群の情報を取得する処理と、前記リソース群の情報を解釈する処理とを実行することを特徴とする請求項４８から請求項５４のいずれか記載のネットワーク負荷軽減方法。
【請求項５６】
前記サブスクライバが、前記管理サーバから前記リソース群の情報を取得するために前記管理サーバに対してサポートの通知を行うことを特徴とする請求項５５記載のネットワーク負荷軽減方法。
【請求項５７】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報が、前記管理サーバで管理する前記リソースのサブセットの識別情報であることを特徴とする請求項４８から請求項５６のいずれか記載のネットワーク負荷軽減方法。
【請求項５８】
前記ＳＵＢＳＣＲＩＢＥ要求に含まれる指定情報が、前記リソースの１以上のリストであることを特徴とする請求項４８から請求項５６のいずれか記載のネットワーク負荷軽減方法。
【請求項５９】
１以上の監視対象の状態を監視する手段と、前記監視対象の状態を自装置に通知する通知手段とを含む第１の端末装置と、１以上の前記監視対象を含む監視対象群を指定する指定情報を含む状態通知要求を自装置に送信する状態通知要求送信手段を含む第２の端末装置とともに情報交換システムを構成する管理サーバのコンピュータに、
前記状態通知要求の更新時に内容が空の通知信号を前記第２の端末装置に送信する処理を実行させるためのプログラム。
【請求項６０】
１以上のリソースの状態を監視する手段と、前記リソースの状態をＮＯＴＩＦＹにて自装置に通知する通知手段とを含むノーティファイアと、１以上の前記リソースを含むリソース群を指定する指定情報を含むＳＵＢＳＣＲＩＢＥ要求を自装置に送信するＳＵＢＳＣＲＩＢＥ要求送信手段を含むサブスクライバとともに情報交換システムを構成する管理サーバのコンピュータに、
前記ＳＵＢＳＣＲＩＢＥ要求の更新時に内容が空のＮＯＴＩＦＹを前記サブスクライバに送信する処理を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００７−２６００６（Ｐ２００７−２６００６Ａ）
【公開日】平成１９年２月１日（２００７．２．１）
【国際特許分類】
【出願番号】特願２００５−２０６２７５（Ｐ２００５−２０６２７５）
【出願日】平成１７年７月１５日（２００５．７．１５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【出願人】（０００２３２２５４）日本電気通信システム株式会社 (586)
【Ｆターム（参考）】
【公開日】平成１９年２月１日（２００７．２．１）
【国際特許分類】
【出願日】平成１７年７月１５日（２００５．７．１５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【出願人】（０００２３２２５４）日本電気通信システム株式会社 (586)
【Ｆターム（参考）】
[ Back to top ]