(57)【要約】【課題】コンテンツファイル群を別のソフトウェアでも利用できる形態を残した上で、意図しないコンテンツファイルの移動を検出可能とする。【解決手段】コピーされたコンテンツファイル群１０２〜１０５に基づいて、コンテンツファイル群の論理構造１０７を管理するためのコンテンツリストファイル１０１を作成し、コンテンツリストファイル１０１上の登録情報に基づいて、各コンテンツファイル１０２〜１０５の移動を検出する。【選択図】  図１
2005010950.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツファイル群を記録媒体内にコピーするコピー手段と、
コピーされた前記コンテンツファイル群に基づいて、前記コンテンツファイル群の論理構造を管理するためのコンテンツリストファイルを作成するコンテンツリストファイル作成手段と、
前記コンテンツリストファイル上の登録情報に基づいて、前記各コンテンツファイルの移動を検出する移動検出手段とを有することを特徴とするファイル管理装置。
【請求項２】
前記コンテンツリストファイルは、前記各コンテンツファイルの前記記録媒体内における当初の記録位置を示す情報を含み、前記移動検出手段は、前記記録媒体内におけるそれらの記録位置をチェックすることにより、前記各コンテンツファイルの移動を検出することを特徴とする請求項１に記載のファイル管理装置。
【請求項３】
前記移動検出手段によりコンテンツファイルの移動が検出された場合、移動が検出されたコンテンツファイルを前記記録媒体内から検索する検索手段を更に有することを特徴とする請求項１又は２に記載のファイル管理装置。
【請求項４】
前記検索手段は、前記コンテンツリストファイル上の登録情報に基づいて、前記移動検出手段によって移動が検出されたコンテンツファイルを前記記録媒体内から検索することを特徴とする請求項３に記載のファイル管理装置。
【請求項５】
前記コンテンツリストファイルは、前記各コンテンツファイルの第１の識別情報を含み、前記検索手段は、それらの第１の識別情報に該当するコンテンツファイルを前記記録媒体内から検索することを特徴とする請求項４に記載のファイル管理装置。
【請求項６】
前記コンテンツリストファイル内の登録情報に基づいて、前記各コンテンツファイルに対して第２の識別情報を付与する識別情報付与手段と、
前記各コンテンツファイルの第２の識別情報と、前記コンテンツリストファイル内の登録情報とを比較することにより、前記検索手段により検索されたコンテンツファイルの正当性を確認する確認手段とを更に有することを特徴とする請求項３〜５の何れか１項に記載のファイル管理装置。
【請求項７】
前記各コンテンツファイルに第２の識別情報を付与する識別情報付与手段と、
前記識別情報付与手段により第２の識別情報が付与された時刻を示す時刻情報を前記各コンテンツファイルに対して夫々付与する時刻情報付与手段と、
前記コンテンツリストファイルに対して前記時刻情報を登録する時刻情報登録手段とを更に有し、
前記検索手段は、前記コンテンツリストファイル内の前記時刻情報と同じ時刻情報が付与されたコンテンツファイルを前記記録媒体内から検索することを特徴とする請求項３〜５の何れか１項に記載のファイル管理装置。
【請求項８】
前記検索手段により検索されたコンテンツファイルの正当性を確認する確認手段を更に有し、
前記識別情報付与手段は、前記コンテンツリストファイル内の登録情報に基づいて前記コンテンツファイル毎に第２の識別情報を付与し、前記確認手段は、前記各コンテンツファイルの第２の識別情報と、前記コンテンツリストファイル内の登録情報とを比較することにより、前記検索手段により検索されたコンテンツファイルの正当性を確認することを特徴とする請求項７に記載のファイル管理装置。
【請求項９】
前記確認手段により正当性が確認されたコンテンツファイルに対して、前記コンテンツリストファイル内におけにおける論理構造の管理内容との整合性をとる処理手段を更に有することを特徴とする請求項６又は８に記載のファイル管理装置。
【請求項１０】
前記記録媒体は、ストレージメディアであることを特徴とする請求項１〜９の何れか１項に記載のファイル管理装置。
【請求項１１】
前記ストレージメディアは、磁気ディスクであることを特徴とする請求項１０に記載のファイル管理装置。
【請求項１２】
請求項ストレージメディアは、半導体メモリであることを特徴とする請求項１０に記載のファイル管理装置。
【請求項１３】
記録媒体にコピーされたコンテンツファイル群の論理構造を情報処理装置において管理するためのファイル管理方法であって、
コンテンツリストファイル作成手段が、コピーされた前記コンテンツファイル群に基づいて、前記コンテンツファイル群の論理構造を管理するためのコンテンツリストファイルを作成し、
移動検出手段が、前記コンテンツリストファイル上の登録情報に基づいて、前記各コンテンツファイルの移動を検出することを特徴とするファイル管理方法。
【請求項１４】
請求項１３に記載のファイル管理方法をコンピュータに実行させるためのプログラム。
【請求項１５】
請求項１４に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、記録媒体にコピーされたコンテンツファイル群の論理構造を情報処理装置において管理するためのファイル管理装置、ファイル管理方法、プログラム及び記録媒体に関するものである。
【０００２】
【従来の技術】
従来、図１１に示すように、デジタルカメラに代表される撮像装置１１０において、撮影した画像データや音声データ等のデータ群（以下、画像ファイル、音声ファイル、動画ファイルなどいわゆるマルチメディアコンテンツファイル全般を「コンテンツファイル」と称す）は一般に、装置内の取り外し可能な記憶メディア１１２に、ある特定のファイル管理方法により特定のフォーマットで記録される。
【０００３】
デジタルカメラにおける画像ファイルは一般にＥｘｉｆ、Ｔｉｆｆといった規格で定められる画像フォーマットで、圧縮される場合はＪＰＥＧと言われる規格で行われることが多い。またリムーバブルメディアへの記録は、一般に、ＤＣＦ（Ｄｅｓｉｇｎ  ｒｕｌｅ  ｆｏｒ  Ｃａｍｅｒａ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）で定める構造で行われることが多い。
【０００４】
ＤＣＦ規格においては、パソコンで多く使われているＤＯＳ  ＦＡＴファイルシステムを採用した上で、図１２に示されるように、そのルートディレクトリ１２０１の直下にＤＣＩＭという名称のディレクトリ１２０２が存在し、その下に各サブディレクトリが配置される。各サブディレクトリの名称は８文字で構成され、その最初の３文字は１００から９９９までの番号で構成され、残りの５文字はＤＣＦ規格の範囲内で自由な文字をつけられている。この例ではこの命名規則に従い、１２０３、１２０４で表されるディレクトリ名称となっている。その各サブディレクトリ内に画像ファイルが含まれる。画像ファイルの名称規則としては８文字で構成されるファイル名の前半４文字はＤＣＦ規格の範囲内で自由な文字列が、後半４文字には０００１から９９９９までの通し番号が付けられる。この例ではこの命名規則に従い、１２０５、１２０６、１２０７、１２０８で表される画像ファイル名称となっている。また、画像ファイル以外の音声、動画などのコンテンツファイルはＤＣＦ規格で規定する画像ファイルとは見なされないが、同一のサブディレクトリに配置することは許されている。
【０００５】
また、記録される画像ファイルは一般に図１３のような構造をもつ。フォーマット全体は１３０１で表しているＳＯＩで開始、１３０２で表すＥＯＩで終了しており、その内部は１３０８、１３０９で表す画像圧縮データとその関連テーブル等だけではなく、１３０３で表す付属情報記録部内に様々なデータがメタデータとして記録できることが多い。たとえば、１３０４のようなマーカ、識別コード、ヘッダ以外にも、１３０５で示すメーカ、ユーザの独自情報が記録できる部分、あるいは１３０６で示すような日時記録部、１３０７で示すようなサムネイル画像を記録することも可能な場合が多い。
【０００６】
上記を一例とするように、記録されたコンテンツ群は、図１１における取り外し可能な記憶メディア１１２そのものを介して、あるいはデジタルカメラ等からＵＳＢ等のケーブル１１４を介してＰＣ等の処理装置１１１により認識される。認識されたコンテンツ群は一般に処理装置内のストレージ装置１１３にコピーされ、アルバム表示等を行うソフトウェアによって利用することができる。
【０００７】
上記のような利用形態において、ソフトウェアがコンテンツ群を管理する形態にはいくつか考えられる。代表的なものとしては以下の２形態が挙げられるであろう。
（１）一つは、コピーの際にコンテンツ群をソフトウェア内に取り込み、ソフトウェア独自の管理方法によって管理する方法である。この場合は元のコンテンツ群はソフトウェア独自の管理データと統合され、一般には一つのコンテンツファイルとして管理される。
【０００８】
（２）もう一つは、図１２で例示したＤＣＦのようなコンテンツファイル群とそのディレクトリ構造をコピー元として、図１４において例示されるようにコピー先のストレージ内で、図１４中の点線内（１４０７）に示すように、同じあるいは別のディレクトリ構造に配置し、コンテンツファイル群自体には変更を加えず、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍというコンソーシアムなどによって規定されているＨＴＭＬと言われる言語に代表されるハイパーリンク等の方法により、コンテンツ群をソフトウェアの作成するファイル内でリンクを作成し表示を行う方法である。
【０００９】
一般にこのような図１４の例では、ＨＴＭＬファイル１４０１をファイルシステム内あるいはネットワーク上の適切な位置、ここでは同一ファイルシステム内のルートディレクトリに配置し、１４０９で示す、ＤＣＦ構造のディレクトリＤＣＩＭをルート直下のディレクトリとして配置している。このようなＨＴＭＬファイルの内容は、例えば図１５のようになる。この例のようなＨＴＭＬをソフトウェアが作成し、Ｗｅｂブラウザに代表されるアプリケーションがコンテンツファイル群の表示を行うことが一般的である。
【００１０】
【発明が解決しようとする課題】
しかしながら、（１）の方法においては、コンテンツ群はそのソフトウェア独自の方法で一般に一つのファイルにまとめられる。その結果、コンテンツは特定のソフトウェア独自の管理方法においてのみアクセス可能となる。その場合、コンテンツ群の改変や削除などはそのソフトウェアを介して行うことになる。これは、意図しないコンテンツの移動などが起きないというメリットがある一方、そのコンテンツ群を別のソフトウェアで再利用することを難しくしてしまうという欠点を持つ。
【００１１】
また、（２）の方法では、コンテンツ群は他のアプリケーションなどにより別に利用することも可能であるというメリットがある。その一方で、以下のような課題が発生する。
・初心者を代表とするその構造を理解しない利用者が、例えば図１４における１４０３から１４０６への移動のように、本来意図しないコンテンツファイルの移動あるいはファイル名の変更を行った場合、図１５の下線部１５０４に示す部分でのリンク切れにより対象コンテンツを管理できなくなるということがある。
・さらに、ＨＴＭＬは一般にレイアウトと文書構造に関する情報を含むフォーマットであるため、コンテンツ群の論理的な構造、たとえばグルーピングなどを正確に処理プログラムなどで管理することが困難である。たとえば図１５の例では、ＴＡＢＬＥ要素内に、１５０１、１５０２、１５０３で示すように３つのＴＲ要素が含まれている。１５０１、１５０２のＴＲ要素はアルバムのグルーピングと論理的に対応するべきものであり、１５０３は他のアルバムへのリンクボタンを表すものであるが、ＨＴＭＬの構造では３者を同一視してしまい、論理構造を正確に反映できるページを作成し、またアプリケーション等で編集することが難しくなる。
【００１２】
従って、本発明の目的は、コンテンツファイル群を別のソフトウェアでも利用できる形態を残した上で、意図しないコンテンツファイルの移動を検出可能とすることにある。
【００１３】
【課題を解決するための手段】
斯かる目的を達成するために、本発明のファイル管理装置は、コンテンツファイル群を記録媒体内にコピーするコピー手段と、コピーされた前記コンテンツファイル群に基づいて、前記コンテンツファイル群の論理構造を管理するためのコンテンツリストファイルを作成するコンテンツリストファイル作成手段と、前記コンテンツリストファイル上の登録情報に基づいて、前記各コンテンツファイルの移動を検出する移動検出手段とを有することを特徴とする。
【００１４】
また、本発明のファイル管理方法は、記録媒体にコピーされたコンテンツファイル群の論理構造を情報処理装置において管理するためのファイル管理方法であって、コンテンツリストファイル作成手段が、コピーされた前記コンテンツファイル群に基づいて、前記コンテンツファイル群の論理構造を管理するためのコンテンツリストファイルを作成し、移動検出手段が、前記コンテンツリストファイル上の登録情報に基づいて、前記各コンテンツファイルの移動を検出することを特徴とする。
【００１５】
また、本発明のプログラムは、前記ファイル管理方法をコンピュータに実行させることを特徴とする。さらに、本発明のコンピュータ読み取り可能な記録媒体は、前記プログラムを記録したことを特徴とする。
【００１６】
【発明の実施の形態】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
＜第１の実施形態＞
図２は、本発明の第１の実施形態に係るファイル管理装置のシステム構成図である。
２０１はメモリカードなどのカードリーダ部を示す。２０２は図１１における１１３であり、ハードディスクドライブなどのストレージ装置を表す。２０３はモニタなどの表示部を表す。２０４はＵＳＢやＩＥＥＥ１３９４などのインタフェースを表す。２０５は処理部であり、ＣＰＵなどの演算装置を指す。以下に説明する各フローチャートに示す各処理プログラムは、ストレージ部２０２あるいはＲＯＭ２０７に予め記録されており、処理部２０５がその内容を適宜読み出し実行する。各処理プログラムにおける変数はＲＡＭ２０６に格納される。あるいは状況により定数としてＲＯＭ２０７に格納される場合もある。２０９はデータバスを表し、各部間のデータの送受信はこのバスを通じて行われる。
【００１７】
図３は、本実施形態において作成するコンテンツリストファイルを示した図である。
図１の例で示したコンテンツ群を管理するためのファイルとして例示している。コンテンツファイルにはコンテンツ群の論理構造を反映するため、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍで規定されているＸＭＬと呼ばれる言語を使用し、記述している。
【００１８】
図１のように、コンテンツとなる各コンテンツファイル１０２，１０３，１０４，１０５の集合であるコンテンツファイル群を管理するＸＭＬコンテンツリストファイル１０１は、ファイルシステム内あるいはネットワーク上の適切な位置、ここでは同一ファイルシステム内のルートディレクトリに配置し、ＤＣＦ構造のディレクトリＤＣＩＭをルート直下のディレクトリとして配置される状況を例として説明している。
【００１９】
図３では、一行目のＸＭＬ宣言の直下で、コンテンツリスト全体をＣＯＬＬＥＣＴＩＯＮという要素で括っており、そのＣＯＬＬＥＣＴＩＯＮに対応するＩＤが属性として割り当てられている。例えば別のコンテンツリストが存在する場合でも、ＣＯＬＬＥＣＴＩＯＮ毎に一意のＣＯＬＬＥＣＴＩＯＮ＿ＩＤが割り当てられる。
【００２０】
また、ＣＯＬＬＥＣＴＩＯＮの直下には、ディレクトリ構造に対応したグループピングのためのＧＲＯＵＰ要素が存在してもよく、それが、その対応するディレクトリ内に存在する各コンテンツファイルへのリンクを括ることができる。この例では画像ファイルのみを対象としているが、音声、動画ファイルなどを対象としても良い。
【００２１】
ＧＲＯＵＰ要素はＮＡＭＥ属性を持ち、この例ではディレクトリ名をそのＮＡＭＥ属性の値として持っている。ディレクトリ構造に対応したグルーピングというものはあくまでも一例であり、実際はディレクトリ構造にグルーピングが限定される必要はなく、別の自由な名称で様々なディレクトリ下のコンテンツファイル群をグルーピングしても、或いは適当なグルーピングを表すためにＧＲＯＵＰ要素をネストさせても、さらにＧＲＯＵＰ要素を使わずにＣＯＬＬＥＣＴＩＯＮ要素の直下にコンテンツを表す要素を配置しても良い。
【００２２】
実際のコンテンツファイルは、そのコンテンツを表す要素、画像ファイルであれば例えばＩＭＧという名称の要素により対応付けられ、その要素のＳＲＣ属性で実際のファイルの物理パスへの記述がなされている。さらにこの例ではＡＬＴ属性でそのコンテンツに対する説明が記述されており、さらにそのＸＭＬ内（ここではＣＯＬＬＥＣＴＩＯＮ内）で一意となるＩＤ属性が付与されている。この例のような規則に従ったＸＭＬコンテンツリストをアプリケーションソフトウェアが利用し、コンテンツファイル群を管理し表示編集を行う。
【００２３】
図４は、上記のようなコンテンツリストを作成する処理の各ステップを表すフローチャートである。
Ｓ４０１においては、まず、図２におけるカードリーダ部２０１あるいはケーブルＩ／Ｆ部２０４を介し、リムーバブルメディアあるいはケーブル経由でデジタルカメラからストレージ部２０２にコンテンツ群をすべてコピーする。
【００２４】
コピーされたコンテンツ群は、コピー元と同じディレクトリ構造を持つか、新たなディレクトリ構造においてストレージ部に記録される。この例では図１中の点線内（１０７）に示すように、コピー元と同じディレクトリ構造をもつこととする。
【００２５】
Ｓ４０２の処理では、ＸＭＬコンテンツリストを作成するための前処理が行われる。具体的には、図５のＳ５０１で示すように、変数ＣｏｌｌｅｃｔｉｏｎＩＤに、システムが作成するＸＭＬコンテンツリストごとに一意な値を代入する。一意な値には様々な作成方法が考えられるが、ここでは例として、一部のオペレーティングシステムが採用しているＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  ＩＤｅｎｔｉｆｉｅｒ）という形式の、１６バイト数値をハイフンで区切った値の一例、”ＡＡＡＡＡＡＡＡ−００００−１１１１−ＢＢＢＢ−ＡＡＡＡＡＡＡＡＡＡＡＡ”という値を入れる。
【００２６】
Ｓ５０２の処理では、システムの日時を変数ＣｒｅａｔｅＤａｔｅに代入する。ここでは、国際標準ＩＳＯ８６０１に準拠した形式で”２００２−０４−１０−Ｔ１１：２７：０４”という値が入る。
【００２７】
ＸＭＬコンテンツリスト作成のための前処理が終わると、Ｓ４０３において、ＤＣＩＭの直下に存在するディレクトリの数をカウントし、その値を変数ＤｉｒＮｕｍに代入する。（ここではＤＣＦ形式のディレクトリ構造をそのままコピーした例であるのでＤＣＩＭ下のディレクトリはネストされていない。）
【００２８】
次にＳ４０４でカウンタ変数ｉに０を代入し、ＤＣＩＭ直下のディレクトリ名を順に読み出す。最初に読み出したディレクトリ名称をＳ４０５で変数ＤｉｒＮａｍｅ（ｉ）に代入する。
【００２９】
続いて、Ｓ４０６で、ディレクトリＤｉｒＮａｍｅ（ｉ）  のファイル数を読み、その値を変数ＦｉｌｅＮｕｍに代入する。
【００３０】
続いて、Ｓ４０７でカウンタ変数ｊに０を代入し、その後ＤｉｒＮａｍｅ（ｉ）以下のファイル名を順に読み出す。
【００３１】
続いて、Ｓ４０８で変数ＦｉｌｅＮａｍｅ（ｉ，ｊ）にファイル名を代入し、Ｓ４０９でそのファイルの、コンテンツリストＸＭＬファイルが配置される予定の位置、ここではルートディレクトリの位置からのディレクトリパスを読み、それをＰａｔｈＮａｍｅ（ｉ，ｊ）に代入する。たとえば、図１における１０２のファイルをディレクトリ、ファイルを図の表示順に読むとすると、ＦｉｌｅＮａｍｅ（０，０）＝”ＩＭＧ＿０００１．ＪＰＧ”、ＰａｔｈＮａｍｅ（０，０）＝”／ＤＣＩＭ／１００ＡＢＣＤＥ／ＩＭＧ＿０００１．ＪＰＧ”となる。
【００３２】
次にＳ４１０で、コンテンツファイルにメタデータを記述する処理に移る。この処理フローは図６に記載している。
図６のＳ６０１において、現在変数ＰａｔｈＮａｍｅ（ｉ，ｊ）の値が対象となるコンテンツに対して、ＩＤ値をシステムが割り当て、それを変数ＣｏｎｔｅｎｔＩＤ（ｉ，ｊ）に代入する。
【００３３】
次に、Ｓ６０２で該当コンテンツファイルをＲＡＭ２０６に読み込み、Ｓ６０３で、予め定められた該当コンテンツファイルのメタデータ指定場所に変数ＣｏｌｌｅｃｔｉｏｎＩＤと変数ＣｏｎｔｅｎｔＩＤ（ｉ，ｊ）を連結した値を記録する。例えば、そのファイルが図１３のような構造をもつファイルである場合には、メーカ、ユーザ情報記録部１３０５に値を記録、あるいはＥＯＩの部分１３０２の直後に値を記録する。
【００３４】
次にＳ６０４で、必要に応じて該当コンテンツファイル変更日時を記録する部分に、変数ＣｒｅａｔｅＤａｔｅの値を適切に形式変換し記録する。たとえば図１３で説明した形式のファイルであれば、日時記録部１３０６に、そのファイルに応じた形式、たとえば”２００２：０４：１０  １１：２７：０４”のようにＣｒｅａｔｅＤａｔｅの値を変換した上で記録する。
【００３５】
さらに、そのファイルシステムにおける変更日時をコンテンツリストファイル上のＣｒｅａｔｅＤａｔｅの値とする。たとえばＤＣＦで使われているＤＯＳ  ＦＡＴファイルシステムあるいは互換ファイルシステムなど同様の情報を定義できるファイルシステムを使用している場合は、該当コンテンツファイルにおけるＤＯＳ  ＦＡＴシステムでいうところの更新日付／時刻のビットフィールドをＣｒｅａｔｅＤａｔｅの値から適切に変換した上で変更する。例えば、ＤＯＳ  ＦＡＴファイルシステムの場合であれば、更新日付のビットフィールドを”０１０１１０００１０００１０１０”（ＹＹＹＹＹＹＭＭＭＭＤＤＤＤの表記でＹは１９８０年からの相対値）、更新時刻のフィールドを”１０１１０１１０１１００００１０”（ｈｈｈｈｈｍｍｍｍｍｍｓｓｓｓｓで、秒は実際の１／２の値が入る）に変更する。ただし、ファイルシステムにおける作成日付を別の目的で使用するためその処理システムで変更を望まない場合、変更は強要されない。ファイル内のデータが上記に変換されたあとは、そのファイルは上書き保存される。
【００３６】
図４に戻り、Ｓ４１１でカウンタ変数ｊがそのディレクトリ内のファイル数であるＦｉｌｅＮｕｍから１を差し引いた数に達したかどうかの判断が行われる。もしまだ達していない場合はＳ４１３の処理でカウンタ変数ｊに１を追加し、Ｓ４０８の処理に戻る。
【００３７】
ｊ＝ＦｉｌｅＮｕｍ−１の場合、Ｓ４１２の処理で、カウンタ変数ｉがすでにＤＣＩＭ直下のディレクトリ数ＤｉｒＮｕｍから１を引いた数に達したかどうかを確認する。まだ達していない場合はＳ４１４でｉに１を加え、Ｓ４０５の処理に戻る。
【００３８】
ｉがＤｉｒＮｕｍ−１に達した場合、Ｓ４１５でＸＭＬコンテンツリストの書き出しの処理に移る。具体的には、変数ＣｏｌｌｅｃｔｉｏｎＩＤ、ＣｒｅａｔｅＤａｔｅの情報をもとにＣＯＬＬＥＣＴＩＯＮ要素とその属性を作成、ＤｉｒＮａｍｅ（ｉ）の情報をもとにＧＲＯＵＰ要素を作成、ＰａｔｈＮａｍｅ（ｉ，ｊ）、ＣｏｎｔｅｎｔＩＤ（ｉ，ｊ）、ＦｉｌｅＮａｍｅ（ｉ，ｊ）の情報をもとにＩＭＧ要素を作成する。この例では、完成したＸＭＬコンテンツリストは図３の通りとなり、図１におけるルートディレクトリ直下の場所１０１にＣｏｎｔｅｎｔｓ．ｘｍｌというファイル名で保存される。
【００３９】
最終的に、コンテンツ群は、各々のコンテンツファイルに「ＣＯＬＬＥＣＴＩＯＮ＿ＩＤ属性値＋ＩＭＧ要素のＩＤ属性値」がメタデータとして記録されている状態となる。図１の１０２、１０３、１０４、１０５内の枠内にその状態を模式的に描いている。
【００４０】
コピーされたコンテンツファイルは図１１におけるＰＣ等の処理装置１１１内でアプリケーションにより利用されることが可能となる。例えば、ＸＳＬＴに対応した機能を持つアプリケーションが作動している場合には、そのコンテンツファイルを先に作成したＸＭＬコンテンツリストのリンク先の対象として表示などを行うことが可能となる。
【００４１】
次に、上記の手段で作成したコンテンツ群に対し、意図しないコンテンツファイルの移動が発生したかどうかのチェックと、発生した場合の検索処理について説明する。
【００４２】
図７は、ユーザによる意図しないコンテンツファイルの移動が発生したことをチェックする処理を記述したフローチャートである。
まず、Ｓ７０１の処理において、図１における１０１に記録されているＸＭＬコンテンツリストファイルをＲＡＭに読み込む。次に、該当ＸＭＬコンテンツリストファイルにおけるＣＯＬＬＥＣＴＩＯＮ要素のＣＯＬＬＥＣＴＩＯＮ＿ＩＤ属性の値を変数ＣｏｌｌｅｃｔｉｏｎＩＤに代入し、ＣＲＥＡＴＥ＿ＤＡＴＥ属性値を変数ＣｒｅａｔｅＤａｔｅに代入する。
【００４３】
さらに、ＸＭＬコンテンツリストファイル内のＩＭＧ要素を順に読む。Ｓ７０４、Ｓ７０５の処理において、該当ＩＭＧ要素のＳＲＣ属性値を変数ＣｏｎｔｅｎｔＰａｔｈに代入し、該当ＩＭＧ要素のＩＤ属性値を変数ＣｏｎｔｅｎｔＩＤに代入する。
【００４４】
次にＳ７０６の処理において、先に代入したＣｏｎｔｅｎｔＰａｔｈの値のパス上にファイルが実在するかどうかの確認を行う。もし確認された場合は、次に読み出すＩＭＧ要素に対して同様の処理をＳ７０３から行う。ファイルの実在が確認されなかった場合は、ユーザによるファイルの意図しない移動があったものとして、Ｓ７０７でコンテンツファイルの検索処理を行い、それが終了すると同様に次のＩＭＧ要素に対して同様の確認を行う。
【００４５】
図１の例では、ファイル１０３をユーザが誤ってディレクトリＸＸＸ下の１０６の位置に移動してしまった状態を模式的に描いている。このような状態の場合は、この処理内の図３におけるＩＭＧ要素３０１を該当ＩＭＧ要素として確認している時点で、ファイルの実在がコンテンツリストで指定している場所に存在しないことがわかる。
【００４６】
コンテンツファイルの検索処理のフローは図８で示している。
まずＳ８０２の処理において、先に代入した変数ＣｏｎｔｅｎｔＰａｔｈのディレクトリを表すデリミタで区別された最後のストリング文字列を変数ＦｉｌｅＮａｍｅに代入する。例えばＣｏｎｔｅｎｔＰａｔｈの値が”ＤＣＩＭ／１００ＡＡＢＣＤＥ／ＩＭＧ＿０００１．ＪＰＧ”となっている場合はデリミタがスラッシュであり、ＦｉｌｅＮａｍｅ値は”ＩＭＧ＿０００１．ＪＰＧ”となる。
【００４７】
次に、Ｓ８０３の処理で、ＦｉｌｅＮａｍｅがファイル名と同じであるファイルをストレージ全体から検索する。もし検索結果１つ以上のファイルが発見できた場合は（Ｓ８０４）、その各々に関してメタデータの確認が行われる（Ｓ８０５）。
【００４８】
ファイルが見つからなかった場合、あるいはメタデータの確認の結果ファイルが違っていた場合は、Ｓ８０６の処理において、変数ＣｒｅａｔｅＤａｔｅの値をそのファイルシステムの形式に適切に変更した値が、ファイルの変更日時と同じであるファイルを全ストレージ内から検索する。
【００４９】
もし検索結果１つ以上のファイルが発見できた場合は（Ｓ８０７）、その各々に関してメタデータの確認が行われる（Ｓ８０８）。ファイルが見つからなかった場合、あるいはメタデータの確認の結果ファイルが違っていた場合は、Ｓ８０９、Ｓ８１０で、ストレージ内の全ファイルに対し、メタデータの確認が行われる。この結果ファイルが見つからなかった場合は、該当ストレージにファイルがない旨をユーザに表示し、図７のＳ７０８に戻る。
【００５０】
図８におけるＳ８０５、Ｓ８０８、Ｓ８１０での各ファイルメタデータの確認の処理のフローは図９に示している。
まずＳ９０２において検索結果の各コンテンツファイルをＲＡＭに読み出す。次にＳ９０３の処理において、該当コンテンツのメタデータ指定場所に記録されているメタデータの値を、変数ＣｏｌｌｅｃｔｉｏｎＣｏｎｔｅｎｔＩＤに代入する。
【００５１】
Ｓ９０４の処理では、このＣｏｌｌｅｃｔｉｏｎＣｏｎｔｅｎｔＩＤの値が、先にＸＭＬファイルから代入したＣｏｌｌｅｃｔｉｏｎＩＤとＣｏｎｔｅｎｔＩＤを連結したものと同じ値かどうかを確認する。たとえば、ＣｏｌｌｅｃｔｉｏｎＣｏｎｔｅｎｔＩＤの値が”  ＡＡＡＡＡＡＡＡ−００００−１１１１−ＢＢＢＢ−ＡＡＡＡＡＡＡＡＡＡＡＡ  ｃｐａｎｏ００１”という値であり、ＣｏｌｌｅｃｔｉｏｎＩＤの値が”  ＡＡＡＡＡＡＡＡ−００００−１１１１−ＢＢＢＢ−ＡＡＡＡＡＡＡＡＡＡＡＡ”、ＣｏｎｔｅｎｔＩＤの値が”  ｃｐａｎｏ００１”であれば、データがマッチしたと見なされる。
【００５２】
データがマッチした場合、該当ファイルを発見したことになる。その場合はＳ９０６の処理において発見時の処理を行う。これは、例えば、▲１▼コンテンツファイル名、▲２▼そのファイルシステム上の現在の場所、▲３▼ＸＭＬコンテンツリスト上のＳＲＣ属性値での場所、をユーザに表示し、ユーザの選択に応じてコンテンツファイルのファイルシステム上の位置を▲３▼で記述されている位置に移動あるいはコピーする。あるいは逆に、▲３▼の値を▲２▼の位置に変更しても良い。これらの処理は、システムの初期設定により自動実行させてもよい。
【００５３】
図１の１０３から１０６の移動の例では、コンテンツファイル自身を１０６から１０３の位置に戻しても良いし、ＸＭＬコンテンツパス内の該当ＩＭＧ要素のＳＲＣ属性を、ＸＸＸ／ＩＭＧ＿０００２．ＪＰＧといったように現在の位置に変更する処理を施すことも可能である。これはユーザがその都度選択する、あるいはあらかじめ決められた選択肢により自動処理しても良い。発見時処理が終了すると、処理は図７のＳ７０８に戻り、別のＩＭＧ要素に対して同様に確認が行われる。
【００５４】
Ｓ９０４においてデータがマッチしなかった場合は、全ファイルが確認されるまでＳ９０２の処理にもどり、次の検索結果コンテンツファイルの確認が同様に行われる。全ファイルが終了し、データがマッチしたファイルがなかった場合は、図９の処理を呼び出した処理の次の処理に戻る。例えばＳ８０５から呼び出した場合は、Ｓ８０６の処理に戻る。
【００５５】
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。本実施形態におけるファイル管理装置のシステム構成は、図２に示した第１の実施形態に係るファイル管理装置のシステム構成と同様であるため、その説明は省略する。本発明の第２の実施形態としては、コンテンツファイルに埋め込むメタデータとして、ＣＯＬＬＥＣＴＩＯＮ＿ＩＤとＣＯＮＴＥＮＴ＿ＩＤの組み合わせの代わりに、そのファイルが存在するファイルパス自体を利用することも挙げられる。
【００５６】
第１の実施形態において使用したコンテンツリストファイルには、このファイルパスも各ＩＭＧファイルのＳＲＣ属性として記述されているので、この情報を同様にファイルのＩＤとして、Ｓ６０３におけるメタデータ指定場所への記録、Ｓ９０３におけるメタデータ指定場所からの変数代入値、Ｓ９０４におけるメタデータとＩＤのチェックにおいて使用することで、第１の実施形態と同様の効果を得ることが可能である。ファイルパスが埋め込まれた状態を模式的に表したものが図１０である。
【００５７】
上記第１及び第２の実施形態によれば、コンテンツ群を別のソフトウェアでも利用できる形態を残した上で、アルバムの論理構造をハイパーリンクに反映しソフトウェアでの管理を容易にし、かつ意図しないコンテンツファイルの移動などが生じた際に適切に修正を行うことができる。尚、本発明においては、上記実施形態におけるストレージメディアとして、磁気ディスクや半導体メモリを適用することができる。
【００５８】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【００５９】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００６０】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【００６１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６２】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６３】
【発明の効果】
本発明によれば、コンテンツファイル群の論理構造を管理するためのコンテンツリストファイルを作成し、そのコンテンツリストファイル上の登録情報に基づいて各コンテンツファイルの移動の検出可能としたことにより、コンテンツファイル群を別のソフトウェアでも利用できる形態を残した上で、意図しないコンテンツファイルの移動を検出することが可能となる。
【図面の簡単な説明】
【図１】ストレージ上におけるコンテンツ群のファイル管理状態の一例を示した図である。
【図２】本発明の一実施形態にファイル管理装置のシステム構成を示した図である。
【図３】ＸＭＬで作成したコンテンツリストの完成形の一例を示した図である。
【図４】コンテンツリスト作成とコンテンツにメタデータを付与する処理を示したフローチャートである。
【図５】コンテンツリスト作成の前処理を示したフローチャートである。
【図６】コンテンツファイルにメタデータを記述する処理を示したフローチャートである。
【図７】ユーザによる意図しないコンテンツファイルの移動が発生したことをチェックする処理を示したフローチャートである。
【図８】コンテンツファイルの検索処理を示したフローチャートである。
【図９】各ファイルメタデータの確認の処理を示したフローチャートである。
【図１０】ストレージ上におけるコンテンツ群のファイル管理の状態において、ファイルパスをＩＤとして埋め込んでいる例を示した図である。
【図１１】デジタルカメラ、ＰＣなどの処理装置、メディア、ケーブルなどの接続構成を模式的に示した図である。
【図１２】デジタルカメラの記録フォーマット構造を模式的に示した図である。
【図１３】画像ファイルなどのコンテンツ記録フォーマットを模式的に示した図である。
【図１４】画像ファイル群をＨＴＭＬで管理している構造を模式的に示した図である。
【図１５】画像ファイル群を表示するＨＴＭＬ文書の一例を示した図である。
【符号の説明】
１０１  ＸＭＬコンテンツリストファイル
１０２〜１０６  コンテンツファイル
１０７  ディレクトリ構造
２０１  カードリーダ部
２０２  ストレージ部
２０３  表示部
２０４  ケーブルＩ／Ｆ部
２０５  処理部
２０６  ＲＡＭ
２０７  ＲＯＭ
２０８  入力部
２０９  データバス
３０１  ＸＭＬコンテンツリストファイル内のＩＭＧ要素
１１０  デジタルカメラ
１１１  ＰＣ
１１２  記憶メディア
１１３  ストレージ装置
１１４  ケーブル
１３０１  圧縮データスタート位置
１３０２  圧縮データ終了位置
１３０３  付属情報記録部
１３０４  マーカ、識別コード、ヘッダ等記録部
１３０５  メーカ、ユーザ情報記録部
１３０６  日時記録部
１３０７  サムネイル画像記録部
１３０８  圧縮のための各種テーブル、各ヘッダ情報記録部
１３０９  圧縮画像データ記録部
【図１】
2005010950.tif 000003
【図２】
2005010950.tif 000004
【図３】
2005010950.tif 000005
【図４】
2005010950.tif 000006
【図５】
2005010950.tif 000007
【図６】
2005010950.tif 000008
【図７】
2005010950.tif 000009
【図８】
2005010950.tif 000010
【図９】
2005010950.tif 000011
【図１０】
2005010950.tif 000012
【図１１】
2005010950.tif 000013
【図１２】
2005010950.tif 000014
【図１３】
2005010950.tif 000015
【図１４】
2005010950.tif 000016
【図１５】
2005010950.tif 000017