JP6056355B2 - 機器、遠隔管理システム及びプログラム - Google Patents

Description

本発明は、部品の配送要求を行う機器、遠隔管理システム及びプログラムに関する。

機器を遠隔で管理する遠隔管理システムでは、サプライニアエンドやエンドや交換時にサプライコールを機器から管理装置に送信する。管理装置は、コール内容（ニアエンド／エンド）に基づき、オペレータに通知する、もしくはサプライ配送システムに送信する。サプライ配送システムは、通知を受けたサプライをお客様に配送する。機器としては、複合機、インクジェットプリンタ、プロジェクタ、デジカメなどがある。

例えば、特許文献１には、画像形成装置などの通信装置が、送信要因となる事象の送信中に主電源が遮断されても、その送信を主電源再投入時に再開する技術が記載されている。また、特許文献２には、外部の中央制御装置が、画像形成装置から通報された消耗品情報に含まれる消耗品の全消費量を基に通信異常を検知する技術が記載されている。

しかし、従来技術では、サプライニアエンドやエンドや交換時に、サプライごとに対してサプライコールを管理装置に送信し、サプライごとに配送されることにより、配送コストが掛かるという問題点があった。

以下、より具体的に説明する。例えば、現状では、トナーのサプライ運用において、機器出荷時に予備用トナーもお客様に届けられる。トナーがエンドになったときに、お客様が予備用トナーを、エンドとなったトナーと交換する。

一方で、トナーがニアエンド、もしくはエンド、もしくは交換時にトナーサプライコールが管理装置に送信され、新トナーが数日以内にお客様に届けられる。予備用トナーが交換された場合に、トナーサプライコールにより配送された新トナーを予備用とする。これにより、機器のトナーエンド時の交換用トナーがないことによる機器のダウンタイムをなくすことができる。

また、トナーのサプライ運用において、機器出荷時に予備用トナーを用意しない場合もある。予備用トナーを用意しない場合、トナーの残量がエンドとなる日数以内に、トナーが確実にお客様に届けられることを考慮したタイミングで、トナーサプライコールを管理装置に送信する。サプライコールが通知されると、トナーがお客様に配送される。これにより、予備用トナーを設ける場合と同様に、機器のトナーエンド時の交換用トナーがないことによる機器のダウンタイムをなくすことができる。

しかしながら、上記のようなトナーのサプライ運用において、トナーの色ごとにサプライコールが管理装置に送信された場合、色ごとにトナーが配送され、配送コストが高くなっていた。

そこで、本発明は、消耗される部品に対して配送タイミングが近い部品をまとめて配送することで、配送コストを抑えることができる機器、通報制御方法及びプログラムを提供することを目的とする。

本発明の一態様における機器は、複数の消耗される部品を有する機器であって、前記機器の消耗される各部品に対し、通報タイミング、通報可能範囲、及び通報済みフラグを対応付けた情報を記憶する記憶部と、前記各部品の残量が、前記各部品に対応する通報タイミングに該当するか否かを判定する第１判定部と、前記通報タイミングに該当する第１部品があると判定された場合、前記複数の消耗される部品のうち、前記第１部品以外の部品の残量が、前記通報タイミングと前記通報可能範囲とに基づく所定範囲内にあるか否かを判定する第２判定部と、前記所定範囲内にあると判定された第２部品及び前記第１部品のうち、各部品に対応する前記通報済みフラグが未通報を示す部品に対する配送要求を、前記部品を管理する管理装置に通報する通報部とを備える。

本発明によれば、消耗される部品に対して配送タイミングが近い部品をまとめて配送することで、配送コストを抑えることができる。

実施例１における遠隔管理システムの構成の一例を示す図。 実施例１における管理装置の構成の一例を示すブロック図。 実施例１における画像処理装置の構成の一例を示すブロック図。 実施例１における画像処理装置のソフトウェア構成の一例を示すブロック図。 実施例１における画像処理装置の機能構成の一例を示すブロック図。 実施例１における部品通報情報の一例を示す図。 実施例１における画像処理装置の通報制御処理の一例を示すシーケンス図。 実施例１における通報判定処理の一例を示すフローチャート。 実施例１における設定処理（その１）の一例を示すシーケンス図。 実施例１における設定処理（その２）の一例を示すシーケンス図。 実施例１における設定処理（その３）の一例を示すシーケンス図。 実施例２における部品通報情報の一例を示す図。 実施例２における画像処理装置の通報制御処理の一例を示すシーケンス図。 実施例２における通報判定処理の一例を示すフローチャート。

以下、本発明の各実施例を図面に基づいて説明する。
［実施例１］
＜遠隔管理システム＞
まず、本発明の実施例１で前提となる遠隔管理システムの概要について説明する。図１は、実施例１における遠隔管理システム１の構成の一例を示す図である。図１に示す遠隔管理システム１は、例えば、管理している機器の部品に対する配送要求を受けると、この部品の配送を手配する。

遠隔管理システム１は、プリンタ、ＦＡＸ装置、デジタル複写機、スキャナ装置、デジタル複合機等の画像処理装置や、ネットワーク家電、自動販売機、医療機器、電源装置、空調システム等に通信機能を持たせた機器を被管理装置１０（１０ａ、１０ｂ、１０ｃ）とする遠隔管理システムである。図１に示す例では、被管理装置１０は、画像処理装置１０として説明し、機器１０とも呼ぶ。

図１に示す例では、機器１０は、通信網２０を介して管理装置３０と接続される。管理装置３０は、複数の機器１０（１０ａ、１０ｂ、１０ｃ）を遠隔管理できる。

図１に示す遠隔管理システム１では、遠隔管理を実現するため、各装置にＲＰＣ（Remote Procedure Call）により、相互実装するアプリケーションのメソッドに対する処理の要求、応答を送受信できるようにしている。

また、このＲＰＣを実現するために、遠隔管理システム１は、ＰＰＰ（Point-to-Point Protocol）、ＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)、ＳＯＡＰ（Simple Object Access Protocol）、ＨＴＴＰ（Hyper Text Transfer Protocol）などのプロトコルを利用して通信を行うことによって、実現されている。

なお、遠隔管理システム１のセキュリティ面を考慮し、ファイアウォール４０が設置される。このファイアウォール４０は、プロキシサーバによって構成される。

なお、遠隔管理システム１には、機器１０とＬＡＮ（Local Area Network）などで接続される装置として、遠隔管理仲介装置としての機能を有する仲介装置を設けてもよい。

＜管理装置＞
次に、管理装置３０の構成について説明する。図２は、実施例１における管理装置３０の構成の一例を示すブロック図である。

図２に示す管理装置３０は、制御部１１１、データベース１１２、操作部１１６、及びプロキシ（Ｐｒｏｘｙ）サーバ１１７等を有する。各部は、データバス１１５を介して、データ送受信可能なように接続されている。

制御部１１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等からなるマイクロコンピュータを備えており、管理装置３０全体を統括的に制御する。また、制御部１１１は、情報の受信機能を有する。

データベース１１２は、ハードディスク装置等の記憶装置に存在し、各機器から受信したデータなどを記憶する。また、データベース１１２は、機器１０を管理するのに用いる各種パラメータ、管理プログラム、オペレータが入力するデータを記憶するパラメータ記憶エリア１１３と、機器１０の情報を記憶する情報記憶エリア１１４とを含む。

操作部１１６は、各種データの入力をオペレータによるキーボードやポインティングデバイス（マウス等）等の入力部上の操作により受け付ける。

プロキシサーバ１１７は、インターネットを介して各機器との通信およびセキュリティ管理を行う。

制御部１１１のＣＰＵが、プログラムに従って動作すると共に、例えばプロキシサーバ１１７を必要に応じて使用することにより、各種機能を実現することができる。

＜機器＞
次に機器１０の一種である画像処理装置について説明する。図３は、実施例１における画像処理装置１０の構成の一例を示すブロック図である。

図３に示す画像処理装置１０は、コントローラボード２１０、操作パネル２１４、ＦＣＵ（Fax Control Unit）２２１、ＵＳＢ（Universal Serial Bus）インターフェース２２２、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Enginners 1394）インターフェース２２３、プロッタ／スキャンエンジン２２４、周辺機２２５などを有する。

コントローラボード２１０は、ＳＤＲＡＭ（Synchronous Dynamic RAM）２１１、ＮＶＲＡＭ（Non Volatile RAM）２１２、ＨＤＤ（Hard Disc Drive）２１３、ＣＰＵ２１５、ＡＳＩＣ（Application Specific Integrated Circuit）２１６、遠隔管理視システム用メモリ２１７、及びＮＩＣ（Network Interface Card）２１８を有する。

ＣＰＵ２１５は、各種プログラムを実行することで、データ演算を行う。また、ＣＰＵ２１５は、各部を制御する。

ＡＳＩＣ２１６は、画像処理用の集積回路であり、ＣＰＵ２１５の制御対象となるデバイスの共有化を図り、アーキテクチャの面からアプリケーションなどの開発の効率化を支援する。

ＳＤＲＡＭ２１１は、各種プログラムを記憶するメモリ、またＣＰＵ２１５がデータ処理時に使用するメモリである。

ＮＶＲＡＭ２１２は、ブートプログラムやＯＳイメージを記憶するメモリであり、また、各種不揮発性を求めるデータ（機種機番、ＩＰアドレスなど）を記憶するメモリである。

ＨＤＤ２１３は、不揮発性記憶媒体であり、更新用ファームウェア、実行用ファームウェアを記憶することができる。

ＮＩＣ２１８は、ローカルネットワーク、また更にインターネットを介して、管理装置３０のプロキシサーバ１１７と接続するインターフェースである。

操作パネル２１４は、画像処理装置１０に対して操作を行うオペレータのためのインターフェースであり、データ入力、ジョブ実行、表示することができる。

ＦＣＵ２２１は、ＦＡＸ装置またはモデム機能を有する画像処理装置などの外部装置との通信を公衆回線で制御する。

ＵＳＢインターフェース２２２、ＩＥＥＥ２３９４インターフェース２２３は、それぞれの規格に準じたインターフェースである。プロッタ／スキャナエンジン２２４は、プロッタやスキャンなどのエンジンである。

（ソフトウェア）
次に、画像処理装置１０のソフトウェア構成について説明する。図４は、画像処理装置１０のソフトウェア構成の一例を示すブロック図である。

画像処理装置１０のソフトウェア構成は、アプリケーションモジュール層、サービスモジュール層、汎用ＯＳ層を有する。

これらのプログラムは、ＣＰＵ２１５がＡＳＩＣ２１６を経由でＮＶＲＡＭ２１２内のブートプログラムを起動させ、さらにＯＳイメージを読み出し、ＳＤＲＡＭ２１１をロードしてＯＳに展開し、ＯＳを起動させる。

ＣＰＵ２１５は、必要に応じて、ＮＶＲＡＭ２１２内の各アプリケーションやサービスなどのプログラムを読み出し、ＳＤＲＡＭ２１１にロードして展開し、起動させることにより、後述する各機能を実現することができる。

アプリケーションモジュール層のソフトウェアは、コントローラボード２１０上のＣＰＵ２１５を、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段として機能させるためのプログラムによって構成される。

サービスモジュール層のソフトウェアは、ＣＰＵ２１５を、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求を受け付ける。また、サービスモジュール層のソフトウェアは、その動作要求の調停、およびその動作要求に基づく動作の実行制御を行うサービス制御手段として機能させるためのプログラムによって構成される。

また、画像処理装置１０は、プロッタ／スキャナエンジン２２４内にセンサ等からなるトナーの残量を検出する検出部を備えている。

サービスモジュール層には、オペレーションコントロールサービス（ＯＣＳ）３００、エンジンコントロールサービス（ＥＣＳ）３０１、メモリコントロールサービス（ＭＣＳ）３０２、ネットワークコントロールサービス（ＮＣＳ）３０３、ファックススコントロールサービス（ＦＣＳ）３０４、システムコントロールサービス（ＳＣＳ）３０６、システムリソースマネージャ（ＳＲＭ）３０７、イメージメモリハンドラ（ＩＭＨ）３０８、デリバリーコントロールサービス（ＤＣＳ）３１６、ユーザコントロールサービス（ＵＣＳ）３１７を実装している。

また、アプリケーションモジュール層には、ＮＲＳアプリ（以下単に「ＮＲＳ」という）３０５、ＣＳＳアプリ（以下単に「ＣＳＳ」という）３１５、コピーアプリ３０９、ファックスアプリ３１０、プリンタアプリ３１１、スキャナアプリ３１２、ネットファイルアプリ３１３、ブラウザアプリ３１４を実装している。更に、汎用ＯＳ層には、汎用ＯＳ３１８を実装している。

ＯＣＳ３００は、操作パネルを制御するモジュールである。ＥＣＳ３０１は、エンジンユニットを制御するモジュールである。ＭＣＳ３０２は、メモリ制御をするモジュールである。

ＮＣＳ３０３は、ネットワークとアプリケーションモジュール層の各アプリケーションと仲介処理を行わせるモジュールである。ＦＣＳ３０４は、ファクシミリ機能を実現するモジュールである。

ＳＣＳ３０６は、コマンド内容に応じたアプリケーションモジュール層の各アプリケーションの起動管理および終了管理を行うモジュールであり、プロッタエンジン、各ｘＣＳ（ｘは、図４に示す各部の任意の先頭アルファベット）とアプリ間の責務調停するモジュールでもある。

ＳＲＭ３０７は、システムの制御およびリソースの管理を行うモジュールである。ＩＭＨ３０８は、一時的に画像データを入れておくメモリを管理するモジュールである。ＤＣＳ３１６はＨＤＤ２１３やコントローラボード２１０上のメモリに記憶している画像ファイルをＳＭＴＰやＦＴＰを用いて送受信するモジュールである。

ＵＣＳ３１７は、機器利用者が登録した宛先情報や宛先情報等のユーザ情報を管理するモジュールである。

ＮＲＳ３０５は、ネットワークを介してデータを送受信する際のデータの変換を行うなど、ネットワークを介した遠隔管理に関する機能およびスケジューラ機能を有するアプリケーションである。ＮＲＳ３０５は、画像処理装置１０の状態情報、カウンタ情報、ファームウェアバージョン情報を管理装置３０に通報する機能、ファームウェア更新、コマンドの実行等の要求をメソッド単位で送信する機能を有する。また、ＮＲＳ３０５は、定期或いは即時的に或いは不定期的に管理装置３０に異常通報、サプライ通報、起動通報する機能を有する。

ＣＳＳ３１５は、遠隔管理に関する機能（管理装置３０との通信に係わる機能）をまとめたモジュールである。

コピーアプリ３０９、ファックスアプリ３１０、プリンタアプリ３１１、スキャナアプリ３１２、ネットファイルアプリ３１３、及びブラウザアプリ３１４はそれぞれ機能のサービスを実現するためのアプリケーションである。

汎用ＯＳ３１８は、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などのオペレーティングシステムである。オペレーティングシステムは、サービスモジュール層やアプリケーションモジュール層のプログラムなどを実行させる処理を司る。ここで、ＵＮＩＸ（登録商標）やＬｉｎｕｘ（登録商標）を用いれば、オープンソースゆえの安全性が担保され、ソースコード入手の容易性などの利点がある。

（機能）
次に、画像処理装置１０の機能構成について説明する。図５は、実施例１における画像処理装置１０の機能構成の一例を示すブロック図である。

図５に示す画像処理装置１０は、記憶部４０１と、検知部４０２と、第１判定部４０３と、第２判定部４０４と、通報判定部４０５と、通報部４０６とを有する。

記憶部４０１は、例えばＮＶＲＡＭ２１２により実現され、検知部４０２は、例えばプロッタ／スキャナエンジン２２４により実現され、第１判定部４０３と、第２判定部４０４と、通報判定部４０５と、通報部４０６とは、例えばＮＲＳ３０５により実現されうる。

記憶部４０１は、消耗される各部品に対し、通報タイミング、通報可能範囲、及び通報済みフラグを対応付けた情報（部品通報情報）を記憶する。消耗される部品とは、例えばトナーである。通報タイミングとは、部品の配送要求を管理装置３０に通報するタイミングである。通報可能範囲とは、通報タイミングではないが、通報してもよい残量を設定した範囲である。通報済みフラグとは、配送要求を行ったか否かを示すフラグである。残量は、例えばトナーの場合はトナー残量、経年劣化する部品の場合は劣化するまでの残りの時間などを表す。

また、記憶部４０１は、通報タイミングで閾値を用いる場合は、部品毎の閾値を部品通報情報に記憶する。なお、部品毎の閾値は、通報タイミングに含めて記憶するようにしてもよい。

図６は、実施例１における部品通報情報の一例を示す図である。図６に示す例では、部品はトナーであり、通報タイミングは閾値を用いる。図６に示す部品通報情報では、トナー毎に、通報タイミング、通報閾値、通報可能範囲、通報済みフラグが関連付けられて保持される。この部品通報情報は、例えばＮＶＲＡＭ２１２に記憶される。

例えば、Ｋ（ブラック）のトナーには、通報タイミング「閾値以下」、通報閾値「１０％」、通報可能範囲「５％」、通報済みフラグ「未通報」が対応付けられている。

また、部品通報情報の各値は、機器出荷時に初期値（例：通報タイミング：「閾値以下」、通報閾値（％）：「１０％」、通報可能範囲（％）：「１０％」、通報済みフラグ：「未通報」）が設定されている。

この初期値は、ファームの量産へのリリース時に組み込まれており、量産時にファームを機器１０にセットアップすることにより、機器に反映される。出荷後に、通報タイミング、通報閾値（％）、通報可能範囲（％）の値に対して、ユーザもしくはＣＥ（Customer Engineer）などが機器１０の入力インターフェースにおいて再設定することができる。もしくは、機器１０が管理装置３０から変更要求に応じて再設定することもできる。

また、通報閾値（%）および通報可能範囲（%）の値は「日数」（期間）単位とも換算できる。これは、サプライ残量からエンドまで使用できる枚数と、期間内の平均使用枚数から算出可能であるからである。

機器１０の入力インターフェース（ユーザもしくはＣＥが入力）について、機器１０のｗｅｂ画面、もしくはパネル画面、もしくは投影画面を見て、機器１０（ＭＦＰ／ＬＰ／ＰＪ／デジカメなど）本体の操作キーより入力することなどが挙げられる。

また、管理装置３０からの変更要求は、管理装置３０を操作するオペレータや、管理装置３０側の一括設定ツールなどによって、機器１０に送信できる要求である。

図５に戻り、検知部４０２は、画像処理装置１０の部品の残量を検知する。例えば、部品としてトナーを例にする場合、検知部４０２は、各トナーのトナー残量を検知する。検知部４０２は、検知した残量を第１判定部４０３及び／又は第２判定部４０４に通知する。

第１判定部４０３は、各部品の残量が、部品関連情報から取得した各部品に対応する通報タイミングに該当するか否かを判定する。例えば、第１判定部４０３は、検知部４０２からＫのトナー残量を取得した場合、部品通報情報からＫの通報タイミングと通報閾値とを取得し、Ｋのトナーザ量が通報閾値以下となっているか否かを判定する。

第１判定部４０３は、通報タイミングに該当すると判定した部品がある場合、その旨を第２判定部４０４及び通報判定部４０５に通知する。通報タイミングに該当する部品を第１部品とも称す。第１部品は１又は複数の部品を含む。

第２判定部４０４は、通報タイミングに該当する第１部品があると判定された場合、この第１部品以外の部品の残量が、通報タイミングと通報可能範囲とに基づく所定範囲内にあるか否かを判定する。通報可能範囲は、部品通報情報から取得される。所定範囲は、例えば、通報タイミングの閾値に通報可能範囲を加算した範囲を所定範囲とする。

第２判定部４０４は、所定範囲内にあると判定した部品がある場合、その旨を通報判定部４０５に通知する。所定範囲内にあると判定された部品を第２部品とも称す。第２部品は、１又は複数の部品を含む。

通報判定部４０５は、第２部品及び第１部品のうち、部品通報情報から取得した各部品に対応する通報済みフラグが未通報を示すか否かを判定する。通報判定部４０５は、通報済みフラグが未通報を示す部品を通報部４０６に通知する。

通報部４０６は、第２部品及び第１部品のうち、各部品に対応する通報済みフラグが未通報を示す部品に対する配送要求を、部品を管理する管理装置３０に通報する。

これにより、消耗される部品に対して配送タイミングが近い部品をまとめて配送させることで、部品の配送コストを抑えることができる。

＜動作＞
次に、実施例１における機器１０の動作について説明する。以下でも、機器１０として画像処理装置を例に説明する。図７は、実施例１における画像処理装置１０の通報制御処理の一例を示すシーケンス図である。

ステップＳ１０１で、プロッタエンジン２２４は、サプライ状態変更を検知した場合、コントローラボード２１０に状態通知を行う。この例では、プロッタエンジン２２４は、トナー（Ｋ）の残量をＳＲＭ３０７に通知する。

ステップＳ１０２で、ＳＲＭ３０７は、通知されたトナー（Ｋ）の残量をＳＣＳ３０６に通知する。

ステップＳ１０３で、ＳＣＳ３０６は、通知されたトナー（Ｋ）の残量をＮＲＳ３０５に通知する。

ここで、ＳＣＳ３０６は、各ｘＣＳ、各アプリにサプライ状態（残量）をブロードキャストする。これは、各ｘＣＳ、各アプリがブロードキャストされたサプライ状態を受信した場合、各自モジュール／アプリの責務に従った処理を行うためである。

例えば、ＯＣＳ３００が受信した場合、操作パネル２１４にバナーでサプライエンドを表示させる。遠隔管理システム１における被管理装置機能を実現するＮＲＳ３０５の場合は、通報するかしないかの判定を行い、必要に応じて、管理装置３０にサプライエンドの通報を行う。

ステップＳ１０４、Ｓ１０５で、ＮＲＳ３０５は、トナー（Ｋ）の残量が通知されると、ＮＶＲＡＭ２１２に記憶された部品通報情報から各トナー（Ｋ／Ｙ／Ｍ／Ｃ）の通報タイミングを取得する。

ステップＳ１０６、Ｓ１０７で、ＮＲＳ３０５は、ＮＶＲＡＭ２１２に記憶された部品通報情報から各トナー（Ｋ／Ｙ／Ｍ／Ｃ）の通報閾値を取得する。

ステップＳ１０８で、ＮＲＳ３０５は、ＳＣＳ３０６に対し、残りのトナー（Ｙ／Ｍ／Ｃ）の残量取得要求を通知する。

ステップＳ１０９で、ＳＣＳ３０６は、ＮＲＳ３０５から取得したトナー（Ｙ／Ｍ／Ｃ）の残量取得要求をＳＲＭ３０７に通知する。

ステップＳ１１０で、ＳＲＭ３０７は、ＳＣＳ３０６から取得したトナー（Ｙ／Ｍ／Ｃ）の残量取得要求をプロッタエンジン２２４に通知する。

ステップＳ１１１で、プロッタエンジン２２４は、トナー（Ｙ／Ｍ／Ｃ）の残量を検知し、検知したトナー（Ｙ／Ｍ／Ｃ）の残量をＳＲＭ３０７に通知し、応答する。

ステップＳ１１２で、ＳＲＭ３０７は、トナー（Ｙ／Ｍ／Ｃ）の残量をＳＣＳ３０６に通知する。

ステップＳ１１３で、ＳＣＳ３０６は、トナー（Ｙ／Ｍ／Ｃ）の残量をＮＲＳ３０５に通知する。

ステップＳ１１４で、ＮＲＳ３０５は、トナー（Ｙ／Ｍ／Ｃ）の通報可能範囲の取得要求をＮＶＲＡＭ２１２に通知する。

ステップＳ１１５で、ＮＶＲＡＭ２１２は、トナー（Ｙ／Ｍ／Ｃ）の通報可能範囲をＮＲＳ３０５に通知し、応答する。

ステップＳ１１６で、ＮＲＳ３０５は、トナー（Ｙ／Ｍ／Ｃ）の通報済みフラグの取得要求をＮＶＲＡＭ２１２に通知する。

ステップＳ１１７で、ＮＶＲＡＭ２１２は、トナー（Ｙ／Ｍ／Ｃ）の通報済みフラグをＮＲＳ３０５に通知し、応答する。

ステップＳ１１８で、ＮＲＳ３０５は、サプライコールが必要なトナーを判定する。この判定処理は図８を用いて後述する。ＮＲＳ３０５は、判定したトナーのサプライコール（トナー配送要求）を管理装置３０に行う。図７に示す例ではトナー（Ｋ／Ｍ）のサプライコールが行われる。

ステップＳ１１９で、管理装置３０は、サプライコールを受信した場合は、受信ＯＫをＮＲＳ３０５に通知する。

ステップＳ１２０で、ＮＲＳ３０５は、通報したトナー（Ｋ／Ｍ）に対し、通報済みフラグを「通報済み」にするための設定要求をＮＶＲＡＭ２１２に通知する。

ステップＳ１２１で、ＮＶＲＡＭ２１２は、部品通報情報のトナー（Ｋ／Ｍ）に対する通報済みフラグを「通報済み」に設定し、設定完了したことをＮＲＳ３０５に通知し、応答する。

（通報判定処理）
次に、ＮＲＳ３０５における通報判定処理について説明する。図８は、実施例１における通報判定処理の一例を示すフローチャートである。図８に示す通報判定処理では、部品としてトナーを例にして説明する。

図８に示すステップＳ２０１で、ＮＲＳ３０５（第１判定部４０３）は、トナー残量が通知されたか否かを判定する。トナー残量が通知されていれば（ステップＳ２０１−ＹＥＳ）ステップＳ２０２に進み、トナー残量が通知されていなければ（ステップＳ２０１−ＮＯ）ステップＳ２０１に戻る。例えば、ＮＲＳ３０５は、トナー（Ｋ）の残量が１０％であることを通知されたとする。

ステップＳ２０２で、ＮＲＳ３０５（第１判定部４０３）は、ＮＶＲＡＭ２１２の部品通報情報（図６参照）から各色のトナーの通報タイミング、閾値（通報閾値）を取得する。

ステップＳ２０３で、ＮＲＳ３０５（第１判定部４０３）は、トナー残量が閾値以下であるか否かを判定する。閾値以下であれば（ステップＳ２０３−ＹＥＳ）ステップＳ２０４に進み、閾値より大きければ（ステップＳ２０３−ＮＯ）ステップＳ２０１に戻る。このとき、ＮＲＳ３０５は、トナー（Ｋ）の残量（１０％）が、通報タイミング「閾値以下」、閾値「１０％」に該当すると判定する。

ステップＳ２０４で、ＮＲＳ３０５（第２判定部４０４）は、ＳＣＳ３０６経由で、プロッタエンジン２２４からその他のトナー（Ｙ／Ｍ／Ｃ）の残量を取得するよう要求する。トナー（Ｋ）の残量は取得されているため、その他のトナーの残量が取得される。ここで、ＮＲＳ３０５（第２判定部４０４）が取得した残量は、Ｙ＝「３０％」、Ｍ＝「２５％」、Ｃ＝「４０％」を例とする。

ステップＳ２０５で、ＮＲＳ３０５（第２判定部４０４）は、ＮＶＲＡＭ２１２の部品通報情報（図６参照）からその他のトナー（Ｙ／Ｍ／Ｃ）の通報可能範囲を取得する。

ステップＳ２０６で、ＮＲＳ３０５（通報判定部４０５）は、ＮＶＲＡＭ２１２の部品通報情報（図６参照）から各トナー（Ｋ／Ｙ／Ｍ／Ｃ）の通報済みフラグを取得する。

ステップＳ２０７で、ＮＲＳ３０５（通報判定部４０５）は、トナー（Ｋ）は、通報済みか否かを、通報済みフラグを用いて判定する。通報済みであれば（ステップＳ２０７−ＹＥＳ）その後の処理を行わずにステップＳ２０１に戻り、通報済みでなければ（ステップＳ２０７−ＮＯ）ステップＳ２０８に進む。閾値以下のトナーが既に通報済みであれば、機器１０はその他の処理を行わずに済む。

ステップＳ２０８で、ＮＲＳ３０５（第２判定部４０４）は、その他のトナー（Ｙ／Ｍ／Ｃ）の残量が「通報閾値＋通報可能範囲」の所定範囲内であるか否かを判定する。通報閾値は通報タイミングに直接設定されていてもよい。その他のトナー残量が所定範囲内であれば（ステップＳ２０８−ＹＥＳ）ステップＳ２０９に進み、その他のトナー残量が所定範囲を超えていれば（ステップＳ２０８−ＮＯ）ステップＳ２１１に進む。

例えば、トナー（Ｙ／Ｍ）の残量は、「通報閾値+通報可能範囲」以内であるため、次の処理（Ｓ２０９）に移る。トナーＣの残量は「通報閾値＋通報可能範囲」を超えるため、トナーＣは通報しないと判断される。
・トナーＹ残量「３０％」は、「通報閾値「２０％」＋通報可能範囲「１０％」」以内である
・トナーＭ残量「２５％」は、「通報閾値「１０％」＋通報可能範囲「１５％」」以内である
・トナーＣ残量「４０％」は、「通報閾値「３０％」＋通報可能範囲「０％」」を超える
ステップＳ２０９で、ＮＲＳ３０５（通報判定部４０５）は、トナー（Ｙ／Ｍ）は、通報済みか否かを、通報済みフラグを用いて判定する。通報済みであれば（ステップＳ２０９−ＹＥＳ）ステップＳ２１１に進み、通報済みでなければ（ステップＳ２０９−ＮＯ）ステップＳ２１０に進む。ＮＲＳ３０５は、トナー（Ｙ／Ｍ）の通報済みフラグを参照し、トナー（Ｍ）は未通報であると判定する。

ステップＳ２１０で、ＮＲＳ３０５（通報部４０６）は、閾値以下のトナーと合わせて通報可能範囲内にあるトナーのサプライコール（配送要求）を管理装置３０に行う。例えば、ＮＲＳ３０５（通報部４０６）は、トナー（Ｋ）のサプライコール（トナー（Ｋ）の配送要求）とあわせて、トナー（Ｍ）のサプライコールも同一コール内で管理装置３０に送信する。トナー（Ｙ）は既に配送要求済みであるため、ＮＲＳ３０５（通報部４０６）は、配送要求を行わない。

ステップＳ２１１で、ＮＲＳ３０５（通報部４０６）は、閾値以下のトナーのサプライコールを管理装置３０に行う。例えば、ＮＲＳ３０５（通報部４０６）は、トナー（Ｋ）のみのサプライコールを管理装置３０に行う。

ステップＳ２１２で、ＮＲＳ３０５は、管理装置３０からトナーの配送要求受信済みの応答を受信した場合、ＮＶＲＡＭ２１２に保持されている配送要求を行ったトナーの通報済みフラグを通報済みに設定する。

ここで、通報済みフラグのリセットについて、通報タイミング「閾値以下」の場合はトナー交換時（新トナーがセットされた際に）に通報済みフラグはリセットされる。

（設定処理）
次に、部品通報情報の各設定値を設定する処理について説明する。図９は、実施例１における設定処理（その１）の一例を示すシーケンス図である。

図９に示すステップＳ３０１で、端末ＰＣ（Personal Computer）は、画像処理装置１０のウェブブラウザ３１４を用いてトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）を設定する。

ステップＳ３０２で、ブラウザアプリ３１４は、設定されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）をＮＲＳ３０５に通知する。

ステップＳ３０３で、ＮＲＳ３０５は、通知されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）をＮＶＲＡＭ２１２の部品通報情報に設定する。

ステップＳ３０４で、ＮＶＲＡＭ２１２は、設定が完了したことをＮＲＳ３０５に通知する。

ステップＳ３０５で、ＮＲＳ３０５は、部品通報情報への設定が完了したことをブラウザアプリ３１４に通知する。

ステップＳ３０６で、ブラウザアプリ３１４は、設定されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）を端末ＰＣ上に表示する。

図１０は、実施例１における設定処理（その２）の一例を示すシーケンス図である。図１０に示すステップＳ４０１で、操作パネル（操作部）２１４は、ユーザにより入力された、トナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）を部品通報情報に設定するためにＯＣＳ３００に通知する。

ステップＳ４０２で、ＯＣＳ３００は、通知されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）をＮＲＳ３０５に通知する。

ステップＳ４０３で、ＮＲＳ３０５は、通知されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）をＮＶＲＡＭ２１２の部品通報情報に設定する。

ステップＳ４０４で、ＮＶＲＡＭ２１２は、設定が完了したことをＮＲＳ３０５に通知する。

ステップＳ４０５で、ＮＲＳ３０５は、部品通報情報への設定が完了したことをＯＣＳ４０５に通知する。

ステップＳ４０６で、ＯＣＳ３００は、設定されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）を操作パネル２１４上に表示する。

図１１は、実施例１における設定処理（その３）の一例を示すシーケンス図である。図１１に示すステップＳ５０１で、管理装置３０は、入力されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）を部品通報情報に設定するためにＮＲＳ３０５に通知する。

ステップＳ５０２で、ＮＲＳ３０５は、通知されたトナー（Ｋ／Ｍ／Ｙ／Ｃ）の通報タイミング、通報閾値（％）、通報可能範囲（％）をＮＶＲＡＭ２１２の部品通報情報に設定する。

ステップＳ５０３で、ＮＶＲＡＭ２１２は、設定が完了したことをＮＲＳ３０５に通知する。

ステップＳ４０５で、ＮＲＳ３０５は、部品通報情報への設定が完了したことを管理装置３０に通知する。

これにより、様々な手段を用いて、部品通報情報への設定を行うことができる。また、画像処理装置１０は、上記各設定手段のうち、１又は複数の組み合わせにより設定を可能にしてもよい。

以上、実施例１によれば、消耗される部品に対して配送タイミングが近い部品をまとめて配送することで、配送コストを抑えることができる。また、実施例１によれば、予備用の部品を持たない場合でも、機器のトナーエンド時の交換用トナーがないことによる機器のダウンタイムをなくすことができる。

［実施例２］
次に、実施例２における機器について説明する。実施例２では、通報タイミングが「交換時」となる。通報タイミングが交換時であっても、配送コストを抑えることができる。

＜遠隔管理システム、管理装置、機器＞
実施例２における遠隔管理システム、管理装置、機器の構成は、実施例１と同様であるため、実施例１と同じ符号を用いる。以降では、実施例１と異なる機器１０の機能について、主に説明する。

（機能）
記憶部４０１は、消耗される各部品に対し、通報タイミング、通報可能範囲、及び通報済みフラグを対応付けた部品通報情報を記憶する。実施例２では、実施例１とは通報タイミングの内容が異なる。

実施例２では、通報タイミングが「交換」に設定されている。つまり、トナーの交換時にトナー配送要求が管理装置３０に通報される。

図１２は、実施例２における部品通報情報の一例を示す図である。図１２に示す例では、部品はトナーである。図１２に示す部品通報情報では、トナー毎に、通報タイミング、通報閾値、通報可能範囲、通報済みフラグが関連付けられて保持される。この部品通報情報は、例えばＮＶＲＡＭ２１２に記憶される。

例えば、Ｋ（ブラック）のトナーには、通報タイミング「交換」、通報閾値「１０％」、通報可能範囲「５％」、通報済みフラグ「未通報」が対応付けられている。なお、通報タイミングが「交換」の場合、通報閾値は不要であるが、通報タイミングを「閾値以下」と「交換」とで切り替えできるように、部品通報情報は通報閾値を残している。よって、通報タイミングが「交換」の場合、通報閾値は参照されない。

＜動作＞
次に、実施例２における機器１０の動作について説明する。以下でも、機器１０として画像処理装置を例に説明する。図１３は、実施例２における画像処理装置１０の通報制御処理の一例を示すシーケンス図である。

ステップＳ５０１で、プロッタエンジン２２４は、サプライ状態変更を検知した場合、コントローラボード２１０に状態通知を行う。この例では、プロッタエンジン２２４は、トナー（Ｋ）の交換をＳＲＭ３０７に通知する。

ステップＳ５０２で、ＳＲＭ３０７は、通知されたトナー（Ｋ）の交換を示す情報をＳＣＳ３０６に通知する。

ステップＳ５０３で、ＳＣＳ３０６は、通知されたトナー（Ｋ）の交換を示す情報をＮＲＳ３０５に通知する。

ステップＳ５０４〜Ｓ５２１の処理は、図７に示すステップＳ１０５〜Ｓ１２１の処理と同様であるため、その説明を省略する。

（通報判定処理）
次に、ＮＲＳ３０５における通報判定処理について説明する。図１４は、実施例２における通報判定処理の一例を示すフローチャートである。図１４に示す通報判定処理では、部品としてトナーを例にして説明する。

図１４に示すステップＳ６０１で、ＮＲＳ３０５（第１判定部４０３）は、トナー交換が通知されたか否かを判定する。トナー交換が通知されていれば（ステップＳ６０１−ＹＥＳ）ステップＳ６０２に進み、トナー交換が通知されていなければ（ステップＳ６０１−ＮＯ）ステップＳ６０１に戻る。例えば、ＮＲＳ３０５は、トナー（Ｋ）の交換が通知されたとする。

ステップＳ６０２〜Ｓ６０５の処理は、図８に示すステップＳ２０２、Ｓ２０４〜Ｓ２０６の処理と同様であるため、その説明を省略する。なお、ステップＳ６０３において、ＮＲＳ３０５（第２判定部４０４）が取得した残量は、Ｙ＝「１０％」、Ｍ＝「１５％」、Ｃ＝「２０％」を例とする。また、ステップＳ６０２において、ＮＲＳ３０５は、通報タイミングが「交換」と予め分かっている場合は通報閾値を取得しなくてもよい。

ステップＳ６０６で、ＮＲＳ３０５（通報判定部４０５）は、交換されたトナー（Ｋ）は、通報済みか否かを、通報済みフラグを用いて判定する。通報済みであれば（ステップＳ６０６−ＹＥＳ）その後の処理を行わずにステップＳ６０１に戻り、通報済みでなければ（ステップＳ６０６−ＮＯ）ステップＳ６０７に進む。閾値以下のトナーが既に通報済みであれば、機器１０はその他の処理を行わずに済む。

ステップＳ６０７で、ＮＲＳ３０５（第２判定部４０４）は、その他のトナー（Ｙ／Ｍ／Ｃ）の残量が「通報可能範囲」である所定範囲内であるか否かを判定する。その他のトナー残量が所定範囲内であれば（ステップＳ６０７−ＹＥＳ）ステップＳ６０８に進み、その他のトナー残量が所定範囲を超えていれば（ステップＳ６０７−ＮＯ）ステップＳ６１０に進む。

例えば、トナー（Ｙ／Ｍ）の残量は、「通報可能範囲」以内であるため、次の処理（Ｓ６０８）に移る。トナーＣの残量は「通報可能範囲」を超えるため、トナーＣは通報しないと判断される。
・トナーＹ残量「１０％」は、通報可能範囲「１０％」以内である
・トナーＭ残量「１５％」は、通報可能範囲「１５％」以内である
・トナーＣ残量「２０％」は、通報可能範囲「０％」を超える
ステップＳ６０８で、ＮＲＳ３０５（通報判定部４０５）は、トナー（Ｙ／Ｍ）は、通報済みか否かを、通報済みフラグを用いて判定する。通報済みであれば（ステップＳ６０８−ＹＥＳ）ステップＳ６１０に進み、通報済みでなければ（ステップＳ６０８−ＮＯ）ステップＳ６０９に進む。ＮＲＳ３０５は、トナー（Ｙ／Ｍ）の通報済みフラグを参照し、トナー（Ｍ）は未通報であると判定する。

ステップＳ６０９で、ＮＲＳ３０５（通報部４０６）は、交換されたトナーと合わせて通報可能範囲内にあるトナーのサプライコール（配送要求）を管理装置３０に行う。例えば、ＮＲＳ３０５（通報部４０６）は、トナー（Ｋ）のサプライコール（トナー（Ｋ）の配送要求）とあわせて、トナー（Ｍ）のサプライコールも同一コール内で管理装置３０に送信する。トナー（Ｙ）は既に配送要求済みであるため、ＮＲＳ３０５（通報部４０６）は、配送要求を行わない。

ステップＳ６１０で、ＮＲＳ３０５（通報部４０６）は、交換されたトナーのサプライコールを管理装置３０に行う。例えば、ＮＲＳ３０５（通報部４０６）は、トナー（Ｋ）のみのサプライコールを管理装置３０に行う。

ステップＳ６１１で、ＮＲＳ３０５は、管理装置３０からトナーの配送要求受信済みの応答を受信した場合、ＮＶＲＡＭ２１２に保持されている配送要求を行ったその他のトナー（Ｍ）の通報済みフラグを通報済みに設定する。

ここで、通報済みフラグのリセットについて、通報タイミング「交換」の場合も、トナー交換時（新トナーがセットされた際に）に通報済みフラグがリセットされる。

（設定処理）
実施例２における部品通報情報の設定処理は、通報タイミングが「交換」に変わるだけで、図９〜１１で説明した処理と同様である。

以上、実施例２によれば、消耗される部品に対して配送タイミングが近い部品をまとめて配送することで、配送コストを抑えることができる。また、実施例２によれば、予備用の部品を持つ場合でも、機器のトナーエンド時の交換用トナーがないことによる機器のダウンタイムをなくすことができる。

［変形例］
次に、上述した各実施例の変形例について説明する。各実施例では、機器１０として画像処理装置について説明したが、消耗される部品であり、かつ交換を必要とする部品を備える機器であれば、上記各実施例を適用することができる。

なお、各実施例の機器１０で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、各実施例の機器１０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、各実施例の機器１０で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、各実施例の機器１０で実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

なお、本発明は、上記各実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施例に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施例に示される全構成要素からいくつかの構成要素を削除してもよい。

１ 遠隔管理システム
１０ 機器
３０ 管理装置
２１２ ＮＶＲＡＭ
２１３ ＨＤＤ
２１５ ＣＰＵ
３０５ ＮＲＳ
３０６ ＳＣＳ
４０１ 記憶部
４０２ 検知部
４０３ 第１判定部
４０４ 第２判定部
４０５ 通報判定部
４０６ 通報部

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

Claims (7)

1. 複数の消耗される部品を有する機器であって、
   前記機器の消耗される各部品に対し、通報タイミング、通報可能範囲、及び通報済みフラグを対応付けた情報を記憶する記憶部と、
   前記各部品の残量が、前記各部品に対応する通報タイミングに該当するか否かを判定する第１判定部と、
   前記通報タイミングに該当する第１部品があると判定された場合、前記複数の消耗される部品のうち、前記第１部品以外の部品の残量が、前記通報タイミングと前記通報可能範囲とに基づく所定範囲内にあるか否かを判定する第２判定部と、
   前記所定範囲内にあると判定された第２部品及び前記第１部品のうち、各部品に対応する前記通報済みフラグが未通報を示す部品に対する配送要求を、前記部品を管理する管理装置に通報する通報部と
   を備える機器。
2. 前記第２判定部及び前記通報部は、
   前記第１部品に対応する通報済みフラグが通報済みを示す場合、処理を行わない請求項１記載の機器。
3. 前記通報済みフラグは、前記部品の交換時にリセットされる請求項１又は２記載の機器。
4. 前記通報タイミングは、閾値以下又は交換時である請求項１乃至３いずれか一項に記載の機器。
5. 前記通報タイミング及び／又は前記通報可能範囲は、前記機器のブラウザ、操作部、又は外部の装置からの設定要求により設定可能とする請求項１乃至４いずれか一項に記載の機器。
6. 部品に対する配送要求を受けると、前記部品の配送を手配する遠隔管理システムであって、
   複数の消耗される部品を有する機器の消耗される各部品に対し、通報タイミング、通報可能範囲、及び通報済みフラグを対応付けた情報を記憶する記憶部と、
   前記各部品の残量が、前記各部品に対応する通報タイミングに該当するか否かを判定する第１判定部と、
   前記通報タイミングに該当する第１部品があると判定された場合、前記複数の消耗される部品のうち、前記第１部品以外の部品の残量が、前記通報タイミングと前記通報可能範囲とに基づく所定範囲内にあるか否かを判定する第２判定部と、
   前記所定範囲内にあると判定された第２部品及び前記第１部品のうち、各部品に対応する前記通報済みフラグが未通報を示す部品に対する配送要求を、前記部品を管理する管理装置に通報する通報部と
   を備える遠隔管理システム。
7. 複数の消耗される部品を有する機器の消耗される各部品に対し、通報タイミング、通報可能範囲、及び通報済みフラグを関連付けた情報を記憶する記憶部を備えるコンピュータに実行させるプログラムであって、
   前記各部品の残量が、前記各部品に対応する通報タイミングに該当するか否かを判定する第１判定ステップと、
   前記通報タイミングに該当する第１部品があると判定された場合、前記複数の消耗される部品のうち、前記第１部品以外の部品の残量が、前記通報タイミングと前記通報可能範囲とに基づく所定範囲内にあるか否かを判定する第２判定ステップと、
   前記所定範囲内にあると判定された第２部品及び前記第１部品のうち、各部品に対応する前記通報済みフラグが未通報を示す部品に対する配送要求を、前記部品を管理する管理装置に通報する通報ステップと
   を有するプログラム。

Images