JP2014514673A - コンテンツ配布 - Google Patents

Abstract

本発明は、キャッシング戦略及び展開を含むネットワーク構成条件を考慮に入れてピア選択及びデータ交換のための良好な代替物をアプリケーションが見出せるようにピア・ツー・ピアアプリケーション環境を通知／構成するための方法を導入する。移動オペレータは、エンドユーザの移動通信装置へ、その移動通信装置により使用するために入手できるトラッカーファイルの位置に関するインストラクションを与える。このように、移動オペレータは、エンドユーザに利用できるピア・ツー・ピア環境をコントロールする。
【選択図】 図４

Description

本発明は、コンテンツ配布に関する。より詳細には、本発明は、ピア・ツー・ピア（Ｐ２Ｐ）の原理に基づいて動作するネットワークにおけるコンテンツ配布に関する。

コンテンツ配布及びキャッシングは、今日のインターネットでも、拡張可能で且つ良好に機能するネットワークアーキテクチャーの重要なイネイブラーである。配布及びキャッシングは、現在のインターネットに使用される幾つかのアプリケーションを挙げると、ＤＮＳ、プロキシーキャッシュ、コンテンツ配布ネットワーク（ＣＤＮ）、データセンターといった多数のレベルで行われる。

慣習的に、インターネットコンテンツの配布は、クライアント・サーバー構成を使用して実施されている。図１は、サーバー２、第１クライアント４、第２クライアント６及び第３クライアント８を備えたシステムを参照番号１で一般的に示している。各クライアントは、サーバー２と両方向通信する。例えば、第１クライアント４は、サーバー２に記憶されたデータにアクセスしたい場合、そのデータに対する要求をサーバーへ送り、サーバーは、それに応答して、データを与える。

クライアント・サーバー構成では、ほぼ全てのデータフローがサーバー（サーバー２のような）からクライアント（第１クライアント４のような）へ流れる。更に、データを得るために、個々のクライアントにより個々のサーバーへダウンロードセッションが開始され、そのセッションを使用して、要求されたデータが得られる。

図１のクライアント・サーバー解決策では、ある特定のクライアントは、異なるクライアントの以前のアクションから何の利益も得られないことに注意するのが重要である。例えば、第１クライアント４がサーバー２から第１ビデオファイルをダウンロードすると仮定する。第２クライアント６がその後に第１ビデオファイルを見たい場合は、そのファイルをサーバー２から第２クライアント６へ個別にダウンロードしなければならない。第２クライアント６は、当該ファイルが異なるクライアント（第１クライアント４）によって既にダウンロードされたという事実の利点を得ることができない。

図１を参照して上述した慣習的なクライアント・サーバー解決策は、コンテンツを得るのに使用できる唯一のメカニズムではない。クライアントが、サーバーに依存するのではなく、互いにコンテンツを与えるピア・ツー・ピア（Ｐ２Ｐ）ネットワークが普通になりつつある。

図２は、第１ユーザ１２、第２ユーザ１４、第３ユーザ１６、第４ユーザ１８、及び第５ユーザ２０を含むシステムを参照番号１０で一般的に示している。ほとんどのピア・ツー・ピアネットワークと同様に、ネットワーク１０内の異なるユーザ間には多数の接続が存在し、更に、それらの接続は、動的に変化し得る。規範的ネットワーク１０では、第１ユーザ１２は、第２、第３及び第５ユーザと両方向通信し、第２ユーザ１４は、第１、第３及び第５ユーザと両方向通信し、第３ユーザ１６は、第１、第２及び第４ユーザと両方向通信し、第４ユーザ１８は、第３及び第５ユーザと両方向通信し、そして第５ユーザは、第１、第２及び第４ユーザと両方向通信する。

第１ユーザ１２がネットワーク１０から音楽トラックをダウンロードしたいという状況について考える。そのトラックは、典型的に、しばしば「チャンク」と称される多数のエレメントに分割される。第１ユーザ１２が音楽トラック全体を検索するには、そのトラックの全てのチャンクをダウンロードしなければならない。

ネットワーク１０内の第２ユーザ１４、第３ユーザ１６及び第５ユーザ２０の各々からはトラックを利用できるが、第４ユーザ１８からは利用できないと仮定する。第１ユーザ１２は、第２、第３及び第５ユーザの１人以上から当該音楽ファイルのチャンクを並列にダウンロードすることができる。

上述したシステム１０は、ネットワーク１０内の他のピア／クライアントによりデータが与えられるピア・ツー・ピア構成を示している。これは、Ｐ２Ｐ解決策の一例である。第２の解決策では、ネットワーク内の他のピアによりデータが与えられ、ネットワーク内のサーバーによってもデータを与えることができる。第３の解決策では、ネットワーク内のサーバーのみによってデータが与えられる。第３の解決策は、複数のユーザからデータを得ることができるという点で、図１を参照して上述したクライアント・サーバー解決策とは異なる。

ピア・ツー・ピアネットワークでは、ユーザは、典型的に、クライアント（即ち、リソースの消費者）及びリソースのソース（又はキャッシュ）の両方として働く。ユーザは、例えば、ダウンロードチャンクのセットを他のユーザに利用できるようにする。典型的に、ユーザは、チャンクのサイズを変更しないが、いわゆる「再チャンク」が可能である。

従って、図２を参照して上述した例における第１ユーザ１２が音楽ファイルを得ると、第１ユーザは、典型的に、そのファイル（又はそのファイルの少なくとも若干）をピア・ツー・ピアネットワーク内の他のユーザに得られる（ひいては、キャッシュのソースとなる）ようにする。例えば、音楽ファイルの最初の数秒だけが得られるようにする（これは、多くの場合、第２ユーザが、音楽ファイル全体ではなく、ファイルの最初の数秒を聴くだけでよいので、有用である）。

ピア・ツー・ピアシステムでは、特定のファイルは、典型的に、１つ以上のキャッシュ位置に記憶されるチャンクに分割される。ピア・ツー・ピアネットワークは、多くの場合に、ファイル（しばしば「トラッカー」ファイルと称される）を含み、このファイルは、ネットワークのどこで特定のファイル（又はファイルの部分）を発見できるか指示する。そのようなトラッカーファイルは、ネットワーク１０のようなネットワークにおいて１つ以上の物理的ノードによって実施される。

図３は、ピア・ツー・ピアダウンロードオペレーションを実施するための既知のアルゴリズムを参照番号２５で一般的に示すフローチャートである。

アルゴリズム２５は、ネットワーク１０内の種々の位置で利用できるビデオファイルをダウンロードするために第１ユーザ１２により使用されると仮定する。アルゴリズム２５は、ステップ２６で開始され、ここで、第１ユーザ１２は、ビデオファイルの種々の部分（又はチャンク）がどこで得られるか指示するトラッカーファイルを得る。トラッカーファイルは、典型的に、関連ファイルを既にダウンロードした（それ故、潜在的にファイルのキャッシュ／ソースとして働くことのできる）全てのユーザの簡単なリストを与える。

クライアント（即ち、第１ユーザ１２）が、要求されたビデオファイルの潜在的なキャッシュ／ソースのリストを含むトラッカーファイルを得ると、アルゴリズムは、ステップ２７へ進み、ここで、クライアントは、ファイルのダウンロードを試みるためにトラッカーファイルにリストされたデータの潜在的ソースのどれを使用すべきか決定する選択ステップを実施する。当業者に明らかなように、このステップは、多数の異なる仕方で実施され、又、ランダムに実施される。

規範的アルゴリズム２５において、ホスト選択ステップ２７は、データチャンクの３つのソースを選択する。これらのデータソースは、コンタクトされる（並列に実行されるアルゴリズム２５のステップ２８、３０及び３２）。従って、アルゴリズム２５は、３つの異なるソースから並列にデータファイルの３つの異なるチャンクをダウンロードすることを求める。明らかに、３つより多くの（又は実際上それより少ない）ソースを並列にコンタクトさせることができる。チャンクのセットは、並列に、又は順次に、或いは何らかの組み合わせでダウンロードされてもよい（例えば、各々チャンクを順次にダウンロードする並列セッションのセット）。

アルゴリズム２５のステップ２８において、ダウンロードのためのファイルが選択される。次いで、アルゴリズムは、ステップ２９へ進み、そのファイルがダウンロードされる。ステップ２９が完了すると、アルゴリズムは、ステップ３４へ進む。並列に、ステップ３０において、ダウンロードのための第２のファイルが選択される。アルゴリズムは、ステップ３０からステップ３１へ進み、第２のファイルがダウンロードされた後に、アルゴリズムは、ステップ３４へ進む。更に、これも並列に、ステップ３２において、ダウンロードのための第３のファイルが選択される。アルゴリズムは、ステップ３２からステップ３３へ進み、第３のファイルがダウンロードされた後に、アルゴリズムは、ステップ３４へ進む。従って、ステップ２９、３１及び３３において、第１ユーザ１２は、隣接するピアからビデオファイルのチャンクを並列にダウンロードする。

ステップ２９、３１及び３３が完了すると、アルゴリズムは、ステップ３４へ進み、そこで、第１ユーザは、全ビデオファイルがダウンロードされたかどうか決定する。もしそうでなければ、アルゴリズム２５は、ステップ２７へ戻り、ダウンロードプロセスが続けられる。全ビデオファイルがダウンロードされると、アルゴリズム２５は、ステップ３５において終了となる。

アルゴリズム２５がステップ２７へ戻る場合には（ステップ３４において全ビデオファイルがまだダウンロードされていないと決定されたために）、ピア・ツー・ピアネットワークから更に別のデータファイルをシークするために新たなホスト選択手順が開始される。ここでも、トラッカーファイル（ステップ２６で得られた）を使用して、コンタクトすべき潜在的なデータソース（又はキャッシュ）を選択する。選択されると、アルゴリズム２５は、ステップ２８、３０及び３２へ進み、上述したダウンロード手順が繰り返される。しかしながら、コンタクトされるソースは、おそらく、以前とは異なる。これは、責任（及びオーバーヘッド）を果たすファイルをネットワーク内の多数の異なるノード配布する。

ピア・ツー・ピアシステムは、クライアント・サーバーシステムに勝る多数の効果を有する。例えば、ピア・ツー・ピアネットワーク内のユーザは、リソース（これに限定されないが、記憶スペースを含む）をシェアする。その結果、ネットワーク内のユーザの数が増加するにつれて、システムの容量が増加する。これは、より多くのユーザがシステムに加わるにつれて、各ユーザに利用できるリソースが減少するクライアント・サーバーシステムとは対照的である。

ピア・ツー・ピアネットワークの別の効果は、ファイル及び他のリソースが一般的に多数のリソースから得られることである。その結果、ネットワークの１つのノードが故障しても、他のユーザがファイルにアクセスできることを妨げないので、慣習的なクライアント・サーバーシステムより頑強なシステムとなる。

ピア・ツー・ピアネットワークは、各クライアントがネットワーク（典型的にインターネット）に常時接続されているときに及びデータ送信のコストがフラットである（即ち、送信されるデータの量に無関係である）ときには良好に機能する。

いわゆるスマートホンのような移動通信装置は、多くの場合に、インターネットに常時接続され、そしてデータ送信を制限しない料率で（エンドユーザに対して、データ送信のコストがフラットになるように）得ることができる。従って、移動通信装置は、ネットワーク１０のようなピア・ツー・ピアネットワークの一部分として使用することができる。しかしながら、ピア・ツー・ピア原理を移動通信装置に適用した場合には、特に、現在のトレンドとして、特定の期間に特定の料率でユーザがアクセスできる合計データ転送予算（例えば、所与のカレンダー月に対する最大データ転送予算）にオペレータが制限するために問題が生じる。

システム１０において、装置１２、１４、１６及び１８は、全て、家庭用ブロードバンド接続によってインターネットに接続された家庭用コンピュータであると仮定する。又、装置２０は、移動用ブロードバンド接続を使用してインターネットに接続された移動通信装置であると仮定する。

上述したアルゴリズム２５の規範的な実施において、第１装置１２がネットワーク１０内の種々の位置で得られるビデオファイルをダウンロードしたいと仮定する。ビデオファイルは、第２ユーザ１４、第３ユーザ１６及び第５ユーザ２０のいずれかから得られると仮定する。

装置１４、１６及び２０が全てアクティブであると仮定すれば、第１ユーザ１２は、全てのそれらユーザからビデオファイルのチャンクをダウンロードすることを求める（アルゴリズム２５のステップ２９、３１及び３３を実施する）。第５ユーザ２０からファイル（又はチャンク）をダウンロードするには、第５ユーザが自分のユーザ装置から移動ネットワークを経てファイルをアップロードする必要がある。これは、（エンドユーザ、移動オペレータ又はその両方にとって）費用のかかる実質的な無線リソースを使用し、データボトルネックを引き起こす（従って、性能を低下させる）。移動ネットワークの性能低下は、ピア・ツー・ピアネットワークの性能に影響を及ぼす。更に、他の目的でのユーザの移動性能に影響する程度に移動ネットワークにも影響が及ぶ。おそらく（移動オペレータの観点から）より重大なことに、移動ネットワークの他のユーザに対して移動ネットワークの性能に悪影響が及ぶ。

移動ネットワークに適用されるインターネット使用の展開及び特性では、移動ネットワークのアップロード能力が課題となる。無線／ワイヤレスアクセスは、ピア・ツー・ピアアプリケーションを使用するための付加的な課題を表わすので、移動ネットワーク（容量、遅延、等）及びピア・ツー・ピアアプリケーション性能の両方に対して良好なオペレーション条件を見出すことが困難である。

移動ネットワークにおけるピア・ツー・ピア原理の使用を禁止し又は制限することは、エンドユーザが別の移動プロバイダーをシークすることになるので、移動オペレータにとって魅力的な選択肢ではない。それ故、影響を受け易い移動ネットワークには、エンドユーザ及びネットワークの両方の観点から移動ネットワークの滑らかで且つ効率的な使用を可能にする最適化が与えられることが重要である。

本発明は、上述した問題の少なくとも幾つかを克服することに向けられる。

本発明は、エンドユーザが、移動通信装置を使用して、移動通信装置のユーザによってシークされたデータファイル（又はデータファイルの部分）の可能性の高い位置の情報を与えるトラッカーファイルをシークし、そして移動通信装置により使用される移動オペレータにより命令された位置からトラッカーファイルを得ることを含む方法を提供する。この方法は、更に、前記トラッカーファイルにより指示された１つ以上の位置から前記データファイルをシークすることを含む。トラッカーファイルは、例えば、前記移動オペレータのサーバーに記憶される。

又、本発明は、データファイル（又はデータファイルの部分）の可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを移動オペレータのサーバーに記憶し、そして前記移動オペレータを使用する１つ以上の移動通信装置へ、その移動通信装置により使用するために入手できるトラッカーファイル（又は１つ以上のトラッカーファイル）の位置に関するインストラクションを与えることを含む方法を提供する。

移動オペレータは、トラッカーファイルを記憶するように予め構成された１つ以上のサーバーを含む。

移動オペレータは、トラッカーファイルを記憶するために動的に割り当てできる１つ以上のサーバーを含む。

移動オペレータは、移動通信装置がアクティブなピアノード発見手順を実施することが許されるかどうかコントロールする（典型的に、１つ以上の隣接ノードが前記エンドユーザによりシークされたファイルを与えることができるかどうか決定するために）。

本発明のある形態において、データファイル（又はファイルの部分）の可能性の高い位置は、データファイルを以前にダウンロードした位置を含む。データファイルの可能性の高い位置は、ＵＲＬのようなアドレスにより指示される。

移動通信装置により使用するために入手できるトラッカーファイルの位置に関する移動通信装置へのインストラクションは、サーバー識別子を含む。それとは別に、又はそれに加えて、移動通信装置により使用するために入手できるトラッカーファイルの位置に関する移動通信装置へのインストラクションは、トラッカーファイル（例えば、ＵＲＬ）に対する絶対的参照を含む。

又、本発明は、データファイル（又はデータファイルの部分）の可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを記憶するためのサーバーと、移動オペレータを使用する移動通信装置へ、その移動通信装置により使用するために入手できるトラッカーファイルの位置に関するインストラクションを与えるためのコントロールメカニズムとを備えた移動オペレータを提供する。コントロールメカニズムは、動的なホスト構成プロトコル（ＤＨＣＰ）を使用させる。

移動オペレータは、１つ以上のトラッカーファイルを記憶するように予め構成された１つ以上のサーバーを備えている。

移動オペレータは、１つ以上のトラッカーファイルを記憶するために動的に割り当てできる１つ以上のサーバーを含む。

移動オペレータは、移動通信装置がアクティブなピアノード発見手順を実施することが許されるかどうかコントロールする（例えば、１つ以上の隣接ノードが前記エンドユーザによりシークされたファイルを与えることができるかどうか決定するために）。

データファイルの可能性の高い位置は、前記データファイルを以前にダウンロードした位置を含む。

移動通信装置により使用するために入手できるトラッカーファイルの位置に関する移動通信装置へのインストラクションは、サーバー識別子を含む。

移動通信装置により使用するために入手できるトラッカーファイルの位置に関する移動通信装置へのインストラクションは、トラッカーファイル（例えば、ＵＲＬ）に対する絶対的参照を含む。

本発明は、更に、移動通信装置のユーザによりシークされたデータファイル（又はデータファイルの部分）の可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを、移動通信装置により使用される移動オペレータにより命令される位置から得るための手段を備えた移動通信装置を提供する。

移動通信装置は、更に、前記トラッカーファイルにより与えられる１つ以上の位置から前記データファイルをシークするための手段を更に備えている。

トラッカーファイルは、前記移動オペレータのサーバーに記憶される。

移動オペレータは、１つ以上のトラッカーファイルを記憶するように予め構成された１つ以上のサーバーを含む。

移動オペレータは、１つ以上のトラッカーファイルを記憶するために動的に割り当てできる１つ以上のサーバーを含む。

移動オペレータは、移動通信装置がアクティブなピアノード発見手順を実施することが許されるかどうかコントロールする（１つ以上の隣接ノードが前記エンドユーザによりシークされたファイルを与えることができるかどうか決定するために）。

又、本発明は、エンドユーザが、移動通信装置を使用して、そのエンドユーザによってシークされたデータファイル（又はデータファイルの部分）の可能性の高い位置の情報を与えるトラッカーファイルをシークできるようにするためのコード（又は他の何らかの手段）、及び移動通信装置により使用される移動オペレータにより命令された位置からトラッカーファイルを得るためのコード（又は他の何らかの手段）を含むコンピュータプログラムを提供する。このコンピュータプログラムは、コンピュータに使用するために実施されたコンピュータプログラムコードを保持するコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品である。

本発明は、更に、１つのデータファイル（又は複数のデータファイル或いはデータファイルの部分）の可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを移動オペレータのサーバーに記憶するためのコード（又は他の何らかの手段）、及び前記移動オペレータを使用する移動通信装置へ、その移動通信装置により使用するために入手できる１つ以上のトラッカーファイルの位置に関するインストラクションを与えるためのコード（又は他の何らかの手段）を備えたコンピュータプログラムを提供する。このコンピュータプログラムは、コンピュータに使用するために実施されたコンピュータプログラムコードを保持するコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品である。

本発明は、Ｐ２Ｐネットワーク内に記憶されたデータにどのようにアクセスするかをユーザ（典型的に移動装置のユーザ）にどのように通知するかの問題に取り組む。換言すれば、移動オペレータが、移動ユーザ（即ち、移動オペレータのネットワークのユーザ）によるＰ２Ｐリソースへのアクセスをどのようにコントロールするかである。

移動装置が移動オペレータにより定義された仕方でＰ２Ｐサービスにアクセスするようにネットワーク構成が調整される。より詳細には、当該移動オペレータは、Ｐ２Ｐファイル（又はファイルチャンク）の潜在的な位置を得るのに使用されるトラッカーファイルを移動装置がどこで得るのかコントロールすることができる。

１つ以上のデータキャッシュ／ソースが、移動オペレータによって与えられる（即ち、移動ネットワークにおいてサーバーに記憶される）。データキャッシュは、移動ユーザに利用可能となる（移動ユーザが移動オペレータの他のエンドユーザのようなエンドユーザからデータにアクセスする必要がないように）。データキャッシュは、移動オペレータによりサービスされないエンドユーザに利用できるようにされても（されなくても）よい（即ち、Ｐ２Ｐ原理が適用されてもされなくてもよい）。

本発明は、キャッシング戦略及び展開を含むネットワーク構成条件を考慮に入れてピア選択及びデータ交換のための良好な代替物をピア・ツー・ピアアプリケーションが見出せるようにピア・ツー・ピアアプリケーション環境を通知／構成するための方法を導入する。本発明の方法は、リンク状態のネットワークトポロジーを明らかにせずにピア・ツー・ピアアプリケーション実行においてネットワーク状態を反映する可能性をネットワークオペレータに与える。アプリケーション及びネットワークの両方を、最適な性能に接近するように構成することができる。

添付図面を参照して本発明の規範的な実施形態を一例として以下に詳細に述べる。

既知のクライアント・サーバーシステムのブロック図である。 既知のピア・ツー・ピアネットワークのブロック図である。 ピア・ツー・ピアダウンロードオペレーションを示すフローチャートである。 本発明の態様によるシステムのブロック図である。 本発明の態様によるシステムのブロック図である。 本発明の態様によるシステムのブロック図である。

図４は、本発明の態様によるシステムを参照番号４０により一般的に示すブロック図である。

システム４０は、インターネットのようなネットワーク４１を備えている。第１ユーザ４２、第２ユーザ４４及び第３ユーザ４６は、各々、ネットワーク４１に接続され、そしてネットワークを経て互いに通信することができる。第１、第２及び第３のユーザは、例えば、パーソナルコンピュータ及び家庭用ブロードバンド接続を使用してネットワーク４１に接続される。

又、システム４０は、ネットワーク４１に接続された移動オペレータ４８も備えている。第４ユーザ５０及び第５ユーザ５２（図４には移動電話記号を使用して示す）は、各々、移動オペレータ４８に接続される。第４ユーザ５０及び第５ユーザ５２は、各々、移動オペレータ４８及びネットワーク４１を経て第１、第２及び第３ユーザと通信することができる。

上述したように、第１、第２、第３、第４及び第５ユーザが、各々、従来のピア・ツー・ピアネットワークの一部分である場合には、第４ユーザ５０からネットワーク内の他のユーザへファイルをアップロードするとき、第４ユーザ５０と移動オペレータ４８との間の無線接続が使用される。同様に、第５ユーザ５２にキャッシュされたファイルをピア・ツー・ピアネットワーク内の他のユーザにアップロードするとき、第５ユーザ５２と移動オペレータ４８との間の無線接続が使用される。

従来のピア・ツー・ピアネットワークでは、各クライアントが情報消費者及びソース／キャッシュの両方として働く。これら２つの役割は、密接に結合される。以下に詳細に述べるように、システム４０は、キャッシュ４９を移動オペレータ４８の一部分として設けることによりこれら２つの役割を切り離す。キャッシュ４９は、従来はエンドユーザ５０及び５２に記憶されたものであってピア・ツー・ピアネットワーク内の他のユーザに利用できるファイルを記憶するのに使用される。

アルゴリズム２５の使用についてもう一度考えると、今度は、アルゴリズムは、システム４０内の種々の位置で利用できるビデオファイルをダウンロードするために第１ユーザ４２により使用される。アルゴリズム２５は、ステップ２６において開始され、そこで、第１ユーザ４２は、ビデオファイルの種々の部分（又はチャンク）の位置が得られることを指示するトラッカーファイルを得る。

当該ビデオファイルが第２ユーザ４４、第３ユーザ４６及び第４ユーザ５０によりアクセスされたと仮定する。慣習的なピア・ツー・ピアノードでは、第２ユーザ４４及び第３ユーザ４６は、各々、ビデオファイルのキャッシュ／ソースとして働き、それ故、ステップ２６において設けられるトラッカーファイルに含まれる。

第４ユーザ５０は、直接的にはビデオファイルのキャッシュ／ソースとして働かない。むしろ、移動オペレータ４８のキャッシュ４９内にファイルが記憶される。従って、トラッカーファイルは、移動オペレータ４８の第１ユーザ４４、第２ユーザ４６及びキャッシュ４９においてビデオファイルにアクセスできることを指示する。

上述したように、クライアント（即ち、第１ユーザ４２）がトラッカーファイルを得ると、第１ユーザ４２は、ビデオファイルのチャンクを隣接するピアから並列にダウンロードする。これらのピアは、移動オペレータ４８を含むが、第４ユーザ５０は含まない。従って、移動オペレータ４８と第４ユーザ５０との間の無線接続は使用されない。

従って、慣習的なピア・ツー・ピアシナリオでは、エンドユーザの２つの役割（情報消費者及び情報ソースの両方としての）が密接に結合されるが、システム４０は、それらの役割を切り離し、それらを移動ネットワーク内のより最適な場所に配置する。

しかしながら、変更型ピア・ツー・ピアネットワーク内に記憶されたデータにどのようにアクセスするかユーザに通知するという問題が残されている。特に、上述したユーザ５０及び５２のような移動ユーザによるＰ２Ｐリソースへのアクセスをコントロールするという問題が残されている。

図５は、移動通信装置６２、移動オペレータ６４及びネットワーク６６（インターネットのような）を備えたシステムを参照番号６０で一般的に示すブロック図である。移動通信装置６２は、移動オペレータ６４を経てネットワーク６６にアクセスすることができる。移動通信装置６２は、以下に述べるように、ピア・ツー・ピアソースにアクセスするように構成される。移動装置は、図４を参照して上述した第４ユーザ５０又は第５ユーザ５２として使用することができる。

移動オペレータ（オペレータ６４のような）は、彼等のユーザの装置がキャッシュ即ちデータソースに作用するピア・ツー・ピア使用シナリオに対して彼等のどんな無線アクセス技術が良く適するかを最も良く知っている。この知識に基づき、移動装置のネットワーク構成を引き受ける構成手順は、移動装置が移動オペレータにより定義されたようにピア・ツー・ピアサービスにアクセスするように調整される。

システム６０において、移動オペレータ６４は、ピア・ツー・ピア原理を使用して特定のファイルにアクセスするために移動通信装置６２がトラッカーリストにどのようにアクセスできるか定義する。従って、移動オペレータ６４は、上述したアルゴリズム２５のステップ２６に使用されるトラッカーファイルを移動装置がどこで得るかをコントロールする。そのために、移動オペレータ６４は、次のうちの少なくとも幾つかを移動通信装置６２に与える。
１．アクティブな隣接ピア発見がＯＮであるかＯＦＦであるか；
２．トラッキングリストを要求することのできるサーバーＩＤ（例えば、ＩＰアドレス又は完全に資格付けされたドメイン名（ＦＱＤＮ））；
３．ダウンロードすることのできるトラッキングリストＩＤ（例えば、ｈｔｔｐ ＵＲＬ）；及び
４．全トラックに使用すると想定される予め構成された（ジェネリックな）トラッキングリスト。

これら４つの選択肢は、クライアントが所与のファイル（音楽又はビデオファイルのような）に対しキャッシュのリストをどのように得るか定義する。従って、本発明は、移動装置６２がピア・ツー・ピアファイル又はファイルの部分を得るように求める場所にわって移動ネットワーク６４がコントロールの度合いを働かせることができるようにする。例えば、移動オペレータ６４は、移動装置が特定のソースからファイル（又はファイル部分／チャンク）を得るのを防止する。

選択肢１は、クライアントがアクティブなピアノード発見手順を実施すべきかどうか定義する。選択肢１は、他の３つの選択肢とは独立して与えられる。アクティブなピアノード発見が許されない場合には、移動装置６２は、ファイルがどこで得られるか決定するためにトラッカーリストに完全に依存しなければならない（以下に詳細に述べるように、選択肢２から４の１つ以上に基づき、どのトラッカーリストが得られるか）。以下に詳細に述べるように、本発明のある実施形態では、トラッカーファイルが移動オペレータ６４から得られる。従って、システム６０は、ある環境において、移動通信装置がピア・ツー・ピアサービスにアクセスできる程度を移動オペレータがコントロールできるようにする。

選択肢３は、トラッカーリストへの絶対的参照を与える。その参照は、例えば、ｈｔｔｐ ＵＲＬ（ユニフォームリソースロケーター）として表現される。それ故、選択肢３は、選択肢２に非常に類似している。選択肢２は、サーバーのコンタクト情報（例えば、ＩＰアドレス）しか与えず、移動装置がどのようにリストを要求するか、即ちどんなプロトコルを使用するか明らかにしない。おそらく、移動装置６２にとって選択肢３を使用する方が容易である。というのは、選択肢３は、当該サーバーにどのようにコンタクトすべきか指定するからである。

選択肢４は、予め構成されたトラッカーリストを与える。例えば、移動オペレータ６４は、要求側ユーザ（ユーザ装置６２のような）へトラッカーリストを与えるために常に利用できる永久的サーバーを有する。本発明のある形態では、選択肢４の予め構成されたトラッカーリストは、常に利用できるが、他のトラッカーリスト（選択肢２又は選択肢３に基づくリストのような）が利用できる場合には無効にされる。従って、他の選択肢が付加的なキャッシュを与えることができ、選択肢４は、デフォールトリストを与える。

例えば、予め構成されたトラッカーリストは、選択肢４を経て常に利用できるが、移動オペレータ６４は、新たなトラッカーファイルを動的に発生できるに充分なほど柔軟性がある（例えば、負荷バランスのため又はボトルネックを除去するため）。新たなトラッカーファイル（１つ又は複数）（一時的でよい）は、選択肢２又は選択肢３に基づいて発生され、選択肢４の予め構成されたトラッカーを無効にする。

図６は、本発明が使用されるシステムを参照番号７０で一般的に示したブロック図である。

システム７０は、移動オペレータ７２を備えている。移動オペレータ７２は、多数の異なる技術を使用して移動通信を与える。システム７０は、第１の移動通信ネットワーク７４、第２の移動通信ネットワーク７６、及び第３の移動通信ネットワーク７８を備えている。移動装置（上述した移動装置６２のような）は、ネットワーク７４、７６及び７８の１つ以上を使用して（例えば、ライセンス付きワイヤレス技術（例えば、３ＧＰＰ）及びライセンスなしワイヤレス技術（例えば、ＷＬＡＮ）の両方を含むアクセスネットワーク並びにワイヤードアクセスネットワークを使用して）移動オペレータ７２と通信することができる。例えば、システム７０の１つの実施形態では、第１ネットワーク７４は、２Ｇネットワークであり、第２ネットワーク７６は、３Ｇネットワークであり、そして第３ネットワーク７８は、ＷｉＦｉネットワークである。当業者に容易に明らかなように、上述したネットワークに代わって又はそれに加えて、他の通信ネットワーク（ＬＴＥネットワークのような）を使用することができる。

移動オペレータ７２は、多数のサーバーを備えている。図６に示すように、オペレータ７２は、第１サーバー８０、第２サーバー８２、第３サーバー８４、第４サーバー８６、及び第５サーバー８８を備えている。これらのサーバーは、移動オペレータ７２によってサポートされる移動装置へトラッカーファイルを与える。

又、システム７０は、ネットワークと移動オペレータとの間の通信の設定をコントロールするメカニズムも備えている。従って、第１のコントロールメカニズム９０は、第１ネットワーク７４と移動オペレータ７２との間の通信の設定をコントロールする。同様に、第２のコントロールメカニズム９２は、第２ネットワーク７６と移動オペレータ７２との間の通信の設定をコントロールし、そして第３のコントロールメカニズム９４は、第３ネットワーク７８と移動オペレータ７２との間の通信の設定をコントロールする。

１つの規範的な実施形態では、コントロールネットワーク９０、９２及び９４は、動的ホスト構成可能プロトコル（ＤＨＣＰ）を使用する。このＤＨＣＰは、例えば、インターネットプロトコルアドレスを指定するために使用される既知の構成プロトコルである。

クライアント（移動装置のような）が特定ファイルに対するキャッシュのリストを得ることができるようにするための上述した４つの選択肢は、システム７０に使用することができる。

上述したように、選択肢１は、特定の移動装置に対するアクティブな隣接ピア発見機能がアクチベートされるかどうか定義する。典型的に、異なるＲＡＮ（無線アクセスネットワーク）にサービスするＤＨＣＰ又は同様のサーバーは、選択肢１をオン又はオフにセットするように予め構成される。規範的システム７０では、ＤＨＣＰサーバー９０及び９２は、各々、第１ネットワーク７４及び第２ネットワーク７６に対して選択肢１を「オフ」にセットする。又、ＤＨＣＰサーバー９４は、第３ネットワーク７８に対して選択肢１を「オン」にセットする。

従って、（例えば、２Ｇネットワークか又は３Ｇネットワークを使用して）移動装置と移動オペレータ７２との間の通信に対して高価な無線リソースが使用されるときに、ＤＨＣＰサーバーは、隣接ピア発見がディスエイブルされることを指示する。しかしながら、例えば、ユーザ装置がＷｉＦｉホットスポットに入る（且つ第３ネットワーク７８を使用する）か、又は他の良好な接続エリアに入る場合には、移動オペレータ６４に対してより慣習的なピア・ツー・ピアシステムを許容できるようになる。そのような環境では、ＤＨＣＰサーバー９４は、隣接ピア発見を許し、移動装置が、特定のトラックファイルにより定義されたもの以外のピアノードにアクセスできるようにする。

規範的な移動オペレータ７２において、第１サーバー８０及び第２サーバー８２は、常に利用でき、第３サーバー８４は利用できるが、コンタクトの詳細が与えられず、第４サーバー８６は、第１ネットワーク７４にトポロジー的に接近していて、帯域巾需要がそれを要求する場合には動的に利用することができ、そして第５サーバー８８は、第２ネットワーク７６にトポロジー的に接近していて、帯域巾需要がそれを要求する場合には動的に利用することができると仮定する。

第１サーバー８０及び第２サーバー８２は、いずれの移動装置でも常に利用できるデフォールトサーバーである。従って、第１サーバー及び第２サーバーは、選択肢４の一部分として設けられる。それ故、これらのサーバーは、トラッカーリストを得るのに使用するために常に入手できるが、その使用は、他の選択肢（もし入手できれば）に取り換えられてもよい。

第３サーバー８４は、選択肢２の一部分として設けられる。第３サーバーは、一般的に利用でき、サーバーＩＤが与えられるが、コンタクトの詳細は与えられない。

第４サーバー８６は、常に利用できるものでないが、必要に応じて、第１ネットワーク７４のユーザに対して利用可能となる。第４サーバーは、移動オペレータ７２のコントロールのもとで動的に展開することができる。第３サーバーの詳細が、選択肢３の一部分として第１ネットワークを使用して移動装置に与えられる。第４サーバーが利用できる場合には、第１ネットワーク７４を使用する移動装置は、ある実施形態では、選択肢４のもとで利用できるいずれのサーバーにも優先して第４サーバーを使用する。

同様に、第５サーバー８８も、常に利用できるのではないが、必要に応じて、第２ネットワーク７６のユーザに対して利用可能となる。第５サーバーは、移動オペレータ７２のコントロールのもとで動的に展開することができる。第５サーバーの詳細が、選択肢３の一部分として第２ネットワークを使用して移動装置に与えられる。第５サーバーが利用できる場合には、第２ネットワーク７６を使用する移動装置は、ある実施形態では、選択肢４のもとで利用できるいずれのサーバーにも優先して第５サーバーを使用する。

従って、上述した４つの選択肢を使用して、オペレータ（システム６０の移動オペレータ６４又はシステム４０の移動オペレータ４８のような）は、その移動オペレータのピア・ツー・ピアキャッシュ展開戦略をたどるようにその異なる無線アクセスネットワークの構成手順を予め構成することができる。ＤＨＣＰは、ホストネットワーク関連パラメータを構成するためのフレームワークを与えるが、このフレームワークは、拡張可能であり、新たな選択肢を追加できることを意味する。しかしながら、ＩＥＴＦ標準化が必要とされない場合には、ＤＨＣＰにより与えられる情報がＡＬＴＯサーバー（http://datatracker.ietf.org/wg/alto/において議論されている）により使用されて、ピア選択に対するクライアント能力の他のピア・ツー・ピアクライアント知識を与えるためにクライアント能力を配布することができる。ＤＨＣＰの使用は、例えば、ブランド付きハンドセットをもつ移動オペレータに対する１つの合理的な展開プランであり、ここで、オペレータは、そのハンドセットの動作をどのように想定するか判断する権限を有し且つ新規な付加的な機能を提案することができる。又、本発明は、特に、クライアントに対する「ラストマイル」アクセスの能力を考えたときに、他のネットワークにとっても有用である。

当業者であれば、上述した４つの選択肢は、特定のシステムにおいてその全部を与える必要がないことが明らかであろう。例えば、デフォールトトラッカーリスト位置がなくてもよい（選択肢４が与えられないように）。デフォールトトラッカーリスト位置だけがあってもよい（選択肢２も選択肢３も与えられないように）。選択肢２及び３の１つが与えられるが、他の選択肢は与えられなくてもよい。更に、全ての実施形態において選択肢１が与えられなくてもよい。従って、本発明は、非常に高度な融通性を含む。

又、本発明は、ネットワーク内のキャッシュの利用を開始しないピア・ツー・ピアクライアントに対しても有益である。というのは、ＤＨＣＰをもつピア・ツー・ピアクライアントの構成が、良好な無線及び他の能力をもつターゲットクライアントに対するＰ２Ｐピア選択に影響を及ぼすからである。構成された能力は、直接ピア通信を通して、又はＡＬＴＯタイプのサーバーの利用を通して、他のピアに利用することができる。

上述した本発明の実施形態は、例示に過ぎず、それに限定されない。当業者であれば、前記装置及び方法は、本発明の一般的な範囲から逸脱せずに多数の変更を合体できることが明らかであろう。特許請求の範囲内に包含されるそのような変更は、全て、本発明の範囲内に含まれることが意図される。

１：システム
２：サーバー
４、６、８：クライアント
１０：システム
１２、１４、１６、１８、２０：ユーザ
２５：アルゴリズム
４０：システム
４１：ネットワーク
４２、４４、４６、５０、５２：ユーザ
４８：移動オペレータ
４９：キャッシュ
６０：システム
６２：移動通信装置
６４：移動オペレータ
６６：ネットワーク
７０：システム
７２：移動オペレータ
７４、７６、７８：移動通信ネットワーク
８０、８２、８４、８６、８８：サーバー
９０、９２、９４：コントロールメカニズム

Claims (16)

1. 移動通信装置を使用して、移動通信装置のユーザによりシークされたデータファイルの可能性の高い位置の情報を与えるトラッカーファイルをシークする段階、及び
   前記移動通信装置により使用される移動オペレータにより命令された位置から前記トラッカーファイルを得る段階、
   を含む方法。
2. データファイルの可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを移動オペレータのサーバーに記憶する段階、及び
   前記移動オペレータを使用する１つ以上の移動通信装置へ、その移動通信装置によって使用するために入手できるトラッカーファイルの位置に関するインストラクションを与える段階、
   を含む方法。
3. 前記移動オペレータは、１つ以上のトラッカーファイルを記憶するように予め構成された１つ以上のサーバーを含む、請求項１又は２に記載の方法。
4. 前記移動オペレータは、前記移動通信装置が、アクティブなピアノード発見手順を実施することが許されるかどうかコントロールする、請求項１から３のいずれか１つに記載の方法。
5. 前記データファイルの前記可能性の高い位置は、前記データファイルを以前にダウンロードした位置を含む、請求項１から４のいずれかに記載の方法。
6. 前記移動通信装置によって使用するために入手できるトラッカーファイルの位置に関する前記移動通信装置への前記インストラクションは、サーバー識別子を含む、請求項１から５のいずれかに記載の方法。
7. 前記移動通信装置によって使用するために入手できるトラッカーファイルの位置に関する前記移動通信装置への前記インストラクションは、トラッカーファイルに対する絶対的参照を含む、請求項１から６のいずれかに記載の方法。
8. データファイルの可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを記憶するためのサーバーと、
   移動オペレータを使用する移動通信装置へ、その移動通信装置によって使用するために入手できるトラッカーファイルの位置に関するインストラクションを与えるためのコントロールメカニズムと、
   を備えた移動オペレータ。
9. 前記コントロールメカニズムは、動的なホスト構成プロトコルを使用する、請求項８に記載の移動オペレータ。
10. １つ以上のトラッカーファイルを記憶するように予め構成された１つ以上のサーバーを備えた、請求項８又は９に記載の移動オペレータ。
11. １つ以上のトラッカーファイルを記憶するように動的に割り当てできる１つ以上のサーバーを備えた、請求項８から１０のいずれか１つに記載の移動オペレータ。
12. 前記移動オペレータは、前記移動通信装置がアクティブなピアノード発見手順の実施を許されるかどうかコントロールするように構成された、請求項８から１１のいずれか１つに記載の移動オペレータ。
13. 前記データファイルの前記可能性の高い位置は、前記データファイルを以前にダウンロードした位置を含む、請求項８から１２のいずれか１つに記載の移動オペレータ。
14. 移動通信装置のユーザによりシークされたデータファイルの可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを、移動通信装置により使用される移動オペレータにより命令される位置から得るための手段を備えた移動通信装置。
15. エンドユーザが、そのエンドユーザによりシークされたデータファイルの可能性の高い位置の情報を与えるトラッカーファイルをシークできるようにする手段、及び
    移動通信装置により使用される移動オペレータにより命令された位置から前記トラッカーファイルを得る手段、
    を含むコンピュータプログラム製品。
16. データファイルの可能性の高い位置の情報を与えるのに使用されるトラッカーファイルを移動オペレータのサーバーに記憶する手段、及び
    前記移動オペレータを使用する移動通信装置へ、その移動通信装置により使用するために入手できるトラッカーファイルの位置に関するインストラクションを与える手段、
    を備えたコンピュータプログラム製品。

Images