JP4445686B2

JP4445686B2 - 分散課金処理システムでの残金管理方法、残金管理プログラム及び分散課金処理システム

Info

Publication number: JP4445686B2
Application number: JP2001249778A
Authority: JP
Inventors: 隆久吉田
Original assignee: Hitachi Software Engineering Co Ltd
Current assignee: Hitachi Software Engineering Co Ltd
Priority date: 2001-08-21
Filing date: 2001-08-21
Publication date: 2010-04-07
Anticipated expiration: 2021-08-21
Also published as: JP2003058717A

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の分散サーバと少なくとも一つの管理サーバとを用いて多数のユーザに対する課金を分散して処理する分散課金処理システムにおける各ユーザの残金を管理する方法、残金管理プログラム及び分散課金処理システムに関する。
【０００２】
【従来の技術】
インターネット上の買物等により電子マネーを利用するユーザが増大している。多数のユーザに対する電子マネーを用いた課金処理を単一のサーバにより処理することは、負荷が単一のサーバに集中することによる処理速度の低下、サーバに障害が発生したときの影響の波及範囲等の点でも問題があり、多くのユーザに対する課金処理を複数のサーバ（以下、分散サーバと呼ぶ）により分散させて処理させるのが現実的である。
【０００３】
ネットワークを介して実行される多数のユーザによる取引に対して一つの管理サーバ（ホームサーバとも呼ばれることがある）と複数の分散サーバを用いて課金処理を実行する分散課金処理システムの一例が、特開２０００−７６３３２号公報に記載されている。この分散課金処理システムでは、各ユーザがあらかじめ支払った金の残金の一部を管理サーバから各分散サーバにあらかじめ送金しておく。いずれかの分散サーバにおいて、いずれかのユーザに対する課金処理を実行するときに、当該分散サーバ内の当該ユーザの残金が当該課金処理に必要な額より多い場合、当該分散サーバ内の当該ユーザの残金を用いて当該課金処理を実行し、それにより管理サーバと交信しないで、課金処理を当該分散サーバで実行する。
【０００４】
しかし、当該分散サーバにおける当該ユーザの残金が課金処理に必要な額より不足している場合には、当該不足額の送金を当該分散サーバより管理サーバに要求する。管理サーバ内にある当該ユーザの残金から要求された不足額の残金を当該要求元のサーバに当該管理サーバから送金する。もし管理サーバ内の当該ユーザに対する残金が要求された不足額に足りないとき、要求元の分散サーバ以外の他の分散サーバから管理サーバにより当該ユーザの残金を回収して、当該回収された残金を用いて要求された不足額の残金を当該管理サーバから当該要求元のサーバに送金している。
【０００５】
なお、上記特開２０００−７６３３２号公報では、分散サーバと管理サーバとの間の残金の送金回数を減らすために、要求元の分散サーバ以外の他の分散サーバから管理サーバにより回収される当該ユーザの残金の額を、当該不足額より多い額にすることを提案している。典型的には、当該他の分散サーバにおける当該ユーザの残金の半分が管理サーバに送金される。
【０００６】
【発明が解決しようとする課題】
特開２０００−７６３３２号公報に記載の分散課金処理システムでは、各分散サーバにおいてユーザに対して課金処理を実行する時点で、当該ユーザの残金が不足であると判明したときに、管理サーバに対して不足額の送金を要求し、管理サーバが、その要求を受けてから不足額を当該分散サーバに送金する。管理サーバの負荷が大きいときには、管理サーバがこの要求を処理するまでに時間が掛かることがある。あるいはネットワークが混雑し、管理サーバと分散サーバの間の通信に時間が掛かることがある。こうして、管理サーバが不足額の送金の要求を分散サーバから受けてから分散サーバに不足額を送金するまでに時間が掛かることが起きる。この間、ユーザは課金処理の完了を待つ状態になり、分散サーバの処理能力も低下することになる。
【０００７】
買物の実態を調べると、高額の品物をごくまれに購入するという利用形態以外に、ほぼ毎日あるいはそれに近い頻度で少額の品物を購入するという用途もある。例えば、日常の食品、書籍、売店やコンビニエンスストアに置かれているような小物とかの商品の購入の場合である。後者のような品物を購入するユーザに対して、買物のたびに残金の不足が発生し分散サーバから管理サーバに不足した残金の送金を要求すると、ユーザが課金処理の完了待ち状態になる頻度が高くなる。
【０００８】
したがって、本発明の目的は、少なくとも一つの管理サーバと複数の分散サーバからなる分散管理システムにおいて、いずれかの分散サーバによりいずれかのユーザの課金処理を実行するときにユーザの残金不足が発生する頻度を減らし、もって残金不足が発生した場合に必要となる不足額送金による課金処理時間の増大を防ぐことである。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る残金管理方法は、複数の分散サーバと、少なくとも一つの管理サーバとを有し、ユーザがあらかじめ支払った金の残金を管理し、ユーザが商品又はサービスを購入したときに当該ユーザに対する課金を購入額に応じて処理する分散課金処理システムにおける残金管理方法である。
【００１０】
より具体的には、前記分散課金処理システムは、各ユーザがあらかじめ支払った金の残金の一部を前記管理サーバから各分散サーバにあらかじめ送金し、いずれかの分散サーバにおいて、いずれかのユーザに対する課金処理を実行するときに、当該分散サーバ内の当該ユーザの残金が当該課金処理に必要な額より多い場合、当該分散サーバ内の当該ユーザの残金を用いて当該課金処理を実行し、当該分散サーバにおける当該ユーザの残金が課金処理に必要な額より不足している場合、当該不足額の送金を当該分散サーバより前記管理サーバに要求し、前記管理サーバ内にある当該ユーザの残金から前記要求された不足額の残金を当該要求元のサーバに当該管理サーバから送金し、若しくは前記管理サーバ内の前記ユーザに対する前記残金が前記要求された不足額に足りないとき、少なくとも当該足りない額の残金を前記要求元の分散サーバ以外の他の分散サーバから前記管理サーバにより回収して、当該回収された残金を用いて前記要求された不足額の残金を当該管理サーバから当該要求元のサーバに送金する分散課金処理システムである。
【００１１】
本発明に係る残金管理方法は、前記管理サーバにより、各分散サーバにおける各ユーザの残金が当該ユーザ毎にあらかじめ定められた補充基準額に達しているか否かを定期的に検査し、前記検査の結果、いずれかのユーザのいずれかの分散サーバ内の残金が前記補充基準額から不足していることが判明したとき、前記管理サーバ内の当該ユーザの残金のうち当該補充基準額からの不足額を当該分散サーバ内の当該ユーザの残金に対して補充する、ステップを含むものである。
【００１２】
これにより、いずれかの分散サーバにおけるいずれかのユーザの残金が当該ユーザに対してあらかじめ定めた補充基準額に達していない場合、管理サーバから当該分散サーバに当該ユーザの残金があらかじめ補充される。したがって、当該ユーザが後に買物をしたとき、買物に伴う課金が上記補充基準額以上であれば、当該分散サーバにおいて残金の不足が発生しないので、当該分散サーバから管理サーバに対して不足額の送金要求が発せられることはなく、当該ユーザに対する課金処理を当該分散サーバにより迅速に実行できる。
【００１３】
具体的には、前記検査は、毎日あらかじめ定めた条件を満たす時刻又は時間帯に実行される。上記時刻又は時間帯は、例えば、ユーザの利用が減少して分散サーバ及び管理サーバの負荷が大幅に減少する深夜の一定の時刻帯である。あるいは分散サーバ及び管理サーバの負荷を検出してあらかじめ定めた負荷限界値より小さいことが検出されたときに、上記検査を行うようにしてもよい。更に、各ユーザに対して定められた前記補充基準額は、当該ユーザがあらかじめ支払った残金の額に依存して定められる。例えば、各ユーザがあらかじめ支払った金の額に比例して当該ユーザに対する補充基準額を決めてもよい。前記検査は、前記管理サーバにより実行されることが望ましい。しかし、前記検査は、前記複数の分散サーバにより分散して実行されることが望ましい場合もある。
【００１４】
【発明の実施の形態】
以下、本発明に係る分散課金処理システム、残金管理方法及び残金管理プログラムの実施の形態を図面を参照して詳細に説明する。
【００１５】
図１は、本発明に係る分散課金処理システムの一つの実施の形態のシステム構成図である。本分散課金処理システムは、各ユーザに対する課金をそれぞれ行うための複数の分散サーバ１３０、１４０と、これらの分散サーバへの各ユーザの残金の供給を管理するための少なくとも一つの管理サーバ１０１とを有する。本システムは、ユーザがあらかじめ支払った金（以下、プリペイドマネーと呼ぶことがある）の残金を管理し、ユーザが商品又はサービスを購入したときに当該ユーザに対して実行する課金を購入額に応じて処理する。
【００１６】
図では分散サーバは二つのみ示されているが、使用される分散サーバの数は特に限定されない。本分散課金処理システムにより管理される残金は、電子マネーの形態で管理されてもよく、電子マネーを用いないで残金の金額だけが管理されてもよい。
【００１７】
課金の対象となる買物は、いろいろな形態で実行することができる。端末１５１又は１５２は、インターネット上の市場をアクセスするパソコン（PC）や、カードを入力できる特殊な端末の場合も考えられる。いずれの場合も、端末１５１又は１５２からの分散サーバ１３０又は１４０へのアクセスは、負荷分散装置１５０を介して行われるものとする。以下ではいろいろな買物の実行形態の例を図２を参照して更に詳しく説明する。
【００１８】
なお、同図において、符号又は記号は次を意味する。１５０は図１の負荷分散装置１５０であり、１５１は図１の端末１５１である。ＳＴは店員が操作する端末、ＰＴは購買者が操作する端末、ＰＣは家庭内のパソコンである。両方向矢印（←→）は商品の参照・選択を示し、片方向矢印（→）は購入した商品の精算を示す。図２において、負荷分散装置１５０には、実際には図１に示された複数の分散サーバ１３０、１４０と管理サーバ１０１とがインターネット、イントラネット、ＬＡＮその他のネットワークを介して接続されているが、図２ではこれらのサーバは簡単化のために図示されていない。また、端末１５０、１５１と負荷分散装置１５０は、インターネット、イントラネット、ＬＡＮその他の適当なネットワークを介して接続されるが、図にはそのネットワークを特に示していない。負荷分散装置１５０と複数の分散サーバ１３０、１４０と管理サーバ１０１とを接続するネットワークについても同様である。
【００１９】
第１の例は、図２（ａ）に示すように、書籍、日常の食品、売店やコンビニエンスストアに置かれているような小物等の商品を販売している実店舗において、購買者が購入した商品の精算に使用する店内端末ＳＴが端末１５１（以下、端末＃１と呼ぶことがある）あるいは端末１５２（端末＃２と呼ぶことがある）の場合である。この場合は、店員が端末１５１を操作する。
【００２０】
第２の例は、同図（ｂ）又は（ｃ）に示すように、購買者が端末１５１を操作して購入する商品を選択し、かつこれら商品の中から購入する商品について購買者自身が端末１５１を操作してその精算をする場合である。この場合、端末１５１は店員のいる実店舗内にあってもよく、また端末１５１だけが設置されている無人店舗であってもよい。さらに、同図（ｂ）のように、購買者に提示する商品の保有元が端末１５１であってもよく（ローカル保有）、同図（ｃ）に示すように、端末１５１とは異なるサーバＧが保有している（リモート保有）商品を端末１５１がネットワークを経由してこの装置から取寄せて購買者に提示してもよい。
【００２１】
第３の例は、同図（ｄ）から（ｇ）に示すように、購買者が家庭内パソコン（ＰＣ）を使用してオンラインショッピングする場合である。購買者によるＰＣの操作によって提示された商品を参照して購入する商品を選択し、かつこれら商品の中から購入する商品について購買者が該ＰＣを操作してその精算をする。購買者の精算操作によって該ＰＣが負荷分散装置１５０であるサーバＬに直接的または間接的に接続される。この場合、同図（ｄ）と（ｅ）においてはＰＣが端末１５１であり、同図（ｆ）と（ｇ）においてはサーバＶが端末１５１である。さらに、同図（ｄ）と（ｆ）のようにＰＣと隣接するサーバが一つであってもよく、また同図（ｅ）と（ｇ）のように隣接するサーバが複数であってもよい。
【００２２】
なお、商品あるいはサービスはその場でユーザが受け取ってもよくあるいは別の時刻、別のところで受け取ってもよい。必要なら、購入時には購入したユーザを特定するための情報（ユーザＩＤ）が入力される。ユーザＩＤは各ユーザ用に別に準備されたカードに記憶され、このカードを使用してユーザＩＤが入力されてもよい。
【００２３】
端末＃１及び端末＃２からの購入に対する課金処理を実行するときには、負荷分散装置１５０により分散サーバ１３０、１４０の一つが選択され、選択された分散サーバにより課金処理が実行される。負荷分散装置１５０は、多数のユーザに対する課金処理を複数の分散サーバにより分散して処理させる。各ユーザに対する課金処理を実行すべき分散サーバの選択は、課金処理を実行すべき契機ごとに、複数の分散サーバをあらかじめ定められた順番にしたがって順次選択するようにしてもよい。他の方法、例えば課金処理を実行すべきユーザのユーザＩＤに基づいて、課金処理すべき分散サーバを選択することもできる。
【００２４】
図３は、管理サーバ１０１に組み込まれた主なプログラム及び関連するデータを示す。管理サーバ１０１では、ユーザ個別設定プログラム１０５、全体課金額制御プログラム１０７、分散サーバ補充プログラム１１１が実行される。より具体的には、全体課金額制御プロセス１０６は、全体課金額制御プログラム１０７を実行するものであり、管理サーバ１０１に対して一つ存在する。管理サーバ１０１上では、ユーザ個別設定プロセス１０４は、各ユーザに対応して存在し、対応するユーザに関してユーザ個別設定プログラム１０５を実行する。分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０は、それぞれ分散サーバ１３０又は１４０に対応して存在し、対応する分散サーバに関して分散サーバ補充プログラム１１１又は１２１を実行する。
【００２５】
管理サーバ１０１には、管理サーバ１０１内のユーザ毎の残金の管理に使用するために全体課金額テーブル１０８が設けられる。更に、各分散サーバ１３０又は１４０内のユーザ毎の残金を管理するためのテーブルとして、分散サーバ＃１対応残金テーブル１１２又は分散サーバ＃２対応残金テーブル１２２が更に設けられている。更に、管理１０１の動作の制御のために制御パラメータテーブル１０３が設けられている。
【００２６】
図４は、複数の分散サーバ１３０、１４０に組み込まれた主なプログラムと関連するデータの例を示す。分散サーバ１３０又は１４０上では、分散サーバ課金額制御プロセス１３１又は１４１が、当該分散サーバ１３０又は１４０上で一つ実行される。分散サーバ課金額制御プロセス１３１又は１４１は、それぞれ分散サーバ課金額制御プログラム１３２又は１４２を実行するものである。各分散サーバ１３０又は１４０には、当該分散サーバ内のユーザ毎の残金を管理するために、分散サーバ内残金テーブル１３３又は１４３が設けられる。
【００２７】
各ユーザがあらかじめ支払った金は、管理サーバ１０１の全体課金額制御プロセス１０６により、管理サーバ１０１及び各分散サーバ１３０、１４０に当該ユーザの残金として分散して設定される。すなわち、全体課金額制御プロセス１０６は、当該ユーザの額をあらかじめ定めた基準にしたがって管理サーバ１０１用の残金、各分散サーバ１３０又は１４０用の残金に分割し、それぞれの残金を管理サーバ１０１、各分散サーバ１３０又は１４０に設定する。管理サーバ又は分散サーバに設定すべき残金の決定方法は後に説明する。各分散サーバ１３０又は１４０へのユーザ別の残金の設定は、全体課金額制御プロセス１０６が、各分散サーバ１３０又は１４０内の分散サーバ課金額制御プロセス１３１又は１４１と交信して実行する。
【００２８】
いずれかのユーザが購入した商品あるいはサービスに対する課金をいずれかの分散サーバ１３０又は１４０において処理するときに、当該分散サーバ１３０又は１４０内の当該ユーザの残金が不足していることが判明した場合には、その分散サーバ１３０又は１４０内の分散サーバ課金額制御プロセス１３１又は１４１より管理サーバ１０１内のユーザ個別設定プロセス１０４に不足分の補充を要求する。
【００２９】
ユーザ個別設定プロセス１０４は、要求された不足分の補充を全体課金額制御プロセス１０６に要求する。全体課金額制御プロセス１０６は、全体課金額テーブルに登録された当該ユーザの残金の一部を要求された不足額の補充に使用する。こうして、いずれかの分散サーバにおいて課金すべき金額に比べてユーザの残金が不足した場合、その都度、当該分散サーバが管理サーバ１０１に要求して不足額を当該分散サーバに補充する。
【００３０】
なお、このような購入に伴う課金処理において不足額を管理サーバ１０１が補充する場合、管理サーバ１０１内の当該ユーザの残金が不足している場合も起こりうる。そのような場合には、管理サーバ１０１の全体課金額制御プロセス１０６は、他の分散サーバ、例えば１４０の分散サーバ課金額制御プロセス１４１と交信して当該他の分散サーバ１４０内の同じユーザの残金から不足額を回収し、要求元の分散サーバに補充する。
【００３１】
このような、ユーザが商品あるいはサービスを購入したときの課金に必要な残金が不足していることができるだけ発生しないように、管理サーバ１０１内の分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０は、対応する分散サーバ１３０又は１４０での各ユーザの残金があらかじめ定めた補充基準額より不足しているか否かを定期的に検査するようになっている。
【００３２】
この検査は、毎日あらかじめ定められた条件の時点、例えば分散サーバにおける処理負荷が小さい夜間に行われる。この検査の結果、もしいずれかの分散サーバにおいていずれかのユーザの残金が上記補充基準額より少ないことが判明したとき、その分散サーバ１３０又は１４０に対応する分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０が、その時点であらかじめその分散サーバ１３０又は１４０のそのユーザの残金を補充基準額まで管理サーバ１０１から補充する。
【００３３】
これにより、ユーザが買物をしたとき、課金額が上記補充基準額より少ないときには、課金処理を実行する段階になって残金不足が発生しない。したがって、分散サーバでの残金の不足が発生する回数を減らすことができる。その結果、残金不足が発生した場合に必要な、分散サーバと管理サーバとの間の残金の移動回数を減らすことができ、分散サーバでの課金処理に要する時間を減らすことができる。
【００３４】
図５は、図１のシステムで使用されるいろいろなデータの例を示す図である。同図（ａ）は、全体課金額テーブル１０８の一例を示す。全体課金額テーブル１０８には、各ユーザに対応して、当該ユーザの識別情報（ユーザＩＤ）１０８Ａ、当該ユーザの管理サーバ１０１内の残金１０８Ｂ、補充基準額１０８Ｃ、排他フラグ１０８Ｄ等が記憶される。補充基準額１０８Ｃは、既に述べたように、当該ユーザの残金として各分散サーバに補充すべき額を示す。残金の不足が発生する前に行うこのような補充を便宜的に事前補充と呼ぶ。事前補充の額をユーザ毎に定めることもできる。排他フラグ１０８Ｄについては後に説明する。
【００３５】
同図（ｂ）は、分散サーバ１３０に対応して管理サーバ１０１に記憶される、分散サーバ＃１対応残金テーブル１１２の例を示す。分散サーバ＃２対応残金テーブル１２２も全く同じ構造を有する。図に示すように、分散サーバ＃１対応残金テーブル１１２には、各ユーザのユーザＩＤ１１２Ａと、当該ユーザの対応する分散サーバ、今の例では１３０における残金１１２Ｂ及び増額分１１２Ｃとが記憶される。増額分１１２Ｃは後に説明する。
【００３６】
図５（ｃ）は、分散サーバ１３０内に記憶される分散サーバ内残金テーブル１３３の例を示す。分散サーバ内残金テーブル１４３も全く同じ構造を有する。図に示すように、分散サーバ内残金テーブル１３３には、各ユーザのユーザＩＤ１３３Ａと、当該ユーザの当該分散サーバ１３０における残金１３３Ｂとが記憶される。
【００３７】
図５（ｄ）は、制御パラメータテーブル１０３の一例を示す。時刻条件１０３Ａには、各サーバに基準補充額まで事前補充を行う時刻又は時間帯に関する条件があらかじめ記憶される。例えば、夜間の所定の時刻が記憶される。事前補充は１日に複数回実行されてもよい。その場合には、時刻条件１０３Ａには、複数の時刻が指定される。あるいは一つの時刻とその時刻からの経過時間が指定されてもよい。
【００３８】
負荷条件１０３Ｂは、分散サーバに対して事前補充の処理を行ってもよい処理負荷の限界値が記憶される。分散サーバの処理負荷がこの限界値より大きいときには、分散サーバが課金処理を行っているときであると推測され、この課金処理を遅延させないように、事前補充処理は、課金処理が終了し分散サーバの処理負荷が小さくなった時点で実行するのが望ましい。
【００３９】
補充基準額決定データ１０３Ｃには、事前補充で補充される補充基準額を決定するためのデータが記憶される。補充基準額は、いろいろの方法により決めることができる。本実施の形態では、ユーザは、買物をする前に、あらかじめ定めた額の金を買物用に支払い、この金が管理サーバ１０１にユーザの残金として使用される。
【００４０】
ユーザによりあらかじめ支払われた額に応じてそのユーザの残金に関する補充基準額を変えることができる。例えば、補充基準額決定データ１０３Ｃは、金額１０３Ｃ１と基準使用日数１０３Ｃ２を含んでいる。金額１０３Ｃ１には、利用可能なプリペイドマネーの額Ｐ１、Ｐ２、Ｐ３等が記憶される。基準使用日数１０３Ｃ２には、それぞれの金額に対応してあらかじめ定められた基準使用日数Ｎ１、Ｎ２、Ｎ３等が記憶される。
【００４１】
このようなデータを使用すると、プリペイドマネーの金額がＰ１、Ｐ２又はＰ３の場合、一日あたりの平均使用額は、それぞれＰ１／Ｎ１、Ｐ２／Ｎ２又はＰ３／Ｎ３等となる。例えば、Ｐ１、Ｐ２、Ｐ３はそれぞれ２万円、６万円、１５万円とし、Ｎ１、Ｎ２、Ｎ３をそれぞれ２０、２０、３０とすることもできる。この例の場合、Ｐ１／Ｎ１＝１０００円、Ｐ２／Ｎ２＝３０００円、Ｐ３／Ｎ３＝５０００円となる。これらの額がそれぞれ金額Ｐ１、Ｐ２、Ｐ３のプリペイドマネーに対する補充基準額として使用される。
【００４２】
ユーザは、自分の平均的な一日の使用額を考慮して、一月で利用する可能性がある額の総額を決め、その一日の使用額若しくはそれに近い補充基準額を与え、一月の使用総額に近い金額を月１回程度の頻度であらかじめ支払うことができる。例えば、１日平均１０００円ずつ使用し一月に２０日程買物をする人は、金額Ｐが１０００円×２０＝２万円で、基準使用日数Ｎが２０日に近い、ＰとＮの組を有する金を事前に支払っておく。上の例では、Ｐ１＝２万円、Ｎ１＝２０のプリペイドマネーをあらかじめ支払えばよい。もちろん買物をするに伴い残金が不足したときには、新たなプリペイドマネーを支払う必要がある。
【００４３】
上の例にあるＰ１、Ｐ２のように、金額Ｐ１とＰ２が同じでも基準使用日数の値が異なるプリペイドマネーが購入できるようにすることが望ましい。このように同じ金額に対応する複数の基準使用日数が利用可能であるとき、ユーザは、その金額を事前に支払う場合、基準使用日数の値を直接あるいは間接に指定する必要がある。もちろん、基準使用日数Ｎは一つの値のみ準備し、金額Ｐとしていくつかの値を利用可能にすることでもよい。あるいは、金額Ｐと基準使用日数Ｎとの組合せをあらかじめ定めておかないで、ユーザに金額Ｐと基準使用日数Ｎとを指定するようにすることもできる。
【００４４】
各ユーザは、本課金処理システムで処理される商品あるいはサービスの使用の前に、管理サーバ１０１に対してあらかじめ所望の金額の金を振り込む。振り込みは、例えばユーザの口座がある銀行からネットワークを介して行われる。本発明では、このようにユーザによりあらかじめ振り込まれた金がその後の課金処理に使用される。金の振り込みの仕方は他の方法でもよく、振り込まれた金の形態は、特に限定されない。電子マネーとしての振り込みであってもよい。
【００４５】
管理サーバ１０１では、図１には図示していない初期設定用のプログラムにより以下の処理が実行される。まず当該ユーザが初めて本システムを使用するときには、全体課金額テーブル１０８内当該ユーザ用のエントリが確保され、そのエントリに初期データが設定される。具体的には、図５（ａ）において、確保されたエントリ内のユーザＩＤ領域１０８Ａに当該ユーザに割り当てたユーザＩＤが記憶され、残金１０８Ｂに振り込まれた金額が記憶され、補充基準額１０８Ｃには、振り込み額に応じて定まる補充基準額が記憶される。
【００４６】
補充基準額は、既に制御パラメータテーブル１０３内の補充基準額決定データ１０３Ｃに関して説明したように、振り込まれた金額が補充基準額決定データに登録されたいずれかの金額、例えばＰ１であるときには、その金額に対応して記憶された基準使用日数、例えばＮ１との比Ｐ１／Ｎ１が補充基準額となる。振り込まれた金額と同じ額が複数個、補充基準額決定データ１０３内にある場合には、管理サーバ１０１が補充基準額を決定することができるように、ユーザはいずれの金額１０３Ｃ１と基準使用日数１０３Ｃ２との組を使用するかを振り込み時に指定する必要がある。
【００４７】
上記初期設定用のプログラムは、管理サーバ１０１内の各分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０に指示して、対応する分散サーバ＃１対応残金テーブル１１２又は分散サーバ＃２対応残金テーブル１２２に当該ユーザ用のエントリを確保させる。確保されたエントリ、例えば図５（ｂ）に示す分散サーバ＃１対応残金テーブル１１２に確保されたエントリには、ユーザＩＤ１１２Ａが記憶される。当該エントリの残金１１２Ｂ、増額分１１２Ｃは０のままである。
【００４８】
同様に、上記初期設定用のプログラムは、各分散サーバ１３０又は１４０内の分散サーバ課金額制御プロセス１３１又は１４１に指示して、分散サーバ内残金テーブル１３３又は１４３内に当該ユーザ用のエントリを確保させる。確保されたエントリ、例えば図５（ｃ）に示す分散サーバ内残金テーブル１３３には、ユーザＩＤ１３３Ａが記憶される。残金１３３Ｂは０のままであり、更新フラグ１３３Ｃは、リセットされたままである。
【００４９】
こうして初期設定が終了する。なお、当該ユーザが既に本課金処理システムを使用中のユーザである場合、当該ユーザ用のエントリが既に全体課金額テーブル１０８に存在するので、振り込まれた額は、全体課金額テーブル１０８内の上記ユーザの残金１０８Ｂに加算される。補充基準額１０８Ｃは、上に説明したように新たに振り込まれた金額に基づいて新たに設定される。管理サーバ１０１内の分散サーバ＃１対応残金テーブル１１２又は分散サーバ＃２対応残金テーブル１２２及び各分散サーバ１３０又は１４０内の分散サーバ内残金テーブル１３３又は１４３は変更されない。
【００５０】
ユーザが振り込んだ金額は、以下のようにして使用される。いずれかのユーザが行った買物に対する課金は、負荷分散装置１５０（図１）により選択されたいずれかの分散サーバにより処理される。各分散サーバにおける各ユーザの残金は、二つの方法で補充される。各分散サーバには、いずれのユーザについても補充基準額だけの残金が存在するように各ユーザが買物を行うのを待たないで事前に補充される。もしユーザが買物を行ったために課金処理が必要になったとき、課金額が補充基準額以下であるならば、当該課金を処理する分散サーバは、当該分散サーバにおける当該ユーザの残金を用いて課金処理を実行できる。
【００５１】
各分散サーバにおける各ユーザの残金を補充する他の方法は、課金処理する時点で課金処理する分散サーバでの当該ユーザの残金より多いときに、管理サーバ１０１より不足の金額を補充するという課金処理時の補充である。
【００５２】
まず、事前補充について説明する。事前補充は、管理サーバ１０１内の分散サーバ補充プログラム１１１又は１２１により実行される。制御パラメータテーブル１０３に記憶された時刻条件１０３Ａにしたがって、図示しない起動プログラムにより、各分散サーバ１３０又は１４０に対応して分散サーバ補充プログラム１１１又は１２１が分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０として起動される。時刻条件１０３Ａが一つの起動時刻を規定している場合には、分散サーバ補充プログラム１１１又は１２１は、１日に１回起動される。この起動時刻は一般に分散サーバでの処理負荷が小さい時間帯に属するように設定される。しかし、１０３Ａが起動時間間隔を指定している場合には、その時間間隔にしたがって一日に複数回起動される。
【００５３】
図６は、分散サーバ補充プログラム１１１の概略フローチャートである。分散サーバ補充プログラム１２１の処理も同じである。分散サーバ補充プログラム１１１又は１２１は、各分散サーバ１３０又は１４０に対応して起動される。以下では、分散サーバ補充プログラム１１１が分散サーバ１３０に対応して起動されたと仮定する。
【００５４】
分散サーバ補充プログラム１１１は、起動されると、対応する分散サーバ１３０と交信してその処理負荷に関するデータを受信し、その処理負荷が、制御パラメータテーブル１０３に登録された負荷条件１０３Ｂ（図５（ｄ））に規定された処理負荷以下であるか否かを判定し、そうでないときには、そのような小さい処理負荷が検出されるまで待機する（ステップＳ３０１）。
【００５５】
対応する分散サーバ１３０の処理負荷がそのような低い処理負荷であることが検出されたとき、対応する分散サーバ１３０内の分散サーバ課金額制御プロセス１３１を呼び出し、当該分散サーバ１３０内の分散サーバ内残金テーブル１３３に登録された各ユーザの残金１３３Ｂを読み出し、管理サーバ１０１内のその分散サーバ１３０に対応する分散サーバ＃１対応残金テーブル１１２内のユーザの残金１１２Ｂ（図５（ｂ））を読み出した残金に合うように更新する（ステップＳ３０２）。
【００５６】
このように残金を合わせることは、全てのユーザに対して実行される。他の分散サーバ１４０に対応する、管理サーバ１０１内の分散サーバ＃２対応残金テーブル１２２と分散サーバ１４０内の分散サーバ内残金テーブル１４３の残金についても同じである。
【００５７】
分散サーバ＃１対応残金テーブル１１２内の残金１１２Ｂが更新された後、そのテーブル１１２に記憶されたいずれかのユーザの残金１１２Ｂ、すなわち、当該テーブルが対応する分散サーバ１３０内での当該ユーザの残金が、そのユーザの補充基準額より少ないか否かが判別される。各ユーザの補充基準額は、全体課金額テーブル１０８のそのユーザ対応のエントリに設けられた領域１０８Ｃに記憶されている。
【００５８】
もしいずれかのユーザの当該分散サーバ１３０内の残金がそのユーザに対して定められた補充基準額より少なければ、全体課金額テーブル１０８内の当該ユーザのエントリをロックする（ステップＳ３０３）。ロックは、全体課金額テーブル１０８内の当該ユーザのエントリに含まれた排他フラグ１０８Ｄにロックを示すビットを書き込むことにより実行される。
【００５９】
その後、分散サーバ補充プログラム１１１又は１２１は、そのユーザについての不足分、すなわち、補充基準額と対応する分散サーバ内の残金との差に相当する残金を全体課金額制御プロセス１０６に補充することを要求する（ステップＳ３０４）。全体課金額制御プロセス１０６は、要求された不足分を当該ユーザの全体課金額テーブル１０８内の残金１０８Ｂ（図５（ａ））から補充できるか否かを全体課金額制御プログラム１０７により判別する。
【００６０】
要求された不足分の残金を補充できる場合には、不足分の残金を要求元の分散サーバ補充プログラム１１１を実行している分散サーバ＃１補充プロセス１１０に対応する分散サーバ＃１対応残金テーブル１１２内の当該ユーザの残金１１２Ｂに加算することにより移動する。移動した金額を増額分１１２Ｃとして記憶する。こうして、いずれかの分散サーバ上の残金が不足しているユーザに対して、その管理サーバ１０１上で当該分散サーバ１３０の残金を増大したことになる。
【００６１】
場合によっては、全体課金額テーブル１０８内の当該ユーザの残金１０８Ｂが、補充基準額より少ない場合がある。この場合には、事前に補充できないので、全体課金額制御プログラム１０７は、補充要求元の分散サーバ補充プログラム１１１又は１２１に対して補充できない旨を通知する。分散サーバ補充プログラム１１１又は１２１では、全体課金額制御プログラム１０７による補充可能／不可能に関する応答に基づいて、不足額を補充できたか否かを判別する（ステップＳ３０５）。もし、補充ができない場合でも、そのことを無視し特別なことはしない（ステップＳ３０６）。
【００６２】
その後、分散サーバ補充プログラム１１１又は１２１は、対応する分散サーバ１３０上の分散サーバ課金額制御プロセス１３１を呼び出し、分散サーバ＃１対応残金テーブル１１２内の増額分１１２Ｃを、分散サーバ１３０内の分散サーバ内残金テーブル１３３に登録された同じユーザの残金１３３Ｂに加算して、この残金を補充基準額まで増額する（ステップＳ３０７）。増額後に上記増額分１１２Ｃは０にリセットされる。なお、当該ユーザに関して補充ができない場合には、分散サーバ＃１対応残金テーブル１１２内の増額分１１２Ｃが０であるので、この場合には、補充は行わない。
【００６３】
その後、全体課金額テーブル１０８内の当該ユーザに対する排他フラグ１０８Ｄをリセットして、当該ユーザの残金１０８Ｂのロックを解除する（ステップＳ３０８）。その後、全てのユーザに付いて事前補充を行ったか否かが判断され（ステップＳ３０９）、そうでないときには、他のユーザが選択されて（ステップＳ３１０）、以上の処理が繰り返される。こうして、一つの分散サーバについて全てのユーザの残金が補充基準額まで事前に補充される。
【００６４】
同じ処理は、他の分散サーバについても全く同様に実行される。例えば、分散サーバ１４０に関しては、管理サーバ１０１内の分散サーバ＃２補充プロセス１２０により、分散サーバ補充プログラム１１１又は１２１と分散サーバ＃１対応残金テーブル１１２を用いて事前補充が実行され、分散サーバ１４０内の分散サーバ内残金テーブル１４３内の残金が全てのユーザに関して補充基準額まで補充される。
【００６５】
ユーザが買物を実行したときの各分散サーバでの課金処理は以下のようにして実行される。図７は、分散サーバ課金額制御プログラム１３２の処理のうちユーザによる商品の購入時に実行される処理の概略フローチャートである。分散サーバ課金額制御プログラム１４２の処理も同じである。ユーザの購入に対する課金処理はいずれかの分散サーバにより実行される。当該分散サーバでは、ユーザの購買に必要な金額が、当該分散サーバ、例えば１３０内の分散サーバ内残金テーブル１３３の残金領域１３３Ｂ（図５（ｃ））に記憶された当該ユーザの残金より多いか否かを判定する（ステップＳ５０１）。もしユーザの残金が購入額より大きいときには、ユーザの購買は有効な購買として処理される。すなわち、当該残金を購入額だけ減額し（ステップＳ５０２）、ユーザには「購入可」を通知する（ステップＳ５０３）。
【００６６】
しかし、ステップＳ５０１での判定の結果、ユーザの当該分散サーバ内の残金が購買額より少ないとき、当該分散サーバ１３０内の分散サーバ課金額制御プロセス１３１により、管理サーバ１０１内のユーザ個別設定プロセス１０４に不足額だけ分散サーバ１３０内の残金を増額するように要求し、増額されるまで待つ（ステップＳ５０４）。
【００６７】
後に更に詳細に説明するように、管理サーバ１０１は、当該管理サーバ１０１内の当該ユーザの残金が不足額より大きいとき、不足額を要求元の分散サーバに補充する。管理サーバ内の当該ユーザの残金が不足額より少ないとき、管理サーバ１０１は、他の分散サーバ、例えば１４０から当該ユーザの残金を不足額だけ回収し、回収された残金を要求元の分散サーバ１３０に補充する。もし他の分散サーバ、例えば１４０内の残金が不足額より少ないとき、管理サーバ１０１は不足額を回収できないので、その旨を要求元の分散サーバ１３０に通知する。
【００６８】
要求元の分散サーバ１３０の分散サーバ課金額制御プロセス１３１では、管理サーバ１０１から不足額が補充された場合、分散サーバ１３０の残金が不足していないと判断されるので（ステップＳ５０５）、当該残金を購入額だけ減額し（ステップＳ５０２）、購入可を返す（ステップＳ５０３）。しかし、管理サーバ１０１により不足額が補充されなかった場合、分散サーバ１３０の当該ユーザの残金が不足であると判断されるので（ステップＳ５０５）、購入不可を返す（ステップＳ５０６）。こうして、分散サーバ１３０での課金処理が終了する。
【００６９】
上で説明した購入額に見合う当該ユーザの、分散サーバ上の残金が不足しているときの管理サーバ１０１による処理の概要は以下のとおりである。
【００７０】
図８は、ユーザ個別設定プログラム１０５の処理の概略フローチャートである。既に述べたように、ユーザに対する課金処理をいずれかの分散サーバ、例えば１３０で実行する過程で購入額に対する当該ユーザの当該分散サーバ１３０での残金が不足しているとき、当該分散サーバ１３０内の分散サーバ課金額制御プロセス１３１から管理サーバ１０１のユーザ個別設定プロセス１０４が呼び出され、不足額の補充が要求される。ユーザ個別設定プロセス１０４は、この補充要求を受けると、ユーザ個別設定プログラム１０５にしたがってその補充要求を処理する。
【００７１】
まず、ステップＳ４０１で、全体課金額テーブル１０８中の当該ユーザの残金１０８Ｂに排他ロックをかける。この排他ロックは、別プロセスから同じユーザに関する残金の補充要求があった場合、同一ユーザの残金の更新を順に実行するためである。排他ロックは、当該ユーザの排他フラグ領域１０８Ｄにロックビットを記憶することにより行われる。
【００７２】
ステップＳ４０２では、全体課金額制御プロセス１０６に、当該ユーザの当該分散サーバ内の残金を不足額だけ増額するよう要求し、全体課金額制御プロセス１０６から残金の増額が承認されるまで待つ。ステップＳ４０３では、全体課金額制御プロセス１０６からの応答が、残金増額の承認であるときには、要求元の分散サーバ１３０の分散サーバ課金額制御プロセス１３１へ残金の不足額だけの増額を通知する。もし全体課金額制御プロセス１０６から応答が残金の増額不可の場合には、要求元の分散サーバ１３０の分散サーバ課金額制御プロセス１３１へ増額不可を返す。ステップＳ４０４では、ステップＳ４０１で設定した、全体課金額テーブル１０８内の当該ユーザの残金のロックを解除し、ユーザ個別設定プロセス１０４を終了する。
【００７３】
図９は全体課金額制御プログラム１０７の概略的なフローチャートである。全体課金額制御プロセス１０６は、分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０あるいはユーザ個別設定プロセス１０４から残金の補充要求により呼び出される。分散サーバ＃１補充プロセス１１０又は分散サーバ＃２補充プロセス１２０からは、いずれかの分散サーバ内の残高が補充基準額より少ないずれかのユーザに対して残金の補充が要求される。ユーザ個別設定プロセス１０４からは、購入金額が課金を処理している分散サーバ内のユーザの残金を超えている場合に呼び出される。全体課金額制御プロセス１０６は、残金補充要求を受けると、全体課金額制御プログラム１０７にしたがってその補充要求を処理する。
【００７４】
まず、ステップＳ８０１で、全体課金額テーブル１０８中の要求元のユーザの残金から要求額が取り出せるか否かが判定される。要求額が残金から取り出せる場合は、ステップ８０７において、全体課金額テーブル１０８内の当該ユーザの残金から要求額だけを要求元に返し、全体課金額制御プロセス１０６は処理を終了する。要求額が残金から取り出せない場合には、ステップＳ８０２で、ユーザ個別設定プロセス１０４からの呼び出しか否かが判定される。
【００７５】
そうである場合、すなわち、購入に関連した補充要求である場合には、ステップＳ８０４では、他の分散サーバから残金を回収できるか否かを検査する。すなわち、要求元の分散サーバ以外の分散サーバの当該ユーザの残金と管理サーバ１０１内の当該ユーザの残金とから、不足額を回収できるか否かを判断する。
【００７６】
この判断は以下のようにして実行される。管理サーバ１０１の当該ユーザの残金は、全体課金額テーブル１０８内の当該ユーザの残金１０８Ｂとして記憶されている。当該他の分散サーバ内の当該ユーザの残金を、管理サーバ１０１内の当該ユーザの残金に加算し、加算の結果、要求額以上の残金が得られた場合、不足額が回収できることになる。要求元の分散サーバ以外の分散サーバが複数個ある場合には、当該ユーザの残金が多い分散サーバの順に、それぞれの他の分散サーバ内の当該ユーザの残金を、管理サーバ１０１内の当該ユーザの残金に加算すればよい。
【００７７】
ステップＳ８０４において要求額が回収できると判断された場合、ステップＳ８０６において、上記他の分散サーバ１４０から当該ユーザの残金を全て回収し（当該残金を０にする）、全体課金額テーブル１０８内の当該ユーザの残金１０８Ｂに加算する。残金を回収すべき分散サーバが複数個であるときには、以上の加算処理をそれぞれの分散サーバについて繰り返す。その後ステップＳ８０７において、既に述べたように、要求元の分散サーバに要求額を補充する。
【００７８】
一方、ステップＳ８０４において要求額が回収できないと判断された場合、ステップＳ８０５において残金不足を要求元に通知する。
【００７９】
なお、ステップＳ８０２において、補充要求がユーザ個別設定プロセス１０４からの要求でない、すなわち、いずれかの分散サーバに対応する分散サーバ補充プロセス、例えば分散サーバ＃１補充プロセス１１０からの呼び出しであると判断された場合、補充要求は、購入に伴う不足額の補充要求ではなく、当該分散サーバにおける残金が補充基準額より少ないために発生した事前補充要求である。この場合には、既にステップＳ８０１において全体課金額テーブル１０８内の当該ユーザの残金は補充を要求された不足分に対して少ないので、補充を実現するには、他の分散サーバから不足分を回収する必要がある。しかし、残金を補充基準額にするために他の分散サーバから残金を回収すると、管理サーバ１０１及び他の分散サーバでの処理オーバヘッドが増大するので、この回収は実行されないで、補充不可を要求元に返し（ステップＳ８０３）、全体課金額制御プロセス１０６は処理を終了する。
【００８０】
こうして、各分散サーバの各ユーザの残金は、補充基準額になるように定期的に補充される。したがって、購入額が補充基準額以内であるときには、ユーザの購入に伴う課金処理を分散サーバが実行するときに、当該分散サーバ内では残金の不足が発生しない。分散サーバと管理サーバ１０１との間で残金を移動する必要が生じると、移動に伴い管理サーバ１０１の処理と分散サーバの処理が増えるために、課金処理時間が増えることになる。したがって、本実施の形態によれば、事前補充を行うことにより、課金処理時間を減らすことができる。
【００８１】
本発明は、以上の実施の形態に限定されるものではなくいろいろな形態で実施可能である。例えば、各ユーザの各分散サーバでの残金が補充基準値に達していないか否かの残金不足チェックは、上記実施の形態では、管理サーバにより全ユーザ、全分散サーバについて実行された。しかし、全分散サーバにおいて、各ユーザのそれぞれの分散サーバ内の残金を並行してチェックするように変更することもできる。このためには、各分散サーバに各ユーザの補充基準値を記憶するようにすればよい。このような変形例では、複数の分散サーバにより残金不足チェックが分散して行われるので、残金不足チェックの完了までに要する時間を短くすることが可能になる。しかし、複数の分散サーバから管理サーバに対して同時に補充要求が発生する可能性があり、管理サーバはこのような同時に発生する複数の補充要求を処理できるようにプログラムされる必要がある。このため管理サーバのプログラムは、既に述べた実施の形態のように管理サーバのみで残金不足チェックを行う場合より複雑になる場合がある。
【００８２】
図１０は、複数の管理サーバを分散配置して実現した他の分散課金処理システムの例を示す。全ユーザが二つのユーザグループに区分され、それぞれのユーザグループに対応して異なる管理サーバが使用される。ユーザのグループ化は、例えばユーザＩＤにより行うことができる。例えば、ユーザグループ１用の管理サーバ９１０とユーザグループ２用の管理サーバ９１１を使用することができる。これにより各管理サーバの負荷を、管理サーバの数が一つの場合より減らすことができる。なお、この例では、いずれのグループのユーザに対しても同じ一組の分散サーバ９２０から９２３が課金処理を実行する。なお、図では図１に示した負荷分散装置１５０と端末１５１等は簡単化のために示されていない。負荷分散装置は、ユーザ毎に処理すべき管理サーバを選択する必要がある。
【００８３】
図１１は、ユーザグループ毎に対応する一組の分散サーバを使用する更に他の分散課金処理システムの例を示す。すなわち、分散サーバ１０２０と１０２１は、ユーザグループ１に属するユーザに対する課金処理に使用され、分散サーバ１０２２と１０２３は、ユーザグループ２に属するユーザに対する課金処理に使用される。管理サーバ１０１は、全てのユーザに対して使用される。ユーザグループ毎に異なる分散サーバ群を使用するので、各分散サーバの処理負荷を減らすことができる。
【００８４】
更に、同一のユーザグループのために使用する分散サーバの総数を少なくしても、ユーザグループの数を増やすことにより各分散サーバの負荷を小さくすることができる。同一のユーザグループのために使用する分散サーバの総数を少なくすると、一つの分散サーバ内の同一のユーザの残金を大きくすることが可能になり、課金処理の実行時の残金不足が発生する可能性を減らすことができる。なお、図では図１に示した負荷分散装置１５０と端末１５１等は簡単化のために示されていない。負荷分散装置は、ユーザ毎に、例えばユーザＩＤに基づいて、処理すべき分散サーバ群を選択する必要がある。
【００８５】
【発明の効果】
以上、説明したように、本発明によれば、ユーザの購入行為に対して課金処理をいずれかの分散サーバにおいて実行するときに、当該分散サーバでの当該ユーザの残金が購入額に対して不足しているという状態が発生する頻度を減らすことができる。それにより、課金処理時に管理サーバから分散サーバへ不足額を送金する頻度を減らすことができ、ひいては課金処理の実行時間の増大を防ぐことができる。
【図面の簡単な説明】
【図１】本発明に係る分散課金処理システムの一つの実施の形態の構成図である。
【図２】本発明に係る分散課金処理システムによる課金の対象となる買物の実行形態のいろいろな例を示す図である。
【図３】管理サーバに組み込まれた主なプログラム及び関連データを示す図である。
【図４】いくつかの分散サーバに組み込まれた主なプログラム及び関連データを示す図である。
【図５】図１のシステムで使用されるいろいろなデータの例を示す図である。
【図６】分散サーバ補充プログラムの概略フローチャートである。
【図７】分散サーバ課金額制御プログラムの処理のうちユーザによる商品の購入時に実行される処理の概略フローチャートである。
【図８】ユーザ個別設定プログラムの概略フローチャートである。
【図９】全体課金額制御プログラムの概略フローチャートである。
【図１０】ユーザグループ毎に異なる管理サーバを使用する課金処理システムの構成図である。
【図１１】ユーザグループ毎に異なる分散サーバ群を使用する課金処理システムの構成図である。

Claims

複数の分散サーバと、少なくとも一つの管理サーバとを有し、ユーザがあらかじめ支払った金の残金を管理し、ユーザが商品若しくはサービスを購入したときに当該ユーザに対する課金を購入額に応じて処理する分散課金処理システムであって、各ユーザがあらかじめ支払った金の残金の一部を前記管理サーバから各分散サーバにあらかじめ送金し、いずれかの分散サーバにおいて、いずれかのユーザに対する課金処理を実行するときに、当該分散サーバ内の当該ユーザの残金が当該課金処理に必要な額より多い場合、当該分散サーバ内の当該ユーザの残金を用いて当該課金処理を実行し、当該分散サーバにおける当該ユーザの残金が課金処理に必要な額より不足している場合、当該不足額の送金を当該分散サーバより前記管理サーバに要求し、前記管理サーバ内にある当該ユーザの残金から前記要求された不足額の残金を当該要求元のサーバに当該管理サーバから送金し、若しくは前記管理サーバ内の前記ユーザに対する前記残金が前記要求された不足額に足りないとき、少なくとも当該足りない額の残金を前記要求元の分散サーバ以外の他の分散サーバから前記管理サーバにより回収して、当該回収された残金を用いて前記要求された不足額の残金を当該管理サーバから当該要求元のサーバに送金する分散課金処理システムにおいて、各分散サーバにおける各ユーザの残金が当該ユーザ毎にあらかじめ定められた補充基準額に達しているか否かを定期的に検査し、前記検査の結果、いずれかのユーザのいずれかの分散サーバ内の残金が前記補充基準額から不足していることが判明したとき、前記管理サーバ内の当該ユーザの残金のうち当該補充基準額からの不足額を当該分散サーバ内の当該ユーザの残金に対して補充し、各ユーザに対して定められた前記補充基準額は、前記管理サーバが備える制御パラメータテーブルに記録された当該ユーザがあらかじめ支払った額及びそれぞれの金額に対応してあらかじめ定められた基準使用日数に依存して前記管理サーバによって定められることを特徴とする残金管理方法。
前記検査は、毎日あらかじめ定めた条件を満たす時間帯に実行されることを特徴とする請求項１に記載の残金管理方法。
前記検査は、前記管理サーバにより実行されることを特徴とする請求項１又は２に記載の残金管理方法。
前記検査は、各分散サーバにより実行されることを特徴とする請求項１又は２に記載の残金管理方法。
複数のユーザが複数のユーザグループに区分され、前記管理サーバは、それぞれ一つのユーザグループに対応した設けられた複数の管理サーバからなり、各管理サーバは、対応するユーザグループに属する複数のユーザの残金を管理する管理サーバとして使用されることを特徴とする請求項１から４のいずれか一つに記載の残金管理方法。
複数のユーザが複数のユーザグループに区分され、前記複数の分散サーバは、複数の分散サーバグループに区分され、各分散サーバグループは、複数の分散サーバを有し、当該分散サーバグループが対応するユーザグループに属する複数のユーザの残金を管理する複数の分散サーバとして使用されることを特徴とする請求項１から４のいずれか一つに記載の残金管理方法。
複数の分散サーバと、少なくとも一つの管理サーバとを有し、ユーザがあらかじめ支払った金の残金を管理し、ユーザが商品若しくはサービスを購入したときに当該ユーザに対する課金を購入額に応じて処理する分散課金処理システムであって、各ユーザがあらかじめ支払った金の残金の一部を前記管理サーバから各分散サーバにあらかじめ送金する手段と、いずれかの分散サーバにおいて、いずれかのユーザに対する課金処理を実行するときに、当該分散サーバ内の当該ユーザの残金が当該課金処理に必要な額より多い場合、当該分散サーバ内の当該ユーザの残金を用いて当該課金処理を実行する手段と、当該分散サーバにおける当該ユーザの残金が課金処理に必要な額より不足している場合、当該不足額の送金を当該分散サーバより前記管理サーバに要求する手段と、前記管理サーバ内にある当該ユーザの残金から前記要求された不足額の残金を当該要求元のサーバに当該管理サーバから送金し、若しくは前記管理サーバ内の前記ユーザに対する前記残金が前記要求された不足額に足りないとき、少なくとも当該足りない額の残金を前記要求元の分散サーバ以外の他の分散サーバから前記管理サーバにより回収して、当該回収された残金を用いて前記要求された不足額の残金を当該管理サーバから当該要求元のサーバに送金する手段と、各分散サーバにおける各ユーザの残金が当該ユーザ毎にあらかじめ定められた補充基準額に達しているか否かを定期的に検査する手段と、前記検査の結果、いずれかのユーザのいずれかの分散サーバ内の残金が前記補充基準額から不足していることが判明したとき、前記管理サーバ内の当該ユーザの残金のうち当該補充基準額からの不足額を当該分散サーバ内の当該ユーザの残金に対して補充する手段と、を備え、各ユーザに対して定められた前記補充基準額は、前記管理サーバが備える制御パラメータテーブルに記録された当該ユーザがあらかじめ支払った額及びそれぞれの金額に対応してあらかじめ定められた基準使用日数に依存して前記管理サーバによって定められることを特徴とする分散課金処理システム。