複数車両モジュールの組合せで構成される車両をチェックするための情報処理システムであって、各車両モジュールが認証済のものか否か判定する第1判定手段と、前記複数車両モジュールの組合せについて、認証可能か否かを判定する第2判定手段と、前記複数車両モジュールの組合せについて、認証を受けるために必要な条件を決定する決定手段と、を備えたことを特徴とする情報処理システム。前記第2判定手段は、複数車両モジュールを組み合わせた場合の動作をシミュレートし、シミュレーション結果が所定の基準を満たすか否かを判定することを特徴とする請求項1に記載の情報処理システム。前記決定手段は、前記認証を受けるために必要なプログラムをダウンロードする手段を含むことを特徴とする請求項1又は2に記載の情報処理システム。前記決定手段は、前記認証を受けるための代替車両モジュールを提示する提示手段を含むことを特徴とする請求項1乃至3のいずれか1項に記載の情報処理システム。前記提示手段は、代替となる車両モジュールを記憶した車両モジュールデータベースをさらに備え、該車両モジュールデータベースから、前記認証の基準を満たした代替車両モジュールを検索して、その検索結果を用いて交換対象となる代替車両モジュールを提示することを特徴とする請求項4に記載の情報処理システム。前記複数車両モジュールの組合せについて、認証を受けることのできる範囲内で、いずれかの車両モジュールの制御設定の変更オプションを提示する提示手段をさらに備えたことを特徴とする請求項1乃至5のいずれか1項に記載の情報処理システム。可搬型通信機を更に含み、該可搬型通信機の通信機能を用いて、前記車両モジュールとの通信を行なうことを特徴とする請求項1乃至6のいずれか1項に記載の情報処理システム。請求項1乃至7のいずれか1項に記載の情報処理システムを備えたことを特徴とする車両。複数車両モジュールの組合せで構成される車両のチェック方法であって、各車両モジュールが認証済のものか否か判定する判定ステップと、前記複数車両モジュールの組合せについて、認証可能か否かを判定する判定ステップと、前記複数車両モジュールの組合せについて、認証を受けるために必要な条件を決定する決定ステップと、を含むことを特徴とする車両のチェック方法。複数車両モジュールの組合せで構成される車両のチェックプログラムであって、各車両モジュールが認証済のものか否か判定する判定ステップと、前記複数車両モジュールの組合せについて、認証可能か否かを判定する判定ステップと、前記複数車両モジュールの組合せについて、認証を受けるために必要な条件を決定する決定ステップと、をコンピュータに実行させることを特徴とする車両のチェックプログラム。しかしながら、上述の技術では、認証されていない、又は認証できないモジュールについては、排除の方法をとっており、ユーザは認証されたモジュール以外を使うことができず、モジュール選択の自由度が非常に狭かった。例えば、ユーザが好みの乗り味等を実現しようとする場合に、認証モジュールの組み合わせでは実現できないことがあった。本発明が解決しようとする課題は、上述の問題を解決する技術を提供することにあり、モジュール選択の自由度を増加させることにある。上記課題を解決するための本発明は、複数車両モジュールの組合せで構成される車両をチェックするための情報処理システムであって、各車両モジュールが認証済のものか否か判定する第1判定手段と、前記複数車両モジュールの組合せについて、認証可能か否かを判定する第2判定手段と、前記複数車両モジュールの組合せについて、認証を受けるために必要な条件を決定する決定手段と、を有することを特徴とする。上記目的を達成するため、本発明に係る車両は、上記システムを備えたことを特徴とする。上記課題を解決するための本発明は、複数車両モジュールの組合せで構成される車両のチェック方法であって、各車両モジュールが認証済のものか否か判定する判定ステップと、前記複数車両モジュールの組合せについて、認証可能か否かを判定する判定ステップと、前記複数車両モジュールの組合せについて、認証を受けるために必要な条件を決定する決定ステップと、を有することを特徴とする。上記目的を達成するため、本発明に係るプログラムは、複数車両モジュールの組合せで構成される車両のチェックプログラムであって、各車両モジュールが認証済のものか否か判定する判定ステップと、前記複数車両モジュールの組合せについて、認証可能か否かを判定する判定ステップと、前記複数車両モジュールの組合せについて、認証を受けるために必要な条件を決定する決定ステップと、をコンピュータに実行させることを特徴とする。本発明によれば、より幅広く、車両を構成するモジュールを選択することが可能となる。以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素はあくまで例示であり、本発明の技術範囲をそれらに限定する趣旨のものではない。なお以下の記載で車両とは車輪の数によらず、移動する装置を全て含む概念である。本発明の第1実施形態として、複数の車両モジュールの組合せで構成される車両をチェックするための情報処理システム100について図1を用いて説明する。図1は、情報処理システム100の構成を示すブロック図である。図1において、情報処理システム100は、モジュール判定部110と組合せ判定部120と条件決定部130とを備えている。モジュール判定部110は、車両150を構成する各車両モジュールが認証済のものか否か判定する。また、組合せ判定部120は、複数車両モジュールの組合せについて、認証可能か否かを判定する。さらに、条件決定部130は、複数車両モジュールの組合せについて、認証を得るために必要な条件を決定する。このように、車両モジュール一つ一つの認証を判定するだけではなく、その組合せの適正について判定し、さらには、認証を得るために必要な条件を決定するため、より簡便に車両を構成する車両モジュールを選択することが可能となる。第2実施形態本発明の第2実施形態として、複数車両モジュールの組合せで構成される車両、及びそのチェックを行なう情報処理システムの一例としてのチェックシステムについて図2乃至図11を用いて説明する。本実施形態では、一例として、電気自動車をモジュール化して、ユーザが各車両モジュールを入手して組み立てたり、改造したりする場合を想定している。車両モジュールとしては、駆動系モジュール、制動系モジュール、車体系モジュール、電装系モジュール、冷却系モジュールなどが挙げられるが、これらに限定されるものではなく、1つ以上の部品によって構成される部品ユニットであればどのような切り分けでモジュール化しても良い。[構成]図2は、チェックシステム200の内部構成及び、車両を駆動する車両駆動システム250の内部構成について示している。チェックシステム200は、車両の内部又は外部において、車両駆動システム250と接続されている。チェックシステム200としては、汎用コンピュータを用いることができ、その場合、図のようにCPU201、ROM202、通信制御部203、RAM204及び大容量記憶部205を備える。CPU201は中央処理部であって、様々なプログラムを実行することによりチェックシステム200全体を制御する。ROM202は、リードオンリメモリであり、CPU201が最初に実行すべきブートプログラムの他、各種パラメータ等を記憶している。また、RAM204は、ランダムアクセスメモリであり、大容量記憶部205から読出されたプログラムの展開領域や、そのプログラムによって用いられるデータや導き出されたデータや通信制御部203を介して入力したデータなどの一時保存領域を有している。大容量記憶部205は、様々なデータベース及びプログラムモジュールを記憶している。また、通信制御部203は、車両駆動システム250との通信や、車両認証機関260及び車両モジュールデータセンタ270とのネットワークを介した通信を制御する。一方、車両駆動システム250は、コントロールチップ251と、複数の車両モジュール252とを備えている。これらの車両モジュール252はそれぞれECUElectricalControlUnit:電子制御部を含んでいる。各ECUはネットワークに接続されて相互に通信可能であり、かつコントロールチップ251とも通信可能である。各車両モジュールには、耐タンパ性の認証チップが埋め込まれており、コントロールチップ251が、それぞれの車両モジュールについて、認証済か否かを判定できる仕組みになっている。或いは、車両モジュールのECUにMACアドレスのような一意に決まる認証済IDを持たせてもよい。そのようにすれば部品のトレーサビリティが実現され、部品の盗難を抑止することができる。このようなシステムにおいて、チェックシステム200は、車両駆動システム250と連動し、コントロールチップ251を介して、車両モジュール252を制御する。特に、車両モジュール252のそれぞれについて、認証済の車両モジュールか否か、性能的に問題が無いか判定し、複数の車両モジュールの連動性に問題が無いかをチェックする。さらに、組み合わせて構成された車両として適正な性能を発揮するか否かをチェックする。また、このチェックシステム200は、問題が見つかれば、その問題を解決するためにユーザが取り得る対応策車両モジュールの交換、ドライバソフトウェアのインストール、更新、制御設定の変更などをユーザに対して報知する。図3は、図2のチェックシステム200における大容量記憶部205の内部構成を示す図である。図3に示すように、大容量記憶部205は、車両認証に関して、車両認証プログラム300、車両認証用データベース310、車両認証結果データ320を記憶している。またさらに、大容量記憶部205は、認証取得方法決定プログラム330、車両モジュールデータベース340、提案提示プログラム350、ソフトウェアパッチダウンロードプログラム360を保存している。図4は、コントロールチップ251の構成を示す図である。コントロールチップ251は、CPU401、ROM402及び記憶部403を含む。記憶部403には、統合制御プログラム431の他、車両モジュール情報432が記憶されている。車両モジュール情報432としては、車両モジュールごとに、認証済か否か対応ECUが認証コードを保有しているかを示すフラグの他、製造年月日、製造元などの製造情報が登録されている。またさらに、各車両モジュールの寸法情報、性能情報、ドライバプログラム、制御パラメータ等が記憶されている。CPU401は統合制御プログラム431を実行することにより、これらの車両モジュール情報432を用いて、複数の車両モジュールを統合的に制御する。図5は、車両認証用データベース310における制御設定変更テーブル313の構成を示す図である。図5の501に示されているように、制動距離に若干の問題がある場合基準値との差が一定値以内の場合には、ブレーキ又はモータの制御を変更するように対応する。たとえば、モータの出力を制限したり、ブレーキのレスポンスを早めたりすることが考えられる。具体的には、通信制御部203を介して、車両モジュールデータセンタ270からソフトウェアパッチをダウンロードして、モータやブレーキのドライバプログラムそのものを更新したり、ドライバプログラムの設定値を変更したりして対応できる。一方、制動距離も発熱量も共に一定値以上基準から乖離している場合には、ソフトウェア更新や制御設定変更では対応できないため、ブレーキモジュール等の変更をユーザに提案する。[処理の流れ]図6は、車両モジュール変更時のシステム全体における処理の流れを説明する図である。車両モジュール変更が行なわれるとS601、変更があった車両モジュールのECUは、車両モジュール情報をコントロールチップ251に送信するS602。あるいは、コントロールチップ251は、全車両モジュールを監視しており、車両モジュール変更があった場合に新しい車両モジュールに対して車両モジュール情報を要求し、取得する。コントロールチップ251は、取得した車両モジュール情報を記憶部403に登録しS603、チェックシステム200に対して新たな車両モジュールのチェックを依頼するS604。チェックシステム200は、適宜、車両認証機関260に対して認証基準を要求しS605、車両認証機関260から認証基準をダウンロードしてS606、車両認証基準データベース312に登録しておく。なお、ここでは、外部の車両認証機関260に問い合わせる例を示すが本発明はこれに限定されるものではなく、大容量記憶部205内の車両認証基準データベース312を参照しても良い。次に、ステップS607において、チェックシステム200のCPU201が車両認証プログラム300のシミュレーションサブルーチン301を実行することにより、新しい車両モジュール組合せにおけるシミュレーションを行なう。このシミュレーションでは、車両認証用データベース310に記憶されている車両シミュレーション用パラメータ311を用いる。たとえば、新しい車両モジュールがバッテリの場合には、実際にモータを所定の回転数で回転させて、その出力や発熱量、発生ノイズなどをチェックする。この時、タイヤは回転させても、回転させなくても良い。あるいは、新しい車両モジュールがオーディオの場合には、そのオーディオを起動して、消費電力や発熱量、発生ノイズなどをチェックする。それらのチェック項目は全て、車両認証基準データベース312に用意されているものとする。なお、ステップS603において登録された車両モジュール情報の信頼性が高く、新たに導入された車両モジュールについて十分なデータが揃っている場合には、各車両モジュール単体について用意された動作モデルを用いてソフト的にシミュレーションを行なっても良い。また、新たに導入された車両モジュールが認証済であって、その動作及び他の車両モジュールとの連動性に問題が無いと確認済であれば、シミュレーションを行なわずに、使用を許可しても良い。その場合、図3の車両認証基準データベース312に、認証済の車両モジュール組合せが複数登録されており、その組合せのいずれかと一致した場合にはシミュレーションを行なわずに車両認証可との結果をコントロールチップ251に返答する。続けて、チェックシステム200のCPU201が認証サブルーチン302を実行することにより、シミュレーション結果としての数値を車両認証基準312に記憶された基準値と比較する。そして、その結果が、図3の車両シミュレーション結果321として記憶される。図3では、制動距離、発熱量、電力消費量、電気的ノイズをチェック項目としてあげているが、本発明はこれらに限定されるものではなく他の項目をチェックしても良い。ステップS608では、シミュレーションの結果をユーザに提示する。この時、認証基準を満たさなかった項目については、認証取得方法決定プログラムが、図5に示した制御設定変更テーブル313を参照してどのような解決方法があるかを決定し、提案提示プログラム330が、その提案を提示する。ソフトウェアパッチたとえば最新ドライバのダウンロードによって解決できる場合には、ソフトウェアパッチダウンドーロプログラム360がユーザからの指示に応じて、車両モジュールデータセンタ270などのからソフトウェアパッチをダウンロードする。一方、車両モジュールそのものの交換が必要な場合には、ユーザの指示に応じて、チェックシステム200が保有する車両モジュールデータベース340から、認証を受けるために交換対象となる代替車両モジュールを検索して、そのリストを提供する。場合によっては、通信制御部203が車両モジュールデータセンタ270から、基準に適合する代替車両モジュールのリストをダウンロードする。この時、チェックシステム200は、ユーザが、どのような走り、どのような車両を求めているかに応じて異なる代替車両モジュールを提案してもよい。なお、ここで提示とは、車内モニタへの表示や、音声での通知など、ユーザに対して情報を提供する全ての態様を含む概念である。ステップS609では、認証結果を車両認証可否データ322として大容量記憶部205に保存し、さらに、コントロールチップ251に送信する。ダウンロードしたソフトウェアパッチがある場合には、そのソフトウェアパッチをコントロールチップ251に送信する。コントロールチップ251では、送信されたソフトウェアパッチによって、統合制御プログラム431や、各車両モジュールのドライバを更新する。又は、認証OKの場合には、認証コードを新たに導入された車両モジュールに送信するS610。図7は、チェックシステム200のCPU201が行なう処理の流れを説明するフローチャートである。まず、ステップS701として、コントロールチップ251を介して車両モジュールについて、車両モジュール情報432を取得する。新たに導入された車両モジュールに加えて、全車両モジュールについての情報を取得しても良い。次に、ステップS703において、各車両モジュールの認証をチェックし、未認証の車両モジュールがあるか否か判定する。未認証の車両モジュールが無い場合には、その車両を構成する複数車両モジュールの組合せについて認証済か否かを判定するS717。車両メーカーが推奨する車両モジュールを導入した場合など、すでに車両モジュールの組合せについても問題なく走行できることが確認されている場合には、ステップS719に進み、その旨をコントロールチップ251に報告する。未認証の車両モジュールがある場合、又は、車両モジュール単体として認証済でも、他の車両モジュールとの組合せについては未認証の場合には、ステップS705に進み、シミュレーションを実行し、車両シミュレーション結果321として蓄積する。そして、ステップS707において、車両シミュレーション結果321と車両認証基準データベース312とを比較し、基準を満たしているか判定する。ステップS709においては、車両シミュレーション結果321と全認証基準との比較が完了したか判定する。全認証基準との比較が完了するまでステップS707を繰り返し、全認証基準との比較が完了すれば、ステップS711に進んで、車両全体として認証OKか否か判定する。その結果、車両全体として認証OKの場合にはステップS711からステップS719に進み、その旨をコントロールチップ251に報告する。いくつかの項目について認証をクリアできなかった場合には、ステップS713において、その結果をユーザに提示し、さらに、認証をクリアするための、制御設定、代替車両モジュール、ソフトウェアパッチの存在などを報知する。設定やソフトウェアの変更で対応できる場合にはステップS715において、ユーザからの指示に基づき、制御設定を変更し、ソフトウェアのアップデートを行なう。たとえば、チェック結果表示画面の一例を図9~図12に示す。図9のチェック結果表示画面901では、モータの発熱量、バッテリの発熱量、冷却器容量などが数値で示され、全体として問題が無いことがメッセージ表示されている。一方、図10のチェック結果表示画面1001では、バッテリ性能のチェック結果を評価する指標として、モータの消費電力や、最大連続走行時間などが表示されている。ここでは、最大連続走行時間が30分と短く、基準値を満たしていないことがアナウンスされている。さらに、解決方法としてバッテリ又はモータの交換を提案している。バッテリリストボタン1002又はモータリストボタン1003がクリックされると、チェックシステム200は、内部の車両モジュールデータベース340又は、外部の車両モジュールデータセンタ270から代替となるバッテリ及びモータを検索して表示する。具体的には、この場合、消費電力の小さなモータ又は容量の大きなバッテリを検索し、表示する。図11のチェック結果表示画面1101では、ブレーキ性能のチェック結果を表示している。ここでは、ブレーキ性能に関連する要素として、車重や制動距離を示しており、制動距離が基準を満たしていないため、ブレーキ制御プログラムの更新を行なうように促すメッセージを表示している。更新ボタン1102をクリックすれば、ブレーキ制御プログラムの更新処理が開始される。その他、車重が軽くなるように車両モジュールの交換を促すメッセージを表示しても良い。さらには、走行性能を制限するたとえば最高速度を制限するソフトウェアのダウンロードを促すメッセージを表示しても良い。図12のチェック結果表示画面1201では、車両モジュールから発生するノイズのチェック結果を表示している。ここでは、発生ノイズに問題が無い旨のメッセージを表示している。図8は、車両の走行開始時にコントロールチップ251のCPU401が統合制御プログラム431を実行して行なう処理の流れを説明するフローチャートである。ステップS801において、キー情報たとえば電子免許証に保存された情報を受信すると、ステップS803において、車両全体としてチェックシステム200による認証が完了しているか否か判定する。次に、ステップS809において、電子免許証などの内容と照らし合わせて、その運転者による、その車両の運転を許可すべきか否かを判定する。たとえば、モータ出力などが、ユーザの運転資格の範囲内にあるかを判断する。運転を許可できると判断した場合には、ステップS811に進み、走行開始する。運転を許可できない場合には、ステップS813に進んで車両の走行を不可として、ユーザに対してその理由を提示する。以上のように、本実施形態によれば、車両モジュール一つ一つの認証を判定し、更にはその組合せの適正について判定し、さらには、認証を得るために必要な条件を決定するため、より簡便に車両を構成する車両モジュールを選択することが可能となる。なお、上記実施形態では、認証基準を満たさない車両モジュールが存在する場合に、ソフトウェアのダウンロードやハードの交換等をユーザに提案しているが、基準を満たす場合に、他の変更オプションを示してもよい。たとえば、現在の車両モジュール組合せに対して適応可能なパラメータセットをダウンロードして車両の乗り味等のカスタマイズを行うといった変形が考えられる。第3実施形態本発明の第3実施形態について、図13を用いて説明する。図13は、モジュール組合せと、カスタマイズデータとの組合せテーブル1300を示す図である。本実施形態に係る情報処理システムでは、乗ったときのシートの位置の移動範囲や、内装色や、運転動作音や、走行モードなど、ユーザによるカスタマイズの幅が、車両モジュール組合せ毎に予め設定されている。従って、車両モジュールを変更して、車両モジュール組合せが変わると、その車両において調整できるシート位置や、内装色や運転動作音や走行モードなどが変わることになる。その他の構成及び動作については上述の第2実施形態と同様であるため、ここでは説明を省略する。図13に示すテーブル1300中、例えば車両モジュール組合せ1では、シート位置がaaa~bbbの間で移動可能、車両モジュール組合せ2では、シート位置がccc~dddの間で移動可能、車両モジュール組合せ3では、シート位置がeee~fffの間で移動可能となる。硬いサスペンションを含む車両モジュール組合せであれば、ロールを小さくするべく、シート位置を低めに調整できるように、カスタマイズ幅が用意されている。同様に、内装色や、車両運転音なども車両モジュール組合せごとに用意されている。更に、車両モジュール組合せ1では、燃費重視モード、走り重視モードの何れかの走行モードを選択可能であるが、車両モジュール組合せ2、3では、そのような選択はできないように設定されている。以上のように、車両モジュール組合せごとにカスタマイズ幅が設定されているので、ユーザは、そのようなカスタマイズ幅を踏まえて車両モジュール組合せひいては車両モジュール自体を選択することができる。第4実施形態本発明の第4実施形態について、図14を用いて説明する。本実施形態では、部品の動作状況をモニタリングして劣化のトレンドを検出する。図14は、本実施形態に係る情報処理システムでの処理の流れを説明するためのフローチャートである。一部の処理は図8のフローチャートを同様であるため、同じ処理については同じ符号を付してその説明を省略する。動作部品は長期間の使用に対して経年劣化することが考えられる。そこで、ステップS803における車両の認証が済んで、ステップS1400で走行を開始すると、ステップS1401に進んで走行ログを蓄積する。次に、走行開始からの経過時間を測定し、所定時間が経過すれば、ステップS1402からステップS1403に進んで、所定回数の認証処理を終了したか判定する。例えば、既にその車両モジュール組合せについて5回の認証が済んでいるのであれば、その車両モジュール組合せに問題ないとして、処理を終了する。このとき、走行に問題のない車両モジュール組合せとして、車両モジュール組合せ340等に登録しても良い。そのようにして、その後同じ組合せを選択する他の運転者に対して、相当数の実走後認証が完了した組合せとして紹介することができる。一方、ステップS1403において、所定回数の認証処理が終了していれば、ステップS1404に進み、走行ログを用いて認証処理をおこなう。ステップS809に戻り、その結果に応じて、運転を許可すべきか否かを改めて判定する。また、経年劣化はシミュレーションに用いた動作モデル初期性能と実際の動作状況を比較して差異の大きさにより検出することも可能である。短期的には動作環境の変化によって動作状況に差異が生じることはありうるが、長期間の動作をモニタリングして2乗平均などの計算手法により全体的な傾向を導出すればより正確な劣化の程度を測定することができる。現在の動作状況と動作モデル初期性能との差異が、予め決められた一定の範囲を超えたこと、あるいはグラフの傾きなどから超えることが予想されることを検出する。そして、現在の動作状況が、予め決められた範囲たとえば初期性能の10落ちなどを超えた部品、あるいは超えることが予想される部品の交換時期をモニタに表示することで利用者に知らせる。また、現在の動作状況が予め決められた範囲たとえば初期性能の10落ちに収まるようにモジュールの動作を制御する。バイワイヤーでの制御が前提である。たとえば、ブレーキの劣化に対しては、ブレーキペダルの踏力と制動距離を一定にする制御を行う。本実施形態は、ブレーキペダル、ペダルの踏力を電気信号に変換する装置、該電気信号をブレーキパッドの締め付け強度に変化する装置、ブレーキ本体、車速感知システム一般的なスピード検知でよいで構成するシステムで実施することができる。一定の踏力であれば、ブレーキが劣化すれば制動距離は伸びるが、踏力に対するブレーキの強さを調整することで、劣化による制動距離の変化を相殺する。ペダルの踏力を電気信号に変換する装置、あるいはその電気信号をブレーキパッドの締め付け強度に変化する装置において、踏力に対するブレーキパッドの締め付け強度の変換係数を変化させることで、制動距離を調整して一定の範囲に収まるようにする。制動距離の計測はブレーキ操作の時点からの車速と制動時間から計算する。以上のように、走行中のログを用いて再度認証を行なったり制御を変化させたりすることにより、より確実に条件を満たした車両を走行させることができる。第5実施形態本発明の第5実施形態について、図15を用いて説明する。図2に示した第2実施形態では、チェックシステム200の通信制御部203が、直接、車両認証機関260や車両モジュールデータセンタ270と通信をしている形態となっていたが、本実施形態に係るチェックシステム1500では、通信制御部203が携帯電話などの通信機1501を介して外部と通信する。すなわち、本実施形態のチェックシステム1500は、携帯電話やPDAなどの可搬型通信機を含み、その通信機と車両とが無線あるいは有線にて接続されることにより両者間の通信を実現する。以上の構成により、車両内に外部装置との通信機能が存在しない場合にでも、可搬型通信機を用いて、チェックシステム1500を実現することができる。他の実施形態以上、本発明の実施形態について詳述したが、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステム又は装置も、本発明の範疇に含まれる。また、本発明は、複数の機器から構成されるシステムに適用しても良いし、単体の装置に適用しても良い。さらに、本発明は、実施形態の機能を実現する車両のチェックプログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるWWWサーバも、本発明の範疇に含まれる。この出願は、2010年9月27日に出願された日本出願特願2010-216252を基礎とする優先権を主張し、その開示の全てをここに取り込む。