JP2009540466A - メディアファイルを管理するためのアプリケーションプログラムインターフェース - Google Patents

Abstract

メディアファイルを管理するためのアプリケーションプログラムインターフェースを説明することができる。装置は、プロセッサおよびメモリを有するメディア処理サブシステムを含むことができる。メモリは、複数のソフトウェアオブジェクトを有するアプリケーションプログラムインターフェースソフトウェアライブラリを格納することができる。プロセッサは、複数のメディアストリームからのメディアコンテンツを格納するのに使用される名前−値対の階層を含む仮想ファイルを管理するために、アプリケーションプログラムインターフェースコマンドに応答してソフトウェアオブジェクトを実行することができる。他の実施形態が説明され、特許請求の範囲に記載される。

Description

本発明は、メディアファイルを管理するためのアプリケーションプログラムインターフェースに関する。

パーソナルビデオレコーダやデジタルビデオレコーダなどのメディア装置を使用して、デジタルメディアコンテンツを格納および複製することができる。デジタルメディアコンテンツの例は、テレビジョン番組、ムービー、ホームビデオ、歌、イメージ、写真などを含むことができる。ケーブルプロバイダ、サテライトプロバイダ、デジタルバーサタイルディスク（ＤＶＤ）プレーヤ、コンパクトディスク（ＣＤ）プレーヤ、デジタルビデオホームシステム、メディアコンテンツプロバイダなどの様々なメディアソースからインターネット接続、コンピュータファイルなどを介してデジタルメディアコンテンツを受け取ることができる。その結果として、メディア装置は、複数のファイルおよびファイルタイプを使用する様々なメディアソースから、ますます多量のメディアコンテンツを格納する必要がある可能性がある。これにより、ファイル管理操作、ファイル構造の複雑さ、および関連するコストが著しく増大する可能性がある。

したがって、上記およびその他の問題を解決するために改良型のファイル管理技法が求められる可能性がある。

この概要は、以下の発明を実施するための最良の形態でさらに説明される、単純化した形の１組の概念を紹介するために与えられるものである。この概要は、特許請求される主題の主要な特徴または不可欠な特徴を識別することを意図するものではなく、特許請求される主題の範囲を限定するために使用されることを意図するものでもない。

様々な実施形態は、一般にメディアシステムを対象とすることができる。ある実施形態は、具体的にはメディアシステムのためのファイル管理技法を対象とすることができる。一実施形態では、例えば、メディア処理システムまたはサブシステムは、プロセッサ、メモリ、および通信インターフェースを含むことができる。メモリを使用して、プロセッサで実行されるメディアファイルマネージャを格納することができる。メディアファイルマネージャを使用して、複数のメディアストリームおよび／またはメディアファイルを単一の仮想ファイルに格納するなどの様々な使用シナリオのために仮想ファイル内にスペースを割り振るファイルアロケーション方式を実装することができる。

様々な実施形態は、ソフトウェアオブジェクトのソフトウェアライブラリと、アプリケーションプログラムインターフェース（ＡＰＩ）層が仮想ファイルにアクセスし、それを管理することをサポートするための定義済みＡＰＩコマンドとをさらに含むことができる。ＡＰＩ層は、様々なカスタムアプリケーションがメディアファイルマネージャを使用して実装されるファイルアロケーション方式を利用することを可能にすることができる。所与の実装について望まれる通りに、ＡＰＩ層をメディアファイルマネージャと共に、メディアファイルマネージャとは別々に、またはメディアファイルマネージャの代わりに使用することができる。

動作の際に、メディア処理システムは、１つまたは複数の通信インターフェースを介して、様々なメディアソースからメディア情報の複数のメディアストリームを受け取ることができる。メディアファイルマネージャは、名前−値対（ｎａｍｅ−ｖａｌｕｅ ｐａｉｒ）の階層を使用する単一仮想ファイルを有する物理メモリに複数のメディアストリームを格納することができる。単一仮想ファイルは、仮想ファイルを格納するのに使用される物理ファイルフォーマットとは異なる論理ファイルフォーマットを有することができる。例えば、物理ファイルフォーマットは、物理メモリの非連続部分および／または非順次部分を使用して仮想ファイルの各部分を格納することができる。このようにして、単一仮想ファイルを使用して複数のメディアストリームまたはメディアファイルを格納することができ、それによってファイルの複雑さおよびファイル管理操作が低減される。他の実施形態が説明され、特許請求の範囲に記載される。

様々な実施形態は、例えばオンディスクストレージなどの任意の形態のマシン可読媒体またはコンピュータ可読媒体を使用してメディアコンテンツを格納、検索、または管理するのに使用することのできるファイルアロケーション方式をサポートするためのアプリケーションプログラムインターフェース（ＡＰＩ）層を対象とする。ファイルアロケーション方式を使用して、様々なメディアソースから受け取った様々なタイプのメディアコンテンツを、単一仮想ファイルを含む一様なファイル構造に格納することができる。あるケースでは、仮想ファイルは、メディアコンテンツを実際に格納するのに使用される物理ファイル構造とは異なる論理ファイル構造を有することができ、それによって仮想ファイルを物理的な制約および要件から解放する。ファイルアロケーション方式は、例えばテレビジョン番組およびムービーに関連する比較的大容量のメディアコンテンツが与えられたとして、ＰＶＲ応用例およびマルチメディア応用例に特に適している。しかし、ファイルアロケーション方式は非常に柔軟性および拡張性があり、必ずしもＰＶＲ応用例またはマルチメディア応用例に束縛されるわけではない。ファイルアロケーション方式を、多くの応用例および使用シナリオ向けのオンディスクストレージコンテナとして使用することができる。ファイルアロケーション方式は何らかの所与のタイプの応用例にしっかりと一体化されるわけではなく、したがって非常に拡張性があるので、大量のデータをを管理しなければならない任意の形態の現在および将来の応用例にファイルアロケーション方式を適用することができる。

様々な実施形態において、ファイルアロケーション方式は、ファイル内のスペースを管理するために、メディアファイルフォーマットのためのファイルアロケーション層を提供する。一部の実施形態において、ファイルアロケーション方式は、基本ファイルセマンティクスのサポート、ファイル保全性およびクラッシュ回復可能性のサポート、複数のライタと複数のリーダの同時サポート、旧バージョンとの後方互換性を可能にし、所与のメディアの性能要件を実施すること、および多数の名前−値対が独立に増大するのを可能にすることなどの様々な設計特徴を含む。ファイルアロケーション方式はまた、所与の実装について望まれる通りに他の設計特徴も含む。

様々な実施形態は、ファイルアロケーション層をサポートするためのＡＰＩ層を含む。ＡＰＩ層は、ソフトウェアオブジェクトのＡＰＩソフトウェアライブラリと、１組の定義済みＡＰＩコマンドとを含むことができる。様々なアプリケーションプログラムは、ＡＰＩコマンドを使用して、様々なソフトウェアオブジェクトを起動し、本明細書に記載のファイルアロケーション方式に従って所望のファイル管理操作を実施することができる。具体的には、ファイルアロケーションＡＰＩ層は、様々なファイルアロケーション関数、メソッド、サービス、または手続きをモデル化する。一実施形態では、例えば、ＡＰＩ層は、仮想ファイルについてのファイルヘッダ内のシグネチャおよびバージョン、仮想ファイルに関するアロケーション統計、仮想ファイル内の名前−値対の階層（名前−値対を作成および削除する能力を含む）、仮想ファイルとしてモデル化されたショート値およびロング値、ショート値またはロング値内の範囲を０にする能力、読取りおよび書込みのためのショート値およびロング値の明示的ロッキング、および値が変化したときを示すイベントへの加入をモデル化することができる。他のファイルアロケーション関数、メソッド、サービス、または手続きをモデル化することもでき、実施形態はこの文脈に限定されない。ファイルアロケーション層をサポートするのに適した様々なＡＰＩコマンドおよび対応するソフトウェアオブジェクトを、図８を参照しながら後で説明することができる。

ファイルアロケーション層
図１は、メディアシステム１００についてのブロック図を示す。メディアシステム１００は、様々な実施形態を実装するのに適した一般的システムアーキテクチャを表すことができる。メディアシステム１００は複数の要素を含むことができる。要素は、一定の操作を実施するように構成された物理構造または論理構造を含むことができる。各要素は、所与の１組の設計パラメータまたは性能制約について望まれる通りに、ハードウェア、ソフトウェア、またはそれらの任意の組合せとして実装することができる。ハードウェア要素の例は、デバイス、構成要素、プロセッサ、マイクロプロセッサ、回路、回路素子（例えばトランジスタ、抵抗器、コンデンサ、インダクタなど）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、メモリユニット、論理ゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセットなどを含むことができる。ソフトウェアの例は、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、マシンプログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、メソッド、インターフェース、ソフトウェアインターフェース、アプリケーションプログラムインターフェース（ＡＰＩ）、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、シンボル、またはそれらの任意の組合せを含むことができる。図１に示されるメディアシステム１００は、一定のトポロジ内に限られた数の要素を有するが、メディアシステム１００は、所与の実装について望まれる通りに、代替トポロジ内により多数または少数の要素を含むことができる。実施形態はこの文脈に限定されない。

様々な実施形態において、メディア情報や制御情報などの様々なタイプの情報を通信、管理、または処理するようにメディアシステム１００を構成することができる。メディア情報の例は一般に、音声情報、ビデオ情報、オーディオ情報、イメージ情報、テキスト情報、数値情報、英数シンボル、グラフィックスなどのユーザに対するコンテンツを表す任意のデータを含むことができる。制御情報は、自動化システムに対するコマンド、命令、または制御語を表す任意のデータを指すことができる。例えば、制御情報を使用してシステムを介してメディア情報をルーティングし、装置間の接続を確立することができ、所定の方式でメディア情報を処理するように装置に指令することなどができる。

様々な実施形態において、メディアシステム１００は、メディアソース１０２−１−ｎを含むことができる。メディアソース１０２−１−ｎは、メディア処理装置１０６に対してメディア情報（例えばデジタルビデオ信号、オーディオ信号など）および／または制御情報をソーシングまたは配信することのできる任意の物理的実体または論理的実体を含むことができる。メディアソース１０２−１−ｎの例は、ＤＶＤ装置、ＶＨＳ装置、デジタルＶＨＳ装置、パーソナルビデオレコーダ（ＰＶＲ）、デジタルビデオレコーダ（ＤＶＲ）、コンピュータ、ゲーミングコンソール、ＣＤプレーヤ、デジタルカメラ、デジタルカムコーダなどを含むことができる。メディアソース１０２−１−ｎの他の例は、ブロードキャストまたはストリーミングアナログまたはデジタルメディア情報をメディア処理装置１０６に提供するためのメディア配布システムを含むことができる。メディア配布システムの例は、ｏｖｅｒ ｔｈｅ ａｉｒ（ＯＴＡ）放送システム、地上ケーブルシステム、（ＣＡＴＶ）、衛星放送システムなどを含むことができる。メディアソース１０２−１−ｎは、所与の実装について望まれる通りに、メディア処理装置１０６の内部または外部でよい。

様々な実施形態において、メディアシステム１００は、１つまたは複数の通信メディア１０４−１−ｍを介して１つまたは複数のメディアソース１０２−１−ｎに接続するためのメディア処理装置１０６を含むことができる。メディア処理装置１０６は、メディアソース１０２−１−ｎから受信されたメディア情報を処理するように構成された任意の論理実体または物理実体を含むことができる。様々な実施形態において、メディア処理装置１０６は、コンピュータ、セットトップボックス（ＳＴＢ）、メディアサーバ、デスクトップコンピュータ、パーソナルコンピュータ（ＰＣ）、ラップトップコンピュータ、ハンドヘルドコンピュータ、ホームエンターテイメントシステム、ホームシアターシステムなどのコンピューティング装置を含むことができ、またはこうしたコンピューティング装置として実装することができる。

様々な実施形態において、メディア処理装置１０６はメディア処理サブシステム１０８を含むことができる。メディア処理サブシステム１０８は、メディアソース１０２−１−ｎから受け取ったメディア情報を処理するように構成されたプロセッサ、メモリ、およびアプリケーションハードウェア、および／またはソフトウェアを含むことができる。例えば、メディア情報の受信、メディア情報の格納、メディア情報の記録、メディア情報の再生、メディア情報についてのトリックモード装置の実施、メディア情報についてのシーク操作の実施などの様々なメディア管理操作を実施するようにメディア処理サブシステム１０８を構成することができる。メディア処理サブシステム１０８は、処理したメディア情報をディスプレイ１１０に出力することができる。ディスプレイ１１０は、メディアソース１０２−１−ｎから受け取ったメディア情報を表示することのできる任意のディスプレイでよい。

図２は、メディア処理装置１０６のより詳細なブロック図を示す。その最も基本的な構成では、メディア処理装置１０６は通常、少なくとも１つの処理装置２０２およびメモリ２０４を含む。処理装置２０２は、汎用プロセッサ、専用プロセッサ、メディアプロセッサ、コントローラ、マイクロコントローラ、組込みプロセッサ、デジタル信号プロセッサ（ＤＳＰ）などの、ソフトウェアを実行することのできる任意のタイプのプロセッサとすることができる。揮発性メモリと不揮発性メモリのどちらも含む、データを格納することのできる任意のマシン可読媒体またはコンピュータ可読媒体を使用してメモリ２０４を実装することができる。例えば、メモリ２０４は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、ダブルデータレートＤＲＡＭ（ＤＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、静的ＲＡＭ（ＳＲＡＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、強誘電体ポリマーメモリなどのポリマーメモリ、オーボニックメモリ、相変化または強誘電体メモリ、シリコン酸化窒化酸化シリコン（ＳＯＮＯＳ）メモリ、磁気カードまたは光カード、あるいは情報を格納するのに適した任意の他のタイプの媒体を含むことができる。図１に示されるように、メモリ２０４は、１つまたは複数のメディアアプリケーション２０６（メディアアプリケーションリーダ２０６ａおよびメディアアプリケーションライタライタ２０６ｂを含む）、メディアファイルマネージャ２０８、付随するデータなどの様々なソフトウェアプログラムを格納することができる。

メディア処理装置１０６はまた、構成１０６を超える追加の特徴および／または機能も有することができる。例えば、メディア処理装置１０６は、取外し可能ストレージ２１０および取外し不能ストレージ２１２を含むことができ、それらは、上述のような様々なタイプのマシン可読媒体またはコンピュータ可読媒体を含むこともできる。メディア処理装置１０６は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの１つまたは複数の入力装置２１４も有することができる。ディスプレイ（例えばディスプレイ１１０）、スピーカ、プリンタなどの１つまたは複数の出力装置２１６をメディア処理装置１０６に含めることもできる。

メディア処理装置１０６は、メディア処理装置１０６が他の装置と通信することを可能にする１つまたは複数の通信接続２１８をさらに含むことができる。通信接続２１８は、１つまたは複数の通信インターフェース、ネットワークインターフェース、ネットワークインターフェースカード（ＮＩＣ）、ラジオ、ワイヤレス送信機／受信機（トランシーバ）、有線および／またはワイヤレス通信媒体、物理コネクタなどの様々なタイプの標準通信要素を含むことができる。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送機構などの被変調データ信号で具体化し、通信媒体は任意の情報送達媒体を含む。「被変調データ信号」という用語は、その特性集合のうちの１つまたは複数を有する信号、または情報を信号中に符号化するように変化する信号を意味する。例えば、通信媒体は、有線通信媒体およびワイヤレス通信媒体を含むが、これらに限定されない。有線通信媒体の例は、ワイヤ、ケーブル、金属リード、プリント回路板（ＰＣＢ）、バックプレーン、スイッチファブリック、半導体材料、撚線対ワイヤ、同軸ケーブル、光ファイバ、伝播信号などを含むことができる。ワイヤレス通信媒体の例は、音響媒体、無線周波数（ＲＦ）スペクトル媒体、赤外線媒体、および他のワイヤレス媒体を含むことができる。本明細書で使用されるマシン可読媒体およびコンピュータ可読媒体という用語は、記憶媒体と通信媒体のどちらも含むことを意味する。

一般の動作では、メディア処理装置１０６は、通信接続２１８を介して１つまたは複数のメディアソース１０２−１−ｎから様々なタイプのメディア情報を受信および格納することができる。メディア処理装置１０６は、例えばストレージ２１０、２１２を使用してメディア情報を格納することができる。メディアファイルマネージャ２０８は、名前−値対の階層を使用する単一仮想ファイルを有する物理メモリに、複数のメディアストリームからのメディア情報を格納することができる。単一仮想ファイルは、仮想ファイルを格納するのに使用される物理ファイルフォーマットとは異なる論理ファイルフォーマットを有することができる。例えば、物理ファイルフォーマットは、ストレージ２１０、２１２からメモリ非連続部分を使用して仮想ファイルの各部分を格納することができる。言い換えれば、論理ファイル構造は物理ファイル構造から切断される。このようにして、メディアファイルマネージャ２０８は、複数のメディアファイルを１つの仮想ファイルに併合することができ、それによってファイルの複雑さおよびファイル管理操作を低減する。一般にはメディア処理装置１０６、具体的にはメディアファイルマネージャ２０８を、図３〜８および付随する例と共にさらに説明することができる。

以下の図および付随する例を参照しながら、上記の実施形態についての動作をさらに説明することができる。図の一部は論理フローを含む場合がある。本明細書で提示されるそのような図は、特定の論理フローを含むことがあるが、論理フローは本明細書に記載の一般的機能をどのように実装することができるかについての一例を与えるものに過ぎないことを理解することができる。さらに、別段の指示がない限り、与えられる論理フローを必ずしも提示される順序で実行する必要はない。さらに、与えられる論理フローを、ハードウェア要素、プロセッサで実行されるソフトウェア要素、またはそれらの任意の組合せで実装することができる。実施形態はこの文脈に限定されない。

図３は、論理フロー３００の一実施形態を示す。論理フロー３００は、メディアシステム１００、メディア処理装置１０６、および／またはメディア処理サブシステム１０８などの本明細書に記載の１つまたは複数の実施形態で実行される動作を表すことができる。図３に示されるように、ブロック３０２で、メディア情報の複数のメディアストリームを受け取ることができる。ブロック３０４で、複数のメディアストリームを、名前−値対（ＮＶＰ）の階層を使用する単一の仮想ファイルに格納することができる。実施形態はこの文脈に限定されない。

メディア処理サブシステム１０８のメディアファイルマネージャ２０８を、仮想メディアファイルなどの仮想ファイル内のスペースを割り振るファイルアロケーション方式を実装するように構成することができる。仮想ファイルは、例えば、１つまたは複数のコンテナ内の複数のＮＶＰを含むことができる。ＮＶＰは、名前とバイナリ値との間の特定のバインディングを表すことができる。１つの特定のタイプのコンテナは、ルートコンテナと呼ばれることがある。ルートコンテナは、所与のファイル内の最高レベルコンテナを含むことができる。

ＮＶＰは、ＮＶＰ名およびＮＶＰ値を含むことができる。ＮＶＰ名は、グローバル固有識別子（ＧＵＩＤ）、ファイル名、テキスト名、文字列、または何らかの他の固有ファイル識別子を含むことができる。ＮＶＰ値は、常駐値（ｒｅｓｉｄｅｎｔ ｖａｌｕｅ）、ショート値、またはロング値を含むいくつかのタイプの値を含むことができる。異なるタイプのＮＶＰ値は、値サイズに関する性能および効率の意味合いを有する区別を提供する。常駐値は、対応するＮＶＰ名に隣接する帯域内に格納される。ショート値は、複数のショートページを含む仮想ファイルを実装するページテーブル技法を使用して格納される。ショートページは、定義された長さのファイル内の２つのアロケーションユニットの短い方を指すことができる。ページテーブルは、ショートページに含まれるテーブルページと呼ばれるページ参照の固定長配列のツリーを使用して実装されたロングページまたはショートページの配列を含むことができる。ロング値は、ロングページに適用されるのと同一または類似のページテーブル技法を使用して格納される。ロングページは、定義された長さのファイル内の２つのアロケーションユニットの長い方を指すことができる。

様々な実施形態において、メディアファイルマネージャ２０８は、仮想ファイルをロングページに区分化することができ、ロングページの長さは、ファイルが作成されたときに決定される。典型的ロングページサイズは、例えば２５６ｋバイトでよい。所与のロングページをいくつかのショートページに区分化することができ、ショートページの長さも、ファイルが作成されるときに決定される。典型的なショートページサイズは、例えば４ｋバイトとすることができる。すべてのロングページは、ファイル保全性を保証するように一貫した方式で区分化されるべきである。新しいロングページは、ファイルの終りに割り振られる。ロングページを、ＳＡＬ＿Ｆｉｌｅ Ｈｅａｄｅｒ ＦｒｅｅＬｏｎｇＰａｇｅｓページテーブルから割り振ることもできる。ページテーブルが空である場合、ページがファイルの終りに割り振られる（例えばファイルが増大する場合）。まずロングページを割り振り、次いでそれからショートページを割り振ることによって新しいショートページが割り振られる。

一般には、ページサイズは様々な設計制約を有することがある。例えば、ショートページサイズおよびロングページサイズ（バイトとして表現される）は通常、２のべき乗である。別の例では、ロングページは一般にショートページよりも長い。さらに別の例では、ショートページは通常、少なくともファイルヘッダと同様の長さである。さらに別の例では、全ファイルサイズは通常、ショートページサイズの４，２９４，９６７，２９６倍に制限される（例えば、ショートページサイズが４ｋバイトである場合、１６テラバイト）。

ページは、ショートページとして表現されるファイル内のそのオフセット値によって参照される。したがって、ファイル内の第１ショートページは、ファイル内の第１ロングページがそうであるのと同様に、参照０を有する。ファイル内の第２ショートページは参照１を有し、第２ロングページは、ロングページサイズをショートページサイズで割ったものに等しい参照を有する。例えば、前のシナリオでの値が与えられるとすると、第２ロングページは参照値６４を有することができる（例えば２５６ｋ／４ｋ＝６４）。

様々な実施形態において、ファイル内の第１ロングページは常にショートページに区分化される。ファイル内の第１ショートページは通常、ファイルヘッダのみを含む。例えば、メディアファイルマネージャ２０８は、仮想ファイルについてのファイルヘッダを仮想ファイルの第１ショートページに格納することができる。ファイルヘッダは、シグネチャおよびバージョン、ページサイズ、ルートコンテナについてのページテーブル、ならびにファイル内の自由空間管理に関する様々なフィールドを含む。メディアファイルマネージャ２０８は、２つの定義済みシグネチャＧＵＩＤを使用することができる。第１シグネチャＧＵＩＤは、ファイルが本明細書に記載のフォーマットに準拠することを示す。第２シグネチャＧＵＩＤは、次の層でファイルがどのようにフォーマットされるかを示すためにアプリケーションによって使用される。２つのバージョン番号はまた、両方の層でフォーマットの後方互換性のある改訂に関しても定義される。

ルートコンテナは、仮想ファイル内の最高レベルＮＶＰを含むショート値である。ショート値は、ショートページのページテーブルを含むことができる。こうしたＮＶＰの値の一部は、コンテナ自体でよく、したがってＮＶＰは、任意の深さの階層を形成することができる。ファイルヘッダの一例を以下のように示すことができる。

ＮＶＰが、ルートコンテナまたは他の何らかのＮＶＰの値のどちらかのコンテナに格納される。ＮＶＰは、ＧＵＩＤまたはテキスト名をバイナリ値にバインドする。ＮＶＰは、コンテナの先頭で開始して、次々に格納される。一実施形態では、例えば、ＮＶＰは６４ビット境界にパディングされる。コンテナ内のＮＶＰの集合の終りは、コンテナの終りに遭遇することによって、またはＧＵＩＤ＿ＮＵＬＬおよびＶａｌｕｅＳｉｚｅゼロのラベルを有するＮＶＰによって示される。ＮＶＰのラベルをＧＵＩＤ＿ＮＵＬＬに設定することによってＮＶＰを効果的に削除することができる。ＮＶＰに関する例示的なタイプ定義は以下のように示される。

一部の実施形態において、ＶａｌｕｅＳｉｚｅの４つの最上位ビットを使用して、所与のＮＶＰについての情報を提供することができる。例えば、ＮＶＰ＿ＦＬＡＧ＿ＴＥＸＴ値は、ＮＶＰがテキスト名を有し、ヘッダがＴｅｘｔＮｖｐＨｅａｄｅｒの形を取ることを示す。ＮＶＰ＿ＦＬＡＧ＿ＣＯＮＴＡＩＮＥＲ値は、ＮＶＰ値がより多くのＮＶＰを含むことを示す。ＮＶＰ＿ＦＬＡＧ＿ＳＨＯＲＴ値は、値が実際にショートページのページテーブルに格納され、ヘッダの後の値がＰａｇｅＴａｂｌｅ構造であることを示す。ＮＶＰ＿ＦＬＡＧ＿ＬＯＮＧは、値が実際にロングページのページテーブルに格納され、ヘッダの後の値がＰａｇｅＴａｂｌｅ構造であることを示す。こうした定義の一例が以下のように示される。

一部の実施形態において、ページテーブル技法を使用してＮＶＰを格納することができる。ページテーブルは、ショートページに含まれるテーブルページと呼ばれる、ページ参照の固定長配列のツリーを使用して実装されたロングページまたはショートページの配列を含むことができる。例えば、ページテーブルからショートページを参照し、ショートページからテーブルページを参照し、テーブルページからデータページを参照して、ツリーを構築することができる。

ページテーブルは、データページの疎配列（ｓｐａｒｓｅ ａｒｒａｙ）の形を取ることができる。ショートページのページテーブルが「ショート」値を格納するのに使用される。ロングページのページテーブルが「ロング」値を格納するのに使用される。どちらの場合も、配列は、ショートページ内の固定長テーブルの階層として実装される。各「テーブルページ」は、データページまたは他のテーブルページへのページ参照を含むことができる。いくつかの例示的ページテーブルを図４〜７を参照しながら図示および説明することができる。

図４は、第１ページテーブルの例示的実施形態を示す。図４はページテーブル４００を示す。ページテーブル４００についてのルート構造４０２は、トップページ４０４および整数テーブル深さ４０６への参照を含むことができる。ページテーブルについてのタイプ定義の一例を以下のように示すことができる。

図４に示されるように、ページテーブル４００は、ヌルトップページを有するトップページ４０４と、ゼロのテーブル深さ４０６とを有する基本ページテーブルを含む。この構成では、ページテーブル４００は、完全にゼロからなる値を表す。ページテーブルは通常は長さセマンティクスを有さないことに留意されたい。例えば、ページテーブル４００は、任意の数のゼロからなる値を表すことができる。

図５は、第２ページテーブルの例示的実施形態を示す。図５はページテーブル５００を示す。ページテーブル５００は、矢印５０８で示されるように単一データページ５１０を参照するトップページ５０４と、ゼロのテーブル深さ５０６とを有するルート構造５０２を有するページテーブルの一例を与える。データページ５１０内のデータは、表される値の中のオフセット０で生じると解釈される。

図６は第３ページテーブルの例示的実施形態を示す。図６はページテーブル６００を示す。ページテーブル６００は、矢印６０８で示されるように単一テーブルページ６１０を参照するトップページ６０４と、１のテーブル深さ６０６とを有するルート構造６０２を有するページテーブルの一例を与える。１のテーブル深さ６０６では、テーブルページ６１０は、データページまたはヌル参照を参照することのできるテーブルページ値（ＴＰＶ）０からＮ−１を含む。図６で示されるように、例えば、ページテーブル６００は、データページ６１４−１への参照６１２−１を有するＴＰＶ［０］と、データページ６１４−２への参照６１２−２を有するＴＰＶ［３］とを含み、残りのＴＰＶはヌル参照を有する。

図７は、第４ページテーブルの例示的実施形態を示す。図７はページテーブル７００を示す。ページテーブル７００は、矢印７０８で示されるように第１テーブルページ７１０を参照するトップページ７０４と、２のテーブル深さ７０６とを有するルート構造７０２を有するページテーブルの一例を与える。２のテーブル深さ７０６では、第１テーブルページ７１０−１は、他のテーブルページまたはヌル参照を参照することのできるＴＰＶ ０からＮ−１を含む。図７に示されるように、例えば、ページテーブル７００は、第２テーブルページ７１０−２への参照７１２を有するＴＰＶ［１］を含み、残りのＴＰＶはヌル参照を有する。第２テーブルページ７１０−２も、データページまたはヌル参照を参照することのできるＴＰＶ ０からＮ−１を含む。例えば、第２テーブルページ７１０−２は、データページ７１８−１への参照７１６−１を有するＴＰＶ［０］と、データページ７１８−２への参照７１６−２を有するＴＰＶ［３］とを含むことができ、残りのＴＰＶはヌル参照を有する。テーブルページ７１０−１、７１０−２はそれぞれテーブル深さ１を有することができることを理解することができる。ページテーブル深さに対して定義された制限はないが、３よりも深い深さは非定型である。

様々な実施形態において、メディアファイルマネージャ２０８は、ショートページおよびロングページの配列についてそれぞれ第１リサイクル済みページテーブルおよび第２リサイクル済みページテーブルを使用して、仮想ファイルに関する自由空間を管理することができる。メディアファイルマネージャ２０８は、ショートページおよびロングページについて、２つの類似しているが別々の方式で自由空間を管理することができる。リサイクル済みページの２つのページテーブルが、ショートページについて１つ、およびロングページについて１つ存在する。第１リサイクル済みページテーブルは、例えばＨｅａｄｅｒ．ＦｒｅｅＳｈｏｒｔＰａｇｅｓと呼ばれることがある。第１リサイクル済みページテーブルＨｅａｄｅｒ．ＦｒｅｅＳｈｏｒｔＰａｇｅｓは常に、インデックス０からインデックスＨｅａｄｅｒ．ＦｒｅｅＳｈｏｒｔＰａｇｅＣｏｕｎｔまで完全にポピュレートされる。第２リサイクル済みページテーブルは、例えばＨｅａｄｅｒ．ＦｒｅｅＬｏｎｇＰａｇｅｓと呼ばれることがある。第２リサイクル済みページテーブルＨｅａｄｅｒ．ＦｒｅｅＬｏｎｇＰａｇｅｓは常に、インデックス０からインデックスＨｅａｄｅｒ．ＦｒｅｅＬｏｎｇＰａｇｅＣｏｕｎｔまで完全にポピュレートされる。リサイクル済みページが配列の終りで追加および除去される。

あるケースでは、フリーロングページについては特に、スタックよりもキューが望ましいことがある。これは、あるシナリオでの時間とファイル位置の間の逆相関を防止するためである。ショート値のために使用されるショートページも、キューで管理されることから利点を得ることがあるが、他の目的のために使用されるショートページはスタックで保持されることがある。２つのインデックスを使用してキューを実装するのにページテーブルを使用することができる。しかし、この手法は、ファイルが循環バッファを実装するために数日間使用される場合などに、長い期間にわたって不必要に深いページテーブルを作成する傾向を有することになる。深さは大きくなり過ぎるべきではないが、１つの非ヌル参照のみを含むトップページを省略し、インデックスを必要に応じて調節することが、このシナリオを管理することになる。

Ｈｅａｄｅｒ．ＮｅｘｔＳｈｏｒｔＰａｇｅおよびＨｅａｄｅｒ．ＮｅｘｔＬｏｎｇＰａｇｅを使用して、フレッシュページをどこに割り振るべきかを示すことができる。ショートページは、Ｈｅａｄｅｒ．ＮｅｘｔＳｈｏｒｔＰａｇｅから、Ｈｅａｄｅｒ．ＮｅｘｔＳｈｏｒｔＰａｇｅがロングページ境界に達するまで割り振られる。これが行われたとき、新しいロングページが割り振られるべきであり、新しく割り振られたロングページからショートページを割り振ることができる。Ｈｅａｄｅｒ．ＮｅｘｔＬｏｎｇＰａｇｅからロングページを割り振ることができる。これはまさにファイルの終りである。あるケースでは、フリーショートページをフリーロングページに併合することが望ましいことがあり、これは圧縮ツールとして有用であることがある。

一部の実施形態において、電源分断やシステム障害などの障害状態の場合に仮想ファイルを回復するために仮想ファイルを構築する間に、状態情報を回復ログに書き込むようにメディアファイルマネージャ２０８を配置することができる。この回復ログは、現スナップショットで確立された仮想ファイル終了後に（例えばＨｅａｄｅｒ．ＮｅｘｔＬｏｎｇＰａｇｅで）ロングページに書き込まれる。回復ログ内のロングページは、第１ショートページ中のヘッダと、最終ショートページ中のトレーラと、第２ショートページで開始するショートデータページとからなる。回復ログは、仮想ファイルに対する回復不能な書込みと衝突しないように保証するように管理されるべきである。回復ログヘッダおよび回復ログトレーラの一例を以下のように示すことができる。

あるページサイズ組合せについて、上述のＲｅｃｏｖｅｒｙＬｏｇＨｅａｄｅｒはショートページの長さを超過することがある。例えば、ページサイズを制限することによってそのようなケースを許可しないことにより、回復ログヘッダについて複数のショートページを使用することにより、かつ／またはログに対して使用されるロングページ当たりのショートページ数を制限することにより、このシナリオに関する確率を低減し、または完全に防ぐことができる。

一部の実施形態において、メディアファイルマネージャ２０８は、様々なキャッシュ技法を実装して性能を向上させることができる。メディアファイルマネージャ２０８は、仮想ファイルを１つまたは複数のロングページおよびショートページに区分化し、ロングページおよびショートページの一部をキャッシュに書き込み、キャッシュしたページに複数のスレッドでアクセスすることができる。一実施形態では、例えば、名前付き共有メモリを使用してプロセス間でキャッシュを共有することができる。キャッシュしたページを、（１）クリーン、（２）ダーティ、（３）スナップショット、および（４）スナップショットゴーストという４つの状態のうちの１つに割り当てることができる。さらに、ファイルのどの部分から来るかに応じて、あるページは回復可能であるが、他のページは回復可能ではない。例えば、すべてのロングページは通常は回復不能である。ショートページが高い頻度で書き込まれ、それに関して回復が必要ではないシナリオがあるのでない限り、ショートページは通常は回復可能である。

すべてのページについて、以下の３つの規則に従って、ページに関する初期状態を定義することができる。（１）ディスクから読み取られるすべてのページはクリーンで始まる、（２）すべての新しく作成されるページはダーティで始まる、（３）書込みのためにロックされ、書き込まれず、次いでロック解除されるクリーンページはクリーンなままとなる。ディスク手順に対するコミットは、クライアント読取り／書込み活動と同時に行われる。回復可能ページよりも高い頻度で回復不能ページをコミットすることができるが、回復可能ページがコミットされるときはいつでも回復不能ページをコミットすべきである。

回復不能ページをコミットするプロセスを以下のように実施することができる。例えば、すべての（回復不能）ダーティページがスナップショットとなる。スナップショットページが書き込まれ、コピーが作成され、コピーがダーティであり、元のものがスナップショットゴーストであるときを除いて、スナップショットページはクリーンページのように扱われる。スナップショットページおよびスナップショットゴーストページは、ファイル内のそれぞれの場所に書き込まれる。スナップショットゴーストページはフラッシュされる。スナップショットページはクリーンとなる。

すべてのページをコミットするプロセスを以下のように実施することができる。すべてのダーティページがスナップショットとなる。スナップショットページが書き込まれ、コピーが作成され、コピーがダーティであり、元のものがスナップショットゴーストであるときを除いて、スナップショットページはクリーンページのように扱われる。そのスナップショットゴーストバージョンではなく、ダーティコピーがＩＯのためのキャッシュの外に公開される。回復不能スナップショットページおよび回復不能スナップショットゴーストページは、ファイル内のそれぞれの場所に書き込まれる。回復可能スナップショットページおよび回復可能スナップショットゴーストページは回復ログに書き込まれる。回復可能スナップショットページおよび回復可能スナップショットゴーストページは、ファイル内のそれぞれの場所に書き込まれる。スナップショットゴーストページがフラッシュされる。スナップショットページがクリーンとなる。回復ログがフラッシュされる。

一部の実施形態において、メディアファイルマネージャ２０８は、衝突を防止するために様々な同時性規則を実装することができる。メディアファイルマネージャ２０８は、仮想ファイルを、ロックをそれぞれ有する複数の資源に区分化し、資源ロックを使用して複数のアプリケーションによって仮想ファイルからメディア情報を読み取ることができる。アロケーション層で実装される同時性規則は、様々なファイルリーダ、ファイルライタ、およびディスク入出力（Ｉ／Ｏ）間の最高度の独立性を達成するように意図される。キャッシュを使用して、リーダおよびライタ間で通信することができ、ディスクＩ／Ｏからリーダおよびライタを分離することもできる。

仮想ファイルを様々な「ファイル資源」に区分化することができる。例えば、ファイル資源は、（１）ヘッダ、（２）ショートページアロケーション、（３）ロングページアロケーション、（４）ルートコンテナ拡張、（５）ルートコンテナアクセス、（６）値拡張（例えば値当たりの）、および（７）値アクセス（例えば値当たりの）を含むことができる。各資源はそれ自体のロックを有することができる。大部分のロックは、アロケーション層に対する単一呼出しで行われ、解放される。例外は、「値アクセス」および「値拡張」である。アロケーション層ＡＰＩは、アプリケーションがこうした資源をアロケーション層に多数の呼出しにわたって明示的にロックすることを可能にすべきである。様々な依存関係規則を確立して、他の資源がロックされるときどの資源を所与の消費者によってロックすることができるかを決定することができる。こうした規則は、普通ならアロケーション層をデッドロックすることになるサイクルを防止する。こうした規則はまた、コンテンツがすべてそこにある前にリーダがコンテンツを読み取ることを防止することにより、「アプリケーション層」がＮＶＰ値に対してセマンティクスを実施することを可能にする。

（１）読取りロック、（２）書込みロックという２つの方式の一方で大部分の資源をロックすることができる。ロッキング規則は以下の通りである。（１）任意の数のリーダはゼロライタと資源を共有することができ、（２）書込みロックはすべての他のロックと排他的である。

一部の例では、短い間隔についてブロック層コードによってロックが行われ、ＮＶＰ、ページテーブル、アロケーションテーブルなどの一貫性が保証される。他の例では、アプリケーションの制御下で、ブロック層ＡＰＩに対する呼出しによって決定される間隔にわたってロックが行われる。

読取りロックは、一連の相関読取り操作が継続するためにデータおよび当該の資源の意味的一貫性を維持しなければならない間隔にわたって、リーダによって行われる。読取りロックを行わずに読取りは試行されない。書込みロックは、一連の相関書込み操作が資源のコヒーレンシを維持するように行われるべき間隔にわたって、ライタによって行われる。書込みロックを行わずに書込みは試行されない。

ライタがファイル資源に書き込んでいる間にリーダが同じファイル資源から読み取ることを可能にするために、ライタは、所与の資源をロック中に、１組のプライベートダーティページを保持する。ライタが書込みロックを解放するプロセスでリーダにコミットするまで、リーダはこうしたダーティページを見ることはない。データは必ずしも、ライタがライタロックを解放するときに解放されない。ライタがコミットすることなくいくつかの書込みを行う（その度ごとにロックし、ロック解除する）ことは申し分ない。２つのライタによって同時に生成されたダーティページをマージするための一般的な方式がない場合、一度に単一のライタだけが許可される。ダーティページがバージョンされる場合、コミットロックを低減し、またはなくすことができる。

複数のファイル資源にわたってコヒーレンシを保証するために、アロケーション層は、コミットされた変更が順序が乱れてディスクに送られることは決してないことをリーダに対して保証すべきである。キャッシュは、このタイプの問題を低減すべきである。ページが順序が乱れてコミットされる可能性があるが、ページが適切にキャッシュ内にとどまる限り、リーダは、リーダのコンテンツを正しい順序で取得することができる。書込みがコミットされるとき、リーダが値変更の通知を受けることができるようにイベントを投じる必要があることがある。

アプリケーションプログラムインターフェース層
様々な実施形態は、上記で参照したファイルアロケーション層をサポートするために、対応する定義済みＡＰＩコマンドと相互運用可能なソフトウェアオブジェクトのＡＰＩソフトウェアライブラリを含むＡＰＩ層をさらに含むことができる。ＡＰＩ層は、様々なカスタムアプリケーションが、メディアファイルマネージャ２０８を使用して実装されたファイルアロケーション方式を利用することを可能にすることができる。所与の実装について望まれる通りに、ＡＰＩ層をメディアファイルマネージャ２０８と共に使用することができ、メディアファイルマネージャ２０８とは別々に使用することができ、またはメディアファイルマネージャ２０８の代わりに使用することができる。

一般には、ＡＰＩは、他のプロセスが一緒に機能することを可能にするコンピュータプロセスまたは技法である。オペレーティングシステムとＭＩＣＲＯＳＯＦＴ ＷＯＲＤ（登録商標）などの様々なアプリケーションとを実行するパーソナルコンピュータの普通の設定では、ＡＰＩは、アプリケーションがオペレーティングシステムと通信することを可能にする。アプリケーションは、オペレーティングシステムＡＰＩに対する呼出しを行って、オペレーティングシステムサービスを起動する。オペレーティングシステムＡＰＩの背後にある実際のコードは、ダイナミックリンクライブラリ（ＤＬＬ）の集合内に配置される。

他のソフトウェア要素と同様に、別のソフトウェア要素によってそのサービスが起動されるコンピュータ実行可能命令の形態でＡＰＩを実装することができる。コンピュータ実行可能命令を多数の異なる形態で実施することができる。最終的には、命令は、コンピュータプロセッサで処理するためにマシン可読ビットにされる。しかし、こうしたマシン可読ビットの生成の前に、ＡＰＩ実装を様々な形態に変換する機能の層が存在することができる。例えば、Ｃ＋＋で実装されるＡＰＩはまず、一連の人間が読めるコードの行のように見える。次いでＡＰＩは、コンパイラソフトウェアにより、例えば処理装置２０２などのプロセッサ上で実行するためのマシン可読コードにコンパイルされる。

様々なプログラミング言語および実行環境の急増により、ＡＰＩ実装などのプログラミングコードの元の実装と、装置上での処理のためのビットへの変形との間の機能の追加の層が必要となった。例えば、Ｃ＋＋などの高水準言語で最初に作成されたコンピュータプログラムを、まずＭＩＣＲＯＳＯＦＴ（登録商標）Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ（ＭＳＩＬ）などの中間言語に変換することができる。次いで、特定の環境で実行する直前に、中間言語をＪｕｓｔ−ｉｎ−Ｔｉｍｅ（ＪＩＴ）コンパイラでコンパイルすることができる。これにより、複数のコンパイル済みバージョンを配布する必要なしにコードを多種多様な処理環境で実行することが可能となる。ＡＰＩを実装することのできる多数のレベル、およびコードを作成、管理、および処理する技法が引き続き進化していることに鑑みて、実施形態は、どのような特定のプログラミング言語または実行環境にも限定されない。

図８は、ソフトウェアアーキテクチャ８００のための論理図を示す。ソフトウェアアーキテクチャ８００は、図１〜７を参照しながら説明したファイルアロケーション方式を実装および／または使用するように構成された様々なソフトウェア要素を示すことができる。図８に示されるように、ソフトウェアアーキテクチャ８００は、様々なカスタムアプリケーション８０２−１〜ｐ、ＡＰＩ層８０４、およびＡＰＩソフトウェアライブラリ８０８を含むことができる。ＡＰＩソフトウェアライブラリ８０８は、複数のファイルオブジェクト８０６−１〜ｑを含むことができる。ソフトウェアアーキテクチャ８００は、所与の実装について望まれる通りに、より多数または少数のソフトウェア要素を含むことができることを理解することができる。

カスタムアプリケーション８０２−１〜ｐは、前述のファイルアロケーション方式と対話し、またはそれを利用するように設計された任意のアプリケーションソフトウェア、アプリケーションハードウェア、またはそれらの組合せを含むことができる。カスタムアプリケーション８０２の一例は、メディアアプリケーション２０６を含むことができる。メディアアプリケーション２０６は、メディアアプリケーションリーダ（ＭＡＲ）２０６ａおよびメディアアプリケーションライタ（ＭＡＷ）２０６ｂをさらに含むことができる。

ＡＰＩ層８０４で定義される様々なＡＰＩコマンドを使用するようにカスタムアプリケーション８０２−１〜ｐをプログラムまたは設計することができる。ＡＰＩ層８０４の様々な定義済みＡＰＩコマンド（および関連パラメータ）が、ＡＰＩソフトウェアライブラリ８０８へのアクセスを与える。ＡＰＩソフトウェアライブラリ８０８は、本明細書でファイルオブジェクト８０６−１〜ｑと呼ぶ様々なソフトウェアオブジェクトを含むことができる。カスタムアプリケーション８０２−１〜ｐは、１つまたは複数のＡＰＩコマンドを使用して、１つまたは複数の対応するファイルオブジェクト８０６−１〜ｑを起動し、特定の１組のファイル関連機能を実施することができる。１組のＡＰＩコマンドおよび対応するファイルオブジェクト８０６−１〜ｑは、後でより詳細に説明する。

様々な実施形態において、１つまたは複数のカスタムアプリケーション８０２−１〜ｐは、ＡＰＩソフトウェアライブラリ８０８の１つまたは複数のファイルオブジェクト８０６−１〜ｑに対応し、またはそれを起動する１つまたは複数のＡＰＩコマンドを使用して、仮想ファイルにアクセスし、仮想ファイルを操作し、あるいは仮想ファイルと対話する。ファイルオブジェクト８０６−１〜ｑと、図および付随する説明でオブジェクトとして識別される任意の他の要素とは、通常はオブジェクト指向プログラミング技法を使用して生成されるソフトウェアの離散的単位である。あるケースでは、カスタムアプリケーション８０２−１〜ｐ、ＡＰＩ層８０４、および／または様々なＡＰＩコマンドを１つまたは複数のオブジェクトとして実装することができる。多数のオブジェクトタイプが業界では入手可能であり、広く使用されており、特定のオブジェクトタイプは、所与の実装について望まれる通りに変更することができる。オブジェクトによって実施される本明細書および特許請求の範囲に記載の機能を、互いに対話するように設計された複数のオブジェクトによって達成することもできることに留意されたい。実施形態はこの文脈に限定されない。

より具体的には、ファイルオブジェクト８０６−１〜ｑは、前述のメディアファイルアロケーション方式の１つまたは複数の態様を実装するのに必要な様々なファイル関連操作を実施するように構成されたソフトウェアの離散的単位を表すことができる。様々な実施形態において、様々なメディアファイルアロケーション関数、メソッド、および手続きをモデル化するようにＡＰＩ層８０４およびＡＰＩソフトウェアライブラリ８０８を設計することができる。例えば、ＡＰＩ層８０４およびＡＰＩソフトウェアライブラリ８０８は、仮想ファイルに関するファイルヘッダ内のシグネチャおよびバージョンのサポート、仮想ファイルに関するアロケーション統計の定義および検索、仮想ファイル内のＮＶＰの階層のサポート（ＮＶＰを作成および削除する能力を含む）、（仮想ファイルとしてモデル化された）ショート値およびロング値の生成、ショート値またはロング値中の範囲をゼロにする能力、読取りおよび書込みに関するショート値およびロング値の明示的ロッキング、値が変化したときを示すイベントへの加入などの機能、ならびに他の機能もモデル化およびサポートすることができる。実施形態はこの文脈に限定されない。

様々な実施形態において、１つまたは複数のファイルオブジェクト８０６−１〜ｑが特定のクラスのインスタンスを含むことができる。あるクラスは、例えばファイルを作成するサービスを提供するオブジェクトを含むことがあり、別のクラスは、ファイルからデータを読み取るオブジェクトを含むことがあり、さらに別のクラスは、ファイルにデータを書き込むオブジェクトを含むことがある。通常、プログラマは、そのオブジェクトのインスタンスを実行する前にオブジェクトのクラスを知っている。オブジェクトのクラスが、ＡＰＩソフトウェアライブラリ８０８またはそのサブセットなどのクラスライブラリ内で検索される。そのようなライブラリは、オブジェクトのすべての利用可能なクラスのディレクトリへのアクセスを有する。クライアントアプリケーションは、クライアントアプリケーションの望むオブジェクトのクラスと、クライアントアプリケーションがそれに対するポインタを望む最初にサポートされるインターフェースとを指定するライブラリ内の関数を呼び出すことができる。次いでライブラリは、そのクラスのオブジェクトを実装するサーバアプリケーションに実行を開始させる。ライブラリはまた、開始クライアントアプリケーションに、新しくインスタンス化されたオブジェクトに関する要求されたインターフェースへのポインタを返す。次いでクライアントは、オブジェクトがサポートする任意の他のインターフェースへのポインタについてオブジェクトに尋ねることができる。

オブジェクトによってサポートされるインターフェースは一般に、オブジェクトとそのクライアントの間の契約と考えられる。オブジェクトは、インターフェースのメソッドをインターフェースが定義するようにサポートすることを保証し、クライアントアプリケーションは、メソッドを正しく起動することを保証する。したがって、オブジェクトとクライアントは、各インターフェースを明示的に識別する方式、インターフェース内のメソッドを記述または定義する共通の方式、およびインターフェースをどのように実装するかについての具体的な定義に関して合意しなければならない。したがって、オブジェクトが継承するインターフェースパラメータならびにオブジェクトが継承するクラスパラメータによってオブジェクトを記述することができる。例えば、オブジェクトのクラスがファイルにデータを書き込む関数を有する場合、クラスを継承するインスタンス並びにインスタンスで提供される任意の追加の特徴も、ファイルにデータを書き込むことができる。クラスが特定のインターフェースをサポートする場合、クラスのインスタンスは「契約」を継承し、したがってやはりインターフェースをサポートする。実施形態の様々な態様がそれによって実装されるオブジェクトは一般に、こうしたプログラミング原理と、オブジェクト、クラス、継承、およびインターフェースについての理解に準拠する。しかし、オブジェクト指向プログラミング技法に対する修正および改善が常に行われており、実施形態が特定のタイプのオブジェクトまたは何らかの特定の特徴に限定されないことは明らかである。提供されるＡＰＩを、現在使用されており、または後に開発される任意の種類のオブジェクトによって実装することができる。

一実施形態では、例えば、ＡＰＩ層８０４は、インターフェースＩＳＡＬクラスを含むことができる。インターフェースＩＳＡＬクラスによれば、ＡＰＩ層８０４は、ファイル作成（ｆｉｌｅ ｃｒｅａｔｅ）コマンドを受け取って仮想ファイルを作成する。ファイル作成オブジェクトは、ｆｉｌｅ ｃｒｅａｔｅコマンドに応答して、ファイルハンドルと共に仮想ファイルを作成する。ファイル作成オブジェクトは、仮想ファイルに関するファイルハンドルを呼出し側アプリケーション８０２に返すことができる。同様に、ファイルオープン（ｏｐｅｎ ｆｉｌｅ）コマンドを使用して、所与の仮想ファイルを開くことができる。インターフェースＩＳＡＬクラスおよび付随するＡＰＩコマンドの一例を以下のように示すことができる。

一実施形態では、例えば、ＡＰＩ層８０４はインターフェースＩＳＡＬＦｉｌｅクラスを含むことができる。インターフェースＩＳＡＬＦｉｌｅクラスに従って、ＡＰＩ層８０４は、ファイル情報取得（ｇｅｔ ｆｉｌｅ ｉｎｆｏｒｍａｔｉｏｎ）コマンドを受け取り、ｇｅｔ ｆｉｌｅ ｉｎｆｏｒｍａｔｉｏｎコマンドに応答して仮想ファイルに関するファイル情報を返すことができる。インターフェースＩＳＡＬＦｉｌｅクラスは、ルートコンテナ取得（ｇｅｔ ｒｏｏｔ ｃｏｎｔａｉｎｅｒ）コマンドも含むことができ、ルートコンテナからＮＶＰのリストを送ることができる。インターフェースＩＳＡＬＦｉｌｅクラスおよび付随するＡＰＩコマンドの一例を以下のように示すことができる。

一実施形態では、例えば、ＡＰＩ層８０４はインターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＲｅａｄｅｒクラスを含むことができる。インターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＲｅａｄｅｒクラスに従って、ＡＰＩ層８０４は、コンテナ読取り（ｃｏｎｔａｉｎｅｒ ｒｅａｄ）コマンドを受け取り、コンテナからＮＶＰを読み取ることができる。インターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＲｅａｄｅｒクラスはまた、読取りロック獲得（ｒｅａｄ ｌｏｃｋ ａｃｑｕｉｒｅ）コマンド、読取りロックリリース（ｒｅａｄ ｌｏｃｋ ｒｅｌｅａｓｅ）コマンド、常駐値取得（ｇｅｔ ｒｅｓｉｄｅｎｔ ｖａｌｕｅ）コマンド、値取得（ｇｅｔ ｖａｌｕｅ）コマンド、およびコンテナ取得（ｇｅｔ ｃｏｎｔａｉｎｅｒ）コマンドを含むことができる。インターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＲｅａｄｅｒクラスおよび付随するＡＰＩコマンドの一例を以下のように示すことができる。

一実施形態では、例えば、ＡＰＩ層８０４はインターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＷｒｉｔｅｒクラスを含むことができる。インターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＷｒｉｔｅｒクラスに従って、ＡＰＩ層８０４は、コンテナ書込み（ｃｏｎｔａｉｎｅｒ ｗｒｉｔｅ）コマンドを受け取り、コンテナにＮＶＰを書き込むことができる。インターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＷｒｉｔｅｒクラスはまた、書込みロック獲得（ｗｒｉｔｅ ｌｏｃｋ ａｃｑｕｉｒｅ）コマンド、変更コミットおよび書込みロックリリース（ｃｏｍｍｉｔ ｃｈａｎｇｅｓ ａｎｄ ｒｅｌｅａｓｅ ｗｒｉｔｅ ｌｏｃｋ）コマンド、変更破棄および書込みロックリリース（ｄｉｓｃａｒｄ ｃｈａｎｇｅｓ ａｎｄ ｒｅｌｅａｓｅ ｗｒｉｔｅ ｌｏｃｋ）コマンド、常駐値設定（ｓｅｔ ｒｅｓｉｄｅｎｔ ｖａｌｕｅ）コマンド、値クリア（ｃｌｅａｒ ｖａｌｕｅ）コマンド、ショート値設定（ｓｅｔ ｓｈｏｒｔ ｖａｌｕｅ）コマンド、ロング値設定（ｓｅｔ ｌｏｎｇ ｖａｌｕｅ）コマンド、およびコンテナ作成（ｃｒｅａｔｅ ｃｏｎｔａｉｎｅｒ）コマンドを含むことができる。インターフェースＩＳＡＬＣｏｎｔａｉｎｅｒＷｒｉｔｅｒクラスおよび付随するＡＰＩコマンドの一例を以下のように示すことができる。

一実施形態では、例えば、ＡＰＩ層８０４はインターフェースＩＳＡＬＶＮＰＲｅａｄｅｒクラスを含むことができる。インターフェースＩＳＡＬＮＶＰＲｅａｄｅｒクラスに従って、ＡＰＩ層８０４は、値リーダ（ｖａｌｕｅ ｒｅａｄｅｒ）コマンドを受け取り、コンテナからショート値またはロング値を読取ることができる。インターフェースＩＳＡＬＮＶＰＲｅａｄｅｒクラスはまた、イズロング（ｉｓ ｌｏｎｇ）コマンド、長さ取得（ｇｅｔ ｌｅｎｇｔｈ）コマンド、読取りロック獲得（ｒｅａｄ ｌｏｃｋ ａｃｑｕｉｒｅ）コマンド、読取りロックリリース（ｒｅａｄ ｌｏｃｋ ｒｅｌｅａｓｅ）コマンド、およびコピーフロム（ｃｏｐｙ ｆｒｏｍ）コマンドを含むことができる。インターフェースＩＳＡＬＮＶＰＲｅａｄｅｒクラスおよび付随するＡＰＩコマンドの一例を以下のように示すことができる。

一実施形態では、例えば、ＡＰＩ層８０４はインターフェースＩＳＡＬＮＶＰＷｒｉｔｅｒクラスを含むことができる。インターフェースＩＳＡＬＮＶＰＷｒｉｔｅｒクラスに従って、ＡＰＩ層８０４は、値ライタコマンドを受け取り、コンテナにショート値またはロング値を書き込むことができる。インターフェースＩＳＡＬＮＶＰＷｒｉｔｅｒクラスはまた、書込みロック獲得（ｗｒｉｔｅ ｌｏｃｋ ａｃｑｕｉｒｅ）コマンド、変更コミットおよび書込みロックリリース（ｃｏｍｍｉｔ ｃｈａｎｇｅｓ ａｎｄ ｒｅｌｅａｓｅ ｗｒｉｔｅ ｌｏｃｋ）コマンド、変更破棄および書込みロックリリース（ｄｉｓｃａｒｄ ｃｈａｎｇｅｓ ａｎｄ ｒｅｌｅａｓｅ ｗｒｉｔｅ ｌｏｃｋ）コマンド、コピートゥ（ｃｏｐｙ ｔｏ）コマンド、長さ設定（ｓｅｔ ｌｅｎｇｔｈ）コマンド、オフセットに後退（ｒｅｔｉｒｅ ｔｏ ｏｆｆｓｅｔ）コマンド、および値域後退（ｒｅｔｉｒｅ ｒａｎｇｅ）コマンドを含むことができる。インターフェースＩＳＡＬＮＶＰＷｒｉｔｅｒクラスおよび付随するＡＰＩコマンドの一例を以下のように示すことができる。

実施形態の完全な理解を与えるために多数の特定の詳細を本明細書で説明した。しかし、こうした特定の詳細を用いずに実施形態を実施できることを当業者は理解されよう。他の例では、実施形態を不明瞭にしないように、周知の操作、構成要素、および回路を詳細には説明していない。本明細書で開示される特定の構造的詳細および機能的詳細は代表的なものであることがあり、必ずしも実施形態の範囲を限定するものではないことを理解することができる。

「一実施形態」または「実施形態」への任意の参照は、実施形態に関連して説明した特定の機能、構造、特徴が少なくとも一実施形態に含まれることを意味することにも留意されたい。本明細書の様々な場所での「一実施形態では」という語句の出現は、必ずしもすべて同一の実施形態を指すわけではない。

ある実施形態が、「結合された」および「接続された」という表現およびその派生語を使用して説明されることがある。こうした用語は互いについて同義語として意図されないことを理解されたい。例えば、ある実施形態が、２つ以上の要素が互いに直接的に物理的または電気的に接触していることを示すために、「接続された」という用語を使用して説明されることがある。別の例では、ある実施形態が、２つ以上の要素が直接的に物理的または電気的に接触していることを示すために、「結合された」という用語を使用して説明されることがある。しかし、「結合された」という用語は、２つ以上の要素が互いに直接的には接触していないが、それでも互いに協働または対話することを意味することもある。実施形態はこの文脈に限定されない。

ある実施形態を、例えば、マシンによって実行された場合に実施形態による方法および／またはオペレーションをマシンに実施させることのできる命令または１組の命令を格納することのできるマシン可読媒体または物品を使用して実装することができる。そのようなマシンは、例えば、任意の適切な処理プラットフォーム、コンピューティングプラットフォーム、コンピューティング装置、コンピューティング装置、コンピューティングシステム、処理システム、コンピュータ、プロセッサなどを含むことができ、ハードウェアおよび／またはソフトウェアの任意の適切な組合せを使用して実装することができる。マシン可読媒体または物品は、例えば、任意の適切なタイプのメモリユニット、メモリ装置、メモリ物品、メモリ媒体、記憶デバイス、記憶物品、記憶媒体、および／または記憶ユニット、例えばメモリ、取外し可能媒体または固定媒体、消去可能媒体または消去不能媒体、書込み可能媒体または書換可能媒体、デジタル媒体またはアナログ媒体、ハードディスク、フロッピィディスク、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、追記型コンパクトディスク（ＣＤ−Ｒ）、書換可能コンパクトディスク（ＣＤ−ＲＷ）、光ディスク、磁気メディア、光磁気媒体、取外し可能メモリカードまたはディスク、様々なタイプのデジタルバーサタイルディスク（ＤＶＤ）、テープ、カセットなどを含むことができる。

構造的特徴および／または方法動作に特有の術語で主題を説明したが、添付の特許請求の範囲で定義される主題は必ずしも上述の特定の特徴または動作に限定されないことを理解されたい。むしろ、上述の特定の特徴および動作は、特許請求の範囲を実装する例示的形態として開示される。

メディアシステムの例示的実施形態を示す図である。 メディア処理装置の例示的実施形態を示す図である。 論理フローの例示的実施形態を示す図である。 第１ページテーブルの例示的実施形態を示す図である。 第２ページテーブルの例示的実施形態を示す図である。 第３ページテーブルの例示的実施形態を示す図である。 第４ページテーブルの例示的実施形態を示す図である。 アプリケーションプログラムインターフェースに関する論理図の例示的実施形態を示す図である。

Claims (20)

1. 実行された場合に、システムがソフトウェアライブラリ（８０８）からソフトウェアオブジェクト（８０６）に対応するアプリケーションプログラムインターフェースコマンドを受け取り、前記ソフトウェアオブジェクトと共に名前−値対の階層を使用して格納された複数のメディアストリームに関するメディア情報を有する仮想ファイルにアクセスすることを可能にする命令を含むマシン可読記憶媒体を含むことを特徴とする物品。
2. 実行された場合に、前記システムがファイル作成コマンドを受け取って前記仮想ファイルを作成し、前記ファイル作成コマンドに応答してファイルハンドルを有する前記仮想ファイルを作成し、前記仮想ファイルに関する前記ファイルハンドルを送ることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
3. 実行された場合に、前記システムがファイル情報取得コマンドを受け取り、前記ファイル情報取得コマンドに応答して前記仮想ファイルに関するファイル情報を送ることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
4. 実行された場合に、前記システムがルートコンテナ取得コマンドを受け取り、ルートコンテナから名前−値対のリストを送ることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
5. 実行された場合に、前記システムがコンテナ読取りコマンドを受け取り、コンテナから名前−値対を読み取ることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
6. 実行された場合に、前記システムがコンテナ書込みコマンドを受け取り、コンテナに名前−値対を書き込むことを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
7. 実行された場合に、前記システムが値リーダコマンドを受け取り、コンテナからショート値またはロング値を読み取ることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
8. 実行された場合に、前記システムが値ライタコマンドを受け取り、コンテナにショート値またはロング値を書き込むことを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
9. 実行された場合に、前記システムが読取りロックコマンドを受け取り、読取りのためにショート値またはロング値をロックすることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
10. 実行された場合に、前記システムが書込みロックコマンドを受け取り、書込みのためにショート値またはロング値をロックすることを可能にする命令をさらに含むことを特徴とする請求項１に記載の物品。
11. プロセッサ（２０２）およびメモリ（２０４）を有するメディア処理サブシステムを含む装置であって、前記メモリが、複数のソフトウェアオブジェクト（８０６）を有するアプリケーションプログラムインターフェースソフトウェアライブラリ（８０８）を格納し、前記プロセッサが、複数のメディアストリームからのメディアコンテンツを格納するのに使用される名前−値対の階層を含む仮想ファイルを管理するために、アプリケーションプログラムインターフェースコマンドに応答して前記ソフトウェアオブジェクトを実行することを特徴とする装置。
12. 前記アプリケーションプログラムインターフェースソフトウェアライブラリが、ファイル作成コマンドに応答するファイル作成オブジェクト、ファイル情報取得コマンドに応答するファイル情報オブジェクト、ルートコンテナ取得コマンドに応答するルートコンテナオブジェクト、コンテナ読取りコマンドに応答するコンテナ読取りオブジェクト、コンテナ書込みコマンドに応答するコンテナ書込みオブジェクト、値リーダコマンドに応答する値リーダオブジェクト、値ライタコマンドに応答する値ライタオブジェクト、読取りロックコマンドに応答する読取りロックオブジェクト、または書込みロックコマンドに応答する書込みロックオブジェクトのうちの少なくとも１つを含むことを特徴とする請求項１１に記載の装置。
13. 前記アプリケーションプログラムインターフェースソフトウェアライブラリを使用して前記仮想ファイルから名前−値対を読み取るためのメディアアプリケーションリーダを含むことを特徴とする請求項１１に記載の装置。
14. 前記アプリケーションプログラムインターフェースソフトウェアライブラリを使用して前記仮想ファイルに名前−値対を書き込むためのメディアアプリケーションライタを含むことを特徴とする請求項１１に記載の装置。
15. 前記仮想ファイルを管理するためのメディアファイルマネージャを含むことを特徴とする請求項１１に記載の装置。
16. ソフトウェアライブラリ（８０８）からソフトウェアオブジェクト（８０６）に対応するアプリケーションプログラムインターフェースコマンドを受け取ること、および
    前記ソフトウェアオブジェクトと共に名前−値対の階層を使用して格納された複数のメディアストリームに関するメディア情報を有する仮想ファイルにアクセスすること
    を含むことを特徴とする方法。
17. 前記ソフトウェアライブラリからの第１ソフトウェアオブジェクトと共に前記仮想ファイルにメディア情報を書き込むことを含むことを特徴とする請求項１６に記載の方法。
18. 前記ソフトウェアライブラリからの第２ソフトウェアオブジェクトと共に前記仮想ファイルからメディア情報を読み取ることを含むことを特徴とする請求項１６に記載の方法。
19. 前記ソフトウェアライブラリからの第３ソフトウェアオブジェクトと共に前記仮想ファイルを作成することを含むことを特徴とする請求項１６に記載の方法。
20. 前記ソフトウェアライブラリからの第４ソフトウェアオブジェクトと共に前記名前−値対を作成することを含むことを特徴とする請求項１６に記載の方法。

Images