JP2006244015A - 共有リソース管理プログラム、方法、装置、アプリケーションサービスシステム - Google Patents

Abstract

【課題】アプリケーションを利用するユーザの共有リソース使用量を簡易に制御する。
【解決手段】データセンタ２０には、アプリケーションを提供するＡＰ１提供装置２４とＡＰ２提供装置２６、及び、リソースの利用状況について集計するリソース集計装置３２が設けられている。リソース集計装置は、ＡＰ１提供装置からユーザのサービス要求があった旨を入力すると、過去の利用量及び基本割り当て量とに基づいて、そのユーザが現在利用できるリソース利用可能量を算出する。ＡＰ１提供装置では、算出されたリソース利用可能量をサービス提供に必要なリソース使用量と比較して、ユーザ要求を受け付けるか否か決定する。
【選択図】図１

Description

本発明は、共有リソースを利用してアプリケーションを提供するための技術、特に、各ユーザが使用する共有リソースの使用量を管理する技術に関する。

複数のユーザを対象とするアプリケーションサービスにおいては、特定のユーザによる共有リソースの占有を回避し、他のユーザに対するサービス品質を維持する必要がある。例えば、アプリケーションサービスプロバイダ（ASP：Application Service Provider）のように同一のデータセンタで複数のアプリケーションを設置しサービスを提供する場合には、複数のアプリケーションによって使用される共有リソースが占有されることのないように管理することが求められている。中でも、ネットワーク帯域のようにリソース容量の絶対値に制約がある共有リソースについては、このような占有の回避に対する要求が高い。

ネットワーク帯域利用状況を監視し制限する技術としては、パケットシェイピングなどと呼ばれる市販の商用装置がある。この技術においては、ポート番号、ＩＰアドレス、ネットワークドメイン、ＵＲＬなどによりネットワークトラフィックをカテゴライズし、カテゴリごとに利用可能なネットワーク帯域の下限と上限を設定することができる。

また、下記特許文献１には、トークンを利用してリソースの利用量の制御を行う技術が開示されている。この技術では、各ユーザには、最低限利用可能なリソース量に対応したバンクが割り当てられ、ここに一定レートで生成されるトークンが蓄積される。そして、バンクが満杯になった場合には容量に余裕のある別のユーザのバンクにトークンが蓄積される。各ユーザはトークンが蓄積できる間はリソースへのアクセスができるため、最低限のサービス品質の維持とリソースの有効利用が図られる。

特開平１０−４９３９０号公報

上述のパケットシェイピングの手法では、一般にアプリケーションが利用するネットワーク帯域を制限することはできるが、各ユーザが利用するネットワーク帯域を制限することには適さない。すなわち、ユーザが同一のパソコン等からアクセスする場合には、この機器のＩＰアドレスを指定して制御することでこのユーザのネットワーク帯域を制限できるが、ユーザが複数の機器を利用する場合には問題が生じる。また、複数のユーザが同一のＰｒｏｘｙサーバ経由でアクセスする場合にも、ユーザ単位の制御ができない。さらに、仮にこうした問題が回避されたとしても、ユーザがサービス利用者として追加されるたびに制御機器にＩＰアドレスを登録する必要があり、運用上の困難を伴う。

他方、上記特許文献１の技術では、複数アプリケーションの間でユーザのアクセスを制御することは可能となる。しかし、定期的に生成するトークンで制御するという仕組み上、ネットワーク帯域の使用量のようなリソース使用量に応じた制御には適用できないという問題がある。

本発明の目的は、アプリケーションを利用するユーザの共有リソース使用量を簡易に制御することにある。

本発明の別の目的は、同一システム内に設置された複数のアプリケーションサービスをユーザが利用する場合に、このユーザによる共有リソースの独占を簡易に回避することにある。

本発明の共有リソース管理プログラムは、共有リソースを利用してアプリケーションサービスを提供するシステムに対し、ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手順と、そのユーザに対する共有リソースの使用許可量を取得する許可量取得手順と、使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手順と、を実行させる。

共有リソースとは、システムを構成する要素のうち複数のユーザ向け処理において使われうる要素のことであり、ＣＰＵ等の演算資源、メモリなどの記憶資源、ネットワークなどの通信資源、ライブラリやデータベースなどのソフトウエア資源などを例示することができる。また、アプリケーションサービスとは、ユーザの要求に応じて実行する情報処理サービスであり、例えば、ユーザの共用のファイル置き場を提供するファイル共有（あるいは交換）サービス、印刷処理を行うプリントサービス、データベースに基づき情報の検索や提示などを行う情報検索サービスなどを挙げることができる。

この共有リソース管理プログラムは、共有リソースを利用してユーザにアプリケーションサービスを提供するシステムにおいて共有リソースに基づく処理制御（の少なくとも一部）を担うプログラムである。予定量取得手順は、ユーザ要求されたアプリケーションサービスの処理に必要となる共有リソースの使用予定量を、ユーザ要求を直接解析して、あるいは、対応するアプリケーションサービスに問い合わせるなどして取得する手順である。また、許可量取得手順は、そのユーザに認められた共有リソースの使用可能量である使用許可量を取得する手順であり、例えば、予め設定されたデータや、あるいはその都度（例えば現在の稼働状況に応じて動的に）算出されたデータを取得することで実施される。予定量取得手順と許可量取得手順とはどちらが先に実行されてもよい。

判定手順は、共有リソースを利用可能かという観点からアプリケーションサービスの処理可能性を判定する手順であり、取得した使用許可量及び使用予定量の対比などを行う所定の条件式に代入したり、あるいは、さらに他の諸量を加味したりして判定が行われる。なお、判定に基づいてさらに手順を実施するように構成することも可能であり、例えば、アプリケーションプログラムの実行の中止（拒否）や実行開始の先延ばしなどを行ってもよいし、また、こうした処理についての情報をユーザに通知する処理を行うこともできる。

この構成によれば、ユーザ毎の共有リソースの使用に基づいて、アプリケーションを実施できるか否かが判定されるため、特定のユーザが共有リソースを独占するといった好ましくない状況が防止され、適正な共有リソース使用量に保つ制御が容易に行われることとなる。この共有リソース使用量の制御は、異なるアプリケーションであってもユーザが同一であることを判断基準として実施できるため、複数のアプリケーションを提供するシステムを管理する上でも有用なものとなる。なお、当該共有リソース管理プログラムは、その機能を実現する単独のプログラムであってもよいし、アプリケーションサービスに係るプログラムの一部を構成する（モジュール）ものであってもよい。あるいは、このプログラムを構成する複数のモジュールが別々の演算装置に組み込まれ、連携してこれらの機能を実現するように構成することも可能である。

本発明の共有リソース管理プログラムの一態様においては、共有リソースは、ネットワークについてのリソースである。すなわち、システムが管理するネットワークをどれだけ利用できるかというネットワーク帯域についての管理を行う。この管理は、例えば、大量のデータ転送を伴うアプリケーションサービスを実施する上で有用である。

本発明の共有リソース管理プログラムの一態様においては、許可量取得手順において取得する使用許可量は、そのユーザに対する基本割当量と、そのユーザの過去のリソース使用量に基づいて決定される。基本割当量とは、ユーザの過去のリソース使用量とは無関係に決定される割当量を指し、固定値であっても全体の空きリソース量などに基づく変動値であってもよい。また、過去のリソース使用量とは、例えば、過去１時間や過去２４時間など一つまたは複数の期間における平均使用量や最大使用量などを指す。この過去のリソース使用量は、例えば、各アプリケーションサービスからユーザ別のリソース使用量の記録を取得することで算出することができる。そして、使用許可量は、基本割当量と過去のリソース使用量との対比などを行う所定の条件式に代入したり、さらに他の諸量を加味したりして決定される。

本発明の共有リソース管理プログラムの一態様においては、当該システムに対し、全共有リソースの未使用量を取得する未使用量取得手順を実行させ、判定手順においては、全共有リソースの未使用量にも基づいて判定を行う。すなわち、現時点での全共有リソースの未使用量に応じて、アプリケーションが実行可能であるかの判定基準を動的に変化させる。これにより、リソース未使用量が十分にある場合に使用制限を緩めたり、制限を解除したりすることが可能であり、リソースを十分に活用したり、ユーザ要求をなるべく受け付けたりすることが可能となる。

本発明の共有リソース管理プログラムの一態様においては、判定手順においては、その時点での処理が不可能であると判定される場合に、処理が可能となる予定時刻が算出される。典型的には、算出された予定時刻はユーザに通知される。

本発明のアプリケーションサービスシステムは、共有リソースを利用してアプリケーションサービスを提供する提供手段と、ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手段と、そのユーザに対する共有リソースの使用許可量を取得する許可量取得手段と、使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手段と、を備える。システムは、一つの筐体を用いて構成されていても、通信可能に設定された複数の筐体を用いて構成されていてもよい。

本発明の共有リソース管理方法は、共有リソースを利用してアプリケーションサービスを提供するシステムが実行する方法であって、ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手順と、そのユーザに対する共有リソースの使用許可量を取得する許可量取得手順と、使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手順と、を含む。

本発明の共有リソース管理装置は、共有リソースを利用してアプリケーションサービスを提供するシステムを管理する装置であって、ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手段と、そのユーザに対する共有リソースの使用許可量を取得する許可量取得手段と、使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手段と、を備える。

以下に本発明の代表的な実施の形態について説明する。ここでは、管理すべき共有リソースの例として、アプリケーションの提供システム内のＬＡＮを取り上げて説明する。

図１は、本実施の形態にかかる装置構成を説明する概略図である。ここには、クライアントマシンとしてのＰＣ（パーソナルコンピュータ）１０，１２，１４が示されており、それぞれ、通常はユーザｕ００１，ｕ００２，ｕ００３によって使用されている。このＰＣ１０，１２，１４は、インターネット１６に接続されており、また、インターネット１６には、データセンタ２０も接続されている。

データセンタ２０は、アプリケーションサービスを提供するためのシステムを構成するものである。具体的には、インターネット１６からＬＡＮ２２が引き込まれ、このＬＡＮ２２にはＡＰ１提供装置２４及びＡＰ２提供装置２６が接続されている。ＡＰ１提供装置２４は、インターネット１６を経由してアクセスする登録ユーザに対し、アプリケーションサービスＡＰ１を提供するための装置であり、ＡＰ２提供装置２６はアプリケーションサービスＡＰ２を提供するための装置である。アプリケーションの例としては、データ交換サービスや、画像処理サービスなどを挙げることができる。このＡＰ１提供装置２４には、共有リソースとしてのＬＡＮ２２を特定のユーザにのみ独占させないように、条件に従ってユーザの利用可能性を判定する判定部２８が設けられている。また、同様にして、ＡＰ２提供装置２６には判定部３０が設けられている。判定部２８，３０は、次に述べるリソース集計装置３２と連携しながら、アプリケーションサービスを要求するユーザに対し、要求を認めるか否かを判定するものである。

データセンタ２０に設けられたリソース集計装置３２は、ＬＡＮ２２の使用状況の集計等を行う装置である。このリソース集計装置３２には、リソースにかかる演算を行う算出部３４、及び、記憶されたデータとしてのリソース利用履歴テーブル３６及びリソース利用可能量テーブル３８が設けられている。リソース利用履歴テーブル３６及びリソース利用可能量テーブル３８は、算出部３４によって参照され更新されるテーブルであり、算出部３４はこれらのテーブルを用いてユーザの現時点における利用可能量の算出を行う。

ここで、図２及び図３を用いて、それぞれ、ＬＡＮ２２の利用にかかるリソース利用履歴テーブル３６及びリソース利用可能量テーブル３８の例を説明する。

図２に示したリソース利用履歴テーブル３６には、左から右に向かって日時欄５０、ＵＩＤ欄５２、利用量欄５４が設けられている。そして、上から下に向かって、各ユーザの利用にかかる記録がなされている。例えば、行６０には、２００５年５月１１日の１５時１４分２１秒にユーザｕ００１によって１．３Ｍｂｙｔｅのデータ転送がなされたことを示している。同様にして、行６２は、２００５年５月１２日の９時５３分３秒にユーザｕ００２によって７．８Ｍｂｙｔｅのデータ転送がなされたことを、行６４は、２００５年５月１２日の１１時５５分３１秒にユーザｕ００１によって５．１Ｍｂｙｔｅのデータ転送がなされたことを記録している。

図３に示したリソース利用可能量テーブル３８は、このテーブルが更新された時刻において各ユーザに割り当てが基本設定されている基本割り当て量及び各ユーザの過去一定期間における利用積算量を表すものである。具体的には、テーブルの左から右にかけて、ＵＩＤ欄７０、１時間当たり基本割り当て量欄７２、１日当たり基本割り当て量欄７４、過去１時間利用量欄７６、過去１日利用量欄７８が設けられている。例えば、行８０は、ユーザｕ００１に設定された基本割り当て量は、１時間当たり１０Ｍｂｙｔｅ、１日当たり５０Ｍｂｙｔｅであり過去１時間に実際に利用した量は５．１Ｍｂｙｔｅ、過去１日に実際に利用した量は２１．１Ｍｂｙｔｅであることを示している。同様にして、行８２は、ユーザｕ００２に設定された基本割り当て量は、１時間当たり２０Ｍｂｙｔｅ、１日当たり１００Ｍｂｙｔｅであり過去１時間及び過去１日に利用した量はそれぞれ０．０Ｍｂｙｔｅ及び３２．９Ｍｂｙｔｅであることを示している。

次に、これらの装置構成を利用した典型的な処理の流れを、図４、図５、図６を用いて説明する。

図４は、アプリケーションサービスの開始から終了までの一連の流れを説明するフローチャートである。アクセス権を有する登録ユーザは、クライアントマシンからインターネット１６を経由して例えばＡＰ１提供装置２４にログインする。そして、データ転送をともなうアプリケーションサービスＡＰ１を要求する（Ｓ１０）。すると、ＡＰ１提供装置２４は、リソース集計装置３２に対し、サービス要求があったユーザのＩＤを送信する（Ｓ１２）。

リソース集計装置３２は、取得したユーザＩＤをもつユーザの現時点における利用可能量ｘを算出し、ＡＰ１提供装置２４に送信する（Ｓ１４）。この情報を受信したＡＰ１提供装置２４においては、判定部２８が、現時点における利用可能量ｘはサービス要求されたアプリケーションサービスＡＰ１の実施に必要なデータ転送量ｙよりも大きいか否かを判定する（Ｓ１６）。そして、大きくない場合には、サービス要求を受け付けないこととし（Ｓ１８）、ユーザにその旨を通知して処理を終了する。

これに対し、利用可能量ｘがデータ転送量ｙよりも大きい場合には、処理が可能であると判定し、ＡＰ１提供装置２４はサービス要求を受け付けて、アプリケーションサービスＡＰ１を実行する（Ｓ２０）。サービスの実行が終了すると、ＡＰ１提供装置２４からリソース集計装置３２に対し実際に転送を行ったデータ転送量が送信され（Ｓ２２）、リソース集計装置３２はこのユーザのリソース利用履歴テーブル３６とリソース利用可能量テーブル３８を最新状態に更新して（Ｓ２４）処理を終了する。

図５は、図４におけるステップＳ１４の過程を詳しく示すフローチャートである。リソース集計装置３２では、ユーザＩＤを受信すると、リソース利用可能量テーブル３８の更新を行う（Ｓ３０）。この更新は、前回の更新時にはリソース利用可能量テーブル３８において過去所定期間の利用量として集計されていたが、現在時刻ではその所定期間からはみ出した利用の記録を、リソース利用履歴テーブル３６から取得することで行う。すなわち、はみ出した分に対応する利用量が、リソース利用可能量テーブル３８における過去１時間利用量及び過去１日利用量の値から減じられる。

続いて、算出部３４は、更新したリソース利用可能量テーブル３８を参照し、「ａ＝（１日当たり基本割り当て量）−（過去１日利用量）」の演算（Ｓ３２）、及び、「ｂ＝（１時間当たり基本割り当て量）−（過去１時間利用量）」の演算を行う（Ｓ３４）。そして、求めたａ，ｂの二つのうち大きな値を、現在のこのユーザの利用可能量ｘとして求める。

図６は、図４におけるステップＳ２４の過程を詳しく示すフローチャートである。リソース集計装置３２は、まず、リソース利用可能量テーブル３８における過去１時間利用量及び過去１日利用量を更新する（Ｓ４０）。この更新は、図５に示したステップＳ３０と同様にして行われる。続いて、ＡＰ１提供装置２４から入力されたユーザの要求にかかるデータ転送量に基づいて、リソース利用可能量テーブル３８の過去１時間利用量及び過去一日利用量の値を増加させる（Ｓ４２）。さらに、リソース利用履歴テーブル３６に、入力されたユーザの要求にかかるデータ転送量についての記録を追加する（Ｓ４４）。

以上に示した例は、様々に変形可能である。例えば、図３に示したリソース利用可能量テーブル３８においては、１時間当たり基本割り当て量及び１日当たり基本割り当て量をユーザ別に設定した。しかし、これは、全ユーザについて共通に設定することも可能である。また、基本割り当て量を、各時点で実際にＬＡＮ２２が使われている状況に基づいて動的に変更するようにしてもよい。例えば、割り当て時やその前の所定期間におけるＬＡＮ２２の使用状況の情報を取得し、ＬＡＮ２２の容量を超えない範囲でユーザの基本割り当て量を動的に増やすことができる。

以下では、図７、図８、図９を用いて、実施態様の別の変形例について説明する。

図７は、変形例にかかる装置構成を説明する概略図である。この図は図１と対応する図であり、同一の構成には同一の番号を付して説明を省略する。

図７においては、図１に記したデータセンタ２０の代わりにデータセンタ１２０が示されている。そしてデータセンタ１２０には、ＡＰ１提供装置１２４及びＡＰ２提供装置１２６が設置されている。ＡＰ１提供装置１２４とＡＰ２提供装置１２６には、図１のＡＰ１提供装置２４やＡＰ２提供装置２６とは異なり、判定部は設けられていない。また、データセンタ１２０には、図１に記したリソース集計装置３２の代わりリソース管理装置１３２が設置されている。このリソース管理装置１３２には、図１のリソース集計装置３２と同様に算出部３４、リソース利用履歴テーブル３６、リソース利用可能量テーブル３８が備えられている他、判定部１４０と受付可能時刻算出部１４２も設けられている。

データセンタ１２０において特徴的な点の一つは、リソース管理装置１３２に判定部１４０が設けられ、ユーザ要求にかかるデータ転送が実施できるか否かを判定することである。これにより、アプリケーションを提供する装置が複数ある場合に、それぞれの装置に判定部を設ける必要がなくなる。また、データセンタ１２０においては、リソース管理装置１３２に受付可能時刻算出部１４２が設けられている点も特徴的である。この受付可能時刻算出部１４２は、ユーザ要求にかかるアプリケーションサービスを直ちに実施できない場合に、いつになれば実施できるようになるかを計算するものである。これにより、ユーザは、サービスの利用計画を立てることが可能となる。

図８は、図７に示した装置構成にかかる処理の流れを概観するフローチャートである。アクセス権を有する登録ユーザは、クライアントマシンからインターネット１６を経由して例えばＡＰ１提供装置１２４にログインする。そして、データ転送をともなうアプリケーションサービスＡＰ１を要求する（Ｓ５０）。すると、ＡＰ１提供装置１２４は、リソース管理装置１３２に対し、サービス要求があったユーザのＩＤとそのサービス要求を実行する上で必要となるデータ転送量ｙを送信する（Ｓ５２）。

リソース管理装置１３２の算出部３４は、取得したユーザＩＤに基づいてそのユーザの利用可能量ｘを算出する（Ｓ５４）。そして、リソース管理装置１３２の判定部１４０は、算出された利用可能量ｘが、受信したデータ転送量ｙよりも大きいか否かに基づいて、実行可能性を判定する。

必要となるデータ転送量ｙの方が大きい場合には、リソース管理装置１３２の受付可能時刻算出部１４２がサービス提供可能となる時刻を算出し、ＡＰ１提供装置１２４に出力する。ＡＰ１提供装置１２４では、その旨をユーザに提示して処理を終了、あるいは、実行待ち状態に入る（Ｓ５８）。

利用可能量ｘの方が大きい場合には、リソース管理装置１３２からＡＰ１提供装置１２４に対してサービス受付が可能である旨の出力が行われ（Ｓ６０）、ＡＰ１提供装置１２４はそのサービス要求を受け付けて実行する（Ｓ６２）。実行が終了すると、ＡＰ１提供装置１２４からリソース管理装置１３２に対して実際に行ったデータ転送量が送信される（Ｓ６４）。そこで、リソース管理装置１３２では、その利用状況をリソース利用履歴テーブル３６とリソース利用可能量テーブル３８に反映させる（Ｓ６６）。

図９は、図８におけるステップＳ５６とＳ５８の過程、すなわちサービス可能となる時刻を算出する処理を詳しく示すフローチャートである。この場合、まず、算出部３４は、リソース利用履歴テーブルの過去１時間利用量及び過去１日利用量を更新する（Ｓ７０）。この処理は、図５のステップＳ３０において説明した処理と同様に行われる。続いて、算出部３４は、「ａ＝（１日当たり基本割り当て量）−（過去１日利用量）」の演算、「ｂ＝（１時間当たり基本割り当て量）−（過去１時間利用量）」の演算、及び、「利用可能量ｘ＝Ｍａｘ（ａ，ｂ）」の演算を実施する（Ｓ７２）。判定部１４０は、この結果に基づいてｘ≧ｙを満たすか判定し（Ｓ７４）、満たす場合には、現在利用可能であると判断する（Ｓ７６）。一方、満たさないと判断された場合には、受付可能時刻算出部１４２に処理が委ねられる。

受付可能時刻算出部１４２では、最初に１時間当たりの利用可能量がｙ以上となる時刻ｔ１を求める処理を行う（Ｓ８０〜Ｓ８８）。具体的には、まず、ａ≧ｙを満たすか否か判定する。満たす場合には、時刻ｔ１として現在時刻を設定する（Ｓ８０）。満たさないと判断した場合には、リソース利用履歴の過去１日の履歴のうち、未だ読み込まれていない最も古い履歴を読み込む（Ｓ８２）。そして、読み込んだ履歴にかかるリソース利用量をａに追加し（Ｓ８４）、更新後のａについてａ≧ｙを満たすか否か判定する。満たさない場合はステップＳ８２からの処理が繰り返される。満たす場合には、その履歴項目に対応する時刻に１日をプラスした時刻が１時間あたりの利用可能量がｙ以上となる時刻ｔ１として設定される。

続いて、受付可能時刻算出部１４２では、同様にして、１日当たりの利用可能量がｙ以上となる時刻ｔ２を求める（Ｓ９０）。そして、得られたｔ１とｔ２のうち大きな値を、ユーザ要求にかかる処理が実行可能となる時刻ｔとして算出する（Ｓ９２）。

本実施の形態にかかる装置構成例を説明する概略図である。 リソース利用履歴テーブルの例を示す図である。 リソース利用可能量テーブルの例を示す図である。 処理の流れの例を示すフローチャートである。 図４のステップＳ１４を詳しく説明するフローチャートである。 図４のステップＳ２４を詳しく説明するフローチャートである。 変形例にかかる装置構成を説明する概略図である。 変形例の処理の流れの例を示すフローチャートである。 図８のステップＳ５６，Ｓ５８を詳しく説明するフローチャートである。

符号の説明

１０，１２，１４ ＰＣ、１６ インターネット、２０，１２０ データセンタ、２２ ＬＡＮ、２４，１２４ ＡＰ１提供装置、２６，１２６ ＡＰ２提供装置、２８，３０，１４０ 判定部、３２ リソース集計装置、３４ 算出部、３６ リソース利用履歴テーブル、３８ リソース利用可能量テーブル、１３２ リソース管理装置、１４２ 受付可能時刻算出部、ＡＰ１ アプリケーションサービス、ＡＰ２ アプリケーションサービス。

Claims (8)

1. 共有リソースを利用してアプリケーションサービスを提供するシステムに対し、
   ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手順と、
   そのユーザに対する共有リソースの使用許可量を取得する許可量取得手順と、
   使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手順と、
   を実行させる、ことを特徴とする共有リソース管理プログラム。
2. 請求項１に記載の共有リソース管理プログラムにおいて、
   共有リソースは、ネットワークについてのリソースである、ことを特徴とする共有リソース管理プログラム。
3. 請求項１に記載の共有リソース管理プログラムにおいて、
   許可量取得手順において取得する使用許可量は、そのユーザに対する基本割当量と、そのユーザの過去のリソース使用量に基づいて決定される、ことを特徴とする共有リソース管理プログラム。
4. 請求項１に記載の共有リソース管理プログラムにおいて、
   当該システムに対し、全共有リソースの未使用量を取得する未使用量取得手順を実行させ、
   判定手順においては、全共有リソースの未使用量にも基づいて判定を行う、ことを特徴とする共有リソース管理プログラム。
5. 請求項１に記載の共有リソース管理プログラムにおいて、
   判定手順においては、その時点での処理が不可能であると判定される場合に、処理が可能となる予定時刻が算出される、ことを特徴とする共有リソース管理プログラム。
6. 共有リソースを利用してアプリケーションサービスを提供する提供手段と、
   ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手段と、
   そのユーザに対する共有リソースの使用許可量を取得する許可量取得手段と、
   使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手段と、
   を備える、ことを特徴とするアプリケーションサービス提供システム。
7. 共有リソースを利用してアプリケーションサービスを提供するシステムが実行する方法であって、
   ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手順と、
   そのユーザに対する共有リソースの使用許可量を取得する許可量取得手順と、
   使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手順と、
   を含む、ことを特徴とする共有リソース管理方法。
8. 共有リソースを利用してアプリケーションサービスを提供するシステムを管理する装置であって、
   ユーザ要求にかかるアプリケーションサービスの処理に必要となる共有リソースの使用予定量を取得する予定量取得手段と、
   そのユーザに対する共有リソースの使用許可量を取得する許可量取得手段と、
   使用許可量と使用予定量とに基づいて、そのアプリケーションサービスの処理可能性を判定する判定手段と、
   を備える、ことを特徴とする共有リソース管理装置。
   
   

Images