JP2014510982A - ファイルシステムに関する改善 - Google Patents

Abstract

データストアとファイルレコードデータベースとを含むファイルシステムからファイルデータを提供する方法。この方法は、ファイルシステム内のファイルを開きたいという要求を受信するステップと、その要求のシンタックスを使用してファイルの所望のプロパティを特定するステップとを含む。次いで、ファイルの特定されたプロパティに基づいてファイルレコードデータベース内にファイルレコードが作成され、そのファイルレコードに関するファイルハンドルが返される。ファイルの特定されたプロパティに基づいて、データストア内のデータから、要求されたファイルを構成するデータが生成され、ファイルからのデータの一部分を読み取りたいという要求に応答して、生成されたデータの対応する部分が返される。
【選択図】図２

Description

本発明は、改善されたファイルシステムに関する。より詳細には、本発明は、明示的に求められた場合にのみファイルが作成されることを可能にする、ファイルシステムゲートウェイと、ファイルシステムからファイルデータを提供する方法とに関するが、それらだけに限定されない。本発明は、メディアファイルを構成するエッセンスデータを含むファイルシステムに特に適しているが、それだけに限定されない。

従来のファイルシステムが、図１において示されている。ファイルシステム１は、データストア２を含み、データストア２は、ファイルシステム１内に格納されるファイルを構成するデータを格納する。（データストア２内のデータの特定のセットは、グローバル一意識別子すなわち「ＧＵＩＤ」などの識別タグを含むこともできる。）ファイルシステム１はさらに、ファイルレコードデータベース３を含み、ファイルレコードデータベース３は、ファイルレコードを含み、ファイルレコードは、ファイルシステム１内に格納されるファイルの詳細、とりわけ、それらのファイルを構成するデータストア２内のデータのロケーション、また、作成日付、ファイルの長さ、許可情報、およびその他の属性など、その他のメタデータを格納する。

ファイルシステム１へのアクセスは、ファイルシステムゲートウェイ４によって提供され、ファイルシステムゲートウェイ４は、たとえば、ファイルシステム１からのファイルの読取り／書込みを行いたいという要求を受け入れ、それに応じて、ファイルレコードデータベース３内のファイルレコードに基づいてデータストア２との間でデータの読取り／書込みを行い、同様に、ファイルシステムゲートウェイ４は、ファイルレコードデータベース３そのものの中のファイルレコードに対して読取り／書込みを行いたいという要求を受け入れる。ファイルシステムゲートウェイ３は、パーソナルコンピュータまたはサーバなどのデバイスに直接接続することができ、あるいはそのデバイスは、ファイルサーバまたはＮＡＳ（ｎｅｔｗｏｒｋ−ａｔｔａｃｈｅｄ ｓｔｏｒａｇｅ）デバイスとして、ネットワークを介してその他のデバイスと通信することができる。そのようなネットワークは、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、またはインターネットなどの公的なネットワークとすることができる。

ファイルシステムゲートウェイ４は、ファイルプロトコル、たとえばＳＭＢ２プロトコル（Ｍｉｃｒｏｓｏｆｔによって開発され、ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｃｃ２４６４８２（ｖ＝ｐｒｏｔ．１３）．ａｓｐｘにおいて規定されている）を使用して通信する。ＳＭＢ２プロトコルは、数ある中でも、下記のタイプの要求を含む（それぞれは、実際にはコマンドのグループ内に存在し、たとえばグループＤＩＲは、コマンドＱＵＥＲＹ＿ＤＩＲＥＣＴＯＲＹおよびＣＨＡＮＧＥ＿ＮＯＴＩＦＹを含む）：
ＤＩＲ−特定のディレクトリ内のファイルおよびフォルダのリストを返す；
ＣＲＥＡＴＥ／ＯＰＥＮ−ファイルを開き、そのファイルを指すために使用される一時的な識別子であるファイルハンドル（またはファイル識別子、「ＦＩＤ」）を作成して返す；
ＲＥＡＤ−ファイルを構成しているデータを読み取る；
ＷＲＩＴＥ−ファイルにデータを書き込む；
ＣＬＯＳＥ−ファイルを閉じて、ＦＩＤを取り下げる。

ファイルシステム１は、たとえばメディアファイルストアとすることができ、そのケースにおいては、データストア２は、メディアデータ、すなわちビデオおよびオーディオデータ（従来「エッセンス」データとして知られている）を格納する。ファイルシステム１内のファイルは、従来のケースと同様に、単一のＧＵＩＤを有するデータストア２からのデータの単一のセットから構成することができる。ファイルは、「クリップ」とすることもでき、このケースにおいては、ファイルは、データストア２内のデータの１つまたは複数のセットからのデータの複数の部分から構成され、どのようにしてクリップが構築されるかについての詳細は、ファイルレコードデータベース３の中のファイルレコード内に格納されるファイルについての詳細の一部となっている。クリップは一般に、ファイルシステム１内に既に存在するファイルを手作業で編集することによって作成される。

特定のクリップを、いくつかの異なるバージョン、たとえば別々のファイルフォーマット、サンプルレート、および／またはイメージサイズで利用可能にすることが望ましい場合がある。しかし、別々のバージョンファイルを格納するためには、大量のスペースが必要とされ、それらのバージョンファイルの作成は、オリジナルクリップを構成しているエッセンスデータの処理を必要とすることがあり、それには時間がかかる場合がある。これを緩和するために、「バーチャル」ファイルシステムが提案されている。

２００８年８月２８日に公開されたＷＯ２００８／８１５９Ａ１（Ｑｕａｎｔｅｌ Ｌｉｍｉｔｅｄ）は、そのようなバーチャルファイルシステムについて記載している。そこに記載されているファイルシステムは、クエリーを受けた場合に、いくつかの異なるバージョンファイルが利用可能であることを示す。しかし、それらの異なるバージョンファイルは、実際にはファイルシステム内に明示的に格納されておらず、その代わりに、それらのバージョンファイルのコンテンツは、要求された場合にのみ作成される。

２０００年３月１６日に公開されたＷＯ００／１４６３２Ａ１（Ｍｅｔａｐｈｏｒｉｃｓ，ＬＬＣ）は、別のバーチャルファイルシステムについて記載しており、そのバーチャルファイルシステムにおいては、同様に、要求されるファイルのコンテンツは、要求された場合にのみ作成される。

したがって、そのようなバーチャルファイルシステムは、必要とされるストレージスペースの問題、および要求される可能性があるすべてのバージョンを前もって作成しておくために要する時間の問題を回避しつつ、いくつかの異なるバージョンファイルを提供することができる。しかし、どのバージョンが提供されることになるかは、前もって設定しなければならない。なぜなら、それによって、クエリーを受けたときに存在している旨をファイルシステムが示すバージョンファイルが決定されるためである。

ＷＯ２００８／８１５９Ａ１ ＷＯ００／１４６３２Ａ１

ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｃｃ２４６４８２（ｖ＝ｐｒｏｔ．１３）．ａｓｐｘ

本発明は、上述の問題を緩和することを目指す。代替として、および／または追加として、本発明は、改善された、よりフレキシブルなバーチャルファイルシステムを提供することを目指す。

本発明の第１の態様によれば、データストアとファイルレコードデータベースとを含むファイルシステムからファイルデータを提供する方法が提供され、この方法は、
ファイルシステム内のファイルを開きたいという要求を受け取るステップと、
その要求のシンタックスを使用してファイルの所望のプロパティを特定するステップと、
ファイルの特定されたプロパティに基づいてファイルレコードデータベース内にファイルレコードを作成するステップと、
そのファイルレコードに関するファイルハンドルを返すステップと、
ファイルの特定されたプロパティに基づいて、データストア内のデータから、要求されたファイルを構成するデータを生成するステップと、
ファイルからのデータの一部分を読み取りたいという要求に応答して、生成されたデータの対応する部分を返すステップとを含む。

この方法を用いれば、ファイルは、それらのファイルを開きたいという要求が受け取られた場合にのみ作成され、したがって、それらのファイルは、前もって作成しておく必要はなく（また、それらのファイルがまったく要求されないならば、作成する必要はまったくなく）、それでもなお、要求を行っているシステムにとっては、既に存在しているように見える。これが意味していることは、要求のシンタックスからファイルの所望のプロパティを特定するための適切なスキームを使用することによって、無限に近い範囲のファイルをオンデマンドで提供することができるということである。たとえば、ピクセルでのファイルの高さがファイル名の中の数字として提供され、それによって、任意の対応するサイズのイメージファイルを提供することが可能になるスキームを使用して、別々のサイズのイメージファイルを提供するためのファイルシステムを提供することができる。別の利点として、この方法は、要求を行っているシステムにとって気付かれないようにできる。なぜなら、そのシステムにとっては、ファイルが既に存在しているように見えることになるためであり、それによって、この方法を既存のシステムとともに使用することが可能となる（それらのシステムが要求するファイルの所望のプロパティを、それらのシステムが行う要求のシンタックスから特定することができる限り）。

好ましくは、ファイルを構成するデータの部分は、要求された場合にのみ生成される。これによって、まったく求められることのないデータが生成されること（それは非効率的である）が回避される。しかし、別法として、１つのファイルを構成するすべてのデータを、ファイルレコードがはじめに作成された時点で生成しておくこともできる。

好ましくは、要求されたファイルのファイル名は、そのファイルに生成されるデータの元となるデータを含むファイルシステム内の既存のファイルを特定する。やはり好ましくは、要求されたファイルの拡張子は、その要求されたファイルのファイルフォーマットを特定する。これらによって、要求されたファイルのコンテンツおよびファイルフォーマットがその要求内に表示されるようにするための便利な方法が提供される。有利には、要求されたファイルが配置されているディレクトリの階層は、その要求されたファイルのプロパティを特定する。さらに有利には、階層内のそれぞれのディレクトリは、ファイルのそれぞれのプロパティを特定する。これによって、要求されたファイルの複数の所望のプロパティがその要求内に表示されるようにするための便利な構造化された方法が提供される。

有利には、要求のシンタックスは、データベースにクエリーを行うためのデータベースクエリーを生成するために使用され、ファイルの所望のプロパティは、前記データベースクエリーの結果を使用して特定される。このクエリーは、たとえば、要求されたファイルが配置されているディレクトリの階層から生成することができる。このクエリーは、結果を返すことができ、次いでその結果は、要求されたファイルのファイル名および／または拡張子を使用してフォーマット設定される。

本発明の第２の態様によれば、データストアとファイルレコードデータベースとを含むファイルシステムのためのファイルシステムゲートウェイが提供され、このファイルシステムゲートウェイは、
ファイルシステム内のファイルを開きたいという要求に応答して、その要求のシンタックスを使用してファイルの所望のプロパティを特定し、ファイルの特定されたプロパティに基づいてファイルレコードデータベース内にファイルレコードを作成し、そのファイルレコードに関するファイルハンドルを返すように構成されており、
このファイルシステムゲートウェイは、ファイルの特定されたプロパティに基づいて、データストア内のデータから、ファイルを構成するデータを生成し、ファイルからのデータの一部分を読み取りたいという要求に応答して、生成されたデータの対応する部分を返すようにさらに構成されている。

好ましくは、ファイルを構成するデータの部分は、要求された場合にのみ生成される。

好ましくは、要求されたファイルのファイル名は、そのファイルに生成されるデータの元となるデータを含むファイルシステム内の既存のファイルを特定する。やはり好ましくは、要求されたファイルの拡張子は、その要求されたファイルのファイルフォーマットを特定する。有利には、要求されたファイルが配置されているディレクトリの階層は、その要求されたファイルのプロパティを特定する。さらに有利には、階層内のそれぞれのディレクトリは、ファイルのそれぞれのプロパティを特定する。

有利には、このファイルシステムゲートウェイは、データベースにクエリーを行うためのデータベースクエリーを要求のシンタックスから生成するように構成されており、ファイルの所望のプロパティは、そのデータベースクエリーの結果を使用して特定される。

このファイルシステムゲートウェイは、ファイルレコードデータベースを含むことができる。

本発明の第３の態様によれば、上述のデータストア、ファイルレコードデータベース、およびファイルシステムゲートウェイを含むファイルシステムが提供される。

本発明の第４の態様によれば、実行されたときに、上述の方法のうちのいずれかの方法のステップを実行するように構成されているコンピュータプログラム製品が提供される。

本発明の第５の態様によれば、コンピューティングデバイス上で実行されたときに、上述のファイルシステムゲートウェイを提供するように構成されているコンピュータプログラム製品が提供される。

本発明の一態様に関連して説明されている特徴を本発明のその他の態様へと組み込むことができるということは、もちろん理解されるであろう。たとえば、本発明の方法は、本発明の装置を参照して説明されている特徴のうちのいずれを組み込むこともでき、その逆もまた同様である。

次いで本発明の実施形態について、単なる例として、添付の概略図を参照しながら説明する。

従来のファイルシステムの概略図である。 本発明の第１の実施形態によるファイルシステムを含むネットワーク化されたコンピュータシステムの概略図である。 ＣＲＥＡＴＥ／ＯＰＥＮ要求に応答した第１の実施形態のファイルシステムのオペレーションを示すフローチャートである。 ＲＥＡＤ要求に応答した第１の実施形態のファイルシステムのオペレーションを示すフローチャートである。 本発明の第２の実施形態によるファイルシステムを含むネットワーク化されたコンピュータシステムの概略図である。 第２の実施形態のファイルシステムのオペレーションを示すフローチャートである。

次いで、本発明の第１の実施形態について、図２から図４を参照しながら説明する。図２は、この実施形態によるファイルシステム１１を含むネットワーク化されたコンピュータシステムの概略図である。従来のファイルシステムの場合と同様に、ファイルシステム１１は、ファイルデータを格納するデータストア１２と、ファイルの詳細を格納するファイルレコードデータベース１３とを含む。データストア１２およびファイルレコードデータベース１３は、完全に従来のものとすることができる。

ファイルシステム１１はさらに、ファイルシステムゲートウェイ１４を含み、ファイルシステムゲートウェイ１４は、ネットワーク１６を介して、以降で説明するようにファイルシステム１１へのアクセスを提供する。ファイルシステムゲートウェイ１４は、所定の構成スキーム１５に従ってファイルを提供するように構成されている（構成スキーム１５は、図１においては概略的に示されているが、実際には別個のエンティティではなく、ファイルシステムゲートウェイ１４の特定のセットアップである）。

次いで、ファイルシステム１１のオペレーションについて説明する。ファイルシステムゲートウェイ１４は、ＳＭＢ２プロトコルに従ってネットワーク１６上のデバイスと通信する。言い換えれば、ファイルシステムゲートウェイ１４は、ＳＭＢ２プロトコルによって定義されている要求を受け入れ、ＳＭＢ２プロトコルを使用して別のシステムによって予期されているタイプおよびフォームの応答を返す。しかしファイルシステム１１は、構成スキーム１５によって定義されている特定の状況に関して従来のＳＭＢ２ファイルサーバをシミュレートするだけであるという意味で、ＳＭＢ２プロトコルを完全に実施するわけではない。そのシミュレーションは完全ではなく、とりわけ、ファイルシステム１１の動作は、すべての状況においてＳＭＢ２プロトコルによって定義されている動作と一致するわけではない。

上で提供されたコアＳＭＢ２要求に応答したファイルシステムゲートウェイ１４の動作は、下記のとおりである。

ＤＩＲ−従来のＳＭＢ２ファイルシステムと同様に、これは、特定のディレクトリ内のファイルおよびフォルダのリストを返す。

ＣＲＥＡＴＥ／ＯＰＥＮ−ＣＲＥＡＴＥ／ＯＰＥＮ要求に応答したファイルシステムゲートウェイ１４の動作について、図３のフローチャートを参照しながら説明する。はじめに、ＣＲＥＡＴＥ／ＯＰＥＮ要求が受け取られる（ステップ２１）。ＣＲＥＡＴＥ／ＯＰＥＮ要求は、開かれるファイルのロケーションおよび名前を、ディレクトリの階層の後にファイル名が続く形式、たとえば「＼ｄｉｒ１＼ｄｉｒ２＼ｄｉｒ３＼ｆｉｌｅ．ｅｘｔ」として定義するテキスト文字列を含み、このテキスト文字列のシンタックスが分析される（ステップ２２）。たとえば、要求されているファイルが配置されている（と予想される）ディレクトリの階層、およびファイル拡張子によって提供されるそのファイルの予想されるフォーマットが抽出される。次いで、そのファイルの予想されるプロパティが、構成スキーム１５によって提供される構成から特定される（ステップ２３）。特定されたプロパティを使用して、そのファイルに関する適切なファイルレコードが、ファイルレコードデータベース１３内に作成される（ステップ２４）。次いで、そのファイルに関するファイルハンドルが作成され（ステップ２５）、返される（ステップ２６）。

ＲＥＡＤ−ＲＥＡＤ要求に応答したファイルシステムゲートウェイ１４の動作について、図４のフローチャートを参照しながら説明する。はじめに、ＲＥＡＤ要求が受け取られる（ステップ３１）。ＲＥＡＤ要求は、ファイルハンドルを含み、バイトレンジを使用して、ファイルからのデータの特定の部分を指定することができる。ファイルハンドルは、ファイルレコードデータベース１３内に格納されているファイルレコードを指し、このファイルレコードから、ファイルの予想されるプロパティが得られる（ステップ３２）。（それらの予想されるプロパティは、ＣＲＥＡＴＥ／ＯＰＥＮ要求の結果としてファイルレコードが作成された時点で特定される。その段階で、それらのプロパティの詳細をファイルレコード内に明示的に格納することができる。あるいは、それらのプロパティをファイルのロケーションおよび名前ならびに構成スキーム１５から再作成することもできる。）次いで、要求されているデータが、それらの予想されるプロパティに基づいてデータストア１２内のデータから生成され（ステップ３３）、返される（ステップ３４）。生成されたデータは、その後の時点で再び要求される場合に備えてデータストア１２内に格納することができ、または別法として破棄することもできる。

ＷＲＩＴＥ−適切な場合には、データストア１２内のデータは、ＷＲＩＴＥ要求によって指示された際に更新される。しかし、たとえば、要求に応じて別々のフォーマット／クォリティのファイルが作成される実施形態においては、第１のフォーマット／クォリティでデータストア１２内に格納されているデータを、そのファイルの別のフォーマット／クォリティでのバーチャルバージョンに対して行われたＷＲＩＴＥ要求に基づいて更新することは、適切でない場合がある。したがって、多くのケースにおいては、ＷＲＩＴＥ要求は影響を及ぼさない。いくつかの実施形態においては、新たに作成されたファイルへの書込みのみを可能にすることができる。

ＣＬＯＳＥ−従来のＳＭＢ２ファイルシステムと同様に、ファイルが閉じられ、ファイルハンドルが取り下げられる。対応するファイルレコードは、削除することができ、またはその後の時点で再びファイルが要求される場合に備えて保存することもできる。

したがって、この実施形態においては、ＣＲＥＡＴＥ／ＯＰＥＮ要求は、従来は既存のファイルに関するファイルハンドルを作成するために使用されるが、このケースにおいては、ファイルシステム１１によってそれまでにいかなるファイルも存在していない場合に、予想されるプロパティ（または少なくとも、そのファイルレコード）を有するファイルが作成されるようにする。これは、とりわけ、ＤＩＲ要求およびＣＲＥＡＴＥ／ＯＰＥＮ要求によって返される応答において見て取ることができ、ＤＩＲ要求が、あるディレクトリが空であることをはじめに示す場合があるが、それにもかかわらず、同じディレクトリ内のあるファイルに関するＣＲＥＡＴＥ／ＯＰＥＮ要求は、そのファイルに関するファイルハンドルをそれでもなお成功裏に返すことができる。次いで、そのファイルが現在はそのディレクトリ内に存在していることを後続のＤＩＲ要求が示すことになる。（代替実施形態においては、ファイルのプロパティにおける変化に起因して望ましくない問題（「競合状態」など）が生じる可能性を回避するために、ファイルをＤＩＲ要求から隠すことができる。）

具体例を提供するために、ファイルシステム１１は、６０ＦＰＳ（ｆｒａｍｅｓ ｐｅｒ ｓｅｃｏｎｄ）のフレームレートおよび４０００×３０００ピクセルのフレームサイズを有するＡＶＩフォーマットの「リアル」ビデオファイルｍｏｖｉｅ１．ａｖｉおよびｍｏｖｉｅ２．ａｖｉを含むことができる。これらのファイルに関するファイルレコードは、これらのファイルが＼ｍｏｖｉｅｓ＼６０＼４０００＼というディレクトリ階層に配置されていることを示し、データストア１２内におけるこれらのファイルに関する（実際に存在する）エッセンスデータのロケーションを提供する。これらのファイルに関するＳＭＢ２要求は、従来のファイルシステムの場合と同様に取り扱われ、言い換えれば、これらのファイルは、従来のＳＭＢ２ファイルシステム内のファイルと同じ方法で開くこと、読み取ること、書き込むこと、閉じることなどが可能である。

しかし、構成スキーム１５は、ファイルシステム１１内の既存ではないファイルの予想されるプロパティを特定するためのルールを提供する。たとえば、構成スキーム１５は、下記のロケーションにおける下記のファイルが下記のようなプロパティを有することを特定することができる：
＼ｍｏｖｉｅｓ＼３０＼４０００＼ｍｏｖｉｅ１．ａｖｉ−３０ＦＰＳのフレームレートおよび４０００×３０００ピクセルのフレームサイズを有するＡＶＩフォーマットのビデオファイルｍｏｖｉｅ１．ａｖｉの１つのバージョン。

＼ｍｏｖｉｅｓ＼３０＼２００＼ｍｏｖｉｅ２．ｍｐ４−３０ＦＰＳのフレームレートおよび２００×１５０ピクセルのフレームサイズを有するＭＰＥＧ４フォーマットのビデオファイルｍｏｖｉｅ２．ａｖｉの１つのバージョン。

＼ｓｔｉｌｌｓ＼１２０．００＼４０００＼ｍｏｖｉｅ１．ｂｍｐ−１２０．００秒の間隔で、ビットマップフォーマットで、かつ４０００×３０００ピクセルのサイズでビデオファイルｍｏｖｉｅ１．ａｖｉから取り出したスチール。

＼ｓｔｉｌｌｓ＼３７．４３＼２００＼ｍｏｖｉｅ２．ｊｐｇ−３７．４３秒の間隔で、ＪＰＥＧフォーマットで、かつ２００×１５０ピクセルのサイズでビデオファイルｍｏｖｉｅ２．ａｖｉから取り出したスチール。

したがって、それぞれのケースにおいて、あるファイルに関するＣＲＥＡＴＥ／ＯＰＥＮ要求は、そのファイルに関する適切なファイルレコードが作成されるようにし、そしてＲＥＡＤ要求は、オリジナル「リアル」ファイルのエッセンスデータから適切なデータが生成されるようにするということがわかる。このように、このファイルシステムは、オリジナルビデオファイルの別のフォーマット／クォリティでのバージョンであるファイルと、また同様に、それらのビデオファイルからの別のフォーマット／クォリティでのスチールとを、それらのファイルそのものを開きたいという要求に基づいて、あたかもそれらのファイルが既に存在していたかのように、提供することができる。

次いで、本発明の第２の実施形態について、図５および図６を参照しながら説明する。図５は、この実施形態によるファイルシステム４１を含むネットワーク化されたコンピュータシステムの概略図である。前述の実施形態の場合と同様に、ファイルシステム４１は、従来のデータストア４２と、ファイルレコードデータベース４３と、ファイルシステムゲートウェイ４４とを含む。

ファイルシステムゲートウェイ４４は、（Ｍｉｃｒｏｓｏｆｔによって開発された）ＩＩＳ（Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）ウェブサーバ４５と通信状態にあり、実際には、単一のサーバが、ファイルシステム４１と、そのサーバがＩＩＳウェブサーバとして機能することを可能にするＩＩＳサーバアプリケーションの両方を組み込むことができる。ＩＩＳウェブサーバ４５は、ビデオストリーミングクライアントアプリケーション４８、たとえばＳｉｌｖｅｒｌｉｇｈｔアプリケーションを実行するパーソナルコンピュータ４７と、インターネット４６を介して通信する。

この実施形態においては、ＩＩＳウェブサーバは、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇを使用して、ビデオをストリーミングする。Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇとは、ビデオを、そのビデオがストリーミングされる帯域幅に適したクォリティレベルで提供するメディアサービスである。実質的には、ビデオは、クライアントによって、そのクライアントにとって利用可能な帯域幅がサポートできる最高のクォリティで要求される。帯域幅の不足に起因してビデオの断片がクライアントによって間に合うように受信されない場合には、クライアントは、自分が要求するビデオのクォリティを下げる。同様に、クライアントは、さらなる帯域幅が利用可能であることに気づいた場合には、自分が要求するビデオのクォリティを上げる。

ビデオの別々のクォリティを提供するために、ＩＩＳウェブサーバ４５は、自分が必要とする可能性があるすべてのクォリティレベルでストリーミングされるビデオの複数のバージョンを提供する複数のファイルが利用可能であることを必要とする。それらのファイルは、ＩＳＭＶフォーマットであり、ＩＳＭＶフォーマットとは、ＭＰＥＧ４フォーマットビデオの検索可能な断片、たとえば２秒間の断片を含むフォーマットである。これによって、ＩＩＳサーバは、ストリーミングされているビデオの元となるファイルを変更すること、ひいては、ストリーミングされるビデオでのクォリティを変更することが可能になる。なぜなら、新たなファイル内のストリーミングすべき次なる断片を検索することができるためである。ファイルは、＼ｓｔｒｅａｍｓ＼ＩＤ＼などのディレクトリにおいて提供され、ファイルのファイル名は、そのファイル内のビデオデータのクォリティを示す。

次いで、このシステムの動作について、図６のフローチャートを参照しながら説明する。ファイルシステム４１は、利用可能な最高のクォリティでのビデオの「リアル」ベースファイルを含む。はじめに、ビデオストリーミングクライアント４８が、特定のクォリティでのビデオデータをＩＩＳウェブサーバ４５に要求する（ステップ５１）。そしてこれによって、ＩＩＳウェブサーバ４５は、ファイルシステム４１内の対応するファイルを開くよう要求する（ステップ５２）。ファイルシステムゲートウェイ４４が、求められているプロパティを有するファイルに関する新たなファイルレコードをファイルレコードデータベース４３内に作成する（ステップ５３）。クライアント４８が、ビデオデータをＩＩＳウェブサーバ４５に要求すると（ステップ５４）、ＩＩＳウェブサーバ４５は、ビデオデータをファイルシステム４１に要求し（ステップ５５）、このビデオデータは、ファイルシステム４１によって、求められているプロパティを伴って、「リアル」ベースビデオファイルに関するデータから生成される。そして、その生成されたデータは、ＩＩＳウェブサーバ４５に返され、次いでクライアント４８に返される。

ステップ５４から５６は、同じクォリティのビデオデータが求められる限り、繰り返される。しかし、クライアントが別のクォリティのビデオデータを要求した場合には、プロセスは、所望のプロパティを有する新たなファイルを作成するために、ステップ５１へ戻る。

このように、この実施形態においては、ファイルシステム４１は、ファイルを作成し、ファイルのファイル名に基づいてビデオデータを生成して返すように構成されており、言い換えれば、ファイルシステム４１の構成スキームは、ＩＩＳウェブサーバ４５からの要求に応答したファイルシステム４１の動作が、ＩＩＳウェブサーバ４５によって求められているとおりになるように定義されている。

本発明について、特定の実施形態を参照しながら説明してきたが、本発明は、本明細書に具体的に記載されていない多くの異なる変形形態にも適しているということが当業者によって理解されるであろう。たとえば、本明細書において提供されている実施形態は、ＳＭＢ２ファイルシステムプロトコルを実施する（と思われる）ファイルシステムについて記載しているが、本発明は、その他のファイルシステムプロトコルとともに同様に使用することができる。さらに、本発明は、メディアファイルを格納するファイルシステムに特に適用可能であるが、さまざまなフォーマット／クォリティでのファイル（たとえば、Ｕｎｉｃｏｄｅ、ＨＴＭＬ、および独自仕様のワードプロセッサフォーマットなど、さまざまなフォーマットで提供することができるテキストファイル）を提供するために使用される任意のファイルシステムに適用可能である。本発明によるファイルシステムは、別々の要件を伴う複数のシステム（アプリケーション、分散型ソフトウェアシステム、またはハードウェアシステムなど）に関する複数のファイルを提供することを、いかなる特定のシステムに関しても、そのファイルシステムを、そのシステムの使用中に生じる状況の中で、その当該システムによって求められるとおりに動作させる適切な構成スキームを定義することによって、行うことができるということが特に理解されるであろう。

Claims (18)

1. データストアとファイルレコードデータベースとを含むファイルシステムからファイルデータを提供する方法であって、
   前記ファイルシステム内のファイルを開きたいという要求を受け取るステップと、
   前記要求のシンタックスを使用して前記ファイルの所望のプロパティを特定するステップと、
   前記ファイルの前記特定されたプロパティに基づいて前記ファイルレコードデータベース内にファイルレコードを作成するステップと、
   前記ファイルレコードに関するファイルハンドルを返すステップと、
   前記ファイルの前記特定されたプロパティに基づいて、前記データストア内のデータから、前記要求されたファイルを構成するデータを生成するステップと、
   前記ファイルからのデータの一部分を読み取りたいという要求に応答して、前記生成されたデータの対応する部分を返すステップと
   を含む方法。
2. 前記ファイルを構成するデータの前記部分が、要求された場合にのみ生成される、請求項１に記載の方法。
3. 前記要求されたファイルのファイル名が、前記ファイルに生成される前記データの元となる前記データを含む前記ファイルシステム内の既存のファイルを特定する、請求項１または２に記載の方法。
4. 前記要求されたファイルの拡張子が、前記要求されたファイルのファイルフォーマットを特定する、前記請求項１〜３のいずれかに記載の方法。
5. 前記要求されたファイルが配置されているディレクトリの階層が、前記要求されたファイルのプロパティを特定する、請求項１から４のいずれかに記載の方法。
6. 前記階層内のそれぞれのディレクトリが、前記ファイルのそれぞれのプロパティを特定する、請求項５に記載の方法。
7. 前記要求の前記シンタックスが、データベースにクエリーを行うためのデータベースクエリーを生成するために使用され、前記ファイルの前記所望のプロパティが、前記データベースクエリーの結果を使用して特定される、請求項１から６のいずれかに記載の方法。
8. データストアとファイルレコードデータベースとを含むファイルシステムのためのファイルシステムゲートウェイであって、
   前記ファイルシステム内のファイルを開きたいという要求に応答して、前記要求のシンタックスを使用して前記ファイルの所望のプロパティを特定し、前記ファイルの前記特定されたプロパティに基づいて前記ファイルレコードデータベース内にファイルレコードを作成し、前記ファイルレコードに関するファイルハンドルを返すように構成されており、
   前記ファイルの前記特定されたプロパティに基づいて、前記データストア内のデータから、前記ファイルを構成するデータを生成し、前記ファイルからのデータの一部分を読み取りたいという要求に応答して、前記生成されたデータの対応する部分を返すようにさらに構成されている、ファイルシステムゲートウェイ。
9. 前記ファイルを構成するデータの前記部分を、要求された場合にのみ生成するように構成されている、請求項８に記載のファイルシステムゲートウェイ。
10. 前記要求されたファイルのファイル名が、前記ファイルに生成される前記データの元となる前記データを含む前記ファイルシステム内の既存のファイルを特定する、請求項８または９に記載のファイルシステムゲートウェイ。
11. 前記要求されたファイルの拡張子が、前記要求されたファイルのファイルフォーマットを特定する、請求項８から１０のいずれかに記載のファイルシステムゲートウェイ。
12. 前記要求されたファイルが配置されているディレクトリの階層が、前記要求されたファイルのプロパティを特定する、請求項８から１１のいずれかに記載のファイルシステムゲートウェイ。
13. 前記階層内のそれぞれのディレクトリが、前記ファイルのそれぞれのプロパティを特定する、請求項１２に記載のファイルシステムゲートウェイ。
14. データベースにクエリーを行うためのデータベースクエリーを前記要求の前記シンタックスから生成するように構成されており、前記ファイルの前記所望のプロパティが、前記データベースクエリーの結果を使用して特定される、請求項８から１３のいずれかに記載のファイルシステムゲートウェイ。
15. 前記ファイルレコードデータベースを含む、請求項８から１４のいずれかに記載のファイルシステムゲートウェイ。
16. 請求項８から１５のいずれかに記載のデータストア、ファイルレコードデータベース、およびファイルシステムゲートウェイを含むファイルシステム。
17. 実行されたときに、請求項１から７に記載の方法のいずれかの方法のステップを実行するように構成されているコンピュータプログラム製品。
18. コンピューティングデバイス上で実行されたときに、請求項８から１５のいずれかに記載のファイルシステムゲートウェイを提供するように構成されているコンピュータプログラム製品。

Images