(57)【要約】【課題】チューナが１つしかない放送受信機などにおいて、自分で録画できない裏番組の予約登録をＰ２Ｐネットワークネットワーク接続された複数の機器を一括して制御するマクロコマンドの内容を予め定義しておくこと無く、個々のユーザの環境や目的に対応した内容で後から登録する。【解決手段】まず、ステップＳ３００で、ホームネットワーク全体に対して、「設定変更通知指令コマンド」をブロードキャストし、各機器を「設定変更通知モード」にし、イベント待ちを行う（ステップＳ３０２）。ユーザが、所望の機器に対する所望の設定を行うと、その都度、機器からコントローラに対して、ユーザ操作に等価なネットワークコマンドである「設定変更通知応答」が送信される。コントローラは、この「設定変更通知応答」をマクロとして記憶する（ステップＳ３０６）。【選択図】  図２
2005006041.tif 000002
【特許請求の範囲】
【請求項１】
放送番組データを受信する放送受信ステップと、
前記放送番組の録画を予約登録する予約登録ステップと、
前記予約登録ステップによって登録された予約対象番組を録画する予約実行ステップと、
ネットワークとの通信を行う通信ステップと、
を備えた予約録画方法において、
前記通信ステップは、
第一の番組識別子によって特定される放送番組の代行予約登録指示を前記ネットワークから受信する代行予約登録受信ステップと、
第二の番組識別子によって特定される放送番組の録画データ送信指示を前記ネットワークから受信する録画データ送信指示受信ステップと、
前記第二の番組識別子によって特定される放送番組の録画データを再生して前記ネットワークに送信する録画データ送信ステップと、を備え、
前記予約登録ステップは前記代行予約登録受信ステップで受信した前記第一の番組識別子で特定される放送番組を予約登録することを特徴とする予約録画方法。
【請求項２】
請求項１に記載の予約録画方法において、
予約対象番組をユーザに指示させる予約指示ステップを備え、
前記予約登録ステップは、前記予約指示ステップによってユーザから指示される番組の方を、前記代行予約登録受信ステップで受信した前記ネットワークから受信する前記代行予約登録指示よりも優先して予約登録することを特徴とする予約録画方法。
【請求項３】
請求項２に記載の予約録画方法において、
前記予約登録ステップでは、後から前記予約指示ステップでユーザに指示された番組が優先登録されたことによって、既に登録されていた前記代行予約登録が抹消されようとするときには、前記代行予約登録の内容を前記ネットワークに送信して前記ネットワーク上の別の予約録画方法に当該代行予約を依頼する代行予約転送ステップを実行することを特徴とする予約録画方法。
【請求項４】
前記ネットワークは、
前記代行予約登録の内容を一元的に管理する予約管理サーバと、前記予約管理サーバに前記代行予約登録を依頼する複数の代行予約依頼装置と、複数の前記予約録画装置とから構成されるハイブリッド型型ピア・ツゥ・ピアネットワークであり、
前記代行予約登録受信ステップでは前記予約管理サーバから発行される前記代行予約登録指示を受信し、
前記録画データ送信指示受信ステップでは前記録画データ送信指示を前記代行予約依頼装置から受信し、
前記録画データ送信ステップでは前記第二の番組識別子によって特定される放送番組の録画データを再生して前記代行予約依頼装置に対して直接送信することを特徴とする請求項１乃至３のいずれかに記載の予約録画方法。
【請求項５】
前記ネットワークは、
前記代行予約登録を依頼する複数の代行予約依頼装置と、複数の前記予約録画装置とから構成されるピュア型ピア・ツゥ・ピアネットワークであり、
前記代行予約登録受信ステップは、
前記代行予約依頼装置もしくは前記予約録画装置から発行される前記代行予約登録指示を受信するステップと、受信した前記代行予約登録指示を隣接した別の前記予約録画装置に転送する代行予約登録指示転送ステップとからなり、
前記録画データ送信指示受信ステップは、前記代行予約依頼装置、もしくは前記予約録画装置から発行される前記第二の番組識別子によって特定される放送番組の録画データ検索要求を受信するステップと、前記第二の番組識別子によって特定される放送番組の録画データが自装置に録画済みか否かを判定する録画データ検索ステップと、受信した録画データ検索要求を隣接した別の前記予約録画装置に転送する録画データ検索要求転送ステップと、隣接した別の前記予約録画装置から前記判定の結果を受信するステップと、前記自装置の判定結果と前記隣接した別の予約録画装置からの判定結果を合わせて、前記録画データ検索要求の要求元に返送する結果返送ステップとからなり、
前記録画データ送信指示受信ステップでは前記録画データ送信指示を前記代行予約依頼装置から受信し、
前記録画データ送信ステップでは前記第二の番組識別子によって特定される放送番組の録画データを再生して前記代行予約依頼装置に対して直接送信することを特徴とする請求項１乃至３のいずれかに記載の予約録画方法。
【請求項６】
放送番組データを受信する放送受信手段と、
前記放送番組データを録画・再生する録画再生手段と、
前記放送番組の録画を予約登録する手段と、
前記予約登録手段によって登録された予約対象番組を前記録画再生手段に記録する予約実行手段と、
ネットワークとの通信手段と、
を備えた予約録画装置において、
前記通信手段は第一の番組識別子によって特定される放送番組の代行予約登録指示を前記ネットワークから受信し、
前記予約登録手段は前記通信手段で受信した前記第一の番組識別子で特定される放送番組を予約登録し、
さらに前記通信手段は第二の番組識別子によって特定される放送番組の録画データ送信指示を前記ネットワークから受信し、
前記録画再生手段は前記第二の番組識別子によって特定される放送番組の録画データを再生して前記通信手段によって前記ネットワークに送信することを特徴とする予約録画装置。
【請求項７】
請求項６に記載の予約録画装置において、
予約対象番組をユーザに指示させる予約指示手段を備え、
前記予約登録手段は、前記予約指示手段によってユーザから指示される番組の方を、前記ネットワークから受信する前記代行予約登録指示よりも優先して予約登録することを特徴とする予約録画装置。
【請求項８】
請求項７に記載の予約録画装置において、
前記予約登録手段に、後から前記予約指示手段でユーザに指示された番組が優先登録されたことによって、既に登録されていた前記代行予約登録が抹消されようとするときには、前記代行予約登録の内容を前記通信手段によって前記ネットワークに送信することで、前記ネットワーク上の別の予約録画装置に当該代行予約を依頼することを特徴とする予約録画装置。
【請求項９】
前記ネットワークは、
前記代行予約登録の内容を一元的に管理する予約管理サーバと、前記予約管理サーバに前記代行予約登録を依頼する複数の代行予約依頼装置と、複数の前記予約録画装置と、
から構成されるハイブリッド型型ピア・ツゥ・ピアネットワークであり、
前記通信手段は、前記予約管理サーバから発行される前記代行予約登録指示を受信し、
さらに前記通信手段は、前記録画データ送信指示を前記代行予約依頼装置から受信し、
前記録画再生手段は前記第二の番組識別子によって特定される放送番組の録画データを再生して前記通信手段によって前記代行予約依頼装置に対して直接送信することを特徴とする請求項６乃至８のいずれかに記載の予約録画装置。
【請求項１０】
前記ネットワークは、
前記代行予約登録を依頼する複数の代行予約依頼装置と、複数の前記予約録画装置とから構成されるピュア型ピア・ツゥ・ピアネットワークであり、
前記通信手段は、前記代行予約依頼装置、もしくは前記予約録画装置から発行される前記代行予約登録指示を受信して、かつ、隣接した別の前記予約録画装置に転送し、
さらに前記通信手段は、前記代行予約依頼装置、もしくは前記予約録画装置から発行される前記第二の番組識別子によって特定される放送番組の録画データ検索要求を受信して、かつ、隣接した別の前記予約録画装置に転送し、
前記第二の番組識別子によって特定される放送番組の録画データが前記録画再生手段に録画されている否かを判定する録画データ検索手段を備え、
前記通信手段は前記録画データ検索手段の判定結果を前記ネットワークに送信し、
さらに前記通信手段は、前記代行予約依頼装置から発行される前記録画データ送信指示を前記ネットワークから受信し、
前記録画再生手段は前記第二の番組識別子によって特定される放送番組の録画データを再生して前記通信手段によって前記代行予約依頼装置に対して直接送信する、ことを特徴とする請求項６乃至８のいずれかに記載の予約録画装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はテレビやラジオ等の放送番組の受信方法、および受信装置に係わり、特に番組の予約録画・予約録音をネットワークに対して行う予約録画方法、および装置に関する。
【０００２】
【従来の技術】
ＣＳデジタル放送やＢＳデジタル放送が一般的になり、視聴者はより多くの放送チャンネルの中から好みの番組を選択することが可能になっている。このとき、ある番組を視聴しながら、同時に放送される別のチャンネルも視聴したいという要求が生じることがある。
【０００３】
従来のアナログ放送においては、放送を受信するために必要なチューナ部品が比較的安価だったため、ビデオデッキ等の蓄積デバイスにはほとんどの場合はチューナが装備されていた。したがって、ビデオデッキ等を複数台揃えて、リアルタイムで視聴できない番組を録画（いわゆる裏番組録画）することによって問題は解決した。
【０００４】
しかし、現在主流になりつつあるデジタル放送では、チューナ部品が比較的高価なことや、放送が有料化されてスクランブル解除のためのＩＣカードが必要なこと等から、各家庭にはそれぞれ専用の受信機が１台ずつしか用意できないことが多い。１つの受信機では同時に複数の番組を受信できなため、裏番組録画ができない状況になっている。
【０００５】
このような中で、特許文献１では、複数のチューナを装備した録画サーバをネットワーク上に設置して、ユーザから任意の番組の録画を請け負うことのできるシステムが開示されている。ＡＤＳＬやＦＴＴＨに代表されるブロードバンド環境が急速に普及している現状を考えれば、このような方式はある程度実用になると考えられる。
【０００６】
ところが、このような中央にサーバを置いたクライアント／サーバ方式では、ユーザ数が増加するに従って、サーバに大きな投資が必要になるという問題がある。これは、多数のユーザからのトラフィックがサーバに一極集中するために、サーバ側のネットワーク回線容量、ストレージや、制御ＣＰＵに高性能なものが必要となるためである。大量のデータを要する映像をサービスの対象とするために、特にネットワーク回線容量がボトルネックになる可能性が高い。また、サーバがダウンするとシステム全体が使用できなくなるという欠点もある。
【０００７】
ところで、このような一極集中型のサーバを設置するサービスの代わりに、ピア・ツゥ・ピア（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ；Ｐ２Ｐ）ネットワークと呼ばれる分散型サービスの技術が最近脚光を浴びている。（非特許文献１参照）  Ｐ２Ｐには、検索などの一部の機能を中央のサーバに残したハイブリッド型Ｐ２Ｐと、サーバを完全に排除して検索なども含めてすべての機能をネットワーク内の各ノードが分散して行うピュア型Ｐ２Ｐという２種類の方式がある。
【０００８】
例えばＰ２Ｐによるファイル共有を行う場合、共有対象のファイルの検索方法は２つの方式によって異なるものの、一旦、目的のファイルが発見されて転送を行う段階になれば、どらの方式においてもノード間で直接的に通信が行われるため、ネットワークボトルネックは生じない。
【０００９】
なお、ハイブリッド型では検索をサーバで行うためにサーバダウン時のフェイルセーフには弱いが、その反面、著作権管理や課金の処理を容易に行えるという利点もあるため、用途に応じて使い分けると良い。
【００１０】
【特許文献１】
特開２００２−１９１００４号公報
【非特許文献１】
高橋健太郎、「特集２  まるわかりＰ２Ｐファイル共有」、日経ＮＥＴＷＯＲＫ、日経ＢＰ社、２００３年２月２２日、第３５号、ｐ．１２０−１３２
【００１１】
【発明が解決しようとする課題】
既に述べたように、特許文献１のようなクライアント／サーバ型の録画予約システムでは、サーバ側の装置に高性能なものが必要であることと、サーバに障害が発生したときの被害が大きいという問題がある。また、この問題を回避しようとして、非特許文献１のようなＰ２Ｐ型ファイル共有方式を裏番組録画の目的で利用したとしても、必ずしもネットワーク上に目的の録画済み番組ファイルが存在している保証はないため、目的の番組を視聴できない可能性が高い。
【００１２】
上記の問題点を鑑み、本発明では、ユーザが自分で録画することが不可能な裏番組をネットワーク上の余剰資源を利用して録画するシステムであって、かつ、中央の録画サーバに対するネットワークのボトルネックやサーバダウン時の影響を受けずに、さらに、あらかじめ目的の番組が録画されるように予約登録を行うことができるシステムを提供することを目的とする。
【００１３】
【課題を解決するための手段】
以上の課題を解決するために、本発明では、中央の録画サーバを設置せずに、Ｐ２Ｐネットワーク上の各ノードが個別に録画したデータを、ノード間で直接的に転送を行う。また、あらかじめ、番組の予約登録をＰ２Ｐネットワーク上にリクエストしておくことで、目的の番組が録画される確率を高くしている。
【００１４】
このため、本発明による録画予約方法では、放送番組データを受信する放送受信ステップと、前記放送番組データを録画する録画ステップと、前記放送番組の録画を予約登録するステップと、前記予約登録ステップによって登録された予約対象番組を記録する予約実行ステップと、ネットワークとの通信を行う通信ステップと、を備えた予約録画方法において、前記通信ステップは、第一の番組識別子によって特定される放送番組の代行予約登録指示を前記ネットワークから受信する代行予約登録受信ステップと、第二の番組識別子によって特定される放送番組の録画データ送信指示を前記ネットワークから受信する録画データ送信指示受信ステップと、前記第二の番組識別子によって特定される放送番組の録画データを再生して前記ネットワークに送信する録画データ送信ステップと、からなり、前記予約登録ステップは前記代行予約登録受信ステップで受信した前記第一の番組識別子で特定される放送番組を予約登録する、ことを特徴としている。
【００１５】
更に本発明による録画予約方法では、予約対象番組をユーザに指示させる予約指示ステップを備え、前記予約登録ステップは、前記予約指示ステップによってユーザから指示される番組の方を、前記代行予約登録受信ステップで受信した前記ネットワークから受信する前記代行予約登録指示よりも優先して予約登録すること、を特徴としている。
【００１６】
更に、前記ネットワークは、前記代行予約登録の内容を一元的に管理する予約管理サーバと、前記予約管理サーバに前記代行予約登録を依頼する複数の代行予約依頼装置と、複数の前記予約録画装置と、から構成されるハイブリッド型型ピア・ツゥ・ピアネットワークであることを特徴としている。
【００１７】
更に、前記ネットワークは、前記代行予約登録を依頼する複数の代行予約依頼装置と、複数の前記予約録画装置と、から構成されるピュア型ピア・ツゥ・ピアネットワークであることを特徴としている。
【００１８】
【発明の実施の形態】
以下、本発明による放送の予約録画の実施の形態について、図面を用いて説明する。図１に本発明の第一の実施例であるハイブリッド型Ｐ２Ｐによる録画予約システムの全体のブロック図を示す。このシステムでは、１台の予約管理サーバ１９０と、複数台のノード１１０、１２０、および１３０が、インターネット１００で接続されている。ノード１１０、１２０、および１３０の実体は、各ユーザが所有する放送受信機であり、ＢＳデジタル放送などを受信するチューナ１１２、受信した放送を録画するＶＴＲやＨＤＤ等の蓄積装置１１３、予約番組の情報を保持する予約メモリ１１４、予約番組の録画実行を管理するタイマ１１５、インターネットに接続するためのＡＤＳＬモデムやＬＡＮアダプタ等のネットワークコントローラ１１６、および、これらすべてを制御する制御マイコン１１１から構成されている。
【００１９】
一方、予約管理サーバ１９０は、各ノードから要求された予約要求や全ノードの予約登録状況を管理するデータベース１９３と、インターネットに接続するためのＡＤＳＬモデムやＬＡＮアダプタ等のネットワークコントローラ１９２、および、これらすべてを制御する制御ＣＰＵ１９１から構成されている。
【００２０】
図２は、この録画予約システムにおける予約登録動作のフローチャートである。図２の左側のチャートが予約登録を行うノード（クライアントノードと呼ぶ）の制御手順を、真中のチャートが予約管理サーバの制御手順を、右側のチャートがクライアントノードの代わりに録画予約を行うべくサーバに選択されたノード（代行ノードと呼ぶ）の制御手順をそれぞれ表している。
【００２１】
まず、クライアントノードにおいて、ユーザが電子番組ガイド（ＥＰＧ）等で希望する予約対象の番組を選択すると、ステップＣ２０１で予約メモリ１１４を検索してその時間に既に別の番組が予約済みか否かを検索する。何も予約が登録されていないか、あるいは、登録済みの場合でもそれが別のクライアントからの予約要求を代行ノードとして請け負ったもの（代行予約と呼ぶ）である場合は、自分自身によってなされた予約（ローカル予約と呼ぶ）の方を優先して新規の予約登録が可能である。この場合はネットワークに対して代行予約を要求する必要は無く、後述するローカル予約登録処理を行う。
【００２２】
一方、既に同一時間帯に別のローカル予約が登録済みの場合には、自分で録画を行うことが不可能な裏番組であるから、予約管理サーバに対して代行予約の要求を行う（ステップＣ２０３）。
【００２３】
予約管理サーバではステップＳ２０１においてこの代行予約要求を受信すると、データベース１９３を検索して、当該番組の予約が既に登録されているか調べる（ステップＳ２０２）。未登録の場合は、データベース１９３に登録された全ノードの中から、当該時間帯にまだ予約登録されていない空きノードを抽出し（ステップＳ２０４）、代行予約の登録を指示し（ステップＳ２０５）。代行ノードからのレスポンスを待つ（ステップＳ２０６）。
【００２４】
一般のノードでは、常に予約管理サーバからの代行予約の登録指示を受信できるよう待ち受けている。ステップＰ２０１でこの指示が受信されると、自分が代行ノードとして選択されたことを知る。ステップＰ２０２で、予約メモリ１１４を検索して当該時間帯に代行予約が可能であるかを判定する（ステップＰ２０３）。予約管理サーバは空きノードから代行ノードを選択しているので、通常は代行予約可能となり、予約内容（時間帯、チャンネル等）を予約メモリ１１４への登録し、タイマ１１５を起動（ステップＰ２０５）した後で、予約管理サーバに登録成功のレスポンスを送信する（ステップＰ２０５）。
【００２５】
予約管理サーバは、登録成功のノードに関しては、そのＩＰアドレスなどをデータベース１９３に登録する（ステップＳ２０７）。
【００２６】
しかし、サーバが把握している予約登録状況よりも後に、その代行ノードのユーザによってローカル予約が登録されていた場合などは、代行予約不能であるので、登録失敗のレスポンスが送られてくる。また、その代行ノードの電源がオフであったり、ネットワークに接続されていない場合などで、予約管理サーバからの代行予約指示が受け取れなかった場合は、予約管理サーバはレスポンスを受信できないので、タイムアウト処理を行って登録失敗とみなす。
【００２７】
なお、上記のように、一度代行予約を受け付けた後でもユーザがローカル予約を登録することが可能であるため、同一の予約内容を複数の代行ノードに対して登録しておき、出来る限り代行予約が実行されるようにしておく。このため、ステップＳ２０８では、代行予約の登録に成功したノードの数が規定の数に達するまでステップＳ２０４からＳ２０７までをループさせる。規定数に到達した場合は、後でデータベース１９３から情報を引き出すための予約番号を、要求元のクライアントノードに送信する（ステップＳ２０９）。また、図示していないが、規定数に達するより先にステップＳ２０４で空きノードが見つからなくなった場合には、予約登録不可である旨をクライアントノードに伝える処理も行う。
【００２８】
クライアントノードでは、ステップＣ２０４においてこの予約番号を受信し、予約メモリ１１４に記憶する（ステップＣ２０５）。
【００２９】
一方、ステップＳ２０３において、既に同一番組の予約が登録済みのときには、改めて代行ノードに予約登録を行う必要は無いので、その予約内容の要求数を１  増やすだけでよい（ステップＳ２１０）。この要求数は、後でクライアントが代行予約をキャンセルしてきた場合には逆に１減ぜられる。その結果、要求数が０になれば、その予約に関連した代行ノード全ての予約を取り消して、空きノードとして別の予約に備えさせることができる。逆に、要求数が大きくなったときは、それだけ予約が失敗したときの被害が増大したことを意味しているため、ある規定数を超える毎に新たな代行ノードを追加して、の代行予約を指示すようようにしても良い。
【００３０】
次に、既に別のクライアントの代行ノードとして登録されているクライアントノードに対するローカル予約登録処理について、図３のフローチャートを基に説明する。
【００３１】
まずステップＣ３０１で予約メモリ１１４を検索して、ユーザが電子番組ガイド（ＥＰＧ）等で選択した予約対象の番組の時間帯に競合する別の番組が代行予約登録されているか調査する。既に登録されていた場合でも、そのノードの所有者からの要求であるローカル予約の方が優先される。その場合は、ステップＣ３０４で予約管理サーバに代行予約の実行が不可能になったことを通知して予約再手配処理を起動させてから、ステップＣ３０５で予約メモリ１１４から消去する。
【００３２】
予約管理サーバの予約再手配処理では、ステップＳ３０１においてこの代行予約不能通知を受信すると、データベース１９３内の当該予約代行ノードの数から１を減ずる（ステップＳ３０２）。この結果、ステップＳ３０３で代行ノード数が規定数より少なくなったことを検出すると、新たな代行ノードを追加登録するために、図２  のフローチャートに示した予約登録処理を再び実行する。
【００３３】
一方、クライアントのステップＣ３０５で代行予約を消去した後、および、ステップＣ３０２で代行予約が未登録だった場合には、ステップＳ３０６でユーザの指定した番組をローカル予約として予約メモリ１１４に登録する。続いて、ステップＣ３０７  で、当該番組の情報を予約管理サーバに通知して、ローカル予約登録処理を起動する。
【００３４】
予約管理サーバのローカル予約登録処理では、ステップＳ３１１でクライアントノードから受信した番組情報が、別のクライアントからの代行予約としても共用できるか否かをデータベース１９３を検索して判定する（ステップＳ３１２）。既に登録済みの代行予約と一致した場合は、その予約の代行ノードとしてクライアントのＩＰアドレス等を追加登録し、代行ノード数に１を加える（ステップＳ３１５）。一方、当該番組への代行予約要求がまだ登録されていない場合でも、後で要求が来たときにもすぐに受け付けられるように予め登録しておいても良い（ステップＳ３１４）。
【００３５】
以上、図２および図３を基に説明した手順によって、各ノードには、ユーザから直接に登録されたローカル予約と、予約管理サーバを経由して別のクライアントから登録された代行予約の両方が存在する。どちらの予約の場合においても、タイマ１１５によって予約対象番組の開始時刻に予約録画処理を実行する。このとき、例えばＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）−２方式による圧縮を行ったデジタルデータを蓄積装置１１３に格納する。
【００３６】
次に、クライアントノードが代行ノードから予約録画済みのデータを回収して視聴を行う手順について、図４に示すフローチャートを基に説明する。
【００３７】
まずクライアントはステップＣ４０１で、予約メモリ１１４に記憶された予約番号を予約管理サーバに通知して、代行ノードの情報を問い合わせる。予約管理サーバでは、ステップＳ４０１でこの問合せを受けると、データベース１９３を検索して当該予約を代行した代行ノードの中から１つを選択して、そのＩＰアドレス等の情報をクライアントに返信する（ステップＳ４０２）。
【００３８】
クライアントは、ステップＣ４０３で通知された代行ノードに対して、Ｐ２Ｐによる直接のデータ転送を試みる（ステップＣ４０４，Ｃ４０５）。Ｐ２Ｐ転送要求を受けた代行ノードでは、当該番組の予約録画が成功していればそのＭＰＥＧ圧縮されたデータを蓄積装置１１３から取り出してクライアントに送信する（ステップＰ４０１，Ｐ４０２）。ただし、予約録画の実行時に電波障害や停電などがあって録画が失敗した場合や、ユーザの割り込み操作によって予約がキャンセルされていた場合などには、予約失敗である旨をクライアントに送信する。
【００３９】
クライアントではステップＣ４０６でこのような予約失敗を検出したときや、あるいは代行ノードの電源断やネットワーク不要などによってＰ２Ｐ通信ができないことを検出すると、ステップＣ４０２からＣ４０５を繰り返し実行して別の代行ノードの情報を予約管理サーバから取得して再びＰ２Ｐ転送を試みる。録画番組データの取得に成功すれば、そのデータのＭＰＥＧデコードを行って、番組を再生する（ステップＣ４０７）。
【００４０】
以上説明したように、ネットワーク上に設置した予約管理サーバが各クライアントからの代行予約要求を受け付けて、代行ノードに対して代行予約を指示することで、自分では録画できない裏番組の代行予約をネットワーク上の余剰資源を用いて実行することができる。また、録画データの入手にあたっては、予約管理サーバを介さないノード間のＰ２Ｐ転送で行われるため、ネットワークのボトルネックの影響を受けない。
【００４１】
さらに、一つの代行予約要求に対して、複数の代行ノードを用意することにより、突然のユーザの割り込みや電波障害などによる録画失敗の可能性を低減することを可能にしている。
【００４２】
なお、本実施例では簡単のために、代行ノードが録画したデータを不特定多数のクライアントノードに分配可能な構成とした。しかし、録画対象のコンテンツの著作権保持者が無制限の複製を許可していないような場合や、コンテンツの配信を有料化したい場合などもある。そのような場合には、図４の手順の中で、例えば、ステップＳ４０２の代行ノード情報送信の時点で課金を行ったり、限定したクライアントだけに分かるように暗号化したりすれば良い。あるいは、代行ノードでは放送時にかけられたスクランブルを解除せずにそのまま蓄積しておき、クライアントがＰ２Ｐ通信よってデータを取得してから自分でスクランブルを解除させて、このとき課金されるようにしても良い。
【００４３】
また、本実施例では代行ノードの予約録画実行時に少しでも電波障害等による録画失敗が発生したら全体が失敗として扱っていたが、そのような場合にも、例えばステップＰ４０２において、録画成功した部分を、その開始時刻と終了時刻などのタイムインデックス情報とともに部分的にクライアントに送信させることもできる。クライアントでは、複数の代行ノードからそのような断片を集めて、全体を再構成すれば良い。
【００４４】
次に、本発明の第二の実施例であるピュア型Ｐ２Ｐによる録画予約システムについて説明する。図５は本システムの全体ブロック図であり、図１と同一の部分には同一番号を付す。このシステムでは、第一の実施例とは異なり、中央の予約管理サーバというものは存在せず、互いに対等な複数台のノード１１０、１２０、および１３０が、インターネット１００で接続されている。ノード１１０、１２０、および１３０の実体は、図１と同様に各ユーザが所有する放送受信機であり、内部構成も図１と同じであるため説明を省略する。
【００４５】
これらのノードは、図６の論理ネットワーク図に示すＰ２Ｐネットワークを構成しているものとする。ここでは例として、各ノードは３つの隣接ノードと接続されているものとする。このとき、あるノード６００からＰ２Ｐネットワークへの検索要求などの要求を発行した場合の情報の伝達方法の例について説明する。
【００４６】
起点となるノード６００からは、３つの隣接ノードのうち、ランダムに選んだ２つのノード６０１と６０３に対して要求を送信する。このとき、Ｐ２Ｐ  ネットワーク内での要求の生存期間を指定する値ＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）を例えば２  としておく。なお、実線の矢印が送信されるノードを示し、破線の矢印は送信されないノードを示している。
【００４７】
次に、この検索要求を受け取ったノード６０１およびノード６０３では、まず指示された検索条件に適合する情報が自ノード内に存在すれば、それを検索結果としてノード６０１に送り返す。適合する情報がなければ、さらに次段の隣接ノードから任意の２つ選択して転送しようとする。ただし、転送の前にＴＴＬ値をチェックし、この値が０であれば転送を行わない。この例ではＴＴＬが１であるので転送が行われる。ノード６０１からはノード６１１と６１３に、また、ノード６０３からはノード６１４と６１６に送信される。このときＴＴＬ値から１を減じておく。
【００４８】
さらに同様にして、ノード６１１，６１３，６１４，６１６では、自ノード内の情報を検索すると共に、適合する情報がなければ、さらに次段の隣接ノードから任意の２つ選択して転送しようとする。このとき、ＴＴＬ値が既に０であるので転送は行われない。
【００４９】
以上のようにして、インターネットを介して接続された複数のノードが隣接ノードとの間で情報を転送するＰ２Ｐネットワークが構築される。なお、この例で用いた隣接ノードの接続数や転送時の選択方法、およびＴＴＬ値の初期値などは一例であり、他の方法でも構わない。
【００５０】
さて、このようなＰ２Ｐネットワークを用いて、裏番組予約の登録を行う手順を述べる。図７は、この録画予約システムにおける予約登録動作のフローチャートである。図７の左側のチャートが予約登録を行うクライアントノードの制御手順を、真中のチャートがクライアントノードの隣接ノードの制御手順を、右側のチャートがさらにその隣の隣接ノードの制御手順をそれぞれ表している。ただし、どちらの隣接ノードの制御手順も同じであるため、同一部分には同一の番号を付してある。
【００５１】
まず、クライアントノードにおいて、ユーザが電子番組ガイド（ＥＰＧ）等で希望する予約対象の番組を選択すると、ステップＣ７０１で予約メモリ１１４を検索してその時間に既に別の番組が予約済みか否かを検索する。既に同一時間帯に別のローカル予約が登録済みの場合には、自分で録画を行うことが不可能な裏番組であるから、Ｐ２Ｐネットワークの隣接ノードに対して代行予約の要求を行う（ステップＣ７０３）。
【００５２】
隣接ノードではステップＮ７０１においてこの代行予約要求を受信すると、自分の予約メモリ１１４を検索して、当該番組の予約が可能かを調べる（ステップＮ７０２）。当該時間帯に何も予約が無い場合は、新規の予約登録として予約内容（時間帯、チャンネル等）を予約メモリ１１４への登録し、タイマ１１５を起動（ステップＮ７０４）  する。次に、ステップＮ７０３での予約登録可否の判定結果に関わらず、受信した代行要求のＴＴＬ値を調べ（ステップＮ７０５）、０より大きければＴＴＬ値から１を減じた後に代行要求を隣接ノードに対して転送する（ステップＮ７０６，Ｎ７０７）。この転送された要求を受けた隣接ノードでは、上記の手順（ステップＮ７０１乃至Ｎ７０７）を繰り返し、ＴＴＬが０になるまで隣接ノードへバケツリレー式に転送を続ける。
【００５３】
このように、代行予約を受け付けたか否かにかかわらず隣接ノードへ転送を続けるため、ネットワーク上の複数のノードに同一の内容の代行予約を登録されることになる。
【００５４】
一方、最初のクライアントノードのステップＣ７０２において、ユーザの指示した番組を自分で録画できると判定された場合は、ステップＣ７０４に進む。
【００５５】
ステップＣ７０４では、当該時間帯に競合する別の番組が代行予約登録されているか調査する。既に登録されていた場合でも、そのノードの所有者からの要求であるローカル予約の方が優先される。その場合は、ステップＣ７０６で登録されていた代行予約を消去する。なお、ステップＣ７０５で、登録されていた代行予約の内容と同じ内容の要求をＰ２Ｐネットワークに要求するようにして、代行予約が失敗する可能性を低減させても良い。
【００５６】
いずれの場合でも、ステップＣ７０７で、ユーザの番組の内容が予約メモリ１１４に登録される。
【００５７】
以上、説明した手順によって、各ノードには、ユーザから直接に登録されたローカル予約と、Ｐ２Ｐネットワークを経由して別のクライアントから登録された代行予約の両方が存在する。どちらの予約の場合においても、タイマ１１５によって予約対象番組の開始時刻に予約録画処理を実行して、ＭＰＥＧデータを蓄積装置１１３に格納する。
【００５８】
次に、クライアントノードが代行ノードから予約録画済みのデータを回収して視聴を行う手順について、図８に示すフローチャートを基に説明する。
【００５９】
まずクライアントはステップＣ８０１で、予約メモリ１１４に記憶された予約情報（番組タイトルやチャンネル番号、予約時刻など）を取り出し、Ｐ２Ｐネットワークに対して検索要求を行う（ステップＣ８０２）。
【００６０】
隣接ノードでは、ステップＮ８０１でこの問合せを受けると、予約メモリ１１４  を検索して自ノードにその録画データが存在するか否かをチェックする（ステップＮ８０２）。自ノードに録画データが存在した場合は、検索結果として自分のＩＰアドレスをクライアントに送り返す（ステップＮ８０７）。一方、自ノードに録画データが存在しない場合は、隣接ノードに問い合わせるために、まず受信した検索要求のＴＴＬ値を調べ（ステップＮ８０３）、０より大きければＴＴＬ値から１を減じた後に検索要求を隣接ノードに対して転送する（ステップＮ８０４，Ｎ８０５）。次にステップＮ８０６で隣接ノードからの検索結果を待つ。ステップＮ８０７では、検索条件に適合した結果が受信されれば、それを要求元に送り返す。あるいは、全ての隣接ノードから該当なしとの結果が得られれば、それを要求元に送り返す。なお、検索要求を転送された隣接ノードでは、上記の手順（ステップＮ８０１乃至Ｎ８０８）を繰り返し、ＴＴＬが０になるまで隣接ノードへバケツリレー式に転送を続け、検索結果を逆向きの方向に送り返す。
【００６１】
以上のようにして、Ｐ２Ｐネットワーク内で当該録画データを検索した結果が、ステップＣ８０３でクライアントに受信される。検索の結果、録画データを発見できた場合には、クライアントは、ステップＣ８０３で通知された代行ノードに対して、Ｐ２Ｐによる直接のデータ転送を試みる（ステップＣ８９０，Ｃ８９１）。Ｐ２Ｐ転送要求を受けた代行ノードでは、そのＭＰＥＧ圧縮されたデータを蓄積装置１１３から取り出してクライアントに送信する（ステップＮ８９０，Ｎ８９１）。
【００６２】
クライアントでは、代行ノードの電源断やネットワーク不要などによってステップＣ８９１でＰ２Ｐ通信ができないことを検出すると、ステップＣ８０２からＣ８０３を繰り返し実行して別の代行ノードの情報をＰ２Ｐネットワークから取得して再びＰ２Ｐ転送を試みる。録画番組データの取得に成功すれば、そのデータのＭＰＥＧデコードを行って、番組を再生する（ステップＣ８９３）。
【００６３】
以上説明したように、Ｐ２Ｐネットワークの隣接ノードに対して代行予約を送信することで、自分では録画できない裏番組の代行予約をネットワーク上の余剰資源を用いて実行することができる。また、録画データの入手にあたっては、ノード間のＰ２Ｐ転送で行われるため、ネットワークのボトルネックの影響を受けない。
【００６４】
さらに、一つの代行予約要求に対して、複数のノードが代行ノードとして機能することにより、突然のユーザの割り込みや電波障害などによる録画失敗の可能性を低減することを可能にしている。
【００６５】
なお、本実施例においても、録画対象のコンテンツの有料配信を行いたい場合などは、第一の実施例と同様の方法が利用できる。すなわち、代行ノードでは放送時にかけられたスクランブルを解除せずにそのまま蓄積しておき、クライアントがＰ２Ｐ通信よってデータを取得してから自分でスクランブルを解除させて、このとき課金されるようにする。
【００６６】
また、受信障害などで部分的に録画に失敗した場合は、ステップＮ８０６における検索結果の返信時に、録画成功した部分の開始時刻と終了時刻などのタイムインデックス情報として送り返すこともできる。クライアントでは、複数の代行ノードからそのような断片を集めて、全体を再構成すれば良い。
【００６７】
本発明によれば、ユーザが自分で録画することが不可能な裏番組をネットワーク上の余剰資源を利用して録画予約することができる。また、Ｐ２Ｐネットワーク技術を利用しているため、中央に高価なサーバを用意すること無く、比較的簡単にシステムを構築できるとともに、サーバがダウンしたときにシステム全体が使用不可能になるという事態を避けることができる。
【００６８】
【発明の効果】
本発明によれば、ユーザにとって使い勝手の良い録画システムを提供できる。
【図面の簡単な説明】
【図１】本発明の第１の実施例による録画予約システム全体のブロック図
【図２】本発明の第１の実施例による録画予約方法の予約登録処理の制御手順
【図３】本発明の第１の実施例による録画予約方法の予約再手配処理の制御手順
【図４】本発明の第１の実施例による録画予約方法の録画検索処理の制御手順
【図５】本発明の第２の実施例による録画予約システム全体のブロック図
【図６】本発明の第２の実施例による録画予約システムのネットワークの論理的接続図
【図７】本発明の第２の実施例による録画予約方法の予約登録処理の制御手順
【図８】本発明の第２の実施例による録画予約方法の録画検索処理の制御手順
【符号の説明】１００…インターネット、１１０，１２０，１３０…放送受信機、１９０…予約管理サーバ、１１１…制御マイコン、１１２…チューナ、１１３…蓄積装置、１１４…予約メモリ、１１５…タイマ、１１６…ネットワークコントローラ、１９１…制御ＣＰＵ、１９２…ネットワークコントローラ、１９３…予約管理データベース
【図１】
2005006041.tif 000003
【図２】
2005006041.tif 000004
【図３】
2005006041.tif 000005
【図４】
2005006041.tif 000006
【図５】
2005006041.tif 000007
【図６】
2005006041.tif 000008
【図７】
2005006041.tif 000009
【図８】
2005006041.tif 000010