(57)【特許請求の範囲】
【請求項１】
ディジタル信号処理に必要な機能としてブロック化された複数のディジタル信号処理ブロック及びホスト演算処理ブロックと、
上記ホスト演算処理ブロックと上記複数のディジタル信号処理ブロックとの間を繋ぐバスと、
上記バスに接続された拡張機能提供媒体のインターフェースとを有し、
上記ディジタル信号処理ブロックは、上記バスを介して送られてきたコマンドを解釈して実行する手段を含み、
上記拡張機能提供媒体は、拡張機能を実現するための手段と、上記拡張機能を動作させるための上位レイヤのコマンドが埋め込まれたスクリプトと、上記上位レイヤの上記コマンドを解釈するドライバとを含み、
上記拡張機能提供媒体が上記インターフェースを介して上記バスに装着されると、上記スクリプトが上記ホスト演算処理ブロック側に送られ、上記ホスト演算処理ブロックから送られた上記上位レイヤの上記コマンドが上記ドライバによって解釈され、上記拡張機能を実現するための手段は解釈された上記コマンドに基づいて動作するディジタルテレビジョン受信機。
【請求項２】
上記スクリプトは、Ｊａｖａ言語によって記述されている請求項１記載のディジタルテレビジョン受信機。
【請求項３】
上記コマンドは、ハイパーテキストのスクリプト中に埋め込まれて記述されており、上記ハイパーテキストがブラウザで解釈され、上記拡張機能を操作するための画像が表示されると共に、上記拡張機能を操作するための画像中にこの機能に対応するコマンドが埋め込まれて表示される請求項１記載のディジタルテレビジョン受信機。
【請求項４】
ディジタル信号処理に必要な機能を、複数のディジタル信号処理ブロック及びホスト演算処理ブロックとにブロック化し、
上記ホスト演算処理ブロックと上記複数のディジタル信号処理ブロックとの間をバスで繋ぐと共に、
上記バスに対して拡張機能提供媒体のインターフェースを設け、
上記ディジタル信号処理ブロックは、上記バスを介して送られてきたコマンドを解釈して実行し、
上記拡張機能提供媒体は、拡張機能を実現するための手段と、上記拡張機能を動作させるための上位レイヤのコマンドが埋め込まれたスクリプトと、上記上位レイヤの上記コマンドを解釈するドライバとを含み、
上記拡張機能提供媒体が上記インターフェースを介して上記バスに装着されると、上記スクリプトが上記ホスト演算処理ブロック側に送られ、上記ホスト演算処理ブロックから送られた上記上位レイヤの上記コマンドが上記ドライバによって解釈され、上記拡張機能を実現するための手段は解釈された上記コマンドに基づいて動作するディジタルテレビジョン受信機における拡張機能提供方法。
【請求項５】
上記スクリプトは、Ｊａｖａ言語によって記述されている請求項４記載のディジタルテレビジョン受信機における拡張機能提供方法。
【請求項６】
上記コマンドは、ハイパーテキストのスクリプト中に埋め込まれて記述されており、上記ハイパーテキストがブラウザで解釈され、上記拡張機能を操作するための画像が表示されると共に、上記拡張機能を操作するための画像中にこの機能に対応するコマンドが埋め込まれて表示される請求項４記載のディジタルテレビジョン受信機における拡張機能提供方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、衛星を使ったディジタル放送や地上波のディジタル放送を受信するためのディジタルテレビジョン受信機、並びにディジタルテレビジョン受信機における拡張機能提供方法に関するもので、特に、効率的な設計が行え、設計変更が容易であると共に、新たなサービスの追加や機能アップに容易に対応できるようにしたものに係わる。
【０００２】
【従来の技術】
テレビジョン放送は、アナログ方式からディジタル方式に移行しつつある。現在、ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ）衛星を使ったディジタル衛星放送のサービスが開始されている。また、ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓａｔｅｌｌｉｔｅ）衛星を使ったディジタル衛星放送の開始準備が進められている。更に、地上波テレビジョン放送についても、ディジタルで行うことが予定されている。
【０００３】
ディジタルテレビジョン放送では、周波数使用効率が向上されるため、多チャンネル化を図ったり、ＨＤＴＶ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅｖｉｓｉｏｒ）放送を行うことが容易にできる。また、ディジタルテレビジョン放送では、双方向サービスやデータ配信サービス、ビデオオンデマンド等、従来のアナログ放送では実現できなかったような種々のサービスが実現できる。
【０００４】
このようなディジタルテレビジョン放送を受信するテレビョンは、従来、図１に示すように構成されている。
【０００５】
図１において、入力端子１０１からチューナ回路１０２に、受信信号が供給される。例えば、ＣＳディジタル放送の場合には、１２ＧＨｚ帯で送られてきた信号がパラボラアンテナ（図示せず）で受信され、この信号がパラボラアンテナに取り付けられた低雑音コンバータで１ＧＨｚ帯の信号に変換されて、チューナ回路１０２に供給される。チューナ回路１０２で、この受信信号の中から所望のチャンネルの搬送波周波数の信号が選択され、この所望のチャンネルの搬送波周波数の信号に対して、復調処理及びエラー訂正処理がなされる。これにより、ビデオパケットとオーディオパケットとからなるトランスポートストリームが復号される。
【０００６】
チューナ回路１０２の出力はデマルチプレクサ１０３に供給される。デマルチプレクサ１０３で、このトランスポートストリームから、ビデオパケットとオーディオパケットとが分離される。ビデオパケットはビデオデコーダ１０４に供給され、オーディオパケットはオーディオデコーダ１０５に供給される。ビデオデコーダ１０４で、例えば、ＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式でビデオデータの伸長処理が行われ、ビデオデータがデコードされる。また、オーディオデコーダ１０５で、例えば、ＭＰＥＧ方式でオーディオデータの伸長処理が行われ、オーディオデータがデコードされる。ビデオデコーダ１０４でデコードされたビデオデータは、グラフィックス処理回路１０６に供給される。グラフィックス処理回路１０６で、画像処理が行われる。グラフィックス処理回路１０６の出力が出力端子１０７から出力される。オーディオデコーダ１０５の出力が出力端子１０８から出力される。
【０００７】
チューナ回路１０２、デマルチプレクサ１０３、ビデオデコーダ１０４、オーディオデコーダ１０５、グラフィックス処理回路１０６に対する制御は、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）１１１により行われる。ＭＰＵ１１１からはバス１１１が導出されており、バス１１０に、チューナ回路１０２、デマルチプレクサ１０３、ビデオデコーダ１０４、オーディオデコーダ１０５、グラフィックス処理回路１０６が接続される。また、バス１１０には、課金処理のためのモデム１１２、外部機器との間でストリームをやり取りするための例えばＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）１３９４のインターフェース１１３が設けられる。
【０００８】
上述のように、従来のディジタルテレビジョン放送の受信機では、ＭＰＵが機器全体の制御を行っている。そして、このＭＰＵは、各部のハードウェアの細かいタイミングレベルまで考慮し、各部のハードウェア毎のコマンドを使って集中制御を行っている。
【０００９】
ところが、各ハードウェアを考慮して、ＭＰＵで全体制御を集中管理するような手法は、機器毎に設計を開始しなければならないため、設計変更に伴って大幅なソフトウェアの書き換えやハードウェアの変更が余儀なくされ、開発効率が悪い。また、部品の共通化やモジュール化を難しくなるため、結局、コストアップになったり、機器の小型化が困難になる場合がある。また、ディジタルテレビジョン放送では、各種のサービスが行われており、ＭＰＵで全体制御を集中管理するような手法では、新たなサービスに対応することが困難である。
【００１０】
そこで、テレビジョン受信機に必要な機能をブロック化し、共通のバスで繋ぐことが考えられる。このようなバスを用いると、設計効率が向上すると共に、設計変更が容易である。
【００１１】
また、バスが標準化されると、このバスに拡張機能を提供するためのハードウェアを追加して、新たなサービスを利用できるようにしたりすることが行える。例えば、拡張機能を提供するために、拡張プラグインカードを用意し、この拡張プラグインカードをインターフェースを介してバスに装着すると、様々な機能やサービスを新たに追加できるようにすることが考えられる。
【００１２】
【発明が解決しようとする課題】
ところが、バスに拡張機能を提供するためのハードウェアを追加しても、そのハードウェアを機能させるために、ホストＭＰＵにそのハードウェアを認識させ、ホストＭＰＵがそのハードウェアに対してコマンドを与えられるようにする必要がある。ホストＭＰＵがそのハードウェアに対してコマンドを与えられるようにするためには、ソフトウェアをインストールしなければならないことがある。
【００１３】
このようなソフトウェアのインストール作業は、特に、テレビジョン受信機のような一般的なユーザにとっては、困難な作業である。したがって、この発明の目的は、必要な機能をブロック化し、標準化されたバスで繋ぐようにした装置で、拡張機能を提供するためのハードウェアを簡単にバスに接続できるようにしたディジタルテレビジョン受信機およびディジタルテレビジョン受信機における拡張機能提供方法を提供することにある。
【００１４】
【課題を解決するための手段】
この発明は、ディジタル信号処理に必要な機能としてブロック化された複数のディジタル信号処理ブロック及びホスト演算処理ブロックと、ホスト演算処理ブロックと複数のディジタル信号処理ブロックとの間を繋ぐバスと、バスに接続された拡張機能提供媒体のインターフェースとを有し、ディジタル信号処理ブロックは、バスを介して送られてきたコマンドを解釈して実行する手段を含み、拡張機能提供媒体は、拡張機能を実現するための手段と、拡張機能を動作させるための上位レイヤのコマンドが埋め込まれたスクリプトと、上位レイヤのコマンドを解釈するドライバとを含み、拡張機能提供媒体がインターフェースを介してバスに装着されると、スクリプトがホスト演算処理ブロック側に送られ、ホスト演算処理ブロックから送られた上位レイヤのコマンドがドライバによって解釈され、拡張機能を実現するための手段は解釈されたコマンドに基づいて動作するディジタルテレビジョン受信機である。
【００１５】
この発明は、ディジタル信号処理に必要な機能を、複数のディジタル信号処理ブロック及びホスト演算処理ブロックとにブロック化し、ホスト演算処理ブロックと複数のディジタル信号処理ブロックとの間をバスで繋ぐと共に、バスに対して拡張機能提供媒体のインターフェースを設け、ディジタル信号処理ブロックは、バスを介して送られてきたコマンドを解釈して実行し、拡張機能提供媒体は、拡張機能を実現するための手段と、拡張機能を動作させるための上位レイヤのコマンドが埋め込まれたスクリプトと、上位レイヤのコマンドを解釈するドライバとを含み、拡張機能提供媒体がインターフェースを介してバスに装着されると、スクリプトがホスト演算処理ブロック側に送られ、ホスト演算処理ブロックから送られた上位レイヤのコマンドがドライバによって解釈され、拡張機能を実現するための手段は解釈されたコマンドに基づいて動作するディジタルテレビジョン受信機における拡張機能提供方法である。
【００１６】
【発明の実施の形態】
以下、この発明の実施の形態について図面を参照して説明する。この発明の実施の形態では、ディジタルテレビジョン受信機に必要な要素をブロック化し、各ブロック間をバスで結合して、ディジタルテレビジョン受信機を構成するようにしている。
【００１７】
このように、ディジタルテレビジョン受信機に必要な要素をブロック化し、各ブロック間をバスを介して接続するようにすると、ブロックを交換するだけで、搬送波や、変調方式、圧縮方式の異なる様々なディジタルテレビジョン放送に対応できる。このため、開発効率が向上する。また、新しいサービスが始まったときに、ハードウェアを追加してそのサービスに対応できるようにすることが簡単に行える。
【００１８】
第２図は、このように、ディジタルテレビジョン受信機に必要な要素をブロック化し、各ブロックをバスで接続して構成するようにしたディジタルテレビジョン受信機の基本的な構成を示すものである。第２図において、ディジタルテレビジョン受信機１は、ディジタルテレビジョン受信機に必要なブロック１１、１２、１３、１４、１５、１６を、バス１０に繋いで構成される。ここでは、ディジタルテレビジョン受信機に必要なブロックとして、ホストＭＰＵブロック１１、ＡＶ信号処理ブロック１２、フロントエンドブロック１３、インターフェースブロック１４、プラグインインターフェースブロック１５、内蔵フィーチャブロック１６がバス１０に繋がれている。
【００１９】
ホストＭＰＵブロック１１は、受信機全体の制御をするものである。ＡＶ信号処理ブロック１２は、ビデオストリーム及びオーディオストリームの伸長処理、グラフィック処理を行うものである。フロントエンドブロック１３は、受信したテレビジョン放送の中から所望のチャンネルの搬送波の信号を選択し、その信号に対して、復調処理、エラー訂正処理等を行って、ビデオストリーム及びオーディオストリームをデコードするものである。インターフェースブロック１４は、ＩＥＥＥ１３９４のような外部機器と接続するためのインターフェースである。プラグインインターフェースブロック１５は、機能拡張用を接続するためのインターフェースである。内蔵フィーチャブロック１６は、その他の内蔵される必要な機能を実現するためのものである。
【００２０】
バス１０には、ビデオデータやオーディオデータのような時間的に連続するストリームと、コマンドやデータが転送される。コマンドは、タイミングを規定したり、ハードウェアを直接制御するような低レベルのレイヤのコマンドではなく、リアルタイム性が要求されず、ハードウェア構成を意識しない高レベルのレイヤのコマンドが用いられる。例えば、フロントエンドブロック１３に対して「何チャンネルの周波数を受信せよ」というようなコマンドを与えたり、ＡＶ信号処理ブロック１２に対して、「画面を拡大或いは縮小せよ」、「円を描け」というような、汎用性の高いスクリプト形式のコマンドである。例えば、ハイパーテキストでスクリプトを記述すると、このような動作が簡単に実現できる。
【００２１】
すなわち、第３図に示すように、アップダウンキー２０１Ａ、２０１Ｂや拡大縮小キー２０１Ｃ、２０１Ｄを表示し、これらの表示２０１Ａ〜２０１Ｅに対応するコマンドＣＭＤ１〜ＣＭＤ４が埋め込まれたスクリプトをハイパーテキストで作成する。このようなスクリプトを表示させると、第３図に示すような画面がブラウザの画面上に表示される。ここで、チャンネルアップダウンボタンや画面の拡大縮小を行うための表示２０１Ａ〜２０１Ｄがクリックされると、対応するコマンドＣＭＤ１〜ＣＭＤ４が発生される。ブロック１１〜１６の中でこのコマンドを受け付けられるブロックにそのコマンドが送られる。コマンドを受け取ったブロックでは、このコマンドに対応する処理が行われる。更に、複雑な処理を行なわせる場合には、ＪＡＶＡ等を用いれば良い。勿論、この発明は、ハイパーテキストを用いたり、ＪＡＶＡを用いたりすることに限定されるものではない。
【００２２】
また、バス１０の物理的な形態は標準化されている。ブロック１１、１２、１３、１４、１５、１６は、この標準化された規格に合うように設計されている。これらのブロック１１〜１６のうち、ホストＭＰＵブロック１１やインターフェースブロック１４、プラグインインターフェースブロック１５のような基本となるブロックは、マザーボード上に配置し、その他のブロック１２、１３、１６は、ドウタボードとしておき、これら他のブロック１２、１３、１６を標準化されたバスに接続する構成が考えられる。また、各ブロック１１、１２、１３、１４、１５、１６を集積回路化又はモジュール化するようにしても良い。
【００２３】
なお、上述の例では、ホストＭＰＵブロック１１と、ＡＶ信号処理ブロック１２と、フロントエンドブロック１３と、インターフェースブロック１４と、プラグインインターフェースブロック１５と、内蔵フィーチャブロック１６とに分割しているが、ブロックの分割のやり方は、これに限るものではない。
【００２４】
また、勿論、各ブロックをボード上に配置する際に、１つのブロックを１つの基板で構成する必要はなく、機能的に２以上のブロックを１つの基板上に配置するようにしても良い。例えば、ホストＭＰＵブロック１１と、インターフェースブロック１４とを１つの基板上に配置するようにしても良い。勿論、１つのブロックを複数の基板で構成するようにしても良い。
【００２５】
各ブロック１１、１２、１３、１４、１５、１６は、バス１０を介して送られてきたコマンドを解釈し、コマンドに対する処理を実行したり、バス１０を介して送られてきたストリームやデータを処理したりする。ハードウェアの依存性が小さいコマンドがバス１０を介して送られてくるため、各ブロック１２、１３、１４、１５、１６は、このコマンドを解釈して処理できるように、多くの場合、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。各ブロック１２、１３、１４、１５、１６のＣＰＵで、送られてきたコマンドが解釈され、そのコマンドに対応する処理が実行される。送られてきたコマンドに対してハードウェアを動作させるためのドライバは、各ブロック１２、１３、１４、１５、１６内に収められており、ハードウェアに強く依存する部分は、そのブロック内で処理が完結するようにしている。
【００２６】
つまり、第４図に概念図で示すように、ホストＭＰＵのブロック１１側には、汎用性が高くハードウェアに依存しないを上位レベルのコマンドで処理を行うために、ハイレベルインターフェースＨＩＦが設けられている。これに対して、各ブロック１２、１３、１４、１５側には、この上位レベルのコマンドを解釈して、よりハードウェアに近い処理を行えるようにするドライバＤＲＶと、実際のハードウェアに対して直接制御するためのローレベルインターフェースＬＩＦが備えられている。ホストＭＰＵのブロック１１側からは、ハイレベルインターフェースＨＩＦを介して、上位レベルのコマンドが送られ、バス１０を介して、各ブロックに転送される。各ブロックのドライバＤＲＶで、この上位レベルのコマンドが解釈され。この場合、ハードウェアに依存する部分は、全て、各ブロック１２、１３、１４、１５のドライバＤＲＶで吸収される。
【００２７】
これに対して、第５図に示すように、ホストＭＰＵのブロック１１側に、ドライバＤＲＶを搭載するという考えかたもある。ところが、第５図に示すようにすると、新たなハードウェアが付加されたり、ハードウェアが変更された場合には、新たなドライバＤＲＶをインストールしたり、ドライバＤＲＶを変更したりしなければならなくなる。
なお、このバス１０には、ビデオデータやオーディオデータのストリームのような高速のストリームと、コマンドやデータのようなリアルタイム性が要求されないデータが転送される。このような性質の異なるデータを転送できるバスとしては、ビデオデータやオーディオデータのような高速性が要求されるストリームを送る帯域と、コマンドのようなリアルタイム性が要求されないデータを送る帯域とを分割してデータを伝送する構成のものを用いることができる。また、データにプライオリティが付けられるようにし、ビデオデータやオーディオデータのストリームに対してはプライオリティを上げることにより、ビデオデータやオーディオデータのストリームを高速で送れるようにしたものを用いるようにしても良い。
【００２８】
また、バス１０に送られるコマンドは、タイミング制御のようなリアルタイム性を要求されるものではなく、スクリプト形式であるため、伝送量も極力抑えられている。このため、同一のバス１０で、コマンドと、ビデオデータやオーディオデータのストリームとを送ることができる。
【００２９】
このように、各ブロック１１、１２、１３、１４、１５、１６をバス１０で繋ぎ、バスを介して、コマンドやストリーム、データをやり取りするようにして、ディジタルテレビジョン受信機を構成すれば、各種の方式のテレビジョン放送に簡単に対応させることができ、開発環境が大幅に向上する。
【００３０】
例えば、地上波ディジタル放送が始まったときには、新たに、地上波ディジタル放送を受信するためのテレビジョン受信機を開発していく必要がある。ところが、新たに地上波ディジタル放送のサービスが開始されるのに伴って、そのための受信機を始めから設計するのでは開発効率が悪い。
【００３１】
既存のディジタル衛星放送と、地上波ディジタル放送とでは、使用される搬送波周波数や変調方式、エラー訂正方式、トランスポートストリームの構成等が異なっているが、他の方式が同じであるとすれば、ＡＶ信号処理ブロック１２及びフロントエンドブロック１３のみ、地上波ディジタル放送用のものを開発すれば良い。すなわち、この場合には、新たに地上波ディジタル放送のサービスが開始されるのに伴って、地上波ディジタル放送用のＡＶ信号処理ブロック１２Ａ及びフロントエンドブロック１３Ａを開発し、ＡＶ信号処理ブロック１２及びフロントエンドブロック１３のみ地上波ディジタル放送用のＡＶ信号処理ブロック１２Ａ及びフロントエンドブロック１３Ａに交換すれば、新たに開始される地上波ディジタル放送に対応でき、受信機を始めから設計し直す必要はない。その他、異なる部分があるとしても、異なる部分のブロックだけ新たに開発すれば良い。また、動作の変更は、ホストＭＰＵブロック１１のアプリケーションプログラムを変更することで対応できる。
【００３２】
同様にして、例えば、ヨーロッパの衛星で放送されているディジタルテレビジョン放送に対応する受信機や、アメリカのＣＡＴＶで放送されているディジタルテレビジョン放送に対応する受信機を、受信機を始めから設計し直すことなく、容易に実現していくことができる。
【００３３】
また、ＣＳディジタル放送では、課金処理のために、モデムが装着され、電話回線を介して、管理会社と接続できるようになっている。このような場合は、内蔵フィーチャ１６として、モデム１６Ａが装着される。このように、その放送のサービスを受けるのに必要な機器は、内蔵フィーチャブロック１６として、簡単に装着できる。
【００３４】
更に、音楽データをダウンロードできるようなサービスや、ビデオオンデマンドのサービス、その他、種々のサービスが考えられており、新たなサービスを受けるために、ハードウェアを追加したい場合がある。この場合には、プラグンインターフェースブロック１５に装着される機器として、そのハードウェアを追加できる。
【００３５】
なお、ブロックを差し替えたり、プラグインインターフェース１５に新たな機器が装着されるような場合に、ドライバが必要な場合がある。このドライバは、ブロック内のメモリやプラグインインターフェース１５に装着される機器のメモリ中の含めておき、ブロックが差し替えられたり、プラグインインターフェース１５に機器が装着されるときに、自動的にインストールさせるようにすると、使い勝手が向上する。
【００３６】
また、第６図に示すように、ブロックが差し替えられたり、プラグインインターフェース１５に機器が装着されるときに、電話回線によりサービスセンターを呼び出し、サービスセンターからドライバをダウンロードさせるようにしても良い。
【００３７】
すなわち、第６図において、ブロックが差し替えられたり、プラグインインターフェース１５に新たな機器が装着されたか否かが判断される（ステップＳ１０１）。ブロックが差し替えられたり、プラグインインターフェース１５に新たな機器が装着された場合には、差し替えられた機器や新たな機器の種類が認識される（ステップＳ１０２）。そして、サービスセンターが電話で呼び出される（ステップＳ１０３）。サービスセンターは、呼び出しを受け付けると、その機器の種類に対応するドライバのソフトウェアを電話回線を介して送る。このドライバのソフトウェアがダウンロードされる（ステップＳ１０４）。更に、ドライバのソフトウェアをディジタル衛星放送やディジタル地上波放送の信号からダウンロードできるようにしても良い。勿論、ドライバのインストールが必要となるのは、第４図に示したように、各ブロック内にドライバを設ける構成とした場合であって、第５図で説明したように、各ブロックに対するコマンドを上位のレイヤのコマンドとしたときには、ドライバのインストールは不要である。しかしながら、この場合であっても、ハードウェアに依存する部分のソフトウェアの変更等で、ドライバのインストールが必要な場合が想定される。
【００３８】
以上のように、ディジタルテレビジョン放送は、衛星、地上波、ＣＡＴＶ網、電話回線等、種々の伝送媒体を介して放送されており、ディジタルテレビジョン放送で使用される搬送波や、変調方式、圧縮方式は、使用される伝送媒体、放送を行っている国や地域、放送を行っている会社等により、種々、様々に異なっている。更に、ディジタルテレビジョン放送では、ＨＤＴＶ放送を行ったり、データ伝送サービスやビデオオンデマンドのサービスを行った等、各種のサービスが考えられている。このため、各伝送媒体や、地域、サービス等に応じたディジタルテレビジョン放送の受信機を開発していかなければならない。上述のように、テレビジョン受信機の各機能を実現するためのブロックを標準化されたバスに繋ぐような構成とし、このバスを介して、ビデオデータやオーディオデータのようなストリームと、コマンドとをやり取りできるようにすれば、テレビジョン受信機の開発効率が向上すると共に、各種のテレビジョン受信機を今後開発されていく新たなサービスに対応していくことが容易にできるようになる。
【００３９】
第７図は、このようなテレビジョン受信機の具体的な構成の一例である。第７図において、ホストＭＰＵ２１からは、内部バス２２が導出されており、このバス２２に、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２３が接続される。また、バス２２には、機能拡張のために、追加ロジック２４を接続できる。ＲＯＭ２３には、テレビジョン受信機の全体を動作させるためのアプリケーションプログラムが内蔵されている。また、ホストＣＰＵ２１には、ＳＤＲＡＭ２５が接続される。このＳＤＲＡＭ２５には、ユーザの固有情報や各種の設定情報が格納される。ホストＣＰＵ２１は、バスコントローラ２６を介して、バス３０に接続される。
【００４０】
バス３０は、ビデオデータやオーディオデータのような時間的に連続するストリームと、コマンドやデータを送るためのものである。コマンドとしては、ハードウェアに依存せず、リアルタイム性が要求されない、上位レイヤのコマンドが用いられる。バス３０には、ＡＶ信号処理ブロック３１、フロントエンドブロック３２、外部インターフェースブロック３３、内蔵フィーチャブロック３４が接続される。また、バス３０には、プラグインインターフェース３５が設けられる。プラグインインターフェース３５には、拡張プラグインカード３６が装着可能とされる。なお、ホストＭＰＵ２１からなる部分をマザーボード上に配置し、各ブロック３１、３２、３３、３４をドウタボード上で構成し、その物理的な形状や端子の配置を決めておき、ホストＭＰＵ２１からなるマザーボード上に、各ブロック３１、３２、３３、３４のドウタボードを着脱できるようにして実現しても良い。また、ブロック３１、３２、３３、３４をモジュール化或いは集積回路化しても良い。
【００４１】
ホストＭＰＵ２１と、各ブロック３１、３２、３３、３４及び拡張プラグインカード３６間で、バス３０を介して転送されるデータは、バスコントローラ２６により管理される。データの転送は、ホストＭＰＵ２１を介さず、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）制御により、各ブロック３１、３２、３３、３４、及び拡張プラグインカード３６間で、直接行うことができる。更に、データの転送は、１つのブロックから１つのブロックへの転送と共に、１つのブロックから複数のブロックへの転送、すなわち、ブロードキャストが可能である。ブロードキャスト転送は、例えば、フロントエンドブロック３２からのトランスポートストリームをＡＶ信号処理ブロック３１とインターフェースブロック３３とに同時に送り、画面を再生させながら、インターフェースブロック３３に接続された機器にトランスポートストリームを送って記録するような場合に利用できる。ＡＶ信号処理ブロック３１は、トランスポートストリームからビデオパケットとオーディオパケットを取り出し、ビデオパテットを伸長処理して元のビデオデータに変換すると共に、オーディオパケットをデコードして元のオーディオデータに変換するものである。また、ＡＶ信号処理ブロック３１は、デコードされたビデオデータに対して、画像処理を行なうことができる。ＡＶ信号処理ブロック３１は、ＣＰＵ４１と、ビデオデコーダ４２と、オーディオデコーダ４３と、デマルチプレクサ４４と、グラフィックス処理回路４５と、ブリッジ回路４６とを有している。これらＣＰＵ４１、ビデオデコーダ４２、オーディオデコーダ４３、デマルチプレクサ４４、グラフィックス処理回路４５、ブリッジ回路４６は、チップ内バス４７に接続される。フロントエンドブロック３２は、受信信号から所望の搬送波の信号を選択し、その信号を復調し、エラー訂正処理を行って、トランスポートストリームを出力するものである。このフロントエンドブロック３２は、フロントエンドパック５１と、ＣＰＵ５２とを有している。フロントエンドパック５１は、受信信号を中間周波信号に変換するミキサ回路や局部発振回路、中間周波数増幅回路、復調回路、エラー訂正回路等を含んでいる。
【００４２】
インターフェースブロック３３は、例えば、ＩＥＥＥ１３９４のような、外部機器とのインターフェースを提供するものである。この外部インターフェースブロック３３は、例えば、ＩＥＥＥ１３９４のインターフェース６１と、ＣＰＵ６２とを含んでいる。内蔵フィーチャブロック３４は、更にそのディジタル放送を受信するために必要な追加回路を設けるためのものである。例えば、ディジタル衛星放送では、課金を行うために、電話回線を介して、受信データが転送される。このためのモデムが内蔵フィーチャブロック３４に設けるものである。この内蔵フィーチャブロック３４は、追加機能を実現するための回路（ここではモデム）７１と、ＣＰＵ７２とを含んでいる。
【００４３】
プラグインインターフェース３５は、新たなサービスを受ける場合等に拡張機能を提供するためのものである。プラグインインターフェース３５には、拡張プラグインカード３６が装着される。拡張プラグインカード３６には、拡張機能を実現するためのソフトウェアやハードウェアからなる拡張機能８１と、ＣＰＵ８２とを含んでいる。
【００４４】
第７図に示すような構成で、例えば、ディジタルＣＳ放送を受信するテレビジョン受信機２０を構成するとする。この場合には、フロントエンドブロック３２としては、ＱＰＳＫの復調処理、ビタビ復号及びリード・ソロモン符号のエラー訂正処理が可能なものが用いられる。また、ＡＶ信号処理ブロック３１として、トランスポートストリームで送られてくるＭＰＥＧ２方式で圧縮されたビデオパケット及びＭＰＥＧ方式で圧縮されたオーディオパケットの伸長処理を行うものが用いられる。
【００４５】
ディジタルＣＳ放送では、例えば、１２ＧＨｚ帯の信号が用いられる。この衛星からの例えば１２ＧＨｚ帯の受信信号は、パラボラアンテナ（図示せず）で受信され、パラボラアンテナに取り付けられた低雑音コンバータで１ＧＨｚ程度の信号に変換されて、フロントエンドブロック３２に送られる。フロントエンドブロック３２で、受信信号の中から、所望のチャンネルの搬送波の信号が選択される。そして、この信号に対して、ＱＰＳＫの復調処理、ビタビ復号及びリード・ソロモン符号のエラー訂正処理が行われ、トランスポートストリームが復号される。
【００４６】
このとき、受信するチャンネルの選択は、ホストＭＰＵ２１から、バス３０を介して送られてくるコマンドに応じて設定される。ホストＭＰＵ２１からは、バス３０を介して、「何チャンネルの周波数を受信せよ」というような、上位レイヤのコマンドが送られてくる。このコマンドは、バス３０から、フロントエンドブロック３２のＣＰＵ５２に送られる。ＣＰＵ５２は、このコマンドを解釈し、このコマンドから、フロントエンドパック３２の受信周波数をコマンドで指定された所望の搬送波周波数に設定する制御信号を発生する。具体的には、ＣＰＵ５２は、送られてきたコマンドに基づいて、局部発振器を構成するＰＬＬの制御信号を発生する。これにより、受信チャンネルの周波数が設定される。
【００４７】
フロントエンドブロック３２からは、ＭＰＥＧ２方式で圧縮されたビデオデータのパケットと、ＭＰＥＧ方式で圧縮されたオーディオデータのパケットとを含むトランスポートするが出力される。このトランスポートストリームは、バス３０を介して、ＡＶ信号処理ブロック３１に送られる。ＡＶ信号処理ブロック３１に送られたトランスポートストリームは、ブリッジ４６、チップ内バス４７を介して、デマルチプレクサ４４に送られる。デマルチプレクサ４４で、ビデオパケットとオーディオパケットとが分離され、ビデオパケットはビデオデコーダ４２に送られ、オーディオパケットはオーディオデコーダ４３に送られる。ビデオデコーダ４２で、ＭＰＥＧ２方式のビデオデータの伸長処理が行われ、ビデオデータがデコードされる。オーディオデコーダ４３で、ＭＰＥＧオーディオ方式のオーディオデータの伸長処理が行われ、オーディオデータがデコードされる。ＭＰＥＧデコーダ４２でデコードされたビデオデータは、チップ内バス４７を介してグラフィックス処理回路４５に送られる。グラフィックス処理回路４５で、画像処理が行われる。
【００４８】
このとき、どのような画像処理をするかは、ホストＭＰＵ２１から、バス３０を介して送られてくるコマンドに応じて設定される。ホストＭＰＵ２１からは、バス３０を介して、「画面を縮小又は拡大せよ」というような、上位レイヤのコマンドが送られてくる。このコマンドは、バス３０から、ブリッジ４６を介して、ＣＰＵ４１に送られる。ＣＰＵ４１は、このコマンドを解釈し、このコマンドから、画面を指定された大きさに縮小／拡大するための制御信号を発生する。具体的には、ＣＰＵ４１は、送られてきたコマンドに基づいて、グラフィックス処理回路４５に、画面の縮小又は拡大のためのタイミング信号やハードウェアを直接制御するコマンドが送られる。
【００４９】
このように、この例では、テレビジョン受信機２０を構成するのに必要な各機能は、ブロック３１、３２、３３、３４、３５としてバス３０に繋がれ、バス３０を介して、コマンドやストリームが転送される。バス３０を標準化することで、開発効率が上がり、放送方式の変更やサービスの変更や追加にも容易に対応できる。
【００５０】
ところでが、この場合には、ビデオパケットやオーディオパケットからなるストリームがバス３０上に直接転送されるため、バス３０に機器を繋いで、バス３０を介して送られてくるビデオパケットやオーディオパケットを抜き出して、外部機器にコピーするようなことが行われる可能性がある。バス３０が標準化されていると、バス３０に繋いでバス３０を介して送られてくるビデオパケットやオーディオパケットを抜き出するような機器が簡単にできてしまう可能性がある。
【００５１】
そこで、コンテンツの保護を図るために、第８図に示すように、バス３０に繋がれる各ブロック３１、３２、３３、３４、３５及び拡張プラグインカード３６には、暗号化エンコーダ／デコーダ４８、５８、６８、７８、８８が設けられる。
【００５２】
この暗号化エンコーダ／デコーダ４８、５８、６８、７８、８８により、各ブロック３１、３２、３３、３４、３５からバス３０を介して転送されるビデオパケットやオーディオパケットのストリームは暗号化される。このように、バス３０を介して転送されるビデオパケットやオーディオパケットのストリームを暗号化することで、コンテンツの保護が図れる。
【００５３】
なお、上述の例では、バス３０上に流されるコンテンツを保護するために、各ブロック３１、３２、３３、３４及び拡張プラグインカード３６の全てに暗号化エンコーダ／デコーダ４８、５８、６８、７８、８８を設けているが、各ブロック３１、３２、３３、３４はセットの中に収納されているため、各ブロック３１、３２、３３、３４からコンテンツが外部に漏れる可能性は比較的少ない。これに対して、プラグインインターフェース３５からはバス３０が外部に導出されている。コンテンツが外部に漏れる可能性が最も高いのは、プラグインインターフェース３５にコピーのための機器を繋いで、バス３０からコンテンツを取り出すことである。
【００５４】
そこで、第９図に示すように、拡張プラグインインターフェース３５に暗号化エンコーダ／デコーダ８９を設けておき、拡張プラグインインターフェース３５からバス３０を流れるコンテンツのデータがそのまま出ることがないようにしても良い。また、この発明が適用されたテレビジョン受信機２０では、外部拡張ブリッジ３５に拡張プラグインカード３６を装着することで、新たな機能を付加して、新たなサービスに対応させたりすることができる。
【００５５】
つまり、第１０図に示すように、上述のようにして構成されたテレビジョン受信機２０では、例えばテレビジョン受信機２０の前面に、カード装着部９１が設けられる。このカード装着部９１に、拡張プラグインカード３６が装着される。カード装着部９１に拡張プラグインカード３６が装着されると、拡張プラグインカード３６がプラグインインターフェース３５を介してバス３０に繋がれる。このように、拡張プラグインカード３６を、プラグインインターフェース３５を介してバス３０に繋ぐことで、新たなサービスに対応したり、機能を拡張させたりすることができる。
【００５６】
このような拡張プラグインカード３６を装着したとき、その拡張プラグインカード３６の機能が働けるようにするためには、制御用のソフトウェアが必要な場合がある。この制御用のソフトウェアを磁気ディスクや光ディスクのような記録媒体で提供し、ユーザがドライバのソフトウェアをインストールすることが考えられるが、それでは、ユーザの負担になる。
【００５７】
そこで、第１１図に示すように、拡張プラグインカード３６内のメモリにスクリプトを入れておき、拡張プラグインカード３６が装着されると、このスクリプトがホストＣＰＵ２１の主記憶にアップロードされるようにしている。つまり、第１１図に概念図で示すように、拡張プラグインカード３６には、コマンドスクリプトＣＭＤと、コマンドインターフェースＣＩＦと、ドライバＤＲＶが含まれている。新たな拡張プラグインカード３６が装着されると、ホストＭＰＵ２１により拡張プラグインカード３６が装着されたことが認識される。それから、この拡張プラグインカード３６を動作させるためのコマンドスクリプトＣＭＤがホストＣＰＵ２１側にアップロードされる。コマンドスクリプトＣＭＤがホストＭＰＵ２１側にアップロードされると、ホストＭＰＵ２１側では、新たに装着された拡張プラグインカード３６を動作させるためのコマンドを発生できる。
【００５８】
新たに装着された拡張プラグインカード３６を動作させるときには、ホストＭＰＵ２１側のスクリプトエンジンＳＥＮＧからコマンドが発生され、このコマンドがバス３０を介して、拡張プラグインカード３６に送られる。拡張プラグインカード３６のコマンドインターフェースＣＩＦで、このコマンドが解釈され、ドライバＤＲＶにより、送られてきたコマンドに応じて、ハードウェアが制御される。
【００５９】
例えば、番組を記録／再生できるような機器が拡張プラグインカード３６の場合には、第１２図に示すように、逆方向送りキー２０２Ａ、停止キー２０２Ｂ、再生キー２０２Ｃ、早送りキー２０２Ｄ、録画キー２０２Ｃの表示に、逆方向送り、停止、再生、早送り、録画を行うためのコマンドＣＭＤ１１、ＣＭＤ１２、ＣＭＤ１３、ＣＭＤ１４、ＣＭＤ１５を埋め込んだようなスクリプトがハイパーテキストで記述される。このようなスクリプトが読み込まれると、ブラウザにより第１２図に示すような画面が形成される。そして、キー２０２Ａ〜２０２Ｅがクリックされると、埋め込まれていたコマンドが発生され、このコマンドにより、その機器の動作が制御される。
【００６０】
第１３図及び第１４図は、このときの処理を示すフローチャートである。第１３図において、拡張プラグインカード３６が装着されると（ステップＳ１）、拡張プラグインカード３６が装着されたことがホストＭＰＵ２１で判断され（ステップＳ２）、このプラグイン拡張カード３６がどのようなカードであるか確認できるか否かが判断される（ステップＳ３）。拡張プラグインカード３６が認識できなければ、警告が出される（ステップＳ４）。
【００６１】
ここで、拡張プラグインカード３６が確認できたら、拡張プラグインカード３６内にあるコマンドスクリプトＣＭＤがアップロードされる（ステップＳ５）。このように、拡張プラグインカード３６内にあるコマンドスクリプトＣＭＤをアップロードすることで、ホストＭＰＵ２１は、装着された拡張プラグインカード３６に対するコマンドを認識し、装着された拡張プラグインカード３６に対する処理を行えるようなる。
【００６２】
第１４図において、コマンドスクリプトがアップロードされた後に、その拡張プラグインカード３６を動作させるためのユーザ操作がなされると（ステップＳ１１）、スクリプトのチェックが行われ（ステップＳ１２）、チェックの結果が正しいか否かが判断される（ステップＳ１３）。チェックの結果が正しくなければ、警告が表示される（ステップＳ１４）。チェックの結果が正しければ、スクリプトエンジンＳＥＮＧでスクリプトが解釈され（ステップＳ１５）、コマンドが発行される（ステップＳ１６）。このコマンドにより、拡張プラグイン機器が動作される（ステップＳ１７）。
【００６３】
なお、上述の例では、新たな拡張プラグインカード３６を装着する場合について説明したが、バス３０に新たなブロックを追加する場合にも、同様な手法を使って、新たなブロックに対するコマンドスクリプトをアップロードすることかできる。
【００６４】
なお、上述の例では、ディジタル放送の受信装置であるが、この発明は、ディジタルＶＴＲ等の他の機器にも同様に適用することができる。この発明によれば、ディジタルテレビジョン受信機に必要な要素をブロック化し、各ブロック間を、汎用性のあるバスを介して接続するようにしている。そして、新たなサービスを受けられるように、このバスに対して着脱自在の拡張プラグインカードが用意される。拡張プラグインカードに、拡張機能を実現するためのハードウェアと、このハードウェアを制御させるためコマンドが記述されたスクリプトが格納されている。拡張プラグインカードがインターフェースを介してバスに装着されると、このスクリプトがホスト演算処理ブロック側に自動的にアップロードされる。ホスト演算処理ブロックは、この転送されてきたスクリプトに基づいて、拡張プラグインカードを動作させることができる。このため、新たなハードウェアを追加したときに、ソフトウェアのインストールは不要となる。
【００６５】
以上のように、この発明は、特にディジタル放送を受信するテレビジョンを実現するのに用いて好適であり、搬送波や、変調方式、圧縮方式の異なる様々なディジタルテレビジョン放送に対応させるのに用いて有用である。
【００６６】
【発明の効果】
ディジタルテレビジョン受信機に必要な要素をブロック化し、各ブロック間を、汎用性のあるバスを介して接続するようにしている。そして、新たなサービスを受けられるように、このバスに対して着脱自在の拡張プラグインカードが用意される。拡張プラグインカードに、拡張機能を実現するためのハードウェアと、このハードウェアを制御させるためコマンドが記述されたスクリプトが格納されている。拡張プラグインカードがインターフェースを介してバスに装着されると、このスクリプトがホスト演算処理ブロック側に自動的にアップロードされる。ホスト演算処理ブロックは、この転送されてきたスクリプトに基づいて、拡張プラグインカードを動作させることができる。このため、新たなハードウェアを追加したときに、ソフトウェアのインストールは不要となる。
【図面の簡単な説明】
【図１】    従来のディジタルテレビジョン放送の受信装置の一例のブロック図である。
【図２】  この発明の基本構成を説明するためのブロック図である。
【図３】  コマンドの発生と画面表示の説明に用いる略線図である。
【図４】  ホストプロセッサから送るコマンドの説明に用いる略線図である。
【図５】  ホストプロセッサから送るコマンドの説明に用いる略線図である。
【図６】  ドライバのインストール時の説明に用いるフローチャートである。
【図７】  この発明が適用されたテレビジョン受信機の一例のブロック図である。
【図８】  この発明が適用されたテレビジョン受信機において暗号化処理を行う場合の一例を示すブロック図である。
【図９】  この発明が適用されたテレビジョン受信機において暗号化処理を行う場合の他の例を示すブロック図である。
【図１０】  この発明が適用されたテレビジョン受信機の説明に用いる斜視図である。
【図１１】  この発明が適用されたテレビジョン受信機において拡張プラグインカードを装着した場合の説明に用いるブロック図である。
【図１２】  新たな機器を装着した場合のコマンドの発生と画面表示の説明に用いる略線図である。
【図１３】  この発明が適用されたテレビジョン受信機において拡張プラグインカードを装着した場合の説明に用いるフローチャートである。
【図１４】  この発明が適用されたテレビジョン受信機において拡張プラグインカードを装着した場合の説明に用いるフローチャートである。
【符号の説明】
１０・・・バス、１１・・・ホストＭＰＵブロック、１２・・・ＡＶ信号処理ブロック、１３・・・フロントエンドブロック、１４・・・インターフェースブロック、１５・・・プラグインインターフェースブロック、１６・・・内蔵フィーチャブロック、４８，５８，６８，７８，８８・・・暗号化エンコーダ／デコーダ
【図１】
0004581316.tif 000002
【図２】
0004581316.tif 000003
【図３】
0004581316.tif 000004
【図４】
0004581316.tif 000005
【図５】
0004581316.tif 000006
【図６】
0004581316.tif 000007
【図７】
0004581316.tif 000008
【図８】
0004581316.tif 000009
【図９】
0004581316.tif 000010
【図１０】
0004581316.tif 000011
【図１１】
0004581316.tif 000012
【図１２】
0004581316.tif 000013
【図１３】
0004581316.tif 000014
【図１４】
0004581316.tif 000015
0004581316.tif 000016