推定されたQoEに関する情報を、複数のアプリケーションが実行されることを可能とする端末上に出力する方法であって、前記端末内に取り付けられているセンサからの情報および統計情報のうちの少なくとも1つに基づいて、前記端末上で最初に実行されることになる第1のアプリケーションを予測すること、前記第1のアプリケーションが実際に実行される前に、前記第1のアプリケーションに関するQoE推定を実行することであり、当該QoE推定が、前記第1のアプリケーションに関連付けられているテストデータを求める要求をクラウドに発行すること、前記クラウドから前記テストデータを受信すること、前記受信されたテストデータに基づいて品質因子を測定すること、および、前記測定された品質因子と、対応する基準との間における関係に基づいてQoEを推定することによって実行され、前記基準が、前記端末のユーザデータに基づいて設定されていること、前記第1のアプリケーションに関する前記QoE推定に基づいて、前記第1のアプリケーションに関する推定されたQoEに関する情報を前記端末上に出力すること、前記端末内に取り付けられているセンサからの前記情報および前記統計情報のうちの少なくとも1つに基づいて、前記端末上で前記第1のアプリケーションの次に実行されることになる第2のアプリケーションを予測すること、前記第1のアプリケーションに関する前記QoE推定が実行された後に、前記第2のアプリケーションに関するQoE推定を実行することであり、当該QoE推定が、前記第2のアプリケーションに関連付けられているテストデータを求める要求を前記クラウドに発行すること、前記クラウドから前記テストデータを受信すること、前記受信されたテストデータに基づいて品質因子を測定すること、および前記測定された品質因子と、対応する基準との間における関係に基づいてQoEを推定することによって実行され、前記基準が、前記端末の前記ユーザデータに基づいて設定されていること、ならびに前記第2のアプリケーションに関する前記QoE推定に基づいて、前記第2のアプリケーションについての推定されたQoEに関する情報を前記端末上に出力すること、を含む前記方法。推定されたQoEに関する情報を、複数のアプリケーションが実行されることが可能である端末上に出力する方法であって、前記複数のアプリケーションごとにQoE推定を実行すること、および、前記QoE推定に基づいて、推定されたQoEに関する情報を前記端末上に出力することを含む前記方法。前記QoE推定が、基準を使用して実行され、前記基準が、前記端末のユーザデータに基づいて設定されている、請求項2に記載の方法。前記QoE推定が、テストデータを求める要求をクラウドに発行すること、前記クラウドから前記テストデータを受信すること、前記受信されたテストデータに基づいて少なくとも1つの品質因子を測定すること、および前記測定された品質因子と、基準との間における関係に基づいてQoEを推定することによって実行され、前記基準が、前記端末の前記ユーザデータに基づいて設定されている、請求項2に記載の方法。前記アプリケーションが、前記クラウド内の画像を閲覧するためのアプリケーションを含み、前記テストデータが、画像データであり、前記画像を閲覧するための前記アプリケーションに関連付けられている前記品質因子が、前記端末における前記画像データの前記要求と前記受信との間における転送時間を含む、請求項4に記載の方法。前記アプリケーションが、前記クラウド内のビデオを閲覧するためのアプリケーションを含み、前記テストデータが、ビデオデータであり、前記ビデオを閲覧するための前記アプリケーションに関連付けられている前記品質因子が、2つの因子を含み、前記因子が、前記端末における前記ビデオデータの前記要求と前記受信との間における転送時間、および前記ビデオデータの前記転送中のパケットロスレートである、請求項4に記載の方法。前記アプリケーションが、前記クラウドを介したIP電話のためのアプリケーションを含み、前記テストデータが、音声データであり、IP電話のための前記アプリケーションに関連付けられている前記品質因子が、2つの因子を含み、前記因子が、前記端末における前記音声データの前記要求と前記受信との間における転送時間、および前記音声データの前記転送中のパケットロスレートである、請求項4に記載の方法。推定されたQoEに関する前記情報を前記端末上に出力することが、前記端末上に表示されるアイコンの色を前記QoE推定に従って変更することを含み、前記それぞれのアイコンが、前記対応するアプリケーションを開始するために提供されている、請求項2に記載の方法。前記端末上で複数のアプリケーションが実行されることになる順序を統計情報に基づいて予測することをさらに含み、前記それぞれのアプリケーションに関する前記QoE推定の順序が、前記予測された順序に従って決定される、請求項2に記載の方法。前記統計情報が、前記アプリケーションの使用の履歴を示す情報である、請求項9に記載の方法。前記それぞれのアプリケーションが前記端末上で実行される確率を、前記端末内に取り付けられているセンサからの情報に基づいて予測することをさらに含み、前記QoE推定が実行されることになる前記アプリケーションが、前記予測された確率に従って決定される、請求項2に記載の方法。センサからの前記情報が、前記端末が配置されている環境を示す情報である、請求項11に記載の方法。前記センサが、GPS受信機、加速度計、マイクロフォンセンサ、照度センサ、電源接続センサ、およびイヤフォン接続センサのうちの少なくとも1つを含む、請求項12に記載の方法。前記端末上で前記それぞれのアプリケーションが実行される確率を、前記端末上に現在表示されている情報に基づいて予測することをさらに含み、前記QoE推定が実行されることになる前記アプリケーションが、前記予測された確率に従って決定される、請求項2に記載の方法。前記端末上に現在表示されている前記情報が、ウェブリンク、添付されている画像ファイル、添付されているビデオファイル、IP電話番号、およびEメールアドレスのうちの少なくとも1つを含み、前記QoE推定が、前記端末上に現在表示されている前記情報に関連付けられている前記アプリケーションに関して実行される、請求項14に記載の方法。推定されたQoEに関する前記情報を前記端末上に出力することが、前記ウェブリンク、前記添付されている画像ファイル、前記添付されているビデオファイル、前記IP電話番号、および前記Eメールアドレスのうちの少なくとも1つのステータスを、前記対応するアプリケーションに関する前記QoE推定に従って変更することを含む、請求項15に記載の方法。複数のアプリケーションが実行されることが可能である端末であって、前記複数のアプリケーションごとにQoE推定を実行すること、および、当該QoE推定に基づいて、推定されたQoEに関する情報を前記端末のディスプレイ上に出力することを行うように構成されている前記端末。したがって、推定されたQoEに関する情報を端末上に出力する有用な方法を提供することが望まれている。一実施形態によれば、推定されたQoEに関する情報を端末上に出力する方法が提供される。この方法は、アプリケーションごとにQoE推定を実行すること、およびそのQoE推定に基づいて、推定されたQoEに関する情報を端末上に出力することを含むことができる。主題は、本明細書の結びの部分において詳細に指摘され、明確に特許請求されている。本開示の前述の特徴およびその他の特徴は、添付の図面とともに以降の説明および添付の特許請求の範囲をから、より完全に明らかになるであろう。これらの図面は、本開示によるいくつかの実施形態を示しているにすぎず、したがって、本開示の範囲を限定するものとみなされるべきではないということを理解して、添付の図面の使用を通じたさらなる具体性および詳細を伴って本開示について説明する。以降の説明は、特許請求されている主題の完全な理解を提供するために、具体的な詳細とともにさまざまな例を示している。しかしながら、特許請求されている主題は、本明細書において開示されている具体的な詳細のうちのいくつかまたはそれ以上を伴わずに実施することができるということを当業者なら理解するであろう。さらに、いくつかの状況においては、特許請求されている主題を不必要にわかりにくくすることを避けるために、よく知られている方法、手順、システム、コンポーネント、および/または回路については、詳細に説明していない。以降の詳細な説明においては、添付の図面を参照し、それらの図面は、本明細書の一部を形成している。それらの図面においては、同様のシンボルは、文脈によって別段の内容が示されない限り、典型的には同様のコンポーネントを識別する。詳細な説明、図面、および特許請求の範囲に記載されている例示的な実施形態は、限定することを意図してはいない。本明細書において提示されている主題の趣旨または範囲から逸脱することなく、その他の実施形態を利用することができ、その他の変更を行うことができる。一般的に本明細書において説明され図に示されている本開示の複数の態様は、さまざまな異なる構成でアレンジすること、代用すること、組み合わせること、および設計することが可能であり、それらの構成のすべては、明示的に本開示の一部であると考えられ、本開示の一部とされるということが容易に理解できるであろう。図1は、クラウドコンピューティングの概念図を示している。図1に示されているように、端末10のユーザは、クラウド20において、またはクラウド20を介して、さまざまなアプリケーション、たとえばEメール、カレンダなどを享受することができる。端末10は、任意のタイプのものであってよい。端末10は、スマートフォン、タブレット、ラップトップコンピュータ、デスクトップコンピュータなどであってもよい。クラウド20は、端末10によってアクセスされる通信ネットワークの複数の要素を含む包含的な要素であってよい。言い換えれば、クラウド20は、アプリケーションを端末10上で実行することを可能にする複数の要素を含むことができる。クラウド20は、インターネット、およびさまざまなサービスプロバイダ、たとえば[Google]、[Yahoo]などを含むことができる。端末10は、アプリケーションごとにQoE推定を実行するように構成されることが可能である。具体的には、端末10は、端末10上で実行されることが可能であるそれぞれのアプリケーションに関するQoEQualityofExperienceをアプリケーションごとに推定するように構成されることが可能である。ここでは、アプリケーションのQoEQualityofExperienceは、ワイヤレスアクセスネットワークのステータス、コアネットワークのステータス、およびクラウド20の内部のステータスなどの因子に依存する場合がある。QoEは、ユーザによって必要とされる通信の品質を示すことができる。したがってQoEは、アプリケーションごとに異なる場合がある。さらにQoEは、ユーザごとに異なる場合がある。アプリケーションに関するQoEを推定する方法は、さまざまなものであってよい。アプリケーションごとにQoEを推定することができる限り、いかなる方法を使用することもできる。アプリケーションに関するQoEを推定する方法のいくつかの例について、以降で説明する。端末10は、それぞれのアプリケーションの推定されたQoEに関する情報を端末のディスプレイ上に出力するように構成されることが可能である。この情報は、さまざまな形で出力されることが可能である。たとえば、それぞれのアプリケーションの推定されたQoEは、端末のディスプレイ上に直接表示されることが可能である。それぞれのアプリケーションの推定されたQoEに関する情報を出力する方法のいくつかの例について、以降で説明する。図2は、端末10によって実行されるプロセスを示すためのフローチャートである。ステップ200においては、QoE推定がアプリケーションごとに実行されることが可能である。たとえば、4つのアプリケーションがある場合には、QoE推定は、それらの4つのアプリケーションのそれぞれに関して別々に実行されることが可能である。4つのアプリケーションのそれぞれに関するQoE推定のタイミングは、任意のものであってよい。たとえば、4つのアプリケーションのそれぞれに関するQoE推定は、バッチ処理として連続して実行されること、または時間をかけて間隔を置いて実行されることが可能である。QoE推定は、基準を使用して実行されてもよい。この基準は、アプリケーションごとに異なってもよい。したがって、この基準は、アプリケーションごとに設定されてもよい。この基準は、デフォルトの基準として前もって設定されてもよい。この基準は、端末のユーザデータに基づいて設定されてもよい。ユーザデータは、端末10のユーザのニーズまたは好みを示す情報を含むことができる。そのような情報は、ユーザによって端末10の実際のオペレーション中に得られるデータから統計的に導出されても、ユーザによって直接入力されてもよい。たとえば、デフォルトの基準は、ユーザからの入力に従って訂正されることが可能である。ステップ202においては、それぞれのアプリケーションの推定されたQoEに関する情報が、端末のディスプレイ上に出力されることが可能である。アプリケーションの推定されたQoEに関する情報は、アプリケーションに関するQoE推定が完了した時点で出力される更新されることが可能である。したがって、それぞれのアプリケーションの推定されたQoEに関する情報どうしは、別々のタイミングで出力され更新されてもよい。アプリケーションの推定されたQoEに関する情報は、そのアプリケーションが端末10上で実際に実行される前に出力され更新されてもよい。図3は、端末10のディスプレイ12上に表示される情報の一例を示すための図である。図3においては、一例として、7つのアプリケーションEメール、ウェブアルバム、地図、ビデオ配信、IP電話、カレンダ、およびストリートビューが、端末10上で実行されることが可能である。図3に示されているように、端末10は、アイコン14a~14gを表示するように構成されることが可能である。アイコンの数は、アプリケーションの数に依存することができる。アイコン14a~14gは、対応するアプリケーションを開始するために提供されることが可能である。言い換えれば、アイコン14a~14gは、対応するアプリケーションのためのランチャであってもよい。それぞれのアプリケーションは、対応するアイコン14a~14gがアクティブ化されたときに開始されることが可能である。アイコン14a~14gのアクティブ化は、クリック操作、タッチ操作などによって実施されることが可能である。アイコン14a~14gは、図3に示されているように、対応するアプリケーションを示す文字またはイラストを含むことができる。端末10は、端末10上に表示されるアイコンの色をQoE推定に従って変更するように構成されることが可能である。たとえば、青色は、非常によいというQoEを示すことができ、緑色は、よいというQoEを示すことができ、黄色は、まずまずというQoEを示すことができ、赤色は、悪いというQoEを示すことができ、グレーは、使用不能というQoEを示すことができる。たとえば、アイコン14aに関連付けられているアプリケーションEメールに関する推定されたQoEがよいである場合には、アイコン14aの色は、黄色に変更されることが可能である。この構成では、推定されたQoEは、色によって容易に区別することが可能である。アイコン14a~14gは、ウェブサイトまたはEメールの場合では、リンクに置き換えることが可能であるということに留意されたい。リンクは、しばしばウェブサイトまたはEメール上で提供される。この場合では、リンクは、アプリケーションを実行するためのランチャとして機能する。したがって、この場合では、リンクの色などのステータスリンクが、対応するアプリケーションの推定されたQoEに従って変更されることが可能である。図4は、アプリケーションウェブアルバムに関するQoE推定の一例を示すための図である。アプリケーションウェブアルバムとは、クラウド20内の画像写真を閲覧する見るためのアプリケーションであると言える。アプリケーションウェブアルバムは、友達および家族などの特定の関係者との間で特定の画像を共有するために使用することができる。アプリケーションウェブアルバムに関するQoE推定は、下記のステップ1~3によって実行することができる。ステップ1において、端末10は、クラウド20内の画像の閲覧を要求することができる。具体的には、端末10は、画像のテストデータを求める要求をクラウド20に発行することができる。テストデータは、図4に概略的に示されているように、通常の画像の一部であってもよい。言い換えれば、テストデータは、通常の画像よりも小さいデータサイズであってもよい。テストデータは、QoE推定のために特別に用意されてもよい。ステップ2において、クラウド20は、要求された画像を端末10へ転送することができる。言い換えれば、端末10は、クラウド20から画像のテストデータを受信することができる。ステップ3において、端末10は、端末10における画像のテストデータの要求と受信との間における転送時間を測定することができる。ステップ4において、端末10は、測定された転送時間に基づいてアプリケーションウェブアルバムに関するQoEを推定することができる。たとえば、測定された転送時間と、基準との間における関係は、QoEを推定する際の基礎であると言える。測定された転送時間が、基準による転送時間よりも十分に短い場合には、QoEは、非常によいと推定されることが可能である。測定された転送時間が、基準による転送時間よりも短いが、十分に短いとは言えない場合には、QoEは、よいと推定されることが可能である。同様に、測定された転送時間が、基準による転送時間よりも大幅に長い場合には、QoEは、悪いと推定されることが可能である。測定された転送時間が、基準による転送時間よりも長いが、大幅に長いとは言えない場合には、QoEは、まずまずと推定されることが可能である。画像のテストデータを端末10において受信することができない場合には、QoEは、使用不能と推定されることが可能である。推定されたQoEが、非常によいまたはよいのように高い場合には、ユーザには、高品質の画像を閲覧するよう推奨することができる。その一方で、推定されたQoEが、悪いのように低い場合には、ユーザには、低品質の画像を閲覧するよう推奨することができる。図5は、アプリケーションビデオ配信に関するQoE推定の一例を示すための図である。アプリケーションビデオ配信とは、クラウド20内のビデオを閲覧する見るためのアプリケーションであると言える。アプリケーションビデオ配信は、[YouTube]などであってもよい。アプリケーションビデオ配信に関するQoE推定は、下記のステップ1~3によって実行することができる。ステップ1において、端末10は、クラウド20内のビデオの閲覧を要求することができる。具体的には、端末10は、ビデオのテストデータを求める要求をクラウド20に発行することができる。テストデータは、図5に概略的に示されているように、通常のビデオの一部であってもよい。言い換えれば、テストデータは、通常のビデオよりも小さいデータサイズであってもよい。テストデータは、QoE推定のために特別に用意されてもよい。ステップ2において、クラウド20は、要求されたビデオを端末10へ転送することができる。言い換えれば、端末10は、クラウド20からビデオのテストデータを受信することができる。ステップ3において、端末10は、端末10におけるビデオのテストデータの要求と受信との間における転送時間を測定することができる。端末10は、転送中のパケットロスレートを測定することもできる。ステップ4において、端末10は、測定された転送時間およびパケットロスレートに基づいてアプリケーションビデオ配信に関するQoEを推定することができる。たとえば、測定された転送時間およびパケットロスレートと、基準との間における関係は、QoEを推定する際の基礎であると言える。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも十分に小さい場合には、QoEは、非常によいと推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも小さいが、十分に小さいとは言えない場合には、QoEは、よいと推定されることが可能である。同様に、測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大幅に大きい場合には、QoEは、悪いと推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大きいが、大幅に大きいとは言えない場合には、QoEは、まずまずと推定されることが可能である。ビデオのテストデータを端末10において受信することができない場合には、QoEは、使用不能と推定されることが可能である。推定されたQoEが、非常によいまたはよいのように高い場合には、ユーザには、高品質のビデオを閲覧するよう推奨することができる。その一方で、推定されたQoEが、悪いのように低い場合には、ユーザには、低品質のビデオを閲覧するよう推奨することができる。図6は、アプリケーションIP電話に関するQoE推定の一例を示すための図である。アプリケーションIP電話とは、IPInternetProtocolを使用した電話サービスのためのアプリケーションであると言える。アプリケーションIP電話に関するQoE推定は、下記のステップ1~3によって実行することができる。ステップ1において、端末10は、クラウド20内での音声の伝送を要求することができる。具体的には、端末10は、音声のテストデータを求める要求をクラウド20に発行することができる。テストデータは、図6に概略的に示されているように、通常の音声データの一部であってもよい。言い換えれば、テストデータは、通常の音声データよりも小さいデータサイズであってもよい。テストデータは、QoE推定のために特別に用意されてもよい。ステップ2において、クラウド20は、要求された音声データを端末10へ転送することができる。言い換えれば、端末10は、クラウド20から音声のテストデータを受信することができる。ステップ3において、端末10は、端末10における音声のテストデータの要求と受信との間における転送時間を測定することができる。端末10は、転送中のパケットロスレートを測定することもできる。ステップ4において、端末10は、測定された転送時間およびパケットロスレートに基づいてアプリケーションIP電話に関するQoEを推定することができる。たとえば、測定された転送時間およびパケットロスレートと、基準との間における関係は、QoEを推定する際の基礎であると言える。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも十分に小さい場合には、QoEは、非常によいと推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも小さいが、十分に小さいとは言えない場合には、QoEは、よいと推定されることが可能である。同様に、測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大幅に大きい場合には、QoEは、悪いと推定されることが可能である。測定された転送時間およびパケットロスレートが、基準による転送時間およびパケットロスレートよりも大きいが、大幅に大きいとは言えない場合には、QoEは、まずまずと推定されることが可能である。音声のテストデータを端末10において受信することができない場合には、QoEは、使用不能と推定されることが可能である。図4~図6に示されている例においては、転送時間およびパケットロスレート以外の任意の品質因子が使用されることも可能であるということに留意されたい。たとえば、品質因子は、S/Nなど、QoSQualityofServiceに関連した任意の因子であってもよい。さらに、転送時間およびパケットロスレートにおける変動を、品質因子として使用してもよい。同様に、転送時間およびパケットロスレートの標準偏差または分散を、品質因子として使用してもよい。図7は、QoEを推定する際に使用される基準を設定する方法の一例を示すためのフローチャートである。このプロセスルーチンは、端末10によって実行することができる。このプロセスルーチンは、基準の変更が要求されたときに開始されることが可能である。アプリケーションが終了されたときに、基準を変更するかどうかを決定するようユーザに促すことができる。ユーザは、いま終了されたアプリケーションについてのQoEに関する出力情報が自分の経験に対応していないと感じた場合には、基準を変更することができる。任意のユーザデータを、任意のユーザインターフェースを介して端末10に入力することが可能であるということに留意されたい。ステップ700においては、基準の変更が数値によって要求されているかどうかを判定することができる。基準の変更が数値によって要求されている場合には、このプロセスルーチンは、ステップ702へ進む。そうでない場合には、このプロセスルーチンは、ステップ704へ進む。ステップ702においては、ユーザからの数値が入力されることが可能である。言い換えれば、端末10は、数値を示すユーザ入力を受け取ることができる。ステップ704においては、ユーザからのQoEが入力されることが可能である。言い換えれば、端末10は、ユーザが評価しているQoEを示すユーザ入力を受け取ることができる。入力されるQoEは、ユーザの実際の経験に基づくことが可能である。この方法においては、ユーザからのQoEのデータが、アプリケーションの実行に基づいて蓄積されることが可能である。ユーザからのQoEのデータは、アプリケーションごとにメモリデータベース内に格納されることが可能である。言い換えれば、QoEのデータは、対応するアプリケーションに関連付けられるように格納されることが可能である。ステップ706においては、ユーザからのQoEの蓄積されたデータに基づいて統計的な推定が実行されることが可能である。この統計的な推定は、端末10のユーザのニーズまたは好みを推定するために実行されることが可能である。たとえば、この統計的な推定は、どの品質因子がQoEに最も影響を与えるかを判定するために実行されることが可能である。ステップ708においては、数値に基づいて基準が更新される調整されることが可能である。たとえば、基準は、ユーザ入力に従って、より厳格にまたはより緩やかにすることができる。基準は、統計的な推定に基づいて更新される調整されることが可能である。たとえば、ユーザがアプリケーションビデオ配信においてスピードに最も重きを置いていることを統計的な推定が示している場合には、転送時間に関連した基準を、より厳格にすることができる。図8は、端末10の構成の一例を示すための機能ブロック図である。図8に示されている例は、上述のその他の例から独立して実施されることが可能であるということに留意されたい。端末10は、後続アクション予測部102、およびQoE推定トリガリング部104を含むことができる。後続アクション予測部102は、ユーザのその後のアクションを予測することができる。言い換えれば、後続アクション予測部102は、端末10のユーザがその後にどの1つまたは複数のアプリケーションを使用するかを予測することができる。たとえば、後続アクション予測部102は、端末10のユーザが所定の時間内にどの1つまたは複数のアプリケーションを使用することになるかを予測することができる。その所定の時間は、QoE推定を実行するのに必要な時間よりも長くなるように設定されてもよい。QoE推定トリガリング部104は、QoE推定を実行するタイミングを決定することができる。QoE推定トリガリング部104は、所定の間隔でQoE推定をトリガすることができる。その所定の間隔は、タイマ106によって測定されることが可能である。さらに、QoE推定トリガリング部104は、ユーザ命令に応答してQoE推定をトリガすることができる。そのユーザ命令は、ユーザインターフェース108を介して入力されることが可能である。さらに、QoE推定トリガリング部104は、後続アクション予測部102の予測に基づいてQoE推定をトリガすることができる。言い換えれば、QoE推定トリガリング部104は、次にどのアプリケーションに関してQoE推定が実行されることになるかを決定すること、およびQoE推定を開始するタイミングを決定することが可能である。アプリケーションに関するQoE推定をトリガする開始するタイミングは、アプリケーションが実際に実行される前に、QoE推定に基づく推定されたQoEに関する情報が出力されるようなタイミングであってもよい。図9は、後続アクション予測部102およびQoE推定トリガリング部104のオペレーションの一例を示すためのフローチャートである。ステップ902において、後続アクション予測部102は、端末10上で複数のアプリケーションが実行されることになる順序を予測することができる。後続アクション予測部102は、統計情報130に基づいて、その順序を予測することができる。統計情報130は、過去のユーザのアクションに基づいて蓄積されることが可能である。端末10上で複数のアプリケーションが実行されることになる順序には、傾向が存在する場合がある。例として、下記のアクションパターンが統計情報130として格納されることが可能である。アクションパターン1:電源オンまたはアクティブ化-Eメール受信-カレンダ-IP電話-地図-ストリートビュー-IP電話-Eメール受信;アクションパターン2:電源オンまたはアクティブ化-Eメール受信-ブラウザ-Eメール送信-ウェブアルバム;アクションパターン3:電源オンまたはアクティブ化-Eメール受信-ウェブアルバム-IP電話-ブラウザ-カレンダ;およびアクションパターン4:電源オンまたはアクティブ化-Eメール受信-IP電話-ブラウザ-カレンダ。このようなアクションパターンは、時間朝、午後、夜、平日、週末、休日など、場所屋外、屋内、電車内などなどの状況または環境に関連付けられるように格納されることが可能である。この場合では、後続アクション予測部102は、現在の状況または環境に基づいてアクションパターンを予測することができる。さらに、後続アクション予測部102は、単に、最も頻繁に検知されるアクションパターンを予測することができる。ステップ904において、QoE推定トリガリング部104は、ステップ902において予測された順序に従って、それぞれのアプリケーションに関するQoE推定の順序を決定することができる。言い換えれば、QoE推定トリガリング部104は、ステップ902において予測された順序に従って、それぞれのアプリケーションに関するQoE推定をトリガすることができる。たとえば、アクションパターン1が予測されている場合には、QoE推定トリガリング部104は、アプリケーションEメールに関するQoE推定を最初に、アプリケーションカレンダに関するQoE推定を2番目に、といった具合にトリガすることができる。QoE推定の結果は、上述のように端末上に出力されることが可能である。図10は、後続アクション予測部102およびQoE推定トリガリング部104のオペレーションの別の例を示すためのフローチャートである。ステップ1002において、後続アクション予測部102は、それぞれのアプリケーションが端末10上で実行される確率を予測することができる。後続アクション予測部102は、統計情報130に基づいて確率を予測することができる。統計情報130は、過去のユーザのアクションに基づいて蓄積されることが可能である。たとえば、後続アクション予測部102は、単に、それぞれのアプリケーションの使用の頻度に基づいて確率を予測することができる。この場合では、後続アクション予測部102は、単に、最も頻繁に使用されるアプリケーションに関する最も高い確率を予測することができる。後続アクション予測部102は、現在使用されているアプリケーションに関する情報140および統計情報130に基づいて確率を予測することができる。たとえば、アクションパターン1~4が統計情報130として格納されている場合では、Eメールを受信するためにアプリケーションEメールを使用した後には、次いで4つのアプリケーション、すなわち、カレンダ、ブラウザ、ウェブアルバム、およびIP電話が使用される場合がある。したがって、後続アクション予測部102は、これらの4つのアプリケーションについての確率を高めることができる。この場合では、後続アクション予測部102は、これらの4つのアプリケーションの間における使用の頻度を比較して、それらのアプリケーションのうちで最も高い確率を有するアプリケーションを判定することができる。後続アクション予測部102は、Eメールコンテンツに関する情報140に基づいて確率を予測することができる。それらのEメールコンテンツは、端末10上で現在開かれている表示されているEメールのコンテンツであってもよい。言い換えれば、それらのEメールコンテンツは、端末10のユーザが現在閲覧しているEメールのコンテンツであってもよい。Eメールコンテンツは、日付情報、スケジュールの問合せなどを含む場合がある。Eメールコンテンツは、ウェブリンクを含む場合がある。Eメールコンテンツは、その中に添付されている画像ファイル、およびその中に添付されているビデオファイルを含む場合がある。Eメールコンテンツは、IP電話番号を伴うまたは伴わない通話を求めるメッセージを含む場合がある。これらのコンテンツは、端末10のアナライザによって分析されることが可能である。この場合では、Eメールコンテンツが、日付情報、スケジュールの問合せなどを含む場合には、後続アクション予測部102は、たとえば、アプリケーションカレンダに関する確率が高くなると予測することができる。同様に、Eメールコンテンツが、ウェブリンクを含む場合には、後続アクション予測部102は、たとえば、アプリケーションブラウザに関する確率が高くなると予測することができる。Eメールコンテンツが、画像ファイルを含む場合には、後続アクション予測部102は、たとえば、アプリケーションウェブアルバムに関する確率が高くなると予測することができる。Eメールコンテンツが、ビデオファイルを含む場合には、後続アクション予測部102は、たとえば、アプリケーションビデオ配信に関する確率が高くなると予測することができる。Eメールコンテンツが、通話を求めるメッセージを含む場合には、後続アクション予測部102は、たとえば、アプリケーションIP電話に関する確率が高くなると予測することができる。後続アクション予測部102は、Eメールコンテンツを伴う場合と同様に、ウェブコンテンツに関する情報140に基づいて確率を予測することができる。後続アクション予測部102は、日付および時間に関する情報140に基づいて確率を予測することができる。週末すなわち、土曜日および日曜日の場合では、後続アクション予測部102は、たとえば、アプリケーション音楽、ゲーム、ナビゲーション、ウェブアルバム、およびニュースとりわけ、一般、経済に関する確率が高くなると予測することができる。平日の場合では、後続アクション予測部102は、たとえば、アプリケーションニュースに関する確率が高くなると予測することができる。朝の場合では、後続アクション予測部102は、たとえば、アプリケーションスケジュール、Eメール読む、およびニュースとりわけ、天気、交通情報に関する確率が高くなると予測することができる。午後または夕方の場合では、後続アクション予測部102は、たとえば、アプリケーションEメール書くに関する確率が高くなると予測することができる。夜の場合では、後続アクション予測部102は、たとえば、アプリケーション音楽、ゲーム、ナビゲーション、ウェブアルバム、およびニュースとりわけ、一般、経済に関する確率が高くなると予測することができる。後続アクション予測部102は、端末10内に取り付けられているセンサからの情報120に基づいて確率を予測することができる。センサからの情報120は、端末10が配置されている環境を示すような情報であってもよい。たとえば、センサは、GPS受信機、加速度計または振動センサ、照度センサ、マイクロフォンセンサインターフェース、電源接続センサインターフェース、およびイヤフォン接続センサインターフェースのうちの少なくとも1つを含むことができる。たとえば、後続アクション予測部102は、GPS受信機からの情報に基づいて、端末10のユーザが移動しているか、または止まっているかを判定することができる。ユーザが移動している場合には、後続アクション予測部102は、たとえば、アプリケーションEメールおよびIPTVに関する確率が高くなると予測することができる。その一方で、ユーザが移動している場合には、後続アクション予測部102は、たとえば、アプリケーションIP電話に関する確率が低くなると予測することができる。ユーザが止まっている場合には、後続アクション予測部102は、たとえば、アプリケーションTV会議、ブラウザウェブ、およびIP電話に関する確率が高くなると予測することができる。GPS受信機からの情報および地図情報は、ユーザすなわち、端末100の場所を推測するために相互参照されることが可能である。言い換えれば、カーナビゲーションの分野において使用されているマップマッチング技術を使用することができる。ユーザが電車内にいる場合には、後続アクション予測部102は、たとえば、アプリケーションIPTV、Eメール、およびツイッターに関する確率が高くなると予測することができる。ユーザが道路沿いを歩いている場合には、後続アクション予測部102は、たとえば、アプリケーションIP電話、ラジオ、地図、およびストリートビューに関する確率が高くなると予測することができる。ユーザが車を運転している場合には、後続アクション予測部102は、たとえば、アプリケーションナビゲーションに関する確率が高くなると予測することができる。ユーザが図書館にいる場合には、後続アクション予測部102は、たとえば、アプリケーションEメールおよび地図に関する確率が高くなると予測することができる。その一方で、ユーザが図書館にいる場合には、後続アクション予測部102は、たとえば、アプリケーションIP電話およびTV会議に関する確率が低くなると予測することができる。ユーザが銀行にいる場合には、後続アクション予測部102は、たとえば、アプリケーションニュースとりわけ、株式、外国為替、IP電話、およびEメールに関する確率が高くなると予測することができる。上述のGPS受信機の場合と同様に、加速度計が使用されることも可能であるということに留意されたい。後続アクション予測部102は、端末10のユーザが屋外環境にいるか、屋内環境にいるか、または暗い環境にいるかを判定することができる。ユーザが屋外環境にいる場合には、後続アクション予測部102は、たとえば、アプリケーションナビゲーション、地図、およびストリートビューに関する確率が高くなると予測することができる。ユーザが屋内環境にいる場合には、後続アクション予測部102は、たとえば、アプリケーションブラウザ、ゲーム、Eメール、ツイッター、およびIPTVに関する確率が高くなると予測することができる。ユーザが暗い環境にいる場合には、後続アクション予測部102は、たとえば、アプリケーション音楽に関する確率が高くなると予測することができる。後続アクション予測部102は、マイクロフォンセンサによって検知される音に基づいて、ユーザが電車内にいるか、または車を運転しているかを判定することができる。ユーザが電車内にいる場合には、後続アクション予測部102は、たとえば、アプリケーションIPTV、Eメール、およびツイッターに関する確率が高くなると予測することができる。ユーザが車を運転している場合には、後続アクション予測部102は、たとえば、アプリケーションナビゲーションに関する確率が高くなると予測することができる。さらに、マイクロフォンが端末10に接続されている場合には、後続アクション予測部102は、たとえば、アプリケーションIP電話に関する確率が高くなると予測することができる。同様に、イヤフォンが端末10に接続されていることがイヤフォン接続センサによって検知された場合には、後続アクション予測部102は、たとえば、アプリケーションIPTV、IP電話、ラジオ、および音楽に関する確率が高くなると予測することができる。さらに、端末10のバッテリーが充電されている最中であるということが電源接続センサによって検知された場合には、後続アクション予測部102は、ユーザが屋内環境にいると判定することができ、ひいては、たとえば、アプリケーションブラウザ、ゲーム、Eメール、ツイッター、およびIPTVに関する確率が高くなると予測することができる。ステップ1004において、QoE推定トリガリング部104は、ステップ902において予測された確率に従って、それぞれのアプリケーションに関するQoE推定の順序を決定することができる。言い換えれば、QoE推定トリガリング部104は、ステップ902において予測された確率に従って、それぞれのアプリケーションに関するQoE推定をトリガすることができる。たとえば、QoE推定トリガリング部104は、確率の高い順にそれぞれのアプリケーションに関するQoE推定をトリガすることができる。さらに、QoE推定トリガリング部104は、所定のしきい値よりも小さい確率を有する1つまたは複数のアプリケーションに関しては、QoE推定をトリガするのをやめることができる。言い換えれば、QoE推定トリガリング部104は、QoE推定が実行されることになるアプリケーションを絞り込むことができる。QoE推定の結果は、上述のように端末上に出力されることが可能である。たとえば、確率を判定するために、Eメールコンテンツまたはウェブコンテンツに関する情報140が使用されている場合には、QoE推定の結果は、当該Eメールまたはウェブサイト上に出力されることが可能である。この場合では、推定されたQoEに関する情報は、ウェブリンク、添付されている画像ファイル、添付されているビデオファイル、IP電話番号などのうちの少なくとも1つのステータスたとえば、色が、対応するアプリケーションに関する推定されたQoEに従って変更されるように、端末10上に出力されることが可能である。たとえば、アプリケーションブラウザに関する推定されたQoEが悪い場合には、通常は青色であるウェブリンクの色が、赤色に変更されることが可能である。上述の順序および確率は、上述の要素の任意の組合せを使用して特定されることが可能であるということに留意されたい。たとえば、後続アクション予測部102は、統計情報130、現在使用されているアプリケーションに関する情報140、Eメールコンテンツに関する情報140、日付および時間に関する情報140、端末10内に取り付けられているセンサからの情報120の任意の組合せに基づいて、それぞれのアプリケーションが実行される確率を予測することができる。後続アクション予測部102の機能は、クラウド20によって実施されることが可能であるということもわかる。たとえば、クラウド20は、ユーザ全般のアプリケーション操作の履歴に関する統計情報を格納すること、ならびに、端末10のユーザに固有の行動、およびユーザ全般に固有の行動の両方に関する情報に基づいて、次なるアプリケーションおよびその操作を予測することが可能である。前述の詳細な説明のうちのいくつかの部分は、コンピュータメモリなどのコンピューティングシステムメモリ内に格納されているデータビットまたはバイナリデジタル信号上のオペレーションのアルゴリズムまたはシンボル表示という点から提示されている。これらのアルゴリズム的な記述または表示は、データ処理技術分野における標準的な技術者が自分の作業の実体を他の当業者たちに伝達するために使用する技術の例である。アルゴリズムとは、ここでは、および一般には、所望の結果へつながるオペレーションまたは類似の処理の首尾一貫したシーケンスであるとみなされている。このコンテキストにおいては、オペレーションまたは処理は、物理量の物理的な操作を含む。典型的には、必須ではないが、そのような量は、格納すること、転送すること、結合すること、比較すること、またはその他の形で操作することが可能な電気信号または磁気信号の形態を取ることができる。ビット、データ、値、要素、シンボル、文字、語、数、数字などとしてそのような信号を指すことが、主として共通の使用という理由から、時として便利であることがわかっている。しかしながら、これらおよび類似の語はすべて、適切な物理量に関連付けられるものであり、便宜上のラベルにすぎないということを理解されたい。特に別段の記載がない限り、以降の論考から明らかなように、本明細書を通じて、処理する、算出する、計算する、判定するなどの語を利用している論考は、コンピューティングデバイスのメモリ、レジスタ、またはその他の情報記憶装置、伝送装置、もしくは表示装置内の物理的、電子的、または磁気的な量として表されているデータを操作または変換する、コンピューティングデバイスのアクションまたはプロセスを指すということに留意されたい。前述の詳細な説明では、ブロック図、フローチャート、および/または例の使用によって、装置および/またはプロセスのさまざまな実施形態を説明してきた。そのようなブロック図、フローチャート、および/または例が1つまたは複数の機能および/または動作を含む限りにおいて、そのようなブロック図、フローチャート、または例の中のそれぞれの機能および/または動作は、広範囲のハードウェア、ソフトウェア、ファームウェア、または実質上それらのすべての組合せにより、個別におよび/または集合的に実装可能であることが、当業者には理解されるであろう。いくつかの実施形態では、本明細書に記載された主題のいくつかの部分は、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGA、デジタルシグナルプロセッサDSP、または他の集積化方式によって実装することができる。しかし、本明細書で開示された実施形態のいくつかの態様が、全体においてまたは一部において、1つまたは複数のコンピュータ上で動作する1つまたは複数のコンピュータプログラムとしてたとえば、1つまたは複数のコンピュータシステム上で動作する1つまたは複数のプログラムとして、1つまたは複数のプロセッサ上で動作する1つまたは複数のプログラムとしてたとえば、1つまたは複数のマイクロプロセッサ上で動作する1つまたは複数のプログラムとして、ファームウェアとして、あるいは実質上それらの任意の組合せとして、等価に集積回路に実装することができることを、当業者は認識するであろうし、電気回路の設計ならびに/またはソフトウェアおよび/もしくはファームウェアのコーディングが、本開示に照らして十分当業者の技能の範囲内であることを、当業者は認識するであろう。さらに、本明細書に記載された主題のメカニズムをさまざまな形式のプログラム製品として配布することができることを、当業者は理解するであろうし、本明細書に記載された主題の例示的な実施形態が、実際に配布を実行するために使用される信号伝達媒体の特定のタイプにかかわらず適用されることを、当業者は理解するであろう。信号伝達媒体の例には、フレキシブルディスク、ハードディスクドライブHDD、コンパクトディスクCD、デジタル多用途ディスクDVD、デジタルテープ、コンピュータメモリ、などの記録可能なタイプの媒体、ならびに、デジタル通信媒体および/またはアナログ通信媒体たとえば、光ファイバケーブル、導波管、有線通信リンク、無線通信リンクなどの通信タイプの媒体が含まれるが、それらには限定されない。本明細書に記載された主題は、さまざまなコンポーネントをしばしば例示しており、これらのコンポーネントは、他のさまざまなコンポーネントに包含されるか、または他のさまざまなコンポーネントに接続される。そのように図示されたアーキテクチャは、単に例にすぎず、実際には、同じ機能を実現する多くの他のアーキテクチャが実装可能であることが理解されよう。概念的な意味で、同じ機能を実現するコンポーネントの任意の構成は、所望の機能が実現されるように効果的に関連付けされる。したがって、特定の機能を実現するために組み合わされた、本明細書における任意の2つのコンポーネントは、アーキテクチャまたは中間のコンポーネントにかかわらず、所望の機能が実現されるように、お互いに関連付けされていると見ることができる。同様に、そのように関連付けされた任意の2つのコンポーネントは、所望の機能を実現するために、互いに動作可能に接続または動作可能に結合されているとみなすこともでき、そのように関連付け可能な任意の2つのコンポーネントは、所望の機能を実現するために、互いに動作可能に結合できるとみなすこともできる。動作可能に結合できる場合の具体例には、物理的にかみ合わせ可能な、および/もしくは物理的に相互作用するコンポーネント、ならびに/またはワイヤレスに相互作用可能な、および/もしくはワイヤレスに相互作用するコンポーネント、ならびに/または論理的に相互作用する、および/もしくは論理的に相互作用可能なコンポーネントが含まれるが、それらに限定されない。本明細書における実質的にすべての複数形および/または単数形の用語の使用に対して、当業者は、状況および/または用途に適切なように、複数形から単数形に、および/または単数形から複数形に変換することができる。さまざまな単数形/複数形の置き換えは、理解しやすいように、本明細書で明確に説明することができる。通常、本明細書において、特に添付の特許請求の範囲たとえば、添付の特許請求の範囲の本体部において使用される用語は、全体を通じてオープンなopen用語として意図されていることが、当業者には理解されようたとえば、用語含むincludingは、含むがそれに限定されないincludingbutnotlimitedtoと解釈されるべきであり、用語有するhavingは、少なくとも有するhavingatleastと解釈されるべきであり、用語含むincludesは、含むがそれに限定されないincludesbutisnotlimitedtoと解釈されるべきである、など。導入される請求項で具体的な数の記載が意図される場合、そのような意図は、当該請求項において明示的に記載されることになり、そのような記載がない場合、そのような意図は存在しないことが、当業者にはさらに理解されよう。たとえば、理解の一助として、添付の特許請求の範囲は、導入句少なくとも1つのatleastoneおよび1つまたは複数のoneormoreを使用して請求項の記載を導くことを含む場合がある。しかし、そのような句の使用は、同一の請求項が、導入句1つまたは複数のまたは少なくとも1つのおよびaまたはanなどの不定冠詞を含む場合であっても、不定冠詞aまたはanによる請求項の記載の導入が、そのように導入される請求項の記載を含む任意の特定の請求項を、単に1つのそのような記載を含む発明に限定する、ということを示唆していると解釈されるべきではないたとえば、aおよび/またはanは、通常、少なくとも1つのまたは1つまたは複数のを意味すると解釈されるべきである。同じことが、請求項の記載を導入するのに使用される定冠詞の使用にも当てはまる。また、導入される請求項の記載で具体的な数が明示的に記載されている場合でも、そのような記載は、通常、少なくとも記載された数を意味すると解釈されるべきであることが、当業者には理解されようたとえば、他の修飾語なしでの2つの記載tworecitationsの単なる記載は、通常、少なくとも2つの記載、または2つ以上の記載を意味する。さらに、A、BおよびC、などの少なくとも1つに類似の慣例表現が使用されている事例では、通常、そのような構文は、当業者がその慣例表現を理解するであろう意味で意図されているたとえば、A、B、およびCの少なくとも1つを有するシステムは、Aのみ、Bのみ、Cのみ、AおよびBを共に、AおよびCを共に、BおよびCを共に、ならびに/またはA、B、およびCを共に、などを有するシステムを含むが、それに限定されない。A、B、またはC、などの少なくとも1つに類似の慣例表現が使用されている事例では、通常、そのような構文は、当業者がその慣例表現を理解するであろう意味で意図されているたとえば、A、B、またはCの少なくとも1つを有するシステムは、Aのみ、Bのみ、Cのみ、AおよびBを共に、AおよびCを共に、BおよびCを共に、ならびに/またはA、B、およびCを共に、などを有するシステムを含むが、それに限定されない。2つ以上の代替用語を提示する事実上いかなる離接する語および/または句も、明細書、特許請求の範囲、または図面のどこにあっても、当該用語の一方oneoftheterms、当該用語のいずれかeitheroftheterms、または両方の用語bothtermsを含む可能性を企図すると理解されるべきであることが、当業者にはさらに理解されよう。たとえば、句AまたはBは、AまたはBあるいはAおよびBの可能性を含むことが理解されよう。本明細書においてさまざまな方法およびシステムを使用して特定の例示的な技術について説明し、示してきたが、特許請求されている主題から逸脱することなく、その他のさまざまな修正を行うことができ、均等物を代用することができるということを当業者なら理解するはずである。加えて、本明細書に記載されている中核となるコンセプトから逸脱することなく、特定の状況を、特許請求されている主題の教示に適合させるために、多くの修正を行うことができる。したがって、特許請求されている主題は、開示されている特定の例に限定されるものではなく、そのような特許請求されている主題は、添付の特許請求の範囲およびその均等物の範囲内に収まるすべての実施態様を含むこともできるということが意図されている。