(57)【要約】【課題】異なるアプリケーションにより処理され、所定の格納場所に所定の構造で格納されたコンテンツファイル群の統一的な管理を行う。【解決手段】異なる格納場所（フォルダＡｐｐＡ、ＡｐｐＢ）に格納された、コンテンツファイル（ＤＳＣ．０００１．ＪＰＧ、ＤＳＣ．０００２．ＪＰＧ、・・・等）を含む複数のコンテンツファイル群（５０１、５０３）を管理する情報処理装置であって、コンテンツファイル群（５０１、５０３）それぞれについて、各コンテンツファイルの有する属性に基づいて各コンテンツファイルを分類する手段と、前記分類された各グループを示す識別子と、前記各グループに分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを記載したファイル（５０２、５０４）を生成する手段と、前記生成されたファイル（５０２、５０４）を関連付けるためのファイル（ｃｏｌ−ｐ．ｘｍｌ）を生成する手段とを備える。【選択図】  図５
2004334529.tif 000002
【特許請求の範囲】
【請求項１】
異なる格納場所に格納された、少なくとも１つのコンテンツファイルを含む複数のコンテンツファイル群を管理する情報処理装置であって、
前記異なる格納場所に格納されたコンテンツファイル群それぞれについて、該コンテンツファイル群の各コンテンツファイルの有する属性に基づいて各コンテンツファイルを分類する分類手段と、
前記分類された各グループを示す識別子と、前記各グループに分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを少なくとも記載した第１のコレクションファイルを、前記異なる格納場所に格納されたコンテンツファイル群ごとに生成する第１の生成手段と、
前記コンテンツファイル群ごとに生成された複数の前記第１のコレクションファイルを関連付けるための第２のコレクションファイルを生成する第２の生成手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記第２のコレクションファイルは、前記コンテンツファイル群ごとに生成された第１のコレクションファイルの識別子と、前記第１のコレクションファイルそれぞれの格納場所に関する情報とが少なくとも記載されていることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第２のコレクションファイルに格納場所が記載されたすべての前記第１のコレクションファイルを読み込むコレクションファイル読込手段と、
前記読み込まれた第１のコレクションファイルに識別子が記載されたすべてのコンテンツファイルについて、該コンテンツファイルの有する属性に応じて再分類する再分類手段と、
前記再分類された各グループを示す識別子と、前記各グループに再分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを少なくとも記載した第３のコレクションファイルを生成する第３の生成手段と
を備えることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記再分類手段は、
前記コンテンツファイルの格納場所に関する情報に基づいて、該コンテンツファイルを読み込むことで該コンテンツファイルに記載された属性に関する情報を取得し、該取得した属性に関する情報を用いて再分類を行うことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記再分類手段は、
前記第１のコレクションファイルに記載された前記各グループを示す識別子に基づいて再分類を行うことを特徴とする請求項３に記載の情報処理装置。
【請求項６】
前記第１のコレクションファイルには、前記コンテンツファイルを一意に識別するための識別子と、前記第１のコレクションファイルを一意に識別するための識別子とが更に記載されていることを特徴とする請求項１に記載の情報処理装置。
【請求項７】
前記複数のコンテンツファイル群は、複数の異なるアプリケーションそれぞれによって、前記異なる格納場所に格納されることを特徴とする請求項１に記載の情報処理装置。
【請求項８】
異なる格納場所に格納された、少なくとも１つのコンテンツファイルを含む複数のコンテンツファイル群を管理するための情報処理方法であって、
前記異なる格納場所に格納されたコンテンツファイル群それぞれについて、該コンテンツファイル群の各コンテンツファイルの有する属性に基づいて各コンテンツファイルを分類する分類工程と、
前記分類された各グループを示す識別子と、前記各グループに分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを少なくとも記載した第１のコレクションファイルを、前記異なる格納場所に格納されたコンテンツファイル群ごとに生成する第１の生成工程と、
前記コンテンツファイル群ごとに生成された複数の前記第１のコレクションファイルを関連付けるための第２のコレクションファイルを生成する第２の生成工程と
を備えることを特徴とする情報処理方法。
【請求項９】
前記第２のコレクションファイルは、前記コンテンツファイル群ごとに生成された第１のコレクションファイルの識別子と、前記第１のコレクションファイルそれぞれの格納場所に関する情報とが少なくとも記載されていることを特徴とする請求項８に記載の情報処理方法。
【請求項１０】
前記第２のコレクションファイルに格納場所が記載されたすべての前記第１のコレクションファイルを読み込むコレクションファイル読込工程と、
前記読み込まれた第１のコレクションファイルに識別子が記載されたすべてのコンテンツファイルについて、該コンテンツファイルの有する属性に応じて再分類する再分類工程と、
前記再分類された各グループを示す識別子と、前記各グループに再分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを少なくとも記載した第３のコレクションファイルを生成する第３の生成工程と
を備えることを特徴とする請求項９に記載の情報処理方法。
【請求項１１】
前記再分類工程は、
前記コンテンツファイルの格納場所に関する情報に基づいて、該コンテンツファイルを読み込むことで該コンテンツファイルに記載された属性に関する情報を取得し、該取得した属性に関する情報を用いて再分類を行うことを特徴とする請求項１０に記載の情報処理方法。
【請求項１２】
前記再分類工程は、
前記第１のコレクションファイルに記載された前記各グループを示す識別子に基づいて再分類を行うことを特徴とする請求項１０に記載の情報処理方法。
【請求項１３】
前記第１のコレクションファイルには、前記コンテンツファイルを一意に識別するための識別子と、前記第１のコレクションファイルを一意に識別するための識別子とが更に記載されていることを特徴とする請求項８に記載の情報処理方法。
【請求項１４】
前記複数のコンテンツファイル群は、複数の異なるアプリケーションそれぞれによって、前記異なる格納場所に格納されることを特徴とする請求項８に記載の情報処理方法。
【請求項１５】
請求項８乃至１４のいずれか１つに記載の情報処理方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項１６】
請求項８乃至１４のいずれか１つに記載の情報処理方法をコンピュータによって実現させるための制御プログラム。
【請求項１７】
異なる格納場所に格納された、少なくとも１つのコンテンツファイルを含む複数のコンテンツファイル群を管理する情報処理システムであって、
前記異なる格納場所に格納されたコンテンツファイル群それぞれについて、該コンテンツファイル群の各コンテンツファイルの有する属性に基づいて各コンテンツファイルを分類する分類手段と、
前記分類された各グループを示す識別子と、前記各グループに分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを少なくとも記載した第１のコレクションファイルを、前記異なる格納場所に格納されたコンテンツファイル群ごとに生成する第１の生成手段と、
前記コンテンツファイル群ごとに生成された複数の前記第１のコレクションファイルを関連付けるための第２のコレクションファイルを生成する第２の生成手段と
を備えることを特徴とする情報処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、画像ファイル等のデータファイル群を管理するための情報処理方法及び装置に関するものである。
【０００２】
【従来の技術】
デジタルカメラに代表される撮像装置において撮影された画像データや音声データ等のデータ群（以降の記述においては、画像ファイル、音声ファイル、動画ファイルなどいわゆるマルチメディアコンテンツファイル全般を「コンテンツファイル」として記述する）は、一般に、装置内に装着される取り外し可能な記憶媒体に、特定のファイル管理方法により特定のフォーマットで記録される。デジタルカメラにおいて、画像ファイルは一般にＥｘｉｆ、Ｔｉｆｆといった規格で定められる画像フォーマットで生成され、ＪＰＥＧと言われる規格で圧縮された上で記録されることが多い。またデジタルカメラに装着され、取り外しが可能な記憶媒体（リムーバブルメディア）への記録は、一般に、ＤＣＦ（Ｄｅｓｉｇｎｒｕｌｅ  ｆｏｒ  Ｃａｍｅｒａ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）で定める構造で行われることが多い（例えば、特許文献１、２）。
【０００３】
このようにして記録されたコンテンツ群は、リムーバブルメディアを介して、あるいはデジタルカメラ等からＵＳＢ等のケーブルを介してパーソナルコンピュータ（ＰＣ）等の情報処理装置に入力され認識されることとなる。認識されたコンテンツ群は一般に、アルバム表示等を行うアプリケーションソフトウェア（以下、アプリケーションとも記述）を介して利用される。このようなアプリケーションソフトウェアにおいては、認識されたコンテンツ群をＰＣのストレージ（記憶装置）内にコピーした上で処理することが多い。コピーの方法としては、先述のＤＣＦのディレクトリ構造をアプリケーションあるいはユーザーが指定するディレクトリにそのままコピーする場合や、アプリケーション独自の構造に変換してコピーする場合等が挙げられる。いずれにせよ、コンテンツ群はアプリケーションにより異なる構造で異なる場所にコピーされ管理されることが一般的である。
【０００４】
【特許文献１】
特開２００２−１４２１８５号公報
【特許文献２】
特開２００１−２８３１８８号公報
【０００５】
【発明が解決しようとする課題】
このようなアプリケーション独自の管理方法では、そのアプリケーションのみをＰＣで使う場合には問題が生じないが、別々のアプリケーションで取り扱っていた別々のコンテンツ群を、例えば１つのＰＣで統合して管理したいといった要求が生じた場合（たとえば同じ日に撮影した画像群を同じグループとしたい場合など）にそれができないか、あるいはできたとしてもユーザに煩雑な作業を強いることとなる、という問題が生じる。特に今後は個人が複数のデジタルカメラを所有するケースが増加していくと考えられることから、デジタルカメラごとに別のアプリケーションを使っていた場合であって、そのコンテンツ群の統一した管理を行いたい場合に、このような支障が生じることとなる。
【０００６】
本発明は、上記課題を鑑みてなされたものであり、異なるアプリケーションにより処理され、所定の格納場所に所定の構造で格納されたコンテンツファイル群を統一的に管理することで、該コンテンツファイルを利用するにあたっての利便性を向上させることを目的とする。
【０００７】
【課題を解決するための手段】
上記の目的を達成するために本発明に係る情報処理装置は以下のような構成を備える。即ち、
異なる格納場所に格納された、少なくとも１つのコンテンツファイルを含む複数のコンテンツファイル群を管理する情報処理装置であって、
前記異なる格納場所に格納されたコンテンツファイルコンテンツファイル群それぞれについて、該コンテンツファイル群の各コンテンツファイルの有する属性に基づいて各コンテンツファイルを分類する分類手段と、
前記分類された各グループを示す識別子と、前記各グループに分類されたコンテンツファイルの識別子と、該コンテンツファイルの格納場所に関する情報とを少なくとも記載した第１のコレクションファイルを、前記異なる格納場所に格納されたコンテンツファイル群ごとに生成する第１の生成手段と、
前記コンテンツファイル群ごとに生成された複数の前記第１のコレクションファイルを関連付けるための第２のコレクションファイルを生成する第２の生成手段とを備える。
【０００８】
【発明の実施の形態】
以下、本発明の各実施形態を図面を用いて説明する。
【０００９】
【第１の実施形態】
［システム構成］
図１は本発明の第１の実施形態にかかる情報処理装置の構成を示す図である。０１０１はメモリカードなどのカードリーダ部を示す。０１０２はハードディスクドライブなどのストレージ部を表す。０１０３はモニタなどの表示部を表す。０１０４はＵＳＢやＩＥＥＥ１３９４ケーブルなどを接続するためのインターフェース部を表す。
【００１０】
０１０５は処理部であり、ＣＰＵなどの演算装置を指す。以降で説明する各フローチャートにおける各処理プログラム、アプリケーションソフトウェアは、ストレージ部０１０２あるいはＲＯＭ０１０７、あるいはＲＡＭ０１０６にあらかじめ記録されており、処理部０１０５がその内容を適宜ＲＡＭ０１０６の適当な領域に読み出し実行する。各処理プログラムにおける変数はＲＡＭ０１０６内の適当な領域に格納される。あるいは状況により定数としてＲＯＭ０１０７に格納される場合もある。０１０９はデータバスを表し、各部間のデータの送受信はこのバスを通じて行われる。
【００１１】
［コンテンツ群の記録構造の説明］
図２は、先述のＤＣＦ規格に従ったコンテンツファイル群の記録状態の一例を示す図である。
【００１２】
ＤＣＦ規格においては、パーソナルコンピュータで広く流通しているファイルシステムと互換のあるＤＯＳ  ＦＡＴファイルシステムを採用した上で、図２で表されるように、そのルートディレクトリ０２００の直下にＤＣＩＭという名称のディレクトリ０２０１が存在し、その下に各サブディレクトリが配置される。各サブディレクトリの名称は８文字で構成され、その最初の３文字は１００から９９９までの番号で構成され、残りの５文字はＤＣＦ規格の範囲内で自由な文字をつけられている。図２の例ではこの命名規則に従い、０２０２で表されるディレクトリ名称となっている。その各サブディレクトリ内にコンテンツファイルが含まれる。コンテンツファイルの名称規則としては８文字で構成されるファイル名の前半４文字はＤＣＦ規格の範囲内で自由な文字列が、後半４文字には０００１から９９９９までの通し番号が付けられる。この例ではこの命名規則に従い、０２０３の一連のファイルで表されるコンテンツファイルの名称となっている。
【００１３】
［各コンテンツのファイルフォーマット構造の説明］
図３は、ＤＣＦ規格で記録される静止画像ファイル（ａ）、動画ファイル（ｂ）および音声ファイル（ｃ）のデータフォーマットの概念を説明する図である。静止画像ファイル０３００ａは、主画像データ０３０５ａと共に、画像属性情報（メタデータ）として、例えば、記録日時情報０３０１ａ、機種名情報０３０２ａ、撮影シーン情報０３０３ａ、およびサムネイル画像０３０４ａなどを格納する。
【００１４】
動画ファイル０３００ｂは、動画データ０３０２ｂと共に、動画属性情報（メタデータ）として、例えば、記録年月日情報０３０１ｂなどを格納する。
【００１５】
音声ファイル０３００ｃは、音声データ０３０４ｃと共に、音声属性情報（メタデータ）として、例えば、第１の属性情報領域における記録年月日情報０３０１ｃや、第２の属性情報領域における記録時刻０３０１ｃ’や機種名情報０３０２ｃなどを格納する。
【００１６】
［コレクションファイルの説明］
図４は、本発明の第１の実施形態にかかる情報処理装置により生成されるＸＭＬ形式によるコンテンツ群のリスト（以下、コレクションと記述）ファイルの記述方法を規定する定義情報ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）の一例を示す図である。
【００１７】
なお、ＸＭＬ並びにＤＴＤの構文規定の詳細は、ＸＭＬ勧告（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＲＥＣ−ｘｍｌ）に記載されている。
【００１８】
コレクションファイルのための定義情報ＤＴＤ０４００は、ＣＯＬＬＥＣＴＩＯＮ要素０４０１、ＧＲＯＵＰ要素０４０２、ＩＭＧ要素０４０３、ＭＯＶ要素０４０４、ＡＵＤ要素０４０５、ＭＥＴＡＤＡＴＡ要素０４０６によって構成される。
【００１９】
ＣＯＬＬＥＣＴＩＯＮ要素０４０１は、コレクションファイル集合全体を格納し、コレクションファイルのＲｏｏｔ要素として機能する。この要素は、０個以上のＭＥＴＡＤＡＴＡ要素（０４０６）に続き、０個以上のＧＲＯＵＰ要素（０４０２）またはＩＭＧ（０４０３）要素またはＭＯＶ要素（０４０４）またはＡＵＤ要素（０４０５）を子要素として持つことができる。またこの要素は、ＩＤ属性０４０１ａ、ＣＯＬＬＥＣＴＩＯＮ＿ＩＤ属性０４０１ｂ、ＮＡＭＥ属性０４０１ｃ、ＣＲＥＡＴＥ＿ＤＡＴＥ属性０４０１ｄ、ＭＯＤＩＦＹ＿ＤＡＴＥ属性０４０１ｅを持つことができる。ここで、ＩＤ属性（０４０１ａ）はコレクションファイル内で一意な要素識別子を表し、ＣＯＬＬＥＣＴＩＯＮ＿ＩＤ属性（０４０１ｂ）は少なくとも本情報処理装置の利用範囲内で一意なコレクション識別子を表す。ＮＡＭＥ属性（０４０１ｃ）はコレクションファイルの名前、ＣＲＥＡＴＥ＿ＤＡＴＥ属性（０４０１ｄ）、ＭＯＤＩＦＹ＿ＤＡＴＥ属性（０４０１ｅ）はそれぞれコレクションファイルの作成日時と更新日時を表す。
【００２０】
ＧＲＯＵＰ要素０４０２は、コレクションファイルを分類する任意集合を格納し、ＧＲＯＵＰ要素の階層構造を構成することができる。この要素は、０個以上のＭＥＴＡＤＡＴＡ要素（０４０６）に続き、０個以上のＧＲＯＵＰ要素（０４０２）またはＩＭＧ（０４０３）要素またはＭＯＶ要素（０４０４）またはＡＵＤ要素（０４０５）を子要素として持つことができる。またこの要素は、ＩＤ属性０４０２ａ、ＣＯＬＬＥＣＴＩＯＮ＿ＩＤ属性０４０２ｂ、ＮＡＭＥ属性０４０２ｃを持つことができる。ここで、ＩＤ属性（０４０２ａ）はコレクションファイル内で一意な要素識別子を表し、ＣＯＬＬＥＣＴＩＯＮ＿ＩＤ属性（０４０２ｂ）は少なくとも本情報処理装置の利用範囲内で一意な分類識別子を表す。ＮＡＭＥ属性（０４０２ｃ）は分類情報の名前を表す。
【００２１】
ＩＭＧ要素０４０３は、静止画像ファイル（例えばＪＰＥＧ画像）の情報を格納する。この要素は、０個以上のＭＥＴＡＤＡＴＡ要素（０４０６）を子要素として持つことができる。またこの要素は、ＩＤ属性０４０３ａ、ＣＯＮＴＥＮＴ＿ＩＤ属性０４０３ｂ、ＳＲＣ属性０４０３ｃ、ＴＹＰＥ属性０４０３ｄ、ＡＬＴ属性０４０３ｅを持つことができる。ここで、ＩＤ属性（０４０３ａ）はコレクションファイル内で一意な要素識別子を表し、ＣＯＮＴＥＮＴ＿ＩＤ属性（０４０３ｂ）は少なくとも本情報処理装置の利用範囲内で一意なデータファイル識別子を表す。ＳＲＣ属性（０４０３ｃ）は対象となる静止画像ファイルへのリンク参照であり、ＴＹＰＥ属性（０４０３ｄ）はＳＲＣ属性にて参照されている静止画像ファイルのＭＩＭＥタイプを表す。ＡＬＴ属性（０４０３ｅ）は簡易表示文字列であり、例えばＳＲＣ属性で参照されている静止画像ファイルを再生できない場合に使用する。
【００２２】
ＭＯＶ要素０４０４は、動画ファイル（例えばＭＰＥＧ動画）の情報を格納する。この要素は、０個以上のＭＥＴＡＤＡＴＡ要素（０４０６）を子要素として持つことができる。またこの要素は、ＩＤ属性０４０４ａ、ＣＯＮＴＥＮＴ＿ＩＤ属性０４０４ｂ、ＳＲＣ属性０４０４ｃ、ＴＹＰＥ属性０４０４ｄ、ＡＬＴ属性０４０４ｅを持つことができる。ここで、ＩＤ属性（０４０４ａ）はコレクションファイル内で一意な要素識別子を表し、ＣＯＮＴＥＮＴ＿ＩＤ属性（０４０４ｂ）は少なくとも本情報処理装置の利用範囲内で一意なデータファイル識別子を表す。ＳＲＣ属性（０４０４ｃ）は対象となる動画ファイルへのリンク参照であり、ＴＹＰＥ属性（０４０４ｄ）はＳＲＣ属性にて参照されている動画ファイルのＭＩＭＥタイプを表す。ＡＬＴ属性（０４０４ｅ）は簡易表示文字列であり、例えばＳＲＣ属性で参照されている動画ファイルを再生できない場合に使用する。
【００２３】
ＡＵＤ要素０４０５は、音声ファイル（例えばＭＰＥＧ音声）の情報を格納する。この要素は、０個以上のＭＥＴＡＤＡＴＡ要素（０４０６）を子要素として持つことができる。またこの要素は、ＩＤ属性０４０５ａ、ＣＯＮＴＥＮＴ＿ＩＤ属性０４０５ｂ、ＳＲＣ属性０４０５ｃ、ＴＹＰＥ属性０４０５ｄ、ＡＬＴ属性０４０５ｅを持つことができる。ここで、ＩＤ属性（０４０５ａ）はコレクションファイル内で一意な要素識別子を表し、ＣＯＮＴＥＮＴ＿ＩＤ属性（０４０５ｂ）は少なくとも本情報処理装置の利用範囲内で一意なデータファイル識別子を表す。ＳＲＣ属性（０４０５ｃ）は対象となる音声ファイルへのリンク参照であり、ＴＹＰＥ属性（０４０５ｄ）はＳＲＣ属性にて参照されている音声ファイルのＭＩＭＥタイプを表す。ＡＬＴ属性（０４０５ｅ）は簡易表示文字列であり、例えばＳＲＣ属性で参照されている音声ファイルを再生できない場合に使用する。
【００２４】
ＭＥＴＡＤＡＴＡ要素０４０６は、前記静止画、動画、音声ファイルの属性情報（メタデータ）を格納する。この要素は、子要素の制限はない。またこの要素は、ＩＤ属性０４０６ａを持つことができる。ここで、ＩＤ属性（０４０６ａ）はコレクションファイル内で一意な要素識別子を表す。
【００２５】
なお、前記リンク参照とはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）においてＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）として標準化されているＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）であり、ＲＦＣ２３９６およびＲＦＣ２７３２に定義されている。
【００２６】
また、前記ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）タイプは、ＲＦＣ２０４５およびＲＦＣ２０４６に定義されるフォーマットで記載され、
タイプ／サブタイプ
と記述される。タイプとしては、例えば、ｉｍａｇｅ、ａｕｄｉｏ、ｖｉｄｅｏなどがあり、それぞれ静止画像データ、音声データ、動画データに分類されるデータであること表す。
【００２７】
［情報処理装置における処理の説明］
本実施形態にかかる情報処理装置における処理の一例として、以下では、情報処理装置上に２つのアプリケーションソフトウェアＡ、Ｂが存在する場合について説明する。具体的には、該アプリケーションソフトウェアＡ、Ｂによってリムーバブルメディアから情報処理装置のストレージ部０１０２にコンテンツファイル群がコピーされる際に、情報処理装置が上記ＤＴＤの規則に従ったコレクションファイルをそれぞれ作成することで、コンテンツファイル群の管理を行うケースについて詳説する。
【００２８】
図５は、各アプリケーションがリムーバブルメディアからコンテンツ群をコピーした状態を示す図である。まず、アプリケーションＡがリムーバブルメディアにおいてＤＣＦ構造で記録されたコンテンツ群を０５０１で示す構造でコピーする際に、本情報処理装置においてＸＭＬで記述されたコレクションファイル０５０２が作成される処理を図６のフローチャートを用いて説明する。
【００２９】
まず、変数Ｄｉｒにコピー先のディレクトリパス、この場合はＣ：￥ＡｐｐＡが代入され（ステップＳ０６０１）、そのディレクトリ以下にリムーバブルメディア内でＤＣＦ構造に従って記録されたコンテンツファイル群をコピーする（ステップＳ０６０２）。ここでは、ＤＣＦの構造であるＤＣＩＭフォルダとそのサブディレクトリの構造をそのままコピーしているが、アプリケーション独自の構造に変換してコピーしても良いことは言うまでもない。
【００３０】
次に、コピーしたコンテンツファイル群の数をカウントし変数ｎに代入する（ステップＳ０６０３）。そしてカウンタｉを０からｎ−１まで繰り返す形で各コンテンツファイルを読み込み（ステップＳ０６０５）、ＦｉｌｅＬｉｓｔ（ｉ）にファイル名とパスを代入（ステップＳ０６０６）、そのコンテンツファイル毎に、少なくとも情報処理装置全体で一意となるＩＤ値を作成（ステップＳ０６０７）し、変数ＣｏｎｔｅｎｔＩＤ（ｉ）に代入する。ここではＯＳＦ（ＯｐｅｎＳｏｆｔｗａｒｅ  Ｆｏｕｎｄａｔｉｏｎ）で規定されたＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  ＩＤｅｎｔｉｆｉｅｒ）という１２８ビットの文字列を使用しているが、これ以外のＩＤを使用しても良い。
【００３１】
次にコンテンツファイルのファイルタイプの判別（ステップＳ０６０８）を行い変数ＦｉｌｅＴｙｐｅ（ｉ）に代入し、先に図３で説明したコンテンツファイルの属性情報（メタデータ）を読み取り、変数Ｍｅｔａｄａｔａ（ｉ）に代入する（ステップＳ０６０９）。ここではメタデータとして日付情報を取得しそれを利用してグルーピング（分類）を行うこととするが、日付情報以外のメタデータあるいは複数のメタデータを組み合わせてグルーピングを行っても良い。
【００３２】
この例では日付ごとのグルーピングを行うため、読み取られたメタデータが図７の０７０１で示されるような日付および時刻で示される形式の場合は、０７０２のとおり日付のみのデータに加工し、変数ＡｔｔＶａｌに代入する（ステップＳ０６１０）。ＧｒｏｕｐＬｉｓｔにＡｔｔＶａｌが存在するか判別し（ステップＳ０６１１）、存在する場合はステップＳ０６１４に進み、一方、存在しない場合はステップＳ０６１２に進んで、ＡｔｔＶａｌをグループ名としてＧｒｏｕｐＬｉｓｔに追加し、更に、グループごとに情報処理装置固有のＩＤ値を作成し、Ｃｏｌｌｅｃｔｉｏｎ＿ＩＤ（ＡｔｔＶａｌ）に代入する（ステップＳ０６１３）。さらにＧｒｏｕｐＬｉｓｔ（ＡｔｔＶａｌ）内にそのＡｔｔＶａｌ値のグループとして分類されるＦｉｌｅＬｉｓｔ（ｉ）を追加する（ステップＳ０６１４）。そして、子コレクションファイル内で一意となるＩＤ値を作成し、ＩＤ（ｉ）に代入する（ステップＳ０６１５）。
【００３３】
これらの処理をすべてのコンテンツファイルに対して行った後（ステップＳ０６１６の「Ｙｅｓ」）、各変数に代入した値をもとに情報処理装置一意のＣｏｌｌｅｃｔｉｏｎ＿ＩＤを付与したコレクションファイル（第１のコレクションファイル、以下では「子コレクションファイル」と記述）を書き出す（ステップＳ０６１８、ステップＳ０６１９）。書き出された子コレクションファイルは図８に示す通りであり、図５の０５０２に示す格納場所にｃｏｌ−ａ．ｘｍｌというファイル名で記録される。
【００３４】
同様の処理をアプリケーションＢが管理するリムーバブルメディアのコンテンツファイル群に対しても行う。コピーされたコンテンツファイル群は図５の０５０３に示す格納場所に保存され、作成されたコレクションファイルは同じく図５の０５０４に示す格納場所にｃｏｌ−ｂ．ｘｍｌというファイル名で保存され、その内容は図９のとおりとなる。
【００３５】
上記までの処理により、各アプリケーションは各々ＸＭＬを使ってグルーピングされたコンテンツファイル群を利用することが可能となるが、別のアプリケーションで管理されているコンテンツファイル群との関連付けは行われていない。次にその関連付けを行うためのコレクションファイル（第２のコレクションファイル、以下では「親コレクションファイル」と記述）を作成する。これは最初に作成した各子コレクションファイルと同じＤＴＤ定義で構成されるＸＭＬファイルとして作成することができる。そのフローチャートを図１０に示す。
【００３６】
まず、先に作成されたそれぞれの子コレクションファイルのファイルパスをＰａｔｈ（ｉ）に代入する（ステップＳ１００２）。ここでは親コレクションファイルをストレージ上の同じドライブのルートディレクトリに作成することとしているので、アプリケーションＡではＰａｔｈ（ｉ）は“．／ＰｒｏｇｒａｍＦｉｌｅｓ／ＡｐｐＡ／ＭＩＳＣ／ｃｏｌ−ａ．ｘｍｌ”、アプリケーションＢでは“．／ＰｒｏｇｒａｍＦｉｌｅｓ／ＡｐｐＢ／ＭＩＳＣ／ｃｏｌ−ｂ．ｘｍｌ”となる。
【００３７】
次に、各子コレクションの名称としての文字列をＧｒｏｕｐＮａｍｅ（ｉ）に代入する（ステップＳ１００３）。ここではアプリケーションＡでは“ＡｐｐＡ”、アプリケーションＢでは“ＡｐｐＢ”としているが、ユーザが入力しても、あるいは情報処理装置が別の名称を割り当てても良い。
【００３８】
上記処理をすべての子コレクションファイルに対して繰り返し（ステップＳ１００４、Ｓ１００７）、繰り返し終了後（ステップＳ１００４の「Ｙｅｓ」）、その子コレクションファイルに情報処理装置で一意となるＩＤを作成し変数ＣｏｌｌｅｃｔｉｏｎＩＤに代入する（ステップＳ１００５）。最後に各変数の値を反映した親コレクションファイルの書き出しを行う（ステップＳ１００６）。本例により書き出された親コレクションファイルの内容は図１１に示す通りとなり、ファイル名はｃｏｌ−ｐ．ｘｍｌとなっている。
【００３９】
この親コレクションファイルを作成することで、別々のアプリケーションによって管理されている各子コレクションファイルを関連付けることができるようになる。
【００４０】
次に、必要に応じて、これら複数の子コレクションファイル群を、一つのフラットなコレクションファイル（以下、フラットコレクションファイルと記述）として再構成する手順を、図１２を用いて説明する。
【００４１】
まず親コレクションファイルを読み込み（ステップＳ１２０１）、そのＧＲＯＵＰ要素のＳＲＣ属性でリンク付けがなされている各子コレクションファイルを、カウンタを変数ｉとして一つずつ読み込む（ステップＳ１２０３）。この例ではリンクされている子コレクションファイルは２つであるが、その数が３つ以上であっても同様に処理が可能であることは言うまでもない。
【００４２】
そのファイル名とパスを変数Ｃｏｌｌｅｃｔｉｏｎ（ｉ）に代入し、さらにその読み込んだ（子）コレクションファイル内のＩＭＧ、ＭＯＶ、ＡＵＤ要素をカウンタをｊとして順に選択する（ステップＳ１２０６）。
【００４３】
続いてその要素名と属性値群を変数Ｅｌｅｍｅｎｔ（ｉ，ｊ）に代入する。ただし、ＩＤ属性は各子コレクションファイル内での一意性のみが保証されているものであるので、合成を行う場合には一般に付け替えが必要となる。そのためＩＤ属性部分はここでは空欄としておく処理を施す（ステップＳ１２０７）。
【００４４】
さらにそこでリンクされているコンテンツファイルそのものを読み込み（ステップＳ１２０８）、読み込んだコンテンツファイルからメタデータを読み、それをＭｅｔａｄａｔａ（ｉ，ｊ）に代入する（ステップＳ１２０９）。
【００４５】
子コレクションファイルを作成した際と同様、必要に応じてＭｅｔａｄａｔａ（ｉ、ｊ）の値を加工してそれを変数ＡｔｔＶａｌに代入し、グループ名とする（ステップＳ１２１０）。ＧｒｏｕｐＬｉｓｔにＡｔｔＶａｌが存在しない場合は、ＡｔｔＶａｌをＧｒｏｕｐＬｉｓｔ（ＡｔｔＶａｌ）に追加し（ステップＳ１２１２）、グループの情報処理装置固有ＩＤ値を作成してＣｏｌｌｅｃｔｉｏｎ＿ＩＤ（ＡｔｔＶａｌ）に代入する（ステップＳ１２１３）。次に先ほど空欄としていたＥｌｅｍｅｎｔ（ｉ、ｊ）のＩＤ属性値部分に、フラットコレクションファイル固有のＩＤ値を作成し格納する（ステップＳ１２１４）。さらにＧｒｏｕｐＬｉｓｔ（ＡｔｔＶａｌ）内にそのＡｔｔＶａｌ値のグループとして分類されるＥｌｅｍｅｎｔ（ｉ、ｊ）を追加する（ステップＳ１２１５）。これを各子コレクションファイルの各要素すべてに対し繰り返す（ステップＳ１２１６〜Ｓ１２１９）。
【００４６】
最後に、フラットコレクションファイル全体の固有ＩＤ値を作成し（ステップＳ１２２０）、各変数に記憶した値をもとに、フラットコレクションファイルを書き出す（ステップＳ１２２１）。
【００４７】
完成したＸＭＬ形式のフラットコレクションファイルはｃｏｌ−ｆ．ｘｍｌとてストレージの同じドライブのルートディレクトリに記録される。その内容は図１３のとおりとなり、ｃｏｌ−ａ．ｘｍｌ，ｃｏｌ−ｂ．ｘｍｌでそれぞれ別に管理されていたが同じ年月日に作成されたコンテンツファイル群は同じグループ内に分類されていることがわかる。
【００４８】
このフラットコレクションファイルを用いると、例えば、ＸＳＬＴというＷ３Ｃで規定された規格に対応した機能を持つＷｅｂブラウザなどのアプリケーションを用いて、作成したフラットなコレクションでの論理的なグルーピングを反映した表示や印刷などを行うことが可能となる。
【００４９】
以上の説明から明らかなように、本実施形態によれば、所定のアプリケーションにより所定の格納場所に所定の構造で格納されたコンテンツファイル群について属性に応じたグルーピングを行うにあたり、子コレクションファイルを生成して管理することで、コンテンツファイルを利用するにあたっての利便性を向上させることが可能となる。
【００５０】
また、異なるアプリケーションにより処理された複数のコンテンツファイルに対しても、各子コレクションファイルを関連付ける親コレクションファイルを生成して管理することで、コンテンツファイルを利用するにあたっての利便性が向上させることが可能となる。
【００５１】
さらに、親コレクションファイルと子コレクションファイルとを用いて、フラットコレクションファイルを生成することで、異なるアプリケーションにより処理された複数のコンテンツファイルを統一的に管理することが可能となり、コンテンツファイルを利用するにあたっての利便性をさらに向上させることが可能となる。
【００５２】
【第２の実施形態】
上記第１の実施形態においては、図１２で示したフラットコレクションファイル作成において各子コレクションファイルが参照している各コンテンツファイルを参照し、そのメタデータを参照することとしたが、最初の各子コレクションファイル作成時のグルーピングおよびフラットコレクションファイルの作成時のグルーピングが同一の基準によって行われ、かつ最初に作成する各子コレクションファイル内のいずれか（この例ではＧＲＯＵＰ要素のＮＡＭＥ属性値）によってその基準が表現されている場合、それをキーとして、各子コンテンツファイルへの参照を行うことなくフラットコレクションファイルを作成することが可能である。
【００５３】
さらに、最初の子コレクションファイル作成時に、必要なメタデータを子コレクションファイルのＭＥＴＡＤＡＴＡ要素内に記述しておくことで、後で改めてコンテンツファイルの参照を行うことなく各子コレクションファイルを参照するのみでフラットコレクションファイルを作成することが可能となる。
【００５４】
具体的には、例えば図８で示したｃｏｌ−ａ．ｘｍｌの代わりに、図１４のｃｏｌ−ａ２．ｘｍｌのように適当なｎａｍｅｓｐａｃｅを持つＭＥＴＡＤＡＴＡ要素（ここでは撮影年月日と撮影者）を各ＩＭＧ、ＡＵＤ、ＭＯＶ要素に内包したものを作成し、ｃｏｌ−ｂ．ｘｍｌも同様な形態で作成することで、それらを参照して図１３で示したｃｏｌ−ｆ．ｘｍｌと同じ撮影年月日でグルーピングしたフラットコレクションファイルや、図１５のｃｏｌ−ｆ２．ｘｍｌで示したような、撮影者によるグルーピングを行ったフラットコレクションファイルなどを作成することが可能となる。
【００５５】
【第３の実施形態】
上記第１、第２の実施形態においては、各コンテンツファイルと子コレクションファイル、親コレクションファイル、フラットコレクションファイルのそれぞれが同じストレージ部内に存在する場合について説明したが、これらは個々に別のデバイス内で作成され、これらの各デバイスがインターネットプロトコル上でのＨＴＴＰプロトコル（ＨＴＴＰプロトコルはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）においてＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）２０６８として標準化されている）などお互いが通信を行うことができる手段を持つネットワーク上に配置されていた場合であっても、当該ネットワーク上で上記第１の実施形態あるいは第２の実施形態で記述した処理を実現できることは言うまでもない。
【００５６】
図１６にその一例を示す。この例では、１６０１、１６０２、１６０３、１６０４はネットワーク１６００上の各デバイスであり、インターネット上で識別される名称（アドレス）である１６０１−ｄ、１６０２−ｄ、１６０３−ｄ、１６０４−ｄを持つ。
【００５７】
各デバイスは図１で示したＣＰＵ等の処理機能群およびＨＴＴＰプロトコル等の処理機能を搭載する。１６０１、１６０２、１６０４はＰＣサーバを一例とする情報処理装置、１６０３は同等の情報処理装置を搭載するデジタルカメラを一例とする撮像装置を例示している。
【００５８】
第１の実施形態において例示したｃｏｌ−ａ．ｘｍｌと同様の子コレクションファイルがデバイス１６０２内の処理のもと、そのストレージ内に、１６０２−ｘとして作成される。
【００５９】
さらに、作成時にデバイス１６０２により参照されるコンテンツファイル群は別のデバイス１６０１のストレージ内に１６０１−ｃの各ファイル名でＤＣＦと同様のディレクトリ構造で格納されており、ＨＴＴＰ等の手段を用いてコンテンツファイル群は参照される。この例でファイル名ｃｏｌ−ａ３．ｘｍｌとして作成される子コレクションファイル１６０２−ｘを図１７に示す。
【００６０】
また、第１の実施形態において例示したｃｏｌ−ｂ．ｘｍｌと同様の子コレクションファイルがデバイス１６０３内の処理のもと、そのストレージ内に、１６０３−ｘとして作成される。作成時に参照されるコンテンツファイル群は同じデバイス１６０３のストレージ内に第１の実施形態と同じディレクトリ構造で格納されている。１６０３−ｃはその各ファイル名である。
【００６１】
デバイス１６０４では親コレクション１６０４−ｘ１およびフラットコレクション１６０４−ｘ２を作成する。作成の際にはＨＴＴＰ等の手段を用いて各子コレクションあるいはコンテンツファイルを参照する。この例において作成される親コレクション１６０４−ｘ１とフラットコレクション１６０４−ｘ２の例をそれぞれ図１８、図１９に示す。
【００６２】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００６３】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００６４】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００６５】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００６６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６７】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６８】
【発明の効果】
以上説明したように本発明によれば、異なるアプリケーションにより処理され、所定の格納場所に所定の構造で格納されたコンテンツファイル群を統一的に管理することで、該コンテンツファイルを利用するにあたっての利便性を向上させることが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態にかかる情報処理装置の構成を示す図である。
【図２】ＤＣＦ規格に従ったコンテンツファイル群の記録状態の一例を示す図である。
【図３】ＤＣＦ規格で記録される静止画像ファイル、動画ファイル、および音声ファイルのデータフォーマットの概念を説明する図である。
【図４】本発明の第１の実施形態にかかる情報処理装置により処理される、ＸＭＬ形式によるコレクションと記述ファイルの記述方法を規定するＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）の例を示す図である。
【図５】各アプリケーションがリムーバブルメディアからコンテンツファイル群をコピーした状態を示す図である。
【図６】本発明の第１の実施形態にかかる情報処理装置における子コレクションファイル作成処理の流れを示すフローチャートである。
【図７】メタデータ値を加工する変換前、変換後の形態を示す図である。
【図８】書き出された子コレクションファイルの内容の一例を示す図である。
【図９】書き出された子コレクションファイルの内容の一例を示す図である。
【図１０】本発明の第１の実施形態にかかる情報処理装置における親コレクションファイル作成処理の流れを示すフローチャートである。
【図１１】書き出された親コレクションファイルの内容の一例を示す図である。
【図１２】本発明の第１の実施形態にかかる情報処理装置におけるフラットコレクションファイル作成処理の流れを示すフローチャートである。
【図１３】書き出されたフラットコレクションファイルの内容の一例を示す図である。
【図１４】書き出されたメタデータ部を含むフラットコレクションファイルの内容の一例を示す図である。
【図１５】書き出されたフラットコレクションファイルの内容の一例を示す図である。
【図１６】本発明の第３の実施形態にかかる情報処理装置を備えるネットワークにおけるコンテンツファイル群の位置関係を示す図である。
【図１７】書き出された子コレクションファイルの内容の一例を示す図である。
【図１８】書き出された親コレクションファイルの内容の一例を示す図である。
【図１９】書き出されたフラットコレクションファイルの内容の一例を示す図である。
【符号の説明】
０１０１：  カードリーダ部
０１０２：  ストレージ部
０１０３：  表示部
０１０４：  インターフェース部
０１０５：  処理部
０１０６：  ＲＡＭ
０１０７：  ＲＯＭ
０１０８：  入力部
０１０９：  データバス
０２００、０２０１、０２０２：  ＤＣＦファイル構造におけるディレクトリ
０２０３：  ＤＣＦファイル構造におけるコンテンツファイル群
０３００ａ：  静止画像ファイル
０３００ｂ：  動画ファイル
０３００ｃ：  音声ファイル
０３０１ａ、０３０１ｂ、０３０１ｃ、０３０１ｃ’：  記録日時情報
０３０２ａ、０３０２ｃ：  機種名情報
＃３０２ｂ：  動画データ
０３０３ａ：  撮影シーン情報
０３０４ａ：  サムネイル画像データ
０３０４ａ：  主画像データ
０３０４ｃ：  音声データ
【図１】
2004334529.tif 000003
【図２】
2004334529.tif 000004
【図３】
2004334529.tif 000005
【図４】
2004334529.tif 000006
【図５】
2004334529.tif 000007
【図６】
2004334529.tif 000008
【図７】
2004334529.tif 000009
【図８】
2004334529.tif 000010
【図９】
2004334529.tif 000011
【図１０】
2004334529.tif 000012
【図１１】
2004334529.tif 000013
【図１２】
2004334529.tif 000014
【図１３】
2004334529.tif 000015
【図１４】
2004334529.tif 000016
【図１５】
2004334529.tif 000017
【図１６】
2004334529.tif 000018
【図１７】
2004334529.tif 000019
【図１８】
2004334529.tif 000020
【図１９】
2004334529.tif 000021