JP6783907B2 - アプリケーション更新方法、アプリケーション更新装置、電子機器およびコンピュータ読み取り可能な記憶媒体 - Google Patents

Description

本発明は、概括的に、アプリケーションの更新に関し、さらに具体的には、アプリケーション試用プラットフォームでアプリケーションを更新するためのアプリケーション更新方法、アプリケーション更新装置、電子機器およびコンピュータ読み取り可能な記憶媒体に関する。

モバイルデバイスの処理能力の向上に伴い、現在までモバイルデバイスにインストールするためのアプリケーションがますます多く現れている。アプリケーションの機能の更なる複雑化に伴い、アプリケーションのインストールパッケージもどんどん多くなっている。モバイルデバイスのユーザは、一般的に、多くの時間を費やしてアプリケーションをダウンロードしてインストールする必要がある。もし、アプリケーションの機能が自分の期待を満たさないことが分かった場合、ユーザは、一般的に、既にインストールしたアプリケーションをアンインストールすることになる。

現在、多くのアプリケーション試用プラットフォームが既に現れている。これらのアプリケーション試用プラットフォームは、ユーザが、自分のモバイルデバイスにアプリケーションをインストールせずに、アプリケーション試用プラットフォームを利用してアプリケーションの機能を事前に試用するようにサポートする。アプリケーションの開発者は、頻繁に更新たなバージョンのアプリケーションを発表することになり、したがって、ユーザが最新なアプリケーションを使用できるように確保するために、試用プラットフォームにおいても、更新たなバージョンの発表に応じて、プラットフォームのアプリケーションのバージョンを絶えず更新する必要がある。したがって、より便利で効率的な方式でアプリケーションを更新する技術案を提供することが望ましい。

本発明によると、アプリケーションを更新するためのアプリケーション更新方法が提供される。

本発明の第１の態様において、アプリケーションを更新するためのアプリケーション更新方法が提供される。アプリケーション更新方法において、アプリケーションのサーバに通信可能にカップリングされるアプリケーション試用プラットフォームで動作する前記アプリケーションの実例の動作期間に生成されたインタフェース画像を取得ステップと、前記インタフェース画像におけるウィジェットに関連する複数の属性を抽出するステップと、抽出された前記複数の属性に基づいて、前記インタフェース画像が前記サーバによって発表された前記アプリケーションの更新の存在を指示するか否かを決定するステップと、前記インタフェース画像が前記更新の存在を指示すると決定されたことに応答して、前記アプリケーション試用プラットフォームで前記アプリケーションの前記実例を更新するステップとを含む。

本発明の第２の態様において、アプリケーションを更新するためのアプリケーション更新装置が提供される。アプリケーション更新装置は、取得モジュールと、抽出モジュールと、決定モジュールと、更新モジュールとを備える。具体的には、取得モジュールは、アプリケーションの実例の動作期間に生成されたインタフェース画像を取得する。アプリケーションの実例は、アプリケーションのサーバに通信可能にカップリングされるアプリケーション試用プラットフォームで動作する。抽出モジュールは、インタフェース画像におけるウィジェットに関連する複数の属性を抽出する。決定モジュールは、抽出された複数の属性に基づいて、インタフェース画像がサーバによって発表されたアプリケーションの更新の存在を指示するか否かを決定する。更新モジュールは、インタフェース画像が更新の存在を指示すると決定されたことに応答して、アプリケーション試用プラットフォームでアプリケーションの実例を更新する。

本発明の第３の態様において、電子機器が提供される。電子機器は、少なくとも一つのプロセッサと、少なくとも一つのプログラムが記憶されている記憶装置とを備え、少なくとも一つの前記プログラムが少なくとも一つの前記プロセッサによって実行される場合、少なくとも一つの前記プロセッサが上記のアプリケーション更新方法を実現する。

本発明の内容の第４の態様において、コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体を提供する。コンピュータプログラムがプロセッサによって実行される場合、上記のアプリケーション更新方法が実現される。

発明内容の部分によって説明された内容は、本発明の内容の実現形態のキーポイントまたは重要な特徴を限定することを意図したものではなく、本発明の範囲を限制するものでもないことを理解すべきである。本発明の他の特徴は、以下の説明によって容易に理解される。

図面および以下の詳細な説明を参考して、本発明の各実現形態の上記の特徴と他の特徴、利点、および、態様がさらに明らかになる。図面において、同一または類似の符号は、同一または類似の要素を示し、その中、
本発明の一実施形態に係る技術案を採用したアプリケーション環境の例示的な図面を模式的に示す。 本発明の一実施形態に係る技術案の例示的なブロック図を模式的に示す。 本発明の一実施形態に係るアプリケーション更新方法の例示的なフローチャート模式的に示す。 本発明の一実施形態に係るウィジェット知識モデルを取得するための例示的なブロック図を模式的に示す。 本発明の一実施形態に係るインタフェース知識モデルを取得するための例示的なブロック図を模式的に示す。 本発明の一実施形態に係るウィジェット知識モデルを更新するための方法の例示的なフローチャートを模式的に示す。 本発明の一実施形態に係るアプリケーション試用プラットフォームにおけるアプリケーションを更新するための変形例のブロック図を模式的に示す。 本発明の一実施形態に係るアプリケーション更新装置の例示的なブロック図を模式的に示す。 本発明の一実施形態に係る電子機器の例示的なブロック図を示す。

以下、図面を参照して本発明の内容の実施形態をさらに詳細に説明する。図面では本発明の内容の特定の実施形態を示したが、本発明の内容はさまざまな形態で実現できることを理解すべきである。以下に説明する実施形態に限られると解釈されるものではなく、逆に、さらに透徹にかつ完全に本発明の内容を理解するために、実施形態を提供する。本発明の図面および実施形態は、単に例示的な作用に用いられ、本発明の保護範囲を限定するものでないことを理解すべきである。

本発明の実施形態の説明において、用語である「含む」およびそれと類似な用語は、開放的に含むことと理解すべきであり、すなわち「含むが限定されない」と理解すべきである。用語である「に基づいて」は、「少なくとも一部に基づいて」と理解すべきである。用語である「一実施形態」または「本実施形態」は、「少なくとも一つの実施形態」と理解すべきである。用語である「第１の」、「第２の」などは、異なる対象または同一の対象を示すことができる。以下に他の明示的および暗黙的な定義も含まれている可能性がある。

図１は、本発明の一実施形態に係る技術案を採用したアプリケーション環境１００の例示的な図面を模式的に示す。
図１は、アプリケーション試用プラットフォーム１１０の一例を模式的に示す。図１に示されるように、アプリケーション試用プラットフォーム１１０には、複数のアプリケーションの実例１１２、・・・・・・、１１４などが動作できる。例えば、アプリケーションの実例１１２は、アプリケーション試用プラットフォーム１１０にインストールされたゲームＡであり、アプリケーションの実例１１４は、アプリケーション試用プラットフォーム１１０にインストールされたゲームＢであってもよい。図１に示していないが、アプリケーション試用プラットフォーム１１０には、ゲームＡの複数の実例が存在してもよい。一般的に、ゲームの更新頻度がより高いため、本発明の文脈ではゲームをアプリケーションの実例として説明する。本発明の文脈において、アプリケーションは、例えば、買い物、チケット予約、または、他の機能を実現するプログラムなどのような他のプログラムをさらに含んでもよいことが理解される。

図１に示されるように、アプリケーション試用プラットフォーム１１０は、ネットワーク１４０を介して各アプリケーションのサーバにカップリングされることができる。例えば、サーバ１３０は、ゲームＡに用いられるサーバであり、サーバ１３２は、ゲームＢに用いられるサーバであってもよい。このとき、複数のユーザは、それぞれのモバイルデバイス１２０、・・・・・・、１２２を介して、アプリケーション試用プラットフォーム１１０で各アプリケーションの機能を試用することができる。具体的には、一方のユーザは、モバイルデバイス１２０を利用して、ネットワーク１４０を介してアプリケーションの実例１１２にアクセスし、他のユーザは、モバイルデバイス１２２を利用して、ネットワーク１４０を介してアプリケーションの実例１１４にアクセスすることができる。

アプリケーションの開発者は、頻繁に更新たなバージョンのアプリケーションを発表することになり、これに応じて、アプリケーション試用プラットフォーム１１０もプラットフォームのアプリケーションのバージョンを絶えず更新する必要がある。現在、アプリケーションの最新インストールパッケージを定期的に採取し、プラットフォームで使用されるインストールパッケージのバージョンと最新インストールパッケージとの間の差異を比較することによって、アプリケーションを更新するかどうかを決定する技術が、既に提出された。しかしながら、現在、アプリケーションの更新は、一般的に、オリジナルインストールパッケージの内容を修正せずに、アプリケーション動作過程にインストールパッケージをダウンロードして更新するように（それを「ホットアップデート」と呼ぶ）ユーザに知らせる。従来技術は、このようなホットアップデートを検出できないため、アプリケーション試用プラットフォーム１１０におけるアプリケーションバージョンが最新のものに更新されるように確保することができない。

先行技術での上記の欠陥に鑑み、さらに便利で効率的にアプリケーションを更新する技術案を提供することが望ましい。さらに、本技術案は既存する技術案と組み合わせること、および、できるだけ既存する技術案のハードウェアアーキテクチャを変更しない状況で実現することが望ましい。

本発明の一実施形態によると、アプリケーションの実例の動作期間に生成されたインタフェース画像を取得し、また、インタフェース画像を識別することで更新が存在するかどうかを決定することができる。
以下、図２から図８を参照して詳細に説明する。図２は、本発明の一実施形態に係る技術案の例示的なブロック図２００を模式的に示す。図２に示されるように、アプリケーション試用プラットフォーム１１０でアプリケーションの実例１１２を動作し、動作期間に生成されたインタフェース画像２１０を取得することができる。例えば、定期的にスクリーンショットする方法によってインタフェース画像２１０を取得してもよいし、あるいは、スクリーンの内容が変えたことが見つかったときにインタフェース画像２１０を取得してもよい。

一般的に、インタフェース画像２１０には、複数のウィジェット２２０が含まれ、このとき、画像識別によって、インタフェース画像２１０におけるウィジェットに関連する複数の属性２３０を取得することができる。図２は、対話ボックスウィジェット２２２（その中にはボタン２２４とボタン２２６が含まれる）を模式的に示し、ウィジェット２２２の属性は、例えば、ウィジェットの文字、種類、位置などを含んでいてもよい。次に、抽出された複数の属性に基づいて、インタフェース画像が、サーバによって発表されたアプリケーションの更新２４０の存在を指示するか否かを決定することができる。もし、更新２４０が存在すると、更新２４０に関連するインストールパッケージをダウンロードし、更新を実行することができる。

上記の実現において、アプリケーション試用プラットフォームで動作されるアプリケーションのインタフェース画像に対して、画像識別を行うことによって、ウィジェットの複数の属性（例えば、文字内容には、「更新」を含み、色は「鮮やか」など）を抽出し、複数の属性に基づいてアプリケーションの更新を検出することができる。この方式によると、一方では、アプリケーション動作期間にインタフェース画像２１０から「ホットアップデート」を検出して更新を実行することができ、他方では、手動操作なしに、画像識別により検出と更新を自動的に実行することができる。

以下、図３を参照して、アプリケーション更新に関するさらに多い細部を詳細に説明する。図３は、本発明の一実施形態に係るアプリケーション更新方法３００の例示的なフローチャートを模式的に示す。
図３に示されるように、ステップ３１０は、アプリケーションの実例１１２の動作期間に生成されたインタフェース画像２１０を取得する。この場合、アプリケーションの実例１１２は、アプリケーション試用プラットフォーム１１０で動作され、また、アプリケーション試用プラットフォーム１１０は、アプリケーションのサーバ１３０に通信可能にカップリングされている。この実現において、ユーザは、自分のモバイルデバイス１２０にアプリケーションをインストールする必要がなく、アプリケーション試用プラットフォーム１１０におけるアプリケーションの実例１１２を遠隔アクセスすることができる。動作期間において、アプリケーションの実例１１２は、モバイルデバイス１２０からのユーザとの対話をアプリケーションのサーバ１３０に伝送し、アプリケーションのサーバ１３０からフィードバックを受信することができる。次に、アプリケーションの実例１１２は、表示されているインタフェースの内容をモバイルデバイス１２０に送信することができる。例えば、ビデオストリームの方式でインタフェース内容をユーザに送信することができる。

ステップ３２０は、インタフェース画像におけるウィジェット２２０に関連する複数の属性２３０を抽出する。具体的には、インタフェース画像２１０における各ウィジェットに対して、関連する属性を抽出することができる。一般的に、ウィジェット２２０は、アプリケーションの更新に関する内容を含む。例えば、図２に示されるウィジェット２２２には、「アプリケーション更新が存在します。インストールパッケージをダウンロードしますか？」とのプロンプトを表示する。この一例において、属性２３０は、例えば、ウィジェットにおける文字を含んでいてもよい。本実施形態によると、ウィジェットの文字、ウィジェットの種類、ウィジェットの位置、ウィジェットのスタイルおよびウィジェットがトリガー可能であるか否かのうちの少なくとも任意の一つに基づいて、複数の属性を抽出することができる。

ステップ３３０は、抽出された複数の属性２３０に基づいて、インタフェース画像２１０が、サーバ１３０によって発表されたアプリケーションの更新の存在を指示するか否かを決定する。例えば、ウィジェット２２２に関連する上記の文字で検出された「更新」との単語に基づいて、更新の存在を決定することができる。また、例えば、更新を知らせる対話ボックスには、例えば「決定」、「バージョン」、「新たなバージョン」、「ダウンロード」、「インストールパッケージ」など文字がさらに含まれていてもよい。このとき、ウィジェットに関連する属性２３０に上記の文字が存在することが検出されると、更新が存在すると判断することができる。ここで、属性２３０に特定の文字が含まれていることのみを一例として、更新が存在するかどうかをどのように判断するかを説明したことが理解される。本実施形態によると、知識モデルに基づいて、属性のさらに多い側面に基づいて、更新が存在するかどうかを決定することができる。

ステップ３４０は、インタフェース画像２１０が更新の存在を指示すると決定したことに応答して（すなわち、判断結果が「はい」である）、ステップ３５０に進む。
ステップ３５０は、アプリケーション試用プラットフォーム１３０でアプリケーションの実例１１２を更新する。例えば、図２に示されるウィジェット２２２におけるボタン２２４をクリックすることによって、更新に関連するインストールパッケージをダウンロードし、続いて、アプリケーション試用プラットフォーム１１０でアプリケーションの実例１１２を更新することができる。
また、ステップ３４０においては、インタフェース画像２１０が更新の存在を指示すると決定した場合（すなわち、判断結果が「いいえ」である）、ステップ３６０に進み、アプリケーション試用プラットフォームにおけるアプリケーションの実例を更新しない。すなわち、アプリケーション試用プラットフォームにおけるアプリケーションの実例が最新なバージョンであるので、直接にアプリケーション試用プラットフォームにおけるアプリケーションの実例を用いればよい。

本実施形態によると、属性２３０は、複数の側面を含んでいてもよい。例えば、上記のウィジェットの文字のほか、属性２３０は、ウィジェットの種類、ウィジェットの位置、ウィジェットのスタイルおよびウィジェットがトリガー可能であるか否かのうちの任意の一つを含んでいてもよい。例えば、ウィジェットの種類は、対話ボックス、選択ボックス、ボタンなどを含んでもよい。ウィジェットの中心（または、左上角）がスクリーンに対する相対的な位置を採用してウィジェットの位置を表示することができる。一般的に、明確にするために、アプリケーション更新を知らせるためのウィジェットは、一般的に、スクリーンの中心に存在する。したがって、もし、ウィジェットに、文字である「更新」が含まれ、かつ、当該ウィジェットがスクリーンの中心位置に位置していることが見つかると、アプリケーション更新が存在すると決定することができる。

本実施形態においては、属性２３０は、ウィジェット２２０のスタイル（例えば、色、フォント、アイコンを含むかどうかなど）をさらに含んでいてもよい。一般的に、顕著にするために、アプリケーション更新を知らせるウィジェット２２０は、一般的に、顕著な色、大きなフォント、感嘆符などを含むアイコンに設定される。したがって、ウィジェット２２０が上記の内容に関することが見つかると、アプリケーション更新が存在すると決定することができる。以上は一例の方式によって属性に関する複数の側面の内容を説明したことに過ぎず、具体的なアプリケーションの環境において、属性２３０は、さらに多い側面の内容、または、さらに少ない側面の内容をさらに含んでもよいことが理解される。

大量の属性が存在する場合、各属性の具体的な数値に基づいて各属性が更新が存在する該当する閾値を満たすかどうかを一つずつ判断すると、大量の判断語句を使用することになり、判断の流れより複雑になることが理解される。本実施形態においては、抽出された複数の属性に基づいてウィジェットの特徴を決定することができる。この方式によると、複数の属性を単一な特徴にマッピングすることによって、ウィジェットのさまざまな側面の要素と更新が存在するかどうかとの間の関連関係を総合的に考慮することができる。

本実施形態においては、線形回帰方法を利用して、複数の属性に基づいてウィジェットの特徴を決定することができる。具体的に、以下の数式１を採用してあるウィジェットの特徴を決定することができる。

上記の数式１において、
ｙは、ウィジェットの特徴を示し、
ｎは、属性の数を示し、
Ｘｉは、複数の属性におけるｉ番目の属性の得点を示し、
ａｉおよびｂｉは、線形回帰方法におけるｉ番目の属性の重みとオフセットを示す。
この方式によると、さらに簡単で効率的な方式で複数の属性を特徴にマッピングすることによって、アプリケーションに更新が存在するかどうかの決定を容易にすることができる。

[００、１００]範囲における数値によって各属性の得点を示すと想定する。例えば、もし、ウィジェットの文字に「更新」、「ダウンロード」などの文字が存在すると、属性である「文字」の得点をより高い数値（例えば、８０）に設定することができる。文字が更新が存在するかどうかの判断に重要であるため、属性に対してより高い重み（例えば、１．５）と正の方向のオフセットを付与することができる。また、例えば、もし、ウィジェットの位置がスクリーンの中央にいると、属性である「位置」の得点をより高い数値（例えば、６０）に設定することができる。ウィジェットの位置が更新が存在するかどうかの判断により重要であるため、属性に対してより高い重み（例えば、１．２）と正の方向のオフセットを付与することができる。上記の実施形態を利用して、各属性の得点に基づいてウィジェットの特徴を決定することができる。

本実施形態においては、ウィジェット知識モデルを取得することができる。ここで、ウィジェット知識モデルは、アプリケーションの更新とウィジェットの特徴との間のマッピング関係を含み、知識モデルは、１グループのサンプルウィジェットの特徴および１グループのサンプルウィジェットに関連するサンプルアプリケーションの更新に基づいて訓練されることができる。次に、もし、ウィジェットの特徴がマッピング関係にマッチングされると決定されると、インタフェース画像が更新の存在を指示すると決定することができる。上記の実施形態を利用して、機械学習方法にしたがって、既存の知識訓練に基づいて得た知識モデルを利用して、アプリケーション更新が存在するかどうかの判断を補助することができる。

以下、図４Ａを参照して、どのようにウィジェットの特徴に基づいて更新が存在するかどうかを決定するかを説明する。図４Ａは、本発明の一実施形態に係るウィジェット知識モデル４２０Ａを取得するためのブロック図４００Ａを模式的に示す。
図４Ａに示されるように、サンプルウィジェット特徴４１０Ａを取得することができ、ここで、サンプルウィジェット特徴４１０Ａとは、以前にアプリケーションを動作して得たものを指す。更新４１２Ａとは、以前にアプリケーションを動作するときウィジェットの更新が行われたか否かを指す。本実施形態においては、サンプルウィジェット特徴４１０Ａおよび更新４１２Ａに基づいてウィジェット知識モデル４２０Ａを訓練することができる。具体的には、１グループのサンプルウィジェットの特徴（グループのサンプルウィジェットによって更新が行われた）を取得することができ、また、他のグループのサンプルウィジェットの特徴（グループのサンプルウィジェットによって更新が行われなかった）を取得することができる。機械学習技術によって、ウィジェット知識モデル４２０Ａを訓練して得ることによって、ウィジェット知識モデル４２０Ａおよび現在得たウィジェット特徴に基づいて、アプリケーションに更新が存在するかどうかを決定することができる。

本実施形態においては、１グループのサンプルウィジェット特徴がいずれも文字である「更新」に関し、また、ウィジェットによって更新が行われたと想定すれば、文字である「更新」に関するウィジェット特徴が受信されると、上記のサンプル訓練によって得られたウィジェット知識モデル４２０Ａを採用して、アプリケーションに更新が存在すると決定することができる。上記の実施形態を利用して、ウィジェット特徴と更新が存在するかどうかに関する歴史経験に十分に基づいて、アプリケーションの実例１１２の動作期間に更新が存在するかどうかを決定することができる。

以上、どのようにウィジェット特徴に基づいて更新が存在するかどうかを判断するかを既に説明した。アプリケーションインタフェースには他の複雑な内容が存在する可能性があるため、ウィジェット特徴に単純に依存すると、誤判断が生じる可能性がある。このとき、インタフェース画像２１０の内容全体に基づいて更新が存在するかどうかの判断を補助することができる。本実施形態においては、インタフェース知識モデルを取得することができ、ここで、インタフェース知識モデルは、アプリケーションの更新とインタフェース画像との間のマッピング関係を含み、インタフェース知識モデルは、１グループのサンプルインタフェース画像および１グループのサンプルインタフェース画像に関連するサンプルアプリケーションの更新に基づいて訓練される。次に、マッピング関係およびインタフェース画像に基づいて、更新の信頼度を決定する。この実現において、もし、インタフェース画像に基づく判断結果とウィジェット特徴に基づくオリジナル判断結果とが一致すると、オリジナル判断結果がより高い信頼度を有すると決定することができ、一致しないと、オリジナル判断結果の信頼度を低減することができる。

以下、図４Ｂを参照して、どのようにインタフェース画像２１０に基づいて更新が存在するかどうかを決定するかを説明する。図４Ｂは、本発明の一実施形態に係るインタフェース知識モデルを取得するためのブロック図４００Ｂを模式的に示す。
図４Ｂに示されるように、サンプルインタフェース画像４１０Ｂを取得することができる。ここで、サンプルインタフェース画像４１０Ｂとは、以前にアプリケーションを動作して得たものを指し、更新４１２Ｂとは、以前にアプリケーションを動作するときインタフェース画像２１０によって更新が行われたか否かを指す。本実施形態によると、サンプルインタフェース画像４１０Ｂおよび更新４１２Ｂに基づいて、インタフェース知識モデル４２０Ｂを訓練することができる。具体的には、１グループのサンプルインタフェース画像（グループのサンプルインタフェース画像によって更新が行われた）を取得することができ、他のグループのサンプルインタフェース画像（グループのサンプルインタフェース画像によって更新が行われなかった）を取得することができる。機械学習技術によって、インタフェース知識モデル４２０Ｂを訓練して得ることによって、インタフェース知識モデル４２０Ｂおよび現在得たインタフェース画像に基づいて、アプリケーションに更新が存在するかどうかを決定することができるようにする。インタフェース知識モデル４２０Ｂを訓練および使用する詳しいステップは、図４Ａを参照して説明したウィジェット知識モデル４２０Ａを訓練および使用するステップと類似であるため、以下繰り返して説明しない。

本実施形態においては、ウィジェットをトリガーすることでサーバから更新に関連するデータをダウンロードすることができる。次に、アプリケーション試用プラットフォームにおいて、ダウンロードしたデータに基づいてアプリケーションの実例を更新する。図２に示した一例に戻り、上記の方法を採用してウィジェット２２２がアプリケーションの更新の存在を指示すると決定されると、このとき、ウィジェット２２２におけるボタン２２４をクリックして、サーバからインストールパッケージをダウンロードする操作をトリガーすることができる。上記の実施形態を利用して、サーバからダウンロードした更新に関するインストールパッケージを利用して、アプリケーション試用プラットフォームで動作されているアプリケーションの実例１１２を更新することができる。

本実施形態においては、アプリケーションの実例１１２を動作した後の時間にアプリケーションの更新が行われたかどうかに基づいて、上記の知識モデル（例えば、ウィジェット知識モデル４２０Ａとインタフェース知識モデル４２０Ｂとが正しいか否か）をさらに検証することができる。以下、ウィジェット知識モデル４２０Ａのみを一例として説明する。図５は、本発明の一実施形態に係るウィジェット知識モデルを更新するための方法５００のフローチャートを模式的に示す。ステップ５１０において、ウィジェットをトリガーした後の予め設定された時点に、アプリケーションの実例の他のインタフェース画像を取得する。ここで、予め設定された時点は、例えば、ウィジェットをトリガーした後の２分間であってもよい（または、他の時間長さ）ことが理解される。一般的に、もし、アプリケーションに更新が存在すると、例えば上記のウィジェット２２２をトリガーした後、他のインタフェースが出現することになる（例えば、インストールパッケージの保存を知らせる対話ボックス、または、インストールパッケージをダウンロードするプログレスバー、など）。このとき、前のインタフェース画像と他のインタフェース画像との間の差異を判断することによって、更新が存在するかどうかを決定することができる。

ステップ５２０において、他のインタフェース画像とインタフェース画像との間の差異の程度を判断することができ、差異が予め設定された閾値よりも小さいと、操作はステップ５３０に進入する。なた、もう一つのインタフェース画像とインタフェース画像との間の差異が予め設定された閾値よりも小さいと、後続に更新操作を実行しなかったことを示す。このとき、前の知識モデルによって誤判断されたと見なすことができるので、後続のステップ５３０において、後続に、ウィジェットの特徴に基づいてマッピング関係を更新することによって、更新されたマッピング関係が、特徴とアプリケーションの更新との間にマッピングが存在しないことを指示するようにすることができる。また、差異が予め設定された閾値よりも小さくない場合には、知識モデルによる判断が正しいことを意味するので、この場合には、ステップ５４０に進み、知識モデルを更新しない。

本実施形態においては、さまざまな方式によって、二つのインタフェース画像の間の差異を決定することができる。例えば、ピクセル比較によって差異を決定することができるし、また、例えば、インタフェース画像における文字、または、画像内容を識別することによって、差異を決定することができる。数値の方式で差異の程度を表示することでき、例えば、予め設定された数値範囲である[００、１００]を差異の範囲とすることができる。このとき、予め設定された閾値を６０、または、他の数値に設定することができる。

一例において、ウィジェットをトリガーした後でダウンロードプログレスバーを表示すると想定すると、ダウンロードプログレスバーと前のインタフェース画像における更新を知らせる対話ボックスとが完全に異なると決定することができ、このとき、現在の知識モデルに基づいて正しい判断結果を得ることができると決定でき、このとき、知識モデルを更新する必要がない。他の一例において、ウィジェットをトリガーした後にインタフェースが依然として現在のゲームインタフェースを表示すると想定すると、二つのインタフェース画像の間の差異が予め設定された閾値よりも小さいと決定することができる。次に、ウィジェットの特徴に基づいてウィジェット知識モデル４２０Ａを更新することができ、インタフェース画像に基づいてインタフェース知識モデル４２０Ｂを更新することもできる。

上記の実施形態を利用して、一方では、実際のアプリケーションの実例１１２の動作によって更新が行われたかどうかに基づいて、ウィジェット知識モデル４２０Ａおよびインタフェース知識モデル４２０Ｂにおける誤りを校正することができる。他方では、知識モデルを訓練する初期段階においてより少ないサンプルのみが存在する場合、二つのインタフェース画像の間の差異が予め設定された閾値よりも大きい状況に基づいて、更新が行われたサンプルを取得し、二つのインタフェース画像の間の差異が予め設定された閾値よりも小さい状況に基づいて、更新が行われなかったサンプルを取得することができる。この方式によると、自発学習の方式によって訓練するためのサンプルを取得することができる。

本発明の実施形態によると、上記の方法３００は、アプリケーション試用プラットフォーム１１０で実行されることができる。本実施形態においては、アプリケーションの実例１１２は、モバイルデバイス１２０からユーザの入力を受信し、モバイルデバイス１２０に、アプリケーションの実例１１２を動作して生成されたインタフェースの画像を出力することができる。このとき、アプリケーション試用プラットフォーム１１０で動作されるアプリケーションの実例１１２は、モバイルデバイス１２０とサーバ１３０との間の仲介になり、両者の間でデータを送信／受信できる。上記の実施形態を利用して、ユーザは、モバイルデバイス１２０にアプリケーションを予めインストールしない状況で、アプリケーションのさまざまな機能を体験することができる。ユーザは、アプリケーションの機能が自身の要求を満たすと確認した後に、アプリケーションをダウンロードし、モバイルデバイス１２０にアプリケーションをインストールすることができる。この方式によると、ユーザが、自身の要求を満たさないアプリケーションをダウンロードし、インストールし、さらに、アンインストールすることを回避することができる。

本実施形態においては、アプリケーション試用プラットフォーム１１０における各アプリケーションの実例１１２、・・・・・・、１２４に対して、上記の方法を実行することができる。本発明の実施形態によると、一部の実例のみに対して上記の方法を実行することができ、また、インタフェース画像が更新の存在を指示すると決定した場合、アプリケーション試用プラットフォーム１１０で動作されているアプリケーションの他の実例を更新することができる。図６は、本発明の一実施形態に係るアプリケーション試用プラットフォーム１１０におけるアプリケーションを更新するための変形例のブロック図６００を模式的に示す。
図６に示されるように、アプリケーション試用プラットフォーム１１０におけるアプリケーションの実例１１２に対して上記の方法を既に実行し、アプリケーション更新が存在すると決定したと想定する。このとき、アプリケーションの実例１１４に対する更新を起動することができる。実例１１２と実例１１４とは同一のアプリケーションに対する実例であるので、更新が既に存在すると決定した場合、実例１１４を更新する過程において、更新が存在するかどうかを判断する操作をスキップして、インタフェース画像における更新に関連するウィジェットを直接トリガーすることによって、更新に関連するインストールパッケージをダウンロードしてインストールすることができる。

本実施形態においては、アプリケーション試用プラットフォーム１１０の作業負荷がより軽い時間帯に（例えば、夜間）上記のアプリケーション更新方法を実行することができる。この実現において、アプリケーション試用プラットフォーム１１０におけるアプリケーションの実例を定期的に動作することによって、アプリケーションの提供者が新たなインストールパッケージを発表したか否かをチェックすることができる。

以上でアプリケーションの実例１１２を更新する一例のみを挙げて、どのようにアプリケーション試用プラットフォーム１１０で動作されているアプリケーションの実例を更新するかを説明したことが理解される。実際の操作環境において、アプリケーション試用プラットフォーム１１０には複数のアプリケーションの複数の実例が動作されることができ、このとき、各実例に対して上記のアプリケーション更新方法を実行することができる。この方式によると、各アプリケーションの各実例がいずれも最新なバージョンに更新されることが確保できる。

以上、図面を参照して、アプリケーション試用プラットフォーム１１０で動作されるアプリケーションの実例１１２を更新するための方法５００の具体的なステップを説明した。本実施形態においては、処理装置を利用して上記の方法を実行することができる。具体的には、図７は、本発明の一実施形態に係るアプリケーション更新装置７００の例示的なブロック図を模式的に示す。
具体的には、アプリケーション更新装置７００は、取得モジュール７１０と、抽出モジュール７２０と、決定モジュール７３０と、更新モジュール７４０とを備えている。
具体的には、取得モジュール７１０は、アプリケーションの実例の動作期間に生成されたインタフェース画像を取得する。アプリケーションの実例はアプリケーション試用プラットフォームで動作され、アプリケーション試用プラットフォームはアプリケーションのサーバに通信可能にカップリングされる。
抽出モジュール７２０は、インタフェース画像におけるウィジェットに関連する複数の属性を抽出する。
決定モジュール７３０は、抽出された複数の属性に基づいて、インタフェース画像がサーバによって発表されたアプリケーションの更新の存在を指示するか否かを決定する。
更新モジュール７４０は、インタフェース画像が更新の存在を指示すると決定されたことに応答して、アプリケーション試用プラットフォームでアプリケーションの実例を更新する。

本実施形態においては、決定モジュール７３０は、特徴抽出モジュールと、モデル取得モジュールと、更新決定モジュールと、をさらに備えている。
特徴抽出モジュールは、抽出された複数の属性に基づいて、ウィジェットの特徴を決定する。
モデル取得モジュールは、ウィジェット知識モデルを取得する。ウィジェット知識モデルは、アプリケーションの更新とウィジェットの特徴との間のマッピング関係を含み、ウィジェット知識モデルは、１グループのサンプルウィジェットの特徴および１グループのサンプルウィジェットに関連するサンプルアプリケーションの更新に基づいて訓練されたものである。
更新決定モジュールは、ウィジェットの特徴がマッピング関係とマッチングされたことに応答して、インタフェース画像が更新の存在を指示すると決定する。

本実施形態においては、抽出モジュール７２０は、属性抽出モジュールを備えている。
属性抽出モジュールは、ウィジェットの文字、ウィジェットの種類、ウィジェットの位置、ウィジェットのスタイル、および、ウィジェットがトリガー可能であるか否かのうちの少なくとも任意の一つに基づいて、複数の属性を抽出する。

本実施形態においては、特徴抽出モジュールは、回帰モジュールを備えている。
回帰モジュールは、線形回帰方法を利用し、複数の属性に基づいてウィジェットの特徴を決定する。

本実施形態に係るアプリケーション更新装置７００は、モデル取得モジュールと、検証モジュールとをさらに備えている。
モデル取得モジュールは、インタフェース知識モデルを取得する。インタフェース知識モデルは、アプリケーションの更新とインタフェース画像との間のマッピング関係を含み、インタフェース知識モデルは、１グループのサンプルインタフェース画像および１グループのサンプルインタフェース画像に関連するサンプルアプリケーションの更新に基づいて訓練される。
検証モジュールは、マッピング関係およびインタフェース画像に基づいて、更新の信頼度を決定する。

本実施形態においては、更新モジュール７４０は、トリガーモジュールと、動作モジュールとを備える。トリガーモジュールは、ウィジェットをトリガーしてサーバから更新に関連するデータをダウンロードする。動作モジュールは、アプリケーション試用プラットフォームで、ダウンロードされたデータに基づいて、アプリケーションの実例を更新する。

本実施形態においては、アプリケーション更新装置７００は、画像取得モジュールと、マッピング更新モジュールとをさらに備えている。
画像取得モジュールは、ウィジェットをトリガーした後の予め設定された時点に、アプリケーションの実例の他のインタフェース画像を取得する。
マッピング更新モジュールは、他のインタフェース画像とインタフェース画像との間の差異が予め設定された閾値よりも小さいことに応答して、ウィジェットの特徴に基づいてマッピング関係を更新することによって、更新されたマッピング関係が、特徴とアプリケーションの更新との間にマッピングが存在しないことを指示する。

本実施形態においては、アプリケーション更新装置７００は、アプリケーション試用プラットフォームに配置される。

本実施形態においては、アプリケーションの実例は、モバイルデバイスからユーザの入力を受信し、アプリケーションの実例を動作して生成されたインタフェースの画像をモバイルデバイスに出力する。

本実施形態においては、アプリケーション更新装置７００は、実例更新モジュールをさらに備えている。
実例更新モジュールは、インタフェース画像が更新の存在を指示すると決定されたことに応答して、アプリケーション試用プラットフォームで動作されるアプリケーションの他の実例を更新する。

図８は、本発明の一実施形態に係るアプリケーション更新方法を実施できる電子機器８００のブロック図を示す。
電子機器８００は、図１のアプリケーション環境を実現することができる。図示のように、電子機器８００は、読み出し専用メモリ（ＲＯＭ）８０２に記憶されているコンピュータプログラム命令または記憶ユニット８０８からランダムアクセスメモリ（ＲＡＭ）８０３にロードされたコンピュータプログラム命令に従ってさまざまな適切な動作およびプロセスを実行可能な中央処理装置（ＣＰＵ）８０１を備えている。ＲＡＭ８０３には、電子機器８００の動作に必要な各種のプログラムやデータも記憶可能である。ＣＰＵ８０１、ＲＯＭ８０２およびＲＡＭ８０３は、バス８０４を介して相互に接続されている。入力／出力（Ｉ／Ｏ）インタフェース８０５もバス８０４に接続されている。

キーボード、マウスなどの入力ユニット８０６と、各種のディスプレイ、スピーカなどの出力ユニット８０７と、ディスク、ＣＤなどの記憶ユニット８０８と、ネットワークカード、モデム、無線通信トランシーバなどの通信ユニット８０９とを備えている、電子機器８００における複数の構成要素は、Ｉ／Ｏインタフェース８０５に接続されている。通信ユニット８０９は、電子機器８００がインターネットおよび／または様々な電気通信ネットワークなどを介して他の機器と情報／データを交換することを許容する。

ＣＰＵ８０１は、アプリケーション更新方法３００など、上記のさまざまな方法およびプロセスを実行する。例えば、変形例としては、アプリケーション更新方法３００は、記憶ユニット８０８などの機器読み取り可能な媒体に有形に含まれるコンピュータソフトウェアプログラムとして実現することができる。変形例では、コンピュータプログラムの少なくとも一部は、ＲＯＭ８０２および／または通信ユニット８０９を介して電子機器８００にロードおよび／またはインストールすることができる。コンピュータプログラムがＲＡＭ８０３にロードされ、ＣＰＵ８０１によって実行されると、上記のアプリケーション更新方法３００の少なくとも１つのステップが実行される。変形例として、ＣＰＵ８０１は、任意の他の適切な手段によって（例えば、ファームウェアによって）アプリケーション更新方法３００を実行するように構成されてもよい。

本発明の一実施形態において、コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体を提供した。プログラムがプロセッサによって実行されるとき、本発明によって説明されたアプリケーション更新方法が実現される。

本明細書で以上によって説明された機能は、少なくとも一部が少なくとも一つのハードウェア論理部品によって実行されてもよい。例えば、限定ではなく一例として、使用できる模範的なタイプのハードウェア論理部品は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準製品（ＡＳＳＰ）、システムオンシステム（ＳＯＣ）、プログラマブルロジック設備（ＣＰＬＤ）などを含む。

本発明の一実施形態に係るアプリケーション更新方法を実施するためのプログラムコードは、少なくとも一つのプログラミング言語の任意の組み合わせでプログラミングすることができる。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサまたはコントローラに提供されてもよい。その結果、プログラムコードがプロセッサまたはコントローラによって実行されると、フローチャートおよび／またはブロック図において特定される機能／操作が実行される。プログラムコードは、完全に機器で実行、部分的に機器で実行することができ、スタンドアロンソフトウェアパッケージとして部分的に機器で実行され、部分的にリモート機器で実行されまたは全てリモート機器またはサーバで実行され得る。

本開示の明細書では、機器読み取り可能な媒体は、命令実行システム、装置、または機器によって使用されるまたは命令実行システム、装置、または機器と組み合わせて使用するためのプログラムを含むまたは記憶することができる有形の媒体とすることができる。機器読み取り可能な媒体は、機器読み取り可能な信号媒体または機器読み取り可能な記憶媒体とすることができる。機器読み取り可能な媒体は、電子、磁気、光学、電磁気、赤外線、または半導体システム、装置、または機器、あるいは上記の任意の適切な組み合わせを含むことができるが、それらに限定されない。機器読み取り可能な記憶媒体のより具体的な一例は、少なくとも一つのラインに基づく電気接続、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンメモリ（ＲＯＭ）、消去可能プログラマブルリードオンメモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、またはこれらの任意の適切な組み合わせを含むことができる。

また、動作は、特定の順序で説明されたが、これは、そのような動作が示された特定の順序または順序の順番で実行されること、または所望の結果を達成するためにすべての示された動作が実行されることを必要とする。特定の状況では、マルチタスキングおよび並列処理は、有利な場合がある。同様に、いくつかの具体的な実施例の詳細が上記の説明に含まれているが、これらは本開示の範囲を限定するものとして解釈されるべきではない。別々の実施例で説明されているいくつかの特徴は、単一の実現において組み合わせて実現することもできる。逆に、単一の実施例に関して説明されている様々な特徴は、個別にまたは任意の適切なサブコンビネーションで複数の実施例で実施することができる。

本願は、構成的特徴および／または方法論理的動作に特有の言語で説明されているが、添付の特許請求の範囲で定義されるテーマは、説明された上記の特定の特徴または動作に限定されないことが理解されるべきである。逆に、上記の特定の特徴および動作は単に特許請求の範囲を実施する例示的な形態である。

Claims (22)

1. アプリケーションを更新するためのアプリケーション更新方法であって、
   前記アプリケーションのサーバに通信可能にカップリングされるアプリケーション試用プラットフォームで動作する前記アプリケーションの実例の動作期間に生成されたインタフェース画像を取得するステップと、
   前記インタフェース画像におけるウィジェットに関連する複数の属性を抽出するステップと、
   抽出された前記複数の属性に基づいて、前記インタフェース画像が前記サーバによって発表された前記アプリケーションの更新の存在を指示するか否かを決定するステップと、
   前記インタフェース画像が前記更新の存在を指示すると決定されたことに応答して、前記アプリケーション試用プラットフォームで前記アプリケーションの前記実例を更新するステップとを含むアプリケーション更新方法。
2. 前記インタフェース画像が前記サーバによって発表された前記アプリケーションの前記更新の存在を指示するか否かを決定するステップは、
   抽出された前記複数の属性に基づいて、前記ウィジェットの特徴を決定するステップと、
   前記アプリケーションの前記更新と前記ウィジェットの前記特徴との間のマッピング関係を含み、１グループのサンプルウィジェットの特徴および該１グループのサンプルウィジェットに関連するサンプルアプリケーションの更新に基づいて訓練されるウィジェット知識モデルを取得するステップと、
   前記ウィジェットの前記特徴が前記マッピング関係とマッチングされたことに応答して、前記インタフェース画像が前記更新の存在を指示すると決定するステップとをさらに含む請求項１に記載のアプリケーション更新方法。
3. 前記インタフェース画像における前記ウィジェットに関連する前記複数の属性を抽出するステップは、
   前記ウィジェットの文字、前記ウィジェットの種類、前記ウィジェットの位置、前記ウィジェットのスタイル、および前記ウィジェットがトリガー可能であるか否かのうちの少なくとも任意の一つに基づいて、前記複数の属性を抽出するステップを含む請求項１に記載のアプリケーション更新方法。
4. 抽出された前記複数の属性に基づいて、前記ウィジェットの前記特徴を決定するステップは、
   線形回帰方法を利用し、前記複数の属性に基づいて、前記ウィジェットの前記特徴を決定するステップを含む請求項２に記載のアプリケーション更新方法。
5. 前記アプリケーションの前記更新と前記インタフェース画像との間のマッピング関係を含み、１グループのサンプルインタフェース画像および該１グループのサンプルインタフェース画像に関連するサンプルアプリケーションの更新に基づいて訓練されるインタフェース知識モデルを取得するステップと、
   前記マッピング関係および前記インタフェース画像に基づいて、前記更新の信頼度を決定するステップとをさらに含む請求項１に記載のアプリケーション更新方法。
6. 前記アプリケーションの前記実例を更新するステップは、
   前記ウィジェットをトリガーして前記サーバから前記更新に関連するデータをダウンロードするステップと、
   前記アプリケーション試用プラットフォームで、ダウンロードされた前記データに基づいて、前記アプリケーションの前記実例を更新するステップとを含む請求項２に記載のアプリケーション更新方法。
7. 前記ウィジェットをトリガーした後の予め設定された時点で、前記アプリケーションの前記実例の他のインタフェース画像を取得するステップと、
   前記他のインタフェース画像と前記インタフェース画像との間の差異が予め設定された閾値よりも小さいことに応答して、前記ウィジェットの前記特徴に基づいて、前記マッピング関係を更新することによって、更新された前記マッピング関係が、前記特徴と前記アプリケーションの前記更新との間にマッピングが存在しないことを指示するステップとをさらに含む請求項６に記載のアプリケーション更新方法。
8. 前記アプリケーション試用プラットフォームで実行される請求項１に記載のアプリケーション更新方法。
9. 前記アプリケーションの前記実例は、モバイルデバイスからユーザの入力を受信し、前記アプリケーションの前記実例を動作して生成された前記インタフェースの画像を前記モバイルデバイスに出力する請求項１に記載のアプリケーション更新方法。
10. 前記インタフェース画像が前記更新の存在を指示すると決定されたことに応答して、前記アプリケーション試用プラットフォームで動作される前記アプリケーションの他の実例を更新するステップをさらに含む請求項１に記載のアプリケーション更新方法。
11. アプリケーションを更新するためのアプリケーション更新装置であって、
    前記アプリケーションのサーバに通信可能にカップリングされるアプリケーション試用プラットフォームで動作し、前記アプリケーションの実例の動作期間に生成されたインタフェース画像を取得する取得モジュールと、
    前記インタフェース画像におけるウィジェットに関連する複数の属性を抽出する抽出モジュールと、
    抽出された前記複数の属性に基づいて、前記インタフェース画像が前記サーバによって発表された前記アプリケーションの更新の存在を指示するか否かを決定する決定モジュールと、
    前記インタフェース画像が前記更新の存在を指示すると決定されたことに応答して、前記アプリケーション試用プラットフォームで前記アプリケーションの前記実例を更新する更新モジュールとを備えるアプリケーション更新装置。
12. 前記決定モジュールは、
    抽出された前記複数の属性に基づいて、前記ウィジェットの特徴を決定する特徴抽出モジュールと、
    前記アプリケーションの前記更新と前記ウィジェットの前記特徴との間のマッピング関係を含み、１グループのサンプルウィジェットの特徴および該１グループのサンプルウィジェットに関連するサンプルアプリケーションの更新に基づいて訓練されるウィジェット知識モデルを取得するモデル取得モジュールと、
    前記ウィジェットの前記特徴が前記マッピング関係とマッチングされたことに応答して、前記インタフェース画像が前記更新の存在を指示すると決定する更新決定モジュールとをさらに備える請求項１１に記載のアプリケーション更新装置。
13. 前記抽出モジュールは、属性抽出モジュールを備え、
    前記属性抽出モジュールは、前記ウィジェットの文字、前記ウィジェットの種類、前記ウィジェットの位置、前記ウィジェットのスタイルおよび前記ウィジェットがトリガー可能であるか否かのうちの少なくとも任意の一つに基づいて、前記複数の属性を抽出する請求項１１に記載のアプリケーション更新装置。
14. 前記特徴抽出モジュールは、回帰モジュールを備え、
    前記回帰モジュールは、線形回帰方法を利用し、前記複数の属性に基づいて、前記ウィジェットの前記特徴を決定する請求項１２に記載のアプリケーション更新装置。
15. 前記アプリケーションの前記更新と前記インタフェース画像との間のマッピング関係を含み、１グループのサンプルインタフェース画像および該１グループのサンプルインタフェース画像に関連するサンプルアプリケーションの更新に基づいて訓練されるインタフェース知識モデルを取得するモデル取得モジュールと、
    前記マッピング関係および前記インタフェース画像に基づいて、前記更新の信頼度を決定する検証モジュールとをさらに備える請求項１１に記載のアプリケーション更新装置。
16. 前記更新モジュールは、
    前記ウィジェットをトリガーして前記サーバから前記更新に関連するデータをダウンロードするトリガーモジュールと、
    前記アプリケーション試用プラットフォームで、ダウンロードされた前記データに基づいて、前記アプリケーションの前記実例を更新する動作モジュールとを備える請求項１２に記載のアプリケーション更新装置。
17. 前記ウィジェットをトリガーした後の予め設定された時点で、前記アプリケーションの前記実例の他のインタフェース画像を取得する画像取得モジュールと、
    前記他のインタフェース画像と前記インタフェース画像との間の差異が予め設定された閾値よりも小さいことに応答して、前記ウィジェットの前記特徴に基づいて、前記マッピング関係を更新することによって、更新された前記マッピング関係が、前記特徴と前記アプリケーションの前記更新との間にマッピングが存在しないことを指示するマッピング更新モジュールとをさらに備える請求項１６に記載のアプリケーション更新装置。
18. 前記アプリケーション試用プラットフォームに配置される請求項１１に記載のアプリケーション更新装置。
19. 前記アプリケーションの前記実例は、モバイルデバイスからユーザの入力を受信し、前記アプリケーションの前記実例を動作して生成されたインタフェースの画像を前記モバイルデバイスに出力する請求項１１に記載のアプリケーション更新装置。
20. 前記インタフェース画像が前記更新の存在を指示すると決定されたことに応答して、前記アプリケーション試用プラットフォームで動作される前記アプリケーションの他の実例を更新する実例更新モジュールをさらに備える請求項１１に記載のアプリケーション更新装置。
21. 少なくとも一つのプロセッサと、
    少なくとも一つのプログラムが記憶されている記憶装置とを備え、
    少なくとも一つの前記プログラムが少なくとも一つの前記プロセッサによって実行される場合、少なくとも一つの前記プロセッサが請求項１から請求項１０のいずれかに記載のアプリケーション更新方法を実現する電子機器。
22. コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体であって、
    前記コンピュータプログラムがプロセッサによって実行される場合、請求項１から請求項１０のいずれかに記載のアプリケーション更新方法が実現されるコンピュータ読み取り可能な記憶媒体。

Images