JP5819953B2 - 多数の体験モジュールを含むアプリケーション - Google Patents

Description

[0001] デスクトップ・コンピューター、ワイヤレス・フォン、ゲーム・コンソール等というような、種々の異なるタイプの計算デバイス(computing device)が極普通に入手できるようになっている。アプリケーション開発者は、多くの場合、これら異なるタイプのデバイスの多くにおいて彼らのアプリケーションを実行させて、より多くのユーザーがこれらのアプリケーションを実行できることを望む。しかしながら、このためには、多くの場合、アプリケーション開発者は彼らの成果(effort)の大部分を複製し、これら異なるタイプのデバイス毎に彼らのアプリケーションの異なるバージョンを維持しなければならない。これは、アプリケーション開発者が彼らのアプリケーションの異なるバージョンを多数書いて維持することにかかるコストおよび時間が増大するので、問題となる可能性がある。同時に、アプリケーション開発者は、一部のデバイスにおけるアプリケーションの体験を、他のデバイスに対する制約のために制限する「最小公分母の解決策」(least common denominator solution)を回避することを望む。

[0002] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを簡略化された形式で紹介するために、設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために使用されることを意図するのでもない。

[0003] １つ以上の態様によれば、多数の体験モジュールを含むアプリケーションをデバイス上にインストールする。これら多数の体験モジュールは、各々、アプリケーションがデバイス上で実行しているとき、１組の機構(feature)を実装する。多数の体験モジュールの各々は、個々のタイプのデバイスに専用のコードを含む第１コンポーネントと、多数のタイプのデバイスにわたって共通であるコードを含む第２コンポーネントとを含む。アプリケーションを実行することの要求に応答して、デバイス上でアプリケーションを実行する。

[0004] １つ以上の態様によれば、アプリケーションの異なる体験モジュール毎に異なる更新パッケージのカタログを維持する。アプリケーションは、多数の体験モジュールを含む、アプリケーションがデバイス上で実行しているとき、各体験モジュールは１組の機構を実装する。多数のモジュールの各々は、個々のタイプのデバイスに専用のプレゼンテーション・ロジック(presentation logic)およびリソースを含む第１コンポーネントと、多数のタイプのデバイスにわたって共通であるビジネス・ロジック(business logic)を含む第２コンポーネントとを含む。デバイス上のアプリケーションに適用される更新パッケージがあるか否かについて判断が行われる。デバイス上のアプリケーションに適用される更新パッケージがある場合、この更新パッケージをデバイスに送る。

[0005] 同様の特徴を指すために、図面全体において同じ番号を使用する。

図１は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションを実装することができるシステム例を示す。 図２は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションを実行するデバイス例を示す。 図３は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションをサポートするプラットフォーム例を示す。 図４は、１つ以上の実施形態にしたがってアプリケーションを更新する例を示す。 図５は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションをインストールし、これらの更新パッケージを入手するプロセス例を示すフローチャートである。 図６は、１つ以上の実施形態にしたがって、デバイスに更新をデプロイする（deploy)プロセス例を示すフローチャートである。 図７は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションを実行するように構成することができる計算デバイス例を示す。

[0013] 本明細書では、多数の体験モジュールを含むアプリケーションについて論ずる。多数の体験モジュールを含むアプリケーションを多数の異なるタイプのデバイスに配信し、これらのデバイスにおいて、アプリケーションをインストールし実行する。アプリケーションにおける各体験モジュールは、そのモジュールと関連付けられた体験に合わせて１つ以上で１組とした機構(feature)を実装する。各体験モジュールは、関連付けられた体験に対するビジネス・ロジック（例えば、命令およびデーター）を含む包括ビジネス・ロジック・コンポーネントを含む。この包括ビジネス・ロジック・コンポーネントは、全てのデバイスに共通であり、デバイスのタイプには関係なく、種々のデバイスにインストールするために供給される。また、各体験モジュールは、デバイス・タイプに特定のプレゼンテーション・コンポーネントも含む。このプレゼンテーション・コンポーネントは、関連付けられた体験に対するプレゼンテーション・ロジック（例えば、命令およびデーター）、およびリソース（画像、ユーザー体験レイアウト・マークアップ(layout markup)等のような、体験をユーザーに表示するためのリソース）を含む。異なるタイプのデバイスには異なるタイプのプレゼンテーション・コンポーネントを供給することによって、個々のタイプのデバイス、およびその個々のタイプのデバイスの能力に合わせて、関連付けられた体験のプレゼンテーションを個別に作成することが可能になる。

[0014] また、アプリケーションがインストールされている種々のデバイスに、アプリケーション更新を配信することもできる。アプリケーション配信は、体験モジュール毎であり、したがってアプリケーション全体ではなく、アプリケーションの体験モジュールを更新する。体験モジュールのビジネス・ロジックに対する変更は、デバイスのタイプには関係なく、アプリケーションが実行している全てのデバイスに供給することができる。しかしながら、体験モジュールのプレゼンテーション・コンポーネントに対する変更は、アプリケーションが実行しており、変更されるプレゼンテーション・コンポーネントに対応するタイプのデバイスのみに供給することができる。

[0015] 図１は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションを実装することができるシステム例１００を示す。システム１００は、パーソナル・コンピューター（ＰＣ）、テレビジョン・デバイス、および／または移動体デバイスというような、種々のデバイス上においてアプリケーションを実行するときに、共通のユーザー体験のための環境を可能にする。サービスおよびアプリケーションは、アプリケーションを利用している間、ビデオ・ゲームをプレーしている間、ビデオを見ている間等において、あるデバイスから次のデバイスに移り変わるときに、共通のユーザー体験に対する３つの環境全てにおいて実質的に同様である。

[0016] デバイス１０２は、多数の体験モジュールで構成されているアプリケーションのインストールおよび実行をサポートするアプリケーション・シェル１０４を含む。種々の実施態様において、デバイス１０２は、コンピューター１０６、移動体デバイス１０８、またはテレビジョンに基づくデバイス１１０というような、種々のタイプの計算デバイスとすることができる。これら異なるタイプのデバイスは、一般に異なる構造および能力を有すると考えられ、したがって、デバイス１０２は異なるデバイス・タイプの１つ以上に応じて構成することができる。例えば、デバイス１０２は、パーソナル・コンピューター、デスクトップ・コンピューター、多画面コンピューター、ラップトップ・コンピューター、ノートブック等というような、コンピュー・タイプのデバイス１０６として実現することもできる。

[0017] また、デバイス１０２は、移動体電話機、携帯用音楽プレーヤー、携帯用ゲーミング・デバイス、タブレット・コンピューター、多画面コンピューター等というような、移動体タイプのデバイス１０８として実現することもできる。また、デバイス１０２は、日常的な視聴環境において通常もっと大きな画面を有するまたは接続されているデバイスのような、テレビジョン・タイプのデバイス１１０として実現することもできる。例えば、テレビジョン・タイプのデバイス１１０は、テレビジョン、セットトップ・ボックス、ゲーミング・コンソール等を含むことができる。

[0018] 加えて、デバイス１０２は、家電製品（例えば、冷蔵庫、電子レンジ等）、自動車用ＰＣ、衣服等というような種々の他のタイプのデバイスとして実現することもできる。本明細書において記載する技法は、種々のタイプのデバイス１０２によってサポートすることができ、ここに記載する具体的な例に限定されるのではない。

[0019] システム例１００では、１つ以上の異なるタイプの多数のデバイス１０２が、いずれの所与の時点においてもクラウド１１２と通信することができる。クラウド１１２は、１つ以上のサーバー・コンピューター、および／またはネットワークおよび／または他のデーター通信リンクを通じてデバイス１０２に接続されている他のタイプのデバイスの集合体である。このようなネットワークは、例えば、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、セルラーまたは他の電話ネットワーク、イントラネット、ＷｉＦｉネットワーク、他の公衆ネットワークおよび／または企業固有のネットワーク、その組み合わせ等とすることができる。このような他のデーター通信リンクは、ユニバーサル・シリアル・バス（ＵＳＢ）リンク、ワイヤレスＵＳＢリンク、無線周波（ＲＦ）リンク、他の公衆通信リンクおよび／または企業固有の通信リンク、その組み合わせ等というような、有線リンクおよび／またはワイヤレス・リンクとすることができる。

[0020] 異なるタイプのデバイス１０２は、各々、異なる物理的要件および能力を有する可能性がある。本明細書において論ずる多数の体験モジュールを含むアプリケーションは、デバイス１２０への体験の配信を可能にする。これらの体験は、個々のタイプのデバイスに合わせて特別に用意されるのであると共に、全てのタイプのデバイスに共通である。１つ以上の実施形態では、デバイスのタイプが定義され、包括的なタイプのデバイスに合わせて体験が個別に用意される。デバイスのタイプは、物理的特徴（例えば、表示画面サイズ、プロセッサー・パワー、サポートされているデーター入力メカニズム等）、使用形態、および／またはデバイスの他の共通な特性によって定義することができる。

[0021] クラウド１１２は、１つ以上の体験サービス１１６およびデプロイ・サービス(deployment service)１１８のためのプラットフォーム１１４を表す。プラットフォーム１１４は、クラウド１１２のハードウェア（例えば、サーバー）およびソフトウェア・リソースの基礎的な機能を抽象化する。サービス１１６および１１８は、デバイス１０２によって利用することができるがデバイス１０２から離れているアプリケーションおよび／またはデーターを含むことができる。サービス１１６および１１８は、ネットワークおよび／または先に論じたような他のデーター通信リンク上における１つ以上のサービスとして提供することができる。プラットフォーム１１４は、デバイス１０２を他の計算デバイス）例えば、他のデバイス１０２）に接続するために、リソースおよび機能を抽象化することができる。また、プラットフォーム１１４は、プラットフォーム１１４を通じて実施されるサービス１１６に対して出された（encounter)要求に合わせて、対応する程度の規模(scale)を提供するために、リソースの規模調整(scaling)を抽象化するように機能することもできる。

[0022] 体験サービス１１６は、アプリケーション、および／またはアプリケーションに種々の機能を設けるデーターを含む。設けられる個々の機能は、アプリケーションのタイプに基づいて様々であり、買い物または電子店舗機能、歌または画像（または他のデーター）記憶および／または引き出し機能、検索機能等を含むことができる。デプロイ・サービス１１８は、多数の体験モジュールを含むアプリケーションのデバイス１０２へのデプロイを管理する。ときの経過と共に種々の変更をアプリケーションに対して行うことができ、デプロイ・サービス１１８はこれらの変更のデバイス１０２に対するデプロイも管理する。以下で更に詳しく論ずるように、これらの変更が適用されるデバイス１０２に、当該変更をデプロイする。

[0023] 各アプリケーションは、多数の体験モジュールで構成されており、各体験モジュールは、その体験モジュールと関連付けられた体験またはそれによって提供される体験に対して、１組の１つ以上の機構を実現する。異なる機構とは、アプリケーションの異なる機能を指し、アプリケーションのユーザーによってあるいは他のコンポーネントまたはモジュールによって呼び出すことができる。１つのアプリケーションにおける異なる体験モジュールは、アプリケーションの開発者によって定義され、機構または機能の論理的集合体(grouping)をアプリケーションのユーザーに供給するように定義されるのが一般的である。個々の体験モジュール、および各体験モジュールにおける１組の機構または機能は、アプリケーションの開発者が決定する。

[0024] 一例として、ある特定の移動体デバイスが携帯用音楽プレーヤーおよび携帯用ゲーミング・デバイスの双方として動作することができると仮定する。移動体デバイス上におけるアプリケーションは、音楽再生体験と関連付けられた第１体験モジュールを含むことができ、トランスポート制御（例えば、停止、再生、巻き戻し、シャッフルなどの機構）、プレーリスト選択、および作成機構等というような、音楽再生体験に関する種々の機構を実装する。また、アプリケーションは、ゲーミング体験と関連付けられた第２体験モジュールも含むことができ、ゲーム選択機構、オンライン・ゲーミングのための体験サービス１１６との通信等というような、ゲーミング体験に関する種々の機構を実装する。また、アプリケーションは、市場体験と関連付けられた第３体験モジュールも含むことができ、ユーザーが購入のために歌またはゲームを選択することを可能にする検索およびブラウズ機構、歌またはゲームの購入のためにクレジット・カードまたは他の情報を提供するための体験サービス１１６との通信等というような、ユーザーが新たな歌またはゲームを購入することができるオンライン市場に関する種々の機構を実装する。

[0025] 各体験モジュールは、２つのコンポーネント、即ち、包括ビジネス・ロジック・コンポーネントおよびデバイス・タイプ特定のプレゼンテーション・コンポーネントに分離されている。包括ビジネス・ロジック・コンポーネントは、関連付けられた体験に対するビジネス・ロジック（例えば、コード、即ち、命令およびデーター）を含み、全てのタイプのデバイスにわたって共通である。異なるタイプのデバイス毎に異なる必要がない命令およびデーターは、包括ビジネス・ロジック・コンポーネントに含まれる。包括ビジネス・ロジック・コンポーネントに含まれる個々の命令およびデーターは、個々のアプリケーションに基づいて様々に変化する。例えば、包括ビジネス・ロジック・コンポーネントは、プレーリスト上にある歌をシャッフルするための命令およびデーター、文書内で単語または句を検索するための命令およびデーター、表計算機能を実装するための命令およびデーター等を含むことができる。

[0026] デバイス・タイプ特定のプレゼンテーション・コンポーネントは、関連付けられた体験に対するプレゼンテーション・ロジック（例えば、コード、即ち、命令およびデーター）およびリソース（例えば、画像、ユーザー体験レイアウト・マークアップ等というような体験をユーザーに表示するまたそれ以外で提示するためのリソース）を含む。異なるタイプのデバイスには異なるプレゼンテーション・コンポーネントを提供することができ、アプリケーションの開発者が、個々のタイプのデバイスおよびその個々のタイプのデバイスの能力に合わせて、関連付けられた体験の提示を特別に用意することを可能にする。異なるタイプのデバイス毎に異なるプレゼンテーション・コンポーネントを提供することができるが、同じプレゼンテーション・コンポーネントを異なるタイプのデバイスに提供するという状況が起こる可能性もある。

[0027] １つ以上の実施形態では、プレゼンテーション・ロジックおよびリソースが、個々のタイプのデバイスに合わせて、このタイプのデバイスの物理的特徴（例えば、表示画面サイズ、プロセッサー・パワー、入力および／出力コンポーネント等）に基づいて、関連付けられた体験の提示を特別に用意する。例えば、データー入力のために大型画面および大型キーボードを通例有するコンピューター・タイプのデバイス１０６に合わせて、第１プレゼンテーション・ロジックおよびリソースを特別に用意することができる。この第１プレゼンテーション・ロジックおよびリソースは、データーを表示する大きなウィンドウおよび／またはフレーム、キーボードまたはマウスによる種々の異なるユーザー入力等をサポートするユーザー・インターフェース（ＵＩ）を含むことができる。第２プレゼンテーション・ロジックおよびリソースは、データー入力のために小型画面を通例有し、任意に小さなキーボードを有する移動体タイプのデバイス１０８に合わせて特別に用意することができる。この第２プレゼンテーション・ロジックおよびリソースは、データーを表示する小さいウィンドウおよび／またはフレーム、マイクロフォン（例えば、音声コマンド）またはタッチスクリーンによる種々の異なるユーザー入力等をサポートするＵＩを含むことができる。第３プレゼンテーション・ロジックおよびリソースは、通例非常に大型の画面を有するがデーター入力のためのキーボードを有していないテレビジョン・タイプのデバイス１１０に合わせて特別に用意することができる。この第３プレゼンテーション・ロジックおよびリソースは、データーを表示する大きなウィンドウおよび／またはフレーム、ハンドヘルド・リモコンまたはハンドヘルド・ゲーム・コントローラによる種々の異なるユーザー入力等をサポートするＵＩを含むことができる。

[0028] 尚、本明細書において論ずるアプリケーションは、単にデバイス１０２にダウンロードしウェブ・ブラウザーにおいて実行するウェブ・アプリケーションだけではないことは注記してしかるべきである。逆に、本明細書において論ずるアプリケーションは、種々の環境においてクラウド１１２からデバイス１０２にデプロイおよびインストールされる。また、アプリケーションに対する種々の更新も、クラウド１１２からデバイス１０２にデプロイおよびインストールすることができる。更に、本明細書において論ずるアプリケーションは、デバイス１０２がクラウド１１２に接続されていないときに実行することができる（しかし、オンライン市場にアクセスするというような一部の機能は、デバイス１０２がクラウド１１２に接続されていないときには、デバイス１０２には利用可能ではあり得ない）。加えて、本明細書において論ずるアプリケーションにおける異なる体験の提示は、そのアプリケーションが実行するデバイスの個々のタイプに合わせて特別に用意される。

[0029] 図２は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションを実行するデバイス例２００を示す。デバイス２００は、種々の異なるタイプの計算デバイスとすることができ、例えば、図１のデバイス１０２である。

[0030] デバイス２００は、アプリケーション・シェル２０２およびオペレーティング・システム２０４を含む。オペレーティング・システム２０４は、ワシントン州RedmondのMicrosoft Corp.（マイクロソフト社）から入手可能なオペレーティング・システムのWindows（登録商標）オペレーティング・システム・ファミリーのいずれか、カリフォルニア州CupertinoのApple Corporation（アップル社）から入手可能なオペレーティング・システムのMac OS（登録商標）オペレーティング・システム・ソフトウェア・ファミリーのいずれか、Linux（登録商標）系オペレーティング・システム、Google Chrome系オペレーティング・システム、電話系オペレーティング・システム、携帯用ゲーミング・デバイス系オペレーティング・システム、セットトップ・ボックス系オペレーティング・システム等というような、種々の従来からのオペレーティング・システムのいずれでも可能である。多数の体験モジュールを含むアプリケーションをサポートするために、オペレーティング・システム２０４によってアプリケーション・シェル２０２を実行する。あるいは、アプリケーション・シェル２０２をオペレーティング・システム２０４の一部として含めることもでき、またはオペレーティング・システム２０４をアプリケーション・シェル２０２の一部として含めることもできる。また、１つ以上の追加のアプリケーションまたはシェル（図示せず）をオペレーティング・システム２０４によって実行することもできる。

[0031] アプリケーション・シェル２０２は、本明細書において論ずる多数の体験モジュールを含むアプリケーションをサポートする。図示した例では、アプリケーション２１８は、シェル２０２に含まれるものとして、またはシェル２０２において実行するものとして示されている。１つのアプリケーション２１８がシェル２０２において実行することが示されているが、多数のアプリケーションをシェル２０２において同時に実行できることは認められてしかるべきである。加えて、１つのアプリケーション・シェル２０２を示すが、多数のアプリケーション・シェル２０２（各々０個以上のアプリケーションを実行する）をデバイス２００上において同時に実行できることも認められてしかるべきである。

[0032] アプリケーション２１８は、多数の（ｎ個）体験モジュール２２０（１）、...、２２０（ｎ）を含み、各体験モジュールは異なる体験と関連付けられている。１つ以上の実施形態では、多数の体験モジュール２２０の集合体がアプリケーション２１８となり、体験モジュール２２０以外には、他の追加のコンポーネントやモジュールはアプリケーション２１８には含まれない。つまり、このような実施形態では、体験モジュール２２０は、シェル２０２において実行する個別モジュールとすることができ、これらがまとまってアプリケーションとなる。

[0033] シェル２０２は、デバイス／サービス通信フレームワーク２１２、体験ストレージ２１４、およびコア・コンポーネント・インターフェース２１６を含む。尚、デバイス／サービス通信フレームワーク２１２およびコア・コンポーネント・インターフェース２１６の機能は、１つのコンポーネントまたはモジュールとして、または別個のコンポーネントまたはモジュールとして実装できることは認められてしかるべきである。また、デバイス／サービス通信フレームワーク２１２およびコア・コンポーネント・インターフェース２１６の内一方または双方の機能は、多数のコンポーネントまたはモジュールとして実装できることも認められてしかるべきである。

[0034] デバイス／サービス通信フレームワーク２１２は、デバイス２００とクラウド（例えば、図１のクラウド１１２）との間における通信を管理する。アプリケーション２１８のコンポーネントは、デバイス／サービス通信フレームワーク２１２に要求を送ることによって、および／またはデバイス／サービス通信フレームワーク２１２から応答または他の情報を受信することによって、クラウドと通信することができる。デバイス／サービス通信フレームワークは、種々のしかるべき設定およびプロトコルで構成され、またそうでなければこれらにアクセスすることができ、デバイス２００がクラウドと通信することを可能にする。つまり、アプリケーション２１８は、クラウドとの通信を管理する負担が軽減されている。代わりに、アプリケーション２１８のコンポーネントは、デバイス／サービス通信フレームワーク２１２によって露出される標準的なインターフェース（例えば、アプリケーション・プログラミング・インターフェース（ＡＰＩ））を呼び出すことができる。異なるタイプのデバイス上における異なるデバイス／サービス通信フレームワーク２１２は、異なるやり方で動作してクラウドと通信することができるが、それでもなお同じインターフェースをアプリケーションに提供することができる。アプリケーションの開発者は、これらのアプリケーションが実行するデバイスがクラウドとどのように通信するかについて具体的な知識を必要とせずに、アプリケーションを書くことができる。

[0035] 体験ストレージ２１４は、アプリケーション２１８に対するコンポーネントのストレージを管理する。アプリケーションは、クラウド（例えば、図１のクラウド１１２）からデバイス２００にデプロイされる。各アプリケーションは、多数のユーザー体験モジュールを含み、各ユーザー体験モジュールは、先に論じたような、多数のコンポーネントを含む。アプリケーションをデプロイすると、これらの種々のコンポーネントがデバイス／サービス通信フレームワーク２１２によって受け取られ、体験ストレージ２１４に供給される。体験ストレージ２１４は、受け取ったコンポーネントを不揮発性メモリー（例えば、磁気ディスク、光ディスク、フラッシュ・メモリー等）に格納する。

[0036] デバイス２００にアプリケーション２１８を最初にインストールするとき、デバイス２００のコンポーネント（例えば、以下で論ずるコア・コンポーネント・インターフェース２１６）がインストールを実行する。アプリケーション２１８のインストールには、個々のファイルを記憶デバイスの特定の位置に書き込む、情報を登録ストレージ（例えば、オペレーティング・システムのレジストリー）に追加する等というような、種々のインストール動作(action)が含まれる。ファイルは、体験ストレージ２１４および／またはデバイス２００の他の記憶デバイスに書き込むことができる。インストールの後、シェル２０２においてアプリケーション２１８を実行することができる。また、アプリケーション２１８の新たなバージョンが入手可能になったとき、アプリケーション２１８を後から更新することもできる。これについては、以下で更に詳しく論ずる。

[0037] アプリケーション２１８は、デバイス２００のユーザーから受けた要求に応答して実行することができ、あるいは他のコンポーネント、モジュール、またはデバイスからの要求に応答して実行することができる。アプリケーション２１８を実行する要求に応答して、シェル２０２は、体験ストレージ２１４および／またはデバイス２００の他の記憶デバイスから、アプリケーション２１８のためにインストールされたファイルを入手して、入手したコンポーネントを実行する。例えば、体験ストレージ２１４によって維持されているファイルまたは他の情報において、入手および実行すべき特定のコンポーネントを識別することができる。

[0038] １つ以上の実施形態では、コンポーネント２１８の多数のバージョンが体験ストレージ２１４に含まれる。例えば、コンポーネントの更新バージョンは、更新パッケージの形態で、デバイス／サービス通信フレームワーク２１２によって受信することができる。これについては、以下で更に詳しく論ずる。更新パッケージをインストールすると、デバイス２００上にコンポーネントの新たなバージョンが得られる。以前にデプロイされていたコンポーネントおよびいずれの更新パッケージも体験ストレージ２１４内に維持されるので、コンポーネントの更新バージョンおよび以前のバージョンは双方共体験ストレージ２１４に維持される。コンポーネントの以前のバージョンを維持することによって、例えば、アプリケーション２１８の以前のバージョンにロール・バック(roll back)する、即ち、戻ること、アプリケーション２１８に対する変更の記録を付けること等が可能になる。体験ストレージ２１４は、任意に、特定の時間量が経過した後、コンポーネントに対する特定数の更新パッケージがその後体験ストレージ２１４に格納された後等というような、種々の規準に基づいて、以前のバージョンのコンポーネントを削除することができる。

[0039] アプリケーション２１８に含まれている異なる体験モジュールの指示、およびこれらの体験モジュールのバージョン番号も、体験ストレージ２１４に維持される。これらのバージョン番号は、デバイス２００上にインストールされている体験モジュールの現在のバージョンを特定し、これらの体験モジュールにおいて新たなバージョンのコンポーネントがデバイス２００上にインストールされると更新される。体験ストレージ２１４には、アプリケーションのマスター・バージョン番号も維持することができる。マスター・バージョン番号は、デバイス上にインストールされているアプリケーション２１８の現在のバージョンを特定し、アプリケーション２１８の体験モジュールにおけるコンポーネントの新たなバージョンがデバイス２００上にインストールされる毎に更新される。

[0040] コア・コンポーネント・インターフェース２１６は、オペレーティング・システム２０４および他のデバイス２００との通信を管理し、シェル２０２内における種々の通信に関する種々のデーターを維持し、種々の通信をサポートする。１つ以上の実施形態では、コア・コンポーネント・インターフェース２１６は、デバイス／サービス通信フレームワーク２１２がクラウドに送った要求の結果を格納するデーター・キャッシュを維持する。このデーター・キャッシュは、一時的に維持することができ（例えば、アプリケーション２１８またはシェル２０２が実行している間）、あるいは不揮発性メモリーにもっと長い期間存続させることもできる。

[0041] 加えて、１つ以上の実施形態では、コア・コンポーネント・インターフェース２１６は、デバイス特定コマンドを抽象化するプレゼンテーション・フレームワークを含む。異なるタイプのデバイス、そして同じタイプの異なるデバイスであっても（デバイスの異なるモデル、異なる製造業者からのデバイス等というような）、異なるやり方で特定のプレゼンテーション機能を実装することができる。インターフェース２１６のプレゼンテーション・フレームワークは、特定のプレゼンテーション機能を実装するやり方を抽象化し、標準的なインターフェース（例えば、ＡＰＩ）をアプリケーション２１８のコンポーネントに提供する。このため、アプリケーションのコンポーネントは、コア・コンポーネント・インターフェース２１６によって露出される標準的なインターフェースを呼び出すことができ、アプリケーションの開発者は、特定のプレゼンテーション・コマンドまたは情報が、アプリケーションが実行しているデバイスの特定のハードウェアにどのようにして伝達されるかについて具体的な知識を必要とせずに、アプリケーションを書くことが可能になる。１つ以上の実施形態では、プレゼンテーション・フレームワークは、ワシントン州RedmondのMicrosoft Corp.から入手可能なSilverlight（登録商標）プラットフォームとすることができる。

[0042] アプリケーション２１８は、多数（ｎ）の体験モジュール２２０（１）、...、２２０（ｎ）を含み、各々が異なる体験と関連付けられている。これらの異なる体験は、先に論じたような、異なる１組の機構を含む。加えて、各体験モジュール２２０は、デバイス・タイプ専用プレゼンテーション・コンポーネント２２２および包括ビジネス・ロジック・コンポーネント２２４の双方を含む。包括ビジネス・ロジック・コンポーネント２２４は、関連付けられた体験に対するビジネス・ロジック（例えば、命令およびデーター）を含み、先に論じたような全てのタイプのデバイスにわたって共通である。デバイス・タイプ専用プレゼンテーション・コンポーネント２２２は、関連付けられた体験に対するプレゼンテーション・ロジック（例えば、命令およびデーター）およびリソース（例えば、画像、ユーザー体験レイアウト・マークアップ等というような、体験をユーザーに表示するまたそれ以外で提示するためのリソース）を含み、これらは、デバイス２００のタイプに専用であることができ、またはデバイス２００のタイプに合わせて特別に用意することができる。

[0043] １つ以上の実施形態では、アプリケーション・シェル２０２は、体験モジュール２２０が互いに分離されるように、コンポーネント２２２および２２４の実行を（例えば、コア・コンポーネント・インターフェース２１６を通じて）管理する。この分離によって、１つの体験モジュール２２０におけるコンポーネントが他の体験モジュール２２０のコンポーネント（または、コンポーネントが使用する汎用メモリー空間）に直接アクセスすることを防止する。また、この分離は、サンドボクシング(sandboxing)と呼ぶこともでき、シェル２０２によって種々の異なる従来のやり方で実現することができる。

[0044] 体験モジュール２２０は互いに直接アクセスすることが禁止されているが、１つ以上の実施形態では、コア・コンポーネント・インターフェース２１６が体験間相互作用モジュール(cross-experience interaction module)２２６を含み、１つの分離された体験の中では不可能な、もっと豊富な機能を可能にするように、体験間相互作用をサポートする。体験間相互作用モジュール２２６はインターフェースを設け、これを通じて、１つの体験モジュール２２０が他の体験モジュール２２０にメッセージを送ることができる。このようなメッセージは、例えば、動作の要求、０個以上のパラメーター、およびメッセージを送るべき先である体験の指示を含む。パラメーターは、通例、データーへのポインターまたはデーターの他の識別子（特定の歌の題名へのポインター、特定のムービー・データーへのポインター等）を含むが、代わりに実際のデーター（例えば、歌の題名、ムービー・データー等）を含むこともできる。例えば、１つの体験モジュール２２０が、コンテンツ・ライブラリー体験モジュールであって、ユーザーが彼または彼女のライブラリー（例えば、歌あるいは他のオーディオおよび／またはビデオ・コンテンツのライブラリー）から特定のコンテンツを維持および選択することを可能にするコンテンツ・ライブラリー体験を提供するのであってもよく、一方他の体験モジュールが、コンテンツ再生体験モジュールであって、特定のコンテンツの再生を可能にするコンテンツ再生体験を提供するのであってもよい。コンテンツ・ライブラリー体験モジュールは、再生のためにユーザーが選択する特定のコンテンツのメディア項目識別子であるパラメーターを有する「歌演奏」(play song)メッセージをコンテンツ再生体験モジュールに送ることができる。

[0045] 加えて、１つ以上の実施形態では、体験モジュール２２０は、体験間相互作用モジュール２２６に、体験モジュール２２０が実行することができる動作のタイプを示すように登録することもできる。この登録は、例えば、体験モジュール２２０が実行することができる、潜在的に要求される可能性がある動作のリストを含む。他の体験モジュール２２０は、体験間相互作用モジュール２２６に問い合わせて、どの要求された動作をどの体験モジュール２２０によって実行できるか特定することができ、こうして、個々の要求された動作を実行させるためには、どの体験モジュール２２０に個々のメッセージを送ればよいか知ることができる。あるいは、いずれの所与の要求された動作についても、１つの体験モジュール２２０のみがその動作を実行できることを、体験間相互作用モジュール２２６に登録するのでもよい。したがって、他の体験モジュール２２０がその動作を実行させたい場合、その特定の動作を要求するメッセージを（しかるべきパラメーターと共に）体験間相互作用モジュール２２６に送ることができる。体験間相互作用モジュール２２６は、要求された動作を実行することが登録されているのはどの体験モジュール２２０か把握しており、メッセージをその体験モジュール２２０に供給する。

[0046] １つ以上の実施形態では、体験間相互作用モジュール２２６は、要求元の体験モジュール２２０に応答メッセージを返送することもサポートする（特定の動作を要求するメッセージを発信した元である体験モジュール２２０）。この応答メッセージは、例えば、要求されたデーター、動作が実行されたことの確認等を含むことができる。応答メッセージを送る応答側の体験モジュール２２０は、この応答メッセージを送るべき要求元の体験モジュール２２０を特定することができる（例えば、要求元の体験モジュール２２０の指示が、体験間相互作用モジュール２２６によって当該体験モジュールに供給された場合）。あるいは、体験間相互作用モジュール２２６が、送られたメッセージの記録を維持し、応答側の体験モジュールがどの体験モジュール２２０が要求元の体験モジュール２２０であるか知ることなく、応答メッセージを要求元の体験モジュール２２０に転送することもできる。

[0047] 体験モジュール２２０が受信したメッセージを理解できないという状況が発生することもあり得る。例えば、受信側の体験モジュール２２０が実行しない（またはしようとしない）動作を要求することがあり、受信側の体験モジュールが、その動作をサポートしない古いバージョンであること等もあり得る。このような状況では、受信側体験モジュール２２０は単にそのメッセージを無視することができる。あるいは、受信側体験モジュール２２０は、応答メッセージ、または要求された動作が実行されなかったことの指示を返送することができる。

[0048] １つ以上の実施形態では、体験モジュール２２０は、互いにメッセージを送り合う際に、ユニフォーム・リソース・ロケーター（ＵＲＬ）に基づくプロトコルを採用する。メッセージを送ろうとする先の体験モジュール２２０、要求された動作、およびパラメーターを、ＵＲＬに埋め込む。このＵＲＬの記録は、メッセージを送る体験モジュール２２０が保持することができ、メッセージの履歴を維持することができ、実行取り消し(undo)コマンドおよび／または再実行コマンドを含むメッセージを体験モジュール２２０に送ることができる等である。

[0049] 加えて、１つ以上の実施形態では、コア・コンポーネント・インターフェース２１６は、デバイス間通信をサポートし、デバイス２００が１つ以上の他のデバイスと通信することが可能になる。例えば、デバイス間通信によって、図１の異なるデバイス１０２同士が互いに通信することが可能になる。デバイス間通信は、先に論じたクラウド（例えば、図１のクラウド１１２）との通信と同じように、種々の異なるネットワークまたは通信リンクを跨いで実行することができる。

[0050] コア・コンポーネント・インターフェース２１６は、異なるやり方でデバイス間通信をサポートすることができる。１つ以上の実施形態では、コア・コンポーネント・インターフェース２１６は、相互作用モジュールを含む。相互作用モジュールは、デバイス／サービス通信フレームワーク２１２がクラウド（例えば、図１のクラウド１１２）と通信するのと同様のやり方で、他のデバイスとの通信をサポートする。コア・コンポーネント・インターフェース２１６は、先に論じたフレームワーク２１２によって露出されるインターフェースと同様の標準インターフェースを露出し、アプリケーション２１８のコンポーネントがこの標準インターフェースを呼び出すことができる。あるいは、１つのインターフェースを露出することができ（例えば、フレームワーク２１２によって）、アプリケーション２１８のコンポーネントからの、他のデバイスにアクセスする要求は、クラウドに導かれるのではなく、フレームワーク２１２によってコア・コンポーネント・インターフェース２１６に導かれる。

[0051] つまり、他のデバイスに通信を送ることを望むアプリケーション２１８のコンポーネントが、フレームワーク２１２を通じてクラウドに通信を送るのと同様のやり方で通信を送り、その他のデバイスから、フレームワーク２１２を通じてクラウドから通信を受信するのと同様のやり方で応答を受信することができ、他のデバイスと通信するために用いられる種々の設定および／またはプロトコルに関与する必要はない。代わりに、コア・コンポーネント・インターフェース２１６には、他のデバイスと通信するために用いられるこのような設定および／またはプロトコルが組み込まれており(configure)、またそうでなければこれらにアクセスすることができる。また、コア・コンポーネント・インターフェース２１６は、デバイス２００が通信することができる他のデバイス２００を特定するように構成されている。他のデバイスは、従来のBluetooth（登録商標）デバイス発見技法を用いる、照合サービス（例えば、図１の体験サービス１１６によって設けられる）を用いる等というような、種々の異なるやり方で特定することができる。

[0052] 本明細書では、アプリケーション２１８に対する更新に関する種々の論述が含まれるが、デバイス２００の他のコンポーネントまたはモジュールも更新できることは認められてしかるべきである。例えば、シェル２０２を更新することができる。デバイス２００のこのような他のコンポーネントまたはモジュールに対する更新は、本明細書において論ずるアプリケーション２１８を更新する技法と同様の技法を用いる、または他の技法を用いるというような、種々のやり方で供給し、デバイス２００上で行うことができる。

[0053] 図３は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションをサポートするプラットフォーム例３００を示す。プラットフォーム３００は、例えば、図１のプラットフォーム１１４とすることができる。プラットフォーム３００は、種々の異なるタイプのサービス、または種々のソフトウェアを実行する他の計算デバイスの内１つ以上を用いて実装することができる。

[0054] プラットフォーム３００は、アプリケーション・インターフェース３０２、１つ以上の体験特定サービス３０４、およびデプロイ・サービス３０６を含む。アプリケーション・インターフェース３０２は、プラットフォーム３００によって露出されるインターフェース（例えば、ＡＰＩ）であり、デバイス（例えば、図１のデバイス１０２または図２のデバイス２００）上で実行するアプリケーションがプラットフォーム３００と通信すること可能にする。１つ以上の実施形態において、図２のデバイス２００のデバイス／サービス通信フレームワーク２１２は、アプリケーション・インターフェース３０２を呼び出すことによって、プラットフォーム３００と通信する。デバイスは、アクセス体験特定サービス３０４および／またはデプロイ・サービス３０６に、アプリケーション・インターフェース３０２を通じてアクセスする。

[0055] 体験特定サービス３０４は、例えば、図１の体験サービス１１６である。体験特定サービス１１６はアプリケーションおよび／またはこのアプリケーションに種々の機能を設けるデーターを含む。設けられる個々の機能は、サービス３０４が機能を設けるアプリケーションのタイプに基づいて様々である。例えば、体験特定サービス３０４によって設けられる個々の機能は、買い物または電子店舗機能、歌または画像（または他のデーター）記憶および／または引き出し機能、検索機能、オンライン・ゲーミングのための友人または仲間との対決(matching)、ソーシャル・ネットワーク交流機能等を含むことができる。

[0056] デプロイ・サービス３０６は、アプリケーションのデバイス（例えば、図１のデバイス１０２または図２のデバイス２００）へのデプロイを管理する。アプリケーションのデバイスへのデプロイには、アプリケーションの初期デプロイ（例えば、アプリケーションを最初にデバイスにインストールするとき）が含まれる。また、アプリケーションのデバイスへのデプロイには、デバイスにインストールされているアプリケーションに変更をデプロイすることも含まれる。あるいは、デバイスに最初にインストールするアプリケーションは、光ディスク（例えば、ＤＶＤまたはＣＤＲＯＭ）から、他のデバイスから等というように、他のやり方で入手することもできる。しかしながら、デバイス上における初期インストールのために、デプロイ・サービス３０６以外からアプリケーションを入手する場合であっても、デプロイ・サービス３０６はその後このアプリケーションに対する変更のデプロイを管理する。

[0057] アプリケーションの開発者は、種々の理由から、種々の時点においてアプリケーションを変更することを望む可能性がある。例えば、開発者は、新たな機能をアプリケーションに追加する、アプリケーションにおいて発見された問題を解決する、特定のタイプのデバイス上においてアプリケーションによって情報を提示するやり方を変更する（例えば、ユーザー・フィードバックによって）等を望むこともあり得る。これらの変更は、アプリケーションに対する非常に重要な変更から、アプリケーションに対する非常に些細な変更までの範囲を取り得る。

[0058] 開発者がアプリケーションを変更するとき、開発者はそのアプリケーションの１つ以上の体験モジュールの１つ以上のコンポーネントを変更し、その結果新たなバージョンの体験モジュールが得られる。開発者は、通例、アプリケーション全体を変更する必要はない。代わりに、所望の変更による影響を受ける体験モジュールのみを変更すればよい。例えば、１０個の体験モジュールを含むアプリケーションの内１つの体験モジュールだけに影響を及ぼす変更を行うことを望む場合、その１つの体験モジュールの新たなバージョンだけを生成し、デバイスにデプロイすればよい。

[0059] １つ以上の実施形態では、体験モジュールにおけるコンポーネントへの変更をデプロイするには、変更する体験モジュールに対する更新パッケージを、アプリケーションをインストールしその変更を適用するデバイスに送る。更新パッケージは、体験モジュールに対する１つ以上の交換コンポーネントを含ませる、コンポーネントに対する１つ以上の変更の指示（例えば、新たなバージョンのコンポーネントと以前のバージョンのコンポーネントとの間の相違のリスト）を含ませること等によって、異なるやり方で変更を特定することができる。また、更新パッケージは、アプリケーションに追加する新たな体験モジュールの新たなコンポーネントも含むことができる。

[0060] 開発者がアプリケーションを変更するために新たな更新パッケージを作成するとき、開発者は新たな更新パッケージをプラットフォーム３００に供給する。デプロイ(deployment)３０６は、更新パッケージが格納されている更新レポジトリー３１２を含む。また、更新パッケージの以前のバージョンも更新レポジトリー３１２に維持し、その結果、体験モジュールの多数の異なるバージョンの更新パッケージを、更新レポジトリー３１２に含めることができる。

[0061] デバイス更新コンポーネント３１４は、更新レポジトリー３１２を管理し、そして適した更新パッケージを適したデバイスに供給する。デバイス更新コンポーネント３１４は、更新パッケージの以前の全てのバージョンを維持することができ、あるいは種々の規準に基づいて更新パッケージの以前のバージョンを削除することができる。例えば、デバイス更新コンポーネント３１４は、特定の時間量が経過した後、同じコンポーネントに対して特定数の更新パッケージがその後更新レポジトリー３１２に格納された後等に、以前の更新パッケージを削除することができる。

[0062] また、デバイス更新コンポーネント３１４は、種々の更新パッケージを記述する情報をバージョン・カタログ３１６に維持する。バージョン・カタログ３１６は、更新レポジトリー３１２に格納されている更新パッケージに関する種々の情報を特定する、表またはリストのような、種々の異なるデーター構造とすることができる。バージョン・カタログ３１６は、デバイス更新コンポーネント３１４が、デバイスから受信したバージョン番号の指示に基づいて、更新レポジトリー３１２に格納されている更新パッケージ（ある場合）の内どれをそのデバイスにデプロイすべきか決定することを可能にする。１つ以上の実施形態では、バージョン・カタログ３１６は、アプリケーション毎に異なる表を含み、あるいは多数のアプリケーションに同じ表を用いることもでき、表におけるどの情報がどのアプリケーションに対応するかという指示を含むことができる。

[0063] 尚、体験モジュールに対する変更の中には、アプリケーションがインストールされている全てのタイプのデバイスに適用できない場合もあることは、注記してしかるべきである。例えば、デバイス特定プレゼンテーション・コンポーネントに対する変更は、ある特定のタイプのデバイスには行ってもよいが、他のタイプのデバイスには行わないのでもよい。したがって、体験モジュールに対する変更は、その特定の一タイプには適用するが、他のタイプのデバイスには適用しない。

[0064] １つ以上の実施形態では、バージョン・カタログ３１６は、デバイス上にインストールされている（またはインストールすることができる）アプリケーション毎に表またはリストを含み、このような各表は１つ以上のレコードを含む。各レコードは、更新レポジトリー３１２に格納されている個々の更新パッケージに対応する。バージョン・カタログ３１６内におけるレコードに対応する個々の更新パッケージは、異なるやり方で識別することができる。１つ以上の実施形態では、各レコードは、少なくとも、体験モジュール識別子、マスター・バージョン番号、およびデバイス・タイプを含む。また、更新レポジトリー３１２は、体験モジュール識別子、マスター・バージョン番号、およびデバイス・タイプがキーに設定されて(keyed)おり、バージョン・カタログ３１６および更新レポジトリー３１２におけるレコード間の対応を維持する。

[0065] 表１は、１つ以上の実施形態にしたがって、バージョン・カタログ３１６のレコードに含まれている情報の一例を示す。尚、表１は一例であり、代わりに、異なる情報をバージョン・カタログ３１６のレコードに含めることもでき、および／または表１に含まれている情報の一部がバージョン・カタログ３１６のレコードに含まれていなくてもよいことは注記してしかるべきである。

[0066] アプリケーションのマスター・バージョン番号は、そのアプリケーションの新たなバージョンが出る毎に増大する。これは、アプリケーションに対する新たな更新パッケージが更新レポジトリー３１２に追加される毎にと言うこともできる。デバイス更新コンポーネント３１４が、デバイス上にインストールされているアプリケーションの現バージョンの指示を受信すると、デバイス更新コンポーネント３１４は、受信したバージョンを、バージョン・カタログ３１６におけるアプリケーションの最新マスター・バージョン番号と比較する。２つのバージョン番号が同じである場合、デバイスにデプロイする新たな更新パッケージはないことになる。しかしながら、２つのバージョン番号が同じでない場合、新たなバージョンのアプリケーションが存在するので、デバイス更新コンポーネント３１４は、デバイスにデプロイすべき１つ以上の更新パッケージがあるか否か判断する。

[0067] 体験識別子は、アプリケーションに含まれている多数の体験モジュールの内どれを、更新パッケージが変更するかを示す。通例、１つの異なる更新パッケージは、１つの体験モジュールに対する変更を含むが、代わりに、１つの更新パッケージが多数の体験モジュールに対する変更を含むこともできる。

[0068] 体験バージョン番号は、体験モジュールに対する変更がある毎に増大する。したがって、体験モジュールの体験バージョン番号は、その体験モジュールに新たな更新パッケージができる毎に増大する。つまり、マスター・バージョン番号は、アプリケーションに含まれている体験モジュールのいずれかに変更がある毎に増大するが、体験バージョン番号は、体験識別子によって識別された体験モジュールに変更があるときにのみ増大する。新たな体験モジュールが更新パッケージによって追加された場合、体験バージョン番号は特定の値（例えば、１の値）を有することができる。

[0069] 即座更新欄(field)は、対応する更新パッケージのインストールを即座に行うべきか、または遅らせることができるかを示す。アプリケーションの開発者は、対応する更新パッケージのインストールを直ちに行うべきか、または遅らせることができるか指示し、この指示が、その特定の更新パッケージに対応するレコードの即座更新欄として追加される。

[0070] 先に論じたように、全ての更新パッケージが全てのデバイスに適用されるとは限らない。したがって、バージョン・カタログ３１６におけるアプリケーションのマスター・バージョン番号が、特定のデバイスにインストールされているアプリケーションの現バージョンと異なっていても、そのアプリケーションのもっと新しいバージョンが、その特定のデバイスには適用されないこともあり得る。デバイス更新コンポーネント３１４は、デバイス・タイプ・マスク、ユーザー識別子、およびロカール識別子の内１つ以上に基づいて、更新パッケージが特定のデバイスに適用されるか否か判断する。ユーザー識別子およびロカール識別子は、任意に、特定のデバイスのユーザーがオプトインに設定している（またはオプトアウトに設定していない）場合にのみ、更新パッケージがこのデバイスに適用され、彼または彼女のユーザー識別子および／またはロカール識別子がこのように用いられるのを許可するか否か判断するために用いることができる。

[0071] デバイス・タイプ・マスクは、更新パッケージが適用されるデバイスの１つ以上のタイプを示す。アプリケーションの開発者は、特定の更新パッケージが適用されるデバイスのタイプを示し、この指示が、その特定の更新パッケージに対応するレコードのデバイス・タイプ・マスクとして追加される。

[0072] 同様に、ユーザー識別子は、更新パッケージが適用される１人以上のユーザーを示す。アプリケーションの開発者は、例えば、アプリケーションの異なる２つのバージョンを試験することを望むこともある。開発者は、２つの異なるバージョンで２つの更新パッケージを作成し、どのユーザーがどのバージョンを受け取るかを示し、この指示が、対応するレコードのユーザー識別子欄に追加される。ユーザーは、例えば、そのユーザーに付随するユーザー名（例えば、ユーザーがログイン情報をプラットフォーム３００に提供してある場合）、デバイスの識別子または物理的特徴等によって識別することができる。あるいは、何人かのユーザーが、特定のアプリケーションの検査人(tester)になるためにサインアップすることもできる。デバイス更新コンポーネント３１４は、特定のデバイスのユーザーが検査人になるためにサインアップしたか否かの指示を受け取る（例えば、デバイス自体から、プラットフォーム３００の他のコンポーネントまたはモジュールから等）。次いで、ユーザー識別子は、デバイスのユーザーの識別子に基づいて、対応する更新パッケージがそのデバイスに適用されるか否か示すことができる。

[0073] ロカール識別子は、更新パッケージが適用されるデバイスの１つ以上の位置を示す。アプリケーションの開発者が、他の地理的位置または境界に基づいて、あるいは他の位置に基づく境界に基づいて、例えば、異なる国毎、異なる州毎に異なるバージョンのアプリケーションを有することを望むこともあり得る。開発者は、異なるバージョンで異なる更新パッケージを作成し、どのデバイス位置(device location)がどのバージョンを受けるべきかを示し、この指示を対応するレコードのロカール識別子欄(locale identifier field)に追加する。デバイス更新コンポーネント３１４は、特定のデバイスの位置の指示を受け取る（例えば、デバイス自体から、プラットフォーム３００の他のコンポーネントまたはモジュールから等）。次いで、ロカール識別子は、デバイスの位置に基づいて、対応する更新パッケージがそのデバイスに適用されるか否か示すことができる。

[0074] デバイス更新コンポーネント３１４は、種々の異なるイベントに応答して、および／または種々の異なる時点において、アプリケーションがインストールされているデバイスに、１つ以上の更新パッケージを送ることができる。１つ以上の実施形態では、デバイスのコア・コンポーネント・インターフェース（例えば、図２のコア・コンポーネント・インターフェース２１６）は、規則的な間隔または不規則な間隔で（例えば、毎日）、アプリケーションが実行し始めたとき、アプリケーションの実行が終了したとき、デバイスにインストールされているアプリケーションが要求をプラットフォーム３００に提出したとき等に、デプロイ・サービス３０６にアクセスするために、更新チェック要求を送るように構成されている。

[0075] デバイスによって送られる更新チェック要求は、デバイスのタイプの指示、およびそのデバイスにインストールされている現アプリケーションのマスター・バージョン番号を含む。デバイス更新コンポーネント３１４は、バージョン・カタログ３１６をチェックして、アプリケーションの体験モジュールのいずれかに対して、デバイスに適用される更新パッケージがあるか否か判断する。アプリケーションの体験モジュールのいずれかに対して、デバイスに適用される更新パッケージがある場合、これらの更新パッケージをデバイスにデプロイする。そうでない場合、デバイスには更新パッケージをデプロイしない。

[0076] あるいは、デバイスは他のやり方でアプリケーションに対する更新をチェックすることもできる。例えば、デバイス上にインストールされている現アプリケーションのマスター・バージョン番号を送る代わりに、更新チェック要求は、特定の体験モジュールの識別子、およびデバイス上にインストールされている現アプリケーションの体験モジュールの体験バージョン番号を含むことができる。つまり、デバイスは、体験モジュール毎に、体験モジュールに対する更新をチェックすることができる。

[0077] 他の実施形態では、デバイスに更新チェック要求をプラットフォーム３００に送らせる代わりに、プラットフォーム３００が更新パッケージをデバイスにプッシュすることができる。例えば、デバイス更新コンポーネント３１４は、種々のデバイス上にインストールされているアプリケーションのマスター・バージョン番号（および／または体験バージョン番号）のレコードを維持することができる。デバイスに適用されるがまだそのデバイスにデプロイされていない更新パッケージが入手可能になったとき、デバイス更新コンポーネント３１４はその更新パッケージをこのデバイスにデプロイする。

[0078] また、デプロイ・サービス３０６は、更新パッケージの廃止もサポートする。１つ以上の実施形態では、更新パッケージを廃止するためには、開発者が交換更新パッケージを供給する（例えば、廃止される更新パッケージの前に用いられた直前の更新パッケージとすることができる）。また、開発者は、交換更新パッケージのインストールを即座に行うべきことを示す。こうして、しかるべきデバイスに交換更新パッケージをデプロイして、直前の更新パッケージを効果的に廃止する。

[0079] 先に論じたように、開発者がアプリケーションを変更するとき、開発者は、更新レポジトリー３１２に格納する変更の更新パッケージ、およびバージョン・カタログ３１６に含ませるための更新パッケージを記述した情報を提供する。開発者は、更新パッケージおよびこの更新パッケージを記述する情報を異なるやり方で提供することができる。例えば、更新パッケージおよびこの更新パッケージを記述する情報を、プラットフォーム３００の管理者に電子通信（例えば、電子メール）によって、光ディスクまたは他の携帯用記憶媒体等によって提供することができる。次いで、プラットフォーム３００の管理者は、更新パッケージを更新レポジトリー３１２に追加し、更新パッケージを記述する情報をバージョン・カタログ３１６に追加することができる。

[0080] あるいは、更新パッケージおよびこの更新パッケージを記述する情報を、デバイス更新コンポーネント３１４から自動的に入手することもできる。例えば、開発者は、サーバーまたは他の計算デバイス上に、更新パッケージおよびこの更新パッケージを記述する情報を維持することができる（デプロイ・サービス３０６が更新パッケージおよびこの更新パッケージを記述する情報を維持するのと同様のやり方で）。デバイス更新コンポーネント３１４は、開発者が維持している計算デバイスに更新要求を送り、この計算デバイスから、更新パッケージおよびこの更新パッケージを記述する情報を入手することができる。このように、デバイスが更新パッケージおよびこの更新パッケージを記述する情報をデプロイ・サービス３０６から入手するのと同様のやり方で、デプロイ・サービス３０６は、自動的に、更新パッケージおよびこの更新パッケージを記述する情報を、開発者が維持している計算デバイスから入手することができる。

[0081] 図４は、１つ以上の実施形態にしたがってアプリケーションを更新する一例を示す。図４の例では、図３のデプロイ・サービス３０６および図２のデバイス２００が示されている。デバイス２００上にインストールされているアプリケーション４０２は、マスター・バージョン番号が５８であり、３つの体験モジュールを有する。アプリケーション４０２における第１体験モジュールは、体験識別子がＡであり、体験バージョン番号が３である。アプリケーション４０２における第２体験モジュールは、体験識別子がＢであり、体験バージョン番号が７である。アプリケーション４０２における第３体験モジュールは、体験識別子がＣであり、体験バージョン番号が５である。

[0082] バージョン・カタログ３１６は、データー例を含む表として示されている。このバージョン・カタログの表には、多数のレコード（各々は表における横方向の行になっている）が示されている。バージョン・カタログ３１６の表において、第１列はマスター・バージョン番号４１０を示し、第２列は体験識別子４１２を示し、第３列は体験バージョン番号４１４を示し、第４列はデバイス・タイプ・マスク４１６を示し、最後の列は即座更新値４１８を示す。また、バージョン・カタログ３１６には、マスター・バージョン番号５７の前の更新パッケージに対応する行というような、追加の行(図示せず）を含めることもできる。デバイス・タイプ・マスク４１６について、「Ｃ」、「Ｍ」、および「Ｔ」の値が、コンピューター・タイプのデバイス（例えば、図１のコンピューター・デバイス１０６）、移動体タイプのデバイス（例えば、図１の移動体デバイス１０８）、およびテレビジョンに基づくタイプのデバイス（例えば、図１のテレビジョンに基づくデバイス１１０）をそれぞれ表すために用いられている。即座更新値４１８について、対応する更新パッケージのインストールを即座に行うべきことを示すために、「Ｔ」の値が用いられており、対応する更新パッケージのインストールを遅らせることができることを示すために、「Ｆ」の値が用いられている。

[0083] バージョン・カタログ３１６から分かるように、第１行は、マスター・バージョン番号が５７の更新パッケージに対応し、体験識別子Ａを有する体験モジュールについてであり、体験バージョン番号が３であり、コンピューター・タイプのデバイスおよびテレビジョンに基づくタイプのデバイスについでであり、対応する更新パッケージのインストールを即座に行うべきとなっている。

[0084] デバイス２００は、更新チェック要求４２０をデプロイ・サービス３０６に送り、デバイス２００のタイプ（テレビジョンに基づくタイプのデバイス）、およびデバイス２００の現マスター・バージョン番号（５８である）を特定する。デバイス更新コンポーネント３１４は、更新チェック要求をバージョン・カタログと突き合わせて評価し、マスター・バージョン番号５９、６１、および６２に対応する更新パッケージをデバイス２００にデプロイすべきであると判断する。デバイス２００の現バージョン番号以下のバージョン番号を有する更新パッケージは、既にデバイス２００にデプロイされている。したがって、マスター・バージョン番号５７および５８に対応する更新パッケージを再度デバイス２００にデプロイする必要はない。

[0085] マスター・バージョン番号５９に対応する更新パッケージは、未だデバイス２００にインストールされていない新しい体験モジュールに対するものであり、したがって、デバイス２００にデプロイしなければならない。マスター・バージョン番号６１および６２に対応する更新パッケージは、双方共、デバイス２００上に既にインストールされている体験モジュールの新しいバージョンに対するものであり、したがって、デバイス２００にデプロイしなければならない。マスター・バージョン番号６０に対応する更新パッケージは、デバイス２００上にインストールされていない新しい体験モジュールに対するものであるが、テレビジョンに基づくタイプのデバイスには適用されない（移動体タイプのデバイスに適用される）。したがって、マスター・バージョン番号６０に対応する更新パッケージをデバイス２００にはデプロイしない。

[0086] このように、デバイス更新コンポーネント３１４は、マスター・バージョン番号５９、６１、および６２に対応する更新パッケージをデバイス２００にデプロイすべきであるという指示４２２をデバイス２００に戻す。また、バージョン・カタログ３１６からの種々の情報も、指示４２２に含めることができる。１つ以上の実施形態では、デバイス更新コンポーネント３１４は、デバイス２００にデプロイすべき更新パッケージ毎に、マスター・バージョン番号の指示、更新パッケージが変更する体験モジュール、体験モジュールの新たなバージョンに対する体験バージョン番号、体験モジュールの新たなバージョンに対する体験バージョン番号、および対応する更新パッケージのインストールを即座に行うべきか、または遅らせることができるかの指示を戻す。

[0087] 図２に戻って、デバイス／サービス通信フレームワーク２１２は、デプロイ・サービス（例えば、図３のデプロイ・サービス３０６）から更新チェック要求に対する応答を受け取る。この応答は、アプリケーション２１８のためにデバイス２００上にインストールすべき特定の１つ以上の更新パッケージがある場合、そのいずれの指示も含む。また、１つ以上の更新パッケージ自体も、デプロイ・サービスから受け取る応答に含めることができ、あるいはデバイス／サービス通信フレームワーク２１２が、後に、特定の１つ以上の更新パッケージに対して要求をデプロイ・サービスに提出し、このような要求に応答して、特定の１つ以上の更新パッケージを、後続の要求に応答して、受け取ることができる。

[0088] １つ以上の実施形態では、デバイス２００上にインストールすべき１つ以上の更新パッケージをデバイス／サービス通信フレームワーク２１２が受け取ったとき、フレームワーク２１２はこれらの更新パッケージを体験ストレージ２１４に格納し、コア・コンポーネント・インターフェース２１６に、受け取った１つ以上の更新パッケージについて通知する。すると、コア・コンポーネント・インターフェース２１６は、更新パッケージをデバイス２００上にインストールし、その結果、デバイス２００上にアプリケーションの更新バージョンがインストールされる。このインストールは、特定のファイルを記憶デバイス上の特定の位置に書き込む、情報を登録ストア（例えば、オペレーティング・システムのレジストリー）に追加する、データーベース方式を更新する等というような、種々の異なる動作を含むことができる。体験ストレージ２１４および／またはデバイス２００の他の記憶デバイスに、ファイルを書き込むことができる。状況によっては、アプリケーション２１８に対する更新パッケージをインストールした後、デバイス２００をブートし直さないと、アプリケーション２１８を実行できない場合がある。他の状況では、アプリケーション２１８に対する更新パッケージをインストールした後、デバイス２００をブートし直すことなく、アプリケーション２１８を実行することができる。

[0089] 更新パッケージの指示が、対応する更新パッケージのインストールを即座に行うべきであることを示す場合、コア・コンポーネント・インターフェース２１６は、できるだけ早く更新パッケージをインストールする。このできるだけ早いインストールは、アプリケーション２１８を再度実行する前に更新パッケージをインストールし、既に実行中である場合にはアプリケーション２１８を停止して更新パッケージをインストールすること等を含むことができる。

[0090] しかしながら、更新パッケージの指示が、対応する更新パッケージのインストールを遅らせることができることを示す場合、コア・コンポーネント・インターフェース２１６は、更新パッケージをいずれかの後の時点にインストールする。コア・コンポーネント・インターフェース２１６は、インストールを遅らせることができる更新パッケージをいつインストールするか、アプリケーション２１８を再度実行する前、アプリケーション２１８の実行が終了した後、デバイス２００を次に切る前またはリセットする前、アプリケーション２１８が実行しておらずデバイス２００がアイドル状態にあるとき（例えば、デバイス２００上におけるプロセッサーおよび／または他のリソースの使用が閾値量よりも少ないとき）等というように、異なるやり方で決定することができる。

[0091] 図５は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションをインストールし、その更新パッケージを入手するプロセス例５００を示すフローチャートである。プロセス５００は、図２のデバイス１０２、または図２のデバイス２００のようなデバイスによって実行し、ソフトウェア、ファームウェア、ハードウェア、またはその組み合わせで実現することができる。プロセス５００は、１組の動作(act)として示されているが、これら種々の動作の処理(operation)を実行するために示される順序には限定されない。プロセス５００は、多数の体験モジュールを含むアプリケーションを実装するプロセス例であり、多数の体験モジュールを含むアプリケーションを実装することについての、異なる図を参照した追加の論述も、本明細書に含まれる。

[0092] プロセス５００では、多数の体験モジュールを含むアプリケーションをインストールする（動作５０２）。このアプリケーションは、プロセス５００を実装するデバイス上にインストールされ、先に論じたように、多数の体験モジュールを含む。

[0093] このアプリケーションを実行する要求に応答して、このアプリケーションの現バージョンを実行する（動作５０４）。このアプリケーションの現バージョンは、プロセス５００を実装するデバイス上にインストールされているアプリケーションの最新バージョンである。

[0094] 加えて、体験モジュールの内１つに対する更新パッケージが入手可能か否かについてチェックを行う（動作５０６）。このような更新パッケージがあるとすれば、プロセス５００を実装するデバイスに適用される更新パッケージである。このチェックは、デプロイ・サービスに更新チェック要求を送ることによって行われる。

[0095] アプリケーションの体験モジュールに対する更新パッケージが入手可能でない場合、プロセス５００は動作５０４に戻って、現バージョンのアプリケーションを実行する。しかしながら、体験モジュールの内１つに対する更新パッケージが入手可能である場合、この更新パッケージを入手する（動作５０８）。

[0096] 入手した更新パッケージをインストールして、現バージョンのアプリケーションを更新する（動作５１０）。更新パッケージは、アプリケーションが実行し終えた後にインストールすることができ（例えば、更新パッケージのインストールを遅らせることができる場合）、あるいは更新パッケージをインストールすることができるように、アプリケーションは実行を終了することができ（例えば、更新パッケージを即座にインストールすべきとき）、そしてアプリケーションを再度実行する。次いで、プロセス５００は動作５０４に戻り、現バージョンのアプリケーションを実行し続ける。

[0097] 尚、図５における動作の順序に拘わらず、動作５０６における更新パッケージの入手可能性をチェックする前に、アプリケーションを実行することができ、あるいはアプリケーションを実行する前に、更新パッケージの入手可能性をチェックすることもできることは注記してしかるべきである。

[0098] 図６は、１つ以上の実施形態にしたがって、更新をデバイスにデプロイするプロセス例６００を示すフローチャートである。プロセス６００は、ソフトウェア、ファームウェア、ハードウェア、またはその組み合わせで実現することができる。図６の左側に示すプロセス６００の動作は、図１のデバイス１０２、または図２のデバイス２００のようなデバイスによって実行する。図６の右側に示すプロセス６００の動作は、図１のデプロイ・サービス１１８、または図３のデプロイ・サービス３０６のようなデプロイ・サービスによって実行する。プロセス６００は、１組の動作(act)として示されているが、これら種々の動作の処理(operation)を実行するために示される順序には限定されない。プロセス６００は、更新をデバイスにデプロイするプロセス例であり、更新をデバイスにデプロイすることについての、異なる図を参照した追加の論述も本明細書に含まれる。

[0099] プロセス６００では、更新パッケージのレポジトリーおよび更新パッケージ記述のカタログを、デプロイ・サービスにおいて維持する（動作６０２）。更新パッケージは、先に論じたように、個々のアプリケーションの体験モジュールに対する変更を含む。

[00100] デバイスは、更新チェック要求をデプロイ・サービスに送る（動作６０４）。先に論じたように、更新チェック要求は、種々の時点においておよび／または種々のイベントに応答して送ることができる。

[00101] デプロイ・サービスは、更新チェック要求を受け取り（動作６０６）、デバイスに適用するあらゆる更新パッケージを特定する（動作６０８）。更新パッケージをデバイスに適用するか否かは、デバイス上における現在の体験モジュールのバージョン、デバイスのタイプ、デバイスのユーザー等というような、先に論じたような種々の異なる規準に応じて判断することができる。

[00102] デバイスに適用するあらゆる更新パッケージの指示をデバイスに戻す（動作６１０）。この指示は、デバイスに適用する０個以上の更新パッケージを特定する。
[00103] デバイスは、あらゆる更新パッケージの指示をデプロイ・サービスから受け取り（動作６１２）、この指示をチェックして、１つ以上の更新パッケージをデバイスに適用するか否か判断する（動作６１４）。

[00104] デバイスに適用する更新パッケージがない場合、現在の更新についてのチェックは終了する（動作６１６）。しかしながら、デプロイ・サービスは、更新パッケージのレポジトリーおよび更新パッケージ記述のカタログを維持し続け（動作６０２）、今後デプロイ・サービスに送られる更新チェック要求のために、プロセス６００を繰り返すことができる。

[00105] しかしながら、１つ以上の更新パッケージをデバイスに適用する場合、更新パッケージ要求をデプロイ・サービスに送る（動作６１８）。この更新パッケージ要求は、デバイスに適用する１つ以上の更新パッケージをデプロイ・サービスから入手するための要求である。

[00106] デプロイ・サービスは、更新パッケージ要求を受け取り（動作６２０）、要求された１つ以上の更新パッケージをデバイスに送ることによって応答する（動作６２２）。１つ以上の更新パッケージは、異なるやり方で（更新パッケージに付随するマスター・バージョン番号を用いることによってというように）特定することができる。デバイスは、要求した１つ以上の更新パッケージを受け取り（動作６２４）、受け取った１つ以上の更新パッケージをデバイス上にインストールする（動作６２６）。１つ以上の更新パケットの各々のインストールは、先に論じたように、即座に行うこと、または遅らせることができる。次いで、更新についての現在のチェックは終了する（動作６１６）。しかしながら、デプロイ・サービスは、更新パッケージのレポジトリーおよび更新パッケージ記述のカタログ維持し続け（動作６０２）、今後デプロイ・サービスに送られる更新チェック要求のために、プロセス６００を繰り返すことができる。

[00107] あるいは、１つ以上の更新パッケージをデバイスに適用する場合、動作６１０において、これらの更新パッケージをデバイスに戻すことができる。このような状況では、動作６１６〜６２０を実行する必要はない。

[00108] 図７は、１つ以上の実施形態にしたがって、多数の体験モジュールを含むアプリケーションを実行するように構成することができる計算デバイス例７００を示す。計算デバイス７００は、例えば、図１のデバイス１０２、図２のデバイス２００とすることができ、図１のプラットフォーム１１４または図３のプラットフォーム３００の少なくとも一部を実装することができる。

[00109] 計算デバイス７００は、１つ以上のプロセッサーまたは演算装置７０２、１つ以上のメモリーおよび／または記憶コンポーネント７０６を含むことができる１つ以上のコンピューター読み取り可能媒体、１つ以上の入力／出力（Ｉ／Ｏ）デバイス７０８、ならびに種々のコンポーネントおよびデバイスが互いに通信することを可能にするバス７１０を含む。コンピューター読み取り可能媒体７０４および／または１つ以上のＩ／Ｏデバイス７０８は、計算デバイス７００の一部として含ませることができ、あるいは計算デバイス７００に結合されてもよい。バス７１０は、数種類のバス構造の内１つ以上を表し、メモリー・バスまたはメモリー・コントローラー、周辺バス、加速グラフィクス・ポート、プロセッサーまたはローカル・バス、および種々の異なるバス構造を用いるその他を含む。バス７１０は、有線バスおよび／またはワイヤレス・バスを含むことができる。

[00110] メモリー／記憶コンポーネント７０６は、１つ以上のコンピューター記憶媒体を表す。コンポーネント７０６は、揮発性媒体（ランダム・アクセス・メモリー（ＲＡＭ）のような媒体）、および／または不揮発性媒体（リード・オンリー・メモリー−（ＲＯＭ）、フラッシュ・メモリー、光ディスク、磁気ディスク等のような媒体）を含むことができる。コンポーネント７０６は、固定媒体（例えば、ＲＡＭ、ＲＯＭ、固定ハード・ドライブ等）、およびリムーバブル媒体（例えば、フラッシュ・メモリー・ドライブ、リムーバブル・ハード・ドライブ、光ディスク等）を含むことができる。

[00111] 本明細書において論じた技法は、１つ以上の演算装置７０２によって命令を実行することによって、ソフトウェアで実現することができる。尚、演算装置７０２、演算装置７０２の種々のキャッシュ・メモリー、デバイス７００（図示せず）の他のキャッシュ・メモリー、他のコンピューター読み取り可能媒体等というような、計算デバイス７００の異なるコンポーネントに、異なる命令を格納できることは認められてしかるべきである。加えて、計算デバイス７００において命令を格納する場所は、ときの経過と共に変化する可能性があることも認められてしかるべきである。

[00112] １つ以上の入力／出力デバイス７０８は、ユーザーがコマンドおよび情報を計算デバイス７００に入力することを可能にし、更に情報をユーザーおよび／または他のコンポーネントまたはデバイスに提示するのを可能にする。入力デバイスの例には、キーボード、カーソル制御デバイス（例えば、マウス）、マイクロフォン、スキャナー等が含まれる。出力デバイスの例には、ディスプレイ・デバイス（例えば、モニターまたはプロジェクター）、スピーカー、プリンター、ネットワーク・カード等が含まれる。

[00113] 本明細書では、種々の技法をソフトウェアまたはプログラム・モジュールという一般的なコンテキストで説明することができる。一般に、ソフトウェアは、ルーチン、プログラム、オブジェクト、コンポーネント、データー構造等を含み、これらは特定のタスクを実行するか、または特定の抽象データー型を実装する。これらのモジュールおよび技法の実施態様は、コンピューター読み取り可能媒体上に格納することができ、またはコンピューター読み取り可能媒体の何らかの形態を通じて伝達することができる。コンピューター読み取り可能媒体は、計算デバイスによってアクセスすることができ入手可能な１つまたは複数のいずれの媒体でも可能である。一例として、そして限定ではなく、コンピューター読み取り可能媒体は、「コンピューター記憶媒体」および「通信媒体」を含むことができる。

[00114] 「コンピューター記憶媒体」は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターというような情報の格納のための方法または技術であればそのいずれでも実現できる。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたはその他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができ、コンピューターによってアクセスすることができる他のあらゆる媒体を含むが、これらに限定されるのではない。

[00115] 「通信媒体」は、通例、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターを、搬送波というような変調データー信号、または他の伝達メカニズムに具体化する。また、通信媒体は、あらゆる情報配信媒体も含む。「変調データー信号」という用語は、その特性の１つ以上が、内部に情報をエンコードするようなやり方で設定または変化させられている信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体と、音響、ＲＦ、赤外線、およびその他のワイヤレス媒体というようなワイヤレス媒体とを含む。以上の内いずれの組み合わせも、コンピューター読み取り可能媒体の範囲に含まれる。

[00116] 一般に、本明細書において記載した機能または技法は、そのいずれもが、ソフトウェア、ファームウェア、ハードウェア（例えば、固定論理回路）、手作業の処理、またはこれらの実施態様の組み合わせを用いて実現することができる。「モジュール」および「コンポーネント」という用語は、本明細書において用いる場合、一般にソフトウェア、ファームウェア、ハードウェア、またはその組み合わせを表す。ソフトウェア実施態様の場合、モジュールまたはコンポーネントは、プロセッサー（例えば、１つまたは複数のＣＰＵ）において実行されると、指定されたタスクを実行するプログラム・コードを表す。プログラム・コードは、１つ以上のコンピューター読み取り可能メモリー・デバイスに格納することができる。これらの更に詳しい説明は、図７を参照すれば見つけることができる。本明細書に記載した、多数の体験モジュールを含むアプリケーションの特徴は、プラットフォームに依存しないということであり、種々のプロセッサーを有する種々の商用計算プラットフォームにおいて、本技術を実現できることを意味する。

[00117] 以上、構造的特徴および／または方法論的動作に特定的な文言で主題について説明したが、添付した特許請求の範囲において定義されている主題は、以上に記載した特定的な特徴または動作には必ずしも限定されないことは言うまでもない。逆に、以上に記載した特定的な特徴および動作は、特許請求の範囲を実現する形態例として開示したのである。

Claims (14)

1. デバイスにおける方法であって、
   前記デバイス上に、多数の体験モジュールを含むアプリケーションをインストールするステップであって、前記アプリケーションが実行しているとき前記体験モジュールの各々が、１組の機構を実装し、前記多数の体験モジュールの各々が、前記デバイスの特定のタイプ(particular type)に専用の(specific)コードを含む第１コンポーネントと、デバイスの多数のタイプにわたって共通であるコードを含む第２コンポーネントとを含む、ステップと、
   前記アプリケーションを実行する要求に応答して、前記デバイス上で、前記アプリケーションを実行するステップと、
   を備えている、方法であって、更に、
   前記多数の体験モジュールの各々が前記多数の体験モジュールの他のものに直接アクセスすることを防止するために、前記多数の体験モジュールを互いに分離するステップを備えている、方法。
2. デバイスにおける方法であって、
   前記デバイス上に、多数の体験モジュールを含むアプリケーションをインストールするステップであって、前記アプリケーションが実行しているとき前記体験モジュールの各々が、１組の機構を実装し、前記多数の体験モジュールの各々が、前記デバイスの特定のタイプ(particular type)に専用の(specific)コードを含む第１コンポーネントと、デバイスの多数のタイプにわたって共通であるコードを含む第２コンポーネントとを含む、ステップと、
   前記アプリケーションを実行する要求に応答して、前記デバイス上で、前記アプリケーションを実行するステップと、
   を備えている、方法であって、更に、
   前記多数の体験モジュールの内第１体験モジュールから、要求された動作を含むメッセージを受け取るステップと、
   前記メッセージを前記多数の体験モジュールの内第２体験モジュールに送るステップと、
   前記多数の体験モジュールの内第２体験モジュールから、前記要求された動作を含む前記メッセージに対する応答を含む応答メッセージを受け取るステップと、
   前記応答メッセージを前記多数の体験モジュールの内前記第１体験モジュールに送るステップと、
   を備えている、方法。
3. 請求項２に記載の方法であって、更に、
   前記多数の体験モジュールの各々から、前記体験モジュールが実行することができる１つ以上の動作の指示を受け取るステップと、
   前記多数の体験モジュールの１つ以上から、前記多数の体験モジュールの内特定の動作を実行できるものを特定する要求を受けるステップと、
   前記多数の体験モジュールの内前記１つ以上に、前記多数の体験モジュールの内前記特定の動作を実行することができる体験モジュールの指示を返すステップと、
   を含む、方法。
4. デバイスにおける方法であって、
   前記デバイス上に、多数の体験モジュールを含むアプリケーションをインストールするステップであって、前記アプリケーションが実行しているとき前記体験モジュールの各々が、１組の機構を実装し、前記多数の体験モジュールの各々が、前記デバイスの特定のタイプ(particular type)に専用の(specific)コードを含む第１コンポーネントと、デバイスの多数のタイプにわたって共通であるコードを含む第２コンポーネントとを含む、ステップと、
   前記アプリケーションを実行する要求に応答して、前記デバイス上で、前記アプリケーションを実行するステップと、
   を備えている、方法であって、更に、
   前記多数の体験モジュールの内第１体験モジュールから要求を受けるステップと、
   前記アプリケーションがインストールされている追加のデバイスに前記要求を送るステップと、
   前記追加のデバイスから、前記要求に対する応答を受け取るステップと、
   前記応答を、前記多数の体験モジュールの内前記第１体験モジュールに送るステップと、
   を備えている、方法。
5. 請求項１〜４のいずれか一項に記載の方法において、前記アプリケーションが、前記デバイス上にあるアプリケーション・シェルにおいて実行され、前記第１コンポーネントが、前記特定のタイプのデバイスを含む１つ以上のタイプのデバイスに専用のプレゼンテーション・ロジックおよびリソースを含み、多数のタイプのデバイスにわたって共通である前記コードが、前記特定のタイプのデバイスおよび他のタイプのデバイスにわたって共通であるビジネス・ロジックを備えている、方法。
6. 請求項５に記載の方法において、前記多数のタイプのデバイスが、コンピューター・タイプのデバイスと、移動体タイプのデバイスと、テレビジョンに基づくタイプのデバイスとを含み、前記デバイスの特定のタイプが、前記多数のデバイスのタイプの内の１つである、方法。
7. 請求項１〜６のいずれか一項に記載の方法であって、更に、
   更新の有無をチェックする要求をデプロイ・サービスに送るステップと、
   前記デプロイ・サービスから、前記多数の体験モジュールの内１つ以上に対する１つ以上の更新パッケージの指示を受け取るステップと、
   前記デプロイ・サービスから、前記多数の体験モジュールの前記１つ以上に対する前記１つ以上の更新パッケージを受け取るステップと、
   前記デバイス上に、前記１つ以上の更新パッケージをインストールするステップと、
   を備えている、方法。
8. 請求項７に記載の方法であって、更に、
   前記１つ以上の更新パッケージの前記指示に基づいて、前記１つ以上の更新パッケージを即座にインストールすべきか否か判断するステップと、
   前記１つ以上の更新パッケージを即座にインストールすべきであると判断した場合、前記アプリケーションを次に実行する前に、前記１つ以上の更新パッケージをインストールするステップと、
   を備えている、方法。
9. 計算デバイスであって、
   プロセッサーと、
   多数の命令が格納されている１つ以上のコンピューター読み取り可能媒体と、
   を備えており、前記命令を前記プロセッサーによって実行すると、前記プロセッサーに、
   アプリケーションの異なる体験モジュール毎に異なる更新パッケージのカタログを維持させ、前記アプリケーションが多数の体験モジュールを含み、前記アプリケーションがデバイス上で実行しているときに、各体験モジュールが１組の機構を実装し、前記多数の体験モジュールの各々が、前記デバイスの特定のタイプに専用のプレゼンテーション・ロジックおよびリソースを含む第１コンポーネントと、多数のデバイスのタイプにわたって共通であるビジネス・ロジックを含む第２コンポーネントとを含み、
   前記デバイス上において前記アプリケーションに適用する更新パッケージがあるか否か判断させ、
   前記デバイス上において前記アプリケーションに適用する更新パッケージがある場合、前記デバイスに前記更新パッケージを送らせる、計算デバイスにおいて、更に、
   前記多数の体験モジュールの各々が前記多数の体験モジュールの他のものに直接アクセスすることを防止するために、前記多数の体験モジュールを互いに分離されている、
   計算デバイス。
10. 請求項９に記載の計算デバイスにおいて、前記多数のタイプのデバイスが、コンピューター・タイプのデバイスと、移動体タイプのデバイスと、テレビジョンに基づくタイプのデバイスとを含み、前記デバイスの特定のタイプが、前記多数のデバイスのタイプの内の１つである、計算デバイス。
11. 請求項９又は１０に記載の計算デバイスにおいて、前記多数の体験モジュールの１つに対する前記更新パッケージが、前記多数の体験モジュールの内前記１つにおけるコンポーネントに対する変更を特定する、計算デバイス。
12. 請求項９〜１１のいずれか一項に記載の計算デバイスにおいて、前記多数の命令が、更に、前記プロセッサーに、前記アプリケーションに対する多数の異なる更新パッケージを維持させ、前記特定のタイプのデバイスに少なくとも部分的に基づいて、前記デバイス上において前記アプリケーションに適用する更新パッケージがあるか否か判断させる、計算デバイス。
13. 請求項９〜１２のいずれか一項に記載の計算デバイスにおいて、前記多数の命令が、更に、前記プロセッサーに、
    前記更新パッケージの指示を前記デバイスに送らせ、
    前記デバイスから前記更新パッケージの要求を受けさせ、
    前記更新パッケージの要求に応答して、前記更新パッケージを前記デバイスに返させる、
    計算デバイス。
14. 請求項９〜１３のいずれか一項に記載の計算デバイスにおいて、前記多数の命令が、更に、前記プロセッサーに、前記更新パッケージの指示を前記デバイスに送らせ、前記更新パッケージの指示が、
    前記アプリケーションのマスター・バージョン番号と、
    前記多数の体験モジュールの内、前記更新パッケージによって変更される体験モジュールを示す体験モジュール識別子と、
    前記多数の体験モジュールの内前記変更された体験モジュールの体験モジュール・バージョン番号と、
    前記更新パッケージを前記デバイスによって即座にインストールすべきか、または遅らせることができるかの指示と、
    を含む、計算デバイス。

Images