JP2015118685A - 情報処理システム、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】機器から取得される情報に基づいて把握される機器の稼動状態の妥当性を向上させること。
【解決手段】一以上のコンピュータを含む情報処理は、機器の稼動状態を示す稼動情報を、所定の間隔で前記機器からネットワークを介して受信する受信部と、前記受信部によって受信された稼動情報を記憶する第一の記憶部と、稼動状態が異常を示す稼動情報が受信された前記機器について、前記異常の解消を示す解消情報の入力を、前記所定の間隔とは非同期に受け付ける受付部と、稼動状態が異常を示す稼動情報が受信されてから次の稼動情報が受信されるまでの期間において、前記受付部が前記解消情報を受け付けた場合に、当該稼動情報が示す異常が当該稼動情報の受信から当該解消情報の受け付けまで継続したことを示す情報を前記第一の記憶部に追加する追加部とを有する。
【選択図】図３

Description

本発明は、情報処理システム、情報処理方法、及びプログラムに関する。

複合機、複写機、スキャナ、又はプリンタ、ファクシミリ、カメラ等に代表される画像形成装置等の機器ベンダと、顧客との間で、機器の正常稼動を保証するためのＳＬＡ（Service Level Agreement）が締結される場合が有る。ＳＬＡにおいては、例えば、稼働率を指標として、機器の正常稼動に関する保証内容が定義される。

ＳＬＡを履行するための手段として、ネットワークを介して機器の状態を遠隔監視するシステム（以下、「機器管理システム」という。）を利用することが考えられる。すなわち、機器管理システムによって、早期に障害を検知し、迅速に障害対応を行うことで、稼働率の向上が期待できる。

しかしながら、機器管理システムにおいて機器の異常が検出されたとしても、機器管理システムによって機器から取得される情報に基づいて、当該異常の継続期間を特定するのは適切でない場合がある。

例えば、機器管理システムが、一定の間隔で定期的に機器から情報を取得する場合、或る時点において検出された異常の解消の検出は、早くとも当該時点から一定の間隔経過後になる。仮に、当該間隔内において、異常が解消された場合、異常の継続期間が実際より長く評価される可能性が有る。

本発明は、上記の点に鑑みてなされたものであって、機器から取得される情報に基づいて把握される機器の稼動状態の妥当性を向上させることを目的とする。

そこで上記課題を解決するため、一以上のコンピュータを含む情報処理は、機器の稼動状態を示す稼動情報を、所定の間隔で前記機器からネットワークを介して受信する受信部と、前記受信部によって受信された稼動情報を記憶する第一の記憶部と、稼動状態が異常を示す稼動情報が受信された前記機器について、前記異常の解消を示す解消情報の入力を、前記所定の間隔とは非同期に受け付ける受付部と、稼動状態が異常を示す稼動情報が受信されてから次の稼動情報が受信されるまでの期間において、前記受付部が前記解消情報を受け付けた場合に、当該稼動情報が示す異常が当該稼動情報の受信から当該解消情報の受け付けまで継続したことを示す情報を前記第一の記憶部に追加する追加部とを有する。

機器について算出される稼働率の妥当性を向上させることができる。

本発明の実施の形態における情報処理システムの構成例を示す図である。 本発明の実施の形態における機器管理装置のハードウェア構成例を示す図である。 本発明の実施の形態における情報処理システムのシステム構成例を示す図である。 機器管理装置と資産管理装置との間で実行される処理手順の一例を説明するためのシーケンス図である。 機器状態履歴記憶部の構成例を示す図である。 資産情報の検索結果の第一の例を示す図である。 保守状態の判定処理の処理手順の一例を説明するためのフローチャートである。 機器状態履歴記憶部に対する資産状態及び保守状態の第一の記憶例を示す図である。 資産情報の検索結果の第二の例を示す図である。 機器状態履歴記憶部に対する資産状態及び保守状態の第二の記憶例を示す図である。 本実施の形態を適用した場合と適用しない場合との保守状態の違いを示す第一の図である。 資産情報の確認要否判定処理の処理手順の一例を説明するためのフローチャートである。 許容期間記憶部の構成例を示す図である。 確認要求の出力処理の処理手順の一例を説明するためのフローチャートである。 出力条件記憶部の構成例を示す図である。 機器の異常状態の発生時において機器管理装置とインシデント管理装置との間で実行される処理手順の一例を説明するための図である。 機器の異常状態の解消時において機器管理装置とインシデント管理装置との間で実行される処理手順の一例を説明するための図である。 異常解消情報に基づく機器状態履歴記憶部へのレコードの追加例を示す図である。 本実施の形態を適用した場合と適用しない場合との保守状態の違いを示す第二の図である。 機能維持作業の開始時において機器管理装置とインシデント管理装置との間で実行される処理手順の一例を説明するための図である。 機能維持作業の開始及び終了に基づく機器状態履歴記憶部へのレコードの追加例を示す図である。 保守状態の判定処理の処理手順の第二の例を説明するためのフローチャートである。 本実施の形態を適用した場合と適用しない場合との保守状態の違いを示す第三の図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における情報処理システムの構成例を示す図である。図１において、機器管理装置１０、資産管理装置２０、インシデント管理装置３０、複数の機器４０、及びクライアント装置５０等は、ＬＡＮ（Local Area Network）又はＷＡＮ（Wide Area Network）等のネットワーク６０を介して接続されている。

機器４０は、例えば、複合機、複写機、スキャナ、又はプリンタ等の画像形成装置である。但し、機器４０は、プロジェクタ、電子黒板、テレビ会議システム、又はデジタルカメラ等、画像形成装置以外の電子機器であってもよい。

機器管理装置１０は、機器４０の稼働状態を遠隔的に監視する一以上のコンピュータである。例えば、機器管理装置１０は、繰り返し（例えば、一定の間隔で定期的に）、機器４０の稼働状態を示す情報（以下、「稼動情報」という。）等を含む、機器４０ごとの情報（以下、「機器情報」という。）を各機器４０より収集する。稼動情報には、機器４０において故障又は消耗品の枯渇等の異常を示す情報や、機器４０のカウンタ等、機器４０の利用に応じて変化する属性情報等が含まれる。なお、カウンタとは、例えば、印刷又はスキャン等に応じて加算され、計測対象ごとに設けられるパラメータ又は属性項目をいう。

本実施の形態において、機器４０の稼動状態について正常な状態とは、例えば、機器４０の本来の性能又は機能を正常に利用可能な状態をいう。機器４０の稼動状態について異常な状態とは、例えば、機器４０の本来の性能又は機能を得られない状態をいう。トナー切れや用紙切れ等、消耗品が枯渇した状態も、異常な状態に含まれる。なお、稼動状態について、どのような状態を正常又は異常とするかは、機器４０のベンダ又は保守業者と、機器４０のユーザ（顧客）との間におけるＳＬＡ（Service Level Agreement）等の契約において定義されてもよい。

稼動状態が正常である期間は、機器４０の稼働率の算出において、平均故障間隔（ＭＴＢＦ（Mean Time Between Failure））に含められる。一方、機器４０の稼動状態が異常である期間は、機器４０の稼働率の算出において、平均修復時間（ＭＴＴＲ（Mean Time To Repair））に含められる。

なお、本実施の形態では、以下の式（１）を、便宜上、稼働率の計算式とする。

稼働率＝ＭＴＢＦ÷（ＭＴＢＦ＋ＭＴＴＲ） ・・・（１）
但し、稼働率の計算式についてもＳＬＡ（Service Level Agreement）等の契約において定義されてもよい。

資産管理装置２０は、各機器４０の資産情報を管理するコンピュータである。資産情報は、例えば、一般的な資産管理において必要とされる情報である。本実施の形態では、機器４０の属性情報の他に、機器４０の資産としての状態（以下、「資産状態」という。）を示す情報が資産情報に含まれる。機器４０の資産状態とは、資産管理におけるライフサイクルを構成する状態をいう。本実施の形態においては、資産状態として、受領状態、在庫状態、配置状態、運用状態、移動状態、及び廃棄状態等が有ることとする。受領状態は、機器４０を受領した状態である。在庫状態は、機器４０の受領が完了し、在庫として管理されている状態である。配置状態は、機器４０の配置作業が行われている状態である。運用状態は、機器４０が運用されている状態である。移動状態は、機器４０の配置位置の移動作業が行われている状態である。廃棄状態は、機器４０が廃棄された状態である。この中で、ユーザが機器４０を利用可能な状態は、運用状態である。なお、資産状態の種類は、資産管理装置２０のユーザによって、任意に定義されてもよい。

インシデント管理装置３０は、機器４０のインシデントに関する情報（以下、「インシデント情報」という。）を管理するコンピュータである。インシデントとは、例えば、ユーザが機器４０の機能を有効に利用できない状態をいう。本実施の形態において、インシデントは、機器４０の稼動状態における異常状態を含む概念である。例えば、カスタマエンジニア等は、インシデント管理装置３０が管理するインシデント情報に基づいて、障害対応等の作業を実施する。インシデント情報は、機器４０の異常状態を示す稼動情報や、当該異常状態の解消を示す情報等を含む。

なお、インシデントは、資産管理の運用状態において発生する事象である。すなわち、インシデントとは、資産状態としては、機器４０を正常に利用できる状態であるにも拘わらず、機器４０を正常に利用できない状態をいう。したがって、資産状態とインシデントとは、機器４０の状態として相互に異なるレイヤに属する概念であるといえる。

クライアント装置５０は、機器管理装置１０や資産管理装置２０に対するユーザインタフェースとして機能する情報処理装置である。すなわち、ユーザは、クライアント装置５０を介して、機器管理装置１０、資産管理装置２０、又はインシデント管理装置３０に対する要求を入力する。クライアント装置５０の一例として、ＰＣ（Personal Computer）、タブレット型端末、スマートフォン、又は携帯電話等が挙げられる。

図２は、本発明の実施の形態における機器管理装置のハードウェア構成例を示す図である。図２の機器管理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

機器管理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って機器管理装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、機器管理装置１０は、一以上のコンピュータによって構成されてもよい。また、資産管理装置２０及びインシデント管理装置３０のそれぞれについても、図２に示されるようなハードウェアを有していてもよいし、一以上のコンピュータによって構成されてもよい。更に、機器管理装置１０、資産管理装置２０、及びインシデント管理装置３０は、一又は複数の同一のコンピュータを用いて実現されてもよい。

図３は、本発明の実施の形態における情報処理システムのシステム構成例を示す図である。図１に示される情報処理システム１において、機器管理装置１０は、機器情報収集部１１、資産情報取得部１２、保守状態判定部１３、異常情報送信部１４、及びインシデント情報受信部１５等を有する。これら各部は、機器管理装置１０にインストールされたプログラムが、ＣＰＵ１０４に実行させる処理により実現される。機器管理装置１０は、また、機器状態履歴記憶部１６を利用する。機器状態履歴記憶部１６は、例えば、補助記憶装置１０２、又は機器管理装置１０にネットワークを介して接続する記憶装置等を用いて実現可能である。

機器情報収集部１１は、管理対象として登録されている各機器４０から、機器情報を収集（受信）する。機器情報の収集は、機器情報収集部１１から各機器４０に対して繰り返し（定期的に）機器情報の取得要求を送信することにより行わる。また、機器４０に異常等が発生した場合は、当該機器４０が、機器情報を能動的に機器情報収集部１１に送信してもよい。機器情報収集部１１は、収集又は受信された機器情報のうちの稼動情報を、機器状態履歴記憶部１６に記憶する。

資産情報取得部１２は、機器情報が収集された機器４０に関する資産情報を、資産管理装置２０から取得する。

保守状態判定部１３は、機器情報が収集された各機器４０について、資産情報取得部１２によって取得された資産情報が示す資産状態に基づいて、ＳＬＡ等の契約に基づく保守責任の有無という観点からの機器４０の状態（以下、「保守状態」という。）を判定する。保守状態は、正常（保守対象）、異常（保守対象）、正常（保守対象外）、異常（保守対象外）に分類される。正常（保守対象）は、稼動状態が正常であり、資産状態が保守責任の有る状態である状態をいう。異常（保守対象）は、稼動状態が異常であり、資産状態が保守責任の有る状態をいう。正常（保守対象外）は、稼動状態が正常である状態であり、資産状態が保守責任の無い状態をいう。異常（保守対象外）は、稼動状態が異常であるが、資産状態が保守責任の無い状態をいう。

本実施の形態における資産状態のうち、運用状態が、保守責任の有る状態であるとする。運用状態の機器４０は、ユーザが利用可能であるべき資産状態であり、そのような資産状態において、機器４０の稼動状態の異常は、ユーザに対して直接的に不便をもたらすといえるからである。一方、運用状態以外は、資産管理上、ユーザが機器４０を利用できない状態であり、そのような状態における稼動状態は、ユーザが受ける不便の直接的な原因ではないと考えられる。そこで、運用状態以外の資産状態は、保守責任の無い状態であるとされる。但し、いずれの資産状態を保守責任の有る状態とするかは、ＳＬＡ等の契約等において適宜定められてよい。

保守状態判定部１３は、判定結果である保守状態を示す情報（以下、「保守状態情報」という。）と、判定に利用された資産情報とを、判定対象の機器４０の稼動情報に対応付けて、機器状態履歴記憶部１６に記憶する。

したがって、機器状態履歴記憶部１６には、機器４０の機器情報が収集されるたびに、当該機器４０の稼動情報、資産情報、及び保守状態情報等が記憶される。

異常情報送信部１４は、機器情報収集部１１によって収集又は受信された機器情報のうち、機器４０の異常状態を示す情報（以下、「異常情報」という。）を、インシデント管理装置３０の異常情報受信部３１宛に送信（通知）する。インシデント情報受信部１５は、機器４０のインシデント情報を、インシデント管理装置３０から受信する。インシデント情報受信部１５が受信する情報の一例として、異常情報送信部１４によって異常情報が通知された機器４０に関する、異常状態の解消又は異常状態からの復旧を示す情報が挙げられる。なお、インシデント管理装置３０の異常情報受信部３１に対するアドレス情報は、例えば、予め機器管理装置１０に記憶されている。

資産管理装置２０は、更新部２１、検索部２２、確認要否判定部２３、及び確認要求出力部２４等を有する。これら各部は、資産管理装置２０にインストールされたプログラムが、資産管理装置２０のＣＰＵに実行させる処理により実現される。資産管理装置２０は、また、資産情報記憶部２５、許容期間記憶部２６、及び出力条件記憶部２７等を利用する。これら各記憶部は、資産管理装置２０が有する補助記憶装置、又は資産管理装置２０にネットワークを介して接続される記憶装置等を用いて実現可能である。

更新部２１は、資産情報記憶部２５が記憶する資産情報の更新を実行する。更新部２１による処理は、例えば、機器４０の資産状態が変化した場合に、当該変化を資産情報記憶部２５に反映するために行われるユーザからの入力に応じて行われる。

検索部２２は、指定された条件に合致する資産情報を、資産情報記憶部２５より検索する。

確認要否判定部２３は、機器管理装置１０からの資産情報の取得要求に応じ、取得要求に係る資産情報の正当性について、ユーザによる確認の要否を判定する。例えば、当該資産情報が誤っている可能性が有る場合、ユーザによる確認が必要であると判定される。当該判定は、許容期間記憶部２６を参照して行われる。許容期間記憶部２６は、異常状態に属する稼動状態ごとに、当該稼動状態の継続の許容期間を記憶する。確認要否判定部２３は、資産状態が保守責任の有る状態であるにも拘わらず、正常でない稼動状態が許容期間を超えている機器４０の資産情報について、ユーザによる確認が必要であると判定する。確認要否判定部２３は、また、取得要求に係る資産情報を、検索部２２を介して取得し、取得された資産情報を、機器管理装置１０に返信する。

確認要求出力部２４は、確認要否判定部２３によって資産情報の確認が必要であると判定された場合に、当該資産情報の確認要求を、例えば、クライアント装置５０に出力する。出力条件記憶部２７は、出力される確認要求を限定するための情報を記憶する。すなわち、確認要否判定部２３による判定結果に基づく確認要求は、出力条件記憶部２７に基づいてフィルタリングされる。

インシデント管理装置３０は、異常情報受信部３１、インシデント情報送信部３２、及びインシデント情報入力部３３等を有する。これら各部は、インシデント管理装置３０にインストールされたプログラムが、インシデント管理装置３０のＣＰＵに実行させる処理により実現される。インシデント管理装置３０は、また、インシデント情報記憶部３４等を利用する。インシデント情報記憶部３４は、インシデント管理装置３０が有する補助記憶装置、又はインシデント管理装置３０にネットワークを介して接続される記憶装置等を用いて実現可能である。

異常情報受信部３１は、異常情報送信部１４から送信される異常情報を受信し、当該異常情報をインシデント情報記憶部３４に記憶する。異常情報がインシデント情報記憶部３４に記憶されることにより、例えば、既定のワークフローシステムに従って、カスタマエンジニア等に、機器４０の異常の発生が通知される。

インシデント情報入力部３３は、例えば、異常状態の機器４０の復旧作業を行ったカスタマエンジニア、又は当該カスタマエンジニアから通知を受けたオペレータより、異常の解消を示す情報（以下、「異常解消情報」という。）の入力を受け付ける。インシデント情報入力部３３は、インシデント管理装置３０が備える入力装置を介して、異常解消情報の入力を受け付けてもよいし、クライアント装置５０等、他の装置において入力された異常解消情報を、ネットワークを介して受信してもよい。インシデント情報入力部３３によって入力された異常解消情報は、インシデント情報記憶部３４に記憶される。

インシデント情報送信部３２は、インシデント情報入力部３３が入力を受け付けた異常解消情報を、機器管理装置１０のインシデント情報受信部１５宛に送信する。なお、機器管理装置１０のインシデント情報受信部１５に対するアドレス情報は、例えば、予めインシデント管理装置３０に記憶されている。

以下、情報処理システム１が実行する処理手順について説明する。図４は、機器管理装置と資産管理装置との間で実行される処理手順の一例を説明するためのシーケンス図である。

例えば、機器情報収集部１１は、定期的に、各機器４０から機器情報を収集すると（Ｓ１０１、Ｓ１０２）、収集された機器情報を機器状態履歴記憶部１６に記憶する（Ｓ１０３）。

図５は、機器状態履歴記憶部の構成例を示す図である。図５では、便宜上、一つの機器４０（以下、「機器Ａ」という。）に関するレコードが示されている。なお、機器状態履歴記憶部１６は、機器４０ごとに、図５に示されるようなテーブルを含んでいてもよいし、図５に示されるような一つのテーブルを有し、各機器４０に関するレコードが、一つのテーブルに記憶されてもよい。

図５において、機器状態履歴記憶部１６の各レコードは、日時、稼動状態、資産状態、及び保守状態等の項目を有する。日時は、機器Ａから機器情報が収集又は受信された日時である。稼動状態は、機器情報に含まれている稼動情報が示す稼動状態である。資産状態は、機器情報の収集時又は受信時における、機器Ａの資産情報が示す資産状態である。保守状態は、機器Ａの保守状態である。

図５では、最後のレコードが、ステップＳ１０３において登録されたレコードを示す。すなわち、ステップＳ１０３においては、新たなレコードが追加され、当該レコードの日時及び稼動状態に値が記憶される。図５では、機器情報を収集する間隔が３時間である例（すなわち、各レコードの日時の間隔が３時間である例）が示されているが、機器情報の収集間隔は、３時間以外であってもよい。

なお、各レコードの稼動状態は、当該レコードの日時から次のレコードの日時まで継続していたこととして扱われる。換言すれば、ステップＳ１０３において記憶されるレコードは、当該レコード（以下、「レコードＡ」という。）の前のレコード（以下、「レコードＢ」という。）の稼動状態が、レコードＢの日時からレコードＡの日時までの期間継続したことを示す情報の一例に相当する。

なお、機器情報の構成要素のうち、稼動情報以外の構成要素が、機器状態履歴記憶部１６に記憶されてもよい。例えば、各機器情報には、各機器４０の識別情報（以下、「機器ＩＤ」という。）が含まれている。機器ＩＤは、シリアル番号、ＭＡＣアドレス、又はＩＰアドレス等、各機器４０を識別可能なものであればよい。したがって、機器情報収集部１１は、各機器情報がいずれの機器４０に対応するものであるかを判別できる。または、機器情報の問い合わせと、機器情報の応答とが同期的に行われる場合、機器情報収集部１１は、機器情報の問い合わせ先の機器４０を、収集された機器情報に係る機器４０として判別することができる。

なお、以降のステップは、機器情報が収集された各機器４０について行われるが、ここでは、便宜上、機器Ａを処理対象として説明する。

ステップＳ１０３に続いて、機器情報収集部１１は、現時点の機器Ａの保守状態の判定を、保守状態判定部１３に要求する（Ｓ１０４）。当該要求には、機器Ａの機器ＩＤ及び機器状態情報の履歴が指定される。機器Ａの機器状態情報の履歴とは、例えば、機器Ａに関して機器状態履歴記憶部１６が記憶する最新のレコードから遡ってＮ件分若しくは最近のＭ日分のレコードをいう。

続いて、保守状態判定部１３は、機器Ａの機器ＩＤ及び機器情報の履歴を指定して、機器Ａの資産情報の取得を資産情報取得部１２に要求する（Ｓ１０５）。資産情報取得部１２は、機器Ａの機器ＩＤ及び機器情報の履歴を指定して、機器Ａの資産情報の取得要求を、資産管理装置２０の確認要否判定部２３に送信する（Ｓ１０６）。続いて、確認要否判定部２３は、機器Ａの機器ＩＤを指定して、検索部２２に対して当該機器ＩＤに係る資産情報の取得を要求する（Ｓ１０７）。

検索部２２は、当該機器ＩＤに関連付けられている資産情報を、資産情報記憶部２５より検索する（Ｓ１０８、Ｓ１０９）。

図６は、資産情報の検索結果の第一の例を示す図である。図６では、機器Ａの資産情報の履歴が検索された例が示されている。すなわち、図６に示される検索結果は、資産情報記憶部２５が、機器４０ごとに、資産状態の変化の履歴を記憶しているという前提に基づく。例えば、機器４０の資産状態が更新されるたびに、資産情報記憶部２５に新たなレコードが生成され、当該レコードに更新後の資産状態が記憶される。各レコードは、日時及び資産状態を含む。日時は、資産状態の更新日時である。資産状態は、更新後の資産状態である。

なお、本実施の形態のように、機器情報が収集されるたびに、当該機器情報に関してステップＳ１０４が実行される場合には、最新の資産状態に係る一つのレコードが検索対象とされてもよい。一方、ステップＳ１０４以降が、バッチ的に実行される場合、すなわち、機器状態履歴記憶部１６における同一の機器４０に対する複数のレコードの資産状態及び保守対象の項目がまとめて記録される場合、図６に示されるような過去の資産情報の履歴を含む検索結果が好ましい。過去の資産情報の履歴が含まれることで、過去の稼動状態に対応する資産情報を特定することができるからである。

続いて、確認要否判定部２３は、機器Ａの資産情報の履歴と、機器Ａの機器状態情報の履歴とを照合することにより、当該資産情報の正当性について、ユーザによる確認の要否を判定する（Ｓ１１１）。

確認の必要が有ると判定された場合、確認要否判定部２３は、当該資産情報の確認要求を確認要求出力部２４に通知する（Ｓ１１２）。確認要求出力部２４は、出力条件記憶部２７より出力条件を取得し（Ｓ１１３、Ｓ１１４）、当該確認要求の内容が、出力条件に合致するか否かを判定する。当該確認要求の内容が出力条件に合致する場合、確認要求出力部２４は、当該確認要求を、予め設定された出力先に出力する（Ｓ１１５）。図４では、クライアント装置５０に対して、当該確認要求が送信されている例が示されている。ユーザは、確認要求を確認することで、資産情報の正否を確認することができる。その結果、ユーザは、資産情報の誤りを訂正することができる。

続いて、確認要否判定部２３は、機器Ａの資産情報の履歴を、資産情報取得部１２に返信する（Ｓ１１６）。資産情報取得部１２は、機器Ａの資産情報の履歴を、保守状態判定部１３に返信する（Ｓ１１７）。

続いて、保守状態判定部１３は、資産情報の履歴のうち、現時点に対応する資産情報（以下、「対象資産情報」という。）が示す資産状態に基づいて、機器Ａの保守状態を判定する（Ｓ１１８）。現時点に対応する資産情報とは、資産情報の履歴の中で、日時が現時点以前であって、最新の資産情報をいう。なお、各資産状態の継続期間は、例えば、当該資産状態の日時から、次の資産状態の日時までとされる。

なお、最新の資産情報のみが取得されている場合、当該資産情報が、対象資産情報に相当する。また、ステップＳ１０４以降が、バッチ的に実行される場合、すなわち、機器状態履歴記憶部１６における同一の機器４０に対する複数のレコードの資産状態及び保守対象の項目がまとめて記録される場合、レコードごとに、対象資産情報は、異なりうる。すなわち、各レコードの日時の時点を当該資産状態の継続期間に含む資産状態、すなわち、各レコードの日時の時点における最新の（最後の）資産情報が、それぞれのレコードに対する対象資産情報となる。

続いて、保守状態判定部１３は、対象資産情報が示す資産状態と、判定結果である保守状態情報が示す保守状態とを、機器状態履歴記憶部１６において、当該対象資産情報及び判定結果が対応するレコード（例えば、図５における最後のレコード）に記憶する（Ｓ１１９）。

続いて、ステップＳ１１８の詳細について説明する。図７は、保守状態の判定処理の処理手順の一例を説明するためのフローチャートである。図７の処理において、機器状態履歴記憶部１６において処理対象とされているレコード（例えば、図５の最後のレコード）を、以下「対象レコード」という。

ステップＳ２０１において、保守状態判定部１３は、資産情報が取得されたか否かを判定する。すなわち、図４のステップＳ１１７において入力された資産情報の履歴が空でないか否かが判定される。なお、例えば、機器Ａに関する資産情報が資産情報記憶部２５に記憶されていない場合、当該履歴は空となる。

資産情報が取得されない場合（Ｓ２０１でＮｏ）、保守状態は判定不能であるため、保守状態判定部１３は、図７の処理を終了させる。この場合、機器状態履歴記憶部１６の対象レコードに対して、資産状態及び保守状態は、記憶されなくてもよい。

資産情報が取得された場合（Ｓ２０１でＹｅｓ）、保守状態判定部１３は、対象レコードの稼動状態が正常以外であるか否か（異常状態であるか否か）を判定する（Ｓ２０２）。当該稼動状態が正常以外である場合（Ｓ２０２でＹｅｓ）、保守状態判定部１３は、対象資産情報の示す資産状態が運用状態であるか否かを判定する（Ｓ２０３）。当該資産状態が運用状態である場合（Ｓ２０３でＹｅｓ）、保守状態判定部１３は、対象レコードに対する保守状態は、異常（保守対象）であると判定する（Ｓ２０４）。当該資産状態が運用状態でない場合（Ｓ２０３でＮｏ）、保守状態判定部１３は、対象レコードに対する保守状態は、異常（保守対象外）であると判定する（Ｓ２０５）。

一方、対象レコードの稼動状態が正常である場合（Ｓ２０２でＮｏ）、保守状態判定部１３は、対象資産情報の示す資産状態が運用状態であるか否かを判定する（Ｓ２０６）。当該資産状態が運用状態である場合（Ｓ２０６でＹｅｓ）、保守状態判定部１３は、対象レコードに対する保守状態は、正常（保守対象）であると判定する（Ｓ２０７）。当該資産状態が運用状態でない場合（Ｓ２０６でＮｏ）、保守状態判定部１３は、対象レコードに対する保守状態は、正常（保守対象外）であると判定する（Ｓ２０８）。

図７において判定される保守状態と、対象資産情報が示す資産状態とが対象レコードに記憶されることにより、機器状態履歴記憶部１６の記憶内容は、例えば、図８に示されるようになる。

図８は、機器状態履歴記憶部に対する資産状態及び保守状態の第一の記憶例を示す図である。図８では、図６における最後のレコードが対象レコードであり、図６に示される資産情報の履歴のうち、最後の資産情報が対象資産情報である場合に記憶される資産状態及び保守状態を示す。この場合、稼動状態は正常以外である。また、対象資産情報が示す資産状態は、運用状態である。したがって、保守状態は、異常（保守対象）となる。

また、仮に、機器Ａの資産情報の検索結果が、図９に示される通りであったとする。図９は、資産情報の検索結果の第二の例を示す図である。図９では、対象資産情報が示す資産状態が、移動状態である点が、図６と異なる。この場合、図７において判定される保守状態と、対象資産情報が示す資産状態とは、図１０に示されるように記憶される。

図１０は、機器状態履歴記憶部に対する資産状態及び保守状態の第二の記憶例を示す図である。図１０において、最後のレコードの保守状態は、異常（保守対象外）とされている。保守対象外であるのは、資産状態が、運用状態以外であるためである。

なお、図７のステップＳ２０３における、対象資産情報が示す資産状態との比較の対象は、固定的に運用状態でなくてもよい。例えば、保守責任の有る又は保守責任の無い資産状態の一覧が、補助記憶装置１０２に記憶されていてもよい。保守状態判定部１３は、対象資産情報が示す資産状態が、当該一覧のいずれかに該当するか否かを判定してもよい。

なお、図８又は図１０に示されるような機器状態履歴記憶部１６によれば、保守責任の無い期間における稼動情報を、稼働率を算出するための情報から除外することができる。すなわち、保守責任の無い期間を、機器Ａの稼働率を算出する際の算出期間から除外することができる。具体的には、保守状態が、正常（保守対象外）又は異常（保守対象外）である期間を、式（１）におけるＭＴＢＦ又はＭＴＴＲから除くことができる。その結果、ＳＬＡ等の契約に照らして、稼働率の算出結果の妥当性を向上させることができる。

図１１は、本実施の形態を適用した場合と適用しない場合との保守状態の違いを示す図である。図１１において、横軸は時間を示す。図中において左から右方向が時間の進行方向である。

縦軸には、資産状態、稼動状態、保守状態Ａ、及び保守状態Ｂが配列されている。稼動状態において、網掛け部分は、正常状態以外である。網掛けの無い部分は、正常状態である。なお、図１１の例では、資産状態が運用状態に遷移した時点ｔ０において、機器管理装置１０による機器情報の収集が開始されていることとする。したがって、稼動状態は、時点ｔ０から有効となっている。

保守状態Ａは、本実施の形態を適用しない場合、すなわち、資産状態を考慮しないで保守状態を判定した場合の保守状態の遷移を示す。保守状態Ｂは、本実施の形態を適用した場合、すなわち、資産状態を考量して保守状態を判定した場合の保守状態の遷移を示す。

保守状態の遷移において、実線は、正常（保守対象）の継続期間を示す。破線は、異常（保守対象）の継続期間を示す。線が無い部分は、正常（保守対象外）又は異常（保守対象外）の継続期間を示す。保守状態Ａによれば、時点ｔ０以降の全ての期間が保守責任の有る期間となる。すなわち、全ての期間が、稼働率の算出期間（稼働率の算出に寄与する期間）となる。一方、保守状態Ｂによれば、時点ｔ１〜時点ｔ２の期間、及び時点ｔ３〜時点ｔ４の期間は、稼働率の算出期間から除かれることになる。

なお、図８又は図１０に基づいて稼働率が算出される場合、各稼動状態の期間は、例えば、当該稼動状態の日時から次の稼動状態の日時までとされる。例えば、図８及び図１０において２行目のレコードの稼動状態であるカバーオープン状態は、当該レコードの日時から次のレコード（稼動状態が正常であるレコード）の日時までの期間において継続しているとされてもよい。

続いて、図４のステップＳ１１１の詳細について説明する。図１２は、資産情報の確認要否判定処理の処理手順の一例を説明するためのフローチャートである。

ステップ３０１において、確認要否判定部２３は、機器Ａの資産情報が取得されたか否かを判定する。資産情報が取得された場合（Ｓ３０１でＹｅｓ）、確認要否判定部２３は、資産情報の履歴の中で、最新の資産情報が示す資産状態が運用状態であるか否かを判定する（Ｓ３０２）。当該資産状態が運用状態である場合（Ｓ３０２でＹｅｓ）、確認要否判定部２３は、機器情報の履歴を参照して、最新の機器情報に含まれる稼動情報が示す稼動状態の継続期間が許容期間内であるか否かを、許容期間記憶部２６を参照して判定する（Ｓ３０３）。

図１３は、許容期間記憶部の構成例を示す図である。図１３において、許容期間記憶部２６は、正常でない稼動状態ごとに、許容期間を記憶する。許容期間は、ＳＬＡ等の契約に基づいて設定されてもよいし、各稼動状態を解消するために一般的に必要とされる期間が設定されてもよい。

最新の稼働状態の継続期間が、許容期間内である場合（Ｓ３０３でＹｅｓ）、確認要否判定部２３は、資産情報の確認は不要であると判定する（Ｓ３０４）。資産状態が運用状態でない場合も（Ｓ３０２でＮｏ）、確認要否判定部２３は、資産情報の確認は不要であると判定する（Ｓ３０４）。

一方、当該継続期間が、許容期間を超える場合（Ｓ３０３でＮｏ）、確認要否判定部２３は、資産情報の確認は必要であると判定する（Ｓ３０５）。運用状態であるにも拘わらず、異常状態が許容期間を超えて放置されているということは、実際には、機器Ａは運用状態ではない可能性が考えられるからである。また、機器Ａの資産情報が無い場合も（Ｓ３０１でＮｏ）、確認要否判定部２３は、資産情報の確認は必要であると判定する（Ｓ３０５）。

図１２において、資産情報の確認が不要であると判定された場合、図４のステップＳ１１２〜Ｓ１１５は実行されない。資産情報の確認が必要であると判定された場合、図４のステップＳ１１２では、当該資産情報と、機器Ａの最新の稼動状態を示す稼動情報とを含む確認要求が、確認要求出力部２４に通知される。但し、機器Ａの資産情報が無いため、資産情報の確認が必要であると判定された場合は、例えば、機器Ａの機器ＩＤと、機器Ａの資産情報が無いことを示す情報を含む確認要求が、確認要求出力部２４に通知される。

なお、図１２では、資産状態が運用状態である場合に限って、確認要求が行われる例を示したが、例えば、資産状態と稼動状態との組み合わせについて、矛盾するか否かが判定され、矛盾する場合に確認要求が行われるようにしてもよい。矛盾する組み合わせを示す情報は、例えば、補助記憶装置１０２に記憶されていてもよい。すなわち、フローチャートで説明したケースも含めて、資産状態と運用状態とが所定の関係を有するか否かに基づいて、確認要求が行われてもよい。

続いて、図４のステップＳ１１５の詳細について説明する。図１４は、確認要求の出力処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ４０１において、確認要求出力部２４は、確認要否判定部２３より通知された確認要求の原因が、出力条件記憶部２７に記憶されたいずれかの出力条件に合致するか否かを判定する。

図１５は、出力条件記憶部の構成例を示す図である。図１５において、出力条件は、ユーザに通知される確認要求を限定するための情報を記憶する。図１５では、確認要求の原因が、資産情報が無いこと、圧着ローラ故障状態が許容期間を超えること、又はトナー切れ状態が許容期間を超えることが、出力条件とされている。したがって、確認要求の原因が、トナー切れ状態が許容期間を超えること又はカバーオープン状態が許容期間を超えることである場合、当該確認要求の原因は、出力条件に合致しないと判定される。

確認要求の原因が出力条件に合致する場合（Ｓ４０１でＹｅｓ）、確認要求出力部２４は、予め設定された出力方法（例えば、電子メールの送信又はＷｅｂサイトへの書き込み等）によって、当該確認要求を出力する（Ｓ４０２）。一方、確認要求の原因が出力条件に合致しない場合（Ｓ４０１でＮｏ）、確認要求の出力は行われない。

出力条件によって確認要求をフィルタリングすることにより、ユーザにとって不要な確認要求が出力されるのを防止することができる。

次に、機器管理装置１０とインシデント管理装置３０との間で実行される処理について説明する。図１６は、機器の異常状態の発生時において機器管理装置とインシデント管理装置との間で実行される処理手順の一例を説明するための図である。

機器情報収集部１１は、一定の間隔で、各機器４０に対して機器情報の取得要求を送信する（Ｓ５０１）。機器４０は、当該取得要求に応じ、機器情報を含む応答を返信する（Ｓ５０２）。機器情報収集部１１は、返信された応答に含まれている機器情報を機器状態履歴記憶部１６に記憶する（Ｓ５０３）。

異常情報送信部１４は、新たに記憶された機器情報の示す稼動状態が、正常以外である場合（例えば、「紙詰まり」である場合）、当該機器情報の送信元の機器４０について、異常の発生を検出する（Ｓ５０４）。そこで、異常情報送信部１４は、当該稼動状態を示す異常情報を、インシデント管理装置３０に送信する（Ｓ５０５）。

インシデント管理装置３０の異常情報受信部３１は、当該異常情報を受信すると、当該異常情報を、インシデント情報記憶部３４に記憶する（Ｓ５０６）。

なお、ステップＳ５０１〜Ｓ５０３は、ステップＳ１０１〜Ｓ１０３と同じ処理である。すなわち、図４のステップＳ１０３に記憶された機器情報が異常状態を示すものである場合、ステップＳ５０４以降の処理が実行される。

続いて、ステップＳ５０６において、インシデント情報記憶部３４に異常情報が記憶された機器４０について、異常状態が解消された場合に実行される処理手順について説明する。

図１７は、機器の異常状態の解消時において機器管理装置とインシデント管理装置との間で実行される処理手順の一例を説明するための図である。

例えば、図１６のステップＳ５０６においてインシデント情報記憶部３４に記憶された異常情報の示す異常状態に関して、カスタマエンジニアは、当該異常状態に係る機器４０について復旧作業を行う。復旧作業の結果、異常状態が解消されると、カスタマエンジニア又はオペレータは、インシデント管理装置３０に対して、異常解消情報を入力する。この際、復旧作業の完了後、迅速に異常解消情報が入力されることで、本実施の形態によって得られる効果を高めることができる。

ステップＳ５１１において、インシデント情報入力部３３は、当該異常解消情報の入力を受け付ける。

続いて、インシデント情報入力部３３は、当該異常解消情報を、インシデント情報記憶部３４に記憶する（Ｓ５１２）。例えば、ステップＳ５０６において記憶された異常情報が示す異常状態に対する対応が完了したことが、インシデント情報記憶部３４に記憶されてもよい。

続いて、インシデント情報送信部３２は、当該異常解消情報を、機器管理装置１０に送信する（Ｓ５１３）。機器管理装置１０のインシデント情報受信部１５は、当該異常解消情報を受信すると、稼動状態の値が正常であるレコードを、機器状態履歴記憶部１６に記憶（追加）する（Ｓ５１４）。

図１８は、異常解消情報に基づく機器状態履歴記憶部へのレコードの追加例を示す図である。図１８では、図５又は図８における最後のレコードの次に、紙詰まりの解消に応じてインシデント管理装置３０に入力された異常解消情報に基づいて登録されたレコードが示されている。

当該レコードにおいて、日時は、当該レコードが登録された日時である。ここで、最後のレコード以外のレコードは、３時間間隔で登録されている。したがって、図１７の処理が実行されない場合、当該機器４０について正常な状態が確認されるのは、「２０１３／０４／０９ ０９：００：００」になってしまう。

一方、図１７の処理によって登録されるレコードの日時は、「２０１３／０４／０９ ０７：１０：００」となっており、３時間という間隔には従っていない。インシデント管理装置３０への異常解消情報の入力は、機器情報の収集間隔とは非同期に行われるからである。その結果、異常状態の継続期間は、１時間１０分であったことが機器状態履歴記憶部１６に記憶される。すなわち、ステップＳ５１４において追加されるレコードは、当該レコード（以下、「レコードＡ」という。）の前のレコード（以下、「レコードＢ」という。）の稼動状態及び保守状態が、レコードＢの日時からレコードＡの日時までの期間継続したことを示す情報の一例に相当する。

図１８の例によれば、稼働率の算出において、異常状態に算入される期間を、１時間５０分だけ短縮することができる。すなわち、当該機器４０のＭＴＢＦを増加させることができ、稼働率を増加させることができる。斯かる稼働率は、実情により即したものであるといえる。

この点について、図を用いて説明する。図１９は、本実施の形態を適用した場合と適用しない場合との保守状態の違いを示す第二の図である。図１９の見方は、図１１と同様である。

図１９では、時点ｔ０ａ、ｔ０ｂ、及びｔ０ｃが記入されている。時点ｔ０ａは、機器管理装置１０が、異常状態を示す稼動情報を収集又は受信した時刻である。時点ｔ０ｂは、カスタマエンジニアによって、異常解消情報が入力された時刻である。時点ｔ０ｃは、機器情報の収集間隔において、時点ｔ０ａの次に機器情報を収集するタイミングである。図１７の処理が実行されない場合、時点ｔ０ａ〜時点ｔ０ｃまでが、異常（保守対象）の継続期間（以下、「期間Ａ」という。）となる。一方、図１７の処理が実行される場合、時点ｔ０ａ〜時点ｔ０ｂまでが、異常（保守対象）の継続期間（以下、「期間Ｂ」という。）となる。図１９より明らかなように、期間Ｂは、期間Ａより短い。

異常情報の通知が、機器４０から能動的に行われるようにすることで、当該機器４０の異常状態の期間の精度をより高めることができる。

なお、図１８の最後のレコードにおける資産状態及び保守状態は、ステップＳ５１４に続いて、図４のステップＳ１０４以降が実行されることにより、登録されてもよい。

ところで、機器４０に関しては、異常又は障害等の発生を予防するため、すなわち、機器４０の機能を維持するため、異常又は障害等が発生しない場合でも、カスタマエンジニア等によって、点検等の機能維持作業（又はメンテナンス作業）が行われる。機能維持作業の期間が、稼働率の算出においてどのように扱われるかは、ＳＬＡ等の契約に依存するが、当該期間が、稼働率の算出から除外されるという契約が結ばれた場合、情報処理システム１は、次のような処理を実行してもよい。

図２０は、機能維持作業の開始時において機器管理装置とインシデント管理装置との間で実行される処理手順の一例を説明するための図である。

ステップＳ６０１において、インシデント情報入力部３３は、機能維持作業の開始を示す入力を受け付ける。

続いて、インシデント情報入力部３３は、機能維持作業の開始を示す情報（以下、「機能維持作業開始情報」という。）を、インシデント情報記憶部３４に記憶する（Ｓ６０２）。続いて、インシデント情報送信部３２は、当該機能維持作業開始情報を、機器管理装置１０に送信する（Ｓ６０３）。機器管理装置１０のインシデント情報受信部１５は、当該機能維持作業開始情報を受信すると、稼動状態の値が「機能維持作業開始」であるレコードを、機器状態履歴記憶部１６に記憶する（Ｓ６０４）。

機能維持作業が終了すると、図２０と同様の処理手順が実行される。但し、機能維持作業の終了時には、機能維持作業の終了を示す入力が、インシデント管理装置３０に対して行われる。その結果、機器状態履歴記憶部１６には、稼動状態の値が「機能維持作業終了」であるレコードが記憶される。

図２１は、機能維持作業の開始及び終了に基づく機器状態履歴記憶部へのレコードの追加例を示す図である。

図２１では、下から５番目に、稼動状態の値が「機能維持作業開始」であるレコード（以下、「作業開始レコード」という。）が記憶され、下から２番目に、稼動状態の値が「機能維持作業終了」であるレコード（以下、「作業終了レコード」という。）が記憶された例が示されている。作業開始レコード及び作業終了レコードのそれぞれの日時は、各レコードが記憶された日時であり、ほぼ機能維持作業の開始日時又は機能維持作業の終了日時である。

なお、機能維持作業の間も、図４の処理は実行されている。したがって、作業開始レコード及び作業終了レコードの間に、レコードが記憶されている。ここで、作業開始レコードと作業終了レコードとの間における各レコードの保守状態は、保守責任の無い状態である、正常（保守対象外）又は異常（保守対象外）である。作業開始レコード及び作業終了レコードのように、機能維持作業の開始又は終了を示すレコードが機器状態履歴記憶部１６に記憶される場合、保守状態判定部１３は、図７の代わりに、例えば、図２２に示される処理手順を実行する。

図２２は、保守状態の判定処理の処理手順の第二の例を説明するためのフローチャートである。図２２中、図７と同一ステップには同一ステップ番号を付し、その説明は省略する。

図２２では、ステップＳ２０３でＹｅｓの場合に、ステップＳ２１１が追加され、ステップＳ２０６でＹｅｓの場合に、ステップＳ２１２が追加されている。

ステップＳ２１１及びＳ２１２において、保守状態判定部１３は、対象レコードより前のレコード群の中に、対となる作業終了レコードの無い作業開始レコードの有無を判定する。作業開始レコードに対して対となる作業終了レコードとは、当該作業開始レコードより日時が後である作業終了レコードである。

該当する作業開始レコードが有る場合、保守状態判定部１３は、ステップＳ２０５又はＳ２０８を実行する。該当する作業開始レコードが無い場合、保守状態判定部１３は、ステップＳ２０４又はＳ２０７を実行する。

このように、機能維持作業開始レコードと、機能維持作業終了レコードとの間のレコードを、保守対象外とすることで、機能維持作業の期間を、稼働率の算出期間から除外することができる。

図２３は、本実施の形態を適用した場合と適用しない場合との保守状態の違いを示す第三の図である。

図２３では、時点ｔ２ａが、機能維持作業の開始時刻であり、時点ｔ２ｄが、機能維持作業の終了時刻である例が示されている。この場合、時点ｔ２ａ〜時点ｔ２ｄまでの期間は、正常（保守対象外）又は異常（保守対象外）となる。したがって、時点ｔ２ａ〜時点ｔ２ｄまでの期間における稼動情報を、稼働率を算出するための情報から除外することができる。すなわち、当該機関を、稼働率の算出期間から除外することができる。その結果、機能維持作業におけるカバーオープンや、トナーの取り外し等、機能維持作業によって発生する異常（機器管理装置１０から見た異常）が、稼働率に影響することを回避することができる。

上述したように、本実施の形態によれば、インシデント管理装置３０に対して入力される異常解消情報に基づいて、機器状態履歴記憶部１６に対して、異常を示す稼動状態の解消を示すレコードが記憶される。その結果、当該異常の継続期間を、実情に即したものとすることができる。すなわち、機器４０から取得される情報に基づいて把握される機器４０の稼動状態の妥当性を向上させることができる。

なお、異常の発生は、機器４０が能動的に機器管理装置１０に対して通知してもよい。同様に、異常の解消についても、機器４０が能動的に機器管理装置１０に対して通知するようにしてもよい。但し、機器４０の通信状態は、インシデント管理装置３０に比較して不安定であると考えられる。具体的には、機器４０は、ユーザによって電源のＯＮ／ＯＦＦが容易に切り替えられ、また、ネットワーク６０から容易に切断されうる。また、機器４０の機種等によって、異常の解消を能動的に通知可能な機器４０も有れば、異常の解消を能動的に通知できない機器４０の存在も考えられる。斯かる観点に鑑みて、本実施の形態では、インシデント管理装置３０において入力される情報に基づいて、機器４０の異常の解消を示すレコードが、機器状態履歴記憶部１６に記憶されるように構成されている。

また、本実施の形態によれば、機器４０に対する機能維持作業の期間における、稼動情報を、機器４０の稼働率の算出に用いる情報から除外することができる。すなわち、当該期間を、機器４０の稼働率の算出期間から除くことができる。したがって、機能維持作業において発生する異常状態の継続期間が、稼働率の算出において異常な期間として扱われるのを回避することができる。

また、本実施の形態によれば、資産情報を利用して、保守責任の無い期間を判定し、当該期間における稼動情報を、機器４０の稼働率の算出に用いる情報から除外することができる。すなわち、当該期間を機器４０の稼働率の算出期間から除外することができる。したがって、機器４０の稼働率の算出結果の妥当性を向上させることができる。

なお、資産情報の利用は、必ずしも行われなくてもよい。すなわち、資産管理装置２０は、情報処理システム１に含まれなくてもよい。この場合、機器状態履歴記憶部１６において、保守状態の項目は不要である。資産情報が利用されない場合であっても、上記したように、機器４０の異常状態の期間の短縮化や、機器４０の機能維持作業期間の稼働率の算出期間からの除外等は、可能である。

なお、本実施の形態において、機器情報収集部１１は、受信部又は第一の受信部の一例である。機器状態履歴記憶部１６は、第一の記憶部の一例である。インシデント情報入力部３３は、受付部の一例である。保守状態判定部１３は、判定部の一例である。資産情報記憶部２５は、第二の記憶部の一例である。インシデント情報受信部１５は、追加部及び第二の受信部の一例である。機器管理装置１０は、第一の情報処理装置の一例である。インシデント管理装置３０は、第二の情報処理装置の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ 情報処理システム
１０ 機器管理装置
１１ 機器情報収集部
１２ 資産情報取得部
１３ 保守状態判定部
１４ 異常情報送信部
１５ インシデント情報受信部
１６ 機器状態履歴記憶部
２０ 資産管理装置
２１ 更新部
２２ 検索部
２３ 確認要否判定部
２４ 確認要求出力部
２５ 資産情報記憶部
２６ 許容期間記憶部
２７ 出力条件記憶部
３０ インシデント管理装置
３１ 異常情報受信部
３２ インシデント情報送信部
３３ インシデント情報入力部
３４ インシデント情報記憶部
４０ 機器
５０ クライアント装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

特開２００９−０７５６４４号公報

Claims (10)

1. 一以上のコンピュータを含む情報処理システムであって、
   機器の稼動状態を示す稼動情報を、所定の間隔で前記機器からネットワークを介して受信する受信部と、
   前記受信部によって受信された稼動情報を記憶する第一の記憶部と、
   稼動状態が異常を示す稼動情報が受信された前記機器について、前記異常の解消を示す解消情報の入力を、前記所定の間隔とは非同期に受け付ける受付部と、
   稼動状態が異常を示す稼動情報が受信されてから次の稼動情報が受信されるまでの期間において、前記受付部が前記解消情報を受け付けた場合に、当該稼動情報が示す異常が当該稼動情報の受信から当該解消情報の受け付けまで継続したことを示す情報を前記第一の記憶部に追加する追加部とを有することを特徴とする情報処理システム。
2. 前記受付部は、前記機器に対する所定の作業の開始及び終了を示す入力を受け付け、
   前記所定の作業が開始されてから終了するまでの期間において前記受信部によって受信された稼動情報を、前記機器の稼働率の算出に用いる情報から除外することを判定する判定部を有する請求項１記載の情報処理システム。
3. 前記判定部は、第二の記憶部が記憶する、前記機器の資産としての状態を示す資産情報が所定の状態を示す期間において前記受信部によって受信された稼動情報を、前記機器の稼働率の算出に用いる情報から除外することを判定する請求項２記載の情報処理システム。
4. 前記判定部は、前記第二の記憶部が記憶する資産情報が所定の状態を示す期間において前記受信部によって受信された稼動情報については、当該稼動情報が示す稼動状態に拘わらず、前記機器の稼働率の算出に用いる情報から除外することを判定する請求項３記載の情報処理システム。
5. 第一の情報処理装置と第二の情報処理装置とを含む情報処理システムであって、
   前記第一の情報処理装置は、
   機器の稼動状態を示す稼動情報を、所定の間隔で前記機器からネットワークを介して受信する第一の受信部と、
   前記第一の受信部によって受信された稼動情報を記憶する第一の記憶部と、
   稼動状態が異常を示す稼動情報が受信された前記機器について、前記異常の解消を示す解消情報を、前記第二の情報処理装置から、前記所定の間隔とは非同期に受信する第二の受信部と、
   稼動状態が異常を示す稼動情報が受信されてから次の稼動情報が受信されるまでの期間において、前記第二の受信部が前記解消情報を受信した場合に、当該稼動情報が示す異常が当該稼動情報の受信から当該解消情報の受け付けまで継続したことを示す情報を前記第一の記憶部に追加する追加部とを有することを特徴とする情報処理システム。
6. 前記第二の受信部は、前記機器に対する所定の作業の開始及び終了を示す情報を前記第二の情報処理装置から受信し、
   前記第一の情報処理装置は、
   前記所定の作業が開始されてから終了するまでの期間において前記第一の受信部によって受信された稼動情報を、前記機器の稼働率の算出に用いる情報から除外することを判定する判定部を有する請求項５記載の情報処理システム。
7. 前記判定部は、第二の記憶部が記憶する、前記機器の資産としての状態を示す資産情報が所定の状態を示す期間において前記第一の受信部によって受信された稼動情報を、前記機器の稼働率の算出に用いる情報から除外することを判定する請求項６記載の情報処理システム。
8. 前記判定部は、前記第二の記憶部が記憶する資産情報が所定の状態を示す期間において前記第一の受信部によって受信された稼動情報については、当該稼動情報が示す稼動状態に拘わらず、前記機器の稼働率の算出に用いる情報から除外することを判定する請求項７記載の情報処理システム。
9. 一以上のコンピュータを含む情報処理システムが、
   機器の稼動状態を示す稼動情報を、所定の間隔で前記機器からネットワークを介して受信する受信手順と、
   前記受信手順において受信された稼動情報を第一の記憶部に記憶する記憶手順と、
   稼動状態が異常を示す稼動情報が受信された前記機器について、前記異常の解消を示す解消情報の入力を、前記所定の間隔とは非同期に受け付ける受付手順と、
   稼動状態が異常を示す稼動情報が受信されてから次の稼動情報が受信されるまでの期間において、前記受付手順が前記解消情報を受け付けた場合に、当該稼動情報が示す異常が当該稼動情報の受信から当該解消情報の受け付けまで継続したことを示す情報を前記第一の記憶部に追加する追加手順とを実行することを特徴とする情報処理方法。
10. 第一の情報処理装置と第二の情報処理装置とを含む情報処理システムにおける前記第一の情報処理装置に、
    機器の稼動状態を示す稼動情報を、所定の間隔で前記機器からネットワークを介して受信する第一の受信手順と、
    前記第一の受信手順において受信された稼動情報を第一の記憶部に記憶する記憶手順と、
    稼動状態が異常を示す稼動情報が受信された前記機器について、前記異常の解消を示す解消情報を、前記第二の情報処理装置から、前記所定の間隔とは非同期に受信する第二の受信手順と、
    稼動状態が異常を示す稼動情報が受信されてから次の稼動情報が受信されるまでの期間において、前記第二の受信手順が前記解消情報を受信した場合に、当該稼動情報が示す異常が当該稼動情報の受信から当該解消情報の受け付けまで継続したことを示す情報を前記第一の記憶部に追加する追加手順とを実行させるプログラム。

Images