(57)【要約】効果的な仮想アプリケーションのアップデートが可能にされる。仮想アプリケーションの旧バージョンは、仮想アプリケーションの新バージョンと比較され、その機能としてアップデートされることが可能である。旧バージョンから新バージョンに変更されないファイルを、新バージョンから旧バージョンにハードリンクすることができる。変更されるファイルについては、ファイルのマッチング部分を旧バージョンから新バージョンにコピーすることができ、また、無変更のままの部分を別の情報源から取得することができる。
2014502396.tif 000002
【特許請求の範囲】
【請求項１】
仮想アプリケーションをアップデートする方法であって、
メモリ内に記憶されるコンピュータ実行可能命令を実行するように構成される少なくとも１つのプロセッサを使用して、
仮想アプリケーションのロードされた第１のバージョンと、前記仮想アプリケーションの第２のバージョンのメタデータとを比較する動作と、
前記第１のバージョンのファイルへのハードリンクを作成する動作であって、前記ファイルは、前記第１のバージョンから前記第２のバージョンに変更されない、作成する動作と
を実行するステップ
を含むことを特徴とする方法。
【請求項２】
前記第１のバージョンから前記第２のバージョンに変更される場合に、前記ファイルの少なくとも一部の取得を開始するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ファイルの前記少なくとも一部の取得をプロキシから開始することを特徴とする請求項２に記載の方法。
【請求項４】
前記ファイル全体の、情報源からの取得を開始するステップをさらに含み、前記ファイルは、前記第１のバージョンおよび前記第２のバージョンに対して異なることを特徴とする請求項１に記載の方法。
【請求項５】
変更量が閾値を満たすまたは超える時に、開始することを特徴とする請求項１に記載の方法。
【請求項６】
仮想アプリケーションのアップデートを円滑にするシステムであって、
メモリに接続されるプロセッサであって、
アプリケーションパッケージのロードされた旧バージョンと、前記アプリケーションパッケージの新バージョンとを比較するように構成される第１のコンポーネントと、
無変更のファイルの新バージョンと旧バージョンとの間のハードリンクを作成するように構成される第２のコンポーネントと、
変更されたファイルの少なくとも一部の、情報源からの取得を開始するように構成される第３のコンポーネントと
を含む、前記メモリに記憶されるコンピュータ実行可能コンポーネントを実行するように構成されるプロセッサ
を備えたことを特徴とするシステム。
【請求項７】
前記変更されたファイルの一部を、前記アプリケーションパッケージの前記旧バージョンからの対応するファイルからコピーするように構成される第４のコンポーネントをさらに含むことを特徴とする請求項６に記載のシステム。
【請求項８】
前記第３のコンポーネントが、前記新バージョンに対して一意的である新しいファイルの、前記情報源からの取得を開始するように構成されることを特徴とする請求項６に記載のシステム。
【請求項９】
前記第３のコンポーネントが、変更の程度に基づき、変更されたファイル全体の、前記情報源からの取得を開始するように構成されることを特徴とする請求項６に記載のシステム。
【請求項１０】
前記情報源がプロキシであることを特徴とする請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、効果的な仮想アプリケーションのアップデートに関する。
【背景技術】
【０００２】
アプリケーションの仮想化は、ソフトウェアアプリケーションをオペレーティングシステムから分離することを可能にする技術の結集である。従来の感覚でコンピュータに直接インストールするのではなく、サーバとしてのコンピュータ上に仮想アプリケーションが配置される。それにもかかわらず、仮想アプリケーションは、コンピュータ上にインストールされたかのように実行される。アプリケーションは、ある意味、インストールされてコンピュータのオペレーティングシステムと直接対話していると、考え違いされている。これは、アプリケーションのファイルおよび他の動作を傍受し、かつ、動作を仮想化された場所にリダイレクトする、仮想環境または仮想層においてアプリケーションをカプセル化することにより達成することができる。
【０００３】
アプリケーションの仮想化にはいくつかの利点がある。特に、アプリケーションは、仮想環境により少なくともある程度お互いから、また実行コンピュータから分離される。従って、他の互換性の無いまたは相反するアプリケーションを含む、複数のアプリケーションを同時に実行させることが可能である。加えて、アプリケーションは、アプリケーションが設計された環境以外の環境において実行させることができる。さらに、分離により、他のアプリケーションおよび下層にあるオペレーティングシステムが分かりにくい、すなわち不完全なコードから保護される。
【０００４】
仮想化アプリケーションには多数の部分が含まれる。第１の部分は、アプリケーション資産すなわちリソースが存在するパッケージファイルである。このパッケージには、アプリケーションをコンピュータ上で実行させるために必要なデータおよびメタデータが含まれる。これらのリソースには、ファイルおよびディレクトリ構造が含まれるがこれらに限定されない。実行時には、仮想アプリケーションには、コンピュータ上で実行されるこれらのリソース、すなわち名前空間が含まれる。仮想化を通して、リソース名前空間およびネイティブ名前空間が一緒にまとめられ、アプリケーションがリソースを発見できるようにすることが可能である。
【発明の概要】
【０００５】
以下では、開示される主題のいくつかの態様について基本的な理解を提供するために、簡素化された要約を示す。この要約は、広範囲な概要ではない。本発明の主要／重要な要素を確認することまたは請求される主題の範囲を明確にすることは、意図されない。その唯一の目的は、後に示されるさらに詳細な記載の前置きとして、いくつかの概念を簡素化された形式で示すことである。
【０００６】
簡単に説明すると、本開示は、概して効果的な仮想アプリケーションのアップデートに関連する。アプリケーションの旧バージョンと同じアプリケーションの新バージョンのファイル間で比較を行うことができる。新しいファイルが、対応する古いファイルに対して無変更である場合、複製のコピーを作成するのではなく、新しいファイルを古いファイルに関連付けしてハードリンクを作成することができる。ファイルが変更されている場合、新しいファイルの無変更の部分を古いファイルからコピーすることができ、かつ、サーバ、プロキシ、クライアント、および／またはクライアントデータストアなどの情報源から変更部分の取得を開始することが可能である。
【０００７】
前述および関連する目的を達成するため、請求される主題の特定の例示的態様が以下の記載および添付の図面と関連して本明細書において記載される。これらの態様は、主題を実践することができる種々の方法を示し、その全ては請求される主題の範囲内にあることが意図される。他の利点および新規の特徴を、図面と併せて考察されるときに以下の詳細な説明から明らかにすることが可能である。
【図面の簡単な説明】
【０００８】
【図１】仮想アプリケーションのアップデートを円滑にするシステムのブロック図である。
【図２】例示のアプリケーションパッケージのブロック図である。
【図３】代表的なアップデートコンポーネントのブロック図である。
【図４】代表的なパッケージビルドコンポーネントのブロック図である。
【図５】仮想アプリケーションのアップデートを円滑にするシステムのブロック図である。
【図６】仮想アプリケーションのアップデートを円滑にするシステムのブロック図である。
【図７】仮想アプリケーションをアップデートする方法のフローチャート図である。
【図８】アプリケーションのアップデートを円滑にするための前処理の方法のフローチャート図である。
【図９】仮想アプリケーションをアップデートする方法のフローチャート図である。
【図１０】仮想アプリケーションをアップデートする方法のフローチャート図である。
【図１１】変更されたデータを情報源から取得する方法のフローチャート図である。
【図１２】主題開示の態様のための適切な動作環境を例示する概略ブロック図である。
【発明を実施するための形態】
【０００９】
以下の詳細は、概して仮想アプリケーションの効果的なアップデート（例えば、アップデート／アップグレード）を対象とする。アプリケーションの新バージョンは、旧バージョンと連動して作成可能である。例えば、ブロックマップおよび中央ディレクトリを利用して旧バージョンと新バージョンの比較に基づき、種々の動作を行うことができる。特に、新しいファイルが、対応する古いファイルに対して無変更のままである場合、ファイルの新バージョンから旧バージョンにハードリンクを作成できる。その結果、新バージョンについてファイルを複製する必要がないため、ディスク空き容量が保たれる。さらに、アップデートの中断または失敗が旧バージョンに影響せず、新バージョンを旧バージョンと同時に実行できる。
【００１０】
ファイルが変更される場合、無変更データの部分（別名、ブロック）を旧バージョンからコピー可能であり、残りの部分をサーバ等の別の情報源から取得可能である。従って、ファイルの変更部分のみがダウンロードされるため、ネットワーク帯域幅が保存される。また、中でもプロキシ、複数のクライアント、および複数のクライアントデータストアの利用を含む保存されたネットワーク帯域幅に、さらなる最適化を使用することが可能である。
【００１１】
ここで、本開示の種々の態様が、添付の図面を参照してさらに詳細に記載されるが、全体を通して同様の数字は同様または対応する要素を参照する。しかし、図面およびそれに関する詳細な説明が、請求される主題を開示される特定の形式に限定することは意図されない旨を理解すべきである。むしろ、請求される主題の精神および範囲の中に入る全ての変形、等価物、代替を包含することが意図される。
【００１２】
まず図１を参照すると、仮想アプリケーションのアップデートを円滑にするシステム１００が例示される。システム１００は、クライアント−サーバパラダイムに従って動作するように構成される。クライアント１１０およびサーバ１３０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピュータ、コンピュータ装置）とすることができる。さらに、クライアント１１０は、クライアントデータストア１２０に接続することができ、サーバはサーバデータストア１４０に接続することができる。また、クライアント１１０とサーバ１３０は、インターネットなどのワイドエリアネットワークを含むがこれに限定されない通信ネットワークを介して通信可能である。
【００１３】
システム１００はアプリケーションの仮想化を可能にすることができ、それにおいて、通信ネットワーク１５０を介してサーバ１３０およびサーバデータストア１４０からアプリケーションをストリーミングすることにより、クライアント１１０および関連するクライアントデータストア１２０上に、アプリケーションがインストールされるのではなくロードされる。ここで示すように、ストリームコンポーネント１１２が、アプリケーションをサーバ１３０に要求し続いてサーバ１３０から受け取ることにより、そのようなアプリケーションストリーミングを達成するように構成される。
【００１４】
例えば、サーバデータストア１４０には、アプリケーションの実行ファイルおよびメタデータを含むＶ１パッケージ１２２が含まれる。ストリームコンポーネント１１２は、サーバ１３０にＶ１パッケージ１２２を要求することができる。それに応答して、サーバ１３０は、Ｖ１パッケージ１２２をサーバデータストア１４０から回収し、通信ネットワーク１５０を介して送信してクライアント１１０に相対するストリームコンポーネント１１２にＶ１パッケージ１２２を返すことができる。次に、ストリームコンポーネント１１２は、ローカルキャッシュに相当し得るクライアントデータストア１２０にＶ１パッケージ１２２をロードすることができる。さらに、ストリーミングの処理のため、パッケージ全体が到着するまで、パッケージの一部を受信しながらロードすることができる。
【００１５】
図２を簡単に検討すると、例示のアプリケーションパッケージ２００が示される。例示のように、アプリケーションパッケージには、ヘッダ２１０、ファイルデータ２２０、ブロックマップ２３０、および中央ディレクトリ２４０が含まれる。ヘッダ２１０は、アプリケーションパッケージに関する一般情報（例えば、サイズ、オフセット．．．）を提供する。ファイルデータ２２０は、アプリケーションの機能を実装する複数の実行ファイルおよび非実行ファイルに相当する。ブロックマップ２３０は、クライアントがローカルファイル内の１つのオフセットをパッケージのオフセットに変換するための方法を提供するメタデータファイルである。さらに、ブロックマップ２３０は、改ざんを防ぎ、かつ、ブロック間の差を計算可能にするブロックレベルのハッシュを提供する。中央ディレクトリ２４０には、ファイルとサブディレクトリとに関するメタデータが含まれる。例えば、アプリケーションに、ファイル「ｆｏｏ．ｅｘｅ」と、「ｂａｒ」内のファイル「ａｌｐｈａ．ｄｌｌ」および「ｂｅｔａ．ｄｌｌ」を有するサブディレクトリ「ｂａｒ」とが含まれていた場合、中央ディレクトリ２４０には、ローカルシステム上にその階層（例えば、「ｆｏｏ．ｅｘｅ」というファイル、２つのファイル「ａｌｐｈａ．ｄｌｌ」および「ｂｅｔａ．ｄｌｌ」を含んでいたディレクトリ「ｂａｒ」）を再現するために必要な情報が含まれる。
【００１６】
図１に戻ると、先に述べたように、ストリームコンポーネント１１２はサーバ１３０に接続し、Ｖ１パッケージ１２２をダウンロードすることができる。さらに詳細には、中央ディレクトリは、ダウンロードされて、パッケージ内にローカルバージョンのファイルとディレクトリを作成するために利用されることが可能である。そして、ストリームコンポーネント１１２は、全てのファイルをクライアントデータストア１２０のローカルシステム上に常駐させることができる。これは、ローカルファイルシステム内の場所（例えば、ファイル「ｆｏｏ．ｄｌｌ」、オフセット「０ｘ４００」）からパッケージ内の範囲（例えば、「ｓａｍｐｌｅ．ａｐｐｖ」、オフセット「０ｘ６３０００」）に移行させるブロックマップを使用することにより、達成させることができる。
【００１７】
ストリームコンポーネント１１２にはまた、アプリケーションの旧バージョンをアプリケーションの新バージョンにアップデートするように構成されるアップデートコンポーネント１１４が含まれる。今までのアップデートの解決法は、アンインストールと再インストール、およびパッチングという２つのカテゴリの内の１つに含まれる。アンインストールと再インストールごとに、全てのファイルを含むアプリケーションの以前のバージョンはシステムから削除され、新バージョンがダウンロードかつインストールされる。しかしここで、アプリケーション内のファイルの１５％だけが変更された場合、全てのアプリケーションファイルがダウンロードされる。これはネットワーク帯域幅を非効率的に使用することであり、また、アプリケーションがこの時間使用できないため中断時間を増加させる。パッチングは、２つの既知のバージョンのファイル間の差に基づく、ビルドラボにおけるパッチの計算を伴う。パッチはダウンロードされファイルのトップに適用される。これには、変更されたデータ用のネットワーク帯域幅が必要であるだけだが、ビルドラボが以前のビルドのライブラリを維持して差を生成することが必要であり、また、パッチが順次適用される必要がある（例えば、パッチ１、パッチ２、パッチ３．．．）。
【００１８】
アップデートコンポーネント１１４は、より効果的なアプローチを仮想アプリケーションのアップデートに提供することができる。さらに具体的には、アップデートコンポーネント１１４は、新バージョンおよび旧バージョンの無変更のファイルをハードリンクすることにより格納空間を保存すること、かつ、ネットワーク帯域幅の効果的な使用を、とりわけファイル変更の要求に制限することにさせることができる。さらに、アプリケーションの旧バージョンと新バージョンの両方が共存可能であり、アップデートは順次実行される必要がない。
【００１９】
図３は、代表的なアップデートコンポーネント１１４をさらに詳細に例示する。アップデートコンポーネント１１４には、前処理コンポーネント３１０およびパッケージビルドコンポーネント３２０が含まれる。前処理コンポーネント３１０は、１つまたは複数の前処理動作を実行してアプリケーションのアップデートを円滑にするように構成される。制限ではなく例として、前処理コンポーネント３１０は、アプリケーションパッケージの中央ディレクトリおよびブロックマップを利用して新パッケージのローカルなスパースコピーを作成することができ、スパースコピーには、メタデータ（例えば、ファイル名、サイズ．．．）が含まれるが内容がないスパースファイルが含まれる。パッケージビルドコンポーネント３２０は、スパースパッケージを利用してローカルパッケージをビルドすることができる。例えば、パッケージビルドコンポーネント３２０は、ファイルを別のファイルにリンクすること、ファイルまたはファイルの一部をコピーすること、および／または新しいファイルを注入することができる。
【００２０】
図４を検討すると、代表的なパッケージビルドコンポーネント３２０が例示され、比較コンポーネント４１０、ハードリンクコンポーネント４２０、コピーコンポーネント４３０、およびストリーム開始コンポーネント４４０が含まれる。比較コンポーネント４１０は、旧パッケージおよび新パッケージを分析すること、２つの間の差および／または類似を識別することができる。換言すれば、比較コンポーネント４１０は、アプリケーションの第１のバージョンに関連するファイルのリスト、およびアプリケーションの第２のバージョンに関連するファイルのリストを調べて変更を判定することができる。一実施形態によると、ファイルまたはファイルの一部に対するアプリケーションのハッシュ機能（別名、ハッシュコード、ハッシュ）の結果が、比較コンポーネント４１０により利用されて差を識別することができる。
【００２１】
比較コンポーネント４１０が、新しいファイルは同じファイルの旧バージョンに対して無変更であると判定すると、ファイルの旧バージョンと新バージョンの間のハードリンクを作成するように構成されるハードリンクコンポーネント４２０を使用することができる。言い方を変えれば、同じままであるファイルの別のコピーを生成するのではなく、エントリを新バージョンのパッケージ内に挿入させることができ、旧パッケージによって常駐にされる同一のファイルにファイルを関連付ける。そのようなハードリンクは、ファイルの複製コピーを格納するのではなく、リンクを使用して元のファイルの場所を参照することにより、少なくとも格納空間を保存する。これに限定されないが、ハードリンクは、ディスクの記憶装置のコストが高いリモートデスクトップおよび仮想デスクトップでのアプリケーション配置について特に有用であり得る。
【００２２】
ファイルが変更された場合に、比較コンポーネント４１０により判定される時は、コピーコンポーネント４３０およびストリーム開始コンポーネント４４０が利用可能である。コピーコンポーネント４３０は、マッチングブロック、すなわち換言すれば、ファイルの無変換の部分を、旧バージョンから新バージョンにコピーするように構成される。パッケージブロックマップが提供するハッシュを利用して、ファイルのマッチングブロックおよび非マッチングブロックを識別することが可能である。変更部分については、ストリーム開始コンポーネント４４０が、サーバなどの情報源からのそのような部分の取得を開始することができる。コピーされた部分および取得された部分は共にファイルを含む。さらに、新バージョンに旧バージョンの一部ではない新しいファイルが含まれる場合、新しいファイルの全体の取得を、ストリーム開始コンポーネント４４０により開始することができる。このように、変更されたファイルおよび旧バージョンの一部ではない新しいファイルの部分にダウンロードを限定することにより、ネットワーク帯域幅が保存される。
【００２３】
空間および帯域幅を保存することに加えて、パッケージビルドコンポーネント３２０は、旧バージョンと新バージョンの同時実行、およびアップデート中の失敗の許容差を許容することができる。典型的なアップデートスキームは、ファイルに対する削除またはコピーを伴う。従って、アップデート中にエラーがある場合、旧バージョンを、いくつかのファイルが削除またはインストールされた不完全な状態のままにすることができる（例えば、部分的なアップグレード）。ファイルの一部のハードリンクおよびコピーを利用することにより、中断または失敗したアップグレードは元のアプリケーションまたは旧アプリケーションバージョンに影響を与えない。同様に、アプリケーションの旧バージョンおよび新バージョンは共存可能であり、これは、例えば、特定のコンピュータのユーザが２人おり、第１のユーザがアプリケーションの第１のバージョンを、第２のユーザが同じアプリケーションの第２のバージョンを使用したい場合に有用となり得る。
【００２４】
図１に戻ると、第２のバージョンのアプリケーション、すなわち、Ｖ２パッケージ１２４、が利用可能である時、アップデートコンポーネント１１４が、サーバ１３０からＶ２中央ディレクトリおよびブロックマップのダウンロードを開始することができる。続いて、中央ディレクトリは、コンテントディレクトリ内にファイル用のスパースファイルおよびエントリ用のディレクトリを作成するローカルファイルシステムに、拡張可能である。そして、アップデートコンポーネント１１４は古いファイルおよび新しいファイルのリストを調べることができ、Ｖ２パッケージ１２４内にファイルが存在する場合、アップデートコンポーネント１１４は、ファイルがＶ１パッケージ１２２に対して変更されているかどうかを判定する。この判定は、古いファイルと新しいファイルの間のブロックのハッシュを比較することにより行うことが出可能である。アップデートされたバージョンにおいて変更されていないファイルは、例えば、矢印で示すようにＶ１パッケージの場所からＶ２パッケージの場所に、アップデートコンポーネント１１４によりハードリンクさせることができる。ファイルが変更されている場合、アップデートコンポーネント１１４は、ファイルの旧バージョンからファイルの新バージョンにマッチングブロックをコピーし、変更部分をダウンロードすることができる。同様に、新しいファイルがアップデートされたバージョンには存在するが元のバージョンには存在しない場合、そのファイルはダウンロード可能である。
【００２５】
一実施形態によると、２つのバージョンのブロックマップおよび中央ディレクトリを利用して、１つの任意のバージョンから別のバージョンに移行させることができる。例えば、あるユーザがバージョン「１」を持っているが１ヶ月間オフラインにしている状況を考える。この間、アプリケーションベンダは、多数のアップグレードを発行、または現バージョンが今度はバージョン「４」になるように修正する。ユーザはバージョン「２」と「３」をパッケージに適用する必要がない。それどころか、アップデートコンポーネント１１４は、バージョン「４」に関連するブロックマップを取得し、バージョン「１」とバージョン「４」の差を計算し、それらの変更を適用することができる。
【００２６】
図５は、一実施形態による仮想アプリケーションのアップデートを円滑にするシステム５００を例示する。システム５５０には、２つまたはそれ以上のクライアント１１０を含むことができ、そのそれぞれがストリームコンポーネント１１２およびアップデートコンポーネント１１４を含む。本明細書において上述したように、ファイルがアプリケーションの旧バージョンからアプリケーションの新バージョンに変更される場合、または、新しいファイルが新バージョンにより導入される場合、そのような変更されたデータの少なくとも一部をローカルシステムの外部から取得することが可能である。有利には、ダウンロードを変更に限定することによりネットワーク帯域幅を保存することが可能である。しかし、データ取得は、プロキシコンポーネント５１０を利用することによりさらに最適化が可能である。
【００２７】
プロキシコンポーネント５１０は、ローカルまたはリモートのプロキシまたは中間段階であり、とりわけ、ファイルまたはその一部を格納するためのキャッシュ５１２を有する。複数のクライアント１１０は、プロキシコンポーネント５１０と対話し、変更されたデータを入手することができる。要求したデータが以前にサーバから回収されてキャッシュ５１２内に存在する場合、データは要求クライアントに返されることが可能である。あるいは、データはサーバから回収され、次回の使用のためにキャッシュ５１２内に格納されてよい。このように、アップデートされたアプリケーションパッケージは、各クライアントにより別々にダウンロードされるのとは対照的に、プロキシコンポーネント５１０により一度ダウンロードされ、複数のクライアント１１０により利用されることが可能である。
【００２８】
さらに、クライアント１１０が別のクライアント１１０と通信可能に接続される場合、アップグレード情報が交換されてよい。例えば、第１のクライアント上でファイルの取得が必要であると判定されると、第１のクライアントはファイルを第２のクライアントに要求可能であり、第２のクライアントはファイルのコピーを返すことができる。その結果、ネットワーク帯域幅は、クライアントとクライアントの通信（例えば、有線、無線、ブルートゥース．．．．）を経由してさらに保存され得る。同様に、サーバが利用可能でない場合でも、アップグレードを実行させることができる。
【００２９】
図６は、一実施形態による仮想アプリケーションのアップデートを円滑にするシステム６００を例示する。システムには、上述のようにクライアント１１０、ストリームコンポーネント１１２、およびアップデートコンポーネント１１４が含まれる。加えて、クライアント１１０は、２つのクライアントデータストア、すなわち第１のクライアントデータストア６２０および第２のクライアントデータストア６３０を含み、および／またはこれらと対話する。いくつかのシナリオにおいて、クライアント１１０は、複数である別々のユーザをサポートし、各ユーザが特定のクライアントデータストアを有するようにすることができる。アップデートコンポーネント１１４は、これらの別々のストアを利用して、中でも、変更されたデータを取得することができる。例えば、第１のクライアントデータストア６２０について、Ｖ１パッケージ１２２がＶ２パッケージ１２４にアップデートされる場合、第２のクライアントデータストア６３０がクエリされかつ利用され、可能な場合は、変更されたデータ、または旧バージョンのＶ１パッケージ１２２について含まれない新しいファイルを取得することができる。もちろん、別のクライアントデータストアが利用可能でない場合、または必要なデータを有していない場合、アップデートコンポーネント１１４は、他の情報源の中でもサーバ、プロキシ、または他のクライアントからデータの取得を求めることができる。
【００３０】
上述のように、アップデートコンポーネント１１４は、サーバ、プロキシ、クライアント、またはクライアントデータストアなどの種々の情報源からデータを取得可能である。もちろん、この情報源のリストは包括的ではない。さらに、アップデートコンポーネント１１４は、１つの情報源を利用して他を除外する必要はない。事実、複数の情報源を利用して、同じまたは異なるファイルについてデータの取得が可能である。加えて、データは、２つまたはそれ以上の情報源に同時に要求してよく、その場合データは、第１の情報源から使用されて要求に応答する。加えて、どの１つまたは複数の情報源が使用されるべきかについて、利用可能な情報源、予測応答時間、経済的コストおよび負荷を含むがこれらに限定されない任意の数の要因に基づき判定を行うことが可能である。
【００３１】
またさらに、アップデートコンポーネント１１４は、どの情報源のデータを要求するのかだけでなく、要求されるデータの量についても判定することができる。一実施形態によると、アップデートコンポーネント１１４は、以前のバージョンの一部を形成していなかった変更されたデータおよび新しいファイルに、要求を限定することが可能である。しかし、アップデートコンポーネント１１４は、もっと多くのデータを回収するように構成されてよい。例えば、変更量に対して、閾値を事前に準備、判定および推測を行うことができる。例えば、ファイルの５０％以上に影響を与える変更がファイルに含まれる場合、変更された部分だけでなくファイル全体を要求することができる。とりわけクライアントおよびネットワーク負荷、ならびにネットワークの速度およびコストを含む多数の要因に基づき、閾値を調整可能である。例として、ネットワーク使用に関連するデータ単位（例えば、キロバイト、メガバイト．．．）の経済的コストがかかる場合、ファイル全体を求める要求がなされる前は、ファイルの変化率は、１００％でない場合、１００％に近似する必要がないことを示す高い値に、閾値を設定することができる。
【００３２】
前述のシステム、アーキテクチャ、環境などは、いくつかのコンポーネント間の相互作用について記載された。そのようなシステムおよびコンポーネントには、それらのコンポーネントまたはその中に特定されるサブコンポーネント、特定のコンポーネントまたはサブコンポーネントの内のいくつか、および／または、追加のコンポーネントが含まれてよいことは理解すべきである。サブコンポーネントはまた、親コンポーネント内に含まれるのではなく他のコンポーネントに対して通信可能に接続されるコンポーネントとして実装されてもよい。さらに、１つまたは複数のコンポーネントおよび／またはサブコンポーネントは、単一のコンポーネントに組み込まれて集約機能を提供することができる。システム、コンポーネントおよび／またはサブコンポーネント間の通信は、プッシュモデルおよび／またはプルモデルのどちらかに従って達成可能である。コンポーネントは、簡潔にする目的で本明細書に詳細には記載しないが、当業者には既知の１つまたは複数の他のコンポーネントと対話してもよい。
【００３３】
さらに、上記に開示されるシステムおよび以下の方法の種々の一部は、人口知能、機械学習もしくは知識、または、ルールベースのコンポーネント、サブコンポーネント、プロセス、手段、方法論、もしくは機構（例えば、サポートベクタマシン、ニューラルネットワーク、エキスパートシステム、ベイジアン信念ネットワーク、ファジー論理、データ融合エンジン、分類子．．．）を含むことまたはこれらから成ることが可能である。そのようなコンポーネントにより、とりわけ、特定の機構またはそれにより実行されるプロセスを自動化し、システムおよび方法の一部をより適応力があり、また効果的かつ知的なものにすることが可能である。制限ではなく例として、アップデートコンポーネント１１４は、そのような機構を利用して、回収するデータ量およびどの１つまたは複数の情報源にデータを要求するかを判定または推測することが可能である。
【００３４】
上記に記載した例示のシステムを考慮すると、開示される主題に従って実装されてよい方法論は、図７から１１のフローチャートを参照することでよりよく理解されるであろう。説明を簡単にする目的で、方法論が一連のブロックとして示され記載されるが、請求される主題がブロックの順番によって制限されず、いくつかのブロックが本明細書に示され記載されるものとは異なる順番で、および／または、他のブロックと同時に発生してよいことは理解かつ認識されるべきである。また、以下に記載される方法を実装するために、例示される全てのブロックが必要とされるわけではない。
【００３５】
図７を参照すると、仮想アプリケーションをアップデートする方法７００が示される。参照番号７１０にて、アプリケーションの第１のバージョンとアプリケーションの第２のバージョンとの差が判定される。例えば、ファイルブロックに関連するハッシュコードを利用して、ファイルの一部、またファイルそのものが異なるかどうかについて判定することができる。番号７２０にて、第１および第２のバージョンから同一のファイルに対するハードリンクを作成することができる。換言すれば、第１のバージョンから第２のバージョンに変更されないファイルは、第２のバージョン用に複製コピーを作成するのではなく、第１のバージョンのファイルの場所にリンクされる。参照番号７３０にて、サーバ、プロキシ、クライアント、および／またはクライアントデータストアを含むがこれに限定されない１つまたは複数の情報源に対して、第１のバージョンと第２のバージョンのファイル間の差のストリーミングすなわちダウンロードを開始することができる。
【００３６】
図８は、アプリケーションのアップデートを円滑にするための前処理の方法８００のフローチャート図である。参照番号８１０にて、次のパッケージファイルが取得される。番号８２０にて、パッケージのファイル全てが処理されたかどうか、または換言すれば、ファイルのリストの最後に到達したかどうかについて判定することができる。最後に到達し（「はい」）、全てのパッケージのファイルが処理されたことが示される場合、方法８００は終了する。しかし、最後に到達していない場合（「いいえ」）、メタデータ（例えば、ファイル名、サイズ．．．）を含むが内容がない特定のファイルについてスパースファイルが作成される。そして、８４０にて、スパースファイルの作成が成功したかどうかについてチェックがなされる。作成が成功した場合（「はい」）、方法８００は参照番号８１０にループして戻り、そこで次のパッケージファイルが取得される。作成が不成功の場合（「いいえ」）、方法８００は８５０に進み、そこで前回実行した前処理動作、すなわち段階分け動作がロールバック（後進復帰）（例えば、アンドゥ）され、方法８００は終了する。
【００３７】
図９は、仮想アプリケーションをアップデートする方法９００を例示する。参照番号９１０にて、ファイルが、新パッケージから取得されるか、または新パッケージに対して識別される。番号９２０にて、パッケージ内の全てのファイルが処理されたかどうか、または換言すれば、ファイルのリストの最後に到達したかどうかについて判定される。全てのファイルが処理された場合（「はい」）、方法９００は終了する。他方の場合（「いいえ」）、方法９００は、９３０へ進み、そこで旧パッケージ内にファイルが存在するかどうかについて判定される。旧パッケージ内にファイルが存在しない場合（「いいえ」）、方法９００は９４０へ進み、そこでファイルのダウンロードが開始またはキュー（待ち行列入る）され、方法９００は参照番号９１０にループして戻る。ファイルが旧パッケージ内に存在する場合（「はい」）、方法９００は９５０へ進み、そこで、例えば、ファイルまたはファイルの一部に関連するハッシュコードを比較することにより、新しいファイルが、対応する古いファイルに対して無変更であるかどうかについて判定される。ファイルが無変更の場合（「はい」）、方法９００は９６０に進み、そこで、古いファイルと新しいファイルの間に、新しいファイルが、常駐する古いファイルの場所に対して関連付けされるようなハードリンクが作成される。続いて、参照番号９１０にて、新しいパッケージファイルを取得することができる。しかし、９５０にて、ファイルが変更されていると判定される場合（「いいえ」）、方法９００は番号９７０へ進み、そこで、マッチングハッシュコードを有するブロックがファイルからコピーされ新しいファイルに追加される。別の言い方をすれば、古いファイルから新しいファイルに変更されないデータの一部が、古いファイルからコピーされ新しいファイルに追加される。参照番号９８０にて、ファイルの非マッチングブロックのダウンロードが開始される。続いて、コピーされたデータおよび取得されたデータを組み合わせて新しいファイルを形成することができる。次に、方法９００は参照番号９１０に戻り、全てのファイルが処理されてしまうまで次のファイルを取得する。
【００３８】
図１０は、仮想アプリケーションをアップデートする方法１０００を示す。参照番号１０１０にて、新しいディレクトリが作成される。新しいディレクトリはスパースディレクトリであってよく、ファイルに関する情報を含むが内容がない１つまたは複数のスパースファイルを含むことができる。番号１０１２にて、新しいパッケージファイルがスパースディレクトリから取得されるか、スパースディレクトリによって識別される。１０１４にて、パッケージ内の全てのファイルが処理されたかどうか、または換言すれば、パッケージまたはファイルのリストの最後に到達したかどうかについてチェックがなされる。全てのパッケージファイルが処理された場合（「はい」）、方法１０００は終了する。他方の場合（「はい」）、方法は番号１０１６へ進み、そこで、新しいファイルが、ファイルの旧バージョンまたは以前のバージョンに対して変更されたかどうかについて判定される。ファイルが変更されなかった場合（「いいえ」）、方法は１０１８へ進み、そこで、ハードリンクが、古いファイルパスと新しいファイルのパスの間に作成され、続いて、番号１０１２にて新しいファイルが取得すなわち識別される。ファイルが変更された場合（「はい」）、方法１０００は１０２０に進み、そこで、旧パッケージの対応する古いファイル（例えば、無変更の）から少なくともファイルの一部をコピーする試みがなされる。番号１０２２にて、１０２０のコピー動作が成功したと判定される場合、または換言すれば、失敗しなかった場合（「いいえ」）、方法は１０２４へ進み、そこで、変更されたブロックのストリーミング、すなわちダウンロードが開始される。続いて、方法１０００は番号１０１２に戻り、そこで、次のファイルが取得される。しかし、１０２２にて、１０２０のコピー動作が失敗したと判定される場合（「はい」）、方法１０００は１０２６に進み、そこで、ファイル全体のストリーミングが開始され、番号１０１２にループして戻り、次のファイルが取得、すなわち識別される。
【００３９】
図１１は、変更されたデータを情報源から取得する方法１１００のフローチャート図である。参照番号１１１０にて、ファイル全体および／またはファイルブロックがプロキシに要求される。１１２０にて、要求が失敗したかどうか、または別の言い方をすれば、結実しなかったかどうか、について判定される。要求された結果を要求が返した場合（「いいえ」）、方法１１００は終了する。あるいは、要求が失敗した場合（「はい」）、方法１１００は番号１０３０に進み、そこで、ファイル全体および／またはファイルブロックがローカルコンピュータに要求される。換言すれば、変更されたデータを求める有線または無線の要求を、別のローカルコンピュータに対して行うことができる。１１４０にて、要求が結果を返す場合、方法１１００は終了する。他方の場合（「はい」）、方法１１００は１１５０に進み、そこで、ファイル全体および／またはブロックを求める要求が、単一マシン上の代替のユーザストアに対して行われる。要求が成功する場合、または換言すれば、失敗しない場合（「いいえ」）、方法１１００は終了する。要求が、要求されるデータを産出できない場合（「はい」）、方法１１００は参照番号１１７０へ進み、そこで、ファイル全体および／またはファイルブロックが仮想アプリケーションサーバなどのサーバに要求され、方法１１００は終了する。要するに、ファイル全体および／またはファイルブロックは、アプリケーションサーバ以外に多くの他のデータソースの内の１つに要求されてよく、多くの他のデータソースが要求されたデータを提供できる場合、ワイドエリアネットワーク帯域幅を保存することができる。
【００４０】
本明細書において使用される時、用語「コンポーネント」および「システム」ならびにその形は、コンピュータ関連の実体、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのどれかに言及することが意図される。例えば、コンポーネントは、プロセッサ上で稼働するプロセス、プロセッサ、オブジェクト、インスタンス、実行ファイル、実行ファイルのスレッド、プログラム、および／またはコンピュータであってよいが、これに限定されない。例として、コンピュータ上で稼働するアプリケーションおよびコンピュータの両方をコンポーネントとすることができる。１つまたは複数のコンポーネントはプロセスおよび／または実行ファイルのスレッド内に存在してよく、また、１つのコンポーネントは１つのコンピュータ上にローカライズされてよく、および／または２つまたはそれ以上のコンピュータ間に分散されてよい。
【００４１】
語「例示の」またはその種々の形は、例、例証、または実例として機能することを意味するために本明細書で使用される。本明細書において「例示の」として記載されるいずれの態様または設計も、他の態様または設計よりも好適または有利であるとは必ずしも解釈されない。さらに、例は、単に明確さおよび理解の目的で提供され、かつ、請求される主題または本開示の関連箇所をいか様にも制限または限定しない。さまざまな範囲の多数の追加または代替の例が存在するが、簡潔にする目的で省略されたことは理解すべきである。
【００４２】
本明細書において使用される時、用語「推測」または「推測する」は概して、事象および／またはデータを介して獲得されるような観察結果の集合から、システム、環境、および／またはユーザについて推論するまたはその状態を推測するプロセスを言う。推測は、特定のコンテキストまたは動作を識別するために使用することができ、または、例えば、状態に対する確立分布を生成することができる。推測は確立的なものであってよく、すなわち、データおよび事象の考察に基づく関心事の状態に対する確立分布の計算である。推測はまた、事象および／またはデータの集合から高レベルの事象を形成するために使用される技術に言及してもよい。そのような推測により、観察された事象および／または記憶された事象データの集合から、結果として新しい事象または動作が構築され、これは、事象が一時的に極めて近接して相互関係があるかどうかに係わらず、また、事象およびデータが１つまたはいくつかの事象およびデータソースに由来するものであるかどうかに係わらない。種々の分類スキームおよび／またはシステム（例えば、サポートベクタマシン、ニューラルネットワーク、エキスパートシステム、ベイジアン信念ネットワーク、ファジー論理、データ融合エンジン．．．）を、請求される主題と関連して自動的動作および／または推測される動作を実行することに関連して、使用することができる。
【００４３】
さらに、用語「含む」「含有する」「有する」「有している」またはその種々の形が、詳細な説明または請求の範囲において使用される限りにおいて、そのような用語は用語「備える」と同様に包括的であることが意図され、「備える」が請求の範囲において移行語として使用される時に解釈されるのと同様である。
【００４４】
請求される主題のコンテキストを提供するために、図１２および以下の検討では、主題の種々の態様を実装可能な適切な環境について簡単で概略的な説明を提供することが意図される。しかし、適切な環境は単なる例であり、使用または機能の範囲について何ら制限を示唆することは意図されない。
【００４５】
上記に開示されるシステムおよび方法は、１つまたは複数のコンピュータ上で稼働するプログラムのコンピュータ実行可能命令の一般的文脈で記載することができるが、当業者は、態様が、他のプログラムモジュールなどと組み合わせて実行可能でもあることを認識するであろう。概して、プログラムモジュールには、中でも、特定のタスクを実行し、および／または、特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造が含まれる。さらに、当業者は、上記のシステムおよび方法が種々のコンピュータシステム構成を用いて実践可能であることを理解するであろう。種々のコンピュータシステム構成には、シングルプロセッサ、マルチプロセッサまたはマルチコアプロセッサのコンピュータシステム、ミニコンピュータ装置、メインフレームコンピュータ、ならびに、パーソナルコンピュータ、携帯用コンピュータ装置（例えば、携帯情報端末（ＰＤＡ）、電話、時計．．．）、マイクロプロセッサベース電子機器またはプログラム可能家庭用電子機器または工業電子機器などが含まれる。態様はまた、タスクが通信ネットワークを介してリンクされるリモート処理装置により実行される、分散コンピュータ環境において、実践可能である。しかし、請求される主題の態様の全てではなくいくつかはスタンドアロンのコンピュータ上で実践可能である。分散コンピュータ環境において、プログラムモジュールはローカルおよびリモートのメモリ記憶装置の一方または両方に設置されてよい。
【００４６】
図１２を参照すると、一例の汎用コンピュータ１２１０またはコンピュータ装置（例えば、デスクトップ、ラップトップ、サーバ、携帯用、プログラム可能家庭用、または工業用の電子機器、セットトップボックス、ゲームシステム．．．）が例示される。コンピュータ１２１０には、１つまたは複数のプロセッサ１２２０、メモリ１２３０、システムバス１２４０、大容量記憶装置１２５０、および１つまたは複数のインターフェースコンポーネント１２７０が含まれる。システムバス１２４０は、少なくとも上記のシステムコンポーネントを通信可能に接続させる。しかし、その最も簡素な形態において、コンピュータ１２１０はメモリ１２３０に接続され、種々のコンピュータ実行可能な動作、命令、および／またはメモリ１２３０内に記憶されるコンポーネントを実行する１つまたは複数のプロセッサ１２２０を含むことができることを理解すべきである。
【００４７】
プロセッサ１２２０は、汎用プロセッサ、ＤＳＰ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）、ＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）もしくは他のプログラム可能論理装置、離散ゲートもしくはトランジスタ論理、離散ハードウェアコンポーネント、または本明細書に記載される機能を実行するべく設計されるこれらの任意の組み合わせ、を用いて実装可能である。汎用プロセッサはマイクロプロセッサであってよいが、代替えとしは、プロセッサは、任意のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってよい。プロセッサ１２２０はまた、コンピュータ装置、例えば、ＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、マルチコアプロセッサ、ＤＳＰコアを併用する１つまたは複数のマイクロプロセッサ、または任意の他のそのような構成においても実装されてよい。
【００４８】
コンピュータ１２１０は、様々なコンピュータ可読媒体を含むことまたはこれと対話することができ、請求される主題の１つまたは複数の態様を実装するコンピュータ１２１０の制御を円滑にする。コンピュータ可読媒体は、コンピュータ１２１０によるアクセスが可能、かつ、揮発性および不揮発性の媒体ならびに着脱可能および着脱不可能の媒体を含む任意の利用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体にはコンピュータ記憶媒体および通信媒体が含まれてよい。
【００４９】
コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意の方法または技術で実装される、揮発性および不揮発性、着脱可能および着脱不可能の媒体が含まれる。コンピュータ記憶媒体には、メモリ装置（例えば、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ  ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）．．．）、磁気記憶装置（例えば、ハードディスク、フロッピー（登録商標）ディスク、カセット、テープ．．．）、光ディスク（例えば、ＣＤ（ｃｏｍｐａｃｔ  ｄｉｓｋ）、ＤＶＤ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）．．．）、および、ソリッドステート装置（例えば、ＳＳＤ（ｓｏｌｉｄ  ｓｔａｔｅ  ｄｒｉｖｅ）、フラッシュメモリ装置（例えば、カード、スティック、キードライブ．．．）．．．）、または、所望の情報を記憶するために使用可能かつコンピュータ１２１０がアクセス可能な任意の他の媒体、が含まれるがこれに限定されない。
【００５０】
通信媒体は典型的には、コンピュータ可読命令、データ構造、プログラムモジュール、または、搬送波もしくは他の転送機構などの変調データ信号内の他のデータを具現化し、任意の情報配信媒体を含む。用語「変調データ信号」は、その１つまたは複数の特徴が信号内の情報を符号化するように設定または変更された信号を意味する。制限ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組み合わせも、コンピュータ可読媒体の範囲内に含むものとする。
【００５１】
メモリ１２３０および大容量記憶装置１２５０は、コンピュータ可読記憶媒体の例である。コンピュータ装置の正確な構成および型に依って、メモリ１２３０は、揮発性（例えば、ＲＡＭ）、不揮発性（例えば、ＲＯＭ、フラッシュメモリ．．．）またはこの２つの何らかの組み合わせとすることができる。例として、基本入出力力システム（ＢＩＯＳ）は、コンピュータ１２１０内の要素間で起動時などに情報を転送する基本ルーチンを含むもので、不揮発性メモリに記憶させることが可能であり、一方、揮発性メモリは外部キャッシュメモリとして動作することができ、中でも、プロセッサ１２２０による処理を円滑にする。
【００５２】
大容量記憶装置１２５０には、メモリ１２３０に関連する大量のデータを記憶するための着脱可能／着脱不可能、揮発性／不揮発性コンピュータ記憶媒体が含まれる。例えば、大容量記憶装置１２５０には、磁気もしくは光のディスクドライブ、フロッピーディスクドライブ、フラッシュメモリ、ソリッドステートドライブ、またはメモリスティック、などの１つまたは複数の装置が含まれるがこれに限定されない。
【００５３】
メモリ１２３０および大容量記憶装置１２５０には、オペレーティングシステム１２６０、１つまたは複数のアプリケーション１２６２、１つまたは複数のプログラムモジュール１２６４、およびデータ１２６６を含むこと、すなわちこれらを記憶することができる。オペレーティングシステム１２６０は、コンピュータ１２１０のリソースを制御および割り当てるべく動作する。アプリケーション１２６２には、システムおよびアプリケーションソフトウェアの一方または両方が含まれ、メモリ１２３０および／または大容量記憶装置１２５０内に記憶されるプログラムモジュール１２６４およびデータ１２６６を介してオペレーティングシステム１２６０によるリソースの管理を活用して、１つまたは複数の動作を実行することができる。よって、アプリケーション１２６２は、それにより提供される論理に従って汎用コンピュータ１２１０を専用マシンに変えることができる。
【００５４】
請求される主題の全てまたは一部は、ソフトウェア、ファームウェア、ハードウェアまたはその任意の組み合わせを制作するための標準プログラミング技術および／または工学技術を使用して実装され、コンピュータを制御して開示される機能を実現させる。制限ではなく例として、ストリームコンポーネント１１２およびアップデートコンポーネント１１４またはその一部は、アプリケーション１２６２のものであってよく、またはその一部を形成するものであってよく、かつ、１つまたは複数のプロセッサ１２２０により実行される時に機能性を実現させることができる、メモリおよび／または大容量記憶装置１２５０に記憶される１つまたは複数のモジュール１２６４およびデータ１２６６を含むことができる。
【００５５】
特定の一実施形態によると、プロセッサ１２２０は、ＳＯＣ（ｓｙｓｔｅｍ  ｏｎ  ａ  ｃｈｉｐ）または、単一の集積回路基板上にハードウェアとソフトウェアの両方を含む、または換言すれば統合する同様のアーキテクチャに相当するものとしてよい。ここで、プロセッサ１２２０には、中でも、少なくともプロセッサ１２２０およびメモリ１２３０と同様な１つまたは複数のプロセッサおよびメモリを含むことができる。従来のプロセッサには、最小限のハードウェアとソフトウェアが含まれ、外付けのハードウェアとソフトウェアに広範囲に依存する。対称的に、プロセッサのＳＯＣ実装はより強力であり、ハードウェアとソフトウェアをその内部に組み込み、最少の、または外付けに依存せずに、ハードウェアとソフトウェアを用いて特定の機能性を有効にする。例えば、ストリームコンポーネント１１２、アップデートコンポーネント１１４、および／または関連する機能性は、ＳＯＣアーキテクチャでハードウェア内に組み込まれてよい。
【００５６】
コンピュータ１２１０にはまた、システムバス１２４０と通信可能に接続され、かつ、コンピュータ１２１０との相互作用を円滑にする１つまたは複数のインターフェースコンポーネント１２７０が含まれる。例として、ポート（例えば、シリアル、パラレル、ＰＣＭＣＩＡ、ＵＳＢ、ＦｉｒｅＷｉｒｅ．．．）またはインターフェースカード（例えば、サウンド、ビデオ．．．）などとすることができる。一例の実装において、インターフェースコンポーネント１２７０はユーザ入出力インターフェースとして具現化することができ、１つまたは複数の入力装置（例えば、マウス、トラックボール、スタイラス、タッチパッド、キーボード、マイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、カメラ、他のコンピュータ．．．などのポインティングデバイス）を介してユーザがコマンドおよび情報をコンピュータ１２１０に入力することを可能にする。別の例の実装において、インターフェースコンポーネント１２７０は出力周辺インターフェースとして具現化し、出力を、中でも、ディスプレイ（例えば、ＣＲＴ、ＬＣＤ、プラズマ．．．）、スピーカ、プリンタ、および／または他のコンピュータに供給することができる。さらに、インターフェースコンポーネント１２７０は、ネットワークインターフェースとして具現化することができ、有線または無線の通信リンクを介するなどして他のコンピュータ装置（図示せず）との通信を可能にする。
【００５７】
上記に記載されたものには、請求される主題の態様の例が含まれる。もちろん、請求される主題を説明する目的でコンポーネントまたは方法論の全ての考え得る組み合わせを記載することは不可能であるが、当業者は、開示される主題の多くのさらなる組み合わせおよび置き換えが可能であることを理解するであろう。従って、開示される主題には、添付の請求項の精神および範囲内に入るような全ての変更、修正、および変形を包含することが意図される。
【図１】
2014502396.tif 000003
【図２】
2014502396.tif 000004
【図３】
2014502396.tif 000005
【図４】
2014502396.tif 000006
【図５】
2014502396.tif 000007
【図６】
2014502396.tif 000008
【図７】
2014502396.tif 000009
【図８】
2014502396.tif 000010
【図９】
2014502396.tif 000011
【図１０】
2014502396.tif 000012
【図１１】
2014502396.tif 000013
【図１２】
2014502396.tif 000014
【国際調査報告】
2014502396.tif 000015
2014502396.tif 000016