(57)【要約】  ＥＰＧから設定される予約録画は予めリソースを利用する時間帯が指定されるが、ＥＰＧから設定される再生はリソースを利用する時間帯は未定である。従って、複数の予約録画間のリソース配分は事前に行うことが可能であるが、予約録画と再生が同一リソースを利用する場合の調停は、事前に行うことは不可能である。しかし予約録画の開始時刻になってから調停処理を行った場合、調停処理自身に時間がかかり、予約録画が開始時刻から指定通りに開始されない恐れがある。予約録画と再生のリソース調停を、予約録画の開始時刻に先立って開始する。どのくらい先立ってリソース調停を開始するかはＥＰＧが指定可能とする。
2008543123.tif 000002
【特許請求の範囲】
【請求項１】
受信した映像情報および音声情報を記録媒体に記録する記録手段と、
前記受信した映像情報および音声情報、または前記記録手段により記録された前記映像情報および前記音声情報を再生する再生手段とを備えた放送受信端末であって、
前記放送受信端末内で実行される第１のプログラムからの要求に従い、前記記録処理を実行する開始時刻および前記記録処理を継続する継続時間を含む予約情報を登録する予約登録手段と、
前記予約登録手段により登録された予約情報を保持する予約保持手段と、
リソース管理手段が管理するリソースが競合する場合、前記競合を解決するための基準を保持する特権プログラムと、
前記第１のプログラムより予約した前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの排他的使用が可能かどうかを調べ、前記所定のリソースが既に前記放送受信端末内で実行される第２のプログラムにより確保されている場合は、前記特権プログラムが定める基準に従って、どちらのプログラムが前記所定のリソースを確保すべきかについて判定処理を行うリソース競合解決手段と、
前記予約保持手段が保持する開始時刻よりもどれくらい前に前記リソース競合解決手段を機能させるかを示す時間間隔情報を保持する解決時間間隔保持手段と、
前記第１のプログラム、前記第２のプログラム、および前記特権プログラムを実行する実行手段とを備え、
前記放送受信端末の電源投入後に前記特権プログラムは受信されて記録され、
前記予約保持手段が保持する前記記録処理を実行する開始時刻よりも前の時刻であって、前記解決時間間隔保持手段が保持する時間間隔に相当する前の時刻になった時点で、前記リソース競合解決手段は機能し、
前記リソース競合解決手段により前記所定のリソースを確保すべきと判定されたプログラムが前記所定のリソースを確保し、前記確保されたリソースを用いて所定の処理または予約に従った記録処理を実行する
ことを特徴とする放送受信端末。
【請求項２】
前記放送受信端末は、さらに、
前記放送受信端末内で実行されるプログラムからの要求に従い、所定の処理をするために前記放送受信端末内で排他的に使用されるリソースを前記リソースの使用を要求するプログラムに対応付けて管理するリソース管理手段を備え、
前記リソース競合解決手段は、前記リソース管理手段にて管理されるリソースを調べることにより、前記所定のリソースが既に前記放送受信端末内で実行される第１のプログラムにより確保されているかどうかを判断する
ことを特徴とする請求項１記載の放送受信端末。
【請求項３】
前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、
前記リソース管理手段は、前記所定のリソースを前記第２のプログラムと対応付けて管理するのを止め、前記第１のプログラムから要求に従って、前記放送受信端末内で排他的に使用される前記所定のリソースを前記第１のプログラムに対応付けて管理する
ことを特徴とする請求項２記載の放送受信端末。
【請求項４】
前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、
前記リソース管理手段は、前記第２のプログラムへ、前記確保した前記放送受信端末内のリソースを解放することを通知する
ことを特徴とする請求項３記載の放送受信端末。
【請求項５】
前記第１のプログラムおよび前記第２のプログラムは実行の優先度を示す情報を有し、
前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、優先度の高いプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項６】
前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項７】
前記特権プログラムは、解決時間間隔保持手段に保持される時間間隔を指定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項８】
前記放送受信端末は、さらに、
前記リソース競合解決手段がいずれのプログラムからの要求を受け入れるのかを判定するための判定ポリシーを登録する判定ポリシー登録手段と、
前記判定ポリシー登録手段により登録された判定ポリシーを保持する判定ポリシー保持手段とを備え、
前記特権プログラムは、前記判定ポリシー登録手段を用いて前記判定ポリシーを登録し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記判定ポリシー保持手段にて保持されている判定ポリシーを用いて、いずれのプログラムが前記所定のリソースを確保すべきかを判定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項９】
前記判定ポリシー保持手段は、
前記第１のプログラムからの要求に従い記録を優先するか前記第２のプログラムからの要求に従い所定の処理を優先するかを表すフラグを、前記判定ポリシーとして保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記フラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１０】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する時間帯を保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、開始時刻が前記記録を優先する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１１】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する時間帯を保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記予約した時間帯が前記判定ポリシー保持手段にて保持する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１２】
前記判定ポリシー保持手段は、
記録を優先する映像情報および音声情報に対応するチャンネル識別子を、前記判定ポリシーとして保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、記録対象となる映像情報および音声情報に対応するチャンネルのチャンネル識別子が前記判定ポリシー保持手段にて保持されているチャンネル識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１３】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する番組の番組識別子を保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、
記録対象となる映像情報および音声情報に対応する番組の番組識別子が前記判定ポリシー保持手段にて保持されている番組識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１４】
番組識別子は複数の番組を指定する
ことを特徴とする請求項１３記載の放送受信端末。
【請求項１５】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する前記放送受信端末内のリソースを保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、判定処理を終了し、
前記放送受信端末内で実行される第２のプログラムにより確保されているリソースが前記判定ポリシー保持手段にて保持されているリソースに含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１６】
前記予約登録手段は、前記予約情報と共に、前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの競合が発生した場合に記録を優先するか前記所定の処理を優先するかを示すフラグを受け取り、
前記予約保持手段は、前記フラグを予約情報と関連付けて保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記記録手段は、前記リソース競合解決手段による判定処理を終了させ、
前記予約情報に対応するフラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを前記リソース競合解決手段に判定させる
ことを特徴とする請求項１記載の放送受信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを蓄積するとともに、蓄積されたコンテンツを再生する録画再生装置たる放送受信端末に関する。殊に、映像、音声およびプログラム等のデータから構成されるコンテンツが相互に同期をとって放送波に多重されて送信され、その放送波を受信して映像、音声、データを蓄積するための仕組み、および、映像、音声とプログラム等のデータの同期を保持しつつコンテンツの早送り、巻戻し等の特殊再生を実行する仕組みに関する。
【背景技術】
【０００２】
放送局から送信される放送波は、多種多様なコンテンツを含んでいる。コンテンツは、通常の番組で用いられる映像、音声の他に、データを含む場合がある。データの送信方法にはいくつかの方式があり、大別して時系列に送信する方式と、一定の間隔ごとに繰り返し送信する方式がある。前者の時系列に送信する方式では、例えば時間経過に合わせて連続するデータを順次送出していく。大量のデータを長時間かけて送信する場合に適しているが、送信タイミングで受信しなかった場合は二度と受信できないという欠点がある。一方、後者の一定の間隔ごとに繰り返し送信する方式では、同じデータを一定の期間何度も繰り返し送出する。同一データを送出している期間内に、繰り返し送信されているデータのいずれかひとつを受信すればよいので、受信タイミングが限定されないというメリットがある。例えば、ＢＭＬに代表されるデータ放送や、ＤＳＭＣＣデータカルーセルによるファイル送信がこの方式である。特に放送においては、受信者がいつ選局して受信を開始するかわからない。時系列に送信する方式では、受信開始が送信時間よりも遅れてしまい、データ取得に失敗すると二度と再取得できない。よって、放送波で映像、音声とともにアプリケーションプログラム等のデータを送信したい場合には、一定の間隔ごとに繰り返し送信される方式が好適である。
【０００３】
現在、上記のような方式で、映像、音声とアプリケーションプログラムとを含む放送波を受信し、アプリケーションプログラムを映像、音声と同期して実行するための仕様が策定され、運用されている。通常の映像、音声を見るだけでなく、送信されたアプリケーションプログラムを受信して端末に取り込み、それを実行して様々な付加機能を実現することができる。このようにアプリケーションプログラムを送信して端末に取り込む方法はダウンロードとも呼ばれている。例えば、ＤＶＢ−ＭＨＰ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ−Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ）ＥＴＳＩ  ＥＳ  ２０１  ８１２  Ｖ１．１．１（２００３−１２））仕様が欧州で策定され、既に仕様に準拠した運用が開始されている。また米国ではケーブル放送環境で同様の仕組みを提供するＯＣＡＰ１．０（ＯｐｅｎＣａｂｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｌａｔｆｏｒｍ  ＯＣ−ＳＰ−ＯＣＡＰ１．０−Ｉ１４−０５０１１９）仕様書が策定されており、２００５年に運用開始予定である。これらの仕様では、アプリケーションがＪａｖａ言語で記述されている。端末上にはチューニングやグラフィックス表示のための様々なＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）が用意されており、ＪａｖａアプリケーションはＡＰＩを呼び出すことでそれらの機能を制御できる。
【０００４】
さらに、北米では、ＯＣＡＰ仕様にコンテンツの録画再生機能を追加するためのＯＣＡＰ−ＤＶＲ仕様（ＯＣ−ＳＰ−ＯＣＡＰ−ＤＶＲ−Ｉ０１−０４０５２４）を策定中である。これは放送されるコンテンツ（映像、音声、アプリケーション等）を記録し、さらに記録したコンテンツを、放送されるコンテンツと同様に再生するものである。
【０００５】
ＯＣＡＰ−ＤＶＲ仕様では、録画予約ＡＰＩが規定され、Ｊａｖａアプリケーションは本ＡＰＩを利用することで、録画予約を登録することが可能である。Ｊａｖａアプリケーションが録画予約ＡＰＩを用いて登録した録画予約に基づき、ＯＣＡＰ−ＤＶＲ端末は指定録画開始時刻に録画を開始、指定録画終了時刻に録画を終了する。
【０００６】
ＯＣＡＰ及びＯＣＡＰ−ＤＶＲ仕様が規定する様々な機能は、端末に存在するデバイスを利用することで実現される。例えば、放送信号に含まれる映像・音声を再生するためには、放送信号から単一のデータストリームを抽出するチューナ、チューナが出力するデータストリームから映像・音声を取り出すＴＳデコーダ、取り出された映像・音声をデコードして再生するＡＶデコーダといったデバイスを利用する。つまり、端末の能力は端末が搭載するデバイスが決定する、と言うことができる。例えば、前述のチューナは放送信号を受信して映像音声再生するときだけでなく、放送信号を録画する際にも用いられる。チューナは放送信号から同時に複数のデータストリームを抽出することはできないため、「映像音声の再生」と、「録画」を同時に実行するためには、２つのチューナが必要になる。従って１つのチューナのみを搭載する端末では「映像音声再生」及び「録画」を同時に実行することはできない。
【０００７】
ＯＣＡＰ−ＤＶＲにおいて、複数のＪａｖａアプリケーションが同時に実行されることがある。各々のＪａｖａアプリケーションは独立して動作し、両方がＯＣＡＰ及びＯＣＡＰ−ＤＶＲの規定ＡＰＩを利用して所望の機能実現を果たそうとする。例えば、ＪａｖａアプリケーションＡが行った録画予約の開始時刻付近でＪａｖａアプリケーションＢが「映像音声再生」を要求することも想定される。このような場合、もし２チューナを搭載する端末であれば、特に問題はなく、「映像音声再生」及び「録画」を同時に実行可能である。しかし、１チューナのみを搭載する端末では、デバイスの絶対数が足りないため、同時に両方の処理を実行することができない。このように、「デバイスの絶対数または能力が不足しているため、要求される複数の処理を同時に実行できない状況」を一般に「競合」と呼ぶ。これは１チューナの時だけ起こる状況と言うわけではない。２チューナを搭載する端末であっても、「映像音声再生」及び２チャンネルの「録画」を同時に処理することが要求されることはあり得、その場合はやはり全ての処理を同時に実行することはできないために「競合」が発生する。
【０００８】
このような「競合」、特に録画予約に関する競合を解決するためのアルゴリズムを定義する知財は既に存在する。特願２００３−６４４５は、「録画予約と追っかけ再生用の録画が同時に要求され、デバイスの競合が起こった際は、常に録画予約を優先する」というデバイス競合ポリシーに関する特許である。このようなポリシーを事前に決定しておくことで、端末は競合を解決し、どちらか一方を優先して処理を進めることができる。
【０００９】
特願２００３−６４４５のように録画予約が絡むデバイス競合の解決ポリシーを事前に決定しておくことで、デバイス競合が実際に起こったときに、どちらの処理を優先するか判断し、処理を進めることができる。しかしながら、これは端末内部で自由にデバイス競合の解決を行い、実行する処理を決定してよい場合だけに適用可能な、端末独自のポリシーである。ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様といったＪａｖａ仕様のいくつかは、デバイス競合が起こったときの解決手順を規定している。典型的な例として、ここでは、ＯＣＡＰが規定する２種類のデバイス競合解決手順をまず紹介する。ＯＣＡＰ仕様に準拠した端末は、放送信号に含まれるＪａｖａアプリケーションをダウンロードして実行することは既に述べた。この端末上では１以上のＪａｖａアプリケーションが同時に動作し、各々が所望の機能を実現するためにＪａｖａＡＰＩを利用するため、端末は同時に複数の処理を要求されることがありうる。このような状況が発生し、デバイスの絶対数が足りないためにデバイスの競合が起こったときにデバイス競合解決が行われる。
【００１０】
第一の手順では、Ｊａｖａアプリケーションの優先度を利用して、デバイス競合解決を行う。ＯＣＡＰ仕様では、各Ｊａｖａアプリケーションは固有の優先度を持っており、高い優先度を持つＪａｖａアプリケーション程重要なアプリケーションである、と位置づけられる。そのため、複数のＪａｖａアプリケーションが同時に行われる複数の処理を要求した場合、より優先度の高いＪａｖａアプリケーションが要求した処理を優先的に動作させる。
【００１１】
第二の手順では、Ｊａｖａアプリケーションの優先度とは関係なく、ある特殊アプリケーションが、優先すべきＪａｖａアプリケーションを決定する。ＯＣＡＰ仕様にはある特権を持ったアプリケーションが定義される。これをモニタアプリケーションと呼ぶ。モニタアプリケーションは、デバイスの競合が起こったときに端末によって呼び返される「デバイス競合解決用のコールバック関数」を事前に端末に登録することができる。この「コールバック関数」が登録されている場合、端末がデバイスの競合が起こったことを検知したら、Ｊａｖａアプリケーションの優先度による判断を行う前に、このコールバック関数を呼ぶ。このコールバック関数は、返値として、優先すべきＪａｖａアプリケーションの識別子を端末に引き渡す。端末はＪａｖａアプリケーション自身に設定された優先度に関係なく、このコールバック関数の返値として引き渡されたＪａｖａアプリケーションが要求する処理を優先的に実行する。
【００１２】
特に第二の手順においては、デバイス競合の解決は完全にモニタアプリケーションに任される。端末はモニタアプリケーションのコールバック関数が返した返値に従ってデバイスを振り分けるのみである。つまり、デバイス競合が起こったときの解決ポリシーは、この場合、端末ではなくモニタアプリケーションが制御している、と捉えられる。
【００１３】
上記デバイス競合解決用のコールバック関数は、モニタアプリケーションによって実装される。ある実装は、単にＪａｖａアプリケーションの優先度をコールバック関数の内部で判断しているだけかもしれない。ある実装は、画面に選択肢ダイアログを提示して、どちらを優先するかユーザの入力を１分間待っているかもしれない。またある実装は、ユーザに選択肢ダイアログを提示して、どちらを優先するかユーザ入力を永久に待ち続けるかもしれない。つまり、端末がこのコールバック関数がいつリターンするかを予測することは不可能であり、ひいては、端末はコールバック関数がリターンするまでは、どちらの処理を優先して実行するか決定することができない。
【００１４】
これは、録画予約にとっては致命的なシステム欠陥である。例えば、「予約録画」と「映像音声再生」が同時に２つのＪａｖａアプリケーションによって要求され、デバイス競合が起こった場合を考える。この時、もしデバイス競合解決用コールバック関数が登録されていれば、端末はＯＣＡＰまたはＯＣＡＰ-ＤＶＲ仕様に従って、そのコールバック関数を呼ばなければならない。しかし、もし予約録画開始時刻になってもコールバック関数が判定結果をリターンしなければ、端末は再生も録画もできずにずっと待っているより他ない。
【００１５】
そこで本発明は、かかる問題に鑑みてなされたものであって、リソースの競合を解決する録画再生装置を提供することを目的とする。
【発明の開示】
【００１６】
上記目的を達成するために、本発明の放送受信端末は、受信した映像情報および音声情報を記録媒体に記録する記録手段と、前記受信した映像情報および音声情報、または前記記録手段により記録された前記映像情報および前記音声情報を再生する再生手段とを備えた放送受信端末であって、前記放送受信端末内で実行される第１のプログラムからの要求に従い、前記記録処理を実行する開始時刻および前記記録処理を継続する継続時間を含む予約情報を登録する予約登録手段と、前記予約登録手段により登録された予約情報を保持する予約保持手段と、リソース管理手段が管理するリソースが競合する場合、前記競合を解決するための基準を保持する特権プログラムと、前記第１のプログラムより予約した前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの排他的使用が可能かどうかを調べ、前記所定のリソースが既に前記放送受信端末内で実行される第２のプログラムにより確保されている場合は、前記特権プログラムが定める基準に従って、どちらのプログラムが前記所定のリソースを確保すべきかについて判定処理を行うリソース競合解決手段と、前記予約保持手段が保持する開始時刻よりもどれくらい前に前記リソース競合解決手段を機能させるかを示す時間間隔情報を保持する解決時間間隔保持手段と、前記第１のプログラム、前記第２のプログラム、および前記特権プログラムを実行する実行手段とを備え、前記放送受信端末の電源投入後に前記特権プログラムは受信されて記録され、前記予約保持手段が保持する前記記録処理を実行する開始時刻よりも前の時刻であって、前記解決時間間隔保持手段が保持する時間間隔に相当する前の時刻になった時点で、前記リソース競合解決手段は機能し、前記リソース競合解決手段により前記所定のリソースを確保すべきと判定されたプログラムが前記所定のリソースを確保し、前記確保されたリソースを用いて所定の処理または予約に従った記録処理を実行することを特徴とする。
【００１７】
これにより、所定の処理と予約に従った記録処理とによるリソースの競合を解決することができる。
【００１８】
また、前記放送受信端末は、さらに、前記放送受信端末内で実行されるプログラムからの要求に従い、所定の処理をするために前記放送受信端末内で排他的に使用されるリソースを前記リソースの使用を要求するプログラムに対応付けて管理するリソース管理手段を備え、前記リソース競合解決手段は、前記リソース管理手段にて管理されるリソースを調べることにより、前記所定のリソースが既に前記放送受信端末内で実行される第１のプログラムにより確保されているかどうかを判断することを特徴としてもよい。
【００１９】
これにより、所定のリソースの排他的使用が可能かどうかを確実に調べることができる。
【００２０】
また、前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、前記リソース管理手段は、前記所定のリソースを前記第２のプログラムと対応付けて管理するのを止め、前記第１のプログラムから要求に従って、前記放送受信端末内で排他的に使用される前記所定のリソースを前記第１のプログラムに対応付けて管理することを特徴としてもよい。
【００２１】
これにより、所定のリソースとそのリソースを確保しているプログラムとの対応関係を正確に管理することができる。
【００２２】
また、前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、前記リソース管理手段は、前記第２のプログラムへ、前記確保した前記放送受信端末内のリソースを解放することを通知することを特徴としてもよい。
【００２３】
これにより、リソースの排他的使用を確実にすることができる。
【００２４】
また、前記第１のプログラムおよび前記第２のプログラムは実行の優先度を示す情報を有し、前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、優先度の高いプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００２５】
これにより、リソース競合解決手段による判定処理が終了しなかった場合にプログラムの優先度を用いたリソースの競合解決が可能となる。
【００２６】
また、前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００２７】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に強制的に記録処理を開始することが可能となる。
【００２８】
また、前記特権プログラムは、解決時間間隔保持手段に保持される時間間隔を指定することを特徴としてもよい。
【００２９】
これにより、使い勝手を向上することができる。
【００３０】
また、前記放送受信端末は、さらに、前記リソース競合解決手段がいずれのプログラムからの要求を受け入れるのかを判定するための判定ポリシーを登録する判定ポリシー登録手段と、前記判定ポリシー登録手段により登録された判定ポリシーを保持する判定ポリシー保持手段とを備え、前記特権プログラムは、前記判定ポリシー登録手段を用いて前記判定ポリシーを登録し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記判定ポリシー保持手段にて保持されている判定ポリシーを用いて、いずれのプログラムが前記所定のリソースを確保すべきかを判定することを特徴としてもよい。
【００３１】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、判定ポリシーを用いたリソース競合解決をすることが可能となる。
【００３２】
また、前記判定ポリシー保持手段は、前記第１のプログラムからの要求に従い記録を優先するか前記第２のプログラムからの要求に従い所定の処理を優先するかを表すフラグを、前記判定ポリシーとして保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記フラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを判定することを特徴としてもよい。
【００３３】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、フラグによるリソース競合解決が可能となる。
【００３４】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する時間帯を保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、開始時刻が前記記録を優先する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００３５】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、時間帯ごとのリソース競合解決が可能となる。
【００３６】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する時間帯を保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記予約した時間帯が前記判定ポリシー保持手段にて保持する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００３７】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、時間帯ごとのリソース競合解決が可能となる。
【００３８】
また、前記判定ポリシー保持手段は、記録を優先する映像情報および音声情報に対応するチャンネル識別子を、前記判定ポリシーとして保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、記録対象となる映像情報および音声情報に対応するチャンネルのチャンネル識別子が前記判定ポリシー保持手段にて保持されているチャンネル識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００３９】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、チャンネルごとのリソース競合解決が可能となる。
【００４０】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する番組の番組識別子を保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、記録対象となる映像情報および音声情報に対応する番組の番組識別子が前記判定ポリシー保持手段にて保持されている番組識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００４１】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、番組ごとのリソース競合解決が可能となる。
【００４２】
また、番組識別子は複数の番組を指定することを特徴としてもよい。
【００４３】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、番組シリーズごとのリソース競合解決が可能となる。
【００４４】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する前記放送受信端末内のリソースを保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記放送受信端末内で実行される第２のプログラムにより確保されているリソースが前記判定ポリシー保持手段にて保持されているリソースに含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００４５】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、リソースごとのリソース競合解決が可能となる。
【００４６】
また、前記予約登録手段は、前記予約情報と共に、前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの競合が発生した場合に記録を優先するか前記所定の処理を優先するかを示すフラグを受け取り、前記予約保持手段は、前記フラグを予約情報と関連付けて保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記記録手段は、前記リソース競合解決手段による判定処理を終了させ、前記予約情報に対応するフラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを判定することを特徴としてもよい。
【００４７】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、予約情報毎に管理されるフラグによってリソース競合解決が可能となる。
【００４８】
なお、本発明は、上記放送受信端末や録画再生装置、放送受信方法、録画再生方法、プログラム、及びそのプログラムを格納する記憶媒体としても実現することができる。
【００４９】
［本願の背景技術に関する詳細情報］
２００５年５月３１日に出願された、明細書と図面と請求項とを含む米国仮出願番号６０／６８５，３８０を本願に引用して援用する。
【発明を実施するための最良の形態】
【００５０】
本発明は、録画等の処理に利用される録画リソースと、前記録画リソースを管理する録画リソース管理手段と、録画予約を保持する録画予約保持手段と、前記録画予約保持手段に前記録画予約を登録する録画予約登録手段と、録画リソースが利用可能かどうか調査し、録画リソースが既に他処理によって利用されていた場合は、プログラムに質問することでどちらの処理に前記録画リソースを利用するか判定処理を行う録画リソース競合解決手段と、前記録画リソース競合解決手段が行う判定処理を、前記録画予約の録画開始時刻にどれくらい先立って行うかを表現する間隔を保持する解決間隔保持手段と、前記解決間隔保持手段に解決間隔を登録する解決間隔登録手段と、前記録画予約に基づいて録画を開始する録画手段と、を備えることで、設定した時間だけ録画開始に先立ちリソースの競合解決を行うことが可能となる。
【００５１】
また、前記録画リソース管理手段は、前記録画リソースを他処理に利用するプログラムの優先度を保持し、前記録画予約保持手段は、録画予約を登録したプログラムの優先度を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、録画リソース解決手段にリソース解決処理の終了を指令し、プログラム優先度を用いた判定として、録画リソースを他処理に利用するプログラムの優先度１と、録画予約を登録したプログラムの優先度２を比較し、前記優先度１が高ければ他処理を継続し、前記優先度２が高ければ、録画処理を開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にプログラムの優先度を用いたリソースの競合解決が可能となる。
【００５２】
また、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画を強制的に開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に強制的に録画を開始することが可能となる。
【００５３】
また更に、リソース配分ポリシーを保持するリソース配分ポリシー保持部と前記リソース配分ポリシーを登録するリソース配分ポリシー登録部とを具備し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、前記リソース配分ポリシーを利用してリソース解決を行って録画を開始するかどうか決定することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、リソース配分ポリシーを用いたリソース競合解決をすることが可能となる。
【００５４】
また、前記リソース配分ポリシー保持手段は、前記リソース配分ポリシーとして録画を優先するか他処理を優先するかを表すフラグを保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、前記フラグが真であれば、録画を開始し、偽であれば他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、フラグによるリソース競合解決が可能となる。
【００５５】
また、前記リソース配分ポリシー保持手段は、前記リソース配分ポリシーとして録画を優先する時間帯を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画開始時刻が時間帯に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、時間帯毎のリソース競合解決が可能となる。
【００５６】
また、前記リソース配分ポリシー保持手段は、前記リソース配分ポリシーとして録画を優先する時間帯を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画時間帯が完全に時間帯に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、時間帯毎のリソース競合解決が可能となる。
【００５７】
また、前記リソース配分ポリシー保持手段は、リソース配分ポリシーとして録画を優先するチャンネル識別子を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画対象チャンネルのチャンネル識別子がチャンネル識別子に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、チャンネル毎のリソース競合解決が可能となる。
【００５８】
また、前記リソース配分ポリシー保持手段は、リソース配分ポリシーとして録画を優先する番組識別子を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画対象番組の番組識別子が番組識別子に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、番組毎のリソース競合解決が可能となる。
【００５９】
また、番組識別子は複数の番組識別子を更に内包することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、番組シリーズ毎のリソース競合解決が可能となる。
【００６０】
また、前記リソース配分ポリシー保持手段は、リソース配分ポリシーとして録画を優先する録画リソースを保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、競合するのが録画リソースであれば録画を開始し、そうでなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、録画リソース毎のリソース競合解決が可能となる。
【００６１】
また、前記録画予約登録手段は、録画予約と共に、録画リソースの競合が発生した場合に録画を優先するか他処理を優先するかを表現するフラグを受け取り、前記録画予約保持手段は、前記フラグを録画予約と共に保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、当該録画予約と共に記録される前記フラグが真であれば録画を開始し、偽であれば他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、録画予約毎に管理されるフラグによってリソース競合解決が可能となる。
【００６２】
また、時間切れコールバックを保持する時間切れコールバック保持手段と、前記時間切れコールバックを登録する時間切れコールバック登録手段を具備し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記時間切れコールバックを呼び出すことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、コールバックを呼ぶことによるリソース競合解決が可能となる。
【００６３】
また、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記時間切れコールバックを呼び出し、呼び出し結果が真であれば前記間隔保持手段が保持する間隔だけ再度待つことで、前記録画リソース解決手段によるリソース解決処理の待ち時間を延長することが可能となる。
【００６４】
また、前記時間切れコールバックの呼び出し結果が偽であれば、他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によっては他処理を継続させることが可能となる。
【００６５】
また、前記時間切れコールバックの呼び出し結果が偽であれば、録画を開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によっては即座に録画を開始することが可能となる。
【００６６】
また、前記時間切れコールバックの呼び出し結果が偽であれば、前記プログラム優先度を用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によっては優先度を用いたリソース競合解決を選択することが可能となる。
【００６７】
また、前記時間切れコールバックの呼び出し結果が偽であれば、前記リソース解決ポリシーを用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によってはリソース解決ポリシーを用いたリソース競合解決を選択することが可能となる。
【００６８】
また、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記時間切れコールバックを呼び出し、呼び出し結果が正の値であれば、結果として得られた正の値が指し示す時間だけ再度待つことで、前記録画リソース解決手段によるリソース解決処理の待ち時間を延長することが可能となる。
【００６９】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、他処理を優先することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によって他処理を優先することが可能となる。
【００７０】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、録画を開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によって録画開始を優先することが可能となる。
【００７１】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、前記プログラム優先度を用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によってプログラム優先度による判定を選択可能となる。
【００７２】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、前記リソース配分ポリシーを用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によってリソース配分ポリシーによる判定を選択することが可能となる。
【００７３】
（実施の形態１）
以下に、本発明の第１の実施形態に係る装置および方法を、図面を参照しながら説明する。本発明は、任意の媒体で送受信されるコンテンツの録画および再生を対象としたものであるが、本実施例ではケーブルテレビ放送システムでの実施の形態を例にとって説明する。ケーブルテレビ放送システムでは、本発明の放送録画再生装置（放送受信端末）は一般的に端末装置と呼ばれる。
【００７４】
図１は、放送システムを構成する装置の関係を表したブロック図であり、放送局側システム１０１および三個の端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３で構成される。放送局側システムと各端末装置間の結合１２１は、ケーブルシステムでは同軸ケーブルや光ファイバでの有線結合である。図１では、１つの放送局側システムに対して三つの端末装置が結合されているが、端末装置の数は任意である。
【００７５】
放送局側システム１０１は、複数の端末装置に対して映像・音声・データ放送用データ等の情報を放送信号に含めて送信する。放送信号は放送システムの運用既定や、放送システムが運用される国・地域の法律により定められた周波数帯域内の周波数を利用して伝送される。
【００７６】
本実施例のケーブルシステムでは、放送信号伝送に利用する周波数帯域は、そのデータの内容と伝送方向（上り、下り）ごとに分割して割り当てる。図２は、周波数帯域の分割の一例を示す表である。周波数帯域は、Ｏｕｔ  Ｏｆ  Ｂａｎｄ（略称ＯＯＢ）とＩｎ−Ｂａｎｄの２種類に大別される。５〜１３０ＭＨｚがＯＯＢに割り当てられ、主に放送局側システム１０１と端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３間の上下双方向データのやり取りに使用される。１３０ＭＨｚ〜８６４ＭＨｚはＩｎ−Ｂａｎｄに割り当てられ、主として、映像・音声を含む下りのみの放送チャンネルに使用される。ＯＯＢではＱＰＳＫ変調方式が、Ｉｎ−ＢａｎｄはＱＡＭ６４またはＱＡＭ２５６変調方式が使用される。変調方式技術については、本発明に関与が薄い公知技術であるので、詳細な説明は省略する。
【００７７】
図３は、ＯＯＢ周波数帯域のさらに詳細な使用の一例である。７０ＭＨｚ〜７４ＭＨｚは放送局側システム１０１からの下りデータ送信に使用され、すべての端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３が、放送局側システム１０１から等しいデータを受け取ることになる。一方、１０．０ＭＨｚ〜１０．１ＭＨｚは端末装置Ａ１１１から放送局側システム１０１への上りデータ送信に使用され、１０．１ＭＨｚ〜１０．２ＭＨｚは端末装置Ｂ１１２から放送局側システム１０１への上りデータ送信に使用され、１０．２ＭＨｚ〜１０．３ＭＨｚは端末装置Ｃ１１３から放送局側システム１０１への上りデータ送信に使用される。これにより、各端末装置固有のデータを各端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３から放送局側システム１０１に独立して送信することができる。図４は、Ｉｎ−Ｂａｎｄの周波数帯に対する使用の一例である。１５０〜１５６ＭＨｚと１５６〜１６２ＭＨｚはそれぞれテレビチャンネル１とテレビチャンネル２に割り当てられ、以降、６ＭＨｚ間隔でテレビチャンネルが割り当てられている。３１０ＭＨｚ以降は、１ＭＨｚ単位でラジオチャンネルに割り当てられている。これらの各チャンネルはアナログ放送として使用してもデジタル放送として使用してもよい。デジタル放送の場合は、ＭＰＥＧ２仕様にもとづいたＴＳパケット形式で伝送され、音声や映像に加え、各種データ放送用データやＥＰＧを構成するための番組編成情報も送信することができる。
【００７８】
放送局側システム１０１は、以上に説明した周波数帯域を利用して端末装置に適切な放送信号を送信するため、ＱＰＳＫ変調部やＱＡＭ変調部等をもつ。また、端末装置からのデータを受信するため、ＱＰＳＫ復調器をもつ。また、放送局側システム１０１は、これら変調部および復調部に関連する様々な機器をもつと考えられる。しかし、本発明は主として端末装置に関わるので、詳細な説明は省略する。
【００７９】
一方、端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３は、放送局側システム１０１からの放送信号を受信し再生するために、ＱＡＭ復調部やＱＰＳＫ復調部を持つ。また、放送局側システム１０１に対して、各端末装置固有のデータを送信するためにＱＰＳＫ変調部を持つ。本発明では、端末装置は放送録画再生装置であり、その詳細な構成は後述する。
【００８０】
放送局側システム１０１は、ＭＰＥＧ２トランスポートストリームを変調して放送信号に含めて伝送する。端末装置は放送信号を受信し、復調してＭＰＥＧ２トランスポートストリームを再現し、その中から必要な情報を抽出して用いる。端末装置に存在するデバイスの機能と接続の構成を説明するため、まずＭＰＥＧ２トランスポートストリームの構成を簡単に述べる。
【００８１】
図５はＴＳパケットの構成を表す図である。ＴＳパケット５００は１８８バイトの長さを持ち、ヘッダ５０１、アダプテーションフィールド５０２、ペイロード５０３からなる。ヘッダ５０１はＴＳパケットの制御情報を保持する。４バイトの長さを持ち、５０４で表される構成をとる。この中に“Ｐａｃｋｅｔ  ＩＤ（以下ＰＩＤ）”と記述されるフィールドを持ち、このＰＩＤの値によって、ＴＳパケットの識別を行う。アダプテーションフィールド５０２は時刻情報等の付加的な情報を保持する。アダプテーションフィールド５０２の存在は必須ではなく、存在しない場合もある。ペイロード５０３は映像・音声やデータ放送用データ等、ＴＳパケットが伝送する情報を保持する。
【００８２】
図６はＭＰＥＧ２トランスポートストリームの模式図である。ＴＳパケットはそのペイロードに映像や音声、データ放送用のデータ等様々な情報を保持する。ＴＳパケット６０１およびＴＳパケット６０３はヘッダにＰＩＤ１００を保持し、ペイロードに映像１に関する情報を保持する。ＴＳパケット６０２およびＴＳパケット６０５はヘッダにＰＩＤ２００を保持し、ペイロードにデータ１に関する情報を保持する。ＴＳパケット６０４はヘッダにＰＩＤ３００を保持し、ペイロードに音声１に関する情報を保持する。このように様々な種類のデータをペイロードに保持したＴＳパケットを混合して一連のシーケンスとして送出することを多重と呼ぶ。ＭＰＥＧ２トランスポートストリーム６００はＴＳパケット６０１〜６０５多重した構成の一例である。
【００８３】
同一ＰＩＤをもつＴＳパケットは同一種類の情報を保持する。そのため、端末装置は多重されたＴＳパケットを受信して、各ＴＳパケットが保持する情報をＰＩＤごとに抽出することで、映像・音声を再現したり、番組編成情報等のデータを再現したりできる。図６においては、ＴＳパケット６０１およびＴＳパケット６０３は共に映像１に関する情報を伝送し、またＴＳパケット６０２およびＴＳパケット６０５は共にデータ１に関する情報を伝送する。
【００８４】
ここで、ペイロードに内包される各種データの形式について説明する。
映像および音声は、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）パケットと呼ばれる形式で表現される。ＰＥＳパケットはある時間帯の映像情報または音声情報を含み、放送録画再生装置は、ＰＥＳパケットを受信することで、そのＰＥＳパケットが内包する映像・音声情報を画面・スピーカに出力することができる。放送局がＰＥＳパケットを途切れなく伝送することで、放送録画再生装置は、映像・音声を途切れなく再生し続けることが可能となる。ＰＥＳパケットは、実際に伝送される際、一つのＴＳパケットのペイロードよりも大きいサイズをもつ場合は分割されて複数のＴＳパケットのペイロードに格納される。図７はＰＥＳパケットを伝送する際の分割例を表す。ＰＥＳパケット７０１は一つのＴＳパケット内のペイロードに格納して伝送するには大きいため、ＰＥＳパケット分割Ａ７０２ａ、ＰＥＳパケット分割Ｂ７０２ｂ、ＰＥＳパケット分割Ｃ７０２ｃに分割され、同一ＰＩＤをもつ三つのＴＳパケット７０３〜７０５によって伝送される。実際には、映像や音声は、複数のＰＥＳパケットのペイロードに含まれるデータを結合して得られるエレメンタリストリーム（ＥＳ）として得られる。このエレメンタリストリームは、ＭＰＥＧ２ Ｖｉｄｅｏ規格やＭＰＥＧ１，２ Ａｕｄｉｏ規格で定義されるデジタル化映像、音声の形式になっている。
【００８５】
一方、番組編成情報やデータ放送用のデータ等の情報はＭＰＥＧ２セクションと呼ばれる形式を用いて表現される。ＭＰＥＧ２セクションは実際に伝送される際、一つのＴＳパケットのペイロードよりも大きいサイズをもつ場合は分割されて複数のＴＳパケットのペイロードに格納される。図８はＭＰＥＧ２セクションを伝送する際の分割例を表す。ＭＰＥＧ２セクション８０１は一つのＴＳパケット内のペイロードに格納して伝送するには大きいため、セクション分割Ａ８０２ａ、セクション分割Ｂ８０２ｂ、セクション分割Ｃ８０２ｃに分割され、同一ＰＩＤをもつ三つのＴＳパケット８０３〜８０５によって伝送される。
【００８６】
図９はＭＰＥＧ２セクションの構造を表現する。ＭＰＥＧ２セクション９００はヘッダ９０１およびペイロード９０２から構成される。ヘッダ９０１はＭＰＥＧ２セクションの制御情報を保持する。その構成はヘッダ構成９０３によって表現される。ペイロード９０２はＭＰＥＧ２セクション９００が伝送するデータを保持する。ヘッダ構成９０３に存在するｔａｂｌｅ＿ｉｄはＭＰＥＧ２セクションの種類を表現し、さらにｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎはｔａｂｌｅ＿ｉｄが等しいＭＰＥＧ２セクション同士を区別する際に用いられる拡張識別子である。ＭＰＥＧ２セクションの使用例として、図１０に番組編成情報を伝送する場合を挙げる。この例では、行１００４に記載されるように、放送信号の復調に必要な情報はヘッダ構成９０３内のｔａｂｌｅ＿ｉｄが６４であるＭＰＥＧ２セクションに記載され、さらにそのＭＰＥＧ２セクションはＰＩＤに１６が付与されたＴＳパケットによって伝送される。
【００８７】
ＭＰＥＧ２セクションの場合、ＰＥＳ形式は存在しない。そのため、ＭＰＥＧ２トランスポートストリームの中の同一ＰＩＤによって識別されるＴＳパケットのペイロードを結合したものをエレメンタリーストリーム（ＥＳ）とする。例えば、図８において、ＭＰＥＧ２セクション８０１を分割して伝送しているＴＳパケット８０３〜８０５はすべてＰＩＤが２００で識別される。これはＭＰＥＧ２セクション８０１を伝送するＥＳである、と言うことができる。
【００８８】
ＭＰＥＧ２トランスポートストリーム内にはさらにプログラムという概念が存在する。プログラムはＥＳの集合として表現され、複数のＥＳをまとめて扱いたい場合に利用される。プログラムを利用すると、映像・音声や、それに付随するデータ放送用データ等を一まとめに扱うことが可能となる。例えば、同時に再生したい映像・音声をまとめて扱う場合、映像ＥＳと、音声ＥＳをプログラムとしてまとめることで、放送録画再生装置はこれら二つのＥＳを１つの番組として同時に再生すべきであることがわかる。
【００８９】
プログラムを表現するために、ＭＰＥＧ２ではＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）およびＰＡＴ（Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅ）と呼ばれる二つのテーブルが利用される。詳細な説明はＩＳＯ／ＩＥＣ１３８１８−１、“ＭＰＥＧ２  Ｓｙｓｔｅｍｓ”仕様を参照されたい。以下ではＰＭＴおよびＰＡＴに関して簡単に説明する。
【００９０】
ＰＭＴはＭＰＥＧ２トランスポートストリーム中に、プログラムの数だけ含まれるテーブルである。ＰＭＴはＭＰＥＧ２セクションとして構成され、ｔａｂｌｅ＿ｉｄは２である。ＰＭＴにはプログラムの識別に用いられるプログラムナンバーとプログラムの付加情報、さらにプログラムに属するＥＳに関する情報を保持する。ＰＭＴの例を図１１に挙げる。１１００はプログラムナンバーである。プログラムナンバーは同一トランスポートストリーム内でプログラムに一意に割り当てられ、ＰＭＴの識別に用いられる。行１１１１〜１１１５は個々のＥＳに関する情報を表現する。列１１０１はＥＳのタイプであり、“映像”、“音声”、“データ”等が指定される。列１１０２はＥＳを構成するＴＳパケットのＰＩＤである。列１１０３はＥＳに関する付加情報である。例えば、行１１１１に表されるＥＳは、音声ＥＳであり、ＰＩＤが５０１１であるＴＳパケットによって伝送される。
【００９１】
ＰＡＴはＭＰＥＧ２トランスポートストリームに一つだけ存在するテーブルである。ＰＡＴはＭＰＥＧ２セクションとして構成され、ｔａｂｌｅ＿ｉｄは０であり、ＰＩＤが０であるＴＳパケットによって伝送される。ＰＡＴには、ＭＰＥＧ２トランスポートストリームの識別に用いられるｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄと、ＭＰＥＧ２トランスポートストリーム内に存在するプログラムを表現するすべてのＰＭＴに関する情報を保持する。ＰＡＴの例を図１２に挙げる。１２００はｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄである。ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄはＭＰＥＧ２トランスポートストリームの識別に用いられる。行１２１１〜１２１３はプログラムに関する情報を表現する。列１２０１はプログラムナンバーである。列１２０２はプログラムに対応するＰＭＴを伝送するＴＳパケットのＰＩＤである。例えば、行１２１１に表されるプログラムのＰＭＴは、プログラムナンバーが１０１であり、対応するＰＭＴはＰＩＤが５０１であるＴＳパケットによって伝送される。
【００９２】
端末装置があるプログラムを再生する場合は、ＰＡＴおよびＰＭＴを用いてプログラムを構成する映像・音声を特定し、それらを再生する。例えば、図１２のＰＡＴおよび図１１のＰＭＴを伝送するＭＰＥＧ２トランスポートストリームに関して、プログラムナンバーが１０１であるプログラムに属する映像・音声の再生を行う場合は以下のような手順をとる。まずＰＩＤが“０”であるＴＳパケットより、ｔａｂｌｅ＿ｉｄが“０”のＭＰＥＧ２セクションとして伝送されるＰＡＴを取得する。ＰＡＴよりプログラムナンバーが“１０１”であるプログラムを探索し、行１２１１を得る。行１２１１より、プログラムナンバーが“１０１”であるプログラムのＰＭＴを伝送するＴＳパケットのＰＩＤ“５０１”を得る。次いでＰＩＤが“５０１”であるＴＳパケットより、ｔａｂｌｅ＿ｉｄが“２”のＭＰＥＧ２セクションとして伝送されるＰＭＴを取得する。ＰＭＴより、音声のＥＳ情報である行１１１１および映像のＥＳ情報である行１１１２を得る。行１１１１より、音声ＥＳを伝送するＴＳパケットのＰＩＤ“５０１１”を得る。また行１１１２より、映像ＥＳを伝送するＴＳパケットのＰＩＤ“５０１２”を得る。次いでＰＩＤ“５０１１”のＴＳパケットより音声用ＰＥＳパケットを、ＰＩＤ“５０１２”のＴＳパケットより映像用ＰＥＳパケットを取得する。これにより、再生対象となる映像・音声のＥＳパケットを取得することが可能となり、プログラムナンバー１０１を構成する映像と音声を再生することができる。
【００９３】
なお、ＭＰＥＧ２トランスポートストリームは暗号化されている場合がある。これは限定視聴とも呼ばれる仕組みである。例えば、ある映像・音声情報を伝送するＰＥＳパケットに対して暗号化処理を行うことで、その暗号を解読できる特定視聴者のみが視聴できるようになる。暗号を解読して映像や音声を視聴するために、視聴者はデスクランブラと呼ばれるデバイスを用いて暗号解除を行う。例えば、ＯＣＡＰ対応の端末装置は、デスクランブラを内蔵したカード型のアダプタを利用する。ケーブルテレビのオペレータは、視聴者ごとに特定のプログラムを解読できるように設定したアダプタを配布し、視聴者はそのアダプタを端末装置に挿入する。すると、アダプタは、暗号解除鍵等の暗号解除情報や各契約者の契約情報を元に、特定のプログラムに関して暗号を解除する。暗号解除の方式や、暗号解除鍵の入手方法はアダプタ依存であり、本発明の実現には影響しない。
【００９４】
ここまでＭＰＥＧ２仕様に関する簡単な説明を行ったが、ここで、単語の詳細な定義を行う。本発明に関して、「プログラム」という単語が二種類存在する。一つはＭＰＥＧ２仕様に登場する「プログラム」であり、もう一つはＣＰＵが実行するコードの集合という意味での「プログラム」である。前者に関しては、運用規定で用いられる「サービス」という単語と同義であるため、混乱を避けるため、以降、前者を「サービス」と呼び、後者を単に「プログラム」とよぶ。さらに後者に関して、特にＪａｖａ言語で記述された「プログラム」を「Ｊａｖａプログラム」とよぶ。
【００９５】
以上、本発明に関わる、ＭＰＥＧ２仕様にて決定されるいくつかの一般的な情報に関して説明を行った。以降、本実施の形態で用いる放送録画再生端末に関して詳細に説明する。
【００９６】
図１３Ａは、本実施例の放送録画再生装置の一般的なハードウェア構成を表すブロック図であり、すなわち図１における端末装置１１１，１１２，１１３の具体的な内部構成である。１３００は放送録画再生装置であり、Ｉｎ−ｂａｎｄ受信用チューナ１３０１、ＴＳデコーダ（ＴＳ  Ｄｅｍｕｌｔｉｐｌｅｘｅｒ）１３０２、ＡＶデコーダ１３０３、スピーカ１３０４、ディスプレイ１３０５、ＣＰＵ１３０６、２次記憶部１３０７、１次記憶部１３０８、ＲＯＭ１３０９、入力部１３１０、アダプタ１３１１、ＡＶエンコーダ１３１４、多重器（ＭＰＥＧ２  Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ  Ｍｕｌｔｉｐｌｅｘｅｒ等）１３１５で構成される。なお本実施例は、ＯＣＡＰ−ＤＶＲ仕様で実現される放送録画再生端末を拡張して得られるものであり、基本的なハードウェア構成はＯＣＡＰ−ＤＶＲ仕様で要求されるものとほぼ同じである。
【００９７】
チューナ１３０１は、ＣＰＵ１３０６が指定する周波数などのチューニング情報に従って、放送局側システム１０１から伝送される変調された放送信号を復調するデバイスである。チューナ１３０１が復調した結果得られるＭＰＥＧ２トランスポートストリームは、暗号解除機能をもつアダプタ１３１１を経て、ＴＳデコーダ１３０２に送信される。
【００９８】
ＴＳデコーダ１３０２は、ＣＰＵ１３０６が指定するＰＩＤ、セクションフィルタ条件等の指定にもとづいてＭＰＥＧ２トランスポートストリームから指定条件に合致するＰＥＳパケットやＭＰＥＧ２セクションを選別する機能をもつデバイスである。放送を受信してサービスを録画せずに再生する場合は、アダプタ１３１１が出力するＭＰＥＧ２トランスポートストリームがＴＳデコーダ１３０２に入力される。一方、２次記憶部１３０７に録画されているサービスを再生する場合は、２次記憶部１３０７が出力するＭＰＥＧ２トランスポートストリームがＴＳデコーダ１３０２に入力される。いずれの入力を受けるかは、ＣＰＵ１３０６によって制御される。
【００９９】
ＴＳデコーダ１３０２が選別した映像及び音声のＰＥＳパケットは、ＡＶデコーダ１３０３に出力される。また、ＴＳデコーダ１３０２が選別したＭＰＥＧ２セクションは、１次記憶部１３０８にＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送され、ＣＰＵ１３０６が実行するプログラムによって利用される。
【０１００】
ＡＶデコーダ１３０３はエンコードされた映像ＥＳおよび音声ＥＳをデコードする機能をもつデバイスである。ＡＶデコーダはＴＳデコーダから転送される音声および映像情報を伝送するＰＥＳパケットからＥＳを取り出してデコードする。ＡＶデコーダ１３０３がデコードして得られたａｕｄｉｏ信号およびｖｉｄｅｏ信号は、サービスの再生時にはスピーカ１３０４、ディスプレイ１３０５に出力されるが、一方、サービスの録画時にはＡＶエンコーダ１３１４へ出力される。いずれの出力経路を取るかは、ユーザの指示に従ってＣＰＵ１３０６によって制御される。
【０１０１】
スピーカ１３０４は、ＡＶデコーダ１３０３から出力された音声を再生する。
【０１０２】
ディスプレイ１３０５は、ＡＶデコーダ１３０３から出力された映像を再生する。
【０１０３】
ＣＰＵ１３０６は放送録画再生装置上で動作するプログラムを実行する。ＣＰＵ１３０６は、ＲＯＭ１３０９に内蔵されるプログラムを実行する。あるいは、放送信号やネットワークよりダウンロードされ１次記憶部１３０８に保持されているプログラムも実行する。あるいは、放送信号やネットワークよりダウンロードされ２次記憶部１３０７に保存されているプログラムも実行する。そして実行するプログラムの指示に従い、チューナ１３０１、ＴＳデコーダ１３０２、ＡＶデコーダ１３０３、スピーカ１３０４、ディスプレイ１３０５、２次記憶部１３０７、１次記憶部１３０８、ＲＯＭ１３０９、入力部１３１０、アダプタ１３１１、ＡＶエンコーダ１３１４、多重器１３１５を制御する。また、ＣＰＵ１３０６は端末装置１３００内に存在するデバイスだけでなく、アダプタ１３１１内のデバイスと通信し、アダプタ１３１１を制御することが可能である。
【０１０４】
２次記憶部１３０７は機器の電源が遮断されても記憶が消去されない記憶装置である。例えばＦＬＡＳＨ−ＲＯＭ等の不揮発性メモリ、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＣＤ−ＲやＤＶＤ−Ｒ等の書き換え可能のメディア等、端末装置１３００の電源断の際にも情報が消去されない機器によって構成され、ＣＰＵ１３０６の指示により情報の保存を行う。
【０１０５】
１次記憶部１３０８は、ＣＰＵ１３０６やＤＭＡ転送可能なデバイスの指示に従って情報を一時的に保存する機能をもつデバイスであり、ＲＡＭ等によって構成される。
【０１０６】
ＲＯＭ１３０９は、書き換え不可能なメモリーデバイスであり、具体的にはＲＯＭやＣＤ−ＲＯＭ、ＤＶＤ等で構成される。ＲＯＭ１３０９には、ＣＰＵ１３０６が実行するプログラムが格納されている。
【０１０７】
入力部１３１０は、具体的には、フロントパネルやリモコン受信機で構成され、ユーザからの入力を受け付ける。図１３Ｂは、フロントパネルで入力部１３１０を構成した場合の一例である。フロントパネル１４００ｘは七つのボタン、上カーソルボタン１４０１ｘ、下カーソルボタン１４０２ｘ、左カーソルボタン１４０３ｘ、右カーソルボタン１４０４ｘ、ＯＫボタン１４０５ｘ、取消ボタン１４０６ｘ、ＥＰＧボタン１４０７ｘ、モード切換ボタン１４０８ｘを備えている。ユーザがボタンを押下すると、押下されたボタンの識別子が、ＣＰＵ１３０６に通知される。
【０１０８】
アダプタ１３１１は、Ｉｎ−ｂａｎｄ周波数帯で伝送されるＭＰＥＧ２トランスポートストリームにかけられた暗号を解除する装置で、１つ以上のデスクランブラを搭載する。アダプタ１３１１にはチューナ１３０１が出力するＭＰＥＧ２トランスポートストリームが入力され、ＣＰＵ１３０６が指定したＰＩＤをもつＴＳパケットに対して暗号解除を行う。アダプタ１３１１は、暗号を解除したＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に出力する。
【０１０９】
さらに、アダプタ１３１１は、ＯＯＢ周波数帯で伝送されるデータの形式変換も行う。ＯＯＢで伝送される情報はＱＰＳＫ変調方式で変調される。下り方向の伝送に関しては、ＱＰＳＫ復調器１３１２は放送局側システム１０１から送信されてくる下りの信号を復調し、生成されたビットストリームをアダプタ１３１１に入力する。アダプタ１３１１はビットストリームが含む様々な情報の中から、ＣＰＵ１３０６が指定する情報を抽出して、ＣＰＵ１３０６上で動作するプログラムが解釈可能な形式に変換して、ＣＰＵ１３０６に提供する。一方、上り方向の伝送に関しては、ＣＰＵ１３０６が、放送局側システム１０１に対して送信したい情報を、アダプタ１３１１に入力する。アダプタ１３１１は、ＣＰＵ１３０６から入力された情報を放送局側システム１０１が解釈可能な形式に変換し、ＱＰＳＫ変調器１３１３に入力する。ＱＰＳＫ変調器１３１３はアダプタ１３１１から入力された情報をＱＰＳＫ変調し、放送局側システム１０１に送信する。
【０１１０】
アダプタ１３１１の具体例としては、米国ケーブルシステムで利用されるＣａｂｌｅＣＡＲＤ、旧名ＰＯＤ（Ｐｏｉｎｔ  Ｏｆ  Ｄｅｐｌｏｙｍｅｎｔ）が挙げられる。
【０１１１】
ＡＶエンコーダ１３１４は、ＡＶデコーダ１３０３によってデコードされたａｕｄｉｏ信号をＭＰＥＧ  ａｕｄｉｏ形式の音声にエンコードし、ｖｉｄｅｏ信号をＭＰＥＧ  ｖｉｄｅｏ形式の映像にエンコードする。ＡＶエンコーダ１３１４がエンコードた映像および音声は、多重器１３１５へ出力される。
【０１１２】
多重器１３１５は、ＡＶエンコーダ１３１４から入力された映像および音声を、ＭＰＥＧ２トランスポートストリームへ多重化する機能をもつデバイスである。
【０１１３】
以上説明した放送録画再生装置が、放送波に含まれるサービスを２次記憶部１３０７に記録する動作と、２次記憶部１３０７から逐次読み出してサービスを再生する動作について、以下に詳細に説明する。
【０１１４】
まず、放送波に含まれるサービスを２次記憶部１３０７に記録する動作について述べる。
【０１１５】
図１４に、サービスの記録時における、各デバイスの物理的な接続順序と処理内容、入出力のデータ形式を表現する概念図を示す。１４００は端末装置であり、チューナ１３０１、アダプタ１３１１、デスクランブラ１４０１、ＴＳデコーダ１３０２、ＰＩＤフィルタ１４０２、セクションフィルタ１４０３、ＡＶデコーダ１３０３、１次記憶部１３０８、ＡＶエンコーダ１３１４、多重器１３１５、および、記録領域１４０４をもつ。図１４の構成要素のうち、図１３Ａの構成要素と同一符号を持つものは、それらと同等の機能をもつため、説明を省略する。
【０１１６】
まずＣＰＵ１３０６が指定したチューニング指示に従って、チューナ１３０１が放送波をチューニングする。チューナ１３０１は、放送波を復調し、アダプタ１３１１にＭＰＥＧ２トランスポートストリームを入力する。
【０１１７】
アダプタ１３１１内にあるデスクランブラ１４０１は、視聴者ごとの限定解除情報に基づいて、ＭＰＥＧ２トランスポートストリームの暗号解除を行う。暗号解除されたＭＰＥＧ２トランスポートストリームは、ＴＳデコーダに入力される。
【０１１８】
ＴＳデコーダ１３０２内にはＭＰＥＧ２トランスポートストリームに対して処理を行う２種類のデバイス、ＰＩＤフィルタ１４０２、セクションフィルタ１４０３が存在する。
【０１１９】
ＰＩＤフィルタ１４０２は、入力されたＭＰＥＧ２トランスポートストリームから、ＣＰＵ１３０６が指定したＰＩＤをもつＴＳパケットを抽出し、さらにそのペイロードに存在するＰＥＳパケットやＭＰＥＧ２セクションを抽出する。例えば、ＣＰＵ１３０６がＰＩＤ＝１００のＴＳパケットを抽出するＰＩＤフィルタリングを指示した場に図６のＭＰＥＧ２トランスポートストリームが入力されたとすると、パケット６０１及び６０３が抽出されて更に連結され、映像１のＰＥＳパケットが再構成される。あるいは、ＣＰＵ１３０６がＰＩＤ＝２００のＴＳパケットを抽出するＰＩＤフィルタリングを指示した場に図６のＭＰＥＧ２トランスポートストリームが入力されたとすると、パケット６０２及び６０５が抽出されて更に連結され、データ１のＭＰＥＧセクションが再構成される。
【０１２０】
セクションフィルタ１４０３は、入力されたＭＰＥＧ２セクションの中から、ＣＰＵ１３０６が指定するセクションフィルタ条件に合致するＭＰＥＧ２セクションを抽出し、１次記憶部１３０８にＤＭＡ転送する。例えば、ＣＰＵ１３０６はＰＩＤ＝２００のＴＳパケットを抽出するＰＩＤフィルタリングとｔａｂｌｅ＿ｉｄが６４であるセクションを抽出するセクションフィルタリングをセクションフィルタ１４０３に対して指定したとする。先に述べたように、データ１のＭＰＥＧ２セクションが再構成された後、セクションフィルタ１４０３はそのＭＰＥＧ２セクションの中からｔａｂｌｅ＿ｉｄが６４であるセクションのみを抽出し、１次記憶部１３０８にＤＭＡ転送する。
【０１２１】
１次記憶部１３０８に入力されたＭＰＥＧ２セクションは、多重器１３１５に入力される。
【０１２２】
ＴＳデコーダ１３０２によって抽出された映像ＰＥＳパケットと音声ＰＥＳパケットは、ＡＶデコーダ１３０３に入力される。
【０１２３】
ＡＶデコーダは、映像ＰＥＳパケットをデコードして映像に変換し、ＡＶエンコーダ１３１４に入力する。また音声ＰＥＳパケットをデコードして音声に変換し、ＡＶエンコーダ１３１４に入力する。
【０１２４】
ＡＶエンコーダ１３１４は、映像をＭＰＥＧ  ｖｉｄｅｏに変換し、多重器１３１５に入力する。また音声をＭＰＥＧ  ａｕｄｉｏに変換し、多重器１３１５に入力する。
【０１２５】
多重器１３１５は、ＡＶエンコーダから入力されたＭＰＥＧ  ｖｉｄｅｏとＭＰＥＧ  ａｕｄｉｏと、１次記憶部１３０８から入力されたＭＰＥＧ２セクションを多重してＭＰＥＧ２トランスポートストリームを生成する。生成されたＭＰＥＧトランスポートストリームは、記録領域１４０４に記録される。
【０１２６】
記録領域１４０４は２次記憶部１３０７の全体または一部、あるいは、その他の記録領域で構成され、サービスを構成するＭＰＥＧ２トランスポートストリームを記憶する。
【０１２７】
次いで、２次記憶部１３０７から逐次読み出してサービスを再生する動作について述べる。
【０１２８】
図１５に、サービスの再生時における、各デバイスの物理的な接続順序と処理内容、入出力のデータ形式を表現する概念図を示す。１５００は端末装置であり、記録領域１４０４、ＴＳデコーダ１３０２、ＰＩＤフィルタ１４０２、セクションフィルタ１４０３、ＡＶデコーダ１３０３、スピーカ１３０４、ディスプレイ１３０５、および、１次記憶部１３０８をもつ。図１５の構成要素のうち、図１３Ａの構成要素と同一符号を持つものは、それらと同等の機能をもつため、説明を省略する。
【０１２９】
図１４で説明した手順で記録領域１４０４に記録されたＭＰＥＧ２トランスポートストリームが、ＴＳデコーダ１３０２に入力される。
【０１３０】
次いで、ＴＳデコーダ１３０２内のＰＩＤフィルタ１４０２によって、ＣＰＵ１３０６が指定したＰＩＤを持つ映像ＰＥＳ及び音声ＰＥＳが抽出される。抽出されたＰＥＳパケットはＡＶデコーダ１３０３に入力される。あるいは、ＴＳデコーダ１３０２内のＰＩＤフィルタ１４０２とセクションフィルタ１４０３によって、ＣＰＵ１３０６が指定したＰＩＤとｔａｂｌｅ＿ｉｄを持つＭＰＥＧ２セクションが抽出される。抽出されたＭＰＥＧ２セクションは１次記憶部１３０８にＤＭＡ転送される。
【０１３１】
ＡＶデコーダ１３０３に入力された映像ＰＥＳと音声ＰＥＳは、デコードされてａｕｄｉｏ信号およびｖｉｄｅｏ信号が出力される。その後、ａｕｄｉｏ信号およびｖｉｄｅｏ信号はディスプレイ１３０５およびスピーカ１３０４に入力され、映像および音声が再生される。
【０１３２】
１次記憶部１３０８に入力されたＭＰＥＧ２セクションは、適宜ＣＰＵ１３０６に入力される。
【０１３３】
ここまでは、本発明に関するハードウェアの構成例に関して述べたが、以降、本発明の前提となる、Ｊａｖａプログラムによるサービスの記録制御に関して説明する。
【０１３４】
本発明におけるサービスの記録とは、サービスに含まれる映像、音声、Ｊａｖａプログラム、Ｊａｖａプログラムの同期情報等をハードディスク、ＢＤ（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）、ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリカードといった記録媒体に記録することである。サービスの再生とは、記録媒体に記録された映像、音声、Ｊａｖａプログラムを同期情報に基づいて再生および実行することである。記録済みサービスの再生結果は、放送波を受信して直接サービスを再生した結果とほぼ等価であることが要求される。
【０１３５】
図１６は、サービスの記録と再生に必要とされるプログラムの構成図であり、ＲＯＭ１３０９に記憶されているソフトウエアである。
【０１３６】
プログラム１６００は、サブプログラムであるＯＳ１６０１、ＥＰＧ１６０２、ＪａｖａＶＭ１６０３、サービスマネージャ１６０４、Ｊａｖａライブラリ１６０５、レコーディングマネージャ１６０６で構成される。
【０１３７】
ＯＳ１６０１は、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）であり、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ等が一例である。ＯＳ１６０１は、他のサブプログラム、例えばＥＰＧ１６０２とＪａｖａＶＭ１６０３を実行するためのカーネル１６０１ａと、サブプログラムが端末装置１３００の構成要素を制御するために利用するライブラリ１６０１ｂで構成される。カーネル１６０１ａは公知技術であり、詳細な説明は省略する。
【０１３８】
ライブラリ１６０１ｂは、例えばチューナを制御するチューニング機能を提供する。ライブラリ１６０１ｂは、他のサブプログラムから周波数を含むチューニング情報を受け取り、それをチューナ１３０１に引き渡す。チューナ１３０１は与えられたチューニング情報にもとづき復調処理を行い、復調したＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に引き渡すことができる。この結果、他のサブプログラムはライブラリ１６０１ｂを通してチューナ１３０１を制御することができる。
【０１３９】
また、ライブラリ１６０１ｂは、チャンネルを一意に識別するためのチャンネル情報を提供する。チャンネル情報の一例を図１９に示す。チャンネル情報はＯＯＢあるいはＩｎ−ｂａｎｄ周波数帯を利用して送信され、アダプタ１３１１で表形式に変換され、ライブラリがアクセス可能な一時記憶部に格納される。列１９０１は、チャンネル識別子で、例えば、ＳＣＴＥ  ６５  Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｄｅｌｉｖｅｒｅｄ  Ｏｕｔ−Ｏｆ−Ｂａｎｄ  Ｆｏｒ Ｄｉｇｉｔａｌ Ｃａｂｌｅ  Ｔｅｌｅｖｉｓｉｏｎで定義されるｓｏｕｒｃｅ＿ＩＤが相当する。列１９０２は、チャンネル名であり、同ＳＣＴＥ  ６５規格ではｓｏｕｒｃｅ＿ｎａｍｅなどに相当する。列１９０３はチューニング情報であり、周波数や転送レート、変調方式といったチューナ１３０１に与える情報である。列１９０４はＰＭＴを指定するためのプログラムナンバーである。例えば、行１９１１はチャンネル識別子が「１」、チャンネル名が「チャンネル１」、チューニング情報に周波数「１５０ＭＨｚ」、プログラムナンバーが「１０１」であるサービス情報の組となっている。
【０１４０】
ＪａｖａＶＭ１６０３は、Ｊａｖａ（登録商標）言語で記述された１以上のプログラムを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウェアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。ＪａｖａＶＭ１６０３は、Ｊａｖａ言語で記述されたＪａｖａライブラリ１６０５を実行する。Ｊａｖａ言語やＪａｖａＶＭの詳細は、書籍「Ｊａｖａ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−１）」や「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１―Ｘ）」等を参照のこと。また、ＪＮＩ（Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。ＪＮＩに関しては、書籍「Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ」等を参照のこと。また、マルチスレッド管理により、複数のプログラムを並列的に動作させることが可能である。
【０１４１】
Ｊａｖａライブラリ１６０５は、Ｊａｖａプログラムが放送録画再生装置の機能を制御するために呼び出すＪａｖａ言語で記述されたライブラリである。ただし、必要に応じて、ＯＳ１６０１のライブラリ１６０１ｂなど非Ｊａｖａ言語で記述されたサブプログラムを利用することもある。Ｊａｖａプログラムは、Ｊａｖａライブラリ１６０５が持つＪａｖａ  ＡＰＩ（アプリケーションプログラミングインタフェース）を呼び出すことで、Ｊａｖａライブラリ１６０５が提供する機能を利用できる。
【０１４２】
Ｔｕｎｅｒ１６０５ｃは、放送録画再生端末のＩｎ−ｂａｎｄ受信用チューナ１３０１を制御するためのＪａｖａライブラリである。ＪａｖａプログラムがＴｕｎｅｒ１６０５ｃにチューニング情報を渡すと、Ｔｕｎｅｒ１６０５ｃはそれを用いてライブラリ１６０１ｂのチューナ機能を呼び出し、結果、放送録画再生端末のＩｎ−ｂａｎｄ受信用チューナ１３０１の動作を制御できる。
【０１４３】
ＳＦ１６０５ｅは、放送録画再生端末のＰＩＤフィルタ１４０２及びセクションフィルタ１４０３機能を制御するためのＪａｖａライブラリである。ＪａｖａプログラムがＳＦ１６０５ｅにＰＩＤやｔａｂｌｅ＿ｉｄなどのフィルタ条件を渡すと、ＳＦ１６０５ｅはその条件を元にライブラリ１６０１ｂの機能などを用いてＰＩＤフィルタ１４０２及びセクションフィルタ１４０３を制御し、所望のフィルタ条件に叶うＭＰＥＧ２セクションを取得して、フィルタ条件を設定したＪａｖａプログラムに渡す。
【０１４４】
ＤＳＭ−ＣＣ１６０５ｄは、ＤＳＭ−ＣＣオブジェクトカルーセルのファイルシステムにアクセスするためのＪａｖａライブラリである。ＤＳＭ−ＣＣオブジェクトカルーセルは、ＳＦ１６０５ｅによって取得されるＭＰＥＧ２セクションが内包している。ＤＳＭ−ＣＣは、ＩＳＯ／ＩＥＣ１３８１８−６規格で定義されており、ＭＰＥＧ２セクションを利用して任意のファイルを伝送するための仕組みである。これを利用することで、放送局から端末にファイルを伝送することができる。ＤＳＭ−ＣＣの詳細な実現方法は本発明とは関係ないため、説明を省略する。
【０１４５】
サービスマネージャ管理１６０５ｆは、サービスマネージャ１６０４に対し、サービスの再生を依頼するためのＪａｖａライブラリである。ＪａｖａＶＭ１６０３によって実行されるＪａｖａプログラムはサービスマネージャ管理１６０５ｆを利用することで、サービスの再生をサービスマネージャ１６０４に依頼する。
【０１４６】
レコーディングマネージャ管理１６０５ｇは、レコーディングマネージャに対して、録画予約を指令するためのＪａｖａライブラリである。ＪａｖａＶＭ１６０３によって実行されるＪａｖａプログラムはレコーディングマネージャ管理１６０５ｇを利用することで、レコーディングマネージャに録画予約を指令する。なお、録画予約は本発明の根幹部分であり、詳細は後述するが、少なくとも録画予約を指令する場合、録画開始時刻及び録画継続時間、録画対象サービスを指すチャンネル識別子を必要とする。
【０１４７】
ＡＭ１６０５ｂは、サービスに含まれるＪａｖａアプリケーションの実行や終了を管理する機能を提供するアプリケーションマネージャである。ＡＭ１６０５ｂは指定されたＭＰＥＧ２トランスポートストリームの指定されたチャンネルに多重されたＪａｖａプログラムを抽出し、その抽出したＪａｖａプログラムを別途多重された同期情報に従って実行したり、あるいは終了させたりする。ＪａｖａプログラムのＪａｖａクラスファイルは、前述のＤＳＭ―ＣＣ方式でＭＰＥＧ２トランスポートストリームに多重されている。また、Ｊａｖａプログラムの同期情報はＡＩＴと呼ばれる形式で、ＭＰＥＧ２トランスポートストリームに多重されている。ＡＩＴは、ＤＶＢ−ＭＨＰ規格（ＥＴＳＩ  ＴＳ  １０１  ８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）の１０章に定義されている、Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅの略であり、ｔａｂｌｅ＿ｉｄが「０ｘ７４」であるＭＰＥＧ２セクションである。
【０１４８】
ＡＭ１６０５ｂの入力は、ＭＰＥＧ２トランスポートストリームとチャンネル識別子である。まず、ＡＭ１６０５ｂは、指定されたチャンネル識別子をキーとしてライブラリ１６０１ｂのチャンネル情報を検索し、プログラムナンバーを得る。次にＳＦ１６０５ｅなどを利用して、ＭＰＥＧ２トランスポートストリームからＰＡＴを取得する。さらにＰＭＴの情報から、先ほど得られたプログラムナンバーに対応するＰＭＴのＰＩＤが得られる。再度ＳＦ１６０５ｅを利用して、実際のＰＭＴを取得する。取得されたＰＭＴは図１１の形式をしており、ストリーム種別が「データ」で補足情報として「ＡＩＴ」をもつエレメンタリ−ストリームのＰＩＤが書かれている。更にＳＦ１６０５ｅに、フィルタリング条件として今得られたＡＩＴのＰＩＤとｔａｂｌｅ＿ｉｄ「０ｘ７４」を与えると、ＡＩＴの実体が得られる。
【０１４９】
図２１は、ＡＩＴの情報の一例を模式的に表した表である。ＡＩＴバージョン２１００は、そのＡＩＴのバージョンを表現する。ＡＩＴバージョンが大きいほど、そのＡＩＴはより新しいＡＩＴである。等しいＡＩＴバージョンをもつＡＩＴは繰り返し受信されるが、ＡＭ１６０５ｂはすでに解析したＡＩＴと等しいＡＩＴバージョンをもつＡＩＴは解析せず、すでに解析したＡＩＴよりも新しいＡＩＴのみを解析して、それに対応した処理をする。列２１０１はＪａｖａプログラムの識別子である。列２１０２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」「ｐｒｅｓｅｎｔ」「ｋｉｌｌ」等があり、「ａｕｔｏｓｔａｒｔ」は即時に端末装置１３００がこのＪａｖａプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味し、「ｋｉｌｌ」はＪａｖａプログラムを停止することを意味する。列２１０３は、ＤＳＭ―ＣＣ方式でＪａｖａプログラムを含んでいるＰＩＤを抽出するためのとＤＳＭ―ＣＣ識別子である。
【０１５０】
列２１０４はＪａｖａプログラムのプログラム名である。行２１１１、行２１１２、行２１１３、行２１１４は、Ｊａｖａプログラムの情報の組である。行２１１１で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。同様に、行２１１２で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。ここで、行２１１１、行２１１２、行２１１４で定義される３つのＪａｖａプログラムは同一のＤＳＭＣＣ識別子をもつが、これは１つのＤＳＭＣＣ方式でエンコードされたファイルシステム内に３つのＪａｖａプログラムが含まれていることを表す。ここでは、Ｊａｖａプログラムに対して４つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はＤＶＢ−ＭＨＰ規格を参照されたい。
【０１５１】
ＡＭ１６０５ｂは、ＡＩＴの中から「ａｕｔｏｓｔａｒｔ」のＪａｖａプログラムを見つけ出し、対応するＤＳＭＣＣ識別子およびＪａｖａプログラム名を抽出する。図２１を参照して、ＡＭ１６０５ｂは行２１１１のＪａｖａプログラムを抽出し、ＤＳＭＣＣ識別子「１」およびＪａｖａプログラム名「ａ／ＴｏｐＸｌｅｔ」を取得する。次いでＡＭ１６０５ｂは、ＡＩＴから取得したＤＳＭＣＣ識別子を用いて、ＪａｖａプログラムをＤＳＭＣＣ方式で格納しているＴＳパケットのＰＩＤをＰＭＴから取得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭＣＣ識別子が合致するエレメンタリ−ストリームのＰＩＤを取得する。ここで、ＤＳＭＣＣ識別子が「１」であり、ＰＭＴが図１１とすると、行１１１４のエレメンタリ−ストリームが合致し、ＰＩＤ「５０１４」を取り出す。
【０１５２】
ＡＭ１６０５ｂは、ＳＦ１６０５ｅに、ＤＳＭＣＣ方式でデータが埋めこまれたＭＰＥＧ２セクションを伝送するＴＳパケットのＰＩＤおよびセクションフィルタ条件を指定する。ここでは、ＰＩＤ「５０１４」を与える。この結果、ＡＭ１６０５ｂは、必要なＤＳＭＣＣ用ＭＰＥＧ２セクションを収集することができる。ＡＭ１６０５ｂは、収集したＭＰＥＧ２セクションから、ＤＳＭＣＣ方式に従ってファイルシステムを復元し、１次記憶部１３０８に保存する。ＭＰＥＧ２トランスポートストリーム中のＴＳパケットからファイルシステム等のデータを取り出し１次記憶部１３０８、２次記憶部１３０７等の記憶手段に保存することを以降、ダウンロードとよぶ。
【０１５３】
図２２は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、２２０１はルートディレクトリ、２２０２はディレクトリ「ａ」、２２０３はディレクトリ「ｂ」、２２０４はファイル「ＴｏｐＸｌｅｔ．ｃｌａｓｓ」、２２０５はファイル「ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」、２２０６はディレクトリ「ｚ」、２２０７はファイル「ＭｕｓｉｃＸｌｅｔ．ｃｌａｓｓ」、２２０８はファイル「ＳｔｕｄｙＸｌｅｔ．ｃｌａｓｓ」である。
【０１５４】
次いでＡＭ１６０５ｂは、１次記憶部１３０８にダウンロードしたファイルシステム中から実行するＪａｖａプログラムをＪａｖａＶＭ１６０３に引き渡す。ここで、実行するＪａｖａプログラム名が「ａ／ＴｏｐＸｌｅｔ」とすると、Ｊａｖａプログラム名の最後に「．ｃｌａｓｓ」を付加したファイル「ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」が実行すべきファイルとなる。「／」はディレクトリやファイル名の区切りであり、図２２を参照して、ファイル２２０４が実行すべきＪａｖａプログラムである。次いでＡＭ１６０５ｂは、ファイル２２０４をＪａｖａＶＭ１６０３に引き渡すと、そのファイルはＪａｖａプログラムとしてＪａｖａ ＶＭ上で実行される。
【０１５５】
ＡＭ１６０５ｂは、新しいＡＩＴバージョンを持つＡＩＴが来る度にそのＡＩＴを解析してＪａｖａプログラムの実行状態を変更させる。ここで、制御情報に「ｋｉｌｌ」が指定されていた場合は、Ｊａｖａプログラムを終了させる。
【０１５６】
ＪＭＦ１６０５ａは、サービスに含まれる映像と音声の再生制御を担う。具体的には、指定されたＭＰＥＧ２トランスポートストリームの指定されたチャンネルに多重された映像ＥＳと音声ＥＳをＡＶデコーダに入力して再生させる。受信した放送波から直接サービスを再生する場合は、アダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームを再生するように指定される。一方、２次記憶部１３０７に一旦記録されたサービスを再生する場合は、２次記憶部１３０７内の記録領域１４０４から出力されるＭＰＥＧ２トランスポートストリームを再生するように指定される。
【０１５７】
まず、ＪＭＦ１６０５ａは、指定されたチャンネル識別子をキーとしてライブラリ１６０１ｂのチャンネル情報を検索し、プログラムナンバーを得る。次にＳＦ１６０５ｅなどを利用して、ＭＰＥＧ２トランスポートストリームからＰＡＴを取得する。さらにＰＭＴの情報から、先ほど得られたプログラムナンバーに対応するＰＭＴのＰＩＤが得られる。再度ＳＦ１６０５ｅを利用して、実際のＰＭＴを取得する。取得されたＰＭＴは図１１の形式をしており、ストリーム種別が「映像」及び「音声」であるエレメンタリ−ストリームのＰＩＤが書かれている。ＪＭＦ１６０５ａが、それらのＰＩＤをＴＳデコーダ１３０２のＰＩＤフィルタ１４０２に設定すると、図１４あるいは図１５に示されたごとく、該当ＰＩＤで多重されている映像ＥＳと音声ＥＳがＡＶデコーダ１３０３経由で再生される。
【０１５８】
レコーディングマネージャ１６０６は、チャンネル識別子と開始時刻、終了時刻を入力として、当該サービスを、指定された開始時刻と終了時刻の間だけ２次記憶部１３０７に記録する。例えば、ＥＰＧ１６０２からチャンネル識別子と開始時刻、終了時刻を指定されると、開始時間になるまで待機する。その後、開始時間に至ると、指定サービスの記録を開始し、終了時間に至ると記録を終了する。以下にその詳細を記述する。
【０１５９】
記録開始時間に至ると、最初に、レコーディングマネージャ１６０６は、２次記憶部１３０７に指定された開始時刻から終了時刻までのＭＰＥＧ２トランスポートストリームを記録するための記録領域１４０４を２次記憶部１３０７内に確保する。確保した記録領域には、メディア識別子を与える。次にＴｕｎｅｒ１６０５ｃにチャンネル識別子を与える。するとＴｕｎｅｒ１６０５ｃは、ライブラリ１６０１ｂ経由でチャンネル情報を参照し、チューニング情報を取得し、チューニングを開始する。すると図１４に示されるように、アダプタ１３１１経由でＭＰＥＧ２トランスポートストリームがＴＳデコーダに入力される。
【０１６０】
一方、レコーディングマネージャ１６０６は、ＳＦ１６０５ｅを利用して、チューニングで得られたＭＰＥＧ２トランスポートストリームからＰＡＴを取得する。さらに、指定されたチャンネル識別子に対応するプログラムナンバーをライブラリ１６０１ｂから検索し、得られたプログラムナンバーに対応するＰＭＴのＰＩＤをＰＡＴから検索する。その後、ＳＦ１６０５ｅを利用して、実際のＰＭＴを取得し、指定されたチャンネルを構成するＥＳの全ＰＩＤを得る。レコーディングマネージャ１６０６は、得られたＰＩＤをＴＳデコーダのＰＩＤフィルタ１４０２に設定する。すると、図１４で説明した流れに沿って、所望のチャンネルを構成する全ＥＳが、先ほど領域確保した記録領域１４０４に記録される。
【０１６１】
その後、指定された終了時刻に至ると、レコーディングマネージャ１６０６はＴｕｎｅｒ１６０５ｃのチューニング動作を停止させ、記録領域１４０４へのＭＰＥＧ２トランスポートストリームの書き込みを終了させる。また、先ほど記録したＭＰＥＧ２トランスポートストリームの管理情報として、図２０に示すレコード情報管理テーブルを作成する。
【０１６２】
図２０は２次記憶部１３０７等の記録領域１４０４に記録されているレコード情報を管理するためのレコード情報管理テーブルの一例である。レコード情報は表形式で記録されている。列２００１は、レコード識別子である。列２００２は、チャンネル識別子である。列２００３はプログラムナンバーである。列２００４はサービスの録画開始時間、列２００５はサービスの録画終了時間である。そして、列２００６はサービスとして記録されたＭＰＥＧ２トランスポートストリームを識別するメディア識別子である。行２０１１〜２０１２の各行は、各レコード識別子、チャンネル識別子、プログラムナンバー、開始時間、終了時間、および、メディア識別子の組となる。例えば、行２０１１はレコード識別子が「０００」、チャンネル識別子が「２」、プログラムナンバーが「１０２」、開始時間が「２００５／０３／３０  １１：００」、終了時間が「２００５／０３／３０  １２：００」、および、メディア識別子が「ＴＳ＿００１」であることを示す。
【０１６３】
サービスマネージャ１６０４は、２次記憶部１３０７に記録済みのＭＰＥＧ２トランスポートストリーム中のサービス、あるいはアダプタ１３１１から入力されるＭＰＥＧ２トランスポートストリーム中のサービスの再生を管理する。
【０１６４】
以下に、２次記憶部１３０７に記録済みのＭＰＥＧ２トランスポートストリーム中のサービスの再生を管理する場合の動作について述べる。これは録画済みサービスの再生に相当する。この場合、サービスマネージャ１６０４は、レコード識別子を入力とする。そのレコード識別子で特定される、２次記憶部１３０７に記録済みのサービスが、再生対象である。
【０１６５】
サービスマネージャ１６０４は、まず、レコーディングマネージャ１６０６が作成したレコード情報管理テーブルを参照して、指定されたレコード識別子で再生されるべきチャンネル識別子と、メディア識別子を得る。そして、２次記憶部１３０７に対して、今得られたメディア識別子で特定されるＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に出力するように、ライブラリ１６０１ｂを通して指示する。その後、ＪＭＦ１６０５ａにＭＰＥＧ２トランスポートストリームの所在として２次記憶部１３０７を与え、また再生すべきチャンネル識別子を与える。すると、ＪＭＦ１６０５ａは、既に述べた動作によって、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重された映像と音声の再生を開始する。
【０１６６】
更に、ＡＭ１６０５ｂにもＭＰＥＧ２トランスポートストリームの所在として２次記憶部１３０７を与え、また再生すべきチャンネル識別子を与える。すると、ＡＭ１６０５ｂは２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重されたＡＩＴに従って、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重されたＪａｖａプログラムの実行及び終了を開始する。その後、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームの終端まで、上述のサービスの再生を継続する。
【０１６７】
一方、以下に、アダプタ１３１１から入力されるＭＰＥＧ２トランスポートストリーム中のサービスの再生を管理する場合を説明する。これは、放送波から直接サービスを再生することに相当する。この場合、サービスマネージャ１６０４は、再生対象サービスのチャンネル識別子を入力とする。
【０１６８】
サービスマネージャ１６０４は、図１４のアダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に出力するように、ライブラリ１６０１ｂを通して指示する。その後、ＪＭＦ１６０５ａにＭＰＥＧ２トランスポートストリームの所在としてアダプタ１３１１を与え、また再生すべきチャンネル識別子を与える。すると、ＪＭＦ１６０５ａは、既に述べた動作によって、アダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームに多重された映像と音声の再生を開始する。更に、ＡＭ１６０５ｂにもＭＰＥＧ２トランスポートストリームの所在としてアダプタ１３１１を与え、また再生すべきチャンネル識別子を与える。すると、ＡＭ１６０５ｂはアダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームに多重されたＡＩＴに従って、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重されたＪａｖａプログラムの実行及び終了を開始する。その後、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームの終端まで、上述のサービスの再生を継続する。
【０１６９】
ＥＰＧ１６０２は、電子番組表（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅの略）であり、録画や再生の対象とする番組をユーザに選択させる機能である。放送波を受信しての通常の再生は本発明の趣旨から外れるため、説明を割愛する。
【０１７０】
番組を記録する場合は、ＥＰＧ１６０２は、放送番組一覧を表示してユーザに希望の番組を選択させる。図１８は、録画対象とする番組を選択させるための画面表示の一例である。時刻１７０１とチャンネル１７０２と１７０３が格子状に表示され、各時刻で記録可能な各チャンネルの番組を一覧できる。ユーザは端末装置１３００の入力部１３１０に備わっている上下左右カーソルボタン１４０１ｘ〜１４０４ｘを用いて画面上のフォーカス１８３０を移動させることができる。更にＯＫボタン１４０５ｘを押下すると、現在フォーカスが当たっている番組が記録対象として選択される。ＥＰＧ１６０２は当該番組のチャンネル識別子をライブラリから取得して知っており、ユーザによって記録対象番組が選択されると、当該番組のチャンネル識別子、開始時間、終了時間をレコーディングマネージャ１６０６に通知する。レコーディングマネージャ１６０６は、その情報に基づいて、当該番組を２次記憶部１３０７に記録する。
【０１７１】
一方、記録済みの番組を再生する場合は、ＥＰＧ１６０２は、記録済み番組一覧を表示してユーザに希望の番組を選択させる。図１７は、録画済み番組を選択させるための画面表示の一例である。その時点で２次記憶部１３０７に記憶されている番組がすべて一覧表示される。ユーザは端末装置１３００の入力部１３１０に備わっている上下カーソルボタン１４０１ｘ，１４０２ｘを用いて画面上のフォーカス１７３０を移動させることができる。更にＯＫボタン１４０５ｘを押下すると、現在フォーカスが当たっている番組が再生対象として選択される。ＥＰＧ１６０２は当該番組のレコード識別子をレコーディングマネージャ１６０６から取得して知っており、ユーザによって再生対象番組が選択されると、当該番組のレコード識別子をサービスマネージャ１６０４に通知する。サービスマネージャ１６０４は、その情報に基づいて、当該番組を２次記憶部１３０７から読み出して再生する。
【０１７２】
またここで、ＯＣＡＰ及びＯＣＡＰ−ＤＶＲ環境にて規定される抽象サービスについても言及しておく。抽象サービスは映像及び音声を含まず、Ｊａｖａプログラムのみを含む特殊なサービスである。抽象サービスに関する情報は、前述のＯＯＢにて伝送される特殊なＡＩＴに記載される。このＡＩＴは、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様ではＸＡＩＴと呼ばれる。端末は電源投入時、ＳＦ１６０５ｅを利用してＸＡＩＴをＯＯＢより取得し、抽象サービスに関する情報を取得し、抽象サービスに含まれるＪａｖａプログラムを起動する。ＸＡＩＴに情報が記載されるＪａｖａプログラムを、本発明では、「特権プログラム」と呼称する。なお、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様では特権プログラムのことをモニタアプリケーションとも呼称する。
【０１７３】
ここまでは、本発明の前提となる録画機能について詳述した。以降、デバイスの競合、及び競合が起こった際の競合解決手法について述べる。
【０１７４】
例えばＩｎ−ｂａｎｄ受信用チューナ１３０１が端末に１つしか存在しない場合、サービスマネージャによる「放送から受信したＭＰＥＧ２トランスポートストリームに含まれる映像及び音声の再生処理」と、「放送から受信したＭＰＥＧ２トランスポートストリームに含まれる番組の記録」を同時に実行することは不可能であるため、Ｉｎ−ｂａｎｄ受信用チューナ１３０１がどちらの処理に利用されるかを決定する必要がある。このように「デバイスの絶対数の不足により、要求される複数の処理を並列的に実行できない状況」を「デバイスの競合」と呼び、さらに、「要求される複数の処理の中から、優先して実行する処理を選別すること」を「デバイス競合の解決」と呼ぶ。
【０１７５】
本発明の端末は、デバイス競合解決時、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様に規定されるデバイス競合解決手順に準拠する。以下、規定のデバイス競合解決手順について詳述する。
【０１７６】
ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様では、競合する可能性のあるデバイスの種類をあらかじめ特定している。Ｉｎ−ｂａｎｄ受信用チューナ１３０１はその一つである。本発明では、これを「排他デバイス」と呼ぶ。また、排他デバイスを操作するＪａｖａライブラリを「排他デバイス操作ライブラリ」と呼ぶ。Ｉｎ−ｂａｎｄ受信用チューナ１３０１に関しては、Ｔｕｎｅｒ１６０５ｃがこれにあたる。
【０１７７】
図２３はＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様に規定される排他デバイス利用手順を表現するシーケンス図である。排他デバイスを利用するすべてのＪａｖａプログラムは本シーケンスを利用する必要がある。まずＳ２３０１において、排他デバイスを確保する。この際デバイスクライアントと呼ばれるＪａｖａオブジェクトを排他デバイスに対して登録する。確保に成功すると、Ｓ２３０２において、排他デバイスを利用して所望の機能を実行する。所望の処理が終わると、Ｓ２３０３に至りＪａｖａプログラムは排他デバイスの解放を行う。もしＪａｖａプログラムが図２３のシーケンスに従わず、排他デバイスの確保をせずにその機能を利用しようとした場合は、そのＪａｖａプログラムに対してエラーを通知する。例として、Ｔｕｎｅｒ１６０５ｃにおいては、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣｏｎｔｒｏｌｌｅｒクラスにある、ｒｅｓｅｒｖｅ、ｔｕｎｅ、ｒｅｌｅａｓｅメソッドがそれぞれ確保、利用、解放に当たる。
【０１７８】
排他デバイス操作ライブラリは、排他デバイス管理テーブルにて、排他デバイスの確保状況を管理する。例えば図２４は、Ｔｕｎｅｒ１６０５ｃが１次記憶部１３０８上または２次記憶部１３０７上に管理するＩｎ−ｂａｎｄ受信用チューナ管理テーブルである。列２４１１はＩｎ−ｂａｎｄ受信用チューナを識別するための識別子である。この例では排他デバイスであるＩｎ−ｂａｎｄ受信用チューナは３つあるもの（つまりチューナ１、２、３の３つ）あるものを例に説明をする。列２４１２はＩｎ−ｂａｎｄ受信用チューナ１３０１を利用しているＪａｖａプログラムの識別子である。列２４１３は、確保時に登録されたデバイスクライアントである。また行２４０１〜行２４０３はＩｎ−ｂａｎｄ受信用チューナに関する情報を示す。図２４においては、Ｉｎ−ｂａｎｄ受信用チューナ１３０１の１つであるチューナ１はプログラムＡによって確保され、デバイスクライアントとしてクライアントＣが登録されている。また、チューナ２はプログラムＢによって確保され、デバイスクライアントとしてクライアントＤが登録されている。またチューナ３はどのプログラムからも確保がされていない。
【０１７９】
図２５は、Ｊａｖａプログラムが排他デバイス確保ＡＰＩの動作を表現するシーケンス図である。まずＳ２５０１において、Ｊａｖａプログラムが指定した排他デバイス識別子、Ｊａｖａプログラム識別子、デバイスクライアントを受け取る。Ｓ２５０２において、排他デバイス管理テーブルを参照し、特定された排他デバイスが既に他のＪａｖａプログラムによって確保されているかどうか調べる。確保されていない場合は、Ｎｏに進んでＳ２５０３に至り、Ｓ２５０１にて受け取ったＪａｖａプログラム識別子及びデバイスクライアントを、排他デバイス管理テーブルに設定する。確保されている場合は、Ｙｅｓに進んでＳ２５０４に至り、デバイスの競合解決を行う。デバイスの競合解決に関しては後述する。
【０１８０】
排他デバイス操作ライブラリは、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様が規定するデバイス競合解決アルゴリズムに従って、Ｓ２５０４にて排他デバイスの競合解決を行う。大別して２種類のデバイス競合解決アルゴリズムが存在するため、デバイス競合解決アルゴリズム１、デバイス競合解決アルゴリズム２と呼んで区別する。
【０１８１】
図２６はデバイス競合アルゴリズム１における動作手順を表すシーケンス図である。Ｓ２６０１において、排他デバイスを既に確保しているＪａｖａプログラム及びデバイスクライアントを取得する。次にＳ２６０２において、Ｓ２６０１にて取得したデバイスクライアントに対して、排他デバイスの解放を要求する。排他デバイスの解放を要求されたデバイスクライアントは、排他デバイスを解放するかどうかの判断を行い、その結果を排他デバイス操作ライブラリに返す。Ｓ２６０３に至って、デバイスクライアントの返答を評価し、解放に同意した場合、Ｙｅｓに進んでＳ２６０６に至り、新規に排他デバイスを確保しようとしているＪａｖａプログラム識別子及びデバイスクライアントで更新して終了する。
【０１８２】
解放に同意しなかった場合、Ｎｏに進んでＳ２６０４に至り、既に排他デバイスを確保していたＪａｖａプログラムの優先度と、新規に排他デバイスを確保しようとしているＪａｖａプログラムの優先度をＡＭ１６０５ｂから取得して、比較する。もし新規に確保しようとしているＪａｖａプログラムの優先度の方が高ければ、Ｙｅｓに進んでＳ２６０５に至り、排他デバイスを確保していたＪａｖａプログラムのデバイスクライアントに強制解放通知を行い、Ｓ２６０６に進んで新規に排他デバイスを確保しようとしているＪａｖａプログラム識別子とデバイスクライアントで排他デバイス管理テーブルを更新して終了する。分岐Ｓ２６０４において、もし既に確保しているＪａｖａプログラムの方が、優先度が高いか等しければ、新規に排他デバイスを確保しようとしているＪａｖａプログラムにエラーを通知して処理を終了する（Ｓ２６０７）。
【０１８３】
図２６で表したように、デバイス競合解決アルゴリズム１はＡＩＴまたはＸＡＩＴに記載されるＪａｖａプログラムの優先度に基づいてデバイスの競合を解決する。デバイス競合解決アルゴリズム１を用いる場合は、優先度が高いＪａｖａプログラムの方が常に有利な結果を得られる。
【０１８４】
一方、デバイス競合解決アルゴリズム２は、特権プログラムがデバイス競合を解決する。この場合、Ｊａｖａプログラムの優先度とは関係なく、特権プログラムが好む条件や順序でデバイスを各Ｊａｖａプログラムに割り当てる。デバイス競合解決アルゴリズム２では、特権プログラムは、２種類の方法で、所望のデバイス競合解決を実現する。一つは、排他デバイスを確保する権利のあるＪａｖａプログラムを選別する「Ｊａｖａプログラムフィルタ」である。例えば、Ｉｎ−ｂａｎｄ受信用チューナ１３０１の確保をさせたくないＪａｖａプログラムに対しては、Ｊａｖａプログラムフィルタを用いて、これを排除可能である。もう一つはＪａｖａプログラムフィルタによって確保が許可されたＪａｖａプログラムの中で排他デバイス確保の優先順序を決定する、「デバイス競合解決ハンドラ」である。本デバイス競合解決ハンドラは、例えば、ＪａｖａプログラムフィルタによってＩｎ−ｂａｎｄ受信用チューナ１３０１の確保権利を持つと判断されたＪａｖａプログラム１とＪａｖａプログラム２の間でＩｎ−ｂａｎｄ受信用チューナ１３０１の競合が起こった場合、どちらを優先するかを決定するものである。デバイス競合解決アルゴリズム２を用いるのは、Ｊａｖａプログラムフィルタ及びデバイス競合解決ハンドラの一方あるいは両方が、排他デバイス操作ライブラリに登録された場合である。
【０１８５】
図２７〜図２９はデバイス競合解決アルゴリズム２における動作手順を表現したシーケンス図である。
【０１８６】
デバイス競合解決アルゴリズム２の第一の図２７は、Ｊａｖａプログラムフィルタに関連する動作手順を表現したシーケンス図である。Ｓ２７０１において、排他デバイス操作ライブラリにＪａｖａプログラムフィルタが既に登録されているかどうか調査し、登録されてなければＮｏのＳ２７０５に進み、図２８のＳ２８０１から始まるシーケンスに接続する。登録されていれば、ＹｅｓのＳ２７０２に進み、新規に排他デバイスを確保しようとしているＪａｖａプログラムが、その排他デバイスを確保する権利があるかどうか、Ｊａｖａプログラムフィルタに問い合わせ、Ｊａｖａプログラムフィルタは、判定結果を排他デバイス操作ライブラリに返す。次にＳ２７０３に至り、そのＪａｖａプログラムが排他デバイスを確保する権利を持っていれば、Ｙｅｓへ進み、Ｓ２７０５に至って図２８のＳ２８０１から始まるシーケンスに接続する。権利を持っていなければ、Ｎｏへ進み、Ｓ２７０４に至る。デバイスを新規予約しようとしているＪａｖａプログラムにエラーを返して、動作手順を終了する。
【０１８７】
デバイス競合解決アルゴリズム２の第二の図２８は、Ｊａｖａプログラム本来の優先度に基づく優先度判断を行う動作手順を表現したシーケンス図である。本シーケンス図は一点を除いてデバイス競合解決アルゴリズム１を解説した図２６と同様であり詳細は割愛する。異なる一点は、Ｊａｖａプログラムの優先度によるデバイス競合解決を行う前に、Ｓ２８０５において、図２９にて表現されるシーケンス図への接続がある点である。
【０１８８】
デバイス競合解決アルゴリズム２の第三の図２９は、特権プログラムが登録したデバイス競合解決ハンドラによるデバイス競合解決を表現する。Ｓ２９０１にて、まずデバイス競合解決ハンドラが登録されているかどうか調査し、登録されていないのであればＮｏへ進んでＳ２９０２に至る。Ｓ２９０２は、図２８のＳ２８０５へ接続し、Ｊａｖａプログラムの優先度に基づくデバイス競合解決処理へ移行する。分岐Ｓ２９０１において、デバイス競合解決ハンドラが登録されている場合、Ｙｅｓに進んでＳ２９０３に至る。Ｓ２９０３では、デバイス競合解決ハンドラに、Ｊａｖａプログラムのデバイス確保優先順位を問い合わせる。デバイス競合解決ハンドラは、Ｊａｖａプログラム識別子の配列を返す。端末は、本ＡＰＩが返した配列を解析し、その配列に含まれるＪａｖａプログラム識別子の順に優先して、排他デバイスの競合を解決する。Ｓ２９０４では、デバイス競合解決ハンドラが返した配列を調査する。もし配列が返ってこなければ、「ＮＵＬＬ」に進み、Ｓ２９０２に至り、図２８のＳ２８０５へ接続し、Ｊａｖａプログラムの優先度に基づくデバイス競合解決処理へ移行する。分岐Ｓ２９０４において、配列の長さが０であれば、「長さ０」に進んでＳ２９０８に至り、新規にデバイスを確保しようとしているＪａｖａプログラムへエラーを返して処理を終了する。分岐Ｓ２９０４において、配列の長さが正の値であれば、「長さ１以上」に進んで、Ｓ２９０５に至る。
【０１８９】
Ｓ２９０５では、Ｓ２９０３にて取得した配列に基づき、新規にデバイスを確保しようとしているＪａｖａプログラムと、既にデバイスを確保しているＪａｖａプログラムで、どちらが優先順位が高いかを判定する。もし、新規にデバイスを確保しようとしているＪａｖａプログラムの方が優先順位が低ければ、Ｎｏに進んでＳ２９０８に至り、そのＪａｖａプログラムへエラーを返してデバイス競合解決処理を終了する。分岐Ｓ２９０５において、新規に排他デバイスを獲得しようとしているＪａｖａプログラムのほうが優先順位が高ければ、Ｙｅｓに進んで、Ｓ２９０６に至る。Ｓ２９０６では、既に排他デバイスを予約しているＪａｖａプログラムのデバイスクライアントを排他デバイス管理テーブルから取得して、デバイスクライアントに対して、強制的に解放することを通知する。Ｓ２９０７では、新規に確保しようとしているＪａｖａプログラムの識別子及びデバイスクライアントを持って排他デバイス管理テーブルを更新し、処理を終了する。
【０１９０】
図２７〜図２９にて表現したデバイス競合解決アルゴリズム２を用いると、特権プログラムは、Ｊａｖａプログラムフィルタ及びデバイス競合解決ハンドラを用いて、Ｊａｖａプログラムの優先度よりも強い特権プログラム独自の判断基準によって、デバイス競合解決を行うことが可能である。
【０１９１】
また、サービスマネージャ１６０４及びレコーディングマネージャ１６０６が排他デバイスを利用する際も、確保、利用、解放の３プロセスを利用する、という原則を守らなければならない。この場合、サービスマネージャ管理１６０５ｆを利用してサービスマネージャ１６０４に対してサービスの再生を依頼したＪａｖａプログラムや、レコーディングマネージャ管理１６０５ｇを利用してレコーディングマネージャ１６０６に対してサービスの記録を依頼したＪａｖａプログラムが、排他デバイスを確保しようとしていると見なされ、デバイス競合解決が行われる。
【０１９２】
以上、説明してきたデバイス競合解決アルゴリズムはＯＣＡＰ及びＯＣＡＰ−ＤＶＲ仕様にて例外なく利用されるデバイス競合解決手順である。デバイス競合解決アルゴリズム１及びデバイス競合解除アルゴリズム２において、デバイス競合解決にかかる時間について考察しておく。
【０１９３】
図３０はデバイス競合解決アルゴリズム１が利用された場合、誰がどのような作業に時間を消費したかを表現したシーケンス図である。まず、新規にＪａｖａプログラムＢが、排他デバイス操作ライブラリに対して、排他デバイスの確保を要求したとする。すると、排他デバイス操作ライブラリはまず確保する対象デバイスが競合しているかどうか判断する（３００１）。競合していた場合、排他デバイス操作ライブラリは、既にそのデバイスを確保しているＪａｖａプログラムＡに対してデバイス解放を要求する。ＪａｖａプログラムＡは、その時行っている処理を中止してデバイスを解放してもよいかどうか判断する（３００２）。ここで、デバイスは解放できないと判断されると、その結果を受け取った排他デバイス操作ライブラリは、ＪａｖａプログラムＡと、新規にデバイスを確保しようとしているＪａｖａプログラムとの間で優先度の比較を行う（３００３）。もし新規にデバイスを確保しようとしているＪａｖａプログラムの方が高優先度であれば、ＪａｖａプログラムＡに対して、強制解放通知を行う。強制解放通知を受け取ったＪａｖａプログラムＡは強制解放に基づく後処理を行って（３００４）、後処理の終了を排他デバイス操作ライブラリに通知する。
【０１９４】
図３１はデバイス競合解決アルゴリズム２が利用された場合、誰がどのような作業に時間を消費するか表現したシーケンス図である。まず、新規にＪａｖａプログラムＢが、排他デバイス操作ライブラリに対して、排他デバイスの確保を要求したとする。すると、排他デバイス操作ライブラリはまず、ＪａｖａプログラムＢが、確保対象の排他デバイスを確保することができるかどうか特権プログラムに判断してもらうため、Ｊａｖａプログラムフィルタを利用する。特権プログラムは、ＪａｖａプログラムＢが対象の排他デバイスを確保することができるかどうか判断し（３１０１）、結果を排他デバイス操作ライブラリに結果を返す。次に、排他デバイス操作ライブラリは、確保対象のデバイスが競合しているかどうかを判断する（３１０２）。
【０１９５】
競合していた場合、排他デバイス操作ライブラリは、既にそのデバイスを確保しているＪａｖａプログラムＡに対してデバイス解放を要求する。ＪａｖａプログラムＡは、その時行っている処理を中止してデバイスを解放してもよいかどうか判断する（３１０３）。ここで、デバイスは解放できないと判断されると、その結果を受け取った排他デバイス操作ライブラリは、特権プログラムに対して、どちらのＪａｖａプログラムを優先するか決定してもらうためにデバイス競合解決ハンドラを利用する。特権プログラムはデバイス確保の優先順位を決定し（３１０５）、排他デバイス操作ライブラリに結果を返す。排他デバイス操作ライブラリは、その優先順位に基づいてデバイスの競合を解決する（３１０６）。さらに、デバイスを奪われたＪａｖａプログラムＡに対して、強制解放通知を行う。強制解放通知を受け取ったＪａｖａプログラムＡは強制解放に基づく後処理を行って（３１０７）、後処理の終了を排他デバイス操作ライブラリに通知する。
【０１９６】
図３０及び図３１で表したように、ＯＣＡＰ及びＯＣＡＰ−ＤＶＲ仕様で規定されるデバイス競合の解決手順には、端末組込みの排他デバイス操作ライブラリだけでなく、ダウンロードして実行する特権プログラムや、デバイスを確保しているＪａｖａプログラムの動作がシーケンシャルに組み込まれている。つまりデバイス競合解決にかかる時間は、特権プログラムやＪａｖａプログラムの動作に依存するため、あらかじめ予測することは不可能である。
【０１９７】
具体的に例を挙げる。特権プログラムが、デバイス競合解決アルゴリズム制御ライブラリ１６０５ｉにデバイス競合解決ハンドラを登録しているケースを考える。この時、ＪａｖａプログラムＡ及びＪａｖａプログラムＢが同時に動作しており、各々がＴｕｎｅｒ１６０５ｃを利用してチューナ１３０１を操作しようとした場合、Ｔｕｎｅｒ１６０５ｃはデバイス競合解決ハンドラのデバイス予約優先順位取得ＡＰＩを呼び出して、順序を表現する配列を取得する。その後、取得した配列内のＪａｖａプログラム識別子の順序に基づいて、デバイス競合解決を行う。ここで、デバイス競合解決ハンドラを特権プログラムが用意していることに注目すると、デバイス予約優先順位取得ＡＰＩ実装内部では、特権プログラムが所望の動作を行うことが可能である。例えば、常にＪａｖａプログラムＡを優先するような配列を返す実装をしておくことができる。
【０１９８】
例えば、ＪａｖａプログラムＡ及びＪａｖａプログラムＢの選択肢を示すダイアログを画面に表示し、ユーザに選択権を与えるような実装も可能である。後者の場合、ユーザに選択を入力させる時間が必要なので、ある特権プログラムは、１分といったタイムアウトを設定してその間ユーザ入力を待つかもしれないし、ある特権プログラムは、ユーザ入力を永久に待ち続けるかもしれない。つまり、Ｔｕｎｅｒ１６０５ｃがデバイス予約優先順位取得ＡＰＩを呼び出してから、優先順位を表す配列を返すまでどれくらいの時間が必要かを、Ｔｕｎｅｒ１６０５ｃは予め予想することができない。
【０１９９】
以下、本発明における特徴的な要素に関して詳述する。本発明は、録画予約とサービスの再生におけるデバイス競合解決に関連する。
【０２００】
Ｊａｖａプログラムはレコーディングマネージャ管理１６０５ｇを利用することにより、録画予約を行うことができることは既に述べた。録画予約は、少なくとも録画対象サービスのチャンネル識別子、録画開始時刻、録画継続時間を持って成される。録画処理は少なくともＩｎ−ｂａｎｄ受信用チューナ１３０１を排他デバイスとして確保する処理であることから、録画予約は、「未来のデバイス確保の予約」である、と捉えることができる。
【０２０１】
録画予約自身、明示的に録画開始時刻及び録画継続時間を有することから、録画予約同士の競合を避けることは容易である。例えば、１０時から１時間録画を行う録画予約Ａと、１２時から１時間録画を行う録画予約Ｂはデバイス競合を起こすことはないが、１０時半から１時間録画を行う録画予約Ｃは録画予約Ａとデバイス競合を起こす。この場合、少なくとも１０時半から１１時の間、二つの録画処理が要求されることになるからである。レコーディングマネージャ管理１６０５ｇは、このような録画予約時間の重複を事前に検知する機能を有する必要がある。
【０２０２】
しかし、録画予約はデバイスを利用する時間帯が明示的に示されているのに対し、放送ＭＰＥＧ２トランスポートストリームに含まれる映像音声の再生のような「Ｊａｖａプログラムがリアルタイムに要求を出して開始される処理」は、デバイスを利用する期限が明示的に示されない。さらに、いつＪａｖａプログラムがこの処理を開始するか、端末には予測のしようがない。本発明ではこのように、いつ開始されいつ終了するか端末が予測できない処理を「突発処理」と呼ぶ。
【０２０３】
ＯＣＡＰ仕様で規定される、ＭＰＥＧ２ストリーム内の情報を利用して行われる処理（セクションフィルタリング処理、ＡＶ再生など）は全て突発処理である。突発処理同士のデバイス競合は、デバイス競合が起こったときにデバイス競合解決を行えばよい。
【０２０４】
録画予約時に、録画予約同士の「未来のデバイス競合」を解決するのが容易であることは既に述べた。しかし突発処理と録画予約のデバイス競合は、予約された録画の開始時刻になってみなければ起こるかどうか不明である（事実１）。
【０２０５】
また、前述したように、ＯＣＡＰ仕様が規定するデバイス競合解決アルゴリズム１及びデバイス競合解決アルゴリズム２に準拠したデバイス競合解決処理に要する時間は、端末が事前に予測することは不可能である（事実２）。
【０２０６】
上記事実１及び事実２より、「デバイス競合解決を録画開始時刻になってから開始した場合、予約時に指定された時刻から録画を開始することは不可能であり、録画開始時刻を守るためには、事前にデバイス競合解決を行っておく必要がある」という結論が導かれる。
【０２０７】
本実施の形態では、特権プログラムが、レコーディングマネージャ管理１６０５ｇに対し、「予約録画の開始時刻よりどれくらい前にデバイス競合解決を行うか」を表す時間を予め指定する。レコーディングマネージャ管理１６０５ｇは、録画が実際に開始される時刻よりも前に、デバイス競合解決処理を開始する。
【０２０８】
図３２は本発明を実現するレコーディングマネージャ管理１６０５ｇの構成図である。
【０２０９】
レコーディングマネージャ１６０６については図１６と同様である。
排他デバイス３２２２は前述したように、チューナ１３０１などの排他デバイスを表現する。
【０２１０】
排他デバイス操作ライブラリ３２２１は前述した排他デバイス操作ライブラリを表現する。
【０２１１】
録画予約管理テーブル３２０１は、録画予約情報を保持するテーブルである。録画予約管理テーブル３２０１は、電源切断時にも保持され続けるよう２次記憶部１３０７上に管理される。図３３は録画予約管理テーブル３２０１の例を表現した図である。列３３１１はサービスのチャンネル識別子である。列３３１２は録画予約を行ったＪａｖａプログラムの識別子である。列３３１３は録画を行う時間帯である。列３３１４は録画予約の状態である。「録画待ち」「競合」「未解決」の状態を管理する。「録画待ち」は他の録画予約と録画時間が重複しないこと表現する。「競合」は他の録画予約と録画時間が重複しており、そのままでは録画が開始されないことを表現する。「未解決」は、当該録画予約が、他の録画予約と録画時間帯が重複しているかどうかまだ調査されていないことを表現する。列３３１５は録画予約を一意に特定するための予約ＩＤである。行３３０１〜行３３０３は、録画予約の内容である。
【０２１２】
デバイス競合アラーム３２０２はデバイス競合解決処理部３２０６に対して、デバイス競合解決処理を行うタイミングを通知する内部モジュールである。デバイス競合アラーム３２０２は、端末の起動時に同時に起動される。本モジュールはハードウェアタイマを用いて実装されてもよく、またソフトウェアを用いて実装されてもよい。図３５はデバイス競合アラームが管理するアラームスケジュール表の一例を表現する図である。列３５１１はデバイス競合を解決する時刻である。列３５１２はデバイス競合を解決すべき対象となる録画予約を指す予約ＩＤである。行３５０１〜行３５０３は、各録画予約である。
【０２１３】
レコーディングマネージャアラーム３２０３は、レコーディングマネージャ１６０６に対して、録画開始時刻になったことを通知する内部モジュールであり、端末の起動時に起動される。本モジュールはハードウェアタイマを用いて実装されてもよく、またソフトウェアを用いて実装されてもよい。
【０２１４】
デバイス競合解決間隔管理部３２０４は、特権プログラムが設定した「録画開始時刻に先駆けて行うデバイス競合解決の、録画開始時刻との間隔」を管理する領域である。デバイス競合解決間隔管理部３２０４は、１次記憶部１３０８または２次記憶部１３０７上に実現される領域である。図３６はデバイス競合解決間隔管理部３２０４の一例を表現した図である。３６１１は、間隔を保持する領域である。図３６の例では、間隔は６０秒である。
【０２１５】
録画予約制御部３２０５は、録画予約の情報管理を行うライブラリとして実現される。ＲＯＭ１３０９上に記録され、実行時には１次記憶部１３０８上に展開される。ＪａｖａＶＭ１６０３が実行するＪａｖａプログラムが利用することで動作する。図３４は録画予約制御部３２０５の動作手順を表現するシーケンス図である。Ｓ３４０１において、Ｊａｖａプログラムが録画予約を登録するために指定したチャンネル識別子、録画開始時刻、録画継続時間を取得する。Ｓ３４０２において、Ｓ３４０１にて取得した情報を録画予約管理テーブル３２０１に追加登録する。このとき、状態は「未解決」に設定する。
【０２１６】
Ｓ３４０３では、Ｓ３４０２にて追加した録画予約と、録画時間帯が重複する録画予約があるかどうか調査を行う。Ｓ３４０４にて録画時間帯が重複する録画予約が存在するかどうか判断を行う。存在しなかった場合、Ｎｏに進んでＳ３４０５に至る。Ｓ３４０５では、Ｓ３４０２で追加登録した録画予約と録画時間帯が重複するものが無かったため、状態を「録画待ち」に変更して処理を終了する。分岐Ｓ３４０４にて、時間帯が重複する録画予約が存在した場合、Ｓ３４０６にて、録画予約間でデバイス競合解決を行って、優先する録画予約を決定する。デバイス競合解決は、前述したデバイス競合解決アルゴリズムに従って行われる。Ｓ３４０７では、優先する録画予約に関して、状態を「録画待ち」に設定し、優先しない録画予約に関して、状態を「競合」に設定する。Ｓ３４０８では、Ｓ３４０７にて状態を「録画待ち」に設定された録画予約の録画開始時刻を録画予約管理テーブル３２０１より取得し、レコーディングマネージャアラーム３２０３に当該録画予約の予約ＩＤ及び録画開始時刻を設定する。
【０２１７】
Ｓ３４０８では、Ｓ３４０７にて状態を「録画待ち」に設定された録画予約の録画開始時刻から、デバイス競合解決間隔管理部３２０４より取得した時間だけ早い時刻を計算し、計算の結果得られた時刻及び予約ＩＤをデバイス競合アラーム３２０２に設定する。例えば、録画予約管理テーブル３２０１が図３３の状態にあり、デバイス競合解決間隔管理部が図３６の状態にあり、Ｓ３４０６の結果、状態を「録画待ち」に設定された録画予約が、行３３０１だった場合、行３３０１より取得した録画開始時刻「Ｍａｙ  ５ｔｈ  ２１：００」を６０秒前倒しして「Ｍａｙ  ５ｔｈ  ２０：５９」を得、この値と、行３３０１より取得した予約ＩＤをデバイス競合アラーム３２０２に設定する。
【０２１８】
デバイス競合解決処理部３２０６は予約された録画と突発処理間のデバイス競合解決を行う内部モジュールである。デバイス競合解決処理部３２０６はそれ自体が能動的に動作するプロセスまたはスレッドとして実現され、端末の起動時にＲＯＭ１３０９から１次記憶部１３０８にロードされ、起動される。図３７はデバイス競合解決処理部３２０６の、デバイス競合アラーム３２０２から通知を受けた際の動作手順を表現したシーケンス図である。Ｓ３７０１にて、デバイス競合アラーム３２０２の通知より、事前デバイス競合解決を行う録画予約の予約ＩＤを取得する。Ｓ３７０２にて、Ｓ３７０１で取得した予約ＩＤを利用して、録画予約管理テーブル３２０１から録画予約に関する情報を取得する。Ｓ３７０３に進んで、予約録画に利用する排他デバイスを管理する排他デバイス操作ライブラリより、排他デバイスの利用状況を取得する。Ｓ３７０４にて排他デバイスの利用状況について判定を行う。
【０２１９】
その時点で再生などの突発処理に利用されていなければＮｏに進んでＳ３７０９に至り、録画予約管理テーブル３２０１の当該録画予約の状態を「録画待ち」に設定し、処理を終了する。その時点で突発処理に利用されていればＹｅｓに進んでＳ３７０５に至る。Ｓ３７０５にて、録画予約と、その時点で行われている突発処理間でデバイス競合解決を行い、優先する処理を決定する。デバイス競合解決は前述したデバイス競合解決アルゴリズムに従って行われる。但し、この時点では録画予約と突発処理間の優先順位を決定するのみで、実際のデバイスの奪い取りは行わない。デバイスの奪い取りはレコーディングマネージャ１６０６が実際に録画を開始する際に行われる。Ｓ３７０６にて、Ｓ３７０５にて行ったデバイス競合解決の結果、録画予約を優先するかどうか判断する。録画予約を優先する場合、Ｙｅｓに進んで、Ｓ３７０９に進んで、録画予約管理テーブル３２０１の当該録画予約の状態を「録画待ち」に設定し、処理を終了する。突発処理を優先する場合、Ｎｏに進んでＳ３７０７に至る。
【０２２０】
Ｓ３７０７では、録画予約がデバイス競合のために開始できないことを表現するため、録画予約管理テーブル３２０１の当該録画予約の状態を「競合」に設定する。Ｓ３７０８では、レコーディングマネージャアラーム３２０３に対して、予約ＩＤを指定してアラームの停止を指令する。これにより、当該録画予約に関して、レコーディングマネージャ１６０６が録画を開始することが無くなる。
【０２２１】
デバイス競合解決間隔登録部３２１０は、デバイス競合解決間隔管理部３２０４にデバイス競合解決間隔を記録するために用いられる。デバイス競合解決間隔登録部３２１０は、ライブラリとして実現され、特権プログラムがこれを呼び出すことで、デバイス競合解決間隔を設定する。
【０２２２】
レコーディングマネージャ１６０６は、レコーディングマネージャアラーム３２０３からの通知を受け取って、録画処理を開始する。この録画開始に先立って録画予約と突発処理間のデバイス競合解決は既に終わっているため、この時点で他突発処理が利用するデバイスを強制的に奪い取って、録画処理を開始する。図３８はレコーディングマネージャ１６０６の動作手順を表現したシーケンス図である。Ｓ３８０１にてレコーディングマネージャアラームの通知より、録画予約を指す予約ＩＤを取得する。Ｓ３８０２にて、録画予約管理テーブル３２０１より予約ＩＤで指定された録画予約に関する情報を録画予約管理テーブルから取得する。Ｓ３８０３にて、強制的にデバイスを奪い取り、Ｓ３８０４にて録画を開始する。
【０２２３】
本実施の形態で述べた手法により、実際に録画開始時刻よりも、特権プログラムが指定した間隔だけ先立ってデバイス競合解決処理を進めることができ、録画開始時刻を厳守することができる。
【０２２４】
なお、本例では、予約録画開始時に、レコーディングマネージャ１６０６が、排他デバイスを確保しているが、レコーディングマネージャ１６０６が行うのではなく、デバイス競合解決処理部３２０６が、事前デバイス競合解決処理の終了時に排他デバイスを確保する実装であってもよい。その場合、実際に排他デバイスが確保されるのは、予約録画開始時刻よりも前になる。
【０２２５】
（実施の形態２）
本実施の形態で述べる発明では、デバイス競合解決処理部３２０６による事前デバイス競合解決処理に時間がかかり、レコーディングマネージャ１６０６による録画開始時にまだ特権プログラムによるデバイス競合解決処理が終わっていなかった場合、強制的にデバイス競合解決処理を終了させ、Ｊａｖａプログラムの優先度によるデバイス競合解決処理に移行する。
【０２２６】
図３６におけるデバイス競合解決間隔管理部３２０４の例では、事前デバイス競合解決処理を、録画予約に６０秒先立って行うことを特権プログラムが設定していた。この場合、特権プログラムは６０秒あれば「デバイス競合解決処理を終了することができる」と想定していたことを意味する。しかし、デバイス競合解決処理は特権プログラムの動作を含む特権プログラムが事前に指定した間隔では処理が終わらない可能性がある。この場合、レコーディングマネージャ１６０６がレコーディングマネージャアラーム３２０３によって起こされた時には、まだデバイス競合解決処理部３２０６によるデバイス競合解決が終わっておらず、不整合が発生する。
【０２２７】
本実施の形態では、レコーディングマネージャ１６０６がレコーディングマネージャアラーム３２０３によって起こされた時にまだデバイス競合解決処理部３２０６によるデバイス競合解決が終わっていない場合には、レコーディングマネージャ１６０６はデバイス競合解決処理部３２０６に対して、デバイス競合解決処理を即座に中止するように指令する。その後、デバイス競合解決処理部３２０６に対して、Ｊａｖａプログラムの優先度を用いたデバイス競合解決処理を即座に開始するよう指令する。図３９はレコーディングマネージャ１６０６の動作手順を表すシーケンス図である。Ｓ３９０１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ３９０２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ３９０３にて、録画予約の状態を調査する。
【０２２８】
「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ３９０７に至る。Ｓ３９０７にて、デバイスを強制的に確保し、Ｓ３９０８にて録画を開始して、処理を終了する。分岐Ｓ３９０３にて、録画予約の状態が「録画待ち」ではなく、「未解決」であれば、デバイス競合解決処理部３２０６による事前デバイス競合解決が継続中であることを意味する。このときＮｏに進んでＳ３９０４に至る。
【０２２９】
Ｓ３９０４では、デバイス競合解決処理部３２０６に、事前デバイス競合解決処理の中止を指令し、Ｓ３９０５にて、Ｊａｖａプログラムの優先度を用いたデバイス競合解決処理を即座に実行するようデバイス競合解決処理部３２０６に指令する。Ｓ３９０６の優先度判定の結果、録画優先であれば、Ｙｅｓに進んでＳ３９０７に至り、前述の処理を行う。録画優先でなければＮｏに進んで処理を終了する。
【０２３０】
（実施の形態３）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合、強制的に予約録画処理を優先する。
【０２３１】
図４０はレコーディングマネージャ１６０６の動作手順を表すシーケンス図である。Ｓ４００１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ４００２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ４００３にて、録画予約の状態を調査する。「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ４００５に至る。Ｓ４００５にて、デバイスを強制的に確保し、Ｓ４００６にて録画を開始して、処理を終了する。Ｓ４００３にて、「未解決」であればＮＯに進んでＳ４００４に至る。Ｓ４００４にて、デバイス競合解決処理部３２０６に事前デバイス競合解決の中止を指令し、Ｓ４００５に進む。
【０２３２】
なお、本実施の形態では、予約録画を常に優先しているが、再生などの突発処理を常に優先する方針であってもよい。
【０２３３】
（実施の形態４）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するか、判定ポリシーを特権プログラムが事前に設定する。録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合は、その判定ポリシーに従って、優先すべき処理を決定する。
【０２３４】
図４１は本実施の形態におけるレコーディングマネージャ管理１６０５ｇの構成である。図３２と同じ番号を持つものは同様であるため説明は省略する。本実施の形態では、デバイス競合解決方針保持部４１０７及びデバイス競合解決方針登録部４１０８を導入する。
【０２３５】
デバイス競合解決方針保持部４１０７は、特権プログラムのよって予め指定された判定ポリシーを保持する。デバイス競合解決方針保持部は、２次記憶部１３０７上に実現され、電源断によってもその内容が失われない。
【０２３６】
デバイス競合解決方針登録部４１０８は、ライブラリとして実現される。デバイス競合解決方針登録部４１０８は、特権プログラムによって利用されると、利用時に指定された判定ポリシーをデバイス競合解決方針保持部４１０７に登録する。
【０２３７】
特権プログラムは、録画予約制御部３２０５利用に先立って、デバイス競合解決方針登録部４１０８呼び出しによって、デバイス競合解決方針を事前に設定しておく。デバイス競合解決方針登録部４１０８が呼び出されると、端末は引数に指定されたデバイス競合解決方針をデバイス競合解決方針保持部４１０７に記録する。本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先するか、再生などの突発処理を優先するかを表現するフラグ」を含む。
【０２３８】
本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４２に示す。領域４２０１は、上記、事前デバイス競合解決処理が終了しなかった場合の判定ポリシーを記憶する。図４２においては、予約録画を優先する旨が記憶されている。
【０２３９】
図４３は本実施の形態におけるレコーディングマネージャ１６０６の動作を表すシーケンス図である。Ｓ４３０１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ４３０２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ４３０３にて、録画予約の状態を調査する。「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ４３０７に至る。Ｓ４３０７にて、デバイスを強制的に確保し、Ｓ４３０８にて録画を開始して、処理を終了する。
【０２４０】
分岐Ｓ４３０３にて、録画予約の状態が「録画待ち」ではなく、「未解決」であれば、デバイス競合解決処理部３２０６による事前デバイス競合解決が継続中であることを意味する。このときＮｏに進んでＳ４３０４に至る。Ｓ４３０４では、デバイス競合解決処理部３２０６に、事前デバイス競合解決処理の中止を指令する。Ｓ４３０５にて、事前に特権プログラムによって設定されたデバイス競合解決方針をデバイス競合解決方針保持部４１０７より取得する。Ｓ４３０６において、Ｓ４３０５で取得したデバイス競合解決方針を判定し、予約録画優先であれば、Ｙｅｓに進んでＳ４３０７に至り、前述の処理を行う。予約録画優先でなければＮｏに進んで処理を終了する。
【０２４１】
（実施の形態５）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「時間帯毎」に設定する。
【０２４２】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先する時間帯指定」を含む。
【０２４３】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、予約録画が優先される時間帯を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４４に示す。列４４１１は時間帯を表現する。行４４０１及び行４４０２は各時間帯設定を表す。本例では、２００５年１０月１０日の１９：００〜２１：００及び２００５年１０月１１日の１９：００〜２１：００は予約録画が優先される。
【０２４４】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４４に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、予約録画の開始時刻が、そのテーブルに記載された時間帯に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２４５】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持する時間帯は予約録画を優先し、その他の時間帯は再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先する時間帯を保持し、その他の時間帯は予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先する時間帯指定」を含む。
【０２４６】
なお、本実施の形態では、デバイス競合解決方針保持部４１０７が保持する時間帯の中に、予約録画の開始時刻が含まれていれば予約録画優先、として説明したが、予約録画の開始時刻から終了時刻までの時間全体が含まれていれば予約録画優先、としてもよい。また、予約録画の終了時刻が含まれていれば予約録画優先、としてもよい。
【０２４７】
（実施の形態６）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「チャンネル毎」に設定する。
【０２４８】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先するチャンネル識別子」を含む。
【０２４９】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、予約録画が優先されるサービスを特定するチャンネル識別子を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４５に示す。列４５１１はチャンネル識別子を表現する。行４５０１及び行４５０２は各チャンネル識別子設定を表す。本例では、チャンネル識別子「１」及び「２」は予約録画が優先される。
【０２５０】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４５に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、予約録画対象のサービスを表現するチャンネル識別子が、そのテーブルに記載されたチャンネル識別子群に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２５１】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持するチャンネル識別子が表現するサービスに関しては予約録画を優先し、その他のサービスは再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先するサービスのチャンネル識別子を保持し、その他のサービスは予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先するチャンネル識別子」を含む。
【０２５２】
（実施の形態７）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「１以上の番組毎」に設定する。
【０２５３】
ＯＣＡＰ−ＤＶＲ仕様等、番組録画に関する仕様では、番組録画指定時に、番組を特定する番組識別子を与える手法が想定される。この時に利用される番組識別子は１以上の番組を示す。番組識別子は、ＳＩによってサービスや時間帯と結び付けられる。端末は番組識別子を指定した予約録画要求を受信すると、ＳＩを利用して具体的なサービスや録画時間を導出し、録画を行う。
【０２５４】
番組識別子が１つの番組を表現する場合の例として、例えばある映画をあらわす番組識別子を指定して録画予約する。番組識別子が複数の番組を表現する場合の例として、例えばあるドラマの１２回シリーズをあらわす番組識別子を指定して録画予約する。このように、番組識別子は、１つで１以上の番組を表現することができる場合もある。なお、「番組識別子が１つの番組を表すか複数の番組を表すか」、「またどのサービスのどの時間帯を表すか」、をＳＩを利用して解決する方法は、ＳＩの形式によって多種多様であり、説明は割愛する。しかし、どのような解決手段が用いられても本発明は適用可能である。
【０２５５】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先する１以上の番組を指す番組識別子」を含む。
【０２５６】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、予約録画が優先される番組を表現する番組識別子を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４６に示す。列４６１１は番組識別子を表現する。行４６０１及び行４６０２は各番組識別子設定を表す。本例では、番組識別子「１」及び「２」は予約録画が優先される。
【０２５７】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４６に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、予約録画対象の番組を表現する番組識別子が、そのテーブルに記載された番組識別子群に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２５８】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持する番組識別子が表現する番組に関しては予約録画を優先し、その他の番組は再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先する番組の番組識別子を保持し、その他の番組は予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先する番組識別子」を含む。
【０２５９】
なお、本実施の形態において、デバイス競合解決方針保持部４１０７は図４６のように番組識別子を管理するが、番組識別子を予めＳＩを用いて解決し、図４４のような時間帯テーブルに変更して保持してもよい。
【０２６０】
（実施の形態８）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「リソース毎」に設定する。
【０２６１】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先するリソース識別子」を含む。
【０２６２】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、録画が優先されるリソースを特定するリソース識別子を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４７に示す。列４７１１はリソース識別子を表現する。行４７０１は各リソース識別子設定を表す。本例では、リソース識別子「チューナ１」は予約録画が優先される。
【０２６３】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４７に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、競合するリソースを表現するリソース識別子が、そのテーブルに記載されたリソース識別子群に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２６４】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持するリソース識別子が表現するリソースに関しては予約録画を優先し、その他のリソースは再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先するリソースのリソース識別子を保持し、その他のリソースは予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先するリソースを特定するリソース識別子」を含む。
【０２６５】
（実施の形態９）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、予約録画時に、録画予約制御部３２０５に引数として与える。
【０２６６】
本実施の形態における録画予約制御部３２０５の引数には、録画対象を指し示す値以外に、少なくとも「予約録画を優先するかどうかを表現するフラグ」を含む。
【０２６７】
図４８は、本実施の形態において、録画予約管理テーブル３２０１が管理する情報を表現する図である。列３３１１〜列３３１５は図３３と同様なので説明は省略する。列４８１６は、録画予約毎に「予約録画を優先するか、再生などの突発処理を優先するか」を表現する録画優先フラグである。行４８０１〜行４８０３は、録画優先フラグを含む、各録画予約である。本例では、行４８０１及び行４８０３に記載される録画予約に関しては録画優先フラグが“ＴＲＵＥ”なので予約録画を優先し、行４８０２に記載される録画予約に関しては録画優先フラグが“ＦＡＬＳＥ”なので再生などの突発処理を優先することを表現する。
【０２６８】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と二点を除いて同様である。異なる点の第一は、Ｓ４３０５において読み出されるのは、録画予約管理テーブル３２０１が管理する図４８に表される情報であることである。異なる点の第二は、Ｓ４３０６における判定に際し、競合を起こしている録画予約に関して、その録画予約の録画優先フラグが“ＴＲＵＥ”であれば予約録画を優先し、“ＦＡＬＳＥ”であれば再生などの突発処理を優先させることである。
【０２６９】
なお、本実施の形態では、録画予約管理テーブル３２０１が管理する図４８の列４８１６の録画優先フラグは、“ＴＲＵＥ”であれば予約録画優先、“ＦＡＬＳＥ”であれば再生などの突発処理優先を表現するが、録画優先フラグの代わりに突発処理優先フラグを導入し、“ＴＲＵＥ”であれば再生などの突発処理優先、“ＦＡＬＳＥ”であれば予約録画優先を表現してもよい。この場合、録画予約制御部３２０５は少なくとも、「再生などの突発処理を優先するかどうかを表現するフラグ」を引数として含む。
【０２７０】
（実施の形態１０）
本実施の形態では、本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、特権プログラムに対して、事前デバイス競合解決処理を延長して実行し続けるかどうか問い合わせる。
【０２７１】
図４９は本実施の形態におけるレコーディングマネージャ管理１６０５ｇの構成である。図３２と同じ番号のものは、同様の機能を持つため説明は割愛する。図４９では、時間切れコールバック保持部４９０７及び時間切れコールバック登録部４９０８が導入されている。
【０２７２】
時間切れコールバック保持部４９０７は、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に呼び出す時間切れコールバックを保持する。時間切れコールバック保持部４９０７は、１次記憶部１３０８または２次記憶部１３０７上の領域として実現される。または専用レジスタとして実現されてもよい。
【０２７３】
時間切れコールバック登録部４９０８は、時間切れコールバック保持部４９０７に保持する時間切れコールバックを登録するのに利用される。時間切れコールバックの登録は、特権プログラムが時間切れコールバック登録部４９０８を呼び出すことによって成される。時間切れコールバック登録部４９０８は、ライブラリとして実現され、実態はＲＯＭ１３０９に存在し、端末の起動時に１次記憶部１３０８に展開される。
【０２７４】
図５０は時間切れコールバックが登録されている場合のレコーディングマネージャ１６０６の動作を表現するシーケンス図である。Ｓ５００１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ５００２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ５００３にて、録画予約の状態を調査する。「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ５００４に至る。
【０２７５】
Ｓ５００４にて、デバイスを強制的に確保し、録画を開始して、処理を終了する。分岐Ｓ５００３にて、録画予約の状態が「録画待ち」ではなく、「未解決」だった場合、事前デバイス競合解決がまだ終わっていないことを意味する。この場合Ｎｏに進んでＳ５００５に至る。ここで時間切れコールバック保持部４９０７に保持される時間切れコールバックを取得する。Ｓ５００６に進み、時間切れコールバックを取得できたかどうか判定を行う。もしなければＳ５０１０に進んでデバイス競合解決処理部に事前デバイス競合解決の中止を指令して処理を終了する。Ｓ５００６で、時間切れコールバックを取得できた場合、Ｙｅｓに進んでＳ５００７に進み、時間切れコールバックを呼び出して、時間内に処理が終了しなかったことを通知する。時間切れコールバックは、返値として、事前デバイス競合解決処理を延長するか終了するかを返す。
【０２７６】
返値が「ＮＯ」だった場合、Ｓ５０１０に進んでデバイス競合解決処理部に事前デバイス競合解決の中止を指令して処理を終了する。返値が「ＹＥＳ」だった場合、事前デバイス競合解決処理を延長するため、Ｓ５００９へ進んで、レコーディングマネージャアラーム３２０３に、再度デバイス競合解決間隔管理部３２０４が管理するタイムアウト時間を設定してアラームを依頼し、処理を終了する。レコーディングマネージャアラーム３２０３にアラームを依頼したことにより、タイムアウト時間が経過したあとに再度図５０のシーケンスが励起される。
【０２７７】
なお、本実施の形態では、Ｓ５００９にてアラームを再設定する際、アラームの時間間隔としてデバイス競合解決間隔管理部３２０４が保持するタイムアウト値を用いた。しかしＳ５００７にて呼び出すコールバックの返値として、新規タイムアウト値を取得し、それを利用してもよい。その場合、Ｓ５００８で行われる判定は上記説明と異なり、返値が０より大きければ事前デバイス競合解決処理延長とみなしてＳ５００９に進み、返値が０以下であれば延長はしないとみなしてＳ５０１０に進む。
【０２７８】
なお、本実施の形態では、Ｓ５０１０にて事前デバイス競合解決処理を中止した後、処理を終了しているが、以前の実施の形態で述べたように、さらにデバイス競合解決処理を行っても良い。例えば実施の形態２にあるようにＪａｖａプログラムの優先度解決を行ってもよいし、実施の形態３にあるように強制的に録画を開始することにしても良い。実施の形態４以降にあるように様々な判定ポリシーを利用して競合解決を図っても良い。また、その場合、どのデバイス競合解決処理を選択するかをコールバックの返値を用いて決定してもよい。例えば「−１」であれば録画強制開始、「−２」であればＪａｖａプログラムの優先度解決、「−３」であれば判定ポリシーを用いた解決、などとしてもよい。
【０２７９】
また、本実施の形態では、Ｓ５００９にて再処理のための間隔を指定してアラーム設定しているが、再処理を想定せず、無限に待つことにしてもよい。この場合、デバイス競合解決処理部３２０６の処理は無限に待たれ、終了した時点で、デバイス競合解決処理部３２０６がレコーディングマネージャ１６０６を起こして録画処理を開始することになる。
【０２８０】
以上説明したいくつかの実施例は、本発明の実現例を示したものであり、本発明の趣旨が実現される限り他の実現例でも実施可能である。
【０２８１】
実施例ではケーブルシステムを対象とした構成を示したが、本発明は放送システムの種類に依存しない。例えば、衛星システム、地上波システム、あるいはＩＰネットワークを用いた番組配信システムなどにも容易に適応可能である。さらに本発明は各放送システムの違いと直接的な関係を持たないため、放送システムに係らず任意の伝送媒体で適用可能である。有線、無線の違いにも依存しない。
【０２８２】
ＡＶデコーダは、必ずしも映像および音声を同時にデコードする必要はない。映像デコーダ、音声デコーダを分離した構成としても、本発明は実現可能である。またＡＶデコーダがクローズドキャプションなどのデータに対するデコード機能を持っていても差し支えない。ＡＶデコーダによってデコードされたａｕｄｉｏ信号およびｖｉｄｅｏ信号が、記録領域１４０４に蓄積されるまでの任意の段階において暗号化されてもよい。
【０２８３】
実施例では、限定視聴を制御するアダプタを導入した例を示したが、アダプタは本発明を実現するために必ずしも必要ではない。アダプタの形式がいかなるものであってもよいし、またアダプタのない構成とすることも可能である。その場合、図１４において、チューナからのＭＰＥＧ２トランスポートストリームが直接ＴＳデコーダに入力される。この場合も本発明は適用可能である。また、アダプタによる限定視聴解除をＴＳデコーダ以前に行う必要はない。任意の位置でアダプタを利用して限定視聴を解除する構成とすることは容易であり、その場合も本発明は適用可能である。
【０２８４】
ＡＶエンコーダによるａｕｄｉｏ信号およびｖｉｄｅｏ信号のエンコード形式は、任意の形式であってもよい。本発明はいかなるエンコード形式であっても適用可能である。
【０２８５】
多重器の多重形式は任意の形式であってもよい。本発明はいかなる多重形式であっても適用可能である。
【０２８６】
ディスプレイ及びスピーカは、放送録画再生装置内部に包含していてもよく、放送録画再生装置に外部ディスプレイ及びスピーカを接続してもよい。ディスプレイおよびスピーカの存在場所や数によらず、本発明は適用可能である。
【０２８７】
ＣＰＵ自身が、ＴＳデコード、ＡＶデコード、ＡＶエンコードおよび多重化のすべてあるいはいくつかの処理を兼用で行うシステムであっても本発明は実施可能である。
【０２８８】
サービスを記録する形式としては、他にもＴＳデコーダを介さずにチューナからのＭＰＥＧ２トランスポートストリーム出力を直接、記録領域記録してもよいし、ＭＰＥＧ２トランスポートストリームの形式を変換するトランスレータを設けてチューナからのＭＰＥＧ２トランスポートストリームを形式変換して記録領域に記録してもよい。いかなるサービス記録方式を用いても、本発明は実施可能である。
【０２８９】
一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵが理解可能な実行形式に翻訳してから、ＣＰＵに引渡して実行するが、この場合でも本発明は適用可能である。
【０２９０】
以上の実施例では、トランスポートストリームがＩｎ−ｂａｎｄから得られるとしてＡＩＴに関して実現方法を説明したが、ＡＭが実行すべきＪａｖａプログラムを参照する手法はＡＩＴによるものだけではない。米国ケーブルシステムで利用されることが想定されるＯＣＡＰでは図３に記載されるＯＯＢにてアプリケーションプログラムの参照情報を記載するＸＡＩＴが利用されている。その他、ＲＯＭに予め記録されているものを起動する、２次記憶にダウンロードして記憶したものを起動する、等の方法も考えられる。
【０２９１】
一部実施例では、事前リソース競合解決が、録画予約開始時刻に間に合わなかった場合の判定ポリシーを、特権プログラムが設定することに関して言及しているが、この場合、複数の判定ポリシーを同時に利用することも可能である。例えば、録画を優先するサービスを表現するチャンネル識別子、及び、その時間帯を指定することにより、条件に合致するサービスで、さらに条件に合致する時間帯のみ録画を優先する、といった指定が可能となる。これはチャンネル識別子と時間帯のペアだけでなく、言及した判定ポリシー同士のいかなる組み合わせを用いることも可能である。
【０２９２】
また、本発明において、特権プログラムが指定する「事前リソース競合解決処理（事前デバイス競合解決処理）を開始する、録画開始時刻から遡る時間間隔（実施の形態１では６０秒を例として説明）」は、特権プログラムが設定する値が用いられるため何秒であってもよい。さらに、特権プログラムが設定するのでなく、端末独自の値を用いるものであっても良い。さらに、遡る基準の時刻は「録画開始時刻」としているが、端末によっては、ＨＤＤ回転処理等、録画を開始するための準備に既に時間をかけなければならない場合があるため、「録画開始時刻を端末固有の準備時間だけ遡った時刻」を基準時刻としてもよい。
【０２９３】
上記に詳細に説明した本発明の実施の形態は単なる例示にすぎず、本発明の新規な教示および効果から実質的に逸脱することなく例示として挙げた実施の形態において様々な変更が可能であることは、当業者であれば容易に理解するところである。したがって、かかる変更はすべて本発明の範囲内に含まれるものである。                                                                             
【産業上の利用可能性】
【０２９４】
本発明は放送信号からアプリケーションをダウンロードして実行する電子機器で、利用可能である。
【図面の簡単な説明】
【０２９５】
本願におけるこれらの目的および他の目的や、効果、特徴は、実施の形態を示す付属図面に関する以下の説明から明確になる。当該図面において、
【図１】図１は、本発明に係る放送システムの構成図である。
【図２】図２は、本発明に係るケーブルテレビシステムにおいて放送局側システムと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図３】図３は、本発明に係るケーブルテレビシステムにおいて放送局側システムと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図４】図４は、本発明に係るケーブルテレビシステムにおいて放送局側システムと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図５】図５は、ＭＰＥＧ２仕様で既定されるＴＳパケットの構成図である。
【図６】図６は、ＭＰＥＧ２トランスポートストリームの模式図である。
【図７】図７は、ＭＰＥＧ２仕様で既定されるＰＥＳパケットがＴＳパケットを用いて伝送される際の分割例を示す図である。
【図８】図８は、ＭＰＥＧ２仕様で既定されるＭＰＥＧ２セクションがＴＳパケットを用いて伝送される際の分割例を示す図である。
【図９】図９は、ＭＰＥＧ２仕様で既定されるＭＰＥＧ２セクションの構成図である。
【図１０】図１０は、ＭＰＥＧ２仕様で既定されるＭＰＥＧ２セクションの利用例を示す図である。
【図１１】図１１は、ＭＰＥＧ２仕様で規定されるＰＭＴの利用例を示す図である。
【図１２】図１２は、ＭＰＥＧ２仕様で規定されるＰＡＴの利用例を示す図である。
【図１３Ａ】図１３Ａは、本発明に係る放送録画再生装置のハードウェア構成の構成例を示す図である。
【図１３Ｂ】図１３Ｂは、本発明にかかる入力部をフロントパネルで構成した場合の一例を示す図である。
【図１４】図１４は、本発明に係る録画再生装置の録画時におけるデバイス接続例を示す図である。
【図１５】図１５は、本発明に係る録画再生装置の再生時におけるデバイス接続例を示す図である。
【図１６】図１６は、本発明に係る端末装置が保存するプログラム構成の構成図である。
【図１７】図１７は、本発明に係る端末装置が実行するＥＰＧの一例を示す図である。
【図１８】図１８は、本発明に係る端末装置が実行するＥＰＧの一例を示す図である。
【図１９】図１９は、本発明に係る２次記憶部が保存する情報の一例を示す図である。
【図２０】図２０は、本発明に係るレコード情報管理テーブルの一例を示す図である。
【図２１】図２１は、本発明に係るＤＶＢ−ＭＨＰ規格が規定するＡＩＴの内容を表す模式図である。
【図２２】図２２は、本発明に係るダウンロードアプリケーションの構成図である。
【図２３】図２３は、本発明に係るデバイスの獲得及び解放を表現するシーケンス図である。
【図２４】図２４は、本発明に係るＩｎ−ｂａｎｄ受信用チューナ管理テーブルの一例を示す図である。
【図２５】図２５は、本発明に係る排他デバイス確保ＡＰＩの動作を表現するシーケンス図である。
【図２６】図２６は、本発明に係るデバイス競合アルゴリズム１のシーケンス図である。
【図２７】図２７は、本発明に係るデバイス競合アルゴリズム２のシーケンス図である。
【図２８】図２８は、本発明に係るデバイス競合アルゴリズム２のシーケンス図である。
【図２９】図２９は、本発明に係るデバイス競合アルゴリズム２のシーケンス図である。
【図３０】図３０は、本発明に係るデバイス競合解決アルゴリズム１利用時の時間消費を表現したシーケンス図である。
【図３１】図３１は、本発明に係るデバイス競合解決アルゴリズム２利用時の時間消費を表現したシーケンス図である。
【図３２】図３２は、本発明を実現するレコーディングマネージャ管理１６０５ｇの構成図である。
【図３３】図３３は、録画予約管理テーブル３２０１の例を表現した図である。
【図３４】図３４は、録画予約制御部３２０５の動作手順を表現するシーケンス図である。
【図３５】図３５は、デバイス競合アラームが管理するアラームスケジュール表の一例を表現する図である。
【図３６】図３６は、デバイス競合解決間隔管理部３２０６の一例を表現した図である。
【図３７】図３７は、デバイス競合解決処理部３２０６の、デバイス競合アラーム３２０２から通知を受けた際の動作手順を表現したシーケンス図である。
【図３８】図３８は、レコーディングマネージャ１６０６の動作手順を表現したシーケンス図である。
【図３９】図３９は、レコーディングマネージャ１６０６の動作手順を表すシーケンス図である。
【図４０】図４０は、レコーディングマネージャ１６０６の動作手順を表すシーケンス図である。
【図４１】図４１は、実施の形態４におけるレコーディングマネージャ管理１６０５ｇの構成を示す図である。
【図４２】図４２は、実施の形態４におけるデバイス競合解決方針保持部４１０７が管理するテーブル例である。
【図４３】図４３は、実施の形態４におけるレコーディングマネージャ１６０６の動作を表すシーケンス図である。
【図４４】図４４は、実施の形態５における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４５】図４５は、実施の形態６における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４６】図４６は、実施の形態７における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４７】図４７は、実施の形態８における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４８】図４８は、実施の形態９における、録画予約管理テーブル３２０１が管理する情報を表現する図である。
【図４９】図４９は、実施の形態１０における、レコーディングマネージャ管理１６０５ｇの構成を示す図である。
【図５０】図５０は、実施の形態１０における、レコーディングマネージャ１６０６の動作シーケンス図である。
【図１】
2008543123.tif 000003
【図２】
2008543123.tif 000004
【図３】
2008543123.tif 000005
【図４】
2008543123.tif 000006
【図５】
2008543123.tif 000007
【図６】
2008543123.tif 000008
【図７】
2008543123.tif 000009
【図８】
2008543123.tif 000010
【図９】
2008543123.tif 000011
【図１０】
2008543123.tif 000012
【図１１】
2008543123.tif 000013
【図１２】
2008543123.tif 000014
【図１３Ａ】
2008543123.tif 000015
【図１３Ｂ】
2008543123.tif 000016
【図１４】
2008543123.tif 000017
【図１５】
2008543123.tif 000018
【図１６】
2008543123.tif 000019
【図１７】
2008543123.tif 000020
【図１８】
2008543123.tif 000021
【図１９】
2008543123.tif 000022
【図２０】
2008543123.tif 000023
【図２１】
2008543123.tif 000024
【図２２】
2008543123.tif 000025
【図２３】
2008543123.tif 000026
【図２４】
2008543123.tif 000027
【図２５】
2008543123.tif 000028
【図２６】
2008543123.tif 000029
【図２７】
2008543123.tif 000030
【図２８】
2008543123.tif 000031
【図２９】
2008543123.tif 000032
【図３０】
2008543123.tif 000033
【図３１】
2008543123.tif 000034
【図３２】
2008543123.tif 000035
【図３３】
2008543123.tif 000036
【図３４】
2008543123.tif 000037
【図３５】
2008543123.tif 000038
【図３６】
2008543123.tif 000039
【図３７】
2008543123.tif 000040
【図３８】
2008543123.tif 000041
【図３９】
2008543123.tif 000042
【図４０】
2008543123.tif 000043
【図４１】
2008543123.tif 000044
【図４２】
2008543123.tif 000045
【図４３】
2008543123.tif 000046
【図４４】
2008543123.tif 000047
【図４５】
2008543123.tif 000048
【図４６】
2008543123.tif 000049
【図４７】
2008543123.tif 000050
【図４８】
2008543123.tif 000051
【図４９】
2008543123.tif 000052
【図５０】
2008543123.tif 000053
【手続補正書】
【提出日】平成19年3月16日(2007.3.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
受信した映像情報および音声情報を記録媒体に記録する記録手段と、
前記受信した映像情報および音声情報、または前記記録手段により記録された前記映像情報および前記音声情報を再生する再生手段とを備えた放送受信端末であって、
前記放送受信端末内で実行される第１のプログラムからの要求に従い、前記記録処理を実行する開始時刻および前記記録処理を継続する継続時間を含む予約情報を登録する予約登録手段と、
前記予約登録手段により登録された予約情報を保持する予約保持手段と、
リソース管理手段が管理するリソースが競合する場合、前記競合を解決するための基準を保持する特権プログラムと、
前記第１のプログラムより予約した前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの排他的使用が可能かどうかを調べ、前記所定のリソースが既に前記放送受信端末内で実行される第２のプログラムにより確保されている場合は、前記特権プログラムが定める基準に従って、どちらのプログラムが前記所定のリソースを確保すべきかについて判定処理を行うリソース競合解決手段と、
前記予約保持手段が保持する開始時刻よりもどれくらい前に前記リソース競合解決手段を機能させるかを示す時間間隔情報を保持する解決時間間隔保持手段と、
前記第１のプログラム、前記第２のプログラム、および前記特権プログラムを実行する実行手段とを備え、
前記放送受信端末の電源投入後に前記特権プログラムは受信されて記録され、
前記予約保持手段が保持する前記記録処理を実行する開始時刻よりも前の時刻であって、前記解決時間間隔保持手段が保持する時間間隔に相当する前の時刻になった時点で、前記リソース競合解決手段は機能し、
前記リソース競合解決手段により前記所定のリソースを確保すべきと判定されたプログラムが前記所定のリソースを確保し、前記確保されたリソースを用いて所定の処理、または予約保持手段に保持されている前記予約情報に従った記録処理を実行する
ことを特徴とする放送受信端末。
【請求項２】
前記放送受信端末は、さらに、
前記放送受信端末内で実行されるプログラムからの要求に従い、所定の処理をするために前記放送受信端末内で排他的に使用されるリソースを前記リソースの使用を要求するプログラムに対応付けて管理するリソース管理手段を備え、
前記リソース競合解決手段は、前記リソース管理手段にて管理されるリソースを調べることにより、前記所定のリソースが既に前記放送受信端末内で実行される第１のプログラムにより確保されているかどうかを判断する
ことを特徴とする請求項１記載の放送受信端末。
【請求項３】
前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、
前記リソース管理手段は、前記所定のリソースを前記第２のプログラムと対応付けて管理するのを止め、前記第１のプログラムから要求に従って、前記放送受信端末内で排他的に使用される前記所定のリソースを前記第１のプログラムに対応付けて管理する
ことを特徴とする請求項２記載の放送受信端末。
【請求項４】
前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、
前記リソース管理手段は、前記第２のプログラムへ、前記確保した前記放送受信端末内のリソースを解放することを通知する
ことを特徴とする請求項３記載の放送受信端末。
【請求項５】
前記第１のプログラムおよび前記第２のプログラムは実行の優先度を示す情報を有し、
前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、優先度の高いプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項６】
前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項７】
前記特権プログラムは、解決時間間隔保持手段に保持される時間間隔を指定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項８】
前記放送受信端末は、さらに、
前記リソース競合解決手段がいずれのプログラムからの要求を受け入れるのかを判定するための判定ポリシーを登録する判定ポリシー登録手段と、
前記判定ポリシー登録手段により登録された判定ポリシーを保持する判定ポリシー保持手段とを備え、
前記特権プログラムは、前記判定ポリシー登録手段を用いて前記判定ポリシーを登録し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記判定ポリシー保持手段にて保持されている判定ポリシーを用いて、いずれのプログラムが前記所定のリソースを確保すべきかを判定する
ことを特徴とする請求項１記載の放送受信端末。
【請求項９】
前記判定ポリシー保持手段は、
前記第１のプログラムからの要求に従い記録を優先するか前記第２のプログラムからの要求に従い所定の処理を優先するかを表すフラグを、前記判定ポリシーとして保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記フラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１０】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する時間帯を保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、開始時刻が前記記録を優先する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１１】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する時間帯を保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、前記予約した時間帯が前記判定ポリシー保持手段にて保持する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１２】
前記判定ポリシー保持手段は、
記録を優先する映像情報および音声情報に対応するチャンネル識別子を、前記判定ポリシーとして保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、記録対象となる映像情報および音声情報に対応するチャンネルのチャンネル識別子が前記判定ポリシー保持手段にて保持されているチャンネル識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１３】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する番組の番組識別子を保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、前記判定処理を終了し、
記録対象となる映像情報および音声情報に対応する番組の番組識別子が前記判定ポリシー保持手段にて保持されている番組識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１４】
番組識別子は複数の番組を指定する
ことを特徴とする請求項１３記載の放送受信端末。
【請求項１５】
前記判定ポリシー保持手段は、
前記判定ポリシーとして、記録を優先する前記放送受信端末内のリソースを保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記リソース競合解決手段は、判定処理を終了し、
前記放送受信端末内で実行される第２のプログラムにより確保されているリソースが前記判定ポリシー保持手段にて保持されているリソースに含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定する
ことを特徴とする請求項８記載の放送受信端末。
【請求項１６】
前記予約登録手段は、前記予約情報と共に、前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの競合が発生した場合に記録を優先するか前記所定の処理を優先するかを示すフラグを受け取り、
前記予約保持手段は、前記フラグを予約情報と関連付けて保持し、
前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、
前記記録手段は、前記リソース競合解決手段による判定処理を終了させ、
前記予約情報に対応するフラグに基づいていずれのプログラムが前記所定のリソースを
確保すべきかを前記リソース競合解決手段に判定させる
ことを特徴とする請求項１記載の放送受信端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを蓄積するとともに、蓄積されたコンテンツを再生する録画再生装置たる放送受信端末に関する。殊に、映像、音声およびプログラム等のデータから構成されるコンテンツが相互に同期をとって放送波に多重されて送信され、その放送波を受信して映像、音声、データを蓄積するための仕組み、および、映像、音声とプログラム等のデータの同期を保持しつつコンテンツの早送り、巻戻し等の特殊再生を実行する仕組みに関する。
【背景技術】
【０００２】
放送局から送信される放送波は、多種多様なコンテンツを含んでいる。コンテンツは、通常の番組で用いられる映像、音声の他に、データを含む場合がある。データの送信方法にはいくつかの方式があり、大別して時系列に送信する方式と、一定の間隔ごとに繰り返し送信する方式がある。前者の時系列に送信する方式では、例えば時間経過に合わせて連続するデータを順次送出していく。大量のデータを長時間かけて送信する場合に適しているが、送信タイミングで受信しなかった場合は二度と受信できないという欠点がある。一方、後者の一定の間隔ごとに繰り返し送信する方式では、同じデータを一定の期間何度も繰り返し送出する。同一データを送出している期間内に、繰り返し送信されているデータのいずれかひとつを受信すればよいので、受信タイミングが限定されないというメリットがある。例えば、ＢＭＬに代表されるデータ放送や、ＤＳＭＣＣデータカルーセルによるファイル送信がこの方式である。特に放送においては、受信者がいつ選局して受信を開始するかわからない。時系列に送信する方式では、受信開始が送信時間よりも遅れてしまい、データ取得に失敗すると二度と再取得できない。よって、放送波で映像、音声とともにアプリケーションプログラム等のデータを送信したい場合には、一定の間隔ごとに繰り返し送信される方式が好適である。
【０００３】
現在、上記のような方式で、映像、音声とアプリケーションプログラムとを含む放送波を受信し、アプリケーションプログラムを映像、音声と同期して実行するための仕様が策定され、運用されている。通常の映像、音声を見るだけでなく、送信されたアプリケーションプログラムを受信して端末に取り込み、それを実行して様々な付加機能を実現することができる。このようにアプリケーションプログラムを送信して端末に取り込む方法はダウンロードとも呼ばれている。例えば、ＤＶＢ−ＭＨＰ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ−Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ）ＥＴＳＩ  ＥＳ  ２０１  ８１２  Ｖ１．１．１（２００３−１２））仕様が欧州で策定され、既に仕様に準拠した運用が開始されている。また米国ではケーブル放送環境で同様の仕組みを提供するＯＣＡＰ１．０（ＯｐｅｎＣａｂｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｌａｔｆｏｒｍ  ＯＣ−ＳＰ−ＯＣＡＰ１．０−Ｉ１４−０５０１１９）仕様書が策定されており、２００５年に運用開始予定である。これらの仕様では、アプリケーションがＪａｖａ言語で記述されている。端末上にはチューニングやグラフィックス表示のための様々なＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）が用意されており、ＪａｖａアプリケーションはＡＰＩを呼び出すことでそれらの機能を制御できる。
【０００４】
さらに、北米では、ＯＣＡＰ仕様にコンテンツの録画再生機能を追加するためのＯＣＡＰ−ＤＶＲ仕様（ＯＣ−ＳＰ−ＯＣＡＰ−ＤＶＲ−Ｉ０１−０４０５２４）を策定中である。これは放送されるコンテンツ（映像、音声、アプリケーション等）を記録し、さらに記録したコンテンツを、放送されるコンテンツと同様に再生するものである。
【０００５】
ＯＣＡＰ−ＤＶＲ仕様では、録画予約ＡＰＩが規定され、Ｊａｖａアプリケーションは本ＡＰＩを利用することで、録画予約を登録することが可能である。Ｊａｖａアプリケーションが録画予約ＡＰＩを用いて登録した録画予約に基づき、ＯＣＡＰ−ＤＶＲ端末は指定録画開始時刻に録画を開始、指定録画終了時刻に録画を終了する。
【０００６】
ＯＣＡＰ及びＯＣＡＰ−ＤＶＲ仕様が規定する様々な機能は、端末に存在するデバイスを利用することで実現される。例えば、放送信号に含まれる映像・音声を再生するためには、放送信号から単一のデータストリームを抽出するチューナ、チューナが出力するデータストリームから映像・音声を取り出すＴＳデコーダ、取り出された映像・音声をデコードして再生するＡＶデコーダといったデバイスを利用する。つまり、端末の能力は端末が搭載するデバイスが決定する、と言うことができる。例えば、前述のチューナは放送信号を受信して映像音声再生するときだけでなく、放送信号を録画する際にも用いられる。チューナは放送信号から同時に複数のデータストリームを抽出することはできないため、「映像音声の再生」と、「録画」を同時に実行するためには、２つのチューナが必要になる。従って１つのチューナのみを搭載する端末では「映像音声再生」及び「録画」を同時に実行することはできない。
【０００７】
ＯＣＡＰ−ＤＶＲにおいて、複数のＪａｖａアプリケーションが同時に実行されることがある。各々のＪａｖａアプリケーションは独立して動作し、両方がＯＣＡＰ及びＯＣＡＰ−ＤＶＲの規定ＡＰＩを利用して所望の機能実現を果たそうとする。例えば、ＪａｖａアプリケーションＡが行った録画予約の開始時刻付近でＪａｖａアプリケーションＢが「映像音声再生」を要求することも想定される。このような場合、もし２チューナを搭載する端末であれば、特に問題はなく、「映像音声再生」及び「録画」を同時に実行可能である。しかし、１チューナのみを搭載する端末では、デバイスの絶対数が足りないため、同時に両方の処理を実行することができない。このように、「デバイスの絶対数または能力が不足しているため、要求される複数の処理を同時に実行できない状況」を一般に「競合」と呼ぶ。これは１チューナの時だけ起こる状況と言うわけではない。２チューナを搭載する端末であっても、「映像音声再生」及び２チャンネルの「録画」を同時に処理することが要求されることはあり得、その場合はやはり全ての処理を同時に実行することはできないために「競合」が発生する。
【０００８】
このような「競合」、特に録画予約に関する競合を解決するためのアルゴリズムを定義する知財は既に存在する。特願２００３−６４４５は、「録画予約と追っかけ再生用の録画が同時に要求され、デバイスの競合が起こった際は、常に録画予約を優先する」というデバイス競合ポリシーに関する特許である。このようなポリシーを事前に決定しておくことで、端末は競合を解決し、どちらか一方を優先して処理を進めることができる。
【０００９】
特願２００３−６４４５のように録画予約が絡むデバイス競合の解決ポリシーを事前に決定しておくことで、デバイス競合が実際に起こったときに、どちらの処理を優先するか判断し、処理を進めることができる。しかしながら、これは端末内部で自由にデバイス競合の解決を行い、実行する処理を決定してよい場合だけに適用可能な、端末独自のポリシーである。ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様といったＪａｖａ仕様のいくつかは、デバイス競合が起こったときの解決手順を規定している。典型的な例として、ここでは、ＯＣＡＰが規定する２種類のデバイス競合解決手順をまず紹介する。ＯＣＡＰ仕様に準拠した端末は、放送信号に含まれるＪａｖａアプリケーションをダウンロードして実行することは既に述べた。この端末上では１以上のＪａｖａアプリケーションが同時に動作し、各々が所望の機能を実現するためにＪａｖａＡＰＩを利用するため、端末は同時に複数の処理を要求されることがありうる。このような状況が発生し、デバイスの絶対数が足りないためにデバイスの競合が起こったときにデバイス競合解決が行われる。
【００１０】
第一の手順では、Ｊａｖａアプリケーションの優先度を利用して、デバイス競合解決を行う。ＯＣＡＰ仕様では、各Ｊａｖａアプリケーションは固有の優先度を持っており、高い優先度を持つＪａｖａアプリケーション程重要なアプリケーションである、と位置づけられる。そのため、複数のＪａｖａアプリケーションが同時に行われる複数の処理を要求した場合、より優先度の高いＪａｖａアプリケーションが要求した処理を優先的に動作させる。
【００１１】
第二の手順では、Ｊａｖａアプリケーションの優先度とは関係なく、ある特殊アプリケーションが、優先すべきＪａｖａアプリケーションを決定する。ＯＣＡＰ仕様にはある特権を持ったアプリケーションが定義される。これをモニタアプリケーションと呼ぶ。モニタアプリケーションは、デバイスの競合が起こったときに端末によって呼び返される「デバイス競合解決用のコールバック関数」を事前に端末に登録することができる。この「コールバック関数」が登録されている場合、端末がデバイスの競合が起こったことを検知したら、Ｊａｖａアプリケーションの優先度による判断を行う前に、このコールバック関数を呼ぶ。このコールバック関数は、返値として、優先すべきＪａｖａアプリケーションの識別子を端末に引き渡す。端末はＪａｖａアプリケーション自身に設定された優先度に関係なく、このコールバック関数の返値として引き渡されたＪａｖａアプリケーションが要求する処理を優先的に実行する。
【００１２】
特に第二の手順においては、デバイス競合の解決は完全にモニタアプリケーションに任される。端末はモニタアプリケーションのコールバック関数が返した返値に従ってデバイスを振り分けるのみである。つまり、デバイス競合が起こったときの解決ポリシーは、この場合、端末ではなくモニタアプリケーションが制御している、と捉えられる。
【００１３】
上記デバイス競合解決用のコールバック関数は、モニタアプリケーションによって実装される。ある実装は、単にＪａｖａアプリケーションの優先度をコールバック関数の内部で判断しているだけかもしれない。ある実装は、画面に選択肢ダイアログを提示して、どちらを優先するかユーザの入力を１分間待っているかもしれない。またある実装は、ユーザに選択肢ダイアログを提示して、どちらを優先するかユーザ入力を永久に待ち続けるかもしれない。つまり、端末がこのコールバック関数がいつリターンするかを予測することは不可能であり、ひいては、端末はコールバック関数がリターンするまでは、どちらの処理を優先して実行するか決定することができない。
【００１４】
これは、録画予約にとっては致命的なシステム欠陥である。例えば、「予約録画」と「映像音声再生」が同時に２つのＪａｖａアプリケーションによって要求され、デバイス競合が起こった場合を考える。この時、もしデバイス競合解決用コールバック関数が登録されていれば、端末はＯＣＡＰまたはＯＣＡＰ-ＤＶＲ仕様に従って、そのコールバック関
数を呼ばなければならない。しかし、もし予約録画開始時刻になってもコールバック関数が判定結果をリターンしなければ、端末は再生も録画もできずにずっと待っているより他ない。
【００１５】
そこで本発明は、かかる問題に鑑みてなされたものであって、リソースの競合を解決する録画再生装置を提供することを目的とする。
【発明の開示】
【００１６】
上記目的を達成するために、本発明の放送受信端末は、受信した映像情報および音声情報を記録媒体に記録する記録手段と、前記受信した映像情報および音声情報、または前記記録手段により記録された前記映像情報および前記音声情報を再生する再生手段とを備えた放送受信端末であって、前記放送受信端末内で実行される第１のプログラムからの要求に従い、前記記録処理を実行する開始時刻および前記記録処理を継続する継続時間を含む予約情報を登録する予約登録手段と、前記予約登録手段により登録された予約情報を保持する予約保持手段と、リソース管理手段が管理するリソースが競合する場合、前記競合を解決するための基準を保持する特権プログラムと、前記第１のプログラムより予約した前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの排他的使用が可能かどうかを調べ、前記所定のリソースが既に前記放送受信端末内で実行される第２のプログラムにより確保されている場合は、前記特権プログラムが定める基準に従って、どちらのプログラムが前記所定のリソースを確保すべきかについて判定処理を行うリソース競合解決手段と、前記予約保持手段が保持する開始時刻よりもどれくらい前に前記リソース競合解決手段を機能させるかを示す時間間隔情報を保持する解決時間間隔保持手段と、前記第１のプログラム、前記第２のプログラム、および前記特権プログラムを実行する実行手段とを備え、前記放送受信端末の電源投入後に前記特権プログラムは受信されて記録され、前記予約保持手段が保持する前記記録処理を実行する開始時刻よりも前の時刻であって、前記解決時間間隔保持手段が保持する時間間隔に相当する前の時刻になった時点で、前記リソース競合解決手段は機能し、前記リソース競合解決手段により前記所定のリソースを確保すべきと判定されたプログラムが前記所定のリソースを確保し、前記確保されたリソースを用いて所定の処理、または予約保持手段に保持されている前記予約情報に従った記録処理を実行することを特徴とする。
【００１７】
これにより、所定の処理と予約に従った記録処理とによるリソースの競合を解決することができる。
【００１８】
また、前記放送受信端末は、さらに、前記放送受信端末内で実行されるプログラムからの要求に従い、所定の処理をするために前記放送受信端末内で排他的に使用されるリソースを前記リソースの使用を要求するプログラムに対応付けて管理するリソース管理手段を備え、前記リソース競合解決手段は、前記リソース管理手段にて管理されるリソースを調べることにより、前記所定のリソースが既に前記放送受信端末内で実行される第１のプログラムにより確保されているかどうかを判断することを特徴としてもよい。
【００１９】
これにより、所定のリソースの排他的使用が可能かどうかを確実に調べることができる。
【００２０】
また、前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、前記リソース管理手段は、前記所定のリソースを前記第２のプログラムと対応付けて管理するのを止め、前記第１のプログラムから要求に従って、前記放送受信端末内で排他的に使用される前記所定のリソースを前記第１のプログラムに対応付けて管理することを特徴としてもよい。
【００２１】
これにより、所定のリソースとそのリソースを確保しているプログラムとの対応関係を正確に管理することができる。
【００２２】
また、前記リソース競合解決手段において、前記第１のプログラムが前記所定のリソースを確保すべきと判定された場合、前記リソース管理手段は、前記第２のプログラムへ、前記確保した前記放送受信端末内のリソースを解放することを通知することを特徴としてもよい。
【００２３】
これにより、リソースの排他的使用を確実にすることができる。
【００２４】
また、前記第１のプログラムおよび前記第２のプログラムは実行の優先度を示す情報を有し、前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前
記判定処理を終了し、優先度の高いプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００２５】
これにより、リソース競合解決手段による判定処理が終了しなかった場合にプログラムの優先度を用いたリソースの競合解決が可能となる。
【００２６】
また、前記リソース競合解決手段による判定処理が、前記第２のプログラムが新たに予約をした時間の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００２７】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に強制的に記録処理を開始することが可能となる。
【００２８】
また、前記特権プログラムは、解決時間間隔保持手段に保持される時間間隔を指定することを特徴としてもよい。
【００２９】
これにより、使い勝手を向上することができる。
【００３０】
また、前記放送受信端末は、さらに、前記リソース競合解決手段がいずれのプログラムからの要求を受け入れるのかを判定するための判定ポリシーを登録する判定ポリシー登録手段と、前記判定ポリシー登録手段により登録された判定ポリシーを保持する判定ポリシー保持手段とを備え、前記特権プログラムは、前記判定ポリシー登録手段を用いて前記判定ポリシーを登録し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記判定ポリシー保持手段にて保持されている判定ポリシーを用いて、いずれのプログラムが前記所定のリソースを確保すべきかを判定することを特徴としてもよい。
【００３１】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、判定ポリシーを用いたリソース競合解決をすることが可能となる。
【００３２】
また、前記判定ポリシー保持手段は、前記第１のプログラムからの要求に従い記録を優先するか前記第２のプログラムからの要求に従い所定の処理を優先するかを表すフラグを、前記判定ポリシーとして保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記フラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを判定することを特徴としてもよい。
【００３３】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、フラグによるリソース競合解決が可能となる。
【００３４】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する時間帯を保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、開始時刻が前記記録を優先する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００３５】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、時間帯ごとのリソース競合解決が可能となる。
【００３６】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する時間帯を保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記予約した時間帯が前記判定ポリシー保持手段にて保持する時間帯に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００３７】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、時間帯ごとのリソース競合解決が可能となる。
【００３８】
また、前記判定ポリシー保持手段は、記録を優先する映像情報および音声情報に対応するチャンネル識別子を、前記判定ポリシーとして保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、記録対象となる映像情報および音声情報に対応するチャンネルのチャンネル識別子が前記判定ポリシー保持手段にて保持されているチャンネル識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００３９】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、チャンネルごとのリソース競合解決が可能となる。
【００４０】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する番組の番組識別子を保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、記録対象となる映像情報および音声情報に対応する番組の番組識別子が前記判定ポリシー保持手段にて保持されている番組識別子に含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００４１】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、番組ごとのリソース競合解決が可能となる。
【００４２】
また、番組識別子は複数の番組を指定することを特徴としてもよい。
【００４３】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、番組シリーズごとのリソース競合解決が可能となる。
【００４４】
また、前記判定ポリシー保持手段は、前記判定ポリシーとして、記録を優先する前記放送受信端末内のリソースを保持し、前記リソース競合解決手段による判定処理が、前記予約の開始時刻になっても終了しなかった場合、前記リソース競合解決手段は、前記判定処理を終了し、前記放送受信端末内で実行される第２のプログラムにより確保されているリソースが前記判定ポリシー保持手段にて保持されているリソースに含まれていれば、前記第１のプログラムが前記所定のリソースを確保すべきと判定することを特徴としてもよい。
【００４５】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、リソースごとのリソース競合解決が可能となる。
【００４６】
また、前記予約登録手段は、前記予約情報と共に、前記記録手段による記録処理を実行するために確保すべき前記放送受信端末内の所定のリソースの競合が発生した場合に記録を優先するか前記所定の処理を優先するかを示すフラグを受け取り、前記予約保持手段は、前記フラグを予約情報と関連付けて保持し、前記リソース競合解決手段による判定処理
が、前記予約の開始時刻になっても終了しなかった場合、前記記録手段は、前記リソース競合解決手段による判定処理を終了させ、前記予約情報に対応するフラグに基づいていずれのプログラムが前記所定のリソースを確保すべきかを判定することを特徴としてもよい。
【００４７】
これにより、リソース競合解決手段による判定処理が終了しなかった場合に、予約情報毎に管理されるフラグによってリソース競合解決が可能となる。
【００４８】
なお、本発明は、上記放送受信端末や録画再生装置、放送受信方法、録画再生方法、プログラム、及びそのプログラムを格納する記憶媒体としても実現することができる。
【００４９】
［本願の背景技術に関する詳細情報］
２００５年５月３１日に出願された、明細書と図面と請求項とを含む米国仮出願番号６０／６８５，３８０を本願に引用して援用する。
【発明を実施するための最良の形態】
【００５０】
本発明は、録画等の処理に利用される録画リソースと、前記録画リソースを管理する録画リソース管理手段と、録画予約を保持する録画予約保持手段と、前記録画予約保持手段に前記録画予約を登録する録画予約登録手段と、録画リソースが利用可能かどうか調査し、録画リソースが既に他処理によって利用されていた場合は、プログラムに質問することでどちらの処理に前記録画リソースを利用するか判定処理を行う録画リソース競合解決手段と、前記録画リソース競合解決手段が行う判定処理を、前記録画予約の録画開始時刻にどれくらい先立って行うかを表現する間隔を保持する解決間隔保持手段と、前記解決間隔保持手段に解決間隔を登録する解決間隔登録手段と、前記録画予約に基づいて録画を開始する録画手段と、を備えることで、設定した時間だけ録画開始に先立ちリソースの競合解決を行うことが可能となる。
【００５１】
また、前記録画リソース管理手段は、前記録画リソースを他処理に利用するプログラムの優先度を保持し、前記録画予約保持手段は、録画予約を登録したプログラムの優先度を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、録画リソース解決手段にリソース解決処理の終了を指令し、プログラム優先度を用いた判定として、録画リソースを他処理に利用するプログラムの優先度１と、録画予約を登録したプログラムの優先度２を比較し、前記優先度１が高ければ他処理を継続し、前記優先度２が高ければ、録画処理を開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にプログラムの優先度を用いたリソースの競合解決が可能となる。
【００５２】
また、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画を強制的に開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に強制的に録画を開始することが可能となる。
【００５３】
また更に、リソース配分ポリシーを保持するリソース配分ポリシー保持部と前記リソース配分ポリシーを登録するリソース配分ポリシー登録部とを具備し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、前記リソース配分ポリシーを利用してリソース解決を行って録画を開始するかどうか決定することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、リソース配分ポリシーを用いたリソース競合解決をすることが可能となる。
【００５４】
また、前記リソース配分ポリシー保持手段は、前記リソース配分ポリシーとして録画を優先するか他処理を優先するかを表すフラグを保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、前記フラグが真であれば、録画を開始し、偽であれば他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、フラグによるリソース競合解決が可能となる。
【００５５】
また、前記リソース配分ポリシー保持手段は、前記リソース配分ポリシーとして録画を優先する時間帯を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画開始時刻が時間帯に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、時間帯毎のリソース競合解決が可能となる。
【００５６】
また、前記リソース配分ポリシー保持手段は、前記リソース配分ポリシーとして録画を優先する時間帯を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画時間帯が完全に時間帯に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、時間帯毎のリソース競合解決が可能となる。
【００５７】
また、前記リソース配分ポリシー保持手段は、リソース配分ポリシーとして録画を優先するチャンネル識別子を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画対象チャンネルのチャンネル識別子がチャンネル識別子に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、チャンネル毎のリソース競合解決が可能となる。
【００５８】
また、前記リソース配分ポリシー保持手段は、リソース配分ポリシーとして録画を優先する番組識別子を保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、録画対象番組の番組識別子が番組識別子に含まれていれば録画を開始し、含まれていなければ他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、番組毎のリソース競合解決が可能となる。
【００５９】
また、番組識別子は複数の番組識別子を更に内包することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、番組シリーズ毎のリソース競合解決が可能となる。
【００６０】
また、前記リソース配分ポリシー保持手段は、リソース配分ポリシーとして録画を優先する録画リソースを保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、競合するのが録画リソースであれば録画を開始し、そうでなければ他処理を継続することで、前記録画リソース解決手段による
リソース解決処理が終了しなかった場合に、録画リソース毎のリソース競合解決が可能となる。
【００６１】
また、前記録画予約登録手段は、録画予約と共に、録画リソースの競合が発生した場合に録画を優先するか他処理を優先するかを表現するフラグを受け取り、前記録画予約保持手段は、前記フラグを録画予約と共に保持し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記録画リソース解決手段にリソース解決処理の終了を指令し、当該録画予約と共に記録される前記フラグが真であれば録画を開始し、偽であれば他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、録画予約毎に管理されるフラグによってリソース競合解決が可能となる。
【００６２】
また、時間切れコールバックを保持する時間切れコールバック保持手段と、前記時間切れコールバックを登録する時間切れコールバック登録手段を具備し、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記時間切れコールバックを呼び出すことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合に、コールバックを呼ぶことによるリソース競合解決が可能となる。
【００６３】
また、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記時間切れコールバックを呼び出し、呼び出し結果が真であれば前記間隔保持手段が保持する間隔だけ再度待つことで、前記録画リソース解決手段によるリソース解決処理の待ち時間を延長することが可能となる。
【００６４】
また、前記時間切れコールバックの呼び出し結果が偽であれば、他処理を継続することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によっては他処理を継続させることが可能となる。
【００６５】
また、前記時間切れコールバックの呼び出し結果が偽であれば、録画を開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によっては即座に録画を開始することが可能となる。
【００６６】
また、前記時間切れコールバックの呼び出し結果が偽であれば、前記プログラム優先度を用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によっては優先度を用いたリソース競合解決を選択することが可能となる。
【００６７】
また、前記時間切れコールバックの呼び出し結果が偽であれば、前記リソース解決ポリシーを用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によってはリソース解決ポリシーを用いたリソース競合解決を選択することが可能となる。
【００６８】
また、前記録画リソース解決手段によるリソース解決処理が、当該録画予約の録画開始時刻になっても終了しなかった場合、前記録画手段は、前記時間切れコールバックを呼び出し、呼び出し結果が正の値であれば、結果として得られた正の値が指し示す時間だけ再度待つことで、前記録画リソース解決手段によるリソース解決処理の待ち時間を延長することが可能となる。
【００６９】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、他処理を優先する
ことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によって他処理を優先することが可能となる。
【００７０】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、録画を開始することで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によって録画開始を優先することが可能となる。
【００７１】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、前記プログラム優先度を用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によってプログラム優先度による判定を選択可能となる。
【００７２】
また、前記時間切れコールバックの呼び出し結果が０以下であれば、前記リソース配分ポリシーを用いた判定を行うことで、前記録画リソース解決手段によるリソース解決処理が終了しなかった場合にコールバックを呼び、その値によってリソース配分ポリシーによる判定を選択することが可能となる。
【００７３】
（実施の形態１）
以下に、本発明の第１の実施形態に係る装置および方法を、図面を参照しながら説明する。本発明は、任意の媒体で送受信されるコンテンツの録画および再生を対象としたものであるが、本実施例ではケーブルテレビ放送システムでの実施の形態を例にとって説明する。ケーブルテレビ放送システムでは、本発明の放送録画再生装置（放送受信端末）は一般的に端末装置と呼ばれる。
【００７４】
図１は、放送システムを構成する装置の関係を表したブロック図であり、放送局側システム１０１および三個の端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３で構成される。放送局側システムと各端末装置間の結合１２１は、ケーブルシステムでは同軸ケーブルや光ファイバでの有線結合である。図１では、１つの放送局側システムに対して三つの端末装置が結合されているが、端末装置の数は任意である。
【００７５】
放送局側システム１０１は、複数の端末装置に対して映像・音声・データ放送用データ等の情報を放送信号に含めて送信する。放送信号は放送システムの運用既定や、放送システムが運用される国・地域の法律により定められた周波数帯域内の周波数を利用して伝送される。
【００７６】
本実施例のケーブルシステムでは、放送信号伝送に利用する周波数帯域は、そのデータの内容と伝送方向（上り、下り）ごとに分割して割り当てる。図２は、周波数帯域の分割の一例を示す表である。周波数帯域は、Ｏｕｔ  Ｏｆ  Ｂａｎｄ（略称ＯＯＢ）とＩｎ−Ｂａｎｄの２種類に大別される。５〜１３０ＭＨｚがＯＯＢに割り当てられ、主に放送局側システム１０１と端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３間の上下双方向データのやり取りに使用される。１３０ＭＨｚ〜８６４ＭＨｚはＩｎ−Ｂａｎｄに割り当てられ、主として、映像・音声を含む下りのみの放送チャンネルに使用される。ＯＯＢではＱＰＳＫ変調方式が、Ｉｎ−ＢａｎｄはＱＡＭ６４またはＱＡＭ２５６変調方式が使用される。変調方式技術については、本発明に関与が薄い公知技術であるので、詳細な説明は省略する。
【００７７】
図３は、ＯＯＢ周波数帯域のさらに詳細な使用の一例である。７０ＭＨｚ〜７４ＭＨｚは放送局側システム１０１からの下りデータ送信に使用され、すべての端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３が、放送局側システム１０１から等しいデータを受け取ることになる。一方、１０．０ＭＨｚ〜１０．１ＭＨｚは端末装置Ａ１１１から放
送局側システム１０１への上りデータ送信に使用され、１０．１ＭＨｚ〜１０．２ＭＨｚは端末装置Ｂ１１２から放送局側システム１０１への上りデータ送信に使用され、１０．２ＭＨｚ〜１０．３ＭＨｚは端末装置Ｃ１１３から放送局側システム１０１への上りデータ送信に使用される。これにより、各端末装置固有のデータを各端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３から放送局側システム１０１に独立して送信することができる。図４は、Ｉｎ−Ｂａｎｄの周波数帯に対する使用の一例である。１５０〜１５６ＭＨｚと１５６〜１６２ＭＨｚはそれぞれテレビチャンネル１とテレビチャンネル２に割り当てられ、以降、６ＭＨｚ間隔でテレビチャンネルが割り当てられている。３１０ＭＨｚ以降は、１ＭＨｚ単位でラジオチャンネルに割り当てられている。これらの各チャンネルはアナログ放送として使用してもデジタル放送として使用してもよい。デジタル放送の場合は、ＭＰＥＧ２仕様にもとづいたＴＳパケット形式で伝送され、音声や映像に加え、各種データ放送用データやＥＰＧを構成するための番組編成情報も送信することができる。
【００７８】
放送局側システム１０１は、以上に説明した周波数帯域を利用して端末装置に適切な放送信号を送信するため、ＱＰＳＫ変調部やＱＡＭ変調部等をもつ。また、端末装置からのデータを受信するため、ＱＰＳＫ復調器をもつ。また、放送局側システム１０１は、これら変調部および復調部に関連する様々な機器をもつと考えられる。しかし、本発明は主として端末装置に関わるので、詳細な説明は省略する。
【００７９】
一方、端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３は、放送局側システム１０１からの放送信号を受信し再生するために、ＱＡＭ復調部やＱＰＳＫ復調部を持つ。また、放送局側システム１０１に対して、各端末装置固有のデータを送信するためにＱＰＳＫ変調部を持つ。本発明では、端末装置は放送録画再生装置であり、その詳細な構成は後述する。
【００８０】
放送局側システム１０１は、ＭＰＥＧ２トランスポートストリームを変調して放送信号に含めて伝送する。端末装置は放送信号を受信し、復調してＭＰＥＧ２トランスポートストリームを再現し、その中から必要な情報を抽出して用いる。端末装置に存在するデバイスの機能と接続の構成を説明するため、まずＭＰＥＧ２トランスポートストリームの構成を簡単に述べる。
【００８１】
図５はＴＳパケットの構成を表す図である。ＴＳパケット５００は１８８バイトの長さを持ち、ヘッダ５０１、アダプテーションフィールド５０２、ペイロード５０３からなる。ヘッダ５０１はＴＳパケットの制御情報を保持する。４バイトの長さを持ち、５０４で表される構成をとる。この中に“Ｐａｃｋｅｔ  ＩＤ（以下ＰＩＤ）”と記述されるフィールドを持ち、このＰＩＤの値によって、ＴＳパケットの識別を行う。アダプテーションフィールド５０２は時刻情報等の付加的な情報を保持する。アダプテーションフィールド５０２の存在は必須ではなく、存在しない場合もある。ペイロード５０３は映像・音声やデータ放送用データ等、ＴＳパケットが伝送する情報を保持する。
【００８２】
図６はＭＰＥＧ２トランスポートストリームの模式図である。ＴＳパケットはそのペイロードに映像や音声、データ放送用のデータ等様々な情報を保持する。ＴＳパケット６０１およびＴＳパケット６０３はヘッダにＰＩＤ１００を保持し、ペイロードに映像１に関する情報を保持する。ＴＳパケット６０２およびＴＳパケット６０５はヘッダにＰＩＤ２００を保持し、ペイロードにデータ１に関する情報を保持する。ＴＳパケット６０４はヘッダにＰＩＤ３００を保持し、ペイロードに音声１に関する情報を保持する。このように様々な種類のデータをペイロードに保持したＴＳパケットを混合して一連のシーケンスとして送出することを多重と呼ぶ。ＭＰＥＧ２トランスポートストリーム６００はＴＳパケット６０１〜６０５多重した構成の一例である。
【００８３】
同一ＰＩＤをもつＴＳパケットは同一種類の情報を保持する。そのため、端末装置は多重されたＴＳパケットを受信して、各ＴＳパケットが保持する情報をＰＩＤごとに抽出することで、映像・音声を再現したり、番組編成情報等のデータを再現したりできる。図６においては、ＴＳパケット６０１およびＴＳパケット６０３は共に映像１に関する情報を伝送し、またＴＳパケット６０２およびＴＳパケット６０５は共にデータ１に関する情報を伝送する。
【００８４】
ここで、ペイロードに内包される各種データの形式について説明する。
映像および音声は、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）パケットと呼ばれる形式で表現される。ＰＥＳパケットはある時間帯の映像情報または音声情報を含み、放送録画再生装置は、ＰＥＳパケットを受信することで、そのＰＥＳパケットが内包する映像・音声情報を画面・スピーカに出力することができる。放送局がＰＥＳパケットを途切れなく伝送することで、放送録画再生装置は、映像・音声を途切れなく再生し続けることが可能となる。ＰＥＳパケットは、実際に伝送される際、一つのＴＳパケットのペイロードよりも大きいサイズをもつ場合は分割されて複数のＴＳパケットのペイロードに格納される。図７はＰＥＳパケットを伝送する際の分割例を表す。ＰＥＳパケット７０１は一つのＴＳパケット内のペイロードに格納して伝送するには大きいため、ＰＥＳパケット分割Ａ７０２ａ、ＰＥＳパケット分割Ｂ７０２ｂ、ＰＥＳパケット分割Ｃ７０２ｃに分割され、同一ＰＩＤをもつ三つのＴＳパケット７０３〜７０５によって伝送される。実際には、映像や音声は、複数のＰＥＳパケットのペイロードに含まれるデータを結合して得られるエレメンタリストリーム（ＥＳ）として得られる。このエレメンタリストリームは、ＭＰＥＧ２ Ｖｉｄｅｏ規格やＭＰＥＧ１，２ Ａｕｄｉｏ規格で定義されるデジタル化映像、音声の形式になっている。
【００８５】
一方、番組編成情報やデータ放送用のデータ等の情報はＭＰＥＧ２セクションと呼ばれる形式を用いて表現される。ＭＰＥＧ２セクションは実際に伝送される際、一つのＴＳパケットのペイロードよりも大きいサイズをもつ場合は分割されて複数のＴＳパケットのペイロードに格納される。図８はＭＰＥＧ２セクションを伝送する際の分割例を表す。ＭＰＥＧ２セクション８０１は一つのＴＳパケット内のペイロードに格納して伝送するには大きいため、セクション分割Ａ８０２ａ、セクション分割Ｂ８０２ｂ、セクション分割Ｃ８０２ｃに分割され、同一ＰＩＤをもつ三つのＴＳパケット８０３〜８０５によって伝送される。
【００８６】
図９はＭＰＥＧ２セクションの構造を表現する。ＭＰＥＧ２セクション９００はヘッダ９０１およびペイロード９０２から構成される。ヘッダ９０１はＭＰＥＧ２セクションの制御情報を保持する。その構成はヘッダ構成９０３によって表現される。ペイロード９０２はＭＰＥＧ２セクション９００が伝送するデータを保持する。ヘッダ構成９０３に存在するｔａｂｌｅ＿ｉｄはＭＰＥＧ２セクションの種類を表現し、さらにｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎはｔａｂｌｅ＿ｉｄが等しいＭＰＥＧ２セクション同士を区別する際に用いられる拡張識別子である。ＭＰＥＧ２セクションの使用例として、図１０に番組編成情報を伝送する場合を挙げる。この例では、行１００４に記載されるように、放送信号の復調に必要な情報はヘッダ構成９０３内のｔａｂｌｅ＿ｉｄが６４であるＭＰＥＧ２セクションに記載され、さらにそのＭＰＥＧ２セクションはＰＩＤに１６が付与されたＴＳパケットによって伝送される。
【００８７】
ＭＰＥＧ２セクションの場合、ＰＥＳ形式は存在しない。そのため、ＭＰＥＧ２トランスポートストリームの中の同一ＰＩＤによって識別されるＴＳパケットのペイロードを結合したものをエレメンタリーストリーム（ＥＳ）とする。例えば、図８において、ＭＰＥＧ２セクション８０１を分割して伝送しているＴＳパケット８０３〜８０５はすべてＰＩ
Ｄが２００で識別される。これはＭＰＥＧ２セクション８０１を伝送するＥＳである、と言うことができる。
【００８８】
ＭＰＥＧ２トランスポートストリーム内にはさらにプログラムという概念が存在する。プログラムはＥＳの集合として表現され、複数のＥＳをまとめて扱いたい場合に利用される。プログラムを利用すると、映像・音声や、それに付随するデータ放送用データ等を一まとめに扱うことが可能となる。例えば、同時に再生したい映像・音声をまとめて扱う場合、映像ＥＳと、音声ＥＳをプログラムとしてまとめることで、放送録画再生装置はこれら二つのＥＳを１つの番組として同時に再生すべきであることがわかる。
【００８９】
プログラムを表現するために、ＭＰＥＧ２ではＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）およびＰＡＴ（Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅ）と呼ばれる二つのテーブルが利用される。詳細な説明はＩＳＯ／ＩＥＣ１３８１８−１、“ＭＰＥＧ２  Ｓｙｓｔｅｍｓ”仕様を参照されたい。以下ではＰＭＴおよびＰＡＴに関して簡単に説明する。
【００９０】
ＰＭＴはＭＰＥＧ２トランスポートストリーム中に、プログラムの数だけ含まれるテーブルである。ＰＭＴはＭＰＥＧ２セクションとして構成され、ｔａｂｌｅ＿ｉｄは２である。ＰＭＴにはプログラムの識別に用いられるプログラムナンバーとプログラムの付加情報、さらにプログラムに属するＥＳに関する情報を保持する。ＰＭＴの例を図１１に挙げる。１１００はプログラムナンバーである。プログラムナンバーは同一トランスポートストリーム内でプログラムに一意に割り当てられ、ＰＭＴの識別に用いられる。行１１１１〜１１１５は個々のＥＳに関する情報を表現する。列１１０１はＥＳのタイプであり、“映像”、“音声”、“データ”等が指定される。列１１０２はＥＳを構成するＴＳパケットのＰＩＤである。列１１０３はＥＳに関する付加情報である。例えば、行１１１１に表されるＥＳは、音声ＥＳであり、ＰＩＤが５０１１であるＴＳパケットによって伝送される。
【００９１】
ＰＡＴはＭＰＥＧ２トランスポートストリームに一つだけ存在するテーブルである。ＰＡＴはＭＰＥＧ２セクションとして構成され、ｔａｂｌｅ＿ｉｄは０であり、ＰＩＤが０であるＴＳパケットによって伝送される。ＰＡＴには、ＭＰＥＧ２トランスポートストリームの識別に用いられるｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄと、ＭＰＥＧ２トランスポートストリーム内に存在するプログラムを表現するすべてのＰＭＴに関する情報を保持する。ＰＡＴの例を図１２に挙げる。１２００はｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄである。ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄはＭＰＥＧ２トランスポートストリームの識別に用いられる。行１２１１〜１２１３はプログラムに関する情報を表現する。列１２０１はプログラムナンバーである。列１２０２はプログラムに対応するＰＭＴを伝送するＴＳパケットのＰＩＤである。例えば、行１２１１に表されるプログラムのＰＭＴは、プログラムナンバーが１０１であり、対応するＰＭＴはＰＩＤが５０１であるＴＳパケットによって伝送される。
【００９２】
端末装置があるプログラムを再生する場合は、ＰＡＴおよびＰＭＴを用いてプログラムを構成する映像・音声を特定し、それらを再生する。例えば、図１２のＰＡＴおよび図１１のＰＭＴを伝送するＭＰＥＧ２トランスポートストリームに関して、プログラムナンバーが１０１であるプログラムに属する映像・音声の再生を行う場合は以下のような手順をとる。まずＰＩＤが“０”であるＴＳパケットより、ｔａｂｌｅ＿ｉｄが“０”のＭＰＥＧ２セクションとして伝送されるＰＡＴを取得する。ＰＡＴよりプログラムナンバーが“１０１”であるプログラムを探索し、行１２１１を得る。行１２１１より、プログラムナンバーが“１０１”であるプログラムのＰＭＴを伝送するＴＳパケットのＰＩＤ“５０１”を得る。次いでＰＩＤが“５０１”であるＴＳパケットより、ｔａｂｌｅ＿ｉｄが“２
”のＭＰＥＧ２セクションとして伝送されるＰＭＴを取得する。ＰＭＴより、音声のＥＳ情報である行１１１１および映像のＥＳ情報である行１１１２を得る。行１１１１より、音声ＥＳを伝送するＴＳパケットのＰＩＤ“５０１１”を得る。また行１１１２より、映像ＥＳを伝送するＴＳパケットのＰＩＤ“５０１２”を得る。次いでＰＩＤ“５０１１”のＴＳパケットより音声用ＰＥＳパケットを、ＰＩＤ“５０１２”のＴＳパケットより映像用ＰＥＳパケットを取得する。これにより、再生対象となる映像・音声のＥＳパケットを取得することが可能となり、プログラムナンバー１０１を構成する映像と音声を再生することができる。
【００９３】
なお、ＭＰＥＧ２トランスポートストリームは暗号化されている場合がある。これは限定視聴とも呼ばれる仕組みである。例えば、ある映像・音声情報を伝送するＰＥＳパケットに対して暗号化処理を行うことで、その暗号を解読できる特定視聴者のみが視聴できるようになる。暗号を解読して映像や音声を視聴するために、視聴者はデスクランブラと呼ばれるデバイスを用いて暗号解除を行う。例えば、ＯＣＡＰ対応の端末装置は、デスクランブラを内蔵したカード型のアダプタを利用する。ケーブルテレビのオペレータは、視聴者ごとに特定のプログラムを解読できるように設定したアダプタを配布し、視聴者はそのアダプタを端末装置に挿入する。すると、アダプタは、暗号解除鍵等の暗号解除情報や各契約者の契約情報を元に、特定のプログラムに関して暗号を解除する。暗号解除の方式や、暗号解除鍵の入手方法はアダプタ依存であり、本発明の実現には影響しない。
【００９４】
ここまでＭＰＥＧ２仕様に関する簡単な説明を行ったが、ここで、単語の詳細な定義を行う。本発明に関して、「プログラム」という単語が二種類存在する。一つはＭＰＥＧ２仕様に登場する「プログラム」であり、もう一つはＣＰＵが実行するコードの集合という意味での「プログラム」である。前者に関しては、運用規定で用いられる「サービス」という単語と同義であるため、混乱を避けるため、以降、前者を「サービス」と呼び、後者を単に「プログラム」とよぶ。さらに後者に関して、特にＪａｖａ言語で記述された「プログラム」を「Ｊａｖａプログラム」とよぶ。
【００９５】
以上、本発明に関わる、ＭＰＥＧ２仕様にて決定されるいくつかの一般的な情報に関して説明を行った。以降、本実施の形態で用いる放送録画再生端末に関して詳細に説明する。
【００９６】
図１３Ａは、本実施例の放送録画再生装置の一般的なハードウェア構成を表すブロック図であり、すなわち図１における端末装置１１１，１１２，１１３の具体的な内部構成である。１３００は放送録画再生装置であり、Ｉｎ−ｂａｎｄ受信用チューナ１３０１、ＴＳデコーダ（ＴＳ  Ｄｅｍｕｌｔｉｐｌｅｘｅｒ）１３０２、ＡＶデコーダ１３０３、スピーカ１３０４、ディスプレイ１３０５、ＣＰＵ１３０６、２次記憶部１３０７、１次記憶部１３０８、ＲＯＭ１３０９、入力部１３１０、アダプタ１３１１、ＡＶエンコーダ１３１４、多重器（ＭＰＥＧ２  Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ  Ｍｕｌｔｉｐｌｅｘｅｒ等）１３１５で構成される。なお本実施例は、ＯＣＡＰ−ＤＶＲ仕様で実現される放送録画再生端末を拡張して得られるものであり、基本的なハードウェア構成はＯＣＡＰ−ＤＶＲ仕様で要求されるものとほぼ同じである。
【００９７】
チューナ１３０１は、ＣＰＵ１３０６が指定する周波数などのチューニング情報に従って、放送局側システム１０１から伝送される変調された放送信号を復調するデバイスである。チューナ１３０１が復調した結果得られるＭＰＥＧ２トランスポートストリームは、暗号解除機能をもつアダプタ１３１１を経て、ＴＳデコーダ１３０２に送信される。
【００９８】
ＴＳデコーダ１３０２は、ＣＰＵ１３０６が指定するＰＩＤ、セクションフィルタ条件等の指定にもとづいてＭＰＥＧ２トランスポートストリームから指定条件に合致するＰＥ
ＳパケットやＭＰＥＧ２セクションを選別する機能をもつデバイスである。放送を受信してサービスを録画せずに再生する場合は、アダプタ１３１１が出力するＭＰＥＧ２トランスポートストリームがＴＳデコーダ１３０２に入力される。一方、２次記憶部１３０７に録画されているサービスを再生する場合は、２次記憶部１３０７が出力するＭＰＥＧ２トランスポートストリームがＴＳデコーダ１３０２に入力される。いずれの入力を受けるかは、ＣＰＵ１３０６によって制御される。
【００９９】
ＴＳデコーダ１３０２が選別した映像及び音声のＰＥＳパケットは、ＡＶデコーダ１３０３に出力される。また、ＴＳデコーダ１３０２が選別したＭＰＥＧ２セクションは、１次記憶部１３０８にＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）転送され、ＣＰＵ１３０６が実行するプログラムによって利用される。
【０１００】
ＡＶデコーダ１３０３はエンコードされた映像ＥＳおよび音声ＥＳをデコードする機能をもつデバイスである。ＡＶデコーダはＴＳデコーダから転送される音声および映像情報を伝送するＰＥＳパケットからＥＳを取り出してデコードする。ＡＶデコーダ１３０３がデコードして得られたａｕｄｉｏ信号およびｖｉｄｅｏ信号は、サービスの再生時にはスピーカ１３０４、ディスプレイ１３０５に出力されるが、一方、サービスの録画時にはＡＶエンコーダ１３１４へ出力される。いずれの出力経路を取るかは、ユーザの指示に従ってＣＰＵ１３０６によって制御される。
【０１０１】
スピーカ１３０４は、ＡＶデコーダ１３０３から出力された音声を再生する。
【０１０２】
ディスプレイ１３０５は、ＡＶデコーダ１３０３から出力された映像を再生する。
【０１０３】
ＣＰＵ１３０６は放送録画再生装置上で動作するプログラムを実行する。ＣＰＵ１３０６は、ＲＯＭ１３０９に内蔵されるプログラムを実行する。あるいは、放送信号やネットワークよりダウンロードされ１次記憶部１３０８に保持されているプログラムも実行する。あるいは、放送信号やネットワークよりダウンロードされ２次記憶部１３０７に保存されているプログラムも実行する。そして実行するプログラムの指示に従い、チューナ１３０１、ＴＳデコーダ１３０２、ＡＶデコーダ１３０３、スピーカ１３０４、ディスプレイ１３０５、２次記憶部１３０７、１次記憶部１３０８、ＲＯＭ１３０９、入力部１３１０、アダプタ１３１１、ＡＶエンコーダ１３１４、多重器１３１５を制御する。また、ＣＰＵ１３０６は端末装置１３００内に存在するデバイスだけでなく、アダプタ１３１１内のデバイスと通信し、アダプタ１３１１を制御することが可能である。
【０１０４】
２次記憶部１３０７は機器の電源が遮断されても記憶が消去されない記憶装置である。例えばＦＬＡＳＨ−ＲＯＭ等の不揮発性メモリ、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＣＤ−ＲやＤＶＤ−Ｒ等の書き換え可能のメディア等、端末装置１３００の電源断の際にも情報が消去されない機器によって構成され、ＣＰＵ１３０６の指示により情報の保存を行う。
【０１０５】
１次記憶部１３０８は、ＣＰＵ１３０６やＤＭＡ転送可能なデバイスの指示に従って情報を一時的に保存する機能をもつデバイスであり、ＲＡＭ等によって構成される。
【０１０６】
ＲＯＭ１３０９は、書き換え不可能なメモリーデバイスであり、具体的にはＲＯＭやＣＤ−ＲＯＭ、ＤＶＤ等で構成される。ＲＯＭ１３０９には、ＣＰＵ１３０６が実行するプログラムが格納されている。
【０１０７】
入力部１３１０は、具体的には、フロントパネルやリモコン受信機で構成され、ユーザからの入力を受け付ける。図１３Ｂは、フロントパネルで入力部１３１０を構成した場合
の一例である。フロントパネル１４００ｘは七つのボタン、上カーソルボタン１４０１ｘ、下カーソルボタン１４０２ｘ、左カーソルボタン１４０３ｘ、右カーソルボタン１４０４ｘ、ＯＫボタン１４０５ｘ、取消ボタン１４０６ｘ、ＥＰＧボタン１４０７ｘ、モード切換ボタン１４０８ｘを備えている。ユーザがボタンを押下すると、押下されたボタンの識別子が、ＣＰＵ１３０６に通知される。
【０１０８】
アダプタ１３１１は、Ｉｎ−ｂａｎｄ周波数帯で伝送されるＭＰＥＧ２トランスポートストリームにかけられた暗号を解除する装置で、１つ以上のデスクランブラを搭載する。アダプタ１３１１にはチューナ１３０１が出力するＭＰＥＧ２トランスポートストリームが入力され、ＣＰＵ１３０６が指定したＰＩＤをもつＴＳパケットに対して暗号解除を行う。アダプタ１３１１は、暗号を解除したＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に出力する。
【０１０９】
さらに、アダプタ１３１１は、ＯＯＢ周波数帯で伝送されるデータの形式変換も行う。ＯＯＢで伝送される情報はＱＰＳＫ変調方式で変調される。下り方向の伝送に関しては、ＱＰＳＫ復調器１３１２は放送局側システム１０１から送信されてくる下りの信号を復調し、生成されたビットストリームをアダプタ１３１１に入力する。アダプタ１３１１はビットストリームが含む様々な情報の中から、ＣＰＵ１３０６が指定する情報を抽出して、ＣＰＵ１３０６上で動作するプログラムが解釈可能な形式に変換して、ＣＰＵ１３０６に提供する。一方、上り方向の伝送に関しては、ＣＰＵ１３０６が、放送局側システム１０１に対して送信したい情報を、アダプタ１３１１に入力する。アダプタ１３１１は、ＣＰＵ１３０６から入力された情報を放送局側システム１０１が解釈可能な形式に変換し、ＱＰＳＫ変調器１３１３に入力する。ＱＰＳＫ変調器１３１３はアダプタ１３１１から入力された情報をＱＰＳＫ変調し、放送局側システム１０１に送信する。
【０１１０】
アダプタ１３１１の具体例としては、米国ケーブルシステムで利用されるＣａｂｌｅＣＡＲＤ、旧名ＰＯＤ（Ｐｏｉｎｔ  Ｏｆ  Ｄｅｐｌｏｙｍｅｎｔ）が挙げられる。
【０１１１】
ＡＶエンコーダ１３１４は、ＡＶデコーダ１３０３によってデコードされたａｕｄｉｏ信号をＭＰＥＧ  ａｕｄｉｏ形式の音声にエンコードし、ｖｉｄｅｏ信号をＭＰＥＧ  ｖｉｄｅｏ形式の映像にエンコードする。ＡＶエンコーダ１３１４がエンコードた映像および音声は、多重器１３１５へ出力される。
【０１１２】
多重器１３１５は、ＡＶエンコーダ１３１４から入力された映像および音声を、ＭＰＥＧ２トランスポートストリームへ多重化する機能をもつデバイスである。
【０１１３】
以上説明した放送録画再生装置が、放送波に含まれるサービスを２次記憶部１３０７に記録する動作と、２次記憶部１３０７から逐次読み出してサービスを再生する動作について、以下に詳細に説明する。
【０１１４】
まず、放送波に含まれるサービスを２次記憶部１３０７に記録する動作について述べる。
【０１１５】
図１４に、サービスの記録時における、各デバイスの物理的な接続順序と処理内容、入出力のデータ形式を表現する概念図を示す。１４００は端末装置であり、チューナ１３０１、アダプタ１３１１、デスクランブラ１４０１、ＴＳデコーダ１３０２、ＰＩＤフィルタ１４０２、セクションフィルタ１４０３、ＡＶデコーダ１３０３、１次記憶部１３０８、ＡＶエンコーダ１３１４、多重器１３１５、および、記録領域１４０４をもつ。図１４の構成要素のうち、図１３Ａの構成要素と同一符号を持つものは、それらと同等の機能をもつため、説明を省略する。
【０１１６】
まずＣＰＵ１３０６が指定したチューニング指示に従って、チューナ１３０１が放送波をチューニングする。チューナ１３０１は、放送波を復調し、アダプタ１３１１にＭＰＥＧ２トランスポートストリームを入力する。
【０１１７】
アダプタ１３１１内にあるデスクランブラ１４０１は、視聴者ごとの限定解除情報に基づいて、ＭＰＥＧ２トランスポートストリームの暗号解除を行う。暗号解除されたＭＰＥＧ２トランスポートストリームは、ＴＳデコーダに入力される。
【０１１８】
ＴＳデコーダ１３０２内にはＭＰＥＧ２トランスポートストリームに対して処理を行う２種類のデバイス、ＰＩＤフィルタ１４０２、セクションフィルタ１４０３が存在する。
【０１１９】
ＰＩＤフィルタ１４０２は、入力されたＭＰＥＧ２トランスポートストリームから、ＣＰＵ１３０６が指定したＰＩＤをもつＴＳパケットを抽出し、さらにそのペイロードに存在するＰＥＳパケットやＭＰＥＧ２セクションを抽出する。例えば、ＣＰＵ１３０６がＰＩＤ＝１００のＴＳパケットを抽出するＰＩＤフィルタリングを指示した場に図６のＭＰＥＧ２トランスポートストリームが入力されたとすると、パケット６０１及び６０３が抽出されて更に連結され、映像１のＰＥＳパケットが再構成される。あるいは、ＣＰＵ１３０６がＰＩＤ＝２００のＴＳパケットを抽出するＰＩＤフィルタリングを指示した場に図６のＭＰＥＧ２トランスポートストリームが入力されたとすると、パケット６０２及び６０５が抽出されて更に連結され、データ１のＭＰＥＧセクションが再構成される。
【０１２０】
セクションフィルタ１４０３は、入力されたＭＰＥＧ２セクションの中から、ＣＰＵ１３０６が指定するセクションフィルタ条件に合致するＭＰＥＧ２セクションを抽出し、１次記憶部１３０８にＤＭＡ転送する。例えば、ＣＰＵ１３０６はＰＩＤ＝２００のＴＳパケットを抽出するＰＩＤフィルタリングとｔａｂｌｅ＿ｉｄが６４であるセクションを抽出するセクションフィルタリングをセクションフィルタ１４０３に対して指定したとする。先に述べたように、データ１のＭＰＥＧ２セクションが再構成された後、セクションフィルタ１４０３はそのＭＰＥＧ２セクションの中からｔａｂｌｅ＿ｉｄが６４であるセクションのみを抽出し、１次記憶部１３０８にＤＭＡ転送する。
【０１２１】
１次記憶部１３０８に入力されたＭＰＥＧ２セクションは、多重器１３１５に入力される。
【０１２２】
ＴＳデコーダ１３０２によって抽出された映像ＰＥＳパケットと音声ＰＥＳパケットは、ＡＶデコーダ１３０３に入力される。
【０１２３】
ＡＶデコーダは、映像ＰＥＳパケットをデコードして映像に変換し、ＡＶエンコーダ１３１４に入力する。また音声ＰＥＳパケットをデコードして音声に変換し、ＡＶエンコーダ１３１４に入力する。
【０１２４】
ＡＶエンコーダ１３１４は、映像をＭＰＥＧ  ｖｉｄｅｏに変換し、多重器１３１５に入力する。また音声をＭＰＥＧ  ａｕｄｉｏに変換し、多重器１３１５に入力する。
【０１２５】
多重器１３１５は、ＡＶエンコーダから入力されたＭＰＥＧ  ｖｉｄｅｏとＭＰＥＧ  ａｕｄｉｏと、１次記憶部１３０８から入力されたＭＰＥＧ２セクションを多重してＭＰＥＧ２トランスポートストリームを生成する。生成されたＭＰＥＧトランスポートストリームは、記録領域１４０４に記録される。
【０１２６】
記録領域１４０４は２次記憶部１３０７の全体または一部、あるいは、その他の記録領
域で構成され、サービスを構成するＭＰＥＧ２トランスポートストリームを記憶する。
【０１２７】
次いで、２次記憶部１３０７から逐次読み出してサービスを再生する動作について述べる。
【０１２８】
図１５に、サービスの再生時における、各デバイスの物理的な接続順序と処理内容、入出力のデータ形式を表現する概念図を示す。１５００は端末装置であり、記録領域１４０４、ＴＳデコーダ１３０２、ＰＩＤフィルタ１４０２、セクションフィルタ１４０３、ＡＶデコーダ１３０３、スピーカ１３０４、ディスプレイ１３０５、および、１次記憶部１３０８をもつ。図１５の構成要素のうち、図１３Ａの構成要素と同一符号を持つものは、それらと同等の機能をもつため、説明を省略する。
【０１２９】
図１４で説明した手順で記録領域１４０４に記録されたＭＰＥＧ２トランスポートストリームが、ＴＳデコーダ１３０２に入力される。
【０１３０】
次いで、ＴＳデコーダ１３０２内のＰＩＤフィルタ１４０２によって、ＣＰＵ１３０６が指定したＰＩＤを持つ映像ＰＥＳ及び音声ＰＥＳが抽出される。抽出されたＰＥＳパケットはＡＶデコーダ１３０３に入力される。あるいは、ＴＳデコーダ１３０２内のＰＩＤフィルタ１４０２とセクションフィルタ１４０３によって、ＣＰＵ１３０６が指定したＰＩＤとｔａｂｌｅ＿ｉｄを持つＭＰＥＧ２セクションが抽出される。抽出されたＭＰＥＧ２セクションは１次記憶部１３０８にＤＭＡ転送される。
【０１３１】
ＡＶデコーダ１３０３に入力された映像ＰＥＳと音声ＰＥＳは、デコードされてａｕｄｉｏ信号およびｖｉｄｅｏ信号が出力される。その後、ａｕｄｉｏ信号およびｖｉｄｅｏ信号はディスプレイ１３０５およびスピーカ１３０４に入力され、映像および音声が再生される。
【０１３２】
１次記憶部１３０８に入力されたＭＰＥＧ２セクションは、適宜ＣＰＵ１３０６に入力される。
【０１３３】
ここまでは、本発明に関するハードウェアの構成例に関して述べたが、以降、本発明の前提となる、Ｊａｖａプログラムによるサービスの記録制御に関して説明する。
【０１３４】
本発明におけるサービスの記録とは、サービスに含まれる映像、音声、Ｊａｖａプログラム、Ｊａｖａプログラムの同期情報等をハードディスク、ＢＤ（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）、ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリカードといった記録媒体に記録することである。サービスの再生とは、記録媒体に記録された映像、音声、Ｊａｖａプログラムを同期情報に基づいて再生および実行することである。記録済みサービスの再生結果は、放送波を受信して直接サービスを再生した結果とほぼ等価であることが要求される。
【０１３５】
図１６は、サービスの記録と再生に必要とされるプログラムの構成図であり、ＲＯＭ１３０９に記憶されているソフトウエアである。
【０１３６】
プログラム１６００は、サブプログラムであるＯＳ１６０１、ＥＰＧ１６０２、ＪａｖａＶＭ１６０３、サービスマネージャ１６０４、Ｊａｖａライブラリ１６０５、レコーディングマネージャ１６０６で構成される。
【０１３７】
ＯＳ１６０１は、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）であり、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ等が一例である。ＯＳ１６０１は、他のサブプログラ
ム、例えばＥＰＧ１６０２とＪａｖａＶＭ１６０３を実行するためのカーネル１６０１ａと、サブプログラムが端末装置１３００の構成要素を制御するために利用するライブラリ１６０１ｂで構成される。カーネル１６０１ａは公知技術であり、詳細な説明は省略する。
【０１３８】
ライブラリ１６０１ｂは、例えばチューナを制御するチューニング機能を提供する。ライブラリ１６０１ｂは、他のサブプログラムから周波数を含むチューニング情報を受け取り、それをチューナ１３０１に引き渡す。チューナ１３０１は与えられたチューニング情報にもとづき復調処理を行い、復調したＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に引き渡すことができる。この結果、他のサブプログラムはライブラリ１６０１ｂを通してチューナ１３０１を制御することができる。
【０１３９】
また、ライブラリ１６０１ｂは、チャンネルを一意に識別するためのチャンネル情報を提供する。チャンネル情報の一例を図１９に示す。チャンネル情報はＯＯＢあるいはＩｎ−ｂａｎｄ周波数帯を利用して送信され、アダプタ１３１１で表形式に変換され、ライブラリがアクセス可能な一時記憶部に格納される。列１９０１は、チャンネル識別子で、例えば、ＳＣＴＥ  ６５  Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｄｅｌｉｖｅｒｅｄ
Ｏｕｔ−Ｏｆ−Ｂａｎｄ  Ｆｏｒ Ｄｉｇｉｔａｌ Ｃａｂｌｅ  Ｔｅｌｅｖｉｓｉｏｎで定義されるｓｏｕｒｃｅ＿ＩＤが相当する。列１９０２は、チャンネル名であり、同ＳＣＴＥ  ６５規格ではｓｏｕｒｃｅ＿ｎａｍｅなどに相当する。列１９０３はチューニング情報であり、周波数や転送レート、変調方式といったチューナ１３０１に与える情報である。列１９０４はＰＭＴを指定するためのプログラムナンバーである。例えば、行１９１１はチャンネル識別子が「１」、チャンネル名が「チャンネル１」、チューニング情報に周波数「１５０ＭＨｚ」、プログラムナンバーが「１０１」であるサービス情報の組となっている。
【０１４０】
ＪａｖａＶＭ１６０３は、Ｊａｖａ（登録商標）言語で記述された１以上のプログラムを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウェアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。ＪａｖａＶＭ１６０３は、Ｊａｖａ言語で記述されたＪａｖａライブラリ１６０５を実行する。Ｊａｖａ言語やＪａｖａＶＭの詳細は、書籍「Ｊａｖａ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−１）」や「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１―Ｘ）」等を参照のこと。また、ＪＮＩ（Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。ＪＮＩに関しては、書籍「Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ」等を参照のこと。また、マルチスレッド管理により、複数のプログラムを並列的に動作させることが可能である。
【０１４１】
Ｊａｖａライブラリ１６０５は、Ｊａｖａプログラムが放送録画再生装置の機能を制御するために呼び出すＪａｖａ言語で記述されたライブラリである。ただし、必要に応じて、ＯＳ１６０１のライブラリ１６０１ｂなど非Ｊａｖａ言語で記述されたサブプログラムを利用することもある。Ｊａｖａプログラムは、Ｊａｖａライブラリ１６０５が持つＪａｖａ  ＡＰＩ（アプリケーションプログラミングインタフェース）を呼び出すことで、Ｊａｖａライブラリ１６０５が提供する機能を利用できる。
【０１４２】
Ｔｕｎｅｒ１６０５ｃは、放送録画再生端末のＩｎ−ｂａｎｄ受信用チューナ１３０１を制御するためのＪａｖａライブラリである。ＪａｖａプログラムがＴｕｎｅｒ１６０５ｃにチューニング情報を渡すと、Ｔｕｎｅｒ１６０５ｃはそれを用いてライブラリ１６０
１ｂのチューナ機能を呼び出し、結果、放送録画再生端末のＩｎ−ｂａｎｄ受信用チューナ１３０１の動作を制御できる。
【０１４３】
ＳＦ１６０５ｅは、放送録画再生端末のＰＩＤフィルタ１４０２及びセクションフィルタ１４０３機能を制御するためのＪａｖａライブラリである。ＪａｖａプログラムがＳＦ１６０５ｅにＰＩＤやｔａｂｌｅ＿ｉｄなどのフィルタ条件を渡すと、ＳＦ１６０５ｅはその条件を元にライブラリ１６０１ｂの機能などを用いてＰＩＤフィルタ１４０２及びセクションフィルタ１４０３を制御し、所望のフィルタ条件に叶うＭＰＥＧ２セクションを取得して、フィルタ条件を設定したＪａｖａプログラムに渡す。
【０１４４】
ＤＳＭ−ＣＣ１６０５ｄは、ＤＳＭ−ＣＣオブジェクトカルーセルのファイルシステムにアクセスするためのＪａｖａライブラリである。ＤＳＭ−ＣＣオブジェクトカルーセルは、ＳＦ１６０５ｅによって取得されるＭＰＥＧ２セクションが内包している。ＤＳＭ−ＣＣは、ＩＳＯ／ＩＥＣ１３８１８−６規格で定義されており、ＭＰＥＧ２セクションを利用して任意のファイルを伝送するための仕組みである。これを利用することで、放送局から端末にファイルを伝送することができる。ＤＳＭ−ＣＣの詳細な実現方法は本発明とは関係ないため、説明を省略する。
【０１４５】
サービスマネージャ管理１６０５ｆは、サービスマネージャ１６０４に対し、サービスの再生を依頼するためのＪａｖａライブラリである。ＪａｖａＶＭ１６０３によって実行されるＪａｖａプログラムはサービスマネージャ管理１６０５ｆを利用することで、サービスの再生をサービスマネージャ１６０４に依頼する。
【０１４６】
レコーディングマネージャ管理１６０５ｇは、レコーディングマネージャに対して、録画予約を指令するためのＪａｖａライブラリである。ＪａｖａＶＭ１６０３によって実行されるＪａｖａプログラムはレコーディングマネージャ管理１６０５ｇを利用することで、レコーディングマネージャに録画予約を指令する。なお、録画予約は本発明の根幹部分であり、詳細は後述するが、少なくとも録画予約を指令する場合、録画開始時刻及び録画継続時間、録画対象サービスを指すチャンネル識別子を必要とする。
【０１４７】
ＡＭ１６０５ｂは、サービスに含まれるＪａｖａアプリケーションの実行や終了を管理する機能を提供するアプリケーションマネージャである。ＡＭ１６０５ｂは指定されたＭＰＥＧ２トランスポートストリームの指定されたチャンネルに多重されたＪａｖａプログラムを抽出し、その抽出したＪａｖａプログラムを別途多重された同期情報に従って実行したり、あるいは終了させたりする。ＪａｖａプログラムのＪａｖａクラスファイルは、前述のＤＳＭ―ＣＣ方式でＭＰＥＧ２トランスポートストリームに多重されている。また、Ｊａｖａプログラムの同期情報はＡＩＴと呼ばれる形式で、ＭＰＥＧ２トランスポートストリームに多重されている。ＡＩＴは、ＤＶＢ−ＭＨＰ規格（ＥＴＳＩ  ＴＳ  １０１
８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）の１０章に定義されている、Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅの略であり、ｔａｂｌｅ＿ｉｄが「０ｘ７４」であるＭＰＥＧ２セクションである。
【０１４８】
ＡＭ１６０５ｂの入力は、ＭＰＥＧ２トランスポートストリームとチャンネル識別子である。まず、ＡＭ１６０５ｂは、指定されたチャンネル識別子をキーとしてライブラリ１６０１ｂのチャンネル情報を検索し、プログラムナンバーを得る。次にＳＦ１６０５ｅなどを利用して、ＭＰＥＧ２トランスポートストリームからＰＡＴを取得する。さらにＰＭＴの情報から、先ほど得られたプログラムナンバーに対応するＰＭＴのＰＩＤが得られる。再度ＳＦ１６０５ｅを利用して、実際のＰＭＴを取得する。取得されたＰＭＴは図１１の形式をしており、ストリーム種別が「データ」で補足情報として「ＡＩＴ」をもつエレメンタリ−ストリームのＰＩＤが書かれている。更にＳＦ１６０５ｅに、フィルタリング
条件として今得られたＡＩＴのＰＩＤとｔａｂｌｅ＿ｉｄ「０ｘ７４」を与えると、ＡＩＴの実体が得られる。
【０１４９】
図２１は、ＡＩＴの情報の一例を模式的に表した表である。ＡＩＴバージョン２１００は、そのＡＩＴのバージョンを表現する。ＡＩＴバージョンが大きいほど、そのＡＩＴはより新しいＡＩＴである。等しいＡＩＴバージョンをもつＡＩＴは繰り返し受信されるが、ＡＭ１６０５ｂはすでに解析したＡＩＴと等しいＡＩＴバージョンをもつＡＩＴは解析せず、すでに解析したＡＩＴよりも新しいＡＩＴのみを解析して、それに対応した処理をする。列２１０１はＪａｖａプログラムの識別子である。列２１０２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」「ｐｒｅｓｅｎｔ」「ｋｉｌｌ」等があり、「ａｕｔｏｓｔａｒｔ」は即時に端末装置１３００がこのＪａｖａプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味し、「ｋｉｌｌ」はＪａｖａプログラムを停止することを意味する。列２１０３は、ＤＳＭ―ＣＣ方式でＪａｖａプログラムを含んでいるＰＩＤを抽出するためのとＤＳＭ―ＣＣ識別子である。
【０１５０】
列２１０４はＪａｖａプログラムのプログラム名である。行２１１１、行２１１２、行２１１３、行２１１４は、Ｊａｖａプログラムの情報の組である。行２１１１で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。同様に、行２１１２で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。ここで、行２１１１、行２１１２、行２１１４で定義される３つのＪａｖａプログラムは同一のＤＳＭＣＣ識別子をもつが、これは１つのＤＳＭＣＣ方式でエンコードされたファイルシステム内に３つのＪａｖａプログラムが含まれていることを表す。ここでは、Ｊａｖａプログラムに対して４つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はＤＶＢ−ＭＨＰ規格を参照されたい。
【０１５１】
ＡＭ１６０５ｂは、ＡＩＴの中から「ａｕｔｏｓｔａｒｔ」のＪａｖａプログラムを見つけ出し、対応するＤＳＭＣＣ識別子およびＪａｖａプログラム名を抽出する。図２１を参照して、ＡＭ１６０５ｂは行２１１１のＪａｖａプログラムを抽出し、ＤＳＭＣＣ識別子「１」およびＪａｖａプログラム名「ａ／ＴｏｐＸｌｅｔ」を取得する。次いでＡＭ１６０５ｂは、ＡＩＴから取得したＤＳＭＣＣ識別子を用いて、ＪａｖａプログラムをＤＳＭＣＣ方式で格納しているＴＳパケットのＰＩＤをＰＭＴから取得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭＣＣ識別子が合致するエレメンタリ−ストリームのＰＩＤを取得する。ここで、ＤＳＭＣＣ識別子が「１」であり、ＰＭＴが図１１とすると、行１１１４のエレメンタリ−ストリームが合致し、ＰＩＤ「５０１４」を取り出す。
【０１５２】
ＡＭ１６０５ｂは、ＳＦ１６０５ｅに、ＤＳＭＣＣ方式でデータが埋めこまれたＭＰＥＧ２セクションを伝送するＴＳパケットのＰＩＤおよびセクションフィルタ条件を指定する。ここでは、ＰＩＤ「５０１４」を与える。この結果、ＡＭ１６０５ｂは、必要なＤＳＭＣＣ用ＭＰＥＧ２セクションを収集することができる。ＡＭ１６０５ｂは、収集したＭＰＥＧ２セクションから、ＤＳＭＣＣ方式に従ってファイルシステムを復元し、１次記憶部１３０８に保存する。ＭＰＥＧ２トランスポートストリーム中のＴＳパケットからファイルシステム等のデータを取り出し１次記憶部１３０８、２次記憶部１３０７等の記憶手段に保存することを以降、ダウンロードとよぶ。
【０１５３】
図２２は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、２２０１はルートディレクトリ、２２０２はディレクトリ「ａ
」、２２０３はディレクトリ「ｂ」、２２０４はファイル「ＴｏｐＸｌｅｔ．ｃｌａｓｓ」、２２０５はファイル「ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」、２２０６はディレクトリ「ｚ」、２２０７はファイル「ＭｕｓｉｃＸｌｅｔ．ｃｌａｓｓ」、２２０８はファイル「ＳｔｕｄｙＸｌｅｔ．ｃｌａｓｓ」である。
【０１５４】
次いでＡＭ１６０５ｂは、１次記憶部１３０８にダウンロードしたファイルシステム中から実行するＪａｖａプログラムをＪａｖａＶＭ１６０３に引き渡す。ここで、実行するＪａｖａプログラム名が「ａ／ＴｏｐＸｌｅｔ」とすると、Ｊａｖａプログラム名の最後に「．ｃｌａｓｓ」を付加したファイル「ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」が実行すべきファイルとなる。「／」はディレクトリやファイル名の区切りであり、図２２を参照して、ファイル２２０４が実行すべきＪａｖａプログラムである。次いでＡＭ１６０５ｂは、ファイル２２０４をＪａｖａＶＭ１６０３に引き渡すと、そのファイルはＪａｖａプログラムとしてＪａｖａ ＶＭ上で実行される。
【０１５５】
ＡＭ１６０５ｂは、新しいＡＩＴバージョンを持つＡＩＴが来る度にそのＡＩＴを解析してＪａｖａプログラムの実行状態を変更させる。ここで、制御情報に「ｋｉｌｌ」が指定されていた場合は、Ｊａｖａプログラムを終了させる。
【０１５６】
ＪＭＦ１６０５ａは、サービスに含まれる映像と音声の再生制御を担う。具体的には、指定されたＭＰＥＧ２トランスポートストリームの指定されたチャンネルに多重された映像ＥＳと音声ＥＳをＡＶデコーダに入力して再生させる。受信した放送波から直接サービスを再生する場合は、アダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームを再生するように指定される。一方、２次記憶部１３０７に一旦記録されたサービスを再生する場合は、２次記憶部１３０７内の記録領域１４０４から出力されるＭＰＥＧ２トランスポートストリームを再生するように指定される。
【０１５７】
まず、ＪＭＦ１６０５ａは、指定されたチャンネル識別子をキーとしてライブラリ１６０１ｂのチャンネル情報を検索し、プログラムナンバーを得る。次にＳＦ１６０５ｅなどを利用して、ＭＰＥＧ２トランスポートストリームからＰＡＴを取得する。さらにＰＭＴの情報から、先ほど得られたプログラムナンバーに対応するＰＭＴのＰＩＤが得られる。再度ＳＦ１６０５ｅを利用して、実際のＰＭＴを取得する。取得されたＰＭＴは図１１の形式をしており、ストリーム種別が「映像」及び「音声」であるエレメンタリ−ストリームのＰＩＤが書かれている。ＪＭＦ１６０５ａが、それらのＰＩＤをＴＳデコーダ１３０２のＰＩＤフィルタ１４０２に設定すると、図１４あるいは図１５に示されたごとく、該当ＰＩＤで多重されている映像ＥＳと音声ＥＳがＡＶデコーダ１３０３経由で再生される。
【０１５８】
レコーディングマネージャ１６０６は、チャンネル識別子と開始時刻、終了時刻を入力として、当該サービスを、指定された開始時刻と終了時刻の間だけ２次記憶部１３０７に記録する。例えば、ＥＰＧ１６０２からチャンネル識別子と開始時刻、終了時刻を指定されると、開始時間になるまで待機する。その後、開始時間に至ると、指定サービスの記録を開始し、終了時間に至ると記録を終了する。以下にその詳細を記述する。
【０１５９】
記録開始時間に至ると、最初に、レコーディングマネージャ１６０６は、２次記憶部１３０７に指定された開始時刻から終了時刻までのＭＰＥＧ２トランスポートストリームを記録するための記録領域１４０４を２次記憶部１３０７内に確保する。確保した記録領域には、メディア識別子を与える。次にＴｕｎｅｒ１６０５ｃにチャンネル識別子を与える。するとＴｕｎｅｒ１６０５ｃは、ライブラリ１６０１ｂ経由でチャンネル情報を参照し、チューニング情報を取得し、チューニングを開始する。すると図１４に示されるように、アダプタ１３１１経由でＭＰＥＧ２トランスポートストリームがＴＳデコーダに入力さ
れる。
【０１６０】
一方、レコーディングマネージャ１６０６は、ＳＦ１６０５ｅを利用して、チューニングで得られたＭＰＥＧ２トランスポートストリームからＰＡＴを取得する。さらに、指定されたチャンネル識別子に対応するプログラムナンバーをライブラリ１６０１ｂから検索し、得られたプログラムナンバーに対応するＰＭＴのＰＩＤをＰＡＴから検索する。その後、ＳＦ１６０５ｅを利用して、実際のＰＭＴを取得し、指定されたチャンネルを構成するＥＳの全ＰＩＤを得る。レコーディングマネージャ１６０６は、得られたＰＩＤをＴＳデコーダのＰＩＤフィルタ１４０２に設定する。すると、図１４で説明した流れに沿って、所望のチャンネルを構成する全ＥＳが、先ほど領域確保した記録領域１４０４に記録される。
【０１６１】
その後、指定された終了時刻に至ると、レコーディングマネージャ１６０６はＴｕｎｅｒ１６０５ｃのチューニング動作を停止させ、記録領域１４０４へのＭＰＥＧ２トランスポートストリームの書き込みを終了させる。また、先ほど記録したＭＰＥＧ２トランスポートストリームの管理情報として、図２０に示すレコード情報管理テーブルを作成する。
【０１６２】
図２０は２次記憶部１３０７等の記録領域１４０４に記録されているレコード情報を管理するためのレコード情報管理テーブルの一例である。レコード情報は表形式で記録されている。列２００１は、レコード識別子である。列２００２は、チャンネル識別子である。列２００３はプログラムナンバーである。列２００４はサービスの録画開始時間、列２００５はサービスの録画終了時間である。そして、列２００６はサービスとして記録されたＭＰＥＧ２トランスポートストリームを識別するメディア識別子である。行２０１１〜２０１２の各行は、各レコード識別子、チャンネル識別子、プログラムナンバー、開始時間、終了時間、および、メディア識別子の組となる。例えば、行２０１１はレコード識別子が「０００」、チャンネル識別子が「２」、プログラムナンバーが「１０２」、開始時間が「２００５／０３／３０  １１：００」、終了時間が「２００５／０３／３０  １２：００」、および、メディア識別子が「ＴＳ＿００１」であることを示す。
【０１６３】
サービスマネージャ１６０４は、２次記憶部１３０７に記録済みのＭＰＥＧ２トランスポートストリーム中のサービス、あるいはアダプタ１３１１から入力されるＭＰＥＧ２トランスポートストリーム中のサービスの再生を管理する。
【０１６４】
以下に、２次記憶部１３０７に記録済みのＭＰＥＧ２トランスポートストリーム中のサービスの再生を管理する場合の動作について述べる。これは録画済みサービスの再生に相当する。この場合、サービスマネージャ１６０４は、レコード識別子を入力とする。そのレコード識別子で特定される、２次記憶部１３０７に記録済みのサービスが、再生対象である。
【０１６５】
サービスマネージャ１６０４は、まず、レコーディングマネージャ１６０６が作成したレコード情報管理テーブルを参照して、指定されたレコード識別子で再生されるべきチャンネル識別子と、メディア識別子を得る。そして、２次記憶部１３０７に対して、今得られたメディア識別子で特定されるＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に出力するように、ライブラリ１６０１ｂを通して指示する。その後、ＪＭＦ１６０５ａにＭＰＥＧ２トランスポートストリームの所在として２次記憶部１３０７を与え、また再生すべきチャンネル識別子を与える。すると、ＪＭＦ１６０５ａは、既に述べた動作によって、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重された映像と音声の再生を開始する。
【０１６６】
更に、ＡＭ１６０５ｂにもＭＰＥＧ２トランスポートストリームの所在として２次記憶
部１３０７を与え、また再生すべきチャンネル識別子を与える。すると、ＡＭ１６０５ｂは２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重されたＡＩＴに従って、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重されたＪａｖａプログラムの実行及び終了を開始する。その後、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームの終端まで、上述のサービスの再生を継続する。
【０１６７】
一方、以下に、アダプタ１３１１から入力されるＭＰＥＧ２トランスポートストリーム中のサービスの再生を管理する場合を説明する。これは、放送波から直接サービスを再生することに相当する。この場合、サービスマネージャ１６０４は、再生対象サービスのチャンネル識別子を入力とする。
【０１６８】
サービスマネージャ１６０４は、図１４のアダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームをＴＳデコーダ１３０２に出力するように、ライブラリ１６０１ｂを通して指示する。その後、ＪＭＦ１６０５ａにＭＰＥＧ２トランスポートストリームの所在としてアダプタ１３１１を与え、また再生すべきチャンネル識別子を与える。すると、ＪＭＦ１６０５ａは、既に述べた動作によって、アダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームに多重された映像と音声の再生を開始する。更に、ＡＭ１６０５ｂにもＭＰＥＧ２トランスポートストリームの所在としてアダプタ１３１１を与え、また再生すべきチャンネル識別子を与える。すると、ＡＭ１６０５ｂはアダプタ１３１１から出力されるＭＰＥＧ２トランスポートストリームに多重されたＡＩＴに従って、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームに多重されたＪａｖａプログラムの実行及び終了を開始する。その後、２次記憶部１３０７から出力されるＭＰＥＧ２トランスポートストリームの終端まで、上述のサービスの再生を継続する。
【０１６９】
ＥＰＧ１６０２は、電子番組表（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅの略）であり、録画や再生の対象とする番組をユーザに選択させる機能である。放送波を受信しての通常の再生は本発明の趣旨から外れるため、説明を割愛する。
【０１７０】
番組を記録する場合は、ＥＰＧ１６０２は、放送番組一覧を表示してユーザに希望の番組を選択させる。図１８は、録画対象とする番組を選択させるための画面表示の一例である。時刻１７０１とチャンネル１７０２と１７０３が格子状に表示され、各時刻で記録可能な各チャンネルの番組を一覧できる。ユーザは端末装置１３００の入力部１３１０に備わっている上下左右カーソルボタン１４０１ｘ〜１４０４ｘを用いて画面上のフォーカス１８３０を移動させることができる。更にＯＫボタン１４０５ｘを押下すると、現在フォーカスが当たっている番組が記録対象として選択される。ＥＰＧ１６０２は当該番組のチャンネル識別子をライブラリから取得して知っており、ユーザによって記録対象番組が選択されると、当該番組のチャンネル識別子、開始時間、終了時間をレコーディングマネージャ１６０６に通知する。レコーディングマネージャ１６０６は、その情報に基づいて、当該番組を２次記憶部１３０７に記録する。
【０１７１】
一方、記録済みの番組を再生する場合は、ＥＰＧ１６０２は、記録済み番組一覧を表示してユーザに希望の番組を選択させる。図１７は、録画済み番組を選択させるための画面表示の一例である。その時点で２次記憶部１３０７に記憶されている番組がすべて一覧表示される。ユーザは端末装置１３００の入力部１３１０に備わっている上下カーソルボタン１４０１ｘ，１４０２ｘを用いて画面上のフォーカス１７３０を移動させることができる。更にＯＫボタン１４０５ｘを押下すると、現在フォーカスが当たっている番組が再生対象として選択される。ＥＰＧ１６０２は当該番組のレコード識別子をレコーディングマネージャ１６０６から取得して知っており、ユーザによって再生対象番組が選択されると
、当該番組のレコード識別子をサービスマネージャ１６０４に通知する。サービスマネージャ１６０４は、その情報に基づいて、当該番組を２次記憶部１３０７から読み出して再生する。
【０１７２】
またここで、ＯＣＡＰ及びＯＣＡＰ−ＤＶＲ環境にて規定される抽象サービスについても言及しておく。抽象サービスは映像及び音声を含まず、Ｊａｖａプログラムのみを含む特殊なサービスである。抽象サービスに関する情報は、前述のＯＯＢにて伝送される特殊なＡＩＴに記載される。このＡＩＴは、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様ではＸＡＩＴと呼ばれる。端末は電源投入時、ＳＦ１６０５ｅを利用してＸＡＩＴをＯＯＢより取得し、抽象サービスに関する情報を取得し、抽象サービスに含まれるＪａｖａプログラムを起動する。ＸＡＩＴに情報が記載されるＪａｖａプログラムを、本発明では、「特権プログラム」と呼称する。なお、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様では特権プログラムのことをモニタアプリケーションとも呼称する。
【０１７３】
ここまでは、本発明の前提となる録画機能について詳述した。以降、デバイスの競合、及び競合が起こった際の競合解決手法について述べる。
【０１７４】
例えばＩｎ−ｂａｎｄ受信用チューナ１３０１が端末に１つしか存在しない場合、サービスマネージャによる「放送から受信したＭＰＥＧ２トランスポートストリームに含まれる映像及び音声の再生処理」と、「放送から受信したＭＰＥＧ２トランスポートストリームに含まれる番組の記録」を同時に実行することは不可能であるため、Ｉｎ−ｂａｎｄ受信用チューナ１３０１がどちらの処理に利用されるかを決定する必要がある。このように「デバイスの絶対数の不足により、要求される複数の処理を並列的に実行できない状況」を「デバイスの競合」と呼び、さらに、「要求される複数の処理の中から、優先して実行する処理を選別すること」を「デバイス競合の解決」と呼ぶ。
【０１７５】
本発明の端末は、デバイス競合解決時、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様に規定されるデバイス競合解決手順に準拠する。以下、規定のデバイス競合解決手順について詳述する。
【０１７６】
ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様では、競合する可能性のあるデバイスの種類をあらかじめ特定している。Ｉｎ−ｂａｎｄ受信用チューナ１３０１はその一つである。本発明では、これを「排他デバイス」と呼ぶ。また、排他デバイスを操作するＪａｖａライブラリを「排他デバイス操作ライブラリ」と呼ぶ。Ｉｎ−ｂａｎｄ受信用チューナ１３０１に関しては、Ｔｕｎｅｒ１６０５ｃがこれにあたる。
【０１７７】
図２３はＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様に規定される排他デバイス利用手順を表現するシーケンス図である。排他デバイスを利用するすべてのＪａｖａプログラムは本シーケンスを利用する必要がある。まずＳ２３０１において、排他デバイスを確保する。この際デバイスクライアントと呼ばれるＪａｖａオブジェクトを排他デバイスに対して登録する。確保に成功すると、Ｓ２３０２において、排他デバイスを利用して所望の機能を実行する。所望の処理が終わると、Ｓ２３０３に至りＪａｖａプログラムは排他デバイスの解放を行う。もしＪａｖａプログラムが図２３のシーケンスに従わず、排他デバイスの確保をせずにその機能を利用しようとした場合は、そのＪａｖａプログラムに対してエラーを通知する。例として、Ｔｕｎｅｒ１６０５ｃにおいては、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣｏｎｔｒｏｌｌｅｒクラスにある、ｒｅｓｅｒｖｅ、ｔｕｎｅ、ｒｅｌｅａｓｅメソッドがそれぞれ確保、利用、解放に当たる。
【０１７８】
排他デバイス操作ライブラリは、排他デバイス管理テーブルにて、排他デバイスの確保状況を管理する。例えば図２４は、Ｔｕｎｅｒ１６０５ｃが１次記憶部１３０８上または
２次記憶部１３０７上に管理するＩｎ−ｂａｎｄ受信用チューナ管理テーブルである。列２４１１はＩｎ−ｂａｎｄ受信用チューナを識別するための識別子である。この例では排他デバイスであるＩｎ−ｂａｎｄ受信用チューナは３つあるもの（つまりチューナ１、２、３の３つ）あるものを例に説明をする。列２４１２はＩｎ−ｂａｎｄ受信用チューナ１３０１を利用しているＪａｖａプログラムの識別子である。列２４１３は、確保時に登録されたデバイスクライアントである。また行２４０１〜行２４０３はＩｎ−ｂａｎｄ受信用チューナに関する情報を示す。図２４においては、Ｉｎ−ｂａｎｄ受信用チューナ１３０１の１つであるチューナ１はプログラムＡによって確保され、デバイスクライアントとしてクライアントＣが登録されている。また、チューナ２はプログラムＢによって確保され、デバイスクライアントとしてクライアントＤが登録されている。またチューナ３はどのプログラムからも確保がされていない。
【０１７９】
図２５は、Ｊａｖａプログラムが排他デバイス確保ＡＰＩの動作を表現するシーケンス図である。まずＳ２５０１において、Ｊａｖａプログラムが指定した排他デバイス識別子、Ｊａｖａプログラム識別子、デバイスクライアントを受け取る。Ｓ２５０２において、排他デバイス管理テーブルを参照し、特定された排他デバイスが既に他のＪａｖａプログラムによって確保されているかどうか調べる。確保されていない場合は、Ｎｏに進んでＳ２５０３に至り、Ｓ２５０１にて受け取ったＪａｖａプログラム識別子及びデバイスクライアントを、排他デバイス管理テーブルに設定する。確保されている場合は、Ｙｅｓに進んでＳ２５０４に至り、デバイスの競合解決を行う。デバイスの競合解決に関しては後述する。
【０１８０】
排他デバイス操作ライブラリは、ＯＣＡＰ仕様及びＯＣＡＰ−ＤＶＲ仕様が規定するデバイス競合解決アルゴリズムに従って、Ｓ２５０４にて排他デバイスの競合解決を行う。大別して２種類のデバイス競合解決アルゴリズムが存在するため、デバイス競合解決アルゴリズム１、デバイス競合解決アルゴリズム２と呼んで区別する。
【０１８１】
図２６はデバイス競合アルゴリズム１における動作手順を表すシーケンス図である。Ｓ２６０１において、排他デバイスを既に確保しているＪａｖａプログラム及びデバイスクライアントを取得する。次にＳ２６０２において、Ｓ２６０１にて取得したデバイスクライアントに対して、排他デバイスの解放を要求する。排他デバイスの解放を要求されたデバイスクライアントは、排他デバイスを解放するかどうかの判断を行い、その結果を排他デバイス操作ライブラリに返す。Ｓ２６０３に至って、デバイスクライアントの返答を評価し、解放に同意した場合、Ｙｅｓに進んでＳ２６０６に至り、新規に排他デバイスを確保しようとしているＪａｖａプログラム識別子及びデバイスクライアントで更新して終了する。
【０１８２】
解放に同意しなかった場合、Ｎｏに進んでＳ２６０４に至り、既に排他デバイスを確保していたＪａｖａプログラムの優先度と、新規に排他デバイスを確保しようとしているＪａｖａプログラムの優先度をＡＭ１６０５ｂから取得して、比較する。もし新規に確保しようとしているＪａｖａプログラムの優先度の方が高ければ、Ｙｅｓに進んでＳ２６０５に至り、排他デバイスを確保していたＪａｖａプログラムのデバイスクライアントに強制解放通知を行い、Ｓ２６０６に進んで新規に排他デバイスを確保しようとしているＪａｖａプログラム識別子とデバイスクライアントで排他デバイス管理テーブルを更新して終了する。分岐Ｓ２６０４において、もし既に確保しているＪａｖａプログラムの方が、優先度が高いか等しければ、新規に排他デバイスを確保しようとしているＪａｖａプログラムにエラーを通知して処理を終了する（Ｓ２６０７）。
【０１８３】
図２６で表したように、デバイス競合解決アルゴリズム１はＡＩＴまたはＸＡＩＴに記載されるＪａｖａプログラムの優先度に基づいてデバイスの競合を解決する。デバイス競
合解決アルゴリズム１を用いる場合は、優先度が高いＪａｖａプログラムの方が常に有利な結果を得られる。
【０１８４】
一方、デバイス競合解決アルゴリズム２は、特権プログラムがデバイス競合を解決する。この場合、Ｊａｖａプログラムの優先度とは関係なく、特権プログラムが好む条件や順序でデバイスを各Ｊａｖａプログラムに割り当てる。デバイス競合解決アルゴリズム２では、特権プログラムは、２種類の方法で、所望のデバイス競合解決を実現する。一つは、排他デバイスを確保する権利のあるＪａｖａプログラムを選別する「Ｊａｖａプログラムフィルタ」である。例えば、Ｉｎ−ｂａｎｄ受信用チューナ１３０１の確保をさせたくないＪａｖａプログラムに対しては、Ｊａｖａプログラムフィルタを用いて、これを排除可能である。もう一つはＪａｖａプログラムフィルタによって確保が許可されたＪａｖａプログラムの中で排他デバイス確保の優先順序を決定する、「デバイス競合解決ハンドラ」である。本デバイス競合解決ハンドラは、例えば、ＪａｖａプログラムフィルタによってＩｎ−ｂａｎｄ受信用チューナ１３０１の確保権利を持つと判断されたＪａｖａプログラム１とＪａｖａプログラム２の間でＩｎ−ｂａｎｄ受信用チューナ１３０１の競合が起こった場合、どちらを優先するかを決定するものである。デバイス競合解決アルゴリズム２を用いるのは、Ｊａｖａプログラムフィルタ及びデバイス競合解決ハンドラの一方あるいは両方が、排他デバイス操作ライブラリに登録された場合である。
【０１８５】
図２７〜図２９はデバイス競合解決アルゴリズム２における動作手順を表現したシーケンス図である。
【０１８６】
デバイス競合解決アルゴリズム２の第一の図２７は、Ｊａｖａプログラムフィルタに関連する動作手順を表現したシーケンス図である。Ｓ２７０１において、排他デバイス操作ライブラリにＪａｖａプログラムフィルタが既に登録されているかどうか調査し、登録されてなければＮｏのＳ２７０５に進み、図２８のＳ２８０１から始まるシーケンスに接続する。登録されていれば、ＹｅｓのＳ２７０２に進み、新規に排他デバイスを確保しようとしているＪａｖａプログラムが、その排他デバイスを確保する権利があるかどうか、Ｊａｖａプログラムフィルタに問い合わせ、Ｊａｖａプログラムフィルタは、判定結果を排他デバイス操作ライブラリに返す。次にＳ２７０３に至り、そのＪａｖａプログラムが排他デバイスを確保する権利を持っていれば、Ｙｅｓへ進み、Ｓ２７０５に至って図２８のＳ２８０１から始まるシーケンスに接続する。権利を持っていなければ、Ｎｏへ進み、Ｓ２７０４に至る。デバイスを新規予約しようとしているＪａｖａプログラムにエラーを返して、動作手順を終了する。
【０１８７】
デバイス競合解決アルゴリズム２の第二の図２８は、Ｊａｖａプログラム本来の優先度に基づく優先度判断を行う動作手順を表現したシーケンス図である。本シーケンス図は一点を除いてデバイス競合解決アルゴリズム１を解説した図２６と同様であり詳細は割愛する。異なる一点は、Ｊａｖａプログラムの優先度によるデバイス競合解決を行う前に、Ｓ２８０５において、図２９にて表現されるシーケンス図への接続がある点である。
【０１８８】
デバイス競合解決アルゴリズム２の第三の図２９は、特権プログラムが登録したデバイス競合解決ハンドラによるデバイス競合解決を表現する。Ｓ２９０１にて、まずデバイス競合解決ハンドラが登録されているかどうか調査し、登録されていないのであればＮｏへ進んでＳ２９０２に至る。Ｓ２９０２は、図２８のＳ２８０５へ接続し、Ｊａｖａプログラムの優先度に基づくデバイス競合解決処理へ移行する。分岐Ｓ２９０１において、デバイス競合解決ハンドラが登録されている場合、Ｙｅｓに進んでＳ２９０３に至る。Ｓ２９０３では、デバイス競合解決ハンドラに、Ｊａｖａプログラムのデバイス確保優先順位を問い合わせる。デバイス競合解決ハンドラは、Ｊａｖａプログラム識別子の配列を返す。端末は、本ＡＰＩが返した配列を解析し、その配列に含まれるＪａｖａプログラム識別子
の順に優先して、排他デバイスの競合を解決する。Ｓ２９０４では、デバイス競合解決ハンドラが返した配列を調査する。もし配列が返ってこなければ、「ＮＵＬＬ」に進み、Ｓ２９０２に至り、図２８のＳ２８０５へ接続し、Ｊａｖａプログラムの優先度に基づくデバイス競合解決処理へ移行する。分岐Ｓ２９０４において、配列の長さが０であれば、「長さ０」に進んでＳ２９０８に至り、新規にデバイスを確保しようとしているＪａｖａプログラムへエラーを返して処理を終了する。分岐Ｓ２９０４において、配列の長さが正の値であれば、「長さ１以上」に進んで、Ｓ２９０５に至る。
【０１８９】
Ｓ２９０５では、Ｓ２９０３にて取得した配列に基づき、新規にデバイスを確保しようとしているＪａｖａプログラムと、既にデバイスを確保しているＪａｖａプログラムで、どちらが優先順位が高いかを判定する。もし、新規にデバイスを確保しようとしているＪａｖａプログラムの方が優先順位が低ければ、Ｎｏに進んでＳ２９０８に至り、そのＪａｖａプログラムへエラーを返してデバイス競合解決処理を終了する。分岐Ｓ２９０５において、新規に排他デバイスを獲得しようとしているＪａｖａプログラムのほうが優先順位が高ければ、Ｙｅｓに進んで、Ｓ２９０６に至る。Ｓ２９０６では、既に排他デバイスを予約しているＪａｖａプログラムのデバイスクライアントを排他デバイス管理テーブルから取得して、デバイスクライアントに対して、強制的に解放することを通知する。Ｓ２９０７では、新規に確保しようとしているＪａｖａプログラムの識別子及びデバイスクライアントを持って排他デバイス管理テーブルを更新し、処理を終了する。
【０１９０】
図２７〜図２９にて表現したデバイス競合解決アルゴリズム２を用いると、特権プログラムは、Ｊａｖａプログラムフィルタ及びデバイス競合解決ハンドラを用いて、Ｊａｖａプログラムの優先度よりも強い特権プログラム独自の判断基準によって、デバイス競合解決を行うことが可能である。
【０１９１】
また、サービスマネージャ１６０４及びレコーディングマネージャ１６０６が排他デバイスを利用する際も、確保、利用、解放の３プロセスを利用する、という原則を守らなければならない。この場合、サービスマネージャ管理１６０５ｆを利用してサービスマネージャ１６０４に対してサービスの再生を依頼したＪａｖａプログラムや、レコーディングマネージャ管理１６０５ｇを利用してレコーディングマネージャ１６０６に対してサービスの記録を依頼したＪａｖａプログラムが、排他デバイスを確保しようとしていると見なされ、デバイス競合解決が行われる。
【０１９２】
以上、説明してきたデバイス競合解決アルゴリズムはＯＣＡＰ及びＯＣＡＰ−ＤＶＲ仕様にて例外なく利用されるデバイス競合解決手順である。デバイス競合解決アルゴリズム１及びデバイス競合解除アルゴリズム２において、デバイス競合解決にかかる時間について考察しておく。
【０１９３】
図３０はデバイス競合解決アルゴリズム１が利用された場合、誰がどのような作業に時間を消費したかを表現したシーケンス図である。まず、新規にＪａｖａプログラムＢが、排他デバイス操作ライブラリに対して、排他デバイスの確保を要求したとする。すると、排他デバイス操作ライブラリはまず確保する対象デバイスが競合しているかどうか判断する（３００１）。競合していた場合、排他デバイス操作ライブラリは、既にそのデバイスを確保しているＪａｖａプログラムＡに対してデバイス解放を要求する。ＪａｖａプログラムＡは、その時行っている処理を中止してデバイスを解放してもよいかどうか判断する（３００２）。ここで、デバイスは解放できないと判断されると、その結果を受け取った排他デバイス操作ライブラリは、ＪａｖａプログラムＡと、新規にデバイスを確保しようとしているＪａｖａプログラムとの間で優先度の比較を行う（３００３）。もし新規にデバイスを確保しようとしているＪａｖａプログラムの方が高優先度であれば、ＪａｖａプログラムＡに対して、強制解放通知を行う。強制解放通知を受け取ったＪａｖａプログラ
ムＡは強制解放に基づく後処理を行って（３００４）、後処理の終了を排他デバイス操作ライブラリに通知する。
【０１９４】
図３１はデバイス競合解決アルゴリズム２が利用された場合、誰がどのような作業に時間を消費するか表現したシーケンス図である。まず、新規にＪａｖａプログラムＢが、排他デバイス操作ライブラリに対して、排他デバイスの確保を要求したとする。すると、排他デバイス操作ライブラリはまず、ＪａｖａプログラムＢが、確保対象の排他デバイスを確保することができるかどうか特権プログラムに判断してもらうため、Ｊａｖａプログラムフィルタを利用する。特権プログラムは、ＪａｖａプログラムＢが対象の排他デバイスを確保することができるかどうか判断し（３１０１）、結果を排他デバイス操作ライブラリに結果を返す。次に、排他デバイス操作ライブラリは、確保対象のデバイスが競合しているかどうかを判断する（３１０２）。
【０１９５】
競合していた場合、排他デバイス操作ライブラリは、既にそのデバイスを確保しているＪａｖａプログラムＡに対してデバイス解放を要求する。ＪａｖａプログラムＡは、その時行っている処理を中止してデバイスを解放してもよいかどうか判断する（３１０３）。ここで、デバイスは解放できないと判断されると、その結果を受け取った排他デバイス操作ライブラリは、特権プログラムに対して、どちらのＪａｖａプログラムを優先するか決定してもらうためにデバイス競合解決ハンドラを利用する。特権プログラムはデバイス確保の優先順位を決定し（３１０５）、排他デバイス操作ライブラリに結果を返す。排他デバイス操作ライブラリは、その優先順位に基づいてデバイスの競合を解決する（３１０６）。さらに、デバイスを奪われたＪａｖａプログラムＡに対して、強制解放通知を行う。強制解放通知を受け取ったＪａｖａプログラムＡは強制解放に基づく後処理を行って（３１０７）、後処理の終了を排他デバイス操作ライブラリに通知する。
【０１９６】
図３０及び図３１で表したように、ＯＣＡＰ及びＯＣＡＰ−ＤＶＲ仕様で規定されるデバイス競合の解決手順には、端末組込みの排他デバイス操作ライブラリだけでなく、ダウンロードして実行する特権プログラムや、デバイスを確保しているＪａｖａプログラムの動作がシーケンシャルに組み込まれている。つまりデバイス競合解決にかかる時間は、特権プログラムやＪａｖａプログラムの動作に依存するため、あらかじめ予測することは不可能である。
【０１９７】
具体的に例を挙げる。特権プログラムが、デバイス競合解決アルゴリズム制御ライブラリ１６０５ｉにデバイス競合解決ハンドラを登録しているケースを考える。この時、ＪａｖａプログラムＡ及びＪａｖａプログラムＢが同時に動作しており、各々がＴｕｎｅｒ１６０５ｃを利用してチューナ１３０１を操作しようとした場合、Ｔｕｎｅｒ１６０５ｃはデバイス競合解決ハンドラのデバイス予約優先順位取得ＡＰＩを呼び出して、順序を表現する配列を取得する。その後、取得した配列内のＪａｖａプログラム識別子の順序に基づいて、デバイス競合解決を行う。ここで、デバイス競合解決ハンドラを特権プログラムが用意していることに注目すると、デバイス予約優先順位取得ＡＰＩ実装内部では、特権プログラムが所望の動作を行うことが可能である。例えば、常にＪａｖａプログラムＡを優先するような配列を返す実装をしておくことができる。
【０１９８】
例えば、ＪａｖａプログラムＡ及びＪａｖａプログラムＢの選択肢を示すダイアログを画面に表示し、ユーザに選択権を与えるような実装も可能である。後者の場合、ユーザに選択を入力させる時間が必要なので、ある特権プログラムは、１分といったタイムアウトを設定してその間ユーザ入力を待つかもしれないし、ある特権プログラムは、ユーザ入力を永久に待ち続けるかもしれない。つまり、Ｔｕｎｅｒ１６０５ｃがデバイス予約優先順位取得ＡＰＩを呼び出してから、優先順位を表す配列を返すまでどれくらいの時間が必要かを、Ｔｕｎｅｒ１６０５ｃは予め予想することができない。
【０１９９】
以下、本発明における特徴的な要素に関して詳述する。本発明は、録画予約とサービスの再生におけるデバイス競合解決に関連する。
【０２００】
Ｊａｖａプログラムはレコーディングマネージャ管理１６０５ｇを利用することにより、録画予約を行うことができることは既に述べた。録画予約は、少なくとも録画対象サービスのチャンネル識別子、録画開始時刻、録画継続時間を持って成される。録画処理は少なくともＩｎ−ｂａｎｄ受信用チューナ１３０１を排他デバイスとして確保する処理であることから、録画予約は、「未来のデバイス確保の予約」である、と捉えることができる。
【０２０１】
録画予約自身、明示的に録画開始時刻及び録画継続時間を有することから、録画予約同士の競合を避けることは容易である。例えば、１０時から１時間録画を行う録画予約Ａと、１２時から１時間録画を行う録画予約Ｂはデバイス競合を起こすことはないが、１０時半から１時間録画を行う録画予約Ｃは録画予約Ａとデバイス競合を起こす。この場合、少なくとも１０時半から１１時の間、二つの録画処理が要求されることになるからである。レコーディングマネージャ管理１６０５ｇは、このような録画予約時間の重複を事前に検知する機能を有する必要がある。
【０２０２】
しかし、録画予約はデバイスを利用する時間帯が明示的に示されているのに対し、放送ＭＰＥＧ２トランスポートストリームに含まれる映像音声の再生のような「Ｊａｖａプログラムがリアルタイムに要求を出して開始される処理」は、デバイスを利用する期限が明示的に示されない。さらに、いつＪａｖａプログラムがこの処理を開始するか、端末には予測のしようがない。本発明ではこのように、いつ開始されいつ終了するか端末が予測できない処理を「突発処理」と呼ぶ。
【０２０３】
ＯＣＡＰ仕様で規定される、ＭＰＥＧ２ストリーム内の情報を利用して行われる処理（セクションフィルタリング処理、ＡＶ再生など）は全て突発処理である。突発処理同士のデバイス競合は、デバイス競合が起こったときにデバイス競合解決を行えばよい。
【０２０４】
録画予約時に、録画予約同士の「未来のデバイス競合」を解決するのが容易であることは既に述べた。しかし突発処理と録画予約のデバイス競合は、予約された録画の開始時刻になってみなければ起こるかどうか不明である（事実１）。
【０２０５】
また、前述したように、ＯＣＡＰ仕様が規定するデバイス競合解決アルゴリズム１及びデバイス競合解決アルゴリズム２に準拠したデバイス競合解決処理に要する時間は、端末が事前に予測することは不可能である（事実２）。
【０２０６】
上記事実１及び事実２より、「デバイス競合解決を録画開始時刻になってから開始した場合、予約時に指定された時刻から録画を開始することは不可能であり、録画開始時刻を守るためには、事前にデバイス競合解決を行っておく必要がある」という結論が導かれる。
【０２０７】
本実施の形態では、特権プログラムが、レコーディングマネージャ管理１６０５ｇに対し、「予約録画の開始時刻よりどれくらい前にデバイス競合解決を行うか」を表す時間を予め指定する。レコーディングマネージャ管理１６０５ｇは、録画が実際に開始される時刻よりも前に、デバイス競合解決処理を開始する。
【０２０８】
図３２は本発明を実現するレコーディングマネージャ管理１６０５ｇの構成図である。
【０２０９】
レコーディングマネージャ１６０６については図１６と同様である。
排他デバイス３２２２は前述したように、チューナ１３０１などの排他デバイスを表現する。
【０２１０】
排他デバイス操作ライブラリ３２２１は前述した排他デバイス操作ライブラリを表現する。
【０２１１】
録画予約管理テーブル３２０１は、録画予約情報を保持するテーブルである。録画予約管理テーブル３２０１は、電源切断時にも保持され続けるよう２次記憶部１３０７上に管理される。図３３は録画予約管理テーブル３２０１の例を表現した図である。列３３１１はサービスのチャンネル識別子である。列３３１２は録画予約を行ったＪａｖａプログラムの識別子である。列３３１３は録画を行う時間帯である。列３３１４は録画予約の状態である。「録画待ち」「競合」「未解決」の状態を管理する。「録画待ち」は他の録画予約と録画時間が重複しないこと表現する。「競合」は他の録画予約と録画時間が重複しており、そのままでは録画が開始されないことを表現する。「未解決」は、当該録画予約が、他の録画予約と録画時間帯が重複しているかどうかまだ調査されていないことを表現する。列３３１５は録画予約を一意に特定するための予約ＩＤである。行３３０１〜行３３０３は、録画予約の内容である。
【０２１２】
デバイス競合アラーム３２０２はデバイス競合解決処理部３２０６に対して、デバイス競合解決処理を行うタイミングを通知する内部モジュールである。デバイス競合アラーム３２０２は、端末の起動時に同時に起動される。本モジュールはハードウェアタイマを用いて実装されてもよく、またソフトウェアを用いて実装されてもよい。図３５はデバイス競合アラームが管理するアラームスケジュール表の一例を表現する図である。列３５１１はデバイス競合を解決する時刻である。列３５１２はデバイス競合を解決すべき対象となる録画予約を指す予約ＩＤである。行３５０１〜行３５０３は、各録画予約である。
【０２１３】
レコーディングマネージャアラーム３２０３は、レコーディングマネージャ１６０６に対して、録画開始時刻になったことを通知する内部モジュールであり、端末の起動時に起動される。本モジュールはハードウェアタイマを用いて実装されてもよく、またソフトウェアを用いて実装されてもよい。
【０２１４】
デバイス競合解決間隔管理部３２０４は、特権プログラムが設定した「録画開始時刻に先駆けて行うデバイス競合解決の、録画開始時刻との間隔」を管理する領域である。デバイス競合解決間隔管理部３２０４は、１次記憶部１３０８または２次記憶部１３０７上に実現される領域である。図３６はデバイス競合解決間隔管理部３２０４の一例を表現した図である。３６１１は、間隔を保持する領域である。図３６の例では、間隔は６０秒である。
【０２１５】
録画予約制御部３２０５は、録画予約の情報管理を行うライブラリとして実現される。ＲＯＭ１３０９上に記録され、実行時には１次記憶部１３０８上に展開される。ＪａｖａＶＭ１６０３が実行するＪａｖａプログラムが利用することで動作する。図３４は録画予約制御部３２０５の動作手順を表現するシーケンス図である。Ｓ３４０１において、Ｊａｖａプログラムが録画予約を登録するために指定したチャンネル識別子、録画開始時刻、録画継続時間を取得する。Ｓ３４０２において、Ｓ３４０１にて取得した情報を録画予約管理テーブル３２０１に追加登録する。このとき、状態は「未解決」に設定する。
【０２１６】
Ｓ３４０３では、Ｓ３４０２にて追加した録画予約と、録画時間帯が重複する録画予約があるかどうか調査を行う。Ｓ３４０４にて録画時間帯が重複する録画予約が存在するかどうか判断を行う。存在しなかった場合、Ｎｏに進んでＳ３４０５に至る。Ｓ３４０５で
は、Ｓ３４０２で追加登録した録画予約と録画時間帯が重複するものが無かったため、状態を「録画待ち」に変更して処理を終了する。分岐Ｓ３４０４にて、時間帯が重複する録画予約が存在した場合、Ｓ３４０６にて、録画予約間でデバイス競合解決を行って、優先する録画予約を決定する。デバイス競合解決は、前述したデバイス競合解決アルゴリズムに従って行われる。Ｓ３４０７では、優先する録画予約に関して、状態を「録画待ち」に設定し、優先しない録画予約に関して、状態を「競合」に設定する。Ｓ３４０８では、Ｓ３４０７にて状態を「録画待ち」に設定された録画予約の録画開始時刻を録画予約管理テーブル３２０１より取得し、レコーディングマネージャアラーム３２０３に当該録画予約の予約ＩＤ及び録画開始時刻を設定する。
【０２１７】
Ｓ３４０８では、Ｓ３４０７にて状態を「録画待ち」に設定された録画予約の録画開始時刻から、デバイス競合解決間隔管理部３２０４より取得した時間だけ早い時刻を計算し、計算の結果得られた時刻及び予約ＩＤをデバイス競合アラーム３２０２に設定する。例えば、録画予約管理テーブル３２０１が図３３の状態にあり、デバイス競合解決間隔管理部が図３６の状態にあり、Ｓ３４０６の結果、状態を「録画待ち」に設定された録画予約が、行３３０１だった場合、行３３０１より取得した録画開始時刻「Ｍａｙ  ５ｔｈ  ２１：００」を６０秒前倒しして「Ｍａｙ  ５ｔｈ  ２０：５９」を得、この値と、行３３０１より取得した予約ＩＤをデバイス競合アラーム３２０２に設定する。
【０２１８】
デバイス競合解決処理部３２０６は予約された録画と突発処理間のデバイス競合解決を行う内部モジュールである。デバイス競合解決処理部３２０６はそれ自体が能動的に動作するプロセスまたはスレッドとして実現され、端末の起動時にＲＯＭ１３０９から１次記憶部１３０８にロードされ、起動される。図３７はデバイス競合解決処理部３２０６の、デバイス競合アラーム３２０２から通知を受けた際の動作手順を表現したシーケンス図である。Ｓ３７０１にて、デバイス競合アラーム３２０２の通知より、事前デバイス競合解決を行う録画予約の予約ＩＤを取得する。Ｓ３７０２にて、Ｓ３７０１で取得した予約ＩＤを利用して、録画予約管理テーブル３２０１から録画予約に関する情報を取得する。Ｓ３７０３に進んで、予約録画に利用する排他デバイスを管理する排他デバイス操作ライブラリより、排他デバイスの利用状況を取得する。Ｓ３７０４にて排他デバイスの利用状況について判定を行う。
【０２１９】
その時点で再生などの突発処理に利用されていなければＮｏに進んでＳ３７０９に至り、録画予約管理テーブル３２０１の当該録画予約の状態を「録画待ち」に設定し、処理を終了する。その時点で突発処理に利用されていればＹｅｓに進んでＳ３７０５に至る。Ｓ３７０５にて、録画予約と、その時点で行われている突発処理間でデバイス競合解決を行い、優先する処理を決定する。デバイス競合解決は前述したデバイス競合解決アルゴリズムに従って行われる。但し、この時点では録画予約と突発処理間の優先順位を決定するのみで、実際のデバイスの奪い取りは行わない。デバイスの奪い取りはレコーディングマネージャ１６０６が実際に録画を開始する際に行われる。Ｓ３７０６にて、Ｓ３７０５にて行ったデバイス競合解決の結果、録画予約を優先するかどうか判断する。録画予約を優先する場合、Ｙｅｓに進んで、Ｓ３７０９に進んで、録画予約管理テーブル３２０１の当該録画予約の状態を「録画待ち」に設定し、処理を終了する。突発処理を優先する場合、Ｎｏに進んでＳ３７０７に至る。
【０２２０】
Ｓ３７０７では、録画予約がデバイス競合のために開始できないことを表現するため、録画予約管理テーブル３２０１の当該録画予約の状態を「競合」に設定する。Ｓ３７０８では、レコーディングマネージャアラーム３２０３に対して、予約ＩＤを指定してアラームの停止を指令する。これにより、当該録画予約に関して、レコーディングマネージャ１６０６が録画を開始することが無くなる。
【０２２１】
デバイス競合解決間隔登録部３２１０は、デバイス競合解決間隔管理部３２０４にデバイス競合解決間隔を記録するために用いられる。デバイス競合解決間隔登録部３２１０は、ライブラリとして実現され、特権プログラムがこれを呼び出すことで、デバイス競合解決間隔を設定する。
【０２２２】
レコーディングマネージャ１６０６は、レコーディングマネージャアラーム３２０３からの通知を受け取って、録画処理を開始する。この録画開始に先立って録画予約と突発処理間のデバイス競合解決は既に終わっているため、この時点で他突発処理が利用するデバイスを強制的に奪い取って、録画処理を開始する。図３８はレコーディングマネージャ１６０６の動作手順を表現したシーケンス図である。Ｓ３８０１にてレコーディングマネージャアラームの通知より、録画予約を指す予約ＩＤを取得する。Ｓ３８０２にて、録画予約管理テーブル３２０１より予約ＩＤで指定された録画予約に関する情報を録画予約管理テーブルから取得する。Ｓ３８０３にて、強制的にデバイスを奪い取り、Ｓ３８０４にて録画を開始する。
【０２２３】
本実施の形態で述べた手法により、実際に録画開始時刻よりも、特権プログラムが指定した間隔だけ先立ってデバイス競合解決処理を進めることができ、録画開始時刻を厳守することができる。
【０２２４】
なお、本例では、予約録画開始時に、レコーディングマネージャ１６０６が、排他デバイスを確保しているが、レコーディングマネージャ１６０６が行うのではなく、デバイス競合解決処理部３２０６が、事前デバイス競合解決処理の終了時に排他デバイスを確保する実装であってもよい。その場合、実際に排他デバイスが確保されるのは、予約録画開始時刻よりも前になる。
【０２２５】
（実施の形態２）
本実施の形態で述べる発明では、デバイス競合解決処理部３２０６による事前デバイス競合解決処理に時間がかかり、レコーディングマネージャ１６０６による録画開始時にまだ特権プログラムによるデバイス競合解決処理が終わっていなかった場合、強制的にデバイス競合解決処理を終了させ、Ｊａｖａプログラムの優先度によるデバイス競合解決処理に移行する。
【０２２６】
図３６におけるデバイス競合解決間隔管理部３２０４の例では、事前デバイス競合解決処理を、録画予約に６０秒先立って行うことを特権プログラムが設定していた。この場合、特権プログラムは６０秒あれば「デバイス競合解決処理を終了することができる」と想定していたことを意味する。しかし、デバイス競合解決処理は特権プログラムの動作を含む特権プログラムが事前に指定した間隔では処理が終わらない可能性がある。この場合、レコーディングマネージャ１６０６がレコーディングマネージャアラーム３２０３によって起こされた時には、まだデバイス競合解決処理部３２０６によるデバイス競合解決が終わっておらず、不整合が発生する。
【０２２７】
本実施の形態では、レコーディングマネージャ１６０６がレコーディングマネージャアラーム３２０３によって起こされた時にまだデバイス競合解決処理部３２０６によるデバイス競合解決が終わっていない場合には、レコーディングマネージャ１６０６はデバイス競合解決処理部３２０６に対して、デバイス競合解決処理を即座に中止するように指令する。その後、デバイス競合解決処理部３２０６に対して、Ｊａｖａプログラムの優先度を用いたデバイス競合解決処理を即座に開始するよう指令する。図３９はレコーディングマネージャ１６０６の動作手順を表すシーケンス図である。Ｓ３９０１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ３９０２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得
する。Ｓ３９０３にて、録画予約の状態を調査する。
【０２２８】
「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ３９０７に至る。Ｓ３９０７にて、デバイスを強制的に確保し、Ｓ３９０８にて録画を開始して、処理を終了する。分岐Ｓ３９０３にて、録画予約の状態が「録画待ち」ではなく、「未解決」であれば、デバイス競合解決処理部３２０６による事前デバイス競合解決が継続中であることを意味する。このときＮｏに進んでＳ３９０４に至る。
【０２２９】
Ｓ３９０４では、デバイス競合解決処理部３２０６に、事前デバイス競合解決処理の中止を指令し、Ｓ３９０５にて、Ｊａｖａプログラムの優先度を用いたデバイス競合解決処理を即座に実行するようデバイス競合解決処理部３２０６に指令する。Ｓ３９０６の優先度判定の結果、録画優先であれば、Ｙｅｓに進んでＳ３９０７に至り、前述の処理を行う。録画優先でなければＮｏに進んで処理を終了する。
【０２３０】
（実施の形態３）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合、強制的に予約録画処理を優先する。
【０２３１】
図４０はレコーディングマネージャ１６０６の動作手順を表すシーケンス図である。Ｓ４００１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ４００２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ４００３にて、録画予約の状態を調査する。「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ４００５に至る。Ｓ４００５にて、デバイスを強制的に確保し、Ｓ４００６にて録画を開始して、処理を終了する。Ｓ４００３にて、「未解決」であればＮＯに進んでＳ４００４に至る。Ｓ４００４にて、デバイス競合解決処理部３２０６に事前デバイス競合解決の中止を指令し、Ｓ４００５に進む。
【０２３２】
なお、本実施の形態では、予約録画を常に優先しているが、再生などの突発処理を常に優先する方針であってもよい。
【０２３３】
（実施の形態４）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するか、判定ポリシーを特権プログラムが事前に設定する。録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合は、その判定ポリシーに従って、優先すべき処理を決定する。
【０２３４】
図４１は本実施の形態におけるレコーディングマネージャ管理１６０５ｇの構成である。図３２と同じ番号を持つものは同様であるため説明は省略する。本実施の形態では、デバイス競合解決方針保持部４１０７及びデバイス競合解決方針登録部４１０８を導入する。
【０２３５】
デバイス競合解決方針保持部４１０７は、特権プログラムのよって予め指定された判定ポリシーを保持する。デバイス競合解決方針保持部は、２次記憶部１３０７上に実現され、電源断によってもその内容が失われない。
【０２３６】
デバイス競合解決方針登録部４１０８は、ライブラリとして実現される。デバイス競合解決方針登録部４１０８は、特権プログラムによって利用されると、利用時に指定された
判定ポリシーをデバイス競合解決方針保持部４１０７に登録する。
【０２３７】
特権プログラムは、録画予約制御部３２０５利用に先立って、デバイス競合解決方針登録部４１０８呼び出しによって、デバイス競合解決方針を事前に設定しておく。デバイス競合解決方針登録部４１０８が呼び出されると、端末は引数に指定されたデバイス競合解決方針をデバイス競合解決方針保持部４１０７に記録する。本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先するか、再生などの突発処理を優先するかを表現するフラグ」を含む。
【０２３８】
本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４２に示す。領域４２０１は、上記、事前デバイス競合解決処理が終了しなかった場合の判定ポリシーを記憶する。図４２においては、予約録画を優先する旨が記憶されている。
【０２３９】
図４３は本実施の形態におけるレコーディングマネージャ１６０６の動作を表すシーケンス図である。Ｓ４３０１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ４３０２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ４３０３にて、録画予約の状態を調査する。「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ４３０７に至る。Ｓ４３０７にて、デバイスを強制的に確保し、Ｓ４３０８にて録画を開始して、処理を終了する。
【０２４０】
分岐Ｓ４３０３にて、録画予約の状態が「録画待ち」ではなく、「未解決」であれば、デバイス競合解決処理部３２０６による事前デバイス競合解決が継続中であることを意味する。このときＮｏに進んでＳ４３０４に至る。Ｓ４３０４では、デバイス競合解決処理部３２０６に、事前デバイス競合解決処理の中止を指令する。Ｓ４３０５にて、事前に特権プログラムによって設定されたデバイス競合解決方針をデバイス競合解決方針保持部４１０７より取得する。Ｓ４３０６において、Ｓ４３０５で取得したデバイス競合解決方針を判定し、予約録画優先であれば、Ｙｅｓに進んでＳ４３０７に至り、前述の処理を行う。予約録画優先でなければＮｏに進んで処理を終了する。
【０２４１】
（実施の形態５）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「時間帯毎」に設定する。
【０２４２】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先する時間帯指定」を含む。
【０２４３】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、予約録画が優先される時間帯を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４４に示す。列４４１１は時間帯を表現する。行４４０１及び行４４０２は各時間帯設定を表す。本例では、２００５年１０月１０日の１９：００〜２１：００及び２００５年１０月１１日の１９：００〜２１：００は予約録画が優先される。
【０２４４】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４４に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、予約録画の開始時刻が、そのテーブルに記載された時間帯に含まれれば予約録画を優先し、含まれなければ再生などの突
発処理を優先する。
【０２４５】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持する時間帯は予約録画を優先し、その他の時間帯は再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先する時間帯を保持し、その他の時間帯は予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先する時間帯指定」を含む。
【０２４６】
なお、本実施の形態では、デバイス競合解決方針保持部４１０７が保持する時間帯の中に、予約録画の開始時刻が含まれていれば予約録画優先、として説明したが、予約録画の開始時刻から終了時刻までの時間全体が含まれていれば予約録画優先、としてもよい。また、予約録画の終了時刻が含まれていれば予約録画優先、としてもよい。
【０２４７】
（実施の形態６）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「チャンネル毎」に設定する。
【０２４８】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先するチャンネル識別子」を含む。
【０２４９】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、予約録画が優先されるサービスを特定するチャンネル識別子を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４５に示す。列４５１１はチャンネル識別子を表現する。行４５０１及び行４５０２は各チャンネル識別子設定を表す。本例では、チャンネル識別子「１」及び「２」は予約録画が優先される。
【０２５０】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４５に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、予約録画対象のサービスを表現するチャンネル識別子が、そのテーブルに記載されたチャンネル識別子群に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２５１】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持するチャンネル識別子が表現するサービスに関しては予約録画を優先し、その他のサービスは再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先するサービスのチャンネル識別子を保持し、その他のサービスは予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先するチャンネル識別子」を含む。
【０２５２】
（実施の形態７）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「１以上の番組毎」に設定する。
【０２５３】
ＯＣＡＰ−ＤＶＲ仕様等、番組録画に関する仕様では、番組録画指定時に、番組を特定する番組識別子を与える手法が想定される。この時に利用される番組識別子は１以上の番組を示す。番組識別子は、ＳＩによってサービスや時間帯と結び付けられる。端末は番組
識別子を指定した予約録画要求を受信すると、ＳＩを利用して具体的なサービスや録画時間を導出し、録画を行う。
【０２５４】
番組識別子が１つの番組を表現する場合の例として、例えばある映画をあらわす番組識別子を指定して録画予約する。番組識別子が複数の番組を表現する場合の例として、例えばあるドラマの１２回シリーズをあらわす番組識別子を指定して録画予約する。このように、番組識別子は、１つで１以上の番組を表現することができる場合もある。なお、「番組識別子が１つの番組を表すか複数の番組を表すか」、「またどのサービスのどの時間帯を表すか」、をＳＩを利用して解決する方法は、ＳＩの形式によって多種多様であり、説明は割愛する。しかし、どのような解決手段が用いられても本発明は適用可能である。
【０２５５】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先する１以上の番組を指す番組識別子」を含む。
【０２５６】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、予約録画が優先される番組を表現する番組識別子を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４６に示す。列４６１１は番組識別子を表現する。行４６０１及び行４６０２は各番組識別子設定を表す。本例では、番組識別子「１」及び「２」は予約録画が優先される。
【０２５７】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４６に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、予約録画対象の番組を表現する番組識別子が、そのテーブルに記載された番組識別子群に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２５８】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持する番組識別子が表現する番組に関しては予約録画を優先し、その他の番組は再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先する番組の番組識別子を保持し、その他の番組は予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先する番組識別子」を含む。
【０２５９】
なお、本実施の形態において、デバイス競合解決方針保持部４１０７は図４６のように番組識別子を管理するが、番組識別子を予めＳＩを用いて解決し、図４４のような時間帯テーブルに変更して保持してもよい。
【０２６０】
（実施の形態８）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、特権プログラムが「リソース毎」に設定する。
【０２６１】
本実施の形態におけるデバイス競合解決方針登録部４１０８の引数は、少なくとも「予約録画を優先するリソース識別子」を含む。
【０２６２】
本実施の形態におけるデバイス競合解決方針保持部４１０７は、録画が優先されるリソースを特定するリソース識別子を保持する。本実施の形態における、デバイス競合解決方針保持部４１０７が管理するテーブル例を図４７に示す。列４７１１はリソース識別子を表現する。行４７０１は各リソース識別子設定を表す。本例では、リソース識別子「チューナ１」は予約録画が優先される。
【０２６３】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と同様である。但し、Ｓ４３０５において読み出されるのは図４７に表現されるテーブルの情報であり、Ｓ４３０６において、どちらを優先するか判定する際、競合するリソースを表現するリソース識別子が、そのテーブルに記載されたリソース識別子群に含まれれば予約録画を優先し、含まれなければ再生などの突発処理を優先する。
【０２６４】
なお、本実施の形態では、デバイス解決方針保持部４１０７が保持するリソース識別子が表現するリソースに関しては予約録画を優先し、その他のリソースは再生などの突発処理を優先する、としたが、逆の設定であってもよい。つまり、デバイス解決方針保持部４１０７は再生などの突発処理を優先するリソースのリソース識別子を保持し、その他のリソースは予約録画を優先するように管理されてもよい。この場合、デバイス競合解決方針登録部４１０８の引数は、少なくとも「再生などの突発処理を優先するリソースを特定するリソース識別子」を含む。
【０２６５】
（実施の形態９）
本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、予約録画及び突発処理のどちらを優先するかを表現する判定ポリシーを、予約録画時に、録画予約制御部３２０５に引数として与える。
【０２６６】
本実施の形態における録画予約制御部３２０５の引数には、録画対象を指し示す値以外に、少なくとも「予約録画を優先するかどうかを表現するフラグ」を含む。
【０２６７】
図４８は、本実施の形態において、録画予約管理テーブル３２０１が管理する情報を表現する図である。列３３１１〜列３３１５は図３３と同様なので説明は省略する。列４８１６は、録画予約毎に「予約録画を優先するか、再生などの突発処理を優先するか」を表現する録画優先フラグである。行４８０１〜行４８０３は、録画優先フラグを含む、各録画予約である。本例では、行４８０１及び行４８０３に記載される録画予約に関しては録画優先フラグが“ＴＲＵＥ”なので予約録画を優先し、行４８０２に記載される録画予約に関しては録画優先フラグが“ＦＡＬＳＥ”なので再生などの突発処理を優先することを表現する。
【０２６８】
本実施の形態におけるレコーディングマネージャ１６０６の動作は図４３と二点を除いて同様である。異なる点の第一は、Ｓ４３０５において読み出されるのは、録画予約管理テーブル３２０１が管理する図４８に表される情報であることである。異なる点の第二は、Ｓ４３０６における判定に際し、競合を起こしている録画予約に関して、その録画予約の録画優先フラグが“ＴＲＵＥ”であれば予約録画を優先し、“ＦＡＬＳＥ”であれば再生などの突発処理を優先させることである。
【０２６９】
なお、本実施の形態では、録画予約管理テーブル３２０１が管理する図４８の列４８１６の録画優先フラグは、“ＴＲＵＥ”であれば予約録画優先、“ＦＡＬＳＥ”であれば再生などの突発処理優先を表現するが、録画優先フラグの代わりに突発処理優先フラグを導入し、“ＴＲＵＥ”であれば再生などの突発処理優先、“ＦＡＬＳＥ”であれば予約録画優先を表現してもよい。この場合、録画予約制御部３２０５は少なくとも、「再生などの突発処理を優先するかどうかを表現するフラグ」を引数として含む。
【０２７０】
（実施の形態１０）
本実施の形態では、本実施の形態では、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に、特権プログラムに対して、事前デバイス競合解決処理を延長して実行し続けるかどうか問い合わせる。
【０２７１】
図４９は本実施の形態におけるレコーディングマネージャ管理１６０５ｇの構成である。図３２と同じ番号のものは、同様の機能を持つため説明は割愛する。図４９では、時間切れコールバック保持部４９０７及び時間切れコールバック登録部４９０８が導入されている。
【０２７２】
時間切れコールバック保持部４９０７は、録画開始時刻までに事前デバイス競合解決処理が終了しなかった場合に呼び出す時間切れコールバックを保持する。時間切れコールバック保持部４９０７は、１次記憶部１３０８または２次記憶部１３０７上の領域として実現される。または専用レジスタとして実現されてもよい。
【０２７３】
時間切れコールバック登録部４９０８は、時間切れコールバック保持部４９０７に保持する時間切れコールバックを登録するのに利用される。時間切れコールバックの登録は、特権プログラムが時間切れコールバック登録部４９０８を呼び出すことによって成される。時間切れコールバック登録部４９０８は、ライブラリとして実現され、実態はＲＯＭ１３０９に存在し、端末の起動時に１次記憶部１３０８に展開される。
【０２７４】
図５０は時間切れコールバックが登録されている場合のレコーディングマネージャ１６０６の動作を表現するシーケンス図である。Ｓ５００１にて、レコーディングマネージャアラーム３２０３の通知より、録画予約を表す予約ＩＤを取得する。Ｓ５００２にて予約ＩＤにて指定される録画予約情報を録画予約管理テーブル３２０１から取得する。Ｓ５００３にて、録画予約の状態を調査する。「録画待ち」であれば既にデバイス競合解決処理部３２０６による事前デバイス競合解決が終わっているということを意味する。この場合、Ｙｅｓに進んでＳ５００４に至る。
【０２７５】
Ｓ５００４にて、デバイスを強制的に確保し、録画を開始して、処理を終了する。分岐Ｓ５００３にて、録画予約の状態が「録画待ち」ではなく、「未解決」だった場合、事前デバイス競合解決がまだ終わっていないことを意味する。この場合Ｎｏに進んでＳ５００５に至る。ここで時間切れコールバック保持部４９０７に保持される時間切れコールバックを取得する。Ｓ５００６に進み、時間切れコールバックを取得できたかどうか判定を行う。もしなければＳ５０１０に進んでデバイス競合解決処理部に事前デバイス競合解決の中止を指令して処理を終了する。Ｓ５００６で、時間切れコールバックを取得できた場合、Ｙｅｓに進んでＳ５００７に進み、時間切れコールバックを呼び出して、時間内に処理が終了しなかったことを通知する。時間切れコールバックは、返値として、事前デバイス競合解決処理を延長するか終了するかを返す。
【０２７６】
返値が「ＮＯ」だった場合、Ｓ５０１０に進んでデバイス競合解決処理部に事前デバイス競合解決の中止を指令して処理を終了する。返値が「ＹＥＳ」だった場合、事前デバイス競合解決処理を延長するため、Ｓ５００９へ進んで、レコーディングマネージャアラーム３２０３に、再度デバイス競合解決間隔管理部３２０４が管理するタイムアウト時間を設定してアラームを依頼し、処理を終了する。レコーディングマネージャアラーム３２０３にアラームを依頼したことにより、タイムアウト時間が経過したあとに再度図５０のシーケンスが励起される。
【０２７７】
なお、本実施の形態では、Ｓ５００９にてアラームを再設定する際、アラームの時間間隔としてデバイス競合解決間隔管理部３２０４が保持するタイムアウト値を用いた。しかしＳ５００７にて呼び出すコールバックの返値として、新規タイムアウト値を取得し、それを利用してもよい。その場合、Ｓ５００８で行われる判定は上記説明と異なり、返値が０より大きければ事前デバイス競合解決処理延長とみなしてＳ５００９に進み、返値が０以下であれば延長はしないとみなしてＳ５０１０に進む。
【０２７８】
なお、本実施の形態では、Ｓ５０１０にて事前デバイス競合解決処理を中止した後、処理を終了しているが、以前の実施の形態で述べたように、さらにデバイス競合解決処理を行っても良い。例えば実施の形態２にあるようにＪａｖａプログラムの優先度解決を行ってもよいし、実施の形態３にあるように強制的に録画を開始することにしても良い。実施の形態４以降にあるように様々な判定ポリシーを利用して競合解決を図っても良い。また、その場合、どのデバイス競合解決処理を選択するかをコールバックの返値を用いて決定してもよい。例えば「−１」であれば録画強制開始、「−２」であればＪａｖａプログラムの優先度解決、「−３」であれば判定ポリシーを用いた解決、などとしてもよい。
【０２７９】
また、本実施の形態では、Ｓ５００９にて再処理のための間隔を指定してアラーム設定しているが、再処理を想定せず、無限に待つことにしてもよい。この場合、デバイス競合解決処理部３２０６の処理は無限に待たれ、終了した時点で、デバイス競合解決処理部３２０６がレコーディングマネージャ１６０６を起こして録画処理を開始することになる。
【０２８０】
以上説明したいくつかの実施例は、本発明の実現例を示したものであり、本発明の趣旨が実現される限り他の実現例でも実施可能である。
【０２８１】
実施例ではケーブルシステムを対象とした構成を示したが、本発明は放送システムの種類に依存しない。例えば、衛星システム、地上波システム、あるいはＩＰネットワークを用いた番組配信システムなどにも容易に適応可能である。さらに本発明は各放送システムの違いと直接的な関係を持たないため、放送システムに係らず任意の伝送媒体で適用可能である。有線、無線の違いにも依存しない。
【０２８２】
ＡＶデコーダは、必ずしも映像および音声を同時にデコードする必要はない。映像デコーダ、音声デコーダを分離した構成としても、本発明は実現可能である。またＡＶデコーダがクローズドキャプションなどのデータに対するデコード機能を持っていても差し支えない。ＡＶデコーダによってデコードされたａｕｄｉｏ信号およびｖｉｄｅｏ信号が、記録領域１４０４に蓄積されるまでの任意の段階において暗号化されてもよい。
【０２８３】
実施例では、限定視聴を制御するアダプタを導入した例を示したが、アダプタは本発明を実現するために必ずしも必要ではない。アダプタの形式がいかなるものであってもよいし、またアダプタのない構成とすることも可能である。その場合、図１４において、チューナからのＭＰＥＧ２トランスポートストリームが直接ＴＳデコーダに入力される。この場合も本発明は適用可能である。また、アダプタによる限定視聴解除をＴＳデコーダ以前に行う必要はない。任意の位置でアダプタを利用して限定視聴を解除する構成とすることは容易であり、その場合も本発明は適用可能である。
【０２８４】
ＡＶエンコーダによるａｕｄｉｏ信号およびｖｉｄｅｏ信号のエンコード形式は、任意の形式であってもよい。本発明はいかなるエンコード形式であっても適用可能である。
【０２８５】
多重器の多重形式は任意の形式であってもよい。本発明はいかなる多重形式であっても適用可能である。
【０２８６】
ディスプレイ及びスピーカは、放送録画再生装置内部に包含していてもよく、放送録画再生装置に外部ディスプレイ及びスピーカを接続してもよい。ディスプレイおよびスピーカの存在場所や数によらず、本発明は適用可能である。
【０２８７】
ＣＰＵ自身が、ＴＳデコード、ＡＶデコード、ＡＶエンコードおよび多重化のすべてあるいはいくつかの処理を兼用で行うシステムであっても本発明は実施可能である。
【０２８８】
サービスを記録する形式としては、他にもＴＳデコーダを介さずにチューナからのＭＰＥＧ２トランスポートストリーム出力を直接、記録領域記録してもよいし、ＭＰＥＧ２トランスポートストリームの形式を変換するトランスレータを設けてチューナからのＭＰＥＧ２トランスポートストリームを形式変換して記録領域に記録してもよい。いかなるサービス記録方式を用いても、本発明は実施可能である。
【０２８９】
一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵが理解可能な実行形式に翻訳してから、ＣＰＵに引渡して実行するが、この場合でも本発明は適用可能である。
【０２９０】
以上の実施例では、トランスポートストリームがＩｎ−ｂａｎｄから得られるとしてＡＩＴに関して実現方法を説明したが、ＡＭが実行すべきＪａｖａプログラムを参照する手法はＡＩＴによるものだけではない。米国ケーブルシステムで利用されることが想定されるＯＣＡＰでは図３に記載されるＯＯＢにてアプリケーションプログラムの参照情報を記載するＸＡＩＴが利用されている。その他、ＲＯＭに予め記録されているものを起動する、２次記憶にダウンロードして記憶したものを起動する、等の方法も考えられる。
【０２９１】
一部実施例では、事前リソース競合解決が、録画予約開始時刻に間に合わなかった場合の判定ポリシーを、特権プログラムが設定することに関して言及しているが、この場合、複数の判定ポリシーを同時に利用することも可能である。例えば、録画を優先するサービスを表現するチャンネル識別子、及び、その時間帯を指定することにより、条件に合致するサービスで、さらに条件に合致する時間帯のみ録画を優先する、といった指定が可能となる。これはチャンネル識別子と時間帯のペアだけでなく、言及した判定ポリシー同士のいかなる組み合わせを用いることも可能である。
【０２９２】
また、本発明において、特権プログラムが指定する「事前リソース競合解決処理（事前デバイス競合解決処理）を開始する、録画開始時刻から遡る時間間隔（実施の形態１では６０秒を例として説明）」は、特権プログラムが設定する値が用いられるため何秒であってもよい。さらに、特権プログラムが設定するのでなく、端末独自の値を用いるものであっても良い。さらに、遡る基準の時刻は「録画開始時刻」としているが、端末によっては、ＨＤＤ回転処理等、録画を開始するための準備に既に時間をかけなければならない場合があるため、「録画開始時刻を端末固有の準備時間だけ遡った時刻」を基準時刻としてもよい。
【０２９３】
上記に詳細に説明した本発明の実施の形態は単なる例示にすぎず、本発明の新規な教示および効果から実質的に逸脱することなく例示として挙げた実施の形態において様々な変更が可能であることは、当業者であれば容易に理解するところである。したがって、かかる変更はすべて本発明の範囲内に含まれるものである。                              
【産業上の利用可能性】
【０２９４】
本発明は放送信号からアプリケーションをダウンロードして実行する電子機器で、利用可能である。
【図面の簡単な説明】
【０２９５】
本願におけるこれらの目的および他の目的や、効果、特徴は、実施の形態を示す付属図面に関する以下の説明から明確になる。当該図面において、
【図１】図１は、本発明に係る放送システムの構成図である。
【図２】図２は、本発明に係るケーブルテレビシステムにおいて放送局側システムと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図３】図３は、本発明に係るケーブルテレビシステムにおいて放送局側システムと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図４】図４は、本発明に係るケーブルテレビシステムにおいて放送局側システムと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図５】図５は、ＭＰＥＧ２仕様で既定されるＴＳパケットの構成図である。
【図６】図６は、ＭＰＥＧ２トランスポートストリームの模式図である。
【図７】図７は、ＭＰＥＧ２仕様で既定されるＰＥＳパケットがＴＳパケットを用いて伝送される際の分割例を示す図である。
【図８】図８は、ＭＰＥＧ２仕様で既定されるＭＰＥＧ２セクションがＴＳパケットを用いて伝送される際の分割例を示す図である。
【図９】図９は、ＭＰＥＧ２仕様で既定されるＭＰＥＧ２セクションの構成図である。
【図１０】図１０は、ＭＰＥＧ２仕様で既定されるＭＰＥＧ２セクションの利用例を示す図である。
【図１１】図１１は、ＭＰＥＧ２仕様で規定されるＰＭＴの利用例を示す図である。
【図１２】図１２は、ＭＰＥＧ２仕様で規定されるＰＡＴの利用例を示す図である。
【図１３Ａ】図１３Ａは、本発明に係る放送録画再生装置のハードウェア構成の構成例を示す図である。
【図１３Ｂ】図１３Ｂは、本発明にかかる入力部をフロントパネルで構成した場合の一例を示す図である。
【図１４】図１４は、本発明に係る録画再生装置の録画時におけるデバイス接続例を示す図である。
【図１５】図１５は、本発明に係る録画再生装置の再生時におけるデバイス接続例を示す図である。
【図１６】図１６は、本発明に係る端末装置が保存するプログラム構成の構成図である。
【図１７】図１７は、本発明に係る端末装置が実行するＥＰＧの一例を示す図である。
【図１８】図１８は、本発明に係る端末装置が実行するＥＰＧの一例を示す図である。
【図１９】図１９は、本発明に係る２次記憶部が保存する情報の一例を示す図である。
【図２０】図２０は、本発明に係るレコード情報管理テーブルの一例を示す図である。
【図２１】図２１は、本発明に係るＤＶＢ−ＭＨＰ規格が規定するＡＩＴの内容を表す模式図である。
【図２２】図２２は、本発明に係るダウンロードアプリケーションの構成図である。
【図２３】図２３は、本発明に係るデバイスの獲得及び解放を表現するシーケンス図である。
【図２４】図２４は、本発明に係るＩｎ−ｂａｎｄ受信用チューナ管理テーブルの一例を示す図である。
【図２５】図２５は、本発明に係る排他デバイス確保ＡＰＩの動作を表現するシーケンス図である。
【図２６】図２６は、本発明に係るデバイス競合アルゴリズム１のシーケンス図である。
【図２７】図２７は、本発明に係るデバイス競合アルゴリズム２のシーケンス図である。
【図２８】図２８は、本発明に係るデバイス競合アルゴリズム２のシーケンス図である。
【図２９】図２９は、本発明に係るデバイス競合アルゴリズム２のシーケンス図である。
【図３０】図３０は、本発明に係るデバイス競合解決アルゴリズム１利用時の時間消費を表現したシーケンス図である。
【図３１】図３１は、本発明に係るデバイス競合解決アルゴリズム２利用時の時間消費を表現したシーケンス図である。
【図３２】図３２は、本発明を実現するレコーディングマネージャ管理１６０５ｇの構成図である。
【図３３】図３３は、録画予約管理テーブル３２０１の例を表現した図である。
【図３４】図３４は、録画予約制御部３２０５の動作手順を表現するシーケンス図である。
【図３５】図３５は、デバイス競合アラームが管理するアラームスケジュール表の一例を表現する図である。
【図３６】図３６は、デバイス競合解決間隔管理部３２０６の一例を表現した図である。
【図３７】図３７は、デバイス競合解決処理部３２０６の、デバイス競合アラーム３２０２から通知を受けた際の動作手順を表現したシーケンス図である。
【図３８】図３８は、レコーディングマネージャ１６０６の動作手順を表現したシーケンス図である。
【図３９】図３９は、レコーディングマネージャ１６０６の動作手順を表すシーケンス図である。
【図４０】図４０は、レコーディングマネージャ１６０６の動作手順を表すシーケンス図である。
【図４１】図４１は、実施の形態４におけるレコーディングマネージャ管理１６０５ｇの構成を示す図である。
【図４２】図４２は、実施の形態４におけるデバイス競合解決方針保持部４１０７が管理するテーブル例である。
【図４３】図４３は、実施の形態４におけるレコーディングマネージャ１６０６の動作を表すシーケンス図である。
【図４４】図４４は、実施の形態５における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４５】図４５は、実施の形態６における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４６】図４６は、実施の形態７における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４７】図４７は、実施の形態８における、デバイス競合解決方針保持部４１０７が管理するテーブル例を示す図である。
【図４８】図４８は、実施の形態９における、録画予約管理テーブル３２０１が管理する情報を表現する図である。
【図４９】図４９は、実施の形態１０における、レコーディングマネージャ管理１６０５ｇの構成を示す図である。
【図５０】図５０は、実施の形態１０における、レコーディングマネージャ１６０６の動作シーケンス図である。
【国際調査報告】
2008543123.tif 000054
2008543123.tif 000055
2008543123.tif 000056