JP4796966B2

JP4796966B2 - ソフトウェアアプリケーションをプログレッシブインストールするためのシステムおよび方法およびａｐｉ

Info

Publication number: JP4796966B2
Application number: JP2006536561A
Authority: JP
Inventors: エイ．アルカザールマーク; ダンマイケル; ダブリュ．カンターアドリアン; ラマプラサドタムマナヴェンカタ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-10-23
Filing date: 2004-07-21
Publication date: 2011-10-19
Anticipated expiration: 2024-07-21
Also published as: US20040237082A1; EP1597654A4; WO2005045562A3; CN1961307A; KR20060114615A; WO2005045562A2; EP1597654A2; JP2007519071A

Description

本発明は、ソフトウェアアプリケーションのインストールに関する。

本出願は、参照により本明細書に組み込まれている、２００３年５月２２日に出願したＭａｒｋＡｌｃａｚａｒ、ＭｉｃｈａｅｌＤｕｎｎ、ＡｄｒｉａａｎＣａｒｔｅｒ、およびＰｒａｓａｄＴａｍｍａｎａらによる「SYSTEM AND METHOD FOR PROGRESSIVELY INSTALLING A SOFTWARE APPLICATION」という表題の米国係属特許出願第１０／４４４６９９号の一部継続出願である。

今日利用可能なアプリケーションは大きく分けて２種類ある。第１の種類のアプリケーションは、クライアントサイドアプリケーションである。クライアントサイドアプリケーションは、クライアントコンピュータに配置され、クライアントコンピュータが動作している限り利用することができる。このクライアントサイドアプリケーションは、利用できるようになるまでの間、異なるインストール状態をとる。通常、インストール状態に関して、インストール時に温度計などの何らかの形式の進行状況指示ユーザインターフェースを表示する。インストール状態では、クライアントサイドアプリケーションは利用できない。クライアントサイドアプリケーションは、ユーザがアプリケーションを使用する前に完全にインストールされていなければならない。

他の種類のアプリケーションは、一般に、ＷｅｂアプリケーションまたはＷｅｂａｐｐと呼ばれる。Ｗｅｂａｐｐは、Ｗｅｂサーバに格納される。Ｗｅｂａｐｐは、一般に、インターネット上でアクセス可能な複数のＷｅｂページとして展開される。従来のＷｅｂａｐｐは、マークアップ言語ベースのドキュメントを表す複数のＷｅｂページを含む。Ｗｅｂａｐｐは、Ｗｅｂページを通じてアクセスされるスクリプトまたはその他のリソースを含むこともできる。ほとんどのＷｅｂａｐｐでは、複数のＷｅｂページおよびリソースは、Ｗｅｂａｐｐの「ビジネスロジック」が複数のリソース上に分散される形でハイパーリンクでつながっている。それぞれのページは、ビジネスロジック全体の一部を受け持ち、ページからページへナビゲートすることにより、ユーザはＷｅｂａｐｐ全体を体験することができる。このドキュメントの目的のために、「ナビゲート（する）」という用語は、ハイパーリンクをアクティブ化することなどによりＷｅｂａｐｐに関連付けられているリソースをホスティング環境に読み出させることを意味する。リソースへのナビゲートでは、通常、ナビゲート先リソースがホスティング環境により読み出されるリソースである他のリソースからナビゲートすることを伴う。Ｗｅｂａｐｐは、インストールフェーズを必要とせず、クライアントコンピュータがＷｅｂサーバから接続を断たれると利用できなくなる。

ソフトウェアアプリケーションと対話するこれらの方法は両方とも、利点と欠点を持ち、いずれも理想的とはいえない。

本発明は、ユーザがアプリケーションとの対話を即座に開始できるようにソフトウェアアプリケーションのプログレッシブインストールを行うためのシステムおよび方法を実現する。その後、アプリケーションと対話をしている間に、アプリケーションは、ユーザのコンピュータにプログレッシブインストールされ、必要ならば、後からオフラインで使用可能にできる。プログレッシブインストール（ｐｒｏｇｒｅｓｓｉｖｅｉｎｓｔａｌｌａｔｉｏｎ）は、スタートアップ状態、デマンド状態、および最終（ファイナル）状態という３つの状態を含む。これらの状態はいずれも、アプリケーションが使用不可になる専用インストールフェーズを必要としない。その代わり、本発明のプログレッシブインストールでは、Ｗｅｂａｐｐが従来のＷｅｂａｐｐとして対話できるように、またその後、ユーザとアプリケーションとの対話に影響を及ぼすことなくクライアントサイドアプリケーションに円滑に遷移できるように、２つの形態のアプリケーションインストールを混合する。

本発明は、アプリケーションをプログレッシブインストールするためのメカニズムを提供する。プログレッシブインストールは、スタートアップ状態、デマンド状態、およびインストール状態という３つの状態を遷移する。スタートアップ状態では、アプリケーションに関連するコンポーネントのサブセットがダウンロードされ、ローカルデータストアに格納される。サブセットは、Ｗｅｂアプリケーションと類似の方法でアプリケーションを実行するのに十分なものである。デマンド状態では、アプリケーションに関連付けられたＷｅｂページ上のハイパーリンクをアクティブにした後アプリケーションに関連する追加リソースがダウンロードされる。オンデマンドリソースである追加リソースは、ローカルデータストアに格納される。オンラインリソースである追加リソースは、一時（ｔｒａｎｓｉｅｎｔ）キャッシュに格納される。インストール状態では、アプリケーションは、クライアントサイドアプリケーションと似た方法で実行される。デマンド状態からインストール状態への遷移は、ユーザとアプリケーションとの対話に影響を及ぼすことなく実行される。この遷移は、ローカルデータストアに格納されている追加リソースの数に基づいて自律的に、または外部からトリガがかかったときに、実行される。遷移の間、まだダウンロードされていない追加リソースがローカルデータストアにダウンロードされる。さらに、デマンド状態で派生する状態は、アプリケーションとともに保存され、これにより、アプリケーションはオフラインで実行されたときに同じ状態から再開することができる。

手短に言うと、本発明は、ユーザがアプリケーションとの対話を即座に開始できるようにソフトウェアアプリケーションのプログレッシブインストールを行うためのシステムおよび方法を実現する。その後、アプリケーションと対話している間に、アプリケーションは、ユーザのコンピュータにプログレッシブインストールされ、必要ならば、後からオフラインで使用できるようにインストールされる。プログレッシブインストールは、スタートアップ状態、デマンド状態、および最終状態という３つの状態を含む。これらの状態はいずれも、アプリケーションが使用不可になる専用インストールフェーズを必要としない。その代わり、本発明のプログレッシブインストールでは、Ｗｅｂａｐｐが従来のＷｅｂａｐｐとして対話できるように２つの形態のアプリケーションインストールを併用し、その後、ユーザとアプリケーションとの対話に影響を及ぼすことなくアプリケーションをオフラインアプリケーションに円滑に遷移させるメカニズムを提供する。

動作環境の例
図１は、本発明の一実施形態で使用できるコンピューティングデバイス例の図である。図１は、本発明の一実施例で使用できるコンピューティングデバイス例の図である。非常に基本的な構成では、コンピューティングデバイス１００は、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を備えるのがふつうである。コンピューティングデバイスの正確な構成と種類に応じて、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこれら２つの何らかの組合せとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を格納し、プログラムデータ１０７を含むこともできる。基本構成は、図１において点線１０８内のコンポーネントにより示されている。

コンピューティングデバイス１００は、さらに特徴または機能性を追加することもできる。例えば、コンピューティングデバイス１００は、磁気ディスク、光ディスク、またはテープなどの追加データ記憶デバイス（取り外し可能および／または固定）を含むこともできる。このような追加記憶装置は、図１では、取り外し可能記憶装置１０９および固定記憶装置１１０により例示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むことができる。システムメモリ１０４、取り外し可能記憶装置１０９、および取り外し不可能記憶装置１１０は、すべてコンピュータ記憶媒体の実施例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）もしくはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶デバイス、または所望の情報を格納するために使用することができコンピューティングデバイス１００によりアクセスできるその他の媒体があるが、これらに限定されない。このような任意のコンピュータ記憶媒体をデバイス１００の一部とすることができる。さらにコンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス１１２を含むこともできる。ディスプレイ、スピーカ、プリンタなどの出力デバイス１１４を含むこともできる。これらのデバイスは、当業ではよく知られているため、本明細書でさらに詳しい説明をする必要はない。

また、コンピューティングデバイス１００は、デバイスがネットワークなどを経由して他のコンピューティングデバイス１１８と通信するために使用する通信接続１１６も含むことができる。通信接続１１６は、通信媒体の一実施例である。通信媒体は、通常、搬送波もしくはその他のトランスポートメカニズムなどの変調されたデータ信号を介して、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータによって実現されることができ、情報配信媒体を含む。「変調されたデータ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体があるが、これらに限定されない。本明細書で使用されているコンピュータ可読媒体という用語は、記憶媒体および通信媒体の両方を含む。

ネットワーク接続環境の例
図２は、本発明の実装を具体化できる分散ネットワーキング環境の機能ブロック図概要である。図２に例示されているように、サーバ２０２およびクライアントコンピュータ２２０などの２台以上のコンピュータがネットワーク２０５を介して接続される。サーバ２０２およびクライアントコンピュータ２２０は、図１とともに上で説明されているデバイスなどのコンピューティングデバイスである。コンピュータは、企業環境内で接続することができ、その場合、ネットワーク２０５はローカルエリアネットワークまたはワイドエリアネットワークとすることができる。同様に、コンピュータは、インターネットなどのワイドエリアネットワークを介して任意に接続することができる。

サーバ２０２は、リソースをネットワーク２０５に接続されている他のコンピューティングデバイスで利用できるようにする構成を採用するコンピューティングデバイスである。サーバ２０２は、ハイパーテキストマークアップ言語（ＨＴＭＬ）ドキュメントなどのインターネット関連リソースに使用されるＷｅｂサービングソフトウェアを備えることができる。サーバ２０２は、サーバデータストア２１０の形態でローカル記憶装置を備える。サーバデータストア２１０上には、ネットワーク２０５上でサーバ２０２により利用できるようにされたリソースの少なくとも一部がある。具体的には、デプロイメントマニフェスト２１２は、サーバデータストア２１０だけでなく、アプリケーションパッケージ２１４および追加アプリケーションリソース２１６にも格納されるが、これらについては、図８〜１０を参照しながら以下で詳述する。サーバ２０２は、さらに、デプロイメントマニフェスト２１２だけでなく他の関連するドキュメントおよびリソースも構築し、保持するための他のアプリケーションも備える。この実装では、サーバ２０２は、アプリケーションパッケージ２１４および追加アプリケーションリソース２１６を他のコンピューティングデバイスからネットワーク２０５上で利用可能にする。

クライアントコンピュータ２２０は、ローカルで実行されるアプリケーションを実行するとともに、ネットワーク２０５上で他のコンピュータに接続するように構成されたコンピューティングデバイスである。クライアントコンピュータ２２０は、クライアントデータストア２２８の形態でローカル記憶装置も備える。クライアントデータストア２２８には、アプリケーションストア２３０および一時キャッシュ２３２が配置される。一実施形態では、クライアントコンピュータ２２０上で実行されるそれぞれのアプリケーションは、関連するアプリケーションストア２３０を有する。クライアントコンピュータ２２０は、さらに、ネットワーク上で他のコンピュータと対話するため他のアプリケーションも備える。このようなアプリケーションの１つに、インターネットブラウジングソフトウェア（これ以降、ブラウザ２２２と呼ばれる）などのホストソフトウェア２２２がある。ブラウザ２２２は、アプリケーションパッケージハンドラ２２４およびリソースローダ２２６と通信する。アプリケーションパッケージハンドラ２２４は、ブラウザ２２２がアプリケーションパッケージ２１４などのアプリケーションパッケージを見つけたときに、ブラウザ側でアプリケーションパッケージハンドラ２２４を呼び出すことがわかるように登録される。その後、アプリケーションパッケージハンドラ２２４は、アプリケーションパッケージ２１４を処理する。アプリケーションパッケージ２１４は、クライアントコンピュータ２２０上で関連するアプリケーションの実行を開始するための情報を含む。アプリケーションパッケージ２１４の形式は、実行可能ファイルまたはその他のパッケージングタイプ形式でよい。一実施形態では、アプリケーションパッケージハンドラ２２４は、関連する情報を取得するためにアプリケーションパッケージの形式を解読するように構成することができる。ブラウザ２２２は、さらに、クライアントコンピュータが追加アプリケーションリソース２１６などの追加リソースをサーバ２０２に要求するときにリソースローダ２２６と通信する。ブラウザ２２２、アプリケーションパッケージハンドラ２２４、およびリソースローダ２２６により実行される処理については、図５〜７の流れ図とともに以下で詳述する。

手短に言うと、クライアントコンピュータ２２０のユーザは、従来の任意の方法でサーバ２０２に接続することができる。サーバ２０２は、サーバデータストア２１０に配置されたファイルを利用可能にするＷｅｂページまたは他の何らかのリソースを表示する。ユーザがリンクなどを選択したことに対する応答として、サーバ２０２はデプロイメントマニフェスト２１２へナビゲートし、要求されたアプリケーションに関連するアプリケーションパッケージ２１４を識別する。以下で詳述するが、アプリケーションパッケージ２１４は、アプリケーションを起動するのに必要な最低限の量のコードを含む。アプリケーションパッケージ２１４は、サーバ２０２からクライアントコンピュータ２２０にダウンロードされる。

図３は、本発明の一実装によりリモートアプリケーションのプログレッシブダウンロードを使用可能にするＷｅｂブラウジングソフトウェアにより表示できる画面表示である。図３を手短に参照すると、上述のサーバ２０２が使用されるＷｅｂページ３１０を含むブラウザ２２２の表示例３００が示されている。Ｗｅｂページ３１０は、特定のＷｅｂａｐｐと関連付けられたリソースででもよいし、またはリモートコンピューティングシステムがソフトウェアアプリケーションをダウンロードに利用できるようにするためのリソースでもよい。Ｗｅｂページ３１０は、上述のデプロイメントマニフェスト２１２を指しているハイパーリンク３６０を含む。デプロイメントマニフェスト２１２は、アプリケーションを起動するのに必要な少なくとも最小のコードを含む、アプリケーションパッケージ２１４を指している。また、Ｗｅｂページ３１０は、上述のデプロイメントマニフェスト２１２を指しているハイパーリンク３８０を含む。ハイパーリンク３８０を選択するということは、ユーザが現在アプリケーションを明示的に「インストール」することに関心を持っていることを示す。図７について以下で詳述するように、ハイパーリンク３８０を選択した後、ユーザは、アプリケーションのダウンロードまたはコンピュータへのインストールを待たずに引き続きアプリケーションと対話することができる。

Ｗｅｂページ３１０はインターネット、企業イントラネット、または他のネットワークアクセス可能なロケーション上で供給することができることは理解されるであろう。ハイパーリンク３６０をアクティブにすると、アプリケーションパッケージ２１４はサーバからプルダウンされる。Ｗｅｂページ３１０は、ユーザがアプリケーションを呼び出せる唯一の手段であることは理解されるであろう。例えば、アプリケーションパッケージ２１４へのリンクは、電子メールメッセージなどに入れて送ることができる。

手法の実例
図４は、本発明の一実装による、アプリケーションのプログレッシブインストールのさまざまな状態を例示する状態図４００である。プログレッシブインストールは、呼び出し状態４０２、スタートアップ状態４０４、デマンド状態４０６、およびインストール状態４１０を含む。呼び出し状態４０２で、ユーザはアプリケーションを呼び出す。ユーザがサーバ２０２から供給されるリンクをクリックすることによりアプリケーションを呼び出すと、プログレッシブインストールはスタートアップ状態４０４に進む。しかし、後で詳述するように、アプリケーションは、クライアントコンピュータ上にすでにインストールされている可能性がある。ローカルにインストールされているアプリケーションは、ローカルアプリケーションへのリンクを選択する、スタートメニュー内のローカルアプリケーションへのショートカットを選択するなどの方法により呼び出すことができる。ローカルにインストールされているアプリケーションが呼び出されると、プロセスはインストール状態４１０に遷移する。他の実施形態では、呼び出し状態４０２からインストール状態４１０への遷移は、サブスクリプション更新状態４１２を介して進行することができる。手短に言うと、サブスクリプション更新状態４１２により、サーバ２０２上でアプリケーションの更新が利用可能かどうかを判別するということである。更新があれば、アプリケーションの更新されたコンポーネントがダウンロードされる。

次に、アプリケーションがローカルにインストールされていないと仮定して、プログレッシブインストールがスタートアップ状態４０４に進む。図５を参照し手短に言うと、スタートアップ状態４０４は、アプリケーションをクライアントコンピュータ上で実行するのに必要な最小のコードをダウンロードする。最小のコードはアプリケーション丸ごとに比べてかなり小さいので、ユーザはアプリケーションとの対話をすぐに開始することができ、これは、今日従来のＷｅｂａｐｐと対話している場合にユーザが経験することとあまり変わらない。プログレッシブインストールは、スタートアップ状態からデマンド状態４０６に進む。図６を参照して手短に説明すると、デマンド状態４０６は、必要に応じて、リソースをダウンロードする。このため、ユーザは、アプリケーションの購入またはアプリケーションとの継続関係を進展させる前にアプリケーションを試すことができる。

デマンド状態４０６から、ユーザは、アプリケーションのローカルでのインストールに先んじて、終了状態４０８に進むことができる。これは、ユーザがブラウザを閉じると実行される。ユーザがデマンド状態４０６から終了状態４０８に遷移すると、アプリケーションダウンロードされたコンポーネントを削除することができる。したがって、クライアントコンピュータは、ユーザがアプリケーションを呼び出す前と同じ状態となる。そこで、ユーザは、後でリモートアプリケーションを再び呼び出すことができる。プログレッシブインストールは、再び、スタートアップ状態とデマンド状態を通る。そのため、ユーザは、アプリケーションをインストールすることに踏み切らずに再びアプリケーションを使用することができる。プログレッシブインストールは、デマンド状態４０６からインストール状態４１０に進む。遷移は、購入決定、昇格許可（ｅｌｅｖａｔｅｄｐｅｒｍｉｓｓｉｏｎ）（例えば、信頼昇格（ｔｒｕｓｔｅｌｅｖａｔｉｏｎ））の要求に基づいてユーザが開始するか、または予め定められている数のリソースがすでにクライアントコンピュータ上にインストールされているときなどに、オペレーティングシステム側で自律的に実行することができる。デマンド状態からインストール状態への遷移は、ユーザとアプリケーションとの対話に影響を及ぼさない。この遷移は、図７に関して以下で説明される。

そこで、本発明によるプログレッシブインストールを使用すると、ユーザは、アプリケーションを呼び出すと直ちにアプリケーションとの対話を開始することができる。ユーザに影響を及ぼすことなくユーザがアプリケーションと対話している間にアプリケーションの各部がダウンロードされる。ユーザが専用のインストールを待つ必要はまったくない。

図５は、本発明の一実施形態によるプログレッシブインストールのスタートアップ状態のプロセスを一般的に例示する論理流れ図である。プロセスはブロック５０１から開始し、そのブロックで、ネットワークに配置されるアプリケーションはアプリケーションに関係するハイパーリンクを選択するなどにより呼び出される。図５に進む前に、ネットワークに配置されるアプリケーションのコンポーネントについて図８と併せて説明する。

図８は、サーバ２０２上のネットワークに配置されたアプリケーションのコンポーネントを図形的に表したものである。コンポーネントは、デプロイメントマニフェスト２１２、アプリケーションパッケージ２１４、および追加アプリケーションリソース２１６を含む。アプリケーションパッケージ２１４は、アプリケーションマニフェスト８０２およびコード８０４を含む。アプリケーションマニフェスト８０２には、各コンポーネント、そのバージョン、および依存関係を含むアプリケーションコードの詳細が記述される。そのような性質のサンプルアプリケーションマニフェストが、本明細書に「付録Ａ−サンプルアプリケーションマニフェスト」として収録されている。本明細書では特定のファイルとして説明されているが、本発明のアプリケーションマニフェスト２１２は何らかの形のアプリケーションのコンポーネントを説明する情報を意味するものとして解釈すべきであり、本明細書で説明されている場所以外の場所に存在していてもよい。本明細書で説明されているアプリケーションマニフェスト２１２は例示のために用意されているにすぎない。一実施形態では、コード８０４は、アプリケーションを実行するのに必要な最小のコードを含む。当業者であれば、本発明から逸脱することなく必要のない追加コードをアプリケーションパッケージ２１４に含めることができることは理解するであろう。しかし、遅延またはユーザへの影響を少なくするために、最低限の量のコードが必要である。追加アプリケーションリソース２１６は、マークアップＡ８１０、追加コード８１２、マークアップＢ８１４などのオンデマンドリソースおよびオンラインリソースを含む。図８は、５つの追加リソースのみを例示しているが、当業者であれば、通常、Ｗｅｂａｐｐのコンポーネントであるリソースがさらにいくつかあることを理解するであろう。

図５を参照すると、本発明の一実施形態では、ブロック５０２でデプロイメントマニフェスト２１２へのナビゲーションが行われる。一実施形態では、デプロイメントマニフェストはリモートサーバ上に配置され、これによりアプリケーションのエントリポイントが識別される。サンプルデプロイメントマニフェストが、本明細書に「付録Ｂ−サンプルデプロイメントマニフェスト」として収録されている。

ブロック５０４で、このエントリポイントへのナビゲーションが実行される。一実施形態では、エントリポイントは、アプリケーションマニフェストおよびアプリケーションを実行するのに必要な最低限の量のコードを含むアプリケーションパッケージ（例えば、図８に示されているアプリケーションパッケージ２１４）とすることができる。

ブロック５０６で、ホストが起動される。一実施形態では、ホストはＷｅｂブラウザである。アプリケーションがクライアントコンピュータからプログレッシブインストールされる他の実施形態では、ホストはスタンドアロンのホストとすることができる。そうすると、スタンドアロンのホストは、ホストがＷｅｂブラウザである実施形態を使用して以下で説明するのと同じ方法で機能する。アプリケーションパッケージに関連するファイルタイプに対しアプリケーションパッケージハンドラが登録される。したがって、ブラウザがアプリケーションパッケージを受け取ると、アプリケーションパッケージハンドラは本発明によるプログレッシブインストールを開始することができる。一実施形態では、アプリケーションパッケージハンドラは、アプリケーションパッケージ２１４に関連付けられたファイルタイプについて登録されているｍｉｍｅハンドラとすることができる。

ブロック５０８で、アプリケーションを実行するために必要が最低限度の量のコードがダウンロードされる。アプリケーションパッケージ２１４を使用する実施形態では、これはアプリケーションパッケージ２１４をダウンロードすることを含む。上述のように、ブラウザはアプリケーションパッケージハンドラを呼び出してアプリケーションパッケージ２１４を処理する。

ブロック５１０で、リソースローダが登録され、アプリケーションに関連付けられる。リソースローダは、必要なときにアプリケーションリソースをロードする役割を持つ。一実施形態では、リソースローダは、アプリケーションの「コンテキストで」リソースをロードする方法が組み込まれているプラグ可能プロトコルとすることができる。

ブロック５１２で、アプリケーションのアプリケーションドメインが作成される。ブロック５１４で、アプリケーションを構成するユーザコードが実行される。一実施形態では、アプリケーションの実行によりアプリケーションオブジェクトが作成される。アプリケーションオブジェクトを作成するために、クラスを定義するアプリケーションパッケージ内のコードが実行される。アプリケーションオブジェクトは一意のＩＤを持つ。さらに、アプリケーションオブジェクトは状態を含む。この状態は、デマンド状態で連続的に更新される。この状態は、ユーザとアプリケーションとの対話に関連する情報を含む。この状態情報を使用することで、アプリケーションはＷｅｂアプリケーションからクライアントアプリケーションへ滑らかに遷移することができる。

スタートアップ状態での処理が完了する。その後、プログレッシブインストールがデマンド状態に進む。図８に示されているように、スタートアップが完了した後、アプリケーションパッケージ２１４はクライアントコンピュータ２２０のアプリケーションストア２３０に格納される。ユーザは、アプリケーションとの対話を開始することができる。従来のＷｅｂａｐｐでは、Ｗｅｂａｐｐのリソースは、アプリケーション毎のストア２３０の概念もなく、一時キャッシュ２３２にダウンロードされていた。これからわかるように、アプリケーション毎のストア２３０を有することにより、本発明はＷｅｂａｐｐからクライアントサイドアプリケーションへユーザに影響を及ぼすことなく滑らかに遷移することができる。

図６は、プログレッシブインストールのデマンド状態のプロセスを一般的に例示する論理流れ図である。デマンド状態はブロック６０１から始まるが、そのブロックでスタートアップ状態が完了し、ユーザはアプリケーションと対話する。プロセス６００は、アプリケーションの一部が要求されたときに必ず実行される処理を示す。これは、アセンブリロード（コード）、リソースなどの要求を含むことができる。通常、デマンド状態ではリソースおよびコードに対する多くの要求が受け取られる。それぞれのそのような要求はプロセス６００を実行する。以下の説明では、要求がリソースの場合のプロセス６００を議論する。当業者であれば、要求がアセンブリロードについてのものである場合にプロセス６００も実行されることを理解するであろう。

ブロック６０２で、要求が受け取られる。通常、ユーザがアプリケーションに関連付けられたＷｅｂページのうちの１つにあるハイパーリンクを選択すると必ず要求が発生する。処理は、決定ブロック６０４に続く。

決定ブロック６０４で、要求がリソースについてのものであるかどうかが判別される。要求がリソースについてのものでない場合、処理は終わりまで進む。その一方で、要求がリソースについてのものである場合、処理は決定ブロック６０６に進む。

決定ブロック６０６で、要求されたリソースがローカルで使用可能であるかどうかが判別される。リソースがローカルで使用可能である場合、使用するリソースのローカルコピーがロードされ、プロセスは終わりまで進む。リソースのタイプに応じて、ローカルコピーはアプリケーションストア内にあるか、または一時キャッシュ内にある。リソースがローカルで使用できない場合、処理は決定ブロック６１０に進む。

決定ブロック６１０で、要求されたリソースがオンデマンドリソースであるかどうかが判別される。要求されたリソースがオンデマンドリソースの場合、処理はブロック６１２に進み、そこで、リソースはｈｔｔｐを介してロードされ、ローカルアプリケーションストアにキャッシュされる。例えば、図９で、マークアップＡ８１０およびコード８１２は、アプリケーションストア２３０に格納される。プロセスは終わりまで進む。決定ブロック６１０で、リソースがオンデマンドリソースでない場合、処理は決定ブロック６２０に続く。

決定ブロック６２０で、要求がオンラインリソースであるかどうかが判別される。リソースがオンラインリソースである場合、処理はブロック６２２に続き、そこで、オンラインリソースがｈｔｔｐを介してロードされる。ブロック６２４で、オンラインリソースはトランスポートキャッシュ２３２にキャッシュされる。例えば、図９で、マークアップｂ８１４は、オンラインリソースとして指定されており、一時キャッシュに格納される。その後処理は完了する。

一実施形態では、それぞれのリソースは、何らかの形で関連付けられているリソースのグループに属すことができる。例えば、一般に併用されるリソースは、１つのグループに入れることができる。このような場合、ブロック６１２および６２２で、対象リソースを含むリソースのグループ全体を読み出すことができる。この手法により、後から必要になる他のリソースがローカルにすでに存在する可能性が高まる。

そのため、デマンド状態では、追加リソースがダウンロードされ、アプリケーション毎のストアに初期値として配置されることが分かるであろう。ダウンロードされるリソースはアプリケーションをオフラインで実行するのに必要なリソースと同じであるため、後述のように、アプリケーションストアをアプリケーションオブジェクトと併用することで、本発明は、ユーザとアプリケーションとの対話に影響を及ぼすことなく、Ｗｅｂアプリケーションからクライアントサイドアプリケーションへ滑らかに遷移することができる。したがって、２つの異なる種類のアプリケーション（つまり、クライアントサイドアプリケーションとＷｅｂアプリケーション）を用意せずに、１種類のアプリケーションを両方の目的に使用することができる。本発明を使用することで、この１種類のアプリケーションは必要なときに一方の目的から他方の目的に滑らかに遷移する。

図７は、プログレッシブインストールのデマンド状態とインストール状態との間で遷移するプロセスを一般的に例示する論理流れ図である。処理はブロック７０１から開始し、そこで、アプリケーションをインストールすべきであることを知らせるトリガが発生する。トリガは、ユーザ開始トリガ、またはアプリケーション毎のストアにすでにダウンロードされているリソースの数などの外部ベンチマークに基づいて自律的なトリガとすることもできる。処理は、ブロック７０２に続く。

ブロック７０２で、残りのオンデマンドリソースがｈｔｔｐを介してダウンロードされる。処理は、ブロック７０４に続く。ブロック７０４で、これら残りのオンデマンドリソースは、アプリケーションストアに格納される。これは、ユーザがまだアプリケーションと対話している間に実行される。例えば、図１０は、アプリケーションストアに現在配置されているマークアップＣ８１６を例示している。処理は、ブロック７０６に続く。

ブロック７０６で、オンラインリソースのコピーがアプリケーションストア２３０に格納される。したがって、一時キャッシュ内のコピーが取り除かれても、オンラインリソースのコピーはそのまま存在する。例えば、図１０を参照すると、マークアップＢ８１４はアプリケーションストアに格納されているものとして例示されている。処理は、ブロック７０８に続く。

ブロック７０８で、アクティベーション情報がオペレーティングシステムに記録される。例えば、ショートカットがスタートメニューに追加される場合がある。アクティベーション情報により、アプリケーションが次回ローカルで呼び出されたときに従来のメカニズムを使用してアプリケーションを呼び出すことができる。処理は、ブロック７１０に続く。

ブロック７１０で、インプレッション情報（ｉｍｐｒｅｓｓｉｏｎｉｎｆｏｒｍａｔｉｏｎ）がオペレーティングシステムに記録される。インプレッション情報は、ファイル関連付けなどの、アプリケーションとオペレーティングシステムとの相互作用を記述するものである。さらに、インプレッション情報では、アプリケーションの変更／プログラムエントリからの削除の仕方についても記述する。図１０を参照すると、アクティベーション情報８３２およびインプレッション情報８３４は、クライアントコンピュータ２２０のオペレーティングシステム情報８３０内に示されている。その後処理は完了する。

上述のように、この時点で、アプリケーションはオフラインで利用可能になっている。上述の説明を読むとわかるように、ユーザはアプリケーションのインストールを待つ必要がなかった。デマンド状態で生成される情報は、インストール状態に移行される。したがって、ユーザがアプリケーションと対話している間に格納されたアプリケーションのＩＤおよび状態情報を使用することにより、アプリケーションはインストール状態に滑らかに遷移することができる。

アプリケーションプログラミングインターフェースの実施例
具体的な一実施例では、上述の手法は、ダウンロードおよびインストール、サービス、信頼とプライバシーの確立、ならびにアプリケーションの最終的実行を管理するための機能性を公開するアプリケーションプログラミングインターフェース（ＡＰＩ）で実装することができる。このようなＡＰＩの一実施例について、これらの各機能を処理するためのＤｅｐｌｏｙｍｅｎｔＭａｎａｇｅｒの以下のクラス例で説明する。このＤｅｐｌｏｙｍｅｎｔＭａｎａｇｅｒのスケルトンタイプの定義を以下に示す。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
public class DeploymentManager
{
public DeploymentManager(string identity, string codebase)
{ ... }

//呼び出すことができる非同期オペレーションに対するイベント。
public event BindCompletedEventHandler
BindCompleted;
public event
DeterminePlatformRequirementsCompletedEventHandler
DeterminePlatformRequirementsCompleted;
public event
DetermineAuthorizationCompletedEventHandler
DetermineAuthorizationCompleted;
public event SynchronizeCompletedEventHandler
SynchronizeCompleted;
public event ExecuteCompletedEventHandler
ExecuteCompleted;

//すべての非同期オペレーションに対するProgressChangedイベント

public event DeploymentProgressChangedEventHandler
DeploymentProgressChanged;

//BindAsync
public void BindAsync(object userToken)
{ ... }

//DetermineRequirementsAsync
public void
DeterminePlatformRequirementsAsync(object userToken)
{ ... }

// DetermineAuthorizationAsync
public void DetermineTrustAsync(object userToken)
{ ... }

// SynchronizeAsync
public void SynchronizeAsync(object userToken)
{ ... }

// ExecuteAsync
public void ExecuteAsync(object userToken)
{ ... }

// AsyncCancel
public void AsyncCancel()
{ ... }
}
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＤｅｐｌｏｙｍｅｎｔＭａｎａｇｅｒは、（１）マニフェストバインディング、（２）プラットフォーム要件の判別、（３）権限の判別、（４）同期処理、および（５）実行の５つの主要オペレーションのためのメソッドを公開することに留意されたい。これらの関数について、それぞれ、簡単にここで説明することにする。

マニフェストバインディング
マニフェストバインディングは、展開されたアプリケーションに関する必要なマニフェストメタデータをインストール、サービス、およびアクティベーションのために最初に取得するプロセスである。バインディングは、一般に、デプロイメントマニフェストへのコードベース、または展開されたアプリケーションのＩＤ、または場合によってはそれらの両方のから始まる。バインディングでは、展開されたアプリケーションに関して後から決定するためのマニフェスト情報の最小セットを取り出す。マニフェストバインドでは、バインド、アプリケーションストアの状態、およびバインド先のアプリケーションのコンテキストに応じてネットワーク接続を必要とする場合もあれば必要としない場合もある。アプリケーションがすでにマシンに展開されている場合、バインドは、ネットワークＩ／Ｏなしの完全オフライン状態で成功することができる。

プラットフォーム要件の判別
バインディングが完了した後、クライアントマシンのインストール状態を問い合わせてアプリケーションを実行するために必要なプラットフォームが存在しているかどうかを判別できるようになる。プラットフォームは、アプリケーションが依存しているが、展開済みアプリケーションインストールの一部としてインストールすることができないソフトウェアとして識別することができる。展開されたアプリケーションは、アプリケーションマニフェストに記述されているこれらの依存関係を参照する。例えば、オペレーティングシステムの最小バージョン、ランタイム環境の最小バージョン、ＧＡＣ常駐アセンブリの特定のバージョンについてサポートを提供することもできる。バージョンが最小として処理されるかどうかは、アセンブリがプラットフォームまたはライブラリとしてマーク付けされるかどうかに依存する場合がある。

プラットフォーム要件が満たされている場合、アプリケーションインストールは続行する。プラットフォーム要件が満たされていない場合、どのプラットフォーム依存関係が満たされていなかったかに関する特定の情報とともに失敗が返される。アプリケーションインストールプロセスは、その後、続行できないが、マシンに必要なプラットフォームをインストールするアクションが実行された後そのプロセスを繰り返すことができる。

権限の判別
アプリケーションにどのような信頼、プライバシー、およびライセンスが受け入れられるかに関する決定を、このような情報を展開およびアプリケーションマニフェスト内に配置することもできるため、マニフェストバインディングが完了した後に行うことができる。これらの決定は、権限の一般的カテゴリの下にグループ化される。例えば、アプリケーションが既定のサンドボックスで実行できない場合に、権限がユーザプロンプティングを必要とすることがある。権限の付与が成功すると、クライアントマシン上でアプリケーションを実行するのに必要な一組の許可付与、プライバシーポリシー保証、ライセンスキーなどが生成される。この情報は、アプリケーションがアクティブにされているときに決定を後で繰り返す必要がないようにキャッシュしておくことができる。権限が失敗した場合、アプリケーションインストールは続行できない。

同期処理
プラットフォームおよび権限の判別が首尾よく完了すると、アプリケーションペイロードをインストールする実際のタスクを開始できる。このプロセスは、同期処理と呼ばれる。同期処理は、展開済みアプリケーションの必要なバージョンがすでにマシン上に存在していることを単に確認するだけで成功する。それとは別に、同期処理では、リモートで展開されているアプリケーション（オンデマンドコンポーネント、言語パックとともに必要）またはアプリケーションを起動するために必要な最小限度必要サブセットのみ（例えば、必要なコンポーネントのみ）の完全ダウンロードを伴う場合がある。ダウンロードが発生した場合、同期処理はさらに、（１）アプリケーションペイロードがディスク上の一時記憶域に複製される純粋なトランスポートフェーズおよび（２）展開済みアプリケーションが格納処理され、バインディングに利用可能にされる、コミットオペレーションの２つのフェーズに細分される。同時処理は、既存のインストール済みアプリケーションのオプションコンポーネントまたはオンデマンドコンポーネントのダウンロードに使用することもできる。

実行
アプリケーションがプラットフォームおよび権限の決定を正常に完了し、ペイロードの同期処理が正常に行われ、格納のコミットが行われた後、アプリケーションを実行（起動（ｌａｕｎｃｈ）または実行（ｒｕｎ））できる。実行は、別のスタンドアロンのプロセスで行うか、または既存の呼び出し側のプロセスを使用して行うことができる。両方の場合に、実行ホストは、場合によっては再プロンプティングを回避するために前回の権限呼び出しですでにすでにキャッシュされている決定を利用して、アプリケーションの安全な実行環境を提供する。

クライアントサイドの実装
非同期完了結果などのＤｅｐｌｏｙｍｅｎｔＭａｎａｇｅｒメソッドの呼び出しからの通知を受け取るために、クライアントは、関連する完了イベントハンドラ（例えば、ＢｉｎｄＣｏｍｐｌｅｔｅｄＥｖｅｎｔＨａｎｄｌｅｒなど）の実装を提供する。これらは、関連付けられた完了イベント引数（例えば、ＢｉｎｄＣｏｍｐｌｅｔｅｄＥｖｅｎｔＡｒｇｓ）を受け渡される。これらのオペレーションに対する非同期の進行結果を受け取るために、クライアントはＤｅｐｌｏｙｒｎｅｎｔＰｒｏｇｒｅｓｓＣｈａｎｇｅｄＥｖｅｎｔＨａｎｄｌｅｒの実装を提供する。これは、引数（ＤｅｐｌｏｙｍｅｎｔＰｒｏｇｒｅｓｓＣｈａｎｇｅｄＥｖｅｎｔＡｒｇｓ）を受け渡される。以下に、そのようなイベントハンドラ実装の実施例のスケルトンを示す。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
//イベントハンドラデリゲートおよび引数をバインドする。

public delegate void BindCompletedEventHandler(object
sender, BindCompletedEventArgs e);
public class BindCompletedEventArgs :
AsyncCompletedEventArgs
{
public BindCompletedEventArgs(Exception error, bool
cancelled, object userToken) : base(error, cancelled,
userToken)
{ ... }
}

//DeterminePlatformRequirementsイベントハンドラデリゲートおよび引数。

public delegate void
DeterminePlatformRequirementsCompletedEventHandler(objec
t sender,
DeterminePlatformRequirementsCompletedEventArgs e);
public class
DeterminePlatformRequirementsCompletedEventArgs :
AsyncCompletedEventArgs
{
public
DeterminePlatformRequirementsCompletedEventArgs(Exceptio
n error, bool cancelled, object userToken) : base(error,
cancelled, userToken)
{ ... }
}
//DetermineAuthorizationイベントハンドラデリゲートおよび引数。

public delegate void
DetermineAuthorizationCompletedEventHandler(object
sender, DetermineAuthorizationCompletedEventArgs e);
public class DetermineAuthorizationCompletedEventArgs :
AsyncCompletedEventArgs
{
public
DetermineAuthorizationCompletedEventArgs(Exception
error, bool cancelled, object userToken) : base(error,
cancelled, userToken)
{ ... }
}

//イベントハンドラデリゲートおよび引数を同期処理する。

public delegate void
SynchronizeCompletedEventHandler(object sender,
SynchronizeCompletedEventArgs e);
public class SynchronizeCompletedEventArgs :
AsyncCompletedEventArgs
{
public SynchronizeCompletedEventArgs(Exception
error, bool cancelled, object userToken) : base(error,
cancelled, userToken)
{ ... }
}

//イベントハンドラデリゲートおよび引数を実行する。

public delegate void ExecuteCompletedEventHandler(object
sender, ExecuteCompletedEventArgs e);
public class ExecuteCompletedEventArgs :
AsyncCompletedEventArgs
{
public ExecuteCompletedEventArgs(Exception error,
bool cancelled, object userToken) : base(error,
cancelled, userToken)
{ ... }
}

//DeploymentProgressChangedイベントハンドラデリゲートおよび引数。

public delegate void
DeploymentProgressChangedEventHandler(object sender,
DeploymentProgressChangedEventArgs e);
public class DeploymentProgressChangedEventArgs :
ProgressChangedEventArgs
{
public DeploymentProgressChangedEventArgs(object
userToken, int progressPercentage) : base(userToken,
progressPercentage)
{ ... }
}
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
説明したばかりのメカニズムを呼び出すクライアント（例えば、アプリケーション）の一実装の一般的な実施例を以下に示す。以下の実施例は、上述のＤｅｐｌｏｙｍｅｎｔＭａｎａｇｅｒを実装するクラス（クライアント）に基づくアプリケーションである。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
public class Client
{
public static void Main()
{
DeploymentManager dep = new
DeploymentManager("name=bar, version=1.0.0.0",
"http://www.foo.com/bar.deploy");
dep.DeploymentProgressChanged += new
DeploymentProgressChangedEventHandler(Client.ProgressCha
nged);
dep.BindCompleted += new
BindCompletedEventHandler(Client.BindCompleted);

dep.BindAsync(null);
}
public static void BindCompleted(object sender,
BindCompletedEventArgs e)
{
System.Console.WriteLine(e.ToString());
}
public static void ProgressChanged(object sender,
DeploymentProgressChangedEventArgs e)
{
System.Console.WriteLine(e.ProgressPercentage);
}
}
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
上記の明細、実施例、およびデータは、本発明の実装の構造および使用に関する完全な説明となっている。本発明の多くの実施形態は、本発明の精神と範囲を逸脱することなく実装できるため、本発明は付属の請求項によって定められる。

付録Ａ．サンプルアプリケーションマニフェスト

付録Ｂ．サンプルデプロイメントマニフェスト

本発明の一実施形態で使用できるコンピューティングデバイス例の図である。本発明の実装を具体化できる分散ネットワーキング環境の機能ブロック図概要である。本発明の一実装によりアプリケーションのプログレッシブダウンロードを使用可能にするためＷｅｂブラウジングソフトウェアにより表示できる画面表示である。本発明の一実装による、アプリケーションのプログレッシブインストールのさまざまな状態を例示する状態図である。プログレッシブインストールのスタートアップ状態のプロセスを一般的に例示する論理流れ図である。プログレッシブインストールのデマンド状態のプロセスを一般的に例示する論理流れ図である。プログレッシブインストールのデマンド状態とインストール状態との間で遷移するプロセスを一般的に例示する論理流れ図である。本発明の一実装による、プログレッシブインストールでロードされるファイルを一般的に例示する一連のブロック図である。本発明の一実装による、プログレッシブインストールでロードされるファイルを一般的に例示する一連のブロック図である。本発明の一実装による、プログレッシブインストールでロードされるファイルを一般的に例示する一連のブロック図である。

Claims

アプリケーションに関連するアプリケーションパッケージであって、ユーザによる前記アプリケーションとの対話的操作を可能にするために必要な最小限のコードを含むアプリケーションパッケージを識別するステップと、
前記識別されたアプリケーションパッケージを、ローカルのストアにダウンロードするステップと、
前記ローカルのストアを含むクライアントから前記アプリケーションに関連する複数の追加のリソースのうちの１つに対する要求を受け取ると、前記追加のリソースをダウンロードするステップであって、前記複数の追加のリソースのうちの１つに対する要求は、前記アプリケーションパッケージに含まれたコードを実行する前記クライアントが、対応するユーザの操作に応じて発生させるステップと、
前記アプリケーションをクライアントサイドのアプリケーションに遷移させるための要求を受け取ると、残りのリソースを前記ローカルのストアにダウンロードするステップであって、前記アプリケーションをクライアントサイドのアプリケーションに遷移させるための要求は、対応するユーザの操作なしに作成されるステップと
をコンピュータに実行させることを特徴とするプログラム。
前記アプリケーションパッケージの識別は、前記アプリケーションに関連するハイパーリンクをアクティブにすることを含むことを特徴とする請求項１に記載のプログラム。
前記アプリケーションパッケージの識別は、前記アプリケーションパッケージを識別するマニフェストの検索を開始することを含むことを特徴とする請求項１に記載のプログラム。
前記アプリケーションパッケージはアプリケーションのマニフェストを含むことを特徴とする請求項１に記載のプログラム。
前記アプリケーションパッケージに含まれたコードは実行可能形式であることを特徴とする請求項１に記載のプログラム。
前記アプリケーションに関連するウェブページ上のハイパーリンクをアクティブにすると、前記アプリケーションに関連する追加のリソースをダウンロードするステップをさらにコンピュータに実行させることを特徴とする請求項１に記載のプログラム。
前記追加のリソースはオンデマンドのリソースを含むことを特徴とする請求項６に記載のプログラム。
前記オンデマンドのリソースを前記ローカルのストアに格納するステップをさらにコンピュータに実行させることを特徴とする請求項７に記載のプログラム。
前記アプリケーションを前記クライアントサイドのアプリケーションに遷移させることは、複数の残りのリソースを前記ローカルのストアに格納することを含み、前記複数の残りのリソースは、前記ローカルのストアに現在格納されていないリソースであることを特徴とする請求項１に記載のプログラム。
前記アプリケーションを前記クライアントサイドのアプリケーションに遷移させることは、前記クライアントサイドのアプリケーションがオフラインで起動されたとき、前記クライアントサイドのアプリケーションの実行が前記アプリケーションに関連付けられた状態で再開するように、前記アプリケーションに関連付けられた状態を前記クライアントサイドのアプリケーションに遷移させることを含むことを特徴とする請求項１に記載のプログラム。
前記状態の情報は前記アプリケーションに関連するアプリケーションオブジェクトに格納されることを特徴とする請求項１０に記載のプログラム。
ウェブアプリケーションをクライアントサイドのアプリケーションに遷移させる方法であって、コンピュータのプロセッサが、
アプリケーションに関連するアプリケーションパッケージであって、ユーザのアプリケーションに対する対話的操作を可能にするために必要な最小限のコードを含むアプリケーションパッケージを識別するステップと、
前記識別されたアプリケーションパッケージをローカルのストアにダウンロードするステップと、
前記ローカルのストアを含むクライアントから前記アプリケーションに関連する複数の追加のリソースのうちの１つに対する要求を受け取ると、前記追加のリソースをダウンロードするステップであって、前記複数の追加のリソースのうちの１つに対する要求は、前記アプリケーションパッケージに含まれたコードを実行する前記クライアントが、対応するユーザの操作に応じて発生させるステップと、
前記アプリケーションを前記クライアントサイドのアプリケーションに遷移させるための要求を受け取ると、残りのリソースを前記ローカルのストアにダウンロードするステップであって、前記アプリケーションを前記クライアントサイドのアプリケーションに遷移させるための要求は、対応するユーザの操作なしに作成されるステップと
を含むことを特徴とする方法。
前記アプリケーションを前記クライアントサイドのアプリケーションに遷移させるための要求は、前記ローカルのストアに現在格納されている追加のリソースの数に基づくことを特徴とする請求項１２に記載の方法。
前記アプリケーションの遷移に対する要求は自律的に発生することを特徴とする請求項１３に記載の方法。
前記アプリケーションパッケージはアプリケーションのマニフェストおよびコードを含み、前記アプリケーションのマニフェストは前記アプリケーションに関するリソースのサブセットを一意に識別することを特徴とする請求項１２に記載の方法。
前記プロセッサが、
前記追加のリソースがローカルで利用可能であるかどうかを判断するステップと、利用可能である場合、前記追加のリソースをダウンロードせずに、前記追加のリソースを利用するステップとをさらに含むことを特徴とする請求項１２に記載の方法。
前記残りのリソースは、前記ローカルのストアに現在格納されていない複数の追加のリソースからの追加のサブセットであることを特徴とする請求項１２に記載の方法。
前記アプリケーションを前記クライアントサイドのアプリケーションに遷移させることは、前記クライアントサイドのアプリケーションがオフラインで起動されたとき、前記クライアントサイドのアプリケーションの実行が、遷移したときの前記アプリケーションに関連付けられた状態で再開するように、前記アプリケーションに関する状態を前記クライアントサイドのアプリケーションに遷移させることを含むことを特徴とする請求項１２に記載の方法。