(57)【要約】【課題】外部制御機器との通信で使用する制御コマンドを容易に変更できる仕組みを提供する。【解決手段】外部制御機器からの制御コマンドを信号伝送路１００を介してデータ送受信部１０１により受信データとして得る。その制御コマンドをインターフェイスマネージャ１１０がインターフェイス定義１２０を参照して制御コマンドから予め決められた内部コマンドに相互変換処理する。インターフェイス定義は外部コマンドを内部コマンドに変換するためのデータを保持しており、相互変換に必要な定義データを書き換え可能な不揮発メモリ上に配置しておくことにより、容易に制御コマンドを変更できる仕組みを提供する。外部制御機器との通信で使用する制御コマンドを容易に変更することができる。【選択図】　図１
2004020976.tif 000002
【特許請求の範囲】
【請求項１】
外部制御機器との間において制御コマンドの受送信を行い、前記制御コマンドを実行する映像表示装置において、
前記制御コマンドの送受信を行うためのデータ送受信部と、
予め決められた内部コマンドを実行する内部コマンド実行部と、
前記データ送受信部で取り扱う前記制御コマンドと前記内部コマンド実行部で取り扱う前記内部コマンド間で相互にコマンド変換するインターフェイスマネージャと、
前記制御コマンドと前記内部コマンド間の相互変換を行う際の変換規則となるインターフェイス定義を記憶するインターフェイス定義記憶手段を具備し、
前記インターフェイスマネージャは前記インターフェイス定義を参照することにより、前記制御コマンドと前記内部コマンド間の相互変換を行うことを特徴とする映像表示装置。
【請求項２】
前記インターフェイス定義は、前記外部制御機器との通信に使用する前記制御コマンドの特徴を定義する少なくとも１つ以上のプロトコル定義と、前記各プロトコル定義に付随する前記各プロトコル定義毎に定義された制御コマンドと、前記内部コマンド間の相互変換をするための情報である変換テーブルと、前記内部コマンドの実行結果を返信するための情報である前記各プロトコル定義に対応して定義されたリターンコード定義の組み合わせからなる少なくとも１つ以上のコマンドセットから構成されることを特徴とする請求項１に記載の映像表示装置。
【請求項３】
前記インターフェイスマネージャは、前記データ送受信部で受信したデータが、前記外部制御機器との通信に使用する制御コマンドとして意味を成すかどうかを前記プロトコル定義を参照して判定するプロトコル判定部と、前記プロトコル判定部での判定結果を元にして前記受信した制御コマンドを対応する内部コマンドに前記変換テーブルを参照して変換するコマンド検索変換部と、前記内部コマンド実行部のコマンド実行結果を前記リターンコード定義を参照して外部制御機器に返信するリターンコード返信部から構成されることを特徴とする請求項２に記載の映像表示装置。
【請求項４】
前記インターフェイスマネージャは、前記プロトコル判定部で前回判定したプロトコル判定結果であるラストプロトコル定義を一時記憶するラストプロトコル定義記憶手段を備え、前記プロトコル判定部は、プロトコル判定の際に、最初に前記ラストプロトコル定義記憶手段の前記ラストプロトコル定義を検索するようにしたことを特徴とする請求項３に記載の映像表示装置。
【請求項５】
前記変換テーブルは、前記外部制御機器からの１つの制御コマンドに対し複数の内部コマンドを含み、前記コマンド検索変換部は１つの制御コマンドに対し複数の内部コマンドが前記変換テーブルに定義されている場合、該定義されている複数の内部コマンドを実行することを特徴とする請求項３に記載の映像表示装置。
【請求項６】
前記インターフェイス定義が記憶されている前記インターフェイス定義記憶手段は、外部から書き換え可能な不揮発性メモリまたは電池でバックアップされたメモリで構成され、前記インターフェイス定義記憶手段の前記インターフェイス定義の少なくとも一部の書き換えまたは追加が可能であることを特徴とする請求項１乃至３のいずれかに記載の映像表示装置。
【請求項７】
前記インターフェイス定義が記憶されている前記インターフェイス定義記憶手段は着脱可能であり、前記インターフェイス定義記憶手段を交換することにより前記インターフェイス定義を変更するようにしたことを特徴とする請求項１乃至３のいずれかに記載の映像表示装置。
【請求項８】
前記インターフェイス定義を構成する複数のコマンドセットのうち、少なくとも１つは従来機種の制御コマンドを処理するために使用されるものであって、制御コマンドの下位互換性を維持するために使用することを特徴とする請求項２に記載の映像表示装置。
【請求項９】
前記インターフェイス定義を構成する複数のコマンドセットを、ユーザ公開用コマンドセットと製造者用コマンドセットに分け、ユーザ公開用と製造者用の制御コマンドに対するプロトコル定義を変えることにより、意図しない制御コマンドからシステムを保護することを特徴とする請求項２に記載の映像表示装置。
【請求項１０】
前記インターフェイス定義は、前記制御コマンドと前記内部コマンドとの間の標準の変換規則である標準コマンドセットと、前記外部制御機器からの（または前記外部制御機器への）コマンドを該標準コマンドセットの制御コマンドである標準コマンドに変換する規則である拡張コマンドセットとを備えてなり、
前記インターフェイスマネージャは、前記プロトコル判定部と、前記コマンド検索変換部と、前記リターンコード返信部とに加えて、前記コマンド検索変換部で変換されたコマンドを受け取って、そのコマンドが予め決められた該標準コマンドセットの内部コマンド（以下標準内部コマンドと称す）かどうかを判定するコマンドフィルタ部を具備し、
前記コマンドフィルタ部は受け取ったコマンドが予め決められた該標準内部コマンドでない場合、前記プロトコル判定部に受け取ったコマンドを再度送ることでコマンドの再処理機能を付加したことを特徴とする請求項３に記載の映像表示装置。
【請求項１１】
前記インターフェイス定義は実行可能なバイナリ実行コードと該バイナリ実行コードが格納されているアドレスを指定するアドレステーブルから構成され、前記インターフェイス定義記憶手段は該アドレステーブルで指定されるアドレスに該バイナリ実行コードが予め記憶されており、
前記インターフェイスマネージャは前記インターフェイス定義の該バイナリ実行コードを、該アドレステーブルを参照して該アドレステーブルで指定される前記インターフェイス定義記憶手段のアドレスに格納されている該バイナリ実行コードを呼び出して直接実行することで、前記制御コマンドと前記内部コマンド間の相互変換機能を提供することを特徴とする請求項１乃至３のいずれかに記載の映像表示装置。
【請求項１２】
前記データ送受信部は複数の外部制御機器との間で前記制御コマンドの送受信を行うための複数のデータ送受信手段からなり、前記データ送受信部と前記インターフェイスマネージャとの間に、前記各データ送受信手段が受送信する生データから、前記インターフェイスマネージャへの入力となる制御コマンドを取り出すための、各データ送受信手段に対応した固有の処理を行うプロトコルスタック処理部を具備し、
前記プロトコルスタック処理部は、各データ送受信手段に対応した固有のデータである制御コマンド取り出し処理を行い、前記インターフェイスマネージャに対し入力を統一することを特徴とする請求項１乃至１１のいずれかに記載の映像表示装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、外部制御機器からの制御コマンドで制御される映像表示装置に係り、特に、映像表示装置の制御コマンドを外部制御機器に合わせて容易に変更可能な仕組みを備えた映像表示装置に関する。
【０００２】
【従来の技術】
従来、映像表示装置を外部制御機器から制御する場合、外部制御機器のパーソナルコンピュータ等の計算機からＲＳ２３２Ｃ回線等のシリアル回線を介して映像表示装置へ制御コマンドを送信することにより制御している。
【０００３】
従来の映像表示装置において、制御コマンドとしては各メーカ間で異なる制御コマンド体系が実装されており、また同一メーカにおいても、映像表示装置の製造年により異なる制御コマンド体系が実装されている場合がある。そのため、外部制御機器から映像表示装置を制御する場合、使用する映像表示装置に実装されている制御コマンド体系に従って制御を行う必要がある。
【０００４】
また、映像表示装置に実装されている制御コマンド体系は映像表示装置内部の組み込みソフトウェアとして実装されており、制御コマンド体系を変更するためにはソフトウェアを変更して再コンパイルする等の高度なソフトウェア知識が必要で一般ユーザが制御コマンド体系を変更することはできない。そのため、外部制御機器により映像表示装置を制御するシステムが構築された後で映像表示装置を新規のものに交換した場合、ＲＳ２３２Ｃ等の同一の接続インターフェイスを持つ映像表示装置であっても、新規に導入した映像表示装置の制御コマンドが異なるために外部制御機器側のソフトウェアや設定等を変更する必要がある。
【０００５】
【発明が解決しようとする課題】
以上のように、従来の映像表示装置の制御コマンドは映像表示装置内部の組み込みソフトウェアで決まっており、映像表示装置の制御コマンドを変更することは技術的に困難という欠点があった。内部の組み込みソフトウェアを変更して制御コマンドを変更するためには、高度なソフトウェア知識が要求される上に、組み込みソフトウェアのソースコードを入手する必要があり、事実上、映像表示装置の開発者にしか制御コマンドの変更ができない。
【０００６】
このように制御コマンドが映像表示装置に固定されているため、映像表示装置を制御するシステムにおいて、映像表示装置を新規のものに交換する際には外部制御機器を映像表示装置に合わせるために、制御システム全体の停止やデバック等の変更に伴う作業が必要となる。そのため、映像表示装置のみを新規のものに変更する場合においても、制御システム全体を見直さなければならないという欠点があった。
【０００７】
本発明の目的は、映像表示装置に制御コマンド体系を容易に変更できる仕組みを備えることで、現状の制御システムや外部制御機器の制御コマンドに対応可能な映像表示装置を提供することにある。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明の映像表示装置は、請求項１に記載の構成とする。かかる発明によれば、前記制御コマンドと前記内部コマンドとの相互変換規則に変更が生じた場合、前記インターフェイス定義記憶手段に記憶されている前記インターフェイス定義を変更することにより、容易に変更対応が可能となる。
【０００９】
そして、請求項２または請求項３に記載のように構成する。このように、前記コマンドセットを複数持てる仕組みを備えることにより、前記インターフェイスマネージャは前記複数のコマンドセットのうちから、前記外部制御機器からの（または前記外部制御機器への）前記制御コマンドが対応するものを選択することができ、複数のコマンドセットを区別することなく取り扱うことができる。インターフェイスマネージャは、各コマンドセットの内容に対する依存性を持たないため、制御コマンドの体系を変更する場合にコマンドセットの内容のみ変更すれば良く、従来のような高度なソフトウェア知識が要求される内部の組み込みソフトウェアを変更する作業を必要とすることなく、容易にコマンドセットを追加、削除及び更新することができる。
【００１０】
また、請求項４のように構成すれば、前回の判定結果のプロトコル定義を優先的に検索することにより、複数のプロトコル定義が存在する場合でも高速に判定できる。
【００１１】
また、請求項１０に記載の構成とすることにより、該拡張コマンドセットで定義されている前記外部制御機器からの制御コマンドを一度、該標準制御コマンドに変換することにより、該拡張コマンドセットを定義する際に該標準内部コマンドについて予め知っておく必要が無くなる。また、組み込みソフトウェアを変更して該標準内部コマンドに変更があった場合でも、該標準コマンドセットの変換テーブルも合わせて変更することにより、該拡張コマンドセットの制御コマンドについては変更する必要が無く、容易に互換性を保つことができる。
【００１２】
また、請求項１１に記載の構成することにより、前記インターフェイスマネージャは、前記制御コマンドと前記内部コマンド間の相互変換を行う際に、該バイナリ実行コードへの該アドレステーブルで指定されるアドレスのみを知っていれば良いため、該バイナリ実行コードの処理内容には直接依存しない構成をとることができる。そのため、予めコマンドセットのデータ定義の構成を決める必要が無く、容易に制御コマンドの変更ができる。また、コマンド間の相互変換が算術的規則で定められたコマンドセットの場合、一覧表形式の変換テーブルを用いた場合に比べて実装サイズを小さくすることができる。
【００１３】
また、請求項１２に記載の構成とし、前記複数のデータ送受信手段から前記インターフェイスマネージャが必要とする固有のデータである制御コマンドを取り出す前記プロトコルスタック処理部を設けることにより、インターフェイスマネージャへの入力を統一して取り扱うことができ、外部制御機器への信号伝送路を追加・削除する際に柔軟に対応することができる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。なお、各図において、同一な機能を有する部分には同一な符号を付して示す。
【００１５】
図１は外部制御機器（図示せず）と映像表示装置との間の通信に用いるコマンド（以下、制御コマンドと略記）と映像表示装置の内部で使用するコマンド（以下、内部コマンドと略記）間の相互変換機能における、本発明の実施の形態である映像表示装置のコマンド変換機能の基本構成を示す図である。
【００１６】
図１において、本発明の基本構成は、信号伝送路１００を介して外部制御機器（図示せず）との間で制御コマンドの送受信処理を行うデータ送受信部１０１と、内部コマンドを受け取ってそのコマンドを実行し、その実行結果を返信する内部コマンド実行部１３０と、データ送受信部１０１で使用される制御コマンドと内部コマンド実行部１３０が受け取る内部コマンド間の相互変換機能を有するインターフェイスマネージャ１１０と、インターフェイスマネージャ１１０が制御コマンドと内部コマンド間の相互変換を行う際の変換規則となるインターフェイス定義１２０を予め記憶しておいた記憶部１２１から構成されている。
【００１７】
インターフェイス定義１２０は、後述するプロトコル判定部１１１、コマンド検索変換部１１２、リターンコード返信部１１３が参照するプロトコル定義、変換テーブル、リターンコード定義の組み合わせからなるコマンドセットを複数備えており、その複数のコマンドセットは標準コマンドセット１２２０と拡張用コマンドセット１２２１、…、１２２ｉ、…、１２２ｎの複数のコマンドセットから構成されている。なおインターフェイス定義１２０は少なくとも１つの標準コマンドセット１２２０を備える。
【００１８】
さらにインターフェイスマネージャ１１０は、データ送受信部１０１で使用される制御コマンドがどのように構成されているかの意味解釈（以下、プロトコル判定と記述）を行うプロトコル判定部１１１と、プロトコル判定部１１１のプロトコル判定結果に基づいて制御コマンドと内部コマンドの間を相互に変換するコマンド検索変換部１１２と、内部コマンド実行部１３０でのコマンド実行結果に基づいて、外部制御機器（図示せず）に対する返信を行うリターンコード返信部１１３から構成されている。なおインターフェイスマネージャ１１０は、インターフェイス定義１２０を構成する複数のコマンドセットに対する検索順序やコマンドセットの管理も行う。
【００１９】
図１における、各機能ブロックの役割はそれぞれ以下のような機能分担となっている。
データ送受信部１０１は、外部制御機器（図示せず）との間の制御コマンドのやり取りを信号伝送路１００を介して行う際に、信号伝送路１００上の電気信号を「０」、「１」で表されるバイナリの数値（以下、データと表記）に変換と、その逆操作（データを電気信号に変換）を行う機能を担う。この電気信号とデータ間の相互変換規約は信号伝送路１００により決められており、データ送受信部１０１は、その通信規約に従った相互変換を行う。一般的にＲＳ２３２Ｃの場合、ＵＡＲＴ制御ＩＣ等を用いて、データを通信速度と通信条件に従った電気信号に変換及び逆変換することで相互変換機能を実現することになる。なお、ここでいうデータとは、単に信号伝送路１００上の電気信号を数値に置き換えたものであり、その数値そのものには意味が無い。データと外部制御機器（図示せず）の制御コマンドの違いは、データ送受信部１０１で相互変換されたデータの塊が、制御コマンドとして意味を成す順序及び組み合わせから構成されているデータを制御コマンドと呼び、単に数値の塊として取り扱う場合はデータと呼ぶ。
【００２０】
インターフェイスマネージャ１１０は、データ送受信部１０１で送受信する制御コマンドと内部コマンド実行部１３０で使用する内部コマンドの間を相互に変換する機能を担う。その相互変換動作において、インターフェイスマネージャ１１０は記憶部１２１に記憶されているインターフェイス定義１２０を参照することにより、制御コマンドと内部コマンド間の相互変換を行う。
【００２１】
インターフェイス定義１２０は、インターフェイスマネージャ１１０のプロトコル判定部１１１、コマンド検索変換部１１２、リターンコード返信部１１３が参照するプロトコル定義、変換テーブル、リターンコード定義の組み合わせからなる複数のコマンドセット１２２０、１２２１、…、１２２ｎから構成されており、各々のコマンドセットがそれぞれ１つの制御コマンドの体系に対応している。プロトコル判定部１１１が参照するコマンドセット内のプロトコル定義は、データ送受信部１０１で受け取ったデータが外部制御機器（図示せず）からの制御コマンドとして意味を成すかどうかを判定するために必要な情報が定義されており、プロトコル判定部１１１はインターフェイス定義１２０内の複数のプロトコル定義を参照し、外部制御機器（図示せず）からの制御コマンドとして意味を成すプロトコル定義を決定する。次にプロトコル判定部１１１にて決定されたプロトコル判定結果に基づいて、コマンド検索変換部１１２はプロトコル判定結果であるプロトコル定義に対応する変換テーブルを用いて、外部制御機器からの制御コマンドを内部コマンドへ変換する。プロトコル判定部１１１とコマンド検索変換部１１２により内部コマンドに変換された制御コマンドは内部コマンド実行部１３０により実行され、その実行結果がリターンコード返信部１１３に渡される。リターンコード返信部１１３は、プロトコル判定結果であるプロトコル定義に対応するリターンコード定義を参照し、実行結果に対応するリターンコードをデータ送受信部１０１に送る。データ送受信部１０１はリターンコード返信部１１３から送られてきたリターンコードを信号伝送路１００を介して外部制御機器（図示せず）に送信することで、制御コマンドに対する応答を行う。なお、プロトコル判定部１１１の判定結果がインターフェイス定義１２０のプロトコル定義の中にない時、及びインターフェイス定義１２０の変換テーブルの中に対象制御コマンドがなくてコマンド検索変換部１１２でのコマンド変換ができない時、リターンコード返信部１１３はエラーの応答を外部制御機器に対して応答する。
【００２２】
図２に示すコマンド例を用いて、以下外部制御機器（図示せず）から入力された制御コマンドを内部コマンド形式に変換して実行し、その実行結果を外部制御機器に返信する動作を以下具体的に説明する。
図２に示すコマンド例は、映像表示装置の赤色のブライトネスを変化させるコマンド例であり、外部制御機器からの制御コマンドとして、制御コマンドの開始を示す「Ｐａｃｋｅｔ　Ｈｅａｄｅｒ　＝　０ｘＡＢＣＤ」、制御コマンドの種別を表す「Ｐａｃｋｅｔ　Ｔｙｐｅ　＝　０ｘ０３」、制御コマンドのサイズを表す「Ｓｉｚｅ　＝　０ｘ０００９」及び制御コマンドのパラメータ部分であるＣｍｄＩＤ（０ｘ００２０）、ＣｍｄＴｙｐｅ（０ｘ０２）、Ｖａｌｕｅ（０ｘ８０）から構成されている。ここで制御コマンドのパラメータ部分以外は固定値であり、パラメータ部分でＢｒｉｇｈｔｎｅｓｓ　Ｒｅｄの制御（ＣｍｄＩＤ　：　０ｘ００２０）　、操作の種類（ＳｅｔＶａｌｕｅ　：　０ｘ０２）及び設定値（Ｖａｌｕｅ　：　０ｘ８０）を指定する構成となっている。この制御コマンドに対応する内部コマンドは、Ｂｒｉｇｈｔｎｅｓｓの制御（Ｏｐｅｒ　：　０ｘ３５００）、操作の種類（ＳｅｔＶａｌｕｅ　：　０ｘ０２）、操作対象色（Ｔａｒｇｅｔ　：　０ｘ００）及び設定値（Ｖａｌｕｅ　：　０ｘ８０）から構成されている。また、本例では外部制御機器への返信として、制御コマンドが正しく実行された場合、図２の例に示すＡｃｋｎｏｗｌｅｄｇｅコードを返信するものとする。
【００２３】
以下、このように制御コマンドとして意味を成すデータの構成や内部コマンドの構成などを取り決めた約束事を総称してプロトコルと呼ぶ。
【００２４】
次に図２に示すコマンド例における、制御コマンドの内部コマンドへの変換動作を図３及び図４を用いて説明する。図３はプロトコル判定部の判定動作を説明するための図、図４はコマンド検索変換部のコマンド変換動作を説明するための図である。
【００２５】
まず図３において、信号伝送路１００からの電気信号をデータ送受信部１０１が受け取り、その受信データ３１０をプロトコル判定部１１１に送る。図３の例では、プロトコル判定部１１１が受け取った、データ送受信部１０１からの受信データ３１０は１６進表示で「ＡＢＣＤ０３０００９００２００２８０」である。次に、プロトコル判定部１１１はインターフェイス定義１２０を参照して、受信データ３１０と一致するプロトコル定義を検索する。ここで、図３のプロトコル定義の一例を示すプロトコル定義例３０１は図１のインターフェイス定義１２０における複数のプロトコル定義を模式的に表した一覧表で、＜＞で表記されているセルは変数であることを示しており（例えば、標準プロトコルのＢｙｔｅ２のセル＜ＣｍｄＩＤ＞）、他の１６進数で表記されたセル（例えば、標準プロトコルのＢｙｔｅ０−１のセル０ｘ５Ａ５Ａ）は定数であることを示している。また、本例での各プロトコル定義は固定長と可変長のものに分けられ、図３の例では固定長の「標準プロトコル」と「定義１」の場合、それぞれ７、９バイト固定である。定義ｎの可変長プロトコルの場合、表の＜Ｓｉｚｅ＞位置のデータ値を全データ長として、データ長を判定することになる。この例のように、プロトコル定義例３０１は定数と変数の区別、定数と変数の位置とその値、全データ長から構成されており、それらの構成要素（定数、変数、位置、値、データ長）の組み合わせの違いを利用して、プロトコル判定部１１１は定義されている複数のプロトコル定義例３０１内を検索し、受信データ３１０が意味を成すプロトコル定義を決定する。
【００２６】
プロトコル定義の検索順は、全てのプロトコル定義を定義順に逐次検索しても良いし、プロトコル判定部１１１で前回検索時に判定したプロトコル定義を優先して検索しても良い。図３の例では、プロトコル判定部１１１が受け取った受信データ３１０と一致するプロトコル定義は「定義１」となり、次回検索時の優先プロトコル定義として「定義１」をプロトコル判定部１１１内の図示しない記憶部に一時記憶する。その後、プロトコル判定部１１１はプロトコル判定結果に基づき、プロトコル定義の構成要素のうち、変数要素のみを内部コマンドへの変換に必要なコマンド変換要素３１１として、コマンド検索変換部１１２に送る。
次に図４において、プロトコル判定部１１１からコマンド変換要素３１１を受け取ったコマンド検索変換部１１２は、プロトコル判定結果の「定義１」に付随する変換テーブル１の一例である例４０１を参照して、コマンド変換要素３１１から内部コマンド４１０にコマンド変換要素を再構成した後、内部コマンド実行部１３０にその内部コマンド４１０を渡す。ここで、図４の変換テーブル１の例４０１は、変換テーブル１の例を模式的に表した表で、図３のプロトコル定義と同様に定数（１６進表記）と変数（＜＞で表記）に分かれている。本動作例では、コマンド変換要素３１１（ＣｍｄＩＤ　＝　０ｘ００２０，　Ｔｙｐｅ　＝　０ｘ０２，　Ｖａｌｕｅ　＝　０ｘ８０）は内部コマンドＢｒｉｇｈｔｎｅｓｓ（ＣｍｄＩＤ　　：　０ｘ３５００）に割り当てられ、変化色は別定数Ｔａｒｇｅｔ（０ｘ００　：　赤）にて指定している。なお、コメント列は分かりやすくするためのもので無くても良い。この例のように、コマンド変換要素３１１から内部コマンド４１０へのコマンドの再構成は、ＣｍｄＩＤをＯｐｅｒに変換する値の変換、定数や変数の付加・削除、順序入れ替えを行って、内部コマンド実行部１３０が実行可能な内部コマンドに再構成する。また、図３のプロトコル判定部１１１からのコマンド変換要素３１１と内部コマンド４１０は１対１に対応していなくても良く、コマンド変換要素３１１から複数の内部コマンドを再構成することもできる（マクロコマンド）。
【００２７】
複数の内部コマンドへの再構成の例として、変換テーブル１の例４０１中の変換定義４０２を示す。ＣｍｄＩＤ　０ｘ００２３で示されるコマンドは、内部コマンドのＢｒｉｇｈｔｎｅｓｓ　Ｒ（Ｔａｒｇｅｔ　：　０ｘ００）とＢｒｉｇｈｔｎｅｓｓ　Ｂ（Ｔａｒｇｅｔ　：　０ｘ０２）に分解され、この場合、外部制御機器からの制御コマンド（Ｃｏｌｏｒ　Ｂａｌａｎｃｅ）が２つの内部コマンド（Ｂｒｉｇｈｔｎｅｓｓ　Ｒ／Ｂ）として実行される。
【００２８】
次に内部コマンドが実行された後の外部制御機器に対する返信動作について、図５により説明する。図５は内部コマンド実行後の外部制御機器に対する返信動作の動作説明図である。
【００２９】
内部コマンド実行部１３０がコマンドを実行し、その結果をリターンコード返信部１１３に送る。リターンコード返信部１１３は、コマンド実行結果５１１に対する返信をプロトコル判定結果の「定義１」に付随するリターンコード定義１の一例を示すリターンコード定義例５０２を参照し、リターンコード５１０（図５の例ではＡＣＫリターンコード）をデータ送受信部１０１に渡す。データ送受信部１０１はリターンコード返信部１１３から渡されたリターンコード５１０を信号伝送路１００を介して外部制御機器（図示せず）に対し返信する。ここで、図５のリターンコード定義例５０２は、リターンコード定義１の一例を模式的に表した表で、図３のプロトコル定義と同様に定数（１６進表記）と変数（＜＞で表記）に分かれている。また、本例ではＡＣＫ返信は常に固定値の例を示しているが、実行したコマンドの結果や実際に設定された値などの複雑な情報を付加しても良い。
【００３０】
次に、コマンドセットの定義やインターフェイスマネージャによるコマンドの相互変換を行う際に必要となる各定義の構成要素について説明する。インターフェイスマネージャがプロトコル判定、コマンド検索変換、リターンコード返信処理を行う際に使用するコマンドセットの構成要素として以下の要素を定義する。その要素はサイズ要素（Ｓｉｚｅ）、計算要素（Ｃｏｍｐｕｔｅ）、値要素（Ｐａｒａｍ）、検索キー要素（Ｋｅｙ）、列挙型要素（Ｅｎｕｍｅｒａｔｅ）、内部変数要素（Ｖａｌｕｅ）からなり、さらに各構成要素は要素の値に関する属性と要素の大きさ（サイズ）に関する属性を持つものとする。構成要素の値と大きさに関する属性は、値に関する属性については絶対（Ａｂｓｏｌｕｔｅ）、一致（Ｍａｔｃｈｅｄ）、任意（Ｖａｒｉａｂｌｅ）の属性値、大きさに関する属性については固定長（Ｆｉｘｅｄ）、条件付（Ｃｏｎｄｉｔｉｏｎａｌ）、区切子（Ｐｕｎｃｔｕａｔｅ）の属性値から構成されるものとする。
【００３１】
まず、各構成要素の役割を以下順に説明する。サイズ要素は、プロトコル定義全体のデータ長に関する要素であり、図３の例ではプロトコル定義３０１の「定義ｎ」におけるセル＜Ｓｉｚｅ＞に相当する。このサイズ要素は必ずしも全データ長を表す必要は無く、予め固定長部分を除いた値、例えば「定義ｎ」の場合にサイズ要素より後ろの構成要素の全データ長の
＜ＣｍｄＩＤ　＝　２＞　＋　＜Ｔｙｐｅ　＝　１＞　＋　＜Ｖａｌｕｅ　＝　１＞　＋　＜Ｔａｒｇｅｔ　＝　１＞　＝　５Ｂｙｔｅｓ
を表す場合もある。このため、サイズ要素は全データ長と固定長部分を引くためのオフセット値の組み合わせとし、プロトコル定義全体のデータ長に係わる構成要素として定義する。次に計算要素は、受信した受信データから算術的に計算される値に関する要素であり、ＣＲＣ値やサムチェック値などの計算値に相当する。この計算要素は必ずしも全構成要素を計算の対象とする必要は無いため、計算の対象となる要素を指定できる仕組みが必要となる。このため、計算要素は計算方法（ＣＲＣやサムチェック）の指定と計算の対象となる要素の組み合わせとし、算術的な計算値に係わる構成要素として定義する。次に値要素は、プロトコル定義を構成するための基本要素であり、通常の定数・変数に相当する。この値要素はプロトコル判定時に使用される定数・変数であって、その違いは構成要素の値に関する属性（絶対、一致、任意）により決定される。例えば、「絶対」の属性を持つ値要素は、図３の例では標準プロトコルのＢｙｔｅ０−１のセル０ｘ５Ａ５Ａのような定数となる。また、「任意」の属性を持つ値要素は変数を表現することになる。次に検索キー要素は、コマンド検索処理部１１２がコマンド検索を行う際の検索キーになる要素であり、図４の例ではＣｍｄＩＤに相当する。この検索キー要素の実体は通常の変数であるが、検索キー要素はコマンド検索変換処理の際の検索キーとして使用され、内部コマンドの一部に置き換わる。つまり、コマンド変換要素３１１を構成する１要素であり、検索の際に使用される構成要素として定義する。次に列挙型要素は、検索キー要素と同様に、コマンド変換要素３１１を構成する１要素であるが、内部コマンドの変数となる要素で、図４の例ではＯｐｅｒＴｙｐｅに相当する。この列挙型要素は予め値に対応する動作・意味が決められたリスト形式の変数を取り扱う。例えば、図３の制御コマンドのプロトコル定義「定義１」での＜Ｔｙｐｅ＞変数は、１＝設定、２＝問い合わせ、３＝初期化の様に値とそれに対応する動作が予め与えられている。しかしながら、内部コマンドでの列挙型要素ＯｐｅｒＴｙｐｅでの値と動作の関係は、１＝問い合わせ、２＝設定、３＝初期化のように順序が異なる場合も考えられる。そのため、列挙型要素は、リストの順序入れ替えに使用する変換規則をもつ構成要素として定義する。最後に内部変数要素は、コマンド変換要素３１１を構成する１要素で、内部コマンドの変数となる要素であり、図４の例ではＶａｌｕｅに相当する。この内部変数要素は通常コマンドの設定値として使用され、そのまま内部コマンドの一部として使用される構成要素として定義される。このように、コマンドの構成要素を役割別に定義しておき、これらの構成要素が組み合わされた定義をインターフェイスマネージャ１１０で判定することにより、さまざまなコマンド体系に対応できる。また、プロトコル定義に関連する構成要素（サイズ要素、計算要素、値要素）とコマンドの内容に関連する要素（検索キー要素、列挙型要素、内部変数要素）に区別されるため、プロトコル判定部１１１ではプロトコル定義に関連する構成要素を判定し、コマンド検索変換部１１２ではコマンドの内容に関連する構成要素を取り扱えば良いことになる。
【００３２】
各構成要素の属性について説明する。値に関する属性については絶対（Ａｂｓｏｌｕｔｅ）、一致（Ｍａｔｃｈｅｄ）、任意（Ｖａｒｉａｂｌｅ）の属性値を定義する。「絶対」属性は値が絶対値であることを示す。「一致」属性は、「絶対」属性のように絶対値ではないがプロトコル判定の際に値が一致することが求められる属性を表す。例えば計算要素のようなＣＲＣ値やサイズ要素のような全データ長などコマンドにより値はその都度異なるが計算結果などと一致することが求められる変数を意味する。したがって、通常計算要素とサイズ要素は「一致」属性を持つことになる。「任意」属性は、文字通り任意の値でありプロトコル判定には直接影響を与えないが、サイズ合わせに使用するダミー変数や無視したい変数を表す。大きさに関する属性については固定長（Ｆｉｘｅｄ）、条件付（Ｃｏｎｄｉｔｉｏｎａｌ）、区切子（Ｐｕｎｃｔｕａｔｅ）の属性値を定義する。「固定長」属性は、構成要素が固定長であることを示す。例えば、図３の例では「定義１」の＜ＣｍｄＩＤ＞（検索キー要素：任意値）は２バイトの「固定長」属性を持つ。「条件付」属性は、他の構成要素の状態により自身の大きさが決まることを示す。例えば、図３の例の「定義１」の＜Ｖａｌｕｅ＞（内部変数要素：任意値）要素は、値を設定するコマンドには必要であるが、初期化のコマンドには必要ない。そのため、＜Ｔｙｐｅ＞（列挙型変数：任意値）要素の値により＜Ｖａｌｕｅ＞要素の大きさが０または１バイトになる場合がある。このように他の構成要素の状態に依存して自身の大きさが変化する属性を表す。「区切子」属性は、その構成要素の最終端が決められた区切り記号により与えられる場合を表す。例えば、「；」記号を区切り記号として”ＢＲＩＧＨＴＮＥＳＳ；０ｘ０１；０ｘ８０”のようなコマンドを考えると、ＢＲＩＧＨＴＮＥＳＳ（１０バイト）、０ｘ０１（１バイト）、０ｘ８０（１バイト）の構成要素に分離されることになる。このように、各構成要素（サイズ、計算、値、検索キー、列挙型、内部変数要素）にその構成要素の値と大きさに対する属性を付加することで、値と大きさに関する特性を表すことができる。
【００３３】
以上の説明のように、構成要素の役割に値と大きさに関する属性を組み合わせたものを単位としてコマンドのプロトコルを定義してゆくことで、コマンドがどのような構造をしているかを表すことができる。また変数属性の構成要素は、変数にもかかわらずその意味合いによって、プロトコル判定に必要な変数と内部コマンドに必要な変数の区別をすることが必要となるが、構成要素の役割によりその区別をすることができる。
【００３４】
次にインターフェイスマネージャ１１０がこのような構成要素を使って定義されたコマンドセットを処理する方法について説明する。データ送受信部１０１で受信した受信データをインターフェイスマネージャ１１０のプロトコル判定部１１１が受け取る。プロトコル判定部１１１は、プロトコル定義に定義されている構成要素の大きさに関する属性（固定長、条件付、区切子）を参照して、受信データの各構成要素に対応する部分を決定する。その際、受信データが不足していればうまく対応する部分が見つけられない構成要素が発生することになり、プロトコル定義として一致しないことを意味する。次に、プロトコル判定部１１１は受信データをうまく各構成要素に割り振ることができたプロトコル定義に対し、構成要素の値に関する属性（絶対、一致、任意）が一致するか否かを調べる。まず、「絶対」属性を持つ構成要素に割り振られた受信データはプロトコル定義に記載された値と一致することが要求される（プロトコル定義の定数部分）。次に、サイズ要素や計算要素のような「一致」属性を持つ構成要素に割り振られた受信データと、実際に受信したデータの大きさや算術的な計算結果が一致することが要求される。このように、各構成要素の大きさに関する属性から受信データを各構成要素に割り振ることができ、値に関する属性のうち「絶対」、「一致」属性が満たされた場合にプロトコルが一致したと判定される。また、値に関する属性「任意」に関しては、値の取り得る範囲を指定して範囲チェックを追加しても良い。プロトコル判定部１１１が各構成要素の値と大きさに関する属性をもとに判定する際に、値と大きさの属性に対し優先順位を設定することにより複数のコマンドセットのプロトコル定義が一致する場合の判定基準として使用することができる。
【００３５】
具体的には、値に関する属性では「絶対」＞「一致」＞「任意」の順に優先順位が高く、「絶対」属性が多く一致したプロトコル定義の方を採用することにする。大きさに関する属性では「固定長」＞「条件付」＞「区切子」の順に優先順位を設定し、「固定長」属性で多く一致したプロトコル定義を採用する。このように、厳密な判定となる「絶対」、「固定長」属性で一致した場合を優先的に採用することで、属性の違いを判定の厳密さに反映させることができる。また、同じ優先順位で複数のコマンドセットのプロトコル定義が一致した場合は、同じプロトコルのコマンドであることを意味しており、複数のコマンドセットに対してコマンド検索変換処理を行っても良いし、最初に定義されているコマンドセットのみを採用しても良い。
【００３６】
プロトコル判定部１１１でプロトコル判定を行った後、コマンド検索変換部１１２でコマンド検索変換処理に必要な構成要素を用いて、コマンド検索変換処理を行う。コマンド検索変換部１１２では、検索キー要素をもとにして、変換テーブルから検索キーと一致する内部コマンドの定義を検索する。検索キー要素により検索された内部コマンドの定義の変数部分を、必要に応じて、列挙型要素と内部変数要素の値で置き換えて、内部コマンドを構成する。
【００３７】
上記の構成要素の役割や値と大きさの属性については、新たな役割や属性を追加してインターフェイスマネージャで新しい役割や属性を取り扱うことができる様にすることで、任意のプロトコルに対応できるコマンドセットを定義することができる。
【００３８】
上記のように、外部制御機器（図示せず）からの制御コマンドの処理をプロトコル判定部１１１、コマンド検索変換部１１２、リターンコード返信部１１３からなるインターフェイスマネージャ１１０と、プロトコル定義、変換テーブル、リターンコード定義から構成される複数のコマンドセット１２２０、１２２１、…、１２２ｉ、…、１２２ｎをインターフェイス定義１２０として記憶した記憶部１２１を用いて行うことにより、インターフェイスマネージャ１１０は複数のコマンドセットを区別することなく取り扱うことができるようになる。インターフェイスマネージャ１１０は、各コマンドセットの内容（実際に定義されている数値）に対する依存性を持たないため、制御コマンドの体系を変更する場合にコマンドセットの内容のみ変更すれば良く、従来のような高度なソフトウェア知識が要求される内部の組み込みソフトウェアを変更する作業を必要とすることなく、容易にコマンドセットを追加、削除及び更新することができる。また、コマンドセットを記憶する記憶部１２１を書き換え可能な不揮発性メモリまたは電池でバックアップされたメモリ（映像表示装置の商用電源をオフとしてもメモリが消去されないことを考慮）とすることで、容易に外部制御機器に対する制御コマンド体系を変更できる。また、前記記憶部１２１を着脱可能にすることにより、記憶部を交換（例えば前記記憶部１２１を搭載した基板ユニットの交換や前記記憶部１２１として外部記録媒体であるフラシュメモリカードを用い、そのフラシュメモリカードを交換）するだけで制御コマンド体系の変更、修正や追加ができる。
【００３９】
また、複数のコマンドセットのうち少なくとも１つを従来機種の制御コマンドを処理する定義とすることにより、下位互換性を保つことができる。
また、複数のコマンドセットをユーザ公開用と製造者用のコマンドセットに分け、プロトコル定義を変えておくことによりユーザの誤ったコマンドからシステムを保護することができる。
また、外部制御機器（図示せず）とのプロトコルはコマンド毎に変更されることはほとんどないため、プロトコル判定部１１１にて判定したプロトコル判定結果をプロトコル判定部１１１内の図示しない記憶部に記憶しておき、前回の判定結果のプロトコル定義を優先的に検索することにより、複数のプロトコル定義が存在する場合でも高速に判定できる。
【００４０】
図６は第２の実施形態を示しており、図７は第２の実施形態における処理フローチャートを示している。図１に示す第１の実施形態との差異は、インターフェイスマネージャ１１０の構成要素にコマンドフィルタ部１１４が新たに追加されたことである。新たなインターフェイスマネージャを１１０’とする。コマンドフィルタ部１１４はコマンド検索変換部１１２から送られる変換後のコマンドが内部コマンド以外の場合、コマンド検索変換部１１２で変換後のコマンド（図６中の例ではコマンドＳ）を再度プロトコル判定部１１１に送る仕組みを備え、内部コマンドの場合にはそのコマンドを内部コマンド実行部１３０（図示せず）に送る。
【００４１】
図６の実施形態における動作例として、拡張コマンドセット１２２１’、…、１２２ｎ’の変換テーブルは内部コマンドへの変換テーブルではなく、標準コマンドセットのプロトコル定義に従ったコマンドへの変換テーブルを備える。つまり、外部制御機器（図示せず）からの制御コマンドのうち例えば「定義１」である拡張コマンドセット１２２１’に定義されている制御コマンドの集合「コマンドＡ」は、標準コマンドセット１２２０に定義されている制御コマンドの集合「コマンドＳ」へ変換される。
【００４２】
図６の動作例を図７のフローチャートを用いて、拡張コマンドセット１２２１’の制御コマンドの集合「コマンドＡ」がデータ送受信部１０１（図示せず）からインターフェイスマネージャ１１０’に入力される場合の動作について順に説明する。
【００４３】
ステップ１（以下、ステップをＳと略す）ではデータ送受信部１０１（図示せず）にて、外部制御機器（図示せず）からの制御コマンドを受信データとして取得する。Ｓ２では、インターフェイスマネージャ１１０’内のプロトコル判定部１１１にて、Ｓ１で取得した受信データ（例では「コマンドＡ」）のプロトコル判定を行う。Ｓ３では、Ｓ２で判定したプロトコル判定結果（例では「定義１」）に基づいて、コマンド検索変換部１１２にて受信データ（「コマンドＡ」）の検索変換処理を行い、変換後のコマンド（「コマンドＳ」）を得る。コマンドフィルタ部１１４は、Ｓ４で、Ｓ２及びＳ３でのプロトコル判定やコマンド検索変換の結果、該当する制御コマンドが存在しないと判定される場合にはＳ７へ行き、リターンコード返信部１１３’にコマンドが存在しないことを通知し、外部機器に対する返信を行わせる。Ｓ４で該当する制御コマンドが存在する場合にはＳ５へ行き、Ｓ３でのコマンド変換処理後のコマンドが内部コマンドであるかどうかをコマンドフィルタ部１１４にて判定し、内部コマンドでない場合はＳ２に行き、その変換後のコマンドをプロトコル判定部１１１に再処理させる。図６の例では、「コマンドＡ」の検索変換処理で「コマンドＳ」を得るが、「コマンドＳ」は内部コマンドではないため（「コマンドＳ」は標準コマンド）、「コマンドＳ」をプロトコル判定部１１１で再処理させることになる。その再処理では「コマンドＳ」が内部コマンド「コマンドＩ」に検索変換処理されて、Ｓ５のステップでコマンドフィルタ部により内部コマンド「コマンドＩ」と判定される。Ｓ５で内部コマンドと判定されたコマンドは、Ｓ６で内部コマンド実行部１３０により実行される。そして、Ｓ７でリターンコード返信部１１３’は内部コマンドの実行結果を外部制御機器に返信する。
【００４４】
以上の説明のように、拡張コマンドセットで定義されている外部制御機器からの制御コマンドを一度、標準プロトコルとして定義した制御コマンドに変換することにより、拡張コマンドセットを定義する際に内部コマンドについて予め知っておく必要が無くなる。また、組み込みソフトウェアを変更して内部コマンドに変更があった場合でも、標準コマンドセットの変換テーブルも合わせて変更することにより、拡張コマンドセットの制御コマンドについては変更する必要が無く、容易に互換性を保つことができる。
【００４５】
図８は第３の実施形態を示している。本実施形態では、いままで述べてきたインターフェイス定義内のコマンドセットが実行可能なバイナリ実行コードと、そのバイナリ実行コードへの実行アドレスの値から構成されるコマンドセットを取り扱えるようにしたものである。即ち、コマンドセットで定義されたバイナリ実行コードを実行するには、実行アドレスで指定されたアドレスに格納されているバイナリ実行コードを呼び出すようにする。なお、図８において、１２０”は上記のようなコマンドセットからなるインターフェイス定義である。
【００４６】
図８において、コマンドセット例８２２ｉ（複数のコマンドセットのうちの任意の１つを添字ｉを付して代表的に示す）のプロトコル定義、変換テーブル、リターンコード定義の各要素はバイナリ実行コード８０２とそのバイナリ実行コードの実行アドレス８０１の組み合わせから構成されており、プロトコル定義の実行アドレス「Ｆ０００：４０００」はバイナリ実行コード「ＩｓＰｒｏｔｏｃｏｌＶａｌｉｄ（ｖｏｉｄ　＊ｐＰａｒａｍ１）」、変換テーブルの実行アドレス「Ｆ０００：５０００」はバイナリ実行コード「ＣｏｎｖｅｒｔＣｏｍｍａｎｄ（ｖｏｉｄ　＊ｐＰａｒａｍ２）」、リターンコード定義の実行アドレス「Ｆ０００：６０００」はバイナリ実行コード「ＳｅｎｄＲｅｔＣｏｄｅ（ｖｏｉｄ　＊ｐＰａｒａｍ３）」にそれぞれ対応している。つまり、記憶部１２１のアドレス「Ｆ０００：４０００」にはバイナリ実行コード「ＩｓＰｒｏｔｏｃｏｌＶａｌｉｄ（ｖｏｉｄ　＊ｐＰａｒａｍ１）」が配置されていることを意味し、アドレス「Ｆ０００：４０００」にあるバイナリ実行コードを実行すると「ＩｓＰｒｏｔｏｃｏｌＶａｌｉｄ（ｖｏｉｄ　＊ｐＰａｒａｍ１）」が呼び出される。
【００４７】
インターフェイスマネージャ８１０は、コマンドセット例８２２ｉの実行アドレス８０１に記載されたバイナリ実行コード８０２へのアドレスを参照して、バイナリ実行コード８０２を直接実行することにより、それぞれプロトコル判定、コマンド検索変換、リターンコード返信処理を行う。図８の例において、プロトコル判定部８１１のコマンドセット例８２２ｉに対する動作は、プロトコル定義に実行アドレス８０１とバイナリ実行コード８０２が定義されているため、データ送受信部１０１で受信した受信データ（図示せず）をパラメータ（ｐＰａｒａｍ１）とし、実行アドレス「Ｆ０００：４０００」に配置されているバイナリ実行コード「ＩｓＰｒｏｔｏｃｏｌＶａｌｉｄ（ｖｏｉｄ　＊ｐＰａｒａｍ１）」を呼び出す。バイナリ実行コード「ＩｓＰｒｏｔｏｃｏｌＶａｌｉｄ（ｖｏｉｄ　＊ｐＰａｒａｍ１）」はパラメータ（ｐＰａｒａｍ１）として受け取った受信データをもとにプロトコル判定を行い、その結果をコマンド検索変換部８１２に送る。
【００４８】
コマンド検索変換部８１２は、プロトコル判定部８１１と同様に、実行アドレス８０１から実行アドレス「Ｆ０００：５０００」を得たのち、プロトコル判定部８１１の結果をパラメータ（ｐＰａｒａｍ２）として、実行アドレス「Ｆ０００：５０００」のバイナリ実行コード「ＣｏｎｖｅｒｔＣｏｍｍａｎｄ（ｖｏｉｄ　＊ｐＰａｒａｍ２）」を呼び出すことで、コマンド検索変換処理を行い内部コマンドを得る。リターンコード返信部８１３も同様に、実行アドレス８０１から実行アドレス「Ｆ０００：６０００」を得たのち、内部コマンド実行部１３０の結果をパラメータ（ｐＰａｒａｍ３）として、バイナリ実行コード「ＳｅｎｄＲｅｔＣｏｄｅ（ｖｏｉｄ　＊ｐＰａｒａｍ３）」を呼び出し、リターンコード返信処理を行う。
【００４９】
以上の説明のように、インターフェイス定義１２０”内のコマンドセットを実行可能なバイナリ実行コードとそのバイナリ実行コードへの実行アドレスから構成することにより、インターフェイスマネージャ８１０は、制御コマンドと内部コマンド間の相互変換を行う際にバイナリ実行コードへの実行アドレスのみを知っていれば良いため、バイナリ実行コードの処理内容には直接依存しない構成をとることができる。この場合、インターフェイスマネージャ８１０の各機能要素（プロトコル判定部８１１、コマンド検索変換部８１２、リターンコード返信部８１３など）はコマンドセットに定義されたバイナリ実行コード８０２を呼び出すだけであり、コマンドセット内部のデータ構成を予め知っておく必要がない。つまり、コマンドセット内部のデータへのアクセス方法と実質的なコマンド相互変換機能はバイナリ実行コード８０２により実装されることになる。そのため、予めコマンドセットのデータ定義の構成を決める必要が無く、容易に制御コマンドの変更ができる。また、コマンド間の相互変換が算術的規則で定められたコマンドセットの場合、一覧表形式の変換テーブルを用いた場合に比べて実装サイズを小さくすることができる。また、各バイナリ実行コードはＣ言語などのプログラミング言語で記述した後、コンパイルを行いバイナリ実行コード化するため、一覧表形式の変換テーブルでは対応できない暗号化された制御コマンドのデコード処理にもソフトウェアで容易に対応できる。
【００５０】
なお、上記では、記憶部１２１の実行アドレスで指定されたバイナリ実行コードを格納しているアドレスに対応する記憶部は、記憶部１２１に含まれるものとしたが、これに限定されるものではなく、記憶部１２１とは異なる別の記憶部であっても良い。但し、記憶部１２１と同様に、商用電源がオフされてもメモリが消去されないように例えば書き換え可能な不揮発性メモリで、また、着脱自在に構成されていることは当然のことである。
【００５１】
図９は第４の実施形態を示す。図９は外部制御機器からの制御コマンドが複数の信号伝送路を介して複数のデータ送受信部に送受信される場合を示しており、信号伝送路毎にデータ送受信部１０１ｉ（ｉ：１，２，…，ｎ）を設け、さらに各データ送受信部１０１ｉで受信したデータ９１０からインターフェイスマネージャ１１０への入力となる制御コマンド９１１の取り出し処理を行うためのプロトコルスタック処理部９００を設けている。プロトコルスタック処理部９００で取り出された制御コマンド９１１は図１と同様にインターフェイスマネージャ１１０とインターフェイス定義１２０により内部コマンドに変換され、内部コマンド実行部１３０により実行される。
【００５２】
ここでデータ送受信部１０１ｉは、信号伝送路上の電気信号をデータとして受送信するだけであり、そのデータにはインターフェイスマネージャ１１０が必要とする制御コマンド以外に信号伝送路固有の通信規約に従った余分なデータが付加されている場合がある。例えば信号伝送路がイーサネット（Ｒ）の場合、データ送受信部のデータには、ＴＣＰ／ＩＰヘッダなどの上位プロトコル階層の情報が付加されているため、これらを取り除いて制御コマンドのみに加工する必要がある。また、音声認識装置や文字列を使用した制御コマンドの場合は、データ文字列のコード（符号）の統一や大文字・小文字変換といった処理が必要になる。このように、データ送受信部１０１ｉのデータからインターフェイスマネージャが必要とする制御コマンドを取り出すために、プロトコルスタック処理部９００をインターフェイスマネージャ１１０の前に設けている。
【００５３】
図１０は第４の実施形態の変形を示しており、プロトコルスタック処理部をデータ送受信部１０１ｉのそれぞれに固有の処理に分割して、各データ送受信部１０１ｉの後にプロトコルスタック処理部９００ｉ’（ｉ：２，３，…，ｎ）を設けた場合を示している。分割された各プロトコルスタック処理部９００ｉ’は、データ送受信部１０１ｉのデータからインターフェイスマネージャ１１０が必要とする制御コマンドを取り出すために、そのデータ送受信部に特化した処理のみを行う。例えば、データ送受信部３（１０１３）のデータ９１０３からプロトコルスタック処理部３（９００３’）により制御コマンド９１１を取り出す。
【００５４】
図１０の例のように、プロトコルスタック処理部９００’内のプロトコルスタックは全てのデータ送受信部に対し必要なわけではないため、必要な部分のみ設ければ良い。例えば、ＲＳ２３２Ｃ等のシリアル通信はデータ送受信部で受送信したデータがそのまま制御コマンドとなる。その例がデータ送信部１（１０１１）のデータ９１０１の場合である。
【００５５】
以上の説明のように、複数のデータ送受信部に対し必要に応じてプロトコルスタックを設けることにより、インターフェイスマネージャへの入力を統一して取り扱うことができ、外部制御機器への信号伝送路を追加・削除する際に柔軟に対応することができる。
【００５６】
【発明の効果】
以上説明したように、本発明では、外部制御機器からの制御コマンドを内部コマンドに変換する仕組みを提供し、その変換処理に必要な定義データを例えば書き換え可能な不揮発性メモリ等上に配置することにより、定義データの変更のみで容易に制御コマンドを追加、削除及び更新することができるという利点を有する。
【００５７】
さらに、制御コマンドから内部コマンドへの変換処理をインターフェイスマネージャにより行うため、外部制御機器との接続経路が複数存在する場合でも、１つの信号伝送路に対してデータ送受信部とプロトコルスタック処理部を設けることで、インターフェイスマネージャへの入力を制御コマンドに統一することができるため、外部制御機器との接続経路を追加・削除する場合に対しても柔軟に対応することができるという利点を有する。
【図面の簡単な説明】
【図１】本発明の実施の形態である映像表示装置のコマンド変換機能の基本構成を示す図。
【図２】コマンド変換定義及び変換例
【図３】プロトコル判定部の判定動作を説明するための図
【図４】コマンド検索変換部のコマンド変換動作を説明するための図
【図５】内部コマンド実行後の外部制御機器に対する返信動作の動作説明図
【図６】第２の実施形態を示す図
【図７】第２の実施形態における処理フローチャートを示す図
【図８】第３の実施形態を示す図
【図９】複数の物理的接続が存在する場合の動作説明図
【図１０】図９の変形例
【符号の説明】
１００…信号伝送路
１０１、１０１１、１０１２、…、１０１ｉ、…、１０１ｎ…データ送受信部
１１０、１１０’…インターフェイスマネージャ、１１１…プロトコル判定部
１１２…コマンド検索変換部、１１３、１１３’…リターンコード返信部
１１４…コマンドフィルタ部、１２０、１２０’…インターフェイス定義、１２１…記憶部
１２２０…標準コマンドセット
１２２１、…、１２２ｉ、…、１２２ｎ…拡張コマンドセット、
１２２１’、１２２２’　、…、１２２ｉ’、…、１２２ｎ’…拡張コマンドセット
１３０…内部コマンド実行部、３０１…プロトコル定義例、３１０…受信データ
３１１…コマンド変換要素、４０１…変換テーブル１の例
４０２…変換テーブル１の例の変換定義
４１０…内部コマンド、５０２…リターンコード定義例、５１０…リターンコード、
５１１…コマンド実行結果
８０１…アドレステーブル、８０２…バイナリ実行コード、８１０…インターフェイスマネージャ
８１１…プロトコル判定部、８１２…コマンド検索変換部、８１３…リターンコード返信部
９００、９００’…プロトコルスタック処理部
９００２’、９００３’、…、９００ｉ’、…、９００ｎ’…プロトコルスタック処理部
９１０１、９１０２、９１０３、…、９１０ｉ、…９１０ｎ…データ
９１１…制御コマンド
【図１】
2004020976.tif 000003
【図２】
2004020976.tif 000004
【図３】
2004020976.tif 000005
【図４】
2004020976.tif 000006
【図５】
2004020976.tif 000007
【図６】
2004020976.tif 000008
【図７】
2004020976.tif 000009
【図８】
2004020976.tif 000010
【図９】
2004020976.tif 000011
【図１０】
2004020976.tif 000012