(57)【要約】【課題】ＭＦＰ等の異常を確実にシステム管理者に知らせ、ＭＦＰ等の再起動をシステム管理者に促すこと。【解決手段】エージェントが動作するＭＦＰ101では、監視スレッド505が、ジョブ履歴送信スレッド504の異常を検出した場合（S902でYES）、ジョブ履歴処理サーバ102に異常を示すデータ（「内部エラー」及び「デバイス再起動待ち」のステータス）を送信し（S905，S906）、ジョブ履歴処理サーバ102と通信する全ての送信スレッドを停止する（S907〜S909）。ジョブ履歴処理サーバ102では、前記異常を示すデータを受信した場合、前記エージェントの状態が稼働中、かつ、前記エージェントに異常が発生していることを通知する（図１０Ａの1002の「稼働中」，1012の赤色表示）。また、前記エージェントからのアクセスが一定時間以上途絶えた場合、前記エージェントの状態が「不明」であることを示す通知を行う（図１０Ｃの1002の「不明」）。【選択図】図９
2019028593.tif 000002
【特許請求の範囲】
【請求項１】
稼働情報を外部送信するエージェントが動作する情報処理装置と、前記情報処理装置を管理するサーバとを有するシステムであって、
前記情報処理装置は、
前記サーバと通信するために前記エージェントが利用する１以上の送信スレッドを監視する監視スレッドが、送信スレッドの異常を検出した場合、前記サーバに異常を示すデータを送信する送信手段と、
前記監視スレッドが送信スレッドの異常を検出した場合、前記サーバと通信する全ての送信スレッドを停止する停止手段と、を有し、
前記サーバは、
前記異常を示すデータを受信した場合には、前記エージェントの状態が稼働中であり、かつ、前記エージェントに異常が発生していることを示す第１の通知を行う通知手段と、を有し、
前記通知手段は、前記エージェントからの通信が無く所定の条件を満たした場合には、前記エージェントの状態が不明であることを示す第２の通知をさらに行うことを特徴とするシステム。
【請求項２】
前記停止手段により前記サーバと通信する全ての送信スレッドを停止すべき前記送信スレッドの異常とは、前記送信スレッドによるデータ送信の停止又は遅延であることを特徴とする請求項１に記載のシステム。
【請求項３】
前記第２の通知に際しては、管理者に対して、前記エージェントの状態が不明であることを示すメールの送信がさらに行われ、
前記第１の通知に際しては、前記管理者に対するメール送信が行われないことを特徴とする請求項２に記載のシステム。
【請求項４】
前記第１の通知は、前記情報処理装置の再起動が必要であることを含むことを特徴とする請求項１〜３のいずれか１項に記載のシステム。
【請求項５】
前記情報処理装置は、前記監視スレッドが送信スレッドの異常を検出した場合、前記情報処理装置の再起動が必要なことを表示する表示手段を有することを特徴とする請求項１〜４のいずれか１項に記載のシステム。
【請求項６】
稼働情報を外部送信するエージェントが動作する情報処理装置と、前記情報処理装置を管理するサーバとを有するシステムの制御方法であって、
前記情報処理装置により実行される、
前記サーバと通信するために前記エージェントが利用する１以上の送信スレッドを監視する監視スレッドが、送信スレッドの異常を検出した場合、前記サーバに異常を示すデータを送信する送信ステップと、
前記監視スレッドが送信スレッドの異常を検出した場合、前記サーバと通信する全ての送信スレッドを停止する停止ステップと、を有し、
前記サーバにより実行される、
前記異常を示すデータを受信した場合には、前記エージェントの状態が稼働中であり、かつ、前記エージェントに異常が発生していることを示す第１の通知を行う第１の通知ステップと、
前記エージェントからの通信が無く所定の条件を満たした場合には、前記エージェントの状態が不明であることを示す第２の通知をさらに行う第２の通知ステップと、を有する、
ことを特徴とするシステムの制御方法。
【請求項７】
稼働情報をサーバに送信するエージェントが動作する情報処理装置であって、
前記サーバと通信するために前記エージェントが利用する１以上の送信スレッドを監視する監視スレッドが、送信スレッドの異常を検出した場合、前記サーバに異常を示すデータを送信する送信手段と、
前記監視スレッドが送信スレッドの異常を検出した場合、前記サーバと通信する全ての送信スレッドを停止する停止手段と、
を有することを特徴とする情報処理装置。
【請求項８】
前記停止手段により前記サーバと通信する全ての送信スレッドを停止すべき前記送信スレッドの異常とは、前記送信スレッドによるデータ送信の停止又は遅延であることを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記監視スレッドが送信スレッドの異常を検出した場合、前記情報処理装置の再起動が必要なことを表示する表示手段を有することを特徴とする請求項７又は８に記載の情報処理装置。
【請求項１０】
稼働情報をサーバに送信するエージェントが動作する情報処理装置の制御方法であって、
前記サーバと通信するために前記エージェントが利用する１以上の送信スレッドを監視する監視スレッドが、送信スレッドの異常を検出した場合、前記サーバに異常を示すデータを送信する送信ステップと、
前記監視スレッドが送信スレッドの異常を検出した場合、前記サーバと通信する全ての送信スレッドを停止する停止ステップと、
を有することを特徴とする情報処理装置の制御方法。
【請求項１１】
コンピュータを、請求項７〜９のいずれか１項に記載の手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、稼働情報を外部送信するエージェントが動作する情報処理装置と、情報処理装置を管理するサーバとを有するシステム、情報処理装置、これらの制御方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、情報漏洩の抑止や、情報漏洩者を追跡する目的で、プリンターやＭＦＰ（Multi Function Peripheral）等の画像形成装置が行った、印刷等のジョブに関する履歴情報を収集するジョブ履歴処理システムが開発されている。
【０００３】
ジョブ履歴処理システムは、ジョブ履歴収集エージェント（以下「エージェント」）と、ジョブ履歴処理サーバを有する。エージェントは、画像形成装置や、画像形成装置に印刷ジョブを送信するＰＣ（Personal Computer）等の情報処理装置上でジョブ履歴を収集する。ジョブ履歴処理サーバは、エージェントからジョブ履歴を受信して監査用にデータ変換や蓄積の処理を行う。
【０００４】
ジョブ履歴処理システムでは、エージェントで異常が発生すると、ジョブ履歴をジョブ履歴処理サーバに送信できず、エージェントが稼働している情報処理装置の記憶領域が一杯になってしまうことがある。
【０００５】
このような場合、その情報処理装置では、ジョブ履歴が記録できなくなる、ジョブ自体が実行できなくなるといった重大な問題に発展する可能性がある。このため、ジョブ履歴処理システムにおいては、エージェントの異常をいち早く検知することが望まれる。
【０００６】
特許文献１では、ネットワークに接続された情報通信端末の異常を検知する技術が提案されている。特許文献１の技術では、センター装置が、情報通信端末の内部状態を定期的に受信して監視することで情報通信端末の異常を検知している。また、情報通信端末からの内部状態の受信が滞った場合に、センター装置が、情報通信端末の異常を検知している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−１９５８６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、特許文献１の技術では、クライアントからの状態の通知が不定期に行われ、且つ、通知とは別に生存確認のためのクライアントからサーバへの定期的なアクセスが行われるようなシステムの場合に以下のような課題がある。
【０００９】
このようなシステムでは、クライアントは、異常が発生した際にそれをサーバに通知しようとするが、通知に不具合等があって、サーバに通知が届かないことがある。この場合、サーバは、クライアントから通知が来ないためにクライアントの異常を知ることができない。また、サーバは、この通知が来ないことでは異常とは検知しない。サーバは、クライアントからの生存確認のための定期的なアクセスが滞ればクライアントの異常検知が可能であるが、生存確認のための定期的なアクセスが正常に動作していれば異常検知もできない。
【００１０】
一方で、情報通信端末が異常を検知した時点で、情報通信端末自身を再起動するようなことが考えられる。再起動により、上述のような通知の不具合等は解消される可能性が高いからである。
【００１１】
しかし、仮に情報通信端末がＭＦＰであった場合、プリントやＦＡＸ受信等のジョブが実行中に、異常が検知されることによって予期せぬ再起動が発生すると、ジョブが中断してしまう等の弊害が出る可能性がある。このため、むやみに再起動することができない。
【００１２】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、ＭＦＰ等の情報処理装置の異常を確実にシステム管理者に知らせ、情報処理装置の再起動をシステム管理者に促すことができる仕組みを提供することである。
【課題を解決するための手段】
【００１３】
本発明は、稼働情報を外部送信するエージェントが動作する情報処理装置と、前記情報処理装置を管理するサーバとを有するシステムであって、前記情報処理装置は、前記サーバと通信するために前記エージェントが利用する１以上の送信スレッドを監視する監視スレッドが、送信スレッドの異常を検出した場合、前記サーバに異常を示すデータを送信する送信手段と、前記監視スレッドが送信スレッドの異常を検出した場合、前記サーバと通信する全ての送信スレッドを停止する停止手段と、を有し、前記サーバは、前記異常を示すデータを受信した場合には、前記エージェントの状態が稼働中であり、かつ、前記エージェントに異常が発生していることを示す第１の通知を行う通知手段と、を有し、前記通知手段は、前記エージェントからの通信が無く所定の条件を満たした場合には、前記エージェントの状態が不明であることを示す第２の通知をさらに行うことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、情報処理装置の異常を確実にシステム管理者に知らせ、情報処理装置の再起動をシステム管理者に促すことができる。
【図面の簡単な説明】
【００１５】
【図１】本実施例のジョブ履歴処理システムの構成例を示す図
【図２】本実施例の情報処理装置のハードウェア構成図
【図３】本実施例のジョブ履歴処理サーバのハードウェア構成図
【図４】実施例１のジョブ履歴処理システムのソフトウェア構成図
【図５】実施例１のエージェント制御部が実行するスレッドを例示する図
【図６】本実施例のステータス確認スレッドの処理手順を例示するフローチャート
【図７】本実施例の設定情報取得スレッドの処理手順を例示するフローチャート
【図８】本実施例のジョブ履歴送信スレッドの処理手順を例示するフローチャート
【図９】実施例１の監視スレッドの処理手順を例示するフローチャート
【図１０Ａ】本実施例のサーバＵＩ部が表示するエージェント一覧画面
【図１０Ｂ】本実施例のサーバＵＩ部が表示するエージェントプロパティー画面
【図１０Ｃ】本実施例のサーバＵＩ部が表示するエージェント一覧画面
【図１０Ｄ】本実施例のサーバＵＩ部が表示するエージェントプロパティー画面
【図１１】実施例２の監視スレッドの処理手順を例示するフローチャート
【図１２】実施例２のエージェントＵＩ部が表示する画面
【図１３】実施例３のジョブ履歴処理システムのソフトウェア構成図
【図１４】実施例３のエージェント制御部が実行するスレッドを例示する図
【図１５】実施例３の監視スレッドの処理手順を例示するフローチャート
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【００１７】
図１は、本発明の一実施例を示すジョブ履歴処理システム100の構成例を示す図である。
本実施例のジョブ履歴処理システム100は、ＭＦＰ101、ジョブ履歴処理サーバ102及びそれらに対する設定等を行うシステム管理者用ＰＣ103等を含むシステムである。
【００１８】
なお、ジョブ履歴処理システム100を構成するこれらの機器は、それぞれが複数台あってもよい。また、ジョブ履歴処理サーバ102は、１台の装置で構成されていてもよいし、複数の装置で構成されてもよい。ジョブ履歴処理サーバ102は、クラウドサーバ等で構成されていてもよい。例えば、ジョブ履歴処理サーバ102は、パブリッククラウドサービス等を利用して構築することも可能である。
【００１９】
ＭＦＰ101は、コピーやプリント等のジョブを実行すると共に、実行されたジョブのジョブ履歴を記録する画像形成装置である。ジョブ履歴は、ジョブの種別に応じて入力または出力される画像（以下「ジョブ履歴画像」）と、ジョブの実行日時や実行ユーザー等の情報からなるジョブ履歴属性情報等で構成される。そして、ＭＦＰ101上で動作するエージェント（後述する図４で詳述する）が、記録されたジョブ履歴をジョブ履歴処理サーバ102に送信する。
【００２０】
ジョブ履歴処理サーバ102は、エージェント400によって送信されるＭＦＰ101のジョブ履歴を受信する管理システムである。さらに、ジョブ履歴処理サーバ102は、必要に応じて、ジョブ履歴属性情報の整形や、ジョブ履歴画像の解像度変換等の処理を行い、蓄積する。また、ジョブ履歴処理サーバ102は、エージェントの設定値やステータス等を管理し、必要に応じてそれらをＵＩ画面に表示する。
【００２１】
システム管理者用ＰＣ103は、ウェブブラウザ（Web Browser）を介してＭＦＰ101で稼働しているエージェントやジョブ履歴処理サーバ102のＵＩ画面にアクセスし、システム管理者が各種設定等を行うためのＰＣである。
【００２２】
図２は、ＭＦＰ101のハードウェア構成の一例を示すブロック図である。
コントローラーユニット200は、スキャナー222やプリンター223およびネットワークや公衆回線と接続して、画像データやデバイス情報の入出力を行う。
【００２３】
ＣＰＵ201は、ＲＯＭ203又はＨＤＤ204に記憶されるプログラムを実行することにより、ＭＦＰ101全体の制御を行う。ＲＡＭ202は、ＣＰＵ201が動作するためのワークメモリであると共に、入力された画像データを一時記憶するための画像メモリでもある。ＲＯＭ203は、ブートＲＯＭであり、システムのブートプログラムが保存されている。ＨＤＤ204は、システムソフトウェア、ジョブ履歴、ユーザーボックス内の画像データ等を保存するハードディスクドライブである。なお、ＨＤＤの代わりに又は併用してＳＳＤ（ソリッドステートドライブ）等の他の記憶装置を備えていてもよい。
【００２４】
操作部Ｉ／Ｆ205は、操作部221とのインターフェース部であり、操作部221に表示する画面データを操作部221に対して出力する。
ネットワークＩ／Ｆ206は、ＬＡＮ等のネットワークに接続し、情報の入出力を行う。モデム207は、公衆回線に接続し、画像データの入出力を行う。
以上のデバイスが、システムバス208上に配置される。
【００２５】
イメージバスＩ／Ｆ209は、システムバス208と、画像データを高速で転送する画像バス210とを接続し、データ構造を変換するバスブリッジである。画像バス210上には、以下のデバイスが配置される。
【００２６】
ＲＩＰ（ラスターイメージプロセッサー）211は、ＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ212は、画像入出力デバイスであるスキャナー222及びプリンター223と、コントローラーユニット200とを接続し、画像データの変換を行う。
【００２７】
スキャナー画像処理部213は、入力画像データに対し補正、加工、編集等を行う。プリンター画像処理部214は、出力画像データに対して、プリンターの補正、解像度変換等を行う。画像回転部215は、画像データの回転を行う。画像圧縮部216は、画像データの圧縮伸長処理を行う。
【００２８】
図３は、ジョブ履歴処理サーバ102を構成する装置のハードウェア構成の一例を示すブロック図である。
ＣＰＵ301を含む制御部300は、サーバ機の動作を制御する。ＣＰＵ301は、ＲＯＭ302やＨＤＤ304に記憶された制御プログラムを読み込んで、入力や出力といった各種制御処理や、演算処理を実行する。ＲＡＭ303は、ＣＰＵ301の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ304は、ジョブ履歴や各種プログラム等を記憶する。
【００２９】
操作入力Ｉ／Ｆ305は、接続されたキーボードやマウス等の操作デバイスからの信号入力を受け付ける。表示出力Ｉ／Ｆ306は、画面表示用のディスプレイ等への信号出力を行う。ネットワークＩ／Ｆ307は、制御部300をネットワークに接続し、ネットワーク上の別の装置との情報の送受信を行う。バス310は、制御部300内の各ブロックを接続するバスである。
【００３０】
図４は、実施例１のジョブ履歴処理システム100のソフトウェア構成の一例を示すブロック図である。なお、図４に示すソフトウェア構成は、ＭＦＰ101およびジョブ履歴処理サーバ102の双方のソフトウェアブロックを含んでいる。
【００３１】
まず、ＭＦＰ101上のソフトウェアブロックから説明する。
エージェント400は、ＭＦＰ101上で動作し、ジョブ履歴処理サーバ102と通信するクライアントであり、エージェント制御部401、エージェントＵＩ部402、エージェント情報管理部403を含む。なお、エージェント400は、ＭＦＰ101のＣＰＵ201が、ＲＯＭ203又はＨＤＤ204に記憶されるプログラムを実行することにより実現される。
【００３２】
エージェント制御部401は、複数のスレッドを生成し、ジョブ履歴処理サーバ102に対してジョブ履歴送信、設定情報取得、ステータス通知等の要求を行う。スレッドの詳細については後述する。
【００３３】
エージェントＵＩ部402は、エージェントの設定やステータス等を確認、設定するためのユーザーインターフェースとなる画面群（以下「エージェントＵＩ画面」）を提供する。エージェントＵＩ画面で扱われる設定やステータスの情報は、後述するエージェント情報管理部403で管理される。
【００３４】
本実施例では、エージェントＵＩ部402は、ウェブアプリケーションとして実装され、システム管理者用ＰＣ103のウェブブラウザからのアクセスに対してエージェントＵＩ画面を応答するものとする。ただし、エージェントＵＩ部402は、ＭＦＰ101上の操作部221にエージェントＵＩ画面を表示するようにしてもよい。なお、以下では、ウェブブラウザにエージェントＵＩ画面を応答することも、単に「エージェントＵＩ画面を表示する」と表現する。
【００３５】
エージェント情報管理部403は、エージェント400の設定やステータス等を保管する。本実施例では、これらの情報を、ＨＤＤ204上にＸＭＬ形式のファイルで管理するものとするが、データベース等で管理するようにしてもよい。
【００３６】
ジョブ履歴記憶部408は、ＭＦＰ101で実行されるジョブのジョブ履歴を記憶するＨＤＤ204上の領域である。
【００３７】
次に、ジョブ履歴処理サーバ102上のソフトウェアブロックについて説明する。
要求処理部411は、ＭＦＰ101上で動作するエージェント400のエージェント制御部401からのジョブ履歴送信や設定情報取得、ステータス通知等の処理要求を受信し、必要に応じた処理を実行する。
【００３８】
例えば、ジョブ履歴を受信した場合、要求処理部411は、後述するデータ処理部414に受信したジョブ履歴に対する処理を依頼する。また、設定情報取得の要求を受信した場合、要求処理部411は、後述するシステム情報管理部417からエージェント400が使用する設定項目とその設定値を取得し、エージェント制御部401に応答する。また、ステータス通知を受信した場合、要求処理部411は、受信したステータスをシステム情報管理部417に保存し、必要に応じて後述するメール通知部413にメール通知依頼等を行う。
【００３９】
サーバＵＩ部412は、ジョブ履歴処理サーバ102及びエージェント400の設定やステータス等を確認、設定するためのユーザーインターフェースとなる画面群（以下「サーバＵＩ画面」）を提供する。サーバＵＩ画面で扱われる設定やステータスの情報は、システム情報管理部417で管理される。
【００４０】
本実施例では、サーバＵＩ部412は、ウェブアプリケーションとして実装され、システム管理者用ＰＣ103のウェブブラウザからのアクセスに応じてサーバＵＩ画面を表示するものとする。ただし、単体で画面を表示するネイティブアプリケーション等であってもよい。なお、以下では、ウェブブラウザにサーバＵＩ画面を応答することも、単に「サーバＵＩ画面を表示する」と表現する。
【００４１】
メール通知部413は、他のソフトウェアブロックからの依頼を受けて、システム管理者等にメール通知を行う。システム管理者等の通知先やメールサーバのアドレス等、メール通知に関する設定は、サーバＵＩ画面で設定され、システム情報管理部417で管理されているものとする。
【００４２】
データ処理部414は、要求処理部411が受信したジョブ履歴に含まれる画像に対し、ＯＣＲによるテキスト抽出や、画像形式変換および解像度変換等の処理を行う。また、データ処理部414は、画像のサムネイルを作成したり、ジョブ履歴属性情報を整形したりする等してもよい。そして、データ処理部414は、処理したジョブ履歴等を後述するデータ管理部416に保存する。
【００４３】
エージェント不明検知部415は、エージェント400からのアクセスが一定時間以上途絶えた場合等の所定の条件を満たした場合に、エージェント400のステータスを「不明」とする。エージェント不明検知部415がステータスを「不明」とする仕組みについては後述する。
【００４４】
データ管理部416は、データ処理部414が処理したジョブ履歴を保管する。本実施例では、データ管理部416は、ジョブ履歴に含まれるジョブ履歴画像やジョブ履歴属性情報、ＯＣＲで抽出されたテキスト等の情報を、それぞれファイルとしてＨＤＤ304上のファイルシステムに保管するものとする。ただし、データ処理部414は、情報をファイルシステムではなくデータベース等に保管するようにしてもよい。また、データ処理部414が、保管したジョブ履歴を監査するための検索の機能を備えていてもよい。
【００４５】
システム情報管理部417は、ジョブ履歴処理サーバ102およびエージェント400の設定やステータス等を保管する。本実施例では、これらの情報を、ジョブ履歴処理サーバ102やエージェント400毎にＸＭＬ形式のファイルで管理するものとするが、データベース等で管理するようにしてもよい。
【００４６】
なお、本実施例では、エージェント400がＭＦＰ101上で動作する構成を例に説明するが、プリンター等の他の画像形成装置上で動作する構成でもよい。また、エージェント400が、画像形成装置に印刷ジョブを投入できるプリンタードライバ（機能追加等によりジョブ履歴情報が取得可能）がインストールされたＰＣ等の上で動作する構成でもよい。また、エージェント400は、ジョブ履歴を送信するものに限定されず、該エージェント400が動作する情報処理装置の稼働情報を外部送信するものであればよい。ジョブ履歴処理サーバ102もＭＦＰ101のジョブ履歴を処理するものに限定されず、エージェント400が動作する情報処理装置の稼働情報を処理し、情報処理装置を管理するものであればよい。
【００４７】
図５は、実施例１におけるエージェント制御部401が実行するスレッドの一例を示す図である。
メインスレッド501は、エージェント400が起動すると開始されるメインのスレッドである。メインスレッド501は、ステータス確認スレッド502、設定情報取得スレッド503、ジョブ履歴送信スレッド504及び監視スレッド505等の１以上のスレッドを順次生成し、開始させる。
【００４８】
各スレッドの処理の詳細については、図６〜図９のフローチャートを用いて説明する。各フローチャートに示す各ステップは、ＭＦＰ101のＣＰＵ201が、ＲＯＭ203またはＨＤＤ204に記憶されているエージェント400を実現するプログラムを実行することで実現される。また、ＣＰＵ201は、各スレッドの処理において、必要に応じて記憶領域としてＲＡＭ202やＨＤＤ204を利用する。
【００４９】
図６は、ステータス確認スレッド502の動作の一例を示すフローチャートである。
S601において、ステータス確認スレッド502は、自身が持つ停止要求フラグがtrueか否かを判定する。停止要求フラグの初期値はfalseであり、自分自身もしくは他のスレッドから停止要求を受けた場合にtrueとなる。
【００５０】
上記S601において、停止要求フラグがtrueであると判定した場合（S601でYESの場合）、ステータス確認スレッド502は、自身の動作を終了する。
【００５１】
一方、上記S601において、停止要求フラグがtrueでないと判定した場合（S601でNOの場合）、ステータス確認スレッド502は、処理をS602に進める。
【００５２】
S602において、ステータス確認スレッド502は、ジョブ履歴記憶部408の空き容量等を確認し、エージェント情報管理部403で管理しているステータスに反映すべき新たなステータスの変化があればそれを反映する。
次にS603において、ステータス確認スレッド502は、エージェント情報管理部403で管理しているステータスと、自身が保持しているステータスとの差異があるかどうかを判定する。
【００５３】
上記S603において、、エージェント情報管理部403で管理しているステータスと、自身が保持しているステータスとに差異があると判定した場合（S603でYESの場合）、ステータス確認スレッド502は、処理をS606に進める。なお、スレッド開始時は保持しているステータスがないため、ステータス確認スレッド502は、処理をS606に進めるものとする。
【００５４】
S606において、ステータス確認スレッド502は、自身が保持しているステータスと現在のステータスとの差分を、ジョブ履歴処理サーバ102の要求処理部411に通知する。
次にS607において、ステータス確認スレッド502は、自身が保持しているステータスを現在のステータスで更新し、処理をS604に進める。
【００５５】
また、上記S603において、、エージェント情報管理部403で管理しているステータスと、自身が保持しているステータスとに差異がないと判定した場合（S603でNOの場合）、ステータス確認スレッド502は、処理をS604に進める。
【００５６】
S604において、ステータス確認スレッド502は、上記S601と同様に、自身が持つ停止要求フラグがtrueか否かを判定する。本ステップは、S601の後で、停止要求を受けた場合に備えるものである。
上記S604において、停止要求フラグがtrueであると判定した場合（S604でYESの場合）、ステータス確認スレッド502は、自身の動作を終了する。
【００５７】
一方、上記S604において、停止要求フラグがtrueでないと判定した場合（S604でNOの場合）、ステータス確認スレッド502は、処理をS605に進める。
S605において、ステータス確認スレッド502は、予め設定されたステータス確認間隔時間（例えば５分）スリープし、処理をS601に戻す。なお、上記S605のスリープ中に他のスレッドから割り込みがあった場合、ステータス確認スレッド502は、スリープを解除して直ちに処理をS601に戻す。
【００５８】
以上のように、ステータス確認スレッド502は、予め設定された間隔で、エージェント400のステータスを確認し、前回のステータス通知からステータスに変化があった場合にはジョブ履歴処理サーバ102の要求処理部411にステータスを通知する。なお、ステータスには、「ジョブ履歴送信エラー」、「内部エラー」、「ディスクニアフル」、「デバイス再起動待ち」等があるものとする。
【００５９】
図７は、設定情報取得スレッド503の動作の一例を示すフローチャートである。
S701において、設定情報取得スレッド503は、自身が持つ停止要求フラグがtrueか否かを判定する。停止要求フラグの初期値はfalseであり、自分自身もしくは他のスレッドから停止要求を受けた場合にtrueとなる。
上記S701において、停止要求フラグがtrueであると判定した場合（S701でYESの場合）、設定情報取得スレッド503は、自身の動作を終了する。
【００６０】
一方、上記S701において、停止要求フラグがtrueでないと判定した場合（S701でNOの場合）、設定情報取得スレッド503は、処理をS702に進める。
S702において、設定情報取得スレッド503は、ジョブ履歴処理サーバ102の要求処理部411に設定情報取得要求を行い、エージェント400に関する設定情報を取得する。
【００６１】
次にS703において、設定情報取得スレッド503は、上記S702で取得した設定情報と、エージェント情報管理部403で管理している設定情報とを比較し、変更があるかどうかを確認する。変更があると判定した場合（S703でYESの場合）、設定情報取得スレッド503は、処理をS706に進める。
S706において、設定情報取得スレッド503は、エージェント情報管理部403の設定情報を、上記S702で取得した設定情報で更新し、処理をS704に進める。
【００６２】
またS703において、上記S702で取得した設定情報に変更がないと判定した場合（S703でNOの場合）、設定情報取得スレッド503は、処理をS704に進める。
【００６３】
S704において、設定情報取得スレッド503は、上記S701と同様に、自身が持つ停止要求フラグがtrueか否かを判定する。本ステップは、S701の後で、停止要求を受けた場合に備えるものである。停止要求フラグがtrueであると判定した場合（S704でYESの場合）、設定情報取得スレッド503は、自身の動作を終了する。
【００６４】
一方、上記S704において、停止要求フラグがtrueでないと判定した場合（S704でNOの場合）、設定情報取得スレッド503は、処理をS705に進める。
S705において、設定情報取得スレッド503は、予め設定された設定情報取得間隔時間（例えば５分）スリープし、処理をS701に戻す。なお、上記S705のスリープ中に他のスレッドから割り込みがあった場合、設定情報取得スレッド503は、スリープを解除して直ちに処理をS701に戻す。
【００６５】
以上のように、設定情報取得スレッド503は、予め設定された間隔で、ジョブ履歴処理サーバ102の要求処理部411に設定情報取得要求を行う。そして、設定情報に変更があった場合には、取得した設定情報をエージェント情報管理部403で管理しているエージェント情報に反映する。
【００６６】
図８は、ジョブ履歴送信スレッド504の動作の一例を示すフローチャートである。
S801において、ジョブ履歴送信スレッド504は、自身が持つ停止要求フラグがtrueか否かを判定する。停止要求フラグの初期値はfalseであり、自分自身もしくは他のスレッドから停止要求を受けた場合にtrueとなる。
上記S801において、停止要求フラグがtrueであると判定した場合（S801でYESの場合）、ジョブ履歴送信スレッド504は、自身の動作を終了する。
【００６７】
一方、上記S801において、停止要求フラグがtrueでないと判定した場合（S801でNOの場合）、ジョブ履歴送信スレッド504は、処理をS802に進める。
S802において、ジョブ履歴送信スレッド504は、現在の日時を最新稼働日時として記憶する。最新稼働日時は、ジョブ履歴送信スレッド504が保持する変数であり、監視スレッド505によって参照される。
【００６８】
次にS803において、ジョブ履歴送信スレッド504は、ジョブ履歴記憶部408にジョブ履歴がある、且つ、現在の時刻がエージェント情報管理部403に保持されている送信時間帯であるか否かを判定する。送信時間帯は、ジョブ履歴をジョブ履歴処理サーバ102に送信する時間帯であり、ネットワークやジョブ履歴処理サーバ102の負荷が集中しないようにするための設定である。送信時間帯は、エージェントＵＩ画面もしくはサーバＵＩ画面で設定できるものとする。
【００６９】
上記S803において、ジョブ履歴記憶部408にジョブ履歴がない、又は、現在の時刻が送信時間帯ではないと判定した場合（S803でNOの場合）、ジョブ履歴送信スレッド504は、処理をS804に進める。
【００７０】
S804において、ジョブ履歴送信スレッド504は、上記S801と同様に、自身が持つ停止要求フラグがtrueか否かを判定する。本ステップは、S801の後で、停止要求を受けた場合に備えるものである。停止要求フラグがtrueであると判定した場合（S804でYESの場合）、ジョブ履歴送信スレッド504は、自身の動作を終了する。
【００７１】
一方、上記S804において、停止要求フラグがtrueでないと判定した場合（S804でNOの場合）、ジョブ履歴送信スレッド504は、処理をS805に進める。
S805において、ジョブ履歴送信スレッド504は、予め設定された送信開始確認間隔時間（例えば1分）スリープし、処理をS801に戻す。なお、上記S805のスリープ中に他のスレッドから割り込みがあった場合、ジョブ履歴送信スレッド504は、スリープを解除して直ちに処理をS801に戻す。
【００７２】
また、上記S803において、ジョブ履歴記憶部408にジョブ履歴があり、且つ、現在の時刻が送信時間帯であると判定した場合（S803でYESの場合）、ジョブ履歴送信スレッド504は、処理をS806に進める。
S806において、ジョブ履歴送信スレッド504は、ジョブ履歴記憶部408にあるジョブ履歴を一つ選択し、S807に処理を進める。
【００７３】
S807において、ジョブ履歴送信スレッド504は、上記S806で選択したジョブ履歴全体の送信が完了したかどうか判定する。これは、ジョブ履歴を予め定められたサイズで分割して送信を行うためである。選択したジョブ履歴全体の送信が完了していないと判定した場合（S808でNOの場合）、ジョブ履歴送信スレッド504は、処理をS808に進める。
S808において、ジョブ履歴送信スレッド504は、上記S802と同様に、最新稼働日時を現在の日時で更新する。
【００７４】
次にS809において、ジョブ履歴送信スレッド504は、予め設定された分割サイズ分だけジョブ履歴を送信する。このとき、既に送信済みの部分があれば読み飛ばし、未送信部分の先頭から分割サイズ分が送信対象となるようにする。また、分割サイズは、送信に時間が掛かり過ぎないサイズ（例えば２メガバイト）に設定されているものとする。送信後、ジョブ履歴送信スレッド504は、上記S807での判定もしくは次の分割サイズ分の送信のために、送信済みのデータサイズを記憶しておくものとする。そして、ジョブ履歴送信スレッド504は、処理をS807に戻す。
【００７５】
また、上記S807において、選択したジョブ履歴全体の送信が完了したと判定した場合（S807でYESの場合）、ジョブ履歴送信スレッド504は、処理をS810に進める。
S810において、ジョブ履歴送信スレッド504は、送信が完了したジョブ履歴をジョブ履歴記憶部408から削除し、処理をS801に戻す。
【００７６】
以上のようにして、ジョブ履歴送信スレッド504は、送信時間帯且つジョブ履歴が存在する場合には、ジョブ履歴を一つずつ分割しながら送信する。また、ジョブ履歴送信スレッド504は、スレッドが正常に動作している場合には、送信開始確認間隔時間毎もしくはジョブ履歴の分割送信毎に、最新稼働日時を更新する。
【００７７】
図９は、実施例１における監視スレッド505の動作の一例を示すフローチャートである。
S901において、監視スレッド505は、自身が持つ停止要求フラグがtrueか否かを判定する。停止要求フラグの初期値はfalseであり、自分自身もしくは他のスレッドから停止要求を受けた場合にtrueとなる。
上記S901において、停止要求フラグがtrueであると判定した場合（S901でYESの場合）、監視スレッド505は、自身の動作を終了する。
【００７８】
一方、上記S901において、停止要求フラグがtrueでないと判定した場合（S901でNOの場合）、監視スレッド505は、処理をS902に進める。
【００７９】
S902において、監視スレッド505は、ジョブ履歴送信スレッド504の最新稼働日時を参照し、タイムアウトしているかどうかを判定する。タイムアウトかどうかの閾値（タイムアウト閾値）は予め設定されているものとし、ジョブ履歴送信スレッド504が最新稼働日時を更新する頻度を考慮して誤検知となりにくい値（例えば６０分）を設定する。タイムアウトの判定は、現在日時と最新稼働日時との差がタイムアウト閾値以上かどうかで行う。例えば、ジョブ履歴送信スレッド504がジョブ履歴処理サーバ102へのデータ送信中にハングアップ等の異常が発生してデータ送信の停止又は遅延が発生した場合、最新稼働日時が更新されないため、タイムアウトとなる。即ち、タイムアウトの発生を検出することにより、ジョブ履歴送信スレッド504の異常を検出することができる。ジョブ履歴送信スレッド504で異常が発生した場合、ジョブ履歴がＭＦＰ101上に溜まり、ジョブ履歴記憶部408で保持可能な上限を超えてしまい（ディスクフル）、未送信のジョブ履歴が削除されてしまう可能性がある。なお、ハングアップ等のジョブ履歴送信スレッド504の異常は、ＭＦＰ101を再起動させることにより解消する可能性が高い。
【００８０】
上記S902において、タイムアウトしていないと判定した場合（S902でNOの場合）、監視スレッド505は、処理をS903に進める。
S903において、監視スレッド505は、上記S901と同様に、自身が持つ停止要求フラグがtrueか否かを判定する。本ステップは、S901の後で、停止要求を受けた場合に備えるものである。
上記S903において、停止要求フラグがtrueであると判定した場合（S903でYESの場合）、監視スレッド505は、自身の動作を終了する。
【００８１】
一方、上記S903において、停止要求フラグがtrueでないと判定した場合（S903でNOの場合）、監視スレッド505は、処理をS904に進める。
S904において、監視スレッド505は、予め設定された監視間隔時間（例えば３０分）スリープし、処理をS901に戻す。なお、上記S904のスリープ中に他のスレッドから割り込みがあった場合、監視スレッド505は、スリープを解除して直ちに処理をS901に戻す。
【００８２】
また、上記S902において、タイムアウトしていると判定した場合（S902でYESの場合）、監視スレッド505は、ジョブ履歴送信スレッド504の異常を検知したと判断し、処理をS905に進める。
【００８３】
S905において、監視スレッド505は、エージェント情報管理部403で管理しているステータスに「内部エラー」及び「デバイス再起動待ち」を設定する。ここで、「内部エラー」とは、通常、エージェント400がジョブ履歴記憶部408からジョブ履歴を取得できないといったようなエージェント400内でのエラーを表すステータスである。また、「デバイス再起動待ち」は、通常、ＭＦＰ101の再起動が必要となるような設定変更をエージェント400で行ったことを表すステータスである。本実施例において、監視スレッド505は、ジョブ履歴送信スレッド504の最新稼働日時がタイムアウトした場合に、これらのステータスを設定することで、ジョブ履歴送信スレッド504の異常を表すものとする。なお、ジョブ履歴送信スレッド504の異常を表す専用のステータスを設けてもよい。
【００８４】
次にS906において、監視スレッド505は、ステータス確認スレッド502にジョブ履歴処理サーバ102へのステータス通知をさせるため、ステータス確認スレッド502に割り込みを行う。これにより、ステータス確認スレッド502は、図６のS603でのスリープを解除し、ステータス確認間隔が経過するのを待つことなく、図６のS606でステータス通知を行うことになる。
【００８５】
次にS907において、監視スレッド505は、ステータス確認スレッド502が持つ停止要求フラグをtrueに設定し、ステータス確認スレッド502に割り込みを行う。これにより、ステータス確認スレッド502は、図６のS603でのスリープを解除し、ステータス確認間隔が経過するのを待つことなく、図６のS601もしくはS604の判定がYESとなり、終了することになる。
【００８６】
次にS908において、監視スレッド505は、設定情報取得スレッド503が持つ停止要求フラグをtrueに設定し、設定情報取得スレッド503に割り込みを行う。これにより、設定情報取得スレッド503は、図７のS705でのスリープを解除し、設定情報取得間隔が経過するのを待つことなく、図７のS701もしくはS704の判定がYESとなり、終了することになる。
【００８７】
次にS909において、監視スレッド505は、自身が持つ停止要求フラグをtrueにし、処理をS901に戻す。これにより、監視スレッド505は、上記S901の判定がYESとなり、終了することになる。
【００８８】
以上のようにして、監視スレッド505は、ジョブ履歴送信スレッド504による最新稼働日時の更新が滞った場合に、それを異常としてジョブ履歴処理サーバ102に知らせるステータス通知を行うと共に、他のスレッドを停止させる。
【００８９】
次に、監視スレッド505が異常を検知したことに伴うジョブ履歴処理サーバ102の動作について説明する。
図１０Ａ〜図１０Ｄは、いずれもジョブ履歴処理サーバ102のサーバＵＩ部412が表示する画面の一例を示す図である。
【００９０】
図１０Ａは、エージェントの一覧を示すエージェント一覧画面である。
図１０Ａの例では、1001に示すエージェント（以下「エージェント１」）と、1002に示すエージェント（以下「エージェント２」）を一覧で表示している。
【００９１】
本実施例のエージェント一覧画面では、図１０Ａに示すように、エージェントＩＤ、エージェント名、ステータスを一覧で表示する。なお、エージェント一覧画面で表示されるステータスは、ステータスの概要であり、例えば「稼働中」、「停止中」、「不明」の３通りがあるものとする。ただし、エージェント一覧画面における表示内容はこれに限るものではなく、ステータスに関しても詳細な表示をするようにしてもよい。
【００９２】
エージェント400の設定情報取得スレッド503による設定情報取得要求を、ジョブ履歴処理サーバ102の要求処理部411が定期的に受信しているとき、ジョブ履歴処理サーバ102は、そのエージェントのステータスを「稼働中」とする。
【００９３】
一方、エージェントからの設定情報取得要求の受信が途絶えた場合、ジョブ履歴処理サーバ102は、そのエージェントのステータスを「不明」に変える。なお、ジョブ履歴処理サーバ102が「不明」のステータスに変える判断の詳細については後述する。また、ＭＦＰ101がシャットダウンされ、エージェント400が停止する際に、エージェント400のステータス確認スレッド502から「停止」のステータス通知を受信すると、ジョブ履歴処理サーバ102は、そのエージェントのステータスを「停止中」に変える。
【００９４】
また、図１０Ａのエージェント一覧画面において、1011は、後述するエージェントプロパティー画面を開くためのプロパティーアイコンである。また、1012は、エージェントでの異常の有無を示すステータスアイコンである。
【００９５】
本実施例において、ステータスアイコン1012は、当該エージェントの異常の有無を色によって表示する。例えば、ステータスアイコン1012は、異常を示すステータスが通知されていない場合は緑色、異常を示すステータスが通知されているかステータスが「不明」の場合は赤色で表示されるものとする。なお、ステータスアイコン1012の表示には、他の色を使用してもよいし、アイコンの形状自体を変えるなどしてもよい。即ち、ステータスに応じて、ステータスアイコン1012の表示形態を変更するものとする。
【００９６】
例えば、エージェント１は異常がなく正常に稼働しているものとする。このとき、エージェント１のステータスアイコン1012は緑色となる。
一方、エージェント２は、監視スレッド505が異常を検知して、「内部エラー」及び「デバイス再起動待ち」のステータスが、ジョブ履歴処理サーバ102に通知されたものとする。このとき、要求処理部411の制御により、エージェント２のステータスアイコン1012は赤色となる。これにより、システム管理者はエージェント２の異常に気付くことができる。ここで、システム管理者は、エージェント２のプロパティーアイコン1011を押下することにより、図１０Ｂのエージェントプロパティー画面を表示させ、ステータスの詳細を確認することができる。
【００９７】
図１０Ｂのエージェントプロパティー画面は、ステータスの詳細を確認するほかに、エージェントの詳細な設定値を確認・設定することができる画面である。
図１０Ｂにおいて、1021は、エージェント２の詳細なステータスであり、異常を示すステータスである「内部エラー」及び「デバイス再起動待ち」のステータスが通知されていることを示している。
【００９８】
図１０Ｃは、図１０Ａと同じエージェント一覧画面において、エージェント２のステータスが「不明」であることを示している画面である。ステータスが「不明」とは、エージェント400からの定期的なアクセス（本実施例では、設定情報取得要求）が一定時間以上途絶えた状態のことである。ジョブ履歴処理サーバ102が、エージェント400のステータスを「不明」とする動作について以下で説明する。
【００９９】
要求処理部411は、エージェント400から設定情報取得要求を受信すると、システム情報管理部417でエージェント毎に管理している最終アクセス日時を受信時の日時で更新する。
【０１００】
一方、エージェント不明検知部415が、予め設定された間隔（例えば、設定情報取得間隔と同じ５分）で各エージェントの最終アクセス日時をチェックする。そして、現在日時と最終アクセス日時との差が、予め設定された不明検知閾値（例えば１５分）以上になっている場合、エージェント不明検知部415は、システム情報管理部417で管理している当該エージェントのステータスを「不明」に設定する。
【０１０１】
一旦「不明」となったエージェントのステータスは、次に、設定情報取得要求を受信した際に、要求処理部411によってクリアされ、「稼働中」に変わるものとする。なお、ステータス通知など、設定情報取得要求以外の通信を受信した際に「不明」ステータスをクリアするようにしてもよい。
【０１０２】
図１０Ｄは、図１０Ｃにおいてエージェント２のプロパティーアイコン1011が押下されることで表示されるエージェント２のエージェントプロパティー画面である。ステータスが「不明」の場合、1041に示すように、ステータスの詳細には「不明」のみを表示する。なお、ステータスが「不明」になる前に受信していた「内部エラー」や「デバイス再起動待ち」のステータスも一緒に表示するようにしてもよい。
【０１０３】
以上の動作により、エージェント２において、監視スレッド505が異常を検知しステータス通知が行われると、ジョブ履歴処理サーバ102のサーバＵＩ部412は、まず図１０Ａおよび図１０Ｂの画面を表示する。これにより、エージェントのステータスが「不明」と検知されるよりも前に、システム管理者は、エージェント２に再起動すべき問題が発生していることを知ることができる。
【０１０４】
一方、もしステータス通知に異常があり、ジョブ履歴処理サーバ102がステータス通知を受信できなかったとしても、エージェント400の各スレッドが終了されたことによって設定情報取得要求等が受信できなくなる。このため、エージェント不明検知部415の動作により、エージェント２のステータスはやがて「不明」となる。このとき、サーバＵＩ部412は、図１０Ｃ及び図１０Ｄの画面を表示するため、ステータス通知に異常があったとしても、システム管理者は、エージェント400に何か問題が発生していることを知ることができる。
【０１０５】
以上のように、実施例１では、クライアント装置（例えばＭＦＰ101）において検知された異常をサーバ装置（ジョブ履歴処理サーバ102）へ通知しつつ、その通知がサーバ装置で受信されなかったとしても、サーバ装置側で異常を検知させる構成を有する。この構成により、より確実にシステム管理者に異常を知らせることができる。また、これによって、システム管理者にクライアント装置の再起動等の対応を促すことができる。
【０１０６】
なお、エージェントの状態が不明であることが検知された際に、メール通知部413からそのエージェントの状態が不明である旨の内容を含むメールの送信を行うことで、システム管理者に、より早く異常を知らせるようにしてもよい。ここで、エージェントの送信スレッドによるデータ送信の停止又は遅延による異常検出に応じた異常判定時については、エージェントは未だ稼働中であるため、メール通知部413からのシステム管理者へのメール送信を抑制することも考えられる。
また、エージェント400から「内部エラー」および「デバイス再起動待ち」のステータス通知を受信している場合、当該エージェントに対するエージェント不明の検知を止めるなどして、ステータスを「不明」にしないようにしてもよい。
【実施例２】
【０１０７】
実施例２では、エージェント400の監視スレッド505が異常を検知した際に、エージェントＵＩ部402でもその異常を表示する構成を有する。なお、実施例２において、実施例１と重複する部分の説明は省略し、差分のみを説明する。
【０１０８】
図１１は、実施例２における監視スレッド505の動作の一例を示すフローチャートであり、図９と同一のステップには同一のステップ番号を付してある。図１１に示す各ステップは、ＭＦＰ101のＣＰＵ201が、ＲＯＭ203またはＨＤＤ204に記憶されているエージェント400を実現するプログラムを実行することで実現される。また、ＣＰＵ201は、必要に応じて記憶領域としてＲＡＭ202やＨＤＤ204を利用する。
【０１０９】
なお、図１１は、実施例１の図９のフローチャートとは、S908の後にS1101が追加されているところだけが異なるため、S1101についてのみ説明する。
【０１１０】
実施例２の監視スレッド505は、S908の処理の後、S1101に処理を進める。
S1101において、監視スレッド505は、エージェントＵＩ部402が参照可能な、メインスレッドが持つタイムアウト表示フラグ（初期値はfalse）をtrueにする。タイムアウト表示フラグがtrueの場合、エージェントＵＩ部402は図１２の画面を表示し、異常を知らせるようにする。
また、実施例２の監視スレッド505は、S1011の処理の後、S909に処理を進める。
【０１１１】
図１２は、エージェント400のエージェントＵＩ部402が表示するエラー表示画面である。
エラー表示画面において表示するメッセージ1201は、エラーの内容により様々であるが、タイムアウト表示フラグがtrueになっている場合には、図１２に示すメッセージ「内部エラーが発生しました。デバイスを再起動してください。」を表示する。この表示により、エージェントＵＩ部402の画面を表示させたシステム管理者に対して、エージェントの異常を知らせ、デバイスの再起動を促すことができる。
【０１１２】
ＯＫボタン1202は、タイムアウト表示フラグがtrueでない場合のエラー表示の場合に、エラー表示画面から他の画面に表示を切り替えさせるためのボタンである。ただし、タイムアウト表示フラグがtrueの場合、つまり図１２の画面が表示されている場合に、ＯＫボタン1202が押下されると、エージェントＵＩ部402は、再度、図１２の画面を表示するものとする。これは、再起動が必要なことを強調するためである。
【０１１３】
以上のように、実施例２では、エージェントＵＩ部402での画面表示によって、より確実にシステム管理者に再起動を促すことができる。
【実施例３】
【０１１４】
実施例３は、エージェント400の監視スレッド505が複数のスレッドを監視対象にしてタイムアウトを検知し、異常を知らせる構成を有する。なお、本実施例において、実施例１および実施例２と重複する部分の説明は省略し、差分のみを説明する。
また、実施例３のジョブ履歴処理システム100は、ジョブ履歴に加えてＭＦＰ101の設定変更等の操作履歴も記録して、ジョブ履歴処理サーバ102に保管するものとする。
【０１１５】
図１３は、実施例３のジョブ履歴処理システム100のソフトウェア構成の一例を示すブロック図である。ただし、ジョブ履歴処理サーバ102上のソフトウェアブロックは、実施例１の図４と同一であるため省略している。また、ＭＦＰ101上のソフトウェアブロックに関して、図４と同一のものには同一の符号を付してあり、操作履歴記憶部1301が追加されている点のみが図４と異なる。
【０１１６】
操作履歴記憶部1301は、ＭＦＰ101で実行されるジョブ以外の、ＭＦＰ101の設定変更等の操作の操作履歴を記憶するＨＤＤ204上の領域である。
【０１１７】
図１４は、実施例３におけるエージェント制御部401が実行するスレッドの一例を示す図である。図１４では、実施例１の図５と同一のものには同一の符号を付してあり、操作履歴送信スレッド1401が追加されている点だけが図５と異なる。
【０１１８】
操作履歴送信スレッド1401は、ジョブ履歴送信スレッド504と同様に、予め設定された間隔で、操作履歴記憶部1301に操作履歴が未送信の操作履歴があるかどうかを確認する。未送信の操作履歴がある場合には、操作履歴送信スレッド1401は、未送信の操作履歴をジョブ履歴処理サーバ102の要求処理部411に送信し、送信した操作履歴は、操作履歴記憶部1301から削除する。なお、本実施例の操作履歴送信スレッド1401の動作は、実施例１の図８に示すジョブ履歴送信スレッド504のフローチャートにおいて、ジョブ履歴が操作履歴に変わるだけであるため、その図示及び詳細な説明は省略する。
【０１１９】
図１５は、実施例３における監視スレッド505の動作の一例を示すフローチャートであり、図１１と同一のステップには同一のステップ番号を付してある。図１５に示す各ステップは、ＭＦＰ101のＣＰＵ201が、ＲＯＭ203またはＨＤＤ204に記憶されているエージェント400を実現するプログラムを実行することで実現される。また、ＣＰＵ201は、必要に応じて記憶領域としてＲＡＭ202やＨＤＤ204を利用する。
【０１２０】
なお、図１５のフローチャートは、図１１において、S902の後にS1501〜Ｓ1504が追加されている点と、S908の後にS1505〜Ｓ1508が追加されている点が図１１と異なる。以下ではこれらのステップについて説明する。
【０１２１】
実施例３の監視スレッド505は、S902でタイムアウトしていると判定した場合（S902でYESの場合）、ジョブ履歴送信スレッド504の異常を検知したと判断し、処理をS1501に進める。
【０１２２】
S1501において、監視スレッド505は、自身が持つジョブ履歴送信スレッドタイムアウトフラグをtrueにし、処理をS1502に進める。ここで、ジョブ履歴送信スレッドタイムアウトフラグは、初期値がfalseであり、trueの場合、ジョブ履歴送信スレッド504がタイムアウトしたことを表す。
【０１２３】
また、実施例３の監視スレッド505は、S902でタイムアウトしていないと判定した場合（S902でNOの場合）、処理をS1502に進める。
【０１２４】
S1502において、監視スレッド505は、上記S902と同様に、操作履歴送信スレッド1401の最新稼働日時を参照し、タイムアウトしているかどうかを判定する。タイムアウトしていると判定した場合（S1502でYESの場合）、監視スレッド505は、操作履歴送信スレッド1401の異常を検知したと判断し、処理をS1503に進める。
【０１２５】
S1503において、監視スレッド505は、自身が持つ操作履歴送信スレッドタイムアウトフラグをtrueにし、処理をS1504に進める。ここで、操作履歴送信スレッドタイムアウトフラグは、初期値がfalseであり、trueの場合、操作履歴送信スレッド1401がタイムアウトしたことを表す。
また、S1502でタイムアウトしていないと判定した場合（S1502でNOの場合）、処理をS1504に進める。
【０１２６】
S1504において、監視スレッド505は、自身が持つジョブ履歴送信スレッドタイムアウトフラグと操作履歴送信スレッドタイムアウトフラグとのどちらかがtrueになっているかどうかを判定する。少なくともどちらかがtrueであると判定した場合（S1504でYESの場合）、監視スレッド505は、処理をS905に進める。一方、どちらもtrueでないと判定した場合（S1504でNOの場合）、監視スレッド505は、処理をS903に進める。
【０１２７】
また、実施例３の監視スレッド505は、S908の処理の後、処理をS1505に進める。
S1505において、監視スレッド505は、自身が持つジョブ履歴送信スレッドタイムアウトフラグがtrueであるか否か判定する。trueでないと判定した場合（S1505でNOの場合）、監視スレッド505は、処理をS1506に進める。
【０１２８】
S1506において、監視スレッド505は、ジョブ履歴送信スレッド504が正常に稼働中とみなし、ジョブ履歴送信スレッド504が持つ停止要求フラグをtrueに設定し、ジョブ履歴送信スレッド504に割り込みを行う。これにより、ジョブ履歴送信スレッド504は、図８のS805でのスリープを解除し、送信開始確認間隔時間が経過するのを待つことなく、図８のS801もしくはS804の判定がYESとなり、終了することになる。
S1506の処理の後、監視スレッド505は、処理をS1507に進める。
【０１２９】
上記S1505において、監視スレッド505は、自身が持つジョブ履歴送信スレッドタイムアウトフラグがtrueであると判定した場合（S1505でYESの場合）、監視スレッド505は、処理をS1507に進める。
【０１３０】
S1507において、監視スレッド505は、自身が持つ操作履歴送信スレッドタイムアウトフラグがtrueであるか否か判定する。trueでないと判定した場合（S1507でNOの場合）、監視スレッド505は、処理をS1508に進める。
【０１３１】
S1508において、監視スレッド505は、操作履歴送信スレッド1401が正常に稼働中とみなし、操作履歴送信スレッド1401が持つ停止要求フラグをtrueに設定し、操作履歴送信スレッド1401に割り込みを行う。これにより、操作履歴送信スレッド1401は、ジョブ履歴送信スレッド504と同様に、送信開始確認間隔時間が経過するのを待つことなく、終了することになる。
S1508の処理の後、監視スレッド505は、処理をS1101に進める。
【０１３２】
上記S1507において、監視スレッド505は、自身が持つ操作履歴送信スレッドタイムアウトフラグがtrueであると判定した場合（S1507でYESの場合）、監視スレッド505は、処理をS1101に進める。
【０１３３】
以上のように、実施例３では、ジョブ履歴送信スレッド504に加え、操作履歴送信スレッド1401のタイムアウトも監視して、どちらかのタイムアウトを検知した場合にデバイスの再起動を促すことができる。なお、同様な方法で、ステータス確認スレッド502や設定情報取得スレッド503のタイムアウトをも監視するようにしてもよい。
【０１３４】
なお、上記各実施例では、エージェント不明を検知するための仕組みで、デバイスの異常が管理者に伝わるので、新しいエラーを、エージェントとジョブ履歴処理サーバとの間で新たに定義する必要がない。このため、エージェントのみの仕様変更で対応することも可能である。
【０１３５】
以上のように、本発明の各実施例は、ＭＦＰ等のクライアント装置において検知された異常をサーバ装置へ通知しつつ、その通知がサーバ装置で受信されなかったとしても、サーバ装置側で異常を検知させる構成を有する。これにより、より確実にシステム管理者にデバイス側の異常を知らせることができる。また、これによって、システム管理者にクライアント装置の再起動等の対応を促すことができる。
【０１３６】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用してもよい。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【０１３７】
（その他の実施例）
本発明は、上述の実施例の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図１】
2019028593.tif 000003
【図２】
2019028593.tif 000004
【図３】
2019028593.tif 000005
【図４】
2019028593.tif 000006
【図５】
2019028593.tif 000007
【図６】
2019028593.tif 000008
【図７】
2019028593.tif 000009
【図８】
2019028593.tif 000010
【図９】
2019028593.tif 000011
【図１０Ａ】
2019028593.tif 000012
【図１０Ｂ】
2019028593.tif 000013
【図１０Ｃ】
2019028593.tif 000014
【図１０Ｄ】
2019028593.tif 000015
【図１１】
2019028593.tif 000016
【図１２】
2019028593.tif 000017
【図１３】
2019028593.tif 000018
【図１４】
2019028593.tif 000019
【図１５】
2019028593.tif 000020