JP6829670B2 - リソース管理サーバ、および、リソース管理方法 - Google Patents

Description

本発明は、リソース管理サーバ、および、リソース管理方法の技術に関する。

Ｗｅｂサーバでサービスを提供し、そのサービスをＡＰＩ（Application Programming Interface）を介してアクセスさせる事業者（以下、卸事業者）が増えている。そして、複数の卸事業者からのサービスを連携させてユーザに提供するサービス事業者も増えている。このように、卸事業者→サービス事業者→ユーザの順にサービスを提供するビジネスモデルは、Ｂ２Ｂ２Ｃ（Business to Business to Consumer）モデルと呼ばれる。さらに、最終提供先のユーザが法人である場合（Ｂ２Ｂ２Ｂ（Business to Business to Business））も含めて、Ｂ２Ｂ２Ｘモデルとも呼ばれる。

Ｂ２Ｂ２Ｘモデルを通信サービスに適用した一例として、非特許文献１には、卸事業者であるＭＮＯ（Mobile Network Operator）と、サービス事業者であるＭＶＮＯ（Mobile Virtual Network Operator）とについて、それぞれのサービス内容や市場動向が紹介されている。

伊藤 裕万、「MVNOを取り巻く環境と動向」、［online］、公正取引委員会競争政策研究センター BBL講演資料、2014年5月30日、［2017年8月16日検索］、インターネット〈URL：http://www.jftc.go.jp/cprc/katsudo/bbl.files/172nd-bbl.pdf〉

サービス事業者は、自身で設備を持たずに卸事業者から設備のリソースをレンタルする。サービス事業者は、サービス事業者の顧客であるユーザ数の増加や、ユーザに提供するサービス内容を充実させるため、リソースのレンタル元となる卸事業者を増やして対応することができる。ここで、別々の卸事業者からレンタルされたリソースを連携させるためには、リソースを管理するシステムをサービス事業者ごとに開発する必要がある。

しかし、卸事業者からレンタルしたリソースの連携のさせ方や、連携させたサービスをユーザに提供する方法はサービス事業者ごとに異なる上に、サービス事業者のノウハウであるため、あるサービス事業者向けのリソース管理システムを、別のサービス事業者向けのリソース管理システムに転用することは困難である。そのため、サービス事業者ごとにリソース管理システムを開発する必要があり、効率が悪い。

そこで、本発明は、外部からの設備のリソースの供給を受けてサービスを提供するサービス事業者にとって、供給されたリソースの管理負担を減らすことを、主な課題とする。

前記課題を解決するために、本発明のリソース管理サーバは、以下の特徴を有する。
本発明は、リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムに用いられる前記リソース管理サーバであって、
前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理するリソース管理部と、
前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新するリソース更新受付部と、
前記メインプール内で前記サービス事業者サーバに割り当ててあるものの、前記サブプール内でどの前記ユーザ端末にも割り当ててない状態のリソース量が所定値より少ないときには、前記自身のリソースを増強するように出力する設備増強支援部と、を有することを特徴とする。

これにより、サービス事業者サーバは自身でユーザ端末ごとに割り当てた第２の割当状況を管理しなくて済み、リソース更新受付部を介して第２の割当状況の管理をリソース管理サーバに依頼すればよい。よって、外部からの設備のリソースの供給を受けてサービスを提供するサービス事業者にとって、供給されたリソースの管理負担を減らすことができる。
さらに、リソース管理サーバを有する卸事業者は、第２の割当状況を把握できるため、サービス事業者サーバからの追加発注を予想してタイミング良く設備増強ができ、販売機会損失を防止できる。

本発明は、リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムに用いられる前記リソース管理サーバであって、
前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理するリソース管理部と、
前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新するリソース更新受付部と、
前記メインプール内で前記サービス事業者サーバに割り当ててあるものの、前記サブプール内でどの前記ユーザ端末にも割り当ててない状態のリソース量が所定値より多いときには、前記自身のリソースを複数の前記サービス事業者サーバに重複して割り当てることを許可する重複割当部と、を有することを特徴とする。

これにより、サービス事業者サーバは自身でユーザ端末ごとに割り当てた第２の割当状況を管理しなくて済み、リソース更新受付部を介して第２の割当状況の管理をリソース管理サーバに依頼すればよい。よって、外部からの設備のリソースの供給を受けてサービスを提供するサービス事業者にとって、供給されたリソースの管理負担を減らすことができる。
さらに、リソース管理サーバを有する卸事業者は、第２の割当状況を把握できるため、一時的には実リソース量以上に販売し、その後に実際に使われるタイミングまでに設備増強することができる。

本発明は、リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムに用いられる前記リソース管理サーバであって、
前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理するリソース管理部と、
前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新するリソース更新受付部と、を有し、
前記リソース管理部が、使用開始時刻になるまでは前記サブプール内で所定の前記ユーザ端末に予約状態のリソースとして確保し、前記使用開始時刻になった後は前記サブプール内で予約状態のリソースを所定の前記ユーザ端末に利用可能状態として割り当てることを特徴とする。

これにより、サービス事業者サーバは自身でユーザ端末ごとに割り当てた第２の割当状況を管理しなくて済み、リソース更新受付部を介して第２の割当状況の管理をリソース管理サーバに依頼すればよい。よって、外部からの設備のリソースの供給を受けてサービスを提供するサービス事業者にとって、供給されたリソースの管理負担を減らすことができる。
さらに、ユーザ端末は、使用開始時刻になったら、確実に事前予約したリソースを用いたサービスを受けることができる。

本発明によれば、外部からの設備のリソースの供給を受けてサービスを提供するサービス事業者にとって、供給されたリソースの管理負担を減らすことができる。

本実施形態に係わるリソース管理システムの概要図である。 分散管理型のリソース管理システムの構成図である。 本実施形態に係わる階層管理型のリソース管理システムの構成図である。 図２の分散管理型におけるリソース割当の一例を示す説明図である。 本実施形態に係わる図３の階層管理型におけるリソース割当の一例を示す説明図である。 本実施形態に係わる卸事業者サーバ→サービス事業者サーバ→ユーザ端末の順にリソースが割り当てられる手順を示す説明図である。 本実施形態に係わるユーザ端末→サービス事業者サーバ→卸事業者サーバの順にリソースの割当が解除される手順を示す説明図である。 本実施形態に係わる設備増強支援部における設備増強契機を示す説明図である。 本実施形態に係わる設備増強支援部における設備増強後を示す説明図である。 本実施形態に係わる重複割当部における重複割当契機を示す説明図である。 本実施形態に係わる重複割当部における重複割当後を示す説明図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、リソース管理システムの概要図である。リソース管理システムは、ユーザ端末１（１ａ〜１ｃ）と、サービス事業者サーバ２（２ｘ、２ｙ）と、卸事業者サーバ３（３ｐ、３ｑ）とがネットワークで接続されて構成される。
これらのリソース管理システムの各装置は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

卸事業者サーバ（リソース管理サーバ）３は、卸サービス３０（３０ｐ、３０ｑ）をサービス事業者サーバ２に提供する。
サービス事業者サーバ２は、複数の卸サービス３０を連携させた連携サービス２０（２０ｘ、２０ｙ）を、ユーザ端末１に提供する。そのため、サービス事業者サーバ２は、各卸事業者サーバ３に対して卸サービス３０の申込処理や保守処理などを依頼する。
ユーザ端末１は、サービス事業者サーバ２に対して連携サービス２０の申込処理や保守処理などを依頼する。

図２は、比較例における分散管理型のリソース管理システムの構成図である。分散管理型とは、サービス事業者サーバ９２と卸事業者サーバ９３とで別々に（分散して）リソース割当を管理するという意味である。
サービス事業者サーバ９２は、図１の連携サービス２０を提供するために、ユーザ端末１からサービスの要求を受け付ける要求受付部９２１と、複数の卸サービス３０のリソースを連携するためのリソース連携部９２２と、卸サービス３０のリソースを卸事業者サーバ９３に発注する発注依頼部９２３とを有する。
卸事業者サーバ９３は、図１の卸サービス３０を提供するために、発注依頼部９２３から発注を受け付ける発注受付部９３１と、卸サービス３０のリソースを管理するリソース管理部９３２とを有する。

ここで、分散管理型によるリソース割当の一例を説明する。
第１の卸事業者サーバ９３内のリソース管理部９３２は、自身が提供する卸側管理リソース９３３ｐとして、第１のサービス事業者サーバ９２に提供するリソース「ＲＳＸ１」と、第２のサービス事業者サーバ９２に提供するリソース「ＲＳＹ１」とを割り当てている。
第２の卸事業者サーバ９３内のリソース管理部９３２は、自身が提供する卸側管理リソース９３３ｑとして、第１のサービス事業者サーバ９２に提供するリソース「ＲＳＸ２」を割り当てている。

第１のサービス事業者サーバ９２内のリソース連携部９２２は、第１の卸事業者サーバ９３から提供されたリソース「ＲＳＸ１」をサービス側管理リソース９２４ｐとして管理する。リソース連携部９２２は、提供されたリソース「ＲＳＸ１」の内訳として、ユーザ端末１ａにサービスを提供するためのリソース「ＲＳＡ１」と、ユーザ端末１ｂのためのリソース「ＲＳＢ１」と、自身で保有しておくリソース「ＲＰＸ１」とに小分けする。

同様に、第１のサービス事業者サーバ９２内のリソース連携部９２２は、第２の卸事業者サーバ９３から提供されたリソース「ＲＳＸ２」をサービス側管理リソース９２４ｑとして管理する。リソース連携部９２２は、提供されたリソース「ＲＳＸ２」の内訳として、ユーザ端末１ａのためのリソース「ＲＳＡ２」と、ユーザ端末１ｂのためのリソース「ＲＳＢ２」と、自身で保有しておくリソース「ＲＳＸ２」とに小分けする。つまり、ユーザ端末１ａには、リソース「ＲＳＡ１」とリソース「ＲＳＡ２」とを連携させたサービスが提供される。

このように、サービス事業者サーバ９２は、リソースの発注先である卸事業者サーバ９３ごとに、リソースを別々に管理していた。よって、サービス事業者サーバ９２は、複数の卸サービス３０を連携させて１つの連携サービス２０を提供するときに、卸事業者サーバ９３（卸サービス３０）ごとに、提供されるリソースをサービス側管理リソース９２４（９２４ｐ、９２４ｑ）として管理をするため、その管理システムの開発負担が大きくなってしまう。
また、卸事業者サーバ９３は、１つのサービス事業者サーバ９２に対して１つのリソース（ＲＳＸ１，ＲＳＸ２）を割り当てたという大まかな管理をしているだけで、そのリソースの内訳を認識することはできなかった。よって、卸事業者サーバ９３は、割り当てたリソースの利用状況を把握し、その利用状況に適した運営を行うことができなかった。

図３は、本発明における階層管理型のリソース管理システムの構成図である。
サービス事業者サーバ２は、図１の連携サービス２０を提供するために、ユーザ端末１からサービスの要求を受け付ける要求受付部２１と、複数の卸サービス３０のリソースを連携するためのリソース連携部２２と、卸サービス３０のリソースを卸事業者サーバ３に発注する発注依頼部２３とを有する。
卸事業者サーバ３（３ｐ）は、図１の卸サービス３０を提供するために、発注依頼部２３から発注を受け付ける発注受付部（リソース更新受付部）３１と、卸サービス３０のリソースを管理するリソース管理部３２とを有する。
さらに、卸事業者サーバ３は、後記するサブプール３５（３５ｘ、３５ｙ）の内容を卸事業者に活用させるための各種処理部（設備増強支援部３８、重複割当部３９）を有する（説明は図８〜図１１）。

卸事業者サーバ３内でのリソース管理機構として、第１層（第１の割当状況）のメインプール３４、第２層（第２の割当状況）のサブプール３５（３５ｘ、３５ｙ）という階層構造を用いる。これにより、仮想化されたリソースを、矛盾なく、わかりやすく管理できる。図２ではサービス事業者サーバ９２がサービス側管理リソース９２４として行っていたリソース管理を、図３では卸事業者サーバ３がサブプール３５として管理する。以下、図２の分散管理型との違いに着目して説明する。

まず、サービス事業者サーバ２に着目して説明する。リソース連携部２２は、図２のサービス側管理リソース９２４のように自身でリソースを管理する必要がなくなる。これにより、複数の卸サービス３０を連携させるときでも、発注先の卸事業者サーバ３ごとにリソース管理システムを開発しなくて済むため、サービス事業者サーバ２の開発が容易になり、連携サービス２０を低コストで提供できるようになる。

次に、卸事業者サーバ３に着目して説明する。卸事業者サーバ３ｐでは、図２の卸側管理リソース９３３ｐが図３のメインプール３４（第１層）に置き換わり、図２のサービス側管理リソース９２４ｐが図３のサブプール３５ｘ（第２層）に置き換わる。
例えば、メインプール３４には、サービス事業者サーバ２ｘに提供するリソース「ＲＳＸ１」と、サービス事業者サーバ２ｙに提供するリソース「ＲＳＹ１」とが記載される。
また、サブプール３５ｘには、サービス側管理リソース９２４ｐと同様に、サービス事業者サーバ２ｘに提供するリソース「ＲＳＸ１」の内訳（ＲＳＡ１，ＲＳＢ１，ＲＰＸ１）が記載される。同様に、サブプール３５ｙには、サービス事業者サーバ２ｙに提供するリソース「ＲＳＹ１」の内訳（ＲＳＣ１，ＲＰＹ１）が記載される。

なお、どのユーザ端末１にどのリソースを割り当てたかなどの詳細な管理を卸事業者サーバ３のサブプール３５側で行うために、卸事業者サーバ３の発注受付部３１は拡充されたＡＰＩ３１１をサービス事業者サーバ２（発注依頼部２３）に公開する。つまり、「リソースを買う、リソースを返却する」という大まかなメインプール３４を扱っていた発注受付部３１のＡＰＩが、サービス事業者サーバ２と卸事業者サーバ３との連携を密にできるように、「ユーザ端末１ａにリソースを利用させる」などの詳細なＡＰＩ３１１へと拡充される。このＡＰＩ３１１の詳細は、図６，図７で後記する。

図４は、図２の分散管理型におけるリソース割当の一例を示す説明図である。
まず、卸側管理リソース９３３ｐとして、卸事業者サーバ９３が卸サービス３０として提供するリソース全体の割当状況が管理されている。卸側管理リソース９３３ｐには、卸事業者サーバ９３が第１のサービス事業者サーバ９２にリソースの使用権を売却した売却リソースＲＳＸ１が含まれている。また、卸側管理リソース９３３ｐには、卸事業者サーバ９３が第２のサービス事業者サーバ９２にリソースの使用権を売却した売却リソースＲＳＹ１が含まれている。

次に、サービス側管理リソース９２４として、卸側管理リソース９３３から割り当てられたリソースの内訳が管理されている。
サービス側管理リソース９２４ｐには、売却リソースＲＳＸ１の内訳として、第１のサービス事業者サーバ９２がユーザ端末１ごとにリソースの使用権を売却した売却リソースＲＳＡ１，ＲＳＢ１が含まれる。さらに、売却リソースＲＳＸ１の内訳として、第１のサービス事業者サーバ９２自身が確保しておいた保有リソースＲＰＸ１と、誰も使用していない状態の空きリソースＲＥも含まれる。
各ユーザ端末１は、サービス事業者サーバ９２から割り当てられたリソースＲＳＡ，ＲＳＢを用いて、連携サービス２０を受ける。

サービス側管理リソース９２４ｒには、売却リソースＲＳＹ１の内訳として、第２のサービス事業者サーバ９２がユーザ端末１ごとにリソースの使用権を売却した売却リソースＲＳＣ１が含まれる。さらに、売却リソースＲＳＹ１の内訳として、第２のサービス事業者サーバ９２自身が確保しておいた保有リソースＲＰＹ１も含まれる。
ユーザ端末１は、サービス事業者サーバ９２から割り当てられたリソースＲＳＣを用いて、連携サービス２０を受ける。

図５は、図３の階層管理型におけるリソース割当の一例を示す説明図である。
まず、メインプール３４として、図４の卸側管理リソース９３３ｐと同様に、リソース全体の割当状況が管理されている。次に、サブプール３５として、図４のサービス側管理リソース９２４ｐ，９２４ｒと同様に、メインプール３４から割り当てられたリソースの内訳が管理されている。
第１のサービス事業者サーバ２は、メインプール３４から割り当てられたリソースＲＳＸ１の内訳として、サブプール３５のリソースＲＳＡ１，ＲＳＢ１を用いて、連携サービス２０を各ユーザ端末１に提供する。
第２のサービス事業者サーバ２も、メインプール３４から割り当てられたリソースＲＳＹ１の内訳として、サブプール３５のリソースＲＳＣ１を用いて、連携サービス２０をユーザ端末１に提供する。

以下、図６，図７を参照して、ＡＰＩ３１１の詳細を説明する。
図６は、卸事業者サーバ３→サービス事業者サーバ２→ユーザ端末１の順にリソースが割り当てられる手順を示す説明図である。
図７は、図６とは逆方向に、ユーザ端末１→サービス事業者サーバ２→卸事業者サーバ３の順にリソースの割当が解除される手順を示す説明図である。
図６，図７では、メインプール３４で管理されるメインプール内リソース６０と、サブプール３５で管理されるサブプール内リソース７０とで、符号６１〜６３，符号７１〜７４で示すように各リソースの状態を複数の状態に分類している。さらに、状態間の遷移を示す矢印と、その矢印の識別子（Ｓ１１〜Ｓ１５，Ｓ２１〜Ｓ２５）も図示している。以下、各状態および各遷移の詳細を説明する。

メインプール内リソース６０のリソースは、サービス業者売却状態６１、卸業者利用状態６２、または、卸業者内空き状態６３のいずれかに分類される。
サービス業者売却状態６１は、図５のＲＳＸ１，ＲＳＹ１のように、サービス事業者サーバ２に対して使用権を売却した状態である。サービス業者売却状態６１の内訳は、サブプール内リソース７０で定義される。
卸業者利用状態６２は、卸事業者サーバ３が自身で使用するために確保してある状態である。
卸業者内空き状態６３は、どのサービス事業者サーバ２にも、卸事業者サーバ３自身にも割り当てていない状態である。なお、卸業者利用状態６２と卸業者内空き状態６３との間の状態遷移は、卸事業者サーバ３の内部処理として行えばよいので、ＡＰＩ３１１としてサービス事業者サーバ２に公開しなくてもよい。

サブプール内リソース７０のリソースは、ユーザ売却状態７１、サービス業者利用状態７２、サービス業者内空き状態７３、または、予約済み状態７４のいずれかに分類される。
ユーザ売却状態７１は、図５の売却リソースＲＳＡ１，ＲＳＢ１，ＲＳＣ１のように、ユーザ端末１に使用させるためにリソースの使用権を売却した状態である。
サービス業者利用状態７２は、図５の保有リソースＲＰＸ１，ＲＰＹ１のように、サービス事業者サーバ２が自身で使用するために確保してある状態である。
サービス業者内空き状態７３は、図５の空きリソースＲＥのように、どのユーザ端末１にも、サービス事業者サーバ２自身にも割り当てていない状態である。
予約済み状態７４は、ユーザ売却状態７１またはサービス業者内空き状態７３に将来遷移するために、予約してある状態である。

以上説明した各状態をふまえ、以下のＡＰＩ３１１を説明する。
（１）「卸業者内空き状態６３の確認用ＡＰＩ」
（２）「サービス業者内空き状態７３への購入用ＡＰＩ」
（３）「ユーザ売却状態７１への割当用ＡＰＩ」
（４）「ユーザ売却状態７１への割当解除用ＡＰＩ」
（５）「卸業者内空き状態６３への返却用ＡＰＩ」
（６）「予約済み状態７４への購入用ＡＰＩ」
（７）「予約済み状態７４の予約内容変更用ＡＰＩ」
（８）「予約済み状態７４の予約キャンセル用ＡＰＩ」
なお、（２）、（３）、（６）がリソースを割り当てるときに使用するＡＰＩであり、（４）、（５）、（８）がリソースの割当を解除するときに使用するＡＰＩである。
リソース管理部３２は、これらの各ＡＰＩ３１１を介してサービス事業者サーバ２から呼び出された指示を受け、サブプール３５内の各リソースの割当状況を更新する。

（１）「卸業者内空き状態６３の確認用ＡＰＩ」は、卸業者内空き状態６３のリソース量がサービス事業者サーバ２の必要分だけ存在するか否かを確認するためのＡＰＩである。このＡＰＩにより、サービス事業者サーバ２がユーザ端末１から受け付けた申込の可否を応答することができる。例えば、卸業者内空き状態６３のリソース量が不足しているときには、ユーザ端末１から受け付けた申込を拒否する。

（２）「サービス業者内空き状態７３への購入用ＡＰＩ」は、サービス事業者サーバ２から卸事業者サーバ３に代金を支払うことで、卸業者内空き状態６３のリソースをサービス業者内空き状態７３のリソースとして購入するためのＡＰＩである（Ｓ１１）。なお、サービス業者内空き状態７３のリソース量は時間経過により変動するので、常に余裕を持ってリソース量を残しておくことが望ましい。
そのため、サービス業者内空き状態７３のリソースが事前に設定しておいた標準リソース量以下となった場合に、そのリソース不足をサービス事業者サーバ２に通知するＡＰＩ（リソース不足警告ＡＰＩ）を設けてもよい。
また、サービス業者内空き状態７３のリソースが標準リソース量以下となった場合に、標準リソース量を越えるまで卸業者内空き状態６３のリソースを自動購入するＡＰＩ（サービス業者内空き状態７３への自動購入用ＡＰＩ）を設けてもよい。

（３）「ユーザ売却状態７１への割当用ＡＰＩ」は、ユーザ端末１からサービス事業者サーバ２に代金を支払うことで、サービス業者内空き状態７３のリソースをユーザ売却状態７１のリソースとして割り当てるためのＡＰＩである（Ｓ１２）。既に所定のユーザ端末１に対してユーザ売却状態７１のリソースを割当済みであるときでも、その割当量を変更するときには、この「ユーザ売却状態７１への割当用ＡＰＩ」を用いる。あらかじめサービス業者内空き状態７３として確保してあるリソースの一部を小売りすることで、所定のユーザ端末１からの追加発注に迅速に対応することができる。

（４）「ユーザ売却状態７１への割当解除用ＡＰＩ」は、Ｓ１２とは逆の流れで、ユーザ売却状態７１のリソース割当を解除して、サービス業者内空き状態７３のリソースに戻すためのＡＰＩである（Ｓ２４）。このＡＰＩは、リソース量を減少させる旨のユーザ端末１からの指示を受けて呼び出される。
なお、図示は省略したが、サービス業者内空き状態７３からサービス業者利用状態７２に割り当てるためのＡＰＩや、サービス業者利用状態７２からサービス業者内空き状態７３に戻すためのＡＰＩも、ＡＰＩ３１１に含めてもよい。

（５）「卸業者内空き状態６３への返却用ＡＰＩ」は、サブプール内リソース７０のリソース割当を解除して、卸業者内空き状態６３のリソースに戻すためのＡＰＩである。このＡＰＩは、例えば、ユーザ売却状態７１から返却する場合（Ｓ２１）や、サービス業者利用状態７２から返却する場合（Ｓ２２）や、サービス業者内空き状態７３から返却する場合（Ｓ２３）に呼び出される。
なお、ユーザ端末１が連携サービス２０を解約したときや、ユーザ売却状態７１の追加リソースの発注が想定よりも少ないときには、サービス業者内空き状態７３が余ってしまう。このようなときに、サービス事業者サーバ２は、余ったサブプール内リソース７０を卸業者内空き状態６３に戻す。

以下では、予約済み状態７４をもとに、リソースの予約に関するＡＰＩを説明する。
（６）「予約済み状態７４への購入用ＡＰＩ」は、卸業者内空き状態６３のリソースを予約済み状態７４のリソースとして予約するためのＡＰＩである（Ｓ１３）。予約済み状態７４のリソースは、予約者としてユーザ端末１またはサービス事業者サーバ２、予約するリソース種別、リソース量、予約したリソースの使用開始時刻などの予約内容が対応付けられる。
予約したリソースの使用開始時刻になったときに、もしくはユーザ端末１が連携サービス２０を利用開始したときに、予約済み状態７４のリソースは、予約者のユーザ売却状態７１のリソースへと遷移し（Ｓ１５）、ユーザ端末１への課金が開始される。または、予約したリソースの使用開始時刻になったら、予約済み状態７４のリソースは、サービス業者内空き状態７３のリソースへと遷移し（Ｓ１４）、サービス事業者サーバ２への課金が開始される。

（７）「予約済み状態７４の予約内容変更用ＡＰＩ」は、予約済み状態７４のリソースに対して、その予約内容を変更するためのＡＰＩである。
（８）「予約済み状態７４の予約キャンセル用ＡＰＩ」は、手続きなどの不備によりユーザ端末１の申込がキャンセルとなったときに、予約済み状態７４のリソースをキャンセルして卸業者内空き状態６３に戻すためのＡＰＩである（Ｓ２５）。
さらに、予約内容が変更されたときや、予約がキャンセルされたときに、その内容をサービス事業者サーバ２に通知するＡＰＩを設けてもよい。

以上、図１〜図７をもとに、リソース管理システムを説明した。図３の階層管理型のリソース管理システムでは、卸事業者サーバ３がサブプール３５を管理することで、サービス事業者サーバ２に貸し出したリソースの利用状況を把握することができる。
以下、図８〜図１１では、卸事業者サーバ３がサブプール３５のリソースの利用状況を、効率的なリソース計画に活用する一例を説明する。
・図３の設備増強支援部３８は、卸サービス３０のリソースを増強するタイミングを提案する（図８，図９）。
・図３の重複割当部３９は、同じ卸サービス３０のリソースを、複数の割当先に重複して割り当てることを許可する（図１０，図１１）。

図８は、設備増強支援部３８における設備増強契機を示す説明図である。
メインプール内リソース６０として、２つのサービス業者売却状態６１ｘ、６１ｙと、卸業者利用状態６２と、卸業者内空き状態６３とのリソースがそれぞれ存在する。
サービス業者売却状態６１ｘの内訳は、２つのユーザ売却状態７１（ＲＳＡ，ＲＳＢ）と、サービス業者利用状態７２（ＲＰＸ）と、サービス業者内空き状態７３（ＲＥ）とで構成される。
サービス業者売却状態６１ｙの内訳は、２つのユーザ売却状態７１（ＲＳＣ，ＲＳＤ）と、サービス業者利用状態７２（ＲＰＹ）と、サービス業者内空き状態７３（ＲＥ）とで構成される。
ここで、太線で示すように、設備増強支援部３８は、サービス業者内空き状態７３（ＲＥ）のリソース量が、２つのサービス事業者サーバ２ともに所定値より少ないため、各サービス事業者サーバ２から近々追加の発注が行われそうと予測する。

図９は、設備増強支援部３８における設備増強後を示す説明図である。図８の状態から設備増強支援部３８が卸事業者に設備増強を促す出力を行う。これにより、太線破線で示すように、卸事業者サーバ３に増強された設備のリソースは、卸業者内空き状態６３ｐのリソースとして追加される。これにより、各サービス事業者サーバ２から追加発注された場合でも、豊富な卸業者内空き状態６３ｐのリソースから発注されたリソースを提供できる。つまり、卸事業者は、サービス事業者サーバ２内のリソースの利用状況を把握できるため、タイミング良く設備増強ができ、販売機会損失を防止できる。

図１０は、重複割当部３９における重複割当契機を示す説明図である。
図８と同様に、メインプール内リソース６０、サブプール内リソース７０にはそれぞれリソースが状態別に割り当てられている。一方、図８ではサービス業者内空き状態７３（ＲＥ）のリソース量が所定値より少ない場合を示したが、図１０では太線の一点鎖線で示すように、サービス業者内空き状態７３（ＲＥ）のリソース量が所定値より多い場合を示す。つまり、各サービス事業者サーバ２は、自身の顧客であるユーザ端末１がこれから多少増加しても、自身のサービス業者内空き状態７３（ＲＥ）のリソース量をやりくりして対処できる状況である。

図１１は、重複割当部３９における重複割当後を示す説明図である。
太線の長破線で示すように、卸事業者サーバ３の重複割当部３９は、同じ卸サービス３０のリソースを、２つのサービス業者売却状態６１ｐ（ＲＥ）のリソースとして、複数の割当先に重複して割り当てることを許可する。つまり、サービス業者内空き状態７３（ＲＥ）のリソースは、現時点ではまだ使用されていない待ち状態なので、重複割当がなされても、割当先で同時に使用される確率は少ない。つまり、ある割当先で実際に使用するときに、別の割当先で同じリソースが使用済みのために、ある割当先がリソースを使用できないという不都合の発生確率は少ない。
このように、卸事業者は、サービス事業者サーバ２内の空きリソースが所定値より多い場合は、一時的には実リソース量以上に販売し、その後に実際に使われるタイミングまでに設備増強することで、効率的な設備増設を実行できる。

以上説明した本実施形態では、卸事業者サーバ３がサービス事業者サーバ２に卸サービス３０を提供し、サービス事業者サーバ２がユーザ端末１に連携サービス２０を提供するＢ２Ｂ２Ｃモデルのビジネスにおける卸サービス３０や連携サービス２０に用いられるリソースの管理システムを示した。
卸事業者サーバ３は、サービス事業者サーバ２ごとのリソース管理をメインプール３４で行うとともに、ユーザ端末１ごとのリソース管理もサブプール３５においてサービス事業者サーバ２から代行することが主な特徴である。
これにより、サービス事業者サーバ２のリソース管理負担を減らせるため、サービス事業者は、連携サービス２０の販売・料金請求・お客様対応等の業務に集中することができる。さらに、リソース管理業務を卸事業者サーバ３に集約することで、卸事業者は、ビジネスチャンスを拡大でき、トータルでの業務効率化につながる。

なお、本実施形態においては、本発明に係るリソース管理システムを、図１に示すユーザ端末１（１ａ〜１ｃ）と、サービス事業者サーバ２（２ｘ、２ｙ）と、卸事業者サーバ３（３ｐ、３ｑ）とで説明したが、これらの台数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、リソース管理システムの各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。

１ ユーザ端末
２ サービス事業者サーバ
３ 卸事業者サーバ（リソース管理サーバ）
２０ 連携サービス
２１ 要求受付部
２２ リソース連携部
２３ 発注依頼部
２４ サービス側管理リソース
３０ 卸サービス
３１ 発注受付部（リソース更新受付部）
３２ リソース管理部
３３ 卸側管理リソース
３４ メインプール
３５ サブプール
３８ 設備増強支援部
３９ 重複割当部
３１１ ＡＰＩ

Claims (6)

1. リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムに用いられる前記リソース管理サーバであって、
   前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理するリソース管理部と、
   前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新するリソース更新受付部と、
   前記メインプール内で前記サービス事業者サーバに割り当ててあるものの、前記サブプール内でどの前記ユーザ端末にも割り当ててない状態のリソース量が所定値より少ないときには、前記自身のリソースを増強するように出力する設備増強支援部と、を有することを特徴とする
   リソース管理サーバ。
2. リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムに用いられる前記リソース管理サーバであって、
   前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理するリソース管理部と、
   前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新するリソース更新受付部と、
   前記メインプール内で前記サービス事業者サーバに割り当ててあるものの、前記サブプール内でどの前記ユーザ端末にも割り当ててない状態のリソース量が所定値より多いときには、前記自身のリソースを複数の前記サービス事業者サーバに重複して割り当てることを許可する重複割当部と、を有することを特徴とする
   リソース管理サーバ。
3. リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムに用いられる前記リソース管理サーバであって、
   前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理するリソース管理部と、
   前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新するリソース更新受付部と、を有し、
   前記リソース管理部は、使用開始時刻になるまでは前記サブプール内で所定の前記ユーザ端末に予約状態のリソースとして確保し、前記使用開始時刻になった後は前記サブプール内で予約状態のリソースを所定の前記ユーザ端末に利用可能状態として割り当てることを特徴とする
   リソース管理サーバ。
4. リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムにより実行されるリソース管理方法であって、
   前記リソース管理サーバは、
   前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理し、
   前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新し、
   前記メインプール内で前記サービス事業者サーバに割り当ててあるものの、前記サブプール内でどの前記ユーザ端末にも割り当ててない状態のリソース量が所定値より少ないときには、前記自身のリソースを増強するように出力することを特徴とする
   リソース管理方法。
5. リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムにより実行されるリソース管理方法であって、
   前記リソース管理サーバは、
   前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理し、
   前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新し、
   前記メインプール内で前記サービス事業者サーバに割り当ててあるものの、前記サブプール内でどの前記ユーザ端末にも割り当ててない状態のリソース量が所定値より多いときには、前記自身のリソースを複数の前記サービス事業者サーバに重複して割り当てることを許可することを特徴とする
   リソース管理方法。
6. リソース管理サーバからリソースの供給を受けたサービス事業者サーバがユーザ端末にサービスを提供するリソース管理システムにより実行されるリソース管理方法であって、
   前記リソース管理サーバは、
   前記リソース管理サーバが自身のリソースを前記サービス事業者サーバごとに割り当てた第１の割当状況を示すメインプールと、前記第１の割当状況において割り当てられたリソースの内訳として、前記サービス事業者サーバが前記ユーザ端末ごとに割り当てた第２の割当状況を示すサブプールとを管理する工程において、使用開始時刻になるまでは前記サブプール内で所定の前記ユーザ端末に予約状態のリソースとして確保し、前記使用開始時刻になった後は前記サブプール内で予約状態のリソースを所定の前記ユーザ端末に利用可能状態として割り当て、
   前記サービス事業者サーバからの指示を受け、前記サブプール内の前記第２の割当状況を更新することを特徴とする
   リソース管理方法。

Images