サーバとクライアント端末が連携して保守状態を管理する保守管理システムであって、前記サーバは、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、前記保守状況情報は、保守毎に付与される保守識別子と、オペレータIDと、保守対象のクライアント端末IDと有し、前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータIDとクライアント端末IDとに基づいて当該オペレータによる保守の可否を判定し、前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知することを特徴とする保守管理システム。前記保守状況情報は、保守終了予定時刻をさらに有し、前記サーバは、前記保守状況情報の各保守終了予定時刻を監視し、現在時刻を経過した保守終了予定日時のクライアント端末に保守の終了を通知する保守継続判定手段をさらに有し、前記保守継続判定手段は、クライアント端末からの保守状態の取得要求を受け付けると、当該取得要求を受け付けた要求時刻と保守終了予定時刻とを比較し、要求時刻が保守終了予定時刻より前の場合には、保守中であることを前記クライアント端末に通知し、前記クライアントは、次回保守状況取得予定日時を保持するとともに、前記次回保守状況取得予定日時に基づき前記サーバに保守状態を要求する保守状況取得手段と、前記保守状況取得手段が取得した保守状態に基づいて、保守継続の可否を判定する保守状況管理手段と、前記保守状況管理手段が保守継続不可と判定した場合、保守の終了を実行する保守終了実行手段とを有することを特徴とする請求項1記載の保守管理システム。前記サーバは、オペレータからの入力に基づいて、前記クライアント端末に対して実施される保守操作内容を、前記保守識別子に対応付けて保持する保守設定管理手段をさらに有し、前記クライアントは、当該クライアント端末に対して実施された保守操作内容の取得要求を前記サーバに送信し、前記サーバから取得した保守操作内容を記憶手段に設定する保守設定取得手段を有することを特徴とする請求項1または請求項2記載の保守管理システム。サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるサーバであって、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、前記保守状況情報は、保守毎に付与される保守識別子と、オペレータIDと、保守対象のクライアント端末IDと有し、前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータIDとクライアント端末IDとに基づいて当該オペレータによる保守の可否を判定し、前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知することを特徴とするサーバ。前記保守状況情報は、保守終了予定時刻をさらに有し、前記サーバは、前記保守状況情報の各保守終了予定時刻を監視し、現在時刻を経過した保守終了予定日時のクライアント端末に保守の終了を通知する保守継続判定手段をさらに有することを特徴とする請求項4記載のサーバ。前記保守継続判定手段は、クライアント端末からの保守状態の取得要求を受け付けると、当該取得要求を受け付けた要求時刻と保守終了予定時刻とを比較し、要求時刻が保守終了予定時刻より前の場合には、保守中であることを前記クライアント端末に通知することを特徴とする請求項5記載のサーバ。前記サーバは、オペレータからの入力に基づいて、前記クライアント端末に対して実施される保守操作内容を、前記保守識別子に対応付けて保持する保守設定管理手段をさらに有すること、を特徴とする請求項4から6のいずれか1項に記載のサーバ。サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるクライアント端末であって、次回保守状況取得予定日時を保持するとともに、前記次回保守状況取得予定日時に基づき前記サーバに保守状態を要求する保守状況取得手段と、前記保守状況取得手段が取得した保守状態に基づいて、保守継続の可否を判定する保守状況管理手段と、前記保守状況管理手段が保守継続不可と判定した場合、保守の終了を実行する保守終了実行手段とを有することを特徴とするクライアント端末。前記保守設定取得手段は、当該クライアント端末に対して実施された操作内容の取得要求を前記サーバに送信し、前記サーバから取得した操作内容を記憶手段に設定することを特徴とする請求項8に記載のクライアント端末。従来の保守システムでは、複数のオペレータが同時に保守操作を実施する場合、ある端末に対して、あるオペレータが保守操作を実施した後に、同じ端末に対して、別のオペレータが別の保守操作を実施したことにより、前者のオペレータが意図した保守操作が実施できなくなるという問題がある。すなわち、別のオペレータが別の操作を実施したことにより、最初のオペレータがもともと意図していた一連の保守操作が中断され、最初のオペレータの一連の保守操作が開始又は完結できなくなる問題がある。本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、複数のオペレータが保守を行う際に、あるオペレータがある端末に対して保守を開始した後は、当該端末に対する他のオペレータによる保守操作を排除可能な保守管理システム、サーバおよびクライアント端末を提供することにある。上記目的を達成するため、本発明は、サーバとクライアント端末が連携して保守状態を管理する保守管理システムであって、前記サーバは、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、前記保守状況情報は、保守毎に付与される保守識別子と、オペレータIDと、保守対象のクライアント端末IDと有し、前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータIDとクライアント端末IDとに基づいて当該オペレータによる保守の可否を判定し、前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知する。本発明は、サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるサーバであって、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、前記保守状況情報は、保守毎に付与される保守識別子と、オペレータIDと、保守対象のクライアント端末IDと有し、前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータIDとクライアント端末IDとに基づいて当該オペレータによる保守の可否を判定し、前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知する。本発明は、サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるクライアント端末であって、前記サーバから通知される次回保守状況取得予定日時を保持するとともに、前記次回保守状況取得予定日時に基づき前記サーバに保守状態を要求する保守状況取得手段と、前記保守状況取得手段が取得した保守状態に基づいて、保守継続の可否を判定する保守状況管理手段と、前記保守状況管理手段が保守継続不可と判定した場合、保守の終了を実行する保守終了実行手段とを有する。本発明によれば、複数のオペレータが保守を行う際に、あるオペレータがある端末に対して保守を開始した後は、当該端末に対する他のオペレータによる保守操作を排除可能な保守管理システム、サーバおよびクライアント端末を提供することができる。以下、本発明の実施の形態について、図面を参照して説明する。図1は、本発明の実施形態に係る保守管理システムの全体構成図である。本実施形態の保守管理システムは、サーバ1と、当該サーバ1とインターネットなどのネットワーク3を介して接続される複数の端末2とを備える。本実施形態の保守管理システムは、サーバ1および各端末2が連携し、複数のオペレータが一定期間に渡って複数の端末2の遠隔保守を実施するものである。図示するサーバ1は、操作可否判定部11と、保守継続判定部12と、保守状況管理部13と、保守設定管理部14と、通信部15とを備える。操作可否判定部11は、端末2の保守を開始する操作、保守を終了する操作、および個別の保守操作を実施する際に、これらの操作の実施可否を判定する。保守状況管理部13は、端末2の保守を開始する際に、保守開始操作を実施するオペレータ情報と、顧客情報と、端末情報と、保守開始日時と、保守終了予定日時と、サーバ1で発行する保守識別子とを関連付けて、当該保守状況管理部13が備える保守状況管理DB131に保持するとともに、保守を終了する際には、それらの関連付けられた情報を保守状況管理DB131から削除する。図2は、保守状況管理DB131の一例を示す図である。保守継続判定部12は、保守状況管理DB131の各保守終了予定日時に基づいて保守継続させるかどうかを判定し、個別の保守操作があった場合には保守終了予定日時を延長する。また、保守継続判定部12は、保守を終了させるための指示を端末2に送信する。保守設定管理部14は、端末2に対して実施された個別の保守操作による設定内容を保守識別子と関連付けて、当該保守設定管理部14が備える保守設定管理DB141に保持する。図3は、保守設定管理DB141の一例を示す図である。通信部15は、端末2と通信する。本実施形態の端末2は、通信部21と、保守終了実行部22と、保守状況取得部23と、保守設定取得部24とを備える。通信部21は、サーバ1と通信する。保守状況取得部23は、サーバ1から通知される保守識別子と、保守開始日時と、次回保守状況取得予定日時とを保守状況取得DB231に保持するとともに、サーバ1に対して保守状況の問い合わせを行うことで、保守を継続させるかどうかを判定する。図4は、保守状況取得DB231の一例を示す図である。保守終了実行部22は、端末2に対して実施された保守操作による設定内容を、保守開始前の状態に戻す。保守設定取得部24は、必要に応じて例えば、端末2が再起動したときに保守設定を引き継ぐ場合、オペレータの指示を受け付けた場合など、保守識別子を指定してサーバ1から保守操作による設定内容を取得する。なお、図示する端末2では、サーバ1と通信するエージェント端末上で動作するプログラムにより、通信部21、保守終了実行部22、保守状況取得部23および保守設定取得部24の機能が実現されるものとする。サーバ1および端末2は、例えば、CPUと、メモリと、HDD等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、サーバ1および端末2の各機能は、サーバ1用のプログラムの場合はサーバ1のCPUが、そして、端末2用のプログラムエージェントの場合は端末2のCPUが、それぞれ実行することにより実現される。また、サーバ1用のプログラムおよび端末2用のプログラムは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD-ROMなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。次に、本実施形態の動作について説明する。まず、保守開始処理について説明する。本実施形態では、端末に対する個別の保守操作を実施する前に、オペレータにより明示的に保守開始の操作を行うことで、サーバと端末とで連携して、端末の保守状態を管理する。図5は、保守開始処理を示すフローチャートである。まず、サーバの操作可否判定部11は、オペレータが入力する保守開始指示を受け付けるS11。すなわち、オペレータは、保守開始の操作の際に、対象とする顧客情報、端末情報、操作内容保守開始および操作するオペレータ情報を含む保守開始指示を入力する。操作可否判定部11は、保守開始指示を受け付けると、図6に示す判定処理に従って、保守開始の実施が可能か否かを判定するS12。図6は、S12の判定処理を示すフローチャートである。まず、操作可否判定部11は、S11で受け付けた端末情報の端末が、保守中であるか否かを判別するS21。すなわち、当該端末情報が、保守識別子と関連付けて操作状況管理DB131に登録され、既に保守が開始された保守状態の端末である否かを判別する。保守状態の端末でない場合であってS21:NO、S11で受け付けた操作内容が保守開始の場合S22:YES、操作可否判定部11は、保守開始が可能であると判定するS25。一方、保守状態の端末の場合S21:YES、および、S11で受け付けた操作内容が保守開始以外の場合S22:NO、操作可否判定部11は、保守開始が不可であると判定しS26、S27、S28、以降の処理を中止する。図6に示す判定処理を行うことにより、既に保守状態である端末に対しては、重複して保守開始を実施できないようにすることができる。なお、図6に示す判定の他に、S11で受け付けた顧客情報に対して、1人の顧客を保守するオペレータを1人のみとするために、同一の顧客情報に関連付けられた他の端末情報が既に保守開始されて、保守状況管理DB131に登録されているか否かの判定を行うこととしてもよい。同一の顧客情報に関連付けられた他の端末情報が既に保守開始されていて、保守状況管理DB131に登録されたオペレータ情報と、S11で受け付けたオペレータ情報とが異なる場合、保守操作不可とする。これにより、1人の顧客に複数の端末が設置されている場合、保守対応するオペレータが1人に絞られることで、顧客へのサービスを向上させることができる。保守開始の実施が可能な場合図6:S25、図5に戻り、保守状況管理部13は、サーバで一意となる保守識別子を払い出すS13。そして、保守状況管理部13は、払い出した保守識別子を含む保守状況情報を、保守状況管理DB131に登録するS14。具体的には、保守識別子に関連付けて、保守開始を実施したオペレータ情報と、顧客情報と、端末情報と、保守開始日時S11の保守開始指示を受け付けた時刻と、保守終了予定日時とを保守状況管理DB131に登録する。保守終了予定日時は、保守開始日時に基づいて設定される日時であって、情報保守開始日時から一定期間後の日時とする。図2に示す保守状況管理DB131の例では、保守終了予定日時は、保守開始日時の3日後としている。なお、本実施形態では、保守終了予定日時を、保守開始日時から一定期間後として説明するが、オペレータが保守開始指示を入力する際に保守終了予定日時を指定するようにしてもよい。そして、保守状況管理部13は、通信部15を用いて、オペレータが指定した端末上で動作するエージェントにS14で登録した保守識別子およびを送信し、保守開始を通知するS15。通信部15は、保守状況管理部DB131に設定された端末情報を用いて送信先の端末を一意に特定する。なお、図2に示す具体例では、端末情報にIPv6アドレスを用いているが、IPv6アドレスに限定されるものではなく、例えばIPv4アドレスを用いることとしてもよい。端末エージェントの通信部21は、サーバから保守識別子を受信し、保守が開始されたことを把握するS16。そして、保守状況取得部23は、S16で受信した保守識別子、現在時刻である保守開始日時、次回保守状況取得予定日時を保守状況取得部DB231に登録するS17。次回保守状況取得予定日時は、保守開始日時に基づいて設定される、次回保守状況を取得するための予定日時であって、保守開始日時から一定期間後の日時とする。図4に示す保守状況取得DB231の例では、次回保守状況取得予定日時は、保守開始日時の3時間後としている。なお、本実施形態では、次回保守状況取得予定日時を、保守開始日時から一定期間後として説明するが、次回保守状況取得予定日時は、サーバの保守状況管理部13が算出し、サーバから端末に送信することとしてもよい。また、明示的な次回保守状況取得予定日時ではなく、取得予定間隔例えば、3時間後であってもよい。次に、個別の保守操作処理について説明する。本実施形態では、保守開始を実施したオペレータによる個別の保守操作が実施される場合に、サーバで、個別の保守操作による設定内容を保持するとともに、保守開始の際に登録された保守終了予定日時を延長するようにする。図7は、個別の保守操作処理を示すフローチャートである。操作可否判定部11は、オペレータが個別の保守操作の際に指定する、対象とする端末情報、個別の操作内容、操作内容に伴う設定内容、操作するオペレータ情報を受け付けるS31。そして、操作可否判定部11は、図6に示す判定処理に従って、個別の保守操作の実施が可能か否かを判定するS32。図6において、操作可否判定部11は、S31で受け付けた端末情報の端末が、保守中であるか否かを判別するS21。すなわち、当該端末情報が、保守識別子と関連付けて操作状況管理DB131に登録され、既に保守が開始された保守状態の端末である否かを判別する。保守状態の端末の場合であってS21:YES、S31で受け付けた操作内容が保守開始以外の場合S23:NO、操作可否判定部11は、S31で受け付けたオペレータ情報が、操作状況管理DB131の当該端末情報と関連付けて登録されているオペレータ情報と一致するか否かを判定するS24。オペレータ情報が一致する場合S24:YES、操作可否判定部11は、S31で受け付けた個別の保守操作の実施が可能であると判定するS27。一方、保守状態でない場合S21:NOであってS31で受け付けた操作内容が保守開始ではない場合S22:NO、保守状態であってS21:YESS31で受け付けた操作内容が保守開始の場合S23:YES、および、オペレータ情報が一致しない場合S24:NO、操作可否判定部11は、個別の保守操作の実施が不可であると判定しS26、S28、以降の処理を中止する。図6に示す判定処理により、保守状態でない端末の場合、保守状態である端末に対する操作内容が保守開始の場合、および保守開始を実行したオペレータ以外のオペレータからの個別の保守操作の場合は、実施できないようにすることができる。なお、サーバの操作状況管理DB131に登録されている保守開始を実施したオペレータ情報を変更することで、保守開始を実施したオペレータ以外のオペレータの保守操作を実施できるようにしてもよい。具体的なオペレータ情報の変更処理としては、保守状況管理部13は、オペレータが入力した、保守識別子、端末情報、変更するオペレータ情報を含むオペレータ情報変更指示を受け付ける。保守状況管理部13は、保守状況管理DB131を参照し、受け付けた保守識別子に関連付けて登録されているオペレータ情報を、受け付けたオペレータ情報に更新する。これにより、保守開始を実施したオペレータ以外のオペレータが、端末に対して個別の保守操作を実施できるようにすることができる。個別の保守操作の実施が可能と判断した場合図6:S27、図7に戻り、保守状況管理部13は、S31で受け付けた端末情報およびオペレタータ情報に関連付けられている保守識別子を取得するS33。そして、保守設定管理部14は、S33で取得した保守識別子に関連付けて保守状況管理DB131に登録されている保守終了予定日時を所定の期間だけ延長するS34。期間の延長は、その時点で登録されている保守終了予定日時に、所定の期間を加算し、加算結果を新たな保守終了予定日時とすることである。なお、延長する期間は、操作内容や端末の種類に応じて異なった期間とすることとしてもよい。この場合、操作内容や端末の種類毎に異なる延長期間を設定した延長期間テーブルを保守設定管理部14が備えるものとする。保守設定管理部14は、S33で取得した保守識別子に関連付けて、S31で受け付けた個別の操作内容および操作内容に伴う設定内容と、再設定要否とを保守設定管理DB141に登録するS35。再設定要否については、各操作内容毎に対応する要または否を保守設定管理部14が保持し、それに基づいて登録する。なお、再設定要否については、S31でオペレータが個別の保守操作を要求する際に個別に指定させるようにしてもよい。図3に示す保守設定管理DB141の例では、操作内容および設定内容として、ログ出力を実施させる操作内容ログ設定であり、ログを出力させる対象をOSおよびアプリ2とし、出力するログレベルをERRORおよびDEBUGとした設定内容が記載されている。また、アプリ1を一時的に停止させる操作内容および設定内容が記載されている。また、再設定要否については、操作内容がログ設定である場合のみ再設定を必要としている。なお、操作内容および設定内容は、図3に示す例に限定されるものではなく、個別の保守操作に応じて定義されるものとする。そして、保守状況管理部13または保守設定管理部14は、通信部15を用いて、オペレータが指定した端末上で動作するエージェントに、個別の保守操作が可能であること、すなわち保守識別子、操作内容、操作内容に伴う設定内容を送信する。S36。端末エージェントの通信部21は、サーバから保守識別子、個別の操作内容、操作内容に伴う設定内容を受信するS37。そして、保守設定取得部24は、個別の操作内容および設定内容に従って、当該保守設定取得部24が備える記憶部不図示に、保守識別子、個別の操作内容、操作内容に伴う設定内容を記憶登録または更新するS38。また、保守状況取得部23は、保守状況取得DB231の次回保守状況取得予定日時を、一定期間延長するようにしてもよい。なお、不正なアクセスを排除できるようにするために、S37において、通信部21にサーバのアドレスを事前に記憶し、排除処理を有効化した場合には、記憶したサーバのアドレスと送信元のアドレスとが同一かどうかを判定し、同一である場合のみ受信するようにしてもよい。また、通信部21は、サーバから受信した保守識別子が、保守状況取得DB231に保持している保守識別子と同一かどうかを判定して、同一の場合のみ受信するようにしてもよい。次に、保守終了処理について説明する。本実施形態では、端末に対する個別の保守操作を実施した後に、オペレータにより明示的に保守終了の操作を行うことで、サーバと端末とで連携して、端末を保守する前の元の状態に戻す。図8は、保守終了処理を示すフローチャートである。サーバの操作可否判定部11は、オペレータが保守終了の操作の際に指定する、対象とする端末情報、操作内容保守終了、操作するオペレータ情報を受け付けるS41。そして、操作可否判定部11は、図6に示す判定処理に従って、保守終了の実施が可能か否か判定するS42。図6において、操作可否判定部11は、S41で受け付けた端末情報の端末が、保守中であるか否かを判別するS21。すなわち、当該端末情報が、保守識別子と関連付けて操作状況管理DB131に登録され、既に保守が開始された保守状態の端末である否かを判別する。保守状態の端末の場合であってS21:YES、S41で受け付けた操作内容が保守開始以外の場合S23:NO、操作可否判定部11は、S41で受け付けたオペレータ情報が、操作状況管理DB131の当該端末情報と関連付けて登録されているオペレータ情報と一致するか否かを判定するS24。オペレータ情報が一致する場合S24:YES、操作可否判定部11は、保守終了の実施が可能であると判定するS27。一方、保守状態でない場合S21:NOであってS41で受け付けた操作内容が保守開始ではない場合S22:NO、保守状態であってS21:YESS41で受け付けた操作内容が保守開始の場合S23:YES、および、オペレータ情報が一致しない場合S24:NO、操作可否判定部11は、保守終了が不可能であると判定しS26、S28、以降の処理を中止する。このような図6に示す判定処理により、保守状態でない端末の場合、保守状態である端末に対する操作内容が保守開始の場合、および、保守開始や個別の保守操作を実施したオペレータ以外のオペレータからの保守終了操作の場合は、実施できないようにすることができる。保守終了の実施が可能と判断した場合図6:S27、図8に戻り、保守状況管理部13は、S41で受け付けた端末情報およびオペレタータ情報に関連付けられている保守識別子を取得するS43。そして、保守状況管理部13は、取得した保守識別子に関連付けて登録されている保守状況情報レコードを、保守状況管理DB131から削除するS44。そして、保守設定管理部14は、取得した保守識別子に関連付けて登録されている保守設定情報レコードを、保守設定管理部DB141から削除するS45。そして、保守状況管理部13または保守設定管理部14は、通信部15を用いて、オペレータが指定した端末上で動作するエージェントに、操作が可能であること、すなわちS43で取得した保守識別子を含む保守終了通知を送信するS46。端末エージェントの通信部21は、サーバから保守識別子を含む保守終了通知を受信するS47。そして、保守状況取得部23は、受信した保守識別子に関連付けて登録されている保守状況情報を、保守状況管理DB231から削除するS48。そして、保守終了実行部22は、保守終了処理例えば、設定内容をデフォルトの設定に戻す等を実施するS49。デフォルトの設定は、端末の不揮発記憶領域電源OFFでも記憶内容を保持することができる記憶領域に記憶されている設定情報であって、この場合、デフォルトの設定を用いて保守開始前の設定情報に設定する。次に、サーバによる自動保守終了処理について説明する。本実施形態では、前述のオペレータによる明示的な保守終了の操作図8参照が行われない場合においても、サーバによって保守終了を実施し、端末を保守開始前の元の状態に戻す。図9は、サーバによる自動保守終了処理を説明するフローチャートである。保守継続判定部12は、保守状態管理DB131に登録されている各保守終了予定日時について予め定めた所定のタイミングで監視チェックし、保守終了予定日時が現在時刻を経過した場合S51:YES、当該保守終了予定日時が現在時刻を経過した端末に対して保守継続不可と判定し、自動的に保守終了させるための処理を行う。なお、保守終了における具体的な内容は、図8の保守終了操作におけるS43からS49の処理と同じであるため、ここでは説明を省略する。次に、端末による自動保守終了処理について説明する。本実施形態では、何らかの理由で、サーバから端末に対する保守終了の通知が到達しなかった場合にも保守終了を自動的に実施し、端末を保守開始前の元の状態に戻す。図10は、端末による自動保守終了処理を説明するフローチャートである。保守状況取得部23は、保守状況取得DB231で保持している次回保守状況取得予定日時が到来した現在時刻よりも前になった場合にS61:YES、通信部21を用いてサーバに保守識別子を通知し、保守状態の取得を要求する。そして、保守状況取得部23は、サーバから保守状態の取得に成功しS62:YES、かつ保守状態が保守中の場合S63:YESに、保守継続可と判定し、保守状況取得DB231の次回保守状況取得予定日時を予め定めた所定の期間分延長して更新する。サーバの保守状況管理部13は、端末からの保守状態の取得要求を受け付けると、保守状況管理DB131を参照し、当該取得要求を受け付けた要求時刻現在時刻と通知された保守識別子の保守終了予定時刻とを比較し、要求時刻が保守終了予定時刻より前の場合には、保守中の保守状況を、通信部15を用いて端末に送信する。要求時刻が保守終了予定時刻以降の場合、または、通知された保守識別子の情報が存在しない場合、保守終了の保守状況を、通信部15を用いて端末に送信する。なお、端末が保守識別子を指定せずに保守状態の取得要求した場合、保守設定管理部14は、アクセス元である端末のアドレスに基づいて、対象となる端末を決定してもよい。すなわち、保守設定管理部14は、アクセス元のアドレスが保守状況管理DB131に保持している端末情報と一致する端末を検索し、保守状態を判別することとしてもよい。なお、次回保守状況取得予定日時は、サーバの保守状況管理部13が設定し、サーバから保守状態の応答とともに送信することにしてもよい。サーバで次回保守状況取得予定日時を設定することで、保守中である端末の数やサーバの負荷状況を考慮することができるため、サーバへのアクセス分散が可能になる。また、次回保守状況取得予定日時という具体的な日時ではなく、取得予定間隔であってもよい。一方、サーバからの応答が保守中でない場合S63:NO、または、サーバと端末間のネットワークの問題発生等により、サーバからの保守状態が取得できなかった場合保守状態の取得要求は、所定の回数リトライを実施することにしてもよいS62:NO、保守終了実行部22は、保守継続不可と判別し、保守終了を実行する。保守終了における具体的な処理の内容は、図8の保守終了操作におけるS48からS49の処理と同じであるため、ここでは説明を省略する。次に、端末での個別の保守操作の設定内容の再設定処理について説明する。本実施形態では、端末に対して実施した個別の保守操作による設定内容を、サーバで保持し、端末2に対して再設定する。図11は、端末での再設定処理を示すフローチャートである。端末の保守状況取得部23は、図5の保守開始の操作におけるS16で、サーバから受信した保守識別子を不揮発領域に保存する。そして、端末の再起動等に伴い、エージェントを起動した場合、保守設定取得部24は、不揮発領域をチェックし、保守識別子が存在している場合S71:YES、通信部21を用いてサーバに対して保守識別子を通知して、再設定内容を要求する。サーバの保守設定管理部14は、保守設定管理DB141を参照し、通知された保守識別子に対応し、かつ、再設定要否が要に設定された操作内容および設定内容を特定し、端末に送信する。なお、端末が保守識別子を指定せずに再設定内容を要求した場合、保守設定管理部14は、アクセス元である端末のアドレスに基づいて、再設定対象となっている操作内容および設定内容を決定してもよい。すなわち、保守設定管理部14は、アクセス元のアドレスが保守状況管理DB131に保持している端末情報と一致する保守識別子を検索し、検索された保守識別子を用いて保守設定管理DB141を検索することとしてもよい。保守設定取得部24は、サーバから再設定内容が取得できた場合にはS72:YES、取得した設定内容にもとづいて再設定を実施する。再設定における具体的な処理の内容は、図7の個別の保守操作におけるS37からS38の処理と同じであるため、ここでは説明を省略する。なお、S72の保守設定取得部24の取得要求は、所定の回数リトライを実施することにしてもよい。また、エージェントの起動時以外にも、サーバがオペレータから設定内容の再設定要求を受け付けて、保守設定取得部24がその通知を受信した時に実施するようにしてもよい。また、上記再設定要求受付の際に、当該再設定が実施された場合に設定される設定内容をオペレータ操作に基づき追加変更や削除ができるようにしてもよい。これにより、再起動後の端末の設定内容を確認した上で意図した内容にすることができ、さらに、再設定のためのサーバからの送信されるデータ量を削減することができる。以上説明した本実施形態では、サーバと端末とを連携させることにより、複数のオペレータが同時に保守を行う環境で、端末に対して一定期間継続して様々な保守操作を行って実施される遠隔保守例えば、一定期間、保守用のログを出力させる、また、保守用のテストアプリを動作させるなどにおいて、複数のオペレータが同一の端末に対して同時に保守操作を行うことを防止することができる。また、本実施形態では、様々な個別の保守操作によって端末の設定変更等を実施した端末2に再起動が生じ、端末における設定変更内容がクリアされてしまった場合であっても、端末での再設定処理図11を行うことで、保守操作による設定変更内容を再設定することができる。また、本実施形態では、オペレータから保守終了の操作指示がない場合であっても、サーバまたは端末で自動的に保守を終了させ、保守する前の元の状態に確実に戻すことができる。これにより、オペレータが明示的な保守終了の操作を忘れた場合、また明示的な保守終了の操作があっても、ネットワーク障害等の何らかの保守終了の通知が端末で受信されない場合であっても、保守する前の元の状態に確実に戻すことができる。なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態のサーバは、保守状況管理部13および保守設定管理部14がそれぞれ、保守状況管理DB131および保守設定管理DB141を備えることとしたが、サーバが独立した記憶部を備え、当該記憶部にまとめて保守状況管理DB131および保守設定管理DB141の情報を記憶するようにしてもよい。