コンテンツ配信システム
【課題】
IP放送のような大規模なストリーム配信サービスは、コンテンツ配信サーバの配信効率を上げるため一般的にUDP(User Datagram Protocol)を使うことが多い。UDPでは基本的に送ったパケットが相手に届いたかどうかは送信側には分からない。このような場合、受信機から視聴不可コンテンツ受信の通知を受けた際には課金を行わない仕組みが必要である。
【解決手段】
本発明は、送ったデータパケットが通信相手に届いたか否かが分からない通信プロトコルを用いてコンテンツのストリーム配信を行う際、受信機側でロスパケット数やバッファオーバーフローの発生状態等を監視し、ある一定の基準値を超えた場合は、視聴に耐えられないと判定し、該コンテンツ配信サービスに対する課金を行わないコンテンツ配信処理を行うように構成した。これによりサービス利用者に不適切なストリームコンテンツを有料配信しないことを保証することができる。
IP放送のような大規模なストリーム配信サービスは、コンテンツ配信サーバの配信効率を上げるため一般的にUDP(User Datagram Protocol)を使うことが多い。UDPでは基本的に送ったパケットが相手に届いたかどうかは送信側には分からない。このような場合、受信機から視聴不可コンテンツ受信の通知を受けた際には課金を行わない仕組みが必要である。
【解決手段】
本発明は、送ったデータパケットが通信相手に届いたか否かが分からない通信プロトコルを用いてコンテンツのストリーム配信を行う際、受信機側でロスパケット数やバッファオーバーフローの発生状態等を監視し、ある一定の基準値を超えた場合は、視聴に耐えられないと判定し、該コンテンツ配信サービスに対する課金を行わないコンテンツ配信処理を行うように構成した。これによりサービス利用者に不適切なストリームコンテンツを有料配信しないことを保証することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、視聴者の要求に応じて、インターネット等の通信ネットワークを介してコンテンツのストリーム配信を行うコンテンツ配信システム、コンテンツ配信方法およびコンテンツ配信プログラムに関する。
【背景技術】
【０００２】
近年、通常のテレビ放送だけではなく、見たい時に見たいタイトルを楽しむことが可能なビデオオンデマンド（ＶＯＤ）サービスが広まりつつある。また、放送局が放送電波の代わりにインターネットを通じて放送番組を配信するＩＰ放送サービスも開始される。このような、VODサービスやIP放送は、サービス事業者の配信サーバが、音楽や動画映像などのＡＶメディアコンテンツファイルを先頭から順次１パケットづつデータ送信し、それを視聴者の受信機（クライアント）が受信することにより実現されるが、その際、一般的に、コンテンツファイル全体が受信機に配信し終わるのを待たず、受信しながら再生視聴することを、ストリーム配信あるいはストリーミングと呼ぶ。これに対し、全てのコンテンツデータを受信し、受信機内の記憶装置に一旦蓄積してから改めて再生する場合はダウンロードの用語が使用されることが多い。
【０００３】
上記ストリーミングによるコンテンツ配信において、視聴者が視聴できるコンテンツは利用する通信回線や受信機の性能により制限される。ストリーミングの際、映像コンテンツは配信サーバによりネットワーク上にデータパケットとして送出され、一般的にルータやスイッチングハブ等の機器を経由して受信機まで届き、受信機内に取り込まれて再生装置に送られて視聴可能な映像へと変換されるが、その１秒当たりのデータ転送容量はビットレートと呼ばれ、各々のコンテンツファイルに固有の値である。この値が大きいほど動画映像の解像度や滑らかさ等の品質が高くなるが、視聴のためのデータ受信に必要な利用帯域は大きくなる。視聴者の利用しているネットワーク環境や受信機の利用可能な帯域が、コンテンツのビットレートよりも大きければ問題なく該コンテンツの再生が可能だが、利用可能な帯域の方が小さい場合、データが受信機まで届かなかったり、受信機内部での再生処理が間に合わなかったりして映像が乱れ飛び、その程度がひどくなると視聴不可能となる。
【０００４】
さらにネットワークを使ったデータパケットの配信では、一般的にサーバが送り出したビットレートでデータが受信機に届くことはなく、途中経由するルータやハブ等の機器の特性により、あるときは非常に高いビットレートで受信し、ある時は途切れるなど、データの到着にばらつきが出る。またパケットが入れ替わって到着したりもする。
特に、無線を使ったモバイル端末などの場合、受信可能な帯域は時と場合により変わってしまう。つまり、受信機の処理能力が一定でも、中継するルータやハブの数や性能が変化する上、周囲の無線環境も時々刻々変わる。このため、同じビットレートのコンテンツが場所や時間によって視聴出来たり出来なかったりすることもありうる。
【０００５】
受信機は通常、データパケット受信時に、コンテンツデータをある程度バッファに貯め、時間差を持って再生することにより、再生時にデータ配信のばらつきがユーザに分からないようにする仕組みを搭載している。該バッファに貯める量を大きくすればするほど、コンテンツ受信時のビットレートの変化には対応できるが、受信機に搭載するメモリ量が増えて機器のコストが高くなる上に、各々の視聴者のネットワーク環境により必要なメモリ量が変わるので、一般的に、それほど大きなバッファは搭載しない。これらの事情から、基本的にコンテンツのビットレートよりも大きい帯域を利用可能な視聴者のみ該コンテンツが視聴可能と言える。
【０００６】
このような状況下で、視聴者にコンテンツ再生を保証するため、各々の映像タイトル毎に、帯域毎に異なったビットレートのコンテンツを用意して視聴者に選択させるなどの対策を行う配信システムもある。ただし、実際には素人の視聴者が帯域に応じた適切なコンテンツを選択するのは困難であり、実帯域より大きなビットレートのコンテンツを選択してしまったり、逆に実帯域よりも非常に小さいビットレートのコンテンツを選んでしまうことで、鮮明なコンテンツを快適に視聴できなくなる可能性がある。
【０００７】
そのため、特開２００４−３５７０９３号公報では、本番のコンテンツ配信を行う前に特殊なダミーデータを送出し、その配信時間を測定した後、再生の保障があると判断すればコンテンツ配信サービスを行うシステムが開示されている。
また、特開２００６−６０８０２号公報には、受信機のバッファ占有率を配信サーバに逐次報告し、配信サーバは該バッファ占有率が高くなると利用帯域幅が低いと判定して、ストリーミングのビットレートを、コンテンツのデータパケットから複数のタイプまたはクラスのビデオフレームを除外することにより低下させ、次いで、該バッファ占有率が低くなってくると、その除外されたタイプまたはクラスのビデオフレームをコンテンツデータパケットに再び挿入することによってビットレートを大きくする制御を行う配信方法が開示されている。
【０００８】
【特許文献１】特開２００４−３５７０９３号公報
【特許文献２】特開２００６−６０８０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、IP放送に代表されるような大規模なストリーム配信サービスは、コンテンツ配信サーバの配信効率を上げるため、一般的にＵＤＰ（User Datagram Protocol）を使ってストリーミングを行うことが多い。UDPは基本的に、プロトコル・レベルでは応答を返さず、データパケットを送りっぱなしであり信頼性はない。つまり送ったデータパケットが通信相手に届いたかどうかは送信側には分からず、受信側ではエラーが起これば単にそのパケットを捨ててしまい再送は行わない。
さらにＩＰ放送などでは、マルチキャスト通信による多数の受信機への同時配信、つまり一対多の送受信でストリーム配信を行う。この方式では、コンテンツ配信サーバは基本的に何台の受信機が受信するのか、また各々どの程度の帯域を利用可能なのか、一回の配信ごとに変わってしまう。
【００１０】
上記のような、信頼性のない1対多の通信では、個々の受信機の利用帯域を測定したり、受信機のバッファ占有率に応じて、送信コンテンツのビットレートをリアルタイムで変更するような一対一の送受信を基本とする帯域調整は適用困難である。
視聴者の側からすると、コンテンツが受信機の利用帯域をオーバーしていて映像が乱れていた場合、どの程度我慢して視聴するかは視聴内容や視聴条件により様々である。単に本日の出来事が知りたくて、無料のニュース番組配信であれば、おおよその内容が分かる程度に映像が再生されていればよいということもあり、有料で美しい映像を見るためのストリーム配信サービス利用の場合は、少しの映像の乱れも気になる。逆に言えば、受信機毎に配信コンテンツのビットレート調整を行えない有料ストリーム配信を行うサービスシステムは、受信機から視聴不可コンテンツ受信の通知を受けた際には、そのコンテンツに対する課金を行わない仕組みが、サービスの誠実さとして必要である。
【課題を解決するための手段】
【００１１】
本発明によるコンテンツ配信システムは、コンテンツ配信サーバがストリーム配信を行う際、受信機が受信したコンテンツのデータパケット受信状況から、再生映像の品質が視聴に堪えられるものであるか否かを判定する手段を持ち、該判定手段が視聴に耐えられないと判定したときには、視聴者に該コンテンツのビットレートが受信機の利用可能帯域から外れている警告を出し、さらに該受信中のストリームコンテンツが有料である場合には、コンテンツ配信サーバに対してストリームサービス無効の通知を送る。該無効通知を受け取ったサーバは、当該受信機の視聴者に対する課金処理を行わないことを特徴とする。
【００１２】
具体的には、本発明による受信機は、受信バッファオーバーフローによるデータ受信中断時間がある閾値を超えた場合、及びエラーにより捨てられてしまったロスパケットの数が、ある閾値を超えた場合に、視聴不可能すなわち視聴者は該コンテンツを視聴していないので、当該ストリーミングサービスは無効と判定するように構成される。
【発明の効果】
【００１３】
本発明のコンテンツ配信システムは、送ったデータパケットが通信相手に届いたか否かが分からない通信プロトコルを用いてコンテンツのストリーム配信を行う際、受信機側で、ロスパケット数やバッファオーバーフローの発生状態を監視し、ある一定の基準値を超えた場合は、コンテンツ配信サービスに対する課金を行わない仕組みを設けることにより、視聴者に対して不適切なコンテンツを有料配信しないことを保証することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の実施例について説明する。
図１は本発明のコンテンツ配信システムの例である。ネットワーク１を介してコンテンツ配信サーバ２から、受信機であるネットワーク対応テレビ３に映像コンテンツがストリーミングされる。
ネットワーク１は、様々な従来のインターネットプロトコルのいずれかを使用し、様々な従来のネットワーク物理層（光、有線、または無線ネットワークを含む）のいずれかで実現される通信ネットワークで、インターネット、１つまたは複数のローカルエリアネットワーク（ＬＡＮ：local area network）、広域ネットワーク（ＷＡＮ：wide area network）の一部などである。本例では汎用的なインターネットであるとする。なお、ネットワーク1にはデータパケットを送信元から送信先へ正確に送り届けるためのルータやハブなどの通信制御機器も含まれている。
【００１５】
コンテンツ配信サーバ２は、映像メディアコンテンツを視聴者からの要求に応じて受信機にストリーミングするサービスを行うサービス事業者が運営するサーバシステムである。通常、このようなコンテンツ配信サービスのためのサーバは、コンテンツを蓄積し管理するコンテンツ管理機能やユーザの要求により選択されたコンテンツをストリーミング配信するストリーミング管理機能、サービスのプロモーションやコンテンツのナビゲーションを提供するための情報配信を行い、ユーザが受信機を通じてサービスを利用するのためのユーザインタフェースを提供するポータルサーバ機能、ユーザ登録処理やユーザ毎のサービス利用履歴管理を行う顧客管理機能、ユーザが有料サービスを利用した際の支払い処理等を行う課金・決済管理機能、暗号化コンテンツの復号のための鍵の付与を行うライセンス管理機能、コンテンツをマルチキャストで一度に多数の受信機にストリーム配信するIP放送管理機能、コンテンツをストリーミングではなくダウンロードするダウンロード機能などを備えている。
【００１６】
なお、サービスの提供形態から、これらサービス事業者のサーバには、上述した機能が全て提供されるとは限らず、また上述した機能以外にも様々な機能が入る場合がある。また、物理的に１台のサーバで構成される場合もあり、各種機能毎に分かれた複数台のサーバでサービス提供する場合もある。
【００１７】
受信機はネットワークを経由してコンテンツを受信し、視聴者のために再生するクライアント装置である。本例では、受信機はネットワーク対応のデジタルテレビであるとする。ネットワーク対応テレビの機能構成を図２に示す。
【００１８】
本実施例のネットワーク対応テレビは、放送電波を受信するアンテナやデジタルチューナの他に、ＩＰ（Internet Protocol）データパケットを送受信するためのＩＰ通信ポートを備え、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＤＨＣＰ（Dynamic Host Configuration Protocol）、ＤＮＳ（domain name server）、ＨＴＴＰ(HyperText Transfer Protocol)、ＲＴＰ(Real-time Transport Protocol)、ＲＴＳＰ(Real Time Streaming Protocol)等の各種通信プロトコルとブラウザなどのアプリケーションを搭載しており、該ＩＰ通信ポートでルータ等を介して宅外の公衆回線(インターネット)に接続し、コンテンツ配信サーバ２にアクセスして様々なコンテンツのストリーミングサービスを利用することができる。
【００１９】
本実施例のコンテンツ配信システムでは、コンテンツ配信サーバと受信機間で、HTTPプロトコルを用いて配信するコンテンツの選択等のサービス利用手続きを行い、該手続ききで得られた情報を元に受信機はRTSPプロトコルを用いてストリームの受信要求を行い、RTPプロトコルを用いてサーバからストリームを受信するものとする。なお、勿論サービス使用するプロトコルは、上述に限るものではない。本ネットワーク対応テレビは、RTPプロトコルを使って受信したコンテンツのデータパケットを、放送波と同じデコード処理が可能なようにデータ変換を行った後デコーダに送る。これにより放送と同様にストリームコンテンツの再生視聴が出来る。
【００２０】
次に、図３と図４を参照してコンテンツ配信システムのストリーミング動作を説明する。図３はネットワーク対応テレビ３がコンテンツ配信サーバ２にアクセスしてストリーミング配信されたコンテンツを受信し再生する動作を示すフローチャート、図４はストリーミング配信サービスを行う際のコンテンツ配信サーバ２の動作を示すフローチャートである。
【００２１】
まず、ユーザの指示で、ネットワーク対応テレビはコンテンツ配信サーバの提供するポータルサイトにHTTPブラウザを使ってアクセスする。本実施例では、サーバと受信機関のユーザインタフェースはＨＴＴＰサーバとブラウザで提供されるものとする。また、通常、特に有料のサービスの場合は、利用者及び使用する受信機の情報などを登録する会員登録が行われていないとサービスを利用できないのが普通であり、さらに大抵の場合、不正利用を防止するためサーバに受信機が最初にコネクションを張った際、受信機とサーバの間で互いに正しい相手につながったか否かを判定する機器認証処理が行われる（ステップ１０００、ステップ２０００、２００１）が、本例では会員登録も済ませてあり、機器認証も正しく処理されるものとする（ステップ２００２）。
【００２２】
ネットワーク対応テレビがサーバのポータルサイトに接続すると、ユーザはテレビのブラウザ上でポータルサイト画面に提示された様々な無料・有料ストリーミングサービスのコンテンツメニューから、視聴したいコンテンツを選択可能になる（ステップ１００２、２００３）。そして、ユーザがコンテンツを選択すると、コンテンツ配信サーバは該選択したコンテンツが有料で配信するものか無料なのかを調べる(ステップ２００３，２００４)。もし有料コンテンツであった場合は、ユーザ認証とライセンス処理を行ない（ステップ２００５）、コンテンツのデータパケットを暗号化して配信し、配信終了後に課金決済を行うことになる。ユーザ認証とは、会員登録したユーザに対して、あらかじめ登録されているパスワードを入力させるなどによって正しいユーザであるかを確認し、成りすましなどの不正アクセスを防止するための処理である。
【００２３】
また、ライセンス処理とは、暗号化して配信するコンテンツを復号するためのキーを配信先の受信機にのみ付与することによって、有料コンテンツを支払いに同意した購入者のみ視聴可能にするための処理である。
【００２４】
なお、コンテンツに関する課金の仕組みは様々な形態があり、例えば、該コンテンツを一回ストリーミングする度にある一定額支払う、あるいは、一回目は無料で２度目のストリーミングからは有料になる、あるいは、一定の料金を支払えば何度でもストリーミング可など色々である。従って、課金・決済処理も、利用するユーザの過去のサービス利用の状況によって変わる。つまり例えば、一定の料金を支払えば何度でもストリーミング可能なコンテンツは、既に以前に支払いを行っているユーザへは課金せず、初めて視聴するユーザのみ支払い要求を行うことになる。コンテンツ配信サーバの顧客管理機能は、ユーザ毎のサービス利用・支払い情報を蓄積管理しており、この情報はユーザがサービスを利用する度毎に蓄積更新される。
【００２５】
ネットワーク対応テレビは、コンテンツ復号のキーを受け取って、配信コンテンツ受信・再生の準備が整うと、コンテンツ配信サーバにストリーム開始要求を送り、コンテンツ配信サーバはストリーミングのデータパケット送信を開始し、ネットワーク対応テレビはデータパケット受信を開始する（ステップ１００４、２００６）。なお、この時、ネットワーク対応テレビにおいて、ストリームの正常受信を意味する有効再生フラグはセット状態に初期化されている（ステップ１００４）。
【００２６】
ネットワーク対応テレビは、ストリーミングデータパケットの受信中は（ステップ１００５）、受信バッファのオーバーフローによる受信処理中断時間（ステップ１００６）や、正しく受信し処理できたデータパケット数と、正しく再生処理できずに破棄したロスパケット数のカウント（ステップ１００８，１０１２）を行っている。正しく受信できたデータパケットは配布された復号キーを使って復号処理後デコーダに送られ、一画面ずつ映像が再生表示される（ステップ１００９）。
【００２７】
受信バッファのオーバーフローが起こった場合はステップ１０１３に進み、オーバーフロー状態の継続時間を受信中断時間として、その累積を算出し、該累計値が設定された閾値よりも大きくなった時は、コンテンツのビットレートがネットワーク対応テレビの利用可能帯域を上回っており、視聴が出来ないと判定して、ステップ１０１４でテレビ画面に上記性能不足を示す情報を表示し、もし有功再生フラグがセットされていれば(ステップ１０１５)、該フラグをクリアしてコンテンツ配信サーバに再生視聴不可能なコンテンツであったことを通知する（ステップ１０１６）。なお本例では、ステップ１０１３での判定のための閾値を、オーバーフロー状態の継続累計時間が受信可能だった時間の累計の１／４以上に設定している。
【００２８】
また、コンテンツのビットレートが中継するネットワーク機器の処理性能を上回ったり、ネットワークの通信状態が悪い場合(特に無線を使用している時に起こりやすいが)、受信バッファに取り込まれたデータパケットが壊れたり、受信バッファまで到達しないデータパケットがあるために順番が飛んでしまっていることがある。このようなエラーパケットを受信した際は、ステップ１０１２に進み、受信バッファまで到達しなかったり壊れて廃棄したロスパケットの数を集計する。本例でストリームに使用しているRTPプロトコルは各々のパケットが送信順の通し番号を付けるようになっているため、抜けた番号の数から用意にロスパケット数を計算できる。そして、ロスパケットの数が設定された閾値よりも多くなった場合は、上記オーバーフロー受信中断の場合と同様にステップ１０１５から１０１７の処理を行う。本例の場合、ステップ１０１２での判定のための閾値としてロスパケット数が本来受け取るべきパケット数の１／２以上に設定している。
【００２９】
なお、上記閾値は、コンテンツ配信する毎にサーバが受信機に送って設定する仕組みでもよい。この場合は、コンテンツ配信サーバがストリーム開始前にライセンス処理で復号キーを受信機に付与した際に、一緒に閾値データを受信機に送り、受け取った受信機がセットして使用する。
【００３０】
あるいは、ロスパケット累計数や受信中断累計時間などの測定カウント値をコンテンツ配信サーバに送り、配信サーバ側で基準（閾値）を設け、その値に基づいて無効判定する仕組みでもよい。また、受信中断時間とロスパケット両方を監視するのではなく、どちらか一方でもよい。
コンテンツを最後まで送り終わるか、またはユーザが意図的に停止指示を行うと(ステップ１０１０、２００７)、コンテンツ配信サーバはデータパケット送信を停止し（ステップ２００８）、ネットワーク対応テレビは受信処理を停止する（ステップ１０１１）。
【００３１】
コンテンツ配信サーバは、コンテンツ配信処理終了後、配信先の受信機からサービス無効通知が来ていないかを調べ（ステップ２００９）、サービス無効通知を送ってきていない配信先のユーザには課金・決済管理機能により料金徴収の手続きを行い、同時に該ユーザのサービス利用履歴情報を更新する（ステップ２０１０）。サービス無効通知を送ってきた受信機に対しては、該コンテンツは視聴していないものとして、料金聴取もサービス利用履歴の更新も行わない。
【００３２】
上記で一つのコンテンツストリーミングが終了する。ユーザは更にコンテンツを視聴したい場合はポータルに戻ってコンテンツ選択を行い、（ステップ１０１７、２０１１）ストリーミングを終了する場合はサーバとのアクセスを切断する（ステップ１０１８、２０１２）。
【００３３】
以上のように、本発明では、送ったデータパケットが通信相手に届いたか否かが分からない通信プロトコルを用いてコンテンツのストリーム配信を行う際、受信機側で、ロスパケット数やバッファオーバーフローの発生状態を監視し、ある一定の基準値を超えた場合は、該コンテンツ配信サービスに対する課金を行わない仕組みにより、視聴者に対して不適切なコンテンツを有料配信しないことを保証する。
【図面の簡単な説明】
【００３４】
【図１】コンテンツ配信システムの実施形態の一例を示すブロック図である。
【図２】ネットワーク対応テレビの機能構成を示す図である。
【図３】コンテンツ配信システムのストリーミング動作を説明するフローチャートである。
【図４】ストリーミング配信サービスを行う際のコンテンツ配信サーバの動作を示すフローチャートである。
【符号の説明】
【００３５】
１ ネットワーク
２ コンテンツ配信サーバ
３ 受信機
１１ アンテナ・チューナ
１２ デスクランブラ
１３ デマルチプレクサ
１４ ビデオオーディオデコーダ
１５ メディア記録制御部
１６ ハードディスク
１７ デジタルビデオディスク
１８ 表示画面
１９ スピーカ
２０ ＣＰＵ
２１ リモコンインタフェース部
２２ ＩＰ（インターネットプロトコル）通信ポート
２３ ランダムアクセスメモリ
２４ リードオンリメモリ
２５ グラフィックオーディオエンジン
２６ 映像表示制御部
２７ オーディオ出力制御部
２８ メモリカード
３０ リモコン
１０１ ポータルサイト管理機能
１０２ 顧客管理機能
１０３ 課金決済管理機能
１０４ ライセンス処理機能
１０５ コンテンツ管理機能
１０６ ストリーム管理機能
１０７ ＩＰ放送管理機能
１０８ ダウンロード管理機能
【技術分野】
【０００１】
本発明は、視聴者の要求に応じて、インターネット等の通信ネットワークを介してコンテンツのストリーム配信を行うコンテンツ配信システム、コンテンツ配信方法およびコンテンツ配信プログラムに関する。
【背景技術】
【０００２】
近年、通常のテレビ放送だけではなく、見たい時に見たいタイトルを楽しむことが可能なビデオオンデマンド（ＶＯＤ）サービスが広まりつつある。また、放送局が放送電波の代わりにインターネットを通じて放送番組を配信するＩＰ放送サービスも開始される。このような、VODサービスやIP放送は、サービス事業者の配信サーバが、音楽や動画映像などのＡＶメディアコンテンツファイルを先頭から順次１パケットづつデータ送信し、それを視聴者の受信機（クライアント）が受信することにより実現されるが、その際、一般的に、コンテンツファイル全体が受信機に配信し終わるのを待たず、受信しながら再生視聴することを、ストリーム配信あるいはストリーミングと呼ぶ。これに対し、全てのコンテンツデータを受信し、受信機内の記憶装置に一旦蓄積してから改めて再生する場合はダウンロードの用語が使用されることが多い。
【０００３】
上記ストリーミングによるコンテンツ配信において、視聴者が視聴できるコンテンツは利用する通信回線や受信機の性能により制限される。ストリーミングの際、映像コンテンツは配信サーバによりネットワーク上にデータパケットとして送出され、一般的にルータやスイッチングハブ等の機器を経由して受信機まで届き、受信機内に取り込まれて再生装置に送られて視聴可能な映像へと変換されるが、その１秒当たりのデータ転送容量はビットレートと呼ばれ、各々のコンテンツファイルに固有の値である。この値が大きいほど動画映像の解像度や滑らかさ等の品質が高くなるが、視聴のためのデータ受信に必要な利用帯域は大きくなる。視聴者の利用しているネットワーク環境や受信機の利用可能な帯域が、コンテンツのビットレートよりも大きければ問題なく該コンテンツの再生が可能だが、利用可能な帯域の方が小さい場合、データが受信機まで届かなかったり、受信機内部での再生処理が間に合わなかったりして映像が乱れ飛び、その程度がひどくなると視聴不可能となる。
【０００４】
さらにネットワークを使ったデータパケットの配信では、一般的にサーバが送り出したビットレートでデータが受信機に届くことはなく、途中経由するルータやハブ等の機器の特性により、あるときは非常に高いビットレートで受信し、ある時は途切れるなど、データの到着にばらつきが出る。またパケットが入れ替わって到着したりもする。
特に、無線を使ったモバイル端末などの場合、受信可能な帯域は時と場合により変わってしまう。つまり、受信機の処理能力が一定でも、中継するルータやハブの数や性能が変化する上、周囲の無線環境も時々刻々変わる。このため、同じビットレートのコンテンツが場所や時間によって視聴出来たり出来なかったりすることもありうる。
【０００５】
受信機は通常、データパケット受信時に、コンテンツデータをある程度バッファに貯め、時間差を持って再生することにより、再生時にデータ配信のばらつきがユーザに分からないようにする仕組みを搭載している。該バッファに貯める量を大きくすればするほど、コンテンツ受信時のビットレートの変化には対応できるが、受信機に搭載するメモリ量が増えて機器のコストが高くなる上に、各々の視聴者のネットワーク環境により必要なメモリ量が変わるので、一般的に、それほど大きなバッファは搭載しない。これらの事情から、基本的にコンテンツのビットレートよりも大きい帯域を利用可能な視聴者のみ該コンテンツが視聴可能と言える。
【０００６】
このような状況下で、視聴者にコンテンツ再生を保証するため、各々の映像タイトル毎に、帯域毎に異なったビットレートのコンテンツを用意して視聴者に選択させるなどの対策を行う配信システムもある。ただし、実際には素人の視聴者が帯域に応じた適切なコンテンツを選択するのは困難であり、実帯域より大きなビットレートのコンテンツを選択してしまったり、逆に実帯域よりも非常に小さいビットレートのコンテンツを選んでしまうことで、鮮明なコンテンツを快適に視聴できなくなる可能性がある。
【０００７】
そのため、特開２００４−３５７０９３号公報では、本番のコンテンツ配信を行う前に特殊なダミーデータを送出し、その配信時間を測定した後、再生の保障があると判断すればコンテンツ配信サービスを行うシステムが開示されている。
また、特開２００６−６０８０２号公報には、受信機のバッファ占有率を配信サーバに逐次報告し、配信サーバは該バッファ占有率が高くなると利用帯域幅が低いと判定して、ストリーミングのビットレートを、コンテンツのデータパケットから複数のタイプまたはクラスのビデオフレームを除外することにより低下させ、次いで、該バッファ占有率が低くなってくると、その除外されたタイプまたはクラスのビデオフレームをコンテンツデータパケットに再び挿入することによってビットレートを大きくする制御を行う配信方法が開示されている。
【０００８】
【特許文献１】特開２００４−３５７０９３号公報
【特許文献２】特開２００６−６０８０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、IP放送に代表されるような大規模なストリーム配信サービスは、コンテンツ配信サーバの配信効率を上げるため、一般的にＵＤＰ（User Datagram Protocol）を使ってストリーミングを行うことが多い。UDPは基本的に、プロトコル・レベルでは応答を返さず、データパケットを送りっぱなしであり信頼性はない。つまり送ったデータパケットが通信相手に届いたかどうかは送信側には分からず、受信側ではエラーが起これば単にそのパケットを捨ててしまい再送は行わない。
さらにＩＰ放送などでは、マルチキャスト通信による多数の受信機への同時配信、つまり一対多の送受信でストリーム配信を行う。この方式では、コンテンツ配信サーバは基本的に何台の受信機が受信するのか、また各々どの程度の帯域を利用可能なのか、一回の配信ごとに変わってしまう。
【００１０】
上記のような、信頼性のない1対多の通信では、個々の受信機の利用帯域を測定したり、受信機のバッファ占有率に応じて、送信コンテンツのビットレートをリアルタイムで変更するような一対一の送受信を基本とする帯域調整は適用困難である。
視聴者の側からすると、コンテンツが受信機の利用帯域をオーバーしていて映像が乱れていた場合、どの程度我慢して視聴するかは視聴内容や視聴条件により様々である。単に本日の出来事が知りたくて、無料のニュース番組配信であれば、おおよその内容が分かる程度に映像が再生されていればよいということもあり、有料で美しい映像を見るためのストリーム配信サービス利用の場合は、少しの映像の乱れも気になる。逆に言えば、受信機毎に配信コンテンツのビットレート調整を行えない有料ストリーム配信を行うサービスシステムは、受信機から視聴不可コンテンツ受信の通知を受けた際には、そのコンテンツに対する課金を行わない仕組みが、サービスの誠実さとして必要である。
【課題を解決するための手段】
【００１１】
本発明によるコンテンツ配信システムは、コンテンツ配信サーバがストリーム配信を行う際、受信機が受信したコンテンツのデータパケット受信状況から、再生映像の品質が視聴に堪えられるものであるか否かを判定する手段を持ち、該判定手段が視聴に耐えられないと判定したときには、視聴者に該コンテンツのビットレートが受信機の利用可能帯域から外れている警告を出し、さらに該受信中のストリームコンテンツが有料である場合には、コンテンツ配信サーバに対してストリームサービス無効の通知を送る。該無効通知を受け取ったサーバは、当該受信機の視聴者に対する課金処理を行わないことを特徴とする。
【００１２】
具体的には、本発明による受信機は、受信バッファオーバーフローによるデータ受信中断時間がある閾値を超えた場合、及びエラーにより捨てられてしまったロスパケットの数が、ある閾値を超えた場合に、視聴不可能すなわち視聴者は該コンテンツを視聴していないので、当該ストリーミングサービスは無効と判定するように構成される。
【発明の効果】
【００１３】
本発明のコンテンツ配信システムは、送ったデータパケットが通信相手に届いたか否かが分からない通信プロトコルを用いてコンテンツのストリーム配信を行う際、受信機側で、ロスパケット数やバッファオーバーフローの発生状態を監視し、ある一定の基準値を超えた場合は、コンテンツ配信サービスに対する課金を行わない仕組みを設けることにより、視聴者に対して不適切なコンテンツを有料配信しないことを保証することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の実施例について説明する。
図１は本発明のコンテンツ配信システムの例である。ネットワーク１を介してコンテンツ配信サーバ２から、受信機であるネットワーク対応テレビ３に映像コンテンツがストリーミングされる。
ネットワーク１は、様々な従来のインターネットプロトコルのいずれかを使用し、様々な従来のネットワーク物理層（光、有線、または無線ネットワークを含む）のいずれかで実現される通信ネットワークで、インターネット、１つまたは複数のローカルエリアネットワーク（ＬＡＮ：local area network）、広域ネットワーク（ＷＡＮ：wide area network）の一部などである。本例では汎用的なインターネットであるとする。なお、ネットワーク1にはデータパケットを送信元から送信先へ正確に送り届けるためのルータやハブなどの通信制御機器も含まれている。
【００１５】
コンテンツ配信サーバ２は、映像メディアコンテンツを視聴者からの要求に応じて受信機にストリーミングするサービスを行うサービス事業者が運営するサーバシステムである。通常、このようなコンテンツ配信サービスのためのサーバは、コンテンツを蓄積し管理するコンテンツ管理機能やユーザの要求により選択されたコンテンツをストリーミング配信するストリーミング管理機能、サービスのプロモーションやコンテンツのナビゲーションを提供するための情報配信を行い、ユーザが受信機を通じてサービスを利用するのためのユーザインタフェースを提供するポータルサーバ機能、ユーザ登録処理やユーザ毎のサービス利用履歴管理を行う顧客管理機能、ユーザが有料サービスを利用した際の支払い処理等を行う課金・決済管理機能、暗号化コンテンツの復号のための鍵の付与を行うライセンス管理機能、コンテンツをマルチキャストで一度に多数の受信機にストリーム配信するIP放送管理機能、コンテンツをストリーミングではなくダウンロードするダウンロード機能などを備えている。
【００１６】
なお、サービスの提供形態から、これらサービス事業者のサーバには、上述した機能が全て提供されるとは限らず、また上述した機能以外にも様々な機能が入る場合がある。また、物理的に１台のサーバで構成される場合もあり、各種機能毎に分かれた複数台のサーバでサービス提供する場合もある。
【００１７】
受信機はネットワークを経由してコンテンツを受信し、視聴者のために再生するクライアント装置である。本例では、受信機はネットワーク対応のデジタルテレビであるとする。ネットワーク対応テレビの機能構成を図２に示す。
【００１８】
本実施例のネットワーク対応テレビは、放送電波を受信するアンテナやデジタルチューナの他に、ＩＰ（Internet Protocol）データパケットを送受信するためのＩＰ通信ポートを備え、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＤＨＣＰ（Dynamic Host Configuration Protocol）、ＤＮＳ（domain name server）、ＨＴＴＰ(HyperText Transfer Protocol)、ＲＴＰ(Real-time Transport Protocol)、ＲＴＳＰ(Real Time Streaming Protocol)等の各種通信プロトコルとブラウザなどのアプリケーションを搭載しており、該ＩＰ通信ポートでルータ等を介して宅外の公衆回線(インターネット)に接続し、コンテンツ配信サーバ２にアクセスして様々なコンテンツのストリーミングサービスを利用することができる。
【００１９】
本実施例のコンテンツ配信システムでは、コンテンツ配信サーバと受信機間で、HTTPプロトコルを用いて配信するコンテンツの選択等のサービス利用手続きを行い、該手続ききで得られた情報を元に受信機はRTSPプロトコルを用いてストリームの受信要求を行い、RTPプロトコルを用いてサーバからストリームを受信するものとする。なお、勿論サービス使用するプロトコルは、上述に限るものではない。本ネットワーク対応テレビは、RTPプロトコルを使って受信したコンテンツのデータパケットを、放送波と同じデコード処理が可能なようにデータ変換を行った後デコーダに送る。これにより放送と同様にストリームコンテンツの再生視聴が出来る。
【００２０】
次に、図３と図４を参照してコンテンツ配信システムのストリーミング動作を説明する。図３はネットワーク対応テレビ３がコンテンツ配信サーバ２にアクセスしてストリーミング配信されたコンテンツを受信し再生する動作を示すフローチャート、図４はストリーミング配信サービスを行う際のコンテンツ配信サーバ２の動作を示すフローチャートである。
【００２１】
まず、ユーザの指示で、ネットワーク対応テレビはコンテンツ配信サーバの提供するポータルサイトにHTTPブラウザを使ってアクセスする。本実施例では、サーバと受信機関のユーザインタフェースはＨＴＴＰサーバとブラウザで提供されるものとする。また、通常、特に有料のサービスの場合は、利用者及び使用する受信機の情報などを登録する会員登録が行われていないとサービスを利用できないのが普通であり、さらに大抵の場合、不正利用を防止するためサーバに受信機が最初にコネクションを張った際、受信機とサーバの間で互いに正しい相手につながったか否かを判定する機器認証処理が行われる（ステップ１０００、ステップ２０００、２００１）が、本例では会員登録も済ませてあり、機器認証も正しく処理されるものとする（ステップ２００２）。
【００２２】
ネットワーク対応テレビがサーバのポータルサイトに接続すると、ユーザはテレビのブラウザ上でポータルサイト画面に提示された様々な無料・有料ストリーミングサービスのコンテンツメニューから、視聴したいコンテンツを選択可能になる（ステップ１００２、２００３）。そして、ユーザがコンテンツを選択すると、コンテンツ配信サーバは該選択したコンテンツが有料で配信するものか無料なのかを調べる(ステップ２００３，２００４)。もし有料コンテンツであった場合は、ユーザ認証とライセンス処理を行ない（ステップ２００５）、コンテンツのデータパケットを暗号化して配信し、配信終了後に課金決済を行うことになる。ユーザ認証とは、会員登録したユーザに対して、あらかじめ登録されているパスワードを入力させるなどによって正しいユーザであるかを確認し、成りすましなどの不正アクセスを防止するための処理である。
【００２３】
また、ライセンス処理とは、暗号化して配信するコンテンツを復号するためのキーを配信先の受信機にのみ付与することによって、有料コンテンツを支払いに同意した購入者のみ視聴可能にするための処理である。
【００２４】
なお、コンテンツに関する課金の仕組みは様々な形態があり、例えば、該コンテンツを一回ストリーミングする度にある一定額支払う、あるいは、一回目は無料で２度目のストリーミングからは有料になる、あるいは、一定の料金を支払えば何度でもストリーミング可など色々である。従って、課金・決済処理も、利用するユーザの過去のサービス利用の状況によって変わる。つまり例えば、一定の料金を支払えば何度でもストリーミング可能なコンテンツは、既に以前に支払いを行っているユーザへは課金せず、初めて視聴するユーザのみ支払い要求を行うことになる。コンテンツ配信サーバの顧客管理機能は、ユーザ毎のサービス利用・支払い情報を蓄積管理しており、この情報はユーザがサービスを利用する度毎に蓄積更新される。
【００２５】
ネットワーク対応テレビは、コンテンツ復号のキーを受け取って、配信コンテンツ受信・再生の準備が整うと、コンテンツ配信サーバにストリーム開始要求を送り、コンテンツ配信サーバはストリーミングのデータパケット送信を開始し、ネットワーク対応テレビはデータパケット受信を開始する（ステップ１００４、２００６）。なお、この時、ネットワーク対応テレビにおいて、ストリームの正常受信を意味する有効再生フラグはセット状態に初期化されている（ステップ１００４）。
【００２６】
ネットワーク対応テレビは、ストリーミングデータパケットの受信中は（ステップ１００５）、受信バッファのオーバーフローによる受信処理中断時間（ステップ１００６）や、正しく受信し処理できたデータパケット数と、正しく再生処理できずに破棄したロスパケット数のカウント（ステップ１００８，１０１２）を行っている。正しく受信できたデータパケットは配布された復号キーを使って復号処理後デコーダに送られ、一画面ずつ映像が再生表示される（ステップ１００９）。
【００２７】
受信バッファのオーバーフローが起こった場合はステップ１０１３に進み、オーバーフロー状態の継続時間を受信中断時間として、その累積を算出し、該累計値が設定された閾値よりも大きくなった時は、コンテンツのビットレートがネットワーク対応テレビの利用可能帯域を上回っており、視聴が出来ないと判定して、ステップ１０１４でテレビ画面に上記性能不足を示す情報を表示し、もし有功再生フラグがセットされていれば(ステップ１０１５)、該フラグをクリアしてコンテンツ配信サーバに再生視聴不可能なコンテンツであったことを通知する（ステップ１０１６）。なお本例では、ステップ１０１３での判定のための閾値を、オーバーフロー状態の継続累計時間が受信可能だった時間の累計の１／４以上に設定している。
【００２８】
また、コンテンツのビットレートが中継するネットワーク機器の処理性能を上回ったり、ネットワークの通信状態が悪い場合(特に無線を使用している時に起こりやすいが)、受信バッファに取り込まれたデータパケットが壊れたり、受信バッファまで到達しないデータパケットがあるために順番が飛んでしまっていることがある。このようなエラーパケットを受信した際は、ステップ１０１２に進み、受信バッファまで到達しなかったり壊れて廃棄したロスパケットの数を集計する。本例でストリームに使用しているRTPプロトコルは各々のパケットが送信順の通し番号を付けるようになっているため、抜けた番号の数から用意にロスパケット数を計算できる。そして、ロスパケットの数が設定された閾値よりも多くなった場合は、上記オーバーフロー受信中断の場合と同様にステップ１０１５から１０１７の処理を行う。本例の場合、ステップ１０１２での判定のための閾値としてロスパケット数が本来受け取るべきパケット数の１／２以上に設定している。
【００２９】
なお、上記閾値は、コンテンツ配信する毎にサーバが受信機に送って設定する仕組みでもよい。この場合は、コンテンツ配信サーバがストリーム開始前にライセンス処理で復号キーを受信機に付与した際に、一緒に閾値データを受信機に送り、受け取った受信機がセットして使用する。
【００３０】
あるいは、ロスパケット累計数や受信中断累計時間などの測定カウント値をコンテンツ配信サーバに送り、配信サーバ側で基準（閾値）を設け、その値に基づいて無効判定する仕組みでもよい。また、受信中断時間とロスパケット両方を監視するのではなく、どちらか一方でもよい。
コンテンツを最後まで送り終わるか、またはユーザが意図的に停止指示を行うと(ステップ１０１０、２００７)、コンテンツ配信サーバはデータパケット送信を停止し（ステップ２００８）、ネットワーク対応テレビは受信処理を停止する（ステップ１０１１）。
【００３１】
コンテンツ配信サーバは、コンテンツ配信処理終了後、配信先の受信機からサービス無効通知が来ていないかを調べ（ステップ２００９）、サービス無効通知を送ってきていない配信先のユーザには課金・決済管理機能により料金徴収の手続きを行い、同時に該ユーザのサービス利用履歴情報を更新する（ステップ２０１０）。サービス無効通知を送ってきた受信機に対しては、該コンテンツは視聴していないものとして、料金聴取もサービス利用履歴の更新も行わない。
【００３２】
上記で一つのコンテンツストリーミングが終了する。ユーザは更にコンテンツを視聴したい場合はポータルに戻ってコンテンツ選択を行い、（ステップ１０１７、２０１１）ストリーミングを終了する場合はサーバとのアクセスを切断する（ステップ１０１８、２０１２）。
【００３３】
以上のように、本発明では、送ったデータパケットが通信相手に届いたか否かが分からない通信プロトコルを用いてコンテンツのストリーム配信を行う際、受信機側で、ロスパケット数やバッファオーバーフローの発生状態を監視し、ある一定の基準値を超えた場合は、該コンテンツ配信サービスに対する課金を行わない仕組みにより、視聴者に対して不適切なコンテンツを有料配信しないことを保証する。
【図面の簡単な説明】
【００３４】
【図１】コンテンツ配信システムの実施形態の一例を示すブロック図である。
【図２】ネットワーク対応テレビの機能構成を示す図である。
【図３】コンテンツ配信システムのストリーミング動作を説明するフローチャートである。
【図４】ストリーミング配信サービスを行う際のコンテンツ配信サーバの動作を示すフローチャートである。
【符号の説明】
【００３５】
１ ネットワーク
２ コンテンツ配信サーバ
３ 受信機
１１ アンテナ・チューナ
１２ デスクランブラ
１３ デマルチプレクサ
１４ ビデオオーディオデコーダ
１５ メディア記録制御部
１６ ハードディスク
１７ デジタルビデオディスク
１８ 表示画面
１９ スピーカ
２０ ＣＰＵ
２１ リモコンインタフェース部
２２ ＩＰ（インターネットプロトコル）通信ポート
２３ ランダムアクセスメモリ
２４ リードオンリメモリ
２５ グラフィックオーディオエンジン
２６ 映像表示制御部
２７ オーディオ出力制御部
２８ メモリカード
３０ リモコン
１０１ ポータルサイト管理機能
１０２ 顧客管理機能
１０３ 課金決済管理機能
１０４ ライセンス処理機能
１０５ コンテンツ管理機能
１０６ ストリーム管理機能
１０７ ＩＰ放送管理機能
１０８ ダウンロード管理機能
【特許請求の範囲】
【請求項１】
蓄積した映像コンテンツから視聴者の指定するコンテンツを通信ネットワークを介してストリーム配信するコンテンツ配信サーバと、該コンテンツ配信サーバの配信するストリームのデータパケットを受信し、視聴者が視聴可能な映像として再生する受信機からなるコンテンツ配信システムにおいて、
前記コンテンツ配信サーバが、コンテンツの配信に伴って視聴者に課金する有料コンテンツ配信サービス手段を備え、
前記受信機が、該コンテンツ配信サーバの送信するコンテンツのデータパケットの受信状態を監視し数値記録する受信不良記録手段と、予め設定された閾値と前記不良記録手段の記録する数値を比較して配信されたコンテンツが視聴可能か否かを決めるサービス判定手段と、該サービス判定手段がコンテンツ視聴不可と判定した場合に該コンテンツ配信サーバにサービス無効通知情報を送信する通知手段と、を備え、
前記コンテンツ配信サーバは、サービス無効通知情報を受信した場合に、該当受信機に対するコンテンツストリーム配信に関わる課金を行わないことを特徴とするコンテンツ配信システム。
【請求項２】
前記受信不良記録手段がコンテンツのデータパケットの受信状態として、ロスパケット累計数を数値記録することを特徴とする請求項１記載のコンテンツ配信システム。
【請求項３】
前記受信不良記録手段がコンテンツのデータパケットの受信状態として、受信中断の累計時間を数値記録することを特徴とする請求項１記載のコンテンツ配信システム。
【請求項４】
前記サービス判定手段の閾値は、前記コンテンツ配信サーバからコンテンツ配信開始前に取得し設定することを特徴とする請求項１記載のコンテンツ配信システム。
【請求項１】
蓄積した映像コンテンツから視聴者の指定するコンテンツを通信ネットワークを介してストリーム配信するコンテンツ配信サーバと、該コンテンツ配信サーバの配信するストリームのデータパケットを受信し、視聴者が視聴可能な映像として再生する受信機からなるコンテンツ配信システムにおいて、
前記コンテンツ配信サーバが、コンテンツの配信に伴って視聴者に課金する有料コンテンツ配信サービス手段を備え、
前記受信機が、該コンテンツ配信サーバの送信するコンテンツのデータパケットの受信状態を監視し数値記録する受信不良記録手段と、予め設定された閾値と前記不良記録手段の記録する数値を比較して配信されたコンテンツが視聴可能か否かを決めるサービス判定手段と、該サービス判定手段がコンテンツ視聴不可と判定した場合に該コンテンツ配信サーバにサービス無効通知情報を送信する通知手段と、を備え、
前記コンテンツ配信サーバは、サービス無効通知情報を受信した場合に、該当受信機に対するコンテンツストリーム配信に関わる課金を行わないことを特徴とするコンテンツ配信システム。
【請求項２】
前記受信不良記録手段がコンテンツのデータパケットの受信状態として、ロスパケット累計数を数値記録することを特徴とする請求項１記載のコンテンツ配信システム。
【請求項３】
前記受信不良記録手段がコンテンツのデータパケットの受信状態として、受信中断の累計時間を数値記録することを特徴とする請求項１記載のコンテンツ配信システム。
【請求項４】
前記サービス判定手段の閾値は、前記コンテンツ配信サーバからコンテンツ配信開始前に取得し設定することを特徴とする請求項１記載のコンテンツ配信システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００８−１５３８００（Ｐ２００８−１５３８００Ａ）
【公開日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願番号】特願２００６−３３７７４０（Ｐ２００６−３３７７４０）
【出願日】平成１８年１２月１５日（２００６．１２．１５）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願日】平成１８年１２月１５日（２００６．１２．１５）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]