JP6900657B2

JP6900657B2 - 機器、情報処理システム及びプログラム

Info

Publication number: JP6900657B2
Application number: JP2016222245A
Authority: JP
Inventors: 孫涛厳
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2016-11-15
Filing date: 2016-11-15
Publication date: 2021-07-07
Anticipated expiration: 2036-11-15
Also published as: JP2018081413A; US20180139350A1

Description

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

従来から、顧客環境に設置された機器に関する解析を外部環境に設置されたサーバなどの情報処理装置で行うため、当該機器からリモートで（ネットワークを介して）情報処理装置に情報を通知する技術が知られている。例えば特許文献１には、複写機から、当該複写機の内部情報、環境情報、及び使用情報を定期的に故障予測装置に送信する技術が開示されている。

しかしながら、上述したような従来技術では、情報処理装置は、機器から情報が通知される間隔よりも長い間隔での機器の状態変動の解析は可能であるが、突発的に生じる状態変動のような、機器から情報が通知される間隔よりも短い間隔で完結してしまうような状態変動を解析することは困難である。

なお、情報処理装置に対する機器からの情報の通知間隔を短くすれば、理論上は、上述したような突発的に生じる状態変動の解析することも可能であるが、この場合、機器は情報処理装置に対して情報を常時通知しなければならず、通信負荷の観点から現実的ではない。

本発明は、上記事情に鑑みてなされたものであり、通信負荷を抑えつつ、機器に対する多様な解析を行うことが可能な機器、情報処理システム及びプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の一態様にかかる機器は、情報処理装置とネットワークを介して接続される機器であって、検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成部と、定期的に訪れる通知タイミングになると、前記機器の現時点での状態を示す第１の状態情報を取得する第１の取得部と、前記第１の状態情報が取得されると、当該第１の状態情報を前記情報処理装置に通知する第１の通知部と、前記第１の状態情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記情報処理装置に未通知の状態情報である第２の状態情報を取得する第２の取得部と、前記第２の状態情報が取得されると、当該第２の状態情報を前記情報処理装置に通知する第２の通知部と、を備える。

本発明によれば、通信負荷を抑えつつ、機器に対する多様な解析を行うことが可能という効果を奏する。

図１は、本実施形態の情報処理システムの構成の一例を示すブロック図である。図２は、本実施形態の機器のハードウェア構成の一例を示すブロック図である。図３は、本実施形態の情報処理装置のハードウェア構成の一例を示すブロック図である。図４は、本実施形態の機器のソフトウェア構成の一例を示すブロック図である。図５は、本実施形態の情報処理システムの機能構成の一例を示すブロック図である。図６は、本実施形態の情報処理システムで行われる時系列の状態情報の生成処理の一例を示すシーケンス図である。図７は、本実施形態の情報処理システムで行われる第１の状態情報及び第２の状態情報の通知処理の一例を示すシーケンス図である。図８は、本実施形態の情報処理システムで行われる対象情報及び第２の状態情報の通知処理の一例を示すシーケンス図である。図９は、本実施形態の情報処理システムで行われる通知処理の一例を示すフローチャートである。図１０は、本実施形態の情報処理システムで行われる第１の状態情報及び第２の状態情報の通知処理の具体例を示す図である。図１１は、本実施形態の情報処理システムで行われる対象情報及び第３の状態情報の通知処理の具体例を示す図である。図１２は、本実施形態の機器で行われる第２の状態情報決定処理の一例を示すフローチャートである。図１３は、本実施形態の機器で行われる第３の状態情報決定処理の一例を示すフローチャートである。図１４は、本実施形態の情報処理システムで行われる通知要否情報の書き込み処理の一例を示すシーケンス図である。図１５は、変形例２の情報処理システムで行われる対象情報及び第２の状態情報の通知処理の一例を示すシーケンス図である。図１６は、変形例２の情報処理システムで行われる通知処理の一例を示すフローチャートである。

以下、添付図面を参照しながら、本発明にかかる機器、情報処理システム及びプログラムの実施の形態を詳細に説明する。

図１は、本実施形態の情報処理システム１の構成の一例を示すブロック図である。図１に示すように、情報処理システム１は、機器１０と、情報処理装置２０とを、備える。機器１０及び情報処理装置２０は、ネットワーク２を介して接続されている。ネットワーク２は、例えば、インターネットやＬＡＮ（Local Area Network）などにより実現できる。

機器１０は、ネットワーク２を介した通信が可能であれば、電子機器、医療機器、及び産業用機器などどのような機器であってもよい。電子機器としては、例えば、印刷装置、複写機、複合機、スキャナ装置、及びファクシミリ装置等の画像形成装置、並びにプロジェクタ、カメラ、ネットワーク家電、蛍光灯、自動販売機、及びハンドヘルド型端末などが挙げられるが、これらに限定されるものではない。複合機は、複写機能、印刷機能、スキャナ機能、及びファクシミリ機能のうち少なくとも２つの機能を有するものである。医療機器としては、例えば、眼底検査装置、Ｘ線検査装置、血圧計、体脂肪計、視力計、及びペースメーカなどが挙げられるが、これらに限定されるものではない。産業用機器としては、例えば、電源装置、空調システム、及びガス・水道・電気等の計量システムなどが挙げられるが、これらに限定されるものではない。

なお本実施形態では、機器１０が、画像形成装置であり、情報処理装置２０の運営業者である機器メーカや機器ベンダなどにより、顧客に販売又はリースされ、当該顧客の顧客環境に設置されている場合を例に取り説明するが、これに限定されるものではない。なお、図１に示す例では、機器１０は、１台のみ図示されているが、複数台存在していてもよい。

図２は、本実施形態の機器１０のハードウェア構成の一例を示すブロック図である。図２に示すように、機器１０は、コントローラ９１０とエンジン部（Engine）９６０とをＰＣＩバスで接続した構成となる。コントローラ９１０は、機器１０の全体の制御、描画、通信、及び操作表示部９２０からの入力を制御するコントローラである。エンジン部９６０は、ＰＣＩバスに接続可能なエンジンであり、例えば、スキャナ等のスキャナエンジンなどである。エンジン部９６０には、エンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分も含まれる。

コントローラ９１０は、ＣＰＵ（Central Processing Unit）９１１と、ノースブリッジ（ＮＢ）９１３と、システムメモリ（ＭＥＭ−Ｐ）９１２と、サウスブリッジ（ＳＢ）９１４と、ローカルメモリ（ＭＥＭ−Ｃ）９１７と、ＡＳＩＣ（Application Specific Integrated Circuit）９１６と、ハードディスクドライブ（ＨＤＤ）９１８とを有し、ノースブリッジ（ＮＢ）９１３とＡＳＩＣ９１６との間をＡＧＰ（Accelerated Graphics Port）バス９１５で接続した構成となる。また、ＭＥＭ−Ｐ９１２は、ＲＯＭ（Read Only Memory）９１２ａと、ＲＡＭ（Random Access Memory）９１２ｂとをさらに有する。

ＣＰＵ９１１は、機器１０の全体制御を行うものであり、ＮＢ９１３、ＭＥＭ−Ｐ９１２およびＳＢ９１４からなるチップセットを有し、このチップセットを介して他の機器と接続される。

ＮＢ９１３は、ＣＰＵ９１１とＭＥＭ−Ｐ９１２、ＳＢ９１４、ＡＧＰバス９１５とを接続するためのブリッジであり、ＭＥＭ−Ｐ９１２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩマスタおよびＡＧＰターゲットとを有する。

ＭＥＭ−Ｐ９１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ９１２ａとＲＡＭ９１２ｂとからなる。ＲＯＭ９１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ９１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。

ＳＢ９１４は、ＮＢ９１３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。このＳＢ９１４は、ＰＣＩバスを介してＮＢ９１３と接続されている。

ＡＳＩＣ９１６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）であり、ＡＧＰバス９１５、ＰＣＩバス、ＨＤＤ９１８およびＭＥＭ−Ｃ９１７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ９１６は、ＰＣＩターゲットおよびＡＧＰマスタと、ＡＳＩＣ９１６の中核をなすアービタ（ＡＲＢ）と、ＭＥＭ−Ｃ９１７を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のＤＭＡＣ（Direct Memory Access Controller）と、エンジン部９６０との間でＰＣＩバスを介したデータ転送をおこなうＰＣＩユニットとからなる。このＡＳＩＣ９１６には、ＰＣＩバスを介して、ＵＳＢ９４０、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インタフェース（Ｉ／Ｆ）９５０が接続される。操作表示部９２０及び通信インタフェース（Ｉ／Ｆ）９３０は、ＡＳＩＣ９１６に直接接続されている。

ＭＥＭ−Ｃ９１７は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＨＤＤ９１８は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。

ＡＧＰバス９１５は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、ＭＥＭ−Ｐ９１２に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。

情報処理装置２０は、前述の機器メーカや機器ベンダなどの運営業者により運営され、当該運営業者により顧客に販売又はリースされた機器１０を遠隔で管理するサーバ装置であり、例えば、１台以上のコンピュータにより実現できる。本実施形態では、情報処理装置２０が１台のコンピュータにより実現されている場合を例に取り説明するが、これに限定されず、２台以上のコンピュータにより情報処理システムとして実現されていてもよい。

図３は、本実施形態の情報処理装置２０のハードウェア構成の一例を示すブロック図である。情報処理装置２０は、ＣＰＵやＧＰＵ（Graphics Processing Unit）などの制御装置２１と、ＲＯＭやＲＡＭなどの主記憶装置２２と、ＨＤＤやＳＳＤ（Solid State Drive）などの補助記憶装置２３と、ディスプレイなどの表示装置２４と、キーボードやマウスなどの入力装置２５と、通信インタフェースなどの通信装置２６と、を備えており、通常のコンピュータを利用したハードウェア構成となっている。

なお情報処理システム１では、情報処理装置２０による遠隔管理を実現するため、機器１０及び情報処理装置２０のそれぞれは、ＲＰＣ（Remote Procedure Call）により、相互実装するアプリケーションのメソッドに対する処理の要求及び応答を送受信できるようにされている。なお、ＲＰＣは、ＰＰＰ（Point to Point Protocol）、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）、ＳＯＡＰ（Simple Object Access Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）、及びＨＴＴＰＳ（HyperText Transfer Protocol Secure）などのプロトコルを利用した通信を行うことによって実現できる。

また本実施形態では、情報処理装置２０から機器１０への通知は、機器１０から情報処理装置２０に対して定期的に行われるポーリングのレスポンスにて行われるものとする。これにより、ファイアウォールのパケットフィルタリング機能などにより、外部からの情報処理装置２０へのアクセスが遮断されるような状況下においても、情報処理装置２０は、機器１０の遠隔管理を実現できる。

図４は、本実施形態の機器１０のソフトウェア構成の一例を示すブロック図である。図４に示すように、機器１０は、アプリケーション層のソフトウェアとして、ネットワークアプリ１１１と、コピー用のアプリケーションであるコピーアプリ１１２と、ファックス用のアプリケーションであるファックスアプリ１１３と、プリンタ用のアプリケーションであるプリンタアプリ１１４と、スキャナ用のアプリケーションであるスキャナアプリ１１５と、ネットファイルアプリ１１６と、ウェブ（ＷＥＢ）ページ閲覧用のアプリケーションであるウェブアプリ１１７と、を含む。

ネットワークアプリ１１１は、ネットワーク２を介した通信を行うアプリケーションであり、機器１０の状態を示す状態情報、カウンタ情報、及びファームウェアバージョン情報を、情報処理装置２０に通知したり、異常や消耗品の残量切れなどの障害の発生を、情報処理装置２０に通知したりする。

なお、以下では、状態情報、カウンタ情報、及びファームウェアバージョン情報など予め通知するタイミングが定められた情報の通知を単に「通知」と称し、障害の発生など不定期なタイミングでの情報の通知を「コール」と称する場合がある。

また図４に示すように、機器１０は、サービス層のソフトウェアとして、ＵＩを制御するＵＩ制御部１２１と、エンジン制御部１２２と、メモリを制御するメモリ制御部１２３と、通信制御部１２４と、ファックス機能を実現するためのファックス制御部１２５と、システム制御部１２６と、画像ファイルの転送を制御する画像制御部１２７と、ユーザ情報を管理するユーザ管理部１２８と、を含む。

エンジン制御部１２２は、エンジン１７０を制御する。エンジン１７０としては、プロッタやスキャナエンジンなどが挙げられるが、これらに限定されるものではない。

通信制御部１２４は、外部と通信する際のネットワーク２とアプリケーション層のアプリとの仲介処理を行う。

システム制御部１２６は、アプリケーション層の各アプリと、サービス層の各サービス及びエンジン１７０と、の間の責務調停を行う。

なおアプリケーション層の各アプリと、サービス層の各サービスとのやり取りは、インタフェース１２０を介して行われる。

主制御部１３０は、システムの制御やリソースの管理を行う。

ＯＳ１４０は、ＵＮＩＸ（登録商標）やＬＩＮＵＸ（登録商標）などの汎用ＯＳ（Operating System）を用いればよい。

画像管理部１５０は、画像を一時保存するメモリを管理する。

なおサービス層の各サービス、主制御部１３０、ＯＳ１４０、及び画像管理部１５０と、エンジン１７０とのやり取りは、インタフェース１６０を介して行われる。

図５は、本実施形態の情報処理システム１の機能構成の一例を示すブロック図である。図５に示すように、機器１０は、通信制御部１２４と、システム制御部１２６と、記憶部１２００と、を含む。通信制御部１２４は、第１の通知部１２４１、第２の通知部１２４２、及び対象情報通知部１２４３を含む。システム制御部１２６は、生成部１２６０、第１の取得部１２６１、第２の取得部１２６２（第２の取得部及び状態情報取得部の一例）、及び対象情報取得部１２６３を含む。

通信制御部１２４（第１の通知部１２４１、第２の通知部１２４２、及び対象情報通知部１２４３）は、例えば、ＣＰＵ９１１、システムメモリ９１２、及び通信Ｉ／Ｆ９３０などにより実現できる。システム制御部１２６（生成部１２６０、第１の取得部１２６１、第２の取得部１２６２、及び対象情報取得部１２６３）は、例えば、ＣＰＵ９１１及びシステムメモリ９１２などにより実現できる。記憶部１２００は、例えば、ＨＤＤ９１８などにより実現できる。

また図５に示すように、情報処理装置２０は、通信部２０１と、予測部２０３と、診断部２０５と、を含む。通信部２０１は、例えば、制御装置２１、主記憶装置２２、及び通信装置２６などにより実現できる。予測部２０３及び診断部２０５は、例えば、制御装置２１及び主記憶装置２２などにより実現できる。

生成部１２６０は、機器１０の状態を監視して、機器１０の状態を時系列で示す時系列の状態情報を生成する。具体的には、システム制御部１２６は、アプリケーション層の各アプリ、サービス層の各サービス、及びエンジン１７０などにより、機器１０の状態が検知され、状態情報としての記録（ロギング）が要求されると、要求された状態情報を時系列の順に記憶部１２００に書き込むことで、時系列の状態情報（ログ情報）を生成する。

なお、各アプリ、各サービス、及びエンジン１７０は、それぞれ、自身の処理に関わる機器１０の状態を検知するため、当然、それぞれが検知する状態の内容は異なる。また、各アプリ、各サービス、及びエンジン１７０から記録（ロギング）が要求される状態情報は、検知された状態そのものを示す情報であってもよいし、各アプリ、各サービス、及びエンジン１７０側で検知した状態の内容を加工した情報（例えば、解析結果を示す情報や、検知した状態のうち障害の発生への影響度が大きい状態を示す情報）であってもよい。

状態情報としては、例えば、電圧値、電流値、トナー濃度、用紙の搬送時間（検知タイミング）などセンサによりセンシングされた値、及びその時刻を示す時刻情報の組などが挙げられるが、これに限定されるものではない。

第１の取得部１２６１は、定期的に訪れる通知タイミングになると、機器１０の現時点での状態を示す第１の状態情報を取得する。定期的に訪れる通知タイミングは、当該通知タイミングでの機器１０の状態を情報処理装置２０に通知するタイミングであり、例えば、毎日０：００時など予め設定されている。

具体的には、第１の取得部１２６１は、定期的に訪れる通知タイミングになると、各アプリ、各サービス、及びエンジン１７０などに機器１０の現時点での状態の検知を要求することで、各アプリ、各サービス、及びエンジン１７０などから、機器１０の現時点での状態を示す第１の状態情報を取得する。なお、第１の取得部１２６１は、ＭＥＭ−Ｐ９１２やＨＤＤ９１８に記憶されている情報も第１の状態情報に含める場合、ＭＥＭ−Ｐ９１２やＨＤＤ９１８からも情報を取得する。このような情報としては、例えば、機器１０のファームウェアバージョン情報、カウンタ値（印刷枚数）、及び機体番号などが挙げられるが、これらに限定されるものではない。なお、カウンタ値や機体番号など初期化されてしまうことを防止する必要がある情報は、基本的にＨＤＤ９１８ではなく、ＭＥＭ−Ｐ９１２に記憶されている。

なお、エンジン１７０の状態については、エンジン１７０が省エネルギー状態である場合を考慮し、エンジン１７０が省エネルギー状態に移行する直前の状態の情報をＭＥＭ−Ｐ９１２やＨＤＤ９１８に記憶しておき、第１の取得部１２６１は、ＭＥＭ−Ｐ９１２やＨＤＤ９１８から、エンジン１７０の第１の状態情報を取得するようにしてもよい。このようにすれば、エンジン１７０を省エネルギー状態から復帰させずにエンジン１７０の第１の状態情報を取得でき、省エネルギー効果を妨げずに済む。

第１の通知部１２４１は、前述の定期的に訪れる通知タイミングを検知し、第１の取得部１２６１に通知することで、第１の状態情報の取得を要求する。そして第１の通知部１２４１は、第１の取得部１２６１により第１の状態情報が取得されると、当該第１の状態情報を情報処理装置２０に通知する。

なお、第１の通知部１２４１は、第１の状態情報の通知後、情報処理装置２０からのレスポンスで第１の状態情報の通知結果を取得し、第１の状態情報の通知の成否を確認して、第２の通知部１２４２に通知する。

第２の取得部１２６２は、第１の通知部１２４１により第１の状態情報の通知が行われると、記憶部１２００に記憶されている時系列の状態情報の中から、情報処理装置２０に未通知の状態情報である第２の状態情報を取得する。具体的には、第２の取得部１２６２は、記憶部１２００に記憶されている時系列の状態情報の中から、情報処理装置２０への第２の状態情報の通知に前回成功した日時から現時点の日時までの状態情報を、情報処理装置２０に未通知の状態情報である第２の状態情報として取得する。

なお、第２の取得部１２６２は、第１の通知部１２４１による第１の状態情報の通知が成功した場合、第２の状態情報を取得し、第１の通知部１２４１による第１の状態情報の通知が失敗した場合、第２の状態情報を取得しない。

第２の通知部１２４２は、第２の取得部１２６２により第２の状態情報が取得されると、当該第２の状態情報を情報処理装置２０に通知する。具体的には、第２の通知部１２４２は、第１の通知部１２４１から第１の状態情報の通知が成功した旨の通知を受けると、第２の取得部１２６２に第２の状態情報の取得を要求し、第２の取得部１２６２から第２の状態情報を取得して、情報処理装置２０に通知する。なお、第２の通知部１２４２は、第１の通知部１２４１から第１の状態情報の通知が失敗した旨の通知を受けた場合、第２の取得部１２６２に第２の状態情報の取得を要求せず、情報処理装置２０に通知しない。

そして、第２の通知部１２４２は、第２の状態情報の通知後、情報処理装置２０からのレスポンスで第２の状態情報の通知結果を取得し、第２の状態情報の通知の成否を確認して、第２の取得部１２６２に通知する。第２の取得部１２６２は、第２の通知部１２４２から第２の状態情報の通知が成功した旨の通知を受けると、上述した第２の状態情報の範囲を定めるために用いた現時点の日時（第２の状態情報における最新の日時）を、情報処理装置２０への第２の状態情報の通知に成功した最新の日時とする。なお、第２の取得部１２６２は、第２の通知部１２４２から第２の状態情報の通知が失敗した旨の通知を受けた場合、この処理は行わない。

対象情報取得部１２６３は、機器１０での障害の発生に伴い発生する通知タイミングになると、当該障害の発生に伴い通知が要請される対象情報を取得する。機器１０での障害の発生に伴い発生する通知タイミングは、コールのタイミングであり、例えば、当該障害の発生時である。

具体的には、対象情報取得部１２６３は、機器１０での障害の発生に伴い発生する通知タイミングになると、各アプリ、各サービス、及びエンジン１７０のうち当該障害に関わるアプリ、サービス、又はエンジンに対象情報を要求することで、対象情報を取得する。なお、対象情報の内容は、障害の種別毎になるが、基本的に、上述した状態情報のような、センサによりセンシングされた値などが挙げられる。例えば、障害が連続ジャム（連続紙詰まり）であれば、対象情報として、用紙の搬送時間（検知タイミング）などが挙げられる。

なお、対象情報取得部１２６３は、ＭＥＭ−Ｐ９１２やＨＤＤ９１８に記憶されている情報も対象情報に含める場合、ＭＥＭ−Ｐ９１２やＨＤＤ９１８からも情報を取得する。このような情報としては、例えば、機器１０のファームウェアバージョン情報、カウンタ値（印刷枚数）、及び機体番号などが挙げられるが、これらに限定されるものではない。

対象情報通知部１２４３は、前述の機器１０での障害の発生に伴い発生する通知タイミングを検知し、対象情報取得部１２６３に通知することで、対象情報の取得を要求する。対象情報通知部１２４３は、例えば、各アプリ、各サービス、及びエンジン１７０のうち、発生した障害に関わるアプリ、サービス、又はエンジンからの通知により、障害の発生に伴い発生する通知タイミングを検知する。そして対象情報通知部１２４３は、対象情報取得部１２６３により対象情報が取得されると、当該対象情報を情報処理装置２０に通知する。

なお、対象情報通知部１２４３は、対象情報の通知後、情報処理装置２０からのレスポンスで対象情報の通知結果を取得し、対象情報の通知の成否を確認して、第２の通知部１２４２に通知する。

第２の取得部１２６２は、対象情報通知部１２４３により対象情報の通知が行われると、記憶部１２００に記憶されている時系列の状態情報の中から、障害の発生の所定時間前以降の状態情報である第３の状態情報を取得する。具体的には、第２の取得部１２６２は、記憶部１２００に記憶されている時系列の状態情報の中から、障害が発生した日時から所定時間前（例えば、３時間前）までの状態情報を第３の状態情報として取得する。

なお、第２の取得部１２６２は、対象情報通知部１２４３による対象情報の通知が成功した場合、第３の状態情報を取得し、対象情報通知部１２４３による対象情報の通知が失敗した場合、第３の状態情報を取得しない。

第２の通知部１２４２は、第２の取得部１２６２により第３の状態情報が取得されると、当該第３の状態情報を情報処理装置２０に通知する。具体的には、第２の通知部１２４２は、対象情報通知部１２４３から対象情報の通知が成功した旨の通知を受けると、第２の取得部１２６２に第３の状態情報の取得を要求し、第２の取得部１２６２から第３の状態情報を取得して、情報処理装置２０に通知する。なお、第２の通知部１２４２は、対象情報通知部１２４３から対象情報の通知が失敗した旨の通知を受けた場合、第２の取得部１２６２に第３の状態情報の取得を要求せず、情報処理装置２０に通知しない。

通信部２０１は、機器１０から第１の状態情報を受信し、レスポンスで第１の状態情報の通知結果を機器１０に送信する。また通信部２０１は、機器１０から第２の状態情報を受信し、レスポンスで第２の状態情報の通知結果を機器１０に送信する。また通信部２０１は、機器１０から対象情報を受信し、レスポンスで対象情報の通知結果を機器１０に送信する。また通信部２０１は、機器１０から第３の状態情報を受信し、レスポンスで第３の状態情報の通知結果を機器１０に送信する。

予測部２０３は、通信部２０１により受信された第１の状態情報及び第２の状態情報に基づいて、機器１０の将来の状態を予測する。例えば、予測部２０３は、機器１０に将来発生する可能性がある障害の発生時期を予測する。

なお予測部２０３は、例えば、第１の状態情報を用いて、第１の状態情報が通知される間隔よりも長い間隔での機器の状態変動を解析し、例えば、機器１０の経年劣化に伴う障害の発生時期などを予測する。また予測部２０３は、例えば、第２の状態情報を用いて、突発的に生じる状態変動のような、機器から情報が通知される間隔よりも短い間隔で完結してしまうような状態変動を解析し、例えば、当該状態変動に伴う障害の次回の発生時期などを予測する。

診断部２０５は、通信部２０１により受信された対象情報及び第２の状態情報に基づいて、機器１０に発生した障害を診断する。

なお診断部２０５は、例えば、対象情報を用いて機器１０に発生した障害の概要を診断し、例えば、第３の状態情報を用いて機器１０に発生した障害の詳細を診断する。この診断の結果、機器１０の顧客先に対するカスタマーエンジニアの手配や、顧客への障害対応方法の連絡などが行われる。

図６は、本実施形態の情報処理システム１で行われる時系列の状態情報の生成処理の一例を示すシーケンス図である。

まず、各サービス又は各アプリは、機器１０の状態の検知タイミングになると、当該機器１０の状態を検知し、状態情報としての書き込みを要求する（ステップＳ１０１）。

続いて、システム制御部１２６の生成部１２６０は、書き込みを要求された状態情報を時系列の順に記憶部１２００に書き込むことで、時系列の状態情報を生成する（ステップＳ１０３）。

続いて、生成部１２６０は、書き込み結果を、書き込みを要求したサービス又はアプリに通知する（ステップＳ１０５）。

なお、ステップＳ１０１〜ステップＳ１０５の処理は、一定の周期で行われ、サービス及びアプリ毎に、当該周期は異なっていてもよい。また、システム制御部１２６に状態情報の書き込みを要求するサービスが、システム制御部１２６自身であってもよい。

続いて、エンジン１７０は、機器１０の状態の検知タイミングになると、当該機器１０の状態を検知し、状態情報としての書き込みを要求する（ステップＳ１１１）。

続いて、システム制御部１２６の生成部１２６０は、書き込みを要求された状態情報を時系列の順に記憶部１２００に書き込むことで、時系列の状態情報を生成する（ステップＳ１１３）。

続いて、生成部１２６０は、書き込み結果を、エンジン１７０に通知する（ステップＳ１１５）。

なお、ステップＳ１１１〜ステップＳ１１５の処理は、一定の周期で行われ、この周期は、サービス及びアプリにおける周期と異なっていてもよい。

図７は、本実施形態の情報処理システム１で行われる第１の状態情報及び第２の状態情報の通知処理の一例を示すシーケンス図である。

まず、通信制御部１２４の第１の通知部１２４１は、定期的に訪れる通知タイミングを検知すると（ステップＳ２０１）、システム制御部１２６の第１の取得部１２６１に第１の状態情報の取得を要求する（ステップＳ２０３）。

続いて、第１の取得部１２６１は、第１の状態情報を取得し（ステップＳ２０５）、第１の通知部１２４１に通知する（ステップＳ２０７）。

続いて、第１の通知部１２４１は、第１の取得部１２６１により取得された第１の状態情報を情報処理装置２０に通知し（ステップＳ２０９）、情報処理装置２０からのレスポンスで第１の状態情報の通知結果を取得し（ステップＳ２１１）、第１の状態情報の通知の成否を確認する（ステップＳ２１３）。

なお、ステップＳ２１５以降の処理は、第１の状態情報の通知に成功した場合に行われ、第１の状態情報の通知に失敗した場合は行われない。

続いて、第１の通知部１２４１は、第１の状態情報の通知に成功した場合、その旨を通信制御部１２４の第２の通知部１２４２に通知し、第２の通知部１２４２は、システム制御部１２６の第２の取得部１２６２に第２の状態情報の取得を要求する（ステップＳ２１５）。

続いて、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている通知日時情報を取得する（ステップＳ２１７）。通知日時情報は、第２の状態情報の通知に前回成功した日時を示す情報である。

続いて、第２の取得部１２６２は、記憶部１２００に記憶されている時系列の状態情報の中から、通知日時情報が示す第２の状態情報の通知に前回成功した日時から現時点の日時までの状態情報を、情報処理装置２０に未通知の状態情報である第２の状態情報として取得し（ステップＳ２１９）、第２の通知部１２４２に通知する（ステップＳ２２１）。

続いて、第２の通知部１２４２は、第２の取得部１２６２により取得された第２の状態情報を情報処理装置２０に通知し（ステップＳ２２３）、情報処理装置２０からのレスポンスで第２の状態情報の通知結果を取得し（ステップＳ２２５）、第２の状態情報の通知の成否を確認する（ステップＳ２２７）。

なお、ステップＳ２２９以降の処理は、第２の状態情報の通知に成功した場合に行われ、第２の状態情報の通知に失敗した場合は行われない。

続いて、第２の通知部１２４２は、第２の状態情報の通知に成功した場合、通知日時情報の更新を第２の取得部１２６２に要求し（ステップＳ２２９）、第２の取得部１２６２は、通知日時情報が示す日時を、第２の状態情報の範囲を定めるために用いた現時点の日時（第２の状態情報における最新の日時）を示すように更新し（ステップＳ２３１）、更新完了を第２の通知部１２４２に通知する（ステップＳ２３３）。

図８は、本実施形態の情報処理システム１で行われる対象情報及び第２の状態情報の通知処理の一例を示すシーケンス図である。

まず、通信制御部１２４の対象情報通知部１２４３は、機器１０での障害の発生に伴い発生する通知タイミングを検知すると（ステップＳ３０１）、システム制御部１２６の対象情報取得部１２６３に対象情報の取得を要求する（ステップＳ３０３）。

続いて、対象情報取得部１２６３は、対象情報を取得し（ステップＳ３０５）、対象情報通知部１２４３に通知する（ステップＳ３０７）。

続いて、対象情報通知部１２４３は、対象情報取得部１２６３により取得された対象情報を情報処理装置２０に通知し（ステップＳ３０９）、情報処理装置２０からのレスポンスで対象情報の通知結果を取得し（ステップＳ３１１）、対象情報の通知の成否を確認する（ステップＳ３１３）。

なお、ステップＳ３１５以降の処理は、対象情報の通知に成功した場合に行われ、対象情報の通知に失敗した場合は行われない。

続いて、対象情報通知部１２４３は、対象情報の通知に成功した場合、その旨を通信制御部１２４の第２の通知部１２４２に通知し、第２の通知部１２４２は、システム制御部１２６の第２の取得部１２６２に第３の状態情報の取得を要求する（ステップＳ３１５）。

続いて、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている所定時間情報を取得する（ステップＳ３１７）。所定時間情報は、障害の発生日時からどの程度の期間の状態情報を第３の状態情報とするかを決定するための所定時間を示す情報である。

続いて、第２の取得部１２６２は、記憶部１２００に記憶されている時系列の状態情報の中から、障害が発生した日時から所定時間情報が示す所定時間前（例えば、３時間前）までの状態情報を第３の状態情報として取得し（ステップＳ３１９）、第２の通知部１２４２に通知する（ステップＳ３２１）。

続いて、第２の通知部１２４２は、第２の取得部１２６２により取得された第３の状態情報を情報処理装置２０に通知し（ステップＳ３２３）、情報処理装置２０からのレスポンスで第３の状態情報の通知結果を取得する（ステップＳ３２５）。

図９は、本実施形態の情報処理システム１で行われる通知処理の一例を示すフローチャートである。

まず、第１の通知部１２４１は、定期的に訪れる定時通知タイミングか否かを判定する（ステップＳ４０１）。

定時通知タイミングの場合（ステップＳ４０１でＹｅｓ）、第１の取得部１２６１は、第１の状態情報を取得し（ステップＳ４０３）、第１の通知部１２４１は、当該第１の状態情報を情報処理装置２０に通知する（ステップＳ４０５）。

続いて、第１の通知部１２４１は、第１の状態情報の通知後、情報処理装置２０からのレスポンスで第１の状態情報の通知の成否を判定する（ステップＳ４０７）。なお、第１の状態情報の通知に失敗した場合（ステップＳ４０７でＮｏ）、ステップＳ４０１へ戻る。

第１の状態情報の通知に成功した場合（ステップＳ４０７でＹｅｓ）、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている通知日時情報を取得し（ステップＳ４０９）、記憶部１２００に記憶されている時系列の状態情報の中から、通知日時情報が示す第２の状態情報の通知に前回成功した日時から現時点の日時までの状態情報を、情報処理装置２０に未通知の状態情報である第２の状態情報として取得する（ステップＳ４１１）。

続いて、第２の通知部１２４２は、第２の取得部１２６２により取得された第２の状態情報を情報処理装置２０に通知する（ステップＳ４１３）。

続いて、第２の通知部１２４２は、第２の状態情報の通知後、情報処理装置２０からのレスポンスで第２の状態情報の通知の成否を判定する（ステップＳ４１５）。なお、第２の状態情報の通知に失敗した場合（ステップＳ４１５でＮｏ）、ステップＳ４０１へ戻る。

第２の状態情報の通知に成功した場合（ステップＳ４１５でＹｅｓ）、第２の取得部１２６２は、通知日時情報が示す日時を、第２の状態情報の範囲を定めるために用いた現時点の日時（第２の状態情報における最新の日時）を示すように更新し（ステップＳ４１７）、ステップＳ４０１へ戻る。

一方、定時通知タイミングでない場合（ステップＳ４０１でＮｏ）、対象情報通知部１２４３は、機器１０での障害の発生に伴い発生する通知タイミングか否かを判定する（ステップＳ４１９）。なお、障害の発生に伴い発生する通知タイミングでない場合（ステップＳ４１９でＮｏ）、ステップＳ４０１へ戻る。

障害の発生に伴い発生する通知タイミングの場合（ステップＳ４１９でＹｅｓ）、対象情報取得部１２６３は、対象情報を取得し（ステップＳ４２１）、対象情報通知部１２４３は、対象情報取得部１２６３により取得された対象情報を情報処理装置２０に通知する（ステップＳ４２３）。

続いて、対象情報通知部１２４３は、対象情報の通知後、情報処理装置２０からのレスポンスで対象情報の通知の成否を判定する（ステップＳ４２５）。なお、対象情報の通知に失敗した場合（ステップＳ４２５でＮｏ）、ステップＳ４０１へ戻る。

対象情報の通知に成功した場合（ステップＳ４２５でＹｅｓ）、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている所定時間情報を取得し（ステップＳ４２７）、記憶部１２００に記憶されている時系列の状態情報の中から、障害が発生した日時から所定時間情報が示す所定時間前（例えば、３時間前）までの状態情報を第３の状態情報として取得する（ステップＳ４２９）。

続いて、第２の通知部１２４２は、第２の取得部１２６２により取得された第３の状態情報を情報処理装置２０に通知し（ステップＳ４３１）、ステップＳ４０１へ戻る。

図１０は、本実施形態の情報処理システム１で行われる第１の状態情報及び第２の状態情報の通知処理の具体例を示す図である。なお、図１０に示す例では、第１の状態情報を通知するための定時通知の通知タイミングは、毎日の０：００であるものとするが、これに限定されるものではない。

図１０に示すように、１０／１の０：００では、第１の状態情報の定時通知に成功するとともに、定時通知後の第２の状態情報の通知にも成功しているものとする。

続いて、次の定時通知の通知タイミングである１０／２の０：００では、第１の状態情報の定時通知に成功するとともに、定時通知後の第２の状態情報の通知にも成功している。なお、この場合の第２の状態情報は、第２の状態情報の通知に前回成功した日時である１０／１の０：００〜現時点の日時である１０／２の０：００までの範囲の状態情報となる。

続いて、次の定時通知の通知タイミングである１０／３の０：００では、第１の状態情報の定時通知に成功しているが、定時通知後の第２の状態情報の通知には失敗している。なお、この場合の第２の状態情報は、第２の状態情報の通知に前回成功した日時である１０／２の０：００〜現時点の日時である１０／３の０：００までの範囲の状態情報となる。

続いて、次の定時通知の通知タイミングである１０／４の０：００では、第１の状態情報の定時通知に成功するとともに、定時通知後の第２の状態情報の通知にも成功している。なお、この場合の第２の状態情報は、第２の状態情報の通知に前回成功した日時である１０／２の０：００〜現時点の日時である１０／４の０：００までの範囲の状態情報となる。つまり、１０／４の０：００の第２の状態情報の通知では、前回通知に失敗した１０／２の０：００〜１０／３の０：００までの範囲の状態情報も第２の状態情報に含まれている。

このように本実施形態では、第２の状態情報の通知に失敗した場合、再通知するのではなく、次回の第２の状態情報を通知する際に併せて通知する。第２の状態情報は、情報処理装置２０側において、機器１０の将来の状態を予測するために用いられるため、即時性が要求されず、再通知に伴うネットワーク負荷の増加を抑えるためである。なお、定時通知後に機器１０が再起動等する場合もあるため、定時通知には成功したが、第２の状態情報の通知に失敗（第２の状態情報を通知できない）するような場合も十分に考えられる。

続いて、次の定時通知の通知タイミングである１０／５の０：００では、第１の状態情報の定時通知に失敗し、定時通知後の第２の状態情報の通知は行われていない。

続いて、次の定時通知の通知タイミングである１０／６の０：００では、第１の状態情報の定時通知に成功するとともに、定時通知後の第２の状態情報の通知にも成功している。なお、この場合の第２の状態情報は、第２の状態情報の通知に前回成功した日時である１０／４の０：００〜現時点の日時である１０／６の０：００までの範囲の状態情報となる。つまり、１０／６の０：００の第２の状態情報の通知では、前回通知が行われなかった１０／４の０：００〜１０／５の０：００までの範囲の状態情報も第２の状態情報に含まれている。

このように本実施形態では、定時通知に失敗した場合、第２の状態情報も通知せず、次回の第２の状態情報を通知する際に併せて通知する。第２の状態情報は、情報処理装置２０側において、機器１０の将来の状態を予測するために用いられるため、即時性が要求されず、再通知に伴うネットワーク負荷の増加を抑えるためである。

図１１は、本実施形態の情報処理システム１で行われる対象情報及び第３の状態情報の通知処理の具体例を示す図である。なお、図１１に示す例では、所定時間が３時間であり、第３の状態情報が、障害が発生した日時から３時間前までの状態情報である場合を例に取り説明するが、これに限定されるものではない。また、図１１に示す例でも、説明の関係上、第１の状態情報及び第２の状態情報の通知処理も含めている。図１１に示す例では、第１の状態情報を通知するための定時通知の通知タイミングは、毎日の０：００であるものとするが、これに限定されるものではない。

図１１に示すように、１０／１の０：００では、第１の状態情報の定時通知に成功するとともに、定時通知後の第２の状態情報の通知にも成功しているものとする。

続いて、１０／１の１２：００に機器１０に障害が発生すると、対象情報を通知する障害通知に成功するとともに、障害通知後の第３の状態情報の通知にも成功している。なお、この場合の第３の状態情報は、障害が発生した日時の３時間前である１０／１の９：００〜障害が発生した日時である１０／１の１２：００までの範囲の状態情報となる。

続いて、１０／２の１２：００に機器１０に障害が発生すると、対象情報を通知する障害通知に失敗し、障害通知後の第３の状態情報の通知は行われていない。

続いて、次の定時通知の通知タイミングである１０／３の０：００では、第１の状態情報の定時通知に成功するとともに、定時通知後の第２の状態情報の通知にも成功している。なお、この場合の第２の状態情報は、第２の状態情報の通知に前回成功した日時である１０／２の０：００〜現時点の日時である１０／３の０：００までの範囲の状態情報となる。

以上のように本実施形態によれば、機器の現時点での状態を示す第１の状態情報の通知と、第１の状態情報の通知間の時系列の状態情報である第２の状態情報の通知と、を併用するため、通信負荷を抑えつつ、機器に対する多様な解析を行うことが可能になる。

同様に本実施形態によれば、障害の発生に伴い通知が要請される対象情報の通知と、障害の発生の所定時間前以降の状態情報である第３の状態情報の通知と、を併用するため、通信負荷を抑えつつ、機器に対する多様な解析を行うことが可能になる。

なお本実施形態では、従来では、第１の状態情報及び対象情報の通知のみを行っていたような機器（情報処理システム）に、第２の状態情報や第３の状態情報の通知を新たな機能として組み込むような形態を想定しているため、第１の状態情報の通知と第２の状態情報の通知とを併用するとともに、対象情報の通知と第３の状態情報の通知とを併用するようにしている。これにより、今までに開発された資産（第１の状態情報や対象情報の解析ロジック）を利用しつつ、より高度な解析が可能となる。

（変形例１）
上記実施形態において、第２の状態情報や第３の状態情報の容量に上限を設けるようにしてもよい。

この場合、第２の状態情報については、第２の取得部１２６２は、時系列の状態情報に含まれる情報処理装置２０に未通知の状態情報の容量が、閾値を超えるか否かを判定し、閾値を超える場合、未通知の状態情報から一部の情報を削減して容量が閾値に収まるように加工した状態情報を第２の状態情報として取得するようにすればよい。

同様に、第３の状態情報については、第２の取得部１２６２は、時系列の状態情報に含まれる障害の発生の所定時間前以降の状態情報の容量が、閾値を超えるか否かを判定し、閾値を超える場合、障害の発生の所定時間前以降の状態情報から一部の情報を削減して容量が閾値に収まるように加工した状態情報を取得するようにすればよい。

情報の削減方法としては、時系列の状態情報を古い順に削除、時系列の状態情報を一定間隔で間引く、情報処理装置２０に削除する情報を問い合わせるなどの手法が挙げられるが、これらに限定されるものではない。

図１２は、本実施形態の機器１０で行われる第２の状態情報決定処理の一例を示すフローチャートであり、図９に示すフローチャートのステップＳ４１１で行われる。

まず、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている閾値を取得するとともに、記憶部１２００に記憶されている時系列の状態情報のうちの、通知日時情報が示す第２の状態情報の通知に前回成功した日時から現時点の日時までの状態情報の容量を取得する（ステップＳ５０１）。

続いて、第２の取得部１２６２は、取得した容量が閾値を超えるか否かを判定する（ステップＳ５０３）。

取得した容量が閾値を超える場合（ステップＳ５０３でＹｅｓ）、第２の取得部１２６２は、通知日時情報が示す第２の状態情報の通知に前回成功した日時から現時点の日時までの状態情報の中から、一部の情報を削減して容量が閾値に収まるように加工した状態情報を第２の状態情報に決定する（ステップＳ５０５）。

続いて、第２の取得部１２６２は、記憶部１２００から決定した第２の状態情報を取得する（ステップＳ５０７）。

一方、取得した容量が閾値を超えない場合（ステップＳ５０３でＮｏ）、第２の取得部１２６２は、記憶部１２００から、通知日時情報が示す第２の状態情報の通知に前回成功した日時から現時点の日時までの状態情報を第２の状態情報として取得する（ステップＳ５０７）。

図１３は、本実施形態の機器１０で行われる第３の状態情報決定処理の一例を示すフローチャートであり、図９に示すフローチャートのステップＳ４２９で行われる。

まず、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている閾値を取得するとともに、記憶部１２００に記憶されている時系列の状態情報のうちの、障害が発生した日時から所定時間情報が示す所定時間前（例えば、３時間前）までの状態情報の容量を取得する（ステップＳ５１１）。

続いて、第２の取得部１２６２は、取得した容量が閾値を超えるか否かを判定する（ステップＳ５１３）。

取得した容量が閾値を超える場合（ステップＳ５１３でＹｅｓ）、第２の取得部１２６２は、障害が発生した日時から所定時間情報が示す所定時間前（例えば、３時間前）までの状態情報の中から、一部の情報を削減して容量が閾値に収まるように加工した状態情報を第３の状態情報に決定する（ステップＳ５１５）。

続いて、第２の取得部１２６２は、記憶部１２００から決定した第３の状態情報を取得する（ステップＳ５１７）。

一方、取得した容量が閾値を超えない場合（ステップＳ５１３でＮｏ）、第２の取得部１２６２は、記憶部１２００から、障害が発生した日時から所定時間情報が示す所定時間前（例えば、３時間前）までの状態情報を第３の状態情報として取得する（ステップＳ５１７）。

（変形例２）
上記実施形態において、障害の種別に応じて、第３の状態情報の通知を行うようにしてもよい。

具体的には、第２の取得部１２６２は、障害の種別に基づいて第３の状態情報の取得の要否を判定し、第３の状態情報の取得が必要な場合、状態情報を取得し、第２の通知部１２４２は、当該第３の状態情報を情報処理装置２０に通知する。

図１４は、本実施形態の情報処理システム１で行われる通知要否情報の書き込み処理の一例を示すシーケンス図である。

まず、通信制御部１２４の第２の通知部１２４２は、情報処理装置２０にポーリングを行う（ステップＳ６０１）。

続いて、情報処理装置２０の通信部２０１は、ポーリングの応答として、障害の種別毎に第３の状態情報の通知の要否を定めた通知要否情報を機器１０に通知し（ステップＳ６０３）、第２の通知部１２４２は、当該通知要否情報を機器１０のシステム制御部１２６に通知する（ステップＳ６０５）。

続いて、システム制御部１２６の第２の取得部１２６２は、通知された通知要否情報をＭＥＭ−Ｐ９１２に書き込む（ステップＳ６０７）。

図１５は、変形例２の情報処理システム１で行われる対象情報及び第２の状態情報の通知処理の一例を示すシーケンス図である。

まず、ステップＳ３０１〜Ｓ３１５までの処理は、図８に示すシーケンス図と同様である。

続いて、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている通知要否情報を取得する（ステップＳ３３１）。

続いて、第２の取得部１２６２は、通知要否情報を参照して、発生した障害が第３の状態情報の通知の要否を判定する（ステップＳ３３３）。

なお、ステップＳ３１７以降の処理は、第３の状態情報の通知が必要な場合に行われ、第３の状態情報の通知が不要な場合は行われない。

続いて、ステップＳ３１７〜Ｓ３２５までの処理は、図８に示すシーケンス図と同様である。

図１６は、変形例２の情報処理システム１で行われる通知処理の一例を示すフローチャートである。

まず、ステップＳ４０１〜Ｓ４２５までの処理は、図９に示すフローチャートと同様である。

続いて、第２の取得部１２６２は、ＭＥＭ−Ｐ９１２に記憶されている通知要否情報を取得し、発生した障害が第３の状態情報の通知が必要か否かを判定する（ステップＳ４２６）。第３の状態情報の通知が必要な場合（ステップＳ４２６でＹｅｓ）、ステップＳ４２７へ進み、第３の状態情報の通知が不要な場合（ステップＳ４２６でＮｏ）、ステップＳ４０１へ戻る。

続いて、ステップＳ４２７〜Ｓ４３１までの処理は、図９に示すフローチャートと同様である。

（プログラム）
上記実施形態の機器１０及び情報処理装置２０（以下、「上記実施形態の各装置」と称する）で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、メモリカード、ＤＶＤ（Digital Versatile Disk）、フレキシブルディスク（ＦＤ）等のコンピュータで読み取り可能な記憶媒体に記憶されて提供される。

また、上記実施形態の各装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するようにしてもよい。また、上記実施形態の各装置で実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するようにしてもよい。また、上記実施形態の各装置で実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するようにしてもよい。

上記実施形態の各装置で実行されるプログラムは、上述した各部をコンピュータ上で実現させるためのモジュール構成となっている。実際のハードウェアとしては、例えば、ＣＰＵがＲＯＭからプログラムをＲＡＭ上に読み出して実行することにより、上記各機能部がコンピュータ上で実現されるようになっている。

なお、上記実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。上記新規な実施の形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これらの実施の形態は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１情報処理システム
２ネットワーク
１０機器
２０情報処理装置
１２４通信制御部
１２６システム制御部
２０１通信部
２０３予測部
２０５診断部
１２００記憶部
１２４１第１の通知部
１２４２第２の通知部
１２４３対象情報通知部
１２６０生成部
１２６１第１の取得部
１２６２第２の取得部
１２６３対象情報取得部

特許第５３７０８３２号公報

Claims

情報処理装置とネットワークを介して接続される機器であって、
検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成部と、
定期的に訪れる通知タイミングになると、前記機器の現時点での状態を示す第１の状態情報を取得する第１の取得部と、
前記第１の状態情報が取得されると、当該第１の状態情報を前記情報処理装置に通知する第１の通知部と、
前記第１の状態情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記情報処理装置に未通知の状態情報である第２の状態情報を取得する第２の取得部と、
前記第２の状態情報が取得されると、当該第２の状態情報を前記情報処理装置に通知する第２の通知部と、
を備える機器。
前記第２の取得部は、前記第１の状態情報の通知が失敗した場合、前記第２の状態情報を取得せず、
前記第２の通知部は、前記第２の状態情報を通知しない請求項１に記載の機器。
前記第２の取得部は、前記記憶部に時系列に記憶されている状態情報に含まれる前記情報処理装置に未通知の状態情報の容量が、閾値を超えるか否かを判定し、前記閾値を超える場合、前記未通知の状態情報から一部の情報を削減して前記容量が前記閾値に収まるように加工した状態情報を前記第２の状態情報として取得する請求項１又は２に記載の機器。
情報処理装置とネットワークを介して接続される機器であって、
検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成部と、
前記機器での障害の発生に伴い発生する通知タイミングになると、当該障害の発生に伴い通知が要請される対象情報を取得する対象情報取得部と、
前記対象情報が取得されると、当該対象情報を前記情報処理装置に通知する対象情報通知部と、
前記対象情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記障害の発生の所定時間前以降の状態情報を取得する状態情報取得部と、
前記状態情報が取得されると、当該状態情報を前記情報処理装置に通知する状態情報通知部と、
を備える機器。
前記状態情報取得部は、前記対象情報の通知が失敗した場合、前記状態情報を取得せず、
前記状態情報通知部は、前記状態情報を通知しない請求項４に記載の機器。
前記状態情報取得部は、前記記憶部に時系列に記憶されている状態情報に含まれる前記障害の発生の所定時間前以降の状態情報の容量が、閾値を超えるか否かを判定し、前記閾値を超える場合、前記障害の発生の所定時間前以降の状態情報から一部の情報を削減して前記容量が前記閾値に収まるように加工した状態情報を取得する請求項４又は５に記載の機器。
前記状態情報取得部は、前記障害の種別に基づいて前記状態情報の取得の要否を判定し、前記状態情報の取得が必要な場合、前記状態情報を取得する請求項４〜６のいずれか１つに記載の機器。
機器と、当該機器とネットワークを介して接続される情報処理装置と、を備える情報処理システムであって、
前記機器は、
検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成部と、
定期的に訪れる通知タイミングになると、前記機器の現時点での状態を示す第１の状態情報を取得する第１の取得部と、
前記第１の状態情報が取得されると、当該第１の状態情報を前記情報処理装置に通知する第１の通知部と、
前記第１の状態情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記情報処理装置に未通知の状態情報である第２の状態情報を取得する第２の取得部と、
前記第２の状態情報が取得されると、当該第２の状態情報を前記情報処理装置に通知する第２の通知部と、を備え、
前記情報処理装置は、
前記通知された第１の状態情報及び第２の状態情報に基づいて、前記機器の将来の状態を予測する予測部を備える情報処理システム。
機器と、当該機器とネットワークを介して接続される情報処理装置と、を備える情報処理システムであって、
前記機器は、
検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成部と、
前記機器での障害の発生に伴い発生する通知タイミングになると、当該障害の発生に伴い通知が要請される対象情報を取得する対象情報取得部と、
前記対象情報が取得されると、当該対象情報を前記情報処理装置に通知する対象情報通知部と、
前記対象情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記障害の発生の所定時間前以降の状態情報を取得する状態情報取得部と、
前記状態情報が取得されると、当該状態情報を前記情報処理装置に通知する状態情報通知部と、を備え、
前記情報処理装置は、
前記通知された対象情報及び状態情報に基づいて、前記障害を診断する診断部を備える情報処理システム。
情報処理装置とネットワークを介して接続される機器に、
検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成ステップと、
定期的に訪れる通知タイミングになると、前記機器の現時点での状態を示す第１の状態情報を取得する第１の取得ステップと、
前記第１の状態情報が取得されると、当該第１の状態情報を前記情報処理装置に通知する第１の通知ステップと、
前記第１の状態情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記情報処理装置に未通知の状態情報である第２の状態情報を取得する第２の取得ステップと、
前記第２の状態情報が取得されると、当該第２の状態情報を前記情報処理装置に通知する第２の通知ステップと、
を実行させるためのプログラム。
情報処理装置とネットワークを介して接続される機器に、
検知された前記機器の状態に基づく状態情報を、時系列に記憶部に記憶する生成ステップと、
前記機器での障害の発生に伴い発生する通知タイミングになると、当該障害の発生に伴い通知が要請される対象情報を取得する対象情報取得ステップと、
前記対象情報が取得されると、当該対象情報を前記情報処理装置に通知する対象情報通知ステップと、
前記対象情報の通知が行われると、前記記憶部に時系列に記憶されている状態情報の中から、前記障害の発生の所定時間前以降の状態情報を取得する状態情報取得ステップと、
前記状態情報が取得されると、当該状態情報を前記情報処理装置に通知する状態情報通知ステップと、
を実行させるためのプログラム。