特許 5797744 コンテンツ配信方法、コントロールサーバ及びピア装置

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

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

(11)【特許番号】5797744

(24)【登録日】2015年8月28日

(45)【発行日】2015年10月21日

(54)【発明の名称】コンテンツ配信方法、コントロールサーバ及びピア装置

(51)【国際特許分類】

   G06F 13/00 20060101AFI20151001BHJP

   G06F 12/00 20060101ALI20151001BHJP

   H04L 12/70 20130101ALI20151001BHJP

   H04L 12/761 20130101ALI20151001BHJP

   H04W 4/06 20090101ALI20151001BHJP

【ＦＩ】

   G06F13/00 353C

   G06F12/00 545Z

   H04L12/70 F

   H04L12/761

   H04W4/06 170

【請求項の数】14

【全頁数】15

(21)【出願番号】特願2013-509552(P2013-509552)

(86)(22)【出願日】2011年5月10日

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

(43)【公表日】2013年12月5日

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

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

(87)【国際公開日】20111124

【審査請求日】2014年5月9日

(31)【優先権主張番号】10305499.5

(32)【優先日】2010年5月11日

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

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】シャンペル，マリー−リュック

(72)【発明者】

【氏名】ウィークス，ピエール

(72)【発明者】

【氏名】ノイマン，クリストフ

【審査官】 佐々木 洋

(56)【参考文献】

【文献】 国際公開第２０１０／０４４１６１（ＷＯ，Ａ１）

【文献】 国際公開第２００９／１４１２６９（ＷＯ，Ａ１）

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

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

Ｇ０６Ｆ １３／００

Ｈ０４Ｌ １２／００−１２／２６

Ｈ０４Ｌ １２／５０−１２／９５５

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

【請求項1】

コンテンツを保存する少なくとも１つのコンテンツサービング手段とピアに対するコンテンツ配信を制御するコントロールサーバとを有する通信ネットワークに結合されたピアにコンテンツを配信する方法であって、
ｉ）特定されたマルチキャストセッションでコンテンツが間もなく配信されることを通知するメッセージであってピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記コントロールサーバが前記ピアへ送信するステップと、
ｉｉ）特定された前記マルチキャストセッションを少なくとも１つのコンテンツサービング手段により開始し、前記ピアへ前記コンテンツを送信し、前記マルチキャストセッションを監視しているピアが個々のメッセージで特定されている前記コンテンツの一部分を保存するステップと、
ｉｉｉ）コンテンツの少なくとも特定された一部分を求めるコンテンツリクエストを前記コントロールサーバがピアから受信した場合に、少なくとも１つの特定されたマルチキャストコネクションを監視することを促す応答を要求側のピアへ送信し、特定された前記マルチキャストコネクションで要求された前記コンテンツの一部分の送信を開始するようにコマンドリクエストを少なくとも１つのピアへ送信し、要求された前記コンテンツの一部分を保存するステップと
を有する方法。

【請求項2】

コンテンツの一部分の識別子を示すリスト、保存されている前記コンテンツの一部分を特定するために関連するピアが使用しなければならない要素を表すデータ、及び保存されている前記コンテンツの一部分に関連する特定のマーキングを表すデータを少なくとも含む群の中から選択された情報を、前記ｉ）における前記メッセージの各々が含んでいる、請求項１に記載の方法。

【請求項3】

前記ｉｉ）のステップにおいて、前記コントロールサーバは、特定された前記マルチキャストコネクションにおいて選択された回数だけ前記コンテンツが送信されることを要求する、請求項１又は２に記載の方法。

【請求項4】

ｉｖ）前記マルチキャストセッションに参加できていないピアを特定し、特定されたピアと前記コンテンツサービング手段との間にユニキャストコネクションを設定し、各自に関連するコンテンツの一部分を送信するステップを更に有する請求項１−３の何れか１項に記載の方法。

【請求項5】

ｉｖ）以前に配信したコンテンツの部分を要求するために、特定された前記ピアにより生成されたリクエストから、前記マルチキャストセッションに参加できていないピアを特定し、新たに特定されたマルチキャストセッションで前記コンテンツが間もなく配信されることを通知するメッセージであって保存のためにピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記コントロールサーバから特定された前記ピアへ送信し、前記新たに特定されたマルチキャストセッションを開始し前記コンテンツを特定された前記ピアへ再度送信することを前記コンテンツサービング手段に指示するステップを更に有する請求項１−３の何れか１項に記載の方法。

【請求項6】

当初のサイズがｑ個分のパーツに等しいコンテンツを送信する前に、冗長符号化を適用し、最終的なサイズがｆ＋ｑ個分のパーツに等しい符号化コンテンツに変換し、前記ｆ＋ｑ個分のパーツのうち少なくともｑ個分のパーツが受信されれば前記コンテンツの全体を再構築できるようにするステップを更に有する請求項１−５の何れか１項に記載の方法。

【請求項7】

前記ｉｉｉ）のステップにおいて、前記コマンドリクエストは要求された前記コンテンツの一部分が前記特定されたマルチキャストコネクションで送信されなければならない回数を特定している、請求項１に記載の方法。

【請求項8】

前記コントロールサーバは、同じコンテンツの特定された一部分を求めるコンテンツリクエストを、選択された閾値より多い数のピアから受信した場合に前記ｉｉｉ）のステップを実行する、請求項１−７の何れか１項に記載の方法。

【請求項9】

複数のマルチキャストセッションで要求側のピアが特定された前記コンテンツの一部分を受信することに成功した場合に、受信は終了したことを通知するためのメッセージを前記コントロールサーバに送信する、請求項１、７又は８のうち何れか１項に記載の方法。

【請求項10】

要求側のピアの各々が特定されたコンテンツの一部分の受信を終了したことを前記コントロールサーバに通知した場合に、前記コントロールサーバは、前記特定されたコンテンツの一部分を提供している各々のピアへ、各自の送信を止めることを求めるコマンドリクエストを送信する、請求項９に記載の方法。

【請求項11】

前記コントロールサーバが少なくとも特定のコンテンツの一部分を求めるコンテンツリクエストをピアから受信した場合に、前記要求側のピアに送信する前記応答は、前記特定のコンテンツの一部分を現在送信しているピアのリストを含み、前記要求側のピアが監視するマルチキャストコネクションの数を決定する、請求項８−１０の何れか１項に記載の方法。

【請求項12】

当初のサイズがｑ個分のパーツに等しいコンテンツを送信する前に、冗長符号化を適用し、最終的なサイズがｆ＋ｑ個分のパーツに等しい符号化コンテンツに変換し、前記ｆ＋ｑ個分のパーツのうち少なくともｑ個分のパーツが受信されれば前記コンテンツの全体を再構築できるようにする、請求項８−１１の何れか１項に記載の方法。

【請求項13】

コンテンツを保存する少なくとも１つのコンテンツサービング手段を有する通信ネットワークに結合されたピアに対するコンテンツ配信を制御するコントロールサーバであって、
特定されたマルチキャストセッションでコンテンツが間もなく配信されることを通知するメッセージであってピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記ピアへ送信し、
特定された前記マルチキャストセッションを開始し、前記ピアへ前記コンテンツを送信し、前記マルチキャストセッションを監視しているピアが個々のメッセージで特定されている前記コンテンツの一部分を保存するように少なくとも１つのコンテンツサービング手段を指示し、
コンテンツの少なくとも特定された一部分を求めるコンテンツリクエストをピアから受信した場合に、要求された前記コンテンツの一部分を保存するために、少なくとも１つの特定されたマルチキャストコネクションを監視することを促す応答を要求側のピアへ送信し、特定された前記マルチキャストコネクションで要求された前記コンテンツの一部分の送信を開始するようにコマンドリクエストを少なくとも１つのピアへ送信する、コントロールサーバ。

【請求項14】

コンテンツを保存する少なくとも１つのコンテンツサービング手段とピア装置に対するコンテンツ配信を制御するコントロールサーバとを有する通信ネットワークに結合されたピア装置であって、
特定されたマルチキャストセッションでコンテンツが間もなく配信されることを当該ピア装置に通知するメッセージであって当該ピア装置に関連付けられている前記コンテンツの一部分を特定するメッセージを、前記コントロールサーバから受信する手段と、
前記マルチキャストセッションを監視し、当該ピア装置に関連する前記コンテンツの前記一部分を保存する手段と、
別のピア装置からの少なくとも特定された前記コンテンツの一部分を求めるコンテンツリクエストを前記コントロールサーバへ送信する手段と、
少なくとも１つの特定された前記マルチキャストセッションで第２のピア装置からコンテンツの少なくとも特定された部分を受信して保存する手段と、
マルチキャストコネクションを開始することを求めるコマンドリクエストを受信し、前記マルチキャストコネクションで当該ピア装置が保存しているコンテンツの一部分を送信する手段と
を有するピア装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はコンテンツ配信方法、コントロールサーバ及びピア装置等に関連する。

【背景技術】

【0002】

本発明は例えばビデオオンデマンド(VOD)のようなコンテンツ配信に関連し、特にピアツーピア(又はP2P)モードでのコンテンツ配信に関連する。

【0003】

本願において「コンテンツ配信(content distribution)」という用語は、通信ネットワークを通じてアクセス可能な少なくとも1つのコンテンツサービング手段を通じて、当初はサービスプロバイダにより提供されるコンテンツをクライアント(すなわち、ピア)が受信できるようにするサービスを意味する。

【0004】

更に、本願において「コンテンツ」という用語は、特にP2Pモードで配信されることが可能な任意の種類のデータ群を意味し、具体的には、情報データのファイル、ビデオ、ビデオのチャンク、共有する画像、htmlファイル、オーディオファイル及びソフトウェアの更新部分であり、より一般的には任意のタイプのファイルである。

【0005】

更に、本願において「ピア(peer)」という用語は、特にP2Pモードでおそらくは無線通信により他のピア又はネットワーク装置とデータ(又はシンボル(すなわち、データのブロック、パケット又はチャンク))を送受信できる通信装置を意味する。従って、ピアはおそらくは無線による通信インターフェース(又は何らかの等価な通信手段)を有する、コンピュータ、ラップトップ、スマートフォン、固定電話機、移動電話機(セルラ電話機)、パーソナルディジタルアシスタント(PDA)等であってもよく、又は或るエリア(例えば、ブース(又はスローボックス(throwbox))で適宜コンテンツ配信を支援する基地局でもよく、又は(DSL又はケーブルを介して接続されている)ホームゲートウェイ若しくは家庭内施設に設けられたセットトップボックス(STB)のようなコンテンツ受信機でもよい。

【0006】

当業者に知られているように、特にピアツーピア(peer-to-peer：P2P)モードでピア同士の間でコンテンツ配信(又はコンテンツアイテムの配信)を可能にする少なくとも2つの通信アーキテクチャが存在する。

【0007】

第1の通信アーキテクチャは所謂セントラル化されたP2Pアーキテクチャである(例えば、ビットトレント(BitTorrent))。これはセントラルサーバ又は中央サーバを有し、セントラルサーバは、ピア間のユニキャスト通信(又は接続)を管理し、それらの間で(及びそれらの間に限って)コンテンツがやり取りできるようにする。

【0008】

第2の通信アーキテクチャは所謂ハイブリッドP2P/CDN(コンテンツ配信ネットワーク)アーキテクチャである。これは、CNDが一群のコンピュータであること活用し、その一群のネットワークは、ネットワークを通じて接続されかつコンテンツのコピーを保存してピアへのコンテンツ配信を最適化する。従って、CDNは、充分に多くのピアが存在していない(すなわち、接続されていない)場合でも充分速やかにコンテンツがアクセス可能でありかつダウンロード可能であるようにする。後者の場合、CDNは多くのピアにコンテンツのパーツを分散し、セントラルサーバは、各々のピアが他のピアからコンテンツをどのようにしてダウンロードできるかを管理及び制御する。そのようなハイブリッドアーキテクチャの場合、要求する側のピアは、そのピアがダウンロードすることを希望しているコンテンツをセントラルサーバに通知する。そして、セントラルサーバはそのピアに他のピアのリスト(おそらくは、CDNに対するリンクをフィードバックピアとして含む)を送信し、そのリストにより、ピアは想定されている時点で所望のコンテンツを取得できる。そして、要求する側のピアは、全てのピアとの又は選択されたピアとの複数のユニキャスト通信を開始することができ、及び/又は要求されるコンテンツをダウンロードするためにリストに示されているCDNとのユニキャスト通信を開始できる。

【発明の概要】

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

【0009】

ハイブリッドアーキテクチャは良好に機能するが、以下のような欠点もある。

【0010】

＿多くのピアが同じコンテンツ又は異なるコンテンツを要求する場合、多数のユニキャスト通信(又は接続)が形成されなければならない。これは、例えばDSLAM(ディジタル加入者回線アクセスマルチプレクサ)において利用可能な帯域幅を過剰に消費してしまう。

【0011】

＿複数のピアが同一のピア又はCDNの同じコンテンツアイテムを要求する場合、それらは何れも同一のピア又はCDNに対する各自自身のユニキャスト接続を必要とし、要求側のピア各々は、自身のダウンロードを開始できるようになる前に、他の要求側のピアが各自のダウンロードを終了するまで待機しなければならない。これは帯域幅の無駄及びダウンロードの遅延時間を長くしてしまう。

【0012】

＿複数のピアが同一コンテンツの異なる部分、パーツ又はアイテムを要求している場合、それら各々は同一のピアに対するユニキャストコネクションを設定し、従って或るコンテンツアイテム又はパーツは何度も送信されてしまうかもしれない。これも帯域幅の無駄になる。例えば、複数のピアが異なるウィンドウ(又は時間部分)で同じコンテンツを要求する場合、ストリームの時間において他のウィンドウよりも早期に生じるウィンドウに含まれているコンテンツ部分を要求するピアは、以後のウィンドウに含まれている他のコンテンツ部分を受信することによる恩恵を享受できるかもしれない。何れにせよそれらを直ぐにダウンロードしなければならなくなるからである。これは、この方法による恩恵を享受できる機会を増やすが、従来のセントラル化されたP2Pアーキテクチャにおいて事前にチャンクを取得することは、それほど直接的な恩恵をもたらすものではない。

【0013】

従って、多くのピアが同一のコンテンツを求めている場合、上記のアーキテクチャはピア同士の間のユニキャスト通信を前提としているので、極めて処理負担が非常に重くなってしまう。

【0014】

従って、開示される発明の課題は、上記の問題点(又は欠点)を少なくとも部分的に克服することで状況を改善することである。

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

【0015】

開示される発明による方法は、
コンテンツを保存する少なくとも1つのコンテンツサービング手段とピアに対するコンテンツ配信を制御するコントロールサーバとを有する通信ネットワークに結合されたピアにコンテンツを配信する方法であって、
i)特定されたマルチキャストセッションでコンテンツが間もなく配信されることを通知するメッセージであってピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記コントロールサーバが前記ピアへ送信するステップと、
ii)特定された前記マルチキャストセッションを少なくとも1つのコンテンツサービング手段により開始し、前記ピアへ前記コンテンツを送信し、前記マルチキャストセッションを監視しているピアが個々のメッセージで特定されている前記コンテンツの一部分を保存するステップと、
iii)コンテンツの少なくとも特定された一部分を求めるコンテンツリクエストを前記コントロールサーバがピアから受信した場合に、少なくとも1つの特定されたマルチキャストセッションを監視することを促す応答を要求側のピアへ送信し、特定された前記マルチキャストセッションで要求された前記コンテンツの一部分の送信を開始するようにコマンドリクエストを少なくとも1つのピアへ送信し、要求された前記コンテンツの一部分を保存するステップと
を有する方法である。

【図面の簡単な説明】

【0016】

【図1】コントロールサーバ、ピア、コンテンツサーバ及びコンテンツ配信ネットワーク(CDN)が通信ネットワークに接続されている様子を示す図。

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

【0017】

＜発明の概要＞
このため、本発明により提供される第1の方法は、コンテンツを保存する少なくとも1つのコンテンツサービング手段とピアに対するコンテンツ配信を制御するコントロールサーバとを有する通信ネットワークに結合されたピアにコンテンツを配信する方法であって、
i)特定されたマルチキャストセッションでコンテンツが間もなく配信されることを通知するメッセージであってピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記コントロールサーバが前記ピアへ送信するステップと、
ii)特定された前記マルチキャストセッションを少なくとも1つのコンテンツサービング手段により開始し、前記ピアへ前記コンテンツを送信し、前記マルチキャストセッションを監視しているピアが個々のメッセージで特定されている前記コンテンツの一部分を保存するステップと
を有する方法である。

【0018】

本発明による第1の方法は、以下の追加的な特徴を単独に又は組み合わせて使用してもよい。

【0019】

コンテンツの一部分の識別子を示すリスト、保存されている前記コンテンツの一部分を特定するために関連するピアが使用しなければならない要素を表すデータ、及び保存されている前記コンテンツの一部分に関連する特定のマーキングを表すデータを少なくとも含む群の中から選択された情報を、前記i)における前記メッセージの各々が含んでいてもよい。

【0020】

前記ii)のステップにおいて、前記コントロールサーバは、特定された前記マルチキャストセッションにおいて選択された回数だけ前記コンテンツが送信されることを要求してもよい。

【0021】

本方法は、(iii)前記マルチキャストセッションに参加できていないピアを特定し、特定されたピアと前記コンテンツサービング手段との間にユニキャストコネクションを設定し、各自に関連するコンテンツの一部分を送信するステップを更に有していてもよい。変形例において、(iii)以前に配信したコンテンツの部分を要求するために、特定された前記ピアにより生成されたリクエストから、前記マルチキャストセッションに参加できていないピアを特定し、新たに特定されたマルチキャストセッションで前記コンテンツが間もなく配信されることを通知するメッセージであって保存のためにピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記コントロールサーバから特定された前記ピア(Pi)へ送信し、前記新たに特定されたマルチキャストセッションを開始し前記コンテンツを特定された前記ピアへ再度送信することを前記コンテンツサービング手段に指示するステップを更に有してもよい。

【0022】

本方法は、(iv)少なくとも特定されたコンテンツの一部分を求めるコンテンツリクエストを前記コントロールサーバがピアから受信する毎に又は場合に、少なくとも1つの特定されたマルチキャストセッションを監視することを促す応答を要求側のピアに送信し、特定されたマルチキャストセッションで要求されたコンテンツの一部分を送信し始めるようにコマンドリクエストを少なくとも1つのピアへ送信し、要求したコンテンツの一部分を保存するステップを更に有してもよい。

【0023】

前記(iv)のステップにおいて、前記コマンドリクエストは要求された前記コンテンツの一部分が前記指定されたマルチキャストセッションで送信されなければならない回数を特定していてもよい。

【0024】

前記コントロールサーバは、同じコンテンツの特定された一部分を求めるコンテンツリクエストを、選択された閾値より多い数のピアから受信した場合に前記(iv)のステップを実行してもよい。

【0025】

複数のマルチキャストセッションで要求側のピアが特定された前記コンテンツの一部分を受信に成功する毎に又は場合に、受信は終了したことを通知するためのメッセージを前記コントロールサーバに送信してもよい。

【0026】

●要求側のピアの各々が特定されたコンテンツの一部分の受信を終了したことを前記コントロールサーバに通知した場合に、前記コントロールサーバは、前記特定されたコンテンツの一部分を提供している各々のピアへ、各自の送信を止めることを求めるコマンドリクエストを送信してもよい。

【0027】

前記コントロールサーバが少なくとも特定のコンテンツの一部分を求めるコンテンツリクエストをピアから受信する毎に又は場合に、前記特定のコンテンツの一部分を現在送信しているピアのリストを含む応答を要求側のピアに送信し、前記要求側のピアが監視するマルチキャストセッションの数を決定してもよい。

【0028】

当初のサイズがq個分のパーツに等しいコンテンツを送信する前に、冗長符号化を適用し、最終的なサイズがf+q個分のパーツに等しい符号化コンテンツに変換し、前記f+q個分のパーツのうち少なくともq個分のパーツが受信されれば前記コンテンツの全体を再構築できるようにするステップを更に有していてもよい。

【0029】

本発明は これらのコンテンツを保存する少なくとも1つのコンテンツサービング手段とこれらのピアに対するコンテンツ配信を制御するコントロールサーバとを有する通信ネットワークに結合されたピアにコンテンツを配信する方法であって、
iv)コンテンツの少なくとも特定された一部分を求めるコンテンツリクエストを前記コントロールサーバがピアから受信する毎に又は場合に、少なくとも1つの特定されたマルチキャストセッションを監視することを促す応答を要求側のピアへ送信し、特定された前記マルチキャストセッションで要求された前記コンテンツの一部分の送信を開始するようにコマンドリクエストを少なくとも1つのピアへ送信し、要求された前記コンテンツの一部分を保存するステップを有する方法である。

【0030】

本発明による第2の方法は、以下の追加的な特徴を単独に又は組み合わせて使用してもよい。

【0031】

ステップ(iv)において、コマンドリクエストは、要求されたコンテンツの一部分が特定されたマルチキャストコネクションで送信されなければならない回数を特定していてもよい。

【0032】

前記コントロールサーバは、同じコンテンツの特定された一部分を求めるコンテンツリクエストを、選択された閾値より多い数のピアから受信した場合に前記(iv)のステップを実行してもよい。

【0033】

複数のマルチキャストセッションで要求側のピアが特定された前記コンテンツの一部分を受信に成功する毎に又は場合に、受信は終了したことを通知するためのメッセージを前記コントロールサーバに送信してもよい。

【0034】

要求側のピアの各々が特定されたコンテンツの一部分の受信を終了したことを前記コントロールサーバに通知した場合に、前記コントロールサーバは、前記特定されたコンテンツの一部分を提供している各々のピアへ、各自の送信を止めることを求めるコマンドリクエストを送信してもよい。

【0035】

前記コントロールサーバが少なくとも特定のコンテンツの一部分を求めるコンテンツリクエストをピアから受信する毎に又は場合に、前記特定のコンテンツの一部分を現在送信しているピアのリストを含む応答を要求側のピアに送信し、前記要求側のピアが監視するマルチキャストセッションの数を決定してもよい。

【0036】

少なくとも特定のコンテンツの一部分を求めるコンテンツリクエストをピアが前記コントロールサーバへ送信する前に、(i)特定のマルチキャストセッションにより前記コンテンツが間もなく配信されることを通知するメッセージであって各々に関連する前記コンテンツの一部分を特定するメッセージを前記コントロールサーバから前記ピアへ送信するステップと、(ii)少なくとも1つのコンテンツサービング手段により前記特定のマルチキャストセッションを開始し、前記コンテンツを前記ピアへ送信し、前記特定のマルチキャストセッションを監視しているピアが個々のメッセージで特定されている前記コンテンツの一部分を保存するようにするステップを実行してもよい。

【0037】

コンテンツの一部分の識別子を示すリスト、保存されている前記コンテンツの一部分を特定するために関連するピアが使用しなければならない要素を表すデータ、及び保存されている前記コンテンツの一部分に関連する特定のマーキング(marking)を表すデータを少なくとも含む群の中から選択された情報を、前記ステップ(i)における前記メッセージの各々が含んでいてもよい。

【0038】

当該方法は、(iii)前記マルチキャストセッションに参加できていないピアを特定し、特定された前記ピアと前記コンテンツサービング手段との間にユニキャストコネクションを設定し、関連する各自のコンテンツの一部分を送信するステップを更に有していてもよい。

【0039】

変形例において、本方法は、(iii)過去に配信されたコンテンツの一部分を要求するために特定された前記ピアにより生成されたリクエストから、前記マルチキャストセッションに参加できていないピアを特定するステップと、新たな特定のマルチキャストセッションにより前記コンテンツが間もなく配信されることを通知するメッセージであって保存のために各々に関連する前記コンテンツの一部分を特定するメッセージを前記コントロールサーバから前記ピアへ送信するステップと、前記新たな特定のマルチキャストセッションを開始し前記コンテンツを特定された前記ピアへ送信することを前記コンテンツサービング手段に指示するステップとを更に有していてもよい。

【0040】

当初のサイズがq個分のパーツに等しいコンテンツを送信する前に、冗長符号化を適用し、最終的なサイズがf+q個分のパーツに等しい符号化コンテンツに変換し、前記f+q個分のパーツのうち少なくともq個分のパーツが受信されれば前記コンテンツの全体を再構築できるようにしてもよい。

【0041】

本発明により提供されるコントロールサーバは、
コンテンツを保存する少なくとも1つのコンテンツサービング手段を有する通信ネットワークに結合されたピアに対するコンテンツ配信を制御するコントロールサーバであって、
特定されたマルチキャストセッションでコンテンツが間もなく配信されることを通知するメッセージであってピアにそれぞれ関連付けられている前記コンテンツの一部分を特定するメッセージを、前記ピアへ送信し、
特定された前記マルチキャストセッションを開始し、前記ピアへ前記コンテンツを送信し、前記マルチキャストセッションを監視しているピアが個々のメッセージで特定されている前記コンテンツの一部分を保存するように少なくとも1つのコンテンツサービング手段を指示するコントロールサーバである。

【0042】

変形例において、前記コントロールサーバは、コンテンツの少なくとも特定された一部分を求めるコンテンツリクエストをピアから受信する毎に又は場合に、i)少なくとも1つの特定されたマルチキャストセッションを監視することを促す応答を要求側のピアへ送信し、ii)特定された前記マルチキャストセッションで要求された前記コンテンツの一部分の送信を開始するようにコマンドリクエストを少なくとも1つのピアへ送信し、要求された前記コンテンツの一部分を保存してもよい。

【0043】

＜図面に関する説明＞
本発明に関する他の特徴及び利点は、以下の詳細な説明及び添付図面を参照することで更に明らかになるであろう。図面は、本発明によるコントロールサーバが、ピア、コンテンツサーバ及びコンテンツ配信ネットワーク(CDN)が接続されている通信ネットワークに接続されている様子を概略的に示す。

【0044】

＜好適な実施形態の詳細な説明＞
添付図面は発明を充分に規定するだけでなく、必要に応じて定義にも使用されてよいが、本発明は図面の内容に限定されない。

【0045】

本出願は、少なくとも1つのコンテンツサービング手段(CNS，Nj)及びコントロールサーバCTSを含む通信ネットワークCNに結合されたピアPiにコンテンツを配信するように意図された方法を提案する。

【0046】

以下の説明において、コンテンツはピアPiに送信されることが可能なビデオ(又は映像又は画像又は映画)であることが想定されており、ピアPiは、DSL(又は光ファイバ又はその他のケーブル)による通信ネットワークCNを通じてインターネットに接続されるように構成及び配置されている。しかしながら本発明はこの種のコンテンツに限定されない。むしろ本発明は任意のタイプのディジタルコンテンツを想定しており、例えば、オーディオ(又は音楽)ファイル、データファイル、共有する画像又は映像、htmlファイル及びソフトウェアの更新部分等である。

【0047】

更に、以下の説明において、ピアPi(例えば、i＝1ないし4である)は、コンテンツプロバイダのクライアントであるユーザのパーソナルコンピュータ(又はラップトップ)である。しかしながら本発明はそのタイプのピアに限定されない。むしろ、ピアは、コンテンツを保存するメモリ手段MMを有する又はそれに結合されており、かつピアツーピア(P2P)モードで他のピアとの通信を確立することが可能な如何なるタイプのユーザ通信装置であってもよい。従って、ピアPiは、通信モデム(又は等価な通信手段)を有するならば、コンテンツ受信機(例えば、ユーザの家庭内施設に設けられているホームゲートウェイやセットトップボックス(STB)等)、モバイル電話機、セルラ電話機又はパーソナルディジタルアシスタント(PDA)等でもよい。また、ピアが接続される通信ネットワークCNは、例えばビデオオンデマンド(VOD)サービスのようにコンテンツ配信サービスを提供できるならば、(有線でも無線でも)如何なるタイプであってもよい。

【0048】

また、以下の説明において、コンテンツ配信を可能にするインフラストラクチャはハイブリッドP2P/CDN(又はコンテンツ配信(又は分配)ネットワーク)アーキテクチャであることが想定されている。更にインフラストラクチャは、配信されるコンテンツを保存する2つの異なるタイプのコンテンツサービング手段、特に、少なくとも1つのコンテンツサーバCNS及びCDN(すなわち、通信ネットワークCNを介して接続される一群のコンピュータNj)に接続される通信ネットワークCNを含む。これらのコンピュータNj(例えば、j＝1ないし3)は、通信ネットワークCNのキーロケーション(key location)に設けられかつコンテンツサーバCNSに保存されるコンテンツのコピーを保存するノードにより構築され、充分な数のPi(すなわち、通信ネットワークCNに有効に接続されているPi)が存在していなかった場合でも常にこれらのコンテンツが充分速やかにアクセス可能でありかつ受信可能であるようにすることに留意を要する。しかしながら本発明はこのタイプの通信配信インフラストラクチャに限定されない。むしろ本発明はCDNを含む又は含まない任意のタイプのP2Pコンテンツ配信インフラストラクチャを想定している。

【0049】

上述したように、本発明はピアPi同士の間でコンテンツの配信を可能にするように意図された方法を提供することに留意を要する。

【0050】

本発明による方法は、コンテンツ配信インフラストラクチャにより実行されることが可能であり、より具体的には、本発明による制御サーバ又はコントロールサーバCTS及びコンテンツサービング手段(本説明では、コンテンツサーバCNS及びCDNのノードNj)により実行可能である。

【0051】

本発明による第1の方法は少なくとも2つのステップ(i)及び(ii)を有する。

【0052】

第1のステップ(i)はコンテンツcがピアPiに配信されなければならない場合に毎回実行される。

【0053】

本発明の場合、ピアPiに配信される前に、コンテンツcは、ピアPiに関連する複数のパーツ(又は部分又はピース又はその他の適切な用語)p(c)に分割される。重要なことに、同一のコンテンツパートp(c)が複数のピアPiに関連付けられ、P2Pモードでのピア同士の間におけるそのコンテンツパーツp(c)の将来の配信を最適化できるようにする。そのような関連付けはコントロールサーバCTSにより実行又は管理されてもよい。ただし、このことは必須ではない。更に、コンテンツの分割はコントロールサーバCTSにより決定されてもよい。

【0054】

この第1のステップ(i)は、特定のマルチキャストセッション手段によりコンテンツがまもなく配信されることをピアPiに通知するためのメッセージであってそれぞれのピアPiにそれぞれ関連するコンテンツcのパーツp(c)を特定するためのメッセージを生成し、それらのメッセージを制御サーバCTSから通信ネットワークCNを介して関連するピアPiへ送信することを、コントロールサーバCTSが実行することを含む。

【0055】

次回のマルチキャストセッションに関する各々のメッセージは、ユニキャスト接続(又は通信)を通じて関連するピアPiに送信されてもよい。

【0056】

当然に、通信ネットワークCNに有効に接続されているピアPiのみが、コンテンツc及びコンテンツパーツp(c)(ローカルな格納のためにピアにそれぞれ関連付けられている)の将来の配信の通知を受けることができる。

【0057】

重要なことに、ピアPiはコンテンツ全体(コンテンツcの全てのパーツp(c))を保存してもよい。

【0058】

メッセージは、ピアPiに関連付けられているコンテンツパーツp(c)をピアPiが特定できるようにする任意のタイプの情報を含んでもよい。例えば、この情報は、コンテンツパーツp(c)の識別子のリストでもよいし、保存されるコンテンツパーツを特定するために対応するピアPiが使用しなければならない要素又はモジュロ(modulo)を表すデータでもよいし、或いは保存されるコンテンツパーツに関連する特定のマーキング又は情報を表すその他のデータ等でもよい。

【0059】

本発明による方法の第2のステップ(ii)の目標又はゴールは、全てのピアPi(又はほとんどのピアPi)がコンテンツcの少なくとも一部分であるパーツp(c)を有する状態を実現し、(P2P通信において)それらのピアPiにわたって少なくとも一度はコンテンツcの全体が見出されるようにすることである。

【0060】

第2のステップ(ii)は、(ステップ(i)の間にコントロールサーバCTSが決定した)少なくとも1つのコンテンツサービング手段CNS，Njからの特定のマルチキャストセッションを開始し、関連するコンテンツc(すなわち、全てのパーツp(c))をピアPiへ送信することを含む。これにより、コントロールサーバCTSは、マルチキャストセッションの識別子を含むメッセージであって指定されたマルチキャストセッションを開始するためのアドレス(すなわち、少なくとも1つのコンテンツサービング手段CNS及び/又はNj)の順序を整えるメッセージを生成する。本説明における「識別子(identifier)」は(IP)マルチキャストアドレスを意味する。

【0061】

重要なことに、コンテンツサーバCNSにより又はCDNの少なくとも1つのノードNjにより又は他のコンテンツサーバCNSにより及びCDNの少なくとも1つのノードNjによりコンテンツcはマルチキャストセッションを介してピアPiに送信できることに、留意を要する。

【0062】

また、重要なことに、ステップ(ii)において、コントロールサーバCTSは、特定のマルチキャストコネクションにおいて選択された回数だけコンテンツcが送信されることを要求してもよい。

【0063】

コンテンツcをピアPiに配信する前に、そのコンテンツに冗長符号化を適用し、符号化されたコンテンツc’に変換してもよい。すなわち、送信されるコンテンツcがq個分のパーツに等しい初期サイズを有していたとすると、符号化後の最終的なサイズはf＋q個分のパーツに等しくなる。そのような符号化の場合、最終的なコンテンツcを取得するには、(f＋q個分のパーツのサイズを有する)符号化されたコンテンツc’のうち少なくともq個分のパーツに等しいサイズを有する部分を受信及びデコード(又は復号)するだけでよい。

【0064】

そのような符号化は、同じマルチキャストコネクションを監視できるピアPiの数を増やすことに寄与する。

【0065】

そのような符号化は組織的(systematic)であってもよいし、非組織的(non-systematic)であってもよい。組織的符号化の場合、f＋qのサイズの符号化コンテンツc’のうちqというサイズの部分(通常は開始部分)は、実際にはコンテンツc自体である。従って、受信したコンテンツのうち多くのパーツは既にデコードされているので、これはデコード処理を容易にする(符号化コンテンツc’のうち最初のq個分のパーツは符号化されていないからである)。非組織的符号化の場合、コンテンツの一部分のみにアクセスすることはできない。なぜなら、サイズがqである部分が受信された場合に限ってコンテンツcをデコードできるからである(これらq個のパーツが符号化されているからである)。しかしながらこれはセキュリティ又は安全性等の観点からは有利である。

【0066】

冗長符号化法を使用する場合、コンテンツのどの部分も他の部分より重要であるとは言えない(なぜなら、f＋q個分のパーツを含む符号化コンテンツc’のうち少なくともq個分のパーツを受信しなければならないからである)。これは、変換前にサイズがqであるコンテンツcがX個のパーツ(パーツはq/Xのサイズを有する)に分割される場合、符号化されたコンテンツc’は(1+f/q)*X個のパーツに分割されることを意味する(パーツはq/Xのサイズを有する)。従って、f/q個多いパーツが利用可能であり、要求側のピアは、少なくともq個分に等しいサイズの部分を受信するまで、これらの任意のパーツを監視又は待機する。

【0067】

そのような符号化が行われる場合、要求側のピアPiの各々は、自身が保存しているコンテンツcのn個のパーツをコントロールサーバCTSに通知し、コントロールサーバCTSが残りの［(1+f/g)*X-n］個分のパーツを選択できるようにし、要求側のピアがコンテンツcの全体を取得するために監視できるようにする。これは有利である。任意のパーツp(c)が適合しそのようなパーツは送信側のピアから既に現在送信されているからである。

【0068】

当業者に知られている任意のタイプの冗長符号化法が使用されてもよい。

【0069】

(コントロールサーバCTSから到来する受信したメッセージに指定されている)マルチキャストセッションを監視するように決定された接続されているピアPiが、分散したコンテンツc(又は符号化されたコンテンツc’)を受信すると、受信したメッセージで特定されているコンテンツパーツp(c)のみを保存手段MMに保存する。

【0070】

このコンテンツを分散させるモードはネットワークの帯域幅の利用を最小化する。実際、新たなコンテンツの単独の送信により、コンテンツcがP2Pインフラストラクチャ全体に充分に分散されていることが保証される。最初のコンテンツサービング手段(CTS又はCDN)の帯域幅が高価である場合に、ただ1回のマルチキャスト送信を行えばよいことはコスト削減になる。しかしながら、そのようなコンテンツの分散は、分散する段階で接続されているピアPiにとってのみ使用可能である。当初は利用可能でなかったピアPi’がそれらに関連するコンテンツパーツp(c)を受信できるようにするため、本発明はステップ(ii)の後に第3のステップ(iii)を実行することを提案する。

【0071】

ステップ(iii)は、マルチキャストセッションに参加できていないピアPi’を特定し、特定されたそれらのピアPi’と関連するコンテンツサービング手段CNS及び/又はNj各々との間にユニキャストコネクションを確立し、それら各自に関連するコンテンツパーツp(c)をそれらに送信することを含む。

【0072】

変形例において、ステップ(iii)は、マルチキャストセッションに参加できていないピアPi’を特定し、コンテンツcが(新たな)特定されたマルチキャストセッションによりまもなく分配されることを通知するためのメッセージであってそれらを保存する各自に関連するコンテンツパーツp(c)を特定するメッセージを、コントロールサーバCTSから特定されたピアPi’へ送信することを含んでもよい。そして、コントロールサーバCTSは、新たなマルチキャストセッションの識別子を含むメッセージであって、特定された新たなマルチキャストセッションを開始し、特定されたピアPiにコンテンツc全体を(再び)送信するためのアドレス(すなわち、少なくとも1つのコンテンツサービング手段CNS及び/又はNj)の順序を整えるメッセージを生成する。本説明において「識別子」は(IP)マルチキャストアドレスを意味する。

【0073】

ステップ(iii)の双方の変形例において、ピアPi’は、以前に配布されたコンテンツcのパーツp(c)を要求するために生成してコントロールサーバCTSへ送信したリクエストから特定されてもよい。

【0074】

一旦コンテンツcがP2Pインフラストラクチャにわたって分散されると、ピアPiは各自が保存しているコンテンツパーツp(c)をP2Pモードで各自同士の間で送受信し始める。従来のインフラストラクチャの場合、そのような送受信はピアPiの組の間のユニキャストコネクション(又は通信)によって実行されている。しかしながら本発明はネットワーク帯域幅を最適化するために第2の方法を提案し、第2の方法ではそれらの送受信の少なくとも一部がピア同士の間のマルチキャストコネクション(又は通信)によって実行される。

【0075】

重要なことに、第2の方法は第1の方法(ステップ(i)及び(ii)及び可能ならばステップ(iii))がインフラストラクチャで実行された後に実行されてもよいことに留意を要する。ただし、このことは必須ではない。実際、コンテンツは、第1の方法とは別の方法を利用して、接続されているピアPiに前もって分配されていてもよい。

【0076】

以下の説明において、一例として、第2の方法(又はステップ(iv))はステップ(i)及び(ii)(及び可能ならばステップ(iii))が実行された直後に実行される。

【0077】

本発明による第2の方法は第4のステップ(iv)を有し、第4のステップ(iv)は、ピアPiからコンテンツcの少なくとも特定されたパーツp(c)を取得するためのコンテンツリクエストを要求する毎にコントロールサーバCTSにより実行される。その場合、コントロールサーバCTSは、特定した少なくとも1つのマルチキャストコネクション(のアドレス又はポート番号)を要求側のピアPiが監視又は待機することを促す応答メッセージを要求側のピアPiに送信する。そして、コントロールサーバCTSはコマンドリクエスト(又はメッセージ)を、要求されたコンテンツパーツp(c)を保存している少なくとも1つのピアPi’に送信し、特定したマルチキャストコネクションで、要求されているコンテンツパーツp(c)を送信し始めるように指示する。

【0078】

ステップ(iv)の間に、要求されたコンテンツパーツp(c)が特定されたマルチキャストコネクションにより例えばカルーセルモード(carousel mode)で送信しなければならない回数を、コントロールサーバCTSはコマンドリクエストから特定してもよい。

【0079】

効率の観点から、選択された閾値より多い数のピアPiから同じコンテンツcの特定のパーツp(c)を求めるコンテンツリクエストを受信した場合及びその場合にのみ、コントロールサーバCTSはステップ(iv)を行うだけでもよい。その閾値は例えば2に等しくてもよい。しかしながら閾値は2より大きくてもよい。例えば閾値は4又は5に等しくてもよい。

【0080】

要求されたコンテンツcが1つ以上の送信ピアPi’からマルチキャストリンクで既に配信されていることを、コントロールサーバCTSが検出した場合、コントロールサーバCTSは如何なるコマンドリクエストもそれらの送信ピアPi’に送信する必要はない。例えば、ディジタル加入者回線アクセスマルチプレクサ(Digital Subscriber Line Access Multiplexer：DSLAM)のようなネットワーク装置は、既存のIGMP方式により、要求されたコンテンツを要求側のピアPiに提供することを管理する。

【0081】

更に、要求側のピアPiは複数のマルチキャストコネクションを監視するかもしれないので、複数のマルチキャストコネクションを介して特定されたコンテンツパーツを受信することに成功する毎に、受信が終了したことを示す情報メッセージをコントロールサーバCTSに送信してもよい。その場合、コントロールサーバCTSは、何台の要求側ピアPiが要求したコンテンツcを待機しているかを常に把握している。そのような情報メッセージはコントロールサーバCTSへ送信されなければならない。なぜなら、それと同様な又は置換可能な典型的なIGMP「リーブ(leave)」メッセージは、送信側のピアPi’に送信されかつそれ故にコントロールサーバCTSには決して届かないからである。そして、要求側のピアPi各々が、特定されたコンテンツパーツp(c)の受信が終了したことの通知を受けた場合、このコントロールサーバCTSは、それらの特定されたコンテンツパーツp(c)を提供していた又は現在提供している送信側ピアPi’各々に、マルチキャストコネクションによるその送信を止めるように指示する。

【0082】

更に、コントロールサーバCTSが、コンテンツcの少なくとも特定又は指定されたパーツp(c)を求めるコンテンツリクエストをピアPiから受信する毎に、それら指定されたコンテンツパーツp(c)を現在送信している送信側ピアPi’のリストを含む応答メッセージをその要求側のピアPiに送信してもよい。その場合、要求側のピアPiが、監視又は待機するマルチキャストコネクションの数を自ら決定する。これは、要求側のピアPiが利用可能な同程度の帯域幅或いは許可されているのと同程度の帯域幅を使用できることを意味する。この場合、要求側のピアPiも、監視するストリーム(又はマルチキャストセッション)を通知する特定のメッセージをコントロールサーバCTSに送信し、コントロールサーバCTSが何台のピアPiが所与の送信側ピアPi’を現在監視しているかを常に把握できるようにしてもよい。

【0083】

重要なことに、コンテンツを送信する際に第2の方法においても冗長符号化が使用されてよいことに留意を要する。

【0084】

本発明は上記の方法及びコントロールサーバの実施の形態に限定されず、それらは単なる一例にすぎず、本発明は、添付の特許請求の範囲内で当業者が認識できる全ての形態及び代替例を包含する。

【図1】