管理装置、管理方法、及びプログラム
【課題】 管理負荷とユーザの運用状況を十分に考慮した、適切な稼動情報の送信スケジュールを画像形成装置に設定する。
【解決手段】 管理装置１００は、データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する（Ｓ８０１〜Ｓ８０３）。そして、管理装置１００は、特定した複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する（Ｓ８０４）。そして、管理装置１００は、管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する（Ｓ８０７〜Ｓ８１４）。
【解決手段】 管理装置１００は、データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する（Ｓ８０１〜Ｓ８０３）。そして、管理装置１００は、特定した複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する（Ｓ８０４）。そして、管理装置１００は、管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する（Ｓ８０７〜Ｓ８１４）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続される複数の画像形成装置を管理する管理装置に関するものである。
【背景技術】
【０００２】
ネットワーク上に配置された監視サーバ及びプリンタを管理する印刷ログ管理サーバが特許文献１に開示されている。
具体的には、特許文献１では、監視サーバの構成変更が生じたとき、印刷ログ管理サーバは、各グループＡ，Ｂに属する複数のプリンタａ〜ｎの監視サーバａ，ｂの監視一覧画面を表示させる。そして、この表示画面上で、監視サーバａ，監視サーバｂが監視対象とするプリンタの印刷ログに基づく情報を表示する。この表示に基づいて、監視サーバａ，ｂが監視すべきプリンタの設定を行う。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−３１０４６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方、部門管理機能を有する複数の画像形成装置の稼動情報に基づき部門管理を行う場合、実際の運用では同じ部門ＩＤを複数の画像形成装置に登録し、ユーザは複数の画像形成装置を利用できるような形態を採用する場合がある。ここで、画像形成装置はプリンタ、複写機、及び複合機などを含むものとする。また、稼動情報は、印刷の度にカウントアップされる印刷枚数や印刷面数などのカウンタ情報を含む。
【０００５】
このため、各部門ＩＤに対応する部門カウンタの情報をリモートで集計する管理装置では、複数の画像形成装置から収集した部門カウンタの情報により各部門のカウンタ情報の総計を求めるなどの集計処理することができる構成を備える。
部門カウンタのデータ量は、画像形成装置に登録する部門数が増えるにつれ増加してしまうため、ネットワーク負荷の集中を避けるために各装置の部門カウンタの送信スケジュールを１〜２回／１日程度に設定している。これにより、頻繁に部門カウンタの情報を送信しないように制御している。
【０００６】
しかしながら、部門カウンタの情報の送信スケジュールをある程度分散させて設定してしまうと、管理装置で部門カウンタの情報を集計して表示する処理において問題が発生する。
例えば、管理装置が、送信スケジュールが朝（ＡＭ５：００）の１０台の画像形成装置と、送信スケジュールが夜（ＰＭ１１：００）の１５台の画像形成装置とを管理する場合を想定する。
【０００７】
ここで、管理装置上で部門カウンタの情報の集計をある日の昼（ＰＭ０：３０）に確認する際、以下のような表示されることとなる。つまり、昼（ＰＭ０：３０）の時点では、その日の朝に収集された１０台の画像形成装置の部門カウンタの情報と、その前日の夜に収集された１５台の画像形成装置の部門カウンタの情報との集計結果が表示される。
特定の日をカウンタ情報に基づき課金処理などを行うための締め日とする場合、設定されたスケジュールにより、締め日の同じ時点での各画像形成装置の部門カウンタの情報が集計結果に反映されないことになる。
【０００８】
このような問題に対して、全ての画像形成装置に対し一律で同じスケジュール設定を行う方法も考えられる。しかしながら、単純に同じ時刻でスケジューリングした場合、大手企業など大量の画像形成装置を利用するユーザにおいては、たとえば１００台単位で同じ時刻にスケジュール設定されることになる。
また、当然ながらユーザの運用により、画像形成装置の利用形態は変更される場合があり、運用の中で適切なスケジューリングになるよう適宜見直す必要がある。
【０００９】
本発明は、上記の課題を解決するためになされたものである。
そして、本発明の目的は、管理負荷とユーザの運用状況を十分に考慮した、適切な稼動情報の送信スケジュールを画像形成装置に設定できる仕組みを提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成する本発明の管理装置は以下に示す構成を備える。
複数の画像形成装置から、各画像形成装置に設定されている送信スケジュールに従い受信される部門カウンタの情報を、データベースを用いて管理する管理装置であって、画像形成装置の識別情報、当該画像形成装置から受信した部門ＩＤ、及び該部門ＩＤに対応する部門カウンタの情報を関連付けて前記データベースに登録する登録手段と、前記データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する特定手段と、前記特定手段で特定された複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する管理手段と、前記管理手段で管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する決定手段と、前記決定手段により決定された各グループの送信スケジュールを各グループに属する画像形成装置に対して設定するための情報を生成し、当該画像形成装置からの要求の応答として生成した情報を送信する送信手段とを備え、前記管理手段は、前記特定手段で特定された複数の画像形成装置の台数が上限以上の場合は、当該特定された複数の画像形成装置を複数の異なるグループで管理し、前記決定手段は、前記管理手段により前記特定手段で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理された場合、当該複数のグループ間においては前記第１の時間間隔よりも短い第２の時間間隔で送信スケジュールを決定することを備えることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、管理負荷とユーザの運用状況を十分に考慮した、適切な稼動情報の送信スケジュールを画像形成装置に設定できる仕組みを提供できる。
【図面の簡単な説明】
【００１２】
【図１】管理システムの一例を示す図である。
【図２】管理装置の構成を説明するブロック図である。
【図３】画像形成装置の構成を示すブロック図である。
【図４】管理装置のソフトウェアモジュールを示すブロック図である。
【図５】画像形成装置のソフトウェアモジュールを示す図である。
【図６】管理システムのデータ処理手順を示すフローチャートである。
【図７】管理装置のデータ処理手順を示すフローチャートである。
【図８】データベースで管理されるテーブルを示す図である。
【図９】管理装置のデータ処理手順を示すフローチャートである。
【図１０】管理装置のデータ処理手順を示すフローチャートである。
【図１１】管理装置のデータ処理手順を示すフローチャートである。
【図１２】表示部に表示されるＵＩの一例を示す図である。
【図１３】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１４】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１５】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１６】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１７】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１８】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１９】各画像形成装置の送信スケジュール設定処理を示す図である。
【発明を実施するための形態】
【００１３】
次に本発明を実施するための最良の形態について図面を参照して説明する。
〔第１実施形態〕
＜システム構成の説明＞
【００１４】
図１は、本実施形態を示す管理システムの一例を示す図である。本例は、監視対象となる部門管理可能な複数の画像形成装置と、それらが画像形成装置から送信する稼動情報を受信し、管理する管理装置から構成される管理システムの例である。より具体的には、ネットワークに接続される複数の画像形成装置から取得される部門カウンタの情報を収集して管理する管理装置が、インターネット１０１、ゲートウエイ１０３、ネットワーク１０７を介して接続される例である。なお、管理装置１００と各画像形成装置は、例えばＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で相互に通信可能に構成されている。ただし、ゲートウエイ１０３はルーターやプロキシサーバー、ファイヤーウォールなどで構成される。
【００１５】
ここで、部門管理可能な画像形成装置とは、複数の部門ＩＤが登録され、印刷時などにそれら部門ＩＤごとにカウンタの情報を部門カウンタとして計数、管理する部門管理機能を有する画像形成装置である。また、複数の画像形成装置で共通する部門ＩＤが登録されて、システム運用される場合もある。
図１において、１０４〜１０６は画像形成装置で、ここでは複合機（ＭＦＰ：Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）で構成される例を示す。また画像形成装置としては、プリンタなどの単一機能周辺機器（ＳＦＰ：Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）や複写機などで構成されていてもよい。
また、インターネット１０１に接続される管理装置１００は、画像形成装置１０４〜１０６からのコマンド要求に対し、所望のデータを送信するよう指示する。また、管理装置１００は、画像形成装置１０４〜１０６から後述するスケジュール設定に従った定期的な、または不定期な、部門カウンタの情報及びエラー情報などを含む稼動情報等を受信して、データベースで管理する。なお、画像形成装置の台数には制限はない。
【００１６】
このように構成された管理システムにおいて、画像形成装置１０４〜１０６は、管理装置１００により指定されるスケジュール設定に合わせて、自身が管理するカウンタ情報、エラー情報を含む稼動情報を管理装置１００に送信する。
管理装置１００は受信した稼動情報を分類し、データベースに蓄積して管理することで、顧客に対して利用枚数に応じた課金等を行う。
画像形成装置１０４〜１０６は、登録された部門ＩＤ毎に管理される部門カウンタの情報を、管理装置１００から受信し、設定されるスケジュール設定に従い、管理装置１００に送信する。
【００１７】
この際、画像形成装置１０４〜１０６に登録されている全ての部門ＩＤに対応するカウンタ情報を管理装置１００に送信する。また、画像形成装置１０４〜１０６において、部門ＩＤが削除された場合、以降の送信時にはその部門ＩＤに関する稼動情報は一切送らない。
管理装置１００は、以前送信されていた部門ＩＤが送信されなくなることで、画像形成装置において部門ＩＤが削除されたことを把握することができる。また、管理装置１００は、稼動情報に変化の無い（カウンタ情報がカウントアップされていない）部門ＩＤを特定することで、画像形成装置でまったく利用されていない部門ＩＤが存在することを把握することができる。
［管理装置１００の構成］
【００１８】
図２は、図１に示した管理装置１００の構成を説明するブロック図である。管理装置１００は、以下に示すハードウエア資源などを備える。ここで、管理装置１００は、例えば、一般的なＰＣなどで構成することができる。
図２において、ＲＯＭ２０３は、ＣＰＵ２０１が実行するプログラム（後述する図４の各処理を実現するモジュールも含む）を格納している。ＣＰＵ２０１は、内部バス２０６を介して接続される各デバイスを総括的に制御する。ここで、内部バス２０６には、ＲＡＭ２０２、ＲＯＭ２０３、ハードディスクドライブ（以後ＨＤＤとする）２０４、ネットワークインタフェース２０５の各デバイスが接続されている。２０８は表示部で、Ｉ／Ｏインタフェース２０７を介して接続され、アプリケーションに基づくユーザインタフェースを表示する。
ネットワークインタフェース（ＮＷ Ｉ／Ｆ）１０５は、図１に示したネットワーク１０７を介して、外部のネットワーク機器或いはパーソナルコンピュータ（ＰＣ）と双方向にデータをやりとりする。ここで、外部のネットワーク機器には、図１に示した画像形成装置１０４〜１０６などが含まれる。
【００１９】
ＨＤＤ２０４は、外部記憶装置として機能し、画像形成装置１０４〜１０６から取得する稼動情報を記憶する。また、ＣＰＵ２０１は、ＨＤＤ２０４に画像データを記録することも可能に構成されている。さらに、ＨＤＤ２０４には、オペレーティングシステム（ＯＳ）がインストールされており、ＲＡＭ２０２にロードされた後、各種のデータ、アプリケーションの実行を管理する。また、ＣＰＵ２０１は、アプリケーションをＲＡＭ２０２にロードして実行することでデータ通信処理、データ算出処理、データ表示処理等を行う。
このように構成された管理装置１００において、以下に示す部門カウンタ監視処理を行う。
【００２０】
具体的には、管理装置１００には、画像形成装置の識別情報（シリアルナンバー、ＩＰアドレス、ＭＡＣアドレス、及び製品名等）が登録されており、各画像形成装置から送信されてくるデータに含まれる識別情報を元にデータベースに格納する。
部門カウンタについては、画像形成装置から１度でも部門カウンタの情報が受信された際に、送信されてきた部門カウンタの情報に対応する部門ＩＤを登録し、新たに部門カウンタの情報をデータベースに格納する。なお、複数部門にまたがる集計値や、部門単位での集計値などについては、管理装置１００の表示部２０７の表示画面から要求された形式での集計を適宜行うため、ここではデータベースには集計値の格納を行わない。
［画像形成装置の構成］
【００２１】
図３は、図１に示した画像形成装置１０４〜１０６の構成を示すブロック図である。画像形成装置の構成は基本的に同じであるので、ここでは画像形成装置１０４について説明する。
画像形成装置１０４は、ＲＯＭ３０３に格納されているプログラム（後述する図５の各処理を実現するプログラムも含む）を実行するＣＰＵ３０１を備え、内部バス３０６を介して各デバイスを総括的に制御する。
内部バス３０６には、ＲＡＭ３０２、ＲＯＭ３０３、ハードディスク装置（以後ＨＤＤとする）３０４、デバイス制御部３０７、印刷部３０８、ＮＷＩ／Ｆ３０５の各デバイスが接続されている。
【００２２】
ＲＡＭ３０２は、ＣＰＵ３０１のメモリやワークエリアとして機能する。デバイス制御部３０７は印刷部３０８又はスキャナ部３０９、あるいは印刷部３０８及びスキャナ部３０９を制御して、画像処理を制御する。
【００２３】
ＮＷ Ｉ／Ｆ３０５は、ネットワーク１０７を介して、外部のネットワーク機器或いはパーソナルコンピュータ（ＰＣ）と双方向にデータをやりとりする。ＨＤＤ３０４は外部記憶装置として機能し、画像データ等を記憶する。さらに、ＨＤＤ３０４は、部門カウンタを含む稼動情報、システム情報及びステータス情報を保存することも可能である。ＣＰＵ３０１は、ＨＤＤ３０４に画像データを記録する処理を行うことも可能に構成されている。
［管理装置のソフトウェアモジュール構成］
【００２４】
図４は、図１に示した管理装置１００のソフトウェアモジュールの構成を示すブロック図である。
図４において、４００はＨＴＴＰ／ＳＯＡＰクライアントモジュール（以下、クライアントモジュールと呼ぶ）で、ＳＯＡＰファンクションモジュール（以下、ファンクションモジュールと呼ぶ）４０１からの送信要求を受け、所定のスキーマに基づくマークアップ言語記述を作成する。ここで、ＨＴＴＰとは、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌであり、ＳＯＡＰとは、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌである。これらのプロトコルは、管理システムにおいて、画像形成装置１０４〜１０６と管理装置１００との間におけるデータやサービスを呼び出すために用いられる。
ここで、情報の各々に対応するスキーマ仕様はクライアントモジュール４００がアクセスできる記憶部、例えばＲＯＭ２０３またはＨＤＤ２０４に予め格納されているものとする。
【００２５】
クライアントモジュール４００は、作成したマークアップ言語記述のデータを、インターネット１０１を介して指定される画像形成装置１０４〜１０６へ送信する。
ここで、マークアップ言語記述としては、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が挙げられる。なお、説明では、ファンクションモジュール４０１がクライアントモジュール４００に各種情報の通知を行うよう説明した。しかしながら、クライアントモジュール４００自らが、上述の情報をファンクションモジュール４０１から取得するようにしても良い。
【００２６】
また、クライアントモジュール４００は、ＳＯＡＰ情報の受信を受け、所定のスキーマに基づきマークアップ言語記述からデータを抽出してファンクションモジュール４０１へ渡す。
データベース４０４には、取得した稼動情報や内部動作のログ、通信履歴（成功、失敗）等が格納されている。例えば、管理する画像形成装置の情報や部門カウンタの識別情報（部門ＩＤ）とその値が関連付けられて格納されることになる。なお、本実施形態に示す稼動情報には、１以上の部門カウンタが含まれており、部門カウンタの情報は、部門ＩＤにより識別されて、実際に画像形成が実行された印刷枚数や面数などの値が含まれる。画像形成装置から稼動情報などを取得するスケジュール設定は、管理装置１００による後述する処理に基づき自動的に更新される場合がある。
【００２７】
データベースに登録されている画像形成装置の情報としては、固有に設定される情報（ＩＰアドレス、ＭＡＣアドレス、デバイスシリアル番号、製品名、製品タイプなど）といった管理に必要な情報を指している。
管理部４０５は、画像形成装置１０４〜１０６から取得した稼動情報のデータベース４０４への格納及びデータベース４０４からの出力の制御を処理ロジック４０３に基づき行うモジュールである。また、管理部４０５は後述するようなスケジューリング処理も行う。管理部４０５は、管理装置１００において稼動情報を受信するなどのタイミングで制御ネージャ４０２から処理要求を受け、処理ロジック４０３に基づく各種処理を実行する。
［画像形成装置のソフトウェアモジュール構成］
【００２８】
図５は、図１に示した画像形成装置１０４のソフトウェアモジュールの構成を示す図である。
図５において、ファンクションモジュール５０１は、クライアントモジュール５００に、マネージャ５０２から受けた情報およびマークアップ言語記述の作成依頼、及び作成したマークアップ言語記述を指定される管理装置１００へ送信する通信依頼を行う。ここで、指定される管理装置の情報は、事前にクライアントモジュール５００が保持している形態でも良いし、設置時に設定しても良い。
【００２９】
クライアントモジュール５００では、ファンクションモジュール５０１からの情報を受け、所定のスキーマに基づくマークアップ言語記述を作成する。ここで、可変情報や固定情報の各々に対応するスキーマ仕様はＨＴＴＰ／ＳＯＡＰクライアントモジュールがアクセスできる記憶部に予め格納されているものとする。
そして、クライアントモジュール５００は、作成したマークアップ言語記述のデータを、指定される管理装置１００へ送信する。マークアップ言語記述としては、例えばＸＭＬが挙げられる。なお、上の説明では、ファンクションモジュール５０１がクライアントモジュール５００に各種情報の通知を行うよう説明した。
【００３０】
例えば、クライアントモジュール５００自らが、上述の情報をファンクションモジュール５０１から取得するようにしても良い。
デバイス制御モジュール５０７は、図３に示したデバイス制御部３０７及び印刷部３０８のインタフェースに対応する。したがって、デバイス制御モジュール５０７を介して、例えば印刷部３０８で検知されるエラーなどを含む、画像形成装置１０４〜１０６におけるステータス情報やカウンタ情報が通知されてくる。
【００３１】
ここで、カウンタ情報には、画像形成装置１０４〜１０６が画像形成した利用枚数を示すカウンタの値や、装置内の部品の使用状況を示す部品カウンタの値、その他の機能の利用状況を示す機能カウンタの値等の各種カウンタ値が含まれる。
また、エラー情報には画像形成装置１０４〜１０６に蓄積される印刷ジョブの状態、画像形成装置１０４〜１０６で発生した障害が含まれる。
【００３２】
画像形成装置１０４〜１０６の障害としては、ハードディスクエラーや課金カウンタエラー等のサービスコールエラー、紙ジャム等のエラー、或いはトナーロー等のワーニングなどのエラーが含まれる。さらに、画像形成装置１０４〜１０６の障害にはドアオープン、排紙トレイの紙積載超過なども含むものとする。
状態イベントモジュール５０４は、デバイス制御モジュール５０７から通知されたエラー情報リスト（複数種類のエラー情報）をマネージャ５０２に通知する。
【００３３】
定期データモジュール５０５は、デバイス制御モジュール５０７から取得できるカウンタ情報をマネージャ５０２に通知する。カウンタ情報は定期的に取得するため、タイマモジュール５０６からの設定されている時刻に基づき、マネージャモジュール５０２より要求される。
【００３４】
５０９は管理部で、記憶装置５０８への格納及び記憶装置５０８からの出力の制御を処理ロジック５０３に基づき行うモジュールである。管理部５０９は、取得した部門カウンタの情報を含む稼動情報を処理ロジック５０３経由で記憶装置５０８に格納する。また、管理部５０９は稼動情報の外部送信などに際して、マネージャモジュール５０２の指示に基づき、保存した稼動情報をファンクションモジュール５０１に渡す。
ハードディスクやＳＲＡＭ等の不揮発性メモリで構成される記憶装置５０８には、エラー情報やカウンタ情報の他に処理に必要な固定情報、可変情報のほか内部動作のログ、通信履歴（成功、失敗）等が設定された部門毎に分けて格納される。これにより、電源がＯＦＦされても再び電源ＯＮして際、前記格納データを読むことで前回の状態が保持される仕組みになっている。
［初期スケジュール設定について］
次に管理システム内におけるスケジュール設定処理について説明する。
【００３５】
図６は、本実施形態を示す管理システムにおけるデータ処理手順の一例を示すフローチャートである。本例は、部門管理を行う画像形成装置を初めて設置する際、または運用中にスケジューリングの変更処理（以降、再スケジューリング処理と称す）を行う際のスケジュール設定およびスケジュール送信の処理例である。
【００３６】
ここで、Ｓ６０１〜Ｓ６０６は管理装置１００のＣＰＵ２０１がＲＡＭ２０２に制御プログラム、上記モジュールをロードして実行することで実現される。また、Ｓ６１０〜Ｓ６１４は画像形成装置１０４〜１０６のＣＰＵ３０１がＲＡＭ３０２制御プログラム、上述したモジュールをロードして実行することで実現される。
【００３７】
なお、管理装置１００によるスケジュール設定手順には以下の２通りの場合においてそれぞれ異なる設定手順が想定される。１つには、現場に設置した画像形成装置の情報が管理装置１００に登録されていない状態で画像形成装置１００がスケジュール取得要求を行う場合である。もう１つには、事前に管理装置１００に設置する画像形成装置が登録された状態で、現場に設置された画像形成装置よりスケジュール取得要求を行う場合である。
【００３８】
ここで、後者の場合は、新たに設置された画像形成装置を利用するユーザが特定でき、そのユーザが利用する他の画像形成装置を把握できる。そこで、管理装置１００は、スケジュール取得要求をしてきた画像形成装置に対して、そのほかの画像形成装置とスケジュール設定を同じ、または近い時間で設定することができる。これにより、同じユーザ環境にある画像形成装置からの稼動情報などがほぼ同一のタイミングで取得できるようになる。
【００３９】
一方、前者の場合は、どのユーザが利用する画像形成装置であるかを特定することができない。そこで、管理装置１００は既に設置されている画像形成装置のスケジュール設定に基づき、稼動情報の送信スケジュールがバラけるようなスケジュール設定するように画像形成装置に応答する。これにより、関連性のない画像形成装置に対して同じスケジュール設定をすることによる、無駄な通信負荷が発生する可能性を低減できる。ここでは、同じユーザ環境に設置された画像形成装置であっても、一部の画像形成装置は朝、残りの画像形成装置は夕方に稼動情報を送信するような状態が起こり得る。
次に、管理装置１００と画像形成装置１０４におけるスケジュール設定の流れについて説明する。
【００４０】
管理装置１００では、画像形成装置１０４からスケジュール要求がなされるのを待っている。これは、図１に示す管理システムがゲートウエイ１０３により管理装置１００から直接、画像形成装置１０４に対してファイヤーウォールを越えて通信を行うことが困難となる構成のためである。
よって、Ｓ６１０で、画像形成装置１０４は管理装置１００に対してスケジュール設定を取得するための要求を送信する。具体的には、図５に示したクライアントモジュール５００が取得要求を管理装置１００に出力する。ここでは、クライアントモジュール５００からマークアップ言語に基づくデータが出力される。
【００４１】
ここで、管理装置１００での初回のスケジュール設定に関して、設定を要する画像形成装置の台数が多ければ、例えばデバイスＩＤの番号順に所定台数ずつグルーピングして、暫定的に画像形成装置に対して設定を行うことが考えられる。これにより、画像形成装置で管理する稼動情報を管理装置１００に送信できるようにする。
【００４２】
このようにして、一度、画像形成装置に対して、稼動情報を管理装置１００に送信するためのスケジュール設定が行われると、画像形成装置は定期的に管理装置１００に対し稼動情報を送信する。この際、画像形成装置は、稼動情報の送信に合わせて、当該稼動情報を送信するためのスケジュール設定の変更や変更が必要か否かの問い合わせを行う。スケジュールの変更処理などについては後述する。
【００４３】
管理装置１００では、画像形成装置１０４からのスケジュールを取得するための要求を待っており、Ｓ６０１で、クライアントモジュール４００を介してスケジュール取得の要求を受信すると、Ｓ６０２に進む。そして、Ｓ６０２で、要求を行った画像形成装置１０４に関する登録情報を検索する。具体的には、管理部４０５が処理ロジック４０３を用いてデータベース４０４内で管理される画像形成装置の情報及びそのスケジュール設定の検索を行う。
次に、Ｓ６０３で、Ｓ６０２の検索で取得した情報より、画像形成装置１０４に対してスケジュール設定を実施するか否かを管理部４０５が処理ロジック４０３を用いて決定する。
【００４４】
ここで、スケジュール設定を行う必要がない場合がある。例えば既にスケジュール設定が過去に行われていて、かつ設定の変更が必要ない場合や、スケジュール更新処理の機能が無効にされている場合である。ここで、スケジュール更新処理の機能を有効（オン）または無効（オフ）とするための再スケジューリングフラグは、管理部４０５により管理されている。
Ｓ６０３において、管理部４０５がスケジュール設定の変更を実施すると判断した場合、Ｓ６０４へ進む。そして、Ｓ６０４で、管理部４０５がデータベース４０４に予め格納されているスケジュール設定を、画像形成装置１０４に設定するための送信情報を生成する。
【００４５】
次に、クライアントモジュール４００は、生成された送信情報を画像形成装置１０４に送信し、Ｓ６０５で、送信が成功したか失敗したかを制御マネージャ４０２が判断する。ここで、制御マネージャ４０２が画像形成装置１０４より受信成功の応答を受信したと判断した場合は、本処理を終了する。
一方、Ｓ６０５で、受信失敗の応答を受信、または通信異常等で応答を受けられなかったと制御マネージャ４０２が判断した場合は、Ｓ６０６へ進む。そして、Ｓ６０６で、管理部４０５は処理ロジック４０３を用いて、スケジュール設定のための情報の送信が失敗したことをデータベース４０４に記録して、本処理を終了する。
【００４６】
一方、画像形成装置１０４では、Ｓ６１０で実行されたスケジュール取得要求に対する管理装置１００からの応答を待っている。
そして、Ｓ６１１で、あらかじめ設定されているタイムアウト時間内にスケジュールの設定を管理装置１００から受信しているかどうかを管理部５０９が処理ロジック５０３を用いて判断する。ここで、処理タイムアウト時間内にスケジュールの設定情報を管理装置１００から受信していると管理部５０９が判断した場合は、Ｓ６１２へ進む。
【００４７】
そして、Ｓ６１２で、管理部５０９は、画像形成装置１０４の記憶装置５０８にスケジュール設定を記憶する。そして、Ｓ６１３で、管理部５０９は、ファンクションモジュール５０１、クライアントモジュール５００を介して管理装置１００に対しスケジュール設定の受信結果を応答し、本処理を終了する。
なお、画像形成装置１０４は、応答は受信の成功だけでなく、失敗を管理装置１００に対して通知することもある。
一方、Ｓ６１１で、管理装置１００からのスケジュール設定を時間内に受信できなかったと管理部５０９が処理ロジック５０３を用いて判断した場合は、Ｓ６１４へ進む。そして、Ｓ６１４で、管理装置との通信に異常があったことを記録するため、通信テストにおいて失敗した際の処理を実行して、本処理を終了する。
【００４８】
図６で説明した処理により、管理システムの運用が開始され、実際に部門カウンタの情報をはじめとする稼動情報が送信され始める。これにより、実際の稼動状況を、管理装置１００がデータベース４０４に格納する部門カウンタを集計することで判断することができる。
ここで、画像形成装置の設置時に登録されている部門ＩＤに対応する部門カウンタの情報は、利用者の都合によりまったく変化しなかったりする。例えば、部門ＩＤを利用するユーザが、そのＩＤを登録した画像形成装置を利用できない場所にいる、または画像形成装置の移動により利用されない部門ＩＤが残るなどにより部門カウンタの情報が変化しないことがある。
また、画像形成装置において、新たな部門ＩＤが追加され、あるときから新しい部門ＩＤに対応する部門カウンタの情報が送信され始めることもある。
【００４９】
そこで、以下に示す運用における部門カウンタ監視処理、再グルーピング判断処理を繰り返すことで、管理装置１００の監視対象の画像形成装置に対するスケジュール設定の見直しが必要か否かを管理装置１００が判断する。本実施例においては、同じグループにグルーピングした画像形成装置に対しては同じ、ほぼ同時刻のスケジュール設定が行われる。管理装置１００の判断に基づき、再グルーピングや再スケジューリングを実行することで、通信負荷も考慮した上で、適切な部門カウンタの集計を行えるようなる。
［運用における部門カウンタ監視処理］
次に、管理装置１００がスケジュール設定に基づき各画像形成装置１０４〜１０６から送信される部門カウンタを含む稼動情報を受信し、その受信データを監視する処理について説明する。
【００５０】
図７は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、部門管理を行う画像形成装置に対する再スケジューリング処理を行う際の処理例である。ここでは、例えば所定のタイミングで管理装置１００が定期的にスケジューリングの見直しを行うことが考えられる。ほかにも、定期的な稼動情報の受信とともに画像形成装置から送信されてくるスケジュール設定に関する問合せに応じたタイミングで、本処理が行われることも考えられる。
なお、Ｓ７０１〜Ｓ７１１で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
まず、Ｓ７０１で、まず、制御マネージャ４０２は、画像形成装置に対する稼動情報の送信スケジュールの再設定（再スケジューリング）処理を自動で行うかどうかを判断する。具体的には、ＲＡＭ２０２上で管理されている再スケジューリング実施有無のフラグがオン（１）になっている場合に、再スケジューリング処理が自動で行われると判断される。
【００５１】
ここで、再スケジューリング実施有無のフラグがオフ（０）になっている際には、再スケジューリング処理が自動で行われないと判断され、以降の処理は行われずに、本処理を終了する。
なお、再スケジューリング実施有無のフラグをオフ（０）とするのは、元々部門管理を実施する予定がない、または１台、もしくは極めて少数の画像形成装置の設置のみである場合などに対処できるよう用意されている。
【００５２】
一方、Ｓ７０１で、再スケジューリング実施有無のフラグがオン（１）になっている際には、再スケジューリング処理が自動で行われると判断され、Ｓ７０２に進む。
そして、Ｓ７０２で、前回の本処理を行った時から稼動情報を画像形成装置１０４から受信しているかどうかを管理部４０５が判断する。なお、この判断は、稼動情報が受信された直後に行われてもよいし、特に稼動情報の受信タイミングに依存しないタイミングにおいて行われてもよい。
【００５３】
なお、Ｓ７０２で、管理装置１００は、前回の本処理を行った時から稼動情報を受信できていない場合（いいえ）は、受信するまで待機する。稼動情報を画像形成装置１０４から受信している場合は、Ｓ７０３に進む。
Ｓ７０３で、画像形成装置から受信した稼動情報における部門カウンタの情報について、すでにデータベース４０４に登録されている部門ＩＤと全て一致するかを管理部４０５が判断する。すべての部門ＩＤが一致したと管理部４０５が判断した場合は、Ｓ７０４に進む。
【００５４】
Ｓ７０４で、管理部４０５は、受信した部門カウンタの情報をデータベース４０４に格納し、Ｓ７０５へ進む。そして、Ｓ７０５で、管理部４０５が前回受信した各部門カウンタの値からの増加分を算出して、増加カウントの値としてデータベース４０４に格納する。
次に、Ｓ７０６で、処理ロジック４０３が現在処理中の部門ＩＤを有する画像形成装置の総カウンタに対する、部門カウンタの増加数を比較して、増加数が閾値（既定値）未満であるかどうかを判断する。具体的には、画像形成装置で３００００枚／月に印刷しているにもかかわらず、ある部門ＩＤの利用が２枚／月だったとした場合、増加なしと見なして再スケジューリング処理を行うためである。
実際の閾値はデータベース４０４の図８（Ｂ）に示すスケジューリング更新パラメータを管理するテーブルに格納されており、システムの運用状況に合わせて管理者が変更することが可能である。
【００５５】
ここで、処理ロジック４０３は、増加閾値を判断するための最大値と増加閾値パラメータ（％）を用いて、増加閾値判断用の最大値×増加閾値パラメータ（％）を算出する。この値が増加なしと判断するカウンタ増加値に対応する。図８の詳細に関しては後述する。
Ｓ７０６で、閾値未満と判断された場合、すなわち、部門カウンタの値にほとんど増加がみられないと管理部４０５が判断した場合、Ｓ７０８に進む。なお、画像形成装置において１枚も印刷しない場合、つまり部門カウンタの値に変化がなかった場合のみを識別したい場合、増加閾値をゼロとすればよい。
そして、Ｓ７０８で、そのＳ７０６でカウンタの値にほとんど増加がみられなかった部門ＩＤを、後述するグルーピング処理における判断対象から削除するため、判断対象フラブを無効に設定する。
一方、Ｓ７０６で、増加閾値を超えていると管理部４０５が判断された場合は、Ｓ７０７で、管理部４０５が前回再スケジューリング処理を実施した時から予め指定された期間が経過していないかを判断する。この判断ステップは、受信する部門カウンタの情報に対応する部門ＩＤに変更なく、稼動情報の受信が続く場合においても、一定期間経過後にスケジューリング処理を自動で行うためのものである。
【００５６】
ここで、指定期間が経過していないと管理部４０５が判断した場合は、Ｓ７０１に戻る。これは、まだグルーピングなどを見直すべきタイミングではないためである。
一方、Ｓ７０７で、指定期間が経過したと管理部４０５が判断した場合は、図９などで後述するような再スケジューリングに関する処理へ進む。
なお、本実施形態では、Ｓ７０７における指定期間を任意に指定可能とし、早期にスケジューリングに関する処理の行うよう指定期間を短く設定することも可能である。
一方、Ｓ７０３で、受信した稼動情報に含まれる部門カウンタの部門ＩＤが、すでに格納されている部門ＩＤと一致しないと判断された場合は、Ｓ７０９に進む。
【００５７】
ここで、管理部４０５は、全ての部門ＩＤにおいて一致しなければ、部門ＩＤの追加、または削除が行われたことになる。具体的には、画像形成装置側で新規に登録された部門ＩＤに対応する部門カウンタの情報が送信されたか、または画像形成装置側で部門ＩＤが削除され送信されなくなったといった場合を示す。
Ｓ７０９では、管理部４０５が新たに部門ＩＤを追加するとともに、受信した部門カウンタの情報をデータベース４０４に格納する。
【００５８】
これに対して、部門ＩＤが削除されている（減っている）と判断された場合、部門ＩＤの判断対象のフラグを無効に設定し、後述する再スケジューリング処理などの対象から外すようにする。なお、集計には必要なので、すでに格納している部門カウンタの情報は残すものとする。
次に、Ｓ７１０で、管理部４０５が前回受信した部門カウンタの値からの増加分を算出して、データベース４０４に格納する。また、管理部４０５は、新たな部門ＩＤに対応する部門カウンタにおいては、データベース４０４に新たに管理用の項目を追加して、今回受信した部門カウンタの値を増加分として格納する。
そして、Ｓ７１１で、管理部４０５は、新しい部門ＩＤの部門カウンタに関して、判断対象フラグを有効にして、図９に示すグルーピング処理に進む。
【００５９】
図８は、図４に示したデータベース４０４で管理されるテーブルの一例を示す図である。
図８（Ａ）は、ある画像形成装置の部門カウンタの情報を管理するテーブルである。具体的には、画像形成装置の識別情報としての機番、その画像形成装置に適用されているスケジュール設定、その画像形成装置に関して登録されている部門ＩＤとその値（日毎）などが管理される。
また、本テーブルでは、部門ＩＤごとにグルーピングの際に処理対象とするかを判断する判断対象フラグや、前回受信時からの増加分を示す増加カウントや、画像形成装置がどのグループに属しているかを示す情報を管理する。
【００６０】
判断対象フラグには、グルーピング処理の際に、この部門ＩＤに対応する情報を判断に用いるか否かの情報が格納される。
増加カウント欄には、再スケジュール処理の実施時から、増加した分のカウンタの値が格納される。この増加カウントは、図８（Ｂ）に示す期間経過後などに参照され、この部門ＩＤがユーザに利用されているか否かの判断に利用される。
【００６１】
グループ欄には本実施例におけるグルーピング処理によって設定されるグループ情報が格納される。具体的には、図１３以降に示すＧ０１、Ｇ０２、Ｇ０３、・・・としている。ここで、グループ情報を、Ｇ０１＝Ｇ０３として同じスケジュール設定を行うことも可能である。
図８（Ｂ）は、スケジューリング更新パラメータを管理するテーブルである。
本テーブルでは、自動でスケジューリングを行う否かを決定する際のスケジューリング実施有無を決定するフラグと、部門カウンタの増加傾向を判断する上でのベースとなる期間を格納する期間を管理する。さらに、スケジュールの再設定の対象となり得る、ほとんど利用されていない部門ＩＤを検出するための最大値（枚）、増加閾値（％）も管理している。
【００６２】
ここでは、期間は、定期的にスケジューリングを見直すためのパラメータで、初期値として、７２０日（或いは３０日）が設定されている。最大値（枚）及び増加閾値（％）は、所定期間において画像形成装置で特定の部門ＩＤが利用されていないとみなす際の判断に使用する。
図８（Ｃ）は、１グループに登録可能な画像形成装置の最大台数を管理するテーブルである。全部門ＩＤが共通する画像形成装置であっても、この設定台数までしか同じグループに登録されない。これは、あまりにも多い台数に対して、同じスケジュール設定が適用されてしまうことを避けるためである。
【００６３】
この上限の設定により、部門ＩＤが共通する複数の画像形成装置の中で同時刻のスケジュール設定ができない画像形成装置がでてくる。しかし、上限設定により分割して別のグルーピングされたということも判別できるため、それぞれのグループのスケジュール設定を近い時刻にすることが可能である。
［グルーピング処理］
次に図９を用いて画像形成装置のグルーピング処理について説明する。
【００６４】
図９は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、各画像形成装置から受信した部門カウンタの情報などをもとに、現在の画像形成装置のグループが適切かを見直す処理例である。なお、Ｓ８０１〜Ｓ８１４で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
【００６５】
Ｓ８０１で、管理部４０５は、本処理の基準とする対象画像形成装置（例えば画像形成装置１０４〜１０６のいずれかに該当する）を設定する。ここで、対象画像形成装置の決定に関しては、とくにその順番は問わない。
次に、Ｓ８０２で、管理部４０５は、本処理の対象となる部門ＩＤの範囲（本実施形態では、説明上、部門Ｎｏ.Ｘ〜Ｙとする）を抽出する。
【００６６】
Ｓ８０３において、管理部４０５が、Ｓ８０２で抽出した部門ＩＤの中の１つ部門ＩＤ（例えば、部門Ｎｏ．Ｘ）が他の画像形成装置の登録情報に存在するかを、データベース４０４を検索し、確認する。ここでは、管理装置１００の管理対象の画像形成装置として、データベースに登録されている画像形成装置の情報に対する検索が行われる。また、画像形成装置の登録情報に部門ＩＤが存在する場合とは、定期的にその画像形成装置からその部門ＩＤに対応する部門カウンタの情報を受信していることになる。
そして、登録情報にその部門ＩＤを含む画像形成装置のリストを作成する。このとき、管理部４０５は、データベース４０４上で確認された部門ＩＤに対して判断対象フラグが無効に設定されていた場合、その画像形成装置に関してはリスト登録の対象としないものとする。
【００６７】
次に、Ｓ８０４で、管理部４０５が、Ｓ８０３で作成したリストをもとに、同じ部門ＩＤに対応する部門カウンタの情報を送信してきた画像形成装置として、同じグループ番号を割り当てる。そして、Ｓ８０５で、管理部４０５は、画像形成装置は既にグループ番号が割り当てられていること（グルーピング済み）を示す処理済フラグを有効にする。
そして、Ｓ８０６で、管理部４０５は、処理対象の部門ＩＤの全てに対してＳ８０３〜Ｓ８０５の処理を行ったかを判断する。例えば、処理対象の部門ＩＤがＳ８０２で抽出した最後の部門ＩＤ（部門Ｎｏ．Ｙ）と一致するかをチェックする。
【００６８】
Ｓ８０６で処理対象の部門ＩＤの全てに対してＳ８０３〜Ｓ８０５の処理を終了したと判断された場合は、Ｓ８０７へ進む。一方、Ｓ８０６で、未処理の部門があると判断された場合は、Ｓ８１０へ進み、未処理の部門ＩＤを処理対象とし、Ｓ８０３へ戻る。
Ｓ８０７で、前回のグルーピングされた時点からグループ番号に対応する画像形成装置のリストに変更があるかどうかを管理部４０５が判断する。ここで、管理部４０５が変更なしと判断した場合、再スケジューリングする必要がないとして、Ｓ８０８に進む。一方、管理部４０５が変更ありと判断した場合、Ｓ８１１に進む。
【００６９】
そして、Ｓ８０８で、管理部４０５は、データベース４０４で管理されるテーブル上で、グルーピング処理に関して処理済みフラグが無効となっている画像形成装置が存在するか否かを判断する。Ｓ８０８で存在すると判断された場合は、Ｓ８０９で、処理済みフラグが無効となっている画像形成装置を次の処理の基準とすべき対象画像形成装置に設定し、Ｓ８０２に戻る。
一方、Ｓ８０８で存在しないと判断された場合は、図１０を用いて後述するグループの分割処理に進む。
【００７０】
Ｓ８１１では、管理部４０５が対象画像形成装置に割り当てたグループ番号に対応するグループが、前回グルーピング処理時に分割され、後述する近似スケジュールの設定がされたか否かを判断する。なお、グループの分割や近似スケジュールに関する処理については図１０において後述する。
ここで、近似スケジュールの設定がされていたと判断された場合は、Ｓ８１２で、管理部４０５は、近似スケジュールの設定がなされていて、かつ画像形成装置のリストに変化のないグループを抽出する。
【００７１】
次に、Ｓ８１３で、対象画像形成装置のグループ番号を、Ｓ８１２で抽出したグループに対して割り当てる。これは、前回近似スケジュールされた各グループの画像形成装置の全てを今回の再グルーピングの対象とするための処理である。
最後に、Ｓ８１４で、管理部４０５は、データベース４０４で管理されている該当グループの再スケジューリングフラグをオンにし、Ｓ８０８に進む。
【００７２】
一方、Ｓ８１１で、当該グループが近似スケジュールのグループでないと管理部４０５が判断した場合、Ｓ８１４でそのグループのみの再スケジューリングフラグをオンにし、Ｓ８０８に進む。
［グループの分割について］
次に、図９で説明したグルーピング処理において、１グループに属する画像形成装置の数が一定数を超えている場合に、複数のグループに分割するようにグルーピングする処理を行う。
【００７３】
図１０は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、上述したグループに登録可能な上限台数を超えているか否かを判断する処理に関する例である。なお、Ｓ９０１〜Ｓ９０５で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
【００７４】
Ｓ９０１で、図９に示した一連のグルーピング処理が完了後に、管理部４０５は、そのグループに割り当てられた画像形成装置の台数が上限未満であるかを判断する。これは、ネットワークの負荷を抑えるとともに、管理装置１００における部門カウンタの情報の登録処理などの負荷を抑えるための処理となる。
ここで、１グループに割り当てられた画像形成装置の台数が上限を超えていないと管理部４０５が判断した場合、分割処理を行わないで、図１１に示すスケジューリング処理に進む。
【００７５】
一方、Ｓ９０１で、上限を超えている（上限以上）と処理ロジック４０３が判断した場合、同一グループ内に含まれる一部の画像形成装置を別のグループに割り当てる必要があるため、Ｓ９０２に進む。
そして、Ｓ９０２で、管理部４０５は、グループを分割する数を算出する処理を行う。一例として、グループに登録されている台数と上限台数との商をもとめ、剰余がない場合は商を、剰余がある場合は商に１を加算した値を分割数とし、Ｓ９０３に進む。
【００７６】
そして、Ｓ９０３で、管理部４０５は、分割数から１を引いた数だけ新たにグループ番号を生成し、更にＳ９０４で、管理部４０５は、Ｓ９０３で生成したグループ番号を、上限数で分割された夫々のグループに割り当てる。
次に、Ｓ９０５では、管理部４０５は、分割されてしまった各グループに対し、近い時刻にスケジュール設定されるようにで近似スケジュール指定を行い、図１１に示すスケジューリング処理に移行する。
【００７７】
これにより、同一のグループとして管理されるべき画像形成装置群が、上限設定により分割されても、大きく異なる時刻でのスケジュール設定がされなくなる。
［スケジューリングについて］
以下、再スケジューリング処理について説明する。
【００７８】
図１１は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、再スケジューリングのフラグに基づき、必要な画像形成装置に対してスケジュール設定を行う処理例である。なお、Ｓ１００１〜Ｓ１００４で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
まず、Ｓ１００１で、管理部４０５は、再スケジューリングのフラグが有効になっているグループがあるかを判断する。ここで、グルーピング処理の結果により再スケジューリングの対象グループがないと管理部４０５が判断した場合、本処理を終了する。一方、Ｓ１００１で、再スケジューリング対象のグループがあると管理部４０５が判断した場合は、Ｓ１００２へ進む。
【００７９】
Ｓ１００２で、管理部４０５は、再スケジューリング対象のグループの含まれる画像形成装置に対して、前回設定されていたグループ番号と異なるかを判断する。
ここで、前回と同じグループ番号が設定されていると管理部４０５が判断した場合、前回からスケジュール設定を変更する必要がないため、本処理を終了する。一方、Ｓ１００２で、異なるグループ番号が設定されていると管理部４０５が判断した場合、該当するグループの再スケジューリングを行うためＳ１００３に進む。
【００８０】
ここで、異なるグループ番号が設定される理由を以下にまとめる。
（１）グルーピング処理に際して、前回のグループに新しい画像形成装置が追加され上限台数を超えると、別のグループ番号でグルーピングされた場合
（２）グルーピング処理に際して、前回から所属していたグループから外され、新たなグループ番号が割り当てられた場合
【００８１】
（３）新しく追加された画像形成装置などであって、前回から管理されていた部門ＩＤを一切含まず、新規のグループ番号が割り当てられた場合
Ｓ１００３では、処理ロジック４０３は、再スケジューリング対象となるグループに対してのスケジュール設定のための時刻などの情報を決定する。このとき、分割処理により、近似スケジュール指定の対象となる複数のグループ対に対しては、１０〜３０分ずらして時刻を決定するなど、部門カウンタの情報の取得時刻が近くなるようにセットする。
【００８２】
なお、近似スケジューリングで設定されるグループ間の送信スケジュールの時間間隔（第２の時間間隔）は、通常の再スケジューリングにおいて設定される時間間隔（第１の時間間隔）よりも十分に短いものとなる。また、ここでの通常の再スケジューリングにおいて設定される時間間隔（第１の時間間隔）は、通信負荷の分散などを十分考慮し、例えば１〜２時間ずらした時刻が決定されるようにするものとする。また、近似スケジュールに関しては、自動で所定間隔ずらして送信スケジュールの時刻を決定するようにし、それ以外の通常の再スケジューリングに関しては管理者からの指示を受けることで決定するようにしてもよい。
そして、Ｓ１００４で、再スケジューリング対象となるグループに含まれる画像形成装置に対して、決定された新しいスケジュール設定を行うための情報を送信することで再スケジューリングを行い、本処理を終了する。先に説明したようにスケジュール設定は、画像形成装置より要求に応じて行われるため、新しいスケジュール設定の反映はそのタイミングで行われる。よって、ここでは新たなスケジュール設定を各画像形成装置の登録情報に対応させて管理し、画像形成装置の要求を待機するといったことが行われる。画像形成装置側では、受信した情報を解析し、自身でスケジュール設定を更新することになる。
［集計表示］
【００８３】
図１２は、図２に示した表示部２０７に表示されるユーザインタフェースの一例を示す図である。本例は、図４に示したデータベース４０４に格納されている部門カウンタの情報を元に集計した部門集計画面例である。
なお、本画面は、ネットワーク上の情報処理装置（ＰＣ１０）が備えるブラウザを介して、管理装置１００に用意されるＷＷＷサーバにアクセスすることで、ＰＣ１０上で表示することが可能である。
なお、図１２において、１２０６は部門管理している画像形成装置全ての総計表示枠を示している。１２０７は部門１（Ｄｅｐａｒｔｍｅｎｔ１）を登録している全画像形成装置の総計表示枠を示している。
【００８４】
図１２に示す部門集計画面１２０１において、１２０５は集計期間を設定する集計期間指定フィールドである。１２０２はデータの存在する部門ＩＤ表示フィールドである。１２０３はカウンタ総計フィールドで、部門ＩＤフィールド１２０２のカウンタごとの総計数を表示する。１２０４は遷移ボタンで、多くの部門ＩＤが存在する場合複数画面に分割して表示する際、次頁への遷移を行う場合に押下される。
【００８５】
カウンタ総計フィールド１２０３には、集計期間指定フィールド１２０５で指定された範囲において集計した複数の画像形成装置より送信されてきた各部門カウンタの情報が表示される。ここで、一例として９台の画像処理装置を表示した例である。
いままで説明してきた再スケジューリング処理によって、ここで集計対象となる画像形成装置の送信時刻はほぼ一緒であるため、期待する集計結果が得られることになる。
［運用における部門カウンタ受信例の説明］
【００８６】
図１３〜図１９は、前述した本実施形態を示す管理装置における各画像形成装置に対するスケジュール設定を説明するための図である。
図１３は、画像形成装置から最初の部門カウンタの情報を受信した後の管理テーブルを示す図である。本例は、複数の画像形成装置（Ｄｅｖ１、Ｄｅｖ２、Ｄｅｖ３、・・・、Ｄｅｖ１０）から部門カウンタが送信されてきたことを表している。
【００８７】
このように初期スケジューリング時には、画像形成装置ごとにまちまちにスケジューリングされる。この例では、同一顧客ということで、画像形成装置Ｄｅｖ１〜Ｄｅｖ１０まで同じスケジューリングにすることはできるが、同一顧客の回線においてトラフィックが集中する可能性もあり好ましくない。このため、ばらつきをもたせてスケジュール設定している。
図１４は、はじめて画像形成装置が設置されたときの初期スケジューリングの状態を想定している。ここで、１３００は画像形成装置の設置後、各画像形成装置のスケジュール設定に基づき、各画像形成装置からの部門カウンタ情報をはじめて受信したとき状態を示している。
【００８８】
本例は、複数の画像形成装置（Ｄｅｖ１、Ｄｅｖ２、Ｄｅｖ３、・・・、Ｄｅｖ１０）から部門カウンタの情報が送信されてきたことを表している。
また、１３０１は送信されてきた部門ＩＤに対して作成されるカラムであり、本例では部門ＩＤが１〜６、５０〜５３、９７〜１００、２００〜２０２に対して部門カウンタの情報が格納されていることを表している。
本実施形態では、設置後、最初にどのような部門カウンタの情報が各画像形成装置から送信されるのか特に把握する必要はないように管理装置１００は構成されている。
【００８９】
図１４においてカウンタ情報に対して網掛けされているのは、それぞれの取得スケジュール設定を識別しやすくするためである。ここでは、画像形成装置Ｄｅｖ１、Ｄｅｖ２、Ｄｅｖ４が同じスケジュール設定が行われている。また、それとは別にＤｅｖ３、Ｄｅｖ１０にはそれぞれ異なるスケジュール設定が行われている。さらに、ほかの画像形成装置とは異なるスケジュール設定がＤｅｖ８、Ｄｅｖ９は同様に行われていることを表している。
次に、図１５を用いて上述した再グルーピング処理結果を反映した表示処について説明する。
【００９０】
運用が進むと、各画像形成装置から図１４に示した部門カウンタの情報の受信状況から、各画像形成装置でどの部門ＩＤがどの程度利用されているのかが特定できる。
図１５ではグループ処理に基づき、部門ＩＤ１〜６を有する画像形成装置Ｄｅｖ１のグループ番号Ｇ０１に対し、他の画像形成装置から同じ部門ＩＤ１〜６が送信されてこないのでＤｅｖ１はＧ０１のまま、部門１〜６は、枠１４０１に示すように、図１４に示したスケジュール設定と同一のスケジュール設定値を据え置く。
一方、画像形成装置Ｄｅｖ２、Ｄｅｖ３、Ｄｅｖ４、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０はそれぞれで同じ部門ＩＤを有していることから、枠１４０２に示す画像形成装置に対してグルーピング処理を実行する。
【００９１】
グループ番号Ｇ０１であったＤｅｖ２とＤｅｖ４はＧ０１グループでなくなることで、再スケジューリングの対象となるとともに、他の共通する部門ＩＤを有する画像形成装置と同じグループ番号Ｇ０２が適用されるために、同じスケジューリング設定が行われる。なお、図１５において、部門１〜６はＤｅｖ１しか使用していないので、他の画像形成装置と異なるグループとしている。
【００９２】
ここで、例えばＤｅｖ１は部門１〜４９までの部門ＩＤを利用し、Ｄｅｖ１１が部門９００〜１０００までの部門ＩＤを利用する際に、他の画像形成装置に比べどちらも利用する部門ＩＤの数が極端に多いとする。本実施形態では詳細に説明していないが、そういった場合は、Ｄｅｖ１とＤｅｖ１１を別のグループにすることも可能である。
また、Ｄｅｖ１が部門１〜６まで、Ｄｅｖ１１が部門９００〜９１０までの部門ＩＤを利用する際には、他の画像形成装置に比べ特に利用する部門ＩＤの数が多くないとして、Ｄｅｖ１とＤｅｖ１１が同じ部門ＩＤを利用していないにもかかわらず、同一のグループと定義したりすることも可能である。これにより、グループ数が増加しすぎることを抑制できる。
【００９３】
次に、図１４〜図１８を用いて部門カウンタがこなくなる、または画像形成装置側で削除された場合について説明する。ここで運用初期は、図１３で説明した状態とする。その後、図１４，図１５に示す状態で上述したグルーピング処理および再スケジューリング処理が実施される。
しかし、運用状況が変わり、特定の部門ＩＤのカウンタ値が増えなくなる、もしくは部門ＩＤが画像形成装置側で削除されることで、その情報が送信されなくなる場合がある。
【００９４】
図１６は、画像形成装置Ｄｅｖ３、Ｄｅｖ４で、一部の部門ＩＤのカウンタ情報が増加しなくなる、または増加の条件を満たさなくなったことを示している。図１６では、画像形成装置Ｄｅｖ３の部門ＩＤ２００、２０１、２０２と、Ｄｅｖ４の部門ＩＤ９７，９８，９９，１００の部門カウンタが増加しなくなったと状態を示している。
これにより、前回までのグループの見直し処理が行われる。ここでは、Ｄｅｖ３の部門２００〜２０２、Ｄｅｖ４の部門９７〜１００がグルーピング判定処理の対象から外れることになる。
前回までのグループ番号０２で示すグループに含まれる画像形成装置は、Ｄｅｖ２、Ｄｅｖ３、Ｄｅｖ４、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０であった。図１６においては、その後の運用状況に合わせて、画像形成装置Ｄｅｖ２、Ｄｅｖ４がグループ番号０２となる。そして、残り画像形成装置Ｄｅｖ３、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０がグループ番号Ｇ０３で示す新たなグループに含まれ、新たなスケジュール設定１５０２が適用される。
【００９５】
図１６では、部門カウンタの情報が増加しなくなった場合について述べたが、部門ＩＤ自体が削除された場合も同様な処理が行われることになる。
図１７は、図１５に示したスケジュール設定が行われた後、画像形成装置Ｄｅｖ４の部門ＩＤ９７，９８，９９，１００の部門カウンタが削除された状態を枠１６０１で示す。
【００９６】
この場合も、図１６と同じように、画像形成装置Ｄｅｖ２、Ｄｅｖ４が同じグループ（グループ番号Ｇ０２）となる。そして、画像形成装置Ｄｅｖ３、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０がそれとは別のグループ（グループ番号Ｇ０３）にグルーピングされる。ここで、グループ番号Ｇ０３で示すグループに属する画像形成装置に対しては、図１８に示す通りスケジュール設定１７０１が新たに行われる。
図１９に示すテーブルでは、１８０１で示すように画像形成装置（Ｄｅｖ１１）が新規に登録された状態を示している。ここでは、再スケジューリング処理が必要であるかを判断する処理について説明する。
【００９７】
ここでは、新規登録の画像形成装置が利用する部門ＩＤに対して、前回までに他の画像形成装置において利用され、登録されている部門ＩＤと重複するかを確認することになる。ここでまったく重複が無い場合は、新たにグループを生成し、スケジュール設定を行うか、もしくは管理しているグループの中で極端にそのグループに属する画像形成装置が少ないグループがあればそのグループに登録するようにしても良い。また、新規登録の画像形成装置が利用する部門ＩＤと１つでも重複する場合は、どの画像形成装置と同じスケジュール設定を行うべきかを判断することになる。ここでは、前述したようにグループの上限台数などが考慮され、グルーピングされ、そのグルーピングされたグループに対して適切なスケジュール設定が行われる。
【００９８】
図１９では、新規登録された画像形成装置Ｄｅｖ１１が、前回までで管理していたグループ番号Ｇ０２で示すグループに登録され、スケジュール設定された状態を示している。
本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン等の処理装置（CPU、プロセッサ）にて実行することでも実現できる。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。
【符号の説明】
【００９９】
１００ 管理装置
１０１ ネットワーク、インターネット
１０３ ゲートウエイ
１０４，１０５，１０６ 画像形成装置
【技術分野】
【０００１】
本発明は、ネットワークに接続される複数の画像形成装置を管理する管理装置に関するものである。
【背景技術】
【０００２】
ネットワーク上に配置された監視サーバ及びプリンタを管理する印刷ログ管理サーバが特許文献１に開示されている。
具体的には、特許文献１では、監視サーバの構成変更が生じたとき、印刷ログ管理サーバは、各グループＡ，Ｂに属する複数のプリンタａ〜ｎの監視サーバａ，ｂの監視一覧画面を表示させる。そして、この表示画面上で、監視サーバａ，監視サーバｂが監視対象とするプリンタの印刷ログに基づく情報を表示する。この表示に基づいて、監視サーバａ，ｂが監視すべきプリンタの設定を行う。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−３１０４６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方、部門管理機能を有する複数の画像形成装置の稼動情報に基づき部門管理を行う場合、実際の運用では同じ部門ＩＤを複数の画像形成装置に登録し、ユーザは複数の画像形成装置を利用できるような形態を採用する場合がある。ここで、画像形成装置はプリンタ、複写機、及び複合機などを含むものとする。また、稼動情報は、印刷の度にカウントアップされる印刷枚数や印刷面数などのカウンタ情報を含む。
【０００５】
このため、各部門ＩＤに対応する部門カウンタの情報をリモートで集計する管理装置では、複数の画像形成装置から収集した部門カウンタの情報により各部門のカウンタ情報の総計を求めるなどの集計処理することができる構成を備える。
部門カウンタのデータ量は、画像形成装置に登録する部門数が増えるにつれ増加してしまうため、ネットワーク負荷の集中を避けるために各装置の部門カウンタの送信スケジュールを１〜２回／１日程度に設定している。これにより、頻繁に部門カウンタの情報を送信しないように制御している。
【０００６】
しかしながら、部門カウンタの情報の送信スケジュールをある程度分散させて設定してしまうと、管理装置で部門カウンタの情報を集計して表示する処理において問題が発生する。
例えば、管理装置が、送信スケジュールが朝（ＡＭ５：００）の１０台の画像形成装置と、送信スケジュールが夜（ＰＭ１１：００）の１５台の画像形成装置とを管理する場合を想定する。
【０００７】
ここで、管理装置上で部門カウンタの情報の集計をある日の昼（ＰＭ０：３０）に確認する際、以下のような表示されることとなる。つまり、昼（ＰＭ０：３０）の時点では、その日の朝に収集された１０台の画像形成装置の部門カウンタの情報と、その前日の夜に収集された１５台の画像形成装置の部門カウンタの情報との集計結果が表示される。
特定の日をカウンタ情報に基づき課金処理などを行うための締め日とする場合、設定されたスケジュールにより、締め日の同じ時点での各画像形成装置の部門カウンタの情報が集計結果に反映されないことになる。
【０００８】
このような問題に対して、全ての画像形成装置に対し一律で同じスケジュール設定を行う方法も考えられる。しかしながら、単純に同じ時刻でスケジューリングした場合、大手企業など大量の画像形成装置を利用するユーザにおいては、たとえば１００台単位で同じ時刻にスケジュール設定されることになる。
また、当然ながらユーザの運用により、画像形成装置の利用形態は変更される場合があり、運用の中で適切なスケジューリングになるよう適宜見直す必要がある。
【０００９】
本発明は、上記の課題を解決するためになされたものである。
そして、本発明の目的は、管理負荷とユーザの運用状況を十分に考慮した、適切な稼動情報の送信スケジュールを画像形成装置に設定できる仕組みを提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成する本発明の管理装置は以下に示す構成を備える。
複数の画像形成装置から、各画像形成装置に設定されている送信スケジュールに従い受信される部門カウンタの情報を、データベースを用いて管理する管理装置であって、画像形成装置の識別情報、当該画像形成装置から受信した部門ＩＤ、及び該部門ＩＤに対応する部門カウンタの情報を関連付けて前記データベースに登録する登録手段と、前記データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する特定手段と、前記特定手段で特定された複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する管理手段と、前記管理手段で管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する決定手段と、前記決定手段により決定された各グループの送信スケジュールを各グループに属する画像形成装置に対して設定するための情報を生成し、当該画像形成装置からの要求の応答として生成した情報を送信する送信手段とを備え、前記管理手段は、前記特定手段で特定された複数の画像形成装置の台数が上限以上の場合は、当該特定された複数の画像形成装置を複数の異なるグループで管理し、前記決定手段は、前記管理手段により前記特定手段で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理された場合、当該複数のグループ間においては前記第１の時間間隔よりも短い第２の時間間隔で送信スケジュールを決定することを備えることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、管理負荷とユーザの運用状況を十分に考慮した、適切な稼動情報の送信スケジュールを画像形成装置に設定できる仕組みを提供できる。
【図面の簡単な説明】
【００１２】
【図１】管理システムの一例を示す図である。
【図２】管理装置の構成を説明するブロック図である。
【図３】画像形成装置の構成を示すブロック図である。
【図４】管理装置のソフトウェアモジュールを示すブロック図である。
【図５】画像形成装置のソフトウェアモジュールを示す図である。
【図６】管理システムのデータ処理手順を示すフローチャートである。
【図７】管理装置のデータ処理手順を示すフローチャートである。
【図８】データベースで管理されるテーブルを示す図である。
【図９】管理装置のデータ処理手順を示すフローチャートである。
【図１０】管理装置のデータ処理手順を示すフローチャートである。
【図１１】管理装置のデータ処理手順を示すフローチャートである。
【図１２】表示部に表示されるＵＩの一例を示す図である。
【図１３】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１４】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１５】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１６】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１７】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１８】各画像形成装置の送信スケジュール設定処理を示す図である。
【図１９】各画像形成装置の送信スケジュール設定処理を示す図である。
【発明を実施するための形態】
【００１３】
次に本発明を実施するための最良の形態について図面を参照して説明する。
〔第１実施形態〕
＜システム構成の説明＞
【００１４】
図１は、本実施形態を示す管理システムの一例を示す図である。本例は、監視対象となる部門管理可能な複数の画像形成装置と、それらが画像形成装置から送信する稼動情報を受信し、管理する管理装置から構成される管理システムの例である。より具体的には、ネットワークに接続される複数の画像形成装置から取得される部門カウンタの情報を収集して管理する管理装置が、インターネット１０１、ゲートウエイ１０３、ネットワーク１０７を介して接続される例である。なお、管理装置１００と各画像形成装置は、例えばＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で相互に通信可能に構成されている。ただし、ゲートウエイ１０３はルーターやプロキシサーバー、ファイヤーウォールなどで構成される。
【００１５】
ここで、部門管理可能な画像形成装置とは、複数の部門ＩＤが登録され、印刷時などにそれら部門ＩＤごとにカウンタの情報を部門カウンタとして計数、管理する部門管理機能を有する画像形成装置である。また、複数の画像形成装置で共通する部門ＩＤが登録されて、システム運用される場合もある。
図１において、１０４〜１０６は画像形成装置で、ここでは複合機（ＭＦＰ：Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）で構成される例を示す。また画像形成装置としては、プリンタなどの単一機能周辺機器（ＳＦＰ：Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）や複写機などで構成されていてもよい。
また、インターネット１０１に接続される管理装置１００は、画像形成装置１０４〜１０６からのコマンド要求に対し、所望のデータを送信するよう指示する。また、管理装置１００は、画像形成装置１０４〜１０６から後述するスケジュール設定に従った定期的な、または不定期な、部門カウンタの情報及びエラー情報などを含む稼動情報等を受信して、データベースで管理する。なお、画像形成装置の台数には制限はない。
【００１６】
このように構成された管理システムにおいて、画像形成装置１０４〜１０６は、管理装置１００により指定されるスケジュール設定に合わせて、自身が管理するカウンタ情報、エラー情報を含む稼動情報を管理装置１００に送信する。
管理装置１００は受信した稼動情報を分類し、データベースに蓄積して管理することで、顧客に対して利用枚数に応じた課金等を行う。
画像形成装置１０４〜１０６は、登録された部門ＩＤ毎に管理される部門カウンタの情報を、管理装置１００から受信し、設定されるスケジュール設定に従い、管理装置１００に送信する。
【００１７】
この際、画像形成装置１０４〜１０６に登録されている全ての部門ＩＤに対応するカウンタ情報を管理装置１００に送信する。また、画像形成装置１０４〜１０６において、部門ＩＤが削除された場合、以降の送信時にはその部門ＩＤに関する稼動情報は一切送らない。
管理装置１００は、以前送信されていた部門ＩＤが送信されなくなることで、画像形成装置において部門ＩＤが削除されたことを把握することができる。また、管理装置１００は、稼動情報に変化の無い（カウンタ情報がカウントアップされていない）部門ＩＤを特定することで、画像形成装置でまったく利用されていない部門ＩＤが存在することを把握することができる。
［管理装置１００の構成］
【００１８】
図２は、図１に示した管理装置１００の構成を説明するブロック図である。管理装置１００は、以下に示すハードウエア資源などを備える。ここで、管理装置１００は、例えば、一般的なＰＣなどで構成することができる。
図２において、ＲＯＭ２０３は、ＣＰＵ２０１が実行するプログラム（後述する図４の各処理を実現するモジュールも含む）を格納している。ＣＰＵ２０１は、内部バス２０６を介して接続される各デバイスを総括的に制御する。ここで、内部バス２０６には、ＲＡＭ２０２、ＲＯＭ２０３、ハードディスクドライブ（以後ＨＤＤとする）２０４、ネットワークインタフェース２０５の各デバイスが接続されている。２０８は表示部で、Ｉ／Ｏインタフェース２０７を介して接続され、アプリケーションに基づくユーザインタフェースを表示する。
ネットワークインタフェース（ＮＷ Ｉ／Ｆ）１０５は、図１に示したネットワーク１０７を介して、外部のネットワーク機器或いはパーソナルコンピュータ（ＰＣ）と双方向にデータをやりとりする。ここで、外部のネットワーク機器には、図１に示した画像形成装置１０４〜１０６などが含まれる。
【００１９】
ＨＤＤ２０４は、外部記憶装置として機能し、画像形成装置１０４〜１０６から取得する稼動情報を記憶する。また、ＣＰＵ２０１は、ＨＤＤ２０４に画像データを記録することも可能に構成されている。さらに、ＨＤＤ２０４には、オペレーティングシステム（ＯＳ）がインストールされており、ＲＡＭ２０２にロードされた後、各種のデータ、アプリケーションの実行を管理する。また、ＣＰＵ２０１は、アプリケーションをＲＡＭ２０２にロードして実行することでデータ通信処理、データ算出処理、データ表示処理等を行う。
このように構成された管理装置１００において、以下に示す部門カウンタ監視処理を行う。
【００２０】
具体的には、管理装置１００には、画像形成装置の識別情報（シリアルナンバー、ＩＰアドレス、ＭＡＣアドレス、及び製品名等）が登録されており、各画像形成装置から送信されてくるデータに含まれる識別情報を元にデータベースに格納する。
部門カウンタについては、画像形成装置から１度でも部門カウンタの情報が受信された際に、送信されてきた部門カウンタの情報に対応する部門ＩＤを登録し、新たに部門カウンタの情報をデータベースに格納する。なお、複数部門にまたがる集計値や、部門単位での集計値などについては、管理装置１００の表示部２０７の表示画面から要求された形式での集計を適宜行うため、ここではデータベースには集計値の格納を行わない。
［画像形成装置の構成］
【００２１】
図３は、図１に示した画像形成装置１０４〜１０６の構成を示すブロック図である。画像形成装置の構成は基本的に同じであるので、ここでは画像形成装置１０４について説明する。
画像形成装置１０４は、ＲＯＭ３０３に格納されているプログラム（後述する図５の各処理を実現するプログラムも含む）を実行するＣＰＵ３０１を備え、内部バス３０６を介して各デバイスを総括的に制御する。
内部バス３０６には、ＲＡＭ３０２、ＲＯＭ３０３、ハードディスク装置（以後ＨＤＤとする）３０４、デバイス制御部３０７、印刷部３０８、ＮＷＩ／Ｆ３０５の各デバイスが接続されている。
【００２２】
ＲＡＭ３０２は、ＣＰＵ３０１のメモリやワークエリアとして機能する。デバイス制御部３０７は印刷部３０８又はスキャナ部３０９、あるいは印刷部３０８及びスキャナ部３０９を制御して、画像処理を制御する。
【００２３】
ＮＷ Ｉ／Ｆ３０５は、ネットワーク１０７を介して、外部のネットワーク機器或いはパーソナルコンピュータ（ＰＣ）と双方向にデータをやりとりする。ＨＤＤ３０４は外部記憶装置として機能し、画像データ等を記憶する。さらに、ＨＤＤ３０４は、部門カウンタを含む稼動情報、システム情報及びステータス情報を保存することも可能である。ＣＰＵ３０１は、ＨＤＤ３０４に画像データを記録する処理を行うことも可能に構成されている。
［管理装置のソフトウェアモジュール構成］
【００２４】
図４は、図１に示した管理装置１００のソフトウェアモジュールの構成を示すブロック図である。
図４において、４００はＨＴＴＰ／ＳＯＡＰクライアントモジュール（以下、クライアントモジュールと呼ぶ）で、ＳＯＡＰファンクションモジュール（以下、ファンクションモジュールと呼ぶ）４０１からの送信要求を受け、所定のスキーマに基づくマークアップ言語記述を作成する。ここで、ＨＴＴＰとは、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌであり、ＳＯＡＰとは、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌである。これらのプロトコルは、管理システムにおいて、画像形成装置１０４〜１０６と管理装置１００との間におけるデータやサービスを呼び出すために用いられる。
ここで、情報の各々に対応するスキーマ仕様はクライアントモジュール４００がアクセスできる記憶部、例えばＲＯＭ２０３またはＨＤＤ２０４に予め格納されているものとする。
【００２５】
クライアントモジュール４００は、作成したマークアップ言語記述のデータを、インターネット１０１を介して指定される画像形成装置１０４〜１０６へ送信する。
ここで、マークアップ言語記述としては、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が挙げられる。なお、説明では、ファンクションモジュール４０１がクライアントモジュール４００に各種情報の通知を行うよう説明した。しかしながら、クライアントモジュール４００自らが、上述の情報をファンクションモジュール４０１から取得するようにしても良い。
【００２６】
また、クライアントモジュール４００は、ＳＯＡＰ情報の受信を受け、所定のスキーマに基づきマークアップ言語記述からデータを抽出してファンクションモジュール４０１へ渡す。
データベース４０４には、取得した稼動情報や内部動作のログ、通信履歴（成功、失敗）等が格納されている。例えば、管理する画像形成装置の情報や部門カウンタの識別情報（部門ＩＤ）とその値が関連付けられて格納されることになる。なお、本実施形態に示す稼動情報には、１以上の部門カウンタが含まれており、部門カウンタの情報は、部門ＩＤにより識別されて、実際に画像形成が実行された印刷枚数や面数などの値が含まれる。画像形成装置から稼動情報などを取得するスケジュール設定は、管理装置１００による後述する処理に基づき自動的に更新される場合がある。
【００２７】
データベースに登録されている画像形成装置の情報としては、固有に設定される情報（ＩＰアドレス、ＭＡＣアドレス、デバイスシリアル番号、製品名、製品タイプなど）といった管理に必要な情報を指している。
管理部４０５は、画像形成装置１０４〜１０６から取得した稼動情報のデータベース４０４への格納及びデータベース４０４からの出力の制御を処理ロジック４０３に基づき行うモジュールである。また、管理部４０５は後述するようなスケジューリング処理も行う。管理部４０５は、管理装置１００において稼動情報を受信するなどのタイミングで制御ネージャ４０２から処理要求を受け、処理ロジック４０３に基づく各種処理を実行する。
［画像形成装置のソフトウェアモジュール構成］
【００２８】
図５は、図１に示した画像形成装置１０４のソフトウェアモジュールの構成を示す図である。
図５において、ファンクションモジュール５０１は、クライアントモジュール５００に、マネージャ５０２から受けた情報およびマークアップ言語記述の作成依頼、及び作成したマークアップ言語記述を指定される管理装置１００へ送信する通信依頼を行う。ここで、指定される管理装置の情報は、事前にクライアントモジュール５００が保持している形態でも良いし、設置時に設定しても良い。
【００２９】
クライアントモジュール５００では、ファンクションモジュール５０１からの情報を受け、所定のスキーマに基づくマークアップ言語記述を作成する。ここで、可変情報や固定情報の各々に対応するスキーマ仕様はＨＴＴＰ／ＳＯＡＰクライアントモジュールがアクセスできる記憶部に予め格納されているものとする。
そして、クライアントモジュール５００は、作成したマークアップ言語記述のデータを、指定される管理装置１００へ送信する。マークアップ言語記述としては、例えばＸＭＬが挙げられる。なお、上の説明では、ファンクションモジュール５０１がクライアントモジュール５００に各種情報の通知を行うよう説明した。
【００３０】
例えば、クライアントモジュール５００自らが、上述の情報をファンクションモジュール５０１から取得するようにしても良い。
デバイス制御モジュール５０７は、図３に示したデバイス制御部３０７及び印刷部３０８のインタフェースに対応する。したがって、デバイス制御モジュール５０７を介して、例えば印刷部３０８で検知されるエラーなどを含む、画像形成装置１０４〜１０６におけるステータス情報やカウンタ情報が通知されてくる。
【００３１】
ここで、カウンタ情報には、画像形成装置１０４〜１０６が画像形成した利用枚数を示すカウンタの値や、装置内の部品の使用状況を示す部品カウンタの値、その他の機能の利用状況を示す機能カウンタの値等の各種カウンタ値が含まれる。
また、エラー情報には画像形成装置１０４〜１０６に蓄積される印刷ジョブの状態、画像形成装置１０４〜１０６で発生した障害が含まれる。
【００３２】
画像形成装置１０４〜１０６の障害としては、ハードディスクエラーや課金カウンタエラー等のサービスコールエラー、紙ジャム等のエラー、或いはトナーロー等のワーニングなどのエラーが含まれる。さらに、画像形成装置１０４〜１０６の障害にはドアオープン、排紙トレイの紙積載超過なども含むものとする。
状態イベントモジュール５０４は、デバイス制御モジュール５０７から通知されたエラー情報リスト（複数種類のエラー情報）をマネージャ５０２に通知する。
【００３３】
定期データモジュール５０５は、デバイス制御モジュール５０７から取得できるカウンタ情報をマネージャ５０２に通知する。カウンタ情報は定期的に取得するため、タイマモジュール５０６からの設定されている時刻に基づき、マネージャモジュール５０２より要求される。
【００３４】
５０９は管理部で、記憶装置５０８への格納及び記憶装置５０８からの出力の制御を処理ロジック５０３に基づき行うモジュールである。管理部５０９は、取得した部門カウンタの情報を含む稼動情報を処理ロジック５０３経由で記憶装置５０８に格納する。また、管理部５０９は稼動情報の外部送信などに際して、マネージャモジュール５０２の指示に基づき、保存した稼動情報をファンクションモジュール５０１に渡す。
ハードディスクやＳＲＡＭ等の不揮発性メモリで構成される記憶装置５０８には、エラー情報やカウンタ情報の他に処理に必要な固定情報、可変情報のほか内部動作のログ、通信履歴（成功、失敗）等が設定された部門毎に分けて格納される。これにより、電源がＯＦＦされても再び電源ＯＮして際、前記格納データを読むことで前回の状態が保持される仕組みになっている。
［初期スケジュール設定について］
次に管理システム内におけるスケジュール設定処理について説明する。
【００３５】
図６は、本実施形態を示す管理システムにおけるデータ処理手順の一例を示すフローチャートである。本例は、部門管理を行う画像形成装置を初めて設置する際、または運用中にスケジューリングの変更処理（以降、再スケジューリング処理と称す）を行う際のスケジュール設定およびスケジュール送信の処理例である。
【００３６】
ここで、Ｓ６０１〜Ｓ６０６は管理装置１００のＣＰＵ２０１がＲＡＭ２０２に制御プログラム、上記モジュールをロードして実行することで実現される。また、Ｓ６１０〜Ｓ６１４は画像形成装置１０４〜１０６のＣＰＵ３０１がＲＡＭ３０２制御プログラム、上述したモジュールをロードして実行することで実現される。
【００３７】
なお、管理装置１００によるスケジュール設定手順には以下の２通りの場合においてそれぞれ異なる設定手順が想定される。１つには、現場に設置した画像形成装置の情報が管理装置１００に登録されていない状態で画像形成装置１００がスケジュール取得要求を行う場合である。もう１つには、事前に管理装置１００に設置する画像形成装置が登録された状態で、現場に設置された画像形成装置よりスケジュール取得要求を行う場合である。
【００３８】
ここで、後者の場合は、新たに設置された画像形成装置を利用するユーザが特定でき、そのユーザが利用する他の画像形成装置を把握できる。そこで、管理装置１００は、スケジュール取得要求をしてきた画像形成装置に対して、そのほかの画像形成装置とスケジュール設定を同じ、または近い時間で設定することができる。これにより、同じユーザ環境にある画像形成装置からの稼動情報などがほぼ同一のタイミングで取得できるようになる。
【００３９】
一方、前者の場合は、どのユーザが利用する画像形成装置であるかを特定することができない。そこで、管理装置１００は既に設置されている画像形成装置のスケジュール設定に基づき、稼動情報の送信スケジュールがバラけるようなスケジュール設定するように画像形成装置に応答する。これにより、関連性のない画像形成装置に対して同じスケジュール設定をすることによる、無駄な通信負荷が発生する可能性を低減できる。ここでは、同じユーザ環境に設置された画像形成装置であっても、一部の画像形成装置は朝、残りの画像形成装置は夕方に稼動情報を送信するような状態が起こり得る。
次に、管理装置１００と画像形成装置１０４におけるスケジュール設定の流れについて説明する。
【００４０】
管理装置１００では、画像形成装置１０４からスケジュール要求がなされるのを待っている。これは、図１に示す管理システムがゲートウエイ１０３により管理装置１００から直接、画像形成装置１０４に対してファイヤーウォールを越えて通信を行うことが困難となる構成のためである。
よって、Ｓ６１０で、画像形成装置１０４は管理装置１００に対してスケジュール設定を取得するための要求を送信する。具体的には、図５に示したクライアントモジュール５００が取得要求を管理装置１００に出力する。ここでは、クライアントモジュール５００からマークアップ言語に基づくデータが出力される。
【００４１】
ここで、管理装置１００での初回のスケジュール設定に関して、設定を要する画像形成装置の台数が多ければ、例えばデバイスＩＤの番号順に所定台数ずつグルーピングして、暫定的に画像形成装置に対して設定を行うことが考えられる。これにより、画像形成装置で管理する稼動情報を管理装置１００に送信できるようにする。
【００４２】
このようにして、一度、画像形成装置に対して、稼動情報を管理装置１００に送信するためのスケジュール設定が行われると、画像形成装置は定期的に管理装置１００に対し稼動情報を送信する。この際、画像形成装置は、稼動情報の送信に合わせて、当該稼動情報を送信するためのスケジュール設定の変更や変更が必要か否かの問い合わせを行う。スケジュールの変更処理などについては後述する。
【００４３】
管理装置１００では、画像形成装置１０４からのスケジュールを取得するための要求を待っており、Ｓ６０１で、クライアントモジュール４００を介してスケジュール取得の要求を受信すると、Ｓ６０２に進む。そして、Ｓ６０２で、要求を行った画像形成装置１０４に関する登録情報を検索する。具体的には、管理部４０５が処理ロジック４０３を用いてデータベース４０４内で管理される画像形成装置の情報及びそのスケジュール設定の検索を行う。
次に、Ｓ６０３で、Ｓ６０２の検索で取得した情報より、画像形成装置１０４に対してスケジュール設定を実施するか否かを管理部４０５が処理ロジック４０３を用いて決定する。
【００４４】
ここで、スケジュール設定を行う必要がない場合がある。例えば既にスケジュール設定が過去に行われていて、かつ設定の変更が必要ない場合や、スケジュール更新処理の機能が無効にされている場合である。ここで、スケジュール更新処理の機能を有効（オン）または無効（オフ）とするための再スケジューリングフラグは、管理部４０５により管理されている。
Ｓ６０３において、管理部４０５がスケジュール設定の変更を実施すると判断した場合、Ｓ６０４へ進む。そして、Ｓ６０４で、管理部４０５がデータベース４０４に予め格納されているスケジュール設定を、画像形成装置１０４に設定するための送信情報を生成する。
【００４５】
次に、クライアントモジュール４００は、生成された送信情報を画像形成装置１０４に送信し、Ｓ６０５で、送信が成功したか失敗したかを制御マネージャ４０２が判断する。ここで、制御マネージャ４０２が画像形成装置１０４より受信成功の応答を受信したと判断した場合は、本処理を終了する。
一方、Ｓ６０５で、受信失敗の応答を受信、または通信異常等で応答を受けられなかったと制御マネージャ４０２が判断した場合は、Ｓ６０６へ進む。そして、Ｓ６０６で、管理部４０５は処理ロジック４０３を用いて、スケジュール設定のための情報の送信が失敗したことをデータベース４０４に記録して、本処理を終了する。
【００４６】
一方、画像形成装置１０４では、Ｓ６１０で実行されたスケジュール取得要求に対する管理装置１００からの応答を待っている。
そして、Ｓ６１１で、あらかじめ設定されているタイムアウト時間内にスケジュールの設定を管理装置１００から受信しているかどうかを管理部５０９が処理ロジック５０３を用いて判断する。ここで、処理タイムアウト時間内にスケジュールの設定情報を管理装置１００から受信していると管理部５０９が判断した場合は、Ｓ６１２へ進む。
【００４７】
そして、Ｓ６１２で、管理部５０９は、画像形成装置１０４の記憶装置５０８にスケジュール設定を記憶する。そして、Ｓ６１３で、管理部５０９は、ファンクションモジュール５０１、クライアントモジュール５００を介して管理装置１００に対しスケジュール設定の受信結果を応答し、本処理を終了する。
なお、画像形成装置１０４は、応答は受信の成功だけでなく、失敗を管理装置１００に対して通知することもある。
一方、Ｓ６１１で、管理装置１００からのスケジュール設定を時間内に受信できなかったと管理部５０９が処理ロジック５０３を用いて判断した場合は、Ｓ６１４へ進む。そして、Ｓ６１４で、管理装置との通信に異常があったことを記録するため、通信テストにおいて失敗した際の処理を実行して、本処理を終了する。
【００４８】
図６で説明した処理により、管理システムの運用が開始され、実際に部門カウンタの情報をはじめとする稼動情報が送信され始める。これにより、実際の稼動状況を、管理装置１００がデータベース４０４に格納する部門カウンタを集計することで判断することができる。
ここで、画像形成装置の設置時に登録されている部門ＩＤに対応する部門カウンタの情報は、利用者の都合によりまったく変化しなかったりする。例えば、部門ＩＤを利用するユーザが、そのＩＤを登録した画像形成装置を利用できない場所にいる、または画像形成装置の移動により利用されない部門ＩＤが残るなどにより部門カウンタの情報が変化しないことがある。
また、画像形成装置において、新たな部門ＩＤが追加され、あるときから新しい部門ＩＤに対応する部門カウンタの情報が送信され始めることもある。
【００４９】
そこで、以下に示す運用における部門カウンタ監視処理、再グルーピング判断処理を繰り返すことで、管理装置１００の監視対象の画像形成装置に対するスケジュール設定の見直しが必要か否かを管理装置１００が判断する。本実施例においては、同じグループにグルーピングした画像形成装置に対しては同じ、ほぼ同時刻のスケジュール設定が行われる。管理装置１００の判断に基づき、再グルーピングや再スケジューリングを実行することで、通信負荷も考慮した上で、適切な部門カウンタの集計を行えるようなる。
［運用における部門カウンタ監視処理］
次に、管理装置１００がスケジュール設定に基づき各画像形成装置１０４〜１０６から送信される部門カウンタを含む稼動情報を受信し、その受信データを監視する処理について説明する。
【００５０】
図７は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、部門管理を行う画像形成装置に対する再スケジューリング処理を行う際の処理例である。ここでは、例えば所定のタイミングで管理装置１００が定期的にスケジューリングの見直しを行うことが考えられる。ほかにも、定期的な稼動情報の受信とともに画像形成装置から送信されてくるスケジュール設定に関する問合せに応じたタイミングで、本処理が行われることも考えられる。
なお、Ｓ７０１〜Ｓ７１１で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
まず、Ｓ７０１で、まず、制御マネージャ４０２は、画像形成装置に対する稼動情報の送信スケジュールの再設定（再スケジューリング）処理を自動で行うかどうかを判断する。具体的には、ＲＡＭ２０２上で管理されている再スケジューリング実施有無のフラグがオン（１）になっている場合に、再スケジューリング処理が自動で行われると判断される。
【００５１】
ここで、再スケジューリング実施有無のフラグがオフ（０）になっている際には、再スケジューリング処理が自動で行われないと判断され、以降の処理は行われずに、本処理を終了する。
なお、再スケジューリング実施有無のフラグをオフ（０）とするのは、元々部門管理を実施する予定がない、または１台、もしくは極めて少数の画像形成装置の設置のみである場合などに対処できるよう用意されている。
【００５２】
一方、Ｓ７０１で、再スケジューリング実施有無のフラグがオン（１）になっている際には、再スケジューリング処理が自動で行われると判断され、Ｓ７０２に進む。
そして、Ｓ７０２で、前回の本処理を行った時から稼動情報を画像形成装置１０４から受信しているかどうかを管理部４０５が判断する。なお、この判断は、稼動情報が受信された直後に行われてもよいし、特に稼動情報の受信タイミングに依存しないタイミングにおいて行われてもよい。
【００５３】
なお、Ｓ７０２で、管理装置１００は、前回の本処理を行った時から稼動情報を受信できていない場合（いいえ）は、受信するまで待機する。稼動情報を画像形成装置１０４から受信している場合は、Ｓ７０３に進む。
Ｓ７０３で、画像形成装置から受信した稼動情報における部門カウンタの情報について、すでにデータベース４０４に登録されている部門ＩＤと全て一致するかを管理部４０５が判断する。すべての部門ＩＤが一致したと管理部４０５が判断した場合は、Ｓ７０４に進む。
【００５４】
Ｓ７０４で、管理部４０５は、受信した部門カウンタの情報をデータベース４０４に格納し、Ｓ７０５へ進む。そして、Ｓ７０５で、管理部４０５が前回受信した各部門カウンタの値からの増加分を算出して、増加カウントの値としてデータベース４０４に格納する。
次に、Ｓ７０６で、処理ロジック４０３が現在処理中の部門ＩＤを有する画像形成装置の総カウンタに対する、部門カウンタの増加数を比較して、増加数が閾値（既定値）未満であるかどうかを判断する。具体的には、画像形成装置で３００００枚／月に印刷しているにもかかわらず、ある部門ＩＤの利用が２枚／月だったとした場合、増加なしと見なして再スケジューリング処理を行うためである。
実際の閾値はデータベース４０４の図８（Ｂ）に示すスケジューリング更新パラメータを管理するテーブルに格納されており、システムの運用状況に合わせて管理者が変更することが可能である。
【００５５】
ここで、処理ロジック４０３は、増加閾値を判断するための最大値と増加閾値パラメータ（％）を用いて、増加閾値判断用の最大値×増加閾値パラメータ（％）を算出する。この値が増加なしと判断するカウンタ増加値に対応する。図８の詳細に関しては後述する。
Ｓ７０６で、閾値未満と判断された場合、すなわち、部門カウンタの値にほとんど増加がみられないと管理部４０５が判断した場合、Ｓ７０８に進む。なお、画像形成装置において１枚も印刷しない場合、つまり部門カウンタの値に変化がなかった場合のみを識別したい場合、増加閾値をゼロとすればよい。
そして、Ｓ７０８で、そのＳ７０６でカウンタの値にほとんど増加がみられなかった部門ＩＤを、後述するグルーピング処理における判断対象から削除するため、判断対象フラブを無効に設定する。
一方、Ｓ７０６で、増加閾値を超えていると管理部４０５が判断された場合は、Ｓ７０７で、管理部４０５が前回再スケジューリング処理を実施した時から予め指定された期間が経過していないかを判断する。この判断ステップは、受信する部門カウンタの情報に対応する部門ＩＤに変更なく、稼動情報の受信が続く場合においても、一定期間経過後にスケジューリング処理を自動で行うためのものである。
【００５６】
ここで、指定期間が経過していないと管理部４０５が判断した場合は、Ｓ７０１に戻る。これは、まだグルーピングなどを見直すべきタイミングではないためである。
一方、Ｓ７０７で、指定期間が経過したと管理部４０５が判断した場合は、図９などで後述するような再スケジューリングに関する処理へ進む。
なお、本実施形態では、Ｓ７０７における指定期間を任意に指定可能とし、早期にスケジューリングに関する処理の行うよう指定期間を短く設定することも可能である。
一方、Ｓ７０３で、受信した稼動情報に含まれる部門カウンタの部門ＩＤが、すでに格納されている部門ＩＤと一致しないと判断された場合は、Ｓ７０９に進む。
【００５７】
ここで、管理部４０５は、全ての部門ＩＤにおいて一致しなければ、部門ＩＤの追加、または削除が行われたことになる。具体的には、画像形成装置側で新規に登録された部門ＩＤに対応する部門カウンタの情報が送信されたか、または画像形成装置側で部門ＩＤが削除され送信されなくなったといった場合を示す。
Ｓ７０９では、管理部４０５が新たに部門ＩＤを追加するとともに、受信した部門カウンタの情報をデータベース４０４に格納する。
【００５８】
これに対して、部門ＩＤが削除されている（減っている）と判断された場合、部門ＩＤの判断対象のフラグを無効に設定し、後述する再スケジューリング処理などの対象から外すようにする。なお、集計には必要なので、すでに格納している部門カウンタの情報は残すものとする。
次に、Ｓ７１０で、管理部４０５が前回受信した部門カウンタの値からの増加分を算出して、データベース４０４に格納する。また、管理部４０５は、新たな部門ＩＤに対応する部門カウンタにおいては、データベース４０４に新たに管理用の項目を追加して、今回受信した部門カウンタの値を増加分として格納する。
そして、Ｓ７１１で、管理部４０５は、新しい部門ＩＤの部門カウンタに関して、判断対象フラグを有効にして、図９に示すグルーピング処理に進む。
【００５９】
図８は、図４に示したデータベース４０４で管理されるテーブルの一例を示す図である。
図８（Ａ）は、ある画像形成装置の部門カウンタの情報を管理するテーブルである。具体的には、画像形成装置の識別情報としての機番、その画像形成装置に適用されているスケジュール設定、その画像形成装置に関して登録されている部門ＩＤとその値（日毎）などが管理される。
また、本テーブルでは、部門ＩＤごとにグルーピングの際に処理対象とするかを判断する判断対象フラグや、前回受信時からの増加分を示す増加カウントや、画像形成装置がどのグループに属しているかを示す情報を管理する。
【００６０】
判断対象フラグには、グルーピング処理の際に、この部門ＩＤに対応する情報を判断に用いるか否かの情報が格納される。
増加カウント欄には、再スケジュール処理の実施時から、増加した分のカウンタの値が格納される。この増加カウントは、図８（Ｂ）に示す期間経過後などに参照され、この部門ＩＤがユーザに利用されているか否かの判断に利用される。
【００６１】
グループ欄には本実施例におけるグルーピング処理によって設定されるグループ情報が格納される。具体的には、図１３以降に示すＧ０１、Ｇ０２、Ｇ０３、・・・としている。ここで、グループ情報を、Ｇ０１＝Ｇ０３として同じスケジュール設定を行うことも可能である。
図８（Ｂ）は、スケジューリング更新パラメータを管理するテーブルである。
本テーブルでは、自動でスケジューリングを行う否かを決定する際のスケジューリング実施有無を決定するフラグと、部門カウンタの増加傾向を判断する上でのベースとなる期間を格納する期間を管理する。さらに、スケジュールの再設定の対象となり得る、ほとんど利用されていない部門ＩＤを検出するための最大値（枚）、増加閾値（％）も管理している。
【００６２】
ここでは、期間は、定期的にスケジューリングを見直すためのパラメータで、初期値として、７２０日（或いは３０日）が設定されている。最大値（枚）及び増加閾値（％）は、所定期間において画像形成装置で特定の部門ＩＤが利用されていないとみなす際の判断に使用する。
図８（Ｃ）は、１グループに登録可能な画像形成装置の最大台数を管理するテーブルである。全部門ＩＤが共通する画像形成装置であっても、この設定台数までしか同じグループに登録されない。これは、あまりにも多い台数に対して、同じスケジュール設定が適用されてしまうことを避けるためである。
【００６３】
この上限の設定により、部門ＩＤが共通する複数の画像形成装置の中で同時刻のスケジュール設定ができない画像形成装置がでてくる。しかし、上限設定により分割して別のグルーピングされたということも判別できるため、それぞれのグループのスケジュール設定を近い時刻にすることが可能である。
［グルーピング処理］
次に図９を用いて画像形成装置のグルーピング処理について説明する。
【００６４】
図９は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、各画像形成装置から受信した部門カウンタの情報などをもとに、現在の画像形成装置のグループが適切かを見直す処理例である。なお、Ｓ８０１〜Ｓ８１４で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
【００６５】
Ｓ８０１で、管理部４０５は、本処理の基準とする対象画像形成装置（例えば画像形成装置１０４〜１０６のいずれかに該当する）を設定する。ここで、対象画像形成装置の決定に関しては、とくにその順番は問わない。
次に、Ｓ８０２で、管理部４０５は、本処理の対象となる部門ＩＤの範囲（本実施形態では、説明上、部門Ｎｏ.Ｘ〜Ｙとする）を抽出する。
【００６６】
Ｓ８０３において、管理部４０５が、Ｓ８０２で抽出した部門ＩＤの中の１つ部門ＩＤ（例えば、部門Ｎｏ．Ｘ）が他の画像形成装置の登録情報に存在するかを、データベース４０４を検索し、確認する。ここでは、管理装置１００の管理対象の画像形成装置として、データベースに登録されている画像形成装置の情報に対する検索が行われる。また、画像形成装置の登録情報に部門ＩＤが存在する場合とは、定期的にその画像形成装置からその部門ＩＤに対応する部門カウンタの情報を受信していることになる。
そして、登録情報にその部門ＩＤを含む画像形成装置のリストを作成する。このとき、管理部４０５は、データベース４０４上で確認された部門ＩＤに対して判断対象フラグが無効に設定されていた場合、その画像形成装置に関してはリスト登録の対象としないものとする。
【００６７】
次に、Ｓ８０４で、管理部４０５が、Ｓ８０３で作成したリストをもとに、同じ部門ＩＤに対応する部門カウンタの情報を送信してきた画像形成装置として、同じグループ番号を割り当てる。そして、Ｓ８０５で、管理部４０５は、画像形成装置は既にグループ番号が割り当てられていること（グルーピング済み）を示す処理済フラグを有効にする。
そして、Ｓ８０６で、管理部４０５は、処理対象の部門ＩＤの全てに対してＳ８０３〜Ｓ８０５の処理を行ったかを判断する。例えば、処理対象の部門ＩＤがＳ８０２で抽出した最後の部門ＩＤ（部門Ｎｏ．Ｙ）と一致するかをチェックする。
【００６８】
Ｓ８０６で処理対象の部門ＩＤの全てに対してＳ８０３〜Ｓ８０５の処理を終了したと判断された場合は、Ｓ８０７へ進む。一方、Ｓ８０６で、未処理の部門があると判断された場合は、Ｓ８１０へ進み、未処理の部門ＩＤを処理対象とし、Ｓ８０３へ戻る。
Ｓ８０７で、前回のグルーピングされた時点からグループ番号に対応する画像形成装置のリストに変更があるかどうかを管理部４０５が判断する。ここで、管理部４０５が変更なしと判断した場合、再スケジューリングする必要がないとして、Ｓ８０８に進む。一方、管理部４０５が変更ありと判断した場合、Ｓ８１１に進む。
【００６９】
そして、Ｓ８０８で、管理部４０５は、データベース４０４で管理されるテーブル上で、グルーピング処理に関して処理済みフラグが無効となっている画像形成装置が存在するか否かを判断する。Ｓ８０８で存在すると判断された場合は、Ｓ８０９で、処理済みフラグが無効となっている画像形成装置を次の処理の基準とすべき対象画像形成装置に設定し、Ｓ８０２に戻る。
一方、Ｓ８０８で存在しないと判断された場合は、図１０を用いて後述するグループの分割処理に進む。
【００７０】
Ｓ８１１では、管理部４０５が対象画像形成装置に割り当てたグループ番号に対応するグループが、前回グルーピング処理時に分割され、後述する近似スケジュールの設定がされたか否かを判断する。なお、グループの分割や近似スケジュールに関する処理については図１０において後述する。
ここで、近似スケジュールの設定がされていたと判断された場合は、Ｓ８１２で、管理部４０５は、近似スケジュールの設定がなされていて、かつ画像形成装置のリストに変化のないグループを抽出する。
【００７１】
次に、Ｓ８１３で、対象画像形成装置のグループ番号を、Ｓ８１２で抽出したグループに対して割り当てる。これは、前回近似スケジュールされた各グループの画像形成装置の全てを今回の再グルーピングの対象とするための処理である。
最後に、Ｓ８１４で、管理部４０５は、データベース４０４で管理されている該当グループの再スケジューリングフラグをオンにし、Ｓ８０８に進む。
【００７２】
一方、Ｓ８１１で、当該グループが近似スケジュールのグループでないと管理部４０５が判断した場合、Ｓ８１４でそのグループのみの再スケジューリングフラグをオンにし、Ｓ８０８に進む。
［グループの分割について］
次に、図９で説明したグルーピング処理において、１グループに属する画像形成装置の数が一定数を超えている場合に、複数のグループに分割するようにグルーピングする処理を行う。
【００７３】
図１０は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、上述したグループに登録可能な上限台数を超えているか否かを判断する処理に関する例である。なお、Ｓ９０１〜Ｓ９０５で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
【００７４】
Ｓ９０１で、図９に示した一連のグルーピング処理が完了後に、管理部４０５は、そのグループに割り当てられた画像形成装置の台数が上限未満であるかを判断する。これは、ネットワークの負荷を抑えるとともに、管理装置１００における部門カウンタの情報の登録処理などの負荷を抑えるための処理となる。
ここで、１グループに割り当てられた画像形成装置の台数が上限を超えていないと管理部４０５が判断した場合、分割処理を行わないで、図１１に示すスケジューリング処理に進む。
【００７５】
一方、Ｓ９０１で、上限を超えている（上限以上）と処理ロジック４０３が判断した場合、同一グループ内に含まれる一部の画像形成装置を別のグループに割り当てる必要があるため、Ｓ９０２に進む。
そして、Ｓ９０２で、管理部４０５は、グループを分割する数を算出する処理を行う。一例として、グループに登録されている台数と上限台数との商をもとめ、剰余がない場合は商を、剰余がある場合は商に１を加算した値を分割数とし、Ｓ９０３に進む。
【００７６】
そして、Ｓ９０３で、管理部４０５は、分割数から１を引いた数だけ新たにグループ番号を生成し、更にＳ９０４で、管理部４０５は、Ｓ９０３で生成したグループ番号を、上限数で分割された夫々のグループに割り当てる。
次に、Ｓ９０５では、管理部４０５は、分割されてしまった各グループに対し、近い時刻にスケジュール設定されるようにで近似スケジュール指定を行い、図１１に示すスケジューリング処理に移行する。
【００７７】
これにより、同一のグループとして管理されるべき画像形成装置群が、上限設定により分割されても、大きく異なる時刻でのスケジュール設定がされなくなる。
［スケジューリングについて］
以下、再スケジューリング処理について説明する。
【００７８】
図１１は、本実施形態を示す管理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、再スケジューリングのフラグに基づき、必要な画像形成装置に対してスケジュール設定を行う処理例である。なお、Ｓ１００１〜Ｓ１００４で示す各ステップは、ＣＰＵ２０１がＲＡＭ２０２に図４に示したモジュールをロードして実行することで実現される。
まず、Ｓ１００１で、管理部４０５は、再スケジューリングのフラグが有効になっているグループがあるかを判断する。ここで、グルーピング処理の結果により再スケジューリングの対象グループがないと管理部４０５が判断した場合、本処理を終了する。一方、Ｓ１００１で、再スケジューリング対象のグループがあると管理部４０５が判断した場合は、Ｓ１００２へ進む。
【００７９】
Ｓ１００２で、管理部４０５は、再スケジューリング対象のグループの含まれる画像形成装置に対して、前回設定されていたグループ番号と異なるかを判断する。
ここで、前回と同じグループ番号が設定されていると管理部４０５が判断した場合、前回からスケジュール設定を変更する必要がないため、本処理を終了する。一方、Ｓ１００２で、異なるグループ番号が設定されていると管理部４０５が判断した場合、該当するグループの再スケジューリングを行うためＳ１００３に進む。
【００８０】
ここで、異なるグループ番号が設定される理由を以下にまとめる。
（１）グルーピング処理に際して、前回のグループに新しい画像形成装置が追加され上限台数を超えると、別のグループ番号でグルーピングされた場合
（２）グルーピング処理に際して、前回から所属していたグループから外され、新たなグループ番号が割り当てられた場合
【００８１】
（３）新しく追加された画像形成装置などであって、前回から管理されていた部門ＩＤを一切含まず、新規のグループ番号が割り当てられた場合
Ｓ１００３では、処理ロジック４０３は、再スケジューリング対象となるグループに対してのスケジュール設定のための時刻などの情報を決定する。このとき、分割処理により、近似スケジュール指定の対象となる複数のグループ対に対しては、１０〜３０分ずらして時刻を決定するなど、部門カウンタの情報の取得時刻が近くなるようにセットする。
【００８２】
なお、近似スケジューリングで設定されるグループ間の送信スケジュールの時間間隔（第２の時間間隔）は、通常の再スケジューリングにおいて設定される時間間隔（第１の時間間隔）よりも十分に短いものとなる。また、ここでの通常の再スケジューリングにおいて設定される時間間隔（第１の時間間隔）は、通信負荷の分散などを十分考慮し、例えば１〜２時間ずらした時刻が決定されるようにするものとする。また、近似スケジュールに関しては、自動で所定間隔ずらして送信スケジュールの時刻を決定するようにし、それ以外の通常の再スケジューリングに関しては管理者からの指示を受けることで決定するようにしてもよい。
そして、Ｓ１００４で、再スケジューリング対象となるグループに含まれる画像形成装置に対して、決定された新しいスケジュール設定を行うための情報を送信することで再スケジューリングを行い、本処理を終了する。先に説明したようにスケジュール設定は、画像形成装置より要求に応じて行われるため、新しいスケジュール設定の反映はそのタイミングで行われる。よって、ここでは新たなスケジュール設定を各画像形成装置の登録情報に対応させて管理し、画像形成装置の要求を待機するといったことが行われる。画像形成装置側では、受信した情報を解析し、自身でスケジュール設定を更新することになる。
［集計表示］
【００８３】
図１２は、図２に示した表示部２０７に表示されるユーザインタフェースの一例を示す図である。本例は、図４に示したデータベース４０４に格納されている部門カウンタの情報を元に集計した部門集計画面例である。
なお、本画面は、ネットワーク上の情報処理装置（ＰＣ１０）が備えるブラウザを介して、管理装置１００に用意されるＷＷＷサーバにアクセスすることで、ＰＣ１０上で表示することが可能である。
なお、図１２において、１２０６は部門管理している画像形成装置全ての総計表示枠を示している。１２０７は部門１（Ｄｅｐａｒｔｍｅｎｔ１）を登録している全画像形成装置の総計表示枠を示している。
【００８４】
図１２に示す部門集計画面１２０１において、１２０５は集計期間を設定する集計期間指定フィールドである。１２０２はデータの存在する部門ＩＤ表示フィールドである。１２０３はカウンタ総計フィールドで、部門ＩＤフィールド１２０２のカウンタごとの総計数を表示する。１２０４は遷移ボタンで、多くの部門ＩＤが存在する場合複数画面に分割して表示する際、次頁への遷移を行う場合に押下される。
【００８５】
カウンタ総計フィールド１２０３には、集計期間指定フィールド１２０５で指定された範囲において集計した複数の画像形成装置より送信されてきた各部門カウンタの情報が表示される。ここで、一例として９台の画像処理装置を表示した例である。
いままで説明してきた再スケジューリング処理によって、ここで集計対象となる画像形成装置の送信時刻はほぼ一緒であるため、期待する集計結果が得られることになる。
［運用における部門カウンタ受信例の説明］
【００８６】
図１３〜図１９は、前述した本実施形態を示す管理装置における各画像形成装置に対するスケジュール設定を説明するための図である。
図１３は、画像形成装置から最初の部門カウンタの情報を受信した後の管理テーブルを示す図である。本例は、複数の画像形成装置（Ｄｅｖ１、Ｄｅｖ２、Ｄｅｖ３、・・・、Ｄｅｖ１０）から部門カウンタが送信されてきたことを表している。
【００８７】
このように初期スケジューリング時には、画像形成装置ごとにまちまちにスケジューリングされる。この例では、同一顧客ということで、画像形成装置Ｄｅｖ１〜Ｄｅｖ１０まで同じスケジューリングにすることはできるが、同一顧客の回線においてトラフィックが集中する可能性もあり好ましくない。このため、ばらつきをもたせてスケジュール設定している。
図１４は、はじめて画像形成装置が設置されたときの初期スケジューリングの状態を想定している。ここで、１３００は画像形成装置の設置後、各画像形成装置のスケジュール設定に基づき、各画像形成装置からの部門カウンタ情報をはじめて受信したとき状態を示している。
【００８８】
本例は、複数の画像形成装置（Ｄｅｖ１、Ｄｅｖ２、Ｄｅｖ３、・・・、Ｄｅｖ１０）から部門カウンタの情報が送信されてきたことを表している。
また、１３０１は送信されてきた部門ＩＤに対して作成されるカラムであり、本例では部門ＩＤが１〜６、５０〜５３、９７〜１００、２００〜２０２に対して部門カウンタの情報が格納されていることを表している。
本実施形態では、設置後、最初にどのような部門カウンタの情報が各画像形成装置から送信されるのか特に把握する必要はないように管理装置１００は構成されている。
【００８９】
図１４においてカウンタ情報に対して網掛けされているのは、それぞれの取得スケジュール設定を識別しやすくするためである。ここでは、画像形成装置Ｄｅｖ１、Ｄｅｖ２、Ｄｅｖ４が同じスケジュール設定が行われている。また、それとは別にＤｅｖ３、Ｄｅｖ１０にはそれぞれ異なるスケジュール設定が行われている。さらに、ほかの画像形成装置とは異なるスケジュール設定がＤｅｖ８、Ｄｅｖ９は同様に行われていることを表している。
次に、図１５を用いて上述した再グルーピング処理結果を反映した表示処について説明する。
【００９０】
運用が進むと、各画像形成装置から図１４に示した部門カウンタの情報の受信状況から、各画像形成装置でどの部門ＩＤがどの程度利用されているのかが特定できる。
図１５ではグループ処理に基づき、部門ＩＤ１〜６を有する画像形成装置Ｄｅｖ１のグループ番号Ｇ０１に対し、他の画像形成装置から同じ部門ＩＤ１〜６が送信されてこないのでＤｅｖ１はＧ０１のまま、部門１〜６は、枠１４０１に示すように、図１４に示したスケジュール設定と同一のスケジュール設定値を据え置く。
一方、画像形成装置Ｄｅｖ２、Ｄｅｖ３、Ｄｅｖ４、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０はそれぞれで同じ部門ＩＤを有していることから、枠１４０２に示す画像形成装置に対してグルーピング処理を実行する。
【００９１】
グループ番号Ｇ０１であったＤｅｖ２とＤｅｖ４はＧ０１グループでなくなることで、再スケジューリングの対象となるとともに、他の共通する部門ＩＤを有する画像形成装置と同じグループ番号Ｇ０２が適用されるために、同じスケジューリング設定が行われる。なお、図１５において、部門１〜６はＤｅｖ１しか使用していないので、他の画像形成装置と異なるグループとしている。
【００９２】
ここで、例えばＤｅｖ１は部門１〜４９までの部門ＩＤを利用し、Ｄｅｖ１１が部門９００〜１０００までの部門ＩＤを利用する際に、他の画像形成装置に比べどちらも利用する部門ＩＤの数が極端に多いとする。本実施形態では詳細に説明していないが、そういった場合は、Ｄｅｖ１とＤｅｖ１１を別のグループにすることも可能である。
また、Ｄｅｖ１が部門１〜６まで、Ｄｅｖ１１が部門９００〜９１０までの部門ＩＤを利用する際には、他の画像形成装置に比べ特に利用する部門ＩＤの数が多くないとして、Ｄｅｖ１とＤｅｖ１１が同じ部門ＩＤを利用していないにもかかわらず、同一のグループと定義したりすることも可能である。これにより、グループ数が増加しすぎることを抑制できる。
【００９３】
次に、図１４〜図１８を用いて部門カウンタがこなくなる、または画像形成装置側で削除された場合について説明する。ここで運用初期は、図１３で説明した状態とする。その後、図１４，図１５に示す状態で上述したグルーピング処理および再スケジューリング処理が実施される。
しかし、運用状況が変わり、特定の部門ＩＤのカウンタ値が増えなくなる、もしくは部門ＩＤが画像形成装置側で削除されることで、その情報が送信されなくなる場合がある。
【００９４】
図１６は、画像形成装置Ｄｅｖ３、Ｄｅｖ４で、一部の部門ＩＤのカウンタ情報が増加しなくなる、または増加の条件を満たさなくなったことを示している。図１６では、画像形成装置Ｄｅｖ３の部門ＩＤ２００、２０１、２０２と、Ｄｅｖ４の部門ＩＤ９７，９８，９９，１００の部門カウンタが増加しなくなったと状態を示している。
これにより、前回までのグループの見直し処理が行われる。ここでは、Ｄｅｖ３の部門２００〜２０２、Ｄｅｖ４の部門９７〜１００がグルーピング判定処理の対象から外れることになる。
前回までのグループ番号０２で示すグループに含まれる画像形成装置は、Ｄｅｖ２、Ｄｅｖ３、Ｄｅｖ４、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０であった。図１６においては、その後の運用状況に合わせて、画像形成装置Ｄｅｖ２、Ｄｅｖ４がグループ番号０２となる。そして、残り画像形成装置Ｄｅｖ３、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０がグループ番号Ｇ０３で示す新たなグループに含まれ、新たなスケジュール設定１５０２が適用される。
【００９５】
図１６では、部門カウンタの情報が増加しなくなった場合について述べたが、部門ＩＤ自体が削除された場合も同様な処理が行われることになる。
図１７は、図１５に示したスケジュール設定が行われた後、画像形成装置Ｄｅｖ４の部門ＩＤ９７，９８，９９，１００の部門カウンタが削除された状態を枠１６０１で示す。
【００９６】
この場合も、図１６と同じように、画像形成装置Ｄｅｖ２、Ｄｅｖ４が同じグループ（グループ番号Ｇ０２）となる。そして、画像形成装置Ｄｅｖ３、Ｄｅｖ８、Ｄｅｖ９、Ｄｅｖ１０がそれとは別のグループ（グループ番号Ｇ０３）にグルーピングされる。ここで、グループ番号Ｇ０３で示すグループに属する画像形成装置に対しては、図１８に示す通りスケジュール設定１７０１が新たに行われる。
図１９に示すテーブルでは、１８０１で示すように画像形成装置（Ｄｅｖ１１）が新規に登録された状態を示している。ここでは、再スケジューリング処理が必要であるかを判断する処理について説明する。
【００９７】
ここでは、新規登録の画像形成装置が利用する部門ＩＤに対して、前回までに他の画像形成装置において利用され、登録されている部門ＩＤと重複するかを確認することになる。ここでまったく重複が無い場合は、新たにグループを生成し、スケジュール設定を行うか、もしくは管理しているグループの中で極端にそのグループに属する画像形成装置が少ないグループがあればそのグループに登録するようにしても良い。また、新規登録の画像形成装置が利用する部門ＩＤと１つでも重複する場合は、どの画像形成装置と同じスケジュール設定を行うべきかを判断することになる。ここでは、前述したようにグループの上限台数などが考慮され、グルーピングされ、そのグルーピングされたグループに対して適切なスケジュール設定が行われる。
【００９８】
図１９では、新規登録された画像形成装置Ｄｅｖ１１が、前回までで管理していたグループ番号Ｇ０２で示すグループに登録され、スケジュール設定された状態を示している。
本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン等の処理装置（CPU、プロセッサ）にて実行することでも実現できる。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。
【符号の説明】
【００９９】
１００ 管理装置
１０１ ネットワーク、インターネット
１０３ ゲートウエイ
１０４，１０５，１０６ 画像形成装置
【特許請求の範囲】
【請求項１】
複数の画像形成装置から、各画像形成装置に設定されている送信スケジュールに従い受信される部門カウンタの情報を、データベースを用いて管理する管理装置であって、
画像形成装置の識別情報、当該画像形成装置から受信した部門ＩＤ、及び該部門ＩＤに対応する部門カウンタの情報を関連付けて前記データベースに登録する登録手段と、
前記データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する特定手段と、
前記特定手段で特定された複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する管理手段と、
前記管理手段で管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する決定手段と、
前記決定手段により決定された各グループの送信スケジュールを各グループに属する画像形成装置に対して設定するための情報を生成し、当該画像形成装置からの要求の応答として生成した情報を送信する送信手段とを備え、
前記管理手段は、前記特定手段で特定された複数の画像形成装置の台数が上限以上の場合は、当該特定された複数の画像形成装置を複数の異なるグループで管理し、
前記決定手段は、前記管理手段により前記特定手段で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理された場合、当該複数のグループ間においては前記第１の時間間隔よりも短い第２の時間間隔で送信スケジュールを決定することを特徴とする管理装置。
【請求項２】
前記データベースに登録された情報に基づき、画像形成装置から受信する部門カウンタの情報の前回受信時からの増加分が既定値に満たない場合は、当該部門カウンタの情報に対応する部門ＩＤが当該画像形成装置で利用されていないとみなし、
前記特定手段は、前記データベースに登録されていても、利用されていないとみなされた部門ＩＤを除外して、部門ＩＤが重複する複数の画像形成装置を特定することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記管理手段は、前記特定手段で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理する場合には、前記管理手段で管理するグループが見直しされる際に当該複数のグループが識別できるように管理することを特徴とする請求項１または２に記載の管理装置。
【請求項４】
複数の画像形成装置から、各画像形成装置に設定されている送信スケジュールに従い受信される部門カウンタの情報を、データベースを用いて管理する管理装置における管理方法であって、
画像形成装置の識別情報、当該画像形成装置から受信した部門ＩＤ、及び該部門ＩＤに対応する部門カウンタの情報を関連付けて前記データベースに登録する登録工程と、
前記データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する特定工程と、
前記特定工程で特定された複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する管理工程と、
前記管理工程で管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する決定工程と、
前記決定工程により決定された各グループの送信スケジュールを各グループに属する画像形成装置に対して設定するための情報を生成し、当該画像形成装置からの要求の応答として生成した情報を送信する送信工程とを備え、
前記管理工程は、前記特定工程で特定された複数の画像形成装置の台数が上限以上の場合は、当該特定された複数の画像形成装置を複数の異なるグループで管理し、
前記決定工程は、前記管理工程により前記特定工程で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理された場合、当該複数のグループ間においては前記第１の時間間隔よりも短い第２の時間間隔で送信スケジュールを決定することを特徴とする管理方法。
【請求項５】
前記データベースに登録された情報に基づき、画像形成装置から受信する部門カウンタの情報の前回受信時からの増加分が既定値に満たない場合は、当該部門カウンタの情報に対応する部門ＩＤが当該画像形成装置で利用されていないとみなし、
前記特定工程は、前記データベースに登録されていても、利用されていないとみなされた部門ＩＤを除外して、部門ＩＤが重複する複数の画像形成装置を特定することを特徴とする請求項４に記載の管理方法。
【請求項６】
前記管理工程は、前記特定工程で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理する場合には、前記管理工程で管理するグループが見直しされる際に当該複数のグループが識別できるように管理することを特徴とする請求項４または５に記載の管理方法。
【請求項７】
請求項４乃至６のいずれか１項に記載の管理方法をコンピュータに実行させることを特徴とするプログラム。
【請求項１】
複数の画像形成装置から、各画像形成装置に設定されている送信スケジュールに従い受信される部門カウンタの情報を、データベースを用いて管理する管理装置であって、
画像形成装置の識別情報、当該画像形成装置から受信した部門ＩＤ、及び該部門ＩＤに対応する部門カウンタの情報を関連付けて前記データベースに登録する登録手段と、
前記データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する特定手段と、
前記特定手段で特定された複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する管理手段と、
前記管理手段で管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する決定手段と、
前記決定手段により決定された各グループの送信スケジュールを各グループに属する画像形成装置に対して設定するための情報を生成し、当該画像形成装置からの要求の応答として生成した情報を送信する送信手段とを備え、
前記管理手段は、前記特定手段で特定された複数の画像形成装置の台数が上限以上の場合は、当該特定された複数の画像形成装置を複数の異なるグループで管理し、
前記決定手段は、前記管理手段により前記特定手段で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理された場合、当該複数のグループ間においては前記第１の時間間隔よりも短い第２の時間間隔で送信スケジュールを決定することを特徴とする管理装置。
【請求項２】
前記データベースに登録された情報に基づき、画像形成装置から受信する部門カウンタの情報の前回受信時からの増加分が既定値に満たない場合は、当該部門カウンタの情報に対応する部門ＩＤが当該画像形成装置で利用されていないとみなし、
前記特定手段は、前記データベースに登録されていても、利用されていないとみなされた部門ＩＤを除外して、部門ＩＤが重複する複数の画像形成装置を特定することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記管理手段は、前記特定手段で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理する場合には、前記管理手段で管理するグループが見直しされる際に当該複数のグループが識別できるように管理することを特徴とする請求項１または２に記載の管理装置。
【請求項４】
複数の画像形成装置から、各画像形成装置に設定されている送信スケジュールに従い受信される部門カウンタの情報を、データベースを用いて管理する管理装置における管理方法であって、
画像形成装置の識別情報、当該画像形成装置から受信した部門ＩＤ、及び該部門ＩＤに対応する部門カウンタの情報を関連付けて前記データベースに登録する登録工程と、
前記データベースに登録された情報に基づき、利用する部門ＩＤが重複する複数の画像形成装置を特定する特定工程と、
前記特定工程で特定された複数の画像形成装置の台数が上限未満の場合は、当該特定された複数の画像形成装置を同じグループで管理する管理工程と、
前記管理工程で管理される複数のグループ対して、少なくとも第１の時間間隔をあけて各グループに属する画像形成装置から部門カウンタの情報が送信されるよう、各グループの送信スケジュールを決定する決定工程と、
前記決定工程により決定された各グループの送信スケジュールを各グループに属する画像形成装置に対して設定するための情報を生成し、当該画像形成装置からの要求の応答として生成した情報を送信する送信工程とを備え、
前記管理工程は、前記特定工程で特定された複数の画像形成装置の台数が上限以上の場合は、当該特定された複数の画像形成装置を複数の異なるグループで管理し、
前記決定工程は、前記管理工程により前記特定工程で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理された場合、当該複数のグループ間においては前記第１の時間間隔よりも短い第２の時間間隔で送信スケジュールを決定することを特徴とする管理方法。
【請求項５】
前記データベースに登録された情報に基づき、画像形成装置から受信する部門カウンタの情報の前回受信時からの増加分が既定値に満たない場合は、当該部門カウンタの情報に対応する部門ＩＤが当該画像形成装置で利用されていないとみなし、
前記特定工程は、前記データベースに登録されていても、利用されていないとみなされた部門ＩＤを除外して、部門ＩＤが重複する複数の画像形成装置を特定することを特徴とする請求項４に記載の管理方法。
【請求項６】
前記管理工程は、前記特定工程で特定された複数の画像形成装置の台数が上限以上のために当該特定された複数の画像形成装置が複数の異なるグループで管理する場合には、前記管理工程で管理するグループが見直しされる際に当該複数のグループが識別できるように管理することを特徴とする請求項４または５に記載の管理方法。
【請求項７】
請求項４乃至６のいずれか１項に記載の管理方法をコンピュータに実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１０−２１８１３５（Ｐ２０１０−２１８１３５Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６３１４１（Ｐ２００９−６３１４１）
【出願日】平成２１年３月１６日（２００９．３．１６）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１６日（２００９．３．１６）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]