JP5361278B2 - 画像管理装置、サーバコンピュータ、画像管理方法、及び、コンピュータプログラム - Google Patents

Description

本発明は、画像管理装置、サーバコンピュータ、画像管理方法及びコンピュータプログラムに関する。

オンラインアルバムなどの画像サーバでは、ネットワーク上に画像を登録し、登録したユーザ本人又は紹介された家族や友人などの他のユーザが、閲覧、印刷、取得などの目的で登録画像を共有することを可能としているものがある。

これらのオンラインアルバムでは、各ユーザが無制限に画像を登録すると、画像サーバに必要なディスクスペースの容量が無限大に必要となる可能性がある。そこで、各ユーザに対して使用できるディスクスペースの容量に制限値を設けることが一般的に行われている。

このようなサービスを提供させるための技術として特許文献１は、登録の時点から一定時間経過すると画像サーバに登録された画像を削除する、又は、削除の旨をユーザに通知するといった方法を提案している。この方法により、画像サーバの容量を自動的に確保し、且つ、古い画像を整理することが可能となる。

また特許文献２は、画像サーバがユーザに提供するストレージにつき、容量制限付きで無期限に画像を保管できる無期限情報メモリと、容量制限なしで登録画像を一定期間後に自動削除する有期限情報メモリとの２種類の利用を提案している。特許文献２では、通常は無期限情報メモリを使用させる一方、無期限情報メモリが不足した場合は有期限情報メモリを使用させる方法を採用して、画像サーバが容量不足となった場合でも画像を一定期間内であれば追加登録可能としている。
特開２００３−１１５９７５号公報 特開２００５−２９３４３２号公報

上述の画像サーバでは、あるユーザが使用している画像サーバの容量が割り当てられた容量制限に達すると、それ以上の追加登録を行えなくなってしまう。この場合、ユーザが引き続き画像サーバを使用するためには、登録済みの画像の一部を削除するなどの操作を行って、自身のアルバムを整理する必要がある。これに対し、画像サーバに既に登録されている画像を整理するのは後回しにして、とりあえずは新たな画像の登録を先に済ませたいという要望がある。

また、画像サーバに登録しても殆ど使わない画像は保存しておく必要が無いので自動で整理したいが、いきなり削除するのは不安なので、ある程度の猶予期間を経てから削除したいというユーザの要望がある。

これに対し上述の特許文献１の提案方法では、画像サーバに登録された画像を一定期間経過後に削除することにより自動的に画像サーバの容量回復を図っている。しかしながら、この方法では画像サーバの残容量が逼迫していなくても、ユーザの必要とする画像が削除されてしまうことがある。

また上述の特許文献２の提案方法では、容量不足の時には有期限情報メモリに登録先を変更することによって、容量不足でも画像を登録することは可能になる。しかし、サーバに登録されたのが古く且つ使われない既存画像はユーザが意識的に処分しなければいつまでも整理されずに残ってしまう。また、係る方法ではサーバの容量に余裕ができたときに画像の保存場所を移動するため、ユーザには画像の保存場所（URLなど）に変更があったことを通知する必要がある。

このように従来は、画像サーバの残容量が不足していても新しい画像のアップロードによる登録処理を先行して行って、後から画像サーバを整理することができず、煩雑な整理を後回しにして画像サーバの利便性を高めることが困難であった。

上記の課題を解決するための一つの側面に対応する本発明は、画像データベースに保存された画像をユーザー単位で管理する画像管理装置であって、
前記画像データベースに格納された画像の管理状態を、該画像に対するユーザからのアクセスに関する情報を含めて画像単位で登録する管理テーブルと、
前記画像データベースにユーザーの新たな画像を追加する場合に、該画像データベースにおけるユーザに割り当てられた格納領域の残容量を、格納されている画像の前記管理状態を参照して計算し、該残容量が不足するか否かを判定する残容量判定手段と、
前記残容量が不足すると判定された場合に、前記格納領域に既に格納され前記残容量の計算に含められた画像のうち、該計算から除外すべき画像を前記アクセスに関する情報に基づいて判定する画像判定手段と、
を備え、
前記残容量判定手段は、前記残容量の計算から除外すべきと判定された画像を除外して前記残容量を再計算して、前記新たな画像を追加するのに前記残容量が不足するか否かをさらに判定し、
前記格納領域には前記残容量の計算から除外すべきと判定された画像が依然として保存され、
前記画像データベースに格納される画像には、オリジナル画像とそのサムネイル画像とが含まれ、
前記画像の管理状態には、
前記オリジナル画像と前記サムネイル画像とが前記格納領域に格納されており、前記残容量の計算に該オリジナル画像と該サムネイル画像とを含める画像であることを示す第１の管理状態と、
前記オリジナル画像と前記サムネイル画像とが前記格納領域に格納されているものの、前記残容量の計算には前記サムネイル画像のみを含める画像であることを示す第２の管理状態と、
前記サムネイル画像のみが前記格納領域に格納され、前記残容量の計算には前記サムネイル画像を含めない画像であることを示す第３の管理状態と
が含まれることを特徴とする。

本発明によれば、画像サーバの残容量が不足していても、新しい画像のアップロードによる登録処理を先行して行って、後から画像サーバを整理することができるため、煩雑な整理を後回しにして画像サーバの利便性を高めることができる。

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

［第１の実施形態］
図１は、本発明を構成するクライアントコンピュータ及びサーバコンピュータのハードウェア構成を示す図である。図１において、表示装置１０１はＣＲＴ（Cathode Ray Tube）、ＬＣＤ(Liquid Crystal Display)などの表示装置である。表示画面には、例えば編集中の文書、図形、画像その他の編集情報、アイコン、メッセージ、メニューその他のユーザインタフェース情報が表示される。なお、本実施形態では、表示装置としてＣＲＴを使用する場合について説明するが、これに限らず、ＬＣＤ（Liquid Crystal Display）やＥＬ（Electro Luminescent）ディスプレイ等であってもよい。

Video RAM（ＶＲＡＭ）１０２は、表示装置１０１の表示画面に表示するための画像が描画される。このＶＲＡＭ１０２に生成された画像は、所定の規定に従って表示装置１０１に転送され、これにより表示装置１０１に画像が表示される。ビットムーブユニット(ＢＭＵ)１０３は、例えば、メモリ間(例えば、ＶＲＡＭ１０２と他のメモリ)のデータ転送や、メモリと各Ｉ／Ｏデバイス(例えば、ネットワークインタフェース１１１)との間のデータ転送を制御する。

キーボード１０４は、文書等を入力するための各種キーを有する。ポインティングデバイス（ＰＤ）１０５は、例えば、表示装置１０１の表示画面上に表示されたアイコン、メニューその他のオブジェクトを指示するために使用される。ＣＰＵ（Central Processing Unit）１０６は、ＲＯＭ（Read Only Memory）１０７、ハードディスクドライブ１０９に格納された制御プログラムに基づいて、バス１１２を介して接続された各デバイスを制御する。

ＲＯＭ１０７は、各種の制御プログラムやデータを保持する。ＲＡＭ（Random Access Memory）１０８は、ＣＰＵ１０６のワーク領域、エラー処理時のデータの退避領域、制御プログラムのロード領域等を有する。ハードディスクドライブ (ＨＤＤ)１０９は、クライアントコンピュータで実行される各制御プログラムや、画像ファイルやテキストファイル等のコンテンツファイルを格納することができる。例えば、ハードディスクドライブ１０９には、オペレーティングシステム（ＯＳ）、サーバプログラム、アプリケーションプログラム、データベース（ＤＢ）管理プログラム、各種情報を管理するためのテーブルなどが格納されている。尚、ハードディスクドライブ１０９は近年開発されたフラッシュメモリで構成されるソリッドステートドライブ（ＳＳＤ）や、ハードディスクとフラッシュメモリを併用したハイブリッドドライブでも代用可能である。

フレキシブルディスクドライブ(ＦＤＤ)１１０は、フレキシブルディスクに対するアクセスを制御する。ネットワークインタフェース１１１は、他の情報処理装置やプリンタ等と通信を行うことができる。

上記において、ＣＰＵ１０６に対する制御プログラムの提供は、ＲＯＭ１０７、ハードディスク、フレキシブルディスクから行うこともできるし、ネットワークインタフェース１１１を介して他の情報処理装置等から行うこともできる。

次に、図２は本実施形態におけるサーバ・クライアントシステムの構成を示すブロック図である。

図２において、サーバ・クライアントシステムにおける画像管理装置としてのサーバコンピュータ２００は通常複数の機器で構成され、夫々の機器がファイアーウォール、負荷分散装置、など多くの役割を分担する。但し、本実施形態では便宜上総称して「サーバコンピュータ」として扱うことにする。また、サーバコンピュータ２００は自身に必要な処理動作のためのサーバアプリケーションプログラムも含め、後述の画像登録部２０１、アルバム制御部２０２、画像管理部２０３を含むサーバコンピュータの稼動に必要な処理を行うための機能の総称である。

画像登録部２０１は、サーバコンピュータ２００における画像の登録処理処理を実行するサーバ・アプリケーションである。アルバム制御部２０２は、サーバコンピュータ２００で管理される画像の表示処理を実行するサーバアプリケーションである。画像管理部２０３は、サーバコンピュータ２００に登録されている画像の状態を管理すると共に、後述する画像ＤＢ２０４の制御を実施するサーバ・アプリケーションである。

画像データベース（ＤＢ）２０４は、画像登録部２０１により登録された画像をユーザー単位に保管し、画像管理部２０３からの指示に応じて保管画像の直接の入出力を制御を実施する。画像ＤＢ２０４に保管されたオリジナル画像２０５は、後述するクライアントコンピュータ２０８から送られた状態の画像データファイルであり、クライアントコンピュータ２０８で加工されない限りその画像の最大画素数を有する。また、サーバ上に登録された画像の中で、ネットワークを通じての印刷依頼、拡大表示、ダウンロードなどの対象となるデータファイルの形態である。

画像ＤＢ２０４に保管されたサムネイル画像２０６は、登録画像をアルバム表示する際に使用される低画素数の粗い画像データファイルである。後述する削除待機画像や削除完了画像をアルバム上に表示する際に使用される。

ネットワーク２０７はインターネット、ローカルエリアネットワークや公衆回線網などのネットワークであり、サーバコンピュータ群２００とクライアントコンピュータ２０８とを接続する。以下では、例としてインターネットとして説明する。端末２０８はクライアントコンピュータの代表であり、本実施形態に対応するサービスの会員がサービスにアクセスするための端末として機能する。

画像登録用アプリケーションプログラム２０９は、本サービスシステムにおけるクライアントコンピュータ２０８上で動作しサーバコンピュータ２００への画像登録を実行するためのアプリケーションプログラムである。アプリケーションプログラム２０９はクライアントコンピュータ２０８のハードディスクドライブ１０９に保存され、ＲＡＭ１０８に展開されて動作する。

ＷＥＢ閲覧アプリケーション２１０は、クライアントコンピュータ２０８上でサーバコンピュータ群２００のアルバム制御部２０２が作成したＷＥＢページを表示し閲覧するためのアプリケーションであり、一般にＷＥＢブラウザと呼ばれている。

本実施形態では、画像登録用アプリケーションプログラム２０９が画像をサーバコンピュータ２００へ登録すると、画像登録部２０１が画像の登録を受け付け、画像管理部２０３に対して画像の状態変更などの必要な処理を実施させる。その処理結果をアルバム制御部２０２によってアルバムとして生成し、ＷＥＢ閲覧アプリケーション２１０により表示させる。

次に、本実施形態における残容量不足時の画像登録処理について説明する。図３は本実施形態における残容量不足時の画像登録処理において、画像の状態遷移を示す模式図である。以下、図３を使用して、本実施形態におけるサーバ容量不足時の画像登録処理の流れを説明する。

図３において、方眼の横軸はそれぞれ画像の管理状態を示し、縦軸は時間の遷移（時間１から時間３まで）を示している。通常登録画像３００の列は画像が通常の登録状態（第１の管理状態）にあることを示す。削除待機画像３０１の列は画像が削除待機画像の状態（第２の管理状態）であることを示す。削除待機サムネイル３０２の列は、画像が削除待機サムネイルを保持していることを示す。削除完了画像３０３の列はオリジナル画像が削除された状態（第３の管理状態）であることを示している。削除完了サムネイル３０４の列は画像が削除完了サムネイルを保持していることを示している。３００乃至３０４の各状態はサーバコンピュータ２００の画像管理部２０３により制御される。

今、時間１で新規に画像３１２の登録が行われると、該新画像３１２は時間１で通常登録画像３００として登録される（３０５）。このときサーバの残容量に不足が生じた場合、通常登録画像３００にある古い画像３１３は、時間２において削除待機画像３０１の管理状態に変更される（３０７）。時間２における通常登録画像３００の管理状態には、時間１において登録されたばかりの新画像３１２が残る（３０６）。また、時間２における削除待機画像３０１の管理状態では、時間１以前で通常登録画像３００として管理されていた古い画像３１３が管理される（３０７）。時間２の削除待機サムネイル３０２の管理状態では、削除待機画像となった古い画像３１３のサムネイル３１４が作成される（３０８）。

時間３の通常登録画像３００の管理状態には依然として新画像３１２のみが含まれている（３０９）。しかし画像３１３は時間３では、削除待機画像３０１の管理状態から削除完了画像３０３の管理状態に変更される（３１０）。また、対応するサムネイル３１４は、時間３において削除完了サムネイル３０４の管理状態に変更される（３１１）。

以上のように、画像ＤＢ２０４においてユーザに割り当てられた格納領域の容量が不足する場合、新画像は登録され、旧画像が削除待機画像に変更される。更に一定時間経過後に削除され、それぞれの状態を示すサムネイルが使用できるようになることが説明できる。

ここで、図９を参照して画像管理部２０３における画像の管理について説明する。図９は、本実施形態における画像管理部２０３で管理されている情報の一例である画像情報管理テーブルの一例を示すブロック図である。

図９において、画像情報管理テーブル９００は画像ＤＢ２０４に保管されている全ての画像に対して１つずつ用意され、画像単位に管理情報を保持している。登録日時９０１はその画像が画像登録部２０１によりサーバコンピュータ２００に登録された日時を記録している。画像ステータス９０２は、その画像の現在の管理状態を記録している。管理状態とは、即ち、上述の通常登録画像３００、削除待機画像３０１、削除完了画像３０３のいずれかの状態を意味する。

アクセス回数９０３は、その画像が登録後にアクセスされた履歴回数を記録している。この場合のアクセスとは、オリジナル画像の拡大表示、サーバからのプリント注文、オリジナル画像のダウンロードによる取得、などオリジナル画像に対してユーザ指示により行うことの出来る操作行為を意味している。

最終アクセス時間９０４は、上記画像アクセス処理が最後に実施されてからの経過時間を記録している。一度もアクセスされたことのない画像の場合、削除待機画像から復元された画像であれば最後に復元されてからの時間が、そうでない場合は始めて登録されてからの時間が記録される。

削除禁止フラグ９０５は、その画像の削除禁止が指定されているときに、その状態を記録している。削除待機時間９０６は、その画像が最後に削除待機画像に変更されてからの経過時間を記録する。画像の現在の管理ステータスが削除待機画像で無い場合には、この領域は使われない。

オリジナル画像アドレス９０７は、画像ＤＢ２０４に記録されているオリジナル画像の保管場所を一意的に指示するアドレス情報を記録している。サムネイル画像アドレス９０８は、画像ＤＢ２０４に記録されているサムネイル画像の保管場所を一意的に指示するアドレス情報を記録している。オリジナル画像２０５はオリジナル画像アドレス９０７により指示されているオリジナル画像ファイルの実態であり、画像ＤＢ２０４に記録されている。サムネイル画像２０６はサムネイル画像アドレス９０８により指示されているサムネイル画像ファイルの実態であり、画像ＤＢ２０４に記録されている。

次に、図４は本実施形態におけるサーバ容量不足時の画像登録処理の一例を示すフローチャートである。以下、図４を参照して、本実施形態におけるサーバ容量不足時の処理の流れを説明する。

ステップＳ４０１で画像のアップロード処理が画像登録部２０１で実行されると、ステップＳ４０２で画像管理部２０３によりサーバの画像ＤＢ２０４の残容量判定が行われる。すなわち、クライアントコンピュータのユーザに関連づけられた容量制限と、ステップＳ４０１でアップロードされた画像の容量およびクライアントコンピュータのユーザが既に登録している画像の容量の合計とを比較する。クライアントコンピュータのユーザに関連づけられた容量制限が、ステップＳ４０１でアップロードされた画像の容量およびクライアントコンピュータのユーザが既に登録している画像の容量の合計より大きければ残容量があると判定される。もし残容量が十分に存在する場合（ステップＳ４０２において「ＹＥＳ」）、ステップＳ４０６に移行する。一方、残容量が十分に存在しない場合（ステップＳ４０２において「ＮＯ」）、ステップＳ４０３に移行する。

ステップＳ４０３では、削除待機画像３０１に指定すべき画像の画像判定を行う。具体的には画像管理部２０３により登録画像の中で所定条件を満たすもの、例えば前回アクセスした時刻が最も古いものを探索する。ここでは、画像情報管理テーブル９００の最終アクセス時間９０４の情報を参照して画像を探索する。なお、最終アクセス時間９０４以外に、アクセス回数９０３や登録日時９０１を参照しても良い。例えば、アクセス回数が最も少ないものや、登録日時から最も時間の経過しているものを探索しても良い。続くステップＳ４０４では、画像管理部２０３が探索された画像の画像ステータス９０２を削除待機画像３０１に変更する。ここで削除待機画像に指定された画像は、後述する復元処理が行われなければ、画像ＤＢ２０４からそのまま削除されることになる。

続くステップＳ４０５では、画像管理部２０３は残容量を再計算して、残容量が十分に存在するかどうかを判定する。もし、十分に存在すると判定された場合（ステップＳ４０５において「ＹＥＳ」）、ステップＳ４０６に移行する。一方、残容量が十分に存在しないと判定された場合（ステップＳ４０５において「ＮＯ」）、ステップＳ４０３に戻って処理を継続する。即ち、ステップＳ４０３、ステップＳ４０４、ステップＳ４０５のサイクルが、残容量が充足するまで繰り返し実施される。

ステップＳ４０６では、ステップＳ４０１でアップロードされた画像が画像ＤＢ２０４のオリジナル画像２０５として新規に登録され、また画像のサムネイルが作成して画像ＤＢ２０４のサムネイル画像２０６として登録される。画像の登録が完了すると、ステップＳ４０７においてアルバム制御部２０２によりアルバムの再作成が実施されて更新されたアルバムが表示されるようになる。

次に、本実施形態における削除待機画像の表示について説明する。図５は本実施形態におけるアルバム画面の表示状態を説明する模式図である。以下、図５を使用して、本実施形態におけるアルバム画面の表示状態を説明する。

図５において、アルバム画面５００は、クライアントコンピュータ２０８のＷＥＢ閲覧アプリケーション２１０により表示装置１０１に表示されるＷＥＢページである。

アルバムのタイトル文字列表示５０１には、アルバムを一意的に識別するためにユーザが任意に入力指定した文字列が表示される。アルバム一覧表示へ画面遷移するためのボタン或いはリンク５０２は、ポインティングデバイス１０５により選択することにより他のアルバムを参照／選択するための画面ページにアルバム画面５００が遷移する。アルバム一覧表示の機能は一般的なオンラインアルバムの機能であるので、ここでの詳細の説明は割愛する。

領域５０３はアルバムに登録されている画像のサムネイルを表示するための領域である。サムネイル５０４は登録されているサムネイルの一つを示し、サムネイル５０４は画像が選択されている状態であることを特に示している。領域５０３に表示されるサムネイル５０４等は画像ＤＢ２０４にサムネイル画像２０６として全てのオリジナル画像２０５に対応して保管されている。

スクロールバー５０５は、領域５０３に全ての登録画像のサムネイルを表示しきれない場合に表示され、領域５０３のスクロール処理を行うために操作される。削除禁止アイコン５０６は、削除禁止状態にある画像を示すためのアイコンである。削除禁止状態にある画像はユーザによる削除操作を受け付けない限り、本実施形態で説明している新規画像の追加により削除待機画像に状態が変更される対象には含まれない。

ボタン又はリンク５０７は選択画像に対して削除禁止状態に変更させるためのボタン又はリンクである。ボタン又はリンク５０８は選択されている削除禁止状態の画像を通常の削除可能な状態の画像に変更するためのボタン又はリンクである。ボタン又はリンク５０９は、領域５０３内の選択画像を削除するためのボタン又はリンクである。ボタン又はリンク５０７、５０８及び５０９は、対象となるサムネイルが選択されているときのみポインティングデバイス１０５により指示選択することができる。

領域５１０は、削除待機画像のサムネイルを表示するための領域であり、サムネイル５１１は削除待機画像のサムネイルの一つである。ボタン又はリンク５１２は削除待機画像を通常の画像に復元するためのボタン又はリンクである。これをポインティングデバイス１０５で選択することにより、後述するパネル画面での操作に従って指定された画像のサムネイル表示が領域５０３内に移動して通常の画像の状態となる。

領域５１３は削除完了画像のサムネイルを表示するための領域である。サムネイル５１４は、削除完了画像のサムネイルの一つである。領域５０３で削除が指示された画像、及び領域５１０で十分な時間が経過後にオリジナル画像が削除された画像のサムネイルが５１４として表示される。

ボタン又はリンク５１５は削除完了画像のサムネイルをクリアすることを指示する為のリンク又はボタンである。このボタン又はリンク５１５を選択することにより画像ＤＢ２０４のサムネイル画像２０６から削除完了画像に対応する画像がまとめて削除され、領域５１３内のサムネイル表示は空になる。

次に、本実施形態における削除待機画像が通常の登録画像に復元される処理の流れを説明する。図６は、本実施形態における削除待機画像が通常の登録画像に復元される処理の一例を説明するためのフローチャートである。また、図７は本実施形態における削除待機画像の復元時に使用される操作画面の一例を示す模式図である。

図６において、ステップＳ６０１では、例えば図５における画像削除ボタン５０９の操作などにより、登録画像のオリジナル画像の削除指示を受け付ける。続くステップＳ６０２では、画像管理部２０３により削除対象となった画像の画像ステータス９０２が削除完了画像に変更され、オリジナル画像２０５が画像ＤＢ２０４から削除される。

更にステップＳ６０３では、画像削除後の画像ＤＢ２０４の残容量が再計算される。ステップＳ６０４では再計算された残容量よりもオリジナル画像のサイズが小さい画像が削除待機画像３０１の管理状態で存在するかを判定する。もし、存在しなければ（ステップＳ６０４において「ＮＯ」）そのまま画像の削除処理が完了する。

一方、復元可能な削除待機画像が存在することが確認されたら（ステップＳ６０４において「ＹＥＳ」）、ステップＳ６０５に移行する。ステップＳ６０５では、全ての復元可能な削除待機画像を抽出し、ステップＳ６０６で後述する復元画像選択パネルを画面上に表示する。

ここで表示される復元画像選択パネルの一例は図７に示す通りである。図７において復元画像選択パネル７０１はアルバム画面５００のサブウィンドウとしてＷＥＢ閲覧アプリケーション２１０により表示装置１０１に表示される。

領域７０２には復元可能な削除待機画像のサムネイル７０３が表示され、チェックボックス７０４をポインティングデバイス１０５にて選択することにより、復元する画像を選択することができる。ボタン又はリンク７０５、７０６はそれぞれ削除待機画像の復元を実行又は非実行を決定するための機能であり、ポインティングデバイス１０５で選択して指示することができる。

図６の説明に戻ってステップＳ６０７では、パネル７０１において画像が選択され、かつ、復元ボタン７０５が選択されたか否かを判定する。もし、選択画像が存在し、復元ボタン７０５が選択された場合（ステップＳ６０７において「ＹＥＳ」）、ステップＳ６０８に移行する。ステップＳ６０８では、選択画像について削除待機画像からの復元処理が指示され、画像管理部２０３により復元処理が実施される。即ち、選択画像の画像ステータス９０２が削除待機画像３０１から通常登録画像３００に変更し、削除待機の状態を解除する。このとき、パネル７０１は閉じられてＷＥＢ閲覧アプリケーション２１０の表示画面は更新されたアルバム画面５００に戻る。

一方で、ステップＳ６０７にてパネル７０１で画像が選択されずに復元ボタン７０５が選択されたか、或いは、画像選択の有無に関わらずボタン７０６が選択された場合は（ステップＳ６０７において「ＮＯ」）、処理を終了する。具体的に、復元処理を行うことなく操作パネル７０１が閉じられてＷＥＢ閲覧アプリケーション２１０の表示画面は今までのアルバム画面５００に戻る。

次に、図８は本実施形態における削除待機画像の復元処理において、画像の状態遷移を示す模式図である。以下、図８を参照して本実施形態における削除待機画像の復元処理の流れを説明する。

図８において、方眼の横軸はそれぞれ画像の管理状態を示し、縦軸は時間の遷移（時間４から時間６）を示している。通常登録画像３００、削除待機画像３０１、削除待機サムネイル３０２、削除完了画像３０３、削除完了サムネイル３０４は、それぞれ図３において説明したものと同様である。３００乃至３０４の各状態はサーバコンピュータ２００の画像管理部２０３により制御される。

まず、時間４で、画像８１１は通常登録画像３００の管理状態におかれている（８０１）。また、画像８１２は、削除待機画像３０１の管理状態に置かれ（８０２）、該画像８１２のサムネイル画像８１３は削除待機サムネイル３０２の管理状態に置かれている（８０３）。

この状態から当該画像８１１が削除されると、時間５において管理状態が通常登録画像３００から削除完了画像３０３に変更される（８０４）。
これにより削除待機画像３０１の管理状態にある他の画像が復元されるのに十分な空き容量が新たに生じた場合、時間６では削除待機画像３０１にあった画像８１２が復元される（８０７）。即ち、画像８１２は、削除待機画像３０１から通常登録画像３００に管理状態が変更される。この場合、画像８１２に関連付けられているサムネイル８１３は表示されなくなる。時間６において画像８１１のサムネイル画像８１４は削除完了サムネイルとして管理され画像８１１のサムネイルとして表示される（８０８）。

次に、本実施形態における削除待機画像の指定について説明する。図１０は、本実施形態における画像管理部２０３において実施される削除待機画像を指定するための処理の一例を示すフローチャートである。図１０のフローチャートを参照して、本実施形態における削除待機画像を指定する処理の流れを説明する。

図１０のステップＳ１００１では、画像の追加処理などにより画像ＤＢ２０４におけるユーザに割り当てられた使用容量が不足しているか否かを判定する。もし、不足していると判定された場合（ステップＳ１００１において「ＹＥＳ」）、ステップＳ１００２に移行する。ステップＳ１００２では画像ＤＢ２０４に保管されている画像のうち、画像ステータス９０２が通常登録画像３００のものを判断し、アクセス回数９０３をさらに参照してアクセス回数が最小の画像を選択する。続くステップＳ１００３では最小アクセス回数が「０」か否かを判定し、「０」の場合（ステップＳ１００３において「ＹＥＳ」）、ステップＳ１００４に移行する。ステップＳ１００４ではアクセス回数が「１」の画像を代わりに選択してステップＳ１００５に移行する。これはまだアクセスされていない画像が削除されるのを防ぐためである。一方、最小アクセス回数が「０」でない場合（ステップＳ１００３において「ＮＯ」）、ステップＳ１００５に移行する。

ステップＳ１００５では、選択された各画像の削除禁止フラグ９０５を参照して、削除禁止が指定されていた画像に対しては削除対象の候補から除外する。続くステップＳ１００６では、選択された画像が全て削除禁止指定されているか否かを判定する。もし、全ての画像が削除禁止指定されている場合（ステップＳ１００６において「ＹＥＳ」）、ステップＳ１００７に移行する。一方、削除禁止指定されていない画像が存在する場合（ステップＳ１００６において「ＮＯ」）、ステップＳ１００８に移行する。

ステップＳ１００７では、画像ＤＢ２０４に登録されているユーザーの画像の中でアクセス回数が、ステップＳ１００６で判定対象となった画像の次に少ない画像を選択する。その後ステップＳ１００５に戻って処理を繰り返す。

また、ステップＳ１００８では、最終アクセス時間９０４を参照して最後にアクセスされてからの時間が最も経過しているものを選択する。続くステップＳ１００９では、画像ステータス９０２を削除待機画像３０１に変更して、画像管理部２０３で該削除待機画像のオリジナル画像２０５の容量を除外して使用容量の再計算を行う。さらにステップＳ１０１０では、再計算した使用容量が十分に回復したか否かを判定する。もし十分に回復していれば（ステップＳ１０１０において「ＹＥＳ」）処理を終了する。一方、ステップＳ１０１０で容量回復が不十分の場合（ステップＳ１０１０において「ＮＯ」）、ステップＳ１０１１に移行する。ステップＳ１０１１では、ステップＳ１００５で選択されている画像の中で削除待機画像に未更新の画像が残っているか否かを判定する。もし残りがあればステップＳ１００８に戻って次の削除待機画像を指定する。ステップＳ１０１１で残りの画像が無い場合には、ステップＳ１００７に戻り、アクセス回数の次に少ない画像を選択する。

以上の処理を繰り返すことにより、本実施形態における画像登録時の削除待機画像の指定が行われる。

次に、図１１を参照して画像ＤＢ２０４におけるユーザに割り当てられた使用容量の計算方法について説明する。図１１は本実施形態における、ユーザの使用容量を画像管理部２０３において計算する方法を説明するための図である。

図１１において、画像ステータス９０２に管理される画像の状態には、通常登録画像３００、削除待機画像３０１、削除完了画像３０３の３種類が存在する。各ステータスの画像で使用容量の計算対象となるのは、通常登録画像３００の場合はオリジナル画像とサムネイル画像の両方であり、削除待機画像３０１はサムネイル画像のみ、削除完了画像３０３は計算対象を持たない。

図１１において、テーブル１１００は、あるユーザが画像ＤＢ２０４に登録している画像とステータス、計算対象となる画像ファイルの関係を表にまとめたものである。

テーブル１１００の縦軸には、画像１１０１、画像ステータス１１０２、オリジナル画像１１０３、サムネイル画像１１０４が含まれる。画像１１０１の行には、４つの画像ＡからＤまでがそれぞれ示されている。画像ステータス１１０２の行は画像ステータス９０２の登録状態を示す。オリジナル画像１１０３の行はオリジナル画像２０５を使用容量の計算対象にするか否かを示す。サムネイル画像１１０４の行はサムネイル画像２０６を容量計算の対象にするか否かを示している。上記において丸印は計算対象であることを示し、バツ印は計算対象でないことを示す。

テーブル１１００において、例えば画像Ａと画像Ｄは通常登録画像３００であるので、オリジナル画像とサムネイル画像とが共に残容量の計算対象となる。画像Ｂは削除待機画像３０１であるのでオリジナル画像は計算対象とならないがサムネイル画像のみ計算対象となる。また、画像Ｃは削除完了画像であるのでオリジナル画像、サムネイル画像共にサーバ容量の計算対象とならない。

次に、本実施形態における画像サーバのアルバム機能において、オリジナル画像に対して実施できる処理アクセスの各制御機能について説明する。

図１２は本実施形態における画像サーバを管理するサーバコンピュータ２００において、オリジナル画像への処理アクセスを行う機能を示すブロック図である。図１２において、２００から２０７までは図２と同等である。また、図１２ではクライアントコンピュータ側のモジュール構成の説明及び表示は割愛してあるが、実際には図２と同様にクライアントコンピュータ２０８がインターネット２０７を介して存在し機能しているものとする。

画像拡大表示制御部１２０１は、アルバム制御部２０２により表示されるオンラインアルバムの一機能として、アルバムに登録されている通常のオリジナル画像をＷＥＢ閲覧アプリケーション２１０に表示させるための制御を行う。ネットプリント注文制御部１２０２は、アルバム制御部２０２により表示されるオンラインアルバムの一機能として、アルバムに登録されている通常のオリジナル画像をネットワークを通じてプリント注文させるための制御を行う。

画像ダウンロード制御部１２０３は、アルバム制御部２０２により表示されるオンラインアルバムの一機能として、アルバムに登録されている通常のオリジナル画像をクライアントコンピュータ２０８にダウンロードさせるための制御を行う。

ここで、各制御部１２０１、１２０２及び１２０３で行う処理アクセスは、通常の登録画像としてアルバムに保管されている画像のオリジナル画像に対して実施されるものであり、削除待機画像、削除完了画像に対しては実施することはできない。また、各制御部１２０１、１２０２及び１２０３で行う処理は公知の技術を利用することが可能であり、その詳細についてはここでは深くは言及しない。

図１３は、本実施形態におけるアルバム画面の一例であり、オリジナル画像に対する各処理アクセスの実施と、削除禁止画像に対する各処理アクセスの制限とを説明するための模式図である。

図１３（ａ）のアルバムのメイン画面の一部１３０１には、登録画像のサムネイルが表示されている。登録画像サムネイル１３０２はアルバムに登録されている通常の登録画像サムネイルの一つであり、選択状態にある。表示１３０３はポインティングデバイス１０５の指示する場所を表示するためのマウスカーソル表示である。本実施形態では、画像サムネイル１３０２を選択した状態でポインティングデバイス１０５の右ボタンクリック等の操作をすることにより、ポップアップメニュー１３０４から１３０７を表示できる。

ポップアップメニュー１３０４は画像拡大表示制御部１２０１によりオリジナル画像の拡大表示を実行することを示すためのメニュー項目である。ポップアップメニュー１３０５はネットプリント注文制御部１２０２によりオリジナル画像のネットプリント注文を実行することを示すためのメニュー項目である。ポップアップメニュー１３０６は画像ダウンロード制御部１２０３によりオリジナル画像のダウンロードを実行することを示すためのメニュー項目である。

一方、図１３（ｂ）のアルバムのメイン画面の一部１３０８には、削除待機画像のサムネイルが表示されている。サムネイル１３０９はアルバムに登録されている削除待機画像のサムネイルの一つであり、選択状態にある。表示１３１０はポインティングデバイス１０５の指示する場所を表示するためのマウスカーソル表示である。本実施形態では、画像サムネイル１３０９を選択した状態でポインティングデバイス１０５の右ボタンクリック等の操作をすることにより、ポップアップメニュー１３１１、１３１２を表示できる。

ポップアップメニュー１３１１は画像の削除を実行するための指令を画像管理部２０３に指示して画像の削除を実行するためのメニュー項目である。ポップアップメニュー１３１２は画像の復元を実行するための指令を画像管理部２０３に指示して、サーバの空き容量に余裕がある場合に限って画像の復元を実行するためのメニュー項目である。

マウスカーソル表示１３０３及び１３１０は夫々画像に対する処理の遂行を指示するために用いられるが、表示されるポップアップメニューの内容は各画像の条件に合わせてアルバム制御部２０２により制御される。これにより本実施形態では、削除待機画像に対してオリジナル画像表示、印刷注文、オリジナル画像のダウンロードの各処理アクセスを実施できないように制御することができる。

以上、図１２及び図１３で説明した方法により、本実施形態の画像管理部２０３において、通常画像に対して提供される諸機能を削除待機画像に対して制限することを可能とすることができる。
なお、図１３では削除待機画像に対して機能を制限するためにポップアップメニューを用いたが、発明の実施形態はこれに限定されるものではない。例えば、予めアルバム画面上に各機能を実施するためのボタン機能を用意して、選択状態にある画像のステータス内容に応じてボタン機能の有効化及び無効化の処理を行うことによっても、同等の機能を得ることが可能である。

次に、本実施形態における画像サーバのアルバム機能において、削除待機画像に対して一定時間経過後に削除処理を実行するための処理について説明する。

図１４は本実施形態における画像サーバを管理するサーバコンピュータ２００において、削除待機画像に対する機能を示すブロック図である。図１４において、２００から２０７までは図２と同等である。また、図１４ではクライアントコンピュータ側のモジュール構成の説明及び表示は割愛してあるが、実際には図２と同様にクライアントコンピュータ２０８がインターネット２０７を介して存在し機能しているものとする。

画像削除制御部１４０１は、後述するタイマー管理部１４０２及びメール送信制御部１４０３に指示することにより、画像管理部２０３より削除待機画像として指示された画像の削除処理を制御を行う。タイマー管理部１４０２は、削除待機画像に対して削除の通知及び実施を行うための契機とするための削除タイマー及び削除通知タイマーを発行する。メール送信制御部１４０３は、タイマー管理部１４０２により発行された削除タイマーイベントの満了を受けて画像削除制御部１４０１の指示によりユーザに対して削除通知を発行し、該当する削除待機画像がまもなく削除されることを通知する。

図１５は本実施形態における画像サーバのアルバム機能において、削除待機画像に対して一定時間経過後に削除処理を実施する処理の一例を説明するためのフローチャートである。

ステップＳ１５０１において、ある画像が削除待機画像３０１に指定されると、ステップＳ１５０２ではタイマー管理部１４０２により削除タイマーが起動される。これにより、一定時間内に復元が行われない限り画像の削除通知が実施される。なお削除タイマーの時間設定は、例えば、１時間単位、１日単位、１週間単位でユーザーが任意に設定しても良いし、予めサーバコンピュータ２００側で設定しておいても良い。

ステップＳ１５０３では、削除タイマー起動中に該当画像が通常登録画像３００に復元されたか否かが判定される。もし、復元されたと判定された場合（ステップＳ１５０３において「ＹＥＳ」）、ステップＳ１５０４で削除タイマーを停止して処理を終える。一方、ステップＳ１５０３で画像が復元されない場合（ステップＳ１５０３において「ＮＯ」）、ステップＳ１５０５に移行する。ステップＳ１５０５では、削除タイマー起動から所定時間が経過して削除タイマーが満了したか否かを判定する。削除タイマーが満了してなければ（ステップＳ１５０５で「ＮＯ」）再びステップＳ１５０３に戻って判定を行う。一方、削除タイマーが満了した場合は（ステップＳ１５０５で「ＹＥＳ」）、ステップＳ１５０６で削除通知メールがメール送信制御部１４０３によりユーザ宛に送信される。削除通知メールが送信されると、ステップＳ１５０７でタイマー管理部１４０２により削除通知タイマーが起動される。これにより、所定時間内に復元が行われない限り画像の削除が実施される。なお削除タイマーの時間設定は、例えば、１時間単位、１日単位、１週間単位でユーザーが任意に設定しても良いし、予めサーバコンピュータ２００側で設定しておいても良い。

ステップＳ１５０８では、削除通知タイマー起動中に該当画像が通常登録画像３００に復元されたか否かが判定される。もし復元された場合（ステップＳ１５０８において「ＹＥＳ」）、ステップＳ１５０９で削除通知タイマーを停止して処理を終える。一方、ステップＳ１５０８で画像が復元されない場合（ステップＳ１５０８において「ＮＯ」）、ステップＳ１５１０に移行する。ステップＳ１５１０では削除通知タイマーが満了したか否かが判定される。もし、削除通知タイマーが満了していない場合（ステップＳ１５１０において「ＮＯ」）、ステップＳ１５０８に戻って処理を継続する。一方、削除通知タイマーが満了した場合（ステップＳ１５１０において「ＹＥＳ」）、ステップＳ１５１１に移行する。ステップＳ１５１１では、画像管理部２０３が該当するオリジナル画像２０５を削除する。

以上のように、本実施形態によれば、画像ＤＢ２０４の容量が不足してきた場合でも、削除候補の画像を決定することで既に格納されているオリジナル画像を削除せずに、新たな画像の追加を先に行うことができる。また、削除候補の画像となった画像もユーザが手動で通常登録画像に復帰させることができるので、新しい画像を追加するために本来必要であった画像が削除されてしまうと言うことが無くなる。

削除候補になった画像でも、実際に削除が行われる場合には予めユーザにその旨が通知されるので、ユーザは通知に対応して削除を回避すべき画像を選択することが可能となる。

また、ユーザが自ら削除を行った場合には、削除候補に指定されていた画像のうちユーザが任意に選択した画像を通常登録画像に復帰させることができるので、削除候補のままオリジナル画像が完全にデータベースから削除されることを防止することができる。

［第２の実施形態］
以下、アルバム画面を利用した発明の第２の実施形態について説明する。図１６は図５で示したアルバム画面の表示状態において、ポインティングデバイス１０５を利用した別の操作方法について説明するための模式図である。図１６において、５００から５１４までの各機能は図５と同じであり説明は割愛する。

矢印１６０１は領域５１０に置かれた削除待機画像を通常画像の領域５０３に向けてポインティングデバイス１０５のドラッグ操作により移動する処理を表している。画像アルバムの容量に余裕がある場合にはドラッグ処理１６０１により、図７で説明した操作画面を使用することなくユーザが指定した削除待機画像を通常の登録画像に復元させることが可能となる。

尚、画像アルバムの残容量が十分でない場合にはオリジナル画像のファイルサイズが残容量よりも大きい画像に対しては、ドラッグ操作を受け付けないように制御することができる。

矢印１６０２は領域５１０に置かれた削除待機画像を削除完了画像の領域５１３に向けてポインティングデバイス１０５のドラッグ操作により移動する処理を表している。ドラッグ処理１６０２により、ユーザが指定した削除待機画像を削除完了画像に設定して、該当画像のオリジナル画像を削除させることが可能となる。

矢印１６０３は、領域５０３に置かれた通常の登録画像を削除待機画像の領域５１０に向けてポインティングデバイス１０５のドラッグ操作により移動する処理を表している。ドラッグ処理１６０３により、ユーザが指定した登録画像を削除待機画像に設定して、該当画像のオリジナル画像のファイルサイズをサーバの使用容量から除外させることが可能となる。

矢印１６０４は、領域５０３に置かれた通常の登録画像を削除完了画像の領域５１３に向けてポインティングデバイス１０５のドラッグ操作により移動する処理を表している。ドラッグ処理１６０４により、ユーザが指定した登録画像を削除完了画像に設定して、該当画像のサムネイル画像を除いてサーバから削除させることが可能となる。

以上の図１６におけるアルバム操作処理１６０１〜１６０４は、アルバム制御部２０２により実施される。また、アルバム操作処理１６０１〜１６０４に伴う画像に対する処理はアルバム制御部２０２から画像管理部２０３へ指示することにより実施される。

［その他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した機能を実現するコンピュータプログラムのコードを記録した記憶媒体を、システムに供給し、そのシステムがコンピュータプログラムのコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたコンピュータプログラムのコード自体が前述した実施形態の機能を実現し、そのコンピュータプログラムのコードを記憶した記憶媒体は本発明を構成する。また、そのプログラムのコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した機能が実現される場合も含まれる。

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

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するコンピュータプログラムのコードが格納されることになる。

発明の第１の実施形態に対応するクライアントコンピュータ及びサーバコンピュータのハードウェア構成を示す図である。 発明の第１の実施形態に対応するサーバ・クライアントシステムの構成を示すブロック図である。 発明の第１の実施形態に対応する残容量不足時の画像登録において、画像の状態遷移を示す模式図である。 発明の第１の実施形態に対応する残容量不足時の画像登録の流れを示すフローチャートである。 発明の第１の実施形態に対応するアルバム画面の表示状態を説明する模式図である。 発明の第１の実施形態に対応する削除待機画像が通常の登録画像に復元される処理の流れを説明するためのフローチャートである。 発明の第１の実施形態に対応する削除待機画像の復元時に使用される操作画面の一例を示す模式図である。 発明の第１の実施形態に対応する削除待機画像の復元処理において、画像の状態遷移を示す模式図である。 発明の第１の実施形態に対応する画像管理に利用される画像情報管理テーブルを示すブロック図である。 発明の第１の実施形態に対応する画像管理部２０３において実施される削除待機画像を指定するための処理の一例を示すフローチャートである。 発明の第１の実施形態に対応する、ユーザの使用容量を画像管理部２０３において計算する方法を説明するための図である。 発明の第１の実施形態に対応する画像サーバを管理するサーバコンピュータにおいて、オリジナル画像への処理アクセスを行う機能を示すブロック図である。 発明の第１の実施形態に対応するアルバム画面の一例であり、オリジナル画像に対する各処理アクセスの実施と、削除禁止画像に対する各処理アクセスの制限とを説明するための模式図である。 発明の第１の実施形態に対応する画像サーバを管理するサーバコンピュータにおいて、削除待機画像に対する機能を示すブロック図である。 発明の第１の実施形態に対応する画像サーバのアルバム機能において、削除待機画像に対して一定時間経過後に削除処理を実施する処理の流れを説明するためのフローチャートである。 発明の第２の実施形態に対応するアルバム画面において、ポインティングデバイス１０５を利用した別の操作方法について説明するための模式図である。

符号の説明

１０１：表示装置
１０２：ＶＲＡＭ
１０３：ＢＭＵ
１０４：キーボード
１０５：ＰＤ
１０６：ＣＰＵ
１０７：ＲＯＭ
１０８：ＲＡＭ
１０９：ＨＤＤ
１１０：ＦＤＤ
１１１：ＮＥＴ Ｉ／Ｆ

Claims (12)

1. 画像データベースに保存された画像をユーザー単位で管理する画像管理装置であって、
   前記画像データベースに格納された画像の管理状態を、該画像に対するユーザからのアクセスに関する情報を含めて画像単位で登録する管理テーブルと、
   前記画像データベースにユーザーの新たな画像を追加する場合に、該画像データベースにおけるユーザに割り当てられた格納領域の残容量を、格納されている画像の前記管理状態を参照して計算し、該残容量が不足するか否かを判定する残容量判定手段と、
   前記残容量が不足すると判定された場合に、前記格納領域に既に格納され前記残容量の計算に含められた画像のうち、該計算から除外すべき画像を前記アクセスに関する情報に基づいて判定する画像判定手段と、
   を備え、
   前記残容量判定手段は、前記残容量の計算から除外すべきと判定された画像を除外して前記残容量を再計算して、前記新たな画像を追加するのに前記残容量が不足するか否かをさらに判定し、
   前記格納領域には前記残容量の計算から除外すべきと判定された画像が依然として保存され、
   前記画像データベースに格納される画像には、オリジナル画像とそのサムネイル画像とが含まれ、
   前記画像の管理状態には、
   前記オリジナル画像と前記サムネイル画像とが前記格納領域に格納されており、前記残容量の計算に該オリジナル画像と該サムネイル画像とを含める画像であることを示す第１の管理状態と、
   前記オリジナル画像と前記サムネイル画像とが前記格納領域に格納されているものの、前記残容量の計算には前記サムネイル画像のみを含める画像であることを示す第２の管理状態と、
   前記サムネイル画像のみが前記格納領域に格納され、前記残容量の計算には前記サムネイル画像を含めない画像であることを示す第３の管理状態と
   が含まれることを特徴とする画像管理装置。
2. 前記サムネイル画像を表示装置に表示させる表示制御手段をさらに備え、
   前記サムネイル画像は、前記第１の管理状態、第２の管理状態及び第３の管理状態ごとに表示されることを特徴とする請求項１に記載の画像管理装置。
3. 前記画像判定手段が前記計算から除外すべきと判定した画像は、前記管理状態が前記第１の管理状態から前記第２の管理状態に変更されることを特徴とする請求項１または２に記載の画像管理装置。
4. 前記管理状態が前記第２の管理状態に変更された画像は、前記オリジナル画像に対するユーザの操作が制限されることを特徴とする請求項３に記載の画像管理装置。
5. 前記ユーザの操作には、前記オリジナル画像の表示、印刷注文、取得の少なくともいずれかが含まれることを特徴とする請求項４に記載の画像管理装置。
6. 前記第２の管理状態に変更された画像のうち、該変更から所定時間が経過した画像について前記格納領域からの削除の旨を前記ユーザに通知する通知手段をさらに備え、
   該通知の後さらに一定時間が経過した前記第２の管理状態の画像につき前記オリジナル画像が前記格納領域から削除されることを特徴とする請求項３乃至５のいずれか１項に記載の画像管理装置。
7. 前記所定時間が経過するまでに、前記第２の管理状態に変更された画像の管理状態が前記第１の管理状態に変更された場合、前記通知手段は前記通知を行われず、
   前記一定時間が経過するまでに、前記第２の管理状態に変更された画像の管理状態が前記第１の管理状態に変更された場合、前記オリジナル画像の削除は行われない
   ことを特徴とする請求項６に記載の画像管理装置。
8. 前記画像判定手段は、ユーザが画像に対して最後にアクセスした時からの経過時間、及び、アクセス回数の少なくともいずれかに基づいて前記計算から除外すべき画像を判定することを特徴とする請求項１乃至７のいずれか１項記載の画像管理装置。
9. 前記管理テーブルは、対応する画像の削除を禁止するか否かを指定する削除禁止フラグを更に含み、
   前記画像判定手段は、前記削除禁止フラグにおいて削除の禁止が指定されている画像は、前記計算から除外すべき画像と判定しないことを特徴とする
   請求項１乃至８のいずれか１項に記載の画像管理装置。
10. 前記画像データベースより画像が削除された場合に、前記残容量判定手段は削除後の残容量を計算し、
    前記画像判定手段は、前記残容量の計算から除外された画像のうち該計算に再び含めることが可能な画像を前記削除後の残容量に基づいて判定し、
    前記計算に再び含めることが可能と判定された画像のうち、前記ユーザが選択した画像の前記管理状態が変更されて、前記残容量判定手段による残容量の計算に含まれることとなることを特徴とする請求項１乃至９のいずれか１項に記載の画像管理装置。
11. 画像データベースに保存された画像を、該画像データベースに格納された画像の管理状態を該画像に対するユーザからのアクセスに関する情報を含めて画像単位で登録する管理テーブルを用いて、ユーザー単位で管理する画像管理方法であって、
    残容量判定手段が、前記画像データベースにユーザーの新たな画像を追加する場合に、該画像データベースにおけるユーザに割り当てられた格納領域の残容量を、格納されている画像の前記管理状態を参照して計算し、該残容量が不足するか否かを判定する残容量判定工程と、
    画像判定手段が、前記残容量が不足すると判定された場合に、前記格納領域に既に格納され前記残容量の計算に含められた画像のうち、該計算から除外すべき画像を前記アクセスに関する情報に基づいて判定する画像判定工程と、
    前記残容量判定手段が、前記残容量の計算から除外すべきと判定された画像を除外して前記残容量を再計算して、前記新たな画像を追加するのに前記残容量が不足するか否かをさらに判定する工程と
    を備え、
    前記格納領域には前記残容量の計算から除外すべきと判定された画像が依然として保存され、
    前記画像データベースに格納される画像には、オリジナル画像とそのサムネイル画像とが含まれ、
    前記画像の管理状態には、
    前記オリジナル画像と前記サムネイル画像とが前記格納領域に格納されており、前記残容量の計算に該オリジナル画像と該サムネイル画像とを含める画像であることを示す第１の管理状態と、
    前記オリジナル画像と前記サムネイル画像とが前記格納領域に格納されているものの、前記残容量の計算には前記サムネイル画像のみを含める画像であることを示す第２の管理状態と、
    前記サムネイル画像のみが前記格納領域に格納され、前記残容量の計算には前記サムネイル画像を含めない画像であることを示す第３の管理状態と
    が含まれることを特徴とする画像管理方法。
12. コンピュータを請求項１乃至１０のいずれか１項に記載の画像管理装置として動作させるためのコンピュータプログラム。

Images