JP2010028693A - コンテンツ配信システム、コンテンツ受信方法および装置 - Google Patents

Abstract

【課題】伝送路で制限される伝送レートや転送レートより大きい再生レートであるノンリアルコンテンツの受信装置を提供する。
【解決手段】少なくとも１つの再生開始時刻が定められたコンテンツを受信するコンテンツ受信装置であって、コンテンツをノンリアルタイムで受けるノンリアルタイム受信手段と、少なくとも１つのコンテンツの再生開始時刻とそのコンテンツの配信方法とを含む番組情報を参照する番組情報参照手段と、前記配信方法がノンリアルタイム配信であるコンテンツの再生開始時刻と現在の時刻とに基づいて前記ノンリアルタイム受信手段によるコンテンツ受信をスケジューリングするスケジューリング手段と、前記ノンリアルタイム受信手段により受信したコンテンツを保存するコンテンツ保存手段と、を有する。
【選択図】図１

Description

本発明は映像や音声などからなるコンテンツを配信するシステムに係り、特にそのコンテンツを受信する受信方法および装置、そのための電子機器システムに関する。

Ｉ．用語の説明
まず、本発明に関連する技術の説明で用いられるいくつかの用語について簡単に触れておく。

・リアルタイム配信とは、送り側から受け側へコンテンツ（例えば、映像や音声）全体、すなわちコンテンツの最初から最後までの内容の転送完了を待つ事なく、受け側にて受信後、逐次的に再生を行う方式の配信方法をいう。コンテンツの転送時間や、コンテンツの転送の遅延の吸収のためのバッファの時間を除くと、放送や通信の時刻とコンテンツの再生の時刻がほぼ一致する。例えば、ストリーミングによるコンテンツの配信（以下、ストリーミング配信）はリアルタイム配信である。

・ノンリアルタイム配信とは、送り側からコンテンツ全体を受け側へ転送し、その後で受け側で再生する方式の配信方法をいう。コンテンツの再生開始時刻は、コンテンツの転送開始時刻から、少なくともコンテンツの転送時間分だけ後となる。例えば、ダウンロードによる配信（以下、ダウンロード配信）はノンリアルタイム配信である。

・再生レートとは、動画再生のために要する単位時間あたりの情報量（ビット数）をいう。たとえば、映像データの圧縮方式の一つであるＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐによって決められた標準規格）のように圧縮されて伝送される場合は、圧縮された状態（例えばＭＰＥＧの状態）でのビットレートが再生レートであり、符号化されたコンテンツが持つ属性である。

・伝送レートとは、伝送路を通して送信する場合にその伝送路を流れる信号のビットレートをいう。例えば、ＡＤＳＬ（非対称デジタル加入者線）で８Ｍｂｐｓ（Ｍｂｐｓ：Mega bit per second）のサービスを受けていたら、伝送レートは８Ｍｂｐｓであり、用いる伝送サービスに依存して物理的に固定されている。

・転送レートとは、コンテンツを配信するシステムのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のプログラムのポートと、コンテンツを受けるシステムのＯＳのプログラムのポートと、の間の通信レートをいう。転送レートはスループットと呼ばれる場合もある。通常、途中のネットワークにおいて、異なるホストコンピュータ間の通信のための帯域が統計的に共有されるので、転送レートは平均により得られる値である。転送レートは、ネットワークの混雑状態とサーバの処理能力とに依存する。また、パケットの転送は伝送路を通って転送されるので、その伝送路を通る転送レートの和は伝送レート以下となる。尚、異なるホストコンピュータ間の通信との間で帯域を共有せずに、占有して帯域を使用できる場合は伝送レートと転送レートとは等しくなる。

・番組とは、あるコンテンツに対し、少なくとも、それを放映する開始時刻と終了時刻とコンテンツの供給方法とが定まっていることをいう。なお、終了時刻が明示的に定まっていなくても、計算などによって終了時刻が分かればよい。例えば、コンテンツの再生時間が定まっていれば、番組開始時刻からコンテンツ再生時間を経過した時刻が番組終了時刻である、とわかる。コンテンツの供給方法の例としては、周波数と変調・復調方式とを定めたもの、コンテンツが存在する場所とそれをダウンロードする方法を定めたものなどが考えられる。コンテンツが存在する場所の例として、コンテンツのファイルが置いてあるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）もコンテンツの供給方法を定めた例といえる。なお、ＵＲＬは、アクセスするプロトコル名＋ホスト名＋パス名や、アクセスするプロトコル名＋ＩＰアドレス＋パス名などであり、コンテンツが置かれている場所、ファイル名と使用すべきプロトコルが明示的に示され、コンテンツへのリンクとなる。

・チャンネルとは、単数または複数の番組の集合をいう。その集合としては、例えば、コンテンツを配信する主体が同一である集合としてもよいし、配信主体が異なっても、同一カテゴリの番組を集めた集合であってもよい。テレビ放送の場合には、キャリアとなる電波の周波数に対してチャンネルを割り当てている。

ＩＩ．関連技術
テレビ放送と同様のコンテンツをネットワークを用いて配信する技術が研究されている。たとえば、特許文献１には、映像信号のリアルタイム配信の方法の一つとして、ＩＰ（インターネットプロトコル）パケットなどのパケットを用いてストリーミングで映像や音声を配信するストリーミング放送システムが開示されている。このシステムでは、ネットワークの通信帯域を割り当ててからストリーミング配信を行うことで、パケットの消失もしくは大幅な遅延などによる映像品質の劣化を回避し安定した配信データを図っている。

特許文献２には、電波を用いたデジタル放送を用いて映像や音声を配信する方法が開示されている。通常、デジタル放送の帯域はチャンネル毎に定められており、たとえば特許文献２に記載の地上デジタル放送では１チャンネルあたりの通信帯域は６ＭＨｚとなっている。その帯域の中で送信することが可能な情報のビットレートは、割り当てられた通信帯域、電波の伝播状態および変調の方式などにより定まる。例えば、６ＭＨｚの帯域が割り当てられた地上デジタル放送の場合、ＱＡＭ変調（直交振幅変調）およびＯＦＤＭ（直交周波数分割多重）を用い、ＣＮ比（Carrier-to-Noise Ratio、すなわちノイズ電力に対するキャリア周波数の電力の比）の状態が良ければ、最大２０Ｍｂｐｓ程度で情報を伝送する事が可能である。この例に限らず、チャンネルあたりの帯域が定まっている事により、その帯域を使用して伝送できるビットレートには限界があり、無限大の情報伝送速度（ビットレート）を得ることは不可能である。

特許文献３には、リアルタイム配信として電波による放送方法を用い、その他の配信方法としてダウンロード機能を利用する例が開示されている。たとえば、ダウンロード能力の有無はＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）に表示され、それを視聴者が見て、必要であればクリックしてダウンロードを開始する。

特許文献４には、番組の放送開始時刻を意識し、選択的にダウンロードした番組の再生の許諾可否を決める技術が開示されている。

特許文献５には、通信帯域不足によるコンテンツの品質低下を回避するためのビデオ配信システムが開示されている。具体的には、ビデオ配信サーバが翌日配信予定のリアルタイム性のないコンテンツを加入者収容装置に予備配信しておく。加入者端末からコンテンツ要求があると、ビデオ配信サーバは加入者収容装置に指示して予備配信したコンテンツを加入者端末へ送信する。

特開２００５−２１０３４７号公報 特開２００７−１０４５８８号公報 特開２００５−１９１９５０号公報 特開２００７−２７４３１８号公報 特開２００３−２９９０５５号公報

まず、特許文献１のようにストリーミング配信を受けて映像を表示し、特許文献２のようにデジタルテレビ放送を受信する場合、使用する通信や放送の帯域が予め定められているので、その定められた帯域以上の再生レートを持つコンテンツを配信する事ができない。例えば、最大８Ｍｂｐｓのビットレートで通信可能なＡＤＳＬ伝送路を使用している場合、ストリーミングで２０Ｍｂｐｓを転送することができないので、リアルタイム配信により２０Ｍｂｐｓの再生レートの映像信号を再生することができない。また、現在の地上デジタル放送の場合では、１３セグメント全てを用いても１チャンネルあたり最大２０Ｍｂｐｓ程度の放送しか行う事が出来ないので、３０Ｍｂｐｓの再生レートの映像信号の放送を送受信する事が出来ない。即ち、この場合、３０Ｍｂｐｓの再生レートの映像信号のリアルタイム配信を受ける事が出来ない。

また、特許文献３では、ダウンロード能力の有無が表示されたのを視聴者が見てクリックすることでダウンロードが開始される。したがって、見ようとする番組がダウンロードされていない場合、その時点からダウンロードを開始する事になり、すぐに再生する事ができない、あるいはコンテンツの再生品質が劣化することになる。以下、具体的に説明する。

例えば１週間後というように時間的に余裕があるがファイルサイズの大きい番組コンテンツＡ（転送レートはａとする）をクリックした後に、放送開始時刻がそのクリック時点であり、再生レートが伝送レートｚと等しい番組コンテンツＢを視聴したくなった場合を考える。既に、先に開始したコンテンツＡのダウンロードにより伝送帯域が使用されているので、新たなダウンロードのために使用できる転送レートは、伝送レートｚから番組コンテンツＡの転送レートａだけ小さい値（ｚ−ａ）となる。新たに使用できる転送レート（ｚ−ａ）は、後から視聴したくなった番組コンテンツＢの再生レートｚ（＝伝送レート）以下となる。したがって、番組コンテンツＢの再生に必要な単位時間あたりの情報量を転送する事が出来ない。このような状態で、ファイルをダウンロードしながら再生したとしても、所定の再生レートで再生する事ができず映像品質が劣化する（コマ落ち、解像度劣化など）。また、ダウンロードが完了してから視聴したとしても、番組開始時刻からダウンロード時間分経過した後にはじめて再生出来る事になり、コンテンツ提供業者が予め設定した番組の開始時刻通りにコンテンツを再生する事が出来ない。したがって、たとえばチャンネルを切り替えた際、ダウンロードの状況によっては、番組スケジュール通りにコンテンツを再生することができない。

再生レートが伝送レートを上回るような番組コンテンツＣの場合も同様に、番組開始時刻にクリックしてからダウンロードを開始する事になるので、番組開始時刻にコンテンツを再生する事が出来ない、もしくはダウンロード時間分だけ待ってから映像を再生する事になる。

特許文献４においては、「放送装置」という用語は、ダウンロード用のコンテンツ配信サーバの事を指しており、リアルタイム配信を含めた技術の記載がなく、生放送を配信・放送する事ができない。又、特許文献４に開示されている技術は、コンテンツを選択的にダウンロードする技術である。選択的にダウンロードする際は、コンテンツ再生装置がダウンロード要求を行って、初めて放送装置がコンテンツのアップロードを行う。従い、伝送レートより大きい再生レートを持つコンテンツの配信を、番組開始時刻までに完了していない場合において、その番組開始時刻後にその番組を見るように視聴者がチャンネルを切り替えると、特許文献３での課題と同様に、劣化した映像を再生する事になるか、もしくは、ダウンロード時間分だけ待ってから映像を再生する事になる。

このように、上述した技術では、伝送レートより大きい再生レートを持つ番組コンテンツを番組開始時刻に再生できない。その他に、番組コンテンツの転送に使用する事ができる転送レートより大きい再生レートを持つ番組コンテンツに対しても同様の問題が生じうる。転送レートは必ず伝送レート以下であるので、転送レートは再生レート以下となり、再生に必要な情報量を送信する事が出来ないからである。

以上述べた特許文献１〜４に開示されている技術では、伝送レートや転送レートより大きい再生レートを持つ番組コンテンツを番組開始時刻に再生することができない。

特許文献５に開示されたビデオ配信システムでは、ビデオ配信サーバが翌日配信予定のコンテンツを加入者収容装置に予備配信し、加入者端末からの要求を受けたビデオ配信サーバが加入者収容装置に指示して予備配信したコンテンツを加入者端末へ送信する。すなわち、「予備配信を行う時刻」になったら、サーバ側が翌日分のコンテンツで配信を行うものがあるか否かをチェックし、予備配信すべきコンテンツがあれば、それを加入者収容装置へ送信するものであり、ダウンロードするか否かはビデオ配信サーバが判断する。

言い換えれば、特許文献５のシステムでは、コンテンツ配信サーバ側がコンテンツの予備配信を制御する。したがって、複数のコンテンツ配信サーバが個別に存在し、それらからのコンテンツ配信時刻が重なると、加入者の持つ伝送レートを超える容量のコンテンツを受信することとなり、加入者収容装置で受信できなくなることがある。さらに、常に翌日分のみが事前にダウンロードされるので、たとえば翌日のためにダウンロードするコンテンツの情報量が大きい場合には、ダウンロード量が大き過ぎて、番組開始時刻までにダウンロードを完了することができないという支障が生じうる。

本発明の目的は、伝送路で制限される伝送レートや転送レートより大きい再生レートであるコンテンツの受信および再生開始時刻での再生を可能にし、かつ、チャンネルを切り替えて他のコンテンツを受信する場合であっても、当該他のコンテンツを、本来の再生レートで、番組のスケジュール通りに再生することを可能とするコンテンツ受信装置および受信方法ならびにコンテンツ配信システムを提供することにある。

本発明によるコンテンツ受信装置は、少なくとも１つの再生開始時刻が定められたコンテンツを受信するコンテンツ受信装置であって、コンテンツをノンリアルタイムで受けるノンリアルタイム受信手段と、少なくとも１つのコンテンツの再生開始時刻とそのコンテンツの配信方法とを含む番組情報を参照する番組情報参照手段と、前記配信方法がノンリアルタイム配信であるコンテンツの再生開始時刻と現在の時刻とに基づいて、前記ノンリアルタイム受信手段によるコンテンツ受信をスケジューリングするスケジューリング手段と、前記ノンリアルタイム受信手段により受信したコンテンツを保存するコンテンツ保存手段と、を有することを特徴とする。

本発明によれば、伝送路で制限される伝送レートや転送レートより大きい再生レートであるコンテンツの受信および再生開始時刻での再生が可能となり、かつ、チャンネルを切り替えて他のコンテンツを受信する場合であっても、当該他のコンテンツを、本来の再生レートで、番組のスケジュール通りに再生することが可能となる。

１．一実施形態
通常、テレビ放送においては、コンテンツの作成のタイミングと放送のタイミングとが同時か否かの観点で、生放送と、録画放送とに分ける事ができる。一方、ネットワークの配信の方法の観点では、撮影しているカメラの映像や音声をそのまま放送するリアルタイム配信と、予め録画してあるコンテンツの配信などのように視聴者への放送にリアルタイム性が要求されないノンリアルタイム配信とに分ける事ができる。従って、例えば放送局において、予め録画してあるコンテンツをノンリアルタイム配信に割り当て、生放送をリアルタイム配信に割り当てる事ができる。なお、リアルタイム配信は、ストリーミングや電波を用いたテレビ放送のような方法を用いる事ができる。ノンリアルタイム配信はファイルのダウンロードという方法を用いる事ができる。

ノンリアルタイム配信は、リアルタイム配信とは異なり、ある決められた時刻に合わせて配信する必要がない。そこで、次の方法を用いる事ができる。まず、ノンリアルタイムの番組コンテンツを、その番組開始日時前に、コンテンツ受信装置で受信して保存しておく。そして、番組開始日時になった時点で、保存しておいたコンテンツの再生を行う。視聴者がリアルタイム配信される番組を視聴する際は、番組開始時にリアルタイム配信の再生を開始させる。このような構成と方法を用いる事により、ネットワークを用いてリアルタイム配信されるコンテンツやノンリアルタイム配信のコンテンツを、視聴者は配信方法を意識する事なく、通常のテレビ放送と同様な感覚で視聴する事が出来る。

１．１）構成
図１は本発明の一実施形態によるコンテンツ受信装置を用いたコンテンツ配信システムの一例を示すブロック図である。ここでは、コンテンツ提供システム１０、番組情報登録・提供システム２０およびコンテンツ受信装置４０がネットワーク３０に接続されているものとする。ネットワーク３０は有線／無線および公衆網／私設網を問わない。コンテンツ受信装置４０は、後述するように、ノンリアルタイムコンテンツをその番組開始前にコンテンツ提供システム１０からネットワーク３０を通して受信するスケジューリングを行う。

コンテンツを配信するコンテンツ提供システム１０は、リアルタイム配信提供システム１１とノンリアルタイム配信提供システム１２とを備える。コンテンツを配信する者は、番組情報登録・提供システム２０に、番組識別子、番組開始時刻、番組コンテンツの配信方法などを含む番組情報を登録する。

登録する番組情報として番組コンテンツの配信方法を指定する事により、番組コンテンツと、コンテンツ提供システム１０のリアルタイム配信システム１１またはノンリアルタイム配信システム１２とが関連付けられる。番組コンテンツがリアルタイム配信される場合は、視聴者は、番組情報登録・提供システム２０において番組コンテンツと関連付けられたリアルタイム配信システム１１から番組コンテンツの配信を受ければよい。番組コンテンツがノンリアルタイム配信される場合は、視聴者は、番組情報登録・提供システム２０において番組コンテンツと関連付けられたノンリアルタイム配信システム１２から番組コンテンツの配信を受ければよい。

コンテンツ受信装置４０は、ネットワーク３０に接続してデータや制御信号の送受信を行う送受信部４１を有し、リアルタイム配信提供システム１１からリアルタイム配信されるデータはリアルタイムデータ受信部４２で受信され、コンテンツ出力部４３から再生装置（図示せず。）へ出力される。ノンリアルタイム配信システム１２からノンリアルタイム配信されるデータは、ノンリアルタイムデータ受信部４４で受信され、コンテンツ保存部４５に保存され、番組開始時刻になるとコンテンツ出力部４３を通して再生装置へ出力される。

コンテンツ受信装置４０は図１に示す機能的な構成を有し、その全体的な動作は制御部４６により制御されるが、ここでは番組情報参照部４７、ノンリアルタイムコンテンツ受信スケジューラ４８および日付時刻参照部４９を用いて実行されるコンテンツ受信動作について説明する。なお、制御部４６、番組情報参照部４７、ノンリアルタイムコンテンツ受信スケジューラ４８および日付時刻参照部４９は、プログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することで同様の機能をソフトウェアにより実現することもできる。

１．２）動作
制御部４６は、番組情報参照部４７により番組情報登録・提供システム２０から受け取った番組情報と、日付時刻参照部４９からの日付時刻情報とを参照し、配信方法としてノンリアルタイム配信を用いる番組コンテンツのうち、番組開始時刻以前であって未だ配信されていないものが存在するか否かをチェックする。ノンリアルタイム配信を受けるべき番組コンテンツが存在する場合には、制御部４６の制御下で、ノンリアルタイムコンテンツ受信スケジューラ４８は、未配信コンテンツの番組開始時刻と現在時刻情報とに基づき、それぞれの番組開始時刻までにノンリアルタイム配信が完了するようにスケジューリングを行う。制御部４６は、送受信部４１、ノンリアルタイムデータ受信部４４およびコンテンツ保存部４５を制御し、未配信コンテンツの受信スケジュールに従って、ノンリアルタイム配信システム１２から各コンテンツを受信し、コンテンツ保存部４５に保存する。そして、番組開始時刻になった時に、コンテンツ保存部４５から当該コンテンツをコンテンツ出力部４３へ順次出力しコンテンツの再生を行う。

一方、配信方法としてリアルタイムにコンテンツ配信を行う番組に対しては、制御部４６の制御の下で、送受信部４１およびリアルタイムデータ受信部４２により、当該リアルタイムコンテンツの番組開始時刻に合わせて、リアルタイム配信提供システム１１から当該コンテンツを受信し、コンテンツ出力部４３へ順次出力しコンテンツの再生を行う。

このように、コンテンツ受信装置４０の制御部４６、番組開始時刻を含む番組情報を参照する事により、番組のコンテンツの配信が、リアルタイム配信かノンリアルタイム配信であるかを把握する事ができる。リアルタイム配信の番組は、番組開始時刻に番組のコンテンツが再生されるようにリアルタイムデータ受信部４２により受信される。ノンリアルタイム配信の番組は、番組開始よりも前に受信が完了するようにスケジュールされ、コンテンツ保存部４５に保存され、番組開始時刻にコンテンツ保存部４５から再生される。

既に述べたように、転送レートより大きい再生レートのコンテンツは、再生に必要な情報量を再生に間に合うように転送する事が出来ないので、品質の劣化なくリアルタイムで配信・再生する事はできない。このような番組コンテンツでリアルタイム性が要求されないものに対しては、まず、コンテンツ配信者が配信方法としてノンリアルタイム配信を選択し、番組情報登録・提供システム２０に登録する。コンテンツ受信装置４０は、番組情報登録・提供システム２０を参照し、その番組コンテンツの受信が番組開始時刻以前に完了するようにノンリアルタイム受信のスケジューリングを行い、番組開始時刻前に当該番組コンテンツのコンテンツ保存を完了させる。当該番組コンテンツは、その番組開始時刻前に、当該番組の所要時間以上の時間をかけて受信することができるので、（転送レート×番組所要時間）以上の情報量（再生レート×番組所要時間）の配信を予め受ける事ができる。

一例として、元々の映像信号が４０Ｍｂｐｓで１時間の番組だと仮定する。伝送システムや放送システムの転送レートが２０Ｍｂｐｓであるとすると、４０Ｍｂｐｓの信号をリアルタイム配信（例えば、ストリーミングやデジタル放送）でそのまま転送する事が出来ない。しかし、ノンリアルタイム配信を採用する事により、４０Ｍｂｐｓの信号１時間分の情報を受信システムに転送する事ができる。この例の場合、その１時間番組を２時間かけてノンリアルタイム配信を受ければよい。

１．３）効果
上述したように、リアルタイム配信の他に、ノンリアルタイム配信を採用することにより、次のような効果を得ることができる。

ノンリアルタイム配信では、転送レートと再生レートとは独立になるので、転送レートより大きい再生レートである精細度の高いコンテンツの配信を受ける事ができる。その際、番組開始時刻と現在時刻とを参照し、どのノンリアルタイム配信の番組コンテンツを優先してノンリアルタイム配信を受けるか、あるいは、いつ、どの番組コンテンツのノンリアルタイム配信を受けるか、のスケジューリングを行う事により、番組開始時刻前にノンリアルタイム配信の受信を完了しておく事が可能となる。すなわち、予め時間をかけて配信を受けることができるので、品質劣化なくコンテンツの持つ本来の情報量そのままの精細度で再生・表示することが可能となる。

このように、リアルタイム配信と、伝送路で制限される伝送レートや転送レートより大きい再生レートであるコンテンツの配信とが混在した番組構成であっても、それぞれの番組開始時刻に品質劣化を招来することなく番組コンテンツの再生を行う事ができる。したがって、その時刻に使用される予定の他の番組コンテンツへ切り替えても、その他の番組コンテンツ固有の再生レートで再生が可能となる。

また、コンテンツファイルの転送のための帯域を予め割り当てないネットワークに本実施形態を適用した場合、次のような効果を得ることができる。

既にノンリアルタイム配信された番組コンテンツの番組開始時刻以降に、他のリアルタイム配信の番組コンテンツを受信する必要が生じても、ノンリアルタイムコンテンツは既にダウンロードされているので、リアルタイムコンテンツの配信トラヒックのみで済む。例えば、ある時刻においてチャンネル１およびチャンネル２でそれぞれコンテンツＣおよびＤを配信する場合、既に述べた関連技術によれば、これらのストリーミング配信（リアルタイム配信）が同時に発生することになる。

これに対して、本実施形態によれば、一方のチャンネル（チャンネル１とする。）のコンテンツＣをダウンロード配信（ノンリアルタイム配信）としてスケジューリングを行い、予めダウンロードして保存しておく。したがって、他方のチャンネル（チャンネル２）のコンテンツＤの配信が生じても、コンテンツＣはすでにダウンロード済みなので、ストリーミング配信はコンテンツＤのみとなる。従って、ネットワーク全体で見ると、コンテンツＤのリアルタイム配信時における、ネットワーク帯域資源の使用量が少なくて済み、ネットワークを他のアプリケーションに使用させる事が可能となる。

また、ストリーミング配信を受けているユーザも、使用ネットワークの帯域が空いているので、輻輳なくストリーミング配信を安定に受信する事ができる。またノンリアルタイム配信の番組コンテンツは、ネットワークのトラヒックが輻輳している時間帯を避けて、トラヒックが空いている時に配信を受ければ、ネットワーク全体を有効に利用する事ができる。

以上のような構成と方法を用いる事により、再生時刻が定められた、もしくは制限された番組コンテンツの配信において、生放送の番組コンテンツを受信する事も可能となる。また、伝送メディアで制限される伝送レートや転送レートより大きい情報量を持つ番組コンテンツを番組開始時刻に再生する事が可能となる。

さらに、ネットワークを用いてリアルタイム配信されるコンテンツや、ノンリアルタイム配信のコンテンツを、視聴者は配信方法を意識する事なく、通常のテレビ放送と同様な感覚で視聴する事が出来る。

２．第１実施例
２．１）構成
図２は本発明の第１実施例によるコンテンツ配信システムにおける電子機器システムの概略的構成を示すブロック図である。ここでは、電子機器システム１３０がコンテンツ提供システム１００および番組情報登録・提供システム１２０にデータ転送手段１１０を介して接続可能であるとする。番組情報登録・提供システム１２０は、番組コンテンツ毎に、コンテンツ提供者から番組識別子、番組開始日時および番組配信方法の登録を受け付け保持する。番組識別子は、番組コンテンツを一意に特定できるように文字や数字などの記号を組み合わせて割り振ったものである。チャンネルと番組開始日時とを指定すれば、一意に配信するコンテンツが定まるのであれば、チャンネルと番組開始時刻との組み合わせからなる文字列も番組識別子として扱うことができる。番組の配信方法は、ダウンロード配信（ノンリアルタイム配信）なのか、ストリーミング配信や放送信号による配信（リアルタイム配信）なのかを示す情報である。ダウンロード配信やストリーミング配信の場合は、配信方法を指定する情報として、それぞれ番組コンテンツのＵＲＬの情報も含むことができる。放送の場合には、放送メディアの種類は、地上波デジタル放送、ＢＳ（放送衛星）デジタル放送、ＣＡＴＶ（コミュニティ・アンテナ・テレビジョン）などの放送のメディアの種類と搬送版の周波数の情報とを含んでいる。同一の放送メディアの中で複数の変復調方式が存在する場合は、変復調方式の情報も含むようにすればよい。以下、詳細に説明する。

コンテンツ提供システム１００は、ノンリアルタイム配信提供システム１０１とリアルタイム配信提供システム１０２とからなり、図１のコンテンツ提供システム１０に対応する。以下、ノンリアルタイム配信方法としてファイルのダウンロード配信を、リアルタイム配信としてストリーミング配信を用いるものとする。したがって、ノンリアルタイム配信提供システム１０１はダウンロードサーバとなり、リアルタイム配信提供システム１０２はストリーミングサーバとなる。番組情報登録・提供システム１２０に登録された番組コンテンツの配信方法の情報により、番組今連津とこれらのサーバ１０１あるいは１０２が関連付けられる。

データ転送手段１１０は図１のネットワーク３０に対応し、ＩＰネットワークでもよいし、放送信号を用いてコンテンツを転送する地上波、衛星放送、ＣＡＴＶなどの放送ネットワークでもよい。ＩＰネットワークの場合、ネットワークで使用する帯域を予め確保できるネットワークでもよいし、帯域を予め確保できないネットワークでもよい。

番組情報登録・提供システム１２０は図１の番組情報登録・提供システム２０に対応し、上述したような番組情報の入力をコンテンツ提供者から受け付け、それを保持し、また外部に配信する機能を有する。

電子機器システム１３０は図１のコンテンツ受信装置４０に対応し、番組情報登録・提供システム１２０から受信した番組情報に基づいてノンリアルタイム受信スケジューリングやコンテンツ提供システム１００から受信したコンテンツの再生を行う。

データ転送インタフェース１３１は図１の送受信部４１に対応し、電子機器システム１３０と外部の通信ネットワークや放送ネットワークなどのデータ転送手段１１０とのインタフェースである。データ転送手段１１０がＩＰネットワークである場合、データ転送インタフェース１３１は、イーサネット（登録商標。以下同様）のフレーム終端機能、ＩＰパケット終端機能などの通信に関係するレイヤでの終端機能を有し、そのレイヤで用いるプロトコルに従い通信処理を行う。それにより、各アプリケーションが、イーサネットやＴＣＰ／ＩＰプロトコル、ＵＤＰ／ＩＰプロトコルを用いてＩＰネットワークを介して情報転送する事を可能とする。物理レイヤとしては、外部環境に応じたインタフェースを持つ。例えば、データ転送手段１１０へＡＤＳＬで接続されているとすると、ＡＤＳＬ信号を終端する機能を持ち、光ファイバによりデータ転送手段１１０へ接続されている場合は、光信号を終端する機能を持つ。イーサネットのケーブルで接続されている場合は、イーサネットの物理レイヤを用いる。

番組情報参照部１３３は図１の番組情報参照部４７に対応し、番組情報登録・提供システム１２０を参照して、番組の識別子、番組開始時刻、番組の配信方法を含む番組情報を入手し必要な情報を保存する。

リアルタイム配信受信部１３４は図１のリアルタイムデータ受信部４２に対応し、データ転送インタフェース１３１を介してリアルタイム配信提供システム１０２からのストリーミングパケットを受信する。

ノンリアルタイム配信受信部１３５は、図１のノンリアルタイムデータ受信部４４に対応し、データ転送インタフェース１３１を介して、ノンリアルタイム配信提供システム１０１のダウンロードサーバにアクセスし、番組のコンテンツをダウンロードの処理を行う。

日付時刻参照部１３６は図１の日付時刻参照部４９に対応し、日付時刻情報を後述する制御部１３８およびノンリアルタイム配信受信スケジューラ１４１へ出力する。

コンテンツ保存部１３７は図１のコンテンツ保存部４５に対応し、ノンリアルタイム配信受信部１３５によりダウンロードしたコンテンツのファイルを保存する。コンテンツ保存部１３７としては、ハードディスク、ＤＶＤディスク、半導体メモリ、磁気テープなど、データを保存できる記録媒体を用いることができる。

コンテンツ出力部１３９は図１のコンテンツ出力部４３に対応し、コンテンツ保存部１３７に保存されたダウンロード済みのファイルや、リアルタイム配信受信部１３４からのリアルタイム配信データを入力し、映像や音声の再生が可能な形式の信号に変換して再生装置（図示せず。）へ出力する。映像の再生であれば、コンテンツ出力部１３９の出力端に対し、液晶ディスプレイ、プラズマディスプレイ、ＣＲＴ（ブラウン管）ディスプレイ、有機ＥＬディスプレイなど、映像信号を再生・表示できるディスプレイを接続してもよい。ただし、コンテンツとしては、映像信号だけに限るものではなく、音声や他の形態であってもよい。

視聴者インタフェース１４０は、視聴者がその時点で見たいチャンネルを選択したり、将来のある時点で見たい番組を入力したりするための操作部や必要な情報を表示する表示部などである。

ノンリアルタイム配信受信スケジューラ１４１は図１のノンリアルタイムコンテンツ受信スケジューラ４８に対応し、番組情報および現在の日付時刻情報を参照してダウンロードを行う順番およびダウンロードを行う日時を決定するスケジューリングを行う。

制御部１３８は、上記の各機能ブロック間での情報のやりとりの制御や、次に述べる全体的な制御フローを管理する。制御部１３８は、プログラムを実行することで制御フローを実行するＣＰＵ等のプログラム制御プロセッサである。

制御部１３８やノンリアルタイム配信受信スケジューラ１４１は、番組情報参照部１３３から各番組コンテンツの番組情報を得ることができ、日付時刻参照部１３６から現在の日付時刻情報を得ることができる。次に上記のような構成を用いたシステムの動作の説明を行う。

２．２）番組情報取得動作
まず、番組のコンテンツ提供者は、番組の識別子、番組の開始時刻、番組の配信方法を含む番組情報を番組情報登録・提供システム１２０に登録する。そして、番組の配信方法で指定したＵＲＬ（リアルタイム配信システム１０２またはノンリアルタイム配信システム１０１）に番組のコンテンツをアップロードする。電気機器システム１３０は、次に述べるように、データ転送インタフェース１３１を介して、番組情報登録・提供システム１２０へアクセスし番組情報を取得・保持する。

図３は本発明の第１実施例による電子機器システムの番組情報取得手順を示すフローチャートである。電子機器システム１３０は、自身が保有している情報よりも新規な番組情報が番組情報登録・提供システム１２０にあるか否かを問合せる（ステップ２０１）。この問い合わせは定期的に行われる。新規番組情報がなければ（ステップ２０２：Ｎｏ）ステップ２０１へ戻り、定期的に問い合わせを行う。新規番組情報がある場合は（ステップ２０２：ｙｅｓ）、番組情報登録・提供システム１２０から新規番組情報をデータ転送インタフェース１３１を介してダウンロードし、番組情報参照部１３３に保存し（ステップ２０３）、ステップ２０１へ戻る。

このように番組情報参照部１３３に番組情報を蓄積することで、番組情報の参照を高速で行うことができる。ただし、番組情報を把握したいときに、番組情報参照部１３３が番組情報提供システム１２０にその都度アクセスし番組情報を参照することも可能である。

２．３）スケジューリング（第１例）
ダウンロード配信される番組コンテンツ（以下、ダウンロード番組コンテンツと呼ぶ。）の中で未だダウンロードしていないものが存在する場合、ノンリアルタイム配信受信スケジューラ１４１は番組開始時刻と現在時刻とを参照して当該番組コンテンツのダウンロードのスケジューリングを行う。以下詳述する。

図４は本発明の第１実施例による電子機器システムのノンリアルタイム配信受信スケジューラにより実行されるスケジューリング動作の第１例を示すフローチャートである。

まず、制御部１３８は、ダウンロード番組コンテンツの中で未だダウンロードしてないものが存在するか否かを判定する（ステップ３０１）。例えば、過去にダウンロードした履歴を保存しておき、番組情報参照部１３３からの番組情報と比較する事により判定することができる。

未だダウンロードしていないダウンロード番組コンテンツが存在する場合、制御部１３８はノンリアルタイム配信受信スケジューラ１４１を制御してダウンロードのスケジューリングを実行する（ステップ３０３）。具体的には、日付時刻参照部１３６からの現在時刻を参照し、番組情報参照部１３３からダウンロードされていない番組コンテンツの番組開始時刻を参照する事により、各ダウンロード番組コンテンツのダウンロード開始時刻および／またはダウンロードの順番が決定される。たとえばダウンロードする順番のみを決める場合では、現在時刻と番組開始時刻とを比較し、番組開始時刻が現在時刻に近い順番にダウンロードを開始するというスケジューリングを行えばよい。

ノンリアルタイム配信受信スケジューラ１４１は、ステップ３０３で作成したダウンロードスケジュールを基にダウンロードすべき番組が存在するか否かを判断する（ステップ３０４）。ダウンロードすべきコンテンツが存在すれば、ノンリアルタイム配信提供システム１０１（ダウンロードサーバ）にコンテンツのダウンロードを要求し、ダウンロードを実行する（ステップ３０５）。ダウンロードしたファイルは、不要になるまで、コンテンツ保存部１３７に格納する。不要な場合としては、例えば、番組コンテンツの再生が完了した後で視聴者がその保存を希望しない場合もしくはコンテンツ提供者が保存を禁止する場合などがある。

続いて、再スケジューリング要因が発生したか否か調べ（ステップ３０６）、発生していなければ（ステップ３０６：Ｎｏ）、ステップ３０４に戻りスケジュールで定めた通りに次のダウンロードに移る。再スケジューリング要因が発生していれば（ステップ３０６：Ｙｅｓ）、再スケジューリングを行うためにステップ３０１に戻る。再スケジューリング要因としては、新たな番組情報が得られダウンロードすべき番組が増加した場合や、ネットワーク障害などにより転送レートが低下した場合、スケジューリングしたダウンロード番組の全てをダウンロード完了した場合などが考えられる。これらのフローの制御および管理は制御部１３８により実行される。

なお、図４のステップ３０３において、ダウンロード時刻を決定するスケジューリングを行う場合は、現在時刻とスケジューリングにより決定されたダウンロード開始時刻とを比較し、現在時刻がダウンロード開始時刻の近傍であれば、ダウンロード開始時刻にダウンロードが開始できるようにダウンロードの準備を行う。そうすると、ダウンロード開始時刻に遅れる事なく、ダウンロードを開始する事ができる（ステップ３０５）。

２．４）コンテンツ出力制御
次に、電子機器システム１３０において、ノンリアルタイム配信とリアルタイム配信とが混在している中で、番組コンテンツの再生信号を番組情報に従って適切に出力する制御手順について説明する。

図５は本発明の第１実施例による電子機器システムのコンテンツ出力制御手順を示すフローチャートである。まず、制御部１３８は、番組情報参照部１３３にて番組情報を参照し、新規に番組コンテンツを再生すべき状態かチェックする（ステップ４０１）。

新規に番組コンテンツを再生すべき状態である場合（ステップ４０１：Ｙｅｓ）、番組情報を参照することで、当該番組コンテンツの配信方法がダウンロード配信あるいはストリーミング配信のいずれであるかを判定する（ステップ４０２）。

ストリーミング配信の場合は、制御部１３８の制御下で、リアルタイム配信受信部１３４はリアルタイム配信提供システム１０２へストリーミング配信の要求を送信し、データ転送インタフェース１３１を通してストリーミング信号を受信する。リアルタイム配信受信部１３４は、受信したストリーミング信号を信号処理した後、コンテンツ出力部１３９へ出力し、コンテンツ出力部１３９は、コンテンツの再生信号に変換して外部の再生装置へ出力する（ステップ４０３）。

一方、ステップ４０２において再生すべきコンテンツがファイルダウンロード配信である場合、制御部１３８はダウンロード済みのファイルを格納したコンテンツ保存部１３７から再生すべき番組ファイルを検索し（ステップ４０４）、再生すべきファイルをコンテンツ出力部１３９を通してコンテンツ再生信号として出力する（ステップ４０５）。その際、番組開始時刻と現在時刻を参照する事により、番組開始時刻から現在時刻までの経過時間を算出する事ができる。経過時間がわかれば、再生しておくべきコンテンツの部分を算出する事ができるので、その時刻にて再生されているべき部分から再生を行うことができる。

なお、図５のステップ４０５にて、番組開始時刻からの経過時間を考慮し、その時点にて再生されるべきコンテンツの部分を算出し、そこから再生する方法を用いたが、番組のコンテンツの最初から再生する方法を用いてもよい。

２．５）コンテンツ再生判定の第１例
次に、上述した新規に番組を再生すべき状態かどうかの判断（図５のステップ４０１）を行うための方法について説明する。

図６は本発明の第１実施例による電子機器システムのコンテンツ再生判定手順の第１例を示すフローチャートである。

視聴者が視聴者インタフェース１４０を通して現在視聴しているチャンネルから他のチャンネルへ切り替えた場合（ステップ５０１：Ｙｅｓ）、それによって新規に番組コンテンツを再生すべき状態となったと判断される（ステップ５０５）。続いて、当該番組コンテンツの再生が開始されたか否かを判断し（ステップ５０６）、再生が開始されるまでは、新規に番組を再生すべき状態から抜けない（ステップ５０６：Ｎｏ）。その番組コンテンツの再生を開始したら（ステップ５０６：Ｙｅｓ）、新規に再生する番組がない状態へ移行する（ステップ５０４）。

視聴者がチャンネル切り替えを行わなかった場合（ステップ５０１：Ｎｏ）、制御部１３８は現在再生中である番組コンテンツが終了しそうかどうかをチェックする（ステップ５０２）。現在、再生中の番組コンテンツが終了しそうであれば（ステップ５０２：Ｙｅｓ）、再生する番組コンテンツの準備をする必要があるので新規に番組を再生すべき状態となる（ステップ５０５）。現在、再生中の番組が終了しそうでなければ（ステップ５０２：Ｎｏ）、新規に番組を再生しない状態となる（ステップ５０４）。

以上の図６の説明において、新規に再生すべき状態となったら、図５のフローのステップ４０１のＹｅｓのフローに戻り、上述したように、ダウンロード配信かストリーミング配信かの場合分けの判断（ステップ４０２）に続いて番組の再生を行う（ステップ４０３あるいはステップ４０４〜４０５）。

２．６）効果
以上のような構成と方法を用いる事により、番組開始時刻が定められた番組コンテンツを視聴するシステムにおいて、ネットワークを用いてリアルタイム配信されるコンテンツやノンリアルタイム配信のコンテンツを、視聴者は配信方法を意識する事なく、通常のテレビ放送と同様な感覚で視聴することができる。

また、ダウンロード配信のようなノンリアルタイム配信を採用する事により、次のような効果がある。ノンリアルタイム配信を受けた場合は、ファイルの転送レートと再生レートとは独立になるので、転送レートより大きい再生レートであるコンテンツの転送を行うことが可能となる。リアルタイム配信の場合は、転送レート以下の配信しか行うことができないが、本システムを用いる事により、リアルタイム配信以上の精細度の高いコンテンツの放送や転送を行う事ができる。そして、その際、番組開始時刻と現在時刻とを参照し、ノンリアルタイム配信のスケジューリングを行う事により、番組開始時刻前にノンリアルタイム配信の受信を完了しておく事が可能となる。それにより、転送レートより大きい再生レートを持つコンテンツの再生を行う事ができる。

さらに、管理者が異なる複数のネットワークを経由することで端末間での帯域制御を行う事が出来ないインターネットのような、帯域を予め割り当てないネットワークの場合には、ダウンロード番組コンテンツのダウンロードをその番組開始時刻前に完了させることができるので、当該コンテンツの再生時に、他のストリーミング番組の配信を受ける必要があっても、ストリーミング番組コンテンツのトラヒックのみで済む。したがって、ネットワーク全体で見ると、リアルタイム配信時におけるネットワーク帯域資源の使用量が少なくて済み、その分を他のアプリケーションに使用させる事が可能である。また、ネットワークの帯域が空いているので、輻輳がなくストリーミング配信を安定に受信する事ができる。

他の効果として、ノンリアルタイム配信は番組の始まる前にコンテンツの配信を受けているので、チャンネル切り替え時に、リアルタイム配信のような通信のセットアップや、再生開始に先立って必要なバッファ分のコンテンツの取り込みを行わなくて済む。したがって、チャンネルを切り替えた時に、コンテンツが再生されるまで、その分、ユーザが視聴開始までに待つ時間が少なくて済む、という効果がある。

なお、コンテンツ提供システム１００側にノンリアルタイム配信のスケジューリング手段を設けると、他のコンテンツ提供システムの事を考慮せずにスケジューリングを行う事になってしまい、番組開始時刻までにノンリアルタイム配信を完了できるスケジューリングを行う事が出来ない場合があり得る。

それに対し、本発明によれば、コンテンツ提供システム１００側でなく、コンテンツの受信側である電子機器システム１３０にノンリアルタイム配信の受信スケジューラ１４１が設けられる。そして、番組情報参照部１３３が、番組情報登録提供システム１２０にアクセスする事により、他のチャンネルの番組情報を得ることができる。それにより、電子機器システム１３０がノンリアルタイム配信を受ける他のチャンネルの番組を考慮した上でノンリアルタイム配信の受信のスケジューリングを行うことが出来る。したがって、他チャンネルのコンテンツのダウンロード時刻と重なってしまうことにより、ダウンロードのための通信帯域が十分確保できず、番組のコンテンツのダウンロードが番組開始時刻に間に合わなくなると言う事態を回避することが可能となる。

３．スケジューリング（第２例）
ノンリアルタイム配信受信スケジューラ１４１は、上述した図４のステップ３０３に示すように、番組開始時刻と現在時刻とを参照してダウンロードのスケジューリングを行うが、他のスケジューリング方法として、ネットワークでの使用可能帯域やダウンロード配信サーバの状況、ダウンロードすべきファイルのファイルサイズから、ダウンロード所要時間を推測し、それをスケジューリングに活かすこともできる。その場合、番組情報登録・提供システム１２０は、番組の提供者が登録する番組情報に番組コンテンツのファイルサイズの情報も加える。

したがって、未だダウンロードされていない番組コンテンツの番組開始時刻およびファイルサイズは、番組情報参照部１３３が番組情報登録・提供システム１２０へアクセスする事により、それらの情報を参照できる。その際、取得した番組情報を番組情報参照部１３３に保持すれば再アクセスする必要がない。現在時刻は、日付時刻参照部１３６を参照する事によりわかる。

なお、ファイルサイズでなくても、ファイルサイズを算出できる情報を登録してもよい。例えば、再生レートと番組時間を登録すれば、それらの積によりファイルサイズを算出する事ができる。例えば、１時間番組で４０Ｍｂｐｓの再生レートで映像信号を再生する場合、４０Ｍｂｐｓ×３６００秒＝１４４Ｇｂｉｔ(Giga bit)のファイルサイズとなる。

このようにファイルサイズと転送レートがわかると、ダウンロード所要時間を推定することができる。具体的には、ダウンロード所要時間は、番組のファイルサイズを転送レートで割る事により、ダウンロードの所要時間の推定値を算出する事ができる。例えば、ファイルサイズが１４４Ｇｂｉｔで、転送レートが４Ｍｂｐｓであれば、ダウンロード時間は、１４４Ｇｂｉｔ÷４Ｍｂｐｓ＝１０時間となる。転送レートは、例えば、サーバへ試験信号を送り、そのサーバからレスポンス信号が戻ってくるまでの時間を用いて測定することができる。

ダウンロード所要時間が推定されると、ダウンロードのスケジューリングの方法として、現在時刻からダウンロード所要時間だけ遡った時刻が最も早いものを優先してダウンロードするという手順を採用できる。例えば、番組情報参照部１３３を参照することで、番組Ｅの番組開始時刻が２００７年１２月１８日の２３時００分であり、そのコンテンツのダウンロード所要時間が１０時間であると推定できるとすれば、２００７年１２月１８日の１３時までにダウンロードを開始する必要がある。これに加えて、他の番組Ｆに関して同様にして求めたダウンロードを開始すべき時刻が２００７年１２月１８日の２３時１０分であったとすると、ノンリアルタイム配信受信スケジューラ１４１は、番組Ｅの後で番組Ｆという順にダウンロードの順番を決めればよい。以下、ダウンロード所要時間の推定値を利用したスケジューリングについて図７を参照しながら説明する。

３．１）ダウンロード所要推定時間を用いたスケジューリング
図７は本発明の第１実施例による電子機器システムのノンリアルタイム配信受信スケジューラにより実行されるスケジューリング動作の第２例を示すフローチャートである。

まず、制御部１３８は、ダウンロード番組コンテンツの中で未だダウンロードしてないものが存在するか否かを判定する（ステップ６０１）。ダウンロードしていないダウンロード番組コンテンツがあれば、それをダウンロードするのに要する転送レートを確認する（ステップ６０２）。

転送レートは、サーバにアクセスして実際に測定してもよいが、ネットワークプロバイダとの契約などにより予めサーバからの転送レートがわかっていれば、その値を用いればよく、必ずしも実測する必要はない。また、ネットワークに予め転送レートを確保しない場合でも、ある時刻の平均的転送レートの値を求めておき、それを利用してもよい。たとえば、何曜日の何時頃に得られる平均的転送レートを予め統計的に求めておき、その値を利用する。

続いて、ダウンロードする番組コンテンツのファイルサイズを番組情報参照部１３３から参照し、求めた転送レートを用いて各ダウンロード番組コンテンツのダウンロード所要時間を推定する。そして、現在時刻および番組開始時刻を参照し、ダウンロード番組コンテンツのダウンロードの優先順および／またはダウンロード時刻を定める（ステップ６０３）。たとえばスケジューリングとしてダウンロード時刻を決定するものとすれば、ノンリアルタイム配信受信スケジューラ１４１は、現在時刻とスケジュールとを参照し、その時点でダウンロードすべき番組が存在するか否かをチェックする（ステップ６０４）。ダウンロードすべき番組が存在すると（ステップ６０４：Ｙｅｓ）、当該番組コンテンツのダウンロードを開始する（ステップ６０５）。そして、ダウンロードを開始した後に、再スケジューリング要因が発生したか否かを常にチェックする（ステップ６０６）。再スケジューリング要因としては、新たな番組情報が得られダウンロードすべき番組が増加した場合や、ネットワーク障害などにより転送レートが低下した場合、スケジューリングしたダウンロード番組の全てをダウンロード完了した場合、などが考えられる。

なお、ここでは、ステップ６０５においてダウンロードを開始後にステップ６０６を常時チェックしたが、ステップ６０５においてダウンロードが完了してから、次のステップに移行してもよい。

３．２）効果
このように、使用可能な転送レート（ネットワーク帯域）を把握してダウンロードのスケジューリングを行う事により、番組開始時刻までに番組コンテンツのダウンロードを完了させるスケジューリングをより正確に且つ確実に行う事ができる。

更に、より効率的なダウンロードを行う事ができるという効果もある。例えば、深夜にストリーミング配信を行っていないチャンネルが多数あったとすると、深夜にはネットワークの帯域が空いている事になる。したがって、深夜に大量にダウンロードし、昼間はあまりダウンロードしない、というようにスケジューリングする事により効率的にネットワークを利用する事が可能となる。また、曜日あるいは１年の内のある日付に対し、またはその時刻毎に使用できるネットワーク帯域の実測値を保持しておく事で、ある日付、時刻における平均的な使用可能ネットワーク帯域の予測精度が高まる。例えば、月曜の１０時にトラヒックが混んでいるとすると、その時間を避けるダウンロードのスケジューリングを行えばよい。

ダウンロード時刻を定めるスケジューリングの方法として、上記のように周期的に時刻を定める以外に、ランダムに、もしくはあるイベントが発生する毎に、もしくは、それらの組み合わせで、ネットワーク帯域が空いている時間を推定し、ダウンロード時刻を定める、という方法もある。

上述したように、ダウンロード配信した番組の再生中は、少なくともその番組に関してはストリーミングによりネットワーク内の帯域は消費されない。したがって、その空き帯域を利用してダウンロードを行うようにダウンロードのスケジューリングを行うと、ネットワークの空く時間帯を作らずに、ネットワークの帯域資源を有効に活用できる事になり、より一層、番組開始時刻までにダウンロードを完了し易くなる。ダウンロードに使用できる空き帯域は、伝送レートから、その時点でのリアルタイム配信の再生レート（転送レート）の合計を差し引いて算出する事ができる。

４．スケジューリング（第３例）
図８は本発明の第１実施例による電子機器システムのノンリアルタイム配信受信スケジューラにより実行されるスケジューリング動作の第３例を示すフローチャートである。ただし、ステップ６０１および６０２は、図７に示す第２例と同様であるから説明は省略する。

図８において、ステップ６０２で転送レートを求めた後、ダウンロードする番組コンテンツのファイルサイズを番組情報参照部１３３から参照し、ステップ６０２で求めた転送レートを用いて各ダウンロード番組コンテンツのダウンロード所要時間を推定する。そして、現在時刻および番組開始時刻を参照し、ダウンロード番組コンテンツのダウンロード順のみを決定したとする（ステップ７０３）。この場合、次にダウンロードすべき番組を確認し（ステップ７０４）、ダウンロードを実行する（ステップ７０５）。

ここで、図４におけるステップ３０５でも述べたように、図８のステップ７０５においても、ダウンロードが完了してから次のステップに移行するとしたが、ダウンロードを開始してから次のステップに移行してもよい。

ダウンロードやスケジューリングに関する他の方法として、一つの番組コンテンツのファイルのダウンロードが完了した時点で、再びスケジューリングを行う、という方法を用いても良い。

また、ダウンロードの途中の段階まで完了したら、次のダウンロード行う、というスケジューリングでもよい。例えば、ファイルサイズの９割をダウンロードしたら、次のダウンロードを行うとしてもよい。

５．スケジューリング（第４例）
また、ある時点において、リアルタイム配信の番組が少なければ、リアルタイム配信用の帯域をノンリアルタイム配信用に使用させ、またノンリアルタイム配信の番組が多ければ、ノンリアルタイム配信用の帯域をリアルタイム配信用に使用させる事により、より一層、ネットワークを有効に使用する事ができる。

たとえば、ある時刻において、リアルタイム配信の番組の数を番組情報参照部１３３を見て把握する。リアルタイム配信の番組コンテンツとして、再生レートが１Ｍｂｐｓ、２０Ｍｂｐｓ、４０Ｍｂｐｓのものがあるとする。その場合、必要な転送レートの合計は、それらの和である６１Ｍｂｐｓである。今、アクセス回線として１００Ｍｂｐｓの光回線を使用しているとすると、その時点でダウンロードには、少なくとも３９Ｍｂｐｓ使用できる。またある時点では、再生レートが１Ｍｂｐｓ、４Ｍｂｐｓのリアルタイム配信の番組コンテンツしか無かったとすると、その時点で、ダウンロードに少なくとも９５Ｍｂｐｓ使用できる。なお、その時点で、実際にリアルタイム配信を受けている数が少なければ、ダウンロードに使用できる帯域は増加する。たとえば、上述した第３例において、４Ｍｂｐｓと１Ｍｂｐｓのリアルタイム配信を行う番組構成であっても、実際には、視聴用に１Ｍｂｐｓの方の番組しかリアルタイム配信を受けないのであれば、ダウンロードに使用できる帯域は９９Ｍｂｐｓとなる。ダウンロード（ノンリアルタイム配信）のスケジューリングの際は、このように、リアルタイム番組の構成やリアルタイム配信を受けるために使用している通信帯域の状況を参照するなどして、刻々と変化するダウンロード使用可能な帯域を考慮してスケジューリングすれば、より最適にスケジューリングできる。

６．スケジューリング（第５例）
ダウンロード所要時間を推定できる場合、ダウンロードのスケジューリングの別の手段として、次の方法を用いる事も可能である。

まず、あるスケジュールを立て、それによって全ての番組コンテンツのダウンロードが番組開始時刻までに完了すれば、スケジーリングを終了し、そうでない場合にはダウンロード開始時刻を他に変更するなどし、考えられ得る他のスケジュールで全体がうまくいくか確認していく。そして、スケジュールを修正しながら、全ての番組を再生開始時刻前にダウンロード出来るスケジュールを見つける、というヒューリスティックな方法を用いても良い。

具体的には、番組Ｇのダウンロード所要時間が１０時間で、現在時刻が番組Ｇの番組開始時刻の２０時間前であり、番組Ｈのダウンロード所要時間が２時間で、現在時刻が番組Ｈの番組開始時刻の５時間前であるとする。その場合、例えば、最初に（現在時刻において）番組Ｈのコンテンツのダウンロードを２時間かけて行い、その完了後（現在時刻から２時間後）に、番組Ｇのコンテンツのダウンロードを開始する、というスケジューリングを行えば、番組Ｇ、番組Ｈの両方の番組のダウンロードを、それぞれの番組開始時刻までに完了する事ができる。この場合、ＧとＨのダウンロードの順を逆にしても両方の番組とも、番組開始時刻までにダウンロード可能である。

他の場合として、番組Ｉのダウンロード所要時間が１０時間で、現在時刻が番組Ｉの番組開始時刻の１１時間前であり、番組Ｊのダウンロード所要時間が２時間で、現在時刻が番組Ｊの番組開始時刻の１３時間前だとする。先に番組Ｊをダウンロードすると、番組Ｉの番組開始時刻９時間前になってしまい、番組Ｉのダウンロード所要時間は１０時間なので、番組Ｉのダウンロードが番組開始時刻までに完了しない事になる。従い、違うスケジューリングの可能性を探る事になる。先に（現在時刻において）番組Ｉのダウンロードを開始し、その完了後（現在時刻から１０時間後）の時刻に、番組Ｊのコンテンツのダウンロードを２時間かけてダウンロードするスケジューリングを行えば、番組Ｉ、番組Ｊの両方の番組のダウンロードを、それぞれの番組開始時刻までに完了する事ができる。したがって、後者のスケジュールを採用する事に決定できる。

また、スケジューリングの優先度の設定の方法として、あるダウンロード配信型の番組コンテンツに関して、当該番組コンテンツの再生レートと、その番組再生時点でリアルタイム配信を受ける他の番組コンテンツの転送レートとの合計のビットレートが、伝送レートに近いビットレートである場合は、ダウンロード用に確保できる帯域が少ないので、ダウンロードの優先度を下げる、という方法を用いてもよい。

また、ダウンロード時刻を決定した後には、それを早い順に並び替えれば、順番を決定するようにもできるので、ダウンロード時刻を決定する方法は、ダウンロードする順番を決定する方法にも適用できる。

７．その他のスケジューリング方法
ダウンロードする際、伝送レートと転送レートを考慮し、複数のダウンロードを並行して行うようなスケジューリングを行っても良い。例えば、８Ｍｂｐｓの伝送レートの伝送路にて４Ｍｂｐｓの転送レートのダウンロードを２つ同時に行ってもそのダウンロードスケジューリングは実現可能である。

このように、スケジューリングは、必ずしもある時刻に１つのファイルをダウンロードするようにする必要がなく、同時に複数のファイルをダウンロードするようにスケジューリングしてもよい。サーバや電子機器システムのノンリアルタイム配信受信部のダウンロード処理能力やネットワークのトラヒックとして、複数同時にダウンロード処理できれば問題ないからである。

図４に示すスケジューリング第１例によりダウンロードの適切なスケジューリングを行えば、ダウンロード配信の番組は、全てダウンロード済みのはずであるが、万一、ダウンロード済みでない場合、（転送レート）＞（その番組のコンテンツの再生レート）であれば、ノンリアルタイム配信受信手段１３５によりファイルのダウンロードを行い、ダウンロードしながら再生（プログレッシブダウンロード）を行ってもよい。

また、スケジューリングを管理するプロセスと個別のコンテンツのダウンロードの進行状態を管理するプロセスを同時に走らせて、ダウンロードの進行状態に依存して、再スケジューリングを行う方法を用いてもよい。例えば、ある方法では、一度、スケジューリングを行ったら、そのスケジュール通りのダウンロードが全て完了するまで、スケジュールに沿ってダウンロードを行う。その後に再びスケジューリングを行う。

さらに、視聴者が予め、視聴したい番組にマーキングを施す方法を用いた場合、図４のステップ３０３、図７のステップ６０３、図８のステップ７０３等でのダウンロードのスケジューリング方法としては、視聴予定のマーキングがなされている番組を優先してダウンロードするように設定する方法を用いてもよい。

また、スケジュールに沿ってダウンロードしているときに、ダウンロードに使用できる帯域がネットワーク障害などにより減少した場合、その時点のリアルタイム配信を妨げるダウンロードのジョブを停止させ、リアルタイム配信を優先させると、その時点での視聴を妨げる事がない。その後は、ダウンロードを一時停止しただけであれば、その時点で持っているスケジュールに沿ってその後のダウンロードを行ってもよいし、その時点の帯域を考慮してダウンロードのスケジューリングを再び行ってもよい。

ネットワークの状況により再スケジューリングを行う場合あるいは行わない場合のいずれであっても、ダウンロードの一時停止および再開を行うことができるダウンロードソフトウェアを用いることができる。この場合、ネットワークのトラヒックが混雑してきたら、ダウンロードを一時停止させ、トラヒックが空いたらダウンロードを再開する、というダウンロード管理を行うことが可能となる。その際、あるコンテンツのダウンロードを一時停止した段階で、再スケジューリングを行ってもよいし、もしくは、そのコンテンツのダウンロードを再開し、全てダウンロードが完了した時点で再スケジューリングを行ってもよい。即ち、ダウンロードの進行状態のどの段階を再スケジューリングのきっかけとしてもよい。

上述した実施例の説明においては、番組の開始時刻を用いて番組コンテンツのダウンロードのスケジューリングを行う方法を示したが、番組開始時刻として、幅を持った時間帯として定めても本実施例を適用可能である。例えば、番組開始時刻として１時から１０時までの間、というような幅を持たせてもよい。

また、上記実施例では、コンテンツ提供システム１００から電子機器システム１３０へ直接配信する例を示したが、電子機器システム１３０の近傍にて、コンテンツの提供システムの代理となるサーバ（エッジサーバ）を設けて、そこから配信することも可能である。

さらに、番組情報登録・提供システム１２０やコンテンツ提供システム１００は、単数の例を示したが、複数存在しても本実施例を適用可能である。また、上記実施例において、番組情報登録・提供システム１２０は、一箇所に集中して配置されている例を示したが、分散して配置されていても実施可能である。１つのファイルを分割し分散して提供する場合や、異なるファイルを異なるサーバから提供する場合の、どちらでも本実施例を適用可能である。

また、ダウンロードするシステムとして、クライアント-サーバ型のシステムを用いたが、たとえばＰ２Ｐ（ピア・トゥ・ピア）技術を用いて電子機器システムどうしにおいて互いにコンテンツのダウンロードを行うことも可能である。これによりコンテンツを配信するシステムの負荷を分散する事ができ、ダウンロード時間を短縮することができる。

Ｐ２Ｐ型のダウンロードを実施するには、電子機器システム１００やコンテンツ受信システム４０にＰ２Ｐのソフトウェアをインストールし、動作させておけば良い。そして、Ｐ２Ｐのソフトウェアは、コンテンツに割り当てられた番組識別子をキーとして、ファイルをダウンロードできるサイトを探し、ファイルをダウンロードする。もしくは、ファイルを断片化し、それを複数のサイトに分散させて保持している場合には、そのような複数のサイトを探し、それらの複数のサイトからファイルの断片を全てダウンロードし、その後、ファイルの断片を合成してファイルを構成する。

ある番組識別子を持つファイルが存在するサイトの情報は、Ｐ２Ｐソフトウェアが互いに通信することにより収集する事ができる。この場合は、番組に対応するファイル又はファイルの断片のダウンロードＵＲＬは、Ｐ２Ｐシステム（Ｐ２Ｐソフトウェアを動作させているサイト、又は、それらを管理するサイト）が保有することになるので、番組情報登録・提供システム１２０は、番組に対するＵＲＬを保有しなくても良い。又、別の方法として、コンテンツのＵＲＬの情報を番組情報登録・提供システム１２０に持たせる事も可能である。例えば、ファイル又はファイルの断片の存在するＵＲＬを管理するサイト（以下、Ｐ２Ｐ管理サイトと呼ぶ）を設ける。そして、番組情報登録・提供システム１２０が持つ、番組コンテンツのＵＲＬとして、Ｐ２Ｐ管理サイトを指定すれば良い。そうすると、電子機器システム１００は、Ｐ２Ｐ管理サイトを参照して、ファイル又はファイルの断片をダウンロードする事が出来る。この場合、Ｐ２Ｐ管理サイトと、Ｐ２Ｐ管理システムが保持するＵＲＬサイトとからなるシステムが、ノンリアルタイム配信提供システム１０１に相当する。又、Ｐ２Ｐ管理サイトが無い場合は、番組のコンテンツの存在場所としてＰ２Ｐソフトウェアを動作させているサイトの１つを指定しておけば、そのサイトをとっかかりに、ファイルをダウンロードする事ができる。

８．コンテンツ再生判定の第２例
上述した新規に番組を再生すべき状態かどうかの判断（図５のステップ４０１）の第２例について説明する。ここでは、ＥＰＧ（電子プログラムガイド）を視聴者に見せて、視聴番組のシナリオを作成し、それに従って再生判定を行う。すなわち、視聴者は、視聴者インタフェース１４０を介して、番組情報参照部１３３に保持した情報を見る事により、例えば、何年何月何日何時何分から何チャンネルで、どんな番組が放送予定か把握する事が出来る。視聴者インタフェースとして、そのような番組情報を画面に表示させる構成を用いる事により、ＥＰＧとして機能させる事ができる。そして、視聴者は、視聴者インタフェース１４０を通して、自分が見たい番組に視聴予定のマーキングを入れることが可能である。そこで、再生する番組のシナリオを作成し、そのシナリオに沿って再生する場合の「新規に番組を再生すべき状態かどうかの判断」方法について説明する。

図９は本発明の第１実施例による電子機器システムのコンテンツ再生判定手順の第２例を示すフローチャートである。ただし、図６に示す第１例と同じステップには同じ参照番号を付して説明は簡略化する。

図９において、視聴者がチャンネルの切り替えを行ったかどうかチェックし（ステップ５０１）、切り替えを行わなかった場合（ステップ５０１：Ｎｏ）、制御部１３８は番組再生シナリオが予め登録されているかどうかをチェックする（ステップ８０２）。ただし、番組再生シナリオが存在する場合においても、視聴者がチャンネルを切り替えると、新規に切り替えた番組の再生をシナリオで定めた番組よりも優先する。これにより視聴者が番組再生シナリオで定めた番組と異なる番組を見たくなった場合に対応できる。

ここでは、番組シナリオは、何月何日の１０時からはこの番組コンテンツ、１１時からは別のチャンネルの番組コンテンツというように再生番組が時刻において定まっている事を指す。例えば、画面に番組情報を表示させ、視聴者が視聴者インタフェース１４０（例えば、リモコン）を操作することで、視聴したい番組コンテンツに視聴予定のマーキングを行う事により番組再生シナリオを作成する事ができる。視聴予定のマーキングは、番組の識別子に対して、マーキング用のメモリ領域を確保しておき、そのビットの値を変化させる事により実行できる。視聴したい番組にマーキングを行う事により、予め登録した見たい番組にチャンネルを自動的に切り替えさせる事が可能となる。

ステップ８０２において、番組再生シナリオがあった場合（ステップ８０２：Ｙｅｓ）、番組シナリオを参照した結果、番組切り替え時で無ければ（ステップ８０３：Ｎｏ）、新規に番組を再生しない状態となる（ステップ５０４）。番組再生シナリオを参照し、その時点の時刻と比較した結果、次の番組を再生する直前であるとすると、それは即ち、新規に番組を再生すべき状態と言えるので、ステップ８０３においてＹｅｓとなる。その時点の時刻は、日付時刻参照部１３６を参照する事により知ることができる。そして、一旦、ステップ５０５にて認識した番組の再生を開始したら、既に述べたように、新規に番組を開始する状態を脱し（ステップ５０６：Ｙｅｓ）、新規に番組を再生しない状態となる（ステップ５０４）。

番組再生シナリオとして、上記の例では、視聴者がシナリオを登録していなければ、番組再生シナリオがないと判断したが、別の方法として、シナリオが登録されていなければ、現在再生中の番組が終了したら、現在のチャンネルにおいて次の番組を再生するシナリオになっていると見なすこともできる。

以上の図９の説明において、新規に再生すべき状態となったら、図５のフローのステップ４０１のＹｅｓのフローに戻り、上述したように、ダウンロード配信かストリーミング配信かの場合分けの判断（ステップ４０２）に続いて番組の再生を行う（ステップ４０３あるいはステップ４０４〜４０５）。

なお、電子機器システム１３０は、番組録画装置としても機能させる事が可能である。予め、保存が必要な番組に録画予定のマーキングを施す事により、マーキングを施した番組については、ダウンロードした番組の再生が完了した後も、コンテンツ保存部１３７から消去せずに、保存しておくと実現可能である。またストリーミングにより配信を受ける番組コンテンツに関しても、録画予定のマーキングのついたものを同様に録画しておきたい場合は、ストリーミングを受けて再生するビットの流れを検出し保存すればよい。

番組録画装置として機能させる際、保存領域として、録画のためのディスク領域とノンリアルタイム配信の番組ダウンロードのための保存するディスク領域を予め分けておく事により、ノンリアルタイム配信用の保存容量は常に一定容量確保され、ノンリアルタイム配信用のコンテンツ保存部１３７が不要なファイルで満たされてしまうという事態を回避する事が可能である。

本実施例によれば、番組コンテンツがリアルタイム配信型であるか、ノンリアルタイム配信型であるかを、視聴者が見られる番組表（ＥＰＧ）に表示させる必要がない。即ち、視聴者にリアルタイム配信型（ストリーミング配信や電波による放送）か、ノンリアルタイム配信型（ダウンロード配信）か、意識させる必要がなく、そのような技術に疎い人（子供など）にも支障なく使用させる事が可能であるという効果を有する。

上述した第１実施例では、リアルタイム配信方法として、ストリーミング配信を用いる方法を示したが、地上デジタル放送、衛星通信、衛星放送、ＣＡＴＶなどの他の放送信号を送信、受信するシステムを用いてもよい。その場合のシステム構成は、図２において、リアルタイム配信提供システム１０２として映像信号送信機を用い、ネットワークではなく電波、もしくは同軸線路を流す高周波電気信号（ＣＡＴＶの場合）を変調して、リアルタイムコンテンツを電子機器システム１３０に送る。その場合、電子機器システム１３０のデータ転送インタフェース１３１としては、放送された電波を受信できる受信機と放送信号の再生処理を行う手段を含んだインタフェースとなる。コンテンツ出力手段１３９にて映像信号を表示できる形態の信号に変換すればよい。

また、データ転送手段１１０として、ＩＰネットワークを用いる例で説明したが、ＩＰネットワークに限らず、パケットやフレームを用いるネットワークであれば、本発明は実施できる。例えば、イーサネットネットワークであっても良いし、ＡＴＭ（非同期転送モード）ネットワークであってもよい。

ＩＰネットワークを用いて映像などのコンテンツや番組情報を配信する構成について説明したが、地上波デジタルシステムや、通信衛星を用いた放送、衛星放送システム、ＣＡＴＶシステムなどにおいても、放送の帯域の一部をダウンロード配信用の帯域とする事により、その帯域を用いてダウンロード配信が可能となる。リアルタイムで放送する以外に予めダウンロードして配信する方法を採用すれば、放送のチャンネルで割り当てられた以上の帯域を必要とするコンテンツの配信を行う事が可能となる。

例えば、通常、放送の１チャンネルの放送の帯域として２０Ｍｂｐｓの転送レートの帯域しか割り当てられていない場合、２０Ｍｂｐｓ以上の再生レートのコンテンツを、放送により配信する事ができない。しかし、別の２０Ｍｂｐｓの放送の帯域をノンリアルタイム配信用に用いる事にすると、２０Ｍｂｐｓ以上の再生レートのコンテンツの配信が可能となる。例えば、４０Ｍｂｐｓの再生レートで、番組の長さが１時間であるコンテンツがあった場合、２０Ｍｂｐｓの転送レートの放送の帯域を用いて、番組開始時刻前までに、２時間配信すれば良い。そして、電子機器システム１３０は、それを保存しておき、番組開始時刻になったら再生する。

また、ノンリアルタイム配信用の別のチャンネルを準備する、という上記の方法以外に、リアルタイムに放送するチャンネルを行っていない時間帯を用いて、ノンリアルタイム配信を行ってもよい。例えば、朝の５時から夜の１時までは放送の電波のチャンネルにより、リアルタイム配信を行い、夜の１時から朝の５時までは、ノンリアルタイム配信用に同じ放送の電波のチャンネルを利用する。

ノンリアルタイム配信提供システム１０１として、このような放送システムを採用した場合、既存のリアルタイム配信用の放送設備の大きな変更や更新を行う事なく、単位時間あたりの情報量がより多いコンテンツの配信を行う事ができるようになるという効果がある。例えば、既存の地上波デジタルの設備を持つ放送局では、２０Ｍｂｐｓの再生レートのコンテンツしか配信できないとすると、４０Ｍｂｐｓのコンテンツを配信するには、４０Ｍｂｐｓのコンテンツを配信できるように放送設備を更新する必要がある。しかし、本実施例を用いると、２０Ｍｂｐｓの再生レートのコンテンツしか放送できない設備を用いて、倍の時間をかけてコンテンツのファイルを転送すれば、４０Ｍｂｐｓの再生レートのコンテンツを転送できるから、放送設備の大きな変更や更新を行う事なく転送レートより大きい再生レートのコンテンツを配信できる。

また、ダウンロードした番組のコンテンツの再生中には、その番組のリアルタイム配信が必要ないので、その時間帯に放送するべきチャンネル数を減らす事ができる。それにより、その時間帯にダウンロード可能な帯域が増加したり他のアプリケーションに利用したりすることができる。

９．第２実施例
本発明の第２実施例として、リアルタイム配信方法として、ストリーミング配信を用いる方法と、電波による放送やＣＡＴＶのように高周波電気信号を変調しケーブルを通して配信する方法との両方を用いたシステムについて説明する。

図１０は、本発明の第２実施例によるコンテンツ配信システムにおける電子機器システムの概略的構成を示すブロック図である。ただし、図２に示すブロックと同一機能を有するブロックには同一参照番号を付して説明は適宜省略する。

本実施例では、リアルタイム配信提供システムとして、放送局９００とストリーミングサーバ９０２の２種類がある。放送局９００は、無線または有線を問わず、映像信号により高周波キャリアを変調することで放送信号あるいはＣＡＴＶ信号を送信する機能を有する。また、データ転送ネットワーク９０１はＩＰネットワークなどを用いることができる。

電子機器システム１３０のデータ転送インタフェース９３１は、イーサネットの終端機能に加えて、放送局９００からの放送信号やＣＡＴＶなどの同軸線路に伝送される高周波信号を受信する受信機能を有する。

さらに、電子機器システム１３０には、リアルタイム配信受信部として、放送信号受信・再生処理部９０１およびストリーミング配信受信部９３４が設けられている。放送信号受信・再生処理部９０１は放送受信器あるいはＣＡＴＶ受信器で受信した信号を映像信号に変換する。ストリーミング配信受信部９３４は、ストリーミングサーバ９０２からのストリーミング配信される信号を受信する。

コンテンツ出力部１３９は、放送信号受信・再生処理部９０１、ストリーミング配信受信部９３４あるいはコンテンツ保存部１３７からの情報を受けて、番組情報参照部１３３を参照して認識した再生されるべきその時点の情報を選択して切り替え出力する。

本実施例によれば、リアルタイム配信手段として、放送電波や同軸の高周波信号経由とデータ転送ネットワーク経由の両方の信号処理機能を備えている。したがって、両方の経路で同一の番組を配信する場合は、どちらかに障害が発生しても、その番組のリアルタイム配信での視聴を継続する事が出来る。

電子機器システム１３０のコンテンツ保存部１３７は、たとえばハードディスクなどであるが、その容量は有限である。したがって、たとえコンテンツのファイルサイズに比べて非常に大きい容量であっても、ダウンロードされた過去のファイルが蓄積されると、いずれ新しいファイルのダウンロードが出来なくなってしまう。

これを回避するためには、ダウンロードしたファイルの保持を一定の期間に限定し、その期間が経過すると自動的に消去する方法が考えられる。例えば、２週間前にダウンロードしたコンテンツは、削除するという削除ポリシーを予め登録しておけば、不要なファイルでコンテンツ保存部１３７が満たされる事態を回避することができる。その際、番組コンテンツの内容やファイルサイズにより、消去するファイルの優先順を決めておくと、その優先順に沿ってファイルを消去する事が可能である。

他の方法として、番組配信側で、ある時刻になったら自己消去する、もしくはファイルサイズを小さくするという仕組みを設けたファイルを配信する方法を用いてもよい。例えば、コンテンツの配信する形態として、番組コンテンツそのもののファイルと、コンテンツの再生実行コマンドおよびファイル消去の実行コマンドが記述されたスクリプトファイルとを含めた、書き換え不能なバッチファイルとして配信する。番組開始時刻になって、その番組が再生されるように視聴者がチャンネルを選択していたら、コンテンツのバッチファイルを実行する。バッチファイルに記述したスクリプトに基づき、コンテンツのファイルの再生を実行する。そして、コンテンツの再生が完了したら、バッチファイルに記述したスクリプトに基づき、そのファイルの消去を実行すればよい。

また、再生不可とする時刻をそのバッチファイルに記述しておき、周期的に日付時刻参照部１３６を用いて現在時刻を確認し、再生不可な時刻になったかのチェックを周期的に行うと、消去する時間を再生終了時刻のみでなく、種々の時刻に設定できる。

さらに、ファイル自身に含ませる方法以外に、番組情報登録・提供システム１２０に登録する情報として、コンテンツを消去する日付時刻を付加し、電子機器システム１３０の番組情報参照部１３３が、その情報を参照する事により、そのコンテンツのファイルを消去すべきかどうかを判断するという方法も可能である。

また、ファイルを自己消去する仕組みだけでなく、再生不可の時刻になったらファイルの中身をＮｕｌｌ（何もなし）などの内容に書き換えるという方法を用いてもよい。この場合、電子機器システム１３０は、周期的に中身がＮｕｌｌのファイルを抽出し、それを消去する仕組みを設けておけば、中身がＮｕｌｌのファイルで溢れることを防ぐことができる。

なお、電子機器システム１３０の形態としては、ＳＴＢ（セットトップボックス）の形態でもよいし、コンテンツ出力部１３９の先にディスプレイなどのコンテンツ表示手段を付加して、ユーザにコンテンツを視聴できるようにしたディスプレイ一体型としてもよい。又、各機能ブロックは同一の筐体に入っている必要はなく、例えば、コンテンツ保存部１３７以外の機能ブロックを同一の筐体に実装し、コンテンツ保存部１３７は、その筐体へ外付けとしてもよい。

また、上記実施例では、コンテンツ出力部１３９として、１つのコンテンツのみを出力する場合について記載したが、それに限定される訳ではなく、コンテンツ出力部１３９が同時刻に番組を組まれている複数のコンテンツを同時に出力してもよい。

本実施例では、コンテンツ保存部１３７を電子機器システム１３０に含めた構成を用いたが、ノンリアルタイム配信受信部１３５がコンテンツ保存部１３７に接続されてさえいれば、コンテンツ保存部１３７は電子機器システム１３０の外に配置されていてもよい。

番組情報としては、上記で述べた以外に、番組のタイトル、番組の概要、番組終了日時、コンテンツのファイルサイズ（配信方法がダウンロードやストリーミングの場合）、再生レートなどの番組情報を付加しても良い。ファイルのダウンロードによって配信する場合、いつダウンロードできるようにアップロードするかの日時を番組情報に含める事も可能である。その他の番組情報として、番組のスポンサーの広告を関連情報として含める事も可能である。ある番組に対し、コンテンツのダウンロードだけでなく、スポンサーのコマーシャル映像も番組開始前にダウンロードさせても良い。コンテンツ配信者は、番組情報登録・提供システム１２０にこれらの情報を登録する。その後、電子機器システム１３０が、それらの番組情報をダウンロードし利用する。番組情報登録・提供システム１２０は、番組情報の登録を受け付けるための登録手段と、登録された番組情報を視聴者に配信するための配信手段を備える。

番組のコンテンツのダウンロードを既に行ったか、それとも未だダウンロードしていないかの判断は、以下の方法により、行う事が出来る。ダウンロードの履歴を一定期間（例えば、番組再生終了後まで）、電子機器システム内（例えば、制御部１３８）に保持しておけば、その保持した履歴情報を参照することでダウンロードしたかどうかを判断できる。別の方法として、ダウンロードしたファイル名を番組のコンテンツのファイルと一対一に対応させれば、コンテンツ保存部１３７に存在するファイル名を参照する事により、ある番組のコンテンツがダウンロード済みであるか判断する事ができる。一対一の対応付けの方法としては、例えば、ファイル名を番組のコンテンツの識別子と一致させれば、番組とそのコンテンツのファイルとの一対一の対応付けを行う事ができる。別の方法としては、電子機器システム１３０内の番組情報参照部１３３に、番組毎に、ダウンロード済みか否かの情報を保持する領域を設け、必要に応じチェックすれば良い。

また、別の方法として、ダウンロード済みかどうかの情報を保持しなくても、本発明は実施可能である。すなわち、ダウンロードしようとした時に、ダウンロードしようとしているファイル名と同名のファイルが既にコンテンツ保存部１３７に存在すか否かをチェックする。同名ファイルがコンテンツ保存部１３７に存在すれば、既にダウンロード済みである事がわかるので、その時点でダウンロードの動作を止めればよい。同名のファイルが存在しなければ、ダウンロードを開始すればよい。

もしサーバ側がダウンロード済みかそうでないかの情報を持つとした場合には、その番組のコンテンツを視聴する可能性のある視聴者の情報を全てサーバ側で持つ必要があり、視聴者が増えた場合に視聴者情報の管理が困難になる。例えば、数億人の視聴者候補がいる場合、その視聴者情報を検索時間は長時間になり、対応が不可能である。それに対し、本発明では、受信側である電子機器システム１３０がダウンロード済みか否かの情報を持つので、そのような問題はない。

番組のスポンサーのコマーシャル映像を予めダウンロードさせる方法を用いても良い。コマーシャル映像は、ダウンロードした映像を再生する事により表示し、番組の中身本体は、リアルタイム配信を受けて再生という方法を用いる事もできる。この方法により再生する際は、予め定めたコマーシャルの時間枠は、ダウンロードしたファイルの再生を行い、次に番組の本内容の時間枠になるとリアルタイム配信を受けるように、時間で区切って、コンテンツ出力手段に渡す信号を切り替えれば良い。

逆に、コマーシャルはリアルタイム配信を受け、番組コンテンツの本内容はノンリアルタイム配信としても、割り当てられた時間で区切ってコンテンツ再生装置に渡す信号を切り替えれば実現可能である。

ＩＰパケットの転送方法としては、ポイント・トゥ・ポイントでも良いし、マルチキャスト等、他の転送方法を用いてもよい。

他の方法として、ダウンロードするファイルを時間的に分割してダウンロードする方式を用いても、本発明は支障なく実施可能である。それは、次のような方式である。ダウンロード配信するコンテンツのファイルを分割し、予めダウンロードするのは、ファイルの一部のみとしておく。残りの一部のファイルは、実際にその番組を再生する状況になってから、残りのファイルの一部をダウンロードし、結合して再生しても、番組開始時刻での再生に間に合う程度のファイルサイズとしておく。そして、実際にその番組を再生する状況になってから、残りのファイルの一部をダウンロードし、結合して再生する。

受信可能なチャンネルが多い場合は、ある時刻においてチャンネルを切り替えても、すぐにコンテンツ固有の再生レートで再生できるチャンネル群を指定する方式を用いても良い。例えば、チャンネル数が３００チャンネルあるシステムにおいて、チャンネル番号１からチャンネル番号１００までは、本発明を適用し、全てのダウンロード配信番組をダウンロードし、チャンネル１０１からチャンネル３００までは、予め、視聴者が視聴予定と番組にマーキングした場合のみダウンロードする、という方法である。

１０．第３実施例
本発明の第３実施例によれば、ダウンロードをした番組のコンテンツを番組開始時刻まで視聴者が見る事ができないような仕組みを付加する。テレビ放送においては、番組開始時刻よりも前にコンテンツを見る事ができないのが普通なので、そのような新たな課題が存在する。

図２に示す第１実施例においては、参照すべき時計（日付時刻参照部１３６）を予め定めておき、ユーザがその時計を参照して現在時刻を参照する（例えば図５のステップ４０５などの説明参照）。現在時刻が番組の開始時刻になれば、番組コンテンツの再生が開始される。悪意のあるユーザがいないと仮定すれば、テレビ放送のように、番組は番組開始時刻にならないと視聴する事ができない。しかしながら、悪意あるユーザであれば、ダウンロードしたファイルを何とかして番組開始時刻前に見るという事を行うかもしれない。例えば、コンテンツ保存部１３７にアクセスして、保存してある番組のコンテンツを番組開始以前にコンピュータにコピーしコンピュータ上で視聴するような事態が考えられる。これを防ぐ対策として次に説明する。

コンテンツ提供者がファイルをノンリアルタイム配信提供システム１０１にアップロードする前に、予めファイルにアクセス制限をかけ、ファイルのオープン時に電子機器システム１３０が持つ日付時刻参照部１３６にアクセスし、現在の日付・時刻を把握する仕組みをファイルに持たせておく。その現在時刻が番組開始時刻の直前であると確認したときのみ、番組を再生できるようにファイルのアクセス制限を解除する方法を用いればよい。なお、直前とは、番組コンテンツの再生準備に要する時間分だけ番組開始時刻から遡った時刻をいう。例えば、あるコンテンツのファイルがあった時に、その再生準備に１分かかるとした場合、番組開始時刻の１分前にアクセス制限を解除する。再生準備に要する時間は、予め、コンテンツ作成者が視聴者の平均的な再生環境を考慮の上で指定しておくこともできる。

他の方法として、次に示す方法を用いることができる。予めファイルを暗号化しておき、それをノンリアルタイム配信提供システム１０１にアップロードしておく。電子機器システム１３０は、番組開始時刻までにダウンロードを完了するようにダウンロードをスケジューリングし、番組開始時刻以前にダウンロードを完了させる。電子機器システム１３０にて、現在時刻が番組開始時刻を経過していると確認したときのみ暗号化されたコンテンツを復号し再生させる。その際、番組開始時刻の直前（番組開始時刻からファイル再生の準備に必要な時間だけ遡る）にのみ、番組コンテンツ提供サーバがクライアントにコンテンツの復号鍵を配信する方法や、復号鍵に現在時刻確認機能を設け、システムが保有する日付時刻確認手段により現在時刻を参照し、現在時刻が番組開始時刻を経過していることを確認した場合にのみ、復号鍵が機能するようにする方法を用いれば良い。

また他の方法として、番組情報にて取得した番組開始時刻と、電子機器システム１３０が持っている日付時刻参照手段から得た現在時刻とを比較し、番組開始時刻が番組開始時刻の近傍であって、番組の開始時刻を過ぎて番組のコンテンツが再生されているべき状態の場合にのみ再生するようにし、その他の場合は、再生できないようなフローを、コンテンツを再生する処理手段のフローに含ませておけばよい。

１１．第４実施例
次に時計の信憑性から来る問題への対処方法について述べる。上記のように、時刻と暗号を組み合わせる方法を用いたとしても、日付時刻参照部１３６が参照する時計の時刻を悪意あるユーザに変更されてしまっては、番組開始時刻以前にその番組を視聴できる事になってしまう。以下、本発明の第４実施例として、時計の変更による不正を防ぐ方法について図１１を用いて説明する。

図１１は、本発明の第４実施例によるコンテンツ配信システムにおける電子機器システムの概略的構成を示すブロック図である。ただし、図２に示すブロックと同一機能を有するブロックには同一参照番号を付して説明は適宜省略する。

本実施例では、日付・時刻基準局１０５０を用いて時計の変更による不正を防ぐ。すなわち、日付・時刻基準局１０５０をデータ転送手段１１０に接続したシステム構成を有する。日付・時計基準局１０５０は、ネットワークで他の日付・時刻基準局と接続されており、正確な日付と時刻を持つべく、他の日付・時刻基準局と同期している。電子機器システム１３０は、制御部１３８の命令により日付・時刻基準局１０５０にアクセスする。

時計の変更による不正を防ぐ第一の方法は、番組開始時刻の直前に、日付・時刻基準局１０５０にアクセスして、正確な時刻を確認することである。これは番組開始直前毎に日付・時刻基準局１０５０にアクセスし、日付・時刻基準局１０５０から時刻認証付きのパケットを受け取り、電子機器システム１３０が参照する日付時刻参照部１３５が正しい時刻を表示している事を確認してから、コンテンツ出力部１３９をとして再生装置を起動する方法である。

電子機器システム１３０は、日付・時刻基準局１０５０の暗号鍵、その復号鍵を発行した認証局にアクセスする事により、「その時刻情報を含んだメッセージの送信者は日付・時刻基準局１０５０である事」を確認する事ができ、且つ、表示した時刻は改ざんされていない事を確認する事ができる。例えば、日付・時刻基準局１０５０が秘密鍵を用いて暗号化（データ変換）し、電子機器システム１３０がその秘密鍵に対応する公開鍵で復号化する事により、電子機器システム１３０は、確かに日付・時刻基準局から日付・時刻情報を受信した事を認証できる。

また、次の方法により、時刻情報や認証情報が改ざんされていない事を確認できる。日付・時刻基準局１０５０は時刻情報や認証情報等の内、改ざん防止したい情報に関して、そのダイジェストをハッシュ関数により作成する（非可逆なデータ変換暗号化）。更に、そのダイジェストを日付・時刻基準局１０５０の秘密鍵で暗号化（データ変換）し、時刻情報や認証情報と共に、電子機器システム１３０へ送信する。電子機器システム１３０では、受信したダイジェストを、秘密鍵に対応する公開鍵で復号化する。受信したデータ（時刻情報や認証情報）のハッシュ関数出力と受信したダイジェストとを比較する事により、時刻情報の内容が改ざんされていない事を確認できる。それらが一致していれば、改ざんされていない事になる。

そして、日付・時刻基準局１０５０から電子機器システム１３０にパケットが到達するまでの時間を考慮の上、認識するべき現在時刻を算出する。例えば、日付・時刻基準局１０５０が発行した認証付きの時刻が午前１０時だとしても、日付・時刻基準局１０５０から電子機器システム１３０に到達するまでに１分を要する場合には電子機器システム１３０では、現在時刻を午前１０時１分と補正する。これにより正確な時刻認証ができる。

次に、時計の変更による不正を防ぐ第二の方法について説明する。それは、図５の「新規に番組を再生するべき状態か？」のステップ４０１の直前に、日付時刻参照部１３６が参照する時計が正しい日付・時刻を表示している事を確認するステップを挿入する事により実現できる。それにより、正しい時刻である前提の上で新規に番組を再生するべきかの判断を行う事ができるからである。日付時刻参照部１３６が参照する時計が正しい日付・時刻を表示しているか確認するステップについて説明する。

図１２は本実施例において参照する時計が正しい日付・時刻を表示しているかを確認する手順を示すフローチャートである。ここでは、現在時刻が偽の時刻とされないために、ネットワーク経由あるいは放送の時報の鳴るタイミングを利用して、装置の時計を日付・時刻基準局１０５０と同期させる（較正する）システムを考える。較正するタイミングは、周期的に設定してもよいし、何かのイベントが起こったタイミングとしてもよい。

まず、状況（設定した較正するべきイベントが発生していないか）や時刻を確認し、時計を較正するタイミングであるいか否かを判定し（ステップ１１０１）、較正タイミングであれば（ステップ１１０１：Ｙｅｓ）、時計を日付・時刻基準局１０５０にアクセスして較正する（ステップ１１０３）。時計を較正するタイミングでなければ（ステップ１１０１：Ｎｏ）、較正以外の場合に時計が進められたり遅らされたり（変更された）形跡がないか否かをチェックする（ステップ１１０２）。それを実現するには、例えば、時計を管理するシステムのオペレーションシステムの機能として、時計の較正時以外に時計の時刻が変更されたらフラグを立てておく（そのようなメモリ領域をオペレーションシステムに確保しておき、その事実をそのメモリ領域に記録）、という機能を設けておけばよい。時計の較正の際は時計が変更されるのは当然なので、その場合を除いている。

時計の較正以外で時刻が変更された形跡がなければ（ステップ１１０２：Ｎｏ）、時計は不正の行われていない正しい日付・時刻を持っていると見なす事ができ、正しい日付・時刻の確認が完了する（ステップ１１０４）。

一方、ステップ１１０２において、時計の較正以外で時計の時刻が変更された形跡があれば（ステップ１１０２：Ｙｅｓ）、日付・時刻基準局１０５０にアクセスし、時刻を較正する（ステップ１１０３）。また、時計の周期的な較正がなされていない場合も日付・時刻基準局１０５０にアクセスし時計の時刻を較正する。

なお、番組開始時刻前に視聴させないようにする他の方法として、次のような方法を用いる事もできる。ダウンロードにより配信する（ノンリアルタイム配信）番組コンテンツを予め暗号化しておき、電子機器システム１３０にダウンロードさせる。そして、番組開始時刻直前になって初めて当該番組コンテンツのファイルの復号鍵を番組提供者が配布する、という方法である。この場合、時刻は番組提供者が管理するので、番組提供者の責任の下、適切なタイミングで復号鍵を配る事ができるので、視聴者側の電子機器システム１３０で時刻同期や時刻認証を取る必要がない。

なお、ダウンロードしたファイルは原則として番組開始時刻になるまでは見られないが、例外的に番組配信時刻前でも見られるように設定された番組コンテンツがあってもよい。

また、コンテンツの複製権を持っている視聴者のみダウンロードを許諾する、という方法を採用することも可能である。その場合、電子機器システム１３０の機能として、コンテンツの複製権を持っているかどうかを確認し、権利を持っていない場合は複製を拒絶する手段を備えればよい。また、コンテンツを閲覧する権利を設定し、閲覧権を持っている視聴者のみ閲覧する方式を用いても本発明は支障なく実施可能である。その場合、閲覧権を持っているか、確認する手段を電子機器システム１３０に備えればよい。

さらに複製権でなくても他の権利に関してダウンロードの許諾ルールを設定することもできる。例えば、番組を視聴する権利を設けて、所望の番組を視聴する権利を持っているユーザのみダウンロードを許諾する手段を備えればよい。

１２．具体例
コンテンツをダウンロードするためのプロトコルとしては、ｈｔｔｐ、ｈｔｔｐｓや、ＦＴＰを用いる事ができる。その場合、ノンリアルタイム配信提供システム１０１は、ｈｔｔｐ、ｈｔｔｐｓ、ｆｔｐのサーバプログラムを動作させればよい。電子機器システム１３０のノンリアルタイム配信受信部（ファイルダウンロード処理部）１３５においては、ｈｔｔｐ、ｈｔｔｐｓ、ｆｔｐのクライアントプログラムを動作させればよい。その他のファイル転送のプロトコルを用いても実施可能である。

１２．１） ダウンロードの一時停止、再開の機能を持ったダウンロードソフトウェアを用いても本発明は支障なく実施できる。その場合、ネットワークが混雑したり、サーバの処理が溢れたりした場合に、優先度の低いコンテンツのダウンロードを一時停止する事により、優先度の高いコンテンツのダウンロードを迅速に完了させる事ができる。そのようなソフトウェアとして、例えばＧＮＵのＷｇｅｔがある。Ｗｇｅｔのソースコードは、次の文献１に記載されている。

（文献１）
表題：ＧＮＵ Ｗｇｅｔ
ＷｇｅｔのソースコードのあるＵＲＬ：http://ftp.gnu.org/gnu/wget/
Ｗｇｅｔについて記載されたＵＲＬ：http://www.gnu.org/software/wget/
著作権保持者：Free Software Foundation, Inc、
媒体のタイプ：インターネット上の電子ファイル（ソースコード）
検索日：２００８年１月８日

１２．２） 図７のステップ６０２などで説明したネットワークの使用可能な帯域（使用可能な転送レート）を観測するステップにおいて、ＩＰネットワークの使用可能な帯域はＩｐｅｒｆ等のツールを用いる事により観測できる。Ｉｐｅｒｆのソースコードは次の文献２に記載されている。

（文献２）
表題：NLANR/DAST : Iperf - The TCP/UDP Bandwidth Measurement Tool
Ｉｐｅｒｆのソースコードを辿れるＵＲＬ：http://dast.nlanr.net/Projects/Iperf/Ｉｐｅｒｆバージョン２．０．２のＵＲＬ：http://dast.nlanr.net/Projects/Iperf/Iperf2.0/Iperf-2.0.2.tar.gz (２００５年５月３日発行)
著作権保持者：イリノイ大学、プロジェクト名：Ｉｐｅｒｆ、
プロジェクトチーム名：The National Laboratory for Applied Network Research(NLANR), The Distributed Applications Support Team (DAST)、
媒体のタイプ：インターネット上の電子ファイル（ソースコード）
検索日：２００８年１月８日
プロジェクトチームの事が記載されているＵＲＬ：http://dast.nlanr.net/

１２．３） Ｐ２Ｐ（ピア・トゥ・ピア）技術を用いる例については、具体的には、例えば、ビットトレントを用いればよい。その詳細は、下記の文献３に記載されている。

（文献３）
表題：ＢｉｔＴｏｒｒｅｎｔ．ｏｒｇ
ビットトレントについて記載されているＵＲＬ：http://www.bittorrent.org/
著作権保持者：ＢｉｔＴｏｒｒｅｎｔ．ｏｒｇ
媒体のタイプ：インターネット上の電子ファイル
検索日：２００８年１月３１日

１２．４） ストリーミングの用途の制御プロトコルとして、ＲＳＴＰ（リアルタイム・ストリーミング・プロトコル）を用いる事が可能である。その場合、図２のリアルタイム配信提供システム１０２にてＲＳＴＰのサーバプログラムを動作させればよい。電子機器システム１３０のリアルタイム配信受信部１３４においては、ＲＳＴＰのクライアントプログラムを動作させればよい。その他の制御プロトコルとしては、ＳＩＰ（セッション・イニシエーション・プロトコル）のようなプロトコルを用いることができる。またコンテンツの転送はＲＴＰ(リアルタイムプロトコル)を用いてもよい。

１２．５） 番組情報の配信の際、情報が更新されたかどうかを電子機器システムに認識させるために、番組情報登録・提供システム１２０は、ＲＳＳ（リッチ・サイト・サマリ）を配信して電子機器システム１３０に知らせる事ができる。その詳細は、下記の文献４に記載されている。

（文献４）
参考技術情報４：ＲＳＳ
表題：RSS 2.0 at Harvard Law
ＲＳＳについて記載されているＵＲＬ：http://cyber.law.harvard.edu/rss/rss.html
著作権保持者：Dave Winer, founder of UserLand software, and fellow at Berkman Center
ライセンサー：the Berkman Center for Internet & Society at Harvard Law School
媒体のタイプ：インターネット上の電子ファイル
検索日：２００８年２月１２日

番組情報登録・提供システム１２０は、ｈｔｔｐなどのファイル転送プロトコルを用いて番組情報を電子機器システム１３０に配信できる。電子機器システム１３０は、周期的に番組情報登録・提供システムにアクセスし、情報が更新されていないかチェックする事ができる。

本発明は、番組コンテンツを配信するようなＩＰＴＶ（ＩＰテレビ）のシステム、電波や高周波電気信号の放送によるテレビ放送のシステム、ストリーミングによりコンテンツを配信するシステム、及び、それらの組み合わせのシステム、といった用途に適用できる。

本発明の一実施形態によるコンテンツ受信装置を用いたコンテンツ配信システムの一例を示すブロック図である。 本発明の第１実施例によるコンテンツ配信システムにおける電子機器システムの概略的構成を示すブロック図である。 本発明の第１実施例による電子機器システムの番組情報取得手順を示すフローチャートである。 本発明の第１実施例による電子機器システムのノンリアルタイム配信受信スケジューラにより実行されるスケジューリング動作の第１例を示すフローチャートである。 本発明の第１実施例による電子機器システムのコンテンツ出力制御手順を示すフローチャートである。 本発明の第１実施例による電子機器システムのコンテンツ再生判定手順の第１例を示すフローチャートである。 本発明の第１実施例による電子機器システムのノンリアルタイム配信受信スケジューラにより実行されるスケジューリング動作の第２例を示すフローチャートである。 本発明の第１実施例による電子機器システムのノンリアルタイム配信受信スケジューラにより実行されるスケジューリング動作の第３例を示すフローチャートである。 本発明の第１実施例による電子機器システムのコンテンツ再生判定手順の第２例を示すフローチャートである。 本発明の第２実施例によるコンテンツ配信システムにおける電子機器システムの概略的構成を示すブロック図である。 本発明の第４実施例によるコンテンツ配信システムにおける電子機器システムの概略的構成を示すブロック図である。 本実施例において参照する時計が正しい日付・時刻を表示しているかを確認する手順を示すフローチャートである。

符号の説明

１０ コンテンツ提供システム
１１ リアルタイム配信提供システム
１２ ノンリアルタイム配信提供システム
２０ 番組情報登録・提供システム
３０ ネットワーク
４０ コンテンツ受信装置
４１ 送受信部
４２ リアルタイムデータ受信部
４３ コンテンツ出力部４３
４４ ノンリアルタイムデータ受信部４４
４５ コンテンツ保存部４５
４６ 制御部
４７ 番組情報参照部
４８ ノンリアルタイムコンテンツ受信スケジューラ
４９ 日付時刻参照部

Claims (10)

1. 少なくとも１つの再生開始時刻が定められたコンテンツを受信するコンテンツ受信装置であって、
   コンテンツをノンリアルタイムで受けるノンリアルタイム受信手段と、
   少なくとも１つのコンテンツの再生開始時刻とそのコンテンツの配信方法とを含む番組情報を参照する番組情報参照手段と、
   前記配信方法がノンリアルタイム配信であるコンテンツの再生開始時刻と現在の時刻とに基づいて、前記ノンリアルタイム受信手段によるコンテンツ受信をスケジューリングするスケジューリング手段と、
   前記ノンリアルタイム受信手段により受信したコンテンツを保存するコンテンツ保存手段と、
   を有することを特徴とするコンテンツ受信装置。
2. 前記スケジューリング手段は、前記コンテンツの再生開始時刻前に当該コンテンツの受信を開始するスケジューリングを行うことを特徴とする請求項１記載のコンテンツ受信装置。
3. 前記コンテンツのノンリアルタイム配信所要時間を推定する所要時間推定手段を更に有し、
   前記スケジューリング手段は、前記推定所要時間と前記再生開始時刻および現在の時刻とに基づいて前記コンテンツ受信をスケジューリングすることを特徴とする請求項１または２に記載のコンテンツ受信装置。
4. 請求項１−３のいずれか１項に記載のコンテンツ受信装置を含む電子機器システムであって、
   前記番組情報から所望のコンテンツを選択するユーザ操作を可能にする情報入出力手段と、
   前記コンテンツ受信装置をネットワークに接続するためのデータ転送インタフェースと、
   再生するコンテンツを出力する出力手段と、
   をさらに備えたことを特徴とする電子機器システム。
5. 少なくとも１つの再生開始時刻が定められたコンテンツを、当該コンテンツの要求元のコンテンツ受信装置へ配信するコンテンツ配信システムであって、
   コンテンツの再生開始時刻および配信方法を含む番組情報を前記コンテンツ受信装置へ配信する番組情報配信手段と、
   リアルタイム配信すべきコンテンツを前記コンテンツ受信装置へ提供するためのリアルタイム配信提供手段と、
   ノンリアルタイム配信すべきコンテンツを前記コンテンツ受信装置へ提供するためのノンリアルタイム配信提供手段と
   を備えたことを特徴とするコンテンツ配信システム。
6. 前記番組情報は、前記ノンリアルタイム配信すべきコンテンツに対してはそのコンテンツのデータサイズを含むことを特徴とする請求項５記載のコンテンツ配信システム。
7. 少なくとも１つの再生開始時刻が定められたコンテンツを受信するコンテンツ受信装置におけるコンテンツ受信方法であって、
   番組情報参照手段が少なくとも１つのコンテンツの再生開始時刻とそのコンテンツの配信方法とを含む番組情報を参照し、
   スケジューリング手段が、ノンリアルタイム配信であるコンテンツの再生開始時刻と現在の時刻とに基づいてノンリアルタイム配信によるコンテンツ受信をスケジューリングし、
   ノンリアルタイム配信により受信したコンテンツをコンテンツ保存手段に保存する、
   ことを特徴とするコンテンツ受信方法。
8. 前記スケジューリング手段が、前記コンテンツの再生開始時刻前に当該コンテンツの受信を開始するようにスケジューリングすることを特徴とする請求項７記載のコンテンツ受信方法。
9. 前記スケジューリング手段が、前記コンテンツのノンリアルタイム配信所要時間を推定し、前記推定所要時間と前記再生開始時刻および現在の時刻とに基づいて前記コンテンツ受信をスケジューリングすることを特徴とする請求項７または８に記載のコンテンツ受信方法。
10. 少なくとも１つの再生開始時刻が定められたコンテンツを受信するコンテンツ受信装置としてコンピュータを機能させるプログラムであって、
    コンテンツをノンリアルタイムで受けるノンリアルタイム受信機能と、
    少なくとも１つのコンテンツの再生開始時刻とそのコンテンツの配信方法とを含む番組情報を参照する番組情報参照機能と、
    前記配信方法がノンリアルタイム配信であるコンテンツの再生開始時刻と現在の時刻とに基づいて、前記ノンリアルタイム受信機能によるコンテンツ受信をスケジューリングするスケジューリング機能と、
    前記ノンリアルタイム受信機能により受信したコンテンツを保存するコンテンツ保存機能と、
    をコンピュータで実現することを特徴とするプログラム。

Images