(57)【要約】【課題】専用アプリケーションのインストールを求めることなく、ＣＤＮと同様な効果を得ることができるコンテンツ配信を実現する。【解決手段】本システムは、コンテンツの配信を求める要求があった場合、要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する。そして、存在しないと判定された場合、要求されたコンテンツをコンテンツ・データベースから取得して要求元のユーザ端末へ配信する。一方、存在すると判定された場合、キャッシュを保有するユーザ端末のうちから１または複数のユーザ端末を選択する。そして、ピアツーピア（P2P）通信によって、選択された１または複数のユーザ端末から要求元のユーザ端末へ要求されたコンテンツを配信させる。【選択図】図１
2016051389.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介してユーザ端末にコンテンツを配信するためのシステムであって、
コンテンツが蓄積されているコンテンツ・データベースと、
前記通信ネットワークに接続された複数のユーザ端末のうちの何れかのユーザ端末からコンテンツの配信を求める要求があった場合、前記通信ネットワークに接続された複数のユーザ端末のうち、前記要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する判定手段と、
存在しないと判定された場合、前記要求されたコンテンツを前記コンテンツ・データベースから取得して要求元のユーザ端末へ配信する配信手段と、
存在すると判定された場合、前記キャッシュを保有するユーザ端末のうちから１または複数のユーザ端末を選択する選択手段と、
前記選択された１または複数のユーザ端末と、前記要求元のユーザ端末との間にピアツーピア（P2P）通信を形成し、前記ピアツーピア（P2P）通信によって、前記選択された１または複数のユーザ端末から前記要求元のユーザ端末へ前記要求されたコンテンツを配信させる制御手段と、
を備えるシステム。
【請求項２】
前記要求されたコンテンツのキャッシュを保有しているユーザ端末に関するキャッシュ情報を管理する管理手段をさらに備え、
前記判定手段は、前記キャッシュ情報に基づき、前記要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する請求項１記載のシステム。
【請求項３】
ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて前記通信ネットワークに接続された複数のユーザ端末を接続するための機能を有するウェブ・リアルタイム通信（ＷｅｂＲＴＣ）を使用するためのWebRTC PF 利用者識別子を登録する登録手段をさらに備え、
前記制御手段は、登録されている前記選択された１または複数のユーザ端末のWebRTC PF 利用者識別子に基づき、前記ピアツーピア（P2P）通信を形成する請求項１記載のシステム。
【請求項４】
通信ネットワークを介してユーザ端末にコンテンツを配信するための方法であって、
前記通信ネットワークに接続された複数のユーザ端末のうちの何れかのユーザ端末からコンテンツの配信を求める要求があった場合、前記通信ネットワークに接続された複数のユーザ端末のうち、前記要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定し、
存在しないと判定された場合、前記要求されたコンテンツをコンテンツ・データベースから取得して要求元のユーザ端末へ配信し、
存在すると判定された場合、前記キャッシュを保有するユーザ端末のうちから１または複数のユーザ端末を選択し、
前記選択された１または複数のユーザ端末と、前記要求元のユーザ端末との間にピアツーピア（P2P）通信を形成し、前記ピアツーピア（P2P）通信によって、前記選択された１または複数のユーザ端末から前記要求元のユーザ端末へ前記要求されたコンテンツを配信させる、方法。
【請求項５】
前記要求されたコンテンツのキャッシュを保有しているユーザ端末に関するキャッシュ情報を管理し、
前記判定することは、前記キャッシュ情報に基づき、前記要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する、請求項４記載の方法。
【請求項６】
ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて前記通信ネットワークに接続された複数のユーザ端末を接続するための機能を有するウェブ・リアルタイム通信（ＷｅｂＲＴＣ）を使用するためのWebRTC PF 利用者識別子を登録し、
前記要求されたコンテンツを配信させることは、登録されている前記選択された１または複数のユーザ端末のWebRTC PF 利用者識別子に基づき、前記P2P通信を形成する、請求項４記載の方法。
【請求項７】
通信ネットワークを介してユーザ端末にコンテンツを配信するためのプログラムであって、
コンピュータに、
前記通信ネットワークに接続された複数のユーザ端末のうちの何れかのユーザ端末からコンテンツの配信を求める要求があった場合、前記通信ネットワークに接続された複数のユーザ端末のうち、前記要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する手順と、
存在しないと判定された場合、前記要求されたコンテンツをコンテンツ・データベースから取得して要求元のユーザ端末へ配信する手順と、
存在すると判定された場合、前記キャッシュを保有するユーザ端末のうちから１または複数のユーザ端末を選択する手順と、
前記選択された１または複数のユーザ端末と、前記要求元のユーザ端末との間にピアツーピア（P2P）通信を形成し、前記ピアツーピア（P2P）通信によって、前記選択された１または複数のユーザ端末から前記要求元のユーザ端末へ前記要求されたコンテンツを配信させる手順と、を実行させるプログラム。
【請求項８】
前記要求されたコンテンツのキャッシュを保有しているユーザ端末に関するキャッシュ情報を管理する手順をコンピュータにさらに実行させ、
前記判定する手順は、前記キャッシュ情報に基づき、前記要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する、請求項７記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えば、ピアツーピア（Ｐ２Ｐ）通信を活用したコンテンツを配信するサービスを実現するシステム、方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、アクセス回線の大容量化に伴い、動画、音楽などの様々なコンテンツ等をユーザに配信するコンテンツ配信サービスの普及が目覚ましく、様々なコンテンツ配信サービスを実現するためのシステムが知られている。従来のこの種のコンテンツ配信サービスは一般的にクライアントサーバ型の通信で実現される。クライアントサーバ型の通信方式を使用した場合、例えばユーザ数が増えることによりサービス規模が大きくなるにつれ、サーバへのトラヒックが集中し、サーバへの負荷が高くなる傾向がある。
【０００３】
したがって、多数のユーザに向けてコンテンツ配信を行う場合、商用目的のコンテンツ配信ネットワークであるContents delivery network（ＣＤＮ）が広く利用されている。
【０００４】
図６は、この種の従来から用いられているＣＤＮを示すシステム概念図である。図６は、具体的には、ＣＤＮでは、複数のキャッシュサーバであるコンテンツキャッシュ管理部６０（＃１）、６０（＃２）、・・・、６０（＃ｎ）が例えばインターネットのような通信ネットワーク１０上に接続されている。また、ネットワーク１０には、ユーザ端末１１（＃１）、・・・、１１（＃ｎ）のように複数のユーザ端末１１が接続されている。また、ＣＤＮは、サービス提供部６１およびユーザ情報管理部６２を有する。
【０００５】
コンテンツキャッシュ管理部６０（＃１）、６０（＃２）、・・・、６０（＃ｎ）の各々は、キャッシュＤＢ６３（＃１）、６３（＃２）、・・・、６３（＃ｎ）、コンテンツキャッシュ機能６４（＃１）、６４（＃２）、・・・、６４（＃ｎ）を備える。各キャッシュＤＢ６３には、コンテンツのキャッシュが格納される。各コンテンツキャッシュ機能６４は、サービス提供部６１のＷｅｂサーバ機能７２と接続されており、Ｗｅｂサーバ機能７２と連携してコンテンツのキャッシュに関する処理を行う。
【０００６】
ユーザ情報管理部６２は、ユーザ情報ＤＢ６９とユーザ認証機能７０を有する。ユーザ認証機能７０は、ユーザ情報ＤＢ６９に予め登録されたユーザの情報に基づき、ユーザの認証を行い、登録ユーザであるか否か判定する。サービス提供部６１は、コンテンツに関する情報を提供するＷｅｂページ等をホストするＷｅｂサーバ機能７２と、コンテンツが蓄積されているコンテンツＤＢ７１を有し、ユーザ端末１１（＃１）、・・・、１１（＃ｎ）からの配信要求に対して要求されるコンテンツを提供する。
【０００７】
このように、図６に示すように、ＣＤＮでは、複数のキャッシュサーバであるコンテンツキャッシュ管理部６０（＃１）、６０（＃２）、・・・、６０（＃ｎ）がネットワーク１０上に分散して配置される。そのため、配信サービスの質を損なうことなく、サーバへの負荷を低減することができる。例えば、Akamai社やLimelight社などによる技術がその具体例として挙げられる。
【０００８】
一方、コンテンツを配信されたユーザ端末１１同士で、保有するコンテンツを交換するＰ２Ｐ型のコンテンツ配信システムもある。Ｐ２Ｐ型のコンテンツ配信システムは、例えば、BitTorrent等がある。Ｐ２Ｐ型のコンテンツ配信システムでは、コンテンツの配信を受けたピア（ユーザ端末１１）が他のピアに対してコンテンツを提供することができる。そのため、人気が高いコンテンツほどサーバとしての機能を提供するピアが増加するため、Ｐ２Ｐ型のコンテンツ配信システムはスケーラビリティに優れている。
【０００９】
また、Ｐ２Ｐ通信を利用するシステムの中には、全くサーバを必要としない完全にサーバレスなＰ２Ｐ通信システムも存在する。しかしながら、多くのシステムは、相手となるピアを発見する手助けをするサーバを介して通信を開始し、その後Ｐ２Ｐ通信に切り替えるものが多い。
【００１０】
今日の典型的な通信環境ではネットワークアドレス変換またはファイアウォール（ＮＡＴ／ＦＷ）が配備されている。（本来、NATとはグローバルIPアドレスとプライベートIPアドレスを１対１で結びつける技術を指していたが、近年ではNATは１つのグローバルIPアドレスを複数端末で共有する技術（NAPT）を指すことが多く、本明細書でもそれに従う。）そのため、このようなサーバによるサポートを受ける場合、ＮＡＴ／ＦＷを通過するための技術を利用しなければならない。ＮＡＴ／ＦＷを通過するための技術は、ピアのグローバルＩＰアドレスとポート番号を知らせてＵＤＰホールパンチング技術によりＮＡＴ／ＦＷ通過を実現する Session Traversal Utilities for NAT （ＳＴＵＮ） 技術や、メディアやアプリの配信サーバを介さずにリレーサーバを配備する Traversal Using Relay NAT （ＴＵＲＮ） 技術、ＳＴＵＮとＴＵＲＮを組み合わせ、体系立ててＮＡＴ／ＦＷを通過するためのプロシージャ手順としてInteractive Connectivity Establishment （ＩＣＥ）技術 などがある（例えば、非特許文献１参照）。
【００１１】
ＩＣＥ技術を利用した実装の例として、ブラウザ上でリアルタイム通信を実現するフレームワークであるWeb Real-time Communications （ＷｅｂＲＴＣ）がある。ＷｅｂＲＴＣはビデオチャット等を簡単に実現する技術として注目されている。そして、Ｐ２Ｐ通信の実現のためにＩＣＥ技術を利用することが定められており、ブラウザやブラウザコンポーネントにＩＣＥ機能が標準的に実装されるようになることが予想される。（例えば、非特許文献２参照。）
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】RFC5245 Interactive Connectivity Establishment(ICE):A Protocol for Network Address Translator (NAT) Traversal Offer/Answer Protocol
【非特許文献２】２０１４年  電子情報通信学会総合大会、通信講演論文集２  B-7-66、「ＷｅｂＲＴＣデータチャネル接続機能のエンドーエンド間通信への活用方式の検討」、2014/3/18~21、新潟市
【発明の概要】
【発明が解決しようとする課題】
【００１３】
ところが、このような従来のＣＤＮを利用する場合、高性能なＣＤＮサーバをキャッシュサーバとして使用すると、安定したコンテンツ配信が期待できるが、コンテンツ配信事業者はＣＤＮサーバを提供する事業者と契約をする必要がある。また、トラヒックに応じて課金されるため、コンテンツ配信事業者にとって、コストが高くなるという問題がある。
【００１４】
また、従来のＰ２Ｐネットワークを用いてコンテンツを配信する場合、コンテンツ配信事業者は、Ｐ２Ｐ通信を有するアプリケーションの開発を要する。また、非特許文献１に示すような複雑な実装規定を理解し、ＮＡＴ／ＦＷ通過を実現するためのＩＣＥ機能を提供するためのサーバを用意する必要がある。また、ユーザは、サービスを利用するために、アプリケーションをインストールすることが求められるため、即時にサービスを利用することが難しいという問題がある。
【００１５】
この発明は上記事情に着目してなされたもので、その目的とするところは、ユーザ端末にプラグインや専用アプリケーションのインストールを求めることなく、キャッシュサーバを用いたＣＤＮを利用する場合と同様な効果を得ることができるコンテンツ配信を実現するためのシステム、方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【００１６】
上記目的を達成するためにこの発明の第１の観点は、以下のような構成要素を備えている。すなわち、通信ネットワークを介してユーザ端末にコンテンツを配信するためのシステムであって、コンテンツを提供しているサービス提供部にコンテンツの配信を求める要求があった場合、通信ネットワークに接続された複数のユーザ端末のうち、要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する判定手段と、存在しないと判定された場合、要求されたコンテンツをコンテンツ・データベースから取得して要求元のユーザ端末へ配信する配信手段と、存在すると判定された場合、キャッシュを保有するユーザ端末のうちから１または複数のユーザ端末を選択する選択手段と、選択された１または複数のユーザ端末と、要求元のユーザ端末との間にP2P通信を形成し、P2P通信によって、選択された１または複数のユーザ端末から要求元のユーザ端末へ要求されたコンテンツを配信させる制御手段と、を備えるシステムである。
【００１７】
また、この発明の第１の観点はさらに以下のような態様を備えることを特徴とする。  
すなわち、要求されたコンテンツのキャッシュを保有しているユーザ端末に関するキャッシュ情報を管理する管理手段をさらに備える。さらに、判定手段は、キャッシュ情報に基づき、要求されたコンテンツのキャッシュを保有するユーザ端末が存在するか否かを判定する。
【００１８】
また、ＮＡＴ／ＦＷを超えて通信ネットワークに接続された複数のユーザ端末を接続するための機能を有するＷｅｂＲＴＣを使用するためのWebRTC PF 利用者識別子を登録する登録手段をさらに備える。さらに、制御手段は、登録されている選択された１または複数のユーザ端末のWebRTC PF 利用者識別子に基づき、P2P通信を形成する。
【００１９】
また、この発明の第１の観点には、同様な構成要素および態様を備える方法およびプログラムも含まれる。
【発明の効果】
【００２０】
すなわちこの発明によれば、ユーザ端末にプラグインや専用アプリケーションのインストールを求めることなく、キャッシュサーバを用いたＣＤＮを利用する場合と同様な効果を得ることができるコンテンツ配信を実現するためのシステム、方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態のコンテンツ配信システムの構成例を示す概念図。
【図２】要求されるコンテンツのキャッシュを保有するユーザが存在しない場合に、本実施形態のコンテンツ配信システムによってなされる処理シーケンスの例。
【図３】要求されるコンテンツのキャッシュを保有するユーザが存在する場合に、本実施形態のコンテンツ配信システムによってなされる処理シーケンスの例。
【図４】本実施形態のコンテンツ配信システムのＷｅｂＲＴＣ  ＰＦ部に格納されるＩＤ管理用データベース構造の例。
【図５】本実施形態のコンテンツ配信システムのキャッシュ情報を示すデータベース構造の例。
【図６】従来のコンテンツ配信システムを示す図。
【発明を実施するための形態】
【００２２】
以下、図面を参照してこの発明に係わる実施形態を説明する。  
図１は、本発明の実施形態のコンテンツ配信システムの構成例を示す概念図である。本発明のコンテンツ配信システム１２は、ＷｅｂＲＴＣ  ＰＦ部１３、ユーザ情報管理部１４、サービス提供部１５、およびコンテンツ情報管理部１６から構成され、例えばインターネットやキャリア網のような通信ネットワーク１０を介してユーザ端末１１（＃１）、・・・、１１（＃ｎ）にコンテンツを配信する。
【００２３】
この構成は、図６のような一般的なコンテンツ配信サービスシステムの構成のコンテンツキャッシュ管理部６０の代わりに、 ＷｅｂＲＴＣ  ＰＦ部１３とコンテンツ情報管理部１６を有している。コンテンツ情報管理部１６は、コンテンツのキャッシュをどのユーザ端末が保有しているかを管理し、コンテンツを保有する複数のユーザ端末１１（＃１）、・・・、１１（＃ｎ）の中から実際にコンテンツをダウンロードするユーザ端末（例えばユーザ端末１１（＃１）とする）を選出する。ＷｅｂＲＴＣ  ＰＦ部１３は、コンテンツを要求したユーザ端末（例えばユーザ端末１１（＃ｎ）とする）とコンテンツ情報管理部１６で選出したコンテンツを保有するユーザ端末１１（＃１）間でＰ２Ｐ通信を実現するためのアシストを行う。そのため、何れのユーザ端末１１もプラグイン、専用アプリケーション等をインストールする必要なく、キャッシュサーバを用いた従来のＣＤＮと同様な効果を得ることができる。なお、ユーザ端末１１（＃１）、・・・、１１（＃ｎ）の各々は、コンテンツキャッシュ機能を有するブラウザを備えている。
【００２４】
ユーザ情報管理部１４は、ユーザ認証機能２４とユーザ情報ＤＢ２５を有し、登録ユーザと未登録の匿名ユーザの両方に対応する。ユーザ認証機能２４は、ユーザ情報ＤＢ２５に予め登録されたユーザの情報に基づき、ユーザの認証を行い、登録ユーザであると判定した場合、認証キーの発行を行う。一方で、ユーザ認証機能２４は、ユーザ情報ＤＢ２５に予め登録されたユーザの情報に基づき、未登録の匿名ユーザであると判定した場合、未登録の匿名ユーザが保有するコンテンツのキャッシュの保有状態を把握するために、一時的なユーザ識別子を払い出す。例えば、ユーザ情報管理部１４は、未登録の匿名ユーザに一時的なユーザ識別子を割り当てる。なお、この際、ユーザがブラウザを閉じる等によりＰ２Ｐ等の通信ネットワーク１０から離脱し、ユーザ端末１１と通信ネットワーク１０との接続が解除した場合、未登録の匿名ユーザに付与した一時的なユーザ識別子はリセットされる。
【００２５】
サービス提供部１５は、コンテンツに関する情報を提供するＷｅｂページ等をホストするＷｅｂサーバ機能２６と、全コンテンツが蓄積されているコンテンツＤＢ２７を有し、ユーザ端末１１からの配信要求に対して要求されるコンテンツを提供する。
【００２６】
コンテンツ情報管理部１６は、コンテンツキャッシュ管理機能２８、キャッシュ情報ＤＢ２９を備え、コンテンツのキャッシュをどのユーザが保有しているかを管理し、コンテンツを保有する複数のユーザ１１（＃１）、・・・、１１（＃ｎ）の中からコンテンツをダウンロードするユーザ端末１１を選出する。また、コンテンツキャッシュ管理機能２８は、コンテンツを要求するユーザのユーザ端末１１へ、要求されたコンテンツを配信する１または複数のユーザ端末を選択する。
【００２７】
ＷｅｂＲＴＣ  ＰＦ部１３は、ＩＣＥ機能１７、シグナリング機能１８、ＷｅｂＲＴＣ利用者ＤＢ１９、サービス認証機能２０、サービス事業者ＤＢ２１、ＩＤ管理機能２２、およびＩＤ管理ＤＢ２３を備える。ＩＣＥ機能１７は、ＳＴＵＮとＴＵＲＮを組み合わせ、ＮＡＴ／ＦＷを通過するための機能を有する。シグナリング機能１８は、通信ネットワーク１０に接続されている、ユーザ端末１１同士をSDP（Session Description Protocol）を用いてIPアドレスや通信するための基本情報（コーデック等）を交換する。ＷｅｂＲＴＣ利用者ＤＢ１９は、ユーザ端末１１のＩＰアドレスを管理し、ユーザ端末１１からの要求に応じて、通信相手のＩＰアドレスを検索する。サービス認証機能２０は、ＷｅｂＲＴＣ  ＰＦを使用できるサービス事業者（例：コンテンツ配信事業者、Ｍ２Ｍ事業者、ゲーム事業者等）の情報を管理する。サービス事業者ＤＢ２１は、ＷｅｂＲＴＣ  ＰＦを使用できるサービス事業者の情報を格納している。ＩＤ管理機能２２は、サービス事業者が管理しているＩＤとＷｅｂＲＴＣを使用するためのＩＤをマッピングする。ＩＤ管理ＤＢ２３は、サービス事業者が管理しているＩＤとＷｅｂＲＴＣを使用するためのＩＤのリストを管理する。
【００２８】
このようなＷｅｂＲＴＣ  ＰＦ部１３によって、コンテンツを要求したユーザ端末１１（例えば、ユーザ端末１１（＃ｎ））とコンテンツ情報管理部１６で選出したコンテンツを保有するユーザ端末１１（例えば、ユーザ端末１１（＃１））間でＰ２Ｐ通信を可能とする。
【００２９】
なお、これらのサーバ／データベース／アプリケーションは独立したエンティティとして記載を行ったが、いずれの組み合わせにおいても同一エンティティとしての実装を制限するものではない。
【００３０】
また、この通信ネットワーク１０は、イーサネット(登録商標)等のＬＡＮ、あるいは公衆回線や専用回線を介して複数のＬＡＮが接続されるＷＡＮ等からなる。ＬＡＮの場合には、必要に応じてルータを介した多数のサブネットから構成される。また、ＷＡＮの場合には、公衆回線に接続するためのファイアウォール等を適宜備えているが、ここではその図示及び詳細説明を省略する。
【００３１】
また、本実施形態のコンテンツ配信システム１２は、例えば、磁気ディスク等の記録媒体に記録されたプログラムや、インターネット等の通信ネットワーク１０を介してダウンロードしたプログラムを読み込み、このプログラムによって動作が制御されるサーバ等のコンピュータによって実現される。
【００３２】
請求項において、コンテンツが蓄積されているコンテンツ・データベースは、コンテンツＤＢ２７に対応する。通信ネットワーク１０に接続された複数のユーザ端末１１（＃１）乃至１１（＃ｎ）のうちの何れかのユーザ端末１１からコンテンツの配信を求める要求があった場合、通信ネットワーク１０に接続された複数のユーザ端末１１（＃１）乃至１１（＃ｎ）のうち、要求されたコンテンツのキャッシュを保有するユーザ端末１１が存在するか否かを判定する判定手段は、コンテンツ情報管理部１６に対応する。存在しないと判定された場合、要求されたコンテンツをコンテンツ・データベースから取得して要求元のユーザ端末１１へ配信する配信手段は、Ｗｅｂサーバ機能２６に対応する。存在すると判定された場合、キャッシュを保有するユーザ端末１１のうちから１または複数のユーザ端末を選択する選択手段は、例えば、Ｗｅｂサーバ機能２６、コンテンツ情報管理部１６、コンテンツキャッシュ管理機能２８に対応する。以下、この選択手段が、Ｗｅｂサーバ機能２６である場合を想定する。選択された１または複数のユーザ端末と、要求元のユーザ端末１１との間にP2P通信を形成し、P2P通信によって、選択された１または複数のユーザ端末から要求元のユーザ端末１１へ要求されたコンテンツを配信させる制御手段は、例えば、Ｗｅｂサーバ機能２６、ＷｅｂＲＴＣ  ＰＦ部１３に対応する。以下、この制御手段が、Ｗｅｂサーバ機能２６である場合を想定する。要求されたコンテンツのキャッシュを保有しているユーザ端末１１に関するキャッシュ情報を管理する管理手段は、コンテンツ情報管理部１６に対応する。ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて通信ネットワーク１０に接続された複数のユーザ端末１１（＃１）乃至１１（＃ｎ）を接続するための機能を有するウェブ・リアルタイム通信（ＷｅｂＲＴＣ）を使用するためのWebRTC PF 利用者識別子を登録する登録手段は、例えば、ＩＤ管理機能２２に対応する。
【００３３】
次に図２を参照して、コンテンツ配信要求時、要求されるコンテンツ（以下、要求コンテンツと称す）のキャッシュを保有するユーザ端末が存在しない場合に、本実施形態のコンテンツ配信システム１２によってなされる処理シーケンスについて説明する。
【００３４】
本実施形態のコンテンツ配信システム１２は、ユーザ端末Ａからのコンテンツ配信要求時に、要求コンテンツのキャッシュを保有するユーザ端末が存在しない場合と、要求コンテンツのキャッシュを保有するユーザ端末が存在する場合とで、処理の流れが異なる。なお、ユーザ端末Ａは、ユーザ端末１１（＃１）乃至１１（＃ｎ）の何れかのユーザ端末である。また、以下、単にユーザ端末と記載した場合、そのユーザ端末は、ユーザ端末１１（＃１）乃至１１（＃ｎ）の何れかのユーザ端末である。Ｗｅｂサーバ機能２６は、ユーザ端末Ａのコンテンツ配信要求時に、要求コンテンツのキャッシュを保有するユーザ端末が存在しない場合、ユーザ端末Ａの配信要求に応じて即時にコンテンツを配信する。一方で、Ｗｅｂサーバ機能２６は、要求コンテンツのキャッシュを保有するユーザ端末が存在する場合、キャッシュを保有するユーザ端末から１または複数のユーザ端末を選出し、コンテンツを提供するユーザ端末とコンテンツを要求したユーザ端末間でＰ２Ｐ通信によりコンテンツを配信させる。
【００３５】
このような処理シーケンスの詳細を以下に説明する。  
始めに、ユーザ端末Ａは、ログインＩＤ、パスワード等のユーザ端末Ａ（例：UserName001）を認証するためのユーザ情報をＷｅｂサーバ機能２６に送信する（ステップＡ−1）。なお、ユーザ端末Ａが匿名ユーザの場合、ステップＡ−１の処理は実施する必要はない。
【００３６】
ユーザ認証機能２４は、ユーザ端末Ａ（例：UserName001）に対応するユーザＡによってユーザ端末Ａを介してＷｅｂサーバ機能２６へ送信されたユーザ情報と、ユーザ情報ＤＢ２５に予め登録されているユーザ端末Ａ（例：UserName001）の認証情報を照合しユーザ端末Ａ（例：UserName001）に対してユーザ認証を行い、ユーザ認証に成功した場合、ユーザ端末Ａに対してユーザ認証キーの発行を行う（ステップＡ−２）。なお、ユーザ認証機能２４は、ユーザ端末Ａが匿名ユーザの場合、ステップＡ−２の処理を実施する必要はない。
【００３７】
次に、Ｗｅｂサーバ機能２６は、ユーザ認証機能２４によって発行されたユーザ端末Ａの認証キーと、コンテンツを配信するサービス事業者を示すサービス事業者識別子（コンテンツ配信事業者の事業者識別ＩＤ等）と、をユーザ端末Ａ（例：UserName001）に通知する（ステップＡ−３）。なお、Ｗｅｂサーバ機能２６は、ユーザ端末Ａが匿名ユーザの場合、認証キーの代わりに、ユーザ端末Ａを一意に識別できる一時的なＩＤをユーザ端末Ａに付与するようにしてもよい。
【００３８】
次に、ユーザ端末Ａは、サービス事業者がユーザ端末Ａ（例：UserName001）を一意に識別するためのユーザ名、サービス事業者識別子、ＷｅｂＲＴＣ  ＰＦを利用するためのＡＰＩ  ｋｅｙ等の情報をシグナリング機能１８に送信し、ＷｅｂＲＴＣ  ＰＦ利用者識別子の発行を要求する（ステップＡ−４）。なお、ここでは、ＡＰＩ  ｋｅｙはユーザ端末Ａによって事前に申請され発行されている場合を想定している。
【００３９】
すると、サービス認証機能２０は、ステップＡ−４でユーザ端末Ａ（例：UserName001）からシグナリング機能１８に送信された情報とサービス事業者ＤＢ２１に予め登録されている情報を照会し、サービス認証を行い、サービス認証に成功した場合、ユーザ端末Ａに対してサービス認証キーの発行を行う（サービス認証）（ステップＡ−５）。
【００４０】
これを受けて、シグナリング機能１８は、サービス認証機能２０で発行されたサービス認証キーと、ＷｅｂＲＴＣ  ＰＦを利用する際にピアを一意に識別するためのＩＤ（以下、WebRTC PF 利用者識別子と称す。）（例：PeerID001）と、をユーザ端末Ａ（例：UserName001）に対して発行し、発行したサービス認証キーとWebRTC PF 利用者識別子をユーザ端末Ａに送信する（ステップＡ−６）。また、ＩＤ管理機能２２は、発行されたWebRTC PF 利用者識別子（例：PeerID001）、ユーザ端末Ａの情報（例：UserName001）、ＩＤの発行時間等をＩＤ管理ＤＢ２３に登録する。なお、ＩＤ管理ＤＢ２３に登録されるＷｅｂＲＴＣ  ＰＦ用ＩＤデータベースの構造については、図４を参照して後述する。
【００４１】
次に、ユーザ端末Ａは、ステップＡ−３で通知されたサービス事業者識別子と、サービス事業者がユーザを一意に識別するためのユーザ名のようなユーザ情報と、ステップＡ−６で通知されたWebRTC PF 利用者識別子（例：PeerID001）をＩＤ管理機能２２に送信する（ステップＡ−７）。
【００４２】
次に、ユーザ端末Ａは、コンテンツを一意に識別するための識別子（例：Contents001）（以下、コンテンツ識別子と称す。）をＷｅｂサーバ機能２６に送信することによって、Ｗｅｂサーバ機能２６に対してコンテンツ配信要求をする（ステップＢ−１）。
【００４３】
Ｗｅｂサーバ機能２６は、コンテンツ識別子に基づき、ユーザ端末Ａ（例：UserName001）が要求するコンテンツを既に取得した他のユーザ端末１１の情報をコンテンツキャッシュ管理機能２８に要求する（ステップＢ−２）。なお、ここでは、ユーザ端末Ａが要求するコンテンツを既に取得したユーザ端末Ｂが存在しない場合を想定しており、ユーザ端末Ａが要求するコンテンツを既に取得したユーザ端末Ｂが存在する場合は、図３に示すステップＣ−１に進む。
【００４４】
ステップＢ−２の後、コンテンツキャッシュ管理機能２８は、ユーザ端末Ａ（例：UserName 001）が要求するコンテンツを既に取得した他のユーザ端末１１が存在しないことをＷｅｂサーバ機能２６に通知する（ステップＢ−３）。例えば、コンテンツキャッシュ管理機能２８は、Ｗｅｂサーバ機能２６にｎｕｌｌを返す。
【００４５】
そのため、Ｗｅｂサーバ機能２６を有するサーバは、ユーザ端末Ａ（例：UserName001）の配信要求に応じて、ユーザ端末Ａが要求するコンテンツをユーザ端末Ａに即時に配信する（ステップＢ−４）。
【００４６】
次に、ユーザ端末Ａ（例：UserName001）は、コンテンツを取得したことをコンテンツキャッシュ管理機能２８に通知する（ステップＢ−５）。その通知を受け、コンテンツキャッシュ管理機能２８は、ユーザ端末Ａがキャッシュを取得した旨をキャッシュ情報ＤＢ２９に登録する。なお、キャッシュ情報ＤＢ２９に登録されるキャッシュ情報データベースの構造については、図５を参照して後述する。
【００４７】
次に図３を参照して、コンテンツ配信要求時、要求コンテンツのキャッシュを保有するユーザ端末が存在する場合に、本実施形態のコンテンツ配信システム１２によってなされる処理シーケンスについて説明する。
【００４８】
なお、ステップＡ−１乃至ステップＡ−7は、図２に示すステップＡ−１乃至ステップＡ−７と同様の処理であり共通するため、その説明を省略する。
【００４９】
ステップＡ−７の後、ユーザ端末Ａ（例：UserName001）は、コンテンツ識別子（例：Contents001）をＷｅｂサーバ機能２６に送信することによって、Ｗｅｂサーバ機能２６に対してコンテンツ配信要求をする（ステップＣ−１）。
【００５０】
次に、Ｗｅｂサーバ機能２６は、コンテンツキャッシュ管理機能２８に対して、ユーザ端末Ａが要求する要求コンテンツのキャッシュ保有ユーザに関する情報を要求する（ステップＣ−２）。
【００５１】
そして、コンテンツキャッシュ管理機能２８は、コンテンツ識別子（例：Contents001）に基づき、ユーザ端末Ａ（例：UserName001）が要求する要求コンテンツを既に取得している他のユーザ端末１１（例：[UserName002，UserName003，…]）の中から１名のユーザに対応するユーザ端末１１を選出し、選出されたユーザ端末Ｂ（例：UserName002）のユーザ情報をキャッシュ情報ＤＢ２９から取得する。なお、複数のユーザ端末１１から１名を選出する方法の例については後述する。また、コンテンツキャッシュ管理機能２８は、要求コンテンツを既に取得している他のユーザ端末１１（例：[UserName002，UserName003，…]）の中から複数のユーザに対応する複数のユーザ端末１１を選出してもよい。
【００５２】
次に、コンテンツキャッシュ管理機能２８は、ユーザ端末Ａ（例：UserName001）の要求コンテンツのキャッシュを保有するユーザ端末Ｂの情報（例：UserName002）をＷｅｂサーバ機能２６に通知する（ステップＣ−３）。そして、ユーザ端末Ａは、Ｗｅｂサーバ機能２６からユーザ端末Ｂの情報を取得する（ステップＣ−４）。
【００５３】
これに応じて、ユーザ端末Ａは、ステップＣ−４で取得したユーザ端末Ｂのユーザ名（例：UserName002）と、サービス事業者識別子と、をＩＤ管理機能２２に送信する（ステップＣ−５）。
【００５４】
そして、ＩＤ管理機能２２は、ユーザ端末Ｂ（例：UserName002）のWebRTC PF 利用者識別子（例：PeerID002）をＩＤ管理ＤＢ２３から取得し、取得したユーザ端末ＢのWebRTC PF 利用者識別子をユーザ端末Ａに通知する（ステップＣ−６）。
【００５５】
次に、ユーザ端末Ａは、ユーザ端末Ｂ（例：UserName002）のICE Candidate（例：UserName002のグローバルＩＰアドレスとポート番号）の取得をＩＣＥ機能１７に要求する（ステップＣ−７）。
【００５６】
ＩＣＥ機能１７は、取得したICE Candidateをユーザ端末Ａに通知する。ユーザ端末Ａは、通知されたICE Candidateを取得する（ステップＣ−８）。
【００５７】
次に、通信路を設定するためにステップＣ−９乃至Ｃ−１２を実行する。具体的には、ユーザ端末Ａは、ステップＣ−８で取得したICE Candidateを基に通信路を設定するためのオファーをシグナリング機能１８を介してユーザ端末Ｂに対して行う（ステップＣ−９、Ｃ−１０）。ユーザ端末Ｂは、通信路を設定するためのアンサーをシグナリング機能１８を介してユーザ端末Ａに対して行う（ステップＣ−１１、Ｃ−１２）。
【００５８】
次に、ユーザ端末Ａとユーザ端末Ｂとの間でＰ２Ｐ通信によるコンテンツデータの送受信を行う。具体的には、ユーザ端末Ａがユーザ端末Ｂに対して、要求コンテンツのダウンロードを要求する（ステップＣ−１３）。ユーザ端末Ａからの要求に応じて、ユーザ端末Ｂが、要求コンテンツをユーザ端末Ａに送信する（ステップＣ−１４）。
【００５９】
次に、ユーザ端末Ａ（例：UserName001）は、要求コンテンツ（例：Contents001）を取得したことをコンテンツキャッシュ管理機能２８に通知し、コンテンツキャッシュ管理機能２８は、キャッシュを取得したユーザ端末Ａの情報をキャッシュ情報ＤＢ２９に登録する（ステップＣ−１５）。
【００６０】
ここで、コンテンツキャッシュ管理機能２８によって行われる、複数のユーザ端末１１のうちの１つ、または複数を選出する方法の例として、以下１）〜７）のアプローチを説明する。
【００６１】
１）コンテンツ取得時間に基づき選出するアプローチ
コンテンツキャッシュ管理機能２８は、キャッシュ情報ＤＢ２９に問い合わせを行い、あるコンテンツ（例：content001）を保有する複数のユーザ端末１１（例：[UserName002, UserName003,…]）の中から、コンテンツの取得時間が一番過去のユーザ端末１１（例：UserName002）を選出する。
２）ランダムに選出するアプローチ
コンテンツキャッシュ管理機能２８は、キャッシュ情報ＤＢ２９から、あるコンテンツ（例：content001）を保有する複数のユーザ端末１１（例：[UserName002, UserName003,…]）から、一様乱数を用いて１名のユーザに対応するユーザ端末１１を選出する。
３）キャッシュヒット率を上げるアプローチ
コンテンツキャッシュ管理機能２８は、キャッシュ情報ＤＢ２９に問い合わせを行い、あるコンテンツ（例：content001）を保有する複数のユーザ端末１１（例：[UserName002, UserName003,…]）から、コンテンツの取得時間が一番最近のユーザ端末１１（例：UserName003）を選出する。
４）Autonomous System（ＡＳ）／Internet Services Provider（ＩＳＰ）間の転送コストを下げるアプローチ
コンテンツキャッシュ管理機能２８は、キャッシュ情報ＤＢ２９に問い合わせを行い、ＩＰアドレス等からＡＳ／ＩＳＰを判定し、コンテンツを要求するユーザ端末１１が属するＡＳ／ＩＳＰと同一のＡＳ／ＩＳＰに属するユーザ端末１１がコンテンツを保有している場合は、そのユーザ端末１１を選出する。コンテンツを要求するユーザ端末１１が属するＡＳ／ＩＳＰと同一のＡＳ／ＩＳＰに属するユーザ端末１１がコンテンツのキャッシュデータを保有していない場合は、コンテンツを要求するユーザ端末１１が属するＡＳ／ＩＳＰに隣接するＡＳ／ＩＳＰに属するユーザ端末１１を選出する。
５）総トラヒック量を減らすアプローチ
コンテンツ配信システム１２は、物理的に一番近いユーザ端末１１からコンテンツを取得する。例えば、コンテンツ配信システム１２は、複数のユーザ端末１１にPingを投げ、RTTの値が一番短いユーザ端末１１を選出する。
６）ダウンロード速度を上げるアプローチ
コンテンツキャッシュ管理機能２８は、キャッシュ情報ＤＢ２９に問い合わせを行い、コンテンツを保有する複数のユーザ端末１１の中から、コンテンツの一部（ピース）を同時並行に取得するためのユーザ端末１１を選出する。
７）ユーザ資源消費の公平性を保つアプローチ
コンテンツキャッシュ管理機能２８は、キャッシュ情報ＤＢ２９に問い合わせを行い、コンテンツ提供回数が一番少ないユーザ端末１１を選出する。
【００６２】
以上、7つの実装例の記載を行ったが、他の方法を制限するものではない。  
次に、図４を参照して、本実施形態のコンテンツ配信システムのＷｅｂＲＴＣ  ＰＦ部１３に格納されるID管理DBのデータベース構造の例について説明する。  
図４に示すように、ＩＤ管理ＤＢ２３の構造４０は、例えば、サービス事業者識別子ａ、ユーザ名ｂ、ＷｅｂＲＴＣ  ＰＦ利用者識別子ｃ、及びＩＤ割当時間ｄのフィールドを有する。
【００６３】
サービス事業者識別子ａは、各ユーザ端末１１が契約しているサービス事業者の識別子を示している。例えば、ユーザ端末１１（＃１）（UserName001）、ユーザ端末１１（＃２）（UserName002）、ユーザ端末１１（＃４）（UserName004）、及びユーザ端末１１（＃５）（UserName005）は、サービス事業者（Provider001）と契約しており、ユーザ端末１１（＃３）（UserABC）はサービス事業者（Provider003）と契約している。
【００６４】
ユーザ名bは、各サービス事業者が各ユーザ端末１１を識別するための要素（UserName001、UserName002、UserABC、・・・）を有する。
【００６５】
ＷｅｂＲＴＣ  ＰＦ利用者識別子ｃは、ＷｅｂＲＴＣ  ＰＦを利用する際にピアを一意に識別するためのＩＤであり、各ユーザ端末１１に対して１つのWebRTC PF 利用者識別子が関連づけられている。WebRTC PF 利用者識別子は、ID管理DBの中でユニークである必要がある。
【００６６】
ＩＤ割当時間ｄは、WebRTC PF 利用者識別子がユーザ端末１１に割り当てられた時刻を示している。  
次に、図５を参照して、本実施形態のコンテンツ配信システムのキャッシュ情報ＤＢ２９を示すデータベース構造の例について説明する。  
図５に示すように、キャッシュ情報データベース５０は、例えば、コンテンツ情報ｅ、コンテンツキャッシュ保有ユーザ情報ｆ、コンテンツ取得時間ｇ、及びコンテンツ提供回数ｈのフィールドを有する。
【００６７】
コンテンツ情報ｅは、コンテンツを一意に識別するための識別子等に関する情報である。  
コンテンツキャッシュ保有ユーザ情報ｆは、コンテンツのキャッシュを保有するユーザ端末１１（例えば、ユーザ端末Ｂ）に関する情報である。また、コンテンツキャッシュ保有ユーザ情報ｆは、ユーザ名ｆ１、及びＩＰアドレスｆ２等のフィールドを有する。ユーザ名ｆ１は、各ユーザ端末１１を識別可能な異なる要素（例えば、UserName002、UserName003、及びUserName005、・・・）を有する。各ユーザ名ｆ１は、コンテンツ情報ｅと関連づけられている。例えば、図５に示すように、UserName002 及びUserName003は、Content001と関連づけられており、UserName002 及びUserName003に対応するユーザ端末１１（＃２）およびユーザ端末１１（＃３）がContent001に対応するコンテンツのキャッシュを保有していることを示している。また、図５に示すContent003のようにContent003を保有しているユーザ端末１１が存在しない場合は、Content003に対応するユーザ名ｆ１の要素はｎｕｌｌである。ＩＰアドレスｆ２は、各ユーザ名ｆ１に対応するユーザ端末１１のＩＰアドレスに関する情報を示している。また、コンテンツキャッシュ保有ユーザ情報ｆは、ユーザ名ｆ１、ＩＰアドレスｆ２に限らず、その他の必要なフィールドを適宜設けるようにしてもよい。
【００６８】
コンテンツ取得時間ｇは、各コンテンツ情報ｅに対応するコンテンツがユーザ端末１１によって取得された時刻を示している。例えば、Content002に対応するコンテンツを取得した複数のユーザ端末１１のうちUserName002に対応するユーザ端末１１（＃２）は UserName005に対応するユーザ端末１１（＃５）よりも先に（過去に）Content001に対応するコンテンツを取得していることを示している。
【００６９】
コンテンツ提供回数ｈは、コンテンツのキャッシュを保有しているユーザ端末１１（例えば、ユーザ端末Ｂ）が他のユーザ端末１１（例えば、ユーザ端末Ａ）にコンテンツを提供した回数を示している。例えば、Content001に対応するコンテンツのキャッシュを保有する複数のユーザ端末１１のうち、UserName002に対応するユーザ端末１１（＃２）は、コンテンツ取得時間ｇによって、UserName003に対応するユーザ端末１１（＃３）よりも先にコンテンツを先に取得していることが明らかである。そして、このように、コンテンツ取得時間ｇがUserName002に対応するユーザ端末１１（＃２）よりも最近であるUserName003に対応するユーザ端末１１（＃３）のコンテンツ提供回数ｈは、UserName002に対応するユーザ端末１１（＃２）のコンテンツ提供回数ｈよりも多いことを示している。
【００７０】
以上のような本実施形態によって、次のような効果を得ることができる。  
コンテンツ配信事業者は、コンテンツ配信のための専用のキャッシュサーバを設置する必要なく、且つ、Ｐ２Ｐ通信を伴うアプリケーションの開発やＮＡＴ／ＦＷのためのＩＣＥサーバ、シグナリングサーバ等を用意することなく、ＣＤＮと同様な効果、すなわち、コンテンツを配信するサーバの負荷の低減を達成することが可能となる。
【００７１】
また、通信事業者は、コンテンツキャッシュ管理機能２８を通信事業者自身が持つ構成であった場合、ネットワークの状況（例えば、経路構成、ネットワーク資源の使用状況）を考慮したコンテンツ配信が可能となる。このように、コンテンツ配信におけるトラヒックを管理することで、冗長なトラヒックを削減することが可能となる。
【００７２】
また、ユーザは、サービスを利用するために、プラグインやアプリケーションのインストールが不要となり、即時にサービスを利用できるようになる。また、アプリケーションをインストールする必要がないため、アプリケーションのアップデートに伴う作業等を行う必要もなくなり、アプリケーションのバージョンが異なることによる不具合を気にする必要がなくなるので、ユーザの使い勝手を格段に向上させることが可能となる。
【００７３】
なお、この発明は上記実施形態に限定されるものではない。例えば、図１に示すような、ＷｅｂＲＴＣ  ＰＦ部１３、ユーザ情報管理部１４、サービス提供部１５、およびコンテンツ情報管理部１６のうちの何れか複数を、適宜１つのエンティティで構成するようにしたり、または、さらに多くのエンティティで構成してもよい。また、例えば、ＷｅｂＲＴＣ  ＰＦ部１３、ユーザ情報管理部１４、サービス提供部１５、およびコンテンツ情報管理部１６の各々が有するデータベースを適宜統合したり、あるいは、さらに分散することによって、コンテンツ配信システム１２を実現してもよい。
【００７４】
その他、図４及び図５は、各データベースの一例であり、適宜、フィールドを追加することができるため、図４及び図５等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【００７５】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００７６】
１０…通信ネットワーク、１１・・・ユーザ端末、１２…コンテンツ配信システム、１３…ＷｅｂＲＴＣ  ＰＦ部、１４…ユーザ情報管理部、１５…サービス提供部、１６…コンテンツ情報管理部、１７・・・ＩＣＥ機能、１８・・・シグナリング機能、１９・・・ＷｅｂＲＴＣ利用者ＤＢ、２０…サービス認証機能、２１・・・サービス事業者ＤＢ、２２・・・ＩＤ管理機能、２３・・・ＩＤ管理ＤＢ、２４・・・ユーザ認証機能、２５・・・ユーザ情報ＤＢ、２６・・・Ｗｅｂサーバ機能、２７・・・コンテンツＤＢ、２８・・・コンテンツキャッシュ管理機能、２９・・・キャッシュ情報ＤＢ、４０・・・ＷｅｂＲＴＣ  ＰＦ用ＩＤデータベース、５０・・・キャッシュ情報データベース、６０・・・コンテンツキャッシュ管理部、６１・・・サービス提供部、６２・・・ユーザ情報管理部、６３・・・キャッシュＤＢ、６４・・・コンテンツキャッシュ機能、６９・・・ユーザ情報ＤＢ、７０・・・ユーザ認証機能、７１・・・コンテンツＤＢ、７２・・・・Ｗｅｂサーバ機能。
【図１】
2016051389.tif 000003
【図２】
2016051389.tif 000004
【図３】
2016051389.tif 000005
【図４】
2016051389.tif 000006
【図５】
2016051389.tif 000007
【図６】
2016051389.tif 000008