(57)【要約】【課題】ユーザが所望する番組を好きな時間に再生して視聴することができる代行録画システムを提供する。【解決手段】代行録画システムにおいては、複数の放送事業者７０１，７０４、受託放送業者７０３が放送するテレビジョン番組のうち、視聴者７０７〜７０９から録画要求されたテレビジョン番組を対応する放送事業者から取得し、視聴者７０７〜７０９の再生要求により、通信ネットワーク７０６を介して、取得された録画要求のテレビジョン番組を有料で視聴者７０７〜７０９に配信するとともに視聴者７０７〜７０９から代行録画サービスに関する料金を徴収する代行録画サービスがサービス業者７０５により運営される。そして、視聴者７０７〜７０９から支払われた料金は、著作権集中管理団体７１０により放送事業者に分配される。【選択図】      図１
2004194255.tif 000002
【特許請求の範囲】
【請求項１】
複数の放送事業者が放送するテレビジョン番組のうち、所望するテレビジョン番組の録画要求および再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビジョン番組を再生可能に受信する受信装置を有する視聴者と、
前記視聴者から録画要求されたテレビジョン番組を対応する放送事業者から取得し、前記視聴者の再生要求に応じて前記通信回線を介して前記取得された録画要求のテレビジョン番組を前記視聴者に配信するとともに前記代行録画サービスに関する料金を前記視聴者から徴収する代行録画サービスを運営するサービス業者と、
前記視聴者から支払われた料金を前記放送事業者に分配する管理団体と
を含むことを特徴とする代理録画システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、視聴者から録画要求されたテレビジョン番組を対応する放送事業者から取得して視聴者に配信する代行録画システムに関する。
【０００２】
【従来の技術】
近年、デジタル技術の進展に伴い、テレビジョン放送方式が、これまでのアナログ方式（ＮＴＳＣ／ＰＡＬ／ＳＥＣＡＭ）方式からデジタル方式に移行しつつある。例えば米国、欧州では、既に地上波デジタル放送が開始されている。また、日本においては、２０００年１２月からＢＳデジタル放送が開始され、２００３年から地上波デジタル放送が開始される予定である。
【０００３】
このテレビジョン放送のデジタル化に伴い、受信側の録画方式も、これまでのアナログビデオテープレコーダから、デジタルビデオテープレコーダなどに移行しつつある。また、これまでコンピュータ用の蓄積手段として用いられてきたハードディスクに、テレビジョン放送を録画する方式、装置などが提案され、実用化されている。さらに、この蓄積手段を極端に大容量化して、テレビジョン受信機に放送中の全ての番組を取り込んでおき、既に放送された番組であれば、好きな番組を好きなタイミングで観ることが可能なホームサーバ、あるいはホームステーションが提案されている。例えば特開平１１−２３４５９９号公報には、全てのテレビジョン放送番組を記憶する１次記憶手段と、２次記憶手段とを有し、１次記憶手段に記憶されている番組のうち、所望の番組のみを２次記憶手段に記憶する放送映像録画装置が開示されている。
【０００４】
また、インターネットなどの通信ネットワークインフラの整備に伴い、テレビジョン番組をインターネット経由で送受信することが可能である。これは、従来不可能であったインターネット経由のビデオならびにオーディオのリアルタイム通信を、一般家庭のパーソナルコンピュータからインターネットへダイヤルアップ接続する２８．８Kbpsの通信速度でも可能にする符号化および通信技術の登場によるものである。この技術では、通信速度（以下ビットレートとする）に応じて、ビデオおよびオーディオの圧縮率を制御して、ビデオおよびオーディオを所望のビットレート以下で送信可能なサイズに圧縮符号化してサーバに格納する。このサーバへ受信側のコンピュータにインストールされているクライアントソフトウエアが送信リクエストを出すと、コンピュータは、サーバから送られてきた動画、オーディオデータをバッファリングしながら直ちに復号して表示する。この技術は、全てのデータをダウンロードしてから再生する方式と区別され、ストリーミングと呼ばれる。ストリーミング技術については、米国特許５，７９３，９８０号に詳しく開示されている。このストリーミング技術としては、米国Microsoft社のWindows（登録商標） Media Technology（Windows（登録商標） MediaPlayer, Windows （登録商標）Media Encoder, Windows （登録商標）Media Server）や、米国Real Networks社のReal Player, Real
Producer, Real Serverなどがあり、パーソナルコンピュータ上で動作するソフトウエアとして提供されている。また、ＡＤＳＬ（Asynchronous Digital Subscriber Line）などのブロードバンドインターネット常時接続の環境が低価格で普及しつつあるため、インターネット経由での番組視聴に掛かる金銭的な負担は軽減されつつある。
【０００５】
【発明が解決しようとしている課題】
しかしながら、上述したホームサーバ、ホームステーションを用いた録画技術では、同じ番組を全国で複数の視聴者がそれぞれの記憶手段に大量に録画、記憶するという無駄が行われており、しかも大容量の記憶手段が用いられるために、コストが増すことになる。
【０００６】
また、各視聴者が各自のテレビジョン受像機に内蔵されたハードディスクやビデオテープに録画する方法では、視聴者の記憶手段がハードディスクであれば、すぐに容量が不足し、ビデオテープであれば、テープメディアが大量になるという問題が発生する。
【０００７】
また、上述したようなストリーミング技術を利用して、インターネット経由で放送するサービスは、コンテンツの数が限られており、視聴者のニーズに十分に応えることはできない。
【０００８】
本発明の目的は、ユーザが所望する番組を好きな時間に再生して視聴することができる代行録画システムを提供することにある。
【０００９】
【課題を解決するための手段】
本発明は、上記目的を達成するため、複数の放送事業者が放送するテレビジョン番組のうち、所望するテレビジョン番組の録画要求および再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビジョン番組を再生可能に受信する受信装置を有する視聴者と、前記視聴者から録画要求されたテレビジョン番組を対応する放送事業者から取得し、前記視聴者の再生要求に応じて前記通信回線を介して前記取得された録画要求のテレビジョン番組を前記視聴者に配信するとともに前記代行録画サービスに関する料金を前記視聴者から徴収する代行録画サービスを運営するサービス業者と、前記視聴者から支払われた料金を前記放送事業者に分配する管理団体とを含むことを特徴とする。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照しながら説明する。
【００１１】
（第１実施形態）
図１は本発明の第１実施形態に係る代行録画システムが適用される放送システムを示すブロック図である。
【００１２】
本実施形態の代行録画システムは、視聴者が録画したいテレビジョン番組を、サービス事業者により有料で代行録画して保管し、視聴者が所望するタイミングで、サービス業者により代行録画された番組を視聴者にストリーミング配信するサービスを提供するシステムである。また、サービス事業者は視聴者から料金を徴収する代わりに、ストリーミング配信するデータに広告を付加することもできる。
【００１３】
本実施形態の代行録画システムが適用される放送システムは、図１に示すように、複数の放送事業者７０１〜７０４、サービス事業者７０５、通信ネットワーク７０６、複数の視聴者７０７〜７０９、著作権集中管理団体７１０、料金徴収代行業者７１１とから構成される。ここで、複数の放送事業者７０１〜７０４、著作権集中管理団体７１０、サービス事業者７０５は、それぞれ独立した事業者である。
【００１４】
次に、各事業者および視聴者間でのサービス、金銭の流れについて説明する。
【００１５】
テレビジョン放送を行う放送事業者７０１〜７０４のうち、番組コンテンツの製作、編成を行い、番組の著作権、著作隣接権を所有する放送事業者７０１，７０２，７０４は、放送した番組コンテンツをサービス事業者７０５が録画、保管することを許諾する代わりに、著作権集中管理団体７１０を通じて、サービス事業者７０５から２次使用料または私的録画保証金の分配を受ける。ただし、受託放送事業者７０３は放送する番組の著作権、著作隣接権を有していない事業者である。この放送事業者の事業形態については、後に説明する。
【００１６】
サービス事業者７０５は、視聴者７０７〜７０９からサービス料を徴収し、視聴者７０７〜７０９から録画依頼された番組が初めて依頼された番組の場合、この番組を受信、保管し、視聴者７０７〜７０９の所望のタイミングでストリーミング配信する。ただし、番組コンテンツの入手方法としては、放送を受信して番組コンテンツを入手する方法でもよいし、放送事業者７０１，７０２，７０４から直接テープメディアなどから番組コンテンツを入手する方法でもよい。また、サービス料金の課金方法としては、例えば月極めの固定料金とする方法、代行録画した回数などに応じた従量制とする方法、あるいはそれらを組み合わせた方法などがある。
【００１７】
視聴者７０７〜７０９は、サービス事業者７０５から録画依頼した番組の配信を受け、サービス事業者７０５にサービス料金を支払う。ただし、サービス料金の徴収方式としては、例えば視聴者７０７のように直接サービス事業者７０５に払う方式、視聴者７０８のように通信ネットワークを介して支払う方式、視聴者７０９のように料金徴収代行業者７１１を介して支払う方式などがある。
【００１８】
著作権集中管理団体７１０は、権利の集中化を通じて多数の権利者の許諾窓口となり権利処理の効率化に資することによって、著作物等の利用の円滑化を図ることを目的とした、文化庁長官の業務許可を受けた非営利団体であり、サービス事業者７０５から支払われた、番組コンテンツの２次使用料または私的録画保証金を放送事業者（７０１，７０２，７０４）に分配する。
【００１９】
次に、代行録画システムの構成について図２を参照しながら説明する。図２は本発明の第１実施形態に係る代行録画システムの構成を示すブロック図である。
【００２０】
代行録画システムは、図２に示すように、放送事業者１１，１４（図１の７０１，７０４に対応）、委託放送事業者１２（図１の７０２に対応）、受託放送事業者１３（図１の７０３）、データセンター１５、通信ネットワーク１６、および受信機１７〜１９から構成される。
【００２１】
まず、放送事業者１１〜１４について説明する。放送事業者には、地上系放送事業者、衛星系放送事業者、ケーブルテレビ事業者がある。上記衛星系放送事業者のうち、ＣＳ（通信衛星）デジタル、ＢＳ（放送衛星）デジタル放送における放送事業者は、番組の製作、当該チャンネルの編成を行う委託放送事業者と、衛星を管理し、各委託放送事業者の番組を一括して通信衛星や放送衛星へ送信する無線局の免許を受けた受託放送事業者に分類される。また上記地上系放送事業者、ケーブルテレビ事業者およびアナログ方式のＢＳ放送に対しては、このような受委託制度は無く、放送番組の編集主体と放送局の管理運営主体が兼ねられている。
【００２２】
次に、データセンター１５について説明する。
【００２３】
データセンター１５は、上記放送事業者から放送される番組コンテンツの２次使用料を、著作権集中管理団体７１０に包括許諾方式、または従量方式で支払う。著作権集中管理団体７１０は、徴収した該２次使用料を上記放送事業者や各権利団体等の著作権者に分配する。ただし、データセンター１５における代行録画サービスが、各視聴者が個人で録画するコンテンツをただ保管していると考えれば、私的録画保証金管理協会（ＳＡＲＶＨ：サーラ）に所定の私的録画保証金を支払うことになる。
【００２４】
このデータセンター１５の構成および動作について図３ないし図５を参照しながら説明する。図３はデータセンター１５の構成を示すブロック図、図４は図３のデータセンター１５の動作手順を示すフローチャート、図５はＨＴＭＬファイルによるユーザＩ／Ｆとして表示される、代理録画、保管されている番組一覧画面を示す図である。
【００２５】
データセンター１５は、図３に示すように、受信手段４１、エンコーダ手段４２、およびサーバ手段４３を有する。受信手段４１は、チューナ手段４１１、フロントエンド手段４１２、ＣＡ手段４１３、デマルチプレクサ手段４１４、ビデオデコーダ手段４１５、オーディオデコーダ手段４１６を有する。エンコーダ手段４２は、ビデオエンコーダ手段４２１およびオーディオエンコーダ手段４２２を有する。サーバ手段４３はディスクストレージ手段４３１、ＣＰＵ４３２およびネットワークＩ／Ｆ手段４３３を有する。
【００２６】
受信手段４１は、テレビジョン放送を受信し、復号化する手段であり、後述する視聴者の受信機１７〜１９より録画リクエストされた番組が、初めての番組すなわち未保存の番組であった場合（ステップＳ１１０１）、後述するサーバ手段４１３の制御に従い録画リクエストされた番組を受信する（ステップＳ１１０２）。
【００２７】
アンテナにより受信された信号はチューナ手段４１１により選局、直交検波され、フロントエンド手段４１２に入力される。フロントエンド手段４１２は、復調部、エラー訂正部（図示せず）により構成され、アンテナから出力されたＲＦ信号を復調例えば８ＰＳＫ復調した後、エラー検出し、必要に応じて補正し、ＣＡ手段４１３に出力する。ＣＡ手段４１３は、詳しくはＩＣカードのＣＡＭ（Conditional Access Module）、およびカードリーダ、デスクランブラにより構成される。ＣＡＭ内には暗号を解読するのに必要なキーが解読プログラムとともに格納されるとともに、課金情報等も格納される。放送局側で暗号化（スクランブル）された信号が送られてきた場合、このＣＡＭ内のマスターキーを用いて放送波にスクランブルされている暗号化されたワークキーを解き、このワークキーを用いてスクランブルキーの暗号を解き、このスクランブルキーを用いてＴＳ（Transport Stream）ペイロードのデスクランブルを行う。なお、暗号化されているか否かの判定はＴＳパケットヘッダのスクランブル制御フラグ、アダプテーションフィールドコントロールを参照することにより行う。ＣＡ手段４１３でデスクランブルされた信号は、デマルチプレクサ手段４１４でビデオ信号と、オーディオ信号とに分離され、それぞれの信号はビデオデコーダ手段４１５、オーディデコーダ手段４１６に送られる。ビデオデコーダ手段４１５およびオーディオデコーダ手段４１６では、それぞれＭＰＥＧ（Moving Pictures Experts Group）−２のビデオ，オーディオの復号処理がなされ、復号された信号はそれぞれエンコーダ手段４２に送られる。ここで、ＭＰＥＧ−２は、ＩＳＯ／ＩＥＣ１３８１８として規格化されたＩＳ（International Standard）である。
【００２８】
ただし、データセンター１５が、各放送事業者１１，１２，１４から直接テープメディアなどで番組コンテンツを取得する場合には、後述の第２実施形態で説明するように、受信手段４１の代わりに、番組コンテンツストレージ手段１０１１より所望のコンテンツを読み出す。
【００２９】
エンコーダ手段４２において、ビデオエンコーダ手段４２１、オーディオエンコーダ手段４２２は、それぞれ入力されたビデオ，オーディオ信号をストリーミング配信に好適な信号に圧縮符号化およびフォーマット変換して、サーバ手段４３に送る（ステップＳ１１０３）。この圧縮符号化およびフォーマット変換処理は、図３に示すように、専用のハードウエアで行ってもよいし、後述のサーバ手段４３のＣＰＵ４３２上で動作するソフトウエアで行ってもよい。また、ビデオの圧縮符号化処理としてはＭＰＥＧ−２よりもさらなる高圧縮率を実現可能なＭＰＥＧ−４を用いることが好適であるが、高圧縮を実現可能な方式であれば、いずれの方式を用いてもよい。なお、ＭＰＥＧ−４は１９９９年１月にＩＳＯ／ＩＥＣ１４４９６としてＩＳとなった圧縮符号化に関する規格であり、 HYPERLINK"http://drogo.cselt.it/mpeg/standards/mpeg-4/mpeg-4.htm" http://drogo.cselt.it/mpeg/standards/mpeg-4/mpeg-4.htmより詳細情報を入手可能である。
【００３０】
また、上記フォーマット変換は、例えばマイクロソフト社のストリーミングクライアント（再生ソフトウエア）であるWindows（登録商標） Media Player用であればＡＳＦ（Advanced Streaming Format）フォーマット、リアルネットワークス社のストリーミングクライアントであるReal Player用であればＲＭ（Real Movie）フォーマットなどに変換される。
【００３１】
サーバ手段４３において、ＣＰＵ４３２は、後述する受信機１７〜１９との通信により、初めて指定された番組の受信を、上記受信手段４１を制御して行い、上記エンコーダ手段４２において圧縮符号化およびフォーマット変換されたビデオ，オーディオ信号を、ディスクストレージ手段４３１に格納する（ステップＳ１１０４）。さらに、上記ビデオ，オーディオデータとともに、ストリーミング配信する際のユーザＩ／Ｆ（インタフェース）を提供するために必要なＨＴＭＬ（Hyper Text Mark up Language）ファイルなどが、ＣＰＵ４３２よりディスクストレージ手段４３１に格納される（ステップＳ１１０５）。このＨＴＭＬファイルによるユーザＩ／Ｆとしては、図５に示すような、これまで代理録画、保管されている番組一覧画面などを表示して、受信機１７〜１９の操作者に選択させるものが望ましい。また、ストリーミング送信されるコンテンツとして、ビデオ、オーディオのみならず、ピクチャ（静止画像）、テキストなどを含める場合には、これらメタデータは上記ビデオ，オーディオデータとともに格納される。これらメタデータコンテンツの同期、表示位置、表示開始時間などを制御する技術としてＳＭＩＬ（Synchronized Multimedia Integrated Language）がある。このＳＭＩＬを用いることにより、ビデオ、オーディオ、テキスト、ピクチャなどを用いたプレゼンテーションとしてのストリーミング配信を行うことができる。上記代行録画されている番組一覧をＨＴＭＬでなく、上記ＳＭＩＬで記述して、ビデオ、オーディオへのハイパーリンクを貼るようにしてもよい。ＳＭＩＬ1.0は、Ｗ３Ｃ（World Wide Web Consortium）より１９９８年６月に勧告されているものである。
【００３２】
そして、サーバ手段４３は、受信機１７〜１９へ再生可能な状態になったことを示す録画受付完了データを送信する（ステップＳ１１０６）。ここで、視聴者７０７〜７０９とデータセンター１５との代理録画サービス契約が、従量制であった場合には（ステップＳ１１０７）、ＣＰＵ４３２の料金データを更新する（ステップＳ１１０８）。
【００３３】
さらに、サーバ手段４３は受信機１７〜１９からのストリーミング再生リクエストを受け（ステップＳ１１０９）、所望のコンテンツをストリーミング配信する（ステップＳ１１１０）。ただし、ストリーミング配信する際のＨＴＴＰ（Hyper Text Transfer Protocol）サーバーソフトウエアおよびストリーミングサーバーソフトウエアはＣＰＵ４３２上で動作する。
【００３４】
また、通常インターネットなどの通信ネットワークのトランスポート層における通信プロトコルとしては、ＴＣＰ（Transmission Control Protocol）が主に用いられるが、ストリーミングの場合、ＵＤＰ（User Datagram Protocol）が用いられる。ＵＤＰはＴＣＰのように、サーバ、クライアント間にコネクションを確立せず、エラー時の再送ができないなど、信頼性の面で劣るものの、高速な通信が可能であるため、多少のエラーが問題にならないストリーミングのようなアプリケーションには好適なプロトコルである。アプリケーション層のプロトコルとしてはＲＴＳＰ（Real Time Streaming Protocol）が主に用いられるが、企業内のＬＡＮ環境からファイアーウオール経由で利用する場合には、ＨＴＴＰが用いられる場合もある。これはファイアーウオールの設定によっては、ＨＴＴＰしか通さない場合があるためである。
【００３５】
ただし、既に他の視聴者の受信機１７〜１９により録画リクエストされ、ストリーミング配信可能なデータとして保存されている番組の録画リクエストに対しては、上述した受信、変換、格納処理（ステップＳ１１０２〜ステップＳ１１０５）は行われない（重複録画は行われない）が、録画受付完了データの送信（ステップＳ１１０６）、および従量制契約の場合における料金データの更新（ステップＳ１１０８）は行われるものとする。
【００３６】
以上データセンター１５の代行録画システムの構成例について説明したが、上述した説明は、機能的に明確にするため、受信手段４１、エンコーダ手段４２、サーバ手段４３に分けて説明したが、実際の構成は例えば、エンコーダ手段４２とサーバ手段４３が１つのコンピュータ上で動作するのもであってもよいし、または全ての手段が１つのコンピュータ上で動作するものであってもよく、この代行録画システムの構成例が、本発明のデータセンター１５の構成を制限しないことはいうまでもない。
【００３７】
通信ネットワーク１６は、例えばインターネットであり、上述したように、ファイルの送受信のようなエラーを許さない場合には、ＴＣＰ／ＩＰプロトコルをそれぞれトランスポート層、ネットワーク層のプロトコルとして用いるネットワークである。ネットワークプロトコルは、コンピュータ同士が通信するための標準的な方法を提供し、プロトコルはネットワークを介した送受信のためにデータをどのようにフォーマットすべきかを示す。このプロトコルにより、ネットワーク上で異機種のコンピュータがシームレスに通信することができる。アプリケーション層の標準インターネットプロトコルとしては、ブラウザソフトウエア（例えばマイクロソフト社のInternet Explorerなど）によりＨＴＭＬファイルを送受信するためのＨＴＴＰ、電子メールを送受信するためのＳＭＴＰ（Simple Mail Transfer Protocol）、汎用的なファイル送信のためのＦＴＰ（File Transfer
Protocol）などがある。
【００３８】
例えば、ＨＴＴＰに関しては、T. Berners Lee, R. FieldingおよびH. Frystykの論文「Hypertext Transfer Protocal-HTTP/1.0」、 HYPERLINK http://www.ics.uci.edu/pub/ietf/http/draftietf-http-v10-spec-03.html http://www.ics.uci.edu/pub/ietf/http/draftietf-http-v10-spec-03.html、1995年９月４日に詳しく解説されている。ＳＭＴＰに関しては、J. B Postelの論文「Simple MailTransfer Protocal」、RFC821、Information Science Institute、USC、1982年８月、 HYPERLINK http://ds.internic.net/std/std10.txt http://ds.internic.net/std/std10.txtに詳しく解説されている。ＦＴＰに関しては、J. B PostelとJ. K. Reynoldsの論文「File Transfer Protocol (FTP) 」、RFC959、Information Sciences Institute、USC、1985年10月、 HYPERLINK "http://www.cis.ohio-state.edu/htbin/rfc/rfc0959.html" http://www.cis.ohio-state.edu/htbin/rfc/rfc0959.htmlなどに詳細に説明されている。
【００３９】
次に、受信機１７〜１９について図６を参照しながら説明する。図６は受信機１７〜１９の構成を示すブロック図である。
【００４０】
受信機１７〜１９は、図６に示すように、チューナ手段３０１、フロントエンド手段３０２、ＣＡ（Conditional Access）手段３０３、デマルチプレクサ手段３０４、ビデオデコーダ手段３０５、表示手段３０６、オーディオデコーダ手段３０７、ＤＡＣ手段３０８、スピーカ３０９、リモコン受光手段３１０、モデム手段３１１、ＣＰＵ３１２、バッファ手段３１３からなる。
【００４１】
受信機１７〜１９は、代行録画された番組を通信ネットワーク１０６経由で受信して再生する機能の他に、通常のテレビジョン番組放送を受信する機能、操作者からのリモコン操作を受けて処理する機能を有する。なお、上記通常のテレビジョン番組放送を受信する機能は必ずも搭載されるものではない。
【００４２】
ここで、テレビジョン放送を受信するための、チューナ手段３０１、フロントエンド手段３０２、ＣＡ手段３０３、デマルチプレクサ手段３０４、ビデオデコーダ手段３０５、オーディオデコード手段３０７は、上述したデータセンター１５の受信手段４１と同様であるため、その説明を省略する。ただし、ビデオデコード手段３０５でデコードされた信号は表示手段３０６に表示され、オーディオデコード手段３０７でデコードされた信号はＤＡＣ手段３０８でＤ／Ａ変換され、アンプ手段（図示せず）により増幅後、スピーカ３０９で再生される。
【００４３】
次に、受信機１７〜１９によるデータセンター１５に対する代行録画リクエスト処理について図７を参照しながら説明する。図７は受信機１７〜１９によるデータセンター１５に対する代行録画リクエスト処理の手順を示すフローチャートである。
【００４４】
まず受信機１７〜１９の操作者が例えばリモコンなどを用いて録画リクエストをすると(ステップＳ６０１)、これをＣＰＵ３１２の制御によりリモコン受光手段３１０で受け付け、ＣＰＵ３１２はデータセンター１５のサーバ手段４３に配信リクエストを出す（ステップＳ６０２）。電話回線もしくは他の通信インフラ経由で、録画予約設定フォーム（ＨＴＭＬまたはＳＭＩＬファイル）を受信すると（ステップＳ６０３）、ＣＰＵ３１２上で動作するＨＴＭＬブラウザソフトウエアまたはストリーミングクライアントソフトウエアを用いて表示する（ステップＳ６０４）。ここで、上記データセンター１５のサーバ手段４３の問題または通信回線の問題などにより、上記録画予約設定フォームデータの受信に失敗した場合には、エラー表示画面を作成して表示する（ステップＳ６０５）。そして、操作者がリモコンなどを用いて録画したい番組情報（バーコード番号など）の入力をすると（ステップＳ６０６）、データセンター１５のサーバ手段４３に設定を送信する（ステップＳ６０７）。データセンター１５において録画予約が正常になされると、受付完了を知らせるデータが受信され（ステップＳ６０８）、このデータが表示手段３０６およびスピーカ３０９に出力される（ステップＳ６１０）。これに対し、録画予約に失敗して、受け付け完了を知らせるデータが受信されない場合、エラー表示画面を作成して表示する（ステップＳ６０９）。
【００４５】
次に、受信機１７〜１９によるデータセンター１５において代理録画された番組の受信表示処理について図８を参照しながら説明する。図８は受信機１７〜１９によるデータセンター１５において代理録画された番組の受信表示処理の手順を示すフローチャートである。
【００４６】
まず、受信機１７〜１９の操作者が例えばリモコンなどを用いて再生リクエスト、または一覧表示リクエストをすると(ステップＳ２０１)、これをＣＰＵ３１２の制御によりリモコン受光手段３１０で受け付け、ＣＰＵ３１２はデータセンター１５のサーバ手段４３に配信リクエストを出す（ステップＳ２０２）。電話回線または他の通信インフラ経由で、一覧表示用データ（ＨＴＭＬまたはＳＭＩＬファイル）を受信すると（ステップＳ２０３）、ＣＰＵ３１２上で動作するＨＴＭＬブラウザソフトウエアまたはストリーミングクライアントソフトウエアを用いて表示する（ステップＳ２０４）。ここで、上記データセンター１５のサーバ手段４３の問題、もしくは通信回線の問題などにより、上記一覧表示用データの受信に失敗した場合には、エラー表示画面を作成して表示する（ステップＳ２０５）。そして、操作者がリモコンなどを用いて再生したい番組を選択すると（ステップＳ２０６）、データセンター１５のサーバ手段４３に番組の送信リクエストを出す（ステップＳ２０７）。
【００４７】
ストリーミングデータが、モデム手段３１１で復調された後、バッファ手段３１３に入力された場合（ステップＳ２０８）、ビデオ、オーディオ、ピクチャに関しては復号処理される（ステップＳ２０９）。そして、これらビデオ、オーディオ、ピクチャ、テキストなどの全メタデータは一緒に送られてきたＳＭＩＬデータに基づいてＣＰＵ３１２によりレイアウト、再生され（ステップＳ２１０）、表示手段３０６およびスピーカ３０９に出力される（ステップＳ２１２）。ただし、ストリーミング配信されてくるデータがＳＭＩＬデータなどを含まない、ビデオ、オーディオのみの場合は、上記ピクチャのデコード、ＳＭＩＬデータに基づくレイアウト処理は必要ない。
【００４８】
また、上記データセンター１５のサーバ手段４３の問題または通信回線の問題などによりストリーミング配信がされない場合には、エラー表示用の画面構成がなされ（ステップＳ２１１）、表示手段３０６およびスピーカ３０９に出力される（ステップＳ２１２）。そして、操作者がリモコンなどにより再生を停止、または通常のテレビジョン番組の視聴への切り替えを行うまで再生を続ける（ステップＳ２１３）。
【００４９】
なお、上記復号処理はＣＰＵ３１２上で動作するソフトウエアによりなされることが好適であるが、ハードウエアでなされてもよい。ここにおけるＣＰＵ３１２上で動作する復号処理が可能なストリーミングクライアントとしては、上述したマイクロソフト社のWindows（登録商標） Media Playerや、リアルネットワークス社のReal
Playerなどがある。
【００５０】
このように、本実施形態によれば、ユーザが所望する番組を好きな時間に再生して視聴することができる。
【００５１】
（第２実施形態）
次に、本発明の第２実施形態について図面を参照しながら説明する。
【００５２】
まず、代行録画システムが適用される放送システムについて説明する。図９は本発明の第２実施形態に係る代行録画システムが適用される放送システムを示すブロック図である。
【００５３】
放送システムは、図９に示すように、複数の放送事業者８０１〜８０３、通信ネットワーク８０４、複数の視聴者８０５〜８０７、料金徴収代行業者８０８、広告主８０９〜８１１とから構成される。
【００５４】
本実施形態では、複数の放送事業者８０１〜８０３が、上述した第１実施形態のサービス事業者７０５を兼ねており、視聴者８０５〜８０７は代行録画サービスを提供する放送事業者８０１〜８０３と直接契約する形態である。
【００５５】
ここで、各事業者８０１〜８０３および視聴者８０５〜８０７間でのサービス、および金銭の流れについて説明する。
【００５６】
テレビジョン放送を行う放送事業者のうち、番組コンテンツの製作、編成を行い、番組の著作権、著作隣接権を所有する放送事業者８０１〜８０３は、自ら放送した番組または放送予定の番組のうち、視聴者８０５〜８０７から録画依頼された番組が初めて依頼された番組の場合、この番組をストリーミングコンテンツとしてサーバに保管し、視聴者８０５〜８０７からの配信リクエストに応じてオンデマンドでストリーミング配信する換わりに、サービス料金を視聴者８０５〜８０７から徴収する。ただし、サービス料金の課金方法としては、第１実施形態同様に、例えば月極めの固定料金とする方法、代理録画した回数などに応じた従量制とする方法、またはそれらを組み合わせた方法などがある。
【００５７】
また、視聴者８０５〜８０７からサービス料金を徴収する換わりに、ストリーミング配信するデータに広告主８０９〜８１１の広告を付加することにより、本発明にかかる代理録画サービスの運営を行うこともできる。この広告の付加方法としては、番組データの前に動画広告用のデータを付加し、これらをあわせてストリーミングコンテンツとして配信する方法がある。視聴者８０５〜８０７は、録画番組を再生する前に必ずこの動画広告を観なければならないようにする。
【００５８】
視聴者８０５〜８０７は、放送事業者８０１〜８０３と個別に契約し、録画依頼しておいた番組の配信を受ける換わりにサービス料金を支払うか、もしくは上述したように録画番組を再生する前に動画広告を視聴する。ただし、サービス料金の徴収は、第１実施形態同様、例えば視聴者８０５のように直接放送事業者８０１に払う方式、視聴者８０６のように通信ネットワーク８０４を介して支払う方式、視聴者８０７のように料金徴収代行業者８０８を介して支払う方式などがある。
【００５９】
次に、本実施形態の代行録画システムについて図１０を参照しながら説明する。図１０は本発明の第２実施形態に係る代行録画システムの構成を示すブロック図である。
【００６０】
代行録画システムは、図１０に示すように、放送事業者９１，９４、委託放送事業者９２、受託放送事業者９３、通信ネットワーク９５、および受信機９６〜９８から構成される。ここで、通信ネットワーク９５、受信機９６〜９８に関しては、第１実施形態と同様であるため、ここでの説明を省略する。
【００６１】
本実施形態における放送事業者９１，９２，９４について図１１および図１２を参照しながら説明する。図１１は放送事業者９１，９２，９４の構成を示すブロック図、図１２は放送事業者９１，９２，９４の動作の手順を示すフローチャートである。
【００６２】
本実施形態では、上述したように、番組コンテンツの著作権、著作隣接権を有する放送事業者９１，９２，９４が、第１実施形態におけるデータセンター１５を兼ねる形態である。従って、サービス提供者である放送事業者９１，９２，９４が、視聴者８０５〜８０７が録画依頼した番組のコンテンツを予め有するため、第１実施形態におけるデータセンター１５のように番組放送を受信する必要は無い。
【００６３】
放送事業者９１，９２，９４は、図１１に示すように、コンテンツストレージ手段１０１、エンコーダー手段１０２、サーバ手段１０３から構成される。コンテンツストレージ手段１０１は、番組コンテンツストレージ手段１０１１、再生手段１０１２を含み、エンコーダ手段１０２は、ビデオエンコーダ手段１０２１およびオーディオエンコーダ手段１０２２を含む。サーバ手段１０３は、ディスクストレージ手段１０３１、ＣＰＵ１０３２、およびネットワークＩ／Ｆ手段１０３３を含む。
【００６４】
まず、コンテンツストレージ手段１０１について説明する。
【００６５】
視聴者の受信機９６〜９８より録画リクエストされた番組が、初めての番組すなわち未保存の番組であった場合（図１２のステップＳ１２０１）、エンコーダ手段１０２が再生データを受けてリアルタイムエンコードするタイプの場合、視聴者の受信機９６〜９８より指定された番組を、後述するサーバ手段１０３の制御により再生する。エンコーダ手段１０２がデータファイルを受けてエンコードするタイプの場合、受信機９６〜９８より送信、指定された番組データファイルを番組コンテンツストレージ手段１０１１からエンコーダ手段１０２に転送する（ステップＳ１２０２）。
【００６６】
エンコーダ手段１０２において、ビデオエンコーダ手段１０２１、オーディオエンコーダ手段１０２２は、再生された信号をリアルタイムエンコードするタイプの場合、それぞれ入力されたビデオ，オーディオ信号をストリーミング配信に好適な信号に圧縮符号化およびフォーマット変換して、サーバ手段１０３に送る（ステップＳ１２０３）。また、ビデオエンコーダ手段１０２１、オーディオエンコーダ手段１０２２は、入力がデータファイルである場合でも、ストリーミング配信に好適なデータに圧縮符号化およびフォーマット変換して、サーバ手段１０３に送る（ステップＳ１２０３）。圧縮符号化およびフォーマット変換処理は、第１実施形態と同様に、図１１に示すような専用のハードウエアで行ってもよいし、サーバ手段１０３のＣＰＵ１０３２上で動作するソフトウエアで行ってもよい。また、ビデオの圧縮符号化処理としては、第１実施形態と同様に、ＭＰＥＧ−２よりもさらに高圧縮可能なＭＰＥＧ−４を用いることが好適であるが、これに限定されることはなく、他の高圧縮方式を用いることができることはいうまでもない。
【００６７】
また、上記フォーマット変換は第１実施形態と同様に、例えばマイクロソフト社のストリーミングクライアント（再生ソフトウエア）であるWindows（登録商標） Media Player用であればＡＳＦ（Advanced Streaming Format）フォーマット、リアルネットワークス社のストリーミングクライアントであるReal Player用であればＲＭ（Real Movie）フォーマットなどに変換される。
【００６８】
次に、サーバ手段１０３について説明する。
【００６９】
サーバ手段１０３のＣＰＵ１０３２は、受信機９６〜９８との通信により、初めて指定された番組を、上記コンテンツストレージ手段１０１を制御して再生または送信させ、上記エンコーダ手段１０２において圧縮符号化およびフォーマット変換されたビデオ，オーディオ信号を、ディスクストレージ手段１０３１に格納せしめる（ステップＳ１２０４）。さらに、上記ビデオ，オーディオデータとともに、ストリーミング配信する際のユーザＩ／Ｆを提供するために必要なＨＴＭＬ（Hyper Text Mark up Language）ファイルなどが、ＣＰＵ１０３２よりディスクストレージ手段１０３１に格納される（ステップＳ１２０５）。
【００７０】
そして、サーバ手段１０３は、受信機９６〜９８へ再生可能な状態になったことを示す録画受付完了データを送信する（ステップＳ１２０６）。ここで、視聴者８０５〜８０７と放送事業者８０１〜８０３との代理録画サービス契約が、従量制であった場合には（ステップＳ１２０７）、ＣＰＵ１０３２の料金データを更新する（ステップＳ１２０８）。
【００７１】
サーバ手段１０３は、受信機９６〜９８からのストリーミング再生リクエストを受け（ステップＳ１２０９）、対応するコンテンツをストリーミング配信する（ステップＳ１２１０）。ただし、ストリーミング配信する際のＨＴＴＰ（Hyper Text Transfer Protocol）サーバソフトウエアおよびストリーミングサーバソフトウエアは、ＣＰＵ１０３２上で動作する。
【００７２】
ただし、本実施形態では、既に他の視聴者の受信機９６〜９８により録画リクエストされ、ストリーミング配信可能なデータとして保存されている番組の録画リクエストに対しては、上述した再生、変換、格納処理（ステップＳ１２０２〜ステップＳ１２０５）は行われない（重複録画は行われない）が、録画受付完了データの送信（ステップＳ１２０６）、および従量制契約の場合における料金データの更新（ステップＳ１２０８）は行われるものとする。
【００７３】
本実施形態では、機能的に明確にするため、コンテンツストレージ手段１０１、エンコーダ手段１０２、サーバ手段１０３に分けて説明したが、実際の構成は例えば、エンコーダ手段１０２とサーバ手段１０３が１つのコンピュータ上で動作するのもであってもよいし、または全ての手段が１つのコンピュータ上で動作するものであってもよく、上述した代行録画システムの構成（放送事業者９１，９２，９４）が本発明の代行録画システムの構成を限定するものではないことはいうまでもない。
【００７４】
（第３実施形態）
次に、本発明の第３実施形態について図１３ないし図１６を参照しながら説明する。図１３は本発明の第３実施形態に係る代行録画システムが適用される放送システムを示すブロック図、図１４は本発明の第３実施形態に係る代行録画システムの構成を示すブロック図、図１５は図１４の放送事業者１９０１，１９０２，１９０４の構成を示すブロック図、図１６は放送事業者１９０１，１９０２，１９０４の動作の手順を示すフローチャートである。
【００７５】
代行録画システムが適用される放送システムは、図１３に示すように、複数の放送事業者１３０１〜１３０３、通信ネットワーク１３０４、複数の視聴者１３０５〜１３０７、料金徴収代行業者１３０８、および広告主１３０９〜１３１１から構成される。
【００７６】
本実施形態では、上記第２実施形態と同様に、複数の放送事業者１３０１〜１３０３が上述した第１実施形態のサービス事業者７５を兼ねており、視聴者１３０５〜１３０７は、代行録画サービスを提供する放送事業者１３０１〜１３０３と直接契約する形態である。また、本実施形態では、放送事業者１３０１，１３０２が互いに番組コンテンツの著作権、著作隣接権を共有することにより、相互に放送を受信して録画配信可能とし、サービス可能な番組コンテンツの数を増すことができる形態である。
【００７７】
次に、本実施形態における各事業者および視聴者間でのサービス、金銭の流れについて説明する。
【００７８】
テレビジョン放送を行う放送事業者のうち、番組コンテンツの製作、編成を行い、番組の著作権、著作隣接権を所有する放送事業者１３０１〜１３０３は、互いに提携して番組コンテンツの著作権、著作隣接権を共有することにより、相互に録画配信可能である。すなわち、視聴者１３０５〜１３０７から録画依頼された番組が初めて依頼された番組の場合、放送事業者自身の番組ならば直接、提携放送事業者の番組ならば、放送を受信してストリーミングコンテンツとしてサーバに保管する。そして、視聴者１３０５〜１３０７からの配信リクエストに応じてオンデマンドでストリーミング配信する代わりに、サービス料金を視聴者１３０５〜１３０７から徴収する。ここで、サービス料金の課金方法としては、第１実施形態と同様に、例えば月極めの固定料金とする方法、代理録画した回数などに応じた従量制とする方法、またはそれらを組み合わせた方法などがある。
【００７９】
また、視聴者１３０５〜１３０７からサービス料金を徴収する代わりに、ストリーミング配信するデータに広告主１３０９〜１３１１の広告を付加することにより、代行録画サービスの運営を行うこともできる。この広告の付加方法としては、番組データの前に動画広告用のデータを付加し、これらをあわせてストリーミングコンテンツとして配信する方法がある。視聴者１３０５〜１３０７は、録画番組を再生する前に必ずこの動画広告を観なければならないようにする。
【００８０】
視聴者１３０５〜１３０７は、放送事業者１３０１〜１３０３と個別に契約し、録画依頼しておいた番組の配信を受ける換わりにサービス料金を支払うか、または上述したように録画番組を再生する前に動画広告を視聴する。サービス料金の徴収は、第１実施形態と同様に、例えば視聴者１３０５のように直接放送事業者１３０１に払う方式、視聴者１３０６のように通信ネットワーク１３０４を介して支払う方式、視聴者１３０７のように料金徴収代行業者１３０８を介して支払う方式などがある。
【００８１】
本実施形態の代行録画システムは、図１４に示すように、放送事業者１９０１，１９０４、委託放送事業者１９０２、受託放送事業者１９０３、通信ネットワーク１９０５、受信機１９０６〜１９０８から構成される。ここで、通信ネットワーク１９０５、受信機１９０６〜１９０８に関しては、上記第１実施形態と同様であるため、その説明は省略する。
【００８２】
次に、放送事業者１９０１，１９０２，１９０４について説明する。
【００８３】
放送事業者１９０１，１９０２，１９０４は、図１５に示すように、受信手段２０１、コンテンツストレージ手段２０２、エンコーダ手段２０３、サーバ手段２０４から構成される。受信手段２０１は、チューナ手段２０１１、フロントエンド手段２０１２、ＣＡ手段２０１３、デマルチプレクサ手段２０１４、ビデオデコーダ手段２０１５、およびオーディオデコーダ手段２０１６を含む。コンテンツストレージ手段２０２は、番組コンテンツストレージ手段２０２１および再生手段２０２２を含む。エンコーダ手段２０３は、ビデオエンコーダ手段２０３１およびオーディオエンコーダ手段２０３２を含む。サーバ手段２０４は、ディスクストレージ手段２０４１、ＣＰＵ２０４２およびネットワークＩ／Ｆ手段２０４３を含む。
【００８４】
放送事業者１９０１，１９０２，１９０４において、視聴者の受信機１９０６〜１９０８より録画リクエストされた番組が初めての番組すなわち未保存の番組であった場合（ステップＳ１６０１）、エンコーダ手段２０３が再生データを受けてリアルタイムエンコードするタイプであれば、エンコーダ手段２０３は、視聴者の受信機１９０６〜１９０８より指定された番組をサーバ手段２０４の制御により再生する。エンコーダ手段２０３がデータファイルを受けてエンコードするタイプであれば、エンコーダ手段２０３は、受信機１９０６〜１９０８より送信、指定された番組データファイルを番組コンテンツストレージ手段２０２１からエンコーダ手段２０３に転送する（ステップＳ１６０２）。
【００８５】
次に、受信手段２０１について説明すると、上記視聴者の受信機１９０６〜１９０８より録画リクエストされた番組が提携放送事業者の番組であった場合（ステップＳ１６０３）、提携事業者の放送する番組を受信手段２０１により受信して（ステップＳ１６０４）、後述するエンコーダー手段２０３に転送する。ここで、受信手段２０１における受信処理は、上記第１実施形態で説明した通りであるため、ここでの説明を省略する。
【００８６】
エンコーダ手段２０３のビデオエンコーダ手段２０３１、オーディオエンコーダ手段２０３２は、再生された信号をリアルタイムエンコードするタイプであれば、それぞれ入力されたビデオ、オーディオ信号をストリーミング配信に好適な信号に圧縮符号化およびフォーマット変換してサーバ手段２０４に送る（ステップＳ１６０５）。また、入力がデータファイルである場合は、ストリーミング配信に好適なデータに圧縮符号化およびフォーマット変換してサーバ手段２０４に送る（ステップＳ１６０６）。圧縮符号化およびフォーマット変換処理は、第１実施形態と同様、専用のハードウエアで行ってもよいし、サーバ手段２０４のＣＰＵ２０４２上で動作するソフトウエアで行ってもよい。また、ビデオの圧縮サーバ処理としては、第１実施形態と同様に、ＭＰＥＧ−２よりもさらなる高圧縮率を実現できるＭＰＥＧ−４を用いることが好適であるが、これに限定されることはなく、他の高圧縮可能な方式であれば、いかなる方式でもかまわない。
【００８７】
また、上記フォーマット変換は第１実施形態と同様、例えばマイクロソフト社のストリーミングクライアント（再生ソフトウエア）であるWindows（登録商標） Media Player用であれば、ＡＳＦ（Advanced Streaming Format）フォーマットに、リアルネットワークス社のストリーミングクライアントであるReal Player用であれば、ＲＭ（Real Movie）フォーマットなどに変換される。
【００８８】
次に、サーバ手段２０４について説明すると、サーバ手段２０４のＣＰＵ２０４２は、受信機１９６〜１９８との通信により、初めて指定された番組のうち、提携放送事業者の番組については、受信手段２０１を制御して受信させ、放送事業者自身の番組については、上記コンテンツストレージ手段２０２を制御して再生または送信させる。そして、ＣＰＵ２０４２は、上記エンコーダ手段２０３において圧縮符号化およびフォーマット変換されたビデオ、オーディオ信号を、ディスクストレージ手段２０４１に格納する（ステップＳ１６０６）。さらに、上記ビデオ、オーディオデータとともに、ストリーミング配信する際のユーザＩ／Ｆを提供するために必要なＨＴＭＬ（Hyper Text Mark up Language）ファイルなどが、ＣＰＵ２０４２によりディスクストレージ手段２０４１に格納される（ステップＳ１６０７）。
【００８９】
そして、サーバ手段２０４は、受信機１９６〜１９８へ再生可能な状態になったことを示す録画受付完了データを送信する（ステップＳ１６０８）。ここで、視聴者１３５〜１３７と放送事業者１３１〜１３３との代理録画サービス契約が従量制であった場合には（ステップＳ１６０９）、ＣＰＵ２０４２の料金データを更新する（ステップＳ１６１０）。
【００９０】
さらに、サーバ手段２０４は受信機１９６〜１９８からのストリーミング再生リクエストを受け（ステップＳ１６１１）、所望のコンテンツをストリーミング配信する（ステップＳ１６１２）。ただし、ストリーミング配信する際のＨＴＴＰ（Hyper Text Transfer Protocol）サーバーソフトウエアおよびストリーミングサーバーソフトウエアは、ＣＰＵ２０４２上で動作する。
【００９１】
ただし、本実施形態では、既に他の視聴者の受信機１９６〜１９８により録画リクエストされ、ストリーミング配信可能なデータとして保存されている番組の録画リクエストに対しては、上述した再生、変換、格納処理（ステップＳ１６０２〜Ｓ１６０７）は行われない（重複録画は行わない）が、録画受付完了データの送信（ステップＳ１６０８）および従量制契約の場合における料金データの更新（ステップＳ１６１０）は行われるものとする。
【００９２】
以上、放送事業者１９１、１９２、１９４に係る代理録画システムの構成例については、その機能的に明確にするため、受信手段２０１、コンテンツストレージ手段２０２、エンコーダ手段２０３、サーバ手段２０４に分けて説明したが、実際の構成は、例えば、エンコーダ手段２０３とサーバ手段２０４が１つのコンピュータ上で動作するのもであってもよいし、または全ての手段が１つのコンピュータ上で動作するものであってもよく、この代理録画システムの構成例が、本発明の放送事業者１９１，１９２，１９４の構成を制限しないことはいうまでもない。
【００９３】
（第４実施形態）
次に、本発明の第４実施形態について図１７および図１８を参照しながら説明する。図１７は本発明の第４実施形態に係る代行録画サービスが適用される放送システムの構成を示すブロック図、図１８は本発明の第４実施形態に係る放送事業者の動作の手順を示すフローチャートである。
【００９４】
代行録画サービスが適用される放送システムは、図１７に示すように、複数の放送事業者１４０１〜１４０３、通信ネットワーク１４０４、複数の視聴者１４０５〜１４０７、料金徴収代行業者１４０８、広告主１４０９〜１４１１とから構成される。
【００９５】
本実施形態では、上記第２実施形態と同様に、複数の放送事業者１４０１〜１４０３が上記第1実施形態のサービス事業者７５を兼ねており、視聴者１４０５〜１４０７は代行録画サービスを提供する放送事業者１４０１〜１４０３と直接契約する形態である。ここで、図１７に示すように、放送事業者１４０１、１４０２が互いに番組コンテンツの著作権、著作隣接権を共有することにより、相互にストリーミングコンテンツを享受して配信可能とし、サービス可能な番組コンテンツの数を増やすことを可能とする。
【００９６】
次に、各事業者および視聴者間でのサービス、金銭の流れについて説明する。
【００９７】
テレビジョン放送を行う放送事業者のうち、番組コンテンツの製作、編成を行い、番組の著作権、著作隣接権を所有する放送事業者１４０１〜１４０３は、互いに提携して番組コンテンツの著作権、著作隣接権を共有することにより、相互に録画配信可能とする。すなわち、視聴者１４０５〜１４０７から録画依頼された番組が初めて依頼された番組の場合、放送事業者自身の番組ならば、直接に、提携放送事業者の番組ならば、通信ネットワーク１４０４経由でストリーミングコンテンツとして入手し、サーバに保管する。そして、視聴者１４０５〜１４０７からの配信リクエストに応じてオンデマンドでストリーミング配信する代わりに、サービス料金を視聴者１４０５〜１４０７から徴収する。ただし、サービス料金の課金方法としては、第１実施形態と同様に、例えば月極めの固定料金とする方法、代行録画した回数などに応じた従量制とする方法、またはそれらを組み合わせた方法などがある。
【００９８】
また、視聴者１４０５〜１４０７からサービス料金を徴収する代わりに、ストリーミング配信するデータに広告主１４０９〜１４１１の広告を付加することにより、代行録画サービスの運営を行うこともできる。この広告の付加方法としては、番組データの前に動画広告用のデータを付加し、これらをあわせてストリーミングコンテンツとして配信する方法がある。視聴者１４０５〜１４０７は、録画番組を再生する前に必ずこの動画広告を観なければならないようにする。
【００９９】
視聴者１４０５〜１４０７は、放送事業者１４０１〜１４０３と個別に契約し、録画依頼しておいた番組の配信を受ける換わりにサービス料金を支払うか、または上述したように録画番組を再生する前に動画広告を視聴する。ただし、サービス料金の徴収は、第１実施形態と同様に、例えば視聴者１４０５のように直接放送事業者１４０１に払う方式、視聴者１４０６のように通信ネットワーク１４０４を介して支払う方式、視聴者１４０７のように料金徴収代行業者１４０８を介して支払う方式などがある。
【０１００】
上記第３実施形態では、提携放送事業者からの番組コンテンツの取得が放送波の受信によって行われているが、本実施形態では、既にエンコード、フォーマット変換されたデータを通信ネットワーク１４０４経由でなされることである。
【０１０１】
本実施形態の代行録画システムは、上記第３実施形態の構成（図１５に示す構成）と同様であり、その説明は省略する。また、以下の説明においては、図１５の符号を用いることとする。ここで、通信ネットワーク１９５、受信機１９６〜１９８に関しては、第１実施形態と同様であるため、その説明は省略する。
【０１０２】
また、本実施形態の放送事業者１９１，１９２，１９４の構成は、上記第２実施形態の構成（図１１に示す構成）と同じであり、その構成についての説明は省略する。
【０１０３】
次に、放送事業者１９１，１９２，１９４の動作について説明する。放送事業者１９１，１９２，１９４においては、図１８に示すように、視聴者の受信機９６〜９８により録画リクエストされた番組が初めての番組すなわち未保存の番組であった場合（ステップＳ１７０１）、エンコーダ手段１０２が再生データを受けてリアルタイムエンコードするタイプであれば、エンコーダ手段１０２は、視聴者の受信機１９６〜１９８により指定された番組を、サーバ手段１０３の制御に従い再生する。これに対し、エンコーダ手段１０２がデータファイルを受けてエンコードするタイプである場合、エンコーダ手段１０２は、受信機１９６〜１９８により送信、指定された番組データファイルを番組コンテンツストレージ手段１０１１からエンコーダ手段１０２に転送する（ステップＳ１７０２）。
【０１０４】
エンコーダ手段１０２のビデオエンコーダ手段１０２１、オーディオエンコーダ手段１０２２は、再生された信号をリアルタイムエンコードするタイプの場合、それぞれ入力されたビデオ、オーディオ信号をストリーミング配信に好適な信号に圧縮符号化およびフォーマット変換してサーバ手段１０３に送る（ステップＳ１７０３）。また、入力がデータファイルである場合、ビデオエンコーダ手段１０２１、オーディオエンコーダ手段１０２２は、ストリーミング配信に好適なデータに圧縮符号化およびフォーマット変換してサーバ手段１０３に送る（ステップＳ１７０３）。圧縮符号化およびフォーマット変換処理は、第１実施形態と同様に、専用のハードウエアで行ってもよいし、サーバ手段１０３のＣＰＵ１０３２上で動作するソフトウエアで行ってもよい。また、ビデオの圧縮符号化処理としては、第1実施形態と同様に、ＭＰＥＧ−２よりもさらなる高圧縮率を実現可能なＭＰＥＧ−４を用いることが好適であるが、これに限定されることはなく、高圧縮を実現可能方式であれば、いかなる方式でもよい。
【０１０５】
また、上記フォーマット変換は、第１実施形態と同様に、例えばマイクロソフト社のストリーミングクライアント（再生ソフトウエア）であるWindows（登録商標） Media Player用であれば、ＡＳＦ（Advanced Streaming Format）フォーマット、リアルネットワークス社のストリーミングクライアントであるReal Player用であれば、ＲＭ（Real Movie）フォーマットなどに変換される。
【０１０６】
サーバ手段１０３においては、そのＣＰＵ１０３２が、受信機１９６〜１９８との通信により、初めて指定された番組を、上記コンテンツストレージ手段１０１を制御して再生または送信させ、上記エンコーダ手段１０２において圧縮符号化およびフォーマット変換されたビデオ、オーディオ信号を、ディスクストレージ手段１０３１に格納する（ステップＳ１７０４）。さらに、上記ビデオ、オーディオデータとともに、ストリーミング配信する際のユーザＩ／Ｆを提供するために必要なＨＴＭＬ（Hyper Text Mark up Language）ファイルなどが、ＣＰＵ１０３２によりディスクストレージ手段１０３１に格納される（ステップＳ１７０５）。
【０１０７】
ただし、上記視聴者の受信機１９６〜１９８により録画リクエストされた番組が未保存でかつ提携放送事業者の番組であった場合（ステップＳ１７０６）、リクエストされた番組のストリーミング配信可能なデータへの変換依頼（ステップＳ１７０７）を行い、通信ネットワーク１９５経由で取得して、上記ディスクストレージ手段１０３１に格納する（ステップＳ１７０８）。この通信ネットワーク１９５経由でのストリーミング配信可能な番組データの送受信は、第１実施形態で説明したＦＴＰで行うことが好適である。
【０１０８】
サーバ手段１０３は、受信機１９６〜１９８へ再生可能な状態になったことを示す録画受付完了データを送信する（ステップＳ１７０９）。ここで、視聴者１４０５〜１４０７と放送事業者１４０１〜１４０３との代理録画サービス契約が従量制であった場合には（ステップＳ１７１０）、ＣＰＵ１０３２の料金データを更新する（ステップＳ１７１１）。
【０１０９】
さらに、サーバ手段１０３は受信機１９６〜１９８からのストリーミング再生リクエストを受け（ステップＳ１７１２）、所望のコンテンツをストリーミング配信する（ステップＳ１７１３）。ただし、ストリーミング配信する際のＨＴＴＰ（Hyper Text Transfer Protocol）サーバーソフトウエアおよびストリーミングサーバソフトウエアは、ＣＰＵ１０３２上で動作する。
【０１１０】
ただし、本実施形態では、既に他の視聴者の受信機１９６〜１９８により録画リクエストされ、ストリーミング配信可能なデータとして保存されている番組の録画リクエストに対しては、上述した再生、変換、格納処理および提携放送事業者からの取得（ステップＳ１７０２〜Ｓ１７０８）は行われない（重複録画は行われない）が、録画受付完了データの送信（ステップＳ１７０９）、および従量制契約の場合における料金データの更新（ステップＳ１７１１）は行われるものとする。
【０１１１】
（第５実施形態）
次に、本発明の第５実施形態について図１９および図２０を参照しながら説明する。図１９は本発明の第５実施形態に係る代行録画サービスが適用される放送システムの構成を示すブロック図、図２０は本発明の第５実施形態に係る放送事業者の動作の手順を示すフローチャートである。
【０１１２】
放送システムは、図１９に示すように、複数の放送事業者１５０１〜１５０３、通信ネットワーク１５０４、複数の視聴者１５０５〜１５０７、料金徴収代行業者１５０８、および広告主１５０９〜１５１１から構成される。
【０１１３】
本実施形態では、上記第２実施形態と同様に、複数の放送事業者１５０１〜１５０３が上述した第1実施形態のサービス事業者７５を兼ねており、視聴者１５０５〜１５０７は代行録画サービスを提供する放送事業者１５０１〜１５０３と直接契約する形態である。ただし、図１９に示すように、放送事業者１５０１，１５０２が提供して相互に番組コンテンツの代行録画を代行し合うことにより、サービス可能な番組コンテンツの数を増やすことが可能である。
【０１１４】
各事業者および視聴者間でのサービス、金銭の流れを説明する。
【０１１５】
テレビジョン放送を行う放送事業者のうち、番組コンテンツの製作、編成を行い、番組の著作権、著作隣接権を所有する放送事業者１５０１〜１５０３は、互いに提携して相互に番組コンテンツの代行録画を代行し合う。すなわち、視聴者１５０５〜１５０７から録画依頼された番組が初めて依頼された番組の場合、放送事業者自身の番組ならば、直接ストリーミングコンテンツとしてサーバに保管し、提携放送事業者の番組ならば、依頼された番組をストリーミングコンテンツとして提携放送事業者のサーバに保管してもらい、そのＵＲＬを取得する。そして、視聴者１５０５〜１５０７からの配信リクエストに応じて、放送事業者自身の番組ならば直接オンデマンドでストリーミング配信する。また、配信する番組が提携放送事業者の番組ならば、提携放送事業者のサーバからオンデマンドでストリーミング配信させる代わりに、サービス料金を視聴者１５０５〜１５０７から徴収する。ただし、サービス料金の課金方法としては、第１実施形態と同様に、例えば月極めの固定料金とする方法、代行録画した回数などに応じた従量制とする方法、またはそれらを組み合わせた方法などがある。
【０１１６】
また、視聴者１５０５〜１５０７からサービス料金を徴収する代わりに、ストリーミング配信するデータに広告主１５０９〜１５１１の広告を付加することにより、代行録画サービスの運営を行うこともできる。この広告の付加方法としては、番組データの前に動画広告用のデータを付加し、これらを合わせてストリーミングコンテンツとして配信する方法がある。視聴者１５０５〜１５０７は、録画番組を再生する前に必ずこの動画広告を観なければならないようにする。
【０１１７】
視聴者１５０５〜１５０７は、放送事業者１５０１〜１５０３と個別に契約し、録画依頼しておいた番組の配信を受ける代わりにサービス料金を支払うか、または上述したように録画番組を再生する前に動画広告を視聴する。ただし、サービス料金の徴収は、第１実施形態と同様に、例えば視聴者１５０５のように直接放送事業者１５０１に払う方式、視聴者１５０６のように通信ネットワーク１５０４を介して支払う方式、視聴者１５０７のように料金徴収代行業者１５０８を介して支払う方式などがある。
【０１１８】
上記第３および第４の実施形態では、提携放送事業者から、番組コンテンツを実際に取得したが、本実施形態では、既にストリーミング配信可能なデータに変換され、提携放送事業者のサーバに格納されているデータのＵＲＬのみを取得し、実際の配信は提携放送事業者のサーバから行う。
【０１１９】
本実施形態の代行録画システムの構成は、上記第３および第４実施形態と同様に、放送事業者１９１、１９４、委託放送事業者１９２、受託放送事業者１９３、通信ネットワーク１９５、および受信機１９６〜１９８から構成される。ここで、通信ネットワーク１９５、受信機１９６〜１９８に関しては、第１実施形態と同様であるため、その説明は省略する。
【０１２０】
また、本実施形態の放送事業者１９１，１９２，１９４の構成は、上記第２および第４実施形態と同じであるので、その説明については省略する。以下の説明においては、図１１の符号を用いることとする。
【０１２１】
次に、本実施形態の放送事業者１９１，１９２，１９４の動作について説明する。
【０１２２】
本実施形態の放送事業者１９１，１９２，１９４において、視聴者の受信機９６〜９８により録画リクエストされた番組が初めての番組すなわち未保存の番組であった場合（ステップＳ１８０１）、エンコーダ手段１０２が再生データを受けてリアルタイムエンコードするタイプであれば、エンコーダ手段１０２は視聴者の受信機１９６〜１９８により指定された番組をサーバ手段１０３の制御に従い再生する。エンコーダ手段１０２がデータファイルを受けてエンコードするタイプであれば、受信機１９６〜１９８により送信、指定された番組データファイルを番組コンテンツストレージ手段１０１１からエンコーダ手段１０２に転送する（ステップＳ１８０２）。
【０１２３】
エンコーダ手段１０２において、ビデオエンコーダ手段１０２１、オーディオエンコーダ手段１０２２は、再生された信号をリアルタイムエンコードするタイプの場合、それぞれ入力されたビデオ,オーディオ信号をストリーミング配信に好適な信号に圧縮符号化およびフォーマット変換してサーバ手段１０２に送る（ステップＳ１８０３）。これに対し、入力がデータファイルである場合も同様に、このデータファイルは、ストリーミング配信に好適なデータに圧縮符号化およびフォーマット変換されてサーバ手段１０３に送られる（ステップＳ１８０３）。圧縮符号化およびフォーマット変換処理は、第１実施形態と同様に、専用のハードウエアで行ってもよいし、サーバ手段１０３のＣＰＵ１０３２上で動作するソフトウエアで行ってもよい。また、ビデオの圧縮符号化処理としては、第１実施形態と同様に、ＭＰＥＧ−２よりもさらなる高圧縮率を実現可能なＭＰＥＧ−４を用いることが好適であるが、高圧縮を実現可能な方式であれば、これに限定されることはない。
【０１２４】
また、上記フォーマット変換は、上記第１実施形態と同様、例えばマイクロソフト社のストリーミングクライアント（再生ソフトウエア）であるWindows（登録商標） Media Player用であればＡＳＦ（Advanced Streaming Format）フォーマット、リアルネットワークス社のストリーミングクライアントであるReal Player用であればＲＭ（Real Movie）フォーマットなどに変換される。
【０１２５】
次に、サーバ手段１０３において、サーバ手段１０３のＣＰＵ１０３２は、受信機１９６〜１９８との通信により、初めて指定された番組を、上記コンテンツストレージ手段１０１を制御して再生または送信させ、上記エンコーダ手段１０２において圧縮符号化およびフォーマット変換されたビデオ、オーディオ信号を、ディスクストレージ手段１０３１に格納する（ステップＳ１８０４）。さらに、上記ビデオ、オーディオデータとともに、ストリーミング配信する際のユーザＩ／Ｆを提供するために必要なＨＴＭＬ（Hyper Text Mark up Language）ファイルなどが、ＣＰＵ１０３２によりディスクストレージ手段１０３１に格納される（ステップＳ１８０５）。
【０１２６】
ただし、上記視聴者の受信機１９６〜１９８により録画リクエストされた番組が未保存でかつ提携放送事業者の番組であった場合（ステップＳ１８０６）、リクエストされた番組の代理録画および配信サービスを提携放送事業者に依頼し（ステップＳ１８０７）、提携放送事業者のストリーミング配信可能なデータのＵＲＬのみを通信ネットワーク１９５経由で取得する（ステップＳ１８０８）。そして、視聴者の受信機１９６〜１９８からの再生リクエストに対しては、ＵＲＬへハイパーリンクを貼る。
【０１２７】
サーバ手段１０３は、受信機１９６〜１９８へ再生可能な状態になったことを示す録画受付完了データを送信する（ステップＳ１８０９）。ここで、視聴者１５５〜１５７と放送事業者１５１〜１５３との代理録画サービス契約が従量制であった場合には（ステップＳ１８１０）、ＣＰＵ１０３２の料金データを更新する（ステップＳ１８１１）。
【０１２８】
次に、サーバ手段１０３は、視聴者の受信機１９６〜１９８からのストリーミング再生リクエストを受け（ステップＳ１８１２）、所望のコンテンツをストリーミング配信する（ステップＳ１８１４）。ただし、再生リクエストされた番組が提携事業者の番組であった場合には、上記提携放送事業者のストリーミング配信可能なデータのＵＲＬへハイパーリンクを貼る（ステップＳ１８１５）。また、ストリーミング配信する際のＨＴＴＰ（Hyper Text Transfer Protocol）サーバソフトウエアおよびストリーミングサーバソフトウエアは、ＣＰＵ１０３２上で動作する。
【０１２９】
ただし、本実施形態では、既に他の視聴者の受信機１９６〜１９８により録画リクエストされ、ストリーミング配信可能なデータとして保存されている番組の録画リクエストに対しては、上述した再生、変換、格納処理および提携放送事業者への代行依頼（ステップＳ１８０２〜ステップＳ１８０８）は行われない（重複録画は行われない）が、録画受付完了データの送信（ステップＳ１８０９）、および従量制契約の場合における料金データの更新（ステップＳ１８１１）は行われるものとする。
【０１３０】
なお、本発明の目的は、前述した各実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることはいうまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【０１３１】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはうまでもない。
【０１３２】
以下、本発明の実施態様の例を列挙する。
【０１３３】
［実施態様１］  複数の放送事業者が放送するテレビジョン番組のうち、所望するテレビジョン番組の録画要求および再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビジョン番組を再生可能に受信する受信装置を有する視聴者と、前記視聴者から録画要求されたテレビジョン番組を対応する放送事業者から取得し、前記視聴者の再生要求に応じて前記通信回線を介して前記取得された録画要求のテレビジョン番組を前記視聴者に配信するとともに前記代行録画サービスに関する料金を前記視聴者から徴収する代行録画サービスを運営するサービス業者と、前記視聴者から支払われた料金を前記放送事業者に分配する管理団体とを含むことを特徴とする代理録画システム。
【０１３４】
［実施態様２］  前記複数の放送事業者は、それぞれ放送するテレビジョン番組に対して著作権を有することを特徴とする実施態様１記載の代行録画システム。
【０１３５】
［実施態様３］  前記複数の放送事業者は、それぞれ放送するテレビジョン番組に対して著作隣接権を有することを特徴とする実施態様１記載の代行録画システム。
【０１３６】
［実施態様４］  前記管理団体は、非営利の著作権集中管理団体であることを特徴とする実施態様１記載の代行録画システム。
【０１３７】
［実施態様５］  前記視聴者から徴収する前記代行録画サービスに関する料金は、テレビジョン番組の２次使用料であることを特徴とする実施態様１記載の代行録画システム。
【０１３８】
［実施態様６］  前記視聴者から徴収する前記代行録画サービスに関する料金は、私的録画保証金であることを特徴とする実施態様１記載の代行録画システム。
【０１３９】
［実施態様７］  前記通信回線は、インターネットであることを特徴とする実施態様１記載の代行録画システム。
【０１４０】
［実施態様８］  前記テレビジョン番組の前記視聴者への配信は、ストリーミング配信であることを特徴とする実施態様１記載の代行録画システム。
【０１４１】
［実施態様９］  前記サービス事業者は、予め取得されている複数のテレビジョン番組を保持し、該保持されている複数のテレビジョン番組の中に、前記視聴者の録画要求に対応するテレビジョン番組がある場合は、該録画要求のテレビジョン番組を前記視聴者に配信することを特徴とする実施態様１記載の代行録画システム。
【０１４２】
［実施態様１０］  所望するテレビジョン番組の再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビビジョン番組を再生可能に受信する受信装置を有する複数の視聴者と、前記視聴者から再生要求されたテレビジョン番組を、前記通信回線を介して前記視聴者に配信するとともに前記視聴者から前記代行録画サービスに関する料金を徴収する代行録画サービスを運営する複数の放送事業者と含むことを特徴とする代行録画システム。
【０１４３】
［実施態様１１］  所望するテレビジョン番組の再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビビジョン番組を付加された広告とともに再生可能に受信する受信装置を有する複数の視聴者と、前記視聴者から再生要求されたテレビジョン番組に広告を付加して、前記通信回線を介して前記視聴者に配信するとともに前記広告の広告主から広告料を徴収する代行録画サービスを運営する複数の放送事業者とを含むことを特徴とする代行録画システム。
【０１４４】
［実施態様１２］  所望するテレビジョン番組の再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビビジョン番組を再生可能に受信する受信装置を有する複数の視聴者と、前記視聴者から再生要求されたテレビジョン番組を、前記通信回線を介して前記視聴者に配信するとともに前記視聴者から前記代行録画サービスに関する料金を徴収する代行録画サービスを運営する放送事業者とを含み、前記放送事業者は、前記視聴者から再生要求された番組が提携放送事業者の番組であった場合、該番組を受信しまたは前記提携放送事業者から直接取得することを特徴とする代行録画システム。
【０１４５】
［実施態様１３］  所望するテレビジョン番組の再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビビジョン番組とともにそれに付加された広告を再生可能に受信する受信装置を有する複数の視聴者と、前記視聴者から再生要求されたテレビジョン番組を、前記通信回線を介して前記視聴者に配信するとともに前記広告の広告主から広告料を徴収する代行録画サービスを運営する放送事業者とを含み、前記放送事業者は、前記視聴者から再生要求された番組が提携放送事業者の番組であった場合、該番組を受信しまたは前記提携放送事業者から直接取得することを特徴とする代行録画システム。
【０１４６】
［実施態様１４］  所望するテレビジョン番組の再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビビジョン番組を再生可能に受信する受信装置を有する複数の視聴者と、前記視聴者から再生要求されたテレビジョン番組を、前記通信回線を介して前記視聴者に配信するとともに、前記視聴者から前記代行録画サービスに関する料金を徴収する代行録画サービスを運営する放送事業者とを含み、前記放送事業者は、前記視聴者から再生要求された番組が提携放送事業者の番組であった場合、前記提携放送事業者が保持する前記再生要求の番組へハイパーリンクすることにより、該再生要求の番組を前記視聴者に配信することを特徴とする代行録画システム。
【０１４７】
［実施態様１５］  所望するテレビジョン番組の再生要求を、通信回線を介して発行可能であるとともに、前記再生要求に応じて配信されたテレビビジョン番組とともにそれに付加された広告を再生可能に受信する受信装置を有する複数の視聴者と、前記視聴者から再生要求されたテレビジョン番組を、前記通信回線を介して前記視聴者に配信するとともに前記広告の広告主から広告料を徴収する代行録画サービスを運営する放送事業者とを含み、前記放送事業者は、前記視聴者から再生要求された番組が提携放送事業者の番組であった場合、前記提携放送事業者が保持する前記再生要求の番組へハイパーリンクすることにより、該再生要求の番組を前記視聴者に配信することを特徴とする代行録画システム。
【０１４８】
【発明の効果】
以上説明したように、本発明によれば、ユーザが所望する番組を好きな時間に再生して視聴することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態に係る代行録画システムが適用される放送システムを示すブロック図である。
【図２】本発明の第１実施形態に係る代行録画システムの構成を示すブロック図である。
【図３】データセンター１５の構成を示すブロック図である。
【図４】図３のデータセンター１５の動作手順を示すフローチャートである。
【図５】ＨＴＭＬファイルによるユーザＩ／Ｆとして表示される、代理録画、保管されている番組一覧画面を示す図である。
【図６】受信機１７〜１９の構成を示すブロック図である。
【図７】受信機１７〜１９によるデータセンター１５に対する代行録画リクエスト処理の手順を示すフローチャートである。
【図８】受信機１７〜１９によるデータセンター１５において代理録画された番組の受信表示処理の手順を示すフローチャートである。
【図９】本発明の第２実施形態に係る代行録画システムが適用される放送システムを示すブロック図である。
【図１０】本発明の第２実施形態に係る代行録画システムの構成を示すブロック図である。
【図１１】放送事業者９１，９２，９４の構成を示すブロック図である。
【図１２】放送事業者９１，９２，９４の動作の手順を示すフローチャートである。
【図１３】本発明の第３実施形態に係る代行録画システムが適用される放送システムを示すブロック図である。
【図１４】本発明の第３実施形態に係る代行録画システムの構成を示すブロック図である。
【図１５】図１４の放送事業者１９０１，１９０２，１９０４の構成を示すブロック図である。
【図１６】放送事業者１９０１，１９０２，１９０４の動作の手順を示すフローチャートである。
【図１７】本発明の第４実施形態に係る代行録画サービスが適用される放送システムの構成を示すブロック図である。
【図１８】本発明の第４実施形態に係る放送事業者の動作の手順を示すフローチャートである。
【図１９】本発明の第５実施形態に係る代行録画サービスが適用される放送システムの構成を示すブロック図である。
【図２０】本発明の第５実施形態に係る放送事業者の動作の手順を示すフローチャートである。
【符号の説明】
１１，１４，９１，８０１，８０２，８０３，１９１，１９４，１３０１，１３０２，１３０３，１４０１，１４０３，１５０１，１５０２，１５０３  放送事業者
１２，９２，１９２  委託放送事業者
１３，９３，１９３  受託放送事業者
１５  データセンター
１６，９５，７０６，８０４，１３０４，１４０４，１５０４  通信ネットワーク
７０７，７０８，７０９，８０５，８０６，８０７，１３０５，１３０６，１３０７，１４０５，１４０６，１４０７，１５０５，１５０６，１５０７  視聴者
１７，１８，１９，９６，９７，９８  受信機
７０５  サービス業者
７１０  著作権管理団体
７１１，８０８，１３０８，１４０８  料金徴収代行業者
８０９，８１０，８１１，１３０９，１３１０，１３１１，１４０９，１４１０，１４１１，１５０９，１５１０，１５１１  広告主
【図１】
2004194255.tif 000003
【図２】
2004194255.tif 000004
【図３】
2004194255.tif 000005
【図４】
2004194255.tif 000006
【図５】
2004194255.tif 000007
【図６】
2004194255.tif 000008
【図７】
2004194255.tif 000009
【図８】
2004194255.tif 000010
【図９】
2004194255.tif 000011
【図１０】
2004194255.tif 000012
【図１１】
2004194255.tif 000013
【図１２】
2004194255.tif 000014
【図１３】
2004194255.tif 000015
【図１４】
2004194255.tif 000016
【図１５】
2004194255.tif 000017
【図１６】
2004194255.tif 000018
【図１７】
2004194255.tif 000019
【図１８】
2004194255.tif 000020
【図１９】
2004194255.tif 000021
【図２０】
2004194255.tif 000022