(57)【要約】【課題】リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行う。【解決手段】リソース共有システム１０は、複数のユーザ２０（ユーザ端末）でリソース３０を共有する。リソース予約管理装置４２は、ユーザ２０からリソース３０の利用条件を含む予約要求を受け付け、リソース共有システム１０内の所定のリソース３０に利用条件に沿った利用予約を設定する予約設定部４０２と、予約を設定したリソース３０が利用不可となった場合に、リソース共有システム１０内の他のリソース３０に利用予約を再設定する予約変更部４０４とを備える。予約変更部４０４は、再設定すべき利用予約に対して他のリソース３０のリソース量が不足する場合、利用条件を変更した上で他のリソース３０に利用予約を再設定する。【選択図】図６
2019211889.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理装置であって、
前記ユーザ端末から前記リソースの利用条件を含む予約要求を受け付け、前記リソース共有システム内の所定のリソースに前記利用条件に沿った利用予約を設定する予約設定部と、
前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更部と、を備え、
前記予約変更部は、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、
ことを特徴とするリソース予約管理装置。
【請求項２】
前記予約変更部は、前記ユーザ端末に対して前記利用条件の変更案を含む通知を行い、前記ユーザ端末から前記変更案を承認する旨の情報が得られた場合に、前記変更案に沿って前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項３】
前記予約要求は、前記利用条件に沿った前記利用予約が設定できない場合に適用される下限利用条件を含んでおり、
前記予約変更部は、前記下限利用条件に基づいて前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項４】
前記利用条件は、複数の項目を含んでおり、
前記予約要求は、前記複数の項目の優先順位を含んでおり、
前記予約変更部は、前記優先順位の高い項目ほど前記予約要求に含まれる利用条件からの変更度合いが小さくなるように前記利用条件を変更する、
ことを特徴とする請求項３に記載のリソース予約管理装置。
【請求項５】
前記予約変更部は、Ｂｉｎ  Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な前記利用予約の数が最大となるように前記利用条件を変更する、
ことを特徴とする請求項３に記載のリソース予約管理装置。
【請求項６】
前記予約要求は、前記利用条件に沿った前記利用予約が設定できない場合に適用される下限利用条件を含んでおり、
前記予約変更部は、前記ユーザ端末に対して前記利用条件の変更案を含む通知を行い、前記ユーザ端末から前記変更案を承認する旨の情報を得られた場合には、前記変更案に沿って前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定し、前記ユーザ端末から前記変更案を承認する旨の情報が得られない場合には、前記下限利用条件に基づいて前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項７】
前記予約設定部は、前記予約変更部により前記利用予約の再設定が行われている間は、新規の前記予約要求の受け付けを停止する、
ことを特徴とする請求項１から請求項６のいずれか１項に記載のリソース予約管理装置。
【請求項８】
複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理方法であって、
前記ユーザ端末から前記リソースの利用条件を含む予約要求を受け付け、所定のリソースに対して前記利用条件に沿った利用予約を設定する予約設定工程と、
前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更工程と、を含み、
前記予約変更工程では、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、
ことを特徴とするリソース予約管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のユーザでリソースを共有するリソース共有システムにおけるリソース予約管理装置およびリソース予約管理方法に関する。
【背景技術】
【０００２】
従来、IaaS（Infrastructure as a Service）のようなクラウドサービスにおいて、複数のユーザ（サービスやアプリケーション等）でリソース（コンピュート、ネットワーク、ストレージ等）を共有し、各ユーザが必要な時に必要な分だけリソースを利用するモデルが普及している。
一方で、共有リソースは有限であるため、ユーザが確実にリソースを利用できるように、リソースの予約を可能とする提案もなされている（例えば、非特許文献１および非特許文献２参照）。特に、リソースが限られる小規模プライベートクラウドサービスでは、予約の重要性がより大きくなる。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“Blazar, the OpenStack Reservation Service”［online］、［平成３０年５月１４日検索］、インターネット<ＵＲＬ：https://docs.openstack.org/blazar/latest/>
【非特許文献２】“Amazon EC2 リザーブドインスタンス”［online］、［平成３０年５月１４日検索］、インターネット<ＵＲＬ：https://aws.amazon.com/jp/ec2/pricing/reserved-instances/>
【非特許文献３】Weijia Song, et. al, “Adaptive Resource Provisioning for the Cloud Using Online Bin Packing”, IEEE Transactions on Computers, Volume: 63, Issue: 11, Nov. 2014
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述したようなリソース共有システムにおいて、予約済みのリソースが故障した場合には、空きのある他のリソース（代替リソース）に当該予約を振り替えることで、ユーザへの影響を解消ないし低減することができる。
しかしながら、システム内の空きリソースが足りない場合、一部の予約が不成立（予約したのにリソースを使えない状況）になる可能性があるという課題がある。
【０００５】
本発明は、このような事情に鑑みなされたものであり、リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行うことを目的とする。
【課題を解決するための手段】
【０００６】
上述の目的を達成するため、請求項１に記載の発明は、複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理装置であって、前記ユーザ端末から前記リソースの利用条件を含む予約要求を受け付け、前記リソース共有システム内の所定のリソースに前記利用条件に沿った利用予約を設定する予約設定部と、前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更部と、を備え、前記予約変更部が、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、ことを特徴とするリソース予約管理装置とした。
【０００７】
また、請求項８に記載の発明は、複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理方法であって、前記ユーザ端末から前記リソースの利用条件を含む予約要求を受け付け、所定のリソースに対して前記利用条件に沿った利用予約を設定する予約設定工程と、前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更工程と、を含み、前記予約変更工程では、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、ことを特徴とするリソース予約管理方法とした。
【０００８】
このようにすることで、所定のリソースが利用不可となり、かつ再設定すべき利用予約に対して他のリソースのリソース量が不足する場合に、利用予約が不成立となることを回避して、ユーザの利便性を向上させることができる。
【０００９】
また、請求項２に記載の発明は、前記予約変更部が、前記ユーザ端末に対して前記利用条件の変更案を含む通知を行い、前記ユーザ端末から前記変更案を承認する旨の情報が得られた場合に、前記変更案に沿って前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１０】
このようにすることで、利用条件の変更内容についてユーザ端末から承認を受けた上で予約の再設定を行うことができ、ユーザの意思に沿った利用条件の変更を行うことができる。特に、ユーザの状況が刻々と変化し、許容できる利用条件の変更量が変化する場合などに有利である。
【００１１】
また、請求項３に記載の発明は、前記予約要求が、前記利用条件に沿った前記利用予約が設定できない場合に適用される下限利用条件を含んでおり、前記予約変更部が、前記下限利用条件に基づいて前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１２】
このようにすることで、予めユーザ端末において指定された下限利用条件の範囲内で利用条件を変更することができ、利用条件の変更内容にユーザの意思を反映させることができる。また、下限利用条件は予約要求により取得するので、予約の再設定時にユーザに確認するのと比較して、迅速に予約の再設定を行うことができる。
【００１３】
また、請求項４に記載の発明は、前記利用条件が、複数の項目を含んでおり、前記予約要求は、前記複数の項目の優先順位を含んでおり、前記予約変更部が、前記優先順位の高い項目ほど前記予約要求に含まれる利用条件からの変更度合いが小さくなるように前記利用条件を変更する、ことを特徴とする請求項３に記載のリソース予約管理装置とした。
【００１４】
このようにすることで、利用条件のうち特定の項目を優先させることができ、ユーザの利便性を向上させることができる。
【００１５】
また、請求項５に記載の発明は、前記予約変更部が、Ｂｉｎ  Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な前記利用予約の数が最大となるように前記利用条件を変更する、ことを特徴とする請求項３に記載のリソース予約管理装置とした。
【００１６】
このようにすることで、リソース共有システム全体で予約を最適化することができ、特定のユーザのみが不利益（予約不成立など）を被るのを防止することができる。
【００１７】
また、請求項６に記載の発明は、前記予約要求が、前記利用条件に沿った前記利用予約が設定できない場合に適用される下限利用条件を含んでおり、前記予約変更部が、前記ユーザ端末に対して前記利用条件の変更案を含む通知を行い、前記ユーザ端末から前記変更案を承認する旨の情報を得られた場合には、前記変更案に沿って前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定し、前記ユーザ端末から前記変更案を承認する旨の情報が得られない場合には、前記下限利用条件に基づいて前記利用条件を変更した上で前記他のリソースに前記利用予約を再設定する、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１８】
このようにすることで、利用予約の再設定時におけるユーザの利便性（ユーザの意思に沿った利用条件の変更）と迅速性とを両立させることができる。
【００１９】
また、請求項７に記載の発明は、前記予約設定部が、前記予約変更部により前記利用予約の再設定が行われている間は、新規の前記予約要求の受け付けを停止する、ことを特徴とする請求項１から請求項６のいずれか１項に記載のリソース予約管理装置とした。
【００２０】
このようにすることで、新規の予約により元々設定されていた利用予約の振り替えが不成立となることを防止することができる。
【発明の効果】
【００２１】
本発明によれば、リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行うことができる。
【図面の簡単な説明】
【００２２】
【図１】本実施形態に係るリソース共有システムの構成例を示す図である。
【図２】本実施形態に係るリソース予約管理装置の機能的構成を示すブロック図である。
【図３】リソースの予約要求の一例を模式的に示す説明図である。
【図４】リソースの予約テーブルを模式的に示す説明図である。
【図５】リソースの予約テーブルを模式的に示す説明図である。
【図６】本実施形態に係るリソース予約管理装置による予約受付処理の手順を示すフローチャートである。
【図７】手法１による予約振り替え時の利用条件の変更処理の手順を示すフローチャートである。
【図８】手法３による予約振り替え時の利用条件の変更処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００２３】
以下に添付図面を参照して、本発明に係るリソース予約管理装置４２およびリソース予約管理方法の好適な実施の形態（以下、「実施形態」と称する。）を詳細に説明する。
図１は、本実施形態に係るリソース共有システム１０の構成例を示す図である。
【００２４】
リソース共有システム１０は、複数のユーザ２０で複数のリソース３０を共有するためのシステムである。
それぞれのユーザ２０は、例えば、リソース共有を実現するためのアプリケーションが格納されたユーザ端末（図示省略）である。リソース３０は、例えばベアメタル、仮想マシン、コンテナ、各種ストレージ等である。各リソース３０は、共通ネットワーク３２に接続されており、例えばＯｐｅｎＳｔａｃｋのようなクラウドオペレーティングシステム３４により管理されている。
【００２５】
クラウドオペレーティングシステム３４は、システム管理装置４０上のダッシュボードを通じて管理され、管理者がＷＥＢインターフェイスを通じてリソース３０をプロビジョニングできるように構成されている。また、システム管理装置４０は、リソース共有システム１０のモニタリングやツールの提供を行う。
ここで、リソース共有システム１０では、Ｂｌａｚａｒのようなサービスを用いてユーザ２０によるリソース３０の予約が可能である。本実施形態では、システム管理装置４０は、リソース３０の予約を管理するリソース予約管理装置４２として機能する。
【００２６】
図２は、本実施形態に係るリソース予約管理装置４２の機能的構成を示すブロック図である。
リソース予約管理装置４２は、制御手段、記憶手段および入出力手段（いずれも図示省略）を備えるコンピュータ等により実現される。そして、制御手段は、予約設定部４０２と、予約変更部４０４とを備える。
【００２７】
予約設定部４０２は、ユーザ２０からリソース３０の利用条件を含む予約要求を受け付け、リソース共有システム１０内の所定のリソース３０に、利用条件に沿った利用予約を設定する。なお、予約設定部４０２は、後述する予約変更部４０４により利用予約の再設定が行われている間は、新規の予約要求の受け付けを停止する。
【００２８】
予約変更部４０４は、所定のリソース３０が利用不可となった場合に、リソース共有システム１０内の他のリソース３０に利用予約を再設定（振り替え）する。リソース３０が利用不可となる場合とは、例えばリソース３０が故障した場合やリソース３０とユーザ２０との間のネットワークに障害が生じた場合などである。以下、利用不可となったリソース３０に設定されていた予約を「変更対象予約」という。
【００２９】
図３は、リソース３０の予約要求の一例を模式的に示す説明図である。
ユーザ２０からの予約要求には、例えば当該予約を識別する予約識別子（図３の例では「プロジェクトＡ」）、リソース３０を利用する日時（図３の例では「２０１８／０２／１０／０：００〜２０１８／０２／１２／２３：５９」）、リソース３０を利用する期間（図３の例では「７２時間」）、利用するリソース３０の種類および容量（図３の例では「４コア、８ＧＢ  ＲＡＭ、１００ＧＢ  ｄｉｓｋのデバイス４台」）などが含まれている。
【００３０】
予約要求を受けた予約設定部４０２は、リソース共有システム１０内のリソース３０に、利用条件に沿った利用予約を設定する。各リソース３０の予約状態は、図４に示すような予約テーブルで管理され、予約テーブルに沿って、ユーザ２０にリソース３０の利用権が与えられる。
【００３１】
図４は、リソース３０の予約テーブルを模式的に示す説明図である。
図４の例では、リソース３０として４台のホストマシン（ホスト１〜ホスト４）を示している。
例えばホスト２は、日曜日はフリー（空き状態）であり、月曜日から火曜日にかけてはプロジェクトＡ、水曜日から木曜日にかけてはプロジェクトＢ、金曜日から土曜日にかけてはプロジェクトＤにより予約されている。
また、リソース量が足りるのであれば、１つのリソース３０を複数のユーザ２０が同時に予約することも可能である。例えばホスト１は、日曜日から火曜日にかけてプロジェクトＡおよびプロジェクトＢにより予約されている。すなわち、１つのリソース３０を部分的に予約することも可能である。
【００３２】
ここで、図４のような予約状態である時にホスト１とホスト２が故障して利用不可となった場合、ホスト１とホスト２に設定されている利用予約、すなわち図５で太実線に囲まれた予約が変更対象予約となる。この場合、予約変更部４０４は、基本的には故障していない他のリソース３０（ホスト３およびホスト４）に予約を振り替える。
例えば図示の例では、図５で太点線に囲まれた領域、すなわちホスト４は全時間帯が、ホスト３は日曜日が、それぞれフリー（空き状態）であるため、予約変更部４０４は、これら空きのあるリソース３０へと変更対象予約を割り振る。しかしながら、ホスト１〜ホスト４のスペックが同等の場合、月曜日以降は空きのあるリソース３０が変更対象予約の実行に必要なリソース量の半分となり、全ての変更対象予約を振り替えることはできない。
【００３３】
このように、再設定すべき利用予約に対して故障していないリソース３０（他のリソース３０）のリソース量が不足する場合、予約変更部４０４は、利用予約の利用条件を変更した上で他のリソース３０に利用予約を再設定する。
利用予約の利用条件を変更することにより、限られたリソース３０をより効率的に利用することができ、リソース３０が利用不可となったことによるユーザ２０への影響を最小限にすることができる。
【００３４】
以下、より詳細に予約変更部４０４による予約変更処理ついて説明するが、これに先立って、リソース予約管理装置４２による予約受付処理について説明する。
図６は、リソース予約管理装置４２による予約受付処理の手順を示すフローチャートである。
【００３５】
まず、リソース予約管理装置４２の予約設定部４０２は、ユーザ２０（ユーザ端末）から予約要求を受信したか否かを判定する（ステップＳ１００）。そして、受信した場合（ステップＳ１００：Ｙｅｓ）、予約設定部４０２は、所定のリソース（ユーザ２０が指定した種類のリソース３０）に利用予約を設定する（ステップＳ１０２）。一方、予約設定部４０２は、予約要求を受信していない場合には（ステップＳ１００：Ｎｏ）、受信するまで待つ。
【００３６】
予約設定部４０２は、利用予約を設定したリソース３０に故障等が発生せず、利用可能な場合は（ステップＳ１０４：Ｙｅｓ）、ステップＳ１００に戻り、利用予約の受付を継続する。なお、図示は省略しているが、利用予約に設定された利用日時となった場合、リソース予約管理装置４２は適宜ユーザ２０にリソース３０の利用権を与える（予約の実行）。
【００３７】
一方、利用予約を設定したリソース３０に故障等が発生し、利用不可となった場合（ステップＳ１０４：Ｎｏ）、予約設定部４０２は、新規の予約要求の受付を停止する（ステップＳ１０６）。
これは、新規予約の受付よりも、利用不可となったリソース３０に入っていた利用予約（変更対象予約）の振り替えを優先させるためである。このようにすることで、新規の予約により元々設定されていた利用予約の振り替えが不成立となることを防止することができる。
【００３８】
また、予約変更部４０４は、利用可能なリソース３０（他のリソース３０）の空き状況の情報を取得し（ステップＳ１０８）、利用不可となったリソース３０に入っていた利用予約を、予約時の利用条件（利用日時やリソース量など）に沿った形で他のリソース３０に振り替え可能か否かを判断する（ステップＳ１１０）。
【００３９】
リソース３０に空きが十分ある場合など、予約時の利用条件に沿った形で他のリソース３０に振り替え可能な場合（ステップＳ１１０：Ｙｅｓ）、予約変更部４０４は、予約時の利用条件で他のリソース３０に変更対象予約を再設定する（ステップＳ１１２）。
【００４０】
一方、リソース３０に空きが少ない場合など、予約時の利用条件に沿った形での振り替えが不可能な場合は（ステップＳ１１０：Ｎｏ）、予約変更部４０４は、変更対象予約の利用条件を変更した上で他のリソース３０に予約を再設定する（ステップＳ１１４）。利用条件の変更方法の詳細は後述する。
利用予約の振り替えが完了すると、予約設定部４０２は新規の予約要求の受付を再開する（ステップＳ１１６）。なお、予約受付再開後は、利用可能なリソース３０にのみ利用予約を割り振る。
【００４１】
つぎに、予約振り替え時の利用条件の変更方法（図６のステップＳ１１４）の詳細について説明する。
本実施形態では、予約振り替え時の利用条件の変更方法として以下の３つの手法を例示する。
手法１：ユーザ２０に問い合わせた上で変更
手法２：予約変更ポリシーに基づく変更
手法３：手法１と手法２の混合型
上記手法１〜３のいずれを採用するかは、例えばリソース共有システム１０の運営者が決定し、予約変更部４０４に設定しておく。
以下、各方法の詳細について説明する。
【００４２】
＜手法１：ユーザ２０に問い合わせた上で変更＞
手法１では、予約時の利用条件に沿った形での振り替えが不可能な場合、ユーザ２０に対し予約が不成立となる可能性を通知する。この通知には、利用条件の変更案が含まれている。利用条件の変更案とは、例えば「利用開始時間を１時間遅らせれば予約可」、「リソースの台数を１台減らせば予約可」などのようなサジェスト情報である。また、例えばリソース３０の空き状況の一覧の情報を送信し、ユーザ２０側で予約の変更先（変更した利用条件）を決定するようにしてもよい。
【００４３】
通知を受けたユーザ２０が変更案を承認した場合（例えば、サジェスト情報に基づいて予約条件を変更し、予約変更要求を送信した場合）、予約変更部４０４は、変更案に沿った内容で他のリソース３０に利用予約の振り替えを行う。
すなわち、手法１では、予約変更部４０４が、ユーザ２０に対して利用条件の変更案を含む通知を行い、ユーザ２０により変更案の承認を得られた場合に、当該変更案に沿って利用条件を変更した上で利用可能な他のリソース３０に利用予約を再設定する。
このようにすることで、利用条件の変更内容についてユーザ２０から承認を受けた上で予約の再設定を行うことができ、ユーザの意思に沿った利用条件の変更を行うことができる。特に、ユーザ側の状況が刻々と変化し、許容できる利用条件の変更量が変化する場合などに有利である。
【００４４】
図７は、手法１による予約振り替え時の利用条件の変更処理の手順を示すフローチャートである。
予約変更部４０４は、図６のステップＳ１０８で取得した利用可能なリソース３０（他のリソース３０）の空き状況に基づいて、変更対象予約の利用条件の変更案を算出し（ステップＳ２００）、変更案を含む通知をユーザ２０に送信する（ステップＳ２０２）。
ユーザ２０が変更案を承認した場合は（ステップＳ２０４：Ｙｅｓ）、変更案に沿って利用条件を変更した上で予約を再設定する（ステップＳ２０６）。
なお、変更案が承認されない場合は（ステップＳ２０４：Ｎｏ）、他の変更案を算出して再送信してもよいし、予約を取り消してもよい。
【００４５】
＜手法２：予約変更ポリシーに基づく変更＞
手法２では、予約ごとに事前に予約変更ポリシーを設定しておき、このポリシーに従って予約変更部４０４が自動的に利用条件を変更し、予約を再設定する。
より詳細には、ユーザ２０は予約要求時に利用条件（利用日時、利用期間、リソース量など）の最低要件（下限利用条件）を設定しておく。下限利用条件の設定例としては、例えば「遅くとも〇日△時までに利用を開始（または終了）」（利用日時要件）、「最短でも□時間は利用時間を確保」（利用期間条件）、「少なくとも２コアのホストを３台確保」（リソース量条件）などのような形が挙げられる。
【００４６】
予約変更部４０４は、予約時の利用条件に沿った形での振り替えが不可能な場合、最低要件を満たせる範囲で変更対象予約の利用条件を変更して予約の再設定を行う。また、下限要件条件を満たせない場合は、例えば予約の再設定を行わず、予約の取り消し（変更失敗）をユーザ２０に通知する。
すなわち、手法２では、ユーザ２０からの予約要求は、当初の利用条件に沿った利用予約が設定できない場合に適用される下限利用条件を含んでおり、予約変更部４０４は、下限利用条件に基づいて利用条件を変更した上で利用可能な他のリソース３０に利用予約を再設定する。
【００４７】
このようにすることで、予めユーザ２０から指定された下限利用条件の範囲内で利用条件を変更することができ、利用条件の変更内容にユーザの意思を反映させることができる。また、下限利用条件は予約要求により取得するので、予約の再設定時にユーザ２０に確認するのと比較して、迅速に予約の再設定を行うことができる。
【００４８】
さらに、手法２を適用する場合において、以下のように「ユーザが指定する項目を優先する方法」と「システム全体を最適化する方法」とが採り得る。
【００４９】
（ユーザが指定する項目を優先する方法）
この手法では、下限利用条件の設定時に、ユーザ２０が特に重視する項目（優先項目）を設定し、予約変更部４０４は優先項目を優先して満たすように利用条件の変更を行う。
なお、利用条件の項目のうち、特定の項目のみを優先条件として指定してもよいし、各項目に対して優先順位を設定して優先度の大小を指定してもよい。
例えば利用期間が優先項目として指定された場合は、利用期間条件を満たすことを優先し、利用時刻やリソース量は妥協した形で利用条件を変更する。また、例えばリソース量が優先項目として設定された場合は、リソース量条件を満たすことを優先し、利用日時や利用期間は妥協した形で利用条件を変更する。
【００５０】
なお、優先項目を優先して満たす、とは、必ずしも「優先項目の変更を許可しない」ことを意味するものではなく、「優先項目の変更度合いを他の項目と比較して小さくする」という意味である。
すなわち、利用条件が複数の項目を含んでおり、予約要求が複数の項目の優先順位を含んでいる場合において、予約変更部４０４は、優先順位の高い項目ほどユーザ２０が指定する利用条件からの変更度合いが小さくなるように利用条件を変更するようにしてもよい。
このようにすることで、利用条件のうち特定の項目を優先させることができ、ユーザの利便性を向上させることができる。
【００５１】
（システム全体を最適化する方法）
この手法では、利用不可となったリソース３０に設定されている予約のみならず、利用可能なリソース３０に設定されている予約を含め、リソース共有システム１０に設定されている全ての予約を対象として下限利用条件に基づいて利用条件を変更し、予約の再設定を行う。
この場合、例えばＢｉｎ  ｐａｃｋｉｎｇ  のような全体最適化アルゴリズム（例えば、非特許文献３参照）を利用し、予約変更に失敗する予約数が最小となるように予約の再設定を行う。
【００５２】
すなわち、予約変更部４０４は、Ｂｉｎ  Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な利用予約の数が最大となるように利用条件を変更する。
このようにすることで、リソース共有システム１０全体で予約を最適化することができ、特定のユーザ２０のみが不利益（予約不成立など）を被るのを防止することができる。
【００５３】
＜手法３：手法１と手法２の混合型＞
手法３では、手法１のようなユーザ２０への問い合わせと、手法２のような予約変更ポリシーとを組み合わせて予約の変更を行う。
手法３では、手法２と同様に、予約要求時に下限利用条件を設定しておく。予約変更部４０４は、予約時の利用条件に沿った形での振り替えが不可能な場合、まず利用条件の変更案が含まれた通知をユーザ２０に送信する。ユーザ２０が変更案を承認した場合には、変更案に沿って利用条件を変更して予約を再設定する。一方、ユーザ２０から応答が所定期間（例えば３分間など）ない場合には、予約変更ポリシーに従って利用条件を変更して予約を再設定する。
【００５４】
すなわち、手法３では、ユーザ２０からの予約要求は、当初の利用条件に沿った利用予約が設定できない場合に適用される下限利用条件を含んでおり、予約変更部４０４は、ユーザ２０に対して利用条件の変更案を含む通知を送信する。そして、予約変更部４０４は、ユーザ２０から変更案の承認を得られた場合には、変更案に沿って利用条件を変更した上で他のリソース３０に利用予約を再設定し、ユーザ２０から変更案の承認を得られない場合には、下限利用条件に基づいて利用条件を変更した上で他のリソース３０に利用予約を再設定する。
このようにすることで、利用予約の再設定時におけるユーザの利便性（ユーザの意思に沿った利用条件の変更）と迅速性とを両立させることができる。
【００５５】
図８は、手法３による予約振り替え時の利用条件の変更処理の手順を示すフローチャートである。
予約変更部４０４は、図６のステップＳ１０８で取得した利用可能なリソース３０（他のリソース３０）の空き状況に基づいて、変更対象予約の利用条件の変更案を算出し（ステップＳ３００）、変更案を含む通知をユーザ２０に送信する（ステップＳ３０２）。
【００５６】
ユーザ２０が変更案を承認した場合は（ステップＳ３０４：Ｙｅｓ）、変更案に沿って利用条件を変更した上で予約を再設定する（ステップＳ３０６）。
一方、ユーザ２０からの応答が所定期間ない場合など、変更案が承認されない場合は（ステップＳ３０４：Ｎｏ）、図６のステップＳ１００で受信した予約要求に含まれる下限利用条件に基づいて利用条件を変更した上で予約を再設定する（ステップＳ３０８）。
【００５７】
以上説明したように、本実施形態に係るリソース共有システム１０のリソース予約管理装置４２によれば、所定のリソース３０が利用不可となり、かつ再設定すべき利用予約に対して空きのある他のリソース３０のリソース量が不足する場合に、利用予約が不成立となることを回避して、ユーザの利便性を向上させることができる。
【符号の説明】
【００５８】
１０  リソース共有システム
２０  ユーザ（ユーザ端末）
３０  リソース
３２  共通ネットワーク
３４  クラウドオペレーティングシステム
４０  システム管理装置
４２  リソース予約管理装置
４０２  予約設定部
４０４  予約変更部
【図１】
2019211889.tif 000003
【図２】
2019211889.tif 000004
【図３】
2019211889.tif 000005
【図４】
2019211889.tif 000006
【図５】
2019211889.tif 000007
【図６】
2019211889.tif 000008
【図７】
2019211889.tif 000009
【図８】
2019211889.tif 000010