(57)【要約】【課題】  新規データを記憶手段に記憶する際、従来はキャッシュ手段にも記憶されることはなかった。一度もアクセスや検索の対象になっていないからである。本発明では、未編集状態の新規画像データは、後で編集のためにアクセスされることが想定されるので、優先的にキャッシュ手段に記憶する。【解決手段】  データ判定部３０４は、保存対象のデータがデータ記憶部３０６に記憶済みのデータと異なる新規のデータであることを判定し、要求元判定部３０３は、データ保存要求を送信したデバイスはデータの編集が可能であるかを判定し、制御部３０７は、データ判定部３０４と要求元判定部３０３の判定結果に基づいて、キャッシュ記憶部３０８上のデータを更新制御する。【選択図】  図３
2016085522.tif 000002
【特許請求の範囲】
【請求項１】
データ記憶手段と高速アクセス可能なキャッシュ記憶手段を備える情報管理装置であって、
データの保存要求と保存対象データを受信する受信手段と、
前記保存対象データが前記データ記憶手段に記憶済みのデータと異なる新規のデータであることを判定するデータ判定手段と、
前記保存要求を送信したデバイスはデータの編集が可能であるかを判定する要求元判定手段と、
前記要求元判定手段及び前記データ判定手段の判定結果に基づいて前記キャッシュ記憶手段上のデータを更新制御する制御手段を備えたことを特徴とする情報管理装置。
【請求項２】
請求項１記載の情報管理装置であって、
前記データはＲＡＷ画像データであり、
前記キャッシュ記憶手段に格納するデータは前記ＲＡＷ画像データに内包されているＪＰＥＧ画像データである
ことを特徴とする情報管理装置。
【請求項３】
請求項１記載の情報管理装置であって、
前記制御手段は、未編集状態と通常状態の２種類の状態を画像に付与し、
前記キャッシュ記憶手段には未編集状態の画像を優先して格納することを特徴とする情報管理装置。
【請求項４】
請求項１記載の情報管理装置であって、
前記制御手段は、未編集状態と判定不能状態と編集状態の３種類の状態を画像に付与し、
前記キャッシュ記憶手段には未編集状態、判定不能状態、編集状態の優先順位で画像を格納することを特徴とする情報管理装置。
【請求項５】
請求項１記載の情報管理装置であって、
前記制御手段は、未編集状態と通常状態の２種類の状態を画像に付与し、
前記制御手段は、各画像が外部デバイスから取得されたかどうかを示す未取得フラグを管理することを特徴とする情報管理装置。
【請求項６】
請求項１記載の情報管理装置であって、
前記受信手段がＵＳＢインタフェースである情報管理装置。
【請求項７】
請求項１記載の情報管理装置であって、
前記受信手段がネットワークインタフェースである情報管理装置。
【請求項８】
請求項１記載の情報管理装置であって、
前記受信手段がＳＤカードスロットインタフェースである情報管理装置。
【請求項９】
請求項１記載の情報管理装置であって、
前記制御手段は、前記データを定められた規則によってグループに分類し、
前記キャッシュ記憶手段に格納するデータを前記グループの単位で選択することを特徴とする情報管理装置。
【請求項１０】
データ記憶工程と高速アクセス可能なキャッシュ記憶工程を備える情報管理方法であって、
データの保存要求と保存対象データを受信する受信工程と、
前記保存対象データが前記データ記憶工程で記憶済みのデータと異なる新規のデータであることを判定するデータ判定工程と、
前記保存要求を送信したデバイスはデータの編集が可能であるかを判定する要求元判定工程と、
前記要求元判定工程及び前記データ判定工程の判定結果に基づいてキャッシュ上のデータを更新制御する制御手段を備えたことを情報管理方法。
【請求項１１】
請求項１から９のいずれか１項に記載の情報管理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データをメモリにキャッシュすることで、以後のアクセス時に高速にアクセスできるキャッシュ方法、そのシステム及びそのプログラムに関する。
【背景技術】
【０００２】
メモリのような高速な記憶装置とハードディスクのような低速な記憶装置をともに備えるデバイスにおいて、アクセスされるデータを高速な記憶装置に配置することで応答性を高めるキャッシュ技術は、従来から存在する。
【０００３】
キャッシュの課題の一つは、キャッシュするデータの選択である。一般的な選択手段としては、アクセスされたデータをキャッシュして次回アクセスを高速化する方法がある。また、キャッシュのヒット率を高めるためのキャッシュデータ入れ替え手法として、例えばＬＲＵ（Ｌｅａｓｔ  Ｒｅｃｅｎｔｌｙ  Ｕｓｅｄ）アルゴリズムが存在する。
【０００４】
初回のアクセスからキャッシュにヒットさせるためのより高度な手段として、アクセスされるデータを予測する方法がある。利用者のアクセス頻度を記憶してアクセス頻度が高いデータをキャッシュする手法が知られている。（例えば特許文献１参照）また、アクセス元が保持しているデータを取得し、アクセス元が保持していないデータをキャッシュする手法が知られている。（例えば特許文献２参照）また、アクセスされたデータに関連するデータをキャッシュする手法が知られている。（例えば特許文献３、４参照）
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１８７３９３号公報
【特許文献２】特開２０１０−２８２４３０号公報
【特許文献３】特開２００９−１８７３９４号公報
【特許文献４】特開２００６−８５５６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１では、過去のアクセス頻度からアクセスされるデータを予測する。しかしながら、各データの個別のアクセス頻度だけでは、予測の精度が高くならない。
【０００７】
特許文献２では、外部装置の現在の表示データと表示状態、およびアクセス操作の種類とデータの読み出し条件との関連を定義した規則情報を用いて予測を行う。しかしながら、外部装置の状態と表示データの取得が必須なため、実施条件が複雑となる。
【０００８】
特許文献３では、利用者がよく利用するデータと、そのデータ間の関連付けルールを用いて、アクセス要求を受けた時にアクセスされたデータと関連が深い情報をキャッシュする。しかし、最初のアクセス要求に対するキャッシュのヒット率を高める工夫はなされていない。また、過去のアクセス履歴に基づいた手法のため、新規データのキャッシュヒット率は高くなりにくい。
【０００９】
特許文献４では、クライアントからの検索クエリによってなされた処理のログである検索ログと、ダウンロード処理のログであるダウンロードログを用いて、検索クエリからダウンロードされるデータを予測する。しかし、一度も検索されていない新規のデータに対しては、効果が生じにくい。
【００１０】
本発明は、画像を保存するＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）用のキャッシュシステムを想定している。画像保存および編集のワークフローとしては、カメラで撮影→カメラからＮＡＳに画像を保存→保存した画像をＰＣで取得して編集作業、というワークフローがある。また、カメラで撮影→カメラからＰＣに画像を保存→ＰＣで編集作業→ＮＡＳに保存、というワークフローもある。ＮＡＳが優先してキャッシュすべき画像は、ＰＣが作業のためにＮＡＳに要求する画像、つまり、未編集の画像でＰＣ側が保持していない画像である。画像編集ソフトによっては、画像を直接編集せずに、編集した操作（レシピ）だけを保持するものもあり、その場合編集後も画像の更新日が変わらないため、画像の作成日と更新日だけでは、未編集であるかを判定することはできない。上記ワークフローを前提として、未編集の画像を特定する手段が必要となる。
【課題を解決するための手段】
【００１１】
上記問題を解決するために、請求項１は、データ記憶手段と高速アクセス可能なキャッシュ記憶手段を備える情報管理装置であって、データの保存要求と保存対象データを受信する受信手段と、前記保存対象データが前記データ記憶手段に記憶済みのデータと異なる新規のデータであることを判定するデータ判定手段と、前記保存要求を送信したデバイスはデータの編集が可能であるかを判定する要求元判定手段と、前記要求元判定手段及び前記データ判定手段の判定結果に基づいて前記キャッシュ記憶手段上のデータを更新制御する制御手段を備えたことを特徴とする。
【発明の効果】
【００１２】
以上の構成からなる本発明によれば、未編集画像データの情報管理装置からの取得が、高速化される。
【図面の簡単な説明】
【００１３】
【図１】情報管理装置のハードウェア構成の一例を示す図である。
【図２】情報管理装置のシステム構成の一例を示す図である。
【図３】情報管理装置の機能のブロック図である。
【図４】管理手段の処理を示すフローチャートである。
【図５】実施例１にかかる画像状態更新手順を示すフローチャートである。
【図６】画像状態テーブルを示す図である。
【図７】実施例１にかかる要求元判定手順を示すフローチャートである。
【図８】実施例４にかかる要求元判定手順を示すフローチャートである。
【図９】実施例７にかかる管理手段の処理を示すフローチャートである。
【図１０】実施例１にかかる制御手段の処理を示すフローチャートである。
【図１１】実施例５にかかる制御手段の処理を示すフローチャートである。
【図１２】実施例６にかかる制御手段の処理を示すフローチャートである。
【図１３】実施例７にかかる制御手段の処理を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１５】
＜実施例１＞
図１は、情報管理装置のハードウェア構成の一例を示す図である。図１に示されるように情報管理装置１０１は、ハードウェア構成として、ＣＰＵ１１を含む。
【００１６】
ＣＰＵ１１が、記憶装置１３に記憶されている後述するアプリケーションやプログラム実行環境等の各々に対応するプログラムに基づき処理を行うことによって、後述する各機能、又はフローチャートを実現する。
【００１７】
また、ＣＰＵ１１には、バス１０を介して、入力装置１２、記憶装置１３及び表示装置１４が接続されている。記憶装置１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータ等を記憶する。表示装置１４は、画面等を表示するディスプレイである。入力装置１２は、情報を入力するキーボード及び／又はマウス、ネットワークインタフェース、外部機器との各種接続インタフェースである。
【００１８】
次に、情報管理装置１０１上に構築するシステム構成について、図２を用いて説明する。図２は、情報管理装置１０１上に構築するファイルシステムに関与するソフトウェア構成の一例を示す図である。
【００１９】
ドライバ２０１は、記憶装置１３の動作に必要なドライバである。ファイルシステム２０２は、情報管理装置１０１上のＯＳの機能として提供されるファイルシステムである。例えば、ＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）、ＮＴＦＳ（ＮＴ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）、ＥＸＴ３（ｔｈｉｒｄ  ｅｘｔｅｎｄｅｄ  ｆｉｌｅ  ｓｙｓｔｅｍ）などが想定される。ファイルシステム２０２は、記憶装置１３の種類や記憶装置１３のパーティションに応じて、複数存在する場合もある。ＶＦＳ（Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）２０３は、アプリケーション２０４からのファイル操作に関する要求を受け付け、それを関連するファイルシステム２０２ごとのＡＰＩに変換する。ＡＰＩに変換された要求は、ドライバ２０１を経由して記憶装置１３を操作する。アプリケーション２０４には、情報管理装置１０１の外部から入力装置１２によって接続されるＰＣやカメラからのファイル操作要求を受け付けるためのファイル共有サービスも含まれる。
【００２０】
次に、情報管理装置１０１の具体的な動作について、図３を用いて説明する。図３は、情報管理装置１０１が備える機能を示すブロック図である。この機能は、コンピュータであるＣＰＵ１１が記憶装置１３に記憶されたプログラムを読み出して、実行することにより実現される。記憶装置１３は、このプログラムをＣＰＵ１１が読み出すことができるように記憶した記憶媒体である。
【００２１】
情報管理装置１０１は、外部のクライアントデバイスと入力装置１２を介して接続され、画像データの管理のために利用される。クライアントデバイスとしては、たとえばカメラ３０１ａやＰＣ３０１ｂ、クラウド３０１ｃが挙げられる。保存される画像データは、ＲＡＷ画像形式である。ＲＡＷ画像形式は、撮像センサが作成したデータのほかに、ＪＰＥＧ形式の画像データや、メタデータを保持するＥｘｉｆファイルを含む。情報管理装置１０１は、保存している各画像データの状態を管理している。情報管理装置１０１は、データ記憶部３０６に同一の画像データを重複して保持しない。
【００２２】
ユーザーは情報管理装置１０１を、ＰＣ３０１ｂより信頼性のあるストレージとして利用する。情報管理装置１０１は、全ての画像データを劣化しないＲＡＷ画像データ形式で保管する。想定される実施形態では、情報管理装置１０１はＮＡＳとなる。
【００２３】
情報管理装置１０１に保管したＲＡＷ画像データ全てをユーザーが編集することは稀である。一般的に、ユーザーは撮影した画像の一覧から、編集する画像を選択して、選択した画像だけを編集する。撮影から編集に至るまでの情報管理装置１０１へのデータの入出力は、以下の２種類のケースが想定される。
ケース１：保存後に編集
１、カメラ３０１ａで撮影
２、カメラ３０１ａから情報管理装置１０１に撮影した画像を保存
３、画像編集アプリケーションが動作するＰＣ３０１ｂから情報管理装置１０１にアクセスして、一覧を表示して編集する画像を選択
４、ＰＣ３０１ｂで編集後、編集結果を情報管理装置１０１に保存。
ケース２：編集してから保存
１、カメラ３０１ａで撮影
２、カメラ３０１ａから画像編集アプリケーションが動作するＰＣに撮影した画像を保存
３、ＰＣ３０１ｂで一覧から編集する画像を選択
４、ＰＣ３０１ｂで編集後、編集結果を情報管理装置１０１に保存。
【００２４】
ケース２の場合、ＰＣ３０１ｂ側には新規に撮影した画像データが存在するため、編集する画像選択のためにＰＣ３０１ｂが情報管理装置１０１からデータを取得することはない。一方、ケース１の場合、ＰＣ３０１ｂ側から情報管理装置１０１に、多数の画像データの取得が要求される。ここで、要求された画像データがデータ記憶部３０６よりも高速に読みだせるキャッシュ記憶部３０８に記憶されていれば、情報管理装置１０１はより高速に応答できる。記憶装置１３は、データ記憶部３０６、キャッシュ記憶部３０８を含む。キャッシュ記憶部３０８に記憶されたデータは、データ記憶部３０６に記憶されたデータよりも高速アクセス可能である。
【００２５】
一般的に、キャッシュ記憶部３０８の容量には制限があるため、キャッシュする画像データの選択が課題となる。また、想定しているケースでは、要求された時点でキャッシュされている必要があるため、要求されるデータを予測してキャッシュすることも課題となる。ここでは、これらの課題を解決するために、画像データの保存要求処理時に、キャッシュするデータを選択してキャッシュする。
【００２６】
次に、情報管理装置１０１の画像データの保存要求受信時の動作について説明する。情報管理装置１０１は受信部３０２を備え、クライアントデバイスが送信した画像データ保存要求を受信すると、データ記憶部３０６への画像データの保存とキャッシュ記憶部３０８の更新を開始する。画像データの保存要求には、保存対象データが含まれている。データ記憶部３０６への画像データの保存が終わると、情報管理装置１０１はクライアントデバイスに応答を返し、保存要求の処理は終了する。入力装置１２は、受信部３０２を含み、データの保存要求と保存対象データを受信する。
【００２７】
情報管理装置１０１は、データ記憶部３０６に保存した画像データが編集されていない画像データであれば、今後編集のために取得されると予測してキャッシュ記憶部３０８に保存し、取得要求処理時の読み込みを高速化する。画像データが編集されているかを判断するためには、画像データが含むＥｘｉｆファイルの撮影日時と更新日時を比較することが最も単純である。しかし、画像編集アプリケーションには、画像データ自体を上書きせずに、編集結果や操作履歴をアプリケーション内部のデータベースに保持するものがある。このようなアプリケーションで編集した画像データは、撮影直後のデータと同一なため、データだけでは編集されているかを判定できない。
【００２８】
ここでデータだけでなく、データの保存要求元を参照することで、データが編集されたかどうかを判定する精度を高めることができる。例えば、カメラ３０１ａからの保存要求ならば、データは未編集と判断でき、ＰＣ３０１ｂからの保存要求ならば、未編集と判断できない。保存を要求された画像データが確実に未編集であると判断するために、情報管理装置１０１は、保存を要求したデバイスを入力装置１２から得られる情報に基づいて判定する要求元判定部３０３を備える。すなわち、要求元判定部３０３は、データ保存要求を送信したデバイスはデータの編集が可能であるかを判定する。データ保存要求を送信したデバイスがカメラ３０１ａであれば、データ保存要求を送信したデバイスはデータの編集が不可能であると判定する。また、データ保存要求を送信したデバイスがＰＣ３０１ｂであれば、データ保存要求を送信したデバイスはデータの編集が可能であると判定する。
【００２９】
以降の説明では、画像データの状態として、未編集と判断できる状態を未編集状態、未編集と判断できない状態を通常状態と記す。また、情報管理装置１０１は、保存を要求したデバイスがカメラ３０１ａであれば保存を要求されたデータの状態を未編集状態とし、ＰＣ３０１ｂであれば通常状態とする。
【００３０】
また、情報管理装置１０１は、管理部３０５によって各画像データの状態をテーブルで管理しており、以降このテーブルを画像状態テーブルと記す。画像状態テーブルの例を図６（Ａ）に示す。図６（Ａ）の画像状態テーブル６０１は、データ記憶部３０６に画像データが２つあるときに、各画像データにＩＤ１、２を付与し、画像データ１の状態を未編集、画像データ２の状態を通常として管理している。画像状態テーブル６０１は、情報管理装置１０１から利用できる状態であれば、どのような実施方法でもよい。実施方法の例としては、データ記憶部３０６内に備えるデータベースが挙げられる。
【００３１】
情報管理装置１０１は、保存を要求されたデータと同じデータがデータ記憶部３０６に存在するかを検索して判定するデータ判定部３０４を備える。すなわち、データ判定部３０４は、保存対象データがデータ記憶部３０６に記憶済みのデータと異なる新規のデータであることを判定する。データが同じであるかどうかは、データのＥｘｉｆファイルが含むシリアルナンバーや撮影日時を参照することで判定できる。同じデータが存在しない場合、新規データと判定される。同じデータが存在する場合、新規データでないと判定される。
【００３２】
判定結果は管理部３０５に渡され、新規データであると判定した場合、管理部３０５はデータ記憶部３０６を用いて、データ記憶部３０６にデータを記憶する。新規データでないと判定した場合、データの更新保存が必要と判定したときは、データ記憶部３０６に存在する同じデータを、保存を要求されたデータで上書きする。データの更新保存が必要と判定されるのは、Ｅｘｉｆファイルが含むファイル変更日時が更新されている場合、あるいはデータにレシピが付加されている場合である。
【００３３】
このように、情報管理装置１０１は、保存要求を受信すると、データ判定部３０４による判定結果をもとに、要求されたデータをデータ記憶部３０６に記憶するかどうかを判定する。データ記憶部３０６への記憶が終わると、情報管理装置１０１は、保存要求元に保存要求が完了したことを応答する。また、データ記憶部３０６に記憶しない場合でも、同一データがデータ記憶部３０６にあるため、同様に保存要求が完了したことを応答すればよい。ただし、データ記憶部３０６に記憶しない場合に、保存要求を受け付けなかったと応答してもよい。
【００３４】
さらに、情報管理装置１０１は、保存要求を受信すると、要求元判定部３０３とデータ判定部３０４の判定結果をもとに、管理部３０５の処理を行う。
【００３５】
管理部３０５の動作の概要について、管理手段の処理を示すフローチャート（図４）を用いて説明する。管理手段は、要求元判定部３０３とデータ判定部３０４の判定結果を受け取って処理を開始する。処理では、まずデータ判定部３０４の判定結果に基づいてデータの保存処理を行い、画像状態テーブルの更新を行う（Ｓ４０１）。そして更新した画像状態テーブルを参照して、保存を要求されたデータをキャッシュ記憶部３０８に記憶すると判定した場合、キャッシュするデータの更新制御を行う制御部３０７を用いてキャッシュにデータを書き込む（Ｓ４０２）。キャッシュにデータを書き込む際には、キャッシュに空きがあれば新規に書き込む。キャッシュに空きがなければ、後述する手順によりキャッシュデータの上書き更新を行う。ステップ４０２の処理については、図１０を用いて後述する。
【００３６】
制御部３０７は、ＶＦＳ２０３とファイルシステム２０２と連携し、キャッシュ記憶部３０８に記憶しているデータをデータ記憶部３０６のデータより優先して読み込むようにする。このため、データ記憶部３０６とキャッシュ記憶部３０８に同一のデータがある場合、キャッシュ記憶部３０８のデータが読み込まれる。また、後述する実施例２に示すように、キャッシュ記憶部３０８にのみ存在するデータも、データ記憶部３０６のデータと同様に扱うようにしてもよい。
【００３７】
以上、発明の概要について説明した。以下では、実施例１にかかるステップＳ４０１について、画像状態テーブル更新処理手順を示すフローチャート（図５）を用いて説明する。
【００３８】
初めに、画像状態テーブル更新処理の手順について説明する。情報管理装置１０１は画像データ保存要求を受信すると、要求元判定部３０３によって、保存要求元デバイスが編集可能なデバイスかどうかを判定する（Ｓ５０１）。具体的には、カメラ３０１ａであれば編集不可、ＰＣ３０１ｂであれば編集可と判定する。判定の方法の詳細については、要求元判定部３０３の動作を示すフローチャート（図７）を用いて後述する。また、カメラ３０１ａが編集可であるデバイスの可能性がある場合の判定方法は、実施例３に後述する。
【００３９】
編集可能なデバイスでないと判定すると、保存を要求されたデータがデータ記憶部３０６に記憶済みのデータと異なる新規のデータであるかをデータ判定部３０４によって判定する（Ｓ５０２）。新規データでないと判定した場合、保存要求されたデータのＥｘｉｆファイルが含むファイル変更日時が更新されている、あるいはデータにレシピが付加されている場合は、上書き保存が必要と判定する（Ｓ５０３）。
【００４０】
ステップＳ５０３で上書き保存が必要と判定した場合は、データ記憶部３０６を用いてデータを保存する（Ｓ５０４）。ステップＳ５０４の処理が終わると、画像状態テーブルの更新は終了する。ステップＳ５０３で上書き保存が必要と判定しなかった場合は、画像状態テーブルの更新処理を終了する。
【００４１】
ステップＳ５０２において新規データと判定した場合、データにＩＤを割り当てて、未編集状態として画像状態テーブルに追加し、テーブルを更新することにより、データに付与された状態を管理する（Ｓ５０５）。そして、ステップＳ５０４以降の処理を行う。
【００４２】
Ｓ５０１において、保存要求元が編集可能なデバイスと判定された場合も、保存要求されたデータが新規データであるか判定する（Ｓ５０６）。新規データでないと判定したとき、保存要求されたデータと同一のデータの状態を、画像状態テーブルを参照して確認する（Ｓ５０７）。状態が通常状態であれば、ステップＳ５０３以降の処理を行う。一方、状態が未編集状態であれば、保存要求されたデータと同一のデータの状態を通常に変更し、画像状態テーブルを更新する（Ｓ５０８）。そして、ステップＳ５０３以降の処理を行う。
【００４３】
ステップＳ５０６において、新規データと判定した場合、データにＩＤを割り当てて、通常状態として画像状態テーブルに追加し、テーブルを更新する（Ｓ５０９）。そして、ステップ５０４以降の処理を行う。
【００４４】
次に、要求元判定部３０３の具体的な動作について、要求元判定部３０３の動作を示すフローチャート（図７）を用いて説明する。要求元判定部３０３は、ステップＳ５０１において、保存要求元が編集可能であるかを判定するために用いられる。また、要求元判定部３０３は、デバイスＩＤやＭＡＣアドレスからデバイスの種類を特定するためのデータベースをもつ。
【００４５】
要求元判定部３０３は、要求を入力した入力装置１２のインタフェースがＵＳＢインタフェースであるかを判定する（Ｓ１００１）。すなわち、要求を受信した受信部３０２がＵＳＢインタフェースであるかを判定する。ＵＳＢと判定した場合、ＵＳＢ接続規格で定義されているデバイスＩＤとデータベースを参照することで、デバイスがカメラであるかを特定する（Ｓ１００２）。デバイスＩＤがカメラであれば、編集不可と判定する（Ｓ１００３）。カメラでないなら編集可と判定する（Ｓ１００４）。
【００４６】
ステップＳ１００１でＵＳＢでないと判定した場合、要求を入力した入力装置１２のインタフェースがＬＡＮインタフェースであるかを判定する（Ｓ１００５）。ＬＡＮインタフェースはネットワークインタフェースの一例である。ＬＡＮインタフェースであると判定した場合、ＭＡＣアドレスとデータベースを参照することで、デバイスがカメラであるかを判定する（Ｓ１００６）。ＭＡＣアドレスがカメラであれば、編集不可と判定する（Ｓ１００７）。カメラでないなら編集可と判定する（Ｓ１００８）。
【００４７】
ステップＳ１００５でＬＡＮでないと判定した場合、編集不可と判定する（Ｓ１００９）。これは、実施例１では他にデータ保存要求を入力する手段がないためである。要求を入力した入力装置１２のインタフェースがＵＳＢでもＬＡＮでもなければ、必ずＳＤカードスロットインタフェースであるため、ステップＳ１００９は編集不可と判定する。すなわち、入力装置１２は、ＵＳＢインタフェース、ＬＡＮインタフェース、ＳＤカードスロットインタフェースを有し、受信部３０２がどのインタフェースから要求を受信したか判定する。
【００４８】
以上、実施例１にかかるステップＳ４０１について説明した。次に、実施例１にかかるステップＳ４０２について、制御部３０７の処理を示すフローチャート（図１０）を用いて説明する。
【００４９】
新規画像データの保存要求の処理において、管理部３０５が画像状態テーブルを更新したとき、制御部３０７はキャッシュ対象データをキャッシュ記憶部３０８に記憶するために、キャッシュの更新処理を開始する。キャッシュ対象データは、新規画像データである。
【００５０】
制御部３０７は、まずキャッシュ記憶部３０８にキャッシュ対象データを追加する空きがあるかを確認する（Ｓ１３０１）。キャッシュに空きがある場合、キャッシュにキャッシュ対象データを書き込み（Ｓ１３０２）、キャッシュの更新処理は終了する。
【００５１】
ステップＳ１３０１において空きがなかった場合、キャッシュ対象データが未編集状態かを画像状態テーブルを参照して判定する（Ｓ１３０３）。画像状態テーブルには、保存対象データが新規のデータであるか、及び、データ保存要求を送信したデバイスはデータの編集が可能であるかを元にデータに付与されたデータの状態が管理されている。キャッシュ対象データが未編集状態の場合、キャッシュされているデータと画像状態テーブルを参照して、通常状態のデータがキャッシュされているかを判定する（Ｓ１３０４）。通常状態のデータがキャッシュされていれば、通常状態のデータをキャッシュ対象データに入れ替える（Ｓ１３０５）。通常状態のデータが複数ある場合に、入れ替える通常状態のデータを選択する方法としては、ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ  Ｆｉｒｓｔ−Ｏｕｔ）方式などが挙げられる。このように、未編集状態の画像を通常状態の画像に優先して格納する。
【００５２】
ステップＳ１３０４において、通常状態のデータが含まれていない場合、キャッシュされている未編集状態のデータをキャッシュ対象データで入れ替える（Ｓ１３０６）。入れ替え対象となる未編集状態のデータを選択する方法は、ステップＳ１３０５と同様である。
【００５３】
ステップＳ１３０３において、キャッシュ対象データが通常状態であった場合、キャッシュに通常状態のデータが含まれるかを判定する（Ｓ１３０７）。通常状態のデータが含まれていれば、ステップＳ１３０５以降の処理を行う。通常状態のデータが含まれていなければ、キャッシュの更新処理を終了する。すなわち、未編集状態の画像を通常状態の画像に優先して格納する。このように、制御部３０７は、保存対象データが新規のデータであるか、及び、データ保存要求を送信したデバイスはデータの編集が可能であるかに基づいてキャッシュ記憶部３０８上のデータを更新制御する。
【００５４】
このように、データ判定部３０４は、保存対象のデータがデータ記憶部３０６に記憶済みのデータと異なる新規のデータであることを判定し、要求元判定部３０３は、データ保存要求を送信したデバイスはデータの編集が可能であるかを判定する。そして、制御部３０７は、データ判定部３０４と要求元判定部３０３の判定結果に基づいて、キャッシュ上（キャッシュ記憶部３０８）上のデータを更新制御する。
【００５５】
以上、キャッシュ記憶部３０８に記憶する画像データの形式とデータ記憶部３０６に記憶する画像データの形式がともにＲＡＷ形式の場合の実施例を説明したが、本発明はこれにとどまるものではない。画像編集アプリケーションがＲＡＷ形式のファイル全てを必要とするのは、実際に編集を行うときであり、一覧表示にはＲＡＷ形式のファイルが内包するＪＰＥＧ画像データだけで十分である。そのため、一覧表示において、画像編集アプリケーションは情報管理装置１０１にＪＰＥＧ形式の画像データを要求し、キャッシュ記憶部３０８にはＪＰＥＧ形式の画像データのみを記憶することで、より多くの画像データをキャッシュすることが可能となる。
【００５６】
キャッシュ記憶部３０８にはＪＰＥＧ形式の画像データのみを記憶し、画像編集アプリケーションが一覧表示のためにＪＰＥＧ形式の画像データを要求する実施例を、実施例２として説明する。
【００５７】
＜実施例２＞
次に、実施例２にかかる情報管理装置１０１の動作について説明する。情報管理装置１０１は、データ記憶部３０６にはＲＡＷ形式の画像データを記憶し、キャッシュ記憶部３０８には、ＪＰＥＧ形式の画像データを記憶する。例えば、画像データｉｍａｇｅ１．ＲＡＷの保存要求を受信したとする。このとき、ステップ４０２においてｉｍａｇｅ１．ＲＡＷをキャッシュすると決定した場合、データ記憶部３０６にｉｍａｇｅ１．ＲＡＷを記憶するとともに、キャッシュ記憶部３０８にｉｍａｇｅ１．ＲＡＷが内包しているｉｍａｇｅ１．ＪＰＥＧを記憶する。
【００５８】
また、ＰＣ３０１ｂで動作する画像編集アプリケーションは、ファイル共有サービスを用いて情報管理装置１０１を利用する。画像編集アプリケーションは、画像の一覧表示のために、情報管理装置１０１からファイル名一覧を取得後、各ファイルのデータを要求する。ファイル名一覧に同一画像のＲＡＷ形式とＪＰＥＧ形式のファイルが含まれる場合、画像編集アプリケーションはＪＰＥＧ形式のファイルを指定してデータを要求する。ＲＡＷ形式のファイルしかなければ、ＲＡＷ形式のファイルを指定してデータを要求する。
【００５９】
以下に、画像アプリケーションが一覧表示のためのデータを情報管理装置１０１から取得する方法について説明する。
【００６０】
情報管理装置１０１はｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷをデータ記憶部３０６に記憶済みであるとする。また、キャッシュ記憶部３０８にｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷが内包するＪＰＥＧ形式の画像データｉｍａｇｅ１．ＪＰＥＧ、ｉｍａｇｅ２．ＪＰＥＧを記憶しているとする。このとき、ファイルシステム２０２には、ｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷ、ｉｍａｇｅ１．ＪＰＥＧ、ｉｍａｇｅ２．ＪＰＥＧが登録されている。
【００６１】
一覧表示において、画像編集アプリケーションは最初に、一覧を表示したいディレクトリを指定して、ディレクトリに含まれるファイル名一覧を要求する。指定したディレクトリには、ｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷが含まれているとする。このとき、情報管理装置１０１は、応答するファイル名一覧に、ｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷを加える。さらに、ｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷに対応するＪＰＥＧ形式のファイル名ｉｍａｇｅ１．ＪＰＥＧ、ｉｍａｇｅ２．ＪＰＥＧも一覧に加えて、画像編集アプリケーションに応答する。
【００６２】
画像編集アプリケーションは、ファイル名一覧を受信すると、画像一覧表示のためにｉｍａｇｅ１．ＪＰＥＧとｉｍａｇｅ２．ＪＰＥＧを情報管理装置１０１に要求する。情報管理装置１０１は、キャッシュ記憶部３０８からｉｍａｇｅ１．ＪＰＥＧとｉｍａｇｅ２．ＪＰＥＧのデータを読み出して、応答する。
【００６３】
画像編集アプリケーションは、応答に含まれるデータを表示し、一覧表示は終了する。
【００６４】
キャッシュ記憶部３０８にｉｍａｇｅ１．ＪＰＥＧしか含まれていない場合には、画像編集アプリケーションが取得するファイル名一覧は、ｉｍａｇｅ１．ＲＡＷ、ｉｍａｇｅ２．ＲＡＷ、ｉｍａｇｅ１．ＪＰＥＧとなる。この場合、画像編集アプリケーションは一覧表示のために、ｉｍａｇｅ１．ＪＰＥＧとｉｍａｇｅ２．ＲＡＷを情報管理装置１０１に要求する。
【００６５】
以上、キャッシュ記憶部３０８にはＪＰＥＧ形式の画像データのみを記憶し、画像編集アプリケーションはＪＰＥＧ形式の画像データを要求する実施例を示したが、本発明はこれにとどまるものではない。要求元判定部３０３が用いるデータベースは、情報管理装置１０１から利用できれば、どこにあっても構わず、認識するデバイスをカメラに限る必要もない。例えば、保存を要求したデバイスを画像の編集ができないポータブルＮＡＳと特定すれば、編集不可と判定できる。また、画像を編集できるカメラと特定すれば、カメラであっても編集可と判定できる。
【００６６】
要求元判定部３０３が、編集可のデバイスと編集不可のデバイスの判定を、より詳細に行う実施例を実施例３として説明する。
【００６７】
＜実施例３＞
次に、実施例３にかかる要求元判定部３０３の動作について説明する。要求元判定部３０３は、デバイスＩＤやＭＡＣアドレスからデバイスの種類を特定するためのデータベースをもつ。データベースには、デバイスＩＤとＭＡＣアドレスに対応するデバイスが、編集可か編集不可かを示す情報が登録されている。
【００６８】
要求元判定部３０３は、データ保存要求元デバイスのデバイスが編集可能なデバイスであるかどうかを、データベースを参照して判定する。
【００６９】
例えば、昔に発売された画像を編集できない機種のカメラであれば編集不可、最近発売された編集できる機種のカメラであれば編集可と判定する。また、ポータブルＮＡＳには画像の編集機能を備えるものもあるため、接続デバイスの機種を特定することで、要求元判定部３０３は、より正確に判定を行える。
【００７０】
以上、要求元判定部３０３が、デバイスＩＤやＭＡＣアドレスからデバイスの種類を詳細に特定する実施例を説明したが、本発明はこれにとどまるものではない。インタフェースがＬＡＮであり、データ保存要求がＨＴＴＰプロトコルである場合、ＨＴＴＰプロトコルメッセージのヘッダを用いると、要求元判定部３０３の判定を容易に行える。また、画像データ自体の変更を行う画像編集アプリケーションが利用された場合には、Ｅｘｉｆを参照することで、画像が編集されたことを容易に判定できる。
【００７１】
データ保存要求元のデバイス情報だけでなく、保存要求および保存を要求するデータそのものに含まれる情報を利用できる場合の要求元判定部３０３の実施例を、実施例４に示す。
【００７２】
＜実施例４＞
次に、実施例４にかかる要求元判定部３０３の動作を示すフローチャート（図８）を用いて説明する。図８は、データ保存要求元のデバイス情報だけでなく、保存要求および保存を要求するデータそのものに含まれる情報を利用できる場合の要求元判定部３０３の実施例である。図１１では、データ保存要求元が編集可能かどうかを判定する条件を、信頼性の高いものから確認している。
【００７３】
情報管理装置１０１を利用するクライアントデバイスの例として、ユーザーが外出先で撮影した画像データを保管するクラウドサービスを考える。情報管理装置１０１はユーザーのオフィスに設置されているものとする。外出先のカメラが写真をクラウドサービスに保管し、クラウドが情報管理装置１０１と同期する場合、情報管理装置１０１はクラウドサービスからＨＴＴＰプロトコルによってデータの保存要求を受信する。ＨＴＴＰプロトコルメッセージには、各種ヘッダが含まれる。
【００７４】
Ｖｉａヘッダのようなメッセージの経路を示すヘッダを参照すれば、要求元判定部３０３は、保存要求がクラウドサービスからなされたことを識別できる。そのため、クラウドサービスが画像の保管しかできないものであれば、編集不可デバイスと判定し、画像の編集もできるクラウドサービスであれば編集可デバイスと判定する。また、ＨＴＴＰプロトコルメッセージのヘッダは独自に拡張できるため、画像の編集もできるクラウドサービスが実際に画像を編集したかを示すフラグをヘッダに含めることで、判定の精度をより高めることも考えられる。
【００７５】
また、画像を編集するアプリケーションが画像データを更新し、保存を要求されたデータのＥｘｉｆに含まれる作成日時と更新日時が異なる場合、そのデータは編集されたと判定できる。
【００７６】
また、画像を編集するアプリケーションには、Ｅｘｉｆにレシピと呼ばれる編集操作ログのみを付加するものもある。そのため、保存を要求されたデータにレシピが含まれていれば、編集されたと判定できる。
【００７７】
上記の判定方法を用いて、データ保存要求元デバイスが編集可か編集不可かを判定する動作について、図８を用いて説明する。
【００７８】
要求元判定部３０３は、保存要求を受信すると、ヘッダに編集可・編集不可を示す情報が含まれているか確認する（Ｓ１１０１）。情報が含まれていれば、その情報が編集可を示すかを判定する（Ｓ１１０２）。編集可を示す場合、編集可と判定する（Ｓ１１０３）。編集可を示さない場合、編集不可と判定する（Ｓ１１０４）。
【００７９】
ステップＳ１１０１で情報が含まれていなければ、保存を要求された画像データが含むＥｘｉｆの作成日時と更新日時を確認する（Ｓ１１０５）。作成日時と更新日時が異なれば、編集可と判定する（Ｓ１１０６）。
【００８０】
ステップＳ１１０５で作成日時と更新日時が同じであれば、Ｅｘｉｆにレシピが含まれているかを確認する（Ｓ１１０７）。レシピが含まれていれば、編集可と判定する（Ｓ１１０８）。
【００８１】
ステップＳ１１０７でレシピが含まれていなければ、Ｓ１１０９からＳ１１１７は、図７のＳ１００１からＳ１００９と同様の処理を行う。
【００８２】
以上、保存要求および保存を要求するデータそのものに含まれる情報を利用できる場合の実施例について説明したが、本発明はこれにとどまるものではない。画像データの状態は、優先してキャッシュすべき画像データを選択するために用いる。これは、キャッシュ記憶部３０８に全ての画像データをキャッシュすると必要な容量が多くなってしまうためである。画像データの状態は、キャッシュする・キャッシュしないというフラグではなく、キャッシュする画像データの優先度を決定するために用いるので、状態は２種類に限らない。
【００８３】
ＨＴＴＰメッセージのヘッダや画像データのＥｘｉｆによって、編集されたことを確実に判定できる場合、編集されたことを保証する編集状態を画像状態テーブルで扱うことができる。画像データの状態を、未編集状態、判定不能状態、編集状態の３種類にした場合の実施例を、実施例５に示す。
【００８４】
＜実施例５＞
次に、実施例５にかかる画像状態テーブルの例を示す図（図６（Ｂ））を用いて説明する。図６（Ｂ）の画像状態テーブル７０１は、管理部３０５が管理する画像データの状態が、未編集状態、判定不能状態、編集状態の３種類であるときの例である。画像データが編集状態と判定されるのは、以下の３つのいずれかの場合である。
【００８５】
ひとつ目の場合は、ステップＳ１１０２において保存要求メッセージに編集したことを示すヘッダが付加されていた場合である。二つ目の場合は、ステップＳ１１０３において撮影日時と更新日時が異なる場合である。三つ目の場合は、ステップＳ１１０５においてレシピが含まれる場合である。以上３つのいずれかの場合には、画像データの状態は編集状態となる。
【００８６】
画像データが未編集状態と判定されるのは、上記の編集状態と判定される場合のいずれでもなく、かつ保存要求が編集不可のデバイスからなされた場合である。
【００８７】
画像データが判定不能状態と判定されるのは、編集状態とも未編集状態とも判定されない場合である。
【００８８】
ステップＳ４０２において、キャッシュする画像データの入れ替えを、編集状態、判定不能状態、未編集状態の順に試みる。こうすることで、キャッシュサイズが限られている場合に、編集可能なデバイスから要求される可能性が高い画像データがキャッシュに残りやすくなる。すなわち、キャッシュ記憶部３０８には未編集状態、判定不能状態、編集状態の優先順位で画像を格納する。
【００８９】
実施例５にかかるステップＳ４０２の動作を、制御手段の処理を示すフローチャート（図１１）を用いて説明する。
【００９０】
新規画像データの保存要求の処理において、管理部３０５が画像状態テーブルを更新したとき、制御部３０７はキャッシュ対象データをキャッシュ記憶部３０８に記憶するために、キャッシュの更新処理を開始する。キャッシュ対象データは、新規画像データである。
【００９１】
ステップＳ１４０１、Ｓ１４０２、Ｓ１４０３は、図１０のＳ１３０１、Ｓ１３０２、Ｓ１３０３と同様である。
【００９２】
ステップＳ１４０３において、キャッシュ対象データを未編集状態と判定したとき、キャッシュされているデータと画像状態テーブルを参照して、編集状態のデータがキャッシュされているかを判定する（Ｓ１４０４）。編集状態のデータがキャッシュされていれば、通常状態のデータをキャッシュ対象データに入れ替える（Ｓ１４０５）。キャッシュされていなければ、判定不能状態のデータがキャッシュされているかを判定する（Ｓ１４０６）。
【００９３】
ステップＳ１４０６において、判定不能状態のデータがキャッシュされていれば、判定不能状態のデータをキャッシュ対象データに入れ替える（Ｓ１４０７）。判定不能状態のデータがキャッシュされていなければ、未編集状態のデータをキャッシュ対象データに入れ替える（Ｓ１４０８）。
【００９４】
ステップＳ１４０３において、キャッシュ対象データが未編集状態でないと判定した場合、判定不能状態であるかを判定する（Ｓ１４０９）。判定不能状態であると判定した場合、キャッシュに編集状態のデータが含まれているかを確認する（Ｓ１４１０）。編集状態のデータが含まれている場合、ステップＳ１４０５以降の処理を行う。編集状態のデータが含まれていない場合、ステップＳ１４０７以降の処理を行う。
【００９５】
ステップＳ１４０９において、キャッシュ対象データが判定不能状態でないと判定した場合、キャッシュに編集状態のデータが含まれているかを確認する（Ｓ１４１１）。編集状態のデータが含まれている場合、ステップＳ１４０５以降の処理を行う。編集状態のデータが含まれていない場合、キャッシュ更新処理を終了する。
【００９６】
以上、画像データの状態が３種類である場合の実施例を説明したが、本発明はこれにとどまるものではない。キャッシュの目的は、編集可能なデバイスから画像データの取得を要求された時に、高速に応答するためである。そのため、編集可能なデバイスが取得済みのキャッシュデータを新規データと入れ替えることで、キャッシュのヒット率を上げることができる。外部のデバイスが取得済みであることを示すフラグを管理部３０５が管理する場合の実施例を、次の実施例６に示す。
【００９７】
＜実施例６＞
次に、実施例６にかかる画像状態テーブルの例を示す図（図６（Ｃ））を用いて説明する。図６（Ｃ）の画像状態テーブル８０１では、管理部３０５が管理する画像データの状態が、未編集状態、通常状態の２種類であり、各画像データの状態には外部のデバイスから取得されたかどうかを示す未取得フラグも含まれている。未取得フラグがＯＮであれば、外部のデバイスから取得されていないことを示し、ＯＦＦであれば取得されたことを示す。
【００９８】
情報管理装置１０１はデータ保存要求を受け取ると、ステップＳ５０１において、編集可能なデバイスからの保存要求と判定した場合は未取得フラグをＯＦＦにし、編集不可能なデバイスからの保存要求であると判定した場合は未取得フラグをＯＮにする。その上で、画像状態テーブルを更新する。ただし、未取得フラグがＯＮになるのは、画像状態テーブルに新規の画像データを追加するときのみである。画像状態テーブルに登録済みの画像データの未取得フラグは、ＯＦＦになったのちに再度ＯＮになることはない。
【００９９】
情報管理装置１０１は外部デバイスからデータ取得要求を受けると、要求されたデータを応答する。このとき、応答したデータがキャッシュ記憶部３０８に記憶されているものであれば、管理部３０５は画像状態テーブルの未取得フラグをＯＦＦにする。
【０１００】
次に実施例６にかかるステップＳ４０２の動作を、制御手段の処理を示すフローチャート（図１２）を用いて説明する。
【０１０１】
情報管理装置１０１が、ステップＳ４０２において最も優先する画像データは、状態が未編集かつ未取得フラグがＯＮのものである。次に優先する画像データは、未編集かつ未取得フラグがＯＦＦのものである。その次に優先するのは、通常かつ未取得フラグがＯＮの画像データである。その次に優先するのは、通常かつ未取得フラグがＯＦＦの画像データである。
【０１０２】
ステップＳ１５０１、Ｓ１５０２、Ｓ１５０７―Ｓ１５１１は、図１０のＳ１３０１―Ｓ１３０７と同様である。
【０１０３】
ステップＳ１５０１においてキャッシュに空きがない場合、キャッシュに未取得フラグがＯＦＦかつ通常状態のデータが含まれるかを判定する（Ｓ１５０３）。含まれると判定した場合、未取得フラグがＯＦＦかつ通常状態のデータをキャッシュ対象データに入れ替える（Ｓ１５０４）。
【０１０４】
ステップＳ１５０３において含まれないと判定した場合、キャッシュに未取得フラグがＯＦＦかつ未編集状態のデータが含まれるかを判定する（Ｓ１５０５）。含まれると判定した場合、未取得フラグがＯＦＦかつ未編集状態のデータをキャッシュ対象データに入れ替える（Ｓ１５０６）。
【０１０５】
以上、外部のデバイスが取得済みであることを示すフラグを管理部３０５が管理する場合の実施例を説明したが、本発明はこれにとどまるものではない。情報管理装置１０１が保持するデータをグループ化することで、キャッシュ記憶部３０８に保存する画像データをより柔軟に選択する実施例を実施例７で説明する。
【０１０６】
＜実施例７＞
実施例７にかかる管理部３０５の動作を示すフローチャート（図９）を用いて説明する。
【０１０７】
情報管理装置１０１は画像データ保存要求を受信すると、後述する分類方法によって、保存を要求された画像が所属するグループを決定する（Ｓ１２０１）。一つの画像は複数のグループに所属してもよい。その上で、ステップＳ５０１と同様に、保存要求元デバイスが編集可能なデバイスかどうかを判定する（Ｓ１２０２）。編集可能なデバイスでないと判定すると、ステップＳ５０２、Ｓ５０３、Ｓ５０４と同様の処理をステップＳ１２０３、Ｓ１２０４、Ｓ１２０５で行う。
【０１０８】
ステップＳ１２０３において新規データと判定した場合、データにＩＤとグループを割り当てて、未編集状態として画像状態テーブルに追加し、テーブルを更新する（Ｓ１２０６）。図９に、実施例７にかかる画像状態テーブルを示す。画像状態テーブルは図６（Ｄ）のように、ＩＤ、状態、所属グループの要素をもつ。ステップＳ１２０６でテーブルを更新すると、ステップＳ１２０５以降の処理を行う。
【０１０９】
Ｓ１２０２において、保存要求元が編集可能なデバイスと判定された場合も、保存要求されたデータが新規データであるか判定する（Ｓ１２０７）。新規データでないと判定したとき、保存要求されたデータと同一のデータの状態を、画像状態テーブルを参照して確認する（Ｓ１２０８）。状態が通常状態であれば、ステップＳ１２０４以降の処理を行う。一方、状態が未編集状態であれば、保存要求されたデータと同一のデータの状態を通常に変更し、画像状態テーブルを更新する（Ｓ１２０９）。そして、ステップＳ１２０４以降の処理を行う。
【０１１０】
ステップＳ１２０７において、新規データと判定した場合、データにＩＤとグループを割り当てて、通常状態として画像状態テーブルに追加し、テーブルを更新する（Ｓ１２１０）。そして、ステップＳ１２０５以降の処理を行う。
【０１１１】
次に、画像の分類方法について説明する。情報管理装置１０１が保存するデータはＲＡＷ画像形式である。一般的なカメラで撮影した画像データには、撮影日時、撮影デバイスＩＤなどの情報がＥｘｉｆとして含まれる。また、ユーザーが入力したタイトルや、ＧＰＳによる位置情報が含まれることもある。これらの情報を用いて画像データを分類する規則を用いれば、情報管理装置１０１は保持している画像データをグループ化することが可能である。分類は、各画像データの特徴量を用いることもありえる。
【０１１２】
画像データをグループ化することで、キャッシュする画像データをグループ単位で選択することが可能となり、キャッシュの入れ替えが効率よく行える。
【０１１３】
例えば、画像データが撮影日の日付のフォルダに格納されている場合を考える。データ記憶部３０６内の２０１０−０１−０１フォルダには１００枚の画像データが存在し、２０１０−０１−０２フォルダにも別の１００枚の画像データがあるとする。各フォルダ内の画像データの状態は、すべて未編集状態とする。また、キャッシュ記憶部３０８には、それぞれのフォルダの画像データ２００枚がキャッシュされているとする。画像編集アプリケーションはフォルダを指定し、フォルダ内の画像一覧を取得し、選択した画像を編集してＮＡＳに上書き保存する。管理部３０５は、２０１０−０１−０１フォルダの画像データをグループ１、２０１０−０１−０２フォルダの画像データをグループ２として管理している。
【０１１４】
ここで、画像編集アプリケーションが、２０１０−０１−０１フォルダを指定して画像一覧を取得し、１枚の画像を編集してＮＡＳに上書き保存したとする。すると、管理部３０５は、上書き保存の要求を受信すると、ステップＳ１２０９において上書き保存された画像データの状態を通常に更新する。
【０１１５】
画像データ単位でキャッシュする画像データを選択する場合、管理部３０５は、ステップＳ４０２において、上書き保存された画像データ１枚しかキャッシュから削除しえない。
【０１１６】
一方、グループ単位でキャッシュする画像データを選択すれば、１枚の画像データの状態が更新された時に、複数の関連する画像データもキャッシュから削除することができる。例えば、グループに含まれる未編集状態の画像データの割合をスコアとし、スコアが高いグループに属する画像データを優先してキャッシュすることが考えられる。上記の例では、上書き保存後に、グループ１のスコアは０．９９、グループ２のスコアは１となるため、グループ１の画像データを削除することが可能となる。
【０１１７】
画像をグループ化する実施例７にかかるステップＳ４０２について、制御部３０７の処理を示すフローチャート（図１３）を用いて説明する。
【０１１８】
キャッシュの更新において、まず各グループのスコアを更新し、スコアによって降順にグループをソートする（Ｓ１６０１）。また、キャッシュ記憶部３０８が保持する記憶容量のサイズをキャッシュ空き容量Ｍとして記憶する（Ｓ１６０２）。
【０１１９】
次に、ソートしたグループでまだ走査していない先頭のグループを、走査対象グループとして設定する（Ｓ１６０３）。走査対象グループを設定すると、走査対象グループに属する画像データをキャッシュするために必要な記憶領域サイズをキャッシュサイズＳとして取得する（Ｓ１６０４）。
【０１２０】
次に、キャッシュ容量ＭがキャッシュサイズＳより大きいかを判定する（Ｓ１６０５）。ＭがＳより小さい値であれば、ステップＳ１６０８に進む。ＭがＳ以上の値であれば、ＭをＭ−Ｓの値で更新する（Ｓ１６０６）。そして、走査対象グループをキャッシュ対象グループリストに登録する（Ｓ１６０７）。
【０１２１】
登録すると、全グループの最下位まで走査済み、あるいはキャッシュ容量Ｍが０であるかを判定する（Ｓ１６０８）。
【０１２２】
ステップＳ１６０８において判定結果が偽であれば、ステップｓ１６０３以降の処理を再度行う。ステップＳ１６０８において判定結果が真であれば、キャッシュ対象グループリストに登録されたグループをキャッシュ記憶部３０８に記憶する（Ｓ１６０９）。記憶したのち、キャッシュ更新を終了する。
【０１２３】
このように、画像データをグループ化することで、各グループの画像データの状態をもとに、キャッシュ記憶部３０８に優先して保存する画像データをグループ単位で選択することができる。グループに含まれる未編集状態の画像データの割合をスコアとすると、図９において、グループＡのスコアは１、グループＢのスコアは０、グループＣのスコアは０．５となる。そのため、キャッシュするグループは、Ａ、Ｃ、Ｂの優先順位で選択される。このように、グループ単位で選択することで、未編集状態の画像データを多く含むグループを優先してキャッシュできる。
【０１２４】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【図１】
2016085522.tif 000003
【図２】
2016085522.tif 000004
【図３】
2016085522.tif 000005
【図４】
2016085522.tif 000006
【図５】
2016085522.tif 000007
【図６】
2016085522.tif 000008
【図７】
2016085522.tif 000009
【図８】
2016085522.tif 000010
【図９】
2016085522.tif 000011
【図１０】
2016085522.tif 000012
【図１１】
2016085522.tif 000013
【図１２】
2016085522.tif 000014
【図１３】
2016085522.tif 000015