JP5626023B2 - リソース管理システム、リソース管理方法およびリソース管理プログラム - Google Patents

リソース管理システム、リソース管理方法およびリソース管理プログラム Download PDF

Info

Publication number
JP5626023B2
JP5626023B2 JP2011044952A JP2011044952A JP5626023B2 JP 5626023 B2 JP5626023 B2 JP 5626023B2 JP 2011044952 A JP2011044952 A JP 2011044952A JP 2011044952 A JP2011044952 A JP 2011044952A JP 5626023 B2 JP5626023 B2 JP 5626023B2
Authority
JP
Japan
Prior art keywords
resource
amount
secured
information
reservation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011044952A
Other languages
English (en)
Other versions
JP2012181730A (ja
Inventor
晋 原田
晋 原田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2011044952A priority Critical patent/JP5626023B2/ja
Publication of JP2012181730A publication Critical patent/JP2012181730A/ja
Application granted granted Critical
Publication of JP5626023B2 publication Critical patent/JP5626023B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、貸し出し対象となるリソースを管理するリソース管理システム、リソース管理方法およびリソース管理プログラムに関し、特に、予約されたリソースを管理するリソース管理システム、リソース管理方法およびリソース管理プログラムに関する。
リソースを用いて提供されるサービスの予約を受け入れるシステムが種々提案されている。例えば、特許文献１には、高機能ネットワークが提供するサービスを利用するエンドユーザコンピュータ、サービス提供に関する様々な状況を管理、処理する管理コンピュータ群、およびサービスの予約と実行を制御するサービス提供管理コンピュータを有するサービス提供システムが記載されている。そして、特許文献１には、基準とする重要度以下の予約の要求に関しては、たとえ、その予約通りのサービスを実行したときに、サービスに使用する資源量がサービスに利用可能な資源量を超えないとしても、その予約を拒否することが記載されている。
また、特許文献２には、グリッド計算のジョブを実行するための複数台の計算機（リソース）を格納するリソースプールと、リソース予約・管理装置とを備えるグリッド計算システムが記載されている。特許文献２に記載されたリソース予約・管理装置は、ジョブ予約情報に基づいてジョブの実行を予約するとともに、計算機にジョブを実行させる。
また、特許文献３には、ジョブ実行予定データと、ジョブ実行実績データから、今後の使用計算機資源量を予測し、今後の使用計算機資源量が、登録されている計算機資源量を上回る場合に、警告することが記載されている。
特開２００１−９２９１０号公報（段落００２１，０１２９） 特開２００５−３４６４３３号公報（段落００１８，００１９） 特開２００８−３７３６号公報（段落００１０）
一般に、コンピュータリソースを貸し出すシステムでは、リソースの利用開始日時が事前に判明している場合、利用者は予めリソースの予約を申請する。また、予約ではなく、即時にリソースを利用することを利用者が要求し、この要求に応じてリソースを貸し出す場合もある。
上記のようにリソースの予約を受け付ける場合、ある利用者が予約したリソースの利用開始の直前に、別の利用者が即時にリソースを利用することを要求した場合、この要求を受け付けてしまうと、先に予約をした利用者に対してリソースの貸し出しを行えなくなってしまう。
一方、このような問題を解決するために、利用者が予約を行った時点で全てのリソースを確保して、即時の利用を望む利用者からの要求を受け付けないようにすると、利用者が予約をした時点で、全てのリソースを貸し出したのと同様の状態になり、予約という概念に実質的な意味がなくなってしまう。
余計なリソースの確保を抑え、即時の利用を望む者に対してはできるだけ即時にリソースを利用させることができ、予約をした利用者に対しては、予約した量のリソースを予定された利用開始時から利用させることができることが好ましい。しかし、特許文献１〜３に記載された技術では、このようなリソースの管理を行うことはできなかった。
そこで、本発明は、余計なリソースの確保を抑えつつ、予約をした利用者が、予約した量のリソースを、予定した利用開始時から利用できる確実性を高めることができるリソース管理システム、リソース管理方法およびリソース管理プログラムを提供することを目的とする。
本発明によるリソース管理システムは、利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶するリソース情報記憶手段と、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算手段と、リソースの確保を行うリソース管理手段と、所定のタイミング毎に、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する制御手段とを備えることを特徴とする。
また、本発明によるリソース管理方法は、リソース情報記憶手段が、利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶し、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算手段に対して、制御手段が、所定のタイミング毎に、現在時に確保しておくべきリソース量、および追加確保量を計算させ、制御手段が、リソースの確保を行うリソース管理手段に対して、追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新することを特徴とする。
また、本発明によるリソース管理プログラムは、利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶するリソース情報記憶手段を備えるコンピュータに搭載されるリソース管理プログラムであって、コンピュータに、所定のタイミング毎に、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算処理、追加確保量分のリソースの確保を行うリソース管理処理、および、リソース管理処理で確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する更新処理を実行させることを特徴とする。
本発明によれば、余計なリソースの確保を抑えつつ、予約をした利用者が、予約した量のリソースを、予定した利用開始時から利用できる確実性を高めることができる。
本発明の第１の実施形態のリソース管理システムの例を示すブロック図である。 リソース管理テーブルの例を示す説明図である。 リソースＤＢ管理装置が記憶する情報の例を示す説明図である。 端末装置から非予約要求を受信する場合における処理経過の例を示すフローチャートである。 端末装置から予約要求を受信する場合における処理経過の例を示すフローチャートである。 リソース確保制御処理の処理経過の例を示すフローチャートである。 リソース不足の通知の出力タイミングの例を示す説明図である。 リソースの払い出し時の処理経過の例を示すフローチャートである。 本発明の第２の実施形態のリソース管理システムの例を示すブロック図である。 第２の実施形態における、現時点で確保しておくべき総リソース量の計算の処理経過の例を示すフローチャートである。 現時点で確保しておくべき総リソース量Ｒの計算例を示す模式図である。 本発明の第３の実施形態のリソース管理システムの例を示すブロック図である。 リソース開放予定情報の例を示す説明図である。 第３の実施形態における、現時点で確保しておくべき総リソース量の計算の処理経過の例を示すフローチャートである。 本発明のリソース管理システムの最小構成の例を示す説明図である。
以下、本発明の実施形態を図面を参照して説明する。
以下に示す各実施形態では、コンピュータリソースの貸し出しを行う場合を例にして説明するが、貸し出し対象となるリソースはコンピュータリソースに限定されない。例えば、ホテルの空き室、レストランの空き席、病室、病床、駐車場、タクシー、各種交通機関等を貸し出し対象リソースとして用いる場合であっても、本発明を適用可能である。
実施形態１．
図１は、本発明の第１の実施形態のリソース管理システムの例を示すブロック図である。第１の実施形態のリソース管理システムは、複数のリソースを有するリソースプール１０と、リソースプール管理装置１１と、リソースデータベース管理装置（以下、リソースＤＢ管理装置と記す）１２と、リソースプロビジョニング装置１３と、確保量計算装置１４と、通知装置１５とを備える。
本実施形態では、リソースがコンピュータリソースである場合を例に説明する。リソースプール１０は、利用者に貸与され利用後に返却されるリソース＃１，＃２，・・・が一定量集められた装置であってもよい。ただし、前述のようにリソースはコンピュータリソースに限定されず、リソースの種類によっては、リソースプール１０は装置でなくてもよい。
また、本例において、コンピュータリソースの態様は特に限定されない。各リソース＃１，＃２，・・・は、複数の属性を持ち、属性毎に値が設定されるもの（例えば、ＣＰＵとストレージ）であってもよい。ここで例示した「ＣＰＵとストレージ」では、「ＣＰＵのコアの数」および「ストレージの容量」が属性に該当し、各属性に値が設定される。
また、個々のリソース＃１，＃２，・・・には、それぞれリソースを識別するためのリソース識別子が割り当てられる。
また、リソースプール１０において、リソースが増設可能であってもよい。リソースの増設方法は特に限定されない。リソースを増設するには、一定の時間がかかる。例えば、リソースがサーバである場合、サーバの増設には、サーバを発注してから、納品・設定が完了するまでのリードタイムが必要になる。
リソースプール管理装置１１は、リソースプール１０を管理する。具体的には、個々のリソースが、どの利用者に利用されているかを管理する。この管理のために、リソースのリソース識別子毎に、利用者を識別する利用者識別子を格納するリソース管理テーブルを保持する。図２は、リソース管理テーブルの例を示す説明図である。リソース識別子毎に、リソースを利用する利用者の利用者識別子が対応付けられる。
ただし、利用されておらず予約もされていないリソースのリソース識別子に対応する利用者識別子としては、そのリソースの状態を示す「空き」という状態情報が設定される。また、現在利用されていないが予約されているリソースのリソース識別子に対応する利用者識別子としては、そのリソースの状態を示す「予約」という状態情報が設定される。このように、リソースプール管理装置１１が保持するリソース管理テーブルでは、利用者識別子として、具体的な利用者を示す識別子だけが設定されるとは限らず、利用されていないリソースに対応する利用者識別子としては、「空き」や「予約」等のリソースの状態情報が設定されることもある。以下の説明では、現在、利用も予約もされていないことを示す状態情報として「空き」という文字列を用い、現在、利用されていないが予約されていることを示す状態情報として「予約」という文字列を用いる場合を例にして説明する。これらの文字列は例示であり、状態情報として他の文字列や値等を用いてもよい。
また、リソースプール管理装置１１は、リソースプロビジョニング装置１３からの要求に応じて、必要量のリソースを利用者に対して払い出す。ここで、「リソースを払い出す」とは、利用者がリソースの利用を開始できる状態にすることを意味する。リソースプール管理装置１１がリソースを払い出した時点から、実際に利用者がリソースの利用を開始するまでにタイムラグが生じてもよい。例えば、リソースプール管理装置１１がリソースを払い出した後（すわなち、リソースを利用開始可能な状態とした後）、その旨を利用者に通知して、利用者がリソースの利用を開始してもよい。
また、リソースプール管理装置１１は、リソースプロビジョニング装置１３からの指示に従って、リソースを確保する。リソースの確保については、後述する。
リソースＤＢ管理装置１２は、リソースの予約状況を示すリソース予約情報や、確保済みリソース量を記憶する。また、リソースＤＢ管理装置１２は、リソースの増設計画に関する情報（以下、リソース増設計画情報と記す。）を記憶していてもよい。リソースＤＢ管理装置１２は、これらの情報の集合（データベース）を管理する。
図３は、リソースＤＢ管理装置１２が記憶する情報の例を示す説明図である。図３（ａ）は、リソース予約情報を示す。リソース予約情報では、リソースを予約した利用者の利用者識別子と、その利用者が予約の際に要求したリソース量（要求リソース量）と、その利用者が利用を開始する利用開始時とを対応付けた情報である。なお、以下の説明では、説明を簡単にするために、「日」を単位にして利用開始時を指定する場合を例にして説明し、利用開始時を「利用開始日」と記す。ただし、「時」、「分」等のより詳細な単位で、利用開始時を指定してもよい。リソース予約情報は、利用者がリソースを予約する毎にリソースプロビジョニング装置１３によって生成され、リソースＤＢ管理装置１２に記録される。
また、リソースＤＢ管理装置１２が記憶する確保済みリソース量（図３（ｂ）参照）は、各予約に応じて払い出されることになるリソース量のうち、確保済みになっているリソース量である。ここで、「確保」とは、予約の際に指定された利用開始日以前の時点で、予約されたリソースを他の利用者に払い出すことを禁止することを意味する。ただし、本発明では、予約されたリソースを時間経過に伴い段階的に確保していく。リソースを確保する処理は、時間経過に伴って、所定のタイミング毎に行われる。そして、各予約において要求されたリソース量のうち、現時点で確保済みになっているリソース量が、確保済みリソース量としてリソースＤＢ管理装置１２に記録される。
図３（ｃ）は、リソース増設計画情報を示す。リソース増設計画情報では、リソースの増設予定日と、その増設予定日に増設されるリソース量とが対応付けられている。リソースの増設計画毎に、リソース増設計画情報が定められる。
リソースプロビジョニング装置１３は、利用者１８の端末装置１７からリソースの要求を受け付け、リソースプール管理装置１１に対して、リソースの払い出しを要求する。利用者１８の端末装置１７からのリソース要求には、即時のリソースの払い出しの要求（以下、非予約要求と記す。）と、リソースの予約の要求（以下、予約要求と記す。）とがある。非予約要求および予約要求は、いずれも、利用者識別子と要求するリソース量の情報とを含んでいる。また、予約要求は、さらに、利用開始日の情報も含んでいる。リソースプロビジョニング装置１３は、利用者１８の端末装置１７から非予約要求を受信すると、すぐに、リソースプール管理装置１１に、要求されたリソース量を、利用者識別子によって特定される利用者に対して払い出させる。また、リソースプロビジョニング装置１３は、利用者１８の端末装置１７から予約要求を受信した場合、指定された利用開始日になったときに、リソースプール管理装置１１に、要求されたリソース量を、利用者識別子によって特定される利用者に対して払い出させる。
また、リソースプロビジョニング装置１３は、時間経過に伴って所定のタイミング毎に、確保量計算装置１４に、新たに確保すべきリソース量を計算させる。そして、計算されたリソース量分のリソースをリソースプール管理装置１１に確保させる。本発明では、この処理により、各予約で要求されているリソースの総量を、時間経過とともに段階的に分けて確保していく。リソースを確保するタイミングの例については後述する。
また、リソースプロビジョニング装置１３は、リソースの増設通知を行う条件が成立したときに、通知装置１５に、リソースの増設が必要である旨の通知を出力させる。この条件については後述する。
確保量計算装置１４は、リソースプロビジョニング装置１３から指示があったときに、その時点におけるリソース予約情報（図３（ａ）参照）と、確保済みリソース量（図３（ｂ）参照）と、現在日時とに基づいて、その時点で新たに追加して確保すべきリソース量を計算する。
通知装置１５は、リソースプロビジョニング装置１３からの要求に従って、リソース管理システムの運用者１９に対して、リソースの増設が必要である旨の通知を出力する。
なお、運用者１９は、リソースプール１０に対するリソースの増設を計画し、リソースの増設を行う。また、通知装置１５からの通知は、運用者１９がリソースの増設を計画する契機の一つになる。
端末装置１７は、リソースの利用者１８によって所持される。そして、端末装置１７は、利用者１８の操作に応じて、非予約要求または予約要求をリソースプロビジョニング装置１３に送信する。
リソースプール１０、リソースプール管理装置１１、リソースＤＢ管理装置１２、リソースプロビジョニング装置１３、確保量計算装置１４、通知装置１５および端末装置１７は、有線または無線の通信ネットワークによって相互に接続されている。通信ネットワークの種類は、特に限定されない。
また、リソースプール管理装置１１、リソースＤＢ管理装置１２、リソースプロビジョニング装置１３、確保量計算装置１４および通知装置１５が、リソース管理プログラムに従って動作するコンピュータによって実現されていてもよい。この場合、コンピュータがリソース管理プログラムを読み込み、そのプログラムに従って、リソースプール管理装置１１、リソースＤＢ管理装置１２、リソースプロビジョニング装置１３、確保量計算装置１４および通知装置１５として動作すればよい。
次に、動作について説明する。
まず、利用者１８の端末装置１７から非予約要求を受信する場合の動作について説明する。図４は、端末装置１７から非予約要求を受信する場合における処理経過の例を示すフローチャートである。端末装置１７は、利用者１８の操作に従って、非予約要求（即時のリソースの払い出し要求）をリソースプロビジョニング装置１３に送信する（ステップＳ１）。端末装置１７は、ステップＳ１において、利用者１８の利用者識別子と、利用者１８に指定された必要なリソース量（利用者１８が要求するリソース量）の情報も含めて非予約要求を送信する。リソースプロビジョニング装置１３は、この非予約要求を受信する。
リソースプロビジョニング装置１３は、非予約要求で指定された利用者識別子が示す利用者１８に、非予約要求で指定されたリソース量を払い出すように、リソースプール管理装置１１に要求する（ステップＳ２）。
リソースプール管理装置１１は、リソースプロビジョニング装置１３からの要求に応じて、リソース管理テーブル（図２参照）で使用者識別子が「空き」に設定されているリソースの集合から、要求されたリソース量分のリソースを選び出し、そのリソースのリソース識別子に対応する利用者識別子として、非予約要求を送信した利用者１８の利用者識別子を設定する。そして、指定された利用者識別子が示す利用者１８に、選び出したリソースを払い出す（ステップＳ３）。
ステップＳ３で、リソースの払い出しが行われることで、非予約要求を送信した利用者１８は、要求したリソースを利用可能となる。
なお、非予約要求は、予約要求とは非同期かつ順不同に発生する。
次に、利用者１８の端末装置１７から予約要求を受信する場合の動作について説明する。図５は、端末装置１７から予約要求を受信する場合における処理経過の例を示すフローチャートである。端末装置１７は、利用者１８の操作に従って、予約要求をリソースプロビジョニング装置１３に送信する（ステップＳ１１）。端末装置１７は、ステップＳ１１において、利用者１８の利用者識別子と、利用者１８に指定された必要なリソース量（利用者１８が予約するリソース量）および利用開始日の情報も含めて予約要求を送信する。リソースプロビジョニング装置１３は、この予約要求を受信する。
リソースプロビジョニング装置１３は、受信した予約要求に含まれている利用者識別子と、予約されたリソース量（要求リソース量）と、利用開始日とを対応付けて、リソース予約情報（図３（ａ）参照）として、リソースＤＢ管理装置１２に記憶させる（ステップＳ１２）。
なお、端末装置１７は、利用者１８の操作に従って予約要求を送信する。従って、ステップＳ１１の発生タイミングは任意であり、また、ステップＳ１１の処理は１回だけとは限らない。端末装置１７によって予約要求が送信され、その予約要求を受信する毎に、リソースプロビジョニング装置１３は上記のステップＳ１２を実行する。
また、リソースプロビジョニング装置１３は、時間経過とともに、所定のタイミング毎に、リソースの確保に関する制御を行う。以下、この処理をリソース確保制御処理と記す。リソース確保制御処理を、時間経過とともに繰り返し行っていくことで、予約されたリソースを段階的に確保していく。
さらに、リソース確保制御処理において、リソースプロビジョニング装置１３は、リソース確保の結果に基づいて、リソースの増設が必要である旨の通知を通知装置１５に出力させるか否かの判断も行い、その通知を出力させると判断した場合には、通知装置１５にその通知（リソースの増設が必要である旨の通知）を出力させる。
本実施形態では、リソース管理システムが定期的（例えば、１日おき）にリソース確保制御処理を行うとともに、リソースＤＢ管理装置１２に記憶されているいずれかの利用開始日（図３（ａ）参照）の所定期間前になった時点でも、リソース確保制御処理を行う場合を例にして説明する。この所定期間とは、リソースの発注から納入までに要する期間に、余裕期間を加えた期間であり、以下、この所定期間を「リソース増設猶予期間」と記す。例えば、リソースがサーバである場合、サーバの発注から納入までに要する期間に、余裕期間となる日数を加えた期間を、リソース増設猶予期間とすればよい。また、リソース（上記の例ではサーバ）の提供会社との間で連携することにより、リソースの発注から納入までに要する期間を動的に決定してもよい。また、余裕期間は、作業効率や休日等を考慮して運用者１９が設定すればよい。
また、本実施形態では、定期的に実行するリソース確保制御処理で、通知装置１５に通知を出力させると判定した場合の通知内容と、利用開始日のリソース増設猶予期間前の時点で実行するリソース確保制御処理で、通知装置１５に通知を出力させると判定した場合の通知内容とを変えてもよい。本例では、後者の場合の通知内容の方が、前者の場合の通知内容よりも、リソース増設の緊急性がより高いことを表しているものとする。例えば、後者の通知では、予約時に指定された利用開始日に間に合うようにリソースを増設するための準備を開始する最終期限になったことを通知する。
次に、リソース確保制御処理の詳細について説明する。図６は、リソース確保制御処理の処理経過の例を示すフローチャートである。ここでは、定期的に実行するリソース確保制御処理を例にして説明する。
リソース確保制御処理の開始タイミングになると、リソースプロビジョニング装置１３は、確保量計算装置１４に、現時点における事前確保リソース量の総和と、現時点において新たに追加して確保すべきリソース量（以下、追加確保量と記す。）とを計算させる（ステップＳ２１）。
事前確保リソース量とは、１つの予約に関して、その予約で指定された利用開始日と、現時点との差分に応じて、現時点で確保しておくべきリソース量である。ただし、そのリソース量の一部は既に確保されていて、確保済みリソース量に含まれていてもよい。すなわち、事前確保リソース量は、これから新たに追加して確保すべきリソース量を意味しているわけではない。
また、事前確保リソース量は、予約毎に計算される値である。そして、予約毎の事前確保リソース量の総和は、現時点で確保しておくべき総リソース量を意味する。
予約毎の事前確保リソース量の総和から、現時点で、リソースＤＢ管理装置１２に記憶されている確保済みリソース量を減算した値が、追加確保量となる。
また、本例では、説明を簡単にするために、時間を「日」を単位として表記する。よって、本例において、「現時点」とは「現在の日付」である。そして、日付同士を比較した場合、後の日付の値の方が、先の日付の値よりも大きいものとする。
ステップＳ２１において、確保量計算装置１４は、リソースプロビジョニング装置１３からの要求に従って、事前確保リソース量の総和および追加確保量を計算する。以下、この計算方法について説明する。
事前確保リソース量の総和は、個々の予約毎に事前確保リソース量を計算し、その事前確保リソース量を合算することによって算出する。１つの予約に着目した場合、その予約で指定された利用開始日をｚとする。また、現在の日付をｎとする。そして、ここでは、利用開始日ｚから現在の日付ｎを減算した変数をｘで表すものとする。ｘは、現在の日付から利用開始日までの期間を表す。
確保量計算装置１４は、変数ｘの関数ｆ（ｘ）を定義する。ただし、関数ｆ（ｘ）は、“０≦ｆ（ｘ）≦１”という条件を満たしているものとする。なお、通常、ａ＞ｂであるとき、ｆ（ａ）≧ｆ（ｂ）であるが、この関係が成立しない場合であっても、本発明に適用可能である。
予約にて要求されているリソース量をｅで表すものとする。ただし、ｅを、以下のように定めるものとする。
ｎ＜ｚならば、ｅ＝０
ｎ≧ｚならば、ｅ＝１
そして、確保量計算装置１４は、以下に示す式（１）により、１つの予約に関する事前確保リソース量を計算する。
事前確保リソース量＝ｅ×ｆ（ｚ−ｎ） 式（１）
なお、ｆ（ｚ−ｎ）は、関数ｆ（ｘ）と同義である。確保量計算装置１４は、予約毎に、リソース予約情報（図３（ａ）参照）を参照して、式（１）の計算を行い、予約毎に計算した事前確保リソース量を合算することで、事前確保リソース量の総和を求めればよい。
なお、個々の予約を変数ｒで表すものとする。そして、個々の予約におけるｅの値をｅ（ｒ）と表し、個々の予約におけるｚの値をｚ（ｒ）と表すものとする。このとき、事前確保リソース量の総和は、以下の式（２）で表される。
事前確保リソース量の総和＝Σ｛ｅ（ｒ）×ｆ（ｚ（ｒ）−ｎ）｝ 式（２）
ここで、事前確保リソース量の算出に用いる関数ｆ（ｘ）は、例えば、以下のように定めればよい。貸し出していたリソース（換言すれば、払い出していたリソース）の単位時間（例えば、１日）あたりの開放数を統計的に測定しておき、その値をｓとする。最悪の場合、開放されたリソースを全て予約されたリソースに投入すれば予約に対するリソースを確保できると仮定し、関数ｄ（ｔ）を以下のように定める。
ｄ（ｔ）＝１−（ｅ／ｓ）×ｔ
上記の関数ｄ（ｔ）において、ｔは、ｚ−ｎであり（すなわち、現在の日付から利用開始日までの期間であり）、変数ｔの意味は、変数ｘと同様である。
上記の関数ｄ（ｔ）は、現在の日付から利用開始日までの期間を引数ｔとし、現時点（現在の日付）で、確保が必要なリソースのうち何割を確保するべきかを、０〜１の実数値で返す関数である。そして、関数ｆ（ｔ）を以下の式（３）のように定める。
Figure 0005626023
上記の関数ｆ（ｔ）を式（１）におけるｆ（ｚ−ｎ）として用いて、事前確保リソース量を計算すればよい。ただし、上記のｆ（ｔ）は、関数ｆ（ｚ−ｎ）の一例であり、関数ｆ（ｚ−ｎ）として他の関数を用いてもよい。
確保量計算装置１４は、事前確保リソース量の総和を計算した後、事前確保リソース量の総和から、リソースＤＢ管理装置１２に記憶されている確保済みリソース量を減算することによって、追加確保量を算出する。すなわち、以下の式（４）の計算によって、追加確保量を求める。
追加確保量＝Σ｛ｅ（ｒ）×ｆ（ｚ（ｒ）−ｎ）｝ − 確保済みリソース量
式（４）
確保量計算装置１４は、事前確保リソース量の総和、および追加確保量の計算後、それらの値をそれぞれリソースプロビジョニング装置１３に返す。
ステップＳ２１の次に、リソースプロビジョニング装置１３は、確保量計算装置１４によって計算された追加確保量分のリソースの確保を、リソースプール管理装置１１に要求する（ステップＳ２２）。
リソースプール管理装置１１は、リソースプロビジョニング装置１３からの要求に応じて、リソース管理テーブル（図２参照）で使用者識別子が「空き」に設定されているリソースの集合から、追加確保量分のリソースを選び出し、そのリソースのリソース識別子に対応する利用者識別子として「予約」を設定する。そして、リソースプール管理装置１１は、選び出したリソースを確保する（ステップＳ２３）。また、ステップＳ２３において、リソースプール管理装置１１は、確保したリソース量の情報をリソースプロビジョニング装置１３に返す。
ステップＳ２３では、リソースプール管理装置１１は、要求された追加確保量分のリソースを全て確保できるとは限らない。その場合、リソースプール管理装置１１は、追加確保量分のリソースを上限として、確保可能なリソースをできるだけ選び出し、そのリソースのリソース識別子に対応する利用者識別子に「予約」を設定すればよい。そして、選び出すことができた分のリソースを確保し、その確保量の情報をリソースプロビジョニング装置１３に返せばよい。
リソースプロビジョニング装置１３は、ステップＳ２３で新たに確保されたリソース量に基づいて、リソースＤＢ管理装置１２に記憶されている確保済みリソース量を更新する（ステップＳ２４）。具体的には、リソースＤＢ管理装置１２に記憶されている確保済みリソース量に、ステップＳ２３で新たに確保されたリソース量を加算する。ステップＳ２２で要求した追加確保量分のリソースが全て確保されたならば、確保済みリソース量に追加確保量を加算し、その加算結果を、更新後の確保済みリソース量とする。確保されたリソース量が追加確保量分に達していなければ、実際に確保されたリソース量を確保済みリソース量に加算し、その加算結果を、更新後の確保済みリソース量とする。
以上のように、事前確保リソース量の総和、および追加確保量を計算し、追加確保量分のリソースの確保をリソースプール管理装置１１に要求することで、予約されたリソースを時間経過とともに、段階的に確保していくことができる。従って、利用開始日の直前に非予約要求が発生したとしても、予約されたリソースを予約した利用者に払い出すことができなくなってしまうリスクを低減することができる。例えば、利用開始日の直前に、非予約要求が大量に発生し、それらの非予約要求に応じるために、予約とは無関係にリソースを割り当ててしまい、利用開始時にリソースを払い出すことができなくなってしまったり、予約を遂行するために大量のリソースを増設しなければならないという事態を避けることができる。また、予約されたリソース量を一度に確保するのではなく、段階的に確保していくので、確保していないリソースも存在することになり、それらのリソースを用いて非予約要求に応じることができる。
ステップＳ２４の後、リソースプロビジョニング装置１３は、ステップＳ２１で計算された事前確保リソース量の総和と、ステップＳ２４における更新後の確保済みリソース量とを比較し、リソースプール１０のリソースが不足しているか否かを判定する（ステップＳ２５）。具体的には、ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算された事前確保リソース量の総和（すなわち、現時点で確保しておくべき総リソース量）未満であるという条件が満たされていれば、リソースが不足していると判定する。逆に、上記の条件が満たされていなければ、リソースは不足していないと判定する。
新たな予約要求が発生せず、各予約により要求されているリソースの総量が一定であるとする。定期的にリソース確保制御処理を行うと、時間の経過とともに、ステップＳ２１で計算される事前確保リソース量の総和は増加していく、この増加に合わせて、新たにリソースを追加することになるが、「ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算された事前確保リソース量の総和（すなわち、現時点で確保しておくべき総リソース量）未満である」ということは、ステップＳ２１で計算された事前確保リソース量の総和に相当する分のリソースを確保できない状態になったことを意味する。
「ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算された事前確保リソース量の総和未満である」という条件が満たされていれる場合（ステップＳ２５におけるＹｅｓ）、リソースプロビジョニング装置１３は、通知装置１５に、リソースの増設が必要である旨の通知を出力させる。通知装置１５は、リソースプロビジョニング装置１３からの要求に応じて、リソースの増設が必要である旨の通知を出力する（ステップＳ２６）。なお、通知装置１５が行うリソース不足の通知の出力態様は、特に限定されない。例えば、通知装置１５が運用者１９の端末（図示略）に電子メールやショートメッセージを送信することで、リソース不足を通知してもよい。あるいは、サイレン等の音を出力することで、運用者１９にリソース不足を通知してもよい。あるいは、通知装置１５に表示部（図示略）が設けられていて、その表示部に、リソースが不足している旨のメッセージを表示してもよい。これらの通知の出力態様は例示であり、他の態様で通知を出力してもよい。
運用者１９は、通知装置１５からリソース不足の通知を受けると、リソースプール１０に対するリソースの増設を検討したり、リソース増設の準備（例えば、リソースの発注等）を開始したりすればよい。
また、「ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算された事前確保リソース量の総和未満である」という条件が満たされていない場合（ステップＳ２５におけるＮｏ）、リソース確保制御処理を終了する。
また、リソース管理システムは、上記のリソース確保制御処理を定期的に行う。さらに、リソースＤＢ管理装置１２に記憶されたいずれかのリソース予約情報における利用開始日のリソース増設猶予期間前になった時点においても、リソース管理システムは、リソース確保制御処理（ステップＳ２１以降の処理）を行う。いずれかの利用開始日のリソース増設猶予期間前になった時点でリソース確保制御処理を開始し、ステップＳ２５において、リソースが不足していると判断したとする（ステップＳ２５におけるＹｅｓ）。すなわち、ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算された事前確保リソース量の総和未満であったとする。この場合、リソースプロビジョニング装置１３は、予約時に指定された利用開始日に間に合うようにリソースを増設するための準備を開始する最終期限になった旨の通知を、通知装置１５に出力させる（ステップＳ２６）。通知装置１５は、リソースプロビジョニング装置１３からの要求に応じて、その通知を出力する（ステップＳ２６）。この通知は、リソース不足を通知するものであるが、定期的なリソース確保制御処理で通知を出力する場合に比べて、高い緊急性を運用者１９に伝えるための通知である。
図７は、リソース不足の通知の出力タイミングの例を示す説明図である。図７において、横軸は時間経過を表し、縦軸はリソース量を表す。図７に示す例では、新たな予約要求が発生せず、各予約により要求されているリソースの総量がＰで一定であるとする。また、図７において、破線は、ステップＳ２１で計算された事前確保リソース量の総和の変化を示す。一点鎖線は、ステップＳ２４における更新後の確保済みリソース量の変化を示す。図７に示すように、ステップＳ２１で計算される事前確保リソース量の総和は、定期的にリソース確保制御処理を行う毎に増加していき、要求されているリソースの総量Ｐに達すると飽和する。また、事前確保リソース量の総和とともにステップＳ２１で計算される追加確保量分のリソースがステップＳ２３で確保されることが理想である。しかし、非予約要求の増加等の要因により、追加確保量分のリソースを全て確保できない場合もある。この場合、ステップＳ２４における更新後の確保済みリソース量が、事前確保リソース量の総和未満であるという条件が満たされることになる。
図７に示す例では、日付Ａにおいて、この条件が満たされ、日付Ａ以降、その状態が続くことになる。従って、定期的にリソース確保制御処理を行う場合、日付Ａより前では、ステップＳ２６に移行しないが、日付Ａ以後では、ステップＳ２６に移行し、通知装置１５が運用者１９にリソース不足を通知する。
また、あるリソース予約情報において、利用開始日がＣであるとする。そして、利用開始日Ｃのリソース増設猶予期間前における日付がＢであるとする。この時点でも、リソース管理システムはリソース確保制御処理（ステップＳ２１以降の処理）を行う。このときにも、ステップＳ２４における更新後の確保済みリソース量が、事前確保リソース量の総和未満であるという条件が満たされることになる。ただし、この場合、利用開始日Ｃのリソース増設猶予期間前になっているので、プロビジョニング装置１３は、通知装置１５に、より緊急性の高いリソース不足の通知を出力させる。例えば、予約時に指定された利用開始日に間に合うようにリソースを増設するための準備を開始する最終期限になった旨の通知を、通知装置１５に出力させる。
次に、リソースの払い出し時の処理経過について説明する。図８は、リソースの払い出し時の処理経過の例を示すフローチャートである。リソースプロビジョニング装置１３は、リソースＤＢ管理装置１２に記憶されている各リソース予約情報内の利用開始日を定期的に参照し、現在の日付が利用開始日に該当するリソース予約情報があるか否かを確認する。現在の日付が利用開始日に該当するリソース予約情報を検出すると（ステップＳ３１）、リソースプロビジョニング装置１３は、そのリソース予約情報で指定された要求リソース量分のリソースを、そのリソース予約情報内の利用者識別子で特定される利用者に対して払い出すように、リソースプール管理装置１１に要求する（ステップＳ３２）。また、リソースプロビジョニング装置１３は、リソースＤＢ管理装置１２に記憶されている確保済みリソース量から、そのリソース予約情報で指定された要求リソース量を減算する（ステップＳ３３）。ステップＳ３３の処理により、リソースＤＢ管理装置１２に記憶されている確保済みリソース量は更新されることになる。
また、リソースプール管理装置１１は、リソースプロビジョニング装置１３からの要求（ステップＳ３２での要求）に応じて、リソース管理テーブル（図２参照）で使用者識別子が「予約」に設定されているリソースの集合から、リソース予約情報で指定された要求リソース量分のリソースを選び出し、そのリソースのリソース識別子に対応する利用者識別子としてリソース予約情報内の利用者識別子を設定する。そして、リソースプール管理装置１１は、選び出したリソースを、その利用者識別子で特定される利用者に払い出す（ステップＳ３４）。
なお、利用者１８によるリソースの利用が終了したら、リソースプール管理装置１１は、利用が終了したリソースを開放する。そして、リソース管理テーブルにおいて、そのリソースのリソース識別子に対応する利用者識別子を「空き」に設定する。
本実施形態によれば、リソースの予約に対して、段階的にリソースを確保していくことで、利用開始日までに十分な時間がある場合には、利用開始日までにリソースの開放が起こることを見越して、確保するリソース量を少なめにし、利用開始日が近づいてきたときいは必要なリソースを確保することができる。そのため、予約されたリソースの払い出しの確実性を高めるとともに、予約以外のリソース要求（すなわち、非予約要求）に対して払い出すことができるリソース量を増やすことができる。
また、利用開始日までの時間の長さに応じて、現時点で確保すべきリソースが確保できない場合には、通知装置１５が運用者１９に対してリソースの不足を通知する。特に、利用開始日のリソース増設猶予期間前の時点で、確保すべきリソースが確保できない場合には、リソースを増設するための準備を開始する最終期限になったことを通知する。このように、運用者１９に対して、利用開始日までにリソースの増設が完了するように注意を喚起することができるので、利用開始日において予約されたリソースを払い出せないという事態を防止することができる。
また、本実施形態では、ステップＳ２４における更新後の確保済みリソース量が、現時点で確保しておくべき総リソース量未満であるという条件を満たした場合に、リソース不足の通知を出力し、運用者１８は、この通知を契機にリソースの増設を行うことができる。単純に、各予約で要求されたリソース量に合わせて、リソースを増設していくと、過剰なリソースの投資を招いてしまうが、本発明では、ステップＳ２５の判断時に上記の条件が満たされている場合に、リソース不足の通知を出力するので、過剰なリソース投資を防止することができる。
実施形態２．
図９は、本発明の第２の実施形態のリソース管理システムの例を示すブロック図である。第２の実施形態のリソース管理システムは、第１の実施形態における確保量計算装置１４に替えて、確保量計算装置１４ａを備える。他の要素に関しては、第１の実施形態と同様であり、図１と同一の符号を付し詳細な説明を省略する。
第２の実施形態において、リソースＤＢ管理装置１２は、リソース予約情報、確保済みリソース量、およびリソース増設計画情報をそれぞれ記憶する（図３参照）。リソース増設計画情報が示すリソースの増設予定日は、適切な時間的マージンを見越して設定してもよい。このマージンは運用者１９によって定められる。なお、リソース増設計画情報は、例えば、運用者１９がリソースＤＢ管理装置１２に記憶させればよいが、リソース増設計画情報の登録態様は特に限定されない。
第１の実施形態では、予約毎の事前確保リソース量の総和を、現時点で確保しておくべき総リソース量とした。すなわち、式（２）で表される値を、現時点で確保しておくべき総リソース量とした。
これに対し、第２の実施形態では、現時点で確保しておくべき総リソース量の導出方法が異なる。他の点に関しては、第１の実施形態と同様である。以下、確保量計算装置１４ａが、現時点で確保しておくべき総リソース量を計算する方法について説明する。
ステップＳ２１（図６参照）において、確保量計算装置１４ａは、リソースプロビジョニング装置１３からの要求に応じて、現時点で確保しておくべき総リソース量を計算する。図１０は、第２の実施形態における、現時点で確保しておくべき総リソース量の計算の処理経過の例を示すフローチャートである。以下、現時点で確保しておくべき総リソース量を“Ｒ”と記す。
まず、確保量計算装置１４ａは、Ｒを初期値０に設定する（ステップＳ４１）。
次に、確保量計算装置１４ａは、リソースＤＢ管理装置１２から各リソース予約情報および各リソース増設計画情報を読み込み、それらの各情報を、情報内に記述されている時刻（本例では日付）順に並べる（ステップＳ４２）。すなわち、リソース予約情報の利用開始日や、リソース増設計画情報内の増設予定日を参照して、その日付順に、各リソース予約情報および各リソース増設計画情報を並べる。
そして、確保量計算装置１４ａは、未選択のリソース予約情報およびリソース増設計画情報のうち、現時点（現在の日付）から最も遠い日付が記述された情報を選択する（ステップＳ４３）。確保量計算装置１４ａは、選択した情報が、リソース予約情報であるかリソース増設計画情報であるかを判定する（ステップＳ４４）。
選択した情報がリソース予約情報である場合、確保量計算装置１４ａは、そのリソース予約情報に関して（すなわち、その情報が示す予約に関して）、事前確保リソース量を計算し、その事前確保リソース量をＲに加算する（ステップＳ４５）。事前確保リソース量は、第１の実施形態で示した式（１）の計算を行うことによって、求めればよい。また、式（１）で用いる“ｅ”や、関数ｆ（ｚ−ｎ）も、第１の実施形態におけるそれらの関数等と同様である。
また、選択した情報がリソース増設計画情報である場合、確保量計算装置１４ａは、Ｒから、そのリソース増設計画情報で記述されている増設リソース量を減算する（ステップＳ４６）。ただし、この減算は、ステップＳ４６に移行したときにおけるＲが、リソース増設計画情報で記述されている増設リソース量よりも大きい場合に実行する。ステップＳ４６に移行したときにおけるＲが、リソース増設計画情報で記述されている増設リソース量以下である場合、ステップＳ４６において、確保量計算装置１４ａは、Ｒを０に設定する。
ステップＳ４５またはステップＳ４６の実行後、確保量計算装置１４ａは、未選択のリソース予約情報またはリソース増設計画情報があるか否かを判定する（ステップＳ４７）。未選択の情報がある場合（ステップＳ４７におけるＹｅｓ）、確保量計算装置１４ａは、ステップＳ４３以降の処理を繰り返す。
また、未選択のリソース予約情報およびリソース増設計画情報がなければ（ステップＳ４７におけるＮｏ）、確保量計算装置１４ａは、その時点におけるＲの値を、現時点で確保しておくべき総リソース量として確定する（ステップＳ４８）。
図１１は、Ｒの計算例を示す模式図である。図１１において、横軸は日付を表し、原点（０）が現在の日付である。また、縦軸は、リソース予約情報に含まれる要求リソース量、およびリソース増設計画情報に含まれる増設リソース量の値を表す。図１１では、日付Ａ，Ｃ，Ｅを利用開始日とするリソース予約情報と、日付Ｂ，Ｄ，Ｆを増設予定日とするリソース増設計画情報が存在する場合を例示している。ただし、現時点（現在の日付）から遠い順に、Ｆ，Ｅ，Ｄ，Ｃ，Ｂ，Ａであるものとする。
確保量計算装置１４ａは、現時点で確保しておくべき総リソース量Ｒを初期値０に設定する（ステップＳ４１）。そして、各リソース予約情報および各リソース増設計画情報を、日付がＦ，Ｅ，Ｄ，Ｃ，Ｂ，Ａの順になるように並べる（ステップＳ４２）。
本例では、確保量計算装置１４ａは、最初にステップＳ４３に移行したときに、増設予定日がＦとなっているリソース増設計画情報を選択し、ステップＳ４６に移行する。このリソース増設計画情報では、増設リソース量がＡ１になっているとする。ステップＳ４６に移行したときに、Ｒは初期値０であるので、Ｒ≦Ａ１である。よって、確保量計算装置１４ａは、Ｒを０に設定する。すなわち、Ｒは０のまま変化しない。
ステップＳ４６の後、まだ未選択のリソース予約情報またはリソース増設計画情報が残っているので（ステップＳ４７におけるＹｅｓ）、ステップＳ４３に移行する。そして、確保量計算装置１４ａは、利用開始日がＥとなっているリソース予約情報を選択し、ステップＳ４５に移行する。ステップＳ４５では、確保量計算装置１４ａは、そのリソース予約情報が示す予約に関して、事前確保リソース量を計算する。事前確保リソース量は式（１）により計算できる。ここでは、ｚ＝Ｅであり、ｎ＝０である。よって、この事前確保リソース量は、ｅ×ｆ（Ｅ）の計算で求めればよい。この事前確保リソース量をＵ１’とする。確保量計算装置１４ａは、事前確保リソース量Ｕ１’をＲに加算する。この結果、Ｒ＝Ｕ１’となる。
ステップＳ４５の後、まだ未選択のリソース予約情報またはリソース増設計画情報が残っているので（ステップＳ４７におけるＹｅｓ）、ステップＳ４３に移行する。そして、確保量計算装置１４ａは、増設予定日がＤとなっているリソース増設計画情報を選択し、ステップＳ４６に移行する。このリソース増設計画情報では、増設リソース量がＡ２になっていて、Ｕ１’≦Ａ２（すなわち、Ｒ≦Ａ２）であるものとする。よって、確保量計算装置１４ａは、Ｒを０に設定する。このことは、利用開始日Ｅの予約に関して求めた事前確保リソース量Ｕ１’が、日付Ｅより前に増設されるリソース量Ａ２で充足されることを意味する。
ステップＳ４６の後、まだ未選択のリソース予約情報またはリソース増設計画情報が残っているので（ステップＳ４７におけるＹｅｓ）、ステップＳ４３に移行する。そして、確保量計算装置１４ａは、利用開始日がＣとなっているリソース予約情報を選択し、ステップＳ４５に移行する。ステップＳ４５では、確保量計算装置１４ａは、そのリソース予約情報が示す予約に関して、事前確保リソース量を計算する。この事前確保リソース量は式（１）を用いて、ｅ×ｆ（Ｃ）計算で求めればよい。この事前確保リソース量をＵ２’とする。確保量計算装置１４ａは、事前確保リソース量Ｕ２’をＲに加算する。この結果、Ｒ＝Ｕ２’となる。
ステップＳ４５の後、まだ未選択のリソース予約情報またはリソース増設計画情報が残っているので（ステップＳ４７におけるＹｅｓ）、ステップＳ４３に移行する。そして、確保量計算装置１４ａは、増設予定日がＢとなっているリソース増設計画情報を選択し、ステップＳ４６に移行する。このリソース増設計画情報では、増設リソース量がＡ３になっていて、Ｕ２’＞Ａ３（すなわち、Ｒ＞Ａ３）であるものとする。よって、確保量計算装置１４ａは、ＲからＡ３を減算する。この結果、Ｒ＝Ｕ２’−Ａ３となる。この減算は、増設予定日Ｂより後の予約に関する事前確保リソース量の一部が、日付Ｂに増設されるリソース量Ａ３で充足されることを意味する。
ステップＳ４６の後、まだ未選択のリソース予約情報が残っているので（ステップＳ４７におけるＹｅｓ）、ステップＳ４３に移行する。そして、確保量計算装置１４ａは、増設予定日がＡとなっているリソース予約情報を選択し、ステップＳ４５に移行する。ステップＳ４５では、確保量計算装置１４ａは、そのリソース予約情報が示す予約に関して、事前確保リソース量を計算する。この事前確保リソース量は式（１）を用いて、ｅ×ｆ（Ａ）計算で求めればよい。この事前確保リソース量をＵ３’とする。確保量計算装置１４ａは、事前確保リソース量Ｕ３’をＲに加算する。この結果、Ｒ＝Ｕ２’−Ａ３＋Ｕ３’となる。
このステップＳ４５の後、未選択のリソース予約情報およびリソース増設計画情報は残っていないので（ステップＳ４７におけるＮｏ）、確保量計算装置１４ａは、現時点で確保しておくべき総リソース量Ｒの値と、Ｕ２’−Ａ３＋Ｕ３’に確定する（ステップＳ４８）。
なお、未選択のリソース予約情報またはリソース増設計画情報が残っていれば、上記のように、ステップＳ４３以降の処理を繰り返せばよい。
また、確保量計算装置１４ａは、ステップＳ２１において、現時点で確保しておくべき総リソース量Ｒを計算したならば、そのＲから、リソースＤＢ管理装置１２に記憶されている確保済みリソース量を減算することによって、追加確保量を算出する。
そして、確保量計算装置１４ａは、現時点で確保しておくべき総リソース量Ｒ、および追加確保量をリソースプロビジョニング装置１３に返す。
その後のステップＳ２２以降の処理は、第１の実施形態におけるステップＳ２２以降の処理と同様である。ただし、ステップＳ２５では、リソースプロビジョニング装置１３は、「ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算されたＲ未満である」という条件が満たされていれば、リソースが不足していると判定する。逆に、上記の条件が満たされていなければ、リソースは不足していないと判定する。
また、ここでは、第２の実施形態におけるリソース確保制御処理（特に、ステップＳ２１）に関して説明したが、リソース確保制御処理以外の各処理に関しては、第１の実施形態と同様である。
第２の実施形態においても、第１の実施形態と同様の効果が得られる。さらに、第２の実施形態では、予約毎に計算する事前確保リソース量を、増設予定のリソース量で充足することができ、リソース確保制御処理の際に、その時点で確保しておくべき総リソース量Ｒを、第１の実施形態よりも少なくすることができる。その結果、予約以外のリソース要求（非予約要求）に対して払い出すことができるリソース量をより増やすことができ、リソースの利用効率をより上げることができる。また、リソース不足の通知の出力を抑え、余計なリソース増設を防止することができる。
実施形態３．
図１２は、本発明の第３の実施形態のリソース管理システムの例を示すブロック図である。本発明の第３の実施形態のリソース管理システムは、第１の実施形態における確保量計算装置１４に代えて、確保量計算装置１４ｂを備える。また、リソースＤＢ管理装置１２に代えて、リソースＤＢ管理装置１２ｂを備える。他の要素に関しては、第１の実施形態と同様であり、図１と同一の符号を付し詳細な説明を省略する。
リソースＤＢ管理装置１２ｂは、第１の実施形態におけるリソースＤＢ管理装置１２と同様に、リソース予約情報（図３（ａ）参照）、および確保済みリソース量（図３（ｂ）参照）を記憶する。第３の実施形態におけるリソースＤＢ管理装置１２ｂは、これらの情報に加えて、さらに、リソース開放予定情報を記憶する。図１３は、リソース開放予定情報の例を示す説明図である。リソース開放予定情報では、リソースの開放予定日と、その予定日に開放されるリソース量とが対応付けられている。
リソースＤＢ管理装置１２ｂに対するリソース開放予定情報の登録は、例えば、リソースプロビジョニング装置１３が行えばよい。例えば、リソースプロビジョニング装置１３は、予約要求を受けるときに、利用者の端末１７から開放予定日も受信する。そして、リソースプロビジョニング装置１３は、予約されたリソースの利用開始日にリソースプール管理装置１１にリソースの払い出しを要求するとき（ステップＳ３２、図８参照）、その開放予定日もリソースプール管理装置１１に通知する。リソースプール管理装置１１は、リソースを払い出した後（ステップＳ３４の後）、払い出したリソース量とその開放予定日とを対にして、リソースプロビジョニング装置１３に返し、リソースプロビジョニング装置１３は、そのリソース量を開放リソース量として、開放予定日とともに、リソース開放予定情報としてリソースＤＢ管理装置１２ｂに記憶させればよい。ただし、ここで示したリソース開放予定情報の登録態様は例示であり、他の方法でリソース開放予定情報を登録してもよい。
なお、リソースＤＢ管理装置１２ｂは、リソース増設計画情報（図３（ｃ）参照）を他の情報とともに記憶していてもよい。
第３の実施形態における確保量計算装置１２ｂは、リソース増設計画情報の代わりにリソース開放予定情報を用いて、第２の実施形態における確保量計算装置１２ａと同様に、現時点で確保しておくべき総リソース量を導出する。以下、確保量計算装置１４ｂが、現時点で確保しておくべき総リソース量を計算する方法について説明する。
ステップＳ２１（図６参照）において、確保量計算装置１４ｂは、リソースプロビジョニング装置１３からの要求に応じて、現時点で確保しておくべき総リソース量を計算する。図１４は、第３の実施形態における、現時点で確保しておくべき総リソース量の計算の処理経過の例を示すフローチャートである。図１０に示す処理と同一の処理に関しては、同一の符号を付す。第２の実施形態と同様に、現時点で確保しておくべき総リソース量を“Ｒ”と記す。
まず、確保量計算装置１４ｂは、Ｒを初期値０に設定する（ステップＳ４１）。
次に、確保量計算装置１４ｂは、リソースＤＢ管理装置１２から各リソース予約情報および各リソース開放予定情報を読み込み、それらの各情報を、情報内に記述されている時刻（本例では日付）順に並べる（ステップＳ４２ａ）。すなわち、リソース予約情報の利用開始日や、リソース開放予定情報内の開放予定日を参照して、その日付順に、各リソース予約情報および各リソース開放予定情報を並べる。
そして、確保量計算装置１４ｂは、未選択のリソース予約情報およびリソース開放予定情報のうち、現時点（現在の日付）から最も遠い日付が記述された情報を選択する（ステップＳ４３ａ）。確保量計算装置１４ｂは、選択した情報が、リソース予約情報であるかリソース開放予定情報であるかを判定する（ステップＳ４４ａ）。
選択した情報がリソース予約情報である場合の処理は、第２の実施形態におけるステップＳ４５（図１０参照）と同様であり、説明を省略する。
また、選択した情報がリソース開放予定情報である場合、確保量計算装置１４ｂは、Ｒから、そのリソース開放予定情報で記述されている開放リソース量を減算する（ステップＳ４６ａ）。ただし、この減算は、ステップＳ４６ａに移行したときにおけるＲが、リソース開放予定情報で記述されている開放リソース量よりも大きい場合に実行する。ステップＳ４６ａに移行したときにおけるＲが、リソース開放予定情報で記述されている開放リソース量以下である場合、ステップＳ４６ａにおいて、確保量計算装置１４ｂは、Ｒを０に設定する。
ステップＳ４５またはステップＳ４６の実行後、確保量計算装置１４ｂは、未選択のリソース予約情報またはリソース開放予定情報があるか否かを判定する（ステップＳ４７ａ）。未選択の情報がある場合（ステップＳ４７ａにおけるＹｅｓ）、確保量計算装置１４ｂは、ステップＳ４３ａ以降の処理を繰り返す。
また、未選択のリソース予約情報およびリソース開放予定情報がなければ（ステップＳ４７ａにおけるＮｏ）、確保量計算装置１４ｂは、その時点におけるＲの値を、現時点で確保しておくべき総リソース量として確定する（ステップＳ４８）。
また、確保量計算装置１４ｂは、ステップＳ２１において、現時点で確保しておくべき総リソース量Ｒを計算したならば、そのＲから、リソースＤＢ管理装置１２に記憶されている確保済みリソース量を減算することによって、追加確保量を算出する。
そして、確保量計算装置１４ｂは、現時点で確保しておくべき総リソース量Ｒ、および追加確保量をリソースプロビジョニング装置１３に返す。
その後のステップＳ２２以降の処理は、第１の実施形態におけるステップＳ２２以降の処理と同様である。ただし、ステップＳ２５では、リソースプロビジョニング装置１３は、「ステップＳ２４における更新後の確保済みリソース量が、ステップＳ２１で計算されたＲ未満である」という条件が満たされていれば、リソースが不足していると判定する。逆に、上記の条件が満たされていなければ、リソースは不足していないと判定する。
また、ここでは、第３の実施形態におけるリソース確保制御処理（特に、ステップＳ２１）に関して説明したが、リソース確保制御処理以外の各処理に関しては、第１の実施形態と同様である。
第３の実施形態においても、第１の実施形態と同様の効果が得られる。さらに、第２の実施形態では、予約毎に計算する事前確保リソース量を、開放予定のリソース量で充足することができる。従って、第２の実施形態と同様に、リソース確保制御処理の際に、その時点で確保しておくべき総リソース量Ｒを少なくすることができる。従って、第２の実施形態と同様の効果も得られる。
なお、第３の実施形態に第２の実施形態を適用してもよい。すなわち、ステップＳ４２ａで、リソース予約情報、リソース開放予定情報およびリソース増設計画情報を日付順に並べ、リソース増設計画情報もステップＳ４３ａにおける選択対象に含めてもよい。そして、ステップＳ４３ａでリソース増設計画情報を選択した場合には、第２の実施形態におけるステップＳ４６と同様の処理を行えばよい。そして、ステップＳ４７ａでは、リソース予約情報、リソース開放予定情報、リソース増設計画情報のいずれかが未選択のまま残っているかを判定し、未選択の情報があれば、ステップＳ４３ａ以降の処理を繰り返せばよい。このように、リソース予約情報、リソース開放予定情報およびリソース増設計画情報を用いてＲを導出してもよい。
なお、上記の第１から第３までの各実施形態において、リソース確保制御処理におけるステップＳ２３において、リソースプール管理装置１１がリソースの確保を行わなくてもよい。ただし、その他の点に関しては、既に説明した動作と同様である。このように、リソースの確保を行わない場合、実際の利用開始日が来るまでの間、利用していないリソースを全て利用することができ、かつ、予約に対応するために必要なリソースの増設の要否を早い段階から知ることが可能になる。
次に、本発明の最小構成について説明する。図１５は、本発明のリソース管理システムの最小構成の例を示す説明図である。本発明のリソース管理システムは、リソース情報記憶手段７１と、確保量計算手段７２と、リソース管理手段７３と、制御手段７４とを備える。
リソース情報記憶手段７１（例えば、リソースＤＢ管理装置１２）は、利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶する。
確保量計算手段７２（例えば、確保量計算装置１４）は、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する。
リソース管理手段７３（例えば、リソースプール管理手段１１）は、リソースの確保を行う。
制御手段７４（例えば、リソースプロビジョニング装置１３）は、所定のタイミング毎に、確保量計算手段７２に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段７３に追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段７１に記憶された確保済みリソース量を更新する。
このような構成により、余計なリソースの確保を抑えつつ、予約をした利用者が、予約した量のリソースを、予定した利用開始時から利用できる確実性を高めることができる。
上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶するリソース情報記憶手段と、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算手段と、リソースの確保を行うリソース管理手段と、所定のタイミング毎に、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する制御手段とを備えることを特徴とするリソース管理システム。
（付記２）リソース不足の通知を出力する通知手段を備え、制御手段は、更新後の確保済みリソース量が、確保量計算手段に計算させた、現在時に確保しておくべきリソース量未満であることを条件に、通知手段に、リソース不足の通知を出力させる付記１に記載のリソース管理システム。
（付記３）制御手段は、いずれかのリソース予約情報に含まれる利用開始時から所定時間前の時点になったときに、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新し、更新後の確保済みリソース量が、前記確保しておくべきリソース量未満であることを条件に、リソース増設のための準備を開始する最終期限になった旨の通知を通知手段に出力させる付記２に記載のリソース管理システム。
（付記４）リソース情報記憶手段は、リソースの増設予定日および当該増設予定日に増設される増設リソース量の情報を含むリソース増設計画情報を記憶し、
確保量計算手段は、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース増設計画情報に含まれる増設予定日の情報と、前記各リソース増設計画情報に含まれる増設リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算する付記１から付記３のうちのいずれかに記載のリソース管理システム。
（付記５）リソース情報記憶手段は、払い出されているリソースの開放予定日および当該開放予定日に開放される開放リソース量の情報を含むリソース開放予定情報を記憶し、確保量計算手段は、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース開放予定情報に含まれる開放予定日の情報と、前記各リソース開放予定情報に含まれる開放リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算する付記１から付記４のうちのいずれかに記載のリソース管理システム。
（付記６）リソース情報記憶手段が、利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶し、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算手段に対して、制御手段が、所定のタイミング毎に、現在時に確保しておくべきリソース量、および追加確保量を計算させ、前記制御手段が、リソースの確保を行うリソース管理手段に対して、前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新することを特徴とするリソース管理方法。
（付記７）更新後の確保済みリソース量が、現在時に確保しておくべきリソース量未満であることを条件に、制御手段が、リソース不足の通知を出力する通知手段に対して前記通知を出力させる付記６に記載のリソース管理方法。
（付記８）制御手段が、いずれかのリソース予約情報に含まれる利用開始時から所定時間前の時点になったときに、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新し、更新後の確保済みリソース量が、前記確保しておくべきリソース量未満であることを条件に、リソース増設のための準備を開始する最終期限になった旨の通知を通知手段に出力させる付記７に記載のリソース管理方法。
（付記９）リソース情報記憶手段が、リソースの増設予定日および当該増設予定日に増設される増設リソース量の情報を含むリソース増設計画情報を記憶し、確保量計算手段が、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース増設計画情報に含まれる増設予定日の情報と、前記各リソース増設計画情報に含まれる増設リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算する付記６から付記８のうちのいずれかに記載のリソース管理方法。
（付記１０）リソース情報記憶手段が、払い出されているリソースの開放予定日および当該開放予定日に開放される開放リソース量の情報を含むリソース開放予定情報を記憶し、確保量計算手段は、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース開放予定情報に含まれる開放予定日の情報と、前記各リソース開放予定情報に含まれる開放リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算する付記６から付記９のうちのいずれかに記載のリソース管理方法。
（付記１１）利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶するリソース情報記憶手段を備えるコンピュータに搭載されるリソース管理プログラムであって、前記コンピュータに、所定のタイミング毎に、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算処理、
追加確保量分のリソースの確保を行うリソース管理処理、および、前記リソース管理処理で確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する更新処理を実行させるためのリソース管理プログラム。
（付記１２）コンピュータに、更新処理における更新後の確保済みリソース量が、確保量計算処理で計算された、現在時に確保しておくべきリソース量未満であることを条件に、リソース不足の通知を出力する通知処理を実行させる付記１１に記載のリソース管理プログラム。
（付記１３）コンピュータに、いずれかのリソース予約情報に含まれる利用開始時から所定時間前の時点になったときに確保量計算処理、リソース管理処理および更新処理を実行させ、通知処理で、更新処理における更新後の確保済みリソース量が、確保量計算処理で計算された、現在時に確保しておくべきリソース量未満であることを条件に、リソース増設のための準備を開始する最終期限になった旨の通知を出力させる付記１２に記載のリソース管理プログラム。
（付記１４）リソースの増設予定日および当該増設予定日に増設される増設リソース量の情報を含むリソース増設計画情報を記憶するリソース情報記憶手段を備えたコンピュータに、確保量計算処理で、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース増設計画情報に含まれる増設予定日の情報と、前記各リソース増設計画情報に含まれる増設リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算させる付記１１から付記１３のうちのいずれかに記載のリソース管理プログラム。
（付記１５）払い出されているリソースの開放予定日および当該開放予定日に開放される開放リソース量の情報を含むリソース開放予定情報を記憶するリソース情報記憶手段を備えたコンピュータに、確保量計算処理で、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース開放予定情報に含まれる開放予定日の情報と、前記各リソース開放予定情報に含まれる開放リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算させる付記１１から付記１４のうちのいずれかに記載のリソース管理プログラム。
本発明は、予約されたリソースを管理するリソース管理システムに好適に適用可能である。
１０ リソースプール
１１ リソースプール管理装置
１２，１２ｂ リソースデータベース管理装置（リソースＤＢ管理装置）
１３ リソースプロビジョニング装置
１４，１４ａ，１４ｂ 確保量計算装置
１５ 通知装置
１７ 端末装置

Claims (10)

  1. 利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶するリソース情報記憶手段と、
    現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算手段と、
    リソースの確保を行うリソース管理手段と、
    所定のタイミング毎に、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する制御手段とを備える
    ことを特徴とするリソース管理システム。
  2. リソース不足の通知を出力する通知手段を備え、
    制御手段は、更新後の確保済みリソース量が、確保量計算手段に計算させた、現在時に確保しておくべきリソース量未満であることを条件に、通知手段に、リソース不足の通知を出力させる
    請求項１に記載のリソース管理システム。
  3. 制御手段は、いずれかのリソース予約情報に含まれる利用開始時から所定時間前の時点になったときに、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新し、更新後の確保済みリソース量が、前記確保しておくべきリソース量未満であることを条件に、リソース増設のための準備を開始する最終期限になった旨の通知を通知手段に出力させる
    請求項２に記載のリソース管理システム。
  4. リソース情報記憶手段は、リソースの増設予定日および当該増設予定日に増設される増設リソース量の情報を含むリソース増設計画情報を記憶し、
    確保量計算手段は、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース増設計画情報に含まれる増設予定日の情報と、前記各リソース増設計画情報に含まれる増設リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算する
    請求項１から請求項３のうちのいずれか１項に記載のリソース管理システム。
  5. リソース情報記憶手段は、払い出されているリソースの開放予定日および当該開放予定日に開放される開放リソース量の情報を含むリソース開放予定情報を記憶し、
    確保量計算手段は、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに加えて、各リソース開放予定情報に含まれる開放予定日の情報と、前記各リソース開放予定情報に含まれる開放リソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算する
    請求項１から請求項４のうちのいずれか１項に記載のリソース管理システム。
  6. リソース情報記憶手段が、利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶し、
    現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算手段に対して、制御手段が、所定のタイミング毎に、現在時に確保しておくべきリソース量、および追加確保量を計算させ、
    前記制御手段が、リソースの確保を行うリソース管理手段に対して、前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する
    ことを特徴とするリソース管理方法。
  7. 更新後の確保済みリソース量が、現在時に確保しておくべきリソース量未満であることを条件に、制御手段が、リソース不足の通知を出力する通知手段に対して前記通知を出力させる
    請求項６に記載のリソース管理方法。
  8. 制御手段が、いずれかのリソース予約情報に含まれる利用開始時から所定時間前の時点になったときに、確保量計算手段に現在時に確保しておくべきリソース量、および追加確保量を計算させ、リソース管理手段に前記追加確保量分のリソースの確保を要求し、確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新し、更新後の確保済みリソース量が、前記確保しておくべきリソース量未満であることを条件に、リソース増設のための準備を開始する最終期限になった旨の通知を通知手段に出力させる
    請求項７に記載のリソース管理方法。
  9. 利用者に予約されたリソース量および当該利用者がリソースの利用を開始する利用開始時の情報を含むリソース予約情報と、利用開始時に払い出せるように確保した確保済みリソース量とを記憶するリソース情報記憶手段を備えるコンピュータに搭載されるリソース管理プログラムであって、
    前記コンピュータに、
    所定のタイミング毎に、現在時と、予約毎に定められた各リソース予約情報に含まれる利用開始時の情報と、前記各リソース予約情報に含まれる予約されたリソース量の情報とに基づいて、現在時に確保しておくべきリソース量を計算し、当該リソース量から確保済みリソース量を減算することにより新たに追加して確保すべきリソース量である追加確保量を計算する確保量計算処理、
    追加確保量分のリソースの確保を行うリソース管理処理、および、
    前記リソース管理処理で確保されたリソース量に基づいて、リソース情報記憶手段に記憶された確保済みリソース量を更新する更新処理
    を実行させるためのリソース管理プログラム。
  10. コンピュータに、
    更新処理における更新後の確保済みリソース量が、確保量計算処理で計算された、現在時に確保しておくべきリソース量未満であることを条件に、リソース不足の通知を出力する通知処理
    を実行させる請求項９に記載のリソース管理プログラム。
JP2011044952A 2011-03-02 2011-03-02 リソース管理システム、リソース管理方法およびリソース管理プログラム Expired - Fee Related JP5626023B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011044952A JP5626023B2 (ja) 2011-03-02 2011-03-02 リソース管理システム、リソース管理方法およびリソース管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011044952A JP5626023B2 (ja) 2011-03-02 2011-03-02 リソース管理システム、リソース管理方法およびリソース管理プログラム

Publications (2)

Publication Number Publication Date
JP2012181730A JP2012181730A (ja) 2012-09-20
JP5626023B2 true JP5626023B2 (ja) 2014-11-19

Family

ID=47012866

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011044952A Expired - Fee Related JP5626023B2 (ja) 2011-03-02 2011-03-02 リソース管理システム、リソース管理方法およびリソース管理プログラム

Country Status (1)

Country Link
JP (1) JP5626023B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9852769B2 (en) 2013-05-20 2017-12-26 Intel Corporation Elastic cloud video editing and multimedia search
JP6829670B2 (ja) * 2017-08-22 2021-02-10 日本電信電話株式会社 リソース管理サーバ、および、リソース管理方法
CN112015542A (zh) * 2019-05-29 2020-12-01 潘仲光 资源收集方法、设备及存储介质
WO2021235312A1 (ja) * 2020-05-20 2021-11-25 ソニーグループ株式会社 情報処理装置及び情報処理方法
JP7340663B1 (ja) 2022-07-13 2023-09-07 株式会社三菱Ｕｆｊ銀行 リソース申請システム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5417287B2 (ja) * 2010-09-06 2014-02-12 株式会社日立製作所 計算機システム、及び、計算機システムの制御方法

Also Published As

Publication number Publication date
JP2012181730A (ja) 2012-09-20

Similar Documents

Publication Publication Date Title
JP5626023B2 (ja) リソース管理システム、リソース管理方法およびリソース管理プログラム
JP5016125B1 (ja) 情報提供装置、情報提供方法、情報提供プログラム及び記録媒体
JP5949145B2 (ja) 会議室予約プログラム及び会議室予約装置
US20130332207A1 (en) System and method for intelligent management of appointment waiting list
JP5714983B2 (ja) 管理装置
JP2014127118A (ja) 予約業務支援サーバ、予約業務支援プログラム及び予約業務の支援方法
JP7455530B2 (ja) レンタル機材管理システム及びレンタル機材管理方法
JP5921157B2 (ja) バスの座席予約システム
JP2001067413A (ja) スケジュール生成装置および方法並びにこれを用いたスケジュール生成システム
CN110706056B (zh) 服务能力的智能控量方法
JP2009140384A (ja) ポイント利用予約管理方法、および、ポイント管理サーバ
JP2005284898A (ja) 座席予約方法及び座席予約システム
JP4785491B2 (ja) 供給計画管理方法および供給計画管理プログラム
JP6173803B2 (ja) 発注量計算システム
JP6535294B2 (ja) ジョブスケジュール変更システム及びジョブスケジュール変更方法
CN112926763A (zh) 支付申请的排程方法、装置、存储介质及服务器
JP6938883B2 (ja) 制御プログラム、装置、及び方法
JP5035048B2 (ja) 工事予約装置、工事予約処理方法及びプログラム
WO2023136011A1 (ja) 車両予約管理装置、車両予約管理方法および車両予約管理プログラム
JP2013134582A (ja) 予約及び受付管理プログラム
JP4090981B2 (ja) 交通ダイヤ管理装置
JP7367483B2 (ja) 電子決裁方法、電子決裁装置
US20230068901A1 (en) Advanced available-to-promise supply creation-based confirmation
JP5485955B2 (ja) 就労マッチング装置
JP2023102197A (ja) 方法及びシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140205

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140820

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140902

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140915

R150 Certificate of patent or registration of utility model

Ref document number: 5626023

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees