特許 5697675 データ通信高速化および効率化のためのシステムおよびその方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5697675

(24)【登録日】2015年2月20日

(45)【発行日】2015年4月8日

(54)【発明の名称】データ通信高速化および効率化のためのシステムおよびその方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20150319BHJP

【ＦＩ】

   G06F13/00 520C

【請求項の数】6

【全頁数】37

(21)【出願番号】特願2012-533329(P2012-533329)

(86)(22)【出願日】2010年10月8日

(65)【公表番号】特表2013-507694(P2013-507694A)

(43)【公表日】2013年3月4日

(86)【国際出願番号】US2010051881

(87)【国際公開番号】WO2011044402

(87)【国際公開日】20110414

【審査請求日】2013年10月4日

(31)【優先権主張番号】61/249,624

(32)【優先日】2009年10月8日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512091475

【氏名又は名称】ホラ ネットワークス、リミテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】特許業務法人浅村特許事務所

(74)【代理人】

【識別番号】100066692

【弁理士】

【氏名又は名称】浅村 皓

(74)【代理人】

【識別番号】100072040

【弁理士】

【氏名又は名称】浅村 肇

(74)【代理人】

【識別番号】100147658

【弁理士】

【氏名又は名称】岩見 晶啓

(74)【代理人】

【識別番号】100138346

【弁理士】

【氏名又は名称】畑中 孝之

(72)【発明者】

【氏名】ヴァレンスキー、オフェル

(72)【発明者】

【氏名】シュリブマン、デリー、ビー．

【審査官】 新田 亮

(56)【参考文献】

【文献】 米国特許出願公開第２００８／０１０９４４６（ＵＳ，Ａ１）

【文献】 特開２００７−２８０３８８（ＪＰ，Ａ）

【文献】 鈴木 慧 Kei SUZUKI，Ｐ２Ｐ映像配信における連携ピア選択方式の提案と評価 A Study on Cooperative Peer Selection Method in P2P Video Delivery，電子情報通信学会技術研究報告 Ｖｏｌ．１０９ Ｎｏ．３７ IEICE Technical Report，日本，社団法人電子情報通信学会 The Institute of Electronics,Information and Communication Engineers，２００９年 ５月１４日，第109巻

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

エージェント・キャッシュ記憶装置を有し、システム中のクライアント通信装置のリストを保持しているアクセラレーション・サーバを使用するエージェント通信装置を介して、クライアント・キャッシュ記憶装置を有するクライアント通信装置とデータ・サーバ間でメッセージを送信するために、システム内部で使用される方法であって、
リクエストを送信するクライアント通信装置がアクセラレーション・サーバに対してデータ・サーバの識別子を送信するステップ、
アクセラレーション・サーバが、１つ以上のクライアント通信装置をデータ・サーバと関連付け、１つ以上のクライアント通信装置のリストをリクエストを送信するクライアント通信装置に与えるステップ、
リクエストを送信するクライアント通信装置が、与えられたクライアント通信装置の１つをデータ・サーバとの通信用にエージェント通信装置として選択し、エージェント通信装置にデータ・サーバ宛のメッセージを送信するステップ、
エージェント通信装置が、１つ以上のクライアント通信装置が過去にデータ・サーバから受信メッセージに対するレスポンスを受信したかどうかを判定するステップ、
１つ以上のクライアント通信装置が、過去にデータ・サーバから受信メッセージに対するレスポンスを受信した場合に、
エージェント通信装置がリクエストを送信するクライアント通信装置に、過去にレスポンスを受信したことのある１つ以上のクライアント通信装置のリストを送信し、過去にレスポンスを受信したことのある１つ以上のクライアント通信装置をピア通信装置として見なすステップ、
リクエストを送信するクライアント通信装置が、リスト中の１つ以上のピア通信装置からのリクエストされたレスポンスの１つ以上の部分を検索するステップ；
リクエストを送信するクライアント通信装置が、リクエストとレスポンスをクライアント・キャッシュ記憶装置に保存するステップ、
エージェント通信装置が、エージェント・キャッシュ記憶装置中のリクエストとレスポンスとに連動して、リクエストを送信するクライアント通信装置の識別子を保存するステップから構成されることを特徴とする方法。

【請求項2】

リクエストを送信するクライアント通信装置からのデータ・サーバ宛のメッセージを受信した後、クライアント通信装置がデータ・サーバに過去に送信したものと同じメッセージに対するレスポンスがエージェント・キャッシュ記憶装置に保存されているかをチェックした上で、エージェント通信装置がメッセージに対する過去の受信レスポンスを保持しているクライアント通信装置を認識しなかった場合に、
エージェント通信装置が、リクエストを送信するクライアント通信装置のメッセージをデータ・サーバに送信するステップ、
データ・サーバが、レスポンス・メッセージをエージェント通信装置に返信するステップ、
エージェント通信装置が、リクエストを送信するクライアント通信装置のメッセージとデータ・サーバのレスポンス・メッセージをエージェント・キャッシュ記憶装置に保存するステップ、
エージェント通信装置が、データ・サーバのレスポンスをリクエストを送信するクライアント通信装置に返信するステップ、
リクエストを送信するクライアント通信装置が、リクエストとレスポンスをクライアント・キャッシュ記憶装置に保存するステップが実行されることを特徴とする、請求項１に記載の方法。

【請求項3】

１つ以上のピア通信装置のリストにリクエストを送信するクライアント通信装置にとって、ピア通信装置からの情報受信スピードの点で最も有利なピア通信装置しか含まれない、請求項１に記載の方法。

【請求項4】

エージェント通信装置によって、もっとも有利であると判定されたクライアント通信装置が、リクエストを送信するクライアント通信装置から最も近い位置にあるクライアント通信装置である、請求項３に記載の方法。

【請求項5】

リクエストが、ＨＴＴＰ、ＵＤＰ、ＤＮＳ、ＴＣＰ、ＦＴＰ、ＰＯＰ３、ＳＭＴＰおよびＳＱＬから成るグループから選択される、請求項１に記載の方法。

【請求項6】

エージェント・キャッシュ記憶装置を有し、システム中のクライアント通信装置のリストを保持しているアクセラレーション・サーバを使用するエージェント通信装置を介して、クライアント・キャッシュ記憶装置を有するクライアント通信装置とデータ・サーバ間でメッセージを送信するためにシステム内部で使用される方法であって、
リクエストを送信するクライアント通信装置がアクセラレーション・サーバに対してデータ・サーバの識別子を送信するステップ、
アクセラレーション・サーバが、１つ以上のクライアント通信装置をデータ・サーバと関連付け、１つ以上のクライアント通信装置のリストをリクエストを送信するクライアント通信装置に与えるステップ、
リクエストを送信するクライアント通信装置が、与えられたクライアント通信装置の１つをデータ・サーバとの通信用にエージェント通信装置として選択し、エージェント通信装置にデータ・サーバ宛のメッセージを送信するステップ、
エージェント通信装置が、１つ以上のクライアント通信装置が過去にデータ・サーバから受信メッセージに対するレスポンスを受信したかどうかを判定するステップ、
エージェント通信装置が、データ・サーバから受信した返信を１つ以上の小さなデータ・チャンクに分解し、チャンクをエージェント・キャッシュ記憶装置に保存し、そのデータをその構成要素となるチャンクのリストとして保存し、各チャンクについてのチャンクのチェックサムをチャンクと連動して保存し、過去にデータの一部分を受信したことが分かっているネットワーク構成要素のリストを保存するステップ、
１つ以上のクライアント通信装置が過去にデータ・サーバから受信メッセージに対するレスポンスを受信した場合に、
エージェント通信装置が、リクエストを送信するクライアント通信装置に、データ・サーバのレスポンスから構成される、チャンクのチェックサム・リストを送信し、各チェックサムについて、エージェント通信装置が過去に受信したチェックサムを保持するクライアント通信装置の識別子を送信し、エージェント通信装置から過去にチェックサムを受信したことのあるクライアント通信装置をピアと見なすステップ、
リクエストを送信するクライアント通信装置が、レスポンスまたはその一部分を、エージェント通信装置から受信したリスト中の１つ以上のピアから受信したチャンクをリクエストすることによって検索するステップ、
リクエストを送信するクライアント通信装置が、リクエストとレスポンスをクライアント・キャッシュ記憶装置に保存するステップ、
エージェント通信装置が、リクエストを送信するクライアント通信装置が受信したチャンクと連動するリクエストを送信するクライアント通信装置の識別子を保存するステップから構成されることを特徴とする方法。

【発明の詳細な説明】

【技術分野】

【0001】

（関連アプリケーションへの相互参照）
本出願は２００９年１０月８日に出願された「データ通信の高速化および効率化ためのシステム」なる名称の米国における同時係属仮出願番号６１／２４９，６２４の優先権を主張し、その全体を参照することにより本明細書に取り込む。

【0002】

本発明は、インターネット通信、特にデータ通信速度およびインターネット帯域幅効率の向上に関連する。

【背景技術】

【0003】

ネットワークおよびインターネット利用において、インターネットで使用される帯域幅を大幅に増加させなければならない傾向が幾つかある。その内の１つに、大小を問わぬビデオクリップを含む動画のオンデマンド視聴の増加がある。加えて、レギュラー番組や長編映画などもインターネット上で視聴される場合がある。インターネット上のトラフィックを増加させているもう１つの傾向として、ウェブサイト（ショッピング・ポータル、新規ポータルおよびソーシャル・ネットワークなど）がグローバル化していること、つまりウェブサイトが世界中のあらゆる地域の人々に閲覧されるようになり、データがインターネット上を長時間に渡り往来するため混雑が激化していることが挙げられる。

【0004】

帯域幅消費の増加は様々な問題を発生させてきた。その内の幾つかを下記に示す。
ユーザが直面する問題−現状のインターネット帯域幅不足による、ユーザの体感する実効「スピード」の低下；
コンテンツ提供者が直面する問題−ユーザが閲覧する大容量データをホスティングし、かつ帯域幅を維持するための費用面の圧迫；
インターネット・サービス・プロバイダ（ＩＳＰ）が直面する問題−インターネット・トラフィックの増加によるインフラストラクチャ（通信回線、ルータなど）費用の増大

【0005】

消費者にとって十分速く、コンテンツ配信業者にとって安価で、かつＩＳＰにとってインフラストラクチャへの投資が必要ない新しいデータ伝送の方法の必要性が大きな課題となっているが、未だ解決されていない。

【0006】

今までにも、消費者に快適な速度、そしてコンテンツ配信業者にとって安価なインターネットを構築するために多くの試みがなされてきた。しかしながら、それまでの試みには広汎性のある実用的ソリューションの提供という視点が欠けている、またはいたインターネット・トラフィックの増加に伴う主な問題のうちごく一部を解決するに過ぎないものであった。これら旧来のソリューションのほとんどにおいて、包括的ソリューションを得るには何十億ドルもの資本投資が必要であり、また試みの大部分はインターネット・コンテンツの多くがユーザおよびユーザのセッションを通して動的に作成されたもの（いわゆる「Ｗｅｂ２．０」の傾向）であるというに対する視点に欠けていた。具体的には、例えばＡｍａｚｏｎやＳａｌｅｓｆｏｒｃｅのウェブサイトのように、表示ページの大部分が閲覧者に応じて変化した表示となること、つまり閲覧者の数だけ表示が異なるという仕様を指す。こうした情報の動的な表示の登場は、保存型コンテンツを、似たようなコンテンツを求めるユーザに提示することを想定としている旧来のソリューションのほとんどに限界を知らせている。

【0007】

これまで使用されてきたソリューションの１つは「プロキシ」と呼ばれる。図１は、ネットワーク２内のプロキシの使用例を図示している。プロキシ、すなわちプロキシ・サーバ４、６、８は、１つ以上のクライアントの間に設置され、インターネット２２を介してウェブ・サーバすなわちウェブ・サーバ３０、３２、３４に対しデータをリクエストする装置であり、図１ではクライアント装置１０、１２、１４、１６、１８、２０として示されている。前記プロキシ・サーバ４、６、８は前記ウェブ・サーバ３０、３２、３４に対しデータをリクエストし、前記ウェブ・サーバ３０、３２、３４からのレスポンスをキャッシュし、類似のリクエストを送信するその他のクライアント装置に送信する。前記プロキシ・サーバ４、６、８は、前記クライアント装置１０、１２、１４、１６、１８、２０から地理的に十分近い位置にあり、前記プロキシ・サーバ４、６、８の記憶装置および帯域幅が十分に大きい場合、前記プロキシ・サーバ４、６、８が対応する前記クライアント装置１０、１２、１４、１６、１８、２０へのリクエストの速度が上がる。

【0008】

ただし、インターネット・サーフィンに対する包括的ソリューションとしては、図１の前記プロキシ・サーバはインターネットが使用される世界中のあらゆる地点に設置されなくてはならず、また各地点の前記プロキシ・サーバの記憶装置の容量はインターネット上に保存されている全データの容量に近い大きさでなくてはならないことに留意が必要である。このため、これらソリューションには莫大なコストがかかり、非実用的である。加えて、ソリューションでは現在ウェブ上に普及している動的データをうまく処理することができない。

【0009】

例えばＡｋａｍａｉのように局地的に係るプロキシを世界中に展開している営利企業もあるが、それはインターネット上における一部の小規模サイト・グループのみに対応している。ウェブ上の全てのサイトについて係るソリューションで解決しようとするならば、それにかかる資本投資は数十億ドル規模になるだろう。さらに、このタイプのソリューションは動的コンテンツを処理できない。

【0010】

プロキシを使用したソリューションでこれまでは、多額のハードウェア費用のかからない大規模情報流通システムを構築する方法として「ピア・ツー・ピア・ファイル共有」方式、例えばＢｉｔＴｏｒｒｅｎｔなどが導入されてきた。図２は、ネットワーク５０におけるピアツーピア・ファイル送信例を図示している。ネットワーク５０において、ファイルは消費者のコンピュータ、すなわちここで言うクライアント装置６０に保存される。各消費者が、インターネット６２を介して他の消費者にデータを提供するため、配信業者からロードせずに済み、関連コストを節約することができる。また、消費者に複数のデータ・ダウンロード・ポイント、すなわちここで言うピア７０、７２、７４、７６、７８が与えられるため、ダウンロード速度を向上させることができる。しかし、係るピア・ツー・ピア方式では、必要なデータを発見するためのインデックスに相当するものを備えなくてはならない。一般的なピア・ツー・ピア・ファイル共有システムでは、係るインデックスがサーバ８０または複数のサーバに分散しているため、係るシステムで利用可能なファイル数は多くはない（さもなければサーバにかかるコストが多額になるか、検索時間が長くなる）。

【0011】

係るピア・ツー・ピア・ファイル共有方式はファイル共有システムで利用できる。一般大衆が関心を抱くメディア・ファイルがそれほど多く存在しないためである（むしろ関心を惹きつけるのは数百万枚規模の動画や音楽ファイルである）。無数のインデックス・エントリを保存し維持することは技術的にも経済的にも可能である。しかし、係るシステムが今日のインターネット上で使用されている膨大な数のファイルを対象に運用された場合、係るインデックスを保存し維持するコストも数十億ドル規模に達するだろう。さらに、こうしたピア・ツー・ピア・ファイル共有システム方式は動的ＨＴＴＰデータを処理することができない。

【発明の概要】

【発明が解決しようとする課題】

【0012】

結論として、インターネット上の大部分のデータを高速で送信できるシステム、高額のコストを要しないシステム、および／または、ごく限定的なインターネット・トラフィック輻輳の問題に対するソリューション提供するシステムは存在しない。従って、業界において従来取り組まれて来なかった前述の欠陥および欠点に対処する必要性がある。

【課題を解決するための手段】

【0013】

現在のシステムおよびメソッドは、通信ネットワーク内でのより高速かつ効率的なデータ通信のためにある。こうしたシステムの運用形態の例を、以下にアーキテクチャ例として簡潔に説明する。データ通信の速度が高めるためのネットワークにおいて：データ・サーバからデータを取得するためにデータ・リクエストを生成する少なくとも１台のクライアント通信装置；クライアント通信装置からデータ・リクエストを受信するデータ・サーバに割り当てられる通信装置で、クライアント通信装置が受信した、データ・リクエストに対して割り当てられたデータ・サーバからのレスポンスを記録する、少なくとも１台のエージェント通信装置；少なくとも１台のクライアント通信装置によるデータ・リクエストのレスポンスとして受信したデータの一部を保存する少なくとも１台のピア通信装置であって、データの一部をクライアント通信装置のリクエストによって、少なくとも１台のクライアント通信装置に送信するピア通信装置；どのエージェント通信装置をどのデータ・サーバに割り当てるかを決定し、かつその情報を少なくとも１台のクライアント通信装置に提供する、少なくとも１台のアクセラレーション・サーバ；を有するネットワーク。

【0014】

現在のシステムとメソッドはさらに、ネットワーク内に通信装置を提供し、この通信装置が：メモリ；このメモリにより以下の要領で段階的に構成されるプロセッサ；データ・サーバからデータを取得するためのデータ・リクエストの生成；データ・サーバに割り当て、割り当てられたデータ・サーバとして参照；ネットワーク内の別の装置からデータ・リクエストを受信し、割り当てられたデータ・サーバからのデータ・リクエストへのレスポンスを受信した、このネットワーク内のクライアント通信装置の記録の保持；生成されたデータ・リクエストに対するレスポンスとして受信したデータの一部を保存し、このデータの一部を通信装置からのリクエストによって通信装置へ送信；を実行するように設定されたプロセッサを有する通信装置を提供する。

【0015】

本発明のその他のシステム、メソッド、機能および利点は、次の図面と詳細な説明に従って精査すれば明らかとなる。これらの付加的なシステム、メソッド、機能、および利点の全ては、本記載、および本発明の範囲に含まれ、かつ添付の特許請求の範囲によって保護されることを意図する。

【図面の簡単な説明】

【0016】

本発明の多くの態様は、以下の図面を参照することでより詳細に理解できる。図面内の構成要素は必ずしも一定の縮尺ではなく、むしろ本発明の例示的実施形態の原理を明確に説明することに重点が置かれている。さらに、図面内で参照する番号は、複数の図面にわたって対応する要素を示している。

【0017】

【図1】ネットワーク内におけるプロキシの先行技術による使用例を図示している。

【図2】ピアツーピア・ファイル送信ネットワークの先行技術例を図示している。

【図3】本発明に従った通信ネットワーク例を図示している。

【図4】図３の通信ネットワーク内の通信装置を詳細に図示している。

【図5】図４のメモリを詳細に図示している。

【図6】図５のアクセラレーション・アプリケーションの通信パスおよび構成要素を図示している。

【図7】通信ネットワーク内で使用されている２つのメイン・データベースを詳細に図示している。

【図8】アクセラレーション・システム初期化モジュールの動作を示すフローチャートである。

【図9】通信ネットワーク内の複数の構成要素間の通信状態を詳細に示すフローチャートである。

【図10】ＨＴＴＰリクエストに対するエージェント・レスポンスに焦点を当てた、図９の続きのフローチャートである。

【図11】エージェントからピアのリストあるいは単一ピア・リストを受信した際の動作を示す、図１０の続きのフローチャートである。

【図12】エージェント、クライアントまたはピアが、特定のＨＴＴＰリクエストが現在も有効であるかどうかを判定するために取るステップを示すフローチャートである。

【図13】アクセラレーション・サーバの動作の概要を示すフローチャートである。

【図14】本発明の代替実施形態におけるＴＣＰ／ＩＰアクセラレーションの詳細を示すフローチャートである。

【図15】本発明の代替実施形態におけるＴＣＰ／ＩＰアクセラレーションの詳細および、接続フェーズが成功した後のクライアントとＴＣＰ／ＩＰサーバ間の通信（読み書き命令）の詳細を示すフローチャートである。

【発明を実施するための形態】

【0018】

本システムおよびメソッドは、通信ネットワーク内でのより高速かつ効率的なデータ通信を提供する。図３の概略図では通信ネットワーク１００を例として示す。図３のネットワーク１００は、複数の通信装置を有する。ここで詳細に説明されている通り、各通信装置にインストールされている各通信装置共通のソフトウェアの機能により、各通信装置はこのネットワーク１００の要求に従ってそれぞれがクライアント、ピア、あるいはエージェントとして機能することができる。図４の説明おいて、通信装置の詳細な説明がなされていることに留意が必要である。

【0019】

ネットワーク１００の代表的実施形態を示す図３では、通信装置の１台がクライアント１０２として機能していることを示している。クライアント１０２は、１つ以上のピア１１２、１１４、１１６および１つ以上のエージェント１２２と通信可能である。ここでは例示だけを目的としているため、ネットワークは３つのピアと１つのエージェントを有しているが、実際にはクライアントがエージェントおよびピアと数に制限無く通信できるように留意することが必要である。

【0020】

通信ネットワーク１００はウェブ・サーバ１５２も有している。ウェブ・サーバ１５２は、クライアント１０２が情報をリクエストするサーバであり、例えば、インターネット上の大多数のサーバと同様、コンテンツを配信するための一般的なＨＴＴＰサーバで代用できる。ただし、サーバ１５２はＨＴＴＰサーバに限定されるものではないことに留意が必要である。実際、通信ネットワーク内で異なる通信プロトコルが使用された場合、そのサーバは異なるプロトコルを処理できなくてはならない。ここでは、ＨＴＴＰを使用するとしているが、本発明はその他の通信プロトコルにも関連するものであり、ＨＴＴＰに限定されるものではない。

【0021】

通信ネットワーク１００はさらに、アクセラレーション・サーバ記憶装置１６４を備えるアクセラレーション・サーバ１６２を有する。本明細書でより詳細に説明する通り、アクセラレーション・サーバ記憶装置１６４は、その内部にアクセラレーション・サーバ・データベースを有する。アクセラレーション・サーバ・データベースは、通信ネットワーク１００内の内部にアクセラレーション・ソフトウェアを有している通信装置のインターネット・プロトコル（ＩＰ）アドレスを保持している。特に、アクセラレーション・サーバ・データベースは、アクセラレーション・ソフトウェアを内部に有する通信ネットワーク１００内でオンライン状態の通信装置のリストを保持している。各エージェントに対し、アクセラレーション・サーバはＩＰアドレスのリストを割り当てる。

【0022】

図３の通信ネットワーク１００において、クライアント１０２のアプリケーションは、ウェブ・サーバ１５２に情報をリクエストするが、これは、通信装置内部のソフトウェアが通信装置をクライアントとして機能させるよう指定したためである。さらに、エージェント１２２はウェブ・サーバ１５２に最も近いため、クライアント１０２からリクエストを受信する。これはまた、エージェント１２２内部のソフトウェアがエージェント１２２の通信装置にエージェントとして機能するよう指定するためである。本発明の他の実施態様に従えば、エージェントはウェブ・サーバに最も近い通信装置である必要はない点に留意すべきである。代わりに、別の通信装置がエージェントとして選定される。

【0023】

ピア１１２、１１４、１１６は、クライアント１０２がウェブ・サーバ１５２から検索した情報の一部を有することから、ピア１１２、１１４、１１６内部のソフトウェアがピア１１２、１１４、１１６の通信装置にピアとして機能するよう指定したためである。クライアント、エージェント、ピアを指定するプロセスは本明細書において詳細に説明されていることに留意すべきである。また、クライアント、エージェント、ピア、アクセラレーション・サーバ、ウェブ・サーバおよびその他ネットワーク１００のコンポーネントの数は、図３に示されている数とは異なる場合があることにも留意すべきである。実際、クライアント、エージェント、ピア、アクセラレーション・サーバ、ウェブ・サーバおよびその他ネットワーク１００のコンポーネントの数は、本説明のものに限定されない。

【0024】

通信ネットワーク１００内部の機能を説明する前に、本発明の最初の代表的実施形態に従い、通信装置２００の詳細な説明を次に示す。図４は、図３の通信ネットワーク１００内の、コンピュータとして一般的なコンポーネントを含む通信装置２００を詳細に示している。前述したように、図４の通信装置２００はクライアント、エージェントあるいはピアのいずれにも成り得ることに留意すべきである。

【0025】

一般的に、図４に示すようなハードウェア・アーキテクチャの観点から、通信装置はプロセッサ２０２、メモリ２１０、少なくとも１台の記憶装置２０８、および１台以上の入出力（Ｉ／Ｏ）装置２４０（または周辺機器）を有し、それらはローカル・インターフェース２５０を介して通信可能な状態に接続されている。ローカル・インターフェース２５０は、例えば当該技術分野において周知であるように、１つ以上のバスあるいはその他の有線または無線で接続されるが、これに限定されない。ローカル・インターフェース２５０は、通信を可能にするために追加的な構成要素、コントローラ、バッファ（キャッシュ）、ドライバ、リピータ、レシーバを有する場合があるが、ここでは簡潔な説明のため省略されている。さらに、ローカル・インターフェース２５０は、前述のコンポーネント間の通信を適切に行うため、アドレス、コントロールおよび／またはデータ接続を有する場合もある。

【0026】

プロセッサ２０２は、ソフトウェア、特にメモリ２１０内に保存されているソフトウェアを実行するためのハードウェア装置である。プロセッサ２０２には、カスタム開発の、あるいは市販のプロセッサ、中央処理装置（ＣＰＵ）、通信装置２００に関連するプロセッサのうちの補助的プロセッサ、半導体ベースのマイクロプロセッサ（マイクロチップあるいはチップセット状のもの）、マイクロプロセッサなど、ソフトウェアからの指示を実行する一般的な装置ならばあらゆるものが使用できる。

【0027】

図５に詳細が説明されているように、メモリ２１０は揮発性メモリ（例：ランダム・アクセス・メモリ（ＤＲＡＭ、ＳＲＡＭＳ、ＤＲＡＭなどのＲＡＭ））および不揮発性メモリ（例：ハード・ドライブ、テープ、ＣＤ−ＲＯＭなど）を単体あるいは一式で構成要素として有する。さらに、メモリ２１０は、電子式、磁気式、光学式、および／またはその他のタイプの記憶媒体を用いてもよい。メモリ２１０は、様々なコンポーネントが互いに遠隔に位置する分散型アーキテクチャとしてもよいが、プロセッサ２０２からアクセスすることができなくてはならない。

【0028】

メモリ２１０内のソフトウェア２１２は、以下の通り１つ以上の個別プログラムを有し、その各々が通信装置２００の論理機能実行のための順序付けられた実行命令リストを有する。図４に示す例では、メモリ２１０内のソフトウェア２１２は、少なくとも１台のアクセラレーション・アプリケーション２２０、およびインターネットブラウザ２１４を有する。また、メモリ２１０は、オペレーティング・システム（Ｏ／Ｓ）２３０を有する場合もある。オペレーティング・システム２３０は基本的にコンピュータプログラムの実行を制御し、スケジューリング、入出力制御、ファイル管理およびデータ管理、メモリ管理、通信制御および関連サービスなどを提供する。アクセラレーション・アプリケーション２２０に加えてインターネットブラウザ２１４およびオペレーティング・システム２３０、メモリ２１０も他のソフトウェアアプリケーションを有している場合があることに留意が必要である。

【0029】

本説明ではインターネットブラウザから送信されたクライアントのリクエストを参考にしているが、本発明において、リクエストはインターネットブラウザからのものに限定されるものではない。代わりに、電子メールプログラムや、ウェブ・サーバに保存されているデータをリクストするために使用されているその他のプログラムから、あるいはクライアント装置によってリクエストされたデータを保持しているその他のサーバから送信されたリクエストの場合もある。

【0030】

通信装置２００の機能は、ソースプログラム、実行可能プログラム（オブジェクトコード）、スクリプトあるいは実行命令の一式を有する他の構成要素によって提供される。ソースプログラムの場合、オペレーティング・システム２３０と連携して適切に運用するため、コンパイラ、アセンブラ、インタプリタその他メモリ２１０に備えられていない変換機で変換する必要がある。さらに、通信装置２００の機能は、（ａ）メソッドおよびデータクラスを有するオブジェクト指向プログラミング言語、または（ｂ）ルーチン、サブルーチンおよび／または関数を有する手続き型プログラミング言語で書かれる。

【0031】

入出力装置２４０は、入力装置、例えば、キーボード、マウス、スキャナ、マイクなどを有するがこれらに限定されない。さらに、入出力装置２４０は、出力装置、例えば、プリンタ、ディスプレイなどを有するがこれらに限定されない。最後に、入出力装置２４０はさらに、入力および出力の両方を通して通信する装置、例えば、変復調装置（モデム；他の装置、システムまたはネットワークへのアクセス用）、無線周波数（ＲＦ）あるいはその他のトランシーバ、電話インターフェース、ブリッジ、ルータなどを有するがこれらに限定されない。

【0032】

通信装置２００の動作中は、プロセッサ２０２は、メモリ２１０を送信元、送信先とするデータ通信を行うため、一般的にはソフトウェア２１２に従って通信装置２００の動作制御を行い、メモリ２１０内に保存されているソフトウェア２１２を実行するように設定されている。ソフトウェア２１２および入出力装置２４０は、その全部または一般的には一部について、プロセッサ２０２によって読み取り、一旦プロセッサ２０２内にバッファし、その後実行する。

【0033】

通信装置２００の機能が図４で示されるようにソフトウェアで実行される場合、その機能はコンピュータ関連システムまたはメソッドと関連して使用されるコンピュータ可読媒体に保存されることに留意が必要である。本明細書において、コンピュータ可読媒体は、電子式、磁気式、光学式またはその他の物理的装置または方法であって、コンピュータ関連システムまたは方法メソッドと関連して使用され、コンピュータプログラムを保持しあるいは保存できるものであるとする。通信装置２００の機能は、コンピュータを使用したシステムなどの命令実行システム、機器または装置、プロセッサを備えたシステム、あるいは命令実行システム、機器または装置から命令を取得してこれを実行することのできる他のシステムと関連して使用されるコンピュータ可読媒体によって実現される。本明細書において、「コンピュータ可読媒体」とは、命令実行システム、機器または装置と関連して使用されるプログラムを保存、通信、伝達、あるいは転送することのできるあらゆる方法を指す。

【0034】

コンピュータ可読媒体とは、例えば、電子式、磁気式、光学式、電磁式、赤外線または半導体システム、機器、装置あるいは伝播媒体のことを指すがこれらに限定されない。コンピュータ可読媒体のより具体的な例（限定的なリスト）を挙げると：１つ以上の回線を有する電気的接続（電子式）、ポータブルコンピュータディスケット（磁気式）、ランダム・アクセス・メモリ（ＲＡＭ）（電子式）、読み取り専用メモリ（ＲＯＭ）、消去およびプログラミング許容読み取り専用メモリ（ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリ）（電子式）、光ファイバ（光学式）およびポータブルコンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）（光学式）などがある。コンピュータ可読媒体は、紙その他プログラムが書き込まれた任意の媒体であってよく、例えば紙その他の媒体を光学スキャンしてプログラムを電子的にキャプチャし、その後必要ならばコンパイル、インタプリタその他の適切な方法で処理してから、コンピュータメモリに保存する。

【0035】

代替実施形態では、通信装置２００の機能はハードウェアで実行され、次の既知技術またはその組み合わせて実現される。：データ信号によって論理関数を実行するための論理ゲートを有する個別論理回路；適切な組合せ論理ゲートを有する特定用途向け集積回路（ＡＳＩＣ）；プログラム可能ゲートアレイ（ＰＧＡ）；フィールドプログラミング許容ゲートアレイ（ＦＰＧＡ）；など。

【0036】

通信装置２００の少なくとも１台の記憶装置２０８は、カテゴリが多岐に渡る記憶装置のうちの１つである可能性がある。ここ本明細書でより詳細に説明するとおりする通り、記憶装置２０８は構成データベース２８０およびキャッシュ・データベース２８２を有する場合がある。もう１つの方法として、構成データベース２８０およびキャッシュ・データベース２８２は通信装置２００との通信が可能な別の記憶装置に含まれる場合もある。以下の説明では構成データベース２８０およびキャッシュ・データベース２８２が同一の記憶装置に含まれていると仮定しているが、本発明はこの設定に限定されるものではないことに留意が必要である。

【0037】

構成データベース２８０は、ここ本明細書でより詳細に説明するとおりする通り、通信ネットワーク１００の全構成要素に共通し、メモリ２１０内に保存されているアクセラレーション・アプリケーション２２０の異なるモジュールの設定情報と同期情報を提供する設定データを保存している。キャッシュ・データベース２８２は、それ自身の使用のため、または通信ネットワーク１００内のその他の構成要素のために対象に通信装置２００が発信したＨＴＴＰリクエストに対するレスポンスを保存している。ここでより詳細に説明するとおり本明細書でより詳細に説明する通り、ＨＴＴＰリクエストに対するリスポンスレスポンスは、通信装置２００または情報を検索し、通信装置をピアあるいはエージェントとして使用する通信ネットワーク１００内のその他の通信装置による将来の使用のため、キャッシュ・データベース２８２内に保存される。

【0038】

前述の説明に加え、本明細書でより詳細に説明する通り、キャッシュ・データベース２８２はその内部に通信装置が認識するＵＲＬのリストを保存している。各ＵＲＬに対し、キャッシュ・データベース２８２は自身のＵＲＬ、ウェブ・サーバから返されたＵＲＬのＨＴＴＰヘッダ、ＵＲＬのコンテンツを含むチャンクのリストおよびチャンクのデータ自体を、ＵＲＬのコンテンツが最後にウェブ・サーバから直接ロードされた時、ウェブ・サーバ上でＵＲＬのコンテンツが最後に変更された時、そして、ＵＲＬのコンテンツを含むチャンクおよびデータのチャンク自体を保存するが。ここで言うチャンクとは、同じサイズのデータの一部としているが、本発明の代替実施形態に従えば、チャンクのサイズは異なっていてもよい点に留意が必要である。

【0039】

図５では、図４のメモリ２１０を詳細に示す。図５で示されている通り、メモリ２１０は、２つの基本的なレベルに分けられる。つまり、オペレーティングシステムレベル２６０とアプリケーションレベル２７０である。オペレーティングシステムレベル２６０はオペレーティング・システム２３０を有し、オペレーティング・システム２３０はさらに、少なくとも１台のデバイスドライバ２６２および少なくとも１台の通信スタック２６４を有する。デバイスドライバ２６２は、ソフトウェアモジュールであって、プロセッサ２０２、記憶装置２０８および入出力装置２４０のような通信装置２００の様々なハードウェア装置に対する基本的な動作命令に関与する。さらに、通信スタック２６４は、様々な標準通信プロトコルを実装することによってネットワーク１００内における通信手段と共に、通信装置２００のアプリケーションを提供する。

【0040】

アプリケーションレベル２７０には、通信装置２００上で実行されるアプリケーションが含まれる。結果として、アプリケーションレベル２７０には、遠隔ウェブ・サーバ上にある情報を閲覧するためのインターネットブラウザ２１４、以下に詳細を説明するアクセラレーション・アプリケーション２２０、通信装置２００に保存されているその他アプリケーション２１６が含まれる。

【0041】

以下により詳細に説明する通り、アクセラレーション・アプリケーション２２０は、通信装置（クライアント）のインターネットを使用するアプリケーションによって生成されるリクエストをインターセプトし、リクエストを修正し、かつ通信ネットワーク内でのリクストの経路を指定する。リクエストをインターセプトする方法には様々なものがある。方法の１つは、メモリ２１０内に中間ドライバ２７２を生成し、これを全ての通信アプリケーションと接続し、通信装置２００のインターネットブラウザ２１４のような通信アプリケーションの出力リクエストをインターセプトし、アクセラレーション・アプリケーション２２０へリクエストの経路を指定する。アクセラレーション・アプリケーション２２０が一旦リクエストを修正し、通信ネットワーク１００上のその他のシステム構成要素に対するリクエストの経路を指定し、ネットワーク１００上のその他のシステム構成要素から応答を受信すると、アクセラレーション・アプリケーション２２０は、中間ドライバ２７２に応答を返し、中間ドライバ２７２がリクエストを送信した通信アプリケーションに応答を送信する。

【0042】

図６は、アクセラレーション・アプリケーション２２０の通信パスおよび構成要素を示す。アクセラレーション・アプリケーション２２０は、その起動時に呼び出されるアクセラレーション・システム初期化モジュール２２２を有する。アクセラレーション・システム初期化モジュール２２２は、通信装置２００の全構成要素を初期化することができる。アクセラレーション・アプリケーション２２０はまた、並行して実行される３通りのモジュール、つまり、クライアントモジュール２２４、ピアモジュール２２６、エージェントモジュール２２８を有し、各モジュールは、通信装置２００が通信ネットワーク１００において一定時間担当している特定の役割に従って動作する。各モジュールの役割は本明細書でより詳細に説明する。

【0043】

クライアントモジュール２２４は、通信装置２００がウェブ・サーバ１５２に対して、例えばウェブページ、データ、ビデオあるいはオーディオなど含むがこれらに限定されない情報をリクエストする場合に必要な機能を提供する。通信装置２００はその内部にクライアントモジュール２２４を有し、情報リクエストをインターセプトして情報リクエストを通信ネットワーク１００内のサーバ、エージェント、ピアなどの他の構成要素に渡す。プロセスは本書でより詳細に説明する。

【0044】

ピアモジュール２２６は、通信ネットワーク１００内の他のクライアントに応答し、内部にピアモジュール２２６を有する通信装置２００が以前別途ダウンロードしておいた情報を、他のクライアントがリクエストした情報として他のクライアントに提供する場合に、通信装置２００に必要とされる機能を提供する。プロセスは本書でより詳細に説明する。

【0045】

エージェントモジュール２２８は、通信ネットワーク１００内のクライアントとして動作する他の通信装置が、エージェントモジュール２２８を内部に有しエージェントとして動作する通信装置２００に問合せし、通信ネットワーク１００内で問い合わせた情報を保持しているピアのリストを取得する場合に、必要とされる機能を提供する。プロセスは本書でより詳細に説明する。

【0046】

アクセラレーション・アプリケーション２２０は記憶装置２０８内の構成データベース２８０およびキャッシュ・データベース２８２の両方と相互通信する。前述の通り、構成データベース２８０は、通信ネットワーク１００内の全通信装置に共通の設定データを保持しており、メモリ２１０内に保存されているアクセラレーション・アプリケーション２２０のそれぞれのモジュール２２２、２２４、２２６、２２８に対して設定情報と同期情報を提供する。

【0047】

キャッシュ・データベース２８２は、自身の使用のため、または通信ネットワーク１００内のその他の構成要素のために、通信装置２００が発信した情報リクエスト、例えばＨＴＴＰリクエストなどに対するレスポンスを保存している。ＨＴＴＰリクエストに対するレスポンスは、通信装置２００による将来の使用のため、あるいは通信ネットワーク１００内の他の通信装置が情報を検索しかつ通信装置２００をピアあるいはエージェントして使用するために、キャッシュ・データベース２８２内に保存される。プロセスは本書でより詳細に説明する。

【0048】

キャッシュ・データベース２８２に保存されている情報には、クライアントから送信されたリクエストに関連する情報が含まれている。例として、メタデータや実際にリクエストされたデータなどが含まれる。例えば、ビデオに対するＨＴＴＰリクエストの場合、データはクライアントからのリクエストに応答するウェブ・サーバのバージョンを有するメタデータであったり、あるいはリクエストされたビデオそのものであったりする。キャッシュ・データベースの記憶装置に空き容量がない場合、関連通信装置のソフトウェアは、通信データ中の既存データを消去してキャッシュ・データベース内に新しいデータ用の空き容量を作る。既存データの例としては再使用の可能性の低いデータ、あるいは古いデータや無効となったデータなどである。通信装置は、既知の方法を用いて、最も関連性の低いデータを選択して消去する。

【0049】

図７は、通信ネットワーク１００内で使用される２つのメイン・データベース、つまり、アクセラレーション・サーバ、データベース１６４およびキャッシュ・データベース２８２を詳細に示すチャートである。前述したように、アクセラレーション・サーバ、データベース１６４は、通信ネットワーク１００内において内部にアクセラレーション・ソフトウェアを有している通信装置のＩＰアドレスを保持している。特に、アクセラレーション・サーバ、データベース１６４は、アクセラレーション・ソフトウェアを内部に有し、かつ現在通信ネットワーク１００内でオンライン状態の通信装置のリストを保存している。アクセラレーション・サーバは、ＩＰアドレスのリストをエージェントとして機能する各通信装置に割り当てる。各通信装置は、ＩＰアドレスが通信装置によって「所有されている」範囲内のウェブ・サーバに対するエージェントとして機能する。例として、最初の通信装置がオンライン状態になった場合、つまり、本書に述べるような、アクセラレーション・アプリケーション２２０を有する最初の通信装置がオンライン状態になった場合、アクセラレーション・サーバは世界中の全ＩＰアドレスを通信装置に割り当て、通信装置があらゆるウェブ・サーバに対するエージェントとなる。２番目の通信装置がオンライン状態になると、ＩＰアドレスを最初の通信装置と共有し、各通信装置はワールドワイドウェブの異なる区域を担当することになる。

【0050】

通信装置２００のキャッシュ・データベース２８２はその内部に通信装置２００が認識するＵＲＬ２８６のリストを保持している。通信装置２００は、ある特定のＵＲＬに存在する情報へのリクエストを受信する度にＵＲＬを学習していく。図７に示す通り、ＵＲＬリスト２８６内の各ＵＲＬ２８８に対して、キャッシュ・データベース２８２は、：ＵＲＬ２９０自身；ウェブ・サーバ１５２からＵＲＬ用に返信されたＨＴＴＰヘッダ２９２；ＵＲＬのコンテンツがウェブ・サーバ１５２から最後に直接ロードされた時刻２９４；ウェブ・サーバ１５２上でＵＲＬのコンテンツが最後に変更された時刻２９６；ＵＲＬのコンテンツを含むチャンクのリスト２９８およびチャンクのコンテンツ；を保存している。前述したように、本説明におけるチャンクとは、同じ大きさの集合ＵＲＬのコンテンツ全体、つまりＵＲＬによってその位置が示されるコンテンツ全体を形成するデータの一部と定義される。例えば、１６ＫＢのサイズのチャンクを使用すれば、あらゆるＨＴＴＰレスポンスは１６ＫＢのチャンクに分解されるが、この例に限定されない。本発明の代替実施形態に従い、レスポンスの最後のチャンクのサイズが設計されたチャンクのサイズに満たない場合、チャンクの残余部分として本例では左側の１６ＫＢを空白とする。

【0051】

各チャンク３００において、キャッシュ・データベース２８２は、チャンクのチェックサム３０２、チャンク自体のデータ３０４、チャンクのデータを保持している可能性の最も高いピアのリスト３０６を有する。ここでさらに詳細に説明する通り、チャンクのデータは、通信ネットワーク１００内の他の通信装置がクライアントに対してチャンクデータのダウンロード先ピアとして機能する場合、通信ネットワーク１００内の他のクライアントによって使用される。

【0052】

チャンクごとにチャックサムが計算され、チャンク自身と一緒に保存される。チェックサムは当業者に周知の数々の方法によって計算される。チェックサムを有する目的は、データを一意に特定できるように、チャックサムをデータであるチャンクの「キー」とするためである。例として、クライアントがＵＲＬのコンテンツをロードする場合、エージェントがリクエストに対するサービスを提供し、チャンクを保持しているピアと共に、チャンクのチェックサムをクライアントに送信する。別のチャンクには別のピアが対応することに留意が必要である。クライアントは、その後各ピアと通信し、チャンクのチェックサムを提供し、ピアはそれをクライアントに返信する。ピアは、その保有するキャッシュ・データベースでチェックサム（キー）を検索し、チェックサム（キー）に対応するチャンク（データ）を返信する。図７に示すとおり通り、ピアのリスト３０６内の各ピア３０８に対して、キャッシュ・データベース２８２はピアのＩＰアドレス３１０およびピア３０８がオンライン状態かどうかを示す、ピアの接続ステータス３１２を有する。

【0053】

本発明の１つの実施形態に従い、キャッシュ・データベース２８２はＵＲＬおよびチェックサムによってインデックスが付される。キャッシュ・データベースにこの方法でインデックスを付けると、以下の理由で有利になる場合がある。エージェントがキャッシュ・データベースを使用する場合、エージェントはクライアントから検索対象であるＵＲＬへのリクエストを受信する。そのような場合、エージェントはＵＲＬによってキャッシュ・データベースにインデックスを付け、ＵＲＬのチャンクを有する対応するピアのリストの検索しやすくする必要がある。ピアがキャッシュ・データベースを使用する場合、ピアはクライアントから特定のチェックサムに対するリクエストを取得し、ピアは、正しいチェックサムを素早く発見できるようにチェックサムによってデータベースにインデックスを付ける必要がある。当該技術に通じていれば既知の通り、他の方法でキャッシュ・データベースにインデックスを付しても良い。

【0054】

通信ネットワーク１００のコンポーネントについて説明してきたが、コンポーネント同士がどのように相互作用し、また個々に機能するのかは以下により詳細に説明する。図８は、アクセラレーション・システム初期化モジュール２２２（以下簡潔に「イニシャライザ２２２」という）の動作を示すフローチャート３００である。フローチャート中のあらゆるプロセス記述あるいはブロックは、モジュール、セグメント、コードの一部、あるいはプロセスの特定の論理機能を実行するための１つ以上の指示を含むステップを有することに留意が必要である。本発明の範囲内である代替実装形態では、本発明の分野における当業者が理解している通り、関係する機能によっては、機能は図示あるいは説明とは異なる順序で実行されたり、実質上同時であったり、逆の順序になる場合もある。

【0055】

イニシャライザ２２２は通信装置２００の最初の構成要素であって、通信装置２００の起動（ブロック３０２）に伴って動作する。イニシャライザ２２２が起動すると、最初にアクセラレーション・サーバ１６２と通信してアクセラレーション・サーバ１６２にサインアップする。動作は、アクセラレーション・サーバ１６２に、イニシャライザ２２２を有する通信装置２００のインターフェースのホスト名および全ＩＰアドレス、媒体アクセス制御アドレス（ＭＡＣアドレス）を与えることによって実行される。

【0056】

本発明の実施形態に従えば、ブロック３０４で示される通り、イニシャライザ２２２はアクセラレーション・サーバ１６２に対して、アクセラレーション・アプリケーション・ソフトウェアのアップデート版が利用できるかどうかを照会する。動作は、当業者には自明であり、またこれに限定されるものではないが、アクセラレーション・アプリケーション・ソフトウェアのバージョン番号をアクセラレーション・サーバ１６２に通知することによって実行される。アクセラレーション・サーバ１６２から返される受信メッセージは、アクセラレーション・アプリケーション・ソフトウェアの新バージョンがあるかどうかを伝える。アクセラレーション・アプリケーション・ソフトウェアの新バージョンが存在すれば、イニシャライザ２２２はアクセラレーション・アプリケーション・ソフトウェアの最新バージョンをアクセラレーション・サーバ１６２または別の場所からダウンロードして最新バージョンを通信装置２００にインストールする。上記に加えて、イニシャライザ２２２はそれ以降、定期的に新しいバージョンがないかどうかをチェックするようになる。例として、イニシャライザ２２２は２日おきにシステム更新をチェックする。

【0057】

ブロック３０６が示す通り、イニシャライザ２２２は、その後通信装置２００から出力されるネットワークトラフィックを、アクセラレーション・アプリケーション１６２を通してリダイレクトする。前述したように、出力ネットワークトラフィックをリダイレクトする方法の１つは、トラフィックをインターセプトしリダイレクトする中間ドライバ２７２を加えることである。リダイレクトを実行する方法は、当該技術に通じていれば既知の方法が多くある点に留意が必要である。

【0058】

ブロック３０８が示すとおり通り、イニシャライザ２２２はその後通信装置２００のクライアントモジュール２２４を起動し、通信装置２００のクライアントモジュール２２４を、通信装置２００の全出力ネットワーク通信をインターセプトするように設定する。そして、出力ネットワーク通信を中間ドライバ２７２から、あるいはその他のルーティング方法を実行して、クライアントモジュール２２４に送信する。動作は、クライアントモジュール２２４がネットワーク・アプリケーションから全ネットワークトラフィックを受信し、必要ならばネットワークトラフィックを修正し、トラフィックを新ルートで送信できるようにするために実行される。当業者には自明であるが、トラフィックを新ルートで送信するには、トラフィックを修正しなくてはならない。例えば、リクエストの宛先の変更である。

【0059】

ブロック３１０に示す通り、イニシャライザ２２２はその後エージェントモジュール２２８およびピアモジュール２２６を起動して通信装置２００上で実行する。エージェントモジュール２２８およびピアモジュール２２６は通信装置２００の所定のポートで待機しており、ポート上で受信したネットワークトラフィックはエージェントモジュール２２８とピアモジュール２２６に送信される。本明細書でより詳細に説明する通り、処理によって通信装置２００は必要に応じ、通信ネットワーク１００内のその他の通信装置に対して、エージェントとしてもピアとしても機能することができる。

【0060】

図９は、より高速で効率の高いデータ通信を可能にする本システムおよびメソッドに従った、通信ネットワーク１００の構成要素間の通信を詳細に示すフローチャートである。

【0061】

ブロック３５２に示す通り、クライアント２００上で実行されているアプリケーションがネットワーク上のリソースへのリクエストを開始する。リクエストは例えば、“ＧＥＴ ｈｔｔｐ：／／ｗｗｗ．ａｏｌ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ ＨＴＴＰ／１．１”などである。リクエストは、クライアント２００のインターネットブラウザ２１４から発信される。リクエストの内容には、インターネットブラウザ２１４がインターネットからページをロードするリクエスト、アプリケーションがインターネットから情報をダウンロードするリクエスト、電子メールの送受信リクエスト、あるいは他のネットワーク通信リクエストなどがある。

【0062】

中間ドライバ２７２あるいは他のクライアント２００のクライアントモジュール２２４への通信を新しいルートで送信する方法を使用することで、リソースリクエストはクライアント２００上で実行されているクライアントモジュール２２４によってインターセプトされる（ブロック３５４）。クライアントモジュール２２４はその後、リソースリクエストのターゲットであるサーバ１５２のＩＰアドレス（例えば、例におけるｗｗｗ．ａｏｌ．ｃｏｍのホストであるウェブ・サーバのＩＰアドレス）を検索して、ＩＰアドレスをアクセラレーション・サーバ１６２（ブロック３５６）に送信し、クライアント２００がエージェントとして使用可能な通信装置（以下「エージェント」という）のリストを取得する。サーバでのＩＰ検索の実行プロセスは当該技術に通じていれば既知のものである前提で、本書ではこれ以上の説明はしない。

【0063】

サーバ１５２のＩＰアドレスを受信すると、アクセラレーション・サーバ１６２はＩＰアドレスからのリクエスト処理に適したエージェントのリストを作成する（ブロック３５８）。リストのサイズは実行形態により異なる。以下にアクセラレーション・サーバ１６２によって作成された５つのエージェントを含むリストを、あくまで例として示す。エージェントのリストはアクセラレーション・サーバ１６２が、通信ネットワーク１００内にあるオンライン状態の通信装置のＩＰアドレスが宛先ウェブ・サーバ１５２のＩＰに数値的に近くなっている通信装置を検索することにより作成する。本明細書では前述のプロセスのより詳細な説明をする。

【0064】

ブロック３６０に示す通り、クライアントモジュール２２４はオリジナル・リクエスト（例：“ＧＥＴ ｈｔｔｐ：／／ｗｗｗ．ａｏｌ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ ＨＴＴＰ／１．１”）をアクセラレーション・サーバ１６２から受信したリストの全エージェントに送信することで、リスト内のエージェントの中からリクエストを補助する上で最も適したエージェントを突き止める。

【0065】

本発明の代替実施形態に従えば、通信装置２００は実際にデータをリクエストする装置に接続される場合もあることに留意が必要である。この代替実施形態では、通信装置はリクエストを送信する装置に接続されたモジュール装置であり、例えばパーソナルデータアシスタント（ＰＤＡ）その他端末などリクエストを送信する装置がデータをリクエストし、通信装置が物理接続、無線接続あるいは他の接続によってそこに接続されており、データ・リクエストを受信して本明細書に述べるように機能する。さらに前述したように、ＨＴＴＰリクエストはウェブ上のリソースを要求するどのようなリクエストにも置換される点に留意が必要である。

【0066】

図１０は、リクエストに対するエージェント・レスポンスに焦点を当てた、図９のフローチャート３８０の続きのフローチャートである。ブロック３８２に示す通り、クライアント２００からリクエストを受信すると、クライアントからレスポンスを受信した各エージェントは、クライアントによるリクエスト情報のネットワーク内のピアからのダウンロードに有用となるリクエストに関する情報を持っているかどうかをクライアント２００に応答する。特に、各エージェントはエージェントがリソースに対する過去のリクエストで要求が満たされたものを参照したことがあるかどうかを応答する。そのような場合には、エージェントは各々保持しているピアおよびチャンクのチェックサムのリストをクライアントに送信する。

【0067】

ブロック３８４に示される通り、クライアントはその後、リスト中のエージェントの内いずれについて特定の情報リクエストに対するエージェントとして使用するかを決定する。リスト中のエージェントの内のいずれを特定の情報リクエストに対するエージェントとして使用するかを決定する際、クライアントは複数の要因、例えば各エージェントによる応答スピードの属性や、エージェントが必要な情報を保持しているかどうかなどを考慮する。エージェントの選定には複数の方法があり、実際的な方法の１つに、時間の小窓タイマーを起動するという方法がある。例えば、エージェントからの最初のレスポンスを受信して５ミリ秒間隔などである。そして、この小窓時間の後、応答のあったエージェント・リストから、リクエストに関する情報を持っているエージェントを、あるいは応答するエージェントが無い場合にはアクセラレーション・サーバ１６２から受信したリストの最初のエージェントを選択する。

【0068】

ブロック３８６に示すように、エージェントを１つ選択後、クライアントは選択されたエージェントに、リクエスト用に使用する旨を通知し、かつその他のエージェントに対してはリクエスト用には使用されない旨を通知する。クライアントはその後選択されたエージェントに、オリジナル情報リクエストのデータの最初の５つのチャンクをリクエストする（ブロック３８８）。選択されたエージェントに対し、フル・レスポンス内の命令でリクエストしたチャンクを指定することで、クライアントはピアのリストおよび選択したエージェントからリクエストしたチャンクのチェックサムを受信する。例として、最初の５つのチャンクに対し、クライアントは選択されたエージェントに５番目までのチャンクを問合せるが、これら５つのチャンクのうち４番目のバッチに対し、クライアントはエージェントに対して１６番目から２０番目までのチャンクを問合せる。前述のように、１回で追加のあるいはより少ない数のチャンクがリクエストされる場合もある。

【0069】

ブロック３９０に示すように、クライアントからリクエストを受信した後、選択されたエージェントは、内部のキャッシュ・データベース内でリクエストを検索して、リクエストされたデータのチャンクに関する情報を有しているかどうかを判断し、選択されたエージェントが通信ネットワーク内のリクエストのデータを保存しているピアに関する情報を有しているかどうか、あるいはエージェント自身がリクエストされたデータを内部のメモリに保持していないかどうかを判断する。選択されたエージェントがリクエストに対するエントリを有しているかどうかを判断するのに加えて、選択されたエージェントはまた情報が有効であるかどうかも判断する。特に、選択されたエージェントは、選択されたエージェントのメモリあるいはピアのメモリに保存されているデータが、リクエストに対してサーバ自身から受信した情報を現在も反映しているかどうかを判断する。ここで、情報が有効かどうかを判定するために、選択されたエージェントが利用するプロセスについて、より詳細な説明をする。

【0070】

ブロック３９２に示すように、情報（リクエストにより要求されたデータ）が存在しかつ有効であれば、エージェントはクライアントに対する以下の各チャンクを含むレスポンスを生成する。：（ｉ）チャンクのチェックサム；（ｉｉ）チャンクを保存している選択されたエージェントのデータベースが有するピアのリスト；（ｉｉｉ）情報の最初の５つのチャンクが存在する場合、選択されたエージェントは、クライアントからの最初のリクストを直接受信したサーバから受信した特定のプロトコル・ヘッダを提供する。

【0071】

ブロック３９４に示すように、各チャンクに対するピアのリストはリクエストを送信するクライアントに地理的に近い通信装置に保存される。本例においては、リスト中には５つの近接ピアしか登録されておらず、残りのピアはリストから除外されている。ブロック３９６に示す通り、作成されたレスポンス、つまり近接ピアのリストがクライアントへ返信される。返信がリクエストに対する最後のチャンク・セットである場合、クライアントに対する情報にその旨が含まれている方が望ましい点に留意が必要である。

【0072】

選択されたエージェントが、リクエストに関する情報を有していないことを発見した場合、あるいは、選択されたエージェントがその有する情報が有効ではないことを発見した場合、選択されたエージェントは、サーバから情報を直接ロードして、リクエストを送信したクライアントに対して応答する必要がある。ブロック４００に示す通り、選択されたエージェントはその後リクエストをサーバに直接送信する。選択されたエージェントは、その後、サーバから受信した情報（リクエストのヘッダおよびレスポンスのチャンク自身の両方）を、クライアントに対するレスポンスとして、および将来データをリクエストする他のクライアントの使用のため、内部のデータベースに保存する。選択されたエージェントは、その後クライアントに対するレスポンス（リスト）を作成する。レスポンスは、プロトコル・ヘッダ（最初の５つのチャンクが存在する場合）およびその５つのチャンクに対するチェックサムを有し、レスポンス自身をチャンクに対する唯一のピアとして提供する（ブロック４０４）。リストはその後クライアントに送信される（ブロック４０６）。

【0073】

図１１は、エージェントからピアのリストあるいは単一ピアのリストを受信した際の動作を示す、図１０のフローチャート続きのフローチャート４２０である。ブロック４２２が示す通り、クライアントはエージェントからレスポンス（チャンクのリスト、ピアその他の情報など対応データを含む）を受信する。５つのチャンクの各々について、クライアントはチャンクのダウンロード先としてリストされた各ピアにリクエストを送信する。クライアントが各ピアに送信するチャンク・リクエストは、クライアントが検索し受信しようとしているデータのチェックサムであり、チャンクのキー（識別子）である。

【0074】

ブロック４２４に示す通り、ピアはその後チャンクのデータを有しているかどうかについて応答する。例として、ピアのうち一部はオフライン状態、一部はオンライン状態関連する情報つまりチャンクを保持していない、また一部はオンライン状態かつ関連情報つまりチャンクを有している、という内容が挙げられる。ブロック４２６に示す通り、クライアントは関連情報に関し最も迅速に肯定的応答をしたピアを選択し、ピアにクライアントにチャンクを提供するために選択された旨を通知し、その他のピアには選択されなかった旨を通知する。

【0075】

ブロック４２８に示す通り、選択されたピアはその後チャンクをクライアントに送信する。クライアントのリクエストに対し応答するピアがない場合、クライアントはエージェントに対しピアが皆無であることを通知し、エージェントが別の５つのエージェントが存在すればそのリストを提供するか、あるいは前述の通りピアが存在しない場合、エージェントがウェブ・サーバから直接情報をダウンロードすることを留意する必要がある。

【0076】

クライアントはその後チャンクを将来の使用のため内部のキャッシュに保存する（ブロック４３０）。将来の使用とは、クライアントが情報と同一の情報を検索している別のクライアントに対し、ピアとして動作する場合に、チャンクを、リクエストを送信する通信装置に提供しなくてはならない場合である。ブロック４３２に示す通り、いずれのピアからもチャンクがロードされなかった場合、クライアントはエージェントに対する次のリクエストでチャンクを再度リクエストし、チャンクにクライアント・リストのピアからはロードできなかったチャンクとしてフラグを付ける。この状況において、エージェントはデータを直接サーバからロードし、クライアントに送信する。

【0077】

クライアントはその後、エージェントに対し、正常に受信したチャンクについて肯定応答する（ブロック４３４）。エージェントはその後チャンクをエージェント内のデータベースで検索し、クライアントにチャンク用のピアのリストを追加する。特にその場合、クライアントはチャンクを保存し他のクライアントにチャンクを提供することができる状態であるため、クライアントはピアとして動作する（ブロック４３６）。

【0078】

ブロック４３８で示す通り、クライアントはその後、オリジナル・リクエストを送信したウェブ・ブラウザあるいはその他のクライアントのアプリケーションにデータを渡し、データを当初の目的通り使用する。クライアントはリクストに対する全てのチャンクが受信されたかどうかを（ブロック４４０）エージェントが設定したフラグをチェックすることによって判断する。特に、エージェントが最後の５つのチャンクのリストを提供する場合、エージェントはクライアントへの応答の一部として情報、ここではフラグ、を含める。この情報によって、クライアントはある特定のリソースリクエストに対する全ての情報を受信した事を知ることができる。

【0079】

最後に受信したチャンクがリクエストに対する最後のチャンクではない場合、クライアントのプロセス・フローは、図１０のブロック３８４の動作まで戻って継続される。代わりに選択されたエージェントに、オリジナル情報リクエストのデータについて次の５つのチャンクをリクエストする。もう１つの方法として、リクエストの全てのチャンクが受信された場合、リクエストは完了し、フローは図９のブロック３５２から再スタートする。

【0080】

図１２は、エージェント、クライアントあるいはピアが、特定のＨＴＴＰリクエストが現在も有効であるかどうかを判定するために取るステップを示すフローチャート５００である。特に以下の例では、エージェント、クライアントまたはピアが、エージェントあるいはピア、クライアントのメモリ内に保存されている特定のデータが現在ウェブ・サーバ上にある情報を反映しているかどうかをどのように判断するのか示す。ブロック５０２に示す通り、ＨＴＴＰリクエストがエージェント、クライアントあるいはピアのキャッシュ・データベース内で検索され、ＨＴＴＰリクエストの有効性がチェックされる。例として、ＲＦＣ２６１６で定義されたＨＴＴＰプロトコルを使用して、ウェブ・サーバがＨＴＴＰヘッダ内の情報で特定のデータの有効性を判定する方法の概要を説明する。例えば、ＨＴＴＰヘッダ情報のうち、“ｍａｘ ａｇｅ”からデータが無効になる前にどのくらいの期間キャッシュされていたか、“ｎｏ ｃａｃｈｅ”からデータがキャッシュされておらずその他の情報に使用されていることなどが分かるが、これに限らない。

【0081】

ブロック５０４に示す通り、有効性評価の標準的方法は対象となっているＨＴＴＰリクエスト情報によって検証される。ブロック５０６に示す通り、保存されているリクエスト情報が現在も有効かどうかが判断される。リクエストされた情報が有効ならば、“ＶＡＬＩＤ（有効）”というレスポンスが返される（ブロック５０８）。また、リクエストされた情報が有効でない場合、関連ウェブ・サーバにＨＴＴＰ条件付きリクエストが送信され、保存されているデータが有効かどうかが判断される（ブロック５１０）。保存されているリクエストされた情報が有効ならば、“ＶＡＬＩＤ（有効）”レスポンスが返される（ブロック５０８）。また、保存されているリクエストされた情報が無効ならば、“ＩＮＶＡＬＩＤ（無効）”レスポンスが返される（ブロック５１４）。図１２に関する前述の説明は、ＨＴＴＰ情報が有効であるかどうかのチェック方法を説明したものであることに留意が必要である。当該技術に通じていれば使用、評価、および理解される、その他プロトコルの有効性を判断する方法は別途いくつか存在する。

【0082】

図１３は、アクセラレーション・サーバの動作の概要を示すフローチャート５５０である。本システムおよび方法におけるアクセラレーション・サーバの主な役割は、クライアントにどのエージェントがどのリクエストを処理するかという情報を提供し、またネットワーク構成要素全てのソフトウェアを最新の状態に保つことである。ブロック５５２に示す通り、アクセラレーション・サーバは、“ｋｅｅｐ ａｌｉｖｅ（キープ・アライブ）”信号をネットワーク構成要素に送信し、内部のデータベースでどのネットワーク構成要素がオンライン状態であるかを記録する。ブロック５５４に示す通り、アクセラレーション・サーバはクライアント・リクエストを待機しかつ受信したかどうかを継続的に判断する。

【0083】

一旦リクエストを受信すると、アクセラレーション・サーバは受信したリクエストのタイプを検証する（ブロック５５６）。クライアント・リクエストがネットワーク内のクライアントにサインアップした場合、クライアントがホスト・マシン上で起動される度にイベントが発生し、クライアントはアクセラレーション・サーバに保存されているエージェント・リストに、クライアントのＩＰアドレスによって追加される（ブロック５５８）。

【0084】

リクエストが特定のリクエストに対するエージェントを発見するものであった場合、アクセラレーション・サーバは新しい空のエージェント・リストを作成する（ブロック５６０）。アクセラレーション・サーバはその後、エージェント・データベースで、ＩＰアドレスがリクエストのターゲットとなっているサーバのＩＰアドレスに最も近い次の５つのアクティブ・エージェントを検索する（ブロック５６２）。この状況においては、１９２．１６６．３．１０３は１９２．１６７．３．１０４よりも１９２．１６６．３．２１２に近い。アクセラレーション・サーバはその後エージェント・リストをクライアントに送信する（ブロック５６４）。

【0085】

また、リクエストの内容が最新のアクセラレーション・ソフトウェアのバージョンをチェックするものであった場合、アクセラレーション・サーバはネットワーク構成要素（クライアント、ピアまたはエージェント）に対して既存のアクセラレーション・ソフトウェアの最新バージョン番号および構成要素が新バージョンにアップグレードしなくてはならない場合に備えて、新バージョンのダウンロード先ＵＲＬを送信する（ブロック５６６）。

【0086】

前述の例がデータに対するＨＴＴＰリクエストに焦点を当てているのに対し、前述したようにその他のプロトコル・リクエストも同じように本システムおよび方法において利用することができる。例として、アクセラレーションの方法が示されている別の実施形態においては、あらゆる通信プロトコルをＯＳＩ層（ＳＭＴＰ、ＤＮＳ、ＵＤＰ、ＥＴＨＥＲＮＥＴなど）でアクセラレートできる。以下の代替実施形態においては、アクセラレーションの方法がどのようにＴＣＰ／ＩＰをアクセラレートするのかを示している。当該の技術に通じていれば自明であるが、高レベル・プロトコルであるＨＴＴＰに対し、ＴＣＰ／ＩＰは相対的に低レベルのプロトコルとなっている。ウェブ・サーバがＴＣＰ／ＩＰとなっている図３でＴＣＰ／ＩＰ通信の例を示す。

【0087】

ＴＣＰ／ＩＰには、特に重要な接続、書き込み、読み取りという３つの通信コマンドがある。接続は、通信装置内のアプリケーションが発するコマンドで、ＴＣＰ／ＩＰスタックを構築して通信を開始し、遠隔の通信装置と接続する。接続メッセージには、通信装置のＩＰアドレスおよび接続先のポート番号が含まれる。アプリケーションは、書き込みコマンドを使用して、ＴＣＰ／ＩＰスタックに対し接続している通信装置にメッセージを送信するように指示する。さらに、アプリケーションは読み取りコマンドを使用してＴＣＰ／ＩＰスタックに接続された遠隔通信装置から送信されてきたメッセージを提供するよう指示する。通信セッションは一般的に、接続されている両者の読み書き後に確立される。

【0088】

図１４は、本発明の代替実施形態によるＴＣＰ／ＩＰアクセラレーションの詳細を示すフローチャート６００である。ブロック６０１および６０２に示す通り、通信装置のアプリケーションが通信スタックに対してリクエストを生成し、ＴＣＰ／ＩＰサーバと接続した場合、通信はアクセラレーション・アプリケーションによってインターセプトされる。

【0089】

エージェントを検出するために通信装置アプリケーションから接続先のＴＣＰ／ＩＰサーバのＩＰアドレスおよびポートを含む接続メッセージを受信すると、クライアント内のアクセラレーション・アプリケーションは、アクセラレーション・サーバ宛のリクエストを生成してＴＣＰ／ＩＰサーバとの通信するためのエージェントはどれであるかを発見する。このステップでは、ＨＴＴＰを使用した本発明の代表的実施形態において説明された方法と類似の方法で実行される。ブロック６０６に示す通り、サーバはその後、クライアントにエージェントのリスト、例えば、プライマリ・エージェントおよび他の４つのエージェントのリストを提供する。

【0090】

接続を確立するために、ブロック６０８に示す通り、クライアントはプライマリ・エージェントあるいはプライマリ・エージェントとの接続が失敗した場合は他のエージェントの１つとのＴＣＰ／ＩＰ接続リクエストを送信し、エージェントとの接続を形成する。クライアントはその後、エージェントに対して、通信装置アプリケーションから提供されたＴＣＰ／ＩＰサーバのＩＰアドレスおよび接続ポートを送信する（ブロック６１０）。ブロック６１２に示す通り、今度はエージェントがクライアントから受信したＴＣＰ／ＩＰサーバのポートに対してＴＣＰ／ＩＰ接続リクエストを送信し、エージェントとの接続を生成する。

【0091】

図１５は、本発明の代替実施形態によるＴＣＰ／ＩＰアクセラレーションの詳細を示すフローチャート８００であって、接続フェーズが成功した後のクライアントとＴＣＰ／ＩＰサーバ間の通信（読み書き命令）の詳細を示すフローチャートである。

【0092】

ブロック８０２に示す通り、クライアント内のネットワーク・アプリケーションがＴＣＰ／ＩＰサーバに対してメッセージを送信する場合、クライアント内のネットワーク・アプリケーションはクライアントのオペレーティング・システム内のＴＣＰ／ＩＰスタックに対しメッセージを書き込む。この「書き込み」コマンドは、クライアントのアクセラレーション・アプリケーションに受信され、以下に説明する方法で処理される。つまり、ＴＣＰ／ＩＰサーバがクライアントにメッセージを送信する場合、ＴＣＰ／ＩＰサーバはＴＣＰ／ＩＰオペレーティング・システムのＴＣＰ／ＩＰスタックに対して、エージェントへの接続に関するメッセージを書き込む。これは、エージェントが、サーバがオリジナルの接続を受信した場所であるためである。この「書き込み」コマンドは、エージェントのアクセラレーション・アプリケーションに受信され、以下に説明する方法で処理される。

【0093】

クライアントのアクセラレーション・アプリケーションがクライアントのネットワーク・アプリケーションからのエージェントに対して送信するメッセージを受信した場合、あるいはエージェントのアクセラレーション・アプリケーションがＴＣＰ／ＩＰサーバへの接続からクライアントへ送信するメッセージを受信した場合、アクセラレーション・アプリケーションは遠隔にある通信装置へメッセージを送信する。例えば、クライアントが通信アプリケーションからのメッセージをインターセプトした場合、クライアントはメッセージをエージェントへ送信し、ＴＣＰ／ＩＰサーバへの接続からのメッセージ、例えば、ＴＣＰ／ＩＰサーバがクライアントとの通信を要求するようなメッセージをインターセプトしたのがエージェントであった場合、エージェントは以下のような方法でクライアントにメッセージを送信する。

【0094】

ブロック８０４に示す通り、アクセラレーション・アプリケーションはメッセージの内容をチャンクに分解して、本明細書で説明する代表的実施形態と同じ方法で対応するチェックサムを計算する。アクセラレーション・アプリケーションはその後、内部のキャッシュ・データベースで各チェックサムを検索する（ブロック８０６）。ブロック８０８に示す通り、アクセラレーション・アプリケーションは、チェックサムがキャッシュ・データベースに存在するかどうかをチェックする。存在した場合、ブロック８１０に示す通り、アクセラレーション・アプリケーションは過去にチェックサムのチャンクを受信したことのあるピアのリストを（あれば）作成する。そして遠隔にある通信装置を、チャンクを受信したことのある通信装置のリストに追加する（内部データベースのチェックサムのピア・リストに追加）。将来情報をリクエストする他の通信装置に提供するためである。ブロック８１２に示す通り、ピアのリストは受信通信装置に送信され、その受信通信装置は、ブロック８１４に示す通り、メイン実施形態と同じ方法で受信したリスト内のピアからチャンクを検索する。

【0095】

送信通信装置のキャッシュ・データベース内にチェックサムが存在しない場合、ブロック８２０に示す通り、前期アクセラレーション・アプリケーションはチェックサムとチャンクを内部のキャッシュ・データベースに追加して、チャンクを遠隔の通信装置に送信し、かつ内部のデータベースにチェックサムを保持しているその他の通信装置をピアのリストに追加する。

【0096】

ブロック８１６に示す通り、全てのチャンクが受信できたかどうかを判断し、全てのチャンクが受信されていなければ、プロセスはブロック８０６から再度継続される。

【0097】

一旦全てのデータが受信されれば、ブロック８１８に示す通り、アクセラレーション・アプリケーションはデータをリクエスタに渡す。特に、クライアントにおいて、アクセラレーション・アプリケーションは完全なデータを通信アプリケーションに渡し、エージェントにおいては、アクセラレーション・アプリケーションは完全なデータを、リクエストを送信したＴＣＰ／ＩＰサーバに渡す。

【0098】

本発明における上述の実施の形態は、本発明の原理を明確に理解するために設定された可能性のある実施例を示したにすぎない。開示されている上記の実施の形態は本発明の開示を限定するものではなく、本発明の精神および原理を逸脱することがない限り、修正および変更を盛んに行ってよい。こうして行われた修正および変更が、本発明の範囲内における本開示および本発明に含まれ、続く請求によって保護されるように意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】