JP2006345303A - ディジタル放送受信装置 - Google Patents

Abstract

【課題】 ＴＹＰＥ２サーバー型放送の受信で欠落データが生じた場合でも、当該欠落データを比較的簡単且つ短い期間で再取得することができるディジタル放送受信装置を提供する。
【解決手段】 システムコントローラ１３は、ＴＹＰＥ２サーバー型放送の受信において、モジュール（ｎ）の取得完了状態やモジュール（ｎ）のブロック（ｍ）の取得完了状態などを管理し、未取得のデータ（ブロック）についての管理データを蓄積する。イーサネットコントローラ１８によってインターネット上のサーバーに接続することができる。前記サーバー（通信路）又は放送波を利用して前記未取得のデータを取得する。前記サーバー（通信路）又は放送波のどちらを用いるのが望ましいかの判断を、当該判断に利用できる付加情報（放送波から取り出すことができる）に基づいて行う。 【選択図】 図１

Description

この発明は、いわゆるＴＹＰＥ２サーバー型放送を受信することができるディジタル放送受信装置に関する。

ディジタル放送ではデータ放送が行われている。データ放送コンテンツは、ＡＲＩＢ ＳＴＤ−Ｂ２４で規定されるＤＳＭ−ＣＣデータカルーセル方式によって伝送され、映像及び音声などのストリーム型の伝送方式とは異なり、同一データを一定期間繰り返し送ることにより、放送受信装置が任意のタイミングでデータを取得することを可能にしている。ここで、繰り返し伝送されるデータの集合をデータカルーセル（図５参照）と呼び、各々のデータをモジュールと呼ぶ。データカルーセルは、ＤＩＩ（図６参照）及び、ＤＤＢの２種類から構成される。

また、通常の放送におけるチャンネルに相当するものはサービスと呼ばれ、各サービスは複数のコンポーネントを含み、各コンポーネントは複数のモジュールを含んで構成される。各サービスはサービス識別（ｓｅｒｖｉｃｅ＿ｉｄ）によって一意に識別され、各コンポーネントは、サービス内において、コンポーネント識別（ｃｏｍｐｏｎｅｎｔ＿ｔａｇ）によって一意に識別され、各モジュールは、コンポーネント内において、モジュール識別（ｍｏｄｕｌｅ＿ｉｄ）によって一意に識別される（すなわち、モジュールはｓｅｒｖｉｃｅ＿ｉｄ／ｃｏｍｐｏｎｅｎｔ＿ｔａｇ／ｍｏｄｕｌｅ＿ｉｄによって一意に識別される）。

更に、近年においては、ディジタル放送においてサーバー型放送が提案されている（特許文献１参照）。サーバー型放送においては、ＴＹＰＥ１と定義される放送とＴＹＰＥ２と定義される放送が予定されている。ＴＹＰＥ１とは、「取得日時と再生日時、取得期間と再生期間が同一のＡＶストリーム伝送」であり、従来の「放送」の受信再生と格段の差異は見当たらない。ＴＹＰＥ２とは、「取得日時と再生日時、取得期間と再生期間が異なる、カルーセルによるコンテンツ伝送」であり、例えば１時間の番組の送信に関して、１／１０の送出レートで１０時間かけて送出し、放送受信装置側に装備されるＨＤＤ（ハードディスクドライブ）などの記録装置に全てのデータを記録した後、ＨＤＤからデータを読み出して再生を行うものである。
特開２００４−３３６５７６号公報

ところで、カルーセルで伝送を行う場合にはデータの再送が基本であり、上記条件で３度の再送を行う場合には、連続した場合も含み、延べ伝送時間として３０時間かけて伝送することになる。放送においては天候等の諸要因により、受信状態が一時的に悪化することが考えられるが、現状のデータ放送等のように少ないサイズのコンテンツを短い周期で再送している場合と異なり、放送波からの欠落分のデータの再取得には、相当の長い時間を要してしまうことが予想される。結果として予約機能等の実行ができない事態が発生する可能性があり、また再送される日時も正確に判断することができないため、待機電力の増大なども懸念される。

この発明は、上記の事情に鑑み、ＴＹＰＥ２サーバー型放送の受信で欠落データが生じた場合でも、当該欠落データを比較的簡単且つ短い期間で再取得することができるディジタル放送受信装置を提供することを目的とする。

この発明のディジタル放送受信装置は、上記の課題を解決するために、取得日時と再生日時が異なり且つ取得期間と再生期間が異なる、カルーセルによるコンテンツ伝送であるＴＹＰＥ２サーバー型放送を受信し、受信したデータカルーセルを蓄積するディジタル放送受信装置において、蓄積済みのデータカルーセル中に欠落データが存在するかどうかを判断し、欠落データに関する情報を生成して蓄積する手段と、サーバーに接続するのに必要となる情報を放送波に載せられている付加情報から取得する手段と、通信路を用いて前記サーバーに対してデータ送信を要求し、送信されてきたデータを蓄積するデータ受信手段と、前記欠落データに関する情報に基づいて前記データ受信手段に対して欠落データの受信を実行させる手段と、放送波による取得済みのデータカルーセルと前記データ受信手段により通信路を用いて取得した欠落データとによってコンテンツを完成させる手段と、を備えたことを特徴とする。

上記の構成であれば、欠落データの取得を放送波だけに頼るのではなく、通信路を用いて欠落データを取得することができるので、ＴＹＰＥ２サーバー型放送の受信で欠落データが生じた場合でも、当該欠落データを比較的簡単且つ短い期間で再取得することが可能となる。

上記構成のディジタル放送受信装置において、前記欠落データを放送波を用いて取得する場合にどれくらいの期間を待たなければならないかを放送受信装置側で判断できようにするための付加情報及び、前記欠落データを通信路を用いて取得する場合にどれくらいの期間を待たなければならないかを放送受信装置側で判断できるようにするための付加情報が、放送波に載せられている場合に、当該付加情報を取り出し、この付加情報に基づいて、待つ期間が短いとされた方で前記欠落データを取得するように構成されているのがよい。かかる構成であれば、より早く欠落データを取得できることになる。

これら構成のディジタル放送受信装置において、前記付加情報にサーバー数を示す情報が存在する場合に、放送受信装置固有のＩＤ番号と前記サーバー数を示す情報とに基づいて当該放送受信装置が属すべきグループを判断し、このグループについて割り当てられているサーバーに接続するように構成されているのがよい。かかる構成であれば、一つ或いは幾つかのサーバーにアクセスが集中してしまうのを防止することができる。

これら構成のディジタル放送受信装置において、前記通信路を用いてサーバーに欠落データの伝送を要求するときに、前記欠落データの前後のデータ又は当該データの一部を、前記伝送の要求における認証情報として送出するのがよい。前記欠落データの前後のデータ又は当該データの一部は、ＴＹＰＥ２サーバー型放送を受信していた放送受信装置が取得できるものであり、ＴＹＰＥ２サーバー型放送を受信していない放送受信装置や他の機器が不正にサーバーにアクセスしてデータを取得する事態を、上記データを認証情報として加えることで、防止することができる。

この発明であれば、ＴＹＰＥ２サーバー型放送の受信で欠落データが生じた場合でも、当該欠落データを比較的簡単且つ短い期間で再取得することができる。よって、予約録画などの他の機能への影響を軽減でき、また、待機電力も軽減できるなどの効果を奏する。

以下、この発明の実施形態のディジタル放送受信装置を図１乃至図４に基づいて説明する

図１は、ディジタル放送受信装置３０を示したブロック図である。アンテナ１は地上放送局或いは衛星から送られてくるディジタル放送波を受信する。

チューナ２は、受信した高周波ディジタル変調信号のうちから特定周波数の信号を取り出す。また、チューナ２は、復調回路、逆インタリーブ回路、誤り訂正回路などを備えることにより、選択したディジタル変調信号を復調してトランスポート・ストリーム（ＴＳ）を出力する。

ＴＳセレクタ３は、前記ＴＳをデマルチプレクサ５に与えるとともに、ＴＳ中のスクランブル状態のデータについてはデスクランブラ４に与える。デスクランブラ４は、デスクランブルキーを用いてデスクランブル処理を行い、この処理によって得られたデータをデマルチプレクサ５に与える。

デマルチプレクサ５は、前記ＴＳからＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ２）のビデオストリーム及びオーディオストリームを取り出してＡＶデコーダ６に与える。また、デマルチプレクサ５は、ＴＳからＰＳＩ／ＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ／Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）等を分離してＣＰＵ１６に与える。また、デマルチプレクサ５は、番組の録画時には、ユーザによって選択された番組を構成するデータをＴＳリマックス９に与える。ＴＳリマックス９は受け取った前記データに基づいてトランスポートストリーム（パーシャルＴＳ）を再構築してハードディスクコントローラ１１に与える。

前記ＳＩには、番組情報（番組名、番組開始時刻、番組継続時間、番組内容情報、番組ジャンル情報等）が含まれている。そして、番組情報中のＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）により、番組名称、放送日時、番組内容情報などを取得することができる。

ハードディスクコントローラ１１は、ハードディスクドライブ（ＨＤＤ）１４との間でデータや制御信号のやりとりを行い、ＴＳリマックス（再時分割多重）９から出力されたパーシャルＴＳをＨＤＤ１４に書き込み（記録）、また、ＨＤＤ１４からパーシャルＴＳを読み出すことができる（再生）。読み出されたパーシャルＴＳはＴＳセレクタ３に供給される。

ＡＶデコーダ６は、ビデオストリームに対してデコードを行うビデオデコーダ、及びオーディオストリームに対してデコードを行うオーディオデコーダを備える。ビデオデコーダは、入力された符号化信号を復号して量子化係数や動きベクトルを求め、逆ＤＣＴ変換や動きベクトルに基づく動き補償制御等を行う。オーディオデコーダは、入力された符号化信号を復号して音声データを生成する。

ＯＳＤ回路７は、ＣＰＵ１６から出力指示された文字情報や色情報に基づくビットマップデータを受信映像データに組み込む処理を行う。このＯＳＤ回路７により、ＣＰＵ１６が受け取った前記ＳＩに基づくＥＰＧ（電子プログラムガイド）表示などが行えることになる。

映像表示部（モニタ）１３は、ＯＳＤ回路７から出力される映像データを受け取り、例えば液晶表示パネルに映像を表示する。また、ＮＴＳＣエンコーダ８は、ＯＳＤ回路７から出力される映像データを受け取ってＤ／Ａ変換等を行い、ＮＴＳＣコンポジット信号に変換する。ＮＴＳＣコンポジット信号はスイッチ１０及び映像外部出力部１２を経て外部に出力される。図示しない音声処理回路は、ＡＶデコーダ６から出力された音声データを受け取ってＤ／Ａ変換を行い、例えば右（Ｒ）音のアナログ信号及び左（Ｌ）音のアナログ信号を生成する。

メモリ（ＲＡＭ、ＲＯＭ、ＮＶＲＡＭ（書き換え可能な不揮発性メモリ））１７には、各種制御プログラムやＥＰＧ表示に用いられる番組情報などが格納される。更に、前記ＮＶＲＡＭには、後述する管理データなどが格納される。

また、ディジタル放送受信装置３０は、イーサネットコントローラ１８を備えており、インターネット接続等によって所望のサイトから各種データをダウンロードできるようになっている。

ＣＰＵ１６は、このディジタル放送受信装置３０における全体制御を行うものであるが、特にこの発明にかかる制御として、以下に示すごとく、通信路を用いてサーバー型放送におけるＴＹＰＥ２カルーセルを補完する処理を実行する。

１．ＴＹＰＥ２コンテンツの蓄積
（１） コンテンツのカルーセル伝送
ディジタル放送受信装置３０は、放送波からＴＹＰＥ２コンテンツを取得する。取得されたコンテンツ（データ）は、ＨＤＤ１４に保存される。前記コンテンツがいくつのモジュールから成りどのように構成されているかは、ＤＩＩ（Download Info Indication）メッセージを解析することにより判断可能である。モジュールは複数のＤＤＢ(Download Data Block) メッセージにより構成されるが、同メッセージに含まれる付帯情報により、各ブロックがどのモジュールの何番目のものかを判断できる。１ブロックは付帯情報を除くと最大4,066 バイトで構成され、モジュール分割できるブロックの最大数が65,536個（DDB 内のブロック番号:16bit）であることから、266,469,376 （約245MB ）がモジュールの最大容量となる。例えば、再生時に平均15Mbpsの品位で30分間の再生となるコンテンツの場合、総容量が3,538,944,000 となり、約14個程度のモジュールに分割するか、コンテンツそのものを分割して伝送することになる。

（２） コンテンツの蓄積管理
コンテンツの蓄積に関しては、ＤＩＩのモジュール構成情報から以下に示す判断が可能であり、放送受信装置の一時的な電源断にも対応するため、以下内容をメモリ（ＮＶＲＡＭ）１７又はＨＤＤ１４に保存する。
<DIIによって指し示されるデータ>
・フロックのサイズ
・モジュールの総数（Ｎ）
・モジュール（ｎ）のモジュールID
・モジュール（ｎ）のモジュールサイズ
・モジュール（ｎ）のバージョン番号
なお、ＤＩＩセクション（最大4096バイト）をそのまま保持してもよい。

< 放送受信装置の処理により管理されるデータ>
・モジュール（ｎ）の取得完了状態（２bit ）
例えば、未取得：０ 取得中：１ 取得済：２とする。
・モジュール（ｎ）のブロック（ｍ）の取得完了状態（65,536bit ）
各モジュール単位で8,192 バイト（65,536bit ）の取得状態の管理領域を用意しておく。例えば、ｍbit 目＝ｍブロックとし、０：未取得 １：取得済とする。
・モジュール（ｎ）のブロック（ｍ）のＤＤＢメッセージ

図２のフローチャートは、コンテンツの初回／継続の蓄積処理を示している。ＣＰＵ１６は、コンテンツの取得指示が発生したとき（ステップＳ１）、初回となる取得かどうかを判断し（ステップＳ２）、初回であるときには管理データ（前述した< 放送受信装置処理により管理されるデータ> ）の初期化を行い（ステップＳ４）、ステップＳ５に進む。一方、初回でないときには、前記管理データを読み出す（ステップＳ３）。そして、カルーセルの取得開始（又は継続）を行う（ステップＳ５）。

次に、取得できたブロックが既に取得済のものかそれとも未取得のもの（欠落データ）かを判断する（ステップＳ６）。既に取得済のブロックであればステップＳ５に戻る。一方、未取得のブロックであれば、前記管理データにおいて、データ更新を行う（ステップＳ７）。そして、全てのブロックを取得できたかどうかを判断し（ステップＳ８）、取得できていなければステップＳ５に戻り、全て取得できた場合にはカルーセルの取得を停止する（ステップＳ９）。

上述した処理によれば、放送受信装置の管理データが不揮発性メモリ（ＮＶＲＡＭ）などに保存される。更に、コンテンツの取得開始（再開）時に、保存済の管理データが利用される。これにより、保存中途の状態からの蓄積再開においても、不足分のブロックデータの取得が完了することで再送周期分の待機をする必要はない。すなわち、不足分のブロックデータの取得が完了すれば、それ以降は待機をする必要はない。

ブロックが取得される度に、前記管理データにおいてブロック取得状態を参照し、必要に応じてＨＤＤ１４上の指定領域へブロックデータの転送を行うことが基本であるが、それが処理負荷となる場合には、取得されたある程度のブロックデータを一時的に保存するバッファ領域を設けておき、適切な間隔で起動される処理によってバッファ領域上のデータをＨＤＤ１４に書き込む処理を行う。そして、その書込処理後に前記管理データの更新を行い、この管理データの更新時に全ブロックが取得されたことが判明した場合、取得処理を停止するなどの処理を行うことも可能である。前記適切な間隔は例えばＨＤＤ１４のキャッシュ容量などにより決まる。

２．通信路を用いたブロック単位の取得要求
通信路（network ）を用いたデータ取得においては、欠落データ（欠落ブロック）を提供してくれるサーバーのURL を最低でも特定する必要がある。更には、サーバーへのアクセス許可期間などの概念が追加されるような構造（descriptor）を定義するのがよい。前記descriptorは、コンテンツ取得時に必ず参照するデータテーブル（例として、PMT/DII ）に多重（記述）することが可能である。カルーセルの１周期分のデータ蓄積が終了した後、欠落データを取得するために更に１周期の待機を行うか、それとも前記通信路を用いて欠落データを取得するかの判断基準として、前記descriptorにおける前記許可期間を利用することができる。

以下に、network 経由でのデータ要求の可否に関する制御情報を例示する。

data＿network ＿request ＿availavility＿descriptor()｛
descriptor＿tag : 8 uimsbf
descriptor＿length : 8 uimsbf
numofserver : 8 uimsbf
for( i=0;i<N;i++) ｛
access＿permit＿id : 8 uimsbf
url ＿info＿length : 8 uimsbf
for(j=0;j<M;j++)｛
url ＿data : 8 uimsbf
｝
start ＿time : 40 bslbf
duration : 24 uimsbf
｝
｝

〔各フィールドの意味〕
（１）descriptor＿ tagは、この識別子に一意につけられるＩＤであり、現状の記述子で使用されているＩＤと重複しない範囲で定義する。
（２）num ＿of server は、通信路によってデータ要求に応答するサーバーの数を示す。サーバー毎に個別情報を持っているため、その数を把握する。
（３）access＿permit＿idは、 8bit 値により、アクセスが許可される放送受信装置をグループ分けする。放送受信装置にセットされているカードのＩＤ（番号）を前記サーバー数で除算し、その剰余によって該当するアクセスサーバーが決定される。これにより、サーバーへのアクセス集中（輻輳）を防止し、サーバーの負荷軽減が図れる。access＿permit＿idの値がサーバー数を超えているときには、全ての放送受信装置にサーバーへのアクセス許可が与えられる。
（４）url ＿info＿lengthは、サーバに対してアクセスを行う際のアドレス情報の長さを示す。
（５）url ＿dataは、サーバアドレス情報を示す。
（６）start ＿timeは、アクセスが可能な開始期間を示す。
（７）durationは、アクセスが可能な期間を示す。

なお、ＣＰＵ１６は、上述した記述子が該当テーブルに記載されていない場合には、通信路を利用したデータ提供はないものと判断する。

ＴＹＰＥ２コンテンツに関して、各ブロックの再送周期は同一のブロックの受信間隔から判断することも可能である。ただし、再送周期を知るためには、同一ブロックが次に送信されてくるまでの時間を要することになる。一方、ＤＩＩ中に再送に関する条件を記述するテーブルを設けておけば、放送受信装置側での処理がより簡単且つ短時間で行えることになる。ただし、現状では、ダウンロードを開始してからのタイムアウト時間がＤＩＩに記述されているが、32bit の値（μsec ）のため、最大値として１時間強の期間しか記載できない。従って、再送に関して何らかの定義（例えば、μsec をsec にするなど）が必要になる場合があると考えられる。以下に、ＴＹＰＥ２コンテンツの伝送周期に関する情報記述を示す。

data＿retransmission＿schedule＿descriptor () ｛
descriptor＿tag : 8 uimsbf
descriptor＿length : 8 uimsbf
retransmission＿num : 8 uimsbf
start ＿time : 40 bslbf
if (contents ＿retransmission＿num ! = 0 )｛
duration : 24 uimsbf
cycle＿time : 24 uimsbf
｝
｝

（１）retransmission＿num は、コンテンツの再送回数を示す。
（２）start ＿timeは、伝送を開始する日時を示す。伝送を開始する日時は、通常ＥＩＴで提供される番組の開始時間と同一と考えられるが同一とは限らない。このため、ＥＩＴを伝送しないチャンネルや番組開始時刻からの伝送時間が前記タイムアウト時間以上離れている場合に記述することが必要である考えられる。その他の場合は全てのビットを１とする。すなわち、全てのビットが１である場合には、伝送を開始する日時はＥＩＴで提供される番組の開始時間と同一であると受信装置側で判断することになる。
（３）durationは、コンテンツの１周期のうちの伝送に使われる時間を示す。
（４）cycle ＿timeは、同一ブロックの再送間隔（１周期）を示す。この値から、上記durationを減算することにより、最後のブロックを送出してからのデータの無送出期間を放送受信装置側で判断することができる。

放送波と通信路のどちらを用いてデータ取得を行うのがよいかの判断処理を含む処理内容を図３のフローチャートに基づいて説明していく。まず、放送波からカルーセルを取得する処理を開始し（ステップＳ１１）、コンテンツの１周期の送出完了を認識し（ステップＳ１２）、全てのデータを取得できた場合は（ステップＳ１３でＹＥＳ）、カルーセルの取得を停止し（ステップＳ１４）、コンテンツの構築処理を行う（ステップＳ１５）。放送波から全てのデータを取得できなかった場合は、通信路を用いてデータを取得することが可能かどうかを判断する（ステップＳ１６）。通信路を用いてデータを取得することが可能でない場合には、カルーセルの取得継続（待機）を行い（ステップＳ１７）、ステップＳ１２に戻る。一方、通信路を用いてデータを取得することが可能である場合には、放送波を用いてデータを取得するほうが早いのかどうかを判断する（ステップＳ１９）。例えば、サーバーへのアクセスが可能な開始期間（start ＿time）やアクセスが可能な期間（duration）に基づいた、サーバーからデータを取得できるようになる期間と、放送波における最後のブロックを送出してからのデータの無送出期間とを比較して、期間が短い方を「早い」と判断する。放送波を利用する方が早い場合にはステップＳ１７に進む。一方、通信路を利用する方が早い場合には、通信サーバーに対して該当データ（欠落データ）を要求し（ステップＳ２０）、全て取得できたかどうかを判断し（ステップＳ２１）、全て取得できたときには、ステップＳ１４に進む。

３．サーバーとのブロックデータ要求プロトコル

欠落データに関する情報は放送受信装置側で管理しているので、そのデータの指定方法とデータの受け渡し方法が再送信用のサーバーと放送受信装置との間で決まっていれば、一般的なインターネット通信で使用されているどのような通信プロトコル（http等）を用いても問題はない。

図４にクライアントとサーバーとの間で遣り取りされる処理（プロトコル）を示す。

まず、放送受信装置からサーバーへのコマンドを示す。

（１）データ要求開始
データ要求の開始後（ステップＳ２１）、サーバーからのデータ要求開始受諾を待機する（ステップＳ２２）。
START:
CARD＿ID(0x????????????)：

（２）指定データ要求
指定データをモジュールＩＤ及び／又はブロックＩＤで指定し（ステップＳ２３）、指定データ要求受諾を待機する（ステップＳ２４）。ブロックＩＤとして開始ＩＤと終了ＩＤとを指定可能とする場合には、連続性のある一纏まりのブロック群を取得できることになる。また、要求ブロックの範囲の直前又は直後のデータのCRC32 を認証コードとして加えるのがよい。前記CRC32 はＴＹＰＥ２サーバー型放送を受信していた放送受信装置が取得できるものであり、ＴＹＰＥ２サーバー型放送を受信していない放送受信装置や他の機器が不正にサーバーにアクセスしてデータを取得する事態を、上述のごとくCRC32 を認証コードとして加えることで、防止することができる。なお、要求ブロックの範囲の直前又は直後のデータの一部を認証コードとして用いてもよい。
REQUEST:
Module＿id(0x????)
StartCRC(0x????????):StartBlockID(0x????):EndblockID(0x????) : EndCRC(0x????????) :

放送受信装置は、上記の指定データ要求の後、サーバーからのブロックデータを受諾する（ステップＳ２４）。受信するデータは4096バイト（セクション）単位とする。その後、放送受信装置は、全ての欠落データを取得することができたかどうかを判断し（ステップＳ２６）、取得できていなければ指定データ応答受諾処理を行い（ステップＳ２７）、取得できたときにはデータ要求終了処理を行う（ステップＳ２８）。

（３）指定データ応答受諾
送信されたデータを受諾したことをサーバに通知する。
ACCEPT:
module＿id(0x????):
AcceptBlockID(0x????):

（４）データ要求終了
サーバーに対して、データ補完処理が終了したことを通知する。
END:

以下に、サーバーから放送受信装置へのコマンドを示す。

（５）データ要求開始受諾
クライアント（放送受信装置）からのデータ要求開始に応答する（ステップＳ３１）。不正なCARDID等の判断を行うことや、登録されているユーザに対してのみ応答を行うことなど再送サーバー側の機能としても有効である。
ACCEPT : START :

（６）指定データ要求受諾
指定データの整合性を判断し（ステップＳ３２）、クライアントからのデータ要求に応答する。
ACCEPT : REQUEST :

サーバーは、送信データのインデックス初期化を行う（ステップＳ３３）。

（７）データ送信
指定されたモジュールＩＤ、ブロックＩＤのデータを送信する（ステップＳ３４）。
SEND: length (0xFFF) : 0x????????

サーバーは、放送受信装置から指定データ応答受諾の受諾又はデータ要求終了の通知がくるのを待ち（ステップＳ３６）、受諾であれば送信データのインデックス加算を行い（ステップＳ３５）、ステップＳ２４に進んで次のデータを送信する。一方、終了であれば、データ送信を終了する（ステップＳ３７）。

以上説明したように、放送波と通信路の融合システムを構築することにより、長い周期で伝送される欠落カルーセルの伝送を待たなくともコンテンツが完成する。カルーセルの欠落の度合いによっては視聴に適さない状態となることも十分考えられ、課金の有無を含めて、蓄積済みＴＹＰＥ２コンテンツは必ず補完する必要があり、ブロードバンドが全盛の現在においては有効な補完方法の一つと考えられる。またそれ以外の効果として、放送受信装置の待機電力の削減や複数のコンテンツの効率的な取得にも寄与できる。衛星放送波などによる伝送においては、天候の影響を受けやすく、同地方で同時に複数の放送受信装置が蓄積コンテンツを取得できない状態になると思われるが、コンテンツの全てを用意する必要はなく、天候異常などを認識した段階で通信サーバに欠落が予想される部分だけに限定したデータを用意するなど、サーバー側の負担もある程度の範囲に抑えられると考えられる。

この発明の実施形態のディジタル放送受信装置を示したブロック図である。 処理内容を示したフローチャートである。 処理内容を示したフローチャートである。 処理内容を示したフローチャートである。 データカルーセルを示した説明図である。 ＤＩＩを示した説明図である。

符号の説明

２ ディジタルチューナ
６ ＡＶデコーダ
１４ ハードディスクドライブ
１６ ＣＰＵ
１７ メモリ
１８ イーサネットコントローラ

Claims (4)

1. 取得日時と再生日時が異なり且つ取得期間と再生期間が異なる、カルーセルによるコンテンツ伝送であるＴＹＰＥ２サーバー型放送を受信し、受信したデータカルーセルを蓄積するディジタル放送受信装置において、蓄積済みのデータカルーセル中に欠落データが存在するかどうかを判断し、欠落データに関する情報を生成して蓄積する手段と、サーバーに接続するのに必要となる情報を放送波に載せられている付加情報から取得する手段と、通信路を用いて前記サーバーに対してデータ送信を要求し、送信されてきたデータを蓄積するデータ受信手段と、前記欠落データに関する情報に基づいて前記データ受信手段に対して欠落データの受信を実行させる手段と、放送波による取得済みのデータカルーセルと前記データ受信手段により通信路を用いて取得した欠落データとによってコンテンツを完成させる手段と、を備えたことを特徴とするディジタル放送受信装置。
2. 請求項１に記載のディジタル放送受信装置において、前記欠落データを放送波を用いて取得する場合にどれくらいの期間を待たなければならないかを放送受信装置側で判断できようにするための付加情報及び、前記欠落データを通信路を用いて取得する場合にどれくらいの期間を待たなければならないかを放送受信装置側で判断できるようにするための付加情報が、放送波に載せられている場合に、当該付加情報を取り出し、この付加情報に基づいて、待つ期間が短いとされた方で前記欠落データを取得するように構成されたことを特徴とするディジタル放送受信装置。
3. 請求項１又は請求項２に記載のディジタル放送受信装置において、前記付加情報にサーバー数を示す情報が存在する場合に、放送受信装置固有のＩＤ番号と前記サーバー数を示す情報とに基づいて当該放送受信装置が属すべきグループを判断し、このグループについて割り当てられているサーバーに接続するように構成されたことを特徴とするディジタル放送受信装置。
4. 請求項１乃至請求項３のいずれかに記載のディジタル放送受信装置において、前記通信路を用いてサーバーに欠落データの伝送を要求するときに、前記欠落データの前後のデータ又は当該データの一部を、前記伝送の要求における認証情報として送出することを特徴とするディジタル放送受信装置。

Images