Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム
【課題】従来よりも更にユーザ端末からみた応答性能などを向上する。
【解決手段】本システムでは、Ｗｅｂクライアント（２０）とＷｅｂサーバ（３０）の間に、Ｗｅｂコンテンツのキャッシュデータを代理応答するＷｅｂプロキシサーバ（１０）のＰ２Ｐネットワーク（１００）が構成される。Ｐ２Ｐネットワーク（１００）で、ＤＨＴの仕組みを用いて、キャッシュの高速な検索、及び負荷分散を図る。Ｗｅｂプロキシサーバ（１０）は、要求を受けた際、Ｗｅｂクライアント（２０）から提供されるＷｅｂクライアント情報（７１）を用いて、キャッシュを応答する好適なノードを選択する機能を有する。Ｗｅｂクライアント情報（７１）は、例えば、Ｗｅｂクライアント（２０）とＷｅｂプロキシサーバ（１０）との間で過去にキャッシュを授受した時の応答時間の情報を含む。
【解決手段】本システムでは、Ｗｅｂクライアント（２０）とＷｅｂサーバ（３０）の間に、Ｗｅｂコンテンツのキャッシュデータを代理応答するＷｅｂプロキシサーバ（１０）のＰ２Ｐネットワーク（１００）が構成される。Ｐ２Ｐネットワーク（１００）で、ＤＨＴの仕組みを用いて、キャッシュの高速な検索、及び負荷分散を図る。Ｗｅｂプロキシサーバ（１０）は、要求を受けた際、Ｗｅｂクライアント（２０）から提供されるＷｅｂクライアント情報（７１）を用いて、キャッシュを応答する好適なノードを選択する機能を有する。Ｗｅｂクライアント情報（７１）は、例えば、Ｗｅｂクライアント（２０）とＷｅｂプロキシサーバ（１０）との間で過去にキャッシュを授受した時の応答時間の情報を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット等の情報処理の技術に関し、特に、Ｗｅｂプロキシ（Ｗｅｂコンテンツのキャッシュ・負荷分散などの機能）、Ｐ２Ｐ（Peer to Peer）通信、等の技術に関する。
【背景技術】
【０００２】
［Ｗｅｂプロキシ］ インターネットにおいて、ユーザ端末（Ｗｅｂクライアント）からＷｅｂサーバにアクセスしてＷｅｂコンテンツ（サービス等）を利用する。その際、Ｗｅｂクライアント−Ｗｅｂサーバ間に介在するＷｅｂプロキシサーバ（キャッシュサーバ）で、Ｗｅｂコンテンツのデータをキャッシュ（キャッシュデータを記憶）し、Ｗｅｂクライアントへ提供（代理応答）する。これにより、Ｗｅｂクライアントへの応答性能や、Ｗｅｂサーバの負荷低減・ネットワーク上の負荷分散などを図っている。
【０００３】
［Ｐ２Ｐ］ インターネット上に構成されるＰ２Ｐネットワークにおいて、Ｐ２Ｐ機能を備えた端末（ノード）は、Ｐ２Ｐのリンク（論理的な接続）で互いに通信し、対象のデータ（ファイル）を順次に転送し、交換し、また転送データのキャッシュ（コピー）を保持する。
【０００４】
［ＤＨＴ］ Ｐ２Ｐにおける有効な手法として分散ハッシュテーブル（ＤＨＴ：Distributed Hash Table）がある。ＤＨＴの手法では、Ｐ２Ｐノード及び転送ファイル（コンテンツ）に一意のＩＤが付与される。このＩＤは、Ｐ２ＰノードのＩＰアドレスや対象ファイル名などをもとに、ハッシュ関数を用いて算出して得られる。ＤＨＴにより、ファイル（そのＩＤ）とその保存先のＰ２Ｐノード（そのＩＤ）との対応関係が構成・管理される。各Ｐ２ＰノードがＤＨＴ情報及びキャッシュデータを分散的に保有する。ファイルを取得する際には、ＩＤからＤＨＴにより保存先が検索（発見）される。ＤＨＴでは、全Ｐ２Ｐノードについて、経路（あるノードから対象ファイルを持つノードまでの経路）が計算される。
【０００５】
［先行技術例］ 上記要素（Ｗｅｂプロキシ等）及びネットワーク性能向上などに関連する先行技術例として、特開２０１０−１９８１１６号公報（特許文献１）などがある。特許文献１（「Ｐ２Ｐを用いたＷｅｂアプリケーション間通信方法」等）では、以下のような記載がある。課題として、マッシュアップ（ＷｅｂＡＰＩを用いて他の複数のＷｅｂアプリケーションの機能を呼び出して組み合わせることによりＷｅｂアプリケーションを構築する等の技術）したＷｅｂアプリケーション間の通信であってもＷｅｂアプリケーションの応答性の低下を防止できるＰ２Ｐの技術を提供する（段落００１２〜００１５等）。ネットワークシステムとして、Ｗｅｂブラウザが動作するクライアントＰＣと、Ｗｅｂアプリケーションが動作するＷｅｂサーバと、キャッシュサーバとが接続され、データを転送するためのＰ２Ｐノードとして機能し、Ｗｅｂブラウザ−Ｗｅｂアプリケーション間、あるいは、Ｗｅｂアプリケーション間でデータが授受される。Ｐ２Ｐノードは、中継系ノード（例えばキャッシュサーバ）と、エッジ系ノード（例えばＷｅｂサーバ及びクライアントＰＣ）とに分類される。中継系ノードは、ネットワーク運営者により管理され、他の中継系ノード及びエッジ系ノードとの間にリンクを張る。エッジ系ノードは、Ｐ２Ｐ網への参加と離脱を自由とし、中継系ノードとの間にリンクを張る。中継系ノードは、データを中継するＰ２Ｐノードを記述したルート（経路）情報を保持し、ルート設定を行い、他の中継系ノードとの間（リンク）で、自ノードで保持しているルート情報を交換する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−１９８１１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前記特許文献１では、多段のＷｅｂアプリケーション（マッシュアップ）の呼び出し、人気のあるＷｅｂアプリケーションへの集中、等に対応するためのキャッシュ機構として、Ｐ２Ｐの仕組みを導入している（段落００１７等）。アクセス要求の多いＷｅｂアプリケーションに関してキャッシュ応答することにより、負荷軽減、応答時間の向上を図る。Ｗｅｂアプリケーション（マッシュアップ）にＰ２Ｐのキャッシュ機構を適用する場合の課題として、Ｐ２Ｐノードの参加・離脱によるルートの再計算による負荷増大・性能低下の問題を挙げている（段落００２８の課題１）。また、Ｐ２Ｐノード間のリンク（論理的な接続）によるオーバーレイネットワークと、実ネットワークとのトポロジ・特性の違いによる性能低下の問題を挙げている（段落００２９の課題２）。上記２つの問題への対処として、Ｐ２Ｐノードを前述の２種類（中継系、エッジ系）に分け、２つの問題を個別に処理する構成としている。中継系ノードのネットワークでは、基本的に固定のノードとし、ノード間のリンクの張り方、ルートの計算を担当し、トポロジ的に近くのノード間にリンクを張り、ルートの再計算を抑制している。
【０００８】
しかしながら、特許文献１のような技術でも、ユーザ端末（Ｗｅｂクライアント）からみた応答性能や応答品質などの面で改善余地などの課題がある。例えば、複数のキャッシュサーバで同じキャッシュデータを保有している場合で、各サーバからのユーザ端末へのキャッシュデータの応答において、応答時間（応答速度など）に差が生じる場合がある。しかし従来システムでは、上記複数の各サーバの応答時間などは考慮されていない。よって、応答時間が短くできる可能性があるにもかかわらず結果的に応答時間が長くなるサーバから応答されてしまう場合があり、ユーザ端末からみた応答性能などの面で劣る場合がある。
【０００９】
以上を鑑み、本発明の主な目的は、Ｗｅｂプロキシを用いたネットワークに係わり、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）からみた応答性能や応答品質などの向上を実現できる技術を提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明のうち代表的な形態は、Ｗｅｂプロキシを用いたネットワークによる情報処理システム（Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム）、等であって、以下に示す構成を有することを特徴とする。
【００１１】
本形態のシステムは、Ｗｅｂコンテンツ（ないしサービス）を要求するＷｅｂブラウザを含むＷｅｂクライアント装置と、Ｗｅｂコンテンツを提供するＷｅｂサーバ装置と、Ｗｅｂクライアント装置とＷｅｂサーバ装置の間でＷｅｂコンテンツのキャッシュデータを保有し代理応答で提供するＷｅｂプロキシサーバ装置とがネットワークで接続されるシステムである。複数のＷｅｂプロキシサーバ装置がＰ２Ｐネットワークで接続される。前記Ｐ２Ｐネットワークは、第１種のＷｅｂプロキシサーバであるグループリーダのノード群のＰ２Ｐ接続による第１のネットワークと、前記グループリーダに対して接続される、第２種のＷｅｂプロキシサーバであるグループメンバのノード群のＰ２Ｐ接続による第２のネットワークとで構成される。
【００１２】
前記第１種のＷｅｂプロキシサーバは、ＤＨＴ機能と、グループ管理機能とを有する。ＤＨＴ機能は、分散ハッシュテーブル（ＤＨＴ）情報を用いて、前記Ｗｅｂコンテンツと、当該Ｗｅｂコンテンツのキャッシュデータを保有する前記第２種のＷｅｂプロキシサーバとの対応関係を管理し、前記Ｗｅｂクライアント装置からのＷｅｂコンテンツの要求を受けると、前記ＤＨＴ情報を用いて、当該Ｗｅｂコンテンツのキャッシュデータを保有する該当の第２種のＷｅｂプロキシサーバを含むグループの該当の第１種のＷｅｂプロキシサーバを検索し、必要に応じて当該要求を転送する処理を行う。グループ管理機能は、自身が担当するグループに対応する前記第２のネットワークのグループメンバの各ノードの情報を管理し各ノードと通信する処理を行う。
【００１３】
前記第２種のＷｅｂプロキシサーバは、キャッシュ管理機能と、グループ通信機能とを有する。キャッシュ管理機能は、前記Ｗｅｂコンテンツのキャッシュデータを保有し情報を管理する処理を行う。グループ通信機能は、自身のグループ内で前記グループリーダのノードと情報を通信する処理を行う。
【００１４】
前記Ｗｅｂクライアント装置は、アクセス機能と、Ｗｅｂクライアント情報管理機能とを有する。アクセス機能は、対象のＷｅｂコンテンツの情報を前記第１種のＷｅｂプロキシサーバへ送信し、前記第２種のＷｅｂプロキシサーバから応答のキャッシュデータを取得する処理を行う。Ｗｅｂクライアント情報管理機能は、自身で管理するＷｅｂクライアント情報を前記第１種のＷｅｂプロキシサーバに対して提供する。
【００１５】
前記Ｗｅｂクライアント情報は、例えば、前記Ｗｅｂクライアント装置と前記Ｗｅｂプロキシサーバ装置との間で過去に前記Ｗｅｂコンテンツのキャッシュデータを取得した時の応答時間（ないし応答速度など）の情報を含む。
【００１６】
前記要求を受けた際、前記該当の第１種のＷｅｂプロキシサーバは、該当の第２種のＷｅｂプロキシサーバの中から、前記要求に対し応答させるノードを決定するために、前記Ｗｅｂクライアント情報を参照し、前記応答時間が短いノードを優先的に選択し、決定したノードへリダイレクトさせる処理を行う応答ノード選択機能を有する。
【００１７】
前記Ｗｅｂクライアント装置は、前記アクセス機能により、前記リダイレクト先の第２種のＷｅｂプロキシサーバから前記キャッシュデータを取得し、前記Ｗｅｂクライアント情報管理機能により、その時の応答時間の情報を記録する処理を行う。
【発明の効果】
【００１８】
本発明のうち代表的な形態によれば、Ｗｅｂプロキシを用いたネットワークに係わり、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）からみた応答性能や応答品質などの向上を実現できる。特に、ネットワークの負荷分散などを図りつつ、ユーザ端末へのＷｅｂコンテンツキャッシュデータの応答時間を短くしたり、応答データの品質を高めたりすることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態１のシステム（Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム）の全体の構成を示す図である。
【図２】実施の形態１のシステムでのネットワーク構造を示す図である。
【図３】実施の形態１のシステムでのネットワーク構築手続き等について示す図である。
【図４】実施の形態１のシステムでのＷｅｂクライアントからのアクセス手順（その１）を示す図である。
【図５】実施の形態１のシステムでのＷｅｂクライアントからのアクセス手順（その２）を示す図である。
【図６】実施の形態１のシステムでのＷｅｂサーバ側のキャッシュ更新の機能について示す図である。
【図７】実施の形態１のシステムでのグループリーダサーバによる応答サーバの選択の判定処理例について示す図である。
【図８】実施の形態１のシステムでの機能構成について示す図である。
【図９】本発明の実施の形態２のシステムでのコンテンツフィルタリング処理例について示す図である。
【図１０】実施の形態２のシステムでの機能構成について示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００２１】
＜実施の形態１＞
図１〜図７を用いて、本発明の実施の形態１のシステム（Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム）について説明する。特に、Ｗｅｂクライアント情報として、今までのＷｅｂクライアント−Ｗｅｂプロキシサーバ間におけるＷｅｂコンテンツキャッシュデータの授受の時の応答時間情報を用いて、最適な応答ノードを選択する構成を示す。
【００２２】
［システム構成］
図１において、実施の形態１のシステムの全体の構成として、インターネット上、ユーザ端末（Ｗｅｂクライアント）２０と、Ｗｅｂサーバ３０と、それらの間に介在するＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０と略す）１００とを有する。ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）１００は、複数のＷｅｂプロキシサーバ１０によるＰ２Ｐネットワークで構成される。１５は、Ｐ２ＰノードであるＷｅｂプロキシサーバ１０間の通信のリンク（論理的な接続）を示す。Ｗｅｂプロキシサーバ１０（特に後述のＧＭＳ１２）は、Ｗｅｂサーバ３０のＷｅｂコンテンツ（オリジナル）のデータ（５１）に関するキャッシュデータ（５２）を保有する。
【００２３】
ユーザ端末（Ｗｅｂクライアント）２０は、Ｗｅｂブラウザ２１と、Ｗｅｂブラウザ２１の追加機能を実現するプラグイン２２とを備える、ＰＣ等の各種の情報処理装置である。本システムでは、Ｗｅｂクライアント情報７１を利用して特徴的な処理を行うため、Ｗｅｂクライアント２０側に、対応する処理モジュール（プログラム）であるプラグイン２２を備える。なお、プラグイン２２という形に限らず、同様の処理機能をユーザ端末２０の持つ機能として実装すればよい。
【００２４】
Ｗｅｂサーバ３０は、Ｗｅｂサーバ３１（プログラム）と、後述の（Ｗｅｂサーバ用）クライアント機能３２とを備える情報処理装置（Ｗｅｂサーバ装置）であり、コンテンツ（オリジナル）５１を保有／提供する。コンテンツ（オリジナル）５１は、Ｗｅｂサーバ３０により提供されるサービス処理と捉えてもよい。
【００２５】
ユーザ端末２０のＷｅｂブラウザ２１（プラグイン２２の処理を経由する）から、Ｗｅｂサーバ３０の代わりに、本ネットワークＮ０のＷｅｂプロキシサーバ１０へアクセスし、Ｗｅｂコンテンツのキャッシュデータ（５２）を取得する。Ｎ０のキャッシュ（５２）を利用することにより、たとえ応答速度の遅いＷｅｂサーバ３０のコンテンツ（５１）（例えば高負荷、遠距離のサーバ、大容量のコンテンツなど）に対しても、ユーザ端末２０から高速なアクセス（取得）が可能である。
【００２６】
Ｗｅｂクライアント２０−Ｗｅｂサーバ３０間で、特に人が何もしなくても自動的に、本ネットワークＮ０が、コンテンツ（５１）に関する負荷分散を図ってくれる。Ｎ０は、ＤＨＴによるキャッシュ（５２）の配置及びその高速な検索、負荷分散などを実現する。
【００２７】
なお本システムで、各ノード（２０，１０，３０）は、必要に応じてＩＤ情報が付与され管理される。このＩＤは、ＩＰアドレスやＵＲＬ、あるいはハッシュ値などが適用可能である。例えば、ユーザ端末２０は、ＷｅｂクライアントＩＤ（プラグインＩＤ）を持つ。Ｗｅｂサーバ３０は、ＷｅｂサーバＩＤ，コンテンツＩＤなどを持つ。Ｗｅｂプロキシサーバ１０は、ＷｅｂプロキシサーバＩＤ（後述のＧＬＳノードＩＤ，ＧＭＳノードＩＤ），コンテンツＩＤなどを持つ。
【００２８】
［ネットワーク構造］
図２で、図１のＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）１００のネットワーク構造を示す。Ｎ０は、２種類（２層）のネットワークＮ１，Ｎ２により構成される。Ｎ０のＷｅｂプロキシサーバ１０は、２種類のＷｅｂプロキシサーバ１０（ＧＬＳ１１，ＧＭＳ１２）により構成される。第１のネットワーク（ＧＬＳネットワーク）Ｎ１は、第１種のＷｅｂプロキシサーバ１０であるグループリーダサーバ（ＧＬＳ）１１により構成される。第２のネットワーク（ＧＭＳネットワーク）Ｎ２は、上位の１つのＧＬＳ１１と、その下位に接続（リンク）される、第２種のＷｅｂプロキシサーバ１０であるグループメンバサーバ（ＧＭＳ）１２により構成される。
【００２９】
第１のネットワーク（ＧＬＳネットワーク）Ｎ１は、構造化ネットワーク（ネットワーク管理者により設定される基本的に静的な構造のネットワーク）である。各ＧＬＳ１１ノードは、ＦＱＤＮで管理されるドメインに対応付けられるグループ（第２のネットワークＮ２）を担当するように構成（設定）される。Ｎ１内（グループ（Ｎ２）間）では、各ＧＬＳ１１ノードが、ＤＨＴを用いて、ＧＬＳ１１間でのキャッシュデータ（５２）の配置、検索、負荷分散など（ＤＨＴ機能と総称する）を高速に実現する。各ＧＬＳ１１は、ＤＨＴ情報や、自身の担当グループ（Ｎ２）を構成する各ＧＭＳ１２ノードの情報などを、管理情報６１として保有する。
【００３０】
第２のネットワーク（ＧＭＳネットワーク）Ｎ２は、非構造化ネットワーク（基本的に動的な構造のネットワーク）であり、負荷の変化や障害に強く、コンテンツ（５２）の人気（要求の多さ）に応じて、適宜ＧＭＳ１２ノードが増減する。Ｎ２は、ＧＬＳ１１ノード毎の担当ドメイン（ＦＱＤＮ）のグループとして構築される。Ｎ２は、管理上は図示のようにツリー構造（Ｐ２Ｐのリンク１５がツリー状）のネットワークとして構成され、グループのメンバである複数のＧＭＳ１２ノードは、このツリー構造で上位の１つのＧＬＳ１１に対して接続される。特にグループ（Ｎ２）内で複数のＧＭＳ１２が同じコンテンツ（５１）のキャッシュデータ（５２）を保有することにより負荷分散を図る。
【００３１】
［ＦＱＤＮ・ドメイン］
本システムでは、グループ（Ｎ２）の構成に関し、ＦＱＤＮ（Fully Qualified Domain Name：完全修飾ドメイン名）を使用する。ＦＱＤＮは階層構造を持つドメイン名である（例：www.abcde.jp）。１つのＧＬＳ１１は、１つのＦＱＤＮを担当し、当該ＦＱＤＮ（対応ドメイン）に応じたグループ（Ｎ２）を担当し、当該グループ（Ｎ２）の情報を管理情報６１として持つ。
【００３２】
例えば図２で、Ｎ１のＧＬＳ１１のうちＩＤ「ＧＬＳ１」は、ある第１のＦＱＤＮ＃１を担当し、ＩＤ「ＧＬＳ２」は、ある第２のＦＱＤＮ＃２を担当する。例えば、「ＧＬＳ１」のグループ（Ｎ２）では、ＧＭＳ１２であるＩＤ「ＧＭＳ１」〜「ＧＭＳ４」が接続されている。
【００３３】
ＧＬＳネットワークＮ１の構築の際は、ＤＨＴの仕組みを利用して、ＦＱＤＮ（ドメイン）に対してＩＰアドレス（ノード）を一意に対応させるハッシュ関数によって、当該ＦＱＤＮ（ドメイン）とＩＰアドレス（ノード）との対応関係を決定する。
【００３４】
コンテンツＩＤ（ＵＲＬ等）とＦＱＤＮ（ドメイン）との対応関係があり、ＤＨＴによりＦＱＤＮ（ドメイン）とＩＰアドレス（ノード）との一意の対応関係が管理される。即ちコンテンツ（５１）のキャッシュ（５２）が配置されるグループ（Ｎ２）のＧＬＳ１１ノードのＩＰアドレスが管理される。またＧＬＳ１１は、グループ（Ｎ２）内でキャッシュ（５２）が配置されるＧＭＳ１２ノードのＩＰアドレスを管理する。Ｗｅｂクライアント２０から対象キャッシュデータ（５２）へのアクセスの際の流れとしては、コンテンツＩＤ（ＵＲＬ等）→ＦＱＤＮ（ドメイン）→ＤＨＴ（ハッシュ）→ＩＰアドレス（ＧＬＳノード）→（リダイレクト）→ＩＰアドレス（ＧＭＳノード）→対象コンテンツ（キャッシュ）、といった対応関係で到達することができる（後述）。
【００３５】
上記に関する構成例として、本システムでは、まず、ＦＱＤＮから生成されるＤＨＴに基づいてＧＭＳ１２（もしくはグループ（Ｎ２））を選出する。このＤＨＴは、キャッシュサーバ（応答ノードの候補）として、唯一のサーバ（ＧＭＳ１２／グループ）を指す（対応付ける）のではなく、特に、ＤＨＴ上の距離空間で距離的に近いサーバ（群）を代替サーバとして選出可能な構成とする。例えば上記構成により選出した上位の（距離的に一番近い）サーバの応答速度が遅いときは、ＤＨＴ上の距離が次に近いサーバ（群）をキャッシュサーバ（応答ノードの候補）として選出する。上記構成により、本システムでは、キャパシティが自動的に且つ効率的に増大する。
【００３６】
［ＤＨＴ］
ＤＨＴの手法（公知技術）において、各Ｐ２Ｐノード（本システムでのＮ１のＧＬＳ１１）は、ＤＨＴによる分散的な経路情報（ＤＨＴ情報）を保有する。経路情報は、自ノードから他ノード（宛先ノード）へデータを送信する際に、自ノードからリンク（１５）を張っているいずれのノードへデータを転送すれば宛先ノードへ届けることができるかを示す情報である。Ｎ１のＧＬＳ１１は、管理情報６１のうちのＤＨＴ情報を用いて、コンテンツキャッシュデータ（５２）の保有先となるグループ（対応ＧＬＳ１１）及びノード（ＧＭＳ１２）の登録及び検索が可能である。
【００３７】
ＧＬＳ１１の持つ管理情報６１は、ユーザ端末２０が要求している対象コンテンツのキャッシュデータ（５２）を提供するために、Ｎ１内のどのＧＬＳ１１ノード（該当ＧＬＳ１１）へ要求を転送するべきかを決定するために必要なＤＨＴ情報、及び、該当ＧＬＳ１１のグループ（Ｎ２）内のどのＧＭＳ１２ノード（該当ＧＭＳ１２）へ要求を転送（リダイレクト）するべきかを決定するために必要な情報（キャッシュの配置を含むＧＬＳノード情報）を含む。該当ＧＭＳ１２は、対象キャッシュ（５２）を保有するノードや、当該データ（５２）をＷｅｂクライアント２０へ応答させるノード（応答ノード）のことである。該当ＧＬＳ１１は、該当ＧＭＳ１２を含むグループ（Ｎ２）の上位ノードのことである。上記ＤＨＴ情報は、ハッシュ関数に基づき計算される、例えばコンテンツＩＤ（ＵＲＬ等）またはその対応ドメインと、宛先／転送先ノードＩＤ（ＧＬＳノードＩＤ）との対応関係の情報を含む。
【００３８】
［管理情報］
図３〜図５等に示すように、各ノードが本システムに係わる管理情報を持つ。Ｗｅｂクライアント２０（プラグイン２２）は、管理情報７０（図４，図５）として、アクセス用情報、ＧＬＳノード情報、ＧＭＳノード情報、などを持つ。上記アクセス用情報は、Ｗｅｂクライアント２０からネットワークＮ０（キャッシュ）へアクセスするための情報であり、対象コンテンツまたはその対応ドメインの情報、後述の初期ノード情報、Ｎ１（ＧＬＳ１１）へのアクセスにより得られるノード情報、などである。アクセス先ノードは基本的にＮ１のＧＬＳ１１ノードとなる。上記ＧＬＳノード情報やＧＭＳノード情報は、初期設定されたアクセス先ＧＬＳ１１ノード（初期ノード）のＩＰアドレス情報や、アクセスの実績に応じて増えるノード（１１，１２）毎のＩＰアドレス情報などである。また実施の形態１では、ＧＭＳノード情報として、応答時間（ＲＴ）の情報を含む。この応答時間（ＲＴ）の情報は、当該Ｗｅｂクライアント２０が今まで（過去）にＧＭＳ１２ノードとの間でキャッシュデータ（５２）を授受した時のＧＭＳ１２からの応答時間を示す情報である（図５）。
【００３９】
ＧＬＳ１１は、管理情報６１（図３，図４）として、ＤＨＴ情報、ＧＬＳノード情報、ＧＭＳノード情報などを持つ。上記ＤＨＴ情報は、前述の経路情報を含む、コンテンツＩＤ／ドメインと宛先／転送先ノードＩＤ（ＧＬＳノードＩＤ）との対応関係を示す情報である。上記ＧＬＳノード情報は、Ｎ１内の他のＧＬＳ１１ノードのＩＰアドレスなどの通信用の情報である。上記ＧＭＳノード情報は、当該ＧＬＳ１１の担当グループ（Ｎ２）内に接続されるメンバである各ＧＭＳ１２ノードのＩＰアドレスなどの通信用の情報、及びＧＭＳ１２に配置されるキャッシュ（５２）を示す管理情報である。ＧＭＳノード情報として特に、負荷情報、応答時間（ＲＴ）情報などを含む。負荷情報は、ＧＭＳ１１の負荷状態を示す情報であり、該当ＧＭＳ１２から通知される。応答時間（ＲＴ）情報は、ＧＭＳ１１とＷｅｂクライアント２０との応答時間（実績）を示す情報であり、Ｗｅｂクライアント２０側（Ｗｅｂクライアント情報７１）から提供される。
【００４０】
ＧＭＳ１２は、管理情報６２（図３，図４）として、グループノード情報、コンテンツ情報、負荷情報などを持つ。上記グループノード情報は、当該ＧＭＳ１２が含まれるグループ（Ｎ２）の上位のＧＬＳ１１ノードや他のＧＭＳ１２ノードとの通信用のＩＰアドレス情報などである。コンテンツ情報は、当該ＧＭＳ１２が保有するＷｅｂコンテンツ（５１）のキャッシュデータ（５２）のＩＤや他の管理情報などである。負荷情報は、当該ＧＭＳ１２の負荷状態を示す情報であり、ＧＬＳ１１へ通知される。
【００４１】
Ｗｅｂサーバ３０の持つ管理情報８０（図６）として、アクセス用情報、キャッシュ情報などを含む。アクセス用情報は、Ｗｅｂクライアント２０側と同様に、本ネットワークＮ０（ＧＬＳ１１）にアクセスするための情報である。キャッシュ情報は、自身が保有するＷｅｂコンテンツ（オリジナル）（５１）のＩＤや他の管理情報である。
【００４２】
［ネットワーク構築］
図３で、Ｎ０（Ｎ１，Ｎ２）のネットワーク構築の手続きや関連処理等について説明する。
【００４３】
（Ｎ１構築） ＧＬＳネットワークＮ１の構築では、ＧＬＳ１１毎の担当グループ（Ｎ２）となるドメイン（ＦＱＤＮ）を決める。所定の特性のハッシュ関数を用いて、ドメイン（ＦＱＤＮ）に対してＩＰアドレス（ノードのＩＰアドレス）を対応付ける。このドメイン（入力）とＩＰアドレス（出力）との対応関係は多対一である（１つのＧＬＳ１１は複数ドメインを１グループとして担当することができる）。
【００４４】
Ｎ０へのキャッシュ登録（配置）としては、例えば、第１のコンテンツ（５１）のＵＲＬが第１のドメイン（例：図２、ＦＱＤＮ＃１）に対応するとき、ＤＨＴで対応付けられる第１のＩＰアドレスのＧＬＳ１１（例：「ＧＬＳ１」）のグループ（Ｎ２）内のＧＭＳ１２に対応キャッシュ（５２）が保有され、また第２のＷｅｂコンテンツ（５２）のＵＲＬが第２のドメイン（例：ＦＱＤＮ＃２）に対応するとき、対応付けられる第２のＩＰアドレスのＧＬＳ１１（例：「ＧＬＳ２」）のグループ（Ｎ２）内のＧＭＳ１２に対応キャッシュ（５２）が保有される。ＧＬＳ１１は、管理情報６１（ＧＭＳノード情報）でキャッシュ配置を管理する。
【００４５】
Ｎ１の構築及び管理では、ネットワーク構築プロトコル（ＧＬＳ１１ノードの増減など）、情報共有プロトコル（ＧＬＳ１１ノード間のＤＨＴ情報の通信など）、耐障害プロトコル（グループ（Ｎ２）間のキャッシュ（５２）の負荷分散など）等については、例えば既存プロトコルを利用して実現する。
【００４６】
ＧＬＳ１１ノードには、最初（設置時）、ネットワーク管理者などにより、初期の管理情報６１が設定される（あるいは隣ノードからのＤＨＴ情報をコピーする等）。また、運用時、ＧＬＳ１１ノード間では、随時、Ｐ２Ｐのリンク１５を介して、管理情報６１の内容（ＤＨＴ情報など）が交換される。各ＧＬＳ１１ノードで最適な内容の状態になるように管理情報６１が動的に更新される。新規のＧＬＳ１１ノードが追加された場合、Ｎ１内の他のＧＬＳ１１ノードと通信して情報を取得することにより、新規のＧＬＳ１１ノードの管理情報６１が構成される。
【００４７】
（Ｎ２構築） ＧＭＳネットワークＮ２の構築では、ＧＬＳ１１をルート（最上位）のノードとして、その下位に、ＧＭＳ１２による管理上のツリー構造のＰ２Ｐネットワークを構築する。各ＧＭＳ１２ノードは負荷などに応じて自由に増減される。各ＧＭＳ１２ノードは、自身の管理情報６２を管理する。
【００４８】
なおツリー構造に応じて、ＧＭＳ１２をグループ（Ｎ２）内のサブリーダとして設定することもできる。例えば、図３の「ＧＭＳ２」をサブリーダとし、その下位の「ＧＭＳ３」「ＧＭＳ４」を含むサブグループを構成し、サブリーダは、サブグループ内のＧＭＳ１２ノードの情報を管理する。
【００４９】
Ｎ２の構築及び管理では、ネットワーク構築プロトコル（ＧＭＳ１２ノードの増減など）、情報共有プロトコル（ＧＭＳ１２ノード間での情報通知など）、耐障害プロトコル（ＧＭＳ１２ノード間でのキャッシュ（５２）の負荷分散など）等については、例えば既存プロトコルを利用して実現する。
【００５０】
運用時、各ＧＭＳ１２は、自身の管理情報６２で管理する自身の負荷状態を示す負荷情報を、自グループ（Ｎ２）の上位のＧＬＳ１１ノードへ通知する（図３、Ｂ１）。ＧＬＳ１１は、通知（Ｂ１）を受けると、管理情報６１の該当ＧＭＳ１２の負荷状態を記憶、更新する。なお逆に、ＧＬＳ１１が下位の各ＧＭＳ１２から負荷情報を収集する形などとしてもよい。負荷情報の通知（Ｂ１）の処理例としては、各ＧＭＳ１２は、自身の負荷（例えば計測値）が一定以上（例えば閾値以上）である場合（時）、その負荷状態（負荷大）を示す情報をＧＬＳ１１へ通知する。また、ＧＭＳ１２は、自身の負荷（例えば計測値）が一定以下（例えば閾値以下）である場合（時）、その負荷状態（負荷小）を示す情報をＧＬＳ１１へ通知する。
【００５１】
ＧＭＳ１２の負荷状態（負荷情報）として、少なくとも２値（負荷大／負荷小）を有するが、複数レベル値としてもよいし、負荷の計測値としてもよい。また上記に限らず他の各種の手段（例えば既存のサーバ監視システムの機能）を用いて、ＧＭＳ１２の負荷状態を検出し把握してもよい。
【００５２】
［クライアントアクセス手順（その１）］
図４で、Ｗｅｂコンテンツキャッシュデータ（５２）要求時のＷｅｂクライアント２０からのアクセス手順（基本）を示す。概略、ステップＳ１〜Ｓ３の順の処理が行われる。
【００５３】
（Ｓ１） まず、Ｗｅｂブラウザ２１（プラグイン２２）から、Ｎ１のＧＬＳ１１ノードにアクセスし、対象コンテンツ取得の要求を送信する。Ｎ１のＤＨＴ機能により、Ｗｅｂクライアント２０から該当ＧＬＳ１１ノード（対象キャッシュ（５２）を保有している該当ＧＭＳ１２を含むグループ（Ｎ２）の上位ノード）へ直接的にアクセス可能である。
【００５４】
（Ｓ２） 上記Ｓ１の要求を受けた該当ＧＬＳ１１ノードは、当該要求を、自身の担当グループ（Ｎ２）内の１つの該当ＧＭＳ１２ノード（対象キャッシュ（５２）を保有するノード）へ転送して処理（応答）を担当させる。そのために、ＧＬＳ１１は、自身の管理情報６１（各ＧＭＳ１２ノードの負荷情報を含む）を参照し、対象キャッシュ（５２）を保有する複数のＧＭＳ１２ノードのうち、なるべく負荷の小さい状態のＧＭＳ１２ノードを応答ノードとして選択する。ＧＬＳ１１は、Ｓ１の要求を自ノードから当該選択した応答ノード（対応するＩＰアドレス）へリダイレクトさせる。
【００５５】
なお通常、負荷分散の観点から、グループ（Ｎ２）内の複数のＧＭＳ１２ノードに同じキャッシュ（５２）を保有させるが、１つしかキャッシュ保有ノードが無い場合は当該ＧＭＳ１２が応答ノードとして決定される。また、上記選択した応答ノード（ＧＭＳ１２）での応答実行ができない場合は、ＧＬＳ１１を介して別のＧＭＳ１２ノード（例えば次に負荷が小さいノード）へ切り換えることができ、同様にリダイレクトすればよい。
【００５６】
上記ＧＭＳ１２の負荷に応じて選択する場合の判定例としては、ＧＬＳ１１は、通知（Ｂ１）で負荷が一定以上の状態（負荷大）のＧＭＳ１２については、以降、当該ＧＭＳ１２をリダイレクト先として指定しないようにする（優先順位を下げる等）。また、ＧＬＳ１１は、通知（Ｂ１）で負荷が一定以下の状態（負荷小）のＧＭＳ１２については、以降、当該ＧＭＳ１２をリダイレクト先として指定する候補にするようにする（優先順位を上げる等）。
【００５７】
（Ｓ３） 上記Ｓ２を受け、Ｗｅｂブラウザ２１（プラグイン２２）は、Ｎ２の上記リダイレクト先（応答ノード）のＧＭＳ１２（ＩＰアドレス）へアクセスし、当該ノードで保有している該当キャッシュデータ（５２）を取得する。即ち、当該ＧＭＳ１２からＷｅｂクライアント２０へ当該キャッシュ（コピー）を応答送信する。プラグイン２２は、対象データを正常に受信すると、自身の管理情報７０（ＧＭＳノード情報）に、今回の当該ＧＭＳ１２との応答で要した実績の応答時間（ＲＴ）の情報を記録する。
【００５８】
図４の例では、対象コンテンツキャッシュデータ（５２）を保有する該当ノードが「ＧＬＳ１」のグループ（Ｎ２）内の「ＧＭＳ１」「ＧＭＳ２」等である。Ｓ２の際、「ＧＬＳ１」は、その時の負荷が一番小さい例えば「ＧＭＳ１」を選択している。そして、「ＧＭＳ１」からのデータの応答の結果、Ｗｅｂクライアント２０は、「ＧＭＳ１」からのデータの応答で要した時間の大きさを示す情報を記録する。
【００５９】
なおＳ１，Ｓ２の際、プラグイン２２では、例えば、対象コンテンツＩＤ（ＵＲＬ等）を要求に添えてＧＬＳ１１側へ与える。ＧＬＳ１１側は、Ｗｅｂクライアント２０から与えられた情報に対し、管理情報６１（ＤＨＴ情報）の参照により、対象コンテンツに関係付けられる該当ＧＬＳ１１ノード（ＩＰアドレス）を高速に検索できる。
【００６０】
［クライアントアクセス手順（その２）］
続いて、図５で、Ｗｅｂコンテンツキャッシュデータ（５２）要求時のＷｅｂクライアント２０からのアクセス手順（詳細）について示す。ステップＡ１〜Ａ４等を有する。
【００６１】
前記Ｓ２でＧＬＳ１１が管理情報６１に基づきリダイレクト先（応答ノード）のＧＭＳ１２を選択する判定処理の際に、各ＧＭＳ１２の負荷状態と併せて、応答時間（ＲＴ）情報を考慮して決定する。
【００６２】
（Ａ１） Ｗｅｂクライアント２０（プラグイン２２）は、管理情報７０の一部として、Ｎ０（Ｎ１）への初期アクセス用の１つ以上のＧＬＳ１１ノードのＩＰアドレス等の情報（初期ノード情報）を有する。この初期ＧＬＳ１１ノードは任意でよい。Ｗｅｂクライアント２０は、初回、初期ノード情報を用いて、Ｎ１の初期ＧＬＳ１１ノードへアクセスする。図５の例では初期ノードが「ＧＬＳ０」である。例えば、プラグイン２２には予め上記初期ノード情報が設定（登録）されている。
【００６３】
上記初回アクセスした際、初期ＧＬＳ１１ノードから、その管理情報６１（ＤＨＴ情報）により、ＧＬＳネットワークＮ１の情報が得られる。即ち、対象キャッシュを保有する該当ＧＭＳ１２ノードを含むグループ（Ｎ２）の上位ノードである該当ＧＬＳ１１ノードの情報、あるいは該当ＧＬＳ１１ノードを含む複数または全てのＧＬＳ１１ノードの情報が得られる。Ｗｅｂクライアント２０は、得られた情報を用いて、該当ＧＬＳ１１ノード（ＩＰアドレス）へアクセス（要求を送信）する。本例では該当ＧＬＳ１１ノードが「ＧＬＳ１」である。
【００６４】
（Ａ２） Ｗｅｂクライアント２０は、２回目以降のＮ１へのアクセスでは、上記Ａ１の初回アクセス時に得た情報を用いて、該当ＧＬＳ１１ノードへ直接的にアクセス可能となる（図４のＳ１に対応）。
【００６５】
なおＷｅｂクライアント２０からのＮ０へのアクセス時に前回に対してＧＬＳネットワークＮ１の構造が変化していた場合は、Ａ１の初回アクセス時と同様の手順を踏む。なお基本的にはＧＬＳ１１を介してＧＭＳ１２（応答ノード）へアクセスする方式とし、Ｗｅｂクライアント２０から直接的に該当ＧＭＳ１２へアクセスする方式とはしない（その都度の適切な応答ノードを決定するため）。
【００６６】
前記図４のＳ１，Ｓ２に関し、該当ＧＬＳ１１ノードからグループ（Ｎ２）内の該当ＧＭＳ１２（応答ノード）を選択しリダイレクトさせる手順の詳細処理例は以下である。
【００６７】
（Ａ３） プラグイン２２は、前述のように、今まで（過去）にキャッシュ（５２）の取得でアクセスしたＧＭＳ１２ノードの情報、特に応答時間（ＲＴ）情報を、自身の管理情報７０として保有している。プラグイン２２は、該当ＧＬＳ１１へアクセスする際（Ａ２）に、要求情報と共に、上記応答時間（ＲＴ）を含む自身の情報（Ｗｅｂクライアント情報７１）を併せて送信・提供する。あるいは、その際、該当ＧＬＳ１１側からプラグイン２２側へ応答時間（ＲＴ）を含むＷｅｂクライアント情報７１を要求して取得してもよい。該当ＧＬＳ１１は、取得したＷｅｂクライアント情報７１の内容を管理情報６１に記録する。例えば、ＷｅｂクライアントＩＤと、当該応答時間（ＲＴ）が長かったＧＭＳ１２のノードＩＤとの対応関係の情報を記録する（後述、図７）。
【００６８】
また上記Ｗｅｂクライアント情報７１のやりとりに関しては、上記とは別の所定のタイミングで、ＧＬＳ１１がプラグイン２２からＷｅｂクライアント情報７１を収集・取得してもよい。また、要求（Ａ２）の都度に送受信せずに、応答時間（ＲＴ）の変化が大きい場合のみ送受信したり、既にＧＬＳ１１で取得済みのＷｅｂクライアント情報７１を繰り返し参照してもよい。
【００６９】
応答時間（ＲＴ）情報としては、例えば、リダイレクト後にＷｅｂクライアント２０（プラグイン２２）から該当ＧＭＳ１２へ要求を送信してから応答のキャッシュデータを受信するまでに要したターンアラウンドタイム［秒］などの形で計測した値としてもよい。あるいは、その計測値をもとに複数のレベルに区分した値などの形にしてもよい（例：短い／普通／長い：３レベル）。また勿論、応答時間に限らず、対応する応答速度などへ変換した値でもよい。あるいは、プラグイン２２での判断で、応答時間が所定の閾値以上で長かった場合や、所定の閾値以下で短かった場合に、対応するＧＭＳノードＩＤを記録またはＧＬＳ１１へ提供するようにしてもよいし、同様にＧＬＳ１１側で判断してもよい。
【００７０】
図５の例では、あるＷｅｂクライアント２０「ＣＬ１」について、過去の直近で、「ＧＭＳ１」との応答時間（ＲＴ）が一番短く、「ＧＭＳ２」のＲＴが一番長かったとする。そして、Ａ３で提供するＲＴ情報として、ＲＴ値が閾値以下、あるいは一番短かった条件に該当するＧＭＳ１２のノードＩＤ「ＧＭＳ１」を送信している。
【００７１】
（Ａ４） 該当ＧＬＳ１１ノードは、Ａ２（Ｓ１）の要求を受けた際、管理情報６１の参照に基づき、前述のように各ＧＭＳ１２ノードの負荷状態を考慮すると共に、各ＧＭＳ１２の応答時間（ＲＴ）情報を併せて考慮し、応答ノードとするＧＭＳ１２を選択する。例えば、グループ（Ｎ２）から、まず負荷が小さいあるいは問題無いノードを基本的な候補として抽出し、その複数のＧＭＳ１２ノードのうち、該当Ｗｅｂクライアント２０との応答時間（ＲＴ）が短かったノードを優先的に選択する。選択された応答ノード（ＩＰアドレス）がリダイレクト先として指定される。本例では、Ａ３の情報により、「ＣＬ１」−「ＧＭＳ１」間でＲＴが短かったため、「ＧＭＳ１」が応答ノードとして選択される。
【００７２】
別の処理例では、該当Ｗｅｂクライアント２０との応答時間（ＲＴ）が長かったＧＭＳ１２ノードを応答ノード選択の候補から外す（優先順位を下げる等）ようにしてもよい。
【００７３】
なお上記応答ノード選択の処理例では、同じＩＤのＷｅｂクライアント２０（例：「ＣＬ１」）に関して判定しているが、他の異なるＩＤのＷｅｂクライアント２０（例：「ＣＬ２」）に関しても、それらのクライアント（ＣＬ１，ＣＬ２）の位置等が類似であれば、応答時間（ＲＴ）も類似になると推測できるため、それら異なるＩＤのＷｅｂクライアント２０（複数）に関しても同様に判定してもよい。
【００７４】
またＷｅｂクライアント２０でプラグイン２２が管理情報７０を保持する方式に関して、例えば過去の複数回の応答時間（ＲＴ）の情報を履歴として保存する。例えば、Ｗｅｂクライアント２０が持つ所定のメモリ量の範囲内で保持する形とし、過去の古い情報から順に消去する。また、ＲＴ値の短い順／長い順にランキングのようにレコードを保持する形としてもよい。
【００７５】
［コンテンツキャッシュ更新］
図６で、Ｗｅｂサーバ３０側によるＷｅｂコンテンツキャッシュデータの更新の機能に関して説明する。Ｗｅｂサーバ３０に備えるクライアント機能３２により、Ｗｅｂサーバ３１のコンテンツ（オリジナル）５１のデータをネットワークＮ０へキャッシュ登録し、またその後、Ｎ０側へプッシュすることにより、Ｎ２（ＧＭＳ１２）のコンテンツ（キャッシュ）５２のデータを更新させる処理を行う。ステップＣ１，Ｃ２を有する。
【００７６】
例えば、Ｗｅｂサーバ３０（３１）は、コンテンツ（オリジナル）５１として、第１のコンテンツＣａ，第２のコンテンツＣｂを持つとする。キャッシュ登録時、第１のコンテンツＣａは、ＤＨＴにより、ある第１のＧＬＳ１１（例：「ＧＬＳ１」）のグループ（Ｎ２）内のＧＭＳ１２（例：「ＧＭＳ１」〜「ＧＭＳ３」）へ格納され、第２のコンテンツＣｂは、ＤＨＴにより、ある第２のＧＬＳ１１（例：「ＧＬＳ２」）のグループ（Ｎ２）のＧＭＳ１２（例：「ＧＭＳ４」）へ格納されるとする。
【００７７】
（Ｃ１） ステップＣ１で、Ｗｅｂサーバ３０（３１）でのコンテンツ（５１）の更新に伴いキャッシュ（５２）の更新を実行したい時、クライアント機能３２から、Ｎ１（該当ＧＬＳ１１）へアクセスする。この際のアクセス手順は、前述のＷｅｂクライアント２０側のアクセス手順と同様にＤＨＴの仕組み等を用いてなされる。本例では、クライアント機能３２から、コンテンツＣａのデータ（コピー）が「ＧＬＳ１」へプッシュ（送信）され、コンテンツＣｂのデータ（コピー）が「ＧＬＳ２」へプッシュ（送信）される。
【００７８】
（Ｃ２） ステップＣ２で、上記プッシュを受けた該当ＧＬＳ１１ノード（ＧＬＳ１，ＧＬＳ２）は、自身のグループ（Ｎ２）内の該当ＧＭＳ１２ノード（旧版のキャッシュを保有しているノード）へ、更新版のコンテンツデータを送信する。この際、Ｎ２のツリー構造に従い、上位のＧＬＳ１１から下位の各ＧＭＳ１２へ当該データを順次伝播させ、該当の各ＧＭＳ１２内のキャッシュ（５２）を更新させる。例えば「ＧＬＳ１」のグループ内の各ＧＭＳ１２（「ＧＭＳ１」〜「ＧＭＳ３」）で保有するキャッシュＣａ’がすべて更新される。
【００７９】
Ｗｅｂサーバ３０側のクライアント機能３２により、ネットワークＮ０内のキャッシュデータ（５２）の鮮度を高めることができ、即ちユーザ端末２０への応答性能・応答品質を高めることができる。
【００８０】
［判定処理例］
図７で、ＧＬＳ１１により応答ノード（ＧＭＳ１２）を選択する際の判定処理例について示す。判定の際に考慮する要素として、前述のように、負荷と応答時間（ＲＴ）があり、本実施の形態では両方を考慮して選択する。一方のみ考慮して選択する形態も可能である。
【００８１】
図７の例では、「ＧＬＳ１」のグループ（Ｎ２）の「ＧＭＳ１」「ＧＭＳ２」があり、それぞれ同じコンテンツ（キャッシュ）Ｃｘ’を保有しているとする。例えば、過去の直近のキャッシュ応答における応答時間（ＲＴ）として、ここでは簡単に短い／普通／長いの３レベル値としたとき、「ＧＭＳ１」はＲＴが短く、「ＧＭＳ２」はＲＴが長かったとする。このＲＴ情報はそれぞれプラグイン２２の管理情報７０にＧＭＳノードＩＤとの対応関係で記載される。このＲＴ情報を含むＷｅｂクライアント情報７１がＧＬＳ１１へ提供され、ＧＬＳ１１の管理情報６１に対応情報が記載される。
【００８２】
一方、ＧＬＳ１１は、随時、各ＧＭＳ１２からの負荷情報の通知（Ｂ１）を受けて、管理情報６１にＧＭＳ１２の負荷状態（現在の負荷状態）を記載している。例えば負荷をここでは簡単に小／中／大の３レベル値としたとき、「ＧＭＳ１」は現在の負荷が大、「ＧＭＳ２」は現在の負荷が小、とする。
【００８３】
前記Ｓ２（Ａ４）で、ＧＬＳ１１が応答ノードを選択するための判定処理において、管理情報６１を参照し、図７の例の状態では、応答ノードの候補となる「ＧＭＳ１」「ＧＭＳ２」に関して、現在の負荷の観点では、「ＧＭＳ２」の方が小さく、過去の応答時間（ＲＴ）の観点では、「ＧＭＳ１」の方が短い。ここで、負荷と応答時間の両方を考慮して判定する方式において、負荷の小ささを優先して選択する方式とする場合は、「ＧＭＳ２」を応答ノードとして選択し、応答時間の短さを優先して選択する方式とする場合は、「ＧＭＳ１」を応答ノードとして選択する。実施の形態１では、応答時間（ＲＴ）の短さを優先して選択する方式とし、本例では「ＧＭＳ１」が応答ノードとして選択される。
【００８４】
なお上記方式（優先する観点）を選択して設定可能としたり、上記方式を状況に応じて使い分けるように制御する形態としてもよい。また例えば、両方の要素（負荷、応答時間）の値を用いて所定の計算式で求めた値をもとに応答ノードを選択する方式としてもよい。例えば要素（優先する観点）に応じて重み付けの係数を設定し、候補のＧＭＳ１２ノード毎に、［負荷の係数］×［現在の負荷値］＋［応答時間の係数］×［過去の応答時間値］、といった計算式で値を求め、当該値に応じてノードを選択する。
【００８５】
また、利用する応答時間（ＲＴ）の情報としては、過去の直近のアクセス時の情報に限らず、過去の複数回のアクセスにおける平均などの統計値を利用してもよいし、ベストやワーストのランキング値を利用してもよい。
【００８６】
［機能］
図８を用いて、実施の形態１のシステムのハードウェア・ソフトウェア実装構成や機能構成についてまとめると以下である。ユーザ端末２０は、プロセッサ、メモリ（ＲＯＭ，ＲＡＭ，ディスク等）、入力装置、出力装置、通信インタフェース装置、及びバスなどを備え、これらを用いたソフトウェアプログラム処理（制御部２０１）により、Ｗｅｂブラウザ２１、及びプラグイン２２を実現する。プラグイン２２により、メモリ（記憶部２０２）に、Ｗｅｂクライアント情報７１を含む管理情報７０を記憶する。
【００８７】
プラグイン２２は、アクセス機能２２Ａ、Ｗｅｂクライアント情報管理機能２２Ｂなどの処理部を有する。アクセス機能２２Ａは、前述のアクセス用情報を用いて、対象コンテンツ（５２）を取得（要求）するためにネットワークＮ０（ＧＬＳ１１，ＧＭＳ１２）へアクセスする機能である。Ｗｅｂクライアント情報管理機能２２Ｂは、例えば、ＧＭＳ１２とのキャッシュデータの応答での応答時間（ＲＴ）を計測し、所定の形式の応答時間情報７２を作成し、Ｗｅｂクライアント情報７１（管理情報７０）の中に格納する処理や、ＧＬＳ１１へＷｅｂクライアント情報７１を送信・提供する処理などを行う。
【００８８】
Ｗｅｂサーバ３０は、プロセッサ、メモリ、入力装置、出力装置、通信インタフェース装置、及びバスなどを備え、これらを用いたソフトウェアプログラム処理（制御部３０１）により、Ｗｅｂサーバ３１やクライアント機能３２を実現する。Ｗｅｂサーバ３１及びクライアント機能３２は、メモリ（記憶部３０２）に、Ｗｅｂコンテンツのオリジナルデータ（５１）、及び管理情報８０などを記憶する。
【００８９】
クライアント機能３２は、アクセス機能３２Ａ、プッシュ機能３２Ｂなどの処理部を備える。アクセス機能３２Ａは、Ｗｅｂクライアント２０側の機能（２２Ａ）と同様にＮ０（ＧＬＳ１１）へアクセスするための機能である。プッシュ機能３２Ｂは、前述（図６）のプッシュによるキャッシュ更新などの処理を行う。
【００９０】
Ｗｅｂプロキシサーバ１０は、ＧＬＳ１１（第１種のＷｅｂプロキシサーバ）、ＧＭＳ１２（第２種のＷｅｂプロキシサーバ）を有し、それぞれ、プロセッサ、メモリ、入力装置、出力装置、通信インタフェース装置、及びバスなどを備え、これらを用いたソフトウェアプログラム処理（制御部１１１，１２１）により、対応する種別に応じたＧＬＳ機能やＧＭＳ機能を実現する。ＧＬＳ機能は、メモリ（記憶部１１２）に、前述の管理情報６１（ＤＨＴ，ＧＬＳ，ＧＭＳなどの情報）を記憶する。ＧＭＳ機能は、メモリ（記憶部１２２）に、前述の管理情報６２（グループ、コンテンツ、負荷などの情報）、及びキャッシュデータ（５２）を記憶する。
【００９１】
ＧＬＳ機能は、ＤＨＴ機能１１Ａ、グループ管理機能１１Ｂ、応答ノード選択機能１１Ｃなどを有する。ＤＨＴ機能１１Ａは、前述のＤＨＴによるキャッシュ（５２）の登録、検索などの処理、及び管理情報６１のＤＨＴ情報の管理処理を行う。グループ管理機能１１Ｂは、担当グループ（Ｎ２）の各ＧＭＳ１２ノードの情報などを管理情報６１として管理する処理を行う。応答ノード選択機能１１Ｃは、前述のＷｅｂクライアント情報７１（管理情報６１）に基づき応答ノードを選択する判定などの処理を行う。
【００９２】
ＧＭＳ機能は、キャッシュ管理機能１２Ａ、負荷管理機能１２Ｂ、グループ通信機能１２Ｃなどを有する。キャッシュ管理機能１２Ａは、自ノードのキャッシュデータ（５２）をメモリに保有し情報を管理する処理などを行う。負荷管理機能１２Ｂは、自ノードの負荷状態を計測し負荷情報として管理情報６２に格納する処理などを行う。グループ通信機能は、負荷情報の通知などのために自グループの上位のＧＬＳ１１や他のＧＭＳ１２と通信する処理などを行う。
【００９３】
［効果等］
以上のように、実施の形態１によれば、ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）及びＤＨＴ等の構成で、Ｗｅｂコンテンツキャッシュデータ（５２）の負荷分散を図りつつ、Ｗｅｂクライアント情報７１（特に応答時間情報）を用いてその都度好適な応答ノードを選択する構成により、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）２０からみた応答性能などを向上できる。特に、ネットワークの負荷分散などを図りつつ、ユーザ端末２０へのキャッシュデータ（５２）の応答時間を短くすることができる。
【００９４】
本システムで、実績の応答時間（ＲＴ）が長かったＧＭＳ１２ノードは、以降、応答ノードとして選択されにくくなるので、負荷は減る可能性があり、やがて応答性能が改善する可能性がある。改善した場合、当該ノードが応答ノードとして選択されやすくなる。また、応答時間（ＲＴ）が短かったノードは、以降、応答ノードとして選択されやすくなるので、負荷は増える可能性があり、やがて応答性能が落ちる可能性がある。落ちた場合、当該ノードが応答ノードとして選択されにくくなる。このように調整の作用が働くため、ネットワーク性能を向上または維持することができる。
【００９５】
＜実施の形態２＞
図９，図１０を用いて、本発明の実施の形態２のシステムについて説明する。実施の形態２では、実施の形態１を前提（図１〜図３等の基本構成を共通とする）として、更に、Ｗｅｂクライアント情報７１として、クライアント属性情報を利用し、クライアント属性情報に応じてキャッシュデータ応答に関するコンテンツフィルタリング（「ＣＦ」と略す）を行い、適切な（品質の高い）キャッシュデータを応答する構成を示す。
【００９６】
実施の形態２では、ネットワークＮ１のＧＬＳ１１ノードは、Ｗｅｂクライアント２０（プラグイン２２）から提供されるクライアント属性情報に応じて、コンテンツキャッシュデータ（５２）の取得（要求−応答）に係わる、応答ノード（実施の形態１と同様）を含む、ＣＦの内容（どのＧＭＳ１２ノードのどのコンテンツキャッシュデータ（５２）をブロック／非ブロックするか等）を決定する。そして、応答品質を高めるための好適な応答ノードとなるＧＭＳ１２ノードを選択し、選択されたＧＭＳ１２ノードからＣＦ後のキャッシュデータ（５２）を応答する。また特に、複数のＷｅｂクライアント２０及び複数のコンテンツ（５１）に関して、ネットワークＮ０側で上記クライアント属性情報を用いて協調フィルタリング処理を行うことにより、クライアント属性に応じたキャッシュデータ（５２）を提供する。
【００９７】
実施の形態２のシステムのＣＦ機能は、実施の形態１の機能（応答時間を考慮して応答ノードを選択する機能）とは独立した機能として説明する（実施の形態２では応答時間情報を用いない）。これに限らず、実施の形態１と実施の形態２の機能の両方を組み合わせた形態が可能である。例えば実施の形態１の機能を持つネットワークＮ０上に実施の形態２のＣＦ機能を持つ上位のネットワークをレイヤとして構成した形態などが可能である。
【００９８】
［コンテンツフィルタリング機能］
図９で、実施の形態２のＣＦ機能による処理例を示す。Ｎ１側のＧＬＳ１１は、ＣＦ機能を備える。Ｗｅｂクライアント２０からのコンテンツ取得要求に対し、ＧＬＳ１１のＣＦ機能により、Ｗｅｂクライアント２０からのＷｅｂクライアント情報７１（クライアント属性情報を含む）に応じて、ＧＭＳ１２のキャッシュ（５２）をフィルタリング（例えばブロック／非ブロック）して、該当ＧＭＳ１２ノードからＷｅｂクライアント２０へ応答する（ブロックの場合はキャッシュデータ送信無し）。
【００９９】
Ｗｅｂクライアント２０のプラグイン２２は、Ｗｅｂクライアント情報７１として、クライアント属性情報７３（あるいはユーザ設定によるＣＦ用設定情報）を管理・保持し、必要に応じてＧＬＳ１１側へ提供（送信）する。クライアント属性情報７３は、Ｗｅｂコンテンツ参照及びＣＦに係わる属性を示す情報である。具体例としては、ユーザ端末２０が教育用（学校など）のＰＣである場合、会社のＰＣである場合、一般家庭や個人のＰＣである場合、などが挙げられる。図９の例では、第１のＷｅｂクライアント２０である「ＣＬ１」のクライアント属性がＡであり、第２のＷｅｂクライアント２０である「ＣＬ２」のクライアント属性がＢとする。
【０１００】
また、Ｗｅｂサーバ３０により提供されるコンテンツ（５１，５２）に関するコンテンツ情報として、コンテンツ属性情報を有し、ＣＦに用いる。図９の例では、「ＧＭＳ１」が持つ第１のコンテンツ（キャッシュ）Ｃｘ’のコンテンツ属性をＸとし、「ＧＭＳ２」が持つ第２のコンテンツ（キャッシュ）Ｃｙ’のコンテンツ属性をＹとする。コンテンツ属性の具体例としては、教育用（学校など）のＷｅｂページ、会社のＷｅｂページ、一般家庭や個人の作成のＷｅｂページ、などが挙げられる。
【０１０１】
ＧＬＳ１１は、Ｗｅｂクライアント２０から提供されたＷｅｂクライアント情報７１（クライアント属性情報７３）に対応する情報を管理情報６１内に格納する。図９の例では、管理情報６１として前述のＤＨＴ情報（コンテンツとノード（ＧＬＳ１１）との対応関係の情報）やＧＭＳノード情報（キャッシュ配置など）などに加え、ＣＦ機能によるＣＦ管理情報９１を有する。ＣＦ管理情報９１において、ＣＦ状態（ＣＦ制御内容）を示す情報を含み、Ｗｅｂクライアント２０の属性と、コンテンツ（コンテンツ属性）と、ＧＭＳ１２（応答ノード）との対応関係における例えばブロック状態（ブロック対象）を管理する。
【０１０２】
ＧＬＳ１１は、コンテンツ取得要求に対し、ＣＦ管理情報９１を含む管理情報６１を参照し、前述の応答ノードとなるＧＭＳ１２、及びそのＣＦ対象のキャッシュデータ（５２）を決定する。実施の形態２では、ＣＦの内容として、簡単に、ブロック（提供しない）／非ブロック（元のまま提供する）の２通りがあるものとするが、これに限らず所定のＣＦ手法（データを加工して提供する等）を適用してもよい。
【０１０３】
図９の例では、あるグループ（Ｎ２）のＧＬＳ１１である「ＧＬＳ１」は、グループ内のＧＭＳ１２（「ＧＭＳ１」，「ＧＭＳ２」）の各キャッシュ（Ｃｘ’，Ｃｙ’）に関して、管理情報６１に基づきＣＦ（ブロック）を実行する。「ＣＬ１」（属性Ａ）は、「ＧＭＳ１」からはコンテンツＣｘ’（属性Ｘ）を非ブロックで取得できるが、「ＧＭＳ２」からはコンテンツＣｙ’（属性Ｙ）がＣＦによりブロックされ取得できない。また、「ＣＬ２」（属性Ｂ）は、「ＧＭＳ２」からはコンテンツＣｙ’（属性Ｙ）を非ブロックで取得できるが、「ＧＭＳ１」からはコンテンツＣｘ’（属性Ｘ）がＣＦによりブロックされ取得できない。
【０１０４】
ＧＬＳ１１のＣＦ機能は、クライアント属性とコンテンツ属性との関係を判断し、ＣＦ内容を決定する。例えば、ＣＦ機能は、複数のＷｅｂクライアント（クライアント属性）と複数のコンテンツ（コンテンツ属性）とを対象として、協調フィルタリング（公知技術）の処理を実行し、ＣＦ内容を決定する。例えば、ある属性Ａの「ＣＬ１」はある属性ＹのコンテンツＣｙ’がブロックされるというＣＦ状態情報を利用し、同じ属性Ａの別のＷｅｂクライアント２０である例えば「ＣＬ３」は同じ属性ＹのＣｙ’がブロックされるように制御される。即ち、類似のクライアント属性に対しては類似のコンテンツ属性をブロック／非ブロックするといったＣＦ内容になる。
【０１０５】
また、プラグイン２２により当該クライアント属性によるコンテンツ属性へのアクセス（対応関係）の情報を管理し、Ｗｅｂクライアント情報７１としてＧＬＳ１１へ提供し、ＧＬＳ１１で当該アクセス（対応関係）の情報を利用して同様に協調フィルタリングなどでＣＦ内容を決定するといった形態としてもよい。
【０１０６】
また、ＣＦ機能（クライアント属性情報に応じてコンテンツの応答をブロックする）をコンテンツ推薦機能（クライアント属性情報に応じて推薦するコンテンツを応答する）に替えてもよい。
【０１０７】
［機能］
図１０を用いて、実施の形態２のシステムのハードウェア・ソフトウェア実装構成や機能構成についてまとめると以下である。図８との違いとして、プラグイン２２によるＷｅｂクライアント情報７１を含む管理情報７０として、Ｗｅｂクライアント属性情報７３を含む。Ｗｅｂクライアント情報管理機能２２Ｂは、自身のＷｅｂクライアント属性情報７３をユーザ設定に基づき作成し、Ｗｅｂクライアント情報７１の中に格納する処理や、ＧＬＳ１１へ送信・提供する処理などを行う。またコンテンツ（５１，５２）に関する管理情報であるコンテンツ情報として、コンテンツ属性情報を含む。ＧＬＳ１１のＧＬＳ機能は、ＣＦ機能１１Ｄを含む。ＣＦ機能１１Ｄは、前述（図９）のＷｅｂクライアント情報７１（クライアント属性情報）に応じて応答ノードの応答キャッシュのフィルタリング処理を行う。ＧＬＳ機能の管理情報６１は、前述のＣＦ管理情報９１を含む。
【０１０８】
［効果等］
以上のように、実施の形態２によれば、ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）及びＤＨＴ等の構成で、Ｗｅｂコンテンツキャッシュデータ（５２）の負荷分散を図りつつ、Ｗｅｂクライアント情報７１（特にクライアント属性情報）を用いてコンテンツフィルタリングして好適なキャッシュデータを応答する構成により、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）２０からみた応答品質などを向上できる。特に、ネットワークの負荷分散などを図りつつ、ユーザ端末２０へ応答するコンテンツデータの品質を高めることができる。
【０１０９】
＜変形例等＞
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。前述した以外の変形例として以下が挙げられる。
【０１１０】
実施の形態１のようにＷｅｂクライアント２０側からＮ０（ＧＬＳ１１）側へ応答時間（ＲＴ）情報を含むＷｅｂクライアント情報７１を提供するので、例えばＲＴが長かったＧＭＳ１２ノード、即ちその時の応答性能が良くなかったノードを情報として把握することができる。この情報を利用して、該当ＧＭＳ１２ノードやそれを含むグループ（Ｎ２）あるいはネットワークＮ０全体に対する対処処理（応答性能の改善を図るための処理）を実行するようにしてもよい。例えば、ＧＬＳ１１から該当ＧＭＳ１２ノードやその管理者へ情報を通知して応答性能の改善に役立てる。例えば、該当グループ（Ｎ２）を含めＤＨＴによるキャッシュ（５２）の配置を再考し、応答性能の改善を図る。
【産業上の利用可能性】
【０１１１】
本発明は、インターネット等に利用可能である。
【符号の説明】
【０１１２】
１０…Ｗｅｂプロキシサーバ、１１…第１種のＷｅｂプロキシサーバ（グループリーダサーバ）、１２…第２種のＷｅｂプロキシサーバ（グループメンバサーバ）、１５…リンク、２０…ユーザ端末（Ｗｅｂクライアント）、２１…Ｗｅｂブラウザ、２２…プラグイン、３０…Ｗｅｂサーバ、３１…Ｗｅｂサーバ、３２…（Ｗｅｂサーバ用）クライアント機能、５１…コンテンツ（オリジナル）、５２…コンテンツ（キャッシュ）、７１…Ｗｅｂクライアント情報、１００…ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）、Ｎ１…グループリーダサーバネットワーク、Ｎ２…グループメンバサーバネットワーク。
【技術分野】
【０００１】
本発明は、インターネット等の情報処理の技術に関し、特に、Ｗｅｂプロキシ（Ｗｅｂコンテンツのキャッシュ・負荷分散などの機能）、Ｐ２Ｐ（Peer to Peer）通信、等の技術に関する。
【背景技術】
【０００２】
［Ｗｅｂプロキシ］ インターネットにおいて、ユーザ端末（Ｗｅｂクライアント）からＷｅｂサーバにアクセスしてＷｅｂコンテンツ（サービス等）を利用する。その際、Ｗｅｂクライアント−Ｗｅｂサーバ間に介在するＷｅｂプロキシサーバ（キャッシュサーバ）で、Ｗｅｂコンテンツのデータをキャッシュ（キャッシュデータを記憶）し、Ｗｅｂクライアントへ提供（代理応答）する。これにより、Ｗｅｂクライアントへの応答性能や、Ｗｅｂサーバの負荷低減・ネットワーク上の負荷分散などを図っている。
【０００３】
［Ｐ２Ｐ］ インターネット上に構成されるＰ２Ｐネットワークにおいて、Ｐ２Ｐ機能を備えた端末（ノード）は、Ｐ２Ｐのリンク（論理的な接続）で互いに通信し、対象のデータ（ファイル）を順次に転送し、交換し、また転送データのキャッシュ（コピー）を保持する。
【０００４】
［ＤＨＴ］ Ｐ２Ｐにおける有効な手法として分散ハッシュテーブル（ＤＨＴ：Distributed Hash Table）がある。ＤＨＴの手法では、Ｐ２Ｐノード及び転送ファイル（コンテンツ）に一意のＩＤが付与される。このＩＤは、Ｐ２ＰノードのＩＰアドレスや対象ファイル名などをもとに、ハッシュ関数を用いて算出して得られる。ＤＨＴにより、ファイル（そのＩＤ）とその保存先のＰ２Ｐノード（そのＩＤ）との対応関係が構成・管理される。各Ｐ２ＰノードがＤＨＴ情報及びキャッシュデータを分散的に保有する。ファイルを取得する際には、ＩＤからＤＨＴにより保存先が検索（発見）される。ＤＨＴでは、全Ｐ２Ｐノードについて、経路（あるノードから対象ファイルを持つノードまでの経路）が計算される。
【０００５】
［先行技術例］ 上記要素（Ｗｅｂプロキシ等）及びネットワーク性能向上などに関連する先行技術例として、特開２０１０−１９８１１６号公報（特許文献１）などがある。特許文献１（「Ｐ２Ｐを用いたＷｅｂアプリケーション間通信方法」等）では、以下のような記載がある。課題として、マッシュアップ（ＷｅｂＡＰＩを用いて他の複数のＷｅｂアプリケーションの機能を呼び出して組み合わせることによりＷｅｂアプリケーションを構築する等の技術）したＷｅｂアプリケーション間の通信であってもＷｅｂアプリケーションの応答性の低下を防止できるＰ２Ｐの技術を提供する（段落００１２〜００１５等）。ネットワークシステムとして、Ｗｅｂブラウザが動作するクライアントＰＣと、Ｗｅｂアプリケーションが動作するＷｅｂサーバと、キャッシュサーバとが接続され、データを転送するためのＰ２Ｐノードとして機能し、Ｗｅｂブラウザ−Ｗｅｂアプリケーション間、あるいは、Ｗｅｂアプリケーション間でデータが授受される。Ｐ２Ｐノードは、中継系ノード（例えばキャッシュサーバ）と、エッジ系ノード（例えばＷｅｂサーバ及びクライアントＰＣ）とに分類される。中継系ノードは、ネットワーク運営者により管理され、他の中継系ノード及びエッジ系ノードとの間にリンクを張る。エッジ系ノードは、Ｐ２Ｐ網への参加と離脱を自由とし、中継系ノードとの間にリンクを張る。中継系ノードは、データを中継するＰ２Ｐノードを記述したルート（経路）情報を保持し、ルート設定を行い、他の中継系ノードとの間（リンク）で、自ノードで保持しているルート情報を交換する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−１９８１１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前記特許文献１では、多段のＷｅｂアプリケーション（マッシュアップ）の呼び出し、人気のあるＷｅｂアプリケーションへの集中、等に対応するためのキャッシュ機構として、Ｐ２Ｐの仕組みを導入している（段落００１７等）。アクセス要求の多いＷｅｂアプリケーションに関してキャッシュ応答することにより、負荷軽減、応答時間の向上を図る。Ｗｅｂアプリケーション（マッシュアップ）にＰ２Ｐのキャッシュ機構を適用する場合の課題として、Ｐ２Ｐノードの参加・離脱によるルートの再計算による負荷増大・性能低下の問題を挙げている（段落００２８の課題１）。また、Ｐ２Ｐノード間のリンク（論理的な接続）によるオーバーレイネットワークと、実ネットワークとのトポロジ・特性の違いによる性能低下の問題を挙げている（段落００２９の課題２）。上記２つの問題への対処として、Ｐ２Ｐノードを前述の２種類（中継系、エッジ系）に分け、２つの問題を個別に処理する構成としている。中継系ノードのネットワークでは、基本的に固定のノードとし、ノード間のリンクの張り方、ルートの計算を担当し、トポロジ的に近くのノード間にリンクを張り、ルートの再計算を抑制している。
【０００８】
しかしながら、特許文献１のような技術でも、ユーザ端末（Ｗｅｂクライアント）からみた応答性能や応答品質などの面で改善余地などの課題がある。例えば、複数のキャッシュサーバで同じキャッシュデータを保有している場合で、各サーバからのユーザ端末へのキャッシュデータの応答において、応答時間（応答速度など）に差が生じる場合がある。しかし従来システムでは、上記複数の各サーバの応答時間などは考慮されていない。よって、応答時間が短くできる可能性があるにもかかわらず結果的に応答時間が長くなるサーバから応答されてしまう場合があり、ユーザ端末からみた応答性能などの面で劣る場合がある。
【０００９】
以上を鑑み、本発明の主な目的は、Ｗｅｂプロキシを用いたネットワークに係わり、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）からみた応答性能や応答品質などの向上を実現できる技術を提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明のうち代表的な形態は、Ｗｅｂプロキシを用いたネットワークによる情報処理システム（Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム）、等であって、以下に示す構成を有することを特徴とする。
【００１１】
本形態のシステムは、Ｗｅｂコンテンツ（ないしサービス）を要求するＷｅｂブラウザを含むＷｅｂクライアント装置と、Ｗｅｂコンテンツを提供するＷｅｂサーバ装置と、Ｗｅｂクライアント装置とＷｅｂサーバ装置の間でＷｅｂコンテンツのキャッシュデータを保有し代理応答で提供するＷｅｂプロキシサーバ装置とがネットワークで接続されるシステムである。複数のＷｅｂプロキシサーバ装置がＰ２Ｐネットワークで接続される。前記Ｐ２Ｐネットワークは、第１種のＷｅｂプロキシサーバであるグループリーダのノード群のＰ２Ｐ接続による第１のネットワークと、前記グループリーダに対して接続される、第２種のＷｅｂプロキシサーバであるグループメンバのノード群のＰ２Ｐ接続による第２のネットワークとで構成される。
【００１２】
前記第１種のＷｅｂプロキシサーバは、ＤＨＴ機能と、グループ管理機能とを有する。ＤＨＴ機能は、分散ハッシュテーブル（ＤＨＴ）情報を用いて、前記Ｗｅｂコンテンツと、当該Ｗｅｂコンテンツのキャッシュデータを保有する前記第２種のＷｅｂプロキシサーバとの対応関係を管理し、前記Ｗｅｂクライアント装置からのＷｅｂコンテンツの要求を受けると、前記ＤＨＴ情報を用いて、当該Ｗｅｂコンテンツのキャッシュデータを保有する該当の第２種のＷｅｂプロキシサーバを含むグループの該当の第１種のＷｅｂプロキシサーバを検索し、必要に応じて当該要求を転送する処理を行う。グループ管理機能は、自身が担当するグループに対応する前記第２のネットワークのグループメンバの各ノードの情報を管理し各ノードと通信する処理を行う。
【００１３】
前記第２種のＷｅｂプロキシサーバは、キャッシュ管理機能と、グループ通信機能とを有する。キャッシュ管理機能は、前記Ｗｅｂコンテンツのキャッシュデータを保有し情報を管理する処理を行う。グループ通信機能は、自身のグループ内で前記グループリーダのノードと情報を通信する処理を行う。
【００１４】
前記Ｗｅｂクライアント装置は、アクセス機能と、Ｗｅｂクライアント情報管理機能とを有する。アクセス機能は、対象のＷｅｂコンテンツの情報を前記第１種のＷｅｂプロキシサーバへ送信し、前記第２種のＷｅｂプロキシサーバから応答のキャッシュデータを取得する処理を行う。Ｗｅｂクライアント情報管理機能は、自身で管理するＷｅｂクライアント情報を前記第１種のＷｅｂプロキシサーバに対して提供する。
【００１５】
前記Ｗｅｂクライアント情報は、例えば、前記Ｗｅｂクライアント装置と前記Ｗｅｂプロキシサーバ装置との間で過去に前記Ｗｅｂコンテンツのキャッシュデータを取得した時の応答時間（ないし応答速度など）の情報を含む。
【００１６】
前記要求を受けた際、前記該当の第１種のＷｅｂプロキシサーバは、該当の第２種のＷｅｂプロキシサーバの中から、前記要求に対し応答させるノードを決定するために、前記Ｗｅｂクライアント情報を参照し、前記応答時間が短いノードを優先的に選択し、決定したノードへリダイレクトさせる処理を行う応答ノード選択機能を有する。
【００１７】
前記Ｗｅｂクライアント装置は、前記アクセス機能により、前記リダイレクト先の第２種のＷｅｂプロキシサーバから前記キャッシュデータを取得し、前記Ｗｅｂクライアント情報管理機能により、その時の応答時間の情報を記録する処理を行う。
【発明の効果】
【００１８】
本発明のうち代表的な形態によれば、Ｗｅｂプロキシを用いたネットワークに係わり、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）からみた応答性能や応答品質などの向上を実現できる。特に、ネットワークの負荷分散などを図りつつ、ユーザ端末へのＷｅｂコンテンツキャッシュデータの応答時間を短くしたり、応答データの品質を高めたりすることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態１のシステム（Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム）の全体の構成を示す図である。
【図２】実施の形態１のシステムでのネットワーク構造を示す図である。
【図３】実施の形態１のシステムでのネットワーク構築手続き等について示す図である。
【図４】実施の形態１のシステムでのＷｅｂクライアントからのアクセス手順（その１）を示す図である。
【図５】実施の形態１のシステムでのＷｅｂクライアントからのアクセス手順（その２）を示す図である。
【図６】実施の形態１のシステムでのＷｅｂサーバ側のキャッシュ更新の機能について示す図である。
【図７】実施の形態１のシステムでのグループリーダサーバによる応答サーバの選択の判定処理例について示す図である。
【図８】実施の形態１のシステムでの機能構成について示す図である。
【図９】本発明の実施の形態２のシステムでのコンテンツフィルタリング処理例について示す図である。
【図１０】実施の形態２のシステムでの機能構成について示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００２１】
＜実施の形態１＞
図１〜図７を用いて、本発明の実施の形態１のシステム（Ｐ２Ｐ型Ｗｅｂプロキシネットワークシステム）について説明する。特に、Ｗｅｂクライアント情報として、今までのＷｅｂクライアント−Ｗｅｂプロキシサーバ間におけるＷｅｂコンテンツキャッシュデータの授受の時の応答時間情報を用いて、最適な応答ノードを選択する構成を示す。
【００２２】
［システム構成］
図１において、実施の形態１のシステムの全体の構成として、インターネット上、ユーザ端末（Ｗｅｂクライアント）２０と、Ｗｅｂサーバ３０と、それらの間に介在するＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０と略す）１００とを有する。ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）１００は、複数のＷｅｂプロキシサーバ１０によるＰ２Ｐネットワークで構成される。１５は、Ｐ２ＰノードであるＷｅｂプロキシサーバ１０間の通信のリンク（論理的な接続）を示す。Ｗｅｂプロキシサーバ１０（特に後述のＧＭＳ１２）は、Ｗｅｂサーバ３０のＷｅｂコンテンツ（オリジナル）のデータ（５１）に関するキャッシュデータ（５２）を保有する。
【００２３】
ユーザ端末（Ｗｅｂクライアント）２０は、Ｗｅｂブラウザ２１と、Ｗｅｂブラウザ２１の追加機能を実現するプラグイン２２とを備える、ＰＣ等の各種の情報処理装置である。本システムでは、Ｗｅｂクライアント情報７１を利用して特徴的な処理を行うため、Ｗｅｂクライアント２０側に、対応する処理モジュール（プログラム）であるプラグイン２２を備える。なお、プラグイン２２という形に限らず、同様の処理機能をユーザ端末２０の持つ機能として実装すればよい。
【００２４】
Ｗｅｂサーバ３０は、Ｗｅｂサーバ３１（プログラム）と、後述の（Ｗｅｂサーバ用）クライアント機能３２とを備える情報処理装置（Ｗｅｂサーバ装置）であり、コンテンツ（オリジナル）５１を保有／提供する。コンテンツ（オリジナル）５１は、Ｗｅｂサーバ３０により提供されるサービス処理と捉えてもよい。
【００２５】
ユーザ端末２０のＷｅｂブラウザ２１（プラグイン２２の処理を経由する）から、Ｗｅｂサーバ３０の代わりに、本ネットワークＮ０のＷｅｂプロキシサーバ１０へアクセスし、Ｗｅｂコンテンツのキャッシュデータ（５２）を取得する。Ｎ０のキャッシュ（５２）を利用することにより、たとえ応答速度の遅いＷｅｂサーバ３０のコンテンツ（５１）（例えば高負荷、遠距離のサーバ、大容量のコンテンツなど）に対しても、ユーザ端末２０から高速なアクセス（取得）が可能である。
【００２６】
Ｗｅｂクライアント２０−Ｗｅｂサーバ３０間で、特に人が何もしなくても自動的に、本ネットワークＮ０が、コンテンツ（５１）に関する負荷分散を図ってくれる。Ｎ０は、ＤＨＴによるキャッシュ（５２）の配置及びその高速な検索、負荷分散などを実現する。
【００２７】
なお本システムで、各ノード（２０，１０，３０）は、必要に応じてＩＤ情報が付与され管理される。このＩＤは、ＩＰアドレスやＵＲＬ、あるいはハッシュ値などが適用可能である。例えば、ユーザ端末２０は、ＷｅｂクライアントＩＤ（プラグインＩＤ）を持つ。Ｗｅｂサーバ３０は、ＷｅｂサーバＩＤ，コンテンツＩＤなどを持つ。Ｗｅｂプロキシサーバ１０は、ＷｅｂプロキシサーバＩＤ（後述のＧＬＳノードＩＤ，ＧＭＳノードＩＤ），コンテンツＩＤなどを持つ。
【００２８】
［ネットワーク構造］
図２で、図１のＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）１００のネットワーク構造を示す。Ｎ０は、２種類（２層）のネットワークＮ１，Ｎ２により構成される。Ｎ０のＷｅｂプロキシサーバ１０は、２種類のＷｅｂプロキシサーバ１０（ＧＬＳ１１，ＧＭＳ１２）により構成される。第１のネットワーク（ＧＬＳネットワーク）Ｎ１は、第１種のＷｅｂプロキシサーバ１０であるグループリーダサーバ（ＧＬＳ）１１により構成される。第２のネットワーク（ＧＭＳネットワーク）Ｎ２は、上位の１つのＧＬＳ１１と、その下位に接続（リンク）される、第２種のＷｅｂプロキシサーバ１０であるグループメンバサーバ（ＧＭＳ）１２により構成される。
【００２９】
第１のネットワーク（ＧＬＳネットワーク）Ｎ１は、構造化ネットワーク（ネットワーク管理者により設定される基本的に静的な構造のネットワーク）である。各ＧＬＳ１１ノードは、ＦＱＤＮで管理されるドメインに対応付けられるグループ（第２のネットワークＮ２）を担当するように構成（設定）される。Ｎ１内（グループ（Ｎ２）間）では、各ＧＬＳ１１ノードが、ＤＨＴを用いて、ＧＬＳ１１間でのキャッシュデータ（５２）の配置、検索、負荷分散など（ＤＨＴ機能と総称する）を高速に実現する。各ＧＬＳ１１は、ＤＨＴ情報や、自身の担当グループ（Ｎ２）を構成する各ＧＭＳ１２ノードの情報などを、管理情報６１として保有する。
【００３０】
第２のネットワーク（ＧＭＳネットワーク）Ｎ２は、非構造化ネットワーク（基本的に動的な構造のネットワーク）であり、負荷の変化や障害に強く、コンテンツ（５２）の人気（要求の多さ）に応じて、適宜ＧＭＳ１２ノードが増減する。Ｎ２は、ＧＬＳ１１ノード毎の担当ドメイン（ＦＱＤＮ）のグループとして構築される。Ｎ２は、管理上は図示のようにツリー構造（Ｐ２Ｐのリンク１５がツリー状）のネットワークとして構成され、グループのメンバである複数のＧＭＳ１２ノードは、このツリー構造で上位の１つのＧＬＳ１１に対して接続される。特にグループ（Ｎ２）内で複数のＧＭＳ１２が同じコンテンツ（５１）のキャッシュデータ（５２）を保有することにより負荷分散を図る。
【００３１】
［ＦＱＤＮ・ドメイン］
本システムでは、グループ（Ｎ２）の構成に関し、ＦＱＤＮ（Fully Qualified Domain Name：完全修飾ドメイン名）を使用する。ＦＱＤＮは階層構造を持つドメイン名である（例：www.abcde.jp）。１つのＧＬＳ１１は、１つのＦＱＤＮを担当し、当該ＦＱＤＮ（対応ドメイン）に応じたグループ（Ｎ２）を担当し、当該グループ（Ｎ２）の情報を管理情報６１として持つ。
【００３２】
例えば図２で、Ｎ１のＧＬＳ１１のうちＩＤ「ＧＬＳ１」は、ある第１のＦＱＤＮ＃１を担当し、ＩＤ「ＧＬＳ２」は、ある第２のＦＱＤＮ＃２を担当する。例えば、「ＧＬＳ１」のグループ（Ｎ２）では、ＧＭＳ１２であるＩＤ「ＧＭＳ１」〜「ＧＭＳ４」が接続されている。
【００３３】
ＧＬＳネットワークＮ１の構築の際は、ＤＨＴの仕組みを利用して、ＦＱＤＮ（ドメイン）に対してＩＰアドレス（ノード）を一意に対応させるハッシュ関数によって、当該ＦＱＤＮ（ドメイン）とＩＰアドレス（ノード）との対応関係を決定する。
【００３４】
コンテンツＩＤ（ＵＲＬ等）とＦＱＤＮ（ドメイン）との対応関係があり、ＤＨＴによりＦＱＤＮ（ドメイン）とＩＰアドレス（ノード）との一意の対応関係が管理される。即ちコンテンツ（５１）のキャッシュ（５２）が配置されるグループ（Ｎ２）のＧＬＳ１１ノードのＩＰアドレスが管理される。またＧＬＳ１１は、グループ（Ｎ２）内でキャッシュ（５２）が配置されるＧＭＳ１２ノードのＩＰアドレスを管理する。Ｗｅｂクライアント２０から対象キャッシュデータ（５２）へのアクセスの際の流れとしては、コンテンツＩＤ（ＵＲＬ等）→ＦＱＤＮ（ドメイン）→ＤＨＴ（ハッシュ）→ＩＰアドレス（ＧＬＳノード）→（リダイレクト）→ＩＰアドレス（ＧＭＳノード）→対象コンテンツ（キャッシュ）、といった対応関係で到達することができる（後述）。
【００３５】
上記に関する構成例として、本システムでは、まず、ＦＱＤＮから生成されるＤＨＴに基づいてＧＭＳ１２（もしくはグループ（Ｎ２））を選出する。このＤＨＴは、キャッシュサーバ（応答ノードの候補）として、唯一のサーバ（ＧＭＳ１２／グループ）を指す（対応付ける）のではなく、特に、ＤＨＴ上の距離空間で距離的に近いサーバ（群）を代替サーバとして選出可能な構成とする。例えば上記構成により選出した上位の（距離的に一番近い）サーバの応答速度が遅いときは、ＤＨＴ上の距離が次に近いサーバ（群）をキャッシュサーバ（応答ノードの候補）として選出する。上記構成により、本システムでは、キャパシティが自動的に且つ効率的に増大する。
【００３６】
［ＤＨＴ］
ＤＨＴの手法（公知技術）において、各Ｐ２Ｐノード（本システムでのＮ１のＧＬＳ１１）は、ＤＨＴによる分散的な経路情報（ＤＨＴ情報）を保有する。経路情報は、自ノードから他ノード（宛先ノード）へデータを送信する際に、自ノードからリンク（１５）を張っているいずれのノードへデータを転送すれば宛先ノードへ届けることができるかを示す情報である。Ｎ１のＧＬＳ１１は、管理情報６１のうちのＤＨＴ情報を用いて、コンテンツキャッシュデータ（５２）の保有先となるグループ（対応ＧＬＳ１１）及びノード（ＧＭＳ１２）の登録及び検索が可能である。
【００３７】
ＧＬＳ１１の持つ管理情報６１は、ユーザ端末２０が要求している対象コンテンツのキャッシュデータ（５２）を提供するために、Ｎ１内のどのＧＬＳ１１ノード（該当ＧＬＳ１１）へ要求を転送するべきかを決定するために必要なＤＨＴ情報、及び、該当ＧＬＳ１１のグループ（Ｎ２）内のどのＧＭＳ１２ノード（該当ＧＭＳ１２）へ要求を転送（リダイレクト）するべきかを決定するために必要な情報（キャッシュの配置を含むＧＬＳノード情報）を含む。該当ＧＭＳ１２は、対象キャッシュ（５２）を保有するノードや、当該データ（５２）をＷｅｂクライアント２０へ応答させるノード（応答ノード）のことである。該当ＧＬＳ１１は、該当ＧＭＳ１２を含むグループ（Ｎ２）の上位ノードのことである。上記ＤＨＴ情報は、ハッシュ関数に基づき計算される、例えばコンテンツＩＤ（ＵＲＬ等）またはその対応ドメインと、宛先／転送先ノードＩＤ（ＧＬＳノードＩＤ）との対応関係の情報を含む。
【００３８】
［管理情報］
図３〜図５等に示すように、各ノードが本システムに係わる管理情報を持つ。Ｗｅｂクライアント２０（プラグイン２２）は、管理情報７０（図４，図５）として、アクセス用情報、ＧＬＳノード情報、ＧＭＳノード情報、などを持つ。上記アクセス用情報は、Ｗｅｂクライアント２０からネットワークＮ０（キャッシュ）へアクセスするための情報であり、対象コンテンツまたはその対応ドメインの情報、後述の初期ノード情報、Ｎ１（ＧＬＳ１１）へのアクセスにより得られるノード情報、などである。アクセス先ノードは基本的にＮ１のＧＬＳ１１ノードとなる。上記ＧＬＳノード情報やＧＭＳノード情報は、初期設定されたアクセス先ＧＬＳ１１ノード（初期ノード）のＩＰアドレス情報や、アクセスの実績に応じて増えるノード（１１，１２）毎のＩＰアドレス情報などである。また実施の形態１では、ＧＭＳノード情報として、応答時間（ＲＴ）の情報を含む。この応答時間（ＲＴ）の情報は、当該Ｗｅｂクライアント２０が今まで（過去）にＧＭＳ１２ノードとの間でキャッシュデータ（５２）を授受した時のＧＭＳ１２からの応答時間を示す情報である（図５）。
【００３９】
ＧＬＳ１１は、管理情報６１（図３，図４）として、ＤＨＴ情報、ＧＬＳノード情報、ＧＭＳノード情報などを持つ。上記ＤＨＴ情報は、前述の経路情報を含む、コンテンツＩＤ／ドメインと宛先／転送先ノードＩＤ（ＧＬＳノードＩＤ）との対応関係を示す情報である。上記ＧＬＳノード情報は、Ｎ１内の他のＧＬＳ１１ノードのＩＰアドレスなどの通信用の情報である。上記ＧＭＳノード情報は、当該ＧＬＳ１１の担当グループ（Ｎ２）内に接続されるメンバである各ＧＭＳ１２ノードのＩＰアドレスなどの通信用の情報、及びＧＭＳ１２に配置されるキャッシュ（５２）を示す管理情報である。ＧＭＳノード情報として特に、負荷情報、応答時間（ＲＴ）情報などを含む。負荷情報は、ＧＭＳ１１の負荷状態を示す情報であり、該当ＧＭＳ１２から通知される。応答時間（ＲＴ）情報は、ＧＭＳ１１とＷｅｂクライアント２０との応答時間（実績）を示す情報であり、Ｗｅｂクライアント２０側（Ｗｅｂクライアント情報７１）から提供される。
【００４０】
ＧＭＳ１２は、管理情報６２（図３，図４）として、グループノード情報、コンテンツ情報、負荷情報などを持つ。上記グループノード情報は、当該ＧＭＳ１２が含まれるグループ（Ｎ２）の上位のＧＬＳ１１ノードや他のＧＭＳ１２ノードとの通信用のＩＰアドレス情報などである。コンテンツ情報は、当該ＧＭＳ１２が保有するＷｅｂコンテンツ（５１）のキャッシュデータ（５２）のＩＤや他の管理情報などである。負荷情報は、当該ＧＭＳ１２の負荷状態を示す情報であり、ＧＬＳ１１へ通知される。
【００４１】
Ｗｅｂサーバ３０の持つ管理情報８０（図６）として、アクセス用情報、キャッシュ情報などを含む。アクセス用情報は、Ｗｅｂクライアント２０側と同様に、本ネットワークＮ０（ＧＬＳ１１）にアクセスするための情報である。キャッシュ情報は、自身が保有するＷｅｂコンテンツ（オリジナル）（５１）のＩＤや他の管理情報である。
【００４２】
［ネットワーク構築］
図３で、Ｎ０（Ｎ１，Ｎ２）のネットワーク構築の手続きや関連処理等について説明する。
【００４３】
（Ｎ１構築） ＧＬＳネットワークＮ１の構築では、ＧＬＳ１１毎の担当グループ（Ｎ２）となるドメイン（ＦＱＤＮ）を決める。所定の特性のハッシュ関数を用いて、ドメイン（ＦＱＤＮ）に対してＩＰアドレス（ノードのＩＰアドレス）を対応付ける。このドメイン（入力）とＩＰアドレス（出力）との対応関係は多対一である（１つのＧＬＳ１１は複数ドメインを１グループとして担当することができる）。
【００４４】
Ｎ０へのキャッシュ登録（配置）としては、例えば、第１のコンテンツ（５１）のＵＲＬが第１のドメイン（例：図２、ＦＱＤＮ＃１）に対応するとき、ＤＨＴで対応付けられる第１のＩＰアドレスのＧＬＳ１１（例：「ＧＬＳ１」）のグループ（Ｎ２）内のＧＭＳ１２に対応キャッシュ（５２）が保有され、また第２のＷｅｂコンテンツ（５２）のＵＲＬが第２のドメイン（例：ＦＱＤＮ＃２）に対応するとき、対応付けられる第２のＩＰアドレスのＧＬＳ１１（例：「ＧＬＳ２」）のグループ（Ｎ２）内のＧＭＳ１２に対応キャッシュ（５２）が保有される。ＧＬＳ１１は、管理情報６１（ＧＭＳノード情報）でキャッシュ配置を管理する。
【００４５】
Ｎ１の構築及び管理では、ネットワーク構築プロトコル（ＧＬＳ１１ノードの増減など）、情報共有プロトコル（ＧＬＳ１１ノード間のＤＨＴ情報の通信など）、耐障害プロトコル（グループ（Ｎ２）間のキャッシュ（５２）の負荷分散など）等については、例えば既存プロトコルを利用して実現する。
【００４６】
ＧＬＳ１１ノードには、最初（設置時）、ネットワーク管理者などにより、初期の管理情報６１が設定される（あるいは隣ノードからのＤＨＴ情報をコピーする等）。また、運用時、ＧＬＳ１１ノード間では、随時、Ｐ２Ｐのリンク１５を介して、管理情報６１の内容（ＤＨＴ情報など）が交換される。各ＧＬＳ１１ノードで最適な内容の状態になるように管理情報６１が動的に更新される。新規のＧＬＳ１１ノードが追加された場合、Ｎ１内の他のＧＬＳ１１ノードと通信して情報を取得することにより、新規のＧＬＳ１１ノードの管理情報６１が構成される。
【００４７】
（Ｎ２構築） ＧＭＳネットワークＮ２の構築では、ＧＬＳ１１をルート（最上位）のノードとして、その下位に、ＧＭＳ１２による管理上のツリー構造のＰ２Ｐネットワークを構築する。各ＧＭＳ１２ノードは負荷などに応じて自由に増減される。各ＧＭＳ１２ノードは、自身の管理情報６２を管理する。
【００４８】
なおツリー構造に応じて、ＧＭＳ１２をグループ（Ｎ２）内のサブリーダとして設定することもできる。例えば、図３の「ＧＭＳ２」をサブリーダとし、その下位の「ＧＭＳ３」「ＧＭＳ４」を含むサブグループを構成し、サブリーダは、サブグループ内のＧＭＳ１２ノードの情報を管理する。
【００４９】
Ｎ２の構築及び管理では、ネットワーク構築プロトコル（ＧＭＳ１２ノードの増減など）、情報共有プロトコル（ＧＭＳ１２ノード間での情報通知など）、耐障害プロトコル（ＧＭＳ１２ノード間でのキャッシュ（５２）の負荷分散など）等については、例えば既存プロトコルを利用して実現する。
【００５０】
運用時、各ＧＭＳ１２は、自身の管理情報６２で管理する自身の負荷状態を示す負荷情報を、自グループ（Ｎ２）の上位のＧＬＳ１１ノードへ通知する（図３、Ｂ１）。ＧＬＳ１１は、通知（Ｂ１）を受けると、管理情報６１の該当ＧＭＳ１２の負荷状態を記憶、更新する。なお逆に、ＧＬＳ１１が下位の各ＧＭＳ１２から負荷情報を収集する形などとしてもよい。負荷情報の通知（Ｂ１）の処理例としては、各ＧＭＳ１２は、自身の負荷（例えば計測値）が一定以上（例えば閾値以上）である場合（時）、その負荷状態（負荷大）を示す情報をＧＬＳ１１へ通知する。また、ＧＭＳ１２は、自身の負荷（例えば計測値）が一定以下（例えば閾値以下）である場合（時）、その負荷状態（負荷小）を示す情報をＧＬＳ１１へ通知する。
【００５１】
ＧＭＳ１２の負荷状態（負荷情報）として、少なくとも２値（負荷大／負荷小）を有するが、複数レベル値としてもよいし、負荷の計測値としてもよい。また上記に限らず他の各種の手段（例えば既存のサーバ監視システムの機能）を用いて、ＧＭＳ１２の負荷状態を検出し把握してもよい。
【００５２】
［クライアントアクセス手順（その１）］
図４で、Ｗｅｂコンテンツキャッシュデータ（５２）要求時のＷｅｂクライアント２０からのアクセス手順（基本）を示す。概略、ステップＳ１〜Ｓ３の順の処理が行われる。
【００５３】
（Ｓ１） まず、Ｗｅｂブラウザ２１（プラグイン２２）から、Ｎ１のＧＬＳ１１ノードにアクセスし、対象コンテンツ取得の要求を送信する。Ｎ１のＤＨＴ機能により、Ｗｅｂクライアント２０から該当ＧＬＳ１１ノード（対象キャッシュ（５２）を保有している該当ＧＭＳ１２を含むグループ（Ｎ２）の上位ノード）へ直接的にアクセス可能である。
【００５４】
（Ｓ２） 上記Ｓ１の要求を受けた該当ＧＬＳ１１ノードは、当該要求を、自身の担当グループ（Ｎ２）内の１つの該当ＧＭＳ１２ノード（対象キャッシュ（５２）を保有するノード）へ転送して処理（応答）を担当させる。そのために、ＧＬＳ１１は、自身の管理情報６１（各ＧＭＳ１２ノードの負荷情報を含む）を参照し、対象キャッシュ（５２）を保有する複数のＧＭＳ１２ノードのうち、なるべく負荷の小さい状態のＧＭＳ１２ノードを応答ノードとして選択する。ＧＬＳ１１は、Ｓ１の要求を自ノードから当該選択した応答ノード（対応するＩＰアドレス）へリダイレクトさせる。
【００５５】
なお通常、負荷分散の観点から、グループ（Ｎ２）内の複数のＧＭＳ１２ノードに同じキャッシュ（５２）を保有させるが、１つしかキャッシュ保有ノードが無い場合は当該ＧＭＳ１２が応答ノードとして決定される。また、上記選択した応答ノード（ＧＭＳ１２）での応答実行ができない場合は、ＧＬＳ１１を介して別のＧＭＳ１２ノード（例えば次に負荷が小さいノード）へ切り換えることができ、同様にリダイレクトすればよい。
【００５６】
上記ＧＭＳ１２の負荷に応じて選択する場合の判定例としては、ＧＬＳ１１は、通知（Ｂ１）で負荷が一定以上の状態（負荷大）のＧＭＳ１２については、以降、当該ＧＭＳ１２をリダイレクト先として指定しないようにする（優先順位を下げる等）。また、ＧＬＳ１１は、通知（Ｂ１）で負荷が一定以下の状態（負荷小）のＧＭＳ１２については、以降、当該ＧＭＳ１２をリダイレクト先として指定する候補にするようにする（優先順位を上げる等）。
【００５７】
（Ｓ３） 上記Ｓ２を受け、Ｗｅｂブラウザ２１（プラグイン２２）は、Ｎ２の上記リダイレクト先（応答ノード）のＧＭＳ１２（ＩＰアドレス）へアクセスし、当該ノードで保有している該当キャッシュデータ（５２）を取得する。即ち、当該ＧＭＳ１２からＷｅｂクライアント２０へ当該キャッシュ（コピー）を応答送信する。プラグイン２２は、対象データを正常に受信すると、自身の管理情報７０（ＧＭＳノード情報）に、今回の当該ＧＭＳ１２との応答で要した実績の応答時間（ＲＴ）の情報を記録する。
【００５８】
図４の例では、対象コンテンツキャッシュデータ（５２）を保有する該当ノードが「ＧＬＳ１」のグループ（Ｎ２）内の「ＧＭＳ１」「ＧＭＳ２」等である。Ｓ２の際、「ＧＬＳ１」は、その時の負荷が一番小さい例えば「ＧＭＳ１」を選択している。そして、「ＧＭＳ１」からのデータの応答の結果、Ｗｅｂクライアント２０は、「ＧＭＳ１」からのデータの応答で要した時間の大きさを示す情報を記録する。
【００５９】
なおＳ１，Ｓ２の際、プラグイン２２では、例えば、対象コンテンツＩＤ（ＵＲＬ等）を要求に添えてＧＬＳ１１側へ与える。ＧＬＳ１１側は、Ｗｅｂクライアント２０から与えられた情報に対し、管理情報６１（ＤＨＴ情報）の参照により、対象コンテンツに関係付けられる該当ＧＬＳ１１ノード（ＩＰアドレス）を高速に検索できる。
【００６０】
［クライアントアクセス手順（その２）］
続いて、図５で、Ｗｅｂコンテンツキャッシュデータ（５２）要求時のＷｅｂクライアント２０からのアクセス手順（詳細）について示す。ステップＡ１〜Ａ４等を有する。
【００６１】
前記Ｓ２でＧＬＳ１１が管理情報６１に基づきリダイレクト先（応答ノード）のＧＭＳ１２を選択する判定処理の際に、各ＧＭＳ１２の負荷状態と併せて、応答時間（ＲＴ）情報を考慮して決定する。
【００６２】
（Ａ１） Ｗｅｂクライアント２０（プラグイン２２）は、管理情報７０の一部として、Ｎ０（Ｎ１）への初期アクセス用の１つ以上のＧＬＳ１１ノードのＩＰアドレス等の情報（初期ノード情報）を有する。この初期ＧＬＳ１１ノードは任意でよい。Ｗｅｂクライアント２０は、初回、初期ノード情報を用いて、Ｎ１の初期ＧＬＳ１１ノードへアクセスする。図５の例では初期ノードが「ＧＬＳ０」である。例えば、プラグイン２２には予め上記初期ノード情報が設定（登録）されている。
【００６３】
上記初回アクセスした際、初期ＧＬＳ１１ノードから、その管理情報６１（ＤＨＴ情報）により、ＧＬＳネットワークＮ１の情報が得られる。即ち、対象キャッシュを保有する該当ＧＭＳ１２ノードを含むグループ（Ｎ２）の上位ノードである該当ＧＬＳ１１ノードの情報、あるいは該当ＧＬＳ１１ノードを含む複数または全てのＧＬＳ１１ノードの情報が得られる。Ｗｅｂクライアント２０は、得られた情報を用いて、該当ＧＬＳ１１ノード（ＩＰアドレス）へアクセス（要求を送信）する。本例では該当ＧＬＳ１１ノードが「ＧＬＳ１」である。
【００６４】
（Ａ２） Ｗｅｂクライアント２０は、２回目以降のＮ１へのアクセスでは、上記Ａ１の初回アクセス時に得た情報を用いて、該当ＧＬＳ１１ノードへ直接的にアクセス可能となる（図４のＳ１に対応）。
【００６５】
なおＷｅｂクライアント２０からのＮ０へのアクセス時に前回に対してＧＬＳネットワークＮ１の構造が変化していた場合は、Ａ１の初回アクセス時と同様の手順を踏む。なお基本的にはＧＬＳ１１を介してＧＭＳ１２（応答ノード）へアクセスする方式とし、Ｗｅｂクライアント２０から直接的に該当ＧＭＳ１２へアクセスする方式とはしない（その都度の適切な応答ノードを決定するため）。
【００６６】
前記図４のＳ１，Ｓ２に関し、該当ＧＬＳ１１ノードからグループ（Ｎ２）内の該当ＧＭＳ１２（応答ノード）を選択しリダイレクトさせる手順の詳細処理例は以下である。
【００６７】
（Ａ３） プラグイン２２は、前述のように、今まで（過去）にキャッシュ（５２）の取得でアクセスしたＧＭＳ１２ノードの情報、特に応答時間（ＲＴ）情報を、自身の管理情報７０として保有している。プラグイン２２は、該当ＧＬＳ１１へアクセスする際（Ａ２）に、要求情報と共に、上記応答時間（ＲＴ）を含む自身の情報（Ｗｅｂクライアント情報７１）を併せて送信・提供する。あるいは、その際、該当ＧＬＳ１１側からプラグイン２２側へ応答時間（ＲＴ）を含むＷｅｂクライアント情報７１を要求して取得してもよい。該当ＧＬＳ１１は、取得したＷｅｂクライアント情報７１の内容を管理情報６１に記録する。例えば、ＷｅｂクライアントＩＤと、当該応答時間（ＲＴ）が長かったＧＭＳ１２のノードＩＤとの対応関係の情報を記録する（後述、図７）。
【００６８】
また上記Ｗｅｂクライアント情報７１のやりとりに関しては、上記とは別の所定のタイミングで、ＧＬＳ１１がプラグイン２２からＷｅｂクライアント情報７１を収集・取得してもよい。また、要求（Ａ２）の都度に送受信せずに、応答時間（ＲＴ）の変化が大きい場合のみ送受信したり、既にＧＬＳ１１で取得済みのＷｅｂクライアント情報７１を繰り返し参照してもよい。
【００６９】
応答時間（ＲＴ）情報としては、例えば、リダイレクト後にＷｅｂクライアント２０（プラグイン２２）から該当ＧＭＳ１２へ要求を送信してから応答のキャッシュデータを受信するまでに要したターンアラウンドタイム［秒］などの形で計測した値としてもよい。あるいは、その計測値をもとに複数のレベルに区分した値などの形にしてもよい（例：短い／普通／長い：３レベル）。また勿論、応答時間に限らず、対応する応答速度などへ変換した値でもよい。あるいは、プラグイン２２での判断で、応答時間が所定の閾値以上で長かった場合や、所定の閾値以下で短かった場合に、対応するＧＭＳノードＩＤを記録またはＧＬＳ１１へ提供するようにしてもよいし、同様にＧＬＳ１１側で判断してもよい。
【００７０】
図５の例では、あるＷｅｂクライアント２０「ＣＬ１」について、過去の直近で、「ＧＭＳ１」との応答時間（ＲＴ）が一番短く、「ＧＭＳ２」のＲＴが一番長かったとする。そして、Ａ３で提供するＲＴ情報として、ＲＴ値が閾値以下、あるいは一番短かった条件に該当するＧＭＳ１２のノードＩＤ「ＧＭＳ１」を送信している。
【００７１】
（Ａ４） 該当ＧＬＳ１１ノードは、Ａ２（Ｓ１）の要求を受けた際、管理情報６１の参照に基づき、前述のように各ＧＭＳ１２ノードの負荷状態を考慮すると共に、各ＧＭＳ１２の応答時間（ＲＴ）情報を併せて考慮し、応答ノードとするＧＭＳ１２を選択する。例えば、グループ（Ｎ２）から、まず負荷が小さいあるいは問題無いノードを基本的な候補として抽出し、その複数のＧＭＳ１２ノードのうち、該当Ｗｅｂクライアント２０との応答時間（ＲＴ）が短かったノードを優先的に選択する。選択された応答ノード（ＩＰアドレス）がリダイレクト先として指定される。本例では、Ａ３の情報により、「ＣＬ１」−「ＧＭＳ１」間でＲＴが短かったため、「ＧＭＳ１」が応答ノードとして選択される。
【００７２】
別の処理例では、該当Ｗｅｂクライアント２０との応答時間（ＲＴ）が長かったＧＭＳ１２ノードを応答ノード選択の候補から外す（優先順位を下げる等）ようにしてもよい。
【００７３】
なお上記応答ノード選択の処理例では、同じＩＤのＷｅｂクライアント２０（例：「ＣＬ１」）に関して判定しているが、他の異なるＩＤのＷｅｂクライアント２０（例：「ＣＬ２」）に関しても、それらのクライアント（ＣＬ１，ＣＬ２）の位置等が類似であれば、応答時間（ＲＴ）も類似になると推測できるため、それら異なるＩＤのＷｅｂクライアント２０（複数）に関しても同様に判定してもよい。
【００７４】
またＷｅｂクライアント２０でプラグイン２２が管理情報７０を保持する方式に関して、例えば過去の複数回の応答時間（ＲＴ）の情報を履歴として保存する。例えば、Ｗｅｂクライアント２０が持つ所定のメモリ量の範囲内で保持する形とし、過去の古い情報から順に消去する。また、ＲＴ値の短い順／長い順にランキングのようにレコードを保持する形としてもよい。
【００７５】
［コンテンツキャッシュ更新］
図６で、Ｗｅｂサーバ３０側によるＷｅｂコンテンツキャッシュデータの更新の機能に関して説明する。Ｗｅｂサーバ３０に備えるクライアント機能３２により、Ｗｅｂサーバ３１のコンテンツ（オリジナル）５１のデータをネットワークＮ０へキャッシュ登録し、またその後、Ｎ０側へプッシュすることにより、Ｎ２（ＧＭＳ１２）のコンテンツ（キャッシュ）５２のデータを更新させる処理を行う。ステップＣ１，Ｃ２を有する。
【００７６】
例えば、Ｗｅｂサーバ３０（３１）は、コンテンツ（オリジナル）５１として、第１のコンテンツＣａ，第２のコンテンツＣｂを持つとする。キャッシュ登録時、第１のコンテンツＣａは、ＤＨＴにより、ある第１のＧＬＳ１１（例：「ＧＬＳ１」）のグループ（Ｎ２）内のＧＭＳ１２（例：「ＧＭＳ１」〜「ＧＭＳ３」）へ格納され、第２のコンテンツＣｂは、ＤＨＴにより、ある第２のＧＬＳ１１（例：「ＧＬＳ２」）のグループ（Ｎ２）のＧＭＳ１２（例：「ＧＭＳ４」）へ格納されるとする。
【００７７】
（Ｃ１） ステップＣ１で、Ｗｅｂサーバ３０（３１）でのコンテンツ（５１）の更新に伴いキャッシュ（５２）の更新を実行したい時、クライアント機能３２から、Ｎ１（該当ＧＬＳ１１）へアクセスする。この際のアクセス手順は、前述のＷｅｂクライアント２０側のアクセス手順と同様にＤＨＴの仕組み等を用いてなされる。本例では、クライアント機能３２から、コンテンツＣａのデータ（コピー）が「ＧＬＳ１」へプッシュ（送信）され、コンテンツＣｂのデータ（コピー）が「ＧＬＳ２」へプッシュ（送信）される。
【００７８】
（Ｃ２） ステップＣ２で、上記プッシュを受けた該当ＧＬＳ１１ノード（ＧＬＳ１，ＧＬＳ２）は、自身のグループ（Ｎ２）内の該当ＧＭＳ１２ノード（旧版のキャッシュを保有しているノード）へ、更新版のコンテンツデータを送信する。この際、Ｎ２のツリー構造に従い、上位のＧＬＳ１１から下位の各ＧＭＳ１２へ当該データを順次伝播させ、該当の各ＧＭＳ１２内のキャッシュ（５２）を更新させる。例えば「ＧＬＳ１」のグループ内の各ＧＭＳ１２（「ＧＭＳ１」〜「ＧＭＳ３」）で保有するキャッシュＣａ’がすべて更新される。
【００７９】
Ｗｅｂサーバ３０側のクライアント機能３２により、ネットワークＮ０内のキャッシュデータ（５２）の鮮度を高めることができ、即ちユーザ端末２０への応答性能・応答品質を高めることができる。
【００８０】
［判定処理例］
図７で、ＧＬＳ１１により応答ノード（ＧＭＳ１２）を選択する際の判定処理例について示す。判定の際に考慮する要素として、前述のように、負荷と応答時間（ＲＴ）があり、本実施の形態では両方を考慮して選択する。一方のみ考慮して選択する形態も可能である。
【００８１】
図７の例では、「ＧＬＳ１」のグループ（Ｎ２）の「ＧＭＳ１」「ＧＭＳ２」があり、それぞれ同じコンテンツ（キャッシュ）Ｃｘ’を保有しているとする。例えば、過去の直近のキャッシュ応答における応答時間（ＲＴ）として、ここでは簡単に短い／普通／長いの３レベル値としたとき、「ＧＭＳ１」はＲＴが短く、「ＧＭＳ２」はＲＴが長かったとする。このＲＴ情報はそれぞれプラグイン２２の管理情報７０にＧＭＳノードＩＤとの対応関係で記載される。このＲＴ情報を含むＷｅｂクライアント情報７１がＧＬＳ１１へ提供され、ＧＬＳ１１の管理情報６１に対応情報が記載される。
【００８２】
一方、ＧＬＳ１１は、随時、各ＧＭＳ１２からの負荷情報の通知（Ｂ１）を受けて、管理情報６１にＧＭＳ１２の負荷状態（現在の負荷状態）を記載している。例えば負荷をここでは簡単に小／中／大の３レベル値としたとき、「ＧＭＳ１」は現在の負荷が大、「ＧＭＳ２」は現在の負荷が小、とする。
【００８３】
前記Ｓ２（Ａ４）で、ＧＬＳ１１が応答ノードを選択するための判定処理において、管理情報６１を参照し、図７の例の状態では、応答ノードの候補となる「ＧＭＳ１」「ＧＭＳ２」に関して、現在の負荷の観点では、「ＧＭＳ２」の方が小さく、過去の応答時間（ＲＴ）の観点では、「ＧＭＳ１」の方が短い。ここで、負荷と応答時間の両方を考慮して判定する方式において、負荷の小ささを優先して選択する方式とする場合は、「ＧＭＳ２」を応答ノードとして選択し、応答時間の短さを優先して選択する方式とする場合は、「ＧＭＳ１」を応答ノードとして選択する。実施の形態１では、応答時間（ＲＴ）の短さを優先して選択する方式とし、本例では「ＧＭＳ１」が応答ノードとして選択される。
【００８４】
なお上記方式（優先する観点）を選択して設定可能としたり、上記方式を状況に応じて使い分けるように制御する形態としてもよい。また例えば、両方の要素（負荷、応答時間）の値を用いて所定の計算式で求めた値をもとに応答ノードを選択する方式としてもよい。例えば要素（優先する観点）に応じて重み付けの係数を設定し、候補のＧＭＳ１２ノード毎に、［負荷の係数］×［現在の負荷値］＋［応答時間の係数］×［過去の応答時間値］、といった計算式で値を求め、当該値に応じてノードを選択する。
【００８５】
また、利用する応答時間（ＲＴ）の情報としては、過去の直近のアクセス時の情報に限らず、過去の複数回のアクセスにおける平均などの統計値を利用してもよいし、ベストやワーストのランキング値を利用してもよい。
【００８６】
［機能］
図８を用いて、実施の形態１のシステムのハードウェア・ソフトウェア実装構成や機能構成についてまとめると以下である。ユーザ端末２０は、プロセッサ、メモリ（ＲＯＭ，ＲＡＭ，ディスク等）、入力装置、出力装置、通信インタフェース装置、及びバスなどを備え、これらを用いたソフトウェアプログラム処理（制御部２０１）により、Ｗｅｂブラウザ２１、及びプラグイン２２を実現する。プラグイン２２により、メモリ（記憶部２０２）に、Ｗｅｂクライアント情報７１を含む管理情報７０を記憶する。
【００８７】
プラグイン２２は、アクセス機能２２Ａ、Ｗｅｂクライアント情報管理機能２２Ｂなどの処理部を有する。アクセス機能２２Ａは、前述のアクセス用情報を用いて、対象コンテンツ（５２）を取得（要求）するためにネットワークＮ０（ＧＬＳ１１，ＧＭＳ１２）へアクセスする機能である。Ｗｅｂクライアント情報管理機能２２Ｂは、例えば、ＧＭＳ１２とのキャッシュデータの応答での応答時間（ＲＴ）を計測し、所定の形式の応答時間情報７２を作成し、Ｗｅｂクライアント情報７１（管理情報７０）の中に格納する処理や、ＧＬＳ１１へＷｅｂクライアント情報７１を送信・提供する処理などを行う。
【００８８】
Ｗｅｂサーバ３０は、プロセッサ、メモリ、入力装置、出力装置、通信インタフェース装置、及びバスなどを備え、これらを用いたソフトウェアプログラム処理（制御部３０１）により、Ｗｅｂサーバ３１やクライアント機能３２を実現する。Ｗｅｂサーバ３１及びクライアント機能３２は、メモリ（記憶部３０２）に、Ｗｅｂコンテンツのオリジナルデータ（５１）、及び管理情報８０などを記憶する。
【００８９】
クライアント機能３２は、アクセス機能３２Ａ、プッシュ機能３２Ｂなどの処理部を備える。アクセス機能３２Ａは、Ｗｅｂクライアント２０側の機能（２２Ａ）と同様にＮ０（ＧＬＳ１１）へアクセスするための機能である。プッシュ機能３２Ｂは、前述（図６）のプッシュによるキャッシュ更新などの処理を行う。
【００９０】
Ｗｅｂプロキシサーバ１０は、ＧＬＳ１１（第１種のＷｅｂプロキシサーバ）、ＧＭＳ１２（第２種のＷｅｂプロキシサーバ）を有し、それぞれ、プロセッサ、メモリ、入力装置、出力装置、通信インタフェース装置、及びバスなどを備え、これらを用いたソフトウェアプログラム処理（制御部１１１，１２１）により、対応する種別に応じたＧＬＳ機能やＧＭＳ機能を実現する。ＧＬＳ機能は、メモリ（記憶部１１２）に、前述の管理情報６１（ＤＨＴ，ＧＬＳ，ＧＭＳなどの情報）を記憶する。ＧＭＳ機能は、メモリ（記憶部１２２）に、前述の管理情報６２（グループ、コンテンツ、負荷などの情報）、及びキャッシュデータ（５２）を記憶する。
【００９１】
ＧＬＳ機能は、ＤＨＴ機能１１Ａ、グループ管理機能１１Ｂ、応答ノード選択機能１１Ｃなどを有する。ＤＨＴ機能１１Ａは、前述のＤＨＴによるキャッシュ（５２）の登録、検索などの処理、及び管理情報６１のＤＨＴ情報の管理処理を行う。グループ管理機能１１Ｂは、担当グループ（Ｎ２）の各ＧＭＳ１２ノードの情報などを管理情報６１として管理する処理を行う。応答ノード選択機能１１Ｃは、前述のＷｅｂクライアント情報７１（管理情報６１）に基づき応答ノードを選択する判定などの処理を行う。
【００９２】
ＧＭＳ機能は、キャッシュ管理機能１２Ａ、負荷管理機能１２Ｂ、グループ通信機能１２Ｃなどを有する。キャッシュ管理機能１２Ａは、自ノードのキャッシュデータ（５２）をメモリに保有し情報を管理する処理などを行う。負荷管理機能１２Ｂは、自ノードの負荷状態を計測し負荷情報として管理情報６２に格納する処理などを行う。グループ通信機能は、負荷情報の通知などのために自グループの上位のＧＬＳ１１や他のＧＭＳ１２と通信する処理などを行う。
【００９３】
［効果等］
以上のように、実施の形態１によれば、ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）及びＤＨＴ等の構成で、Ｗｅｂコンテンツキャッシュデータ（５２）の負荷分散を図りつつ、Ｗｅｂクライアント情報７１（特に応答時間情報）を用いてその都度好適な応答ノードを選択する構成により、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）２０からみた応答性能などを向上できる。特に、ネットワークの負荷分散などを図りつつ、ユーザ端末２０へのキャッシュデータ（５２）の応答時間を短くすることができる。
【００９４】
本システムで、実績の応答時間（ＲＴ）が長かったＧＭＳ１２ノードは、以降、応答ノードとして選択されにくくなるので、負荷は減る可能性があり、やがて応答性能が改善する可能性がある。改善した場合、当該ノードが応答ノードとして選択されやすくなる。また、応答時間（ＲＴ）が短かったノードは、以降、応答ノードとして選択されやすくなるので、負荷は増える可能性があり、やがて応答性能が落ちる可能性がある。落ちた場合、当該ノードが応答ノードとして選択されにくくなる。このように調整の作用が働くため、ネットワーク性能を向上または維持することができる。
【００９５】
＜実施の形態２＞
図９，図１０を用いて、本発明の実施の形態２のシステムについて説明する。実施の形態２では、実施の形態１を前提（図１〜図３等の基本構成を共通とする）として、更に、Ｗｅｂクライアント情報７１として、クライアント属性情報を利用し、クライアント属性情報に応じてキャッシュデータ応答に関するコンテンツフィルタリング（「ＣＦ」と略す）を行い、適切な（品質の高い）キャッシュデータを応答する構成を示す。
【００９６】
実施の形態２では、ネットワークＮ１のＧＬＳ１１ノードは、Ｗｅｂクライアント２０（プラグイン２２）から提供されるクライアント属性情報に応じて、コンテンツキャッシュデータ（５２）の取得（要求−応答）に係わる、応答ノード（実施の形態１と同様）を含む、ＣＦの内容（どのＧＭＳ１２ノードのどのコンテンツキャッシュデータ（５２）をブロック／非ブロックするか等）を決定する。そして、応答品質を高めるための好適な応答ノードとなるＧＭＳ１２ノードを選択し、選択されたＧＭＳ１２ノードからＣＦ後のキャッシュデータ（５２）を応答する。また特に、複数のＷｅｂクライアント２０及び複数のコンテンツ（５１）に関して、ネットワークＮ０側で上記クライアント属性情報を用いて協調フィルタリング処理を行うことにより、クライアント属性に応じたキャッシュデータ（５２）を提供する。
【００９７】
実施の形態２のシステムのＣＦ機能は、実施の形態１の機能（応答時間を考慮して応答ノードを選択する機能）とは独立した機能として説明する（実施の形態２では応答時間情報を用いない）。これに限らず、実施の形態１と実施の形態２の機能の両方を組み合わせた形態が可能である。例えば実施の形態１の機能を持つネットワークＮ０上に実施の形態２のＣＦ機能を持つ上位のネットワークをレイヤとして構成した形態などが可能である。
【００９８】
［コンテンツフィルタリング機能］
図９で、実施の形態２のＣＦ機能による処理例を示す。Ｎ１側のＧＬＳ１１は、ＣＦ機能を備える。Ｗｅｂクライアント２０からのコンテンツ取得要求に対し、ＧＬＳ１１のＣＦ機能により、Ｗｅｂクライアント２０からのＷｅｂクライアント情報７１（クライアント属性情報を含む）に応じて、ＧＭＳ１２のキャッシュ（５２）をフィルタリング（例えばブロック／非ブロック）して、該当ＧＭＳ１２ノードからＷｅｂクライアント２０へ応答する（ブロックの場合はキャッシュデータ送信無し）。
【００９９】
Ｗｅｂクライアント２０のプラグイン２２は、Ｗｅｂクライアント情報７１として、クライアント属性情報７３（あるいはユーザ設定によるＣＦ用設定情報）を管理・保持し、必要に応じてＧＬＳ１１側へ提供（送信）する。クライアント属性情報７３は、Ｗｅｂコンテンツ参照及びＣＦに係わる属性を示す情報である。具体例としては、ユーザ端末２０が教育用（学校など）のＰＣである場合、会社のＰＣである場合、一般家庭や個人のＰＣである場合、などが挙げられる。図９の例では、第１のＷｅｂクライアント２０である「ＣＬ１」のクライアント属性がＡであり、第２のＷｅｂクライアント２０である「ＣＬ２」のクライアント属性がＢとする。
【０１００】
また、Ｗｅｂサーバ３０により提供されるコンテンツ（５１，５２）に関するコンテンツ情報として、コンテンツ属性情報を有し、ＣＦに用いる。図９の例では、「ＧＭＳ１」が持つ第１のコンテンツ（キャッシュ）Ｃｘ’のコンテンツ属性をＸとし、「ＧＭＳ２」が持つ第２のコンテンツ（キャッシュ）Ｃｙ’のコンテンツ属性をＹとする。コンテンツ属性の具体例としては、教育用（学校など）のＷｅｂページ、会社のＷｅｂページ、一般家庭や個人の作成のＷｅｂページ、などが挙げられる。
【０１０１】
ＧＬＳ１１は、Ｗｅｂクライアント２０から提供されたＷｅｂクライアント情報７１（クライアント属性情報７３）に対応する情報を管理情報６１内に格納する。図９の例では、管理情報６１として前述のＤＨＴ情報（コンテンツとノード（ＧＬＳ１１）との対応関係の情報）やＧＭＳノード情報（キャッシュ配置など）などに加え、ＣＦ機能によるＣＦ管理情報９１を有する。ＣＦ管理情報９１において、ＣＦ状態（ＣＦ制御内容）を示す情報を含み、Ｗｅｂクライアント２０の属性と、コンテンツ（コンテンツ属性）と、ＧＭＳ１２（応答ノード）との対応関係における例えばブロック状態（ブロック対象）を管理する。
【０１０２】
ＧＬＳ１１は、コンテンツ取得要求に対し、ＣＦ管理情報９１を含む管理情報６１を参照し、前述の応答ノードとなるＧＭＳ１２、及びそのＣＦ対象のキャッシュデータ（５２）を決定する。実施の形態２では、ＣＦの内容として、簡単に、ブロック（提供しない）／非ブロック（元のまま提供する）の２通りがあるものとするが、これに限らず所定のＣＦ手法（データを加工して提供する等）を適用してもよい。
【０１０３】
図９の例では、あるグループ（Ｎ２）のＧＬＳ１１である「ＧＬＳ１」は、グループ内のＧＭＳ１２（「ＧＭＳ１」，「ＧＭＳ２」）の各キャッシュ（Ｃｘ’，Ｃｙ’）に関して、管理情報６１に基づきＣＦ（ブロック）を実行する。「ＣＬ１」（属性Ａ）は、「ＧＭＳ１」からはコンテンツＣｘ’（属性Ｘ）を非ブロックで取得できるが、「ＧＭＳ２」からはコンテンツＣｙ’（属性Ｙ）がＣＦによりブロックされ取得できない。また、「ＣＬ２」（属性Ｂ）は、「ＧＭＳ２」からはコンテンツＣｙ’（属性Ｙ）を非ブロックで取得できるが、「ＧＭＳ１」からはコンテンツＣｘ’（属性Ｘ）がＣＦによりブロックされ取得できない。
【０１０４】
ＧＬＳ１１のＣＦ機能は、クライアント属性とコンテンツ属性との関係を判断し、ＣＦ内容を決定する。例えば、ＣＦ機能は、複数のＷｅｂクライアント（クライアント属性）と複数のコンテンツ（コンテンツ属性）とを対象として、協調フィルタリング（公知技術）の処理を実行し、ＣＦ内容を決定する。例えば、ある属性Ａの「ＣＬ１」はある属性ＹのコンテンツＣｙ’がブロックされるというＣＦ状態情報を利用し、同じ属性Ａの別のＷｅｂクライアント２０である例えば「ＣＬ３」は同じ属性ＹのＣｙ’がブロックされるように制御される。即ち、類似のクライアント属性に対しては類似のコンテンツ属性をブロック／非ブロックするといったＣＦ内容になる。
【０１０５】
また、プラグイン２２により当該クライアント属性によるコンテンツ属性へのアクセス（対応関係）の情報を管理し、Ｗｅｂクライアント情報７１としてＧＬＳ１１へ提供し、ＧＬＳ１１で当該アクセス（対応関係）の情報を利用して同様に協調フィルタリングなどでＣＦ内容を決定するといった形態としてもよい。
【０１０６】
また、ＣＦ機能（クライアント属性情報に応じてコンテンツの応答をブロックする）をコンテンツ推薦機能（クライアント属性情報に応じて推薦するコンテンツを応答する）に替えてもよい。
【０１０７】
［機能］
図１０を用いて、実施の形態２のシステムのハードウェア・ソフトウェア実装構成や機能構成についてまとめると以下である。図８との違いとして、プラグイン２２によるＷｅｂクライアント情報７１を含む管理情報７０として、Ｗｅｂクライアント属性情報７３を含む。Ｗｅｂクライアント情報管理機能２２Ｂは、自身のＷｅｂクライアント属性情報７３をユーザ設定に基づき作成し、Ｗｅｂクライアント情報７１の中に格納する処理や、ＧＬＳ１１へ送信・提供する処理などを行う。またコンテンツ（５１，５２）に関する管理情報であるコンテンツ情報として、コンテンツ属性情報を含む。ＧＬＳ１１のＧＬＳ機能は、ＣＦ機能１１Ｄを含む。ＣＦ機能１１Ｄは、前述（図９）のＷｅｂクライアント情報７１（クライアント属性情報）に応じて応答ノードの応答キャッシュのフィルタリング処理を行う。ＧＬＳ機能の管理情報６１は、前述のＣＦ管理情報９１を含む。
【０１０８】
［効果等］
以上のように、実施の形態２によれば、ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）及びＤＨＴ等の構成で、Ｗｅｂコンテンツキャッシュデータ（５２）の負荷分散を図りつつ、Ｗｅｂクライアント情報７１（特にクライアント属性情報）を用いてコンテンツフィルタリングして好適なキャッシュデータを応答する構成により、従来よりも更に、ユーザ端末（Ｗｅｂクライアント）２０からみた応答品質などを向上できる。特に、ネットワークの負荷分散などを図りつつ、ユーザ端末２０へ応答するコンテンツデータの品質を高めることができる。
【０１０９】
＜変形例等＞
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。前述した以外の変形例として以下が挙げられる。
【０１１０】
実施の形態１のようにＷｅｂクライアント２０側からＮ０（ＧＬＳ１１）側へ応答時間（ＲＴ）情報を含むＷｅｂクライアント情報７１を提供するので、例えばＲＴが長かったＧＭＳ１２ノード、即ちその時の応答性能が良くなかったノードを情報として把握することができる。この情報を利用して、該当ＧＭＳ１２ノードやそれを含むグループ（Ｎ２）あるいはネットワークＮ０全体に対する対処処理（応答性能の改善を図るための処理）を実行するようにしてもよい。例えば、ＧＬＳ１１から該当ＧＭＳ１２ノードやその管理者へ情報を通知して応答性能の改善に役立てる。例えば、該当グループ（Ｎ２）を含めＤＨＴによるキャッシュ（５２）の配置を再考し、応答性能の改善を図る。
【産業上の利用可能性】
【０１１１】
本発明は、インターネット等に利用可能である。
【符号の説明】
【０１１２】
１０…Ｗｅｂプロキシサーバ、１１…第１種のＷｅｂプロキシサーバ（グループリーダサーバ）、１２…第２種のＷｅｂプロキシサーバ（グループメンバサーバ）、１５…リンク、２０…ユーザ端末（Ｗｅｂクライアント）、２１…Ｗｅｂブラウザ、２２…プラグイン、３０…Ｗｅｂサーバ、３１…Ｗｅｂサーバ、３２…（Ｗｅｂサーバ用）クライアント機能、５１…コンテンツ（オリジナル）、５２…コンテンツ（キャッシュ）、７１…Ｗｅｂクライアント情報、１００…ＷｅｂプロキシサーバＰ２Ｐネットワーク（Ｎ０）、Ｎ１…グループリーダサーバネットワーク、Ｎ２…グループメンバサーバネットワーク。
【特許請求の範囲】
【請求項１】
Ｗｅｂコンテンツを要求するＷｅｂブラウザを含むＷｅｂクライアント装置と、Ｗｅｂコンテンツを提供するＷｅｂサーバ装置と、Ｗｅｂクライアント装置とＷｅｂサーバ装置の間でＷｅｂコンテンツのキャッシュデータを保有し代理応答で提供するＷｅｂプロキシサーバ装置とがネットワークで接続され、
複数のＷｅｂプロキシサーバ装置がＰ２Ｐネットワークで接続され、
前記Ｐ２Ｐネットワークは、
第１種のＷｅｂプロキシサーバであるグループリーダのノード群のＰ２Ｐ接続による第１のネットワークと、
前記グループリーダに対して接続される、第２種のＷｅｂプロキシサーバであるグループメンバのノード群のＰ２Ｐ接続による第２のネットワークとで構成され、
前記第１種のＷｅｂプロキシサーバは、
分散ハッシュテーブル（ＤＨＴ）情報を用いて、前記Ｗｅｂコンテンツと、当該Ｗｅｂコンテンツのキャッシュデータを保有する前記第２種のＷｅｂプロキシサーバを含むグループの前記第１種のＷｅｂプロキシサーバとの対応関係を管理し、前記Ｗｅｂクライアント装置からのＷｅｂコンテンツの要求を受けると、前記ＤＨＴ情報を用いて、当該Ｗｅｂコンテンツのキャッシュデータを保有する該当の第２種のＷｅｂプロキシサーバを含むグループの該当の第１種のＷｅｂプロキシサーバを検索し、必要に応じて当該要求を転送する処理を行うＤＨＴ機能と、
自身が担当するグループに対応する前記第２のネットワークのグループメンバの各ノードの情報を管理し各ノードと通信する処理を行うグループ管理機能と、を有し、
前記第２種のＷｅｂプロキシサーバは、
前記Ｗｅｂコンテンツのキャッシュデータを保有し情報を管理する処理を行うキャッシュ管理機能と、
自身のグループ内で前記グループリーダのノードと情報を通信する処理を行うグループ通信機能とを有し、
前記Ｗｅｂクライアント装置は、
対象のＷｅｂコンテンツの情報を前記第１種のＷｅｂプロキシサーバへ送信し、前記第２種のＷｅｂプロキシサーバから応答のキャッシュデータを取得する処理を行うアクセス機能と、
自身で管理するＷｅｂクライアント情報を前記第１種のＷｅｂプロキシサーバに対して提供するＷｅｂクライアント情報管理機能とを有し、
前記Ｗｅｂクライアント情報は、前記Ｗｅｂクライアント装置と前記Ｗｅｂプロキシサーバ装置との間で過去に前記Ｗｅｂコンテンツのキャッシュデータを取得した時の応答時間の情報を含み、
前記該当の第１種のＷｅｂプロキシサーバは、該当の第２種のＷｅｂプロキシサーバの中から、前記要求に対し応答させるノードを決定するために、前記Ｗｅｂクライアント情報を参照し、前記応答時間が短いノードを優先的に選択し、決定したノードへリダイレクトさせる処理を行う応答ノード選択機能を有し、
前記Ｗｅｂクライアント装置は、前記アクセス機能により、前記リダイレクト先の第２種のＷｅｂプロキシサーバから前記キャッシュデータを取得し、前記Ｗｅｂクライアント情報管理機能により、その時の応答時間の情報を記録する処理を行うこと、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項２】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記第２種のＷｅｂプロキシサーバは、自身の負荷の状態を含む情報を管理する処理を行う負荷管理機能を有し、前記グループ通信機能により、自身の負荷の状態を含む情報を自身のグループ内の前記グループリーダのノードへ通知する処理を行い、
前記第１種のＷｅｂプロキシサーバのグループ管理機能は、前記通知をもとに、各グループメンバのノードの負荷状態を管理し、
前記該当の第１種のＷｅｂプロキシサーバは、前記応答ノード選択機能により、該当の第２種のＷｅｂプロキシサーバの中から、当該要求に対し応答させるノードを決定するために、前記各グループメンバのノードの負荷状態を参照し、負荷が小さいノードを優先的に選択する、あるいは負荷が大きいノードをなるべく選択しないようにする処理を行うこと、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項３】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント装置から、前記第１種のＷｅｂプロキシサーバに対し、前記Ｗｅｂコンテンツの要求の際に、併せて、前記応答時間の情報を含むＷｅｂクライアント情報を送信し、
前記第１種のＷｅｂプロキシサーバは、受信したＷｅｂクライアント情報に基づき、自身のグループのグループメンバのノード毎の前記応答時間の情報を管理すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項４】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記応答時間の情報は、前記Ｗｅｂクライアント装置が前記リダイレクト先の第２種のＷｅｂプロキシサーバから対象のＷｅｂコンテンツのキャッシュデータを受信するまでの時間を計測した値であること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項５】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記応答時間の情報は、前記Ｗｅｂクライアント装置が前記リダイレクト先の第２種のＷｅｂプロキシサーバから対象のＷｅｂコンテンツのキャッシュデータを受信するまでの時間の大きさを示すレベル値であること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項６】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント装置から前記第１種のＷｅｂプロキシサーバへ提供される前記Ｗｅｂクライアント情報は、前記応答時間が短かった第２種のＷｅｂプロキシサーバのノードの識別情報を含み、
前記第１種のＷｅｂプロキシサーバの応答ノード選択機能は、前記提供された識別情報に基づき、前記応答時間が短かった第２種のＷｅｂプロキシサーバのノードを優先的に選択すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項７】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント装置から前記第１種のＷｅｂプロキシサーバへ提供される前記Ｗｅｂクライアント情報は、前記応答時間が長かった第２種のＷｅｂプロキシサーバのノードの識別情報を含み、
前記第１種のＷｅｂプロキシサーバの応答ノード選択機能は、前記提供された識別情報に基づき、前記応答時間が長かった第２種のＷｅｂプロキシサーバのノードをなるべく選択しないようにすること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項８】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記該当の第１種のＷｅｂプロキシサーバは、前記応答ノード選択機能により、前記要求に対し応答させるノードを決定する際、前記各グループメンバのノードの負荷と応答時間の大きさの両方を考慮し、第１に、応答時間の短いノードを優先的に選択し、第２に、負荷の小さいノードを優先的に選択すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項９】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記該当の第１種のＷｅｂプロキシサーバは、前記応答ノード選択機能により、前記要求に対し応答させるノードを決定する際、前記各グループメンバのノードの負荷と応答時間の大きさの両方を考慮し、第１に、負荷の小さいノードを優先的に選択し、第２に、応答時間の短いノードを優先的に選択すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項１０】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂサーバ装置は、前記Ｗｅｂプロキシサーバ装置のＰ２Ｐネットワークに配置される前記Ｗｅｂコンテンツのキャッシュデータを最新の状態に更新させるためのプッシュ機能を含むクライアント機能を備えること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項１１】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント情報は、前記Ｗｅｂクライアント装置の属性情報を含み、
前記第１種のＷｅｂプロキシサーバは、前記第２種のＷｅｂプロキシサーバから前記Ｗｅｂクライアント装置へ応答する前記Ｗｅｂコンテンツのキャッシュデータをコンテンツフィルタリングする制御を行うコンテンツフィルタリング機能を有し、当該コンテンツフィルタリングの管理情報を保有し、
前記該当の第１種のＷｅｂプロキシサーバは、前記要求に対し応答させるノードから前記キャッシュデータを応答させる際、前記コンテンツフィルタリング機能により、前記Ｗｅｂクライアント情報を参照し、当該Ｗｅｂクライアントの属性に応じて、当該キャッシュデータをブロックするかどうかを含むコンテンツフィルタリング内容を決定し、当該内容で応答を制御する処理を行うこと、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項１】
Ｗｅｂコンテンツを要求するＷｅｂブラウザを含むＷｅｂクライアント装置と、Ｗｅｂコンテンツを提供するＷｅｂサーバ装置と、Ｗｅｂクライアント装置とＷｅｂサーバ装置の間でＷｅｂコンテンツのキャッシュデータを保有し代理応答で提供するＷｅｂプロキシサーバ装置とがネットワークで接続され、
複数のＷｅｂプロキシサーバ装置がＰ２Ｐネットワークで接続され、
前記Ｐ２Ｐネットワークは、
第１種のＷｅｂプロキシサーバであるグループリーダのノード群のＰ２Ｐ接続による第１のネットワークと、
前記グループリーダに対して接続される、第２種のＷｅｂプロキシサーバであるグループメンバのノード群のＰ２Ｐ接続による第２のネットワークとで構成され、
前記第１種のＷｅｂプロキシサーバは、
分散ハッシュテーブル（ＤＨＴ）情報を用いて、前記Ｗｅｂコンテンツと、当該Ｗｅｂコンテンツのキャッシュデータを保有する前記第２種のＷｅｂプロキシサーバを含むグループの前記第１種のＷｅｂプロキシサーバとの対応関係を管理し、前記Ｗｅｂクライアント装置からのＷｅｂコンテンツの要求を受けると、前記ＤＨＴ情報を用いて、当該Ｗｅｂコンテンツのキャッシュデータを保有する該当の第２種のＷｅｂプロキシサーバを含むグループの該当の第１種のＷｅｂプロキシサーバを検索し、必要に応じて当該要求を転送する処理を行うＤＨＴ機能と、
自身が担当するグループに対応する前記第２のネットワークのグループメンバの各ノードの情報を管理し各ノードと通信する処理を行うグループ管理機能と、を有し、
前記第２種のＷｅｂプロキシサーバは、
前記Ｗｅｂコンテンツのキャッシュデータを保有し情報を管理する処理を行うキャッシュ管理機能と、
自身のグループ内で前記グループリーダのノードと情報を通信する処理を行うグループ通信機能とを有し、
前記Ｗｅｂクライアント装置は、
対象のＷｅｂコンテンツの情報を前記第１種のＷｅｂプロキシサーバへ送信し、前記第２種のＷｅｂプロキシサーバから応答のキャッシュデータを取得する処理を行うアクセス機能と、
自身で管理するＷｅｂクライアント情報を前記第１種のＷｅｂプロキシサーバに対して提供するＷｅｂクライアント情報管理機能とを有し、
前記Ｗｅｂクライアント情報は、前記Ｗｅｂクライアント装置と前記Ｗｅｂプロキシサーバ装置との間で過去に前記Ｗｅｂコンテンツのキャッシュデータを取得した時の応答時間の情報を含み、
前記該当の第１種のＷｅｂプロキシサーバは、該当の第２種のＷｅｂプロキシサーバの中から、前記要求に対し応答させるノードを決定するために、前記Ｗｅｂクライアント情報を参照し、前記応答時間が短いノードを優先的に選択し、決定したノードへリダイレクトさせる処理を行う応答ノード選択機能を有し、
前記Ｗｅｂクライアント装置は、前記アクセス機能により、前記リダイレクト先の第２種のＷｅｂプロキシサーバから前記キャッシュデータを取得し、前記Ｗｅｂクライアント情報管理機能により、その時の応答時間の情報を記録する処理を行うこと、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項２】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記第２種のＷｅｂプロキシサーバは、自身の負荷の状態を含む情報を管理する処理を行う負荷管理機能を有し、前記グループ通信機能により、自身の負荷の状態を含む情報を自身のグループ内の前記グループリーダのノードへ通知する処理を行い、
前記第１種のＷｅｂプロキシサーバのグループ管理機能は、前記通知をもとに、各グループメンバのノードの負荷状態を管理し、
前記該当の第１種のＷｅｂプロキシサーバは、前記応答ノード選択機能により、該当の第２種のＷｅｂプロキシサーバの中から、当該要求に対し応答させるノードを決定するために、前記各グループメンバのノードの負荷状態を参照し、負荷が小さいノードを優先的に選択する、あるいは負荷が大きいノードをなるべく選択しないようにする処理を行うこと、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項３】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント装置から、前記第１種のＷｅｂプロキシサーバに対し、前記Ｗｅｂコンテンツの要求の際に、併せて、前記応答時間の情報を含むＷｅｂクライアント情報を送信し、
前記第１種のＷｅｂプロキシサーバは、受信したＷｅｂクライアント情報に基づき、自身のグループのグループメンバのノード毎の前記応答時間の情報を管理すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項４】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記応答時間の情報は、前記Ｗｅｂクライアント装置が前記リダイレクト先の第２種のＷｅｂプロキシサーバから対象のＷｅｂコンテンツのキャッシュデータを受信するまでの時間を計測した値であること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項５】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記応答時間の情報は、前記Ｗｅｂクライアント装置が前記リダイレクト先の第２種のＷｅｂプロキシサーバから対象のＷｅｂコンテンツのキャッシュデータを受信するまでの時間の大きさを示すレベル値であること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項６】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント装置から前記第１種のＷｅｂプロキシサーバへ提供される前記Ｗｅｂクライアント情報は、前記応答時間が短かった第２種のＷｅｂプロキシサーバのノードの識別情報を含み、
前記第１種のＷｅｂプロキシサーバの応答ノード選択機能は、前記提供された識別情報に基づき、前記応答時間が短かった第２種のＷｅｂプロキシサーバのノードを優先的に選択すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項７】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント装置から前記第１種のＷｅｂプロキシサーバへ提供される前記Ｗｅｂクライアント情報は、前記応答時間が長かった第２種のＷｅｂプロキシサーバのノードの識別情報を含み、
前記第１種のＷｅｂプロキシサーバの応答ノード選択機能は、前記提供された識別情報に基づき、前記応答時間が長かった第２種のＷｅｂプロキシサーバのノードをなるべく選択しないようにすること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項８】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記該当の第１種のＷｅｂプロキシサーバは、前記応答ノード選択機能により、前記要求に対し応答させるノードを決定する際、前記各グループメンバのノードの負荷と応答時間の大きさの両方を考慮し、第１に、応答時間の短いノードを優先的に選択し、第２に、負荷の小さいノードを優先的に選択すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項９】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記該当の第１種のＷｅｂプロキシサーバは、前記応答ノード選択機能により、前記要求に対し応答させるノードを決定する際、前記各グループメンバのノードの負荷と応答時間の大きさの両方を考慮し、第１に、負荷の小さいノードを優先的に選択し、第２に、応答時間の短いノードを優先的に選択すること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項１０】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂサーバ装置は、前記Ｗｅｂプロキシサーバ装置のＰ２Ｐネットワークに配置される前記Ｗｅｂコンテンツのキャッシュデータを最新の状態に更新させるためのプッシュ機能を含むクライアント機能を備えること、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【請求項１１】
請求項１記載のＰ２Ｐ型Ｗｅｂプロキシネットワークシステムにおいて、
前記Ｗｅｂクライアント情報は、前記Ｗｅｂクライアント装置の属性情報を含み、
前記第１種のＷｅｂプロキシサーバは、前記第２種のＷｅｂプロキシサーバから前記Ｗｅｂクライアント装置へ応答する前記Ｗｅｂコンテンツのキャッシュデータをコンテンツフィルタリングする制御を行うコンテンツフィルタリング機能を有し、当該コンテンツフィルタリングの管理情報を保有し、
前記該当の第１種のＷｅｂプロキシサーバは、前記要求に対し応答させるノードから前記キャッシュデータを応答させる際、前記コンテンツフィルタリング機能により、前記Ｗｅｂクライアント情報を参照し、当該Ｗｅｂクライアントの属性に応じて、当該キャッシュデータをブロックするかどうかを含むコンテンツフィルタリング内容を決定し、当該内容で応答を制御する処理を行うこと、を特徴とするＰ２Ｐ型Ｗｅｂプロキシネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１３−１０５２２７（Ｐ２０１３−１０５２２７Ａ）
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１１−２４７０８０（Ｐ２０１１−２４７０８０）
【出願日】平成２３年１１月１１日（２０１１．１１．１１）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年１１月１１日（２０１１．１１．１１）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]