リソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびプログラム
【課題】管理対象のネットワーク装置のリソース不足が発生した際に自動的に最適なリソースの再配置を短時間で実施する仕組みを提供する。
【解決手段】ネットワークを構成するネットワーク装置である装置Ａ１ ２０１１，…，装置Ａｎ ２０ｎ１のリソース状態を管理するリソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ２１０１に、管理対象の各装置のリソース管理Ａｇｅｎｔ２０１１，…，２０ｎ１が、リソース不足が発生した際にリソース管理サーバ２１００側で実施して欲しい希望アクションをプロファイルとして各装置のリソース状態とともに事前に登録しておき、リソース管理Ｍａｎａｇｅｒ２１０１は、或る装置のリソース管理Ａｇｅｎｔからリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行う。
【解決手段】ネットワークを構成するネットワーク装置である装置Ａ１ ２０１１，…，装置Ａｎ ２０ｎ１のリソース状態を管理するリソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ２１０１に、管理対象の各装置のリソース管理Ａｇｅｎｔ２０１１，…，２０ｎ１が、リソース不足が発生した際にリソース管理サーバ２１００側で実施して欲しい希望アクションをプロファイルとして各装置のリソース状態とともに事前に登録しておき、リソース管理Ｍａｎａｇｅｒ２１０１は、或る装置のリソース管理Ａｇｅｎｔからリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムに関する。
【背景技術】
【０００２】
インターネット等のネットワークは、呼処理装置、無線制御装置、ルータ、ハブ等のネットワーク装置を相互に接続して構成されている。ネットワークにおいては、所定の品質のサービスを実現するために、例えば、特許文献１の特開２００４−１４０８１４号公報「リソース管理システム」等に記載されているように、ネットワークの帯域や通信速度や通信経路等のネットワークリソース（以下、単に「リソース」と略称する）を確保し管理するリソース管理サーバが設置されている。
【０００３】
このようなネットワークのリソースを管理するリソース管理システムにおける現状のリソース不足検知機能について、図１５を参照して説明する。図１５は、ネットワークのリソースを管理するリソース管理システムにおける動作の一例を説明するための説明図である。
【０００４】
図１５において、ネットワーク全体のリソースを管理しているリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１５１０１は、リソースの管理対象のネットワーク装置である装置Ａ１ １５０１０，…，装置Ａｎ １５０ｎ０それぞれに対して、リソース不足の発生の有無を判別するためのアラーム閾値をあらかじめ設定している。そして、装置Ａ１ １５０１０，…，装置Ａｎ １５０ｎ０それぞれにおいて、使用するリソースがアラーム閾値を超えようとしていることを検知した際に、リソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ１５１０１に対してリソース不足が発生している旨をＳＮＭＰ(Simple Network Management Protocol)のＴｒａｐメッセージ（トラップメッセージ）を用いてアラーム通報する。
【０００５】
ここで、例えば、管理対象の各ネットワーク装置のうち、装置Ａ１ １５０１０がリソース不足になったものと仮定する。また、検知対象のリソースの例として、システム動作状況のロギングを収集する手段であるＳＹＳＬＯＧ（シスログ）動作に関するリソースを取り上げる。
【０００６】
装置Ａ１ １５０１０は、システム動作状況を監視しており、ＳＹＳＬＯＧ機能を用いて、ログファイルとして管理者に通報している。装置Ａ１ １５０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント：本実施例においてはＳＹＳＬＯＧ Ａｇｅｎｔ）１５０１１は、ＳＹＳＬＯＧ用のリソース不足を検知すると、アラーム通報用してあらかじめ設定されたＴｒａｐメッセージ（トラップメッセージ）を、インタフェースＲ１１経由で、管理ネットワークを介してリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ：本実施例においてはＳＹＳＬＯＧ Ｍａｎａｇｅｒ）１５１０１に送信することによって、リソースの管理を行っているリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ１５１０１に対してリソース不足の発生を通知する。
【０００７】
装置Ａ１ １５０１０からのＴｒａｐメッセージ（トラップメッセージ）を受け取ったリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１５１０１は、装置Ａ１ １５０１０にリソース不足が発生している旨をアラーム画面として表示して管理者に通報する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−１４０８１４号公報（第５−８頁）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
図１５に示した現状のリソース管理システムの場合、リソース管理サーバ側から管理対象の各ネットワーク装置のアラーム閾値を設定することによってネットワーク全体のリソース管理を実施しているが、管理対象の各ネットワーク装置側から希望するアクション（処理実施内容）をリソース管理サーバ側へ依頼することによって、リソースの再配置を行って、ネットワーク全体のリソース状況を最適化するというものではなかった。つまり、前述のように、ＳＮＭＰ Ｔｒａｐメッセージを用いた監視方法は、単に、アラームを検知したことをリソース管理サーバ側に通知するのみであり、リソース不足を解消するために実施して欲しい具体的なアクション（処理実施内容）を通知して依頼することができないし、さらには、ネットワーク全体のリソース配分を最適化するために、他のネットワーク装置に対して具体的なアクション（処理実施内容）を実施させることもできなかった。したがって、アラームを検知しても、管理者が手動でアラーム内容を解析して適切と思われる処理を施すことが多かったため、本当に適切なリソース割当処理を実施するまでに時間がかかることが多かった。
【００１０】
このため、現状のリソース不足検知機能においては、次のような課題がある。
【００１１】
第１の課題は、リソース管理サーバのアラーム画面を、管理者が常に監視していることが必要であり、ヒューマンリソースが常に必要であるということにある。
【００１２】
第２の課題は、リソース管理サーバは、管理者が介在して、管理ネットワークの管理対象の各ネットワーク装置におけるリソースの配分状況をチェックして、リソース不足に対する処置を、リソース不足を解消させるための具体的な処理実施内容として管理対象の各ネットワーク装置に対して適切に施さないといけないため、リソースの再配置処理に時間がかかってしまうということにある。
【００１３】
第３の課題は、管理対象のネットワーク装置が異なると、リソース不足の発生形態例えばＳＹＳＬＯＧメッセージの内容が異なる可能性があるので、リソースを管理するリソース管理サーバ側としては、リソース不足のアラーム通知を受け取っても、リソース不足を解消させるために実施すべきアクション（処理実施内容）が各ネットワーク装置ごとに異なる可能性が大きく、実施すべきアクション（処理実施内容）を決定することが非常に厄介になるということにある。
【００１４】
（本発明の目的）
本発明は、かかる課題に鑑みてなされたものであり、リソース管理サーバ側と管理対象の各ネットワーク装置側とのネゴシエーションを行うことにより、ネットワーク全体のリソースの最適化を迅速かつ確実に行うことが可能なリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムを提供することを、その目的としている。
【００１５】
つまり、本発明は、管理対象のネットワーク装置においてリソース不足が発生した際に実施すべきアクション（処理実施内容）を、ネットワーク全体のリソースの管理を行うリソース管理サーバに対して管理対象のネットワーク装置から希望アクション（希望実施内容）としてあらかじめ事前登録しておくことによって、突然発生したリソース不足に対して、事前登録された希望アクション（希望実施内容）にしたがって、最適なリソースの再配置を自動的にかつ短時間に実施する仕組みを提供することを、その目的としている。
【課題を解決するための手段】
【００１６】
前述の課題を解決するため、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムは、主に、次のような特徴的な構成を採用している。
【００１７】
（１）本発明によるリソース管理システムは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えたリソース管理システムにおいて、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。
【００１８】
（２）本発明によるリソース管理サーバは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバにおいて、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録しておき、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。
【００１９】
（３）本発明によるネットワーク装置は、ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置において、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信することを特徴とする。
【００２０】
（４）本発明によるリソース管理方法は、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えることにより、ネットワーク全体のリソース状態を管理するリソース管理方法であって、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。
【００２１】
（５）本発明によるリソース管理プログラムは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバに、プログラムを実行可能なコンピュータを備え、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションをプロファイルとして各前記ネットワーク装置のリソース状態とともに事前に登録するステップと、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うステップと、を前記コンピュータによりプログラムとして実行することを特徴とする。
【００２２】
（６）本発明による別のリソース管理プログラムは、ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置に、プログラムを実行可能なコンピュータを備え、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記ソース管理サーバに事前に登録するステップと、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信するステップと、を前記コンピュータによりプログラムとして実行することを特徴とする。
【発明の効果】
【００２３】
本発明のリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムによれば、以下のような効果を奏することができる。
【００２４】
第１の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション（処理実施内容）をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。
【００２５】
第２の効果は、リソース管理サーバは、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション（処理実施内容）を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション（希望処理実施内容）を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。
【図面の簡単な説明】
【００２６】
【図１】本発明によるリソース管理システムのシステム構成の一例を示すシステム構成図である。
【図２】図１のリソース管理システムにおけるリソース管理サーバおよび各ネットワーク装置の装置構成の一例を説明するための説明図である。
【図３】図１のリソース管理システムにおけるリソース管理サーバと各ネットワーク装置との間のリソース管理に関するインタフェースの一例を説明するための説明図である
【図４】図３のリソース管理システムにおける希望アクションの事前登録シーケンスおよび希望アクションの削除シーケンスの一例を示すシーケンスチャートである。
【図５】図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの一例を示すシーケンスチャートである。
【図６】図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの図５とは異なる例を示すシーケンスチャートである。
【図７】図３のリソース管理システムにおいてネットワーク装置からリソース管理サーバに対して送信される事前登録・削除要求パケットのフォーマットの一例を示すテーブルである。
【図８】図３のリソース管理システムにおいてリソース管理サーバから事前登録・削除要求元のネットワーク装置に対して送信される事前登録・削除応答パケットのフォーマットの一例を示すテーブルである。
【図９】図３のリソース管理システムにおいて事前登録・削除応答パケットを受け取ったネットワーク装置からリソース管理サーバに対して送信される事前登録・削除応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【図１０】図３のリソース管理システムにおいてアラーム発生元のネットワーク装置からリソース管理サーバに対して送信されるアラーム発生通知パケットのフォーマットの一例を示すテーブルである。
【図１１】図３のリソース管理システムにおいてリソース管理サーバからアラーム発生通知パケットの送信元のネットワーク装置に対して送信されるアラーム発生応答パケットのフォーマットの一例を示すテーブルである。
【図１２】図３のリソース管理システムにおいてアラーム発生応答パケットを受け取ったネットワーク装置からリソース管理サーバに対して送信されるアラーム発生応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【図１３】本発明に係るリソース管理システムの具体的なシステム構成の一例を示すシステム構成図である。
【図１４】本発明によるリソース管理システムのシステム構成の図１とは異なる例を示すシステム構成図である。
【図１５】ネットワークのリソースを管理するリソース管理システムにおける動作の一例を説明するための説明図である。
【発明を実施するための形態】
【００２７】
以下、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムの好適な実施形態について添付図を参照して説明する。なお、以下の説明においては、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置およびリソース管理方法について説明するが、かかるリソース管理方法をコンピュータにより実行可能なリソース管理プログラムとして実施するようにしても良いし、あるいは、リソース管理プログラムをコンピュータにより読み取り可能な記録媒体に記録するようにしても良いことは言うまでもない。
【００２８】
（本発明の特徴）
本発明の実施形態の説明に先立って、本発明の特徴についてその概要をまず説明する。本発明は、ネットワーク全体のリソースの管理を行うリソース管理サーバにおいて、管理対象のネットワーク装置がリソース不足になった場合に、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）が実施すべきアクション（処理実施内容）を、管理対象の各ネットワーク装置のリソース管理Ａｇｅｎｔ（リソース管理エージェント）それぞれからリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）へあらかじめ事前登録しておくことにより、リソース管理サーバ側から、管理対象のネットワーク装置の運用状況を考慮した適切なリソース割当とアクションの実施とを可能にしていることを主要な特徴としている。
【００２９】
つまり、本発明は、管理対象のネットワーク装置がリソース不足に陥った時に、当該ネットワーク装置側が希望するアクション（処理実施内容）をリソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に事前登録しておくことにより、実際にリソース不足が発生した際に、当該リソース不足を解消させるための最適なアクション（処理実施内容）を速やかに、滞りなく実施することができ、リソースの最適割当を迅速に行うことができるようになっている。
【００３０】
また、本発明は、他のネットワーク装置のリソース使用状況、つまり、管理ネットワーク全体のリソース使用状況をも考慮して、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）が実施すべきアクション（処理実施内容）を判断することができるように、ネットワーク全体の各ネットワーク装置からの希望アクション（希望実施内容）を、各ネットワーク装置のリソース状態とともにプロファイルとしてあらかじめ設定し、リソース不足に陥ったネットワーク装置側が事前登録したアクション（処理内容）を実施することが適切か否かを判断することができる処理シーケンスを採用している。
【００３１】
さらに、本発明は、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に対してアクセスしてきたネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証する仕組みを採用しており、不正なネットワーク装置によってリソース管理への悪影響を防止するようにしている。例えば、不正なネットワーク装置が、リソース管理サーバが管理対象としている他のいずれかのネットワーク装置をシャットダウンさせるようなコマンドの実行を事前登録しておいて、リソース不足を示すアラーム発生通知をリソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に送信してくるようなことがあると、事前登録されているアクション（他のいずれかのネットワーク装置をシャットダウンさせる処理内容）が実施されてしまって、ネットワークのリソース管理を適切に実施することができなくなるので、リソース不足時のアクションを事前登録するネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証するようにしている。
【００３２】
（本発明の実施形態）
次に、本発明の実施形態について図を参照しながら詳細に説明する。本発明の実施形態は、図１に示すように、ネットワーク全体のリソースを管理するリソース管理サーバと、リソースの管理対象となる呼処理装置や無線制御装置やルータやハブ等のネットワーク装置と、リソース管理サーバと各ネットワーク装置との間を接続する管理ネットワークと、からなるリソース管理システムに関するものであり、前述したように、管理対象のネットワーク装置がリソース不足になった場合に、ネットワーク全体の運用状況を考慮して、リソース管理サーバ側から適切なリソース割当とアクションの実施とを可能にしている。図１は、本発明によるリソース管理システムのシステム構成の一例を示すシステム構成図である。
【００３３】
図１に示すリソース管理システムは、ネットワーク全体のリソースを管理するリソース管理サーバ１１００、リソースの管理対象となる１ないし複数のネットワーク装置に相当する装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０、および、ＳＮＭＰ(Simple Network Management Protocol)プロトコルを用いた管理ネットワークであるネットワーク１２００によって構成されている。
【００３４】
図１において、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０は、それぞれ、リソース管理サーバ１１００に対して、ネットワーク１２００を介して、あらかじめ定めた周期やリソースの使用状況に変化が発生する都度、自装置のリソース状況を通知している。リソース管理サーバ１１００は、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０それぞれのリソース使用状況を、ネットワーク１２００を介して受信して、ネットワーク１２００全体のリソースの使用状況をプロファイルとして保持して管理している。
【００３５】
次に、図１のリソース管理システムにおける装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０およびリソース管理サーバ１１００のリソース管理に関する部位について、その一例を、図２を用いて説明する。図２は、図１のリソース管理システムにおけるリソース管理サーバ１１００および各ネットワーク装置すなわち装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０の装置構成の一例を説明するための説明図であり、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０とリソース管理サーバ１１００とにおける各リソース管理用の機能部と、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０とリソース管理サーバ１１００との間のインタフェースについて示している。
【００３６】
なお、図２には、図１のリソース管理サーバ１１００、装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０を、それぞれ、リソース管理サーバ２１００、装置Ａ１ ２０１０，…，装置Ａｎ ２０ｎ０と、千番台の符号を図番号に対応する形で変更して示している。また、以下の各図面においても、同様に、符号を図番号に対応する形で変更している。
【００３７】
図２において、装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、それぞれ、自装置のリソース状況を保持している。また、装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定している。
【００３８】
装置Ａ２ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、それぞれに設定した該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、インタフェースＲ１１ないしインタフェースＲｎ１を経由して、図１に示したネットワーク１２００を介して、リソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１に対してアラーム発生通知を行い、あらかじめ事前登録しておいた希望アクション（希望実施内容）の実施を要求する。
【００３９】
リソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１は、装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理（リソースの再割当処理等）を実施して、実施結果を示す応答（アラーム発生応答）を、アラーム発生通知元の装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１に対して、それぞれ、インタフェースＲ１２ないしインタフェースＲｎ２を経由して、図１に示したネットワーク１２００を介して返送する。
【００４０】
装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、リソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１からの応答（アラーム発生応答）を受け取ると、該応答を正常に受信した旨を示す応答ＡＣＫを生成して、それぞれ、インタフェースＡＣＫ１ないしインタフェースＡＣＫｎを経由して、図１に示したネットワーク１２００を介して、リソース管理サーバ ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１に対して返送する。
【００４１】
次に、図１のリソース管理システムにおけるリソース管理サーバ１１００のリソース管理に関する部位と管理対象のネットワーク装置である装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０との間のさらに詳細なインタフェースについて、その一例を、図３を用いて説明する。図３は、図１のリソース管理システムにおけるリソース管理サーバ１１００と各ネットワーク装置すなわち装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０との間のリソース管理に関するインタフェースの一例を説明するための説明図であり、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０のうち、第ｍ番目と第ｎ番目の装置を取り出して、リソース管理サーバ１１００のリソース管理用の機能部と、管理対象のネットワーク装置である装置Ａｍ １０ｍ０、装置Ａｎ １０ｎ０との間のリソース管理に関する全インタフェースについて示している。
【００４２】
なお、図３においても、前述したように、図１のリソース管理サーバ１１００、装置Ａｍ １０ｍ０、装置Ａｎ １０ｎ０を、それぞれ、リソース管理サーバ３１００、装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０と、千番台の符号を図番号に対応する形で変更して示している。また、図２のリソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１についても、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１と、千番台の符号を図番号に対応する形で変更している。
【００４３】
さらに、図２の装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１、装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１についても、それぞれ、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１と、千番台の符号を図番号に対応する形で変更して示している。
【００４４】
図３においても、図２の場合と同様、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理（リソースの割当処理）を実施して、実施結果を示す応答（アラーム発生応答）を、アラーム発生通知元の装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信している。
【００４５】
また、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、図２の場合と同様、それぞれ、自装置のリソース状況を保持している。さらに、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定し、該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知の送信を行っている。
【００４６】
図３に示すように、リソース管理サーバ３１００は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に、管理対象の各ネットワーク装置である装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０ごとに、それぞれのリソース管理に関する情報（希望アクション（希望する処理実施内容）、処理開始時刻、処理実施履歴、リソース状況等）を登録保持しているデータベースとしてプロファイル３１０４を所持している他、アクセスしてくる各ネットワーク装置例えば装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０の認証を行う認証管理３１０２、リソース管理に関するアプリ処理を実行するアプリケーションＸ ３１０３の各機能部を有している。また、装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０にも、それぞれ、リソース管理に関するアプリ処理を実行するアプリケーションＡｍ ３０ｍ２、アプリケーションＡｎ ３０ｎ２、の機能部を有している。
【００４７】
図３に示す各機能部および各機能部間のインタフェースに関する説明を、次の表１に示している。
【００４８】
【表１】
【００４９】
装置Ａｎ ３０ｎ０、装置Ａｍ ３０ｍ０は、いずれも、前述したように、リソース管理サーバ３１００のリソース管理対象となるネットワーク装置であり、図３においては、装置Ａｎ ３０ｎ０にリソース不足が発生して、装置Ａｎ ３０ｎ０からリソース管理サーバ３１００に対してアラーム発生通知を送信した場合に、ネットワーク全体のリソース配分を最適化するために、リソース管理サーバ３１００のアプリケーションＸ ３１０３が、アラーム発生通知元とは異なる他のネットワーク装置の装置Ａｍ ３０ｍ０に対してアクションを指示する場合がある例も説明することとする。
【００５０】
表１に示すように、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１は、いずれも、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１との間のネゴシエーションを行い、自装置内のリソースを管理するアプリケーションであり、使用するリソースが使用可能な限界値としてあらかじめ設定されたリソース閾値を超えた場合に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、事前に登録された希望アクション（希望実施内容）を実施することを要求するアラーム発生通知を送信する。
【００５１】
装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２は、使用するリソースがリソース閾値を超えた場合にリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１にてアラーム発生通知をリソース管理サーバ３１００に送信した結果として、リソース管理サーバ３１００のアプリケーションＸ ３１０３からの要求に基づいて実施されるリソース管理関連のアプリケーションであり、装置Ａｎ ３０ｎ０に常駐しており、アプリケーションＸ ３１０３からの要求に応じて、いつでも実行することが可能である。
【００５２】
これに対して、装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からのアラーム処理要求があった場合に、該アラーム処理要求に該当する処理内容を実行して、処理結果をアラーム処理要求元のリソース管理サーバ３１００のアプリケーションＸ ３１０３に対して返送するリソース管理関連のアプリケーションであり、装置Ａｍ ３０ｍ０に常駐しており、アプリケーションＸ ３１０３からのアラーム処理要求に応じて、いつでも実行することが可能である。
【００５３】
リソース管理サーバ３１００は、図３においては、リソースの管理対象のネットワーク装置である装置Ａｎ ３０ｎ０のリソース使用状況を監視する監視サーバであり、装置Ａｎ ３０ｎ０のリソースがリソース閾値を超えた場合に装置Ａｎ ３０ｎ０から送信されてくるアラーム発生通知に応じて、当該リソース管理サーバ３１００にあらかじめ設定登録されている希望アクション（希望実施内容）を実施するようにアプリケーションＸ ３１０３に対して指示する。
【００５４】
また、アラーム発生通知を送信してきた装置Ａｎ ３０ｎ０がリソース管理対象のネットワーク装置であるか否かを認証する動作を実施して、リソース管理サーバ３１００への不適当なネットワーク装置からの不正接続を防止する機能も有している。つまり、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、リソースの管理対象のネットワーク装置である装置Ａｎ ３０ｎ０の装置起動時に送信されてくる希望アクション（希望実施内容）の事前登録要求を受け取った際に、要求元の装置Ａｎ ３０ｎ０の認証を行うために、認証管理３１０２に対して認証要求を行う。また、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１がリソース閾値を超えたことを検知した際に送信してくるアラーム発生通知を受け取った際に、事前に設定登録された希望アクション（希望実施内容）に基づいて適切な判断を行い、必要に応じてアプリケーションＸ ３１０３に対してアラーム処理要求を出力する。
【００５５】
なお、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、リソースの管理対象のネットワーク装置であるすべての装置（図３の場合、装置Ａｎ ３０ｎ０、装置Ａｍ ３０ｍ０の２つのネットワーク装置を示している）のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｉ１（ｉ＝１，２，…，ｍ，…ｎ）に関するプロファイル３１０４を備えており、必要に応じて、プロファイル３１０４に保持されている各ネットワーク装置のデータを参照することが可能である。
【００５６】
ここで、プロファイル３１０４は、管理対象の各ネットワーク装置の希望アクション（希望実施内容：リソース不足発生時にリソース管理サーバ３１００側で実施して欲しい処理内容）を、各ネットワーク装置のリソース状態とともに事前登録しているものであり、リソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｉ１（ｉ＝１，２，…，ｍ，…ｎ）を有するすべてのネットワーク装置（図３の場合、装置Ａｎ ３０ｎ０、装置Ａｍ ３０ｍ０の２つのネットワーク装置）それぞれが希望する処理実施内容や実施開始時刻等に関する希望アクション情報をリソース状態とともに設定しているデータベースである。リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、必要に応じて、プロファイル３１０４のデータ（例えばアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のデータ）を参照して、希望するアクション（処理実施内容）を決定して実施する。
【００５７】
リソース管理サーバ３１００の認証管理３１０２は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からの要求があった装置Ａｎ ３０ｎ０が、管理対象のネットワーク装置として管理すべきネットワーク装置であるか否かを認証する処理を実施する。
【００５８】
リソース管理サーバ３１００のアプリケーションＸ ３１０３は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム処理要求を受け取った場合、つまり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からアラーム発生通知を受け取ったリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１がアプリケーションＸ ３１０３による処理が必要であると判断した場合、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２、または、該送信元とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２に対して、事前に設定登録されているアクション（処理内容）の実行を要求するアラーム処理要求を送信する。
【００５９】
ここで、アプリケーションＸ ３１０３は、特定のアプリケーションを意味しているものではなく、アラーム発生通知の内容とプロファイル３１０４に設定されているデータとを参照した結果による判断結果に基づいてリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１によって選択されて指示されたアプリケーションのことである。
【００６０】
また、インタフェースＲｎｊ（ｊ＝１，２，７，８，９，１０，１１，１２）、ＡＣＫｎ、ＡＣＫｍは、異なる装置間で通信するためのインタフェースであり、インタフェースＲｎ３，４，５，６は、リソース管理サーバ３１００内の機能部間で通信するためのＡＰＩ（Application Program Interface）である。
【００６１】
より詳細には、インタフェースＲｎ１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースＲｎ２は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対してアクションの実施結果を示す処理応答（アラーム発生応答）を送信するためのインタフェースである。
【００６２】
また、インタフェースＲｎ３は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から認証管理３１０２に対して認証要求を送信するためのＡＰＩであり、インタフェースＲｎ４は、リソース管理サーバ３１００の認証管理３１０２からリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して認証結果を送信するためのＡＰＩである。
【００６３】
また、インタフェースＲｎ５は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアプリケーションＸ ３１０３に対して指定したアプリ実行要求を送信するためのＡＰＩであり、インタフェースＲｎ６は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアプリ実行結果を送信するためのＡＰＩである。
【００６４】
また、インタフェースＲｎ７は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースＲｎ８は、アラーム処理要求の送信先の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２からリソース管理サーバ３１００のアプリケーションＸ ３１０３に対して処理結果を示す応答を送信するためのインタフェースである。
【００６５】
また、インタフェースＲｎ９は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からアラーム発生通知の送信元とは異なる装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースＲｎ１０は、アラーム処理要求の送信先の装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２からリソース管理サーバ３１００のアプリケーションＸ ３１０３に対して処理結果を示す応答を送信するためのインタフェースである。
【００６６】
また、インタフェースＲｎ１１は、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースＲｎ１２は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生通知の送信元の装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１に対してアクションの実施結果を示す処理応答（アラーム発生応答）を送信するためのインタフェースである。
【００６７】
また、インタフェースＡＣＫｎは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して処理応答を正常に受け取った旨を示す応答ＡＣＫを送信するためのインタフェースであり、インタフェースＡＣＫｍは、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して処理応答を正常に受け取った旨を示す応答ＡＣＫを送信するためのインタフェースである。
【００６８】
次に、図３のリソース管理システムに示したリソース管理サーバ３１００と管理対象のネットワーク装置である装置Ａｎ ３０ｎ０との間の通信シーケンスについて、装置Ａｎ ３０ｎ０から事前に設定登録する希望実施内容すなわち希望アクションの登録および希望実施内容すなわり希望アクションの削除を行う際のシーケンスの一例を、図４を用いて説明する。
【００６９】
図４は、図３のリソース管理システムにおける希望アクション（希望実施内容）の事前登録シーケンスおよび希望アクション（希望実施内容）の削除シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置Ａ１ ３０１０ないし装置Ａｎ ３０ｎ０のうち、いずれかのネットワーク装置例えば第ｎ番目の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からのリソース管理サーバ３１００に対する事前登録要求があった際に、希望アクション（希望実施内容）を事前に設定登録し、かつ、事前登録削除要求に応じて、設定登録していた希望アクション（希望実施内容）を削除する場合のシーケンスについて示している。
【００７０】
装置Ａｎ ３０ｎ０は、収容する端末数の変化やネットワークのリソース変動等に伴って、使用するリソースがあらかじめ設定したリソース閾値を超えた場合に、リソース管理サーバ３１００に対してアラーム発生通知を送信することによって、あらかじめ事前に設定登録している希望アクション（希望実施内容）の実施を要求する。ここで、実施してもらいたい希望アクション（希望実施内容）とは、例えば、装置Ａｎ ３０ｎ０を利用する端末数が増加したために、装置Ａｎ ３０ｎ０の使用可能なリソース量を増加させるようなリソースの再配分を実施してもらうことを要求したり、あるいは、新たな装置Ａｍ ３０ｍ０に増加した一部または全ての端末を収容させるために、装置Ａｍ ３０ｍ０の閉塞状態を解除することを要求したりする場合を意味している。以下においては、図４のシーケンスで示す一連の処理を「事前登録・削除処理」と称することにする。
【００７１】
図４のシーケンスチャートにおいて、まず、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、装置起動時に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、図７に示すフォーマットからなる事前登録・削除要求パケットを送信する（シーケンスＳ４００１）。
【００７２】
図７は、図３のリソース管理システムにおいてネットワーク装置の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信される事前登録・削除要求パケットのフォーマットの一例を示すテーブルである。
【００７３】
ここで、図７に示す事前登録・削除要求パケットは、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、リソース閾値を超えた場合にアラーム発生通知をリソース管理サーバ３１００に送信することによって、リソース管理サーバ３１００側で実施して欲しい希望アクション（希望実施内容）をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に事前登録するために用いられ、また、事前登録されている希望アクション（希望実施内容）に関する情報を削除するために用いられる。
【００７４】
具体的には、図７に示す事前登録・削除要求パケットは、バージョン、ヘッダ長、パケット長、タイプ、要求数、シーケンス番号、承認キー、予約の各情報からなるヘッダ情報に引き続くデータ領域に、実施して欲しい希望アクション（希望実施内容）に関する情報として、希望優先度、指示対象名、実施回数、仮登録番号、開始時刻、希望実施内容を１組の希望アクションとし、必要に応じて、優先度を付して、希望アクション１，…，希望アクションｊと複数組纏めて収容することができる。
【００７５】
図７に示す事前登録・削除要求パケットに設定されるそれぞれの情報の意味は、次の表２に示す通りである。なお、表２には、後述する図８の事前登録・削除応答パケット、図９の事前登録・削除応答ＡＣＫパケット、図１０のアラーム発生通知パケット、図１１のアラーム発生応答パケット、図１２のアラーム発生応答ＡＣＫパケットに設定される情報の意味についても併せて説明しているので、後述する該当の箇所においても、表２をそれぞれ参照されたい。
【００７６】
【表２】
【００７７】
表２に示すように、図７に示す事前登録・削除要求パケットのヘッダ情報内のバージョンフィールドは、当該パケットフォーマットタイプのバージョンを示す情報であり、送信元のネットワーク装置の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１と送信先のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１との双方で同じ方式のパケットフォーマットを用いて通信を行うために設定している。また、事前登録・削除要求パケットのヘッダ情報内のヘッダ長フィールドは、事前登録・削除要求パケットのヘッダ情報の長さ（バイト数）を示している。図７に示す事前登録・削除要求パケットの場合は１２バイトである。
【００７８】
また、事前登録・削除要求パケットのヘッダ情報内のパケット長フィールドは、データ領域に収容している希望アクション１、…、希望アクションｊの合計のメッセージサイズを設定し、ヘッダ情報内のタイプフィールドは、当該事前登録・削除要求パケットの種別を示し、事前登録要求であるか事前登録内容の削除要求であるかを設定する。
【００７９】
また、事前登録・削除要求パケットのヘッダ情報内の要求数フィールドは、希望アクション（希望実施内容）の個数（図７に示す例では、ｊ個）を設定し、事前登録・削除要求パケットのヘッダ情報内のシーケンス番号フィールドは、イベントが発生する都度、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１へ送信したパケットの送信順を示す番号を設定する。
【００８０】
また、事前登録・削除要求パケットのヘッダ情報内の承認キーフィールドには、事前登録要求時には、'０'が設定され、事前登録した希望アクション（希望実施内容）の削除要求時には、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録要求時に要求元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１が承認されることによって付与されていた承認キーが設定される。なお、ヘッダ情報内の予約フィールドは、現在使用されていないダミー領域である。
【００８１】
また、事前登録・削除要求パケットのデータ領域内の希望優先度フィールドは、複数の希望アクション（希望実施内容）を事前登録しようとする場合にそれぞれの希望アクションの優先順位を設定する。なお、複数の希望アクションに同一値の優先度が付されていた場合には、ヘッダ情報側に近い希望アクションほど優先して処理が実施されることにする。ただし、該希望優先度については、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側で、必要に応じて、優先順を変更することが可能である。
【００８２】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される指示対象名フィールドは、リソース管理サーバ３１００のアプリケーションＸ ３１０３から、複数のネットワーク装置すなわち装置Ａ１ ３０１０，…，装置Ａｎ ３０ｎ０のうち、設定したネットワーク装置例えば装置ＡｉのアプリケーションＡｉに対して、アラーム処理要求を送信して、希望アクション（希望実施内容）を実施してもらうことを示している。また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数フィールドは、希望アクション（希望実施内容）を実施する回数を設定する。
【００８３】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される仮登録番号フィールドは、事前登録要求元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１側において、実施を希望する処理実施内容すなわち希望アクション（希望実施内容）を管理するために使用されるユニークな仮の登録番号を設定する。該仮登録番号は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において本登録キーが発行完了されて、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から通知されてくるまでの一時的なキーとして扱われる。
【００８４】
なお、事前登録・削除要求パケットとして、事前登録された希望アクション（希望実施内容）を削除することを要求する場合には、既に、本登録キーが付与された状態にあるので、仮登録番号の代わりに、本登録キーを用いる。また、削除要求の場合には、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数、開始時刻、希望実施内容の各フィールドを省略することも可能である。また、すべての希望アクション（希望実施内容）を削除する場合には、場合によっては、ヘッダ情報のみからなる事前登録・削除要求パケットを用いるようにしても良い。
【００８５】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される開始時刻フィールドは、希望アクション（希望実施内容）をいつ実施するかというエポックタイムを指定する時刻情報を設定する。即時に実施することを指定する場合には、開始時刻を例えば'ａｌｌ０'に設定する。
【００８６】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される希望実施内容フィールドは、リソース閾値を超えるリソース不足が発生した際に、または、リソース閾値以下に低下してリソース不足から回復した際に、リソース管理サーバ３１００側において、さらに、必要に応じて、アプリケーションＸ ３１０３を駆動することにより、実施してもらいたい処理内容を設定する。リソース管理サーバ３１００やアプリケーションＸ ３１０３が指定された処理内容を実施する開始タイミングは、事前登録・削除要求パケットの開始時刻フィールドによって指定されている。なお、希望実施内容フィールドに設定する希望アクション（希望実施内容）の情報量が、一定のデータサイズ例えば４バイトに収まらない場合には、希望実施内容フィールドを任意の長さに拡張することも可能である。
【００８７】
なお、以下の説明においては、ヘッダ情報に含まれるタイプには、事前登録を要求するパケットである旨の表示が設定され、要求数には、前述のように、事前登録を要求する希望アクションの個数が設定されているものとする。
【００８８】
リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から事前登録・削除要求パケットを受け取ると、該事前登録・削除要求パケットの送信元の装置Ａｎ ３０ｎ０が、管理対象のネットワーク装置であるか否かを判別するために、認証管理３１０２に対して認証要求を行う（シーケンスＳ４００２）。かかる動作は、前述したように、装置Ａｎ ３０ｎ０がリソース管理に該当していない不正なネットワーク装置であった場合に、ネットワーク全体に悪影響を及ぼし兼ねないので、かかる事態の発生を未然に防止するためである。
【００８９】
なお、認証管理３１０２に対する該認証要求には、認証の対象となるネットワーク装置を一意に特定することができる情報であって、かつ、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が確実に把握することができるネットワーク装置識別情報が付されている。例えば、事前登録・削除要求パケットの送信元を示す装置Ａｎ ３０ｎ０のＩＰアドレスやＭＡＣアドレス等が付されている。
【００９０】
認証要求を受け取った認証管理３１０２においては、該認証要求に付されているネットワーク装置識別情報例えばＩＰアドレスやＭＡＣアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置Ａｎ ３０ｎ０がリソース管理の対象装置であるか否かを判別することにより、装置Ａｎ ３０ｎ０の認証処理を行う。なお、認証管理３１０２における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。
【００９１】
認証管理３１０２は、装置Ａｎ ３０ｎ０の認証処理を終了すると、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して認証応答として返送する（シーケンスＳ４００３）。
【００９２】
リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、認証管理３１０２から認証応答として装置Ａｎ ３０ｎ０の認証結果を受け取り、該認証結果がＮＧであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取った事前登録・削除要求パケットに含まれている全ての希望アクションの事前登録を拒否する。一方、該認証結果がＯＫであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取った事前登録・削除要求パケットに含まれている全ての希望アクションすなわち希望アクション１，…，希望アクションｊを事前登録するとともに、それぞれの希望アクションごとに、それぞれの希望アクションを一意に特定するための本登録キーを発行する。
【００９３】
さらに、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、認証結果がＮＧであった場合には、事前登録要求を受け付けられない旨を示すＮＧ応答として、図８に示す事前登録応答パケットのヘッダ情報内の承認キーを"ａｌｌ０"に設定して、事前登録要求の送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信する（シーケンスＳ４００４）。
【００９４】
一方、認証結果がＯＫであった場合には、事前登録要求を受け付けた旨を示すＯＫ応答として、事前登録・削除要求パケットに含まれているそれぞれの希望アクションを一意に特定する本登録キーを付与した図８に示す事前登録応答パケットを作成するとともに、ヘッダ情報内の承認キーを、装置Ａｎ ３０ｎ０をリソース管理対象のネットワーク装置として承認したことを示す"ａｌｌ０"以外の有意な一意の値に設定して、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信する（シーケンスＳ４００４）。
【００９５】
図８は、図３のリソース管理システムにおいてリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から事前登録・削除要求元のネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信される事前登録・削除応答パケットのフォーマットの一例を示すテーブルである。
【００９６】
ここで、図８に示す事前登録・削除応答パケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、事前登録・削除要求パケットの送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に送信することによって、事前登録・削除要求パケットによって要求された希望アクション（希望実施内容）を事前登録したか否かを通知するために用いられる。
【００９７】
具体的には、図８に示す事前登録・削除応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域が要求受付数に関する情報を設定する領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、事前登録・削除要求パケットに含まれていた仮登録番号ごとに、仮登録結果および希望するアクション（処理内容）を一意に特定する本登録キーを１組の希望アクション応答とし、受け取った事前登録・削除要求パケットに応じて、希望アクション１応答，…，希望アクションｊ応答と複数組纏めて収容することができる。なお、ヘッダ情報に含まれるタイプには、事前登録・削除の応答を返送するパケットである旨を示す表示が設定される。
【００９８】
つまり、前述の表２に示すように、事前登録・削除応答パケットのヘッダ情報内の要求受付数フィールドには、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取った事前登録・削除要求パケットの希望実施内容フィールドにて指定されている希望アクション（希望実施内容）のうち、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において正当な処理要求であると認識して、事前登録された希望アクション（希望実施内容）の個数が設定される。
【００９９】
また、事前登録・削除応答パケットのデータ領域内において希望アクション応答ごとに設定される仮登録結果フィールドは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からの各希望アクション（希望実施内容）ごとの事前登録結果（事前登録されたか否かを示す情報）を設定する。事前登録・削除応答パケットのデータ領域内において希望アクション応答ごとに設定される本登録キーフィールドは、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録した希望アクション（希望実施内容）ごとに発行した本登録キーを設定する。
【０１００】
事前登録・削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、仮登録番号の各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、事前登録要求元の装置Ａｎ ３０ｎ０がリソース管理対象のネットワーク装置として承認され、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録・削除要求パケットに含まれている希望アクション（希望実施内容）の少なくとも１つ以上を事前登録した際に発行された'ａｌｌ０'以外の有意な一意の値である承認キーが設定される。
【０１０１】
また、シーケンス番号フィールドには、イベントが発生する都度、図７に示した事前登録・削除要求パケットの場合とは逆方向に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１へ送信したパケットの送信順を示す番号が設定される。
【０１０２】
図４のシーケンスチャートに戻って、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から事前登録・削除応答パケットを受け取ると、該事前登録・削除応答パケットのヘッダ情報に含まれている承認キーを参照して、'ａｌｌ０'以外の有意な一意の値が設定されているか否かを判別する。承認キーが'ａｌｌ０'であった場合には、当該装置Ａｎ ３０ｎ０が、リソース管理サーバ３１００のリソース管理対象のネットワーク装置ではないと認定されて、事前登録が拒絶されたことを示している。
【０１０３】
一方、承認キーが'ａｌｌ０'以外の有意な一意の値であった場合には、先に送信した事前登録・削除要求パケットに含まれている希望アクション（希望実施内容）の事前登録要求が受け付けられたものとして、事前登録・削除応答パケットを正常に受け取ったことを示す応答ＡＣＫを、図９に示す事前登録・削除応答ＡＣＫパケットとして、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信する（シーケンスＳ４００５）。
【０１０４】
なお、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においては、以降、データ領域に仮登録番号ごとに対応付けて設定されている本登録キーを用いて、実施を希望する希望実施内容すなわち希望アクション（処理内容）を管理することになる。
【０１０５】
図９は、図３のリソース管理システムにおいて事前登録・削除応答パケットを受け取ったネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信される事前登録・削除応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【０１０６】
ここで、図９に示す事前登録・削除応答ＡＣＫパケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、事前登録・削除応答パケットの送信元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信することによって、事前登録・削除応答パケットを正常に受け取った旨を通知するために用いられる。
【０１０７】
具体的には、図９に示す事前登録・削除応答ＡＣＫパケットは、ヘッダ情報のみからなり、ヘッダ情報にはバージョン、ヘッダ長、パケット長、タイプ、承認応答結果、シーケンス番号、承認キー、予約が含まれている。なお、ヘッダ情報に含まれるタイプには、事前登録・削除応答パケットを正常に受け取った旨を示す応答ＡＣＫパケットである旨を示す表示が設定される。
【０１０８】
つまり、前述の表２に示すように、事前登録・削除応答ＡＣＫパケットのヘッダ情報内の承認応答結果フィールドは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においても、事前登録・削除要求パケットの希望実施内容フィールドにて指定した希望アクション（希望実施内容）のうちリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録された希望アクション（希望実施内容）を正しく認識することができたか否かを示す情報を設定する。なお、複数存在している予約フィールドは、いずれも、現在使用されていないダミーの領域を示している。
【０１０９】
事前登録・削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録・削除要求パケットを受け付けて、事前登録・削除要求パケットに含まれている希望アクション（希望実施内容）の少なくとも１つ以上を事前登録した際に発行された'ａｌｌ０'以外の有意な一意の値である承認キーが設定される。
【０１１０】
以上の図４のシーケンスチャートに関する説明は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からの事前登録・削除要求パケットとして、リソース閾値を超えてリソース不足が発生したことを示すアラーム発生通知をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信した際に実施してもらいたい希望アクション（希望実施内容）を事前登録することを要求している場合について説明したが、事前登録されている希望アクション（希望実施内容）を削除することを要求する場合についても、全く同様のシーケンスで実施される。
【０１１１】
ただし、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からの事前登録・削除要求パケットとして、事前登録されている希望アクション（希望実施内容）の削除を要求する場合には、ヘッダ情報に含まれるタイプには、事前登録の削除を要求するパケットである旨の表示が設定され、要求数には、事前登録の削除を要求する希望アクションの個数が設定される。
【０１１２】
また、削除要求を行う場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においても、各希望アクション（各希望実施内容）を一意に特定するための識別番号として、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が発行した本登録キーが既に用いられているので、事前登録の要求時においてデータ領域の希望実施内容ごとに設定されていた仮登録番号の代わりに、本登録キーが設定される。
【０１１３】
なお、図４に示すような事前登録・削除処理においては、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から送信されてくる事前登録・削除要求パケットを受け取ったとしても、アプリケーション実行の予約に関する情報は無効であり、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から、アプリケーションＸ ３１０３に対してアプリケーション実行の予約等を事前に行うことはない。
【０１１４】
アプリケーションＸ ３１０３の実行を予約する場合は、あくまでも、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１において、使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいはリソース閾値以下に低下してリソース不足から回復したりして、アラーム発生通知をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信してきた場合のみに限られる。
【０１１５】
次に、図３のリソース管理システムに示したリソース管理サーバ３１００と管理対象のネットワーク装置である装置Ａｎ ３０ｎ０との間の通信シーケンスについて、装置Ａｎ ３０ｎ０において使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置Ａｎ ３０ｎ０からリソース管理サーバ３１００に対して送信する際のシーケンスの一例を、図５を用いて説明する。
【０１１６】
図５は、図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置Ａ１ ３０１０ないし装置Ａｎ ３０ｎ０のうち、いずれかのネットワーク装置例えば第ｎ番目の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００に対してアラーム発生通知が送信されて、事前に設定登録されていた希望アクション（希望実施内容）を実施する際の処理シーケンスの一例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、事前登録された希望アクション（希望実施内容）とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションＸ ３１０３を駆動して、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２に対して、アラーム処理要求を送信することによって、装置Ａｎ ３０ｎ０のＭＩＢ（Management Information Base）情報を収集して輻輳状態を判別し、リソース状態の再配分を行う場合のシーケンス例について示している。以下においては、図５のシーケンスで示す一連の処理を「アラーム処理１」と称することにする。
【０１１７】
図５のシーケンスチャートにおいて、まず、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、使用しようとするネットワークのリソースがあらかじめ設定しているリソース閾値を超えたか、あるいは、該リソース閾値を超えた状態から該リソース閾値以下にまで低下してリソース不足から回復したりしたことを検知すると、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、アラーム処理要求を行うためのアラーム発生通知として、図１０に示すフォーマットからなるアラーム発生通知パケットを送信する（シーケンスＳ５００１）。
【０１１８】
図１０は、図３のリソース管理システムにおいてアラーム発生元のネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信されるアラーム発生通知パケットのフォーマットの一例を示すテーブルである。
【０１１９】
ここで、図１０に示すアラーム発生通知パケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、アラーム発生元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信することによって、事前登録しておいた希望アクション（希望実施内容）のいずれかを実施することを要求するために用いられる。
【０１２０】
具体的には、図１０に示すアラーム発生通知パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、閾値種別、予約からなるアラーム内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生を通知するパケットである旨を示す表示が設定され、アラーム内容の閾値種別には、リソース閾値を超えたかまたは該リソース閾値以下に低下してリソース不足から回復したかを示す情報が設定されている。
【０１２１】
つまり、前述の表２に示すように、アラーム発生通知パケットのヘッダ情報内のシーケンス番号フィールドは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１において、アラームが発生する都度、インクリメントされる番号であり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１へ送信したパケットの送信順を示している。該シーケンス番号は、装置Ａｎ ３０ｎ０に発生したアラームをリソース管理サーバ３１００に通知した状況を管理するための識別番号として使用される。
【０１２２】
また、アラーム発生通知パケットのデータ領域にあるアラーム内容内の閾値種別フィールドは、前述したように、装置Ａｎ ３０ｎ０の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
【０１２３】
アラーム発生通知パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において既に発行されている承認キーが設定される。
【０１２４】
図５のシーケンスチャートに戻って、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からアラーム発生通知パケットを受け取ると、図４の事前登録・削除処理の場合と同様、該アラーム発生通知パケットの送信元の装置Ａｎ ３０ｎ０が、管理対象のネットワーク装置であるか否かを判別するために、認証管理３１０２に対して認証要求を行う（シーケンスＳ５００２）。
【０１２５】
認証要求を受け取った認証管理３１０２においては、図４の事前登録・削除処理の場合と同様、該認証要求に付されているネットワーク装置識別情報例えばＩＰアドレスやＭＡＣアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置Ａｎ ３０ｎ０がリソース管理の対象装置であるか否かを判別することにより、装置Ａｎ ３０ｎ０の認証処理を行う。なお、認証管理３１０２における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。
【０１２６】
認証管理３１０２は、装置Ａｎ ３０ｎ０の認証処理を終了すると、図４の事前登録・削除処理の場合と同様、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して認証応答として返送する（シーケンスＳ５００３）。
【０１２７】
リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、認証管理３１０２からの認証応答として、装置Ａｎ ３０ｎ０の認証結果を受け取り、該認証結果がＮＧであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。
【０１２８】
一方、該認証結果がＯＫであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション（希望実施内容）を参照して、実施すべきアクション（処理内容）を決定する。決定されたアクション（処理内容）が、例えば、アプリケーションＸ ３１０３を駆動して、輻輳状態を判別するためにアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２にアラーム処理要求を送信することによって、装置Ａｎ ３０ｎ０のＭＩＢ（Management Information Base）情報を収集する処理を行う場合には、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、アプリケーションＸ ３１０３を駆動して、アラーム処理要求として、決定したアクション（処理内容）にしたがった処理の実施を要求する（シーケンスＳ５００４）。
【０１２９】
駆動されたアプリケーションＸ ３１０３は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０にアラーム処理要求を送信することによって、装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２のＳＮＭＰ（Simple Network Management Protocol） ＭＩＢ（Management Information Base）情報を収集する動作を起動する。この動作が起動されると、アプリケーションＸ ３１０３は、事前登録された希望アクション（希望実施内容）の中から決定した希望アクション（希望実施内容）にしたがったアラーム処理要求として、例えば、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２に対して、ＳＮＭＰ ＭＩＢ情報の収集を指示するアラーム処理要求を送信する（シーケンスＳ５００５）。
【０１３０】
装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２は、決定した事前登録の希望アクション（希望実施内容）にしたがったアラーム処理要求例えばＳＮＭＰ ＭＩＢ情報の収集を指示するアラーム処理要求をリソース管理サーバ３１００のアプリケーションＸ ３１０３から受け取ると、事前登録の希望アクション（希望実施内容）にしたがった処理例えばＳＮＭＰ ＭＩＢ情報の収集処理を実施して、事前登録の希望アクション（希望実施内容）の実施結果例えばＳＮＭＰ ＭＩＢ情報の収集結果を、リソース管理サーバ３１００のアプリケーションＸ ３１０３に対して返送する（シーケンスＳ５００６）。
【０１３１】
リソース管理サーバ３１００のアプリケーションＸ ３１０３は、アラーム処理要求に応じて、装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２から返送されてきた事前登録の希望アクション（希望実施内容）の実施結果例えばＳＮＭＰ ＭＩＢ情報の収集結果を受け取ると、受け取った実施結果例えばＳＮＭＰ ＭＩＢ情報の収集結果を保持するとともに、該ＳＮＭＰ ＭＩＢ情報の収集結果に基づくリソースの再配分を行い、決定した事前登録の希望アクション（希望実施内容）の実施が成功したか否かを、当該アプリケーションＸ ３１０３から、アラーム処理要求に対する応答として、アラーム処理要求元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して返送する（シーケンスＳ５００７）。
【０１３２】
リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、アプリケーションＸ ３１０３からアラーム処理要求に対する応答を受け取ると、該応答を実行結果として含む図１１に示すフォーマットからなるアラーム発生応答パケットを作成して、アラーム発生通知パケットの送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信する（シーケンスＳ５００８）。
【０１３３】
なお、アプリケーションＸ ３１０３における何らかの処理が失敗した場合には、アプリケーションＸ ３１０３は、アラーム処理要求元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して処理を失敗した旨を示す応答を返送する。かくのごとく、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、アプリケーションＸ ３１０３における処理が失敗した旨の応答を受け取った場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対するアラーム発生応答パケットの送信動作を抑止して、応答待ちタイムアウトによる装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からのアラーム発生通知パケットの再送信を促すようにしても良い。
【０１３４】
図１１は、図３のリソース管理システムにおいてリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生通知パケットの送信元のネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信されるアラーム発生応答パケットのフォーマットの一例を示すテーブルである。
【０１３５】
ここで、図１１に示すアラーム発生応答パケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、アラーム発生通知パケットの送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に送信することによって、アラーム発生通知パケットによって要求された希望アクション（希望実施内容）の実施に成功したか否かを通知するために用いられる。
【０１３６】
具体的には、図１１に示すアラーム発生応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、実行結果、閾値種別、強制削除フラグからなるアラーム応答内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生通知に対する応答を返送するパケットである旨を示す表示が設定される。
【０１３７】
つまり、前述の表２に示すように、アラーム発生応答パケットのヘッダ情報内のシーケンス番号フィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において、イベントが発生する都度、図１０に示したアラーム発生通知パケットの場合と同様、インクリメントされる番号であり、図１０に示したアラーム発生通知パケットの場合とは逆方向に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１へ送信したパケットの送信順を示している。
【０１３８】
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図１０に示したアラーム発生通知パケットにより送信されてきた閾値種別がそのまま設定され、装置Ａｎ ３０ｎ０の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
【０１３９】
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドには、アラーム発生通知パケットにより要求された希望アクション（希望実施内容）の処理例えばＳＮＭＰ ＭＩＢ情報の収集処理が成功し、リソースの再配分に成功したか否かを示す実行結果が設定され、本実施例においては、アプリケーションＸ ３１０３により駆動された装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２の実施が成功したか否かを示す情報が設定される。なお、該実行結果として、アプリケーションＸ ３１０３により駆動された装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２の実施結果を示す処理詳細例えばＳＮＭＰ ＭＩＢ情報の収集結果やリソース再配分処理結果を含むようにしても良い。
【０１４０】
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の強制削除フラグフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、ネットワーク全体の各ネットワーク装置からの希望アクション（希望実施内容）やリソース状態を保持しているプロファイル３１０４に設定されているデータの参照結果として、アプリケーションＸ ３１０３に対するアラーム処理要求は不適当であると判定して、アプリケーションＸ ３１０３に対して希望アクション（希望実施内容）の実施を要求するアラーム処理要求を行わなかった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して事前登録されている当該希望アクション（希望実施内容）の強制的な削除を指示するための強制削除フラグが設定される。該強制削除フラグが設定されているアラーム発生応答パケットを受け取った装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、必ず、当該希望アクション（希望実施内容）の削除を実施しなければならない。なお、プロファイル３１０４に設定されているデータの詳細については後述する。
【０１４１】
アラーム発生応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において既に発行されている承認キーが設定される。
【０１４２】
図５のシーケンスチャートに戻って、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生応答パケットを受け取ると、該アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドを確認し、実施要求していた希望アクション（希望実施内容）の実施が成功したか否かを確認する。希望アクション（希望実施内容）の実施が成功していた場合には、使用するリソースの割当状況に変化が生じているものと看做すことができるが、実施が失敗していた場合には、さらに、データ領域にあるアラーム応答内容内の強制削除フラグフィールドを参照して強制削除フラグが設定されているか否かを確認する。
【０１４３】
強制削除フラグが設定されていた場合には、前述したように、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、事前登録・削除要求パケットを送信して、事前登録していた希望アクション（希望実施内容）を削除しなければならない。
【０１４４】
かくのごとき事前登録の希望アクション（希望実施内容）の強制的な削除処理を実行する目的は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側において、実施が失敗になってしまうようなアラーム処理要求をアプリケーションＸ ３１０３に対していつまでも送信し続けることがないように、該希望アクション（希望実施内容）の実施を要求するアラーム発生通知パケットを、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から送信する動作を抑止するためである。つまり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、何回も繰り返して、実施することが出来ない希望アクション（希望実施内容）の実施を要求するアラーム発生通知パケットが送信されることによる輻輳を防止するためである。
【０１４５】
受け取ったアラーム発生応答パケットの処理を終了すると、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム発生応答パケットを正常に受け取ったことを示すアラーム発生応答ＡＣＫを、図１２に示すアラーム発生応答ＡＣＫパケットとして、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信する（シーケンスＳ５００９）。
【０１４６】
図１２は、図３のリソース管理システムにおいてアラーム発生応答パケットを受け取ったネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信されるアラーム発生応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【０１４７】
ここで、図１２に示すアラーム発生応答ＡＣＫパケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、アラーム発生応答パケットの送信元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信することによって、アラーム発生応答パケットを正常に受け取った旨を通知するために用いられる。
【０１４８】
具体的には、図１２に示すアラーム発生応答ＡＣＫパケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、応答結果、閾値種別、強制削除結果、予約からなるアラームＡＣＫが設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生応答パケットを正常に受け取った旨を示すアラーム発生応答ＡＣＫパケットである旨を示す表示が設定される。
【０１４９】
つまり、前述の表２に示すように、アラーム発生応答ＡＣＫパケットのヘッダ情報内のシーケンス番号フィールドは、図１０に示したアラーム発生通知パケットの場合と同様、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１において、イベントが発生する都度、インクリメントされる番号であり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１へ送信したパケットの送信順を示している。
【０１５０】
また、アラーム発生応答ＡＣＫパケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図１０に示したアラーム発生通知パケットにより送信した閾値種別がそのまま設定され、装置Ａｎ ３０ｎ０の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
【０１５１】
また、アラーム発生応答ＡＣＫパケットのデータ領域にあるアラームＡＣＫ内の応答結果フィールドには、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においても、アラーム発生応答パケットのアラーム応答内容、すなわち、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において実施された処理内容を正しく認識することができたか否かを示す情報が設定される。
【０１５２】
また、アラーム発生応答ＡＣＫパケットのデータ領域にあるアラームＡＣＫ内の強制削除結果フィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からの指示通りに、事前登録した希望アクション（希望実施内容）を強制削除することができたか否かを示す情報が設定される。なお、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム発生応答パケットに強制削除フラグが設定されていなかった場合には、アラームＡＣＫ内の強制削除結果フィールドには無効なデータが設定された状態になっている。
【０１５３】
アラーム発生応答ＡＣＫパケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において既に発行されている承認キーが設定される。
【０１５４】
なお、図５のシーケンスＳ５００８において、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から、アラーム発生通知パケットを送信した後、あらかじめ定めた時間閾値を経過しても、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生応答パケットを受信することができなかった場合には、応答待ちタイムアウトが発生したものとして、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知パケットを再度送信する動作を行うようにしても良い。
【０１５５】
次に、図３のリソース管理システムに示したリソース管理サーバ３１００と管理対象のネットワーク装置である装置Ａｎ ３０ｎ０との間の通信シーケンスについて、装置Ａｎ ３０ｎ０において使用するリソースがリソース閾値を超えたりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置Ａｎ ３０ｎ０からリソース管理サーバ３１００に対して送信する際のシーケンスについて、図５とは異なる例を、図６を用いて説明する。
【０１５６】
図６は、図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの図５とは異なる例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置Ａ１ ３０１０ないし装置Ａｎ ３０ｎ０のうち、いずれかのネットワーク装置例えば第ｎ番目の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００に対してアラーム処理要求が送信されて、事前に設定登録されていた希望アクション（希望実施内容）を実施する際の処理シーケンスの他の例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、事前登録された希望アクション（希望実施内容）とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションＸ ３１０３を駆動して、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２に対してアラーム処理要求を送信することによって、アプリケーションＡｍ ３０ｍ２を駆動して、装置Ａｍ ３０ｍ０の閉塞状態を解除させる装置Ａｍ ３０ｍ０側のコマンドを実施する場合のシーケンス例について示している。以下においては、図６のシーケンスで示す一連の処理を「アラーム処理２」と称することにする。
【０１５７】
図６のシーケンスチャートにおいて、シーケンスＳ６００１〜Ｓ６００３までのシーケンスおよびシーケンスＳ６００７〜Ｓ６００９までのシーケンスは、それぞれ、図５のシーケンスチャートＳ５００１〜Ｓ５００３までのシーケンスおよびシーケンスＳ５００７〜Ｓ５００９までのシーケンスと全く同様であるので、ここでの重複する説明は省略する。
【０１５８】
図６のシーケンスＳ６００４において、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、シーケンスＳ６００３において認証管理３１０２から認証応答として返送されてきた装置Ａｎ ３０ｎ０の認証結果を受け取ると、該認証結果がＮＧであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。
【０１５９】
一方、該認証結果がＯＫであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション（希望実施内容）を参照して、実施すべきアクション（処理内容）を決定する。
【０１６０】
決定されたアクション（処理内容）が、例えば、アプリケーションＸ ３１０３を駆動して、図５のシーケンスＳ５００４の場合とは異なり、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２の輻輳状態を解決するために、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２のＴｅｌｎｅｔサーバに対してリソース管理サーバ３１００のＴｅｌｎｅｔクライアントが接続を要求して、ＣＬＩ（Command Line Interface）を用いて装置Ａｍ ３０ｍ０側のコマンドを実施するアラーム処理要求であった場合には、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、アプリケーションＸ ３１０３を駆動して、アラーム処理要求として、決定したアクション（処理内容）にしたがった処理の実施を要求する（シーケンスＳ６００４）。
【０１６１】
駆動されたアプリケーションＸ ３１０３は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２のＴｅｌｎｅｔサーバに対してリソース管理サーバ３１００のアプリケーションＸ ３１０３のＴｅｌｎｅｔクライアントが接続を要求して、ＣＬＩ（Command Line Interface）のコマンドラインインタフェースを用いて、装置Ａｍ ３０ｍ０側のコマンドを実施する動作、を起動する。
【０１６２】
この動作が起動されると、アプリケーションＸ ３１０３は、事前登録された希望アクション（希望実施内容）の中から決定した希望アクション（希望実施内容）にしたがった実施処理結果として、例えば、装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２のＴｅｌｎｅｔサーバに対してリソース管理サーバ３１００のＴｅｌｎｅｔクライアントが接続を要求して、ＣＬＩ（Command Line Interface）のコマンドラインインタフェースを用いて、装置Ａｍ ３０ｍ０側のコマンドを実施するというアラーム処理要求を送信する（シーケンスＳ６００５）。
【０１６３】
装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２は、決定した事前登録の希望アクション（希望実施内容）にしたがったアラーム処理要求例えばＣＬＩ（Command Line Interface）を用いて装置Ａｍ ３０ｍ０側のコマンドを実施するというアラーム処理要求をリソース管理サーバ３１００のアプリケーションＸ ３１０３から受け取ると、事前登録の希望アクション（希望実施内容）にしたがった処理例えばリソース管理サーバ３１００のＴｅｌｎｅｔクライアントからのＣＬＩ（Command Line Interface）を用いた要求に該当する装置Ａｍ ３０ｍ０側のコマンドをＴｅｌｎｅｔサーバとして実施して（例えば、装置Ａｍ ３０ｍ０の閉塞状態を解除して）、事前登録の希望アクション（希望実施内容）の実施結果例えばコマンドの実行結果を、リソース管理サーバ３１００のアプリケーションＸ ３１０３に対して返送する（シーケンスＳ６００６）。
【０１６４】
かくのごとく、輻輳状態に陥ってアラーム発生通知の送信元となっていた装置Ａｎ ３０ｎ０とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２においてコマンドを実行することによって、例えば、装置Ａｍ ３０ｍ０の閉塞状態を解除して、アラーム処理要求元の装置Ａｎ ３０ｎ０側の負荷の一部を分担することが可能になる。
【０１６５】
次に、図５のシーケンスＳ５００５において、アラーム発生応答パケットの強制削除フラグを設定するか否かを判別するために、つまり、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１がアプリケーションＸ ３１０３への実施要求が適当か否かを判定して、該判定結果に基づいてアプリケーションＸ ３１０３に対して希望アクション（希望実施内容）の実施を要求するか否かを判別するために、参照されるプロファイル３１０４のデータについて、次の表３を用いて詳細に説明する。
【０１６６】
【表３】
【０１６７】
表３に示すプロファイル３１０４は、前述のように、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１内に保持されているネットワーク全体のリソース管理に関するデータベースであり、ネットワークを構成する各ネットワーク装置から事前登録されている希望アクション（希望実施内容）を実施履歴や各ネットワーク装置のリソース状態とともに保持している。つまり、プロファイル３１０４は、表３に示すように、承認キー３０１、承認先ＩＰアドレス／プレフィックス３０２、本登録キー３０３、希望優先度３０４、指示対象名３０５、実施回数３０６、開始時刻３０７、希望実施内容３０８、登録完了時刻３０９、現在の状態３１０を少なくとも有して構成されている。さらに、本登録キーごとにそれぞれのアクション（処理内容）の実施履歴として、項番３１１、実施結果３１２、開始時刻３１３、完了時刻３１４を有して構成されている。
【０１６８】
表３に示すプロファイル３１０４の設定例においては、承認キー３０１、承認先ＩＰアドレス／プレフィックス３０２および希望実施内容３０８に示すように、承認先ＩＰアドレス／プレフィックス３０２が'Ａ，Ｂ，Ｃ，Ｄ／Ｐ'のネットワーク装置の装置Ａｎ ３０ｎ０からの事前登録処理により、承認キー３０１が'3fe9105a'として登録された２つの希望実施内容（本登録キー３０３が'０００００００１'および'０００００００２'の２つ）が設定され、承認先ＩＰアドレス／プレフィックス３０２が'Ｗ，Ｘ，Ｙ，Ｚ／Ｐ'のネットワーク装置の装置Ａｍ ３０ｍ０からの事前登録処理により、承認キー３０１が'3fe9105b'として登録された２つの希望実施内容（本登録キー３０３が'０００００００３'および'０００００００４'の２つ）が設定されている例が示されている。
【０１６９】
ここで、表３に示すプロファイル３１０４の承認キー３０１、本登録キー３０３、希望優先度３０４、指示対象名３０５、実施回数３０６、開始時刻３０７、希望実施内容３０８、実施結果３１２のそれぞれのデータについては、図７の事前登録・削除要求パケット、図８の事前登録・削除応答パケット、図９の事前登録・削除応答ＡＣＫパケット、図１０のアラーム発生通知パケット、図１１のアラーム発生応答パケット、および、図１２のアラーム発生応答ＡＣＫパケットの内容が反映される。
【０１７０】
また、表３に示すプロファイル３１０４の承認先ＩＰアドレス／プレフィックス３０２、および、登録完了時刻３０９については、図４の事前登録・削除処理のシーケンス処理中において、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が認識することにより設定することができる。
【０１７１】
また、表３に示すプロファイル３１０４の現在の状態３１０、および、実施履歴の項番３１１については、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１による監視結果として決定して設定することができる。
【０１７２】
また、表３に示すプロファイル３１０４の実施履歴の開始時刻３１３、および、完了時刻３１４については、図５のアラーム処理１のシーケンスにおけるシーケンスＳ５００４（アプリケーションＸ ３１０３へのアラーム処理要求を行うシーケンス）、および、シーケンスＳ５００７（アプリケーションＸ ３１０３から実施結果を受け取るシーケンス）や、あるいは、図６のアラーム処理２のシーケンスにおけるシーケンスＳ６００４（アプリケーションＸ ３１０３へのアラーム処理要求を行うシーケンス）、および、シーケンスＳ６００７（アプリケーションＸ ３１０３から実施結果を受け取るシーケンス）によって、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が認識して設定することができる。
【０１７３】
ここで、現在の状態３１０は、本登録キーごとに'待ち'、'実行中'、'完了'、'失敗'の４つの状態が存在する。'完了'の後は、'待ち'の状態に遷移する。'待ち'の後は、'実行中'の状態に遷移する。'失敗'の後は、'待ち'の状態に遷移するか、あるいは、強制削除によって、当該本登録キー自体が削除される。表３に示す例においては、本登録キー'０００００００４'の場合が、現在の状態３１０に示すように、'失敗'の状態になっている。
【０１７４】
かくのごとく、現在の状態３１０が'失敗'の状態にある場合に、次の状態として'待ち'の状態に遷移するか、あるいは、強制削除するかは、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において適宜判別される。例えば、当該本登録キーで特定される希望アクション（希望実施内容）の実施回数があらかじめ定めた回数閾値に達するまでは、'待ち'の状態に移行し、実施回数が該回数閾値以上に及んで何回も'失敗'を繰り返している場合には、当該本登録キーで特定される希望アクション（希望実施内容）は、強制的に削除することにしても良い。
【０１７５】
なお、プロファイル３１０４から希望アクション（希望実施内容）のデータの削除を行う場合には、図４の事前登録・削除処理のシーケンスにしたがって、当該本登録キーの希望アクション（希望実施内容）を事前登録したネットワーク装置例えば装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１との間で、希望アクション（希望実施内容）の削除処理を実施することになるが、当該本登録キーを主キーとしてプロファイル３１０４のデータを参照して削除することが可能である。
【０１７６】
また、表３に示すプロファイル３１０４の実施結果３１２には、'成功'、'失敗'、および、'実行中'の３つの結果が存在する。実施結果３１２が'実行中'の場合には、現在の状態３１０も'実行中'の状態にあり、実施結果３１２が'失敗'の場合には、現在の状態３１０も'失敗'かまたは'待ち'の状態になり、実施結果３１２が'成功'の場合には、現在の状態３１０は'完了'かまたは'待ち'の状態になる。
【０１７７】
以上のように、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、プロファイル３１０４としてネットワークを構成する各ネットワーク装置に関する各種のデータを保持しているので、送信先ＩＰアドレスの払い出しや希望アクション（希望実施内容）の実行優先度付けを適宜行うことが可能である。
【０１７８】
このようにして、本実施形態においては、各ネットワーク装置例えば例えば装置Ａｎ ３０ｎ０から、リソース不足時に実施してもらいたい希望アクション（希望実施内容）をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側に事前登録し、かつ、実際にリソース不足が発生した際に、事前登録した希望アクション（希望実施内容）の実施を要求するアラーム発生通知をネットワーク装置側からリソース管理サーバ３１００に対して送信し、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側において、事前登録された希望アクション（希望実施内容）の実施の可否判断をプロファイル３１０４に基づいて行っている。
【０１７９】
したがって、従来技術におけるＳＮＭＰ Ｔｒａｐメッセージ（トラップメッセージ）などとは異なり、アラームの発生をリソース管理サーバ３１００に対して通報するだけではなく、アラーム発生通知に基づいて、事前登録の希望アクション（希望実施内用）としてあらかじめ登録された処理を実施させることができ、多数のネットワーク装置のリソース管理とアクション処理の管理とを一元化することができる。
【０１８０】
（実施形態の具体的構成例）
以上に説明した本発明に係るリソース管理システムのシステム構成について、例えば、ネットワーク装置として呼処理装置を対象とした場合の構成例を、図１３に示す。図１３は、本発明に係るリソース管理システムの具体的なシステム構成の一例を示すシステム構成図であり、呼処理ネットワークにおけるシステム構成例を示しており、図１の場合とは異なり、ネットワーク装置として呼処理装置を対象とし、該呼処理装置が呼処理の制御対象とするユーザ端末装置とネットワークを介して接続されている様子を示している。
【０１８１】
図３のシステム構成において、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０，呼処理装置Ａ３ １３０３０は、図３におけるネットワーク装置例えば装置Ａｎ ３０ｎ０と同様、それぞれ、リソース管理Ａｇｅｎｔ（リソース管理エージェント）を備えており、管理ネットワーク１３２００を介して、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）を備えているリソース管理サーバ１３１００と通信を行うことによって、リソースの管理を行っている。
【０１８２】
また、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０は、それぞれ、呼処理の制御対象となるユーザ端末群１３００１，ユーザ端末群１３００２とネットワーク１３３００を介して接続されている。ここで、現時点においては、ユーザ端末群１３００１，ユーザ端末群１３００２の端末数が、それぞれ、既に、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０それぞれに収容可能な端末数の最大限界値近くの端末数に達しているものと仮定する。一方、呼処理装置Ａ３ １３０３０は、管理ネットワーク１３２００およびネットワーク１３３００に接続されてオンライン状態になっているものの、呼処理の制御対象となるユーザ端末が存在していなく、ＶＬＡＮ（Virtual Local Area Network）機能を閉塞している状態になっているものと仮定する。
【０１８３】
また、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０は、それぞれ、図４の事前登録・削除要求処理のシーケンスにしたがって、リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に対して、収容端末数が収容可能端末数を超える場合には、収容端末数が少ない呼処理装置に呼処理を実施してもらいたいという希望アクション（希望実施内容）を事前登録しているものと仮定する。
【０１８４】
具体的には、収容端末数が収容可能端末数を超える場合には、図６に示したアラーム処理２のシーケンスにおいて説明したように、リソース管理サーバ１３１００側のＴｅｌｎｅｔクライアントから収容端末数が少ない呼処理装置側のＴｅｌｎｅｔサーバへＴｅｌｎｅｔ接続して、ＣＬＩ（Command Line Interface）によるコマンドを実行させることによって、ＣＬＩ上から割り出した呼処理装置のＶＬＡＮ機能の閉塞状態を解除させて、呼処理を実行できるようにしたり、あるいは、リソース確保のために必要とする装置設定を行うようなコマンドを投入したりすることを要求する希望アクション（希望実施内容）が事前登録されている。
【０１８５】
また、リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）は、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０，呼処理装置Ａ３ １３０３０の希望アクション（希望実施内容）を、図７に示した事前登録・削除要求パケットによって受け取って、表３に示したようなプロファイルとして保持して管理している。
【０１８６】
（実施形態の具体的構成例の動作の説明）
次に、図１３に示した具体的なシステム構成例における動作の一例を、図１３を用いてさらに説明する。
【０１８７】
図１３のシステム構成例において、前述したように、ユーザ端末群１３００１，ユーザ端末群１３００２の端末数が、それぞれ、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０それぞれの収容可能端末数の最大限界値近くの端末数に既に達している状態にある。
【０１８８】
かかる状態において、さらに、新しいユーザ端末群１３００３に対して呼処理サービスを提供し始めた場合、例えば、呼処理装置Ａ１ １３０１０によって新しいユーザ端末群１３００３に対する呼処理を実施しようとした場合には、呼処理装置Ａ１ １３０１０のリソースがあらかじめ定めたリソース閾値を超えてしまうため、呼処理装置Ａ１ １３０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）は、図１０に示したようなアラーム発生通知パケットをリソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に対して送信して、事前登録されている希望アクション（希望処理要求）の実施を要求する。すなわち、収容可能端末数を超えるユーザ端末の呼処理を収容端末数が少ない呼処理装置によって実行することを要求する。
【０１８９】
リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）側においては、呼処理装置Ａ１ １３０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）からのアラーム発生通知パケットを受け取ると、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０，呼処理装置Ａ３ １３０３０に関するプロファイルのデータを参照して、収容端末数が最も少ない呼処理装置が、呼処理装置Ａ３ １３０３０であることを判別する。
【０１９０】
その結果、リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）は、図６に示したアラーム処理２のシーケンスにしたがって、シーケンスＳ６００４において、例えば、アプリケーションＸのＴｅｌｎｅｔクライアントからのＴｅｌｎｅｔ通信によって、収容端末数が最も少ない呼処理装置Ａ３ １３０３０のＶＬＡＮ機能の閉塞状態を解除させて、呼処理を実施できるようにし、新しいユーザ端末群１３００３に対して呼処理サービスを提供することができる状態に設定する。
【０１９１】
以上のように、各呼処理装置からの事前登録要求に基づいてそれぞれの希望アクション（希望実施内容）をプロファイルとして事前登録することによって、該プロファイルに基づいてリソース管理を行うことを可能にし、適切な収容端末数の割当を自動的に行うことが可能になる。
【０１９２】
（本実施形態の効果の説明）
以上に詳細に説明したように、本実施形態においては、以下に記載するような効果を奏することができる。
【０１９３】
第１の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション（処理実施内容）をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。
【０１９４】
第２の効果は、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）は、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション（処理実施内容）を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション（希望処理実施内容）を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。
【０１９５】
第３の効果は、ネットワークのリソースを管理するリソース管理サーバは、管理対象のネットワーク装置であるか否かを認証する仕組みを採用しているので、不正なネットワーク装置からのアクセスを確実に抑止して、不正なネットワーク装置によるリソース管理への悪影響を確実に防止することができることである。
【０１９６】
（本発明の他の実施形態）
次に、本発明の他の実施形態として、リソース管理システムの基本的構成は、前述した実施形態の場合と同様であるが、多階層のリソース管理を実現する場合の構成例について図１４を用いて説明する。図１４は、本発明によるリソース管理システムのシステム構成の図１とは異なる例を示すシステム構成図であり、ネットワーク全体のリソースを管理するリソース管理サーバが、多階層化（図１４の例においては２階層化）されて構成されている例を示している。つまり、本実施形態においては、多階層のリソース管理を実現するために、図１４に示すように、リソース管理Ａｇｅｎｔ（リソース管理エージェント）とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）とを併せ持つリソース管理サーバを設置している。
【０１９７】
図１４のシステム構成に示すように、最上位のリソース管理サーバＣ １４１００の配下に、下位層のリソース管理サーバＡ １４２１０とリソース管理サーバＢ １４３１０とが分散配置されており、最上位のリソース管理サーバＣ １４１００は、下位層のリソース管理サーバＡ １４２１０とリソース管理サーバＢ １４３１０とのリソースを管理する。また、リソース管理サーバＣ １４１００とリソース管理サーバＡ １４２１０およびリソース管理サーバＢ １４３１０との間は、管理ネットワークＣ １４４１０を介して接続される。
【０１９８】
最上位のリソース管理サーバＣ １４１００は、下位層のリソース管理サーバＡ １４２１０とリソース管理サーバＢ １４３１０とのリソースを管理するために、前述の図３に示したリソース管理サーバ３１００の場合と同様、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４１０１を備えている。一方、下位層のリソース管理サーバＡ １４２１０は、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４２１１とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４２０１との双方を備え、同様に、リソース管理サーバＢ １４３１０も、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４３１１とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４３０１との双方を備えている。
【０１９９】
下位層のリソース管理サーバＡ １４２１０のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４２０１は、管理ネットワークＡ １４４２０を介して、管理対象のネットワーク装置として、装置Ａ１ １４５００と装置Ａ２ １４６００とを対象にしてリソース管理を実施する。このため、装置Ａ１ １４５００と装置Ａ２ １４６００とには、前述の図３に示した装置Ａｎ ３０ｎ０の場合と同様、それぞれ、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４５１０とリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４６１０とを備えている。
【０２００】
同様に、下位層のリソース管理サーバＢ １４７００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４３０１は、管理ネットワークＢ １４４３０を介して、装置Ｂ１ １４７００と装置Ｂ２ １４８００を対象にしてリソース管理を実施する。このため、装置Ｂ１ １４７００と装置Ｂ２ １４８００とには、前述の図３に示した装置Ａｎ ３０ｎ０の場合と同様、それぞれ、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４７１０とリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４８１０とを備えている。
【０２０１】
つまり、最上位のリソース管理サーバＣ １４１００の管理ドメインは、リソース管理サーバＡ １４２１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４２１１とリソース管理サーバＢ １４３１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４３１１となる。
【０２０２】
下位層のリソース管理サーバＡ １４２１０の管理ドメインは、装置Ａ１ １４５００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４５１０と装置Ａ２ １４６００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４６１０となり、下位層のリソース管理サーバＢ １４３１０の管理ドメインは、装置Ｂ１ １４７００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４７１０と装置Ｂ２ １４８００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４８１０となる。
【０２０３】
かくのごとく、多階層のネットワークトポロジーにおけるリソース管理を行う場合、ネットワーク全体のリソースを管理するリソース管理サーバを多階層（図１４に示す例では２階層）に分散配置した構成とし、最上位のリソース管理サーバ以外の各階層のリソース管理サーバについては、リソース管理Ａｇｅｎｔ（リソース管理エージェント）とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）との双方を具備することにより、多階層のネットワークトポロジーにおいても、それぞれの階層ごとのリソース管理を迅速かつ確実に実施することが可能になる。
【０２０４】
以上、本発明の好適な実施形態の構成を説明した。しかし、かかる実施形態は、本発明の単なる例示に過ぎず、何ら本発明を限定するものではないことに留意されたい。本発明の要旨を逸脱することなく、特定用途に応じて種々の変形変更が可能であることが、当業者には容易に理解できよう。
【符号の説明】
【０２０５】
１１００ リソース管理サーバ
１１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１０１０ 装置Ａ１
１０ｎ０ 装置Ａｎ
１２００ ネットワーク
２０１０ 装置Ａ１
２０１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
２０ｎ０ 装置Ａｎ
２０ｎ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
２１００ リソース管理サーバ
２１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
３０ｍ０ 装置Ａｍ
３０ｍ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
３０ｍ２ アプリケーションＡｍ
３０ｎ０ 装置Ａｎ
３０ｎ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
３０ｎ２ アプリケーションＡｎ
３１００ リソース管理サーバ
３１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
３１０２ 認証管理
３１０３ アプリケーションＸ
３１０４ プロファイル
１３００１ ユーザ端末群
１３００２ ユーザ端末群
１３００３ ユーザ端末群
１３０１０ 呼処理装置Ａ１
１３０２０ 呼処理装置Ａ２
１３０３０ 呼処理装置Ａ３
１３１００ リソース管理サーバ
１３２００ 管理ネットワーク
１３３００ ネットワーク
１４１００ リソース管理サーバＣ
１４１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１４２０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１４２１０ リソース管理サーバＡ
１４２１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４３０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１４３１０ リソース管理サーバＢ
１４３１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４４１０ 管理ネットワークＣ
１４４２０ 管理ネットワークＡ
１４４３０ 管理ネットワークＢ
１４５００ 装置Ａ１
１４５１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４６００ 装置Ａ２
１４６１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４７００ 装置Ｂ１
１４７１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４８００ 装置Ｂ２
１４８１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１５０１０ 装置Ａ１
１５０１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１５０ｎ０ 装置Ａｎ
１５０ｎ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１５１００ リソース管理サーバ
１５１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
Ｒ１１ インタフェース
Ｒ１２ インタフェース
Ｒｎ１ インタフェース
Ｒｎ２ インタフェース
Ｒｎ３ インタフェース
Ｒｎ４ インタフェース
Ｒｎ５ インタフェース
Ｒｎ６ インタフェース
Ｒｎ７ インタフェース
Ｒｎ８ インタフェース
Ｒｎ９ インタフェース
Ｒｎ１０ インタフェース
Ｒｎ１１ インタフェース
Ｒｎ１２ インタフェース
ＡＣＫ１ インタフェース
ＡＣＫｍ インタフェース
ＡＣＫｎ インタフェース
【技術分野】
【０００１】
本発明は、リソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムに関する。
【背景技術】
【０００２】
インターネット等のネットワークは、呼処理装置、無線制御装置、ルータ、ハブ等のネットワーク装置を相互に接続して構成されている。ネットワークにおいては、所定の品質のサービスを実現するために、例えば、特許文献１の特開２００４−１４０８１４号公報「リソース管理システム」等に記載されているように、ネットワークの帯域や通信速度や通信経路等のネットワークリソース（以下、単に「リソース」と略称する）を確保し管理するリソース管理サーバが設置されている。
【０００３】
このようなネットワークのリソースを管理するリソース管理システムにおける現状のリソース不足検知機能について、図１５を参照して説明する。図１５は、ネットワークのリソースを管理するリソース管理システムにおける動作の一例を説明するための説明図である。
【０００４】
図１５において、ネットワーク全体のリソースを管理しているリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１５１０１は、リソースの管理対象のネットワーク装置である装置Ａ１ １５０１０，…，装置Ａｎ １５０ｎ０それぞれに対して、リソース不足の発生の有無を判別するためのアラーム閾値をあらかじめ設定している。そして、装置Ａ１ １５０１０，…，装置Ａｎ １５０ｎ０それぞれにおいて、使用するリソースがアラーム閾値を超えようとしていることを検知した際に、リソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ１５１０１に対してリソース不足が発生している旨をＳＮＭＰ(Simple Network Management Protocol)のＴｒａｐメッセージ（トラップメッセージ）を用いてアラーム通報する。
【０００５】
ここで、例えば、管理対象の各ネットワーク装置のうち、装置Ａ１ １５０１０がリソース不足になったものと仮定する。また、検知対象のリソースの例として、システム動作状況のロギングを収集する手段であるＳＹＳＬＯＧ（シスログ）動作に関するリソースを取り上げる。
【０００６】
装置Ａ１ １５０１０は、システム動作状況を監視しており、ＳＹＳＬＯＧ機能を用いて、ログファイルとして管理者に通報している。装置Ａ１ １５０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント：本実施例においてはＳＹＳＬＯＧ Ａｇｅｎｔ）１５０１１は、ＳＹＳＬＯＧ用のリソース不足を検知すると、アラーム通報用してあらかじめ設定されたＴｒａｐメッセージ（トラップメッセージ）を、インタフェースＲ１１経由で、管理ネットワークを介してリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ：本実施例においてはＳＹＳＬＯＧ Ｍａｎａｇｅｒ）１５１０１に送信することによって、リソースの管理を行っているリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ１５１０１に対してリソース不足の発生を通知する。
【０００７】
装置Ａ１ １５０１０からのＴｒａｐメッセージ（トラップメッセージ）を受け取ったリソース管理サーバ１５１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１５１０１は、装置Ａ１ １５０１０にリソース不足が発生している旨をアラーム画面として表示して管理者に通報する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−１４０８１４号公報（第５−８頁）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
図１５に示した現状のリソース管理システムの場合、リソース管理サーバ側から管理対象の各ネットワーク装置のアラーム閾値を設定することによってネットワーク全体のリソース管理を実施しているが、管理対象の各ネットワーク装置側から希望するアクション（処理実施内容）をリソース管理サーバ側へ依頼することによって、リソースの再配置を行って、ネットワーク全体のリソース状況を最適化するというものではなかった。つまり、前述のように、ＳＮＭＰ Ｔｒａｐメッセージを用いた監視方法は、単に、アラームを検知したことをリソース管理サーバ側に通知するのみであり、リソース不足を解消するために実施して欲しい具体的なアクション（処理実施内容）を通知して依頼することができないし、さらには、ネットワーク全体のリソース配分を最適化するために、他のネットワーク装置に対して具体的なアクション（処理実施内容）を実施させることもできなかった。したがって、アラームを検知しても、管理者が手動でアラーム内容を解析して適切と思われる処理を施すことが多かったため、本当に適切なリソース割当処理を実施するまでに時間がかかることが多かった。
【００１０】
このため、現状のリソース不足検知機能においては、次のような課題がある。
【００１１】
第１の課題は、リソース管理サーバのアラーム画面を、管理者が常に監視していることが必要であり、ヒューマンリソースが常に必要であるということにある。
【００１２】
第２の課題は、リソース管理サーバは、管理者が介在して、管理ネットワークの管理対象の各ネットワーク装置におけるリソースの配分状況をチェックして、リソース不足に対する処置を、リソース不足を解消させるための具体的な処理実施内容として管理対象の各ネットワーク装置に対して適切に施さないといけないため、リソースの再配置処理に時間がかかってしまうということにある。
【００１３】
第３の課題は、管理対象のネットワーク装置が異なると、リソース不足の発生形態例えばＳＹＳＬＯＧメッセージの内容が異なる可能性があるので、リソースを管理するリソース管理サーバ側としては、リソース不足のアラーム通知を受け取っても、リソース不足を解消させるために実施すべきアクション（処理実施内容）が各ネットワーク装置ごとに異なる可能性が大きく、実施すべきアクション（処理実施内容）を決定することが非常に厄介になるということにある。
【００１４】
（本発明の目的）
本発明は、かかる課題に鑑みてなされたものであり、リソース管理サーバ側と管理対象の各ネットワーク装置側とのネゴシエーションを行うことにより、ネットワーク全体のリソースの最適化を迅速かつ確実に行うことが可能なリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムを提供することを、その目的としている。
【００１５】
つまり、本発明は、管理対象のネットワーク装置においてリソース不足が発生した際に実施すべきアクション（処理実施内容）を、ネットワーク全体のリソースの管理を行うリソース管理サーバに対して管理対象のネットワーク装置から希望アクション（希望実施内容）としてあらかじめ事前登録しておくことによって、突然発生したリソース不足に対して、事前登録された希望アクション（希望実施内容）にしたがって、最適なリソースの再配置を自動的にかつ短時間に実施する仕組みを提供することを、その目的としている。
【課題を解決するための手段】
【００１６】
前述の課題を解決するため、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムは、主に、次のような特徴的な構成を採用している。
【００１７】
（１）本発明によるリソース管理システムは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えたリソース管理システムにおいて、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。
【００１８】
（２）本発明によるリソース管理サーバは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバにおいて、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録しておき、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。
【００１９】
（３）本発明によるネットワーク装置は、ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置において、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信することを特徴とする。
【００２０】
（４）本発明によるリソース管理方法は、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えることにより、ネットワーク全体のリソース状態を管理するリソース管理方法であって、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。
【００２１】
（５）本発明によるリソース管理プログラムは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバに、プログラムを実行可能なコンピュータを備え、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションをプロファイルとして各前記ネットワーク装置のリソース状態とともに事前に登録するステップと、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うステップと、を前記コンピュータによりプログラムとして実行することを特徴とする。
【００２２】
（６）本発明による別のリソース管理プログラムは、ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置に、プログラムを実行可能なコンピュータを備え、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記ソース管理サーバに事前に登録するステップと、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信するステップと、を前記コンピュータによりプログラムとして実行することを特徴とする。
【発明の効果】
【００２３】
本発明のリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムによれば、以下のような効果を奏することができる。
【００２４】
第１の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション（処理実施内容）をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。
【００２５】
第２の効果は、リソース管理サーバは、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション（処理実施内容）を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション（希望処理実施内容）を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。
【図面の簡単な説明】
【００２６】
【図１】本発明によるリソース管理システムのシステム構成の一例を示すシステム構成図である。
【図２】図１のリソース管理システムにおけるリソース管理サーバおよび各ネットワーク装置の装置構成の一例を説明するための説明図である。
【図３】図１のリソース管理システムにおけるリソース管理サーバと各ネットワーク装置との間のリソース管理に関するインタフェースの一例を説明するための説明図である
【図４】図３のリソース管理システムにおける希望アクションの事前登録シーケンスおよび希望アクションの削除シーケンスの一例を示すシーケンスチャートである。
【図５】図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの一例を示すシーケンスチャートである。
【図６】図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの図５とは異なる例を示すシーケンスチャートである。
【図７】図３のリソース管理システムにおいてネットワーク装置からリソース管理サーバに対して送信される事前登録・削除要求パケットのフォーマットの一例を示すテーブルである。
【図８】図３のリソース管理システムにおいてリソース管理サーバから事前登録・削除要求元のネットワーク装置に対して送信される事前登録・削除応答パケットのフォーマットの一例を示すテーブルである。
【図９】図３のリソース管理システムにおいて事前登録・削除応答パケットを受け取ったネットワーク装置からリソース管理サーバに対して送信される事前登録・削除応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【図１０】図３のリソース管理システムにおいてアラーム発生元のネットワーク装置からリソース管理サーバに対して送信されるアラーム発生通知パケットのフォーマットの一例を示すテーブルである。
【図１１】図３のリソース管理システムにおいてリソース管理サーバからアラーム発生通知パケットの送信元のネットワーク装置に対して送信されるアラーム発生応答パケットのフォーマットの一例を示すテーブルである。
【図１２】図３のリソース管理システムにおいてアラーム発生応答パケットを受け取ったネットワーク装置からリソース管理サーバに対して送信されるアラーム発生応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【図１３】本発明に係るリソース管理システムの具体的なシステム構成の一例を示すシステム構成図である。
【図１４】本発明によるリソース管理システムのシステム構成の図１とは異なる例を示すシステム構成図である。
【図１５】ネットワークのリソースを管理するリソース管理システムにおける動作の一例を説明するための説明図である。
【発明を実施するための形態】
【００２７】
以下、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムの好適な実施形態について添付図を参照して説明する。なお、以下の説明においては、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置およびリソース管理方法について説明するが、かかるリソース管理方法をコンピュータにより実行可能なリソース管理プログラムとして実施するようにしても良いし、あるいは、リソース管理プログラムをコンピュータにより読み取り可能な記録媒体に記録するようにしても良いことは言うまでもない。
【００２８】
（本発明の特徴）
本発明の実施形態の説明に先立って、本発明の特徴についてその概要をまず説明する。本発明は、ネットワーク全体のリソースの管理を行うリソース管理サーバにおいて、管理対象のネットワーク装置がリソース不足になった場合に、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）が実施すべきアクション（処理実施内容）を、管理対象の各ネットワーク装置のリソース管理Ａｇｅｎｔ（リソース管理エージェント）それぞれからリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）へあらかじめ事前登録しておくことにより、リソース管理サーバ側から、管理対象のネットワーク装置の運用状況を考慮した適切なリソース割当とアクションの実施とを可能にしていることを主要な特徴としている。
【００２９】
つまり、本発明は、管理対象のネットワーク装置がリソース不足に陥った時に、当該ネットワーク装置側が希望するアクション（処理実施内容）をリソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に事前登録しておくことにより、実際にリソース不足が発生した際に、当該リソース不足を解消させるための最適なアクション（処理実施内容）を速やかに、滞りなく実施することができ、リソースの最適割当を迅速に行うことができるようになっている。
【００３０】
また、本発明は、他のネットワーク装置のリソース使用状況、つまり、管理ネットワーク全体のリソース使用状況をも考慮して、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）が実施すべきアクション（処理実施内容）を判断することができるように、ネットワーク全体の各ネットワーク装置からの希望アクション（希望実施内容）を、各ネットワーク装置のリソース状態とともにプロファイルとしてあらかじめ設定し、リソース不足に陥ったネットワーク装置側が事前登録したアクション（処理内容）を実施することが適切か否かを判断することができる処理シーケンスを採用している。
【００３１】
さらに、本発明は、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に対してアクセスしてきたネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証する仕組みを採用しており、不正なネットワーク装置によってリソース管理への悪影響を防止するようにしている。例えば、不正なネットワーク装置が、リソース管理サーバが管理対象としている他のいずれかのネットワーク装置をシャットダウンさせるようなコマンドの実行を事前登録しておいて、リソース不足を示すアラーム発生通知をリソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に送信してくるようなことがあると、事前登録されているアクション（他のいずれかのネットワーク装置をシャットダウンさせる処理内容）が実施されてしまって、ネットワークのリソース管理を適切に実施することができなくなるので、リソース不足時のアクションを事前登録するネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証するようにしている。
【００３２】
（本発明の実施形態）
次に、本発明の実施形態について図を参照しながら詳細に説明する。本発明の実施形態は、図１に示すように、ネットワーク全体のリソースを管理するリソース管理サーバと、リソースの管理対象となる呼処理装置や無線制御装置やルータやハブ等のネットワーク装置と、リソース管理サーバと各ネットワーク装置との間を接続する管理ネットワークと、からなるリソース管理システムに関するものであり、前述したように、管理対象のネットワーク装置がリソース不足になった場合に、ネットワーク全体の運用状況を考慮して、リソース管理サーバ側から適切なリソース割当とアクションの実施とを可能にしている。図１は、本発明によるリソース管理システムのシステム構成の一例を示すシステム構成図である。
【００３３】
図１に示すリソース管理システムは、ネットワーク全体のリソースを管理するリソース管理サーバ１１００、リソースの管理対象となる１ないし複数のネットワーク装置に相当する装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０、および、ＳＮＭＰ(Simple Network Management Protocol)プロトコルを用いた管理ネットワークであるネットワーク１２００によって構成されている。
【００３４】
図１において、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０は、それぞれ、リソース管理サーバ１１００に対して、ネットワーク１２００を介して、あらかじめ定めた周期やリソースの使用状況に変化が発生する都度、自装置のリソース状況を通知している。リソース管理サーバ１１００は、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０それぞれのリソース使用状況を、ネットワーク１２００を介して受信して、ネットワーク１２００全体のリソースの使用状況をプロファイルとして保持して管理している。
【００３５】
次に、図１のリソース管理システムにおける装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０およびリソース管理サーバ１１００のリソース管理に関する部位について、その一例を、図２を用いて説明する。図２は、図１のリソース管理システムにおけるリソース管理サーバ１１００および各ネットワーク装置すなわち装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０の装置構成の一例を説明するための説明図であり、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０とリソース管理サーバ１１００とにおける各リソース管理用の機能部と、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０とリソース管理サーバ１１００との間のインタフェースについて示している。
【００３６】
なお、図２には、図１のリソース管理サーバ１１００、装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０を、それぞれ、リソース管理サーバ２１００、装置Ａ１ ２０１０，…，装置Ａｎ ２０ｎ０と、千番台の符号を図番号に対応する形で変更して示している。また、以下の各図面においても、同様に、符号を図番号に対応する形で変更している。
【００３７】
図２において、装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、それぞれ、自装置のリソース状況を保持している。また、装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定している。
【００３８】
装置Ａ２ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、それぞれに設定した該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、インタフェースＲ１１ないしインタフェースＲｎ１を経由して、図１に示したネットワーク１２００を介して、リソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１に対してアラーム発生通知を行い、あらかじめ事前登録しておいた希望アクション（希望実施内容）の実施を要求する。
【００３９】
リソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１は、装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理（リソースの再割当処理等）を実施して、実施結果を示す応答（アラーム発生応答）を、アラーム発生通知元の装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１に対して、それぞれ、インタフェースＲ１２ないしインタフェースＲｎ２を経由して、図１に示したネットワーク１２００を介して返送する。
【００４０】
装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１ないし装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１は、リソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１からの応答（アラーム発生応答）を受け取ると、該応答を正常に受信した旨を示す応答ＡＣＫを生成して、それぞれ、インタフェースＡＣＫ１ないしインタフェースＡＣＫｎを経由して、図１に示したネットワーク１２００を介して、リソース管理サーバ ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１に対して返送する。
【００４１】
次に、図１のリソース管理システムにおけるリソース管理サーバ１１００のリソース管理に関する部位と管理対象のネットワーク装置である装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０との間のさらに詳細なインタフェースについて、その一例を、図３を用いて説明する。図３は、図１のリソース管理システムにおけるリソース管理サーバ１１００と各ネットワーク装置すなわち装置Ａ１ １０１０，…，装置Ａｎ １０ｎ０との間のリソース管理に関するインタフェースの一例を説明するための説明図であり、装置Ａ１ １０１０ないし装置Ａｎ １０ｎ０のうち、第ｍ番目と第ｎ番目の装置を取り出して、リソース管理サーバ１１００のリソース管理用の機能部と、管理対象のネットワーク装置である装置Ａｍ １０ｍ０、装置Ａｎ １０ｎ０との間のリソース管理に関する全インタフェースについて示している。
【００４２】
なお、図３においても、前述したように、図１のリソース管理サーバ１１００、装置Ａｍ １０ｍ０、装置Ａｎ １０ｎ０を、それぞれ、リソース管理サーバ３１００、装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０と、千番台の符号を図番号に対応する形で変更して示している。また、図２のリソース管理サーバ２１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）２１０１についても、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１と、千番台の符号を図番号に対応する形で変更している。
【００４３】
さらに、図２の装置Ａ１ ２０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０１１、装置Ａｎ ２０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）２０ｎ１についても、それぞれ、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１と、千番台の符号を図番号に対応する形で変更して示している。
【００４４】
図３においても、図２の場合と同様、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理（リソースの割当処理）を実施して、実施結果を示す応答（アラーム発生応答）を、アラーム発生通知元の装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信している。
【００４５】
また、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、図２の場合と同様、それぞれ、自装置のリソース状況を保持している。さらに、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定し、該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知の送信を行っている。
【００４６】
図３に示すように、リソース管理サーバ３１００は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に、管理対象の各ネットワーク装置である装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０ごとに、それぞれのリソース管理に関する情報（希望アクション（希望する処理実施内容）、処理開始時刻、処理実施履歴、リソース状況等）を登録保持しているデータベースとしてプロファイル３１０４を所持している他、アクセスしてくる各ネットワーク装置例えば装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０の認証を行う認証管理３１０２、リソース管理に関するアプリ処理を実行するアプリケーションＸ ３１０３の各機能部を有している。また、装置Ａｍ ３０ｍ０、装置Ａｎ ３０ｎ０にも、それぞれ、リソース管理に関するアプリ処理を実行するアプリケーションＡｍ ３０ｍ２、アプリケーションＡｎ ３０ｎ２、の機能部を有している。
【００４７】
図３に示す各機能部および各機能部間のインタフェースに関する説明を、次の表１に示している。
【００４８】
【表１】
【００４９】
装置Ａｎ ３０ｎ０、装置Ａｍ ３０ｍ０は、いずれも、前述したように、リソース管理サーバ３１００のリソース管理対象となるネットワーク装置であり、図３においては、装置Ａｎ ３０ｎ０にリソース不足が発生して、装置Ａｎ ３０ｎ０からリソース管理サーバ３１００に対してアラーム発生通知を送信した場合に、ネットワーク全体のリソース配分を最適化するために、リソース管理サーバ３１００のアプリケーションＸ ３１０３が、アラーム発生通知元とは異なる他のネットワーク装置の装置Ａｍ ３０ｍ０に対してアクションを指示する場合がある例も説明することとする。
【００５０】
表１に示すように、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１は、いずれも、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１との間のネゴシエーションを行い、自装置内のリソースを管理するアプリケーションであり、使用するリソースが使用可能な限界値としてあらかじめ設定されたリソース閾値を超えた場合に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、事前に登録された希望アクション（希望実施内容）を実施することを要求するアラーム発生通知を送信する。
【００５１】
装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２は、使用するリソースがリソース閾値を超えた場合にリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１にてアラーム発生通知をリソース管理サーバ３１００に送信した結果として、リソース管理サーバ３１００のアプリケーションＸ ３１０３からの要求に基づいて実施されるリソース管理関連のアプリケーションであり、装置Ａｎ ３０ｎ０に常駐しており、アプリケーションＸ ３１０３からの要求に応じて、いつでも実行することが可能である。
【００５２】
これに対して、装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からのアラーム処理要求があった場合に、該アラーム処理要求に該当する処理内容を実行して、処理結果をアラーム処理要求元のリソース管理サーバ３１００のアプリケーションＸ ３１０３に対して返送するリソース管理関連のアプリケーションであり、装置Ａｍ ３０ｍ０に常駐しており、アプリケーションＸ ３１０３からのアラーム処理要求に応じて、いつでも実行することが可能である。
【００５３】
リソース管理サーバ３１００は、図３においては、リソースの管理対象のネットワーク装置である装置Ａｎ ３０ｎ０のリソース使用状況を監視する監視サーバであり、装置Ａｎ ３０ｎ０のリソースがリソース閾値を超えた場合に装置Ａｎ ３０ｎ０から送信されてくるアラーム発生通知に応じて、当該リソース管理サーバ３１００にあらかじめ設定登録されている希望アクション（希望実施内容）を実施するようにアプリケーションＸ ３１０３に対して指示する。
【００５４】
また、アラーム発生通知を送信してきた装置Ａｎ ３０ｎ０がリソース管理対象のネットワーク装置であるか否かを認証する動作を実施して、リソース管理サーバ３１００への不適当なネットワーク装置からの不正接続を防止する機能も有している。つまり、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、リソースの管理対象のネットワーク装置である装置Ａｎ ３０ｎ０の装置起動時に送信されてくる希望アクション（希望実施内容）の事前登録要求を受け取った際に、要求元の装置Ａｎ ３０ｎ０の認証を行うために、認証管理３１０２に対して認証要求を行う。また、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１がリソース閾値を超えたことを検知した際に送信してくるアラーム発生通知を受け取った際に、事前に設定登録された希望アクション（希望実施内容）に基づいて適切な判断を行い、必要に応じてアプリケーションＸ ３１０３に対してアラーム処理要求を出力する。
【００５５】
なお、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、リソースの管理対象のネットワーク装置であるすべての装置（図３の場合、装置Ａｎ ３０ｎ０、装置Ａｍ ３０ｍ０の２つのネットワーク装置を示している）のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｉ１（ｉ＝１，２，…，ｍ，…ｎ）に関するプロファイル３１０４を備えており、必要に応じて、プロファイル３１０４に保持されている各ネットワーク装置のデータを参照することが可能である。
【００５６】
ここで、プロファイル３１０４は、管理対象の各ネットワーク装置の希望アクション（希望実施内容：リソース不足発生時にリソース管理サーバ３１００側で実施して欲しい処理内容）を、各ネットワーク装置のリソース状態とともに事前登録しているものであり、リソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｉ１（ｉ＝１，２，…，ｍ，…ｎ）を有するすべてのネットワーク装置（図３の場合、装置Ａｎ ３０ｎ０、装置Ａｍ ３０ｍ０の２つのネットワーク装置）それぞれが希望する処理実施内容や実施開始時刻等に関する希望アクション情報をリソース状態とともに設定しているデータベースである。リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、必要に応じて、プロファイル３１０４のデータ（例えばアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のデータ）を参照して、希望するアクション（処理実施内容）を決定して実施する。
【００５７】
リソース管理サーバ３１００の認証管理３１０２は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からの要求があった装置Ａｎ ３０ｎ０が、管理対象のネットワーク装置として管理すべきネットワーク装置であるか否かを認証する処理を実施する。
【００５８】
リソース管理サーバ３１００のアプリケーションＸ ３１０３は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム処理要求を受け取った場合、つまり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からアラーム発生通知を受け取ったリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１がアプリケーションＸ ３１０３による処理が必要であると判断した場合、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２、または、該送信元とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２に対して、事前に設定登録されているアクション（処理内容）の実行を要求するアラーム処理要求を送信する。
【００５９】
ここで、アプリケーションＸ ３１０３は、特定のアプリケーションを意味しているものではなく、アラーム発生通知の内容とプロファイル３１０４に設定されているデータとを参照した結果による判断結果に基づいてリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１によって選択されて指示されたアプリケーションのことである。
【００６０】
また、インタフェースＲｎｊ（ｊ＝１，２，７，８，９，１０，１１，１２）、ＡＣＫｎ、ＡＣＫｍは、異なる装置間で通信するためのインタフェースであり、インタフェースＲｎ３，４，５，６は、リソース管理サーバ３１００内の機能部間で通信するためのＡＰＩ（Application Program Interface）である。
【００６１】
より詳細には、インタフェースＲｎ１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースＲｎ２は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対してアクションの実施結果を示す処理応答（アラーム発生応答）を送信するためのインタフェースである。
【００６２】
また、インタフェースＲｎ３は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から認証管理３１０２に対して認証要求を送信するためのＡＰＩであり、インタフェースＲｎ４は、リソース管理サーバ３１００の認証管理３１０２からリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して認証結果を送信するためのＡＰＩである。
【００６３】
また、インタフェースＲｎ５は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアプリケーションＸ ３１０３に対して指定したアプリ実行要求を送信するためのＡＰＩであり、インタフェースＲｎ６は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアプリ実行結果を送信するためのＡＰＩである。
【００６４】
また、インタフェースＲｎ７は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースＲｎ８は、アラーム処理要求の送信先の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２からリソース管理サーバ３１００のアプリケーションＸ ３１０３に対して処理結果を示す応答を送信するためのインタフェースである。
【００６５】
また、インタフェースＲｎ９は、リソース管理サーバ３１００のアプリケーションＸ ３１０３からアラーム発生通知の送信元とは異なる装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースＲｎ１０は、アラーム処理要求の送信先の装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２からリソース管理サーバ３１００のアプリケーションＸ ３１０３に対して処理結果を示す応答を送信するためのインタフェースである。
【００６６】
また、インタフェースＲｎ１１は、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースＲｎ１２は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生通知の送信元の装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１に対してアクションの実施結果を示す処理応答（アラーム発生応答）を送信するためのインタフェースである。
【００６７】
また、インタフェースＡＣＫｎは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して処理応答を正常に受け取った旨を示す応答ＡＣＫを送信するためのインタフェースであり、インタフェースＡＣＫｍは、装置Ａｍ ３０ｍ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｍ１がリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して処理応答を正常に受け取った旨を示す応答ＡＣＫを送信するためのインタフェースである。
【００６８】
次に、図３のリソース管理システムに示したリソース管理サーバ３１００と管理対象のネットワーク装置である装置Ａｎ ３０ｎ０との間の通信シーケンスについて、装置Ａｎ ３０ｎ０から事前に設定登録する希望実施内容すなわち希望アクションの登録および希望実施内容すなわり希望アクションの削除を行う際のシーケンスの一例を、図４を用いて説明する。
【００６９】
図４は、図３のリソース管理システムにおける希望アクション（希望実施内容）の事前登録シーケンスおよび希望アクション（希望実施内容）の削除シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置Ａ１ ３０１０ないし装置Ａｎ ３０ｎ０のうち、いずれかのネットワーク装置例えば第ｎ番目の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からのリソース管理サーバ３１００に対する事前登録要求があった際に、希望アクション（希望実施内容）を事前に設定登録し、かつ、事前登録削除要求に応じて、設定登録していた希望アクション（希望実施内容）を削除する場合のシーケンスについて示している。
【００７０】
装置Ａｎ ３０ｎ０は、収容する端末数の変化やネットワークのリソース変動等に伴って、使用するリソースがあらかじめ設定したリソース閾値を超えた場合に、リソース管理サーバ３１００に対してアラーム発生通知を送信することによって、あらかじめ事前に設定登録している希望アクション（希望実施内容）の実施を要求する。ここで、実施してもらいたい希望アクション（希望実施内容）とは、例えば、装置Ａｎ ３０ｎ０を利用する端末数が増加したために、装置Ａｎ ３０ｎ０の使用可能なリソース量を増加させるようなリソースの再配分を実施してもらうことを要求したり、あるいは、新たな装置Ａｍ ３０ｍ０に増加した一部または全ての端末を収容させるために、装置Ａｍ ３０ｍ０の閉塞状態を解除することを要求したりする場合を意味している。以下においては、図４のシーケンスで示す一連の処理を「事前登録・削除処理」と称することにする。
【００７１】
図４のシーケンスチャートにおいて、まず、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、装置起動時に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、図７に示すフォーマットからなる事前登録・削除要求パケットを送信する（シーケンスＳ４００１）。
【００７２】
図７は、図３のリソース管理システムにおいてネットワーク装置の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信される事前登録・削除要求パケットのフォーマットの一例を示すテーブルである。
【００７３】
ここで、図７に示す事前登録・削除要求パケットは、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、リソース閾値を超えた場合にアラーム発生通知をリソース管理サーバ３１００に送信することによって、リソース管理サーバ３１００側で実施して欲しい希望アクション（希望実施内容）をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に事前登録するために用いられ、また、事前登録されている希望アクション（希望実施内容）に関する情報を削除するために用いられる。
【００７４】
具体的には、図７に示す事前登録・削除要求パケットは、バージョン、ヘッダ長、パケット長、タイプ、要求数、シーケンス番号、承認キー、予約の各情報からなるヘッダ情報に引き続くデータ領域に、実施して欲しい希望アクション（希望実施内容）に関する情報として、希望優先度、指示対象名、実施回数、仮登録番号、開始時刻、希望実施内容を１組の希望アクションとし、必要に応じて、優先度を付して、希望アクション１，…，希望アクションｊと複数組纏めて収容することができる。
【００７５】
図７に示す事前登録・削除要求パケットに設定されるそれぞれの情報の意味は、次の表２に示す通りである。なお、表２には、後述する図８の事前登録・削除応答パケット、図９の事前登録・削除応答ＡＣＫパケット、図１０のアラーム発生通知パケット、図１１のアラーム発生応答パケット、図１２のアラーム発生応答ＡＣＫパケットに設定される情報の意味についても併せて説明しているので、後述する該当の箇所においても、表２をそれぞれ参照されたい。
【００７６】
【表２】
【００７７】
表２に示すように、図７に示す事前登録・削除要求パケットのヘッダ情報内のバージョンフィールドは、当該パケットフォーマットタイプのバージョンを示す情報であり、送信元のネットワーク装置の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１と送信先のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１との双方で同じ方式のパケットフォーマットを用いて通信を行うために設定している。また、事前登録・削除要求パケットのヘッダ情報内のヘッダ長フィールドは、事前登録・削除要求パケットのヘッダ情報の長さ（バイト数）を示している。図７に示す事前登録・削除要求パケットの場合は１２バイトである。
【００７８】
また、事前登録・削除要求パケットのヘッダ情報内のパケット長フィールドは、データ領域に収容している希望アクション１、…、希望アクションｊの合計のメッセージサイズを設定し、ヘッダ情報内のタイプフィールドは、当該事前登録・削除要求パケットの種別を示し、事前登録要求であるか事前登録内容の削除要求であるかを設定する。
【００７９】
また、事前登録・削除要求パケットのヘッダ情報内の要求数フィールドは、希望アクション（希望実施内容）の個数（図７に示す例では、ｊ個）を設定し、事前登録・削除要求パケットのヘッダ情報内のシーケンス番号フィールドは、イベントが発生する都度、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１へ送信したパケットの送信順を示す番号を設定する。
【００８０】
また、事前登録・削除要求パケットのヘッダ情報内の承認キーフィールドには、事前登録要求時には、'０'が設定され、事前登録した希望アクション（希望実施内容）の削除要求時には、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録要求時に要求元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１が承認されることによって付与されていた承認キーが設定される。なお、ヘッダ情報内の予約フィールドは、現在使用されていないダミー領域である。
【００８１】
また、事前登録・削除要求パケットのデータ領域内の希望優先度フィールドは、複数の希望アクション（希望実施内容）を事前登録しようとする場合にそれぞれの希望アクションの優先順位を設定する。なお、複数の希望アクションに同一値の優先度が付されていた場合には、ヘッダ情報側に近い希望アクションほど優先して処理が実施されることにする。ただし、該希望優先度については、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側で、必要に応じて、優先順を変更することが可能である。
【００８２】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される指示対象名フィールドは、リソース管理サーバ３１００のアプリケーションＸ ３１０３から、複数のネットワーク装置すなわち装置Ａ１ ３０１０，…，装置Ａｎ ３０ｎ０のうち、設定したネットワーク装置例えば装置ＡｉのアプリケーションＡｉに対して、アラーム処理要求を送信して、希望アクション（希望実施内容）を実施してもらうことを示している。また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数フィールドは、希望アクション（希望実施内容）を実施する回数を設定する。
【００８３】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される仮登録番号フィールドは、事前登録要求元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１側において、実施を希望する処理実施内容すなわち希望アクション（希望実施内容）を管理するために使用されるユニークな仮の登録番号を設定する。該仮登録番号は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において本登録キーが発行完了されて、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から通知されてくるまでの一時的なキーとして扱われる。
【００８４】
なお、事前登録・削除要求パケットとして、事前登録された希望アクション（希望実施内容）を削除することを要求する場合には、既に、本登録キーが付与された状態にあるので、仮登録番号の代わりに、本登録キーを用いる。また、削除要求の場合には、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数、開始時刻、希望実施内容の各フィールドを省略することも可能である。また、すべての希望アクション（希望実施内容）を削除する場合には、場合によっては、ヘッダ情報のみからなる事前登録・削除要求パケットを用いるようにしても良い。
【００８５】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される開始時刻フィールドは、希望アクション（希望実施内容）をいつ実施するかというエポックタイムを指定する時刻情報を設定する。即時に実施することを指定する場合には、開始時刻を例えば'ａｌｌ０'に設定する。
【００８６】
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される希望実施内容フィールドは、リソース閾値を超えるリソース不足が発生した際に、または、リソース閾値以下に低下してリソース不足から回復した際に、リソース管理サーバ３１００側において、さらに、必要に応じて、アプリケーションＸ ３１０３を駆動することにより、実施してもらいたい処理内容を設定する。リソース管理サーバ３１００やアプリケーションＸ ３１０３が指定された処理内容を実施する開始タイミングは、事前登録・削除要求パケットの開始時刻フィールドによって指定されている。なお、希望実施内容フィールドに設定する希望アクション（希望実施内容）の情報量が、一定のデータサイズ例えば４バイトに収まらない場合には、希望実施内容フィールドを任意の長さに拡張することも可能である。
【００８７】
なお、以下の説明においては、ヘッダ情報に含まれるタイプには、事前登録を要求するパケットである旨の表示が設定され、要求数には、前述のように、事前登録を要求する希望アクションの個数が設定されているものとする。
【００８８】
リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から事前登録・削除要求パケットを受け取ると、該事前登録・削除要求パケットの送信元の装置Ａｎ ３０ｎ０が、管理対象のネットワーク装置であるか否かを判別するために、認証管理３１０２に対して認証要求を行う（シーケンスＳ４００２）。かかる動作は、前述したように、装置Ａｎ ３０ｎ０がリソース管理に該当していない不正なネットワーク装置であった場合に、ネットワーク全体に悪影響を及ぼし兼ねないので、かかる事態の発生を未然に防止するためである。
【００８９】
なお、認証管理３１０２に対する該認証要求には、認証の対象となるネットワーク装置を一意に特定することができる情報であって、かつ、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が確実に把握することができるネットワーク装置識別情報が付されている。例えば、事前登録・削除要求パケットの送信元を示す装置Ａｎ ３０ｎ０のＩＰアドレスやＭＡＣアドレス等が付されている。
【００９０】
認証要求を受け取った認証管理３１０２においては、該認証要求に付されているネットワーク装置識別情報例えばＩＰアドレスやＭＡＣアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置Ａｎ ３０ｎ０がリソース管理の対象装置であるか否かを判別することにより、装置Ａｎ ３０ｎ０の認証処理を行う。なお、認証管理３１０２における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。
【００９１】
認証管理３１０２は、装置Ａｎ ３０ｎ０の認証処理を終了すると、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して認証応答として返送する（シーケンスＳ４００３）。
【００９２】
リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、認証管理３１０２から認証応答として装置Ａｎ ３０ｎ０の認証結果を受け取り、該認証結果がＮＧであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取った事前登録・削除要求パケットに含まれている全ての希望アクションの事前登録を拒否する。一方、該認証結果がＯＫであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取った事前登録・削除要求パケットに含まれている全ての希望アクションすなわち希望アクション１，…，希望アクションｊを事前登録するとともに、それぞれの希望アクションごとに、それぞれの希望アクションを一意に特定するための本登録キーを発行する。
【００９３】
さらに、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、認証結果がＮＧであった場合には、事前登録要求を受け付けられない旨を示すＮＧ応答として、図８に示す事前登録応答パケットのヘッダ情報内の承認キーを"ａｌｌ０"に設定して、事前登録要求の送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信する（シーケンスＳ４００４）。
【００９４】
一方、認証結果がＯＫであった場合には、事前登録要求を受け付けた旨を示すＯＫ応答として、事前登録・削除要求パケットに含まれているそれぞれの希望アクションを一意に特定する本登録キーを付与した図８に示す事前登録応答パケットを作成するとともに、ヘッダ情報内の承認キーを、装置Ａｎ ３０ｎ０をリソース管理対象のネットワーク装置として承認したことを示す"ａｌｌ０"以外の有意な一意の値に設定して、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信する（シーケンスＳ４００４）。
【００９５】
図８は、図３のリソース管理システムにおいてリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から事前登録・削除要求元のネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信される事前登録・削除応答パケットのフォーマットの一例を示すテーブルである。
【００９６】
ここで、図８に示す事前登録・削除応答パケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、事前登録・削除要求パケットの送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に送信することによって、事前登録・削除要求パケットによって要求された希望アクション（希望実施内容）を事前登録したか否かを通知するために用いられる。
【００９７】
具体的には、図８に示す事前登録・削除応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域が要求受付数に関する情報を設定する領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、事前登録・削除要求パケットに含まれていた仮登録番号ごとに、仮登録結果および希望するアクション（処理内容）を一意に特定する本登録キーを１組の希望アクション応答とし、受け取った事前登録・削除要求パケットに応じて、希望アクション１応答，…，希望アクションｊ応答と複数組纏めて収容することができる。なお、ヘッダ情報に含まれるタイプには、事前登録・削除の応答を返送するパケットである旨を示す表示が設定される。
【００９８】
つまり、前述の表２に示すように、事前登録・削除応答パケットのヘッダ情報内の要求受付数フィールドには、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取った事前登録・削除要求パケットの希望実施内容フィールドにて指定されている希望アクション（希望実施内容）のうち、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において正当な処理要求であると認識して、事前登録された希望アクション（希望実施内容）の個数が設定される。
【００９９】
また、事前登録・削除応答パケットのデータ領域内において希望アクション応答ごとに設定される仮登録結果フィールドは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からの各希望アクション（希望実施内容）ごとの事前登録結果（事前登録されたか否かを示す情報）を設定する。事前登録・削除応答パケットのデータ領域内において希望アクション応答ごとに設定される本登録キーフィールドは、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録した希望アクション（希望実施内容）ごとに発行した本登録キーを設定する。
【０１００】
事前登録・削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、仮登録番号の各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、事前登録要求元の装置Ａｎ ３０ｎ０がリソース管理対象のネットワーク装置として承認され、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録・削除要求パケットに含まれている希望アクション（希望実施内容）の少なくとも１つ以上を事前登録した際に発行された'ａｌｌ０'以外の有意な一意の値である承認キーが設定される。
【０１０１】
また、シーケンス番号フィールドには、イベントが発生する都度、図７に示した事前登録・削除要求パケットの場合とは逆方向に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１へ送信したパケットの送信順を示す番号が設定される。
【０１０２】
図４のシーケンスチャートに戻って、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から事前登録・削除応答パケットを受け取ると、該事前登録・削除応答パケットのヘッダ情報に含まれている承認キーを参照して、'ａｌｌ０'以外の有意な一意の値が設定されているか否かを判別する。承認キーが'ａｌｌ０'であった場合には、当該装置Ａｎ ３０ｎ０が、リソース管理サーバ３１００のリソース管理対象のネットワーク装置ではないと認定されて、事前登録が拒絶されたことを示している。
【０１０３】
一方、承認キーが'ａｌｌ０'以外の有意な一意の値であった場合には、先に送信した事前登録・削除要求パケットに含まれている希望アクション（希望実施内容）の事前登録要求が受け付けられたものとして、事前登録・削除応答パケットを正常に受け取ったことを示す応答ＡＣＫを、図９に示す事前登録・削除応答ＡＣＫパケットとして、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信する（シーケンスＳ４００５）。
【０１０４】
なお、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においては、以降、データ領域に仮登録番号ごとに対応付けて設定されている本登録キーを用いて、実施を希望する希望実施内容すなわち希望アクション（処理内容）を管理することになる。
【０１０５】
図９は、図３のリソース管理システムにおいて事前登録・削除応答パケットを受け取ったネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信される事前登録・削除応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【０１０６】
ここで、図９に示す事前登録・削除応答ＡＣＫパケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、事前登録・削除応答パケットの送信元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信することによって、事前登録・削除応答パケットを正常に受け取った旨を通知するために用いられる。
【０１０７】
具体的には、図９に示す事前登録・削除応答ＡＣＫパケットは、ヘッダ情報のみからなり、ヘッダ情報にはバージョン、ヘッダ長、パケット長、タイプ、承認応答結果、シーケンス番号、承認キー、予約が含まれている。なお、ヘッダ情報に含まれるタイプには、事前登録・削除応答パケットを正常に受け取った旨を示す応答ＡＣＫパケットである旨を示す表示が設定される。
【０１０８】
つまり、前述の表２に示すように、事前登録・削除応答ＡＣＫパケットのヘッダ情報内の承認応答結果フィールドは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においても、事前登録・削除要求パケットの希望実施内容フィールドにて指定した希望アクション（希望実施内容）のうちリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録された希望アクション（希望実施内容）を正しく認識することができたか否かを示す情報を設定する。なお、複数存在している予約フィールドは、いずれも、現在使用されていないダミーの領域を示している。
【０１０９】
事前登録・削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において事前登録・削除要求パケットを受け付けて、事前登録・削除要求パケットに含まれている希望アクション（希望実施内容）の少なくとも１つ以上を事前登録した際に発行された'ａｌｌ０'以外の有意な一意の値である承認キーが設定される。
【０１１０】
以上の図４のシーケンスチャートに関する説明は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からの事前登録・削除要求パケットとして、リソース閾値を超えてリソース不足が発生したことを示すアラーム発生通知をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信した際に実施してもらいたい希望アクション（希望実施内容）を事前登録することを要求している場合について説明したが、事前登録されている希望アクション（希望実施内容）を削除することを要求する場合についても、全く同様のシーケンスで実施される。
【０１１１】
ただし、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からの事前登録・削除要求パケットとして、事前登録されている希望アクション（希望実施内容）の削除を要求する場合には、ヘッダ情報に含まれるタイプには、事前登録の削除を要求するパケットである旨の表示が設定され、要求数には、事前登録の削除を要求する希望アクションの個数が設定される。
【０１１２】
また、削除要求を行う場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においても、各希望アクション（各希望実施内容）を一意に特定するための識別番号として、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が発行した本登録キーが既に用いられているので、事前登録の要求時においてデータ領域の希望実施内容ごとに設定されていた仮登録番号の代わりに、本登録キーが設定される。
【０１１３】
なお、図４に示すような事前登録・削除処理においては、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から送信されてくる事前登録・削除要求パケットを受け取ったとしても、アプリケーション実行の予約に関する情報は無効であり、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から、アプリケーションＸ ３１０３に対してアプリケーション実行の予約等を事前に行うことはない。
【０１１４】
アプリケーションＸ ３１０３の実行を予約する場合は、あくまでも、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１において、使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいはリソース閾値以下に低下してリソース不足から回復したりして、アラーム発生通知をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信してきた場合のみに限られる。
【０１１５】
次に、図３のリソース管理システムに示したリソース管理サーバ３１００と管理対象のネットワーク装置である装置Ａｎ ３０ｎ０との間の通信シーケンスについて、装置Ａｎ ３０ｎ０において使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置Ａｎ ３０ｎ０からリソース管理サーバ３１００に対して送信する際のシーケンスの一例を、図５を用いて説明する。
【０１１６】
図５は、図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置Ａ１ ３０１０ないし装置Ａｎ ３０ｎ０のうち、いずれかのネットワーク装置例えば第ｎ番目の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００に対してアラーム発生通知が送信されて、事前に設定登録されていた希望アクション（希望実施内容）を実施する際の処理シーケンスの一例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、事前登録された希望アクション（希望実施内容）とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションＸ ３１０３を駆動して、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２に対して、アラーム処理要求を送信することによって、装置Ａｎ ３０ｎ０のＭＩＢ（Management Information Base）情報を収集して輻輳状態を判別し、リソース状態の再配分を行う場合のシーケンス例について示している。以下においては、図５のシーケンスで示す一連の処理を「アラーム処理１」と称することにする。
【０１１７】
図５のシーケンスチャートにおいて、まず、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、使用しようとするネットワークのリソースがあらかじめ設定しているリソース閾値を超えたか、あるいは、該リソース閾値を超えた状態から該リソース閾値以下にまで低下してリソース不足から回復したりしたことを検知すると、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、アラーム処理要求を行うためのアラーム発生通知として、図１０に示すフォーマットからなるアラーム発生通知パケットを送信する（シーケンスＳ５００１）。
【０１１８】
図１０は、図３のリソース管理システムにおいてアラーム発生元のネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信されるアラーム発生通知パケットのフォーマットの一例を示すテーブルである。
【０１１９】
ここで、図１０に示すアラーム発生通知パケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、アラーム発生元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信することによって、事前登録しておいた希望アクション（希望実施内容）のいずれかを実施することを要求するために用いられる。
【０１２０】
具体的には、図１０に示すアラーム発生通知パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、閾値種別、予約からなるアラーム内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生を通知するパケットである旨を示す表示が設定され、アラーム内容の閾値種別には、リソース閾値を超えたかまたは該リソース閾値以下に低下してリソース不足から回復したかを示す情報が設定されている。
【０１２１】
つまり、前述の表２に示すように、アラーム発生通知パケットのヘッダ情報内のシーケンス番号フィールドは、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１において、アラームが発生する都度、インクリメントされる番号であり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１へ送信したパケットの送信順を示している。該シーケンス番号は、装置Ａｎ ３０ｎ０に発生したアラームをリソース管理サーバ３１００に通知した状況を管理するための識別番号として使用される。
【０１２２】
また、アラーム発生通知パケットのデータ領域にあるアラーム内容内の閾値種別フィールドは、前述したように、装置Ａｎ ３０ｎ０の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
【０１２３】
アラーム発生通知パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において既に発行されている承認キーが設定される。
【０１２４】
図５のシーケンスチャートに戻って、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からアラーム発生通知パケットを受け取ると、図４の事前登録・削除処理の場合と同様、該アラーム発生通知パケットの送信元の装置Ａｎ ３０ｎ０が、管理対象のネットワーク装置であるか否かを判別するために、認証管理３１０２に対して認証要求を行う（シーケンスＳ５００２）。
【０１２５】
認証要求を受け取った認証管理３１０２においては、図４の事前登録・削除処理の場合と同様、該認証要求に付されているネットワーク装置識別情報例えばＩＰアドレスやＭＡＣアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置Ａｎ ３０ｎ０がリソース管理の対象装置であるか否かを判別することにより、装置Ａｎ ３０ｎ０の認証処理を行う。なお、認証管理３１０２における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。
【０１２６】
認証管理３１０２は、装置Ａｎ ３０ｎ０の認証処理を終了すると、図４の事前登録・削除処理の場合と同様、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して認証応答として返送する（シーケンスＳ５００３）。
【０１２７】
リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、認証管理３１０２からの認証応答として、装置Ａｎ ３０ｎ０の認証結果を受け取り、該認証結果がＮＧであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。
【０１２８】
一方、該認証結果がＯＫであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション（希望実施内容）を参照して、実施すべきアクション（処理内容）を決定する。決定されたアクション（処理内容）が、例えば、アプリケーションＸ ３１０３を駆動して、輻輳状態を判別するためにアラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２にアラーム処理要求を送信することによって、装置Ａｎ ３０ｎ０のＭＩＢ（Management Information Base）情報を収集する処理を行う場合には、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、アプリケーションＸ ３１０３を駆動して、アラーム処理要求として、決定したアクション（処理内容）にしたがった処理の実施を要求する（シーケンスＳ５００４）。
【０１２９】
駆動されたアプリケーションＸ ３１０３は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０にアラーム処理要求を送信することによって、装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２のＳＮＭＰ（Simple Network Management Protocol） ＭＩＢ（Management Information Base）情報を収集する動作を起動する。この動作が起動されると、アプリケーションＸ ３１０３は、事前登録された希望アクション（希望実施内容）の中から決定した希望アクション（希望実施内容）にしたがったアラーム処理要求として、例えば、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２に対して、ＳＮＭＰ ＭＩＢ情報の収集を指示するアラーム処理要求を送信する（シーケンスＳ５００５）。
【０１３０】
装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２は、決定した事前登録の希望アクション（希望実施内容）にしたがったアラーム処理要求例えばＳＮＭＰ ＭＩＢ情報の収集を指示するアラーム処理要求をリソース管理サーバ３１００のアプリケーションＸ ３１０３から受け取ると、事前登録の希望アクション（希望実施内容）にしたがった処理例えばＳＮＭＰ ＭＩＢ情報の収集処理を実施して、事前登録の希望アクション（希望実施内容）の実施結果例えばＳＮＭＰ ＭＩＢ情報の収集結果を、リソース管理サーバ３１００のアプリケーションＸ ３１０３に対して返送する（シーケンスＳ５００６）。
【０１３１】
リソース管理サーバ３１００のアプリケーションＸ ３１０３は、アラーム処理要求に応じて、装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２から返送されてきた事前登録の希望アクション（希望実施内容）の実施結果例えばＳＮＭＰ ＭＩＢ情報の収集結果を受け取ると、受け取った実施結果例えばＳＮＭＰ ＭＩＢ情報の収集結果を保持するとともに、該ＳＮＭＰ ＭＩＢ情報の収集結果に基づくリソースの再配分を行い、決定した事前登録の希望アクション（希望実施内容）の実施が成功したか否かを、当該アプリケーションＸ ３１０３から、アラーム処理要求に対する応答として、アラーム処理要求元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して返送する（シーケンスＳ５００７）。
【０１３２】
リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、アプリケーションＸ ３１０３からアラーム処理要求に対する応答を受け取ると、該応答を実行結果として含む図１１に示すフォーマットからなるアラーム発生応答パケットを作成して、アラーム発生通知パケットの送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信する（シーケンスＳ５００８）。
【０１３３】
なお、アプリケーションＸ ３１０３における何らかの処理が失敗した場合には、アプリケーションＸ ３１０３は、アラーム処理要求元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して処理を失敗した旨を示す応答を返送する。かくのごとく、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、アプリケーションＸ ３１０３における処理が失敗した旨の応答を受け取った場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対するアラーム発生応答パケットの送信動作を抑止して、応答待ちタイムアウトによる装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からのアラーム発生通知パケットの再送信を促すようにしても良い。
【０１３４】
図１１は、図３のリソース管理システムにおいてリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生通知パケットの送信元のネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して送信されるアラーム発生応答パケットのフォーマットの一例を示すテーブルである。
【０１３５】
ここで、図１１に示すアラーム発生応答パケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、アラーム発生通知パケットの送信元の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に送信することによって、アラーム発生通知パケットによって要求された希望アクション（希望実施内容）の実施に成功したか否かを通知するために用いられる。
【０１３６】
具体的には、図１１に示すアラーム発生応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、実行結果、閾値種別、強制削除フラグからなるアラーム応答内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生通知に対する応答を返送するパケットである旨を示す表示が設定される。
【０１３７】
つまり、前述の表２に示すように、アラーム発生応答パケットのヘッダ情報内のシーケンス番号フィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において、イベントが発生する都度、図１０に示したアラーム発生通知パケットの場合と同様、インクリメントされる番号であり、図１０に示したアラーム発生通知パケットの場合とは逆方向に、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１から装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１へ送信したパケットの送信順を示している。
【０１３８】
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図１０に示したアラーム発生通知パケットにより送信されてきた閾値種別がそのまま設定され、装置Ａｎ ３０ｎ０の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
【０１３９】
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドには、アラーム発生通知パケットにより要求された希望アクション（希望実施内容）の処理例えばＳＮＭＰ ＭＩＢ情報の収集処理が成功し、リソースの再配分に成功したか否かを示す実行結果が設定され、本実施例においては、アプリケーションＸ ３１０３により駆動された装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２の実施が成功したか否かを示す情報が設定される。なお、該実行結果として、アプリケーションＸ ３１０３により駆動された装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２の実施結果を示す処理詳細例えばＳＮＭＰ ＭＩＢ情報の収集結果やリソース再配分処理結果を含むようにしても良い。
【０１４０】
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の強制削除フラグフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、ネットワーク全体の各ネットワーク装置からの希望アクション（希望実施内容）やリソース状態を保持しているプロファイル３１０４に設定されているデータの参照結果として、アプリケーションＸ ３１０３に対するアラーム処理要求は不適当であると判定して、アプリケーションＸ ３１０３に対して希望アクション（希望実施内容）の実施を要求するアラーム処理要求を行わなかった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１に対して事前登録されている当該希望アクション（希望実施内容）の強制的な削除を指示するための強制削除フラグが設定される。該強制削除フラグが設定されているアラーム発生応答パケットを受け取った装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、必ず、当該希望アクション（希望実施内容）の削除を実施しなければならない。なお、プロファイル３１０４に設定されているデータの詳細については後述する。
【０１４１】
アラーム発生応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において既に発行されている承認キーが設定される。
【０１４２】
図５のシーケンスチャートに戻って、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生応答パケットを受け取ると、該アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドを確認し、実施要求していた希望アクション（希望実施内容）の実施が成功したか否かを確認する。希望アクション（希望実施内容）の実施が成功していた場合には、使用するリソースの割当状況に変化が生じているものと看做すことができるが、実施が失敗していた場合には、さらに、データ領域にあるアラーム応答内容内の強制削除フラグフィールドを参照して強制削除フラグが設定されているか否かを確認する。
【０１４３】
強制削除フラグが設定されていた場合には、前述したように、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、事前登録・削除要求パケットを送信して、事前登録していた希望アクション（希望実施内容）を削除しなければならない。
【０１４４】
かくのごとき事前登録の希望アクション（希望実施内容）の強制的な削除処理を実行する目的は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側において、実施が失敗になってしまうようなアラーム処理要求をアプリケーションＸ ３１０３に対していつまでも送信し続けることがないように、該希望アクション（希望実施内容）の実施を要求するアラーム発生通知パケットを、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から送信する動作を抑止するためである。つまり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して、何回も繰り返して、実施することが出来ない希望アクション（希望実施内容）の実施を要求するアラーム発生通知パケットが送信されることによる輻輳を防止するためである。
【０１４５】
受け取ったアラーム発生応答パケットの処理を終了すると、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム発生応答パケットを正常に受け取ったことを示すアラーム発生応答ＡＣＫを、図１２に示すアラーム発生応答ＡＣＫパケットとして、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信する（シーケンスＳ５００９）。
【０１４６】
図１２は、図３のリソース管理システムにおいてアラーム発生応答パケットを受け取ったネットワーク装置すなわち装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対して送信されるアラーム発生応答ＡＣＫパケットのフォーマットの一例を示すテーブルである。
【０１４７】
ここで、図１２に示すアラーム発生応答ＡＣＫパケットも、事前登録・削除要求パケットと同様、ＵＤＰ（User Datagram protocol）パケット上のペイロードとして扱われ、アラーム発生応答パケットの送信元のリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に送信することによって、アラーム発生応答パケットを正常に受け取った旨を通知するために用いられる。
【０１４８】
具体的には、図１２に示すアラーム発生応答ＡＣＫパケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、応答結果、閾値種別、強制削除結果、予約からなるアラームＡＣＫが設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生応答パケットを正常に受け取った旨を示すアラーム発生応答ＡＣＫパケットである旨を示す表示が設定される。
【０１４９】
つまり、前述の表２に示すように、アラーム発生応答ＡＣＫパケットのヘッダ情報内のシーケンス番号フィールドは、図１０に示したアラーム発生通知パケットの場合と同様、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１において、イベントが発生する都度、インクリメントされる番号であり、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１へ送信したパケットの送信順を示している。
【０１５０】
また、アラーム発生応答ＡＣＫパケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図１０に示したアラーム発生通知パケットにより送信した閾値種別がそのまま設定され、装置Ａｎ ３０ｎ０の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
【０１５１】
また、アラーム発生応答ＡＣＫパケットのデータ領域にあるアラームＡＣＫ内の応答結果フィールドには、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１においても、アラーム発生応答パケットのアラーム応答内容、すなわち、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において実施された処理内容を正しく認識することができたか否かを示す情報が設定される。
【０１５２】
また、アラーム発生応答ＡＣＫパケットのデータ領域にあるアラームＡＣＫ内の強制削除結果フィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からの指示通りに、事前登録した希望アクション（希望実施内容）を強制削除することができたか否かを示す情報が設定される。なお、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム発生応答パケットに強制削除フラグが設定されていなかった場合には、アラームＡＣＫ内の強制削除結果フィールドには無効なデータが設定された状態になっている。
【０１５３】
アラーム発生応答ＡＣＫパケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キーの各フィールドに関しては、図７に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において既に発行されている承認キーが設定される。
【０１５４】
なお、図５のシーケンスＳ５００８において、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から、アラーム発生通知パケットを送信した後、あらかじめ定めた時間閾値を経過しても、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からアラーム発生応答パケットを受信することができなかった場合には、応答待ちタイムアウトが発生したものとして、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１は、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１に対してアラーム発生通知パケットを再度送信する動作を行うようにしても良い。
【０１５５】
次に、図３のリソース管理システムに示したリソース管理サーバ３１００と管理対象のネットワーク装置である装置Ａｎ ３０ｎ０との間の通信シーケンスについて、装置Ａｎ ３０ｎ０において使用するリソースがリソース閾値を超えたりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置Ａｎ ３０ｎ０からリソース管理サーバ３１００に対して送信する際のシーケンスについて、図５とは異なる例を、図６を用いて説明する。
【０１５６】
図６は、図３のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの図５とは異なる例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置Ａ１ ３０１０ないし装置Ａｎ ３０ｎ０のうち、いずれかのネットワーク装置例えば第ｎ番目の装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１からリソース管理サーバ３１００に対してアラーム処理要求が送信されて、事前に設定登録されていた希望アクション（希望実施内容）を実施する際の処理シーケンスの他の例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が、事前登録された希望アクション（希望実施内容）とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションＸ ３１０３を駆動して、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２に対してアラーム処理要求を送信することによって、アプリケーションＡｍ ３０ｍ２を駆動して、装置Ａｍ ３０ｍ０の閉塞状態を解除させる装置Ａｍ ３０ｍ０側のコマンドを実施する場合のシーケンス例について示している。以下においては、図６のシーケンスで示す一連の処理を「アラーム処理２」と称することにする。
【０１５７】
図６のシーケンスチャートにおいて、シーケンスＳ６００１〜Ｓ６００３までのシーケンスおよびシーケンスＳ６００７〜Ｓ６００９までのシーケンスは、それぞれ、図５のシーケンスチャートＳ５００１〜Ｓ５００３までのシーケンスおよびシーケンスＳ５００７〜Ｓ５００９までのシーケンスと全く同様であるので、ここでの重複する説明は省略する。
【０１５８】
図６のシーケンスＳ６００４において、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、シーケンスＳ６００３において認証管理３１０２から認証応答として返送されてきた装置Ａｎ ３０ｎ０の認証結果を受け取ると、該認証結果がＮＧであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。
【０１５９】
一方、該認証結果がＯＫであった場合には、装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション（希望実施内容）を参照して、実施すべきアクション（処理内容）を決定する。
【０１６０】
決定されたアクション（処理内容）が、例えば、アプリケーションＸ ３１０３を駆動して、図５のシーケンスＳ５００４の場合とは異なり、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２の輻輳状態を解決するために、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０のアプリケーションＡｎ ３０ｎ２とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２のＴｅｌｎｅｔサーバに対してリソース管理サーバ３１００のＴｅｌｎｅｔクライアントが接続を要求して、ＣＬＩ（Command Line Interface）を用いて装置Ａｍ ３０ｍ０側のコマンドを実施するアラーム処理要求であった場合には、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、アプリケーションＸ ３１０３を駆動して、アラーム処理要求として、決定したアクション（処理内容）にしたがった処理の実施を要求する（シーケンスＳ６００４）。
【０１６１】
駆動されたアプリケーションＸ ３１０３は、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置Ａｎ ３０ｎ０とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２のＴｅｌｎｅｔサーバに対してリソース管理サーバ３１００のアプリケーションＸ ３１０３のＴｅｌｎｅｔクライアントが接続を要求して、ＣＬＩ（Command Line Interface）のコマンドラインインタフェースを用いて、装置Ａｍ ３０ｍ０側のコマンドを実施する動作、を起動する。
【０１６２】
この動作が起動されると、アプリケーションＸ ３１０３は、事前登録された希望アクション（希望実施内容）の中から決定した希望アクション（希望実施内容）にしたがった実施処理結果として、例えば、装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２のＴｅｌｎｅｔサーバに対してリソース管理サーバ３１００のＴｅｌｎｅｔクライアントが接続を要求して、ＣＬＩ（Command Line Interface）のコマンドラインインタフェースを用いて、装置Ａｍ ３０ｍ０側のコマンドを実施するというアラーム処理要求を送信する（シーケンスＳ６００５）。
【０１６３】
装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２は、決定した事前登録の希望アクション（希望実施内容）にしたがったアラーム処理要求例えばＣＬＩ（Command Line Interface）を用いて装置Ａｍ ３０ｍ０側のコマンドを実施するというアラーム処理要求をリソース管理サーバ３１００のアプリケーションＸ ３１０３から受け取ると、事前登録の希望アクション（希望実施内容）にしたがった処理例えばリソース管理サーバ３１００のＴｅｌｎｅｔクライアントからのＣＬＩ（Command Line Interface）を用いた要求に該当する装置Ａｍ ３０ｍ０側のコマンドをＴｅｌｎｅｔサーバとして実施して（例えば、装置Ａｍ ３０ｍ０の閉塞状態を解除して）、事前登録の希望アクション（希望実施内容）の実施結果例えばコマンドの実行結果を、リソース管理サーバ３１００のアプリケーションＸ ３１０３に対して返送する（シーケンスＳ６００６）。
【０１６４】
かくのごとく、輻輳状態に陥ってアラーム発生通知の送信元となっていた装置Ａｎ ３０ｎ０とは異なる他のネットワーク装置例えば装置Ａｍ ３０ｍ０のアプリケーションＡｍ ３０ｍ２においてコマンドを実行することによって、例えば、装置Ａｍ ３０ｍ０の閉塞状態を解除して、アラーム処理要求元の装置Ａｎ ３０ｎ０側の負荷の一部を分担することが可能になる。
【０１６５】
次に、図５のシーケンスＳ５００５において、アラーム発生応答パケットの強制削除フラグを設定するか否かを判別するために、つまり、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１がアプリケーションＸ ３１０３への実施要求が適当か否かを判定して、該判定結果に基づいてアプリケーションＸ ３１０３に対して希望アクション（希望実施内容）の実施を要求するか否かを判別するために、参照されるプロファイル３１０４のデータについて、次の表３を用いて詳細に説明する。
【０１６６】
【表３】
【０１６７】
表３に示すプロファイル３１０４は、前述のように、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１内に保持されているネットワーク全体のリソース管理に関するデータベースであり、ネットワークを構成する各ネットワーク装置から事前登録されている希望アクション（希望実施内容）を実施履歴や各ネットワーク装置のリソース状態とともに保持している。つまり、プロファイル３１０４は、表３に示すように、承認キー３０１、承認先ＩＰアドレス／プレフィックス３０２、本登録キー３０３、希望優先度３０４、指示対象名３０５、実施回数３０６、開始時刻３０７、希望実施内容３０８、登録完了時刻３０９、現在の状態３１０を少なくとも有して構成されている。さらに、本登録キーごとにそれぞれのアクション（処理内容）の実施履歴として、項番３１１、実施結果３１２、開始時刻３１３、完了時刻３１４を有して構成されている。
【０１６８】
表３に示すプロファイル３１０４の設定例においては、承認キー３０１、承認先ＩＰアドレス／プレフィックス３０２および希望実施内容３０８に示すように、承認先ＩＰアドレス／プレフィックス３０２が'Ａ，Ｂ，Ｃ，Ｄ／Ｐ'のネットワーク装置の装置Ａｎ ３０ｎ０からの事前登録処理により、承認キー３０１が'3fe9105a'として登録された２つの希望実施内容（本登録キー３０３が'０００００００１'および'０００００００２'の２つ）が設定され、承認先ＩＰアドレス／プレフィックス３０２が'Ｗ，Ｘ，Ｙ，Ｚ／Ｐ'のネットワーク装置の装置Ａｍ ３０ｍ０からの事前登録処理により、承認キー３０１が'3fe9105b'として登録された２つの希望実施内容（本登録キー３０３が'０００００００３'および'０００００００４'の２つ）が設定されている例が示されている。
【０１６９】
ここで、表３に示すプロファイル３１０４の承認キー３０１、本登録キー３０３、希望優先度３０４、指示対象名３０５、実施回数３０６、開始時刻３０７、希望実施内容３０８、実施結果３１２のそれぞれのデータについては、図７の事前登録・削除要求パケット、図８の事前登録・削除応答パケット、図９の事前登録・削除応答ＡＣＫパケット、図１０のアラーム発生通知パケット、図１１のアラーム発生応答パケット、および、図１２のアラーム発生応答ＡＣＫパケットの内容が反映される。
【０１７０】
また、表３に示すプロファイル３１０４の承認先ＩＰアドレス／プレフィックス３０２、および、登録完了時刻３０９については、図４の事前登録・削除処理のシーケンス処理中において、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が認識することにより設定することができる。
【０１７１】
また、表３に示すプロファイル３１０４の現在の状態３１０、および、実施履歴の項番３１１については、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１による監視結果として決定して設定することができる。
【０１７２】
また、表３に示すプロファイル３１０４の実施履歴の開始時刻３１３、および、完了時刻３１４については、図５のアラーム処理１のシーケンスにおけるシーケンスＳ５００４（アプリケーションＸ ３１０３へのアラーム処理要求を行うシーケンス）、および、シーケンスＳ５００７（アプリケーションＸ ３１０３から実施結果を受け取るシーケンス）や、あるいは、図６のアラーム処理２のシーケンスにおけるシーケンスＳ６００４（アプリケーションＸ ３１０３へのアラーム処理要求を行うシーケンス）、および、シーケンスＳ６００７（アプリケーションＸ ３１０３から実施結果を受け取るシーケンス）によって、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１が認識して設定することができる。
【０１７３】
ここで、現在の状態３１０は、本登録キーごとに'待ち'、'実行中'、'完了'、'失敗'の４つの状態が存在する。'完了'の後は、'待ち'の状態に遷移する。'待ち'の後は、'実行中'の状態に遷移する。'失敗'の後は、'待ち'の状態に遷移するか、あるいは、強制削除によって、当該本登録キー自体が削除される。表３に示す例においては、本登録キー'０００００００４'の場合が、現在の状態３１０に示すように、'失敗'の状態になっている。
【０１７４】
かくのごとく、現在の状態３１０が'失敗'の状態にある場合に、次の状態として'待ち'の状態に遷移するか、あるいは、強制削除するかは、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１において適宜判別される。例えば、当該本登録キーで特定される希望アクション（希望実施内容）の実施回数があらかじめ定めた回数閾値に達するまでは、'待ち'の状態に移行し、実施回数が該回数閾値以上に及んで何回も'失敗'を繰り返している場合には、当該本登録キーで特定される希望アクション（希望実施内容）は、強制的に削除することにしても良い。
【０１７５】
なお、プロファイル３１０４から希望アクション（希望実施内容）のデータの削除を行う場合には、図４の事前登録・削除処理のシーケンスにしたがって、当該本登録キーの希望アクション（希望実施内容）を事前登録したネットワーク装置例えば装置Ａｎ ３０ｎ０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）３０ｎ１との間で、希望アクション（希望実施内容）の削除処理を実施することになるが、当該本登録キーを主キーとしてプロファイル３１０４のデータを参照して削除することが可能である。
【０１７６】
また、表３に示すプロファイル３１０４の実施結果３１２には、'成功'、'失敗'、および、'実行中'の３つの結果が存在する。実施結果３１２が'実行中'の場合には、現在の状態３１０も'実行中'の状態にあり、実施結果３１２が'失敗'の場合には、現在の状態３１０も'失敗'かまたは'待ち'の状態になり、実施結果３１２が'成功'の場合には、現在の状態３１０は'完了'かまたは'待ち'の状態になる。
【０１７７】
以上のように、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１は、プロファイル３１０４としてネットワークを構成する各ネットワーク装置に関する各種のデータを保持しているので、送信先ＩＰアドレスの払い出しや希望アクション（希望実施内容）の実行優先度付けを適宜行うことが可能である。
【０１７８】
このようにして、本実施形態においては、各ネットワーク装置例えば例えば装置Ａｎ ３０ｎ０から、リソース不足時に実施してもらいたい希望アクション（希望実施内容）をリソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側に事前登録し、かつ、実際にリソース不足が発生した際に、事前登録した希望アクション（希望実施内容）の実施を要求するアラーム発生通知をネットワーク装置側からリソース管理サーバ３１００に対して送信し、リソース管理サーバ３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）３１０１側において、事前登録された希望アクション（希望実施内容）の実施の可否判断をプロファイル３１０４に基づいて行っている。
【０１７９】
したがって、従来技術におけるＳＮＭＰ Ｔｒａｐメッセージ（トラップメッセージ）などとは異なり、アラームの発生をリソース管理サーバ３１００に対して通報するだけではなく、アラーム発生通知に基づいて、事前登録の希望アクション（希望実施内用）としてあらかじめ登録された処理を実施させることができ、多数のネットワーク装置のリソース管理とアクション処理の管理とを一元化することができる。
【０１８０】
（実施形態の具体的構成例）
以上に説明した本発明に係るリソース管理システムのシステム構成について、例えば、ネットワーク装置として呼処理装置を対象とした場合の構成例を、図１３に示す。図１３は、本発明に係るリソース管理システムの具体的なシステム構成の一例を示すシステム構成図であり、呼処理ネットワークにおけるシステム構成例を示しており、図１の場合とは異なり、ネットワーク装置として呼処理装置を対象とし、該呼処理装置が呼処理の制御対象とするユーザ端末装置とネットワークを介して接続されている様子を示している。
【０１８１】
図３のシステム構成において、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０，呼処理装置Ａ３ １３０３０は、図３におけるネットワーク装置例えば装置Ａｎ ３０ｎ０と同様、それぞれ、リソース管理Ａｇｅｎｔ（リソース管理エージェント）を備えており、管理ネットワーク１３２００を介して、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）を備えているリソース管理サーバ１３１００と通信を行うことによって、リソースの管理を行っている。
【０１８２】
また、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０は、それぞれ、呼処理の制御対象となるユーザ端末群１３００１，ユーザ端末群１３００２とネットワーク１３３００を介して接続されている。ここで、現時点においては、ユーザ端末群１３００１，ユーザ端末群１３００２の端末数が、それぞれ、既に、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０それぞれに収容可能な端末数の最大限界値近くの端末数に達しているものと仮定する。一方、呼処理装置Ａ３ １３０３０は、管理ネットワーク１３２００およびネットワーク１３３００に接続されてオンライン状態になっているものの、呼処理の制御対象となるユーザ端末が存在していなく、ＶＬＡＮ（Virtual Local Area Network）機能を閉塞している状態になっているものと仮定する。
【０１８３】
また、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０は、それぞれ、図４の事前登録・削除要求処理のシーケンスにしたがって、リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に対して、収容端末数が収容可能端末数を超える場合には、収容端末数が少ない呼処理装置に呼処理を実施してもらいたいという希望アクション（希望実施内容）を事前登録しているものと仮定する。
【０１８４】
具体的には、収容端末数が収容可能端末数を超える場合には、図６に示したアラーム処理２のシーケンスにおいて説明したように、リソース管理サーバ１３１００側のＴｅｌｎｅｔクライアントから収容端末数が少ない呼処理装置側のＴｅｌｎｅｔサーバへＴｅｌｎｅｔ接続して、ＣＬＩ（Command Line Interface）によるコマンドを実行させることによって、ＣＬＩ上から割り出した呼処理装置のＶＬＡＮ機能の閉塞状態を解除させて、呼処理を実行できるようにしたり、あるいは、リソース確保のために必要とする装置設定を行うようなコマンドを投入したりすることを要求する希望アクション（希望実施内容）が事前登録されている。
【０１８５】
また、リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）は、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０，呼処理装置Ａ３ １３０３０の希望アクション（希望実施内容）を、図７に示した事前登録・削除要求パケットによって受け取って、表３に示したようなプロファイルとして保持して管理している。
【０１８６】
（実施形態の具体的構成例の動作の説明）
次に、図１３に示した具体的なシステム構成例における動作の一例を、図１３を用いてさらに説明する。
【０１８７】
図１３のシステム構成例において、前述したように、ユーザ端末群１３００１，ユーザ端末群１３００２の端末数が、それぞれ、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０それぞれの収容可能端末数の最大限界値近くの端末数に既に達している状態にある。
【０１８８】
かかる状態において、さらに、新しいユーザ端末群１３００３に対して呼処理サービスを提供し始めた場合、例えば、呼処理装置Ａ１ １３０１０によって新しいユーザ端末群１３００３に対する呼処理を実施しようとした場合には、呼処理装置Ａ１ １３０１０のリソースがあらかじめ定めたリソース閾値を超えてしまうため、呼処理装置Ａ１ １３０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）は、図１０に示したようなアラーム発生通知パケットをリソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）に対して送信して、事前登録されている希望アクション（希望処理要求）の実施を要求する。すなわち、収容可能端末数を超えるユーザ端末の呼処理を収容端末数が少ない呼処理装置によって実行することを要求する。
【０１８９】
リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）側においては、呼処理装置Ａ１ １３０１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）からのアラーム発生通知パケットを受け取ると、呼処理装置Ａ１ １３０１０，呼処理装置Ａ２ １３０２０，呼処理装置Ａ３ １３０３０に関するプロファイルのデータを参照して、収容端末数が最も少ない呼処理装置が、呼処理装置Ａ３ １３０３０であることを判別する。
【０１９０】
その結果、リソース管理サーバ１３１００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）は、図６に示したアラーム処理２のシーケンスにしたがって、シーケンスＳ６００４において、例えば、アプリケーションＸのＴｅｌｎｅｔクライアントからのＴｅｌｎｅｔ通信によって、収容端末数が最も少ない呼処理装置Ａ３ １３０３０のＶＬＡＮ機能の閉塞状態を解除させて、呼処理を実施できるようにし、新しいユーザ端末群１３００３に対して呼処理サービスを提供することができる状態に設定する。
【０１９１】
以上のように、各呼処理装置からの事前登録要求に基づいてそれぞれの希望アクション（希望実施内容）をプロファイルとして事前登録することによって、該プロファイルに基づいてリソース管理を行うことを可能にし、適切な収容端末数の割当を自動的に行うことが可能になる。
【０１９２】
（本実施形態の効果の説明）
以上に詳細に説明したように、本実施形態においては、以下に記載するような効果を奏することができる。
【０１９３】
第１の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション（処理実施内容）をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。
【０１９４】
第２の効果は、リソース管理サーバのリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）は、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション（処理実施内容）を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション（希望処理実施内容）を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。
【０１９５】
第３の効果は、ネットワークのリソースを管理するリソース管理サーバは、管理対象のネットワーク装置であるか否かを認証する仕組みを採用しているので、不正なネットワーク装置からのアクセスを確実に抑止して、不正なネットワーク装置によるリソース管理への悪影響を確実に防止することができることである。
【０１９６】
（本発明の他の実施形態）
次に、本発明の他の実施形態として、リソース管理システムの基本的構成は、前述した実施形態の場合と同様であるが、多階層のリソース管理を実現する場合の構成例について図１４を用いて説明する。図１４は、本発明によるリソース管理システムのシステム構成の図１とは異なる例を示すシステム構成図であり、ネットワーク全体のリソースを管理するリソース管理サーバが、多階層化（図１４の例においては２階層化）されて構成されている例を示している。つまり、本実施形態においては、多階層のリソース管理を実現するために、図１４に示すように、リソース管理Ａｇｅｎｔ（リソース管理エージェント）とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）とを併せ持つリソース管理サーバを設置している。
【０１９７】
図１４のシステム構成に示すように、最上位のリソース管理サーバＣ １４１００の配下に、下位層のリソース管理サーバＡ １４２１０とリソース管理サーバＢ １４３１０とが分散配置されており、最上位のリソース管理サーバＣ １４１００は、下位層のリソース管理サーバＡ １４２１０とリソース管理サーバＢ １４３１０とのリソースを管理する。また、リソース管理サーバＣ １４１００とリソース管理サーバＡ １４２１０およびリソース管理サーバＢ １４３１０との間は、管理ネットワークＣ １４４１０を介して接続される。
【０１９８】
最上位のリソース管理サーバＣ １４１００は、下位層のリソース管理サーバＡ １４２１０とリソース管理サーバＢ １４３１０とのリソースを管理するために、前述の図３に示したリソース管理サーバ３１００の場合と同様、リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４１０１を備えている。一方、下位層のリソース管理サーバＡ １４２１０は、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４２１１とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４２０１との双方を備え、同様に、リソース管理サーバＢ １４３１０も、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４３１１とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４３０１との双方を備えている。
【０１９９】
下位層のリソース管理サーバＡ １４２１０のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４２０１は、管理ネットワークＡ １４４２０を介して、管理対象のネットワーク装置として、装置Ａ１ １４５００と装置Ａ２ １４６００とを対象にしてリソース管理を実施する。このため、装置Ａ１ １４５００と装置Ａ２ １４６００とには、前述の図３に示した装置Ａｎ ３０ｎ０の場合と同様、それぞれ、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４５１０とリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４６１０とを備えている。
【０２００】
同様に、下位層のリソース管理サーバＢ １４７００のリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）１４３０１は、管理ネットワークＢ １４４３０を介して、装置Ｂ１ １４７００と装置Ｂ２ １４８００を対象にしてリソース管理を実施する。このため、装置Ｂ１ １４７００と装置Ｂ２ １４８００とには、前述の図３に示した装置Ａｎ ３０ｎ０の場合と同様、それぞれ、リソース管理Ａｇｅｎｔ（リソース管理エージェント）１４７１０とリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４８１０とを備えている。
【０２０１】
つまり、最上位のリソース管理サーバＣ １４１００の管理ドメインは、リソース管理サーバＡ １４２１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４２１１とリソース管理サーバＢ １４３１０のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４３１１となる。
【０２０２】
下位層のリソース管理サーバＡ １４２１０の管理ドメインは、装置Ａ１ １４５００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４５１０と装置Ａ２ １４６００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４６１０となり、下位層のリソース管理サーバＢ １４３１０の管理ドメインは、装置Ｂ１ １４７００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４７１０と装置Ｂ２ １４８００のリソース管理Ａｇｅｎｔ（リソース管理エージェント）１４８１０となる。
【０２０３】
かくのごとく、多階層のネットワークトポロジーにおけるリソース管理を行う場合、ネットワーク全体のリソースを管理するリソース管理サーバを多階層（図１４に示す例では２階層）に分散配置した構成とし、最上位のリソース管理サーバ以外の各階層のリソース管理サーバについては、リソース管理Ａｇｅｎｔ（リソース管理エージェント）とリソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）との双方を具備することにより、多階層のネットワークトポロジーにおいても、それぞれの階層ごとのリソース管理を迅速かつ確実に実施することが可能になる。
【０２０４】
以上、本発明の好適な実施形態の構成を説明した。しかし、かかる実施形態は、本発明の単なる例示に過ぎず、何ら本発明を限定するものではないことに留意されたい。本発明の要旨を逸脱することなく、特定用途に応じて種々の変形変更が可能であることが、当業者には容易に理解できよう。
【符号の説明】
【０２０５】
１１００ リソース管理サーバ
１１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１０１０ 装置Ａ１
１０ｎ０ 装置Ａｎ
１２００ ネットワーク
２０１０ 装置Ａ１
２０１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
２０ｎ０ 装置Ａｎ
２０ｎ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
２１００ リソース管理サーバ
２１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
３０ｍ０ 装置Ａｍ
３０ｍ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
３０ｍ２ アプリケーションＡｍ
３０ｎ０ 装置Ａｎ
３０ｎ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
３０ｎ２ アプリケーションＡｎ
３１００ リソース管理サーバ
３１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
３１０２ 認証管理
３１０３ アプリケーションＸ
３１０４ プロファイル
１３００１ ユーザ端末群
１３００２ ユーザ端末群
１３００３ ユーザ端末群
１３０１０ 呼処理装置Ａ１
１３０２０ 呼処理装置Ａ２
１３０３０ 呼処理装置Ａ３
１３１００ リソース管理サーバ
１３２００ 管理ネットワーク
１３３００ ネットワーク
１４１００ リソース管理サーバＣ
１４１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１４２０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１４２１０ リソース管理サーバＡ
１４２１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４３０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
１４３１０ リソース管理サーバＢ
１４３１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４４１０ 管理ネットワークＣ
１４４２０ 管理ネットワークＡ
１４４３０ 管理ネットワークＢ
１４５００ 装置Ａ１
１４５１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４６００ 装置Ａ２
１４６１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４７００ 装置Ｂ１
１４７１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１４８００ 装置Ｂ２
１４８１０ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１５０１０ 装置Ａ１
１５０１１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１５０ｎ０ 装置Ａｎ
１５０ｎ１ リソース管理Ａｇｅｎｔ（リソース管理エージェント）
１５１００ リソース管理サーバ
１５１０１ リソース管理Ｍａｎａｇｅｒ（リソース管理マネジャ）
Ｒ１１ インタフェース
Ｒ１２ インタフェース
Ｒｎ１ インタフェース
Ｒｎ２ インタフェース
Ｒｎ３ インタフェース
Ｒｎ４ インタフェース
Ｒｎ５ インタフェース
Ｒｎ６ インタフェース
Ｒｎ７ インタフェース
Ｒｎ８ インタフェース
Ｒｎ９ インタフェース
Ｒｎ１０ インタフェース
Ｒｎ１１ インタフェース
Ｒｎ１２ インタフェース
ＡＣＫ１ インタフェース
ＡＣＫｍ インタフェース
ＡＣＫｎ インタフェース
【特許請求の範囲】
【請求項１】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えたリソース管理システムにおいて、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理システム。
【請求項２】
前記リソース管理サーバは、前記ネットワーク装置からアクセスがあった際に、当該ネットワーク装置が、リソース管理対象としている正当なネットワーク装置であるか否かを認証する認証管理手段を備えていることを特徴とする請求項１に記載のリソース管理システム。
【請求項３】
前記リソース管理サーバは、前記プロファイルとして、各前記ネットワーク装置ごとに、複数の前記希望アクションを登録することができ、かつ、それぞれの前記希望アクションに関する希望優先度、実施対象とするネットワーク装置、実施開始時刻、実施回数および実施履歴の１ないし複数を少なくとも含む情報を保持していることを特徴とする請求項１または２に記載のリソース管理システム。
【請求項４】
前記リソース管理サーバが、ＳＮＭＰ(Simple Network Management Protocol)準拠のリソース管理マネジャ機能を有し、各前記ネットワーク装置が、ＳＮＭＰ準拠のリソース管理エージェント機能を有していることを特徴とする請求項１ないし３のいずれかに記載のリソース管理システム。
【請求項５】
前記リソース管理サーバを、階層構造の複数のリソース管理サーバとして構成し、最上位のリソース管理サーバは、ＳＮＭＰ準拠のリソース管理マネジャ機能を有し、最上位のリソース管理サーバ以外の各リソース管理サーバが、ＳＮＭＰ準拠のリソース管理マネジャ機能とリソース管理エージェント機能との双方の機能を有して構成されていることを特徴とする請求項１ないし４のいずれかに記載のリソース管理システム。
【請求項６】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバにおいて、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録しておき、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理サーバ。
【請求項７】
ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置において、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信することを特徴とするネットワーク装置。
【請求項８】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えることにより、ネットワーク全体のリソース状態を管理するリソース管理方法であって、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理方法。
【請求項９】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバに、プログラムを実行可能なコンピュータを備え、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録するステップと、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うステップと、を前記コンピュータによりプログラムとして実行することを特徴とするリソース管理プログラム。
【請求項１０】
ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置に、プログラムを実行可能なコンピュータを備え、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録するステップと、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信するステップと、を前記コンピュータによりプログラムとして実行することを特徴とするリソース管理プログラム。
【請求項１】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えたリソース管理システムにおいて、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理システム。
【請求項２】
前記リソース管理サーバは、前記ネットワーク装置からアクセスがあった際に、当該ネットワーク装置が、リソース管理対象としている正当なネットワーク装置であるか否かを認証する認証管理手段を備えていることを特徴とする請求項１に記載のリソース管理システム。
【請求項３】
前記リソース管理サーバは、前記プロファイルとして、各前記ネットワーク装置ごとに、複数の前記希望アクションを登録することができ、かつ、それぞれの前記希望アクションに関する希望優先度、実施対象とするネットワーク装置、実施開始時刻、実施回数および実施履歴の１ないし複数を少なくとも含む情報を保持していることを特徴とする請求項１または２に記載のリソース管理システム。
【請求項４】
前記リソース管理サーバが、ＳＮＭＰ(Simple Network Management Protocol)準拠のリソース管理マネジャ機能を有し、各前記ネットワーク装置が、ＳＮＭＰ準拠のリソース管理エージェント機能を有していることを特徴とする請求項１ないし３のいずれかに記載のリソース管理システム。
【請求項５】
前記リソース管理サーバを、階層構造の複数のリソース管理サーバとして構成し、最上位のリソース管理サーバは、ＳＮＭＰ準拠のリソース管理マネジャ機能を有し、最上位のリソース管理サーバ以外の各リソース管理サーバが、ＳＮＭＰ準拠のリソース管理マネジャ機能とリソース管理エージェント機能との双方の機能を有して構成されていることを特徴とする請求項１ないし４のいずれかに記載のリソース管理システム。
【請求項６】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバにおいて、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録しておき、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理サーバ。
【請求項７】
ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置において、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信することを特徴とするネットワーク装置。
【請求項８】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えることにより、ネットワーク全体のリソース状態を管理するリソース管理方法であって、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理方法。
【請求項９】
ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバに、プログラムを実行可能なコンピュータを備え、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録するステップと、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うステップと、を前記コンピュータによりプログラムとして実行することを特徴とするリソース管理プログラム。
【請求項１０】
ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置に、プログラムを実行可能なコンピュータを備え、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録するステップと、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信するステップと、を前記コンピュータによりプログラムとして実行することを特徴とするリソース管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１２−２２７７３６（Ｐ２０１２−２２７７３６Ａ）
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願番号】特願２０１１−９３６１２（Ｐ２０１１−９３６１２）
【出願日】平成２３年４月２０日（２０１１．４．２０）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願日】平成２３年４月２０日（２０１１．４．２０）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]