(57)【要約】　　　（修正有）【課題】アプリケーション独立のカーネル内キャッシュを提供すること。【解決手段】コンテンツを格納するための方法および道具であるキャッシュ・オブジェクトが、オペレーティング・システムが供給する機構を利用して与えられる。キャッシュ・オブジェクトのための記憶を獲得するシステムが実施される。多数の変化するデータのソースを可能にするための技術が定義される。多数のデータ・ソースを、アプリケーション固有またはアプリケーション独立あるいはその両方のデータを、様々なプロトコルを使用して提供することができる。前述のキャッシュ・オブジェクト格納機構はデータのソースから独立しており、その逆もまた同様である。キャッシュ・オブジェクトの高速ルックアップおよび管理のための技術が定義される。データをデータ・ソースからキャッシュ・オブジェクト格納機構に移動させるための機構が実施される。【選択図】図３
2004133931.tif 000002
【特許請求の範囲】
【請求項１】
　オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュするためのシステムであって、
　キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するための構成と、
　少なくとも１つのキャッシュ・オブジェクトをルックアップするための少なくとも１つの構成と、
　データを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに前記収集されたデータを移植するための構成と
　を含む、システム。
【請求項２】
　少なくとも１つのキャッシュ・オブジェクトが、前記オペレーティング・システムに固有の少なくとも１つの格納機構を使用するように適合される、請求項１に記載のシステム。
【請求項３】
　少なくとも１つの格納機構は、独立キャッシュ・オブジェクト・タイプおよび独立キャッシュ・オブジェクト区分のうちの少なくとも１つに対応する、請求項２に記載のシステム。
【請求項４】
　少なくとも１つのキャッシュ・オブジェクトが、前記システムによって排他的に管理および制御される、請求項１に記載のシステム。
【請求項５】
　少なくとも１つのキャッシュ・オブジェクトの処理を、特定のオペレーティング・システム環境に適合させるための構成をさらに含む、請求項４に記載のシステム。
【請求項６】
　少なくとも１つのキャッシュ・オブジェクトの処理を適合させるための前記構成が、少なくとも１つのキャッシュ・オブジェクトの処理を、使用されているページング可能メモリの量、自由に使用できるページング可能メモリの量、前記システム内のページング可能メモリの合計量、前記カーネル内のページング可能メモリの合計量、使用されている非ページング可能メモリの量、自由に使用できる非ページング可能メモリの量、前記システム内の非ページング可能メモリの合計量、前記カーネル内の非ページング可能メモリの合計量、使用されているシステム・ページ・テーブル・エントリの数、使用可能なシステム・ページ・テーブル・エントリの数、前記システム・ページ・テーブルに割り振られた仮想メモリの量、システム・キャッシュのサイズ、システム・キャッシュで使用可能な空間の量、システム・キャッシュで使用されている空間の量、システム・ワーキング・セットのサイズ、使用中のシステム・バッファの数、使用可能なシステム・バッファの数、システム・バッファの数、ページ・サイズ、確立されたネットワーク接続の数、１つまたは複数の中央処理装置（ＣＰＵ）の利用度、割り振られたワーカ・スレッドの数、アイドル状態のワーカ・スレッドの数、ビジーなワーカ・スレッドの数、割り振られたキャッシュ・オブジェクトの数、カーネル内で消費されたＣＰＵ時間の割合、単位時間毎のシステム割込みの数、単位時間毎のページ・フォルトの数、単位時間毎のシステム・キャッシュ内のページ・フォルトの数、単位時間毎のページング済みプール割り振りの数、単位時間毎の非ページング・プール割り振りの数、ルック・アサイド・リストの長さ、オープン・ファイル・ディスクリプタの数、ディスク上の空き空間の量、および割込みレベル、あるいは高割込み要求レベルで消費された時間の割合のうちの少なくとも１つに基づいて適合させるように構成される、請求項５に記載のシステム。
【請求項７】
　少なくとも１つのキャッシュ・オブジェクトをルックアップするための前記少なくとも１つの構成は、少なくとも１つのデータ構造を含む、請求項１に記載のシステム。
【請求項８】
　前記少なくとも１つのデータ構造が、前記システムによって制御される、請求項７に記載のシステム。
【請求項９】
　前記少なくとも１つのデータ構造は、少なくとも１つのハッシュ・テーブル、少なくとも１つのリンク・リスト、少なくとも１つのツリー、少なくとも１つのヒープ、および少なくとも１つのキューのうちの少なくとも１つを含む、請求項８に記載のシステム。
【請求項１０】
　前記複数のデータ・ソースに関係する詳細を格納する揮発性記憶域をさらに含む、請求項１に記載のシステム。
【請求項１１】
　前記少なくとも１つのキャッシュ・オブジェクトが、前記複数のデータ・ソースの前記格納された詳細を使用して、前記複数のデータ・ソースとのコヒーレンシを維持するように適合される、請求項１０に記載のシステム。
【請求項１２】
　前記少なくとも１つのキャッシュ・オブジェクトのいずれかの区分が、前記複数のデータ・ソースのいずれかの区分の単一のインスタンスに関連付けられる、請求項１に記載のシステム。
【請求項１３】
　前記複数のデータ・ソースからのデータを格納するためのいずれかの構成は、前記複数のデータ・ソースに関係する詳細を格納するためのいずれかの構成から独立している、請求項１２に記載のシステム。
【請求項１４】
　前記複数のデータ・ソースは、前記少なくとも１つのキャッシュ・オブジェクトから独立している、請求項１３に記載のシステム。
【請求項１５】
　前記複数のデータ・ソースからの前記データは、アプリケーション固有である、請求項１に記載のシステム。
【請求項１６】
　前記複数のデータ・ソースからの前記データは、アプリケーション独立である、請求項１に記載のシステム。
【請求項１７】
　少なくとも１つのキャッシュ・オブジェクトを削除するための構成をさらに含む、請求項１に記載のシステム。
【請求項１８】
　前記少なくとも１つのキャッシュ・オブジェクトの移植中に、前記複数のデータ・ソースからのデータがクライアント・アプリケーションに送信されることを許可するための構成をさらに含む、請求項１に記載のシステム。
【請求項１９】
　前記クライアント・アプリケーションは、要求パラメータの任意の必要な構文解析、前記複数のデータ・ソースによって提供された以外の任意の必要なアプリケーション固有の応答データの生成、少なくとも１つのデータのタイプの選択、および前記複数のデータ・ソースの作成のうちの少なくとも１つを実施する、請求項１に記載のシステム。
【請求項２０】
　前記複数のデータ・ソースは、ファイル・システム、ＨＴＴＰサーバ、およびユーザ・レベル・アプリケーションのうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項２１】
　キャッシュされたコンテンツを要求に応じて返すための構成をさらに含む、請求項１に記載のシステム。
【請求項２２】
　キャッシュされたコンテンツを返すための前記構成が、少なくとも１つのキャッシュ・オブジェクトの前記データを要求に応じて返すように適合される、請求項２１に記載のシステム。
【請求項２３】
　キャッシュされたコンテンツを返すための前記構成が、キャッシュ・オブジェクトを使用して、少なくとも１つの包含キャッシュ・オブジェクトの前記データを返すように適合される、請求項２１に記載のシステム。
【請求項２４】
　オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュする方法であって、
　キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するステップと、
　少なくとも１つのキャッシュ・オブジェクトをルックアップするステップと、
　データを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに、前記収集されたデータを移植するステップと
　を含む、方法。
【請求項２５】
　前記作成するステップは、前記オペレーティング・システムに固有の少なくとも１つの格納機構を使用するように適合された、少なくとも１つのキャッシュ・オブジェクトを作成するステップを含む、請求項２４に記載の方法。
【請求項２６】
　少なくとも１つの格納機構は、独立キャッシュ・オブジェクト・タイプおよび独立キャッシュ・オブジェクト区分のうちの少なくとも１つに対応する、請求項２５に記載の方法。
【請求項２７】
　少なくとも１つのキャッシュ・オブジェクトが、前記システムによって排他的に管理および制御される、請求項２４に記載の方法。
【請求項２８】
　少なくとも１つのキャッシュ・オブジェクトの処理を、特定のオペレーティング・システム環境に適合させるステップをさらに含む、請求項２７に記載の方法。
【請求項２９】
　少なくとも１つのキャッシュ・オブジェクトの処理を適合させる前記ステップは、少なくとも１つのキャッシュ・オブジェクトの処理を、使用されているページング可能メモリの量、自由に使用できるページング可能メモリの量、前記システム内のページング可能メモリの合計量、前記カーネル内のページング可能メモリの合計量、使用されている非ページング可能メモリの量、自由に使用できる非ページング可能メモリの量、前記システム内の非ページング可能メモリの合計量、前記カーネル内の非ページング可能メモリの合計量、使用されているシステム・ページ・テーブル・エントリの数、使用可能なシステム・ページ・テーブル・エントリの数、前記システム・ページ・テーブルに割り振られた仮想メモリの量、システム・キャッシュのサイズ、システム・キャッシュで使用可能な空間の量、システム・キャッシュで使用されている空間の量、システム・ワーキング・セットのサイズ、使用中のシステム・バッファの数、使用可能なシステム・バッファの数、システム・バッファの数、ページ・サイズ、確立されたネットワーク接続の数、１つまたは複数の中央処理装置（ＣＰＵ）の利用度、割り振られたワーカ・スレッドの数、アイドル状態のワーカ・スレッドの数、ビジーなワーカ・スレッドの数、割り振られたキャッシュ・オブジェクトの数、カーネル内で消費されたＣＰＵ時間の割合、単位時間毎のシステム割込みの数、単位時間毎のページ・フォルトの数、単位時間毎のシステム・キャッシュ内のページ・フォルトの数、単位時間毎のページング済みプール割り振りの数、単位時間毎の非ページング・プール割り振りの数、ルック・アサイド・リストの長さ、オープン・ファイル・ディスクリプタの数、ディスク上の空き空間の量、および割込みレベル、あるいは高割込み要求レベルで消費された時間の割合のうちの少なくとも１つに基づいて適合させるステップを含む、請求項２８に記載の方法。
【請求項３０】
　少なくとも１つのデータ構造を提供するステップをさらに含み、
　少なくとも１つのキャッシュ・オブジェクトをルックアップする前記ステップは、少なくとも１つのキャッシュ・オブジェクトを前記少なくとも１つのデータ構造によりルックアップするステップを含む、
　請求項２４に記載の方法。
【請求項３１】
　前記少なくとも１つのデータ構造が、前記システムによって制御される、請求項３０に記載の方法。
【請求項３２】
　前記少なくとも１つのデータ構造は、少なくとも１つのハッシュ・テーブル、少なくとも１つのリンク・リスト、少なくとも１つのツリー、少なくとも１つのヒープ、および少なくとも１つのキューのうちの少なくとも１つを含む、請求項３１に記載の方法。
【請求項３３】
　前記複数のデータ・ソースに関係する詳細を格納するための揮発性記憶域を提供するステップをさらに含む、請求項２４に記載の方法。
【請求項３４】
　前記少なくとも１つのキャッシュ・オブジェクトは、前記複数のデータ・ソースの前記格納された詳細を使用して、前記複数のデータ・ソースとのコヒーレンシを維持する、請求項３３に記載の方法。
【請求項３５】
　前記少なくとも１つのキャッシュ・オブジェクトのいずれかの区分が、前記複数のデータ・ソースのいずれかの区分の単一のインスタンスに関連付けられる、請求項２４に記載の方法。
【請求項３６】
　前記複数のデータ・ソースからのデータを格納するための任意の構成は、前記複数のデータ・ソースに関係する詳細を格納するための任意の構成から独立している、請求項３５に記載の方法。
【請求項３７】
　前記複数のデータ・ソースは、前記少なくとも１つのキャッシュ・オブジェクトから独立している、請求項３６に記載の方法。
【請求項３８】
　前記複数のデータ・ソースからの前記データは、アプリケーション固有である、請求項２４に記載の方法。
【請求項３９】
　前記複数のデータ・ソースからの前記データは、アプリケーション独立である、請求項２４に記載の方法。
【請求項４０】
　少なくとも１つのキャッシュ・オブジェクトを削除するための構成を提供するステップをさらに含む、請求項２４に記載の方法。
【請求項４１】
　前記少なくとも１つのキャッシュ・オブジェクトの移植中に、前記複数のデータ・ソースからのデータがクライアント・アプリケーションに送信されることを許可するステップをさらに含む、請求項２４に記載の方法。
【請求項４２】
　前記クライアント・アプリケーションは、要求パラメータの任意の必要な構文解析、前記複数のデータ・ソースによって提供された以外の任意の必要なアプリケーション固有の応答データの生成、少なくとも１つのデータのタイプの選択、および前記複数のデータ・ソースの作成のうちの少なくとも１つを実施する、請求項２４に記載の方法。
【請求項４３】
　前記複数のデータ・ソースは、ファイル・システム、ＨＴＴＰサーバ、およびユーザ・レベル・アプリケーションのうちの少なくとも１つを含む、請求項２４に記載の方法。
【請求項４４】
　キャッシュされたコンテンツを要求に応じて返すステップをさらに含む、請求項２４に記載の方法。
【請求項４５】
　キャッシュされたコンテンツを返す前記ステップは、少なくとも１つのキャッシュ・オブジェクトの前記データを要求に応じて返すステップを含む、請求項４４に記載の方法。
【請求項４６】
　キャッシュされたコンテンツを返す前記ステップは、キャッシュ・オブジェクトを使用して、少なくとも１つの包含キャッシュ・オブジェクトの前記データを返すステップを含む、請求項４４に記載の方法。
【請求項４７】
　マシンによって可読なプログラム記憶デバイスであって、オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュするための方法ステップを実行するために、前記マシンによって実行可能な命令のプログラムを具体的に組み込んだプログラム記憶デバイスであり、前記方法は、
　キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するステップと、
　少なくとも１つのキャッシュ・オブジェクトをルックアップするステップと、
　データを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに、前記収集されたデータを移植するステップとを含む、
　プログラム記憶デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は一般にオペレーティング・システムに関し、より詳細には、オペレーティング・システム・カーネル環境内のアプリケーション・データのキャッシングに関する。
【背景技術】
【０００２】
　キャッシングはコンピュータ・サイエンスの多数の分野で見られ、全体として「物を隠したり格納する安全な場所」という辞書の定義（たとえば、「Webster's New World Dictionary of the American」、2nd college ed.、1976年を参照）に一致している。プロセッサは多数のレベルのキャッシュを有することができるが（Hennessy、JohnおよびDavidA Patterson、「Computer Architecture A Quantitative Approach」、2nd ed.、SanFrancisco: Morgan Kaufmann、1996年、375頁を参照）、いくつかのファイル・システムもまたキャッシュを有することができる（Solomon、DavidおよびMarkRussinovich、「Inside Microsoft Windows（Ｒ） 2000」、3rd ed.、Redmond: Microsoft Press、2000年、646頁を参照）。ＨＴＴＰサーバなどのアプリケーション（Fielding、R.他、「RFC2068」、1997年、70頁、http://www.ietf.org/rfc/rfc2068.txt）もこれらを有する可能性がある。さらなる例は多い。いくつかのアプリケーションは、オペレーティング・システム・カーネル内でアプリケーション固有のキャッシュさえ有する（Hu、Elbert他、「AdaptiveFast Path Architecture」、IBM Journal of Research and Development、2001年3月、191〜206頁）。「カーネル」という用語は一般に、オペレーティング・システムのうち特権モードで動作する部分を指すように理解されており、これはオペレーティング・システムのうち基本機能およびサービスを実行する必須の部分である。
【非特許文献１】「Webster's New World Dictionary ofthe American」、2nd college ed.、1976年
【非特許文献２】Hennessy、JohnおよびDavid A Patterson、「ComputerArchitecture A Quantitative Approach」、2nd ed.、San Francisco: Morgan Kaufmann、1996年、375頁
【非特許文献３】Solomon、DavidおよびMark Russinovich、「InsideMicrosoft Windows（Ｒ） 2000」、3rd ed.、Redmond: Microsoft Press、2000年、646頁
【非特許文献４】Fielding、R.他、「RFC 2068」、1997年、70頁、http://www.ietf.org/rfc/rfc2068.txt
【非特許文献５】Hu、Elbert他、「Adaptive Fast Path Architecture」、IBMJournal of Research and Development、2001年3月、191〜206頁
【非特許文献６】Berners-Lee、T.、他、「RFC1945」、1996年、http://www.ietf.org/rfc/rfc1945.txt
【非特許文献７】W. Richard Stevens、「TCP/IPIllustrated」、Volume 1 The Protocols Addison-Wesley、1994年
【発明の開示】
【発明が解決しようとする課題】
【０００３】
　しかし、現在まで、データのソースから独立している、任意の汎用オペレーティング・システム・カーネル環境のキャッシュが存在することは知られていない。したがって、このような欠点の克服に関連した必要性が認識されている。
【課題を解決するための手段】
【０００４】
　本発明の少なくとも１つの現在好ましい実施形態によれば、アプリケーション固有およびアプリケーション独立のデータの両方をキャシングし、かつこのようなデータを本質的にいかなるアプリケーション・プロトコルを介しても配信することができる汎用オペレーティング・システム・カーネル・キャッシュが広く企図される。データは様々なソースから来ることができ、多数のカーネル固有機構を使用してカーネル・キャッシュに格納されることができる。キャッシュを管理するためのシステムも、本明細書で広く企図される。
【０００５】
　要約すると、本発明は、一態様では、オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュするためのシステムを提供し、このシステムは、キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するための構成、少なくとも１つのキャッシュ・オブジェクトをルックアップするための少なくとも１つの構成、およびデータを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに収集されたデータを移植する（populating）ための構成を含む。
【０００６】
　もう１つの態様では、本発明はオペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュする方法を提供し、この方法はキャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するステップ、少なくとも１つのキャッシュ・オブジェクトをルックアップするステップ、およびデータを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに収集されたデータを移植するステップを含む。
【０００７】
　さらに、追加の態様では、本発明はマシンによって可読なプログラム記憶デバイスを提供し、これは、オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュするための方法ステップを実行するために、マシンによって実行可能な命令のプログラムを具体的に組み込み、この方法はキャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するステップ、少なくとも１つのキャッシュ・オブジェクトをルックアップするステップ、およびデータを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに収集されたデータを移植するステップを含む。
【０００８】
　本発明の他および更なる特徴ならび利点と共に本発明をよりよく理解するために、添付の図面と共に以下の説明を参照し、本発明の範囲を添付の特許請求の範囲で示す。
【発明を実施するための最良の形態】
【０００９】
　一般に、本発明の少なくとも１つの現在好ましい実施形態は、高性能ネットワーク・サーバをオーサリングするためのカーネル・ランタイム環境に関係する。本発明の一態様は、Ｎソース・カーネル内キャッシュ（N-source In-kernel Cache；ＮＩＣａｃｈｅ）に関係する。ＮＩＣａｃｈｅは、１つまたは複数のアプリケーションがオペレーティング・システムを高性能にするために拡張することを可能にする。ここで論じる、ＮＩＣａｃｈｅにより拡張されるアプリケーションは、AdaptiveFast Path Architecture（ＡＦＰＡ）である。ＡＦＰＡはカーネル内ネットワーク・サーバ・アクセラレータであり、多数の別個のソースからのデータを供給する。ＮＩＣａｃｈｅはスタンドアロン・アプリケーションではなく、１つまたは複数のアプリケーションによって使用されなければならないことを理解されたい。
【００１０】
　以下は、本明細書で使用されるいくつかの有用な用語の詳細な定義である。
【００１１】
　「コールバック関数」は離散コードへの参照、即ち、後の望ましい時間に指定され、呼び出される関数として理解することができる。この技術はしばしば、関数がイベントの結果として呼び出されることを望む、あるいは関数が同期的に呼び出されることを望まないプログラマによって使用される。たとえば、信号ハンドラは、信号が生じたとき、プログラマによって書かれた関数を実行する。
【００１２】
　「ハッシュ・テーブル」は、プログラマによってデータを格納するために使用されるデータ構造として理解することができる。ハッシュ・テーブルは、集合のＫ個の要素を格納するのに十分大きい格納機構を使用する必要なしに、テーブル内の要素の高速直接アドレス指定を提供する。ハッシュ・テーブルは、通常はハッシュ関数と呼ばれる関数を各データ要素に適用して、テーブルへのインデックスを決定する。ハッシュ・テーブルは通常、固定長である。
【００１３】
　「リンク・リスト」は、プログラマによってデータを格納するために使用されるデータ構造として理解することができる。リンク・リストはデータを線形に格納し、通常はリストの前方または後方へのアクセスを有する。リンク・リストは固定長ではなく、容易に増大される。リンク・リストを探索するために必要とされる時間の量は一般に、リスト内の項目の数により線形に増大する。
【００１４】
　ここで、本発明の好ましい実施形態の説明に戻ると、図１に例示したようなネイティブ・カーネル環境１１０は、オペレーティング・システムのアドレス空間、実行コンテキスト、セキュリティ属性など、通常はユーザ・レベル・アプリケーションから隠されたものを含むことができる。ネイティブ・カーネル環境はアプリケーションに露出されたサービスをユーザ空間で実施し、カーネル・エクステンションを書くためのサービスを提供することができる。
【００１５】
　「ネイティブ」という用語は「カーネル環境」への修飾語句として使用され、特定のカーネル環境を指す。たとえば、ＡＩＸ、ＬｉｎｕｘおよびＷｉｎｄｏｗｓ（Ｒ）のオペレーティング・システムは、すべて独特のネイティブ・カーネル環境を有する。これらはそれぞれに、サブシステム（ネットワーク・アダプタ・ドライバ、ビデオ・ドライバ、またはカーネル・エクステンションなど）を書くための特定の１組のアプリケーション・プログラム・インターフェース（ＡＰＩ）を有するので、独特である。Ｗｉｎｄｏｗｓ（Ｒ）は、数百ものＡＰＩをそのネイティブ・カーネル環境内で提供する。ＡＩＸおよびＬｉｎｕｘは、それぞれ異なるＡＰＩを有する。さらに、これらのオペレーティング・システムの環境は、ファイル・システムとＴＣＰ／ＩＰサブシステムが対話する方法において異なる。
【００１６】
　Ｎソース・カーネル内キャッシュ（ＮＩＣａｃｈｅ）１３０は、これらのＡＰＩをカーネル・エクステンションとして使用する。通常、ＮＩＣａｃｈｅは、１つまたは複数のアプリケーション１２０と共に、あるいはその内部で使用される。アプリケーションもまた、その目的が何であれ、ネイティブ・カーネル環境１１０内で実行する。本発明の好ましい実施形態では、ＨＴＴＰサーバ・アクセラレータがアプリケーションであり、ＮＩＣａｃｈｅがアプリケーションにリンクされる。すなわち、ＮＩＣａｃｈｅをアプリケーションの外部でスタンドアロン実行可能ユニットとして実行することはできない。アプリケーション自体は複数の実行ユニットを有することができ、これにはユーザ空間内で実行するエクステンションが含まれる。アプリケーション・エクステンション１４０はネイティブ・カーネル環境内で実行せず、ユーザ空間内で実行することが好ましい。
【００１７】
　アプリケーション・エクステンション１４０をＨＴＴＰサーバの一部にすることができ、これは受信されたＨＴＴＰ要求に基づいて動的コンテンツを生成する。アプリケーションがサーバをカーネルおよびユーザ・コンポーネントに分離することは有用である。この手法により、サーバを書く者が、サーバの何の部分をユーザ空間内に置く必要があるか、および何の部分をカーネル内に置く必要があるかを念入りに選ぶことを可能にする。たとえば、コモン・ゲートウェイ・インターフェース（ＣＧＩ）がユーザ空間保護を必要とするため、ＨＴＴＰサーバは常にクライアントのＣＧＩ要求をカーネル内ではなくユーザ空間で実行することを望む。
【００１８】
　本発明の好ましい実施形態では、アプリケーションは、GET、HEAD、およびPOSTの要求を含むＨＴＴＰ要求を処理する。応答がキャッシュ内に存在する場合、そのときは要求がカーネルからサービスされる。しかし、ＨＴＴＰ要求が動的コンテンツ（たとえば、ＣＧＩ要求）についての要求である場合、そのときはアプリケーション・エクステンション１４０に処理が委ねられる。アプリケーション・エクステンションは、ユーザ空間実行コンテキストを必要とする要求のいずれの部分も実行する。
【００１９】
　ＮＩＣａｃｈｅ１３０は、それに付随するアプリケーション１２０にＡＰＩを提供する。このＡＰＩへのすべてのコールが、キャッシュ・オブジェクト・マネージャ２１０（図２を参照）を通じて一か所に集められる。図２に進むと、キャッシュ・オブジェクト・マネージャ２１０は好ましくはあらゆるコールをＮＩＣａｃｈｅにプロキシし、すべての内部コンポーネントおよびロジックを管理する。その任務を最適に実行するため、キャッシュ・オブジェクト・マネージャは物理メモリ利用度またはＣＰＵ利用度などのマシンのハードウェアの状態を２６０で問い合わせることができる。ネイティブ・カーネル環境の状態、すなわち、非ページング・プール使用量（non-paged pool usage）または空きページ・ディスクリプタの数についても、２６０で問い合わせることができる。
【００２０】
　キャッシュされたコンテンツは、ＮＩＣａｃｈｅがアプリケーションに代わってキャッシュ中であるデータである。より詳細には、アプリケーションによって、データが検索しやすいシステムに格納されることを必要としたデータである。このデータを、任意のソースから生成された、ＡＳＣＩＩまたはバイナリなどの任意のフォーマットにすることもできる。キャッシュされたコンテンツにおける制限は、ネイティブ・カーネル環境の制限である。データの各部分は、そのソースによって決定される。ソースには、ユーザ・レベル・プログラムからの出力、ＨＴＴＰ　ＧＥＴ要求への応答、またはローカル・ファイルあるいはリモート・ファイルのコンテンツが含まれる可能性がある。キャッシュ・コンテンツは、キャッシュ・オブジェクト２３０、２３１、２３２に格納される。キャッシュ・オブジェクトは、要求されたデータを、特定のカーネル機構を使用して格納またはキャッシュするための構造および手続きである。これらの機構には、ファイル・システム・キャッシュ、ピン・メモリ、またはページング可能メモリが含まれる可能性があり、様々なキャッシュ・オブジェクト・タイプまたはクラスを表すことができる。各キャッシュ・オブジェクトを、場合によっては、アプリケーションによって提供されたディスクリプタまたは探索キーに関連付けることができる。
【００２１】
　キャッシュ・コンテンツを維持し、位置付けるために、キャッシュ・オブジェクト・マネージャ２１０は任意の数のコンテナ・データ構造２２０を利用する。これらのコンテナは、キャッシュ・オブジェクト２３０への参照を各コンテナに固有の方法で保持することが好ましい。たとえば、コンテナは、リンク・リスト２２１、ハッシュ・テーブル２２０、２分木、またはアレイを含むことができる。リンク・リスト・コンテナ２２１は、二重にリンクされたリストのヘッド・キャッシュ・オブジェクトへの参照２５０を有することが好ましい。ハッシュ・テーブル・コンテナ２２０は、ハッシュ・テーブルに格納されたすべてのキャッシュ・オブジェクトへの参照２７０を保持する。各キャッシュ・オブジェクトへの参照を少なくとも１つのコンテナに格納しなければならない。キャッシュ・オブジェクト・マネージャ２１０は、どのコンテナがどのキャッシュ・オブジェクトを保持するかについての単独の決定権を有することが好ましい。他のコンテナは、データのソース、使用されているあるシステム・リソースの量、または他の基準に基づいてキャッシュ・オブジェクトをソートするために使用されることができる。
【００２２】
　各キャッシュ・オブジェクトが、単一のデータ・ソースに関連付けられることが好ましい。データ・ソースはキャッシュ・オブジェクトのデータが生じたところを表し、以下でより詳細に説明する。データ・ソースは、キャッシュ・オブジェクトに代わってネイティブ・カーネル環境１１０と、２１５、２２５、２３５で通信する。そのデータ・ソース２４０、２４１、２４２を位置付けるために、各キャッシュ・オブジェクト２３０、２３１、２３２はデータ・ソースへの参照２８０を維持することが好ましい。同様に、データ・ソースはキャッシュ・オブジェクトに戻る参照２９０を所有することが好ましい。
【００２３】
　ＮＩＣａｃｈｅ１３０は、いかなるタイプの、任意の数のキャッシュ・オブジェクトをも同時にサポートすることが好ましい。さらに、ＮＩＣａｃｈｅ１３０は、多数のソースからのデータを同時にサポートすることができる。いかなるタイプのキャッシュ・オブジェクトも任意のソースから移植することができる。たとえば、そのコンテンツをピン・メモリに格納するキャッシュ・オブジェクトは、ローカル・ファイルから、あるいは場合によってはＨＴＴＰ応答からコンテンツを受信することができる。分りやすく言えば、キャッシュ・オブジェクトは、キャッシュされたコンテンツを格納する。データのソースは、そのコンテンツがどこから来たかを識別し、コンテンツを検索するために構成される。各キャッシュ・オブジェクトが単一のデータ・ソースに関連付けられ、その逆もまた同様である。どのタイプのキャッシュ・オブジェクトをどのタイプのデータ・ソースとペアにすることができるか、およびその逆における制限はないことが好ましい。
【００２４】
　図３を見ると、ＮＩＣａｃｈｅ１３０は通常、１つまたは複数のアプリケーション１２０からの要求に反応することができる。キャッシュとして、ＮＩＣａｃｈｅ１３０は、Lookup/Find３１０、Store/Create３５０、およびRemove/Delete３８０の要求に応答する。前述の要求などのキャッシュ・オブジェクトのオペレーションについてのすべての要求が、キャッシュ・オブジェクト・マネージャ２１０に対して行われることが好ましい。キャッシュ・オブジェクト・マネージャ２１０は好ましくはすべてのキャッシュ・オブジェクトを管理し、従ってすべての外部要求を処理する。アプリケーション１２０がキャッシュされるべきデータを有するとき、アプリケーション１２０は、好ましくはcreateコマンドをＮＩＣａｃｈｅ１３０に発行し、これにデータ・ソースへの参照（データではない）を渡す。データ・ソース内のフィールド、システムの現在状態およびＮＩＣａｃｈｅの現在状態について２６０で収集された情報に基づいて、キャッシュ・オブジェクト・マネージャ２１０は、どの格納機構を使用してデータを格納するべきであるか（すなわち、使用するべきキャッシュ・オブジェクトのタイプ）を決定することが好ましい。キャッシュ・オブジェクト・タイプが決定された後、そのタイプのキャッシュ・オブジェクト３３０が好ましくは３６０で作成され、そのキャッシュ・オブジェクトへの参照が１つまたは複数の適切なコンテナ２２０、２２１に、３６１、３６２で格納される。新たに作成されたキャッシュ・オブジェクトへの参照が、アプリケーション１２０に３７０で返される。
【００２５】
　逆に、アプリケーション１２０がコンテンツをキャッシュから除去しようとするとき、アプリケーション１２０は、好ましくはキャッシュ・オブジェクトを削除するためにＮＩＣａｃｈｅ１３０へのコールを３８０で行い、除去されるべきキャッシュ・オブジェクトへの参照を渡す。キャッシュ・オブジェクト・マネージャ２１０はアプリケーション１２０からの要求３８０を、キャッシュ・オブジェクトへの参照を含む任意のコンテナ２２０、２２１に除去手続き３９０、３９１を呼び出し、次いでdeleteコマンドをキャッシュ・オブジェクト３３０に発行することによって処理する。キャッシュ・オブジェクトは、キャッシュされたコンテンツを格納するために使用していた任意の揮発性および場合によっては不揮発性記憶域をクリーン・アップすることが好ましい。これらのタスクが完了すると、キャッシュ・オブジェクト・マネージャ２１０は、キャッシュ・オブジェクト・データ構造自体によって使用されたすべての揮発性記憶域を削除することが好ましい。
【００２６】
　キャッシュのＮＩＣａｃｈｅ１３０に格納されたデータがアプリケーションによって必要とされるとき、lookup要求３１０が識別子に基づいてキャッシュ・オブジェクトについて作成されることが好ましい。本発明の例示的実施形態では、この識別子はＨＴＴＰユニバーサル・リソース識別子（ＵＲＩ）（Berners-Lee、T.、他、「RFC1945」、1996年、http://www.ietf.org/rfc/rfc1945.txt）を含む。キャッシュ・オブジェクトがＮＩＣａｃｈｅのコンテナの少なくとも１つにある場合、これはアプリケーション１２０へ３１２で返される。また、この実施形態に含まれるものは「高速探索コンテナ」の概念、即ち、識別子に関するルックアップが一定時間内で行われるコンテナの概念であり、キャッシュ・オブジェクト・マネージャはこのコンテナを配置する方法を理解している。ＮＩＣａｃｈｅの好ましい実施態様は、ハッシュ・テーブル２２０をこの目的のために使用する。キャッシュ・オブジェクト・マネージャがルックアップ・コール３２０をこの高速コンテナに発行して、識別子の下に格納されたデータを発見することは言うまでもない。配置された後、コンテナは３４０でキャッシュ・オブジェクトをキャッシュ・オブジェクト・マネージャ２１０に返し、これは３１２でキャッシュ・オブジェクト（または見つからなかったこと）をアプリケーションに返す。これらのアクションを同期的または非同期的に行うことができる。
【００２７】
　ＮＩＣａｃｈｅ１３０の好ましい実施態様は、リンク・リスト・コンテナ２２１を２つのコンテナ２２１、２２０の一方として含む。このリンク・リストは、重み付けされた最低使用頻度（Least Recently Used；ＬＲＵ）アルゴリズムを使用してソートされることが好ましい。キャッシュ・オブジェクトがlookup要求３１０の結果として返される度に、キャッシュ・オブジェクトがリンク・リストの先頭に移動されることが好ましい。これにより、最近最もアクセスされていないキャッシュ・オブジェクトが確実にリストの末尾に向かう。この情報は、リソースに制約のある環境内などのキャッシュ・オブジェクトがキャッシュから除去されなければならないときに有用となる。
【００２８】
　キャッシュ・オブジェクトの多数の異なるクラスはキャッシュ・オブジェクトの多数の別個の実施につながるが、すべてのキャッシュ・オブジェクトが一般に、ある部分を有することが必要とされる。次に図４および５を見ると、キャッシュ・オブジェクトが、データのソースが除去されているのでキャッシュ・オブジェクト自体が除去されなければならないことをキャッシュ・オブジェクト・マネージャに通知する必要がある場合に、キャッシュ・オブジェクト・マネージャ２１０への参照４５０が維持されることが好ましい。メタ・データ構造４１０は、このキャッシュ・オブジェクトを説明する情報を所有することが好ましい。ネットワーク・プロトコル・ヘッダを生成するために必要とされた情報は、ここで発見される。あらゆるキャッシュ・オブジェクトは、単一のメタ・データへの参照４６０を含むことが好ましい。同様に、各キャッシュ・オブジェクトは利用度（utilization）４２０への参照４７０を維持することが好ましく、利用度４２０はその対応するキャッシュ・オブジェクト２３０のシステム・リソース利用度を説明するものである。キャッシュ・オブジェクトは、包含キャッシュ・オブジェクト４３０のリストへの参照４４０を含むことが好ましい。キャッシュ・オブジェクトへのデータがアプリケーションによって要求されるとき、包含キャッシュ・オブジェクトからのデータが元のキャッシュ・オブジェクトのデータに加えて返される。包含キャッシュ・オブジェクト構造４３０は、包含キャッシュ・オブジェクトのデータを送信するために、順序付けなどのルールを含むことができる。キャッシュ・オブジェクトのタイプ固有部分４３０は、キャッシュ・オブジェクトによって使用されたあらゆるデータおよび参照を含み、キャッシュされたコンテンツをタイプ定義方法で維持することが好ましい。データ・ソース２４０は、それらの個々のキャッシュ・オブジェクト２３０への参照２９０およびその逆の参照２８０を維持することができる。図４および５はこの関連付けを示す。
【００２９】
　キャッシュ・オブジェクトへの参照２９０に加えて、あらゆるデータ・ソースが、（もし、あれば）データのサイズおよび（もし、あれば）データが期限切れになる時間を保持することが好ましい。データのソースおよびソースからコンテンツを検索する方法についての固有の情報が、データ・ソース２４０のタイプ固有５１０の部分に含まれることが好ましい。
【００３０】
　図６を見ると、アプリケーション１２０が情報をキャッシュ・オブジェクト２３０から抽出しようと意図するとき、任意選択でデータについてのオフセットおよび長さを含む要求６１０を発行することが好ましい。ＮＩＣａｃｈｅの現在好ましい実施態様では、アプリケーションはこのような要求６１０を、クライアントに送信するためにコンテンツが必要とされるときにのみ発行する。加えて、キャッシュ・オブジェクトはコンテンツをあらかじめ満たさない。従って、データについての要求６１０がキャッシュ・オブジェクトに行われるとき、データは存在しない（すなわち、キャッシュ・オブジェクト内に格納されていない）場合がある。データが存在する場合、キャッシュ・オブジェクトが６２０でコンテンツを即時に返す。キャッシュ・オブジェクトの包含キャッシュ・オブジェクトの構造４３０におけるルールに基づいて、次いでキャッシュ・オブジェクトは要求６２０を包含キャッシュ・オブジェクトに向けて送ることができる。コンテンツがキャッシュ・オブジェクト内に存在しない場合、そのときは、コール６１０が保留状況コードと共に返り、キャッシュ・オブジェクトが任意選択でオフセットおよび長さを含むコール６３０を、データを要求するそのデータ・ソースに行う。データ・ソースがすでに要求された情報をソースから有しているとき、要求６３０が即時に返され、次いでデータをアプリケーション１２０へ戻す６２０で渡す。しかし、データ・ソースがカーネル機構を介してデータのソースと６１５で接触して、データの最近のコピーを得なければならない場合がある。この場合、キャッシュ・オブジェクトのコール６３０が保留状況コードと共に返される一方でデータ・ソースはソースがデータを返すのを待機する。データ・ソースが、キャッシュ・オブジェクトによって必要とされたコンテンツの一部またはすべてを受信すると、キャッシュ・オブジェクトが６４０でデータと共にコール・バックされ、これによりキャッシュ・オブジェクトにデータをアプリケーション１２０へ、６２０で返させる。キャッシュ・オブジェクト・コールバック６４０が、データ・ソースへの単一の要求６３０について複数回コールされる場合がある。この二重層非同期インターフェースは、アプリケーションおよびキャッシュ・オブジェクトが待機することを防止する。これによりアプリケーション１２０が、データ６１０についての要求を割込みレベルまたは高割込み要求レベル（ＩＲＱＬ）で提出することを可能にする。
【００３１】
　前述のように、データ・ソースはネイティブ・カーネル環境１１０と通信して、６１５で項目によって示されたデータの最近のコピーを得る。図７は、ネイティブ・カーネル環境１１０内で発見することができる、異なるサブコンポーネントに焦点を合わせる。名称および潜在的なグループ化はオペレーティング・システムの間で変わるが、これらのコンポーネントはすべて、ＡＩＸ、ＬｉｎｕｘおよびＷｉｎｄｏｗｓ（Ｒ）などの商用オペレーティング・システムに特徴として存在する。これらのコンポーネントの多数は、潜在的にＮＩＣａｃｈｅによって使用されることができる。
【００３２】
　ファイル・システム７１０は、オペレーティング・システムのうち、不揮発性記憶域とのデータの転送を処理する部分である。この記憶域を、同じ物理的マシン内に配置するか、あるいはネットワークを介して配置する物理的または論理的ディスク・ドライブとすることができる。これらのファイルからのデータを使用して、キャッシュ・オブジェクトを移植することができる。ＮＩＣａｃｈｅデータ・ソースはファイル・システムＡＰＩを通信７１５で使用してファイルを作成し、ファイルを開き、ファイル・ハンドルを検索し、データを読み取り、およびデータの書き込みを行うことができる。図８は、どのようにして例示的実施形態におけるファイル・データ・ソース８００がファイル・オープン要求８１０をファイル・システム７１０に発行し、ファイル・ハンドル８２０が返されるかを示す。
【００３３】
　メモリ・マネージャ７２０は、仮想メモリの割り振り、割り振り解除および管理、ハードウェア・メモリ例外の解決、およびページ・テーブルの管理（上記のSolomonおよびRussinovich、380頁を参照）を担うシステム・サービスのセットである。データ・ソースは、キャッシュ・オブジェクトのゲット・データ要求６３０を満たすために、メモリ（ピン・メモリ、非ページング・プールなど）を７２５で割り振るか、あるいは共有メモリにアクセスする必要がある場合がある。
【００３４】
　カーネルのネットワーク・スタック７３０は通常、W. Richard Stevens、「TCP/IPIllustrated」、Volume 1 The Protocols Addison-Wesley、1994年に詳細に説明されているように、ネットワークを介してデータを送信および受信する。データ・ソースは、そのデータをネットワーク・スタック７３０との対話７３５から得ることができる。図９は、ＨＴＴＰデータ・ソース９００がカーネルのネットワーク・スタック７３０を利用してＨＴＴＰ要求９１０をＨＴＴＰサーバに送信する（Berners-Lee、T.、他、「RFC1945」、1996年、http://www.ietf.org/rfc/rfc1945.txtを参照）、ＮＩＣａｃｈｅの例示的実施形態を示す。データ・ストリーム９２０の形式で、これらのＨＴＴＰ要求への応答は、ＨＴＴＰデータ・ソース９００へ戻るように経路指定される。様々なデータ・ソースを、ネットワーク・スタック７３０の使用を必要とする他のネットワーク・プロトコルに基づいて構築することができる。
【００３５】
　プロセスおよびスレッド７４０は、同じマシン上でＮＩＣａｃｈｅとして、しかし異なるコンテキストで実行するいかなるプログラムも参照する。データ・ソースは別のプロセスまたはスレッドと、ネイティブ・カーネル環境１１０によって提供されたプロセス間通信機構を介して７４５で通信することができる。
【００３６】
　図１０は、例示的実施形態におけるデータ・ソースのクラスであるユーザ・レベル・データ・ソース１０００を示し、これは実行の別のプログラムまたはスレッド１０３０と対話する。データについての要求１０１０およびデータを含む応答１０２０が、カーネル機構を介して、ソケット、ストリーム、共有メモリ、信号、またはパイプを含む、プロセス間通信のために交信される。
【００３７】
　本発明は、少なくとも１つの現在好ましい実施形態によれば、キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するための構成と、少なくとも１つのキャッシュ・オブジェクトをルックアップするための少なくとも１つの構成と、データを複数のデータ・ソースから収集して、少なくとも１つのキャッシュ・オブジェクトに、収集されたデータを移植するための構成とを含むことを理解されたい。合わせて、これらの要素を、適切なソフトウェア・プログラムを実行する少なくとも１つの汎用コンピュータ上で実施することができる。これらをまた、少なくとも１つの集積回路または少なくとも１つの集積回路の一部で実施することもできる。したがって、本発明をハードウェア、ソフトウェア、または両方の組み合わせにおいて実施できることを理解されたい。
【００３８】
　本明細書で他に述べられていない場合、本明細書で言及および引用したすべての特許、特許出願、特許公報および他の出版物（ウェブ・ベースの出版物を含む）は、全体が本明細書で述べられているかのように、参照により本明細書に完全に組み込まれる。
【００３９】
　本発明の例示的実施形態を添付の図面を参照して説明したが、本発明はこれらの正確な実施形態に限定されないこと、および本発明の範囲または精神から逸脱することなく、当業者が様々な他の変更および修正をその中で実施することができることを理解されたい。
【００４０】
　まとめとして、本発明の構成に関して以下の事項を開示する。
【００４１】
（１）オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュするためのシステムであって、
　キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するための構成と、
　少なくとも１つのキャッシュ・オブジェクトをルックアップするための少なくとも１つの構成と、
　データを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに前記収集されたデータを移植するための構成と
　を含む、システム。
（２）少なくとも１つのキャッシュ・オブジェクトが、前記オペレーティング・システムに固有の少なくとも１つの格納機構を使用するように適合される、上記（１）に記載のシステム。
（３）少なくとも１つの格納機構は、独立キャッシュ・オブジェクト・タイプおよび独立キャッシュ・オブジェクト区分のうちの少なくとも１つに対応する、上記（２）に記載のシステム。
（４）少なくとも１つのキャッシュ・オブジェクトが、前記システムによって排他的に管理および制御される、上記（１）に記載のシステム。
（５）少なくとも１つのキャッシュ・オブジェクトの処理を、特定のオペレーティング・システム環境に適合させるための構成をさらに含む、上記（４）に記載のシステム。
（６）少なくとも１つのキャッシュ・オブジェクトの処理を適合させるための前記構成が、少なくとも１つのキャッシュ・オブジェクトの処理を、使用されているページング可能メモリの量、自由に使用できるページング可能メモリの量、前記システム内のページング可能メモリの合計量、前記カーネル内のページング可能メモリの合計量、使用されている非ページング可能メモリの量、自由に使用できる非ページング可能メモリの量、前記システム内の非ページング可能メモリの合計量、前記カーネル内の非ページング可能メモリの合計量、使用されているシステム・ページ・テーブル・エントリの数、使用可能なシステム・ページ・テーブル・エントリの数、前記システム・ページ・テーブルに割り振られた仮想メモリの量、システム・キャッシュのサイズ、システム・キャッシュで使用可能な空間の量、システム・キャッシュで使用されている空間の量、システム・ワーキング・セットのサイズ、使用中のシステム・バッファの数、使用可能なシステム・バッファの数、システム・バッファの数、ページ・サイズ、確立されたネットワーク接続の数、１つまたは複数の中央処理装置（ＣＰＵ）の利用度、割り振られたワーカ・スレッドの数、アイドル状態のワーカ・スレッドの数、ビジーなワーカ・スレッドの数、割り振られたキャッシュ・オブジェクトの数、カーネル内で消費されたＣＰＵ時間の割合、単位時間毎のシステム割込みの数、単位時間毎のページ・フォルトの数、単位時間毎のシステム・キャッシュ内のページ・フォルトの数、単位時間毎のページング済みプール割り振りの数、単位時間毎の非ページング・プール割り振りの数、ルック・アサイド・リストの長さ、オープン・ファイル・ディスクリプタの数、ディスク上の空き空間の量、および割込みレベル、あるいは高割込み要求レベルで消費された時間の割合のうちの少なくとも１つに基づいて適合させるように構成される、上記（５）に記載のシステム。
（７）少なくとも１つのキャッシュ・オブジェクトをルックアップするための前記少なくとも１つの構成は、少なくとも１つのデータ構造を含む、上記（１）に記載のシステム。
（８）前記少なくとも１つのデータ構造が、前記システムによって制御される、上記（７）に記載のシステム。
（９）前記少なくとも１つのデータ構造は、少なくとも１つのハッシュ・テーブル、少なくとも１つのリンク・リスト、少なくとも１つのツリー、少なくとも１つのヒープ、および少なくとも１つのキューのうちの少なくとも１つを含む、上記（８）に記載のシステム。
（１０）前記複数のデータ・ソースに関係する詳細を格納する揮発性記憶域をさらに含む、上記（１）に記載のシステム。
（１１）前記少なくとも１つのキャッシュ・オブジェクトが、前記複数のデータ・ソースの前記格納された詳細を使用して、前記複数のデータ・ソースとのコヒーレンシを維持するように適合される、上記（１０）に記載のシステム。
（１２）前記少なくとも１つのキャッシュ・オブジェクトのいずれかの区分が、前記複数のデータ・ソースのいずれかの区分の単一のインスタンスに関連付けられる、上記（１）に記載のシステム。
（１３）前記複数のデータ・ソースからのデータを格納するためのいずれかの構成は、前記複数のデータ・ソースに関係する詳細を格納するためのいずれかの構成から独立している、上記（１２）に記載のシステム。
（１４）前記複数のデータ・ソースは、前記少なくとも１つのキャッシュ・オブジェクトから独立している、上記（１３）に記載のシステム。
（１５）前記複数のデータ・ソースからの前記データは、アプリケーション固有である、上記（１）に記載のシステム。
（１６）前記複数のデータ・ソースからの前記データは、アプリケーション独立である、上記（１）に記載のシステム。
（１７）少なくとも１つのキャッシュ・オブジェクトを削除するための構成をさらに含む、上記（１）に記載のシステム。
（１８）前記少なくとも１つのキャッシュ・オブジェクトの移植中に、前記複数のデータ・ソースからのデータがクライアント・アプリケーションに送信されることを許可するための構成をさらに含む、上記（１）に記載のシステム。
（１９）前記クライアント・アプリケーションは、要求パラメータの任意の必要な構文解析、前記複数のデータ・ソースによって提供された以外の任意の必要なアプリケーション固有の応答データの生成、少なくとも１つのデータのタイプの選択、および前記複数のデータ・ソースの作成のうちの少なくとも１つを実施する、上記（１）に記載のシステム。
（２０）前記複数のデータ・ソースは、ファイル・システム、ＨＴＴＰサーバ、およびユーザ・レベル・アプリケーションのうちの少なくとも１つを含む、上記（１）に記載のシステム。
（２１）キャッシュされたコンテンツを要求に応じて返すための構成をさらに含む、上記（１）に記載のシステム。
（２２）キャッシュされたコンテンツを返すための前記構成が、少なくとも１つのキャッシュ・オブジェクトの前記データを要求に応じて返すように適合される、上記（２１）に記載のシステム。
（２３）キャッシュされたコンテンツを返すための前記構成が、キャッシュ・オブジェクトを使用して、少なくとも１つの包含キャッシュ・オブジェクトの前記データを返すように適合される、上記（２１）に記載のシステム。
（２４）オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュする方法であって、
　キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するステップと、
　少なくとも１つのキャッシュ・オブジェクトをルックアップするステップと、
　データを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに、前記収集されたデータを移植するステップと
　を含む、方法。
（２５）前記作成するステップは、前記オペレーティング・システムに固有の少なくとも１つの格納機構を使用するように適合された、少なくとも１つのキャッシュ・オブジェクトを作成するステップを含む、上記（２４）に記載の方法。
（２６）少なくとも１つの格納機構は、独立キャッシュ・オブジェクト・タイプおよび独立キャッシュ・オブジェクト区分のうちの少なくとも１つに対応する、上記（２５）に記載の方法。
（２７）少なくとも１つのキャッシュ・オブジェクトが、前記システムによって排他的に管理および制御される、上記（２４）に記載の方法。
（２８）少なくとも１つのキャッシュ・オブジェクトの処理を、特定のオペレーティング・システム環境に適合させるステップをさらに含む、上記（２７）に記載の方法。
（２９）少なくとも１つのキャッシュ・オブジェクトの処理を適合させる前記ステップは、少なくとも１つのキャッシュ・オブジェクトの処理を、使用されているページング可能メモリの量、自由に使用できるページング可能メモリの量、前記システム内のページング可能メモリの合計量、前記カーネル内のページング可能メモリの合計量、使用されている非ページング可能メモリの量、自由に使用できる非ページング可能メモリの量、前記システム内の非ページング可能メモリの合計量、前記カーネル内の非ページング可能メモリの合計量、使用されているシステム・ページ・テーブル・エントリの数、使用可能なシステム・ページ・テーブル・エントリの数、前記システム・ページ・テーブルに割り振られた仮想メモリの量、システム・キャッシュのサイズ、システム・キャッシュで使用可能な空間の量、システム・キャッシュで使用されている空間の量、システム・ワーキング・セットのサイズ、使用中のシステム・バッファの数、使用可能なシステム・バッファの数、システム・バッファの数、ページ・サイズ、確立されたネットワーク接続の数、１つまたは複数の中央処理装置（ＣＰＵ）の利用度、割り振られたワーカ・スレッドの数、アイドル状態のワーカ・スレッドの数、ビジーなワーカ・スレッドの数、割り振られたキャッシュ・オブジェクトの数、カーネル内で消費されたＣＰＵ時間の割合、単位時間毎のシステム割込みの数、単位時間毎のページ・フォルトの数、単位時間毎のシステム・キャッシュ内のページ・フォルトの数、単位時間毎のページング済みプール割り振りの数、単位時間毎の非ページング・プール割り振りの数、ルック・アサイド・リストの長さ、オープン・ファイル・ディスクリプタの数、ディスク上の空き空間の量、および割込みレベル、あるいは高割込み要求レベルで消費された時間の割合のうちの少なくとも１つに基づいて適合させるステップを含む、上記（２８）に記載の方法。
（３０）少なくとも１つのデータ構造を提供するステップをさらに含み、
　少なくとも１つのキャッシュ・オブジェクトをルックアップする前記ステップは、少なくとも１つのキャッシュ・オブジェクトを前記少なくとも１つのデータ構造によりルックアップするステップを含む、
　上記（２４）に記載の方法。
（３１）前記少なくとも１つのデータ構造が、前記システムによって制御される、上記（３０）に記載の方法。
（３２）前記少なくとも１つのデータ構造は、少なくとも１つのハッシュ・テーブル、少なくとも１つのリンク・リスト、少なくとも１つのツリー、少なくとも１つのヒープ、および少なくとも１つのキューのうちの少なくとも１つを含む、上記（３１）に記載の方法。
（３３）前記複数のデータ・ソースに関係する詳細を格納するための揮発性記憶域を提供するステップをさらに含む、上記（２４）に記載の方法。
（３４）前記少なくとも１つのキャッシュ・オブジェクトは、前記複数のデータ・ソースの前記格納された詳細を使用して、前記複数のデータ・ソースとのコヒーレンシを維持する、上記（３３）に記載の方法。
（３５）前記少なくとも１つのキャッシュ・オブジェクトのいずれかの区分が、前記複数のデータ・ソースのいずれかの区分の単一のインスタンスに関連付けられる、上記（２４）に記載の方法。
（３６）前記複数のデータ・ソースからのデータを格納するための任意の構成は、前記複数のデータ・ソースに関係する詳細を格納するための任意の構成から独立している、上記（３５）に記載の方法。
（３７）前記複数のデータ・ソースは、前記少なくとも１つのキャッシュ・オブジェクトから独立している、上記（３６）に記載の方法。
（３８）前記複数のデータ・ソースからの前記データは、アプリケーション固有である、上記（２４）に記載の方法。
（３９）前記複数のデータ・ソースからの前記データは、アプリケーション独立である、上記（２４）に記載の方法。
（４０）少なくとも１つのキャッシュ・オブジェクトを削除するための構成を提供するステップをさらに含む、上記（２４）に記載の方法。
（４１）前記少なくとも１つのキャッシュ・オブジェクトの移植中に、前記複数のデータ・ソースからのデータがクライアント・アプリケーションに送信されることを許可するステップをさらに含む、上記（２４）に記載の方法。
（４２）前記クライアント・アプリケーションは、要求パラメータの任意の必要な構文解析、前記複数のデータ・ソースによって提供された以外の任意の必要なアプリケーション固有の応答データの生成、少なくとも１つのデータのタイプの選択、および前記複数のデータ・ソースの作成のうちの少なくとも１つを実施する、上記（２４）に記載の方法。
（４３）前記複数のデータ・ソースは、ファイル・システム、ＨＴＴＰサーバ、およびユーザ・レベル・アプリケーションのうちの少なくとも１つを含む、上記（２４）に記載の方法。
（４４）キャッシュされたコンテンツを要求に応じて返すステップをさらに含む、上記（２４）に記載の方法。
（４５）キャッシュされたコンテンツを返す前記ステップは、少なくとも１つのキャッシュ・オブジェクトの前記データを要求に応じて返すステップを含む、上記（４４）に記載の方法。
（４６）キャッシュされたコンテンツを返す前記ステップは、キャッシュ・オブジェクトを使用して、少なくとも１つの包含キャッシュ・オブジェクトの前記データを返すステップを含む、上記（４４）に記載の方法。
（４７）マシンによって可読なプログラム記憶デバイスであって、オペレーティング・システムのカーネル環境内でアプリケーション・データをキャッシュするための方法ステップを前記マシンによって実行させるための実行可能な命令のプログラムを具体的に組み込んだプログラム記憶デバイスであって、前記方法は、
　キャッシュされたコンテンツをカーネル環境内に格納するための少なくとも１つのキャッシュ・オブジェクトを作成するステップと、
　少なくとも１つのキャッシュ・オブジェクトをルックアップするステップと、
　データを複数のデータ・ソースから収集し、少なくとも１つのキャッシュ・オブジェクトに、前記収集されたデータを移植するステップとを含む、
　プログラム記憶デバイス。
【図面の簡単な説明】
【００４２】
【図１】ランタイム環境を例示するブロック図である。
【図２】異なるインスタンス化オブジェクトおよびそれらの参照を示すインスタンス図である。
【図３】様々なモジュールとオブジェクトの間の対話を例示するブロック図である。
【図４】キャッシュ・オブジェクトのためのメモリ・レイアウトおよび参照を例示する図である。
【図５】データ・ソースのためのメモリ・レイアウトおよび参照を例示するグラフィカル図である。
【図６】データについての要求に関係するオブジェクトとモジュールの間の通信を例示するブロック図である。
【図７】様々なカーネル・コンポーネントを例示するブロック図である。
【図８】ファイル・データ・ソースとその関連付けられたカーネル・コンポーネントの間の通信を例示するブロック図である。
【図９】ＨＴＴＰデータ・ソースとその関連付けられたカーネル・コンポーネントの間の通信を例示するブロック図である。
【図１０】ユーザ空間とカーネル空間の間の通信を例示するブロック図である。
【符号の説明】
【００４３】
　１１０　ネイティブ・カーネル環境
　１２０　アプリケーション
　１３０　Ｎソース・カーネル内キャッシュ（ＮＩＣａｃｈｅ）
　１４０　アプリケーション・エクステンション
　２１０　キャッシュ・オブジェクト・マネージャ
　２２０　ハッシュ・テーブル・コンテナ
　２２１　リンク・リスト・コンテナ
　２３０、２３１、２３２　キャッシュ・オブジェクト
　２４０、２４１、２４２　データ・ソース
　３３０　新しいキャッシュ・オブジェクト
　４１０　メタ・データ構造
　４２０　利用度
　４３０　包含キャッシュ・オブジェクト
　７１０　ファイル・システム
　７２０　メモリ・マネージャ
　７３０　ネットワーク・スタック
　７４０　プロセスおよびスレッド
　８００　ファイル・データ・ソース
　９００　ＨＴＴＰデータ・ソース
　１０００　ユーザ・レベル・データ・ソース
　１０３０　ユーザ・レベル・プログラム
【図１】
2004133931.tif 000003
【図２】
2004133931.tif 000004
【図３】
2004133931.tif 000005
【図４】
2004133931.tif 000006
【図５】
2004133931.tif 000007
【図６】
2004133931.tif 000008
【図７】
2004133931.tif 000009
【図８】
2004133931.tif 000010
【図９】
2004133931.tif 000011
【図１０】
2004133931.tif 000012