(57)【要約】【課題】情報処理装置から収集された情報に基づいてサーバ装置で生成された診断モデルを用いて、より精度の高い故障診断を情報処理装置において行う技術を提供する。【解決手段】サーバ装置１２０は、ＭＦＰ１１０を含む複数のＭＦＰから、各ＭＦＰの設定及び状態の時間的変化を示す時系列情報と、各ＭＦＰにおいて発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データを生成する。サーバ装置１２０は、生成した学習データに基づく学習により、ＭＦＰ１１０の故障診断のための診断モデルを生成する。ＭＦＰ１１０は、サーバ装置１２０によって生成された診断モデルを当該サーバ装置から取得する。ＭＦＰ１１０は、故障診断に必要な情報を自装置内で収集し、収集した情報と、サーバ装置１２０から取得した診断モデルとを用いて故障診断を実行することで、ＭＦＰ１１０においてエラーが発生する可能性を示す診断結果を出力する。【選択図】図１
2019213192.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置と、前記サーバ装置と通信可能な情報処理装置とを備える情報処理システムであって、
前記サーバ装置は、
前記情報処理装置を含む複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データを生成する生成手段と、
前記生成手段によって生成された学習データに基づく学習により、前記情報処理装置の故障診断のための学習済モデルである診断モデルを生成する学習手段と、
を備え、
前記情報処理装置は、
前記サーバ装置によって生成された診断モデルを、前記サーバ装置から取得する取得手段と、
前記故障診断に必要な情報を自装置内で収集し、収集した情報と前記取得手段によって取得された診断モデルとを用いて前記故障診断を実行することで、前記情報処理装置においてエラーが発生する可能性を示す診断結果を出力する実行手段と、
を備えることを特徴とする情報処理システム。
【請求項２】
前記情報処理装置は、自装置において発生したイベントに関連するイベントログを前記サーバ装置へ送信する送信手段を更に備え、
前記生成手段は、各情報処理装置から受信されたイベントログに対して、前記時系列情報及び前記エラー情報を収集するためのフィルタリング処理を行う
ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記フィルタリング処理では、各情報処理装置から順に受信された複数のイベントログから、当該情報処理装置の設定及び状態を示す、同じ属性を有する情報を、前記時系列情報として収集する
ことを特徴とする請求項２に記載の情報処理システム。
【請求項４】
前記フィルタリング処理では、各情報処理装置から順に受信された複数のイベントログから、当該情報処理装置の状態の時間的変化を示す前記時系列情報として、当該情報処理装置が備える特定のセンサに対応する時系列のセンサ値を収集する
ことを特徴とする請求項２又は３に記載の情報処理システム。
【請求項５】
前記学習手段は、前記エラー情報を含むイベントログが当該情報処理装置から受信されるごとに、前記生成手段によって生成される学習データに基づいて前記学習を行うことで、前記診断モデルを更新する
ことを特徴とする請求項２から４のいずれか１項に記載の情報処理システム。
【請求項６】
前記学習手段は、前回の前記診断モデルの更新から所定時間が経過すると、前記生成手段によって生成される学習データに基づいて前記学習を行うことで、前記診断モデルを更新する
ことを特徴とする請求項２から５のいずれか１項に記載の情報処理システム。
【請求項７】
前記実行手段は、前記サーバ装置への送信対象のイベントログとして、特定のイベントに関連するイベントログが生じると、前記故障診断を実行する
ことを特徴とする請求項２から６のいずれか１項に記載の情報処理システム。
【請求項８】
前記実行手段は、前記サーバ装置への送信対象のイベントログが生じた際に、前回の前記故障診断の実行から所定時間が経過していれば、前記故障診断を実行する
ことを特徴とする請求項２から７のいずれか１項に記載の情報処理システム。
【請求項９】
前記実行手段は、前記故障診断の実行指示をユーザから受け付けると、前記故障診断を実行する
ことを特徴とする請求項２から８のいずれか１項に記載の情報処理システム。
【請求項１０】
前記情報処理装置は、前記取得手段によって取得された診断モデルが格納される記憶手段を更に備え、
前記サーバ装置は、前記学習手段によって前記診断モデルが更新された場合に、前記診断モデルの更新を前記情報処理装置へ通知する第１通知手段を更に備え、
前記取得手段は、前記診断モデルの更新が前記サーバ装置から通知されると、前記記憶手段に格納された前記診断モデルを更新するために、前記サーバ装置によって更新された診断モデルを前記サーバ装置から取得する
ことを特徴とする請求項１から９のいずれか１項に記載の情報処理システム。
【請求項１１】
前記診断結果が、前記情報処理装置においてエラーが発生する可能性があることを示す場合に、前記情報処理装置のユーザ又は管理者に対して前記診断結果の通知を行う第２通知手段を更に備える
ことを特徴とする請求項１から１０のいずれか１項に記載の情報処理システム。
【請求項１２】
前記実行手段は、前記診断結果として、エラーが発生する可能性を示すパラメータ値をエラー種別ごとに出力し、
前記第２通知手段は、それぞれ異なるエラー種別に対応する前記パラメータ値の合計値が閾値を超えると、前記通知を行う
ことを特徴とする請求項１１に記載の情報処理システム。
【請求項１３】
前記第２通知手段は、前記診断結果をイベントログとして前記サーバ装置へ送信する
ことを特徴とする請求項１１又は１２に記載の情報処理システム。
【請求項１４】
前記学習手段は、前記生成手段による前記フィルタリング処理で用いられたフィルタリング条件に対応する属性情報を、生成した前記診断モデルに対応付けて保存し、
前記取得手段は、属性情報の指定を含む、診断モデルの取得要求を、前記サーバ装置へ送信することで、前記取得要求で指定した属性情報に対応する診断モデルを前記サーバ装置から取得する
ことを特徴とする請求項２から４のいずれか１項に記載の情報処理システム。
【請求項１５】
前記属性情報は、前記情報処理装置の機種を示す情報、前記情報処理装置のパーツを示す情報、前記情報処理装置におけるエラー種別を示す情報、及び前記情報処理装置において発生するイベントの種別を示す情報、のうちの少なくとも１つを含む
ことを特徴とする請求項１４に記載の情報処理システム。
【請求項１６】
情報処理装置と通信可能なサーバ装置であって、
前記情報処理装置を含む複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データを生成する生成手段と、
前記生成手段によって生成された学習データに基づく学習により、前記情報処理装置の故障診断のための学習済モデルである診断モデルを生成する学習手段であって、前記診断モデルを用いた前記故障診断により、前記情報処理装置においてエラーが発生する可能性を示す診断結果が出力される、前記学習手段と、
前記学習手段によって生成された診断モデルを、前記情報処理装置からの取得要求に応じて前記情報処理装置へ送信する送信手段と、
を備えることを特徴とするサーバ装置。
【請求項１７】
複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データに基づく学習により、情報処理装置の故障診断のための学習済モデルである診断モデルを生成するサーバ装置と通信可能な情報処理装置であって、
前記サーバ装置によって生成された診断モデルを、前記サーバ装置から取得する取得手段と、
前記故障診断に必要な情報を自装置内で収集し、収集した情報と前記取得手段によって取得された診断モデルとを用いて前記故障診断を実行することで、前記情報処理装置においてエラーが発生する可能性を示す診断結果を出力する実行手段と、
を備えることを特徴とする情報処理装置。
【請求項１８】
情報処理装置と通信可能なサーバ装置の制御方法であって、
前記情報処理装置を含む複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データを生成する生成工程と、
前記生成工程で生成された学習データに基づく学習により、前記情報処理装置の故障診断のための学習済モデルである診断モデルを生成する学習工程であって、前記診断モデルを用いた前記故障診断により、前記情報処理装置においてエラーが発生する可能性を示す診断結果が出力される、前記学習工程と、
前記学習工程で生成された診断モデルを、前記情報処理装置からの取得要求に応じて前記情報処理装置へ送信する送信工程と、
を含むことを特徴とするサーバ装置の制御方法。
【請求項１９】
複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データに基づく学習により、情報処理装置の故障診断のための学習済モデルである診断モデルを生成するサーバ装置と通信可能な情報処理装置の制御方法であって、
前記サーバ装置によって生成された診断モデルを、前記サーバ装置から取得する取得工程と、
前記故障診断に必要な情報を自装置内で収集し、収集した情報と前記取得工程で取得された診断モデルとを用いて前記故障診断を実行することで、前記情報処理装置においてエラーが発生する可能性を示す診断結果を出力する実行工程と、
を含むことを特徴とする情報処理装置の制御方法。
【請求項２０】
請求項１８に記載のサーバ装置の制御方法の各工程を、コンピュータに実行させるためのプログラム。
【請求項２１】
請求項１９に記載の情報処理装置の制御方法の各工程を、コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置等の情報処理装置の故障診断に用いる診断モデルをサーバ装置で生成して情報処理装置へ提供する情報処理システムに関するものである。
【背景技術】
【０００２】
近年、複合機（ＭＦＰ）等の画像形成装置では、多機能化及び高機能化により、装置の動作に問題が生じた場合の復旧に要する時間が以前よりも長くなってきている。また、装置の複雑化により故障原因の特定が難しくなったことで、復旧自体が難しい場合もある。
【０００３】
上述のように画像形成装置において故障が発生した場合に故障原因の特定を支援するシステムとして、エラー情報に対応した診断モデルを用いた故障診断システムがある。例えば、特許文献１では、故障診断の精度を向上させるために、エラー情報に加えて、動作モード（故障時に提供中であった機能）とユーザが入力する故障情報とに基づいて診断モデルを生成する技術が提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−０１７２６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述の従来技術では、エラー情報、動作モード及びユーザが入力する故障情報等の情報に基づいて診断モデルを生成し、当該診断モデルを用いて故障原因を特定している。しかし、診断モデルの生成において、画像形成装置における設定値又はセンサ値の時間的変化を示す情報のような動的情報は考慮されていない。また、故障の発生前に故障が発生する予兆を検知することは行われていない。
【０００６】
本発明は、上述の問題に鑑みてなされたものであり、情報処理装置から収集された情報に基づいてサーバ装置で生成された診断モデルを用いて、より精度の高い故障診断を情報処理装置において行う技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係る情報処理システムは、サーバ装置と、前記サーバ装置と通信可能な情報処理装置とを備える情報処理システムであって、前記サーバ装置は、前記情報処理装置を含む複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データを生成する生成手段と、前記生成手段によって生成された学習データに基づく学習により、前記情報処理装置の故障診断のための学習済モデルである診断モデルを生成する学習手段と、を備え、前記情報処理装置は、前記サーバ装置によって生成された診断モデルを、前記サーバ装置から取得する取得手段と、前記故障診断に必要な情報を自装置内で収集し、収集した情報と前記取得手段によって取得された診断モデルとを用いて前記故障診断を実行することで、前記情報処理装置においてエラーが発生する可能性を示す診断結果を出力する実行手段と、を備えることを特徴とする。
【０００８】
本発明の一態様に係るサーバ装置は、情報処理装置と通信可能なサーバ装置であって、前記情報処理装置を含む複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データを生成する生成手段と、前記生成手段によって生成された学習データに基づく学習により、前記情報処理装置の故障診断のための学習済モデルである診断モデルを生成する学習手段であって、前記診断モデルを用いた前記故障診断により、前記情報処理装置においてエラーが発生する可能性を示す診断結果が出力される、前記学習手段と、前記学習手段によって生成された診断モデルを、前記情報処理装置からの取得要求に応じて前記情報処理装置へ送信する送信手段と、を備えることを特徴とする。
【０００９】
本発明の一態様に係る情報処理装置は、複数の情報処理装置から、各情報処理装置の設定及び状態の時間的変化を示す時系列情報と、各情報処理装置において発生したエラーを示すエラー情報とを収集し、収集した情報を含む学習データに基づく学習により、情報処理装置の故障診断のための学習済モデルである診断モデルを生成するサーバ装置と通信可能な情報処理装置であって、前記サーバ装置によって生成された診断モデルを、前記サーバ装置から取得する取得手段と、前記故障診断に必要な情報を自装置内で収集し、収集した情報と前記取得手段によって取得された診断モデルとを用いて前記故障診断を実行することで、前記情報処理装置においてエラーが発生する可能性を示す診断結果を出力する実行手段と、を備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、画像形成装置等の情報処理装置から収集された情報に基づいてサーバ装置で生成された診断モデルを用いて、より精度の高い故障診断を情報処理装置において行うことが可能になる。また、故障（エラー）の発生前に故障が発生する予兆を検知することが可能になる。
【図面の簡単な説明】
【００１１】
【図１】通信システムの構成例を示す図。
【図２】ＭＦＰのハードウェア構成例を示すブロック図。
【図３】ＭＦＰのコントローラ部のハードウェア構成例を示すブロック図。
【図４】サーバ装置のハードウェア構成例を示すブロック図。
【図５】ＭＦＰの機能構成例を示すブロック図。
【図６】サーバ装置の機能構成例を示すブロック図。
【図７】サーバ装置における診断モデルの生成処理の手順を示すフローチャート。
【図８】サーバ装置におけるフィルタリング処理の手順を示すフローチャート。
【図９】サーバ装置における学習処理の手順を示すフローチャート。
【図１０】ＭＦＰにおける故障診断処理の手順を示すフローチャート。
【図１１】第２実施形態に係る診断モデルの生成処理の手順を示すフローチャート。
【図１２】第２実施形態に係る故障診断処理の手順を示すフローチャート。
【図１３】ＭＦＰにおける故障診断に関連する操作画面の例を示す図。
【図１４】サーバ装置における診断モデルの生成処理の概要を示す図。
【図１５】作成した診断モデルの適用方法の概要を示す図。
【図１６】故障発生確率の表示処理を示すフローチャート。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１３】
以下の第１及び第２実施形態では、画像形成装置に本発明を適用した例について説明する。なお、本発明は、情報処理装置であれば適用可能であり、例えば、印刷装置、複写機、複合機及びファクシミリ装置等にも適用可能である。
【００１４】
［第１実施形態］
＜システム構成＞
図１は、本発明の実施形態に係る情報処理システム（通信システム）の構成例を示す図である。図１に示す情報処理システムにおいて、複合機（ＭＦＰ）１１０ａ，１１０ｂ及びサーバ装置１２０は、ネットワーク１００に接続されており、ネットワーク１００を介して互いに通信可能である。ネットワーク１００は、例えば、有線ＬＡＮ（ローカルエリアネットワーク）で構成される。
【００１５】
サーバ装置１２０は、ＭＦＰ１１０ａ，１１０ｂ等のクライアント装置の情報を収集するとともに、クライアント装置の故障診断用の診断モデルを管理する。サーバ装置１２０は、ＭＦＰ１１０ａ，１１０ｂから情報を収集する機能、収集した情報から診断モデルを生成する機能、及び生成した診断モデルをＭＦＰ１１０ａ，１１０ｂに送信する機能を有する。
【００１６】
ＭＦＰ１１０（１１０ａ，１１０ｂ）は、プリント、コピー、スキャナ、ファクシミリ（ＦＡＸ）送信等の、複数の機能を有する情報機器である。本実施形態のＭＦＰ１１０は、サーバ装置１２０に対するクライアント装置として機能する。ＭＦＰ１１０は、装置内で生成した情報をサーバ装置１２０に送信する機能、サーバ装置１２０から診断モデルを取得する機能、及び取得した診断モデルを用いて自装置の故障診断を行う機能を有する。
【００１７】
ＭＦＰ１１０は、各機能の実行時に使用する設定値、及び実行時の動作ログ（イベントログ）を、自装置内に記憶しており、これらの情報をサーバ装置１２０へ送信しうる。また、ＭＦＰ１１０は、サーバ装置１２０において診断モデルの変更（更新）が生じたことを示す情報を受信すると、自装置用の診断モデルをサーバ装置１２０から取得することで、自装置内に保持している診断モデルを更新する。ＭＦＰ１１０は、自装置内に記憶している設定値及びイベントログに対して診断モデルを用いて、自装置の故障診断を行う。ＭＦＰ１１０は、必要に応じて診断結果を当該ＭＦＰのユーザ又は管理者に通知する。
【００１８】
＜ＭＦＰのハードウェア構成＞
図２は、本実施形態に係るＭＦＰ１１０のハードウェア構成例を示すブロック図である。ＭＦＰ１１０は、コントローラ部２０１、プリンタコントローラ２０２、スキャナコントローラ２０３、プリンタ２０４、スキャナ２０５、及び操作部２０６を備えている。コントローラ部２０１は、プリンタコントローラ２０２、スキャナコントローラ２０３、及び操作部２０６と接続され、ＭＦＰ１１０全体の動作を制御する。プリンタコントローラ２０２は、画像出力デバイスであるプリンタ２０４を制御する。スキャナコントローラ２０３は、画像入力デバイスであるスキャナ２０５を制御する。
【００１９】
図３は、コントローラ部２０１のハードウェア構成例を示すブロック図である。コントローラ部２０１は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、及びＨＤＤ（ハードディスクドライブ）３０４を有する。コントローラ部２０１は、更に、ネットワークインタフェース（Ｉ／Ｆ）３０５、操作部Ｉ／Ｆ３０６、画像処理部３０７、及びデバイスコントローラＩ／Ｆ３０８を有する。これらのデバイスは、システムバス３１０にそれぞれ接続されている。
【００２０】
ＣＰＵ３０１は、ＲＯＭ３０２に格納されているブートプログラムを実行してＯＳ（オペレーティングシステム）を起動する。ＲＯＭ３０２には、ＣＰＵ３０１によって実行される制御プログラムが格納される。ＣＰＵ３０１は、ＯＳ上で、ＲＯＭ３０２又はＨＤＤ３０４に格納されているアプリケーションプログラムを実行することにより、各種処理を実行する。ＲＡＭ３０３は、ＣＰＵ３０１に対して作業領域を提供するとともに、画像データを一時的に格納するための画像メモリ領域を提供する。ＨＤＤ３０４には、上記のアプリケーションプログラム等の各種プログラム、画像データ等の各種データ、及び各種設定値が格納される。
【００２１】
操作部Ｉ／Ｆ３０６は、操作部２０６とのインタフェースである。操作部２０６は、タッチパネル機能を有するディスプレイ（表示部）を備える。操作部Ｉ／Ｆ３０６は、操作部２０６に表示すべき画面の画面データを、操作部２０６に対して出力する。また、操作部Ｉ／Ｆ３０６は、操作部２０６を介してユーザにより入力された情報を、ＣＰＵ３０１へ送信する。
【００２２】
デバイスコントローラＩ／Ｆ３０８には、プリンタコントローラ２０２及びスキャナコントローラ２０３が接続される。デバイスコントローラＩ／Ｆ３０８は、データ又は制御信号の入出力を行う。ネットワークＩ／Ｆ３０５は、ネットワーク１００に接続されており、ネットワーク１００を介して、サーバ装置１２０及び他のＭＦＰ１１０等の外部装置との通信（情報の入出力）を行う。画像処理部３０７は、プリンタ２０４へ出力する画像データ、及びスキャナ２０５から入力された画像データに対する画像処理を行う。画像処理部３０７は、例えば、画像回転、画像圧縮、解像度変換、色空間変換、階調変換等の処理を行う。
【００２３】
＜サーバ装置のハードウェア構成＞
図４は、本実施形態に係るサーバ装置１２０のハードウェア構成例を示すブロック図である。サーバ装置１２０は、コントローラ部４００及び操作部４２０を備えている。コントローラ部４００は、ＣＰＵ４０１、ＲＯＭ４０２、ＲＡＭ４０３、ＨＤＤ４０４、操作部Ｉ／Ｆ４０５、及びネットワークＩ／Ｆ４０６を有する。コントローラ部４００内のこれらのデバイスは、システムバス４１０にそれぞれ接続されている。
【００２４】
ＣＰＵ４０１は、ＲＯＭ４０２に格納されているブートプログラムを実行してＯＳを起動する。ＲＯＭ４０２には、ＣＰＵ４０１によって実行される制御プログラムが格納される。ＣＰＵ４０１は、ＯＳ上で、ＲＯＭ４０２又はＨＤＤ４０４に格納されているアプリケーションプログラムを実行することにより、各種処理を実行する。ＲＡＭ４０３は、ＣＰＵ４０１に対して作業領域を提供する。ＨＤＤ４０４には、上記のアプリケーションプログラム等の各種プログラム、各種データ、及び各種設定値が格納される。
【００２５】
操作部Ｉ／Ｆ４０５は、操作部４２０とのインタフェースである。操作部４２０は、マウス、キーボード等の入力デバイス、及び液晶ディスプレイ等の表示デバイスを備える。操作部Ｉ／Ｆ４０５は、操作部４２０に表示すべき画面の画面データを、操作部４２０に対して出力する。また、操作部Ｉ／Ｆ４０５は、操作部４２０を介してユーザにより入力された情報を、ＣＰＵ４０１へ送信する。ネットワークＩ／Ｆ４０６は、ネットワーク１００に接続されており、ネットワーク１００を介して、ＭＦＰ１１０等の外部装置との通信（情報の入出力）を行う。
【００２６】
＜ＭＦＰの機能構成＞
図５は、本実施形態に係るＭＦＰ１１０のソフトウェア構成例を示すブロック図であり、ＭＦＰファームウェア５００によって実現される機能構成例を示している。図５に示す各機能ユニットは、ＲＯＭ３０２又はＨＤＤ３０４等の記憶装置に格納されているＭＦＰファームウェア５００のプログラムを、ＣＰＵ３０１が当該記憶装置から読み出して実行することによって実現される。
【００２７】
ジョブ管理部５０１は、ネットワークＩ／Ｆ３０５を介してネットワーク１００と接続されており、特定の通信プロトコルを用いてプリントジョブ等のジョブを外部装置から受信し、受信したジョブを実行する。また、ジョブ管理部５０１は、操作部制御部５０２から受けた通知に従って、コピージョブ、プリントジョブ又はスキャンジョブ等のジョブを実行する。ジョブ管理部５０１は、ジョブを実行した際に、当該ジョブの実行履歴をジョブ履歴ＤＢ（データベース）５０４に保存する。
【００２８】
また、ジョブ管理部５０１は、他の機能ユニットからの問い合わせに応じて、ジョブに関連するデータを提供する機能、及び他の機能ユニットからイベント購読要求を受け付けて、当該購読要求に従ってイベントを伝達する機能を有する。ジョブ管理部５０１は、例えば、ジョブの開始、一時停止及び終了のタイミングといった、ジョブの実行状態に変化が生じたタイミングに、イベントの伝達を行う。
【００２９】
ジョブ履歴ＤＢ５０４には、ジョブの実行履歴が格納される。実行履歴には、ジョブの実行に関連する情報（ジョブの実行の開始日時及び終了日時、給紙枚数、排紙枚数、ステイプルの有無等）が含まれるが、他の情報が含まれていてもよい。なお、ジョブ履歴ＤＢ５０４に格納されるジョブ実行履歴は、ＨＤＤ３０４に格納される。
【００３０】
操作部制御部５０２は、操作部２０６により受け付けた、コピージョブ又はスキャンジョブ等のジョブの実行を指示するためのユーザ操作の内容を示すデータを、操作部Ｉ／Ｆ３０６を介して操作部２０６から受信する。操作部制御部５０２は、ユーザから受け付けたユーザ操作の内容を、上述のようにジョブ管理部５０１に通知する。また、操作部制御部５０２は、ユーザから受け付けたユーザ操作の内容、ＭＦＰ１１０内で生じた制御イベント、及び操作部２０６で生じた故障に関する故障情報を、構造化部５０５へ伝達する。
【００３１】
構造化部５０５に伝達される情報のうち、ユーザ操作の内容は、例えば、操作部２０６に表示されたボタンの押下、又はＭＦＰ１１０へのユーザのログイン操作である。ＭＦＰ１１０内の制御イベントは、例えば、ＭＦＰ１１０の起動、又はＭＦＰ１１０のスリープ状態への移行である。また、故障情報は、操作部２０６で生じた故障の内容を特定するための情報であり、ＵＵＩＤ（Universal Unique ID）等の情報である。
【００３２】
デバイス制御部５２０は、デバイスコントローラＩ／Ｆ３０８を介してプリンタコントローラ２０２及びスキャナコントローラ２０３を制御することにより、各デバイス（プリンタ２０４及びスキャナ２０５）を制御する。具体的には、デバイス制御部５２０は、処理対象の画像データ及び制御内容をジョブ管理部５０１から受け付けて、受け付けた制御内容に従って、プリンタコントローラ２０２及びスキャナコントローラ２０３を制御する。デバイス制御部５２０は、各デバイスの制御内容と、プリンタコントローラ２０２又はスキャナコントローラ２０３から受信した情報とを、構造化部５２１に伝達する。
【００３３】
デバイス制御部５２０が、プリンタコントローラ２０２又はスキャナコントローラ２０３から受信する情報には、例えば以下の情報が含まれる。
‐プリンタ２０４又はスキャナ２０５の設定情報（設定値等の情報）。
‐プリンタ２０４又はスキャナ２０５を構成する部品（パーツ）の使用情報（使用期間等の情報）。
‐プリンタ２０４又はスキャナ２０５に設けられたセンサ（温度センサ等）の出力値。  ‐プリンタ２０４又はスキャナ２０５の故障情報。
【００３４】
プリンタコントローラ２０２又はスキャナコントローラ２０３は、デバイス制御部５２０へ提供する情報を一時的に保存していてもよい。この場合、デバイス制御部５２０は、プリンタコントローラ２０２又はスキャナコントローラ２０３が保存している情報を取得する。
【００３５】
構造化部５０３は、ジョブ管理部５０１から出力されたデータ（即ち、ジョブの実行に関連するデータ）を、所定のデータスキーマに従って構造化されたデータへ変換する。構造化部５０５は、操作部制御部５０２から出力されたデータ（即ち、ユーザ操作に関連するデータ）を、所定のデータスキーマに従って構造化されたデータへ変換する。構造化部５２１は、デバイス制御部５２０から出力されたデータ（即ち、ＭＦＰ１１０が備えるデバイスの制御に関連するデータ）を、所定のデータスキーマに従って構造化されたデータへ変換する。
【００３６】
上述の各構造化部５０３，５０５，５２１は、変換の結果、中間データ生成部５２２が解釈可能なデータを生成する。変換の具体例としては、データの発生日時、又はデータを一意に特定するためのＵＵＩＤ（Universal Unique ID）を新たに付与する処理、及びデータを所定の階層構造又は表現形式を有するデータへ変換する処理が挙げられる。これらの変換は、複数の種類のデータを統一的に扱うために、又は、処理の効率性のために情報が符号化若しくは簡略化されているデータを、後の分析が容易になるように加工するために行われる。なお、上述の各構造化部は、サーバ装置１２０へ送信されるデータに対して、上述の処理以外にも、必要に応じて、データ構造に関する前加工を更に行ってもよい。
【００３７】
中間データ生成部５２２は、構造化部５０３，５０５，５２１によって生成された、所定の表現形式で表現されたデータを、バッファリングのために永続化可能なデータ形式のデータである中間データに変換する。中間データのデータ形式として、データサイズが可能な限り小さくなるデータ形式を用いることにより、バッファＤＢ５０９に蓄積可能なデータを増やすことが可能である。例えば、値域に応じてデータサイズが可変となるＣＢＯＲ（Concise Binary Object Representation）のようなデータ形式が使用されてもよいし、ハフマン符号等の符号化形式が使用されてもよい。あるいは、これらが併用されてもよい。
【００３８】
バッファ制御部５０７は、中間データ生成部５２２によって生成された、バッファリング対象の中間データを、バッファＤＢ５０９に格納することで、中間データのバッファリングを行う。また、バッファ制御部５０７は、バッファＤＢ５０９への中間データ（イベントログ）のバッファリングに関する通知を、バッファ通知部５１０に指示する機能を有する。
【００３９】
バッファＤＢ５０９は、サーバ装置１２０への送信前に、中間データをバッファリングするためのデータベースである。バッファＤＢ５０９は、中間データの生成タイミングと、この中間データをイベントログとしてサーバ装置１２０へ送信するタイミングとの差を吸収するためのバッファとして設けられる。例えば、通信障害等に起因してサーバ装置１２０との通信が滞っている間に生成されてバッファリングされた中間データは、サーバ装置１２０との通信が可能になるまで、バッファＤＢ５０９に保持し続けられる。サーバ装置１２０との通信が可能になると、バッファＤＢ５０９に保持された中間データの送信（データ変換部５１１による変換後のデータの送信）が順次行われる。サーバ通信部５１２による送信が完了したデータに対応する中間データは、バッファ制御部５０７によって、バッファＤＢ５０９から削除される。
【００４０】
バッファ通知部５１０は、バッファ制御部５０７から通知を受けると、中間データ（イベントログ）がバッファＤＢ５０９に格納されている（バッファリングされている）ことを示す格納通知を、サーバ通信部５１２及び診断制御部５１５へ送る。
【００４１】
データ変換部５１１は、中間データ生成部５２２が生成した、イベントログに相当する中間データを、サーバ装置１２０が解釈可能なデータ形式のデータへ変換する。例えば、データ変換部５１１による変換により生成されるイベントログのデータ形式は、ＪＳＯＮ（JavaScript(登録商標) Object Notation）形式である。ＪＳＯＮ形式は、一般的に、インターネット通信で広く用いられるデータ形式である。
【００４２】
フィルタリング部５１３は、サーバ通信部５１２による送信対象のイベントログの内容を確認し、当該イベントログを実際にサーバ装置１２０へ送信すべきか否かを判定するフィルタリング処理を行う。このフィルタリング処理は、例えば、通信回線の状態に合わせて送信データ量を削減するため、又は所定の状態にある装置のみからサーバ装置１２０が特定のイベントを取得できるようにするために行われる。
【００４３】
サーバ通信部５１２は、フィルタリング部５１３によるフィルタリング処理で抽出された、自装置において発生したイベントに関連するイベントログを、ネットワーク１００を介してサーバ装置１２０へ送信する。具体的には、サーバ通信部５１２は、バッファ通知部５１０からの通知を受け付けると、フィルタリング部５１３を用いて、バッファＤＢ５０９に格納されたイベントログのうちで、送信の必要があるイベントログを抽出する。更に、サーバ通信部５１２は、抽出したイベントログをサーバ装置１２０へ送信し、送信が完了すると、バッファ通知部５１０から次の通知を受けるまで待機する。
【００４４】
（故障診断に関連する機能ユニット群）
次に、ＭＦＰ１１０の故障診断に関連する処理を実現する機能ユニット群について説明する。このような機能ユニット群には、情報収集部５１４、診断制御部５１５、診断モデル管理部５１６、診断結果通知部５１７、診断処理部５１８、及び診断モデルＤＢ５１９が含まれる。
【００４５】
診断制御部５１５は、ＭＦＰ１１０の故障診断を実現するために、情報収集部５１４、診断モデル管理部５１６、及び診断処理部５１８を制御する。診断制御部５１５は、バッファ通知部５１０からの通知を受け付けると、受け付けた通知に関連するイベントログの内容に基づいて、故障診断を実行するか否かを判定する。診断制御部５１５は、例えば、以下のような場合に、故障診断を実行すると判定する。
・特定のイベントログに関する通知を受け付けた（即ち、特定のイベントに関連するイベントログが生じた）場合。
・イベントログに関する通知を受け付けた時点で、前回の故障診断の実行から所定時間が経過していた（即ち、サーバ装置１２０への送信対象のイベントログが生じた際に、前回の故障診断の実行から所定時間が経過していた）場合。
・故障診断の実行指示をユーザから受け付けた場合。
【００４６】
診断制御部５１５は、上述の判定の結果に従って、診断モデルの取得を診断モデル管理部５１６に対して指示し、故障診断用の情報の収集を情報収集部５１４に対して指示し、また、故障診断の実行を診断処理部５１８に対して指示する。
【００４７】
診断モデル管理部５１６は、ＭＦＰ１１０で使用する、故障診断用の診断モデルを管理する。診断モデル管理部５１６は、診断制御部５１５から診断モデルの取得指示を受け付けると、診断モデルの取得要求を、サーバ通信部５１２を介してサーバ装置１２０へ送信する。診断モデル管理部５１６は、サーバ装置１２０から診断モデルを取得できた場合、取得した診断モデルを、診断モデルＤＢ５１９に保存して管理する。診断モデル管理部５１６は、診断制御部５１５からの取得指示に対する応答として、診断モデルＤＢ５１９に保存して管理している診断モデルを診断制御部５１５へ提供する。
【００４８】
サーバ装置１２０から診断モデルを取得した際、診断モデル管理部５１６は、診断モデルＤＢ５１９内に既に診断モデルが保存されている場合には、保存されている診断モデルを更新するか否かを判定し、必要に応じて診断モデルの更新を行う。例えば、診断モデル管理部５１６は、サーバ装置１２０との通信を行うことができた場合に、診断モデルＤＢ５１９内の診断モデルの更新を行ってもよい。また、診断モデル管理部５１６は、取得した診断モデルに付与されたタイムスタンプと、診断モデルＤＢ５１９内の診断モデルに付与されたタイムスタンプとを比較し、比較結果に従って診断モデルの更新を行ってもよい。その場合、診断モデル管理部５１６は、新しい方の診断モデルが診断モデルＤＢ５１９に保存されるように、必要に応じて診断モデルの更新を行う。
【００４９】
情報収集部５１４は、診断制御部５１５からの収集指示に従って、故障診断に必要な情報（故障診断用の情報）を、ＭＦＰ１１０内で収集する。情報収集部５１４は、例えば、バッファＤＢ５０９又は設定値ＤＢ（図示せず）から情報を収集する。バッファＤＢ５０９からは、故障診断に必要なイベントログが収集される。設定値ＤＢからは、ＭＦＰ１１０の各種設定の設定値が収集される。なお、設定値ＤＢに格納される設定値は、ＨＤＤ３０４に格納される。
【００５０】
診断制御部５１５から情報収集部５１４への収集指示には、情報収集部５１４が収集すべき情報（イベントログ又は設定値）の指定が含まれてもよい。収集指示にそのような指定が含まれない場合には、情報収集部５１４は、予め定められている情報を、故障診断用の情報として収集してもよい。
【００５１】
診断制御部５１５は、診断処理部５１８に対して、診断モデル管理部５１６から提供された診断モデルと、情報収集部５１４によって収集された情報とに基づく故障診断の実行を指示する。診断処理部５１８は、診断制御部５１５からの指示に従って故障診断を行う。具体的には、診断処理部５１８は、診断モデルに基づいて、情報収集部５１４によって収集された情報のうちで、当該診断モデルに対する入力パラメータを決定し、決定した入力パラメータを用いて故障診断を行う。更に、診断処理部５１８は、故障診断の結果として得られた出力パラメータを、診断結果通知部５１７へ出力する。
【００５２】
診断結果通知部５１７は、診断処理部５１８から出力された診断結果（出力パラメータ）に基づいて、当該診断結果の通知を行うか否かを判定する。診断結果通知部５１７は、診断結果の通知を行うと判定した場合、例えば、操作部制御部５０２に対して、操作部２０６を用いた診断結果の通知を要求する。
【００５３】
本実施形態では、診断結果通知部５１７は、診断処理部５１８から出力された診断結果が、ＭＦＰ１１０において故障（エラー）が発生する可能性があることを示す場合に、ＭＦＰ１１０のユーザ又は管理者に対して診断結果の通知を行う。例えば、診断結果通知部５１７は、診断処理部５１８から出力された診断結果に基づいて、何らかのエラーが発生する可能性が高まっていると判定した場合には、エラー発生の可能性を示す警告通知を行ってもよい。また、診断結果通知部５１７は、エラーの発生の可能性を示すパラメータ値をエラー種別ごとに保持し、それぞれ異なるエラー種別に対応するパラメータ値の合計値が所定の閾値を超えた場合に、そのような警告通知を行ってもよい。また、診断結果通知部５１７は、ユーザによる実行指示に従って故障診断が行われた場合には、故障診断の完了に応じて、操作部２０６を用いた診断結果の通知を行ってもよい。
【００５４】
（故障診断に関連する操作画面）
ここで、図１３は、故障診断に関連する操作画面の例を示す図であり、ＭＦＰ１１０の操作部２０６に表示される画面の例を示している。
【００５５】
図１３（Ａ）に示す操作画面１３００は、故障診断の実行を開始するか否かの指示をユーザから受け付けるための操作画面である。操作画面１３００は、例えば、ＭＦＰ１１０の操作部２０６におけるユーザ操作に応じて、操作部２０６に表示される。操作画面１３００においてキャンセルボタン１３０１が押下された場合には、操作部２０６の表示画面は、操作画面１３００が表示される前に操作部２０６に表示されていた画面に戻る。一方、操作画面１３００において開始ボタン１３０２が押下された場合には、故障診断の実行が開始される。その後、診断結果に応じて、操作画面１３１０又は操作画面１３２０が操作部２０６に表示される。
【００５６】
図１３（Ｂ）に示す操作画面１３１０は、故障診断の結果、特定のエラー（故障）が発生する可能性があるとの判定結果が得られた場合に表示される画面の例である。操作画面１３１０には、故障診断の結果を示す情報として、発生する可能性があると判定されたエラーを示すエラー情報１３１２が含まれる。エラー情報１３１２は、故障診断の結果に応じて変更される。操作画面１３１０においてＯＫボタン１３１１が押下された場合、操作部２０６の表示画面は、例えばメニュー画面（図示せず）に戻ってもよいし、操作画面１３００に戻ってもよい。
【００５７】
図１３（Ｃ）に示す操作画面１３２０は、故障診断の結果、エラーが発生する可能性がないとの判定結果が得られた場合に表示される画面の例である。操作画面１３２０には、エラー（故障）が発生する可能性がなく、ＭＦＰ１１０の利用を継続可能であることを示すメッセージが含まれる。操作画面１３２０においてＯＫボタン１３２１が押下された場合、操作部２０６の表示画面は、例えばメニュー画面（図示せず）に戻ってもよいし、操作画面１３００に戻ってもよい。
【００５８】
＜サーバ装置の機能構成＞
図６は、本実施形態に係るサーバ装置１２０のソフトウェア構成例を示す図であり、モデル生成サービス６００によって実現される機能構成例を示している。図６に示す各機能ユニットは、ＲＯＭ４０２又はＨＤＤ４０４等の記憶装置に格納されているモデル生成サービス６００のプログラムを、ＣＰＵ４０１が当該記憶装置から読み出して実行することによって実現される。
【００５９】
イベントログ受信部６０１は、ネットワークＩ／Ｆ４０７を介してネットワーク１００と接続され、特定の通信プロトコルを用いてクライアント装置（本実施形態ではＭＦＰ１１０）からイベントログを受信する。その際、イベントログ受信部６０１は、受信したイベントログをイベントログ管理部６０４に通知し、イベントログの送信元のＭＦＰ１１０の装置情報（機器情報）及び設定情報をＭＦＰ情報管理部６０２に通知する。
【００６０】
ＭＦＰ情報管理部６０２は、サーバ装置１２０（モデル生成サービス６００）に接続するクライアント装置（ＭＦＰ１１０）の装置情報及び設定情報を、ＭＦＰ情報として管理する。ＭＦＰ情報ＤＢ６０３には、サーバ装置１２０へイベントログを送信したＭＦＰ１１０の装置情報及び設定情報が、ＭＦＰ情報として格納される。ＭＦＰ情報管理部６０２は、イベントログ受信部６０１から通知を受けると、ＭＦＰ情報ＤＢ６０３に格納されている情報を更新する。
【００６１】
イベントログ管理部６０４は、ＭＦＰ１１０から受信されたイベントログを、イベントログＤＢ６０５に格納した状態で管理する。イベントログ管理部６０４は、イベントログ受信部６０１からの受信通知に従って、ＭＦＰ１１０から受信されたイベントログをイベントログＤＢ６０５に格納（登録）し、イベントログの受信を学習制御部６０６へ通知する。
【００６２】
学習制御部６０６は、学習処理部６１１による診断モデルの学習処理を制御する。学習制御部６０６は、学習処理の制御として、学習処理を実行するか否かの判定を行う。学習制御部６０６は、例えば、所定数のイベントログについて更新（登録）が行われた場合、又は、故障情報（エラー情報）を含むイベントログの更新（登録）が行われた場合に、学習処理を実行すると判定しうる。また、学習制御部６０６は、前回の学習処理が完了してから所定時間が経過した場合、又は、ネットワーク１００を介して学習処理の開始指示を受信した場合に、学習処理を実行すると判定しうる。更に、学習制御部６０６は、ＭＦＰ１１０においてＭＦＰファームウェア５００のバージョンアップが行われた場合に、学習処理を実行すると判定しうる。
【００６３】
学習制御部６０６は、学習処理を実行すると判定した場合には、学習データを生成するためのフィルタリング処理を行うよう、フィルタリング部６０７に指示する。フィルタリング部６０７は、学習制御部６０６からの指示に従って、学習データを生成するためのフィルタリング条件を決定する。フィルタリング条件は、予め定められていてもよいし、サーバ装置１２０の操作部４２０を介して設定されてもよいし、又は登録されたイベントログの内容に基づいて決定されてもよい。フィルタリング部６０７は、決定したフィルタリング条件の指定を含む、学習データの生成指示を、学習データ生成部６０９へ出力する。
【００６４】
学習データ生成部６０９は、フィルタリング部６０７から受信したフィルタリング条件に基づいて、学習データを生成し、生成した学習データを学習データＤＢ６１０に格納する。具体的には、学習データ生成部６０９は、ＭＦＰ情報ＤＢ６０３及びイベントログＤＢ６０５に格納される情報を用いて、指定されたフィルタリング条件を満たす情報を含む学習データを生成する。
【００６５】
学習データには、静的情報、動的情報、及びエラー情報が含められる。静的情報は、例えば、ＭＦＰ１１０の機種情報、ＭＦＰ１１０が備えるセンサ等のパーツを示すパーツ情報といった、ＭＦＰ１１０に関する情報である。動的情報（経時的情報）は、各情報処理装置（ＭＦＰ１１０）の設定及び状態の時間的変化を示す時系列情報の一例である。動的情報は、例えば、ある特定のイベントログに関連する情報であって、時系列の複数のイベントログから得られる、ＭＦＰ１１０の設定又は状態の時間的変化を示す情報に相当する。エラー情報は、動的情報に含まれる情報の収集元となったイベントログから得られる、各情報処理装置（ＭＦＰ１１０）において発生したエラー（故障）を示す情報である。
【００６６】
また、学習データ生成部６０９は、イベントログＤＢ６０５に格納されているイベントログから、エラー（故障）の発生に関連するイベントログを選択し、選択したイベントログを学習データに含めうる。学習データに含められる、エラーの発生に関連するイベントログの数は、生成する学習データの数とイベントログＤＢ６０５に格納されているイベントログが示す、特定のエラーが発生している度合いとに基づいて決定されてもよい。
【００６７】
学習データ生成部６０９による学習データの生成が完了すると、学習制御部６０６は、学習処理を実行するよう、学習処理部６１１に指示する。学習制御部６０６から学習処理部６１１へ出力される、学習処理の実行指示には、学習データＤＢ６１０に格納されている学習データのうちで、学習処理に使用する学習データの指定が含められる。
【００６８】
学習処理部６１１は、学習制御部６０６から受信した実行指示に従って、指定された学習データを用いて学習を行って診断モデルを生成する学習処理を行う。本実施形態における（広義の）学習とは、教師データに従って学習処理を行う狭義の機械学習や、ニューラルネットワークを用いたディープラーニング学習処理を含む。以下、特段明示しない場合には、学習とは、広義の学習を意味する。学習処理部６１１は、学習データを用いた学習処理を終えると、当該学習処理の結果として得られた学習済モデルである診断モデルを、診断モデル管理部６１２へ出力する。
【００６９】
診断モデル管理部６１２は、学習処理部６１１から出力された診断モデルを、当該診断モデルの生成に使用されたフィルタリング条件とともに診断モデルＤＢ６１３に格納して管理する。診断モデル管理部６１２は、診断モデル配信部６１４からの診断モデルの取得要求に応じて、取得要求で指定された条件を満たす診断モデルを診断モデルＤＢ６１３から取得し、取得した診断モデルを診断モデル配信部６１４へ出力する。
【００７０】
診断モデル配信部６１４は、ネットワークＩ／Ｆ４０７を介してネットワーク１００に接続されており、特定の通信プロトコルを用いてクライアント装置（ＭＦＰ１１０）から診断モデルの取得要求を受信する。診断モデル配信部６１４は、診断モデルの取得要求を受信すると、受信した取得要求に対する応答として、要求された診断モデルを送信する。その際、診断モデル配信部６１４は、取得要求の送信元のクライアント装置（ＭＦＰ１１０）の情報を、診断モデル管理部６１２に通知する。診断モデル配信部６１４は、診断モデル管理部６１２から診断モデルを取得できなかった場合には、診断モデルを取得できなかったことを示す応答を、取得要求の送信元のクライアント装置（ＭＦＰ１１０）へ送信する。
【００７１】
本実施形態では、ＭＦＰファームウェア５００及びモデル生成サービス６００によって使用される診断モデルは、ニューラルネットワークモデルに従って生成される。ニューラルネットワークは、Ｌ個のニューロンを含む入力層と、Ｍ個のニューロンを含む中間層（隠れ層）と、Ｎ個のニューロンを含む出力層とで構成される。ニューラルネットワークにおいて、中間層は、１層に限定されず２層以上設けられてもよく、それぞれの中間層に含まれるニューロンの数は同じである必要はない。なお、学習処理部６１１による学習処理は、ＣＰＵ又はＧＰＧＰＵ（General-purpose computing on graphics processing units）による処理によって実現することも可能である。あるいは、学習処理部６１１による学習処理は、別の大規模サーバを使用した処理によって実現することも可能である。
【００７２】
ニューラルネットワークモデルに従う場合、診断モデルは、ニューラルネットワークの構造と、学習により更新される、内部の中間層の重みパラメータとで表現される。ニューラルネットワークの構造は、入力層へ入力される入力パラメータの数及び形式と、出力層から出力される出力パラメータの数及び形式と、中間層の構造とで表現される。この場合、ＭＦＰ１１０とサーバ装置１２０は、診断モデルとして、入力パラメータの数及び形式と、出力パラメータの数及び形式と、中間層の構造とについて、同じモデルを保持しておく必要がある。なお、診断モデルの構造の変更が行われないことを前提とし、中間層の重みパラメータのみを、診断モデルを表す情報として用いてもよい。
【００７３】
上述のような診断モデルを用いた故障診断では、当該診断モデルから学習済のニューラルネットワークを復元し、そのニューラルネットワークの入力層に必要なパラメータを入力することで、出力層から出力パラメータが診断結果として出力される。出力パラメータは、特定の故障（エラー）が発生する可能性を示すパラメータであってもよいし、複数の故障（エラー）が発生する可能性を示すパラメータであってもよいし、又は正常状態が発生する可能性を示すパラメータであってもよい。また、故障が発生する可能性を示すパラメータ値は、例えば、最大値若しくは最小値を定めた値、連続値、又は離散値をとりうる。
【００７４】
＜サーバ装置における診断モデルの生成処理＞
次に、図７から図９及び図１４を参照して、サーバ装置１２０において実行される、診断モデルの生成処理について説明する。
【００７５】
まず、診断モデルの生成の概要について図１４を用いて説明する。各ＭＦＰ１１０ａからｃは、定期的にイベントログをサーバに送信する。イベントログには例えば、イベントログの生成日時、部品ごとのセンサ値、使用時間、設定値、本体設定値などが含まれている。
【００７６】
本体設定値としては例えば、印刷速度に関する設定や、ネットワーク設定、認証設定、動作モード（例えば、結露対策モードのＯＮ、ＯＦＦなど）が含まれる。
【００７７】
イベントログに含まれるパラメータは上記に限るものではない。例えば、ＭＦＰ１１０が実行したプリントの枚数や、スキャン処理を行った回数、ＭＦＰ１１０に含まれる不図示の感光体ドラムや各種ローラの回転数、機種情報等の情報をイベントログに含めることとしてもよい。また、上記のパラメータを全てイベントログに含める必要はない。
【００７８】
また、ＭＦＰ１１０においてエラーが発生した場合には、イベントログには、上記のパラメータに加えて、発生したエラーの種別を示す情報であるエラーコードが含まれている。エラーが発生していない状態で送られたイベントログには、エラーコードを含まないで送ってもよいし、エラーが発生していないことを示す情報を含めて送ることとしてもよい。
【００７９】
サーバ装置１２０は、各ＭＦＰ１１０ａからｃから収集したイベントログをエラーコードの有無、及び、エラーコードの種別に基づいてクラスタリング（分類）する。
【００８０】
サーバ装置１２０は、クラスタリング結果を分析して、ログの内容と発生するエラーの関連付けを行う。例えば、分析により、部品Ａのセンサ値と部品Ｂのセンサ値の組み合わせが所定の組み合わせになった場合には、エラーコード１０のエラーが発生する可能性が高いことを検出することができる。あるいは、部品Ａのセンサ値が時系列で所定の推移をした場合（例えば、センサ値が所定期間内に所定量だけ上昇した等）に、エラーコード１５のエラーが発生する可能性が高いことなどを検出することができる。さらに、上記の例に設定値の状況を加味してログの内容とエラー種別との関連付けを行うこととしてもよい。例えば、部品Ａの設定値が所定範囲内の場合に、センサ値が所定期間内に所定量上昇するとエラーコード１５のエラーが発生するなどの関連付けを行うこととしてもよい。また例えば、動作モードの状況を加味してイベントログとエラー種別の関連付けを行ってもよい。例えば、結露対策モードがＯＮ（有効）になっている状態で、かつ、ＭＦＰ１１０内のファンの合計動作時間が所定時間以上となっている場合には、ファンの特定のエラーが起きやすいことなどを関連付けることとしてもよい。
【００８１】
このようにして、サーバ装置１２０はイベントログの内容とエラー種別とを関連付けた診断モデルを作成することができる。以下、上記のクラスタリング処理及び、ログの内容とエラー種別との関連付け処理のことを学習処理と呼ぶ場合がある。
【００８２】
図７は、本実施形態に係る、診断モデルの生成処理の手順を示すフローチャートである。診断モデルの生成処理は、ネットワーク１００を介してＭＦＰ１１０から受信した情報を用いて行われる。図７に示す各ステップの処理は、サーバ装置１２０において、ＨＤＤ４０４に格納されたモデル生成サービス６００のプログラムをＣＰＵ４０１が読み出して実行することによって実現されうる。
【００８３】
Ｓ７０１で、イベントログ受信部６０１は、クライアント装置（ＭＦＰ１１０）の情報を収集する。具体的には、イベントログ受信部６０１は、ＭＦＰ１１０からイベントログの受信を待ち受け、イベントログを受信した場合、ＭＦＰ情報管理部６０２及びイベントログ管理部６０４に対して、情報の保存を指示する。ＭＦＰ情報ＤＢ６０３及びイベントログＤＢ６０５への情報の保存が完了すると、イベントログ受信部６０１はＳ７０２へ処理を進める。
【００８４】
Ｓ７０２で、学習制御部６０６は、学習処理の実行を開始するか否かを判定する。この判定は、学習処理を実行するか否かの判定についての上述の判定基準に従って行われる。例えば、故障情報（エラー情報）を含むイベントログがＭＦＰ１１０から受信されるごとに（イベントログＤＢ６０５に登録されるごとに）、学習処理の実行を開始すると判定されうる。また、前回の診断モデルの更新から所定時間が経過している場合、学習処理の実行を開始すると判定されうる。学習制御部６０６は、学習処理の実行を開始すると判定した場合には、フィルタリング部６０７への通知を行い、Ｓ７０３へ処理を進め、学習処理の実行を開始しないと判定した場合には、Ｓ７０１へ処理を戻し、再びイベントログの受信を待ち受ける。
【００８５】
Ｓ７０３で、フィルタリング部６０７及び学習データ生成部６０９は、図８に示す手順に従って、フィルタリング処理を実行する。本実施形態では、フィルタリング部６０７及び学習データ生成部６０９は、各情報処理装置（ＭＦＰ１１０）から受信されたイベントログに対して、動的情報（時系列情報）及びエラー情報を収集するためのフィルタリング処理を行う。フィルタリング部６０７は、フィルタリング処理を完了すると、フィルタリング処理の完了を学習制御部６０６に通知する。フィルタリング部６０７からの通知に応じて、学習制御部６０６は、学習処理の実行を開始するよう、学習処理部６１１に指示する。学習制御部６０６からの指示に従って、Ｓ７０４で、学習処理部６１１は、図９に示す手順に従って、学習処理を実行する。学習処理部６１１は、学習処理を完了すると、学習処理の完了を診断モデル管理部６１２に通知し、Ｓ７０５へ処理を進める。
【００８６】
Ｓ７０５で、診断モデル管理部６１２は、学習処理の結果として得られた、ＭＦＰ１１０の故障診断のための学習済モデルである診断モデルを、フィルタリング部６０７によるフィルタリング条件とともに診断モデルＤＢ６１３に格納（登録）する。診断モデル管理部６１２は、診断モデルＤＢ６１３に新しい診断モデル及びフィルタリング条件を格納すると、当該診断モデル及びフィルタリング条件を、診断モデル配信部６１４へ通知する。
【００８７】
診断モデル配信部６１４は、通知された診断モデル及びフィルタリング条件に基づいて、当該フィルタリング条件を満たすクライアント装置（ＭＦＰ１１０）へ、ネットワーク１００を介して診断モデルを配信（送信）する。クライアント装置への診断モデルの配信は、サーバ装置１２０によって自律的に行われてもよいし、当該クライアント装置からの診断モデルの取得要求に対する応答として行われてもよい。
【００８８】
このように、Ｓ７０５において学習処理により生成された診断モデルの出力（クライアント装置への送信）が完了すると、図７に示す手順による処理が終了する。
【００８９】
＜サーバ装置におけるフィルタリング処理＞
図８は、図７のＳ７０３において実行されるフィルタリング処理の手順を示すフローチャートである。図８に示す各ステップの処理は、学習制御部６０６からの指示に従って、フィルタリング部６０７及び学習データ生成部６０９によって実行される。
【００９０】
Ｓ８０１で、フィルタリング部６０７は、学習データを生成するためのフィルタリング条件を決定する。フィルタリング条件には、生成する学習データの数が含まれてもよい。フィルタリング部６０７は、決定したフィルタリング条件を、学習データ生成部６０９へ出力し、Ｓ８０２へ処理を進める。
【００９１】
Ｓ８０２で、学習データ生成部６０９は、フィルタリング条件を満たす学習データが収集済みであるか否かを判定する。学習データ生成部６０９は、フィルタリング条件を満たす学習データが収集済みではない場合には、Ｓ８０３へ処理を進め、収集済みである場合には、処理を終了する。
【００９２】
Ｓ８０３で、学習データ生成部６０９は、フィルタリング条件に基づいて、ＭＦＰ１１０の静的情報をＭＦＰ情報ＤＢ６０３から取得し、Ｓ８０４へ処理を進める。Ｓ８０３では、フィルタリング条件を満たす静的情報が取得される。Ｓ８０４で、学習データ生成部６０９は、フィルタリング条件に基づいて、１つ以上のイベントログをイベントログＤＢ６０５から取得し、Ｓ８０５へ処理を進める。Ｓ８０４では、フィルタリング条件を満たすイベントログが取得される。
【００９３】
Ｓ８０５で、学習データ生成部６０９は、Ｓ８０４で取得した、各ＭＦＰ１１０から順に受信された複数のイベントログから、当該ＭＦＰの設定及び状態を示す、同じ属性を有する情報を、動的情報（時系列情報）として収集（取得）する。例えば、学習データ生成部６０９は、複数のイベントログを時系列に並べて、各イベントログに含まれる特定のセンサに対応するセンサ値を収集し、収集した時系列のセンサ値を動的情報として取得する。
【００９４】
その後Ｓ８０６で、学習データ生成部６０９は、Ｓ８０３からＳ８０５において取得した情報（静的情報及び動的情報）を統合したデータを、学習データとして学習データＤＢ６１０に登録し、処理をＳ８０２へ戻す。なお、学習データ生成部６０９は、Ｓ８０３からＳ８０５において情報を取得するごとに、取得した情報を、学習データＤＢ６１０に格納されている、対応する学習データに登録しうる。
【００９５】
＜サーバ装置における学習処理＞
図９は、図７のＳ７０４において実行される学習処理の手順を示すフローチャートである。図９に示す各ステップの処理は、学習制御部６０６からの指示に従って、学習処理部６１１によって実行される。
【００９６】
Ｓ９０１で、学習処理部６１１は、学習制御部６０６からの指示に基づいて、学習処理部６１１による学習処理を終了する条件である学習条件を決定する。学習条件として、例えば、学習制御部６０６から指定された学習データの全てを用いて学習を行うという条件が設定されるが、その他の条件が設定されてもよい。
【００９７】
次にＳ９０２で、学習処理部６１１は、学習条件が満たされたか否かを判定する。学習条件が満たされていない場合には、Ｓ９０３へ処理を進め、学習条件が満たされた場合には、学習処理を終了する。
【００９８】
Ｓ９０３で、学習処理部６１１は、学習制御部６０６からの指示において指定された学習データのうちで、未学習の（即ち、学習処理に未だ用いられていない）学習データを選択し、Ｓ９０４へ処理を進める。Ｓ９０４で、学習処理部６１１は、Ｓ９０３で選択した学習データを用いて学習を行うことにより、学習済モデルである診断モデルを生成又は更新する。学習処理部６１１は、学習データを用いた学習を終えると、Ｓ９０２へ処理を戻し、学習条件が満たされるまでＳ９０３及びＳ９０４の処理を繰り返す。
【００９９】
サーバ装置１２０は、図７から図９を用いて説明した上述の処理を実行することにより、学習により診断モデルを生成し、生成した診断モデルを、クライアント装置であるＭＦＰ１１０へ配信できる。
【０１００】
＜ＭＦＰにおける故障診断処理＞
次に、サーバ１２０が作成した診断モデルのＭＦＰ１１０における適用方法の概要について図１５を用いて説明する。ＭＦＰ１１０は、サーバ１２０が生成した診断モデルを取得する。そして、ＭＦＰ１１０は、取得した診断モデルと、ＭＦＰ１１０自身のログ情報とを比較して、今後自装置で発生する可能性がある故障（エラー）の種別や発生確率を導出する。
【０１０１】
ＭＦＰ１１０は、診断モデルに含まれるイベントログのパターンのうちから、自装置のログ情報と類似するパターンを抽出する。そして、抽出したイベントログのパターンに関連付けられたエラー種別を、診断モデルを参照して特定する。
【０１０２】
このようにしてＭＦＰ１１０は、今後自装置で発生する可能性がある故障の種別を特定することができる。
【０１０３】
またＭＦＰ１１０は、診断モデルに含まれるイベントログのパターンと、自装置のログのパターンとの類似度を求め、当該類似度に基づいて、今後自装置で発生する可能性がある故障の種別及び発生確率を出力してもよい。
【０１０４】
故障の発生確率の表示処理について図１６を用いて説明する。図１６に示す各ステップの処理は、ＭＦＰ１１０において、ＨＤＤ３０４又はＲＯＭ３０２に格納されたプログラムをＣＰＵ３０１が読み出して実行することによって実現されうる。
【０１０５】
図１６では、診断モデルに、部品の識別情報と、センサ値の所定時間あたりの変化量と、エラーの種別が関連付けられて記述されている例について説明する。また図１６では、ＭＦＰ１１０は、部品０から部品ｎのそれぞれについて、故障発生確率を求める例について説明する。
【０１０６】
故障発生確率の表示処理が開始されると、ＣＰＵ３０１は、ステップＳ１６００において部品の種別を示すｉに初期値を設定する。すなわち、ｉ＝０を設定する。
【０１０７】
次にステップＳ１６０１において、ＣＰＵ３０１は、自装置のログに基づいて、部品ｉについてのセンサ値の所定時間あたりの変化量（変化量Ａ）を取得する。変化量は、変化前の量と変化後の量の差でもよいし、割合（変化率）で取得することとしてもよい。
【０１０８】
次にステップＳ１６０２において、ＣＰＵ３０１は、診断モデルを参照し、部品ｉに関連付けられたセンサ値の所定時間あたりの変化量（変化量Ｂ）を取得する。なお本実施形態では、説明を簡潔にするため、１つの部品について１つの変化量と１つのエラー種別のみ関連付けられている例について説明するが、これに限らない。１つの部品について複数の変化量が関連付けられており、それぞれの変化量にエラー種別が関連付けられている構成とすることが可能である。１つの部品に複数の変化量が関連付けられている場合、ＣＰＵ３０１は各変化量についてステップＳ１６０２からステップＳ１６０６の処理を繰り返す。
【０１０９】
次にステップＳ１６０３において、ＣＰＵ３０１は、ステップＳ１６０１で取得した変化量ＡとステップＳ１６０２で取得した変化量Ｂとの差分量が所定範囲内であるかを判定する。ＣＰＵ３０１は、所定範囲外である場合（ステップＳ１６０３においてＮｏの場合）は、エラーの発生の確率はないものとしてステップＳ１６０８に進む。
【０１１０】
一方、変化量Ａと変化量Ｂとの差分量が所定範囲内である場合（ステップＳ１６０３においてＹｅｓの場合）には、ステップＳ１６０４において、ＣＰＵ３０１は、Ｓ１６０２で取得した変化量Ｂに関連付けられたエラーのエラーコードを取得する。
【０１１１】
ステップＳ１６０４において、エラーコードを取得すると、次にステップＳ１６０５において、ＣＰＵ３０１は、変化量Ａと変化量Ｂとの差分量に対応する故障発生確率を取得する。例えば、差分量と故障発生確率は予め対応付けられてＨＤＤ３０４又はＲＯＭ３０２に記憶しておくことができる。ＣＰＵ３０１は、ＨＤＤ３０４又はＲＯＭ３０２から、ステップＳ１６０３で取得した差分量に対応付けられた故障発生確率を取得することができる。
【０１１２】
故障発生確率と差分量の関係について、例えば、差分量が０の場合は、故障発生確率９０％から１００％などとすることができる。また、差分量が１から５の場合は、故障発生確率が８０％から９０％などとすることができる。このように、差分量が小さいほど、故障発生確率が高いと判定することができる。
【０１１３】
次にＳ１６０６において、ＣＰＵ３０１は、ステップＳ１６０４で取得したエラーコードと、ステップＳ１６０５で取得した故障発生確率と、部品ｉの識別情報を関連付けて、ＲＡＭ３０３に記憶する。
【０１１４】
続いてＳ１６０７において、ＣＰＵ３０１は、判定対象の全ての部品についてステップＳ１６０１からＳ１６０６の処理を完了したか判定する。例えば、ｉ＝ｎとなった場合に、判定対象の全ての部品について、処理を完了したと判定する。全ての部品について処理が完了していない場合には（ステップＳ１６０７でＮｏの場合）、ＣＰＵ３０１はステップＳ１６０８に進み、ｉの値をインクリメントしてステップＳ１６０１に戻る。一方、全ての部品について処理が完了した場合には、ステップＳ１６０９において、ＣＰＵ３０１は、ステップＳ１６０６においてＲＡＭ３０３に記憶した内容を操作部２０６の表示部に表示させて処理を終了する。
【０１１５】
次に、図１０を参照して、ＭＦＰ１１０によって実行される故障診断処理について説明する。図１０は、本実施形態に係る故障診断処理の手順を示すフローチャートである。本実施形態では、ＭＦＰ１１０は、ネットワーク１００を介してサーバ装置１２０から診断モデル取得し、取得した診断モデルを用いて、自装置の故障診断を行う。図１０の各ステップの処理は、ＭＦＰ１１０において、ＲＯＭ３０２又はＨＤＤ３０４等の記憶装置に格納されたＭＦＰファームウェア５００のプログラムをＣＰＵ３０１が読み出して実行することによって実現されうる。
【０１１６】
Ｓ１００１で、診断制御部５１５は、バッファ通知部５１０からの通知を受け付けると、受け付けた通知に関連するイベントログの内容に基づいて、故障診断を実行するか否かを判定する。故障診断を実行すると判定する条件は、例えば、特定のイベントログに関する通知を受け付けたこと、又はイベントログに関する通知を受け付けた時点で、前回の故障診断の実行から所定時間が経過していることである。あるいは、当該条件は、故障診断の実行指示をユーザから受け付けたことである。
【０１１７】
診断制御部５１５は、故障診断を実行すると判定した場合には、診断モデル管理部５１６への指示を出力し、Ｓ１００１からＳ１００２へ処理を進め、故障診断を実行しないと判定した場合には、処理を終了する。
【０１１８】
Ｓ１００２で、診断モデル管理部５１６は、診断モデルＤＢ５１９に保存されている診断モデルの更新が必要か否かを判定する。診断モデルの更新が必要と判定する条件は、例えば、サーバ装置１２０において診断モデルの変更（更新）が行われたことがサーバ装置１２０から通知されたことである。診断モデル管理部５１６は、診断モデルの更新が必要と判定した場合には、Ｓ１００３へ処理を進める。一方、診断モデル管理部５１６は、診断モデルの更新が必要ないと判定した場合には、故障診断に使用すべき診断モデルを、診断モデルＤＢ５１９から読み出して診断制御部５１５へ出力し、Ｓ１００４へ処理を進める。
【０１１９】
Ｓ１００３で、診断モデル管理部５１６は、サーバ通信部５１２を介してサーバ装置１２０と通信することで、自装置用の診断モデルをサーバ装置１２０から取得する。なお、診断モデル管理部５１６は、サーバ装置１２０から取得した診断モデルを、診断モデルＤＢ５１９に保存し、かつ、診断制御部５１５へ出力し、Ｓ１００４へ処理を進める。
【０１２０】
Ｓ１００４で、診断制御部５１５は、診断モデルを用いた故障診断に必要な情報（故障診断用の情報）の収集を、情報収集部５１４に対して指示する。情報収集部５１４は、診断制御部５１５からの指示に従って、故障診断用の情報をＭＦＰ１１０内で収集し、収集した情報を診断制御部５１５へ出力する。故障診断用の情報は、例えば、バッファＤＢ５０９又は設定値ＤＢ（図示せず）から収集される。
【０１２１】
次にＳ１００５で、診断制御部５１５は、故障診断用の情報の収集を取集できたか否かを判定し、情報を収集できた場合にはＳ１００６へ処理を進め、情報を収集できなかった場合には処理を終了する。
【０１２２】
Ｓ１００６で、診断処理部５１８は、診断モデル管理部５１６から出力された診断モデルと、Ｓ１００４で収集された情報とに基づいて、図１６を用いて説明した自装置の故障診断を実行する。具体的には、診断処理部５１８は、収集された情報を入力パラメータとして診断モデルに対して入力し、故障診断の結果として診断モデルから出力される出力パラメータを得ることにより、故障診断を実行する。診断処理部５１８は、故障診断の結果として得られた出力パラメータを、診断結果通知部５１７へ出力し、Ｓ１００７へ処理を進める。
【０１２３】
Ｓ１００７で、診断結果通知部５１７は、診断処理部５１８から出力された診断結果に基づいて、当該診断結果の通知を行う通知条件が満たされたか否かを判定する。この通知条件は、例えば、特定のエラー（故障）が発生する可能性が所定の閾値を超えたこと、又は特定のエラーが発生する可能性が増加傾向にあること等である。診断結果通知部５１７は、通知条件が満たされていない場合には、診断結果の通知を行わずに処理を終了し、通知条件が満たされた場合には、Ｓ１００８へ処理を進める。
【０１２４】
Ｓ１００８で、診断結果通知部５１７は、診断結果の通知を行い、処理を終了する。診断結果の通知は、ＭＦＰ１１０のユーザに対して行われてもよいし、ＭＦＰ１１０を管理する管理者に対して行われてもよい。ユーザに対する通知は、図１３（Ｂ）及び（Ｃ）に示すように、操作部２０６を用いて行われてもよい。管理者に対する通知は、電子メール送信等の通信を用いて行われてもよい。診断結果通知部５１７は、診断結果をイベントログとしてサーバ装置１２０へ送信してもよい。
【０１２５】
以上説明したように、本実施形態では、サーバ装置１２０は、ＭＦＰ１１０を含む複数のＭＦＰから、各ＭＦＰの設定及び状態の時間的変化を示す時系列情報と、各ＭＦＰにおいて発生したエラーを示すエラー情報とを収集する。サーバ装置１２０は、収集した情報を含む学習データを生成し、生成した学習データに基づく学習により、ＭＦＰ１１０の故障診断のための学習済モデルである診断モデルを生成する。ＭＦＰ１１０は、サーバ装置１２０によって生成された診断モデルを、当該サーバ装置から取得する。更に、ＭＦＰ１１０は、故障診断に必要な情報を自装置内で収集し、収集した情報と、サーバ装置１２０から取得した診断モデルとを用いて故障診断を実行することで、ＭＦＰ１１０においてエラーが発生する可能性を示す診断結果を出力する。
【０１２６】
このように、ＭＦＰ１１０を含む複数のＭＦＰから収集された情報に基づいてサーバ装置１２０が学習により生成した診断モデルをＭＦＰ１１０に提供する。ＭＦＰ１１０は、サーバ装置１２０から提供された診断モデルを用いて故障診断を実行することで、より精度の高い故障診断を実現することが可能となる。また、ＭＦＰ１１０において、故障（エラー）の発生前にエラーが発生する予兆を検知することが可能になる。
【０１２７】
本実施形態では、ニューラルネットワークを利用した学習により、診断モデルの生成又は更新と、診断モデルによる故障診断とを行う例について説明しているが、他の方法を利用した学習により、これらの処理を行うことも可能である。
【０１２８】
［第２実施形態］
第１実施形態では、サーバ装置１２０が、ＭＦＰ１１０から収集した情報に基づいて診断モデルを生成し、ＭＦＰ１１０が、その診断モデルをサーバ装置１２０から取得し、取得した診断モデルを用いて自装置の故障診断を行う例について説明した。サーバ装置１２０は、ＭＦＰ１１０についてのある程度の情報を収集できれば、収集した情報を用いて学習データを生成し、診断モデルを生成することが可能である。一方、サーバ装置１２０は、エラーの発生情報を含むイベントログ等の情報を十分に収集できている場合には、診断モデルを生成する際に用いるフィルタリング条件として具体的な条件を指定して、当該条件を満たす診断モデルを生成することが可能である。
【０１２９】
そこで、第２実施形態では、上述のフィルタリング条件として、ＭＦＰの特定の機種、特定のパーツ、エラー種別等の条件を指定し、当該条件を満たす診断モデルを生成し、生成した診断モデルを用いてＭＦＰ１１０の故障診断を行う例について説明する。以下では、第１実施形態と共通する部分については説明を省略し、異なる部分について説明する。
【０１３０】
＜属性情報＞
第２実施形態のサーバ装置１２０は、生成した診断モデルを、当該診断モデルの属性情報と対応付けて管理する。この属性情報は、診断モデルの生成に用いられたフィルタリング条件と対応しており、例えば以下の情報を含む。
‐機種情報
‐パーツ情報
‐エラー情報
‐診断タイミング情報
【０１３１】
機種情報は、ＭＦＰの機種に関連する情報であり、ＭＦＰについての特定の機種を示す情報、ＭＦＰがモノクロ用であるかカラー用であるかを示す情報、ＭＦＰが対応している用紙サイズを示す情報、又はＭＦＰの稼働地域を示す情報である。ＭＦＰの機種に依存する診断モデルに対応する属性情報には、機種情報が含まれる。ＭＦＰの機種に依存しない診断モデルに対応する属性情報には、機種情報は含まれない。
【０１３２】
パーツ情報は、故障診断の対象となる、ＭＦＰのパーツを示す情報である。ＭＦＰのパーツに依存する診断モデルに対応する属性情報には、パーツ情報が含まれる。ＭＦＰのパーツに依存しない診断モデルに対応する属性情報には、パーツ情報は含まれない。
【０１３３】
エラー情報は、ＭＦＰにおける特定のエラー種別を示す情報である。特定のエラー種別用の診断モデルに対応する属性情報には、エラー情報が含まれる。特定のエラー種別用ではない診断モデルに対応する属性情報には、エラー情報は含まれない。エラー情報は、ＭＦＰ１１０内のバッファＤＢ５０９に登録されるイベントログに含まれる、発生したエラーの種別を示す情報であってもよい。あるいは、エラー情報は、発生したエラーがＭＦＰ１１０内のいずれの箇所において発生したエラーであるかを特定可能な構造を有する情報であってもよいし、エラーの内容を一意に特定するためのＵＵＩＤを含んでもよい。
【０１３４】
診断タイミング情報は、対応する診断モデルによる故障診断の実行タイミングを定めるための情報であり、本実施形態では、イベントログとしてバッファＤＢ５０９に登録されるイベントの種別を含む。即ち、診断タイミング情報に含まれる種別のイベントが発生した（当該イベントのイベントログが登録された）タイミングが、対応する診断モデルによる故障診断の実行タイミングとして定められる。
【０１３５】
＜サーバ装置の機能構成＞
本実施形態のサーバ装置１２０は、第１実施形態と同様の機能構成（図６）を有する。以下では、診断モデルに加えて属性情報を使用する場合の、本実施形態における各機能ユニットの動作について説明する。
【０１３６】
学習制御部６０６は、フィルタリング部６０７に対して指示するフィルタリング条件を内部に保持しており、当該フィルタリング条件から、診断モデルの属性情報を生成する。学習制御部６０６は、学習処理部６１１に対して学習処理の実行を指示する際に、学習データの指定とともに属性情報を実行指示に含めることで、学習処理に用いる学習データ及び属性情報を、学習処理部６１１に通知する。
【０１３７】
学習処理部６１１は、学習処理が完了し、生成した診断モデルを診断モデル管理部６１２へ出力する際に、学習制御部６０６から通知された属性情報も出力する。診断モデル管理部６１２は、学習処理部６１１から出力された診断モデルと属性情報とを対応付けて、診断モデルＤＢ６１３に登録（格納）する。その際、診断モデル管理部６１２は、登録対象の診断モデルに対応付けられた属性情報と同じ属性情報を有する診断モデルが診断モデルＤＢ６１３に登録されている場合には、登録済みの診断モデルに対して上書きを行ってもよい。あるいは、診断モデル管理部６１２は、登録対象の診断モデルに対してタイムスタンプを属性情報として付加し、タイムスタンプを属性情報として有する診断モデルを診断モデルＤＢ６１３に登録してもよい。
【０１３８】
診断モデル管理部６１２は、診断モデル配信部６１４からの診断モデルの取得要求において属性情報が指定されている場合には、指定された属性情報を有する診断モデルを診断モデルＤＢ６１３から取得する。更に、診断モデル管理部６１２は、取得した診断モデルを属性情報とともに診断モデル配信部６１４へ出力する。取得要求では、例えば、属性情報の全体が指定されるのではなく、機種又はパーツを示す情報の一部のみが指定されてもよい。この場合、診断モデル管理部６１２は、指定された情報を一部に含む属性情報に対応する診断モデルを、取得要求に対する応答として出力する。また、診断モデルにおいて属性情報としてタイムスタンプが指定された場合、診断モデル管理部６１２は、指定されたタイムスタンプ以降のタイムスタンプを有する診断モデルを、応答として出力する。
【０１３９】
診断モデル配信部６１４は、ＭＦＰ１１０から診断モデルの取得要求を受信する際、取得要求とともに属性情報の指定も受信する。属性情報の指定は、取得要求に含まれた状態で受信されてもよい。診断モデル配信部６１４は、受信した取得要求とともに属性情報を診断モデル管理部６１２に通知し、通知した属性情報を有する診断モデルを診断モデル管理部６１２から取得する。診断モデル配信部６１４は、診断モデル管理部６１２から取得した診断モデルと属性情報とを、取得要求に対する応答としてＭＦＰ１１０へ送信する。
【０１４０】
＜ＭＦＰの機能構成＞
本実施形態のＭＦＰ１１０は、第１実施形態と同様の機能構成（図５）を有する。以下では、診断モデルに加えて属性情報を使用する場合の、本実施形態における各機能ユニットの動作について説明する。
【０１４１】
診断モデル管理部５１６は、サーバ装置１２０から取得した診断モデルを、属性情報と対応付けて診断モデルＤＢ５１９に格納して管理する。また、診断モデル管理部５１６は、診断モデルの取得要求を、サーバ通信部５１２を介してサーバ装置１２０へ送信する際に、属性情報を指定することが可能である。その場合、サーバ装置１２０から受信した診断モデルを、属性情報と対応付けて診断モデルＤＢ５１９に格納する。なお、属性情報として、例えば、機種情報、パーツ情報、エラー情報、及び診断タイミング情報の１つ以上を指定可能である。また、診断モデル管理部５１６は、他の機能ユニットから属性情報の指定を受け付けてもよい。
【０１４２】
診断制御部５１５は、バッファ通知部５１０からの通知を受け付けると、受け付けた通知に関連するイベントログの内容を取得する。診断制御部５１５は、イベントログが示す種別のイベントに関連する診断モデル（即ち、対応する診断タイミング情報に、イベントログが示すイベント種別が含まれる診断モデル）を、診断モデル管理部５１６に対して要求する。これにより、診断制御部５１５は、イベントログが示す種別のイベントの発生に応じた故障診断のための１つ以上の診断モデルを取得する。
【０１４３】
診断制御部５１５は、診断モデル管理部５１６から取得した１つ以上の診断モデルを順に選択し、選択した診断モデルを用いた故障診断に必要となる情報の収集を、情報収集部５１４に対して指示する。更に、診断制御部５１５は、選択した診断モデルと、情報収集部５１４によって収集された故障診断用の情報とに基づく故障診断の実行を、診断処理部５１８に対して指示する。
【０１４４】
＜サーバ装置における診断モデルの生成処理＞
次に、図１１を参照して、サーバ装置１２０において実行される、診断モデルの生成処理について説明する。図１１は、本実施形態に係る、診断モデルの生成処理の手順を示すフローチャートである。診断モデルの生成処理は、ネットワーク１００を介してＭＦＰ１１０から受信した情報を用いて行われる。図１１に示す各ステップの処理は、サーバ装置１２０において、ＨＤＤ４０４に格納されたモデル生成サービス６００のプログラムをＣＰＵ４０１が読み出して実行することによって実現されうる。
【０１４５】
Ｓ７０１で、イベントログ受信部６０１は、第１実施形態と同様の処理を行い、Ｓ１１０１へ処理を進める。
【０１４６】
Ｓ１１０１で、学習制御部６０６は、イベントログ受信部６０１によって受信されたイベントログに基づいて属性情報を決定し、Ｓ１１０２へ処理を進める。Ｓ１１０２で、学習制御部６０６は、Ｓ１１０１で決定した属性情報に基づいて、学習処理の実行を開始するか否かを判定する。学習制御部６０６は、学習処理の実行を開始すると判定した場合には、フィルタリング部６０７への通知を行い、Ｓ７０３へ処理を進め、学習処理の実行を開始しないと判定した場合には、Ｓ７０１へ処理を戻し、再びイベントログの受信を待ち受ける。
【０１４７】
Ｓ７０３及びＳ７０４では、フィルタリング部６０７及び学習処理部６１１は、第１実施形態と同様の処理を行う。Ｓ７０４の処理が完了すると、学習処理部６１１は、Ｓ１１０３へ処理を進める。
【０１４８】
Ｓ１１０３で、診断モデル管理部６１２は、学習処理の結果として得られた診断モデルと、Ｓ１１０１で取得した属性情報とを対応付けて、診断モデルＤＢ６１３に格納（登録）し、処理を終了する。
【０１４９】
上述の処理によれば、属性情報ごとに診断モデルを生成するための学習処理を行うことができ、生成した診断モデルと属性情報とを対応付けて保存できる。
【０１５０】
＜ＭＦＰにおける故障診断処理＞
次に、図１２を参照して、ＭＦＰ１１０によって実行される故障診断処理について説明する。図１２は、本実施形態に係る故障診断処理の手順を示すフローチャートである。本実施形態では、ＭＦＰ１１０は、属性情報を指定してサーバ装置１２０から診断モデルを取得し、指定した属性情報に対応する診断モデルを用いて、自装置の故障診断を行う。図１０の各ステップの処理は、ＭＦＰ１１０において、ＲＯＭ３０２又はＨＤＤ３０４等の記憶装置に格納されたＭＦＰファームウェア５００のプログラムをＣＰＵ３０１がＲＡＭ３０３に展開して実行することによって実現される。
【０１５１】
Ｓ１２０１で、診断制御部５１５は、バッファ通知部５１０からの通知を受け付けると、受け付けた通知に関連するイベントログの内容に基づいて、故障診断を実行するか否かを判定する。具体的には、診断制御部５１５は、イベントログが示すイベントの種別が診断タイミング情報として対応付けられている診断モデルを、診断モデル管理部５１６に対して要求する。診断制御部５１５は、診断モデル管理部５１６から１つ以上の診断モデルを取得できた場合には、故障診断を実行するために、Ｓ１２０２へ処理を進める。一方、診断制御部５１５は、診断モデル管理部５１６からそのような診断モデルを取得できなかった場合には、故障診断を実行せずに処理を終了する。
【０１５２】
Ｓ１２０２で、診断制御部５１５は、Ｓ１２０１で取得した１つ以上の診断モデルのうち、未選択の診断モデルを１つ選択し、選択した診断モデルと対応する属性情報とを、診断モデル管理部５１６へ出力し、Ｓ１００２へ処理を進める。
【０１５３】
Ｓ１００２で、診断モデル管理部５１６は、第１実施形態と同様に、診断モデルの更新が必要か否かを判定し、診断モデルの更新が必要と判定した場合には、Ｓ１２０３へ処理を進め、必要ないと判定した場合には、Ｓ１００４へ処理を進める。
【０１５４】
Ｓ１２０３で、診断モデル管理部５１６は、更新対象の診断モデルに対応する属性情報を指定して、自装置用の診断モデルをサーバ装置１２０から取得する。診断モデル管理部５１６は、サーバ装置１２０から取得した診断モデルを、属性情報と対応付けて診断モデルＤＢ５１９に保存し、Ｓ１００４へ処理を進める。
【０１５５】
Ｓ１００４〜Ｓ１００８では、第１実施形態と同様の処理が行われる。ただし、Ｓ１００５において故障診断用の情報の収集を取集できなかった場合、Ｓ１００７において診断結果の通知条件が満たされなかった場合、及びＳ１００８における診断結果の通知が完了した場合に、Ｓ１２０４へ処理が進められる。
【０１５６】
Ｓ１２０４で、診断制御部５１５は、Ｓ１２０１で取得した１つ以上の診断モデルの全てについて、Ｓ１２０２における選択が完了しているか否かを判定する。診断制御部５１５は、未選択の診断モデルが残っている場合にはＳ１２０２へ処理を戻し、全ての診断モデルの選択が完了している場合には、処理を終了する。
【０１５７】
以上説明したように、本実施形態では、サーバ装置１２０は、学習データを生成するためのフィルタリング処理で用いられたフィルタリング条件に対応する属性情報を、生成した診断モデルに対応付けて保存する。ＭＦＰ１１０は、属性情報の指定を含む、診断モデルの取得要求を、サーバ装置１２０へ送信することで、当該取得要求で指定した属性情報に対応する診断モデルをサーバ装置１２０から取得し、取得した診断モデルを用いた故障診断を実行する。
このように、ＭＦＰ１１０は、属性情報ごとの故障診断モデルを用いた故障診断を実行することができるため、特定の属性情報に対応する故障診断の精度を向上することができる。また、複数の診断モデルを用いることで複数の故障について診断することができる。
【０１５８】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１５９】
１１０（１１０ａ，１１０ｂ）：ＭＦＰ、１２０：管理サーバ、１００：ネットワーク、２０１：コントローラ部、２０２：プリンタコントローラ、２０３：スキャナコントローラ、３０１：ＣＰＵ、４０１：ＣＰＵ
【図１】
2019213192.tif 000003
【図２】
2019213192.tif 000004
【図３】
2019213192.tif 000005
【図４】
2019213192.tif 000006
【図５】
2019213192.tif 000007
【図６】
2019213192.tif 000008
【図７】
2019213192.tif 000009
【図８】
2019213192.tif 000010
【図９】
2019213192.tif 000011
【図１０】
2019213192.tif 000012
【図１１】
2019213192.tif 000013
【図１２】
2019213192.tif 000014
【図１３】
2019213192.tif 000015
【図１４】
2019213192.tif 000016
【図１５】
2019213192.tif 000017
【図１６】
2019213192.tif 000018