(57)【要約】      （修正有）【課題】リソースを確実に融通させることができる情報処理装置、リソーススケジュール方法およびリソーススケジュールプログラムを提供する。【解決手段】少なくとも、リソースの使用期間と使用状態と譲渡条件とを含む要求を、融通元ユーザおよび融通先ユーザから受信する受信部１０４と、融通前使用状態と融通後使用状態と算出条件とを対応付けて記憶する作業工程記憶部と、算出条件に対応付けて作業時間の算出式を記憶する作業時間算出式記憶部と、融通元ユーザから受信した要求の譲渡条件にリソースを融通させる旨が示されているか否かを判定し、算出条件に対応する算出式とに基づいて算出した作業時間と融通元ユーザの使用期間と融通先ユーザの使用期間とに基づいて、融通先ユーザが融通元ユーザから融通を受けて使用可能なリソースの量を算出する融通案作成部１０５と、算出した量のリソースを融通先ユーザに融通させる融通管理部１０６と、を備える。【選択図】図１
2011123812.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも、リソースの使用期間と、前記リソースが使用される環境を示す使用状態と、融通元ユーザから融通先ユーザへの前記リソースの融通の可否を示す譲渡条件とを含む要求を、前記融通元ユーザおよび前記融通先ユーザから受信する受信部と、
前記融通元ユーザの前記リソースの使用状態である融通前使用状態と、前記融通先ユーザの前記リソースの使用状態である融通後使用状態と、前記融通前使用状態から前記融通後使用状態に移行するための作業時間を算出する算出条件とを対応付けて記憶する作業工程記憶部と、
前記算出条件に対応付けて前記作業時間の算出式を記憶する作業時間算出式記憶部と、
前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースを融通させる旨が示されているか否かを判定し、前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースの融通させる旨が示されていると判定した場合、前記融通元ユーザから受信した前記要求に含まれる前記使用状態に一致する前記融通前使用状態および前記融通先ユーザから受信した前記要求に含まれる前記使用状態に一致する前記融通後使用状態を特定し、特定した前記融通前使用状態および前記融通後使用状態に対応する前記算出条件と前記算出条件に対応する前記算出式とに基づいて前記作業時間を算出し、算出した前記作業時間と前記融通元ユーザの前記要求に含まれる前記使用期間と前記融通先ユーザの前記要求に含まれる前記使用期間とに基づいて、前記融通先ユーザが前記融通元ユーザから融通を受けて使用可能な前記リソースの量を算出する融通案作成部と、
前記融通案作成部が算出した量の前記リソースを前記融通元ユーザから前記融通先ユーザに融通させる融通管理部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記受信部は、さらに、前記融通先ユーザが必要とする前記リソースの量を含む前記要求を前記融通先ユーザから受信し、前記融通元ユーザから融通される前記リソースの量が、前記融通先ユーザが必要とする前記リソースの量を満たすか否かを判定し、前記融通元ユーザから融通される前記リソースの量が、前記融通先ユーザが必要とする前記リソースの量を満たすと判定した場合であって、前記融通先ユーザから受信した前記要求の前記譲渡条件に前記リソースの融通させる旨が示されていると判定した場合にのみ、前記融通先ユーザを新たな融通元ユーザに設定する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信部は、前記融通元ユーザから融通される前記リソースの量が、前記融通先ユーザが必要とする前記リソースの量を満たさないと判定した場合に、前記融通先ユーザを前記融通元ユーザまたは前記新たな融通元ユーザから前記リソースの融通を受けることを待つ待ち融通先ユーザに設定する、
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記融通案作成部は、前記受信部が設定した、前記新たな融通元ユーザの前記要求に含まれる前記使用期間と、前記待ち融通先ユーザの前記要求に含まれる前記使用期間とが重複しているか否かを判定し、前記新たな融通元ユーザの前記要求に含まれる前記使用期間と前記待ち融通先ユーザの前記要求に含まれる前記使用期間とが重複していないと判定した場合に、前記待ち融通先ユーザを設定する、
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記作業工程記憶部は、さらに、前記融通前使用状態から前記融通後使用状態に移行するための複数の作業内容を、前記融通前使用状態と前記融通後使用状態と前記算出条件とに対応付けて記憶し、
前記融通案作成部は、前記複数の作業内容の中から、前記待ち融通先ユーザの前記要求に含まれる前記使用状態から前記新たな融通元ユーザの前記要求に含まれる前記使用状態に移行するための作業内容を特定し、前記融通前使用状態と前記融通後使用状態と特定した作業内容に対応する前記算出条件に対応する前記算出式とに基づいて、特定した前記作業内容ごとの内容作業時間を算出し、算出した前記内容作業時間を累積することにより、前記作業時間を算出する、
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記作業工程記憶部は、さらに、前記作業内容と前記融通先ユーザが融通を受ける前記リソースの単位である単位リソースとを対応付けて記憶し、
前記融通案作成部は、算出した前記内容作業時間を前記単位リソースごとに累積した単位リソース作業時間を算出することによって、前記単位リソースごとの前記作業時間を算出する、
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記融通案作成部は、前記単位リソース作業時間を算出した場合において、最も長い前記単位リソース作業時間を前記作業時間とする、
ことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記受信部は、さらに、外部から前記作業時間の実績を示す実績作業時間を受信し、
前記融通案作成部は、算出した前記作業時間と前記受信部が受信した前記実績作業時間との差分を求める、
ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
【請求項９】
前記融通管理部は、前記リソースを前記融通元ユーザから前記融通先ユーザに融通させる場合に、前記融通元ユーザに対して、前記融通先ユーザへの前記リソースの融通の許諾を求める旨を送信する、
ことを特徴とする請求項１〜８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記融通管理部は、前記リソースの融通の許諾を求める旨とともに、前記融通案作成部が算出した前記作業時間が、現在時刻から前記融通元ユーザの前記要求に含まれる前記使用期間内であるか否かを判定し、前記融通案作成部が算出した前記作業時間が、現在時刻から前記融通元ユーザの前記要求に含まれる前記使用期間内であると判定した場合、前記融通元ユーザの前記要求に含まれる前記使用期間と前記現在時刻に前記作業時間を加えた時間との差分期間を算出し、前記現在時刻に前記差分期間を経過するまでの期間である有効期間を送信する、
ことを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
融通元ユーザがリソースを使用する状態である融通前使用状態と、融通先ユーザがリソースを使用する状態である融通後使用状態と、前記融通前使用状態から前記融通後使用状態に移行するための作業時間を算出する算出条件とを対応付けて記憶する作業工程記憶部と、前記算出条件に対応付けて前記作業時間の算出式を記憶する作業時間算出式記憶部と、を備えた情報処理装置で実行されるリソーススケジュール方法であって、
少なくとも、前記リソースの使用期間と、前記リソースが使用される環境を示す使用状態と、融通元ユーザから融通先ユーザへの前記リソースの融通の可否を示す譲渡条件とを含む要求を、前記融通元ユーザおよび前記融通先ユーザから受信する受信ステップと、
前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースを融通させる旨が示されているか否かを判定し、前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースの融通させる旨が示されていると判定した場合、前記融通元ユーザから受信した前記要求に含まれる前記使用状態に一致する前記融通前使用状態および前記融通先ユーザから受信した前記要求に含まれる前記使用状態に一致する前記融通後使用状態を特定し、特定した前記融通前使用状態および前記融通後使用状態に対応する前記算出条件と前記算出条件に対応する前記算出式とに基づいて前記作業時間を算出し、算出した前記作業時間と前記融通元ユーザの前記要求に含まれる前記使用期間と前記融通先ユーザの前記要求に含まれる前記使用期間とに基づいて、前記融通先ユーザが前記融通元ユーザから融通を受けて使用可能な前記リソースの量を算出する融通案作成ステップと、
前記融通案作成部が算出した量の前記リソースを前記融通元ユーザから前記融通先ユーザに融通させる融通管理ステップと、
を含むことを特徴とするリソーススケジュール方法。
【請求項１２】
コンピュータに、
少なくとも、リソースの使用期間と、前記リソースが使用される環境を示す使用状態と、融通元ユーザから融通先ユーザへの前記リソースの融通の可否を示す譲渡条件とを含む要求を、前記融通元ユーザおよび前記融通先ユーザから受信する受信ステップと、
前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースを融通させる旨が示されているか否かを判定し、前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースの融通させる旨が示されていると判定した場合、前記融通元ユーザから受信した前記要求に含まれる前記使用状態に一致する融通元ユーザがリソースを使用する状態である融通前使用状態および前記融通先ユーザから受信した前記要求に含まれる前記使用状態に一致する融通先ユーザがリソースを使用する状態である融通後使用状態を特定し、特定した前記融通前使用状態および前記融通後使用状態に対応する前記融通前使用状態および前記融通後使用状態と、前記融通前使用状態から前記融通後使用状態に移行するための作業時間を算出する算出条件と前記算出条件に対応付けられた前記作業時間の算出式とに基づいて前記作業時間を算出し、算出した前記作業時間と前記融通元ユーザの前記要求に含まれる前記使用期間と前記融通先ユーザの前記要求に含まれる前記使用期間とに基づいて、前記融通先ユーザが前記融通元ユーザから融通を受けて使用可能な前記リソースの量を算出する融通案作成ステップと、
前記融通案作成部が算出した量の前記リソースを前記融通元ユーザから前記融通先ユーザに融通させる融通管理ステップと、
を実行させることを特徴とするリソーススケジュールプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータが使用するサーバやストレージ等のリソースを管理する情報処理装置、リソーススケジュール方法およびリソーススケジュールプログラムに関する。
【背景技術】
【０００２】
一般に、サーバやディスク等のリソースを有するシステムをユーザが利用する場合、これらのリソースは、通常そのユーザによって占有される。しかし、タイミングによっては、リソースが一度占有されたものの、ある期間利用されず、その後再び利用される場合もあり、必ずしもリソースが常時占有されるとは限らない。従って、そのリソースが利用されない間に他のユーザから要求があった場合には、そのリソースの利用を許容して、効率的にリソースを配分することが望ましい。
【０００３】
近年、プライベートクラウドという新しい計算機システムが注目されている。プライベートクラウドでは、クラウド内の共有されたリソースにアクセスすることによって、個々の計算機のリソースの性能を超えた情報処理を可能とする。ユーザは、クラウド内のリソースを共有することができるため、計算機システムの全体のリソースが効率的に利用され、その運用コストの削減が可能となる。
【０００４】
ところで、リソースの利用率を向上するための一つの技術に、仮想化技術がある。仮想化技術では、ＰＣ等の計算機の内部に仮想の計算機を構築することによって、物理的には１つの計算機であっても、複数の論理的な計算機として、種々の処理を同時に実行可能としている。このため、そのような計算機を複数有したシステム全体から見た場合、物理的な計算機の数を減らすことができ、システム全体のリソースの利用率を高め、コストを削減できる（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２１７３０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
プライベートクラウドでは、ユーザ数が多ければ多いほど、計算機のリソースの利用率が向上する。しかし、より多くのユーザ数を確保するために、プライベートクラウド内のリソースをスケジュールする場合に以下の課題が存在する。
【０００７】
すなわち、従来は、クラウド内の全ての計算機のリソースが使用中である場合、新たなユーザが緊急に予約要求を行っても、その予約要求をキャンセルしていた。図２７は、従来のリソーススケジュールシステムが、予約要求をキャンセルする様子を示す図である。
【０００８】
図２７に示すように、プライベートクラウド内のある貸出リソースを利用するために、ユーザＡが、既に貸出リソースとして登録されている「サーバ」を予約していた場合を考える。ユーザＡは、７／３０の９：００に利用を再開できるのであれば、それまでは他のユーザに利用させてもよいと考えている場合、新規ユーザＢが、「３日間だけサーバを融通してほしい」と、プライベートクラウド内のリソーススケジュールシステムにその要求を行った場合であっても、新規ユーザＢが予約した時点では「サーバ」は予約済みであるため、その予約要求はキャンセルされてしまい、効率的にリソースが利用されていない。
【０００９】
このような場合、より効率的にリソースを利用するためには、プライベートクラウド内のリソースを利用中のユーザの中で融通可能なユーザを空いている時間帯へ移動させ、新規ユーザからの予約要求を受け付けて、リソースをその新規ユーザに融通する必要がある。ところが、既にリソースを利用しているユーザから見た場合、一旦他のユーザにリソースを利用させると、必ずしも融通を許可した期間内にリソースの利用を再開できるとは限らなかった。
【００１０】
その理由は、リソースが計算機場合、その再起動やＣＰＵ割当の変更といった保守作業が、他の計算機の利用状況との関係で不確定となるためである。すなわち、融通させる計算機のリソースが物理サーバとして利用されているのか、または仮想サーバとして利用されているのか、あるいは融通させる計算機のＣＰＵやメモリ容量の空きリソースの容量がどの程度あるのか等によって、ＣＰＵの確保やメモリの開放等の所要時間が異なってくるためである。
【００１１】
このように、元のユーザが計算機の利用を再開できない場合が生じると、プライベートクラウドの利用率が低下し、その結果、計算機のリソースを効率的に利用することが出来なくなってしまう。したがって、プライベートクラウドにおいて、計算機のリソースを効率的に利用するためには、上述した作業時間の正確な見積もりが必須となる。
【００１２】
この点、特許文献１では、仮想化ソフトウエア（ＶＭＭ：Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｍｏｎｉｔｏｒ）のバージョンを考慮して仮想マシンのコンバートにかかる時間求め、ユーザにとって最適な仮想サーバを融通させている。しかし、「ＣＰＵの割当変更」など、上述した作業時間を考慮したものではなく、融通を許可した期間を確実に保証できない、すなわち、リソースを確実に融通させることができないという問題があった。
【００１３】
本発明は、上記に鑑みてなされたものであって、リソースを確実に融通させることができる情報処理装置、リソーススケジュール方法およびリソーススケジュールプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上述した目的を達成するために、本発明にかかる情報処理装置は、少なくとも、リソースの使用期間と、前記リソースが使用される環境を示す使用状態と、融通元ユーザから融通先ユーザへの前記リソースの融通の可否を示す譲渡条件とを含む要求を、前記融通元ユーザおよび前記融通先ユーザから受信する受信部と、前記融通元ユーザの前記リソースの使用状態である融通前使用状態と、前記融通先ユーザの前記リソースの使用状態である融通後使用状態と、前記融通前使用状態から前記融通後使用状態に移行するための作業時間を算出する算出条件とを対応付けて記憶する作業工程記憶部と、前記算出条件に対応付けて前記作業時間の算出式を記憶する作業時間算出式記憶部と、前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースを融通させる旨が示されているか否かを判定し、前記融通元ユーザから受信した前記要求の前記譲渡条件に前記リソースの融通させる旨が示されていると判定した場合、前記融通元ユーザから受信した前記要求に含まれる前記使用状態に一致する前記融通前使用状態および前記融通先ユーザから受信した前記要求に含まれる前記使用状態に一致する前記融通後使用状態を特定し、特定した前記融通前使用状態および前記融通後使用状態に対応する前記算出条件と前記算出条件に対応する前記算出式とに基づいて前記作業時間を算出し、算出した前記作業時間と前記融通元ユーザの前記要求に含まれる前記使用期間と前記融通先ユーザの前記要求に含まれる前記使用期間とに基づいて、前記融通先ユーザが前記融通元ユーザから融通を受けて使用可能な前記リソースの量を算出する融通案作成部と、前記融通案作成部が算出した量の前記リソースを前記融通元ユーザから前記融通先ユーザに融通させる融通管理部と、を備えることを特徴とする。
【００１５】
また、本発明は、上記情報処理装置で実行されるリソーススケジュール方法およびリソーススケジュールプログラムである。
【発明の効果】
【００１６】
本発明によれば、リソースを確実に融通させることができる情報処理装置、リソーススケジュール方法、リソーススケジュールプログラムを提供することができる。
【図面の簡単な説明】
【００１７】
【図１】第１の実施の形態におけるリソーススケジュールシステムの構成を示すブロック図である。
【図２】第１の実施の形態における予約要求の例を示す図である。
【図３】第１の実施の形態における使用権限譲渡条件リストの例を示す図である。
【図４】第１の実施の形態における使用権限譲渡要求リストの例を示す図である。
【図５】第１の実施の形態における使用状態変更作業時間算出式リストの例を示す図である。
【図６】第１の実施の形態における使用状態変更作業工程リストの例を示す図である。
【図７】第１の実施の形態におけるリソースリストの例を示す図である。
【図８】第１の実施の形態における使用権限予約リストの例を示す図である。
【図９】第１の実施の形態における融通案作成開始フラグの例を示す図である。
【図１０】第１の実施の形態における融通元融通先候補リストの例を示す図である。
【図１１】第１の実施の形態における融通作業候補リストの例を示す図である。
【図１２】第１の実施の形態における使用可能リソースクラスリストの例を示す図である。
【図１３】融通案作成適用処理の処理手順を示すフローチャートである。
【図１４】図１３に示したイベント受信処理の処理手順を示すフローチャートである。
【図１５】第１の実施の形態の融通案作成処理の処理手順を示すフローチャートである。
【図１６】図１５に示した融通元融通先候補リスト作成処理の処理手順を示すフローチャートである。
【図１７】図１５に示した使用状態変更作業候補リスト作成処理の処理手順を示すフローチャートである。
【図１８】使用状態変更作業時間処理の処理手順を示すフローチャートである。
【図１９】トータル使用状態変更作業時間処理の処理手順を示すフローチャートである。
【図２０】融通案リストの例を示す図である。
【図２１】融通元ユーザのリソースの再開時刻を保証できなくなる場合の様子を示す図である。
【図２２】第２の実施の形態におけるリソーススケジュールシステムの構成を示すブロック図である。
【図２３】使用状態変更作業時間実績情報の例を示す図である。
【図２４】使用状態変更作業時間算出式リスト更新処理の処理手順を示すフローチャートである。
【図２５】融通案リストの変形例を示す図である。
【図２６】承認要求に対して拒絶する旨の例を示す図である。
【図２７】従来のリソーススケジュールシステムが、予約要求をキャンセルする様子を示す図である。
【発明を実施するための形態】
【００１８】
以下に添付図面を参照して、この発明にかかる情報処理装置、リソーススケジュール方法、リソーススケジュールプログラムの実施の形態を詳細に説明するが、本発明はこれらの実施の形態に限定されるものではない。
【００１９】
（第１の実施の形態）
図１は、本実施の形態におけるリソーススケジュールシステム１０００の構成を示すブロック図である。図１に示すように、リソースのスケジュールを管理するＰＣ１００と、物理サーバ１２１Ａと、物理サーバ１２１Ｂと、ネットワーク機器１２２と、ストレージ機器１２３と、ユーザ端末１３０Ａ、ユーザ端末１３０Ｂと、管理端末１４０とを含んで構成されている。
【００２０】
なお、以下の説明では、物理サーバ１２１Ａおよび物理サーバ１２１Ｂを、単に物理サーバ１２１と呼び、ユーザ端末１３０Ａおよびユーザ端末１３０Ｂを、単にユーザ端末１３０と呼び、ユーザ１３１Ａおよびユーザ１３１Ｂを、単にユーザ１２１と呼ぶこともある。また、以下では、物理サーバ１２１が２台、ネットワーク機器１２２が１台、ストレージ機器１２３が１台であるとして説明しているが、これらの台数に限られることはない。
【００２１】
ＰＣ１００は、プロセッサ１０１と、メモリ１０２と、ユーザ端末にネットワーク経由で接続されるネットワークインターフェイスカード（ＮＩＣ）１０３とを含んで構成されている。また、ＰＣ１００は、ネットワークを介してユーザ端末１３０Ａと、ユーザ端末１３１Ｂと、管理端末１４０とに接続される。なお、以下の説明では、ユーザ端末は２台であるとして説明しているが、上述した機器と同様、これらの台数に限られることはない。
【００２２】
各物理サーバ１２１は、不図示のＮＩＣ等の通信装置を介してユーザ端末１３０に接続し後述する各種の情報を送受信する。また、物理サーバ１２１は、プロセッサ１２４が、ストレージ機器１２３の中から、後述する各種の処理を行うためのプログラムを含むユーザデータ１２６Ａ及びユーザデータ１２６Ｂをメモリ１２５にロードすることによって、後述する各種の処理を実行することができるようになっている。
【００２３】
ネットワーク機器１２２は、物理サーバ１２１及びストレージ機器１２３と接続されており、必要に応じてユーザデータ１２６Ａ及びユーザデータ１２６Ｂの参照や更新に必要な通信情報を転送する。
【００２４】
ストレージ機器１２３は、ユーザデータ１２６Ａ及びユーザデータ１２６Ｂを記憶する。物理サーバ１２１Ａ及び物理サーバ１２１Ｂは、ネットワークを介して、これらのデータを参照や更新を行う。
【００２５】
図１に示すように、本実施の形態におけるリソーススケジュールシステム１０００では、物理サーバ１２１、ネットワーク機器１２２及びストレージ機器１２３が計算機リソースとして含まれているが、これらに代えて、ＰＣなどの簡易な計算機が１台以上含まれるように構成してもよい。
【００２６】
ユーザ端末１３０は、ユーザ１３１が他のユーザ１３１からリソースを融通してもらうための要求（以下、予約要求と呼ぶ。）を含む入力情報１３２Ａ及び入力情報１３２Ｂを受け付け、ネットワークを介して予約要求１３３を送信する。なお、予約要求１３３の詳細については、図２を用いて後述する。
【００２７】
ここで、融通とは、物理サーバ１２１やストレージ機器１２３等のリソースに対して再起動等を行って、リソースが使用される環境を、ある状態から別の状態に移行するための作業（以下、使用状態変更作業と呼ぶ。）を実施し、そのリソースの使用権限を、使用中であった元のユーザから新たなユーザに移すことである。
【００２８】
管理端末１４０は、管理者１４１から、ＰＣ１００や物理サーバ１２１等をメンテナンスするための各種の管理情報１４２の入力を受け付ける。管理端末１４０は、受け付けられた管理情報に従って、ＰＣ１００や物理サーバ１２４Ａ等の各装置に対するメンテナンスを行う。
【００２９】
ディスク記憶媒体１５０及び磁気記憶媒体１５１は、メモリ１０２に記憶されるプログラム及びデータを格納する。ＰＣ１００のプロセッサ１０１は、これらのディスク記憶媒体１５０及び磁気記憶媒体１５１に記憶されたプログラムを呼び出して、メモリ１０２上にロードすることによって、ＰＣ１００は、後述する各種の処理を実行することができるようになっている。
【００３０】
メモリ１０２は、例えば、ＲＡＭ（Random  Access  Memory）であり、プロセッサ１０１によって実行されるプログラム及びデータを記憶する。具体的には、イベント受信処理部１０４、融通管理部１０５、融通案作成部１０６、使用権限譲渡条件リスト１０７、使用権限譲渡要求リスト１０８、使用状態変更作業時間算出リスト１０９、使用状態変更作業工程リスト１１０、リソースリスト１１１、使用権限予約リスト１１２、融通案作成開始フラグ１１３、融通元融通先候補リスト１１４、融通作業候補リスト１１５及び使用可能リソースクラスリスト１１６が記憶される。
【００３１】
イベント受信処理部１０４は、ＮＩＣ１０３を介して予約要求１３３を受信する。具体的には、イベント受信処理部１０４は、ユーザ端末１３２から送信された予約要求をＮＩＣ１０３が受信すると、受信した予約要求１３３をＮＩＣ１０３から受け取る。なお、イベント受信処理部１０４は、ユーザ端末１３２Ａ等から、予約要求１３３以外の種々のデータを受信しており、予約要求１３３やこれらの種々のデータのことを単にイベントと呼ぶこともある。
【００３２】
融通案作成部１０５は、イベント受信処理部１０４が予約要求１３３を受取った場合に、その予約要求された要求を満たすための融通案を作成するものである。融通案作成部１０５は、使用状態変更作業時間算出部１１６を含み、必要時にこれを呼び出して起動する。融通案作成部１０５、および使用状態変更作業時間算出部１１６が行う具体的な処理については、フローチャートを用いて後述する。
【００３３】
使用権限譲渡条件リスト１０７は、予約要求されたリソースの使用権限を譲渡するための条件を格納している。使用権限譲渡条件リスト１０７には、予約要求１３３によって融通が確定したユーザに関する種々の条件が格納されているが、これらの具体的な内容については、図３を用いて後述する。
【００３４】
使用権限譲渡要求リスト１０８は、予約要求によって融通が確定せず、別のユーザの使用権限が譲渡されることを待つユーザに関する情報を格納している。使用権限譲渡要求リスト１０８は、イベント受信処理部１０４が受け取った予約要求１３３のうち、使用権限譲渡条件リスト１０７に格納されていない予約要求１３３を格納する。融通要求リスト１０８の具体的な内容については、図４を用いて後述する。
【００３５】
使用状態変更作業時間算出式リスト１０９は、予約要求にしたがってリソースを融通させる際に生じる使用状態変更作業に要する時間（以下、使用状態変更作業時間と呼ぶ。）を算出するための式を格納する。使用状態変更作業時間算出式リスト１０９の具体的な内容については、図５を用いて後述する。
【００３６】
使用状態変更作業工程リスト１１０は、予約要求された場合において、リソースをどのような手順で融通させるかを示す融通方式を格納する。使用状態変更作業工程リスト１１０については、の具体的な内容については、図６を用いて後述する。
【００３７】
リソースリスト１１１は、リソースが予約要求された場合の期間に関する情報を格納する。リソースリスト１１１の具体的な内容については、図７を用いて後述する。
【００３８】
使用権限予約リスト１１２は、予約要求されたリソースの融通が確定したされたリソースに関する情報を格納する。使用権限予約リスト１１２の具体的な内容については、図８を用いて後述する。
【００３９】
融通案作成開始フラグ１１３は、融通案作成部１０５が、後述する融通案作成処理を開始するか否かの情報を格納する。イベント受信処理部１０４が後述するイベント受信処理を行った場合に、融通案作成開始フラグ１１３の値が更新される。融通案作成部１０５が行う具体的な処理については、図１５以降の各図面を用いて後述する。
【００４０】
融通元融通先候補リスト１１４は、予約要求されたリソースの融通が確定した場合におけるリソースの融通元及び融通先に関する情報を格納する。融通元融通先候補リスト１１４の具体的な内容については、図１０を用いて後述する。
【００４１】
使用状態変更作業候補リスト１１５は、融通案作成部１０５が、後述する融通案作成処理を実施する際に、予約要求されたリソースが融通された場合に生じる使用状態変更作業に関する情報を格納する。融通作業候補リスト１１５の具体的な内容については、図１１を用いて後述する。
【００４２】
使用可能リソースクラスリスト１１６は、融通案作成部１０５が、後述する融通案作成処理を行う際に、予約要求されたリソースの融通が可能か否かを判定するための情報を格納する。使用可能リソースクラスリスト１１６の具体的な内容については、図１２を用いて後述する。
【００４３】
続いて、図１に示した使用権限譲渡条件リスト１０７、融通要求リスト１０８、使用状態変更作業時間算出式リスト１０９、使用状態変更作業工程リスト１１０、リソースリスト１１１、使用権限予約リスト１１２、融通案作成開始フラグ１１３、融通元融通先候補リスト１１４、使用状態変更作業候補リスト１１５及び使用可能リソースクラスリスト１１６の各データの具体的な内容について、図２〜図１２を参照しながら説明する。
【００４４】
図２は、本実施の形態における予約要求１３３の例を示す図である。図２に示すように、予約要求１３３は、予約要求番号２０１と、ユーザ名２０２と、開始時刻２０３と、期間２０４と、使用状態２０５と、リソース量２０６と、使用権限譲渡条件２０７とを含んでいる。
【００４５】
予約要求番号２０１は、予約要求１３３を一意に特定するものである。また、ユーザ名２０２は、予約要求したユーザを一意に特定するものである。具体的には、ユーザ名２０２は、ユーザ端末１３０を利用するユーザ１３１のＩＤ（IDentifier）である。なお、ユーザ名２０２に保持する内容としては、「Ｕｓｅｒ１」のようなＩＤに代えて具体的なユーザの名前を用いてもよい。
【００４６】
開始時刻２０３は、予約要求したユーザ１３１が他のユーザ１３１からリソースを融通してもらう場合の始期である。期間２０４は、予約要求１３３を行ったユーザ１３１がリソースの融通を希望する期間である。使用状態２０５は、ユーザ１３１が融通を希望するリソースを、どのような状態で利用するのかについての情報（使用状態情報）を示すものである。例えば、使用状態情報として、あるサーバを仮想サーバとして利用する場合には「仮想サーバ」、あるいはあるサーバを物理サーバとして利用する場合には「物理サーバ」等の値が格納されている。
【００４７】
リソース量２０６は、予約要求したユーザ１３１が融通を希望するリソースの容量である。例えば、リソース量２０６としては、「台数：１台、ＣＰＵ使用率：５０％、メモリ使用量：１ＧＢ」等の値が格納されている。以下では、リソース量２０６に含まれる「台数」「ＣＰＵ使用率」「メモリ使用量」等、融通させるリソースをカテゴライズしたものをパラメータ名と呼び、「１台」「５０％」「１ＧＢ」等、パラメータ名に対応する値をパラメータと呼ぶこともある。
【００４８】
使用権限譲渡条件２０７は、後述する各処理において、予約要求に従ってリソースの融通が確定した場合に、予約要求を行ったユーザ１３１とは異なる他のユーザ１３１に対して、そのリソースの融通を許可するための条件である。例えば、使用権限譲渡条件として、あるリソースを２００９／７／３０以降に利用したい場合には、「融通可否＝ＹＥＳ，再開時刻＝２００９／７／３０」等の値が格納されている。続いて、使用権限譲渡条件リスト１０７について説明する。
【００４９】
図３は、本実施の形態における使用権限譲渡条件リスト１０７の例を示す図である。なお、以下では、リソースの融通が確定した場合、そのリソースを融通させるユーザのことを融通元ユーザと呼び、リソースの融通を受けるユーザを融通先ユーザと呼ぶ場合もある。
【００５０】
図３に示すように、使用権限譲渡条件リスト１０７は、使用権限譲渡条件ＩＤ３０１と、ユーザ名３０２と、開始時刻３０３と、期間３０４と、使用状態３０５と、リソース量３０６と、使用権限譲渡条件３０７と、予約リソース名３０８とを含んでいる。
【００５１】
使用権限譲渡条件ＩＤ３０１は、使用権限譲渡条件リスト１０７の各レコードを特定するための識別情報である。ユーザ名３０２は融通元ユーザの識別情報が設定されているが、リソースの融通が確定した場合には、予約要求１３３を行った融通先ユーザの識別情報が設定される。具体的には、図２に示した予約要求１３３のユーザ名２０２が設定される。
【００５２】
また、開始時刻３０３は、予約要求情報１３３の開始時刻２０３である。期間３０４は、予約要求１３３に含まれる期間２０４が設定される。これと同様に、使用状態３０５は、元の予約要求１３３の使用状態２０５であり、リソース量３０６は、予約要求１３３のリソース量２０６である。
【００５３】
また、使用権限譲渡条件３０７は、予約要求１３３の使用権限譲渡条件２０７であり、予約リソース名３０８は、融通元ユーザが予約要求した場合において、予約要求１３３に含まれる使用状態２０５に対応するリソースクラス１２０２（後述）のリソース名である。
【００５４】
図４は、本実施の形態における使用権限譲渡要求リスト１０８の例を示す図である。図４に示すように、使用権限譲渡要求リスト１０８は、使用権限譲渡要求ＩＤ４０１と、ユーザ名４０２と、開始時刻４０３と、期間４０４と、使用状態４０５と、リソース量４０６と、を含んでいる。
【００５５】
また、使用権限譲渡要求ＩＤ４０１は、使用権限譲渡要求リスト２０７の各レコードを特定するための識別情報である。ユーザ名４０２は、予約要求１３３のユーザ名２０２が設定される。これと同様に、開始時刻４０３は、予約要求１３３の開始時刻２０３であり、期間４０４は、予約要求１３３の期間２０４である。また、使用状態４０５は、予約要求１３３の使用状態２０５であり、リソース量４０６は、予約要求１３３のリソース量２０６である。
【００５６】
図５は、本実施の形態における使用状態変更作業時間算出式リスト１０９の例を示す図である。図５に示すように、使用状態変更作業時間算出式リスト１０９は、使用状態変更作業主体５０１と、使用状態変更作業内容５０２と、使用状態変更作業時間算出式５０３と、を含んでいる。
【００５７】
使用状態変更作業主体５０１は、リソースを融通するための使用状態変更作業を行う主体である。例えば、使用状態変更作業主体５０１には、「仮想サーバ」「物理サーバ」などが格納される。使用状態変更作業内容５０２は、どのような使用状態変更作業を行うかを示すものである。例えば、使用状態変更作業内容５０２には、「ＣＰＵ空き確保」「メモリ解放」などが格納される。
【００５８】
使用状態変更作業時間算出式５０３は、使用状態変更作業の所要時間を算出するための式や値である。例えば、使用状態変更作業内容５０２が「ＣＰＵ空き確保」である場合、固定値の「１秒」という値が設定されている。また、使用状態変更作業内容５０２が「メモリ解放」である場合、「２分×（メモリ解放量）」が格納されていることを示している。このほか、使用状態変更作業内容５０２が「メモリ解放」である場合、「１分×（仮想マシンのメモリ解放量）／（メモリ解放スピード）」という式を用いてもよい。なお、これらの各項目は、管理者１４１等によってあらかじめ設定されている。
【００５９】
図６は、本実施の形態における使用状態変更作業工程リスト１１０の例を示す図である。図６に示すように、使用状態変更作業工程リスト１１０は、融通前使用状態６０１と、融通後使用状態６０２と、条件６０３と、使用状態変更作業主体６０４と、使用状態変更作業内容６０５と、を含んでいる。
【００６０】
融通前使用状態６０１は、リソースを融通する前における使用状態である。融通後使用状態６０２は、リソースが融通された後における使用状態である。条件６０３は、使用状態変更作業内容６０５が適用される条件である。使用状態変更作業主体６０４は、融通作業の実行主体である。なお、これらの各項目は、使用状態変更作業時間算出式リスト１０９と同様に、管理者１４１等によってあらかじめ設定されている。
【００６１】
図７は、本実施の形態におけるリソースリスト１１１の例を示す図である。図７に示すように、リソースリスト１１１は、リソースクラス７０１と、リソース名７０２と、予約開始時刻７０３と、予約期間７０４と、を含んでいる。
【００６２】
リソースクラス７０１は、リソーススケジュールシステム１０００が有するリソースの種別である。例えば、リソースのスペックや容量、あるいは業務の種類等によって、「ＣｌａｓｓＡ」「ＣｌａｓｓＢ」等と分類されている。リソース名７０２は、融通先ユーザが融通を受けるリソースの単位を示すものであり、例えば、リソーススケジュールシステム１０００が有する物理的なリソースまたは論理的なリソースを一意に特定するための識別情報である。例えば、リソース名として論理的なリソースとして「サーバＡ１」、あるいは物理的なリソースとして「物理サーバ１２１Ａ」等が格納される。予約開始時刻７０３は、予約要求１３３に含まれる開始時刻２０３である。予約期間７０４は、予約要求１３３の期間２０４である。
【００６３】
なお、予約開始時刻７０３および予約期間７０４は、イベント受信処理部１０４が、予約要求１３３を受信した場合に、その都度更新される。また、図７では、リソーススケジュールシステム１０００が有するリソースのリソースクラス７０１には、「ＣｌａｓｓＡ」〜「ＣｌａｓｓＣ」まで存在し、そのうち「ＣｌａｓｓＣ」のリソース名７０２「サーバＣ２」のリソースのみ予約要求されていないことを示している。
【００６４】
図８は、本実施の形態における使用権限予約リスト１１２の例を示す図である。図８に示すように、使用権限予約リスト１１２は、融通が確定した場合の種々の情報が含まれている。具体的には、使用権限予約リスト１１２は、使用権限予約リスト番号８０１と、予約ユーザ名８０２と、予約開始時刻８０３と、予約期間８０４と、予約リソース名８０５と、使用状態８０６と、予約リソース量８０７と、使用権限譲渡条件８０８と、を含んでいる。
【００６５】
使用権限予約リストＩＤ８０１は、予約要求１３３の予約要求番号２０１が設定される。これと同様に、予約ユーザ名８０２は、予約要求１３３のユーザ名２０２であり、予約開始時刻８０３は、予約要求１３３に含まれる開始時刻２０３である。
【００６６】
また、予約期間８０４は、予約要求１３３の期間２０４であり、予約リソース名８０５は、図３に示した使用権限譲渡条件リスト１０７に含まれる予約リソース名３０８である。使用状態８０６は、予約要求１３３の使用状態２０５であり、予約リソース量８０７は、予約要求１３３のリソース量２０６であり、使用権限譲渡条件８０８は、予約要求１３３の使用権限譲渡条件２０７である。なお、後述する各処理で予約要求１３３に対する融通が確定した場合にはじめて、これらの各項目が設定される。
【００６７】
図９は、本実施の形態における融通案作成開始フラグ１１３の例を示す図である。融通案作成開始フラグ１１３は、イベント受信処理部１０４がイベント受信処理を実行した後に融通案を作成するか否かを示す情報である。例えば、融通案作成開始フラグ１１３には、融通案を作成する場合は「Ｏｎ」、また融通案を作成しない場合は「Ｏｆｆ」等の状態を示す情報が格納される。
【００６８】
図１０は、本実施の形態における融通元融通先候補リスト１１４の例を示す図である。融通元融通先候補リスト１１４は、融通先ユーザが要求するリソースに関する情報と、リソースを融通する融通元ユーザのリソースに関する情報とを対応付けて記憶するものである。
【００６９】
図１０に示すように、融通元融通先候補リスト１１４は、融通先ユーザ名１００１と、融通先使用状態１００２と、融通先リソース量１００３と、確保済みリソース量１００４と、融通元ユーザ名１００５と、融通元使用状態１００６と、融通元リソース量１００７と、融通方式１００８と、予約リソース名１００９と、を含んでいる。
【００７０】
融通先ユーザ名１００１は、融通先ユーザを一意に特定するための識別情報であり、予約要求１３３のユーザ名２０２が設定される。融通先使用状態１００２は、融通先ユーザが要求するリソースの使用状態であり、予約要求１３３の使用状態２０５である。融通先リソース量１００３は、融通先ユーザが要求するリソース量であり、予約要求１３３のリソース量２０６である。確保済みリソース量１００４は、融通先ユーザに融通させることとなったリソース量である。
【００７１】
融通元ユーザ名１００５は、融通元ユーザを一意に特定するための識別情報であり、予約要求１３３のユーザ名２０２である。融通元使用状態１００６は、融通元ユーザがリソースを使用する場合の使用状態であり、予約要求１３３の使用状態２０５である。融通元リソース量１００７は、融通元ユーザがリソースを使用する場合のリソース量であり、予約要求１３３のリソース量２０６である。融通方式１００８は、融通元ユーザが使用するリソース及び融通先ユーザが要求するリソースについて行う使用状態変更作業である。予約リソース名１００９は、融通元ユーザが融通させるリソースを一意に特定するための識別情報であり、図３に示した使用権限譲渡条件リスト１０７の予約リソース名３０８である。
【００７２】
図１１は、本実施の形態における融通作業候補リスト１１５の例を示す図である。融通作業候補リスト１１５は、使用状態変更作業を行う場合の作業時間を、リソースごとに対応付けて記憶するものである。図１１に示すように、融通作業候補リスト１１５は、使用状態変更作業主体１１０１と、使用状態変更作業候補１１０２と、使用状態変更作業時間予測値１１０３と、使用状態変更作業対象リソース名１００４と、を含んでいる。
【００７３】
使用状態変更作業主体１１０１は、リソースの融通に伴って発生する使用状態変更作業を実施する主体であり、図６に示した使用状態変更作業工程リスト１１０の使用状態変更作業主体６０４である。使用状態変更作業候補１１０２は、使用状態変更作業の候補であり、図６に示した使用状態変更作業工程リスト１１０の使用状態変更作業内容６０５である。使用状態変更作業時間予測値１１０３は、使用状態変更作業候補１１０２に記された使用状態変更作業を行うために必要な時間の予測値である。使用状態変更作業対象リソース名１１０４は、使用状態変更作業の対象となるリソースを一意に特定するための識別情報であり、図３に示した使用権限譲渡条件リスト１０７に含まれる予約リソース名３０８である。
【００７４】
図１２は、本実施の形態における使用可能リソースクラスリスト１１６の例を示す図である。使用可能リソースクラスリスト１１６は、予約要求１３３に含まれる使用状態２０５をどのクラスで使用させるかを示す情報を格納するものである。
【００７５】
図１２に示すように、使用可能リソースクラスリスト１１６は、使用状態１２０１と、リソースクラス１２０２と、を含んでいる。
【００７６】
使用状態１２０１は、予約要求１３３の使用状態２０５と同様のものである。リソースクラス１２０２は、リソースを使用状態１２０１に示された状態でユーザ１３１に使用させるクラスであり、図７に示したリソースリスト１１１に含まれるリソースクラス７０１と同様のものである。これらの各項目は、管理者１４１等によってあらかじめ設定されている。
【００７７】
図１２に示した例では、使用状態１２０１に示された「仮想サーバ」という状態でリソースが使用される場合、「ＣｌａｓｓＡ、ＣｌａｓｓＢ」というリソースクラス（例えば、高スペックのもの）が設定され、使用状態１２０１に示された「物理サーバ」という状態でリソースが使用される場合、高スペックの「ＣｌａｓｓＡ」と、「ＣｌａｓｓＣ」（例えば、低スペックのもの）というリソースクラスが設定されていることを示している。
【００７８】
続いて、リソーススケジュールシステム１０００で行われる処理（融通案作成適用処理）について説明する。図１３は、融通案作成適用処理の処理手順を示すフローチャートである。
【００７９】
融通案作成適用処理は、ユーザから指定された予約要求１３３にしたがって、使用状態変更作業時間を見積もり、予約要求１３３で指定された内容を保証する融通案を作成するものである。
【００８０】
まず、融通案作成適用処理では、イベント受信処理部１０４は、予約要求１３３を受信したときに、イベント受信処理（ステップＳ１３０１）を実行する。そして、融通案作成部１０５は、融通案作成開始フラグの値を判定し（ステップ１３０２）、融通案作成開始フラグ１１３がＯｎ状態であると判定した場合（ステップＳ１３０２；Ｙｅｓ）、融通案作成部１０５は、融通案を作成する（ステップ１３０３）。一方、融通案作成部１０５は、融通案作成開始フラグがＯｎ状態ではないと判定した場合（ステップＳ１３０２；Ｎｏ）、ステップＳ１３０４に進む。
【００８１】
そして、融通管理部１０６は、融通案作成部１０５によって融通案が作成されているか否か判定し（ステップ１３０４）、融通案が作成されていると判定した場合（ステップＳ１３０４；Ｙｅｓ）、融通管理部１０６は融通案を選択し（ステップ１３０５）、融通元ユーザ及び融通先ユーザへの承認要求を送信する（ステップ１３０６）。
【００８２】
その後、融通管理部１０６は、承認要求の受諾返答の受信を待機し、タイムアウトせずに受諾返答を受信した場合（ステップＳ１３０７；Ｎｏ）、融通管理部１０６は融通案を適用する（ステップ１３０８）。一方、融通管理部１０６は、受諾返答を受信せずタイムアウトした場合（ステップＳ１３０７；Ｙｅｓ）、ステップＳ１３０４に戻る。
【００８３】
ステップＳ１３０４において、融通案作成部１０５によって融通案が作成されていないと判定した場合（ステップ１３０４；Ｎｏ）、融通管理部１０６は、図１３に示す融通案作成適用処理を終了させる。
【００８４】
図１４は、図１３に示したイベント受信処理の処理手順を示すフローチャートである。図１４に示すように、イベント受信処理部１０４は、ユーザ端末１３０からイベントを受信するまで待機する（ステップ１４０１）。そして、イベント受信処理部１０４は、受信したイベントに予約要求番号２０１が含まれているか否かを判定する（ステップＳ１４０２）。
【００８５】
そして、イベント受信処理部１０４は、受信したイベントに予約要求番号２０１が含まれていないと判定した場合（ステップＳ１４０２；Ｎｏ）、そのまま待機する。
【００８６】
一方、イベント受信処理部１０４は、受信したイベントに予約要求番号２０１が含まれていると判定した場合（ステップＳ１４０２；Ｙｅｓ）、受信したイベントは予約要求１３３であると判断して、その予約要求１３３に含まれる開始時刻２０３、期間２０４、使用状態２０５、リソース量２０６を取得する（ステップＳ１４０３）。
【００８７】
その後、イベント受信処理部１０４は、図１２に示した使用可能リソースクラスリスト１１６にアクセスし、使用状態２０５に対応したリソースクラス１２０２を取得する（ステップＳ１４０４）。
【００８８】
イベント受信処理部１０４は、リソースリスト１１１を参照し、ステップＳ１４０３で取得したリソースクラス１２０２に対応するリソースを検索する（ステップＳ１４０５）。そして、イベント受信処理部１０４は、取得したリソースクラス１２０２に含まれるリソースの全てのリソースを検索したか否かを判定する（ステップＳ１４０６）。
【００８９】
例えば、図２に示した予約要求１３３があった場合、その使用状態２０５は「仮想サーバ」であるため、イベント受信処理部１０４は、図１２に示す使用可能リソースクラスリスト１１６の使用状態１２０１を参照し、その使用状態１２０１に対応するリソースクラス１２０２である「ＣｌａｓｓＡ、ＣｌａｓｓＢ」を取得する。さらに、イベント受信処理部１０４は、図７に示したリソースリスト１１１を参照し、取得したリソースクラス１２０２に対応するリソース名７０２のリソース（例えば、サーバＡ１、サーバＡ２）を検索する。そして、イベント受信処理部１０４は、全てのリソース（例えば、サーバＡ１、サーバＡ２）を検索したと判定した場合（ステップＳ１４０６；Ｙｅｓ）、ステップＳ１４１５に進む。
【００９０】
一方、イベント受信処理部１０４は、全てのリソース（例えば、サーバＡ１、サーバＡ２）を検索していないと判定した場合（ステップＳ１４０６；Ｎｏ）、ステップＳ１４０４で取得したリソースクラス１２０２のうち、未だ検索していないリソース名７０２のリソースに対応する予約開始時刻７０３および予約期間７０４を取得する（ステップＳ１４０７）。
【００９１】
そして、イベント受信処理部１０４は、ステップＳ１４０３において取得した開始時刻２０３および期間２０４が、ステップＳ１４０７において取得した予約開始時刻７０３および予約期間７０４に含まれているか否か、すなわち予約要求された時間に既に他のユーザ１３１からの予約要求があるか否かを判定する（ステップＳ１４０８）。
【００９２】
イベント受信処理部１０４は、予約要求された時間に既に他のユーザ１３１からの予約があると判定した場合（ステップＳ１４０８；Ｙｅｓ）、ステップＳ１４０５に戻る。一方、予約要求された時間に既に他のユーザ１３１からの予約要求がないと判定した場合（ステップＳ１４０８；Ｎｏ）、予約要求されていないリソース名７０２のリソースの台数を使用可能なリソースの台数に加算する（ステップＳ１４０９）。
【００９３】
例えば、イベント受信処理部１０４は、予約要求されていないリソース名７０２のリソース、すなわち使用可能なリソース量が既に３台存在していれば、その台数に予約要求１３３のリソース量２０６に含まれる「台数」の値（例えば、図２に示した例では、「１」）を加算し、使用可能なリソースの台数を４台とする。
【００９４】
そして、イベント受信処理部１０４は、使用可能なリソース名７０２のリソースの台数と予約要求１３３に含まれるリソース量２０６の「台数」とを比較し、使用可能なリソース名７０２のリソース量の台数が予約要求１３３に含まれるリソース量２０６の「台数」以上であるか否かを判定する（ステップＳ１４１０）。イベント受信処理部１０４は、使用可能なリソース名７０２のリソースの台数が予約要求されたリソース量２０６の「台数」以上ではないと判定した場合（ステップＳ１４１０；Ｎｏ）、ステップＳ１４０５に戻り、ステップＳ１４０５〜Ｓ１４１０までの処理を繰り返す。
【００９５】
一方、イベント受信処理部１０４は、使用可能なリソース名７０２のリソースの台数が予約要求されたリソース量２０６の「台数」以上であると判定した場合（ステップＳ１４１０；Ｙｅｓ）、予約要求１３３を使用予約権限リスト１１２に追加し、予約要求１３３の内容を登録する（ステップＳ１４１１）。このように、予約要求されたリソース量２０６の「台数」分のリソースが確保され、その予約要求の内容が使用権限予約リスト１１２に登録されてはじめて予約要求に対して融通を行うことが確定する。
【００９６】
なお、イベント受信処理部１０４は、予約要求１３３を使用権限予約リスト１１２に登録する際に、リソースリスト１１１および使用可能リソースクラスリスト１１６を参照し、予約要求１３３に含まれる使用状態２０５に対応するリソース名７０２を使用権限予約リスト１１２の予約リソース名８０５に設定する。予約リソース名８０５以外の各項目については、予約要求１３３の各項目の内容が設定される。このように、使用権限予約リスト１１２には、予約要求１３３のうち、上述したように融通が確定したもののみが順次追加される。
【００９７】
例えば、図８では、イベント受信処理部１０４が、上述したステップＳ１４０１〜Ｓ１４１１までの処理を行って、図２に示したユーザ名３０２が「Ｕｓｅｒ１」である予約要求１３３の各項目を使用権限予約リスト１１２の各項目に登録し、さらに、これと同様に、図２に示したユーザ名３０２が「Ｕｓｅｒ３」である予約要求１３３の各項目を使用権限予約リスト１１２の各項目に登録されている。
【００９８】
その後、イベント受信処理部１０４は、ステップＳ１４０１で受信した予約要求１３３に含まれる使用権限譲渡条件２０７を参照し、「融通可否＝Ｙｅｓ」となっているか否かを判定する（ステップＳ１４１２）。そして、イベント受信処理部１０４は、「融通可否＝Ｙｅｓ」となっていないと判定した場合（ステップＳ１４１２；Ｎｏ）、ステップＳ１４１４に進む。
【００９９】
一方、イベント受信処理部１０４は、「融通可否＝Ｙｅｓ」となっていると判定した場合（ステップＳ１４１２；Ｙｅｓ）、ステップＳ１４１１において使用権限予約リスト１１２に追加された予約要求１３３と予約リソース名８０５とを使用権限譲渡条件リスト１０７に追加する（ステップＳ１４１３）。
【０１００】
例えば、図８では、ユーザ名「Ｕｓｅｒ１」の予約要求１３３に含まれる使用権限譲渡条件２０７は、「融通可否＝Ｙｅｓ」となっているため、図２に示したユーザ名「Ｕｓｅｒ１」の予約要求１３３と予約リソース名８０５とが、図３に示した使用権限譲渡条件リスト１０７に追加されている。なお、予約リソース名８０５は、ステップＳ１４０５において、イベント受信処理部１０４が検索した図７に示したリソース名７０２が設定される。
【０１０１】
また、図８に示した使用権限予約リスト１１２では、ユーザ名「Ｕｓｅｒ３」である予約要求１３３は、使用権限譲渡条件２０７が「融通可否＝Ｎｏ」であるため、図３に示した使用権限譲渡条件リスト１０７には追加されない。すなわち、図３に示した使用権限譲渡条件リスト１０７には、予約要求１３３を行って、その融通が確定したユーザ１３１が、他のユーザ１３１に対してリソースをさらに融通させてもよいもののみが登録されている。
【０１０２】
そして、ステップＳ１４１２またはステップＳ１４１３が終了すると、イベント受信処理部１０４は、後述する融通案作成処理を開始させないために、融通案作成開始フラグ１１３の「Ｏｆｆ」に更新する（ステップＳ１４１４）。
【０１０３】
ステップＳ１４０６において、イベント受信処理部１０４が、全てのリソースを検索したと判定した場合（ステップ１４０６；Ｙｅｓ）、ステップＳ１４０１で受信した予約要求１３３の各項目の中で、使用権限譲渡条件２０７以外の項目を、使用権限譲渡要求リスト１０８に追加し（ステップＳ１４１５）、イベント受信処理部１０４は、後述する融通案作成処理を開始させるために、融通案作成開始フラグ１１３の「Ｏｎ」に更新する（ステップＳ１４１６）。
【０１０４】
例えば、図４では、イベント受信処理部１０４が、ユーザ名「Ｕｓｅｒ２」の予約要求１３３を受信したが、ステップＳ１４０１〜Ｓ１４１０の処理を行っても、予約要求された条件に合致するリソースが検索できなかった（例えば、開始時刻４０３「２００９／ＮＮ／ＮＮ」から、期間４０４「１０ｄａｙｓ」の期間で、リソース量４０６で指定されただけのリソースが見つからなかった）ため、ユーザ名「Ｕｓｅｒ２」の予約要求１３３が、使用権限譲渡要求リスト１０８に登録されている。また、ユーザ名「Ｕｓｅｒ４」の予約要求１３３についても、これと同様に、使用権限譲渡要求リスト１０８に登録されている。
【０１０５】
すなわち、図４に示した使用権限譲渡要求リスト１０８には、予約要求１３３を行ったが、その予約が確定せず、未だ他のユーザ１３１からリソースが融通されていない予約要求１３３のみが登録されている。
【０１０６】
このステップＳ１４１６の処理が終了すると、図１４に示したイベント受信処理の全ての処理が終了する。このように、イベント受信処理部１０４が、図１４に示したイベント受信処理を行うことによって、後述する融通案作成処理が必要であるか否かを判定している。続いて、図１３に示した融通案作成処理について説明する。
【０１０７】
図１５は、本実施の形態の融通案作成処理の処理手順を示すフローチャートである。図１５に示すように、融通案作成部１０５は、まず、融通元融通先候補リスト作成処理を行う（ステップＳ１５０１）。
【０１０８】
図１６は、図１５に示した融通元融通先候補リスト作成処理の処理手順を示すフローチャートである。図１６に示すように、融通案作成部１０５は、まず、使用権限譲渡要求リスト１０８を参照し、図１４に示したステップＳ１４１５で追加された使用権限譲渡条件２０７以外の項目を取得し、取得した項目のうち、開始時刻４０３に期間４０４を加算して、終了時刻を算出する（ステップＳ１６０１）。
【０１０９】
その後、融通案作成部１０５は、使用権限譲渡条件リスト１０７を参照し（ステップＳ１６０２）、全件について検索したか否か（すなわち、未処理のレコードがあるか否か）を判定する（ステップＳ１６０３）。そして、融通案作成部１０５は、使用権限譲渡条件リスト１０７の全件について検索したと判定した場合（ステップＳ１６０３；Ｙｅｓ）、融通元融通先候補リスト作成処理を終了させる。
【０１１０】
なお、融通案作成部１０５が、使用権限譲渡条件リスト１０７の全件を検索したか否かの具体的な判定は、例えば、使用権限譲渡条件ＩＤ３０１をキーとして使用権限譲渡条件リスト１０７内のレコードを検索し、検索が終了するとそのレコードの使用権限譲渡条件ＩＤ３０１を不図示のメモリ等に記憶しておく。そして、融通案作成部１０５は、レコードをこの処理を最終レコードまで行うことによって、使用権限譲渡条件リスト１０７の全件を検索したか否かを判定する。以下の説明においても、これと同様に、ある項目をキーにして全件を検索したか否かを判定しているものとする。
【０１１１】
一方、融通案作成部１０５は、使用権限譲渡条件リスト１０７の全件について検索していないと判定した場合（ステップＳ１６０３；Ｎｏ）、使用権限譲渡条件リスト１０７のレコードを取得し、使用権限譲渡条件３０７に含まれる再開時刻を取得する（ステップＳ１６０４）。
【０１１２】
そして、融通案作成部１０５は、ステップＳ１６０１で算出した終了時刻と、ステップＳ１６０４で取得した再開時刻とを比較し、再開時刻が終了時刻よりも前であるか否か、すなわち融通元ユーザがリソースを使用する期間と融通先ユーザがリソースを使用する期間とが重複しているか否かを判定する（ステップＳ１６０５）。
【０１１３】
融通案作成部１０５は、再開時刻が終了時刻よりも前であると判定した場合（ステップＳ１６０５；Ｙｅｓ）、ステップＳ１６０３に戻り、ステップＳ１６０３〜Ｓ１６０５の処理を繰り返す。
【０１１４】
一方、融通案作成部１０５は、再開時刻が終了時刻よりも前でないと判定した場合（ステップＳ１６０５；Ｎｏ）、ステップＳ１６０１で取得した使用権限譲渡要求リスト１０８の各項目と、ステップＳ１６０２で参照した使用権限譲渡条件リスト１０７の各項目を、融通元融通先候補リスト１１４に追加する（ステップＳ１６０６）。
【０１１５】
例えば、図１０に示した融通元融通先候補リスト１１４では、融通先ユーザ名１００１には、図４に示した使用権限譲渡要求リスト１０８のユーザ名４０「Ｕｓｅｒ２」が設定され、融通先使用状態１００２には、使用権限譲渡要求リスト１０８の使用状態４０５「仮想サーバ」が設定される。さらに、融通先リソース量１００３には、使用権限譲渡要求リスト１０８のリソース量４０６「台数１台，ＣＰＵ使用率：５０％，メモリ使用量：１ＧＢ」が設定される。
【０１１６】
融通元候補ユーザ名１００５には、図３に示した使用権限譲渡条件リスト１０７のユーザ名３０２「Ｕｓｅｒ１」が設定され、融通元候補使用状態１００６には、使用権限譲渡条件リスト１０７の使用状態３０５「仮想サーバ」が設定される。さらに、融通元候補リソース量１００７および予約リソース名１００９には、使用権限譲渡条件リスト１０７のリソース量３０６および予約リソース名３０８がそれぞれ設定される。
【０１１７】
このように、融通元融通先候補リスト１１４には、どの融通先ユーザがどの融通元ユーザからリソースの融通をうけるかについての種々の情報が対応付けて設定される。なお、この段階では、確保済みリソース量１００４および融通方式１００８には初期値（例えば、ゼロ台、ゼロ％、ゼロＧＢ等）が設定されているものとする。そして、ステップＳ１６０６の処理が終了するとステップＳ１６０３に戻り、融通案作成部１０５は、融通元融通先候補リスト作成処理を終了させる。続いて、図１５に戻り、融通案作成処理のステップＳ１５０２以降の各処理について説明する。
【０１１８】
融通元融通先候補リスト作成処理が終了すると、融通案作成部１０５は、融通元融通先候補リスト１１４の全件について検索したか否か（すなわち、未処理のレコードがあるか否か）を判定する（ステップＳ１５０２）。
【０１１９】
融通案作成部１０５は、融通元融通先候補リスト１１４の全件について検索していないと判定した場合（ステップＳ１５０２；Ｎｏ）、使用状態変更作業候補リスト作成処理（ステップＳ１５０３）を行う。
【０１２０】
図１７は、図１５に示した使用状態変更作業候補リスト作成処理の処理手順を示すフローチャートである。図１７に示すように、融通案作成部１０５は、図１０に示した融通元融通先候補リスト１００９を参照し、融通元候補使用状態１００６と融通先使用状態１００２とを取得する（ステップＳ１７０１）。
【０１２１】
そして、融通案作成部１０５は、取得した融通元候補使用状態１００６と融通先使用状態１００２の両方を満たすレコードを検索し（ステップＳ１７０２）、検索したレコードに条件が設定されているか否かを判定する（ステップＳ１７０３）。
【０１２２】
例えば、図１０に示した融通元融通先候補リスト１００９の融通元候補使用状態１００６および融通先使用状態１００２はいずれも「仮想サーバ」であるため、図６に示した使用状態変更作業候補リスト１１０の現在使用状態６０１および融通後使用状態６０２がいずれも「仮想サーバ」であるレコードを検索し、そのレコードに含まれる条件６０３に条件が設定されている条件の有無を判定する。図１０に示した例では、条件６０３として、「確保済みリソース量のＣＰＵ使用率が融通先リソース量のＣＰＵ使用率に満たない（確保済みリソース量１００４（ＣＰＵ使用率）≦融通先リソース量１００３（ＣＰＵ使用率））」、および「確保済みリソース量のメモリ使用率が融通先リソース量のメモリ使用率に満たない（確保済みリソース量１００４（メモリ使用率）≦融通先リソース量１００３（メモリ使用率））」が設定されているので、融通案作成部１０５は、検索したレコードに条件が設定されていると判定する。
【０１２３】
その後、融通案作成部１０５は、全ての条件について検索したか否か（すなわち、未処理の条件があるか否か）を判定し（ステップＳ１７０４）、全ての条件について検索していないと判定した場合（ステップＳ１７０４；Ｎｏ）、条件６０３に設定された条件式を取得する（ステップＳ１７０５）。そして、融通案作成部１０５は、取得した条件式に含まれるパラメータ名を参照し、そのパラメータ名をキーにして、図１０に示した融通元融通先候補リスト１００９に含まれる確保済みリソース量１００４および融通先リソース量１００３に設定されているパラメータを取得する（ステップＳ１７０６）。
【０１２４】
例えば、図６に示した使用状態変更作業候補リスト１１０の条件６０３にはパラメータ名として「ＣＰＵ使用率」「メモリ使用率」が含まれているため、これらのパラメータ名をキーにして、図１０に示した融通元融通先候補リスト１００９の確保済みリソース量１００４に設定されているパラメータ名「ＣＰＵ使用率」に対応するパラメータ「５０％」および融通先リソース量１００３に設定されているパラメータ名「ＣＰＵ使用率」に対応するパラメータ「５０％」を取得する。
【０１２５】
さらに、融通案作成部１０５は、図１０に示した融通元融通先候補リスト１００９の確保済みリソース量１００４に設定されているパラメータ名「メモリ使用率」に対応するパラメータ「０．４ＧＢ」および融通先リソース量１００３に設定されているパラメータ名「メモリ使用率」に対応するパラメータ「１ＧＢ」を取得する。
【０１２６】
その後、融通案作成部１０５は、取得したパラメータを条件６０３に設定されている条件式に代入し（ステップＳ１７０７）、その条件式の結果が真であるか否かを判定する（ステップＳ１７０８）。そして、融通案作成部１０５は、条件式の結果が真でないと判定した場合（ステップＳ１７０８；Ｎｏ）、ステップＳ１７０３に戻ってステップＳ１７０３〜Ｓ１７０８の処理を繰り返す。
【０１２７】
一方、融通案作成部１０５は、条件式の結果が真であると判定した場合（ステップＳ１７０８；Ｙｅｓ）、使用状態変更作業主体６０４および使用状態変更作業内容６０５を図１１に示した使用状態変更作業候補リスト１１５に追加し（ステップＳ１７０９）、ステップＳ１７０３に戻り、ステップＳ１７０３〜Ｓ１７０８の処理を繰り返す。
【０１２８】
例えば、図６に示した例では、条件６０３の条件式「確保済みリソース量１００４（ＣＰＵ使用率）≦融通先リソース量１００３（ＣＰＵ使用率）」は「５０％＝５０％」であり、条件式「確保済みリソース量１００４（メモリ使用率）≦融通先リソース量１００３（メモリ使用率）」は「０．４＜１．０ＧＢ」であるため、融通案作成部１０５は、これらの条件式の結果を真と判定する。
【０１２９】
そして、融通案作成部１０５は、図６に示す使用状態変更作業工程リスト１１０を参照し、これらの条件式に対応する使用状態変更作業主体６０４および使用状態変更作業内容６０５を取得し、取得したこれらの使用状態変更作業主体６０４および使用状態変更作業内容６０５を、図１１に示す使用状態変更作業候補リスト１１５に追加する（ステップＳ１７０９）。
【０１３０】
例えば、図６に示した条件式のうち、「ＣＰＵ使用率」についての条件式に対応する使用状態変更作業主体６０４は「仮想スーパバイザ」であり、使用状態変更作業内容６０５は「ＣＰＵ空き確保」であるため、これらの値を図１１に示す使用状態変更作業候補リスト１１５に追加する。
【０１３１】
また、図６に示した条件式のうち、「メモリ使用率」についての条件式に対応する使用状態変更作業主体６０４は「仮想サーバ」であり、使用状態変更作業内容６０５は「メモリ解放」であるため、これらの値を図１１に示す使用状態変更作業候補リスト１１５に追加する。なお、図１１に示した使用状態変更作業候補リスト１１５の使用状態変更作業時間予測値１１０３には値が設定されているが、これらの値は、後述する使用状態変更作業時間処理において設定される。
【０１３２】
このステップＳ１７０９の処理が終了すると、ステップＳ１７０３に戻り、以降の各処理を繰り返す。そして、ステップＳ１７０４において、全ての条件について検索したと判定した場合（ステップＳ１７０４；Ｙｅｓ）、ステップＳ１７１０に進む。
【０１３３】
ステップＳ１７１０では、融通案作成部１０５は、図６に示した条件６０３のうち「デフォルト」となっている条件を検索し、その条件「デフォルト」に対応する使用状態変更作業内容６０５である「仮想サーバ起動」を、図１１に示す使用状態変更作業候補リスト１１５に追加する（ステップＳ１７１０）。仮想サーバ等のリソースを融通させる場合、すなわち使用状態変更作業を行う場合、必ず仮想サーバ等の起動が必要であるため、使用状態変更作業候補リスト作成処理の最後のステップであるＳ１７１０において、このような設定を行っている。続いて、図１５に戻り、融通案作成処理のステップＳ１５０４以降の各処理について説明する。
【０１３４】
融通案作成部１０５は、使用状態変更作業候補リスト作成処理（ステップＳ１５０３）が終了すると、使用状態変更作業時間算出処理（ステップＳ１５０４）を行う。図１８は、使用状態変更作業時間処理の処理手順を示すフローチャートである。
【０１３５】
図１８に示すように、使用状態変更作業時間算出部１１７は、使用状態変更作業候補リスト１１５を参照し（ステップＳ１８０１）、使用状態変更作業候補リスト１１５を全件検索したか否かを判定する（ステップＳ１８０２）。
【０１３６】
使用状態変更作業時間算出部１１７は、使用状態変更作業候補リスト１１５を全件検索していないと判定した場合（ステップＳ１８０２；Ｎｏ）、参照した使用状態変更作業候補リスト１１５のレコードに一致するレコードを、図５に示した使用状態変更作業時間算出リスト１０９の中から検索し（ステップＳ１８０３）、そのレコードに対応する使用状態変更作業時間算出式５０３を取得する（ステップＳ１８０４）。
【０１３７】
例えば、使用状態変更作業時間算出部１１７は、図１１に示した使用状態変更作業候補リスト１１５の１レコード目の使用状態変更作業主体１１０１が「仮想サーバ」であり、使用状態変更作業候補１１０２が「メモリ解放」であるため、これらと同じ値の融通作業主体５０１および融通作業内容５０２を含むレコード（この場合、上から２つ目のレコード）検索し、検索した融通作業主体５０１および融通作業内容５０２に対応する使用状態変更作業時間算出式５０３（この場合、「２分×メモリ解放量」）を取得する。
【０１３８】
その後、使用状態変更作業時間算出部１１７は、取得した使用状態変更作業時間算出式５０３に含まれるパラメータ名を参照し、そのパラメータ名と同じパラメータ名に対応するパラメータを取得し（ステップＳ１８０５）、取得したパラメータを使用状態変更作業時間算出式５０３に代入して使用状態変更作業時間を算出し（ステップＳ１８０６）、算出した使用状態変更作業時間を、図１１に示した使用状態変更作業候補リスト１１５の使用状態変更作業時間予測値１１０３に設定する（ステップＳ１８０７）。
【０１３９】
例えば、使用状態変更作業時間算出部１１７は、使用状態変更作業時間算出式５０３として、「２分×メモリ解放量」を取得した場合において、まず、図６に示した使用状態変更作業工程リスト１１０の使用状態変更作業内容６０５を参照し、「メモリ解放」とともに記載されているメモリ解放量を求めるための算式「メモリ解放量＝融通先リソース量のメモリ使用量―確保済みリソース量のメモリ使用量」を参照して、パラメータ名「メモリ使用量」を取得する。
【０１４０】
その後、使用状態変更作業時間算出部１１７は、取得したパラメータ名「メモリ使用量」と同じパラメータ名を、図１０に示した融通元融通先候補リスト１００９に含まれる融通先リソース量１００３および確保済みリソース量１００４の中から取得し、そのパラメータ名に対応するパラメータ「１ＧＢ」「０．４ＧＢ」を取得する。
【０１４１】
そして、使用状態変更作業時間算出部１１７は、取得したパラメータ「１ＧＢ」「０．４ＧＢ」を上述した算式に代入して「メモリ解放量」の値「０．６ＧＢ」を求める。そして、使用状態変更作業時間算出部１１７は、求めた「メモリ解放量」の値「０．６ＧＢ」を、使用状態変更作業時間算出式５０３「２分×メモリ解放量」に代入し、使用状態変更作業時間「１．２分／ＧＢ」を算出し、算出した使用状態変更作業時間を、使用状態変更作業時間予測値１１０３に設定する。
【０１４２】
このステップＳ１８０７が終了すると、ステップＳ１８０２に戻り、ステップＳ１８０２〜Ｓ１８０７までの処理を繰り返す。そして、使用状態変更作業時間算出部１１７は、ステップＳ１８０２において、使用状態変更作業候補リスト１１５を全件検索したと判定した場合（ステップＳ１８０２；Ｙｅｓ）、図１８に示した使用状態変更作業時間処理を終了させる。続いて、図１５に戻り、ステップＳ１５０５以降の各処理について説明する。
【０１４３】
使用状態変更作業時間算出部１１７は、使用状態変更作業時間処理（ステップＳ１５０４）が終了すると、トータル使用状態変更作業時間算出処理（ステップＳ１５０５）を行う。
【０１４４】
図１９は、トータル使用状態変更作業時間処理の処理手順を示すフローチャートである。図１１に示した使用状態変更作業候補リスト１１５内の各作業が同じリソースを対象としている場合、各作業はシーケンシャルに実施されるため、使用状態変更作業時間は、各作業時間を加算して算出すべきである。一方、使用状態変更作業候補リスト１１５内の各作業が別のリソースを対象としている場合（例えば、あるユーザが同じ時期に複数のリソースの融通を要求している場合等）、使用状態変更作業はパラレルに実施されるため、使用状態変更作業時間は、リソースごとに求めた各作業時間の最大値を算出すべきである。
【０１４５】
したがって、以下に説明するように、トータル使用状態変更作業時間算出処理では、このような事情を考慮するために、使用状態変更作業候補リスト１１５内の各作業対象となるリソースが同じリソースであるか否かを判定することにより、それぞれの使用状態変更作業時間を加算し、あるいは最大値を算出し、トータルの使用状態変更作業時間を算出している。
【０１４６】
図１９に示すように、使用状態変更作業時間算出部１１７は、トータルの使用状態変更作業時間をゼロに初期化する（ステップ２４０１）。なお、トータルの使用状態変更作業時間は不図示のメモリ等の記憶媒体に記憶され、使用状態変更作業時間算出部１１７が過去にトータルの使用状態変更作業時間を算出した場合には、その時間が不図示のメモリ等の記憶媒体に記憶されているため、ステップＳ２４０１において、このように、その時間を初期化している。
【０１４７】
そして、使用状態変更作業時間算出部１１７は、使用状態変更作業候補リスト１１５を参照し（ステップ２４０２）、使用状態変更作業候補リスト１１５を全件検索したか否かを判定し（ステップＳ２４０３）、使用状態変更作業候補リスト１１５を全件検索したと判定した場合（ステップＳ２４０３；Ｙｅｓ）、図１９に示すトータル使用状態変更作業時間算出処理を終了させる。
【０１４８】
一方、使用状態変更作業時間算出部１１７は、使用状態変更作業候補リスト１１５を全件検索していないと判定した場合（ステップＳ２４０３；Ｎｏ）、使用状態変更作業候補リスト１１５の最初のレコードを検索し（ステップＳ２４０４）、検索したレコードに含まれる使用状態変更作業リソース名１１０４を取得する（ステップＳ２４０５）。
【０１４９】
その後、使用状態変更作業時間算出部１１７は、取得した使用状態変更作業リソース名１１０４と同一の使用状態変更作業リソース名１１０４を含むレコードを検索し（ステップＳ２４０６）、検索したレコードに含まれる使用状態変更作業時間予測値１１０３を加算する（ステップＳ２４０７）。
【０１５０】
例えば、使用状態変更作業時間算出部１１７は、図１１に示した使用状態変更作業候補リスト１１５の最初のレコードを検索して使用状態変更作業リソース名１１０４「サーバＡ１」を取得する。そして、使用状態変更作業時間算出部１１７は、取得した「サーバＡ１」と同じ使用状態変更作業リソース名１１０４を含むレコード（図１１に示した例では、上から２番目、４番目のレコード）を検索し、そのレコードに含まれる使用状態変更作業時間予測値１１０３（図１１に示した例では、「５分」、「０．５秒」）を、最初のレコードに含まれる使用状態変更作業時間予測値１１０３「１．２分」に加算した値「６．２分０．５秒」を取得する。
【０１５１】
そして、使用状態変更作業時間算出部１１７は、ステップＳ２４０７で加算した値が、それまでに算出したトータルの使用状態変更作業時間よりも大きいか否かを判定し（ステップＳ２４０８）、ステップＳ２４０７で加算した値がトータルの使用状態変更作業時間よりも大きいと判定した場合（ステップＳ２４０８；Ｙｅｓ）、トータルの使用状態変更作業時間に、ステップＳ２４０７で加算した値を設定する（ステップＳ２４０９）。その後、ステップＳ２４０３に戻り、ステップＳ２４０３〜Ｓ２４０９の各処理を繰り返す。
【０１５２】
一方、使用状態変更作業時間算出部１１７は、ステップＳ２４０７で加算した値がトータルの使用状態変更作業時間よりも大きくないと判定した場合（ステップＳ２４０８；Ｎｏ）、何もせずにステップＳ２４０３に戻り、ステップＳ２４０３〜Ｓ２４０９の各処理を繰り返す。このように、図１１に示した使用状態変更作業候補リスト１１５のレコードに含まれる使用状態変更作業リソース名１１０４ごとに使用状態変更作業時間予測値１１０３を加算して、最大値をトータルの使用状態変更作業時間に設定する。続いて、図１５に戻り、ステップＳ１５０６以降の各処理について説明する。
【０１５３】
使用状態変更作業時間算出部１１７が、トータルの使用状態変更作業時間を算出すると、融通案作成部１０５は、現在の時刻からトータルの使用状態変更作業時間と使用権限譲渡条件リスト１０７に含まれる期間３０４が経過した場合に、融通元ユーザがリソースの使用を再開する時刻が過ぎていないか否か、すなわち融通元ユーザがリソースを融通するために指定した使用権限譲渡条件リスト１０７に含まれる期間３０４が確保できているか否かを判定する（ステップＳ１５０６）。
【０１５４】
そして、融通案作成部１０５は、使用権限譲渡条件リスト１０７に含まれる期間３０４が確保できていると判定した場合（ステップＳ１５０６；Ｙｅｓ）、図１０に示した融通元融通先候補リスト１００９の確保済みリソース量１００４に、融通可能なリソースの量（例えば、使用状態変更作業時間算出部１１７が求めた「メモリ解放量」の値「０．６ＧＢ」）を加算するとともに、図１０に示した融通元融通先候補リストの融通方式１００８に、使用状態変更作業内容６０５（例えば、「メモリ解放」）を設定し（ステップＳ１５０７）、加算後の確保済みリソース量１０００４が融通先リソース量１００３以上となっているか否かを判定する（ステップＳ１５０８）。
【０１５５】
ここで、ステップＳ１５０６において、現在の時刻からトータルの使用状態変更作業時間の２倍の時間を算出し、算出したその時間と使用権限譲渡条件リスト１０７に含まれる期間３０４が経過した場合に、融通元ユーザがリソースの使用を再開する時刻が過ぎていないか否かを判定してもよい。すなわち、現在使用状態から融通先使用状態に遷移するための作業時間に、融通先使用状態から現在使用状態に戻すための作業時間を同じと見積もり加えて、それぞれの作業時間を確保できるかを判定することとしてもよい。
【０１５６】
また、ステップＳ１５０３において、融通案作成部１０５は、融通元候補使用状態１００６と融通先使用状態１００２を入れ替えて検索した使用状態変更作業候補についても使用状態変更作業候補リストに追加することにより、融通先使用状態から現在使用状態に戻すための作業時間も含めてトータルの使用状態変更作業時間を算出することとしてもよい。
【０１５７】
そして、融通案作成部１０５は、加算後の確保済みリソース量１０００４が融通先リソース量１００３以上となっていると判定した場合（ステップＳ１５０８；Ｙｅｓ）、融通案リスト２３０１を作成する（ステップＳ１５０９）。
【０１５８】
図２０は、上述した融通案リスト２３０１の例を示す図である。図２０に示すように、融通案リスト２３０１は、融通案番号２３０２と、予約要求番号２３０３と、ユーザ名２３０４と、融通内容２３０５と、を含んでいる。
【０１５９】
融通案番号２３０２は、融通案を一意に識別するための識別情報である。予約要求番号２３０３は、図２に示した予約要求１３３に含まれる予約要求番号２０１である。ユーザ名２３０４は、融通案リスト２３０１の送信先であり、融通元ユーザおよび融通先ユーザである。
【０１６０】
融通内容２３０５は、具体的な融通案の内容を含むものである。図２０に示す例では、図２に示した予約要求１３３に含まれる開始時刻２０３「２００９／ｘｘ／ｘｘ」、図１０に示した融通元融通先候補リスト１１４に含まれる融通元候補ユーザ名１００５「Ｕｓｅｒ１」および融通先候補ユーザ名１００１「Ｕｓｅｒ２」、図３に示した使用権限譲渡条件リスト１０７の使用権限譲渡条件３０７に含まれる再開時刻「２００９／ｙｙ／ｙｙ」が含まれていることを示している。
【０１６１】
そして、融通案作成部１０５は、上述した融通案を作成すると、ステップＳ１５０２に戻り、ステップＳ１５０２〜Ｓ１５０９までの処理を繰り返し、ステップＳ１５０２において、融通元融通先候補リスト１１４の全件について検索したと判定した場合（ステップＳ１５０２；Ｙｅｓ）、融通案作成処理を終了させる。続いて、図１３に戻り、ステップＳ１３０４以降の各処理について説明する。
【０１６２】
その後、融通管理部１０６は、融通案作成部１０５によって作成された融通案があるか否かを判定し（ステップ１３０４）、融通案があると判定した場合（ステップＳ１３０４；Ｙｅｓ）、作成されている融通案を選択し（ステップＳ１３０５）、融通元ユーザ及び融通先ユーザに対して、融通案にしたがってリソースの融通についての許可を求めるための承認要求を送信する（ステップＳ１３０６）。
【０１６３】
そして、融通管理部１０６は、承認要求を送信した後、返信を受信したか否かを判定し（ステップＳ１３０７）、返信を受信していないと判定した場合（ステップＳ１３０７；Ｎｏ）、ステップＳ１３０４に戻り、ステップＳ１３０４以降の各処理を繰り返し実行する。
【０１６４】
一方、融通管理部１０６は、返信を受信したと判定した場合（ステップＳ１３０７；Ｙｅｓ）、ステップＳ１３０３において作成された融通案に従って、リソースの融通を開始させる（ステップＳ１３０８）。そして、ステップＳ１３０４において、融通管理部１０６が、融通案作成部１０５によって作成された融通案がないと判定した場合（ステップ１３０４；Ｎｏ）、図１３に示す融通案作成処理を終了させる。
【０１６５】
このように、イベント受信部１０４が、少なくとも、リソースが使用される期間２０４と、リソースが使用される環境を示す使用状態２０５と、融通元ユーザから融通先ユーザへのリソースの融通の可否を示す譲渡条件２０７とを含む予約要求１３３を、融通元ユーザおよび融通先ユーザから受信し、使用状態作業工程リスト１１０が、融通元ユーザのリソースの使用状態である融通前使用状態と、融通先ユーザのリソースの使用状態である融通後使用状態と、融通前使用状態から融通後使用状態に移行するための使用状態変更作業時間を算出する条件６０３とを対応付けて記憶し、使用状態変更作業時間算出リスト１０９が、条件６０３に対応付けて作業時間の使用状態変更作業時間算出式５０３を記憶し、融通案作成部１０５が、融通元ユーザから受信した予約要求１３３の譲渡条件２０７にリソースを融通させる旨が示されているか否かを判定し、融通元ユーザから受信した予約要求１３３の譲渡条件２０７にリソースの融通させる旨が示されていると判定した場合、融通元ユーザから受信した予約要求１３３に含まれる使用状態２０５に一致する融通前使用状態および融通先ユーザから受信した予約要求１３３に含まれる使用状態２０５に一致する融通後使用状態を特定し、特定した融通前使用状態および融通後使用状態に対応する条件６０３と条件６０３に対応する使用状態変更時間算出式５０３とに基づいて使用状態変更作業時間を算出し、算出した使用状態変更作業時間と融通元ユーザの予約要求１３３に含まれる期間２０４と融通先ユーザの予約要求１３３に含まれる期間２０４とに基づいて、融通先ユーザが融通元ユーザから融通を受けて使用可能なリソースの量を算出し、融通管理部１０６が、融通案作成部１０５が算出した量のリソースを融通元ユーザから融通先ユーザに融通させるので、リソースを確実に融通させることができる。
【０１６６】
例えば、融通元ユーザが指定した再開時刻を越えて、融通先ユーザがリソースを使用してしまう（融通元ユーザのリソースの再開時刻を保証できなくなる）ことがなくなる。図２１は、融通元ユーザのリソースの再開時刻を保証できなくなる場合の様子を示す図である。図２１に示すように、融通元ユーザＸは、再開時刻として「２００９／７／３０／９：００」を指定しているが、融通先ユーザＹがリソースを使用する期間が３日間であり、使用状態変更作業時間が１日以上かかるような場合において、融通を開始する時刻を「２００９／７／２６／９：００」とした場合には、再開時刻に、融通元ユーザＸにリソースを使用させることができなくなってしまうという問題がなくなる。すなわち、融通元ユーザが指定した要求と融通先ユーザが指定した要求を共に満たすようにリソースを融通させることができる。
【０１６７】
（第２の実施の形態）
上述した第１の実施の形態においては、使用状態変更作業時間を算出することによって、融通可能なリソースの融通案リスト２３０１を作成し、リソースを確実に融通させることとした。しかし、使用状態変更作業時間は、融通元ユーザが予約要求１３３として指定したリソースの容量や、リソースの使用状態等によって変わり得る。そこで、本実施の形態においては、融通案を作成した後、使用状態変更作業時間の実測結果（後述）にしたがって、融通案を作成した過程で算出した使用状態変更作業時間の算出方法を変更し、使用状態変更作業時間の算出精度を向上させる場合について説明する。
【０１６８】
図２２は、第２の実施の形態におけるリソーススケジュールシステム５０００の構成を示すブロック図である。図２２に示すように、ＰＣ８０００は、メモリ使用状態変更作業時間実績情報２１０１と、第１の実施の形態におけるイベント受信処理部１０４とは異なるイベント受信処理部８１０４と、第１の実施の形態における使用状態作業時間算出部１１７とは異なる使用状態作業時間算出部８１７０と、を備えている点で、第１の実施の形態におけるＰＣ１００とは異なっている。以下では、第１の実施の形態におけるＰＣ１００と同一の構成要素については同一の符号を付して、その説明を省略している。
【０１６９】
イベント受信処理部８１０４は、第１の実施の形態におけるイベント受信処理部１０４と同様の処理を行うほか、リソーススケジュールシステム５０００が有するサーバ１２１等から、使用状態変更作業時間実績情報２１０１（後述）を受信する。
【０１７０】
使用状態作業時間算出部８１７０は、第１の実施の形態における使用状態作業時間算出部１１７と同様の処理を行うほか、使用状態変更作業時間算出式リスト更新処理を行う。使用状態変更作業時間算出式リスト更新処理の具体的な内容については後述する。
【０１７１】
使用状態変更作業時間実績情報２１０１は、図１に示したサーバ１２１Ａやサーバ１２１Ｂ、あるいはネットワーク機器１２２やストレージ機器１２３に対して、リソーススケジュールシステム１０００が、リソースを融通させた場合における使用状態変更作業時間の過去の実績を記憶するものである。以下に示す使用状態変更作業時間実績情報２１０１の各項目の内容は、管理者１４１等が過去の実績にしたがって、あらかじめ設定されているものである。
【０１７２】
図２３は、使用状態変更作業時間実績情報２１０１の例を示す図である。図２３に示すように、使用状態変更作業時間実績情報２１０１は、使用状態変更作業主体２１０２と、使用状態変更作業内容２１０３と、使用状態変更作業時間実績値２１０４とを含んでいる。これらの具体的な内容については、後述する使用状態変更作業時間算出式リスト更新処理を説明する際にあわせて説明する。
【０１７３】
図２４は、使用状態変更作業時間算出式リスト更新処理の処理手順を示すフローチャートである。図２４に示すように、リソーススケジュールシステム５０００が有するサーバ１２１等が、ＰＣ８０００に使用状態変更作業時間実績情報２１０１を送信する（ステップ２２０１）。使用状態変更作業時間実績情報２１０１は、例えば、不図示のタイマによって、プロセッサ１２４Ａ等が定期的に送信するものとする。
【０１７４】
その後、ＰＣ８０００のイベント受信処理部８１０４は、使用状態変更作業時間実績情報２１０１を受信し（ステップ２２０２）、使用状態作業時間算出部８１７０は、イベント受信処理部８１０４が受信した使用状態変更作業時間実績情報２１０１に含まれる使用状態変更作業主体２１０２と使用状態変更作業内容２１０３と使用状態変更作業時間実績値２１０４とを参照する。
【０１７５】
なお、図２３に示した使用状態変更作業時間実績情報２１０１には、複数のレコードが含まれているが、以下では、使用状態変更作業主体２１０２が「仮想サーバ」であり、使用状態変更作業内容２１０３が「メモリ解放」である場合について説明し、使用状態変更作業時間実測値２１０４が「８分」である場合について説明している。
【０１７６】
その後、使用状態変更作業時間算出部８１７０は、図１１に示した使用状態変更作業候補リスト１１５を参照し、ステップＳ２０２２で受信した使用状態変更作業主体２１０２及び使用状態変更作業内容２１０３に対応する使用状態変更作業時間予測値１１０３を取得し（ステップ２２０３）、
そして、使用状態変更作業時間算出部８１７０は、ステップＳ２２０２で受信した使用状態変更作業時間実績値２１０４と、ステップＳ２２０３で取得した使用状態変更作業時間予測値１１０３とを用いて、その差分を求める（ステップ２２０４）。例えば、図２３に示した使用状態変更作業時間実績値２１０４「８分」と図１１に示した使用状態変更作業時間予測値１１０３「１．２分」との差分「６．８分」を求める。なお、以下では、これらの差分を求めているが、例えば、これらの比率を求めることによって、使用状態変更作業時間予測値１１０３を使用状態変更作業時間実績値２１０４に修正することとしても良い。
【０１７７】
その後、使用状態変更作業時間算出部８１７０は、図５に示した使用状態変更作業時間算出リスト１０９を参照し、ステップＳ２２０２で受信した使用状態変更主体２１０２及び使用状態変更作業内容２１０３に対応するレコードを検索する（ステップ２２０５）。
【０１７８】
例えば、図２３に示した使用状態変更作業時間実績情報２１０１を受信した場合には、使用状態変更作業時間算出リスト１０９から、使用状態変更作業主体５０１が「仮想サーバ」であり、かつ使用状態変更作業内容５０２が「メモリ解放」であるレコードを検索する。
【０１７９】
そして、使用状態変更作業時間算出部８１７０は、検索したレコードに含まれる使用状態変更作業時間算出式５０３に、ステップＳ２２０４で求めた差分を代入し、使用状態変更作業時間の差分を求める（ステップ２２０６）。
【０１８０】
このステップＳ２２０６の処理が終了すると、図２２に示した使用状態変更作業時間算出式リスト更新処理の全ての処理が終了する。そして、管理者１４１等は、このように算出された使用状態変更作業時間の差分を参照することによって、使用状態変更作業時間予測値１１０３を算出する元となる使用状態変更作業時間算出式５０３を、より現実的な使用状態変更作業時間に近づけるように修正することができる。
【０１８１】
このように、イベント受信部８１０４が、さらに、外部から使用状態変更作業時間の実績を示す使用状態変更作業時間実績情報２１０１を受信し、融通案作成部１０５（使用状態変更作業時間算出部８１７０）が、算出した使用状態変更作業時間とイベント受信部８１０４が受信した使用状態変更作業実績情報２１０１との差分を求めるので、使用状態変更作業時間算出精度が向上し、リソースをより確実に融通させることができる。
【０１８２】
なお、上述した第１の実施の形態または第２の実施の形態においては、融通案作成部１０５が融通案リスト２３０１を作成した場合に、融通管理部１０６が融通案リスト２３０１を融通元ユーザおよび融通先ユーザに送信することとした。しかし、融通案リスト２３０１を受信した融通元ユーザおよび融通先ユーザによっては、承認要求に対する返信を失念してしまう場合や、融通元ユーザもしくは融通先ユーザが行うべき準備作業がある場合も存在する。そこで、融通管理部１０６が、融通案作成部１０５が作成した融通案リスト２３０１に、承認要求に対する返信期限を示す有効期間を算出し、算出した有効期間を融通案リスト２３０１に付加した上で、融通案リスト２３０１を送信する場合について説明する。
【０１８３】
この場合、融通先ユーザが現実にリソースの融通を受ける場合に、例えば、融通先ユーザは、所管するシステムのバックアップ等の準備作業をいつまでに実行しておく必要があるか否か等を事前に確認することができる。したがって、融通先ユーザは、融通を受けるタイミングまでに間に合わなくなってしまう等、上述した準備作業が無駄になってしまうことを防止することができる。これと同様に、融通元ユーザにおいても、融通前における動作中のシステムのバックアップ等の準備作業を、いつまでに実行しておく必要があるか等を事前に確認することができる。
【０１８４】
例えば、融通管理部１０６は、図１３に示した融通案作成適用処理のステップＳ１３０７において、融通案作成部１０５が図１５に示した融通案作成処理のステップＳ１５０６において現在の時刻からトータルの使用状態変更作業時間と使用権限譲渡条件リスト１０７に含まれる期間３０４が経過した場合に、融通元ユーザがリソースの使用を再開する時刻が過ぎていないか否か、を判定した場合において、さらに、現在の時刻からトータルの使用状態変更作業時間が経過してから図３に示した使用権限譲渡条件リスト１０７に含まれる期間３０４までの時間からあらかじめ定められた予備の期間を差し引いた時間を算出し、算出した時間を有効期間として融通案リストに設定する。
【０１８５】
図２５は、このように設定された融通案リスト８３０１の例を示す図である。図２５に示すように、融通案リスト８３０１には、返信有効期限８３０６として、融通内容２３０５に含まれる時刻「２００９／ｘｘ／ｗｗ」よりも前の時刻である「２００９／ｘｘ／ｚｚ」（ｗｗ＞ｚｚ）が設定されている。
【０１８６】
なお、融通管理部１０６は、返信有効期限８３０６に示された時刻を経過するまでに承認要求に対して返信を受けていない場合には、融通案リスト８３０１に含まれる融通案番号２３０１の融通案を、図１０に示した融通元融通先候補リスト１１４から削除する。この場合、融通管理部１０６は、返信有効期限８３０６に示された時刻を経過するまでに、承認要求に対して拒絶する旨の返信を受けた場合には、直ちに融通案リスト８３０１に含まれる融通案番号２３０１の融通案を、図１０に示した融通元融通先候補リスト１１４から削除してもよい。
【０１８７】
承認要求に対して拒絶する旨の返信としては、例えば、図２６に示したように、融通案番号２４０２と、ユーザ名２４０３と、融通承認２４０４と、を含む融通承認返信情報２４０１のようなレイアウトとすることができる。これらの符号２４０２〜２４０３に示した各項目は、図２５に示した融通案リスト８３０１に含まれる符号２３０２、２３０４の各値が設定される。
【０１８８】
このように、融通管理部１０６は、リソースの融通の許諾を求める旨とともに、融通案作成部１０５が算出した使用状態変更作業時間が、現在時刻から融通元ユーザの予約要求１３３に含まれる期間２０４内であるか否かを判定し、融通案作成部１０５が算出した使用状態変更作業時間が、現在時刻から融通元ユーザの予約要求１３３に含まれる期間２０４内であると判定した場合、融通元ユーザの予約要求１３３に含まれる期間２０４と現在時刻に使用状態変更作業時間を加えた時間との差分期間を算出し、現在時刻に差分期間を経過するまでの期間である有効期間を送信するので、融通先ユーザが融通を受ける前に行うべき準備作業がある場合であっても、リソースを確実に融通させることができる。
【０１８９】
なお、本実施形態のＰＣ１００、ＰＣ８０００において実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１９０】
また、上述したプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、上述したプログラムを、インターネット等のネットワーク経由で提供または配布するように構成しても良い。さらに、また、本実施形態のプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１９１】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【符号の説明】
【０１９２】
１０００、５０００：リソーススケジュールシステム、１００、８０００：ＰＣ、１０１：プロセッサ、：１０２、８０２０：メモリ、１０３：ＮＩＣ、１０４：イベント受信処理部、１０５：融通案作成部、１０６：融通管理部、１０７：使用権限譲渡条件リスト、１０８：融通要求リスト、１０９：使用状態変更作業時間算出式リスト、１１０：使用状態変更作業工程リスト、１１１：リソースリスト、１１２：使用権限予約リスト、１１３：融通案作成開始フラグ、１１４：融通元融通先候補リスト、１１５：融通作業候補リスト、１１６：使用可能リソースクラスリスト、１１７、８１７０：使用状態変更作業時間算出部、２１０１：使用状態変更期間作業実績情報、１２１：物理サーバ、１２２：ネットワーク機器、１２３：ストレージ機器、１２４：プロセッサ（物理サーバ）、１２５：メモリ（物理サーバ）、１３０：ユーザ端末、：１３１：ユーザ、１４０：管理端末、１５０：ディスク記憶媒体、１５１：磁気記憶媒体。
【図１】
2011123812.tif 000003
【図２】
2011123812.tif 000004
【図３】
2011123812.tif 000005
【図４】
2011123812.tif 000006
【図５】
2011123812.tif 000007
【図６】
2011123812.tif 000008
【図７】
2011123812.tif 000009
【図８】
2011123812.tif 000010
【図９】
2011123812.tif 000011
【図１０】
2011123812.tif 000012
【図１１】
2011123812.tif 000013
【図１２】
2011123812.tif 000014
【図１３】
2011123812.tif 000015
【図１４】
2011123812.tif 000016
【図１５】
2011123812.tif 000017
【図１６】
2011123812.tif 000018
【図１７】
2011123812.tif 000019
【図１８】
2011123812.tif 000020
【図１９】
2011123812.tif 000021
【図２０】
2011123812.tif 000022
【図２１】
2011123812.tif 000023
【図２２】
2011123812.tif 000024
【図２３】
2011123812.tif 000025
【図２４】
2011123812.tif 000026
【図２５】
2011123812.tif 000027
【図２６】
2011123812.tif 000028
【図２７】
2011123812.tif 000029