JP4921072B2

JP4921072B2 - 画像形成装置、リソース保持装置、画像形成システム、リソース要求方法、リソース保持方法、リソース管理方法、プログラム

Info

Publication number: JP4921072B2
Application number: JP2006226276A
Authority: JP
Inventors: 一大古賀
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-08-23
Filing date: 2006-08-23
Publication date: 2012-04-18
Anticipated expiration: 2026-08-23
Also published as: US20080052342A1; JP2008049515A; US8289539B2

Description

本発明は、画像形成装置のリソース要求処理に関するものである。

近年の画像形成装置は、画像形成装置本来の画像形成機能に加えて、通信インタフェースやハードディスクを備え、ネットワークで複数の機器を接続して機器間でデータを送受信してハードディスクに格納することが可能である。

また、ネットワーク接続された画像形成装置では、特許文献１のように、印刷に必要なリソースをネットワーク上の所定のサーバから取得して印刷を実行する装置が提案されている。

このような従来技術によれば、サーバに印刷に必要な関連情報の所在を問い合わせることにより、印刷に必要なリソースを取得することができる。

しかし、ネットワーク上に常駐すべきサーバの設置が必要であり、設定や管理面では手間がかかる。そのため、クライアント・サーバ型の通信技術ではなく、ピアツーピアの通信技術を用いてサーバを設置せずにデバイス同士が情報のやり取りを行い、分散処理を実現する装置が提案されている(例えば特許文献２）。

また、ネットワークでデータをダウンロードを行う場合には、データの再入手性が重要になってくるが、データ提供元の装置で削除を禁止する設定を行える装置が提案されている（例えば特許文献３）。
特開2002−215358号公報特開2005-74881号公報特開2004-110832号公報

上記のように構成された画像形成システムにおいて、印刷に必要なリソースの授受を行う機能をピアツーピアの技術を用いて画像形成装置に適用可能である。この場合、交換するリソースファイルは、ピアツーピアの仕組みを用いれば、お互いにリソース情報を交換し合い、ファイルを交換していくことになる。

しかし、リソースを不揮発性デバイスに保持できない画像形成装置では電源再投入の度に必要なリソースのダウンロードが発生する。例えば、ハードディスクを備えリソースをハードディスクに格納可能な画像形成装置であれば一度リソースをダウンロードしてしまえば電源再投入後にリソースを再度ダウンロードする必要はない。

しかし、安価な画像形成装置ではハードディスクは標準で装着されておらず、電源再投入を行った場合には再度ダウンロードを行う必要がある。よってこのような装置の場合には、なるべく確実にリソースをダウンロードできるようにしておく必要がある。

しかしながら、ピアツーピアの特性上、交換しあっているリソースファイルはディスクの容量上限に伴い、使用頻度の低いものが削除されてしまう。このため、ハードディスクを持たない画像形成装置が前回と同じ画像形成装置からリソースファイルを取得できる保障はない。

よって、ネットワーク上の近隣画像形成装置からリソースを確実にダウンロードできないという問題が発生する場合がある。

このような問題に対して、従来技術ではデータ提供元の装置側でデータをロックする設定を行い格納領域がフルになっても指定データだけは削除されないようにする方法がある。しかし、ピアツーピアのネットワークでは随時ファイル交換が行われるため動的にファイルが追加されていくことから、ファイルを個別にデータ提供元で削除禁止の設定を行うのは手間がかかり困難である。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、リソースを保持不可な画像形成装置でも、画像形成に必要なリソースを他の画像形成装置に保持させ、画像形成時毎にダウンロードして利用できる仕組みを提供することである。

上記目的を達成する本発明の画像形成装置は以下に示す構成を備える。

リソースの保持要求を含むリソースのダウンロード要求を行うか、リソースの保持要求を含まないリソースのダウンロード要求を行うか決定する決定手段と、前記決定手段によりリソースの保持要求を含むリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含むリソースのダウンロード要求を行い、前記決定手段によりリソースの保持要求を含まないリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含まないリソースのダウンロード要求を行う要求手段とを有することを特徴とする。

上記目的を達成する本発明のリソース保持装置は以下に示す構成を備える。

画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードする手段と、画像形成装置から保持要求を含まないリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げることなく、リソースを画像形成装置にダウンロードする手段とを有することを特徴とする。

上記目的を達成する本発明の画像形成システムは以下に示す構成を備える。

リソースの保持要求を含むリソースのダウンロード要求を行う画像形成装置と、画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードするリソース保持装置とを有することを特徴とする。

上記目的を達成する本発明のリソース要求方法は以下に示す構成を備える。

リソースの保持要求を含むリソースのダウンロード要求を行うか、リソースの保持要求を含まないリソースのダウンロード要求を行うか決定する決定ステップと、前記決定ステップによりリソースの保持要求を含むリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含むリソースのダウンロード要求を行い、前記決定ステップによりリソースの保持要求を含まないリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含まないリソースのダウンロード要求を行う要求ステップとを有することを特徴とする。

上記目的を達成する本発明のリソース保持方法は以下に示す構成を備える。

画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードするステップと、画像形成装置から保持要求を含まないリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げることなく、リソースを画像形成装置にダウンロードするステップとを有することを特徴とする。

上記目的を達成する本発明のリソース管理方法は以下に示す構成を備える。

リソースの保持要求を含むリソースのダウンロード要求を行うステップと、保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースをダウンロードするステップとを有することを特徴とする。

本発明によれば、リソースを不揮発に保持する手段を備えていない画像形成装置であっても、画像形成に必要なリソースを他の画像形成装置に保持させ、画像形成時毎にダウンロードして利用することができる。

次に本発明を実施するための最良の形態について図面を参照して説明する。

＜システム構成の説明＞
〔第１実施形態〕
以下、本発明の一実施形態について図面を参照しながら説明する。

図１は、本発明の第１実施形態を示す画像形成システムのシステム構成と基本動作を示した概念図である。なお、本実施形態では、画像形成装置は、プリンタ（ＳＦＰ）、複合機（ＭＦＰ）、コピー機（Ｃｏｐｙ）のいずれかを含む画像形成システム例を説明する。なお、本実施形態では、画像形成システムを利用する情報処理装置のオペレーティングシステム（ＯＳ）として、例えばWindows（登録商標）の例を示す。なお、ＯＳがWindows（登録商標）系のOSでピアツーピア接続を行う際には、「TCP/IP」と「NetBEUI」という代表的な２つのプロトコルを選択可能に構成されている。

ここで、「TCP/IP」はインターネットにも使われているプロトコルで、現在最も利用されているプロトコルである。WindowsXP（登録商標）でも標準のプロトコルとして、あらかじめインストールされている。

図１に示す画像形成システムは、複数の画像形成装置を含み、画像形成装置の種別として複合機（ＭＦＰ）１０１、１０２がＬＡＮ−Ａ１１１を介して接続される。また、プリンタ（ＳＦＰ）１０３、コピー機（Ｃｏｐｙ−１）１０４、コピー機（Ｃｏｐｙ−２）１０５などがＬＡＮ−Ａ１１１を介して接続される。なお、これらの機器を総称する場合は、画像形成装置として記載する。

また、本実施形態では、リソース要求元のＳＦＰ１０３とし、ＳＦＰ１０３は、ハードウエアの構成として、他の画像形成装置からダウンロードしたリソースを不揮発に保持する手段を備えていない画像形成装置として説明する。なお、リソース要求元のＳＦＰ１０３は保持するに十分な不揮発性メモリを備えていない画像形成装置の場合も同様である。

各画像形成装置はネットワークインタフェース（図２に示すＮＩＣ２０４）を備え、対応するＬＡＮに接続しており、ネットワークによる通信が可能である。

図１において、ＬＡＮ−Ａ１１１とＬＡＮ−Ｂ１１２は、ネットワークを中継する装置であるルータ１１３によって接続され、各ＬＡＮ間の通信はルータ１１３によって中継される。

各画像形成装置はピアツーピアネットワークのグループ１１０に参加しており、お互いにピアツーピアの通信手法を用いて装置情報やデータの交換を行うことが可能である。

図１に示した本実施形態では、ＳＦＰ１０３が印刷に必要なリソース（フォントなど）をＭＦＰ−２１０２に対して要求する場合の基本動作について図示している。なお、リソースは、フォントに限らず、フォームの場合も含まれる。

まず、ＳＦＰ１０３は、ピアツーピアネットワークグループ１１０に参加するため、隣接する初期ノードであるコピー機１０４に対してピアツーピアの接続を行い、お互いに所有するリソース情報１２０を交換し合う。

リソース情報１２０の交換を行うことにより、ＳＦＰ１０３は、必要とするリソースがネットワーク上のＭＦＰ１０２に存在することを認識する。ＭＦＰ１０２は既にピアツーピアネットワークグループ１１０に参加しており、自装置が持ち合わせていないリソースをＭＦＰ１０１からリソース１２１をダウンロードする。そして、ダウンロードしたリソース１２１をＲＡＭ２０３に一時的に保持している。つまり、ＳＦＰ１０３が他の画像形成装置からリソースをダウンロードした場合に、そのリソースを利用して印刷処理を実行した後、電源がオフ状態となった場合には、リソース自体は、ＲＡＭ上から消失する。つまり、ＳＦＰ１０３は、ダウンロードしたリソースが電源がオフに以降した後は、再度他の画像形成装置から同一のリソースをダウンロードしなければ、そのリソースを利用する印刷が保証されない画像形成装置である。

しかしながら、ＳＦＰ１０３には、小容量の不揮発性メモリを備えて、ダウンロードしたリソースを記憶している画像形成装置を特定する情報となる、リソース保持を了承したＰｅｅｒを特定する情報を記憶している。なお、上記小容量の不揮発性メモリは、いわゆる、ＲＡＭ領域が電池等でバックアップされるＮＶＲＡＭで構成することが好適である。また、ここで、リソース保持を了承したＰｅｅｒとは、ＭＦＰ１０２のことである。ＳＦＰ１０３がリソースを他の画像形成装置（ＭＦＰ１０２）に要求する際に、そのリソースが削除されないように、リソース保持させる要求を伴ってＭＦＰ１０２にリソース取得要求する。

具体的には、ＳＦＰ１０３は必要とするリソースを持つＭＦＰ１０２に対して、ダウンロード要求１３０を送信し、ダウンロードの許可を求める。

この際、本実施形態の特徴である保持要求を付加してダウンロード要求１３０を送信する。

そして、このダウンロード要求１３０を受信したＭＦＰ１０２は、保持優先度の変更が可能であれば、要求されたリソースの保持優先度を示す保持優先度１３１を高く（Ｈｉｇｈ）に変更設定する。そして、ダウンロード要求１３０を許可するダウンロード応答１３２をＳＦＰ１０３に送信する。

これにより、ＭＦＰ１０２よりダウンロード応答１３２を受信したＳＦＰ１０３では、要求したリソースに対して保持要求を了承してくれたＰｅｅｒであるＭＦＰ１０２の情報をダウンロードが許可されたリソース情報と共に不揮発性メモリに記憶する。この不揮発性メモリとは、小容量のＮＶＲＡＭ等が好適である。

また、この時、ＭＦＰ１０２は、保持管理しているリソースの保持優先度１３１を「Ｈｉｇｈ」に変更して、ＭＦＰ１０２がメモリ領域の不足等により、リソース領域を開放する場合でも、優先度の低いリソースから解放させる。これにより、他の画像形成装置から保持要求されているリソースが消去されてしまう危険性を低減して、ＳＦＰ１０３が同一のリソースをＭＦＰ１０２から短時間に取得できる状態を維持することができる。

ここでは、ＳＦＰ１０３を基準として基本動作の説明を行ったが、この動作はピアツーピアネットワークグループ１１０に参加する各画像形成装置がそれぞれ上述した手順に従い同様に行う。具体的には、各画像形成装置がリソース情報の交換、必要なリソースのダウンロード要求や応答、実際のダウンロードを行い、リソースを交換し合うことになる。

このように本実施形態では、他の画像形成装置がＳＦＰ１０３からの保持要求付が了承した場合に、他の画像形成装置を特定するための了承したＰｅｅｒを示す情報をＳＦＰ１０３に応答する。

そこで、その保持了承したＰｅｅｒを上記ＮＶＲＡＭ等で保持することで、次に、ＳＦＰ１０３の電源が投入された場合に、同一のリソース要求を取得する取得先を複数の画像形成装置中から即座に特定する情報として使用する。

これにより、電源再投入した場合でもダウンロード要求先を単純化でき、リソースの再検索時間を削減すると共に、保持を了承したＰｅｅｒのみを検索するため、ダウンロードできないという不確実な状態も回避することができる。

以下、本実施形態における画像形成システムの特徴について説明する。

図１に示すように本実施形態の画像形成システムは、いずれかの画像形成装置が不揮発性のメモリ手段を備える。そして、このメモリ手段に、画像形成に使用するリソースを他の画像形成装置のキャッシュとして記憶させることができる。

また、この場合に、キャッシュを作成する要求側の画像形成装置からリソースの保持要求がなされる。

そして、リソースのダウンロードを要求を行う画像形成装置、例えばＳＦＰ１０３は、リソースを不揮発に記憶するハードディスク等を備えていない。このため、ダウンロードしたリソースは、電源切断で揮発性のメモリ手段上から消失し、電源再投入時には、リソースがダウンロードされていない状態となる。

そこで、ＳＦＰ１０３は、まず、自らＮＶＲＡＭ等で保持するリソース情報をネットワークの画像形成装置と相互に交換し合うことで、未取得のリソースの情報を作成する。この作成の処理の詳細については、図６において説明する。

そして、ＳＦＰ１０３は、未取得のリソース情報に基づき、画像形成で使用するリソースを保持する画像形成装置であるＭＦＰ１０２にリソースのダウンロード要求を行う場合に、リソースの保持要求を付加して行う。この付加処理の詳細は、図９において説明する。なお、ＳＦＰ１０３は、リソース情報を不揮発に記憶するメモリ手段として、ＮＶＲＡＭを備える。

そこで、ＳＦＰ１０３がダウンロード要求を行う場合、リソースを不揮発性に保持する不揮発性保持手段（ハードディスク等）を備えているかどかを判断する。そして、不揮発性保持手段（ハードディスク等）を備えていない場合、電源投入毎に、メモリ手段に記憶されたリソース情報に基づいて、画像形成に使用するリソースをダウンロードする画像形成装置先を、例えばＭＦＰ１０２と決定する。

一方、リソースのダウンロードを要求を受け付ける画像形成装置として機能するＭＦＰ１０２は、ハードディスク等の不揮発性のメモリ手段で構成される保持手段に保持されるリソースのリソース情報を記憶する。ここで、リソース情報は、例えば図４に示すデータ構造のテーブルとして記憶する。

そして、ＭＦＰ１０２は、いずれかの画像形成装置からのリソースダウンロード要求にリソース保持要求が付加されているかを判断する。この判断処理の詳細は、図１０において説明する。

ここで、ＭＦＰ１０２が備えるＣＰＵは、リソース保持要求が保持されていると判断した場合、保持手段に保持されているリソースの保持状態を決定するための保持優先度を設定する。

そして、ＭＦＰ１０２が備えるＣＰＵは、保持優先度に基づいて保持手段に保持されているリソースの保持状態を制御する。ここで、保持状態は、例えば優先度が高い、低い、普通等のいずれかで管理可能に構成されている。

また、ＭＦＰ１０２が備えるＣＰＵは、保持要求を了承した保持了承情報を要求元の画像形成装置に応答する。この処理の詳細は、図１０において説明する。

一方、ＭＦＰ１０２から応答される応答情報に前記保持要求に対する補助了承情報が含まれていると要求元のＳＦＰ１０３のＣＰＵが判断した場合、メモリ手段に記憶されるリソース情報中の保持優先度を高めに設定する。これにより、ＳＦＰ１０３は、電源投入時に、保持優先度の高いリソースを他の画像形成装置にキャッシュしていることを認識することができる。この場合、他の画像形成装置のデバイス名称等を認識して、近接するＭＦＰ１０２より画像形成に使用する確率の高いリソースをダウンロードして、ＲＡＭ等に保持する。

この場合、ＭＦＰ１０２は、保持手段に保持されている前記保持優先度が高いリソースを削除すべきリソース候補から外す制御を行う。

これにより、ＭＦＰ１０２は、ＳＦＰ１０３のためにキャッシュしているリソースを誤って消失してしまう自体を回避する。また、ＭＦＰ１０２のメモリ資源を解放する要求がある場合に、保持優先度の高いリソースは、極力消失させてしまうことを回避できる。なお、ＳＦＰ１０３は、ＮＶＲＡＭ等で保持するリソース情報を参照することで、リソースの取得先を電源再投入時に即座に特定できるため、リソースを利用するＳＦＰ１０３のダウンロード処理時間が短縮される。

ここで、リソース情報は、リソース名、リソースサイズ、取得元デバイス名、保持優先度、ダウンロード日時、ダウンロード回数を含むが、その構成は後述する。

また、ＭＦＰ１０２は、自らリソース情報から保持されているリソースの保持優先度を低めに設定すべきかどうかを判別する。この判別処理は、図１０において説明する。この判別処理により、使用されていない他の画像形成装置のためにキャッシュしたリソースを、保持手段から削除され易くすることで、保持手段を有効活用できる。

このように本画像形成システムは、複数の画像形成装置がＰ２Ｐで通信可能に接続されるシステムである。そして、いずれかの画像形成装置とも、リソース情報を管理するテーブルを不揮発に記憶可能である。

したがって、いずれかの画像形成装置がリソース自体を不揮発に記憶する保持手段を備えていない安価な画像形成装置であっても、電源再投入時に、リソース情報を各画像形成装置と交換する。これにより、未取得のリソースをキャッシュされている画像形成装置から短時間にダウンロードして、画像形成に利用可能としている。

以上、本発明のシステム構成と基本動作について概略的に述べたが、以下において具体的な実施方法について図面を用いて詳細に説明する。

まず、図２を用いて画像形成装置である複合機、プリンタ、コピー機の内部構成を説明する。

図２は、図１に示したＭＦＰ１０１、１０２の構成を説明するブロック図である。本例は、図１に示した画像形成システムにおける複合機（ＭＦＰ）１０１、１０２の内部構成を示したものであり、本発明の複合機のコントローラも同様の構成を取るものである。なお、図１に示したＳＦＰ１０３も、図２に示すようなＣＰＵ、ＲＯＭ、ＲＡＭ、ＮＩＣ等を備えるが、他の画像形成装置からダウンロードしたリソースを不揮発に保持する手段を備えていない。

同様に、ＳＦＰ１０３は、プリント機能のみを実行するプリンタであるので、当然に画像読取り部も備えていなし、後述するＨＤ等も備えていない。

図２において、２００は複合機全体である。複合機２００は、ＲＯＭ２０２あるいは、例えばハードディスクなどの大規模記憶装置２１０に記憶されたソフトウエアを実行するＣＰＵ２０１を備える。そして、ＣＰＵ２０１はシステムバス２１３に接続される各デバイスを総括的に制御する。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０５は外部入力コントローラ（ＰＡＮＥＬＣ）で、複合機に備えられた各種ボタンあるいはタッチパネル２０６等からの指示入力を制御する。２０７はディスプレイコントローラ（ＤＩＳＰＣ）で、例えば液晶ディスプレイなどで構成される表示モジュール（ＤＩＳＰＬＡＹ）２０８の表示を制御する。

２０４はネットワークインタフェースカード（ＮＩＣ）で、ＬＡＮ２１４を介して、他のネットワーク機器あるいはファイルサーバ等と双方向にデータを所定のプロトコルでやりとりする。ここで、所定のプロトコルとは、TCP/IP等が好例である。

２１１は、例えば電子写真方式あるいはインクジェット方式などで実現される紙への印字部である。２１２は画像読取り部で、紙に印字された画像を読み込むための光学読み取りセンサを走査させるスキャナ部を備える。また、画像読取り部２１２は、多くの場合、オプションとしてオートドキュメントフィーダ（不図示）が装着されており、複数枚の原稿を自動的に読み込むことができる。なお、この場合、スキャナ部を所定の流し込み読み取り位置に移動させて固定した状態で、原稿のみを所定の搬送速度で搬送させる。

なお、大規模記憶装置２１０は、ＤＫＣ２０９を介してシステムバス２１３に接続され、場合によっては画像データの一時記憶場所としても使われることがある。

また、図１のプリンタ（ＳＦＰ）１０３の内部構成は、図２の複合機と基本的に近い構造になっているが、画像読み取り部２１２は存在せず、紙への印字を主目的とした構成である。また、安価なプリンタでは大規模記憶装置２１０は装着されていない。

また、図１のコピー機１０４、１０５の内部構成は、複合機と構造は基本的に同じである。

次に、図３を用いて本実施形態を示す画像形成装置上で動作するプログラムのソフトウエア構成をピアツーピアとの関係において説明する。

図３は、本実施形態を示す画像形成装置のモジュール構成を説明する図である。

図３において、３００はモジュール群で、ピアツーピア通信を実現する画像形成装置のソフトウエア構成を階層的に図示したものである。

図１に示した画像形成装置はオペレーティングシステム３０１により各デバイスやアプリケーションが制御や管理がなされており、デバイスドライバ３０２により図２で説明した各デバイスの制御を行う。ここで、画像形成装置は、符号で示すと、１０１〜１０５である。

また、図２のネットワークインタフェース（ＮＩＣ）２０４についてもデバイスドライバ３０２の層で制御される。

例えば、ＮＩＣ２０４で受信したデータはデバイスドライバ３０２でよりプロトコルスタック３０３に送られる。そして、プロトコルスタック３０３では受信したパケットの組み立てやパケット種別判定、データ部の取り出しなどを行い、上位層にデータを渡す。

プロトコルスタック３０３では、受信したデータがピアツーピア（Ｐ２Ｐ）の通信種別であった場合には、Ｐ２Ｐの通信制御を行うＰ２Ｐミドルウェア３０５にデータを渡す。そして、Ｐ２Ｐミドルウェア３０５でピアツーピアの接続／通信の維持管理が行われる。Ｐ２Ｐで取得したメタデータはアプリケーション層３０６に運ばれ、データの保存や管理などの最終的な処理が行われる。

なお、印字等の画像形成のための通信であった場合にはＪＯＢ制御層３０４にデータが通知され適切なアプリケーション層３０６でデータが処理され、目的のＪＯＢ処理が行われる。

次に、本発明における特徴的な部分の詳細について述べる。

なお、これから説明する特徴的な部分の詳細については、図１に示した画像形成システムの構成例を基準として説明する。

図１ではＳＦＰ１０３をダウンロード要求元の画像形成装置とする例で説明する。しかし、実際には各画像形成装置がそれぞれこれから説明する手段を備えていてもよく、それぞれがダウンロード要求元として動作し、それぞれがダウンロード要求先として動作することが可能である。また、ここで、リソースとは、フォントファイルやフォームファイル等である。

＜リソースリスト交換手段の説明＞
なお、お互いの画像形成装置が自分の持つリソースの情報を交換し合い、必要なリソースを要求して許可を得るまでの概略的な説明は図１を用いて流れを説明した。そこで、まず図１に示したＳＦＰ１０３とコピー機１０４が最初のステップとして実行しているリソース情報１２０の交換処理について説明する。

画像形成装置は、自装置が保有するフォントデータなど個々のリソースの情報を、図４で図示するリソース情報テーブルに格納して管理する。なお、リソース情報テーブルは、図２に示したＨＤ２１０、ＲＡＭ２０３等のいずれかに記憶される。つまり、リソースを書き換え可能で、かつ、不揮発性に記憶する場合には、ＨＤ２１０に記憶され、一時的に記憶する場合には、ＲＡＭ２０３に保持される。これは、各画像形成装置のメモリ資源の構成で決定される。特に、図１に示した画像形成装置の内、ＳＦＰ１０３は、メモリ資源としてＨＤを備えず、他の画像形成装置からダウンロードしたリソースは、ＲＡＭ２０３上で保持し、電源オフにより、リソース本体はＲＡＭ２０３から消失する。なお、ＲＡＭ２０３のうち、ＮＶＲＡＭ領域には、リソースの取得先に関する情報が不揮発に保持される。そして、電源再投入時には、ＮＶＲＡＭに記憶されたリソースの取得先に関する情報を読み出し、該取得先で特定される画像形成装置から同一のリソースをＲＡＭ２０３上にダウンロードする。

図４は、本実施形態を示す画像形成装置により管理されるリソース情報テーブルの一例を示す図である。以下、本実施形態では、リソース情報テーブル（ＲＩＴＡＢ）４００の構成要素を説明する。

図４において、ＣＰＵ２０１は、ＲＡＭ２０３に確保するＲＩＴＡＢ４００上にリソースＩＤ４０１、リソース名４０２をテーブルに格納することでリソースの管理を行う。

同様に、ＣＰＵ２０１は、ＲＡＭ２０３に確保するＲＩＴＡＢ４００上にサイズ４０３、取得元Ｐｅｅｒ４０４、取得日時４０５をテーブルに格納することでリソースの管理を行う。

同様に、ＣＰＵ２０１は、ＲＡＭ２０３に確保するＲＩＴＡＢ４００上に保持優先度４０６、最終アクセス時刻４０７、ダウンロード回数４０８をテーブルに格納することでリソースの管理を行う。

リソースＩＤ４０１は、各画像形成装置が保持している印刷資源として利用可能なリソースを識別するための識別子であり、画像形成装置内でリソース毎に固有の整数値を持つ。

リソース名４０２は、リソースをあらわす文字列であり、具体例としてはファイル名が一般的である。図４に示す例では、「Ｆｏｎｔ−Ａ．ｄａｔ」の場合である。

また、サイズ４０３は、リソースのデータサイズを表し、具体例としてはＢｙｔｅサイズを格納する。

さらに、取得元Ｐｅｅｒ４０４は、リソースＩＤ４０１に対応するリソースをダウンロードした時の取得元Ｐｅｅｒの名前を格納する。このフィールドが空である場合は自装置がオリジナルデータを保有することを意味する。ここで、取得元Ｐｅｅｒの名前として、画像形成装置名が設定される。

また、取得日時４０５は、取得元Ｐｅｅｒからリソースデータを取得した日付と時刻（例えば２００５／５／１０２０：０４）を格納する。

また、保持優先度４０６は、リソースの保持優先度を「Ｈｉｇｈ」か「Ｎｏｒｍａｌ」かの２段階の値を格納する例としているが、さらに多段階の優先度であってもよい。ここで、保持優先度４０６は、当該リソースを格納するメモリ資源の空き領域を確保する場合に、可能な限りメモリ資源内に残存させるかどうかを決定するためのフラグとして機能する。つまり、リソースの保持優先度を「Ｈｉｇｈ」の場合は、リソースがメモリ解放処理で消失する可能性が低いことを意味する。

また、リソースの保持優先度は、リソース要求元の画像形成装置がリソース要求時にリソース保持要求を伴う場合、リソースを管理している画像形成装置のＣＰＵ２０１がその状態を「Ｎｏｒｍａｌ」から「Ｈｉｇｈ」に設定変更する。

さらに、最終アクセス時刻４０７は、最後に当該リソースに対してダウンロードアクセスがあった日付と時刻を格納する。ダウンロード回数４０８は、そのリソースに対するダウンロードが行われた回数を整数値で格納する。なお、ダウンロードが行われた回数は、ＣＰＵ２０１にカウントアップされる。

このように本実施形態では、リソースを保持する画像形成装置のＣＰＵ２０１がＲＩＴＡＢ４００上のこれらの情報を参照／更新していくことにより、リソースの情報交換やリソースの削除などのリソース管理を実現する。

図４で説明したＲＩＴＡＢ４００を用いて各リソースの情報を格納した上で、各リソースをリスト構造にしてテーブルを連結して保有リソースの管理を行う。

図５は、図４に示した各リソース情報に対応するリソース情報リスト（ＲＩＬ）を説明する図である。本例は、複数のＲＩＴＡＢをＲＡＭ２０３上で管理する例を示す。

図５において、５００は情報リストであり、５０１はリストのリストヘッドである。このリストヘッド５０１に最初に作成したリソース情報テーブル５０２をリンクする。さらに、次に作成したリスト情報テーブル５０３を情報テーブル５０２にリンクし、これを繰り返すことで情報リスト５００が作成できる。ここで、情報リスト５００は、図１に示したリソース情報１２０に対応する情報である。

上記処理により作成できたリソース情報を各画像形成装置がＲＡＭ２０３上に作成し、お互いにＰｅｅｒからの情報提供要求に対して自装置のリソース情報を提供することが可能になる。

図１に示す画像形成装置システムの構成の場合、ＳＦＰ１０３がコピー機１０４に対し、リソースリスト要求メッセージを送信し、その応答をコピー機１０４がＳＦＰ１０３に返す例としている。実際に情報リスト５００をＰｅｅｒから取得する実施形態について図６のフローチャートを用いて説明する。

図６は、本実施形態を示す画像形成装置における第１のデータ処理手順の一例を示すフローチャートである。本処理は、ＳＦＰ１０３が実際に情報リスト５００をネットワーク上のＰｅｅｒ（自機以外の画像形成装置）から取得する処理例である。ここで、Ｐｅｅｒ候補として、コピー機１０４の例を示す。なお、Ｓ６０１〜Ｓ６０７は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、ＳＦＰ１０３がＰｅｅｒであるコピー機１０４に対してリソースリスト要求メッセージを作成して（Ｓ６０１）、要求メッセージを送信してコピー機１０４からのリソースリスト応答（ＲＩＬ）待ちに入る（Ｓ６０２）。

次に、ＳＦＰ１０３は、コピー機１０４からＲＩＬ応答を受信するまで待つ（Ｓ６０３）。そして、コピー機１０４からＲＩＬ応答を受信した場合、ＳＦＰ１０３は自装置がＲＡＭ２０３に記憶するリソース情報リストＬ６１を参照して自装置が保有していない未取得リソースを受信メッセージ中のＲＩＬ応答中から検索する（Ｓ６０４）。

そして、ＣＰＵ２０１がこの検索によって受信メッセージ中のＲＩＬ応答中から未取得リソースが発見される場合がある。

この場合は、コピー機１０４からの未取得リソース情報に対して、図７に示すように、ＲＡＭ２０３上に未取得リソーステーブル（ＲＩＴＡＢ）７００を作成して未取得リソースリストＬ６２に追加して（Ｓ６０６）、本処理を終了する。

なお、未取得リソースリストＬ６２に新規にリソース情報を追加する場合は、最初に未取得リソーステーブルＲＩＴＡＢ７００を作成する。この場合、初めて追記した場合と、既に未取得リソーステーブルＲＩＴＡＢ７００にリソース情報を追記している場合は、受信したリソース情報により未取得リソーステーブルＲＩＴＡＢの内容に更新される。

図７は、本実施形態を示す画像形成装置が管理する未取得リソーステーブル（ＲＩＴＡＢ）の一例を示す図である。本例は、コピー機１０４のＣＰＵ２０１が管理する未取得リソーステーブル（ＲＩＴＡＢ）Ｌ６２の例である。

ここでは構成要素例として、コピー機１０４のＣＰＵ２０１は、リソースＩＤ７０１、リソース名７０２、サイズ７０３、保有Ｐｅｅｒ名７０４、オリジナルフラグ７０５をテーブルに格納することで未取得リソースの管理を行う。同様に、コピー機１０４のＣＰＵ２０１は、保持優先度７０６、ダウンロードステータス７０７をテーブルに格納することで未取得リソースの管理を行う。

なお、図７に示すリソース情報テーブルと図４のリソース情報テーブルと同じ要素は説明を割愛する。

本実施形態において、図７において新しい要素として、相手Ｐｅｅｒが持つリソースがオリジナルデータであるかどうかを示すオリジナルフラグ７０５（図７参照）が存在する。これにより、コピー機１０４のＣＰＵ２０１は、そのリソースがオリジナルデータであるかどうかが判断可能である。

また、未取得リソーステーブルＬ６２には、ダウンロードする際の状態管理に用いるダウンロードステータス７０７が存在する。この未取得リソーステーブルＬ６２もリソース情報テーブルと同様、図５で図示したリスト構造でテーブルを連結して管理する。

次に、要求を受けたコピー機１０４側の応答処理について図８のフローチャートを用いて説明する。

図８は、本実施形態を示す画像形成装置における第２のデータ処理手順の一例を示すフローチャートである。本処理は、リソース取得要求を受けたコピー機１０４側がリソース情報リストをＰｅｅｒに応答する処理例である。なお、Ｓ８０１〜Ｓ８０３は各ステップを示す。また、各ステップは、コピー機１０４のＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

コピー機１０４は、いずれかの画像形成装置から自機宛に対するリソースリスト要求を受信するまで待つ（Ｓ８０１）。なお、ここで、コピー機１０４は、リソースを不揮発性に記憶するメモリ資源を備え、かつ、リソースの管理状態を保持優先度に応じて管理しているものとする。

ここで、コピー機１０４のＣＰＵ２０１が、例えばＳＦＰ１０３よりＮＩＣ２０４を介してリソースリスト要求を受信する。これに応じて、コピー機１０４のＣＰＵ２０１がリソース情報リストＬ８１と未取得リソースリストＬ８２に格納されたリソース情報を元にリソースリスト応答メッセージを作成する（Ｓ８０２）。

そして、コピー機１０４のＣＰＵ２０１が作成した応答メッセージを要求元Ｐｅｅｒ（図１の場合、ＳＦＰ１０３）に送信して（Ｓ８０３）、本処理を終了する。

これにより、コピー機１０４のＣＰＵ２０１はリソース情報の提供を要求元のＳＦＰ１０３に対して行うことができる。

ここでは図１の構成例に基づき、ＳＦＰ１０３とコピー機１０４との間のリソースリスト交換について説明した。

しかし、リソースリスト交換についてはピアツーピアネットワークグループ１１０に参加している各画像形成装置同士がそれぞれ行うことが可能な処理である。

＜リソースダウンロード要求手段の説明＞
次に、ここでは上記リソースリスト交換手段によって作成した未取得リソーステーブルを元に、実際にリソースを使用する場面でのリソースダウンロード要求を行うリソースダウンロード要求手段について説明する。より具体的には、図１の構成例を基に、図９のフローチャートを用いて説明する。

図９は、本実施形態を示す画像形成装置における第３のデータ処理手順の一例を示すフローチャートである。

本処理は、作成した未取得リソーステーブルを元に、実際にリソースを使用する場面でのリソースダウンロード要求を行うリソースダウンロード要求する処理例である。

なお、Ｓ９０１〜Ｓ９１７は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

なお、図９のフローチャート中には後述するリソース保持了承リスト記憶手段やリソース保持要求付加判断手段についての処理も合わせて図示しているが、ここではリソースダウンロード要求の基本的な流れの部分のみを説明する。

まず、リソースを使用する場面で、ＳＦＰ１０３のＣＰＵ２０１はＲＡＭ２０３に保持されるリソース情報リストＬ６１を参照し、必要なリソースが自装置に存在するかを確認する（Ｓ９０１）。

そして、ＣＰＵ２０１は、フォント等で不足するリソースがあるかどうかをリソース情報リストＬ９１を検索して判断する（Ｓ９０２）。なお、ＳＦＰ１０３のＲＡＭ２０３のＮＶＲＡＭ領域において、リソース情報リストＬ９１が記憶されているものとする。

ここで、ＣＰＵ２０１がリソースが不足すると判断した場合は、不足するリソースの数分、リソースを保有する画像形成装置に対してダウンロード要求処理を行う。このため、ＣＰＵ２０１は処理を不足リソースの取得先を決定するためのループの先頭に移る（Ｓ９０３）。なお、ループは、Ｓ９０３〜ＳＳ９１７で構成される。

そして、ＳＦＰ１０３のＣＰＵ２０１は、ＲＡＭ２０３に保持される未取得リソースリスト６０７から不足リソースを持つＰｅｅｒ（取得先）を保持了承リソースリストＬ９２を参照して検索する（Ｓ９０４）。

そして、ＳＦＰ１０３のＣＰＵ２０１は、保持了承された取得先があるかどうかを判断する（Ｓ９０５）。ここで、ＣＰＵ２０１が該当リソースを持つＰｅｅｒを検索により発見できたと判断した場合は、Ｓ９１０へ進む。

一方、Ｓ９０５で、保持了承された取得先がないと判断した場合は、未取得リソースリストＬ９３を参照して、不足リソースの取得先を検索する（Ｓ９０７）。そして、Ｓ９０７で、優先度（図７に示す保持優先度７０６に対応する）が「Ｈｉｇｈ」の取得先があるかどうかを判断する。ここで、優先度が「Ｈｉｇｈ」の取得先があると判断した場合は、保持了承リソースリストＬ９２にその取得先を追加して、Ｓ９１０へ進む。

一方、Ｓ９０７で、優先度が「Ｈｉｇｈ」の取得先がないと判断した場合は、Ｓ９０９へ進み、ＣＰＵ２０１が不足リソースの取得先があるかどうかを判断する。ここで、ＣＰＵ２０１が不足リソースの取得先ないと判断した場合はＳ９１６へ進む。

一方、Ｓ９０７で、取得先があると判断した場合は、Ｓ９１０へ進む。そして、Ｓ９１０で、ダウンロード要求先をそのＰｅｅｒに決定する（図１ではＭＦＰ１０２がダウンロード要求先の構成例である）。

次に、Ｓ９１１で、詳細は後述する保持要求付加判断処理を実行する。これは、ＳＦＰ１０３のＲＡＭ２０３では、ダウンロードしたリソースを電源切断とともに消失してしまう構成としているからである。そこで、利用するリソースを保持する他の画像形成装置（Ｐｅｅｒ）に、必要なリソースを勝手に消去しないように保持させるための要求処理を行う。

そして、Ｓ９１２で、ＳＦＰ１０３のＣＰＵ２０１はダウンロード要求に対してリソースの保持要求を付加するか否かを未取得リソースリストＬ９４を検索して判断する。

ここで、ＳＦＰ１０３のＣＰＵ２０１が保持要求を付加しないと判断した場合は、ＳＦＰ１０３のＣＰＵ２０１が保持要求無しのダウンロード要求メッセージを作成する（Ｓ９１４）。そして、Ｓ９１５へ進み、ＭＦＰ１０２に対して、ＮＩＣ２０４がダウンロード要求メッセージを送信する。

そして、最後に、図７に示した未取得リソースリストＬ２の該当テーブルのダウンロードステータス７０７を更新して、Ｓ９１７へ進む。

そして、Ｓ９１７で、ルールの終端処理で、まだ不足リソースが存在する場合は、Ｓ９０３のループの先頭に戻り同様の処理を繰り返すことで必要とするリソースに対してダウンロード要求を行うことができる。

一方、Ｓ９１７で、不足リソースが存在しないと判断した場合は、本処理を終了する。

一方、Ｓ９１２で、保持要求を付加すると判断した場合は、ＳＦＰ１０３のＣＰＵ２０１が保持要求付きのダウンロード要求メッセージを作成する（Ｓ９１３）。そして、Ｓ９１５〜Ｓ９１７を同様に処理する。

＜リソース保持要求付加手段の説明＞
上記リソースダウロード要求手段によってダウンロードを要求する基本的な処理について説明したが、ここでは、上記リソースダウンロード要求に対し、リソース保持要求を付加するリソース保持要求付加手段について図９のフローチャートを用いてさらに説明する。

既に前記リソースダウンロード要求手段の所で説明したように、Ｓ９１０で、ダウンロード要求先が決定される（図１の構成例ではＭＦＰ１０２に決定）。その後、ＳＦＰ１０３は、ダウンロード要求先であるＭＦＰ１０２に対してリソースの保持を要求するかどうかを判断する（Ｓ９１１）。

そして、ダウンロード要求先に保持要求を付加すると判断した場合には（Ｓ９１２）、保持要求を含めたダウンロード要求メッセージを作成して（Ｓ９１３）、ダウンロード要求メッセージをＭＦＰ１０２に送信する（Ｓ９１５）。ここで、ダウンロード要求メッセージは、図１に示したダウンロード要求１３０に対応する。

なお、リソース保持要求を行うかどうかの判断処理部については、後ほどリソース保持要求付加判断手段の説明の所で説明するため、ここでの説明は割愛する。

このリソース保持要求付加の処理を追加することにより、ダウンロード要求メッセージ中にリソース保持要求を付加して送信することでダウンロード要求先のＰｅｅｒに対して該当リソースを保持するように要求することが可能となる。

＜リソース保持優先度変更手段の説明＞
次に、上記のリソース保持要求が付加されたリソースダウンロード要求を受信したＰｅｅｒ（図１の構成例ではＭＦＰ１０２）がリソース保持優先度を変更するリソース保持優先度変更手段について図１０、図４を用いて説明する。

まず、ＳＦＰ１０３からリソース保持要求が含まれるダウンロード要求を受信したＭＦＰ１０２が、優先度を変更するまでの流れについて図１０を用いて説明する。なお、優先度は、図４に示すＲＩＴＡＢ４００の保持優先度４０６の状態で記憶されていて、ＭＦＰ１０２のＣＰＵ２０１が参照可能に構成されている。

図１０は、本実施形態を示す画像形成装置における第４のデータ処理手順の一例を示すフローチャートである。本処理は、他の画像形成装置からリソース保持要求を受信した画像形成装置によるリソース保持優先度を変更するリソース保持優先度変更処理例である。ここでは、ＭＦＰ１０２がＳＦＰ１０３からリソース保持要求を受信した場合のリソース保持優先度変更処理例について説明する。

なお、Ｓ１００１〜Ｓ１０１４は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、ＭＦＰ１０２は、ネットワーク上の他の画像形成装置（ここでは、ＳＦＰ１０３から）からのダウンロード要求を受信するまで待つ（Ｓ１００１）。ＭＦＰ１０２がダウンロード要求を受信したら自装置の所有するリソースをリソース情報リストＬ８１を参照して確認する（Ｓ１００２）。なお、リソース情報リストＬ８１は、ＨＤ２１０等に記憶され、ＭＦＰ１０２のＲＡＭ２０３にロードされた状態で、ＣＰＵ２０１により参照される。

そして、ＣＰＵ２０１がＳＦＰ１０３から要求されたリソースを持っているかどうかを判断する（Ｓ１００３）。ここで、ＣＰＵ２０１がＳＦＰ１０３から要求されたリソースを持っていないと判断した場合は、Ｓ１０１０へ進み、ダウンロード拒否応答メッセージを作成して、Ｓ１０１４へ進む。

一方、Ｓ１００３で、ＳＦＰ１０３から要求されたリソースを持っていると判断した場合は、Ｓ１００４へ進み、ＳＦＰ１０３から要求されたリソースに対する要求メッセージにリソース保持要求が含まれるかを確認する（Ｓ１００４）。

そして、ＭＦＰ１０２のＣＰＵ２０１がＳＦＰ１０３から要求メッセージに保持要求が含まれていると判断した場合には、ＭＦＰ１０２は、リソースリスト優先度最適化処理を行う（Ｓ１００５）。続いて、保持優先度を変更可能かどうかをリソース領域管理テーブル１４００を参照して判断する（Ｓ１００６）。

なお、Ｓ１００５におけるリソースリスト優先度最適化処理については必須の処理ではないので、Ｓ１００４からＳ１００６に進むものとして、以下説明する。なお、Ｓ１００５におけるリソースリスト優先度最適化処理の詳細については、リソース保持優先度最適化手段の説明中で説明する。

Ｓ１００７では、保持優先度が変更可能かどうかを未取得リソースリストＬ８２を参照して判断する。なお、本判断処理の詳細については、図１１、図１２を用いて説明する。

図１１は、本実施形態を示す画像形成装置のリソース領域を管理するリソース領域管理テーブルの一例を示す図である。

図１１において、未取得リソースリストＬ８２は、ダウンロード領域サイズ１４０１、使用サイズ１４０２、保持最大サイズ１４０３、保持サイズ１４０４の４つの要素で構成されている。なお、未取得リソースリストＬ８２は、ＨＤ２１０等に記憶され、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により参照可能に構成されている。なお、リソース領域は、不揮発性のＨＤ２１０を備えていない画像形成装置の場合は、ＲＡＭ２０３のＮＶＲＡＭ領域として構成される。

ダウンロード領域サイズ１４０１は、リソースデータを格納する領域の全サイズが格納される。使用サイズ１４０２は、実際にリソースが格納されて使用中となっているリソース総量が格納される。

保持最大サイズ１４０３は、ダウンロード領域サイズ１４０１内で保持優先度を高くして格納できる領域の最大サイズが格納され、新たに保持要求が来たリソースの保持優先度を高くできるかどうかの判断に使用される。

保持サイズ１４０４は、保持優先度を高くして実際に格納しているリソースの総量が格納される。

なお、保持最大サイズ１４０３の設定については、画像形成装置の管理者が、複合機に備えられた各種ボタンあるいはタッチパネル２０６等から非図示の設定画面で値を入力して設定が可能である。この未取得リソースリストＬ８２は、リソースを保有する画像形成装置それぞれ（図１の構成ではＭＦＰ１０１、１０２、ＳＦＰ１０３、コピー機１０４、１０５）で作成／管理される。

この未取得リソースリストＬ８２を用いて、新規に保持要求が来たリソースの保持優先度を高くできるかどうかを判断する処理の流れを図１の構成例と図１２のフローチャートを用いて説明する。

図１２は、本実施形態を示す画像形成装置における第５のデータ処理手順の一例を示すフローチャートである。本処理は、リソース保持優先度を変更するリソース保持優先度変更処理例である。

なお、Ｓ１５０１〜Ｓ１５０３は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

新たにＳＦＰ１０３からリソースの保持が要求されたＭＦＰ１０２は、要求されたリソースのサイズＳに、現在既に保持優先度を高くして保持している保持サイズ１４０４を加算した値が保持最大サイズ１４０３を超えていないかを判断する（Ｓ１５０１）。

ここで、ＭＦＰ１０２は、保持最大サイズ１４０３を超えていると判断した場合は、保持優先度を高くできない（保持不可能）と判断して（Ｓ１５０２）、本処理を終了する。

一方、Ｓ１５０１で、保持最大サイズ１４０３を超えていないと判断した場合は、保持優先度を高くできるため、ＭＦＰ１０２は、リソースファイルを保持可能と判断して（Ｓ１５０３）、本処理を終了する。

これにより、ＭＦＰ１０２が確保しているリソース領域内で、リソース保持されたリソースを格納して、優先度を「Ｈｉｇｈ」とすることで、以後、他の画像形成装置がこのリソースをダウンロード可能となる。

ここで、図１０に示すＳ１００７以降の処理について説明する。

上述した図１２に示す手順に従いＳ１００６の可否判断処理結果から、ＭＦＰ１０２のＣＰＵ２０１が優先度変更が可能かどうかを判断する（Ｓ１００７）。

なお、Ｓ１００７で、優先度変更が不可能であると判断した場合には、Ｓ１０１１で、リソースバックアップ処理を行うこともできるが、必須の処理ではなく、後ほどリソースバックアップ手段の所で説明するため、ここでは説明を省く。

ここで、保持しているリソースに対する優先度変更が可能であると判断した場合は、ＭＦＰ１０２は、優先度の変更をリソース情報リストＬ８１の該当リソース情報テーブル（図４）の保持優先度４０６の優先度を「Ｈｉｇｈ」状態に変更する（Ｓ１００８）。

これにより、ＭＦＰ１０２は、ＳＦＰ１０３から保持を要求されたリソースに対して保持優先度を高くすることが出来、リソース領域が不足した場合に消去対象から外されて保持が可能となる。つまり、ＳＦＰ１０３が再電源投入時に、ＭＦＰ１０２から同一のリソースを取得できる確率が高まり、ユーザのリソースダウンロード要求に対する利便性が向上する。

＜リソース保持応答付加手段の説明＞
次に、ここでは、上記リソース保持要求に対して優先度を変更した後、ダウンロード要求元のＰｅｅｒ（図１ではＳＦＰ１０３）に対してＭＦＰ１０２がリソース保持応答を付加したダウンロード許可応答を送信する。以下、リソース保持応答付加手段について図１０を参照して説明する。

上述したように、Ｓ１００７で、ＭＦＰ１０２で優先度変更が可能であった場合には、優先度の変更をリソース情報リストＬ８１の該当リソース情報テーブル（図４）の保持優先度４０６の優先度を「Ｈｉｇｈ」変更する（Ｓ１００８）。その後、保持了承を付加したダウンロード許可応答メッセージを作成する（Ｓ１００９）。

そして、作成したダウンロード許可応答を要求元ＰｅｅｒであるＳＦＰ１０３へ送信する（１０１４）。そして、本処理を終了する。

一方、Ｓ１００７で優先度変更が不可能であると判断した場合には、リソースバックアップ処理を実行して、Ｓ１０１２へ進む。

そして、Ｓ１０１２で、保持拒否を付加したダウンロード許可応答メッセージを作成し、ダウンロード応答をＳＦＰ１０３へ送信する（Ｓ１０１４）。

これにより、リソースダウンロード要求元となるＰｅｅｒであるＳＦＰ１０３に対して保持が可能かどうかの返答を付加してダウンロード要求に対する応答を返信することが可能となる。

＜リソース保持了承リスト記憶手段の説明＞
次に、上記リソースダウンロード要求に対する応答を受信して保持が了承されていた場合に保持を了承されたリソース情報を不揮発性メモリに記憶するリソース保持了承リスト記憶手段について図１３を参照して説明する。なお、ここで、不揮発性メモリとは、ＳＦＰ１０３のようにＨＤを備えず、ＲＡＭ２０３のＮＶＲＡＭ領域に確保される小記憶領域であって、ダウンロードするリソースを全て記憶できないメモリである。

図１３は、本実施形態を示す画像形成装置における第６のデータ処理手順の一例を示すフローチャートである。本処理は、リソースダウンロード要求に対する応答を受信して保持が了承されていた場合に保持を了承されたリソース情報を不揮発性メモリに記憶するリソース保持了承リストを記憶するまでの処理例である。なお、Ｓ１１０１〜Ｓ１１０６は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、ＳＦＰ１０３はダウンロード応答をＭＦＰ１０２から受信するまで待つ（Ｓ１１０１）。そして、ダウンロード応答をＭＦＰ１０２から受信したら、ダウンロード応答に基づいて、未取得リソースリストＬ１３１の該当テーブルのダウンロードステータスを更新する（Ｓ１１０２）。

次に、ＳＦＰ１０３はダウンロード応答からダウンロードが許可されているかどうかを確認し（Ｓ１１０３）、許可されていると判断した場合は、応答メッセージにリソース保持了承が付加されているかを確認する（Ｓ１１０４）。

ここで、ＳＦＰ１０３のＣＰＵ２０１は、保持了承が含まれていると判断した場合には、該当の未取得リソース情報テーブル７００を不揮発性メモリ上に格納される保持了承リソースリストＬ１３２に追加する（Ｓ１１０５）。ここで、不揮発性メモリとは、ＲＡＭ２０３上に確保されるＮＶＲＡＭ領域に対応する。

次に、ＳＦＰ１０３はＭＦＰ１０２により許可されたリソースのダウンロード処理を行い（Ｓ１１０６）、本処理を終了する。ここで、ダウンロードされたリソースは、一時的にＲＡＭ２０３のリソース領域に保持されるが、ＳＦＰ１０３の電源が切断されると、リソースも同時に消失する。

このようにして本実施形態では、ＳＦＰ１０３はＭＦＰ１０２により保持が了承されたリソース情報に対する保持了承リソースリストＬ１３２を不揮発性メモリに格納する。保持了承リソースリストＬ１３２には、特定情報として、保持されているリソースを特定する情報とそのリソースを保持することを了承した装置を特定するアドレス情報が記憶される。

これにより、電源再投入を行った後に同じリソースをダウンロードする必要が発生した場合には、ＳＦＰ１０３内の不揮発性メモリに格納された保持了承リソースリストＬ１３２から検索する。

そして、リソースを取得先を確実にダウンロード可能なＰｅｅｒであるＭＦＰ１０２であると即座に決定するこが可能となる。

以下、ＳＦＰ１０３内の不揮発性メモリに格納された保持了承リソースリストＬ１３２を用いてダウンロード要求を送信する場合の手順を図９のフローチャートを用いて説明する。

既に図９のフローチャートを用いて基本的なダウンロード要求送信手段をリソースダウンロード要求手段の説明の所で説明済みである。そこで、以下、先ほど説明した保持了承リソースリストに格納された特定情報（リソースを保持している装置を特定するアドレス情報）を使用してダウンロード要求先を決定する処理フローのみを説明する。

不足リソースの取得先を決定するために、Ｓ９０６で、ＳＦＰ１０３は未取得リソースリストＬ９３から不足リソースを持つＰｅｅｒを検索を行う前に、以下の処理を行う。まず保持了承リソースリストＬ９２を参照して不足リソースがリスト中のＰｅｅｒに存在するか検索を行う（Ｓ９０４）。そして、保持了承された取得先が保持了承リソースリストＬ９２から発見できれば（Ｓ９０５）、その時点でダウンロード要求先をそのＰｅｅｒ（図１の構成例ではＭＦＰ１０２）に決定する９１０。発見できなければ、通常の検索手順である未取得リソースリスト６０７から不足リソースを持つＰｅｅｒを検索する既に説明した処理を行うことになる。なお、ここで、保持了承リソースリストＬ９２と、保持了承リソースリストＬ１３２とは同一のものである。

＜リソース保持要求付加判断手段の説明＞
次に、ここでは、ダウンロード要求を行う際に、リソース保持要求を付加すべきかどうかを判断するリソース保持要求付加判断手段について図１４、図１５を参照して説明する。

図１４は、本実施形態を示す画像形成装置が保持要求付加するかどうかを判断するための条件設定値を格納する保持要求条件設定テーブルの構成を説明する図である。

図１４において、本実施形態では、保持要求条件設定テーブル１３００は、ＨＤＤ条件１３０１、保有台数条件１３０２、オリジナル保有Ｐｅｅｒ存在条件１３０３という要素から構成される。

ここで、ＨＤＤ条件１３０１がＥｎａｂｌｅ（有効）に設定されている場合には、ＨＤＤ（大規模記憶装置２１０のこと）が装着されているかどうかを条件判定に使用する。Ｄｉｓａｂｌｅ（無効）と設定されている場合にはこの判定は行わない。

保有台数条件１３０２は、ダウンロード要求を行うリソースと同一のリソースを持つ画像形成装置が同一ＬＡＮ内に何台存在するかを判定条件に使用する。設定値としては、例えば「４」という数値が設定されている場合、同一リソースを持つ画像形成装置が４台以下であった場合には保持要求をすると判定される。

なお、保有台数条件１３０２がＤｉｓａｂｌｅ（無効）の場合の値は「０」である。

オリジナル保有Ｐｅｅｒ存在条件１３０３の設定がＥｎａｂｌｅ（有効）が設定されている場合には、同一ＬＡＮ内にリソースのオリジナルを持つ画像形成装置が存在するかどうかを判定条件に使用する。

一つの実施形態として同一ＬＡＮ内に存在するリソース保有台数やオリジナルデータ保有装置の存在を判断手段としているが、別の実施形態として、同一ピアグループ内を基準として同様の判断をしてもよい。

また、ダウンロードを必要とするリソースのオリジナルを保有する画像形成装置がルータを超えた先に存在する場合にのみリソース保持要求を付加してダウンロードを要求するリソース保持要求付加の判断を行うように構成してもよい。

図１５は、本実施形態を示す画像形成装置における第７のデータ処理手順の一例を示すフローチャートである。本処理は、リソース保持の要求を付加するかどうかを判断する処理例である。なお、Ｓ１２０１〜Ｓ１２０９は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、ＳＦＰ１０３のＣＰＵ２０１は、図１４に示す保持要求条件設定テーブルＬ１５１の設定情報を読取り（Ｓ１２０１）、ＨＤＤ判定条件が有効かを確認する（Ｓ１２０２）。

次に、ＳＦＰ１０３のＣＰＵ２０１は、ＨＤＤ判定条件が有効か否かを判断する（Ｓ１２０２）。ここで、ＨＤＤ判定条件が有効であると判断した場合には、ＳＦＰ１０３のＣＰＵ２０１がＨＤＤが存在するかを確認する（Ｓ１２０３）。ここで、ＨＤＤが存在しないと判断した場合は、ＳＦＰ１０３のＣＰＵ２０１は、保持要求を付加すると判断して（Ｓ１２０８）、本処理を終了する。なお、Ｓ１２０３では、ＨＤＤが存在するか確認したが、ダウンロードするリソースの容量と不揮発性メモリの空き容量を比較し、ダウンロードするリソースを不揮発性メモリに記憶できるか確認しても良い。その際、ダウンロードするリソースを不揮発性メモリに記憶できないと判断した場合、保持要求を付加すると判断する。

一方、Ｓ１２０２で、設定が無効であると、もしくは、Ｓ１２０３でＨＤＤが存在すると判断した場合は、Ｓ１２０４へ進む。そして、Ｓ１２０４で、ＳＦＰ１０３のＣＰＵ２０１は、次の条件である、同一ＬＡＮ内のリソース保有台数条件が有効かを確認する（Ｓ１２０４）。ここで、ＳＦＰ１０３のＣＰＵ２０１が有効であると判断した場合は、同一ＬＡＮ内に同一リソースを保有する台数が設定値以下であるかを確認する（Ｓ１２０５）。

ここで、ＳＦＰ１０３のＣＰＵ２０１が設定値以下であると判断した場合は、保持要求を付加すると判断して（Ｓ１２０８）、本処理を終了する。

一方、Ｓ１２０４で設定が無効であると、もしくはＳ１２０５で設定値以上であると判断した場合は、Ｓ１２０６へ進む。

そして、Ｓ１２０６で、ＳＦＰ１０３のＣＰＵ２０１は、次の条件である、オリジナル保有Ｐｅｅｒが同一ＬＡＮ内に存在するかの設定が有効かを確認する（Ｓ１２０６）。

ここで、ＳＦＰ１０３のＣＰＵ２０１が設定が有効であると判断した場合は、ＳＦＰ１０３のＣＰＵ２０１がオリジナル保有Ｐｅｅｒが同一ＬＡＮ内に存在するか確認する（Ｓ１２０７）。ここで、ＳＦＰ１０３のＣＰＵ２０１がオリジナル保有Ｐｅｅｒが同一ＬＡＮ内に存在しないと判断した場合（ルータを超えた先に存在すると判断した場合）は、保持要求を付加すると判断して（Ｓ１２０８）、本処理を終了する。ここでのオリジナル保有Ｐｅｅｒとは、図１の例ではＭＦＰ−１（１０１）のことであり、オリジナルのリソースを保持する装置のことである。ＭＦＰ−１（１０１）がルータ内にあれば、ＭＦＰ−２（１０２）にキャッシュされているリソースが削除されてもＭＦＰ−１（１０１）から高速にダウンロードできるので、ＭＦＰ−２（１０２）に対して保持要求を行わない。一方、ＭＦＰ−１（１０１）がルータ外にあれば、ＭＦＰ−２（１０２）にキャッシュされているリソースが削除された際、ＭＦＰ−１（１０１）からダウンロードすると時間がかかる場合があるので、ＭＦＰ−２（１０２）に対して保持要求を行う。

一方、Ｓ１２０６で、ＳＦＰ１０３のＣＰＵ２０１が設定が無効であると、もしくは、Ｓ１２０７で、オリジナル保有Ｐｅｅｒが同一ＬＡＮ内に存在すると判断した場合は、付加しないと判断して（Ｓ１２０９）、本処理を終了する。

なお、リソースを保有するＰｅｅｒが同一ＬＡＮ内に存在しているかどうかの判断についてはピアツーピアの通信手法でルータのホップ数（ＴＴＬ）を指定した通信を行うことで知ることが可能であるが、本発明の特徴による所ではないため、説明は割愛する。

ここで、TTLとは、IPパケットヘッダに指定可能な「生存時間」である。ただし、実際には時間ではなく、「ホップ数」を意味している。つまり、そのパケットが「生存」できるホップ数を指定するのがTTLの機能である。

＜リソース保持優先度最適化手段の説明＞
すでに、ＭＦＰ１０２がリソース保持要求を含むダウンロード要求を受信して優先度を変更するまでの流れについて図１０を用いてリソース優先度変更手段の説明のところで説明した。

ここではＭＦＰ１０２が、要求メッセージにリソース保持要求が含まれていた場合に、リソースリストの各リソースの保持優先度を見直して更新する。そして、新たに保持を要求されたリソースをなるべく了承できるようにするリソース保持優先度最適化手段（図１０のフローチャートの１００５の処理）について、図１６のフローチャートを用いて説明する。

図１６は、本実施形態を示す画像形成装置における第８のデータ処理手順の一例を示すフローチャートである。本処理は、図１０に示したＳ１００５におけるリソースリスト優先度最適化処理の詳細処理例である。なお、Ｓ１６０１〜Ｓ１６０５は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、リソース保持要求があった場合（図１の構成ではＳＦＰ１０３からＭＦＰ１０２へ送信された要求１３０）、ＭＦＰ１０２は、リソース情報リストＬ１６１から最初のリソース情報テーブルを読み込む（Ｓ１６０１）。そして、保持優先度４０６が高い（Ｈｉｇｈ）か否かを確認する（Ｓ１６０２）。

ここで、保持優先度４０６が高いと判断した場合は、最終アクセス時刻からの経過時間を計算し、設定経過時間Ｔを超過しているか否かを判断する（Ｓ１６０３）。ここで、Ｓ１６０３で、設定経過時間Ｔを超過していると判断した場合は、リソース情報リストＬ１６１のリソース情報テーブルの保持優先度４０６を「Ｎｏｒｍａｌ」に下げる変更を行う（Ｓ１６０５）。

一方、Ｓ１６０３で、最終アクセス時刻からの経過時間を計算し、設定経過時間Ｔを超過していないと判断した場合は、次の条件であるダウンロード回数が設定回数を超えているか否かを判断する（Ｓ１６０４）。ここで、ダウンロード回数４０８が設定回数(Ｎ)を超えていると判断した場合は、Ｓ１６０５へ進み、保持優先度４０６を下げる変更を行う。

一方、Ｓ１６０４で、ダウンロード回数４０８が設定回数(Ｎ)を超えていないと判断した場合には、このリソースに対する優先度見直し処理を終了（ＲＥＴＵＲＮ）し、次のリソースに対して同様の見直しを行う。

この見直し処理をリソース情報リストに登録された全リソースに対して行うことで優先度を下げてもかまわないリソースの優先度を下げ、新たな保持要求になるべく了承を応答できるようにすることが可能となる。

＜リソースバックアップ手段の説明＞
すでに、リソース保持要求が含まれるダウンロード要求を受信して優先度を変更するまでの流れを図１０を用いてリソース優先度変更手段の説明のところで説明した。

以下、保持を要求されたリソースの保持優先度を変更できなかった場合に、そのリソースを他の画像形成装置にバックアップするリソースバックアップ手段（図１０に示したフローチャートの１０１１の処理）について図１７のフローチャートを用いて説明する。

図１７は、本実施形態を示す画像形成装置における第９のデータ処理手順の一例を示すフローチャートである。本処理は、図１０に示したＳ１００５におけるリソースリスト優先度最適化処理の詳細処理例である。なお、Ｓ１７０１〜Ｓ１７０５は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、ＭＦＰ１０２は、リソースを他の画像形成装置にアップロードするために、自装置が所属するピアグループに存在する近隣Ｐｅｅｒの中から近隣の画像形成装置を選択する。

そのＰｅｅｒ宛て（例えば図１の構成ではコピー機１０４が考えられる）にまずアップロード要求メッセージを作成して（Ｓ１７０１）、要求メッセージをコピー機１０４に送信する（Ｓ１７０２）。

ここで、アップデート要求を受信した画像形成装置（図１の構成ではコピー機１０４）のアップロード応答の処理手順については、図１０で説明したダウンロード応答の処理手順とほぼ同様であるため、説明は割愛する。

次に、ＭＦＰ１０２は、アップロード要求に対するアップロード応答をコピー機１０４から待ち（Ｓ１７０３）、コピー機１０４から応答を受信したら、保持了承でのアップロードが了承されたか確認する（Ｓ１７０４）。

ここで、ＭＦＰ１０２は、アップロードが了承されていると判断した場合のみ、リソースアップロード処理を行い（Ｓ１７０５）、本処理を終了する。

一方、Ｓ１７０４で、了承されなかったと判断した場合は、他の近隣Ｐｅｅｒを再度選択して、再度、Ｓ１７０１からＳ１７０５の処理を繰り返す。

これにより、保持を了承してくれるＰｅｅｒを探し出して対象リソースをアップロードすることが出来、自装置で保持できなかったリソースを他の画像形成装置で保持してもらうことが可能になる。

なお、上記アップロードの条件を、ＳＦＰ１０３からリソース保持要求を伴うダウンロード要求に対してダウンロード対象リソースの保持優先度を高く設定することが出来ない場合がある。そこで、ＭＦＰ１０２が対象リソースの保持が可能な他の画像形成装置（例えばコピー機１０４）に転送するように制御してもよい。

これにより、ダウンロード対象リソースの保持優先度を高く設定することが出来なかった場合、リソース保持領域に余裕のある他の近隣画像形成装置に転送することが可能になる。そして、リソースが削除された場合であってもダウンロード要求元がリソースの再検索を行えば、同一リソースをダウンロード可能にすることができる。

〔第２実施形態〕
なお、上記第１実施形態では、画像形成装置が他の画像形成装置からリソースをダウンロードする場合に、リソースを保持していることを前提とした場合について説明した。

しかし、必要なリソースの内、一部のリソースが、近接の画像形成装置にキャッシュされていない場合、該当するリソースをキャッシュするように近接の画像形成装置に指示する。そして、近接の画像形成装置がその指示に基づいて、不足しているリソースをＲＡＭ２０３にキャッシュする。その後、リソースのキャッシュを完了した旨を示すキャッシュ完了を要求元の画像形成装置に通知する。この流れを図１８の概念図を用いて説明する。

図１８は、本発明の第２実施形態を示す画像形成システムのシステム構成と基本動作を示した概念図である。

図１８において、ＳＦＰ１０３は既にＭＦＰ１０２にキャッシュされたリソースをダウンロードしており、さらに必要となるリソース（ＭＦＰ１０２が保有しない）に対し、ＭＦＰ１０２にリソース獲得保持要求を送信する。リソース獲得保持要求を受信したＭＦＰ１０２は、保有していないリソースをＭＦＰ１０１からダウンロードし、ダウンロード完了したリソースの保持優先度を高く（Ｈｉｇｈ）に設定する。そして、要求元のＳＦＰ１０３に対しリソース獲得保持完了応答を送信する。ＳＦＰ１０３は完了応答を受信することで、ＭＦＰ１０２が新たにリソースをキャッシュした旨を把握し、必要なリソースのダウンロードを同一画像形成装置からダウンロードすることが可能となる。

＜リソース獲得保持要求手段の説明＞
まず、概念図を用いて全体の説明を行ったが、次に、リソース獲得保持要求を送信するＳＦＰ１０３の処理の実施例を図１９を用いて説明する。

図１９は、本実施形態を示す画像形成装置における第１０のデータ処理手順の一例を示すフローチャートである。本処理は、リソース獲得保持要求を送信するＳＦＰ１０３の処理例である。なお、Ｓ２００１〜Ｓ２００８は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、リソース情報リスト（Ｌ２０１）を参照し、Ｓ２００１で、画像形成に必要なリソースの不足を確認する。次に、Ｓ２００２で、不足リソースがあるかどうかを判断し、不足リソースが存在しない場合は、何もせずに終了する。

一方、Ｓ２００２で、不足リソースが存在する場合は、Ｓ２００３で、前回ダウンロード要求先に選定したＰｅｅｒが不足リソースを保有しているか確認する。ここで、保有している場合は、Ｓ２００４で、既に図９で説明してきたダウンロード要求処理を行い、本処理を終了する。

一方、Ｓ２００３で、前回ダウンロード要求先に選定したＰｅｅｒに保有されていない場合は、Ｓ２００５で、リソース獲得保持要求メッセージを作成し、Ｓ２００６でメッセージを送信する。

そして、Ｓ２００７で、獲得保持応答メッセージの受信を待ち、リソース獲得保持完了応答を受信した場合には、Ｓ２００８で、保持了承リソースリストＬ２０２に追加を行う。

＜リソース獲得保持手段とリソース獲得完了応答手段の説明＞
次に、リソース獲得保持要求を要求されたＭＦＰ１０２の処理の実施例を図２１を用いて説明する。

図２０は、本実施形態を示す画像形成装置における第１１のデータ処理手順の一例を示すフローチャートである。本処理は、リソース獲得保持要求を要求されたＭＦＰ１０２の処理例である。なお、Ｓ２１０１〜Ｓ２１０９は各ステップを示す。また、各ステップは、ＣＰＵ２０１がＲＯＭ２０２、ＨＤ２１０に記憶された制御プログラムをＲＡＭ２０３にロードして実行することで実現される。

まず、Ｓ２１０１で、獲得保持要求の受信待ち状態となり、獲得保持要求を受信した場合は、Ｓ２１０２で、獲得要求されたリソースを他の画像形成装置からダウンロードする処理を行う。

次に、Ｓ２１０３で、ダウンロードが正常に完了すると、Ｓ２１０４で、既に図１２で説明した保持優先度変更可否判断を行う。

そして、Ｓ２１０６で、優先度変更が可能かどうかを判断する。ここで、優先度を変更可能であると判断した場合は、Ｓ２１０７で、優先度変更を行う。そして、Ｓ２１０８で、獲得保持完了応答メッセージを作成し、Ｓ２１０９で、応答を送信する。

一方、Ｓ２１０３で、ダウンロードが出来なかったと判断した場合、もしくはＳ２１０６で、優先度変更が不可能だったと破断した場合は、Ｓ２１０５で、獲得保持拒否応答メッセージを作成する。そして、Ｓ２１０９で、応答を送信して、本処理を終了する。

これにより、リソース要求元の画像形成装置がリソースを近隣の画像形成装置からダウンロードできない状態を回避して、画像形成装置が他の画像形成装置に保持されているリソースを使用する画像形成が可能となる。

上記実施形態によれば、ダウンロード要求先の画像形成装置に対しダウンロードを要求したリソースの保持優先度を上げさせ、リソースを消去させないようにすることが可能となる。

また、リソース提供側の画像形成装置でのダウンロード用ハードディスク領域がフルになった場合に、保持優先度を基に削除するファイルを決定することで、安価な画像形成装置からの保持要求を考慮した優先度の高いファイルを残すことが可能となる。

また、保持要求の認められたリソースとそれを認めた画像形成装置の情報を不揮発性メモリに格納しておく。これにより、電源再投入した場合でもダウンロード要求先を単純化でき、リソースの再検索時間を削減すると共に、保持を了承したＰｅｅｒのみを検索する。このため、ダウンロードできないという不確実な状態も回避することができる。

また、リソース保持要求を付加してダウンロード要求するかどうかを判断する手段を加えることにより、不要なリソース保持要求が増えることを防ぐことが可能になる。

また、保持優先度の最適化を行い、保持が不要と判断したリソースの優先度を下げることで、新たに要求のあったリソースに対してなるべく保持了承を返せるようにすることが可能になる。

また、ダウンロード対象リソースの保持優先度を高く設定することが出来なかった場合、リソース保持領域に余裕のある他の近隣画像形成装置に転送することが可能になる。また、該リソースが削除された場合であってもダウンロード要求元がリソースの再検索を行えば、同一リソースをダウンロード可能にすることができる。

〔第３実施形態〕
以下、図２１に示すメモリマップを参照して本発明に係る画像形成装置で読み取り可能なデータ処理プログラムの構成について説明する。

図２１は、本発明に係る画像形成装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図６、図８、図９、図１０、図１２、図１３、図１５、図１６、図１７、図１９、図２０に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。

本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。

本発明の第１実施形態を示す画像形成システムのシステム構成と基本動作を示した概念図である。図１に示したＭＦＰの構成を説明するブロック図である。本実施形態を示す画像形成装置のモジュール構成を説明する図である。本実施形態を示す画像形成装置により管理されるリソース情報テーブルの一例を示す図である。図４に示した各リソース情報に対応するリソース情報リスト（ＲＩＬ）を説明する図である。本実施形態を示す画像形成装置における第１のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置が管理する未取得リソーステーブルの一例を示す図である。本実施形態を示す画像形成装置における第２のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置における第３のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置における第４のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置のリソース領域を管理するリソース領域管理テーブルの一例を示す図である。本実施形態を示す画像形成装置における第５のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置における第６のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置が保持要求付加するかどうかを判断するための条件設定値を格納する保持要求条件設定テーブルの構成を説明する図である。本実施形態を示す画像形成装置における第７のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置における第８のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置における第９のデータ処理手順の一例を示すフローチャートである。本発明の第２実施形態を示す画像形成システムのシステム構成と基本動作を示した概念図である。本実施形態を示す画像形成装置における第１０のデータ処理手順の一例を示すフローチャートである。本実施形態を示す画像形成装置における第１１のデータ処理手順の一例を示すフローチャートである。本発明に係る画像形成装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

符号の説明

１０１、１０２ＭＦＰ
１０３ＳＦＰ
１０４、１０５コピー機

Claims

リソースの保持要求を含むリソースのダウンロード要求を行うか、リソースの保持要求を含まないリソースのダウンロード要求を行うか決定する決定手段と、
前記決定手段によりリソースの保持要求を含むリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含むリソースのダウンロード要求を行い、前記決定手段によりリソースの保持要求を含まないリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含まないリソースのダウンロード要求を行う要求手段とを有することを特徴とする画像形成装置。
前記決定手段は、ダウンロードされたリソースを記憶できない場合に、保持要求を含むリソースのダウンロード要求を行うと決定することを特徴とする請求項１記載の画像形成装置。
前記決定手段は、リソースを保持する装置の台数が設定値以下の場合、保持要求を含むリソースのダウンロード要求を行うと決定することを特徴とする請求項１記載の画像形成装置。
前記決定手段は、リソースのオリジナルを保持する装置がルータを超えた先に存在する場合、保持要求を含むリソースのダウンロード要求を行うと決定することを特徴とする請求項１記載の画像形成装置。
前記保持要求に基づきリソースを保持することが了承された場合、リソースを保持している装置を特定する特定情報を記憶する記憶手段と、
前記記憶手段に記憶されている特定情報に基づき、リソースのダウンロード先を決定する決定手段とを有することを特徴とする請求項１記載の画像形成装置。
画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードする手段と、
画像形成装置から保持要求を含まないリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げることなく、リソースを画像形成装置にダウンロードする手段とを有することを特徴とするリソース保持装置。
リソースの保持要求を含むリソースのダウンロード要求を行う画像形成装置と、
画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードするリソース保持装置とを有することを特徴とする画像形成システム。
リソースの保持要求を含むリソースのダウンロード要求を行うか、リソースの保持要求を含まないリソースのダウンロード要求を行うか決定する決定ステップと、
前記決定ステップによりリソースの保持要求を含むリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含むリソースのダウンロード要求を行い、前記決定ステップによりリソースの保持要求を含まないリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含まないリソースのダウンロード要求を行う要求ステップとを有することを特徴とするリソース要求方法。
画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードするステップと、
画像形成装置から保持要求を含まないリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げることなく、リソースを画像形成装置にダウンロードするステップとを有することを特徴とするリソース保持方法。
リソースの保持要求を含むリソースのダウンロード要求を行うステップと、
保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースをダウンロードするステップとを有することを特徴とするリソース管理方法。
リソースの保持要求を含むリソースのダウンロード要求を行うか、リソースの保持要求を含まないリソースのダウンロード要求を行うか決定する決定ステップと、
前記決定ステップによりリソースの保持要求を含むリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含むリソースのダウンロード要求を行い、前記決定ステップによりリソースの保持要求を含まないリソースのダウンロード要求を行うと決定された場合、リソースの保持要求を含まないリソースのダウンロード要求を行う要求ステップとをコンピュータに実行させるプログラム。
前記決定ステップは、ダウンロードされたリソースを記憶できない場合に、保持要求を含むリソースのダウンロード要求を行うと決定することを特徴とする請求項１１記載のプログラム。
前記決定ステップは、リソースを保持する装置の台数が設定値以下の場合、保持要求を含むリソースのダウンロード要求を行うと決定することを特徴とする請求項１１記載のプログラム。
前記決定ステップは、リソースのオリジナルを保持する装置がルータを超えた先に存在する場合、保持要求を含むリソースのダウンロード要求を行うと決定することを特徴とする請求項１１記載のプログラム。
前記保持要求に基づきリソースを保持することが了承された場合、リソースを保持している装置を特定する特定情報を記憶する記憶ステップと、
前記記憶ステップにより記憶された特定情報に基づき、リソースのダウンロード先を決定する決定ステップとをコンピュータに実行させることを特徴とする請求項１１記載のプログラム。
画像形成装置から保持要求を含むリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げ、リソースを画像形成装置にダウンロードするステップと、
画像形成装置から保持要求を含まないリソースのダウンロード要求を受けた場合、リソースを保持する際の優先度を上げることなく、リソースを画像形成装置にダウンロードするステップとをコンピュータに実行させることを特徴とするプログラム。