(57)【要約】【課題】放送コンテンツをサーバから受信してクライアントで記録する構成において、録画予約に基づく録画実行処理などの改良された構成を提供する。【解決手段】サーバがクライアントから入力する録画予約情報に基づく録画予約リストを生成してクライアントに提供する。クライアントは予約リストの記録情報に基づいて録画コンテンツの取得要求を実行する。サーバは時間の重複する複数のコンテンツ取得要求データからコンテンツ送信の実行対象を選択し送信許諾応答を行い、その他の要求に対して要求が実行されないことを示す応答を行なう。また、録画予約リストにサーバ側で決定した録画実行時間や、放送受信部の受信した現在時刻情報を記録し、これらの情報に基づく正確なコンテンツ取得要求を実現する。【選択図】図２
2008199436.tif 000002
【特許請求の範囲】
【請求項１】
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバと、前記サーバから受信するデータの再生または記録を行なうクライアントとを有する通信システムであり、
前記サーバは、
放送データを受信する放送受信部と、
前記クライアントから入力する録画予約情報に基づく録画予約リストを生成するサーバ録画予約情報管理部を有し、
前記クライアントは、
前記サーバから前記録画予約リストを取得するクライアント録画予約情報管理部と、
前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行する録画処理部を有し、
前記サーバ録画予約情報管理部は、
ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領し、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データの応答としてコンテンツ送信許諾応答を行い要求コンテンツの送信を行なうとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なう構成であることを特徴とする通信システム。
【請求項２】
前記クライアントの録画処理部は、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信し、
前記サーバ録画予約情報管理部は、
前記クライアントからのコンテンツ取得要求に応じたコンテンツ送信を実行するか否かを予め設定された選択アルゴリズムを実行して決定する構成であることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記サーバ録画予約情報管理部は、
前記録画予約リストの更新がなされた場合に、更新がなされたことを示す更新通知を前記クライアントに送信する構成であることを特徴とする請求項１に記載の通信システム。
【請求項４】
前記サーバは、さらに、
放送コンテンツの放送時間の変更に基づく前記録画予約リストの更新の必要性を判断する情報更新監視部を有し、
前記サーバ録画予約情報管理部は、
前記情報更新監視部からの前記録画予約リストの更新の必要性ありとの判断に基づいて前記録画予約リストの更新処理を行なう構成であることを特徴とする請求項１に記載の通信システム。
【請求項５】
前記サーバ録画予約情報管理部は、
前記録画予約リスト中に、録画予約番組の放送開始時間情報と、サーバ側で決定した録画実行開始時間情報を記録する構成であることを特徴とする請求項１に記載の通信システム。
【請求項６】
前記クライアントの録画処理部は、
前記録画予約リストに記録された録画実行開始時間情報に基づいてサーバに対するコンテンツ取得要求の出力タイミングを決定する処理を実行する構成であることを特徴とする請求項５に記載の通信システム。
【請求項７】
前記サーバは、さらに、
前記放送波受信部が受信した現在時刻情報を保存し管理を行うサーバ時刻情報管理部を有し、
前記サーバ録画予約情報管理部は、
前記サーバ時刻情報管理部の取得した現在時刻情報を録画予約リストに記録してクライアントに提供する構成であることを特徴とする請求項１に記載の通信システム。
【請求項８】
前記クライアントは、
前記録画予約リストに記録された現在時刻情報と、クライアントに備えられた時計との差分を算出するクライアント時刻情報管理部を有し、
クライアントの前記録画処理部は、前記録画予約リストに記録された録画予約番組に対応する時間情報と、前記クライアント時刻情報管理部から提供される差分情報とに基づいて、録画処理の実行タイミングを決定する処理を行なう構成であることを特徴とする請求項７に記載の通信システム。
【請求項９】
前記サーバは、
前記クライアントに送信するデータに対して設定するタイムスタンプの値を決定するタイムスタンプ管理部を有し、
前記クライアントは、
前記サーバから受信するデータの復号処理および記憶部に記憶されるデータのタイムスタンプの値を保持するクライアント暗号処理部を有し、
前記クライアントの録画処理部は、
前記サーバとの通信中断の後のコンテンツ送信要求の出力に際し、前記クライアント暗号処理部の保持するタイムスタンプの値を適用して、サーバにおけるコンテンツ送信再開時のデータに設定するタイムスタンプの値を開始タイムスタンプ値として決定し、該開始タイムスタンプ値をサーバに通知する処理を実行する構成であることを特徴とする請求項１に記載の通信システム。
【請求項１０】
前記サーバのタイムスタンプ管理部は、
前記クライアントから受信したデータに含まれる開始タイムスタンプ値に基づいて、通信中断後の送信データに設定するタイムスタンプの値を決定する処理を行なう構成であることを特徴とする請求項９に記載の通信システム。
【請求項１１】
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバとしての情報処理装置であり、
放送データを受信する放送受信部と、
前記クライアントから入力する録画予約情報に基づく録画予約リストを生成するサーバ録画予約情報管理部を有し、
前記サーバ録画予約情報管理部は、
ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領し、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データの応答としてコンテンツ送信許諾応答を行い要求コンテンツの送信を行なうとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なう構成であることを特徴とする情報処理装置。
【請求項１２】
前記サーバ録画予約情報管理部は、
前記クライアントからのコンテンツ取得要求に応じたコンテンツ送信を実行するか否かを予め設定された選択アルゴリズムを実行して決定する構成であることを特徴とする請求項１１に記載の情報処理装置。
【請求項１３】
前記サーバ録画予約情報管理部は、
前記録画予約リストの更新がなされた場合に、更新がなされたことを示す更新通知を前記クライアントに送信する構成であることを特徴とする請求項１１に記載の情報処理装置。
【請求項１４】
前記情報処理装置は、さらに、
放送コンテンツの放送時間の変更に基づく前記録画予約リストの更新の必要性を判断する情報更新監視部を有し、
前記サーバ録画予約情報管理部は、
前記情報更新監視部からの前記録画予約リストの更新の必要性ありとの判断に基づいて前記録画予約リストの更新処理を行なう構成であることを特徴とする請求項１１に記載の情報処理装置。
【請求項１５】
前記サーバ録画予約情報管理部は、
前記録画予約リスト中に、録画予約番組の放送開始時間情報と、サーバ側で決定した録画実行開始時間情報を記録する構成であることを特徴とする請求項１１に記載の情報処理装置。
【請求項１６】
前記情報処理装置は、さらに、
前記放送波受信部が受信した現在時刻情報を保存し管理を行うサーバ時刻情報管理部を有し、
前記サーバ録画予約情報管理部は、
前記サーバ時刻情報管理部の取得した現在時刻情報を録画予約リストに記録してクライアントに提供する構成であることを特徴とする請求項１１に記載の情報処理装置。
【請求項１７】
前記情報処理装置は、
前記クライアントに送信するデータに対して設定するタイムスタンプの値を決定するタイムスタンプ管理部を有し、
前記タイムスタンプ管理部は、
前記クライアントから受信したデータに含まれる開始タイムスタンプ値に基づいて、通信中断後の送信データに設定するタイムスタンプの値を決定する処理を行なう構成であることを特徴とする請求項１１に記載の情報処理装置。
【請求項１８】
サーバにおいて受信された放送データを受信し、受信データの再生または記録を行なうクライアントとしての情報処理装置であり、
クライアントから入力される録画予約情報に基づいて前記サーバにおいて生成された録画予約リストを前記サーバから取得するクライアント録画予約情報管理部と、
前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行する録画処理部を有し、
前記録画処理部は、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信する構成であることを特徴とする情報処理装置。
【請求項１９】
前記サーバの生成する録画予約リストは、録画予約番組の放送開始時間情報と、サーバ側で決定した録画実行開始時間情報が記録された構成であり、
前記録画処理部は、
前記録画予約リストに記録された録画実行開始時間情報に基づいてサーバに対するコンテンツ取得要求の出力タイミングを決定する処理を実行する構成であることを特徴とする請求項１８に記載の情報処理装置。
【請求項２０】
前記サーバの生成する録画予約リストは、サーバの放送波受信部が受信した現在時刻情報が記録された構成を有し、
前記情報処理装置は、
前記録画予約リストに記録された現在時刻情報と、クライアントに備えられた時計との差分を算出するクライアント時刻情報管理部を有し、
前記録画処理部は、前記録画予約リストに記録された録画予約番組に対応する時間情報と、前記クライアント時刻情報管理部から提供される差分情報とに基づいて、録画処理の実行タイミングを決定する処理を行なう構成であることを特徴とする請求項１８に記載の情報処理装置。
【請求項２１】
前記情報処理装置は、
前記サーバから受信するデータの復号処理および記憶部に記憶されるデータのタイムスタンプの値を保持するクライアント暗号処理部を有し、
前記録画処理部は、
前記サーバとの通信中断の後のコンテンツ送信要求の出力に際し、前記クライアント暗号処理部の保持するタイムスタンプの値を適用して、サーバにおけるコンテンツ送信再開時のデータに設定するタイムスタンプの値を開始タイムスタンプ値として決定し、開始タイムスタンプ値をサーバに通知する処理を実行する構成であることを特徴とする請求項１８に記載の情報処理装置。
【請求項２２】
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバとしての情報処理装置において実行する情報処理方法であり、
放送受信部が、放送データを受信する放送受信ステップと、
サーバ録画予約情報管理部が、前記クライアントから入力する録画予約情報に基づく録画予約リストを生成するステップと、
前記サーバ録画予約情報管理部が、ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領し、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データの応答としてコンテンツ送信許諾応答を行い要求コンテンツの送信を行なうとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なうステップと、
を実行することを特徴とする情報処理方法。
【請求項２３】
サーバにおいて受信された放送データを受信し、受信データの再生または記録を行なうクライアントとしての情報処理装置において実行する情報処理方法であり、
クライアント録画予約情報管理部が、クライアントから入力される録画予約情報に基づいて前記サーバにおいて生成された録画予約リストを前記サーバから取得する録画予約情報管理ステップと、
録画処理部が、前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行する録画処理ステップを有し、
前記録画処理ステップは、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信するステップを含むことを特徴とする情報処理方法。
【請求項２４】
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバとしての情報処理装置において情報処理を実行させるコンピュータ・プログラムであり、
放送受信部に、放送データを受信させる放送受信ステップと、
サーバ録画予約情報管理部に、前記クライアントから入力する録画予約情報に基づく録画予約リストを生成させるステップと、
前記サーバ録画予約情報管理部に、ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領させ、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択させ、選択された要求データの応答としてコンテンツ送信許諾応答を行わせて要求コンテンツの送信を行なわせるとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なわせるステップと、
を実行させることを特徴とするコンピュータ・プログラム。
【請求項２５】
サーバにおいて受信された放送データを受信し、受信データの再生または記録を行なうクライアントとしての情報処理装置において情報処理を実行させるコンピュータ・プログラムであり、
クライアント録画予約情報管理部に、クライアントから入力される録画予約情報に基づいて前記サーバにおいて生成された録画予約リストを前記サーバから取得させる録画予約情報管理ステップと、
録画処理部に、前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行させる録画処理ステップを有し、
前記録画処理ステップは、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信させるステップを含むことを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、情報処理装置、および情報処理方法、並びにコンピュータ・プログラムに関する。さらに、詳細には、チューナを有するサーバ（ネットワークチューナ）が、チューナによって受信したデータをネッワーク接続されたクライアントに提供して、クライアント側で再生や記録処理を行なう通信システム、情報処理装置、および情報処理方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００２】
昨今のデータ通信ネットワークの普及に伴い、家庭内においても家電機器やコンピュータ、その他の周辺機器をネットワーク接続し、各機器間での通信を可能とした、いわゆるホームネットワークが浸透しつつある。ホームネットワークは、ネットワーク接続機器間で通信を行なうことにより各機器のデータ処理機能を共有することを可能とするものである。ネットワーク接続機器間のコンテンツ送受信等、ユーザに利便性・快適性を提供するものであり、今後、ますます普及することが予測される。
【０００３】
チューナにおいて受信した放送データをこのようなホームネットワークを介してネットワーク接続されたＰＣやディスプレイなどの機器に配信し、チューナとは異なる場所の機器において放送コンテンツを再生するといったことも可能となる。
【０００４】
昨今、放送コンテンツを含むＡＶコンテンツの多くがデジタル化されて提供されているが、デジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易であることから、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する対策が必要となっており、デジタル・コンテンツの著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準として、ＤＴＬＡ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｉｃｅｎｓｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）がある。ＤＴＣＰにおいては著作権が保護された形でコンテンツを伝送させるための仕組みについて規定されている（例えば、非特許文献１を参照のこと）。
【０００５】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００６】
コンテンツ提供元であるサーバ（ＤＴＣＰ  Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ  Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。
【０００７】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホームネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。しかしながら、最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ）に代表されるように、デジタル化されたＡＶコンテンツをＩＰネットワークを用いて家庭内で流通させようという動きが本格的になっていることから、ＩＰネットワークに対応したＤＴＣＰ技術、すなわちＩＰパケットを利用してＤＴＣＰ規格に従ったコンテンツ流通を実現させるＤＴＣＰＩＰ（ＤＴＣＰ  ｏｖｅｒ  ＩＰ）規格が提唱されており、この規格に従った機器が、今後のホームネットワーク機器の主流になると予測される。
【０００８】
ホームネットワークの多くはルータなどを経由してインターネットなどの外部のＩＰネットワークに接続されると、コンテンツの不正コピーや改竄の危惧が指摘されるが、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られることになる。
【０００９】
ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれ、ＤＴＣＰ技術をＩＰネットワークに移植した技術であり、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送に適用するプロトコルなどについて規定されている。ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送する詳細な規定を有している（例えば、非特許文献２を参照のこと）。
【００１０】
ここで、ＤＴＣＰ−ＩＰに準拠したコンテンツ伝送について説明する。ＤＴＣＰ−ＩＰに準拠したソース（Ｓｏｕｒｃｅ）機器およびシンク（Ｓｉｎｋ）機器間でＨＴＴＰプロトコルを利用したコンテンツ伝送を実施する場合について説明する。ソースは例えばコンテンツを提供するサーバ、シンクはサーバからコンテンツを受信するクライアントである。ソース（Ｓｏｕｒｃｅ）機器およびシンク（Ｓｉｎｋ）機器間では、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ストリームのような長大なバイト・ストリームを伝送の途中でコンテンツ鍵を変更しながら暗号化通信が行なわれ、且つ、暗号化コンテンツの復号処理その他のコンテンツ処理を実施する際にコンテンツ鍵の確認手続きが行なわれる。また、相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立される。
【００１１】
具体的には、ＡＫＥ手続きが成功すると、ソース（ＤＴＣＰ＿Ｓｏｕｒｃｅ）機器とシンク（ＤＴＣＰ＿Ｓｉｎｋ）機器は、認証鍵Ｋａｕｔｈを共有することができ、それぞれ内部で同様の処理を行なってＫａｕｔｈからコンテンツ鍵の種となる種鍵Ｋｘを生成する。Ｓｏｕｒｃｅ機器は、乱数を用いてノンスＮｃを生成して、ＫｘとＮｃを基にコンテンツ鍵Ｋｃを生成する。そして、Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋｃを用いて暗号化し、暗号化コンテンツとノンスＮｃからなるパケットをＴＣＰストリーム上に乗せてＳｉｎｋ機器に送信する。一方、Ｓｉｎｋ機器側では、ＴＣＰストリームからノンスＮｃを取り出すと、これと認証鍵Ｋａｕｔｈから求めた鍵Ｋｘを用いて同様にコンテンツ鍵Ｋｃを算出し、暗号化コンテンツを復号することができる。
【００１２】
このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化および復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００１３】
例えば、ＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成され、コンテンツの伝送を開始する。ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＤＴＣＰ＿Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋｃを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮｃを含んだヘッダからなるパケット（ＰＣＰ：Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ（例えば、特許文献１を参照のこと））をＴＣＰストリーム上に乗せて送信する。
【００１４】
放送波を受信してネットワークにストリーミング配信するサーバとしてのネットワークチューナ１台と、その配信データを、ネットワークを介して受信してローカルストレージに蓄積する録画クライアントが複数台存在するホームネットワークを想定する。各クライアントは、サーバとしてのネットワークチューナに対して、様々なチャンネルの様々な番組の録画予約を実行し、ネットワークチューナはこれらの録画予約を受領して、予約情報に従ってチューナの選局、受信コンテンツのクライアントに対する提供処理を実行する。
【００１５】
ただし、ネットワークチューナが１つのチューナのみを持つ場合、同じ時間帯に異なるチャンネルの番組に対する録画予約が発生していたとしても、１つの録画予約に対する処理しか実行できない。クライアントは、自由に録画予約を行なうことが可能であり、録画予約は重複して行うわれる可能性がある。重複の態様としては、複数の異なる番組の録画時間が完全に重複する場合、複数の録画予約の時間帯の一部が重複する場合など様々である。
【００１６】
クライアントは、自己が録画予約を行なった番組の開始時刻に近づくとネットワークチューナに対して番組受信要求を行う。例えば番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをネットワークチューナに送信する。ネットワークチューナはＨＴＴＰ  ＧＥＴの受信に応じて指定番組に対応するチャンネル選局を実行して、受信コンテンツをクライアントに送信する処理を行なう。
【００１７】
録画予約情報の管理構成としては、クライアントにおける個別管理構成と、サーバとしてのネットワークチューナにおける一括管理構成の２つの手法が考えられる。クライアントが１つであれば、例えば、そのクライアントにおいて同一時間帯に異なる番組予約を行なっていたとしても、クライアント側で実行するアルゴリズムに従って競合する予約中から１つの録画実行番組を決定してその決定した１つの番組に対する番組受信要求を行うことが可能である。
【００１８】
しかし、複数のクライアントが存在するネットワークにおいて各クライアントが個別に録画予約情報の管理を行なうと、それぞれのクライアントからの番組受信要求がネットワークチューナに送信され、さらにネットワークチューナ側においてチューナ独自の選択アルゴリズムを実行して１つの録画番組の決定を行なうことが必要となる。すなわち各クライアントと、ネットワークチューナがそれぞれ録画番組の選択処理を個別に実行することが必要となり処理負荷が増加するとともに、実際にはどの番組が録画されるのかについてクライアント側では知ることができないといった事態も発生する。このような場合、それぞれのクライアントは、自己の予約した番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをネットワークチューナに送信する処理を継続して実行してしまうといった事態が発生する。
【００１９】
具体的な例として各クライアントが実行した録画予約時間が一部重複する場合の処理例について説明する。一方のクライアントＡが予約した番組ａ（放送時間＝１６：００〜１７：００）が選択されて録画が実行されている場合、他方のクライアントＢの予約した番組ｂ（放送時間＝１６：００〜１７：３０）の録画が、番組ａの終了後（１７：００）から可能になるといった場合があるが、クライアントＢは、クライアントＡの番組ａの録画がいつ終了するかを知る手段がなく、クライアントＢは、番組ｂを番組ａの終了後（１７：００）に確実に実行させるためには、番組ｂに対応する番組受信要求（ＨＴＴＰ  ＧＥＴ）を番組ｂの開始時刻から繰り返しチューナに対して送信せざる得ないことになる。
【００２０】
【特許文献１】特開２０００−２８７１９２号公報
【非特許文献１】Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｖｏｌｕｍｅ  １  （Ｉｎｆｏｒｍａｔｉｏｎａｌ  Ｖｅｒｓｉｏｎ），  Ｒｅｖｉｓｉｏｎ  １．４  （ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ）
【非特許文献２】ＤＴＣＰ  Ｖｏｌｕｍｅ  １  Ｓｕｐｐｌｅｍｅｎｔ  Ｅ  Ｍａｐｐｉｎｇ  ＤＴＣＰ  ｔｏ  ＩＰ（Ｉｎｆｏｒｍａｔｉｏｎａｌ  Ｖｅｒｓｉｏｎ），  Ｒｅｖｉｓｉｏｎ  １．１  （ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ）
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明は、このような状況に鑑みてなされたものであり、ネットワーク接続されたチューナ機能を持つネットワークチューナの受信した放送コンテンツをネットワーク接続されたクライアントに提供して再生や記録を行なうシステムにおいて、ネットワークチューナが各クライアントの録画予約情報を一括管理し、クライアントに予約情報に基づく情報提供を行なう構成とすることでクライアントにおける無駄な処理を発生させることなく録画処理を実行可能とした通信システム、情報処理装置、および情報処理方法、並びにコンピュータ・プログラムを提供することを目的とする。
【課題を解決するための手段】
【００２２】
本発明の第１の側面は、
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバと、前記サーバから受信するデータの再生または記録を行なうクライアントとを有する通信システムであり、
前記サーバは、
放送データを受信する放送受信部と、
前記クライアントから入力する録画予約情報に基づく録画予約リストを生成するサーバ録画予約情報管理部を有し、
前記クライアントは、
前記サーバから前記録画予約リストを取得するクライアント録画予約情報管理部と、
前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行する録画処理部を有し、
前記サーバ録画予約情報管理部は、
ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領し、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データの応答としてコンテンツ送信許諾応答を行い要求コンテンツの送信を行なうとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なう構成であることを特徴とする通信システムにある。
【００２３】
さらに、本発明の通信システムの一実施態様において、前記クライアントの録画処理部は、前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信し、前記サーバ録画予約情報管理部は、前記クライアントからのコンテンツ取得要求に応じたコンテンツ送信を実行するか否かを予め設定された選択アルゴリズムを実行して決定する構成であることを特徴とする。
【００２４】
さらに、本発明の通信システムの一実施態様において、前記サーバ録画予約情報管理部は、前記録画予約リストの更新がなされた場合に、更新がなされたことを示す更新通知を前記クライアントに送信する構成であることを特徴とする。
【００２５】
さらに、本発明の通信システムの一実施態様において、前記サーバは、さらに、放送コンテンツの放送時間の変更に基づく前記録画予約リストの更新の必要性を判断する情報更新監視部を有し、前記サーバ録画予約情報管理部は、前記情報更新監視部からの前記録画予約リストの更新の必要性ありとの判断に基づいて前記録画予約リストの更新処理を行なう構成であることを特徴とする。
【００２６】
さらに、本発明の通信システムの一実施態様において、前記サーバ録画予約情報管理部は、前記録画予約リスト中に、録画予約番組の放送開始時間情報と、サーバ側で決定した録画実行開始時間情報を記録する構成であることを特徴とする。
【００２７】
さらに、本発明の通信システムの一実施態様において、前記クライアントの録画処理部は、前記録画予約リストに記録された録画実行開始時間情報に基づいてサーバに対するコンテンツ取得要求の出力タイミングを決定する処理を実行する構成であることを特徴とする。
【００２８】
さらに、本発明の通信システムの一実施態様において、前記サーバは、さらに、前記放送波受信部が受信した現在時刻情報を保存し管理を行うサーバ時刻情報管理部を有し、前記サーバ録画予約情報管理部は、前記サーバ時刻情報管理部の取得した現在時刻情報を録画予約リストに記録してクライアントに提供する構成であることを特徴とする。
【００２９】
さらに、本発明の通信システムの一実施態様において、前記クライアントは、前記録画予約リストに記録された現在時刻情報と、クライアントに備えられた時計との差分を算出するクライアント時刻情報管理部を有し、クライアントの前記録画処理部は、前記録画予約リストに記録された録画予約番組に対応する時間情報と、前記クライアント時刻情報管理部から提供される差分情報とに基づいて、録画処理の実行タイミングを決定する処理を行なう構成であることを特徴とする。
【００３０】
さらに、本発明の通信システムの一実施態様において、前記サーバは、前記クライアントに送信するデータに対して設定するタイムスタンプの値を決定するタイムスタンプ管理部を有し、前記クライアントは、前記サーバから受信するデータの復号処理および記憶部に記憶されるデータのタイムスタンプの値を保持するクライアント暗号処理部を有し、前記クライアントの録画処理部は、前記サーバとの通信中断の後のコンテンツ送信要求の出力に際し、前記クライアント暗号処理部の保持するタイムスタンプの値を適用して、サーバにおけるコンテンツ送信再開時のデータに設定するタイムスタンプの値を開始タイムスタンプ値として決定し、該開始タイムスタンプ値をサーバに通知する処理を実行する構成であることを特徴とする。
【００３１】
さらに、本発明の通信システムの一実施態様において、前記サーバのタイムスタンプ管理部は、前記クライアントから受信したデータに含まれる開始タイムスタンプ値に基づいて、通信中断後の送信データに設定するタイムスタンプの値を決定する処理を行なう構成であることを特徴とする。
【００３２】
さらに、本発明の第２の側面は、
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバとしての情報処理装置であり、
放送データを受信する放送受信部と、
前記クライアントから入力する録画予約情報に基づく録画予約リストを生成するサーバ録画予約情報管理部を有し、
前記サーバ録画予約情報管理部は、
ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領し、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データの応答としてコンテンツ送信許諾応答を行い要求コンテンツの送信を行なうとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なう構成であることを特徴とする情報処理装置にある。
【００３３】
さらに、本発明の情報処理装置の一実施態様において、前記サーバ録画予約情報管理部は、前記クライアントからのコンテンツ取得要求に応じたコンテンツ送信を実行するか否かを予め設定された選択アルゴリズムを実行して決定する構成であることを特徴とする。
【００３４】
さらに、本発明の情報処理装置の一実施態様において、前記サーバ録画予約情報管理部は、前記録画予約リストの更新がなされた場合に、更新がなされたことを示す更新通知を前記クライアントに送信する構成であることを特徴とする。
【００３５】
さらに、本発明の情報処理装置の一実施態様において、前記情報処理装置は、さらに、放送コンテンツの放送時間の変更に基づく前記録画予約リストの更新の必要性を判断する情報更新監視部を有し、前記サーバ録画予約情報管理部は、前記情報更新監視部からの前記録画予約リストの更新の必要性ありとの判断に基づいて前記録画予約リストの更新処理を行なう構成であることを特徴とする。
【００３６】
さらに、本発明の情報処理装置の一実施態様において、前記サーバ録画予約情報管理部は、前記録画予約リスト中に、録画予約番組の放送開始時間情報と、サーバ側で決定した録画実行開始時間情報を記録する構成であることを特徴とする。
【００３７】
さらに、本発明の情報処理装置の一実施態様において、前記情報処理装置は、さらに、前記放送波受信部が受信した現在時刻情報を保存し管理を行うサーバ時刻情報管理部を有し、前記サーバ録画予約情報管理部は、前記サーバ時刻情報管理部の取得した現在時刻情報を録画予約リストに記録してクライアントに提供する構成であることを特徴とする。
【００３８】
さらに、本発明の情報処理装置の一実施態様において、前記情報処理装置は、前記クライアントに送信するデータに対して設定するタイムスタンプの値を決定するタイムスタンプ管理部を有し、前記タイムスタンプ管理部は、前記クライアントから受信したデータに含まれる開始タイムスタンプ値に基づいて、通信中断後の送信データに設定するタイムスタンプの値を決定する処理を行なう構成であることを特徴とする。
【００３９】
さらに、本発明の第３の側面は、
サーバにおいて受信された放送データを受信し、受信データの再生または記録を行なうクライアントとしての情報処理装置であり、
クライアントから入力される録画予約情報に基づいて前記サーバにおいて生成された録画予約リストを前記サーバから取得するクライアント録画予約情報管理部と、
前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行する録画処理部を有し、
前記録画処理部は、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信する構成であることを特徴とする情報処理装置にある。
【００４０】
さらに、本発明の情報処理装置の一実施態様において、前記サーバの生成する録画予約リストは、録画予約番組の放送開始時間情報と、サーバ側で決定した録画実行開始時間情報が記録された構成であり、前記録画処理部は、前記録画予約リストに記録された録画実行開始時間情報に基づいてサーバに対するコンテンツ取得要求の出力タイミングを決定する処理を実行する構成であることを特徴とする。
【００４１】
さらに、本発明の情報処理装置の一実施態様において、前記サーバの生成する録画予約リストは、サーバの放送波受信部が受信した現在時刻情報が記録された構成を有し、前記情報処理装置は、前記録画予約リストに記録された現在時刻情報と、クライアントに備えられた時計との差分を算出するクライアント時刻情報管理部を有し、前記録画処理部は、前記録画予約リストに記録された録画予約番組に対応する時間情報と、前記クライアント時刻情報管理部から提供される差分情報とに基づいて、録画処理の実行タイミングを決定する処理を行なう構成であることを特徴とする。
【００４２】
さらに、本発明の情報処理装置の一実施態様において、前記情報処理装置は、前記サーバから受信するデータの復号処理および記憶部に記憶されるデータのタイムスタンプの値を保持するクライアント暗号処理部を有し、前記録画処理部は、前記サーバとの通信中断の後のコンテンツ送信要求の出力に際し、前記クライアント暗号処理部の保持するタイムスタンプの値を適用して、サーバにおけるコンテンツ送信再開時のデータに設定するタイムスタンプの値を開始タイムスタンプ値として決定し、開始タイムスタンプ値をサーバに通知する処理を実行する構成であることを特徴とする。
【００４３】
さらに、本発明の第４の側面は、
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバとしての情報処理装置において実行する情報処理方法であり、
放送受信部が、放送データを受信する放送受信ステップと、
サーバ録画予約情報管理部が、前記クライアントから入力する録画予約情報に基づく録画予約リストを生成するステップと、
前記サーバ録画予約情報管理部が、ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領し、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データの応答としてコンテンツ送信許諾応答を行い要求コンテンツの送信を行なうとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なうステップと、
を実行することを特徴とする情報処理方法にある。
【００４４】
さらに、本発明の第５の側面は、
サーバにおいて受信された放送データを受信し、受信データの再生または記録を行なうクライアントとしての情報処理装置において実行する情報処理方法であり、
クライアント録画予約情報管理部が、クライアントから入力される録画予約情報に基づいて前記サーバにおいて生成された録画予約リストを前記サーバから取得する録画予約情報管理ステップと、
録画処理部が、前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行する録画処理ステップを有し、
前記録画処理ステップは、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信するステップを含むことを特徴とする情報処理方法にある。
【００４５】
さらに、本発明の第６の側面は、
放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバとしての情報処理装置において情報処理を実行させるコンピュータ・プログラムであり、
放送受信部に、放送データを受信させる放送受信ステップと、
サーバ録画予約情報管理部に、前記クライアントから入力する録画予約情報に基づく録画予約リストを生成させるステップと、
前記サーバ録画予約情報管理部に、ネットワーク接続されたクライアントからのコンテンツ取得要求データを受領させ、時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択させ、選択された要求データの応答としてコンテンツ送信許諾応答を行わせて要求コンテンツの送信を行なわせるとともに、選択されなかった要求データの応答として要求が実行されないことを示す応答を行なわせるステップと、
を実行させることを特徴とするコンピュータ・プログラムにある。
【００４６】
さらに、本発明の第７の側面は、
サーバにおいて受信された放送データを受信し、受信データの再生または記録を行なうクライアントとしての情報処理装置において情報処理を実行させるコンピュータ・プログラムであり、
クライアント録画予約情報管理部に、クライアントから入力される録画予約情報に基づいて前記サーバにおいて生成された録画予約リストを前記サーバから取得させる録画予約情報管理ステップと、
録画処理部に、前記録画予約リストに記録された録画予約情報に基づいて、録画予定コンテンツの取得要求を実行させる録画処理ステップを有し、
前記録画処理ステップは、
前記録画予約リストの記録データである録画予約情報に含まれる各録画予約番組の開始予定時刻情報に基づいて、前記サーバに対するコンテンツ取得要求を送信させるステップを含むことを特徴とするコンピュータ・プログラムにある。
【００４７】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能なコンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００４８】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【発明の効果】
【００４９】
本発明の一実施例の構成によれば、放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバと、前記サーバから受信するデータの再生または記録を行なうクライアントとを有する通信システムにおいて、サーバがクライアントから入力する録画予約情報に基づく録画予約リストを生成してクライアントに提供し、クライアントは、録画予約リストに記録された録画予約情報に基づいて録画予定コンテンツの取得要求を実行し、サーバ側で時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データに対してはコンテンツ送信許諾応答を行い要求コンテンツの送信を実行するとともに、選択されなかった要求データの応答としては要求が実行されないことを示す応答を行なう構成としたので、クライアントは時間の重複するコンテンツについての選択処理などを行なうことなく自己の設定した録画予約に基づくコンテンツ送信要求を行うのみとなり、処理負荷が軽減される。
【００５０】
また、本発明の一実施例の構成によれば、録画予約情報にサーバ側で決定した録画実行時間や、放送受信部の受信した現在時刻情報を記録してクライアントに提供する構成としたので、クライアント側ではこれらの情報に基づく正確なコンテンツ取得要求が実現される。
【００５１】
また、本発明の一実施例の構成によれば、サーバとクライアント間の通信中断などが発生した場合のサーバの設定するタイムスタンプの値をクライアント側で決定したサーバに通知することを可能としたので、タイムスタンプの連続性が保持され、クライアントがサーバとなってデータを送信する場合に設定済みのタイムスタンプを書き換える必要がなく処理負荷が軽減される。
【発明を実施するための最良の形態】
【００５２】
以下、図面を参照しながら本発明の情報処理装置、および情報処理方法、並びにコンピュータ・プログラムの詳細について説明する。なお、説明は、以下の項目に従って行なう。
１．ネットワーク構成例について
２．ネットワークチューナにおける録画予約情報管理および情報提供処理構成
３．録画予約リストに基づくクライアントにおける録画実行開始時間の制御
４．録画処理における時刻情報管理
５．タイムスタンプの制御
【００５３】
［１．ネットワーク構成例について］
まず、本発明の情報処理装置の適用可能なネットワーク環境について図１を参照して説明する。図１は、様々な情報処理機器が接続されているホームネットワーク構成を示している。ネットワークチューナ２００は、ＴＶチューナを内蔵し、衛星放送、地上波放送を、アンテナ１２１，１２２を介して受信し、受信コンテンツをネットワーク１５０を介してクライアント２５０，２６０に提供する。クライアント２５０，２６０は、ネットワークチューナ２００からネットワークチューナ２００の受信した放送コンテンツを受信し、ハードディスクなどによって構成される自己の記憶部２５１，２６１に記録（録画）する。この録画処理は、例えば録画予約に基づいて実行される。なお、図１には２つのクライアントを示しているが、さらに多くのクライアントがネットワークに接続された構成としてもよい。
【００５４】
図１に示すネットワーク１５０は例えばＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークであり、ネットワーク１５０を介したデジタル・コンテンツの伝送はＤＴＣＰＩＰ（ＤＴＣＰ  ｏｖｅｒ  ＩＰ）規格に従って実行される。ＤＴＣＰ−ＩＰに従ったデジタル・コンテンツの伝送においては、先に説明したように、例えばコンテンツ提供側であるサーバ（ソース）と、コンテンツ受信側であるクライアント（シンク）間での認証処理の後、サーバ側でコンテンツを暗号化して送信し、クライアント側で受信暗号化コンテンツを復号して再生処理が実行される。この一連の処理、すなわち相互認証および鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にサーバクライアント間でＴＣＰコネクションが確立されて処理が実行される。
【００５５】
コンテンツは、コンテンツ鍵を用いて暗号化され、暗号化コンテンツからなるペイロード、コンテンツ鍵生成情報（ノンスＮ）を含んだヘッダからなるパケット（ＰＣＰ：Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ）としてＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ストリーム上に乗せて送信される。図１に示すネットワークチューナ２００は、アンテナ１２１，１２２を介して放送コンテンツを受信してクライアント２５０，２６０に受信コンテンツを提供する際、受信コンテンツに対する暗号化処理、ＰＣＰの生成を行なって出力する。
【００５６】
［２．ネットワークチューナにおける録画予約情報管理および情報提供処理構成］
図１に示すように１つのネットワークチューナ（サーバ）２００と、複数のクライアント２５０，２６０が存在するネットワークにおいて、各クライアント２５０，２６０がそれぞれ独自に録画予約を行い、録画予約に基づく番組取得要求（特定の番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴ）をネットワークチューナ２００に対して出力することが可能となる。
【００５７】
しかし、先に説明したように、図１に示すように複数のクライアント２５０，２６０が存在するネットワーク環境においては、各クライアントからネットワークチューナにおいて受信された番組受信要求が異なるチャンネルの同一時間帯に重なった番組である場合、ネットワークチューナが録画を実行する番組の選択を行なうことが必要となる。この場合、クライアントは自己の予約番組の録画が実行されるか等を知ることができず、各クライアント２５０，２６０の少なくとも一方は、自己の要求する番組が受信できないため自己の予約番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをネットワークチューナ２００に継続して送信せざる得ない状況が発生する。
【００５８】
このような状況を解決するため、図１に示すネットワークチューナ２００は、各クライアント２５０，２６０の録画予約情報を一括管理し、クライアント２５０，２６０に予約情報に基づく情報提供を行なう。このような構成とすることでクライアント側の無駄な処理を発生させることのない録画処理を実現する。
【００５９】
本発明の一実施例に係る通信システムを構成するネットワークチューナ（サーバ）２００、およびクライアント２５０の構成例について、図２を参照して説明する。なお、図２には、１つのクライアント２５０の構成例を示しているが、他のクライアントも同様の構成を有する。
【００６０】
ネットワークチューナ２００は、図２に示すように放送波受信部２０１、サーバ録画予約情報管理部２０２、コネクション管理部２０３、データ送受信部２０４を有する。放送波受信部２０１は、放送データをアンテナ１２１，１２２を介して受信し、選局されているチャンネル対応の放送コンテンツ（ＭＥＰＧデータ）を取り出してデータ送受信部２０４に出力し、データ送受信部２０４はクライアント２５０に対して受信データを出力する。出力されるデータは、例えば録画予約された番組であり、クライアント２５０から出力される番組対応のＵＲＬを設定したＨＴＴＰ  ＧＥＴの受信に基づいて番組提供処理が実行される。
【００６１】
サーバ録画予約情報管理部２０２は、ネットワークに接続された各クライアント、例えば図１に示す例では、クライアント２５０，２６０の各クライアントからの録画予約情報を一括管理する。具体的には、各クライアントからの録画予約情報に基づく予約リストを生成し、生成した予約リストをクライアント２５０からの要求（ＣＤＳ  Ｂｒｏｗｓｅ要求）に基づいてクライアントに提供する。コネクション管理部２０３は、クライアント２５０や、他のクライアントとの通信コネクションの管理を実行する。
【００６２】
クライアントに対してコンテンツを提供するサーバであるネットワークチューナ２００は、放送受信部２０１を介して受信する放送コンテンツに対応する番組情報や各クライアントからの録画予約情報に基づく予約リストを図示しない記憶部に格納して管理する。このデータ管理は例えばホームネットワーク仕様を規定したＵＰｎＰにおいて定義されているＣＤＳ（コンテンツディレクトリサービス）を適用して実行される。
【００６３】
サーバ録画予約情報管理部２０２は、各クライアントからの録画予約情報を入力して予約リストを生成し、ＣＤＳ（コンテンツディレクトリサービス）を適用し、論理的な階層構成のディレクトリを用いてクライアントからの録画予約情報に基づいて生成した予約リストの管理を行なう。ネットワークに接続された各クライアントは、ＣＤＳによって管理されている様々な情報の閲覧要求を行うことが可能であり、この閲覧要求はＣＤＳ  Ｂｒｏｗｓｅと呼ばれる。サーバ録画予約情報管理部２０２は、クライアントからの録画予約リストの閲覧要求であるＣＤＳ  Ｂｒｏｗｓｅを受信した場合録画予約リストをクライアントに出力する。
【００６４】
なお、ＣＤＳ（コンテンツディレクトリサービス）によって管理されているデータの更新がなされると、クライアントに対して情報変更や更新がなされたことの通知処理としてのＧＥＮＡ  Ｎｏｔｉｆｙの送信が実行され、各クライアントは例えば他のクライアントからの番組録画予約が新たに発生してサーバ録画予約情報管理部２０２の管理する予約リストに変更が発生した場合、その変更発生についてこの通知処理（ＧＥＮＡ  Ｎｏｔｉｆｙ）によって知ることが可能であり、この通知に応じて録画予約リストの閲覧要求としてのＣＤＳ  Ｂｒｏｗｓｅを出力することも可能である。
【００６５】
図２に示すクライアント２５０の構成について説明する。クライアント２５０は、図に示すように、例えば録画番組を記録する記憶部２５１、クライアント側での録画予約情報の管理を行なうクライアント録画予約情報管理部２５２、ネットワークチューナ（サーバ）２００とのデータ通信を実行するデータ送受信部２５３、録画処理を実行する録画処理部２５４を有する。
【００６６】
クライアント録画予約情報管理部２５２は、クライアント側での録画予約情報の管理、および録画予約情報のネットワークチューナ２００に対する出力処理の他、前述した閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）をネットワークチューナ２００に送信し、ネットワークチューナ２００の生成する予約リストを取得する処理を実行する。録画処理部２５４は、クライアント録画予約情報管理部２５２から取得する情報、具体的には、クライアント側での録画予約情報や、ネットワークチューナ２００から取得した予約リストの情報に基づいて、録画処理の開始可能な時刻を判断して録画予定番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをデータ送受信部２５３を介してネットワークチューナ２００に対して送信する。
【００６７】
ネットワークチューナ２００は、ＨＴＴＰ  ＧＥＴに対する応答として、情報送信可能であることを示すステータスコードである［ｓｔａｔｕｓ  ｃｏｄｅ  ＯＫ］をクライアントに送信し、クライアントはこのステータスコードをネットワークチューナ２００から受信した後、放送コンテンツの受信を開始して記憶部２５１に格納して録画処理を実行する。
【００６８】
図２に示すネットワークチューナ２００およびクライアント２５０の主な処理の概要についてまとめて説明する。ネットワークチューナ２００は、クライアント２５０からの録画予約を受領して録画予約リストを生成し、ＣＤＳにおいて管理し、クライアント２５０からの要求（ＣＤＳ  Ｂｒｏｗｓｅ）に応じて録画予約リストをクライアントに提供する。
【００６９】
クライアント２５０は自己の録画予約情報や録画予約リストに基づいて、自己の録画開始時間を判断して録画番組の取得要求（ＨＴＴＰ  ＧＥＴ）をネットワークチューナ２００に送信する。ネットワークチューナ２００は、クライアント２５０からの要求による放送コンテンツの提供が可能な場合は、情報送信可能であることを示す［ｓｔａｔｕｓ  ｃｏｄｅ  ＯＫ］をクライアント２５０に通知した後、クライアント２５０に対して録画番組を出力する。また、重複録画予約等に起因して、クライアント２５０からの録画番組の取得要求（ＨＴＴＰ  ＧＥＴ）に応じることが出来ない場合は、ＨＴＴＰ  ＧＥＴに対応する情報提供処理ができないことを示すステータスコードである［ＨＴＴＰ  ５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ］をクライアント２５０に出力する。
【００７０】
ネットワークチューナ２００の実行する主な処理は以下の通りである。
（ア）予約リストを保持し、重複予約時にどの予約を優先するかを判断する。
（イ）クライアントからのＣＤＳ  Ｂｒｏｗｓｅ要求に応じて、予約リスト情報を出力する。
また、ネットワークチューナ２００から放送データを受信し録画するクライアント２５０の実行する主な処理は以下の通りである。
（ア）ネットワークチューナにＣＤＳ  Ｂｒｏｗｓｅ要求を送信し、ネットワークチューナの管理する予約リスト情報を取得する。
（イ）ＣＤＳ  Ｂｒｏｗｓｅの結果から自分が録画実行を行うべき予約を抽出する。
（ウ）ＣＤＳ  Ｂｒｏｗｓｅの結果から自分がサーバから録画映像データを取得しに行く時間を計算する。
（エ）ネットワークチューナから出力される予約リスト情報を元に放送データを受信するためのＨＴＴＰ  ＧＥＴを送信する。
これらの処理がネットワークチューナ２００およびクライアント２５０の実行する主要な処理である。
【００７１】
図３、図４を参照して、クライアントからネットワークチューナに出力される予約リスト閲覧要求であるＣＤＳ  Ｂｒｏｗｓｅ要求と、ネットワークチューナがクライアントに対して提供する予約リスト情報のデータ構成例について説明する。図３（ａ）は、予約リストの閲覧処理を実行するクライアント２５０とネットワークチューナ２００との間の通信処理シーケンスを示している。まず、ステップＳ１０１において、クライアント２５０は、ネットワークチューナ２００に対してＣＤＳ  Ｂｒｏｗｓｅ要求を送信する。ＣＤＳ  Ｂｒｏｗｓｅ要求を受信したネットワークチューナ２００は、ＣＤＳ  Ｂｒｏｗｓｅ要求に対する応答として、予約リストを提示する。
【００７２】
図３に示すデータ３０１は、クライアント２５０から出力される予約リスト閲覧要求であるＣＤＳ  Ｂｒｏｗｓｅ要求データ３０１のデータ構成例である。図に示す予約リスト閲覧（Ｂｒｏｗｓｅ）要求データ３０１は、ＵＰｎＰにおいてネットワーク機器間のメッセージ通信処理の１つとして定義されるＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）アクションを用いた予約リスト閲覧（Ｂｒｏｗｓｅ）要求データ例である。
【００７３】
この閲覧（Ｂｒｏｗｓｅ）要求データ３０１を受信したネットワークチューナ２００のサーバ録画予約情報管理部２０２は、この閲覧要求に対する応答（ｒｅｓｐｏｎｃｅ）として図４に示す予約リスト３０２をクライアント２５０に出力する。
【００７４】
図４に示す録画予約リスト３０２は、ネットワークチューナ２００のサーバ録画予約情報管理部２０２において、各クライアントからの録画予約情報に基づいて生成した録画予約リストである。予約リスト３０２には、ネットワーク接続されたクライアントからの予約情報が記録されている。例えば記録データ３１１，３１２，３１３は、それぞれ個別の録画予約情報に対応する録画予約データであり、
（１）録画予約データ３１１
クライアント［Ｃ１］による番組Ａ（放送時間２００７／０１／１４：１５：：００〜１６：００）の予約
（２）録画予約データ３１２
クライアント［Ｃ１］による番組Ｂ（放送時間２００７／０１／１４：１５：：００〜１６：３０）の予約
（３）録画予約データ３１３
クライアント［Ｃ２］による番組Ｃ（放送時間２００７／０１／１４：１５：：００〜１７：００）の予約
これらの予約情報である。
【００７５】
このように、ネットワークチューナ２００が保持する予約リストは、各クライアントからの録画予約情報をすべて記録したリストとして設定され、この予約リストは、クライアントからの閲覧（ＣＤＳ  Ｂｒｏｗｓｅ）要求に応じて提示される。
【００７６】
予約リスト３０２に含まれる各録画予約データ３１１〜３１３中の
［ａｖ：ｒｅｃｒｏｄＤｅｓｔｉｎａｔｉｏｎ］
が録画先クライアントを示している。予約リスト３０２に示す例では、番組Ａと番組Ｂは録画クライアント［Ｃ１］が、番組Ｃは録画クライアント［Ｃ２］が録画先に設定されている。
【００７７】
例えばクライアント２５０が予約リストをネットワークチューナ２００から取得した場合、取得した予約リストを画面に出力することが可能となる。予約リストの取得および管理は、図２に示すクライアント２５０のクライアント録画予約情報管理部２５２が行なっており、入力部（図示せず）を介して予約リスト表示要求を入力することで図４に示す予約リスト３０２に基づくデータ表示がなされる。例えば、クライアント録画予約情報管理部２５２は、予約リスト３０２に基づいて図５に示すような表示データ３２０を生成して表示部（ディスプレイ）に出力する。表示データ３２０は、図４に示す予約リスト３０２に含まれる各クライアントからの録画予約状況の一覧として示される。
【００７８】
クライアント２５０の録画処理部２５４は、図４に示す予約リスト３０２に基づいて、録画番組の取得要求をネットワークチューナ２００に対して出力する。例えば、ネットワークチューナ２００が録画開始時刻の２分前から録画実行クライアントのコンテンツ取得要求としてのＨＴＴＰ  ＧＥＴを受け付けるとすると、予約リスト３０２において、１５：００の番組スタート時間を持つ番組ＡやＢの予約を行なっているクライアント１は、これらの番組Ａ，Ｂに対応するコンテンツ取得要求としてのＨＴＴＰ  ＧＥＴを送信する。また、予約リスト３０２において、１５：００の番組スタート時間を持つ番組Ｃの予約を行なっているクライアント２は、番組Ｃに対応するコンテンツ取得要求としてのＨＴＴＰ  ＧＥＴを送信する。ＨＴＴＰ  ＧＥＴの送信タイミングは、ネットワークチューナの受付開始時刻に応じて設定される。例えば２分前からの受付設定がなされている場合は、番組開始予定時刻の２分前以降、すなわち、１４：５８以降に放送データ受信のためのＨＴＴＰ  ＧＥＴを送信すればよい。
【００７９】
本実施例では、各クライアントは、自身で予約したすべての録画予約に対応する番組取得要求としてのＨＴＴＰ  ＧＥＴをネットワークチューナ２００に対して出力することを許容する。ネットワークチューナ２００のサーバ録画予約情報管理部２０２は、重複する時間帯の複数の番組取得要求としてのＨＴＴＰ  ＧＥＴを受信した場合は、サーバ録画予約情報管理部２０２の規定する選択アルゴリズムを適用して、実際に録画するコンテンツを決定する。
【００８０】
サーバ録画予約情報管理部２０２は、この決定処理の後、録画実行コンテンツに対応するＨＴＴＰ  ＧＥＴを送信したクライアントに対して、録画実行可能であり番組情報の送信が可能であることを示すステータスコードである［ｓｔａｔｕｓ  ｃｏｄｅ  ＯＫ］をクライアントに送信し、クライアントはこのステータスコードをネットワークチューナ２００から受信した後、放送コンテンツの受信を開始して録画処理を実行する。また、重複録画予約等に起因して、クライアントからの録画番組の取得要求（ＨＴＴＰ  ＧＥＴ）に応じることが出来ない場合は、ＨＴＴＰ  ＧＥＴに対応する情報提供処理ができないことを示すステータスコードである［ＨＴＴＰ  ５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ］をクライアントに出力する。
【００８１】
以上の処理についてのシーケンスについて図６を参照して説明する。図６は、図４に示す録画予約リスト３０２が設定されている場合の処理シーケンスを示している。すなわち、
（１）録画予約データ３１１
クライアント［Ｃ１］による番組Ａ（放送時間２００７／０１／１４：１５：：００〜１６：００）の予約
（２）録画予約データ３１２
クライアント［Ｃ１］による番組Ｂ（放送時間２００７／０１／１４：１５：：００〜１６：３０）の予約
（３）録画予約データ３１３
クライアント［Ｃ２］による番組Ｃ（放送時間２００７／０１／１４：１５：：００〜１７：００）の予約
これらの録画予約が録画予約リストに設定されている場合の処理シーケンスである。
【００８２】
クライアント［Ｃ１］２５０、およびクライアント［Ｃ２］２６０は、それぞれ、１４：５８以前に予約リストの閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）をネットワークチューナ２００に送信して、図４に示す予約リスト３０２を取得し、各クライアントのクライアント予約情報管理部２５２の管理データとしてクライアントの記憶部に格納している。各クライアントの録画処理部は、この予約リストを参照して、自己の録画予約時間の開始前（例えば２分前）に録画番組の送信要求としてのＨＴＴＰ  ＧＥＴをネットワークチューナ２００に出力する。
【００８３】
録画予約時間の開始前（例えば２分前）である１４：５８に、図６に示すステップＳ１０１〜Ｓ１０３の処理が一斉に実行される。
すなわち、クライアント［Ｃ１］２５０はステップＳ１０１，Ｓ１０２において、番組Ａと番組Ｂに対応するＵＲＬ設定のＨＴＴＰ  ＧＥＴをネットワークチューナ２００に送信する。
また、クライアント［Ｃ２］２６０はステップＳ１０３において、番組Ｃに対応するＵＲＬ設定のＨＴＴＰ  ＧＥＴをネットワークチューナ２００に送信する。
【００８４】
ネットワークチューナ２００は、受け取ったＨＴＴＰ  ＧＥＴに対して、番組開始時刻各クライアントとのコネクションを保持し続ける。
ネットワークチューナ２００は、番組開始時刻（１５：００）、またはその時刻前に自身の判定アルゴリズムにより、同一時間帯にあるクライアントからの録画予約から１つの録画実行番組を選択する。この選択アルゴリズムは、ネットワークチューナ２００において予め定められたアルゴリズムであり、例えばチャンネル番号の小さいものを優先するなど様々な態様のアルゴリズムが適用可能である。このアルゴリズムの具体例については後段で説明する。
【００８５】
例えば、この選択アルゴリズムによって、クライアント［Ｃ１］の要求する番組Ｂが録画対象として選択されたとする。ネットワークチューナは、この録画実行番組の決定結果に基づいて以下の処理を実行する。
ステップＳ１１１において、クライアント［Ｃ１］２５０から受け取った番組Ｂに対するＨＴＴＰ  ＧＥＴに対して、番組録画の実行がなされることを示すステータスコード［ｓｔａｔｕｓ  ｃｏｄｅ］を送信し、放送データの送信を開始する。
さらに、ステップＳ１１２、Ｓ１１３において、クライアント［Ｃ１］から受け取った番組Ａに対するＨＴＴＰ  ＧＥＴおよびクライアント［Ｃ２］から受け取った番組Ｃに対するＨＴＴＰ  ＧＥＴに対して、番組録画の実行が開始されないことを示すステータスコード［Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅのｓｔａｔｕｓ  ｃｏｄｅ］を送信する。このステータスコード［Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅのｓｔａｔｕｓ  ｃｏｄｅ］は、「他の予約が優先されました」ということを意味する。
【００８６】
次に番組録画の実行がなされることを示すステータスコード［ｓｔａｔｕｓ  ｃｏｄｅ］を受信したクライアント［Ｃ１］２５０は、ネットワークチューナ２００から送信される番組Ｂを受信し、録画処理部２５４の制御の下で受信した放送データをＨＤＤなどの記憶部２５１に蓄積する録画処理を行なう。
【００８７】
なお、番組録画の実行が開始されないことを示すステータスコード［Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅのｓｔａｔｕｓ  ｃｏｄｅ］を、番組Ａについて受信したクライアント［Ｃ１］２５０、番組Ｃについて受信したクライアント［Ｃ２］２６０は、１５：００以降にもこれらの番組対応のＨＴＴＰ  ＧＥＴを送信する場合がある。この場合、ネットワークチューナ２００はすでに番組Ｂの録画が選択されたことを分かっているので、これらのＨＴＴＰ  ＧＥＴに対する応答として番組録画の実行が開始されないことを示すステータスコード［Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅのｓｔａｔｕｓ  ｃｏｄｅ］を繰り返し送信する。
【００８８】
図７に、ネットワークチューナ２００におけるクライアントから受信するコンテンツ送信要求としてＨＴＴＰ  ＧＥＴへの対応の変化と時刻の関係を表したタイムチャートを示す。
【００８９】
ネットワークチューナ２００の対応は、
（ａ）番組送信要求の受付開始時間（１４：５８）以前の時間［Ｔ１］、
（ｂ）番組送信要求の受付開始時間（１４：５８）から番組開始時間（１５：００）の時間［Ｔ２］、
（ｃ）番組開始時間（１５：００）以後の時間［Ｔ３］、
これらの３つの時間帯に応じて変更される。
【００９０】
まず、（ａ）番組送信要求の受付開始時間（１４：５８）以前の時間［Ｔ１］においては、ネットワークチューナ２００は、クライアントから番組Ａ、番組Ｂ、番組Ｃに対応するコンテンツ送信要求としてＨＴＴＰ  ＧＥＴを受信した場合、即座にエラーを返す。
【００９１】
（ｂ）番組送信要求の受付開始時間（１４：５８）から番組開始時間（１５：００）の時間［Ｔ２］においては、ネットワークチューナ２００は、クライアントから番組Ａ、番組Ｂ、番組Ｃに対応するコンテンツ送信要求としてＨＴＴＰ  ＧＥＴを受信した場合、受付時間内であることを確認し、番組開始時間（１５：００）までクライアントとのコネクションを継続させて待機することになる。番組開始時間（１５：００）になると、図６を参照して説明した処理が実行される。すなわち、ネットワークチューナ側の選択アルゴリズムの実行によって決定した録画実行番組に対するＨＴＴＰ  ＧＥＴに対して、番組録画の実行がなされることを示すステータスコード［ｓｔａｔｕｓ  ｃｏｄｅ］を送信し、放送データの送信を開始し、選択されなかった番組対応のＨＴＴＰ  ＧＥＴに対して、番組録画の実行が開始されないことを示すステータスコード［Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅのｓｔａｔｕｓ  ｃｏｄｅ］を送信する。
【００９２】
（ｃ）番組開始時間（１５：００）以後の時間［Ｔ３］では、ネットワークチューナ２００は、番組Ａ、番組Ｃに対応するＨＴＴＰ  ＧＥＴには番組録画の実行が開始されないことを示すステータスコード［Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅのｓｔａｔｕｓ  ｃｏｄｅ］を送信し、録画実行番組に対するＨＴＴＰ  ＧＥＴに対しては、番組録画の実行がなされることを示すステータスコード［ｓｔａｔｕｓ  ｃｏｄｅ］を送信して当該番組のストリーミング送信処理を実行する。
【００９３】
ネットワークチューナ２００のサーバ録画予約情報管理部２０２では、同一時間帯に複数の録画予約が存在する場合、１つの録画実行番組を予め設定されたアルゴリズムに従って決定する。この選択アルゴリズムには様々なアルゴリズムが適用可能である。アルゴリズムの一例について説明する。例えば以下のようなステップによって構成されるアルゴリズムが適用可能である。
（ステップＳ１）
放送プログラムをチェックし、録画予約番組が放送されるかを確認し、放送中止となったものを録画対象外として設定。すなわち、放送局の都合などで番組が延期、消滅している可能性がある。このような録画予約は録画対象外に設定する。
（ステップＳ２）
ステップ（Ｓ１）で対象外とならなかった有効な録画予約について、各録画予約を以下の２つにカテゴリを区分する。
（カテゴリ１）ユーザの意志で予約した録画予約、
（カテゴリ２）「おまかせ」機能によって自動的に登録された予約、
なお、「おまかせ」とはユーザがキーワードやジャンルなどの条件を登録しておくことで、勝手にその条件にマッチする番組を予約する機能のことである。
【００９４】
（ステップＳ３）
ステップ（Ｓ２）のカテゴライズの結果、
（Ｓ３−ａ）
カテゴリ１，２が混在した場合、
カテゴリ１のユーザの意志で予約した録画予約を優先する。
（Ｓ３−ｂ）
ステップ（Ｓ２）のカテゴライズの結果、ユーザの意志で登録した録画予約が複数存在する場合、ユーザ設定の「優先度」が付与されているか否かを検証し、優先度が付与されている場合、優先度の高い予約を選択する。例えば、クライアントは最優先の録画予約に対して識別情報を付与した「保護処理」を実行することができ、「保護処理」による録画予約が最優先される。なお、「優先度」が同一のものが存在した場合は、時間的に一番最後に予約された予約を選択する。
（Ｓ３−ｃ）
ステップ（Ｓ２）のカテゴライズの結果、「おまかせ」で登録された予約のみであった場合は、「おまかせ」で登録された予約の中から、時間的に一番最後に予約された予約を選択する。
【００９５】
ネットワークチューナ２００のサーバ録画予約情報管理部２０２では、例えば上述したような選択アルゴリズムを実行して、複数の重複する時間における録画予約から、唯一の録画実行対象とする予約を決定する。なお、上述した選択アルゴリズムは一例であり、このアルゴリズム以外のアルゴリズムを適用してもよい。例えば、以下のようなアルゴリズムが利用可能である。
＊過去の予約録画履歴を保持しておき、そこからユーザ嗜好を割り出して、一番マッチするものを選択する。
＊インターネット上に、どれくらいの人が当該番組を予約しているかを取得できるサービスが存在するとしたら、最もその人数が多いものを選択する。
例えば、このようなアルゴリズムを実行する構成としてもよい。
【００９６】
上述した実施例に係る処理構成によるメリットとしては例えば以下のようなものがある。
１．ネットワークチューナが予約リストを一元管理する構成であるため、
（ア）唯一の予約リストを複数のクライアントが共有可能となる。すなわた、ネットワークチューナの保持する予約リストを各クライアントが参照可能であり、各クラライアント間での問い合わせ等は不要となる。
（イ）時間的に重複した予約があっても、ネットワークチューナの実行する選択アルゴリズムによって、１つの録画が実行される。いずれかを優先録画するかの決定アルゴリズムがサーバ内で変わっても、クライアントには影響を与えない。
（ウ）優先させたい録画予約に対応する処理として実行される「保護処理」の一元管理が可能となる。
【００９７】
また、本処理構成では、クライアントは自己の実行した録画予約情報を予約リストに基づいて確認し、録画開始時刻に応じて受信要求（ＨＴＴＰ  ＧＥＴ）をネットワークチューナに出力すればよいだけなので、クライアント側での複雑な判定処理が不要となり、処理負荷が低減される。
すなわち、
（ア）クライアントは予約が重複している場合でも、重複していない場合でも、同様にサーバに対して接続を行うだけで良い。
（イ）クライアントは、他のクライアントの有無などを気にしなくても良い。
（ウ）クライアントは、他のクライアントがいない場合で、かつ、自分用に重複した予約がある場合でも、気にせずに同様の方法で録画を行えばよい。
（エ）クライアントは重複を気にせずに録画予約を作成できる。
これらのメリットがある。
【００９８】
［３．録画予約リストに基づくクライアントにおける録画実行開始時間の制御］
次に、上述した録画予約リストに基づくクライアントにおける録画実行開始時間の制御構成について説明する。
【００９９】
本実施例に係るネッワークチューナ２００とクライアント２５０の構成を図８に示す。ネットワークチューナ２００は、図８に示すように放送波受信部２０１、サーバ録画予約情報管理部２０２、コネクション管理部２０３、データ送受信部２０４、情報更新監視部２０５を有する。放送波受信部２０１は、放送データをアンテナ１２１，１２２を介して受信し、選局されているチャンネル対応の放送コンテンツ（ＭＥＰＧデータ）を取り出してデータ送受信部２０４に出力し、データ送受信部２０４はクライアント２５０に対して受信データを出力する。出力されるデータは、例えば録画予約された番組であり、クライアント２５０から出力される番組対応のＵＲＬを設定したＨＴＴＰ  ＧＥＴの受信に基づいて番組提供処理が実行される。
【０１００】
サーバ録画予約情報管理部２０２は、ネットワークに接続された各クライアント、例えば図１に示す例では、クライアント２５０，２６０の各クライアントからの録画予約情報を一括管理する。具体的には、各クライアントからの録画予約情報に基づく予約リストを生成し、生成した予約リストをクライアント２５０からの要求（ＣＤＳ  Ｂｒｏｗｓｅ要求）に基づいてクライアントに提供する。コネクション管理部２０３は、クライアント２５０や、他のクライアントとの通信コネクションの管理を実行する。
【０１０１】
情報更新監視部２０５は、サーバ録画予約情報管理部２０２において管理されている情報、すなわち録画予約リストなどに対応する情報の更新の必要の有無を監視する。例えば録画予約された番組の放送時間の変更などの情報を放送受信部２０１から受信する放送局からのメッセージ等によって検出し、サーバ録画予約情報管理部２０２において管理されている情報の更新が必要な場合、サーバ録画予約情報管理部２０２に更新処理を要求する。
【０１０２】
サーバ録画予約情報管理部２０２がＣＤＳによる管理情報の更新を実行した場合は、サーバ録画予約情報管理部２０２は、前述したように更新通知（ＧＥＮＡ  Ｎｏｔｉｆｙ）をクライアントに送信する。
【０１０３】
図８に示すクライアント２５０の構成は、先に図２を参照して説明したと同様であり、例えば録画番組を記録する記憶部２５１、クライアント側での録画予約情報の管理を行なうクライアント録画予約情報管理部２５２、ネットワークチューナ（サーバ）２００とのデータ通信を実行するデータ送受信部２５３、録画処理を実行する録画処理部２５４を有する。
【０１０４】
クライアント録画予約情報管理部２５２は、クライアント側での録画予約情報の管理、および録画予約情報のネットワークチューナ２００に対する出力処理の他、前述した閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）をネットワークチューナ２００に送信し、ネットワークチューナ２００の生成する予約リストを取得する処理を実行する。録画処理部２５４は、クライアント録画予約情報管理部２５２から取得する情報、具体的には、クライアント側での録画予約情報や、ネットワークチューナ２００から取得した予約リストの情報に基づいて、録画処理の開始可能な時刻を判断して録画予定番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをデータ送受信部２５３を介してネットワークチューナ２００に対して送信する。
【０１０５】
図８に示すネットワークチューナ２００のサーバ録画予約情報管理部２０２は、クライアントからの録画予約情報を入力して予約リストを生成し、ＣＤＳ（コンテンツディレクトリサービス）を適用して予約リストを管理し、クライアントからの閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）に基づいて予約リストをクライアントに提供する。また、サーバ録画予約情報管理部２０２は、ＣＤＳ（コンテンツディレクトリサービス）によって管理されているデータである予約リストの更新がなされると、クライアントに対して情報変更や更新がなされたことの通知処理としてのＧＥＮＡ  Ｎｏｔｉｆｙの送信を実行し、各クライアントは例えば他のクライアントからの番組録画予約が新たに発生してサーバ録画予約情報管理部２０２の管理する予約リストに変更が発生した場合、その変更発生についても、この通知処理（ＧＥＮＡ  Ｎｏｔｉｆｙ）によって知ることが可能となる。
【０１０６】
クライアントでは、図８に示すクライアント録画予約情報管理部２５２において、閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）をネットワークチューナ２００に対して出力し、予約リストをクライアント録画予約情報管理部２５２のアクセス可能な記憶部に格納して管理し、録画処理部２５４は、この予約リストに基づいて録画実行処理としてのコンテンツ送信要求、すなわち番組対応のＵＲＬを設定したＨＴＴＰ  ＧＥＴをネットワークチューナ２００に対して発行して録画処理を開始する。
【０１０７】
このような処理構成において、ある１つのクライアント、例えば図１に示すクライアント２５０が複数の録画予約を実行し、これらの録画予約時間が一部重複する場合を想定する。例えば、図９に示すように、
番組Ａ（放送時間＝１５：００〜１６：００）
番組Ｂ（放送時間＝１５：３０〜１６：３０）
番組Ｃ（放送時間＝１６：１５〜１７：００）
これらの３番組の録画予約を行なった場合について考察する。
【０１０８】
ネットワークチューナ２００は、これらの複数の録画予約から、実際に録画を実行する予約を選択する。すなわち、ネットワークチューナ２００側において実行する選択アルゴリズムによって録画実行番組を決定する。
例えば、選択アルゴリズムによって、
まず、番組Ａの録画が終了してから番組Ｂの録画を開始、
次に、番組Ｃの開始時刻を迎えたら番組Ｂの録画は終了する。
この処理を決定したとする。
すなわち、
１５：００〜１６：００
番組Ａの録画を実行、
１６：００〜１６：１５
番組Ｂの録画を実行、
１６：１５〜１７：００
番組Ｃの録画を実行、
上記シーケンスでの録画処理を行なうことを決定したとする。
【０１０９】
ネットワークチューナ２００は録画予約を行なったクライアント２５０からの予約リスト閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）、すなわち、先に図３を参照して説明した予約リスト閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）３０１を受信すると、図１０に示すような予約リスト４０１をクライアント２５０に提供する。なお、本処理例では、１つのクライアント２５０からの録画予約のみが存在する例であり、図４において説明した予約リストに含まれていたクライアントの識別情報は省略している。
【０１１０】
図１０に示す録画予約リスト４０１には、クライアント２５０からの予約情報が記録されている。データ４１１，４１２，４１３は、それぞれ個別の録画予約情報に対応する録画予約対応データであり、
（１）録画予約対応データ４１１：番組Ａ（放送時間＝１５：００〜１６：００）
（２）録画予約対応データ４１２：番組Ｂ（放送時間＝１５：３０〜１６：３０）
（３）録画予約対応データ４１３：番組Ｃ（放送時間＝１６：１５〜１７：００）
これらの予約情報である。
【０１１１】
本例に示す予約リストに含まれる録画予約対応データ４１１，４１２，４１３の各々には、クライアントが実行した録画予約の情報として、
録画予約番組の番組開始時間情報４２１：＜ｕｐｎｐ：ｓｃｈｅｄｕｌｅｄＳｔａｒｔＴｉｍｅ＞
録画予約番組の番組終了時間情報４２２：＜ｕｐｎｐ：ｓｃｈｅｄｕｌｅｄＥｎｄＴｉｍｅ＞
これらの予約情報の他、
ネットワークチューナが実行した録画番組の選択アルゴリズムの結果として決定した以下の情報、すなわち、
録画実行開始時間情報４２３：＜ａｖ：ｒｅｃｏｒｄＳｔａｒｔＤａｔｅＴｉｍｅ＞
これらの情報が記録される。
【０１１２】
クライアント２５０は、図１０に示す録画予約リスト４０１に記載された録画実行開始時間情報４２３に基づいて、各番組に対応するコンテンツ取得要求［ＨＴＴＰ  ＧＥＴ］の出力タイミングを決定することが可能となる。クライアント２５０の録画処理部２５４は、クライアント録画予約情報管理部２５２がネットワーチチューナ２００から取得した図１０に示す予約リスト４０１を参照して、予約リスト４０１に記録された各予約情報中の録画実行開始時間情報を確認して、この録画実行開始時間情報に従って各予約番組対応の番組コンテンツ取得要求である［ＨＴＴＰ  ＧＥＴ］をネットワークチューナ２００に対して送信する。
【０１１３】
ネットワークチューナ２００が録画開始時刻の２分前からクライアントからの番組コンテンツ取得要求である［ＨＴＴＰ  ＧＥＴ］を受け付けるとすると、クライアント２５０の録画処理部２５４は、図１０に示す予約リスト４０１に記録された各予約情報中の録画実行開始時間情報に従って、
＊番組Ａに対しては１４：５８以降にＨＴＴＰ  ＧＥＴを送信、
＊番組Ｂに対しては１５：５８以降にＨＴＴＰ  ＧＥＴを送信、
＊番組Ｃに対しては１６：１３以降にＨＴＴＰ  ＧＥＴを送信、
このように、ネットワークチューナの決定した各番組の録画開始可能時間に対応する時間に番組取得要求を送信するこが可能となる。
【０１１４】
このように、本実施例では、ネットワークチューナ２００は、クライアントからの録画予約に基づいて、録画番組の選択を実行して決定した各録画予約番組の実際の録画開始時間を予約リストに記録する処理を実行し、録画実行開始時間情報を記録した予約リストをクライアントに提供する構成としたので、クライアントは、実際の録画開始時間を知ることが可能となり、この録画開始時刻に対応するタイミングでのコンテンツ取得要求［ＨＴＴＰ  ＧＥＴ］をネットワークチューナに対して出力するこが可能となる。
【０１１５】
本構成により、録画予約時間からの録画が開始されない場合でも、クライアントは録画予約における番組開始時間から実際の録画開始時間まで繰り返しＨＴＴＰ  ＧＥＴの出力を行なうといった処理を実行することなく、実際の録画開始時間に合わせたタイミングでのコンテンツ取得要求［ＨＴＴＰ  ＧＥＴ］を送信することが可能となり、双方の機器における処理負荷が低減し、またネットワークにおける無駄な通信が削減できる。
【０１１６】
なお、番組の放送時間は放送局の都合などにより変更される場合がある。ネットワークチューナ２００は、このような放送時間の変更情報を放送局から受信し、放送時間に変更があった場合、録画予約リストを参照し、録画予約番組に対応する番組の放送時間の変更がある場合には、予約リストの更新処理を実行する。
【０１１７】
前述したように、図８に示すネットワークチューナ２００のサーバ録画予約情報管理部２０２は、クライアントからの録画予約情報を入力して予約リストを生成し、ＣＤＳ（コンテンツディレクトリサービス）を適用して予約リストを管理する。情報更新監視部２０５が予約リストの更新が必要であることを検出すると、検出情報がサーバ録画予約情報管理部２０２に入力され、サーバ録画予約情報管理部２０２は予約リストの更新を実行する。
【０１１８】
サーバ録画予約情報管理部２０２は、予約リストの更新を完了すると、クライアントに対して情報変更や更新がなされたことの通知処理としてのＧＥＮＡ  Ｎｏｔｉｆｙの送信を実行する。従って、クライアントは予約リストに変更が発生した場合、その変更発生についても、この通知処理（ＧＥＮＡ  Ｎｏｔｉｆｙ）によって知ることが可能となり、変更通知の後、予約リスト閲覧要求としての（ＣＤＳ  Ｂｒｏｗｓｅ）を実行することで、更新された予約リストを受信することができる。
【０１１９】
例えば、番組Ａの終了時間が放送局の都合で１０分延長された場合の処理例について、図１１、図１２を参照して説明する。図１１（ａ）に示すように、ネットワークチューナ２００のサーバ録画予約情報管理部２０２は、ＣＤＳ（コンテンツディレクトリサービス）において管理されている予約リストを更新し、この更新処理の実行後、クライアント２５０に対して情報更新がなされたことの通知処理としてのＧＥＮＡ  Ｎｏｔｉｆｙの送信を実行する。
【０１２０】
すなわち図１１に示す更新通知［ＧＥＮＡ  Ｎｏｔｉｆｙ］データ４５１がネットワークチューナ２００からクライアント２５０に送信される。ＣＤＳ（コンテンツディレクトリサービス）における管理情報は、様々なカテゴリに対応するデータアイテム（ｉｔｅｍ）集合としてのコンテナ単位で管理がなされ、あるコンテナ（Ｃｏｎｔａｉｎｅｒ）に属する情報の更新がなされるとそのコンテナ単位で更新通知［ＧＥＮＡ  Ｎｏｔｉｆｙ］がなされる。本例では、予約リスト情報はＲＳＶコンテナ（Ｃｏｎｔａｉｎｅｒ）の１つのアイテム（ｉｔｅｍ）として設定されているためＲＳＶコンテナに対するＧＥＮＡ  Ｎｏｔｉｆｙがクライアント２５０に送信される。
【０１２１】
クライアント２５０のクライアント録画予約情報管理部２５２は、この更新通知（ＧＥＮＡ  Ｎｏｔｉｆｙ）を受け取ると、更新された予約リストの取得処理として、予約リスト閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）を実行する。ネットワークチューナ２００は、クライアント２５０からのこの予約リスト閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）に応じて、クライアント２５０に対して更新された録画予約リストを送信する。
【０１２２】
この更新された録画予約リストのデータ例を図１２に示す。図１２に示す録画予約リスト４５２は、先に図１０を参照して説明した当初の予約リスト４０１を更新したリストである。
【０１２３】
番組Ａに対応する予約情報４６１における
録画予約番組の番組終了時間情報４７１：＜ｕｐｎｐ：ｓｃｈｅｄｕｌｅｄＥｎｄＴｉｍｅ＞が、
図１０に示す当初の予約リスト４０１では、［１６：００］として設定されていたデータが、図１２に示す更新予約リスト４５２では、［１６：１０］に変更されている。
さらに、
この番組Ａの延長に伴い、
番組Ｂに対応する予約情報４６２中の、
録画実行開始時間情報４７２：＜ａｖ：ｒｅｃｏｒｄＳｔａｒｔＤａｔｅＴｉｍｅ＞が、
図１０に示す当初の予約リスト４０１では、［１６：００］として設定されていたデータが、図１２に示す更新予約リスト４５２では、［１６：１０］に変更されている。
【０１２４】
クライアント２５０のクライアント録画予約情報管理部２５２は、この更新された録画予約リスト４５２をクライアントの記憶部に格納する。録画処理に際してコンテンツ取得要求を行うクライアント２５０の録画処理部２５４は、この更新された録画予約リスト４５２を参照して、番組Ｂのコンテンツ取得要求、すなわち、番組Ｂに対するＨＴＴＰ  ＧＥＴを［１６：１０］の２分前［１６：０８］にネットワークチューナ２００に送信する。
【０１２５】
このように、クライアントは、録画予約番組の放送時間が変更された場合であっても、ネットワークチューナから更新通知（ＧＥＮＡ  Ｎｏｔｉｆｙ）を受け取り、予約リストの閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）を実行して更新された予約リストを取得し、更新予約リストに基づいてコンテンツ取得要求（ＨＴＴＰ  ＧＥＴ）の送信タイミングを決定して送信することが可能であり、実際の録画開始時刻に併せたタイミングでのコンテンツ取得要求の送信処理が可能となる。
【０１２６】
なお、上述した実施例では、ネットワークチューナは各番組に対応する実際の録画開始時刻を記録した予約リストをクライアントに提示する構成としていたが、録画開始時刻ではなく、例えば、録画終了時刻を記録した予約リストを生成してクニイアントに提供する構成としてもよい。このような構成でも、クライアントは重複している予約で現在録画中の予約の録画終了時刻が分かるので、重複しているもう一方の予約の開始時刻が判断できる。
【０１２７】
あるいは、ネットワークチューナは録画開始時刻ではなく予約リストに記録された各録画予約のエントリごとの優先順位情報を予約リストに記録してクライアントに提供する構成としてもよい、クライアントは優先順位と各録画予約エントリの録画予約番組の開始時刻情報＜ｕｐｎｐ：ｓｃｈｅｄｕｌｅｄＳｔａｒｔＴｉｍｅ＞とに基づいて、どの番組が実際に録画されるかを判断することができる。すにわち、時間の重なりがある複数の録画予約がある場合、優先順位の高い予約が優先して録画されるという判断が可能となる。
【０１２８】
なお、ネットワークチューナにおいて、予約リストに各予約番組に対応する実際の録画開始時刻情報＜ａｖ：ｒｅｃｏｒｄＳｔａｒｔＤａｔｅＴｉｍｅ＞を記録するタイミングは、クライアントからの録画予約が投入されたとき、ネットワークチューナにおいて録画実行番組の選択アルゴリズムを実行して録画番組を決定したとき、あるいは、重複する時間のある録画予約のどれかの録画時刻を迎えたとき、など、様々なタイミングにおいて実行することが可能である。
【０１２９】
また、録画予約を実行するクライアント側で、録画時間が重複している予約エントリの優先順位を設定できる構成としてもよい。例えば、ネットワークチューナにおける予約リストの管理構成としてのＣＤＳに対する新たなオブジェクトの生成要求（ＣＤＳ  ｃｒｅａｔｅＯｂｊｅｃｔ）や情報更新要求としての（ＣＤＳ  ｕｐｄａｔｅＯｂｊｅｃｔ）を利用して、クライアントが録画予約エントリのネットワークチューナに対する設定要求を行なう際に、送信される要求（ＳＯＡＰリクエスト）に優先順位を記録して送信し、ネットワークチューナ側で、この優先順位を予約リスト中に記録する。
【０１３０】
本実施例の構成によれば、ネットワークチューナで予約リストを一元管理できるため、
（ア）予約リストをクライアントが管理する場合に、複数のクライアントが存在したときに必要な同期処理が必要ない。
（イ）重複している予約の場合、チューナがどちらの予約を優先するかのアルゴリズムをクライアントが知る必要はない。
（ウ）重複している予約のいずれかを優先録画するアルゴリズムがサーバ内で変わっても、クライアントには影響を与えない。
これらのメリットがある。
【０１３１】
さらに、ネットワークチューナが重複予約時の録画開始時刻をクライアントに通知する構成であるため、クライアントは、重複している予約の録画が実際に始まるまでに、コンテンツ取得要求（ＨＴＴＰ  ＧＥＴ）の繰り返し送信などのポーリング等の余計な処理を行なう必要がない。それによって、ネットワークチューナやクライアントの負荷が軽減され、またネットワーク上の無駄なデータ通信の発生も抑制される。
【０１３２】
［４．録画処理における時刻情報管理］
次に、クライアントによる録画処理における録画開始時間や録画終了時間などの時間管理を正確に行なう実施例について説明する。
【０１３３】
例えば図１に示す構成において、クライアント２５０，２６０は、ネットワークチューナ２００の受信する放送コンテンツを受信してクライアントの記憶部２５１，２６１に各機能する録画処理を行なう場合、録画開始時刻や録画終了時刻を前述した予約リストに記録された時間情報を参照して行なうことになる。この際、クライアントの装置の持つ時計を利用して、予約リストに記録された時間になったことを確認して録画の開始処理や終了処理を行なうことになる。
【０１３４】
ネットワークチューナが保持する予約リストをクライアントがその情報を受信し、クライアント自身の時計で処理を行った場合、クライアントの時計が正確でなくずれていると、正確な番組開始時刻からの録画開始や、終了処理ができないという問題が発生する。例えば、録画をするクライアントの時計が５分時計遅れていたとすると、最初の５分は録画ができず後ろに５分余計な番組が録画されてしまう。
【０１３５】
以下、説明する実施例は、このような事態を防止する構成を持つ実施例である。具体的には、ネットワークチューナが放送受信部を介して受信するデータに含まれる現在時刻情報を取得して、これを予約リストに併せてクライアントに提供し、クライアントは、予約リストに記録されている現在時刻情報と、クライアントの持つ時計の時刻情報を比較して、クライアントの時計の正しい時刻との差分を算出して、この差分情報を保持し、差分情報を考慮した録画開始、終了処理を実行する。
【０１３６】
本実施例に係るネッワークチューナ２００とクライアント２５０の構成を図１３に示す。ネットワークチューナ２００は、図１３に示すように放送波受信部２０１、サーバ録画予約情報管理部２０２、コネクション管理部２０３、データ送受信部２０４、サーバ時刻情報管理部２０６を有する。放送波受信部２０１は、放送データをアンテナ１２１，１２２を介して受信し、選局されているチャンネル対応の放送コンテンツ（ＭＥＰＧデータ）を取り出してデータ送受信部２０４に出力し、データ送受信部２０４はクライアント２５０に対して受信データを出力する。出力されるデータは、例えば録画予約された番組であり、クライアント２５０から出力される番組対応のＵＲＬを設定したＨＴＴＰ  ＧＥＴの受信に基づいて番組提供処理が実行される。
【０１３７】
サーバ録画予約情報管理部２０２は、ネットワークに接続された各クライアント、例えば図１に示す例では、クライアント２５０，２６０の各クライアントからの録画予約情報を一括管理する。具体的には、各クライアントからの録画予約情報に基づく予約リストを生成し、生成した予約リストをクライアント２５０からの要求（ＣＤＳ  Ｂｒｏｗｓｅ要求）に基づいてクライアントに提供する。コネクション管理部２０３は、クライアント２５０や、他のクライアントとの通信コネクションの管理を実行する。
【０１３８】
また、放送波受信部２０１は、放送波に含まれる現在時刻情報を受信し、この現在時刻情報をサーバ時刻情報管理部２０６に出力する。サーバ時刻情報管理部２０６は、放送波受信部２０１が受信した現在時刻情報を保存し管理を行う。サーバ時刻情報管理部２０６の管理する現在時刻情報は、サーバ録画予約情報管理部２０２が管理する録画予約リストに記録され、データ送受信部２０４を介してクライアント２５０に提供される。
【０１３９】
図１３に示すクライアント２５０の構成は、先に図２を参照して説明したと同様、例えば録画番組を記録する記憶部２５１、クライアント側での録画予約情報の管理を行なうクライアント録画予約情報管理部２５２、ネットワークチューナ（サーバ）２００とのデータ通信を実行するデータ送受信部２５３、録画処理を実行する録画処理部２５４と、さらに、クライアント時刻情報管理部２５５を有する。
【０１４０】
クライアント録画予約情報管理部２５２は、クライアント側での録画予約情報の管理、および録画予約情報のネットワークチューナ２００に対する出力処理の他、前述した閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）をネットワークチューナ２００に送信し、ネットワークチューナ２００の生成する予約リストを取得する処理を実行する。録画処理部２５４は、クライアント録画予約情報管理部２５２から取得する情報、具体的には、クライアント側での録画予約情報や、ネットワークチューナ２００から取得した予約リストの情報に基づいて、録画処理の開始可能な時刻を判断して録画予定番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをデータ送受信部２５３を介してネットワークチューナ２００に対して送信する。
【０１４１】
クライアント時刻情報管理部２５５は、ネットワークチューナ２００から提供される予約リストに記録された現在時刻情報を読み取り、図示しないクライアント２５０の時計の時刻との差分を算出し、録画開始や録画終了処理の実行タイミングを決定する。
【０１４２】
録画を実行するクライアント２５０が、ネットワークチューナ２００から予約リストを受信する処理シーケンス、および予約リストのデータ構成例について、図１４を参照して説明する。
【０１４３】
図１４（ａ）は、予約リストの閲覧処理を実行するクライアント２５０とネットワークチューナ２００との間の通信処理シーケンスを示している。まず、ステップＳ３０１において、クライアント２５０は、ネットワークチューナ２００に対してＣＤＳ  Ｂｒｏｗｓｅ要求を送信する。ＣＤＳ  Ｂｒｏｗｓｅ要求を受信したネットワークチューナ２００は、ＣＤＳ  Ｂｒｏｗｓｅ要求に対する応答として、予約リストを提示する。
【０１４４】
ステップＳ３０１において、クライアント２５０がネットワークチューナ２００に対して出力するＣＤＳ  Ｂｒｏｗｓｅ要求は、先に、図３を参照して説明したデータ３０１と同様の予約リスト閲覧要求であるＣＤＳ  Ｂｒｏｗｓｅ要求データ３０１である。
【０１４５】
本実施例においては、この予約リスト閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ要求）を受信したネットワークチューナ２００のサーバ録画予約情報管理部２０２は、この閲覧要求に対する応答（ｒｅｓｐｏｎｃｅ）として図１４に示す録画予約リスト５０１をクライアント２５０に出力する。
【０１４６】
図１４に示す予約リスト５０１は、ネットワークチューナ２００のサーバ録画予約情報管理部２０２において、各クライアントからの録画予約情報に基づいて生成した録画予約リストである。なお、図１４に示す予約リスト５０１は本実施例に関連する項目のみを記載した簡略化したデータとして示している。
【０１４７】
予約リスト５０１には、ネットワーク接続されたクライアントからの録画予約情報が記録されている。すなわち、録画番組の開始時刻情報５１１が記録されている。さらに、予約リスト５０１には、現在時刻情報５１２が記録されている。
【０１４８】
この現在時刻情報５１２は、サーバ録画予約情報管理部２０２がクライアントに対して予約リストを送信するタイミングの放送波受信部２０１を介して受信する放送波に含まれる現在時刻情報に相当する。放送波受信部２０１を介して受信する現在時刻情報が、サーバ時刻情報管理部２０６を介してサーバ録画予約情報管理部２０２に提供されて、サーバ録画予約情報管理部２０２において現在時刻情報が録画予約リストに記録される。本実施例の構成では、このように放送波に含まれる正確な現在時刻情報が追記された予約リスト５０１がクライアント２５０に提供される。
【０１４９】
クライアント２５０のクライアント録画予約情報管理部２５２が、予約リスト５０１を受信すると、クライアント時刻情報管理部２５５は、予約リストに記録された現在時刻情報を読み取り、クライアント２５０の時計の時刻との差分を算出し、録画開始や録画終了処理の実行タイミング、すなわち録画処理実行タイミングを決定する。この録画処理実行タイミング情報は、録画処理部２５４に提供される。録画処理部２５４は、予約リストに記録された録画開始時刻、およびクライアント時刻情報管理部２５５から提供されるクライアント時計の時刻と正確な時刻との時間差情報に基づいて、録画開始タイミングや録画終了タイミングを決定して処理を実行する。例えば録画コンテンツ取得要求としてのＨＴＴＰ  ＧＥＴの送信タイミングを決定して処理を実行する。
【０１５０】
なお、上述の実施例では、クライアントの録画処理における処理タイミングの決定を行なう例として説明したが、録画処理のみならず、視聴タイミングを決定する処理に、ネットワークチューナから提供される正確な時刻情報を適用する構成とすることも可能である。例えば、番組情報（ＥＰＧ）を元に、タイマーによる視聴を実施する場合、上記と同様の流れでクライアントの時計の誤差から正確な時刻を計算し、その値を利用してクライアントが放送コンテンツの取得タイミングを決定して処理、すなわち、コンテンツ取得、再生を開始することが可能となる。
【０１５１】
本実施例の構成によれば、ネットワークチューナ（サーバ）とクライアントが時計を同期させる必要がなくなるため、
（ア）ネットワークチューナ（サーバ）に時計同期のための特別なデーモンを立ち上げる必要がない。
（イ）クライアントに時計同期のための特別なアプリケーションを入れる必要がない。
（ウ）クライアントの時計を変更することにより、クライアントで動いている処理に悪影響を与えるリスクがなくなる。
というメリットが発生する。また、ネットワークチューナ（サーバ）は、現在時刻と、時刻に基づく情報を同時に出力できるため、
（ア）ネットワークに余計な情報を流れず、帯域を有効に利用できる。
（イ）クライアントは、時刻の差分を瞬時に求められるため、処理が容易に行える。
という効果をもたらす。
また、本処理例は、既存のプロトコルの枠組みで実現可能なため、実装が容易であるというメリットもある。
【０１５２】
［５．タイムスタンプの制御］
次に、ネットワークチューナ２００からクライアント２５０に対して送信するコンテンツに設定するタイムスタンプの制御を行う実施例について説明する。
【０１５３】
例えば、図１に示すネットワークチューナ２００は、放送コンテンツの録画や視聴を行なうクライアント２５０，２６０に対して放送コンテンツを送信する。ネットワークチューナ２００がアンテナ１２１，１２２を介して受信する放送データはＭＰＥＧ２−ＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）形式で送信されてくるが、これをネットワークチューナ２００が受信してネットワーク１５０にストリーミング配信する際にはＭＰＥＧ２−ＴＴＳ（Ｔｉｍｅｓｔａｍｐｅｄ  ＴＳ）形式に変換する。ＭＰＥＧ２−ＴＴＳは、図１５に示すように、ＭＰＥＧ２−ＴＳにｔｉｍｅｓｔａｍｐを付加したデータによって構成されるデータストリーム形式である。
【０１５４】
つまり、ネットワークチューナ２００は、クライアント２５０，２６０の要求に応じて放送データをネットワーク配信する際には、放送から受信したデータに再生順に従った時間情報としてのタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を随時付加して出力する。ＴＳパケットに格納されたＭＰＥＧ−２データを再生順に並べて再生することが可能となる。
【０１５５】
また、ネットワーク間を流れてクライアントに提供されるデジタル放送データは、不正コピー防止のため、ネットワークチューナにおいて暗号化され、ネットワーク出力される。すなわち、例えば、デジタル化されたＡＶコンテンツをＩＰホームネットワークを介して家庭内で流通させる場合、ＤＴＣＰＩＰ（ＤＴＣＰ  ｏｖｅｒ  ＩＰ）規格に従った流通が行なわれる。コンテンツ提供元であるサーバ（ＤＴＣＰ  Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ  Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いてコンテンツを暗号化して伝送を行なう。
【０１５６】
以上の前提において、例えば図１に示すクライアント２５０がネットワークチューナ２００からコンテンツを受信し録画処理を実行している場合、通信障害が発生し、コンテンツの受信ができなくなった場合、以下のような問題が発生する。
【０１５７】
通信障害が復旧してクライアントが録画を再開したとすると、サーバとしてのネットワークチューナ２００はクライアント２５０が受信に成功し保存できているデータの最後のタイムスタンプ（ｔｉｍｅｓｔａｍｐ）の値を知りえないので、通信障害が復旧し、データ送信を再開した後の送信パケット（ＴＴＳ）に付与するタイムスタンプ（ｔｉｍｅｓｔａｍｐ）と、通信障害発生前の送信済みパケット（ＴＴＳ）に付与していたタイムスタンプ（ｔｉｍｅｓｔａｍｐ）の値は不連続になる。
【０１５８】
不連続なタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を持つデータはクライアント２５０によって受信され記憶部２５１に格納される。クライアント２５０は、録画コンテンツを記憶部２５１から取得して、タイムスタンプに従って再生することになるが、この再生に際して問題となる可能性がある。
【０１５９】
また、クライアント２５０によって受信され記憶部２５１に格納されたデータを、さらに他のクライアント、例えば図１に示すクライアント２６０に送信する際に、このような不連続のタイムスタンプの設定されたデータ（ＴＴＳ）は問題となる。すなわち、クライアント２５０がコンテンツ提供サーバとなって、コンテンツをストリーミング配信する際に問題になる。なぜなら、サーバとなってストリーミング配信する際にはタイムスタンプ（ｔｉｍｅｓｔａｍｐ）の連続性を保証する必要があるからである。
【０１６０】
従って、このような不連続なタイムスタンプを持つデータを、クライアント２５０がコンテンツ提供サーバとなって、他のクライアント２６０などにストリーミング配信する際には、暗号化されて記憶部２５１に保存されている録画コンテンツの暗号をいったん復号し、タイムスタンプを書き換えなければならない。その後、再度暗号化してから録画コンテンツをネットワークに送信する処理が必要になる。これは非常に負荷の高い処理である。
【０１６１】
以下、説明する実施例では、このような処理を行なう必要のないように、ネットワークチューナ（サーバ）に対して、設定すべきタイムスタンプの値をクライアント側から通知する構成としている。例えば通信障害によるデータ送信の中断の後、クライアントは、受信済みのデータであるＴＴＳパケットに設定されたタイムスタンプの値を確認し、この値と連続性のあるタイムスタンプの値をネットワークチューナ（サーバ）に通知する。ネットワークチューナ（サーバ）は、この通知された値を利用して通信障害からの復旧後の送信データに付与するタイムスタンプの値を決定して送信を再開する。
【０１６２】
本実施例に係るネッワークチューナ２００とクライアント２５０の構成を図１６に示す。ネットワークチューナ２００は、図１６に示すように放送波受信部２０１、サーバ録画予約情報管理部２０２、コネクション管理部２０３、データ送受信部２０４、タイムスタンプ管理部２０７、サーバ暗号処理部２０８を有する。放送波受信部２０１は、放送データをアンテナ１２１，１２２を介して受信し、選局されているチャンネル対応の放送コンテンツ（ＭＥＰＧデータ）を取り出してデータ送受信部２０４に出力し、データ送受信部２０４はクライアント２５０に対して受信データを出力する。出力されるデータは、例えば録画予約された番組であり、クライアント２５０から出力される番組対応のＵＲＬを設定したＨＴＴＰ  ＧＥＴの受信に基づいて番組提供処理が実行される。
【０１６３】
サーバ録画予約情報管理部２０２は、ネットワークに接続された各クライアント、例えば図１に示す例では、クライアント２５０，２６０の各クライアントからの録画予約情報を一括管理する。具体的には、各クライアントからの録画予約情報に基づく予約リストを生成し、生成した予約リストをクライアント２５０からの要求（ＣＤＳ  Ｂｒｏｗｓｅ要求）に基づいてクライアントに提供する。コネクション管理部２０３は、クライアント２５０や、他のクライアントとの通信コネクションの管理を実行する。
【０１６４】
タイムスタンプ管理部２０７は、ネットワーク出力するパケットであるＭＰＥＧ２−ＴＴＳ（Ｔｉｍｅｓｔａｍｐｅｄ  ＴＳ）に設定するタイムスタンプの値を決定する。例えば、コンテンツ送信中のクライアントとの通信が中断した後、クライアントからのタイムスタンプ設定値情報をデータ送受信部２０４を介して受け取り、放送波受信部２０１から受け取ったＭＰＥＧ２−ＴＳデータにその値から始まるタイムスタンプを付加する。このようにして生成されたＭＰＥＧ２−ＴＴＳデータはサーバ暗号処理部２０８に渡される。
【０１６５】
サーバ暗号処理部２０８は、タイムスタンプ管理部２０７においてタイムスタンプの設定されたＭＰＥＧ−ＴＴＳデータを受け取り、暗号化処理を実行して暗号化データをデータ送受信部２０４に出力する。データ送受信部２０４は、サーバ暗号処理部２０８において暗号化されたデータをクライアントに対して出力する。
【０１６６】
図１６に示すクライアント２５０の構成は、先に図２を参照して説明したと同様、例えば録画番組を記録する記憶部２５１、クライアント側での録画予約情報の管理を行なうクライアント録画予約情報管理部２５２、ネットワークチューナ（サーバ）２００とのデータ通信を実行するデータ送受信部２５３、録画処理を実行する録画処理部２５４と、さらに、クライアント暗号処理部２５６を有する。
【０１６７】
クライアント録画予約情報管理部２５２は、クライアント側での録画予約情報の管理、および録画予約情報のネットワークチューナ２００に対する出力処理の他、前述した閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）をネットワークチューナ２００に送信し、ネットワークチューナ２００の生成する予約リストを取得する処理を実行する。録画処理部２５４は、クライアント録画予約情報管理部２５２から取得する情報、具体的には、クライアント側での録画予約情報や、ネットワークチューナ２００から取得した予約リストの情報に基づいて、録画処理の開始可能な時刻を判断して録画予定番組に対応するＵＲＬを設定したＨＴＴＰ  ＧＥＴをデータ送受信部２５３を介してネットワークチューナ２００に対して送信する。
【０１６８】
クライアント暗号処理部２５６は、ネットワークチューナ２００から提供される暗号化データの復号処理を実行する。すなわち録画処理部２５４から受け取った暗号データを、保存に適した形式の暗号データに変換してＨＤＤなどの記憶部２５１へ保存する。なお、この保存処理の際、保存データのＭＰＥＧ２−ＴＴＳのタイムスタンプの値を監視し、録画処理部２５４からの要求に応じてタイムスタンプ情報を渡す。また、クライアント２５０が記憶部２５１に格納された録画コンテンツを配信するサーバとしての処理を実行する際、クライアント暗号処理部２５６は、記憶部２５１に保存されているコンテンツをネットワークに出力するのに適した形式に暗号化しなおしてデータ送受信部２５３を介して出力する。
【０１６９】
なお、録画処理部２５４は、例えばネットワークチューナ（サーバ）２００からのコンテンツ受信中に発生した通信切断からの復旧後に録画を再開する際、クライアント暗号処理部２５６から、記憶部２５１に格納した最新のタイムスタンプの値に関する情報を受け取り、この情報に基づいて、データ送信再開後にネットワークチューナ２００の最初の送信データ（ＴＴＳ）に付与すべきタイムスタンプの値（開始タイムスタンプ値）を求め、決定した開始タイムスタンプ値を記録した録画ストリーミング要求を、データ送受信部２５３を介してネットワークチューナ２００に対して出力する。
【０１７０】
この処理について、図１７を参照して説明する。図１７（ａ）は、通信の中断後、録画コンテンツのストリーミング配信の再開要求をネットワークチューナ２００に対して送信するクライアント２５０とネットワークチューナ２００との間の通信処理シーケンスを示している。まず、ステップＳ５０１において、クライアント２５０は、ネットワークチューナ２００に対して録画コンテンツのストリーミング配信の再開要求を出力する。
【０１７１】
この送信再開要求データの具体例が図に示す送信再開要求データ６０１である。このデータ６０１はコンテンツＵＲＬを設定したＨＴＴＰ  ＧＥＴの送信データであり、ＨＴＴＰのヘッダに開始タイムスタンプ値の設定情報を記述している。すなわち、クライアント２５０の記憶部２５１に格納した最新のタイムスタンプ値情報に基づいて、データ送信再開後にネットワークチューナ２００の最初の送信データ（ＴＴＳ）に付与すべきタイムスタンプの値である開始タイムスタンプ値６２１が記録されている。すなわち、
［Ｘ−ｓｔａｒｔＴｉｍｅＳｔａｍｐ：０２ｅｄｆ］
である。
【０１７２】
コンテンツ提供サーバとしてのネットワークチューナ２００のタイムスタンプ管理部２０７は、送信再開要求データ６０１を受け取り、送信再開要求データ６０１に含まれる開始タイムスタンプ値６２１、すなわち、
［Ｘ−ｓｔａｒｔＴｉｍｅＳｔａｍｐ：０２ｅｄｆ］
この開始タイムスタンプ値［０２ｅｄｆ］を受け取り、放送波受信部２０１から受け取ったＭＰＥＧ２−ＴＳデータにその値［０２ｅｄｆ］から始まるタイムスタンプを付加して生成したＭＰＥＧ２−ＴＴＳデータをサーバ暗号処理部２０８に渡し暗号化の後、データ送受信部２０４からクライアントに出力される。
【０１７３】
図１７に示す例では、ＨＴＴＰのヘッダに開始タイムスタンプ値の設定情報を記述した例であり、クライアント２５０は「ストリーミングデータのタイケスタンプを０２ｅｄｆ（１６進数）から開始して下さい。」という要求をネットワークチューナ２００に送信した例である。この要求を受け取ったネットワークチューナ（サーバ）２００は、［０２ｅｄｆ］の開始タイムスタンプ値で始まるＭＰＥＧ２−ＴＴＳデータの送信を開始する。
【０１７４】
このようにして、図１７に示すステップＳ５０２においてネットワークチューナ２００からクライアント２５０に対して送信されるデータ（ＴＴＳ）に設定されたタイムスタンプは、クライアント２５０の記憶部２５１に格納済みのデータに設定されたタイムスタンプの値と連続性が保持されることになる。
【０１７５】
クライアント２５０が、通信障害復旧後にネットワークチューナ２００に要求する開始タイムスタンプ値は、通常、クライアント暗号処理部２５６がそれまでに記憶部２５１に保存したデータの最後のタイムスタンプの値に連続するの「次」の値とすればよい。
【０１７６】
ただし、クライアント暗号処理部２５６における処理の都合上、記憶部２５１に保存した録画データの最後のタイムスタンプの値が求められず、ある程度前の値しか求められない場合、その値をそのまま開始タイムスタンプ値として要求し、記憶部２５１に保存済みのデータ中から、開始タイムスタンプ値以降のデータを破棄してしまう構成としてもよい。
【０１７７】
なお、上述した実施例では、ネットワークチューナ２００は、クライアントから要求された開始タイムスタンプ値をそのまま再開送信データに設定する値として利用したが、クライアント側からネットワークチューナ（サーバ）に対して通知するタイムスタンプ情報をクライアントにおいて受信済みの最新のタイムスタンプ値として、サーバ側で、そのタイムスタンプ値に連続する次のタイムスタンプ値を算出して、算出したタイムスタンプ値を送信再開データに対して設定する構成としてもよい。
【０１７８】
本実施例の構成によれば、
１．クライアント側での録画処理時にタイムスタンプの連続性が保てるため、クライアントの記憶部に暗号化して保存されているデータを他のクライアント等に転送する際、タイムスタンプを付け直すという高負荷な作業が必要なくなる。
２．録画処理の実行に際して、コンテンツ送信要求としてクライアントからネットワークチューナに送信するＨＴＴＰリクエスト（ＨＴＴＰ  ＧＥＴ）のヘッダに要求する開始タイムスタンプ値を付加するという簡易な処理が可能であり、既存のプロトコルの枠組みで実現することが可能である。
このようなメリットがある。
【０１７９】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
【０１８０】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０１８１】
例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０１８２】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０１８３】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【産業上の利用可能性】
【０１８４】
以上、説明したように、本発明の一実施例の構成によれば、放送データを受信しネットワーク接続されたクライアントに受信データを出力するサーバと、前記サーバから受信するデータの再生または記録を行なうクライアントとを有する通信システムにおいて、サーバがクライアントから入力する録画予約情報に基づく録画予約リストを生成してクライアントに提供し、クライアントは、録画予約リストに記録された録画予約情報に基づいて録画予定コンテンツの取得要求を実行し、サーバ側で時間の重複する複数のコンテンツ取得要求データに対して、コンテンツ送信処理を実行する要求データを選択し、選択された要求データに対してはコンテンツ送信許諾応答を行い要求コンテンツの送信を実行するとともに、選択されなかった要求データの応答としては要求が実行されないことを示す応答を行なう構成としたので、クライアントは時間の重複するコンテンツについての選択処理などを行なうことなく自己の設定した録画予約に基づくコンテンツ送信要求を行うのみとなり、処理負荷が軽減される。
【０１８５】
また、本発明の一実施例の構成によれば、録画予約情報にサーバ側で決定した録画実行時間や、放送受信部の受信した現在時刻情報を記録してクライアントに提供する構成としたので、クライアント側ではこれらの情報に基づく正確なコンテンツ取得要求が実現される。
【０１８６】
また、本発明の一実施例の構成によれば、サーバとクライアント間の通信中断などが発生した場合のサーバの設定するタイムスタンプの値をクライアント側で決定したサーバに通知することを可能としたので、タイムスタンプの連続性が保持され、クライアントがサーバとなってデータを送信する場合に設定済みのタイムスタンプを書き換える必要がなく処理負荷が軽減される。
【図面の簡単な説明】
【０１８７】
【図１】本発明の情報処理装置の適用可能なネットワーク環境について説明する図である。
【図２】ネットワークチューナの第１実施例の構成例について説明する図である。
【図３】クライアントからネットワークチューナに出力される予約リスト閲覧要求であるＣＤＳ  Ｂｒｏｗｓｅ要求のデータ構成例について説明する図である。
【図４】クライアントからネットワークチューナに出力される予約リスト閲覧要求であるＣＤＳ  Ｂｒｏｗｓｅ要求に対する応答として、ネットワークチューナがクライアントに対して提供する予約リスト情報のデータ構成例について説明する図である。
【図５】予約リストに基づいてクライアントの表示部に表示される表示データの例について説明する図である。
【図６】録画予約リストに基づく録画開始の際の処理シーケンスについて説明する図である。
【図７】クライアントからのコンテンツ送信要求（ＨＴＴＰ  ＧＥＴ）に対するネットワークチューナの対応の変化と時刻の関係を表したタイムチャートを示す図である。
【図８】ネットワークチューナの第２実施例の構成例について説明する図である。
【図９】録画時間の重複する録画予約に対する録画実行例について説明する図である。
【図１０】予約リスト閲覧要求（ＣＤＳ  Ｂｒｏｗｓｅ）の受信に応じてクライアントに提示される予約リストの例を示す図である。
【図１１】番組の放送時間が放送局の都合で変更された場合の処理例について説明する図である。
【図１２】番組の放送時間が放送局の都合で変更された場合の処理例について説明する図である。
【図１３】ネットワークチューナの第３実施例の構成例について説明する図である。
【図１４】録画を実行するクライアントが、ネットワークチューナから予約リストを受信する処理シーケンス、および予約リストのデータ構成例について説明する図である。
【図１５】ＭＰＥＧ２−ＴＴＳの構成例について説明する図である。
【図１６】ネットワークチューナの第４実施例の構成例について説明する図である。
【図１７】開始タイムスタンプ値を記録した録画ストリーミング要求の送信による処理シーケンス、および録画ストリーミング要求データのデータ構成例について説明する図である。
【符号の説明】
【０１８８】
１２１，１２２  アンテナ
１５０  ネットワーク
２００  ネットワークチューナ
２０１  放送受信部
２０２  暗号処理部
２０３  データ蓄積部（バッファ）
２０４  データ送受信部
２０５  情報更新監視部
２０６  サーバ時刻情報管理部
２０７  タイムスタンプ管理部
２０８  サーバ暗号処理部
２５０，２６０  クライアント
２５１，２６１  記憶部
２５２  クライアント録画予約情報管理部
２５３  データ送受信部
２５４  録画処理部
２５５  クライアント時刻情報管理部
２５６  クライアント暗号処理部
３０１  ＣＤＳ  Ｂｒｏｗｓｅ要求データ
３０２  録画予約リスト
３１１，３１２，３１３  録画予約データ
３２０  表示データ
４０１  録画予約リスト
４１１，４１２，４１３  録画予約データ
４２１  録画予約番組の番組開始時間情報
４２２  録画予約番組の番組終了時間情報
４２３  録画実行開始時間情報
４５１  更新通知［ＧＥＮＡ  Ｎｏｔｉｆｙ］データ
４５２  録画予約リスト
４６１，４６２  予約情報
４７１  録画予約番組の番組終了時間情報
４７２  録画実行開始時間情報
５０１  録画予約リスト
５１１  録画番組の開始時刻情報
５１２  現在時刻情報
６０１  送信再開要求データ
６２１  開始タイムスタンプ値
【図３】
2008199436.tif 000003
【図４】
2008199436.tif 000004
【図６】
2008199436.tif 000005
【図７】
2008199436.tif 000006
【図９】
2008199436.tif 000007
【図１０】
2008199436.tif 000008
【図１１】
2008199436.tif 000009
【図１２】
2008199436.tif 000010
【図１４】
2008199436.tif 000011
【図１７】
2008199436.tif 000012
【図１】
2008199436.tif 000013
【図２】
2008199436.tif 000014
【図５】
2008199436.tif 000015
【図８】
2008199436.tif 000016
【図１３】
2008199436.tif 000017
【図１５】
2008199436.tif 000018
【図１６】
2008199436.tif 000019