(57)【特許請求の範囲】
【請求項１】
通信ネットワークに接続されるユーザ端末と、コンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムであって、
前記コンテンツプロバイダは、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶する手段と、リアルタイムビデオストリームＡを送信した第１のユーザ端末からビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納する手段と、前記ＳＮＳサービスプロバイダから送信されてきた前記ビデオストリームフラグメントＢの閲覧リクエストの通知に応答して格納した前記ビデオストリームフラグメントＢを第２のユーザ端末に送信する手段とを備え、
前記ユーザ端末は、前記第１のユーザ端末として、前記コンテンツプロバイダから送信されてきた前記リアルタイムビデオストリームＡの再生中に前記ビデオストリームフラグメントＢを選択するユーザ入力があると当該ビデオストリームフラグメントＢに関する前記選択信号を前記コンテンツプロバイダに送信する手段と、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記ＳＮＳサービスプロバイダに送信する手段とを備えるとともに、前記第２のユーザ端末として、前記ビデオストリームフラグメントＢの閲覧要求を前記ＳＮＳサービスプロバイダに送信する手段と、前記閲覧要求に対して当該ＳＮＳサービスプロバイダから送信されてきた前記メッセージＣを表示するとともに前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢを再生する手段とを備え、
前記ＳＮＳサービスプロバイダは、前記第１のユーザ端末からの前記投稿リクエストとともに送信されてきた前記メッセージＣを格納する手段と、前記メッセージＣを前記ユーザ端末に対して掲載する手段と、前記第２のユーザ端末からの前記ビデオストリームフラグメントＢの閲覧要求に応答して前記メッセージＣを前記第２のユーザ端末に送信するとともに、前記ビデオストリームフラグメントＢの閲覧リクエストの通知を前記コンテンツプロバイダに送信する手段とを備える、
コンテンツ配信システム。
【請求項２】
通信ネットワークに接続されるユーザ端末と、コンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムであって、
前記コンテンツプロバイダは、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶する手段と、リアルタイムビデオストリームＡを送信した第１のユーザ端末からビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納する手段と、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送する手段と、第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストを受信すると前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信する手段とを備え、
前記ユーザ端末は、前記第１のユーザ端末として、前記コンテンツプロバイダから送信されてきた前記リアルタイムビデオストリームＡの再生中に前記ビデオストリームフラグメントＢを選択するユーザ入力があると当該ビデオストリームフラグメントＢに関する前記選択信号を前記コンテンツプロバイダに送信する手段と、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信する手段とを備えるとともに、前記第２のユーザ端末として、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信する手段と、前記閲覧要求の送信を起源として当該ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示して当該ビデオストリームフラグメントＢを再生する手段とを備え、
前記ＳＮＳサービスプロバイダは、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納する手段と、前記メッセージＣを前記ユーザ端末に対して掲載する手段と、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと、前記ビデオストリームフラグメントＢとを受信すると、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信する手段とを備える、
コンテンツ配信システム。
【請求項３】
請求項１又は請求項２において、前記リアルタイムビデオストリームは、前記ビデオストリームフラグメントを分割の最小単位として前記コンテンツプロバイダに格納されている、コンテンツ配信システム。
【請求項４】
通信ネットワークに接続されるユーザ端末と、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムにより、前記ＳＮＳサービスプロバイダに前記ビデオストリームフラグメントを投稿する方法であって、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末が、ビデオストリームフラグメントＢの選択信号を送信し、
前記コンテンツプロバイダが、前記ビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納し、
前記第１のユーザ端末が、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記ＳＮＳサービスプロバイダに送信し、
前記ＳＮＳサービスプロバイダが、前記第１のユーザ端末からの前記投稿リクエストとともに送信されてきた前記メッセージＣを格納するとともに、当該記メッセージＣを前記ユーザ端末に対して掲載し、
第２のユーザ端末が、前記ビデオストリームフラグメントＢの閲覧要求を前記ＳＮＳサービスプロバイダに送信し、
前記ＳＮＳサービスプロバイダが前記第２のユーザ端末からの前記ビデオストリームフラグメントＢの閲覧要求に応答して前記メッセージＣを前記第２のユーザ端末に送信するとともに、前記ビデオストリームフラグメントＢの閲覧リクエストの通知を前記コンテンツプロバイダに送信し、
前記コンテンツプロバイダが、前記ＳＮＳサービスプロバイダから送信されてきた前記ビデオストリームフラグメントＢの閲覧リクエストの通知に応答して格納した前記ビデオストリームフラグメントＢを第２のユーザ端末に送信し、
前記第２のユーザ端末が、前記ＳＮＳサービスプロバイダから送信されてきた前記メッセージＣを表示するとともに、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢを再生する、
ビデオストリームフラグメントの投稿方法。
【請求項５】
通信ネットワークに接続されるユーザ端末と、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムにより、前記ＳＮＳサービスプロバイダに前記ビデオストリームフラグメントを投稿する方法であって、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末が、ビデオストリームフラグメントＢの選択信号を送信し、
前記コンテンツプロバイダが、前記ビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納し、
前記第１のユーザ端末が、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信し、
前記コンテンツプロバイダが、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送し、
前記ＳＮＳサービスプロバイダが、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納するとともに、前記メッセージＣを前記ユーザ端末に対して掲載し、
第２のユーザ端末が、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信し、
前記コンテンツプロバイダが、前記第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストを受信すると前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信し、
前記ＳＮＳサービスプロバイダが、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと、前記ビデオストリームフラグメントＢとを受信すると、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信し、
前記第２のユーザ端末が、前記ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示して当該ビデオストリームフラグメントＢを再生する、
ビデオストリームフラグメントの投稿方法。
【請求項６】
請求項４又は請求項５において、前記リアルタイムビデオストリームは、前記ビデオストリームフラグメントを分割の最小単位として前記コンテンツプロバイダに格納されている、ビデオストリームフラグメントの投稿方法。
【請求項７】
通信ネットワークに接続されてコンテンツ配信システムを構成する、ユーザ端末、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダ、およびＳＮＳサービスプロバイダにて処理されることで、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末に、ビデオストリームフラグメントＢの選択信号を送信させるステップと、
前記コンテンツプロバイダに、前記ビデオストリームフラグメントＢの選択信号を受信させて当該ビデオストリームフラグメントＢを格納させるステップと、
前記第１のユーザ端末が、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送させるステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納させるとともに、前記メッセージＣを前記ユーザ端末に対して掲載するステップと、
第２のユーザ端末に、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストとを受信させるとともに、前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信するステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと前記ビデオストリームフラグメントＢとを受信させるとともに、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信させるステップと、
前記第２のユーザ端末に、前記ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示させて当該ビデオストリームフラグメントＢを再生させるステップと、
を実行させる、ビデオストリームフラグメントの投稿プログラム。
【請求項８】
通信ネットワークに接続されてコンテンツ配信システムを構成する、ユーザ端末、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダ、およびＳＮＳサービスプロバイダにて処理されることで、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末に、ビデオストリームフラグメントＢの選択信号を送信させるステップと、
前記コンテンツプロバイダに、前記ビデオストリームフラグメントＢの選択信号を受信させて当該ビデオストリームフラグメントＢを格納させるステップと、
前記第１のユーザ端末に、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送させるステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納させるとともに、前記メッセージＣを前記ユーザ端末に対して掲載させるステップと、
第２のユーザ端末に、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストを受信させるとともに、前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信させるステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと、前記ビデオストリームフラグメントＢとを受信させるとともに、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信させるステップと、
前記第２のユーザ端末に、前記ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示させて当該ビデオストリームフラグメントＢを再生させるステップと、
を実行させる、ビデオストリームフラグメントの投稿プログラム。
【請求項９】
請求項７又は請求項８において、前記リアルタイムビデオストリームは、前記ビデオストリームフラグメントを分割の最小単位として前記コンテンツプロバイダに格納されている、ビデオストリームフラグメントの投稿プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信システムに関する。
【背景技術】
【０００２】
近年、急激なスマートフォン等のユーザ端末の普及と共に、高性能化が進んでおり、ユーザ端末を所有するユーザは、あらゆる場所からインターネットに接続し、様々なサービスを受けることができる。多くのサービスはユーザの近くにある基地局を介して行われる。
【０００３】
インターネットでは、ＹｏｕＴｕｂｅ（商標）やニコニコ動画（商標）等の様々なアプリケーションを用いて、動画像サービスの提供が行われている。このようなストリーミング動画配信サービスは、インターネットの広域化とＣＤＮ（Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｎｅｔｗｏｒｋ）の普及に伴って普及し、ＨＴＴＰを用いれば、キャッシュを利用でき、ファイアフォールやＮＡＴを簡単に越えられること、及びサーバを簡単に用意できることなどの利点がある事から、ＨＴＴＰ／ＴＣＰを用いての配信が主流になりつつある。
【０００４】
また、情報通信技術の進歩により、無線ＬＡＮ機器の応用は、無線機能を持った装置の価格の低下に伴い、オフィスのコンピュータやネットワークにとどまらず、一般家庭にも浸透し、無線ＬＡＮの特徴であるスマートフォン等の無線端末のポータビリティを活かして、無線ＬＡＮを公衆ネットワークに接続する公衆無線ＬＡＮサービスが開始されており、街中や店舗内での無線ＬＡＮの利用が当たり前のこととなっている。これにより、様々な場所で無線ＬＡＮによるインターネット接続ができるようになり、また、利用する機会が増えてきている。無線ＬＡＮは、通常、ＬＡＮケーブルの接続が不要なため、アクセスポイント（ＡＰ）があれば場所に左右されずにインターネットを利用できる。
【０００５】
ここで、インターネットの普及によって、Ｔｗｉｔｔｅｒ（商標）やＦａｃｅｂｏｏｋ（商標）等のＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ）といった数多くの新しいインターネットメディアが、普及しつつある。これらのインターネット上で展開される様々なメディアを連携したサービスも出現している。これらの複数のインターネットメディアと動画像サービスといったメディアストリームとの連携と同期は、インターネット上での新しいサービスの実現に必須のものである。
【０００６】
このような事情から、高性能化したスマートフォン等のユーザ端末を用いて、簡単な方法で、上記の新しいインターネットメディアと動画配信サービスとの連携及び同期を達成することができるコンテンツ配信システムが望まれる。
【０００７】
例えば、特許文献１は、時間とともに進行する投稿対象についての投稿を収集する収集部と、収集した投稿の数を所定のクラス毎に集計する集計部と、前記クラス毎の投稿数の時系列の推移を示す複数のグラフを、各時刻における投稿または前記投稿対象に関する情報のうち少なくとも一方を含む情報である付加情報とともに時間軸に沿って表示するように制御する表示制御部とを含む、動画コンテンツ等の時間とともに進行する投稿対象についての投稿の傾向の推移を容易に把握できる情報処理装置を教示している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１３‐０３３３７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１は、サーバがクライアントに配信するコンテンツのサーバ側での格納方法、コンテンツの配信方法、及び投稿対象物の投稿方法について記載していない。
【００１０】
従って、特許文献１の情報処理装置によって提供されるサービスは、クライアントでリアルタイムビデオストリームを視聴中に、そのリアルタイムビデオストリームの任意の位置のビデオストリームフラグメントのＳＮＳサイトへの投稿を、クライアントのみを用いて簡単な方法で可能にするものではない。
【課題を解決するための手段】
【００１１】
従って、本発明の第１の態様によれば、本発明は、通信ネットワークに接続されるユーザ端末と、コンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムであって、
前記コンテンツプロバイダは、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶する手段と、リアルタイムビデオストリームＡを送信した第１のユーザ端末からビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納する手段と、前記ＳＮＳサービスプロバイダから送信されてきた前記ビデオストリームフラグメントＢの閲覧リクエストの通知に応答して格納した前記ビデオストリームフラグメントＢを第２のユーザ端末に送信する手段とを備え、
前記ユーザ端末は、前記第１のユーザ端末として、前記コンテンツプロバイダから送信されてきた前記リアルタイムビデオストリームＡの再生中に前記ビデオストリームフラグメントＢを選択するユーザ入力があると当該ビデオストリームフラグメントＢに関する前記選択信号を前記コンテンツプロバイダに送信する手段と、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記ＳＮＳサービスプロバイダに送信する手段とを備えるとともに、前記第２のユーザ端末として、前記ビデオストリームフラグメントＢの閲覧要求を前記ＳＮＳサービスプロバイダに送信する手段と、前記閲覧要求に対して当該ＳＮＳサービスプロバイダから送信されてきた前記メッセージＣを表示するとともに前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢを再生する手段とを備え、
前記ＳＮＳサービスプロバイダは、前記第１のユーザ端末からの前記投稿リクエストとともに送信されてきた前記メッセージＣを格納する手段と、前記メッセージＣを前記ユーザ端末に対して掲載する手段と、前記第２のユーザ端末からの前記ビデオストリームフラグメントＢの閲覧要求に応答して前記メッセージＣを前記第２のユーザ端末に送信するとともに、前記ビデオストリームフラグメントＢの閲覧リクエストの通知を前記コンテンツプロバイダに送信する手段とを備える、
コンテンツ配信システムである。
【００１２】
また、本発明の第２の態様によれば、本発明は、通信ネットワークに接続されるユーザ端末と、コンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムであって、
前記コンテンツプロバイダは、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶する手段と、リアルタイムビデオストリームＡを送信した第１のユーザ端末からビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納する手段と、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送する手段と、第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストを受信すると前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信する手段とを備え、
前記ユーザ端末は、前記第１のユーザ端末として、前記コンテンツプロバイダから送信されてきた前記リアルタイムビデオストリームＡの再生中に前記ビデオストリームフラグメントＢを選択するユーザ入力があると当該ビデオストリームフラグメントＢに関する前記選択信号を前記コンテンツプロバイダに送信する手段と、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信する手段とを備えるとともに、前記第２のユーザ端末として、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信する手段と、前記閲覧要求の送信を起源として当該ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示して当該ビデオストリームフラグメントＢを再生する手段とを備え、
前記ＳＮＳサービスプロバイダは、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納する手段と、前記メッセージＣを前記ユーザ端末に対して掲載する手段と、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと、前記ビデオストリームフラグメントＢとを受信すると、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信する手段とを備える、
コンテンツ配信システムである。
【００１３】
さらに、本発明の第３の態様によれば、本発明は、通信ネットワークに接続されるユーザ端末と、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムにより、前記ＳＮＳサービスプロバイダに前記ビデオストリームフラグメントを投稿する方法であって、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末が、ビデオストリームフラグメントＢの選択信号を送信し、
前記コンテンツプロバイダが、前記ビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納し、
前記第１のユーザ端末が、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記ＳＮＳサービスプロバイダに送信し、
前記ＳＮＳサービスプロバイダが、前記第１のユーザ端末からの前記投稿リクエストとともに送信されてきた前記メッセージＣを格納するとともに、当該記メッセージＣを前記ユーザ端末に対して掲載し、
第２のユーザ端末が、前記ビデオストリームフラグメントＢの閲覧要求を前記ＳＮＳサービスプロバイダに送信し、
前記ＳＮＳサービスプロバイダが前記第２のユーザ端末からの前記ビデオストリームフラグメントＢの閲覧要求に応答して前記メッセージＣを前記第２のユーザ端末に送信するとともに、前記ビデオストリームフラグメントＢの閲覧リクエストの通知を前記コンテンツプロバイダに送信し、
前記コンテンツプロバイダが、前記ＳＮＳサービスプロバイダから送信されてきた前記ビデオストリームフラグメントＢの閲覧リクエストの通知に応答して格納した前記ビデオストリームフラグメントＢを第２のユーザ端末に送信し、
前記第２のユーザ端末が、前記ＳＮＳサービスプロバイダから送信されてきた前記メッセージＣを表示するとともに、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢを再生する、
ビデオストリームフラグメントの投稿方法である。
【００１４】
本発明の第４の態様によれば、本発明は、通信ネットワークに接続されるユーザ端末と、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダと、ＳＮＳサービスプロバイダとを含むコンテンツ配信システムにより、前記ＳＮＳサービスプロバイダに前記ビデオストリームフラグメントを投稿する方法であって、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末が、ビデオストリームフラグメントＢの選択信号を送信し、
前記コンテンツプロバイダが、前記ビデオストリームフラグメントＢの選択信号を受信して当該ビデオストリームフラグメントＢを格納し、
前記第１のユーザ端末が、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信し、
前記コンテンツプロバイダが、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送し、
前記ＳＮＳサービスプロバイダが、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納するとともに、前記メッセージＣを前記ユーザ端末に対して掲載し、
第２のユーザ端末が、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信し、
前記コンテンツプロバイダが、前記第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストを受信すると前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信し、
前記ＳＮＳサービスプロバイダが、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと、前記ビデオストリームフラグメントＢとを受信すると、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信し、
前記第２のユーザ端末が、前記ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示して当該ビデオストリームフラグメントＢを再生する、
ビデオストリームフラグメントの投稿方法である。
【００１５】
本発明の第５の態様によれば、本発明は、通信ネットワークに接続されてコンテンツ配信システムを構成する、ユーザ端末、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダ、およびＳＮＳサービスプロバイダにて処理されることで、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末に、ビデオストリームフラグメントＢの選択信号を送信させるステップと、
前記コンテンツプロバイダに、前記ビデオストリームフラグメントＢの選択信号を受信させて当該ビデオストリームフラグメントＢを格納させるステップと、
前記第１のユーザ端末が、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送させるステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納させるとともに、前記メッセージＣを前記ユーザ端末に対して掲載するステップと、
第２のユーザ端末に、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストとを受信させるとともに、前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信するステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと前記ビデオストリームフラグメントＢとを受信させるとともに、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信させるステップと、
前記第２のユーザ端末に、前記ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示させて当該ビデオストリームフラグメントＢを再生させるステップと、
を実行させる、ビデオストリームフラグメントの投稿プログラムである。
【００１６】
本発明の第６の態様によれば、本発明は、通信ネットワークに接続されてコンテンツ配信システムを構成する、ユーザ端末、複数のビデオストリームフラグメントを含むリアルタイムビデオストリームを記憶するコンテンツプロバイダ、およびＳＮＳサービスプロバイダにて処理されることで、
前記コンテンツプロバイダからリアルタイムビデオストリームＡを受信した第１のユーザ端末に、ビデオストリームフラグメントＢの選択信号を送信させるステップと、
前記コンテンツプロバイダに、前記ビデオストリームフラグメントＢの選択信号を受信させて当該ビデオストリームフラグメントＢを格納させるステップと、
前記第１のユーザ端末に、前記ビデオストリームフラグメントＢの投稿リクエストをメッセージＣとともに前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第１のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを前記ＳＮＳサービスプロバイダに転送させるステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから転送されてきた前記ビデオストリームフラグメントＢの投稿リクエストとメッセージＣとを格納させるとともに、前記メッセージＣを前記ユーザ端末に対して掲載させるステップと、
第２のユーザ端末に、前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧要求を前記コンテンツプロバイダに送信させるステップと、
前記コンテンツプロバイダに、前記第２のユーザ端末から送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストを受信させるとともに、前記ＳＮＳサービスプロバイダに当該閲覧リクエストと格納した前記ビデオストリームフラグメントＢを送信させるステップと、
前記ＳＮＳサービスプロバイダに、前記コンテンツプロバイダから送信されてきた前記ビデオストリームフラグメントＢと前記メッセージＣとに対する閲覧リクエストと、前記ビデオストリームフラグメントＢとを受信させるとともに、当該ビデオストリームフラグメントＢと前記メッセージＣとを第２のユーザ端末に送信させるステップと、
前記第２のユーザ端末に、前記ＳＮＳサービスプロバイダから前記メッセージＣと前記ビデオストリームフラグメントＢとが送信されてくると、当該メッセージＣを表示させて当該ビデオストリームフラグメントＢを再生させるステップと、
を実行させる、ビデオストリームフラグメントの投稿プログラムである。
【発明の効果】
【００２０】
本発明によれば、ユーザ端末のみを使用することにより、ユーザ端末でのリアルタイムビデオストリームの視聴中に、そのリアルタイムビデオストリームの任意の位置のビデオストリームフラグメントのＳＮＳサイトへの投稿が、簡単な方法で可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明に従ったコンテンツ配信システムを実装するための無線通信ネットワークの全体構成を示す図である。
【図２】モバイル通信ネットワーク１０４の構成を示す図である。
【図３】ユーザ端末１１８−ｉの機能ブロック図である。
【図４】コンテンツ配信サーバ１２２のハードウェア構成を示す図である。
【図５】データベースサーバ１２４のハードウェア構成を示す図である。
【図６】ＳＮＳサーバ１２８のハードウェア構成を示す図である。
【図７】データベースサーバ１３０のハードウェア構成を示す図である。
【図８】Ｗｅｂサーバ１２０及び１２６のハードウェア構成を示す図である。
【図９】ＯＦＤＭ変復調部の機能ブロック図である。
【図１０】データベースサーバ１２４のコンテンツデータベース５１０におけるリアルタイムビデオストリームの格納の様子を示す図である。
【図１１】ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ）プロトコルに従ったリアルタイムビデオストリームの配信を示す図である。
【図１２】ＲＴＰパケットのデータ構造を示す図である。
【図１３】ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）プロトコルストリーミングを示す図である。
【図１４】ユーザ端末１１８−ｉとコンテンツ配信サーバ１２２との間のセッションの確立を示すシーケンス図である。
【図１５】ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２とユーザ端末１１８−ｉとの間で行われる適応ビット割当処理のフローチャートである。
【図１６】リアルタイムの番組表を表示したユーザ端末１１８−ｉの表示部２１０を示す図である。
【図１７】ＲＴＰプロトコルに従った階層型ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）制御機能の構成を示す図である。
【図１８】ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）プロトコルに従ったＱｏＳ制御機能の構成を示す図である。
【図１９】コンテンツ配信サーバ１２２とユーザ端末１１８−ｉとの間で行われるシンボルレート（帯域幅）ネゴシエーションのシーケンス図である。
【図２０】ユーザ端末１１８−ｉでのプログラム視聴中のザッピング動作のフローチャートである。
【図２１】ユーザ端末１１８−ｉの表示部２１０上での横方向（長手方向）のザッピングの様子を示す図である。
【図２２】ユーザ端末１１８−ｉの表示部２１０上での横方向（長手方向）のザッピングの様子を示す図である。
【図２３】ユーザ端末１１８−ｉの表示部２１０上での縦方向のザッピングの様子を示す図である。
【図２４】ビデオストリームフラグメントのＳＮＳへの拡散の第１の実施形態を示すシーケンス図である。
【図２５】ビデオストリームフラグメントのＳＮＳへの拡散の第２の実施形態を示すシーケンス図である。
【図２６】ビデオストリームフラグメントのＳＮＳへの拡散の第３の実施形態を示すシーケンス図である。
【図２７】指定した再生時間に対応するビデオストリームフラグメントをＳＮＳサイトに投稿する際の操作を示す図である。
【図２８】指定した再生時間に対応するビデオストリームフラグメントをＳＮＳサイトに投稿する際の操作を示す図である。
【図２９】指定した再生時間に対応するビデオストリームフラグメントをＳＮＳサイトに投稿する際の操作を示す図である。
【発明を実施するための形態】
【００２２】
本発明は様々な変更形態及び代替形態が可能であるが、本発明の一例としての実施形態が実施例として図面に示されており、本明細書で詳細に説明される。しかし、一例としての実施形態の本明細書における説明は、開示された特定の形態に本発明を限定することを意図するものではなく、本発明は、特許請求の範囲によって規定された本発明の趣旨及び範囲に入る全ての変更形態、同等形態、及び代替形態を含む。
【００２３】
（１）  ネットワークの全体構成
図１は、本実施形態に従ったコンテンツ配信システムを実装するための無線通信ネットワークの全体構成を示す図である。
【００２４】
無線通信ネットワーク１００は、コアネットワークとして機能する上位ネットワーク１０２と、複数のモバイル通信ネットワーク１０４とからなる。コアネットワーク１０２は、複数のコンテンツサービスルータ１０６を含み、複数のモバイル通信ネットワーク１０４は、それぞれ、無線ネットワークコントローラ（ＲＮＣ）１０８と、複数のＮｏｄｅＢ１１０と、複数のｅＮｏｄｅＢ１１２とを含むことができる。リアルタイムビデオストリーム等のコンテンツを配信するコンテンツプロバイダ１１４、及びＴｗｉｔｔｅｒやＬｉｎｅといったＳｏｃｉａｌ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ（ＳＮＳ）を提供するＳＮＳサービスプロバイダ１１６が、上位ネットワーク１０２に接続され、複数のユーザ端末１１８−ｉ（ｉ＝１，…，ｎ）が、複数のモバイル通信ネットワーク１０４に接続される。ここで、ユーザ端末のインデックスｉは、ユーザｉｄに対応している。
【００２５】
コンテンツプロバイダ１１４は、Ｗｅｂサーバ１２０と、コンテンツ配信サーバ１２２と、データベースサーバ１２４とを含み、ＳＮＳサービスプロバイダ１１６は、Ｗｅｂサーバ１２６と、ＳＮＳサーバ１２８と、データベースサーバ１３０とを含む。
【００２６】
ユーザ端末１１８−ｉは、スマートフォン、タブレット端末、セルラ電話、携帯情報端末、テキスト・メッセージング装置、ページャ、ネットワーク・インターフェース・カード、ノートブックコンピュータ、デスクトップコンピュータ、及びパーソナル・ディジタル・アシスタント（ＰＤＡ）であっても良い。ユーザ端末１１８−ｉは、トラフィック・チャネル、シグナリング・チャネル、ページング・チャネル等、いくつかの通信チャネルを含むエア・インターフェース（又は無線通信リンク）を介して情報を交換することによって通信することができる。
【００２７】
コアネットワーク１０２は、公衆交換電話ネットワーク（ＰＳＴＮ）等の回線交換ネットワーク又はインターネット等のパケット・ベース・ネットワークであってもよい。コアネットワーク１０２は、少なくともその一部分に、無線信号を介してデータ通信を提供する任意のモバイル通信ネットワーク１０４を含む。モバイル通信ネットワーク１０４は、例えば、ＷｉＦｉ／ＷｉＭａｘ通信を使用する無線ローカル・エリア・ネットワーク（ＷＬＡＮ）を含む。モバイル通信ネットワーク１０４の例示的実装は、会社又はキャンパスの企業ネットワークとして、又は空港、喫茶店、その他等の一般的な公共の場の「ホット・スポット」として実装されるものであってもよい。モバイル通信ネットワーク１０４は、さらに、複数のユーザ端末１１８−ｉへの無線接続を提供する１つ又は複数のアクセスポイントを含む。アクセスポイントには、基地局、基地局ルータ、アクセス・ネットワークが含まれる。
【００２８】
エア・インターフェースの通信チャネルは、コアネットワーク１０２又はモバイル通信ネットワーク１０４によって使用される１つ又は複数の無線通信プロトコルに従って定義される。コアネットワーク１０２及びモバイル通信ネットワーク１０４は、通常、データ通信に対して使用されるが、ＶｏＩＰ呼等の音声通信を転送することができるネットワークであってもよい。例えば、コアネットワーク１０２及びモバイル通信ネットワーク１０４は、音声、ビデオ、パケットデータ、メッセージング、ブロードキャスト等の様々な通信サービスを提供するために広く展開されていてもよい。これらの通信ネットワークは、利用可能なネットワークリソースを共有することによって、複数のユーザ端末をサポートすることが可能な多元接続ネットワークであってもよい。そのような多元接続ネットワークは、例えば、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、及びシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）ネットワークを含む。例えば、符号分割多元接続（ＣＤＭＡ）に従って動作するエア・インターフェースの通信チャネルは、情報を、エア・インターフェースを介して送信するために使用される無線信号を変調する直交符号によって定義される。エア・インターフェースの通信チャネルは、また、エア・インターフェースを介して情報を送信するために使用される搬送波の周波数によって決定されてもよい。例えば、直交周波数分割多元接続（ＯＦＤＭＡ）では、１つ又は複数のユーザ端末１１８−ｉが複数の直交周波数、又はトーンを共用しても良い。
【００２９】
ここで、「ネットワーク」及び「システム」という用語は、しばしば互換的に使用される。ＣＤＭＡネットワークは、ユニバーサル地上無線アクセス（ＵＴＲＡ）、ＣＤＭＡ２０００等の無線技術を実装することができる。ＵＴＲＡは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）及びＣＤＭＡの他の変形形態を含む。ＣＤＭＡ２０００は、ＩＳ−２０００規格、ＩＳ−９５規格及びＩＳ−８５６規格をカバーする。ＴＤＭＡネットワークは、モバイル通信用グローバルシステム（ＧＳＭ）等の無線技術を実装することができる。ＯＦＤＭＡネットワークは、発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ウルトラモバイルブロードバンド（ＵＭＢ）、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２．２０、フラッシュＯＦＤＭＡ等の無線技術を実装することができる。ＵＴＲＡ及びＥ−ＵＴＲＡは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）の一部である。３ＧＰＰのロングタームエボリューション（ＬＴＥ）及びＬＴＥアドバンスト（ＬＴＥ−Ａ）は、Ｅ−ＵＴＲＡを使用する、新たにリリースされたＵＭＴＳである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥ、ＬＴＥ−Ａ、及びＧＳＭは、「第３世代パートナーシッププロジェクト」（３ＧＰＰ）で説明されている。ＣＤＭＡ２０００及びＵＭＢは、「第３世代パートナーシッププロジェクト２」（３ＧＰＰ２）で説明されている。
【００３０】
図２は、モバイル通信ネットワーク１０４の構成を示す図である。
【００３１】
モバイル通信ネットワーク１０４は、複数のＮｏｄｅＢ１１０と複数のｅＮｏｄｅＢ１１２と無線ネットワークコントローラ（ＲＮＣ）１０８と他のネットワークエンティティとを含んでもよい。ＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２は、ユーザ端末１１８−ｉと通信する局であり、基地局、アクセスポイント、又は他の用語を用いて呼ばれる場合もある。各ＮｏｄｅＢ−１乃至ＮｏｄｅＢ−３は、特定の地理的エリアであるマクロセルに無線カバレッジを提供することができる。
【００３２】
マクロセルは、比較的大きい地理的エリア（半径数キロメートル）をカバーでき、サービスに加入しているユーザ端末１１８−ｉによる制限無しのアクセスを可能にする。各ｅＮｏｄｅＢ１１２は、比較的小さい地理的エリアであるフェムトセル及びピコセル等に無線カバレッジを提供することができ、サービスに加入しているユーザ端末１１８−ｉによる制限無しのアクセスを可能にする。フェムトセルは、そのフェムトセルとの関連を有する限定加入者グループ（ＣＳＧ）内のユーザ端末１１８−ｉ、家庭内のユーザのためのユーザ端末１１８−ｉ等のユーザ端末１１８−ｉによる制限有りのアクセスを可能にする。フェムトセルを取り扱う（Ｓｅｒｖｉｎｇ）ｅＮｏｄｅＢ１１２は、フェムトｅＮｏｄｅＢ又はホームｅＮｏｄｅＢ（ＨＮＢ）と呼ばれることがあり、ピコセルを取り扱うｅＮｏｄｅＢは、ピコｅＮｏｄｅＢと呼ばれることがある。図２の例では、ＮｏｄｅＢ−１、ＮｏｄｅＢ−２、及びＮｏｄｅＢ−３は、それぞれマクロセル１３２、１３４、及び１３６を取り扱うマクロＮｏｄｅＢであり得る。ｅＮｏｄｅＢ１１２のうちの４つは、フェムトセルを取り扱うフェムトｅＮｏｄｅＢであり、ｅＮｏｄｅＢ１１２の残りの１つは、ピコセルを取り扱うピコｅＮｏｄｅＢである。
【００３３】
モバイル通信ネットワーク１０４は、様々なタイプのｅＮｏｄｅＢやリレー（中継器）等を含む異種ネットワークであってもよい。これらの異なるタイプのｅＮｏｄｅＢは、異なる送信電力レベル、異なるカバレッジエリア、及びモバイル通信ネットワーク１０４の干渉に対する異なる影響を有してもよい。例えば、マクロＮｏｄｅＢは、高い送信電力レベル（２０ワット）を有することがあるが、ピコｅＮｏｄｅＢ、フェムトｅＮｏｄｅＢ、及びリレーは、より低い送信電力レベル（１ワット）を有することがある。図２において、両矢印付きの実線は、ダウンリンク及びアップリンクを介しての、ユーザ端末１１８−ｉを取り扱う（Ｓｅｒｖｉｎｇ）ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２と、そのユーザ端末１１８−ｉとの間の通信を示す。両矢印付信号を示す。
【００３４】
モバイル通信ネットワーク１０４は、同期動作又は非同期動作をサポートすることができる。同期動作の場合、ＮｏｄｅＢ及びｅＮｏｄｅＢは、同様のフレームタイミングを有することができ、異なるｅＮｏｄｅＢからの送信は、ほぼ時間的に整列され得る。非同期動作の場合には、ｅＮｏｄｅＢは、異なるフレームタイミングを有することができ、異なるｅＮｏｄｅＢからの送信は時間的に整列されないこともある。
【００３５】
ＲＮＣ１０８は、ＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２のと無線リンクを介して接続され、これらのＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２を制御する。ＲＮＣ１０８は、コアネットワーク１０２（バックホールネットワーク）を介してＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２と通信することができる。ＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２は、無線バックホール又は有線バックホールを介して、直接的に又は間接的に互いに通信することができる。
【００３６】
ＬＴＥは、通常、ダウンリンク上では直交周波数分割多重化（ＯＦＤＭ）を利用し、アップリンク上ではシングルキャリア周波数分割多重化（ＳＣ−ＦＤＭ）を利用することが多い。ＯＦＤＭ及びＳＣ−ＦＤＭは、システム帯域幅を、通常はトーンと称される複数の直交サブキャリアに分割する。各サブキャリアは、データで変調されてもよい。変調シンボルは、一般に、ＯＦＤＭでは周波数領域で、ＳＣ−ＦＤＭでは時間領域で送信される。隣接するサブキャリア間の間隔は固定であってもよく、サブキャリアの総数は、システム帯域幅に依存する。システム帯域幅あたりのサブキャリアの数は、１．２５、２．５、５、１０、又は２０［ＭＨｚ］のシステム帯域幅については、それぞれ、１２８、２５６、５１２、１０２４、又は２０４８となっていてもよい。システム帯域幅は、複数のサブバンドから構成されることができる。サブバンドは、例えば、１．０８［ＭＨｚ］をカバーすることができ、１．２５、２．５、５、１０、又は２０［ＭＨｚ］のシステム帯域幅については、それぞれ１個、２個、４個、８個、又は１６個のサブバンドが存在する。
【００３７】
（２）  ユーザ端末
図３は、ユーザ端末１１８−ｉの機能ブロック図である。
【００３８】
ユーザ端末２００は、ディジタル処理部２０２と、ベースバンド部２０４と、ＲＦ部２０６とからなる。ディジタル処理部２０２は、入力部２０８と、表示部２１０と、記憶装置２１２と、メモリ２１４と、ＣＰＵ２１６とを含む。ＣＰＵ２１６は、記憶装置２１２に記憶されているプログラムをメモリ２１４に読み出して実行することにより各種の機能を実現する。メモリ２１４は、例えば、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）及び／又は読取り専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）を含む。記憶装置２１２は、テープ・ドライブ、フロッピー（登録商標）・ドライブ、ハードディスク・ドライブ又はコンパクト・ディスク・ドライブを含む。入力部２０８は、データの入力を受け付ける、例えば、キーボードやマウス、トラックボール、タッチパネル、マイクロフォン等を含む。表示部２１０は、データを出力する、例えば、ディスプレイやスピーカ等を含む。
【００３９】
ベースバンド部２０４は、目的に応じて、復調部２１８と、変復調部２２０と、ＯＦＤＭ復調部２２２と、変復調部２２４を含むことができる。ＲＦ部も、同様に、目的に応じて、受信部２２６と、送受信部２２８と、チューナ２３０と、送受信部２３２を含むことができる。
【００４０】
例えば、送受信部２３２と変復調部２２４は、広帯域ＣＤＭＡ（ＷＣＤＭＡ）ネットワーク又はモバイル通信用グローバルシステム（ＧＳＭ）ネットワークを介して、音声通信を行うのに使用することができる。変復調部２２４は、一次変調スキームとして、ＢＰＳＫ、ＱＰＳＫ、８値ＰＳＫ、１６値ＱＡＭ、３２値ＱＡＭ等のスキームを使用することができる。変復調部２２４は、その一次変調を施した信号に、各ユーザ端末１１８−ｉに割り当てられ、相互相関の小さいＰＮ符号又はＧｏｌｄ符号、又は互いに直行するＷａｌｓｈ−Ｈａｄａｍａｒｄ符号を乗算することにより、スペクトル拡散を行った信号を送受信部２３２に送る。送受信部２３２は、受け取ったスペクトル拡散信号をアナログディジタル（Ａ／Ｄ）変換し、増幅器で増幅した後にアンテナから送出する。受信動作においては、送受信部２３２は、受信した信号をアナログディジタル（Ａ／Ｄ）変換し、変復調部２２４は、同期した符号系列を再度乗積し、元の信号を復元する逆拡散を行う。変復調部２２４は、挟帯域の干渉信号を除去するために、逆拡散された広帯域信号にローパスフィルタ（ＬＰＦ）によりフィルタリング処理を行う。
【００４１】
また、チューナ２３０とＯＦＤＭ復調部２２２は、コンテンツプロバイダ１１４からビデオストリームを受信するのに使用することができる。チューナ２３０は、受信帯域を変更可能に構成されている。チューナ２３０は、ＣＰＵ２１６から中心周波数の指示を受信し、その中心周波数の指示に基づいて中心周波数を移動することにより受信帯域を移動させることができる。チューナ２３０は、全ディジタル位相ロックループ（Ａｌｌ  Ｄｉｇｉｔａｌ  Ｐｈａｓｅ  Ｌｏｃｋｅｄ  Ｌｏｏｐ（ＡＤＰＬＬ））を用いて構成することができる。ＡＤＰＬＬは、位相比較のために、加算回路と遅延差をディジタル値へ変換する時間―ディジタルコンバータ（Ｔｉｍｅ−ｔｏ−Ｄｉｇｉｔａｌ  Ｃｏｎｖｅｒｔｅｒ（ＴＤＣ））回路を用いて構成してもよい。ＡＤＰＬＬは、ディジタル値で発振周波数の制御を行うディジタル制御発振器（Ｄｉｇｉｔａｌ  Ｃｏｎｔｒｏｌｌｅｄ  Ｏｓｃｉｌｌａｔｏｒ（ＤＣＯ））を含んでもよく、このことは、プロセスポータビリティ、スケーラビリティ、低電圧動作を可能とし、出力信号位相雑音に及ぼす雑音源も限定できる。ＡＤＰＬＬは、チューニング時は、システムのループゲインをディジタルで段階的に切り替えることで収束時間を短縮し、出力周波数微調整及び収束時にはＭＡＳＨΔ−Σ構成を有するフラクショナル方式を用いてもよい。チューナ２３０は、周波数選択した受信信号をＯＦＤＭ復調部２２２に送る。
【００４２】
ＯＦＤＭ復調部２２２は、例えば、図９の下段に示すように構成してもよい。ＯＦＤＭ変調方式は、１つのサブバンドについて複数のサブキャリアを使用し、それぞれのサブキャリアを異なるデータでディジタル変調することによって並列伝送を行う変調方式である。ＯＦＤＭ復調部２２２は、アンテナ１０２０で受信された信号に帯域通過フィルタ（ＢＰＦ）１０２２を用いてフィルタリングを行う。ＯＦＤＭ復調部２２２は、搬送帯域信号から基底帯域信号への変換を行う。具体的には、ＯＦＤＭ復調部２２２は、受信信号にｃｏｓ（２πｆｃｔ）を掛け合わせて、同相成分を求め、ローパスフィルタ（ＬＰＦ）１０２４を用いてフィルタリングを行う。同様に、ＯＦＤＭ復調部２２２は、受信信号に−ｓｉｎ（２πｆｃｔ）を掛け合わせて、直角位相成分を求め、ＬＰＦ１０２４を用いてフィルタリングを行う。ＯＦＤＭ復調部２２２は、同相成分及び直角位相成分をそれぞれ標本化（Ａ／Ｄ変換）し（１０２６）、Ａ／Ｄ変換した信号を、直並列変換器（ｓｅｒｉａｌ−ｔｏ−ｐａｒａｌｌｅｌ  ｃｏｎｖｅｒｔｅｒ（Ｓ／Ｐ））１０２８により複数のデータ系列に分割する。Ｓ／Ｐ出力後のデータ系列の伝送速度は、受信信号の伝送速度よりも低速になる。
【００４３】
ＯＦＤＭ復調部２２２は、Ｓ／Ｐ変換の際にガードインターバルを除去する（１０３０）。ガードインターバル（サイクリックプレフィックス）は、通常、基底帯域ＯＦＤＭシンボルの後半部分をコピーしたものを先頭に接続して用いる。ガードインターバルの付加は、マルチパスの遅延の広がりがガードインターバル長未満であるという条件のもとで、シンボル間干渉の影響を効果的になくすことを可能にする。
【００４４】
ＯＦＤＭ復調部２２２は、ガードインターバルを除去した信号に離散フーリエ変換（ＤＦＴ）処理を行う（１０３２）。受信シンボル系列に高速フーリエ変換（ＦＦＴ）を行ったシンボルは、そのシンボルを伝送した搬送波周波数に対応する伝送路特性と雑音成分のみを含み、その他のシンボルからの影響は一切含まれない。ＯＦＤＭ復調部２２２は、正しくシンボルを判定するために、伝送路特性の影響を補正する等価処理（１０３４）を行い、等価処理を行ったものに対して並直列変換器（ｐａｒａｌｌｅｌ−ｔｏ−ｓｅｒｉａｌ  ｃｏｎｖｅｒｔｅｒ（Ｐ／Ｓ））１０３６によりＰ／Ｓ変換を行い、送信された元のディジタルデータ系列を得る。等価処理としては、最小平均二乗誤差（Ｍｉｎｉｍｕｍ  Ｍｅａｎ  Ｓｑｕａｒｅ  Ｅｒｒｏｒ（ＭＭＳＥ））等価を用いてもよい。
【００４５】
ＯＦＤＭ復調部２２２は、Ｐ／Ｓ変換を行ったシンボル系列を一次復調し（１０３８）、ベースバンド信号を取り出す。ＯＦＤＭ復調部２２２は、取り出したベースバンド信号にトレリス復号化処理を行う（１０４０）。ＯＦＤＭ変調方式をビデオストリームの配信に応用する場合には、ある一定の伝送帯域幅の中で充分なビットレートを得るために、ＯＦＤＭの各搬送波の変調方式を１６ＱＡＭ等の多値変調とする必要があることが多い。この場合に、帯域幅一定のままビットレートを増やすとビット誤り率特性は劣化するが、この劣化を最小限に抑える手段として、ＯＦＤＭの各搬送波をトレリス符号化変調（Ｔｒｅｌｌｉｓ  Ｃｏｄｅｄ  Ｍｏｄｕｌａｔｉｏｎ（ＴＣＭ））してもよい。トレリス復号は、軟判定ビタビアルゴリズムによって行うことができる。ＯＦＤＭ復調部２２２は、トレリス復号化したものを用いてビット判定を行い、ビット誤り率を求める（１０４２）。
【００４６】
（３）  コンテンツ配信サーバ
図４は、コンテンツ配信サーバ１２２のハードウェア構成を示す図である。
【００４７】
コンテンツ配信サーバ４００は、ＣＰＵ４０２と、メモリ４０４と、記憶装置４０６と、入力部４０８と、出力部４１０と、送受信インターフェイス（Ｉ／Ｆ）４１２と、コンテンツ検索部４１４と、検索情報生成部４１６と、検索ログ生成部４１８と、閲覧ログ生成部４２０と、ストリームセグメンタ４２２と、メディアエンコーダ４２４とを含む。記憶装置４０６は、各種のデータやプログラムを記憶する、ハードディスク・ドライブやソリッドステート・ドライブ、フラッシュメモリ等であってもよい。ＣＰＵ４０２は、記憶装置４０６に記憶されているプログラムをメモリ４０４に読み出して実行することにより各種の機能を実現する。送受信インターフェイス４１２は、コアネットワーク１０２に接続するためのインターフェイスであり、イーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム等である。入力部４０８は、データの入力を受け付ける、キーボードやマウス、トラックボール、タッチパネル、マイクロフォン等であってもよい。出力部４１０は、データを出力する、ディスプレイやプリンタ、スピーカなどであってもよい。
【００４８】
送受信Ｉ／Ｆ４１２は、例えば、図１１に示されるＯＦＤＭ変復調部を用いて構成してもよい。送受信Ｉ／Ｆ４１２の受信動作は、ユーザ端末１１８−ｉのＯＦＤＭ復調部２２２の動作と同様である。
【００４９】
送受信Ｉ／Ｆ４１２は、データベースサーバ１２４からビデオストリームデータを受信し（１００２）、受信したビデオストリームデータのシンボル系列にトレリス符号化処理を行う（１００４）。送受信Ｉ／Ｆ４１２は、トレリス符号化処理を行ったシンボル系列に一次変調を行い、シンボル系列が表すデータでディジタル変調する。送受信Ｉ／Ｆ４１２は、ディジタル変調を行ったシンボル系列をＳ／Ｐ変換器１００８により複数のデータ系列に分割する。Ｓ／Ｐ出力後のデータ系列の伝送速度は、元のビデオストリームの伝送速度よりも低速になる。送受信Ｉ／Ｆ４１２は、Ｓ／Ｐ出力後のデータ系列に、逆離散フーリエ変換（ＩＤＦＴ）処理を行う（１０１０）。送受信Ｉ／Ｆ４１２は、逆高速フーリエ変換（ＩＦＦＴ）を行ったシンボル系列に対してＰ／Ｓ変換器１０１２によりＰ／Ｓ変換を行い、送信ディジタルデータ系列を得る。送受信Ｉ／Ｆ４１２は、送信ディジタルデータ系列に連続化（Ｄ／Ａ変換）を行う（１０１６）。送受信Ｉ／Ｆ４１２は、送信ディジタルデータ系列にｃｏｓ（２πｆｃｔ）を掛け合わせて、同相成分を求め、送信ディジタルデータ系列に−ｓｉｎ（２πｆｃｔ）を掛け合わせて、直角位相成分を求める。送受信Ｉ／Ｆ４１２は、求めた同相成分及び直角位相成分を増幅器１０１８で増幅し、アンテナ１０２０を介して送出する。
【００５０】
コンテンツ検索部４１４は、ユーザ端末１１８−ｉからの選択信号で指定されたコンテンツを、データベースサーバ１２４から検索する。検索情報生成部４１６は、ユーザ端末１１８−ｉからの選択信号に応答して検索されたコンテンツのシーケンスの情報を、“ユーザｉｄ”ｉと関連させた形で生成し、その検索されたコンテンツのシーケンスの情報を検索ログ生成部４１８に送る。検索ログ生成部４１８は、検索されたコンテンツのシーケンスに関する情報に、検索の年月日及び時間を付与して検索ログを生成する。検索ログ生成部４１８は、検索されたコンテンツのシーケンスに関する情報に検索の年月日及び時間を付与した検索ログを、閲覧ログ生成部４２０に送る。閲覧ログ生成部４２０は、ユーザｉが実際にそのコンテンツを視聴した時間に基づいて、ユーザ端末１１８−ｉからの選択信号による検索が閲覧に該当するのか、又は、単なる検索に該当するのかを判定する。ユーザｉが、番組をザッピングする過程でユーザ端末１１８−ｉから選択信号が送られてそのコンテンツが検索ログに記録される場合もあり、一方で、ユーザｉが一定時間以上、その番組を閲覧する目的で視聴する場合もあるからである。閲覧ログ生成部４２０は、検索ログ生成部４１８から送られた検索ログのうち、ユーザ端末１１８−ｉからの選択信号による検索が閲覧に該当するものを、閲覧ログとして出力する。
【００５１】
メディアエンコーダ４２４は、データベースサーバ１２４からリアルタイムビデオストリーム信号を受信し、受信したアルタイムビデオストリーム信号を配信のためにエンコードし、カプセル化する。エンコードは、Ｈ．２６４ビデオ及びＨＥ−ＡＡＣオーディオ等の、ユーザ端末１１８−ｉによって受信可能なフォーマットで行われる。受信可能な配信フォーマットは、ＭＰＥＧ−２トランスポートストリームである。メディアエンコーダ４２４は、ＬＡＮを介して、ストリームセグメンタ４２２に、ＭＰＥＧ−２トランスポートストリームで、エンコードされたリアルタイムビデオストリームパケットを送信する。ストリームセグメンタ４２２は、メディアエンコーダ４２４からの入力に基づいて、Ｈ．２６４ビデオストリームを搬送するＭＰＥＧ−２トランスポートストリームの複数のセグメントを含む複数のトランスポートストリーム（ｔｓ）ファイルからなる複数のビデオストリームセグメントファイルを生成する。
【００５２】
（４）  データベースサーバ
図５は、データベースサーバ１２４のハードウェア構成を示す図である。
【００５３】
データベースサーバ５００は、コンテンツ検索情報データベース５０２と、ユーザ閲覧ログデータベース５０４と、ユーザ検索ログデータベース５０６と、ユーザ個人情報データベース５０８と、コンテンツデータベース５１０と、フラグメント―ポインタ対応テーブル５１２と、ＳＮＳサービスプロバイダアドレスデータベース５１４と、ユーザ投稿履歴データベース５１６とを含む。コンテンツ検索情報データベース５０２と、ユーザ閲覧ログデータベース５０４と、ユーザ検索ログデータベース５０６と、ユーザ個人情報データベース５０８は、“ユーザｉｄ”ｉによって索引付されるユーザ情報エリアを形成し、コンテンツデータベース５１０と、フラグメント―ポインタ対応テーブル５１２は、“コンテンツｉｄ”ｌによって索引付されるコンテンツエリアを形成し、ＳＮＳサービスプロバイダアドレスデータベース５１４と、ユーザ投稿履歴データベース５１６は、ＳＮＳサービスプロバイダ情報エリアを形成する。
【００５４】
コンテンツ検索情報データベース５０２は、検索情報生成部４１６が生成した、ユーザ端末１１８−ｉからの選択信号に応答して検索されたコンテンツのシーケンスに関する情報を格納している。検索されたコンテンツのシーケンスに関する情報は、“ユーザｉｄ”ｉと関連させた形で格納されている。ユーザ検索ログデータベース５０６は、検索ログ生成部４１８が検索されたコンテンツのシーケンスに関する情報に検索の年月日及び時間を付与して生成した検索ログを格納している。検索ログは、“ユーザｉｄ”ｉと関連させた形で格納されている。ユーザ閲覧ログデータベース５０４は、閲覧ログ生成部４２０が検索ログのうちユーザ端末１１８−ｉからの選択信号による検索が閲覧に該当するものを抽出して生成した閲覧ログを格納している。ユーザ個人情報データベース５０８は、各“ユーザｉｄ”ｉについて、ユーザｉの個人情報、すなわち、ユーザｉの性別、年齢、住所、職業、使用端末、クレジットの有無、ポイント残高、ｅ−ｍａｉｌの送付の有無等を格納している。
【００５５】
コンテンツデータベース５１０は、“コンテンツｉｄ”ｌごとに、リアルタイムビデオストリームを任意の長さに分割したビデオストリームフラグメントという単位で、コンテンツを格納している。各ビデオストリームフラグメントは、フラグメントごとの符号化データと、その符号化データごとに付されたヘッダからなる。リアルタイムビデオストリームの配信は、ビデオストリームフラグメント単位で行われてもよい。フラグメント―ポインタ対応テーブル５１２は、各ビデオストリームフラグメントとそのフラグメントのコンテンツデータベース５１０内での格納場所を指定するポインタとの対応関係を格納している。
【００５６】
ＳＮＳサービスプロバイダアドレスデータベース５１４は、ＳＮＳサービスプロバイダ１１６ごとにそのアドレス情報を格納している。ユーザ投稿履歴データベース５１６は、“ユーザｉｄ”ｉと関連付けて、ユーザｉが投稿したビデオストリームフラグメントの系列を格納している。
【００５７】
（５）  ＳＮＳサーバ、データベースサーバ、及びＷｅｂサーバ
図６は、ＳＮＳサーバ１２８のハードウェア構成を示す図である。
【００５８】
ＳＮＳサーバ６００は、ＣＰＵ６０２と、メモリ６０４と、記憶装置６０６と、入力部６０８と、出力部６１０と、送受信インターフェイス（Ｉ／Ｆ）６１２と、ビデオストリームフラグメント受信部６１４と、メッセージ受信部６１６と、メッセージ掲載部６１８と、ビデオストリームフラグメント掲載部６２０とを含む。ＣＰＵ６０２と、メモリ６０４と、記憶装置６０６と、入力部６０８と、出力部６１０と、送受信インターフェイス（Ｉ／Ｆ）６１２は、コンテンツ配信サーバ１２２のものと同様である。
【００５９】
ビデオストリームフラグメント受信部６１４は、コンテンツプロバイダ１１４又はユーザ端末１１８−ｉから、Ｔｗｉｔｔｅｒ（商標）等のＳＮＳサイトに投稿されたビデオストリームフラグメントを受信する。ビデオストリームフラグメント受信部６１４は、コンテンツプロバイダ１１４と連携することができ、ユーザ端末１１８−ｉがコンテンツプロバイダ１１４を介してＳＮＳサービスプロバイダ１１６にビデオストリームフラグメントの投稿リクエストを送信する場合には、コンテンツプロバイダ１１４から投稿されたビデオストリームフラグメントを受信してもよい。また、ビデオストリームフラグメント受信部６１４は、ユーザ端末１１８−ｉがビデオストリームフラグメントをコンテンツプロバイダ１１４からダウンロードし、その後、アップロードする場合には、ユーザ端末１１８−ｉから投稿されたビデオストリームフラグメントを受信してもよい。メッセージ受信部６１６は、ユーザ端末１１８−ｉから、投稿されたメッセージを受信する。メッセージ掲載部６１８は、受信したメッセージをＳＮＳサイトに掲載する。ビデオストリームフラグメント掲載部６２０は、投稿されたビデオストリームフラグメントをＳＮＳサイトに掲載する。
【００６０】
図７は、データベースサーバ１３０のハードウェア構成を示す図である。
【００６１】
データベースサーバ７００は、メッセージ投稿履歴データベース７０２と、ビデオストリームフラグメント投稿履歴データベース７０４と、ユーザ個人情報データベース７０６と、メッセージデータベース７０８と、ビデオストリームフラグメントデータベース７１０と、コンテンツプロバイダアドレスデータベース７１２と、ユーザ投稿履歴データベース７１４とを含む。メッセージ投稿履歴データベース７０２と、ビデオストリームフラグメント投稿履歴データベース７０４と、ユーザ個人情報データベース７０６は、“ユーザｉｄ”ｉによって索引付されるユーザ情報エリアを形成し、メッセージデータベース７０８とビデオストリームフラグメントデータベース７１０は、ＳＮＳエリアを形成し、コンテンツプロバイダアドレスデータベース７１２とユーザ投稿履歴データベース７１４は、コンテンツプロバイダ情報エリアを形成する。
【００６２】
メッセージ投稿履歴データベース７０２は、各“ユーザｉｄ”ｉについて、ユーザｉがＳＮＳサービスプロバイダ１１６に投稿したメッセージのシーケンスを、投稿した年月日及び時間を付して格納する。ビデオストリームフラグメント投稿履歴データベース７０４は、各“ユーザｉｄ”ｉについて、ユーザｉがＳＮＳサービスプロバイダ１１６に投稿したビデオストリームフラグメントのシーケンスを、投稿した年月日及び時間を付して格納する。ユーザ個人情報データベース７０６は、各“ユーザｉｄ”ｉについて、ユーザｉの性別、年齢、住所、職業、使用端末、クレジットの有無、ポイント残高、ｅ−ｍａｉｌの送付の有無等を格納する。
【００６３】
メッセージデータベース７０８は、投稿され、ＳＮＳサイトに掲載されるメッセージを格納し、ビデオストリームフラグメントデータベース７１０は、投稿され、ＳＮＳサイトに掲載されるビデオストリームフラグメントを格納する。コンテンツプロバイダアドレスデータベース７１２は、コンテンツプロバイダ１１４ごとにそのアドレス情報を格納している。ユーザ投稿履歴データベース７１４は、“コンテンツｉｄ”ｌで識別されるコンテンツごとに、及び投稿されたメッセージごとに、そのコンテンツを投稿した“ユーザｉｄ”のシーケンス、及びそのメッセージを投稿した“ユーザｉｄ”のシーケンスを格納している。
【００６４】
図８は、Ｗｅｂサーバ１２０及び１２６のハードウェア構成を示す図である。
【００６５】
Ｗｅｂサーバ４００は、ＣＰＵ４０２と、メモリ４０４と、記憶装置４０６と、入力部４０８と、送受信インターフェイス４１０と、出力部４１２とを含む。ＣＰＵ６０２と、メモリ６０４と、記憶装置６０６と、入力部６０８と、出力部６１０と、送受信インターフェイス（Ｉ／Ｆ）６１２は、コンテンツ配信サーバ１２２のものと同様である。
【００６６】
（６）  リアルタイムビデオストリームの配信
図１０は、データベースサーバ１２４のコンテンツデータベース５１０におけるリアルタイムビデオストリームの格納の様子を示す図である。
【００６７】
コンテンツデータベース５１０は、“コンテンツｉｄ”ｌごとに、リアルタイムビデオストリームを任意の長さに分割したビデオストリームフラグメントという単位で、コンテンツを格納している。この格納方法は、ユーザ端末１１８−ｉでリアルタイムビデオストリームを視聴中に、そのリアルタイムビデオストリームの任意の位置のビデオストリームフラグメントのＳＮＳサイトへの投稿を、ユーザ端末１１８−ｉのみを用いて簡単な方法で可能にする。各ビデオストリームフラグメントは、フラグメントごとの符号化データと、その符号化データごとに付されたヘッダと、ファイルの固有のタイプを示すプレフィックス部分からなる。
【００６８】
プレフィックス部分９０２には、格納するデータの種類に応じて、例えば、アルファベット４文字からなる固有のタイプが割り当てられてもよい。ヘッダ部分９０４は、符号化データのフレームサイズ、再生時間の長さ、符号化データの格納位置を示すアドレス情報、及び復号や表示時刻等のヘッダ情報を格納している。ここで、例えば、１つのリアルタイムビデオストリームセグメントに１つのヘッダ部分のみを設けることとすると、ヘッダ情報がその１つのヘッダ部分に格納されることから、リアルタイムビデオストリームの再生時間長に比例してヘッダ部分のサイズが増加する。その結果、プログレッシブダウンロードのように、ダウンロードしながら再生する場合でも、再生開始前にヘッダ部分を取得する必要があり、再生時間までの待ち時間が長くなるなどの問題がある。従って、本実施形態においては、ヘッダ部分９０４は、各ビデオストリームフラグメントごとに設けられる。
【００６９】
符号化データは、フレーム単位で、音声フレームとビデオフレームとを交互に、復号順に格納される。符号化データは、再生時には、ヘッダ部分を参照して所望の再生時刻に相当するフレームの格納アドレスを特定することにより、そのアドレスに基づいてフレームデータとして取得される。
【００７０】
図１１は、ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ）プロトコルに従ったリアルタイムビデオストリームの配信を示す図である。
【００７１】
ＲＴＰプロトコルは、映像や音声などのリアルタイムデータをパケット化してＩＰネットワーク上で伝送するためのプロトコルである。ＲＴＰプロトコルに従ったストリーミングにおいては、ユーザ端末１１８−ｉは、以下のような手順でコンテンツ配信サーバ１２２に蓄積されたコンテンツを受信する。すなわち、
手順１．  ビデオ及び音声の符号化データを取得するためのコンテンツ配信サーバ１２２のアドレス情報を取得する。
【００７２】
手順２．  ユーザ端末１１８−ｉとコンテンツ配信サーバ１２２との間のセッションを確立する。
【００７３】
手順３．  ビデオ及び音声の符号化データを格納したＲＴＰパケットを受信する。
【００７４】
コンテンツ配信サーバとユーザ端末１１８−ｉとの間の通信制御を行うためのプロトコルは、例えば、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）を使用することができ、再生開始、終了、一時停止等の再生制御を、ＲＴＳＰに従ったコマンドとして実行することができる。ＲＴＳＰデータの送受信には、ＲＴＰと別の通信チャネルを使用し、下位層には信頼性の高い転送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ））を使用することができる。
【００７５】
図１２は、ＲＴＰパケットのデータ構造を示す図である。
【００７６】
ＲＴＰヘッダ部分１２０２は、ＲＴＰペイロード１２０４に格納されるビデオ符号化データ及び音声符号化データの識別情報や再生時刻、伝送するリアルタイムビデオストリームの種類を示す値であるペイロードタイプ、ＲＴＰパケットのカウンタであるシーケンス番号、及びペイロードデータの先頭バイトのサンプリング時刻であるタイムスタンプ等を含んでいる。ＲＴＰペイロード部分１２０４は、ペイロードヘッダ１２０６とペイロードデータ１２０８とからなり、ペイロードヘッダ１２０６は、符号化方式に固有のヘッダ情報を含み、ペイロードデータ１２０８は、符号化データを格納している。ペイロード部分１２０８におけるデータの格納方式であるペイロードフォーマットは、Ｈ．２６４やＡＡＣ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）等の符号化方式ごとのフォーマットを採用することができる。
【００７７】
図１３は、ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）プロトコルストリーミングを示す図である。
【００７８】
ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇプロトコルストリーミングは、コンテンツ配信サーバ１２２の側で、配信したい動画ファイルをエンコードし、分割を行い、同時にどの順番でファイルを再生すべきかを示すプレイリストファイルを作成することを必要とする。コンテンツ配信サーバ１２２のメディアエンコーダ４２４が、配信する動画をＨ．２６４／ＡＡＣフォーマットにエンコードし、ＭＰＥＧ２−ＴＳフォーマットのファイルに変換し、ストリームセグメンタ４２２が、指定された秒数ごとにファイルを分割し、同時にプレイリストを含むインデックスファイルを生成する。ユーザ端末１１８−ｉは、プレイリストを含むインデックスファイルに従って、分割されたファイルを順番にＨＴＴＰでダウンロードすることによって、動画を再生することができる。
【００７９】
メディアエンコーダ４２４は、データベースサーバ１２４からリアルタイムビデオストリーム信号を受信し、受信したアルタイムビデオストリーム信号を配信のためにエンコードし、カプセル化する。エンコードは、Ｈ．２６４ビデオ及びＨＥ−ＡＡＣオーディオ等の、ユーザ端末１１８−ｉによって受信可能なフォーマットで行われる。受信可能な配信フォーマットは、ＭＰＥＧ−２トランスポートストリームである。メディアエンコーダ４２４は、リアルタイムビデオストリームをエンコードしている最中に、ビデオデータの大きさやコーデックタイプといったリアルタイムビデオストリームの設定を変更することはなく、リアルタイムビデオストリームの設定の変更が不可避である場合には、メディアエンコーダ４２４は、セグメントの境界でリアルタイムビデオストリームの設定を変更し、後続のセグメントに所定のタグを設定する。メディアエンコーダ４２４は、ＬＡＮを介して、ストリームセグメンタ４２２に、ＭＰＥＧ−２トランスポートストリームで、エンコードされたリアルタイムビデオストリームパケットを送信する。ストリームセグメンタ４２２は、メディアエンコーダ４２４からの入力に基づいて、Ｈ．２６４ビデオストリームを搬送するＭＰＥＧ−２トランスポートストリームの複数のセグメントを含む複数のトランスポートストリーム（ｔｓ）ファイルからなる複数のビデオストリームセグメントファイルを生成する。ストリームセグメンタ４２２は、複数のメディアファイルのプレイリストを含むインデックスファイル（Ｍ３Ｕ８）を生成する。インデックスファイルは、これらの複数のメディアファイルの利用可能性に関する情報及び位置を取得するのに使用される。
【００８０】
ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇでは、図１３に示されている“Ｌｏｗ  Ｑｕａｌｉｔｙ”、“Ｍｉｄｄｌｅ  Ｑｕａｌｉｔｙ”、及び“Ｈｉｇｈ  Ｑｕａｌｉｔｙ”等の異なる帯域幅（シンボルレート）の動画を用意し、インデックスファイルにその情報を記述することができる。このことは、動画を再生するユーザ端末１１８−ｉが、自身の環境に応じて、帯域幅の異なる動画に切り替える事を可能とする。
【００８１】
図１４は、ユーザ端末１１８−ｉとコンテンツ配信サーバ１２２との間のセッションの確立を示すシーケンス図である。
【００８２】
ＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２は、ＳＣＨ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ）を介して、ユーザ端末１１８−ｉによるセルサーチに使用される同期信号を送信する。ユーザ端末１１８−ｉは、同期をとるためにＳＣＨをサーチし、捕捉する（ステップＳ１４０２）。ユーザ端末１１８−ｉは、ＳＣＨを補足すると、同期を確立し、セルｉｄを取得する。ＮｏｄｅＢ１１０及びｅＮｏｄｅＢ１１２は、ＰＢＣＨ（Ｐｈｙｓｉｃａｌ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）を介して、ユーザ端末１１８−ｉがセルサーチの後に最初に読むべきシステム帯域幅、システムフレーム番号、及び送信アンテナの数等の最低限の情報を含む信号を送信している。ユーザ端末１１８−ｉは、Ｐ−ＢＣＨ（Ｐｒｉｍａｒｙ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）を補足することにより、システム帯域幅、システムフレーム番号、及び送信アンテナの数等のＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２に特有の情報を取得する（ステップＳ１４０４）。ユーザ端末１１８−ｉは、Ｄ−ＢＣＨ（Ｄｙｎａｍｉｃ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）を補足することにより、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）に関する情報を取得し、ＰＲＡＣＨの周波数位置を特定する（ステップＳ１４０６）。ユーザ端末１１８−ｉは、ステップＳ１４０６で得られたアップリンク周波数帯及びＰＲＡＣＨの周波数位置に基づいて、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２にＲＡＣＨプリアンブルを送信する（ステップＳ１４０８）。
【００８３】
ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ユーザ端末１１８−ｉからＲＡＣＨプリアンブルを受信し、適応ビット割当処理を行う（ステップＳ１４１０）。ＲＡＣＨプリアンブルシンボルから推定された通信チャネル条件に基づいて、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、すべてのユーザ端末１１８−ｉに対して適切な周波数スロット及びビットを割り当てるための適応割り当て手順を開始し、システムチャネル容量を最大化する。ｊ（ｊ＝１，…，Ｎｃ）をサブキャリアの番号、ｍ（ｍ＝１，…，Ｎｍ）を変調スキームの種類を示す番号、Ｈ（ｉ，ｊ）を、プリアンブルシンボルに基づいてパイロットトーンで構造化されたアップリンクＲＡＣＨプリアンブルシンボルを使用して推定された通信チャネル周波数応答とすると、マルチパスフェージング環境下でサブキャリアｊでのユーザ端末１１８−ｉについてのキャリア対雑音電力比（ＣＮＲ）は、
0006709624.tif 000002
と推定することができる。ここで、変数ｍは、例えば、変調スキームがＢＰＳＫである場合には、ｍ＝１、ＱＰＳＫである場合には、ｍ＝２、８値ＰＳＫである場合には、ｍ＝３、１６値ＱＡＭである場合には、ｍ＝４、３２値ＱＡＭである場合には、ｍ＝５、１２８値ＱＡＭである場合には、ｍ＝７となり、１シンボルで送ることができるビット数を示す。
【００８４】
Ｑ（）を誤差補関数とすると、推定されたキャリア対雑音電力比Ｒ（ＣＮＲ）（ｉ，ｊ，ｍ）を用いて、ｍビット変調スキームを使用する際のサブキャリアｊでのユーザ端末１１８−ｉについてのビットエラー率（ＢＥＲ）特性の予測値Ｅ（ＢＥＲ）（ｉ，ｊ，ｍ）は、
0006709624.tif 000003
となる。ここで、
0006709624.tif 000004
である。
【００８５】
ｓ（ｓ＝１，…，Ｎｓ）を周波数スロットの番号、Ｎｓを割り当てられた周波数帯域内の利用可能な周波数スロットの数、Ｎｃ／Ｎｓを１周波数スロットに含まれるサブキャリアの数とすると、対象となるスロットｓにおいて最も悪いＢＥＲ特性を持つサブキャリアｊｍａｘは、
0006709624.tif 000005
となり、周波数スロットｓについて最も悪いＢＥＲ特性Ｂ（ＢＥＲ）（ｉ，ｓ，ｍ）は、
0006709624.tif 000006
となる。Ｎｐを１つのパケット内のバイト数とすると、スロットｓにおいてユーザ端末１１８−ｉにｍビットの変調スキームを割り当てた際のパケットエラー率（ＰＥＲ）特性の予測値Ｅ（ＰＥＲ）（ｉ，ｍ，ｓ）は、
0006709624.tif 000007
となる。システム内で共通に要求される目標ＰＥＲ特性をＥ（ＰＥＲ）０とし、周波数スロットｓにおいて条件Ｅ（ＰＥＲ）（ｉ，ｓ，ｍ）≦Ｅ（ＰＥＲ）０を満たす最大のｍを各ユーザ端末１１８−ｉについて求めると、
0006709624.tif 000008
となり、Ｍｉ，ｓは、Ｎｕ×Ｎｓの行列となる。
【００８６】
すべての周波数スロットにわたって割り当て可能なビット数の総和をとることにより、各ユーザ端末１１８−ｉについての全体の通信チャネル条件Ｖｉは、
0006709624.tif 000009
と求まる。Ｖｉは、Ｎｕ×１の行列となる。行列Ｍｉ，ｓの各成分について、その成分が０の場合に対応する成分が０となり、その成分が０以外の整数となる場合に対応する成分が１となる行列をＡｉ，ｓと定義する。例えば、周波数スロットｓにおいてユーザ端末１１８−ｉに割り当て可能なビットが０ビットである場合、すなわち、ユーザ端末１１８−ｉがいずれの変調スキームを使用してもシステム内で共通に要求される目標ＰＥＲ特性Ｅ（ＰＥＲ）０を満たさないことにより、ユーザ端末１１８−ｉがその周波数スロットｓを使用できない場合、行列Ａｉ，ｓのｉ，ｓ成分は０となる。一方、周波数スロットｓにおいてユーザ端末１１８−ｉに割り当て可能なビットがｍビットである場合には、行列Ａｉ，ｓのｉ，ｓ成分は１となる。周波数スロットｓを利用可能なユーザ端末１１８−ｉの数により、スロットｓについての全体的な通信チャネル条件Ｗｓは、
0006709624.tif 000010
と求まる。
【００８７】
適切な周波数スロット及びビットが、行列Ｖｉ及びＷｓを使用して、以下の基準に従って各ユーザ端末１１８−ｉに適応的に割り当てられる。すなわち、
基準１．  より小さなＶｉの値をもつユーザ端末１１８−ｉは、割り当てにおいてより高い優先順位を有する。
【００８８】
基準２．  あるユーザ端末１１８−ｉについて、より小さなＷｓの値を有する周波数スロットは、割り当てにおいてより高い優先順位を有する。
【００８９】
上記の基準を使用することにより、より大きなＶｉ及びＷｓの値を有するユーザ端末１１８−ｉは優先順位が低くなるが、そのようにしてもより柔軟な周波数スロット割り当てを実現することができる。その理由は、より大きなＶｉ及びＷｓの値を有するユーザ端末１１８−ｉは、割り当ての順番が後になっても、周波数スロットの割り当てにおいてより多くの機会を有するからである。従って、周波数スロットが割り当てられないことによるユーザ端末１１８−ｉとの通信の途絶を低減することができる。
【００９０】
図１５は、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２とユーザ端末１１８−ｉとの間で行われる適応ビット割当処理のフローチャートである。
【００９１】
ステップＳ１５０４において、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“ユーザｉｄ”をｉ＝１に設定する。ステップＳ１５０６において、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“周波数スロットの番号”をｓ＝１に設定する。ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、パケットエラー率特性の初期値Ｅ（ＰＥＲ）０（ｉ，ｓ）をＥ（ＰＥＲ）０（ｉ，ｓ）＝０に設定する（ステップＳ１５０８）。ステップＳ１５１０において、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“変調スキームの種類”をｍ＝１に設定する。ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ビットエラー率の初期値Ｅ（ＢＥＲ）０をＥ（ＢＥＲ）０＝０に設定する。ステップＳ１５０４において、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“サブキャリアの番号”をｊ＝１に設定する。
【００９２】
ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ユーザ端末１１８−ｉから受信したアップリンクＲＡＣＨプリアンブルシンボルに基づいて、変調スキームの種類ｍの場合に、サブキャリアｊでのユーザ端末１１８−ｉについて、キャリア対雑音電力比Ｒ（ＣＮＲ）（ｉ，ｊ，ｍ）を推定する（ステップＳ１５１６）。ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、キャリア対雑音電力比Ｒ（ＣＮＲ）（ｉ，ｊ，ｍ）を使用してビットエラー率特性Ｅ（ＢＥＲ）（ｉ，ｊ，ｍ）を予測する（ステップＳ１５１８）。ビットエラー率特性がＥ（ＢＥＲ）（ｉ，ｊ，ｍ）＞Ｅ（ＢＥＲ）０を満たす場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、Ｅ（ＢＥＲ）０←Ｅ（ＢＥＲ）（ｉ，ｊ，ｍ）（変数Ｅ（ＢＥＲ）０に、Ｅ（ＢＥＲ）（ｉ，ｊ，ｍ）の値を代入する処理を意味する。以下、同じ。）及びｊｍａｘ←ｊの処理を行う（ステップＳ１５２０）。
【００９３】
ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“サブキャリアの番号”ｊがｓ（Ｎｃ＋１）／Ｎｓよりも小さいか否かを判定する（ステップＳ１５２２）。“サブキャリアの番号”ｊがｓ（Ｎｃ＋１）／Ｎｓよりも小さい場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ｊ←ｊ＋１の処理を行い（ステップＳ１５２４）、処理は、ステップＳ１５１６に戻る。
【００９４】
“サブキャリアの番号”ｊがｓ（Ｎｃ＋１）／Ｎｓ以上である場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ｊｍａｘの値を使用して、スロットｓについて最も悪いＢＥＲ特性“Ｂ（ＢＥＲ）（ｉ，ｓ，ｍ）”を求め、パケットエラー率特性Ｅ（ＰＥＲ）（ｉ，ｓ，ｍ）を予測する（ステップＳ１５２６）。パケットエラー率特性が、Ｅ（ＰＥＲ）０（ｉ，ｓ）＜Ｅ（ＰＥＲ）（ｉ，ｓ，ｍ）≦Ｅ（ＰＥＲ）０を満たす場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、Ｅ（ＰＥＲ）０（ｉ，ｓ）←Ｅ（ＰＥＲ）（ｉ，ｓ，ｍ）及びｍｍａｘ（ｉ，ｓ）←ｍの処理を行う（ステップＳ１５２８）。ここで、Ｅ（ＰＥＲ）０は、システム内で共通に要求される目標ＰＥＲ特性であり、ｍｍａｘ（ｉ，ｓ）は、スロットｓにおけるユーザ端末１１８−ｉについての、条件Ｅ（ＰＥＲ）（ｉ，ｓ，ｍ）≦Ｅ（ＰＥＲ）０を満たす最大のｍである。
【００９５】
ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“変調スキームの種類”ｍがＮｍよりも小さいか否かを判定する（ステップＳ１５３０）。“変調スキームの種類”ｍがＮｍよりも小さい場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ｍ←ｍ＋１の処理を行い（ステップＳ１５３２）、処理は、ステップＳ１５１２に戻る。変調スキームの種類”ｍがＮｍ以上である場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、スロットｓにおける各ユーザ端末１１８−ｉのｍｍａｘ（ｉ，ｓ）を格納する（ステップＳ１５３４）。ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“周波数スロットの番号”ｓがＮｓよりも小さいか否かを判定する（ステップＳ１５３６）。“周波数スロットの番号”ｓがＮｓよりも小さい場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ｓ←ｓ＋１の処理を行い（ステップＳ１５３８）、処理は、ステップＳ１５０８に戻る。周波数スロットの番号”ｓがＮｓ以上である場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、“ユーザｉｄ”ｉがＮｕよりも小さいか否かを判定する（ステップＳ１５４０）。“ユーザｉｄ”ｉがＮｕよりも小さい場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ｉ←ｉ＋１の処理を行い（ステップＳ１５４２）、処理は、ステップＳ１５０６に戻る。“ユーザｉｄ”ｉがＮｕ以上である場合には、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、各ユーザ端末１１８−ｉについてのスロットの優先度、及び各ユーザ端末１１８−ｉのビット割当の優先度に従って、周波数スロット及び変調スキームのビットｍを適応的に割り当てる。
【００９６】
再び、図１４に戻り、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、周波数スロット、変調ビット、及びタイムスロットの割り当て情報をユーザ端末１１８−ｉに送信する（ステップＳ１４１２）。ユーザ端末１１８−ｉは、周波数スロット、変調シンボルのビット数、及びタイムスロットの割り当て情報の通知に対する応答をＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２に送信する（ステップＳ１４１４）。ユーザ端末１１８−ｉは、ビデオストリーム配信要求をＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２に送信し（ステップＳ１４１６）、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、そのビデオストリーム配信要求をコンテンツ配信サーバ１２２に送信する（ステップＳ１４１８）。この段階で、ユーザ端末１１８−ｉとコンテンツ配信サーバ１２２は、データ通信可能な状態となる（ステップＳ１４２０）。コンテンツ配信サーバ１２２は、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２に番組表を送信し（ステップＳ１４２２）、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ユーザ端末１１８−ｉにその番組表を送信する（ステップＳ１４２４）。
【００９７】
番組表は、例えば、図１６に示されているように構成してもよい。図示の例では、表示部２１０の横方向（長手方向）が各プログラムチャネルに対応し、縦方向が各時間帯に対応している。図１６に示されている番組表は、図示のように、長手方向、縦方向、及び斜め方向に自由にスクロールさせることができ、また、円を描くように回転させることも可能である。例えば、プログラムチャネルとしては、「Ａｂｅｍａ  Ｎｅｗｓ」、「Ｌｉｖｅ  Ｓｐｏｒｔｓ」、「Ｓｐｏｒｔ１」、及び「Ｓｐｏｒｔ２」がある。このうち、「Ａｂｅｍａ  Ｎｅｗｓ」及び「Ｌｉｖｅ  Ｓｐｏｒｔｓ」は、ライブ、すなわち、生中継である。「Ｓｐｏｒｔ１」及び「Ｓｐｏｒｔ２」は、生中継であっても録画であってもよい。
【００９８】
このように、本実施形態のビデオストリーム配信と従来のＶｉｄｅｏ  Ｏｎ−Ｄｅｍａｎｄ方式のストリーム配信との決定的な差異は、（１）番組表によって決められたスケジュールで各番組（プログラム）が配信され、（２）ライブ、すなわち、生中継を視聴することが可能であるという点である。本実施形態に従ったビデオストリーム配信によれば、プログラムの予約視聴、プログラムの予約録画を上記の番組表によってプログラムチャネル及び時間帯を指定することにより視聴することができ、過去に見逃したプログラムを番組表で指定することにより視聴することも可能である。
【００９９】
再び、図１４に戻ると、ユーザ端末１１８−ｉは、番組表の受信に応答して、ユーザｉが選択したプログラムが配信されているプログラムチャネルを示す選択信号をＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２に送信し（ステップＳ１４２６）、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、その選択信号をコンテンツ配信サーバ１２２に送信する（ステップＳ１４２８）。選択信号は、コンテンツ配信サーバ１２２が番組表に従って配信している生放送や録画放送等のプログラムを視聴しようとする場合、及びコンテンツ配信サーバ１２２が既に配信したプログラムを視聴しようとする場合（タイムシフト視聴）の双方の場合に、ユーザ端末１１８−ｉからＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２を介してコンテンツ配信サーバ１２２に送られる。選択信号は、現在配信されている又は将来配信されるプログラムを視聴しようとする場合には、選択するべきプログラムチャネルを指定するのに使用され、いわゆる、タイムシフト視聴の場合には、コンテンツを指定するのに使用される。選択信号を受信したコンテンツ配信サーバ１２２は、ユーザ端末１１８−ｉとの間でシンボルレート（帯域幅）ネゴシエーションを行う（ステップＳ１４３０）。
【０１００】
コンテンツ配信サーバ１２２とユーザ端末１１８−ｉとの間で行われる帯域幅ネゴシエーションは、例えば、ＲＴＰプロトコルに従ったリアルタイムビデオストリームの配信の場合には、階層型ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）制御機能により行われる。
【０１０１】
図１７は、ＲＴＰプロトコルに従った階層型ＱｏＳ制御機能の構成を示す図である。
【０１０２】
データベースサーバ１２４のコンテンツデータベース５１０は、例えば、Ｆ１［Ｇｂｐｓ］、Ｆ１［Ｇｂｐｓ］、Ｆ３［Ｇｂｐｓ］、…の複数の符号化レートで符号化されたコンテンツを格納しており、コンテンツ配信サーバ１２２とユーザ端末１１８−ｉとの間で帯域制御により転送レート調整を行う際に、コンテンツの選択によってデータ量を調節する。コンテンツ配信サーバ１２２は、コンテンツ情報やサーバ情報を記述するＭＶＸファイルを格納しており、ユーザ端末１１８−ｉとコンテンツ配信サーバ１２２との間のセッション確立時に帯域幅ネゴシエーション機能によって最適なコンテンツを選択する。コンテンツ情報やサーバ情報を記述するＭＶＸファイルには、そのコンテンツが保持するメディアデータの数や帯域幅の情報が記述されている。輻輳予測及び検出機能、転送レート制御機能、及び限定的再送機能は、フレーム間引型動画配信システムを同様であるが、輻輳予測及び検出機能で帯域幅の上げ下げが発生した場合には階層型コンテンツ選択機能によるコンテンツの切替えを行う。
【０１０３】
帯域幅ネゴシエーション機能は、ユーザ端末１１８−ｉがコンテンツ配信サーバ１２２との間の初期セッションを確立する際に、ユーザ端末１１８−ｉが接続されているモバイル通信ネットワーク１０４の状態から受信可能なシステム帯域幅を認識し、コンテンツ配信サーバ１２２に通知する機能である。ＲＴＰプロトコルに従った帯域幅ネゴシエーション機能は、ＲＴＳＰ及びＲＴＣＰによるセッション管理を行っており、ＲＴＳＰ及びＲＴＣＰを利用して初期セッション確立時に帯域幅ネゴシエーションを行う。コンテンツ配信サーバ１２２は、コンテンツとして保持している複数の階層型コンテンツの中で通知された帯域に最適なコンテンツを選択し配信を行う。
【０１０４】
フレーム間引型ＱｏＳ制御の転送レート制御機能は、フレームレート制御機能を用いて、動画フレームを間引く方式であったため、輻輳時に極端にフレームレートが低下する傾向があり、静止画面の連続の様な動画再生となって再生品質が低下する場合があった。これに対して、階層型ＱｏＳ制御は、転送レート制御機能の一機能として階層型コンテンツ選択機能を追加してあり、輻輳予測及び検出機能によって動的に利用可能な帯域幅が推定でき、階層型コンテンツ選択機能は、この帯域幅に基づいて動的に最適なコンテンツに切替えることにより、転送レートを制御する。このような階層型ＱｏＳ制御方式の転送レート制御は、フレーム間引型ＱｏＳ制御のようにフレームレートだけを調整して帯域を制御するものではないため、輻輳時でも再生側でフリーズ時間が発生しにくく、スムーズな再生が実現できる。
【０１０５】
図１８は、ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）プロトコルに従ったＱｏＳ制御機能の構成を示す図である。
【０１０６】
ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇの再生においては、ユーザ端末１１８−ｉがインデックスファイル（Ｍ３Ｕ８）のプレイリストを読み込み、分割された複数のメディアファイルにプレイリストに示された順番でアクセスし、再生を行う。最初に、先頭のインデックスファイルを読み込み、次に、インデックスファイルに記載されたメディアファイルのＵＲＬにアクセスして再生し、その次に記載されたメディアファイルのＵＲＬにアクセスして再生するといった手順で動画を順次再生する。最後に再び、インデックスファイルを読み込んで再生終了となる。そのため、通常のストリーミングの再生では、コネクションを確立したら再生終了までコネクションを切断する事はないが、ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇの再生においては、違うファイルにアクセスする度にコネクションの確立及び切断を繰り返す。
【０１０７】
ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇの再生においては、図１３に示されている“Ｌｏｗ  Ｑｕａｌｉｔｙ”、“Ｍｉｄｄｌｅ  Ｑｕａｌｉｔｙ”、及び“Ｈｉｇｈ  Ｑｕａｌｉｔｙ”等の異なる帯域幅（シンボルレート）の動画を用意し、インデックスファイルにその情報を記述することができる。このことは、動画を再生するユーザ端末１１８−ｉが、自身の環境に応じて、帯域幅の異なる動画に切り替える事を可能とする。例えば、ユーザ端末１１８−ｉを取り扱うモバイル通信ネットワーク１０４の環境が悪くなった場合等に、今よりも低い帯域幅の動画に切り替える事が可能である。また、異なる帯域幅の情報だけでなく、動画を配信するコンテンツ配信サーバ１２２が複数ある場合に、その情報をインデックスルファイルに記述することもできる。このことは、いずれかのコンテンツ配信サーバ１２２において障害が発生した場合等に、ビデオストリームの再生をすることができなくなっても、ユーザ端末１１８−ｉは、インデックスファイルに記述してある別のコンテンツ配信サーバ１２２にアクセスすることにより、動画の再生を可能とする。
【０１０８】
ＲＴＰプロトコルやＨＬＳプロトコルの他にも、ＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）に従ったＱｏＳ制御を行ってもよい。ＭＰＥＧ−ＤＡＳＨに従ったリアルタイムビデオストリームの配信においては、様々なユーザ端末１１８−ｉで動画を視聴する際に、帯域幅等のユーザの環境を考慮し、再生が途切れないようにシンボルレートを変動させることによって、システム帯域に対して最適な品質で動画を視聴することができる。例えば、モバイル通信ネットワーク１０４が混雑して帯域幅が狭い場合には、高ビットレートで動画を配信してしまうと再生が途切れてしまう可能性があるため、ビットレートを最適なものに変更し、再生が途切れないようにする。
【０１０９】
ビットレートの切替えを行うために、予めコンテンツプロバイダ１１４のデータベースサーバ１２４に複数のビットレートに対応したメディアファイルを用意しておき、これらについての情報をＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルに記載しておく。ユーザ端末１１８−ｉは、最初に、ＭＰＤファイルを取得し、解析を実行する。解析によりプログラムタイミングやメディアファイルの取得先、最大ビットレート及び最小ビットレート等のストリーミング配信に必要な情報を取得し、ＨＴＴＰ  ＧＥＴ要求を用いて、ビデオストリームセグメントを取得しストリーミングを開始する。ある程度バッファリングが行われた後に、システム帯域幅のモニタリングも行われ、この計測によってビットレートを決定し、十分なバッファ量を維持及び確保する。
【０１１０】
図１９は、コンテンツ配信サーバ１２２とユーザ端末１１８−ｉとの間で行われるシンボルレート（帯域幅）ネゴシエーションのシーケンス図である。
【０１１１】
コンテンツ配信サーバ１２２から番組表を受信したユーザ端末１１８−ｉは、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２を介してコンテンツ配信サーバ１２２に選択信号を送信する（ステップＳ１９１２、Ｓ１９１４）。選択信号を受信したコンテンツ配信サーバ１２２は、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２にそのプログラム（番組）の最も低いシンボルレートＦ１のリアルタイムビデオストリームを送信し（ステップＳ１９１６）、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ユーザ端末１１８−ｉにそのリアルタイムビデオストリームを送信する（ステップＳ１９１８）。ユーザ端末１１８−ｉは、受信した最も低いシンボルレートＦ１のリアルタイムビデオストリームを復調及び復号し、ビットエラー率を推定する（ステップＳ１９２０）。ユーザ端末１１８−ｉは、推定したビットエラー率に基づいて受信シンボルレートＦ１を上げるか否かの判定を行う（ステップＳ１９２２）。このとき、推定したビットエラー率が極めて低く、信号電力対雑音電力比（ＳＮＲ）の推定が困難な場合には、ユーザ端末１１８−ｉは、伝送シンボルレートを上げ、且つ、変調指数の小さくして送信するように、コンテンツ配信サーバ１２２に要求する。ユーザ端末１１８−ｉは、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２にシンボルレート増大要求信号を送信し（ステップＳ１９２４）、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、コンテンツ配信サーバ１２２にそのシンボルレート増大要求信号を送信する（ステップＳ１９２６）。シンボルレート増大要求信号を受信したコンテンツ配信サーバ１２２は、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２にそのプログラムの次に低いシンボルレートＦ２のリアルタイムビデオストリームを送信し（ステップＳ１９２８）、ＮｏｄｅＢ１１０又はｅＮｏｄｅＢ１１２は、ユーザ端末１１８−ｉにそのリアルタイムビデオストリームを送信する（ステップＳ１９３０）。この手順を繰り返すことにより、ユーザ端末１１８−ｉが取り扱われているモバイル通信ネットワークのその時点での環境下で受信可能な最も高いシンボルレートが決定される。
【０１１２】
再び、図１４に戻り、ユーザ端末１１８−ｉが取り扱われているモバイル通信ネットワークのその時点での環境下で受信可能な最も高いシンボルレートが決定されると、コンテンツ配信サーバ１２２は、その決定されたシンボルレートで選択されたプログラムのリアルタイムビデオストリームの配信を開始する（ステップＳ１４３２）。
【０１１３】
（７）  プログラム視聴中のザッピング動作
図２０は、ユーザ端末１１８−ｉでのプログラム視聴中のザッピング動作のフローチャートである。図２１及び図２２は、ユーザ端末１１８−ｉの表示部２１０上での横方向（長手方向）のザッピングの様子を示す図である。図２３は、ユーザ端末１１８−ｉの表示部２１０上での縦方向のザッピングの様子を示す図である。
【０１１４】
図２１の上の図に示されているように、横方向のザッピング動作では、ユーザ端末１１８−ｉとコンテンツ配信サーバ１２２との間のセッションが確立され、選択されたプログラムチャネルのリアルタイムビデオストリームの受信を開始した後は、その選択した主プログラムチャネルが中央の部分に表示され、主プログラムチャネルの２つの隣接プログラムチャネルが、主プログラムチャネルの左右の部分に表示されている。この状態において、選択した主プログラムチャネルは、高いシンボルレートで受信及び再生され、２つの隣接プログラムチャネルは、主プログラムチャネルのシンボルレートよりも低いシンボルレートで受信及び再生されている。２つの隣接プログラムチャネルは、主プログラムチャネルよりも小さく表示される。図２３の左の図においても同様に、その選択した主プログラムチャネルが中央の部分に表示され、主プログラムチャネルの２つの隣接プログラムチャネルが、主プログラムチャネルの上下の部分に表示されている。同様に、選択した主プログラムチャネルは、高いシンボルレートで受信及び再生され、２つの隣接プログラムチャネルは、主プログラムチャネルのシンボルレートよりも低いシンボルレートで受信及び再生されている。２つの隣接プログラムチャネルは、主プログラムチャネルよりも小さく表示される。
【０１１５】
ユーザｉが、図示するように、指で主プログラムチャネルの表示位置を一方の方向に移動させようとすると、ユーザ端末１１８−ｉは、主プログラムチャネルの表示位置の移動を、入力部２０８へのユーザｉによる入力として検出する（ステップＳ２００４）。ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量をモニタリングする（ステップＳ２００６）。ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上となったか否かを判定する（ステップＳ２００８）。主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上となっていない場合には、処理は、ステップＳ２００６に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量のモニタリングを継続する。主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上となっている場合には、ユーザ端末１１８−ｉのＣＰＵ２１６は、移動方向である一方の方向の隣接プログラムチャネルの受信及び再生を終了する（ステップＳ２０１０）。この時点の状態は、図２１の下の図及び図２３の中央の図に示されている。
【０１１６】
一方の方向の隣接プログラムチャネルの受信及び再生を終了した後、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量をモニタリングする（ステップＳ２０１２）。ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量が第２の閾値ｘ２以上となったか否かを判定する（ステップＳ２０１４）。主プログラムチャネルの表示位置の移動量が第２の閾値ｘ２以上となっていない場合には、ユーザ端末１１８−ｉのＣＰＵ２１６は、再び、主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上であるか否かを判定する（ステップＳ２０１６）。主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上である（ｘ１≦（主プログラムチャネルの表示位置の移動量）＜ｘ２）場合には、処理は、ステップＳ２０１２に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、最初の移動方向である一方の方向の隣接プログラムチャネルの受信及び再生を終了した後の主プログラムチャネルの表示位置の移動量のモニタリングを継続する。主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１より小さくなってしまった（（主プログラムチャネルの表示位置の移動量）＜ｘ１）場合には、ユーザ端末１１８−ｉのＣＰＵ２１６は、最初の移動方向である一方の方向の隣接プログラムチャネルの受信及び再生を再び開始し（ステップＳ２０１８）、処理は、ステップＳ２００６に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量のモニタリングを継続する。この状態は、ユーザｉが、一旦、主プログラムチャネルの表示位置を第１の閾値ｘ１を超えて移動させたが、その後、主プログラムチャネルの表示位置の移動量を第１の閾値ｘ１より小さくなるように戻してしまったということを意味する。
【０１１７】
ステップＳ２０１４で、主プログラムチャネルの表示位置の移動量が第２の閾値ｘ２以上である場合には、最初の移動方向である一方の方向とは反対方向の他方の方向の隣接プログラムチャネルのさらに隣の隣接プログラムチャネルの受信及び再生を開始する（ステップＳ２０２０）。この時点の状態は、図２２の下の図及び図２３の右の図に示されている。一方の方向と反対方向の他方の方向の隣接プログラムチャネルのさらに隣の隣接プログラムチャネルの受信及び再生を開始した後に、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量をモニタリングする（ステップＳ２０２２）。ユーザ端末１１８−ｉのＣＰＵ２１６は、最初の移動方向である一方の方向とは反対方向の他方の方向の隣接プログラムチャネルが主プログラムチャネルの初期位置（中央の部分）に達したか否かを判定する（ステップＳ２０２４）。一方の方向とは反対方向の他方の方向の隣接プログラムチャネルが主プログラムチャネルの初期位置（中央の部分）に達している場合には、ユーザ端末１１８−ｉのＣＰＵ２１６は、最初の移動方向である一方の方向とは反対方向の他方の方向の隣接プログラムチャネルを高いシンボルレートで受信及び再生して精密な動画とするとともに、元の主プログラムチャネルを低いシンボルレートで受信及び再生して粗い動画を表示する（ステップＳ２０２８）。この時点の状態では、最初の移動方向である一方の方向とは反対方向の他方の方向の隣接プログラムチャネルが主プログラムチャネルになったということであり、ユーザ端末１１８−ｉのＣＰＵ２１６は、その隣接プログラムチャネルを指定する選択信号を生成し、コンテンツ配信サーバ１２２に送信する。コンテンツ配信サーバ１２２の検索ログ生成部４１８は、検索ログを生成し、その検索ログをデータベースサーバ１２４に送信し、データベースサーバ１２４は、その検索ログをユーザ検索ログデータベース５０６に格納する。
【０１１８】
ステップＳ２０２４で、最初の移動方向である一方の方向とは反対方向の他方の方向の隣接プログラムチャネルが主プログラムチャネルの初期位置（中央の部分）に達していない場合には、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量が第２の閾値ｘ２以上であるか否かを判定する（ステップＳ２０２６）。主プログラムチャネルの表示位置の移動量が第２の閾値ｘ２以上である場合には、処理は、ステップＳ２０２２に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量のモニタリングを継続する。ステップＳ２０２６で、主プログラムチャネルの表示位置の移動量が第２の閾値ｘ２よりも小さくなった場合には、処理は、ステップＳ２０１６に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、再び、主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上であるか否かを判定する。
【０１１９】
主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１以上である（ｘ１≦（主プログラムチャネルの表示位置の移動量）＜ｘ２）場合には、処理は、ステップＳ２０１２に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、一方の方向の隣接プログラムチャネルの受信及び再生を終了した後の主プログラムチャネルの表示位置の移動量のモニタリングを継続する。この状態は、ユーザｉが、一旦、主プログラムチャネルの表示位置を第２の閾値ｘ２を超えて移動させたが、その後、主プログラムチャネルの表示位置の移動量を第２の閾値ｘ２より小さくなるように戻してしまったということを意味する。
【０１２０】
主プログラムチャネルの表示位置の移動量が第１の閾値ｘ１より小さくなってしまった（（主プログラムチャネルの表示位置の移動量）＜ｘ１）場合には、ユーザ端末１１８−ｉのＣＰＵ２１６は、最初の移動方向である一方の方向の隣接プログラムチャネルの受信及び再生を再び開始し（ステップＳ２０１８）、処理は、ステップＳ２００６に戻り、ユーザ端末１１８−ｉのＣＰＵ２１６は、主プログラムチャネルの表示位置の移動量のモニタリングを継続する。この状態は、ユーザｉが、一旦、主プログラムチャネルの表示位置を第２の閾値ｘ２を超えて移動させたが、その後、主プログラムチャネルの表示位置の移動量を第１の閾値ｘ１より小さくなるように戻してしまったということを意味する。
【０１２１】
（８）  ビデオストリームフラグメントのＳＮＳへの拡散
本実施形態に従ったユーザ端末１１８−ｉは、リアルタイムビデオストリームの視聴中に、そのリアルタイムビデオストリームの任意の再生時間を指定して、ＳＮＳサービスプロバイダ１１６を介して、その指定した再生時間に対応するビデオストリームフラグメントをＳＮＳサイトに投稿することができる。図２７乃至図２９は、指定した再生時間に対応するビデオストリームフラグメントをＳＮＳサイトに投稿する際の操作を示す図である。
【０１２２】
図２７に示されるように、ユーザｉがユーザ端末１１８−ｉの表示部２１０の画面の右下の部分にある紙飛行機のマークをタッチすると、コメントを入力できる拡散画面が表示される。図２８に示されているように、ユーザｉがコメントを入力した後、画面の右下の部分のツィートという表示にタッチすると、ＳＮＳサイトに指定した再生時間に対応するビデオストリームフラグメントとコメントが掲載される。
【０１２３】
図２４は、ビデオストリームフラグメントのＳＮＳへの拡散の第１の実施形態を示すシーケンス図である。
【０１２４】
コンテンツプロバイダ１１４のコンテンツ配信サーバ１２２は、第１のユーザ端末１１８−ｉ１に対してリアルタイムビデオストリームを配信している（ステップＳ２４０２）。この際、第１のユーザ端末１１８−ｉ１は、リアルタイムビデオストリームを受信した後に、一時的にその受信したリアルタイムビデオストリームをバッファリングし、受信した時点から所定時間（約２秒）後にバッファリングしたリアルタイムビデオストリームを再生する。ユーザｉがリアルタイムビデオストリーム視聴中に再生時刻に対応するビデオストリームフラグメントを指定すると、第１のユーザ端末１１８−ｉ１は、コンテンツプロバイダ１１４にビデオストリームフラグメント選択信号を送信する（ステップＳ２４０４）。ここで、第１のユーザ端末１１８−ｉ１が受信したＲＴＰヘッダ部分１２０２は、ＲＴＰパケットのカウンタであるシーケンス番号、及びペイロードデータの先頭バイトのサンプリング時刻であるタイムスタンプ等を含んでいるので、第１のユーザ端末１１８−ｉ１は、指定したビデオストリームフラグメントを指定する情報として、シーケンス番号及びタイムスタンプをビデオストリームフラグメント選択信号に含めて送信する。また、ＨＬＳプロトコルに従った配信の場合には、第１のユーザ端末１１８−ｉ１が受信したインデックスファイルは、再生される複数のメディアファイルの位置に関する情報を含んでいるので、第１のユーザ端末１１８−ｉ１は、選択したビデオストリームフラグメントを指定する情報として、メディアファイルの位置に関する情報をビデオストリームフラグメント選択信号に含めて送信する。さらに、ＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）プロトコルに従った配信の場合には、第１のユーザ端末１１８−ｉ１が受信したＭＰＤファイルは、プログラムタイミングやメディアファイルの取得先についての情報を含んでいるので、プログラムタイミングやメディアファイルの取得先についての情報をビデオストリームフラグメント選択信号に含めて送信する。
【０１２５】
ビデオストリームフラグメント選択信号を受信したコンテンツプロバイダ１１４は、選択されたビデオストリームフラグメントを特定し、特定したビデオストリームフラグメントを格納する（ステップＳ２４０６）。ここで、データベースサーバ１２４のコンテンツデータベース５１０に格納されている各ビデオストリームフラグメントのヘッダ部分９０４は、符号化データの格納位置を示すアドレス情報、及び復号や表示時刻等のヘッダ情報を格納しているので、コンテンツプロバイダ１１４は、これらの情報に基づいて、選択されたビデオストリームフラグメントを特定することができる。第１のユーザ端末１１８−ｉ１は、ＳＮＳサービスプロバイダ１１６にメッセージ投稿及び選択されたビデオストリームフラグメントの投稿リクエストを送信する（ステップＳ２４０８）。ＳＮＳサービスプロバイダ１１６は、投稿されたメッセージを格納及び表示する（ステップＳ２４１０）。
【０１２６】
第２のユーザ端末１１８−ｉ２は、ＳＮＳサービスプロバイダ１１６に投稿されたメッセージ及び選択されたビデオストリームフラグメントの閲覧リクエストを送信する（ステップＳ２４１２）。ＳＮＳサービスプロバイダ１１６は、コンテンツプロバイダ１１４に投稿されたメッセージ及び選択されたビデオストリームフラグメントの閲覧リクエストがあった旨を通知する（ステップＳ２４１４）。ＳＮＳサービスプロバイダ１１６は、第２のユーザ端末１１８−ｉ２に、投稿されたメッセージの内容を送信する（ステップＳ２４１６）と共に、コンテンツプロバイダ１１４は、第２のユーザ端末１１８−ｉ２に、選択されたビデオストリームフラグメントを送信する（ステップＳ２４１８）。
【０１２７】
この実施形態では、選択されたビデオストリームフラグメントは、ＳＮＳサービスプロバイダ１１６のデータベースサーバ１３０に格納されることはない。
【０１２８】
また、本実施形態によれば、ユーザ端末１１８−ｉのみを使用することにより、ユーザ端末１１８−ｉでのリアルタイムビデオストリームの視聴中に、そのリアルタイムビデオストリームの任意の位置のビデオストリームフラグメントのＳＮＳサイトへの投稿が、簡単な方法で可能となる。このことは、データベースサーバ１２４における図１０に示すリアルタイムビデオストリームの格納方法、及び図１１乃至１３と図１７及び図１８に示すリアルタイムビデオストリームの配信方法を合わせて使用することにより、可能となることである。
【０１２９】
図２５は、ビデオストリームフラグメントのＳＮＳへの拡散の第２の実施形態を示すシーケンス図である。
【０１３０】
コンテンツプロバイダ１１４のコンテンツ配信サーバ１２２は、第１のユーザ端末１１８−ｉ１に対してリアルタイムビデオストリームを配信している（ステップＳ２５０２）。ユーザｉがリアルタイムビデオストリーム視聴中に再生時刻に対応するビデオストリームフラグメントを指定すると、第１のユーザ端末１１８−ｉ１は、コンテンツプロバイダ１１４にビデオストリームフラグメント選択信号を送信する（ステップＳ２５０４）。ここで、第１のユーザ端末１１８−ｉ１が受信したＲＴＰヘッダ部分１２０２は、ＲＴＰパケットのカウンタであるシーケンス番号、及びペイロードデータの先頭バイトのサンプリング時刻であるタイムスタンプ等を含んでいるので、第１のユーザ端末１１８−ｉ１は、指定したビデオストリームフラグメントを指定する情報として、シーケンス番号及びタイムスタンプをビデオストリームフラグメント選択信号に含めて送信する。また、ＨＬＳプロトコルに従った配信の場合には、第１のユーザ端末１１８−ｉ１が受信したインデックスファイルは、再生される複数のメディアファイルの位置に関する情報を含んでいるので、第１のユーザ端末１１８−ｉ１は、選択したビデオストリームフラグメントを指定する情報として、メディアファイルの位置に関する情報をビデオストリームフラグメント選択信号に含めて送信する。さらに、ＭＰＥＧ−ＤＡＳＨプロトコルに従った配信の場合には、第１のユーザ端末１１８−ｉ１が受信したＭＰＤファイルは、プログラムタイミングやメディアファイルの取得先についての情報を含んでいるので、プログラムタイミングやメディアファイルの取得先についての情報をビデオストリームフラグメント選択信号に含めて送信する。
【０１３１】
第１のユーザ端末１１８−ｉ１は、コンテンツプロバイダ１１４から選択したビデオストリームフラグメントをダウンロードする（ステップＳ２５０６）。この際、データベースサーバ１２４のコンテンツデータベース５１０に格納されている各ビデオストリームフラグメントのヘッダ部分９０４は、符号化データの格納位置を示すアドレス情報、及び復号や表示時刻等のヘッダ情報を格納しているので、コンテンツプロバイダ１１４は、これらの情報に基づいて、選択されたビデオストリームフラグメントを取得することができる。第１のユーザ端末１１８−ｉ１は、ダウンロードした選択されたビデオストリームフラグメントを格納する（ステップＳ２５０８）。第１のユーザ端末１１８−ｉ１は、ＳＮＳサービスプロバイダ１１６にメッセージ投稿及び選択されたビデオストリームフラグメントの投稿リクエストを送信し（ステップＳ２５１０）、選択されたビデオストリームフラグメントをＳＮＳサービスプロバイダ１１６にアップロードする（ステップＳ２５１２）。ＳＮＳサービスプロバイダ１１６は、アップロードされた選択されたビデオストリームフラグメントを、データベースサーバ１３０のビデオストリームフラグメントデータベース７１０に格納する（ステップＳ２５１４）。
【０１３２】
第２のユーザ端末１１８−ｉ２は、ＳＮＳサービスプロバイダ１１６に投稿されたメッセージ及び選択されたビデオストリームフラグメントの閲覧リクエストを送信する（ステップＳ２５１６）。ＳＮＳサービスプロバイダ１１６は、第２のユーザ端末１１８−ｉ２に、投稿されたメッセージの内容を送信する（ステップＳ２５１８）と共に、第２のユーザ端末１１８−ｉ２に、選択されたビデオストリームフラグメントを送信する（ステップＳ２５２０）。
【０１３３】
本実施形態によれば、ユーザ端末１１８−ｉのみを使用することにより、ユーザ端末１１８−ｉでのリアルタイムビデオストリームの視聴中に、そのリアルタイムビデオストリームの任意の位置のビデオストリームフラグメントのＳＮＳサイトへの投稿が、簡単な方法で可能となる。このことは、データベースサーバ１２４における図１０に示すリアルタイムビデオストリームの格納方法、及び図１１乃至１３と図１７及び図１８に示すリアルタイムビデオストリームの配信方法を合わせて使用することにより、可能となることである。
【０１３４】
図２６は、ビデオストリームフラグメントのＳＮＳへの拡散の第３の実施形態を示すシーケンス図である。
【０１３５】
コンテンツプロバイダ１１４のコンテンツ配信サーバ１２２は、第１のユーザ端末１１８−ｉ１に対してリアルタイムビデオストリームを配信している（ステップＳ２６０２）。ユーザｉがリアルタイムビデオストリーム視聴中に再生時刻に対応するビデオストリームフラグメントを指定すると、第１のユーザ端末１１８−ｉ１は、コンテンツプロバイダ１１４にビデオストリームフラグメント選択信号を送信する（ステップＳ２６０４）。ここで、第１のユーザ端末１１８−ｉ１が受信したＲＴＰヘッダ部分１２０２は、ＲＴＰパケットのカウンタであるシーケンス番号、及びペイロードデータの先頭バイトのサンプリング時刻であるタイムスタンプ等を含んでいるので、第１のユーザ端末１１８−ｉ１は、指定したビデオストリームフラグメントを指定する情報として、シーケンス番号及びタイムスタンプをビデオストリームフラグメント選択信号に含めて送信する。また、ＨＬＳプロトコルに従った配信の場合には、第１のユーザ端末１１８−ｉ１が受信したインデックスファイルは、再生される複数のメディアファイルの位置に関する情報を含んでいるので、第１のユーザ端末１１８−ｉ１は、選択したビデオストリームフラグメントを指定する情報として、メディアファイルの位置に関する情報をビデオストリームフラグメント選択信号に含めて送信する。さらに、ＭＰＥＧ−ＤＡＳＨプロトコルに従った配信の場合には、第１のユーザ端末１１８−ｉ１が受信したＭＰＤファイルは、プログラムタイミングやメディアファイルの取得先についての情報を含んでいるので、プログラムタイミングやメディアファイルの取得先についての情報をビデオストリームフラグメント選択信号に含めて送信する。
【０１３６】
ビデオストリームフラグメント選択信号を受信したコンテンツプロバイダ１１４は、選択されたビデオストリームフラグメントを特定し、特定したビデオストリームフラグメントを格納する（ステップＳ２６０６）。ここで、データベースサーバ１２４のコンテンツデータベース５１０に格納されている各ビデオストリームフラグメントのヘッダ部分９０４は、符号化データの格納位置を示すアドレス情報、及び復号や表示時刻等のヘッダ情報を格納しているので、コンテンツプロバイダ１１４は、これらの情報に基づいて、選択されたビデオストリームフラグメントを特定することができる。第１のユーザ端末１１８−ｉ１は、コンテンツプロバイダ１１４にメッセージ投稿及び選択されたビデオストリームフラグメントの投稿リクエストを送信し（ステップＳ２６０８）、コンテンツプロバイダ１１４は、ＳＮＳサービスプロバイダ１１６に、そのメッセージ投稿及び選択されたビデオストリームフラグメントの投稿リクエストを送信する（ステップＳ２６１６）。ＳＮＳサービスプロバイダ１１６は、投稿されたメッセージを格納及び表示する（ステップＳ２６１２）。
【０１３７】
第２のユーザ端末１１８−ｉ２は、コンテンツプロバイダ１１４に、投稿されたメッセージ及び選択されたビデオストリームフラグメントの閲覧リクエストを送信し（ステップＳ２６１４）、コンテンツプロバイダ１１４は、ＳＮＳサービスプロバイダ１１６に、その投稿されたメッセージ及び選択されたビデオストリームフラグメントの閲覧リクエストを送信する（ステップＳ２６１６）。コンテンツプロバイダ１１４は、ＳＮＳサービスプロバイダ１１６に、選択されたビデオストリームフラグメントを送信し（ステップＳ２６１８）、ＳＮＳサービスプロバイダ１１６は、第２のユーザ端末１１８−ｉ２に、選択されたビデオストリームフラグメントを送信する（ステップＳ２６２０）。ＳＮＳサービスプロバイダ１１６は、第２のユーザ端末１１８−ｉ２に、投稿されたメッセージの内容を送信する（ステップＳ２６２２）。
【０１３８】
本実施形態によれば、ユーザ端末１１８−ｉのみを使用することにより、ユーザ端末１１８−ｉでのリアルタイムビデオストリームの視聴中に、そのリアルタイムビデオストリームの任意の位置のビデオストリームフラグメントのＳＮＳサイトへの投稿が、簡単な方法で可能となる。このことは、データベースサーバ１２４における図１０に示すリアルタイムビデオストリームの格納方法、及び図１１乃至１３と図１７及び図１８に示すリアルタイムビデオストリームの配信方法を合わせて使用することにより、可能となることである。
【０１３９】
図２９に示されるように、第２のユーザ端末１１８−ｉ２が選択されたビデオストリームフラグメントを閲覧すると、ＳＮＳサービスプロバイダ１１６のデータベースサーバ１３０のユーザ投稿履歴データベース７１４に格納されている、“コンテンツｉｄ”ｌで識別されるコンテンツごとに、及び投稿されたメッセージごとに、そのコンテンツを投稿した“ユーザｉｄ”のシーケンス、及びそのメッセージを投稿した“ユーザｉｄ”のシーケンスが一覧表の形で表示される。
【０１４０】
本発明に従った上記の方法の各ステップは、ＣＰＵとメモリとを備えた、図示しないオペレータの端末によって行われてもよい。本発明の実施形態においては、上記の方法を実行するのに用いられるソフトウェアプログラムが、デジタル・データ・ストレージ媒体等のプログラム・ストレージ・デバイスに格納されていてもよく、これらのプログラム・ストレージ・デバイスは、機械読取り可能、又はコンピュータ読取り可能であり、また、これらのコンピュータ又は機械は、プログラム命令を機械実行可能プログラム、又はコンピュータ実行可能プログラムとしてエンコードし、エンコードされたプログラム命令は、本発明の方法のステップのうちの一部又は全部を実行する。プログラム・ストレージ・デバイスは、例えば、デジタル・メモリ、磁気ディスク及び磁気テープ等の磁気ストレージ媒体、ハード・ドライブ、又は光学的読取り可能デジタル・データ・ストレージ媒体とすることができる。
【０１４１】
本発明は、ソフトウェア、及び／又はソフトウェアとハードウェアの組合せで、例えば、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）と、汎用コンピュータ、又は他の任意のハードウェア等価物を使用して実装されてもよい。
【０１４２】
上記の説明は、単に、本発明の特定の実施形態の開示を提供しているにすぎず、本発明を上記の実施形態のみに限定するように意図されてはいない。従って、本発明は、上記で説明された実施形態だけに限定されるものではなく、むしろ、当業者が本発明の範囲内に含まれる代替の実施形態を考案し得ることが認識される。
【符号の説明】
【０１４３】
１００：  無線通信ネットワーク
１０２：  上位ネットワーク
１０４：  モバイル通信ネットワーク
１０６：  コンテンツサービスルータ
１０８：  無線ネットワークコントローラ（ＲＮＣ）
１１０：  ＮｏｄｅＢ
１１２：  ｅＮｏｄｅＢ
【図１】
0006709624.tif 000011
【図２】
0006709624.tif 000012
【図３】
0006709624.tif 000013
【図４】
0006709624.tif 000014
【図５】
0006709624.tif 000015
【図６】
0006709624.tif 000016
【図７】
0006709624.tif 000017
【図８】
0006709624.tif 000018
【図９】
0006709624.tif 000019
【図１０】
0006709624.tif 000020
【図１１】
0006709624.tif 000021
【図１２】
0006709624.tif 000022
【図１３】
0006709624.tif 000023
【図１４】
0006709624.tif 000024
【図１５】
0006709624.tif 000025
【図１６】
0006709624.tif 000026
【図１７】
0006709624.tif 000027
【図１８】
0006709624.tif 000028
【図１９】
0006709624.tif 000029
【図２０】
0006709624.tif 000030
【図２１】
0006709624.tif 000031
【図２２】
0006709624.tif 000032
【図２３】
0006709624.tif 000033
【図２４】
0006709624.tif 000034
【図２５】
0006709624.tif 000035
【図２６】
0006709624.tif 000036
【図２７】
0006709624.tif 000037
【図２８】
0006709624.tif 000038
【図２９】
0006709624.tif 000039