(57)【要約】【課題】単純なＣＰＵ稼働率だけを見て機能をどのデバイスに配置すべきかを決定すると、画像形成装置の連携の場合、普段あまり使われずスリープ状態でいられるデバイスなどに親機能が配置されてしまう。その結果親機能を提供するためだけにシステムを起動し続ける状態になってしまい省エネではない。【解決手段】親子連携がどの程度頻繁に行われているのかに加えて、プリントやスキャンなどのデバイス単体の動作の状態を集計して、なるべくデバイス単体の動作の少ないデバイスには親機能を配置しないように制御を行うことで全体最適で省エネを実現する。【選択図】  図３
2015166947.tif 000002
【特許請求の範囲】
【請求項１】
同一ネットワーク環境上に複数の画像形成装置が存在し、ネットワークを介して画像形成装置間でのクライアント・サーバの機能連携が行われる環境下の画像形成装置であって、
画像形成装置単体で動作する機能によって定まる装置単体使用率（５０１）と、
画像形成装置同士が通信して連携して提供する機能によって定まる連携機能使用率（５０２、５０３）を、画像形成装置の機能が動作するたびに保存する使用率保存手段（３１０）と、
前記装置単体使用率と前記連携機能使用率を複数の画像形成装置から集計する集計手段（３２０）と、
前記集計手段が集計した使用率情報（３１１）に基づいて連携機能のサーバとクライアントの最適配置を分析する最適配置分析手段（３３０）と、
前記最適配置分析手段の分析結果にしたがって機能配置を制御する最適配置制御手段（３３１）を具備することを特徴とする画像形成装置。
【請求項２】
最適配置分析手段であって、なるべく装置単体使用率の高く、連携機能の高いデバイスに連携機能のサーバ機能を移譲するよう分析することを特徴とする請求項１に記載の画像形成装置。
【請求項３】
装置単体使用率としては、プリント枚数、スキャン枚数、ファックス送受信枚数を指標にすることを特徴とする請求項１に記載の画像形成装置。
【請求項４】
装置単体使用率としては、消耗ユニットの摩耗度合いを指標とすることを特徴とする請求項１に記載の画像形成装置。
【請求項５】
装置単体使用率としては、コントローラへの累積通電時間を指標とすることを特徴とする請求項１に記載の画像形成装置。
【請求項６】
最適配置制御手段であって最適配置分析手段の分析結果を画面に表示してユーザに配置換えを促すことを特徴とする請求項１に記載の画像形成装置。
【請求項７】
最適配置制御手段であって最適配置分析手段の分析結果を使って、自動的にサーバ機能を別の画像形成装置に移動させ、クライアント機能を持つ画像形成装置にサーバ機能の移譲を伝え、新たなサーバに切り替え、さらに旧サーバ機能を停止させる制御を行うことを特徴とする請求項１に記載の画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、同一フロアなどに複数の画像形成装置が配置される環境下において、画像形成装置同士が通信を行い１つの機能提供を行う状況における画像形成装置の最適な配置に関する。
【背景技術】
【０００２】
画像形成装置がネットワークに接続し、複数の画像形成装置間でデータを送受し、複数画像形成装置で機能連携して、ユーザに機能提供するものがある。
【０００３】
例えば１つの画像形成装置に複数台で共有するデータを保存し、連携する各画像形成装置はそのデータを必要な時に取り出す。どこかの画像形成装置でこれを編集するとその共有データが更新されるといったデータの共有サーバとなる連携機能がある。
【０００４】
またプリントジョブなどユーザから投入されたジョブ情報を、１つの画像形成装置にスプールしておき、ユーザが任意の画像形成装置でジョブ実行の操作を行うことで、どの画像形成装置でも印刷できる、複数画像形成装置が連携した留め置きプリント機能もある。      
【０００５】
これらの仕組みを利用すると基本的にはクライアント・サーバのモデルになる。他のデバイスに機能を提供するサーバ（以降ではこれを「親機能」と記載する）となる画像形成装置（以降「親デバイス」）と、親デバイスにアクセスし親機能を利用するクライアントとなる画像形成装置（以降「子デバイス」）として役割を分担することになる。また、子デバイスが親デバイスに対して処理を依頼し、子デバイスが処理結果を受け取る処理全体を「親子連携」と記載する。
【０００６】
一般的に子デバイスが増えると親デバイスの処理負荷が上がるためこれを分散するために、親機能をもった親デバイスを２重化するなどすることで連携の負荷分散を行うような手法は提案されている（特許文献１）。
【０００７】
また特定の条件設定下において自動的に親デバイスを選択し親機能をアクティベートするような提案もなされている（特許文献２）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−２５１６６０号公報
【特許文献２】特開２００３−１８６７６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
先行件では、親機能の２重化や、親デバイスと子デバイスの入れ替えで処理の負荷を分散することを目的とした処理を行っていた。しかしながら画像形成装置の場合、親子連携のみがユーザに提供する機能ではなく、通常のコピー、スキャン、プリント、ファックスといった画像形成装置単体で処理を提供する必要がある。またこれら機能が利用されていない場合は画像形成装置は自動的にスリープ状態に入りオフィス全体の省エネに貢献するといった運用を行えるような制御が備わっている。
【００１０】
しかし多くの場合親機能が動作している親デバイスは子デバイスから問い合わせに応答するために、スリープしていても通電してスリープ復帰し、子デバイスからの問い合わせに応答する必要がある。
【００１１】
このような構成下では、どの画像形成装置を親デバイスとして機能させるかによってオフィス全体の省エネ効果が格段に異なってくるが、先行件のように負荷分散だけを考慮した親子連携の制御では、これを解決できない。
【課題を解決するための手段】
【００１２】
本課題を解決するために、
同一ネットワーク環境上に複数の画像形成装置が存在し、ネットワークを介して画像形成装置間でのクライアント・サーバの機能連携が行われる環境下の画像形成装置であって、
画像形成装置単体で動作する機能によって定まる装置単体使用率（５０１）と、
画像形成装置同士が通信して連携して提供する機能によって定まる連携機能使用率（５０２、５０３）を、画像形成装置の機能が動作するたびに保存する使用率保存手段（３１０）と、
前記装置単体使用率と前記連携機能使用率を複数の画像形成装置から集計する集計手段（３２０）と、
前記集計手段が集計した使用率情報（３１１）に基づいて連携機能のサーバとクライアントの最適配置を分析する最適配置分析手段（３３０）と、
前記最適配置分析手段の分析結果にしたがって機能配置を制御する最適配置制御手段（３３１）を具備することを特徴とする。
【発明の効果】
【００１３】
これにより、画像形成装置間の連携機能が行われるネットワーク環境下で、負荷を軽減しかつ省エネな、装置間連携を実現する最適配置を得ることができる。
【図面の簡単な説明】
【００１４】
【図１】本願発明のネットワーク構成を示す図である。
【図２】本願発明のハードウェア構成を示す図である。
【図３】本願発明に係る画像形成装置内のソフトウェア構成を示す図である。
【図４】本願発明の分析対象となる稼働状況のイメージを示す図である。
【図５】本願発明のカウンタストレージ３１１の内部情報の例を示す図である。
【図６】本願発明の集計結果ストレージ３２１の内部情報の例を示す図である。
【図７】本願発明第１〜第４の実施形態における単一の親機能をどのデバイスに配置するべきかを分析する最適配置分析モジュールのフローチャートである。
【図８】本願発明第１〜第４の実施形態における複数の親機能をどのデバイスに配置するべきかを分析する最適配置分析モジュールのフローチャートである。
【図９】本願発明第４の実施形態おける、親機能の自動移行を説明するフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態を図面に基づいて説明する。
【００１６】
図１は本発明の実施の形態に係る本願発明の画像処理装置を含むシステムの全体構成を示すブロック図である。
【００１７】
本発明は、１つの閉じたネットワーク環境上に複数台の画像形成装置が稼働している状況下を想定している。
【００１８】
システムは、画像処理装置１１０，１２０，１３０、ＰＣ１４０などの複数のネットワーク機器と、ネットワーク機器群が接続されているＬＡＮ１００から構成される。
【００１９】
画像処理装置１１０は、画像の入出力と送受信および各種の画像処理を行う複合機（ＭＦＰ；Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）である。
【００２０】
画像入力デバイスであるスキャナ１１３、画像出力デバイスであるプリンタ１１４、コントロールユニット１１１、およびユーザインタフェースである操作部１１２、外部ストーレジメモリメディア１１５を有する。
【００２１】
スキャナ１１３、プリンタ１１４、操作部１１２、およびメモリメディア１１５は、それぞれ、コントロールユニット１１１に接続され、コントロールユニット１１１からの命令によって制御される。
【００２２】
各画像処理装置１２０、１３０は、画像処理装置１１０と同様の機器構成を有し、それらは同様にＬＡＮ１００に接続されている。画像処理装置１２０は、スキャナ１２３、プリンタ１２４、操作部１２２およびスキャナ１２３、プリンタ１２４、操作部１２２のそれぞれを制御するコントロールユニット１２１を備える。画像処理装置１３０は、スキャナ１３３、プリンタ１３４、操作部１３２およびスキャナ１３３、プリンタ１３４、操作部１３２のそれぞれを制御するコントロールユニット１３１を備える。
【００２３】
またコントロールユニット１２１および１３１は１１１と同様にメモリメディア１１５を接続することが可能である。
【００２４】
また、ＰＣ１４０は、画像処理装置１１０、１２０、１３０とＬＡＮ１００を介して通信可能で、画像処理装置１１０や１２０や１３０にプリントジョブを投入したり、画像処理装置１１０や１２０や１３０でスキャンし生成された画像を受信することができる。
【００２５】
次に、画像処理装置１１０の構成について図２を参照しながら説明する。図２は図１の画像処理装置１１０の詳細構成を示すブロック図である。ここでは、各画像処理装置１１０，１２０の構成は、同じであるので、画像処理装置１１０の構成を説明するものとする。
【００２６】
画像処理装置１１０は、図２に示すように、装置全体を制御するコントロールユニット１１１を備える。コントロールユニット１１１は、画像入力デバイスであるスキャナ１１３や画像出力デバイスであるプリンタ１１４を接続し、これらを制御する一方、ＬＡＮや公衆回線と接続され、これらを介して画像情報やデバイス情報の入出力を行うものである。
【００２７】
コントロールユニット１１１は、ＣＰＵ２０１を有する。
【００２８】
ＣＰＵ２０１は、システムバス２０７を介して、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ（ハードディスク装置）２０４、イメージバスＩ／Ｆ２０５、操作部Ｉ／Ｆ２０６、ネットワークＩ／Ｆ２０８、およびモデム２０９と接続される。
【００２９】
ＲＡＭ２０２は、ＣＰＵ２０１の作業領域を提供するためのメモリであり、また、画像データを一時記憶するための画像メモリとしても使用される。ＲＯＭ２０３はブートＲＯＭであり、ＲＯＭ２０３には、システムのブートプログラムが格納されている。ＨＤＤ２０４には、システムソフトウェア、画像データなどが格納される。
【００３０】
操作部Ｉ／Ｆ２０６は、操作部１１２との間で入出力を行うためのインタフェースであり、操作部１１２に表示する画像データを操作部１１２に対して出力し、ユーザが操作部１１２を介して入力した情報を、ＣＰＵ２０１に伝送するなどの役割を果たす。
【００３１】
ネットワークＩ／Ｆ２０８は、ＬＡＮと接続され、ＬＡＮに対して情報の入出力を行う。モデム２０９は、公衆回線と接続され、公衆回線に対して情報の入出力を行う。
【００３２】
イメージバスＩ／Ｆ２０５は、システムバス２０７と画像データを高速で転送する画像バス２１０とを接続し、データ構造を変換するバスブリッジである。
【００３３】
画像バス２１０には、ＲＩＰ（ラスタイメージプロセッサ）２１１、デバイスＩ／Ｆ２１２、スキャナ画像処部２１３、プリンタ画像処理部２１４、画像回転部２１５、および画像圧縮部２１６が接続されている。
【００３４】
ＲＩＰ２１１は、ＬＡＮから受信されたＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ２１２は、スキャナ１１３およびプリンタ１１４とコントロールユニット１１１とを接続し、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部２１３は、入力画像データに対し補正、加工、編集などを行う。プリンタ画像処理部２１４は、プリント出力画像データに対して、プリンタの補正、解像度変換などを行う。画像回転部２１５は、画像データの回転を行う。画像圧縮部２１６は、多値画像データに対してはＪＰＥＧ圧縮伸長処理を行い、２値画像データに対してはＪＢＩＧ，ＭＭＲ，ＭＨなどの圧縮伸長処理を行う。
【００３５】
外部ストレージＩ／Ｆ２１７は、メモリメディア１１５と接続され、メモリメディア１１５へ機器内のデータや画像を保存する、あるいはメモリメディア１１５内のデータを機器内に書き込む際に利用される。
【００３６】
続いて図３を用いて画像処理装置１１０のソフトウェア構成について説明する。図３に示すソフトウェア構造はＲＯＭ２０３にプログラムとして保存され、実行時にＣＰＵ２０１によってＲＡＭ２０２にロードされて実行される。
【００３７】
また画像形成装置を機能させるために必要なソフトウェアモジュールのうち本発明の構成要件に必要なモジュールだけを抜粋して記載している。
【００３８】
ネットワーク通信モジュール３０１はネットワークＩ／Ｆ２０８を利用しＬＡＮ１００を通して通信の制御を行う、Ｗｅｂサービスなどを利用する形態で必要なデータの通信を行う。コンテンツプロバイダモジュール３０２は、事前に定義した親デバイスとなる親機能を提供するサーバーモジュールである。ネットワーク通信モジュールを利用しながら同一フロア内の別の画像形成装置からのリクエストを受けて、処理を行い、結果を返却したり、必要なデータを送信したりするなどを行う。
【００３９】
コンテンツリクエスタモジュール３０３が親機能を利用するクライアントモジュールである。同様にネットワーク通信モジュールを利用して別の親機能のコンテンツプロバイダモジュール３０２と通信を行い必要な処理を依頼したり、必要なデータを取得したりなどを行う。
【００４０】
なお、コンテンツプロバイダ３０２およびコンテンツリクエスタ３０３は画像形成装置内に唯一ではなく、提供するサービスごとに複数のペアが存在している状態となる。
【００４１】
例えば、画像形成装置間で共有データ連携機能と、留め置き印刷機能の両方がシステム内でサポートされていれば、共有データ連携機能用のコンテンツプロバイダとコンテンツリクエスタが存在する。さらに留め置き印刷機能用のコンテンツプロバイダとコンテンツリクエスタといった４つのモジュールが画像形成装置内に存在することになる。
【００４２】
ジョブ制御モジュール３０４は画像形成装置内で発生するジョブを管理するモジュールである。ジョブとはコピー、センド、スキャン、プリント、ファックス、画像変換など様々な画像形成に係る処理の単位である。ジョブ制御モジュール３０４はデバイスＩ／Ｆ２１２を介してスキャナ１１３およびプリンタ１１４を利用する。
【００４３】
画面制御モジュール３０５は操作部Ｉ／Ｆ２０６を介して操作部１１２に画面を表示したり、ユーザの操作部操作による指示をジョブ制御モジュールに伝えジョブを実行するなどの制御を行う。
【００４４】
機能カウントモジュール３１０はシステム内の各所からの指示を受けて、使用されたリソースをカウンタストレージ３１１に書き込む処理を行う。カウンタストレージ３１１はＨＤＤ２０４内に不揮発データとして保存される。詳細は後述するがジョブ制御モジュール３０４からの指示を受け、プリント枚数、スキャン回数等のカウントを行う。またコンテンツプロバイダモジュールから指示を受け他の画像形成装置からのアクセス回数を、コンテンツリクエスタモジュールからの指示を受け、他の画像形成装置へのアクセス回数などをカウントし保存する機能性を有する。
【００４５】
集計モジュール３２０はカウンタストレージの内容を読み出すとともにネットワーク通信モジュール３０１を介して別の画像形成装置の集計モジュール３２０と通信を行い、別の画像形成装置のカウンタストレージ３１１の情報を読み出す。関係する全ての画像形成装置からの集計結果を集計結果ストレージ３２１に保存する。
【００４６】
最適配置分析モジュール３３０は最適配置制御モジュール３３１の指示に従って集計結果ストレージ３２１の情報を元にして、コンテンツプロバイダモジュール３０２とコンテンツリクエスタモジュール３０３がどの画像形成装置上で動作するのが最適かを計算する。
【００４７】
なお、複数の画像形成装置が連携し合う中においては、コンテンツプロバイダモジュール３０２は１台の画像形成装置でのみアクティベートされ機能している状態が望ましく、その際他の画像形成装置では機能しない。またコンテンツリクエスタモジュール３０３に関しては、該当の画像形成装置上で利用しない設定等で動作しない場合は機能しない状態となることが望ましい。
【００４８】
続いて図４以降で具体的な運用例について説明する。
【００４９】
図４は本願発明を適用するに際して、画像形成装置の連携機能が運用されている状態をシミュレートしたものである。
【００５０】
この仮想状態では同一イントラネット環境上に５台の画像形成装置が配置されＤｅｖ１に親機能Ａのコンテンツプロバイダが稼働しており、Ｄｅｖ２に親機能Ｂのコンテンツプロバイダが稼働している状態である。
【００５１】
特定の期間内におけるカウンタストレージ３１１内部に保持されるカウンタ情報を図示している。Ｐｒｉｎｔは特定期間内にプリント機能が動作した回数。Ｓｃａｎは同様にスキャナが動作した回数を示し、画像形成装置間の矢印は親機能Ａもしくは親機能Ｂを利用した回数を表現している。
【００５２】
例えばＤｅｖ１に着目すると集計の対象期間内にプリントが１０００回、スキャナが２０００回動作していることを意味する。さらに親機能Ａの利用としては、Ｄｅｖ１（自分自身）から１００回、Ｄｅｖ３から１０回、Ｄｅｖ４から２００回のアクセスがあり、親機能Ｂを利用するためにＤｅｖ２に対して５０回の処理依頼を行ったという状態を示している。
【００５３】
この状況をＤｅｖ１のカウンタストレージ３１１に保存されているテーブルの状態として示しているのが図５である。
【００５４】
ここでこの後使用する言葉の定義を行うが、図５の表中の「プリント」、「スキャン」カラムに属す画像形成装置単体で提供する機能の使われた回数を示すパラメータを「デバイス稼働率」（５０１）とする。
【００５５】
「親機能Ａ提供」「親機能Ｂ提供」などの親機能の提供を行うコンテンツプロバイダの使われた回数などを示すパラメータは「親機能稼働率」（５０２）とする。
【００５６】
最後に「親機能Ａ利用」「親機能Ｂ利用」のコンテンツリクエスタからの親機能の使われ方を示すパラメータを「親機能利用率」（５０３）と以下で記載することとする。
また以降の説明およびフォローチャート内では特に断らない限り「デバイス」は画像形成装置そのものを指すものとする。
【００５７】
またここでは「デバイス稼働率」の例としてプリントの枚数カウントとスキャナの枚数のカウントを上げているが、デバイスの単体の稼働率の指標になるものであればよい。したがってドラムなどの消耗品の利用回数や、コントローラへの累積通電時間などを指標にしてもよい。ここではプリントとスキャナの使用状況を例に記載する。
【００５８】
第１実施の形態では、最適配置制御モジュール３３１は特定の画像形成装置上で定期的に動作するものとする。最適配置制御モジュール３３１はここでは仮にＤｅｖ１上で動作しているものとする。
【００５９】
Ｄｅｖ１上の最適配置制御モジュール３３１はあらかじめ設定されたタイマなどに従って定期的に最適配置分析モジュール３３０に分析処理を依頼する。
【００６０】
Ｄｅｖ１上の最適配置分析モジュール３３０はＤｅｖ１上の集計モジュール３２０に対して集計指示を出す。Ｄｅｖ１上の集計モジュール３２０は自分自身のカウンタストレージ３１１の内容を読み出す。その後集計結果ストレージ３３０に情報を書き込むと共に、連携しているＤｅｖ２〜５の集計モジュールに対してネットワーク通信モジュール３０１を通して処理を依頼する。さらにＤｅｖ２〜５のそれぞれのカウンタストレージの中身を読み出してＤｅｖ１の集計モジュールに通知する。各画像形成装置から集計結果を受け取ったＤｅｖ１上の集計モジュール３２０は各画像形成装置のカウンタ情報を集計結果ストレージ３２１に書き込む。
【００６１】
書き込まれた情報は図６に示されるようなテーブルとして集計される。
図５のように各デバイス上で保持されていた情報の集計であるため、図５同様にデバイス稼働率６０１、親機能利用率６０２、親機能利用率６０３の情報からなる。
【００６２】
最適配置分析モジュール３３０は全ての集計結果が保存された後に、集計結果ストレージ３２１に保存された情報から、親機能の最適配置を分析する。
【００６３】
最適配置分析モジュール３３０は分析結果を最適配置制御モジュール３３１に通知し、最適配置制御モジュールは結果を受けてユーザに対して表示を行う。
【００６４】
図７、および図８のフローチャートを用いて親機能の最適配置結果の導出方法について説明する。
【００６５】
図７は最適配置分析モジュール３３０が１つの親機能に対して、どの画像形成装置に配置することが最適かを判断し、現在の親デバイスから親機能の移譲先の画像形成装置を決定するためのフローチャートである。ここでは図４の環境から取得された図６の情報を具体例として交えながらフローについて説明する。
【００６６】
最適配置分析モジュール３３０は分析を開始する際にＳ７０１においてまず、処理の入力として、分析対象になるデバイスの一覧を得る、図４の例ではＤｅｖ１〜Ｄｅｖ５の５台の画像形成装置が対象である。また分析対象となる親機能を１つ得る。例えば図４の例では親機能Ａであるとする。続いて最適配置分析モジュール３３０はＳ７０２で移譲先の候補リストを初期化する。ここまでが処理の前準備である。
【００６７】
Ｓ７０３では入力された全ての分析対象デバイスについて１つずつ以降の処理を行う。
【００６８】
最適配置分析モジュール３３０はＳ７０４ではデバイス稼働率の比較を行う。図６の例で親機能Ａについて分析を行う場合、親機能Ａが搭載されているのはＤｅｖ１であるため、Ｄｅｖ２〜Ｄｅｖ５のデバイスに対してＤｅｖ１の稼働率と比較を行うことになる。最適配置分析モジュール３３０はＳ７０４でＤｅｖ１のデバイス稼働率よりも対象デバイスのデバイス稼働率が低ければ何もせず次のデバイスへ処理を進める。Ｄｅｖ１よりもデバイス稼働率が高いデバイスの場合にはＳ７０５に進み。該当の親機能Ａの利用率についての比較を行う。対象デバイスの親機能使用率の方が低ければ何もせず次のデバイスへ処理を進める。
【００６９】
ここで親機能使用率が高いデバイスが存在するとＳ７０６に進み、ここで最適配置分析モジュール３３０は移譲先候補リストに対象のデバイスを追加する。ここで追加されるデバイスは、現在の親デバイスよりもデバイス稼働率が高く、親機能利用率も高いデバイスであるということになる。図６の例ではＤｅｖ４だけがここで保存されることになる。
【００７０】
全ての対象デバイスに対して処理を完了すると。移譲先対象リストに親機能を委譲したほうが好ましいデバイスの一覧が登録された状態になる。
【００７１】
次に最適配置分析モジュール３３０はＳ７０７においてこのリストの中身をチェックする。中身に情報が入っていなければ、Ｓ７０８に進む。これは現在の親デバイスに親機能を搭載して置く事が望ましいという結論になるため、本フローのアウトプットである移譲先デバイスとしては現在のデバイスのままが良いという情報を埋めて処理を終了する。
【００７２】
Ｓ７０７においてリストに１台以上のデバイスが存在する場合はＳ７０９に進み、リスト上に１台のみか複数台が保持されているかをチェックする。
【００７３】
複数デバイスが存在している場合はＳ７１０に進み、その中で最もデバイス稼働率が高いデバイスを移譲先デバイスとして決定する。候補が複数存在する場合、最も効果的な判断をするためにはデバイス稼働率が最も高いデバイスに親機能を預けることが最も省エネ効果が高いと想定できるためである。
【００７４】
Ｓ７０９でリストに１つだけのデバイスが存在する場合は、これを移譲先デバイスとして確定する。図６の例ではＳ７０７の時点でＤｅｖ４のみが保存された状態になっているためこのフローを通り、Ｄｅｖ４が移譲先として決定する。
【００７５】
このように単一の親機能に対して、親機能がどのデバイスに所属することが望ましいかを集計結果ストレージ３２１に保存された集計結果から算出することができる。
【００７６】
続いて同一イントラネット環境上に複数の親機能が混在している場合の最適配置分析モジュール３３０の処理シーケンスについて図８のフローチャートを用いて説明する。
【００７７】
まず最適配置分析モジュール３３０はＳ８０１においてこの処理シーケンスの入力として親機能の一覧と、分析対象デバイスの一覧を得る。図４の例では親機能は親機能Ａおよび親機能Ｂの２つ、対象デバイスはＤｅｖ１からＤｅｖ５の５台である。
【００７８】
以降で最適配置分析モジュール３３０はＳ８０２で親機能一覧の中の１つ１つの親機能に対して下記の処理を行う。
【００７９】
Ｓ８０３では、選択された１つの親機能と対象デバイスの一覧を使って図７で説明したフローチャートをサブルーチンとして呼び出す。これにより単一の親機能だけで判断した場合どのデバイスに親機能を委譲すべきかの処理結果が戻ってくる。図６の例では上述した通り親機能Ａの場合はＤｅｖ４が処理結果として戻ってくる。これを受けて最適配置分析モジュール３３０はＳ８０４では結果（親機能Ａ、Ｄｅｖ４）を仮決定移譲先リストに追加する。同様に親機能ＢについてもＳ８０３のサブルーチンコールを行うとＤｅｖ４が戻ってくるため（親機能Ｂ、Ｄｅｖ４）を仮決定移譲先リストに追加することになる。
【００８０】
全ての親機能に対して処理を終えると最適配置分析モジュール３３０はＳ８０５において仮決定移譲先リスト内に同一デバイスが複数回登場していないかをチェックする。
登場していない場合は、Ｓ８１０に進み、仮決定リストの内容を確定移譲先として処理を終了する。
【００８１】
同一デバイスが複数回登場する場合はＳ８０６に進み、設定として親機能の同一デバイス上での共存が許可されるモードか否かを確認し、共存可であればやはりＳ８１０に進み、仮決定リストの内容を確定移譲先として処理を終了する。
【００８２】
Ｓ８０６で共存否の設定がなされている場合はＳ８０７に進む。
【００８３】
最適配置分析モジュール３３０はＳ８０７で、仮決定リスト上で複数の親機能の移譲候補とされたデバイスの該当親機能を保持している元親デバイスの親デバイス稼働率を比較する。これが最も高いデバイスを確定親機能とし、その機能の移譲候補として親デバイスを確定する。最も稼働されている親機能を優先的に配置することが効率的であるという判断基準からである。
【００８４】
図６の例では親機能Ａと親機能Ｂでは親機能Ａの方が稼働率が高いため親機能Ａの方が優先的に確定し、親機能Ａの移譲先がＤｅｖ４として決定することになる。
ここで１つの親機能の移譲先が決まると、Ｓ８０８に進む。
【００８５】
Ｓ８０８では確定した親機能を親機能一覧から、およびその移譲先として確定した親デバイスを分析対象一覧から除去し、仮決定のリストを初期化する。これをインプットとして再度Ｓ８０２からの処理を再帰的にコールする。
【００８６】
図６の例では、Ｄｅｖ４および親機能Ａが除外された状態でＳ８０２以降の処理がすすみ、Ｓ８０５まで進んだ段階で仮決定移譲先リストには（親機能Ｂ、Ｄｅｖ１）が記述されることになる。この状態でＳ８０５の判断を経てＳ８１０へ進み処理が終了することになる。
【００８７】
以上の処理の結果確定移譲先リストには（親機能Ａ、Ｄｅｖ４）（親機能Ｂ、Ｄｅｖ１）という結果が得られ、親機能ＡをＤｅｖ１→Ｄｅｖ４へ、親機能ＢをＤｅｖ２→Ｄｅｖ１へ移譲することが望ましいと最適配置分析モジュール３３０がいう判断下すことになる。
【００８８】
この判断の結果を最適配置分析モジュール３３０は最適配置制御モジュール３３１に返して処理を終了する。
【００８９】
本実施形態では、分析結果を受け取った最適配置制御モジュール３３１は親機能の移譲が必要ないという結果が出ていれば、特に何もせず次回の起動のタイマを仕掛けて終了する。
【００９０】
移譲を行った方が良いという分析結果を受けていれば、その結果を画面制御モジュール３０５に渡し、画面制御モジュール３０５は操作部Ｉ／Ｆ２０６を介してその結果を操作部１１２に表示することでユーザにレコメンドを行う。
【００９１】
以上で本願発明第１実施の形態の説明を終わる。
【００９２】
引き続き本願発明の別の実施形態について説明する。
【００９３】
以下の別の実施形態でも基本的なモジュール構成等は第１の実施系と同様のため再度の説明は割愛するがハード構成およびソフト構成は図１、２および図３と同様である。
【００９４】
第２実施の形態について説明する。
【００９５】
第１実施の形態ではある１台の画像形成装置の最適配置分析モジュールだけが定期的に起動して集計モジュールにキックをかけて集計を行う状態としたが、本機能はＰＣなどの汎用情報処理装置上のプログラムとして実装することが可能である。
【００９６】
ＰＣ１４０などの情報処理装置上に最適配置制御モジュール３３１および最適配置分析モジュール３３０および集計結果ストレージ３２１を具備する。これがネットワークを介して各デバイスの集計モジュールにキックをかけ各画像形成装置上のカウンタストレージ３１１の情報を吸い上げ、第１実施の形態と同様に最適配置を分析する。
【００９７】
続いて第３実施の形態について説明する。
【００９８】
第１実施の形態ではある１台の画像形成装置の最適配置制御モジュール３３１だけが定期的に起動して集計モジュールにキックをかけて集計を行う状態とした。第３実施の形態では定期起動する代わりに特定の条件が発生した場合に最適配置制御モジュール３３１が起動する形態の実施が可能である。
【００９９】
親機能を提供している画像形成装置の機能カウントモジュール３１０に対してあらかじめ閾値や条件を設定しておき、カウンタストレージ３１１に書き込みを行う際に、その閾値に到達した場合に最適配置制御モジュール３３１に対して処理開始のキックをかける。
設定する閾値は、デバイス稼働率に対する親機能稼働率の比で設定することが望ましい。プリンタ、スキャナの使用状況が低い状態であって親機能の提供頻度の高い状態になった場合は、スリープに入れる時間が短くなっていることが想像される。この場合別の画像形成装置の稼働状況を集計し分析すると親機能を別デバイスに移譲することが望ましいという結果が出ることが想定されるためである。動作のキックをかけた後は第１実施の形態と同様に最適配置を分析する。
【０１００】
続いて第４実施の形態について説明する。
【０１０１】
第１〜第３実施の形態では、集計および分析後にユーザに対して親機能を別の画像形成装置に移譲することが望ましいというレコメンドを画面上に表示するところまでを実施する例として記載した。第４実施の形態ではレコメンドの代わりに実際に自動的に親子関係を入れ替えてしまうものとする。
【０１０２】
図９のフローチャートでは最適配置分析モジュール３３０の分析の結果、親機能の移譲を実施したほうが良いという結論を最適配置制御モジュール３３１が受けた際に、最適配置制御モジュール３３１が行う親機能の自動入れ替え動作について説明する。第１〜第３のどの実施形態においてもこの第４の実施形態への置き換えが可能である。
【０１０３】
図９ではそれまで親機能を担っていた旧親デバイスと、これから親機能を委譲される新親デバイスとそのどちらでもない親機能を利用する子デバイスのそれぞれの処理を並列に記載している。
【０１０４】
まず旧親デバイスの親機能移行処理について説明する。
【０１０５】
旧親デバイスの最適配置制御モジュール３３１はＳ９０１において、最適配置分析モジュール３３０が分析した親機能の移行先のデバイスに対して処理開始通知を出す。これに正しく応答が返れば、最適配置制御モジュール３３１はＳ９０２においてコンテンツプロバイダ３０２に指示にコンテンツプロバイダ３０２は親機能に必要でそれまで蓄積していたデータを新親デバイスにコピーする。
【０１０６】
データの移行処理が終わると、Ｓ９０３、Ｓ９０４において最適配置制御モジュール３３１は最適配置分析モジュールが分析時に分析対象とした全デバイスに対して親デバイスの変更を通知する。
【０１０７】
その後、最適配置制御モジュール３３１はＳ９０５において自デバイスのコンテンツリクエスタ３０３に対して親デバイスの登録の変更を指示する。その後Ｓ９０６においてコンテンツリクエスタ３０３は新親デバイスに対して通信の確認処理を行う。
【０１０８】
正しく通信できた後、最適配置制御モジュール３３１がＳ９０７において新親デバイスから移譲処理の完了通知を受けると、Ｓ９０８において最適配置制御モジュール３３１の指示によりコンテンツプロバイダ３０２の機能を停止し、親機能の移譲処理を完了する。
【０１０９】
続いて新親デバイス側の処理について説明する。
【０１１０】
Ｓ９１１において新親デバイスの最適配置制御モジュール３３１は旧親デバイスから機能移譲の通知を受ける。これは旧親デバイスのＳ９０１で発行された通知である。内部状態を確認し受付可能な状態であればＳ９１２で最適配置制御モジュール３３１が必要なデータの受信処理を受ける。これは旧親デバイスのＳ９０２で送付されたデータになる。受信が完了したところで、Ｓ９１３において最適配置制御モジュール３３１がコンテンツプロバイダ３０２を起動させる。この際先に受信済みのデータが利用される。
【０１１１】
コンテンツプロバイダ３０２が起動したのち、Ｓ９１４、Ｓ９１５においてコンテンツプロバイダ３０２は旧親デバイスから指示を受けた全デバイス（新たに子デバイスになる）からの通信確認が到達することを確認する。
【０１１２】
確認が取れたらＳ９１６にて最適配置制御モジュール３３１は旧親デバイスに対して親機能の移譲完了の通知を送付して、親機能の移譲処理を完了する。
【０１１３】
最後に子デバイスの動きについて説明する。
【０１１４】
子デバイスはＳ９２１において最適配置制御モジュール３３１は旧親デバイスから親デバイスの変更通知を受ける。これは旧親デバイスのＳ９０４にて発行された通知である。これを受けた最適配置制御モジュール３３１はＳ９２２において自デバイスのコンテンツリクエスタ３０３に対して親デバイスの登録の変更を指示する。その後Ｓ９２３においてコンテンツリクエスタ３０３は新親デバイスに対して通信の確認処理を行う。正しく通信が確認されれば以降は新たな親デバイスから親機能の提供を受ける。
【０１１５】
説明の都合上各所での通信異常などのエラーケースを記載していないが、全ての処理の途中で異常状態に陥った際は、移譲処理を停止してロールバックする実装を行うべきなのは言うまでもない。
【０１１６】
以上で、本発明を実施するための実施形態について説明を終わる。
【符号の説明】
【０１１７】
１１０、１２０、１３０  画像形成装置
３０２  コンテンツプロバイダ（親機能提供モジュール）
３０３  コンテンツリクエスタ（親機能利用モジュール）
３３０  最適配置分析モジュール
３３１  最適配置制御モジュール
【図１】
2015166947.tif 000003
【図２】
2015166947.tif 000004
【図３】
2015166947.tif 000005
【図４】
2015166947.tif 000006
【図５】
2015166947.tif 000007
【図６】
2015166947.tif 000008
【図７】
2015166947.tif 000009
【図８】
2015166947.tif 000010
【図９】
2015166947.tif 000011