JP2008538627A - ローカル・サムネイル・キャッシュ - Google Patents

Abstract

【課題】 ユーザ毎／システム毎のサムネイル・キャッシュにサムネイル画像を格納し検索するシステムおよび方法を提供する。
【解決手段】 １つ以上のデータ・ファイルを用いて、様々なサイズのサムネイル画像を格納することができる。個々のファイルに対するサムネイルの１つまたは複数の位置でインデックスを更新し、そのＵＲＬおよび変更時間をキーとして用いて、インデックス内においてサムネイルを発見することができる。サムネイル画像の直接メモリ・マッピングを備えている。同時技法を利用して、多数のプロセス間でキャッシュへの協同アクセスを維持する。キャッシュ内容が孤立していたり使用されていない場合には、これらよりも新しいサムネイル画像または頻繁に用いられるサムネイル画像を用いるために回収される。
【選択図】 図１

Description

本発明は、コンピュータ上における画像のキャッシュ処理に関する。更に特定すれば、本発明は、システム全体のサムネイル画像データベースにおける画像のキャッシュ方法およびシステムを提供する。

サムネイル画像は、実際に画像またはファイルを開くことを必要とせずに、その画像またはファイルの内容を伝達するためにコンピュータ上で広く用いられている方式である。サムネイルは、画像、ワープロ文書、ウェブ・ページ、プレゼンテーション用スライド等を微小化した描写を提示することができる。サムネイルは、グラフィカル・オペレーティング・システムにおいてファイルを表すために頻繁に用いられている。

図２Ａは、グラフィカル・オペレーティング・システムにおける従来技術のサムネイルの使用例を示す。ウィンドウ２０１は、共通ファイル・ディレクトリに収容されているＪＰＥＧフォーマット・ファイル２０２の集合体のサムネイル画像を表示する。各サムネイル画像は、ファイルの内容の複製であり、標準的なサイズに合わせて大きさを変更してある。特定の１ファイルを選択すると、ウィンドウ２０１は選択したファイルのサムネイル２０３を表示する。

図２Ｂは、コンピュータ１１０に利用可能なファイル階層２０５における従来技術のサムネイル記憶の一例を示す。ファイル階層２０５内に表されているファイルは、コンピュータ１１０上（例えば、ハード・ドライブ上またはダイナミック・メモリ内）、リムーバブル媒体（例えば、フロッピ・ドライブまたはＵＳＢサムドライブ）上、ネットワーク・サーバ上、またはそれ以外のコンピュータ１１０にアクセス可能な場所に格納することができる。ファイル階層２０５内部にあるファイルは、ファイル・フォルダのシステムを用いて、階層状に格納することができる。ファイル・フォルダは、ファイルおよびその他のファイル・フォルダを収容する。第１ファイル・フォルダ２１１はファイルの第１集合体２１２を格納し、第２ファイル・フォルダ２２１は第２ファイル集合体２２２を格納する。

従来の方法論を用いると、コンピュータ１１０上のオペレーティング・システムは、ファイル・フォルダ２１１、２２１内にファイルのサムネイルを作成する。例えば、ウィンドウ２０１のフォルダ・ビューを作成するには、オペレーティング・システムは、各ファイルを繰り返し見渡し、その内容を走査し、内容の標準サイズの複製を発生することによって、ファイルのサムネイルを作成することができる。オペレーティング・システムによっては、個々のサムネイル集合が必要となる毎に、このステップを繰り返す場合もある。別のオペレーティング・システムでは、サムネイルを１回だけ発生し、次いでグラフィカル・ファイル（ビットマップまたはＪＰＥＧ）として格納し、その後検索することができるようにしている。このようなシステムは、今後のサムネイル検索のための処理時間を節約する。コンピュータ１１０は、以前に描出したサムネイルを、サムネイル・キャッシュ２１４、２２４に格納する。

第１サムネイル・キャッシュ２１４は、第１集合体２１２におけるファイルの各々についてサムネイルを収容することができる。呼び出されたときにはいつでも、第１サムネイル・キャッシュ２１４はオペレーティング・システムまたは第三者であるソフトウェアのいずれかによる使用のために、これらの画像を供出することができる。同様に、第２サムネイル・キャッシュ２２４は、要求に応じて、第２集合体２２２からの画像を提出することができる。このようにフォルダ毎にサムネイルを格納することは、単純であるが、コンピュータ１１０のユーザにとって問題が発生する可能性がある。

現行の方法論を用いると、コンピュータ１１０が発生したサムネイルを格納できるのは、それが書き込みアクセスすることができるファイル・フォルダだけである。例えば、コンピュータ１１０のユーザがリード・オンリＣＤ−ＲＯＭ上に格納されている画像を閲覧する場合、発生したサムネイルを今後の再利用のために格納することができない。何故なら、オペレーティング・システムはＣＤ−ＲＯＭ上に格納されているファイル・フォルダ内にサムネイル・キャッシュを作成することができないからである。加えて、現行の方法論では、機密ファイルに対する安全なアクセスがないがしろにされている場合がある。例えば、スライド・プレゼンテーション２２３の所有者が、コンピュータ１１０の他のいずれのユーザにもアクセス不可能なファイルを作成したとしても、他のユーザは、オペレーティング・システムが発生し第２サムネイル・キャッシュ２２４に格納したサムネイルを見ることができてしまう。これはプレゼンテーション・スライドの微小化バージョンに過ぎないが、サムネイルだけでも機密情報を開示するのに十分であることもあり得る。サムネイル画像の大きさおよび詳細が拡大する程、このようなセキュリティ上の問題は増々心配の種となる。

従来のサムネイル・システムでは、サムネイル・コンテンツを表示するために複製するにつれて、サムネイル画像の多数のコピーをメモリ内に作成させるので、必要以上のメモリを利用している。また、むやみにサムネイル・キャッシュを格納することにより、使用頻度が少ないサムネイルを識別して間引きすることがし難くなっている（例えば、追加のディスク空間を必要とするとき）。更に、コンピュータ１１０のユーザが、多数のディレクトリからのファイルを含むファイル探索結果を見る場合、問い合わせ結果はサムネイルとして表示することができない。

したがって、当技術分野では、ファイル・アクセス特権を特別に与えて、ユーザがアクセスできるファイルのサムネイルのみをユーザに見せることを許可するサムネイル・キャッシュが求められている。更に、リード・オンリ位置に常駐することができるファイルのサムネイルを格納することが可能なサムネイル・キャッシュも求められている。また、メモリ内におけるサムネイル画像の不要な複製を極力抑えるサムネイル・キャッシュも求められている。最後に、サムネイルを特定して間引きすることができ、更にファイル位置には無関係にサムネイル画像の全体表示を可能にするサムネイル・キャッシュも求められている。

以下に、本発明の様々な態様の基本的な理解を得るために簡素化した概要を示す。概要は、本発明の広範な全体像ではない。また、本発明の鍵となる要素や重要な要素を特定したり、発明の範囲を明確に描写することも意図していない。以下の概要は、単に、以下に続く更に詳細な説明への序文として、簡素化した形態で本発明の概念の一部を示すに過ぎない。

第１の例示実施形態は、ローカル・サムネイル・キャッシュにサムネイルを格納する方法を提供する。サムネイル画像および識別情報（例えば、変更タイムスタンプ、ファイル・パス、またはストリングＵＲＬのＣＲＣ−６４ハッシュ）を、画像を格納する要求と共に提示する。１つ以上のデータ・ファイルの１つに画像を格納し、データ・ファイル内におけるサムネイルの位置に伴うインデックス・ファイルに、識別情報を格納する。

第２の例示実施形態は、サムネイル・キャッシュを管理するシステムを提供する。このシステムは、データ・ファイルおよびインデックス・ファイルを格納するストレージを含む。また、このシステムは、ファイルと関連付けられた識別情報を伴う、サムネイル画像を格納する要求を受けるように構成されている。また、プロセッサは、データ・ファイルにサムネイル画像を格納し、データ・ファイルにおけるその位置を、識別情報と共に、インデックス・ファイルに格納するように構成されている。

添付図面に、限定ではなく一例として、本発明を示す。図面では、同様の参照番号は同一または同様の要素を示すものとする。

以下の種々の実施形態の説明では、その一部をなす添付図面を参照する。図面には、本発明を実用化することができる種々の実施形態が一例として示されている。尚、別の実施形態も利用可能であり、本発明の範囲および主旨から逸脱することなく、構造および機能の変更が可能であることは理解されよう。

図１は、本発明を実施することができる、適当な計算システム環境１００の一例を示す。計算システム環境１００は、適した計算機環境の一例に過ぎず、本発明の使用範囲や機能性について限定を示唆する意図は全くない。また、計算機環境１００は、動作環境例１００に示す構成要素のいずれの１つまたは組み合わせに関しても、何らかの依存性や必須要件を有するという解釈は行わないこととする。

本発明の態様は、多数のその他の汎用または特殊目的用計算システム環境や構成とでも動作することができる。本発明と共に用いるのに適していると思われる周知の計算システム、環境、および／または構成の例には、パーソナル・コンピュータ（ＰＣ）、サーバ・コンピュータ、パーソナル・ディジタル・アシスタント（ＰＤＡ）、タブレットＰＣまたはラップトップＰＣのようなハンド・ヘルドまたはその他の携帯デバイス、マルチプロセッサ・システム、マイクロプロセッサに基づくシステム、セット・トップ・ボックス、プログラマブル消費者用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、前述のシステムまたはデバイスのいずれをも含む分散型計算機環境等が含まれる。

本発明の態様についての説明は、総じて、コンピュータによって実行するプログラム・モジュールのような、コンピュータ実行可能命令との関連において行うこととする。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含み、特定のタスクを実行するか、または特定の抽象的データ・タイプを実現する。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスがタスクを実行する分散型計算機環境においても実用可能である。分散型計算機環境では、プログラム・モジュールは、メモリ記憶装置を含むローカルおよびリモート・コンピュータ記憶媒体双方に配することができる。

図１を参照すると、本発明を実施するシステム例は、コンピュータ１１０の形態とした汎用計算機を含む。コンピュータ１１０の構成要素は、限定ではなく、演算装置１２０、システム・メモリ１３０、およびシステム・バス１２１を含むことができる。システム・バス１２１は、システム・メモリを含む種々のシステム構成要素を演算装置１２０に結合する。システム・バス１２１は、数種類のバス構造のいずれでもよく、メモリ・バスまたはメモリ・コントローラ、周辺バス、および種々のバス構造のいずれかを用いるローカル・バスを含む。限定ではなく一例として、このような構造には、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、改良ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格連合（ＶＥＳＡ）ローカル・バス、およびMezzanine バスとしても知られている周辺素子相互接続（ＰＣＩ）バスが含まれる。

コンピュータ１１０は、通例、種々のコンピュータ読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、コンピュータ１１０がアクセス可能な入手可能な媒体であればいずれでも可能であり、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。限定ではない一例をあげると、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体から成ると考えられる。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータというような情報の格納のために、あらゆる方法または技術で実施される、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。コンピュータ記憶媒体は、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、電気的消去可能プログラマブル・メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリまたはその他のメモリ技術、コンパクト・ディスクＲＯＭ（ＣＤ−ＲＯＭ）、ディジタル多様ディスク（ＤＶＤ）またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができしかもコンピュータ１１０がアクセス可能なその他のいずれの媒体も含むが、これらに限定されるのではない。通信媒体は、通例、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータを、搬送波またはその他の移送機構のような変調データ信号において具体化し、あらゆる情報配信媒体を含む。限定ではなく、一例として、通信媒体は、有線ネットワークまたは直接有線接続というような有線媒体、ならびに音響、ＢＬＵＥＴＯＯＴＨまたは超広帯域（ＵＷＢ）標準ワイヤレス・リンクというような無線周波数（ＲＦ）、赤外線、およびその他のワイヤレス媒体というようなワイヤレス媒体を含む。前述のいずれの組み合わせも、コンピュータ読み取り可能媒体の範囲に当然含まれるものとする。

システム・メモリ１３０は、ＲＯＭ１３１およびＲＡＭ１３２のような揮発性および／または不揮発性メモリの形態で、コンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中のように、コンピュータ２０内のエレメント間におけるデータ転送を補助する基本的なルーチンを含み、典型的にＲＯＭ１３１内に格納されている。ＲＡＭ１３２は、典型的に、演算装置１２０が直ちにアクセス可能であるデータおよび／またはプログラム・モジュール、または現在これによって処理されているデータおよび／またはプログラム・モジュールを収容する。一例として、そして限定ではなく、図１は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７を示す。

また、コンピュータ１１０は、その他のリムーバブル／非リムーバブル揮発性／不揮発性コンピュータ記憶媒体も含むことができる。一例としてのみ、図１は、非リムーバブル不揮発性磁気媒体からの読み取りおよびこれへの書き込みを行なうハード・ディスク・ドライブ１４１、リムーバブル不揮発性磁気ディスク１５２からの読み取りおよびこれへの書き込みを行なう磁気ディスク・ドライブ１５１、ならびにＣＤ ＲＯＭまたはその他の光媒体のようなリムーバブル不揮発性光ディスク１５６からの読み取りおよびこれへの書き込みを行なう光ディスク・ドライブ１５５を示す。動作環境の一例において使用可能なその他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、限定する訳ではないが、磁気テープ・カセット、フラッシュ・メモリ・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれる。ハード・ディスク・ドライブ１４１は、典型的に、インターフェース１４０のような非リムーバブル・メモリ・インターフェースを介してシステム・バス１２１に接続され、磁気ディスク・ドライバ１５１および光ディスク・ドライブ１５５は、典型的に、インターフェース１５０のようなリムーバブル・メモリ・インターフェースによって、システム・バス１２１に接続する。

先に論じ図１に示すドライブおよびそれらと連動するコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびコンピュータ１１０のその他のデータを格納する。図１では、例えば、ハード・ディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７を格納するように示されている。尚、これらの構成要素は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じでも異なっていても可能であることを注記しておく。オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７は、ここで、少なくともこれらが異なるコピーであることを示すために、異なる番号が与えられている。

ユーザは、キーボード１６２、および一般にマウス、トラックボールまたはタッチ・パッドと呼ばれているポインティング・デバイス１６１によって、コマンドおよび情報をコンピュータ１１０に入力することができる。これらのデバイスの各々は、複数の入力構成要素を含むことができ、その各々はそれ自体の入力を供給する。キーボードの場合、キーまたは特殊ボタンの各々は入力構成要素として機能することができる。更に、ユーザがＣｏｎｔｒｏｌ、Ａｌｔ、Ｓｈｉｆｔまたはその他のキーを組み合わせて同時に押下したままにすることによってキー入力を変更するというように、キーの組み合わせによって一意の入力構成要素として機能することもできる。マウス、トラックボール、またはその他のポインティング・デバイスの場合、各々が提供する一情報に加えて、入力構成要素は、ボタン、ホイール、またはデバイス内に内蔵されているその他の入力メカニズムを含むこともできる。

追加の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲーム・パッド、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、ユーザ入力インターフェース１６０を介して、演算装置１２０に接続されている。ユーザ入力インターフェース１６０は、システム・バスに結合されているが、パラレル・ポート、ゲーム・ポート、ユニバーサル・シリアル・バス（ＵＳＢ）、ＩＥＥＥ１３９４シリアル・バス（ＦＩＲＥＷＩＲＥ）のようなその他のインターフェースおよびバス構造によって接続することも可能である。モニタ１８４またはその他の形式の表示装置も、ビデオ・インターフェース１８３のようなインターフェースを介して、システム・バス１２１に接続されている。ビデオ・アダプタ１８３は、それ自体の特殊プロセッサおよびメモリに加えて、先進の２Ｄまたは３Ｄグラフィクス処理能力も備えることができる。

また、コンピュータ１１０は、ユーザがスタイラス１８６を用いて入力することを可能にするために、ディジタイザ１８５を含むこともできる。ディジタイザ１８５は、モニタ１８４に一体化することも別の表示装置とすることもでき、あるいはディジタイザ・パッドのように、別個のデバイスの一部とすることもできる。また、コンピュータ１１０は、スピーカ１８９およびプリンタ１８８のような、その他の周辺出力装置も含むことができ、これらは出力周辺インターフェース１８７を通じて接続することができる。

コンピュータ１１０は、リモート・コンピュータ１８０のような１つ以上のリモート・コンピュータへの論理接続を用いて、ネットワーク環境において動作することも可能である。リモート・コンピュータ１８０は、パーソナル・コンピュータ、ハンド・ヘルド・デバイス、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードとすることができ、典型的に、コンピュータ１１０に関して先に説明したエレメントの多くまたは全てを含むが、図１にはメモリ記憶装置１８１のみを示す。図１に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１７１およびワイド・エリア・ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーク環境は、事務所、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットにおいては、一般的である。

ＬＡＮネットワーク環境で用いる場合、コンピュータ１１０は、ネットワーク・インターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続する。ＷＡＮネットワーク環境で用いる場合、コンピュータ１１０は、典型的に、モデム１７２、衛星円盤（図示せず）、またはインターネットのようなＷＡＮ１７３を通じて通信を確立するその他の手段を含む。モデム１７２は、内蔵でも外付けでもよく、ユーザ入力インターフェース１６０またはその他の適切な機構を介してシステム・バス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して図示したプログラム・モジュール、またはその一部は、リモート・メモリ記憶装置に格納することもできる。一例として、そして限定ではなく、図１は、リモート・アプリケーション・プログラム１８５がメモリ素子１８１上に常駐するものとして示している。尚、図示のネットワーク接続は一例であり、コンピュータ間で通信リンクを確立する他の手段も使用可能であることは認められよう。

図３は、本発明の１つ以上の例示実施形態によるローカル・サムネイル・キャッシュ３０１のブロック図を示す。ローカル・サムネイル・キャッシュ３０１は、サムネイル画像の発生、格納、および表示において連携する構成要素の大きな集合における一部であってもよい。これらの構成要素は、サムネイル・クライアント３１０を含むことができ、サムネイル・コンシューマ(thumbnail consumer)３１３はプログラムによってサムネイル・クライアント３１０と双方向処理を行うことができる。サムネイル・コンシューマ３１３は、オペレーティング・システム１３２の構成要素（例えば、グラフィカル・ファイル・ブラウザ）または第三者ソフトウェア（例えば、グラフィクス編集ソフトウェア）の構成要素を含むこともできる。サムネイル・コンシューマ３１３は、特定のファイルについてのサムネイルを要求および検索することができる。サムネイル・クライアント３１０は、このような要求を受信すると、サムネイル画像発生を要求することができ（恐らくは背景プロセスとして）、あるいはローカル・サムネイル・キャッシュ３１０から画像を検索することができる。

特定のファイルに関連する情報は、サムネイルを格納および検索するための「キー」として用いることができる。この関連情報は、個々のファイルの位置または特性を識別するために用いることができるので、「識別データ」と記述することもできる。このような情報は、個々のファイルの名称、ファイルの位置（例えば、ユニフォーム・リソース・ロケータ（ＵＲＬ）またはファイル経路）、変更タイムスタンプ、作成タイムスタンプ、ファイル・サイズ等を含むことができる。更に、識別データは、前述のいずれの暗号ハッシュ(cryptographic hash)も含むことができる。例えば、あるファイルと関連があるＵＲＬを変更日時と組み合わせれば、識別ストリングを形成することができ、これからＣＲＣ−６４ハッシュを抽出する。このような識別情報は、ローカル・サムネイル・キャッシュ３０１内部でサムネイルにインデックスを付けるときに用いることができる。

例えば、サムネイル・コンシューマ３１３の１つが、ファイル３１２のサムネイル画像を要求する際、このファイルについての識別情報（例えば、ＵＲＬ、および／または変更日時）を提供すればよい。識別情報を参照キーとして用いて、サムネイル・クライアント３１０は最初にローカル・サムネイル・キャッシュ３０１を調べて、ファイル３１２のサムネイル画像が既に格納されているか否か確認することができる。ローカル・サムネイル・キャッシュ３０１がそのサムネイルを有していない場合、サムネイル・クライアント３１０は、登録されているサムネイル抽出部３１１にファイル３１２に対するサムネイル画像を発生するように要求することができる。一旦発生したなら、サムネイル・クライアント３１０は、コンシューマの要求に返答して、新たに発生したサムネイルのコピーまたはサムネイルへの参照を与えることができる。次回サムネイル・コンシューマがファイル３１２のサムネイルを要求したときは、サムネイル・クライアント３１０は、新たにサムネイル画像を発生する無駄な処理時間を要することなく、ローカル・サムネイル・キャッシュ３０１に格納されている画像のコピー、または画像への参照を与えて返答することができる。

ローカル・サムネイル・キャッシュ３０１を「ローカル」と記述するのは、これにアクセスできるのが現在認識済みのユーザだけであるからである。認識済みのユーザという用語は、オペレーティング・システム１３４が認識したコンピュータ１１０のユーザを意味する。コンピュータは多くのユーザを有することがあるが、認識済みのユーザだけに、彼らのファイルのセキュリティに対する制御、および彼らのローカル設定値に対する制御を付与することができる。認識済みのユーザは、彼または彼女自身のローカル設定集合にアクセスすることができる。ローカル設定集合は、デスクトップの好み（例えば、背景色）や、セキュリティ特権（例えば、ユーザ・ファイルから他のユーザを締め出す）を含むことができる。

ローカル・サムネイル・キャッシュ３０１は、認識済みのユーザのローカル・ファイル間に格納することができる。コンピュータ１１０の各認識済みユーザには、彼または彼女のローカル・サムネイル・キャッシュ３０１を割り当てることができる。これは複製可能にしてもよいが、機密ファイルと考えられる場合、自由なアクセスを防止する。前述のように、全体的にアクセス可能なサムネイル・キャッシュでは、無許可ユーザがアクセスできないファイルのサムネイル画像に、無許可ユーザをアクセスさせてしまう可能性がある。全てのサムネイルをローカル・キャッシュにキャッシュし、認識済みユーザのみにアクセス可能とすることにより、潜在的なセキュリティの孔を塞ぐことができる。種々の最適化方式によって、サムネイル発生プロセスを合理化することができる。これらの方式には、他のローカルまたはリモート・キャッシュにキャッシュされているサムネイルの共有（セキュリティ対策が妨害されないことを確保しつつ）を含むことができる。このキャッシュ方式は、ユーザ毎／マシン毎キャッシュと記述することができる。何故なら、別個のキャッシュをコンピュータ１１０の認識されているユーザ毎に作成するからである。

ローカル・サムネイル・キャッシュ３０１は、データ・ストア３０３およびインデックス・ストア３０４と結合されたサムネイル・サーバ３０２という形態で、演算装置１２０によって実行可能なソフトウェア・コードを含むことができる。データ・ストア３０３は、グラフィカル情報として格納したサムネイル画像を収容する１つ以上のデータ・ファイルを含むことができる。データ・ストア３０３は、画像の寸法やファイル・サイズには関係なく、全てのサムネイル画像を格納する単一のデータ・ファイルのみを含んでもよい。あるいは、寸法が異なるサムネイルを格納するために、多数のデータ・ファイルを用いてもよい。インデックス・ストア３０４は、データ・ストア３０３内にある関連するサムネイルの位置（または位置オフセット）と結合したファイル識別情報を収容するインデックス・ファイルを含むことができる。インデックス・ストア３０４およびデータ・ストア３０３は、オペレーティング・システム１３４内に別個のファイルとして格納することができる。全体を通じて別個のファイルと記述するが、これらのファイルを組み合わせて、メモリに格納するときには、単一の連合キャッシュ・ファイルとしてもよい。

サムネイル・サーバ３０２は、特定のサムネイル関連プログラム・インターフェースを実施する実行可能コードの集合体とすることができる。サムネイル・サーバ３０２は、実行可能ファイル（例えば、thumbs.exe）または実行可能コードの動的リンク可能ライブラリ（例えば、thumbcache.dll）とすることができる。サムネイル・サムネイル・サーバ３０２によって実施するIThumbnailCacheインターフェースは、サムネイル・クライアント３１０がキャッシュに格納されているサムネイルを取り込み（例えば、GetThumbnai()）、サムネイルをキャッシュに保存する（例えば、SetThumbnail()）ことを可能にする、２つの必須機能を含むことができる。

サムネイル・クライアント３１０がローカル・サムネイル・キャッシュ３０１からサムネイル画像を取り込もうとする場合、サムネイル・クライアント３１０は、識別情報をサムネイル・サーバ３０２に供給することによって、これを要求することができる。先に注記したように、この識別情報は、ＵＲＬ、日付、時刻、以上のデータ全てのハッシュ等を含むことができる。加えて、ローカル・サムネイル・キャッシュ３０１が多数のサイズのサムネイル画像を格納している場合、識別情報はサムネイルの寸法（例えば、３２×３２または１２８×１２８）も含むことができる。ローカル・サムネイル・キャッシュ３０１に、識別情報の全てが一致するサムネイルがない場合、キャッシュ３０１はキャッシュ・ミス・インディケータ(cache miss indicator)をサムネイル・クライアント３１０に戻すことができる。

ローカル・サムネイル・キャッシュ３０１が、要求されたサムネイルのコピーを格納している場合、サムネイル画像のコピー、または直接キャッシュを指し示す画像への参照のいずれかを戻すことができる。これを「直接マッピング」と呼ぶこともできる。サムネイル画像への直接キャッシュ参照を用いると、サムネイルの余分なバッファ・コピー、即ち、管理しなければならないコピーの作成（例えば、基礎のサムネイルを変更したときに、コピーをリフレッシュしなければならない）を回避することができる。キャッシュに格納されているサムネイル画像への参照を供給することにより、ビデオ・アダプタ１８３は、オペレーティング・システム１３４が採用するメモリ管理メカニズムに応じて、ハード・ディスク１４１から直接サムネイルを参照することが可能となる。

図４は、本発明の１つ以上の例示実施形態による、関連データ・ファイル４０２、４０３、４０４を有するサムネイル・キャッシュ・インデックス４０１を示す。ローカル・サムネイル・キャッシュ３０１は、インデックス４０１を含むことができる。インデックス４０１は、インデックス・バージョン番号のような情報や、読み取り／書き込みロックを管理するためのフィールドを有するヘッダを含むことができる。インデックス４０１内にある個々のエントリ、例えば、エントリ４２１は、識別情報（例えば、発生したＵＲＬストリングのハッシュおよび／または変更の日時）を含むことができる。加えて、各インデックス・エントリは、位置情報のアレイ、サムネイルを収容することができるサムネイル・データ・ファイル毎に１つのアレイ・エントリを収容することができる。インデックス４０１に格納されているインデックス・エントリは、素早いアクセスのために、ハッシュ・テーブルまたは散乱テーブル(scatter table)を用いて格納することもできる。具体的には、インデックス・エントリは、線形精査シーケンス(linear probe sequence)で、開放アドレス散乱テーブル(open addressed scatter table)に格納することができる。インデックス４０１内部におけるインデックス・エントリの編成を調整または最適化して、ファイルの格納場所(locality)を増大させ、頻繁に要求されるサムネイルを一緒に互いに都合が良い位置に格納すれば、素早くアクセスすることが可能となる。

ローカル・サムネイル・キャッシュ３０１は、１つ以上の関連データ・ファイル４０２、４０３、４０４を含むことができ、各々、特定のサイズまたは寸法のサムネイルを収容する。各データ・ファイルは、ヘッダ４１２、４１３、４１４を含むことができ、ヘッダは、データ・ファイル・バージョン番号、付随するサムネイルのサイズ（例えば、３２×３２または１２８×１２８）というような情報、更には孤立画像(orphan)除去および読み出し／書き込み／維持系統(maintainer)ロックを管理するためのフィールドを含むことができるう。サムネイル・サイズが１つだけのデータ・ファイルを用いると、コード化を簡素化することができる。何故なら、直列化したビットマップ（またはその他のグラフィック・フォーマット）は必ず標準サイズとなり、データ・ファイルの考察および操作が一層簡単になるからである。画素またはファイル・サイズの要件を完全に満たすサムネイル画像（例えば、標準のアスペクト比とは異なるアスペクト比を有する）には、詰め物をして、標準のエントリ・サイズを維持すればよい。例えば、サムネイルの直接マッピングを可能にするために必要な特定のファイル・サイズを得るために、画像に詰め物をする場合がある。

データ・ファイル４０２、４０３、４０４のヘッダ４１２、４１３、４１４に続いて、格納したビットマップ（またはＪＰＥＧ、あるいはその他のグラフィック・フォーマット）の直列化バージョンが、各データ・ファイル内にあるとよい。サムネイル、特に大きな画像を格納するために、圧縮フォーマットを用いることもできる。これらの圧縮画像は、検索のときに伸張することができる。インデックス４０１の各インデックス・エントリと共に格納されている位置情報は、オフセット情報を含み、各データ・ファイル内において固定されている開始点から計数するバイト数または画像数を与えるようにするとよい。加えて、インデックス４０１の各インデックス・エントリ内に格納されている位置情報は、サムネイル画像の内容のＣＲＣ−３２チェックサム（または同様のチェックサム）も含むことができる。これによって、ローカル・サムネイル・キャッシュ３０１は、サムネイル画像の内容が、その画像が格納されて以来、不用意に（または悪意で）変更されていないか否かチェックすることが可能となる。

ローカル・サムネイル・キャッシュ３０１には、各クライアント・プロセスのプロセス内サーバ構成要素を通じてアクセスすることができる。サムネイル・キャッシュへのアクセスを調停するためにユーザ毎またはシステム毎のブローカ・サービスを用いる代わりに、個々のクライアント・プロセスが協同してアクセスの同期を取り、同じファイルまたはメモリ空間にアクセスするときの競合を回避するとよい。インデックス４０１上での競合は少ないと思われる。標準的な多重リーダ／単一ライタ・グループ・ロックを用いて、インデックス４０１内における競合に対して保護してもよい。グループ・ロックの実施態様は、「ライタ切望型」(writer-starved)とし、リーダ・ロックを優先するとよい。１つ以上のデータ・ファイル４０２、４０３上の競合は多いと思われる。リーダ／ライタ／維持系統ロックを用いて、データ・ファイル４０２、４０３、４０４における競合を回避するとよい。維持系統は、リーダがアクセスできないデータ・ファイル・エントリを変更することだけを許可し（例えば、インデックス・エントリ位置の移動のためにデータ・ファイル・エントリが孤立している場合）、古くなったサムネイルの「収集整理」ならびに背景走査およびフラグメンテーション解消を実行することを許可するとよい。

ローカル・サムネイル・キャッシュ３０１はキャッシュである（データベースではない）ので、キャッシュのファイル・サイズを管理するために一連の方策を採用するとよい。キャッシュの中にいつまでも残っていられることを保証されている特別なサムネイル画像はない。使用頻度が少ないサムネイルまたは期限切れのサムネイルを、定期的に削除して、新しいサムネイルのための余裕空間を作るとよい。キャッシュ・サイズを管理する方策は、各ユーザのサムネイル・キャッシュ（または全てのユーザのキャッシュ）を、特定のサイズまたは利用可能なディスク空間の特定の割合に制約し、ディスク浄化ウィザードの一部としてユーザに全てのサムネイル・キャッシュを消去させ、「ごみ」を収集することによって孤立した（参照されてない）データ・ファイル・エントリを除去し、新しいサムネイルが用いるために、古いキャッシュ・エントリおよび／または使用されないキャッシュ・エントリが占める空間を回収することを含むことができる。回収の方策は、使用頻度、最後の使用以来の時間、最初に変換したファイルのサイズ等を考慮に入れるとよい。例えば、元のファイルの方が大きい場合（そして、サムネイルを発生するために長い時間がかかる）、元のファイルが頻繁に用いられなくても、これがキャッシュ内に残留し回収されない可能性の方が高い場合もある。

個々のサムネイル画像が現在使用されている（したがって、ごみではない）か否か判定する際、従来の手法または従来と異なった手法を採用することができる。サムネイルが使用されているか否か追跡する方法の１つでは、参照カウンタによって、サムネイルへの参照を追跡する。参照カウンタは、インデックス４０１と共に共有メモリに格納されていることもある。しかしながら、参照カウンタは、予期せずに終了したプロセスによっては減数されないようにすれば、現在孤立しているサムネイル画像のガベージ・コレクションを防止することができる。

データ・ファイルにおける画像への参照を追跡する代替方法の１つでは、読み取られたサムネイル画像毎に、一意の名称を付けたカーネル・オブジェクトを作成する。サムネイルを読み取るとき、例えば、画像名のＵＲＬおよびＣＲＣ−６４の連結を用いて、チープ・カーネル・オブジェクト(cheap kernel object)（例えば、ミュテックス(mutex)またはイベント）を作成し、カーネル・オブジェクトに名称を付ける。サムネイルを読み取っている間にプロセスが消滅した場合、オペレーティング・システムはカーネル・オブジェクト（複数のカーネル・オブジェクト）を浄化する。個々のサムネイルが使用されているか否か確認するためにチェックする場合、システムは単にカーネルに問い合わせて一意の名称を求めるか、または同じオブジェクトを作成しようとして、エラーとなるか否か調べる。エラーとなり、そのオブジェクトが既に存在することが述べられる限り、そのサムネイルは「用いられている」ことになる。

回収アルゴリズムを用いて、ガベージ・コレクションを行うことができる（例えば、もはやインデックスによって参照されず、もはや「用いられて」いないサムネイル画像を除去または上書きする）。このようなアルゴリズムは、データ・ファイルの全体を精査して（恐らく、背景プロセスとして）孤立したサムネイルおよび使用されていないサムネイルを探し出すことを要する場合がある。孤立したサムネイルは、直ちに新しいサムネイルと交換することもできるが、あるいはこれらにフラグを立てて、今後再利用できるようにしてもよい。データ・ファイル内にあるサムネイルは、格納されている各画像の先頭にヘッダ・エントリを含むことができる。このヘッダは、孤立した状態を示すフラグを収容することができる。代わりに、格納されている各画像のヘッダは、「次の孤立した」データ・ファイル・エントリに対する値を収容することもできる。「次に孤立した」エントリをリンクしたリストを調べることにより、全ての孤立したサムネイル画像を発見し、１つずつ処置することができる。加えて、フラグメンテーション解消パスが、孤立したサムネイル画像をデータ・ファイルから完全に除去し、参照されているサムネイルを詰めて行って隙間をなくすこともできる。これらのパスは、経時的な使用カウントを連続的に更新したヒストグラムのような、使用統計に基づいて、より良い場所に位置付けるために画像を配列し直すこともできる。

図５は、前述の回収方策が示唆するローカル・サムネイル・キャッシュ３０１におけるサムネイル画像の格納プロセスを示す。ステップ５００において、サムネイル画像を格納する要求を受け、識別情報によって遂行する。判断５０１においてインデックス４０１をチェックし、同じ識別情報を用いて、画像が既にこのサムネイル・サイズで格納されているか否か確認する。画像が既に格納されている場合、判断５０２において、古い画像をチェックし、これが現在使用されているか否か確認する。使用されている場合、ステップ５０３において、既に格納されている画像の位置を、後に浄化する、孤立位置のリストに格納する。画像が現在用いられていない場合、ステップ５０５において、新しい画像のためにその位置を再利用する。ステップ５０３の後、または判断５０１において、画像が以前に格納されていなかった場合、判断５０４において孤立画像のリストをチェックして、現在使用されていないものがあるか否か確認する。使用されていない孤立画像がある場合、ステップ５０６において、この孤立画像の画像サイズが、交換する画像を収容できるだけの大きさであるならば、この孤立画像の位置を新しい画像のために用いる。利用可能な孤立画像がない場合、判断５０７において、データ・ファイルを検査して、先に論じた制約を仮定して、データ・ファイルを拡大することができるか否か確認する。データ・ファイルを拡大することができる場合、ステップ５０８において、新しい画像をデータ・ファイルに添付する。データ・ファイルをそれ以上拡大することができない場合、判断５１１において、先に論じた回収方策の使用を開始して、孤立していないが使用されていない画像を選択して回収する。画像を発見することができない場合、ステップ５１２において、新しい画像をキャッシュには格納しない。回収可能な画像が発見された場合、ステップ５０９において、格納位置を再利用し、選択した回収可能な画像と新しい画像を置き換える。前述のステップ（５０５、５０６、５０８、または５０９）のいずれかにおいて新しい画像を確認した場合、ステップ５１０において、画像の新しい位置を用いて、インデックス４０１におけるエントリを更新する。

図６は、ローカル・サムネイル・キャッシュ３０１にサムネイルを格納し検索する総合的なプロセスを示す。ステップ６０１において、インデックス４０１および１つ以上のデータ・ファイルを用いて、ローカル・サムネイル・キャッシュ３０１を維持する。ステップ６０２において、サムネイルを格納する要求を受け取り、識別情報によって遂行する。ステップ６０３において、サムネイル画像をデータ・ファイルに格納する。ここで、先に概要を述べたプロセスを用いることができる。ステップ６０４において、インデックス４０１に識別情報を格納し、ステップ６０５において、データ・ファイル内における画像の位置を、識別情報と共に、インデックス４０１に格納する。ステップ６０６において、その識別情報によって示されるように、サムネイル画像を検索する要求を受け取る。ステップ６０７において、先に概要を述べたプロセスを用いて、画像またはそれへの参照を検索する。

以上、現時点において本発明を実施するのに好ましい態様を含む、具体的な例に関して、本発明の態様を説明したが、前述の説明および技術には、添付した特許請求の範囲に明記した発明の主旨および範囲に該当する数多くの変形および代用物があることは、当業者には認められよう。

図１は、本発明の例示実施形態の１つ以上の態様を実施することができる動作環境の機能ブロック図である。 図２Ａは、従来技術のサムネイル・キャッシュを示す。 図２Ｂは、従来技術のサムネイル・キャッシュを示す。 図３は、本発明の１つ以上の例示実施形態によるローカル・サムネイル・キャッシュのブロック図を示す。 図４は、本発明の１つ以上の例示実施形態による、サムネイル・キャッシュ・インデックス・ファイルを、付随するデータ・ファイルと共に示す。 図５は、本発明の１つ以上の例示実施形態にしたがって、サムネイル・キャッシュにサムネイルを格納するプロセスを示す。 図６は、本発明の１つ以上の例示実施形態にしたがって、サムネイル・キャッシュを用いてサムネイルを格納および検索するプロセスを示す。

Claims (20)

1. サムネイル画像を管理するためのコンピュータで実施する方法であって、
   コンピュータ内にサムネイル・キャッシュを維持するステップであって、前記サムネイル・キャッシュがインデックスとデータ・ストアとを含む、ステップと、
   サムネイル画像を前記サムネイル・キャッシュに追加する第１要求を受けるステップであって、前記第１要求は、前記サムネイル画像と、識別情報と、サムネイル・サイズをと含む、ステップと、
   前記サムネイル画像を前記データ・ストアに格納するステップと、
   前記インデックスに、前記識別情報と、前記サムネイル・サイズと、前記データ・ストア内における前記サムネイル画像の位置とを格納するステップと、
   を備えている、方法。
2. 請求項１記載の方法において、前記識別情報は、ファイル位置と、変更時刻とを含む、方法。
3. 請求項１記載の方法であって、更に、
   前記サムネイル画像を検索する第２要求を受けるステップであって、前記第２要求は、前記識別情報と前記サムネイル・サイズとを含む、ステップと、
   前記第２要求に対して、前記サムネイル画像を与えて回答するステップと、
   を備えている、方法。
4. 請求項３記載の方法であって、更に、
   ディスプレイ上に前記サムネイル画像を表示するステップを備えており、前記ディスプレイと連動するメモリが、前記サムネイル・キャッシュから直接前記サムネイル画像の非圧縮コピーを読み出す、方法。
5. 請求項１記載の方法において、
   前記データ・ストアは、複数のデータ・ファイルを含み、複数の異なるサムネイル・サイズ毎に、１つのデータ・ファイルを有し、
   前記インデックスにおけるエントリは、前記識別情報と、前記複数のデータ・ファイル内における複数のサムネイル画像とを含む、方法。
6. 請求項１記載の方法において、前記コンピュータの認識された各ユーザが、専用のサムネイル・キャッシュを有する、方法。
7. 請求項６記載の方法において、各専用サムネイル・キャッシュは、対応する認識済みユーザのみがアクセス可能である、方法。
8. 請求項１記載の方法において、前記サムネイル・キャッシュは、前記コンピュータ上でランする複数のプロセスによって同時にアクセス可能である、方法。
9. 請求項８記載の方法において、前記複数のプロセスは、協同して、前記サムネイル・キャッシュに対するこれらのアクセスを同期させる、方法。
10. 請求項１記載の方法において、前記サムネイル画像を前記データ・ストアに格納するステップは、
    前記識別情報と関連付けられた古いサムネイル画像が、既に前記データ・ストア内の位置に存在するか否か判定するステップと、
    前記古いサムネイル画像が前記データ・ストアに存在することに応答して、前記サムネイル画像を、前記古いサムネイル画像の位置に格納するステップと、
    を備えている、方法。
11. サムネイル画像を管理するシステムであって、
    サムネイル・キャッシュを格納するストレージであって、前記サムネイル・キャッシュがインデックス・ファイルと１つ以上のデータ・ファイルとを含む、ストレージと、
    プロセッサと、
    を備えており、前記プロセッサが、
    サムネイル画像を前記サムネイル・キャッシュに格納する第１要求を受け、前記第１要求が前記サムネイル画像と識別情報とを含み、
    前記１つ以上のデータ・ファイルの１つに、前記サムネイル画像を格納し、
    前記インデックスに、前記識別情報と、前記１つ以上のデータ・ファイルの前記１つにおける前記サムネイル画像の位置とを格納し、
    前記サムネイル画像を検索する第２要求を受け、前記第２要求が前記識別情報を含み、
    前記第２要求に対して、前記サムネイル画像への参照を与えて回答する、
    ように構成されている、システム。
12. 請求項１１記載のシステムにおいて、前記識別情報は、ファイル位置と、変更の日時とを含む、システム。
13. 請求項１２記載のシステムにおいて、前記ファイル位置は、ユニフォーム・リソース・ロケータである、システム。
14. 請求項１０記載のシステムであって、更に、
    ディスプレイと、
    メモリと、
    を備えており、前記サムネイル画像への参照は、前記サムネイル画像の表現が位置する前記メモリ内におけるメモリ位置を指し示し、前記プロセッサは、更に、前記メモリ位置を直接参照することによって、前記ディスプレイ上に前記サムネイル画像を表示するように構成されている、システム。
15. 請求項１１記載のシステムにおいて、前記プロセッサは、更に、
    前記識別情報に対するメモリ位置に、古いサムネイル画像が以前に格納されていたか否か判定を行い、
    前記古いサムネイル画像が以前に格納されていたことに応答して、前記サムネイル画像を格納するために、前記１つ以上のデータ・ファイルの前記１つの内部における前記古いサムネイル画像のメモリ位置を再利用する、
    ように構成されている、システム。
16. 請求項１１記載のシステムにおいて、当該システムの認識されたユーザが専用のサムネイル・キャッシュを有する、システム。
17. 請求項１１記載のシステムにおいて、前記サムネイル・キャッシュは、前記コンピュータ上でランする多数のプロセスによって同時にアクセス可能である、システム。
18. 請求項１１記載のシステムにおいて、
    前記サムネイル・キャッシュは、複数のデータ・ファイルを備えており、複数の異なるサムネイル画像サイズ毎に１つのデータ・ファイルがあり、
    前記インデックス・ファイルにおけるエントリは、前記識別情報と、前記複数のデータ・ファイル内における１つ以上のサムネイル画像の位置とを含み、
    前記第１要求は、更に、前記複数の異なるサムネイル画像サイズの１つのインディケータを含む、システム。
19. サムネイル画像を管理するシステムであって、
    ディスプレイと、
    サムネイル・キャッシュを格納するストレージであって、前記サムネイル・キャッシュがインデックス・ファイルと複数のデータ・ファイルとを含む、ストレージと、
    プロセッサと、
    を備えており、
    前記プロセッサが、
    サムネイル画像を前記サムネイル・キャッシュに格納する第１要求を受け、該第１要求が、前記サムネイル画像と、ファイル位置と、変更日時と、サムネイル・サイズとを含み、
    前記サムネイル画像を前記複数のデータ・ファイルの１つに格納し、
    前記インデックス・ファイルに、前記複数のデータ・ファイルの前記１つにおける前記サムネイル画像の前記ファイル位置と、前記変更日時と、前記サムネイル・サイズとを格納し、
    前記サムネイル画像を検索する第２要求を受け、該第２要求が、前記ファイル位置と、前記変更日時と、前記サムネイル・サイズとを備えており、
    前記サムネイル画像を前記ディスプレイ上に表示するように構成されている、システム。
20. 請求項１８記載のシステムであって、更に、
    ビデオ・アダプタを備えており、該ビデオ・アダプタは、前記サムネイル画像を前記サムネイル・キャッシュから直接読み出す、システム。

Images