(57)【特許請求の範囲】
【請求項１】
ネットワーク経由で取得したダウンロードアプリケーション及び内蔵アプリケーションにより機能を実現する受信機であって、
ダウンロードアプリケーションの管理情報を受信したか否かを判断する判断部と、
内蔵アプリケーションにより実行される内蔵メニュー上の所定の機能の表示を制御するメニュー管理部と、を備え、
前記所定の機能は、ダウンロードアプリケーションと内蔵アプリケーションで共通する機能であり、
前記メニュー管理部は、前記判断部において前記管理情報が受信された場合は、前記所定の機能を前記内蔵メニュー上に表示せず、前記判断部において前記管理情報が受信されなかった場合は、前記所定の機能を前記内蔵メニュー上に表示させるよう、前記内蔵メニューの表示を制御する、ことを特徴とする受信機。
【請求項２】
前記メニュー管理部は、内蔵アプリケーションにより実行される内蔵メニュー上の所定の機能について、内蔵メニュー上で表示させるか否かを示す表示設定を行う手段を更に有し、
前記判断部において前記管理情報が受信された場合は、前記表示設定にしたがい、内蔵メニュー上での前記所定の機能の表示の有無を決定し、前記判断部において前記管理情報が受信されなかった場合は、前記表示設定にかかわらず、前記所定の機能をすべて前記内蔵メニュー上に表示させるよう、前記内蔵メニューの表示を制御する、請求項１記載の受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ケーブル放送等のデジタル放送の受信機であって、特に、内蔵アプリケーションとダウンロードしたアプリケーションに基づき種々の機能を実現する受信機に関する。
【背景技術】
【０００２】
近年、ケーブル放送においてもデジタル化が進み、種々のサービスが提供されている。このようなケーブル放送の受信機として種々の技術が開発されている（例えば特許文献１参照）。次世代の北米向けケーブル放送の標準規格としてＯＣＡＰ（Open Cable Application Platform）が提案されている。
【０００３】
ＯＣＡＰによれば、ＳＴＢ（セットトップボックス）等の受信機は、放送局から電子番組表（ＥＰＧ）やＶＯＤ（Video on Demand）視聴用アプリケーション等の種々のアプリケーション（Ｊａｖａアプリケーション）をダウンロード可能であり、そのダウンロードしたアプリケーションをＯＣＡＰ規格で定まるＡＰＩ(Application Program Interface)に基づいて実行することで所定の機能を実現する。すなわち、受信機は決められたＡＰＩに基づき動作するのみで、ダウンロードアプリケーションが実現する具体的な機能については認識していない。
【０００４】
そのような受信機は、電源ＯＮ時に、局側から定期的に送信されるダウンロードアプリケーション等の配信の有無をチェックし、配信されている場合はダウンロードアプリケーションを実行する。
【０００５】
受信機は、局側から送信されるダウンロードァプリンケーション以外に、元々インストールされているアプリケーション（以下「内蔵アプリケーション」という。）を保持している。受信機はダウンロードアプリケーションがない場合、内蔵アプリケーションにしたがい機能を実行する。
【０００６】
【特許文献１】特表２００６−５１１１０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
字幕設定、暗証番号設定のような重要な機能は、ＯＣＡＰアプリケーションによるメニューと内蔵アプリケーションによるメニューの双方で提供される場合があり、このように２つのメニュー間で同じ機能が存在する場合、ユーザはいずれのメニューを用いればよいか判断に迷い、混乱する。
【０００８】
【０００９】
本発明は上記課題を解決すべくなされたものであり、ユーザの混乱を防止する受信機を提供することにある。
【課題を解決するための手段】
【００１０】
本発明において、ネットワーク経由で取得したダウンロードアプリケーション及び内蔵アプリケーションにより機能を実現するデジタル放送の受信機が提供される。第１の態様のデジタル放送の受信機は、ダウンロードアプリケーションの管理情報を受信したか否かを判断する判断部と、内蔵アプリケーションにより実行される内蔵メニュー上の所定の機能の表示を制御するメニュー管理部と、を備える。所定の機能は、ダウンロードアプリケーションと内蔵アプリケーションで共通する機能である。メニュー管理部は、判断部において管理情報が受信された場合は、所定の機能を内蔵メニュー上に表示せず、判断部において管理情報が受信されなかった場合は、所定の機能を内蔵メニュー上に表示させるよう、内蔵メニューの表示を制御する。
【００１１】
【００１２】
【００１３】
【００１４】
【００１５】
【発明の効果】
【００１６】
本発明によれば、ケーブル放送受信機において、内蔵メニューの表示を制御することで、ユーザの混乱を防止できる。
【発明を実施するための形態】
【００１７】
以下、添付の図面を参照して本発明の実施の形態を説明する。
【００１８】
１．受信機のハードウェア構成
図１は、本発明の実施形態における、ケーブル放送を受信する受信機のハードウェア構成を示した図である。受信機１００は、ケーブル放送局に設置され、ケーブル放送を提供するサーバ２００にケーブル２５０を介して接続されている。受信機１００には、ケーブル放送を受信するためのケーブルカード３００が挿入される。受信機１００はリモコン４００を介してユーザ操作情報（キーコード）を受信し、その操作に応じた処理を行う。本実施形態の受信機１００は、ＯＣＡＰ（Open Cable Application Platform）規格に準拠したケーブル放送を受信可能とする。なお、図１では、音声信号を処理するための構成は説明の簡略化のために省略してある。
【００１９】
受信機１００は図１に示すようなハードウェア構成を有する。ディスプレイ１１は、内蔵アプリケーションまたはＯＣＡＰアプリケーションにより再生された映像、または受信した映像を表示する。ビデオメモリ１２は、ディスプレイ１１に表示される映像データを保持する。ＡＶデコーダ１３は、ケーブル局よりＭＰＥＧ形式等で配信された音声/映像データを復号する。ＴＤデコーダ１４は、音声/映像/データを多重化したトランスポートストリームをフィルタリングする。チューナ１５は、ケーブル放送局よりケーブルを介して配信された信号を受信する。
【００２０】
ＣＰＵ１０は受信機１００の動作を制御するコントローラである。ＣＰＵ１０には、データの記憶手段としてハードディスクドライブ（ＨＤＤ）２２と、揮発性メモリ２０と、不揮発性記憶手段であるキャッシュメモリ２１とが接続されている。
【００２１】
受信機１００は、ケーブルカード３００とデータのやりとりを行うためのケーブルカードインタフェース１８と、リモコン４００から信号を受信するためのリモコン受信部１９とをさらに備える。ケーブルカード３００は特定のケーブル放送局から放送を受信できるようにするためのカードである。
【００２２】
受信機１００は、ケーブル２５０を介してインターネットに接続するためのケーブルモデム１６と、イーサパケットの送受信を行うためのイーサチップ１７とをさらに有する。
【００２３】
受信機１００はケーブル放送からの情報以外に複数の映像音声情報の入力系統（入力１、入力２、入力３）を有する。各入力には映像音声信号を処理するための処理回路２３ａ〜２３ｃが接続され、セレクタ２４により、処理回路２３ａ〜２３ｃの出力のうちの１つが選択され、ディスプレイ１１に出力される。なお、本実施形態の受信機１００では、ケーブル放送及び入力１〜３のうちのいずれか１つがユーザ操作に基づきＣＰＵ１０により選択され、ディスプレイ１１に出力される。
【００２４】
２．受信機の機能的な構成
図２に、受信機１００の機能的構成を示す。図２に示す機能的構成はＣＰＵ１０が所定のプログラムを実行することで実現される。なお、図２においては説明の便宜上、主要な機能のみを示している。図２に示されていない機能であっても、後述する受信機１００の機能はＣＰＵ１０が所定のプログラムを実行することで実現され得ることは言うまでもない。
【００２５】
図２に示すように、受信機１００は、出荷時にインストールされているアプリケーション（以下「内蔵アプリケーション」という。）５１ａ、５１ｂと、ケーブル放送局からダウンロードして取得したアプリケーション（以下、「ＯＣＡＰアプリケーション」という。）５２ａ、５２ｂとを含む。内蔵アプリケーション管理部５３は、内蔵アプリケーションの画面排他制御及びキー配送制御を行う。ＯＣＡＰアプリケーション管理部５４は、Ｊａｖａバイトコード及びＯＣＡＰアプリケーションを実行するミドルウェアであって、ＯＣＡＰアプリケーションの画面排他制御及びキー配送の制御も行う。
【００２６】
動作モード管理部５５は受信機１００の動作モードを管理するモジュールである。動作モードには、ＯＣＡＰアプリケーションを実行する動作モード(以下「ＯＣＡＰモード」という。)と、内蔵アプリケーションを実行する動作モード(以下「ＩＤＴＶモード（または非ＯＣＡＰモード）」という)とがある。
【００２７】
キー配送部５６は、キードライバ７９により受信されたリモコン４００からのキーコードを内蔵アプリケーション管理部５３またはＯＣＡＰアプリケーション管理部５４へ配送するモジュールである。
【００２８】
ケーブルカード管理部５９は、ケーブルカード３００からの要求を受信し、管理し、実行するモジュールである。ケーブルモデム管理部６１は、ＤＳＧチャンネルのスキャン/ＤＳＧトンネル取得等、ケーブルモデム１６を制御するモジュールである。
【００２９】
メニュー管理部６２は、ＯＣＡＰアプリケーションまたは内蔵アプリケーションにより提示される設定メニューを管理するモジュールである。
【００３０】
リソース制御部６３は、ディスプレイ１１やスピーカ等のリソースに対するアプリケーションからの映像出力や音声出力のような制御要求を制御するためのモジュールである。
【００３１】
ファイルシステム７１は、アプリケーションからＯＳ（Operating System）へのファイルシステムＡＰＩ(Open/close/write/ioctl等)を管理するＯＳ上のサブシステムである。ソケット（SocketAPI）７２は、アプリケーションからＯＳへのネットワークAPIを管理するサブシステムである。
【００３２】
ＴＣＰ７４は、ソケット７２から要求されたＴＣＰ通信を制御するモジュールである。ＵＤＰ７３は、ソケット７２により要求されたＵＤＰ通信を制御するモジュールである。ＩＰ７５はＩＰパケットの送受信、及びパケットのルーティングを制御するモジュールである。イーサモジュール７６ａ、７６ｂは、イーサパケットの送受信を制御するモジュールである。フィルタ７７は、イーサパケットをイーサモジュール７６ａまたはイーサモジュール７６ｂへの振り分けを行うドライバである。
【００３３】
ネットワークドライバ７８はイーサチップ１７を制御するデバイスドライバである。キードライバ７９はリモコン４００から送信されたキーコードの受信を行うデバイスドライバである。ケーブルカードドライバ８０は、ケーブルカード３００からのデータの送受信を制御するデバイスドライバである。ＡＶドライバ８１は、ＡＶデコーダ１３においてＡＶストリームのデコードを行うデバイスドライバである。
【００３４】
ＴＤドライバは、ＴＤデコーダ１４においてsectionデータをフィルタリングするデバイスドライバである。描画サブシステム８２は、ＯＣＡＰアプリケーションまたは内蔵アプリケーションにより描画された映像をディスプレイ１１に表示させるサブシステムである。
【００３５】
３．受信機の機能
上記の構成を有する本実施形態の受信機１００の種々の機能について以下に説明する。
【００３６】
３．１  リモコンキーの配送制御
ＯＣＡＰ規格では、ＯＣＡＰアプリケーションで利用可能なリモコンキーが決められている。同様に、内蔵アプリケーションで利用可能なリモコンキーも決められている。リモコン４００は、受信機１００の内蔵アプリケーションにより実行されるメニュー（以下「内蔵メニュー」という。）を起動させるためのメニューキーを有する。このような状況では、ＯＣＡＰアプリケーションの所定の機能を実行させるためのリモコンキーと、受信機１００の内蔵メニューを起動するためのリモコンキーとが同一である場合がある。このような場合、受信機１００をＯＣＡＰモードで動作させると、リモコン４００を用いて受信機１００の内蔵メニューを表示することができないという問題がある。
【００３７】
上記の問題を解決すべく、本実施形態では、リモコン４００に、送出するキーコードを動作モードに応じて切り替えられるよう切替スイッチを設けている。さらに、受信機１００は、受信したキーコードの配送先を動作モードに応じて変更するよう構成されている。以下、具体的に説明する。
【００３８】
図３にリモコン４００の構成を示す。リモコン４００は、その動作を制御する制御部４１と、ユーザが操作を行う各種操作キーを含む操作部４２と、キーコードを送信するキーコード送出部４３を含む。操作部４２は、メニューを起動させるためのメニューキーを含む。リモコン４００はモード切替スイッチ４６を有し、動作モードに応じたキーコードの送信を可能とする。リモコン４００は、ＯＣＡＰモードに対応するキーコード（以下「通常キーコード」という。）を保持する通常キーコード保持部４４と、ＩＤＴＶモード（非ＯＣＡＰモード）に対応するキーコード（以下「別キーコード」という。）を保持する別キーコード保持部４５とを含む。別キーコードは、機能が対応する通常キーコードの先頭に所定のバイトデータ（例えば”０Ａ”）を付加することで生成してもよい。
【００３９】
モード切替スイッチ４６がオンのときは、リモコン４００はＯＣＡＰモードに対応する通常キーコードを送信する。すなわち、リモコン４００は、ユーザにより操作されたキーに対応した、ＯＣＡＰモード用のキーコードをキーコード送出部４３から送信する。一方、モード切替スイッチ４６がオフのときは、リモコン４００はＩＤＴＶモードに対応する別キーコードの送信を行う。すなわち、リモコン４００は、ユーザにより操作されたキーに対応した別キーコードをキーコード送出部４３から送信する。
【００４０】
次に、図４を参照し、リモコン４００からのキーコードを受けた場合の受信機１００の動作を説明する。
【００４１】
ユーザによりリモコン４００が操作されると、リモコン４００からキーコードが受信機に送信される。受信機１００は、リモコン４００からキーコードを受信すると、キードライバ７９が受信したキーコードをキー配送部５６に送信する。
【００４２】
キー配送部５６は、受信機１００の動作モードがＯＣＡＰモードか否かを判断する（Ｓ１１）。動作モードがＯＣＡＰモードであれば、キー配送部５６はさらに、受信したキーコードがＯＣＡＰ用のキーコードである「通常キーコード」であるか否かを判断する（Ｓ１２）。
【００４３】
受信したキーコードが通常キーコードであれば、受信したキーコードをＯＣＡＰアプリケーションに配送する（Ｓ１３）。ＯＣＡＰアプリケーションは、その受信したキーコードに基づいた機能を実行する（Ｓ１４）。
【００４４】
受信したキーコードが通常キーコードでない場合、受信したキーコードを内蔵アプリケーションに配送する（Ｓ１５）。内蔵アプリケーションは、その受信したキーコードに基づいた機能を実行する（Ｓ１６）。
【００４５】
一方、ステップＳ１１で、受信機１００の動作モードがＯＣＡＰモードでない場合、すなわち、ＩＤＴＶモードである場合、キー配送部５６は、受信したキーコードを内蔵アプリケーションに配送する（Ｓ１５）。内蔵アプリケーションは、その受信したキーコードに基づいた機能を実行する（Ｓ１６）。
【００４６】
上記の処理によれば、例えば、モード切替スイッチ４６をオンにしてリモコン４００のメニューキーが押下された場合、リモコン４００からＯＣＡＰモード用のキーコード（通常キーコード）が送出されるため、ＯＣＡＰアプリケーションによるメニューが表示される。一方、モード切替スイッチ４６をオフにして、メニューキーが押下された場合、リモコン４００からＩＤＴＶモード用のキーコード（別キーコード）が送出されるため、内蔵アプリケーションによるメニューすなわち内蔵メニューが表示される。つまり、リモコン４００のモード切替スイッチ４６をオフにしておけば、受信機１００がＯＣＡＰモードで動作していても、リモコン操作により、受信機１００の内蔵メニューを表示させることが可能となる。
【００４７】
３．２  内蔵メニュー上の共通機能の表示制御
受信機１００がＩＤＴＶモードで動作する場合、字幕設定や暗証番号（ＰＩＮ）設定などは、受信機１００の内蔵メニューから設定される。
【００４８】
ＯＣＡＰモードで動作する場合、種々の機能はケーブル放送業者（ＭＳＯ）が作成したＯＣＡＰアプリケーションにより実現される。どのような機能をＯＣＡＰアプリケーションに含めるかは、ケーブル放送業者が決定することから、ＯＣＡＰアプリケーションが必ずしも、上記の字幕設定や暗証番号設定の機能をサポートしているとは限らない。
【００４９】
字幕設定や暗証番号設定は重要な機能であり、受信機１００においてこれらの機能は必ず実現される必要がある。このため、受信機１００では、ＯＣＡＰアプリケーションがそのような機能をサポートしていない場合であっても、ＯＣＡＰモードで動作中において字幕設定や暗証番号設定を実行できるように、内蔵メニューの表示を制御する必要がある。
【００５０】
図５（ａ）に内蔵メニューの表示例を、図５（ｂ）にＯＣＡＰアプリケーションによるメニューの表示例を示す。内蔵メニュー５００は字幕設定を行う際にユーザにより選択されるアイコン５０１と、暗証番号の設定を行う際に選択されるアイコン５０３を含む。同様に、ＯＣＡＰアプリケーションにより実行されるメニュー５２０は字幕設定を行う際に選択されるアイコン５２１と、暗証番号の設定を行う際に選択されるアイコン５２３を含む。図５（ａ）、（ｂ）に示すように、字幕設定、暗証番号設定のような重要な機能は、ＯＣＡＰアプリケーションによるメニュー５２０と内蔵アプリケーションによるメニュー５００の双方で提供される場合があり、このように２つのメニュー間で同じ機能が存在する場合、ユーザはいずれのメニューを用いればよいか判断に迷い、混乱する。
【００５１】
そこで、本実施形態の受信機１００では、ＯＣＡＰアプリケーションと内蔵アプリケーションの間で重複した機能の表示が基本的に行われないように内蔵メニューの表示を制御する。
【００５２】
具体的には、ＯＣＡＰアプリケーションによるメニューと内蔵メニューで共通して表示され得る所定の機能（以下「共通機能」という。）については、ＯＣＡＰアプリケーションが受信されたときには、基本的に、内蔵メニュー上で表示させないようにする。但し、ＯＣＡＰアプリケーションが受信された場合の内蔵メニュー上での共通機能の表示の可否は、ユーザが設定できるようにする。以下、この設定を「共通機能の表示設定」という。つまり、ユーザの要望により、ＯＣＡＰアプリケーションが受信された場合であっても、内蔵メニュー上で共通機能を表示できるようにする。ユーザが操作において混乱しなければ問題ないからである。一方、ＯＣＡＰアプリケーションが受信されなかったときには、内蔵メニュー上で共通機能を必ず表示するようにする。
【００５３】
内蔵メニュー上の共通機能の表示設定について説明する。図６（ａ）に、内蔵メニュー上での共通機能の表示設定のための画面例を示す。同図において、字幕表示の設定は「ＯＮ」、暗証番号の設定は「ＯＦＦ」となっている。これらの設定は、受信機１００がＯＣＡＰアプリケーションを受信できたときに、字幕表示については内蔵メニュー上に表示するが、暗証番号については内蔵メニュー上には表示しないことを指定する。なお、共通機能の表示設定のデフォルト値は「ＯＦＦ」とする。すなわち、受信機１００がＯＣＡＰアプリケーションを受信できたときは、基本的には、内蔵メニュー上で共通機能の表示は行わないようにし、ユーザが要望する場合のみ、その機能を表示させる。
【００５４】
本実施形態では、ＯＣＡＰアプリケーションが受信できたか否かの判断を、ＸＡＩＴ（Extended Application Information Table）の受信の有無に基づいて行う。ここで、ＸＡＩＴとは、ケーブル放送局から送信されるダウンロードアプリケーションの管理情報であって、アプリケーションの格納場所と起動するアプリケーションの情報を含む。受信機１００はＸＡＩＴをケーブル放送局のサーバ２００から定期的に受信する。
【００５５】
受信機１００は、ＸＡＩＴの受信の有無及び内蔵メニュー上の共通機能の表示設定に応じて、内蔵メニューにおける共通機能の表示の有無を制御する。表１にその内容を示す。表１に示すように、ＸＡＩＴが受信できたときは、共通機能の表示設定にしたがった表示を行う。ＸＡＩＴが受信できなかったときは、共通機能の表示設定の内容にかかわらず、内蔵メニュー上に共通機能を表示する。
【００５６】
【表１】
0005349660.tif 000002
【００５７】
図７に、上記制御に関連した、受信機１００のメニュー管理部６２の処理フローを示す。メニュー管理部６２は、ＸＡＩＴが受信できたか否かを判断する（Ｓ２１）。ＸＡＩＴが受信されたことは、受信機１００がＯＣＡＰモードで動作可能なことを意味する。この場合、ＯＣＡＰアプリケーションと内蔵アプリケーション間で２つのメニューが存在することになり、前述の共通機能の重複表示の問題が生じ得る。
【００５８】
ＸＡＩＴが受信できた場合、内蔵メニュー上の共通機能の表示設定を確認する。表示設定が「ＯＦＦ」の場合、すなわち、内蔵メニュー上でその機能を表示（実行）しないように設定されている場合、内蔵メニュー上でその機能が表示されないように、内蔵メニューの表示を制御する（Ｓ２３）。表示設定が「ＯＮ」の場合、すなわち、内蔵メニュー上でその機能を表示（実行）するように設定されている場合、内蔵メニュー上でその機能が表示されるように、内蔵メニューの表示を制御する（Ｓ２４）。
【００５９】
ＸＡＩＴが受信できなかった場合、受信機１００がＩＤＴＶモードでのみ動作することを意味する。よって、この場合は内蔵メニュー上で字幕設定や暗証番号設定が可能であることが要求される。このため、ＸＡＩＴが受信できなかった場合は、内蔵メニュー上で各機能が表示されるように、内蔵メニューの表示を制御する（Ｓ２４）。共通機能の各々に対して上記の処理を行う。
【００６０】
例えば、字幕設定及び暗証番号設定に対して図６（ａ）に示すような表示設定がなされている場合、ＸＡＩＴが受信された場合は、図６（ｂ）に示すような、字幕設定に対するアイコン５０１が表示され、暗証番号設定に対するアイコン５０３が表示されない内蔵メニュー５００が表示される。一方、ＸＡＩＴが受信されなかった場合、図６（ｃ）に示すような、字幕設定に対するアイコン５０１及び暗証番号設定に対するアイコン５０３が表示された内蔵メニュー５００が表示される。
【００６１】
以上のように内蔵メニューの表示を制御することで、内蔵メニューとＯＣＡＰアプリケーションによるメニューの間で表示される機能の重複表示を排除でき、ユーザの混乱を防止でき、ユーザフレンドリな操作環境を提供できる。
【００６２】
３．３  入力ソース切替時のリソースの排他制御
図１に示すように、本実施形態の受信機１００はケーブル放送以外に複数の入力系統（入力１、入力２、入力３）を有し、いずれか１つの入力系統（入力ソース）が選択される。
【００６３】
受信機１００では、ＶＯＤ（Video On Demand）のようなＯＣＡＰアプリケーションを実行中の入力ソースから、他の入力ソースへ入力が切替えられた時、その実行中のＯＣＡＰアプリケーションを終了させず、バックグラウンドで継続して実行させる。以下、このようにＯＣＡＰアプリケーションをバックグラウンドで実行する処理を「ｐａｕｓｅ処理」という。ｐａｕｓｅ処理はＯＣＡＰアプリケーション管理部５４により制御される。このｐａｕｓｅ処理により、再度元の入力ソースに入力が切り替えられたときに迅速なＯＣＡＰアプリケーションの実行が可能となる。
【００６４】
ＯＣＡＰアプリケーションがｐａｕｓｅ状態にある場合に、ユーザがそのＯＣＡＰアプリケーションに関連したリモコンキーを操作すると、ＯＣＡＰアプリケーションがそのキーに反応し、映像や音声を出力してしまうおそれがある。また、バックグラウンドで動作中のＯＣＡＰアプリケーション本来の仕様により、映像出力、音声出力のようなリソースに対する制御要求（例えば、ポップアップウィンドウの表示要求）が発生したりする場合がある。このような場合、画面や音声等のリソースの利用が調停されず、映像、音声などが乱れる可能性がある。また、バックグラウンドでＯＣＡＰアプリケーションを動作中に、外部入力(PC/HDMIなど)や、Jpeg Viewerなどの内蔵アプリケーションを同時に動作させる場合も、複数のアプリケーションで共有されている画面や音声等のリソースの利用が調停されず、映像、音声などが乱れる可能性がある。
【００６５】
以上の問題を解決すべく、本実施形態の受信機１００は、ＯＣＡＰアプリケーションを実行中の入力ソースから他の入力ソースへ入力切替が行われたときに、実行中のＯＣＡＰアプリケーションをｐａｕｓｅ状態に制御するとともに、ｐａｕｓｅ状態では、外部から入力されたキーコード及び内部で発生したリソース制御要求を破棄（無視）するように制御を行う。図８を参照し、これを詳細に説明する。
【００６６】
図８は、入力切替時のリソースの排他制御のフローチャートである。ＯＣＡＰアプリケーションを実行中の入力ソースから他の入力ソースへ入力切替の指示を受けると、入力切替がなされる（Ｓ３１）。それに伴い、ＯＣＡＰアプリケーションをｐａｕｓｅ状態に制御する（Ｓ３２）。
【００６７】
ＯＣＡＰアプリケーションがｐａｕｓｅ状態にあるときは、ＯＣＡＰアプリケーション管理部５４は、リモコン４００等からＯＣＡＰアプリケーションに対するキーコードの入力があっても、ＯＣＡＰアプリケーションに対し、そのキーコードを配送しない（Ｓ３３）。また、ｐａｕｓｅ状態中、リソース制御部６３は、バックグラウンドで実行中のＯＣＡＰアプリケーションからのリソース制御要求を受けても、その制御要求を破棄（無視）する（Ｓ３４）。
【００６８】
その後、入力ソースが元の入力ソースに切替えられると（Ｓ３５）、ｐａｕｓｅ処理を終了する（Ｓ３６）。以後、ＯＣＡＰアプリケーションに対するキーコードの配送及びＯＣＡＰアプリケーションからのリソースの制御に関しては通常どおりの制御を行う。
【００６９】
以上の方法により、例えば、ＯＣＡＰアプリケーションによるＶＯＤ（Video On Demand）の視聴中に入力切替を行なった場合でも、画面/音声などが乱されることがなく、かつ、再度ＶＯＤの視聴に入力が切替えられたときに、迅速にＶＯＤの表示を行うことができる。
【００７０】
３．４  電源ＯＮ時の高速起動制御
受信機１００は、主電源がオンされてから、ＯＣＡＰアプリケーションの１つであるＥＰＧ（番組表）アプリケーションが起動されるまでに以下の処理を実行する。
【００７１】
（１）受信機１００は、ケーブルカード３００からＤＳＧ（Docsis Set-up Gateway）モードの指示を受信し、ケーブルモデム１６にＤＳＧチャンネルのスキャンを要求する。
（２）ケーブルモデム１６は、スキャンを完了しＤＣＤ（Downstream Channel Descriptor）をＣＰＵ１０へ送信する。
（３）ＣＰＵ１０はケーブルカード３００にＤＣＤを送り、ＸＡＩＴのＤＳＧトンネルＯｐｅｎ要求をケーブルカード３００から受信し、ケーブルモデム１６に指示する。
（４）ＣＰＵ１０は、ケーブルモデム１６から受信したＤＳＧトンネルのパケットをケーブルカード３００に送り、ケーブルカード３００からＸＡＩＴのデータを受信する。
（５）ＣＰＵ１０は、ＸＡＩＴから、起動すべきモニタアプリケーションを特定し、起動させる。
（６）モニタアプリケーションがＥＰＧアプリケーションを起動する。
【００７２】
以上のように、受信機１００は、ＥＰＧを起動するための起動情報を取得するためにＸＡＩＴを取得する必要がある。このＸＡＩＴの取得に種々の手順を実行する必要があることから、ＸＡＩＴの取得に時間を要し、結果としてＥＰＧ起動までに時間を要していた。
【００７３】
そこで、本実施形態の受信機１００は、受信したＸＡＩＴを不揮発性のキャッシュメモリ２１に記憶しておき、主電源オン時にそのキャッシュメモリ２１に格納されたＸＡＩＴを用いて起動を行う。これにより、ＸＡＩＴの取得時間を短縮し、ＥＰＧ起動までに要する時間を短縮する。以下、図９、１０のフローチャートを参照し、この処理を説明する。
【００７４】
受信機１００の主電源がオンされると、ＸＡＩＴがキャッシュメモリ２１に格納されているか否かを判断する（Ｓ５１）。キャッシュメモリ２１に格納されている場合、ＸＡＩＴに記述されているＯＣＡＰアプリケーションを起動する（Ｓ５２）。このように主電源オン時から即座にＸＡＩＴを取得できることから、ＥＰＧ起動までに時間を短縮できる。
【００７５】
ここで、受信機１００の主電源がオンされると、図９、１０に示す手順と平行して、前述の（１）〜（４）の手順が実行され、ＸＡＩＴの受信のための処理が実行されている。主電源がオン後、所定時間内（例えば１０秒以内）にＸＡＩＴを受信したか否かを判断する（Ｓ５３）。
【００７６】
所定時間内にＸＡＩＴを受信できなかった場合、起動中のＯＣＡＰアプリケーションを終了し、キャッシュメモリ２１をクリアし（Ｓ５４）、内蔵アプリケーションを起動する（Ｓ５５）。この場合、受信機１００が受信したケーブル放送がＯＣＡＰに対応していないと判断されるからである。
【００７７】
所定時間内にＸＡＩＴを受信できた場合、受信したＸＡＩＴがキャッシュされたＸＡＩＴと等しいか否かを判断する（Ｓ５６）。両ＸＡＩＴが等しい場合、処理を終了する。起動に用いたＸＡＩＴが正しいものであるからである。両ＸＡＩＴが異なる場合、受信したＸＡＩＴをキャッシュメモリ２１に格納する（Ｓ５７）。その後、起動中のＯＣＡＰアプリケーションを終了し、受信したＸＡＩＴに記述されているＯＣＡＰアプリケーションを起動する（Ｓ５８）。これは、正しいＸＡＩＴを用いてＯＣＡＰアプリケーションを起動する必要があるからである。
【００７８】
一方、ステップＳ５１において、ＸＡＩＴがキャッシュメモリ２１に格納されていない場合、主電源がオン後、所定時間内にＸＡＩＴを受信したか否かを判断する（Ｓ６１）。所定時間内にＸＡＩＴを受信できた場合、受信したＸＡＩＴをキャッシュメモリ２１に格納し（Ｓ６２）、受信したＸＡＩＴに記述されているＯＣＡＰアプリケーションを起動する（Ｓ６３）。主電源がオン後、所定時間内にＸＡＩＴを受信できなかった場合は、内蔵アプリケーションを起動する（Ｓ６４）。
【００７９】
以上のように、キャッシュしたＸＡＩＴを用いて起動を行うことで、主電源オン時のＥＰＧの起動待ち時間を短縮できる。なお、上記方法により、ＥＰＧに限らず、他のＯＣＡＰアプリケーションの起動時間も短縮できることは言うまでもない。
【００８０】
３．５  通信制御
ＯＣＡＰ規格では、ＯＣＡＰアプリケーションとケーブルカード３００の双方が別々のマックアドレスを用いてＩＰ通信を行う。従来、１つのイーサチップで複数のＩＰアドレスを実現するＩＰエイリアスがあるが、この技術では、別々のマックアドレスを付与することはできない。
【００８１】
また、受信機は、ケーブルカード用とＯＣＡＰアプリケーション用の二つのＩＰアドレスを管理する。それらのＩＰアドレスは同一ネットワーク上のアドレスである。この状況下で、ソケット（SocketAPI）を用いてＩＰパケットを送信すると、ＯＳ（Operating System）がＩＰアドレスを割り当てる。この場合、ＯＣＡＰアプリケーションが送信したパケットに対して、ケーブルカード用のＩＰアドレスが割り当てられるという問題が生じるおそれがある。この問題を解決するために、ソケットを用いて明示的にＩＰアドレスを割り当てる方法がある。この場合、ＯＣＡＰアプリケーションがＩＰアドレスを明示的に指定する必要がある。しかし、ＯＣＡＰアプリケーションはケーブル放送業者から提供されるため、必ずそのような仕様を有するように設計されることを期待することはできない。
【００８２】
以下では、上記の課題を解決し、１つのイーサチップで、ＯＣＡＰアプリケーションとケーブルカードそれぞれに別々のマックアドレスを付与してＩＰ通信を行うための構成を説明する。
【００８３】
図１１は、図２に関連して、受信機１００の通信に関わる部分の構成をより詳細に示した図である。
【００８４】
受信機１００は、ケーブルカード３００用とＯＣＡＰアプリケーション用の二つのＩＰアドレスを有する。それらのＩＰアドレスは、同一ネットワーク上のアドレスである。
【００８５】
イーサモジュール１（７６ａ）はＯＣＡＰアプリケーション５２に対するイーサパケットの送受信を制御するためのモジュールである。イーサモジュール２（７６ｂ）はケーブルカード３００に対するイーサパケットの送受信を制御するためのモジュールである。
【００８６】
イーサパケットの受信について説明する。本実施形態では、ネットワークドライバ７８は無差別モード（promiscuous mode）に設定され、通過する全てのパケットを取得する。
【００８７】
フィルタ７７は、ＯＣＡＰアプリケーション５２に割り当てられたＭＡＣアドレスと、ケーブルカード３００に割り当てられたＭＡＣアドレスを事前に取得し、管理している。フィルタ７７は、ネットワークドライバ７８により取得された全てのパケットのヘッダを解析し、ＭＡＣアドレスがＯＣＡＰアプリケーション５２のＭＡＣアドレスまたはケーブルカード３００のＭＡＣアドレスに等しいパケットを抽出する。そして、フィルタ７７は、ＭＡＣアドレスがＯＣＡＰアプリケーション５２のＭＡＣアドレスに等しいパケットは、イーサモジュール１（７６ａ）に送信する。一方、ＭＡＣアドレスが、ケーブルカード３００のＭＡＣアドレスに等しいパケットはイーサモジュール２（７６ｂ）に送信する。この方法により、１つのイーサチップにより２種類のＭＡＣアドレスのデータの受信を可能とする。
【００８８】
次に、ＯＣＡＰアプリケーション５２またはケーブルカード３００からのデータに対するＩＰアドレスの付与方法について説明する。
【００８９】
受信機１００の起動時に、受信機１００のＤＨＣＰクライアントは、ＯＣＡＰアプリケーション５２及びケーブルカード３００それぞれのＭＡＣアドレスを指定して、それぞれのＩＰアドレスをＤＨＣＰサーバに問い合わせ、取得した２つのＩＰアドレス取得し、ＯＳに登録する。ケーブルカード３００は自己のＩＰアドレスをＯＳに問い合わせて取得する。
【００９０】
ルーティング管理８３は、ルーティングテーブルにおいて、ケーブルカード３００のＩＰアドレスのメトリック（metric）の値を、ＯＣＡＰアプリケーション５２のＩＰアドレスのメトリックの値よりも大きい値に設定する。ＯＳは一般にＩＰアドレスを割り当てる場合、メトリック値が小さいＩＰアドレスから優先的に割り当てる。よって、ＯＣＡＰアプリケーション５２のＩＰアドレスのメトリック値を、ケーブルカード３００のＩＰアドレスのメトリック（metric）値よりも小さくすることで、ＯＣＡＰアプリケーション５２のＩＰアドレスが優先的に割り当てられるようになる。
【００９１】
ＯＣＡＰアプリケーション５２はデータを送信する場合、自己のＩＰアドレスを指定せずに、送信先を指定してデータをＯＣＡＰ通信部５７に送る。ＯＣＡＰ通信部５７は、ＩＰアドレスは指定せずにそのデータをソケット７２に送る。ＯＣＡＰアプリケーション５２のデータにはＩＰアドレスが付与されていないので、ＯＳがＩＰアドレスを付与する。その際、ＯＣＡＰアプリケーション５２のＩＰアドレスのメトリックの値がケーブルカード３００のＩＰアドレスのメトリックの値よりも小さいことから、ＤＨＣＰサーバにより付与されたＯＣＡＰアプリケーション５２のＩＰアドレスが、ＯＳにより確実にＯＣＡＰアプリケーション５２のデータに割り当てられる。
【００９２】
一方、ケーブルカード３００はＯＳよりＩＰアドレスを取得しているため、ケーブルカード３００がデータを送信する場合、データに対して送信先及び自己のＩＰアドレスを指定してケーブルカード通信部８４に送信する。ケーブルカード通信部８４はデータをソケット７２に送る。ケーブルカード３００からのデータは、明示的にＩＰアドレスが指定されていることから、ＯＳによりＩＰアドレスが付与されることはない。
【００９３】
以上のように、ＯＣＡＰアプリケーション５２のデータに対しては、ＯＳによりＩＰアドレスが割り当てられ、ケーブルカード３００のデータに対してはケーブルカード３００が自己のＩＰアドレスを明示的に指定する。このように、それぞれのデータに対して適切なＩＰアドレスが付与される。
【００９４】
以上の処理により、１つのイーサチップにおいて、複数のマックアドレスでのＩＰ通信が可能となる。ＯＣＡＰアプリケーションはＩＰアドレスを意識せずに、正しいＩＰアドレスでの通信を行うことが可能となる。
【００９５】
上記の実施形態では、放送データの伝送媒体としてケーブルを用いた例を説明した。本発明が適用できる伝送媒体の種類はケーブルに限定されない。本発明の思想は、放送データを受信する受信機であって、内蔵のアプリケーションとダウンロードアプリケーションの双方により機能が実現される受信機に対して適用できることは言うまでもない。
【００９６】
また、本発明の思想が適用できる受信機としては表示装置以外にＳＴＢがある。
【産業上の利用可能性】
【００９７】
本発明は、放送データを受信する受信機であって、内蔵のアプリケーションとダウンロードアプリケーションの双方により機能が実現されるＳＴＢ等の受信機に有用である。
【図面の簡単な説明】
【００９８】
【図１】本発明の実施形態における、ケーブル放送を受信する受信機のハードウェア構成を示した図
【図２】受信機の機能的構成を示す図
【図３】リモコンの構成を示す図
【図４】リモコンからキーコードを受けた場合の受信機の処理を示すフローチャート
【図５】（ａ）内蔵メニューの一例を示す図、（ｂ）ＯＣＡＰアプリケーションによるメニューの一例を示す図
【図６】（ａ）内蔵メニュー上での共通機能の表示設定のための画面例を示す図、（ｂ）ＸＡＩＴ受信時の内蔵メニューの表示例を示す図、（ｃ）ＸＡＩＴ未受信時の内蔵メニューの表示例を示す図
【図７】内蔵メニュー上での共通機能の表示制御に関するメニュー管理部の処理を示すフローチャート
【図８】入力切替時のリソースの排他制御のフローチャート
【図９】受信機の起動時の処理のフローチャート
【図１０】受信機の起動時の処理のフローチャート
【図１１】受信機の通信に関わる部分の構成をより詳細に示した図
【符号の説明】
【００９９】
１７  イーサチップ
１０  ＣＰＵ
１１  ディスプレイ
１９  リモコン受信部
２１  キャッシュメモリ
２３ａ〜２３ｃ  入力
２４  セレクタ
５１ａ、５１ｂ  内蔵アプリケーション
５２ａ、５２ｂ  ＯＣＡＰアプリケーション
５５  動作モード管理部
５６  キー配送部
６２  メニュー管理部
６３  リソース制御部
７７  フィルタ
８３  ルーティング管理部
１００  受信機
２００  局内サーバ
２５０  ケーブル
３００  ケーブルカード
４００  リモコン
【図１】
0005349660.tif 000003
【図２】
0005349660.tif 000004
【図３】
0005349660.tif 000005
【図４】
0005349660.tif 000006
【図５】
0005349660.tif 000007
【図６】
0005349660.tif 000008
【図７】
0005349660.tif 000009
【図８】
0005349660.tif 000010
【図９】
0005349660.tif 000011
【図１０】
0005349660.tif 000012
【図１１】
0005349660.tif 000013