JP6529678B2 - アプリケーションの実行を加速する方法及びデバイス - Google Patents

Description

本発明は、第１の態様によれば、アプリケーションの実行の方法に関する。第２の態様によれば、本発明はデータパーツを送信する方法に関する。第３の態様によれば、本発明はデータパーツの格納に関する。更なる態様によれば、本発明は、更に、デバイス及びコンピュータプログラムに関する。

上述の種類の一般的な方法、具体的にはアプリケーションの実行の方法、は、従来技術から知られている。

アプリケーションの起動処理中に、アプリケーションが最終的にユーザによる対話的使用のための準備ができる前に、数秒もしくは数分、又はアプリケーションがインターネットなどのネットワークを介してサーバから最初にダウンロードされる必要がある場合は、数時間さえも、経過する可能性がある。しかしながら、一般的に、ユーザは選択したアプリケーションをできるだけ早く使用することを望んでいるであろうし、これは、起動処理はできるだけ短くすべきであることを意味する。

更に、最近では、実行可能アプリケーションがもはやデータ媒体で配布されず、ネットワーク、一例としてインターネット、を介して配布されるので、実行可能アプリケーションを転送する必要が益々頻繁に生じている。この場合にも、アプリケーションを開始するまでの時間が短いことが達成されることが確実になるように、多くのアプローチが取られてきた。

１つの例はビデオストリーミングと呼ばれるものであり、アプリケーションはサーバ上で実行され、オーディオ及びビデオストリームのみが、アプリケーションが使用されることが意図されているクライアントに転送される。

しかしながら、これに関する欠点は、待ち時間が或る状況において長すぎて、サーバから離れたクライアント上でアプリケーションを満足に、特に流動的に、使用することを可能にすることができないことである。一例として、帯域幅が十分ではない可能性があるか又は特にインターネットを介する転送では、数百ミリ秒までの待ち時間が発生する可能性がある。加えて、オーディオ及び／又はビデオストリームの形態でのデータの連続転送が必要であり、これはクライアントが連続的にオンラインである必要があることを意味する。

これらの欠点に対処するために、アプリケーションがサーバによって必要に応じてクライアントに提供されるアプリケーションストリーミングとして知られているものが使用されている。しかしながら、アプリケーションはサーバ上のビデオストリーミングと同様には実行されずに、オーディオ及び／又はビデオデータのみがクライアントに転送されることになり、どちらかと言えば、アプリケーション自体は転送され、クライアントによってローカルに実行される。アプリケーションがクライアント上でローカルに実行されるので、サーバのパフォーマンスはアプリケーションの実行のために設計される必要はない。加えて、長い待ち時間は問題にならないか又は無関係ですらある。

従って、アプリケーションが、最初にインターネットなどのネットワークを介してリモートサーバからダウンロードされる必要がある場合、アプリケーションが最終的にユーザによって対話的に使用されることができるまでに実際には数時間がかかる可能性がある。

この特定の欠点に対処するために、従来技術から、一例として、アプリケーションを開始するまでの時間が最終的に短縮されるように、アプリケーションのダウンロード及びインストールに必要な時間を短縮することが知られている。この目的のために、例えば、ソフトウェアタイトルのブロックが、実行可能な閾値に到達するまでダウンロードされることができる。その後、ソフトウェアタイトルは実行されることができ、ソフトウェアタイトルの更なるブロックのダウンロードは、ソフトウェアタイトルが実行されている間、継続されることができる。

このようにして、具体的にはアプリケーションがリモートサーバからダウンロードされる必要がある場合に、アプリケーションを開始する前及びそれまでの時間を短縮することができる。しかしながら、（部分的な）ダウンロードに続いて、その後アプリケーションは、ユーザのローカルメモリ、一例としてユーザのハードディスク、に通常通り格納される。この点に関して、最良の場合のシナリオでは、アプリケーションの実際の起動処理は、ローカルにインストールされたアプリケーションと同じくらい速いだけであろう。これは、この場合も、必要なデータが既にローカルに利用可能であるにもかかわらず、アプリケーションの起動には、ユーザが対話的にアプリケーションを使用することができるまでに、まだ数秒又は数分かかることを意味している。

しかしながら、上述のように、アプリケーションの起動までの時間を短縮することだけでなく、実行自体及び特に実際の起動自体を加速することにも関心がある。コンピュータゲームの場合、コンピュータゲームの起動時に、ユーザ又はゲーマーは、コンピュータゲームがやっと再生されるまで、一例として、ビデオシーケンスによって気をそらされることが多い。この点に関して、アプリケーション起動自体の短縮も望ましい。これは他のアプリケーションにも同様に適用される。それは、また、アプリケーションストリーミングを介してユーザに利用可能にされるアプリケーション及びローカルにユーザに既に利用可能であるアプリケーションの両方に適用される。

従って、本発明の目的は、アプリケーションの実行、具体的には起動、の加速を可能にする意図で、一般的な方法、デバイス、及びコンピュータプログラムを示すことである。

第１の態様によれば、本発明は、少なくとも１つのデバイスによって遂行されるアプリケーションを実行する方法に関し、前記方法は、
− データメモリからアプリケーションの実行に必要なデータパーツを提供するステップであって、データパーツは少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納されるステップ、
を備える。

本発明は、データパーツがデータメモリから提供されるとき、データパーツが特定の順序で、すなわち、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納されているという事実を利用する。これは、アプリケーションの必要なデータパーツを通常より早く定常的に利用可能にすることができ、具体的には、アプリケーションの起動処理が、プログラムがローカルに既にインストールされているか又は最初にリモートサーバからダウンロードされる必要があるかどうかにかかわらず、劇的に加速することができることを意味する。従って、具体的には、アプリケーションの実行を加速する方法が提供される。

ここで、データメモリは、一例として、ほんの数例を挙げると、ハードディスク、ソリッドステートディスク（ＳＳＤ）、作業メモリ（ＲＡＭ）、又は外部ドライブによって提供されることができる。

しかしながら、アプリケーションがデータメモリ（例えばハードディスク上）に従来の仕方で格納されている場合、データメモリ内の個々のデータパーツの順序は、一例として、ファイルの所属又はフォルダ構造に依存する。更に、データパーツは断片化された形態で存在することが多く、それはアプリケーションの実行を更に遅くする。断片化は、何よりも使用されている実際のファイルシステムに起因する可能性がある。ほとんどのファイルシステムは、最適な全体的な性能が達成されることができるように開発され、アプリケーションに属するデータパーツがデータメモリ内で時間と共に断片化されることにつながる。近代的なファイルシステムは、進行中の動作の間この影響を最小限に抑えることができるが、それでもなお、個々のファイルのデータパーツの順序は以前と同じように壊される。利用可能なデータメモリの様々な物理的アクセス機構にかかわらず、換言すると、一例として、回転スピンドルを有するハードディスク、ソリッドステートディスク（ＳＳＤ）、又は作業メモリ（ＲＡＭ）の場合であろうとなかろうと、直接アクセス（ランダムアクセス又はシーク動作として知られるターゲット・ジャンプ（独：gezielter Spruenge，英：targeted jump）によるアクセスとも呼ばれる）は全く同様に遅い。

データパーツは、今、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納されているので、本発明は、データパーツを、ストリーミング処理中の連続ストリームと同様の手法で利用可能にされることを可能にする。データメモリが、一例として、回転スピンドルを有するハードディスクである場合、一般に、要求されたデータパーツと同じトラック上に位置する全てのデータパーツは、これらが何れにしても書き込み読み出しヘッドを通過するので、読み出される。従って、同じトラック上の更なるデータパーツの読み出しによる追加の遅延は生じない。これらが後に要求されることがある場合には、それらは直ちに利用可能である。この点に関して、データパーツのプリロード（「データプリフェッチ」）が達成される。データメモリが、一例として、ソリッドステートベース（一例としてＳＳＤ、ＲＡＭ）上のデータメモリである場合、一般に、１つのステップで、要求されたデータパーツのみではなく、メモリページ全体が読み出される。従って、キャッシュは、隣接して格納されたデータパーツも含む。必要な次のデータパーツが短時間後に要求される場合、これはキャッシュにおいて既に利用可能である。この場合も、データパーツのプリフェッチが達成される。最後に、この方法は、（多数のホップを有する）遠距離では、ラウンドトリップ遅延時間が数百ミリ秒である可能性があり、個々のデータパーツの要求にはかなり時間がかかる可能性があるので、ネットワークを介する通信においても有利である可能性がある。

アプリケーションは、具体的には、有用又は所望の、非システム向けの機能を処理、サポート、又は提供するために使用されるコンピュータプログラムとすることができる。アプリケーションは、画像処理、ビデオ処理、テキスト処理、スプレッドシート、及び／又は財務会計、顧客管理などの特定の業務機能に使用されることが基本的に考えられる。アプリケーションは、少なくとも部分的にはユーザ空間で実行される。特に好ましくは、アプリケーションは、コンピュータゲーム又はその一部であるか又はそれを備える。方法は、アプリケーションを実行するステップを備えることもできる。

性能を更に高くするために、この方法は、好ましくは（少なくとも部分的には）カーネル空間で実行される。

アプリケーションを実行するために、アプリケーションは、一例として、１つ又は複数の実行可能ファイルを備えることができる。ここでは、一例として、直接又はランタイムシステムによって実行されることができる機械コードでのバイナリファイル又はバイトコードファイルあるいはオペレーティングシステムシェルによって解釈されることができるテキストファイルが関わっている可能性がある。データパーツは、具体的には、実行可能ファイルのデータパーツとすることができる。

アプリケーションを実行するために必要なデータパーツは、具体的には、必須の及び／又は任意選択的に必要なデータパーツであると理解されることができる。

データパーツがデータメモリに格納される順序が予期される必要な順序に基づくという事実は、具体的には、データパーツがデータメモリに格納されている（物理的な）順序が必要な（経時的）順序から決定されていることを意味する。一例として、データパーツがデータメモリに格納されている順序は、予期される必要な順序である。これが少なくとも一部の領域において起きるという事実は、具体的には、データメモリにおいて、アプリケーションを実行するために必要なデータパーツは、ある程度、従来通りに、すなわち、予期される必要な順序とは独立して格納されることもできることを意味する。

ここで、予期される必要な順序は、具体的には、アプリケーションがデータパーツをその順序で必要とするであろうことが予期されることができることを意味する。言い換えれば、データパーツは、具体的には、アプリケーション用のデータパーツの経時的必要性を反映する順序で物理的に格納される。予期される必要な順序は、具体的には、経験的に決定されることができる。具体的には、予期される必要な順序は、本発明の第３の態様に関連してより詳細に説明されるように決定されることができる。

必ずしも、アプリケーションの実行に必要な全てのデータパーツが記述したように格納されている必要はない。一例として、アプリケーションの実行に必要なデータパーツのほんの一部は、少なくとも一部の領域において予期される必要な順序に基づく順番で格納されていることもできる。

第１の態様による方法は、具体的には、他の態様に関連してより詳細に説明される少なくとも１つの第１のデバイスによって実行されることができる。

第１の態様の方法の実施形態によれば、方法は、
− アプリケーションの実行に必要なデータパーツを要求するステップ、
を更に備える。

要求するステップは、一例として、アプリケーションによって、オペレーティングシステム及び／又はファイルシステムによって、遂行されることができる。一例として、アプリケーションは、実行のためにデータパーツを必要とし、これをファイルシステムに渡す。要求するステップは、一例として、データメモリ内のデータパーツを明白に識別する（相対的及び／又は絶対的な）アドレッシングが引き渡されることで行われる。アドレッシングは、一例として、（一例として、メモリアドレス又はメモリオフセット値の形態で）データメモリ内のデータパーツの位置を指定することができる。一例として、アドレッシングは、複数のデータパーツを備えるデータメモリの領域を指定することができる。その後、アドレッシングに基づいて、（少なくとも）必要なデータパーツが読み出され提供されて、一例として、アプリケーション、ファイルシステム、及び／又はオペレーティングシステムに返される。上述したように、一般に、要求されたデータパーツだけでなく、物理的に隣接する他のデータパーツも読み出される。最適な場合には、必要なデータパーツは、別のデータパーツのプリフェッチにより既にデータメモリから読み出されており、従って、一例としてより高速なキャッシュにおいて利用可能であるため、もはやデータメモリから読み出される必要さえない。従って、データパーツは、説明された方法で著しくより高速に要求に応答して提供されることができる。

第１の態様の方法の実施形態によれば、方法は、
− アプリケーションの実行に必要なデータパーツの要求するステップに使用されるアドレッシングを、データメモリに格納されているデータパーツの順序にマッピングするステップ、
を更に備える。

要求するステップに使用されるアドレッシングをマッピングすることにより、（一例として、ファイルシステムレベルでの）アドレッシングは通常のように行われることができる。これは、例えば、アプリケーションの従来のインストールの場合と同様に、必要なデータパーツが元のアドレッシングによって要求されることができることを意味する。具体的には、要求するステップに使用されるアドレッシングは、第２のアドレッシングにマッピングされる第１のアドレッシングとすることができる。一例として、要求されたメモリアドレス又は第１のメモリアドレス領域は、第２のメモリアドレス又は第２のメモリアドレス領域にマッピングされることができる。一例として、第１のブロック番号又は第１のブロック番号範囲（又は複数の範囲）は、第２のブロック番号又は第２のブロック番号範囲（又は複数の範囲）にマッピングされることができる。マッピングは曖昧ではなく、具体的には１対１であることが好ましい。

第１の態様の方法の実施形態によれば、使用されるアドレッシングのマッピングは、ファイルシステム層の下で行われる。

一般に、ファイルシステムはオペレーティングシステムの特定の層を表す。（オペレーティングシステムの更なる層又はアプリケーションなどの）上の層はファイルにアクセスできる。ファイルシステムは、一般に、これらの抽象データをアドレッシング（一例として、ブロック番号、トラック、セクタまたは類似のもの）に変換する。下の層では、ファイルシステムドライバは、この目的のために、一例として、関連するデバイスドライバと通信することができる。

今使用されているアドレッシングのマッピングがファイルシステムの層の下で行われる故に、マッピングは非常に効率的に遂行されることができる。一例として、必要なデータパーツがファイルシステム層（又はこれより上の層）から要求される場合、ファイルシステムは通常のようにデータパーツをアドレッシングすることができるので、ファイルシステム又はその上への適応は省かれることができる。一例として、マッピングはデバイスドライバによって行われる。従って、マッピングは、好ましくは、デバイスドライバに関連付けられる層で行われる。

従って、アプリケーションの実行に必要なデータパーツの提供は、具体的には、デバイスドライバに関連付けられる層から行われることもできる。

第１の態様の方法の実施形態によれば、方法は、
− アプリケーションの実行に必要なデータパーツを受信するステップ、
を更に備える。

アプリケーションの実行に必要なデータパーツが、アプリケーションの実行中に、まだデータメモリに格納されていないか又は少なくとも部分的に格納されていないことが可能である。その後、残りのデータパーツは完全に又は部分的に受信されることができる。データパーツは、一例として、別のローカル又はリモートのデータメモリによって受信されることができる。一例として、データパーツは、ネットワークを介して、一例としてインターネットを介して、受信される。データパーツは、好ましくは、インターネットを介してリモートサーバから受信される。

一例として、要求された必要なデータパーツがデータメモリに格納されていないと判定される場合、これらのデータパーツは、それらを受信するために、（一例としてリモートサーバから）要求されることができる。しかしながら、データパーツが好ましくは連続的に受信されるので、データメモリにまだ格納されていない必要なデータパーツに対する個々の要求は好ましくは不要である。これは、個々のデータパーツは要求される必要がなく、データパーツがストリームに類似して少しずつ受信されることを意味する。これは、アプリケーションの実行を更に加速する。一方で、一例として、必要なデータパーツが既にデータメモリに格納されているか又は現在必要でないと判定される場合、説明された連続の受信を、既に格納されている及び（現在）必要でないデータパーツに対して（少なくとも部分的に）スキップすることもできる。その後、これらのデータパーツは、一例として、後の時点で受信されることができる。

データパーツは、好ましくは（少なくとも部分的には）少なくとも一部の領域において予期される必要な順序に基づく順序で受信されることができる。このように、最初に必要であると予期されるデータパーツは受信される最初のものでもある。これは、必要なデータパーツ（特に、アプリケーションを開始するために必要なデータパーツ）が最初にリモートサーバから受信される必要がある場合に、特に有利である。

アプリケーションの実行に必要なデータパーツは、具体的には、更なる態様に関連してより詳細に説明されるように、少なくとも第２のデバイスによって受信されることができる。

第１の態様の方法の実施形態によれば、方法は、
− 少なくとも一部の領域において予期される必要な順序に基づく順序でデータパーツをデータメモリに格納するステップ、
を更に備える。

必要なデータパーツがデータメモリにまだ格納されていない場合、一例として、これらが最初に受信される必要がある故に、これらは、受信後にデータメモリに好ましくは格納される。少なくとも一部の領域における順序での格納は、既に説明したように、予期される必要な順序に基づいているので、アプリケーションの実行の加速が達成される。

第１の態様の方法の実施形態によれば、データパーツはデータブロック及び／又は連続のデータブロックであり、順序はブロック順序である。

データブロックが少なくとも一部の領域において予期される必要なブロック順序に基づくブロック順序でデータメモリに格納されている場合、アプリケーションの実行の加速が特に効果的に達成されることができることが示されている。ブロック順序は、一例として、個々のデータブロック又は連続のデータブロックの順序を指定することができる。

データブロックは、具体的には限定され、設定されたバイト数と見なされる。データブロックは、個々のトランスポート単位又はアクセスでの最小の読み出し可能又は書き込み可能な単位と見なされることができる。データブロックの構造及びデータブロックの要素は、それぞれのデータメモリ、ファイルシステム、又は他の要因に依存することができる。

データブロックは、一例として、５１２バイトから４０９６バイトのサイズを有することができる。しかしながら、本質的に、より小さい、特により大きいデータブロックが考えられる。一般に、各データブロックは、データメモリ内で明白にアドレッシングされることができる。これは、様々な方法を使用して行うことができる。一例として、連続番号のブロック（ＬＢＡ）を介するデータブロックのアドレッシングが行うことができる。同様に（スピンドルを有するハードディスクの場合）、シリンダ番号、ヘッド番号、セクタ番号（ＣＨＳ）を介してブロックをアドレッシングすることが考えられる。他のデータブロックアドレッシング方法も考えられる。

また、データブロック及びブロック順序に基づく第１の態様による方法の実装に特に有利なのは、このようにして、実質的に全てのオペレーティングシステムとの高いレベルの互換性が達成されるという事実である。実際の機能は、プラットフォームに関係なく実際に実装されることができる。達成される必要のある全ては、一例として、対応するデバイスドライバを、それぞれのオペレーティングシステムにおける対応する（仮想）ブロックデバイスの作動方法に適合させることである。

第１の態様の方法の実施形態によれば、データパーツはブロックデバイス、具体的には仮想ブロックデバイス、に格納される。

（仮想）ブロックデバイスを使用することにより、データメモリは利用可能にされることができ、データブロックの形態でのデータパーツの所望の順序が達成されることができる。（仮想）ブロックデバイス又はブロック指向のデバイスは、データをデータブロックで格納又は転送する（仮想）デバイスであると理解される。ブロックデバイスは、具体的にはオペレーティングシステム自体のバッファを使用することができる。ブロックデバイスは、具体的には、ハードディスク、ＳＳＤ、ＵＳＢスティックまたは類似のものとすることができる。仮想ブロックデバイスは、実際には、オペレーティングシステムに対して、ブロックデバイスが存在し、オペレーティングシステムと通信しているか又は通信することができると見せ掛ける。具体的には、仮想ブロックデバイスは、ソフトウェアベースで、具体的にはデバイスドライバを介して、各システムにおいて利用可能とされることができるので有利である。この場合、物理データメモリは、一例として、ローカルハードディスクのデータメモリの一部によって提供されることができる。

デバイスドライバは、有利にも、具体的にはカーネル空間においてそれ自体のキャッシュに関連付けられることができるか又はこれをそれに利用可能にすることができる。このことはデータブロックの提供を更に加速する。この点に関し、第１の態様の方法は、好ましくは、ブロックデバイスを既存のファイルシステムにマウントするステップを更に備える。このようにして、ブロックデバイス上に又はブロックデバイスに存在するファイルシステムに格納されているデータは、オペレーティングシステムに利用可能にさせられることができる。仮想ブロックデバイスでは、データは、一例として、イメージに格納される。

第１の態様の方法の実施形態によれば、データメモリからアプリケーションの実行に必要なデータパーツを提供するために、デバイスドライバ、好ましくはブロックデバイスドライバ、が使用される。デバイスドライバは、好ましくは、仮想ブロックデバイス用のデバイスドライバである。

デバイスドライバは、具体的には、（仮想）デバイスとの相互作用を制御するコンピュータプログラム又はソフトウェアモジュールであると理解される。この目的のために、ドライバは、一方では、一例として（仮想）デバイスと直接通信し、データを（仮想）デバイスと交換することができる。他方では、デバイスドライバは、一例として、（仮想）デバイスが同様のデバイスと同じ手法でアドレッシングされることができるように、オペレーティングシステム及び／又はアプリケーションソフトウェア（従って、具体的にはデバイスドライバに関連付けられる層の上に位置する層）に標準化されたインターフェイスを提供することができる。

これに関して、第１の態様の方法は、好ましくは、データメモリからアプリケーションの実行に必要なデータパーツを提供するデバイスドライバをインストールするステップを更に備える。一例として、インストールはユーザによって開始される。その後、（仮想）デバイスは既存のファイルシステムにマウントされることができる。（仮想）デバイスを使用して、最終的に、データメモリがアクセスされることができ、アプリケーションが実行されることができる。

第１の態様の方法の実施形態によれば、方法は、
− 特に、必要なデータパーツがデータメモリ内で利用可能でない場合、イベントキューの処理を一時中断するステップと、
− イベントキューの処理を再開するステップと、
を更に備える。

イベントキューは、具体的には、データメモリに適用されることが意図される動作（具体的には、書き込み及び／又は読み出し動作）を備えることができる。

一例として、要求された必要なデータパーツがデータメモリに（未だ）格納されておらず、従って利用可能でない場合、アプリケーションの誤動作を避けるために、イベントキューの処理を一時中断することが有利である可能性がある。イベントキューが以前に説明したデバイスドライバ又は（仮想）デバイスのイベントキューである場合、特に有利である。その後、一時中断は、一例としてデバイスドライバによって遂行されることができる。しかしながら、基本的には、（オペレーティングシステム又はプログラムの）外部コマンドによってデバイスドライバのイベントキューを一時中断することも可能である。その際、ファイルシステムなどのデバイスドライバに関連付けられる層の上の層がデバイスドライバを待っているという事実を利用することは有利である。従って、データパーツが利用可能でない場合、状況は、実際には、あたかも遅延を引き起こす（仮想）デバイスの遅い読み出しが存在したかのようである。

一例として、イベントキューの処理は所定時間の間一時中断される。一例として、イベントキューの処理が一時中断される時間が決定される（一例として、計算又は推定される）。データパーツが、一例としてネットワークを介して一例として伝送速度を使用して受信される場合、必要なデータパーツが受信される（ことが予測される）であろうし、且つデータメモリに格納することができて従って利用可能となることができる時が推定されることができる。

その後、データパーツが利用可能かどうかがチェックされることができる。データパーツが利用可能である場合、イベントキューの処理が再開されることができる。そうでない場合、イベントキューの処理の更なる一時中断が行われる可能性がある。

第１の態様の方法の実施形態によれば、アプリケーションの開始に関連するデータパーツに少なくとも関するデータパーツは、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納される。

アプリケーション開始に関連するデータパーツは、アプリケーションを開始するのに関連するデータパーツであると理解される。一例として、アプリケーション開始に関連するデータパーツは、アプリケーションがユーザによって対話的に使用されることができる限りにおいてアプリケーションを実行するために必要とされるデータパーツである。一例として、アプリケーション開始に関連するデータパーツは、アプリケーション全体の１０％未満及び／又は５０メガバイト未満を占める。これは、具体的には、アプリケーションの実行時に起動が加速されることを可能にする。

しかしながら、これとは独立に、少なくとも一部の領域において予期される必要な順序に基づく順序で、アプリケーションを開始するのに直接には必要ではない（しかし後になってからのみ必要となる）データパーツを格納することも明らかに可能である。

一例として、データパーツが予期される必要な順序に基づいて格納されているアプリケーションのデータパーツの第１の量が提供され、データパーツが予期される必要な順序に基づいていなく、それとは独立しているアプリケーションのデータパーツの第２の量が提供されることも考えられる。その結果、第１の量は、一例として迅速な実行が可能となるように、アプリケーション関連のデータパーツを備えることができるのに対して、第２の量におけるデータパーツの順序は最適化される必要はない。

第１の態様の方法の実施形態によれば、方法は、
− アプリケーションを実行するためにアプリケーションに関連付けられるメタデータ情報を使用するステップ、
を更に備える。

メタデータ情報は、具体的には、アプリケーションを実行するために（少なくとも部分的に）必要なアプリケーション特有の情報であると理解される。一例として、メタデータ情報は、アプリケーションのインストール及び／又は実行中に、アプリケーションを実行するシステム（例えば、オペレーティングシステム及び／又はファイルシステム）にもたらされる変更を備える。一例として、メタデータ情報は、経路情報、ファイル情報、ディレクトリ情報、環境変数に関する情報及び／又はデータベース（例えば、登録データベース）に関する情報、あるいはこれらに対する変更（例えば、新規エントリ）を備える。メタデータ情報は更なる従属情報も備えることができる。

同様に、メタデータ情報は、アプリケーションの実行に必要なデータパーツを要求するために使用されるアドレッシングを、データメモリに格納されるデータパーツの順序にマッピングすることを可能にするマッピング情報を含むことができる。しかしながら、マッピング情報はメタデータ情報とは独立に転送されることもできる。

第２の態様によれば、本発明は、少なくとも１つのデバイスによって実施される、具体的には第１の態様による方法で使用される、データパーツを送信する方法にも関し、方法は、
− アプリケーションの実行に必要なデータパーツを送信するステップであって、データパーツは、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納される、ステップ、
を備える。

第１の態様に関連して既に述べたように、データパーツは、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納されているので、必要なデータパーツアプリケーションが概して通常よりも素早くアプリケーションに利用可能となること及び具体的にはアプリケーション起動処理が劇的に加速されることが可能である。

第２の態様による方法は、具体的には、更なる態様に関連してより詳細に記載される少なくとも１つの第２のデバイスによって実行されることができる。

データパーツは、一例として第１の態様による方法を実施する第１のデバイスに送信されることができる。一例として、データパーツは、少なくとも１つのファイル、一例としてイメージ、に格納される。これは、イメージのみが送信される必要があることを意味する。送信されたデータパーツが受信されて格納される場合、これらは、有利にも、少なくとも一部の領域において予期される必要な順序に基づく順序で、直接データメモリ内に受け取り側で自動的に格納される。

そのような順序が決定されることができる手法は、本発明の第３の態様に関連して一例として説明される。

第２の態様の方法の実施形態によれば、データパーツは少なくとも部分的に格納された順序で送信される。

データパーツは少なくとも部分的に格納された順序で送信されるので、最初に必要とされると予期されるデータパーツが送信されるべき最初のものであり、最初に受信されることができる。従って、具体的には、必要なデータパーツ（具体的には、アプリケーションを開始するために必要なデータパーツ）が（例えば、第１のデバイスによって）依然として受信される必要がある状況において、アプリケーションを開始するまでの時間も短縮される。

第２の態様の方法の実施形態によれば、方法は、
− アプリケーションの実行に必要なデータパーツの少なくとも一部を送信する要求を受信するステップ、
を更に備える。

一例として、必要なデータパーツがそこのデータメモリに格納されていないことが第１のデバイスによって判別される場合、これらのデータパーツは、それらが受信されるために要求されることができる。その後、データパーツの送信の要求は、第２の態様の方法の過程で、一例として第２のデバイスによって、受信されることができる。

送信リクエストでは、個々のデータパーツ又はデータパーツの範囲が要求されることが考えられる。しかしながら、データパーツは好ましくは連続的に送信されるので、必要なデータパーツを個々に要求することは好ましくは不要である。これは、データパーツが、受信される必要のある個々のデータパーツの要求なしに、ストリームに類似して少しずつ送信されることを意味する。これは、アプリケーションの受信ひいては実行を加速する。

第２の態様の方法の実施形態によれば、方法は、
− アプリケーションの実行のためにアプリケーションに関連付けられるメタデータ情報を送信するステップ、
を更に備える。

第１の態様に関連して既に説明したように、メタデータ情報は、一例として、経路情報、ファイル情報、ディレクトリ情報、環境変数に関する情報及び／又はデータベース（例えば、登録データベース）に関する情報、あるいはこれらに対する変更（例えば、新規エントリ）を備える。メタデータ情報は、一例として、同様に、少なくとも１つのファイルに含まれることができる。同様に、メタデータ情報が含まれる少なくとも１つの別個のファイルが提供されることができる。メタデータ情報はメモリに保持されることもできる。メタデータ情報は好ましくは最初に送信される。一例として、メタデータ情報は、プッシュ処理の過程で又はプル処理の過程で送信されることができる。

同様に、メタデータ情報は、アプリケーションの実行に必要なデータパーツを要求するために使用されるアドレッシングを、データメモリに格納されるデータパーツの順序にマッピングすることを可能にするマッピング情報を備えることができる。しかしながら、マッピング情報はメタデータ情報とは独立に転送されることもできる。

更なる実施形態に関して、具体的にはデータブロックとしてのデータパーツの実施形態に関して、第１の態様に関連する説明が参照される。

第３の態様によれば、本発明は、少なくとも１つのデバイスによって実施される必要なデータパーツを格納する方法にも関し、前記方法は、
− アプリケーションの実行に必要なデータパーツの取得された必要な順序を受信するステップと、
− 取得された必要な順序に少なくとも基づいて、予期される必要な順序を決定するステップと、
− 少なくとも一部の領域において予期される必要な順序に基づく順序で必要なデータパーツをデータメモリに格納するステップと、
を備える。

方法は、必要なデータパーツが少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納されることを可能にする。

少なくとも取得された必要な順序に基づいて、予期される必要な順序は決定されることができる。一例として、取得された必要な順序は、予期される必要な順序に対応する。一例として、取得された必要な順序は、予期される必要な順序を決定する際において、複数の要因（一例として、更なる取得された必要な順序）のうちの１つにすぎない。

最後に、必要なデータパーツは、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに格納されることができる。結果として、データパーツは、一例としてデータメモリにおけるアプリケーションの通常のインストール後に存在する元の格納された順序と比較して、再配列される。従って、最適化されたアプリケーションが利用可能である。第１の態様に関連して既に説明したように、これは、アプリケーションの実行が、一例として第１の態様の方法に従って、今や加速されることを可能にする。

加えて、一例としてデータメモリにおけるアプリケーションの通常のインストール後に存在する元の格納された順序と再配列された順序との間のマッピングを可能にするマッピング情報が格納されることができる。言い換えると、マッピング情報は、アプリケーションの実行に必要なデータパーツを要求するために使用されるアドレッシングを、データメモリに再配列されたデータパーツの順序にマッピングすることを可能にする。

方法は、アプリケーションによって必要な全てのデータパーツに対して必ずしも遂行される必要はなく、それは、一例として、必要なデータパーツのほんの一部に対して遂行されることもできる。

方法は、具体的には、更なる態様に関連してより詳細に記載されるように、少なくとも第３のデバイスによって実施されることができる。

第３の態様の方法の実施形態によれば、方法は、以下のステップ、
− デバイスドライバ、好ましくはブロックデバイスドライバ、をインストールするステップ、
− イメージを生成するステップ、
− デバイスドライバを介して、具体的にはインストールされたデバイスドライバを介して、デバイスをマウントするステップ、
− アプリケーションを、特に、生成されたイメージ上にインストールするステップ、
− アプリケーションの実行のためにアプリケーションに関連付けられるメタデータ情報を決定するステップ、
− アプリケーションを実行するステップ、
− アプリケーションの実行に必要なデータパーツの必要な順序を取得するステップ、
のうちの１つ又は複数を更に備える。

１つ又は複数のステップは、具体的には、アプリケーションの実行に必要なデータパーツの必要な順序の取得を準備するために役立つ。１つ又は複数（特に全て）の上記のステップは、一例として、１つ又は複数のデータ処理システム上で、具体的には分析環境で、実施される。分析環境は、具体的には、ソフトウェアを分析するために使用される技術的／組織的インフラであると理解される。

デバイスドライバ、具体的にはブロックデバイスドライバ、を介して、アプリケーションを実行するために必要なデータパーツの必要な順序の取得は極めて効率的に遂行されることができる。イメージも生成されることができる。デバイスドライバのインストールに続いて、デバイス、具体的にはブロックデバイス及びそれによるイメージも、既存のファイルシステム内のデバイスドライバを介してマウントされることができる。ここで、ブロックデバイスは、好ましくは仮想ブロックデバイスである。デバイスひいてはイメージも、デバイスドライバを介してアクセスされることができる。その後、アプリケーションはデバイス上にひいてはイメージ上にもインストールされることができる。

加えて、アプリケーションに関連付けられるメタデータ情報は、この時点でアプリケーションの実行のために決定されることができる。これは、一例として、アプリケーションのインストール前とインストール後のシステム（例えば、オペレーティングシステム及び／又はファイルシステム）の比較によって行われることができる。同様に、（一例として、書き込み及び／又は読み出し処理の取得による）実際のシステム変更の性能が取得されることができる。これは、他のデバイス（一例として、第１のデバイス）上でのアプリケーションの実行を単純化する。これらは、既にインストールされているアプリケーション及びメタデータ情報のイメージだけが利用可能にされることを必要とし、再インストールは不要である。第１の態様及び第２の態様に関連して既に説明されたように、メタデータ情報は、一例として、経路情報、ファイル情報、ディレクトリ情報、環境変数に関する情報及び／又はデータベース（例えば、登録データベース）に関する情報、あるいはこれらに対する変更（例えば、新しいエントリ）を備える。

次に、アプリケーションが実行されることができる。このアプリケーションは、第１の態様の方法に従って実行されるアプリケーションに対応する。これに関して、第１の態様に関連する説明が参照される。しかしながら、ここでは、アプリケーションによって必要とされるデータパーツは、初期に（少なくとも部分的には）少なくとも一部の領域において予期される必要な順序に基づく順序でまだ格納されていない。

アプリケーションの実行の過程で、アプリケーションはその実行のために或る（経時的）順序でデータパーツを必要とするであろう。この目的のために、一例として、アプリケーション、オペレーティングシステム、及び／又はファイルシステムは、必要なデータパーツを要求することができる。この順序は取得されることができ、これは、有利にもファイルシステムのレベルの下位で行われることができる。一例として、取得はデバイスドライバによって行われる。第１の態様に関して既に説明されたように、データパーツは好ましくはデータブロックであり、順序はブロック順序である。この点について、第１の態様に関連する説明が参照される。

第３の態様の方法の実施形態によれば、アプリケーションの実行に必要なデータパーツの取得された必要な順序は、アプリケーションの実行中に必要なデータパーツに対する読み出し動作に関するログ情報を備える。

このようにして、アプリケーションの実行に必要なデータパーツの順序の取得は、極めて効率的に遂行されることができる。情報をログすることは、デバイスドライバによって特に有利に遂行される。一例として、デバイスドライバにおいて定義された書き込み及び／又は読み出し動作は、何れにせよ、アプリケーションの実行中に必要なデータパーツに対する読み出し動作に関する情報をログすることを可能にするように、拡張される。（相対的又は絶対的な）アドレッシングがログされるので、必要なデータパーツに対する読み出し動作に関する情報をログすることは、一例として実施されることができる。一例として、ログ情報を含むログファイルが生成される。

第３の態様の方法の実施形態によれば、ログ情報はそれぞれの必要なデータパーツの曖昧でない識別を可能にする。

曖昧でない識別は、曖昧でない（相対的及び／又は絶対的な）アドレッシングをログすることによって達成されることができる。アドレッシングは、一例として、（曖昧でないメモリアドレス又は曖昧でないメモリオフセット値の形態で）データメモリ内のデータパーツの曖昧でない位置を備えることができる。一例として、アドレッシングは、複数のデータパーツを備えるデータメモリの曖昧でない領域を指定することができる。データパーツが一例としてデータブロックである場合、一例として、曖昧でないブロック番号又は曖昧でないブロック番号範囲がログされることができる。

第３の態様の方法の実施形態によれば、ログ情報はまた、以下の情報、
− 時間情報、
− アプリケーション特有のイベント、
− ユーザ特有の情報、
のうちの１つ又は複数を備える。

時間情報は、一例としてデータパーツ又はデータパーツの範囲が必要とされた時点、すなわち、具体的には対応するデータパーツ又は範囲に対する読取りアクセスが行われた時点、に関する相対的及び／又は絶対的な時間情報を備えることができる。

アプリケーション特有のイベントは、一例としてアプリケーションの起動の開始、アプリケーションの対話部分の開始、及び／又は或るアプリケーションセクションの開始（ゲームでは、一例として、レベル１、レベル２、レベル３などの開始）とすることができる。

ユーザ特有の情報は、一例としてユーザ入力情報とすることができる。入力情報は、具体的には（例えば、キーボード又はマウスを有する）入力デバイスを使用して入力される入力、一例としてどのキーが押されたか、に関する情報である。

予期される必要な順序の決定は、その後、有利にも、これらの情報の項目のうちの１つ又は複数に基づいて実施されることができる。一例として、入力情報などの或るユーザ特有の情報は、予期される必要な順序に影響を及ぼす可能性がある。これは、その後、一例としてアプリケーションの実行に必要なデータパーツの受信後に考慮に入れられることができる。

第３の態様の方法の実施形態によれば、アプリケーションの実行に必要なデータパーツの多数の取得された必要な順序が受信され、予期される必要な順序は、多数の取得された必要な順序に少なくとも基づいて決定される。

一例として、取得は少なくとも２回、好ましくは多数回遂行される。その後、予期される必要な順序が少なくとも多数の取得された必要な順序に基づいて決定される場合、予期される必要な順序は、より信頼性高く決定されることができる。これは、アプリケーションのプログラムフローがユーザによって影響を受ける可能性がある対話型アプリケーションでは特に有利であり、それは、このように、必要なデータパーツの順序も影響を受けるからである。一例として、この目的のために、それぞれの取得された必要な順序が、集約された順序又は結合された順序を形成するように集約され、それに基づいて、予期される必要な順序が決定されることができる。

一例として、多数の取得が、様々なデバイス上で、一例として一連の分析デバイス上で、実施されることができる。他方、予期される必要な順序の決定及び必要なデータパーツの保存は、好ましくは中央デバイス上で実施されることができる。

第３の態様の方法の実施形態によれば、取得された必要な順序のうちの連続セクションの場合には、連続セクションは短縮される。

これは、具体的には取得が多数回遂行される場合にも、必要な順序の連続セクションを可能な限り１つの列として受信することが達成されることを可能にし、取得された必要な順序が短縮される。従って、例として、一例として、必要なデータパーツの連続セクション（２、３、４、５、…、ｎ−１、ｎ）が取得される場合、連続セクションは（２…ｎ）のように短縮され、そのようにログされる。しかしながら、連続セクションは必ずしも短縮される必要はない。一例として、或る長さの連続セクション又は最大数の連続セクションのみが短縮される。

第３の態様によれば、格納されている必要なデータパーツは、その後一例として、第２の態様の方法に従って送信されることができる。第１の態様の方法では、アプリケーションの起動は最終的に加速されることができる。

更なる態様によれば、本発明は、第１の態様による方法を実施及び／又は制御する適切な手段として構成されるか又はその手段を備えるデバイス（第１のデバイス）にも関する。第１のデバイスは、具体的には、エンドユーザ、一例としてクライアント、のデータ処理システムとすることができる。

更なる態様によれば、本発明は、コンピュータプログラムがプロセッサ上で動作する場合、プロセッサが第１の態様（又はその一部）による方法を実施及び／又は制御することを可能にするプログラム命令を備えるコンピュータプログラム（第１のコンピュータプログラム）にも関する。

更なる態様によれば、上記の目的は、第２の態様による方法を実施及び／又は制御する適切な手段として構成されるか又はその手段を備えるデバイス（第２のデバイス）によっても達成される。第２のデバイスは、具体的には、データをエンドユーザに対して利用可能にするサーバとすることができる。

更なる態様によれば、本発明は、コンピュータプログラムがプロセッサ上で動作している場合、プロセッサが第２の態様（又はその一部）による方法を実施及び／又は制御することを可能にするプログラム命令を備えるコンピュータプログラム（第２のコンピュータプログラム）にも関する。

更なる態様によれば、上記の目的は、第３の態様による方法を実施及び／又は制御する適切な手段として構成されるか又はその手段を備えるデバイス（第３のデバイス）によっても達成される。第３のデバイスは、具体的には、複数のデータ処理システムを備えることができ、一例として、第３のデバイスは複数の分析データ処理システム及び中央サーバを備える。

更なる態様によれば、本発明は、コンピュータプログラムがプロセッサ上で動作している場合、プロセッサが第３の態様（又はその一部）による方法を実施及び／又は制御することを可能にするプログラム命令を備えるコンピュータプログラム（第３のコンピュータプログラム）にも関する。

それぞれのデバイスは、好ましくは、少なくとも１つのプロセッサ及びコンピュータプログラムコードを有する少なくとも１つのメモリを備え、少なくとも１つのメモリ及びコンピュータプログラムコードは、第１の態様、第２の態様、及び／又は第３の態様による少なくとも１つの方法で、少なくとも１つのプロセッサを実施及び／又は制御するように構成される。

例えば、第１のデバイス、第２のデバイス、及び第３のデバイスは、本発明によるそれぞれの方法のそれぞれのステップ（又はこれらのうちの一部）を実施することができるように、ソフトウェア及び／又はハードウェアベースで構成される、互いに異なるデータ処理システムである。ソフトウェア及び／又はハードウェアベースで構成されることは、例えば、一例としてコンピュータプログラムの形態で、それぞれの方法のステップ（又はその一部）の実施を可能にするために必要なそれぞれのデータ処理システムの準備を意味するように意図されている。データ処理システムの例は、コンピュータ、デスクトップコンピュータ、ラップトップコンピュータなどのポータブルコンピュータ、タブレットコンピュータ、パーソナルデジタルアシスタント、スマートフォン、及び／又はシンクライアントである。

しかしながら、一例として、個々の態様の、一例として第２の態様及び第３の態様の、ステップは、共有データ処理システム上で実施されることも基本的に考えられる。態様のステップは様々なデータ処理システム上で実施されることが同様に考えられる。

例えば、第１のデバイス、第２のデバイス、及び／又は第３のデバイスは、各々、プロセッサなどの本発明によるコンピュータプログラムのうちの１つを実行する手段を含む。プロセッサは、例えば、制御ユニット、マイクロプロセッサ、マイクロコントローラなどのマイクロ制御ユニット、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）であると理解されるように意図されている。

例えば、第１のデバイス、第２のデバイス、及び／又は第３のデバイスは、何れの場合も、プログラムメモリ及び／又はメインメモリなどの情報を格納する手段も備える。

例えば、第１のデバイス、第２のデバイス、及び／又は第３のデバイスは、何れの場合も、ネットワークインタフェースなどのネットワークを介して情報を受信及び／又は送信する手段も備える。例えば、第１のデバイス、第２のデバイス、及び／又は第３のデバイスは、１つ又は複数のネットワークを介して互いに接続される且つ／又は接続可能である。

コンピュータプログラムは、一例としてネットワークを介して配布可能である。コンピュータプログラムは、少なくとも部分的には、プロセッサのソフトウェア及び／又はファームウェアとすることができる。

第１のコンピュータプログラム、第２のコンピュータプログラム、及び／又は第３のコンピュータプログラムは、一例としてアプリケーションプログラムを備えることができる。第１のコンピュータプログラム及び／又は第２のコンピュータプログラムは具体的にはデバイスドライバを備える。

本発明によるコンピュータプログラムは、何れの場合も、本発明による１つ又は複数のコンピュータプログラムを含む機械可読記憶媒体に格納されることができ、例えば、磁気、電気、電磁気、光学、及び／又は他のタイプの記憶媒体として構成される。このような機械可読記憶媒体は、好ましくは物理的（従って有形）であり、例えばデータ媒体デバイスとして構成される。そのようなデータ媒体デバイスは、一例として、携帯可能であるか又は取り外せないようにデバイスにインストールされる。そのようなデータ媒体デバイスの例は、例えばＮＯＲフラッシュメモリなどのランダムアクセス（ＲＡＭ）を有するかもしくはＮＡＮＤフラッシュメモリなどの逐次型アクセスを有する揮発性もしくは不揮発性メモリ及び／又は読み出し（ＲＯＭ）もしくは読み出し／書き込みアクセスを有するメモリである。機械可読は、例えば記憶媒体がコンピュータ又はデータ処理システムによって、一例としてプロセッサによって、読まれ（読み出され）又は書き込まれることができることを意味するように意図されている。

この明細書に記載されている例示的実施形態は、全ての互いの組み合わせで開示されることも意図されている。

本発明の更なる有利な例示的実施形態は、具体的には図面に関連して本発明の多くの実例の以下の詳細な説明によって示される。

しかしながら、本出願に添付されている図面は、明確化の目的のためにのみ使用されることが意図され、本発明の保護の範囲を決定することが意図されるものではない。添付の図面は一定の縮尺ではなく、本発明の一般概念を反映する例としてのみ意図されている。特に、図面に示されている特徴は、決して、本発明の必須の構成要素の一部と見なされるものではない。

図面を以下に示す。

例示的なデータ処理システムのブロック図 様々な態様による方法を実施するための様々な例示的なデバイスのシステムの概略図 第３の態様による方法の例示的実施形態の文脈において実施されることができる例示的な方法のフロー図 オペレーティングシステムの様々な層の概略図 第３の態様による方法の例示的実施形態のフロー図 第２の態様による方法の例示的実施形態のフロー図 第１の態様による方法の例示的実施形態のフロー図

図１はデータ処理システム１の例示的実施形態のブロック図を示す。データ処理システム１は様々な態様によるデバイスの一例としての機能を果たし、具体的には、第１のデバイス、第２のデバイス、及び／又は第３のデバイスはデータ処理システム１に従って実装されることができる。

データ処理システム１は、一例として、コンピュータ、デスクトップコンピュータ、ラップトップコンピュータなどのポータブルコンピュータ、タブレットコンピュータ、パーソナルデジタルアシスタント、スマートフォン、及び／又はシンクライアントとすることができる。データ処理システムは、一例として、サーバ又はクライアントの機能を実行することができる。

データ処理システム１のプロセッサ１００は、具体的には、マイクロプロセッサ、マイクロコントローラなどのマイクロ制御ユニット、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）として構成される。

プロセッサ１００は、プログラムメモリ１２０に格納されているプログラム命令を実行し、一例として中間結果又は類似のものをメインメモリ１１０に格納する。例えば、プログラムメモリ１２０は、フラッシュメモリ、磁気メモリ、ＥＥＰＲＯＭメモリ（電気的に消去可能なプログラム可能な読み出し専用メモリ）、及び／又は光メモリなどの不揮発性メモリである。メインメモリ１１０は、例えば、揮発性又は不揮発性メモリであり、具体的には、スタティックＲＡＭメモリ（ＳＲＡＭ）、ダイナミックＲＡＭメモリ（ＤＲＡＭ）、強誘電体ＲＡＭメモリ（ＦｅＲＡＭ）及び／又は磁気ＲＡＭメモリ（ＭＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）である。

プログラムメモリ１２０は、好ましくは、データ処理システム１への固定接続を有するローカルデータ媒体である。データ処理システム１への固定接続を有するデータ媒体は、一例としてデータ処理システム１に組み込まれたハードディスクである。代替的に、データ媒体は、一例として、メモリスティック、リムーバブル記憶デバイス、ポータブルハードドライブ、ＣＤ、ＤＶＤ、及び／又はディスケットなどの、データ処理システム１に分離可能に接続されているデータ媒体とすることもできる。

プログラムメモリ１２０は、データ処理システム１が起動される場合、少なくとも部分的にメインメモリ１１０にロードされ、プロセッサ１００によって実行されるデータ処理システム１のオペレーティングシステムを含む。具体的には、データ処理システム１が起動される場合、オペレーティングシステムのコアの少なくとも一部がメインメモリ１１０にロードされ、プロセッサ１００によって実行される。データ処理システム１のオペレーティングシステムは、一例として、Ｗｉｎｄｏｗｓ、ＵＮＩＸ（登録商標）具体的にはＬｉｎｕｘ（登録商標）、Ａｎｄｒｏｉｄ、Ａｐｐｌｅ ｉＯＳ、及び／又はＭＡＣオペレーティングシステムである。

オペレーティングシステムは、具体的には、データ処理のためにデータ処理システム１の使用を可能にする。オペレーティングシステムは、一例として、メインメモリ１１０及びプログラムメモリ１２０、ネットワークインタフェース１３０、並びに入力／出力デバイス１４０などのリソースを管理し、他の基本プログラム機能をとりわけプログラミングインターフェースを介して利用可能にし、且つプログラムの実行を制御する。

プロセッサ１００は、一例として、データ処理システム１とネットワークとの間のリンクを作成するためにネットワークカード、ネットワークモジュール、及び／又はモデムであり且つそれらとして構成されるネットワークインタフェース１３０を制御する。ネットワークインタフェース１３０は、一例としてネットワークを介してデータを受信してこれをプロセッサ１００に渡し且つ／又はプロセッサ１００からデータを受信してそれをネットワークを介して送信することができる。ネットワークの例は、イーサネット（登録商標）ネットワークもしくはＩＥＥＥ８０２ネットワークなどのローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ネットワーク、有線ネットワーク、携帯電話ネットワーク、電話ネットワーク、及び／又はインターネットである。

プロセッサ１００は少なくとも１つの入力／出力デバイス１４０を更に制御することができる。入力／出力デバイス１４０は、一例として、キーボード、マウス、ディスプレイユニット、マイクロホン、タッチセンシティブ・ディスプレイデバイス、拡声器、スキャナー、ディスクドライブ、及び／又はカメラである。入力／出力デバイス１４０は、一例として、ユーザからの入力を受信してこれらをプロセッサ１００に渡し且つ／又はプロセッサ１００からユーザ向けの出力情報を受信することができる。

図２は様々な態様による方法を実施するための様々な例示的なデバイスのシステム２の概略図である。

サーバ２００は、コンピュータ２１０と共に、図３に関連してより詳細に説明されるように、第３の態様による方法の実施形態を実施することができる。同様に、サーバ２００は、図５に関連してより詳細に説明されるように、第２の態様による方法の実施形態を実施することができる。最後に、コンピュータ２５０は、図６に関連してより詳細に説明されるように、第１の態様による方法の実施形態を実施することができる。

初めに、図３は、第３の態様による方法の例示的実施形態の文脈において実施されることができる例示的な方法のフロー図３を示す。

方法は１つ又は複数のコンピュータ２１０上で実施されることができる。ここで、コンピュータ２１０は分析環境を提供する。初めに、何れの場合でも仮想ブロックデバイス用のブロックデバイスドライバがインストールされる（ステップ３１０）。次に、イメージがそれぞれのコンピュータ２１０上に生成される（ステップ３２０）。ブロックデバイスドライバの助けを借りて、仮想ブロックデバイス及びそれによりイメージも、それぞれのコンピュータ２１０のオペレーティングシステムのファイルシステムにマウントされることができる（ステップ３３０）。次に、最適化されることになっているアプリケーション（例えば、コンピュータゲーム）は、生成されたイメージ上にインストールされることができる（ステップ３４０）。ここで、イメージは、それぞれのコンピュータ２１０のそれぞれのローカル（例えば、ハードディスク上）のプログラムメモリ１２０に物理的に格納される。従って、アプリケーションの実行に必要なデータブロックは、それぞれのプログラムメモリ内に存在する。しかしながら、これらはまだ最適化された順序３０で格納されていない。

ステップ３４０の後又は少なくとも部分的にはステップ３４０の間に実施されることができるステップ３５０において、アプリケーションに関連付けられるメタデータ情報は、アプリケーションの実行のために決定されることができる。そうすることで、アプリケーションを開始するために必要な、それぞれのコンピュータ２１０にインストールされたオペレーティングシステム及びファイルシステムへの変更が取得される。これらは、一例としてファイルに格納される。

その後、アプリケーションはそれぞれのコンピュータ２１０上で実行され（ステップ３６０）、それぞれのユーザ２２０によって使用されることができる。そうすることで、アプリケーションの実行に必要なデータブロックの必要な順序を取得することができる（ステップ３７０）。

ここで、図４は、一例として、個々のコンピュータ２１０又は２５０上に存在するオペレーティングシステム４の様々な層の概略図である。４つの層４１０、４２０、４３０、４４０が示されている。オペレーティングシステム４は、その上、その下、又はその間に配置される追加の層を有することもできる。層４２０において、デバイスドライバ４２１、４２２（「ドライバ１」、「ドライバ２」）が提供される。これらは、下層４１０のハードウェアとの相互作用を制御するコンピュータプログラム又はソフトウェアモジュールとすることができる。その一方で、デバイスドライバは、層４３０のファイルシステム４３１、４３２（「ファイルシステム１」、「ファイルシステム２」）と通信する。次に、ファイルシステムは、一例として、アプリケーションによって使用されることができる層４４０のシステムコールルーチンと通信することができる。基本的に、一例として様々なファイルシステムが１つのドライバと通信する必要があるだけでよいように、ドライバの様々なインスタンスが使用されることもできる。一例として、複数のインスタンスは、各々が異なるアプリケーションを含む仮想ブロックデバイスを同時に使用することができる。

ここで、アプリケーションが或るデータブロックを必要とする場合、これらはファイルシステム、一例としてファイルシステム４３１、を介して要求される。この要求は、イメージ上にインストールされているアプリケーションにアクセスすることができるブロックデバイスドライバ、一例としてドライバ４２１、によって対処され、必要なデータブロックが返される。

ここで、ブロックデバイスドライバ４２１における書き込み及び／又は読み出し動作は、要求されたデータブロックが（例えば、データブロックを明白に識別するブロック番号、メモリアドレス及び／又はメモリオフセットをログすることによって）ログされるように拡張される。従って、アプリケーションの実行に必要なデータブロックの必要なブロック順序は、ブロックデバイスドライバ４２１を使用してログされる。加えて、時間オフセットの形態での時間情報がログされる。アプリケーション特有のイベントまたはユーザ特有の情報などの更なる情報が同様にログされる。

一例として、コンピュータ２１０のうちの１つの上で、必要なデータブロックのブロック番号及び関連付けられる時間オフセットを示す以下の第１の必要な順序が取得される。

一例として、コンピュータ２１０のうちの別のものの上で、必要なデータブロックのブロック番号及び関連付けられる時間オフセットを示す以下の第２の必要な順序が取得される。

次に、図５は第３の態様による方法の例示的実施形態のフロー図を示す。

多数の取得された順序は、一例として、サーバは、ネットワーク２３０を介してサーバ２００に利用可能にされることができ、アプリケーションの実行に必要なデータブロックの取得された必要な順序を受信する（ステップ５１０）。

これらに基づいて、サーバ２００は予期される必要な順序を決定することができる（ステップ５２０）。この目的のために、複数の取得された順序は、時間情報に従ってソートされ短縮されることができ、次の順序になる。

予期される必要なブロック順序（０、２、０、８、９、５、６、７）もそれから決定されることができる。任意選択的に、含まれている多数のデータブロックは、予期される必要なブロック順序（０、２、８、９、５、６、７）となるように、無視されることができる。

このようにして決定された予期される必要なブロック順序は、その後、少なくとも一部の領域において予期される必要な順序に基づく順序で、具体的には予期される必要な順序自体で、必要なデータブロックをデータメモリに格納するために使用される（ステップ５３０）。

一例として、インストールされたアプリケーションを示す元のイメージのデータブロックは再配列される。加えて、マッピング情報は格納され、元のイメージを再配列されたイメージにマッピングすることを可能にする。

次に、図６は第２の態様による方法の例示的実施形態のフロー図を示す。方法は、一例としてサーバ２００によって同様に実施されることができる。

初めに、サーバ２００は、アプリケーションの実行に必要なデータブロックうちの少なくとも一部を送信する要求を受信する（ステップ６１０）。要求は、一例としてインターネット２４０などのネットワークを介してコンピュータ２５０のうちの１つによって行われることができる。

対応するコンピュータ２５０上で、アプリケーションの実行のためにアプリケーションに関連付けられるメタデータ情報が未だ利用可能でない場合、これらが最初に送信されることができる（ステップ６２０）。メタデータ情報と一緒に又はそれらとは別に、元のイメージの再配列イメージへのマッピングを可能にする格納されているマッピング情報もコンピュータ２５０に送信される。次に、必要なデータブロックが対応するコンピュータに送信される（ステップ６３０）。一例として、イメージは、説明されたように再配列されたアプリケーションのデータブロックと共に送信される。そうすることで、データブロックは、ステップ５３０によって可能にされるように、少なくとも一部の領域において予期される必要な順序に基づく既存の順序で、サーバ２００上でデータメモリに格納される。そうすることで、データブロックも好ましくは格納されている順序で送信される。

図７は第１の態様による方法の例示的実施形態のフロー図を示す。方法は、一例として何れの場合もコンピュータ２５０によって実施されることができる。一例として、コンピュータ２５０のユーザ２６０はアプリケーションを実行することを望む。この目的のために、対応するコンピュータ２５０は、一例としてインターネット２４０を介してサーバ２００に要求を送信することができる。

対応するコンピュータ２５０上には、仮想ブロックデバイス用のブロックデバイスドライバが既にインストールされている。このようにして、仮想ブロックデバイスはコンピュータ２５０のオペレーティングシステムのファイルシステムにマウントされることができる。ブロックデバイスドライバ（例えば、ドライバ４２１）のインストール及び仮想デバイスのマウントは、既に図３及び図４に関連して更に詳細に説明されており、これは同じ手法でここで行われることができる。それがまだ行われていない場合、コンピュータ２５０は、例えばステップ６２０に従って送信されたアプリケーションに関連付けられるアプリケーションの実行のためのメタデータ情報を受信することができる（ステップ７１０）。同様に、コンピュータ２５０も、元のイメージの再配列イメージへのマッピングを可能にする格納されているマッピング情報を、メタデータ情報と共に（又はこれとは別に）受信する（ステップ７１１）。

コンピュータ２５０は、好ましくは、データパーツに必要な記憶スペースに関する情報（例えば、サイズ）も受信する。

この情報（例えば、経路情報及びファイル情報）の助けを借りて、必要なサイズを有するイメージのマウントが行われることができ、アプリケーションは（一例として実行可能ファイルを用いて）実行されることができる（ステップ７２０）。これは、アプリケーションのデータブロックが対応するコンピュータ２５０のデータメモリにローカルに未だ格納されていない場合でさえも、情報が実行可能ファイルを介して既に利用可能であるので、適用される。

アプリケーションは、今その実行のためにデータブロックを必要とする。これらは、一例としてブロックデバイスドライバ（例えば、ドライバ４２１）からファイルシステム（例えば、ファイルシステム４３１）によって要求される（ステップ７３０）。

必要なデータブロックがデータメモリ内で利用可能でない場合、デバイスドライバ・イベントキューの処理は一時中断される（任意選択的ステップ７４０）。データブロックが既に利用可能である場合、処理はステップ７８０（下記参照）から継続することができる。しかしながら、一時中断が起きる場合、アプリケーションの実行に必要なデータブロックは最初にサーバ２００から受信されることができる（ステップ７５０）。

データブロックは、少なくとも一部の領域において予期される必要な順序に基づく順序で、対応するコンピュータ２５０のローカルデータメモリ（例えば、ハードディスク）に直接格納される（ステップ７６０）。それは、データブロックが再配列されたイメージによりサーバ２００からその順序で転送されるからである。

データブロックがローカルで利用可能である場合、デバイスドライバのイベントキューの処理は再開されることができる（任意選択的ステップ７７０）。

要求されたデータブロックが受信されたイメージ内のデータブロックのブロック順序の変更により変更されているので、デバイスドライバは、アプリケーションの実行に必要なデータブロックを要求するために使われるアドレッシングを、データメモリに格納されているデータブロックの順序にマッピングする（ステップ７８０）。これは、元のイメージを再配列されたイメージにマッピングすることを可能にする、サーバ２００によって以前に格納されたマッピング情報がコンピュータ２５０に転送されているので、可能である。

従って、アプリケーションの実行に必要なデータブロックは、ブロックデバイスドライバによってコンピュータ２５０のデータメモリから提供されることができる。データブロックは、少なくとも一部の領域において予期される必要な順序に基づく順序でデータメモリに既に格納されているので、その提供は極めて効率的に行われることができる（ステップ７９０）。具体的には、アプリケーションの開始は、このようにして、アプリケーションがサーバ２００から未だダウンロードされる必要があるか又は既にコンピュータ２５０に格納されているかどうかとは独立に加速されることができる。

Claims (23)

1. 少なくとも１つのデバイスによって遂行されるアプリケーションを実行する方法であって、前記アプリケーションは、アプリケーションのプログラムフローがアプリケーションのユーザによって少なくとも部分的に影響を受ける対話型アプリケーションであり、
   前記方法は、
   − データメモリから前記アプリケーションの前記実行に必要なデータパーツを提供するステップ（７９０）を備え、前記データパーツは少なくとも一部の領域において予期される必要な経時的順序に基づく物理的順序で前記データメモリに格納され、前記予期される必要な経時的順序は、少なくとも前記アプリケーションのそれぞれの実行中に取得された多数の必要な経時的順序の組み合わせに基づく、
   方法。
2. 前記方法は、
   − 前記アプリケーションの実行に必要な前記データパーツを要求するステップ（７３０）、
   を更に備える、請求項１に記載の方法。
3. 前記方法は、
   − 前記アプリケーションの実行に必要な前記データパーツの前記要求するステップに使用されるアドレッシングを、前記データメモリに格納されている前記データパーツの前記順序にマッピングするステップ（７８０）、
   を更に備える、請求項２に記載の方法。
4. 使用される前記アドレッシングの前記マッピングはファイルシステム（４３１、４３２）層（４３０）の下で行われる、請求項３に記載の方法。
5. 前記方法は、
   − 前記アプリケーションの実行に必要な前記データパーツを受信するステップ（７５０）、
   を更に備える、請求項１〜４の何れか一項に記載の方法。
6. 前記方法は、
   − 少なくとも一部の領域において予期される必要な順序に基づく前記順序で前記データパーツをデータメモリに格納するステップ（７６０）、
   を更に備える、請求項１〜４の何れか一項に記載の方法。
7. 前記データパーツはデータブロック及び／又は連続のデータブロックであり、前記順序はブロック順序である、請求項１〜６の何れか一項に記載の方法。
8. 前記データパーツはブロックデバイス、具体的には仮想ブロックデバイス、に格納される、請求項１〜７の何れか一項に記載の方法。
9. 前記データメモリから前記アプリケーションの実行に必要な前記データパーツを前記提供するステップのために、デバイスドライバ（４２１、４２２）、好ましくはブロックデバイスドライバ、が使用される、請求項１〜８の何れか一項に記載の方法。
10. 前記方法は、
    − 特に、前記必要なデータパーツが前記データメモリ内で利用可能でない場合、イベントキューの処理を一時中断するステップ（７４０）と、
    − 前記イベントキューの前記処理を再開するステップ（７７０）と、
    を更に備える、請求項１〜９の何れか一項に記載の方法。
11. 前記アプリケーションの開始に関連するデータパーツに少なくとも関する前記データパーツは、少なくとも一部の領域において予期される必要な順序に基づく順序で前記データメモリに格納される、請求項１〜１０の何れか一項に記載の方法。
12. 前記方法は、
    − 前記アプリケーションの実行のために前記アプリケーションに関連付けられるメタデータ情報を使用するステップ、
    を更に備える、請求項１〜１１の何れか一項に記載の方法。
13. 少なくとも１つのデバイスによって実施される、具体的には請求項１〜１２の何れか一項に記載の方法で使用される、データパーツを送信する方法であって、
    − アプリケーションの実行に必要なデータパーツを送信するステップ（６３０）であって、前記アプリケーションは、アプリケーションのプログラムフローがアプリケーションのユーザによって少なくとも部分的に影響を受ける対話型アプリケーションであり、前記データパーツは少なくとも一部の領域において予期される必要な経時的順序に基づく物理的順序でデータメモリに格納され、前記予期される必要な経時的順序は、少なくとも前記アプリケーションのそれぞれの実行中に取得された多数の必要な経時的順序の組み合わせに基づくステップを備える、
    方法。
14. 前記データパーツは少なくとも部分的に前記格納された順序で送信される、請求項１３に記載の方法。
15. 前記方法は、
    − 前記アプリケーションの実行に必要な前記データパーツの少なくとも一部を送信する要求を受信するステップ（６１０）、
    を更に備える、請求項１３または１４に記載の方法。
16. 前記方法は、
    − 前記アプリケーションの実行のために前記アプリケーションに関連付けられるメタデータ情報を送信するステップ（６３０）、
    を更に備える、請求項１３〜１５の何れか一項に記載の方法。
17. 少なくとも１つのデバイスによって実施されるデータパーツを格納する方法であって、
    − アプリケーションの実行に必要な前記データパーツの多数の取得された必要な経時的順序を受信するステップ（５１０）であって、前記アプリケーションは、アプリケーションのプログラムフローがアプリケーションのユーザによって少なくとも部分的に影響を受ける対話型アプリケーションであり、前記アプリケーションのそれぞれの実行に必要な前記データパーツの前記多数の取得された必要な経時的順序は、前記アプリケーションのそれぞれの実行中の前記必要なデータパーツに対する読み出し動作に関するログ情報を備えるステップと、
    − 前記多数の取得された必要な経時的順序の組み合わせに少なくとも基づいて、予期される必要な経時的順序を決定するステップ（５２０）と、
    − 少なくとも一部の領域において前記予期される必要な経時的順序に基づく物理的順序で前記必要なデータパーツをデータメモリに格納するステップ（５３０）と、
    を備える方法。
18. 前記方法は、以下のステップ、
    − デバイスドライバ、好ましくはブロックデバイスドライバ、をインストールするステップ（３１０）、
    − イメージを生成するステップ（３２０）、
    − デバイスドライバを介して、具体的にはインストールされた前記デバイスドライバを介して、デバイスをマウントするステップ（３３０）、
    − 前記アプリケーションを、特に、生成された前記イメージ上にインストールするステップ（３４０）、
    − 前記アプリケーションの前記実行のために前記アプリケーションに関連付けられるメタデータ情報を決定するステップ（３５０）、
    − 前記アプリケーションを実行するステップ（３６０）、
    − アプリケーションの前記実行に必要な前記データパーツの前記必要な順序を取得するステップ（３７０）、
    のうちの１つ又は複数を更に備える、請求項１７に記載の方法。
19. 前記ログ情報は前記それぞれの必要なデータパーツの曖昧でない識別を可能にする、請求項１７または１８に記載の方法。
20. 前記ログ情報はまた、以下の情報、
    − 時間情報、
    − アプリケーション特有のイベント、
    − ユーザ特有の情報、
    のうちの１つ又は複数を備える、請求項１７〜１９の何れか一項に記載の方法。
21. 取得された必要な順序のうちの連続セクションの場合には、前記連続セクションは短縮される、請求項１７〜２０の何れか一項に記載の方法。
22. 請求項１〜２１の何れか一項に記載の方法を実施及び／又は制御する適切な手段として構成されるか又は前記手段を備えるデバイス。
23. コンピュータプログラムがプロセッサ上で動作する場合、前記プロセッサが請求項１〜２１の何れか一項に記載の方法を実施及び／又は制御することを可能にするプログラム命令を備えるコンピュータプログラム。

Images