JP2016139339A - 課金処理装置、課金処理方法、及び課金処理プログラム - Google Patents

Abstract

【課題】サービスの使用可能量に対する残余量の更新タイミングの最適化を図るための課金処理技術を提供する。
【解決手段】課金処理装置は、記憶部、更新部、及び制御部を含む。記憶部は、サービスの使用可能量に対する残余量を示す残余情報を記憶する。更新部は、サービスの使用量に応じて、残余情報を更新する。制御部は、更新された残余情報に基づいて、更新部による次の更新のタイミングを制御する。
【選択図】図１

Description

本発明は、課金処理装置、課金処理方法、及び課金処理プログラムに関する。

サービス提供者が通信ネットワークを介してソフトウェアやハードウェア資源等を利用者へ提供するクラウドサービスがある。

クラウドサービスの課金方式の一つにプリペイド課金方式がある。プリペイド課金方式は、クラウドサービスの利用者が事前にサービスの利用料金をチャージ（入金）し、残高が無くなるまでサービスの利用が可能となる方式である。この方式では、利用者がサービスを利用すると、利用に応じた金額がチャージ金額（プリペイド残高）から差し引かれる。

クラウドサービスのプリペイド課金方式に関して、データセンタを用いたクラウドコンピューティングサービスの利用に対する課金を行うプリペイド課金システムがある。プリペイド課金システムは、各利用者のプリペイド残高のデータをデータベースで記憶する。次に、プリペイド課金システムは、データセンタの仮想サーバにネットワークを介して接続された利用者について、クラウドコンピューティングサービスの使用量に応じた料金を算出する。そしてプリペイド課金システムは、算出した料金で、データベースに記憶された利用者のプリペイド残高を更新し、利用者のプリペイド残高がゼロ以下になった場合、利用者と仮想サーバとの通信を切断する制御を行う。

特開２０１３−１５９８６号公報 特開２００７−１５９２９８号公報 特開２００９−２４００４９号公報

しかしながら、上記のプリペイド課金方式では、一定の間隔でプリペイド残高の更新がされており、例えば、連続するプリペイド残高の更新時点の間にプリペイド残高が0になり、次の更新時点では、プリペイド残高がマイナスになってしまう場合がある。このように、上記技術では、プリペイド残高の更新のタイミングが考慮されていなかったため、利用者はプリペイド金額を超過してサービスを利用してしまう場合がある。

そこで、１つの側面では、本発明は、サービスの使用可能量に対する残余量の更新タイミングの最適化を図る技術を提供する。

一態様による課金処理装置は、記憶部、更新部、及び制御部を含む。記憶部は、サービスの使用可能量に対する残余量を示す残余情報を記憶する。更新部は、サービスの使用量に応じて、残余情報を更新する。制御部は、更新された残余情報に基づいて、更新部による次の更新のタイミングを制御する。

一側面によれば、サービスの使用可能量に対する残余量の更新タイミングの最適化を図るための課金処理技術を提供することができる。

実施形態に係る課金処理装置の構成の一例を示す。 比較例に係る課金処理の説明図である。 比較例における、サービスの利用金額がプリペイド残高を超過することの説明図である。 実施形態に係る課金処理の説明図である。 実施形態における超過利用の抑制の説明図である。 実施形態に係る課金処理システムの構成の一例を示す。 リソース情報の一例を示す。 システム情報の一例を示す。 利用者情報の一例を示す。 課金情報の一例を示す。 メータリング情報の一例を示す。 実施形態に係る課金処理装置の処理の詳細を図解したフローチャートの一例である。 実施形態に係る課金処理装置のハードウェア構成の一例を示す。

図１は、実施形態に係る課金処理装置の構成の一例を示す。図１において、課金処理装置１は、記憶部２、更新部３、制御部４、及び変更部５を含む。

記憶部２は、サービスの使用可能量に対する残余量を示す残余情報を記憶する。サービスは、例えばクラウドサービスである。残余情報は、例えばプリペイド残高である。

更新部３は、サービスの使用量に応じて、残余情報を更新する。
制御部４は、更新された残余情報に基づいて、更新部３による次の更新のタイミングを制御する。

これにより、課金処理装置１は、サービスの使用可能量に対する残余量の更新タイミングの最適化を図ることができる。

また、残余量が所定の閾値以下である場合に、サービスの利用を抑止するための制御を行うことで、課金処理装置１は、許容される使用可能量を超過したサービスの利用を抑止することができる。尚、許容された使用可能量は予め設定可能である。

また、使用可能量がプリペイド金額である場合には、課金処理装置１は、プリペイド金額を超過したサービスの利用を抑止することができる。

また、課金処理装置１は、残余情報の更新頻度を低減することができる。これにより課金処理装置１は、課金処理にかかる負荷を抑制することができる。

また、記憶部２は、さらに、単位時間当たりのサービスの使用量の最大値を示す最大使用量情報を記憶する。そして制御部４は、更新された残余情報と最大使用量情報とに基づいて、更新部３による次の更新のタイミングを制御する。

これにより、更新された残余情報と最大使用量情報とに基づいて、更新部３による次の更新のタイミングを制御するため、実施形態に係る課金処理装置は、サービスの使用可能量に対する残余量の更新タイミングをより適切に設定することが可能となる。

また、制御部４は、残余情報が更新された場合、更新された残余情報と最大使用量情報とに基づいて、次の更新の実行時刻を算出し、算出した実行時刻に更新を行うように更新部３を制御する。

このように、残余情報が更新された場合に、再度、次の更新の時刻を算出しなおすことで、課金処理装置１は、サービスの使用可能量に対する残余量の更新タイミングをより適切に設定することが可能となる。

変更部５は、サービスの使用形態に応じて、最大使用量情報を変更する。
制御部４は、最大使用量情報が変更部５により変更された場合、残余情報と最大使用量情報とに基づいて、次の更新の実行時刻を算出し、算出した実行時刻に更新を行うように更新部３を制御する。

このように、最大使用量情報が更新された場合に、再度、次の更新の時刻を算出しなおすことで、課金処理装置１は、サービスの使用可能量に対する残余量の更新タイミングをより適切に設定することが可能となる。

また、制御部４は、残余情報が所定の閾値以下である場合、予め定められた設定値に基づいて、次の更新の実行時刻を算出し、算出した実行時刻に更新を行うように更新部３を制御する。

このように、課金処理装置１は、予め定められた設定値に基づいて、残余情報が所定の閾値以下である場合、次の更新の実行時刻を算出するため、利用料金の計算間隔の極小化を防止することができる。

また、更新部３は、サービスの使用量に応じた使用料金を算出し、算出した該使用料金を、残余情報から差し引いて、新たな前記残余情報を算出する。使用料金は、仮想マシン、ストレージ、データベース、ネットワーク、データ転送量のうちの１つまたは所定の組み合わせの使用形態に応じて予め設定される使用料金の単価に基づいて算出される値である。

以下、実施形態の課金処理について詳細に説明する。先ず実施形態の効果を説明するために比較例に係るプリペイド課金処理について説明する。その後、実施形態に係る課金処理について説明し、比較例と比較した場合の実施形態の効果を記載する。

図２は、比較例に係る課金処理の説明図である。図２の課金処理システムは、仮想システム１１が利用者に提供される例を示している。課金処理システムは、仮想システム１１、利用者端末１２、及び課金処理装置１３を含む。仮想システム１１、利用者端末１２、及び課金処理装置１３は、通信ネットワーク等を介して接続される。仮想システム１１は利用者に提供されるサービスの一例であり、仮想サーバ、仮想ストレージ、仮想ネットワーク等を含むシステムである。利用者端末１２は、仮想システム１１を利用する利用者の操作端末である。課金処理装置１３は、利用者に対する課金処理を行う装置である。利用者により前払いされた仮想システム１１の利用料金（以下、プリペイド残高と記す）は、課金処理装置１３の記憶領域に予め格納されている。

比較例の課金処理装置１３は、以下のように課金処理を行う。すなわち、先ず課金処理装置１３は、利用者による仮想システム１１の利用状況を示すデータを収集（メータリング）して、データベースに格納する。次に課金処理装置１３は、定期的に利用実績に応じた利用者の利用料金を算出する。次に課金処理装置１３は、算出した利用料金を利用者のプリペイド残高から差し引くことによりプリペイド残高を更新する。プリペイド残高が１未満であれば、課金処理装置１３は、利用者のサービス利用の停止制御を行う。プリペイド残高が１以上であれば、そのままサービスの利用が継続される。

比較例においては、利用料金の算出は定期的に（例えば、１日１回）実施される。このため、サービスの利用金額がプリペイド残高を超過する場合がある。図３は、比較例における、サービスの利用金額がプリペイド残高を超過することの説明図である。図３において、横軸は利用料金が算出された時刻（日）を示し、縦軸は累積利用金額（円）を示す。プリペイド金額が「1000」円であるとすると、「9」日と「10」日の利用料金の算出時刻の間に利用金額がプリペイド金額に達し、「10」日に利用金額の算出が行われた時点では、プリペイド金額の「1000」円を超過したサービスの利用が行われてしまっている。

利用金額がプリペイド金額を超過した場合、超過分の料金をサービス提供者が負担することは難しい。この場合、超過分の料金は利用者が負担する場合が多い。このように比較例においては、厳密にはプリペイド課金が実現できていない。

また、比較例においては、定期的に実施する利用料金の計算の頻度を上げることで、超過利用の発生予測の正確性を高めることができる。しかしながら、この場合、課金計算の頻度が上がることでシステムにかかる負荷も上昇する。よって、課金処理装置１３が課金処理を行う対象の全ての仮想システム１１に対して、一律に課金計算の頻度を上げることはできない場合がある。

次に実施形態に係る課金処理について説明する。図４は、実施形態に係る課金処理の説明図である。尚、以下の説明では、プリペイド残高は金額で表しているが、例えば、プリペイド残高は金額に還元可能なポイント等としてもよく、種々の形式で表現されてもよい。また、プリペイド残高は、利用者により前払いで支払われた利用料金として説明するが、サービスの使用可能量を示す所定の値としてもよい。この場合、利用者による料金の支払は、サービスの利用前でなくともよく、利用料金はサービスの利用後に支払われてもよい。

図４の課金処理システムは、仮想システム２１が利用者に提供される例を示している。課金処理システムは、仮想システム２１、利用者端末２２、及び課金処理装置２３を含む。仮想システム２１、利用者端末２２、及び課金処理装置２３は、通信ネットワーク等を介して接続される。仮想システム２１、及び利用者端末２２は、それぞれ、図２の仮想システム１１、及び利用者端末１２と同様である。

課金処理装置２３は、利用者に対する課金処理を行う装置である。実施形態の課金処理においては、利用者の利用料金の算出及びプリペイド残高の更新のタイミングが適切に制御される。すなわち、実施形態の課金処理装置２３は、以下のように課金処理を行う。

予め課金処理装置２３は、利用者毎の利用料金計算間隔の最小値を所定の記憶領域に記憶しておく。また課金処理装置２３は、仮想システム２１を利用することで発生し得る、単位時間当たりの利用料金の最大値を算出して所定の記憶領域に格納する。

課金処理装置２３は、記憶領域に記憶されたプリペイド残高と単位時間当たりの利用料金の最大値とから、次回利用料金を算出するまでの時間間隔の候補（以下、候補時間と記す）を算出する。候補時間の算出の詳細については後ほど説明する。

そして課金処理装置２３は、利用料金計算間隔の最小値と候補時間とを比較し、比較の結果大きい値（同じ値の場合はどちらかの値）を、次回利用料金を算出するまでの時間間隔として決定する。そして課金処理装置２３は、決定した次回利用料金を算出するまでの時間間隔を、現在時刻に加えた時刻を、次回利用料金を算出する時刻（以下、次回計算時刻と記す）として設定して記憶する。利用料金計算間隔の最小値と候補時間とを比較する処理を行う理由は後ほど説明する。

課金処理装置２３は、算出した次回計算時刻まで、仮想システム２１の利用状況をメータリングする。メータリングにより収集した情報に基づいて、課金処理装置２３は、単位時間当たりの利用料金の最大値の変更を検出し、再度、次回計算時刻を算出しなおす。単位時間当たりの利用料金の最大値が変更されるのは、例えば、仮想システム２１の構成変更、利用者による仮想システム２１のリソースの追加もしくは返却、または、仮想システム２１の利用価格の変更があった場合である。よって、これらの場合に課金処理装置２３は、単位時間当たりの利用料金最大値を再度算出し、課金処理装置２３は再度算出した利用料金最大値とプリペイド残高とを用いて次回計算時刻を算出する。

また課金処理装置２３は、次回計算時刻までの間に利用者からの利用料金の前払によるプリペイド残高の追加が行われた場合には、追加されたプリペイド残高と利用料金最大値とから次回計算時刻を再度算出しなおす。

そして課金処理装置２３は、次回計算時刻になったら利用実績に応じた利用料金の算出を行う。その後、課金処理装置２３は算出した利用料金を利用者のプリペイド残高から差し引いて、残高を更新する。残高が１未満であれば、利用者のサービス利用の停止制御を行い、残高が１以上であれば、そのままサービスの利用が継続される。

上述したように実施形態においては、利用者が仮想システム２１を利用することで発生し得る利用料金の最大値を予め算出しておく。そして算出した利用料金の最大値とプリペイド残高とに基づいて、仮想システム２１ごとに計算間隔を調整する。これにより、プリペイド金額を超過した仮想システム２１の利用を抑止することができる。また、実施形態においては、利用料金の最大値、プリペイド残高の何れか又は両方に変更があった場合には、次回計算時刻の算出処理が再度行われ、次回計算時刻が更新される。これにより、プリペイド金額を超過した仮想システム２１の利用を抑止することができ、また、利用料金の計算頻度を低減することができる。比較例１に比べて、実施形態では利用料金の算出頻度を低減できるため、システムにかかる負荷を軽減することができる。

次に候補時間の算出の詳細について説明する。候補時間は以下の式（１）により算出する。
候補時間＝プリペイド残高／単位時間当たりの利用料金の最大値 （１）

式（１）によれば、候補時間は、単位時間当たりの最大利用料金で仮想システム２１が利用された場合に、プリペイド残高が「1」未満となる時間間隔を示す値として算出される。

候補時間を用いて次回計算時刻の設定が行われる場合、設定された次回計算時刻に利用料金の算出が行われ、算出された利用料金を用いてプリペイド残高の更新が行われる。プリペイド残高の更新後、プリペイド残高が「1」未満であれば、サービス利用の停止制御が行われる。そのため、単位時間当たりの最大利用料金で仮想システム２１が利用された場合でも、プリペイド額を超過してサービスの利用が行われることを防ぐことができる。

尚、式（１）において、値が割り切れない場合には、所定の位で切り捨てた値を候補時間としてもよい。

次に、実施形態において、利用料金計算間隔の最小値と候補時間とを比較する処理を行う理由について説明する。

候補時間の値は、式（１）より、プリペイド残高が「0」に近づくにつれて小さくなる。候補時間の値が小さい場合、候補時間をそのまま現在の時刻に加えて次回計算時刻として設定すると、次回計算時刻までの間隔が短くなり料金計算の負荷が高くなる。このような料金計算の負荷の増大を防ぐために、実施形態では、予め次回の利用料金計算間隔の最小値を設定しておく。そして、算出した候補時間の値が、利用料金計算間隔の最小値より小さい場合は、次回の利用料金計算までの時間間隔を、利用料金計算間隔の最小値と決定する。これにより、利用料金計算間隔の極小化を防止することができる。

利用料金計算間隔の極小化を防止するための処理を行う場合、最大で、「<単位時間当たりの利用料金最大値> × <利用料金計算間隔の最小値> - 1」の金額がプリペイド金額を超過する場合がある。ここで、「1」は利用料金の通貨の最小値を表している。例えば、利用料金が円であれば「\1」のことであり、ドルであれば「¢1(=$0.01)」に相当する。

ただしこの場合でも、利用料金計算間隔の最小値を適切に設定することで、超過料金を「0」とすることも可能である。すなわち、「<利用料金計算間隔の最小値> = 1 / <単位時間当たりの利用料金の最大値>」として、利用料金計算間隔の最小値を設定することで、超過料金を「0」とすることができる。具体的には例えば、単位時間当たりの利用料金最大値が100[円]の場合、利用料金計算間隔の最小値を0.01[H]と設定することで、プリペイド金額の超過を抑止することが出来る。すなわち、「100[円] × 0.01[H] - 1 = 0」とすることができる。

尚、利用料金計算間隔の最小値は、例えば、プリペイド残高と単位時間当たりの利用料金の最大値とに基づいて算出した値としてもよい。この場合、課金処理装置は、次回計算時刻の設定を行う毎に、利用料金計算間隔の最小値を算出してもよい。

また、利用料金計算間隔の最小値は利用者毎に設定することも可能である。利用者毎に利用料金計算間隔の最小値を設定することで、実施形態においては、利用者に応じて利用料金の計算頻度を調節することができる。

停止制御前の最後の利用料金計算でプリペイド額を超過してしまった場合でも、超過額を少額に抑えることができる。超過額をサービス提供者側が負担可能となるように計算間隔の最小値を設定することで、サービス利用者に追加請求が発生することを防ぐことができる。実施形態のプリペイド課金においては、利用料金の算出処理のためにシステムにかかる負荷と、発生する可能性のある超過料金の額のバランスを取りつつ、利用料金計算間隔を適切に設定することが可能となる。

図５は、実施形態における超過利用の抑制の説明図である。図５において、横軸は利用料金が算出された時刻（日）を示し、縦軸は累積利用金額（円）を示す。また、折れ線は実際の利用料金、棒線は計算された利用料金を示す。また、プリペイド金額は「1000」円であるとする。尚、棒線の記載のない時刻（日）には、利用料金の算出が行われていないことを示している。

図５に示すように、実施形態における利用料金の算出は、「1」、「5」、「7」、「9」（日）に実施されており、図３に示す比較例と比較すると利用料金の算出頻度が減少している。このように実施形態では、利用料金の算出にかかる負荷を軽減することができる。また、累積利用料金がプリペイド金額の「1000」円に近づくに従って、利用料金の算出間隔が小さくなっている。このように実施形態では、プリペイド金額の超過利用を抑制することができる。

次に、実施形態にかかる課金処理装置２３の構成の詳細について説明する。図６は、実施形態に係る課金処理システムの構成の一例を示す。課金処理システムは、仮想システム２１、利用者端末２２、課金処理装置２３、及び中継装置２４を含む。仮想システム２１、利用者端末２２、課金処理装置２３、及び中継装置２４は、通信ネットワーク等を介して接続される。

仮想システム２１は、例えば、物理サーバ、ストレージ、ネットワーク機器、仮想サーバ（Virtual Machine（ＶＭ）ホスト、ＶＭゲスト）、仮想ストレージ、仮想ネットワーク等のいずれかまたは所定の組合せを含んでもよい。

中継装置２４は、仮想システム２１と利用者端末２２の通信を中継する中継装置である。利用者端末２２は、中継装置２４を介して、仮想システム２１の仮想サーバ等にログインして仮想システム２１のリソースを利用する。中継装置２４は、具体的には例えばルータ等である。

尚、実施形態においては、利用者はシステム単位でクラウドサービスの利用を行うものとする。

課金処理装置２３は、記憶部３１、課金管理部３２、システム管理部３３、ネットワーク管理部３４、及び利用者情報管理部３５を含む。

尚、課金処理装置２３は、図１の課金処理装置１の一例である。記憶部３１は、図１の記憶部２の一例である。課金管理部３２は、図１の更新部３、制御部４の一例である。課金管理部３２及びシステム管理部３３は、変更部５の一例である。

記憶部３１は、リソース情報４１、システム情報４２、利用者情報４３、課金情報４４、及びメータリング情報４５を記憶する。

リソース情報４１は、利用者に対して提供されるリソース毎の単価を示す情報である。図７はリソース情報４１の一例を示す。図７においてリソース情報４１は、「リソース種別」、「リソース識別情報」、及び「単価」のデータ項目を含み、各データ項目はレコード（行）毎に対応付けて記憶される。

「リソース種別」は、利用者に提供可能なリソースの種別を示す情報である。「リソース識別情報」は、対応する「リソース情報」で示されるリソース種別のリソースの識別情報である。「リソース識別情報」は、例えば、対応するリソースが含まれるサーバプールまたはストレージプールの識別情報で示される。「単価」は、対応する「リソース情報」で示されるリソース種別であって対応する「リソース識別情報」で示されるリソースの単価を示す情報である。

尚、リソース情報４１は、図７に示す例に限定されず、利用者に対して提供されるリソースに応じて種々のデータ項目を含むことができる。

システム情報４２は、利用者に提供されるシステムの構成を示す情報である。図８はシステム情報４２の一例を示す。図８においてシステム情報４２は、「システムＩＤ」、「サーバＩＤ」、「ＣＰＵコア数」、「ＣＰＵ周波数」、「メモリ容量」、「サーバプール」、「ディスクＩＤ」、「ディスク容量」、「ストレージプール」、及び「帯域」のデータ項目を含む。システム情報４２の各データ項目はレコード毎に対応付けられる。

「システムＩＤ」は、利用者に提供されるシステムの識別情報である。「サーバＩＤ」は、「システムＩＤ」で示されるシステムに含まれるサーバの識別情報である。「ＣＰＵコア数」は、「サーバＩＤ」で示されるサーバに含まれるCentral Processing Unit（ＣＰＵ）のコア数を示す情報である。「ＣＰＵ周波数」は、「サーバＩＤ」で示されるサーバに含まれるＣＰＵの周波数を示す情報である。「メモリ容量」は、「サーバＩＤ」で示されるサーバに含まれるメモリの容量を示す情報である。「サーバプール」は、「サーバＩＤ」で示されるサーバが含まれるサーバプールの識別情報である。「ディスクＩＤ」は、「システムＩＤ」で示されるシステムに含まれるディスクの識別情報である。「ディスク容量」は、「ディスクＩＤ」で示されるディスクのディスク容量を示す情報である。「ストレージプール」は、「ディスクＩＤ」で示されるディスクが含まれるストレージプールの識別情報である。「帯域」は、「システムＩＤ」で示されるシステムに含まれるネットワークの帯域を示す情報である。

尚、システム情報４２は、図８に示す例に限定されず、システムの構成に応じて種々のデータ項目を含むことができる。

利用者情報４３は、利用者が利用するシステムの識別情報と、単位時間当たりの最大利用料金とを利用者毎に対応付けた情報である。図９は利用者情報４３の一例を示す。図９において利用者情報４３は、「利用者ＩＤ」、「システムＩＤ」、及び「最大利用料金」のデータ項目を含み、各データ項目はレコード毎に対応付けて記憶される。「利用者ＩＤ」は、利用者の識別情報である。「システムＩＤ」は、「利用者ＩＤ」で示される利用者が利用するシステムの識別情報である。尚、利用者情報４３の「システムＩＤ」は、システム情報４２の「システムＩＤ」と対応する。「最大利用料金」は、「システムＩＤ」で示されるシステムの、単位時間当たりの利用料金の最大値を示す情報である。尚、「最大利用料金」、すなわち、単位時間当たりの利用料金の最大値は、最大使用量情報の一例である。

課金情報４４は、利用者毎の、利用料金計算間隔の最小値、プリペイド残高、及び、次回計算時刻を対応付けた情報である。図１０は課金情報４４の一例を示す。図１０において課金情報４４は、「利用者ＩＤ」、「最小時間」、「残高」、及び「次回計算時刻」のデータ項目を含み、各データ項目はレコード毎に対応付けて記憶される。「利用者ＩＤ」は、利用者の識別情報である。尚、課金情報４４の「利用者ＩＤ」は、利用者情報４３の「利用者ＩＤ」と対応する。「最小時間」は、「利用者ＩＤ」で示される利用者に設定された利用料金計算間隔の最小値を示す情報である。尚、「最小時間」の値は予め定められた設定値である。「残高」は、「利用者ＩＤ」で示される利用者のプリペイド残高を示す情報である。尚、「残高」は、残余情報の一例である。「次回計算時刻」は、「利用者ＩＤ」で示される利用者の次回計算時刻を示す情報である。

メータリング情報４５は、仮想システム２１（サーバ、ストレージ、ネットワーク、各リソースを含む）の配備や稼働実績を記憶する情報であり、利用者毎のシステムの利用状況をメータリングして収集した情報である。図１１は、メータリング情報４５の一例を示す。図１１において、メータリング情報４５は、「サーバＩＤ」、「イベント」、及び「時刻」のデータ項目を含み、各データ項目はレコード毎に対応付けて記憶される。

「サーバＩＤ」は、サーバの識別情報である。尚、メータリング情報４５の「サーバＩＤ」は、システム情報４２の「サーバＩＤ」に対応する。「イベント」は、「サーバＩＤ」で示されるサーバに対して発生したイベントを示す情報である。「時刻」は、「サーバＩＤ」で示されるサーバに対して「イベント」で示されるイベントが発生した時刻を示す情報である。

尚、メータリング情報４５のデータ項目は図１１に示すものに限定されない。メータリング情報４５は、例えば、システムまたはリソース毎に対応付けられた、平均ＣＰＵ使用率、平均メモリ使用量、最小メモリ使用量、最大メモリ使用量などを含んでもよい。さらに、メータリング情報４５は、例えば、システムまたはリソース毎に対応付けられた、仮想マシンに割り当てられた最大ディスク領域量、合計受信ネットワークトラフィック量、合計送信ネットワークトラフィック量等の情報を含んでもよい。

課金管理部３２は、課金に関する処理を実行する。具体的には課金管理部３２は、単位時間当たりの最大利用料金の算出処理、次回計算時刻の算出処理、利用料金算出処理、及び残高更新処理を実行する。課金管理部３２による各処理について以下で説明する。

先ず、単位時間当たりの最大利用料金の算出処理について説明する。単位時間当たりの最大利用料金の算出処理において、課金管理部３２は、利用者毎に単位時間当たりの最大利用料金を算出し、利用者情報４３の各利用者に対応するレコードの「最大利用料金」に算出した値を格納する。

具体的には、利用者毎の単位時間当たりの最大利用料金の算出においては、課金管理部３２は、利用者が利用するシステムの構成と、そのシステムに含まれるリソースの単価に基づいて算出する。すなわち課金管理部３２は、リソース情報４１、システム情報４２、及びメータリング情報４５に基づいて、単位時間当たりの最大利用料金を算出する。課金管理部３２は、算出した最大利用料金を、利用者の識別情報とシステムの識別情報と対応付けて、利用者情報４３に格納する。

単位時間当たりの最大利用料金の算出について、以下に具体例を挙げて説明する。ここでは、利用者Ａが、仮想マシン１台、仮想ディスク（500GB）１本、帯域32Mbpsを含むシステムＡを利用すると仮定する。この情報は、予めシステム情報４２に格納されているものとする。また、各リソースの単価は、仮想マシンの起動状態の利用が10[円/H]、仮想ディスクの配備状態の利用が0.01[円/(H*GB)]、ＨＴＴＰ通信の利用が15[円/GB]であるとする。この情報は、予めリソース情報４１に格納されているものとする。また、システムＡに含まれるリソースはすべて配備中で且つ稼働中であるものとする。この情報は、メータリング情報４５に格納されているものとする。

課金管理部３２は、リソース情報４１とシステム情報４２を参照し、システムＡの情報とシステムＡに含まれる各リソースの単価の情報を取得する。また課金管理部３２は、メータリング情報４５を参照し、システムＡに含まれる各リソースの稼働または配備状況を取得する。そして、課金管理部３２は以下のように計算を行い、単位時間当たりの最大利用料金を算出する。ここでは、単位時間は1時間として説明する。すなわち課金管理部３２は、仮想マシン利用料金について、「10[円/H] * 1[台] = 10[円/H]」であると算出する。課金管理部３２は、仮想ディスク利用料金について、「0.01[円/(H*GB)] * 500[GB] * 1[本] = 5[円/H]」であると算出する。課金管理部３２は、HTTP通信利用料金について、「15[円/GB] * ((32[Mbps] / (8 * 1000)) * 3600[sec]) = 216[円/H]」であると算出する。そして課金管理部３２は、単位時間当たりの最大利用料金は、「10 + 5 + 216 = 231[円/H]」であると算出する。

次に、次回計算時刻の算出処理について説明する。次回計算時刻の算出処理においては、先ず課金管理部３２は、上述した式（１）を用いて候補時間を算出する。すなわち、課金管理部３２は、算出対象の利用者について、課金情報４４の「残高」の値を参照して、次回計算時刻の算出対象の利用者のプリペイド残高を取得する。そして課金管理部３２は、取得したプリペイド残高と、上述のように算出した単位時間当たりの最大利用料金とを用いて、式（１）より候補時間を算出する。次に課金管理部３２は、課金情報４４の「最小時間」の値を参照して、対象利用者についての利用料金計算間隔の最小値を取得する。次に課金管理部３２は、取得した利用料金計算間隔の最小値と候補時間とを比較し、比較の結果大きいほうの値（同じ値の場合はどちらかの値）を、次回利用料金を算出するまでの時間間隔と決定する。そして課金管理部３２は、決定した次回利用料金を算出するまでの時間間隔を、現在時刻に加えた時刻を次回計算時刻として設定し、課金情報４４における対象利用者のレコードの「次回計算時刻」に格納する。

次に、利用料金算出処理について説明する。利用料金算出処理は次回計算時刻が示す時刻に実行される。すなわち課金管理部３２は、課金情報４４における利用者のレコードの「次回計算時刻」を監視して、現在時刻が「次回計算時刻」が示す時刻になった場合に、利用料金算出処理を実行する。

利用料金算出処理においては、課金管理部３２は、メータリング情報４５を参照して、算出対象の利用者の利用実績を取得する。そして課金管理部３２は、取得した利用実績及びリソース情報４１に基づいて、利用料金を算出する。具体的には例えば、課金管理部３２は、先ず、利用者が利用したシステムに含まれる各リソースの利用実績値を、メータリング情報４５から取得する。各リソースは、例えば、仮想マシン、ストレージ、データベース、ネットワーク等であり、利用者が利用するシステムは、各リソースのうちの１つまたは所定の組み合わせを含んでもよい。各リソースの利用実績値としては、例えば、データ転送量、ディスク使用量、メモリ使用量、またはＣＰＵ使用率等を含んでもよい。次に課金管理部３２は、利用者が利用したシステムに含まれる各リソースの単価をリソース情報４１から取得する。そして課金管理部３２は、利用者が利用したシステムに含まれるリソースそれぞれについて、利用実績と単価を掛け合わせて、全てのリソースの合計した値を利用料金として算出する。

次に、残高更新処理について説明する。残高更新処理は、利用料金の算出処理が行われた後、または、利用者から利用料金の前払いがあった場合に実行される。

利用料金の算出処理が行われた後に実行される残高更新処理においては、先ず課金管理部３２は、課金情報４４における利用者のレコードの「残高」を参照し、利用者のプリペイド残高を取得する。次に課金管理部３２は、取得したプリペイド残高から、利用料金算出処理において算出した利用料金を差し引く。そして課金管理部３２は、差し引き後のプリペイド残高を新たなプリペイド残高として、課金情報４４の「残高」に格納する。

利用者から利用料金の前払いがあった場合に実行される残高更新処理においては、課金管理部３２は、利用者からの前払いで支払われた金額を示す情報を取得する。また課金管理部３２は、課金情報４４における利用者のレコードの「残高」を参照し、利用者のプリペイド残高を取得する。次に課金管理部３２は、取得したプリペイド残高に、取得した前払いで支払われた金額を加える。そして課金管理部３２は、前払いで支払われた金額を加えた後のプリペイド残高を新たなプリペイド残高として、課金情報４４の「残高」に格納する。

尚、利用者からの利用料金の前払いは、例えば利用者の口座への入金を通じて行われてもよい。この場合、入金を受け付けた他の入金を管理するシステムから、通信ネットワーク等を介して口座への入金情報を受信することにより、課金管理部３２は利用者からの前払いで支払われた金額を示す情報を取得してもよい。

システム管理部３３は、仮想システム２１のサービス全体の管理を行う。仮想システム２１の構成が変更された場合には、システム管理部３３は、変更された構成についての情報をリソース情報４１及びシステム情報４２に反映する。尚、仮想システム２１の構成の変更があった場合は、システム管理部３３は利用者情報管理部３５から通知を受信することによりシステムの構成の変更を検出する。尚、システムの構成の変更には、システムに含まれる各リソースの単価の変更も含まれる。

ネットワーク管理部３４は、プリペイド残高がなくなった場合に、利用者端末２２による仮想システム２１の利用停止制御を行う。すなわち、例えばネットワーク管理部３４は、課金情報４４の「残高」の値を監視し、「残高」の値が「1」未満となった場合に、そのレコードの利用者の仮想システム２１の利用停止制御を行う。仮想システム２１の利用停止制御において、例えばネットワーク管理部３４は、利用者端末２２と仮想システム２１の間の通信を中継する中継装置２４を制御し、中継装置２４におけるアクセス制御やルーティングテーブルを変更してもよい。また仮想システム２１の利用停止制御において、例えばネットワーク管理部３４は、利用者に割り当てられたVirtual LAN（ＶＬＡＮ）の削除又は変更等を行ってもよい。尚、ネットワーク管理部３４による仮想システム２１の利用停止制御は、利用者端末２２に対して利用料の超過が発生している旨の通知を行うことで利用者に対して注意喚起を行う処理等としてもよい。

利用者情報管理部３５は、利用者毎の仮想システム２１（サーバ、ストレージ、ネットワーク、各リソース等）の利用状況をメータリングして情報を収集し、メータリング情報４５に格納する。例えば利用者情報管理部３５は、仮想システム２１の配備、稼動実績を収集し、メータリング情報４５に格納する。また利用者情報管理部３５は、仮想システム２１に含まれる各リソースの利用実績、すなわち、ＣＰＵ使用率、ディスクの使用量、またはネットワークの使用量等の情報を収集して、メータリング情報４５に格納してもよい。

また利用者情報管理部３５は、メータリングにより収集した情報に基づいて、仮想システム２１の構成の変更を検出する。そして利用者情報管理部３５は、システムの構成が変更された旨、及び変更箇所を示す情報をシステム管理部３３に通知する。

次に、実施形態に係る課金処理装置２３の処理の流れについて説明する。図１２は、実施形態に係る課金処理装置２３の処理の詳細を図解したフローチャートの一例である。図１２のフローにおいては、課金処理の対象となる利用者を対象利用者として記す。また、図１２のフローにおいては、処理の開始前に、利用者により、仮想システムの利用申請が行われ、また、プリペイド残高にチャージが行われているものとする。

図１２において、先ず課金管理部３２は、対象利用者の単位時間当たりの最大利用料金の算出処理を行う（Ｓ１０１）。すなわち課金管理部３２は、リソース情報４１、システム情報４２、及びメータリング情報４５に基づいて、対象利用者の単位時間当たりの最大利用料金を算出する。

次に課金管理部３２は、対象利用者の次回計算時刻の算出処理を実行する（Ｓ１０２）。すなわち課金管理部３２は、先ず、Ｓ１０１で算出した対象利用者の単位時間当たりの最大利用料金と、対象利用者のプリペイド残高とを用いて、式（１）より候補時間を算出する。そして課金管理部３２は、対象利用者の利用料金計算間隔の最小値と候補時間との比較を行い、大きいほうの値を現在時刻（Ｓ１０２の処理時刻）に加えた時刻を次回計算時刻として算出する。

次に利用者情報管理部３５は、メータリングを行い、利用者毎の仮想システム２１の利用状況を収集し、メータリング情報４５に格納する（Ｓ１０３）。

次に利用者情報管理部３５は、メータリングにより収集した情報に基づいて、仮想システム２１の構成に変更があるか否かを判定する（Ｓ１０４）。仮想システム２１の構成に変更があると判定された場合（Ｓ１０４でＮｏ）、処理は再びＳ１０１に遷移し、単位時間当たりの最大利用料金の算出処理が行われる。

一方、仮想システム２１の構成に変更がないと判定された場合（Ｓ１０４でＹｅｓ）、課金管理部３２は、利用者からの利用料金の前払いによりプリペイド残高が増加したか否かを判定する（Ｓ１０５）。プリペイド残高が増加したと判定された場合（Ｓ１０５でＹｅｓ）、処理は再びＳ１０２に遷移し、再度、次回計算時刻の算出処理が行われる。

一方、プリペイド残高が増加していないと判定された場合（Ｓ１０５でＮｏ）、課金管理部３２は、現在時刻（Ｓ１０６の処理時刻）が、Ｓ１０２で算出された次回計算時刻に到達したか否かを判定する（Ｓ１０６）。現在時刻が次回計算時刻に到達していないと判定された場合（Ｓ１０６でＮｏ）、処理は再度Ｓ１０３に遷移し、メータリングが行われる。

一方、現在時刻が次回計算時刻に到達したと判定した場合（Ｓ１０６でＹｅｓ）、課金管理部３２は、利用料金の算出処理を実行する（Ｓ１０７）。すなわち、例えば課金管理部３２は、メータリング情報４５から取得した利用実績及びリソース情報４１から取得した各リソースの単価に基づいて、利用料金を算出する。

次に課金管理部３２は、利用料金の算出処理が行われた後に実行される残高更新処理を実行する（Ｓ１０８）。すなわち課金管理部３２は、プリペイド残高から、Ｓ１０７で算出した利用料金を差し引いて、差し引き後のプリペイド残高を新たなプリペイド残高として設定する。

次にネットワーク管理部３４は、プリペイド残高が「1」未満か否かを判定する（Ｓ１０９）。プリペイド残高が「1」以上であると判定された場合（Ｓ１０９でＮｏ）、処理は再度Ｓ１０２に遷移し、次回計算時刻の算出が行われる。

一方、プリペイド残高が「1」未満であると判定した場合（Ｓ１０９でＹｅｓ）、ネットワーク管理部３４は、仮想システム２１の利用停止制御を行う（Ｓ１１０）。そして処理は終了する。

次に、実施形態に係る課金処理装置２３のハードウェア構成の一例を説明する。図１３は、実施形態に係る課金処理装置２３のハードウェア構成の一例を示す。

図１３において、課金処理装置２３は、ＣＰＵ５１、メモリ５２、記憶装置５３、読取装置５４、入力装置５５、及び通信インターフェース５６を含む。ＣＰＵ５１、メモリ５２、記憶装置５３、読取装置５４、入力装置５５、及び通信インターフェース５６はバス等を介して接続される。

ＣＰＵ５１は、メモリ５２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、課金管理部３２、システム管理部３３、ネットワーク管理部３４、及び利用者情報管理部３５の一部または全部の機能を提供する。

メモリ５２は、例えば半導体メモリであり、Random Access Memory（ＲＡＭ）領域およびRead Only Memory（ＲＯＭ）領域を含んで構成される。メモリ５２は記憶部３１の一部または全部の機能を提供する。記憶装置５３は、例えばハードディスクである。なお、記憶装置５３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置５３は、外部記録装置であってもよい。記憶装置５３は、記憶部３１の機能を提供してもよい。

読取装置５４は、ＣＰＵ５１の指示に従って着脱可能記憶媒体６０にアクセスする。着脱可能記憶媒体６０は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。尚、読取装置５４は課金処理装置２３に含まれなくてもよい。

入力装置５５は、利用者毎の利用料金計算間隔の最小値の入力を受け付ける。尚、入力装置５５は課金処理装置２３に含まれなくてもよい。

通信インターフェース５６は、ＣＰＵ５１の指示に従ってネットワークを介して、中継装置２４、仮想システム２１、及び利用者端末２２等と通信する。ネットワーク管理部３４は、通信インターフェース５６を介して中継装置２４に接続し、利用者の仮想システム２１の利用停止を制御する。また、利用者情報管理部３５は、通信インターフェース５６を介して、仮想システム２１からメータリングにより仮想システム２１の利用状況を示す情報を収集する。

実施形態のプログラムは、例えば、下記の形態で課金処理装置２３に提供される。
（１）記憶装置５３に予めインストールされている。
（２）着脱可能記憶媒体６０により提供される。
（３）プログラムサーバ（図示せず）から通信インターフェース５６を介して提供される。

さらに、実施形態の課金処理装置２３の一部は、ハードウェアで実現してもよい。或いは、実施形態の課金処理装置２３は、ソフトウェアおよびハードウェアの組み合わせで実現してもよい。

尚、実施形態においては、クラウドサービスで提供されるサービスはハードウェア資源として説明したが、提供されるサービスはソフトウェア等としてもよい。

尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 課金処理装置
２ 記憶部
３ 更新部
４ 制御部
５ 変更部
１１ 仮想システム
１２ 利用者端末
１３ 課金処理装置
２１ 仮想システム
２２ 利用者端末
２３ 課金処理装置
２４ 中継装置
３１ 記憶部
３２ 課金管理部
３３ システム管理部
３４ ネットワーク管理部
３５ 利用者情報管理部
４１ リソース情報
４２ システム情報
４３ 利用者情報
４４ 課金情報
４５ メータリング情報
５１ ＣＰＵ
５２ メモリ
５３ 記憶装置
５４ 読取装置
５５ 入力装置
５６ 通信インターフェース
６０ 着脱可能記憶媒体

Claims (8)

1. サービスの使用可能量に対する残余量を示す残余情報を記憶する記憶部と、
   前記サービスの使用量に応じて、前記残余情報を更新する更新部と、
   更新された前記残余情報に基づいて、前記更新部による次の前記更新のタイミングを制御する制御部と、
   を備えることを特徴とする課金処理装置。
2. 前記記憶部は、さらに、単位時間当たりの前記サービスの使用量の最大値を示す最大使用量情報を記憶し、
   前記制御部は、前記更新された残余情報と前記最大使用量情報とに基づいて、次の前記更新のタイミングを制御する
   ことを特徴とする請求項１に記載の課金処理装置。
3. 前記制御部は、前記残余情報が更新された場合、前記更新された残余情報と前記最大使用量情報とに基づいて、前記次の更新の実行時刻を算出し、該算出した実行時刻に前記更新を行うように前記更新部を制御する
   ことを特徴とする請求項２に記載の課金処理装置。
4. 前記課金処理装置は、さらに、
   前記サービスの使用形態に応じて、前記最大使用量情報を変更する変更部
   を備え、
   前記制御部は、前記最大使用量情報が変更された場合、前記残余情報と前記最大使用量情報とに基づいて、前記次の更新の実行時刻を算出し、該算出した実行時刻に前記更新を行うように前記更新部を制御する
   ことを特徴とする請求項２または３に記載の課金処理装置。
5. 前記制御部は、前記残余情報が所定の閾値以下である場合、予め定められた設定値に基づいて、前記次の更新の実行時刻を算出し、該算出した実行時刻に前記更新を行うように前記更新部を制御する
   ことを特徴とする請求項１〜４のうちいずれか１項に記載の課金処理装置。
6. 前記更新部は、前記サービスの使用量に応じた使用料金を算出し、算出した該使用料金を、前記残余情報から差し引いて、新たな前記残余情報を算出し、
   前記使用料金は、仮想マシン、ストレージ、データベース、ネットワーク、データ転送量のうちの１つまたは所定の組み合わせの使用形態に応じて予め設定される使用料金に基づいて算出される値である
   ことを特徴とする請求項１〜５のうちいずれか１項に記載の課金処理装置。
7. サービスの使用量に応じて、該サービスの使用可能量に対する残余量を示す残余情報を記憶する記憶部に記憶された前記残余情報を更新し、
   更新された前記残余情報に基づいて、次の前記更新のタイミングを制御する
   処理をコンピュータが実行することを特徴とする課金処理方法。
8. コンピュータに、
   サービスの使用量に応じて、該サービスの使用可能量に対する残余量を示す残余情報を記憶する記憶部に記憶された前記残余情報を更新し、
   更新された前記残余情報に基づいて、次の前記更新のタイミングを制御する
   処理を実行させることを特徴とする課金処理プログラム。

Images