"ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えたリソース管理システムにおいて、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理システム。前記リソース管理サーバは、前記ネットワーク装置からアクセスがあった際に、当該ネットワーク装置が、リソース管理対象としている正当なネットワーク装置であるか否かを認証する認証管理手段を備えていることを特徴とする請求項1に記載のリソース管理システム。前記リソース管理サーバは、前記プロファイルとして、各前記ネットワーク装置ごとに、複数の前記希望アクションを登録することができ、かつ、それぞれの前記希望アクションに関する希望優先度、実施対象とするネットワーク装置、実施開始時刻、実施回数および実施履歴の1ないし複数を少なくとも含む情報を保持していることを特徴とする請求項1または2に記載のリソース管理システム。前記リソース管理サーバが、SNMP準拠のリソース管理マネジャ機能を有し、各前記ネットワーク装置が、SNMP準拠のリソース管理エージェント機能を有していることを特徴とする請求項1ないし3のいずれかに記載のリソース管理システム。前記リソース管理サーバを、階層構造の複数のリソース管理サーバとして構成し、最上位のリソース管理サーバは、SNMP準拠のリソース管理マネジャ機能を有し、最上位のリソース管理サーバ以外の各リソース管理サーバが、SNMP準拠のリソース管理マネジャ機能とリソース管理エージェント機能との双方の機能を有して構成されていることを特徴とする請求項1ないし4のいずれかに記載のリソース管理システム。ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバにおいて、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録しておき、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理サーバ。ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置において、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信することを特徴とするネットワーク装置。ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えることにより、ネットワーク全体のリソース状態を管理するリソース管理方法であって、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とするリソース管理方法。ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバに、プログラムを実行可能なコンピュータを備え、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録するステップと、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うステップと、を前記コンピュータによりプログラムとして実行することを特徴とするリソース管理プログラム。ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置に、プログラムを実行可能なコンピュータを備え、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録するステップと、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信するステップと、を前記コンピュータによりプログラムとして実行することを特徴とするリソース管理プログラム。図15に示した現状のリソース管理システムの場合、リソース管理サーバ側から管理対象の各ネットワーク装置のアラーム閾値を設定することによってネットワーク全体のリソース管理を実施しているが、管理対象の各ネットワーク装置側から希望するアクション処理実施内容をリソース管理サーバ側へ依頼することによって、リソースの再配置を行って、ネットワーク全体のリソース状況を最適化するというものではなかった。つまり、前述のように、SNMPTrapメッセージを用いた監視方法は、単に、アラームを検知したことをリソース管理サーバ側に通知するのみであり、リソース不足を解消するために実施して欲しい具体的なアクション処理実施内容を通知して依頼することができないし、さらには、ネットワーク全体のリソース配分を最適化するために、他のネットワーク装置に対して具体的なアクション処理実施内容を実施させることもできなかった。したがって、アラームを検知しても、管理者が手動でアラーム内容を解析して適切と思われる処理を施すことが多かったため、本当に適切なリソース割当処理を実施するまでに時間がかかることが多かった。このため、現状のリソース不足検知機能においては、次のような課題がある。第1の課題は、リソース管理サーバのアラーム画面を、管理者が常に監視していることが必要であり、ヒューマンリソースが常に必要であるということにある。第2の課題は、リソース管理サーバは、管理者が介在して、管理ネットワークの管理対象の各ネットワーク装置におけるリソースの配分状況をチェックして、リソース不足に対する処置を、リソース不足を解消させるための具体的な処理実施内容として管理対象の各ネットワーク装置に対して適切に施さないといけないため、リソースの再配置処理に時間がかかってしまうということにある。第3の課題は、管理対象のネットワーク装置が異なると、リソース不足の発生形態例えばSYSLOGメッセージの内容が異なる可能性があるので、リソースを管理するリソース管理サーバ側としては、リソース不足のアラーム通知を受け取っても、リソース不足を解消させるために実施すべきアクション処理実施内容が各ネットワーク装置ごとに異なる可能性が大きく、実施すべきアクション処理実施内容を決定することが非常に厄介になるということにある。本発明の目的本発明は、かかる課題に鑑みてなされたものであり、リソース管理サーバ側と管理対象の各ネットワーク装置側とのネゴシエーションを行うことにより、ネットワーク全体のリソースの最適化を迅速かつ確実に行うことが可能なリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムを提供することを、その目的としている。つまり、本発明は、管理対象のネットワーク装置においてリソース不足が発生した際に実施すべきアクション処理実施内容を、ネットワーク全体のリソースの管理を行うリソース管理サーバに対して管理対象のネットワーク装置から希望アクション希望実施内容としてあらかじめ事前登録しておくことによって、突然発生したリソース不足に対して、事前登録された希望アクション希望実施内容にしたがって、最適なリソースの再配置を自動的にかつ短時間に実施する仕組みを提供することを、その目的としている。前述の課題を解決するため、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムは、主に、次のような特徴的な構成を採用している。1本発明によるリソース管理システムは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えたリソース管理システムにおいて、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。2本発明によるリソース管理サーバは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバにおいて、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして事前に登録しておき、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。3本発明によるネットワーク装置は、ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置において、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信することを特徴とする。4本発明によるリソース管理方法は、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバを備えることにより、ネットワーク全体のリソース状態を管理するリソース管理方法であって、管理対象の各前記ネットワーク装置は、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションを各前記ネットワーク装置のリソース状態とともにプロファイルとして前記リソース管理サーバに事前に登録しておき、前記リソース管理サーバは、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うことを特徴とする。5本発明によるリソース管理プログラムは、ネットワークを構成する各ネットワーク装置のリソース状態を管理するリソース管理サーバに、プログラムを実行可能なコンピュータを備え、管理対象の前記ネットワーク装置にてリソース不足が発生した際に実施して欲しい希望アクションをプロファイルとして各前記ネットワーク装置のリソース状態とともに事前に登録するステップと、前記ネットワーク装置からリソース不足が発生した旨の通知を受け取った際に、ネットワーク全体の各前記ネットワーク装置の希望アクションとリソース状態とを保持している前記プロファイルを参照することにより、リソース割当に関する制御を行うステップと、を前記コンピュータによりプログラムとして実行することを特徴とする。6本発明による別のリソース管理プログラムは、ネットワークを構成するネットワーク装置であって、当該ネットワーク全体のリソース状態を管理するリソース管理サーバによってリソース状態を管理されるネットワーク装置に、プログラムを実行可能なコンピュータを備え、リソース不足が発生した際に前記リソース管理サーバ側で実施して欲しい希望アクションをリソース状態とともにプロファイルとして前記ソース管理サーバに事前に登録するステップと、リソース不足が実際に発生した際に、事前登録している前記希望アクションの実施を要求するアラーム発生通知を、前記リソース管理サーバに対して送信するステップと、を前記コンピュータによりプログラムとして実行することを特徴とする。本発明のリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムによれば、以下のような効果を奏することができる。第1の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション処理実施内容をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。第2の効果は、リソース管理サーバは、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション処理実施内容を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション希望処理実施内容を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。以下、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムの好適な実施形態について添付図を参照して説明する。なお、以下の説明においては、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置およびリソース管理方法について説明するが、かかるリソース管理方法をコンピュータにより実行可能なリソース管理プログラムとして実施するようにしても良いし、あるいは、リソース管理プログラムをコンピュータにより読み取り可能な記録媒体に記録するようにしても良いことは言うまでもない。本発明の特徴本発明の実施形態の説明に先立って、本発明の特徴についてその概要をまず説明する。本発明は、ネットワーク全体のリソースの管理を行うリソース管理サーバにおいて、管理対象のネットワーク装置がリソース不足になった場合に、リソース管理サーバのリソース管理Managerリソース管理マネジャが実施すべきアクション処理実施内容を、管理対象の各ネットワーク装置のリソース管理Agentリソース管理エージェントそれぞれからリソース管理Managerリソース管理マネジャへあらかじめ事前登録しておくことにより、リソース管理サーバ側から、管理対象のネットワーク装置の運用状況を考慮した適切なリソース割当とアクションの実施とを可能にしていることを主要な特徴としている。つまり、本発明は、管理対象のネットワーク装置がリソース不足に陥った時に、当該ネットワーク装置側が希望するアクション処理実施内容をリソース管理サーバのリソース管理Managerリソース管理マネジャに事前登録しておくことにより、実際にリソース不足が発生した際に、当該リソース不足を解消させるための最適なアクション処理実施内容を速やかに、滞りなく実施することができ、リソースの最適割当を迅速に行うことができるようになっている。また、本発明は、他のネットワーク装置のリソース使用状況、つまり、管理ネットワーク全体のリソース使用状況をも考慮して、リソース管理サーバのリソース管理Managerリソース管理マネジャが実施すべきアクション処理実施内容を判断することができるように、ネットワーク全体の各ネットワーク装置からの希望アクション希望実施内容を、各ネットワーク装置のリソース状態とともにプロファイルとしてあらかじめ設定し、リソース不足に陥ったネットワーク装置側が事前登録したアクション処理内容を実施することが適切か否かを判断することができる処理シーケンスを採用している。さらに、本発明は、リソース管理サーバのリソース管理Managerリソース管理マネジャに対してアクセスしてきたネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証する仕組みを採用しており、不正なネットワーク装置によってリソース管理への悪影響を防止するようにしている。例えば、不正なネットワーク装置が、リソース管理サーバが管理対象としている他のいずれかのネットワーク装置をシャットダウンさせるようなコマンドの実行を事前登録しておいて、リソース不足を示すアラーム発生通知をリソース管理サーバのリソース管理Managerリソース管理マネジャに送信してくるようなことがあると、事前登録されているアクション他のいずれかのネットワーク装置をシャットダウンさせる処理内容が実施されてしまって、ネットワークのリソース管理を適切に実施することができなくなるので、リソース不足時のアクションを事前登録するネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証するようにしている。本発明の実施形態次に、本発明の実施形態について図を参照しながら詳細に説明する。本発明の実施形態は、図1に示すように、ネットワーク全体のリソースを管理するリソース管理サーバと、リソースの管理対象となる呼処理装置や無線制御装置やルータやハブ等のネットワーク装置と、リソース管理サーバと各ネットワーク装置との間を接続する管理ネットワークと、からなるリソース管理システムに関するものであり、前述したように、管理対象のネットワーク装置がリソース不足になった場合に、ネットワーク全体の運用状況を考慮して、リソース管理サーバ側から適切なリソース割当とアクションの実施とを可能にしている。図1は、本発明によるリソース管理システムのシステム構成の一例を示すシステム構成図である。図1に示すリソース管理システムは、ネットワーク全体のリソースを管理するリソース管理サーバ1100、リソースの管理対象となる1ないし複数のネットワーク装置に相当する装置A11010,...,装置An10n0、および、SNMPプロトコルを用いた管理ネットワークであるネットワーク1200によって構成されている。図1において、装置A11010ないし装置An10n0は、それぞれ、リソース管理サーバ1100に対して、ネットワーク1200を介して、あらかじめ定めた周期やリソースの使用状況に変化が発生する都度、自装置のリソース状況を通知している。リソース管理サーバ1100は、装置A11010ないし装置An10n0それぞれのリソース使用状況を、ネットワーク1200を介して受信して、ネットワーク1200全体のリソースの使用状況をプロファイルとして保持して管理している。次に、図1のリソース管理システムにおける装置A11010ないし装置An10n0およびリソース管理サーバ1100のリソース管理に関する部位について、その一例を、図2を用いて説明する。図2は、図1のリソース管理システムにおけるリソース管理サーバ1100および各ネットワーク装置すなわち装置A11010,...,装置An10n0の装置構成の一例を説明するための説明図であり、装置A11010ないし装置An10n0とリソース管理サーバ1100とにおける各リソース管理用の機能部と、装置A11010ないし装置An10n0とリソース管理サーバ1100との間のインタフェースについて示している。なお、図2には、図1のリソース管理サーバ1100、装置A11010,...,装置An10n0を、それぞれ、リソース管理サーバ2100、装置A12010,...,装置An20n0と、千番台の符号を図番号に対応する形で変更して示している。また、以下の各図面においても、同様に、符号を図番号に対応する形で変更している。図2において、装置A12010のリソース管理Agentリソース管理エージェント2011ないし装置An20n0のリソース管理Agentリソース管理エージェント20n1は、それぞれ、自装置のリソース状況を保持している。また、装置A12010のリソース管理Agentリソース管理エージェント2011ないし装置An20n0のリソース管理Agentリソース管理エージェント20n1は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定している。装置A22010のリソース管理Agentリソース管理エージェント2011ないし装置An20n0のリソース管理Agentリソース管理エージェント20n1は、それぞれに設定した該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、インタフェースR11ないしインタフェースRn1を経由して、図1に示したネットワーク1200を介して、リソース管理サーバ2100のリソース管理Managerリソース管理マネジャ2101に対してアラーム発生通知を行い、あらかじめ事前登録しておいた希望アクション希望実施内容の実施を要求する。リソース管理サーバ2100のリソース管理Managerリソース管理マネジャ2101は、装置A12010のリソース管理Agentリソース管理エージェント2011ないし装置An20n0のリソース管理Agentリソース管理エージェント20n1からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理リソースの再割当処理等を実施して、実施結果を示す応答アラーム発生応答を、アラーム発生通知元の装置A12010のリソース管理Agentリソース管理エージェント2011ないし装置An20n0のリソース管理Agentリソース管理エージェント20n1に対して、それぞれ、インタフェースR12ないしインタフェースRn2を経由して、図1に示したネットワーク1200を介して返送する。装置A12010のリソース管理Agentリソース管理エージェント2011ないし装置An20n0のリソース管理Agentリソース管理エージェント20n1は、リソース管理サーバ2100のリソース管理Managerリソース管理マネジャ2101からの応答アラーム発生応答を受け取ると、該応答を正常に受信した旨を示す応答ACKを生成して、それぞれ、インタフェースACK1ないしインタフェースACKnを経由して、図1に示したネットワーク1200を介して、リソース管理サーバ2100のリソース管理Managerリソース管理マネジャ2101に対して返送する。次に、図1のリソース管理システムにおけるリソース管理サーバ1100のリソース管理に関する部位と管理対象のネットワーク装置である装置A11010ないし装置An10n0との間のさらに詳細なインタフェースについて、その一例を、図3を用いて説明する。図3は、図1のリソース管理システムにおけるリソース管理サーバ1100と各ネットワーク装置すなわち装置A11010,...,装置An10n0との間のリソース管理に関するインタフェースの一例を説明するための説明図であり、装置A11010ないし装置An10n0のうち、第m番目と第n番目の装置を取り出して、リソース管理サーバ1100のリソース管理用の機能部と、管理対象のネットワーク装置である装置Am10m0、装置An10n0との間のリソース管理に関する全インタフェースについて示している。なお、図3においても、前述したように、図1のリソース管理サーバ1100、装置Am10m0、装置An10n0を、それぞれ、リソース管理サーバ3100、装置Am30m0、装置An30n0と、千番台の符号を図番号に対応する形で変更して示している。また、図2のリソース管理サーバ2100のリソース管理Managerリソース管理マネジャ2101についても、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101と、千番台の符号を図番号に対応する形で変更している。さらに、図2の装置A12010のリソース管理Agentリソース管理エージェント2011、装置An20n0のリソース管理Agentリソース管理エージェント20n1についても、それぞれ、装置Am30m0のリソース管理Agentリソース管理エージェント30m1、装置An30n0のリソース管理Agentリソース管理エージェント30n1と、千番台の符号を図番号に対応する形で変更して示している。図3においても、図2の場合と同様、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101は、装置Am30m0のリソース管理Agentリソース管理エージェント30m1、装置An30n0のリソース管理Agentリソース管理エージェント30n1からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理リソースの割当処理を実施して、実施結果を示す応答アラーム発生応答を、アラーム発生通知元の装置Am30m0のリソース管理Agentリソース管理エージェント30m1、装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して送信している。また、装置Am30m0のリソース管理Agentリソース管理エージェント30m1、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、図2の場合と同様、それぞれ、自装置のリソース状況を保持している。さらに、装置Am30m0のリソース管理Agentリソース管理エージェント30m1、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定し、該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対してアラーム発生通知の送信を行っている。図3に示すように、リソース管理サーバ3100は、リソース管理Managerリソース管理マネジャ3101に、管理対象の各ネットワーク装置である装置Am30m0、装置An30n0ごとに、それぞれのリソース管理に関する情報希望アクション希望する処理実施内容、処理開始時刻、処理実施履歴、リソース状況等を登録保持しているデータベースとしてプロファイル3104を所持している他、アクセスしてくる各ネットワーク装置例えば装置Am30m0、装置An30n0の認証を行う認証管理3102、リソース管理に関するアプリ処理を実行するアプリケーションX3103の各機能部を有している。また、装置Am30m0、装置An30n0にも、それぞれ、リソース管理に関するアプリ処理を実行するアプリケーションAm30m2、アプリケーションAn30n2、の機能部を有している。図3に示す各機能部および各機能部間のインタフェースに関する説明を、次の表1に示している。装置An30n0、装置Am30m0は、いずれも、前述したように、リソース管理サーバ3100のリソース管理対象となるネットワーク装置であり、図3においては、装置An30n0にリソース不足が発生して、装置An30n0からリソース管理サーバ3100に対してアラーム発生通知を送信した場合に、ネットワーク全体のリソース配分を最適化するために、リソース管理サーバ3100のアプリケーションX3103が、アラーム発生通知元とは異なる他のネットワーク装置の装置Am30m0に対してアクションを指示する場合がある例も説明することとする。表1に示すように、装置An30n0のリソース管理Agentリソース管理エージェント30n1、装置Am30m0のリソース管理Agentリソース管理エージェント30m1は、いずれも、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101との間のネゴシエーションを行い、自装置内のリソースを管理するアプリケーションであり、使用するリソースが使用可能な限界値としてあらかじめ設定されたリソース閾値を超えた場合に、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して、事前に登録された希望アクション希望実施内容を実施することを要求するアラーム発生通知を送信する。装置An30n0のアプリケーションAn30n2は、使用するリソースがリソース閾値を超えた場合にリソース管理Agentリソース管理エージェント30n1にてアラーム発生通知をリソース管理サーバ3100に送信した結果として、リソース管理サーバ3100のアプリケーションX3103からの要求に基づいて実施されるリソース管理関連のアプリケーションであり、装置An30n0に常駐しており、アプリケーションX3103からの要求に応じて、いつでも実行することが可能である。これに対して、装置Am30m0のアプリケーションAm30m2は、リソース管理サーバ3100のアプリケーションX3103からのアラーム処理要求があった場合に、該アラーム処理要求に該当する処理内容を実行して、処理結果をアラーム処理要求元のリソース管理サーバ3100のアプリケーションX3103に対して返送するリソース管理関連のアプリケーションであり、装置Am30m0に常駐しており、アプリケーションX3103からのアラーム処理要求に応じて、いつでも実行することが可能である。リソース管理サーバ3100は、図3においては、リソースの管理対象のネットワーク装置である装置An30n0のリソース使用状況を監視する監視サーバであり、装置An30n0のリソースがリソース閾値を超えた場合に装置An30n0から送信されてくるアラーム発生通知に応じて、当該リソース管理サーバ3100にあらかじめ設定登録されている希望アクション希望実施内容を実施するようにアプリケーションX3103に対して指示する。また、アラーム発生通知を送信してきた装置An30n0がリソース管理対象のネットワーク装置であるか否かを認証する動作を実施して、リソース管理サーバ3100への不適当なネットワーク装置からの不正接続を防止する機能も有している。つまり、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101は、リソースの管理対象のネットワーク装置である装置An30n0の装置起動時に送信されてくる希望アクション希望実施内容の事前登録要求を受け取った際に、要求元の装置An30n0の認証を行うために、認証管理3102に対して認証要求を行う。また、リソース管理Managerリソース管理マネジャ3101は、装置An30n0のリソース管理Agentリソース管理エージェント30n1がリソース閾値を超えたことを検知した際に送信してくるアラーム発生通知を受け取った際に、事前に設定登録された希望アクション希望実施内容に基づいて適切な判断を行い、必要に応じてアプリケーションX3103に対してアラーム処理要求を出力する。なお、リソース管理Managerリソース管理マネジャ3101は、リソースの管理対象のネットワーク装置であるすべての装置図3の場合、装置An30n0、装置Am30m0の2つのネットワーク装置を示しているのリソース管理Agentリソース管理エージェント30i1i=1,2,...,m,...nに関するプロファイル3104を備えており、必要に応じて、プロファイル3104に保持されている各ネットワーク装置のデータを参照することが可能である。ここで、プロファイル3104は、管理対象の各ネットワーク装置の希望アクション希望実施内容:リソース不足発生時にリソース管理サーバ3100側で実施して欲しい処理内容を、各ネットワーク装置のリソース状態とともに事前登録しているものであり、リソース管理Agentリソース管理エージェント30i1i=1,2,...,m,...nを有するすべてのネットワーク装置図3の場合、装置An30n0、装置Am30m0の2つのネットワーク装置それぞれが希望する処理実施内容や実施開始時刻等に関する希望アクション情報をリソース状態とともに設定しているデータベースである。リソース管理Managerリソース管理マネジャ3101は、必要に応じて、プロファイル3104のデータ例えばアラーム発生通知の送信元の装置An30n0のデータを参照して、希望するアクション処理実施内容を決定して実施する。リソース管理サーバ3100の認証管理3102は、リソース管理Managerリソース管理マネジャ3101からの要求があった装置An30n0が、管理対象のネットワーク装置として管理すべきネットワーク装置であるか否かを認証する処理を実施する。リソース管理サーバ3100のアプリケーションX3103は、リソース管理Managerリソース管理マネジャ3101からアラーム処理要求を受け取った場合、つまり、装置An30n0のリソース管理Agentリソース管理エージェント30n1からアラーム発生通知を受け取ったリソース管理Managerリソース管理マネジャ3101がアプリケーションX3103による処理が必要であると判断した場合、アラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2、または、該送信元とは異なる他のネットワーク装置例えば装置Am30m0のアプリケーションAm30m2に対して、事前に設定登録されているアクション処理内容の実行を要求するアラーム処理要求を送信する。ここで、アプリケーションX3103は、特定のアプリケーションを意味しているものではなく、アラーム発生通知の内容とプロファイル3104に設定されているデータとを参照した結果による判断結果に基づいてリソース管理Managerリソース管理マネジャ3101によって選択されて指示されたアプリケーションのことである。また、インタフェースRnjj=1,2,7,8,9,10,11,12、ACKn、ACKmは、異なる装置間で通信するためのインタフェースであり、インタフェースRn3,4,5,6は、リソース管理サーバ3100内の機能部間で通信するためのAPIApplicationProgramInterfaceである。より詳細には、インタフェースRn1は、装置An30n0のリソース管理Agentリソース管理エージェント30n1がリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースRn2は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からアラーム発生通知の送信元の装置An30n0のリソース管理Agentリソース管理エージェント30n1に対してアクションの実施結果を示す処理応答アラーム発生応答を送信するためのインタフェースである。また、インタフェースRn3は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から認証管理3102に対して認証要求を送信するためのAPIであり、インタフェースRn4は、リソース管理サーバ3100の認証管理3102からリソース管理Managerリソース管理マネジャ3101に対して認証結果を送信するためのAPIである。また、インタフェースRn5は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からアプリケーションX3103に対して指定したアプリ実行要求を送信するためのAPIであり、インタフェースRn6は、リソース管理サーバ3100のアプリケーションX3103からリソース管理Managerリソース管理マネジャ3101に対してアプリ実行結果を送信するためのAPIである。また、インタフェースRn7は、リソース管理サーバ3100のアプリケーションX3103からアラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースRn8は、アラーム処理要求の送信先の装置An30n0のアプリケーションAn30n2からリソース管理サーバ3100のアプリケーションX3103に対して処理結果を示す応答を送信するためのインタフェースである。また、インタフェースRn9は、リソース管理サーバ3100のアプリケーションX3103からアラーム発生通知の送信元とは異なる装置Am30m0のアプリケーションAm30m2に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースRn10は、アラーム処理要求の送信先の装置Am30m0のアプリケーションAm30m2からリソース管理サーバ3100のアプリケーションX3103に対して処理結果を示す応答を送信するためのインタフェースである。また、インタフェースRn11は、装置Am30m0のリソース管理Agentリソース管理エージェント30m1がリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースRn12は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からアラーム発生通知の送信元の装置Am30m0のリソース管理Agentリソース管理エージェント30m1に対してアクションの実施結果を示す処理応答アラーム発生応答を送信するためのインタフェースである。また、インタフェースACKnは、装置An30n0のリソース管理Agentリソース管理エージェント30n1がリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して処理応答を正常に受け取った旨を示す応答ACKを送信するためのインタフェースであり、インタフェースACKmは、装置Am30m0のリソース管理Agentリソース管理エージェント30m1がリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して処理応答を正常に受け取った旨を示す応答ACKを送信するためのインタフェースである。次に、図3のリソース管理システムに示したリソース管理サーバ3100と管理対象のネットワーク装置である装置An30n0との間の通信シーケンスについて、装置An30n0から事前に設定登録する希望実施内容すなわち希望アクションの登録および希望実施内容すなわり希望アクションの削除を行う際のシーケンスの一例を、図4を用いて説明する。図4は、図3のリソース管理システムにおける希望アクション希望実施内容の事前登録シーケンスおよび希望アクション希望実施内容の削除シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置A13010ないし装置An30n0のうち、いずれかのネットワーク装置例えば第n番目の装置An30n0のリソース管理Agentリソース管理エージェント30n1からのリソース管理サーバ3100に対する事前登録要求があった際に、希望アクション希望実施内容を事前に設定登録し、かつ、事前登録削除要求に応じて、設定登録していた希望アクション希望実施内容を削除する場合のシーケンスについて示している。装置An30n0は、収容する端末数の変化やネットワークのリソース変動等に伴って、使用するリソースがあらかじめ設定したリソース閾値を超えた場合に、リソース管理サーバ3100に対してアラーム発生通知を送信することによって、あらかじめ事前に設定登録している希望アクション希望実施内容の実施を要求する。ここで、実施してもらいたい希望アクション希望実施内容とは、例えば、装置An30n0を利用する端末数が増加したために、装置An30n0の使用可能なリソース量を増加させるようなリソースの再配分を実施してもらうことを要求したり、あるいは、新たな装置Am30m0に増加した一部または全ての端末を収容させるために、装置Am30m0の閉塞状態を解除することを要求したりする場合を意味している。以下においては、図4のシーケンスで示す一連の処理を事前登録削除処理と称することにする。図4のシーケンスチャートにおいて、まず、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、装置起動時に、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して、図7に示すフォーマットからなる事前登録削除要求パケットを送信するシーケンスS4001。図7は、図3のリソース管理システムにおいてネットワーク装置の装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信される事前登録削除要求パケットのフォーマットの一例を示すテーブルである。ここで、図7に示す事前登録削除要求パケットは、UDPUserDatagramprotocolパケット上のペイロードとして扱われ、リソース閾値を超えた場合にアラーム発生通知をリソース管理サーバ3100に送信することによって、リソース管理サーバ3100側で実施して欲しい希望アクション希望実施内容をリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に事前登録するために用いられ、また、事前登録されている希望アクション希望実施内容に関する情報を削除するために用いられる。具体的には、図7に示す事前登録削除要求パケットは、バージョン、ヘッダ長、パケット長、タイプ、要求数、シーケンス番号、承認キー、予約の各情報からなるヘッダ情報に引き続くデータ領域に、実施して欲しい希望アクション希望実施内容に関する情報として、希望優先度、指示対象名、実施回数、仮登録番号、開始時刻、希望実施内容を1組の希望アクションとし、必要に応じて、優先度を付して、希望アクション1,...,希望アクションjと複数組纏めて収容することができる。図7に示す事前登録削除要求パケットに設定されるそれぞれの情報の意味は、次の表2に示す通りである。なお、表2には、後述する図8の事前登録削除応答パケット、図9の事前登録削除応答ACKパケット、図10のアラーム発生通知パケット、図11のアラーム発生応答パケット、図12のアラーム発生応答ACKパケットに設定される情報の意味についても併せて説明しているので、後述する該当の箇所においても、表2をそれぞれ参照されたい。表2に示すように、図7に示す事前登録削除要求パケットのヘッダ情報内のバージョンフィールドは、当該パケットフォーマットタイプのバージョンを示す情報であり、送信元のネットワーク装置の装置An30n0のリソース管理Agentリソース管理エージェント30n1と送信先のリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101との双方で同じ方式のパケットフォーマットを用いて通信を行うために設定している。また、事前登録削除要求パケットのヘッダ情報内のヘッダ長フィールドは、事前登録削除要求パケットのヘッダ情報の長さバイト数を示している。図7に示す事前登録削除要求パケットの場合は12バイトである。また、事前登録削除要求パケットのヘッダ情報内のパケット長フィールドは、データ領域に収容している希望アクション1、...、希望アクションjの合計のメッセージサイズを設定し、ヘッダ情報内のタイプフィールドは、当該事前登録削除要求パケットの種別を示し、事前登録要求であるか事前登録内容の削除要求であるかを設定する。また、事前登録削除要求パケットのヘッダ情報内の要求数フィールドは、希望アクション希望実施内容の個数図7に示す例では、j個を設定し、事前登録削除要求パケットのヘッダ情報内のシーケンス番号フィールドは、イベントが発生する都度、装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101へ送信したパケットの送信順を示す番号を設定する。また、事前登録削除要求パケットのヘッダ情報内の承認キーフィールドには、事前登録要求時には、0が設定され、事前登録した希望アクション希望実施内容の削除要求時には、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において事前登録要求時に要求元の装置An30n0のリソース管理Agentリソース管理エージェント30n1が承認されることによって付与されていた承認キーが設定される。なお、ヘッダ情報内の予約フィールドは、現在使用されていないダミー領域である。また、事前登録削除要求パケットのデータ領域内の希望優先度フィールドは、複数の希望アクション希望実施内容を事前登録しようとする場合にそれぞれの希望アクションの優先順位を設定する。なお、複数の希望アクションに同一値の優先度が付されていた場合には、ヘッダ情報側に近い希望アクションほど優先して処理が実施されることにする。ただし、該希望優先度については、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101側で、必要に応じて、優先順を変更することが可能である。また、事前登録削除要求パケットのデータ領域内において希望アクションごとに設定される指示対象名フィールドは、リソース管理サーバ3100のアプリケーションX3103から、複数のネットワーク装置すなわち装置A13010,...,装置An30n0のうち、設定したネットワーク装置例えば装置AiのアプリケーションAiに対して、アラーム処理要求を送信して、希望アクション希望実施内容を実施してもらうことを示している。また、事前登録削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数フィールドは、希望アクション希望実施内容を実施する回数を設定する。また、事前登録削除要求パケットのデータ領域内において希望アクションごとに設定される仮登録番号フィールドは、事前登録要求元の装置An30n0のリソース管理Agentリソース管理エージェント30n1側において、実施を希望する処理実施内容すなわち希望アクション希望実施内容を管理するために使用されるユニークな仮の登録番号を設定する。該仮登録番号は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において本登録キーが発行完了されて、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から通知されてくるまでの一時的なキーとして扱われる。なお、事前登録削除要求パケットとして、事前登録された希望アクション希望実施内容を削除することを要求する場合には、既に、本登録キーが付与された状態にあるので、仮登録番号の代わりに、本登録キーを用いる。また、削除要求の場合には、事前登録削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数、開始時刻、希望実施内容の各フィールドを省略することも可能である。また、すべての希望アクション希望実施内容を削除する場合には、場合によっては、ヘッダ情報のみからなる事前登録削除要求パケットを用いるようにしても良い。また、事前登録削除要求パケットのデータ領域内において希望アクションごとに設定される開始時刻フィールドは、希望アクション希望実施内容をいつ実施するかというエポックタイムを指定する時刻情報を設定する。即時に実施することを指定する場合には、開始時刻を例えばall0に設定する。また、事前登録削除要求パケットのデータ領域内において希望アクションごとに設定される希望実施内容フィールドは、リソース閾値を超えるリソース不足が発生した際に、または、リソース閾値以下に低下してリソース不足から回復した際に、リソース管理サーバ3100側において、さらに、必要に応じて、アプリケーションX3103を駆動することにより、実施してもらいたい処理内容を設定する。リソース管理サーバ3100やアプリケーションX3103が指定された処理内容を実施する開始タイミングは、事前登録削除要求パケットの開始時刻フィールドによって指定されている。なお、希望実施内容フィールドに設定する希望アクション希望実施内容の情報量が、一定のデータサイズ例えば4バイトに収まらない場合には、希望実施内容フィールドを任意の長さに拡張することも可能である。なお、以下の説明においては、ヘッダ情報に含まれるタイプには、事前登録を要求するパケットである旨の表示が設定され、要求数には、前述のように、事前登録を要求する希望アクションの個数が設定されているものとする。リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101は、装置An30n0のリソース管理Agentリソース管理エージェント30n1から事前登録削除要求パケットを受け取ると、該事前登録削除要求パケットの送信元の装置An30n0が、管理対象のネットワーク装置であるか否かを判別するために、認証管理3102に対して認証要求を行うシーケンスS4002。かかる動作は、前述したように、装置An30n0がリソース管理に該当していない不正なネットワーク装置であった場合に、ネットワーク全体に悪影響を及ぼし兼ねないので、かかる事態の発生を未然に防止するためである。なお、認証管理3102に対する該認証要求には、認証の対象となるネットワーク装置を一意に特定することができる情報であって、かつ、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が確実に把握することができるネットワーク装置識別情報が付されている。例えば、事前登録削除要求パケットの送信元を示す装置An30n0のIPアドレスやMACアドレス等が付されている。認証要求を受け取った認証管理3102においては、該認証要求に付されているネットワーク装置識別情報例えばIPアドレスやMACアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置An30n0がリソース管理の対象装置であるか否かを判別することにより、装置An30n0の認証処理を行う。なお、認証管理3102における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。認証管理3102は、装置An30n0の認証処理を終了すると、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Managerリソース管理マネジャ3101に対して認証応答として返送するシーケンスS4003。リソース管理Managerリソース管理マネジャ3101は、認証管理3102から認証応答として装置An30n0の認証結果を受け取り、該認証結果がNGであった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取った事前登録削除要求パケットに含まれている全ての希望アクションの事前登録を拒否する。一方、該認証結果がOKであった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取った事前登録削除要求パケットに含まれている全ての希望アクションすなわち希望アクション1,...,希望アクションjを事前登録するとともに、それぞれの希望アクションごとに、それぞれの希望アクションを一意に特定するための本登録キーを発行する。さらに、リソース管理Managerリソース管理マネジャ3101は、認証結果がNGであった場合には、事前登録要求を受け付けられない旨を示すNG応答として、図8に示す事前登録応答パケットのヘッダ情報内の承認キーをall0に設定して、事前登録要求の送信元の装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して送信するシーケンスS4004。一方、認証結果がOKであった場合には、事前登録要求を受け付けた旨を示すOK応答として、事前登録削除要求パケットに含まれているそれぞれの希望アクションを一意に特定する本登録キーを付与した図8に示す事前登録応答パケットを作成するとともに、ヘッダ情報内の承認キーを、装置An30n0をリソース管理対象のネットワーク装置として承認したことを示すall0以外の有意な一意の値に設定して、装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して送信するシーケンスS4004。図8は、図3のリソース管理システムにおいてリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から事前登録削除要求元のネットワーク装置すなわち装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して送信される事前登録削除応答パケットのフォーマットの一例を示すテーブルである。ここで、図8に示す事前登録削除応答パケットも、事前登録削除要求パケットと同様、UDPUserDatagramprotocolパケット上のペイロードとして扱われ、事前登録削除要求パケットの送信元の装置An30n0のリソース管理Agentリソース管理エージェント30n1に送信することによって、事前登録削除要求パケットによって要求された希望アクション希望実施内容を事前登録したか否かを通知するために用いられる。具体的には、図8に示す事前登録削除応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域が要求受付数に関する情報を設定する領域に変更した以外は、事前登録削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、事前登録削除要求パケットに含まれていた仮登録番号ごとに、仮登録結果および希望するアクション処理内容を一意に特定する本登録キーを1組の希望アクション応答とし、受け取った事前登録削除要求パケットに応じて、希望アクション1応答,...,希望アクションj応答と複数組纏めて収容することができる。なお、ヘッダ情報に含まれるタイプには、事前登録削除の応答を返送するパケットである旨を示す表示が設定される。つまり、前述の表2に示すように、事前登録削除応答パケットのヘッダ情報内の要求受付数フィールドには、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取った事前登録削除要求パケットの希望実施内容フィールドにて指定されている希望アクション希望実施内容のうち、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において正当な処理要求であると認識して、事前登録された希望アクション希望実施内容の個数が設定される。また、事前登録削除応答パケットのデータ領域内において希望アクション応答ごとに設定される仮登録結果フィールドは、装置An30n0のリソース管理Agentリソース管理エージェント30n1からの各希望アクション希望実施内容ごとの事前登録結果事前登録されたか否かを示す情報を設定する。事前登録削除応答パケットのデータ領域内において希望アクション応答ごとに設定される本登録キーフィールドは、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において事前登録した希望アクション希望実施内容ごとに発行した本登録キーを設定する。事前登録削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、仮登録番号の各フィールドに関しては、図7に示した事前登録削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、事前登録要求元の装置An30n0がリソース管理対象のネットワーク装置として承認され、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において事前登録削除要求パケットに含まれている希望アクション希望実施内容の少なくとも1つ以上を事前登録した際に発行されたall0以外の有意な一意の値である承認キーが設定される。また、シーケンス番号フィールドには、イベントが発生する都度、図7に示した事前登録削除要求パケットの場合とは逆方向に、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から装置An30n0のリソース管理Agentリソース管理エージェント30n1へ送信したパケットの送信順を示す番号が設定される。図4のシーケンスチャートに戻って、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から事前登録削除応答パケットを受け取ると、該事前登録削除応答パケットのヘッダ情報に含まれている承認キーを参照して、all0以外の有意な一意の値が設定されているか否かを判別する。承認キーがall0であった場合には、当該装置An30n0が、リソース管理サーバ3100のリソース管理対象のネットワーク装置ではないと認定されて、事前登録が拒絶されたことを示している。一方、承認キーがall0以外の有意な一意の値であった場合には、先に送信した事前登録削除要求パケットに含まれている希望アクション希望実施内容の事前登録要求が受け付けられたものとして、事前登録削除応答パケットを正常に受け取ったことを示す応答ACKを、図9に示す事前登録削除応答ACKパケットとして、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信するシーケンスS4005。なお、装置An30n0のリソース管理Agentリソース管理エージェント30n1においては、以降、データ領域に仮登録番号ごとに対応付けて設定されている本登録キーを用いて、実施を希望する希望実施内容すなわち希望アクション処理内容を管理することになる。図9は、図3のリソース管理システムにおいて事前登録削除応答パケットを受け取ったネットワーク装置すなわち装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信される事前登録削除応答ACKパケットのフォーマットの一例を示すテーブルである。ここで、図9に示す事前登録削除応答ACKパケットも、事前登録削除要求パケットと同様、UDPUserDatagramprotocolパケット上のペイロードとして扱われ、事前登録削除応答パケットの送信元のリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に送信することによって、事前登録削除応答パケットを正常に受け取った旨を通知するために用いられる。具体的には、図9に示す事前登録削除応答ACKパケットは、ヘッダ情報のみからなり、ヘッダ情報にはバージョン、ヘッダ長、パケット長、タイプ、承認応答結果、シーケンス番号、承認キー、予約が含まれている。なお、ヘッダ情報に含まれるタイプには、事前登録削除応答パケットを正常に受け取った旨を示す応答ACKパケットである旨を示す表示が設定される。つまり、前述の表2に示すように、事前登録削除応答ACKパケットのヘッダ情報内の承認応答結果フィールドは、装置An30n0のリソース管理Agentリソース管理エージェント30n1においても、事前登録削除要求パケットの希望実施内容フィールドにて指定した希望アクション希望実施内容のうちリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において事前登録された希望アクション希望実施内容を正しく認識することができたか否かを示す情報を設定する。なお、複数存在している予約フィールドは、いずれも、現在使用されていないダミーの領域を示している。事前登録削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キーの各フィールドに関しては、図7に示した事前登録削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において事前登録削除要求パケットを受け付けて、事前登録削除要求パケットに含まれている希望アクション希望実施内容の少なくとも1つ以上を事前登録した際に発行されたall0以外の有意な一意の値である承認キーが設定される。以上の図4のシーケンスチャートに関する説明は、装置An30n0のリソース管理Agentリソース管理エージェント30n1からの事前登録削除要求パケットとして、リソース閾値を超えてリソース不足が発生したことを示すアラーム発生通知をリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信した際に実施してもらいたい希望アクション希望実施内容を事前登録することを要求している場合について説明したが、事前登録されている希望アクション希望実施内容を削除することを要求する場合についても、全く同様のシーケンスで実施される。ただし、装置An30n0のリソース管理Agentリソース管理エージェント30n1からの事前登録削除要求パケットとして、事前登録されている希望アクション希望実施内容の削除を要求する場合には、ヘッダ情報に含まれるタイプには、事前登録の削除を要求するパケットである旨の表示が設定され、要求数には、事前登録の削除を要求する希望アクションの個数が設定される。また、削除要求を行う場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1においても、各希望アクション各希望実施内容を一意に特定するための識別番号として、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が発行した本登録キーが既に用いられているので、事前登録の要求時においてデータ領域の希望実施内容ごとに設定されていた仮登録番号の代わりに、本登録キーが設定される。なお、図4に示すような事前登録削除処理においては、装置An30n0のリソース管理Agentリソース管理エージェント30n1から送信されてくる事前登録削除要求パケットを受け取ったとしても、アプリケーション実行の予約に関する情報は無効であり、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から、アプリケーションX3103に対してアプリケーション実行の予約等を事前に行うことはない。アプリケーションX3103の実行を予約する場合は、あくまでも、装置An30n0のリソース管理Agentリソース管理エージェント30n1において、使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいはリソース閾値以下に低下してリソース不足から回復したりして、アラーム発生通知をリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に送信してきた場合のみに限られる。次に、図3のリソース管理システムに示したリソース管理サーバ3100と管理対象のネットワーク装置である装置An30n0との間の通信シーケンスについて、装置An30n0において使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置An30n0からリソース管理サーバ3100に対して送信する際のシーケンスの一例を、図5を用いて説明する。図5は、図3のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置A13010ないし装置An30n0のうち、いずれかのネットワーク装置例えば第n番目の装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100に対してアラーム発生通知が送信されて、事前に設定登録されていた希望アクション希望実施内容を実施する際の処理シーケンスの一例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が、事前登録された希望アクション希望実施内容とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションX3103を駆動して、アラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2に対して、アラーム処理要求を送信することによって、装置An30n0のMIBManagementInformationBase情報を収集して輻輳状態を判別し、リソース状態の再配分を行う場合のシーケンス例について示している。以下においては、図5のシーケンスで示す一連の処理をアラーム処理1と称することにする。図5のシーケンスチャートにおいて、まず、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、使用しようとするネットワークのリソースがあらかじめ設定しているリソース閾値を超えたか、あるいは、該リソース閾値を超えた状態から該リソース閾値以下にまで低下してリソース不足から回復したりしたことを検知すると、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して、アラーム処理要求を行うためのアラーム発生通知として、図10に示すフォーマットからなるアラーム発生通知パケットを送信するシーケンスS5001。図10は、図3のリソース管理システムにおいてアラーム発生元のネットワーク装置すなわち装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信されるアラーム発生通知パケットのフォーマットの一例を示すテーブルである。ここで、図10に示すアラーム発生通知パケットも、事前登録削除要求パケットと同様、UDPUserDatagramprotocolパケット上のペイロードとして扱われ、アラーム発生元の装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に送信することによって、事前登録しておいた希望アクション希望実施内容のいずれかを実施することを要求するために用いられる。具体的には、図10に示すアラーム発生通知パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、閾値種別、予約からなるアラーム内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生を通知するパケットである旨を示す表示が設定され、アラーム内容の閾値種別には、リソース閾値を超えたかまたは該リソース閾値以下に低下してリソース不足から回復したかを示す情報が設定されている。つまり、前述の表2に示すように、アラーム発生通知パケットのヘッダ情報内のシーケンス番号フィールドは、装置An30n0のリソース管理Agentリソース管理エージェント30n1において、アラームが発生する都度、インクリメントされる番号であり、装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101へ送信したパケットの送信順を示している。該シーケンス番号は、装置An30n0に発生したアラームをリソース管理サーバ3100に通知した状況を管理するための識別番号として使用される。また、アラーム発生通知パケットのデータ領域にあるアラーム内容内の閾値種別フィールドは、前述したように、装置An30n0の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。アラーム発生通知パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図7に示した事前登録削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において既に発行されている承認キーが設定される。図5のシーケンスチャートに戻って、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101は、装置An30n0のリソース管理Agentリソース管理エージェント30n1からアラーム発生通知パケットを受け取ると、図4の事前登録削除処理の場合と同様、該アラーム発生通知パケットの送信元の装置An30n0が、管理対象のネットワーク装置であるか否かを判別するために、認証管理3102に対して認証要求を行うシーケンスS5002。認証要求を受け取った認証管理3102においては、図4の事前登録削除処理の場合と同様、該認証要求に付されているネットワーク装置識別情報例えばIPアドレスやMACアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置An30n0がリソース管理の対象装置であるか否かを判別することにより、装置An30n0の認証処理を行う。なお、認証管理3102における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。認証管理3102は、装置An30n0の認証処理を終了すると、図4の事前登録削除処理の場合と同様、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Managerリソース管理マネジャ3101に対して認証応答として返送するシーケンスS5003。リソース管理Managerリソース管理マネジャ3101は、認証管理3102からの認証応答として、装置An30n0の認証結果を受け取り、該認証結果がNGであった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。一方、該認証結果がOKであった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション希望実施内容を参照して、実施すべきアクション処理内容を決定する。決定されたアクション処理内容が、例えば、アプリケーションX3103を駆動して、輻輳状態を判別するためにアラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2にアラーム処理要求を送信することによって、装置An30n0のMIBManagementInformationBase情報を収集する処理を行う場合には、リソース管理Managerリソース管理マネジャ3101は、アプリケーションX3103を駆動して、アラーム処理要求として、決定したアクション処理内容にしたがった処理の実施を要求するシーケンスS5004。駆動されたアプリケーションX3103は、リソース管理Managerリソース管理マネジャ3101からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置An30n0にアラーム処理要求を送信することによって、装置An30n0のアプリケーションAn30n2のSNMPSimpleNetworkManagementProtocolMIBManagementInformationBase情報を収集する動作を起動する。この動作が起動されると、アプリケーションX3103は、事前登録された希望アクション希望実施内容の中から決定した希望アクション希望実施内容にしたがったアラーム処理要求として、例えば、アラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2に対して、SNMPMIB情報の収集を指示するアラーム処理要求を送信するシーケンスS5005。装置An30n0のアプリケーションAn30n2は、決定した事前登録の希望アクション希望実施内容にしたがったアラーム処理要求例えばSNMPMIB情報の収集を指示するアラーム処理要求をリソース管理サーバ3100のアプリケーションX3103から受け取ると、事前登録の希望アクション希望実施内容にしたがった処理例えばSNMPMIB情報の収集処理を実施して、事前登録の希望アクション希望実施内容の実施結果例えばSNMPMIB情報の収集結果を、リソース管理サーバ3100のアプリケーションX3103に対して返送するシーケンスS5006。リソース管理サーバ3100のアプリケーションX3103は、アラーム処理要求に応じて、装置An30n0のアプリケーションAn30n2から返送されてきた事前登録の希望アクション希望実施内容の実施結果例えばSNMPMIB情報の収集結果を受け取ると、受け取った実施結果例えばSNMPMIB情報の収集結果を保持するとともに、該SNMPMIB情報の収集結果に基づくリソースの再配分を行い、決定した事前登録の希望アクション希望実施内容の実施が成功したか否かを、当該アプリケーションX3103から、アラーム処理要求に対する応答として、アラーム処理要求元のリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して返送するシーケンスS5007。リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101は、アプリケーションX3103からアラーム処理要求に対する応答を受け取ると、該応答を実行結果として含む図11に示すフォーマットからなるアラーム発生応答パケットを作成して、アラーム発生通知パケットの送信元の装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して送信するシーケンスS5008。なお、アプリケーションX3103における何らかの処理が失敗した場合には、アプリケーションX3103は、アラーム処理要求元のリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して処理を失敗した旨を示す応答を返送する。かくのごとく、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が、アプリケーションX3103における処理が失敗した旨の応答を受け取った場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1に対するアラーム発生応答パケットの送信動作を抑止して、応答待ちタイムアウトによる装置An30n0のリソース管理Agentリソース管理エージェント30n1からのアラーム発生通知パケットの再送信を促すようにしても良い。図11は、図3のリソース管理システムにおいてリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からアラーム発生通知パケットの送信元のネットワーク装置すなわち装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して送信されるアラーム発生応答パケットのフォーマットの一例を示すテーブルである。ここで、図11に示すアラーム発生応答パケットも、事前登録削除要求パケットと同様、UDPUserDatagramprotocolパケット上のペイロードとして扱われ、アラーム発生通知パケットの送信元の装置An30n0のリソース管理Agentリソース管理エージェント30n1に送信することによって、アラーム発生通知パケットによって要求された希望アクション希望実施内容の実施に成功したか否かを通知するために用いられる。具体的には、図11に示すアラーム発生応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、実行結果、閾値種別、強制削除フラグからなるアラーム応答内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生通知に対する応答を返送するパケットである旨を示す表示が設定される。つまり、前述の表2に示すように、アラーム発生応答パケットのヘッダ情報内のシーケンス番号フィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において、イベントが発生する都度、図10に示したアラーム発生通知パケットの場合と同様、インクリメントされる番号であり、図10に示したアラーム発生通知パケットの場合とは逆方向に、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101から装置An30n0のリソース管理Agentリソース管理エージェント30n1へ送信したパケットの送信順を示している。また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図10に示したアラーム発生通知パケットにより送信されてきた閾値種別がそのまま設定され、装置An30n0の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドには、アラーム発生通知パケットにより要求された希望アクション希望実施内容の処理例えばSNMPMIB情報の収集処理が成功し、リソースの再配分に成功したか否かを示す実行結果が設定され、本実施例においては、アプリケーションX3103により駆動された装置An30n0のアプリケーションAn30n2の実施が成功したか否かを示す情報が設定される。なお、該実行結果として、アプリケーションX3103により駆動された装置An30n0のアプリケーションAn30n2の実施結果を示す処理詳細例えばSNMPMIB情報の収集結果やリソース再配分処理結果を含むようにしても良い。また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の強制削除フラグフィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が、ネットワーク全体の各ネットワーク装置からの希望アクション希望実施内容やリソース状態を保持しているプロファイル3104に設定されているデータの参照結果として、アプリケーションX3103に対するアラーム処理要求は不適当であると判定して、アプリケーションX3103に対して希望アクション希望実施内容の実施を要求するアラーム処理要求を行わなかった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1に対して事前登録されている当該希望アクション希望実施内容の強制的な削除を指示するための強制削除フラグが設定される。該強制削除フラグが設定されているアラーム発生応答パケットを受け取った装置An30n0のリソース管理Agentリソース管理エージェント30n1は、必ず、当該希望アクション希望実施内容の削除を実施しなければならない。なお、プロファイル3104に設定されているデータの詳細については後述する。アラーム発生応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図7に示した事前登録削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において既に発行されている承認キーが設定される。図5のシーケンスチャートに戻って、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からアラーム発生応答パケットを受け取ると、該アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドを確認し、実施要求していた希望アクション希望実施内容の実施が成功したか否かを確認する。希望アクション希望実施内容の実施が成功していた場合には、使用するリソースの割当状況に変化が生じているものと看做すことができるが、実施が失敗していた場合には、さらに、データ領域にあるアラーム応答内容内の強制削除フラグフィールドを参照して強制削除フラグが設定されているか否かを確認する。強制削除フラグが設定されていた場合には、前述したように、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して、事前登録削除要求パケットを送信して、事前登録していた希望アクション希望実施内容を削除しなければならない。かくのごとき事前登録の希望アクション希望実施内容の強制的な削除処理を実行する目的は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101側において、実施が失敗になってしまうようなアラーム処理要求をアプリケーションX3103に対していつまでも送信し続けることがないように、該希望アクション希望実施内容の実施を要求するアラーム発生通知パケットを、装置An30n0のリソース管理Agentリソース管理エージェント30n1から送信する動作を抑止するためである。つまり、装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して、何回も繰り返して、実施することが出来ない希望アクション希望実施内容の実施を要求するアラーム発生通知パケットが送信されることによる輻輳を防止するためである。受け取ったアラーム発生応答パケットの処理を終了すると、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からのアラーム発生応答パケットを正常に受け取ったことを示すアラーム発生応答ACKを、図12に示すアラーム発生応答ACKパケットとして、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信するシーケンスS5009。図12は、図3のリソース管理システムにおいてアラーム発生応答パケットを受け取ったネットワーク装置すなわち装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対して送信されるアラーム発生応答ACKパケットのフォーマットの一例を示すテーブルである。ここで、図12に示すアラーム発生応答ACKパケットも、事前登録削除要求パケットと同様、UDPUserDatagramprotocolパケット上のペイロードとして扱われ、アラーム発生応答パケットの送信元のリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に送信することによって、アラーム発生応答パケットを正常に受け取った旨を通知するために用いられる。具体的には、図12に示すアラーム発生応答ACKパケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、応答結果、閾値種別、強制削除結果、予約からなるアラームACKが設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生応答パケットを正常に受け取った旨を示すアラーム発生応答ACKパケットである旨を示す表示が設定される。つまり、前述の表2に示すように、アラーム発生応答ACKパケットのヘッダ情報内のシーケンス番号フィールドは、図10に示したアラーム発生通知パケットの場合と同様、装置An30n0のリソース管理Agentリソース管理エージェント30n1において、イベントが発生する都度、インクリメントされる番号であり、装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101へ送信したパケットの送信順を示している。また、アラーム発生応答ACKパケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図10に示したアラーム発生通知パケットにより送信した閾値種別がそのまま設定され、装置An30n0の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。また、アラーム発生応答ACKパケットのデータ領域にあるアラームACK内の応答結果フィールドには、装置An30n0のリソース管理Agentリソース管理エージェント30n1においても、アラーム発生応答パケットのアラーム応答内容、すなわち、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において実施された処理内容を正しく認識することができたか否かを示す情報が設定される。また、アラーム発生応答ACKパケットのデータ領域にあるアラームACK内の強制削除結果フィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からの指示通りに、事前登録した希望アクション希望実施内容を強制削除することができたか否かを示す情報が設定される。なお、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からのアラーム発生応答パケットに強制削除フラグが設定されていなかった場合には、アラームACK内の強制削除結果フィールドには無効なデータが設定された状態になっている。アラーム発生応答ACKパケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キーの各フィールドに関しては、図7に示した事前登録削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において既に発行されている承認キーが設定される。なお、図5のシーケンスS5008において、装置An30n0のリソース管理Agentリソース管理エージェント30n1から、アラーム発生通知パケットを送信した後、あらかじめ定めた時間閾値を経過しても、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101からアラーム発生応答パケットを受信することができなかった場合には、応答待ちタイムアウトが発生したものとして、装置An30n0のリソース管理Agentリソース管理エージェント30n1は、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101に対してアラーム発生通知パケットを再度送信する動作を行うようにしても良い。次に、図3のリソース管理システムに示したリソース管理サーバ3100と管理対象のネットワーク装置である装置An30n0との間の通信シーケンスについて、装置An30n0において使用するリソースがリソース閾値を超えたりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置An30n0からリソース管理サーバ3100に対して送信する際のシーケンスについて、図5とは異なる例を、図6を用いて説明する。図6は、図3のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの図5とは異なる例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置A13010ないし装置An30n0のうち、いずれかのネットワーク装置例えば第n番目の装置An30n0のリソース管理Agentリソース管理エージェント30n1からリソース管理サーバ3100に対してアラーム処理要求が送信されて、事前に設定登録されていた希望アクション希望実施内容を実施する際の処理シーケンスの他の例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が、事前登録された希望アクション希望実施内容とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションX3103を駆動して、アラーム発生通知の送信元の装置An30n0とは異なる他のネットワーク装置例えば装置Am30m0のアプリケーションAm30m2に対してアラーム処理要求を送信することによって、アプリケーションAm30m2を駆動して、装置Am30m0の閉塞状態を解除させる装置Am30m0側のコマンドを実施する場合のシーケンス例について示している。以下においては、図6のシーケンスで示す一連の処理をアラーム処理2と称することにする。図6のシーケンスチャートにおいて、シーケンスS6001~S6003までのシーケンスおよびシーケンスS6007~S6009までのシーケンスは、それぞれ、図5のシーケンスチャートS5001~S5003までのシーケンスおよびシーケンスS5007~S5009までのシーケンスと全く同様であるので、ここでの重複する説明は省略する。図6のシーケンスS6004において、リソース管理Managerリソース管理マネジャ3101は、シーケンスS6003において認証管理3102から認証応答として返送されてきた装置An30n0の認証結果を受け取ると、該認証結果がNGであった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。一方、該認証結果がOKであった場合には、装置An30n0のリソース管理Agentリソース管理エージェント30n1から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション希望実施内容を参照して、実施すべきアクション処理内容を決定する。決定されたアクション処理内容が、例えば、アプリケーションX3103を駆動して、図5のシーケンスS5004の場合とは異なり、アラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2の輻輳状態を解決するために、アラーム発生通知の送信元の装置An30n0のアプリケーションAn30n2とは異なる他のネットワーク装置例えば装置Am30m0のアプリケーションAm30m2のTelnetサーバに対してリソース管理サーバ3100のTelnetクライアントが接続を要求して、CLICommandLineInterfaceを用いて装置Am30m0側のコマンドを実施するアラーム処理要求であった場合には、リソース管理Managerリソース管理マネジャ3101は、アプリケーションX3103を駆動して、アラーム処理要求として、決定したアクション処理内容にしたがった処理の実施を要求するシーケンスS6004。駆動されたアプリケーションX3103は、リソース管理Managerリソース管理マネジャ3101からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置An30n0とは異なる他のネットワーク装置例えば装置Am30m0のアプリケーションAm30m2のTelnetサーバに対してリソース管理サーバ3100のアプリケーションX3103のTelnetクライアントが接続を要求して、CLICommandLineInterfaceのコマンドラインインタフェースを用いて、装置Am30m0側のコマンドを実施する動作、を起動する。この動作が起動されると、アプリケーションX3103は、事前登録された希望アクション希望実施内容の中から決定した希望アクション希望実施内容にしたがった実施処理結果として、例えば、装置Am30m0のアプリケーションAm30m2のTelnetサーバに対してリソース管理サーバ3100のTelnetクライアントが接続を要求して、CLICommandLineInterfaceのコマンドラインインタフェースを用いて、装置Am30m0側のコマンドを実施するというアラーム処理要求を送信するシーケンスS6005。装置Am30m0のアプリケーションAm30m2は、決定した事前登録の希望アクション希望実施内容にしたがったアラーム処理要求例えばCLICommandLineInterfaceを用いて装置Am30m0側のコマンドを実施するというアラーム処理要求をリソース管理サーバ3100のアプリケーションX3103から受け取ると、事前登録の希望アクション希望実施内容にしたがった処理例えばリソース管理サーバ3100のTelnetクライアントからのCLICommandLineInterfaceを用いた要求に該当する装置Am30m0側のコマンドをTelnetサーバとして実施して例えば、装置Am30m0の閉塞状態を解除して、事前登録の希望アクション希望実施内容の実施結果例えばコマンドの実行結果を、リソース管理サーバ3100のアプリケーションX3103に対して返送するシーケンスS6006。かくのごとく、輻輳状態に陥ってアラーム発生通知の送信元となっていた装置An30n0とは異なる他のネットワーク装置例えば装置Am30m0のアプリケーションAm30m2においてコマンドを実行することによって、例えば、装置Am30m0の閉塞状態を解除して、アラーム処理要求元の装置An30n0側の負荷の一部を分担することが可能になる。次に、図5のシーケンスS5005において、アラーム発生応答パケットの強制削除フラグを設定するか否かを判別するために、つまり、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101がアプリケーションX3103への実施要求が適当か否かを判定して、該判定結果に基づいてアプリケーションX3103に対して希望アクション希望実施内容の実施を要求するか否かを判別するために、参照されるプロファイル3104のデータについて、次の表3を用いて詳細に説明する。表3に示すプロファイル3104は、前述のように、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101内に保持されているネットワーク全体のリソース管理に関するデータベースであり、ネットワークを構成する各ネットワーク装置から事前登録されている希望アクション希望実施内容を実施履歴や各ネットワーク装置のリソース状態とともに保持している。つまり、プロファイル3104は、表3に示すように、承認キー301、承認先IPアドレス/プレフィックス302、本登録キー303、希望優先度304、指示対象名305、実施回数306、開始時刻307、希望実施内容308、登録完了時刻309、現在の状態310を少なくとも有して構成されている。さらに、本登録キーごとにそれぞれのアクション処理内容の実施履歴として、項番311、実施結果312、開始時刻313、完了時刻314を有して構成されている。表3に示すプロファイル3104の設定例においては、承認キー301、承認先IPアドレス/プレフィックス302および希望実施内容308に示すように、承認先IPアドレス/プレフィックス302がA,B,C,D/Pのネットワーク装置の装置An30n0からの事前登録処理により、承認キー301が3fe9105aとして登録された2つの希望実施内容本登録キー303が00000001および00000002の2つが設定され、承認先IPアドレス/プレフィックス302がW,X,Y,Z/Pのネットワーク装置の装置Am30m0からの事前登録処理により、承認キー301が3fe9105bとして登録された2つの希望実施内容本登録キー303が00000003および00000004の2つが設定されている例が示されている。ここで、表3に示すプロファイル3104の承認キー301、本登録キー303、希望優先度304、指示対象名305、実施回数306、開始時刻307、希望実施内容308、実施結果312のそれぞれのデータについては、図7の事前登録削除要求パケット、図8の事前登録削除応答パケット、図9の事前登録削除応答ACKパケット、図10のアラーム発生通知パケット、図11のアラーム発生応答パケット、および、図12のアラーム発生応答ACKパケットの内容が反映される。また、表3に示すプロファイル3104の承認先IPアドレス/プレフィックス302、および、登録完了時刻309については、図4の事前登録削除処理のシーケンス処理中において、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が認識することにより設定することができる。また、表3に示すプロファイル3104の現在の状態310、および、実施履歴の項番311については、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101による監視結果として決定して設定することができる。また、表3に示すプロファイル3104の実施履歴の開始時刻313、および、完了時刻314については、図5のアラーム処理1のシーケンスにおけるシーケンスS5004アプリケーションX3103へのアラーム処理要求を行うシーケンス、および、シーケンスS5007アプリケーションX3103から実施結果を受け取るシーケンスや、あるいは、図6のアラーム処理2のシーケンスにおけるシーケンスS6004アプリケーションX3103へのアラーム処理要求を行うシーケンス、および、シーケンスS6007アプリケーションX3103から実施結果を受け取るシーケンスによって、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101が認識して設定することができる。ここで、現在の状態310は、本登録キーごとに待ち、実行中、完了、失敗の4つの状態が存在する。完了の後は、待ちの状態に遷移する。待ちの後は、実行中の状態に遷移する。失敗の後は、待ちの状態に遷移するか、あるいは、強制削除によって、当該本登録キー自体が削除される。表3に示す例においては、本登録キー00000004の場合が、現在の状態310に示すように、失敗の状態になっている。かくのごとく、現在の状態310が失敗の状態にある場合に、次の状態として待ちの状態に遷移するか、あるいは、強制削除するかは、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101において適宜判別される。例えば、当該本登録キーで特定される希望アクション希望実施内容の実施回数があらかじめ定めた回数閾値に達するまでは、待ちの状態に移行し、実施回数が該回数閾値以上に及んで何回も失敗を繰り返している場合には、当該本登録キーで特定される希望アクション希望実施内容は、強制的に削除することにしても良い。なお、プロファイル3104から希望アクション希望実施内容のデータの削除を行う場合には、図4の事前登録削除処理のシーケンスにしたがって、当該本登録キーの希望アクション希望実施内容を事前登録したネットワーク装置例えば装置An30n0のリソース管理Agentリソース管理エージェント30n1との間で、希望アクション希望実施内容の削除処理を実施することになるが、当該本登録キーを主キーとしてプロファイル3104のデータを参照して削除することが可能である。また、表3に示すプロファイル3104の実施結果312には、成功、失敗、および、実行中の3つの結果が存在する。実施結果312が実行中の場合には、現在の状態310も実行中の状態にあり、実施結果312が失敗の場合には、現在の状態310も失敗かまたは待ちの状態になり、実施結果312が成功の場合には、現在の状態310は完了かまたは待ちの状態になる。以上のように、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101は、プロファイル3104としてネットワークを構成する各ネットワーク装置に関する各種のデータを保持しているので、送信先IPアドレスの払い出しや希望アクション希望実施内容の実行優先度付けを適宜行うことが可能である。このようにして、本実施形態においては、各ネットワーク装置例えば例えば装置An30n0から、リソース不足時に実施してもらいたい希望アクション希望実施内容をリソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101側に事前登録し、かつ、実際にリソース不足が発生した際に、事前登録した希望アクション希望実施内容の実施を要求するアラーム発生通知をネットワーク装置側からリソース管理サーバ3100に対して送信し、リソース管理サーバ3100のリソース管理Managerリソース管理マネジャ3101側において、事前登録された希望アクション希望実施内容の実施の可否判断をプロファイル3104に基づいて行っている。したがって、従来技術におけるSNMPTrapメッセージトラップメッセージなどとは異なり、アラームの発生をリソース管理サーバ3100に対して通報するだけではなく、アラーム発生通知に基づいて、事前登録の希望アクション希望実施内用としてあらかじめ登録された処理を実施させることができ、多数のネットワーク装置のリソース管理とアクション処理の管理とを一元化することができる。実施形態の具体的構成例以上に説明した本発明に係るリソース管理システムのシステム構成について、例えば、ネットワーク装置として呼処理装置を対象とした場合の構成例を、図13に示す。図13は、本発明に係るリソース管理システムの具体的なシステム構成の一例を示すシステム構成図であり、呼処理ネットワークにおけるシステム構成例を示しており、図1の場合とは異なり、ネットワーク装置として呼処理装置を対象とし、該呼処理装置が呼処理の制御対象とするユーザ端末装置とネットワークを介して接続されている様子を示している。図3のシステム構成において、呼処理装置A113010,呼処理装置A213020,呼処理装置A313030は、図3におけるネットワーク装置例えば装置An30n0と同様、それぞれ、リソース管理Agentリソース管理エージェントを備えており、管理ネットワーク13200を介して、リソース管理Managerリソース管理マネジャを備えているリソース管理サーバ13100と通信を行うことによって、リソースの管理を行っている。また、呼処理装置A113010,呼処理装置A213020は、それぞれ、呼処理の制御対象となるユーザ端末群13001,ユーザ端末群13002とネットワーク13300を介して接続されている。ここで、現時点においては、ユーザ端末群13001,ユーザ端末群13002の端末数が、それぞれ、既に、呼処理装置A113010,呼処理装置A213020それぞれに収容可能な端末数の最大限界値近くの端末数に達しているものと仮定する。一方、呼処理装置A313030は、管理ネットワーク13200およびネットワーク13300に接続されてオンライン状態になっているものの、呼処理の制御対象となるユーザ端末が存在していなく、VLANVirtualLocalAreaNetwork機能を閉塞している状態になっているものと仮定する。また、呼処理装置A113010,呼処理装置A213020は、それぞれ、図4の事前登録削除要求処理のシーケンスにしたがって、リソース管理サーバ13100のリソース管理Managerリソース管理マネジャに対して、収容端末数が収容可能端末数を超える場合には、収容端末数が少ない呼処理装置に呼処理を実施してもらいたいという希望アクション希望実施内容を事前登録しているものと仮定する。具体的には、収容端末数が収容可能端末数を超える場合には、図6に示したアラーム処理2のシーケンスにおいて説明したように、リソース管理サーバ13100側のTelnetクライアントから収容端末数が少ない呼処理装置側のTelnetサーバへTelnet接続して、CLICommandLineInterfaceによるコマンドを実行させることによって、CLI上から割り出した呼処理装置のVLAN機能の閉塞状態を解除させて、呼処理を実行できるようにしたり、あるいは、リソース確保のために必要とする装置設定を行うようなコマンドを投入したりすることを要求する希望アクション希望実施内容が事前登録されている。また、リソース管理サーバ13100のリソース管理Managerリソース管理マネジャは、呼処理装置A113010,呼処理装置A213020,呼処理装置A313030の希望アクション希望実施内容を、図7に示した事前登録削除要求パケットによって受け取って、表3に示したようなプロファイルとして保持して管理している。実施形態の具体的構成例の動作の説明次に、図13に示した具体的なシステム構成例における動作の一例を、図13を用いてさらに説明する。図13のシステム構成例において、前述したように、ユーザ端末群13001,ユーザ端末群13002の端末数が、それぞれ、呼処理装置A113010,呼処理装置A213020それぞれの収容可能端末数の最大限界値近くの端末数に既に達している状態にある。かかる状態において、さらに、新しいユーザ端末群13003に対して呼処理サービスを提供し始めた場合、例えば、呼処理装置A113010によって新しいユーザ端末群13003に対する呼処理を実施しようとした場合には、呼処理装置A113010のリソースがあらかじめ定めたリソース閾値を超えてしまうため、呼処理装置A113010のリソース管理Agentリソース管理エージェントは、図10に示したようなアラーム発生通知パケットをリソース管理サーバ13100のリソース管理Managerリソース管理マネジャに対して送信して、事前登録されている希望アクション希望処理要求の実施を要求する。すなわち、収容可能端末数を超えるユーザ端末の呼処理を収容端末数が少ない呼処理装置によって実行することを要求する。リソース管理サーバ13100のリソース管理Managerリソース管理マネジャ側においては、呼処理装置A113010のリソース管理Agentリソース管理エージェントからのアラーム発生通知パケットを受け取ると、呼処理装置A113010,呼処理装置A213020,呼処理装置A313030に関するプロファイルのデータを参照して、収容端末数が最も少ない呼処理装置が、呼処理装置A313030であることを判別する。その結果、リソース管理サーバ13100のリソース管理Managerリソース管理マネジャは、図6に示したアラーム処理2のシーケンスにしたがって、シーケンスS6004において、例えば、アプリケーションXのTelnetクライアントからのTelnet通信によって、収容端末数が最も少ない呼処理装置A313030のVLAN機能の閉塞状態を解除させて、呼処理を実施できるようにし、新しいユーザ端末群13003に対して呼処理サービスを提供することができる状態に設定する。以上のように、各呼処理装置からの事前登録要求に基づいてそれぞれの希望アクション希望実施内容をプロファイルとして事前登録することによって、該プロファイルに基づいてリソース管理を行うことを可能にし、適切な収容端末数の割当を自動的に行うことが可能になる。本実施形態の効果の説明以上に詳細に説明したように、本実施形態においては、以下に記載するような効果を奏することができる。第1の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション処理実施内容をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。第2の効果は、リソース管理サーバのリソース管理Managerリソース管理マネジャは、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション処理実施内容を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション希望処理実施内容を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。第3の効果は、ネットワークのリソースを管理するリソース管理サーバは、管理対象のネットワーク装置であるか否かを認証する仕組みを採用しているので、不正なネットワーク装置からのアクセスを確実に抑止して、不正なネットワーク装置によるリソース管理への悪影響を確実に防止することができることである。本発明の他の実施形態次に、本発明の他の実施形態として、リソース管理システムの基本的構成は、前述した実施形態の場合と同様であるが、多階層のリソース管理を実現する場合の構成例について図14を用いて説明する。図14は、本発明によるリソース管理システムのシステム構成の図1とは異なる例を示すシステム構成図であり、ネットワーク全体のリソースを管理するリソース管理サーバが、多階層化図14の例においては2階層化されて構成されている例を示している。つまり、本実施形態においては、多階層のリソース管理を実現するために、図14に示すように、リソース管理Agentリソース管理エージェントとリソース管理Managerリソース管理マネジャとを併せ持つリソース管理サーバを設置している。図14のシステム構成に示すように、最上位のリソース管理サーバC14100の配下に、下位層のリソース管理サーバA14210とリソース管理サーバB14310とが分散配置されており、最上位のリソース管理サーバC14100は、下位層のリソース管理サーバA14210とリソース管理サーバB14310とのリソースを管理する。また、リソース管理サーバC14100とリソース管理サーバA14210およびリソース管理サーバB14310との間は、管理ネットワークC14410を介して接続される。最上位のリソース管理サーバC14100は、下位層のリソース管理サーバA14210とリソース管理サーバB14310とのリソースを管理するために、前述の図3に示したリソース管理サーバ3100の場合と同様、リソース管理Managerリソース管理マネジャ14101を備えている。一方、下位層のリソース管理サーバA14210は、リソース管理Agentリソース管理エージェント14211とリソース管理Managerリソース管理マネジャ14201との双方を備え、同様に、リソース管理サーバB14310も、リソース管理Agentリソース管理エージェント14311とリソース管理Managerリソース管理マネジャ14301との双方を備えている。下位層のリソース管理サーバA14210のリソース管理Managerリソース管理マネジャ14201は、管理ネットワークA14420を介して、管理対象のネットワーク装置として、装置A114500と装置A214600とを対象にしてリソース管理を実施する。このため、装置A114500と装置A214600とには、前述の図3に示した装置An30n0の場合と同様、それぞれ、リソース管理Agentリソース管理エージェント14510とリソース管理Agentリソース管理エージェント14610とを備えている。同様に、下位層のリソース管理サーバB14700のリソース管理Managerリソース管理マネジャ14301は、管理ネットワークB14430を介して、装置B114700と装置B214800を対象にしてリソース管理を実施する。このため、装置B114700と装置B214800とには、前述の図3に示した装置An30n0の場合と同様、それぞれ、リソース管理Agentリソース管理エージェント14710とリソース管理Agentリソース管理エージェント14810とを備えている。つまり、最上位のリソース管理サーバC14100の管理ドメインは、リソース管理サーバA14210のリソース管理Agentリソース管理エージェント14211とリソース管理サーバB14310のリソース管理Agentリソース管理エージェント14311となる。下位層のリソース管理サーバA14210の管理ドメインは、装置A114500のリソース管理Agentリソース管理エージェント14510と装置A214600のリソース管理Agentリソース管理エージェント14610となり、下位層のリソース管理サーバB14310の管理ドメインは、装置B114700のリソース管理Agentリソース管理エージェント14710と装置B214800のリソース管理Agentリソース管理エージェント14810となる。かくのごとく、多階層のネットワークトポロジーにおけるリソース管理を行う場合、ネットワーク全体のリソースを管理するリソース管理サーバを多階層図14に示す例では2階層に分散配置した構成とし、最上位のリソース管理サーバ以外の各階層のリソース管理サーバについては、リソース管理Agentリソース管理エージェントとリソース管理Managerリソース管理マネジャとの双方を具備することにより、多階層のネットワークトポロジーにおいても、それぞれの階層ごとのリソース管理を迅速かつ確実に実施することが可能になる。以上、本発明の好適な実施形態の構成を説明した。しかし、かかる実施形態は、本発明の単なる例示に過ぎず、何ら本発明を限定するものではないことに留意されたい。本発明の要旨を逸脱することなく、特定用途に応じて種々の変形変更が可能であることが、当業者には容易に理解できよう。"