JP2013121061A - 保守管理システム、サーバおよびクライアント端末 - Google Patents

Abstract

【課題】複数のオペレータが保守を行う際に、あるオペレータがある端末に対して保守を開始した後は、当該端末に対する他のオペレータによる保守操作を排除可能とする。
【解決手段】保守管理システムであって、サーバ１は、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段１１と、端末２の保守状況情報を管理する保守状況管理手段１３とを有し、操作可否判定手段１１は、保守状況情報を参照し、オペレータから入力されたオペレータＩＤとクライアント端末ＩＤとに基づいて当該オペレータによる保守の可否を判定し、保守状況管理手段１３は、保守可能と判定された場合、保守対象の端末に対して、操作が可能であることを通知する。
【選択図】図１

Description

本発明は、ネットワークに接続された端末を保守する保守管理システム、サーバおよびクライアント端末に関する。

ネットワークに接続された多数の端末を遠隔制御し、保守するシステムとして、例えば特許文献１などがある。特許文献１には、既存の多種類のメーカや機種の異なる被制御機器を、既存のＷＷＷブラウザ等の閲覧ソフトを搭載した端末を用いて遠隔から操作することを可能とするリモートコントロールシステムが記載されている。

特開２００３−１４３６６５号公報

従来の保守システムでは、複数のオペレータが同時に保守操作を実施する場合、ある端末に対して、あるオペレータが保守操作を実施した後に、同じ端末に対して、別のオペレータが別の保守操作を実施したことにより、前者のオペレータが意図した保守操作が実施できなくなるという問題がある。すなわち、別のオペレータが別の操作を実施したことにより、最初のオペレータがもともと意図していた一連の保守操作が中断され、最初のオペレータの一連の保守操作が開始又は完結できなくなる問題がある。

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、複数のオペレータが保守を行う際に、あるオペレータがある端末に対して保守を開始した後は、当該端末に対する他のオペレータによる保守操作を排除可能な保守管理システム、サーバおよびクライアント端末を提供することにある。

上記目的を達成するため、本発明は、サーバとクライアント端末が連携して保守状態を管理する保守管理システムであって、前記サーバは、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、前記保守状況情報は、保守毎に付与される保守識別子と、オペレータＩＤと、保守対象のクライアント端末ＩＤと有し、前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータＩＤとクライアント端末ＩＤとに基づいて当該オペレータによる保守の可否を判定し、前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知する。

本発明は、サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるサーバであって、オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、前記保守状況情報は、保守毎に付与される保守識別子と、オペレータＩＤと、保守対象のクライアント端末ＩＤと有し、前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータＩＤとクライアント端末ＩＤとに基づいて当該オペレータによる保守の可否を判定し、前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知する。

本発明は、サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるクライアント端末であって、前記サーバから通知される次回保守状況取得予定日時を保持するとともに、前記次回保守状況取得予定日時に基づき前記サーバに保守状態を要求する保守状況取得手段と、前記保守状況取得手段が取得した保守状態に基づいて、保守継続の可否を判定する保守状況管理手段と、前記保守状況管理手段が保守継続不可と判定した場合、保守の終了を実行する保守終了実行手段とを有する。

本発明によれば、複数のオペレータが保守を行う際に、あるオペレータがある端末に対して保守を開始した後は、当該端末に対する他のオペレータによる保守操作を排除可能な保守管理システム、サーバおよびクライアント端末を提供することができる。

本発明の実施形態に係る保守管理システムの全体構成図である。 保守状況管理ＤＢの一例を示す図である。 保守設定管理ＤＢの一例を示す図である。 保守状況取得ＤＢの一例を示す図である。 保守開始処理のフローチャートである。 操作可否判定処理のフローチャートである。 個別の保守操作処理のフローチャートである。 保守終了処理のフローチャートである。 サーバによる自動保守終了処理のフローチャートである。 端末による自動保守終了処理のフローチャートである。 端末による再設定処理のフローチャートである。

以下、本発明の実施の形態について、図面を参照して説明する。

図１は、本発明の実施形態に係る保守管理システムの全体構成図である。本実施形態の保守管理システムは、サーバ１と、当該サーバ１とインターネットなどのネットワーク３を介して接続される複数の端末２とを備える。本実施形態の保守管理システムは、サーバ１および各端末２が連携し、複数のオペレータが一定期間に渡って複数の端末２の遠隔保守を実施するものである。

図示するサーバ１は、操作可否判定部１１と、保守継続判定部１２と、保守状況管理部１３と、保守設定管理部１４と、通信部１５とを備える。操作可否判定部１１は、端末２の保守を開始する操作、保守を終了する操作、および個別の保守操作を実施する際に、これらの操作の実施可否を判定する。

保守状況管理部１３は、端末２の保守を開始する際に、保守開始操作を実施するオペレータ情報と、顧客情報と、端末情報と、保守開始日時と、保守終了予定日時と、サーバ１で発行する保守識別子とを関連付けて、当該保守状況管理部１３が備える保守状況管理ＤＢ１３１に保持するとともに、保守を終了する際には、それらの関連付けられた情報を保守状況管理ＤＢ１３１から削除する。図２は、保守状況管理ＤＢ１３１の一例を示す図である。

保守継続判定部１２は、保守状況管理ＤＢ１３１の各保守終了予定日時に基づいて保守継続させるかどうかを判定し、個別の保守操作があった場合には保守終了予定日時を延長する。また、保守継続判定部１２は、保守を終了させるための指示を端末２に送信する。

保守設定管理部１４は、端末２に対して実施された個別の保守操作による設定内容を保守識別子と関連付けて、当該保守設定管理部１４が備える保守設定管理ＤＢ１４１に保持する。図３は、保守設定管理ＤＢ１４１の一例を示す図である。通信部１５は、端末２と通信する。

本実施形態の端末２は、通信部２１と、保守終了実行部２２と、保守状況取得部２３と、保守設定取得部２４とを備える。通信部２１は、サーバ１と通信する。保守状況取得部２３は、サーバ１から通知される保守識別子と、保守開始日時と、次回保守状況取得予定日時とを保守状況取得ＤＢ２３１に保持するとともに、サーバ１に対して保守状況の問い合わせを行うことで、保守を継続させるかどうかを判定する。図４は、保守状況取得ＤＢ２３１の一例を示す図である。

保守終了実行部２２は、端末２に対して実施された保守操作による設定内容を、保守開始前の状態に戻す。保守設定取得部２４は、必要に応じて（例えば、端末２が再起動したときに保守設定を引き継ぐ場合、オペレータの指示を受け付けた場合など）、保守識別子を指定してサーバ１から保守操作による設定内容を取得する。

なお、図示する端末２では、サーバ１と通信するエージェント（端末上で動作するプログラム）により、通信部２１、保守終了実行部２２、保守状況取得部２３および保守設定取得部２４の機能が実現されるものとする。

サーバ１および端末２は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、サーバ１および端末２の各機能は、サーバ１用のプログラムの場合はサーバ１のＣＰＵが、そして、端末２用のプログラム（エージェント）の場合は端末２のＣＰＵが、それぞれ実行することにより実現される。

また、サーバ１用のプログラムおよび端末２用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

次に、本実施形態の動作について説明する。

まず、「保守開始処理」について説明する。本実施形態では、端末に対する個別の保守操作を実施する前に、オペレータにより明示的に保守開始の操作を行うことで、サーバと端末とで連携して、端末の保守状態を管理する。

図５は、保守開始処理を示すフローチャートである。

まず、サーバの操作可否判定部１１は、オペレータが入力する保守開始指示を受け付ける（Ｓ１１）。すなわち、オペレータは、保守開始の操作の際に、対象とする顧客情報、端末情報、操作内容（保守開始）および操作するオペレータ情報を含む保守開始指示を入力する。操作可否判定部１１は、保守開始指示を受け付けると、図６に示す判定処理に従って、保守開始の実施が可能か否かを判定する（Ｓ１２）。

図６は、Ｓ１２の判定処理を示すフローチャートである。

まず、操作可否判定部１１は、Ｓ１１で受け付けた端末情報の端末が、保守中であるか否かを判別する（Ｓ２１）。すなわち、当該端末情報が、保守識別子と関連付けて操作状況管理ＤＢ１３１に登録され、既に保守が開始された保守状態の端末である否かを判別する。保守状態の端末でない場合であって（Ｓ２１：ＮＯ）、Ｓ１１で受け付けた操作内容が保守開始の場合（Ｓ２２：ＹＥＳ）、操作可否判定部１１は、保守開始が可能であると判定する（Ｓ２５）。

一方、保守状態の端末の場合（Ｓ２１：ＹＥＳ）、および、Ｓ１１で受け付けた操作内容が保守開始以外の場合（Ｓ２２：ＮＯ）、操作可否判定部１１は、保守開始が不可であると判定し（Ｓ２６、Ｓ２７、Ｓ２８）、以降の処理を中止する。

図６に示す判定処理を行うことにより、既に保守状態である端末に対しては、重複して保守開始を実施できないようにすることができる。

なお、図６に示す判定の他に、Ｓ１１で受け付けた顧客情報に対して、１人の顧客を保守するオペレータを１人のみとするために、同一の顧客情報に関連付けられた他の端末情報が既に保守開始されて、保守状況管理ＤＢ１３１に登録されているか否かの判定を行うこととしてもよい。同一の顧客情報に関連付けられた他の端末情報が既に保守開始されていて、保守状況管理ＤＢ１３１に登録されたオペレータ情報と、Ｓ１１で受け付けたオペレータ情報とが異なる場合、保守操作不可とする。これにより、１人の顧客に複数の端末が設置されている場合、保守対応するオペレータが１人に絞られることで、顧客へのサービスを向上させることができる。

保守開始の実施が可能な場合（図６：Ｓ２５）、図５に戻り、保守状況管理部１３は、サーバで一意となる保守識別子を払い出す（Ｓ１３）。そして、保守状況管理部１３は、払い出した保守識別子を含む保守状況情報を、保守状況管理ＤＢ１３１に登録する（Ｓ１４）。具体的には、保守識別子に関連付けて、保守開始を実施したオペレータ情報と、顧客情報と、端末情報と、保守開始日時（Ｓ１１の保守開始指示を受け付けた時刻）と、保守終了予定日時とを保守状況管理ＤＢ１３１に登録する。

保守終了予定日時は、保守開始日時に基づいて設定される日時であって、情報保守開始日時から一定期間後の日時とする。図２に示す保守状況管理ＤＢ１３１の例では、保守終了予定日時は、保守開始日時の３日後としている。なお、本実施形態では、保守終了予定日時を、保守開始日時から一定期間後として説明するが、オペレータが保守開始指示を入力する際に保守終了予定日時を指定するようにしてもよい。

そして、保守状況管理部１３は、通信部１５を用いて、オペレータが指定した端末上で動作するエージェントにＳ１４で登録した保守識別子およびを送信し、保守開始を通知する（Ｓ１５）。通信部１５は、保守状況管理部ＤＢ１３１に設定された端末情報を用いて送信先の端末を一意に特定する。なお、図２に示す具体例では、端末情報にIPv6アドレスを用いているが、IPv6アドレスに限定されるものではなく、例えばIPv4アドレスを用いることとしてもよい。

端末（エージェント）の通信部２１は、サーバから保守識別子を受信し、保守が開始されたことを把握する（Ｓ１６）。

そして、保守状況取得部２３は、Ｓ１６で受信した保守識別子、現在時刻である保守開始日時、次回保守状況取得予定日時を保守状況取得部ＤＢ２３１に登録する（Ｓ１７）。次回保守状況取得予定日時は、保守開始日時に基づいて設定される、次回保守状況を取得するための予定日時であって、保守開始日時から一定期間後の日時とする。図４に示す保守状況取得ＤＢ２３１の例では、次回保守状況取得予定日時は、保守開始日時の３時間後としている。なお、本実施形態では、次回保守状況取得予定日時を、保守開始日時から一定期間後として説明するが、次回保守状況取得予定日時は、サーバの保守状況管理部１３が算出し、サーバから端末に送信することとしてもよい。また、明示的な次回保守状況取得予定日時ではなく、取得予定間隔（例えば、「３時間後」）であってもよい。

次に、「個別の保守操作処理」について説明する。

本実施形態では、保守開始を実施したオペレータによる個別の保守操作が実施される場合に、サーバで、個別の保守操作による設定内容を保持するとともに、保守開始の際に登録された保守終了予定日時を延長するようにする。

図７は、個別の保守操作処理を示すフローチャートである。

操作可否判定部１１は、オペレータが個別の保守操作の際に指定する、対象とする端末情報、個別の操作内容、操作内容に伴う設定内容、操作するオペレータ情報を受け付ける（Ｓ３１）。そして、操作可否判定部１１は、図６に示す判定処理に従って、個別の保守操作の実施が可能か否かを判定する（Ｓ３２）。

図６において、操作可否判定部１１は、Ｓ３１で受け付けた端末情報の端末が、保守中であるか否かを判別する（Ｓ２１）。すなわち、当該端末情報が、保守識別子と関連付けて操作状況管理ＤＢ１３１に登録され、既に保守が開始された保守状態の端末である否かを判別する。保守状態の端末の場合であって（Ｓ２１：ＹＥＳ）、Ｓ３１で受け付けた操作内容が保守開始以外の場合（Ｓ２３：ＮＯ）、操作可否判定部１１は、Ｓ３１で受け付けたオペレータ情報が、操作状況管理ＤＢ１３１の当該端末情報と関連付けて登録されているオペレータ情報と一致するか否かを判定する（Ｓ２４）。オペレータ情報が一致する場合（Ｓ２４：ＹＥＳ）、操作可否判定部１１は、Ｓ３１で受け付けた個別の保守操作の実施が可能であると判定する（Ｓ２７）。

一方、保守状態でない場合（Ｓ２１：ＮＯ）であってＳ３１で受け付けた操作内容が保守開始ではない場合（Ｓ２２：ＮＯ）、保守状態であって（Ｓ２１：ＹＥＳ）Ｓ３１で受け付けた操作内容が保守開始の場合（Ｓ２３：ＹＥＳ）、および、オペレータ情報が一致しない場合（Ｓ２４：ＮＯ）、操作可否判定部１１は、個別の保守操作の実施が不可であると判定し（Ｓ２６、Ｓ２８）、以降の処理を中止する。

図６に示す判定処理により、保守状態でない端末の場合、保守状態である端末に対する操作内容が保守開始の場合、および保守開始を実行したオペレータ以外のオペレータからの個別の保守操作の場合は、実施できないようにすることができる。

なお、サーバの操作状況管理ＤＢ１３１に登録されている保守開始を実施したオペレータ情報を変更することで、保守開始を実施したオペレータ以外のオペレータの保守操作を実施できるようにしてもよい。具体的なオペレータ情報の変更処理としては、保守状況管理部１３は、オペレータが入力した、保守識別子、端末情報、変更するオペレータ情報を含むオペレータ情報変更指示を受け付ける。保守状況管理部１３は、保守状況管理ＤＢ１３１を参照し、受け付けた保守識別子に関連付けて登録されているオペレータ情報を、受け付けたオペレータ情報に更新する。これにより、保守開始を実施したオペレータ以外のオペレータが、端末に対して個別の保守操作を実施できるようにすることができる。

個別の保守操作の実施が可能と判断した場合（図６：Ｓ２７）、図７に戻り、保守状況管理部１３は、Ｓ３１で受け付けた端末情報およびオペレタータ情報に関連付けられている保守識別子を取得する（Ｓ３３）。

そして、保守設定管理部１４は、Ｓ３３で取得した保守識別子に関連付けて保守状況管理ＤＢ１３１に登録されている保守終了予定日時を所定の期間だけ延長する（Ｓ３４）。期間の延長は、その時点で登録されている保守終了予定日時に、所定の期間を加算し、加算結果を新たな保守終了予定日時とすることである。なお、延長する期間は、操作内容や端末の種類に応じて異なった期間とすることとしてもよい。この場合、操作内容や端末の種類毎に異なる延長期間を設定した延長期間テーブルを保守設定管理部１４が備えるものとする。

保守設定管理部１４は、Ｓ３３で取得した保守識別子に関連付けて、Ｓ３１で受け付けた個別の操作内容および操作内容に伴う設定内容と、再設定要否とを保守設定管理ＤＢ１４１に登録する（Ｓ３５）。再設定要否については、各操作内容毎に対応する「要」または「否」を保守設定管理部１４が保持し、それに基づいて登録する。なお、再設定要否については、Ｓ３１でオペレータが個別の保守操作を要求する際に個別に指定させるようにしてもよい。

図３に示す保守設定管理ＤＢ１４１の例では、操作内容および設定内容として、ログ出力を実施させる操作内容（ログ設定）であり、ログを出力させる対象をＯＳおよびアプリ２とし、出力するログレベルをERRORおよびDEBUGとした設定内容が記載されている。また、アプリ１を一時的に停止させる操作内容および設定内容が記載されている。また、再設定要否については、操作内容がログ設定である場合のみ再設定を必要としている。なお、操作内容および設定内容は、図３に示す例に限定されるものではなく、個別の保守操作に応じて定義されるものとする。

そして、保守状況管理部１３または保守設定管理部１４は、通信部１５を用いて、オペレータが指定した端末上で動作するエージェントに、個別の保守操作が可能であること、すなわち保守識別子、操作内容、操作内容に伴う設定内容を送信する。（Ｓ３６）。

端末（エージェント）の通信部２１は、サーバから保守識別子、個別の操作内容、操作内容に伴う設定内容を受信する（Ｓ３７）。そして、保守設定取得部２４は、個別の操作内容および設定内容に従って、当該保守設定取得部２４が備える記憶部（不図示）に、保守識別子、個別の操作内容、操作内容に伴う設定内容を記憶（登録または更新）する（Ｓ３８）。また、保守状況取得部２３は、保守状況取得ＤＢ２３１の次回保守状況取得予定日時を、一定期間延長するようにしてもよい。

なお、不正なアクセスを排除できるようにするために、Ｓ３７において、通信部２１にサーバのアドレスを事前に記憶し、排除処理を有効化した場合には、記憶したサーバのアドレスと送信元のアドレスとが同一かどうかを判定し、同一である場合のみ受信するようにしてもよい。また、通信部２１は、サーバから受信した保守識別子が、保守状況取得ＤＢ２３１に保持している保守識別子と同一かどうかを判定して、同一の場合のみ受信するようにしてもよい。

次に、「保守終了処理」について説明する。

本実施形態では、端末に対する個別の保守操作を実施した後に、オペレータにより明示的に保守終了の操作を行うことで、サーバと端末とで連携して、端末を保守する前の元の状態に戻す。

図８は、保守終了処理を示すフローチャートである。

サーバの操作可否判定部１１は、オペレータが保守終了の操作の際に指定する、対象とする端末情報、操作内容（保守終了）、操作するオペレータ情報を受け付ける（Ｓ４１）。

そして、操作可否判定部１１は、図６に示す判定処理に従って、保守終了の実施が可能か否か判定する（Ｓ４２）。

図６において、操作可否判定部１１は、Ｓ４１で受け付けた端末情報の端末が、保守中であるか否かを判別する（Ｓ２１）。すなわち、当該端末情報が、保守識別子と関連付けて操作状況管理ＤＢ１３１に登録され、既に保守が開始された保守状態の端末である否かを判別する。保守状態の端末の場合であって（Ｓ２１：ＹＥＳ）、Ｓ４１で受け付けた操作内容が保守開始以外の場合（Ｓ２３：ＮＯ）、操作可否判定部１１は、Ｓ４１で受け付けたオペレータ情報が、操作状況管理ＤＢ１３１の当該端末情報と関連付けて登録されているオペレータ情報と一致するか否かを判定する（Ｓ２４）。オペレータ情報が一致する場合（Ｓ２４：ＹＥＳ）、操作可否判定部１１は、保守終了の実施が可能であると判定する（Ｓ２７）。

一方、保守状態でない場合（Ｓ２１：ＮＯ）であってＳ４１で受け付けた操作内容が保守開始ではない場合（Ｓ２２：ＮＯ）、保守状態であって（Ｓ２１：ＹＥＳ）Ｓ４１で受け付けた操作内容が保守開始の場合（Ｓ２３：ＹＥＳ）、および、オペレータ情報が一致しない場合（Ｓ２４：ＮＯ）、操作可否判定部１１は、保守終了が不可能であると判定し（Ｓ２６、Ｓ２８）、以降の処理を中止する。

このような図６に示す判定処理により、保守状態でない端末の場合、保守状態である端末に対する操作内容が保守開始の場合、および、保守開始や個別の保守操作を実施したオペレータ以外のオペレータからの保守終了操作の場合は、実施できないようにすることができる。

保守終了の実施が可能と判断した場合（図６：Ｓ２７）、図８に戻り、保守状況管理部１３は、Ｓ４１で受け付けた端末情報およびオペレタータ情報に関連付けられている保守識別子を取得する（Ｓ４３）。そして、保守状況管理部１３は、取得した保守識別子に関連付けて登録されている保守状況情報（レコード）を、保守状況管理ＤＢ１３１から削除する（Ｓ４４）。そして、保守設定管理部１４は、取得した保守識別子に関連付けて登録されている保守設定情報（レコード）を、保守設定管理部ＤＢ１４１から削除する（Ｓ４５）。

そして、保守状況管理部１３または保守設定管理部１４は、通信部１５を用いて、オペレータが指定した端末上で動作するエージェントに、操作が可能であること、すなわちＳ４３で取得した保守識別子を含む保守終了通知を送信する（Ｓ４６）。

端末（エージェント）の通信部２１は、サーバから保守識別子を含む保守終了通知を受信する（Ｓ４７）。そして、保守状況取得部２３は、受信した保守識別子に関連付けて登録されている保守状況情報を、保守状況管理ＤＢ２３１から削除する（Ｓ４８）。

そして、保守終了実行部２２は、保守終了処理（例えば、設定内容をデフォルトの設定に戻す等）を実施する（Ｓ４９）。デフォルトの設定は、端末の不揮発記憶領域（電源OFFでも記憶内容を保持することができる記憶領域）に記憶されている設定情報であって、この場合、デフォルトの設定を用いて保守開始前の設定情報に設定する。

次に、サーバによる自動保守終了処理について説明する。本実施形態では、前述のオペレータによる明示的な保守終了の操作（図８参照）が行われない場合においても、サーバによって保守終了を実施し、端末を保守開始前の元の状態に戻す。

図９は、サーバによる自動保守終了処理を説明するフローチャートである。保守継続判定部１２は、保守状態管理ＤＢ１３１に登録されている各保守終了予定日時について予め定めた所定のタイミングで監視・チェックし、保守終了予定日時が現在時刻を経過した場合（Ｓ５１：ＹＥＳ）、当該保守終了予定日時が現在時刻を経過した端末に対して保守継続不可と判定し、自動的に保守終了させるための処理を行う。なお、保守終了における具体的な内容は、図８の保守終了操作におけるＳ４３からＳ４９の処理と同じであるため、ここでは説明を省略する。

次に、端末による自動保守終了処理について説明する。本実施形態では、何らかの理由で、サーバから端末に対する保守終了の通知が到達しなかった場合にも保守終了を自動的に実施し、端末を保守開始前の元の状態に戻す。

図１０は、端末による自動保守終了処理を説明するフローチャートである。

保守状況取得部２３は、保守状況取得ＤＢ２３１で保持している次回保守状況取得予定日時が到来した（現在時刻よりも前になった）場合に（Ｓ６１：ＹＥＳ）、通信部２１を用いてサーバに保守識別子を通知し、保守状態の取得を要求する。そして、保守状況取得部２３は、サーバから保守状態の取得に成功し（Ｓ６２：ＹＥＳ）、かつ保守状態が保守中の場合（Ｓ６３：ＹＥＳ）に、保守継続可と判定し、保守状況取得ＤＢ２３１の次回保守状況取得予定日時を予め定めた所定の期間分延長して更新する。

サーバの保守状況管理部１３は、端末からの保守状態の取得要求を受け付けると、保守状況管理ＤＢ１３１を参照し、当該取得要求を受け付けた要求時刻（現在時刻）と通知された保守識別子の保守終了予定時刻とを比較し、要求時刻が保守終了予定時刻より前の場合には、保守中の保守状況を、通信部１５を用いて端末に送信する。要求時刻が保守終了予定時刻以降の場合、または、通知された保守識別子の情報が存在しない場合、保守終了の保守状況を、通信部１５を用いて端末に送信する。

なお、端末が保守識別子を指定せずに保守状態の取得要求した場合、保守設定管理部１４は、アクセス元である端末のアドレスに基づいて、対象となる端末を決定してもよい。すなわち、保守設定管理部１４は、アクセス元のアドレスが保守状況管理ＤＢ１３１に保持している端末情報と一致する端末を検索し、保守状態を判別することとしてもよい。

なお、次回保守状況取得予定日時は、サーバの保守状況管理部１３が設定し、サーバから保守状態の応答とともに送信することにしてもよい。サーバで次回保守状況取得予定日時を設定することで、保守中である端末の数やサーバの負荷状況を考慮することができるため、サーバへのアクセス分散が可能になる。また、次回保守状況取得予定日時という具体的な日時ではなく、取得予定間隔であってもよい。

一方、サーバからの応答が保守中でない場合（Ｓ６３：ＮＯ）、または、サーバと端末間のネットワークの問題発生等により、サーバからの保守状態が取得できなかった場合（保守状態の取得要求は、所定の回数リトライを実施することにしてもよい）（Ｓ６２：ＮＯ）、保守終了実行部２２は、保守継続不可と判別し、保守終了を実行する。保守終了における具体的な処理の内容は、図８の保守終了操作におけるＳ４８からＳ４９の処理と同じであるため、ここでは説明を省略する。

次に、端末での個別の保守操作の設定内容の再設定処理について説明する。本実施形態では、端末に対して実施した個別の保守操作による設定内容を、サーバで保持し、端末２に対して再設定する。

図１１は、端末での再設定処理を示すフローチャートである。

端末の保守状況取得部２３は、図５の保守開始の操作におけるＳ１６で、サーバから受信した保守識別子を不揮発領域に保存する。そして、端末の再起動等に伴い、エージェントを起動した場合、保守設定取得部２４は、不揮発領域をチェックし、保守識別子が存在している場合（Ｓ７１：ＹＥＳ）、通信部２１を用いてサーバに対して保守識別子を通知して、再設定内容を要求する。

サーバの保守設定管理部１４は、保守設定管理ＤＢ１４１を参照し、通知された保守識別子に対応し、かつ、再設定要否が「要」に設定された操作内容および設定内容を特定し、端末に送信する。

なお、端末が保守識別子を指定せずに再設定内容を要求した場合、保守設定管理部１４は、アクセス元である端末のアドレスに基づいて、再設定対象となっている操作内容および設定内容を決定してもよい。すなわち、保守設定管理部１４は、アクセス元のアドレスが保守状況管理ＤＢ１３１に保持している端末情報と一致する保守識別子を検索し、検索された保守識別子を用いて保守設定管理ＤＢ１４１を検索することとしてもよい。

保守設定取得部２４は、サーバから再設定内容が取得できた場合には（Ｓ７２：ＹＥＳ）、取得した設定内容にもとづいて再設定を実施する。再設定における具体的な処理の内容は、図７の個別の保守操作におけるＳ３７からＳ３８の処理と同じであるため、ここでは説明を省略する。なお、Ｓ７２の保守設定取得部２４の取得要求は、所定の回数リトライを実施することにしてもよい。

また、エージェントの起動時以外にも、サーバがオペレータから設定内容の再設定要求を受け付けて、保守設定取得部２４がその通知を受信した時に実施するようにしてもよい。

また、上記再設定要求受付の際に、当該再設定が実施された場合に設定される設定内容をオペレータ操作に基づき追加変更や削除ができるようにしてもよい。これにより、再起動後の端末の設定内容を確認した上で意図した内容にすることができ、さらに、再設定のためのサーバからの送信されるデータ量を削減することができる。

以上説明した本実施形態では、サーバと端末とを連携させることにより、複数のオペレータが同時に保守を行う環境で、端末に対して一定期間継続して様々な保守操作を行って実施される遠隔保守（例えば、一定期間、保守用のログを出力させる、また、保守用のテストアプリを動作させるなど）において、複数のオペレータが同一の端末に対して同時に保守操作を行うことを防止することができる。

また、本実施形態では、様々な個別の保守操作によって端末の設定変更等を実施した端末２に再起動が生じ、端末における設定変更内容がクリアされてしまった場合であっても、端末での再設定処理（図１１）を行うことで、保守操作による設定変更内容を再設定することができる。

また、本実施形態では、オペレータから保守終了の操作指示がない場合であっても、サーバまたは端末で自動的に保守を終了させ、保守する前の元の状態に確実に戻すことができる。これにより、オペレータが明示的な保守終了の操作を忘れた場合、また明示的な保守終了の操作があっても、ネットワーク障害等の何らかの保守終了の通知が端末で受信されない場合であっても、保守する前の元の状態に確実に戻すことができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態のサーバは、保守状況管理部１３および保守設定管理部１４がそれぞれ、保守状況管理ＤＢ１３１および保守設定管理ＤＢ１４１を備えることとしたが、サーバが独立した記憶部を備え、当該記憶部にまとめて保守状況管理ＤＢ１３１および保守設定管理ＤＢ１４１の情報を記憶するようにしてもよい。

１ ：サーバ
１１：操作可否判定部
１２：保守継続判定部
１３：保守状況管理部
１３１：保守状況管理ＤＢ
１４：保守設定管理部
１４１：保守設定管理ＤＢ
１５：通信部
２ ：端末
２１：通信部
２２：保守終了実行部
２３：保守状況取得部
２３１：保守状況取得ＤＢ
２４：保守設定取得部
３ ：ネットワーク

Claims (9)

1. サーバとクライアント端末が連携して保守状態を管理する保守管理システムであって、
   前記サーバは、
   オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、
   前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、
   前記保守状況情報は、保守毎に付与される保守識別子と、オペレータＩＤと、保守対象のクライアント端末ＩＤと有し、
   前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータＩＤとクライアント端末ＩＤとに基づいて当該オペレータによる保守の可否を判定し、
   前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知すること
   を特徴とする保守管理システム。
2. 前記保守状況情報は、保守終了予定時刻をさらに有し、
   前記サーバは、
   前記保守状況情報の各保守終了予定時刻を監視し、現在時刻を経過した保守終了予定日時のクライアント端末に保守の終了を通知する保守継続判定手段をさらに有し、
   前記保守継続判定手段は、クライアント端末からの保守状態の取得要求を受け付けると、当該取得要求を受け付けた要求時刻と保守終了予定時刻とを比較し、要求時刻が保守終了予定時刻より前の場合には、保守中であることを前記クライアント端末に通知し、
   前記クライアントは、
   次回保守状況取得予定日時を保持するとともに、前記次回保守状況取得予定日時に基づき前記サーバに保守状態を要求する保守状況取得手段と、
   前記保守状況取得手段が取得した保守状態に基づいて、保守継続の可否を判定する保守状況管理手段と、
   前記保守状況管理手段が保守継続不可と判定した場合、保守の終了を実行する保守終了実行手段とを有すること
   を特徴とする請求項１記載の保守管理システム。
3. 前記サーバは、
   オペレータからの入力に基づいて、前記クライアント端末に対して実施される保守操作内容を、前記保守識別子に対応付けて保持する保守設定管理手段をさらに有し、
   前記クライアントは、
   当該クライアント端末に対して実施された保守操作内容の取得要求を前記サーバに送信し、前記サーバから取得した保守操作内容を記憶手段に設定する保守設定取得手段を有すること
   を特徴とする請求項１または請求項２記載の保守管理システム。
4. サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるサーバであって、
   オペレータからの入力を受け付け操作の可否を判定する操作可否判定手段と、
   前記クライアント端末の保守状況情報を管理する保守状況管理手段と、を有し、
   前記保守状況情報は、保守毎に付与される保守識別子と、オペレータＩＤと、保守対象のクライアント端末ＩＤと有し、
   前記操作可否判定手段は、前記保守状況情報を参照し、前記オペレータから入力されたオペレータＩＤとクライアント端末ＩＤとに基づいて当該オペレータによる保守の可否を判定し、
   前記保守状況管理手段は、保守可能と判定された場合、保守対象のクライアント端末に対して、操作が可能であることを通知すること
   を特徴とするサーバ。
5. 前記保守状況情報は、保守終了予定時刻をさらに有し、
   前記サーバは、前記保守状況情報の各保守終了予定時刻を監視し、現在時刻を経過した保守終了予定日時のクライアント端末に保守の終了を通知する保守継続判定手段をさらに有すること
   を特徴とする請求項４記載のサーバ。
6. 前記保守継続判定手段は、クライアント端末からの保守状態の取得要求を受け付けると、当該取得要求を受け付けた要求時刻と保守終了予定時刻とを比較し、要求時刻が保守終了予定時刻より前の場合には、保守中であることを前記クライアント端末に通知すること
   を特徴とする請求項５記載のサーバ。
7. 前記サーバは、オペレータからの入力に基づいて、前記クライアント端末に対して実施される保守操作内容を、前記保守識別子に対応付けて保持する保守設定管理手段をさらに有すること、
   を特徴とする請求項４から６のいずれか１項に記載のサーバ。
8. サーバとクライアント端末が連携して保守状態を管理する保守管理システムにおけるクライアント端末であって、
   次回保守状況取得予定日時を保持するとともに、前記次回保守状況取得予定日時に基づき前記サーバに保守状態を要求する保守状況取得手段と、
   前記保守状況取得手段が取得した保守状態に基づいて、保守継続の可否を判定する保守状況管理手段と、
   前記保守状況管理手段が保守継続不可と判定した場合、保守の終了を実行する保守終了実行手段とを有すること
   を特徴とするクライアント端末。
9. 前記保守設定取得手段は、当該クライアント端末に対して実施された操作内容の取得要求を前記サーバに送信し、前記サーバから取得した操作内容を記憶手段に設定すること
   を特徴とする請求項８に記載のクライアント端末。

Images