JP5104871B2 - リソース割当管理プログラム、リソース割当管理装置およびリソース割当管理方法 - Google Patents

Description

この発明は、所定のリソースに対するオークション処理を所定の周期毎におこなって、顧客へのリソースの割当量を決定するリソース割当管理プログラム、リソース割当管理装置およびリソース割当管理方法に関し、特に、各周期への資金の配分を適切におこなうことができるリソース割当管理プログラム、リソース割当管理装置およびリソース割当管理方法に関する。

複数の顧客から委託されたネットワークサービスを運用するデータセンタでは、プロセッサの処理能力やネットワークの帯域といった各種リソースが有効活用されるように、これらのリソースを顧客の需要に合わせて配分することが非常に重要である。それぞれの顧客が必要とするリソース量は時間によって変動し、その変動パターンは顧客ごとに異なるため、データセンタは、各顧客へのリソースの割当量を周期的に変更する必要がある。

需要に合わせて顧客へのリソースの割当量を周期的に変更するための方式として、オークション方式が知られている（例えば、非特許文献１および非特許文献２を参照）。オークション方式とは、リソースを特定の大きさに分割した取引単位を対象として所定の周期毎にオークションを行い、各周期において各取引単位を、その取引単位に対して最も高い入札価格を提示した顧客へ割り当てていく方式である。このオークション方式では、各取引単位に対して自身の需要に応じた入札価格が顧客から示され、その結果として、各種リソースの配分が各顧客の需要に合わせて適切に行われる。

例えば、月初に多くのリソースを必要とする顧客Ａと、月末に多くのリソースを必要とする顧客Ｂとがいるものとする。この場合、顧客Ａは、月初に十分なリソースを落札するために月初のオークションへの資金配分を多くし、顧客Ｂは、月末に十分なリソースを落札するために月末のオークションへの資金配分を多くすることが期待される。このように、オークション方式のリソース割り当てにおいては、顧客が自身の需要パターンに合わせて資金配分を調整することにより、各顧客の需要に合わせたリソースの適切な配分が実現される。

Kevin Lai, Bernardo A. Huberman, Leslie Fine, "Tycoon: A Distributed Market-based Resource Allocation System", [online], HP Laboratories, 2004, [retrieved on 2007-08-02]. Retrieved from the Internet: <URL: http://arxiv.org/abs/cs.DC/0404013>. Carl A. Waldspurger, Tod Hogg, Bernardo A. Huberman, Jeffrey O. Kephart, Scott Stornetta, "Spawn: A Distributed Computational Economy", [online], 1991, [retrieved on 2007-08-02]. Retrieved from the Internet: <URL: http://citeseer.ist.psu.edu/512006.html>.

しかしながら、従来のオークション方式のリソース割り当てにおいては、顧客が、戦略の未熟さのために、自身が必要とするリソースを十分に獲得できないことがあるという問題があった。例えば、月末に多くのリソースを必要とする顧客が、月初において他の顧客に競り勝とうとして資金の大半を使用してしまい、多くのリソースを必要とする月末に資金が不足して十分なリソースを獲得できないことがあった。

このため、戦略が未熟な顧客でも自身の需要パターンに合わせて十分な量のリソースを確保することができるように、適切な資金の配分を自動的に決定する技術の実現が強く要望されていた。この発明は、上述した従来技術による問題点を解消するためになされたものであり、各周期への資金の配分を適切におこなうことができるリソース割当管理プログラム、リソース割当管理装置およびリソース割当管理方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一つの態様では、所定のリソースに対するオークション処理を所定の周期毎におこなって、顧客へのリソースの割当量を決定するリソース割当管理装置であって、各顧客の周期毎のリソースの必要量の予測値を示す需要予測情報と、各顧客がオークションに使用する資金の予測値を示す資金予測情報とに基づいて、各顧客がオークションに使用する資金を各周期にどのように配分すべきかを示す資金配分計画情報を生成する資金配分計画生成手段と、前記資金配分計画情報に基づいて、各顧客がオークションにおいて使用する資金の上限を決定する使用資金決定手段とを備えたことを特徴とする。

この発明の態様によれば、各顧客のリソースの需要の変動を示す情報と、各顧客がオークションに使用可能な資金に関する情報とに基づいてリソース割当管理装置が資金配分計画を生成することとしたので、個別の顧客の需要だけでなく、各顧客の需要の相対的な関係を考慮して、各周期への資金の配分を適切におこなうことができる。

また、本発明の他の態様では、上記の発明の態様において、前記使用資金決定手段は、顧客が設定したポリシーに基づいて該顧客がオークションにおいて使用する資金の上限を決定した場合のオークションのシミュレーション結果と、前記資金配分計画情報に基づいて該顧客がオークションにおいて使用する資金の上限を決定した場合のオークションのシミュレーション結果とを比較して、いずれか一方の上限を該顧客がオークションにおいて使用する資金の上限と決定することを特徴とする。

この発明の態様によれば、顧客が設定したポリシーによる予算配分によって得られた資金の上限と、自動作成された資金配分計画による予算配分によって得られた資金の上限とを比較してオークションに使用する資金の上限を決定することとしたので、顧客の個別的な要因を考慮した資金配分をおこなうことができる。

また、本発明の他の態様では、上記の発明の態様において、前記使用資金決定手段は、顧客が設定したポリシーに基づいて求めた上記上限と、前記資金配分計画情報に基づいて求めた上記上限とを選択肢として提示し、選択された方の上限を該顧客がオークションにおいて使用する資金の上限と決定することを特徴とする。

この発明の態様によれば、顧客が設定したポリシーによる予算配分によって得られた資金の上限と、自動作成された資金配分計画による予算配分によって得られた資金の上限とを選択肢として提示し、選択された方をオークションに使用する資金の上限を決定することとしたので、顧客の意思を反映した資金配分をおこなうことができる。

また、本発明の他の態様では、上記の発明の態様において、資金配分計画生成手段は、各顧客が出来るだけ多くのリソースを出来るだけ少ない資金で獲得できるように前記資金配分計画情報を生成することを特徴とする。

この発明の態様によれば、各顧客が出来るだけ多くのリソースを出来るだけ少ない資金で獲得できるように前記資金配分計画情報を生成することとしたので、全ての顧客が最適なコスト効率でリソースを獲得可能な資金配分を実現できる。

また、本発明の他の態様では、上記の発明の態様において、前記需要予測情報に基づいて前記資金予測情報を生成する資金予測情報生成手段をさらに備えたことを特徴とする。

この発明の態様によれば、需要予測の変動パターンに基づいて資金予測情報を生成することとしたので、リソースの必要量に適合した資金予測情報を生成することができる。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

本発明によれば、個別の顧客の需要だけでなく、各顧客の需要の相対的な関係を考慮して、全ての顧客の各周期への資金の配分を適切におこなうことができるという効果を奏する。

以下に、本発明に係るリソース割当管理プログラム、リソース割当管理装置およびリソース割当管理方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

まず、本実施例に係るリソース割当管理方法の概要について説明する。図１は、本実施例に係るリソース割当管理方法の概要を示す図である。同図に示すように、本実施例に係るリソース割当管理方法では、所定の周期（例えば、１日）毎にオークションを実行して顧客へのリソースの割当量を決定する。ここでいうリソースとは、プロセッサ、ネットワークの帯域、ストレージ装置の記憶領域等である。

データセンタのリソースは、予めポイントグループ（以下、「ＰＧ」という）と呼ばれる特定の大きさの取引単位に分割され、オークションは、ＰＧ毎に実行される。例えば、プロセッサについては、１０ＧＨｚ相当の処理能力が実現されるようにホストを組み合わせて構成されたＰＧ毎にオークションが行われる。

各周期における資金の動きを図２に示す。同図に示すように、顧客は、所定の期間毎にオークションに使用する資金を収入として得る。例えば、会員制サービスのようにユーザから月末毎に料金を徴収するタイプのネットワークサービスを提供している顧客は、月末毎に収入を獲得し、オンラインショッピングサイトのようにユーザから料金を都度徴収するタイプのネットワークサービスを提供している顧客は、毎日収入を獲得する。そして、顧客は、獲得した収入とそれまでのオークションの残金を、次に収入が得られるまでの各周期に入札金額として配分してオークションに使用する。

各周期のオークションにおいて、顧客が必要な量のリソースを確保するには、将来に渡る自身の需要の推移とオークションに使用可能な資金の推移を正確に把握しておき、これらの情報に基づいて資金を各周期に適切に配分することが必要である。しかしながら、これらの情報を正確に把握していたとしても、実際に必要なだけのリソースを確保できる可能性は、他の顧客が必要としているリソース量や、オークションに使用しようとしている資金量によっても変動する。このため、顧客が資金を各周期に適切に配分して十分なリソースを獲得することは、非常に困難であり、高度な戦略が求められる。

そこで、本実施例に係るリソース割当管理方法では、図１に示すように、全顧客のリソースの使用実績を把握しているデータセンタが、使用実績等に基づいて所定の予測期間（例えば、１年）における各顧客の需要予測情報と資金予測情報とを生成する。需要予測情報は、予測期間内の各周期において顧客が必要とするリソース量の予測値を示す情報であり、資金予測情報は、予測期間内の各周期において顧客がオークションに使用可能な資金の予測値を示す情報である。

そして、データセンタは、運用フェーズが始まる前の計画フェーズにおいて、需要予測情報と資金予測情報に基づいて、資金配分計画情報を生成する。資金配分計画情報は、各顧客のリソースの必要量の相対的な関係に基づいて、全ての顧客が各周期において出来るだけ多くのリソースを出来るだけ少ない資金で獲得できるように、予測期間内の各周期でオークションに使用すべき資金の割合を顧客毎に規定した情報である。そして、データセンタは、この資金配分計画情報に基づいて、各顧客が周期毎に使用する資金の上限を算出してオークションを実行し、各顧客へのリソースの割当量を決定する。

このように、本実施例に係るリソース割当管理方法では、全顧客のリソースの使用実績を把握しているデータセンタが、資金配分計画情報を生成し、これに基づいてオークションを実行することとしたので、高い戦略を用いて資金の配分を決定することができない顧客であっても、十分な量のリソースを少ない資金で確保することができる。

なお、図１の例では、単独の予測期間について、データセンタが、資金配分計画情報を生成する例を示したが、予測期間は、間隔が開くことがないように連続して設けられる。そして、現行の予測期間に対応する運用フェーズが完了する前に、次の予測期間のための計画フェーズが平行して進行し、それまでの運用実績等に基づいて、次の予測期間の資金配分計画情報が作成される。

次に、本実施例に係るリソース割当管理方法を実行するリソース割当管理装置１０の構成について説明する。リソース割当管理装置１０は、データセンタ等に設置され、顧客がリソースを獲得するために予測期間の各周期において使用すべき資金の割合を規定した資金配分計画情報を生成するとともに、この資金配分計画情報を利用してオークションを自動実行する。なお、以下の説明では、予測期間が、「２００７／４／１」から「２００８／３／３１」までの１年であり、周期が１日であるものとする。また、リソースの配分の一例として、プロセッサを顧客に配分する例を示すこととする。

図３は、リソース割当管理装置１０の構成を示すブロック図である。同図に示すように、リソース割当管理装置１０は、表示部１１０と、入力部１２０と、ネットワークインターフェース部１３０と、記憶部１４０と、制御部１５０とを有する。表示部１１０は、各種情報を表示する表示デバイスであり、例えば、液晶表示装置からなる。入力部１２０は、各種情報や操作指示を入力するための入力デバイスであり、例えば、キーボードやマウスからなる。ネットワークインターフェース部１３０は、リソース割当管理装置１０が他の装置とネットワークを介して情報をやりとりするための通信制御をおこなうインターフェース装置である。

記憶部１４０は、各種情報を記憶する記憶デバイスであり、需要予測情報１４１と、資金予測情報１４２と、資金配分計画情報１４３、ポリシー情報１４４と、保有資金情報１４５と、リソース情報１４６と、需要情報１４７と、割当実績情報１４８と、入金情報１４９とを記憶する。

需要予測情報１４１は、予測期間における各顧客の周期毎のリソースの必要量の予測値を示す情報である。需要予測情報１４１の一例を図４に示す。同図に示すように、需要予測情報１４１は、顧客ＩＤ、周期、必要リソース量といった項目を有し、顧客ＩＤ毎に、周期と必要リソース量の組合せを複数保持することができる構造となっている。顧客ＩＤは、顧客を識別するための識別子である。周期は、周期を識別するための日時であり、必要リソース量は、その周期で必要とするリソース量をＰＧ数で表したものである。

図４に示した需要予測情報１４１の１〜３行目は、「顧客Ａ」という顧客ＩＤに対応する顧客が、２００７／４／１にＰＧ４個分のリソースを必要とし、２００７／４／２にＰＧ５個分のリソースを必要とし、２００７／４／３にＰＧ４個分のリソースを必要とすることを表している。

需要予測情報１４１は、図示しない処理部によって、過去における各顧客のネットワークサービスの負荷（例えば、ネットワークのトラフィック）の測定結果に基づいて生成される。具体的には、各顧客のネットワークサービスの負荷が周期毎に計測され、対応する周期の計測結果に所定の係数を乗じる等の処理を加えることにより、各顧客の周期毎の必要リソース量が算出される。なお、ネットワークサービスの負荷の測定結果に基づいて需要予測情報１４１を生成するのではなく、過去におけるリソースの割当実績である割当実績情報１４８に基づいて需要予測情報１４１を生成することもできる。また、顧客の申請に基づいて需要予測情報１４１を生成することもできる。

資金予測情報１４２は、予測期間の各周期において各顧客が新たにオークションに使用できるようになる資金の予測値を示す情報である。資金予測情報１４２の一例を図５に示す。同図に示すように、資金予測情報１４２は、顧客ＩＤ、周期、追加資金といった項目を有し、顧客ＩＤ毎に、周期と追加資金の組合せを複数保持することができる構造となっている。顧客ＩＤは、顧客を識別するための識別子である。周期は、周期を識別するための日時であり、追加資金は、その周期で新たにオークションに使用できるようになる資金である。

図５に示した資金予測情報１４２の１〜３行目は、「顧客Ａ」という顧客ＩＤに対応する顧客が、２００７／４／１に６万円の資金を新たにオークションに使用できるようになり、２００７／４／２に６万円の資金を新たにオークションに使用できるようになり、２００７／４／３に６万円の資金を新たにオークションに使用できるようになることを表している。

資金予測情報１４２は、制御部１５０の資金予測情報生成部１５２によって、需要予測情報１４１に基づいて生成される。資金予測情報１４２においては、ユーザから月末毎に料金を徴収するタイプのネットワークサービスを提供している顧客の場合であっても、周期毎に資金が追加されるものとして情報が設定される。すなわち、ある周期における収入が、次に収入がある周期までの各周期に配分されて追加資金として設定される。このように、全ての顧客が、周期毎に資金を得るという単純なモデルを採用することにより、資金配分計画情報１４３の生成処理を簡略化することができる。

資金配分計画情報１４３は、予測期間の各周期において各顧客がオークションに使用すべき資金の割合を規定した情報である。資金配分計画情報１４３の一例を図６に示す。同図に示すように、資金配分計画情報１４３は、顧客ＩＤ、周期、資金消費率といった項目を有し、顧客ＩＤ毎に、周期と資金消費率の組合せを複数保持することができる構造となっている。顧客ＩＤは、顧客を識別するための識別子である。周期は、周期を識別するための日時であり、資金消費率は、その周期の追加資金のうちどれだけの金額をオークションに使用すべきかを示す割合である。

図６に示した資金配分計画情報１４３の１行目は、「顧客Ａ」という顧客ＩＤに対応する顧客の２００７／４／１の資金消費率が８０％であり、５行目は、「顧客Ａ」という顧客ＩＤに対応する顧客の２００７／１２／１の資金消費率が１２０％であることを表している。このように、資金消費率は、１００％を超える値となることがある。

資金消費率が、１００％未満の場合、オークションに使用される資金が追加資金よりも少ないため、その周期の追加資金の全てがオークションに使用されることはなく、追加資金の一部が後続のオークションへ繰り越される。また、資金消費率に関わりなく、オークションの結果によっては、追加資金の一部が後続のオークションへ繰り越される。そして、資金消費率が１００％を超過する周期においては、その周期の追加資金に加えて、過去のオークションで繰り越された資金が消費される。

ポリシー情報１４４は、予測期間の各周期において各顧客がオークションに使用すべき資金の上限を顧客が自身の裁量で決定するためのポリシーを定義した情報であり、顧客によって編集される。ポリシー情報１４４の一例を図７に示す。同図に示すように、ポリシー情報１４４は、顧客ＩＤ、区分、値といった項目を有し、顧客ＩＤ毎に、区分と値の組合せを複数保持することができる構造となっている。顧客ＩＤは、顧客を識別するための識別子である。区分と値は、ポリシーの属性値の区分と値である。

図７に示したポリシー情報１４４の１行目は、「重点期間指定型」というタイプのポリシーが選択されていることを表しており、２〜４行目は、１０／１〜１１／３０の期間は資金消費率を１００％とし、１２／１〜１／１０の期間は資金消費率を１２０％とし、その他の期間は資金消費率を８０％とすることを表している。ポリシー情報１４４において定義されるポリシーの詳細については後述する。

保有資金情報１４５は、各顧客が次回のオークションにおいて実際に使用できる資金を示す情報である。保有資金情報１４５の一例を図８に示す。同図に示すように、保有資金情報１４５は、顧客ＩＤ、追加資金、繰越資金といった項目を有し、顧客ＩＤ毎に、追加資金と追加資金の組合せを１つ保持する構造となっている。顧客ＩＤは、顧客を識別するための識別子である。追加資金は、次回の周期で新たにオークションに使用できるようになる資金であり、繰越資金は、それまでのオークションにおいて繰り越された資金である。

図８に示した保有資金情報１４５の１行目は、「顧客Ａ」という顧客ＩＤに対応する顧客が、次回の周期で６万円の資金を新たにオークションに使用できるようになり、それまでのオークションにおいて８万円の資金を繰り越していることを表している。すなわち、この１行目のデータは、「顧客Ａ」という顧客ＩＤに対応する顧客が、次回の周期で合計１４万円の資金をオークションに使用できることを表している。

リソース情報１４６は、リソースがどのように分割されているかを示す情報である。リソース情報１４６の一例を図９に示す。同図に示すように、リソース情報１４６は、ＰＧＩＤ、ホストといった項目を有し、ＰＧＩＤ毎に、ホストを１つ保持する構造となっている。ＰＧＩＤは、ＰＧを識別するための識別子である。ホストは、そのＰＧを構成するプロセッサを含むホストの一覧である。

図９に示したリソース情報１４６の１行目は、「ＰＧ０１」というＰＧＩＤに対応するＰＧは、「ｓｅｒｖ０１」というホストに含まれるプロセッサと、「ｓｅｒｖ０２」というホストに含まれるプロセッサとから構成されていることを表している。図９に示したリソース情報１４６の例では、それぞれのＰＧに対応するホストの数が異なっているが、処理能力の合計は、共通になっている。このように、処理能力の異なるプロセッサを含むホストを組み合わせて、処理能力が共通になるようにＰＧを構成することにより、オークションのモデルが単純化され、資金配分計画の作成処理の実現が容易になる。

需要情報１４７は、各顧客が実際に周期毎に必要とするリソース量を示す情報である。需要情報１４７は、図示しない処理部によって、需要予測情報１４１の内容を複製することにより生成され、需要予測情報１４１と同様の構造を有する。

割当実績情報１４８は、各周期におけるオークションの結果として、実際にリソースがどのように顧客に割り当てられたかを示す情報である。割当実績情報１４８の一例を図１０に示す。同図に示すように、割当実績情報１４８は、周期、ＰＧＩＤ、顧客ＩＤ、落札価格といった項目を有し、周期毎に、ＰＧＩＤと顧客ＩＤと落札価格の組合せを１つ保持する構造となっている。周期は、周期を識別するための日時であり、ＰＧＩＤは、ＰＧを識別するための識別子である。顧客ＩＤは、そのＰＧを割り当てられた顧客を識別するための識別子であり、落札価格は、その顧客がそのＰＧを落札するために使用した金額である。

図１０に示した割当実績情報１４８の１行目は、２００７／４／１に対応する周期において、「ＰＧ０１」というＰＧＩＤに対応するＰＧが、２万円で落札され、「顧客Ａ」という顧客ＩＤに対応する顧客に割り当てられたことを表しており、２行目は、同周期において、「ＰＧ０２」というＰＧＩＤに対応するＰＧが、４万円で落札され、「顧客Ｂ」という顧客ＩＤに対応する顧客に割り当てられたことを表している。

入金情報１４９は、各顧客が実際に新たにオークションに使用する資金を示す情報である。入金情報１４９の一例を図１１に示す。同図に示すように、入金情報１４９は、顧客ＩＤ、周期、追加資金といった項目を有し、顧客ＩＤ毎に、周期と追加資金の組合せを複数保持することができる構造となっている。顧客ＩＤは、顧客を識別するための識別子である。周期は、周期を識別するための日時または複数の周期を示す期間であり、追加資金は、その周期で新たにオークションに使用できるようになる資金である。

図１１に示した入金情報１４９の１〜３行目は、「顧客Ａ」という顧客ＩＤに対応する顧客が、２００７／４／１〜２００７／４／３０の期間の周期用に１８０万円の資金を新たにオークションに使用できるようになり、２００７／５／１〜２００７／５／３１の期間の周期用に１９０万円の資金を新たにオークションに使用できるようになり、２００７／６／１〜２００７／６／３０の期間の周期用に１７０万円の資金を新たにオークションに使用できるようになることを表している。

制御部１５０は、リソース割当管理装置１０を全体制御する制御部であり、情報編集部１５１と、資金予測情報生成部１５２と、資金配分計画生成部１５３と、使用資金決定部１５４と、オークション実行部１５５と、保有資金更新部１５６と、リソース割当部１５７とを有する。情報編集部１５１、資金予測情報生成部１５２および資金配分計画生成部１５３は、計画フェーズにおける処理を担当し、使用資金決定部１５４、保有資金更新部１５６およびリソース割当部１５７は、運用フェーズにおける処理を担当し、オークション実行部１５５は、計画フェーズと運用フェーズの両方における処理を担当する。

情報編集部１５１は、記憶部１４０に記憶されている各種情報を編集するための編集画面を表示部１１０、または、リソース割当管理装置１０とネットワーク接続された情報処理装置の表示部に表示し、顧客に情報の内容を編集させる処理部である。具体的には、情報編集部１５１は、需要予測情報１４１、資金予測情報１４２、ポリシー情報１４４および需要情報１４７の中の顧客自身に関する情報を顧客に編集させる。

図１２は、需要予測情報１４１と資金予測情報１４２の編集画面の一例を示す図である。同図に示すように、情報編集部１５１は、需要予測情報１４１と資金予測情報１４２から指定された顧客の情報を抽出し、必要リソース量と追加資金の時系列の変動をグラフに表す。このように必要リソース量と追加資金の変動を視覚的に表現することにより、顧客は、これらの予測値が適切であるか否かを容易に判断することができる。この画面において、編集ボタンを押下すると、需要予測情報１４１もしくは資金予測情報１４２の内容を編集するための画面が表示され、顧客は、情報の内容を変更することができる。顧客による需要予測情報１４１と資金予測情報１４２の編集は、資金配分計画生成部１５３による資金配分計画情報１４３の生成よりも先に行われる。

図１３は、ポリシー情報１４４の編集画面の一例を示す図である。同図に示すように、情報編集部１５１は、ポリシー情報１４４から指定された顧客の情報を抽出し、編集画面として表示する。同図は、図７に示した「顧客Ａ」という顧客ＩＤに対応する顧客のポリシー情報を編集する編集画面の例を示しており、付加情報として、保有資金情報１４５から当該の顧客の追加資金と繰越資金の値が取得されて上部に表示されている。

この例では、顧客は、ポリシーとして、簡易型と重点期間指定型とを指定することができるようになっている。簡易型ポリシーは、それぞれの周期において、繰越資金を含めた全ての資金を使用するというポリシーである。重点期間指定型ポリシーは、特定の期間毎に資金消費率を顧客が自身の裁量で決めることができるポリシーである。顧客は、この編集画面において、資金消費率を変更する期間とその期間における資金消費率を任意に指定することができる。

顧客によるポリシー情報１４４の編集は、計画フェーズだけでなく、運用フェーズの任意の時点においても可能である。顧客がポリシー情報１４４の内容を変更すると、その結果は、次以降の周期のオークションに反映される。各フェーズのオークションでは、資金配分計画情報１４３に基づいて資金の上限を決定した場合の予算効率と、顧客が設定したポリシーに基づいて資金の上限を決定した場合の予算効率とが顧客毎に求められ、コスト効率が高い方の資金の上限を用いてオークションが実行される。

なお、図７や図１３で示したポリシーは一例であり、これら以外のタイプのポリシーを顧客が選択できるように構成してもよい。例えば、商品検索や現金決済といったトランザクションの種別毎に資金消費率を顧客が自身の裁量で決めることができるポリシーを選択可能にしてもよい。

資金予測情報生成部１５２は、計画フェーズにおいて、需要予測情報１４１から資金予測情報１４２を生成する処理部である。具体的には、資金予測情報生成部１５２は、需要予測情報１４１の必要リソース量に、顧客が提供するネットワークサービスの利益率等を考慮して予め決められた係数を乗じることにより、各顧客の周期毎の追加資金を算出する。この追加資金の予測は、多くのリソースを割り当てられるほど、顧客は多くの収入を得ることができるはずであるという前提に基づいている。

各顧客の周期毎の追加資金を算出した後、資金予測情報生成部１５２は、顧客の収入発生パターンに合わせて、追加資金の平準化処理をおこなう。例えば、収入を得る周期（以下、「収入周期」という）が１ヶ月の顧客の場合は、１ヶ月間の各周期の追加資金の予測値を集計し、その集計値をその月の各周期に均等に配分し直す。なお、集計値を均等に配分し直すのではなく、顧客が予め設定したポリシーに従って、各周期への配分比率を変更することもできる。例えば、収入周期が１ヶ月で、月初に多くのリソースを必要とする顧客の場合は、月初の周期へ資金が多く配分されるようにポリシーを設定することができる。

上記の集計値の配分は、ある収入周期に必要とするリソースを確保するために必要な資金を、その収入周期が始まる前に確保しておくという運用を前提にしているが、収入周期において得られた資金を用いて次の収入周期のリソースを確保していくという運用も考えられる。このような運用をおこなうことを想定する場合は、資金予測情報生成部１５２が、収入周期毎の集計値を当該の収入周期の各周期に配分するのではなく、次の収入周期の各周期に配分するように構成すればよい。

資金配分計画生成部１５３は、計画フェーズにおいて、全ての顧客が各周期において出来るだけ多くのリソースを出来るだけ少ない資金で獲得できるように、予測期間内の各周期における各顧客の資金消費率の最適値を探索し、その結果を資金配分計画情報１４３へ格納する処理部である。資金配分計画生成部１５３は、資金消費率の最適値を求めるために、仮設定した資金消費率と、需要予測情報１４１と、資金予測情報１４２とに基づいて、予測期間内の全周期のオークションのシミュレートをオークション実行部１５５に実行させ、その結果を目的関数によって評価する。

各周期における各顧客の資金消費率を最適化するための目的関数としては、顧客毎のコスト効率関数、すなわち、全周期のオークションのシミュレーションを通じて当該顧客の勝ち取ったリソース量の総合計を、全周期のオークションにおいて当該顧客が使用した資金の総合計で除算したものが好適である。なぜなら、少しでも少ない賭け金で少しでも多くのリソースを勝ち取れる資金配分こそが最も合理的な資金配分といえるからである。

最適な決定変数の値の探索は、例えば、資金消費率を決定変数として、数理計画法に基づく解空間の探索アルゴリズムを用いて実現することができる。具体的には、各顧客に対応させて生成した番号を第１インデックスとし、各周期に対応させて生成した番号を第２インデックスとする資金消費率の２次元配列からなる決定変数の値の最適値を、上記のコスト効率関数を最大化するように探索すればよい。

しかしながら、この方式で顧客の資金配分の最適化をおこなう場合、顧客の数と周期の数の積に等しい数の決定変数が存在することになる。データセンタでは、ネットワークサービスをホスティングする顧客の数が１００を超えることは珍しくなく、また、予測期間を１年間、周期を１日とすると、周期の数は３６５個となる。すなわち、決定変数の数は、数万個のオーダーとなることが珍しくないと想定される。

決定変数の値が離散値を取るとしても、ニュートン法で最適解の探索動作を１回おこなうには、各決定変数の現在値にΔ値を加算した場合と減算した場合について目的関数を評価しなくてはならないから、決定変数の数が数万個であるとすると、目的関数の評価を２の数万乗の回数行わなくてはならなくなる。したがって、現在の電子計算機の性能を考慮すると、何らの工夫もなく単純な最適化をおこなうのは現実的ではない。

そこで、資金配分計画生成部１５３は、以下に説明する縮退関数を導入し、この縮退関数に渡す少数の制御パラメータの値を最適化するという方式を採用する。縮退関数とは、顧客毎に定義される関数で、数個程度の制御パラメータ、顧客単体でのリソースの需要度に関するパラメータ、顧客全体でのリソースの需要度に関するパラメータという３つの種類のパラメータを入力として受け取り、予測期間内の各周期における顧客の資金消費率を算出する関数である。

顧客単体でのリソースの需要度に関するパラメータの値と、顧客全体でのリソースの需要度に関するパラメータの値は、需要予測情報１４１によって決定されるが、制御パラメータは、任意に設定可能である。ある顧客の縮退関数の制御パラメータを変化させると、制御パラメータの変化に応じて縮退関数によって算出される各周期の資金消費率が変化し、オークションのシミュレーション結果とコスト効率関数の値も変化してゆく。すなわち、全ての縮退関数の制御パラメータの集合を決定変数とし、縮退関数とコスト効率関数の組合せを目的関数とする最適化問題を構成することにより、資金配分計画情報１４３を短時間で生成することができる。

資金配分計画生成部１５３の構成の詳細を図１４に示す。同図に示すように、資金配分計画生成部１５３は、最適解探索部１５３ａと、パラメータ設定部１５３ｂと、使用金額算出部１５３ｃと、必要リソース量取得部１５３ｄとを有する。

最適解探索部１５３ａは、最適解の探索を制御する。具体的には、最適解探索部１５３ａは、解探索の探索方向を設定し、その探索方向に従った制御パラメータをパラメータ設定部１５３ｂに設定させる。そして、制御パラメータを用いて算出された各顧客の周期毎の資金消費率を適用してシミュレートされたオークションの結果に基づいて、解探索の探索方向を再設定する。この処理を繰り返し実行して解領域の探索が完了した後に、最適解探索部１５３ａは、目的関数の値が最良であったときの各顧客の周期毎の資金消費率を資金配分計画情報１４３に格納する。

パラメータ設定部１５３ｂは、最適解探索部１５３ａによって設定された探索方向に従って各顧客の縮退関数の制御パラメータを設定する。使用金額算出部１５３ｃは、パラメータ設定部１５３ｂによって設定された制御パラメータを用いて各顧客の周期毎の資金消費率を算出する。そして、算出された資金消費率と資金予測情報１４２に基づいて各周期のオークションのシミュレーションにおいて各顧客が使用する資金の上限を算出する。必要リソース量取得部１５３ｄは、需要予測情報１４１から、各顧客が周期毎に必要とするリソース量を取得する。

使用金額算出部１５３ｃによって算出された使用資金の上限と、必要リソース量取得部１５３ｄによって取得されたリソース量は、オークション実行部１５５に入力される。そして、オークション実行部は、入力された情報に基づいて、予想期間の全周期のオークションをシミュレートし、その結果を最適解探索部１５３ａへ通知する。

ここで、資金配分計画生成部１５３が使用する各種関数の例を示す。以下の式１は、周期ｔにおける顧客τの資金消費率ｂｉｄ＿ｒａｔｅ[τ，ｔ]を求める縮退関数ＤＧの一例である。

上記の式において、λ１τ〜λｐτは、顧客τの制御パラメータを表す。αは、周期ｔにおける顧客τの必要リソース量がピーク時に対してどれだけの大きさであるかを示す割合であり、βは、周期ｔにおけるリソース獲得の競争率である。αは、以下の式２によって求めることができ、βは、以下の式３によって求めることができる。

上記の式において、Ｒ（τ，ｔ）は、周期ｔにおいて顧客τが必要とするリソース量を表し、ＲＴは、データセンタの全リソース量を表す。

また、顧客τのコスト効率Ｆｏｐｔτを求める目的関数は、以下の式４のように表される。

上記の式において、Ａ（τ，ｔ）は、周期ｔにおいて顧客τが獲得したリソース量を表し、ωτｔは、周期ｔにおいて顧客τが所定量のリソースを獲得する毎に得ることができると想定される収益額を表す。また、ｂｕｄｇｅｔ[τ，ｔ]は、周期ｔにおける顧客τの追加資金を表す。

図３に戻って、使用資金決定部１５４は、運用フェーズの各周期におけるオークションの実行前に、資金配分計画情報１４３とポリシー情報１４４のいずれかに基づいてオークションに使用する資金の上限を顧客ごとに決定する処理部である。

具体的には、使用資金決定部１５４は、まず、資金配分計画情報１４３と保有資金情報１４５に基づいて、次の周期においてオークションに使用する資金の上限を顧客毎に算出し、この上限を適用した場合のオークションをオークション実行部１５５にシミュレートさせる。使用資金の上限は、保有資金情報１４５の追加資金に資金配分計画情報１４３の次の周期の資金消費率を乗じることにより算出される。ただし、算出された額が、保有資金情報１４５の追加資金と繰越資金の合計よりも大きい場合は、追加資金と繰越資金の合計が使用資金の上限となる。

続いて、使用資金決定部１５４は、ポリシー情報１４４と保有資金情報１４５に基づいて、次の周期においてオークションに使用する資金の上限を顧客毎に算出し、この上限を適用した場合のオークションをオークション実行部１５５にシミュレートさせる。使用資金の上限は、顧客によって選択されているポリシーが重点期間指定型であれば、該当期間の資金消費率を用いて上記と同様に算出される。また、顧客によって選択されているポリシーが簡易型であれば、追加資金と繰越資金の合計が使用資金の上限となる。

そして、使用資金決定部１５４は、資金配分計画情報１４３に基づいて使用資金の上限を算出した場合の予算効率と、ポリシー情報１４４に基づいて使用資金の上限を算出した場合の予算効率とを顧客毎に算出する。そして、顧客毎に予算効率を比較し、予算効率が良かった方の資金の上限を、その顧客が次の周期のオークションにおいて使用する資金の上限と決定する。

なお、予算効率とは、当該オークションにおいて所与の賭け金額でどれだけ資金的に効率良く、より多くのリソースを勝ち取れるかを示す数値である。周期ｔにおける顧客τの予算効率Ｂｅｆｆτｔは、例えば、以下の式５によって求めることができる。以下の式５において、ｂｉｄτｔは、周期ｔにおいて顧客τが使用した資金を表す。

このように、リソース割当管理装置１０は、予め最適化した資金消費率だけではなく、顧客が自身の裁量で設定したポリシーに基づく資金消費率も用いて、各顧客がオークションに使用する金額の上限を決定する。もし、最適化した資金消費率だけを用いて、各顧客がオークションに使用する金額の上限を決定することとすると、以下のような問題が生じる可能性がある。

第１に、オークションと言いながら、顧客自身が市場の相場決定や賭け金額の決定に関与できない不満により、顧客が、データセンタ業者のビジネスに不信感を抱く可能性がある。第２に、リソース割当管理装置１０がおこなう顧客の資金配分の最適化は、需要予測情報１４１と資金予測情報１４２のみに基づいて行われるため、顧客毎の特別な要因に適合した資金配分がなされない可能性がある。

例えば、ある顧客が、在庫維持コストが非常に高い商品をネット販売する電子商取引サービスをデータセンタでホスティングしていたとする。この場合、各周期における商品の在庫量や各商品の在庫期間の長さ、在庫期限が経過した場合の商品廃棄に伴う計上損失などに着目して各周期で必要とするリソース量とオークション使用資金を見積もることが重要である。

このような特別な要因をもった顧客であっても、最適な資金配分を容易におこなうことができるように、リソース割当管理装置１０は、顧客が自身の裁量で設定したポリシーに基づく資金消費率も用いて、各顧客がオークションに使用する金額の上限を決定するように構成されている。

なお、顧客の意思を重視するために、ポリシー情報１４４に基づいて使用資金の上限を算出した場合の方が予算効率で劣っていても、予算効率の差が所定の閾値以下であれば、ポリシー情報１４４に基づいて算出した使用資金の上限を、その顧客が次の周期のオークションにおいて使用する資金の上限と決定することとしてもよい。また、算出した２つの上限値とそれぞれに対応する予算効率を顧客に提示し、その顧客が次の周期のオークションにおいて使用する資金の上限を顧客に選択させることとしてもよい。

オークション実行部１５５は、リソース情報１４６に登録されている各ＰＧを商品としてオークションを実行する処理部である。オークション実行部１５５は、資金配分計画生成部１５３からオークションのシミュレーションを依頼された場合は、各顧客が必要とするリソース量と、各顧客が使用する資金の上限とをオークション実行部１５５から取得し、オークション結果を資金配分計画生成部１５３へ応答する。また、オークション実行部１５５は、使用資金決定部１５４からオークションのシミュレーションを依頼された場合は、各顧客が次の周期において必要とするリソース量を需要情報１４７から取得し、各顧客が使用する資金の上限を使用資金決定部１５４から取得し、オークション結果を使用資金決定部１５４へ応答する。

また、オークション実行部１５５は、所定の日時となって、次の周期におけるリソースの配分を決定することが必要になった場合は、各顧客が次の周期において必要とするリソース量を需要情報１４７から取得し、各顧客が使用する資金の上限を使用資金決定部１５４から取得する。そして、オークション結果をリソース割当部１５７に通知するとともに、割当実績情報１４８に追記する。なお、オークションの実現方式の詳細については後述する。

保有資金更新部１５６は、オークションの実行結果に基づいて保有資金情報１４５を更新する処理部である。具体的には、保有資金更新部１５６は、顧客毎に、オークションで使用されなかった資金を保有資金情報１４５の繰越資金として設定し、入金情報における次の周期の追加資金を保有資金情報１４５の追加資金として設定する。なお、顧客の収入周期が周期毎でない場合には、保有資金更新部１５６は、該当する収入周期の追加資金を収入周期内の周期数で割った値、もしくは、顧客が設定したポリシーに基づいて配分した値を保有資金情報１４５の追加資金として設定する。

リソース割当部１５７は、各ＰＧを、当該周期に対応するオークションにおいてそのＰＧを落札した顧客に割り当てる処理部である。

次に、リソース割当管理装置１０の処理手順について説明する。図１５は、リソース割当管理装置１０がある予測期間に対応して実行する処理の全体の流れを示すフローチャートである。同図に示すように、まず、資金予測情報生成部１５２が、需要予測情報１４１に基づいて、当該予測期間の資金予測情報１４２を生成する（ステップＳ１０１）。なお、顧客による需要予測情報１４１と資金予測情報１４２の修正は、必要であれば、このタイミングで実行される。

続いて、資金配分計画生成部１５３が、後述する資金配分計画情報生成処理を実行し、需要予測情報１４１と資金予測情報１４２に基づいて、当該予測期間の資金配分計画情報１４３を生成する（ステップＳ１０２）。こうして、資金配分計画情報１４３が作成された後は、当該予測期間の周期毎に以下の処理が実行される。

すなわち、使用資金決定部が、後述する使用資金決定処理を実行して、次のオークションにおいて各顧客が使用する資金の上限を決定し（ステップＳ１０３）、オークション実行部１５５が、その決定に基づいて、後述するオークション処理を実行し、各ＰＧをどの顧客に割り当てるかを決定する（ステップＳ１０４）。そして、オークション実行部１５５が、その結果を割当実績情報１４８に記録し（ステップＳ１０５）、保有資金更新部１５６が、次回のオークションに向けて、保有資金情報１４５における各顧客の資金情報を更新する（ステップＳ１０６）。

そして、実行されたオークションに対応する周期が始まったならば（ステップＳ１０７肯定）、リソース割当部１５７が、オークション実行部１５５によるオークションの実行結果に基づいてリソースを顧客に割り当てる（ステップＳ１０８）。ここで、当該の周期が、予測期間の最後の周期であれば（ステップＳ１０９肯定）、当該の予測周期に関する一連の処理が終了し、さもなければ（ステップＳ１０９否定）、次の周期を対象としてステップＳ１０３以降の手順が再び実行される。

図１６は、資金配分計画情報生成処理の処理手順を示すフローチャートである。同図に示すように、まず、パラメータ設定部１５３ｂが、最適解探索部１５３ａによって設定された探索方向に従って縮退関数の制御パラメータを初期設定する（ステップＳ２０１）。そして、資金予測情報生成部１５２は、周期を表す変数Ｔを１に初期化し（ステップＳ２０２）、図示しないメモリ上に一時記憶されている各顧客の繰越資金をクリアして初期化する（ステップＳ２０３）。

続いて、使用金額算出部１５３ｃが、周期Ｔにおける各顧客の資金消費率を縮退関数によって求める（ステップＳ２０４）。そして、使用金額算出部１５３ｃが、資金予測情報１４２から周期Ｔにおける各顧客の追加資金の予測値を取得し（ステップＳ２０５）、これにステップＳ２０４で算出した各顧客の資金消費率を乗じて、周期Ｔにおける各顧客の使用資金の上限を算出する（ステップＳ２０６）。

こうして使用資金の上限が算出されたならば、資金予測情報生成部１５２は、オークション実行部１５５に後述するオークション処理を実行させることにより、オークションをシミュレートし（ステップＳ２０７）、その結果に基づいて図示しないメモリ上に一時記憶されている各顧客の繰越資金を更新する（ステップＳ２０８）。そして、周期Ｔが予測期間の最後の周期でなければ（ステップＳ２０９否定）、Ｔに１を加算した後（ステップＳ２１０）、ステップＳ２０４以降の手順が再実行される。

一方、周期Ｔが予測期間の最後の周期である場合、すなわち、現在の制御パラメータの設定で予測期間内の全周期のオークションのシミュレーションが実行された場合は（ステップＳ２０９肯定）、最適解探索部１５３ａが、各顧客のリソース獲得状況を目的関数で評価する（ステップＳ２１１）。そして、解空間の探索が完了していなければ（ステップＳ２１２否定）、最適解探索部１５３ａが、解空間の探索方向を決定し（ステップＳ２１３）、パラメータ設定部が、その探索方向に従って、縮退関数の制御パラメータを再設定した後（ステップＳ２１４）、ステップＳ２０２以降の手順が再実行される。

そして、解空間の探索が完了していた場合は（ステップＳ２１２肯定）、最適解探索部１５３ａが、目的関数で最も良好な結果が得られた場合の制御パラメータに対応する各顧客の周期毎の資金消費率を資金配分計画情報１４３へ格納する（ステップＳ２１５）。なお、目的関数で最も良好な結果が得られた場合とは、全顧客について最も良好な結果が得られた場合を意味する。目的関数が顧客毎のコスト効率を求めるものであれば、例えば、各顧客について目的関数を評価した結果がいずれも所定値より良好な場合の中で、目的関数の評価結果の平均が最も良好な場合を、最も良好な結果が得られた場合とすることができる。

図１７は、縮退関数における資金消費率の決定論理の一例を示すフローチャートである。同図は、制御変数を閾値として使用する例を示している。同図に示すように、縮退関数においては、まず、顧客τが周期Ｔにおいて必要とするリソース量がピーク時に対してどれだけの大きさであるかを示す割合、すなわち、リソースの必要度であるαと、周期Ｔにおけるリソース獲得の競争倍率であるβとが評価される（ステップＳ３０１）。

そして、リソースの必要度αが第１の閾値であるλ１よりも高く（ステップＳ３０２肯定）、競争倍率βが第２の閾値であるλ２以下の場合は（ステップＳ３０３否定）、積極的に資金を投入して少しでも多くのリソースを勝ち取るべきであるので、資金消費率を１２０％のように大きな値に設定する（ステップＳ３０４）。一方、リソースの必要度αが第１の閾値であるλ１よりも高くても（ステップＳ３０２肯定）、競争倍率βが第２の閾値であるλ２よりも高い場合は（ステップＳ３０３肯定）、積極的に資金を投入してもリソースを十分に取得することができない可能性があるので、資金消費率を９０％のように中程度の値に設定する（ステップＳ３０５）。

また、リソースの必要度αが第１の閾値であるλ１以下であり（ステップＳ３０２否定）、競争倍率βが第２の閾値であるλ２より大きい場合は（ステップＳ３０６肯定）、資金を節約すべきであるので、資金消費率を６０％のように小さな値に設定する（ステップＳ３０７）。一方、リソースの必要度αが第１の閾値であるλ１以下であっても（ステップＳ３０２否定）、競争倍率βが第２の閾値であるλ２以下である場合は（ステップＳ３０６否定）、リソースを十分に取得することができる可能性が高いので、資金消費率を９０％のように中程度の値に設定する（ステップＳ３０８）。

図１８は、使用資金決定処理の処理手順を示すフローチャートである。同図に示すように、使用資金決定部１５４は、各顧客の追加資金と繰越資金を保有資金情報１４５から取得し（ステップＳ４０１）、次の周期における各顧客の資金消費率を資金配分計画情報１４３から取得する（ステップＳ４０２）。そして、使用資金決定部１５４は、取得した情報から、次のオークションにおける各顧客の使用資金の上限を算出し（ステップＳ４０３）、オークション実行部１５５に後述するオークション処理を実行させることにより、オークションをシミュレートする（ステップＳ４０４）。そして、使用資金決定部１５４は、オークションのシミュレート結果に基づいて、顧客毎に予算効率を算出する（ステップＳ４０５）。

続いて、使用資金決定部１５４は、各顧客のポリシーの設定をポリシー情報１４４から取得し（ステップＳ４０６）、取得したポリシーの設定に基づいて、次のオークションにおける各顧客の使用資金の上限を算出する（ステップＳ４０７）。そして、使用資金決定部１５４は、オークション実行部１５５に後述するオークション処理を実行させることにより、オークションをシミュレートし（ステップＳ４０８）、オークションのシミュレート結果に基づいて、顧客毎に予算効率を算出する（ステップＳ４０９）。

そして、使用資金決定部１５４は、顧客毎に予算効率を比較し、優れている方の予算効率に対応する使用資金の上限を、次のオークションにおいて顧客が使用する資金の上限とする（ステップＳ４１０）。

図１９は、オークション処理の処理手順を示すフローチャートである。オークション実行部１５５は、情報処理装置内でＰＧ毎に仮想的なオークションを開催し、各顧客に対応する仮想人格に入札価格を競り合わさせて、最も高い入札価格を示した仮想人格に対応する顧客にＰＧを割り当てる。仮想人格やＰＧ毎の仮想的なオークションは、例えば、適切な属性とメソッドを備えたオブジェクトを生成することによって実現される。なお、以下の処理手順の説明においては、便宜上、顧客に対応する仮想人格を単に顧客と呼ぶこととする。

同図に示すように、オークション実行部１５５は、ＰＧ毎に仮想的なオークションを開催し、各オークションに最低入札金額を設定する（ステップＳ５０１）。このように、最低金額を設定することにより、データセンタは、落札価格が不当に低くなることを防止し、適正な利益を確保することができる。

続いて、オークション実行部１５５は、全ての顧客を必要数分のＰＧのオークションに参入させる（ステップＳ５０２）。このとき、各顧客の入札金額は、当該のオークションで使用可能な資金の上限を参入するＰＧ数で割った金額とする。もしこの金額が最低金額よりも低ければ、最低金額を入札金額とし、入札金額の合計が使用資金の上限を超えないように、参入するＰＧ数を調整する。なお、顧客をオークションへ参入させるにあたっては、参入する顧客の数がＰＧ毎にばらつかないように、顧客を分散させることが好ましい。

続いて、オークション実行部１５５は、各オークションにおいて、単独で参入している顧客がいれば、その顧客をそのオークションの勝者と設定する（ステップＳ５０３）。そして、オークション実行部１５５は、参入している全てのオークションで勝者となっている顧客がいれば、その顧客に完了フラグを設定し（ステップＳ５０４）、また、いずれのオークションにも参入していない顧客がいれば、その顧客にも完了フラグを設定する（ステップＳ５０５）。そして、全ての顧客に完了フラグが設定されたならば（ステップＳ５０６肯定）、オークション処理を終了させる。

一方、完了フラグが設定されていない顧客がいれば（ステップＳ５０６否定）、オークション実行部１５５は、そのうちの１人を選択し（ステップＳ５０７）、その顧客に使用資金の残金がなければ（ステップＳ５０８否定）、最も高値で負けているオークションから顧客を撤退させ、そのオークションに掛けていた入札金額をその顧客の使用資金として復活させる（ステップＳ５０９）。このように顧客が資金を使い果たした場合に、勝ち目の薄いオークションから顧客を撤退させることにより、顧客の資金を復活させ、他のＰＧのオークションにおける劣勢を挽回するために使用させることができる。

そして、オークション実行部１５５は、その顧客が参入しているオークションの中で負け幅が最小で最高入札価格が最安値のオークションへの入札額を更新させる。具体的には、最高入札額と顧客の現在の入札額との差額に１円を加算した金額を使用可能であれば、その額をオークションに入札額に追加させ、さもなければ、使用資金の残高全額を入札額に追加させる。

そして、オークション実行部１５５は、完了フラグが設定されていない顧客で選択していない顧客がいれば（ステップＳ５１１否定）、ステップＳ５０７に戻って、その顧客の１人を選択してステップＳ５０８以降の手順を再実行する。一方、完了フラグが設定されていない顧客を全て選択済みであれば（ステップＳ５１１肯定）、ステップＳ５０３から処理手順を再開する。

なお、図３に示した本実施例に係るリソース割当管理装置１０の構成は、本発明の要旨を逸脱しない範囲で種々に変更することができる。例えば、リソース割当管理装置１０の制御部１５０の機能をソフトウェアとして実装し、これをコンピュータで実行することにより、リソース割当管理装置１０と同等の機能を実現することもできる。以下に、制御部１５０の機能をソフトウェアとして実装したリソース割当管理プログラム１０７１を実行するコンピュータの一例を示す。

図２０は、リソース割当管理プログラム１０７１を実行するコンピュータ１０００を示す機能ブロック図である。このコンピュータ１０００は、各種演算処理を実行するＣＰＵ（Central Processing Unit）１０１０と、ユーザからのデータの入力を受け付ける入力装置１０２０と、各種情報を表示するモニタ１０３０と、記録媒体からプログラム等を読み取る媒体読取り装置１０４０と、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース装置１０５０と、各種情報を一時記憶するＲＡＭ（Random Access Memory）１０６０と、ハードディスク装置１０７０とをバス１０８０で接続して構成される。

そして、ハードディスク装置１０７０には、図３に示した制御部１５０と同様の機能を有するリソース割当管理プログラム１０７１と、図３に示した記憶部１４０に記憶される各種データに対応するリソース割当管理用データ１０７２とが記憶される。なお、リソース割当管理用データ１０７２を、適宜分散させ、ネットワークを介して接続された他のコンピュータに記憶させておくこともできる。

そして、ＣＰＵ１０１０がリソース割当管理プログラム１０７１をハードディスク装置１０７０から読み出してＲＡＭ１０６０に展開することにより、リソース割当管理プログラム１０７１は、リソース割当管理プロセス１０６１として機能するようになる。そして、リソース割当管理プロセス１０６１は、リソース割当管理用データ１０７２から読み出した情報等を適宜ＲＡＭ１０６０上の自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種データ処理を実行する。

なお、上記のリソース割当管理プログラム１０７１は、必ずしもハードディスク装置１０７０に格納されている必要はなく、ＣＤ−ＲＯＭ等の記憶媒体に記憶されたこのプログラムを、コンピュータ１０００が読み出して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等を介してコンピュータ１０００に接続される他のコンピュータ（またはサーバ）等にこのプログラムを記憶させておき、コンピュータ１０００がこれらからプログラムを読み出して実行するようにしてもよい。

上述してきたように、本実施例では、需要予測情報１４１と、資金予測情報１４２とに基づいて資金配分計画生成部１５３が資金配分計画情報１４３を生成することとしたので、個別の顧客の需要だけでなく、各顧客の需要の相対的な関係を考慮して、全ての顧客の各周期への資金の配分を適切におこなうことができる。

以上のように、本発明に係るリソース割当管理プログラム、リソース割当管理装置およびリソース割当管理方法は、所定のリソースに対するオークション処理を所定の周期毎におこなって、顧客へのリソースの割当量を決定する場合に有用であり、特に、全ての顧客の各周期への資金の配分を適切におこなうことが必要な場合に適している。

本実施例に係るリソース割当管理方法の概要を示す図である。 各周期における資金の動きを示す図である。 リソース割当管理装置の構成を示すブロック図である。 需要予測情報の一例を示す図である。 資金予測情報の一例を示す図である。 資金配分計画情報の一例を示す図である。 ポリシー情報の一例を示す図である。 保有資金情報の一例を示す図である。 リソース情報の一例を示す図である。 割当実績情報の一例を示す図である。 入金情報の一例を示す図である。 需要予測情報と資金予測情報の編集画面の一例を示す図である。 ポリシー情報の編集画面の一例を示す図である。 資金配分計画生成部の構成の詳細を示す図である。 リソース割当管理装置がある予測期間に対応して実行する処理の全体の流れを示すフローチャートである。 資金配分計画情報生成処理の処理手順を示すフローチャートである。 縮退関数における資金消費率の決定論理の一例を示すフローチャートである。 使用資金決定処理の処理手順を示すフローチャートである。 オークション処理の処理手順を示すフローチャートである。 リソース割当管理プログラムを実行するコンピュータを示す機能ブロック図である。

１０ リソース割当管理装置
１１０ 表示部
１２０ 入力部
１３０ ネットワークインターフェース部
１４０ 記憶部
１４１ 需要予測情報
１４２ 資金予測情報
１４３ 資金配分計画情報
１４４ ポリシー情報
１４５ 保有資金情報
１４６ リソース情報
１４７ 需要情報
１４８ 割当実績情報
１４９ 入金情報
１５０ 制御部
１５１ 情報編集部
１５２ 資金予測情報生成部
１５３ 資金配分計画生成部
１５３ａ 最適解探索部
１５３ｂ パラメータ設定部
１５３ｃ 使用金額算出部
１５３ｄ 必要リソース量取得部
１５４ 使用資金決定部
１５５ オークション実行部
１５６ 保有資金更新部
１５７ リソース割当部
１０００ コンピュータ
１０１０ ＣＰＵ
１０２０ 入力装置
１０３０ モニタ
１０４０ 媒体読取り装置
１０５０ ネットワークインターフェース装置
１０６０ ＲＡＭ
１０６１ リソース割当管理プロセス
１０７０ ハードディスク装置
１０７１ リソース割当管理プログラム
１０７２ リソース割当管理用データ
１０８０ バス

Claims (4)

1. 所定のリソースに対するオークション処理を所定の周期毎におこなって、顧客へのリソースの割当量を決定するリソース割当管理プログラムであって、
   記憶手段に記憶された、顧客ごとに、周期毎に必要とするリソースの必要量の予測値を示す需要予測情報と、前記記憶手段に記憶された、オークションに使用する周期毎の資金の予測値を示す資金予測情報と、該資金予測情報のうちどれだけの金額をオークションに使用するかの割合を示す資金消費率を乗算した金額と、に基づいて、前記オークション処理のシミュレーションを実行し、該シミュレーションの結果から所定周期間について獲得したリソース量をリソース獲得に使用した金額で除算したコスト効率を算出する処理を、前記資金消費率を変化させて、全ての顧客のコスト効率を加算した値が最大となる顧客ごとの資金消費率を解析することにより、顧客の周期毎の資金消費率を示す資金配分計画情報を生成し、生成した前記資金配分計画情報を前記記憶手段に記憶する資金配分計画生成手順と、
   それぞれの顧客について、前記記憶手段を参照して前記資金予測情報に前記資金配分計画情報を乗算することにより、周期毎に使用する資金の上限を決定する使用資金決定手順と、
   をコンピュータに実行させることを特徴とするリソース割当管理プログラム。
2. 前記使用資金決定手順は、前記記憶手段にさらに記憶されたポリシ情報により示される顧客が設定したポリシーに基づいて該顧客がオークションにおいて使用する資金の上限を決定した場合のオークションのシミュレーション結果と、前記記憶手段に記憶された前記資金配分計画情報に基づいて該顧客がオークションにおいて使用する資金の上限を決定した場合のオークションのシミュレーション結果とを比較して、いずれか一方の上限を該顧客がオークションにおいて使用する資金の上限と決定することを特徴とする請求項１に記載のリソース割当管理プログラム。
3. 所定のリソースに対するオークション処理を所定の周期毎におこなって、顧客へのリソースの割当量を決定するリソース割当管理装置であって、
   前記オークション処理をシミュレーションするシミュレーション手段と、
   記憶手段に記憶された、顧客ごとに、周期毎に必要とするリソースの必要量の予測値を示す需要予測情報と、前記記憶手段に記憶された、オークションに使用する周期毎の資金の予測値を示す資金予測情報と、該資金予測情報のうちどれだけの金額をオークションに使用するかの割合を示す資金消費率を乗算した金額と、に基づいて、前記シミュレーション手段により前記オークション処理のシミュレーションを実行し、該シミュレーションの結果から所定周期間について獲得したリソース量をリソース獲得に使用した金額で除算したコスト効率を算出する処理を、前記資金消費率を変化させて、全ての顧客のコスト効率を加算した値が最大となる顧客ごとの資金消費率を解析することにより、顧客の周期毎の資金消費率を示す資金配分計画情報を生成し、生成した前記資金配分計画情報を前記記憶手段に記憶する資金配分計画生成手段と、
   それぞれの顧客について、前記記憶手段を参照して前記資金予測情報に前記資金配分計画情報を乗算することにより、周期毎に使用する資金の上限を決定する使用資金決定手段と、
   を備えたことを特徴とするリソース割当管理装置。
4. 所定のリソースに対するオークション処理を所定の周期毎におこなって、顧客へのリソースの割当量を決定するリソース割当管理方法であって、
   コンピュータが、
   記憶手段に記憶された、顧客ごとに、周期毎に必要とするリソースの必要量の予測値を示す需要予測情報と、前記記憶手段に記憶された、オークションに使用する周期毎の資金の予測値を示す資金予測情報と、該資金予測情報のうちどれだけの金額をオークションに使用するかの割合を示す資金消費率を乗算した金額と、に基づいて、前記オークション処理のシミュレーションを実行し、該シミュレーションの結果から所定周期間について獲得したリソース量をリソース獲得に使用した金額で除算したコスト効率を算出する処理を、前記資金消費率を変化させて、全ての顧客のコスト効率を加算した値が最大となる顧客ごとの資金消費率を解析することにより、顧客の周期毎の資金消費率を示す資金配分計画情報を生成し、生成した前記資金配分計画情報を前記記憶手段に記憶する資金配分計画生成工程と、
   それぞれの顧客について、前記記憶手段を参照して前記資金予測情報に前記資金配分計画情報を乗算することにより、周期毎に使用する資金の上限を決定する使用資金決定工程と、
   を実行することを特徴とするリソース割当管理方法。

Images