JP2009134457A - プログラム及び画像ファイル管理装置 - Google Patents

Abstract

【課題】互いに関連する複数のファイルの削除の際の処理を円滑に行うことができるプログラム及び画像ファイル管理装置等を提供する。
【解決手段】「ＡＰＰ１」１１３のデータ領域には、オリジナル画像ファイル１００の格納場所を示すアドレスタグ１２１、及び、ショートカット画像ファイル１０１に対応するオリジナル画像ファイル１００の削除に関する情報を示す削除タグ１２２が格納される。削除タグ１２２が「可」を示している場合、当該ショートカット画像ファイル１０１が削除されると、これに対応するオリジナル画像ファイル１００も削除される。つまり、削除タグ１２２がオリジナル画像ファイル１００の削除を肯定している場合には、オリジナル画像ファイル１００も削除される。一方、削除タグ１２２が「否」を示している場合には、当該ショートカット画像ファイル１０１が削除されても、これに対応するオリジナル画像ファイル１００は削除されない。
【選択図】図２

Description

本発明は、画像ファイルの分割記録に好適なプログラム及び画像ファイル管理装置等に関する。

画像ファイルの管理方法として、ＤＣＦ（Design rule for Camera File system）規格のように高解像度の実画像データと低解像度のサムネイル画像データとを一つの画像ファイルにするフォーマットを採用した方法が提案されている。この管理方法では、画像データの詳細な情報を知りたいときには高解像度の画像データを参照し、画像データの概要がわかればよいときには低解像度の画像データを参照することとなる。従って、画像データを使用する目的によって参照する情報を選択することができるという利点がある。

その一方で、上記画像データの管理方法では、必ず低解像度の画像データと高解像度の画像データとが一つのファイルとして構成されている。このため、画像データの概要だけわかればよく、高解像度の画像データを参照しない場合においても、高解像度の画像データを含んだ大きなファイルサイズとして取り扱わなければならないという問題がある。特に、電子メール及びファクシミリ等のデータ通信において、送受信する画像ファイルのデータサイズの効率化は重要である。

画像ファイルのデータサイズの効率化に関し、特許文献１には、次のような技術が記載されている。先ず、低解像度の画像データと高解像度の画像データとを切り分けて、低解像度の画像データのみを電子メールに添付して送信する。そして、受信した相手は高解像度の画像データが必要なときだけ電子メールに記された指示に従って、高解像度の画像データを別の通信手段で取得する。

しかしながら、特許文献１の管理方法においては、高解像度の画像データを取得する場合には、低解像度の画像データが添付された電子メールの指示に従う必要がある。つまり、低解像度の画像データで構成される画像ファイルのみを手がかりに、高解像度の画像データが含まれる画像ファイルを参照することができない。

また、特許文献２には、次のような技術が記載されている。先ず、第１のオリジナル画像ファイルのうち、第１の画像よりも低解像度であるサムネイルのみを有する第２の画像ファイルを、第１の画像ファイルから切り分ける。そして、通常は第２の低解像度の画像を取り扱い、必要に応じて第１の高解像度の画像データを利用することで、高解像度なデータと低解像度なデータを別々に管理する。

また、特許文献３には、特許文献２の分割管理方法にしたがって分割された画像ファイルを用いて、低解像度なデータから高解像度なデータを取得する手順が記載されている。

このように、特許文献２の管理方法は、画像の分割管理方法に関するフォーマット規定の発明であり、特許文献２では上記分割管理方法にしたがって画像ファイルを作成する手順について提案されている。また、特許文献３の画像データ処理方法は、画像の取得方法に関する発明であり、特許文献２の分割管理方法にしたがって分割された画像ファイルを取得する手順について提案されている。

しかしながら、特許文献２及び特許文献３には、いずれも、第１のオリジナル画像ファイル（高解像度なデータ）及び第２のサムネイル画像ファイル（低解像度なデータ）の削除の際の処理に関する記載がない。

互いに関連する画像を消去する技術に関し、特許文献４には、主画像と１つ以上の異なる副画像の対応を管理するためのリレーショナルファイルを作成して、この情報を元に、画像の削除を行う技術が記載されている。画像の削除の方法としては、主画像と副画像すべてを消去／副画像すべてを消去／選択した１つの副画像のみ消去、の３種類の方法が記載されている。

また、特許文献５には、オリジナル画像からサムネイル画像を作成する際に、オリジナル画像のあるディレクトリ名とオリジナル画像のファイル名から、サムネイル画像のファイル名を作成し、オリジナル画像とサムネイル画像を関連付ける技術が記載されている。そして、いずれか一方を削除すると、もう一方が自動的に削除されている。

特開平１０−２３３８６０号公報 特開２００５−３２６９０８号公報 特開２００６−１３９６３２号公報 特許第３５５６２６５号公報 特開２００３−２０８４４８号公報

しかしながら、特許文献４又は５に記載されている技術を採用したのでは、操作及び処理が煩雑なものとなりやすい。また、不意に主画像又はオリジナル画像が消滅してしまうこともあり得る。

本発明は、互いに関連する複数のファイルの削除の際の処理を円滑に行うことができるプログラム及び画像ファイル管理装置等を提供することを目的とする。

ここで、特許文献２又は特許文献３に記載されている第１のオリジナル画像ファイル（高解像度なデータ）及び第２のサムネイル画像ファイル（低解像度なデータ）の使い方について検討する。第１のオリジナル画像ファイルをネットワーク上のサーバ又はユーザのパーソナルコンピュータ等に記憶し、第２のサムネイル画像ファイルをユーザのデジタルカメラ又はＰＤＡ（Personal Digital Assistant）等の電子機器に保存することが想定される。そして、ユーザは電子機器上で、第２のサムネイル画像ファイルを閲覧して、特定の画像を印刷したい場合及びより大きいサイズの画像を扱いたい場合等に、サーバ等から対応する第１のオリジナル画像ファイルを取得することも想定される。また、ユーザが画像ファイルを他人に配布したい場合には、第１のオリジナル画像ファイルを配布するとデータサイズが大きくなるため、データサイズの小さい第２のサムネイル画像ファイルをコピーして配布することも想定される。更に、ユーザが第２のサムネイル画像ファイルを、デジタルカメラ、ＰＤＡ及び携帯電話等の複数の電子機器で閲覧するために、第２のサムネイル画像ファイルをコピーして、他の電子機器に保存することも想定される。このため、第１のオリジナル画像ファイルをサーバ等に１つ保存してあるのに対して、第２のサムネイル画像ファイルは、ユーザの複数の電子機器に保存されていたり、他人に配布されていたりする。つまり、複数のサムネイル画像ファイルが存在することが想定される。

次に、画像ファイルの削除処理について検討する。第１のオリジナル画像ファイルと第２のサムネイル画像ファイルとが１対１の関係にある場合には、操作及び処理の簡素化のためには、いずれか一方が削除されると、もう一方も削除されることが望ましい。ユーザが閲覧する画像ファイルは、多くの場合、第２のサムネイル画像ファイルであるため、第２のサムネイル画像ファイルが削除されると、これに対応する第１のオリジナル画像ファイルも削除されるように関連付けられていることが望ましい。

ところが、上述のように、第１のオリジナル画像ファイルと第２のサムネイル画像ファイルとが１対１の関係にあるとは限らず、１個の第１のオリジナル画像ファイルに関連する第２のサムネイル画像ファイルが複数存在することもある。このような場合、１個の第２のサムネイル画像ファイルが削除されただけで、第１のオリジナル画像ファイルが削除されたのでは、不都合が生じることがある。例えば、ユーザの電子機器に保存してある第２のサムネイル画像ファイルと、ユーザが他人に配布した第２のサムネイル画像ファイルとでは、その重要度が異なることがある。即ち、第１のオリジナル画像ファイルがユーザにとっては非常に重要なものであっても、配布された者にとっては、一度閲覧すれば十分に満足を得られることがある。このような場合、配布された者が、受け取った第２のサムネイル画像ファイルを直ぐに削除することも想定される。このような場合に、第１のオリジナル画像ファイルが削除されたのでは、配布したユーザの不具合は計り知れない。このため、どのようなタイミングで第１のオリジナル画像ファイルを削除すればよいか、という課題がある。

従って、互いに関連する複数のファイルを作成する場合には、これらの削除に関連する条件を適切に規定しておき、この条件に従った削除処理を行うことが望ましい。

本願発明者は、このような状況に鑑みて鋭意検討を重ねた結果、以下に示す発明の諸態様に想到した。

本発明に係る第１のプログラムは、コンピュータに、画像ファイルの削除の命令を受けた場合に、当該画像ファイルに派生元となる派生元画像ファイルの削除に関する情報を示す削除タグが存在するか判断するタグ判断ステップと、前記削除タグが存在し、かつ当該削除タグが前記派生元画像ファイルの削除を肯定している場合に、前記派生元画像ファイルの削除を命令する削除命令ステップと、を実行させることを特徴とする。

本発明に係る第２のプログラムは、コンピュータに、第１の画像データを含む派生元画像ファイルから、前記第１の画像データよりも解像度が低い第２の画像データを取得する取得ステップと、前記派生元画像ファイルの削除に関する情報を示す削除タグを作成するタグ作成ステップと、前記第２の画像データ及び前記削除タグを含む画像ファイルを作成するファイル作成ステップと、を実行させることを特徴とする。

本発明によれば、画像ファイルに、その派生元画像ファイルの削除に関する情報を示す削除タグが付されるので、画像ファイルの削除と派生元画像ファイルの削除とを関連付けることができる。このため、これらの削除の際の処理を円滑に行うことができる。

以下、本発明の実施形態について添付の図面を参照して具体的に説明する。

（第１の実施形態）
先ず、本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態に係る画像ファイル管理方法の実行に用いられる画像ファイル管理システムを示す図である。

図１に示すように、この画像データ処理システムには、サーバ１４０１と、ネットワーク１４０５を介してこのサーバ１４０１に接続されたターミナル（端末装置）１４０６とが含まれている。サーバ１４０１の内部には、ＣＰＵ１４０２、メモリ１４０３及びＨＤＤ１４０４等が含まれている。また、ＨＤＤ１４０４には、例えば、オンラインフォトアルバムサービス等の提供に関するプログラムが記録されている。ターミナル１４０６は、例えば、パーソナルコンピュータであり、その内部には、ＣＰＵ１４０７、メモリ１４０８、ＨＤＤ１４０９等が含まれている。本実施形態では、サーバ１４０１及びターミナル１４０６が画像ファイル管理装置として機能する。なお、ターミナル１４０６として、スキャナ、デジタルカメラ又はＰＤＡ等を用いてもよい。なお、サーバ１４０１として、プリンタ等を用いてもよい。また、ネットワーク１４０５として、ＵＳＢ等のローカル環境における通信等を用いてもよい。

また、サーバ１４０１及びターミナル１４０６に入力インタフェースが設けられており、画像ファイルを格納した画像記録装置１４１０がサーバ１４０１及びターミナル１４０６に接続可能となっている。画像記録装置１４１０は、例えばデジタルカメラである。

ここで、本実施形態において処理される画像ファイルのフォーマットについて説明する。本実施形態では、オリジナル画像ファイル（派生元画像ファイル）及びショートカット画像ファイル（画像ファイル）の２種類の画像ファイルが処理対象となっている。オリジナル画像ファイルは、例えばデジタルカメラ（撮像装置）による撮影により得られた画像（オリジナル画像）データを含むファイルであって解像度が高い画像データ（オリジナル画像データ）を含む。一方、ショートカット画像ファイルは、オリジナル画像データに基づいて作成されたオリジナル画像データよりも解像度が低い画像（ショートカット画像）データを含むファイルである。ショートカット画像ファイルには、少なくとも、オリジナル画像データのサムネイル画像のデータ及びオリジナル画像ファイルの所在位置を示す情報が含まれている。

また、本実施形態では、画像ファイルの基本フォーマットとしてＤＣＦ／Ｅｘｉｆ形式を用いる。従って、以下の説明では、画像ファイルの特定部分を示す用語として必要に応じてＤＣＦ／Ｅｘｉｆ（Exchangeable Image File）規格（又はＪＰＥＧ規格）において対応する部分を示す用語を用いる。

図２は、オリジナル画像ファイル（派生元画像ファイル）及びショートカット画像ファイルのフォーマットを示す模式図である。

先ず、オリジナル画像ファイル１００について説明する。オリジナル画像ファイル１００のＤＣＦ基本ファイルのフォーマットには、「ＳＯＩ（Start of Image）」１０２、「ＡＰＰ１」１０３、ＤＣＦ基本主画像データ１０４及び「ＥＯＩ（End of Image）」１０５が含まれている。「ＳＯＩ」１０２は、圧縮画像データの先頭を示すマーカーコード（通常０ｘＦＦＤ８）である。「ＥＯＩ」１０５は、「ＳＯＩ」１０２と対をなして圧縮画像データの終了を示すマーカーコード（通常０ｘＦＦＤ９）である。ＤＣＦ規格においては、ＳＯＩから始まりＥＯＩでデータが終わるように規定されている。「ＡＰＰ１」１０３はアプリケーションマーカーセグメントであり、主画像の付加情報及び低解像度の画像データであるサムネイル画像データ１０６が「ＡＰＰ１」１０３のデータ領域に格納される。サムネイル画像データ１０６のファイルのフォーマットには、「ＳＯＩ」１０２、「ＡＰＰ１」１０７、ＤＣＦ基本サムネイル画像データ１０８及び「ＥＯＩ」１０５が含まれている。そして、ＤＣＦ基本ファイルと同様に、ＳＯＩから始まりＥＯＩでデータが終わるように規定されている。なお、サムネイル画像データ１０６の「ＡＰＰ１」１０７はＤＣＦ基本ファイルの「ＡＰＰ１」１０３と同じ内容のデータを有していてもよい。ＤＣＦ基本サムネイル画像データ１０８に対し、ＤＣＦ基本主画像データ１０４は高解像度の画像データとなっている。

このように、本実施形態におけるＤＣＦ規格に準拠したオリジナル画像ファイル１００には、低解像度のＤＣＦ基本サムネイル画像データ１０８と高解像度のＤＣＦ基本主画像データ１０４（第１の画像データ）とが含まれている。従って、ユーザは、画像の概要を知りたいときにはＤＣＦ基本サムネイル画像データ１０８を参照し、画像の詳細を知りたいときにはＤＣＦ基本主画像データ１０４を、夫々参照すればよい。

次に、ショートカット画像ファイル１０１について説明する。ショートカット画像ファイル１０１のＤＣＦ基本ファイルのファイルフォーマットには、「ＳＯＩ」１０２、「ＡＰＰ１」１１３、ヌル（ＮＵＬＬ）データ１１４及び「ＥＯＩ」１０５が含まれている。「ＡＰＰ１」１１３のデータ領域には、サムネイル画像データ１１６が格納される。更に、オリジナル画像ファイル１００の格納場所を示すアドレスタグ１２１、及び、ショートカット画像ファイル１０１に対応するオリジナル画像ファイル１００の削除に関する情報を示す削除タグ１２２も、「ＡＰＰ１」１１３のデータ領域に格納される。削除タグ１２２が「可」を示している場合、当該ショートカット画像ファイル１０１が削除されると、これに対応するオリジナル画像ファイル１００も削除される。つまり、削除タグ１２２がオリジナル画像ファイル１００の削除を肯定している場合には、オリジナル画像ファイル１００も削除される。一方、削除タグ１２２が「否」を示している場合には、当該ショートカット画像ファイル１０１が削除されても、これに対応するオリジナル画像ファイル１００は削除されない。このように、オリジナル画像ファイル１００とは異なり、ＤＣＦ基本主画像データが必要とされず、その代りにＮＵＬＬデータ１１４が格納されている。サムネイル画像データ１１６（第２の画像データ）のファイルのフォーマットには、「ＳＯＩ」１０２、「ＡＰＰ１」１１７、ＤＣＦ基本サムネイル画像データ１１８及び「ＥＯＩ」１０５が含まれている。そして、ＤＣＦ基本ファイルと同様に、ＳＯＩから始まりＥＯＩでデータが終わるように規定されている。なお、サムネイル画像データ１１６の「ＡＰＰ１」１１７はＤＣＦ基本ファイルの「ＡＰＰ１」１１３と同じ内容のデータを有していてもよい。

このように、本実施形態におけるショートカット画像ファイル１０１はＤＣＦ規格に準拠しつつ、その「ＡＰＰ１」１１３のデータ領域に、アドレスタグ１２１及び削除タグ１２２が付与されている。また、主画像データは不要である。

なお、ショートカット画像ファイル１０１に主画像データが含まれていてもよい。また、一つのオリジナル画像ファイル１００に対して、複数のショートカット画像ファイル１０１が存在していてもよい。また、アドレスタグ１２１が含まれていれば、当該ファイルがショートカット画像ファイル１０１であると認識できるが、その他に、当該ファイルをオリジナル画像データと識別するためのタグ等の標識が付されていてもよい。

次に、アドレスタグ１２１のデータ構成について説明する。図３は、アドレスタグ１２１のデータ構成を示す図である。

アドレスタグ１２１に相当するアドレスタグ２００は、Ｅｘｉｆ（ＤＣＦ）規約に基づき「Ｅｘｉｆ ＩＦＤ」内に記録される。アドレスタグ２００のタグ番号としては、Ｔｉｆｆのプライベートタグ番号（例えば、４３０００）が利用される。

アドレスタグ２００の内容を示すタグのＶａｌｕｅは、「Ｖａｌｕｅ ｏｆ Ｅｘｉｆ ＩＦＤ」内に記録される。Ｖａｌｕｅの格納場所は、アドレスタグ２００の「Ｖａｌｕｅ Ｏｆｆｓｅｔ」に記される。アドレスタグ２００の「Ｔａｇ」、「Ｔｙｐｅ」、「Ｃｏｕｎｔ」、「Ｖａｌｕｅ Ｏｆｆｓｅｔ」は特に規定しないが、例えば「Ｔｙｐｅ」は「ＡＮＹ」、「Ｃｏｕｎｔ」も「Ａｎｙ」としておく。

アドレスタグ２００の内容２０１（アドレスタグのＶａｌｕｅ）は、例えば次のように構成されている。即ち、図３に示すように、「アドレスタグのＶａｌｕｅ」の先頭には、以降続く文字コードを識別するための文字コード種別情報２０２が記録される。この文字コード種別情報２０２としては、例えばＡＳＣＩＩコード、ＪＩＳコード、Ｕｎｉｃｏｄｅ、又はそれ以外の文字コードが指定される。

文字コード種別情報２０２に続いて、オリジナル画像ファイル１００の格納場所を示すアドレス文字列２０３が「アドレスタグのＶａｌｕｅ」に記録される。アドレス文字列２０３には、オリジナル画像ファイル１００の格納場所を示すパス名と、オリジナル画像ファイルのファイル名とが含まれる。「アドレスタグのＶａｌｕｅ」へのオフセットは、ＴＩＦＦの規定に従ってアドレスタグ２００の「Ｖａｌｕｅ Ｏｆｆｓｅｔ」に記される。

なお、「アドレスタグのＶａｌｕｅ」に、文字コード種別情報２０２が記録されずに、オリジナル画像ファイル１００のアドレスを示す文字列２０３のみが記録されてもよい。例えば、文字コードとして一定のコード（例えばＵＴＦ−８）を固定的に用いる場合には、文字コード種別情報２０２は必要ない。一方、ＵＴＦ−１６で符号化する場合は、ＩＳＯ／ＩＥＣ １０６４６の附属書Ｅ及びＵｎｉｃｏｄｅの付録Ｂで規定するバイト順マーク（「ＺＥＲＯ ＷＩＤＴＨ ＮＯ−ＢＲＥＡＫ ＳＰＡＣＥ文字」、０ｘＦＥＦＦ又は０ｘＦＦＦＥ）で始まらなければならない。また、明示的にＵＴＦ−８であることを識別するために、先頭の３バイトに識別コード（０ｘＥＦ ０ｘＢＢ ０ｘＢＦ）を入れてもよい。

また、「アドレスタグのＶａｌｕｅ」は、ＵＤＦに従って記録されてもよい。このときは、Ｖａｌｕｅの先頭１バイトに文字コード種別、次の１バイトに文字列長、続けてオリジナル画像の格納場所を示すアドレス文字列が記録される。

本実施形態では、このようなアドレスタグ１２１が各ショートカット画像ファイル１０１に付与されている。このため、ショートカット画像ファイル１０１にアクセス可能なアプリケーション又は画像制御装置は、ショートカット画像ファイル１０１から、これに対応するオリジナル画像ファイル１００の格納場所を取得することができる。従って、例えば、オリジナル画像ファイル１００をファイルサイズが大きい場合でも、これをサーバ１４０１等に格納しておけば、ファイルサイズの小さいショートカット画像ファイル１０１を介して容易にオリジナル画像ファイル１００を使用することができる。即ち、ターミナル１４０６の記憶容量が小さい場合でも、容易にかつ的確にオリジナル画像ファイル１００にアクセスすることができる。

また、画像データの概要だけわかればよい場合には、画像を格納するメモリエリアを圧迫しないファイルサイズの小さいショートカット画像ファイル１０１を利用すればよい。また、画像に対する詳細な情報を得たい場合には、オリジナル画像ファイル１００を利用すればよい。

次に、削除タグ１２２のデータ構成について説明する。図４は、削除タグ１２２のデータ構成を示す図である。

削除タグ１２２に相当する削除タグ７００は、Ｅｘｉｆ（ＤＣＦ）規約に基づき「Ｅｘｉｆ ＩＦＤ」内に記録される。削除タグ７００のタグ番号としては、Ｔｉｆｆのプライベートタグ番号（例えば、４３００１）が利用される。

削除タグ７００の内容を示すタグのＶａｌｕｅは、「Ｖａｌｕｅ ｏｆ ＥＸＩＦ ＩＦＤ」内に記録される。Ｖａｌｕｅの格納場所は、削除タグ７００の「Ｖａｌｕｅ Ｏｆｆｓｅｔ」に記される。削除タグ７００の「Ｔａｇ」、「Ｔｙｐｅ」、「Ｃｏｕｎｔ」、「Ｖａｌｕｅ Ｏｆｆｓｅｔ」は特に規定しないが、例えば「Ｔｙｐｅ」は「ＡＮＹ」、「Ｃｏｕｎｔ」も「Ａｎｙ」としておく

削除タグ７００の内容７０１（削除タグのＶａｌｕｅ）は、例えば次のように構成されている。即ち、図４に示すように、「削除タグのＶａｌｕｅ」の先頭には、以降続く文字コードを識別するための文字コード種別情報７０２が記録される。この文字コード種別情報７０２にとして、例えばＡＳＣＩＩコード、ＪＩＳコード、Ｕｎｉｃｏｄｅ、又はそれ以外の文字コードが指定される。

文字コード種別情報７０２に続いて、オリジナル画像ファイル１００の削除の可否を示す文字列７０３が「削除タグのＶａｌｕｅ」に記録される。「削除タグのＶａｌｕｅ」へのオフセットは、ＴＩＦＦの規定に従って削除タグ７００の「Ｖａｌｕｅ Ｏｆｆｓｅｔ」に記される。

なお、「削除タグのＶａｌｕｅ」には、文字コード種別情報７０２が記録されずに、オリジナル画像ファイル１００の削除に関する情報を示す文字列７０３のみが記録されてもよい。例えば、文字コードとして一定のコード（例えばＵＴＦ−８）を固定的に用いる場合には、文字コード種別情報７０２は必要ない。一方、ＵＴＦ−１６で符号化する場合は、ＩＳＯ／ＩＥＣ １０６４６の附属書Ｅ及びＵｎｉｃｏｄｅの付録Ｂで規定するバイト順マーク（「ＺＥＲＯ ＷＩＤＴＨ ＮＯ−ＢＲＥＡＫ ＳＰＡＣＥ文字」、０ｘＦＥＦＦ又は０ｘＦＦＦＥ）で始まらなければならない。また、明示的にＵＴＦ−８であることを識別するために、先頭の３バイトに識別コード（０ｘＥＦ ０ｘＢＢ ０ｘＢＦ）を入れてもよい。

また、「削除タグのＶａｌｕｅ」は、ＵＤＦに従って記録されてもよい。このときは、Ｖａｌｕｅの先頭１バイトに文字コード種別、次の１バイトに文字列長、続けてオリジナル画像の格納場所を示すアドレス文字列が記録される。

本実施形態では、このような削除タグ１２２が各ショートカット画像ファイル１０１に付与されている。このため、ショートカット画像ファイル１０１にアクセス可能なアプリケーション又は画像制御装置は、ショートカット画像ファイル１０１から、これに対応するオリジナル画像ファイル１００の削除に関する情報を取得することができる。従って、ショートカット画像ファイル１０１を削除しようとする際に、これに対応するオリジナル画像ファイル１００を削除してよいかどうかを容易に判断することができる。

次に、オリジナル画像ファイル１００からショートカット画像ファイル１０１を作成する方法について説明する。図５は、ショートカット画像ファイル１０１を作成する方法を示すフローチャートである。ショートカット画像ファイル１０１の作成は、サーバ１４０１、ターミナル１４０６及び画像記録装置１４１０のいずれにおいても可能であるが、以下の説明では、サーバ１４０１において作成されるものとする。なお、ターミナル１４０６又は画像記録装置１４１０において作成される場合にも同様の処理が実行される。

先ず、ＣＰＵ１４０２が、ショートカット画像ファイルを作成しようとするオリジナル画像ファイル１００を参照する（ステップＳ５００）。以下の説明では、オリジナル画像ファイル１００のファイル名が「IMG_0011.JPＧ」であるとする。なお、オリジナル画像ファイル１００の格納場所は、ＣＰＵ１４０２がアクセス可能な範囲内であれば、特に限定されない。例えば、サーバ１４０１内に格納されていてもよく、ターミナル１４０６又は画像記録装置１４１０内に格納されていてもよい。

次に、ＣＰＵ１４０２は、当該オリジナル画像ファイル１００に対応するサムネイル画像データ１０６が存在するか否かを判別する（ステップＳ５０１）。

そして、ステップＳ５０１の結果、当該オリジナル画像ファイル１００にサムネイル画像データ１０６が存在すれば、ＣＰＵ１４０２は、当該サムネイル画像データ１０６を抽出する（ステップＳ５０４）。次いで、ＣＰＵ１４０２は、当該サムネイル画像データ１０６をサムネイル画像データ１１６とすると決定する（ステップＳ５０５）。

一方、ステップＳ５０１の結果、当該オリジナル画像ファイル１００にサムネイル画像データ１０６が存在しなければ、ＣＰＵ１４０２は、オリジナル画像ファイル１００の主画像データ１０４から任意の間引きを行う。つまり、ＣＰＵ１４０２は、主画像データ１０４から縮小画像データを作成する（ステップＳ５０２）。次いで、ＣＰＵ１４０２は、当該縮小画像データをサムネイル画像データ１１６とすると決定する（ステップＳ５０３）。

このようにして、オリジナル画像ファイル１００のサムネイル画像データ１０６、又はオリジナル画像ファイル１００の主画像データ１０４を縮小した画像データがサムネイル画像データ１１６として取得される。

ステップＳ５０３又はＳ５０５の後、ＣＰＵ１４０２は、当該オリジナル画像ファイル１００の格納予定場所を示すアドレスタグ１２１を生成する。そして、ＣＰＵ１４０２はこれをサムネイル画像データ１１６（ステップＳ５０３又はＳ５０５）に付与する（ステップＳ５０６）。この処理の詳細については後述する。

その後、ＣＰＵ１４０２は、当該オリジナル画像ファイル１００の削除に関する情報を示す削除タグ１２２を生成する。そして、ＣＰＵ１４０２は、これをサムネイル画像データ１１６（ステップＳ５０３又はＳ５０５）に付与する（ステップＳ５０７）。この削除タグ作成の処理の詳細については後述する。

このようにして、ショートカット画像ファイル１０１のファイル作成が行われる。ファイル名が「IMG_0011.JPG」のオリジナル画像ファイル１００に対して作成されたショートカット画像ファイル１０１のファイル名は、例えば「img_0011.JPG」とする。

なお、ショートカット画像ファイル１０１に、オリジナル画像ファイル１００と同じ主画像データ１０４を含ませてもよい。

また、デジタルカメラ（画像記録装置１４１０）における写真撮影に伴うオリジナル画像ファイル１００の作成に続けて、図５に示すフローに従ってショートカット画像ファイル１０１が作成されてもよい。つまり、ショートカット画像ファイル１０１の作成処理がオリジナル画像ファイル１００の作成処理と一連のものとなっていてもよい。

次に、ステップＳ５０６におけるアドレスタグ１２１を作成する方法について説明する。図６は、アドレスタグ１２１を作成する方法を示すフローチャートである。

アドレスタグ１２１には、オリジナル画像ファイル１００の格納場所を示すパス名（文字列Ｂ）６０２、オリジナル画像ファイル１００のファイル名（文字列Ｃ）６０３、並びに文字列Ｂ及びＣの文字コードを示す文字コード種別情報（文字列Ａ）６０１が含まれる。なお、上述のように、文字コード種別情報（文字列Ａ）６０１が含まれていなくてもよい。

先ず、ＣＰＵ１４０２は、当該オリジナル画像ファイル１００のアドレスをどのように決定するのかを判別する（ステップＳ６０４）。ここでは、オリジナル画像ファイル１００の現在の格納場所をオリジナル画像ファイル１００の格納予定場所とするか、それ以外の任意の場所をオリジナル画像ファイル１００の格納予定場所とするか判断する。

そして、ステップＳ６０４の結果、現在の格納場所をオリジナル画像ファイル１００の格納予定場所とする場合、ＣＰＵ１４０２は、現在のオリジナル画像ファイル１００の格納場所（アドレス）をパス名（文字列Ｂ）６０２として取得する（ステップＳ６０５）。

一方、ステップＳ６０４の結果、任意の格納場所をオリジナル画像ファイル１００の格納予定場所とするのであれば、当該任意の格納場所を示す文字列をパス名（文字列Ｂ）６０２として取得する（ステップＳ６０６）。任意の格納場所は、例えば、サーバ１４０１上で動作するアプリケーション等を用いてユーザが設定する。例えば、オリジナル画像ファイル１００が常にサーバ１４０１の「http://www.canon.co.jp/original-image/」に格納されることが設定される。

ここでは、オリジナル画像ファイル１００の格納予定場所として、予め「http://www.canon.co.jp/original-image/」が設定されているとする。従って、「http://www.canon.co.jp/original-image/」がパス名（文字列Ｂ）６０２として取得される。

ステップＳ６０５又はＳ６０６の後、ＣＰＵ１４０２は、オリジナル画像ファイル１００のファイル名（文字列Ｃ）６０３を取得する（ステップＳ６０７）。ここでは、「IMG_0011.JPG」がファイル名（文字列Ｃ）６０３として取得される。

次いで、ＣＰＵ１４０２は、文字コード種別情報（文字列Ａ）６０１、パス名（文字列Ｂ）６０２、及びファイル名（文字列Ｃ）６０３を結合させて、オリジナル画像ファイル１００のアドレスを示す文字列を作成する（ステップＳ６０８）。このとき、文字コード種別情報（文字列Ａ）６０１を含ませなくてもよい。例えば、文字列Ｂ及び文字列ＣをＵＴＦ−８で符号化して記述する場合には、文字列Ａは不要となる。

その後、ＣＰＵ１４０２は、ステップＳ６０７で作成した文字列をＶａｌｕｅとするアドレスタグ１２１を作成し、これをサムネイル画像データ１１６（ステップＳ５０３又はＳ５０５）に付与する（ステップＳ６０９）。ここでは、「http://www.canon.co.jp/original-image/ IMG_0011.JPG」をＶａｌｕｅとするアドレスタグ１２１が、ファイル名が「img_0011.JPG」であるショートカット画像ファイル１０１に付与される。

次に、ステップＳ５０７における削除タグ１２２を作成する方法について説明する。図７は、削除タグ１２２を作成する方法を示すフローチャートである。

削除タグ１２２には、オリジナル画像ファイル１００の削除に関する情報を示す削除情報（文字列Ｂ）８０２、及び文字列Ｂの文字コードを示す文字コード種別情報（文字列Ａ）８０１が含まれる。なお、上述のように、文字コード種別情報（文字列Ａ）８０１が含まれていなくてもよい。

先ず、ＣＰＵ１４０２は、削除タグ１２２を付与しようとしているショートカット画像ファイル１０１が、当該オリジナル画像ファイル１００にとって最初に作成されるショートカット画像ファイル１０１であるかどうかを判別する（ステップＳ８０３）。言い換えると、ＣＰＵ１４０２は、当該オリジナル画像ファイル１００から初めてショートカット画像ファイル１０１が作成されている過程にあるかどうかを判別する。

そして、ステップＳ８０３の結果、最初のショートカット画像ファイル１０１であれば、ＣＰＵ１４０２は、削除情報（文字列Ｂ）８０２を「可」に決定する（ステップＳ８０５）。

一方、ステップＳ８０３の結果、最初のショートカット画像ファイル１０１ではなければ、ＣＰＵ１４０２は、削除情報（文字列Ｂ）８０２を「否」に決定する（ステップＳ８０４）。これは、オリジナル画像ファイル１００を削除できるショートカット画像ファイル１０１が複数存在する状態になることを防止するためである。

ここでは、ファイル名が「IMG_0011.JPG」のオリジナル画像ファイル１００に最初のショートカット画像ファイル１０１が作成されていることとする。従って、「可」が削除情報（文字列Ｂ）８０２として決定される。

ステップＳ８０４又はＳ８０５の後、ＣＰＵ１４０２は、文字コード種別情報（文字列Ａ）８０１、及び削除情報（文字列Ｂ）８０２を結合させて、削除の可否に関する文字列を作成する（ステップＳ８０６）。このとき、文字コード種別情報（文字列Ａ）８０１を含ませなくてもよい。

その後、ＣＰＵ１４０２は、ステップＳ８０６で作成した文字列をＶａｌｕｅとする削除タグ１２２を作成し、これをサムネイル画像データ１１６（ステップＳ５０３又はＳ５０５）に付与する（ステップＳ８０７）。ここでは、「可」をＶａｌｕｅとする削除タグ１２２が付与される。

このようにして（図５〜図７）、オリジナル画像ファイル１００からショートカット画像ファイル１０１が作成される。例えば、サーバ１４０１に保存されるファイル名が「IMG_0011.JPG」のオリジナル画像ファイル１００に対応するファイル名が「img_0011.JPG」のショートカット画像ファイル１０１が作成される。そして、このショートカット画像ファイル１０１のアドレスタグ１２１には、オリジナル画像ファイル１００が保存されている場所（「http://www.canon.co.jp/original-image/ IMG_0011.JPG」）を示すアドレスタグ１２１が記録されている。このため、ショートカット画像ファイル１０１にアクセス可能なアプリケーション又は画像制御装置は、必要に応じてオリジナル画像ファイル１００の格納場所へアクセスすることが可能である。

次に、上述のようにして作成されたオリジナル画像ファイル１００及びこれに対応するショートカット画像ファイル１０１に対する、図１に示す画像データ処理システムにおける管理の方法の例について説明する。図８は、オリジナル画像ファイルとショートカット画像ファイルとの関係の一例を示す図である。

上述のようにしてサーバ１４０１においてショートカット画像ファイル１０１が作成されると、当該ショートカット画像ファイル１０１は、例えば電子メール等を用いてターミナル１４０６に送信される。この結果、図８に示すように、サーバ１４０１にオリジナル画像ファイル１００が格納され、ターミナル１４０６にショートカット画像ファイル１０１が格納される。ここでは、４種類のオリジナル画像ファイル１００（Ａ、Ｂ、Ｃ、Ｄ）がサーバ１４０１の所定の格納予定場所（「http://www.canon.co.jp/original-image/」）に格納されているとする。また、上記４種類のオリジナル画像ファイル１００に夫々対応するショートカット画像ファイル１０１（ａ、ｂ、ｃ、ｄ）が、ターミナル１４０６の格納場所、例えば「C:\My Pictures\shortcut-image\」で表わされる場所に格納されているとする。

この例の場合、図８に示すように、ファイル名が「IMG_0011.JPG」の「Ｄ」のオリジナル画像ファイル３０１の格納場所が「http://www.canon.co.jp/original-image/」である。このため、「ｄ」のショートカット画像ファイル３０２のアドレスタグ１２１には、「http://www.canon.co.jp/original-image/IMG_0011.JPG」３０３が記録されている。「ａ」、「ｂ」及び「ｃ」のショートカット画像ファイルについても、これに準じたアドレスタグ１２１が記録される。

また、「ｄ」のショートカット画像ファイル３０２は、「Ｄ」のオリジナル画像ファイル３０１から最初に作成されたショートカット画像ファイルであるとする。従って、「ｄ」のショートカット画像ファイル３０２の削除タグ１２２には、「可」３０４が記録されている。「ａ」〜「ｃ」のショートカット画像ファイルについては、当該ショートカット画像ファイルがこれらに対応する「Ａ」〜「Ｃ」のオリジナル画像ファイルから最初に作成されたものであるか否かに応じて「可」又は「否」が記録されている。

このような状態が形成されると、ユーザはターミナル１４０６のＨＤＤ１４０９等に格納されたショートカット画像ファイル３０２のサムネイル画像を参照するだけで、サーバ１４０１に保存されているオリジナル画像ファイル３０１の概要を取得することができる。つまり、ユーザは、ターミナル１４０６をサーバ１４０１に接続せずとも、所望の情報を取得することができる。例えば、ユーザがデジタルカメラ（画像記録装置１４１０）における写真撮影によってオリジナル画像ファイル１００を取得し、オンラインフォトアルバムサービス等を提供するサーバ１４０１に保存したとする。また、サーバ１４０１上においてオリジナル画像ファイル１００からショートカット画像ファイル１０１を作成したとする。このような場合、ユーザは、ターミナル１４０６のＨＤＤ１４０９等に格納されたショートカット画像ファイル１０１のサムネイル画像を参照するだけで、当該オリジナル画像ファイル１００に関する所望の情報を取得することができるのである。

また、ＰＤＡ等の携帯端末ではメモリエリアに制限があるが、このような環境下においても、ショートカット画像ファイル１０１さえ保存しておけば、画像の概要を知ることはできる。また、ユーザが画像の詳細情報の取得を希望する場合には、サーバ１４０１からオリジナル画像ファイル１００を取得すればよい。

また、オリジナル画像ファイル１００の格納場所は限定されない。但し、特にサーバ１４０１にオリジナル画像ファイル１００が格納されている場合には、サーバ１４０１に接続可能なターミナル１４０６からは、ショートカット画像ファイル１０１があれば、オリジナル画像ファイル１００の詳細を取得することが可能である。従って、この場合には、ユーザ間で画像データの授受を行う際にショートカット画像ファイル１０１を利用してもよい。例えば、電子メールを用いて写真画像データを送信しようとする際に、主画像データを含まないショートカット画像ファイル１０１を添付すれば、オリジナル画像ファイル１００自体を添付する場合と比較して電子メールのファイルサイズを小さくすることができる。そして、ショートカット画像ファイル１０１を受け取ったユーザは、希望する場合には、ショートカット画像ファイル１０１からサーバ１４０１にアクセスしてオリジナル画像ファイル１００を取得したり、その詳細情報を取得したりすることができる。

なお、他のユーザとの間で、小さいファイルサイズで画像を授受する方法として、先に述べた特許文献１のように電子メールの指示に従ってオリジナル画像を取得する方法もある。しかしながら、この従来の方法では、その都度、電子メールの指示を参照する必要がある。これに対し、本実施形態によれば、ショートカット画像ファイル１０１にオリジナル画像ファイル１００の格納場所が記録されているため、そのような煩雑な作業が不要となる。

また、本実施形態によれば、電子メール以外の手段でも、ファイルサイズの制限を少なくして、他のユーザとの間で画像データの授受を行うことができる。例えば、メモリカードにショートカット画像ファイル１０１のみを格納し、相手にメモリカードを渡せば、相手はそのメモリカードから任意のオリジナル画像ファイル１００を取得することができる。このため、特許文献１のような電子メール自体が不要となる。

なお、詳細は後述するが、「ｄ」のショートカット画像ファイル１０１の削除タグ１２２のＶａｌｕｅは「可」３０４であるため、ショートカット画像ファイル１０１が削除されると、これに付随して「Ｄ」のオリジナル画像ファイル１００も削除される。

次に、オリジナル画像ファイル１００及びこれに対応するショートカット画像ファイル１０１に対する管理の方法の他の例について説明する。図９は、オリジナル画像ファイルとショートカット画像ファイルとの関係の他の一例を示す図である。図８に示す例では、オリジナル画像ファイル１００及びショートカット画像ファイル１０１が互いに異なるホスト（サーバ１４０１、ターミナル１４０６）に夫々格納されている。これに対し、図９に示す例では、オリジナル画像ファイル１００及びショートカット画像ファイル１０１が、一つのホスト（ターミナル１４０６）内の互いに異なるフォルダ（ディレクトリ）に格納されている。なお、オリジナル画像ファイル１００及びショートカット画像ファイル１０１が、一つのサーバ１４０１内の互いに異なるフォルダに格納されていてもよい。

例えば、ターミナル１４０６にオリジナル画像ファイル１００がユーザにより入力され、ターミナル１４０６においてショートカット画像ファイル１０１が作成され、オリジナル画像ファイル１００とは異なるフォルダに格納されたとする。ここでは、オリジナル画像ファイル１００（Ａ、Ｂ、Ｃ、Ｄ）がフォルダＡに格納され、これらのオリジナル画像ファイル１００に対するショートカット画像ファイル１０１（ａ、ｂ、ｃ、ｄ）が、同じターミナル１４０６内の他のフォルダに格納されているとする。例えば、「ａ」〜「ｄ」のショートカット画像ファイル１０１がフォルダＢに格納され、「ａ」、「ｂ」のショートカット画像ファイル１０１がフォルダＣに格納され、「ａ」、「ｃ」及び「ｄ」のショートカット画像ファイル１０１がフォルダＢに格納されているとする。また、フォルダＡは「C:\My Pictures\original-image\」で表わされ、フォルダＢは「C:\My Pictures\shortcut-image\」で表わされるとする。また、フォルダＣは「C:\My Pictures\子供の写真\」で表わされあり、フォルダＤは「C:\My Pictures\２００３年０１月撮影\」で表わされるとする。

この例の場合、図９に示すように、ファイル名が「IMG_0011.JPG」の「Ｄ」のオリジナル画像ファイル４０１の格納場所が「C:\My Pictures\original-image\」である。このため、「ｄ」のショートカット画像ファイル４０２のアドレスタグ１２１には、「C:\My Pictures\original-image\ IMG_0011.JPG」４０３が記録されている。「ａ」、「ｂ」及び「ｃ」のショートカット画像ファイルについても、これに準じたアドレスタグ１２１が記録される。

また、フォルダＢ内の「ｄ」のショートカット画像ファイル４０２は、「Ｄ」のオリジナル画像ファイル４０１から第２番目以降に作成されたショートカット画像ファイルであるとする。従って、「ｄ」のショートカット画像ファイル４０２の削除タグ１２２には、「否」４０４が記録されている。「ａ」〜「ｃ」のショートカット画像ファイルについては、当該ショートカット画像ファイルがこれらに対応する「Ａ」〜「Ｃ」のオリジナル画像ファイルから最初に作成されたものであるか否かに応じて「可」又は「否」が記録されている。

このような状態が形成されると、ユーザはターミナル１４０６のＨＤＤ１４０９等に格納されたショートカット画像ファイル４０２のサムネイル画像を参照するだけで、他のフォルダＡに格納されているオリジナル画像ファイル４０１の概要を取得することができる。つまり、ユーザは、オリジナル画像ファイル４０１を探し出さずとも、所望の情報を取得することができる。例えば、ユーザがデジタルカメラ（画像記録装置１４１０）における写真撮影によってオリジナル画像ファイル１００を取得し、フォルダＡに保存したとする。また、このオリジナル画像ファイル１００に対応する。ショートカット画像ファイル１０１を他のフォルダに保存したとする。このような場合、ユーザは、常にオリジナル画像ファイル１００を特定のフォルダに一括して保存しておき、撮影時刻及び／又はテーマ等のフォルダごとに整理するときはショートカット画像ファイル１０１を利用することができる。

そして、一つのオリジナル画像ファイル１００に対して複数のショートカット画像ファイル１０１が作成されてもよい。例えば、「Ａ」のオリジナル画像ファイル１００が２００３年１月に作成された画像データを含み、かつ、その被写体に子供が含まれているとする。この場合、ユーザは、画像に子供が写っていることを示すフォルダＣ、及び撮影時刻が２００３年１月を示すフォルダＤの２つのフォルダに、同一の「ａ」のショートカット画像ファイルを含ませることができる。このような分類を行っておけば、２００３年１月に撮影した写真を検索する場合にも、子供が写った写真を検索する場合にも、「Ａ」のオリジナル画像ファイル１００に対応する「ａ」のショートカット画像ファイル１０１にたどり着くことができる。そして、ショートカット画像ファイル１０１のファイルサイズは、主画像データを含ませなければ小さくすることが可能である。このため、複数のカテゴリに同一のオリジナル画像ファイル１００から関連付けられたショートカット画像ファイル１０１が重複していても、ファイルサイズの増加が抑えられる。

なお、詳細は後述するが、フォルダＢ内の「ｄ」のショートカット画像ファイル１０１の削除タグ１２２のＶａｌｕｅは「否」４０４であるため、ショートカット画像ファイル１０１が削除されても、「Ｄ」のオリジナル画像ファイル１００は削除されない。

次に、第１の実施形態におけるオリジナル画像ファイル１００及びショートカット画像ファイル１０１の削除方法について説明する。図１０は、オリジナル画像ファイル１００及びショートカット画像ファイル１０１を削除する方法を示すフローチャートである。ここでは、図１１に示すように、ターミナル１４０６においてアプリケーションＡ及びＢが動作し、サーバ１４０１においてアプリケーションＣが動作することとする。アプリケーションＡは、例えば、ユーザが画像を閲覧したり削除したり印刷指示を出すような画像の制御を行うために使用するアプリケーションである。アプリケーションＢは、例えば、ターミナル１４０６に格納されたショートカット画像ファイルを管理するアプリケーションである。アプリケーションＣは、例えば、サーバ１４０１に格納されたオリジナル画像ファイルを管理するアプリケーションである。

先ず、ユーザの指示により、ショートカット画像ファイル１０１の削除要求が発生する（ステップＳ１２０１）。例えば、ユーザの指示に基づいて、アプリケーションＡがショートカット画像を管理するアプリケーションＢに対してショートカット画像削除要求を行う。

次いで、ＣＰＵ１４０７が、タグ判断手段として、アプリケーションＢに基づいてショートカット画像ファイル１０１の削除タグ１２２を確認する（ステップＳ１２０２）。

ステップＳ１２０２の結果、削除タグ１２２が「可」の場合、ＣＰＵ１４０７は、アプリケーションＢに基づいてオリジナル画像ファイル１００の削除が必要であると判断する。そして、ＣＰＵ１４０７は、アプリケーションＢに基づいて当該ショートカット画像ファイル１０１のアドレスタグ１２１の情報を取得する（ステップＳ１２０３）。この結果、当該ショートカット画像ファイル１０１に対応するオリジナル画像ファイル１００の削除要求の発行が可能となる。

その後、ＣＰＵ１４０７は、削除命令手段として、アプリケーションＢに基づいてステップＳ１２０３において取得したアドレス情報を参照してオリジナル画像ファイル１００の削除要求を発行する（ステップＳ１２０４）。例えば、ショートカット画像ファイル１０１を管理するアプリケーションＢがオリジナル画像ファイルを管理するアプリケーションＣに対してオリジナル画像削除要求を行う。

続いて、ＣＰＵ１４０２が、アプリケーションＣに基づいてオリジナル画像削除要求の対象となっているオリジナル画像ファイル１００を削除できるかどうかを判断する（ステップＳ１２０５）。例えば、他のターミナル等からアプリケーションＣを用いて当該オリジナル画像ファイル１００が使用されている場合には、これを削除することができないと判断される。

そして、ステップＳ１２０５の結果、削除が可能であれば、ＣＰＵ１４０２は、アプリケーションＣに基づいてオリジナル画像ファイル１００を削除する（ステップＳ１２０６）。

その後、ＣＰＵ１４０２は、アプリケーションＣに基づいてオリジナル画像削除要求への応答をアプリケーションＢに返却する（ステップＳ１２０７）。この応答には、オリジナル画像ファイル１００の削除が実行されたか否かの情報、及び削除されなかった場合の理由等が含まれる。削除されなかった場合には、例えば「オリジナル画像ファイルの削除に失敗した」旨の情報が含まれる。

一方、ステップＳ１２０２の結果、削除タグ１２２が「否」の場合、ＣＰＵ１４０７は、アプリケーションＢに基づいてオリジナル画像ファイル１００の削除が不要であると判断する。そして、ＣＰＵ１４０７は、アプリケーションＢに基づいてショートカット画像ファイル１０１を削除できるかどうかを判断する（ステップＳ１２０８）。このステップＳ１２０８の処理は、ステップＳ１２０７の後にも行われる。例えば、ターミナル１４０６内の他のアプリケーションによっても当該ショートカット画像ファイル１０１が使用されている場合には、これを削除することができないと判断される。

そして、ステップＳ１２０５の結果、削除が可能であれば、ＣＰＵ１４０７は、アプリケーションＢに基づいてショートカット画像ファイル１０１を削除する（ステップＳ１２０９）。

その後、ＣＰＵ１４０７は、アプリケーションＢに基づいてショートカット画像削除要求への応答をアプリケーションＡに返却する（ステップＳ１２１０）。この応答には、ショートカット画像ファイル１０１の削除が実行されたか否かの情報、及び削除されなかった場合の理由等が含まれる。

このように、本実施形態では、削除タグ１２２からオリジナル画像ファイル１００の削除の必要性を判断することが可能であり、必要な場合には、アドレスタグ１２１からオリジナル画像ファイル１００の格納場所を取得して削除することができる。

なお、オリジナル画像削除応答の結果が「失敗」の場合、ステップＳ１２０８及びＳ１２０９の処理を省略してもよい。この場合、ステップＳ１２１０のショートカット画像削除応答の際に、オリジナル画像ファイル１００の削除の失敗に伴ってショートカット画像ファイルの削除を省略した旨の情報を応答に含ませることが好ましい。このような情報を応答に含ませることにより、後に、ユーザに通知することが可能となるからである。

オリジナル画像ファイル１００の削除の失敗の原因としては、上記のような既に使用状態となっていることの他に、アプリケーションＢとアプリケーションＣとの間の通信の不具合が挙げられる。また、オリジナル画像ファイル１００が所定の格納場所に存在しないことも原因の一つとして挙げられる。更に、何らかの理由によりアドレスの示す領域にアクセスできないことも原因の一つとしてあげられる。

また、オリジナル画像ファイル１００に、その格納場所を示すアドレスタグが存在していてもよい。このような構成は、サーバ及びターミナル（クライアント）の両方にオリジナル画像ファイルが存在する場合に有効である。例えば、クライアントから印刷を行う場合に、クライアントの持つアドレスタグの情報からサーバにアクセスし、サーバ側でオリジナル画像が変更されていないかという確認を行うことによって、クライアントに印刷を許可するような構成を採用する場合に有効である。ここで、オリジナル画像が変更されていないかという確認に代えて、正式なクライアントとしての認証を行ってもよい。このような構成では、クライアントにショートカット画像ファイルが格納されている場合、確認又は認証の後にオリジナル画像ファイルを読み込む必要があるが、クライアントにオリジナル画像ファイルが格納されていれば、読み込みのためのダウンロードが不要となる。つまり、確認又は認証の後に、オリジナル画像ファイルのダウンロードを行わずともクライアントに格納されているオリジナル画像ファイルを用いて印刷を行うことができる。このため、ダウンロードに必要な時間が省略され、印刷にかかる時間が短縮される。

ここで、「ｄ」のショートカット画像ファイル１０１がターミナル１４０６に格納され、「Ｄ」のオリジナル画像ファイル１００がサーバ１４０１に格納されている場合の具体的な削除処理について説明する。

先ず、「ｄ」のショートカット画像ファイル１０１の削除タグ１２２が「否」である場合の処理について説明する。図１２は、削除タグ１２２が「否」である場合の処理を示す図である。特に、図１２（ａ）は、各アプリケーション間の要求を示す模式図であり、図１２（ｂ）は、削除手順インタフェースを示す応答図である。

図１２（ａ）及び（ｂ）に示すように、ステップＳ１２０１において、アプリケーションＡがアプリケーションＢに対し、その管理下にある「ｄ」のショートカット画像ファイル１０１の削除の要求１００３を行う。

この要求を受けたアプリケーションＢは、ステップＳ１２０２において、「ｄ」のショートカット画像ファイル１０１の削除タグ１２２を確認する。この例では、削除タグ１２２が「否」であるため、ステップＳ１２０２に続いて、アプリケーションＢは、ステップＳ１２０８の処理を行う。即ち、アプリケーションＢは、「ｄ」のショートカット画像ファイル１０１を削除してよいかどうかの判定１００４を行う。例えば、ターミナル１４０６内の他のアプリケーションによっても「ｄ」のショートカット画像ファイル１０１が使用されている場合、削除することができないと判断される。

そして、アプリケーションＢは、判定の結果、削除可能ならば、「ｄ」のショートカット画像ファイル１０１を削除する。その後、アプリケーションＢは、ショートカット画像削除応答１００５で、アプリケーションＡに対して「ｄ」のショートカット画像ファイル１０１の削除の可否及び不可の場合の理由等を通知する。

なお、この例では、ステップＳ１２０３〜Ｓ１２０７の処理が行われないため、サーバ１４０１内での処理は生じず、オリジナル画像ファイル１００への影響はない。

次に、「ｄ」のショートカット画像ファイル１０１の削除タグ１２２が「可」である場合の処理について説明する。図１３は、削除タグ１２２が「可」である場合の処理を示す図である。特に、図１３（ａ）は、各アプリケーション間の要求を示す模式図であり、図１３（ｂ）は、削除手順インタフェースを示す応答図である。

図１３（ａ）及び（ｂ）に示すように、ステップＳ１２０１において、アプリケーションＡがアプリケーションＢに対し、その管理下にある「ｄ」のショートカット画像ファイル１０１の削除の要求１１０３を行う。

この要求を受けたアプリケーションＢは、ステップＳ１２０２において、「ｄ」のショートカット画像ファイル１０１の削除タグ１２２を確認する。この例では、削除タグ１２２が「可」であるため、ステップＳ１２０２に続いて、アプリケーションＢは、ステップＳ１２０３の処理を行う。即ち、アプリケーションＢは、「ｄ」のショートカット画像ファイル１０１のアドレスタグ１２１の情報を取得し、その後、これを用いてオリジナル画像削除要求１１０４をアプリケーションＣに発行する（ステップＳ１２０４）。

次いで、アプリケーションＣは、「ｄ」のオリジナル画像ファイル１００を削除してよいかどうかの判定１１０５を行う（ステップＳ１２０５）。例えば、他のターミナル等からアプリケーションＣを用いて「Ｄ」のオリジナル画像ファイル１００が使用されている場合、削除することができないと判断される。

そして、アプリケーションＣは、判定１１０５の結果、削除可能ならば、「Ｄ」のオリジナル画像ファイル１００を削除する。その後、アプリケーションＣは、オリジナル画像削除応答１１０６で、アプリケーションＢに対して「Ｄ」のオリジナル画像ファイル１００の削除の可否及び不可の場合の理由等を通知する。

次いで、アプリケーションＢは、「ｄ」のショートカット画像ファイル１０１を削除してよいかどうかの判定１１０７を行う。

そして、アプリケーションＢは、判定の結果、削除可能ならば、「ｄ」のショートカット画像ファイル１０１を削除する。その後、アプリケーションＢは、ショートカット画像削除応答１１０８で、アプリケーションＡに対して「ｄ」のショートカット画像ファイル１０１の削除の可否及び不可の場合の理由等を通知する。

なお、削除の命令を受けたショートカット画像ファイルに削除タグが付されていない場合には、そのままオリジナル画像ファイルを削除することとしてもよい。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。第１の実施形態では、一つのオリジナル画像ファイル１００に対して一つのショートカット画像ファイル１０１のみに「可」の削除タグ１２２が付与される。これに対し、第２の実施形態では、一つのオリジナル画像ファイル１００に対して複数のショートカット画像ファイル１０１に「可」の削除タグ１２２が付与され得る構成となっている。以下、第１の実施形態と相違する点を中心にして説明する。先ず、第２の実施形態における削除タグ１２２を作成する方法について説明する。図１４は、削除タグ１２２を作成する方法を示すフローチャートである。

先ず、ＣＰＵ１４０２は、削除タグ１２２を付与しようとしているショートカット画像ファイル１０１が、削除タグ１２２のＶａｌｕｅを「可」とすべきものであるか判別する（ステップＳ１３０３）。この判別に当たり、ＣＰＵ１４０２はユーザに入力を求めてもよく、また、第１の実施形態と同様に、最初のショートカット画像ファイル１０１であるかという基準を用いてもよい。

そして、ステップＳ１３０３の結果、「可」とすべきものであれば、ＣＰＵ１４０２は、削除情報（文字列Ｂ）８０２を「可」に決定する（ステップＳ１３０５）。

次いで、ＣＰＵ１４０２は、当該オリジナル画像ファイル１００作成したショートカット画像ファイル１０１のうち、削除情報（文字列Ｂ）８０２を「可」と決定したものの数を記録する（ステップＳ１３０６）。

一方、ステップＳ１３０３の結果、「可」とすべきものでなければ、ＣＰＵ１４０２は、削除情報（文字列Ｂ）８０２を「否」に決定する（ステップＳ１３０４）。

ステップＳ８０４又はＳ８０５の後、ＣＰＵ１４０２は、第１の実施形態と同様の処理を行う。

次に、第２の実施形態におけるオリジナル画像ファイル１００及びショートカット画像ファイル１０１の削除方法について説明する。ここでは、ステップＳ１２０２の内容が第１の実施形態と相違する。

本実施形態のステップＳ１２０２では、ＣＰＵ１４０７が、削除タグ１２２が「可」であり、かつ、当該オリジナル画像ファイル１００に関してその時点で「可」の削除タグ１２２が付されているショートカット画像ファイル１０１の数が１個であるか判断する。つまり、ＣＰＵ１４０７がタグ解析ステップとして削除タグ１２２が示す情報を解析し、所定の条件を満たすショートカット画像ファイル１０１の数が１こであるか判断する。そして、これらの条件が満たされた場合に限り、ＣＰＵ１４０７は、アプリケーションＢに基づいてオリジナル画像ファイル１００の削除が必要であると判断する。

一方、ＣＰＵ１４０７は、削除タグ１２２が「否」であれば、第１の実施形態と同様に、そのままステップＳ１２０８〜Ｓ１２１０の処理を行う。また、削除タグ１２２が「可」であり、かつ、「可」の削除タグ１２２が付されているショートカット画像ファイル１０１の数が２個以上の場合には、ＣＰＵ１４０７は、削除タグ１２２を「否」に変更する。この結果、「可」の削除タグ１２２が付されているショートカット画像ファイル１０１の数が１個減る。そして、ＣＰＵ１４０７は、オリジナル画像削除要求１１０４を発行することなく、ステップＳ１２０８〜Ｓ１２１０の処理を行う。つまり、ＣＰＵ１４０７は、当該ショートカット画像ファイル１０１を削除してよいかどうかの判定１１０７及びショートカット画像削除応答１１０８の発行を行う。

他の構成は第１の実施形態と同様である。

このような第２の実施形態では、オリジナル画像ファイル１００の削除の権限が複数のショートカット画像ファイル１０１に付与されるが、全てのショートカット画像ファイル１０１を介して削除要求があった場合に限りオリジナル画像ファイル１００が削除される。従って、「可」の削除タグ１２２が付与されたショートカット画像ファイル１０１を保持しているにも拘わらず、知らない間にオリジナル画像ファイル１００が削除されていたという不都合を回避することができる。

なお、「可」の削除タグ１２２が付与されたショートカット画像ファイル１０１の数は、例えばアプリケーションＢにより管理されるが、アプリケーションＣが管理してもよい。アプリケーションＣが管理している場合には、ステップＳ１２０２の判断の際にＣＰＵ１４０７がサーバ１４０１にアクセスして、その数を取得すればよい。このような場合には、複数のユーザがアプリケーションＢを使用する場合でも、容易に処理することができる。

例えば、アプリケーションＢが５個のターミナルに個別にインストールされていて、いずれにも同一のオリジナル画像ファイルから作成されたショートカット画像ファイルが格納されているとする。そして、５個のターミナルのうちの１個においてオリジナル画像削除要求が生じたとする。このような場合、他のターミナルの起動状態に拘わらず、サーバ１４０１において、「可」の削除タグが付与されたショートカット画像ファイルの数が５個から４個に減らされる。「可」の削除タグ１２２が付与されたショートカット画像ファイル１０１の数はサーバ１４０１により管理されるからである。従って、容易な処理が可能となる。また、その後に、他のターミナルにおいてオリジナル画像削除要求が生じると、サーバ１４０１において、「可」の削除タグが付与されたショートカット画像ファイルの数が４個から３個に減らされる。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。第３の実施形態は、第２の実施形態とオリジナル画像ファイル１００及びショートカット画像ファイル１０１の削除方法が相違している。ここでは、ステップＳ１２０２の内容が第１の実施形態と同一であるが、ステップＳ１０５の内容が第１の実施形態と相違している。

即ち、本実施形態のステップＳ１２０５では、ＣＰＵ１４０２が、当該オリジナル画像ファイル１００に関してその時点で「可」の削除タグ１２２が付されているショートカット画像ファイル１０１の数が１個であるか判断する。そして、このようなショートカット画像ファイル１０１の数が１個である場合に限り、ＣＰＵ１４０２は、アプリケーションＣに基づいてオリジナル画像ファイル１００の削除が必要であると判断する。

一方、ＣＰＵ１４０２は、「可」の削除タグ１２２が付されているショートカット画像ファイル１０１の数が２個以上の場合には、「可」の削除タグ１２２が付されているショートカット画像ファイル１０１の数を１個減らし、ステップＳ１２０７の処理を行う。つまり、ＣＰＵ１４０２は、オリジナル画像削除応答１１０６の発行を行う。

他の構成は第１の実施形態と同様である。

このような第３の実施形態でも、オリジナル画像ファイル１００の削除の権限が複数のショートカット画像ファイル１０１に付与されるが、全てのショートカット画像ファイル１０１を介して削除要求があった場合に限りオリジナル画像ファイル１００が削除される。従って、「可」の削除タグ１２２が付与されたショートカット画像ファイル１０１を保持しているにも拘わらず、知らない間にオリジナル画像ファイル１００が削除されていたという不都合を回避することができる。

なお、「可」の削除タグ１２２が付与されたショートカット画像ファイル１０１の数は、例えばアプリケーションＣにより管理される。

なお、いずれの実施形態においても、オリジナル画像ファイル１００の削除に先立ち、ユーザに削除の確認を行うことが好ましい。例えば、アプリケーションＢにおいて、オリジナル画像削除要求１１０４を発行する際に、「本当にオリジナル画像ファイルを削除してもよいですか？」等のダイアログを表示し、外部のユーザに「はい」又は「いいえ」を選択させる。そして、ユーザが許可した場合に限り、オリジナル画像削除要求１１０４を発行する。また、次のような処理を行ってもよい。即ち、アプリケーションＣにおいて、オリジナル画像ファイル１００を削除してよいかどうかの判定１１０５の際に、「本当にオリジナル画像ファイルを削除してもよいですか？」等のダイアログをアプリケーションＢを介して表示する。そして、ユーザに「はい」又は「いいえ」を選択させ、この結果をアプリケーションＢを介して取得する。そして、ユーザが同意した場合に限り、オリジナル画像ファイル１００を削除する。

このような処理を行うことにより、誤った操作に伴うオリジナル画像ファイル１００の削除を抑制することができる。

但し、このような処理を行うと、ユーザがオリジナル画像ファイル１００の削除を拒否した場合に、オリジナル画像ファイル１００が削除されずに、「可」の削除タグ１２２が付与されたショートカット画像ファイル１０１が削除されることがある。つまり、オリジナル画像ファイル１００とショートカット画像ファイル１０１との対応がとれなくなる可能性がある。そこで、アプリケーションＡ又はＢに、ショートカット画像ファイルから独立してオリジナル画像ファイルを削除する機能を設けておいてもよい。また、ユーザがオリジナル画像ファイル１００の削除を拒否した場合には、このオリジナル画像ファイル１００から作成されたショートカット画像ファイル１０１の削除を省略してもよい。

また、オリジナル画像ファイル１００が削除されると、「否」の削除タグ１２２が付与されたショートカット画像ファイル１０１が、これに関連するオリジナル画像ファイル１００が存在しないにも拘らず、そのまま残存することもあり得る。このような場合、当該ショートカット画像ファイル１０１からオリジナル画像ファイル１００を使用としても、それは不可能である。このため、ターミナル１４０６とサーバ１４０１の接続時に、アプリケーションＢを用いて管理されているショートカット画像ファイル１０１とアプリケーションＣを用いて管理されているオリジナル画像ファイル１００との整合性の確認を行うことが好ましい。そして、この確認の結果、「否」の削除タグ１２２が付与されたショートカット画像ファイル１０１のうちで、それに該当するオリジナル画像ファイル１００が存在しないものがあれば、当該ショートカット画像ファイル１０１を削除してもよい。また、削除せずとも、アプリケーションＢを介してオリジナル画像ファイル１００が存在しない旨をユーザに通知し、その後の削除等の処理をユーザに委ねてもよい。

なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記の印刷処理用のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。

本発明の第１の実施形態に係る画像ファイル管理方法の実行に用いられる画像ファイル管理システムを示す図である。 オリジナル画像ファイル（派生元画像ファイル）及びショートカット画像ファイルのフォーマットを示す模式図である。 アドレスタグ１２１のデータ構成を示す図である。 削除タグ１２２のデータ構成を示す図である。 ショートカット画像ファイル１０１を作成する方法を示すフローチャートである。 アドレスタグ１２１を作成する方法を示すフローチャートである。 第１の実施形態において削除タグ１２２を作成する方法を示すフローチャートである。 オリジナル画像ファイルとショートカット画像ファイルとの関係の一例を示す図である。 オリジナル画像ファイルとショートカット画像ファイルとの関係の他の一例を示す図である。 オリジナル画像ファイル１００及びショートカット画像ファイル１０１を削除する方法を示すフローチャートである。 サーバ１４０１及びターミナル１４０６とアプリケーションＡ〜Ｃとの関係を示す図である。 削除タグ１２２が「否」である場合の処理を示す図である。 削除タグ１２２が「可」である場合の処理を示す図である。 第２の実施形態において削除タグ１２２を作成する方法を示すフローチャートである。

符号の説明

１００：オリジナル画像ファイル
１０１：ショートカット画像ファイル
１０２：ＳＯＩ
１０３：ＡＰＰ１
１０４：ＤＣＦ基本主画像データ
１０５：ＥＯＩ
１０６：サムネイル画像データ
１０７：ＡＰＰ１
１０８：ＤＣＦ基本サムネイル画像データ
１１３：ＡＰＰ１
１１４：ヌル（ＮＵＬＬ）データ
１１６：サムネイル画像データ
１１７：ＡＰＰ１
１１８：ＤＣＦ基本サムネイル画像データ
１２１：アドレスタグ
１２２：削除タグ

Claims (13)

1. コンピュータに、
   画像ファイルの削除の命令を受けた場合に、当該画像ファイルに派生元となる派生元画像ファイルの削除に関する情報を示す削除タグが存在するか判断するタグ判断ステップと、
   前記削除タグが存在し、かつ当該削除タグが前記派生元画像ファイルの削除を肯定している場合に、前記派生元画像ファイルの削除を命令する削除命令ステップと、
   を実行させることを特徴とするプログラム。
2. 前記削除命令ステップにおいて、前記削除タグが存在しない場合にも、前記派生元画像ファイルの削除を命令することを特徴とする請求項１に記載のプログラム。
3. 前記削除命令ステップは、前記派生元画像ファイルの削除を命令する前に、前記派生元画像ファイルの削除を外部に確認する確認ステップを有し、前記派生元画像ファイルの削除の許可を受けた場合に、前記派生元画像ファイルの削除を命令することを特徴とする請求項１又は２に記載のプログラム。
4. 前記タグ判断ステップは、前記派生元画像ファイルの削除を命令する前に、前記派生元画像ファイルから派生した画像ファイルが他にも存在する場合に、当該他の画像ファイルに付された削除タグが示す情報を解析するタグ解析ステップを有し、
   前記削除命令ステップにおいて、前記派生元画像ファイルの削除が認められる状態となっている場合に、前記派生元画像ファイルの削除を命令することを特徴とする請求項１乃至３のいずれか１項に記載のプログラム。
5. 前記派生元画像ファイルに含まれる画像データの解像度は、前記画像ファイルの解像度よりも高いことを特徴とする請求項１乃至４のいずれか１項に記載のプログラム。
6. 前記画像ファイルには、前記派生元画像ファイルの格納場所を示す情報が含まれていることを特徴とする請求項１乃至５のいずれか１項に記載のプログラム。
7. コンピュータに、
   第１の画像データを含む派生元画像ファイルから、前記第１の画像データよりも解像度が低い第２の画像データを取得する取得ステップと、
   前記派生元画像ファイルの削除に関する情報を示す削除タグを作成するタグ作成ステップと、
   前記第２の画像データ及び前記削除タグを含む画像ファイルを作成するファイル作成ステップと、
   を実行させることを特徴とするプログラム。
8. 前記画像ファイルに、前記派生元画像ファイルの格納場所を示す情報を含ませることを特徴とする請求項７に記載のプログラム。
9. 前記派生元画像ファイルと前記画像ファイルとを互いに異なる場所に格納することを特徴とする請求項７又は８に記載のプログラム。
10. 画像ファイルの削除の命令を受けた場合に、当該画像ファイルに派生元となる派生元画像ファイルの削除に関する情報を示す削除タグが存在するか判断するタグ判断手段と、
    前記削除タグが存在し、かつ当該削除タグが前記派生元画像ファイルの削除を肯定している場合に、前記派生元画像ファイルの削除を命令する削除命令手段と、
    を有することを特徴とする画像ファイル管理装置。
11. 第１の画像データを含む派生元画像ファイルから、前記第１の画像データよりも解像度が低い第２の画像データを取得する取得手段と、
    前記派生元画像ファイルの削除に関する情報を示す削除タグを作成するタグ作成手段と、
    前記第２の画像データ及び前記削除タグを含む画像ファイルを作成するファイル作成手段と、
    を有することを特徴とする画像ファイル管理装置。
12. 画像ファイルの削除の命令を受けた場合に、当該画像ファイルに派生元となる派生元画像ファイルの削除に関する情報を示す削除タグが存在するか判断するタグ判断ステップと、
    前記削除タグが存在し、かつ当該削除タグが前記派生元画像ファイルの削除を肯定している場合に、前記派生元画像ファイルの削除を命令する削除命令ステップと、
    を有することを特徴とする画像ファイル管理方法。
13. 第１の画像データを含む派生元画像ファイルから、前記第１の画像データよりも解像度が低い第２の画像データを取得する取得ステップと、
    前記派生元画像ファイルの削除に関する情報を示す削除タグを作成するタグ作成ステップと、
    前記第２の画像データ及び前記削除タグを含む画像ファイルを作成するファイル作成ステップと、
    を有することを特徴とする画像ファイル管理方法。

Images