"受信したデータに対して処理を実行する情報処理装置であって、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段と、を備えることを特徴とする情報処理装置。前記通知手段により前記管理者に対して通知をする時刻の設定を受け付ける通知時刻受付手段をさらに備え、前記判定手段は、さらに、前記通知時刻受付手段で受け付けた時刻までに前記データの処理が実行されたか否かを判定し、前記判定手段により、前記通知時刻受付手段で受け付けた時刻までに前記データの処理が実行されたと判定された場合、前記通知手段は、当該データの処理が遅延している旨の通知はしないことを特徴とする請求項1に記載の情報処理装置。前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知するための電子メールを記憶する通知メール記憶手段をさらに備え、前記通知手段は、前記通知メール記憶手段を、前記通知時刻時受付手段で受け付けた時刻に前記管理者に対して送信することを特徴とする請求項2に記載の情報処理装置。前記通知メール記憶手段に記憶された電子メールのうち、前記判定手段により前記通知時刻受付手段で受け付けた時刻までに処理が実行されたと判定されたデータにかかる遅延通知メールを削除する通知メール削除手段をさらに備えることを特徴とする請求項3に記載の情報処理装置。前記通知手段は、前記管理者に対する遅延通知が複数ある場合、当該通知をひとつの通知として当該管理者に通知することを特徴とする請求項1に記載の情報処理装置。受信したデータに対して処理を実行する情報処理装置における情報処理方法であって、前記情報処理装置の監視スケジュール設定受付手段が、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付工程と、前記情報処理装置の判定手段が、前記監視スケジュール設定受付工程により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定工程と、前記情報処理装置の通知手段が、前記判定工程により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知工程と、を備えることを特徴とする情報処理方法。受信したデータに対して処理を実行する情報処理装置において実行されるプログラムであって、前記情報処理装置を、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段として機能させることを特徴とするプログラム。上記特許文献1のシステムでは、着信待機時間と遅延監視時間が同一の設定となっている。すなわち、着信受信を待機している時間内にデータを受信できなければ、処理が遅延していると判断される。しかし、着信待機時間と遅延監視時間は必ずしも一致しないケースが存在する。例えば、24時間、常に着信を待機しているが、所定の時間帯に着信ができなければ通知をしたいといった場合である。このような場合、特許文献1のシステムでは、着信待機時間と遅延監視時間が同一であることから対応できず、ユーザの要望に沿えないことがある。また、特許文献1では、遅延監視時間内に処理が完了していない場合には通知がされることになる。しかし、遅延監視時間内に処理が完了していなくても、監視時間内に処理が開始され、遅延通知がされるまでの間に処理が完了しているという場合には、遅延とみなさず正常扱いとしたいケースも存在する。さらに、特許文献1のシステムでは、ひとつひとつのジョブデータ交換ごとに遅延した旨の通知がなされてしまい、大量のジョブを処理するシステムにおいては、大量の通知がなされることもあり、業務が煩雑となってしまう。そこで、上記課題を解決するべく、本発明は、EDIシステムにおいて、より業務に則したデータ交換処理の監視機能を提供することを目的とする。本発明は、受信したデータに対して処理を実行する情報処理装置であって、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段と、を備えることを特徴とする。また、本発明は、受信したデータに対して処理を実行する情報処理装置における情報処理方法であって、前記情報処理装置の監視スケジュール設定受付手段が、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付工程と、前記情報処理装置の判定手段が、前記監視スケジュール設定受付工程により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定工程と、前記情報処理装置の通知手段が、前記判定工程により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知工程と、を備えることを特徴とする。また、本発明は、受信したデータに対して処理を実行する情報処理装置において実行されるプログラムであって、前記情報処理装置を、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段として機能させることを特徴とする。本発明によれば、EDIシステムにおいて、より業務に則したデータ交換処理の監視機能を提供することが可能となる。以下、図面を参照して本発明の実施形態を詳細に説明する。図1は、EDIサーバ100、1つのメールサーバ101がローカルエリアネットワークLANを介して接続される構成となっている。また、EDIサーバ100と、1又は複数の接続先取引先側EDIシステム102が公衆回線専用線インターネットなどのネットワークを介して接続される構成となっている。EDIサーバ100は、各種テーブル後述する図8~11に示すを記憶し、接続先側EDIシステム102とファイル転送処理データ交換処理を行う。その結果、ファイル転送処理に遅延が発生した場合、メールサーバ101に対してメール送信を要求する。送信されたメールは、事前に登録したメールアドレスへ送信され、遅延が発生したことを担当者が検知できる仕組みである。具体的には、事前に登録されたファイル転送監視スケジュール状況テーブル図8をもとに、ファイル転送に遅延がないかを監視する。もし、遅延がある場合は、メールサーバ101に対して、遅延通知メールを送信する。またメール通知は、即時通知とまとめ通知の2種類が用意されているものとする。まとめ通知を選択していた際は、メール通知までの間に通信が実行された場合に、遅延通知メールを送信しないようにステータスを更新するといった制御が可能である。なおEDIサーバ100は本発明における情報処理装置の適用例となる構成である。メールサーバ101は、メール送信を行うためのSMTPサーバ機能を搭載したサーバである。接続先側EDIシステム102は、EDI通信プロトコルを搭載したサーバである。EDIサーバ100や、その他のEDIシステムと接続し、ファイル転送を行うことができる。以下、図2を用いて、図1に示したEDIサーバ100,メールサーバ101、接続先EDIシステム102に適用可能な情報処理装置のハードウェア構成について説明する。図2は、図1に示したEDIサーバ100、メールサーバ101、接続先EDIシステム102に適用可能な情報処理装置のハードウェア構成を示すブロック図である。図2において、201はCPUで、システムバス204に接続される各デバイスやコントローラを統括的に制御する。また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるBIOSBasicInput/OutputSystemやオペレーティングシステムプログラム以下、OSや、各サーバ或いは各PCの実行する機能を実現するために必要な各種プログラム等が記憶されている。202はRAMで、CPU201の主メモリ、ワークエリア等として機能する。CPU201は、処理の実行に際して必要なプログラム等をROM203あるいは外部メモリ211からRAM202にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。また、205は入力コントローラで、入力装置209等からの入力を制御する。206はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置210への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、CRTディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。207はメモリコントローラで、ブートプログラム,各種のアプリケーション,フォントデータ,ユーザファイル,編集ファイル,各種データ等を記憶するハードディスクHDや、フレキシブルディスクFD、或いはPCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ登録商標メモリ等の外部メモリ211へのアクセスを制御する。208は通信I/Fコントローラで、ネットワーク例えば、図1に示したLAN400を介して外部機器と接続通信するものであり、ネットワークでの通信制御処理を実行する。例えば、TCP/IPを用いた通信等が可能である。なお、CPU201は、例えばRAM202内の表示情報用領域へアウトラインフォントの展開ラスタライズ処理を実行することにより、ディスプレイ装置210上での表示を可能としている。また、CPU201は、ディスプレイ装置210上の不図示のマウスカーソル等でのユーザ指示を可能とする。ハードウエア上で動作する各種プログラムは、外部メモリ211に記録されており、必要に応じてRAM202にロードされることによりCPU201によって実行されるものである。なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。図3は、本発明の実施例におけるEDIサーバ100の機能構成の一例を示すブロック図である。監視スケジュール設定受付部301は、図12に示す設定画面を介して、転送ファイル毎に監視スケジュールの設定を受け付ける。判定部302は、監視スケジュール設定受付部301で受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する。また、通知時刻受付部304で受け付けた通知時刻までに当該データの処理が実行されたか否かを判定する。通知部303は、判定部302により監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、当該実行されなかった旨処理が遅延している旨を管理者に通知する。通知時刻受付部304は、通知部303により管理者に対して処理が実行されなかった旨を通知する時刻を管理者ごとに受け付ける。受け付けた結果が図9に示すメール通知実行スケジュール状況テーブルに登録される。通知メール記憶部305は、図11に示す通知メール状況テーブルを記憶する。すなわち、判定部により監視スケジュールで特定される時間内にデータ処理が実行されなかったと判定されたデータに関して、処理が遅延している旨を通知するメールを記憶する。通知メール削除部306は、図11のテーブルに登録された通知メールのうち、判定部302で通知時刻までにデータの処理が実行されたと判定された場合、当該データにかかる通知メールを削除する削除済みにステータスを更新する。次に、図4を用いて、本発明の実施形態においてEDIサーバ100が実行する遅延通知処理について説明する。なお、図4のフローチャートで示す処理については、EDIサーバ100のCPU201が所定の制御プログラムを読み出して実行する処理である。ステップS401では、EDIサーバ100のCPU201は、遅延監視処理を実行する。遅延監視処理は、ファイル転送処理において遅延が発生したことを検知し、遅延通知メールを登録する処理である。詳細については、図5のフローチャートを用いて後述する。ステップS402では、EDIサーバ100のCPU201は、遅延通知メールステップS401で登録されたメールの消し込み処理を実行する。消し込み処理は、ファイル転送処理自体は遅延していたが、遅延通知メールを送信するまでの間に処理が実行された場合に、当該処理にかかる遅延通知メールを削除する処理である。本処理の詳細については、図6のフローチャートを用いて後述する。ステップS403では、EDIサーバ100のCPU201は、遅延通知メールの送信処理を実行する。ステップS401で登録されたメールを送信する処理であり、本処理の詳細については、図7のフローチャートを用いて後述する。次に図5を用いて、本発明の実施形態においてEDIサーバ100が実行する遅延監視処理について説明する。なお図5のフローチャートで示す処理は、図4のステップS401の処理の詳細であり、EDIサーバ100のCPU201が所定の制御プログラムを読み出して実行する処理である。ステップS501では、EDIサーバ100のCPU201は、遅延監視状態に遷移すべき情報があるか否か、すなわち監視開始時刻が到来したレコードがあるか否かを判断する。具体的には、ファイル転送監視スケジュール状況テーブル図8から、ステータスが監視待ちであり監視開始時刻がEDIサーバ100のシステム時刻を経過したレコードを検索する。検索の結果当該レコードが存在した場合は、遅延監視状態に遷移すべき情報があると判断される。遅延監視状態に遷移すべき情報があると判断された場合ステップS501:YESは、処理をステップS502に移行する。遅延監視状態に遷移すべき情報がないと判断された場合ステップS501:NOは、処理をステップS503に移行する。ステップS502では、EDIサーバ100のCPU201は、ステップS501で検索されたレコードのステータスを監視中1に変更する。監視中1とは、当該レコードの監視開始時刻から監視終了時刻の間であり、通信処理が実行されていない状態を示す。ステップS503では、EDIサーバ100のCPU201は、遅延完了状態に遷移すべき情報があるか否か、すなわち通信処理が実行されないまま監視終了時刻が到来したレコードがあるか否かを判断する。具体的には、ファイル転送監視スケジュール状況テーブル図8から、ステータスが監視中1であり、監視終了時刻がEDIサーバ100のシステム時刻を経過したレコードを検索する。検索の結果、当該レコードが存在した場合は、遅延完了状態に遷移すべき情報が存在すると判断される。遅延完了状態に遷移すべき情報が存在すると判断された場合ステップS503:YESは、処理をステップS504に移行する。遅延完了状態に遷移すべき情報が存在しないと判断された場合ステップS503:NOは、処理をステップS507に移行する。ステップS504では、EDIサーバ100のCPU201は、ステップS503で検索されたレコードを遅延通知が必要な情報とみなし監視中である通信処理が実行されていないのに、監視終了時刻が到来したため、通知メール状況テーブル図11に当該レコードを追加する。この際、ユーザマスタテーブル図10に登録されたユーザすべてに対して遅延通知をするため、ユーザマスタテーブルに登録されたユーザ分のレコードを追加する。また、ステータスは通知待ちとする。ステップS505では、EDIサーバ100のCPU201は、ステップS503で検索され抽出されたレコードの遅延判定が終了時の場合は、ステップS508へ処理を移行する。他方、遅延判定が開始時延長の場合は、処理をステップS506へ移行する。なお、遅延判定が終了時とは、監視終了時刻が到来した時点で通信処理が終了完了していない場合には遅延と判定することを意味する。また、遅延判定が開始時延長とは、監視終了時刻が到来した時点で通信処理が終了完了していなくても、遅延している旨のメールを送信するまでの間に処理が開始されていれば、遅延とは判定されないことを意味する。このような判定の仕方を採用することで、遅延監視時刻が到来したあとであっても、遅延を通知するメールが送信されるまでの間に処理がなされた場合には、遅延している旨のメールを送信せずに済ませることが可能となる。ステップS506では、EDIサーバ100のCPU201は、ステップS503で抽出されたレコードのうち、遅延判定が開始時延長のレコードのステータスを監視中2に更新する。これにより、監視中2のステータス時にファイル転送が正常終了した場合、未通知の遅延通知メールを消し込むことが可能となる。なお、監視中2とは、監視終了時刻からメール通知までの間における監視をしている状態を示すステータスである。ステップS507では、EDIサーバ100のCPU201は、遅延完了状態に遷移すべき情報、すなわち監視終了時刻が到来しているのに未通信のレコードがあるか否かを判断する。具体的には、ファイル転送監視スケジュール状況テーブルからステータスが監視中2であり通信ステータスが未通信のレコードを検索し抽出する。レコードが抽出された場合、すなわち遅延完了状態に遷移すべき情報がある場合ステップS507:YESは処理をステップS508に移行する。レコードが抽出されなかった場合、すなわち遅延完了状態に遷移すべき情報がない場合ステップS507:NOは、処理をステップS510へ移行する。ステップS508では、EDIサーバ100のCPU201は、遅延状態を確定するために、ステップS505またはステップS507で抽出されたレコードに対して、遅延結果を遅延ありに更新する。ここで、遅延結果が遅延ありとは、監視終了時刻までにファイル転送処理が実行されなかったことを意味する。ステップS509では、EDIサーバ100のCPU201は、ステップS508で遅延結果を更新したレコードについて、ステータスを監視済みに更新する。なお、ステータスが監視中2であるレコードについては、ステータスの更新は行わない。ステップS510では、EDIサーバ100のCPU201は、ユーザからの遅延監視終了要求があるか否かを判断する。遅延監視終了要求があった場合は、本フローチャートに示す処理を終了する。遅延監視終了要求がない場合は、処理をステップS501に戻し、本フローチャートの処理を繰り返す。次に、図6を用いて、本発明の実施形態においてEDIサーバ100が実行する通信処理について説明する。なお、図6のフローチャートで示す処理は、図4のステップS402に該当する処理であり、EDIサーバ100のCPU201が所定の制御プログラムを読み出して実行する処理である。ステップS601では、EDIサーバ100のCPU201は、ファイル転送監視スケジュール状況テーブルの処理対象レコードの通信ステータスを通信中に更新する。ステップS602では、EDIサーバ100のCPU201は、処理対象レコードにかかる転送ファイルについて、ファイル転送処理を実行する。ステップS603では、EDIサーバ100のCPU201は、ステップS602の処理の結果、通信結果が正常であったか否かを判断する。正常であった場合ステップS603:YESは、処理をステップS604へ移行する。正常ではない場合はステップS603:NOは、処理をステップS609に移行する。ステップS604では、EDIサーバ100のCPU201は、ファイル転送監視スケジュール状況テーブルのレコードから、処理対象のレコードであり、ステータスが監視中1または監視中2のレコードを検索する。ステップS604における検索の結果、該当するレコードが存在する場合ステップS604:YESは、処理をステップS605に移行する。ステップS604における検索の結果、該当するレコードが存在しない場合ステップS604:NOは、処理をステップS609に移行する。ステップS605では、EDIサーバ100のCPU201は、ステップS604で検索されたレコードに対して、遅延結果を遅延なしに更新する。ステップS606では、EDIサーバ100のCPU201は、ステップS604で検索されたレコードに対して、ステータスを監視済みに更新する。ステップS607では、EDIサーバ100のCPU201は、通知メール状況テーブル図11からステップS604で検索されたレコードと関連するレコードであり、ステータスが通知待ちのレコードを検索する。ステップS607における検索の結果、該当するレコードが存在する場合ステップS607:YESは、処理をステップS608に移行する。ステップS607における検索の結果、該当するレコードが存在しない場合ステップS607:NOは、処理をステップS609に移行する。ステップS608では、EDIサーバ100のCPU201は、ステップS607で検索されたレコードのステータスを削除済みに更新する。これにより、ステータスが監視中2であるときにファイル転送処理が実行されたレコードについては、遅延通知のメールを送信しないことが可能となる。ステップS609では、EDIサーバ100のCPU201は、ステップS601で変更したステータスを戻すために、ファイル転送監視スケジュール状況テーブルの通信ステータスを未通信に更新する。次に、図7を用いて、本発明の実施形態においてEDIサーバ100が実行するメール送信処理について説明する。なお図7のフローチャートで示す処理は、図4のステップS403に示す処理であり、EDIサーバ100のCPU201が所定の制御プログラムを読み出して実行する処理である。ステップS701では、EDIサーバ100のCPU201は、メールのまとめ通知を実施するために、ユーザマスタテーブル図10でまとめ通知ありのユーザのうち、メール通知実行スケジュール状況テーブル図9から、ステータスが実行待ちであり、メール通知時刻がEDIサーバ100のシステム時刻を経過したれレコードを検索する。すなわち、まとめメール通知すべきユーザがいるか否かを判断する。ステップS701の検索の結果、該当するレコードが抽出された存在した場合ステップS701:YESは、処理をステップS702に移行する。ステップS701の検索の結果、該当するレコードが抽出されなかった存在しなかった場合ステップS701:NOは、処理をステップS705に移行する。ステップS702では、EDIサーバ100のCPU201は、通知メール状況テーブル図11のレコードのうち、ステップS701で抽出されたレコードのユーザIDと対応するレコードであり、ステータスが通知待ちのレコードを検索する。すなわち、通知先ユーザへ通知すべきレコードを検索する。検索の結果、抽出できた場合該当するレコードが存在した場合ステップS702:YESは、処理をステップS703に移行する。検索の結果、抽出できなかった場合該当するレコードが存在しない場合ステップS702:NOは、処理をステップS705に移行する。ステップS703では、EDIサーバ100のCPU201は、ステップS702で抽出された全てのレコードのメール情報を、1ユーザに対して1通のメールにまとめて送信する。具体的には、同一のユーザIDのレコードのメール内容を、1メールに添付し、メールサーバへSMTPプロトコルでユーザマスタテーブル図10のメールアドレス宛てに送信する。ステップS704では、EDIサーバ100のCPU201は、ステップS702で抽出されたレコードのステータスを通知済みに更新する。ステップS705では、EDIサーバ100のCPU201は、まとめ通知ではなく即時通知にメールを検出するために、ユーザマスタテーブル図10のまとめ通知がなしであるユーザを検索し、当該ユーザIDで通知メール状況テーブル図11を検索し、ステータスが通知待ちのレコードを抽出する。該当するレコードが存在した場合ステップS705:YESは、処理をステップS706に移行する。該当するレコードが存在しない場合ステップS705:NOは、処理をステップS708に移行する。ステップS706では、EDIサーバ100のCPU201は、ステップS705で抽出されたれレコードから、1レコード1メールとしてユーザに送信する。ステップS707では、EDIサーバ100のCPU201は、ステップS705で抽出されたレコードのステータスを通知済みに更新する。ステップS708では、EDIサーバ100のCPU201は、ユーザからのメール送信監視終了要求があるか否かを確認し、終了要求があれば処理を終了する。終了要求が無ければ、処理をステップS701に移行し、再度メール送信監視処理を繰り返す。図12は、ファイル転送監視スケジュールの設定を受け付ける画面の一例である。転送ファイル毎に監視スケジュールの設定を受け付ける。なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。また、本発明におけるプログラムは、図4~図7の処理方法をコンピュータが実行可能なプログラムである。なお、本発明におけるプログラムは図4~図7の各装置の処理方法ごとのプログラムであってもよい。以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータまたはCPUやMPUが記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD-ROM、CD-R、DVD-ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク等を用いることが出来る。また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOSオペレーティングシステム等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。"