プロジェクター、制御方法、表示方法ならびにコンピュータープログラム
【課題】画像表示装置を利用するための労力を軽減することのできる技術を提供することを目的とする。
【解決手段】画像供給装置の汎用インターフェースに画像表示装置が接続される。画像表示装置のデバイス種類は、画像表示デバイスでない特定の汎用デバイスとして、画像供給装置に識別される。そして、画像供給装置は、表示のための画像を、汎用デバイスとして識別された画像供給装置に送信する。画像表示装置は、汎用デバイスとして画像を受け取って表示する。
【解決手段】画像供給装置の汎用インターフェースに画像表示装置が接続される。画像表示装置のデバイス種類は、画像表示デバイスでない特定の汎用デバイスとして、画像供給装置に識別される。そして、画像供給装置は、表示のための画像を、汎用デバイスとして識別された画像供給装置に送信する。画像表示装置は、汎用デバイスとして画像を受け取って表示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像供給装置と画像表示装置との間の通信に関するものである。
【背景技術】
【０００２】
従来より、データ記憶装置や入力装置、画像表示装置といった種々の周辺装置が、コンピュータに接続され、利用されている。このような種々の周辺装置を手軽に接続するための汎用インターフェースとして、ＵＳＢ（Universal Serial Bus）インターフェースが、しばしば利用されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−６９９９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、コンピュータと、インターフェースを介して接続された周辺装置と、の間でデータ通信を行うためには、その周辺装置の種類に適した通信プロトコルが利用されている。例えば、プロジェクタのような画像表示装置を、画像信号専用のインターフェースの代わりに、このような汎用のインターフェースに接続する場合には、画像表示装置の機種毎に異なる専用の通信プロトコルが利用されている。
【０００５】
ところが、このような専用プロトコルのためのインターフェース制御用プログラム（デバイスドライバとも呼ばれる）の利用には、種々の作業が要求されていた。例えば、ユーザは、このような専用ドライバを自分でコンピュータにインストールしていた。また、画像表示装置の製造者は、このような専用ドライバを新たに開発していた。このように、画像表示装置を利用するために多大な労力が要求されていた。
【０００６】
なお、このような問題は、ＵＳＢインターフェースに限らず、複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに共通する問題であった。また、このような問題は、コンピュータに画像表示装置を接続する場合に限らず、一般に、インターフェースを介して画像供給装置から画像表示装置に画像を供給して表示させるシステムに共通する問題であった。
【０００７】
本発明は、上記の課題を解決するためになされたものであり、画像表示装置を利用するための労力を軽減することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述の課題の少なくとも一部を解決するため、本発明の第１の態様に係る画像表示装置は、画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置であって、前記インターフェースを介したデータ通信を制御する通信制御部と、前記画像データに基づいて画像を表示する画像表示部と、を備え、前記通信制御部は、前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信し、前記通信制御部は、前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する。
【０００９】
この画像表示装置によれば、汎用デバイスとして画像表示装置が識別されるので、画像供給装置と画像表示装置との間でのデータ通信を容易に行うことができる。その結果、画像表示装置を利用するための労力を軽減することができる。
【００１０】
ここで、前記インターフェースは、ＵＳＢインターフェースであり、前記識別情報は、マスストレージクラスに設定されていることが好ましい。
【００１１】
ＵＳＢインターフェースは、装置間の接続が容易であり、手軽に利用することができる。また、マスストレージクラスは、データ記憶装置に素早くデータを書き込むために、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送を素早く行うことが可能となる。
【００１２】
上記画像表示装置は、さらに、前記画像供給装置がアクセス可能なデータ記憶部を備え、前記通信制御部は、（ｉ）前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを受信した場合には、受信したデータを前記データ記憶部に供給し、（ｉｉ）データリードのための通信コマンドとは異なる所定の通信コマンドを受信した場合には、受信したデータを画像データとして前記画像表示部に供給することが好ましい。
【００１３】
この構成によれば、画像表示装置は、画像データを受信するとともに、データ記憶部に格納された種々のデータを画像供給装置に提供することができる。
【００１４】
さらに、前記データ記憶部は、前記マスストレージクラスよる通信を利用して前記画像表示装置に前記画像データを送信する機能をコンピュータに実現させるための画像転送プログラムを格納することが好ましい。
【００１５】
この構成によれば、画像データを画像表示装置に送信するためのプログラムを、容易に画像供給装置に提供することができるので、画像表示装置を利用するための労力を軽減することができる。
【００１６】
上記画像表示装置において、前記画像転送プログラムは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を前記コンピュータに実現させることが好ましい。
【００１７】
この構成によれば、一部の領域のみが変化した画像を画像表示装置に表示させる場合には、変化した領域を含む一部の領域のみが送信されるので、画像供給装置と画像表示装置との間で転送されるデータ量を低減することができる。その結果、画像表示装置によって表示される画像の更新頻度を高めることが可能となる。
【００１８】
上記各画像表示装置において、前記画像表示部は、受信済みの画像データによって表示されるべき現行画像の内の一部の領域のみを表す更新画像データを受信した場合に、前記一部の領域のみを更新することが好ましい。
【００１９】
この構成によれば、一部の領域のみが変化した画像を画像表示装置に表示させる場合には、変化した領域を含む一部の領域のみを送信すればよいので、画像供給装置と画像表示装置との間で転送されるデータ量を低減することができる。その結果、画像表示装置によって表示される画像の更新頻度を高めることが可能となる。
【００２０】
また、本発明の第２の態様に係る画像供給装置は、画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させるための画像供給装置であって、前記画像表示装置が接続されるインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースと、前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する通信制御部と、前記通信制御部を制御することによって、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する画像転送処理モジュールと、を備える。
【００２１】
この画像供給装置によれば、汎用デバイスとして画像表示装置が識別されるので、画像供給装置と画像表示装置との間でのデータ通信を容易に行うことができる。その結果、画像表示装置を利用するための労力を軽減することができる。
【００２２】
上記画像供給装置において、前記インターフェースは、ＵＳＢインターフェースであり、前記通信制御部は、前記画像表示装置のデバイス種類をマスストレージクラスとして識別することが好ましい。
【００２３】
ＵＳＢインターフェースは、装置間の接続が容易であり、手軽に利用することができる。また、マスストレージクラスは、データ記憶装置に素早くデータを書き込むために、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送を素早く行うことが可能となる。
【００２４】
上記画像供給装置において、前記画像表示装置は、さらに、前記画像供給装置がアクセス可能なデータ記憶部を備え、前記画像供給装置は、さらに、前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを利用することによって、前記データ記憶部に格納されたデータを読み出すデータ読み出しモジュールを備え、前記画像転送処理モジュールは、データリードのための通信コマンドとは異なる所定の通信コマンドを利用することによって、前記画像データを送信することが好ましい。
【００２５】
この構成によれば、画像供給装置は、画像データを送信するとともに、データ記憶部に格納された種々のデータを利用することができる。
【００２６】
上記各画像供給装置において、前記画像転送処理モジュールは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を有することが好ましい。
【００２７】
この構成によれば、一部の領域のみが変化した画像を画像表示装置に表示させる場合には、変化した領域を含む一部の領域のみが送信されるので、画像供給装置と画像表示装置との間で転送されるデータ量を低減することができる。その結果、画像表示装置によって表示される画像の更新頻度を高めることが可能となる。
【００２８】
上記画像供給装置において、さらに、画像の描画命令を発行可能なアプリケーションプログラムと、前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、を備え、前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、前記画像転送処理モジュールは、（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、（ｉｉ）前記第１の変化領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、（ｉｉｉ）取得した画像部分を、前記第１と第２の変化領域の和である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することとしてもよい。
【００２９】
この構成によれば、特定の描画命令が発行された場合には、描画モジュールの代わりにフック処理モジュールがその描画命令をフックして取得し、汎用メモリ内の画像を描画するので、転送対象となる画像の全体をＶＲＡＭからＲＡＭ（汎用メモリ）に転送する場合に比べて転送処理全体のスピードを向上させることができる。また、第２の変化領域のうちで第１の変化領域に含まれない領域はフック処理モジュールでは描画されていない領域であるが、この領域の画像はフレームメモリから取得するので、欠落無しに画像を転送することが可能である。
【００３０】
上記画像供給装置において、さらに、画像の描画命令を発行可能なアプリケーションプログラムと、前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、を備え、前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、前記画像転送処理モジュールは、（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、（ｉｉ）前記第２の変化領域のうちで前記第１の変化領域にも含まれる領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、（ｉｉｉ）取得した画像部分を、前記第２の変化領域と同一である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することとしてもよい。
【００３１】
この構成によれば、特定の描画命令が発行された場合には、描画モジュールの代わりにフック処理モジュールがその描画命令をフックして取得し、汎用メモリ内の画像を描画するので、転送対象となる画像の全体をＶＲＡＭからＲＡＭ（汎用メモリ）に転送する場合に比べて転送処理全体のスピードを向上させることができる。
【００３２】
なお、本発明は種々の形態で実現することが可能であり、例えば、画像表示システム、画像表示システムを構成する画像供給装置及び画像表示装置、画像供給装置に利用されるフック処理モジュール及び画像転送処理モジュール、画像供給方法及び画像表示方法、それら方法又は装置を実現するためのコンピュータプログラム、それらのコンピュータプログラムを記録した記録媒体などの種々の態様で実現することが可能である。
【図面の簡単な説明】
【００３３】
【図１】本発明の一実施例として画像表示システムの構成を示す説明図。
【図２】コンピュータ１００とプロジェクタ２００の内部構成を示すブロック図。
【図３】第１実施例におけるソフトウェア構成の詳細を示す説明図。
【図４】プロジェクタ２００をコンピュータ１００に接続したときに実行される接続処理の手順を示すフローチャート。
【図５】画像表示処理の手順を示すフローチャート。
【図６】Ｄ９コマンドの一例を示す説明図。
【図７】第２実施例における画像表示処理の手順を示すフローチャート。
【図８】第２実施例における画像表示処理の一例の具体的な手順を示すフローチャート。
【図９】第３実施例におけるソフトウェア構成の詳細を示す説明図。
【図１０】第３実施例における接続処理の手順を示すフローチャート。
【図１１】第３実施例における画像表示処理の手順を示すフローチャート。
【図１２】画面内の変化部分をキャプチャするためのコンピュータのソフトウェアとハードウェアの階層構造を示す説明図。
【図１３】実施例における変化領域情報と画像データ格納領域の例を示す説明図。
【図１４】第３実施例におけるフック処理モジュール４００と画像転送プログラム５００ａの動作を示すフローチャート。
【図１５】ステップＳ２０の詳細手順を示すフローチャート。
【図１６】第３実施例における変化領域と画面更新領域との関係を示す説明図。
【図１７】画面更新領域の最適化処理の内容を示す説明図。
【図１８】ステップＳ２２の詳細手順を示すフローチャート。
【図１９】第４実施例における変化領域と画面更新領域との関係を示す説明図。
【図２０】プロジェクタ２００ａの要求に応じる処理の手順を示すフローチャート。
【発明を実施するための形態】
【００３４】
次に、この発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．第１実施例：
Ｂ．第２実施例：
Ｃ．第３実施例：
Ｄ．第４実施例：
Ｅ．第５実施例：
Ｆ．変形例：
【００３５】
Ａ．第１実施例：
図１は本発明の一実施例として画像表示システムの構成を示す説明図である。本実施例の画像表示システム１０は、画像供給装置としてのパーソナルコンピュータ１００（以下「ＰＣ１００」とも呼ぶ）と、画像表示装置としてのプロジェクタ２００と、コンピュータ１００とプロジェクタ２００とをつなぐＵＳＢケーブル３００と、を備えている。コンピュータ１００は、ＵＳＢケーブル３００を介して画像をプロジェクタ２００供給して、プロジェクタ２００に画像を投写させて投写表示画面７０に表示させる機能を有している。
【００３６】
図２は、コンピュータ１００とプロジェクタ２００の内部構成を示すブロック図である。コンピュータ１００は、ＣＰＵ１０２と、ＲＯＭ１０４と、汎用メモリ（「システムメモリ」とも呼ぶ）としてのＲＡＭ１０６と、ハードディスクドライブ１０８と、キーボードやポインティングデバイスなどで構成される入力部１１０と、ＵＳＢインターフェース部１１２と、フレームメモリとしてのＶＲＡＭ１１４と、グラフィックコントローラ１１６と、液晶ディスプレイなどの表示デバイス１１８と、これら各要素を接続するバス１２０と、を備えている。
【００３７】
ＲＡＭ１０６には、アプリケーションプログラム１２２と、グラフィカルデバイスインターフェース（ＧＤＩ：Graphics Device Interface）１２４と、ディスプレイドライバ１２６と、ファイルシステムモジュール１３０と、ＳＣＳＩドライバ１３２と、マスストレージドライバ１３４と、ＵＳＢモジュール１３６と、画像転送プログラム５００と、を含む各種コンピュータプログラムが格納されている。なお、ＧＤＩ１２４と、ディスプレイドライバ１２６と、ファイルシステムモジュール１３０と、ＳＣＳＩドライバ１３２と、マスストレージドライバ１３４と、ＵＳＢモジュール１３６は、オペレーティングシステム（ＯＳ）の一部として機能する。なお、本実施例においては、オペレーティングシステムとして、マイクロソフト社によって提供されるWindows（登録商標）を想定している。このような各種コンピュータプログラムは、フレキシブルディスクやＣＤ−ＲＯＭ等の、コンピュータ読み取り可能な記録媒体に記録された形態で提供される。
【００３８】
ＧＤＩ１２４は、表示装置（例えば、コンピュータ１００の表示デバイス１１８）や印刷装置（図示せず）などへの描画を統一的に管理しているコンピュータプログラムである。良く知られているように、ＧＤＩ１２４は、「ＧＤＩ関数」と呼ばれる描画に関するアプリケーションプログラムインタフェース（ＡＰＩ：Application Program Interface）を各種のアプリケーションプログラムに対して提供している。なお、ＡＰＩとは、一般に、アプリケーションプログラムがオペレーティングシステムの持つ様々な機能を利用するための手続きの集まりを言う。
【００３９】
アプリケーションプログラム１２２は、ＧＤＩ１２４に対して、例えばプレゼンテーションファイルに含まれているプレゼンテーションシートの画像の描画要求を発行する。通常は、描画要求には、画像の出力先に関する情報（即ち、画像を表示装置に出力するか、印刷装置に出力するかを指定する情報）も含まれている。ＧＤＩ１２４は、アプリケーションプログラム１２２から出された描画要求を受け取り、その描画要求に基づいて画像の出力先をチェックし、その出力先が表示装置であれば、ディスプレイドライバ１２６に対して描画要求を渡す。ディスプレイドライバ１２６は、受け取った描画要求に従ってＶＲＡＭ１１４内に画像データを描画する。
【００４０】
コンピュータ１００の他の構成要素については、後述する。
【００４１】
一方、プロジェクタ２００は、ＣＰＵ２０２と、ＲＯＭ２０４と、ＲＡＭ２０６と、各種の操作ボタンを含む入力部２１０と、ＵＳＢインターフェース部２１２と、画像処理部２１４と、光源ランプと液晶パネルと投写光学系を含む投写部２１６と、これら各要素を接続するバス２１８と、を備えている。ＲＯＭ２０４には、画像表示モジュール２４０と、ディスクイメージ２２４と、コマンドディスパッチャモジュール２２６（以下、単に「ディスパッチャ２２６」とも呼ぶ）と、データ管理モジュール２３０と、ＳＣＳＩドライバ２３２と、マスストレージドライバ２３４と、ＵＳＢモジュール２３６と、を含む各種コンピュータプログラムが格納されている。
【００４２】
図３は、第１実施例におけるソフトウェア構成の詳細を示す説明図である。図３では、各構成要素が、データ通信の階層と同じ順番に並んで配置されている。ＵＳＢモジュール１３６、２３６は、それぞれ、ＵＳＢインターフェース部１１２、２１２（図２）を制御し、ＵＳＢプロトコルを解釈することによってデータ通信を行う。ＵＳＢモジュール１３６、２３６の上位層に設けられたマスストレージドライバ１３４、２３４は、マスストレージクラスの通信プロトコルに従ってデータ通信を行う。マスストレージドライバ１３４、２３４の上位層に設けられたＳＣＳＩドライバ１３２、２３２は、ＳＣＳＩコマンドセットを利用してデータ通信を行う。コンピュータ１００のファイルシステムモジュール１３０は、ＳＣＳＩドライバ１３２にデータアクセス要求を発行することによって、ファイルシステムの管理を行う。一方、プロジェクタ２００のデータ管理モジュール２３０は、ディスパッチャ２２６、ＳＣＳＩドライバ２３２を介してコンピュータ１００からのアクセス要求を受信し、この要求に応じて、ディスクイメージ２２４に対するアクセスを中継する。
【００４３】
また、図３には、画像転送プログラム５００と画像表示モジュール２４０との詳細な構成も示されている。画像転送プログラム５００は、キャプチャモジュール５１０と、データ生成モジュール５２０と、ＳＣＳＩラッパモジュール５３０と、を含んでいる。画像表示モジュール２４０は、画像展開モジュール２４２とデータ取得モジュール２４４とを含んでいる。これらの詳細については後述する。
【００４４】
図４は、プロジェクタ２００をコンピュータ１００に接続したときに実行される接続処理の手順を示すフローチャートである。まず、プロジェクタ２００は、ＳＣＳＩドライバ２３２（図３）と、マスストレージドライバ２３４と、ＵＳＢモジュール２３６とによって、ＣＤ−ＲＯＭドライブとして動作する（ステップＳ１００）。
【００４５】
次に、コンピュータ１００のＵＳＢモジュール１３６は、ＵＳＢケーブル３００を介してプロジェクタ２００がコンピュータ１００に接続されたことを検出し（ステップＳ１０４）、この検出に応じてプロジェクタ２００に装置構成情報を要求する（ステップＳ１０８）。
【００４６】
プロジェクタ２００のＵＳＢモジュール２３６は、この要求に応じて、装置構成情報をコンピュータ１００に送信する（ステップＳ１１２）。送信される装置構成情報には、プロジェクタ２００がＵＳＢ規格に準じたデータ記憶装置として動作することを表す情報が含まれている。具体的には、装置構成情報には、ＵＳＢデバイスのデバイスクラス（インターフェースクラス）が「マスストレージクラス」であることを示す情報が含まれている。また、よく知られているように、「マスストレージクラス」で利用可能なコマンドセットは、インターフェースサブクラスによって特定される。第１実施例のプロジェクタ２００は、「ＳＣＳＩコマンドセット」に対応していることとしている。そこで、装置構成情報には、サブクラスが「ＳＣＳＩコマンドセット」であることを示す情報も含まれる。なお、サブクラスとしては、他の種々のクラス（例えば、「ＡＴＡＰＩ」）を採用可能である。また、装置構成情報には、他の種々のＵＳＢディスクリプタも含まれている。
【００４７】
コンピュータ１００（図３）のＵＳＢモジュール１３６は、この装置構成情報を受信したことに応じて、プロジェクタ２００をマスストレージクラスに分類される装置であると識別し、ＯＳに標準的に備えられている汎用のマスストレージドライバ１３４をロードする（ステップＳ１１６）。マスストレージドライバ１３４は、動作中のＯＳプロセス内に組み込まれる。これにより、コンピュータ１００は、マスストレージドライバ１３４を利用することによって、プロジェクタ２００とデータ通信を行うことが可能となる。
【００４８】
なお、マスストレージドライバ１３４は、ＵＳＢのクラスドライバに相当する。クラスドライバは、ＵＳＢバスのドライバ（図３の例では、ＵＳＢモジュール１３６）の上位層に位置し、ＵＳＢデバイスの種類に応じた通信プロトコルに従ってＵＳＢデバイスとの通信を行う通信制御モジュールである。ＵＳＢ規格では、ＵＳＢデバイスの種類が複数のクラスに分類されている。そして、クラス毎（すなわち、デバイス種類毎）に異なる通信プロトコルが利用されている。ここで、種々の機能を有するＵＳＢデバイスを利用可能とするために、ベンダ独自のクラス（Vendor Specific Class）を定義することも可能である。この場合には、専用の通信プロトコル（すなわち、専用のクラスドライバ）が利用される。
【００４９】
一方、いくつかの代表的なクラスについては、装置間のデータ通信を容易に行うために、通信プロトコルが標準化されている。「マスストレージクラス」は、このようなクラスの一つである。マスストレージドライバ１３４は、マスストレージクラス用の通信プロトコルに従ってデータ通信を行う。このようなマスストレージドライバ１３４は、特定の製造者のデータ記憶装置に限らず、種々の製造者のデータ記憶装置（例えば、ＣＤ−ＲＯＭドライブやＤＶＤ−ＲＯＭドライブ、ハードディスクドライブ、半導体メモリ）に共用される。同様に、標準化された通信プロトコルを利用する汎用のデータ記憶装置（例えば、ＣＤ−ＲＯＭドライブ）は、特定の製造者のコンピュータに限らず、種々の製造者のコンピュータ（例えば、パーソナルコンピュータや情報携帯端末）に対して共通に利用可能である。
【００５０】
また、本実施例では、マスストレージドライバ１３４（図３）とともに、ＳＣＳＩドライバ１３２もロードされる。この際、ＳＣＳＩドライバ１３２は、プロジェクタ２００のＳＣＳＩドライバ２３２から、プロジェクタ２００がＣＤ−ＲＯＭドライブであることを示す情報を取得する。これにより、ファイルシステムモジュール１３０は、ＳＣＳＩドライバ１３２を介してＳＣＳＩコマンドをプロジェクタ２００に送信することにより、プロジェクタ２００（ディスクイメージ２２４）をＣＤ−ＲＯＭドライブとして利用可能である。なお、プロジェクタ２００は、ＣＤ−ＲＯＭドライブに限らず、種々のデータ記憶装置（例えば、ＤＶＤ−ＲＯＭドライブや、ハードディスクドライブ）として識別されてもよい。いずれの場合も、ディスクイメージ２２４からのデータ読み出しは、ファイルシステムモジュール１３０とＳＣＳＩドライバ１３２とによって行われる。このように、ファイルシステムモジュール１３０とＳＣＳＩドライバ１３２との全体は、本発明における「データ読み出しモジュール」に相当する。
【００５１】
次のステップＳ１２０では、コンピュータ１００は、ＣＤ−ＲＯＭドライブとして認識したプロジェクタ２００に記憶されているオートランプログラムを実行する。これにより、ディスクイメージ２２４（図３）に記録された画像転送プログラム５００が、プロジェクタ２００からコンピュータ１００へ送信され（ステップＳ１２４）、そして、画像転送プログラム５００が起動する（ステップＳ１２８）。Windowsオペレーティングシステムは、ＣＤ−ＲＯＭのルートフォルダに、「Autorun.inf」というファイルが記録されていると、このファイルによって指定された任意のプログラムの実行を行う。そこで、本実施例ではこの機能を利用して、ディスクイメージ２２４に記録された画像転送プログラム５００を実行することとしている。
【００５２】
なお、オペレーティングシステムの設定によっては、オートランプログラムの自動実行機能が無効になっている場合がある。また、オペレーティングシステムの中には、自動実行機能を利用できないものもある。このような場合には、ユーザの指示に応じて、コンピュータ１００が、画像転送プログラム５００をプロジェクタ２００（ディスクイメージ２２４）から取得してもよい。また、プロジェクタ２００に格納された画像転送プログラム５００の代わりに、別のＣＤ−ＲＯＭ等の記録媒体に記録された画像転送プログラム５００や、インターネットからダウンロードした画像転送プログラム５００を利用してもよい。
【００５３】
起動した画像転送プログラム５００は、プロジェクタ２００を利用した画像表示処理を開始する。図５は、画像表示処理の手順を示すフローチャートである。最初のステップＳ２００では、キャプチャモジュール５１０（図３）は、表示デバイス１１８（図２）によって表示されている画像をキャプチャする。画像のキャプチャ方法としては、任意の方法を採用可能である。例えば、画像をキャプチャするためのＧＤＩ関数を呼び出してもよく、他の描画用ＡＰＩを利用してもよい。また、キャプチャモジュール５１０が、直接に、ＶＲＡＭ１１４から画像データを取得することとしてもよい。なお、第１実施例では、表示デバイス１１８によって表示されている表示画面の全体がキャプチャされる。
【００５４】
次のステップＳ２０４では、データ生成モジュール５２０は、キャプチャによって取得されたキャプチャ画像データを用いて、表示用データを生成する。第１実施例では、キャプチャ画像データを圧縮することによって、表示用データが生成される。圧縮のアルゴリズムとしては、任意のものを採用可能である。ただし、圧縮せずに、表示用データを生成してもよい。これは、後述する他の実施例についても同じである。
【００５５】
次に、データ生成モジュール５２０は、ＳＣＳＩラッパモジュール５３０に対して、表示用データを送信する命令を発行する。ＳＣＳＩラッパモジュール５３０は、この命令に応じて、表示用データを送信するための特別なＳＣＳＩコマンド（以下「Ｄ９コマンド」とも呼ぶ）を生成する。図６は、Ｄ９コマンドの一例を示す説明図である。このＤ９コマンドは、ＳＣＳＩの規定で定められているコマンドデスクリプターブロック（ＣＤＢ：Command Descriptor Block）の構造に準じている。この理由は、ＳＣＳＩドライバ１３２（図３）と同様に、マスストレージドライバ１３４を利用することによってプロジェクタ２００とデータ通信を行うためである。
【００５６】
０バイト目は、オペレーションコード（以下「ＯＰコード」とも呼ぶ）を表している。ＯＰコードはコマンドを識別するコードであり、「リード」や「ライト」といったコマンド毎に所定のコードが予め割り当てられている。第１実施例では、画像転送プログラム５００によって発行されたＳＣＳＩコマンドには、「Ｄ９ｈ（ｈは１６進表記を意味する。以下同様）」が割り当てられる。これにより、ＯＰコードが「Ｄ９ｈ」である場合には、そのコマンドが画像転送プログラム５００によって発行されたものであると判定できる。ＯＰコードが「Ｄ９ｈ」以外の場合には、そのコマンドがＳＣＳＩドライバ１３２によって発行されたものであると判定できる。
【００５７】
なお、画像転送プログラム５００によって発行されたＳＣＳＩコマンドを識別するＯＰコードとしては、「Ｄ９ｈ」に限らず任意のコードを採用可能である。ただし、ディスクイメージ２２４のデータリードのためのＳＣＳＩコマンドのコードとは異なるコードを採用することが好ましい。こうすれば、画像データの転送と、ディスクイメージ２２４のリードと、を両立させることができる。なお、データリードのためのコマンドとは、データ記憶装置をインターフェースに接続してから、通信を確立し、データリードを完了するまでの一連の処理に利用されるコマンドを意味している。このようなコマンドには、例えば、インクワイアリ（inquiry）コマンドやリード（READ）コマンドが含まれる。
【００５８】
２バイト目は、ＵＤコマンドコードを表している。ＵＤコマンドコードは、画像転送プログラム５００が発行するコマンドの具体的な内容を識別するコードである。画像転送プログラム５００が複数種類のコマンドを発行する場合には、これらのコマンドがＵＤコマンドコードによって識別される。従って、ＯＰコードとＵＤコマンドコードとの組み合わせによって、画像転送プログラム５００によって発行されたコマンドを識別することができる。だたし、画像転送プログラム５００によって発行されるコマンドが、画像データ送信コマンドのみである場合には、ＵＤコマンドコードを省略してもよい。
【００５９】
３バイト目から６バイト目は、送信されるデータサイズを表している。このデータサイズは、このＳＣＳＩコマンドに続けて送信されるデータのサイズを意味している。後述するように、このＤ９コマンドに続けて表示用データが送信されるので、データサイズは、表示用データのサイズに設定される。
【００６０】
７バイト目は、ＣＥフラグを表している。ＣＥフラグは、送信されるデータの続きの有無を示すフラグである。データを複数の部分データに分割して送信する場合がある。この場合、最後の部分データを送信するためのＤ９コマンドでは、ＣＥフラグが「Ｅ（終了）」に設定され、他の部分データを送信するためのＤ９コマンドでは、ＣＥフラグが「Ｃ（継続）」に設定される。データを分割せずに送信する場合には、ＣＥフラグは「Ｅ」に設定される。
【００６１】
Ｄ９コマンドの他の部分は、所定の値に設定される。これらの値は、ＳＣＳＩの規定に従ったデータ通信に利用される（詳細は省略）。
【００６２】
Ｄ９コマンドが生成されたら、ＳＣＳＩラッパモジュール５３０は、このＤ９コマンド（ＣＤＢ）と表示用データとを送信する命令をマスストレージドライバ１３４に対して発行する。すると、マスストレージドライバ１３４は、Ｄ９コマンドを送信するためのコマンドブロックラッパ（ＣＢＷ：Command Block Wrapper）を生成する。ＣＢＷは、マスストレージクラスを利用してＳＣＳＩコマンドを送信するためのデータであり、ＣＤＢを格納している。そして、マスストレージドライバ１３４は、ＵＳＢモジュール１３６を制御することによって、ＣＢＷと表示用データとをこの順番に送信する。
【００６３】
図５には、送信されるＣＢＷと表示用データＴＤとが示されている。表示用データＴＤは、ヘッダＩｍｇＨと、圧縮された画像データＩｍｇＤとを含んでいる。ヘッダＩｍｇＨは、圧縮形式（アルゴリズム）と、画像の高さ（ドット数）及び幅（ドット数）と、画面内における画像の位置と、を表す情報を含んでいる。画面内の位置は、例えば、画像データＩｍｇＤによって表される画像の基準点（通常は左上の角のドット）の画面内の位置によって表される。なお、第１実施例では、表示用データＴＤは、分割されずに送信される。
【００６４】
コンピュータ１００は、以上説明した画像のキャプチャと（Ｓ２００）、ＣＢＷ（Ｄ９コマンド）と表示用データＴＤとの送信と（Ｓ２０４）、を繰り返し実行する。
【００６５】
一方、プロジェクタ２００では、ＵＳＢモジュール２３６、マスストレージドライバ２３４によってＣＢＷ（Ｄ９コマンド）と表示用データＴＤとが受信される（ステップＳ２２０）。次のステップＳ２２４では、ディスパッチャ２２６は、ＣＢＷに格納されたＳＣＳＩコマンドのＯＰコードが「Ｄ９ｈ」であるか否かを判断する。ＯＰコードが「Ｄ９ｈ」である場合には、次のステップＳ２３０で、ディスパッチャ２２６は、受信されたデータをデータ取得モジュール２４４に供給する。供給されるデータには、ＳＣＳＩコマンドと、そのコマンドと共に送信されたデータ（すなわち、ＣＢＷと表示用データＴＤ）が含まれる。次のステップＳ２３４では、データ取得モジュール２４４は、表示用データＴＤを抽出して画像展開モジュール２４２に供給する。画像展開モジュール２４２は、ヘッダＩｍｇＨで指定された圧縮形式に従って画像データＩｍｇＤを伸長する。そして、画像展開モジュール２４２は、ヘッダＩｍｇＨの情報（高さ、幅、位置）と伸長された画像データとに従って画像処理部２１４（図２）を制御し、画像処理部２１４によって画像処理部２１４内の表示メモリ（図示せず）に画像データを展開させる。この際、画像展開モジュール２４２は、投写部２１６の解像度（画素数）と、ヘッダＩｍｇＨの情報と、に応じた解像度変換処理を実行してもよい。
【００６６】
以上の結果、プロジェクタ２００は、図１に示すように、投写表示画面７０に画像を表示することができる。このように、画像表示モジュール２４０は、プロジェクタ２００が画像データを受信したことに応じて、画像を表示する。従って、コンピュータ１００が画像データの送信を繰り返し実行することによって、プロジェクタ２００によって表示される画像も繰り返し更新される。
【００６７】
次のステップＳ２３８では、データ取得モジュール２４４は、正常に表示用データＴＤを受信したことを表す応答を送信する命令をマスストレージドライバ２３４に対して発行する。すると、マスストレージドライバ２３４は、応答を送信するためのコマンドステイタスラッパ（ＣＳＷ：Command Status Wrapper）を生成する。ＣＳＷは、マスストレージクラスを利用してＳＣＳＩのステータス応答を送信するためのデータである。そして、マスストレージドライバ２３４は、ＵＳＢモジュール２３６を制御することによって、ＣＳＷを送信する。
【００６８】
一方、ＯＰコードが「Ｄ９ｈ」とは異なる場合には（Ｓ２２４：Ｎｏ）、次のステップＳ２９０で、ディスパッチャ２２６は、受信されたデータをＳＣＳＩドライバ２３２に供給する。供給されるデータには、ＳＣＳＩコマンドと、そのコマンドと共に送信されたデータが含まれる。ただし、ＳＣＳＩコマンドのみが受信される場合には、ＳＣＳＩコマンドのみが供給される（例えば、ＲＥＡＤコマンドが発行される場合）。次のステップＳ２９４では、データ管理モジュール２３０は、ＳＣＳＩドライバ２３２を介して受け取ったＳＣＳＩコマンドに従って、ディスクイメージ２２４に対するアクセスを中継する（例えば、ディスクイメージ２２４に格納されたデータがコンピュータ１００に送信される）。なお、ＳＣＳＩドライバ２３２とデータ管理モジュール２３０とディスクイメージ２２４との全体は、本発明における「データ記憶部」に相当する。
【００６９】
次のステップＳ２９８では、データ管理モジュール２３０は、コマンドの実行結果を表すステータス応答をコンピュータ１００に送信する。この処理は、ステップＳ２３８と同様に行われる。なお、画像転送プログラム５００がコンピュータ１００に送信される場合には、これらのステップＳ２９０〜Ｓ２９８の処理が実行される。
【００７０】
以上のように、第１実施例は、以下のような種々の特徴と利点を有している。第１の特徴点は、プロジェクタ２００が、プロジェクタとは異なる汎用デバイス（マスストレージクラス）として識別される点である。プロジェクタ２００のＵＳＢモジュール２３６は、このような汎用デバイスを示す識別情報（デバイスクラス（インターフェースクラス））をコンピュータ１００に送信する。これにより、プロジェクタ２００のための専用のデバイスドライバをコンピュータ１００にインストールせずに、汎用のマスストレージドライバ１３４を利用して、ＵＳＢインターフェース部１１２、２１２を介したデータ通信（画像データの転送）が可能となるという利点がある。なお、プロジェクタ２００におけるＵＳＢモジュール２３６とマスストレージドライバ２３４とディスパッチャ２２６との全体は、本発明における「画像表示装置の通信制御部」に相当する。一方、コンピュータ１００におけるＵＳＢモジュール１３６とマスストレージドライバ１３４との全体は、本発明における「画像供給装置の通信制御部」に相当する。
【００７１】
第２の特徴点は、プロジェクタ２００が、データ記憶装置（マスストレージクラス）として識別される点である。マスストレージクラスの通信プロトコルは、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送速度を高め、プロジェクタ２００による表示画像の更新頻度を高めることが可能となる。
【００７２】
第３の特徴点は、プロジェクタ２００のデータ記憶部（ディスクイメージ２２４）に、画像転送プログラム５００が格納されている点である。これにより、画像転送プログラム５００を、容易に、コンピュータ１００に提供することができる。その結果、画像転送プログラム５００の準備が容易となるので、プロジェクタ２００の利用に関する利便性をさらに向上させることができる。
【００７３】
Ｂ．第２実施例：
図７は、第２実施例における画像表示処理の手順を示すフローチャートである。この図７には、プロジェクタ２００が実行する処理が示されている。第２実施例では、図５に示す第１実施例とは異なり、データ生成モジュール５２０は、キャプチャされた画像データを複数の部分データに分割して、１つずつ順番にプロジェクタ２００に送信する。装置の構成は、図１〜図３に示す第１実施例と同じである。
【００７４】
ステップＳ２２０、Ｓ２２４の処理は、図５のステップＳ２２０、Ｓ２２４の処理と、それぞれ同じである。Ｄ９コマンドを受け取ったデータ取得モジュール２４４は、ＣＥフラグ（図６）の値を確認する（Ｓ２２８）。ＣＥフラグが「Ｃ」に設定されている場合には、データ取得モジュール２４４は、受信した部分データをＲＡＭ２０６（図２）に格納し（Ｓ２４０）、正常応答を発行する（Ｓ２４４）。このステップＳ２４４は、図５のステップＳ２３８と同様である。そして、処理はステップＳ２２０に戻り、データ取得モジュール２４４は、残りの部分データを待つ。
【００７５】
複数の部分データの内の最後の部分データが送られてきた場合には、ＣＥフラグが「Ｅ」に設定されている。この場合には、次のステップＳ２５０で、データ取得モジュール２４４は、受信した複数の部分データを結合することによって表示用データを再構成し、この表示用データを画像展開モジュール２４２に供給する。すると、画像展開モジュール２４２は、図５のステップＳ２３４と同様に、ヘッダと画像データに従って画像処理部２１４（図２）を制御する。この結果、プロジェクタ２００は、図１に示すように、投写表示画面７０に画像を表示する。次のステップＳ２５４は、図５のステップＳ２３８と同様である。このステップＳ２５４の後、処理はステップＳ２２０に戻る。そして、上述した一連の処理が繰り返し実行される。
【００７６】
図８は、第２実施例における画像表示処理の一例の具体的な手順を示すフローチャートである。この例は、画像データが２つの部分データに分割して送られる場合を示している。
【００７７】
最初のステップＳ２００は、図５のステップＳ２００と同じである。次のステップＳ２０８ａでは、データ生成モジュール５２０（図３）は、キャプチャされた画像データを圧縮することによって送信用画像データＩｍｇＤを生成し、この画像データＩｍｇＤを用いて第１表示用データＴＤ１を生成する。ここで、データ生成モジュール５２０は、画像データＩｍｇＤを、第１部分データＩｍｇＤ１と第２部分データＩｍｇＤ２とに分割する。そして、データ生成モジュール５２０は、ヘッダＩｍｇＨと第１部分データＩｍｇＤ１とから構成される第１表示用データＴＤ１を生成する。
【００７８】
次に、データ生成モジュール５２０は、ＣＥフラグを「Ｃ」に設定して第１表示用データＴＤ１を送信する命令をＳＣＳＩラッパモジュール５３０に対して発行する。ＳＣＳＩラッパモジュール５３０によって生成されるＤ９コマンド（ＣＤＢ１）では、ＯＰコードが「Ｄ９ｈ」に設定され、ＣＥフラグが「Ｃ」に設定されている。
【００７９】
生成されたＤ９コマンド（ＣＤＢ１）を格納するコマンドブロックラッパＣＢＷ１と、第１表示用データＴＤ１とは、マスストレージドライバ１３４によって、プロジェクタ２００に送信される。
【００８０】
一方、データを受信したプロジェクタ２００では、受信されたＤ９コマンドのＣＥフラグが「Ｃ」に設定されているので、図７のステップＳ２２８、Ｓ２４０、Ｓ２４４と同様の一連の処理が実行される。
【００８１】
コンピュータ１００では、ステップＳ２４４で発行された正常応答（ＣＳＷ）を受信したことに応じて、データ生成モジュール５２０（図３）が、残りの第２部分データＩｍｇＤ２を送信する命令をＳＣＳＩラッパモジュール５３０に対して発行する（Ｓ２０８ｂ）。この際、ＣＥフラグを「Ｅ」に設定する指示が発行される。ＳＣＳＩラッパモジュール５３０によって生成されたＤ９コマンド（ＣＤＢ２）では、ＯＰコードが「Ｄ９ｈ」に設定され、ＣＥフラグが「Ｅ」に設定されている。
【００８２】
生成されたＤ９コマンド（ＣＤＢ２）を格納するコマンドブロックラッパＣＢＷ２と、第２表示用データＴＤ２（第２部分データＩｍｇＤ２）とは、マスストレージドライバ１３４によって、プロジェクタ２００に送信される。
【００８３】
一方、データを受信したプロジェクタ２００では、受信されたＤ９コマンドのＣＥフラグが「Ｅ」に設定されているので、図７のステップＳ２２８、Ｓ２５０、Ｓ２５４と同様の一連の処理が実行される。
【００８４】
以上、画像データが２つの部分データに分割して送信される場合について説明したが、画像データが３つ以上の部分データに分割して送信される場合についても、同様の手順に従って、部分データが逐次送信され、全ての部分データが転送された後に画像が表示される。
【００８５】
このように、第２実施例の画像表示処理では、画像データが分割して送信される。従って、画像データのサイズが大きい場合であっても、適切にプロジェクタ２００に画像データの全体を送信することができる。特に、通信用のインターフェースによっては、１回のコマンド発行で送信可能なデータサイズに上限が設けられている場合が多い。このような場合であっても、サイズに拘わらずに、画像データの全体を転送することができる。
【００８６】
なお、図８の例では、送信用画像データＩｍｇＤを分割して送信していたが、画像データを分割して送信する方法としては、他の種々の方法を採用可能である。例えば、表示画面を複数の部分画面に分割し、各部分画面毎にキャプチャ画像データを送信してもよい。例えば、表示デバイス１１８の表示画面を左半分と右半分との２つの部分画面に区分してもよい。ここで、左部分画面の画像データをプロジェクタ２００へ送信して、プロジェクタ２００に左半分を更新させ、その後、右部分画面の画像データを送信して、プロジェクタ２００に右半分を更新させる一連の処理を、繰り返し実行してもよい。ここで、表示画面全体のキャプチャ画像データの転送が完了した後に、プロジェクタ２００が表示を更新してもよい。なお、画面の区分としては、左半分と右半分への区分に限らず任意の区分を採用可能である。また、３以上の領域に区分してもよい。
【００８７】
Ｃ．第３実施例：
図９は、第３実施例におけるソフトウェア構成の詳細を示す説明図である。図３に示す第１実施例との差違は３点ある。第１の差違は、画像転送プログラム５００ａが、判断モジュール５４０を有している点である。第２の差違は、コンピュータ１００ａ上で、フック処理モジュール４００と、プロジェクタドライバ１２８と、が動作している点である。第３の差違は、プロジェクタ２００ａ上で、状態チェックモジュール２５０が動作している点である。他の構成は、図３に示す第１実施例と同じである。第３実施例では、これらの構成要素によって、画面の変化領域のみが、コンピュータ１００ａからプロジェクタ２００ａに転送される。なお、コンピュータ１００ａ上で動作するプログラム５００ａ、４００、１２８は、ディスクイメージ２２４に格納されている。そして、図４に示す接続処理におけるオートランプログラム、あるいは、ユーザの指示に応じて、プロジェクタ２００ａからコンピュータ１００ａに転送される。また、ハードウェア構成は、図１、図２に示す第１実施例と同じである。
【００８８】
図１０は、第３実施例における接続処理の手順を示すフローチャートである。図１０の処理は、図４に示す接続処理の後に実行される。この接続処理は、コンピュータ１００ａが、プロジェクタ２００ａによる画像データ受信準備の完了を待つために、実行される。プロジェクタ２００ａの受信準備完了を待つ理由は以下の通りである。第３実施例では、後述するように、最初に画面全体の画像データが送信された後は、画像の変化した部分の画像データのみが送信される。従って、最初の画面全体の画像データを確実にプロジェクタ２００ａに受信させるために、コンピュータ１００ａは、プロジェクタ２００ａの受信準備完了を待つ。
【００８９】
最初のステップＳ３００では、判断モジュール５４０（図９）は、プロジェクタ２００ａに、状態問い合わせを送信する命令を、ＳＣＳＩラッパモジュール５３０に対して発行する。ＳＣＳＩラッパモジュール５３０は、画像データを送信する場合と同様に、状態問い合わせを送信するためのＤ９コマンドを生成する。ここで、ＵＤコマンドコード（図６）は、画像データ送信コマンドのＵＤコマンドコードとは異なるコードに設定される。例えば、第３実施例では、画像データ送信コマンドに対しては「８０ｈ」が採用され、状態問い合わせを送信するコマンドに対しては「Ｃ１ｈ」が採用されることとしている。生成されたＤ９コマンドは、マスストレージドライバ１３４によってプロジェクタ２００ａに送信される。なお、受信状態に加えて他の種々の状態を、この状態問い合わせ用のＤ９コマンド（ＵＤコマンドコード＝Ｃ１ｈ）を用いて問い合わせる場合には、このＤ９コマンドに続けて、問い合わせの内容を識別するデータを送信してもよい。
【００９０】
一方、プロジェクタ２００ａのディスパッチャ２２６は、ＳＣＳＩコマンドを受信したら（Ｓ３５０）、そのコマンドがＤ９コマンドか否かを判断する（Ｓ３５４）。そのコマンドがＤ９コマンドである場合には、さらに、ＵＤコマンドコードを確認する（Ｓ３５８）。ＵＤコマンドコードが「Ｃ１ｈ」である場合には、受信したデータを状態チェックモジュール２５０に供給する。なお、図１０では図示を省略しているが、ＵＤコマンドコードが「８０ｈ」である場合には、ディスパッチャ２２６は、受信したデータ（画像データ送信用Ｄ９コマンドと表示用データ）をデータ取得モジュール２４４に供給する。
【００９１】
ＵＤコマンドコードがＣ１ｈに設定されたＤ９コマンド（すなわち、状態問い合わせ）を受信した状態チェックモジュール２５０は、プロジェクタ２００ａの状態が、画像データ受信が可能な状態か否かを判断する（Ｓ３６０）。受信可能と判断するための条件としては、受信した画像データを消失させずに保持できることを示す任意の条件を採用可能である。例えば、画像表示モジュール２４０（図９）の起動が完了していることを条件として採用してもよい。また、画像処理部２１４（図２）の起動が完了していることを条件として採用してもよい。状態チェックモジュール２５０は、判断結果を表す状態データを、コンピュータ１００ａに送信すべきデータとして、ＲＡＭ２０６（図２）に格納する。本実施例では、状態データは、「ＲＥＤＹ（受信可能）」あるいは「ＢＵＳＹ（受信不可）」のいずれかの文字列である。
【００９２】
次に、状態チェックモジュール２５０は、状態問い合わせを正常に受信したことを示す応答をコンピュータ１００ａに送信する（Ｓ３６４）。この応答送信は、図５のステップＳ２３８と同様に行われる。なお、この段階では、状態データはコンピュータ１００ａに送信されない。この理由は、プロジェクタ２００ａは、ＳＣＳＩのターゲットに相当するので、自発的にデータを送信することができないからである。
【００９３】
コンピュータ１００ａの判断モジュール５４０は、正常応答（ＣＳＷ）を受信したことに応じて（Ｓ３０４）、リクエスト問い合わせを送信する命令を、ＳＣＳＩラッパモジュール５３０に対して発行する（Ｓ３１０）。このリクエスト問い合わせは、プロジェクタ２００ａに種々のデータを送信させるためのコマンドである。ＳＣＳＩラッパモジュール５３０は、画像データを送信する場合と同様に、Ｄ９コマンドを生成する。ここで、ＵＤコマンドコード（図６）は、画像データ送信コマンドと、状態問い合わせ送信コマンドと、のいずれのコードとも異なるコードに設定される。例えば、第３実施例では、リクエスト問い合わせ送信コマンドに対しては「００ｈ」が採用されることとしている。生成されたＤ９コマンドは、マスストレージドライバ１３４によってプロジェクタ２００ａに送信される。
【００９４】
一方、プロジェクタ２００ａのディスパッチャ２２６は、受信したＳＣＳＩコマンドがＤ９コマンドであり（Ｓ３５４：Ｙｅｓ）、ＵＤコマンドコードが「００ｈ」である場合には、受信したデータを状態チェックモジュール２５０に供給する。
【００９５】
ＵＤコマンドコードが００ｈに設定されたＤ９コマンド（すなわち、リクエスト問い合わせ）を受信した状態チェックモジュール２５０は、先ほどのステップＳ３６０でメモリに格納した状態データを送信する命令を、マスストレージドライバ２３４に対して発行する（Ｓ３７０）。マスストレージドライバ２３４は、命令に従って、状態データをコンピュータ１００ａに送信する。次のステップＳ３７４では、状態チェックモジュール２５０は、リクエスト問い合わせに応じたデータ送信を正常に行ったことを示す応答をコンピュータ１００ａに送信する。この応答は、ステップＳ３６４と同様に行われる。
【００９６】
コンピュータ１００ａによって受信された状態データと応答とは、判断モジュール５４０に供給される（Ｓ３１４、Ｓ３１８）。状態データが「ＢＵＳＹ」である場合には、判断モジュール５４０は、「ＲＥＤＹ」に設定された状態データを受信するまで、ステップＳ３００〜Ｓ３２０の一連の処理を繰り返し実行する。
【００９７】
状態データが「ＲＥＤＹ」である場合には、判断モジュール５４０は、次のステップＳ３３０で、画像表示処理を開始する指示を、各モジュール５１０、５２０、５３０に対して発行する。
【００９８】
図１１は、第３実施例における画像表示処理の手順を示すフローチャートである。最初のステップＳ４００、Ｓ４０４、Ｓ４０８、Ｓ４１２の処理は、図５のステップＳ２００、Ｓ２０４、Ｓ２３４、Ｓ２３８と、それぞれ同じである。特に、ステップＳ４００では、表示デバイス１１８によって表示されている表示画面の全体がキャプチャされる。これにより、プロジェクタ２００ａは、図１に示すように、投写表示画面７０に画像を表示することができる。なお、図１１のフローチャートでは、ＯＰコードとＵＤコマンドコードとを確認する処理は、図示が省略されている。
【００９９】
次のステップＳ４２０では、キャプチャモジュール５１０は、画面内の変化した領域のみのキャプチャを実行する。この変化領域のみのキャプチャの詳細については後述する。次のステップＳ４２４では、ステップＳ４０４と同様に、キャプチャされた画像データがコンピュータ１００ａからプロジェクタ２００ａへ送信される。この際、ヘッダにおけるサイズ（高さ、幅）と位置とは、変化領域を表す値に設定される。
【０１００】
次のステップＳ４２８では、画像展開モジュール２４２は、ステップＳ４０８と同様に、ヘッダと画像データに従って画像処理部２１４（図２）を制御する。この際、変化領域を表す部分の画像データのみが更新される。他の部分については更新されずに維持される。その結果、プロジェクタ２００ａは、変化領域が更新された画像を表示することができる。次のステップＳ４３２は、ステップＳ４１２と同じである。このステップＳ４３２の後、処理は、ステップＳ４２０に戻る。そして、上述したステップＳ４２０〜Ｓ４３２の一連の処理が繰り返し実行される。
【０１０１】
以上のように、第３実施例では、表示画面の全体が送信された後は、変化した領域のみが送信される。また、画像展開モジュール２４２は、変化した領域のみを受信した場合には、変化した領域のみを更新する。これらにより、送信されるデータ量を低減することができる。その結果、プロジェクタ２００ａによって表示される画像の更新頻度を速めることが可能となる。
【０１０２】
なお、図１１の例では、画面全体の画像データ送信が接続直後の１回だけであったが（Ｓ４００、Ｓ４０４）、接続後、複数回に渡って画面全体の画像データが送信されてもよい。こうすれば、プロジェクタ２００ａによって表示される画像が乱れることを抑制できる。例えば、画像転送プログラム５００ａが、定期的に画面全体の画像データを送信してもよい。また、画像転送プログラム５００ａが、ユーザの指示を受けたことに応じて画面全体の画像データを送信してもよい。
【０１０３】
次に、変化領域のみのキャプチャ（図１１：Ｓ４２０）について説明する。図１２は、画面内の変化部分をキャプチャするためのコンピュータのソフトウェアとハードウェアの階層構造を示す説明図である。アプリケーションプログラム１２２と画像転送プログラム５００ａは、アプリケーションプログラム層（「ユーザアプリケーションプログラム層」とも呼ぶ）に属する。ＧＤＩ１２４とディスプレイドライバ１２６とプロジェクタドライバ１２８は、カーネル層に属する。また、汎用メモリとしてのＲＡＭ１０６と、ＵＳＢインターフェース部１１２と、ＶＲＡＭ１１４と、グラフィックコントローラ１１６と、表示デバイス１１８は、ハードウェア層に属する。
【０１０４】
また、アプリケーションプログラム１２２とＧＤＩ１２４との間には、フック処理モジュール４００が設けられている。フック処理モジュール４００は、アプリケーションプログラム１２２が発行する特定の描画命令をフックして先取りし、後述する処理を実行する。他の描画命令は通常通りＧＤＩ１２４によって処理される。なお、フック処理モジュール４００は、アプリケーションプログラム１２２に応じた適切な特定の描画命令のみをフックするように、各アプリケーションプログラム専用に構成されることが好ましい。
【０１０５】
第３実施例では、アプリケーションプログラム１２２としてプレゼンテーションプログラム（例えばマイクロソフト社のPowerPoint）を使用した場合について説明する。まず、描画命令がフック処理モジュール４００を介さずに直接にＧＤＩ１２４に渡される場合について説明し、次に、描画命令がフック処理モジュール４００によって先取りされる場合について説明する。
【０１０６】
アプリケーションプログラム１２２は、ＧＤＩ１２４に対して、例えばプレゼンテーションファイルに含まれているプレゼンテーションシートの画像の描画要求を発行する。通常は、描画要求には、画像の出力先に関する情報（即ち、画像を表示装置に出力するか、印刷装置に出力するかを指定する情報）も含まれている。
【０１０７】
なお、ＧＤＩ１２４の代わりに、他の汎用の描画用ＡＰＩを使用することも可能である。「汎用の描画用ＡＰＩ」とは、多数のアプリケーションプログラムに対して共通に使用されるＡＰＩを意味している。
【０１０８】
ＧＤＩ１２４と、ディスプレイドライバ１２６と、プロジェクタドライバ１２８の全体は、描画命令に従って描画処理を実行する描画モジュールとして機能する。具体的には、ＧＤＩ１２４は、アプリケーションプログラム１２２から出された描画要求を受け取り、その描画要求に基づいて画像の出力先をチェックし、その出力先が表示装置であれば、ディスプレイドライバ１２６とプロジェクタドライバ１２８のそれぞれに対して描画要求を渡す。
【０１０９】
ディスプレイドライバ１２６は、受け取った描画要求に従ってＶＲＡＭ１１４内に画像データを描画する。なお、よく知られているように、描画要求としては、画面の全体を描画するものに限らず、画面の一部を描画するものも多用される。画面の一部を描画する描画命令を受けた場合には、ディスプレイドライバ１２６は、ＶＲＡＭ１１４内で描画対象となっている領域（「変化領域」とも呼ぶ）の画像部分のみを描画する。グラフィックコントローラ１１６は、ＶＲＡＭ１１４内に描画された画像データ（即ち、ビットマップデータ）に基づいて、表示デバイス１１８に画像を表示する。一方、プロジェクタドライバ１２８は、ＧＤＩ１２４から受け取った描画要求に従って、ＶＲＡＭ１１４内の描画対象領域（すなわち変化領域）の位置及びサイズを表す変化領域情報１０６ａをＲＡＭ１０６内に書き込む。以下、プロジェクタドライバ１２８によって書き込まれる変化領域情報を、第２変化領域情報１０６ａ２（変化領域情報Ａ２）とも呼ぶ。
【０１１０】
図１３（Ａ），（Ｂ）は、ＲＡＭ１０６内の変化領域情報１０６ａ２と画像データ格納領域１０６ｂの例を示す説明図である。ここでは、プロジェクタで投写表示されるべき画像が図１３（Ａ）から図１３（Ｂ）のように変化する例を想定する。後述するように、画像データ格納領域１０６ｂには、キャプチャモジュール５１０によってＶＲＡＭ１１４から転送された画像データが格納される。画像データ格納領域１０６ｂは、ＶＲＡＭ１１４（フレームメモリ）と同じデータ容量を有することが好ましい。
【０１１１】
変化領域Ｒａは、図４（Ａ）から図４（Ｂ）に画像を変更する際の描画命令によって描画される画像部分の領域である。この変化領域Ｒａに関する変化領域情報１０６ａ２は、変化領域Ｒａの基準点（通常は左上点）のｘ座標Ｘａ及びｙ座標Ｙａと、変化領域Ｒａの幅Ｗａ及び高さＨａとを含んでいる。なお、基準点の座標（Ｘａ，Ｙａ）は、変化領域Ｒａの位置を示すデータであり、幅Ｗａと高さＨａは変化領域Ｒａのサイズを示すデータである。
【０１１２】
キャプチャモジュール５１０は、ＲＡＭ１０６内の変化領域情報１０６ａ２を参照して、変化領域Ｒａの画像データを、ＶＲＡＭ１１４からＲＡＭ１０６内の画像データ格納領域１０６ｂに転送する。この画像データ格納領域１０６ｂは、例えばコンピュータ１００又はプロジェクタ２００の表示解像度に等しいサイズのメモリ領域である。キャプチャモジュール５１０は、さらに、画像データ格納領域１０６ｂから変化領域Ｒａの画像データを読み出して、読み出した画像データと変化領域情報１０６ａ２とをデータ生成モジュール５２０に供給する。データ生成モジュール５２０は、受け取ったデータを用いて、表示用データ（ヘッダと画像データ）を生成する。生成された表示用データは、マスストレージドライバ１３４によってプロジェクタ２００ａに送信される。
【０１１３】
このように、描画命令がフック処理モジュール４００を介さずに直接にＧＤＩ１２４に渡される場合には、一旦ＶＲＡＭ１１４に格納された画像データを汎用メモリであるＲＡＭ１０６に転送した後で、ＲＡＭ１０６内にある画像データをプロジェクタ２００ａに転送している。このため、ＶＲＡＭ１１４からＲＡＭ１０６に転送するためにかなりの時間を要してしまい、十分な転送速度が得られない場合があった。
【０１１４】
次に、描画命令がフック処理モジュール４００によって先取りされる場合について説明する。なお、フック処理モジュール４００も一種の描画用ＡＰＩと考えることも可能であるが、ＧＤＩ１２４のような汎用の描画用ＡＰＩとは区別される。すなわち、フック処理モジュール４００は、典型的には特定の描画命令のみを処理するように構成されているのに対して、ＧＤＩ１２４はすべての描画命令を処理するように構成されている点で相違する。
【０１１５】
フック処理モジュール４００は、例えばＤＬＬ（ダイナミックリンクライブラリ）としてアプリケーションプログラム１２２にロード（インストール）される。一般に、アプリケーションプログラムは「プロセス」という単位で動作している。また、アプリケーションプログラムの実行中は、そのプロセス内に複数のモジュール（GDI32.DLLやKernel32.DLLなど）がロードされており、アプリケーションプログラムはそれらのモジュール内の関数を利用することによって各種の動作を行っている。フック処理モジュール４００の「ロード」とは、アプリケーションプログラム１２２のプロセス内に、フックプロシージャが実装されているモジュール４００を組み込むことを意味している。
【０１１６】
フック処理モジュール４００がロードされる際には、アプリケーションプログラム１２２から発行される特定の描画命令の関数アドレスが、フック処理モジュール４００内に実装されている独自機能を実行するための別の関数のアドレスに差し替えられる。この独自機能の関数内では、変化情報と画像データのＲＡＭへの書き込み処理（後述する）が実行され、その後、通常のＧＤＩ関数が実行される。フック処理モジュール４００をアンロードする際には、ロード時に差し替えられていた関数アドレスを元に戻した後に、プロセス内にロードされていたフック処理モジュール４００がアンロードされる。
【０１１７】
なお、フック処理モジュール４００は、必要に応じていつでもアプリケーションプログラム１２２にロードしたり、アンロードしたりすることが可能である。但し、画像転送プログラム５００ａが起動する際に、動作中の特定のアプリケーションプログラム１２２（本実施例ではプレゼンテーションプログラム）にフック処理モジュール４００をロードし、また、画像転送プログラム５００ａを終了するときにフック処理モジュール４００をアンロードするように、画像転送プログラム５００ａを構成することが好ましい。こうすれば、画像転送プログラム５００ａが実行中の期間にのみフック処理モジュール４００を動作させることができるので、コンピュータ１００上で画像転送プログラム５００ａが実行されていない（起動していない）ときに描画命令をフックしてしまい、望ましくない結果が生じることを回避することができる。なお、本明細書において、「コンピュータ１００上で画像転送プログラム５００ａが実行されている」という文言は、画像転送プログラム５００ａのプロセスが起動されていることを意味している。
【０１１８】
図１４は、第３実施例におけるフック処理モジュール４００と画像転送プログラム５００ａの動作を示すフローチャートである。ステップＳ１０〜Ｓ１６はフック処理モジュール４００によって実行され、ステップＳ２０〜Ｓ２６は画像転送プログラム５００ａによって定期的に実行される。
【０１１９】
フック処理モジュール４００は、アプリケーションプログラム１２２から特定の描画命令が発行されたときに、ステップＳ１０においてその描画命令をフックして、ＧＤＩ１２４の代わりにその描画命令を取得する。なお、フック処理モジュール４００がフックする描画命令は、すべての描画命令ではなく、限られた特定の描画命令のみに限定することが好ましい。この理由は、アプリケーションプログラム１２２が発行する描画命令には多数のものがあるので、そのすべてをフックするようにすると、却って処理速度を低下させたり、所望の描画を行えなかったりする可能性があるからである。
【０１２０】
ステップＳ１２では、取得した描画命令に応じて変化領域情報を登録する処理が実行される。具体的には、フック処理モジュール４００が、描画命令に従って描画が行われる領域（図１３（Ｂ）の変化領域Ｒａ）の位置とサイズを取得し、その変化領域を表す変化領域情報１０６ａ１（以下「変化領域情報Ａ１」とも呼ぶ）をＲＡＭ１０６に直接書き込む処理を実行する。
【０１２１】
ステップＳ１４では、変化領域Ｒａの画像データの書込処理が実行される。具体的には、フック処理モジュール４００が、描画命令に従って変化領域Ｒａ内の画像データを展開して、その画像データをＲＡＭ１０６内の画像データ格納領域１０６ｂに直接書き込む処理を実行する。
【０１２２】
ステップＳ１６では、フック処理モジュール４００が、ステップＳ１０で取得した描画命令に従って通常のＧＤＩ関数を呼び出して描画処理を実行させる。なお、ディスプレイドライバ１２６とプロジェクタドライバ１２８（図１２）は、描画命令がフック処理モジュール４００を介さずに直接にＧＤＩ１２４に渡される場合と同様に、ＧＤＩ１２４から受け取った描画命令に従ってそれぞれの処理を実行する。すなわち、ディスプレイドライバ１２６がＶＲＡＭ１１４内に画像を描画し、プロジェクタドライバ１２８がその描画領域を示す変化領域情報Ａ２をＲＡＭ１０６内に書き込む。
【０１２３】
一方、キャプチャモジュール５１０は、ステップＳ２０において、プロジェクタ２００に転送すべき画像データの領域（「画面更新領域」と呼ぶ）を決定する。図１５は、ステップＳ２０の詳細手順を示すフローチャートである。ステップＳ３０，Ｓ３２では、第１と第２の変化領域情報Ａ１，Ａ２が取得される。前述したように、第１の変化領域情報Ａ１は、フック処理モジュール４００によってＲＡＭ１０６内の画像データ格納領域１０６ｂに描画された領域を表す情報であり、フック処理モジュール４００によってＲＡＭ１０６内に書き込まれたものである。一方、第２の変化領域情報Ａ２は、ディスプレイドライバ１２６によってＶＲＡＭ１１４内に描画された領域を表している情報であり、プロジェクタドライバ１２８によってＲＡＭ１０６内に書き込まれたものである。
【０１２４】
図１６（Ａ）は、２つの変化領域情報Ａ１，Ａ２で表される２つの変化領域ＲＡ１，ＲＡ２の一例を示している。ここでは、２つの変化領域ＲＡ１，ＲＡ２を、同一の画面領域ＳＣＡ内に配置している。ここで、「画面領域ＳＣＡ」とは、ＶＲＡＭ１１４に格納される画像の全体の領域を意味しており、これは、画像データ格納領域１０６ｂ全体の領域と等しい。厳密に言えば、第１の変化領域ＲＡ１は画像データ格納領域１０６ｂ内のアドレスで定義された領域であり、第２の変化領域ＲＡ２はＶＲＡＭ１１４内のアドレスで定義された領域であるが、これらは同じ画面領域ＳＣＡで表現することができる。
【０１２５】
なお、図１６（Ａ）の例では、２つの変化領域ＲＡ１，ＲＡ２は部分的に重なっているが、２つの変化領域ＲＡ１，ＲＡ２はこれ以外の種々の関係を取る場合がある。例えば、２つの変化領域ＲＡ１，ＲＡ２が全く重なり合わない場合も存在し、両者が完全に重なり合う場合も存在する。例えば、フック処理モジュール４００が特定の描画命令に従って描画を行い、その後、通常の描画モジュール１２４，１２６，１２８が同じ描画命令に従って同じ領域の描画を行った場合には、２つの変化領域ＲＡ１，ＲＡ２は同一となる。但し、同じ描画命令を実行したときにも、各モジュールの設定によっては、２つの変化領域ＲＡ１，ＲＡ２に若干の差異が生じる場合もあり得る。
【０１２６】
図１６（Ｂ）は、キャプチャモジュール５１０がキャプチャ時にＲＡＭ１０６から画像を直接取得する領域ＴＧ１を示しており、図１６（Ｃ）はＶＲＡＭ１１４から画像を取得する領域ＴＧ２を示している。これらの領域ＴＧ１，ＴＧ２を「転送領域」とも呼ぶ。この例から理解できるように、第１の変化領域ＲＡ１（＝ＴＧ１）の画像は、ＲＡＭ１０６内から直接取得される。一方、第２の変化領域ＲＡ２のうちで第１の変化領域ＲＡ１に含まれない部分の領域ＴＧ２の画像は、ＶＲＡＭ１１４から取得される。このように区別する理由は、ＶＲＡＭ１１４から取得する画像を可能な限り少なくして、その取得に要する時間を少なくするためである。例えば、２つの変化領域ＲＡ１，ＲＡ２が完全に重なる場合には、ＶＲＡＭ１１４から画像を取得する必要が無くなるので、転送処理を高速に行うことができる。図１６（Ｄ）は、キャプチャモジュール５１０によって取得される領域全体（画面更新領域ＴＴＧ）を示している。この画面更新領域ＴＴＧは、第１と第２の変化領域ＲＡ１，ＲＡ２の和領域に相当する。
【０１２７】
なお、第１の変化領域情報Ａ１に複数の描画命令に対応する複数の情報が含まれている場合がある。この場合には、これらの複数の描画命令の描画領域の和領域が第１の変化領域ＲＡ１となる。第２の変化領域ＲＡ２についても同様である。
【０１２８】
図１５のステップＳ３４では、キャプチャモジュール５１０が、２種類の変化領域情報Ａ１，Ａ２で表される変化領域ＲＡ１，ＲＡ２の差分を計算する。具体的には、第２の変化領域ＲＡ２の中で、第１の変化領域ＲＡ１に含まれない領域ＴＧ２（図１６（Ｃ））が算出される。ステップＳ３６では、キャプチャモジュール５１０によって、画面更新領域ＴＴＧ（図１６（Ｄ））の最適化処理が実行される。
【０１２９】
図１７は、画面更新領域の最適化処理の内容を示す説明図である。図１７（Ａ）は、図１６（Ｄ）と同じ画面更新領域ＴＴＧを示している。最適化処理では、図１７（Ｂ）に示すように、画面更新領域ＴＴＧを互いに重ならない隣接する矩形領域Ｒ１１〜Ｒ１３に分割する。そして、これらの矩形領域Ｒ１１〜Ｒ１３が、最適化後の画面更新領域として採用される。個々の画面更新領域Ｒ１１〜Ｒ１３は矩形なので、最適化前の画面更新領域ＴＴＧを包含するような矩形形状の画像を転送する場合に比べて、転送される画像データ量を削減することが可能である。
【０１３０】
図１４のステップＳ２２では、キャプチャモジュール５１０によって、画面更新領域に相当する画像部分の画像データが取得される。図１８は、ステップＳ２２の詳細手順を示すフローチャートである。ステップＳ４０では、第２の転送領域ＴＧ２（図１６（Ｃ））が空である否かが調べられる。第２の変化領域情報Ａ２が存在しない場合、及び、第２の変化領域Ａ２が第１の変化領域Ａ１に完全に包含されている場合には、第２の転送領域ＴＧ２は空である。第２の転送領域ＴＧ２が空である場合には、後述するステップＳ４４に移行する。一方、第２の転送領域ＴＧ２が空でない場合には、ステップＳ４２が実行される。ステップＳ４２では、キャプチャモジュール５１０が第２の転送領域ＴＧ２の画像データをＶＲＡＭ１１４から取得してＲＡＭ１０６内の画像データ格納領域１０６ｂに書き込む。この結果、画像データ格納領域１０６ｂには、図１６（Ｄ）に示す画面更新領域ＴＴＧ内の画像がすべて格納された状態になる。ステップＳ４４では、キャプチャモジュール５１０が画面更新領域ＴＴＧの画像データをＲＡＭ１０６の画像データ格納領域１０６ｂから取得する。なお、実際に取得されるのは、最適化処理後の個々の画面更新領域Ｒ１１〜Ｒ１３（図１０（Ｂ））の画像データである。
【０１３１】
図１４のステップＳ２４では、キャプチャモジュール５１０は、変化領域情報と画像データとをデータ生成モジュール５２０に供給する。データ生成モジュール５２０は、受信したデータを用いて、表示用データを生成する。ステップＳ２６では、こうして生成された表示用データが、ＵＳＢインターフェース部１１２を介してプロジェクタ２００ａに転送される。なお、最適化処理によって画面更新領域が複数の部分領域に分割された場合には、各部分領域毎に表示用データが生成される。なお、各表示用データは、１つのＤ９コマンドでまとめて転送されてもよく、別々のＤ９コマンドで転送されてもよい。
【０１３２】
一方、プロジェクタ２００ａ（図９）の画像展開モジュール２４２は、受信した表示用データ（ヘッダと画像データ）に従って画像処理部２１４を制御し、プロジェクタ２００ａによって表示される画像を更新する。
【０１３３】
このように、第３実施例では、フック処理モジュール４００が、特定の描画命令をフックして先取りし、変化領域の画像データをＲＡＭ１０６に直接書き込む処理を実行するようにしている。この結果、ＶＲＡＭ１１４からＲＡＭ１０６への画像データの転送に要していた時間を節約することができる。この結果、プロジェクタ２００ａに画像データを転送する場合の転送速度を十分に速くすることができるという利点がある。
【０１３４】
なお、一般に使用されているパーソナルコンピュータでは、ＲＡＭ１０６からＶＲＡＭ１１４へのデータ転送は非常に高速に実行できるのに対して、ＶＲＡＭ１１４からＲＡＭ１０６へのデータ転送はその数倍低速でしか実行できないアーキテクチャとなっていることが多い。第３実施例では、低速なＶＲＡＭからＲＡＭへのデータ転送を削減できるので、プロジェクタ２００に画像データを転送するために要する時間を大幅に削減することが可能である。
【０１３５】
また、上記第３実施例では、フック処理モジュール４００によって描画されていない領域ＴＧ２（図１６（Ｃ））の画像部分に関しては、ＶＲＡＭ１１４から取得してプロジェクタ２００ａに転送している。この結果、通常の描画モジュール１２４，１２６，１２８で描画された画像についても欠落無しにプロジェクタ２００に転送することが可能である。
【０１３６】
Ｄ．第４実施例：
図１９は、第４実施例における変化領域と画面更新領域との関係を示す説明図であり、第３実施例の図１６に対応するものである。第４実施例は、装置構成や処理フローの全体は第３実施例と同じであるが、転送対象となる領域が第３実施例と異なっている。具体的には、第４実施例では、ＲＡＭ１０６から画像が直接取得される第１の転送領域ＴＧ１（図１９（Ｂ））は、第１と第２の変化領域ＲＡ１，ＲＡ２が重なり合っている部分に設定される。換言すれば、第１の転送領域ＴＧ１は、第２の変化領域ＲＡ２のうちで第１の変化領域ＲＡ１にも含まれている領域に設定される。一方、ＶＲＡＭ１１４から画像が取得される第２の転送領域ＴＧ２（図１９（Ｃ））は、第３実施例と同様に、第２の変化領域ＲＡ２のうちで第１の変化領域ＲＡ１に含まれていない部分に設定される。従って、転送対象となる領域の全体である画面更新領域ＴＴＧ（図１９（Ｄ））は、第２の変化領域ＲＡ２と同一である。
【０１３７】
このように、第４実施例では、ＧＤＩ１２４及びディスプレイドライバ１２６によってＶＲＡＭ１１４内に描画される領域である第２の変化領域ＲＡ２内の画像が画像転送プログラム５００ａによって転送されることになる。このように処理を行う理由は、以下の通りである。すなわち、フック処理モジュール４００によってフック処理された描画命令も、その後、ＧＤＩ１２４及びディスプレイドライバ１２６によって再度実行されるので、基本的にすべての描画命令がＧＤＩ１２４及びディスプレイドライバ１２６によって実行される。従って、第２の変化領域ＲＡ２の画像を転送すれば、プロジェクタ２００ａに正しい画像を表示させることが可能である。但し、この際にすべての画像データをＶＲＡＭ１１４から取得すると、データ転送にかなりの時間を要するという問題を生じてしまう。そこで、第４実施例では、第２の変化領域ＲＡ２の中で、第１の変化領域ＲＡ１に含まれている部分についてはＲＡＭ１０６から画像データを直接取得することによって、データ取得に要する時間を短縮している。また、第４実施例では、転送される画像データ量が第１実施例よりも更に少ない点で第１実施例よりも好ましい。
【０１３８】
なお、多くの場合には、フック処理モジュール４００によって描画される領域（第１の変化領域ＲＡ１）と、ＧＤＩ１２４及びディスプレイドライバ１２６で描画される領域（第２の変化領域ＲＡ２）とは一致している。従って、第４実施例のように、第１の変化領域ＲＡ１のうちで第２の変化領域ＲＡ２に含まれない部分の画像転送を省略しても、プロジェクタ２００ａに表示される画像に違和感が生じる可能性は無視できる程度である。これに対して、上述した第３実施例では、第１の変化領域ＲＡ１のうちで第２の変化領域ＲＡ２に重ならない部分も画像を転送するので、仮に、第１と第２の変化領域ＲＡ１，ＲＡ２がかなり大幅に異なっている場合にも、より完全な画像を転送できるという利点がある。
【０１３９】
なお、画像転送プログラム５００ａは、第３実施例の転送処理（「第１の転送モード」とも呼ぶ）と第４実施例の転送処理（「第２の転送モード」とも呼ぶ）を含む複数の転送モードの中から１つを選択して実行できるように構成されていても良い。転送モードの選択は、ユーザが行うようにしてもよく、あるいは、コンピュータ１００ａ（一般には画像供給装置）の処理能力（ＣＰＵの処理速度やバスの転送速度など）に応じて画像転送プログラム５００ａが自動的に転送モードの選択を行うようにしてもよい。こうすれば、適切な転送速度で好ましい画像を転送できる転送モードを選択することが可能である。
【０１４０】
Ｅ．第５実施例：
上述の第３実施例および第４実施例において、プロジェクタ２００ａがコンピュータ１００ａに、画面全体の画像データを要求できることとしてもよい。図２０は、このような要求に応じる処理の手順を示すフローチャートである。
【０１４１】
最初のステップＳ５００では、判断モジュール５４０（図９）が、リクエスト問い合わせを発行する。この処理は、図１０のステップＳ３１０と同じである。
【０１４２】
プロジェクタ２００ａのディスパッチャ２２６（図９）は、受信したＳＣＳＩコマンドのＯＰコードが「Ｄ９ｈ」でありＵＤコマンドコードが「００ｈ」であるので（Ｓ５０４：Ｙｅｓ、Ｓ５０８：Ｙｅｓ）、受信したデータを状態チェックモジュール２５０に供給する。なお、ＵＤコマンドコードが「００ｈ」とは異なる場合には、ＵＤコマンドコードに応じた処理が実行される（例えば、ＵＤコマンドコードが「８０ｈ」である場合には、画像表示処理が実行される）。また、ＯＰコードが「Ｄ９ｈ」とは異なる場合には、ＯＰコードに応じた処理が実行される（例えば、ディスクイメージ２２４に対するアクセス中継処理が実行される）。
【０１４３】
状態チェックモジュール２５０は、リクエスト問い合わせを受信したことに応じて、コンピュータ１００ａに送信すべきデータをＲＡＭ２０６（図２）から検索する（Ｓ５１２）。第５実施例では、状態チェックモジュール２５０は、入力部２１０（図２）を介してユーザから全画面取得指示を受けた場合には、全画面送信コマンドを表すコマンドデータを、送信すべきデータとしてＲＡＭ２０６（図２）に格納することとしている。このような全画面取得指示は、プロジェクタ２００ａによる表示画面に乱れが生じた場合に、ユーザによって発行され得る。
【０１４４】
このようなコマンドデータがＲＡＭ２０６から検出された場合には、状態チェックモジュール２５０は、検出されたコマンドデータをコンピュータ１００ａに送信し、そして、正常応答をコンピュータ１００ａに送信する（Ｓ５２０、Ｓ５２４）。一方、送信すべきデータが検出されなかった場合には、状態チェックモジュール２５０は、要求の無いことを表すデータをコンピュータ１００ａに送信し、そして、正常応答をコンピュータ１００ａに送信する（Ｓ５３０、Ｓ５３４）。ステップＳ５２０、Ｓ５３０の処理は、図１０のステップＳ３７０と同様に行われ、ステップＳ５２４、Ｓ５３４の処理は、図１０のステップＳ３７４と同様に行われる。
【０１４５】
コンピュータ１００ａによって受信されたデータは、判断モジュール５４０に供給される。判断モジュール５４０は、全画面送信コマンドを受信した場合には（Ｓ５４０：Ｙｅｓ）、次のステップＳ５５０で、全画面の画像データを送信する指示を、各モジュール５１０、５２０、５３０に対して発行する。その結果、全画面の画像データがプロジェクタ２００ａに送信され（Ｓ５５０）、プロジェクタ２００ａは、正しい全画面を表示する（Ｓ５５４）。一方、全画面送信コマンドが受信されなかった場合には（Ｓ５４０：Ｎｏ）、判断モジュール５４０は、処理を終了する。
【０１４６】
判断モジュール５４０は、上述したステップＳ５００〜Ｓ５５０の一連の処理を定期的に実行する。なお、これらの一連の処理は、コンピュータ１００ａが表示用データ送信処理完了の応答を受信した後から（例えば、図５のＳ２３８）、次の表示用データの送信が開始されるまで（例えば、図５のＳ２０４）の間に実行される。
【０１４７】
このように、第５実施例では、画像転送プログラム５００ａが、プロジェクタ２００ａからの要求に応じて全画面の画像データを送信するので、ユーザの利便性を向上させることができる。
【０１４８】
なお、プロジェクタ２００ａからコンピュータ１００ａへ送信される要求としては、画面全体の画像データの送信要求に限らず任意の要求を採用可能である。例えば、画像転送プログラム５００ａの動作設定（例えば、画像データの送信頻度）を変更する要求を採用してもよい。ここで、状態チェックモジュール２５０が、複数種類の要求を発行することとしてもよい。この場合には、要求を識別する情報をコンピュータ１００ａに送信すればよい。判断モジュール５４０は、この要求識別情報に応じて、要求された処理を実行すればよい。一般には、判断モジュール５４０は、プロジェクタ２００ａからの要求に応じて、要求された所定の処理を実行すればよい。ここで、プロジェクタ２００ａによる自発的なデータ送信が可能な場合には、判断モジュール５４０による要求問い合わせを省略してもよい。また、状態チェックモジュール２５０は、ユーザの指示が無い場合であっても、自動的に要求を発行してもよい。例えば、状態チェックモジュール２５０は、定期的に全画面送信要求を発行してもよい。また、ユーザの指示を受け取る入力部２１０（図２）としては、操作ボタンを含む装置に限らず、ユーザによって操作されるリモコンを介して指示を受け取る装置を採用してもよい。
【０１４９】
Ｆ．変形例：
なお、上記各実施例における構成要素の中の、独立クレームでクレームされた要素以外の要素は、付加的な要素であり、適宜省略可能である。また、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
【０１５０】
変形例１：
上述の各実施例において、コンピュータ１００、１００ａによって識別されるプロジェクタ２００、２００ａのデバイス種類としては、「マスストレージクラス」に限らず、汎用デバイスのための種々の種類（クラス）を採用可能である。このような汎用デバイスのためのクラスでは、通信プロトコルが標準化されているので、画像供給装置と画像表示装置との間のデータ通信を容易に行うことができる。また、このようなクラスのドライバは、広く普及している場合が多く、しばしば、ＵＳＢインターフェースを有する種々の装置に予め組み込まれている。従って、専用のドライバをインストールせずに、画像供給装置と画像表示装置とのデータ通信を行うことができる。また、専用ドライバの開発を省略することもできる。これらの結果、画像表示装置を利用するための労力を軽減することが可能となる。
【０１５１】
ここで、コンピュータ１００、１００ａからプロジェクタ２００、２００ａへのデータ転送速度が過剰に遅くならないように設計されたクラスを採用することが好ましい。例えば、「オーディオ（Audio）」と、「マスストレージ（Mass Storage）」と、「コミュニケーションデバイス（Communication Device）」と、の中から任意に選択されたものを採用可能である。
【０１５２】
なお、本発明は、ＵＳＢの将来のバージョンにも適用可能である。また、インターフェースとしては、ＵＳＢに限らず、複数種類の汎用デバイスに任意に接続可能な種々の汎用インターフェースを採用可能である。いずれの場合も、プロジェクタ２００、２００ａ２が汎用デバイスとして識別されることが好ましい。ここで、汎用デバイスとは、インターフェースの標準のプロトコルを利用してデータ通信を行うデバイスを意味している。標準のプロトコルとしては、そのインターフェースの規格団体によって標準化されたものを採用してもよく、また、業界の実質的な標準のものを採用してもよい。
【０１５３】
変形例２：
上記各実施例において、ディスクイメージ２２４（図３、図９）を省略してもよい。この場合には、コンピュータ１００、１００ａで実行されるプログラムを、インターネットや他の記録媒体から取得すればよい。ただし、上記各実施例のようにプロジェクタ２００、２００ａに、コンピュータ１００、１００ａからアクセス可能なデータ記憶部（例えば、ディスクイメージ２２４）を設ければ、データ記憶部に格納された種々のデータをコンピュータ１００、１００ａに提供することができる。この際、表示用データの送信に利用される通信コマンドは、データ記憶装置のための通信プロトコルで利用されるコマンドの内の、データ記憶部のデータリードのためのコマンドとは異なる所定のコマンドであることが好ましい。こうすれば、表示用データの転送と、データ記憶部のリードとを、両立させることができる。
【０１５４】
なお、データ記憶装置のための通信プロトコルで利用されるコマンドの内の、データリードのためのコマンドと、画像転送プログラム５００によって発行されるコマンド（特に、表示用データの送信コマンド）と、のいずれとも異なるコマンド（例えば、ライト（WRITE）コマンド）が発行された場合にプロジェクタ２００、２００ａによって実行される処理としては、任意の処理を採用可能である。例えば、ディスパッチャ２２６が、エラー応答をコンピュータ１００、１００ａに送信してもよい。また、ディスパッチャ２２６が、受信データをＳＣＳＩドライバ２３２に供給することによって、データ管理モジュール２３０に応答させてもよい。
【０１５５】
また、記憶領域に予め格納しておくデータとしては、プロジェクタ２００、２００ａの取扱説明書等の任意のデータを採用可能である。ただし、上記各実施例のように、プロジェクタ２００、２００ａに対して画像データ（表示用データ）を送信する機能をコンピュータ１００、１００ａに実現させるためのプログラムを採用することが好ましい。こうすれば、画像データを送信するためのプログラムを、容易にコンピュータ１００、１００ａに提供することができるので、プロジェクタ２００、２００ａを利用するための労力を軽減することができる。ここで、画像データの送信に利用されるプログラム（モジュール）の内の、記憶領域に格納しておくものとしては、任意に選択されたものを採用可能である。例えば、標準的にコンピュータ１００、１００ａに組み込まれているモジュールについては、省略してもよい。図９、図１２の例で、プロジェクタドライバ１２８が標準的にコンピュータ１００ａに組み込まれている場合には、ディスクイメージ２２４のプロジェクタドライバ１２８を省略してもよい。
【０１５６】
変形例３：
上記各実施例において、変化領域のみをキャプチャする方法としては、図１２〜図１８に示した第３実施例の方法や、図１９に示した第４実施例の方法に限らず、任意の方法を採用可能である。例えば、キャプチャモジュール５１０が、ＶＲＡＭ１１４を監視し続けることによって、変化した領域を検出してもよい。この場合には、キャプチャモジュール５１０は、ＶＲＡＭ１１４から変化領域の画像データを取得すればよい。また、図１７で説明したような最適化処理を省略してもよい。この場合には、キャプチャモジュール５１０は、最適化前の画面更新領域ＴＴＧを包含するような矩形形状の画像をキャプチャすればよい。このように、キャプチャされる画像は、変化した領域よりも大きくてもよい。ただし、画面全体の内の変化した領域を含む一部の画像であることが好ましい。
【０１５７】
また、コンピュータ１００、１００ａからプロジェクタ２００、２００ａへ供給される表示用データとしては、上記実施例で使用したもの以外の種々のものを使用することが可能である。例えば、表示用データとして、少なくとも画像データを含むものを使用することができる。具体的には、例えば、画面全体の画像データを転送する場合には、ヘッダ（変化領域情報）を転送する必要は無い。
【０１５８】
また、表示用データとしては、変化領域（画面更新領域）の位置及びサイズを示す情報と、変化領域内の画像データとを少なくとも含むことが好ましい。この理由は、変化領域に関するデータ（変化領域情報及びその画像データ）のみを転送すれば、転送すべきデータ量が少なくなるからである。
【０１５９】
変形例４：
上記各実施例において、プロジェクタ２００、２００ａによって表示される画面としては、表示デバイス１１８によって表示されている画面に限らず、任意の画面を採用可能である。例えば、コンピュータ１００、１００ａ上で動作している特定のアプリケーションによって描画される画像のみをプロジェクタ２００、２００ａで表示することとしてもよい。この場合には、キャプチャモジュール５１０が、そのアプリケーションによって描画される画像をキャプチャすればよい。
【０１６０】
変形例５：
上記各実施例では、ＳＣＳＩコマンドセットを利用している。従って、プロジェクタ２００、２００ａからコンピュータ１００、１００ａへ種々のデータ（例えば、図１０：Ｓ３７０の状態データや、図２０：Ｓ５２０のコマンドデータ）を送信する場合であっても、データサイズは、ＳＣＳＩのイニシエータに相当するコンピュータ１００、１００ａによって決められる（上記各実施例では所定のサイズに設定されている）。ここで、送信すべきデータのサイズが大きい場合には、データの一部がプロジェクタ２００、２００ａに残る場合がある。このような場合には、コンピュータ１００、１００ａに転送されるデータ内に残存データのサイズを書き込んでおき、コンピュータ１００、１００ａは、残存データの全てを受信するまで、プロジェクタ２００、２００ａにデータを送信させる処理を繰り返し実行すればよい。
【０１６１】
変形例６：
表示用データや状態データ、コマンドデータを転送する通信手順としては、上記各実施例の手順に限らず、種々の手順を採用可能である。例えば、図１４のステップＳ２６で、図８の例と同様に、表示用データを分割して送信してもよい。また、上記各実施例では、データ通信にＳＣＳＩコマンドセットが利用されていたが、データ通信に利用されるコマンドセットとしては、任意のものを採用可能である。また、データ通信の手順としても、採用されたコマンドセットに適した手順を採用すればよい。
【０１６２】
変形例７：
上記実施例では、第２の転送領域ＴＧ２（図１６（Ｃ），図１９（Ｃ））の画像部分をＶＲＡＭ１１４から取得して一旦ＲＡＭ１０６内の画像データ格納領域１０６ｂ内に書き込んだ後で、ＲＡＭ１０６から画面更新領域ＴＴＧの画像を取得してインターフェースを介して転送することとしていたが、画像データ格納領域１０６ｂに書き込む処理を省略することも可能である。但し、上記実施例の手順によれば、インターフェースを介して最終的に画像を転送する際に、画像を１つの画像データ格納領域１０６ｂから取得できるので、処理が単純になるという利点がある。
【０１６３】
変形例８：
上記実施例では、描画モジュールがＧＤＩ１２４とディスプレイドライバ１２６とプロジェクタドライバ１２８の３つのモジュールに分かれていたが、モジュールの区分は任意であり、これらの機能を１つのモジュールにまとめることも可能である。また、ディスプレイドライバ１２６とプロジェクタドライバ１２８の機能を１つのモジュールにまとめることも可能である。
【０１６４】
変形例９：
上記実施例においては、画像供給装置としてパーソナルコンピュータを用いていたが、この代わりに、他の種類のコンピュータ（モバイルコンピュータ、ハンドヘルドコンピュータ、ワークステーションなど）を用いるようにしても良い。また、これらコンピュータの他に、インターフェースを有するとともに、コンピュータと同様な機能を有する機器を用いるようにしても良い。そのような機器には、例えば、情報携帯端末や、携帯電話機や、メール端末や、ゲーム機や、セットトップボックスなどが含まれる。また、画像表示装置としては、プロジェクタ以外の種々の表示装置を使用することが可能である。
【０１６５】
変形例１０：
上記実施例においてソフトウェアで実現されている機能の一部をハードウェアで実現してもよく、あるいは、ハードウェアで実現されている機能の一部をソフトウェアで実現してもよい。
【符号の説明】
【０１６６】
１０…画像表示システム
６０…表示画面
７０…投写表示画面
１００、１００ａ…パーソナルコンピュータ（ＰＣ）
１０２…ＣＰＵ
１０４…ＲＯＭ
１０６…ＲＡＭ
１０６ａ…変化領域情報
１０６ａ１…変化領域情報
１０６ａ２…変化領域情報
１０６ｂ…画像データ格納領域
１０８…ハードディスクドライブ
１１０…入力部
１１２…ＵＳＢインターフェース部
１１４…ＶＲＡＭ
１１６…グラフィックコントローラ
１１８…表示デバイス
１２０…バス
１２２…アプリケーションプログラム
１２４…ＧＤＩ（グラフィックスデバイスインタフェイス）
１２６…ディスプレイドライバ
１２８…プロジェクタドライバ
１３０…ファイルシステムモジュール
１３２…ＳＣＳＩドライバ
１３４…マスストレージドライバ
１３６…ＵＳＢモジュール
２００、２００ａ…プロジェクタ
２０２…ＣＰＵ
２０４…ＲＯＭ
２０６…ＲＡＭ
２１０…入力部
２１２…ＵＳＢインターフェース部
２１４…画像処理部
２１６…投写部
２１８…バス
２２４…ディスクイメージ
２２６…コマンドディスパッチャモジュール
２３０…データ管理モジュール
２３２…ＳＣＳＩドライバ
２３４…マスストレージドライバ
２３６…ＵＳＢモジュール
２４０…画像表示モジュール
２４２…画像展開モジュール
２４４…データ取得モジュール
２５０…状態チェックモジュール
３００…ＵＳＢケーブル
４００…フック処理モジュール
５００、５００ａ…画像転送プログラム
５１０…キャプチャモジュール
５２０…データ生成モジュール
５３０…ＳＣＳＩラッパモジュール
５４０…判断モジュール
【技術分野】
【０００１】
本発明は、画像供給装置と画像表示装置との間の通信に関するものである。
【背景技術】
【０００２】
従来より、データ記憶装置や入力装置、画像表示装置といった種々の周辺装置が、コンピュータに接続され、利用されている。このような種々の周辺装置を手軽に接続するための汎用インターフェースとして、ＵＳＢ（Universal Serial Bus）インターフェースが、しばしば利用されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−６９９９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、コンピュータと、インターフェースを介して接続された周辺装置と、の間でデータ通信を行うためには、その周辺装置の種類に適した通信プロトコルが利用されている。例えば、プロジェクタのような画像表示装置を、画像信号専用のインターフェースの代わりに、このような汎用のインターフェースに接続する場合には、画像表示装置の機種毎に異なる専用の通信プロトコルが利用されている。
【０００５】
ところが、このような専用プロトコルのためのインターフェース制御用プログラム（デバイスドライバとも呼ばれる）の利用には、種々の作業が要求されていた。例えば、ユーザは、このような専用ドライバを自分でコンピュータにインストールしていた。また、画像表示装置の製造者は、このような専用ドライバを新たに開発していた。このように、画像表示装置を利用するために多大な労力が要求されていた。
【０００６】
なお、このような問題は、ＵＳＢインターフェースに限らず、複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに共通する問題であった。また、このような問題は、コンピュータに画像表示装置を接続する場合に限らず、一般に、インターフェースを介して画像供給装置から画像表示装置に画像を供給して表示させるシステムに共通する問題であった。
【０００７】
本発明は、上記の課題を解決するためになされたものであり、画像表示装置を利用するための労力を軽減することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述の課題の少なくとも一部を解決するため、本発明の第１の態様に係る画像表示装置は、画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置であって、前記インターフェースを介したデータ通信を制御する通信制御部と、前記画像データに基づいて画像を表示する画像表示部と、を備え、前記通信制御部は、前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信し、前記通信制御部は、前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する。
【０００９】
この画像表示装置によれば、汎用デバイスとして画像表示装置が識別されるので、画像供給装置と画像表示装置との間でのデータ通信を容易に行うことができる。その結果、画像表示装置を利用するための労力を軽減することができる。
【００１０】
ここで、前記インターフェースは、ＵＳＢインターフェースであり、前記識別情報は、マスストレージクラスに設定されていることが好ましい。
【００１１】
ＵＳＢインターフェースは、装置間の接続が容易であり、手軽に利用することができる。また、マスストレージクラスは、データ記憶装置に素早くデータを書き込むために、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送を素早く行うことが可能となる。
【００１２】
上記画像表示装置は、さらに、前記画像供給装置がアクセス可能なデータ記憶部を備え、前記通信制御部は、（ｉ）前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを受信した場合には、受信したデータを前記データ記憶部に供給し、（ｉｉ）データリードのための通信コマンドとは異なる所定の通信コマンドを受信した場合には、受信したデータを画像データとして前記画像表示部に供給することが好ましい。
【００１３】
この構成によれば、画像表示装置は、画像データを受信するとともに、データ記憶部に格納された種々のデータを画像供給装置に提供することができる。
【００１４】
さらに、前記データ記憶部は、前記マスストレージクラスよる通信を利用して前記画像表示装置に前記画像データを送信する機能をコンピュータに実現させるための画像転送プログラムを格納することが好ましい。
【００１５】
この構成によれば、画像データを画像表示装置に送信するためのプログラムを、容易に画像供給装置に提供することができるので、画像表示装置を利用するための労力を軽減することができる。
【００１６】
上記画像表示装置において、前記画像転送プログラムは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を前記コンピュータに実現させることが好ましい。
【００１７】
この構成によれば、一部の領域のみが変化した画像を画像表示装置に表示させる場合には、変化した領域を含む一部の領域のみが送信されるので、画像供給装置と画像表示装置との間で転送されるデータ量を低減することができる。その結果、画像表示装置によって表示される画像の更新頻度を高めることが可能となる。
【００１８】
上記各画像表示装置において、前記画像表示部は、受信済みの画像データによって表示されるべき現行画像の内の一部の領域のみを表す更新画像データを受信した場合に、前記一部の領域のみを更新することが好ましい。
【００１９】
この構成によれば、一部の領域のみが変化した画像を画像表示装置に表示させる場合には、変化した領域を含む一部の領域のみを送信すればよいので、画像供給装置と画像表示装置との間で転送されるデータ量を低減することができる。その結果、画像表示装置によって表示される画像の更新頻度を高めることが可能となる。
【００２０】
また、本発明の第２の態様に係る画像供給装置は、画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させるための画像供給装置であって、前記画像表示装置が接続されるインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースと、前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する通信制御部と、前記通信制御部を制御することによって、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する画像転送処理モジュールと、を備える。
【００２１】
この画像供給装置によれば、汎用デバイスとして画像表示装置が識別されるので、画像供給装置と画像表示装置との間でのデータ通信を容易に行うことができる。その結果、画像表示装置を利用するための労力を軽減することができる。
【００２２】
上記画像供給装置において、前記インターフェースは、ＵＳＢインターフェースであり、前記通信制御部は、前記画像表示装置のデバイス種類をマスストレージクラスとして識別することが好ましい。
【００２３】
ＵＳＢインターフェースは、装置間の接続が容易であり、手軽に利用することができる。また、マスストレージクラスは、データ記憶装置に素早くデータを書き込むために、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送を素早く行うことが可能となる。
【００２４】
上記画像供給装置において、前記画像表示装置は、さらに、前記画像供給装置がアクセス可能なデータ記憶部を備え、前記画像供給装置は、さらに、前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを利用することによって、前記データ記憶部に格納されたデータを読み出すデータ読み出しモジュールを備え、前記画像転送処理モジュールは、データリードのための通信コマンドとは異なる所定の通信コマンドを利用することによって、前記画像データを送信することが好ましい。
【００２５】
この構成によれば、画像供給装置は、画像データを送信するとともに、データ記憶部に格納された種々のデータを利用することができる。
【００２６】
上記各画像供給装置において、前記画像転送処理モジュールは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を有することが好ましい。
【００２７】
この構成によれば、一部の領域のみが変化した画像を画像表示装置に表示させる場合には、変化した領域を含む一部の領域のみが送信されるので、画像供給装置と画像表示装置との間で転送されるデータ量を低減することができる。その結果、画像表示装置によって表示される画像の更新頻度を高めることが可能となる。
【００２８】
上記画像供給装置において、さらに、画像の描画命令を発行可能なアプリケーションプログラムと、前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、を備え、前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、前記画像転送処理モジュールは、（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、（ｉｉ）前記第１の変化領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、（ｉｉｉ）取得した画像部分を、前記第１と第２の変化領域の和である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することとしてもよい。
【００２９】
この構成によれば、特定の描画命令が発行された場合には、描画モジュールの代わりにフック処理モジュールがその描画命令をフックして取得し、汎用メモリ内の画像を描画するので、転送対象となる画像の全体をＶＲＡＭからＲＡＭ（汎用メモリ）に転送する場合に比べて転送処理全体のスピードを向上させることができる。また、第２の変化領域のうちで第１の変化領域に含まれない領域はフック処理モジュールでは描画されていない領域であるが、この領域の画像はフレームメモリから取得するので、欠落無しに画像を転送することが可能である。
【００３０】
上記画像供給装置において、さらに、画像の描画命令を発行可能なアプリケーションプログラムと、前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、を備え、前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、前記画像転送処理モジュールは、（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、（ｉｉ）前記第２の変化領域のうちで前記第１の変化領域にも含まれる領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、（ｉｉｉ）取得した画像部分を、前記第２の変化領域と同一である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することとしてもよい。
【００３１】
この構成によれば、特定の描画命令が発行された場合には、描画モジュールの代わりにフック処理モジュールがその描画命令をフックして取得し、汎用メモリ内の画像を描画するので、転送対象となる画像の全体をＶＲＡＭからＲＡＭ（汎用メモリ）に転送する場合に比べて転送処理全体のスピードを向上させることができる。
【００３２】
なお、本発明は種々の形態で実現することが可能であり、例えば、画像表示システム、画像表示システムを構成する画像供給装置及び画像表示装置、画像供給装置に利用されるフック処理モジュール及び画像転送処理モジュール、画像供給方法及び画像表示方法、それら方法又は装置を実現するためのコンピュータプログラム、それらのコンピュータプログラムを記録した記録媒体などの種々の態様で実現することが可能である。
【図面の簡単な説明】
【００３３】
【図１】本発明の一実施例として画像表示システムの構成を示す説明図。
【図２】コンピュータ１００とプロジェクタ２００の内部構成を示すブロック図。
【図３】第１実施例におけるソフトウェア構成の詳細を示す説明図。
【図４】プロジェクタ２００をコンピュータ１００に接続したときに実行される接続処理の手順を示すフローチャート。
【図５】画像表示処理の手順を示すフローチャート。
【図６】Ｄ９コマンドの一例を示す説明図。
【図７】第２実施例における画像表示処理の手順を示すフローチャート。
【図８】第２実施例における画像表示処理の一例の具体的な手順を示すフローチャート。
【図９】第３実施例におけるソフトウェア構成の詳細を示す説明図。
【図１０】第３実施例における接続処理の手順を示すフローチャート。
【図１１】第３実施例における画像表示処理の手順を示すフローチャート。
【図１２】画面内の変化部分をキャプチャするためのコンピュータのソフトウェアとハードウェアの階層構造を示す説明図。
【図１３】実施例における変化領域情報と画像データ格納領域の例を示す説明図。
【図１４】第３実施例におけるフック処理モジュール４００と画像転送プログラム５００ａの動作を示すフローチャート。
【図１５】ステップＳ２０の詳細手順を示すフローチャート。
【図１６】第３実施例における変化領域と画面更新領域との関係を示す説明図。
【図１７】画面更新領域の最適化処理の内容を示す説明図。
【図１８】ステップＳ２２の詳細手順を示すフローチャート。
【図１９】第４実施例における変化領域と画面更新領域との関係を示す説明図。
【図２０】プロジェクタ２００ａの要求に応じる処理の手順を示すフローチャート。
【発明を実施するための形態】
【００３４】
次に、この発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．第１実施例：
Ｂ．第２実施例：
Ｃ．第３実施例：
Ｄ．第４実施例：
Ｅ．第５実施例：
Ｆ．変形例：
【００３５】
Ａ．第１実施例：
図１は本発明の一実施例として画像表示システムの構成を示す説明図である。本実施例の画像表示システム１０は、画像供給装置としてのパーソナルコンピュータ１００（以下「ＰＣ１００」とも呼ぶ）と、画像表示装置としてのプロジェクタ２００と、コンピュータ１００とプロジェクタ２００とをつなぐＵＳＢケーブル３００と、を備えている。コンピュータ１００は、ＵＳＢケーブル３００を介して画像をプロジェクタ２００供給して、プロジェクタ２００に画像を投写させて投写表示画面７０に表示させる機能を有している。
【００３６】
図２は、コンピュータ１００とプロジェクタ２００の内部構成を示すブロック図である。コンピュータ１００は、ＣＰＵ１０２と、ＲＯＭ１０４と、汎用メモリ（「システムメモリ」とも呼ぶ）としてのＲＡＭ１０６と、ハードディスクドライブ１０８と、キーボードやポインティングデバイスなどで構成される入力部１１０と、ＵＳＢインターフェース部１１２と、フレームメモリとしてのＶＲＡＭ１１４と、グラフィックコントローラ１１６と、液晶ディスプレイなどの表示デバイス１１８と、これら各要素を接続するバス１２０と、を備えている。
【００３７】
ＲＡＭ１０６には、アプリケーションプログラム１２２と、グラフィカルデバイスインターフェース（ＧＤＩ：Graphics Device Interface）１２４と、ディスプレイドライバ１２６と、ファイルシステムモジュール１３０と、ＳＣＳＩドライバ１３２と、マスストレージドライバ１３４と、ＵＳＢモジュール１３６と、画像転送プログラム５００と、を含む各種コンピュータプログラムが格納されている。なお、ＧＤＩ１２４と、ディスプレイドライバ１２６と、ファイルシステムモジュール１３０と、ＳＣＳＩドライバ１３２と、マスストレージドライバ１３４と、ＵＳＢモジュール１３６は、オペレーティングシステム（ＯＳ）の一部として機能する。なお、本実施例においては、オペレーティングシステムとして、マイクロソフト社によって提供されるWindows（登録商標）を想定している。このような各種コンピュータプログラムは、フレキシブルディスクやＣＤ−ＲＯＭ等の、コンピュータ読み取り可能な記録媒体に記録された形態で提供される。
【００３８】
ＧＤＩ１２４は、表示装置（例えば、コンピュータ１００の表示デバイス１１８）や印刷装置（図示せず）などへの描画を統一的に管理しているコンピュータプログラムである。良く知られているように、ＧＤＩ１２４は、「ＧＤＩ関数」と呼ばれる描画に関するアプリケーションプログラムインタフェース（ＡＰＩ：Application Program Interface）を各種のアプリケーションプログラムに対して提供している。なお、ＡＰＩとは、一般に、アプリケーションプログラムがオペレーティングシステムの持つ様々な機能を利用するための手続きの集まりを言う。
【００３９】
アプリケーションプログラム１２２は、ＧＤＩ１２４に対して、例えばプレゼンテーションファイルに含まれているプレゼンテーションシートの画像の描画要求を発行する。通常は、描画要求には、画像の出力先に関する情報（即ち、画像を表示装置に出力するか、印刷装置に出力するかを指定する情報）も含まれている。ＧＤＩ１２４は、アプリケーションプログラム１２２から出された描画要求を受け取り、その描画要求に基づいて画像の出力先をチェックし、その出力先が表示装置であれば、ディスプレイドライバ１２６に対して描画要求を渡す。ディスプレイドライバ１２６は、受け取った描画要求に従ってＶＲＡＭ１１４内に画像データを描画する。
【００４０】
コンピュータ１００の他の構成要素については、後述する。
【００４１】
一方、プロジェクタ２００は、ＣＰＵ２０２と、ＲＯＭ２０４と、ＲＡＭ２０６と、各種の操作ボタンを含む入力部２１０と、ＵＳＢインターフェース部２１２と、画像処理部２１４と、光源ランプと液晶パネルと投写光学系を含む投写部２１６と、これら各要素を接続するバス２１８と、を備えている。ＲＯＭ２０４には、画像表示モジュール２４０と、ディスクイメージ２２４と、コマンドディスパッチャモジュール２２６（以下、単に「ディスパッチャ２２６」とも呼ぶ）と、データ管理モジュール２３０と、ＳＣＳＩドライバ２３２と、マスストレージドライバ２３４と、ＵＳＢモジュール２３６と、を含む各種コンピュータプログラムが格納されている。
【００４２】
図３は、第１実施例におけるソフトウェア構成の詳細を示す説明図である。図３では、各構成要素が、データ通信の階層と同じ順番に並んで配置されている。ＵＳＢモジュール１３６、２３６は、それぞれ、ＵＳＢインターフェース部１１２、２１２（図２）を制御し、ＵＳＢプロトコルを解釈することによってデータ通信を行う。ＵＳＢモジュール１３６、２３６の上位層に設けられたマスストレージドライバ１３４、２３４は、マスストレージクラスの通信プロトコルに従ってデータ通信を行う。マスストレージドライバ１３４、２３４の上位層に設けられたＳＣＳＩドライバ１３２、２３２は、ＳＣＳＩコマンドセットを利用してデータ通信を行う。コンピュータ１００のファイルシステムモジュール１３０は、ＳＣＳＩドライバ１３２にデータアクセス要求を発行することによって、ファイルシステムの管理を行う。一方、プロジェクタ２００のデータ管理モジュール２３０は、ディスパッチャ２２６、ＳＣＳＩドライバ２３２を介してコンピュータ１００からのアクセス要求を受信し、この要求に応じて、ディスクイメージ２２４に対するアクセスを中継する。
【００４３】
また、図３には、画像転送プログラム５００と画像表示モジュール２４０との詳細な構成も示されている。画像転送プログラム５００は、キャプチャモジュール５１０と、データ生成モジュール５２０と、ＳＣＳＩラッパモジュール５３０と、を含んでいる。画像表示モジュール２４０は、画像展開モジュール２４２とデータ取得モジュール２４４とを含んでいる。これらの詳細については後述する。
【００４４】
図４は、プロジェクタ２００をコンピュータ１００に接続したときに実行される接続処理の手順を示すフローチャートである。まず、プロジェクタ２００は、ＳＣＳＩドライバ２３２（図３）と、マスストレージドライバ２３４と、ＵＳＢモジュール２３６とによって、ＣＤ−ＲＯＭドライブとして動作する（ステップＳ１００）。
【００４５】
次に、コンピュータ１００のＵＳＢモジュール１３６は、ＵＳＢケーブル３００を介してプロジェクタ２００がコンピュータ１００に接続されたことを検出し（ステップＳ１０４）、この検出に応じてプロジェクタ２００に装置構成情報を要求する（ステップＳ１０８）。
【００４６】
プロジェクタ２００のＵＳＢモジュール２３６は、この要求に応じて、装置構成情報をコンピュータ１００に送信する（ステップＳ１１２）。送信される装置構成情報には、プロジェクタ２００がＵＳＢ規格に準じたデータ記憶装置として動作することを表す情報が含まれている。具体的には、装置構成情報には、ＵＳＢデバイスのデバイスクラス（インターフェースクラス）が「マスストレージクラス」であることを示す情報が含まれている。また、よく知られているように、「マスストレージクラス」で利用可能なコマンドセットは、インターフェースサブクラスによって特定される。第１実施例のプロジェクタ２００は、「ＳＣＳＩコマンドセット」に対応していることとしている。そこで、装置構成情報には、サブクラスが「ＳＣＳＩコマンドセット」であることを示す情報も含まれる。なお、サブクラスとしては、他の種々のクラス（例えば、「ＡＴＡＰＩ」）を採用可能である。また、装置構成情報には、他の種々のＵＳＢディスクリプタも含まれている。
【００４７】
コンピュータ１００（図３）のＵＳＢモジュール１３６は、この装置構成情報を受信したことに応じて、プロジェクタ２００をマスストレージクラスに分類される装置であると識別し、ＯＳに標準的に備えられている汎用のマスストレージドライバ１３４をロードする（ステップＳ１１６）。マスストレージドライバ１３４は、動作中のＯＳプロセス内に組み込まれる。これにより、コンピュータ１００は、マスストレージドライバ１３４を利用することによって、プロジェクタ２００とデータ通信を行うことが可能となる。
【００４８】
なお、マスストレージドライバ１３４は、ＵＳＢのクラスドライバに相当する。クラスドライバは、ＵＳＢバスのドライバ（図３の例では、ＵＳＢモジュール１３６）の上位層に位置し、ＵＳＢデバイスの種類に応じた通信プロトコルに従ってＵＳＢデバイスとの通信を行う通信制御モジュールである。ＵＳＢ規格では、ＵＳＢデバイスの種類が複数のクラスに分類されている。そして、クラス毎（すなわち、デバイス種類毎）に異なる通信プロトコルが利用されている。ここで、種々の機能を有するＵＳＢデバイスを利用可能とするために、ベンダ独自のクラス（Vendor Specific Class）を定義することも可能である。この場合には、専用の通信プロトコル（すなわち、専用のクラスドライバ）が利用される。
【００４９】
一方、いくつかの代表的なクラスについては、装置間のデータ通信を容易に行うために、通信プロトコルが標準化されている。「マスストレージクラス」は、このようなクラスの一つである。マスストレージドライバ１３４は、マスストレージクラス用の通信プロトコルに従ってデータ通信を行う。このようなマスストレージドライバ１３４は、特定の製造者のデータ記憶装置に限らず、種々の製造者のデータ記憶装置（例えば、ＣＤ−ＲＯＭドライブやＤＶＤ−ＲＯＭドライブ、ハードディスクドライブ、半導体メモリ）に共用される。同様に、標準化された通信プロトコルを利用する汎用のデータ記憶装置（例えば、ＣＤ−ＲＯＭドライブ）は、特定の製造者のコンピュータに限らず、種々の製造者のコンピュータ（例えば、パーソナルコンピュータや情報携帯端末）に対して共通に利用可能である。
【００５０】
また、本実施例では、マスストレージドライバ１３４（図３）とともに、ＳＣＳＩドライバ１３２もロードされる。この際、ＳＣＳＩドライバ１３２は、プロジェクタ２００のＳＣＳＩドライバ２３２から、プロジェクタ２００がＣＤ−ＲＯＭドライブであることを示す情報を取得する。これにより、ファイルシステムモジュール１３０は、ＳＣＳＩドライバ１３２を介してＳＣＳＩコマンドをプロジェクタ２００に送信することにより、プロジェクタ２００（ディスクイメージ２２４）をＣＤ−ＲＯＭドライブとして利用可能である。なお、プロジェクタ２００は、ＣＤ−ＲＯＭドライブに限らず、種々のデータ記憶装置（例えば、ＤＶＤ−ＲＯＭドライブや、ハードディスクドライブ）として識別されてもよい。いずれの場合も、ディスクイメージ２２４からのデータ読み出しは、ファイルシステムモジュール１３０とＳＣＳＩドライバ１３２とによって行われる。このように、ファイルシステムモジュール１３０とＳＣＳＩドライバ１３２との全体は、本発明における「データ読み出しモジュール」に相当する。
【００５１】
次のステップＳ１２０では、コンピュータ１００は、ＣＤ−ＲＯＭドライブとして認識したプロジェクタ２００に記憶されているオートランプログラムを実行する。これにより、ディスクイメージ２２４（図３）に記録された画像転送プログラム５００が、プロジェクタ２００からコンピュータ１００へ送信され（ステップＳ１２４）、そして、画像転送プログラム５００が起動する（ステップＳ１２８）。Windowsオペレーティングシステムは、ＣＤ−ＲＯＭのルートフォルダに、「Autorun.inf」というファイルが記録されていると、このファイルによって指定された任意のプログラムの実行を行う。そこで、本実施例ではこの機能を利用して、ディスクイメージ２２４に記録された画像転送プログラム５００を実行することとしている。
【００５２】
なお、オペレーティングシステムの設定によっては、オートランプログラムの自動実行機能が無効になっている場合がある。また、オペレーティングシステムの中には、自動実行機能を利用できないものもある。このような場合には、ユーザの指示に応じて、コンピュータ１００が、画像転送プログラム５００をプロジェクタ２００（ディスクイメージ２２４）から取得してもよい。また、プロジェクタ２００に格納された画像転送プログラム５００の代わりに、別のＣＤ−ＲＯＭ等の記録媒体に記録された画像転送プログラム５００や、インターネットからダウンロードした画像転送プログラム５００を利用してもよい。
【００５３】
起動した画像転送プログラム５００は、プロジェクタ２００を利用した画像表示処理を開始する。図５は、画像表示処理の手順を示すフローチャートである。最初のステップＳ２００では、キャプチャモジュール５１０（図３）は、表示デバイス１１８（図２）によって表示されている画像をキャプチャする。画像のキャプチャ方法としては、任意の方法を採用可能である。例えば、画像をキャプチャするためのＧＤＩ関数を呼び出してもよく、他の描画用ＡＰＩを利用してもよい。また、キャプチャモジュール５１０が、直接に、ＶＲＡＭ１１４から画像データを取得することとしてもよい。なお、第１実施例では、表示デバイス１１８によって表示されている表示画面の全体がキャプチャされる。
【００５４】
次のステップＳ２０４では、データ生成モジュール５２０は、キャプチャによって取得されたキャプチャ画像データを用いて、表示用データを生成する。第１実施例では、キャプチャ画像データを圧縮することによって、表示用データが生成される。圧縮のアルゴリズムとしては、任意のものを採用可能である。ただし、圧縮せずに、表示用データを生成してもよい。これは、後述する他の実施例についても同じである。
【００５５】
次に、データ生成モジュール５２０は、ＳＣＳＩラッパモジュール５３０に対して、表示用データを送信する命令を発行する。ＳＣＳＩラッパモジュール５３０は、この命令に応じて、表示用データを送信するための特別なＳＣＳＩコマンド（以下「Ｄ９コマンド」とも呼ぶ）を生成する。図６は、Ｄ９コマンドの一例を示す説明図である。このＤ９コマンドは、ＳＣＳＩの規定で定められているコマンドデスクリプターブロック（ＣＤＢ：Command Descriptor Block）の構造に準じている。この理由は、ＳＣＳＩドライバ１３２（図３）と同様に、マスストレージドライバ１３４を利用することによってプロジェクタ２００とデータ通信を行うためである。
【００５６】
０バイト目は、オペレーションコード（以下「ＯＰコード」とも呼ぶ）を表している。ＯＰコードはコマンドを識別するコードであり、「リード」や「ライト」といったコマンド毎に所定のコードが予め割り当てられている。第１実施例では、画像転送プログラム５００によって発行されたＳＣＳＩコマンドには、「Ｄ９ｈ（ｈは１６進表記を意味する。以下同様）」が割り当てられる。これにより、ＯＰコードが「Ｄ９ｈ」である場合には、そのコマンドが画像転送プログラム５００によって発行されたものであると判定できる。ＯＰコードが「Ｄ９ｈ」以外の場合には、そのコマンドがＳＣＳＩドライバ１３２によって発行されたものであると判定できる。
【００５７】
なお、画像転送プログラム５００によって発行されたＳＣＳＩコマンドを識別するＯＰコードとしては、「Ｄ９ｈ」に限らず任意のコードを採用可能である。ただし、ディスクイメージ２２４のデータリードのためのＳＣＳＩコマンドのコードとは異なるコードを採用することが好ましい。こうすれば、画像データの転送と、ディスクイメージ２２４のリードと、を両立させることができる。なお、データリードのためのコマンドとは、データ記憶装置をインターフェースに接続してから、通信を確立し、データリードを完了するまでの一連の処理に利用されるコマンドを意味している。このようなコマンドには、例えば、インクワイアリ（inquiry）コマンドやリード（READ）コマンドが含まれる。
【００５８】
２バイト目は、ＵＤコマンドコードを表している。ＵＤコマンドコードは、画像転送プログラム５００が発行するコマンドの具体的な内容を識別するコードである。画像転送プログラム５００が複数種類のコマンドを発行する場合には、これらのコマンドがＵＤコマンドコードによって識別される。従って、ＯＰコードとＵＤコマンドコードとの組み合わせによって、画像転送プログラム５００によって発行されたコマンドを識別することができる。だたし、画像転送プログラム５００によって発行されるコマンドが、画像データ送信コマンドのみである場合には、ＵＤコマンドコードを省略してもよい。
【００５９】
３バイト目から６バイト目は、送信されるデータサイズを表している。このデータサイズは、このＳＣＳＩコマンドに続けて送信されるデータのサイズを意味している。後述するように、このＤ９コマンドに続けて表示用データが送信されるので、データサイズは、表示用データのサイズに設定される。
【００６０】
７バイト目は、ＣＥフラグを表している。ＣＥフラグは、送信されるデータの続きの有無を示すフラグである。データを複数の部分データに分割して送信する場合がある。この場合、最後の部分データを送信するためのＤ９コマンドでは、ＣＥフラグが「Ｅ（終了）」に設定され、他の部分データを送信するためのＤ９コマンドでは、ＣＥフラグが「Ｃ（継続）」に設定される。データを分割せずに送信する場合には、ＣＥフラグは「Ｅ」に設定される。
【００６１】
Ｄ９コマンドの他の部分は、所定の値に設定される。これらの値は、ＳＣＳＩの規定に従ったデータ通信に利用される（詳細は省略）。
【００６２】
Ｄ９コマンドが生成されたら、ＳＣＳＩラッパモジュール５３０は、このＤ９コマンド（ＣＤＢ）と表示用データとを送信する命令をマスストレージドライバ１３４に対して発行する。すると、マスストレージドライバ１３４は、Ｄ９コマンドを送信するためのコマンドブロックラッパ（ＣＢＷ：Command Block Wrapper）を生成する。ＣＢＷは、マスストレージクラスを利用してＳＣＳＩコマンドを送信するためのデータであり、ＣＤＢを格納している。そして、マスストレージドライバ１３４は、ＵＳＢモジュール１３６を制御することによって、ＣＢＷと表示用データとをこの順番に送信する。
【００６３】
図５には、送信されるＣＢＷと表示用データＴＤとが示されている。表示用データＴＤは、ヘッダＩｍｇＨと、圧縮された画像データＩｍｇＤとを含んでいる。ヘッダＩｍｇＨは、圧縮形式（アルゴリズム）と、画像の高さ（ドット数）及び幅（ドット数）と、画面内における画像の位置と、を表す情報を含んでいる。画面内の位置は、例えば、画像データＩｍｇＤによって表される画像の基準点（通常は左上の角のドット）の画面内の位置によって表される。なお、第１実施例では、表示用データＴＤは、分割されずに送信される。
【００６４】
コンピュータ１００は、以上説明した画像のキャプチャと（Ｓ２００）、ＣＢＷ（Ｄ９コマンド）と表示用データＴＤとの送信と（Ｓ２０４）、を繰り返し実行する。
【００６５】
一方、プロジェクタ２００では、ＵＳＢモジュール２３６、マスストレージドライバ２３４によってＣＢＷ（Ｄ９コマンド）と表示用データＴＤとが受信される（ステップＳ２２０）。次のステップＳ２２４では、ディスパッチャ２２６は、ＣＢＷに格納されたＳＣＳＩコマンドのＯＰコードが「Ｄ９ｈ」であるか否かを判断する。ＯＰコードが「Ｄ９ｈ」である場合には、次のステップＳ２３０で、ディスパッチャ２２６は、受信されたデータをデータ取得モジュール２４４に供給する。供給されるデータには、ＳＣＳＩコマンドと、そのコマンドと共に送信されたデータ（すなわち、ＣＢＷと表示用データＴＤ）が含まれる。次のステップＳ２３４では、データ取得モジュール２４４は、表示用データＴＤを抽出して画像展開モジュール２４２に供給する。画像展開モジュール２４２は、ヘッダＩｍｇＨで指定された圧縮形式に従って画像データＩｍｇＤを伸長する。そして、画像展開モジュール２４２は、ヘッダＩｍｇＨの情報（高さ、幅、位置）と伸長された画像データとに従って画像処理部２１４（図２）を制御し、画像処理部２１４によって画像処理部２１４内の表示メモリ（図示せず）に画像データを展開させる。この際、画像展開モジュール２４２は、投写部２１６の解像度（画素数）と、ヘッダＩｍｇＨの情報と、に応じた解像度変換処理を実行してもよい。
【００６６】
以上の結果、プロジェクタ２００は、図１に示すように、投写表示画面７０に画像を表示することができる。このように、画像表示モジュール２４０は、プロジェクタ２００が画像データを受信したことに応じて、画像を表示する。従って、コンピュータ１００が画像データの送信を繰り返し実行することによって、プロジェクタ２００によって表示される画像も繰り返し更新される。
【００６７】
次のステップＳ２３８では、データ取得モジュール２４４は、正常に表示用データＴＤを受信したことを表す応答を送信する命令をマスストレージドライバ２３４に対して発行する。すると、マスストレージドライバ２３４は、応答を送信するためのコマンドステイタスラッパ（ＣＳＷ：Command Status Wrapper）を生成する。ＣＳＷは、マスストレージクラスを利用してＳＣＳＩのステータス応答を送信するためのデータである。そして、マスストレージドライバ２３４は、ＵＳＢモジュール２３６を制御することによって、ＣＳＷを送信する。
【００６８】
一方、ＯＰコードが「Ｄ９ｈ」とは異なる場合には（Ｓ２２４：Ｎｏ）、次のステップＳ２９０で、ディスパッチャ２２６は、受信されたデータをＳＣＳＩドライバ２３２に供給する。供給されるデータには、ＳＣＳＩコマンドと、そのコマンドと共に送信されたデータが含まれる。ただし、ＳＣＳＩコマンドのみが受信される場合には、ＳＣＳＩコマンドのみが供給される（例えば、ＲＥＡＤコマンドが発行される場合）。次のステップＳ２９４では、データ管理モジュール２３０は、ＳＣＳＩドライバ２３２を介して受け取ったＳＣＳＩコマンドに従って、ディスクイメージ２２４に対するアクセスを中継する（例えば、ディスクイメージ２２４に格納されたデータがコンピュータ１００に送信される）。なお、ＳＣＳＩドライバ２３２とデータ管理モジュール２３０とディスクイメージ２２４との全体は、本発明における「データ記憶部」に相当する。
【００６９】
次のステップＳ２９８では、データ管理モジュール２３０は、コマンドの実行結果を表すステータス応答をコンピュータ１００に送信する。この処理は、ステップＳ２３８と同様に行われる。なお、画像転送プログラム５００がコンピュータ１００に送信される場合には、これらのステップＳ２９０〜Ｓ２９８の処理が実行される。
【００７０】
以上のように、第１実施例は、以下のような種々の特徴と利点を有している。第１の特徴点は、プロジェクタ２００が、プロジェクタとは異なる汎用デバイス（マスストレージクラス）として識別される点である。プロジェクタ２００のＵＳＢモジュール２３６は、このような汎用デバイスを示す識別情報（デバイスクラス（インターフェースクラス））をコンピュータ１００に送信する。これにより、プロジェクタ２００のための専用のデバイスドライバをコンピュータ１００にインストールせずに、汎用のマスストレージドライバ１３４を利用して、ＵＳＢインターフェース部１１２、２１２を介したデータ通信（画像データの転送）が可能となるという利点がある。なお、プロジェクタ２００におけるＵＳＢモジュール２３６とマスストレージドライバ２３４とディスパッチャ２２６との全体は、本発明における「画像表示装置の通信制御部」に相当する。一方、コンピュータ１００におけるＵＳＢモジュール１３６とマスストレージドライバ１３４との全体は、本発明における「画像供給装置の通信制御部」に相当する。
【００７１】
第２の特徴点は、プロジェクタ２００が、データ記憶装置（マスストレージクラス）として識別される点である。マスストレージクラスの通信プロトコルは、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送速度を高め、プロジェクタ２００による表示画像の更新頻度を高めることが可能となる。
【００７２】
第３の特徴点は、プロジェクタ２００のデータ記憶部（ディスクイメージ２２４）に、画像転送プログラム５００が格納されている点である。これにより、画像転送プログラム５００を、容易に、コンピュータ１００に提供することができる。その結果、画像転送プログラム５００の準備が容易となるので、プロジェクタ２００の利用に関する利便性をさらに向上させることができる。
【００７３】
Ｂ．第２実施例：
図７は、第２実施例における画像表示処理の手順を示すフローチャートである。この図７には、プロジェクタ２００が実行する処理が示されている。第２実施例では、図５に示す第１実施例とは異なり、データ生成モジュール５２０は、キャプチャされた画像データを複数の部分データに分割して、１つずつ順番にプロジェクタ２００に送信する。装置の構成は、図１〜図３に示す第１実施例と同じである。
【００７４】
ステップＳ２２０、Ｓ２２４の処理は、図５のステップＳ２２０、Ｓ２２４の処理と、それぞれ同じである。Ｄ９コマンドを受け取ったデータ取得モジュール２４４は、ＣＥフラグ（図６）の値を確認する（Ｓ２２８）。ＣＥフラグが「Ｃ」に設定されている場合には、データ取得モジュール２４４は、受信した部分データをＲＡＭ２０６（図２）に格納し（Ｓ２４０）、正常応答を発行する（Ｓ２４４）。このステップＳ２４４は、図５のステップＳ２３８と同様である。そして、処理はステップＳ２２０に戻り、データ取得モジュール２４４は、残りの部分データを待つ。
【００７５】
複数の部分データの内の最後の部分データが送られてきた場合には、ＣＥフラグが「Ｅ」に設定されている。この場合には、次のステップＳ２５０で、データ取得モジュール２４４は、受信した複数の部分データを結合することによって表示用データを再構成し、この表示用データを画像展開モジュール２４２に供給する。すると、画像展開モジュール２４２は、図５のステップＳ２３４と同様に、ヘッダと画像データに従って画像処理部２１４（図２）を制御する。この結果、プロジェクタ２００は、図１に示すように、投写表示画面７０に画像を表示する。次のステップＳ２５４は、図５のステップＳ２３８と同様である。このステップＳ２５４の後、処理はステップＳ２２０に戻る。そして、上述した一連の処理が繰り返し実行される。
【００７６】
図８は、第２実施例における画像表示処理の一例の具体的な手順を示すフローチャートである。この例は、画像データが２つの部分データに分割して送られる場合を示している。
【００７７】
最初のステップＳ２００は、図５のステップＳ２００と同じである。次のステップＳ２０８ａでは、データ生成モジュール５２０（図３）は、キャプチャされた画像データを圧縮することによって送信用画像データＩｍｇＤを生成し、この画像データＩｍｇＤを用いて第１表示用データＴＤ１を生成する。ここで、データ生成モジュール５２０は、画像データＩｍｇＤを、第１部分データＩｍｇＤ１と第２部分データＩｍｇＤ２とに分割する。そして、データ生成モジュール５２０は、ヘッダＩｍｇＨと第１部分データＩｍｇＤ１とから構成される第１表示用データＴＤ１を生成する。
【００７８】
次に、データ生成モジュール５２０は、ＣＥフラグを「Ｃ」に設定して第１表示用データＴＤ１を送信する命令をＳＣＳＩラッパモジュール５３０に対して発行する。ＳＣＳＩラッパモジュール５３０によって生成されるＤ９コマンド（ＣＤＢ１）では、ＯＰコードが「Ｄ９ｈ」に設定され、ＣＥフラグが「Ｃ」に設定されている。
【００７９】
生成されたＤ９コマンド（ＣＤＢ１）を格納するコマンドブロックラッパＣＢＷ１と、第１表示用データＴＤ１とは、マスストレージドライバ１３４によって、プロジェクタ２００に送信される。
【００８０】
一方、データを受信したプロジェクタ２００では、受信されたＤ９コマンドのＣＥフラグが「Ｃ」に設定されているので、図７のステップＳ２２８、Ｓ２４０、Ｓ２４４と同様の一連の処理が実行される。
【００８１】
コンピュータ１００では、ステップＳ２４４で発行された正常応答（ＣＳＷ）を受信したことに応じて、データ生成モジュール５２０（図３）が、残りの第２部分データＩｍｇＤ２を送信する命令をＳＣＳＩラッパモジュール５３０に対して発行する（Ｓ２０８ｂ）。この際、ＣＥフラグを「Ｅ」に設定する指示が発行される。ＳＣＳＩラッパモジュール５３０によって生成されたＤ９コマンド（ＣＤＢ２）では、ＯＰコードが「Ｄ９ｈ」に設定され、ＣＥフラグが「Ｅ」に設定されている。
【００８２】
生成されたＤ９コマンド（ＣＤＢ２）を格納するコマンドブロックラッパＣＢＷ２と、第２表示用データＴＤ２（第２部分データＩｍｇＤ２）とは、マスストレージドライバ１３４によって、プロジェクタ２００に送信される。
【００８３】
一方、データを受信したプロジェクタ２００では、受信されたＤ９コマンドのＣＥフラグが「Ｅ」に設定されているので、図７のステップＳ２２８、Ｓ２５０、Ｓ２５４と同様の一連の処理が実行される。
【００８４】
以上、画像データが２つの部分データに分割して送信される場合について説明したが、画像データが３つ以上の部分データに分割して送信される場合についても、同様の手順に従って、部分データが逐次送信され、全ての部分データが転送された後に画像が表示される。
【００８５】
このように、第２実施例の画像表示処理では、画像データが分割して送信される。従って、画像データのサイズが大きい場合であっても、適切にプロジェクタ２００に画像データの全体を送信することができる。特に、通信用のインターフェースによっては、１回のコマンド発行で送信可能なデータサイズに上限が設けられている場合が多い。このような場合であっても、サイズに拘わらずに、画像データの全体を転送することができる。
【００８６】
なお、図８の例では、送信用画像データＩｍｇＤを分割して送信していたが、画像データを分割して送信する方法としては、他の種々の方法を採用可能である。例えば、表示画面を複数の部分画面に分割し、各部分画面毎にキャプチャ画像データを送信してもよい。例えば、表示デバイス１１８の表示画面を左半分と右半分との２つの部分画面に区分してもよい。ここで、左部分画面の画像データをプロジェクタ２００へ送信して、プロジェクタ２００に左半分を更新させ、その後、右部分画面の画像データを送信して、プロジェクタ２００に右半分を更新させる一連の処理を、繰り返し実行してもよい。ここで、表示画面全体のキャプチャ画像データの転送が完了した後に、プロジェクタ２００が表示を更新してもよい。なお、画面の区分としては、左半分と右半分への区分に限らず任意の区分を採用可能である。また、３以上の領域に区分してもよい。
【００８７】
Ｃ．第３実施例：
図９は、第３実施例におけるソフトウェア構成の詳細を示す説明図である。図３に示す第１実施例との差違は３点ある。第１の差違は、画像転送プログラム５００ａが、判断モジュール５４０を有している点である。第２の差違は、コンピュータ１００ａ上で、フック処理モジュール４００と、プロジェクタドライバ１２８と、が動作している点である。第３の差違は、プロジェクタ２００ａ上で、状態チェックモジュール２５０が動作している点である。他の構成は、図３に示す第１実施例と同じである。第３実施例では、これらの構成要素によって、画面の変化領域のみが、コンピュータ１００ａからプロジェクタ２００ａに転送される。なお、コンピュータ１００ａ上で動作するプログラム５００ａ、４００、１２８は、ディスクイメージ２２４に格納されている。そして、図４に示す接続処理におけるオートランプログラム、あるいは、ユーザの指示に応じて、プロジェクタ２００ａからコンピュータ１００ａに転送される。また、ハードウェア構成は、図１、図２に示す第１実施例と同じである。
【００８８】
図１０は、第３実施例における接続処理の手順を示すフローチャートである。図１０の処理は、図４に示す接続処理の後に実行される。この接続処理は、コンピュータ１００ａが、プロジェクタ２００ａによる画像データ受信準備の完了を待つために、実行される。プロジェクタ２００ａの受信準備完了を待つ理由は以下の通りである。第３実施例では、後述するように、最初に画面全体の画像データが送信された後は、画像の変化した部分の画像データのみが送信される。従って、最初の画面全体の画像データを確実にプロジェクタ２００ａに受信させるために、コンピュータ１００ａは、プロジェクタ２００ａの受信準備完了を待つ。
【００８９】
最初のステップＳ３００では、判断モジュール５４０（図９）は、プロジェクタ２００ａに、状態問い合わせを送信する命令を、ＳＣＳＩラッパモジュール５３０に対して発行する。ＳＣＳＩラッパモジュール５３０は、画像データを送信する場合と同様に、状態問い合わせを送信するためのＤ９コマンドを生成する。ここで、ＵＤコマンドコード（図６）は、画像データ送信コマンドのＵＤコマンドコードとは異なるコードに設定される。例えば、第３実施例では、画像データ送信コマンドに対しては「８０ｈ」が採用され、状態問い合わせを送信するコマンドに対しては「Ｃ１ｈ」が採用されることとしている。生成されたＤ９コマンドは、マスストレージドライバ１３４によってプロジェクタ２００ａに送信される。なお、受信状態に加えて他の種々の状態を、この状態問い合わせ用のＤ９コマンド（ＵＤコマンドコード＝Ｃ１ｈ）を用いて問い合わせる場合には、このＤ９コマンドに続けて、問い合わせの内容を識別するデータを送信してもよい。
【００９０】
一方、プロジェクタ２００ａのディスパッチャ２２６は、ＳＣＳＩコマンドを受信したら（Ｓ３５０）、そのコマンドがＤ９コマンドか否かを判断する（Ｓ３５４）。そのコマンドがＤ９コマンドである場合には、さらに、ＵＤコマンドコードを確認する（Ｓ３５８）。ＵＤコマンドコードが「Ｃ１ｈ」である場合には、受信したデータを状態チェックモジュール２５０に供給する。なお、図１０では図示を省略しているが、ＵＤコマンドコードが「８０ｈ」である場合には、ディスパッチャ２２６は、受信したデータ（画像データ送信用Ｄ９コマンドと表示用データ）をデータ取得モジュール２４４に供給する。
【００９１】
ＵＤコマンドコードがＣ１ｈに設定されたＤ９コマンド（すなわち、状態問い合わせ）を受信した状態チェックモジュール２５０は、プロジェクタ２００ａの状態が、画像データ受信が可能な状態か否かを判断する（Ｓ３６０）。受信可能と判断するための条件としては、受信した画像データを消失させずに保持できることを示す任意の条件を採用可能である。例えば、画像表示モジュール２４０（図９）の起動が完了していることを条件として採用してもよい。また、画像処理部２１４（図２）の起動が完了していることを条件として採用してもよい。状態チェックモジュール２５０は、判断結果を表す状態データを、コンピュータ１００ａに送信すべきデータとして、ＲＡＭ２０６（図２）に格納する。本実施例では、状態データは、「ＲＥＤＹ（受信可能）」あるいは「ＢＵＳＹ（受信不可）」のいずれかの文字列である。
【００９２】
次に、状態チェックモジュール２５０は、状態問い合わせを正常に受信したことを示す応答をコンピュータ１００ａに送信する（Ｓ３６４）。この応答送信は、図５のステップＳ２３８と同様に行われる。なお、この段階では、状態データはコンピュータ１００ａに送信されない。この理由は、プロジェクタ２００ａは、ＳＣＳＩのターゲットに相当するので、自発的にデータを送信することができないからである。
【００９３】
コンピュータ１００ａの判断モジュール５４０は、正常応答（ＣＳＷ）を受信したことに応じて（Ｓ３０４）、リクエスト問い合わせを送信する命令を、ＳＣＳＩラッパモジュール５３０に対して発行する（Ｓ３１０）。このリクエスト問い合わせは、プロジェクタ２００ａに種々のデータを送信させるためのコマンドである。ＳＣＳＩラッパモジュール５３０は、画像データを送信する場合と同様に、Ｄ９コマンドを生成する。ここで、ＵＤコマンドコード（図６）は、画像データ送信コマンドと、状態問い合わせ送信コマンドと、のいずれのコードとも異なるコードに設定される。例えば、第３実施例では、リクエスト問い合わせ送信コマンドに対しては「００ｈ」が採用されることとしている。生成されたＤ９コマンドは、マスストレージドライバ１３４によってプロジェクタ２００ａに送信される。
【００９４】
一方、プロジェクタ２００ａのディスパッチャ２２６は、受信したＳＣＳＩコマンドがＤ９コマンドであり（Ｓ３５４：Ｙｅｓ）、ＵＤコマンドコードが「００ｈ」である場合には、受信したデータを状態チェックモジュール２５０に供給する。
【００９５】
ＵＤコマンドコードが００ｈに設定されたＤ９コマンド（すなわち、リクエスト問い合わせ）を受信した状態チェックモジュール２５０は、先ほどのステップＳ３６０でメモリに格納した状態データを送信する命令を、マスストレージドライバ２３４に対して発行する（Ｓ３７０）。マスストレージドライバ２３４は、命令に従って、状態データをコンピュータ１００ａに送信する。次のステップＳ３７４では、状態チェックモジュール２５０は、リクエスト問い合わせに応じたデータ送信を正常に行ったことを示す応答をコンピュータ１００ａに送信する。この応答は、ステップＳ３６４と同様に行われる。
【００９６】
コンピュータ１００ａによって受信された状態データと応答とは、判断モジュール５４０に供給される（Ｓ３１４、Ｓ３１８）。状態データが「ＢＵＳＹ」である場合には、判断モジュール５４０は、「ＲＥＤＹ」に設定された状態データを受信するまで、ステップＳ３００〜Ｓ３２０の一連の処理を繰り返し実行する。
【００９７】
状態データが「ＲＥＤＹ」である場合には、判断モジュール５４０は、次のステップＳ３３０で、画像表示処理を開始する指示を、各モジュール５１０、５２０、５３０に対して発行する。
【００９８】
図１１は、第３実施例における画像表示処理の手順を示すフローチャートである。最初のステップＳ４００、Ｓ４０４、Ｓ４０８、Ｓ４１２の処理は、図５のステップＳ２００、Ｓ２０４、Ｓ２３４、Ｓ２３８と、それぞれ同じである。特に、ステップＳ４００では、表示デバイス１１８によって表示されている表示画面の全体がキャプチャされる。これにより、プロジェクタ２００ａは、図１に示すように、投写表示画面７０に画像を表示することができる。なお、図１１のフローチャートでは、ＯＰコードとＵＤコマンドコードとを確認する処理は、図示が省略されている。
【００９９】
次のステップＳ４２０では、キャプチャモジュール５１０は、画面内の変化した領域のみのキャプチャを実行する。この変化領域のみのキャプチャの詳細については後述する。次のステップＳ４２４では、ステップＳ４０４と同様に、キャプチャされた画像データがコンピュータ１００ａからプロジェクタ２００ａへ送信される。この際、ヘッダにおけるサイズ（高さ、幅）と位置とは、変化領域を表す値に設定される。
【０１００】
次のステップＳ４２８では、画像展開モジュール２４２は、ステップＳ４０８と同様に、ヘッダと画像データに従って画像処理部２１４（図２）を制御する。この際、変化領域を表す部分の画像データのみが更新される。他の部分については更新されずに維持される。その結果、プロジェクタ２００ａは、変化領域が更新された画像を表示することができる。次のステップＳ４３２は、ステップＳ４１２と同じである。このステップＳ４３２の後、処理は、ステップＳ４２０に戻る。そして、上述したステップＳ４２０〜Ｓ４３２の一連の処理が繰り返し実行される。
【０１０１】
以上のように、第３実施例では、表示画面の全体が送信された後は、変化した領域のみが送信される。また、画像展開モジュール２４２は、変化した領域のみを受信した場合には、変化した領域のみを更新する。これらにより、送信されるデータ量を低減することができる。その結果、プロジェクタ２００ａによって表示される画像の更新頻度を速めることが可能となる。
【０１０２】
なお、図１１の例では、画面全体の画像データ送信が接続直後の１回だけであったが（Ｓ４００、Ｓ４０４）、接続後、複数回に渡って画面全体の画像データが送信されてもよい。こうすれば、プロジェクタ２００ａによって表示される画像が乱れることを抑制できる。例えば、画像転送プログラム５００ａが、定期的に画面全体の画像データを送信してもよい。また、画像転送プログラム５００ａが、ユーザの指示を受けたことに応じて画面全体の画像データを送信してもよい。
【０１０３】
次に、変化領域のみのキャプチャ（図１１：Ｓ４２０）について説明する。図１２は、画面内の変化部分をキャプチャするためのコンピュータのソフトウェアとハードウェアの階層構造を示す説明図である。アプリケーションプログラム１２２と画像転送プログラム５００ａは、アプリケーションプログラム層（「ユーザアプリケーションプログラム層」とも呼ぶ）に属する。ＧＤＩ１２４とディスプレイドライバ１２６とプロジェクタドライバ１２８は、カーネル層に属する。また、汎用メモリとしてのＲＡＭ１０６と、ＵＳＢインターフェース部１１２と、ＶＲＡＭ１１４と、グラフィックコントローラ１１６と、表示デバイス１１８は、ハードウェア層に属する。
【０１０４】
また、アプリケーションプログラム１２２とＧＤＩ１２４との間には、フック処理モジュール４００が設けられている。フック処理モジュール４００は、アプリケーションプログラム１２２が発行する特定の描画命令をフックして先取りし、後述する処理を実行する。他の描画命令は通常通りＧＤＩ１２４によって処理される。なお、フック処理モジュール４００は、アプリケーションプログラム１２２に応じた適切な特定の描画命令のみをフックするように、各アプリケーションプログラム専用に構成されることが好ましい。
【０１０５】
第３実施例では、アプリケーションプログラム１２２としてプレゼンテーションプログラム（例えばマイクロソフト社のPowerPoint）を使用した場合について説明する。まず、描画命令がフック処理モジュール４００を介さずに直接にＧＤＩ１２４に渡される場合について説明し、次に、描画命令がフック処理モジュール４００によって先取りされる場合について説明する。
【０１０６】
アプリケーションプログラム１２２は、ＧＤＩ１２４に対して、例えばプレゼンテーションファイルに含まれているプレゼンテーションシートの画像の描画要求を発行する。通常は、描画要求には、画像の出力先に関する情報（即ち、画像を表示装置に出力するか、印刷装置に出力するかを指定する情報）も含まれている。
【０１０７】
なお、ＧＤＩ１２４の代わりに、他の汎用の描画用ＡＰＩを使用することも可能である。「汎用の描画用ＡＰＩ」とは、多数のアプリケーションプログラムに対して共通に使用されるＡＰＩを意味している。
【０１０８】
ＧＤＩ１２４と、ディスプレイドライバ１２６と、プロジェクタドライバ１２８の全体は、描画命令に従って描画処理を実行する描画モジュールとして機能する。具体的には、ＧＤＩ１２４は、アプリケーションプログラム１２２から出された描画要求を受け取り、その描画要求に基づいて画像の出力先をチェックし、その出力先が表示装置であれば、ディスプレイドライバ１２６とプロジェクタドライバ１２８のそれぞれに対して描画要求を渡す。
【０１０９】
ディスプレイドライバ１２６は、受け取った描画要求に従ってＶＲＡＭ１１４内に画像データを描画する。なお、よく知られているように、描画要求としては、画面の全体を描画するものに限らず、画面の一部を描画するものも多用される。画面の一部を描画する描画命令を受けた場合には、ディスプレイドライバ１２６は、ＶＲＡＭ１１４内で描画対象となっている領域（「変化領域」とも呼ぶ）の画像部分のみを描画する。グラフィックコントローラ１１６は、ＶＲＡＭ１１４内に描画された画像データ（即ち、ビットマップデータ）に基づいて、表示デバイス１１８に画像を表示する。一方、プロジェクタドライバ１２８は、ＧＤＩ１２４から受け取った描画要求に従って、ＶＲＡＭ１１４内の描画対象領域（すなわち変化領域）の位置及びサイズを表す変化領域情報１０６ａをＲＡＭ１０６内に書き込む。以下、プロジェクタドライバ１２８によって書き込まれる変化領域情報を、第２変化領域情報１０６ａ２（変化領域情報Ａ２）とも呼ぶ。
【０１１０】
図１３（Ａ），（Ｂ）は、ＲＡＭ１０６内の変化領域情報１０６ａ２と画像データ格納領域１０６ｂの例を示す説明図である。ここでは、プロジェクタで投写表示されるべき画像が図１３（Ａ）から図１３（Ｂ）のように変化する例を想定する。後述するように、画像データ格納領域１０６ｂには、キャプチャモジュール５１０によってＶＲＡＭ１１４から転送された画像データが格納される。画像データ格納領域１０６ｂは、ＶＲＡＭ１１４（フレームメモリ）と同じデータ容量を有することが好ましい。
【０１１１】
変化領域Ｒａは、図４（Ａ）から図４（Ｂ）に画像を変更する際の描画命令によって描画される画像部分の領域である。この変化領域Ｒａに関する変化領域情報１０６ａ２は、変化領域Ｒａの基準点（通常は左上点）のｘ座標Ｘａ及びｙ座標Ｙａと、変化領域Ｒａの幅Ｗａ及び高さＨａとを含んでいる。なお、基準点の座標（Ｘａ，Ｙａ）は、変化領域Ｒａの位置を示すデータであり、幅Ｗａと高さＨａは変化領域Ｒａのサイズを示すデータである。
【０１１２】
キャプチャモジュール５１０は、ＲＡＭ１０６内の変化領域情報１０６ａ２を参照して、変化領域Ｒａの画像データを、ＶＲＡＭ１１４からＲＡＭ１０６内の画像データ格納領域１０６ｂに転送する。この画像データ格納領域１０６ｂは、例えばコンピュータ１００又はプロジェクタ２００の表示解像度に等しいサイズのメモリ領域である。キャプチャモジュール５１０は、さらに、画像データ格納領域１０６ｂから変化領域Ｒａの画像データを読み出して、読み出した画像データと変化領域情報１０６ａ２とをデータ生成モジュール５２０に供給する。データ生成モジュール５２０は、受け取ったデータを用いて、表示用データ（ヘッダと画像データ）を生成する。生成された表示用データは、マスストレージドライバ１３４によってプロジェクタ２００ａに送信される。
【０１１３】
このように、描画命令がフック処理モジュール４００を介さずに直接にＧＤＩ１２４に渡される場合には、一旦ＶＲＡＭ１１４に格納された画像データを汎用メモリであるＲＡＭ１０６に転送した後で、ＲＡＭ１０６内にある画像データをプロジェクタ２００ａに転送している。このため、ＶＲＡＭ１１４からＲＡＭ１０６に転送するためにかなりの時間を要してしまい、十分な転送速度が得られない場合があった。
【０１１４】
次に、描画命令がフック処理モジュール４００によって先取りされる場合について説明する。なお、フック処理モジュール４００も一種の描画用ＡＰＩと考えることも可能であるが、ＧＤＩ１２４のような汎用の描画用ＡＰＩとは区別される。すなわち、フック処理モジュール４００は、典型的には特定の描画命令のみを処理するように構成されているのに対して、ＧＤＩ１２４はすべての描画命令を処理するように構成されている点で相違する。
【０１１５】
フック処理モジュール４００は、例えばＤＬＬ（ダイナミックリンクライブラリ）としてアプリケーションプログラム１２２にロード（インストール）される。一般に、アプリケーションプログラムは「プロセス」という単位で動作している。また、アプリケーションプログラムの実行中は、そのプロセス内に複数のモジュール（GDI32.DLLやKernel32.DLLなど）がロードされており、アプリケーションプログラムはそれらのモジュール内の関数を利用することによって各種の動作を行っている。フック処理モジュール４００の「ロード」とは、アプリケーションプログラム１２２のプロセス内に、フックプロシージャが実装されているモジュール４００を組み込むことを意味している。
【０１１６】
フック処理モジュール４００がロードされる際には、アプリケーションプログラム１２２から発行される特定の描画命令の関数アドレスが、フック処理モジュール４００内に実装されている独自機能を実行するための別の関数のアドレスに差し替えられる。この独自機能の関数内では、変化情報と画像データのＲＡＭへの書き込み処理（後述する）が実行され、その後、通常のＧＤＩ関数が実行される。フック処理モジュール４００をアンロードする際には、ロード時に差し替えられていた関数アドレスを元に戻した後に、プロセス内にロードされていたフック処理モジュール４００がアンロードされる。
【０１１７】
なお、フック処理モジュール４００は、必要に応じていつでもアプリケーションプログラム１２２にロードしたり、アンロードしたりすることが可能である。但し、画像転送プログラム５００ａが起動する際に、動作中の特定のアプリケーションプログラム１２２（本実施例ではプレゼンテーションプログラム）にフック処理モジュール４００をロードし、また、画像転送プログラム５００ａを終了するときにフック処理モジュール４００をアンロードするように、画像転送プログラム５００ａを構成することが好ましい。こうすれば、画像転送プログラム５００ａが実行中の期間にのみフック処理モジュール４００を動作させることができるので、コンピュータ１００上で画像転送プログラム５００ａが実行されていない（起動していない）ときに描画命令をフックしてしまい、望ましくない結果が生じることを回避することができる。なお、本明細書において、「コンピュータ１００上で画像転送プログラム５００ａが実行されている」という文言は、画像転送プログラム５００ａのプロセスが起動されていることを意味している。
【０１１８】
図１４は、第３実施例におけるフック処理モジュール４００と画像転送プログラム５００ａの動作を示すフローチャートである。ステップＳ１０〜Ｓ１６はフック処理モジュール４００によって実行され、ステップＳ２０〜Ｓ２６は画像転送プログラム５００ａによって定期的に実行される。
【０１１９】
フック処理モジュール４００は、アプリケーションプログラム１２２から特定の描画命令が発行されたときに、ステップＳ１０においてその描画命令をフックして、ＧＤＩ１２４の代わりにその描画命令を取得する。なお、フック処理モジュール４００がフックする描画命令は、すべての描画命令ではなく、限られた特定の描画命令のみに限定することが好ましい。この理由は、アプリケーションプログラム１２２が発行する描画命令には多数のものがあるので、そのすべてをフックするようにすると、却って処理速度を低下させたり、所望の描画を行えなかったりする可能性があるからである。
【０１２０】
ステップＳ１２では、取得した描画命令に応じて変化領域情報を登録する処理が実行される。具体的には、フック処理モジュール４００が、描画命令に従って描画が行われる領域（図１３（Ｂ）の変化領域Ｒａ）の位置とサイズを取得し、その変化領域を表す変化領域情報１０６ａ１（以下「変化領域情報Ａ１」とも呼ぶ）をＲＡＭ１０６に直接書き込む処理を実行する。
【０１２１】
ステップＳ１４では、変化領域Ｒａの画像データの書込処理が実行される。具体的には、フック処理モジュール４００が、描画命令に従って変化領域Ｒａ内の画像データを展開して、その画像データをＲＡＭ１０６内の画像データ格納領域１０６ｂに直接書き込む処理を実行する。
【０１２２】
ステップＳ１６では、フック処理モジュール４００が、ステップＳ１０で取得した描画命令に従って通常のＧＤＩ関数を呼び出して描画処理を実行させる。なお、ディスプレイドライバ１２６とプロジェクタドライバ１２８（図１２）は、描画命令がフック処理モジュール４００を介さずに直接にＧＤＩ１２４に渡される場合と同様に、ＧＤＩ１２４から受け取った描画命令に従ってそれぞれの処理を実行する。すなわち、ディスプレイドライバ１２６がＶＲＡＭ１１４内に画像を描画し、プロジェクタドライバ１２８がその描画領域を示す変化領域情報Ａ２をＲＡＭ１０６内に書き込む。
【０１２３】
一方、キャプチャモジュール５１０は、ステップＳ２０において、プロジェクタ２００に転送すべき画像データの領域（「画面更新領域」と呼ぶ）を決定する。図１５は、ステップＳ２０の詳細手順を示すフローチャートである。ステップＳ３０，Ｓ３２では、第１と第２の変化領域情報Ａ１，Ａ２が取得される。前述したように、第１の変化領域情報Ａ１は、フック処理モジュール４００によってＲＡＭ１０６内の画像データ格納領域１０６ｂに描画された領域を表す情報であり、フック処理モジュール４００によってＲＡＭ１０６内に書き込まれたものである。一方、第２の変化領域情報Ａ２は、ディスプレイドライバ１２６によってＶＲＡＭ１１４内に描画された領域を表している情報であり、プロジェクタドライバ１２８によってＲＡＭ１０６内に書き込まれたものである。
【０１２４】
図１６（Ａ）は、２つの変化領域情報Ａ１，Ａ２で表される２つの変化領域ＲＡ１，ＲＡ２の一例を示している。ここでは、２つの変化領域ＲＡ１，ＲＡ２を、同一の画面領域ＳＣＡ内に配置している。ここで、「画面領域ＳＣＡ」とは、ＶＲＡＭ１１４に格納される画像の全体の領域を意味しており、これは、画像データ格納領域１０６ｂ全体の領域と等しい。厳密に言えば、第１の変化領域ＲＡ１は画像データ格納領域１０６ｂ内のアドレスで定義された領域であり、第２の変化領域ＲＡ２はＶＲＡＭ１１４内のアドレスで定義された領域であるが、これらは同じ画面領域ＳＣＡで表現することができる。
【０１２５】
なお、図１６（Ａ）の例では、２つの変化領域ＲＡ１，ＲＡ２は部分的に重なっているが、２つの変化領域ＲＡ１，ＲＡ２はこれ以外の種々の関係を取る場合がある。例えば、２つの変化領域ＲＡ１，ＲＡ２が全く重なり合わない場合も存在し、両者が完全に重なり合う場合も存在する。例えば、フック処理モジュール４００が特定の描画命令に従って描画を行い、その後、通常の描画モジュール１２４，１２６，１２８が同じ描画命令に従って同じ領域の描画を行った場合には、２つの変化領域ＲＡ１，ＲＡ２は同一となる。但し、同じ描画命令を実行したときにも、各モジュールの設定によっては、２つの変化領域ＲＡ１，ＲＡ２に若干の差異が生じる場合もあり得る。
【０１２６】
図１６（Ｂ）は、キャプチャモジュール５１０がキャプチャ時にＲＡＭ１０６から画像を直接取得する領域ＴＧ１を示しており、図１６（Ｃ）はＶＲＡＭ１１４から画像を取得する領域ＴＧ２を示している。これらの領域ＴＧ１，ＴＧ２を「転送領域」とも呼ぶ。この例から理解できるように、第１の変化領域ＲＡ１（＝ＴＧ１）の画像は、ＲＡＭ１０６内から直接取得される。一方、第２の変化領域ＲＡ２のうちで第１の変化領域ＲＡ１に含まれない部分の領域ＴＧ２の画像は、ＶＲＡＭ１１４から取得される。このように区別する理由は、ＶＲＡＭ１１４から取得する画像を可能な限り少なくして、その取得に要する時間を少なくするためである。例えば、２つの変化領域ＲＡ１，ＲＡ２が完全に重なる場合には、ＶＲＡＭ１１４から画像を取得する必要が無くなるので、転送処理を高速に行うことができる。図１６（Ｄ）は、キャプチャモジュール５１０によって取得される領域全体（画面更新領域ＴＴＧ）を示している。この画面更新領域ＴＴＧは、第１と第２の変化領域ＲＡ１，ＲＡ２の和領域に相当する。
【０１２７】
なお、第１の変化領域情報Ａ１に複数の描画命令に対応する複数の情報が含まれている場合がある。この場合には、これらの複数の描画命令の描画領域の和領域が第１の変化領域ＲＡ１となる。第２の変化領域ＲＡ２についても同様である。
【０１２８】
図１５のステップＳ３４では、キャプチャモジュール５１０が、２種類の変化領域情報Ａ１，Ａ２で表される変化領域ＲＡ１，ＲＡ２の差分を計算する。具体的には、第２の変化領域ＲＡ２の中で、第１の変化領域ＲＡ１に含まれない領域ＴＧ２（図１６（Ｃ））が算出される。ステップＳ３６では、キャプチャモジュール５１０によって、画面更新領域ＴＴＧ（図１６（Ｄ））の最適化処理が実行される。
【０１２９】
図１７は、画面更新領域の最適化処理の内容を示す説明図である。図１７（Ａ）は、図１６（Ｄ）と同じ画面更新領域ＴＴＧを示している。最適化処理では、図１７（Ｂ）に示すように、画面更新領域ＴＴＧを互いに重ならない隣接する矩形領域Ｒ１１〜Ｒ１３に分割する。そして、これらの矩形領域Ｒ１１〜Ｒ１３が、最適化後の画面更新領域として採用される。個々の画面更新領域Ｒ１１〜Ｒ１３は矩形なので、最適化前の画面更新領域ＴＴＧを包含するような矩形形状の画像を転送する場合に比べて、転送される画像データ量を削減することが可能である。
【０１３０】
図１４のステップＳ２２では、キャプチャモジュール５１０によって、画面更新領域に相当する画像部分の画像データが取得される。図１８は、ステップＳ２２の詳細手順を示すフローチャートである。ステップＳ４０では、第２の転送領域ＴＧ２（図１６（Ｃ））が空である否かが調べられる。第２の変化領域情報Ａ２が存在しない場合、及び、第２の変化領域Ａ２が第１の変化領域Ａ１に完全に包含されている場合には、第２の転送領域ＴＧ２は空である。第２の転送領域ＴＧ２が空である場合には、後述するステップＳ４４に移行する。一方、第２の転送領域ＴＧ２が空でない場合には、ステップＳ４２が実行される。ステップＳ４２では、キャプチャモジュール５１０が第２の転送領域ＴＧ２の画像データをＶＲＡＭ１１４から取得してＲＡＭ１０６内の画像データ格納領域１０６ｂに書き込む。この結果、画像データ格納領域１０６ｂには、図１６（Ｄ）に示す画面更新領域ＴＴＧ内の画像がすべて格納された状態になる。ステップＳ４４では、キャプチャモジュール５１０が画面更新領域ＴＴＧの画像データをＲＡＭ１０６の画像データ格納領域１０６ｂから取得する。なお、実際に取得されるのは、最適化処理後の個々の画面更新領域Ｒ１１〜Ｒ１３（図１０（Ｂ））の画像データである。
【０１３１】
図１４のステップＳ２４では、キャプチャモジュール５１０は、変化領域情報と画像データとをデータ生成モジュール５２０に供給する。データ生成モジュール５２０は、受信したデータを用いて、表示用データを生成する。ステップＳ２６では、こうして生成された表示用データが、ＵＳＢインターフェース部１１２を介してプロジェクタ２００ａに転送される。なお、最適化処理によって画面更新領域が複数の部分領域に分割された場合には、各部分領域毎に表示用データが生成される。なお、各表示用データは、１つのＤ９コマンドでまとめて転送されてもよく、別々のＤ９コマンドで転送されてもよい。
【０１３２】
一方、プロジェクタ２００ａ（図９）の画像展開モジュール２４２は、受信した表示用データ（ヘッダと画像データ）に従って画像処理部２１４を制御し、プロジェクタ２００ａによって表示される画像を更新する。
【０１３３】
このように、第３実施例では、フック処理モジュール４００が、特定の描画命令をフックして先取りし、変化領域の画像データをＲＡＭ１０６に直接書き込む処理を実行するようにしている。この結果、ＶＲＡＭ１１４からＲＡＭ１０６への画像データの転送に要していた時間を節約することができる。この結果、プロジェクタ２００ａに画像データを転送する場合の転送速度を十分に速くすることができるという利点がある。
【０１３４】
なお、一般に使用されているパーソナルコンピュータでは、ＲＡＭ１０６からＶＲＡＭ１１４へのデータ転送は非常に高速に実行できるのに対して、ＶＲＡＭ１１４からＲＡＭ１０６へのデータ転送はその数倍低速でしか実行できないアーキテクチャとなっていることが多い。第３実施例では、低速なＶＲＡＭからＲＡＭへのデータ転送を削減できるので、プロジェクタ２００に画像データを転送するために要する時間を大幅に削減することが可能である。
【０１３５】
また、上記第３実施例では、フック処理モジュール４００によって描画されていない領域ＴＧ２（図１６（Ｃ））の画像部分に関しては、ＶＲＡＭ１１４から取得してプロジェクタ２００ａに転送している。この結果、通常の描画モジュール１２４，１２６，１２８で描画された画像についても欠落無しにプロジェクタ２００に転送することが可能である。
【０１３６】
Ｄ．第４実施例：
図１９は、第４実施例における変化領域と画面更新領域との関係を示す説明図であり、第３実施例の図１６に対応するものである。第４実施例は、装置構成や処理フローの全体は第３実施例と同じであるが、転送対象となる領域が第３実施例と異なっている。具体的には、第４実施例では、ＲＡＭ１０６から画像が直接取得される第１の転送領域ＴＧ１（図１９（Ｂ））は、第１と第２の変化領域ＲＡ１，ＲＡ２が重なり合っている部分に設定される。換言すれば、第１の転送領域ＴＧ１は、第２の変化領域ＲＡ２のうちで第１の変化領域ＲＡ１にも含まれている領域に設定される。一方、ＶＲＡＭ１１４から画像が取得される第２の転送領域ＴＧ２（図１９（Ｃ））は、第３実施例と同様に、第２の変化領域ＲＡ２のうちで第１の変化領域ＲＡ１に含まれていない部分に設定される。従って、転送対象となる領域の全体である画面更新領域ＴＴＧ（図１９（Ｄ））は、第２の変化領域ＲＡ２と同一である。
【０１３７】
このように、第４実施例では、ＧＤＩ１２４及びディスプレイドライバ１２６によってＶＲＡＭ１１４内に描画される領域である第２の変化領域ＲＡ２内の画像が画像転送プログラム５００ａによって転送されることになる。このように処理を行う理由は、以下の通りである。すなわち、フック処理モジュール４００によってフック処理された描画命令も、その後、ＧＤＩ１２４及びディスプレイドライバ１２６によって再度実行されるので、基本的にすべての描画命令がＧＤＩ１２４及びディスプレイドライバ１２６によって実行される。従って、第２の変化領域ＲＡ２の画像を転送すれば、プロジェクタ２００ａに正しい画像を表示させることが可能である。但し、この際にすべての画像データをＶＲＡＭ１１４から取得すると、データ転送にかなりの時間を要するという問題を生じてしまう。そこで、第４実施例では、第２の変化領域ＲＡ２の中で、第１の変化領域ＲＡ１に含まれている部分についてはＲＡＭ１０６から画像データを直接取得することによって、データ取得に要する時間を短縮している。また、第４実施例では、転送される画像データ量が第１実施例よりも更に少ない点で第１実施例よりも好ましい。
【０１３８】
なお、多くの場合には、フック処理モジュール４００によって描画される領域（第１の変化領域ＲＡ１）と、ＧＤＩ１２４及びディスプレイドライバ１２６で描画される領域（第２の変化領域ＲＡ２）とは一致している。従って、第４実施例のように、第１の変化領域ＲＡ１のうちで第２の変化領域ＲＡ２に含まれない部分の画像転送を省略しても、プロジェクタ２００ａに表示される画像に違和感が生じる可能性は無視できる程度である。これに対して、上述した第３実施例では、第１の変化領域ＲＡ１のうちで第２の変化領域ＲＡ２に重ならない部分も画像を転送するので、仮に、第１と第２の変化領域ＲＡ１，ＲＡ２がかなり大幅に異なっている場合にも、より完全な画像を転送できるという利点がある。
【０１３９】
なお、画像転送プログラム５００ａは、第３実施例の転送処理（「第１の転送モード」とも呼ぶ）と第４実施例の転送処理（「第２の転送モード」とも呼ぶ）を含む複数の転送モードの中から１つを選択して実行できるように構成されていても良い。転送モードの選択は、ユーザが行うようにしてもよく、あるいは、コンピュータ１００ａ（一般には画像供給装置）の処理能力（ＣＰＵの処理速度やバスの転送速度など）に応じて画像転送プログラム５００ａが自動的に転送モードの選択を行うようにしてもよい。こうすれば、適切な転送速度で好ましい画像を転送できる転送モードを選択することが可能である。
【０１４０】
Ｅ．第５実施例：
上述の第３実施例および第４実施例において、プロジェクタ２００ａがコンピュータ１００ａに、画面全体の画像データを要求できることとしてもよい。図２０は、このような要求に応じる処理の手順を示すフローチャートである。
【０１４１】
最初のステップＳ５００では、判断モジュール５４０（図９）が、リクエスト問い合わせを発行する。この処理は、図１０のステップＳ３１０と同じである。
【０１４２】
プロジェクタ２００ａのディスパッチャ２２６（図９）は、受信したＳＣＳＩコマンドのＯＰコードが「Ｄ９ｈ」でありＵＤコマンドコードが「００ｈ」であるので（Ｓ５０４：Ｙｅｓ、Ｓ５０８：Ｙｅｓ）、受信したデータを状態チェックモジュール２５０に供給する。なお、ＵＤコマンドコードが「００ｈ」とは異なる場合には、ＵＤコマンドコードに応じた処理が実行される（例えば、ＵＤコマンドコードが「８０ｈ」である場合には、画像表示処理が実行される）。また、ＯＰコードが「Ｄ９ｈ」とは異なる場合には、ＯＰコードに応じた処理が実行される（例えば、ディスクイメージ２２４に対するアクセス中継処理が実行される）。
【０１４３】
状態チェックモジュール２５０は、リクエスト問い合わせを受信したことに応じて、コンピュータ１００ａに送信すべきデータをＲＡＭ２０６（図２）から検索する（Ｓ５１２）。第５実施例では、状態チェックモジュール２５０は、入力部２１０（図２）を介してユーザから全画面取得指示を受けた場合には、全画面送信コマンドを表すコマンドデータを、送信すべきデータとしてＲＡＭ２０６（図２）に格納することとしている。このような全画面取得指示は、プロジェクタ２００ａによる表示画面に乱れが生じた場合に、ユーザによって発行され得る。
【０１４４】
このようなコマンドデータがＲＡＭ２０６から検出された場合には、状態チェックモジュール２５０は、検出されたコマンドデータをコンピュータ１００ａに送信し、そして、正常応答をコンピュータ１００ａに送信する（Ｓ５２０、Ｓ５２４）。一方、送信すべきデータが検出されなかった場合には、状態チェックモジュール２５０は、要求の無いことを表すデータをコンピュータ１００ａに送信し、そして、正常応答をコンピュータ１００ａに送信する（Ｓ５３０、Ｓ５３４）。ステップＳ５２０、Ｓ５３０の処理は、図１０のステップＳ３７０と同様に行われ、ステップＳ５２４、Ｓ５３４の処理は、図１０のステップＳ３７４と同様に行われる。
【０１４５】
コンピュータ１００ａによって受信されたデータは、判断モジュール５４０に供給される。判断モジュール５４０は、全画面送信コマンドを受信した場合には（Ｓ５４０：Ｙｅｓ）、次のステップＳ５５０で、全画面の画像データを送信する指示を、各モジュール５１０、５２０、５３０に対して発行する。その結果、全画面の画像データがプロジェクタ２００ａに送信され（Ｓ５５０）、プロジェクタ２００ａは、正しい全画面を表示する（Ｓ５５４）。一方、全画面送信コマンドが受信されなかった場合には（Ｓ５４０：Ｎｏ）、判断モジュール５４０は、処理を終了する。
【０１４６】
判断モジュール５４０は、上述したステップＳ５００〜Ｓ５５０の一連の処理を定期的に実行する。なお、これらの一連の処理は、コンピュータ１００ａが表示用データ送信処理完了の応答を受信した後から（例えば、図５のＳ２３８）、次の表示用データの送信が開始されるまで（例えば、図５のＳ２０４）の間に実行される。
【０１４７】
このように、第５実施例では、画像転送プログラム５００ａが、プロジェクタ２００ａからの要求に応じて全画面の画像データを送信するので、ユーザの利便性を向上させることができる。
【０１４８】
なお、プロジェクタ２００ａからコンピュータ１００ａへ送信される要求としては、画面全体の画像データの送信要求に限らず任意の要求を採用可能である。例えば、画像転送プログラム５００ａの動作設定（例えば、画像データの送信頻度）を変更する要求を採用してもよい。ここで、状態チェックモジュール２５０が、複数種類の要求を発行することとしてもよい。この場合には、要求を識別する情報をコンピュータ１００ａに送信すればよい。判断モジュール５４０は、この要求識別情報に応じて、要求された処理を実行すればよい。一般には、判断モジュール５４０は、プロジェクタ２００ａからの要求に応じて、要求された所定の処理を実行すればよい。ここで、プロジェクタ２００ａによる自発的なデータ送信が可能な場合には、判断モジュール５４０による要求問い合わせを省略してもよい。また、状態チェックモジュール２５０は、ユーザの指示が無い場合であっても、自動的に要求を発行してもよい。例えば、状態チェックモジュール２５０は、定期的に全画面送信要求を発行してもよい。また、ユーザの指示を受け取る入力部２１０（図２）としては、操作ボタンを含む装置に限らず、ユーザによって操作されるリモコンを介して指示を受け取る装置を採用してもよい。
【０１４９】
Ｆ．変形例：
なお、上記各実施例における構成要素の中の、独立クレームでクレームされた要素以外の要素は、付加的な要素であり、適宜省略可能である。また、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
【０１５０】
変形例１：
上述の各実施例において、コンピュータ１００、１００ａによって識別されるプロジェクタ２００、２００ａのデバイス種類としては、「マスストレージクラス」に限らず、汎用デバイスのための種々の種類（クラス）を採用可能である。このような汎用デバイスのためのクラスでは、通信プロトコルが標準化されているので、画像供給装置と画像表示装置との間のデータ通信を容易に行うことができる。また、このようなクラスのドライバは、広く普及している場合が多く、しばしば、ＵＳＢインターフェースを有する種々の装置に予め組み込まれている。従って、専用のドライバをインストールせずに、画像供給装置と画像表示装置とのデータ通信を行うことができる。また、専用ドライバの開発を省略することもできる。これらの結果、画像表示装置を利用するための労力を軽減することが可能となる。
【０１５１】
ここで、コンピュータ１００、１００ａからプロジェクタ２００、２００ａへのデータ転送速度が過剰に遅くならないように設計されたクラスを採用することが好ましい。例えば、「オーディオ（Audio）」と、「マスストレージ（Mass Storage）」と、「コミュニケーションデバイス（Communication Device）」と、の中から任意に選択されたものを採用可能である。
【０１５２】
なお、本発明は、ＵＳＢの将来のバージョンにも適用可能である。また、インターフェースとしては、ＵＳＢに限らず、複数種類の汎用デバイスに任意に接続可能な種々の汎用インターフェースを採用可能である。いずれの場合も、プロジェクタ２００、２００ａ２が汎用デバイスとして識別されることが好ましい。ここで、汎用デバイスとは、インターフェースの標準のプロトコルを利用してデータ通信を行うデバイスを意味している。標準のプロトコルとしては、そのインターフェースの規格団体によって標準化されたものを採用してもよく、また、業界の実質的な標準のものを採用してもよい。
【０１５３】
変形例２：
上記各実施例において、ディスクイメージ２２４（図３、図９）を省略してもよい。この場合には、コンピュータ１００、１００ａで実行されるプログラムを、インターネットや他の記録媒体から取得すればよい。ただし、上記各実施例のようにプロジェクタ２００、２００ａに、コンピュータ１００、１００ａからアクセス可能なデータ記憶部（例えば、ディスクイメージ２２４）を設ければ、データ記憶部に格納された種々のデータをコンピュータ１００、１００ａに提供することができる。この際、表示用データの送信に利用される通信コマンドは、データ記憶装置のための通信プロトコルで利用されるコマンドの内の、データ記憶部のデータリードのためのコマンドとは異なる所定のコマンドであることが好ましい。こうすれば、表示用データの転送と、データ記憶部のリードとを、両立させることができる。
【０１５４】
なお、データ記憶装置のための通信プロトコルで利用されるコマンドの内の、データリードのためのコマンドと、画像転送プログラム５００によって発行されるコマンド（特に、表示用データの送信コマンド）と、のいずれとも異なるコマンド（例えば、ライト（WRITE）コマンド）が発行された場合にプロジェクタ２００、２００ａによって実行される処理としては、任意の処理を採用可能である。例えば、ディスパッチャ２２６が、エラー応答をコンピュータ１００、１００ａに送信してもよい。また、ディスパッチャ２２６が、受信データをＳＣＳＩドライバ２３２に供給することによって、データ管理モジュール２３０に応答させてもよい。
【０１５５】
また、記憶領域に予め格納しておくデータとしては、プロジェクタ２００、２００ａの取扱説明書等の任意のデータを採用可能である。ただし、上記各実施例のように、プロジェクタ２００、２００ａに対して画像データ（表示用データ）を送信する機能をコンピュータ１００、１００ａに実現させるためのプログラムを採用することが好ましい。こうすれば、画像データを送信するためのプログラムを、容易にコンピュータ１００、１００ａに提供することができるので、プロジェクタ２００、２００ａを利用するための労力を軽減することができる。ここで、画像データの送信に利用されるプログラム（モジュール）の内の、記憶領域に格納しておくものとしては、任意に選択されたものを採用可能である。例えば、標準的にコンピュータ１００、１００ａに組み込まれているモジュールについては、省略してもよい。図９、図１２の例で、プロジェクタドライバ１２８が標準的にコンピュータ１００ａに組み込まれている場合には、ディスクイメージ２２４のプロジェクタドライバ１２８を省略してもよい。
【０１５６】
変形例３：
上記各実施例において、変化領域のみをキャプチャする方法としては、図１２〜図１８に示した第３実施例の方法や、図１９に示した第４実施例の方法に限らず、任意の方法を採用可能である。例えば、キャプチャモジュール５１０が、ＶＲＡＭ１１４を監視し続けることによって、変化した領域を検出してもよい。この場合には、キャプチャモジュール５１０は、ＶＲＡＭ１１４から変化領域の画像データを取得すればよい。また、図１７で説明したような最適化処理を省略してもよい。この場合には、キャプチャモジュール５１０は、最適化前の画面更新領域ＴＴＧを包含するような矩形形状の画像をキャプチャすればよい。このように、キャプチャされる画像は、変化した領域よりも大きくてもよい。ただし、画面全体の内の変化した領域を含む一部の画像であることが好ましい。
【０１５７】
また、コンピュータ１００、１００ａからプロジェクタ２００、２００ａへ供給される表示用データとしては、上記実施例で使用したもの以外の種々のものを使用することが可能である。例えば、表示用データとして、少なくとも画像データを含むものを使用することができる。具体的には、例えば、画面全体の画像データを転送する場合には、ヘッダ（変化領域情報）を転送する必要は無い。
【０１５８】
また、表示用データとしては、変化領域（画面更新領域）の位置及びサイズを示す情報と、変化領域内の画像データとを少なくとも含むことが好ましい。この理由は、変化領域に関するデータ（変化領域情報及びその画像データ）のみを転送すれば、転送すべきデータ量が少なくなるからである。
【０１５９】
変形例４：
上記各実施例において、プロジェクタ２００、２００ａによって表示される画面としては、表示デバイス１１８によって表示されている画面に限らず、任意の画面を採用可能である。例えば、コンピュータ１００、１００ａ上で動作している特定のアプリケーションによって描画される画像のみをプロジェクタ２００、２００ａで表示することとしてもよい。この場合には、キャプチャモジュール５１０が、そのアプリケーションによって描画される画像をキャプチャすればよい。
【０１６０】
変形例５：
上記各実施例では、ＳＣＳＩコマンドセットを利用している。従って、プロジェクタ２００、２００ａからコンピュータ１００、１００ａへ種々のデータ（例えば、図１０：Ｓ３７０の状態データや、図２０：Ｓ５２０のコマンドデータ）を送信する場合であっても、データサイズは、ＳＣＳＩのイニシエータに相当するコンピュータ１００、１００ａによって決められる（上記各実施例では所定のサイズに設定されている）。ここで、送信すべきデータのサイズが大きい場合には、データの一部がプロジェクタ２００、２００ａに残る場合がある。このような場合には、コンピュータ１００、１００ａに転送されるデータ内に残存データのサイズを書き込んでおき、コンピュータ１００、１００ａは、残存データの全てを受信するまで、プロジェクタ２００、２００ａにデータを送信させる処理を繰り返し実行すればよい。
【０１６１】
変形例６：
表示用データや状態データ、コマンドデータを転送する通信手順としては、上記各実施例の手順に限らず、種々の手順を採用可能である。例えば、図１４のステップＳ２６で、図８の例と同様に、表示用データを分割して送信してもよい。また、上記各実施例では、データ通信にＳＣＳＩコマンドセットが利用されていたが、データ通信に利用されるコマンドセットとしては、任意のものを採用可能である。また、データ通信の手順としても、採用されたコマンドセットに適した手順を採用すればよい。
【０１６２】
変形例７：
上記実施例では、第２の転送領域ＴＧ２（図１６（Ｃ），図１９（Ｃ））の画像部分をＶＲＡＭ１１４から取得して一旦ＲＡＭ１０６内の画像データ格納領域１０６ｂ内に書き込んだ後で、ＲＡＭ１０６から画面更新領域ＴＴＧの画像を取得してインターフェースを介して転送することとしていたが、画像データ格納領域１０６ｂに書き込む処理を省略することも可能である。但し、上記実施例の手順によれば、インターフェースを介して最終的に画像を転送する際に、画像を１つの画像データ格納領域１０６ｂから取得できるので、処理が単純になるという利点がある。
【０１６３】
変形例８：
上記実施例では、描画モジュールがＧＤＩ１２４とディスプレイドライバ１２６とプロジェクタドライバ１２８の３つのモジュールに分かれていたが、モジュールの区分は任意であり、これらの機能を１つのモジュールにまとめることも可能である。また、ディスプレイドライバ１２６とプロジェクタドライバ１２８の機能を１つのモジュールにまとめることも可能である。
【０１６４】
変形例９：
上記実施例においては、画像供給装置としてパーソナルコンピュータを用いていたが、この代わりに、他の種類のコンピュータ（モバイルコンピュータ、ハンドヘルドコンピュータ、ワークステーションなど）を用いるようにしても良い。また、これらコンピュータの他に、インターフェースを有するとともに、コンピュータと同様な機能を有する機器を用いるようにしても良い。そのような機器には、例えば、情報携帯端末や、携帯電話機や、メール端末や、ゲーム機や、セットトップボックスなどが含まれる。また、画像表示装置としては、プロジェクタ以外の種々の表示装置を使用することが可能である。
【０１６５】
変形例１０：
上記実施例においてソフトウェアで実現されている機能の一部をハードウェアで実現してもよく、あるいは、ハードウェアで実現されている機能の一部をソフトウェアで実現してもよい。
【符号の説明】
【０１６６】
１０…画像表示システム
６０…表示画面
７０…投写表示画面
１００、１００ａ…パーソナルコンピュータ（ＰＣ）
１０２…ＣＰＵ
１０４…ＲＯＭ
１０６…ＲＡＭ
１０６ａ…変化領域情報
１０６ａ１…変化領域情報
１０６ａ２…変化領域情報
１０６ｂ…画像データ格納領域
１０８…ハードディスクドライブ
１１０…入力部
１１２…ＵＳＢインターフェース部
１１４…ＶＲＡＭ
１１６…グラフィックコントローラ
１１８…表示デバイス
１２０…バス
１２２…アプリケーションプログラム
１２４…ＧＤＩ（グラフィックスデバイスインタフェイス）
１２６…ディスプレイドライバ
１２８…プロジェクタドライバ
１３０…ファイルシステムモジュール
１３２…ＳＣＳＩドライバ
１３４…マスストレージドライバ
１３６…ＵＳＢモジュール
２００、２００ａ…プロジェクタ
２０２…ＣＰＵ
２０４…ＲＯＭ
２０６…ＲＡＭ
２１０…入力部
２１２…ＵＳＢインターフェース部
２１４…画像処理部
２１６…投写部
２１８…バス
２２４…ディスクイメージ
２２６…コマンドディスパッチャモジュール
２３０…データ管理モジュール
２３２…ＳＣＳＩドライバ
２３４…マスストレージドライバ
２３６…ＵＳＢモジュール
２４０…画像表示モジュール
２４２…画像展開モジュール
２４４…データ取得モジュール
２５０…状態チェックモジュール
３００…ＵＳＢケーブル
４００…フック処理モジュール
５００、５００ａ…画像転送プログラム
５１０…キャプチャモジュール
５２０…データ生成モジュール
５３０…ＳＣＳＩラッパモジュール
５４０…判断モジュール
【特許請求の範囲】
【請求項１】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置であって、
前記インターフェースを介したデータ通信を制御する通信制御部と、
前記画像データに基づいて画像を表示する画像表示部と、
を備え、
前記通信制御部は、前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信し、
前記通信制御部は、前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する、
画像表示装置。
【請求項２】
請求項１に記載の画像表示装置であって、
前記インターフェースは、ＵＳＢインターフェースであり、
前記識別情報は、マスストレージクラスに設定されている、
画像表示装置。
【請求項３】
請求項２に記載の画像表示装置であって、さらに、
前記画像供給装置がアクセス可能なデータ記憶部を備え、
前記通信制御部は、
（ｉ）前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを受信した場合には、受信したデータを前記データ記憶部に供給し、
（ｉｉ）データリードのための通信コマンドとは異なる所定の通信コマンドを受信した場合には、受信したデータを画像データとして前記画像表示部に供給する、
画像表示装置。
【請求項４】
請求項３に記載の画像表示装置であって、
前記データ記憶部は、前記マスストレージクラスよる通信を利用して前記画像表示装置に前記画像データを送信する機能をコンピュータに実現させるための画像転送プログラムを格納する、
画像表示装置。
【請求項５】
請求項４に記載の画像表示装置であって、
前記画像転送プログラムは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を前記コンピュータに実現させる、
画像表示装置。
【請求項６】
請求項１ないし請求項４のいずれかに記載の画像表示装置であって、
前記画像表示部は、受信済みの画像データによって表示されるべき現行画像の内の一部の領域のみを表す更新画像データを受信した場合に、前記一部の領域のみを更新する、
画像表示装置。
【請求項７】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置の制御方法であって、
前記画像表示装置は、前記画像データに基づいて画像を表示する画像表示部を備え、
前記制御方法は、
（ａ）前記画像表示装置が、前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信する工程と、
（ｂ）前記画像表示装置が、前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する工程と、
を備える、制御方法。
【請求項８】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置を制御する処理をコンピュータに実行させるためのコンピュータプログラムであって、
前記画像表示装置は、前記画像データに基づいて画像を表示する画像表示部を備え、
前記コンピュータプログラムは、
（ａ）前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信する機能と、
（ｂ）前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する機能と、
をコンピュータに実現させるコンピュータプログラム。
【請求項９】
画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させるための画像供給装置であって、
前記画像表示装置が接続されるインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースと、
前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する通信制御部と、
前記通信制御部を制御することによって、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する画像転送処理モジュールと、
を備える、
画像供給装置。
【請求項１０】
請求項９に記載の画像供給装置であって、
前記インターフェースは、ＵＳＢインターフェースであり、
前記通信制御部は、前記画像表示装置のデバイス種類をマスストレージクラスとして識別する、
画像供給装置。
【請求項１１】
請求項１０に記載の画像供給装置であって、
前記画像表示装置は、さらに、前記画像供給装置がアクセス可能なデータ記憶部を備え、
前記画像供給装置は、さらに、
前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを利用することによって、前記データ記憶部に格納されたデータを読み出すデータ読み出しモジュールを備え、
前記画像転送処理モジュールは、データリードのための通信コマンドとは異なる所定の通信コマンドを利用することによって、前記画像データを送信する、
画像供給装置。
【請求項１２】
請求項９ないし請求項１１のいずれかに記載の画像供給装置であって、
前記画像転送処理モジュールは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を有する、
画像供給装置。
【請求項１３】
請求項１２に記載の画像供給装置であって、さらに、
画像の描画命令を発行可能なアプリケーションプログラムと、
前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、
前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、
を備え、
前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し
前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、
前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、
前記画像転送処理モジュールは、
（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、
（ｉｉ）前記第１の変化領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、
（ｉｉｉ）取得した画像部分を、前記第１と第２の変化領域の和である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することを特徴とする画像供給装置。
【請求項１４】
請求項１２に記載の画像供給装置であって、さらに、
画像の描画命令を発行可能なアプリケーションプログラムと、
前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、
前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、
を備え、
前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し
前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、
前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、
前記画像転送処理モジュールは、
（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、
（ｉｉ）前記第２の変化領域のうちで前記第１の変化領域にも含まれる領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、
（ｉｉｉ）取得した画像部分を、前記第２の変化領域と同一である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することを特徴とする画像供給装置。
【請求項１５】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させる方法であって、
（ａ）前記画像供給装置が、前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する工程と、
（ｂ）前記画像供給装置が、前記インターフェースを介して、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する工程と、
を備える、表示方法。
【請求項１６】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させる処理をコンピュータに実行させるためのコンピュータプログラムであって、
（ａ）前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する機能と、
（ｂ）前記インターフェースを介して、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する機能と、
をコンピュータに実現させる、コンピュータプログラム。
【請求項１】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置であって、
前記インターフェースを介したデータ通信を制御する通信制御部と、
前記画像データに基づいて画像を表示する画像表示部と、
を備え、
前記通信制御部は、前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信し、
前記通信制御部は、前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する、
画像表示装置。
【請求項２】
請求項１に記載の画像表示装置であって、
前記インターフェースは、ＵＳＢインターフェースであり、
前記識別情報は、マスストレージクラスに設定されている、
画像表示装置。
【請求項３】
請求項２に記載の画像表示装置であって、さらに、
前記画像供給装置がアクセス可能なデータ記憶部を備え、
前記通信制御部は、
（ｉ）前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを受信した場合には、受信したデータを前記データ記憶部に供給し、
（ｉｉ）データリードのための通信コマンドとは異なる所定の通信コマンドを受信した場合には、受信したデータを画像データとして前記画像表示部に供給する、
画像表示装置。
【請求項４】
請求項３に記載の画像表示装置であって、
前記データ記憶部は、前記マスストレージクラスよる通信を利用して前記画像表示装置に前記画像データを送信する機能をコンピュータに実現させるための画像転送プログラムを格納する、
画像表示装置。
【請求項５】
請求項４に記載の画像表示装置であって、
前記画像転送プログラムは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を前記コンピュータに実現させる、
画像表示装置。
【請求項６】
請求項１ないし請求項４のいずれかに記載の画像表示装置であって、
前記画像表示部は、受信済みの画像データによって表示されるべき現行画像の内の一部の領域のみを表す更新画像データを受信した場合に、前記一部の領域のみを更新する、
画像表示装置。
【請求項７】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置の制御方法であって、
前記画像表示装置は、前記画像データに基づいて画像を表示する画像表示部を備え、
前記制御方法は、
（ａ）前記画像表示装置が、前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信する工程と、
（ｂ）前記画像表示装置が、前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する工程と、
を備える、制御方法。
【請求項８】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、前記画像供給装置から順番に供給される複数の画像データに基づいて、画像を順次表示する画像表示装置を制御する処理をコンピュータに実行させるためのコンピュータプログラムであって、
前記画像表示装置は、前記画像データに基づいて画像を表示する画像表示部を備え、
前記コンピュータプログラムは、
（ａ）前記データ通信の開始のために、前記画像表示装置のデバイス種類を示す識別情報として、画像表示デバイスでない特定の汎用デバイスを示す識別情報を、前記画像供給装置に送信する機能と、
（ｂ）前記汎用デバイスとして前記画像供給装置から前記画像データを受信するとともに、受信した画像データを表示のために前記画像表示部に供給する機能と、
をコンピュータに実現させるコンピュータプログラム。
【請求項９】
画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させるための画像供給装置であって、
前記画像表示装置が接続されるインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースと、
前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する通信制御部と、
前記通信制御部を制御することによって、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する画像転送処理モジュールと、
を備える、
画像供給装置。
【請求項１０】
請求項９に記載の画像供給装置であって、
前記インターフェースは、ＵＳＢインターフェースであり、
前記通信制御部は、前記画像表示装置のデバイス種類をマスストレージクラスとして識別する、
画像供給装置。
【請求項１１】
請求項１０に記載の画像供給装置であって、
前記画像表示装置は、さらに、前記画像供給装置がアクセス可能なデータ記憶部を備え、
前記画像供給装置は、さらに、
前記マスストレージクラスによる通信で利用される通信コマンドであって、データリードのための通信コマンドを利用することによって、前記データ記憶部に格納されたデータを読み出すデータ読み出しモジュールを備え、
前記画像転送処理モジュールは、データリードのための通信コマンドとは異なる所定の通信コマンドを利用することによって、前記画像データを送信する、
画像供給装置。
【請求項１２】
請求項９ないし請求項１１のいずれかに記載の画像供給装置であって、
前記画像転送処理モジュールは、送信済みの画像データによって表示されるべき現行画像の内の一部の領域のみが変化した画像を前記画像表示装置に表示させるために、前記現行画像の内の前記変化した領域を含む一部の領域のみを表す更新画像データを送信する機能を有する、
画像供給装置。
【請求項１３】
請求項１２に記載の画像供給装置であって、さらに、
画像の描画命令を発行可能なアプリケーションプログラムと、
前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、
前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、
を備え、
前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し
前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、
前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、
前記画像転送処理モジュールは、
（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、
（ｉｉ）前記第１の変化領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、
（ｉｉｉ）取得した画像部分を、前記第１と第２の変化領域の和である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することを特徴とする画像供給装置。
【請求項１４】
請求項１２に記載の画像供給装置であって、さらに、
画像の描画命令を発行可能なアプリケーションプログラムと、
前記アプリケーションプログラムによって発行される描画命令を処理するための描画モジュールと、
前記アプリケーションプログラムによって発行される特定の描画命令をフックして先取りし、取得した描画命令に従って汎用メモリ内の特定の転送用画像格納領域に画像を描画するフック処理モジュールと、
を備え、
前記画像転送処理モジュールは、前記転送用画像格納領域から画像を取得するとともに、取得した画像を前記インターフェースを介して前記画像表示装置に転送する機能を有し
前記フック処理モジュールは、前記転送用画像格納領域の中で前記特定の描画命令に応じて画像が描画される領域である第１の変化領域を示す第１の変化領域情報を前記汎用メモリ内に書き込む機能と、前記特定の描画命令を処理した後に当該描画命令を前記描画モジュールに供給する機能とを有し、
前記描画モジュールは、前記アプリケーションプログラム又は前記フック処理モジュールから受けた描画命令に従ってフレームメモリ内に画像を描画する機能と、前記フレームメモリの中で前記描画命令に応じて画像が描画される領域である第２の変化領域を示す第２の変化領域情報を前記汎用メモリ内に書き込む機能とを有し、
前記画像転送処理モジュールは、
（ｉ）前記汎用メモリ内に格納されている前記第１と第２の変化領域情報を参照して、前記第２の変化領域のうちで前記第１の変化領域に含まれない領域に相当する画像部分を前記フレームメモリから取得し、
（ｉｉ）前記第２の変化領域のうちで前記第１の変化領域にも含まれる領域に相当する画像部分を前記フレームメモリから取得することなく前記転送用画像格納領域から取得し、
（ｉｉｉ）取得した画像部分を、前記第２の変化領域と同一である画面更新領域を示す画面更新領域情報とともに前記インターフェースを介して前記画像表示装置に転送することを特徴とする画像供給装置。
【請求項１５】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させる方法であって、
（ａ）前記画像供給装置が、前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する工程と、
（ｂ）前記画像供給装置が、前記インターフェースを介して、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する工程と、
を備える、表示方法。
【請求項１６】
画像供給装置のインターフェースであって複数種類の汎用デバイスに任意に接続可能な汎用インターフェースに接続されるとともに、画像表示デバイスでない特定の汎用デバイスとして画像データを受信する画像表示装置に、順番に複数の画像データを供給して、画像を順次表示させる処理をコンピュータに実行させるためのコンピュータプログラムであって、
（ａ）前記画像表示装置のデバイス種類を前記汎用デバイスとして識別することによって、前記インターフェースを介したデータ通信を制御する機能と、
（ｂ）前記インターフェースを介して、前記表示のための前記画像データを、画像表示デバイスではない前記汎用デバイスとして識別された前記画像表示装置に送信する機能と、
をコンピュータに実現させる、コンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１０−２４４０５８（Ｐ２０１０−２４４０５８Ａ）
【公開日】平成２２年１０月２８日（２０１０．１０．２８）
【国際特許分類】
【出願番号】特願２０１０−１１８１３９（Ｐ２０１０−１１８１３９）
【出願日】平成２２年５月２４日（２０１０．５．２４）
【分割の表示】特願２００６−８５９１３（Ｐ２００６−８５９１３）の分割
【原出願日】平成１８年３月２７日（２００６．３．２７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
【公開日】平成２２年１０月２８日（２０１０．１０．２８）
【国際特許分類】
【出願日】平成２２年５月２４日（２０１０．５．２４）
【分割の表示】特願２００６−８５９１３（Ｐ２００６−８５９１３）の分割
【原出願日】平成１８年３月２７日（２００６．３．２７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
[ Back to top ]