JP6025821B2 - 推定されたＱｏＥをアプリケーションごとに端末上に出力する方法 - Google Patents

Description

本明細書において別段の記載がない限り、このセクションにおいて説明されているアプローチは、本出願における特許請求の範囲に対する従来技術であるわけではなく、また、このセクションに含まれることによって従来技術であると認められるわけではない。

特定のアプリケーションを端末上で使用したいと望むユーザにとって、そのアプリケーションが端末上で実際に実行された場合にどれぐらい多くのＱｏＥを得ることができるかを知ることは有用である。

したがって、推定されたＱｏＥに関する情報を端末上に出力する有用な方法を提供することが望まれている。

一実施形態によれば、推定されたＱｏＥに関する情報を端末上に出力する方法が提供される。この方法は、アプリケーションごとにＱｏＥ推定を実行すること、およびそのＱｏＥ推定に基づいて、推定されたＱｏＥに関する情報を端末上に出力することを含むことができる。

主題は、本明細書の結びの部分において詳細に指摘され、明確に特許請求されている。本開示の前述の特徴およびその他の特徴は、添付の図面とともに以降の説明および添付の特許請求の範囲をから、より完全に明らかになるであろう。これらの図面は、本開示によるいくつかの実施形態を示しているにすぎず、したがって、本開示の範囲を限定するものとみなされるべきではないということを理解して、添付の図面の使用を通じたさらなる具体性および詳細を伴って本開示について説明する。

クラウドコンピューティングを示す概念図である。 端末１０によって実行されるプロセスを示すためのフローチャートである。 端末１０のディスプレイ１２上に表示される情報の一例を示すための図である。 アプリケーション「ウェブアルバム」に関するＱｏＥ推定の一例を示すための図である。 アプリケーション「ビデオ配信」に関するＱｏＥ推定の一例を示すための図である。 アプリケーション「ＩＰ電話」に関するＱｏＥ推定の一例を示すための図である。 ＱｏＥを推定する際に使用される基準を設定する方法の一例を示すためのフローチャートである。 端末１０の構成の一例を示すための機能ブロック図である。 後続アクション予測部１０２およびＱｏＥ推定トリガリング部１０４のオペレーションの一例を示すためのフローチャートである。 後続アクション予測部１０２およびＱｏＥ推定トリガリング部１０４のオペレーションの別の例を示すためのフローチャートである。

以降の説明は、特許請求されている主題の完全な理解を提供するために、具体的な詳細とともにさまざまな例を示している。しかしながら、特許請求されている主題は、本明細書において開示されている具体的な詳細のうちのいくつかまたはそれ以上を伴わずに実施することができるということを当業者なら理解するであろう。さらに、いくつかの状況においては、特許請求されている主題を不必要にわかりにくくすることを避けるために、よく知られている方法、手順、システム、コンポーネント、および／または回路については、詳細に説明していない。

以降の詳細な説明においては、添付の図面を参照し、それらの図面は、本明細書の一部を形成している。それらの図面においては、同様のシンボルは、文脈によって別段の内容が示されない限り、典型的には同様のコンポーネントを識別する。詳細な説明、図面、および特許請求の範囲に記載されている例示的な実施形態は、限定することを意図してはいない。本明細書において提示されている主題の趣旨または範囲から逸脱することなく、その他の実施形態を利用することができ、その他の変更を行うことができる。一般的に本明細書において説明され図に示されている本開示の複数の態様は、さまざまな異なる構成でアレンジすること、代用すること、組み合わせること、および設計することが可能であり、それらの構成のすべては、明示的に本開示の一部であると考えられ、本開示の一部とされるということが容易に理解できるであろう。

図１は、クラウドコンピューティングの概念図を示している。図１に示されているように、端末１０のユーザは、クラウド２０において、またはクラウド２０を介して、さまざまなアプリケーション、たとえばＥメール、カレンダなどを享受することができる。

端末１０は、任意のタイプのものであってよい。端末１０は、スマートフォン、タブレット、ラップトップコンピュータ、デスクトップコンピュータなどであってもよい。

クラウド２０は、端末１０によってアクセスされる通信ネットワークの複数の要素を含む包含的な要素であってよい。言い換えれば、クラウド２０は、アプリケーションを端末１０上で実行することを可能にする複数の要素を含むことができる。クラウド２０は、インターネット、およびさまざまなサービスプロバイダ、たとえば［Ｇｏｏｇｌｅ］、［Ｙａｈｏｏ］などを含むことができる。

端末１０は、アプリケーションごとにＱｏＥ推定を実行するように構成されることが可能である。具体的には、端末１０は、端末１０上で実行されることが可能であるそれぞれのアプリケーションに関するＱｏＥ（Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）をアプリケーションごとに推定するように構成されることが可能である。

ここでは、アプリケーションのＱｏＥ（Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）は、ワイヤレスアクセスネットワークのステータス、コアネットワークのステータス、およびクラウド２０の内部のステータスなどの因子に依存する場合がある。ＱｏＥは、ユーザによって必要とされる通信の品質を示すことができる。したがってＱｏＥは、アプリケーションごとに異なる場合がある。さらにＱｏＥは、ユーザごとに異なる場合がある。

アプリケーションに関するＱｏＥを推定する方法は、さまざまなものであってよい。アプリケーションごとにＱｏＥを推定することができる限り、いかなる方法を使用することもできる。アプリケーションに関するＱｏＥを推定する方法のいくつかの例について、以降で説明する。

端末１０は、それぞれのアプリケーションの推定されたＱｏＥに関する情報を端末のディスプレイ上に出力するように構成されることが可能である。この情報は、さまざまな形で出力されることが可能である。たとえば、それぞれのアプリケーションの推定されたＱｏＥは、端末のディスプレイ上に直接表示されることが可能である。それぞれのアプリケーションの推定されたＱｏＥに関する情報を出力する方法のいくつかの例について、以降で説明する。

図２は、端末１０によって実行されるプロセスを示すためのフローチャートである。

ステップ２００においては、ＱｏＥ推定がアプリケーションごとに実行されることが可能である。たとえば、４つのアプリケーションがある場合には、ＱｏＥ推定は、それらの４つのアプリケーションのそれぞれに関して別々に実行されることが可能である。４つのアプリケーションのそれぞれに関するＱｏＥ推定のタイミングは、任意のものであってよい。たとえば、４つのアプリケーションのそれぞれに関するＱｏＥ推定は、バッチ処理として連続して実行されること、または時間をかけて間隔を置いて実行されることが可能である。

ＱｏＥ推定は、基準を使用して実行されてもよい。この基準は、アプリケーションごとに異なってもよい。したがって、この基準は、アプリケーションごとに設定されてもよい。この基準は、デフォルトの基準として前もって設定されてもよい。この基準は、端末のユーザデータに基づいて設定されてもよい。ユーザデータは、端末１０のユーザのニーズまたは好みを示す情報を含むことができる。そのような情報は、ユーザによって端末１０の実際のオペレーション中に得られるデータから統計的に導出されても、ユーザによって直接入力されてもよい。たとえば、デフォルトの基準は、ユーザからの入力に従って訂正されることが可能である。

ステップ２０２においては、それぞれのアプリケーションの推定されたＱｏＥに関する情報が、端末のディスプレイ上に出力されることが可能である。アプリケーションの推定されたＱｏＥに関する情報は、アプリケーションに関するＱｏＥ推定が完了した時点で出力される（更新される）ことが可能である。したがって、それぞれのアプリケーションの推定されたＱｏＥに関する情報どうしは、別々のタイミングで出力され（更新され）てもよい。アプリケーションの推定されたＱｏＥに関する情報は、そのアプリケーションが端末１０上で実際に実行される前に出力され（更新され）てもよい。

図３は、端末１０のディスプレイ１２上に表示される情報の一例を示すための図である。図３においては、一例として、７つのアプリケーション（Ｅメール、ウェブアルバム、地図、ビデオ配信、ＩＰ電話、カレンダ、およびストリートビュー）が、端末１０上で実行されることが可能である。

図３に示されているように、端末１０は、アイコン１４ａ〜１４ｇを表示するように構成されることが可能である。アイコンの数は、アプリケーションの数に依存することができる。アイコン１４ａ〜１４ｇは、対応するアプリケーションを開始するために提供されることが可能である。言い換えれば、アイコン１４ａ〜１４ｇは、対応するアプリケーションのためのランチャであってもよい。それぞれのアプリケーションは、対応するアイコン１４ａ〜１４ｇがアクティブ化されたときに開始されることが可能である。アイコン１４ａ〜１４ｇのアクティブ化は、クリック操作、タッチ操作などによって実施されることが可能である。アイコン１４ａ〜１４ｇは、図３に示されているように、対応するアプリケーションを示す文字またはイラストを含むことができる。

端末１０は、端末１０上に表示されるアイコンの色をＱｏＥ推定に従って変更するように構成されることが可能である。たとえば、「青色」は、「非常によい」というＱｏＥを示すことができ、「緑色」は、「よい」というＱｏＥを示すことができ、「黄色」は、「まずまず」というＱｏＥを示すことができ、「赤色」は、「悪い」というＱｏＥを示すことができ、「グレー」は、「使用不能」というＱｏＥを示すことができる。たとえば、アイコン１４ａに関連付けられているアプリケーション「Ｅメール」に関する推定されたＱｏＥが「よい」である場合には、アイコン１４ａの色は、黄色に変更されることが可能である。この構成では、推定されたＱｏＥは、色によって容易に区別することが可能である。

アイコン１４ａ〜１４ｇは、ウェブサイトまたはＥメールの場合では、リンクに置き換えることが可能であるということに留意されたい。リンクは、しばしばウェブサイトまたはＥメール上で提供される。この場合では、リンクは、アプリケーションを実行するためのランチャとして機能する。したがって、この場合では、リンクの色などのステータスリンクが、対応するアプリケーションの推定されたＱｏＥに従って変更されることが可能である。

図４は、アプリケーション「ウェブアルバム」に関するＱｏＥ推定の一例を示すための図である。アプリケーション「ウェブアルバム」とは、クラウド２０内の画像（写真）を閲覧する（見る）ためのアプリケーションであると言える。アプリケーション「ウェブアルバム」は、友達および家族などの特定の関係者との間で特定の画像を共有するために使用することができる。

アプリケーション「ウェブアルバム」に関するＱｏＥ推定は、下記のステップ１〜３によって実行することができる。

ステップ１において、端末１０は、クラウド２０内の画像の閲覧を要求することができる。具体的には、端末１０は、画像のテストデータを求める要求をクラウド２０に発行することができる。テストデータは、図４に概略的に示されているように、通常の画像の一部であってもよい。言い換えれば、テストデータは、通常の画像よりも小さいデータサイズであってもよい。テストデータは、ＱｏＥ推定のために特別に用意されてもよい。

ステップ２において、クラウド２０は、要求された画像を端末１０へ転送することができる。言い換えれば、端末１０は、クラウド２０から画像のテストデータを受信することができる。

ステップ３において、端末１０は、端末１０における画像のテストデータの要求と受信との間における転送時間を測定することができる。

ステップ４において、端末１０は、測定された転送時間に基づいてアプリケーション「ウェブアルバム」に関するＱｏＥを推定することができる。たとえば、測定された転送時間と、基準との間における関係は、ＱｏＥを推定する際の基礎であると言える。測定された転送時間が、基準による転送時間よりも十分に短い場合には、ＱｏＥは、「非常によい」と推定されることが可能である。測定された転送時間が、基準による転送時間よりも短いが、十分に短いとは言えない場合には、ＱｏＥは、「よい」と推定されることが可能である。同様に、測定された転送時間が、基準による転送時間よりも大幅に長い場合には、ＱｏＥは、「悪い」と推定されることが可能である。測定された転送時間が、基準による転送時間よりも長いが、大幅に長いとは言えない場合には、ＱｏＥは、「まずまず」と推定されることが可能である。画像のテストデータを端末１０において受信することができない場合には、ＱｏＥは、「使用不能」と推定されることが可能である。推定されたＱｏＥが、「非常によい」または「よい」のように高い場合には、ユーザには、高品質の画像を閲覧するよう推奨することができる。その一方で、推定されたＱｏＥが、「悪い」のように低い場合には、ユーザには、低品質の画像を閲覧するよう推奨することができる。

図５は、アプリケーション「ビデオ配信」に関するＱｏＥ推定の一例を示すための図である。アプリケーション「ビデオ配信」とは、クラウド２０内のビデオを閲覧する（見る）ためのアプリケーションであると言える。アプリケーション「ビデオ配信」は、［ＹｏｕＴｕｂｅ］などであってもよい。

アプリケーション「ビデオ配信」に関するＱｏＥ推定は、下記のステップ１〜３によって実行することができる。

ステップ１において、端末１０は、クラウド２０内のビデオの閲覧を要求することができる。具体的には、端末１０は、ビデオのテストデータを求める要求をクラウド２０に発行することができる。テストデータは、図５に概略的に示されているように、通常のビデオの一部であってもよい。言い換えれば、テストデータは、通常のビデオよりも小さいデータサイズであってもよい。テストデータは、ＱｏＥ推定のために特別に用意されてもよい。

ステップ２において、クラウド２０は、要求されたビデオを端末１０へ転送することができる。言い換えれば、端末１０は、クラウド２０からビデオのテストデータを受信することができる。

ステップ３において、端末１０は、端末１０におけるビデオのテストデータの要求と受信との間における転送時間を測定することができる。端末１０は、転送中のパケットロスレートを測定することもできる。

ステップ４において、端末１０は、測定された転送時間およびパケットロスレートに基づいてアプリケーション「ビデオ配信」に関するＱｏＥを推定することができる。たとえば、測定された転送時間およびパケットロスレートと、基準との間における関係は、ＱｏＥを推定する際の基礎であると言える。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも十分に小さい場合には、ＱｏＥは、「非常によい」と推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも小さいが、十分に小さいとは言えない場合には、ＱｏＥは、「よい」と推定されることが可能である。同様に、測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大幅に大きい場合には、ＱｏＥは、「悪い」と推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大きいが、大幅に大きいとは言えない場合には、ＱｏＥは、「まずまず」と推定されることが可能である。ビデオのテストデータを端末１０において受信することができない場合には、ＱｏＥは、「使用不能」と推定されることが可能である。推定されたＱｏＥが、「非常によい」または「よい」のように高い場合には、ユーザには、高品質のビデオを閲覧するよう推奨することができる。その一方で、推定されたＱｏＥが、「悪い」のように低い場合には、ユーザには、低品質のビデオを閲覧するよう推奨することができる。

図６は、アプリケーション「ＩＰ電話」に関するＱｏＥ推定の一例を示すための図である。アプリケーション「ＩＰ電話」とは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使用した電話サービスのためのアプリケーションであると言える。

アプリケーション「ＩＰ電話」に関するＱｏＥ推定は、下記のステップ１〜３によって実行することができる。

ステップ１において、端末１０は、クラウド２０内での音声の伝送を要求することができる。具体的には、端末１０は、音声のテストデータを求める要求をクラウド２０に発行することができる。テストデータは、図６に概略的に示されているように、通常の音声データの一部であってもよい。言い換えれば、テストデータは、通常の音声データよりも小さいデータサイズであってもよい。テストデータは、ＱｏＥ推定のために特別に用意されてもよい。

ステップ２において、クラウド２０は、要求された音声データを端末１０へ転送することができる。言い換えれば、端末１０は、クラウド２０から音声のテストデータを受信することができる。

ステップ３において、端末１０は、端末１０における音声のテストデータの要求と受信との間における転送時間を測定することができる。端末１０は、転送中のパケットロスレートを測定することもできる。

ステップ４において、端末１０は、測定された転送時間およびパケットロスレートに基づいてアプリケーション「ＩＰ電話」に関するＱｏＥを推定することができる。たとえば、測定された転送時間およびパケットロスレートと、基準との間における関係は、ＱｏＥを推定する際の基礎であると言える。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも十分に小さい場合には、ＱｏＥは、「非常によい」と推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも小さいが、十分に小さいとは言えない場合には、ＱｏＥは、「よい」と推定されることが可能である。同様に、測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大幅に大きい場合には、ＱｏＥは、「悪い」と推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大きいが、大幅に大きいとは言えない場合には、ＱｏＥは、「まずまず」と推定されることが可能である。音声のテストデータを端末１０において受信することができない場合には、ＱｏＥは、「使用不能」と推定されることが可能である。

図４〜図６に示されている例においては、転送時間およびパケットロスレート以外の任意の品質因子が使用されることも可能であるということに留意されたい。たとえば、品質因子は、Ｓ／Ｎなど、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）に関連した任意の因子であってもよい。さらに、転送時間およびパケットロスレートにおける変動を、品質因子として使用してもよい。同様に、転送時間およびパケットロスレートの標準偏差または分散を、品質因子として使用してもよい。

図７は、ＱｏＥを推定する際に使用される基準を設定する方法の一例を示すためのフローチャートである。このプロセスルーチンは、端末１０によって実行することができる。このプロセスルーチンは、基準の変更が要求されたときに開始されることが可能である。アプリケーションが終了されたときに、基準を変更するかどうかを決定するようユーザに促すことができる。ユーザは、いま終了されたアプリケーションについてのＱｏＥに関する出力情報が自分の経験に対応していないと感じた場合には、基準を変更することができる。任意のユーザデータを、任意のユーザインターフェースを介して端末１０に入力することが可能であるということに留意されたい。

ステップ７００においては、基準の変更が数値によって要求されているかどうかを判定することができる。基準の変更が数値によって要求されている場合には、このプロセスルーチンは、ステップ７０２へ進む。そうでない場合には、このプロセスルーチンは、ステップ７０４へ進む。

ステップ７０２においては、ユーザからの数値が入力されることが可能である。言い換えれば、端末１０は、数値を示すユーザ入力を受け取ることができる。

ステップ７０４においては、ユーザからのＱｏＥが入力されることが可能である。言い換えれば、端末１０は、ユーザが評価しているＱｏＥを示すユーザ入力を受け取ることができる。入力されるＱｏＥは、ユーザの実際の経験に基づくことが可能である。この方法においては、ユーザからのＱｏＥのデータが、アプリケーションの実行に基づいて蓄積されることが可能である。ユーザからのＱｏＥのデータは、アプリケーションごとにメモリ（データベース）内に格納されることが可能である。言い換えれば、ＱｏＥのデータは、対応するアプリケーションに関連付けられるように格納されることが可能である。

ステップ７０６においては、ユーザからのＱｏＥの蓄積されたデータに基づいて統計的な推定が実行されることが可能である。この統計的な推定は、端末１０のユーザのニーズまたは好みを推定するために実行されることが可能である。たとえば、この統計的な推定は、どの品質因子がＱｏＥに最も影響を与えるかを判定するために実行されることが可能である。

ステップ７０８においては、数値に基づいて基準が更新される（調整される）ことが可能である。たとえば、基準は、ユーザ入力に従って、より厳格にまたはより緩やかにすることができる。基準は、統計的な推定に基づいて更新される（調整される）ことが可能である。たとえば、ユーザがアプリケーション「ビデオ配信」においてスピードに最も重きを置いていることを統計的な推定が示している場合には、転送時間に関連した基準を、より厳格にすることができる。

図８は、端末１０の構成の一例を示すための機能ブロック図である。図８に示されている例は、上述のその他の例から独立して実施されることが可能であるということに留意されたい。

端末１０は、後続アクション予測部１０２、およびＱｏＥ推定トリガリング部１０４を含むことができる。

後続アクション予測部１０２は、ユーザのその後のアクションを予測することができる。言い換えれば、後続アクション予測部１０２は、端末１０のユーザがその後にどの（１つまたは複数の）アプリケーションを使用するかを予測することができる。たとえば、後続アクション予測部１０２は、端末１０のユーザが所定の時間内にどの（１つまたは複数の）アプリケーションを使用することになるかを予測することができる。その所定の時間は、ＱｏＥ推定を実行するのに必要な時間よりも長くなるように設定されてもよい。

ＱｏＥ推定トリガリング部１０４は、ＱｏＥ推定を実行するタイミングを決定することができる。ＱｏＥ推定トリガリング部１０４は、所定の間隔でＱｏＥ推定をトリガすることができる。その所定の間隔は、タイマ１０６によって測定されることが可能である。さらに、ＱｏＥ推定トリガリング部１０４は、ユーザ命令に応答してＱｏＥ推定をトリガすることができる。そのユーザ命令は、ユーザインターフェース１０８を介して入力されることが可能である。

さらに、ＱｏＥ推定トリガリング部１０４は、後続アクション予測部１０２の予測に基づいてＱｏＥ推定をトリガすることができる。言い換えれば、ＱｏＥ推定トリガリング部１０４は、次にどのアプリケーションに関してＱｏＥ推定が実行されることになるかを決定すること、およびＱｏＥ推定を開始するタイミングを決定することが可能である。アプリケーションに関するＱｏＥ推定をトリガする（開始する）タイミングは、アプリケーションが実際に実行される前に、ＱｏＥ推定に基づく推定されたＱｏＥに関する情報が出力されるようなタイミングであってもよい。

図９は、後続アクション予測部１０２およびＱｏＥ推定トリガリング部１０４のオペレーションの一例を示すためのフローチャートである。

ステップ９０２において、後続アクション予測部１０２は、端末１０上で複数のアプリケーションが実行されることになる順序を予測することができる。後続アクション予測部１０２は、統計情報１３０に基づいて、その順序を予測することができる。統計情報１３０は、過去のユーザのアクションに基づいて蓄積されることが可能である。

端末１０上で複数のアプリケーションが実行されることになる順序には、傾向が存在する場合がある。例として、下記のアクションパターンが統計情報１３０として格納されることが可能である。
アクションパターン１：電源オン（またはアクティブ化） − Ｅメール（受信） − カレンダ − ＩＰ電話 − 地図 − ストリートビュー − ＩＰ電話 − Ｅメール（受信）；
アクションパターン２：電源オン（またはアクティブ化） − Ｅメール（受信） − ブラウザ − Ｅメール（送信） − ウェブアルバム；
アクションパターン３：電源オン（またはアクティブ化） − Ｅメール（受信） − ウェブアルバム − ＩＰ電話 − ブラウザ − カレンダ；および
アクションパターン４：電源オン（またはアクティブ化） − Ｅメール（受信） − ＩＰ電話 − ブラウザ − カレンダ。

このようなアクションパターンは、時間（朝、午後、夜、平日、週末、休日など）、場所（屋外、屋内、電車内など）などの状況または環境に関連付けられるように格納されることが可能である。この場合では、後続アクション予測部１０２は、現在の状況または環境に基づいてアクションパターンを予測することができる。さらに、後続アクション予測部１０２は、単に、最も頻繁に検知されるアクションパターンを予測することができる。

ステップ９０４において、ＱｏＥ推定トリガリング部１０４は、ステップ９０２において予測された順序に従って、それぞれのアプリケーションに関するＱｏＥ推定の順序を決定することができる。言い換えれば、ＱｏＥ推定トリガリング部１０４は、ステップ９０２において予測された順序に従って、それぞれのアプリケーションに関するＱｏＥ推定をトリガすることができる。たとえば、アクションパターン１が予測されている場合には、ＱｏＥ推定トリガリング部１０４は、アプリケーション「Ｅメール」に関するＱｏＥ推定を最初に、アプリケーション「カレンダ」に関するＱｏＥ推定を２番目に、といった具合にトリガすることができる。

ＱｏＥ推定の結果は、上述のように端末上に出力されることが可能である。

図１０は、後続アクション予測部１０２およびＱｏＥ推定トリガリング部１０４のオペレーションの別の例を示すためのフローチャートである。

ステップ１００２において、後続アクション予測部１０２は、それぞれのアプリケーションが端末１０上で実行される確率を予測することができる。

後続アクション予測部１０２は、統計情報１３０に基づいて確率を予測することができる。統計情報１３０は、過去のユーザのアクションに基づいて蓄積されることが可能である。

たとえば、後続アクション予測部１０２は、単に、それぞれのアプリケーションの使用の頻度に基づいて確率を予測することができる。この場合では、後続アクション予測部１０２は、単に、最も頻繁に使用されるアプリケーションに関する最も高い確率を予測することができる。

後続アクション予測部１０２は、現在使用されているアプリケーションに関する情報１４０および統計情報１３０に基づいて確率を予測することができる。たとえば、アクションパターン１〜４が統計情報１３０として格納されている場合では、Ｅメールを受信するためにアプリケーション「Ｅメール」を使用した後には、次いで４つのアプリケーション、すなわち、カレンダ、ブラウザ、ウェブアルバム、およびＩＰ電話が使用される場合がある。したがって、後続アクション予測部１０２は、これらの４つのアプリケーションについての確率を高めることができる。この場合では、後続アクション予測部１０２は、これらの４つのアプリケーションの間における使用の頻度を比較して、それらのアプリケーションのうちで最も高い確率を有するアプリケーションを判定することができる。

後続アクション予測部１０２は、Ｅメールコンテンツに関する情報１４０に基づいて確率を予測することができる。それらのＥメールコンテンツは、端末１０上で現在開かれている（表示されている）Ｅメールのコンテンツであってもよい。言い換えれば、それらのＥメールコンテンツは、端末１０のユーザが現在閲覧しているＥメールのコンテンツであってもよい。Ｅメールコンテンツは、日付情報、スケジュールの問合せなどを含む場合がある。Ｅメールコンテンツは、ウェブリンクを含む場合がある。Ｅメールコンテンツは、その中に添付されている画像ファイル、およびその中に添付されているビデオファイルを含む場合がある。Ｅメールコンテンツは、ＩＰ電話番号を伴うまたは伴わない通話を求めるメッセージを含む場合がある。これらのコンテンツは、端末１０のアナライザによって分析されることが可能である。この場合では、Ｅメールコンテンツが、日付情報、スケジュールの問合せなどを含む場合には、後続アクション予測部１０２は、たとえば、アプリケーション「カレンダ」に関する確率が高くなると予測することができる。同様に、Ｅメールコンテンツが、ウェブリンクを含む場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ブラウザ」に関する確率が高くなると予測することができる。Ｅメールコンテンツが、画像ファイルを含む場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ウェブアルバム」に関する確率が高くなると予測することができる。Ｅメールコンテンツが、ビデオファイルを含む場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ビデオ配信」に関する確率が高くなると予測することができる。Ｅメールコンテンツが、通話を求めるメッセージを含む場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰ電話」に関する確率が高くなると予測することができる。

後続アクション予測部１０２は、Ｅメールコンテンツを伴う場合と同様に、ウェブコンテンツに関する情報１４０に基づいて確率を予測することができる。

後続アクション予測部１０２は、日付および時間に関する情報１４０に基づいて確率を予測することができる。週末（すなわち、土曜日および日曜日）の場合では、後続アクション予測部１０２は、たとえば、アプリケーション「音楽」、「ゲーム」、「ナビゲーション」、「ウェブアルバム」、および「ニュース（とりわけ、一般、経済）」に関する確率が高くなると予測することができる。平日の場合では、後続アクション予測部１０２は、たとえば、アプリケーション「ニュース」に関する確率が高くなると予測することができる。朝の場合では、後続アクション予測部１０２は、たとえば、アプリケーション「スケジュール」、「Ｅメール（読む）」、および「ニュース（とりわけ、天気、交通情報）」に関する確率が高くなると予測することができる。午後または夕方の場合では、後続アクション予測部１０２は、たとえば、アプリケーション「Ｅメール（書く）」に関する確率が高くなると予測することができる。夜の場合では、後続アクション予測部１０２は、たとえば、アプリケーション「音楽」、「ゲーム」、「ナビゲーション」、「ウェブアルバム」、および「ニュース（とりわけ、一般、経済）」に関する確率が高くなると予測することができる。

後続アクション予測部１０２は、端末１０内に取り付けられているセンサからの情報１２０に基づいて確率を予測することができる。センサからの情報１２０は、端末１０が配置されている環境を示すような情報であってもよい。たとえば、センサは、ＧＰＳ受信機、加速度計（または振動センサ）、照度センサ、マイクロフォンセンサ（インターフェース）、電源接続センサ（インターフェース）、およびイヤフォン接続センサ（インターフェース）のうちの少なくとも１つを含むことができる。

たとえば、後続アクション予測部１０２は、ＧＰＳ受信機からの情報に基づいて、端末１０のユーザが移動しているか、または止まっているかを判定することができる。ユーザが移動している場合には、後続アクション予測部１０２は、たとえば、アプリケーション「Ｅメール」および「ＩＰＴＶ」に関する確率が高くなると予測することができる。その一方で、ユーザが移動している場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰ電話」に関する確率が低くなると予測することができる。ユーザが止まっている場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＴＶ会議」、「ブラウザ（ウェブ）」、および「ＩＰ電話」に関する確率が高くなると予測することができる。

ＧＰＳ受信機からの情報および地図情報は、ユーザ（すなわち、端末１００）の場所を推測するために相互参照されることが可能である。言い換えれば、カーナビゲーションの分野において使用されているマップマッチング技術を使用することができる。ユーザが電車内にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰＴＶ」、「Ｅメール」、および「ツイッター」に関する確率が高くなると予測することができる。ユーザが道路沿いを歩いている場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰ電話」、「ラジオ」、「地図」、および「ストリートビュー」に関する確率が高くなると予測することができる。ユーザが車を運転している場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ナビゲーション」に関する確率が高くなると予測することができる。ユーザが図書館にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「Ｅメール」および「地図」に関する確率が高くなると予測することができる。その一方で、ユーザが図書館にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰ電話」および「ＴＶ会議」に関する確率が低くなると予測することができる。ユーザが銀行にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ニュース（とりわけ、株式、外国為替）」、「ＩＰ電話」、および「Ｅメール」に関する確率が高くなると予測することができる。上述のＧＰＳ受信機の場合と同様に、加速度計が使用されることも可能であるということに留意されたい。

後続アクション予測部１０２は、端末１０のユーザが屋外環境にいるか、屋内環境にいるか、または暗い環境にいるかを判定することができる。ユーザが屋外環境にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ナビゲーション」、「地図」、および「ストリートビュー」に関する確率が高くなると予測することができる。ユーザが屋内環境にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ブラウザ」、「ゲーム」、「Ｅメール」、「ツイッター」、および「ＩＰＴＶ」に関する確率が高くなると予測することができる。ユーザが暗い環境にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「音楽」に関する確率が高くなると予測することができる。

後続アクション予測部１０２は、マイクロフォンセンサによって検知される音に基づいて、ユーザが電車内にいるか、または車を運転しているかを判定することができる。ユーザが電車内にいる場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰＴＶ」、「Ｅメール」、および「ツイッター」に関する確率が高くなると予測することができる。ユーザが車を運転している場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ナビゲーション」に関する確率が高くなると予測することができる。

さらに、マイクロフォンが端末１０に接続されている場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰ電話」に関する確率が高くなると予測することができる。同様に、イヤフォンが端末１０に接続されていることがイヤフォン接続センサによって検知された場合には、後続アクション予測部１０２は、たとえば、アプリケーション「ＩＰＴＶ」、「ＩＰ電話」、「ラジオ」、および「音楽」に関する確率が高くなると予測することができる。さらに、端末１０のバッテリーが充電されている最中であるということが電源接続センサによって検知された場合には、後続アクション予測部１０２は、ユーザが屋内環境にいると判定することができ、ひいては、たとえば、アプリケーション「ブラウザ」、「ゲーム」、「Ｅメール」、「ツイッター」、および「ＩＰＴＶ」に関する確率が高くなると予測することができる。

ステップ１００４において、ＱｏＥ推定トリガリング部１０４は、ステップ９０２において予測された確率に従って、それぞれのアプリケーションに関するＱｏＥ推定の順序を決定することができる。言い換えれば、ＱｏＥ推定トリガリング部１０４は、ステップ９０２において予測された確率に従って、それぞれのアプリケーションに関するＱｏＥ推定をトリガすることができる。たとえば、ＱｏＥ推定トリガリング部１０４は、確率の高い順にそれぞれのアプリケーションに関するＱｏＥ推定をトリガすることができる。さらに、ＱｏＥ推定トリガリング部１０４は、所定のしきい値よりも小さい確率を有する（１つまたは複数の）アプリケーションに関しては、ＱｏＥ推定をトリガするのをやめることができる。言い換えれば、ＱｏＥ推定トリガリング部１０４は、ＱｏＥ推定が実行されることになるアプリケーションを絞り込むことができる。

ＱｏＥ推定の結果は、上述のように端末上に出力されることが可能である。たとえば、確率を判定するために、Ｅメールコンテンツまたはウェブコンテンツに関する情報１４０が使用されている場合には、ＱｏＥ推定の結果は、当該Ｅメールまたはウェブサイト上に出力されることが可能である。この場合では、推定されたＱｏＥに関する情報は、ウェブリンク、添付されている画像ファイル、添付されているビデオファイル、ＩＰ電話番号などのうちの少なくとも１つのステータス（たとえば、色）が、対応するアプリケーションに関する推定されたＱｏＥに従って変更されるように、端末１０上に出力されることが可能である。たとえば、アプリケーション「ブラウザ」に関する推定されたＱｏＥが「悪い」場合には、通常は青色であるウェブリンクの色が、「赤色」に変更されることが可能である。

上述の順序および確率は、上述の要素の任意の組合せを使用して特定されることが可能であるということに留意されたい。たとえば、後続アクション予測部１０２は、統計情報１３０、現在使用されているアプリケーションに関する情報１４０、Ｅメールコンテンツに関する情報１４０、日付および時間に関する情報１４０、端末１０内に取り付けられているセンサからの情報１２０の任意の組合せに基づいて、それぞれのアプリケーションが実行される確率を予測することができる。

後続アクション予測部１０２の機能は、クラウド２０によって実施されることが可能であるということもわかる。たとえば、クラウド２０は、ユーザ全般のアプリケーション操作の履歴に関する統計情報を格納すること、ならびに、端末１０のユーザに固有の行動、およびユーザ全般に固有の行動の両方に関する情報に基づいて、次なるアプリケーションおよびその操作を予測することが可能である。

前述の詳細な説明のうちのいくつかの部分は、コンピュータメモリなどのコンピューティングシステムメモリ内に格納されているデータビットまたはバイナリデジタル信号上のオペレーションのアルゴリズムまたはシンボル表示という点から提示されている。これらのアルゴリズム的な記述または表示は、データ処理技術分野における標準的な技術者が自分の作業の実体を他の当業者たちに伝達するために使用する技術の例である。アルゴリズムとは、ここでは、および一般には、所望の結果へつながるオペレーションまたは類似の処理の首尾一貫したシーケンスであるとみなされている。このコンテキストにおいては、オペレーションまたは処理は、物理量の物理的な操作を含む。典型的には、必須ではないが、そのような量は、格納すること、転送すること、結合すること、比較すること、またはその他の形で操作することが可能な電気信号または磁気信号の形態を取ることができる。ビット、データ、値、要素、シンボル、文字、語、数、数字などとしてそのような信号を指すことが、主として共通の使用という理由から、時として便利であることがわかっている。しかしながら、これらおよび類似の語はすべて、適切な物理量に関連付けられるものであり、便宜上のラベルにすぎないということを理解されたい。特に別段の記載がない限り、以降の論考から明らかなように、本明細書を通じて、「処理する」、「算出する」、「計算する」、「判定する」などの語を利用している論考は、コンピューティングデバイスのメモリ、レジスタ、またはその他の情報記憶装置、伝送装置、もしくは表示装置内の物理的、電子的、または磁気的な量として表されているデータを操作または変換する、コンピューティングデバイスのアクションまたはプロセスを指すということに留意されたい。

前述の詳細な説明では、ブロック図、フローチャート、および／または例の使用によって、装置および／またはプロセスのさまざまな実施形態を説明してきた。そのようなブロック図、フローチャート、および／または例が１つまたは複数の機能および／または動作を含む限りにおいて、そのようなブロック図、フローチャート、または例の中のそれぞれの機能および／または動作は、広範囲のハードウェア、ソフトウェア、ファームウェア、または実質上それらのすべての組合せにより、個別におよび／または集合的に実装可能であることが、当業者には理解されるであろう。いくつかの実施形態では、本明細書に記載された主題のいくつかの部分は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタルシグナルプロセッサ（ＤＳＰ）、または他の集積化方式によって実装することができる。しかし、本明細書で開示された実施形態のいくつかの態様が、全体においてまたは一部において、１つまたは複数のコンピュータ上で動作する１つまたは複数のコンピュータプログラムとして（たとえば、１つまたは複数のコンピュータシステム上で動作する１つまたは複数のプログラムとして）、１つまたは複数のプロセッサ上で動作する１つまたは複数のプログラムとして（たとえば、１つまたは複数のマイクロプロセッサ上で動作する１つまたは複数のプログラムとして）、ファームウェアとして、あるいは実質上それらの任意の組合せとして、等価に集積回路に実装することができることを、当業者は認識するであろうし、電気回路の設計ならびに／またはソフトウェアおよび／もしくはファームウェアのコーディングが、本開示に照らして十分当業者の技能の範囲内であることを、当業者は認識するであろう。さらに、本明細書に記載された主題のメカニズムをさまざまな形式のプログラム製品として配布することができることを、当業者は理解するであろうし、本明細書に記載された主題の例示的な実施形態が、実際に配布を実行するために使用される信号伝達媒体の特定のタイプにかかわらず適用されることを、当業者は理解するであろう。信号伝達媒体の例には、フレキシブルディスク、ハードディスクドライブ（ＨＤＤ）、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）、デジタルテープ、コンピュータメモリ、などの記録可能なタイプの媒体、ならびに、デジタル通信媒体および／またはアナログ通信媒体（たとえば、光ファイバケーブル、導波管、有線通信リンク、無線通信リンクなど）の通信タイプの媒体が含まれるが、それらには限定されない。

本明細書に記載された主題は、さまざまなコンポーネントをしばしば例示しており、これらのコンポーネントは、他のさまざまなコンポーネントに包含されるか、または他のさまざまなコンポーネントに接続される。そのように図示されたアーキテクチャは、単に例にすぎず、実際には、同じ機能を実現する多くの他のアーキテクチャが実装可能であることが理解されよう。概念的な意味で、同じ機能を実現するコンポーネントの任意の構成は、所望の機能が実現されるように効果的に「関連付け」される。したがって、特定の機能を実現するために組み合わされた、本明細書における任意の２つのコンポーネントは、アーキテクチャまたは中間のコンポーネントにかかわらず、所望の機能が実現されるように、お互いに「関連付け」されていると見ることができる。同様に、そのように関連付けされた任意の２つのコンポーネントは、所望の機能を実現するために、互いに「動作可能に接続」または「動作可能に結合」されているとみなすこともでき、そのように関連付け可能な任意の２つのコンポーネントは、所望の機能を実現するために、互いに「動作可能に結合できる」とみなすこともできる。動作可能に結合できる場合の具体例には、物理的にかみ合わせ可能な、および／もしくは物理的に相互作用するコンポーネント、ならびに／またはワイヤレスに相互作用可能な、および／もしくはワイヤレスに相互作用するコンポーネント、ならびに／または論理的に相互作用する、および／もしくは論理的に相互作用可能なコンポーネントが含まれるが、それらに限定されない。

本明細書における実質的にすべての複数形および／または単数形の用語の使用に対して、当業者は、状況および／または用途に適切なように、複数形から単数形に、および／または単数形から複数形に変換することができる。さまざまな単数形／複数形の置き換えは、理解しやすいように、本明細書で明確に説明することができる。

通常、本明細書において、特に添付の特許請求の範囲（たとえば、添付の特許請求の範囲の本体部）において使用される用語は、全体を通じて「オープンな（ｏｐｅｎ）」用語として意図されていることが、当業者には理解されよう（たとえば、用語「含む（ｉｎｃｌｕｄｉｎｇ）」は、「含むがそれに限定されない（ｉｎｃｌｕｄｉｎｇ ｂｕｔ ｎｏｔ ｌｉｍｉｔｅｄ ｔｏ）」と解釈されるべきであり、用語「有する（ｈａｖｉｎｇ）」は、「少なくとも有する（ｈａｖｉｎｇ ａｔ ｌｅａｓｔ）」と解釈されるべきであり、用語「含む（ｉｎｃｌｕｄｅｓ）」は、「含むがそれに限定されない（ｉｎｃｌｕｄｅｓ ｂｕｔ ｉｓ ｎｏｔ ｌｉｍｉｔｅｄ ｔｏ）」と解釈されるべきである、など）。導入される請求項で具体的な数の記載が意図される場合、そのような意図は、当該請求項において明示的に記載されることになり、そのような記載がない場合、そのような意図は存在しないことが、当業者にはさらに理解されよう。たとえば、理解の一助として、添付の特許請求の範囲は、導入句「少なくとも１つの（ａｔ ｌｅａｓｔ ｏｎｅ）」および「１つまたは複数の（ｏｎｅ ｏｒ ｍｏｒｅ）」を使用して請求項の記載を導くことを含む場合がある。しかし、そのような句の使用は、同一の請求項が、導入句「１つまたは複数の」または「少なくとも１つの」および「ａ」または「ａｎ」などの不定冠詞を含む場合であっても、不定冠詞「ａ」または「ａｎ」による請求項の記載の導入が、そのように導入される請求項の記載を含む任意の特定の請求項を、単に１つのそのような記載を含む発明に限定する、ということを示唆していると解釈されるべきではない（たとえば、「ａ」および／または「ａｎ」は、通常、「少なくとも１つの」または「１つまたは複数の」を意味すると解釈されるべきである）。同じことが、請求項の記載を導入するのに使用される定冠詞の使用にも当てはまる。また、導入される請求項の記載で具体的な数が明示的に記載されている場合でも、そのような記載は、通常、少なくとも記載された数を意味すると解釈されるべきであることが、当業者には理解されよう（たとえば、他の修飾語なしでの「２つの記載（ｔｗｏ ｒｅｃｉｔａｔｉｏｎｓ）」の単なる記載は、通常、少なくとも２つの記載、または２つ以上の記載を意味する）。さらに、「Ａ、ＢおよびＣ、などの少なくとも１つ」に類似の慣例表現が使用されている事例では、通常、そのような構文は、当業者がその慣例表現を理解するであろう意味で意図されている（たとえば、「Ａ、Ｂ、およびＣの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢを共に、ＡおよびＣを共に、ＢおよびＣを共に、ならびに／またはＡ、Ｂ、およびＣを共に、などを有するシステムを含むが、それに限定されない）。「Ａ、Ｂ、またはＣ、などの少なくとも１つ」に類似の慣例表現が使用されている事例では、通常、そのような構文は、当業者がその慣例表現を理解するであろう意味で意図されている（たとえば、「Ａ、Ｂ、またはＣの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢを共に、ＡおよびＣを共に、ＢおよびＣを共に、ならびに／またはＡ、Ｂ、およびＣを共に、などを有するシステムを含むが、それに限定されない）。２つ以上の代替用語を提示する事実上いかなる離接する語および／または句も、明細書、特許請求の範囲、または図面のどこにあっても、当該用語の一方（ｏｎｅ ｏｆ ｔｈｅ ｔｅｒｍｓ）、当該用語のいずれか（ｅｉｔｈｅｒ ｏｆ ｔｈｅ ｔｅｒｍｓ）、または両方の用語（ｂｏｔｈ ｔｅｒｍｓ）を含む可能性を企図すると理解されるべきであることが、当業者にはさらに理解されよう。たとえば、句「ＡまたはＢ」は、「Ａ」または「Ｂ」あるいは「ＡおよびＢ」の可能性を含むことが理解されよう。

本明細書においてさまざまな方法およびシステムを使用して特定の例示的な技術について説明し、示してきたが、特許請求されている主題から逸脱することなく、その他のさまざまな修正を行うことができ、均等物を代用することができるということを当業者なら理解するはずである。加えて、本明細書に記載されている中核となるコンセプトから逸脱することなく、特定の状況を、特許請求されている主題の教示に適合させるために、多くの修正を行うことができる。したがって、特許請求されている主題は、開示されている特定の例に限定されるものではなく、そのような特許請求されている主題は、添付の特許請求の範囲およびその均等物の範囲内に収まるすべての実施態様を含むこともできるということが意図されている。

Claims (14)

1. 推定されたＱｏＥに関する情報を、複数のアプリケーションが実行されることを可能とする端末上に出力する方法であって、
   前記端末内に取り付けられているセンサからの情報および統計情報のうちの少なくとも１つに基づいて、前記端末上で最初に実行されることになる第１のアプリケーションを予測すること、
   前記第１のアプリケーションが実際に実行される前に、前記第１のアプリケーションに関するＱｏＥ推定を実行することであり、当該ＱｏＥ推定が、前記第１のアプリケーションに関連付けられているテストデータを求める要求をクラウドに発行すること、前記クラウドから前記テストデータを受信すること、前記受信されたテストデータに基づいて品質因子を測定すること、および、前記測定された品質因子と、対応する基準との間における関係に基づいてＱｏＥを推定することによって実行され、前記基準が、前記端末のユーザデータに基づいて設定されていること、
   前記第１のアプリケーションに関する前記ＱｏＥ推定に基づいて、前記第１のアプリケーションに関する推定されたＱｏＥに関する情報を前記端末上に出力すること、
   前記端末内に取り付けられているセンサからの前記情報および前記統計情報のうちの少なくとも１つに基づいて、前記端末上で前記第１のアプリケーションの次に実行されることになる第２のアプリケーションを予測すること、
   前記第１のアプリケーションに関する前記ＱｏＥ推定が実行された後に、前記第２のアプリケーションに関するＱｏＥ推定を実行することであり、当該ＱｏＥ推定が、前記第２のアプリケーションに関連付けられているテストデータを求める要求を前記クラウドに発行すること、前記クラウドから前記テストデータを受信すること、前記受信されたテストデータに基づいて品質因子を測定すること、および前記測定された品質因子と、対応する基準との間における関係に基づいてＱｏＥを推定することによって実行され、前記基準が、前記端末の前記ユーザデータに基づいて設定されていること、ならびに
   前記第２のアプリケーションに関する前記ＱｏＥ推定に基づいて、前記第２のアプリケーションについての推定されたＱｏＥに関する情報を前記端末上に出力すること、
   を含む前記方法。
2. 推定されたＱｏＥに関する情報を、複数のアプリケーションが実行されることが可能である端末上に出力する方法であって、
   前記複数のアプリケーションごとにＱｏＥ推定を実行すること、および、
   前記ＱｏＥ推定に基づいて、推定されたＱｏＥに関する情報を前記端末上に出力することを含み、
   前記ＱｏＥ推定が、テストデータを求める要求をクラウドに発行すること、前記クラウドから前記テストデータを受信すること、前記受信されたテストデータに基づいて少なくとも１つの品質因子を測定すること、および前記測定された品質因子と、基準との間における関係に基づいてＱｏＥを推定することによって実行され、前記基準が、前記端末の前記ユーザデータに基づいて設定されている、方法。
3. 前記アプリケーションが、前記クラウド内の画像を閲覧するためのアプリケーションを含み、前記テストデータが、画像データであり、前記画像を閲覧するための前記アプリケーションに関連付けられている前記品質因子が、前記端末における前記画像データの前記要求と前記受信との間における転送時間を含む、請求項２に記載の方法。
4. 前記アプリケーションが、前記クラウド内のビデオを閲覧するためのアプリケーションを含み、前記テストデータが、ビデオデータであり、前記ビデオを閲覧するための前記アプリケーションに関連付けられている前記品質因子が、２つの因子を含み、前記因子が、前記端末における前記ビデオデータの前記要求と前記受信との間における転送時間、および前記ビデオデータの前記転送中のパケットロスレートである、請求項２に記載の方法。
5. 前記アプリケーションが、前記クラウドを介したＩＰ電話のためのアプリケーションを含み、前記テストデータが、音声データであり、ＩＰ電話のための前記アプリケーションに関連付けられている前記品質因子が、２つの因子を含み、前記因子が、前記端末における前記音声データの前記要求と前記受信との間における転送時間、および前記音声データの前記転送中のパケットロスレートである、請求項２に記載の方法。
6. 推定されたＱｏＥに関する情報を、複数のアプリケーションが実行されることが可能である端末上に出力する方法であって、
   前記複数のアプリケーションごとにＱｏＥ推定を実行すること、および、
   前記ＱｏＥ推定に基づいて、推定されたＱｏＥに関する情報を前記端末上に出力することを含み、
   推定されたＱｏＥに関する前記情報を前記端末上に出力することが、前記端末上に表示されるアイコンの色を前記ＱｏＥ推定に従って変更することを含み、前記それぞれのアイコンが、前記対応するアプリケーションを開始するために提供されている、方法。
7. 推定されたＱｏＥに関する情報を、複数のアプリケーションが実行されることが可能である端末上に出力する方法であって、
   前記複数のアプリケーションごとにＱｏＥ推定を実行すること、および、
   前記ＱｏＥ推定に基づいて、推定されたＱｏＥに関する情報を前記端末上に出力することを含み、
   前記端末上で複数のアプリケーションが実行されることになる順序を統計情報に基づいて予測することをさらに含み、
   前記それぞれのアプリケーションに関する前記ＱｏＥ推定の順序が、前記予測された順序に従って決定される、方法。
8. 前記統計情報が、前記アプリケーションの使用の履歴を示す情報である、請求項７に記載の方法。
9. 推定されたＱｏＥに関する情報を、複数のアプリケーションが実行されることが可能である端末上に出力する方法であって、
   前記複数のアプリケーションごとにＱｏＥ推定を実行すること、および、
   前記ＱｏＥ推定に基づいて、推定されたＱｏＥに関する情報を前記端末上に出力することを含み、
   前記それぞれのアプリケーションが前記端末上で実行される確率を、前記端末内に取り付けられているセンサからの情報に基づいて予測することをさらに含み、
   前記ＱｏＥ推定が実行されることになる前記アプリケーションが、前記予測された確率に従って決定される、方法。
10. センサからの前記情報が、前記端末が配置されている環境を示す情報である、請求項９に記載の方法。
11. 前記センサが、ＧＰＳ受信機、加速度計、マイクロフォンセンサ、照度センサ、電源接続センサ、およびイヤフォン接続センサのうちの少なくとも１つを含む、請求項１０に記載の方法。
12. 推定されたＱｏＥに関する情報を、複数のアプリケーションが実行されることが可能である端末上に出力する方法であって、
    前記複数のアプリケーションごとにＱｏＥ推定を実行すること、および、
    前記ＱｏＥ推定に基づいて、推定されたＱｏＥに関する情報を前記端末上に出力することを含み、
    前記端末上で前記それぞれのアプリケーションが実行される確率を、前記端末上に現在表示されている情報に基づいて予測することをさらに含み、前記ＱｏＥ推定が実行されることになる前記アプリケーションが、前記予測された確率に従って決定される、方法。
13. 前記端末上に現在表示されている前記情報が、ウェブリンク、添付されている画像ファイル、添付されているビデオファイル、ＩＰ電話番号、およびＥメールアドレスのうちの少なくとも１つを含み、
    前記ＱｏＥ推定が、前記端末上に現在表示されている前記情報に関連付けられている前記アプリケーションに関して実行される、請求項１２に記載の方法。
14. 推定されたＱｏＥに関する前記情報を前記端末上に出力することが、前記ウェブリンク、前記添付されている画像ファイル、前記添付されているビデオファイル、前記ＩＰ電話番号、および前記Ｅメールアドレスのうちの少なくとも１つのステータスを、前記対応するアプリケーションに関する前記ＱｏＥ推定に従って変更することを含む、請求項１３に記載の方法。