JP2000076332A

JP2000076332A - 複数サーバ間送信数最適化システムおよびその方法

Info

Publication number: JP2000076332A
Application number: JP24155998A
Authority: JP
Inventors: Hiroshi Kawazoe; 博川副; Takeshi Tokuyama; 豪徳山; Tetsuo Shibuya; 哲郎渋谷; Hiroshi Maruyama; 宏丸山
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-08-27
Filing date: 1998-08-27
Publication date: 2000-03-14

Abstract

(57)【要約】（修正有）【課題】分散サーバによる資源管理システムの通信数を
軽減する方法及びシステムを提供することである。【解決手段】ホームサーバは、複数サーバ内から、資源
の送信要求を受け取り、要求以上の資源をそのサーバへ
送信する。要求以上の資源が、ホームサーバにない場合
は、１つ以上のサーバへ資源の送信要求を出し、資源を
集めて送信する。この時は、要求以上の資源をホームサ
ーバが受信するようにする。理論的に最適化するには、
要求以上の資源を、サーバの有する資源の半分になるよ
うに設定する。また資源を集めるにあたり、仮想資源残
高リストを用いて、１つ以上のサーバへ資源の送信要求
を出すようにしておき、ホームサーバが他のサーバから
資源を受信するにあたり、他のサーバの資源残高を受信
し、これに基づき前記仮想資源残高リストを更新する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本願は、分散サーバシステムにお
ける送信数の最適化に関し、特に分散サーバによる資源
管理システムにおいて、複数サーバ間の送信数を最適化
する方法およびシステムに関する。本願はネットワーク
上の課金方法及びシステムに関し、特に顧客とコンテン
ツ保有者との間で、効率的にかつ安全に課金を行う、課
金方法、システム、及びプログラムを含む媒体に関する
発明である。

【０００２】

【従来の技術】ネットワーク上での資源管理システムの
代表的な例として課金システムがあげられる。プリペイ
ド型のネットワーク上の課金システムとしては、特願平
９−１４６１２９が既に知られている。この課金システ
ムは有料Web ページの閲覧及びWeb上での購買に際して
の自動課金システムであり、面倒な支払操作をユーザが
意識的に行なわなくて済む事を目的としたシステムであ
る。

【０００３】特願平９−１４６１２９では、顧客のアク
セス要求を代行して、ネットワーク上でのコンテンツの
購入依頼を受けとる課金サーバを設けている。該課金サ
ーバは、ネットワーク上のコンテンツへのアクセス要求
に対して、顧客からのコンテンツの要求を受け取り、顧
客が誰であるかを特定し、アクセス要求があったコンテ
ンツの保有者、存在する場所、価格、及び売上げ経常先
を特定し、アクセス要求を発した顧客に代わって、コン
テンツのアクセスを行い、コンテンツ・サーバから、課
金サーバに送付されたコンテンツを顧客へ送付し、課金
サーバ内の顧客情報から、前記価格分を減じ、売上げ経
常先の情報に価格分を増じることにより、購入手続を簡
潔にした、安全で効率的な、ネットワーク上の課金シス
テムを提供している。

【０００４】このように、ネットワーク上の課金システ
ムをプリペイド電子マネーシステムとして使うと、あら
かじめ支払ったプリペイドマネーの残高がシステム上に
ある間は有料項目のマウスクリックと同時に自動的に課
金が行なわれていく。有料ページをすべて単一のサーバ
で管理する事はインターネットの巨大さから現実的でな
いので、インターネット上ではウエブページは複数のサ
ーバに分散して管理されている。同様に、課金のための
サーバが1台である中央管理的なシステムだと、そのサ
ーバへの要求が集中し、システムのボトルネックにな
る。従って、課金は分散したサーバで行なわれ、送金を
インターネットを経由するサーバ間の通信を用いて行な
うモデルが現実的である。ここでは、各々のクリックで
遷移するプリペイドマネーの情報と分散管理をネットワ
ーク上で通信によってアップデートする必要がある。送
金はトレースを管理、記録しなければならず、セキュリ
ティー上の注意が必要になる。このような分散課金にお
いては、送金通信数が多いとパフォーマンスの劣化が予
測される。従って、送金のメッセージの数をいかに軽減
するかが非常に重要であり、プリペイドマネーの効率的
な管理と分散により通信数を軽減する手法が望まれる。
この問題はネットワーク上の課金システムのみに限定し
たものではなく、分散サーバにおける資源管理システム
に共通の問題である。

【０００５】単独課金サーバーで管理されたネットワー
ク上の課金システムでは課金通信管理の問題は生じな
い。複数課金サーバで管理されたシステムあるいは同様
な小口課金システムでの課金では、通信数の問題が生じ
る。従来の銀行オンラインシステムなどでは、現実の金
銭は、サーバ（キャッシュディスペンサー等）に適当に
配備されて、金銭の移動は少なくて済むようになってい
るが、サーバ（キャッシュディスペンサー）からの通信
自体は課金（入金、出金）操作ごとに常に行なわれてお
り、インターネット上でのクリックに際して常に課金数
と同等の通信量の電子マネー送金が必要になるのは問題
である。

【０００６】

【発明が解決しようとする課題】従って、本発明が解決
しようとする課題は、分散サーバによる資源管理システ
ムの通信数を軽減する方法及びシステムを提供すること
である。従って、本発明が解決しようとする課題は、分
散サーバによる課金システムの通信数を軽減する方法及
びシステムを提供することである。また別の課題は、分
散サーバによる資源管理システムのパフォーマンスを向
上する方法及びシステムを提供することである。また別
の課題は、プリペイド型電子マネーシステムの送金メッ
セージの数を軽減する方法及びシステムを提供すること
である。また別の課題は、プリペイド型電子マネーシス
テムのパフォーマンスを向上する方法及びシステムを提
供することである。

【０００７】

【課題を解決するための手段】上記課題を解決するため
に、ホームサーバは、複数サーバ内のサーバから、資源
の送信要求を受け取り、要求以上の資源を前記サーバへ
送信する。要求以上の資源が、ホームサーバにない場合
は、複数サーバ内の、１つ以上のサーバへ資源の送信要
求を出し、資源を集めて送信するように構成する。また
資源を集めて送信する時に、資源の送信要求を受け取る
サーバから、要求以上の資源をホームサーバが受信する
ようにする。理論的に最適化するには、要求以上の資源
を、サーバの有する資源の半分になるように設定する。
(ここでサーバと資源送信側のサーバであり、ホームサ
ーバの場合もあるし、その他のサーバの場合もある）ま
た資源を集めるにあたり、仮想資源残高リストを用い
て、１つ以上のサーバへ資源の送信要求を出すようにし
ておき、ホームサーバが他のサーバから資源を受信する
にあたり、他のサーバの資源残高を受信し、これに基づ
き前記仮想資源残高リストを更新する。なお、ホームサ
ーバも分散サーバの中の１つのサーバである。ホームサ
ーバと残りのサーバは説明上、名前を異にするのみで、
ホームサーバとその他のサーバの物理的機能は同一で構
わない。

【０００８】電子マネー課金システムの場合、あるサー
バにおいて課金が必要になり、そのサーバでの残金では
不足になった場合、ホームサーバへの送金要求を送る。
ホームサーバは集金処理を行う。それには仮想残高リス
トを用いてサーバを選定し、そこへ返金要求を行なう。
返金要求を受けとったサーバは、指定された額の返金を
ホームサーバに送り、残高を同時に連絡する。返金が送
金額に達した場合、ホームサーバは送金を行なう。達し
ない場合は更に返金要求を行なう。

【０００９】このように構成することにより、分散サー
バ環境での通信数の最適化が可能となる。同じく分散サ
ーバシステムで課金が行なわれるプリペイド型の電子マ
ネー方式において起きる送金通信の数を最小にすること
ができる。通信数最適方法は送金要求に際して送金要求
をかなり上回る送金を行ない、送金元としては、仮想的
な残高リストを用いて残高のあるサーバから組織的に選
ぶ手法をとる。任意の通信数最適方法は本発明の方法よ
り理論的に2倍以上良くなれない事が証明されている。

【００１０】

【発明の実施の形態】以下本発明の方法およびシステム
をプリペイド型の電子マネーシステムに応用した実施例
を説明する。送金をオンライン通信数最適方法の観点か
ら捉え、ユーザーが使用するサーバーの所持金のバラン
スを常にある程度保つ事により理論的に通信数が漸近最
適となるようにすることができる。ユーザのプリペイド
マネーの状態を総合管理するホームサーバを一つ指定
し、残りのサーバをゲストサーバと呼ぶ。ホームサーバ
と他のサーバに物理的機能の差異は必要ないので、たと
えばホームサーバをネットワーク上でユーザに最も近い
課金サーバと規定し、ユーザごとにホームサーバは異な
るようにしても構わない。

【００１１】基本的な処理をまず説明する。あるサーバ
において課金が必要になり、そのサーバでの残金では不
足になった場合、ホームサーバへの送金要求を送る。送
金要求を行なったサーバでは送金がくるまで課金をスト
ップする。ホームサーバは仮想残高リストを用いてサー
バを一つ選定し（ホームサーバ自身である可能性もあ
る）、そこへ返金要求を行なう。（送金額が大きい場
合、2つ以上のサーバへの返金要求を行なう事もあ
る）。返金要求を受けとったサーバは、通信数最適方法
で指定された額の返金をホームサーバに送る。その際、
残高を同時に連絡する。返金が送金額に達した場合、ホ
ームサーバは送金を行なう。達しない場合は更に返金要
求を行なう。すべてのサーバから残高がゼロである報告
を受けた場合、通信数最適方法は終了する。ホストサー
バへのユーザからの新たな入金があり、残高が常に残っ
ているかぎり、処理はそのまま続行する。

【００１２】以上をより詳細に説明する。図１にホーム
サーバ自身に課金要求がきたとき処理の流れを示す。ま
ずステップ１１０はリクエスト待ちのブロックである。
課金リクエストがあると、まず１２０でサーバの残高を
調べ、足りる場合は処理は１６０の通常処理へ移る。残
高が足りない場合、ステップ１３０のかき集め処理に移
る。これで残高が足りる場合はステップ１６０の通常処
理へいく。もし足りないようであれば、全体での残高不
足であるので、ステップ１５０へ移動し処理不能とな
る。なおホームサーバ自身の残高も残高見積り表に入れ
る。自身への送金要求はその時の残高の半分を割り当て
る。

【００１３】図２に、ステップ１６０の通常処理の流れ
示す。まずステップ２１０でユーザが購入した価格分残
高を減らす。次にステップ２２０で、残高見積表をアッ
プデートする。ただし、ホームサーバ以外の通常処理で
はステップ２２０は実行しない。

【００１４】図３に、ホームサーバに他のサーバからの
送金要求がきた時の処理の流れを示す。まずステップ３
１０で、他のサーバからの送金要求をまつ。要求がある
と、ステップ３２０でかき集め処理を行う。そしてステ
ップ３３０で残高が足りるか判断し、足りる場合はステ
ップ３４０へいき、送り先のサーバの残高見積表を更新
する。そしてステップ３５０で送金する。もしステップ
３３０で残高が足りない場合は、ステップ３６０で送っ
てきた額をホームサーバの残高にする。そしてステップ
３７０で０円を送金する。

【００１５】図４にホームサーバでのかき集め処理の流
れを示す。まずステップ４１０でｉを初期化する。ステ
ップ４３０で今までに送金したことがあるサーバ全部を
検査したかを判断し、全部を検査した場合は処理は終わ
る。もしそうでない場合は、ステップ４３０でｉを増分
し、ステップ４４０で残高見積表の中でｉ番目の残高が
多いサーバに送金要求を送る。処理はステップ４５０で
サーバからの返事を待つ処理へ移る。サーバから返事が
くるとステップ４６０で残高見積表のｉ番目のサーバの
残高を送ってきた送金額とするように更新する。その理
由はサーバからホームサーバへ送ってくる額は、そのサ
ーバの所持金の半分を送ってくるので、送り側にも同額
の残っているからである。なを残高が０の場合は送金額
は０である。そして処理はステップ４７０へ移り、金額
が足りたかを判断し、足りていれば処理は終了し、そう
でなければ再びステップ４２０へ戻る。

【００１６】図５に、ホームサーバ以外のサーバに課金
要求がきたときの処理の流れを示す。ステップ５１０で
課金リクエストを待つ。リクエストがあるとまずステッ
プ５２０で残高が足りるかを判断し、足りていれば処理
はステップ５３０の通常処理へ移る。足りない場合はス
テップ５４０でホームサーバに送金要求を送る。そして
ステップ５５０で送金（要求の返事）がくるのを待つ。

【００１７】図６に、サーバにホームサーバからの送金
要求がきた時の処理の流れを示す。ステップ６１０で送
金要求があるまで待つ。送金要求がある場合は、ステッ
プ６２０で残高の半分をホームサーバへ送る。

【００１８】図７に、サーバにホームサーバから送金さ
れたときの処理の流れを示す。ステップ７１０でホーム
サーバからの送金を待つ。送金があった場合、ステップ
７２０で０が送られてきたかを判断し、もしそうであれ
ばステップ７５０で残高不足の処理を行いステップ７１
０へ戻る。もし送金が０でなければ、ステップ７３０で
残高に送金分を加える。そしてステップ７４０で通常処
理を行う。

【００１９】上記各処理の中で、仮想残高リストは、過
去に送金を行ない、報告された残高（過去に報告のない
場合、最初の送金額）が正であるサーバのリストであ
る。データ構造としては仮想残高によるソートされたリ
ストを用いる。（他の実装、例えばバケットにより、仮
想残高の大きさによって類別しておいても通信数最適方
法の解析上問題ない）また、返金指定のサーバは仮想残
高の最も多いサーバとし、その返金額は、現在のサーバ
の所持金の半分（奇数なら切り上げ）とする。なお、送
金要求が複数ホームサーバにきている場合、要求順に処
理するが、先読みによる並列処理を行なってもよい。ま
た、残高紹介に際して、現在の残高を通信によって知る
必要がある。これに対する解消法の例として、サーバの
残高及び少し前の時点の残高を報告するようにする。ま
たはユーザの手元のレコードからシステム上の総残高
をブラウザが計算する。このように本発明の方法は、サ
ーバー間通信の個数に対してのみでなく、サーバー間通
信のコスト（サーバの対によりコストは異なる）の軽減
に対しても拡張でき、具体的な戦略を最適化する事によ
り通信コストに関しても理論的に最適な通信数最適方法
にする事が出来る。

【００２０】この他の実施例として、ファイルサーバで
のディスク領域割り当てに応用することができる。ファ
イルサーバ上にはファイルをオープンしたプロセスのエ
ージェントとして、ファイルサーバ上のプロセスが動い
ている。このプロセスがファイルサーバ上のOSに対して
ディスクＩ／Ｏ要求を出す。プロセスとＯＳとのコミュ
ニケーションがすくないほどファイルサーバの性能は上
がる。つまりＯＳはプロセスからのディスク領域要求に
対して要求量より大目の領域を渡し、その領域の管理を
のプロセスに任せるように構成する。ディスク領域をす
べて使い切ったときに、ディスク領域要求を受け取る
と、プロセスに対して未使用領域回収要求を行う。

【００２１】ファイルサーバでのディスク領域割り当て
においては、ファイルサーバ上でのプロセスがプリペイ
ドカードの場合のサーバに相当する。プリペイドカード
のホームサーバはファイルサーバでのＯＳに相当する。
ディスク領域は最初はすべてＯＳの支配下にある。プロ
セスからディスク領域要求が来ると、ＯＳ支配下の領域
を渡す。プロセスは渡された領域をファイルのデータを
書くために使用していく。領域に余りがある間はＯＳへ
の要求を発生させないですむ。ディスク上の未使用（フ
ァイルとしてデータが置かれていない）領域をプリペイ
ドカードの残高とみなす。プロセスがに割り当てられた
領域がプリペイドカードの残高のそのサーバへ渡された
額となる。そのプロセスがディスク領域をファイルとし
てデータを置くことは、そのサーバでのプリペイド残高
の使用となる。このように、プリペイドカードの場合と
同様の方法により、最適なファイルサーバでのディスク
領域割り当てが可能となる。

【００２２】以下、図８に、本発明において使用される
ホームサーバを含むサーバのハードウェア構成の一実施
例を示す。システム１００は、中央処理装置（ＣＰＵ）
１とメモリ４とを含んでいる。ＣＰＵ１とメモリ４は、
バス２を介して、補助記憶装置としてのハードディスク
装置１３（またはＭＯ、ＣＤ−ＲＯＭ２３、ＤＶＤ等の
記憶媒体駆動装置）とＩＤＥコントローラ２５を介して
接続してある。同様にＣＰＵ１とメモリ４は、バス２を
介して、補助記憶装置としてのハードディスク装置３０
（またはＭＯ２８、ＣＤ−ＲＯＭ２３、ＤＶＤ等の記憶
媒体駆動装置）とＳＣＳＩコントローラ２７を介して接
続してある。フロッピーディスク装置２０はフロッピー
ディスクコントローラ１９を介してバス２へ接続されて
いる。

【００２３】フロッピーディスク装置２０には、フロッ
ピーディスクが挿入され、このフロッピーディスク等や
ハードディスク装置１３（またはＭＯ、ＣＤ−ＲＯＭ、
ＤＶＤ等の記憶媒体）、ＲＯＭ１４には、オペレーティ
ングシステムと協働してＣＰＵ等に命令を与え、本発明
を実施するためのコンピュータ・プログラムのコード若
しくはデータを記録することができ、メモリ４にロード
されることによって実行される。コンピュータ・プログ
ラムにはＯＳのほか、インターネット等を介して他のサ
ーバとの通信を行うコード、ブラウザ等のアプリケーシ
ョンなどが含まれている。コンピュータ・プログラムの
コードは圧縮し、または、複数に分割して、複数の媒体
に記録することもできる。

【００２４】システム１００は更に、ユーザ・インター
フェース・ハードウェアを備え、入力をするためのポイ
ンティング・デバイス（マウス、ジョイスティック等）
７またはキーボード６や、視覚データをユーザに提示す
るためのディスプレイ１２を有することができる。ま
た、パラレルポート１６を介してプリンタを接続するこ
とや、シリアルポート１５を介してモデムを接続するこ
とが可能である。このシステム１００は、シリアルポー
ト１５およびモデムまたは通信アダプタ１８(イーサネ
ットやトークンリング・カード)等を介してネットワー
クに接続し、他のコンピュータ等と通信を行う。またシ
リアルポート１５若しくはパラレルポート１６に、遠隔
送受信機器を接続して、赤外線若しくは電波によりデー
タの送受信を行うことも可能である。

【００２５】スピーカ２３は、オーディオ・コントロー
ラ２１によってＤ／Ａ（デジタル／アナログ変換）変換
された音声信号を、アンプ２２を介して受領し、音声と
して出力する。また、オーディオ・コントローラ２１
は、マイクロフォン２４から受領した音声情報をＡ／Ｄ
（アナログ／デジタル）変換し、システム外部の音声情
報をシステムにとり込むことを可能にしている。

【００２６】このように、本発明のサーバは、通常のパ
ーソナルコンピュータ（ＰＣ）やワークステーション、
ノートブックＰＣ、パームトップＰＣ、ネットワークコ
ンピュータ、コンピュータを内蔵したテレビ等の各種家
電製品、通信機能を有するゲーム機、電話、ＦＡＸ、携
帯電話、ＰＨＳ、電子手帳、等を含む通信機能有する通
信端末、または、これらの組合せによって実施可能であ
ることを容易に理解できるであろう。ただし、これらの
構成要素は例示であり、その全ての構成要素が本発明の
必須の構成要素となるわけではない。

【００２７】

【発明の効果】本発明により、分散サーバ環境での通信
数の最適化が可能となる。同じく分散サーバシステムで
課金が行なわれるプリペイド型の電子マネー方式におい
て起きる通信の数を最小にすることができる。

【図面の簡単な説明】

【図１】ホームサーバ自身に課金要求がきたとき処理の
流れを示す図である。

【図２】通常処理の流れを示す図である。

【図３】ホームサーバに他のサーバからの送金要求がき
た時の処理の流れを示す図である。

【図４】ホームサーバでのかき集め処理の流れを示す図
である。

【図５】ホームサーバ以外のサーバに課金要求がきたと
きの処理の流れを示す図である。

【図６】サーバにホームサーバからの送金要求がきた時
の処理の流れを示す図である。

【図７】サーバにホームサーバから送金されたときの処
理の流れを示す図である。

【図８】サーバまたはホームサーバに使用されるハード
ウェア実施例を示す図である。

フロントページの続き (72)発明者川副博神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内 (72)発明者徳山豪神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内 (72)発明者渋谷哲郎神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内 (72)発明者丸山宏神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内Ｆターム(参考） 5B049 BB46 CC36 EE31 GG02 5B055 BB10 EE02 EE12 EE15 EE21 5B089 GA11 JA11 JA36 JB12 KA05 KA07 KA15 KC11 KC15 KC60

Claims

【特許請求の範囲】

【請求項１】少なくとも１つのホームサーバを含む、複
数サーバ間において、送信数を最適化するシステムであ
って、該ホームサーバが、（１）前記複数サーバ内のサ
ーバから、資源の送信要求を受け取る手段と、（２）要
求以上の資源を前記サーバへ送信する手段と、（３）前
記要求以上の資源が、ホームサーバにない場合は、前記
複数サーバ内の、１つ以上のサーバへ資源の送信要求を
出し、資源を集めて送信する手段と、を具備することを
特徴とする、複数サーバ間送信数最適化システム。
【請求項２】前記資源を集めて送信する手段（３）が、
資源の送信要求を受け取るサーバから、要求以上の資源
をホームサーバが受信する手段を具備する、請求項１記
載のシステム。
【請求項３】前記要求以上の資源が、資源送信側のサー
バの有する資源の半分であることを特徴とする、請求項
２に記載のシステム。
【請求項４】前記資源を集めて送信する手段（３）が、
資源を集めるにあたり、仮想資源残高リストを用いて、
１つ以上のサーバへ資源の送信要求を出す手段を含む、
請求項１記載のシステム。
【請求項５】前記資源を集めて送信する手段（３）が、
ホームサーバが他のサーバから資源を受信するにあた
り、該他のサーバの資源残高を受信し、これに基づき前
記仮想資源残高リストを更新する手段を含む、請求項４
記載のシステム。
【請求項６】前記資源を集めて送信する手段（３）が、
前記仮想資源残高リストを用いて残高のあるサーバか
ら、資源の送信要求を出す手段を含む、請求項５記載の
システム。
【請求項７】少なくとも１つのホームサーバを含む、複
数サーバ間において、送信数を最適化するシステムであ
って、（１）サーバの有する資源を超える資源要求があ
った場合、ホームサーバに資源の送信要求を出す手段
と、（２）要求以上の資源を、ホームサーバから前記サ
ーバへ送信する手段と、（３）前記要求以上の資源が、
ホームサーバにない場合は、前記複数サーバ内の、１つ
以上のサーバへ資源の送信要求を出し、資源を集めて送
信する手段と、を具備することを特徴とする、複数サー
バ間送信数最適化システム。
【請求項８】前記資源を集めて送信する手段（３）が、
ホームサーバから資源を要求されたサーバが、要求以上
の資源をホームサーバに送信する手段を具備する、請求
項７記載のシステム。
【請求項９】前記要求量以上の資源が、資源送信側のサ
ーバの有する資源の半分であることを特徴とする、請求
項８に記載のシステム。
【請求項１０】前記資源を集めて送信する手段（３）
が、資源を集めるにあたり、仮想資源残高リストを用い
て、１つ以上のサーバへ資源の送信要求を出す手段を含
む、請求項７記載のシステム。
【請求項１１】前記資源を集めて送信する手段（３）
が、ホームサーバが他のサーバから資源を受信するにあ
たり、該他のサーバの資源残高を受信し、これに基づき
前記仮想資源残高リストを更新する手段を含む、請求項
１０記載のシステム。
【請求項１２】前記資源を集めて送信する手段（３）
が、前記仮想資源残高リストを用いて残高のあるサーバ
から、資源の送信要求を出す手段を含む、請求項１１記
載のシステム。
【請求項１３】前記資源が電子マネーであり、前記送信
要求が送金要求であり、前記仮想資源残高リストが、仮
想電子マネー残高見積表である、請求項１乃至１２の何
れかに記載のシステム。
【請求項１４】少なくとも１つのホームサーバを含む、
複数サーバ間において、送信数を最適化する方法であっ
て、該ホームサーバが、（１）前記複数サーバ内のサー
バから、資源の送信要求を受け取る段階と、（２）要求
以上の資源を前記サーバへ送信する段階と、（３）前記
要求以上の資源が、ホームサーバにない場合は、前記複
数サーバ内の、１つ以上のサーバへ資源の送信要求を出
し、資源を集めて送信する段階と、を有することを特徴
とする、複数サーバ間送信数最適化方法。
【請求項１５】前記資源を集めて送信する段階（３）
が、資源の送信要求を受け取るサーバから、要求以上の
資源をホームサーバが受信する手段を有する、請求項１
４記載のシステム。
【請求項１６】前記要求以上の資源が、資源送信側のサ
ーバの有する資源の半分であることを特徴とする、請求
項１５に記載の方法。
【請求項１７】前記資源を集めて送信する段階（３）
が、資源を集めるにあたり、仮想資源残高リストを用い
て、１つ以上のサーバへ資源の送信要求を出す段階を含
む、請求項１４記載の方法。
【請求項１８】前記資源を集めて送信する段階（３）
が、ホームサーバが他のサーバから資源を受信するにあ
たり、該他のサーバの資源残高を受信し、これに基づき
前記仮想資源残高リストを更新する段階を含む、請求項
１７記載の方法。
【請求項１９】前記資源を集めて送信する段階（３）
が、前記仮想資源残高リストを用いて残高のあるサーバ
から、資源の送信要求を出す手段を含む、請求１８記載
の方法。
【請求項２０】少なくとも１つのホームサーバを含む、
複数サーバ間において、送信数を最適化するためのプロ
グラムを含む媒体であって、該プログラムが、（１）ホ
ームサーバが前記複数サーバ内のサーバから、資源の送
信要求を受け取る機能と、（２）ホームサーバが、前記
送信要求を満たし、かつ最適量の資源を送信する機能
と、（３）前記送信要求を満たす資源が、ホームサーバ
にない場合は、ホームサーバを除く、前記複数サーバ内
の、１つ以上のサーバへ資源の送信要求を出し、資源を
集めて送信する機能と、を有することを特徴とする、プログラムを含む媒体。