JP2020181371A - 管理システム、ジョブ処理装置および方法 - Google Patents

Abstract

【課題】画像形成装置等で利用される消耗品の配送を適切に管理可能とする。【解決手段】管理システムの第一のジョブ処理装置は、消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる第一のジョブ処理装置の利用実績データを記録する記録手段を有する。記録手段は、第一のジョブ処理装置と紐付けて管理される第二のジョブ処理装置にエラーが発生したときに第一のジョブ処理装置が学習中であるかを判断し、第二のジョブ処理装置のエラーが解消したときに第一のジョブ処理装置が学習中であれば、エラーの発生中に第一のジョブ処理装置で記録された利用実績データを、第二の利用実績データとして退避させる。【選択図】図１１

Description

本発明は、管理システム、ジョブ処理装置および方法に関する。

従来、ネットワークを介して管理サーバが監視する顧客の画像形成装置が特定の消耗品の消耗度が一定以下となったことを示すアラームを管理サーバへ送信し、アラームを受信した管理サーバが該画像形成装置に交換用の消耗品を自動配送するサービスがある。画像形成装置において、該アラームを送信するべきかを判定する際に用いられる仕組み（ロジック）には、消耗品の消耗度を用いるものや、消耗品の消耗度に加えて顧客先に設置された画像形成装置の利用状況を用いるもの等、様々な仕組みがあり得る。

特許文献１は、トナーの残量と、画像形成装置の稼働条件とに基づいて配送指示を行うまでの残日数を算出し、該残日数が経過した時点でトナーを交換する作業が必要となる前に画像形成装置の設置場所へのトナーの配送指示を行う画像形成装置を開示している。

特開２０１４−９１２９８号公報

しかしながら、上述のように、トナーのボトルが空になるまでの残日数を算出して交換用のトナーを配送する仕組みにおいては、顧客先での画像形成装置の利用状況が急変すると、交換用のトナーの配送が間に合わないおそれもある。例えば、複数の画像形成装置を運用する顧客先で特定の画像形成装置が印刷できない状態となると、残りの画像形成装置に印刷が集中し、急激にプリントボリュームが伸びる事態が生じうる。

また、顧客の利用状況を学習して消耗品の交換までの残日数を算出するための予測モデルを作成し、当該予測モデルに基づいて消耗品の残日数を予測することも検討されている。ところが、予測モデルを作成する学習フェーズでイレギュラーな利用状況の変動が生じると、予測モデルにイレギュラーな利用状況が反映されてしまう。イレギュラーな利用状況で作成された予測モデルによる残日数の予測は、通常の利用状況下での信頼性が大きく低下するおそれがある。

本発明は、上記の状況に鑑みてなされたものであって、画像形成装置等で利用される消耗品の配送を適切に管理可能な管理システムを提供する。

本発明の一例である管理システムは、第一のジョブ処理装置と、前記第一のジョブ処理装置で利用される消耗品の配送を管理するサーバ装置とを備える。前記第一のジョブ処理装置は、前記消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる前記第一のジョブ処理装置の利用実績データを記録する記録手段と、前記学習で作成された前記予測モデルを用いて、前記第一のジョブ処理装置で実行された処理を入力として前記第一のジョブ処理装置に装着される前記消耗品の交換までの残日数を予測する予測手段と、を有する。前記記録手段は、前記第一のジョブ処理装置と紐付けて管理される第二のジョブ処理装置にエラーが発生したときに前記第一のジョブ処理装置が学習中であるかを判断し、前記第二のジョブ処理装置の前記エラーが解消したときに前記第一のジョブ処理装置が学習中であれば、前記エラーの発生中に前記第一のジョブ処理装置で記録された前記利用実績データを、第二の利用実績データとして退避させる。前記予測手段は、前記第二のジョブ処理装置で前記エラーが発生していない間に前記第一のジョブ処理装置で記録された第一の利用実績データから前記学習で作成された前記予測モデルを用いて、前記残日数を予測する。

本発明の一例であるジョブ処理装置は、自装置に装着される消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる前記自装置の利用実績データを記録する記録手段と、前記学習で作成された前記予測モデルを用いて、前記自装置で実行された処理を入力として前記消耗品の交換までの残日数を予測する予測手段と、を有する。前記記録手段は、前記自装置にエラーが発生したときに前記学習中であれば、記録中の前記利用実績データを退避させ、前記自装置のエラーが解消したときに前記学習中であれば、前記利用実績データを退避した利用実績データで更新し、前記利用実績データの記録を再開させる。

本発明によれば、画像形成装置等で利用される消耗品の配送を適切に管理できる。

本発明の一実施形態における管理システムの全体構成例を示す図である。 画像形成装置のハードウェア構成例を示す図である。 管理サーバのハードウェア構成例を示す図である。 画像形成装置のソフトウェア構成例を示す図である。 管理サーバのソフトウェア構成例を示す図である。 イベント情報のデータ構造の一例を示す図である。 事前配送アラームの送信処理を説明するフローチャートである。 事前配送アラームの生成処理を説明するフローチャートである。 算出部の処理を説明するフローチャートである。 算出部の処理を説明するフローチャートである。 第二の画像形成装置にエラーが発生した場合における第一の画像形成装置の処理を説明するフローチャートである。 第二の画像形成装置のエラーが解消する場合における第一の画像形成装置の処理を説明するフローチャートである。 高消耗アラームの送信処理を説明するフローチャートである。 消耗品の配送遅れの抑止処理を説明するフローチャートである。 在庫管理テーブル、監視アラーム受信管理テーブルおよび高消耗アラーム受信管理テーブルの一例を示す図である。 在庫推奨フラグのリセット処理を説明するフローチャートである。

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

図１は、本発明の一実施例における管理システムの全体構成例を示す図である。
図１に示すＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１には、画像形成装置１０２ａ、１０２ｂ、Ｐｒｏｘｙ Ｓｅｒｖｅｒ１０３、Ｆｉｒｅｗａｌｌ１０４、パーソナルコンピュータ（ＰＣ）１０５が接続されている。

なお、説明上、画像形成装置１０２ａ、１０２ｂに共通する事項に関しては、画像形成装置１０２として説明を行う。図１では、画像形成装置１０２は、ＬＡＮ１０１に２台接続されており、同一顧客の環境下において複数の画像形成装置１０２が設置されていることを示している。しかし、これに限られるものではなく、本実施形態における画像形成装置１０２は１台であってもよく、３台以上設置されていてもよい。

また、本実施形態では、管理システムによって消耗品の自動配送を受けるジョブ処理装置の一例として、用紙に対してトナーやインク等の記録剤を用いて画像形成を行う画像形成装置を説明する。しかし、ジョブ処理装置は画像形成装置に限られず、例えば、造形材料等の記録剤を用いて３次元のオブジェクトを造形する装置、所謂３Ｄプリンタであってもよい。また、画像形成装置１０２は、ＦＡＸやコピー等の複合機能を備える装置であってもよい。

Ｐｒｏｘｙ Ｓｅｒｖｅｒ１０３は、イントラネット１０７からＨＴＴＰやＨＴＴＰＳなどのプロトコルで、複数のユーザがインターネット１０８に接続可能とする。Ｆｉｒｅｗａｌｌ１０４は、イントラネット１０７のセキュリティを高めるために設置される。ＰＣ１０５は、顧客先において一般のユーザが業務等で使用するものであって、ハードウェア資源と、ソフトウェア資源を備えて構成され、ソフトウェア資源に含まれるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）がアプリケーションの実行等を制御する。

管理サーバ１０６は、サーバ装置の一例であって、画像形成装置１０２の稼動状態を一元的に管理する。例えば、管理サーバ１０６は、画像形成装置１０２の稼動情報の収集や画像形成装置１０２の故障検出等を行い、必要に応じて保守の手配等を行う。また、例えば、管理サーバ１０６は、管理対象の画像形成装置１０２の消耗品の顧客先での在庫状況の管理を行い、必要に応じて新しい消耗品の顧客先への配送の自動手配等を行う。ここで、消耗品とは、トナー、インク、紙、造形材料全般等の消耗材や、トナーボトル、トナーカートリッジ、インクタンク、インクボトル、インクカートリッジ、交換部品等のことである。

イントラネット１０７は、画像形成装置１０２とＰｒｏｘｙ Ｓｅｒｖｅｒ１０３、Ｆｉｒｅｗａｌｌ１０４とがＬＡＮ１０１を介して相互に接続された環境に対応する。実際には複数のイントラネット１０７と、管理サーバ１０６とがインターネット１０８を介して相互に通信可能に接続されている。配送システム１０９は、販売会社が構築するシステムであり、管理サーバ１０６からメール等で通知される各種情報に基づいて、消耗品を顧客へ配送する。本実施形態では、配送対象の消耗品の一例として、トナーボトルについて説明するが、これに限られるものではなく、本発明は、交換部品等その他の消耗品についても同様に適用できる。

図２は、画像形成装置１０２のハードウェア構成例を示す図である。
画像形成装置１０２は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０４、ネットワークＩ／Ｆ２０５、内部バス２０６、デバイス制御部２０７、印刷部２０８、入出力Ｉ／Ｆ２０９、入出力装置２１０等を有する。なお、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略であり、ＲＯＭはＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略であり、ＲＡＭはＲａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙの略である。

ＣＰＵ２０１は、内部バス２０６を介して各デバイスを総括的に制御する。内部バス２０６には、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０４、ネットワークＩ／Ｆ２０５、デバイス制御部２０７、入出力Ｉ／Ｆ２０９、等が接続されている。ＲＯＭ２０２には、後述する図７〜図１３のフローチャートの処理を実現するプログラムが格納されている。

ＲＡＭ２０３は、ＣＰＵ２０１のメモリやワークエリアとして機能する。ＣＰＵ２０１は、ＲＯＭ２０２やＲＡＭ２０３とともに上記プログラムの実行処理を行うとともに、記憶装置２０４等の記録媒体に画像データを記録する処理を行う。記憶装置２０４は、外部記憶装置として機能し、画像データ等を格納するほか、ＲＡＭ２０３に代わって、カウンタ情報やシステム情報、各種ログを格納することも可能である。

ネットワークＩ／Ｆ２０５は、ＬＡＮ１０１を介して、外部のネットワーク機器あるいはＰＣと片方向または双方向にデータをやり取りする。デバイス制御部２０７は、印刷部２０８を制御する。印刷部２０８は、例えば電子写真方式の印刷部であり、露光部、転写部や定着器などを含む。入出力装置２１０は、画像形成装置１０２における入出力を担う複数の構成を示す。

具体的には、顧客先のユーザからの入力（ボタン入力など）を受け付け、該入力に対応する信号を、入出力Ｉ／Ｆ２０９によって、前述した各処理部へ伝える。入出力装置２１０は、他にも、ユーザに対して必要な情報を提供したり、操作を受け付けたりするための表示装置（タッチパネルなど）を含む。さらに、原稿を読み取り、入力として電子データを受付けるためのスキャン装置も入出力装置２１０に含まれてよい。

図３は、管理サーバ１０６のハードウェア構成例を示す図である。
管理サーバ１０６は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、記憶装置３０４、ネットワークＩ／Ｆ３０５、内部バス３０６、入出力Ｉ／Ｆ３０７、入出力装置３０８等を有する。

ＣＰＵ３０１は、内部バス３０６を介して各デバイスを総括的に制御する。内部バス３０６には、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、記憶装置３０４、ネットワークＩ／Ｆ３０５、入出力Ｉ／Ｆ３０７、等が接続されている。ＲＯＭ３０２には、後述する図１４、図１６のフローチャートの処理を実現するプログラムが格納されている。

ＲＡＭ３０３は、ＣＰＵ３０１のメモリやワークエリアとして機能する。ＣＰＵ３０１は、ＲＯＭ３０２やＲＡＭ３０３とともに上記プログラムの実行処理を行う。記憶装置３０４は、外部記憶装置として機能し、画像形成装置１０２の稼動情報等を格納する他、ＲＡＭ３０３に代わって、システム情報および各種処理情報を格納することも可能である。

ネットワークＩ／Ｆ３０５は、ＬＡＮ１０１を介して、画像形成装置１０２等の外部のネットワーク機器あるいはＰＣ１０５と片方向または双方向にデータをやり取りする。このやり取りにより、管理サーバ１０６は、画像形成装置１０２から稼働情報等の各種情報を収集することが可能となる。

入出力装置３０８は、管理サーバ１０６における入出力を担う複数の構成を示す。具体的には、管理サーバ１０６のオペレータからの入力をキーボードやポインティングデバイス等から受け付け、該入力に対応する信号を、入出力Ｉ／Ｆ３０７によって、前述した各処理部へ伝える。入出力装置３０８は、他にも管理サーバ１０６のオペレータに対して必要な情報を提供したり、操作を受け付けたりするための表示装置（ＣＲＴや液晶ディスプレイ等）を含む。

図４は、画像形成装置１０２のソフトウェア構成例を説明する図である。
図４では、主に消耗品の一例としてのトナーボトルの管理に関連する制御を実行するソフトウェア構成について示し、それ以外の構成については省略する。画像形成装置１０２は、送信部４０１、記憶部４０２、画像形成部４０３、状態管理部４０４、操作部４０５、表示部４０６、イベント管理部４０７、トナーボトル管理部４０８等を有する。

送信部４０１は、画像形成装置１０２に関する情報（デバイス情報）や画像形成装置１０２で発生したイベントに関する情報（イベント情報）、各種カウンタ情報、消耗品の消耗度情報等を管理サーバ１０６へ送信する。詳細には、送信部４０１は、上述した各種情報を記憶部４０２から取得し、取得した情報を所定のフォーマットに編集したうえで管理サーバ１０６へ送信する。デバイス情報には、画像形成装置１０２の識別情報（シリアルナンバー）、ネットワーク情報（ＩＰアドレス）、稼動情報等が含まれ、必要に応じていずれかの情報が通知などに利用される。

管理サーバ１０６へのイベント情報の送信は、画像形成装置１０２を顧客先で設置する際の一連の設置作業の中で、管理サーバ１０６と通信テストが行われた後に開始される。また、送信部４０１は、管理サーバ１０６から送信される各種指示や、設定データ等を受信する。なお、上述した各種データの送受信は、ＳＭＴＰやＨＴＴＰ／ＨＴＴＰＳなどのプロトコルを用いて行う。

記憶部４０２は、ＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０４等への情報の格納や読み出しといった記憶制御を行う。また、記憶部４０２は、画像形成装置１０２の管理に必要な管理情報を格納する。具体的には、管理情報は、例えば、ファームウェア情報や画像形成装置１０２の識別情報等のデバイス構成情報、各種カウンタ情報、消耗品の消耗度情報、画像形成装置１０２の動作履歴や、さまざまな異常状態を表す履歴情報（ログデータ）等を含む。

本実施形態において、画像形成装置１０２の記憶部４０２は、後述する事前配送アラーム発行済フラグ（図７）の情報および在庫推奨フラグ（図１３）の情報を格納する。また、画像形成装置１０２の記憶部４０２は、それぞれ後述する利用実績データや学習結果の情報を格納する。

また、管理情報は、例えば、前述したデバイス情報や、管理サーバ１０６に関する情報（サーバ情報）を含む。サーバ情報は、画像形成装置１０２を管理する管理サーバ１０６のアドレス情報等、管理サーバ１０６との通信に用いる情報を含む。記憶部４０２は、上述した各種情報をＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０４等に記録する。

画像形成部４０３は、印刷部２０８に渡す印刷データを生成し出力する。
状態管理部４０４は、画像形成装置１０２の印刷制御や異常状態の管理等を行うとともに、カウンタ情報の管理や通知情報の管理を行う。カウンタ情報とは、例えば、画像形成装置で印刷された印刷枚数をセンサ等でカウントした値や、部品の消耗度および記録剤の残量等を含む消耗品の消耗度を表す情報（消耗度情報）である。
また、状態管理部４０４は、管理サーバ１０６へ定期的に画像形成装置１０２に対する指示あるいは通知があるか問い合わせを行う。問い合わせの結果、画像形成装置１０２への指示がある場合、画像形成装置１０２は当該指示を実行し、その実行結果を管理サーバ１０６へ通知する。指示の内容によっては、画像形成装置１０２は各処理部への指示を行い、各処理部での指示に基づく実行結果を管理サーバ１０６へ通知する。

操作部４０５は、画像形成装置１０２に対する操作指示を可能とするインタフェースである。操作指示は、例えば、印刷指示等である。表示部４０６は、画像形成装置１０２の状態情報や、記録剤の残量情報等を含む各種消耗品の消耗度情報、設定情報等のＵＩ画面を入出力装置２１０に表示する。

イベント管理部４０７は、画像形成装置１０２でのイベント発生を受けてイベント情報を管理する。イベント管理部４０７が管理するイベント情報は、例えば、画像形成装置１０２のユーザが発行する印刷ジョブやエラー（障害）、画像形成装置１０２のステータス情報等を含む。

例えば、画像形成装置１０２のエラーには、ハードディスクエラーや課金カウンタエラー等の緊急性の高いエラーや、紙ジャム、トナーロー（トナーの残量少）またはトナー空（トナー残量が０％）等のワーニングレベルのエラーがある。また、トナーボトルの交換により発生するイベントや、ファームウェアの更新により発生するイベントについても、イベント情報がデバイスインタフェース４１６を介してイベント管理部４０７へ通知される。

トナーボトル管理部４０８は、画像形成装置１０２におけるトナーボトルの着脱およびトナー残量情報の管理を行う。トナー残量情報には、該トナーボトルの現状態のトナー残量や、該トナー残量およびユーザの利用状況に基づき算出されたトナーボトルの交換が必要となり得るまでの日数（残日数）が含まれる。トナーボトル管理部４０８は、ボトル検知部４０９、残量検知部４１０、ボトルＩＤ検知部４１１、および算出部４１２から構成される。

ボトル検知部４０９は、画像形成装置１０２においてトナーボトルが交換されたことを検知すると、トナーボトルの交換の開始や完了を示す情報を、デバイスインタフェース４１６を介してイベント管理部４０７へ通知する。残量検知部４１０は、トナーボトルが装着されると、トナーボトル内のトナーの残量情報をトナーボトルが備えるメモリタグ等の記憶装置から取得し、トナー残量の初期値として算出部４１２へ送信する。

ボトルＩＤ検知部４１１は、トナーボトルの識別情報をトナーボトルが備えるメモリタグ等の記憶装置から取得する。ボトルＩＤ検知部４１１は、例えば、画像形成装置１０２にトナーボトルが装着された際に、トナーボトルの識別情報（シリアルナンバー）を取得する。また、ボトルＩＤ検知部４１１は、取得したトナーボトルの識別情報を、デバイスインタフェース４１６を介して記憶部４０２へ送信し、管理する。また、ボトルＩＤ検知部４１１は、取得したトナーボトルの識別情報を、デバイスインタフェース４１６を介してイベント管理部４０７に送信する。

算出部４１２は、画像形成装置１０２が印刷処理を行うことによりトナーを利用すると、現時点でのトナー残量を算出する。算出部４１２は、例えば、画像形成の際にラスタデータのドットカウント値に基づいてトナー残量のカレント値を算出する。また、算出部４１２は、例えば、トナー貯留部（ホッパ）内に設けられた可動部材の駆動源であるモータの累積回転数に基づいてトナー残量のカレント値を算出する。なお、算出部４１２において、トナー残量を算出するときのロジックについては特に限定するものではない。

算出部４１２は、画像形成装置１０２におけるユーザの過去の利用状況を学習して作成された予測モデルを用いて、画像形成装置１０２で実行された処理を入力としてトナーボトルの交換が必要となり得るまでの日数（残日数）を算出する。算出部４１２の処理は、予測モデルを作成する学習フェーズと、予測モデルが作成された後の予測フェーズで以下のように相違する。

学習フェーズでの算出部４１２は、ユーザによる画像形成装置１０２の利用状況の実測データ（利用実績データ）を用いて学習を行い、上記の残日数の予測モデルを作成する処理を行う。学習フェーズでの算出部４１２および記憶部４０２は、記録手段の一例である。また、学習フェーズでの算出部４１２は、学習手段の一例である。

学習フェーズの算出部４１２は、画像形成装置１０２の実際の利用状況に基づく利用実績データを記憶部４０２に記録して収集する。一例として、利用実績データは、任意の時点でのトナー残量のカレント値と当該時点からトナーが実際になくなるまでの時間が紐付けされた情報を含む。また、利用実績データには、例えば、画像形成装置１０２での月日、曜日、時間帯に応じた印刷頻度や、個々の印刷の設定（例えば、印刷枚数、用紙のサイズ、カラーや白黒の印刷種別）や、トナーボトルの交換期間等の情報などが含まれていてもよい。なお、利用実績データに含まれる利用状況の情報は上記に限定されない。

学習フェーズの算出部４１２は、利用実績データから学習用データとして入力データと教師データを準備する。また、算出部４１２は、学習モデル（パラメータ調整が完了していない予測モデル）に入力データを入力することで残日数を算出する。そして、算出部４１２は、学習モデルから入力データによって得られた残日数と、教師データに基づいて得られた残日数との乖離を所定の損失関数で求める。算出部４１２は、利用実績データを収集しながら、汎化能力が適切な状態で上記の乖離が小さくなるように学習モデルのパラメータを調整する処理を繰り返して学習を行う。これにより、上記の予測モデルが作成される。
なお、学習フェーズにおいて収集された利用実績データから予測モデルを作成する学習の処理自体は、図示しない外部のコンピュータ（例えば、管理サーバ１０６や配送システム１０９とは異なる他のサーバ装置）で行われてもよい。

一方、予測フェーズでの算出部４１２は、学習フェーズで作成された予測モデルを用いて、画像形成装置１０２で実行された処理を入力としてトナーボトルの交換までの残日数を予測する。予測フェーズでの算出部４１２は、予測手段の一例である。

また、算出部４１２は、画像形成装置１０２においてトナーが利用されると、その都度算出したトナー残量等のトナー残量情報を記憶部４０２およびトナーボトルの記憶装置に格納する。トナー残量情報には、上記の残日数の情報が含まれていてもよい。
なお、本実施形態では、トナー残量やトナーボトルの交換までの残日数は、算出部４１２が算出するが、これに限られるものではない。例えば、これらの情報の一部または全部は、画像形成装置１０２では算出せず、外部の装置から取得するようにしてもよい。

また、算出部４１２は、算出したトナー残量情報を、デバイスインタフェース４１６を介して表示部４０６へ送信する。表示部４０６は、受信したトナー残量情報を入出力装置２１０に表示する。また、算出部４１２は、トナーボトルの交換までの残日数が配送閾値に達したことを示すイベントの発生を管理サーバ１０６に通知し、管理サーバ１０６に交換用ボトルの配送を促す。

図５は、管理サーバ１０６のソフトウェア構成を示す図である。
管理サーバ１０６は、通信部５０１、記憶部５０２、表示部５０３、コマンド解析部５０４、レスポンス生成部５０５、管理部５０６、アラーム生成部５１３等を有する。通信部５０１は、画像形成装置１０２と通信を行う。

具体的には、通信部５０１は、画像形成装置１０２から送信されるデバイス情報や画像形成装置１０２で発生したイベント、例えば、トナーボトル交換イベント等のイベント情報を受信する。また、通信部５０１は、画像形成装置１０２へ通信スケジュールの指示や、各種設定情報、保守に必要な情報等を送信する。

記憶部５０２は、ＲＯＭ３０２、ＲＡＭ３０３、記憶装置３０４等への情報の格納や読み出しといった記憶制御を行う。記憶部５０２は、例えば、デバイス情報や販売会社情報、顧客情報等を格納する。表示部５０３は、記憶部５０２に格納された画像形成装置１０２の状態情報や設定情報等のデバイス情報をＷｅｂ画面として入出力装置３０８に表示する。管理サーバ１０６では、ＷＷＷサーバプログラムが動作しており、これにより販売会社の担当者等がＰＣ上のＷｅｂブラウザを用いて上述した各種情報を閲覧することができる。以下、管理サーバ１０６が提供するＷｅｂ画面をポータルサイトと呼ぶ。

コマンド解析部５０４は、画像形成装置１０２から送信された要求（コマンド）を解析し、解析した結果を記憶部５０２、表示部５０３、および管理部５０６に反映させる。レスポンス生成部５０５は、コマンド解析部５０４により解析されたコマンドに対する画像形成装置１０２へのレスポンスを生成する。

管理部５０６は、画像形成装置１０２を監視し保守を行うために必要な情報を管理する。管理部５０６は、通知管理部５０７、販売会社管理部５０８、デバイス情報管理部５０９、顧客管理部５１０、イベント受信部５１１、および在庫管理部５１２から構成される。通知管理部５０７は、通知内容や通知先の指定を行い、通知情報を生成する。通知には、例えば、画像形成装置１０２を保守する販売会社の担当者を手配するシステム（不図示）への保守依頼を行う通知や消耗品の補充依頼を行う通知がある。

販売会社管理部５０８は、顧客環境に設置された画像形成装置１０２の管理、保守（サポート）を行う販売会社の情報を管理する。

デバイス情報管理部５０９は、保守対象の画像形成装置１０２のデバイス情報を管理する。デバイス情報管理部５０９の管理対象となる情報は、画像形成装置１０２の識別情報、異常などの状態情報、保守履歴、画像形成装置１０２の管理者情報、画像形成装置１０２の消耗品管理情報、イベント受信部５１１が受信したイベント情報の履歴等である。
また、本実施形態において、デバイス情報管理部５０９は、監視アラーム受信管理テーブルと高消耗アラーム受信管理テーブルの各データテーブルを格納する。監視アラーム受信管理テーブルのデータ構造は、図１５（Ｂ）を用いて後述し、高消耗アラーム受信管理テーブルのデータ構造は、図１５（Ｃ）を用いて後述する。

顧客管理部５１０は、画像形成装置１０２を設置する顧客（ユーザ）の情報を管理する。顧客の情報は、顧客が利用する画像形成装置１０２の識別情報や、顧客と販売会社との保守契約に関する情報を含む。

イベント受信部５１１は、画像形成装置１０２で発生したイベント情報を、通信部５０１を介して受信する。イベント受信部５１１が受信するイベント情報は、例えば、トナーボトル交換イベントや、トナーボトルの交換までの残日数が配送閾値に達したことを示すイベント等のイベント情報である。

本実施形態では、トナーボトル交換に関連するイベントとして管理サーバ１０６に送信されるイベント情報には、トナーボトルの新品配送に係るアラームがある。具体的には、トナーボトルの交換までの残日数が所定の配送閾値に達したことから、トナーを使い切る前に交換用のトナーボトルの配送を促す「事前配送アラーム」がある。配送閾値は、トナーの残量または交換までの残日数が少なくなり、新しいトナーボトルの配送手配が必要となることを示す値である。ここでの配送閾値は、トナーボトルの配送に要する日数を鑑みて任意の値を設定できる。

また、トナーボトル交換に関連するイベントとして管理サーバ１０６に送信されるイベント情報には、新しいトナーボトルが装着されたことを通知するアラームや、トナーボトルが使い切られる前に途中で取り出されたことを通知するアラーム等が含まれる。
さらに、その他のイベント情報には、例えば、高消耗アラームや、トナーボトル空アラームが含まれる。高消耗アラームは、単位時間当たりのトナーの消費量が既定値を超えたトナーボトルがあることを示すアラームである。トナーボトル空アラーム（以下、空アラームとも称する）は、画像形成装置１０２の残量検知部４１０が、特定のトナーボトル内のトナー残量が０％になったことを検知した際に発行するアラームである。

なお、本実施形態では、画像形成装置１０２からのアラームとは、画像形成装置１０２の障害ではなく、通知または記録すべきイベントとして定義する。画像形成装置１０２は、送信部４０１により、上述した各種アラームを管理サーバ１０６やその他の外部のシステムに通知することができる。

イベント受信部５１１は、受信したイベント情報をデバイス情報管理部５０９に格納する。また、イベント受信部５１１は、事前配送アラームを受信すると、新しいトナーボトルの自動配送を依頼するメッセージを作成し、通信部５０１を介して販売会社の配送システム１０９に送信する。すなわち、イベント受信部５１１は、配送システム１０９に対して新しいトナーボトルの配送指示を行う。

これにより、トナーボトルの交換時期が来る前に新しいトナーボトルが自動的にユーザへ配送される。したがって、ユーザ自らが画像形成装置１０２の表示装置等で表示されるトナー残量情報等を監視し、適切なタイミングで新しいトナーボトルを発注するといった手間を省くことができる。

また、イベント受信部５１１は、画像形成装置１０２から管理サーバ１０６に対する各種情報の取得要求を受信する。イベント受信部５１１は、該取得要求を受信すると、レスポンス生成部５０５を介して画像形成装置１０２が必要とする情報を含むレスポンスを生成し、通信部５０１を介して画像形成装置１０２へ送信する。

在庫管理部５１２は、顧客情報に関連付けて、画像形成装置１０２で交換可能なトナーボトルや定着器などの部品、回収トナーボックス等、顧客が利用できる消耗品の在庫数を在庫情報として管理する。本実施形態において、在庫管理部５１２は、在庫情報に関するデータテーブルである在庫管理テーブルを格納する。在庫管理テーブルのデータ構造については、図１５（Ａ）を用いて後述する。

在庫管理部５１２は、管理サーバ１０６において、顧客が消耗品を交換し、在庫から新しい消耗品を利用したことを示す通知を画像形成装置１０２から受信すると、該当する顧客の在庫情報を更新、すなわち在庫数を減算する。
また、在庫管理部５１２は、顧客が利用できる消耗品の在庫数が少なくなると、自動配送を依頼するメッセージを作成し、通信部５０１を介して販売会社などに消耗品の配送を指示する。

アラーム生成部５１３は、通常は画像形成装置１０２が生成し管理サーバ１０６に通知するイベント情報を、擬似的に生成する。
例えば、アラーム生成部５１３は、顧客に対して予備のトナーボトルの配送が必要と判断した際に、画像形成装置１０２の生成する事前配送アラームの代わりとなるイベント情報を、イベント受信部５１１からの指示を受けて擬似的に生成する。これにより、画像形成装置１０２からのイベント通知なしに消耗品の配送を指示するためのアラーム（以下、疑似アラームとも称する）を疑似的に生成することができる。なお、疑似アラームに関連する処理の詳細については、図１４を用いて後述する。

図６は、管理サーバ１０６が、画像形成装置１０２から受信するイベント情報のデータ構造の一例を示す図である。
なお、図６では、画像形成装置１０２から送信されるイベント情報の一例として事前配送アラームを例に説明する。すなわち、図６に示すイベント情報は、トナーボトルのトナー残量またはトナーボトルの交換までの残日数が配送閾値に達したことを示すイベントが発生した場合に、画像形成装置１０２から管理サーバ１０６に通知される。その他のイベント情報についても同様のデータ構成とする。

イベント情報は、画像形成装置１０２において各種イベントが発生した際に生成され、管理サーバ１０６に送信される。イベント情報は、例えば、ＸＭＬ形式で記述され、ＨＴＴＰＳ等の暗号化プロトコルを用いて管理サーバ１０６に送信される。しかし、イベント情報の形式や送信する際の通信プロトコル等はこれに限定するものではない。

トナーボトルのトナー残量またはトナーボトルの交換が必要となり得る日数が所定の閾値に達したことを示すイベント情報は、画像形成装置１０２からのアラーム（事前配送アラーム）として管理サーバ１０６へ通知される。なお、上述したように、本実施形態では、画像形成装置１０２からのアラームは、画像形成装置１０２の障害ではなく、通知または記録すべきイベントとして定義される。画像形成装置１０２のアラームは、トナーボトルに関するイベントに限らず、「用紙切れ」や「ステープル切れ」等のイベントも含む。

これらのイベントは、管理サーバ１０６においてコードで管理されており、イベント毎に対応するコードが存在する。イベント情報には、これらのコードが後述するアラームコード６０７およびアラームサブコード６０８として含まれる。以下、イベント情報に含まれる各項目について説明する。

図６に示すように、イベント情報は、デバイス識別情報６０１とアラーム情報６０５とから構成される。デバイス識別情報６０１は、画像形成装置１０２を識別するための情報であり、本実施形態では、ＩＰアドレス６０２、シリアルナンバー６０３、製品名称６０４等の情報を含む。アラーム情報６０５は、画像形成装置１０２で発生したイベントの内容を示す情報であり、発生時刻６０６、アラームコード６０７、アラームサブコード６０８、拡張情報６０９、カウンタ値６１０を含む。

発生時刻６０６は、イベントが発生した時刻を示し、例えば、事前配送アラームの場合、トナー残量またはトナーボトルの交換までの残日数が所定の配送閾値に達したことを検知したときの時刻が記録される。アラームコード６０７は、上述した各イベントに対応するコードであり、画像形成装置１０２で発生したイベントの内容を示す情報をコード化したものである。

本実施形態では、アラームコード６０７により、画像形成装置１０２において発生したイベントが、トナー残量やトナーボトルの交換が必要となり得る日数が配送閾値に達したことを通知するイベントであることが特定される。

アラームサブコード６０８は、イベントの内容の詳細を示す情報をコード化したものである。例えば、アラームサブコード６０８は、トナーボトルに関連するイベント情報の場合、イベントの対象であるトナーボトルのトナーの色情報等を示す。また、例えば、トナーボトルの交換に関連するイベント情報において、アラームサブコード６０８には、新しいボトルが装着されたのか、使い切られる前に途中で取り出されたのか等の情報がサブコード化されて設定されてもよい。

拡張情報６０９は、アラームコード６０７やアラームサブコード６０８のみでは表現できないイベント固有の情報を記録する。例えば、事前配送アラームの場合、イベントの対象であるトナーボトルの識別情報（トナーボトルＩＤ）やイベントが発生した時点でのトナーボトルのトナー残量情報（残量または残日数）が記録される。カウンタ値６１０は、イベントが発生した時点で画像形成装置１０２がカウントしたトータルカウンタ値を記録する。

図７は、画像形成装置１０２が事前配送アラームを送信するまでの処理を説明するフローチャートである。

まず、ステップＳ７０１において、算出部４１２は、画像形成装置１０２に装着されているトナーボトルの何れかにおいて、トナーボトルの交換までの残日数が配送閾値に達したことを検知する。
ここで、予測フェーズの場合、算出部４１２は予測モデルを用いて上記の残日数を予測する。一方、学習フェーズの場合、算出部４１２は、学習モデルを用いずに所定のアルゴリズムで上記の残日数を算出してもよく、学習中の学習モデルを用いて上記の残日数を算出してもよい。

ステップＳ７０２において、算出部４１２は、ステップＳ７０１で検知されたトナーボトルを対象とする事前配送アラームが発行済であるか判断する。例えば、算出部４１２は、記憶部４０２で管理する事前配送アラーム発行済フラグがＯＮ（１）であると、事前配送アラームが発行済であると判断する。
ここで、事前配送アラーム発行済フラグは、事前配送アラームが発行されたときにＯＦＦ（０）からＯＮ（１）に変更される。また、ユーザにより新しいボトルが装填されたことをボトル検知部４０９が検知した際に、事前配送アラーム発行済フラグは、ＯＮ（１）からＯＦＦ（０）に変更される。

事前配送アラームを発行済の場合、図７の処理は終了する。これにより、１つのトナーボトルに対して、事前配送アラームが重複して発行されてしまうことが抑止される。一方、事前配送アラームを発行済ではない場合、処理はステップＳ７０３へ進む。

ステップＳ７０３において、送信部４０１は、事前配送アラームを生成し、生成した事前配送アラームを管理サーバ１０６へ送信する。なお、ステップＳ７０３の処理の詳細は、図８を用いて後述する。
ステップＳ７０４において、算出部４１２は、記憶部４０２で管理する事前配送アラーム発行済フラグの値をＯＮ（１）に更新し、図７に示す処理を終了する。

図８は、ステップＳ７０３の処理の詳細を説明するフローチャートである。
ステップＳ８０１において、送信部４０１は、事前配送アラームとして送信するデータ（図６）を生成する。このとき、アラームコード６０７に対して、事前配送アラームの対象となるトナーボトルの残日数が配送閾値に達したことを通知するイベントが発生したことを意味するアラームコードを設定する。

ステップＳ８０２において、送信部４０１は、事前配送アラームとして送信するデータのアラームサブコード６０８を決定する。アラームサブコード６０８には、例えば、アラームの対象となるトナーボトルの色情報等が設定されてもよい。なお、本実施形態では、事前配送アラームにはアラームサブコード６０８を設定しないものとする。

ステップＳ８０３において、送信部４０１は、拡張情報６０９に設定する情報を記憶部４０２から取得する。詳細には、送信部４０１は、事前配送アラームの対象となるトナーボトルについて、算出部４１２が算出した現時点でのトナー残量を記憶部４０２から取得し、拡張情報６０９に取得したトナー残量を設定する。

ステップＳ８０４において、送信部４０１は、さらに、事前配送アラームの対象となるトナーボトルについて、トナーボトルの交換が必要となり得るまでの日数に関する情報（残日数情報）が記憶部４０２に存在するか確認する。残日数情報が存在する場合、処理はステップＳ８０５へ進み、残日数情報が存在しない場合、処理はステップＳ８０６に進む。

ステップＳ８０５において、送信部４０１は、事前配送アラームの対象となるトナーボトルの残日数情報を記憶部４０２から取得し、拡張情報６０９に取得した日数に関する情報を設定する。その後に処理はステップＳ８０６へ進む。

ステップＳ８０６において、送信部４０１は状態管理部４０４が管理する現時点でのトータルカウンタ値を取得し、カウンタ値６１０に取得したカウンタ値を設定する。そして、送信部４０１は、上述したように各項目の値を設定することにより生成した事前配送アラームを管理サーバ１０６へ送信する。送信部４０１が送信を完了すると、図８の処理は終了する。

図９は、画像形成装置１０２にエラーが発生したときの算出部４１２の処理を説明するフローチャートである。

ステップＳ９０１において、算出部４１２は、画像形成装置１０２でのエラー発生と画像形成装置１０２の印刷不可を示すエラー通知をイベント管理部４０７から受信し、画像形成装置１０２のエラー発生を検知する。

ステップＳ９０２において、算出部４１２は、残日数の算出に関する学習フェーズであるかを判定する。学習フェーズである場合には、処理はステップＳ９０３に進む。一方、学習フェーズではない場合には、図９の処理は終了する。なお、本実施形態において学習フェーズではない場合としては、例えば、予測モデルが作成済みであって予測フェーズである場合や、予測モデルの作成に関する学習機能自体をオフにしている場合などが挙げられる。

ステップＳ９０３において、算出部４１２は、学習フェーズにおいて現時点で収集されている利用実績データと学習結果（学習中の学習モデル）を、記憶部４０２に保存して退避させる。その後、図９の処理は終了する。

図１０は、画像形成装置１０２のエラーが解消したときの算出部４１２の処理を説明するフローチャートである。

ステップＳ１００１において、算出部４１２は、画像形成装置１０２でのエラー解消と画像形成装置１０２が印刷可能であることを示すエラー解消通知をイベント管理部４０７から受信し、画像形成装置１０２のエラー解消を検知する。

ステップＳ１００２において、算出部４１２は、残日数の算出に関する学習フェーズであるかを判定する。学習フェーズである場合には、処理はステップＳ１００３に進む。一方、学習フェーズではない場合には、図１０の処理は終了する。

ステップＳ１００３において、算出部４１２は、現時点の利用実績データと学習結果を、ステップＳ９０３で記憶部４０２に保存することで退避していた利用実績データと学習結果でそれぞれ更新する。
ステップＳ１００４において、算出部４１２は、ステップＳ１００３の更新後に、利用実績データの収集と学習モデルの学習を再開する。その後、図１０の処理は終了する。

上記のように、画像形成装置１０２は、残日数の算出に関する学習フェーズでエラーが発生すると、現時点の利用実績データと学習結果を退避させる（Ｓ９０１、Ｓ９０３）。そして、画像形成装置１０２は、エラーの解消時に退避させた利用実績データと学習結果に基づいて、利用実績データの収集と学習モデルの学習を再開させる（Ｓ１００１、Ｓ１００３、Ｓ１００４）。

エラーの発生中（画像形成装置１０２が利用不可であった期間）はトナーの消費がエラーの発生していない通常時と異なる。図９、図１０の例では、当該期間のイレギュラーな利用状況は利用実績データとして収集されないので、学習フェーズでイレギュラーな利用状況に基づき学習モデルの学習が行われることを避けることができる。そのため、学習フェーズの学習によりトナーボトルの交換までの残日数を高い精度で予測しうる予測モデルを作成できるので、当該予測モデルを使用する予測フェーズでは消耗品の配送を適切に管理することができる。

次に、複数の画像形成装置１０２が設置されている顧客先でいずれかの画像形成装置１０２にエラーが生じた場合に、他の画像形成装置１０２における処理を説明する。
以下の説明では、エラーが発生していない画像形成装置１０２を第一の画像形成装置１０２ａと称し、エラーの発生した画像形成装置１０２を第二の画像形成装置１０２ｂと称する。第二の画像形成装置１０２ｂは、第一の画像形成装置１０２ａに紐付けて管理される画像形成装置である。

図１１は、第二の画像形成装置１０２ｂにエラーが発生する場合における第一の画像形成装置１０２ａの処理を説明するフローチャートである。

ステップＳ１１０１において、第一の画像形成装置１０２ａの状態管理部４０４は、管理サーバ１０６に対して、第一の画像形成装置１０２ａに対する指示あるいは通知があるか定期的に問い合わせを行う。

ステップＳ１１０２において、第一の画像形成装置１０２ａの状態管理部４０４は、問い合わせのレスポンスとして、第二の画像形成装置１０２ｂでエラーが発生したことを示す通知を管理サーバ１０６から受信する。これにより、第一の画像形成装置１０２ａの算出部４１２は、第二の画像形成装置１０２ｂのエラー発生を検知する。

ステップＳ１１０３において、第一の画像形成装置１０２ａの算出部４１２は、第一の画像形成装置１０２ａが残日数の算出に関する学習フェーズであるかを判定する。学習フェーズである場合には、処理はステップＳ１１０４に進む。一方、学習フェーズではない場合には、図１１の処理は終了する。

ステップＳ１１０４において、第一の画像形成装置１０２ａの算出部４１２は、第二の画像形成装置１０２ｂでエラーが発生したときの第一の画像形成装置１０２ａの利用実績データおよび学習結果が記憶部４０２にあるかを判定する。

以下、第二の画像形成装置１０２ｂでエラーが発生していないときの第一の画像形成装置１０２ａの利用実績データおよび学習結果は、第一の利用実績データおよび第一の学習結果とも称する。また、第二の画像形成装置１０２ｂでエラーが発生したときの第一の画像形成装置１０２ａの利用実績データおよび学習結果は、第二の利用実績データおよび第二の学習結果とも称する。

第二の利用実績データおよび第二の学習結果が記憶部４０２にある場合には、処理はステップＳ１１０５に移行する。一方、第二の利用実績データおよび第二の学習結果が記憶部４０２にない場合には、図１１の処理は終了する。

ステップＳ１１０５において、画像形成装置１０２ａの算出部４１２は、記憶部４０２から第二の利用実績データおよび第二の学習結果を取得する。

ステップＳ１１０６において、画像形成装置１０２ａの算出部４１２は、現時点で記録中の利用実績データと学習結果を、第一の利用実績データおよび第一の学習結果として、記憶部４０２に保存して退避させる。

ステップＳ１１０７において、画像形成装置１０２ａの算出部４１２は、現時点で収集されている利用実績データと学習結果を、第二の利用実績データおよび第二の学習結果（Ｓ１１０５）でそれぞれ更新する。

ステップＳ１１０８において、算出部４１２は、ステップＳ１１０７の更新後に、第二の利用実績データの収集と、第二の学習結果の学習モデルの学習を再開する。その後、図１１の処理は終了する。

ここで、上記のステップＳ１１０４でＮｏの場合（第二の利用実績データおよび第二の学習結果が記憶部４０２にない場合）に、算出部４１２は以下の処理を行ってもよい。
ステップＳ１１０４でＮｏの場合、算出部４１２は、ステップＳ１１０６と同様に、現時点で収集されている利用実績データと学習結果を、第一の利用実績データおよび第一の学習結果として、記憶部４０２に保存して退避させてもよい。

また、算出部４１２は、上記のように利用実績データと学習結果を退避させた後に、必要に応じて利用実績データと学習結果をリセットしてもよい。この場合、第二の画像形成装置１０２ｂで初めてエラーが発生したときに、第一の画像形成装置１０２ａでは、エラー発生前の利用実績が含まれていない利用実績データが収集されるようになる。そして、当該利用実績データに基づいてエラー発生後の学習結果が作成される。

図１２は、第二の画像形成装置１０２ｂのエラーが解消する場合における第一の画像形成装置１０２ａの処理を説明するフローチャートである。

ステップＳ１２０１において、第一の画像形成装置１０２ａの状態管理部４０４は、管理サーバ１０６に対して、第一の画像形成装置１０２ａに対する指示あるいは通知があるか定期的に問い合わせを行う。

ステップＳ１２０２において、第一の画像形成装置１０２ａの状態管理部４０４は、問い合わせのレスポンスとして、第二の画像形成装置１０２ｂでエラーが解消したことを示す通知を管理サーバ１０６から受信する。これにより、第一の画像形成装置１０２ａの算出部４１２は、第二の画像形成装置１０２ｂのエラー解消を検知する。

ステップＳ１２０３において、第一の画像形成装置１０２ａの算出部４１２は、第一の画像形成装置１０２ａが残日数の算出に関する学習フェーズであるかを判定する。学習フェーズである場合には、処理はステップＳ１２０４に進む。一方、学習フェーズではない場合には、図１２の処理は終了する。

ステップＳ１２０４において、画像形成装置１０２ａの算出部４１２は、現時点で記録中の利用実績データと学習結果を、第二の利用実績データおよび第二の学習結果として、記憶部４０２に保存して退避させる。

ステップＳ１２０５において、第一の画像形成装置１０２ａの算出部４１２は第一の利用実績データおよび第一の学習結果が記憶部４０２にあるかを判定する。
第一の利用実績データおよび第一の学習結果が記憶部４０２にある場合には、処理はステップＳ１２０６に移行する。一方、第一の利用実績データおよび第一の学習結果が記憶部４０２にない場合には、図１２の処理は終了する。

ステップＳ１２０６において、画像形成装置１０２ａの算出部４１２は、記憶部４０２から第一の利用実績データおよび第一の学習結果を取得する。

ステップＳ１２０７において、画像形成装置１０２ａの算出部４１２は、現時点で収集されている利用実績データと学習結果を、第一の利用実績データおよび第一の学習結果（Ｓ１２０６）でそれぞれ更新する。

ステップＳ１２０８において、算出部４１２は、ステップＳ１２０７の更新後に、第一の利用実績データの収集と、第一の学習結果の学習モデルの学習を再開する。その後、図１２の処理は終了する。

上記のように、第一の画像形成装置１０２ａは、第二の画像形成装置１０２ｂでエラーが発生またはエラーが解消したときに、残日数の算出に関する学習フェーズであるかを判断する（Ｓ１１０２、Ｓ１１０３、Ｓ１２０２、Ｓ１２０３）。上記のエラーが解消したときに学習フェーズである場合、第一の画像形成装置１０２ａは、エラーの発生中に収集された利用実績データを第二の利用実績データとして退避させる（Ｓ１２０４）。これにより、第一の画像形成装置１０２ａは、エラーが発生していないときの第一の利用実績データとは別に、第二の利用実績データを保存できる。

第二の画像形成装置１０２ｂでエラーが発生すると、残りの第一の画像形成装置１０２ａに印刷が集中し、急激にプリントボリュームが伸びるイレギュラーな利用状況が生じうる。図１１、図１２の例では、第二の画像形成装置１０２ｂでエラーが発生していないときの学習を第一の利用実績データに基づいて行うことができる。同様に、第二の画像形成装置１０２ｂでエラーが発生しているときの学習を第二の利用実績データに基づいて行うことができる。そのため、算出部４１２は、第二の画像形成装置１０２ｂでのエラー発生の有無に応じた複数の予測モデルを取得できる。具体的には、算出部４１２は、第一の利用実績データから学習で作成された第一の予測モデルと、第二の利用実績データから学習で作成された第二の予測モデルを取得できる。そして、予測フェーズでの算出部４１２は、第二の画像形成装置１０２ｂでのエラーの発生に応じてこれらの予測モデルを使い分けることで消耗品の配送を適切に管理することができる。

図１３は、画像形成装置１０２が高消耗アラームを送信するまでの処理を説明するフローチャートである。
詳細には、画像形成装置１０２の算出部４１２が、画像形成装置１０２の過去２４時間のトナーの消費量が既定値を超えたトナーボトルを検知したことを示すイベント情報（高消耗アラーム）を管理サーバ１０６へ送信するまでの処理を示す。

本実施形態において、画像形成装置１０２は、過去２４時間のトナーの消費量が既定値を超えたトナーボトルがあった場合に高消耗アラームを発行して、高消耗アラームを管理サーバ１０６へ送信する。高消耗アラームを受けた管理サーバ１０６は、図１４に示す処理を実行する。また、顧客先においてトナーボトルの在庫を置かない運用がされている場合、高消耗アラームの発行を契機として、管理サーバ１０６から販売会社に対し、トナーボトルの在庫を１つ以上置く在庫運用を顧客に促すことが可能になる。

なお、図１３に示す処理は、画像形成装置１０２の算出部４１２において、一定間隔で行われる。画像形成装置１０２が複数のトナーボトルを利用する場合、図１３に示す処理は、すべてのトナーボトル（全色分）を順次判定対象とするように実行される。

まず、ステップＳ１３０１において、算出部４１２は、高消耗アラームの発行の判定対象となるトナーボトルについて、記憶部４０２で管理する画像形成装置１０２の在庫推奨フラグがＯＮ（１）であるか判断する。

ここで、在庫推奨フラグは、画像形成装置１０２で利用中の各トナーボトルについて、高消耗アラームを発行済かを管理するためのフラグである。在庫推奨フラグがＯＮ（１）の場合、高消耗アラームを発行済であることを意味し、在庫推奨フラグがＯＦＦ（０）の場合、高消耗アラームを発行されていないことを意味する。画像形成装置１０２が複数のトナーボトルを利用する場合、記憶部４０２には各トナーボトルに対応する在庫推奨フラグがそれぞれ設定される。在庫推奨フラグは、高消耗アラームが発行された状態を示す管理情報の一例である。
なお、画像形成装置１０２の算出部４１２は、在庫推奨フラグがＯＮ（１）であるトナーボトルにおいては、高消耗アラームを発行しないように制御している。

ステップＳ１３０１において、在庫推奨フラグがＯＮ（１）の場合、処理はステップＳ１３０８へ進む。在庫推奨フラグがＯＦＦ（０）の場合、処理はステップＳ１３０２へ進む。
ステップＳ１３０２において、算出部４１２は、判定対象となるトナーボトルにおける過去２４時間のトナーの消費量を算出する。なお、本実施形態においては、トナーの消費量を算出するときの単位時間の一例として２４時間を挙げたが、トナーの消費量を算出するときの単位時間は適宜変更することができる。

ステップＳ１３０３において、算出部４１２は、過去２４時間当たりのトナーの消費量が予め設定された閾値以上か判断する。過去２４時間当たりのトナーの消費量が閾値未満の場合には、処理はＳ１３０８へ進む。一方、過去２４時間当たりのトナーの消費量が閾値以上の場合には、処理はＳ１３０４へ進む。

ステップＳ１３０４において、算出部４１２は送信部４０１に通知して高消耗アラームの生成処理へ進む。これにより、送信部４０１が高消耗アラームの送信用データを生成する。このとき、送信部４０１は、アラームコード６０７に、過去２４時間当たりのトナーの消費量が予め設定された閾値以上となったイベントが発生したことを示すアラームコードを設定する。

ステップＳ１３０５において、送信部４０１は、高消耗アラームとして送信するデータのアラームサブコード６０８を決定する。なお、本実施形態では、高消耗アラームにはアラームサブコード６０８を設定しないものとする。

ステップＳ１３０６において、送信部４０１は、生成した高消耗アラームを管理サーバ１０６へ送信する。送信部４０１が送信を完了すると、ステップＳ１３０７へ進む。
ステップＳ１３０７において、算出部４１２は、画像形成装置１０２の記憶部４０２で管理する在庫推奨フラグを初期値であるＯＦＦ（０）からＯＮ（１）に変更する。

ステップＳ１３０８において、算出部４１２は、画像形成装置１０２で利用中である全色分のトナーボトルについて判定が終了したかを判断する。全色分のトナーボトルの判定が終了していないと判断した場合、ステップＳ１３０１へ戻り、判定対象となるトナーボトルを変更して上述した処理を繰り返す。一方、全色分のトナーボトルの判定が終了したと判断した場合、図１３の処理は終了する。

図１４は、管理サーバ１０６側で実行される消耗品の配送遅れを抑止するための処理を説明するフローチャートである。
詳細には、高消耗アラームを受信した管理サーバ１０６が、消耗品の配送遅れを抑止するために疑似アラームを生成するときの処理を示す。
ここで、図１４の説明の前に、管理サーバ１０６が在庫管理の処理で参照する在庫管理テーブルについて説明する。

図１５（Ａ）は、管理サーバ１０６の在庫管理部５１２が、顧客先における消耗品の在庫を管理するための在庫管理テーブルの一例を示す図である。
在庫管理テーブルは、顧客先に消耗品の在庫を置く運用がされているときに、在庫管理対象となる消耗品の顧客先での在庫数を示す情報が格納される。なお、図１５（Ａ）に示す在庫管理テーブルは、在庫管理対象の消耗品が画像形成装置のトナーボトルである場合の例を示している。

在庫管理テーブルは、在庫保管場所、型番、デバイス識別子、初期在庫数、通知を行う在庫数、推定在庫数の各カラムから構成される。
「在庫保管場所」のカラムには、在庫管理対象となる消耗品の顧客先での在庫保管場所を示す情報が格納される。「型番」のカラムには、管理対象となる消耗品の型番を示す情報が格納される。「デバイス識別子」のカラムには、消耗品に対応するデバイス（画像形成装置）を一意に特定する識別情報が格納される。「初期在庫数」のカラムには、消耗品（この場合、トナーボトル）の在庫管理を開始するにあたり、顧客先の在庫保管場所に保管した初期在庫数を示す情報が格納される。「通知を行う在庫数」のカラムには、顧客先の消耗品が安全在庫数以下になり、販売会社に補充を促すための通知を行うときの在庫数を示す情報が格納される。「推定在庫数」のカラムには、現時点での顧客先の在庫保管場所における消耗品の推定在庫数を示す情報が格納される。

推定在庫数は、画像形成装置１０２から顧客が消耗品を交換利用したことを示す通知（トナーボトルの場合、後述する監視アラーム）を管理サーバ１０６が受信する毎に、初期在庫数から減算した結果の値を示す。なお、在庫保管場所、型番、デバイス識別子、初期在庫数、通知を行う在庫数の各情報は、顧客先での消耗品の在庫管理を開始する際に、例えば、管理サーバ１０６の入出力装置３０８を介して設定することが可能となっている。

図１４の説明に戻る。まず、ステップＳ１４０１において、画像形成装置１０２の送信部４０１から高消耗アラームが送信されると、管理サーバ１０６のデバイス情報管理部５０９が通信部５０１を介して高消耗アラームを受信する。

ステップＳ１４０２において、デバイス情報管理部５０９は、今回受信した高消耗アラームに対応するトナーボトルを特定し、特定されたトナーボトルが在庫管理対象であるか判断する。
在庫管理対象の判断において、在庫管理部５１２が管理する在庫管理テーブル（図１５（Ａ））を参照し、特定されたトナーボトルに対応する情報が在庫管理テーブルに存在すれば、在庫管理対象であると判断する。在庫管理対象であると判断した場合、図１４の処理は終了する。

一方、特定されたトナーボトルに対応する情報が在庫管理テーブルに存在しなければ、在庫管理対象ではないと判断し、処理はステップＳ１４０３へ進む。
ステップＳ１４０３において、デバイス情報管理部５０９は、特定されたトナーボトルの監視アラームを画像形成装置１０２から受信済か否かを判断する。換言すると、デバイス情報管理部５０９は、顧客先に交換用のトナーボトルを配送済であるかを判断する。

ここで、監視アラームについて説明する。監視アラームは、管理サーバ１０６がトナーボトルの配送のトリガーとなるアラームである。
管理サーバ１０６の運用において、監視アラームは、個々の画像形成装置１０２に対して予め用意されたアラームの中からユーザが選択することができる。管理サーバ１０６の運用においてユーザが選択できる監視アラームとしては、事前配送アラームの他に、トナーボトル交換完了アラーム、トナーローアラームがある。トナーボトル交換完了アラームは、新しいトナーボトルが装填されたことを検知して画像形成装置１０２が発行するアラームであり、主に、顧客先に在庫を１つ以上置く運用（在庫運用）の場合において利用される。トナーローアラームは、画像形成装置１０２内の特定のボトルのトナー残量が一定閾値以下となったことを示すステータス情報の受信を検知して、管理サーバ１０６が擬似的に発行する疑似アラームの一つである。トナーローアラームは、主に、事前配送アラームやトナーボトル交換完了アラームに対応していない画像形成装置１０２において利用される。

また、管理サーバ１０６における上記の監視アラームの受信は、デバイス情報管理部５０９に格納される監視アラーム受信管理テーブルによって管理される。
図１５（Ｂ）は、監視アラーム受信管理テーブルの一例を示す図である。なお、図１５（Ｂ）に示す監視アラーム受信管理テーブルは、消耗品が画像形成装置のトナーボトルである場合の例を示している。

監視アラーム受信管理テーブルは、デバイス識別子、フラグ更新日時、トナーボトル種別、監視アラーム受信済フラグ、残日数の各カラムから構成される。
「デバイス識別子」のカラムには、高消耗アラームを送信したデバイス（画像形成装置）を一意に特定する識別情報が格納される。「フラグ更新日時」のカラムには、監視アラーム受信済フラグを更新した日時を示す情報が格納される。「トナーボトル種別」のカラムには、監視アラームに対応するトナーボトルの種別（Ｃ、Ｍ、Ｙ、Ｂｋなどの色）を示す情報が格納される。

「監視アラーム受信済フラグ」のカラムには、対応するトナーボトルについて、事前配送アラームを受信したときまたはトナーローアラームが発行されたときにＯＮ（１）の情報が格納される。また、「監視アラーム受信済フラグ」のカラムには、初期状態またはトナーボトル交換完了アラームを受信してリセットされたときにＯＦＦ（０）の情報が格納される。「残日数」のカラムには、事前配送アラームを受信したときに、トナー残量情報に含まれる残日数の情報が格納される。

図１４に示すステップＳ１４０３の説明に戻る。監視アラームを受信済か否かは、図１５（Ａ）の監視アラーム受信管理テーブルにおいて、特定されたトナーボトル種別に対応する監視アラーム受信済フラグがＯＮ（１）か否かで判断する。監視アラームを受信済と判断した場合（すなわち、顧客先に対して交換用のトナーボトルを配送済の場合）、図１４の処理は終了する。

一方、監視アラームを受信済ではないと判断した場合、処理はステップＳ１４０４へ進む。ステップＳ１４０４において、デバイス情報管理部５０９はアラーム生成部５１３に通知して監視アラームを疑似的に生成する処理に進み、交換用のトナーボトルを配送指示する。

これにより、アラーム生成部５１３が、上記のトナーローアラーム（疑似アラーム）を生成することで、通常、画像形成装置１０２より受信する監視アラームを管理サーバ１０６で擬似的に生成する。この疑似アラームの発行は、管理サーバ１０６において監視アラームの受信の一態様として扱われる。また、アラーム生成部５１３は、配送システム１０９に対してトナーボトルの配送を依頼するメッセージを送信する。

ステップＳ１４０５において、擬似アラーム発行済フラグがＯＦＦ（０）からＯＮ（１）に変更される。以上で、図１４に示す処理が終了する。

本実施形態では、画像形成装置１０２から高消耗アラームを受信すると、管理サーバ１０６は、必要に応じて交換用ボトルが未配送のトナーボトルの監視アラームを擬似的に生成する（Ｓ１４０４）。このように、管理サーバ１０６側で交換用ボトルの配送指示を行うことで、交換用ボトルの配送の遅れが抑止される。

ここで、管理サーバ１０６における上記の疑似アラームの発行は、デバイス情報管理部５０９に格納される高消耗アラーム受信管理テーブルによって管理される。
図１５（Ｃ）は、高消耗アラーム受信管理テーブルの一例を示す図である。なお、図１５（Ｃ）に示す高消耗アラーム受信管理テーブルは、消耗品が画像形成装置のトナーボトルである場合の例を示している。

高消耗アラーム受信管理テーブルは、デバイス識別子、フラグ更新日時、トナーボトル種別、高消耗アラーム受信済フラグ、疑似アラーム発行済フラグ、カウンタ、高消耗フラグリセット閾値の各カラムから構成される。
「デバイス識別子」のカラムには、高消耗アラームを送信したデバイス（画像形成装置）を一意に特定する識別情報が格納される。「フラグ更新日時」のカラムには、高消耗アラーム受信済フラグを更新した日時を示す情報が格納される。「トナーボトル種別」のカラムには、高消耗アラームに対応するトナーボトルの種別（Ｃ、Ｍ、Ｙ、Ｂｋなどの色）を示す情報が格納される。

「高消耗アラーム受信済フラグ」のカラムには、対応するトナーボトルについて、高消耗アラームを受信したときにＯＮ（１）の情報が格納される。また、「高消耗アラーム受信済フラグ」のカラムには、初期状態または当該フラグをリセットする指示を受けたときにＯＦＦ（０）の情報が格納される。「疑似アラーム発行済フラグ」のカラムには、対応するトナーボトルについて、疑似アラームが発行されたときにＯＮ（１）の情報が格納される。また、「疑似アラーム発行済フラグ」のカラムには、初期状態または当該フラグをリセットする指示を受けたときにＯＦＦ（０）の情報が格納される。

「カウンタ」のカラムには、事前配送アラームの生成閾値として用いられる残日数が、実績日数に収まっていると判断した回数をカウントした値が格納される。「高消耗フラグリセット閾値」のカラムには、高消耗フラグをリセットするときのカウンタの閾値が格納される。カウンタおよび高消耗フラグリセット閾値は、トナーボトルの種別ごとにそれぞれ設定されている。

図１６は、管理サーバ１０６側で実行される在庫推奨フラグのリセット処理を説明するフローチャートである。

ステップＳ１６０１において、管理サーバ１０６のイベント受信部５１１は、第二の画像形成装置１０２ｂでエラーが解消したことを示す通知を第二の画像形成装置１０２ｂから受信する。これにより、イベント受信部５１１は、第二の画像形成装置１０２ｂのエラー解消を検知する。

ステップＳ１６０２において、イベント受信部５１１は、第二の画像形成装置１０２ｂと同一顧客先に設置されている第一の画像形成装置１０２ａの高消耗アラームの受信状態を確認する。そして、イベント受信部５１１は、第二の画像形成装置１０２ｂでエラーが発生していた期間（第二の画像形成装置１０２ｂが利用できない期間）に、第一の画像形成装置１０２ａから高消耗アラームを受信した履歴があるかを判断する。

イベント受信部５１１は、例えば、高消耗アラーム受信管理テーブル（図１５（Ｃ））で第一の画像形成装置１０２ａに紐付けされた情報を抽出する。そして、イベント受信部５１１は、抽出された情報の高消耗アラーム受信済フラグがＯＮ（１）であれば、第一の画像形成装置１０２ａから高消耗アラームを受信済であると判断する。なお、イベント受信部５１１は、トナーボトルの種別ごとに上記の判断を行う。
高消耗アラームを受信した履歴がある場合、処理はステップＳ１６０３へ進む。一方、高消耗アラームを受信した履歴がない場合、図１６の処理は終了する。

ステップＳ１６０３において、イベント受信部５１１は、高消耗アラームを受信したトナーボトルが在庫管理対象であるかを判断する。イベント受信部５１１は、例えば、在庫管理部５１２の管理する在庫管理テーブル（図１５（Ａ））において、第一の画像形成装置１０２ａに紐付けされたトナーボトルの情報が存在すれば、トナーボトルが在庫管理対象であると判断する。
高消耗アラームを受信したトナーボトルが在庫管理対象である場合、処理はステップＳ１６０４に進む。一方、高消耗アラームを受信したトナーボトルが在庫管理対象でない場合、処理はステップＳ１６０６に進む。

ステップＳ１６０４において、イベント受信部５１１は、当該トナーボトルが在庫管理対象に設定された時期が第二の画像形成装置１０２ｂでエラーが発生していた期間であるかを判定する。
在庫管理対象に設定された時期が第二の画像形成装置１０２ｂでエラーが発生していた期間である場合、処理はステップＳ１６０５に進む。一方、在庫管理対象に設定された時期が第二の画像形成装置１０２ｂでエラーが発生していた期間ではない場合、図１６の処理は終了する。

ステップＳ１６０５において、イベント受信部５１１は、販売会社に対して、在庫管理の設定の確認を促すメール通知を行う。当該メール通知は、通知管理部５０７および通信部５０１を介して配送システム１０９に送信される。その後、図１６の処理は終了する。このメール通知を契機として、販売会社の担当者は、当該トナーボトルを在庫運用から在庫レス運用（すなわち、顧客先にトナーボトルの在庫を置かない運用）に切り替えることが可能となる。

ステップＳ１６０６において、通信部５０１は、第一の画像形成装置１０２ａに対して、上述したステップＳ１３０７でＯＮ（１）にした在庫推奨フラグをＯＦＦ（０）へ変更するためのリセット指示を送信する。これにより、第一の画像形成装置１０２ａは図１３に示す処理において、高消耗アラームを発行済の状態から解除されるので、高消耗アラームを再び生成することが可能になる。
ステップＳ１６０７において、イベント受信部５１１は、高消耗アラーム受信管理テーブル（図１５（Ｃ））で管理する高消耗アラーム受信済フラグをＯＮ（１）からＯＦＦ（０）に変更する。その後、図１６の処理は終了する。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

１０２ 画像形成装置
１０２ａ 第一の画像形成装置
１０２ｂ 第二の画像形成装置
１０６ 管理サーバ
４０２ 記憶部
４１２ 算出部

Claims (11)

1. 第一のジョブ処理装置と、前記第一のジョブ処理装置で利用される消耗品の配送を管理するサーバ装置とを備える管理システムであって、
   前記第一のジョブ処理装置は、
   前記消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる前記第一のジョブ処理装置の利用実績データを記録する記録手段と、
   前記学習で作成された前記予測モデルを用いて、前記第一のジョブ処理装置で実行された処理を入力として前記第一のジョブ処理装置に装着される前記消耗品の交換までの残日数を予測する予測手段と、を有し、
   前記記録手段は、
   前記第一のジョブ処理装置と紐付けて管理される第二のジョブ処理装置にエラーが発生したときに前記第一のジョブ処理装置が学習中であるかを判断し、
   前記第二のジョブ処理装置の前記エラーが解消したときに前記第一のジョブ処理装置が学習中であれば、前記エラーの発生中に前記第一のジョブ処理装置で記録された前記利用実績データを、第二の利用実績データとして退避させ、
   前記予測手段は、
   前記第二のジョブ処理装置で前記エラーが発生していない間に前記第一のジョブ処理装置で記録された第一の利用実績データから前記学習で作成された前記予測モデルを用いて、前記残日数を予測する
   ことを特徴とする管理システム。
2. 前記第一のジョブ処理装置は、
   単位時間当たりの前記消耗品の消費量が既定値を超えているときに前記サーバ装置に高消耗アラームを送信する送信手段と、
   前記高消耗アラームが発行された状態を示す管理情報を記憶する管理手段と、をさらに有し、
   前記サーバ装置は、
   前記高消耗アラームを受信したときに、前記消耗品の配送を指示する監視アラームが受信済でなければ、前記第一のジョブ処理装置の指示を受けずに前記消耗品の配送を指示するための疑似アラームを生成する
   ことを特徴とする請求項１に記載の管理システム。
3. 前記サーバ装置は、
   前記第二のジョブ処理装置の前記エラーが解消されたときに、前記エラーの発生中に前記第一のジョブ処理装置から前記高消耗アラームを受信していれば、前記第一のジョブ処理装置に対して前記高消耗アラームが発行された状態を解除する指示を送信する
   ことを特徴とする請求項２に記載の管理システム。
4. 前記予測手段は、
   前記第一の利用実績データから前記学習で作成された第一の予測モデルと、前記第二の利用実績データから前記学習で作成された第二の予測モデルをそれぞれ取得する
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の管理システム。
5. 前記記録手段は、
   前記第二のジョブ処理装置にエラーが発生したときに前記第一のジョブ処理装置が学習中であれば、記録中の前記利用実績データを前記第一の利用実績データとして退避させる
   ことを特徴とする請求項１から請求項４のいずれか一項に記載の管理システム。
6. 前記記録手段は、
   前記第二のジョブ処理装置にエラーが発生したときに前記第一のジョブ処理装置が学習中であり、かつ退避した前記第二の利用実績データがあるときには、前記利用実績データを退避した前記第二の利用実績データで更新して前記利用実績データの記録を再開させる
   ことを特徴とする請求項１から請求項５のいずれか一項に記載の管理システム。
7. 前記記録手段は、
   前記第二のジョブ処理装置の前記エラーが解消したときに前記第一のジョブ処理装置が学習中であり、かつ退避した前記第一の利用実績データがあるときには、前記利用実績データを退避した前記第一の利用実績データで更新して前記利用実績データの記録を再開させる
   ことを特徴とする請求項５に記載の管理システム。
8. 前記第一のジョブ処理装置は、
   前記利用実績データを用いた学習により前記予測モデルを生成する学習手段をさらに有する
   ことを特徴とする請求項１から請求項７のいずれか一項に記載の管理システム。
9. 第一のジョブ処理装置と、前記第一のジョブ処理装置で利用される消耗品の配送を管理するサーバ装置とを備える管理システムにおける方法であって、
   前記第一のジョブ処理装置において、前記消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる前記第一のジョブ処理装置の利用実績データを記録する記録工程と、
   前記第一のジョブ処理装置において、前記学習で作成された前記予測モデルを用いて、前記第一のジョブ処理装置で実行された処理を入力として前記第一のジョブ処理装置に装着される前記消耗品の交換までの残日数を予測する予測工程と、を有し、
   前記記録工程では、
   前記第一のジョブ処理装置と紐付けて管理される第二のジョブ処理装置にエラーが発生したときに前記第一のジョブ処理装置が学習中であるかを判断し、
   前記第二のジョブ処理装置の前記エラーが解消したときに前記第一のジョブ処理装置が学習中であれば、前記エラーの発生中に前記第一のジョブ処理装置で記録された前記利用実績データを、第二の利用実績データとして退避させ、
   前記予測工程では、
   前記第二のジョブ処理装置で前記エラーが発生していない間に前記第一のジョブ処理装置で記録された第一の利用実績データから前記学習で作成された前記予測モデルを用いて、前記残日数を予測する
   ことを特徴とする方法。
10. 自装置に装着される消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる前記自装置の利用実績データを記録する記録手段と、
    前記学習で作成された前記予測モデルを用いて、前記自装置で実行された処理を入力として前記消耗品の交換までの残日数を予測する予測手段と、を有し、
    前記記録手段は、
    前記自装置にエラーが発生したときに前記学習中であれば、記録中の前記利用実績データを退避させ、
    前記自装置のエラーが解消したときに前記学習中であれば、前記利用実績データを退避した利用実績データで更新し、前記利用実績データの記録を再開させる
    ことを特徴とするジョブ処理装置。
11. ジョブ処理装置における方法であって、
    自装置に装着される消耗品の交換までの残日数を予測する予測モデルを作成するための学習中に、当該学習に用いられる前記自装置の利用実績データを記録する記録工程と、
    前記学習で作成された前記予測モデルを用いて、前記自装置で実行された処理を入力として前記消耗品の交換までの残日数を予測する予測工程と、を有し、
    前記記録工程では、
    前記自装置にエラーが発生したときに前記学習中であれば、記録中の前記利用実績データを退避させ、
    前記自装置のエラーが解消したときに前記学習中であれば、前記利用実績データを退避した利用実績データで更新し、前記利用実績データの記録を再開させる
    ことを特徴とする方法。
    
    

Images