JP7042963B1 - 関連コンテンツを先見的に特定し、タッチ感知デバイス上に表面化させるためのシステム及び方法 - Google Patents

Abstract

【課題】関連コンテンツを先見的に特定し、タッチ感知デバイス上に表面化させるためのシステム、方法及びコンピュータ可読記憶媒体を提供する。【解決手段】方法は、電子デバイスのユーザからの命令に応じて、アプリケーションを実行し、アプリケーションを実行している間、使用データを収集することを含む。使用データは、アプリケーション内でユーザが実行した１つ以上のアクションを少なくとも含む。方法はさらに、収集した使用データに基づいて、自動的に、かつ、人の介入なしに、少なくとも１つのトリガー条件を取得することと、少なくとも１つのトリガー条件を、アプリケーション内でユーザが実行した１つ以上のアクションのうち特定のアクションと関連付けることと、少なくとも１つのトリガー条件が満たされたと判定すると、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することを含む。【選択図】図２４Ａ

Description

本明細書に開示される実施形態は、全般的に、タッチ感知ディスプレイを有する電子デバイスに関し、より具体的には、関連コンテンツを先見的に特定し、ディスプレイ及びタッチ感知面と通信する電子デバイス上に表面化させるためのシステム及び方法に関する。

タッチ感知ディスプレイを有するハンドヘルド型電子デバイスは広く普及している。これらの広く普及しているハンドヘルド型電子デバイスのユーザは、現在、自身のデバイスに多数のアプリケーションをインストールし、これらのアプリケーションを使用して自身の日々の活動をより効率的に行っている。しかしながら、これらアプリケーションにアクセスするためには、ユーザは、通常、自身のデバイスをロック解除し、所望のアプリケーションの場所を特定し（例えば、ホームスクリーンをあちこち見て所望のアプリケーションと関連付けられたアイコンの場所を特定することにより、又は検索インタフェース内で所望のアプリケーションを検索することにより）、次いで、また、所望のアプリケーション内で所望の機能の場所を特定しなければならない。したがって、ユーザは、所望のアプリケーションを単に即座に（例えば、シングルタッチ入力によって）実行できる及び／又は所望の機能を実行できる代わりに、所望のアプリケーション及びこれらのアプリケーション内の所望の機能の場所を特定するのに多大な量の時間を費やすことが多い。

更に、多数のアプリケーションがインストールされていることでユーザに連続的な情報の流れが押し寄せるため、全てを即座に閲覧することはできない。このため、ユーザは、多くの場合、前に気づいた特定の情報を後で戻って閲覧すること、又は特定の情報を後で使用することを所望する。しかしながら、しばしば、ユーザは特定の情報の場所を特定することができない、又は特定の情報の場所をどう特定するかを憶えることができない。

このため、関連コンテンツ（例えば、特定の情報）を先見的に特定し、ディスプレイ及びタッチ感知面と通信する電子デバイス上に表面化させるための、直感的かつ使用が簡単なシステム並びに方法を提供することが望ましい。

したがって、アプリケーション及びこれらのアプリケーション内の所望の機能に迅速にアクセスするためのより速くより効率的な方法並びにインタフェースを有する電子デバイス対する需要がある。更に、関連情報（例えば、連絡先、近くの場所、アプリケーション、ニュース記事、住所、及びデバイス上で入手可能な他の情報）を、この情報がユーザにより明示的に要求される前に先見的に特定し、提供することにより、ユーザが日々受信する連続的な情報の流れの管理に関してユーザを支援する電子デバイスに対する需要がある。このような方法及びインタフェースは、任意選択的に、アプリケーションにアクセスするための従来の方法を補完する、又はそれらに取って代わる。このような方法及びインタフェースにより、ユーザが所望の情報の場所を特定するのに必要とする入力が少なくなることによって、より効率的なヒューマンマシンインタフェースが生じる。電池駆動式デバイスの場合、このような方法及びインタフェースにより、電力が節約され、電池充電の時間間隔が延びる（例えば、種々の機能を実行するために必要なタッチ入力の回数が少なくなることにより）。更に、このような方法及びインタフェースによって必要とするタッチ入力の回数が少なくなることにより（例えば、所望の情報の場所を特定するためにタッチ感知ディスプレイを連続的にかつ目的なくタップしなければならない代わりに、本明細書に開示される方法及びインタフェースがこの情報を、ユーザ入力を必要とすることなく先見的に提供する）タッチ感知ディスプレイの寿命が延びる。

タッチ感知面を備える電子デバイス用のユーザインタフェースに関連する上記の欠陥及び他の問題は、開示されるデバイスによって対処される。一部の実施形態では、本デバイスは、デスクトップコンピュータである。一部の実施形態では、このデバイスは、ポータブル（例えば、ノートブックコンピュータ、タブレットコンピュータ、又はハンドヘルドデバイス）である。一部の実施形態では、このデバイスは、タッチパッドを有する。一部の実施形態では、本デバイスは、タッチ感知ディスプレイ（「タッチスクリーン」又は「タッチスクリーンディスプレイ」としても知られる）を有する。一部の実施形態では、このデバイスは、グラフィカルユーザインタフェース（ＧＵＩ）、１つ以上のプロセッサ、メモリ、及び複数の機能を実行するためにメモリに記憶された１つ以上のモジュール、プログラム、又は命令セットを有する。一部の実施形態では、ユーザは主にタッチ感知面上でのスタイラス並びに／又は指の接触及びジェスチャによってＧＵＩと相互作用する。一部の実施形態では、機能は、画像編集、描画、プレゼンティング、ワードプロセッシング、ウェブサイト作成、ディスクオーサリング、スプレッドシートの作成、ゲームプレイ、電話をかけること、ビデオ会議、電子メール送信、インスタントメッセージング、フィットネスサポート、デジタル写真撮影、デジタルビデオ撮影、ウェブブラウジング、デジタル音楽の再生、及び／又はデジタルビデオの再生を任意選択的に、含む。これらの機能を実行する実行可能命令は、任意選択的に、非一時的コンピュータ可読記憶媒体又は１つ以上のプロセッサによって実行されるように構成された他のコンピュータプログラム製品に含まれる。

（Ａ１）一部の実施形態では、方法が、タッチ感知ディスプレイ（タッチスクリーン１１２、図１Ｃ）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、電子デバイスのユーザからの命令に応じて、電子デバイス上でアプリケーションを実行することを含む。当該方法は、アプリケーションを実行している間、使用データを収集することを更に含む。使用データは、アプリケーション内でユーザが実行した１つ以上のアクション（又はアクションの種類）を少なくとも含む。当該方法は、また、（ｉ）収集した使用データに基づいて、自動的に、かつ人の介入なしに、少なくとも１つのトリガー条件を取得することと、（ｉｉ）少なくとも１つのトリガー条件を、アプリケーション内でユーザが実行した１つ以上のアクションのうち特定のアクションと関連付けることと、を含む。当該方法は、少なくとも１つのトリガー条件が満たされたと判定すると、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することを含む。

（Ａ２）Ａ１に記載の方法の一部の実施形態では、少なくとも１つのトリガー条件を取得することは、電子デバイスからリモートに位置する１つ以上のサーバに使用データを送信することと、１つ以上のサーバから少なくとも１つのトリガー条件を受信することと、を含む。

（Ａ３）Ａ１又はＡ２に記載の方法の一部の実施形態では、インジケーションを提供することは、タッチ感知ディスプレイのロックスクリーン上に、トリガー条件と関連付けられた特定のアクションに対応するユーザインタフェースオブジェクトを表示することを含む。

（Ａ４）Ａ３に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、トリガー条件と関連付けられた特定のアクションの説明を含む。

（Ａ５）Ａ４に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、アプリケーションと関連付けられたアイコンを更に含む。

（Ａ６）Ａ３からＡ５のいずれか１つに記載の方法の一部の実施形態では、当該方法は、ユーザインタフェースオブジェクトにおいて第１のジェスチャを検出することを更に含む。第１のジェスチャを検出したことに応じて、（ｉ）タッチ感知ディスプレイ上にアプリケーションを表示し、（ｉｉ）当該方法は、アプリケーションを表示している間、トリガー条件と関連付けられた特定のアクションを実行することを含む。

（Ａ７）Ａ６に記載の方法の一部の実施形態では、第１のジェスチャは、ユーザインタフェースオブジェクト上におけるスワイプジェスチャである。

（Ａ８）Ａ３からＡ５のいずれか１つに記載の方法の一部の実施形態では、当該方法は、ユーザインタフェースオブジェクトにおいて第２のジェスチャを検出することを更に含む。第２のジェスチャを検出したことに応じて、かつタッチ感知ディスプレイ上にロックスクリーンを表示し続けている間、トリガー条件と関連付けられた特定のアクションを実行する。

（Ａ９）Ａ８に記載の方法の一部の実施形態では、第２のジェスチャは、ユーザインタフェースオブジェクトの既定のエリアにおけるシングルタップである。

（Ａ１０）Ａ３からＡ９のいずれか１つに記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、ロックスクリーンの既定の中央部に表示される。

（Ａ１１）Ａ１に記載の方法の一部の実施形態では、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することは、特定のアクションを実行することを含む。

（Ａ１２）Ａ３に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトはアプリケーションと関連付けられたアイコンであり、ユーザインタフェースオブジェクトは、実質的に、タッチ感知ディスプレイのロックスクリーンの隅に表示される。

（Ａ１３）Ａ１からＡ１２のいずれか１つに記載の方法の一部の実施形態では、当該方法は、ユーザから、電子デバイスをロック解除する命令を受信することを更に含む。当該方法は、命令の受信に応じて、タッチ感知ディスプレイ上に、電子デバイスのホームスクリーンを表示することを含む。当該方法は、また、ホームスクリーン上に、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することを含む。

（Ａ１４）Ａ１３に記載の方法の一部の実施形態では、ホームスクリーンは、（ｉ）電子デバイス上で利用可能なアプリケーションの第１セットを起動するための１つ以上のユーザインタフェースページを含む第１部分と、（ｉｉ）第１部分に隣接して表示される、電子デバイス上で利用可能なアプリケーションの第２セットを起動するための第２部分と、を含む。第２部分は、第１部分に含まれる全てのユーザインタフェースページ上に表示され、ホームスクリーン上にインジケーションを提供することは、インジケーションを第２部分上に表示することを含む。

（Ａ１５）Ａ１４に記載の方法の一部の実施形態では、アプリケーションの第２セットはアプリケーションの第１セットとは異なり、かつアプリケーションの第１セットよりも小さい。

（Ａ１６）Ａ１からＡ１５のいずれか１つに記載の方法の一部の実施形態では、少なくとも１つのトリガー条件が満たされたと判定することは、電子デバイスが、電子デバイスとは異なる第２のデバイスと結合されたと判定することを含む。

（Ａ１７）Ａ１からＡ１６のいずれか１つに記載の方法の一部の実施形態では、少なくとも１つのトリガー条件が満たされたと判定することは、電子デバイスが、ユーザと関連付けられた自宅又は職場に対応する住所に到着したと判定することを含む。

（Ａ１８）Ａ１７に記載の方法の一部の実施形態では、電子デバイスが、ユーザと関連付けられた自宅又は職場に対応する住所に到着したと判定することは、電子デバイスの加速度計からのモーションデータを監視することと、監視されたモーションデータに基づいて、電子デバイスが閾値時間量を超えて移動していないと判定することと、を含む。

（Ａ１９）Ａ１からＡ１８のいずれか１つに記載の方法の一部の実施形態では、使用データは、アプリケーションの実行を継続している間に、ユーザからバーチャルアシスタントアプリケーションに提供される口頭命令を更に含む。少なくとも１つのトリガー条件は、更に、バーチャルアシスタントアプリケーションに提供される口頭命令に基づく。

（Ａ２０）Ａ１９に記載の方法の一部の実施形態では、口頭命令は、アプリケーションの現在の状態に対応するリマインダを作成することの要求を含み、現在の状態は、口頭命令が提供されたときのアプリケーションの状態に対応する。

（Ａ２１）Ａ２０に記載の方法の一部の実施形態では、口頭命令が提供されたときのアプリケーションの状態は、口頭命令が提供されたときにアプリケーション内に表示されるページ、口頭命令が提供されたときにアプリケーション内で再生されているコンテンツ、口頭命令が提供されたときにアプリケーション内に表示される通知、及び口頭命令が提供されたときにアプリケーション内に表示されるページのアクティブ部分からなる群より選択される。

（Ａ２２）Ａ２０に記載の方法の一部の実施形態では、口頭命令は、アプリケーションの現在の状態に関する「この（this）」という語を含む。

（Ａ２３）別の態様では、方法が、１つ以上の電子デバイス（例えば、ポータブル多機能デバイス１００（図５）及び１つ以上のサーバ５０２（図５））において実行される。当該方法は、第１の電子デバイスのユーザからの命令に応じて、１つ以上の電子デバイスのうちの第１の電子デバイス上でアプリケーションを実行することを含む。当該方法は、アプリケーションを実行している間、自動的に、かつ人の介入なしに、使用データを収集することを含み、使用データは、アプリケーション内でユーザが実行した１つ以上のアクション（又はアクションの種類）を少なくとも含む。当該方法は、収集した使用データに基づいて、自動的に、かつ人の介入なしに、少なくとも１つのトリガー条件を設けることを更に含む。当該方法は、少なくとも１つのトリガー条件を、アプリケーション内でユーザが実行した１つ以上のアクションのうち特定のアクションと関連付けることを更に含む。当該方法は、少なくとも１つのトリガー条件が満たされたと判定すると、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することを含む。

（Ａ２４）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリとを含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは電子デバイスにＡ１からＡ２２のいずれか１つに記載の方法を実行させる。

（Ａ２５）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知ディスプレイと、Ａ１からＡ２２のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ａ２６）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知ディスプレイを有する電子デバイスによって実行されると、実行可能命令は電子デバイスにＡ１からＡ２２のいずれか１つに記載の方法を実行させる。

（Ａ２７）更なる一態様では、タッチ感知ディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ａ１からＡ２２のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ａ２８）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４２０１、図４２）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４２０３、図４２）と、処理ユニット（例えば、処理ユニット４２０５、図４２）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４２は、電子デバイス４２００に一体化されているとしてディスプレイユニット４２０１及びタッチ感知面ユニット４２０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、タッチ感知面ユニット及びディスプレイユニットと結合されている。一部の実施形態では、タッチ感知面ユニット及びディスプレイユニットは１つのタッチ感知ディスプレイユニット（本明細書では、タッチ感知ディスプレイとも称される）に一体化されている。処理ユニットは、実行ユニット（例えば、実行ユニット４２０７、図４２）と、収集ユニット（例えば、収集ユニット４２０９、図４２）と、取得ユニット（例えば、取得ユニット４２１１、図４２）と、関連付けユニット（例えば、関連付けユニット４２１３、図４２）と、提供ユニット（例えば、提供ユニット４２１５、図４２）と、送信ユニット（例えば、送信ユニット４２１７、図４２）と、受信ユニット（例えば、受信ユニット４２１９、図４２）と、表示ユニット（例えば、表示ユニット４２２１、図４２）と、検出ユニット（例えば、検出ユニット４２２３、図４２）と、実施ユニット（例えば、実施ユニット４２２５、図４２）と、判定ユニット（例えば、判定ユニット４２２７、図４２）と、監視ユニット（例えば、監視ユニット４２２９、図４２）と、を含む。処理ユニット（又はユニット４２０７から４２２９などのその１つ以上の構成要素）は、電子デバイスのユーザからの命令に応じて電子デバイス上でアプリケーションを実行し（例えば、実行ユニット４２０７によって）、アプリケーションを実行している間、使用データであって、を収集し（例えば、収集ユニット４２０９によって）、使用データは、アプリケーション内でユーザが実行した１つ以上のアクションを少なくとも含む、使用データを収集し、収集した使用データに基づいて、自動的に、かつ人の介入なしに、少なくとも１つのトリガー条件を取得し（例えば、取得ユニット４２１１によって）、少なくとも１つのトリガー条件を、アプリケーション内でユーザが実行した１つ以上のアクションのうち特定のアクションと関連付け（例えば、関連付けユニット４２１３によって）、少なくとも１つのトリガー条件が満たされたと判定すると、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供する（例えば、提供ユニット４２１５によって）ように構成されている。

（Ａ２９）Ａ２８に記載の電子デバイスの一部の実施形態では、少なくとも１つのトリガー条件を取得することは、電子デバイスからリモートに位置する１つ以上のサーバに使用データを送信すること（例えば、送信ユニット４２１７によって）と、１つ以上のサーバから少なくとも１つのトリガー条件を受信すること（例えば、受信ユニット４２１９によって）と、を含む。

（Ａ３０）Ａ２８又はＡ２９に記載の電子デバイスの一部の実施形態では、インジケーションを提供することは、タッチ感知ディスプレイユニットのロックスクリーン上に、トリガー条件と関連付けられた特定のアクションに対応するユーザインタフェースオブジェクトを表示すること（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）を含む。

（Ａ３１）Ａ３０に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、トリガー条件と関連付けられた特定のアクションの説明を含む。

（Ａ３２）Ａ３１に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、アプリケーションと関連付けられたアイコンを更に含む。

（Ａ３３）Ａ３０からＡ３２のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザインタフェースオブジェクトにおいて第１のジェスチャを検出する（例えば、検出ユニット４２２３及び／又はタッチ感知面ユニット４２０３によって）ように更に構成されている。第１のジェスチャを検出したことに応じて、（ｉ）タッチ感知ディスプレイユニット上にアプリケーションを表示し（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）、（ｉｉ）アプリケーションを表示している間、トリガー条件と関連付けられた特定のアクションを実行する（例えば、実施ユニット４２２５によって）。

（Ａ３４）Ａ３３に記載の電子デバイスの一部の実施形態では、第１のジェスチャは、ユーザインタフェースオブジェクト上におけるスワイプジェスチャである。

（Ａ３５）Ａ３０からＡ３３のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザインタフェースオブジェクトにおいて第２のジェスチャを検出する（例えば、検出ユニット４２２３及び／又はタッチ感知面ユニット４２０３によって）ように更に構成されている。第２のジェスチャを検出したことに応じて、かつタッチ感知ディスプレイユニット上にロックスクリーンを表示し続けている間、処理ユニットは、トリガー条件と関連付けられた特定のアクションを実行する（例えば、実施ユニット４２２５によって）ように構成されている。

（Ａ３６）Ａ３５に記載の電子デバイスの一部の実施形態では、第２のジェスチャは、ユーザインタフェースオブジェクトの既定のエリアにおけるシングルタップである。

（Ａ３７）Ａ３０からＡ３６のいずれか１つに記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、ロックスクリーンの既定の中央部に表示される。

（Ａ３８）Ａ２８に記載の電子デバイスの一部の実施形態では、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することは、特定のアクションを実行すること（例えば、実施ユニット４２２５によって）を含む。

（Ａ３９）Ａ３０に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトはアプリケーションと関連付けられたアイコンであり、ユーザインタフェースオブジェクトは、実質的に、タッチ感知ディスプレイユニットのロックスクリーンの隅に表示される。

（Ａ４０）Ａ２８からＡ３９のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザから、電子デバイスをロック解除する命令を受信する（例えば、受信ユニット４２１９によって）ように更に構成されている。命令の受信に応じて、処理ユニットは、タッチ感知ディスプレイユニット上に、電子デバイスのホームスクリーンを表示する（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）ように構成されている。処理ユニットはまた、ホームスクリーン上に、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供する（例えば、提供ユニット４２１５によって）ように構成されている。

（Ａ４１）Ａ４０に記載の電子デバイスの一部の実施形態では、ホームスクリーンは、（ｉ）電子デバイス上で利用可能なアプリケーションの第１セットを起動するための１つ以上のユーザインタフェースページを含む第１部分と、（ｉｉ）第１部分に隣接して表示される、電子デバイス上で利用可能なアプリケーションの第２セットを起動するための第２部分と、を含む。第２部分は、第１部分に含まれる全てのユーザインタフェースページ上に表示され、ホームスクリーン上にインジケーションを提供することは、インジケーションを第２部分上に表示すること（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）を含む。

（Ａ４２）Ａ４１に記載の電子デバイスの一部の実施形態では、アプリケーションの第２セットはアプリケーションの第１セットとは異なり、かつアプリケーションの第１セットよりも小さい。

（Ａ４３）Ａ２８からＡ４２のいずれか１つに記載の電子デバイスの一部の実施形態では、少なくとも１つのトリガー条件が満たされたと判定することは、電子デバイスが、電子デバイスとは異なる第２のデバイスと結合されたと判定すること（例えば、判定ユニット４２２７によって）を含む。

（Ａ４４）Ａ２８からＡ４３のいずれか１つに記載の電子デバイスの一部の実施形態では、少なくとも１つのトリガー条件が満たされたと判定することは、電子デバイスが、ユーザと関連付けられた自宅又は職場に対応する住所に到着したと判定すること（例えば、判定ユニット４２２７によって）を含む。

（Ａ４５）Ａ４４に記載の電子デバイスの一部の実施形態では、電子デバイスが、ユーザと関連付けられた自宅又は職場に対応する住所に到着したと判定することは、電子デバイスの加速度計からのモーションデータを監視すること（例えば、監視ユニット４２２９によって）と、監視されたモーションデータに基づいて、電子デバイスが閾値時間量を超えて移動していないと判定すること（例えば、判定ユニット４２２７によって）と、を含む。

（Ａ４６）Ａ２８からＡ４５のいずれか１つに記載の電子デバイスの一部の実施形態では、使用データは、アプリケーションの実行を継続している間に、ユーザからバーチャルアシスタントアプリケーションに提供される口頭命令を更に含む。少なくとも１つのトリガー条件は、更に、バーチャルアシスタントアプリケーションに提供される口頭命令に基づく。

（Ａ４７）Ａ４６に記載の電子デバイスの一部の実施形態では、口頭命令は、アプリケーションの現在の状態に対応するリマインダを作成することの要求を含み、現在の状態は、口頭命令が提供されたときのアプリケーションの状態に対応する。

（Ａ４８）Ａ４７に記載の電子デバイスの一部の実施形態では、口頭命令が提供されたときのアプリケーションの状態は、口頭命令が提供されたときにアプリケーション内に表示されるページ、口頭命令が提供されたときにアプリケーション内で再生されているコンテンツ、口頭命令が提供されたときにアプリケーション内に表示される通知、及び口頭命令が提供されたときにアプリケーション内に表示されるページのアクティブ部分からなる群より選択される。

（Ａ４９）Ａ４６に記載の電子デバイスの一部の実施形態では、口頭命令は、アプリケーションの現在の状態に関する「この（this）」という語を含む。

（Ｂ１）一部の実施形態では、方法が、タッチ感知ディスプレイ（タッチスクリーン１１２、図１Ｃ）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、電子デバイスのユーザと関連付けられた使用データに基づく少なくとも１つのトリガー条件を取得することを含み、使用データは、アプリケーションが電子デバイス上で実行されている間、アプリケーション内でユーザが実行した１つ以上のアクション（又はアクションの種類）を含む。当該方法は、また、少なくとも１つのトリガー条件を、アプリケーション内でユーザが実行した１つ以上のアクションのうち特定のアクションと関連付けることを含む。当該方法は、少なくとも１つのトリガー条件が満たされたと判定すると、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することを含む。

（Ｂ２）Ｂ１に記載の方法の一部の実施形態では、当該方法は、Ａ２からＡ２２のいずれか１つに記載の方法を更に含む。

（Ｂ３）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは電子デバイスにＢ１又はＢ２に記載の方法を実行させる。

（Ｂ４）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知ディスプレイと、Ｂ１又はＢ２に記載の方法を実行するための手段と、を含む。

（Ｂ５）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知ディスプレイを有する電子デバイスによって実行されると、実行可能命令は電子デバイスにＢ１又はＢ２に記載の方法を実行させる。

（Ｂ６）更なる一態様では、タッチ感知ディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｂ１又はＢ２に記載の方法に従って表示されるユーザインタフェースを含む。

（Ｂ７）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４２０１、図４２）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４２０３、図４２）と、処理ユニット（例えば、処理ユニット４２０５、図４２）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４２は、電子デバイス４２００に一体化されているとしてディスプレイユニット４２０１及びタッチ感知面ユニット４２０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、実行ユニット（例えば、実行ユニット４２０７、図４２）と、収集ユニット（例えば、収集ユニット４２０９、図４２）と、取得ユニット（例えば、取得ユニット４２１１、図４２）と、関連付けユニット（例えば、関連付けユニット４２１３、図４２）と、提供ユニット（例えば、提供ユニット４２１５、図４２）と、送信ユニット（例えば、送信ユニット４２１７、図４２）と、受信ユニット（例えば、受信ユニット４２１９、図４２）と、表示ユニット（例えば、表示ユニット４２２１、図４２）と、検出ユニット（例えば、検出ユニット４２２３、図４２）と、実施ユニット（例えば、実施ユニット４２２５、図４２）と、判定ユニット（例えば、判定ユニット４２２７、図４２）と、監視ユニット（例えば、監視ユニット４２２９、図４２）と、を含む。処理ユニット（又はユニット４２０７から４２２９などのその１つ以上の構成要素）は、電子デバイスのユーザと関連付けられた使用データであって、使用データは、アプリケーションが電子デバイス上で実行されている間、アプリケーション内でユーザが実行した１つ以上のアクションを含む、使用データに基づく少なくとも１つのトリガー条件を取得し（例えば、取得ユニット４２１１によって）、少なくとも１つのトリガー条件を、アプリケーション内でユーザが実行した１つ以上のアクションのうち特定のアクションと関連付け（例えば、関連付けユニット４２１３によって）、少なくとも１つのトリガー条件が満たされたと判定すると、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供する（例えば、提供ユニット４２１５によって）ように構成されている。

（Ｂ８）Ｂ７に記載の電子デバイスの一部の実施形態では、少なくとも１つのトリガー条件を取得することは、電子デバイスからリモートに位置する１つ以上のサーバに使用データを送信すること（例えば、送信ユニット４２１７によって）と、１つ以上のサーバから少なくとも１つのトリガー条件を受信すること（例えば、受信ユニット４２１９によって）と、を含む。

（Ｂ９）Ｂ７又はＢ８に記載の電子デバイスの一部の実施形態では、インジケーションを提供することは、タッチ感知ディスプレイのロックスクリーン上に、トリガー条件と関連付けられた特定のアクションに対応するユーザインタフェースオブジェクトを表示すること（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）を含む。

（Ｂ１０）Ｂ９に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、トリガー条件と関連付けられた特定のアクションの説明を含む。

（Ｂ１１）Ｂ１０に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、アプリケーションと関連付けられたアイコンを更に含む。

（Ｂ１２）Ｂ９からＢ１１のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザインタフェースオブジェクトにおいて第１のジェスチャを検出する（例えば、検出ユニット４２２３及び／又はタッチ感知面ユニット４２０３によって）ように更に構成されている。第１のジェスチャを検出したことに応じて、（ｉ）タッチ感知ディスプレイ上にアプリケーションを表示し（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）、（ｉｉ）アプリケーションを表示している間、トリガー条件と関連付けられた特定のアクションを実行する（例えば、実施ユニット４２２５によって）。

（Ｂ１３）Ｂ１２に記載の電子デバイスの一部の実施形態では、第１のジェスチャは、ユーザインタフェースオブジェクト上におけるスワイプジェスチャである。

（Ｂ１４）Ｂ９からＢ１２のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザインタフェースオブジェクトにおいて第２のジェスチャを検出する（例えば、検出ユニット４２２３及び／又はタッチ感知面ユニット４２０３によって）ように更に構成されている。第２のジェスチャを検出したことに応じて、かつタッチ感知ディスプレイ上にロックスクリーンを表示し続けている間、処理ユニットは、トリガー条件と関連付けられた特定のアクションを実行する（例えば、実施ユニット４２２５によって）ように構成されている。

（Ｂ１５）Ｂ１４に記載の電子デバイスの一部の実施形態では、第２のジェスチャは、ユーザインタフェースオブジェクトの既定のエリアにおけるシングルタップである。

（Ｂ１６）Ｂ９からＢ１５のいずれか１つに記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、ロックスクリーンの既定の中央部に表示される。

（Ｂ１７）Ｂ７に記載の電子デバイスの一部の実施形態では、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供することは、特定のアクションを実行すること（例えば、実施ユニット４２２５によって）を含む。

（Ｂ１８）Ｂ９に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトはアプリケーションと関連付けられたアイコンであり、ユーザインタフェースオブジェクトは、実質的に、タッチ感知ディスプレイのロックスクリーンの隅に表示される。

（Ｂ１９）Ｂ７からＢ１８のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザから、電子デバイスをロック解除する命令を受信する（例えば、受信ユニット４２１９によって）ように更に構成されている。命令の受信に応じて、処理ユニットは、タッチ感知ディスプレイ上に、電子デバイスのホームスクリーンを表示する（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）ように構成されている。処理ユニットはまた、ホームスクリーン上に、ユーザに対し、トリガー条件と関連付けられた特定のアクションが利用可能であるというインジケーションを提供する（例えば、提供ユニット４２１５によって）ように構成されている。

（Ｂ２０）Ｂ１９に記載の電子デバイスの一部の実施形態では、ホームスクリーンは、（ｉ）電子デバイス上で利用可能なアプリケーションの第１セットを起動するための１つ以上のユーザインタフェースページを含む第１部分と、（ｉｉ）第１部分に隣接して表示される、電子デバイス上で利用可能なアプリケーションの第２セットを起動するための第２部分と、を含む。第２部分は、第１部分に含まれる全てのユーザインタフェースページ上に表示され、ホームスクリーン上にインジケーションを提供することは、インジケーションを第２部分上に表示すること（例えば、表示ユニット４２１７及び／又はディスプレイユニット４２０１によって）を含む。

（Ｂ２１）Ｂ２０に記載の電子デバイスの一部の実施形態では、アプリケーションの第２セットはアプリケーションの第１セットとは異なり、かつアプリケーションの第１セットよりも小さい。

（Ｂ２２）Ｂ７からＢ２１のいずれか１つに記載の電子デバイスの一部の実施形態では、少なくとも１つのトリガー条件が満たされたと判定することは、電子デバイスが、電子デバイスとは異なる第２のデバイスと結合されたと判定すること（例えば、判定ユニット４２２７によって）を含む。

（Ｂ２３）Ｂ７からＢ２２のいずれか１つに記載の電子デバイスの一部の実施形態では、少なくとも１つのトリガー条件が満たされたと判定することは、電子デバイスが、ユーザと関連付けられた自宅又は職場に対応する住所に到着したと判定すること（例えば、判定ユニット４２２７によって）を含む。

（Ｂ２４）Ｂ２３に記載の電子デバイスの一部の実施形態では、電子デバイスが、ユーザと関連付けられた自宅又は職場に対応する住所に到着したと判定することは、電子デバイスの加速度計からのモーションデータを監視すること（例えば、監視ユニット４２２９によって）と、監視されたモーションデータに基づいて、電子デバイスが閾値時間量を超えて移動していないと判定すること（例えば、判定ユニット４２２７によって）と、を含む。

（Ｂ２５）Ｂ７からＢ２４のいずれか１つに記載の電子デバイスの一部の実施形態では、使用データは、アプリケーションの実行を継続している間に、ユーザからバーチャルアシスタントアプリケーションに提供される口頭命令を更に含む。少なくとも１つのトリガー条件は、更に、バーチャルアシスタントアプリケーションに提供される口頭命令に基づく。

（Ｂ２６）Ｂ２５に記載の電子デバイスの一部の実施形態では、口頭命令は、アプリケーションの現在の状態に対応するリマインダを作成することの要求を含み、現在の状態は、口頭命令が提供されたときのアプリケーションの状態に対応する。

（Ｂ２７）Ｂ２６に記載の電子デバイスの一部の実施形態では、口頭命令が提供されたときのアプリケーションの状態は、口頭命令が提供されたときにアプリケーション内に表示されるページ、口頭命令が提供されたときにアプリケーション内で再生されているコンテンツ、口頭命令が提供されたときにアプリケーション内に表示される通知、及び口頭命令が提供されたときにアプリケーション内に表示されるページのアクティブ部分からなる群より選択される。

（Ｂ２８）Ｂ２６に記載の電子デバイスの一部の実施形態では、口頭命令は、アプリケーションの現在の状態に関する「この（this）」という語を含む。

（Ｃ１）一部の実施形態では、方法が、タッチ感知ディスプレイ（タッチスクリーン１１２、図１Ｃ）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、タッチ感知ディスプレイ上の、電子デバイスのユーザの検索アクティブ化ジェスチャを検出することを含む。当該方法は、検索アクティブ化ジェスチャを検出したことに応じて、タッチ感知ディスプレイ上に検索インタフェースを表示させること、を含み、検索インタフェースは、（ｉ）検索エントリ部分と、（ｉｉ）検索エントリ部分において何らかのユーザ入力を受信する前に表示される予測部分と、を含む。予測部分は、（ａ）複数の以前連絡を取った人物のうちの人物に連絡するための少なくとも１つのアフォーダンスであって、人物は、複数の以前連絡を取った人物の中から、少なくとも一部、現在時刻に基づいて自動的に選択される、少なくとも１つのアフォーダンスと、（ｂ）電子デバイス上で利用可能な複数のアプリケーションのうちのアプリケーション内で、予測されたアクションを実行するための少なくとも１つのアフォーダンスであって、予測されたアクションは、少なくとも一部、電子デバイスのユーザと関連付けられたアプリケーション利用履歴に基づいて自動的に選択される、少なくとも１つのアフォーダンスと、の１つ以上でポピュレートされる。

（Ｃ２）Ｃ１に記載の方法の一部の実施形態では、人物は更に、少なくとも一部、電子デバイスに対応する位置データに基づいて選択される。

（Ｃ３）Ｃ１又はＣ２に記載の方法の一部の実施形態では、アプリケーション利用履歴及び人物に対する連絡先情報が電子デバイスのメモリから取り出される。

（Ｃ４）Ｃ１又はＣ２に記載の方法の一部の実施形態では、アプリケーション利用履歴及び人物に対する連絡先情報が、電子デバイスからリモートに位置するサーバから取り出される。

（Ｃ５）Ｃ１からＣ４のいずれか１つに記載の方法の一部の実施形態では、予測部分は、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスで更にポピュレートされ、予測されたアプリケーションは、少なくとも一部、アプリケーション利用履歴に基づいて自動的に選択される。

（Ｃ６）Ｃ１からＣ５のいずれか１つに記載の方法の一部の実施形態では、予測部分は、予測された場所（又は近くの場所）カテゴリの少なくとも１つのアフォーダンスで更にポピュレートされ、予測された場所カテゴリは、少なくとも一部、現在時刻、及び電子デバイスに対応する位置データの１つ以上に基づいて自動的に選択される。

（Ｃ７）Ｃ１からＣ６のいずれか１つに記載の方法の一部の実施形態では、当該方法は、予測部分をスクロールするためのユーザ入力を検出することを更に含む。当該方法は、予測部分をスクロールするためのユーザ入力を検出したことに応じて、予測部分をユーザ入力に従ってスクロールすることを含む。当該方法は、スクロールに応じて、予測されたニュース記事の少なくとも１つのアフォーダンスを予測部分に顕示化させることを含む（例えば、予測されたニュース記事はユーザが関心を持つことが予想されるものである）。

（Ｃ８）Ｃ７に記載の方法の一部の実施形態では、予測されたニュース記事は、少なくとも一部、電子デバイスに対応する位置データに基づいて自動的に選択される。

（Ｃ９）Ｃ１からＣ８のいずれか１つに記載の方法の一部の実施形態では、当該方法は、予測されたアクションをアプリケーション内で実行するための少なくとも１つのアフォーダンスの選択を検出することを更に含む。当該方法は、選択を検出したことに応じて、タッチ感知ディスプレイ上にアプリケーションを表示し、予測されたアクションをアプリケーション内で実行することを含む。

（Ｃ１０）Ｃ３又はＣ４に記載の方法の一部の実施形態では、当該方法は、人物に連絡するための少なくとも１つのアフォーダンスの選択を検出することを更に含む。当該方法は、選択を検出したことに応じて、人物に対する連絡先情報を用いて人物に連絡することを含む。

（Ｃ１１）Ｃ５に記載の方法の一部の実施形態では、当該方法は、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスの選択を検出することを更に含む。当該方法は、選択を検出したことに応じて、タッチ感知ディスプレイ上に予測されたアプリケーションを表示することを含む。

（Ｃ１２）Ｃ６に記載の方法の一部の実施形態では、当該方法は、予測された場所カテゴリの少なくとも１つのアフォーダンスの選択を検出することを更に含む。当該方法は、選択を検出したことに応じて、（ｉ）少なくとも１つの近くの場所に対応するデータを受信することと、（ｉｉ）タッチ感知ディスプレイ上に、少なくとも１つの近くの場所に対応する受信データを表示することと、を更に含む。

（Ｃ１３）Ｃ７に記載の方法の一部の実施形態では、当該方法は、予測されたニュース記事の少なくとも１つのアフォーダンスの選択を検出することを更に含む。当該方法は、選択を検出したことに応じて、タッチ感知ディスプレイ上に、予測されたニュース記事を表示することを含む。

（Ｃ１４）Ｃ１からＣ１３のいずれか１つに記載の方法の一部の実施形態では、検索アクティブ化ジェスチャは少なくとも２つの異なるユーザインタフェースから利用可能であり、少なくとも２つの異なるユーザインタフェースのうちの第１のユーザインタフェースは、一連のホームスクリーンページのうちの対応するホームスクリーンページをタッチ感知ディスプレイ上に表示することに対応する。

（Ｃ１５）Ｃ１４に記載の方法の一部の実施形態では、対応するホームスクリーンページが一連のホームスクリーンページのうちの最初のホームスクリーンページである場合、検索アクティブ化ジェスチャは以下、すなわち、（ｉ）電子デバイスのユーザに対して実質的に下方向に移動するジェスチャ、又は（ｉｉ）ユーザに対して実質的に左から右の方向にかつ下方向に実質的に直角に移動する連続的なジェスチャ、のうちの１つを含む。

（Ｃ１６）Ｃ１５に記載の方法の一部の実施形態では、対応するホームスクリーンページが一連のホームスクリーンページのうちの第２のホームスクリーンページである場合、検索アクティブ化ジェスチャは、電子デバイスのユーザに対して実質的に下方向に移動する連続的なジェスチャを含む。

（Ｃ１７）Ｃ１４に記載の方法の一部の実施形態では、少なくとも２つの異なるユーザインタフェースのうちの第２のユーザインタフェースは、アプリケーション切替インタフェースをタッチ感知ディスプレイ上に表示することに対応する。

（Ｃ１８）Ｃ１７に記載の方法の一部の実施形態では、検索アクティブ化ジェスチャは、タッチ感知ディスプレイ上の、アプリケーション切替インタフェースの既定の検索アクティブ化部分における接触を含む。

（Ｃ１９）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＣ１からＣ１８のいずれか１つに記載の方法を実行させる。

（Ｃ２０）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知ディスプレイと、Ｃ１からＣ１８のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｃ２１）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知ディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＣ１からＣ１８のいずれか１つに記載の方法を実行させる。

（Ｃ２２）更なる一態様では、タッチ感知ディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｃ１からＣ１８のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｃ２３）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４３０１、図４３）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４３０３、図４３）と、処理ユニット（例えば、処理ユニット４３０５、図４３）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４３は、電子デバイス４３００に一体化されているとしてディスプレイユニット４３０１及びタッチ感知面ユニット４３０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、表示ユニット（例えば、表示ユニット４３０９、図４３）と、検出ユニット（例えば、検出ユニット４３０７、図４３）と、取り出しユニット（例えば、取り出しユニット４３１１、図４３）と、ポピュレーティングユニット（例えば、ポピュレーティングユニット４３１３、図４３）と、スクローリングユニット（例えば、スクローリングユニット４３１５、図４３）と、顕示化ユニット（例えば、顕示化ユニット４３１７、図４３）と、選択ユニット（例えば、選択ユニット４３１９、図４３）と、連絡ユニット（例えば、連絡ユニット４３２１、図４３）と、受信ユニット（例えば、受信ユニット４３２３、図４３）と、実行ユニット（例えば、実行ユニット４３２５、図４３）と、を含む。処理ユニット（又はユニット４３０７から４２２５などのその１つ以上の構成要素）は、タッチ感知ディスプレイ上の、電子デバイスのユーザの検索アクティブ化ジェスチャを検出し（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）、検索アクティブ化ジェスチャを検出したことに応じて、タッチ感知ディスプレイ上に検索インタフェースを表示する（例えば、表示ユニット４３０９及び／又はディスプレイユニット４３０１によって）ように構成されており、検索インタフェースは、（ｉ）検索エントリ部分と、（ｉｉ）検索エントリ部分において何らかのユーザ入力を受信する前に表示される予測部分と、を含む。予測部分は、（ａ）複数の以前連絡を取った人物のうちの人物に連絡するための少なくとも１つのアフォーダンスであって、人物は、複数の以前連絡を取った人物の中から、少なくとも一部、現在時刻に基づいて自動的に選択される（例えば、選択ユニット４３１９によって）、少なくとも１つのアフォーダンスと、（ｂ）電子デバイス上で利用可能な複数のアプリケーションのうちのアプリケーション内で、予測されたアクションを実行するための少なくとも１つのアフォーダンスであって、予測されたアクションは、少なくとも一部、電子デバイスのユーザと関連付けられたアプリケーション利用履歴に基づいて、自動的に選択される（例えば、選択ユニット４３１９によって）、少なくとも１つのアフォーダンスと、の１つ以上でポピュレートされる。

（Ｃ２４）Ｃ２３に記載の電子デバイスの一部の実施形態では、人物は更に、少なくとも一部、電子デバイスに対応する位置データに基づいて選択される（例えば、選択ユニット４３１９によって）。

（Ｃ２５）Ｃ２３又はＣ２４に記載の電子デバイスの一部の実施形態では、アプリケーション利用履歴及び人物に対する連絡先情報が電子デバイスのメモリから取り出される（例えば、取り出しユニット４３１１によって）。

（Ｃ２６）Ｃ２３又はＣ２４に記載の電子デバイスの一部の実施形態では、アプリケーション利用履歴及び人物に対する連絡先情報が電子デバイスからリモートに位置するサーバから取り出される（例えば、取り出しユニット４３１１によって）。

（Ｃ２７）Ｃ２３からＣ２６のいずれか１つに記載の電子デバイスの一部の実施形態では、予測部分は、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスで更にポピュレートされ（例えば、ポピュレーティングユニット４３１３によって）、予測されたアプリケーションは、少なくとも一部、アプリケーション利用履歴に基づいて自動的に選択される（例えば、選択ユニット４３１９によって）。

（Ｃ２８）Ｃ２３からＣ２７のいずれか１つに記載の電子デバイスの一部の実施形態では、予測部分は、予測された場所カテゴリの少なくとも１つのアフォーダンスで更にポピュレートされ（例えば、ポピュレーティングユニット４３１３によって）、予測された場所カテゴリは、少なくとも一部、現在時刻、及び電子デバイスに対応する位置データの１つ以上に基づいて自動的に選択される（例えば、選択ユニット４３１９によって）。

（Ｃ２９）Ｃ２３からＣ２８のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、予測部分をスクロールするためのユーザ入力を検出する（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）ように更に構成されている。予測部分をスクロールするためのユーザ入力を検出したことに応じて、処理ユニットは、予測部分をユーザ入力に従ってスクロールする（例えば、スクローリングユニット４３１９によって）ように構成されている。スクロールに応じて、処理ユニットは、予測されたニュース記事の少なくとも１つのアフォーダンスを予測部分に顕示化する（例えば、顕示化ユニット４３１７によって）ように構成されている（例えば、予測されたニュース記事はユーザが関心を持つことが予想されるものである）。

（Ｃ３０）Ｃ７に記載の電子デバイスの一部の実施形態では、予測されたニュース記事は、少なくとも一部、電子デバイスに対応する位置データに基づいて自動的に選択される（例えば、選択ユニット４３１９によって）。

（Ｃ３１）Ｃ２３からＣ３０のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、予測されたアクションをアプリケーション内で実行するための少なくとも１つのアフォーダンスの選択を検出する（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）ように更に構成されている。選択を検出したことに応じて、処理ユニットは、タッチ感知ディスプレイ（例えば、ディスプレイユニット４３０１）上にアプリケーションを表示し（例えば、表示ユニット４３０９によって）、予測されたアクションをアプリケーション内で実行する（例えば、実行ユニット４３２５によって）ように構成されている。

（Ｃ３２）Ｃ２５又はＣ２６に記載の電子デバイスの一部の実施形態では、処理ユニットは、人物に連絡するための少なくとも１つのアフォーダンスの選択を検出する（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）ように更に構成されている。選択を検出したことに応じて、処理ユニットは、人物に対する連絡先情報を用いて人物に連絡する（例えば、連絡ユニット４３２１によって）ように構成されている。

（Ｃ３３）Ｃ２７に記載の電子デバイスの一部の実施形態では、処理ユニットは、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスの選択を検出する（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）ように更に構成されている。選択を検出したことに応じて、処理ユニットは、タッチ感知ディスプレイ（例えば、ディスプレイユニット４３０１によって）上に予測されたアプリケーションを表示する（例えば、表示ユニット４３０７によって）ように構成されている。

（Ｃ３４）Ｃ２８に記載の電子デバイスの一部の実施形態では、処理ユニットは、予測された場所カテゴリの少なくとも１つのアフォーダンスの選択を検出する（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）ように更に構成されている。選択を検出したことに応じて、処理ユニットは、（ｉ）少なくとも１つの近くの場所に対応するデータを受信し（例えば、受信ユニット４３２３によって）、（ｉｉ）タッチ感知ディスプレイ（例えば、ディスプレイユニット４３０１）上に少なくとも１つの近くの場所に対応する受信データを表示する（例えば、表示ユニット４３０７によって）ように構成されている。

（Ｃ３５）Ｃ２９に記載の電子デバイスの一部の実施形態では、処理ユニットは、予測されたニュース記事の少なくとも１つのアフォーダンスの選択を検出する（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３によって）ように更に構成されている。選択を検出したことに応じて、処理ユニットは、タッチ感知ディスプレイ（例えば、ディスプレイユニット４３０１）上に予測されたニュース記事を表示する（例えば、表示ユニット４３０７によって）ように構成されている。

（Ｃ３６）Ｃ２３からＣ３５のいずれか１つに記載の電子デバイスの一部の実施形態では、検索アクティブ化ジェスチャは少なくとも２つの異なるユーザインタフェースから利用可能であり、少なくとも２つの異なるユーザインタフェースのうちの第１のユーザインタフェースは、一連のホームスクリーンページのうちの対応するホームスクリーンページをタッチ感知ディスプレイ上に表示することに対応する。

（Ｃ３７）Ｃ３６に記載の電子デバイスの一部の実施形態では、対応するホームスクリーンページが一連のホームスクリーンページのうちの最初のホームスクリーンページである場合、検索アクティブ化ジェスチャは以下、すなわち、（ｉ）電子デバイスのユーザに対して実質的に下方向に移動するジェスチャ、又は（ｉｉ）ユーザに対して実質的に左から右の方向にかつ下方向に実質的に直角に移動する連続的なジェスチャ、のうちの１つを含む。

（Ｃ３８）Ｃ３７に記載の電子デバイスの一部の実施形態では、対応するホームスクリーンページが一連のホームスクリーンページのうちの第２のホームスクリーンページである場合、検索アクティブ化ジェスチャは、電子デバイスのユーザに対して実質的に下方向に移動する連続的なジェスチャを含む。

（Ｃ３９）Ｃ３６に記載の電子デバイスの一部の実施形態では、少なくとも２つの異なるユーザインタフェースのうちの第２のユーザインタフェースは、アプリケーション切替インタフェースをタッチ感知ディスプレイ上に表示することに対応する。

（Ｃ４０）Ｃ３９に記載の電子デバイスの一部の実施形態では、検索アクティブ化ジェスチャは、タッチ感知ディスプレイ上の、アプリケーション切替インタフェースの既定の検索アクティブ化部分における接触を含む。

したがって、ディスプレイと、タッチ感知面と、任意選択的に、タッチ感知面との接触の強度を検出するための１つ以上のセンサと、を有する電子デバイスは、アプリケーションに先見的にアクセスし、アプリケーション内で機能を先見的に実行するためのより速くより効率的な方法及びインタフェースが提供され、それにより、このようなデバイスにおける効果、効率及びユーザの満足度が高まる。このような方法及びインタフェースは、アプリケーションにアクセスするための従来の方法及びこの方法に関連する機能を補完してもよく又はそれらに置き換わってもよい。

（Ｄ１）一部の実施形態では、方法が、タッチ感知面（例えば、タッチ感知面１９５、図１Ｄ）と、ディスプレイ（例えば、ディスプレイ１９４、図１Ｄ）とを有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、ディスプレイ上に、電子デバイス上で実行されているアプリケーションと関連付けられたコンテンツを表示することを含む。当該方法は、タッチ感知面を介して、検出されると電子デバイスにアプリケーションとは異なる検索モードへと移行させるスワイプジェスチャを検出することを更に含む。当該方法は、また、スワイプジェスチャを検出したことに応じて、検索モードに移行することを含み、検索モードは、ディスプレイ上に表示される検索インタフェースを含む。検索モードに移行することと併せて、当該方法は、少なくとも一部、コンテンツと関連付けられた情報に基づいて、少なくとも１つの提案された検索クエリを判定することを含む。当該方法は、検索インタフェースにおいて何らかのユーザ入力を受信する前に、表示された検索インタフェースを少なくとも１つの提案された検索クエリでポピュレートすることを含む。このようにして、情報を憶えて検索インタフェースに再入力しなければならない代わりに、デバイスがユーザに対し、ユーザが見ているアプリケーションコンテンツに基づく関連の提案を提供し、ユーザは提案のうちの１つを選択する必要があるだけで、何もタイプする必要はない。

（Ｄ２）Ｄ１に記載の方法の一部の実施形態では、スワイプジェスチャを検出することは、現在表示されているコンテンツの少なくとも一部上のスワイプジェスチャを検出することを含む。

（Ｄ３）Ｄ１又はＤ２に記載の方法の一部の実施形態では、当該方法は、スワイプジェスチャを検出する前に、電子デバイスのホームスクリーンを見ることの要求に対応する入力を検出することと、入力を検出したことに応じて、アプリケーションと関連付けられたコンテンツを表示するのを停止し、電子デバイスのホームスクリーンの対応するページを表示することと、を更に含む。一部の実施形態では、対応するページは一連のホームスクリーンページのうちの初期ページであり、スワイプジェスチャは、ホームスクリーンの初期ページがディスプレイ上に表示されている間に検出される。

（Ｄ４）Ｄ１からＤ３のいずれか１つに記載の方法の一部の実施形態では、検索インタフェースはアプリケーションに半透明に重なって表示される。

（Ｄ５）Ｄ１からＤ４のいずれか１つに記載の方法の一部の実施形態では、当該方法は、コンテンツがテキストコンテンツを含むという判定に従って、少なくとも一部、テキストコンテンツに基づいて、少なくとも１つの提案された検索クエリを判定することを更に含む。

（Ｄ６）Ｄ５に記載の方法の一部の実施形態では、少なくとも一部、テキストコンテンツに基づいて、少なくとも１つの提案された検索クエリを判定することは、テキストコンテンツを分析して、少なくとも１つの提案された検索クエリを判定するために使用された１つ以上の定義済みのキーワードを検出することを含む。

（Ｄ７）Ｄ１からＤ６のいずれか１つに記載の方法の一部の実施形態では、少なくとも１つの提案された検索クエリを判定することは、複数の提案された検索クエリを判定することを含み、検索インタフェースをポピュレートすることは、検索インタフェースを複数の提案された検索クエリでポピュレートすることを含む。

（Ｄ８）Ｄ１からＤ７のいずれか１つに記載の方法の一部の実施形態では、当該方法は、タッチ感知面を介して、現在表示されている新たなコンテンツ上の新たなスワイプジェスチャを検出することと、新たなスワイプジェスチャを検出したことに応じて、検索モードに移行することであって、検索モードに移行することは、ディスプレイ上に検索インタフェースを表示することを含む、ことと、検索モードに移行することと併せて、かつ新たなコンテンツがテキストコンテンツを含まないという判定に従って、検索インタフェースを、電子デバイスのユーザによる、選択された過去の検索クエリのセットに基づいて提案された検索クエリでポピュレートすることと、を更に含む。

（Ｄ９）Ｄ８に記載の方法の一部の実施形態では、アプリケーションとは異なる第２のアプリケーションにより提供される位置情報に基づいて、検索インタフェースは対象地点と共に表示される。

（Ｄ１０）Ｄ８又はＤ９のいずれか１つに記載の方法の一部の実施形態では、検索インタフェースは１つ以上の提案されたアプリケーションを更に含む。

（Ｄ１１）Ｄ８からＤ１０のいずれか１つに記載の方法の一部の実施形態では、過去の検索クエリのセットは、少なくとも一部、最近の検索クエリの頻度に基づいて選択される。

（Ｄ１２）Ｄ１からＤ１１のいずれか１つに記載の方法の一部の実施形態では、当該方法は、検索モードに移行することと併せて、電子デバイス上で利用可能な１つ以上のアクセシビリティ機能を使用することにより、コンテンツと関連付けられた情報を取得することを更に含む。

（Ｄ１３）Ｄ１２に記載の方法の一部の実施形態では、１つ以上のアクセシビリティ機能を使用することは、（ｉ）アプリケーション内に現在表示されているテキストコンテンツに自然言語処理アルゴリズムを適用すること、及び（ｉｉ）自然言語処理アルゴリズムから取得したデータを使用してコンテンツを説明する１つ以上のキーワードを判定することであって、少なくとも１つの提案された検索クエリが１つ以上のキーワードに基づいて判定される、こと、により、１つ以上のアクセシビリティ機能を使用してコンテンツと関連付けられた情報を生成することを含む。

（Ｄ１４）Ｄ１３に記載の方法の一部の実施形態では、コンテンツを説明する１つ以上のキーワードを判定することは、（ｉ）アプリケーション内に現在表示されている非テキストコンテンツに対応するメタデータを取り出すこと、及び（ｉｉ）自然言語処理アルゴリズムから取得したデータに加えて、取り出したメタデータを使用して１つ以上のキーワードを判定することも含む。

（Ｄ１５）Ｄ１からＤ１４のいずれか１つに記載の方法の一部の実施形態では、検索インタフェースは１つ以上のトレンドクエリを更に含む。

（Ｄ１６）Ｄ１５に記載の方法の一部の実施形態では、検索インタフェースは、電子デバイスのユーザが関心を持つことが予想される１つ以上のアプリケーションを更に含む。

（Ｄ１７）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは電子デバイスにＤ１からＤ１６のいずれか１つに記載の方法を実行させる。

（Ｄ１８）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｄ１からＤ１６のいずれか１つに記載の方法実行するための手段と、を含む。

（Ｄ１９）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は電子デバイスにＤ１からＤ１６のいずれか１つに記載の方法を実行させる。

（Ｄ２０）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｄ１からＤ１６のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｄ１からＤ１６のいずれか１つに記載の方法を実行するための手段を含む。

（Ｄ２１）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４４０１、図４４）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４４０３、図４４）と、処理ユニット（例えば、処理ユニット４４０５、図４４）と、を含む電子デバイスが提供される。処理ユニットは、タッチ感知面ユニット及びディスプレイユニットと結合されている。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４４は、電子デバイス４４００に一体化されているとしてディスプレイユニット４４０１及びタッチ感知面ユニット４４０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。一部の実施形態では、タッチ感知面ユニット及びディスプレイユニットは１つのタッチ感知ディスプレイユニット（本明細書では、タッチ感知ディスプレイとも称される）に一体化されている。処理ユニットは、検出ユニット（例えば、検出ユニット４４０７、図４４）と、表示ユニット（例えば、表示ユニット４４０９、図４４）と、取り出しユニット（例えば、取り出しユニット４４１１、図４４）と、検索モード移行ユニット（例えば、検索モード移行ユニット４４１２、図４４）と、ポピュレーティングユニット（例えば、ポピュレーティングユニット４４１３、図４４）と、取得ユニット（例えば、取得ユニット４４１５、図４４）と、判定ユニット（例えば、判定ユニット４４１７、図４４）と、選択ユニット（例えば、選択ユニット４４１９、図４４）と、を含む。処理ユニット（又はユニット１００７から１０２９などのその１つ以上の構成要素）は、ディスプレイユニット（例えば、ディスプレイユニット４４０７）上に、電子デバイス上で実行されているアプリケーションと関連付けられたコンテンツを表示し（例えば、表示ユニット４４０７によって）、タッチ感知面ユニット（例えば、タッチ感知面ユニット４４０３）を介して、検出されると電子デバイスにアプリケーションとは異なる検索モードへと移行させるスワイプジェスチャを検出し（例えば、検出ユニット４４０７によって）、スワイプジェスチャを検出したことに応じて、検索モードはディスプレイユニット（例えば、ディスプレイユニット４４０７）上に表示される検索インタフェースを含む、検索モードに移行し（例えば、検索モード移行ユニット４４１２によって）、検索モードに移行することと併せて、少なくとも一部、コンテンツと関連付けられた情報に基づいて、少なくとも１つの提案された検索クエリを判定し（例えば、判定ユニット４４１７によって）、検索インタフェースにおいて何らかのユーザ入力を受信する前に、表示された検索インタフェースを少なくとも１つの提案された検索クエリでポピュレートする（例えば、ポピュレーティングユニット４４１３によって）ように構成されている。

（Ｄ２２）Ｄ２１に記載の電子デバイスの一部の実施形態では、スワイプジェスチャを検出することは、現在表示されているコンテンツの少なくとも一部上のスワイプジェスチャを検出すること（例えば、検出ユニット４４０７によって）を含む。

（Ｄ２３）Ｄ２１又はＤ２２に記載の電子デバイスの一部の実施形態では、処理ユニットは、スワイプジェスチャを検出する前に、電子デバイスのホームスクリーンを見ることの要求に対応する入力を検出し（例えば、検出ユニット４４０７によって）、入力の検出（例えば、検出ユニット４４０７によって）に応じて、アプリケーションと関連付けられたコンテンツを表示するのを停止し、電子デバイスのホームスクリーンの対応するページを表示する（例えば、表示ユニット４４０９によって）ように更に構成されており、対応するページは一連のホームスクリーンページのうちの初期ページであり、スワイプジェスチャは、ホームスクリーンの初期ページがディスプレイユニット上に表示されている間に検出される（例えば、検出ユニット４４０７によって）。

（Ｄ２４）Ｄ２１からＤ２３のいずれか１つに記載の電子デバイスの一部の実施形態では、検索インタフェースはアプリケーションに半透明に重なって表示される（例えば、表示ユニット４４０９及び／又はディスプレイユニット４４０１）。

（Ｄ２５）Ｄ２１からＤ２４のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、コンテンツがテキストコンテンツを含むという判定に従って、少なくとも一部、テキストコンテンツに基づいて、少なくとも１つの提案された検索クエリを判定する（例えば、判定ユニット４４１７によって）ように更に構成されている。

（Ｄ２６）Ｄ２５に記載の電子デバイスの一部の実施形態では、少なくとも一部、テキストコンテンツに基づいて、少なくとも１つの提案された検索クエリを判定することは、テキストコンテンツを分析して、少なくとも１つの提案された検索クエリを判定する（例えば、判定ユニット４４１７によって）ために使用された１つ以上の定義済みのキーワードを検出する（例えば、検出ユニット４４０７によって）ことを含む。

（Ｄ２７）Ｄ２１からＤ２６のいずれか１つに記載の電子デバイスの一部の実施形態では、少なくとも１つの提案された検索クエリを判定することは、複数の提案された検索クエリを判定すること（例えば、判定ユニット４４１７によって）を含み、検索インタフェースをポピュレートすることは、検索インタフェースを複数の提案された検索クエリでポピュレートすること（例えば、ポピュレーティングユニット４４１３によって）を含む。

（Ｄ２８）Ｄ２１からＤ２７のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、タッチ感知面ユニット（例えば、タッチ感知面ユニット４４０３によって）を介して、現在表示されている新たなコンテンツ上の新たなスワイプジェスチャを検出し（例えば、検出ユニット４４０７によって）、新たなスワイプジェスチャを検出したことに応じて、検索モードに移行することは、ディスプレイユニット上に検索インタフェースを表示する（例えば、ディスプレイユニット４４０９によって）ことを含む、検索モードに移行し（例えば、検索モード移行ユニット４４１２によって）、検索モードに移行することと併せて、かつ新たなコンテンツがテキストコンテンツを含まないという判定に従って、検索インタフェースを、電子デバイスのユーザによる、選択された過去の検索クエリのセットに基づいて提案された検索クエリでポピュレートする（例えば、ポピュレーティングユニット４４１３によって）ように更に構成されている。

（Ｄ２９）Ｄ２８に記載の電子デバイスの一部の実施形態では、アプリケーションとは異なる第２のアプリケーションにより提供される位置情報に基づいて、検索インタフェースに対象地点が表示される（例えば、表示ユニット４４０９）。

（Ｄ３０）Ｄ２８又はＤ２９に記載の電子デバイスの一部の実施形態では、検索インタフェースは１つ以上の提案されたアプリケーションを更に含む。

（Ｄ３１）Ｄ２８からＤ３０のいずれか１つに記載の電子デバイスの一部の実施形態では、過去の検索クエリのセットは、少なくとも一部、最近の検索クエリの頻度に基づいて選択される（例えば、選択ユニット４４１９によって）。

（Ｄ３２）Ｄ２１からＤ３１のいずれか１つに記載の電子デバイスの一部の実施形態では、処理ユニットは、検索モードに移行することと併せて、電子デバイス上で利用可能な１つ以上のアクセシビリティ機能を使用することにより、コンテンツと関連付けられた情報を取得する（例えば、取得ユニット４４１５によって）ように更に構成されている。

（Ｄ３３）Ｄ３２に記載の電子デバイスの一部の実施形態では、１つ以上のアクセシビリティ機能を使用することは、（ｉ）アプリケーション内に現在表示されているテキストコンテンツに自然言語処理アルゴリズムを適用すること、及び（ｉｉ）自然言語処理アルゴリズムから取得した（例えば、取得ユニット４４１５によって）データを使用してコンテンツを説明する１つ以上のキーワードを判定すること（例えば、判定ユニット４４１７によって）であって、少なくとも１つの提案された検索クエリが１つ以上のキーワードに基づいて判定される（例えば、判定ユニット４４１７によって）こと、により、１つ以上のアクセシビリティ機能を使用してコンテンツと関連付けられた情報を生成することを含む。

（Ｄ３４）Ｄ３３に記載の電子デバイスの一部の実施形態では、コンテンツを説明する１つ以上のキーワードを判定することは、（ｉ）アプリケーション内に現在表示されている非テキストコンテンツに対応するメタデータを取り出すこと（例えば、取り出しユニット４４１１によって）、及び（ｉｉ）自然言語処理アルゴリズムから取得したデータに加えて、取り出したメタデータを使用して１つ以上のキーワードを判定すること（例えば、判定ユニット４４１７によって）、も含む。

（Ｄ３５）Ｄ２１からＤ３４のいずれか１つに記載の電子デバイスの一部の実施形態では、検索インタフェースは１つ以上のトレンドクエリを更に含む。

（Ｄ３６）Ｄ３５に記載の電子デバイスの一部の実施形態では、検索インタフェースは、電子デバイスのユーザが関心を持つことが予想される１つ以上のアプリケーションを更に含む。

（Ｅ１）一部の実施形態では、方法が、タッチ感知面（例えば、タッチ感知面１９５、図１Ｄ）と、ディスプレイ（例えば、ディスプレイ１９４、図１Ｄ）とを有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、タッチ感知面を介して、ユーザインタフェース上のスワイプジェスチャを検出することを含み、スワイプジェスチャは、スワイプジェスチャが検出されると、電子デバイスに検索モードへと移行させる。当該方法は、スワイプジェスチャを検出したことに応じて、検索モードに移行することを更に含み、検索モードに移行することは、検索インタフェース内で何らかのユーザ入力を受信する前に、ユーザインタフェースとは異なる検索インタフェースを、第１のコンテンツアイテムでポピュレートすることを含む。一部の実施形態では、ユーザインタフェースが、アプリケーションを呼び出すための選択可能なアイコンを含むホームスクリーンとは異なるアプリケーションと関連付けられたコンテンツを含むという判定に従って、検索インタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースを、少なくとも一部、アプリケーションと関連付けられたコンテンツに基づく少なくとも１つの提案された検索クエリでポピュレートすることを含み、ユーザインタフェースがホームスクリーンのページと関連付けられているという判定に従って、検索インタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースを、電子デバイスの現在位置の閾値距離内の少なくとも１つの対象地点の選択可能な説明を含むアフォーダンスでポピュレートすることを含む。

（Ｅ２）Ｅ１に記載の方法の一部の実施形態では、検索インタフェースをアフォーダンスでポピュレートすることは、検索インタフェースの検索エントリ部分をタッチ感知面上に表示することを含み、当該方法は、検索エントリ部分における入力を検出することと、検索エントリ部分における入力を検出したことに応じて、アフォーダンスを表示するのを停止し、少なくとも１つの提案された検索クエリを検索インタフェース内に表示することを更に含む。

（Ｅ３）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは電子デバイスにＥ１又はＥ２に記載の方法を実行させる。

（Ｅ４）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｅ１又はＥ２に記載の方法を実行するための手段と、を含む。

（Ｅ５）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は電子デバイスにＥ１又はＥ２に記載の方法を実行させる。

（Ｅ６）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｅ１又はＥ２に記載の方法に従って表示されるユーザインタフェースを含む。更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｅ１又はＥ２に記載の方法を実行するための手段を含む。

（Ｅ７）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４５０１、図４５）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４５０３、図４５）と、処理ユニット（例えば、処理ユニット４５０５、図４５）と、を含む電子デバイスが提供される。処理ユニットは、タッチ感知面ユニット及びディスプレイユニットと結合されている。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４５は、電子デバイス４５００に一体化されているとしてディスプレイユニット４５０１及びタッチ感知面ユニット４５０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。一部の実施形態では、タッチ感知面ユニット及びディスプレイユニットは１つのタッチ感知ディスプレイユニット（本明細書では、タッチ感知ディスプレイとも称される）に一体化されている。処理ユニットは、検出ユニット（例えば、検出ユニット４５０７、図４５）と、表示ユニット（例えば、表示ユニット４５０９、図４５）と、ポピュレーティングユニット（例えば、ポピュレーティングユニット４５１１、図４５）と、検索モード移行ユニット（例えば、検索モード移行ユニット４５１３、図４５）と、を含む。処理ユニット（又はユニット４５０７から４５１３などのその１つ以上の構成要素）は、タッチ感知面ユニット（例えば、タッチ感知面ユニット４５０３）を介して、ユーザインタフェース上のスワイプジェスチャであって、スワイプジェスチャは、スワイプジェスチャが検出されると、電子デバイスに検索モードへと移行させる、スワイプジェスチャを検出し（例えば、検出ユニット４５０７によって）、スワイプジェスチャを検出したことに応じて、検索モードに移行する（例えば、検索モード移行ユニット４５１３によって）、ように構成されており、検索モードに移行することは、検索インタフェース内で何らかのユーザ入力を受信する前に、ユーザインタフェースとは異なる検索インタフェースを、第１のコンテンツアイテムでポピュレートする（例えば、ポピュレーティングユニット４５１１によって）含む。一部の実施形態では、ユーザインタフェースが、アプリケーションを呼び出すための選択可能なアイコンを含むホームスクリーンとは異なるアプリケーションと関連付けられたコンテンツを含むという判定に従って、検索インタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースを、少なくとも一部、アプリケーションと関連付けられたコンテンツに基づく少なくとも１つの提案された検索クエリでポピュレートする（例えば、ポピュレーティングユニット４５１１によって）ことを含み、ユーザインタフェースがホームスクリーンのページと関連付けられているという判定に従って、検索インタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースを、電子デバイスの現在位置の閾値距離内の少なくとも１つの対象地点の選択可能な説明を含むアフォーダンスでポピュレートすること（例えば、ポピュレーティングユニット４５１１によって）を含む。

（Ｅ８）Ｅ７に記載の電子デバイスの一部の実施形態では、検索インタフェースをアフォーダンスでポピュレートすることは、検索インタフェースの検索エントリ部分を表示すること（例えば、表示ユニット４５０７及び／又はディスプレイユニット４５０１によって）を含み、処理ユニットは、検索エントリ部分における入力を検出し（例えば、検出ユニット４５０７によって）、検索エントリ部分の入力を検出したことに応じて、アフォーダンスを表示する（例えば、表示ユニット４５０７及び／又はディスプレイユニット４５０１によって）のを停止し、少なくとも１つの提案された検索クエリを検索インタフェース内に表示する（例えば、表示ユニット４５０７及び／又はディスプレイユニット４５０１によって）ように更に構成されている。

（Ｆ１）一部の実施形態では、方法が、位置センサと、タッチ感知面（例えば、タッチ感知面１９５、図１Ｄ）と、ディスプレイ（例えば、ディスプレイ１９４、図１Ｄ）と、を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、自動的にかつユーザからの命令なしに、電子デバイスのユーザが地理的位置において停止した車両内にいると判定することと、地理的位置においてユーザが車両から離れたと判定すると、地理的位置を特定するために位置センサから取り出された位置情報が精度基準を満たすかどうかを判定することと、を含む。当該方法は、位置情報が精度基準を満たさないと判定すると、ユーザに対し、地理的位置に関する情報を入力するというプロンプトを提供することを更に含む。当該方法は、また、プロンプトの提供に応じて、ユーザから地理的位置についての情報を受信し、この情報を車両位置情報として記憶することを含む。

（Ｆ２）Ｆ１に記載の方法の一部の実施形態では、当該方法は、位置情報が精度基準を満たすと判定すると、自動的にかつユーザからの命令なしに、この位置情報を車両位置情報として記憶することを更に含む。

（Ｆ３）請求項Ｆ２に記載の方法の一部の実施形態では、当該方法は、ユーザが地理的位置に向かっているという判定に従って、車両位置情報を含むユーザインタフェースオブジェクトを表示することを更に含む。

（Ｆ４）請求項Ｆ３に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、ユーザの現在位置に関する識別子と地理的位置に関する別の識別子とを含む地図オブジェクトである。

（Ｆ５）請求項Ｆ４に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは電子デバイスのロックスクリーン上に表示される。

（Ｆ６）請求項Ｆ４に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、電子デバイスに検索モードへと移行させるスワイプジェスチャに応じて表示される。

（Ｆ７）請求項Ｆ６に記載の方法の一部の実施形態では、ユーザが地理的位置に向かっているかどうかを判定することは、スワイプジェスチャの受信に応じて実行される。

（Ｆ８）Ｆ１からＦ７のいずれか１つに記載の方法の一部の実施形態では、プロンプトは、電子デバイスを介して利用可能なバーチャルアシスタントによって提供される音声プロンプトであり、ユーザから情報を受信することは、ユーザから、地理的位置を特定する口頭での説明を受信することを含み、ユーザインタフェースオブジェクトを表示することは、選択されると、デバイスに口頭での説明を再生させる選択可能なアフォーダンスを表示することを含む。

（Ｆ９）Ｆ１からＦ７のいずれか１つに記載の方法の一部の実施形態では、プロンプトは電子デバイスのディスプレイ上に表示され、ユーザから情報を受信することは、ユーザから、地理的位置を特定するテキストでの説明を受信することを含み、ユーザインタフェースオブジェクトを表示することは、ユーザからのテキストでの説明を表示することを含む。

（Ｆ１０）Ｆ１からＦ７のいずれか１つに記載の方法の一部の実施形態では、ユーザが地理的位置に向かっているかどうかを判定することは、位置センサから受信した新たな位置情報を使用して、電子デバイスが地理的位置に向かって移動していると判定することを含む。

（Ｆ１１）Ｆ１０に記載の方法の一部の実施形態では、ユーザが地理的位置に向かっているかどうかを判定することは、（ｉ）電子デバイスが異なる地理的位置に閾値時間を超えて留まっていると判定すること、及び（ｉｉ）新たな位置情報が、電子デバイスが異なる地理的位置から離れ、地理的位置の方に向かっていることを示していると判定すること、を含む。

（Ｆ１２）Ｆ１からＦ１１のいずれか１つに記載の方法の一部の実施形態では、地理的位置において停止した車両内にユーザがいると判定することは、（ｉ）電子デバイスが閾値速度超で移動していると判定することによりユーザが車両内にいると判定することと、（ｉｉ）（ａ）電子デバイスが閾値時間を超えて地理的位置に留まっていると判定すること、（ｂ）電子デバイスと車両との間の通信リンクが切断されたと判定すること、及び（ｃ）地理的位置が駐車場内の位置に対応すると判定すること、のうちの１つ以上によって、車両が地理的位置において停止したと判定することを含む。

（Ｆ１３）請求項Ｆ１２に記載の方法の一部の実施形態では、車両が地理的位置において停止したと判定することは、電子デバイスが閾値時間を超えて地理的位置に留まっていると判定することを含む。

（Ｆ１４）Ｆ１２又はＦ１３に記載の方法の一部の実施形態では、車両が地理的位置において停止したと判定することは、電子デバイスと車両との間の通信リンクが切断されたと判定することを含む。

（Ｆ１５）Ｆ１２からＦ１４のいずれか１つに記載の方法の一部の実施形態では、車両が地理的位置において停止したと判定することは、地理的位置が駐車場内の位置に対応すると判定することを含む。

（Ｆ１６）Ｆ１からＦ１５のいずれか１つに記載の方法の一部の実施形態では、精度基準は、位置情報と関連付けられたＧＰＳ読取値の精度が精度の閾値レベルを超える場合に満たされる基準を含む。

（Ｆ１７）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、位置センサと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＦ１からＦ１６のいずれか１つに記載の方法を実行させる。

（Ｆ１８）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、位置センサと、Ｆ１からＦ１６のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｆ１９）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令が、タッチ感知面と、ディスプレイと、位置センサと、を有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＦ１からＦ１６のいずれか１つに記載の方法を実行させる。

（Ｆ２０）更なる一態様では、タッチ感知面と、ディスプレイと、位置センサと、を有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｆ１からＦ１６のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。更なる一態様では、タッチ感知面と、ディスプレイと、位置センサと、を含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｆ１からＦ１６のいずれか１つに記載の方法を実行するための手段を含む。

（Ｆ２１）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４６０１、図４６）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４６０３、図４６）と、位置センサユニット（例えば、位置センサユニット４６０７、図４６）と、処理ユニット（例えば、処理ユニット４６０５、図４６）と、を含む電子デバイスが提供される。処理ユニットは、タッチ感知面ユニット、ディスプレイユニット、及び位置センサユニットと結合されている。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４６は、電子デバイス４６００に一体化されているとしてディスプレイユニット４６０１及びタッチ感知面ユニット４６０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。一部の実施形態では、タッチ感知面ユニット及びディスプレイユニットは１つのタッチ感知ディスプレイユニット（本明細書では、タッチ感知ディスプレイとも称される）に一体化されている。処理ユニットは、表示ユニット（例えば、表示ユニット４６０９、図４６）と、取り出しユニット（例えば、取り出しユニット４６１１、図４６）と、判定ユニット（例えば、判定ユニット４６１３、図４６）と、記憶ユニット（例えば、記憶ユニット４６１５、図４６）と、特定ユニット（例えば、特定ユニット４６１７、図４６）と、選択ユニット（例えば、選択ユニット４６１９、図４６）と、受信ユニット（例えば、受信ユニット４６２１、図４６）と、提供ユニット（例えば、提供ユニット４６２３、図４６）と、再生ユニット（例えば、再生ユニット４６２５、図４６）と、を含む。処理ユニット（又はユニット４６０７から４６２５などのその１つ以上の構成要素）は、自動的にかつユーザからの命令なしに、電子デバイスのユーザが地理的位置において停止した車両内にいると判定し（例えば、判定ユニット４６１３によって）、地理的位置においてユーザが車両から離れたと判定すると、地理的位置を特定する（例えば、特定ユニット４６１７によって）ために位置センサユニット（例えば、位置センサユニット４６０７）から取り出された（例えば、取り出しユニット４６１１によって）位置情報が精度基準を満たすかどうかを判定し（例えば、判定ユニット４６１３によって）、位置情報が精度基準を満たさないと判定する（例えば、判定ユニット４６１３によって）と、ユーザに対し、地理的位置に関する情報を入力するというプロンプトを提供し（例えば、提供ユニット４６２３によって）、プロンプトの提供に応じて、ユーザから地理的位置についての情報を受信し（例えば、受信ユニット４６２１によって）、この情報を車両位置情報として記憶する（例えば、記憶ユニット４６１５によって）ように構成されている。

（Ｆ２２）Ｆ２１に記載の電子デバイスの一部の実施形態では、処理ユニットは、位置情報が精度基準を満たすと判定すると、自動的にかつユーザからの命令なしに、この位置情報を車両位置情報として記憶する（例えば、記憶ユニット４６１５によって）ように更に構成されている。

（Ｆ２３）Ｆ２２に記載の電子デバイスの一部の実施形態では、処理ユニットは、ユーザが地理的位置に向かっているという判定に従って、車両位置情報を含むユーザインタフェースオブジェクトを表示する（例えば、ディスプレイユニット４６０１と併せて表示ユニット４６０９によって）ように更に構成されている。

（Ｆ２４）Ｆ２３に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、ユーザの現在位置に関する識別子と地理的位置に関する別の識別子とを含む地図オブジェクトである。

（Ｆ２５）Ｆ２４に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは電子デバイスのロックスクリーン上に表示される（例えば、ディスプレイユニット４６０１と併せて表示ユニット４６０９によって）。

（Ｆ２６）Ｆ２４に記載の電子デバイスの一部の実施形態では、ユーザインタフェースオブジェクトは、電子デバイスに検索モードへと移行させるスワイプジェスチャに応じて表示される（例えば、ディスプレイユニット４６０１と併せて表示ユニット４６０９によって）。

（Ｆ２７）Ｆ２６に記載の電子デバイスの一部の実施形態では、ユーザが地理的位置に向かっているかどうかを判定することは、スワイプジェスチャの受信に応じて実行される。

（Ｆ２８）Ｆ２１からＦ２７のいずれか１つに記載の電子デバイスの一部の実施形態では、プロンプトは、電子デバイスを介して利用可能なバーチャルアシスタントによって提供される音声プロンプトであり、ユーザから情報を受信することは、ユーザから、地理的位置を特定する口頭での説明を受信すること（例えば、受信ユニット４６２１によって）を含み、ユーザインタフェースオブジェクトを表示することは、選択されると（例えば、選択ユニット４６１９によって）、デバイスに口頭での説明を再生させる（例えば、再生ユニット４６２５によって）選択可能なアフォーダンスを表示する（例えば、ディスプレイユニット４６０１と併せて表示ユニット４６０９によって）ことを含む。

（Ｆ２９）Ｆ２１からＦ２７のいずれか１つに記載の電子デバイスの一部の実施形態では、プロンプトは電子デバイスのディスプレイ上に表示され（例えば、ディスプレイユニット４６０１と併せて表示ユニット４６０９によって）、ユーザから情報を受信することは、ユーザから、地理的位置を特定するテキストでの説明を受信すること（例えば、受信ユニット４６２１によって）を含み、ユーザインタフェースオブジェクトを表示することは、ユーザからのテキストでの説明を表示することを含む。

（Ｆ３０）Ｆ２１からＦ２７のいずれか１つに記載の電子デバイスの一部の実施形態では、ユーザが地理的位置に向かっているかどうかを判定することは、位置センサユニット（例えば、位置センサユニット４６０７）から受信した（例えば、受信ユニット４６２１によって）新たな位置情報を使用して、電子デバイスが地理的位置に向かって移動していると判定する（例えば、判定ユニット４６１３によって）ことを含む。

（Ｆ３１）Ｆ３０に記載の電子デバイスの一部の実施形態では、ユーザが地理的位置に向かっているかどうかを判定することは、（ｉ）電子デバイスが異なる地理的位置に閾値時間を超えて留まっていると判定すること（例えば、判定ユニット４６１３によって）、及び（ｉｉ）新たな位置情報が、電子デバイスが異なる地理的位置から離れ、地理的位置の方に向かっていることを示していると判定すること（例えば、判定ユニット４６１３によって）を含む。

（Ｆ３２）Ｆ２１からＦ３１のいずれか１つに記載の電子デバイスの一部の実施形態では、地理的位置において停止した車両内にユーザがいると判定することは、（ｉ）電子デバイスが閾値速度超で移動していると判定すること（例えば、判定ユニット４６１３によって）によりユーザが車両内にいると判定することと、（ｉｉ）（ａ）電子デバイスが閾値時間を超えて地理的位置に留まっていると判定すること（例えば、判定ユニット４６１３によって）、（ｂ）電子デバイスと車両との間の通信リンクが切断されたと判定すること（例えば、判定ユニット４６１３によって）、及び（ｃ）地理的位置が駐車場内の位置に対応すると判定すること（例えば、判定ユニット４６１３によって）、のうちの１つ以上によって、車両が地理的位置において停止したと判定することと、を含む。

（Ｆ３３）Ｆ３２に記載の電子デバイスの一部の実施形態では、車両が地理的位置において停止したと判定することは、電子デバイスが閾値時間を超えて地理的位置に留まっていると判定すること（例えば、判定ユニット４６１３によって）を含む。

（Ｆ３４）Ｆ３２又はＦ３３に記載の電子デバイスの一部の実施形態では、車両が地理的位置において停止したと判定することは、電子デバイスと車両との間の通信リンクが切断されたと判定すること（例えば、判定ユニット４６１３によって）を含む。

（Ｆ３５）Ｆ３２からＦ３４のいずれか１つに記載の電子デバイスの一部の実施形態では、車両が地理的位置において停止したと判定することは、地理的位置が駐車場内の位置に対応すると判定すること（例えば、判定ユニット４６１３によって）を含む。

（Ｆ３６）Ｆ２１からＦ３５のいずれか１つに記載の電子デバイスの一部の実施形態では、精度基準は、位置情報と関連付けられたＧＰＳ読取値の精度が精度の閾値レベルを超える場合に満たされる基準を含む。

（Ｇ１）一部の実施形態では、方法が、位置センサと、タッチ感知面（例えば、タッチ感知面１９５、図１Ｄ）と、ディスプレイ（例えば、ディスプレイ１９４、図１Ｄ）と、を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、位置センサを使用して、電子デバイスの地理的位置を監視することを含む。当該方法は、監視された地理的位置に基づいて、電子デバイスが既定の種類の対象地点の閾値距離内にあると判定することを更に含む。当該方法は、また、電子デバイスが対象地点の閾値距離内にあると判定したことに従って、対象地点において現在人気のある少なくとも１つのアクティビティを特定し、対象地点に関する情報を取り出すことを含み、対象地点において現在人気のある少なくとも１つのアクティビティに関する情報を取り出すことを含む。当該方法は、タッチ感知面を介して、検出されると電子デバイスに検索モードへと移行させる第１の入力を検出することと、第１の入力を検出したことに応じて、検索モードに移行することであって、検索モードに移行することは、検索インタフェースにおいて何らかのユーザ入力を受信する前に、ディスプレイを介して、（ｉ）少なくとも１つのアクティビティに関する情報と、（ｉｉ）少なくとも１つのアクティビティが対象地点において現在人気があると特定されたというインジケーションと、を含むアフォーダンスを提示することを含む、ことと、を更に含む。

（Ｇ２）請求項Ｇ１に記載の方法の一部の実施形態では、当該方法は、第２の入力を検出することと、第２の入力を検出したことに応じて、対象地点とは異なる第２の対象地点における現在のアクティビティに関する利用可能な情報を含むようにアフォーダンスを更新することと、を含み、対象地点は電子デバイスの閾値距離の範囲内である。

（Ｇ３）Ｇ１又はＧ２に記載の方法の一部の実施形態では、アフォーダンスは対象地点の選択可能なカテゴリを更に含み、当該方法は、対応する選択可能なカテゴリの選択を検出することと、選択を検出したことに応じて、デバイスの第２の閾値距離の範囲内に位置する追加の対象地点に関する情報を含むようにアフォーダンスを更新することと、を更に含む。

（Ｇ４）Ｇ１からＧ３のいずれか１つに記載の方法の一部の実施形態では、対象地点は遊園地であり、取り出される情報は、遊園地の乗り物の現在の待ち時間を含む。

（Ｇ５）請求項Ｇ４に記載の方法の一部の実施形態では、取り出される情報は、電子デバイスの既定の距離の範囲内に位置する乗り物の待ち時間に関する情報を含む。

（Ｇ６）Ｇ１からＧ３のいずれか１つに記載の方法の一部の実施形態では、対象地点はレストランであり、取り出される情報は、レストランの人気のメニュー項目に関する情報を含む。

（Ｇ７）請求項Ｇ６に記載の方法の一部の実施形態では、取り出される情報は、電子デバイスのユーザと関連付けられたソーシャルネットワークから取り出される。

（Ｇ８）Ｇ１からＧ３のいずれか１つに記載の方法の一部の実施形態では、対象地点は映画館であり、取り出される情報は、映画館の上映時間に関する情報を含む。

（Ｇ９）請求項Ｇ８に記載の方法の一部の実施形態では、取り出される情報は、電子デバイスのユーザと関連付けられたソーシャルネットワークから取り出される。

（Ｇ１０）Ｇ１からＧ９のいずれか１つに記載の方法の一部の実施形態では、電子デバイスのロック解除後、アフォーダンスは、電子デバイスのホームスクリーンの初期ページ上における実質的に水平方向のスワイプに応じて利用可能である。

（Ｇ１１）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、位置センサと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＧ１からＧ１０のいずれか１つに記載の方法を実行させる。

（Ｇ１２）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、位置センサと、Ｇ１からＧ１０のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｇ１３）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令が、タッチ感知面と、ディスプレイと、位置センサと、を有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＧ１からＧ１０のいずれか１つに記載の方法を実行させる。

（Ｇ１４）更なる一態様では、タッチ感知面と、ディスプレイと、位置センサと、を有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｇ１からＧ１０のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。更なる一態様では、タッチ感知面と、ディスプレイと、位置センサと、を含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｇ１からＧ１０のいずれか１つに記載の方法を実行するための手段を含む。

（Ｇ１５）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４７０１、図４７）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４７０３、図４７）と、位置センサユニット４７０７と、処理ユニット（例えば、処理ユニット４７０５、図４７）と、を含む電子デバイスが提供される。処理ユニットは、タッチ感知面ユニット、ディスプレイユニット、及び位置センサユニットと結合されている。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（すなわち、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４７は、電子デバイス４７００に一体化されているとしてディスプレイユニット４７０１及びタッチ感知面ユニット４７０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。一部の実施形態では、タッチ感知面ユニット及びディスプレイユニットは１つのタッチ感知ディスプレイユニット（本明細書では、タッチ感知ディスプレイとも称される）に一体化されている。処理ユニットは、検出ユニット（例えば、検出ユニット４７０９、図４７）と、表示ユニット（例えば、表示ユニット４７１１、図４７）と、取り出しユニット（例えば、取り出しユニット４７１３、図４７）と、判定ユニット（例えば、判定ユニット４７１５、図４７）と、特定ユニット（例えば、特定ユニット４７１７、図４７）と、ロック解除ユニット（例えば、ロック解除ユニット４７１９、図４７）と、検索モード移行ユニット（例えば、検索モード移行ユニット４７２１、図４７）と、を含む。処理ユニット（又はユニット４７０９から４７２１などのその１つ以上の構成要素）は、電子デバイスのユーザから何ら命令を受信することなく、位置センサユニット（例えば、位置センサユニット４７０７）を使用して、電子デバイスの地理的位置を監視し、監視された地理的位置に基づいて、電子デバイスが既定の種類の対象地点の閾値距離内にあると判定し（例えば、判定ユニット４７１５によって）、電子デバイスが対象地点の閾値距離内にあると判定したことに従って、対象地点において現在人気のある少なくとも１つのアクティビティを特定し（例えば、特定ユニット４７１７によって）、対象地点において現在人気のある少なくとも１つのアクティビティに関する情報を取り出すことを含む、対象地点に関する情報を取り出し（例えば、取り出しユニット４７１３によって）、タッチ感知面ユニット（例えば、タッチ感知面ユニット４７０３）を介して、検出されると電子デバイスに検索モードへと移行させる第１の入力を検出し（例えば、検出ユニット４７０９によって）、第１の入力を検出したことに応じて、検索モードに移行する（例えば、検索モード移行ユニット４７２１によって）ように構成されており、検索モードに移行することは、検索インタフェースにおいて何らかのユーザ入力を受信する前に、ディスプレイユニット（例えば、ディスプレイユニット４７０１）を介して、（ｉ）少なくとも１つのアクティビティに関する情報と、（ｉｉ）少なくとも１つのアクティビティが対象地点において現在人気があると特定されたというインジケーションと、を含むアフォーダンスを提示すること（例えば、表示ユニット４７１１によって）を含む。

（Ｇ１６）Ｇ１５に記載の電子デバイスの一部の実施形態では、処理ユニットは、第２の入力を検出し（例えば、検出ユニット４７０９によって）、第２の入力を検出したことに応じて、対象地点とは異なる第２の対象地点における現在のアクティビティに関する利用可能な情報を含むようにアフォーダンスを更新する（例えば、表示ユニット４７１１によって）ように更に構成されており、対象地点は電子デバイスの閾値距離の範囲内である。

（Ｇ１７）Ｇ１５又はＧ１６に記載の電子デバイスの一部の実施形態では、アフォーダンスは対象地点の選択可能なカテゴリを更に含み、処理ユニットは、対応する選択可能なカテゴリの選択を検出し（例えば、検出ユニット４７０９によって）、選択を検出したことに応じて、デバイスの第２の閾値距離の範囲内に位置する追加の対象地点に関する情報を含むようにアフォーダンスを更新する（例えば、表示ユニット４７１１によって）ように更に構成されている。

（Ｇ１８）Ｇ１５からＧ１７のいずれか１つに記載の電子デバイスの一部の実施形態では、対象地点は遊園地であり、取り出される情報は、遊園地の乗り物の現在の待ち時間を含む。

（Ｇ１９）Ｇ１８に記載の電子デバイスの一部の実施形態では、取り出される情報は、電子デバイスの既定の距離の範囲内に位置する乗り物の待ち時間に関する情報を含む。

（Ｇ２０）Ｇ１５からＧ１７のいずれか１つに記載の電子デバイスの一部の実施形態では、対象地点はレストランであり、取り出される情報は、レストランの人気のメニュー項目に関する情報を含む。

（Ｇ２１）Ｇ２０に記載の電子デバイスの一部の実施形態では、取り出される情報は、電子デバイスのユーザと関連付けられたソーシャルネットワークから取り出される。

（Ｇ２２）Ｇ１５からＧ１７のいずれか１つに記載の電子デバイスの一部の実施形態では、対象地点は映画館であり、取り出される情報は、映画館の上映時間に関する情報を含む。

（Ｇ２３）Ｇ２２に記載の電子デバイスの一部の実施形態では、取り出される情報は、電子デバイスのユーザと関連付けられたソーシャルネットワークから取り出される。

（Ｇ２４）Ｇ１５からＧ２３のいずれか１つに記載の電子デバイスの一部の実施形態では、電子デバイスのロック解除（例えば、ロック解除ユニット４７１９によって）後、アフォーダンスは、電子デバイスのホームスクリーンの初期ページ上における実質的に水平方向のスワイプに応じて利用可能である。

（Ｈ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（タッチスクリーン１１２、図１Ｃにおいて示されるように、一部の実施形態では、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、音声通信の少なくとも一部（例えば、１０秒以下の生通話又は録音済みボイスメール）を受信することを含み、音声通信の一部は、電子デバイスのユーザとは異なるリモートデバイスのリモートユーザによって提供されるスピーチを含む。当該方法は、また、コンテンツアイテムを、少なくとも一部、リモートデバイスのリモートユーザによって提供されるスピーチに基づいて抽出することを含む。当該方法は、コンテンツアイテムが電子デバイス上で現在利用可能かどうかを判定することを更に含む。当該方法は、コンテンツアイテムが電子デバイス上で現在利用可能でないという判定に従って、（ｉ）コンテンツアイテムと関連付けられたアプリケーションを特定することと、（ｉｉ）コンテンツアイテムの選択可能な説明をディスプレイ上に表示することと、を含む。当該方法は、選択可能な説明の選択を検出したことに応じて、コンテンツアイテムを、特定されたアプリケーションで提示するために記憶すること（例えば、コンテンツアイテムを、特定されたアプリケーションによる提示のために利用できるように記憶すること）を含む。このようにして、ユーザは、音声通信で言及された又は話されたコンテンツアイテムを記憶することができ、話された」詳細の全てを憶え、後にこれら詳細を入力して適切なコンテンツアイテムを作成する必要はない。その代わり、電子デバイスが、種々の対応するコンテンツアイテムを説明するスピーチに基づいてコンテンツアイテムを検出及び抽出し、その後、ユーザが選択できるコンテンツアイテムの選択可能な説明を提供し、対応するコンテンツアイテムを電子デバイスに記憶することができる。

（Ｈ２）Ｈ１に記載の方法の一部の実施形態では、コンテンツアイテムは新たなイベントである。

（Ｈ３）Ｈ１に記載の方法の一部の実施形態では、コンテンツアイテムは、電子デバイス上のカレンダアプリケーションと現在関連付けられているイベントの新たなイベント詳細である。

（Ｈ４）Ｈ１に記載の方法の一部の実施形態では、コンテンツアイテムは新たな連絡先である。

（Ｈ５）Ｈ１に記載の方法の一部の実施形態では、コンテンツアイテムは、電子デバイス上の電話アプリケーションと関連付けられた既存の連絡先の新たな連絡先情報である。

（Ｈ６）Ｈ１からＨ５のいずれか１つに記載の方法の一部の実施形態では、音声通信は生通話である。

（Ｈ７）Ｈ１からＨ５のいずれか１つに記載の方法の一部の実施形態では、音声通信は生ＦａｃｅＴｉｍｅ通話である。

（Ｈ８）Ｈ１からＨ５のいずれか１つに記載の方法の一部の実施形態では、音声通信は録音済みボイスメールである。

（Ｈ９）Ｈ１からＨ８のいずれか１つに記載の方法の一部の実施形態では、選択可能な説明を表示することは、ユーザインタフェース内に、電話アプリケーションを使用して行った最近の通話を含む選択可能な説明を表示することを含む。このようにして、ユーザは、最近の通話を含む、ユーザインタフェースから直接、抽出されたコンテンツアイテム（例えば、対応する音声通信の最中に抽出されたもの）に簡単かつ便利にアクセスすることができる。

（Ｈ１０）Ｈ９に記載の方法の一部の実施形態では、選択可能な説明は、コンテンツアイテムが音声通信と関連付けられているというインジケーションと共に表示される。

（Ｈ１１）Ｈ９に記載の方法の一部の実施形態では、選択を検出することは、最近の通話を含むユーザインタフェースが表示されている間に選択を受信することを含む。

（Ｈ１２）Ｈ１からＨ１１のいずれか１つに記載の方法の一部の実施形態では、当該方法は、コンテンツアイテムの選択可能な説明を表示することと併せて、電子デバイスのユーザに対し、コンテンツアイテムが検出されたというフィードバックを提供すること（例えば、電子デバイスにより発生する触覚フィードバック又は第２のデバイス上のユーザインタフェースオブジェクトの提示。これにより、ユーザは通話中に自身の耳から電話を離す必要はない）を更に含む。このようにして、音声通信中、コンテンツアイテムが検出された／抽出されたという簡潔なインジケーションがユーザに提供され、その後、ユーザはコンテンツアイテムを記憶するかどうかを決定することができる。

（Ｈ１３）Ｈ１２に記載の方法の一部の実施形態では、フィードバックを提供することは、電子デバイスの近傍にある異なる電子デバイス（例えば、ラップトップコンピュータ、テレビモニタ、スマートウォッチ等）にコンテンツアイテムの検出に関する情報を送信することを含む。このようにして、ユーザは音声通信を中断する必要はなく、それでも、検出された／抽出されたコンテンツアイテムに関する詳細を異なるデバイスで閲覧することができる。

（Ｈ１４）Ｈ１からＨ１３のいずれか１つに記載の方法の一部の実施形態では、当該方法は、音声通信が第１の物理的位置に関する情報（例えば、通話中に述べられた住所又は通話中に話されたレストラン名等。更なる詳細は以下に記載する）を含むと判定することを更に含む。当該方法は、また、入力を検出することと、入力を検出したことに応じて位置データを受け付けることができるアプリケーションを開き、このアプリケーションを、第１の物理的位置に関する情報でポピュレートすることと、を含む。このようにして、電子デバイスは、イベント及び連絡先情報を検出し、抽出することに加えて、音声通信で話された位置情報を抽出し、この位置情報をユーザに適切なアプリケーションで提供することができる（例えば、このため、通話で話された特定の位置詳細、特にユーザになじみのない可能性のある新たな詳細を憶える負担をユーザにかけず、デバイスがこれらの位置詳細を抽出し、これらをユーザによる使用のために表示する）。

（Ｈ１５）Ｈ１４に記載の方法の一部の実施形態では、アプリケーションは地図アプリケーションであり、地図アプリケーションを、第１の物理的位置に関する情報でポピュレートすることは、地図アプリケーション内に表示される地図を、第１の物理的位置に対応する位置識別子でポピュレートすることを含む。このようにして、ユーザは、新たに抽出された位置詳細を簡単に使用し、新たな目的地へと移動することができ、特定の位置がどれほど離れているかを閲覧することができると共に、地図アプリケーションによって提供される他の機能を簡単に使用することができる。

（Ｈ１６）Ｈ１からＨ１３のいずれか１つに記載の方法の一部の実施形態では、当該方法は、音声通信が第１の物理的位置に関する情報を含むと判定することを更に含む。当該方法は、また、入力（例えば、スワイプジェスチャなどの検索アクティブ化ジェスチャ。以下詳細に記載する）を検出することと、入力を検出したことに応じて、検索インタフェースを、第１の物理的位置に関する情報でポピュレートすることと、を含む。このようにして、位置情報をユーザに対し、特定のアプリケーションで使用するために提供することに加えて（又は、その代わりとして）、電子デバイスはまた、位置情報を、検索インタフェースで使用するために（例えば、関連対象地点を検索するために、又は電話番号、メニュー等などの第１の物理的位置に関する追加の詳細を検索するために）提供することができる。

（Ｈ１７）Ｈ１からＨ１６のいずれか１つに記載の方法の一部の実施形態では、コンテンツアイテムを抽出することは、既定の種類のコンテンツの検出のために音声通信の一部を分析することを含み、分析は、電子デバイスと通信しているオーディオシステムを介して音声通信を出力している間に実行される（例えば、音声通信は、音声通信が電子デバイスのユーザに出力されている間にリアルタイムで分析される）。

（Ｈ１８）Ｈ１７に記載の方法の一部の実施形態では、音声通信を分析することは、（ｉ）リモートデバイスのリモートユーザによって提供されるスピーチをテキストに変換することと、（ｉｉ）テキストが１つ以上の定義済みのキーワードを含むかどうかを判定するためにテキストに自然言語処理アルゴリズムを適用することと、（ｉｉｉ）テキストが対応する定義済みのキーワードを含むという判定に従って、音声通信が、コンテンツアイテムを説明するスピーチを含むと判定することと、を含む。

（Ｈ１９）Ｈ１からＨ１８のいずれか１つに記載の方法の一部の実施形態では、音声通信の少なくとも一部を受信することは、電子デバイスのユーザから、音声通信の一部が分析されるべきであるというインジケーションを受信することを含む。

（Ｈ２０）Ｈ１９に記載の方法の一部の実施形態では、インジケーションは、ハードウェアボタンの選択に対応する（例えば、ユーザは、音声通信がオーディオシステムにより出力されている間にハードウェアボタンを選択し、既定の秒数（例えば、前の１０、１５、又は２０秒）の音声通信が分析されるべきであるということを示す）。一部の実施形態では、ボタンはまた、ユーザの選択用に電子デバイスのディスプレイ上に提示されるボタン（例えば、音声通信中に表示される、「ここをタップしてこの音声通信の新たなコンテンツを分析する」というボタン）であってもよい。

（Ｈ２１）Ｈ１９に記載の方法の一部の実施形態では、インジケーションは、電子デバイスのユーザからの、「ヘイＳｉｒｉ（hey Siri）」という言葉を含むコマンドに対応する。したがって、ユーザは、電子デバイスに対し、音声通信の一部の分析を開始し、音声通信で話されたコンテンツアイテム（イベント、連絡先情報、及び物理的位置に関する情報など）を検出するように簡単に指示することができる。

（Ｈ２２）Ｈ１からＨ２１のいずれか１つに記載の方法の一部の実施形態では、当該方法は、音声通信の第２部分を受信することを更に含む。第２部分は、リモートデバイスのリモートユーザによって提供されるスピーチと、電子デバイスのユーザによって提供されるスピーチと、を含む（例えば、音声通信は生通話であり、第２部分はユーザとリモートユーザとの間の会話を含む）。当該方法は、また、第２のコンテンツアイテムを、少なくとも一部、リモートデバイスのリモートユーザによって提供されるスピーチ、及び電子デバイスのユーザによって提供されるスピーチに基づいて抽出することを含む。当該方法は、第２のコンテンツアイテムが電子デバイス上で現在利用可能でないという判定に従って、（ｉ）第２のコンテンツアイテムと関連付けられた第２のアプリケーションを特定することと、（ｉｉ）第２のコンテンツアイテムの第２の選択可能な説明をディスプレイ上に表示することと、を含む。当該方法は、第２の選択可能な説明の選択を検出したことに応じて、第２のコンテンツアイテムを、特定された第２のアプリケーションで提示するために記憶することを含む。

（Ｈ２３）Ｈ２２に記載の方法の一部の実施形態では、電話アプリケーションを使用して行った最近の通話を含む、選択可能な説明及び第２の選択可能な説明がユーザインタフェース内に表示される。このようにして、ユーザに対し、いくつかの音声通信（例えば、いくつかの通話、ボイスメール、又は通話及びボイスメール）で検出されたコンテンツアイテムを便利に含む１つのインタフェースが提供される。

（Ｈ２４）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＨ１からＨ２３のいずれか１つに記載の方法を実行させる。

（Ｈ２５）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｈ１からＨ２３のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｈ２６）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＨ１からＨ２３のいずれか１つに記載の方法を実行させる。

（Ｈ２７）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｈ１からＨ２３のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｈ２８）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｈ１からＨ２３のいずれか１つに記載の方法を実行するための手段を含む。

（Ｈ２９）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４８０１、図４８）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４８０３、図４８）と、処理ユニット（例えば、処理ユニット４８０５、図４８）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４８は、電子デバイス４８００に一体化されているとしてディスプレイユニット４８０１及びタッチ感知面ユニット４８０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、音声通信受信ユニット（例えば、音声通信受信ユニット４８０７、図４８）と、コンテンツアイテム抽出ユニット（例えば、コンテンツアイテム抽出ユニット４８０９、図４８）と、利用可能性判定ユニット（例えば、利用可能性判定ユニット４８１１、図４８）と、アプリケーション特定ユニット（例えば、アプリケーション特定ユニット４８１３、図４８）と、表示ユニット（例えば、表示ユニット４８１５、図４８）と、コンテンツアイテム記憶ユニット（例えば、コンテンツアイテム記憶ユニット４８１７、図４８）と、フィードバック提供ユニット（例えば、フィードバック提供ユニット４８１９、図４８）と、入力検出ユニット（例えば、入力検出ユニット４８２１、図４８）と、アプリケーションオープンユニット（例えば、アプリケーションオープンユニット４８２３、図４８）と、ポピュレーティングユニット（例えば、ポピュレーティングユニット４８２５、図４８）と、音声通信分析ユニット（例えば、音声通信分析ユニット４８２７、図４８）と、を含む。処理ユニット（又はユニット４８０７から４８２７などのその１つ以上の構成要素）は、音声通信の少なくとも一部を受信する（例えば、音声通信受信ユニット４８０７によって）ように構成されており、音声通信の一部は、電子デバイスのユーザとは異なるリモートデバイスのリモートユーザによって提供されるスピーチを含む。処理ユニットは、コンテンツアイテムを、少なくとも一部、リモートデバイスのリモートユーザによって提供されるスピーチに基づいて抽出し（例えば、コンテンツアイテム抽出ユニット４８０９によって）、このコンテンツアイテムが電子デバイス上で現在利用可能であるかどうかを判定する（例えば、利用可能性判定ユニット４８１１によって）ように更に構成されている。コンテンツアイテムが電子デバイス上で現在利用可能でないという判定に従って、処理ユニットは、（ｉ）コンテンツアイテムと関連付けられたアプリケーションを特定し（例えば、アプリケーション特定ユニット４８１３によって）、（ｉｉ）コンテンツアイテムの選択可能な説明をディスプレイ上に表示させる（例えば、表示ユニット４８１５及び／又はディスプレイユニット４８０１によって）ように更に構成されている。選択可能な説明の選択の検出（例えば、入力検出ユニット４８２１及び／又はタッチ感知面ユニット４８０３によって）に応じて、処理ユニットは、コンテンツアイテムを、特定されたアプリケーションで提示するために記憶する（例えば、コンテンツアイテム記憶ユニット４８１７によって）ように構成されている。

（Ｈ３０）Ｈ２９に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット４９０７から４９２７などのその１つ以上の構成要素）は、Ｈ２からＨ２３のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｉ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、音声通信の少なくとも一部を受信することを含み、音声通信の一部（例えば、生通話、録音済みボイスメール）は、電子デバイスのユーザとは異なるリモートデバイスのリモートユーザによって提供されるスピーチを含む。当該方法は、また、音声通信が物理的位置を特定するスピーチを含むと判定することを含む。当該方法は、音声通信が物理的位置を特定するスピーチを含むと判定したことに応じて、物理的位置に関する情報が検出されたというインジケーションを提供すること（例えば、ユーザに触覚フィードバックを提供すること、ユーザインタフェースオブジェクトを物理的位置に関する情報と共に表示すること、又は物理的位置に関する情報を近くのデバイスに送信し、その近くのデバイスで表示させること）を含む。当該方法は、タッチ感知面を介して入力を検出することを更に含む。当該方法は、入力を検出したことに応じて、（ｉ）地理的位置データを受け付けるアプリケーションを開くことと、（ｉｉ）アプリケーションを、物理的位置に関する情報でポピュレートすることと、を含む。このようにして、ユーザは、音声通信で言及された又は話された物理的位置に関する情報を記憶することができ、話された詳細の全てを憶え、後にこれら詳細を適切なアプリケーションで入力する必要はない。その代わり、電子デバイスが、物理的位置に関する情報を、物理的位置を説明する（例えば、レストラン、物理的位置への運転指示等の説明）スピーチに基づいて検出及び抽出し、その後、対応する物理的位置に関する情報が検出されたというインジケーションを提供することができる。

（Ｉ２）Ｉ１に記載の方法の一部の実施形態では、音声通信は生通話である。

（Ｉ３）Ｉ１に記載の方法の一部の実施形態では、音声通信は生ＦａｃｅＴｉｍｅ通話である。

（Ｉ４）Ｉ１に記載の方法の一部の実施形態では、音声通信は録音済みボイスメールである。

（Ｉ５）Ｉ１からＩ４のいずれか１つに記載の方法の一部の実施形態では、インジケーションを提供することは、ユーザインタフェース内に、電話アプリケーションを使用して行った最近の通話を含む物理的位置の選択可能な説明を表示することを含む。

（Ｉ６）Ｉ５に記載の方法の一部の実施形態では、選択可能な説明は、コンテンツアイテムが音声通信と関連付けられていることを示す。

（Ｉ７）Ｉ５又はＩ６に記載の方法の一部の実施形態では、入力を検出することは、最近の通話を含むユーザインタフェースが表示されている間に、選択可能な説明上における入力を検出することを含む。

（Ｉ８）Ｉ１からＩ７のいずれか１つに記載の方法の一部の実施形態では、インジケーションを提供することは、電子デバイスのユーザに触覚フィードバックを提供することを含む。

（Ｉ９）Ｉ１からＩ８のいずれか１つに記載の方法の一部の実施形態では、インジケーションを提供することは、電子デバイスの近傍にある異なる電子デバイスに物理的位置に関する情報を送信することを含む。

（Ｉ１０）Ｉ１からＩ９のいずれか１つに記載の方法の一部の実施形態では、音声通信が物理的位置を説明するスピーチを含むと判定することは、物理的位置に関する情報を検出するために音声通信の一部を分析することを含み、分析は、電子デバイスと通信しているオーディオシステムを介して音声通信を出力している間に実行される。

（Ｉ１１）Ｉ１からＩ１０のいずれか１つに記載の方法の一部の実施形態では、音声通信の少なくとも一部を受信することは、電子デバイスのユーザから、音声通信の一部が分析されるべきであるという命令を受信することを含む。

（Ｉ１２）Ｉ１１に記載の方法の一部の実施形態では、命令は、ハードウェアボタンの選択に対応する。一部の実施形態では、ボタンはまた、ユーザの選択用に電子デバイスのディスプレイ上に提示されるボタン（例えば、音声通信中に表示される、「ここをタップしてこの音声通信の新たなコンテンツを分析する」というボタン）であってもよい。

（Ｉ１３）Ｉ１１に記載の方法の一部の実施形態では、命令は、電子デバイスのユーザからの、「ヘイＳｉｒｉ（hey Siri）」という言葉を含むコマンドに対応する。

（Ｉ１４）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＩ１からＩ１３のいずれか１つに記載の方法を実行させる。

（Ｉ１５）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｉ１からＩ１３のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｉ１６）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＩ１からＩ１３のいずれか１つに記載の方法を実行させる。

（Ｉ１７）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｉ１からＩ１３のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｉ１８）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｉ１からＩ１３のいずれか１つに記載の方法を実行するための手段を含む。

（Ｉ１９）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット４９０１、図４９）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット４９０３、図４９）と、処理ユニット（例えば、処理ユニット４９０５、図４９）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図４９は、電子デバイス４９００に一体化されているとしてディスプレイユニット４９０１及びタッチ感知面ユニット４９０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、音声通信受信ユニット（例えば、音声通信受信ユニット４９０７、図４９）と、コンテンツアイテム抽出ユニット（例えば、コンテンツアイテム抽出ユニット４９０９、図４９）と、インジケーション提供ユニット（例えば、インジケーション提供ユニット４９１１、図４９）と、入力検出ユニット（例えば、入力検出ユニット４９１３、図４９）と、アプリケーションオープンユニット（例えば、アプリケーションオープンユニット４９１５、図４９）と、アプリケーションポピュレーティングユニット（例えば、アプリケーションポピュレーティングユニット４９１７、図４９）と、フィードバック提供ユニット（例えば、フィードバック提供ユニット４９１９、図４９）と、音声通信分析ユニット（例えば、音声通信分析ユニット４９２１、図４９）と、を含む。処理ユニット（又はユニット４９０７から４９２１などのその１つ以上の構成要素）は、音声通信の少なくとも一部を受信するように構成されており、音声通信の一部は、電子デバイスのユーザとは異なるリモートデバイスのリモートユーザによって提供される（例えば、音声通信受信ユニット４９０７によって）スピーチを含む。処理ユニットは、音声通信が物理的位置を特定するスピーチを含むと判定する（例えば、コンテンツアイテム抽出ユニット４９０９によって）ように更に構成されている。音声通信が物理的位置を特定するスピーチを含むと判定したことに応じて、処理ユニットは、物理的位置に関する情報が検出されたというインジケーションを提供する（例えば、コンテンツアイテム抽出ユニット４９０９によって）ように構成されている。処理ユニットはまた、タッチ感知面ユニットを介して入力を検出する（例えば、入力検出ユニット４９１１によって）ように構成されている。入力を検出したことに応じて、処理ユニットは、（ｉ）地理的位置データを受け付けるアプリケーションを開き（例えば、アプリケーションオープンユニット４９１３によって）、（ｉｉ）アプリケーションを、物理的位置に関する情報でポピュレートする（例えば、アプリケーションポピュレーティングユニット４９１５によって）ように構成されている。

（Ｉ２０）Ｉ１９に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット４９０７から４９２１などのその１つ以上の構成要素）は、Ｉ２からＩ１３のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｊ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、ディスプレイ上のメッセージアプリケーションにおいて、テキスト入力フィールド及び会話記録を提示することを含む。当該方法は、また、メッセージアプリケーションがディスプレイ上に提示されている間に、電子デバイスのユーザからの次の可能性のある入力が物理的位置に関する情報であると判定することを含む。当該方法は、テキスト入力フィールド及び会話記録と関連付けられたコンテンツを分析して、少なくとも一部、分析されたコンテンツの一部に基づいて、提案された物理的位置を判定することを更に含む。当該方法は、ディスプレイ上のメッセージアプリケーション内に、提案された物理的位置を特定する選択可能なユーザインタフェース要素を提示することと、選択可能なユーザインタフェース要素の選択を受信することと、を更に含む。当該方法は、選択を受信したことに応じて、テキスト入力フィールド内に、提案された物理的位置の表現を提示することを含む。このようにして、電子デバイスのユーザに対し、必要とするコンテンツが便利に提供され、ユーザは何もタイプする必要はなく、コンテンツを検索する必要はない（例えば、ユーザは選択可能なユーザインタフェース要素を選択するだけで自身の現在地を入力することができ、自身の正確な位置を明らかにするために地図アプリケーションにアクセスし、メッセージアプリケーションに戻り、位置情報を送信するために明示的な入力を行う必要はない）。

（Ｊ２）Ｊ１に記載の方法の一部の実施形態では、メッセージアプリケーションはバーチャルキーボードを含み、選択可能なユーザインタフェース要素は、バーチャルキーボードに隣接しかつバーチャルキーボードの上にある提案部分に表示される。

（Ｊ３）Ｊ１又はＪ２に記載の方法の一部の実施形態では、電子デバイスのユーザからの次の可能性のある入力が物理的位置に関する情報であると判定することは、会話トランスクリプションがユーザの現在位置に関する質問を含むことを検出するために、テキスト入力フィールド及び会話記録と関連付けられたコンテンツを処理することを含む。このようにして、ユーザに対し、会話トランスクリプション内の説明に直接関連する、提案された物理的位置が提供される（例えば、「どこにいますか」という第２のユーザの質問に応じて、ユーザに、選択されるとデバイスにユーザの現在位置に関する情報を第２のユーザに送信させるユーザインタフェースオブジェクトが提示される）。

（Ｊ４）Ｊ３に記載の方法の一部の実施形態では、コンテンツを処理することは、質問（例えば、「どこにいますか」又は「あなたの住所はどこですか」）を形成する１つ以上の定義済みのキーワードを検出するために自然言語処理アルゴリズムを適用することを含む。

（Ｊ５）Ｊ３又はＪ４に記載の方法の一部の実施形態では、質問は、ユーザとは異なる第２のユーザから受信するメッセージに含まれる。

（Ｊ６）Ｊ１からＪ５のいずれか１つに記載の方法の一部の実施形態では、電子デバイスのユーザからの次の可能性のある入力が物理的位置に関する情報であると判定することは、メッセージアプリケーションのテキスト入力部分においてユーザから受けるタイピング入力を監視することを含む。

（Ｊ７）Ｊ１からＪ６のいずれか１つに記載の方法の一部の実施形態では、当該方法は、ユーザがタイピングしており、かつ選択可能なユーザインタフェース要素を選択していないという判定に従って、選択可能なユーザインタフェース要素の提示を停止することを更に含む。このようにして、ユーザがオブジェクトの選択に関心がないと判定され得る場合、デバイスは、選択可能なユーザインタフェースオブジェクトを提示し続けることはない。

（Ｊ８）Ｊ１からＪ７のいずれか１つに記載の方法の一部の実施形態では、当該方法は、ユーザが選択可能なユーザインタフェース要素を選択しないことを示す追加の入力をユーザが提供したという判定に従って、選択可能なユーザインタフェース要素の提示を停止することを更に含む。このようにして、ユーザがオブジェクトの選択に関心がないと判定され得る場合、デバイスは、選択可能なユーザインタフェースオブジェクトを提示し続けることはない。

（Ｊ９）Ｊ１からＪ５のいずれか１つに記載の方法の一部の実施形態では、提案された物理的位置の表現は、電子デバイスの現在の地理的位置を特定する情報を含む。

（Ｊ１０）Ｊ１からＪ９のいずれか１つに記載の方法の一部の実施形態では、提案された物理的位置の表現は住所である。

（Ｊ１１）Ｊ１からＪ９のいずれか１つに記載の方法の一部の実施形態では、提案された物理的位置は提案された物理的位置に関する識別子を含む地図オブジェクトである。

（Ｊ１２）Ｊ１からＪ１１のいずれか１つに記載の方法の一部の実施形態では、提案された物理的位置は、メッセージアプリケーション以外のアプリケーションにおいてユーザが最近閲覧した位置に対応する。

（Ｊ１３）Ｊ１からＪ１２のいずれか１つに記載の方法の一部の実施形態では、メッセージアプリケーションは電子メールアプリケーションである。

（Ｊ１４）Ｊ１からＪ１２のいずれか１つに記載の方法の一部の実施形態では、メッセージアプリケーションはテキストメッセージアプリケーションである。

（Ｊ１５）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＪ１からＪ１４のいずれか１つに記載の方法を実行させる。

（Ｊ１６）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｊ１からＪ１４のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｊ１７）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＪ１からＪ１４のいずれか１つに記載の方法を実行させる。

（Ｊ１８）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｊ１からＪ１４のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｊ１９）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｊ１からＪ１４のいずれか１つに記載の方法を実行するための手段を含む。

（Ｊ２０）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット５００１、図５０）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット５００３、図５０）と、処理ユニット（例えば、処理ユニット５００５、図５０）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図５０は、電子デバイス５０００に一体化されているとしてディスプレイユニット５００１及びタッチ感知面ユニット５００３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、提示ユニット（例えば、提示ユニット５００７、図５０）と、次の入力判定ユニット（例えば、次の入力判定ユニット５００９、図５０）と、コンテンツ分析ユニット（例えば、コンテンツ分析ユニット５０１１、図５０）と、選択受信ユニット（例えば、選択受信ユニット５０１３、図５０）と、タイピング入力監視ユニット（例えば、タイピング入力監視ユニット５０１５、図５０）と、提示終了ユニット（例えば、提示終了ユニット５０１７、図５０）と、を含む。処理ユニット（又はユニット５００７から５０１７などのその１つ以上の構成要素）は、ディスプレイ上のメッセージアプリケーションにおいて、テキスト入力フィールド及び会話記録を提示する（例えば、提示ユニット５００７及び／又はディスプレイユニット５００１によって）ように構成されている。メッセージアプリケーションがディスプレイ上に提示されている間に、処理ユニットはまた、電子デバイスのユーザからの次の可能性のある入力が物理的位置に関する情報であると判定する（例えば、次の入力判定ユニット５００９によって）ように構成されている。処理ユニットは、テキスト入力フィールド及び会話記録と関連付けられたコンテンツを分析して、少なくとも一部、分析されたコンテンツの一部に基づいて、提案された物理的位置を判定し（例えば、コンテンツ分析ユニット５０１１によって）、ディスプレイ上のメッセージアプリケーション内に、提案された物理的位置を特定する選択可能なユーザインタフェース要素を提示し（例えば、提示ユニット５００７によって）、選択可能なユーザインタフェース要素の選択を受信し（例えば、選択受信ユニット５０１３及び／又はタッチ感知面ユニット５００３によって）、選択を受信したことに応じて、テキスト入力フィールド内に、提案された物理的位置の表現を提示する（例えば、提示ユニット５００７によって）ように更に構成されている。

（Ｊ２１）Ｊ２０に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット５００７から５０１７などのその１つ以上の構成要素）は、Ｊ２からＪ１４のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｋ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、第１のアプリケーションを表示している間に、第１のアプリケーションでユーザが閲覧した第１の物理的位置（例えば、地元企業の検索を可能にするアプリケーションでユーザが検索したレストラン）を特定する情報を取得することを含む。当該方法は、また、第１のアプリケーションを終了することと、第１のアプリケーションの終了後、ユーザから、第１のアプリケーションとは異なる第２のアプリケーションを開くことの要求を受信することと、を含む。一部の実施形態では、要求は、第１のアプリケーションにおいて何ら入力を受信することなく受信される（例えば、要求は、第１のアプリケーション内のリンク又はボタンをクリックすることを含んでいない）。要求の受信に応じて、かつ第２のアプリケーションが地理的位置情報を受け付けることができるという判定に従って、当該方法は、第２のアプリケーションを提示することを含み、第２のアプリケーションを提示することは、第２のアプリケーションを、少なくとも一部、第１の物理的位置を特定する情報に基づく情報でポピュレートすることを含む。このようにして、ユーザが、情報を２つの異なるアプリケーション間において手動で移す必要はない。その代わり、デバイスが、第２のアプリケーションが地理的位置情報を受け付けることができることを知的に判定し、次いで、第１のアプリケーションで閲覧した物理的位置に関する情報を直接第２のアプリケーションをポピュレートする（例えば、物理的位置に関する識別子を含むように地図オブジェクトを第２のアプリケーションをポピュレートする）。

（Ｋ２）Ｋ１に記載の方法の一部の実施形態では、第２のアプリケーションを開くことの要求を受信することは、第１のアプリケーションの終了後、第２のアプリケーションのアフォーダンス上において入力を検出することを含む。換言すると、要求は、第１のアプリケーション内のリンクをクリックすることに対応せず、その代わり、ユーザが第２のアプリケーションを開くことを明示的かつ直接的に要求し、次いで、デバイスが、第２のアプリケーションを、ユーザがこの、前に閲覧した物理的位置を第２のアプリケーションで更に調査又は検討することができるように、前に閲覧した（異なる第１のアプリケーションで前に閲覧した）物理的位置に関する情報でポピュレートすることを決定する。

（Ｋ３）Ｋ２に記載の方法の一部の実施形態では、第２のアプリケーションのアフォーダンスは、電子デバイスのホームスクリーン内に表示されるアイコンである。一部の実施形態では、ホームスクリーンはオペレーティングシステムのシステムレベルコンポーネントであり、電子デバイス上で利用可能なアプリケーションを呼び出すためのアイコンを含む。

（Ｋ４）Ｋ２に記載の方法の一部の実施形態では、入力を検出することは、（ｉ）物理的なホームボタンにおけるダブルタップを検出することと、（ｉｉ）ダブルタップを検出したことに応じて、アプリケーション切替ユーザインタフェースを表示することと、（ｉｉｉ）アプリケーション切替ユーザインタフェース内からのアフォーダンスの選択を検出することと、を含む。

（Ｋ５）Ｋ１からＫ４のいずれか１つに記載の方法の一部の実施形態では、第２のアプリケーションをポピュレートすることは、少なくとも一部、第１の物理的位置を特定する情報に基づく情報を含むユーザインタフェースオブジェクトを表示することを含む。

（Ｋ６）Ｋ５に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、第１のアプリケーションにおいて第１の物理的位置を最近閲覧したことをユーザに知らせるテキストでの説明を含む。

（Ｋ７）Ｋ６に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは第２のアプリケーション内に表示される地図であり、第２のアプリケーションをポピュレートすることは、第１の物理的位置の識別子を含むように地図をポピュレートすることを含む。

（Ｋ８）Ｋ６又はＫ７に記載の方法の一部の実施形態では、第２のアプリケーションはバーチャルキーボードと共に提示され、ユーザインタフェースオブジェクトはバーチャルキーボードの上方に表示される。

（Ｋ９）Ｋ６からＫ８のいずれか１つに記載の方法の一部の実施形態では、情報を取得することは、第２の物理的位置に関する情報を取得することを含み、ユーザインタフェースオブジェクトを表示することは、第２の物理的位置に関する情報を有するユーザインタフェースオブジェクトを表示することを含む。

（Ｋ１０）Ｋ１からＫ９のいずれか１つに記載の方法の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができるという判定は、（ｉ）第２のアプリケーションが、地理的位置データを受け付け、処理することができる入力受け取りフィールドを含むと判定すること、（ｉｉ）第２のアプリケーションが地図上に地理的位置情報を表示することができると判定すること、（ｉｉｉ）第２のアプリケーションが、経路案内を容易にするために地理的位置情報を使用できると判定すること、及び（ｉｖ）第２のアプリケーションが、輸送サービスを位置特定し、提供するために地理的位置情報を使用できると判定することの１つ以上を含む。

（Ｋ１１）Ｋ１０に記載の方法の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができるという判定は、第２のアプリケーションが、地理的位置データを受け付け、処理することができる入力受け取りフィールドを含むと判定することを含み、入力受け取りフィールドは、第２のアプリケーション内に表示される地図内での検索を可能にする検索ボックスである。

（Ｋ１２）Ｋ１からＫ１１のいずれか１つに記載の方法の一部の実施形態では、当該方法は、要求の受信に応じて、ユーザのアプリケーション利用履歴に基づいて、第２のアプリケーションが第１のアプリケーションと関連付けられている（例えば、第１のアプリケーションを開いた後、閾値回数開かれた）かどうかを判定することを更に含む。

（Ｋ１３）Ｋ１２に記載の方法の一部の実施形態では、当該方法は、第２のアプリケーションを提示する前に、第２のアプリケーションに対し、第１の物理的位置を特定する情報へのアクセスを提供することを更に含み、アクセスが提供される前、第２のアプリケーションは第１の物理的位置を特定する情報へのアクセスを有しない。このようにして、第２のアプリケーションは、第１のアプリケーションにおいてユーザが行ったアクションに関する情報を受信することができ、その後、ユーザに、この情報を第２のアプリケーション内で使用する手法が提供される（例えば、第１の物理的位置に関する更なる情報を検索するために、又は第１の物理的位置を、第２のアプリケーションを通じて利用可能な、ライドシェアサービスなどの何らかのサービスに使用するために）。

（Ｋ１４）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＫ１からＫ１３のいずれか１つに記載の方法を実行させる。

（Ｋ１５）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｋ１からＫ１３のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｋ１６）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＫ１からＫ１３のいずれか１つに記載の方法を実行させる。

（Ｋ１７）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｋ１からＫ１３のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｋ１８）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｋ１からＫ１３のいずれか１つに記載の方法を実行するための手段を含む。

（Ｋ１９）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット５１０１、図５１）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット５１０３、図５１）と、処理ユニット（例えば、処理ユニット５１０５、図５１）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図５１は、電子デバイス５１００に一体化されているとしてディスプレイユニット５１０１及びタッチ感知面ユニット５１０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、情報取得ユニット（例えば、情報取得ユニット５１０７、図５１）と、アプリケーション終了ユニット（例えば、アプリケーション終了ユニット５１０９、図５１）と、要求受信ユニット（例えば、要求受信ユニット５１１１、図５１）と、アプリケーション性能判定ユニット（例えば、アプリケーション性能判定ユニット５１１３、図５１）と、アプリケーション提示ユニット（例えば、アプリケーション提示ユニット５１１５、図５１）と、アプリケーションポピュレーティングユニット（例えば、アプリケーションポピュレーティングユニット５１１７、図５１）と、入力検出ユニット（例えば、入力検出ユニット５１１９、図５１）と、アプリケーション切替ユーザインタフェース表示ユニット（例えば、アプリケーション切替ユーザインタフェース表示ユニット５１２１、図５１）と、アプリケーション関連付け判定ユニット（例えば、アプリケーション関連付け判定ユニット５１２３、図５１）と、アクセス提供ユニット（例えば、アクセス提供ユニット５１２５、図５１）と、を含む。処理ユニット（又はユニット５１０７から５１２５などのその１つ以上の構成要素）は、第１のアプリケーションを表示している間に、第１のアプリケーションでユーザが閲覧した第１の物理的位置を特定する情報を取得する（例えば、情報取得ユニット５１０７によって）ように構成されている。処理ユニットはまた、第１のアプリケーションを終了し（例えば、アプリケーション終了ユニット５１０９によって）、第１のアプリケーションの終了後、ユーザから、第１のアプリケーションとは異なる第２のアプリケーションを開くことの要求を受信する（例えば、要求受信ユニット５１１１によって）ように構成されている。要求の受信に応じて、かつ第２のアプリケーションが地理的位置情報を受け付けることができるという判定（例えば、アプリケーション性能判定ユニット５１１３により処理又は実行される判定）に従って、第２のアプリケーションを提示し（例えば、アプリケーション提示ユニット５１１５によって）、第２のアプリケーションを提示することは、第２のアプリケーションを、少なくとも一部、第１の物理的位置を特定する情報に基づく情報でポピュレートすることを含む（例えば、アプリケーションポピュレーティングユニット５１１７によって）。

（Ｋ２０）Ｋ１９に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット５１０７から５１２５などのその１つ以上の構成要素）は、Ｋ２からＫ１３のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｌ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、第１のアプリケーションにおいてユーザが閲覧した第１の物理的位置を特定する情報を取得し、第１の入力を検出することを含む。当該方法は、第１の入力を検出したことに応じて、（ｉ）地理的位置情報を受け付けることができる第２のアプリケーションを特定することと、（ｉｉ）ディスプレイの少なくとも一部分上に、第１のアプリケーションとは異なる、第１の物理的位置に関する情報を有する第２のアプリケーションを開く提案を有するアフォーダンスを提示することと、を含む。当該方法は、また、アフォーダンスにおいて第２の入力を検出することを含む。アフォーダンスにおいて第２の入力を検出したことに応じて、（ｉ）第２のアプリケーションを開くことと、（ｉｉ）少なくとも一部、第１の物理的位置を特定する情報に基づく情報を含むように、第２のアプリケーションをポピュレートすることと。

上記Ｋ１に関連する操作と比較して、Ｌ１に関連する操作では、第１の物理的位置に関する情報を有する第２のアプリケーションを開く提案をユーザに提供する前には、第２のアプリケーションを開くための特定の要求をユーザから受信しない。このようにして、上記Ｋ１及びＬ１の両方（並びにこれら方法それぞれのいくつかの処理工程を使用するこれらの組み合わせ）に関連する操作を提供することにより、電子デバイスは、地理的位置情報を受け付けることができるアプリケーションをユーザが開く前又は後のいずれかにおいて位置データを予測的に使用することを可能にする効率的なユーザ経験を提供することができる。加えて、Ｌ１によって、第２のアプリケーションが地理的位置情報を受け付けることができるという判定が第２のアプリケーションを開く前でも行われ、このようにして、入力がアプリケーション切替ユーザインタフェースを開くことの要求に対応するＬ１の実施形態では、アプリケーション切替ユーザインタフェースは、アプリケーションが位置データを受け付けることができることが既知である場合、第１の物理的位置に関する情報を有するアプリケーション（例えば、第２のアプリケーション）を開く提案を単に表示する。

（Ｌ２）Ｌ１に記載の方法の一部の実施形態では、第１の入力は、アプリケーション切替ユーザインタフェースを開くことの要求に対応する（例えば、第１の入力は電子デバイスの物理的なホームボタン上のダブルタップである）。

（Ｌ３）Ｌ２に記載の方法の一部の実施形態では、アフォーダンスはアプリケーション切替ユーザインタフェース内に提示される。

（Ｌ４）Ｌ３に記載の方法の一部の実施形態では、アフォーダンスを提示することは、アフォーダンスを提示することと併せて、アプリケーション切替ユーザインタフェース内に、電子デバイス上で実行されているアプリケーションの表現（例えば、アプリケーションのアプリケーションコンテンツのスナップショット）を提示することと、アプリケーションの表現の下方に位置するディスプレイの領域内にアフォーダンスを提示することと、を含む。

（Ｌ５）Ｌ１に記載の方法の一部の実施形態では、第１の入力は、電子デバイスのホームスクリーンを開くことの要求に対応する（例えば、第１の入力は電子デバイスの物理的なホームボタン上のシングルタップである）。

（Ｌ６）Ｌ５に記載の方法の一部の実施形態では、アフォーダンスは、ホームスクリーンの一部分上に提示される。

（Ｌ７）Ｌ１からＬ６のいずれか１つに記載の方法の一部の実施形態では、提案は、第２のアプリケーションと関連付けられた種類に固有のテキストでの説明を含む。

（Ｌ８）Ｌ１からＬ７のいずれか１つに記載の方法の一部の実施形態では、第２のアプリケーションをポピュレートすることは、少なくとも一部、第１の物理的位置を特定する情報に基づく情報を含むユーザインタフェースオブジェクトを表示することを含む。

（Ｌ９）Ｌ８に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは、第１のアプリケーションにおいて第１の物理的位置を最近閲覧したことをユーザに知らせるテキストでの説明を含む。

（Ｌ１０）Ｌ９に記載の方法の一部の実施形態では、ユーザインタフェースオブジェクトは第２のアプリケーション内に表示される地図であり、第２のアプリケーションをポピュレートすることは、第１の物理的位置の識別子を含むように地図をポピュレートすることを含む。

（Ｌ１１）Ｌ９又はＬ１０に記載の方法の一部の実施形態では、第２のアプリケーションはバーチャルキーボードと共に提示され、ユーザインタフェースオブジェクトはバーチャルキーボードの上方に表示される。

（Ｌ１２）Ｌ１からＬ１１のいずれか１つに記載の方法の一部の実施形態では、地理的位置情報を受け付けることができる第２のアプリケーションを特定することは、（ｉ）第２のアプリケーションが、地理的位置データを受け付け、処理することができる入力受け取りフィールドを含むと判定すること、（ｉｉ）第２のアプリケーションが地図上に地理的位置情報を表示することができると判定すること、（ｉｉｉ）第２のアプリケーションが、経路案内を容易にするために地理的位置情報を使用できると判定すること、及び（ｉｖ）第２のアプリケーションが、輸送サービスを位置特定し、提供するために地理的位置情報を使用できると判定すること、の１つ以上を含む。

（Ｌ１３）Ｌ１２に記載の方法の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができることを特定することは、第２のアプリケーションが、地理的位置データを受け付け、処理することができる入力受け取りフィールドを含むと判定することを含み、入力受け取りフィールドは、第２のアプリケーション内に表示される地図内での検索を可能にする検索ボックスである。

（Ｌ１４）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＬ１からＬ１３のいずれか１つに記載の方法を実行させる。

（Ｌ１５）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｌ１からＬ１３のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｌ１６）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＬ１からＬ１３のいずれか１つに記載の方法を実行させる。

（Ｌ１７）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｌ１からＬ１３のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｌ１８）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｌ１からＬ１３のいずれか１つに記載の方法を実行するための手段を含む。

（Ｌ１９）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット５２０１、図５２）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット５２０３、図５２）と、処理ユニット（例えば、処理ユニット５２０５、図５２）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図５２は、電子デバイス５２００に一体化されているとしてディスプレイユニット５２０１及びタッチ感知面ユニット５２０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、情報取得ユニット（例えば、情報取得ユニット５２０７、図５２）と、入力検出ユニット（例えば、入力検出ユニット５２０９、図５２）と、アプリケーション特定ユニット（例えば、アプリケーション特定ユニット５２１１、図５２）と、アフォーダンス提示ユニット（例えば、アフォーダンス提示ユニット５２１３、図５２）と、アプリケーションオープンユニット（例えば、アプリケーションオープンユニット５２１５、図５２）と、アプリケーションポピュレーティングユニット（例えば、アプリケーションポピュレーティングユニット５２１７、図５２）と、アプリケーション切替ユーザインタフェース提示ユニット（例えば、アプリケーション切替ユーザインタフェース提示ユニット５２１９、図５２）と、アプリケーション性能判定ユニット（例えば、アプリケーション性能判定ユニット５２２１、図５２）と、を含む。処理ユニット（又はユニット５２０７から５２２１などのその１つ以上の構成要素）は、第１のアプリケーションにおいてユーザが閲覧した第１の物理的位置を特定する情報を取得し（例えば、情報取得ユニット５２０７によって）、第１の入力を検出する（例えば、入力検出ユニット５２０９によって）ように構成されている。第１の入力を検出したことに応じて、処理ユニットは、（ｉ）地理的位置情報を受け付けることができる第２のアプリケーションを特定し（例えば、アプリケーション特定ユニット５２０９によって）、（ｉｉ）ディスプレイの少なくとも一部分上に、第１のアプリケーションとは異なる、第１の物理的位置に関する情報を有する第２のアプリケーションを開く提案を有するアフォーダンスを提示する（例えば、アフォーダンス提示ユニット５２１３によって）ように構成されている。処理ユニットはまた、アフォーダンスにおいて第２の入力を検出する（例えば、入力検出ユニット５２０９によって）ように構成されている。アフォーダンスにおいて第２の入力を検出したことに応じて、処理ユニットは、（ｉ）第２のアプリケーションを開き（例えば、アプリケーションオープンユニット５２１５によって）、（ｉｉ）少なくとも一部、第１の物理的位置を特定する情報に基づく情報を含むように、第２のアプリケーションをポピュレートする（例えば、アプリケーションポピュレーティングユニット５２１７によって）ように構成されている。

（Ｌ２０）Ｌ１９に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット５２０７から５２２１などのその１つ以上の構成要素）は、Ｌ２からＬ１３のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｍ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、電子デバイス上で実行されている第１のアプリケーションにおいてユーザが閲覧した第１の物理的位置を特定する情報を取得することを含む。当該方法は、また、ユーザが車両に入ったと判定することを含む。ユーザが車両に入ったと判定したことに応じて、ユーザに対し、第１の物理的位置を経路案内の目的地として使用するというプロンプトを提供する。当該方法は、プロンプトの提供に応じて、ユーザから、第１の物理的位置を経路案内の目的地として使用する命令を受信することを含む。当該方法は、第１の物理的位置への経路案内を容易にすることを更に含む。このようにして、ユーザに、電子デバイス上のアプリケーションで以前見ていた物理的位置に基づいて、目的地の経路設定の提案が便利に提供される。

（Ｍ２）Ｍ１に記載の方法の一部の実施形態では、当該方法は、メッセージが第２の物理的位置を特定する情報を含むことを検出することを含む、電子デバイスがメッセージを受信したことを検出することと、検出したことに応じて、ユーザに対し、第２の物理的位置を経路案内の新たな目的地として使用するという新たなプロンプトを提供することと、を更に含む。このようにして、メッセージ（例えば、テキスト、電子メール、ボイスメール等）に含まれる情報に基づいて、ユーザは動的に、中間地点を追加する又は経路案内の新たな目的地を追加することができる。

（Ｍ３）Ｍ２に記載の方法の一部の実施形態では、当該方法は、ユーザから、第２の物理的位置を新たな目的地として使用する命令を受信したことに応じて、第２の物理的位置への経路案内を容易にすることを更に含む。

（Ｍ４）Ｍ２又はＭ３に記載の方法の一部の実施形態では、メッセージが第２の物理的位置を特定する情報を含むことを検出することは、電子デバイス上で利用可能なバーチャルアシスタントが、電子デバイスと通信しているオーディオシステムを介してユーザに対しメッセージを読み上げている間、検出を実行することを含む。このようにして、オーディオシステムにより（例えば、電子デバイスを介して利用可能なパーソナルアシスタントを介して）読み上げられるメッセージをユーザが聞いているとき、電子デバイスは第２の物理的位置を特定する情報を検出し、この検出された情報を使用して、第２の物理的位置を新たな目的地として使用することを提案する。したがって、ユーザは運転中に道路から注意をそらす必要がなく、それでも、経路案内の設定及び目的地を動的に調整することができる。

（Ｍ５）Ｍ２からＭ４のいずれか１つに記載の方法の一部の実施形態では、ユーザが車両に入ったと判定することは、電子デバイスが車両との通信リンクを確立したことを検出することを含む。

（Ｍ６）Ｍ２からＭ５のいずれか１つに記載の方法の一部の実施形態では、経路案内を容易にすることは、電子デバイスのディスプレイを介して経路案内を提供することを含む。

（Ｍ７）Ｍ２からＭ５のいずれか１つに記載の方法の一部の実施形態では、経路案内を容易にすることは、車両に、第１の物理的位置を特定する情報を送信することを含む。

（Ｍ８）Ｍ２からＭ７のいずれか１つに記載の方法の一部の実施形態では、経路案内を容易にすることは、電子デバイスと通信しているオーディオシステム（例えば、車のスピーカ又はデバイス自身の内蔵スピーカ）によって経路案内を提供することを含む。

（Ｍ９）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＭ１からＭ８のいずれか１つに記載の方法を実行させる。

（Ｍ１０）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｍ１からＭ８のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｍ１１）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＭ１からＭ８のいずれか１つに記載の方法を実行させる。

（Ｍ１２）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｍ１からＭ８のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｍ１３）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｍ１からＭ８のいずれか１つに記載の方法を実行するための手段を含む。

（Ｍ１４）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット５３０１、図５３）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット５３０３、図５３）と、処理ユニット（例えば、処理ユニット５３０５、図５３）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図５３は、電子デバイス５３００に一体化されているとしてディスプレイユニット５３０１及びタッチ感知面ユニット５３０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、情報取得ユニット（例えば、情報取得ユニット５３０７、図５３）と、車両エントリ判定ユニット（例えば、車両エントリ判定ユニット５３０９、図５３）と、プロンプト提供ユニット（例えば、プロンプト提供ユニット５３１１、図５３）と、命令受信ユニット（例えば、命令受信ユニット５３１３、図５３）と、経路案内容易化ユニット（例えば、経路案内容易化ユニット５３１５、図５３）と、メッセージ検出ユニット（例えば、メッセージ検出ユニット５３１７、図５３）と、を含む。処理ユニット（又はユニット５３０７から５３１７などのその１つ以上の構成要素）は、電子デバイス上で実行されている第１のアプリケーションにおいてユーザが閲覧した第１の物理的位置を特定する情報を取得する（例えば、情報取得ユニット５３０７によって）ように構成されている。処理ユニットはまた、ユーザが車両に入ったと判定する（例えば、車両エントリ判定ユニット５３０９によって）ように構成されている。ユーザが車両に入ったと判定したことに応じて、処理ユニットは、ユーザに対し、第１の物理的位置を経路案内の目的地として使用するというプロンプトを提供する（例えば、プロンプト提供ユニット５３１１によって）ように構成されている。プロンプトの提供に応じて、ユーザから、第１の物理的位置を経路案内の目的地として使用する命令を受信する（例えば、命令受信ユニット５３１３によって）。処理ユニットは、第１の物理的位置への経路案内を容易にする（例えば、経路案内容易化ユニット５３０７によって）ように更に構成されている。

（Ｍ１５）Ｍ１４に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット５３０７から５３１７などのその１つ以上の構成要素）はに、Ｍ２からＭ８のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｎ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、第１のアプリケーションにおいてコンテンツを提示することを含む。当該方法は、また、ユーザから、第１のアプリケーションとは異なる第２のアプリケーションを開くことの要求を受信することを含み、第２のアプリケーションは入力受け取りフィールドを含む。当該方法は、要求の受信に応じて、第２のアプリケーションに入力受け取りフィールドを提示することを含む。当該方法は、入力受け取りフィールドにおいて何らかのユーザ入力を受信する前に、ユーザがコンテンツの少なくとも一部を入力受け取りフィールドに貼り付けることを可能とするための選択可能なユーザインタフェースオブジェクトを提供することを含む。当該方法は、選択可能なユーザインタフェースオブジェクトの選択を検出したことに応じて、コンテンツの一部を入力受け取りフィールドに貼り付けることを含む。このようにして、ユーザに対し、第１のアクションで前に閲覧した第２のアプリケーションベースのコンテンツにおいて先見的な貼り付けアクションが提供される（例えば、これにより、ユーザが、第１のアプリケーションを再度開き、明示的なコピーアクションを実行し、第２のアプリケーションを再度開き、その後、コピーされたコンテンツを第２のアプリケーションに貼り付けることを明示的に要求する必要なく、コンテンツを第２のアプリケーションに貼り付けることを可能にする）。

（Ｎ２）Ｎ１に記載の方法の一部の実施形態によれば、当該方法は、選択可能なユーザインタフェースオブジェクトを提供する前に、入力受け取りフィールドを、コンテンツの一部を受け付けることができるフィールドとして特定することを含む。

（Ｎ３）Ｎ２に記載の方法の一部の実施形態によれば、入力受け取りフィールドを、コンテンツの一部を受け付けることができるフィールドとして特定することは、入力受け取りフィールドの選択を検出に応じて実行される。

（Ｎ４）Ｎ１からＮ３のいずれか１つに記載の方法の一部の実施形態によれば、コンテンツの一部は画像に対応する。

（Ｎ５）Ｎ１からＮ３のいずれか１つに記載の方法の一部の実施形態によれば、コンテンツの一部はテキストコンテンツに対応する。

（Ｎ６）Ｎ１からＮ３のいずれか１つに記載の方法の一部の実施形態によれば、コンテンツの一部はテキストコンテンツ及び画像に対応する。

（Ｎ７）Ｎ１からＮ６のいずれか１つに記載の方法の一部の実施形態によれば、第１のアプリケーションはウェブブラウズアプリケーションであり、第２のアプリケーションはメッセージアプリケーションである。

（Ｎ８）Ｎ１からＮ６のいずれか１つに記載の方法の一部の実施形態によれば、第１のアプリケーションは写真ブラウズアプリケーションであり、第２のアプリケーションはメッセージアプリケーションである。

（Ｎ９）Ｎ１からＮ８のいずれか１つに記載の方法の一部の実施形態によれば、当該方法は、第２のアプリケーションを開くことの要求を受信する前に、コンテンツの少なくとも一部をコピーすることの要求を受信することを含む。

（Ｎ１０）Ｎ１からＮ９のいずれか１つに記載の方法の一部の実施形態によれば、選択可能なユーザインタフェースオブジェクトは、コンテンツの一部を第１のアプリケーションにおいて最近閲覧したというインジケーションと共に表示される。このようにして、ユーザに、貼り付けの提案がなぜ行われたかに関する明確なインジケーションが提供される。

（Ｎ１１）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＮ１からＮ１０のいずれか１つに記載の方法を実行させる。

（Ｎ１２）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｎ１からＮ１０のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｎ１３）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＮ１からＮ１０のいずれか１つに記載の方法を実行させる。

（Ｎ１４）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｎ１からＮ１０のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｎ１５）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｎ１からＮ１０のいずれか１つに記載の方法を実行するための手段を含む。

（Ｎ１６）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット５４０１、図５４）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット５４０３、図５４）と、処理ユニット（例えば、処理ユニット５４０５、図５４）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図５４は、電子デバイス５４００に一体化されているとしてディスプレイユニット５４０１及びタッチ感知面ユニット５４０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、提示ユニット（例えば、提示ユニット５４０７、図５４）と、要求受信ユニット（例えば、要求受信ユニット５４０９、図５４）と、ユーザインタフェースオブジェクト提供ユニット（例えば、ユーザインタフェースオブジェクト提供ユニット５４１１、図５４）と、先見的な貼り付けユニット（例えば、先見的な貼り付けユニット５４１３、図５４）と、性能判定ユニット（例えば、性能判定ユニット５４１５、図５４）と、を含む。処理ユニット（又はユニット５４０７から５４１５などのその１つ以上の構成要素）は、第１のアプリケーションにおいてコンテンツを提示し（例えば、提示ユニット５４０７及び／又はディスプレイユニット５４０１によって）、ユーザから、第１のアプリケーションとは異なる第２のアプリケーションを開くことの要求を受信し（例えば、要求受信ユニット及び／又はタッチ感知面ユニット５４０３によって）、第２のアプリケーションは入力受け取りフィールドを含み、要求の受信に応じて、第２のアプリケーションに入力受け取りフィールドを提示し（例えば、提示ユニット５４０７及び／又はディスプレイユニット５４０１によって）、入力受け取りフィールドにおいて何らかのユーザ入力を受信する前に、ユーザがコンテンツの少なくとも一部を入力受け取りフィールドに貼り付けることを可能とするための選択可能なユーザインタフェースオブジェクトを提供し（例えば、ユーザインタフェースオブジェクト提供ユニット５４１１及び／又はディスプレイユニット５４０１によって）、選択可能なユーザインタフェースオブジェクトの選択を検出したことに応じて、コンテンツの一部を入力受け取りフィールドに貼り付ける（例えば、先見的な貼り付けユニット５４１３によって）ように構成されている。

（Ｎ１７）Ｎ１６に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット５４０７から５４１５などのその１つ以上の構成要素）は、Ｎ１からＮ１０のいずれか１つに記載の方法を実行するように更に構成されている。

（Ｏ１）一部の実施形態では、方法が、タッチ感知面及びディスプレイ（一部の実施形態では、タッチスクリーン１１２、図１Ｃにおいて示されるように、タッチ感知面とディスプレイとは一体化されている）を有する電子デバイス（例えば、コンピューティングデバイスＡからＤ（図１Ｅ）のいずれか１つに従って構成されたポータブル多機能デバイス１００（図１Ａ））において実行される。当該方法は、ディスプレイ上に、アプリケーションと関連付けられたテキストコンテンツを提示することを含む。当該方法は、また、テキストコンテンツの一部が（ｉ）位置、（ｉｉ）連絡先、又は（ｉｉｉ）イベントに関連すると判定することを含む。当該方法は、テキストコンテンツの一部が位置に関連すると判定すると、電子デバイス上の位置センサから位置情報を取得し、取得した位置情報を予測されたコンテンツアイテムとして表示するために準備することを含む。当該方法は、テキストコンテンツの一部が連絡先に関連すると判定すると、電子デバイス上で、テキストコンテンツの一部に関連する連絡先情報について検索を行うことと、検索により取り出した、少なくとも１つの連絡先と関連付けられた情報を、予測されたコンテンツアイテムとして表示するために準備することと、を含む。当該方法は、テキストコンテンツの一部がイベントに関連すると判定すると、電子デバイス上で、テキストコンテンツの一部に関連するイベント情報について新たな検索を行い、少なくとも一部、新たな検索により取り出した少なくとも１つのイベントに基づく情報を、予測されたコンテンツアイテムとして表示するために準備することを含む。当該方法は、アプリケーション内に、予測されたコンテンツアイテムを含むアフォーダンスを表示することと、タッチ感知面を介して、アフォーダンスの選択を検出することと、選択を検出したことに応じて、予測されたコンテンツアイテムと関連付けられた情報を、ディスプレイ上に、テキストコンテンツに隣接して表示することと、を更に含む。このようにして、ユーザに対し、文を完成する（又は例えば、メッセージアプリケーション内で他のユーザにより寄せられた質問に答える）ために使用できる予測されたコンテンツアイテムが便利に提供され、ユーザは何もタイプする必要はなく、所望の情報を捜すために電子デバイス上で利用可能な情報を調べる必要はない。例えば、電子デバイスは、電話番号、現在位置、新たなイベントをスケジューリングするための空き、現在のイベントに関連する詳細を全て、ユーザによる明示的な要求又は余計な労力を全く必要とすることなく提供するため、時間が節約される一方でなお、ユーザに所望の情報が効率的に提供されるようにする。

（Ｏ２）Ｏ１に記載の方法の一部の実施形態によれば、テキストコンテンツの一部は、アプリケーション内に最も最近提示されたテキストコンテンツに対応する。

（Ｏ３）Ｏ１又はＯ２に記載の方法の一部の実施形態によれば、アプリケーションはメッセージアプリケーションであり、テキストコンテンツの一部は、メッセージアプリケーション内で電子デバイスとは異なるリモートデバイスのリモートユーザから受信した質問である。

（Ｏ４）Ｏ１又はＯ２に記載の方法の一部の実施形態によれば、テキストコンテンツの一部は、アプリケーション内の入力受け取りフィールドにおいて電子デバイスのユーザにより提供される入力である。

（Ｏ５）Ｏ１に記載の方法の一部の実施形態によれば、テキストコンテンツの一部は、テキストコンテンツの一部を含むユーザインタフェースオブジェクトを選択するユーザ入力に応じて特定される。

（Ｏ６）Ｏ５に記載の方法の一部の実施形態によれば、アプリケーションはメッセージアプリケーションであり、ユーザインタフェースオブジェクトは、メッセージアプリケーション内に表示される会話におけるメッセージ用吹き出しである。

（Ｏ７）Ｏ５又はＯ６に記載の方法の一部の実施形態によれば、当該方法は、第２のユーザインタフェースオブジェクトの選択を検出することと、選択を検出したことに応じて、（ｉ）アフォーダンスを予測されたコンテンツアイテムと共に表示するのを停止し、第２のユーザインタフェースオブジェクトと関連付けられたテキストコンテンツが位置、連絡先、又はイベントに関連すると判定することと、判定に従って、アプリケーション内に新たな予測されたコンテンツアイテムを表示することと、を更に含む。このようにして、ユーザは容易にメッセージの会話に戻り、以前に受信したメッセージを選択することができると共に、なお、適切に予測されたコンテンツアイテムが提供され得る。

（Ｏ８）Ｏ１からＯ７のいずれか１つに記載の方法の一部の実施形態によれば、アフォーダンスは、アプリケーション内のバーチャルキーボードに隣接する入力受け取りフィールド内に表示される。

（Ｏ９）Ｏ８に記載の方法の一部の実施形態によれば、入力受け取りフィールドは、バーチャルキーボードにおいて受けたタイピング入力を表示するフィールドである。

（Ｏ１０）Ｏ１からＯ９のいずれか１つに記載の方法の一部の実施形態によれば、判定することは、テキストコンテンツをアプリケーションで受信した際にパースし、連絡先、イベント及び／又は位置に関連することが知られている記憶されたパターンを検出することを含む。

（Ｏ１１）別の態様では、電子デバイスが提供される。一部の実施形態では、電子デバイスは、タッチ感知面と、ディスプレイと、１つ以上のプロセッサと、１つ以上のプログラムを記憶するメモリと、を含み、１つ以上のプログラムが１つ以上のプロセッサによって実行されると、１つ以上のプログラムは、電子デバイスにＯ１からＯ１０のいずれか１つに記載の方法を実行させる。

（Ｏ１２）更に別の態様では、電子デバイスが提供され、電子デバイスは、タッチ感知面と、ディスプレイと、Ｏ１からＯ１０のいずれか１つに記載の方法を実行するための手段と、を含む。

（Ｏ１３）更に別の態様では、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は実行可能命令を記憶し、実行可能命令がタッチ感知面及びディスプレイを有する電子デバイスによって実行されると、実行可能命令は、電子デバイスにＯ１からＯ１０のいずれか１つに記載の方法を実行させる。

（Ｏ１４）更なる一態様では、タッチ感知面及びディスプレイを有する電子デバイス上のグラフィカルユーザインタフェースが提供される。一部の実施形態では、グラフィカルユーザインタフェースは、Ｏ１からＯ１０のいずれか１つに記載の方法に従って表示されるユーザインタフェースを含む。

（Ｏ１５）更なる一態様では、タッチ感知面及びディスプレイを含む電子デバイスで使用するための情報処理装置が提供される。情報処理装置は、Ｏ１からＯ１０のいずれか１つに記載の方法を実行するための手段を含む。

（Ｏ１６）更なる一態様では、ディスプレイユニット（例えば、ディスプレイユニット５５０１、図５５）と、タッチ感知面ユニット（例えば、タッチ感知面ユニット５５０３、図５５）と、処理ユニット（例えば、処理ユニット５５０５、図５５）と、を含む電子デバイスが提供される。一部の実施形態では、電子デバイスは、図１Ｅに示されるコンピューティングデバイスのいずれか１つ（例えば、コンピューティングデバイスＡからＤ）に従って構成されている。説明を容易にするため、図５５は、電子デバイス５５００に一体化されているとしてディスプレイユニット５５０１及びタッチ感知面ユニット５５０３を示すが、一部の実施形態では、これらユニットの１つ又は両方は、ユニットが電子デバイスから物理的に離れたままであっても、電子デバイスと通信する。処理ユニットは、提示ユニット（例えば、提示ユニット５５０７、図５５）と、判定ユニット（例えば、判定ユニット５５０９、図５５）と、取得ユニット（例えば、取得ユニット５５１１、図５５）と、検索実施ユニット（例えば、検索実施ユニット５５１３、図５５）と、情報準備ユニット（例えば、情報準備ユニット５５１５、図５５）と、アフォーダンス表示ユニット（例えば、アフォーダンス表示ユニット５５１７、図５５）と、検出ユニット（例えば、検出ユニット５５１９、図５５）と、を含む。処理ユニット（又はユニット５５０７から５５１９などのその１つ以上の構成要素）は、ディスプレイ上に、アプリケーションと関連付けられたテキストコンテンツを提示し（例えば、提示ユニット５５０７及び／又はディスプレイユニット５５０１によって）、テキストコンテンツの一部が（ｉ）位置、（ｉｉ）連絡先、又は（ｉｉｉ）イベントに関連すると判定し（例えば、判定ユニット５５０９によって）、テキストコンテンツの一部が位置に関連すると判定すると、電子デバイス上の位置センサから位置情報を取得し（例えば、取得ユニット５５１１によって）、取得した位置情報を予測されたコンテンツアイテムとして表示するために準備し（例えば、情報準備ユニット５５１５によって）テキストコンテンツの一部が連絡先に関連すると判定すると、電子デバイス上でテキストコンテンツの一部に関連する連絡先情報について検索を行い（例えば、検索実施ユニット５５１３によって）、検索により取り出した、少なくとも１つの連絡先と関連付けられた情報を、予測されたコンテンツアイテムとして表示するために準備し（例えば、情報準備ユニット５５１５によって）、テキストコンテンツの一部がイベントに関連すると判定すると、電子デバイス上でテキストコンテンツの一部に関連するイベント情報について新たな検索を行い（例えば、検索実施ユニット５５１３によって）、少なくとも一部、新たな検索により取り出した少なくとも１つのイベントに基づく情報を、予測されたコンテンツアイテムとして表示するために準備し（例えば、情報準備ユニット５５１５によって）、アプリケーション内に、予測されたコンテンツアイテムを含むアフォーダンスを表示し（例えば、アフォーダンス表示ユニット５５１７及び／又はディスプレイユニット５５０１によって）、タッチ感知面を介して、アフォーダンスの選択を検出し（例えば、検出ユニット５５１９によって）、選択を検出したことに応じて、予測されたコンテンツアイテムと関連付けられた情報を、ディスプレイ上に、テキストコンテンツに隣接して表示する（例えば、提示ユニット５５０７及び／又はディスプレイユニット５５０１によって）ように構成されている。

（Ｏ１７）Ｏ１６に記載の電子デバイスの一部の実施形態では、処理ユニット（又はユニット５５０７から５５１９などのその１つ以上の構成要素）は、Ｏ１からＯ１０のいずれか１つに記載の方法を実行するように更に構成されている。

上で（及び以下により詳細に）記載するように、本技術の一態様は、ユーザが関心を持つ可能性のあるコンテンツのユーザへの配布を向上するための、種々のソース（例えば、音声通信中に提供されるスピーチに基づく）から入手可能なデータの収集及び使用である。本開示は、いくつかの例においては、この収集されたデータが、特定の人物を固有に識別する、又は特定の人物と連絡を取る若しくは特定の人物を位置特定するために使用され得る個人情報データを含んでもよいと考える。そのような個人情報データは、人口統計上のデータ、場所ベースのデータ、電話番号、電子メールアドレス、家の住所、又は任意の他の身元特定可能な情報を含んでもよい。

本開示は、本技術で、そのような個人情報データの使用がユーザへの利益のために使用され得ることを認識している。例えば、よりユーザの興味を引く対象コンテンツを配信するために、個人情報データが使用されてもよい。したがって、そのような個人情報データの使用は、配信されるコンテンツの意図的な制御を可能にする。更に、ユーザに利益をもたらす個人情報データの他の使用目的が、本開示によって想到される。

本開示は、そのような個人情報データの収集、分析、開示、転送、記憶、又は他の使用目的の責任を負うエンティティが、適切に規定されたプライバシーのポリシー及び／又はプライバシーの慣行に準拠すると更に想到する。具体的には、そのようなエンティティは、個人情報データを秘密として厳重に保守するための業界又は政府の要件を満たすか又は上回るものとして一般に認識されている、プライバシーのポリシー及び慣行を実行し常に使用すべきである。例えば、ユーザからの個人情報は、そのエンティティの合法的かつ正当な使用のために収集されるべきであり、それらの合法的使用を除いて、共有又は販売されるべきではない。更に、そのような収集は、ユーザに告知して同意を得た後にのみ実行するべきである。更に、そのようなエンティティは、そのような個人情報データへのアクセスを保護して安全化し、その個人情報データへのアクセスを有する他者が、それらのプライバシーのポリシー及び手順を遵守することを保証するための、あらゆる必要な措置を講じ得る。更に、そのようなエンティティは、広く受け入れられているプライバシーのポリシー及び慣行に対する自身の遵守を証明するために、第三者による評価を自らが受けることができる。

前述のことがらにもかかわらず、本開示はまた、ユーザが、個人情報データの使用又は個人情報データへのアクセスを選択的に阻止する実施形態も企図している。すなわち、本開示は、そのような個人情報データへのアクセスを防止又は阻止するために、ハードウェア要素及び／又はソフトウェア要素を提供することができると想到する。例えば、音声通信を監視する、又はアプリケーション内でユーザが実行するアクションを監視する場合、本技術は、ユーザがサービスの登録中に個人情報データの収集への参加の「オプトイン」又は「オプトアウト」を選択することを可能にするよう構成することができる。別の実施例では、ユーザは、対象のコンテンツ配信サービスに対して位置情報を提供しないことを選択してもよい。更に別の実施例では、ユーザは、正確な位置情報を提供しないが位置のゾーン情報の転送は許可することを選択してもよい。

したがって、本開示は、１つ以上の様々な開示された実施形態を実行するための個人情報データの使用を広範に網羅しているが、本開示は、それらの様々な実施形態がまた、そのような個人情報データにアクセスすることを必要とせずに実行されることも可能であることも企図している。即ち、本技術の様々な実施形態は、そのような個人情報データの全て又は一部分の欠如により、実施不可能となるものではない。例えば、ユーザに関連付けられたデバイスによって要求されるコンテンツなどの非個人情報データ若しくは必要最小限の個人情報、コンテンツ配信サービスが入手可能な他の非個人情報、又は公的に入手可能な情報に基づいて嗜好を推測することによって、コンテンツを選択し、ユーザへ配信することができる。

上述の種々の実施形態は本明細書に記載される任意の他の実施形態と組み合わせることができることに留意されたい。本明細書に記載される特徴及び利点は包括的ではなく、特に、当業者には、図面、明細書及び請求項に鑑み、多くの更なる特徴及び利点が明らかとなろう。更に、本明細書において使用される文言は、専ら読みやすさ及び説明の目的で選択されたものであり、本発明の主題を画定又は制限するために選択されたものではない点には留意されたい。

説明される様々な実施形態を良好に理解するため、以下の図面と併せて、以下の「発明を実施するための形態」セクションを参照されたい。ここで、類似の参照番号は、それらの図にわたって、対応する部分を指す。

一部の実施形態に係る、タッチ感知ディスプレイを備えるコンピューティングデバイスの高レベルブロック図である。

一部の実施形態に係る、イベント処理のための構成要素例のブロック図である。

一部の実施形態に係る、タッチ感知ディスプレイを有するポータブル多機能デバイスの概要である。

一部の実施形態に係る、ディスプレイとは別個のタッチ感知面を備えるコンピューティングデバイスを示すために使用される概要である。

一部の実施形態に係る、アプリケーションのメニューのためのユーザインタフェースを示すために使用されるタッチスクリーンの概要である。

一部の実施形態に係る、アプリケーション使用データを記憶するためのデータ構造を示すブロック図である。 一部の実施形態に係る、アプリケーション使用データを記憶するためのデータ構造を示すブロック図である。

一部の実施形態に係る、トリガー条件を記憶するためのデータ構造を示すブロック図である。 一部の実施形態に係る、トリガー条件を記憶するためのデータ構造を示すブロック図である。

一部の実施形態に係る、トリガー条件確立システムの一例を示すブロック図である。

一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて関連コンテンツを先見的に特定し、表面化（例えば、ユーザ選択のために表面化）させる方法を示すフローチャートである。 一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて関連コンテンツを先見的に特定し、表面化（例えば、ユーザ選択のために表面化）させる方法を示すフローチャートである。

一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させるためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させるためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて関連コンテンツを先見的に特定し、表面化（例えば、ユーザ選択のために表面化）させる方法を示すフローチャートである。 一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて関連コンテンツを先見的に特定し、表面化（例えば、ユーザ選択のために表面化）させる方法を示すフローチャートである。

一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させるためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させるためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させるためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させるためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案する方法を示すフローチャートである。 一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案する方法を示すフローチャートである。 一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案する方法を示すフローチャートである。

一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、ヒューリスティックに基づいて検索モードへと移行する方法を示すフローチャートである。

一部の実施形態に係る、ヒューリスティックに基づいて検索モードへと移行するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、ヒューリスティックに基づいて検索モードへと移行するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて車両位置を先見的に提供する方法を示すフローチャートである。

一部の実施形態に係る、車両位置を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、車両位置を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供する方法を示すフローチャートである。 一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供する方法を示すフローチャートである。

一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、音声通信からコンテンツアイテムを抽出し、その抽出したコンテンツアイテムと相互作用する方法を示すフローチャートである。 一部の実施形態に係る、音声通信からコンテンツアイテムを抽出し、その抽出したコンテンツアイテムと相互作用する方法を示すフローチャートである。

一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、音声通信が物理的位置を特定するスピーチを含むと判定し、アプリケーションを、その物理的位置についての情報でポピュレートする方法を示すフローチャートである。

一部の実施形態に係る、音声通信が物理的位置を特定するスピーチを含むと判定し、アプリケーションを、その物理的位置についての情報でポピュレートするためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、音声通信が物理的位置を特定するスピーチを含むと判定し、アプリケーションを、その物理的位置についての情報でポピュレートするためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、メッセージアプリケーションにて使用するための物理的位置を先見的に提案する方法を示すフローチャートである。 一部の実施形態に係る、メッセージアプリケーションにて使用するための物理的位置を先見的に提案する方法を示すフローチャートである。

一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案する方法を示すフローチャートである。

一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする方法を示すフローチャートである。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする方法を示すフローチャートである。

一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、第２のアプリケーションでの使用のために、第１のアプリケーション内でユーザにより以前に閲覧された情報を先見的に提案する方法を示すフローチャートである。 一部の実施形態に係る、第２のアプリケーションでの使用のために、第１のアプリケーション内でユーザにより以前に閲覧された情報を先見的に提案する方法を示すフローチャートである。

一部の実施形態に係る、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案する方法を示すフローチャートである。

一部の実施形態に係る、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、貼り付けアクションを先見的に提案する方法を示すフローチャートである。

一部の実施形態に係る、貼り付けアクションを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、貼り付けアクションを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、貼り付けアクションを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。 一部の実施形態に係る、貼り付けアクションを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。

一部の実施形態に係る、モバイルデバイスの動的調整を実行するよう構成されたモバイルデバイスを示す。

一部の実施形態に係る、ヒューリスティックプロセスを呼び出すためのプロセス例を示す。

一部の実施形態に係る、ヒューリスティックプロセスを使用してモバイルデバイスの設定を調整するためのプロセスを示す。

一部の実施形態に係る、アプリケーションのバックグラウンドフェッチ更新を実行するためのシステム例を示す。

一部の実施形態に係る、モバイルデバイス１００上のアプリケーションに対するユーザ呼び出しの蓋然性を判定するためのピア予想を示す。

一部の実施形態に係る、アプリケーションを予測的に起動してバックグラウンド更新を実行するためのプロセス例のフロー図である。

一部の実施形態に係る、モバイルデバイス上でアプリケーションをいつ起動するかを判定するためのプロセス例のフロー図である。

一部の実施形態に係る、トレンドテーブルへの入力のための状態遷移を示すフロー図である。

一部の実施形態に係る、プッシュ通知をモバイルデバイスに提供するためのシステムを示すブロック図である。

一部の実施形態に係る、プッシュ通知サーバにてノンウェイキングプッシュを実行するためのプロセス例のフロー図である。

一部の実施形態に係る、低優先プッシュ通知に応じて、アプリケーションのバックグラウンド更新を実行するためのプロセス例のフロー図である。

一部の実施形態に係る、高優先プッシュ通知に応じて、アプリケーションのバックグラウンド更新を実行するためのプロセス例のフロー図である。

一部の実施形態に係る、モバイルデバイス上にてデータのバックグラウンドダウンローディング及び／又はアップローディングを実行するためのシステム例のブロック図である。

一部の実施形態に係る、バックグラウンドダウンロード及びアップロードを実行するためのプロセス例のフロー図である。

一部の実施形態に係る、モバイルデバイス上のアプリケーションに対するバックグラウンド更新を有効及び／又は無効にするためのグラフィカルユーザインタフェース（ＧＵＩ）例を示す。

一部の実施形態に係る、ピアデバイス間でデータをシェアするためのシステム例を示す。

一部の実施形態に係る、ピアデバイス間でデータをシェアするためのプロセス例を示す。

一部の実施形態に係る、入力されたクエリプレフィックスに基づく検索結果を返すシステムの一実施形態のブロック図である。

一部の実施形態に係る、入力されたクエリプレフィックスに基づくクエリ補完及び関連結果を判定するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、アグリゲータ及び複数の検索ドメインの一実施形態のブロック図である。

一部の実施形態に係る、クエリ補完検索ドメインに対する一実施形態の図である。

地図検索ドメインの一実施形態の図である。 一部の実施形態に係る、複数の検索ドメインからのクエリ補完を判定するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、判定されたクエリ補完から、複数の検索ドメインにわたる関連結果を判定するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、ユーザフィードバックをフィードバック検索インデックスに組み込むシステムの一実施形態のブロック図である。

一部の実施形態に係る、ユーザフィードバックを引用検索インデックスに組み込むプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、ユーザ検索セッション中にユーザフィードバックを収集するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、ユーザフィードバックをフィードバックインデックスに組み込むプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、ユーザフィードバックを使用して結果キャッシュを更新するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、特徴付けられたクエリ補完を使用してマルチドメイン検索を実行するフェデレータの一実施形態のブロック図である。

一部の実施形態に係る、語彙サービスを使用して関連結果を判定するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、クエリ補完を特徴付けるプロセスの一実施形態のフローチャートである。

一部の実施形態に係る、複数の検索ドメインからのクエリ補完を判定する補完モジュールの一実施形態のブロック図である。

一部の実施形態に係る、判定されたクエリ補完から複数の検索ドメインにわたる関連結果を判定する結果モジュールの一実施形態のブロック図である。

一部の実施形態に係る、ユーザ検索セッション中にユーザフィードバックを収集するフィードバック収集モジュールの一実施形態のブロック図である。

一部の実施形態に係る、ユーザフィードバックをフィードバックインデックスに組み込むフィードバック処理モジュールの一実施形態のブロック図である。

一部の実施形態に係る、ユーザフィードバックを使用して結果キャッシュを更新するクエリ結果更新モジュールの一実施形態のブロック図である。

一部の実施形態に係る、ユーザフィードバックをフィードバックインデックスに組み込むフィードバック処理モジュールの一実施形態のブロック図である。

一部の実施形態に係る、ユーザフィードバックを使用して結果キャッシュを更新するクエリ結果更新モジュールの一実施形態のブロック図である。

従来技術に既知のコンピューティングデバイス上のローカル検索サブシステム及びリモート検索サブシステムを、ブロック図の形態にて示す。

一部の実施形態に係る、コンピューティングデバイス上のリモート検索アプリケーションから返された結果を改善するために使用され得るローカル学習機能を有するローカル検索サブシステムを、ブロック図の形態にて示す。

一部の実施形態に係る、ローカル検索クエリ、ローカル結果、及び、ローカル結果に基づくローカルフィードバックを使用する、クエリ特徴をローカルにて学習する方法を、ブロック図の形態にて示す。

一部の実施形態に係る、ローカル検索クエリ及びリモート検索クエリの両方から返された検索結果、並びにローカル及びリモート検索クエリ結果の両方におけるローカルフィードバックを使用する、クエリ特徴をローカルにて学習する方法を、ブロック図の形態にて示す。

一部の実施形態に係る、リモートサービスに渡されたクエリに応じて、リモートサービスによりローカルデバイスに送信されたクエリ特徴をローカルにて学習する方法を、ブロック図の形態にて示す。

一部の実施形態に係る、新たな特徴を受信又は判定し、ローカルにてトレーニングし、使用する方法を、ブロック図の形態にて示す。

一部の実施形態に係る、本発明の一部の実施形態にて使用可能なソフトウェアスタックの例示的実施形態を示す。

一部の実施形態に係る、提案された連絡先のための例示的データアーキテクチャのブロック図を示す。

一部の実施形態に係る、提案されたカレンダーイベントのための例示的データアーキテクチャのブロック図を示す。

一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ａは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。 一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ｂは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。 一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ｃは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。 一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ｄは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。 一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ｅは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。 一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ｆは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。 一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的ユーザインタフェースを示す。図１Ａ～１Ｂ、２、及び３は、本セクションに記載の連絡先及びイベント情報を提案するための技術を実行するための例示的デバイスの説明を提供する。図３４－６Ｇは、連絡先及びイベント情報を提案するための例示的ユーザインタフェース示す。これらの図内のユーザインタフェースはまた、図３４－７Ａ～図３４－１３に示すプロセスを含む、以下に説明するプロセスを示すために使用される。

一部の実施形態に係る、提案された連絡先を生成するための例示的プロセスのフロー図を示す。 一部の実施形態に係る、提案された連絡先を生成するための例示的プロセスのフロー図を示す。

一部の実施形態に係る、既存の連絡先を、提案された連絡先情報のアイテムと共に更新するための例示的プロセスのフロー図を示す。 一部の実施形態に係る、既存の連絡先を、提案された連絡先情報のアイテムと共に更新するための例示的プロセスのフロー図を示す。

一部の実施形態に係る、連絡先を、提案された連絡先情報と共に表示するための例示的プロセスのフロー図を示す。 一部の実施形態に係る、連絡先を、提案された連絡先情報と共に表示するための例示的プロセスのフロー図を示す。

一部の実施形態に係る、提案された連絡先情報を、メッセージと共に表示するための例示的プロセスのフロー図を示す。

一部の実施形態に係る、提案されたカレンダーイベントを生成するための例示的プロセスのフロー図を示す。 一部の実施形態に係る、提案されたカレンダーイベントを生成するための例示的プロセスのフロー図を示す。

一部の実施形態に係る、提案されたイベント情報を、メッセージと共に表示するための例示的プロセスのフロー図を示す。

一部の実施形態に係る、複数の提案された連絡先又はイベント情報を、メッセージと共に表示するための例示的プロセスのフロー図を示す。

一部の実施形態に係る電子デバイスの機能ブロック図である。

一部の実施形態に係る電子デバイスの機能ブロック図である。

一部の実施形態に係る、検出されたイベントに基づいてアプリケーションを提案する方法３５＿１００のフローチャートである。

一部の実施形態に係るセグメンテーションプロセス３５＿２００を示す。

一部の実施形態により生成されてよい決定木３５＿３００を示す。

一部の実施形態に係る、アプリケーションを、コンピューティングデバイスのユーザに、イベントに基づいて提案する方法３５＿４００のフローチャートである。

一部の実施形態に係る、様々な正確な数値及び不正確な数値に対する二項分布例のプロットを示す。 一部の実施形態に係る、様々な正確な数値及び不正確な数値に対する二項分布例のプロットを示す。 一部の実施形態に係る、様々な正確な数値及び不正確な数値に対する二項分布例のプロットを示す。 一部の実施形態に係る、様々な正確な数値及び不正確な数値に対する二項分布例のプロットを示す。

一部の実施形態に係る、セグメンテーションに起因する親モデル及びサブモデルを示す。 一部の実施形態に係る、セグメンテーションに起因する親モデル及びサブモデルを示す。

一部の実施形態に係る、１つ以上のアプリケーションとの相互作用のためのユーザインタフェースをユーザに提供するためのアーキテクチャ例３５＿７００を示す。

一部の実施形態に係る、トリガーイベントに基づいてアプリケーションを特定する方法のフローチャートである。

一部の実施形態に係る、トリガーイベントを判定するためのシステムのブロック図を示す。

一部の実施形態に係る、トリガーイベントに基づいて、ユーザに対するアプリケーションを特定するためのシステムのブロック図を示す。

一部の実施形態に係る、複数の予測モデルを用いてアプリケーションを特定するためのシステムのブロック図を示す。

一部の実施形態に係る、デバイスでのトリガーイベントに基づいてアプリケーションを特定する方法のフローチャートである。

一部の実施形態に係る、音楽アプリケーションのためのユーザインタフェースを有するデバイスの簡易図である。

一部の実施形態に係る、特定されたアプリケーションをユーザインタフェースから消去する方法のフローチャートである。 一部の実施形態に係る、特定されたアプリケーションをユーザインタフェースから消去する方法のフローチャートである。

一部の実施形態に係る、検出されたイベントに基づいて、宛先を提案する方法１００のフローチャートである。

一部の実施形態に係る、トリガーイベントを判定するためのシステムのブロック図を示す。

一部の実施形態に係る、トリガーイベントに基づいて、宛先を特定するためのシステムのブロック図を示す。

一部の実施形態に係る、電子メールアプリケーションのためのユーザインタフェース内に、宛先を提案する一例を示す。

一部の実施形態に係る、検索アプリケーションのためのユーザインタフェース内に、宛先を提案する一例を示す。

一部の実施形態に係る、イベントに基づいて、コンピューティングデバイスのユーザに受領者を提案する方法３７－６００のフローチャートである。

一部の実施形態に係る、宛先を提案するためのデータフロー例を示す。

一部の実施形態に係る、相互作用モジュールのブロック図を示す。

一部の実施形態に係る、宛先を提案するためのユーザインタフェースをユーザに提供するためのアーキテクチャ例３７－９００を示す。

一部の実施形態に係る、本明細書に記載の様々な技術を実施するよう構成されたモバイルコンピューティングデバイスの異なる構成要素のブロック図を示す。

一部の実施形態に係る、図３８－１のアプリケーション予測エンジンにより実行される方法を示す。

一部の実施形態に係る、図１の検索アプリケーションにより実行される方法を示す。

一部の実施形態に係る、図３８－１の検索アプリケーションのユーザインタフェース例の概念図を示す。

一部の実施形態に係る、本明細書に記載の様々な技術を実施するよう構成されたモバイルコンピューティングデバイスの異なる構成要素のブロック図を示す。

一部の実施形態に係る、図３９－１（又は、図１Ａ）に示すモバイルコンピューティングデバイスの特定の構成要素のより詳細なブロック図を示す。

一部の実施形態に係る、予測エンジンの高レベルな初期化及び動作の方法を示す。

一部の実施形態に係る、予測エンジンでの予測を同期して提供する方法を示す。

一部の実施形態に係る、予測エンジンでの予測を非同期に提供する方法を示す。

一部の実施形態に係る、予測を同期して受信することを要求する消費者向けアプリケーションの方法を示す。

一部の実施形態に係る、予測を非同期に受信するよう登録する消費者向けアプリケーションの方法を示す。

一部の実施形態に係る、予測エンジンセンターにて予測エンジン登録を管理する方法を示す。

一部の実施形態に係る、予測エンジンセンターにて消費者向けアプリケーションに予測を同期して提供する方法を示す。

一部の実施形態に係る、予測エンジンセンターにて消費者向けプリケーションに予測を非同期に提供する方法を示す。

一部の実施形態に係る、コンピューティングデバイスの現在のコンテキストにおける変化を監視し、予測し、コンテキストクライアントに通知するためのシステム例のブロック図である。

一部の実施形態に係る、現在のコンテキストを構成し得るコンテキストアイテムの一例を示す。

一部の実施形態に係る、現在のコンテキストに加えられている新たなコンテキストアイテムの一例を示す。

一部の実施形態に係る、コールバック述語データベース例を示す。

一部の実施形態に係る、コンテキストアイテムに関連付けられた、経時による状態変化例を示すグラフである。

一部の実施形態に係る、コンテキストアイテムに関連付けられたイベントストリーム例を示すグラフである。

一部の実施形態に係る、過去イベントストリームデータベース例を示す。

一部の実施形態に係る、コンテキストコールバック通知を要求クライアントに提供するためのシステム例のブロック図である。

一部の実施形態に係る、終了した要求クライアントを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、終了した要求クライアントを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、終了したコンテキストデーモンを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、終了したコンテキストデーモンを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、終了したコンテキストデーモン及び要求クライアントを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、終了したコンテキストデーモン及び要求クライアントを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、起動デーモンにより受信されたデバイス状態情報に基づいて、クライアント及び／又はコンテキストデーモンを再開始するよう構成されたシステム例のブロック図である。

一部の実施形態に係る、起動デーモンを使用してコンテキストデーモンを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、起動デーモンを使用してコンテキストデーモンを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、起動デーモンを使用して要求クライアントを再開始することを示すシステム例のブロック図である。

一部の実施形態に係る、起動デーモンを使用して要求クライアントを再開することを示すシステム例のブロック図である。

一部の実施形態に係る、将来のイベントを予測するスロットワイズ平均化（slot-wise averaging）の一例を示すグラフである。

一部の実施形態に係る、スロット重み付け（slot weighting）を示すグラフ例を示す。

一部の実施形態に係る、将来のコンテキストを予測する方法例を示すグラフである。

一部の実施形態に係る、スロットワイズ確率（slot-wise probabilities）を確率曲線に変換する方法例を示すグラフである。

一部の実施形態に係る、予測された将来のイベントを含むイベントストリーム例を示す。

一部の実施形態に係る、コンピューティングデバイス上のコンテキスト変化をクライアントに通知するためのプロセス例のフロー図である。

一部の実施形態に係る、コンテキストデーモンを再開始してコールバック要求をサービスするためのプロセス例のフロー図である。

一部の実施形態に係る、コールバッククライアントを再開始してコールバック通知を受信するためのプロセス例のフロー図である。

一部の実施形態に係る、過去コンテキスト情報に基づいて将来のイベントを予測するためのプロセス例のフロー図である。

一部の実施形態に係る、スリープコンテキストコールバック要求をサービスするためのプロセス例のフロー図である。

ローカルデバイス検索インデックスでの使用のためにアプリケーション状態のインデックスを付けるシステムの一実施形態のブロック図である。

オンデバイスアプリケーション状態検索インデックスを使用してアプリケーション状態を検索するシステムの一実施形態のブロック図である。

他のクエリ結果中の、アプリケーション状態クエリ結果を表示するユーザインタフェースの実施形態のブロック図である。

デバイス上の複数の異なるアプリケーションから受信したアプリケーション状態にインデックスを付けるプロセスの一実施形態のフロー図である。

アプリケーション状態インデックスを使用して、クエリに対するクエリ結果を判定するプロセスの一実施形態のフロー図である。

アプリケーション状態を受信し、クエリ結果の一部として提示するプロセスの一実施形態のフロー図である。

リモート検索インデックスでの使用のために、アプリケーション状態にインデックスを付けるシステムの一実施形態のブロック図である。

リモートアプリケーション状態検索インデックスを使用して、アプリケーション状態を検索するシステムの一実施形態のブロック図である。

アプリケーション状態をアプリケーション状態インデックスに加えるプロセスの一実施形態のフロー図である。

アプリケーション状態をアプリケーション状態インデキシングサービスにエクスポートするプロセスの一実施形態のフロー図である。

アプリケーション状態インデックスを使用して、クエリ検索を実行するプロセスの一実施形態のフローチャートである。

アプリケーション状態を受信し、クエリ結果の一部として提示するプロセスの一実施形態のフロー図である。

リモート検索インデックスでの使用のために、アプリケーション状態ビューにインデックスを付けるシステムの一実施形態のブロック図である。

アプリケーションビューの一実施形態のブロック図である。

アプリケーション状態を使用して、アプリケーション状態ビューを生成するプロセスの一実施形態のフローチャートである。

アプリケーション状態ビューを含むアプリケーション状態を受信し、クエリ結果の一部として提示するプロセスの一実施形態のフローチャートである。

一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。 一部の実施形態に係る電子デバイスの機能ブロック図である。

上記のように、そして以下に詳述するように、アプリケーション及びそれらのアプリケーション内の所望する機能に素早くアクセスするための、より迅速でより効率的な方法及びインタフェースを備える電子デバイスの要望が高まっている。特に、繰り返しタスクを排除し、ユーザが明示的に関連情報を要求する前にそれを特定して提供することで、先見的なアシスタンスを提供するようユーザを補助するデバイスへの要望が高まっている。更に、アプリケーション及びそれらのアプリケーション内の所望する機能に、特定の期間（例えば、毎朝起床後にカレンダーアプリケーションにアクセスする）及び特定の場所（例えば、ジムで音楽アプリケーションにアクセスする）などにて素早くアクセスするという要望が高まっている。本明細書に開示するものは、それらの要望に対処し、アプリケーションと、それらのアプリケーション内の機能に、それらの特定の場所及び期間などにて素早くアクセスする方法をユーザに提供する新たな方法及びインタフェースである。このような方法及びインタフェースは任意選択的に、アプリケーションにアクセスするための既存の方法を補完又は置き換える。このような方法及びインタフェースは、ユーザの認識的負担を軽減し、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作デバイスの場合、このような方法及びインタフェースは、電力を節約し、バッテリを充電する間隔を延長する。更に、このような方法及びインタフェースは、必要な入力数を減らすことにより、タッチ感知ディスプレイの寿命を延ばすよう補助する（例えば、連続的にかつ漫然とタッチ感知ディスプレイをタップして所望する情報を特定する代わりに、本明細書に開示する方法及びインタフェースは、ユーザ入力を必要とすることなく、情報を先見的に提供する）。

以下、図１Ａ～１Ｅ、及び２は、デバイス例の説明を提供する。図１０及び１１は、電子デバイス例の機能ブロック図を提供する。図３Ａ～３Ｂ及び４Ａ～４Ｂは、関連コンテンツを先見的に特定し、表面化させるために使用されるデータ構造例のブロック図である（これらのデータ構造は、図６Ａ～６Ｂに関連して説明される方法及び図８Ａ～８Ｂを参照して説明される方法にて使用される）。図５は、関連コンテンツを先見的に特定し、表面化させるために使用されるトリガー条件を確立するためのシステム例を示すブロック図である（このシステム例は、図６Ａ～６Ｂに関連して説明される方法及び図８Ａ～８Ｂを参照して説明される方法にて使用される）。図６Ａ～６Ｂは、関連コンテンツを先見的に特定し、表面化させる方法を示すフローチャートである。図７Ａ～７Ｂは、関連コンテンツを先見的に特定し、表面化させるユーザインタフェース及びジェスチャ例を示すために使用されるタッチ感知ディスプレイの概要である。図８Ａ～８Ｂは、関連コンテンツを先見的に特定し、表面化させる方法を示すフローチャートである。図９Ａ～９Ｄは、関連コンテンツを先見的に特定し、表面化させるための追加ユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図３Ａ～３Ｂ、４Ａ～４Ｂ、５、及び７Ａ～７Ｂは、図６Ａ～６Ｂの方法及び／又はプロセスを示すために使用される。図３Ａ～３Ｂ、４Ａ～４Ｂ、５、及び９Ａ～９Ｄは、図８Ａ～８Ｂの方法及び／又はプロセスを示すために使用される。

図１０Ａ～１０Ｃは、タッチ感知ディスプレイを備える電子デバイス上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案する方法を示すフローチャートである。図１１Ａ～１１Ｊは、タッチ感知ディスプレイ上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図１１Ａ～１１Ｊは、図１０Ａ～１０Ｃの方法及び／又はプロセスを示すために使用される。

図１２は、ヒューリスティックに基づいて検索モードへと移行する方法を示すフローチャートである。図１３Ａ～１３Ｂは、ヒューリスティックに基づいて検索モードへと移行するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図１３Ａ～１３Ｂは、図１２の方法及び／又はプロセスを示すために使用される。

図１４は、一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて車両位置を先見的に提供する方法を示すフローチャートである。図１５Ａ～１５Ｂは、一部の実施形態に係る、車両位置を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図１５Ａ～１５Ｂは、図１４の方法及び／又はプロセスを示すために使用される。

図１６Ａ～１６Ｂは、一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供する方法を示すフローチャートである。図１７Ａ～１７Ｅは、一部の実施形態に係る、検索クエリに対する近隣の対象地点（ＰＯＩ）情報を先見的に提供するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図１６Ａ～１６Ｂは、図１７Ａ～１７Ｅの方法及び／又はプロセスを示すために使用される。

図１８Ａ～１８Ｂは、一部の実施形態に係る、音声通信からコンテンツアイテムを抽出し、その抽出したコンテンツアイテムと相互作用する方法を示すフローチャートである。図１９Ａ～１９Ｆは、一部の実施形態に係る、音声通信から抽出されたコンテンツアイテムを表示し、相互作用するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図１９Ａ～１９Ｆは、図１８Ａ～１８Ｂの方法及び／又はプロセスを示すために使用される。

図２０は、一部の実施形態に係る、音声通信が物理的位置を特定するスピーチを含むと判定し、アプリケーションを、その物理的位置についての情報でポピュレートする方法を示すフローチャートである。図２１Ａ～２１Ｂは、一部の実施形態に係る、音声通信が物理的位置を特定するスピーチを含むと判定し、アプリケーションを、その物理的位置についての情報でポピュレートするためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図１９Ａ～１９Ｆ及び２１Ａ～２１Ｂは、図２０の方法及び／又はプロセスを示すために使用される。

図２２Ａ～２２Ｂは、一部の実施形態に係る、メッセージアプリケーションにて使用するための物理的位置を先見的に提案する方法を示すフローチャートである。図２３Ａ～２３Ｏは、一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案するため（例えば、ユーザによる容易な選択、及び、メッセージアプリケーション内での含有のため）のユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図２３Ａ～２３Ｏは、図２２Ａ～２２Ｂの方法及び／又はプロセスを示すために使用される。

図２２Ｃは、一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案する方法を示すフローチャートである。図２３Ａ～２３Ｏは、図２２Ｃの方法及び／又はプロセスを示すために使用される。

図２４Ａ～２４Ｂは、一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、前もって先見的にポピュレートする方法を示すフローチャートである。図２５Ａ～２５Ｊは、一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、前もって先見的にポピュレートする（例えば、ライドシェアアプリケーションを、レビューアプリケーション内でユーザにより閲覧された位置についての情報で、ポピュレートする）ためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図２５Ａ～２５Ｊは、図２４Ａ～２４Ｂの方法及び／又はプロセスを示すために使用される。

図２６Ａ～２６Ｂは、一部の実施形態に係る、第２のアプリケーションでの使用のために、第１のアプリケーション内でユーザにより以前に閲覧された情報を先見的に提案する方法を示すフローチャートである。図２５Ａ～２５Ｊは、図２６Ａ～２６Ｂの方法及び／又はプロセスを示すために使用される。

図２７は、一部の実施形態に係る、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案する方法を示すフローチャートである。図２８は、一部の実施形態に係る、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図２８は、図２７の方法及び／又はプロセスを示すために使用される。

図２９は、一部の実施形態に係る、貼り付けアクションを先見的に提案する方法を示すフローチャートである。図３０Ａ～３０Ｄは、一部の実施形態に係る、貼り付けアクション先見的に提案するためのユーザインタフェースを示すために使用されるタッチ感知ディスプレイの概要である。図３０Ａ～３０Ｄは、図２９の方法及び／又はプロセスを示すために使用される。

「発明を実施するための追加形態」セクション内のセクション１～１１は、図１Ａ～３０Ｄに関連して提供される説明を補完する追加詳細を説明する。

ここで、添付図面に実施例が示される実施形態を、詳細に参照する。以下の詳細な説明では、説明されている様々な実施形態の完全な理解を提供するために数多くの具体的な詳細が記載されている。しかしながら、説明されている様々な実施形態は、これらの具体的な詳細を伴わずとも実践し得ることが、当業者には明らかであろう。他の例においては、周知の、方法、手続き、構成要素、回路、及びネットワークは、実施形態の態様を不必要に不明瞭なものとしないよう、詳細には説明されていない。

本明細書では、第１、第２などの用語は、一部の実施例で、様々な要素を説明するために使用されるが、これらの要素は、それらの用語によって限定されるべきではないことも理解されるであろう。これらの用語は、ある要素を別の要素と区別するためにのみ使用される。例えば、説明されている様々な実施形態の範囲から逸脱することなく、第１の接触は、第２の接触と称することができ、同様に、第２の接触は、第１の接触と称し得る。第１の接触及び第２の接触は両方とも接触であるが、それらは同じ接触ではない。

本明細書で説明される様々な実施形態の説明で使用される用語は、特定の実施形態を説明することのみを目的とするものであって、限定することを意図するものではない。様々な記載の実施形態、及び添付の特許請求の範囲で使用される時に、単数形「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈が別途明確に示さない限り、複数形も同様に含むことが意図されている。本明細書で使用する時、用語「及び／又は」は、関連する列挙されたアイテムのうちの１つ以上の任意の全ての可能な組み合わせを指し、かつこれを含むことをもまた理解されたい。用語「ｉｎｃｌｕｄｅｓ（含む）、「ｉｎｃｌｕｄｉｎｇ（含む）」、「ｃｏｍｐｒｉｓｅｓ（含む）」及び／又は「ｃｏｍｐｒｉｓｉｎｇ（含む）」は、本明細書で使用されるとき、述べられた特徴、整数、ステップ、動作、要素、及び／又は構成要素の存在を指定するが、１つ以上の他の特徴、整数、ステップ、動作、要素、構成要素、及び／又はそれらの群、の存在又は追加を除外しないことが更に理解されるであろう。

本明細書で使用する時、用語「ｉｆ（～の場合には）」は、任意選択的に、文脈に応じて「ｗｈｅｎ（～の時）」、「ｕｐｏｎ（～すると）」、「ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｒｍｉｎｉｎｇ（～という判定に応じて）」、又は「ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｃｔｉｎｇ（～の検出に応じて）」を意味するものと解釈される。同様に、句「ｉｆ ｉｔ ｉｓ ｄｅｔｅｒｍｉｎｅｄ（～と判定される場合に）」又は「ｉｆ（ａ ｓｔａｔｅｄ ｃｏｎｄｉｔｉｏｎ ｏｒ ｅｖｅｎｔ）ｉｓ ｄｅｔｅｃｔｅｄ（（述べられる条件又はイベント）が検出される場合に）」を、文脈に応じて「ｕｐｏｎ ｄｅｔｅｒｍｉｎｉｎｇ（～と判定されると）」、「ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｒｍｉｎｉｎｇ（～との判定に応じて）」、「ｕｐｏｎ ｄｅｔｅｃｔｉｎｇ（ｔｈｅ ｓｔａｔｅｄ ｃｏｎｄｉｔｉｏｎ ｏｒ ｅｖｅｎｔ）（（述べられる条件又はイベント）が検出されると）」、又は「ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｃｔｉｎｇ（ｔｈｅ ｓｔａｔｅｄ ｃｏｎｄｉｔｉｏｎ ｏｒ ｅｖｅｎｔ）（（述べられる条件又はイベント）の検出に応じて）」を意味するものと、任意選択的に、解釈する。

本明細書の開示は、特定のユーザインタフェース要素又はタッチ感知ディスプレイの特定の一部上での、にての、にわたる、の上での、又は、の実質的にそれ以内でのタッチ入力の検出を互換的に引用する。本明細書で使用する時、特定のユーザインタフェース要素「にて」検出されたタッチ入力はまた、コンテキストによっては、同じユーザインタフェース要素「上で」、「にわたって」、「の上で」、又は、「の実質的にそれ以内で」検出されたタッチ入力であり得る。一部の実施形態では、及び、以下に詳述するように、タッチ入力を検出するための所望する感度レベルは、電子デバイスのユーザにより構成される（例えば、タッチ入力が完全にユーザインタフェース要素内である場合にのみ、そのタッチ入力は検出されるべきであると、ユーザは決定し得る（及び、電子デバイスを構成して操作し得る））。

電子デバイス、このようなデバイス用のユーザインタフェース、及びこのようなデバイスを使用するための関連処理、の実施形態を説明する。一部の実施形態では、このデバイスは、ＰＤＡ機能及び／又は音楽プレーヤ機能などの、他の機能も含む、モバイル電話機などのポータブル通信デバイスである。ポータブル多機能デバイスの例示的な実施形態としては、限定を伴わずに、Ｃａｌｉｆｏｒｎｉａ州ＣｕｐｅｒｔｉｎｏのＡＰＰＬＥ Ｉｎｃ．のＩＰＨＯＮＥ（登録商標）、ＩＰＯＤ ＴＯＵＣＨ（登録商標）、及びＩＰＡＤ（登録商標）デバイスが挙げられる。タッチ感知面（例えば、タッチ感知ディスプレイ及び／又はタッチパッド）を備えるラップトップ又はタブレットコンピュータなどの他のポータブル電子デバイスも、任意選択的に、使用される。また、一部の実施形態では、このデバイスはポータブル通信デバイスではなく、タッチ感知面（例えば、タッチ感知ディスプレイ及び／又はタッチパッド）を備えるデスクトップコンピュータであることを理解されたい。

以下の説明では、ディスプレイ及びタッチ感知面を備える電子デバイスについて説明する。しかし、この電子デバイスは、物理キーボード、マウス、及び／又はジョイスティックなどの１つ以上の他の物理ユーザインタフェースデバイスを任意選択的に含むことを理解されたい。

本デバイスは、一般的に、描画アプリケーション、プレゼンテーションアプリケーション、ワードプロセッシングアプリケーション、ウェブサイト作成アプリケーション、ディスクオーサリングアプリケーション、スプレッドシートアプリケーション、ゲームアプリケーション、電話アプリケーション、テレビ会議アプリケーション、電子メールアプリケーション、インスタントメッセージアプリケーション、ヘルス／フィットネスアプリケーション、写真管理アプリケーション、デジタルカメラアプリケーション、デジタルビデオカメラアプリケーション、ウェブブラウズアプリケーション、デジタル音楽プレーヤアプリケーション及び／又はデジタルビデオプレーヤアプリケーションのうちの１つ以上などの様々なアプリケーションをサポートする。

このデバイス上で実行される様々なアプリケーションは、タッチ感知面などの、少なくとも１つの共通の物理ユーザインタフェースデバイスを、任意選択的に使用する。タッチ感知面の１つ以上の機能、並びにデバイス上に表示される対応する情報は、アプリケーションごとに、及び／又は対応するアプリケーション内で、任意選択的に、調整及び／又は変更される。このように、デバイスの共通の（タッチ感知面などの）物理アーキテクチャは、ユーザにとって直観的かつ透過的なユーザインタフェースを有する様々なアプリケーションを、任意選択的にサポートする。

次に、タッチ感知ディスプレイを備えるポータブル電子デバイスの実施形態に注意を向ける。図１Ａは、一部の実施形態に係る、タッチ感知ディスプレイ１１２を備えるポータブル多機能デバイス１００（本明細書ではまた、互換的に、電子デバイス１００又はデバイス１００とも呼ぶ）を示すブロック図である。タッチ感知ディスプレイ１１２は、便宜上「タッチスクリーン」と呼ばれる場合があり、タッチ感知ディスプレイシステムとして、知られる場合又は呼ばれる場合もある。デバイス１００は、（任意選択的に、１つ以上のコンピュータ可読記憶媒体を含む）メモリ１０２、コントローラ１２０、１つ以上の処理ユニット（ＣＰＵ）１２２、周辺機器インタフェース１１８、ＲＦ回路１０８、オーディオ回路１１０、スピーカ１１１、マイクロフォン１１３、入出力（Ｉ／Ｏ）サブシステム１０６、他の入力又は制御デバイス１１６、及び外部ポート１２４を含む。デバイス１００は、１つ以上の光センサ１６４を任意選択的に含む。デバイス１００は、デバイス１００（例えば、デバイス１００のタッチ感知ディスプレイシステム１１２などのタッチ感知面）上の接触の強度を検出するための、１つ以上の強度センサ１６５を任意選択的に含む。デバイス１００は、デバイス１００上にタクタイル出力を生成する（例えば、デバイス１００のタッチ感知ディスプレイシステム１１２又はデバイス１００のタッチパッドなどの、タッチ感知面上にタクタイル出力を生成する）ための、１つ以上のタクタイル出力生成器１６７を任意選択的に含む。これらの構成要素は、１つ以上の通信バス又は信号ライン１０３を介して任意選択的に通信する。

本明細書及び特許請求の範囲で使用されるとき、タッチ感知面上の接触の「強度」という用語は、タッチ感知面上の接触（例えば、指接触）の力又は圧力（単位面積当りの力）、あるいはタッチ感知面上の接触の力又は圧力の代替物（代用物）を指す。接触の強度は、少なくとも４つの別個の値を含み、より典型的には、何百もの異なる値（例えば、少なくとも２５６）を含む、値の範囲を有する。接触の強度は、様々な方法及び様々なセンサ、又はセンサの組み合わせを使用して、任意選択的に、判定（又は、測定）される。例えば、タッチ感知面の下に又は隣接して配置された１つ以上の力センサは、タッチ感知面上の様々な点における力を測定するために、任意選択的に使用される。一部の実装において、複数の力センサの力測定値を組み合わせて（例えば、加重平均）、接触力の推定値を判定する。同様に、タッチ感知面上のスタイラスの圧力を判定するために、スタイラスの圧力感知チップが、任意選択的に用いられる。あるいは、タッチ感知面上で検出される接触領域のサイズ及び／若しくはその変化、接触に近接するタッチ感知面の電気容量及び／若しくはその変化、並びに／又は、接触に近接するタッチ感知面の抵抗及び／若しくはその変化が、タッチ感知面上の接触の力又は圧力の代替物として、任意選択的に用いられる。一部の実装では、接触の力又は圧力の代替的測定値は、強度閾値を超えているか否かを判定するために直接に用いられる（例えば、強度閾値は、代替的測定値に対応する単位で記述される）。一部の実装では、接触の力又は圧力の代替的測定値は、推定される力又は圧力に変換され、この推定される力又は圧力を用いて、強度閾値を超えているか否かを判定する（例えば、強度閾値は、圧力の単位で測定された圧力閾値である）。

本明細書及び特許請求の範囲で使用される時、用語「タクタイル出力」は、ユーザの触覚でユーザによって検出されることになる、デバイスの従前の位置に対するデバイスの物理的変位、デバイスの構成要素（例えば、タッチ感知面）の、デバイスの別の構成要素（例えば、筐体）に対する物理的変位、又はデバイスの重心に対する構成要素の変位を指す。例えば、デバイス又はデバイスの構成要素が、タッチに敏感なユーザの表面（例えば、ユーザの手の指、手のひら、又は他の部分）に接触している状況において、物理的変位によって生成されたタクタイル出力は、デバイス又はデバイスの構成要素の物理的特性の認識された変化に相当する触感として、ユーザによって解釈される。例えば、タッチ感知面（例えば、タッチ感知ディスプレイ又はトラックパッド）の移動は、ユーザによって、物理アクチュエータボタンの「ダウンクリック」又は「アップクリック」として任意選択的に解釈される。一部の場合には、ユーザの動作により物理的に押された（例えば、変位された）タッチ感知面に関連付けられた物理アクチュエータボタンの移動がない時でさえ、ユーザは「ダウンクリック」又は「アップクリック」などの触感を感じるであろう。別の実施例として、タッチ感知面の運動は、タッチ感知面の平滑度に変化がない場合であっても、ユーザによって、そのタッチ感知面の「粗さ」として、任意選択的に解釈又は感知される。そのようなユーザによるタッチの解釈は、ユーザの個人的な感覚認知に左右されるものではあるが、大多数のユーザに共通する、多くのタッチの感覚認知が存在する。従って、タクタイル出力が、ユーザの特定の感覚認知（例えば、「アップクリック」、「ダウンクリック」、「粗さ」）に対応するものと記述される場合、別途記載のない限り、生成されたタクタイル出力は、典型的な（又は、平均的な）ユーザの記述された感覚認知を生成するデバイス、又はデバイスの構成要素の物理的変位に対応する。

デバイス１００は、ポータブル多機能デバイスの一実施例に過ぎず、デバイス１００は、示されるものよりも多いか又は少ない構成要素を任意選択的に有するか、２つ以上の構成要素を任意選択的に組み合わせるか、又は構成要素の異なる構成若しくは配置を任意選択的に有することを理解されたい。図１Ａに示される様々な構成要素は、１つ以上の信号処理回路、及び／又は特定用途向け集積回路を含む、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの組み合わせで実装される。

メモリ１０２は、任意選択的に、高速ランダムアクセスメモリ（例えば、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ、又は他のランダムアクセスソリッドステートメモリデバイス）を含み、また任意選択的に、１つ以上の磁気ディスク記憶デバイス、フラッシュメモリデバイス、又は他の不揮発性ソリッドステートメモリデバイスなどの、不揮発性メモリを含む。メモリ１０２は、プロセッサ（単数又は複数）１２２からリモートに位置する１つ以上の記憶デバイスを任意選択的に含む。ＣＰＵ１２２及び周辺機器インタフェース１１８などの、デバイス１００の他の構成要素によるメモリ１０２へのアクセスは、コントローラ１２０により任意選択的に制御される。

周辺機器インタフェース１１８を使用して、本デバイスの入力及び出力周辺機器を、ＣＰＵ１２２及びメモリ１０２に連結することができる。１つ以上のプロセッサ１２２は、デバイス１００のための様々な機能を実行するため並びにデータを処理するために、メモリ１０２に記憶された様々なソフトウェアプログラム及び／若しくは命令セットを動作させる、又は実行する。

一部の実施形態では、周辺機器インタフェース１１８、ＣＰＵ１２２、及びコントローラ１２０は、任意選択的に、チップ１０４などの単一チップ上に実装される。一部の他の実施形態では、これらは、任意選択的に、個別のチップ上に実装される。

ＲＦ（無線周波数）回路１０８は、電磁信号とも呼ばれるＲＦ信号を送受信する。ＲＦ回路１０８は、電気信号を電磁信号に、又は電磁信号を電気信号に変換し、電磁信号を介して通信ネットワーク及び他の通信デバイスと通信する。ＲＦ回路１０８は、アンテナシステム、ＲＦ送受信機、１つ以上の増幅器、同調器、１つ以上の発振器、デジタル信号プロセッサ、ＣＯＤＥＣチップセット、加入者識別モジュール（ＳＩＭ）カード、メモリなどを含むがこれらに限定されない、これらの機能を実行するための周知の回路を、任意選択的に含んでいる。ＲＦ回路１０８は、ワールドワイドウェブ（ＷＷＷ）とも呼ばれるインターネット、イントラネット、並びに／又は、セルラー電話ネットワーク、無線ローカルエリアネットワーク（ＬＡＮ）及び／若しくは、メトロポリタンエリアネットワーク（ＭＡＮ）、などの無線ネットワーク、及び他のデバイスと無線通信によって、任意選択的に通信する。無線通信は、任意選択的に、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）（登録商標）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ＧＳＭ Ｅｎｖｉｒｏｎｍｅｎｔ（ＥＤＧＥ）（登録商標）、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）、高速アップリンクパケットアクセス（ＨＳＵＰＡ）、Ｅｖｏｌｕｔｉｏｎ、Ｄａｔａ－Ｏｎｌｙ（ＥＶ－ＤＯ）、ＨＳＰＡ、ＨＳＰＡ＋、Ｄｕａｌ－Ｃｅｌｌ ＨＳＰＡ（ＤＣ－ＨＳＰＤＡ）、ロングタームエボリューション（ＬＴＥ）、近距離無線通信（ＮＦＣ）、広帯域符号分割多元接続（Ｗ－ＣＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、及び／又はワイヤレスフィデリティ（Ｗｉ－Ｆｉ）（登録商標）（例えば、ＩＥＥＥ８０２．１ ｌａ、ＩＥＥＥ８０２．１ ｌｂ、ＩＥＥＥ８０２．１ ｌｇ、及び／又はＩＥＥＥ８０２．１ｌｎ）を含むが、これらに限定されない複数の通信規格、プロトコル及び技術のいずれかを用いる。

オーディオ回路１１０、スピーカ１１１、及びマイクロフォン１１３は、ユーザとデバイス１００との間のオーディオインタフェースを提供する。オーディオ回路１１０は、周辺機器インタフェース１１８からオーディオデータを受信し、このオーディオデータを電気信号に変換し、この電気信号をスピーカ１１１に送信する。スピーカ１１１は、電気信号を人間の可聴音波に変換する。オーディオ回路１１０は、マイクロフォン１１３により音波から変換された電気信号もまた受信する。オーディオ回路１１０は、電気信号をオーディオデータに変換し、このオーディオデータを処理のために周辺機器インタフェース１１８に送信する。オーディオデータは、周辺機器インタフェース１１８によって任意選択的に、メモリ１０２及び／若しくはＲＦ回路１０８から取り出され、並びに／又はメモリ１０２及び／若しくはＲＦ回路１０８へ送信される。一部の実施形態では、オーディオ回路１１０はヘッドセットジャックを更に備える。ヘッドセットジャックは、オーディオ回路１１０と、出力専用ヘッドホン又は出力（例えば、片耳又は両耳用のヘッドホン）及び入力（例えば、マイクロフォン）の両方を有するヘッドセットなどの、取り外し可能なオーディオ入出力周辺機器と、の間のインタフェースを提供する。

Ｉ／Ｏサブシステム１０６は、周辺機器インタフェース１１８に、タッチスクリーン１１２及び他の入力制御デバイス１１６などのデバイス１００の入出力周辺機器を接続する。Ｉ／Ｏサブシステム１０６は、任意選択的に、ディスプレイコントローラ１５６、光センサコントローラ１５８、強度センサコントローラ１５９、触覚フィードバックコントローラ１６１、及び他の入力若しくは制御デバイスのための１つ以上の入力コントローラ１６０を含む。１つ以上の入力コントローラ１６０は、他の入力又は制御デバイス１１６から電気信号を受信し、それらへ電気信号を送信する。他の入力制御デバイス１１６は、任意選択的に、物理ボタン（例えば、プッシュボタン、ロッカボタンなど）、ダイヤル、スライダスイッチ、ジョイスティック、クリックホイールなどを含む。一部の代替的な実施形態では、入力コントローラ（単数又は複数）１６０は、キーボード、赤外線ポート、ＵＳＢポート、及びマウスなどのポインタデバイスのうちのいずれかに、任意選択的に連結される（又は、いずれにも連結されない）。１つ以上のボタンは、スピーカ１１１及び／又はマイクロフォン１１３の音量調整のためのアップ／ダウンボタンを任意選択的に含む。１つ以上のボタンは、プッシュボタンを任意選択的に含む。

タッチ感知ディスプレイ１１２は、デバイスとユーザとの間の入力インタフェース及び出力インタフェースを提供する。ディスプレイコントローラ１５６は、タッチスクリーン１１２から電気信号を受信し、及び／又はそれへ電気信号を送信する。タッチスクリーン１１２は、ユーザに視覚出力を表示する。視覚出力は、グラフィック、テキスト、アイコン、映像、及びこれらの任意の組み合わせ（総称して「グラフィック」と称する）を任意選択的に含む。一部の実施形態では、視覚出力の一部又は全ては、ユーザインタフェースオブジェクトに対応する。

タッチスクリーン１１２は、触覚及び／若しくは触感の接触に基づくユーザからの入力を受け入れるタッチ感知面、センサ、又はセンサのセットを有する。タッチスクリーン１１２及びディスプレイコントローラ１５６は（メモリ１０２内の任意の関連モジュール及び／又は命令セットと共に）、タッチスクリーン１１２上で接触（及び任意の接触の移動又は中断）を検出し、検出された接触をタッチスクリーン１１２上に表示されたユーザインタフェースオブジェクト（例えば、１つ以上のソフトキー、アイコン、ウェブページ又は画像）との相互作用に変換する。例示的な実施形態では、タッチスクリーン１１２とユーザとの間の接触点は、ユーザの指下のエリアに対応する。

タッチスクリーン１１２は任意選択的に、ＬＣＤ（液晶ディスプレイ）技術、ＬＰＤ（発光ポリマーディスプレイ）技術又はＬＥＤ（発光ダイオード）技術若しくはＯＬＥＤ（有機発光ダイオード）技術を使用するが、他の実施形態では、他のディスプレイ技術が使用される。タッチスクリーン１１２及びディスプレイコントローラ１５６は、静電容量技術、抵抗性技術、赤外線技術、及び表面弾性波技術、並びに、タッチスクリーン１１２との１つ以上の接触点を判定するための他の近接センサアレイ又は他の要素を含むが、これらに限定されない、現在公知の若しくは後日に開発される複数のタッチ感知技術のうちのいずれかを使用して、接触及び接触のあらゆる移動又は中断を任意選択的に検出する。ある実施形態例では、Ｃａｌｉｆｏｒｎｉａ州ＣｕｐｅｒｔｉｎｏのＡＰＰＬＥ Ｉｎｃ．からのＩＰＨＯＮＥ（登録商標）、ＩＰＯＤ ＴＯＵＣＨ（登録商標）、及びＩＰＡＤ（登録商標）などにおいて見られるような、投影された相互キャパシタンス感知技術が使用されている。

タッチスクリーン１１２は、任意選択的に、４００ｄｐｉを超えるビデオ解像度を有する。一部の実施形態では、タッチスクリーン１１２は少なくとも６００ｄｐｉのビデオ解像度を有する。他の実施形態では、タッチスクリーン１１２は少なくとも１０００ｄｐｉのビデオ解像度を有する。ユーザは、スタイラス、指などの任意の好適な物体又は指を使用して、タッチスクリーン１１２と任意選択的に接触する。一部の実施形態では、ユーザインタフェースは、指に基づく接触及びジェスチャにて主に機能するよう設計されている。一部の実施形態では、デバイスは、指に基づく入力を正確なポインタ／カーソル位置又はユーザの望むアクションを実行するためのコマンドに変換する。

一部の実施形態では、タッチスクリーンに加えて、デバイス１００は、特定の機能をアクティブ又は非アクティブにさせるためのタッチパッド（図示せず）を、任意選択的に含む。一部の実施形態では、タッチパッドは、タッチスクリーンとは異なり、視覚出力を表示しない、デバイスのタッチ感知領域である。タッチパッドは、任意選択的に、タッチスクリーン１１２とは別個のタッチ感知面、又はタッチスクリーンによって形成されたタッチ感知面の延長である。

デバイス１００はまた、様々な構成要素に電力を供給するための電力システム１６２も含む。電力システム１６２は、任意選択的に、電力管理システム、１つ以上の電源（例えば、バッテリ、交流（ＡＣ））、再充電システム、停電検出回路、電力コンバータ又はインバータ、電力状態インジケータ（例えば、発光ダイオード（ＬＥＤ））、並びにポータブルデバイス内での電力の生成、管理、及び分配に関連付けられた任意の他の構成要素を含む。

デバイス１００はまた、１つ以上の光センサ１６４を任意選択的に含む。図１Ａは、Ｉ／Ｏサブシステム１０６内の光センサコントローラ１５８に連結された光センサを示す。光センサ１６４は、電荷結合デバイス（ＣＣＤ）又は相補的金属酸化物半導体（ＣＭＯＳ）フォトトランジスタを任意選択的に含む。光センサ１６４は、１つ以上のレンズを通して投影された、環境からの光を受光し、その光を、画像を表現するデータに変換する。撮像モジュール１４３（カメラモジュールとも称する）と併せて、光センサ１６４は、静止画像又は映像を任意選択的にキャプチャする。一部の実施形態では、タッチ感知ディスプレイを静止画像及び／又は映像取得のためのビューファインダとして有効化するように、光センサは、デバイスの前面のタッチスクリーン１１２の反対側である、デバイス１００の背面に配置されている。一部の実施形態では、ユーザがタッチ感知ディスプレイ上で他のテレビ会議参加者を見ている間に、ユーザの画像を、テレビ会議のために任意選択的に、得るように、別の光センサがデバイスの前面に配置される。

デバイス１００はまた、１つ以上の接触強度センサ１６５も任意選択的に含む。図１Ａは、Ｉ／Ｏサブシステム１０６内の強度センサコントローラ１５９に連結された接触強度センサを示す。接触強度センサ１６５は、１つ以上のピエゾ抵抗ひずみゲージ、電気容量式力センサ、電気力センサ、圧電力センサ、光学力センサ、容量式タッチ感知面、又は他の強度センサ（例えば、タッチ感知面上の接触の力（又は圧力）を測定するために使用するセンサ）を、任意選択的に含む。接触強度センサ１６５は、環境から接触強度情報（例えば、圧力情報又は圧力情報の代用物）を受信する。一部の実施形態では、少なくとも１つの接触強度センサが、タッチ感知面（例えば、タッチ感知ディスプレイシステム１１２）に配置されているか、又は、それに近接している。一部の実施形態では、少なくとも１つの接触強度センサが、デバイス１００の前面に配置されたタッチスクリーン１１２の反対側である、デバイス１００の背面に配置されている。

デバイス１００は、１つ以上の近接センサ１６６をも任意選択的に含む。図１Ａは、周辺機器インタフェース１１８と連結された近接センサ１６６を示す。あるいは、近接センサ１６６は、Ｉ／Ｏサブシステム１０６内の入力コントローラ１６０に連結される。一部の実施形態では、多機能デバイスがユーザの耳の近くに配置されている場合（例えば、ユーザが電話通話を行っている場合）、近接センサがオフになり、タッチスクリーン１１２が無効になる。

デバイス１００はまた、１つ以上のタクタイル出力生成器１６７も任意選択的に含む。図１Ａは、Ｉ／Ｏサブシステム１０６内の触覚フィードバックコントローラ１６１に連結されたタクタイル出力生成器を示す。タクタイル出力生成器１６７は、スピーカ又は他のオーディオ構成要素などの１つ以上の電気音響デバイス、及び／又はモータ、ソレノイド、電気活性ポリマー、圧電アクチュエータ、静電アクチュエータ、若しくは他のタクタイル出力生成構成要素（例えば、デバイス上で電気信号をタクタイル出力に変換する構成要素）などの、エネルギを直線運動に変換する電気機械デバイスを、任意選択的に含む。接触強度センサ１６５は、触覚フィードバックモジュール１３３から触覚フィードバック生成命令を受信し、デバイス１００のユーザが感知できるタクタイル出力をデバイス１００上で生成する。一部の実施形態では、少なくとも１つのタクタイル出力生成器は、タッチ感知面（例えば、タッチ感知ディスプレイシステム１１２）に配置されているか、又はそれに近接しており、任意選択的に、タッチ感知面を垂直方向（例えば、デバイス１００の表面の内／外）に、又は横方向（例えば、デバイス１００の表面と同じ平面内の前後）に動かすことによって、タクタイル出力を生成する。一部の実施形態では、少なくとも１つのタクタイル出力生成器センサが、デバイス１００の前面に配置されたタッチ感知ディスプレイ１１２の反対側である、デバイス１００の背面に配置されている。

デバイス１００はまた、１つ以上の加速度計１６８も任意選択的に含む。図１Ａは、周辺機器インタフェース１１８に連結された加速度計１６８を示す。あるいは、加速度計１６８は、Ｉ／Ｏサブシステム１０６内の入力コントローラ１６０に、任意選択的に、連結される。一部の実施形態では、情報は、１つ以上の加速度計から受信したデータの分析に基づいて、縦長表示又は横長表示でタッチ感知ディスプレイ上に表示される。デバイス１００は、加速度計（単数又は複数）１６８に加えて、磁気計（図示せず）並びにデバイス１００の位置及び向き（例えば、縦長又は横長）に関する情報を取得するためのＧＰＳ（又はＧＬＯＮＡＳＳ又は他のグローバルナビゲーションシステム）受信部（図示せず）を任意選択的に含む。

一部の実施形態では、メモリ１０２に記憶されたソフトウェア構成要素は、オペレーティングシステム１２６、プロアクティブモジュール１６３（任意選択的に、１つ以上のアプリケーション使用データテーブル３３５、トリガー条件テーブル４０２、トリガー確立モジュール１６３－１、及び／又は使用データ収集モジュール１６３－２、を含む）、通信モジュール（又は命令セット）１２８、接触／動きモジュール（又は命令セット）１３０、グラフィックモジュール（又は命令セット）１３２、テキスト入力モジュール（又は命令セット）１３４、全地球測位システム（ＧＰＳ）モジュール（又は命令セット）１３５、及びアプリケーション（又は命令セット）１３６を含む。更に、一部の実施形態では、図１Ａに示すように、メモリ１０２はデバイス／グローバル内部状態１５７を記憶する。デバイス／グローバル内部状態１５７は、以下の１つ以上を含む。現在アクティブ状態のアプリケーションがある場合、どのアプリケーションがアクティブかを示す、アクティブアプリケーション状態、どのアプリケーション、ビュー、又は他の情報がタッチ感知ディスプレイ１１２の様々な領域を占有しているかを示す、表示状態、デバイスの様々なセンサ及び入力制御デバイス１１６から得られる情報を含む、センサ状態、及び、デバイスの位置及び／又は姿勢に関する位置情報（例えば、デバイスの向き）。

オペレーティングシステム１２６（例えば、Ｄａｒｗｉｎ（登録商標）、ＲＴＸＣ（登録商標）、ＬＩＮＵＸ（登録商標）、ＵＮＩＸ（登録商標）、ＯＳ Ｘ（登録商標）、ＷＩＮＤＯＷＳ（登録商標）、又はＶｘＷｏｒｋｓ（登録商標）などの組み込みオペレーティングシステム）は、一般的なシステムタスク（例えば、メモリ管理、記憶デバイス制御、電力管理など）を制御及び管理するための様々なソフトウェア構成要素及び／又はドライバを含み、様々なハードウェア構成要素とソフトウェア構成要素との間の通信を容易にする。

通信モジュール１２８は、１つ以上の外部ポート１２４を介して他のデバイスとの通信を容易にし、ＲＦ回路１０８及び／又は外部ポート１２４が受信したデータを処理するための様々なソフトウェア構成要素を含む。外部ポート１２４（例えば、ユニバーサルシリアルバス（ＵＳＢ）、ＦＩＲＥＷＩＲＥ（登録商標）など）は、直接的に、又はネットワーク（例えば、インターネット、無線ＬＡＮなど）を通して間接的に、他のデバイスに連結するように適応している。一部の実施形態では、外部ポートは、ＡＰＰＬＥ Ｉｎｃ．からのＩＰＯＤデバイスの一部の実施形態上にて使用される３０ピンコネクタと同じ、又は類似の、及び／若しくは互換するマルチピン（例えば、３０ピン）コネクタである。他の実施形態では、外部ポートは、ＡＰＰＬＥ Ｉｎｃ．からのＬＩＧＨＴＮＩＮＧコネクタにて使用される８ピンコネクタと同じ、又は類似の、及び／若しくは互換するマルチピン（例えば、８ピン）コネクタである。

接触／動きモジュール１３０は、任意選択的に、（ディスプレイコントローラ１５６と併せて）タッチスクリーン１１２及び他のタッチ感知デバイス（例えば、タッチパッド又は物理クリックホイール）との接触を検出する。接触／動きモジュール１３０は、接触が生じたか否かを判定すること（例えば、指を下ろすイベントを検出すること）、接触の強度（例えば、接触の力若しくは圧力、又は、接触の力若しくは圧力の代替物）を判定すること、接触の移動が存在するか否かを判定し、タッチ感知面を横断する移動を追跡すること（例えば、指をドラッグする１つ以上のイベントを検出すること）、及び接触が停止したか否かを判定すること（例えば、指を上げるイベント又は接触の中断を検出すること）などの、接触の検出に関する様々な動作を実行するための、様々なソフトウェア構成要素を含む。接触／動きモジュール１３０は、タッチ感知面から接触データを受信する。一連の接触データにより表される接触点の移動を判定することは、接触点の速さ（大きさ）、速度（大きさ及び方向）、及び／又は加速度（大きさ及び／又は方向の変化）を判定することを任意選択的に含む。これらの動作は、任意選択的に、単一の接触（例えば、１本の指の接触）又は複数の同時接触（例えば、「マルチタッチ」／複数の指の接触）に適用される。一部の実施形態では、接触／動きモジュール１３０及びディスプレイコントローラ１５６は、タッチパッド上の接触を検出する。

一部の実施形態では、接触／動きモジュール１３０は、ユーザによって動作が実行されたか否かを判定するための（例えば、ユーザがアフォーダンス上で選択したか否か又は「クリック」したか否かを判定するための）、１つ以上の強度閾値のセットを使用する。一部の実施形態では、少なくとも強度閾値のサブセットが、ソフトウェアパラメータに従って判定される（例えば、強度閾値は、特定の物理アクチュエータのアクティブ化閾値によって判定されず、デバイス１００の物理ハードウェアを変更することなく調整し得る）。例えば、トラックパッド又はタッチ感知ディスプレイのマウス「クリック」閾値は、トラックパッド又はタッチ感知ディスプレイのハードウェアを変更することなく広範囲の既定閾値のうちのいずれかに設定することができる。更に、一部の実装では、デバイスのユーザには、（例えば、個々の強度閾値を調整することにより、及び／又は、システムレベルのクリック「強度」パラメータにより、一度に複数の強度閾値を調整することによって）強度閾値のセットのうちの１つ以上を調整するためのソフトウェア設定が提供される。

接触／動きモジュール１３０は任意選択的に、ユーザによるジェスチャ入力を検出する。タッチ感知面上の異なるジェスチャは、異なる接触パターン（例えば、異なる動き、タイミング、及び／又は検出される接触の強度）を有する。従って、ジェスチャは、特定の接触パターンを検出することによって、任意選択的に検出される。例えば、指のタップジェスチャを検出することは、（例えば、アイコンの位置での）指を下ろすイベントを検出し、続いてその指を下ろすイベントと同じ位置（又は、実質的に同じ位置）で指を上げる（リフトオフ）イベントを検出することを含む。別の実施例として、タッチ感知面上での指のスワイプジェスチャを検出することは、指を下ろすイベントを検出し、続いて、１つ以上の、指をドラッグするイベントを検出し、その後、一部の実施形態では、続いて指を上げる（リフトオフ）イベントを検出することを含む。

グラフィックモジュール１３２は、表示されるグラフィックの視覚的効果（例えば、輝度、透明度、彩度、コントラスト、又は他の視覚特性）を変更するための構成要素を含めた、タッチスクリーン１１２又は他のディスプレイ上にグラフィックをレンダリングして表示するための、様々な既知のソフトウェア構成要素を含む。本明細書で使用する時、用語「グラフィック」は、ユーザに対して表示することができる任意のオブジェクトを含み、これらのオブジェクトとしては、テキスト、ウェブページ、アイコン（ソフトキーを含むユーザインタフェースオブジェクトなど）、デジタル画像、ビデオ、アニメーションなどが挙げられるが、これらに限定されない。

一部の実施形態では、グラフィックモジュール１３２は、使用されるグラフィックを表すデータを記憶する。各グラフィックには、対応するコードが、任意選択的に割り当てられる。グラフィックモジュール１３２は、アプリケーションなどから、必要に応じて、座標データ及び他のグラフィック特性データと共に、表示されることとなるグラフィックを指定する１つ以上のコードを受信し、次にディスプレイコントローラ１５６に出力する画面の画像データを生成する。

触覚フィードバックモジュール１３３は、デバイス１００とのユーザ相互作用に応じて、デバイス１００上の１つ以上の場所でタクタイル出力を生成するために、タクタイル出力生成器（単数又は複数）１６７によって使用される命令を生成するための、様々なソフトウェア構成要素を含む。

テキスト入力モジュール１３４は、任意選択的に、グラフィックモジュール１３２の構成要素であり、様々なアプリケーション（例えば、連絡先モジュール１３７、電子メールクライアントモジュール１４０、ＩＭモジュール１４１、ブラウザモジュール１４７、及びテキスト入力を必要とする任意の他のアプリケーション）でテキストを入力するための、ソフトキーボードを提供する。

ＧＰＳモジュール１３５は、デバイスの位置を判定し、この情報を様々なアプリケーションで使用するために、（例えば、位置ベースのダイヤリングで使用するために電話１３８のアプリケーションに、画像／ビデオのメタデータとしてカメラ１４３のアプリケーションに、並びに気象ウィジェット、ローカルなイエローページウィジェット、及びマップ／ナビゲーションウィジェットなどの位置ベースのサービスを提供するアプリケーションに）提供する。

アプリケーション（「ａｐｐｓ」）１３６は任意選択的に以下のモジュール（又は、命令のセット）、又はそれらのサブセット若しくはスーパーセットを含む。
●連絡先モジュール１３７（アドレス帳又は連絡先リストと称されることもある）、
●電話モジュール１３８、
●テレビ会議モジュール１３９、
●電子メールクライアントモジュール１４０、
●インスタントメッセージ（ＩＭ）モジュール１４１、
●ヘルスモジュール１４２、
●静止画像及び／又はビデオ画像用のカメラモジュール１４３、
●画像管理モジュール１４４、
●ブラウザモジュール１４７、
●カレンダーモジュール１４８、
●気象ウィジェット１４９－１、株式ウィジェット１４９－２、計算機ウィジェット１４９－３、アラーム時計ウィジェット１４９－４、辞書ウィジェット１４９－５、及びユーザによって取得された他のウィジェット、並びにユーザ作成ウィジェット１４９－６のうちの１つ以上を任意選択的に含む、ウィジェットモジュール１４９、
●検索モジュール１５１、
●任意選択的にビデオプレーヤモジュール及び音楽プレーヤモジュールから構成される、ビデオ及び音楽プレーヤモジュール１５２、
●メモモジュール１５３、
●地図モジュール１５４、及び／又は
●オンラインビデオモジュール１５５。

任意選択的にメモリ１０２内に記憶される他のアプリケーション１３６の例としては、他のワードプロセッシングアプリケーション、他の画像編集アプリケーション、描画アプリケーション、プレゼンテーションアプリケーション、ウェブサイト作成アプリケーション、ディスクオーサリングアプリケーション、スプレッドシートアプリケーション、ＪＡＶＡ（登録商標）対応アプリケーション、暗号化、デジタル著作権管理、音声認識、ユーザ作成ウィジェットを作るためのウィジェットクリエータモジュール１４９－６、及び音声複製が挙げられる。

タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、連絡先モジュール１３７は、（例えば、メモリ１０２又はメモリ３７０内の連絡先モジュール１３７に記憶される）アドレスブック又は連絡先リストを管理するために任意選択的に用いられ、それには、アドレスブックに名前（単数又は複数）を加えること、アドレス帳から名前（単数又は複数）を削除すること、電話番号（単数又は複数）、メールアドレス（単数又は複数）、住所（単数又は複数）、又は他の情報を名前と関連付けること、画像を名前と関連付けること、名前を分類して並べ替えること、電話番号又は電子メールアドレスを提供して、電話モジュール１３８、テレビ会議モジュール１３９、電子メールモジュール１４０、若しくはＩＭモジュール１４１による通信を開始する及び／又は容易にすること、などが含まれる。

ＲＦ回路１０８、オーディオ回路１１０、スピーカ１１１、マイクロフォン１１３、タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、電話モジュール１３８は、電話番号と対応する一連の文字を入力し、アドレス帳１３７内の１つ以上の電話番号にアクセスし、入力されている電話番号を修正し、対応する電話番号をダイヤルし、会話を遂行し、会話が完了した際に接続を切るか又は電話を切るために任意選択的に使用される。上述のように、無線通信は、複数の通信規格、プロトコル、及び技術のうちのいずれかを任意選択的に使用する。

ＲＦ回路１０８、オーディオ回路１１０、スピーカ１１１、マイクロフォン１１３、タッチスクリーン１１２、ディスプレイコントローラ１５６、光センサ１６４、光センサコントローラ１５８、接触モジュール１３０、グラフィックモジュール１３２、テキスト入力モジュール１３４、連絡先リスト１３７、及び電話モジュール１３８と併せて、テレビ会議モジュール１３９は、ユーザの指示に従って、ユーザと１人以上の他の参加者との間のテレビ会議を開始し、行い、終了するための実行可能命令を含む。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、電子メールクライアントモジュール１４０は、ユーザの指示に応じて、電子メールを作成し、送信し、受信し、管理するための、実行可能命令を含む。画像管理モジュール１４４と併せて、電子メールクライアントモジュール１４０は、カメラモジュール１４３で撮影された静止画像又はビデオ画像を有する電子メールを作成及び送信することを非常に容易にする。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、インスタントメッセージモジュール１４１は、インスタントメッセージに対応する文字列を入力し、入力済みの文字を修正し、対応するインスタントメッセージを送信し（例えば、電話ベースのインスタントメッセージのためのショートメッセージサービス（ＳＭＳ）若しくはマルチメディアメッセージサービス（ＭＭＳ）プロトコルを用いて、又はインターネットベースのインスタントメッセージのためのＸＭＰＰ、ＳＩＭＰＬＥ、若しくはＩＭＰＳを用いて）、インスタントメッセージを受信しその受信したインスタントメッセージを表示するための実行可能命令を含む。一部の実施形態では、送信及び／又は受信されるインスタントメッセージは、任意選択的に、ＭＭＳ及び／又は拡張メッセージサービス（Enhanced Messaging Service、ＥＭＳ）でサポートされるような、グラフィック、写真、オーディオファイル、ビデオファイル、及び／又は他の添付ファイルを含む。本明細書で使用する時、「インスタントメッセージ」とは、電話ベースのメッセージ（例えば、ＳＭＳ又はＭＭＳを使用して送信されるメッセージ）及びインターネットベースのメッセージ（例えば、ＸＭＰＰ、ＳＩＭＰＬＥ、又はＩＭＰＳを使用して送信されるメッセージ）の両方を示す。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、テキスト入力モジュール１３４、ＧＰＳモジュール１３５、地図モジュール１５４、及びビデオ及び音楽プレーヤモジュール１４６と併せて、ヘルスモジュール１４２は、トレーニングを作成したり（例えば、時間、距離、及び／又はカロリー消費目標に関して）、トレーニングセンサ（携帯時計又は歩数計などのスポーツデバイス）と通信したり、トレーニングセンサデータを受信したり、トレーニングを監視するために用いられるセンサを較正したり、トレーニングのための音楽を選択して再生したり、トレーニングデータを表示、記憶、送信したりするための実行可能命令を含む。

タッチスクリーン１１２、ディスプレイコントローラ１５６、光センサ（単数又は複数）１６４、光センサコントローラ１５８、接触モジュール１３０、グラフィックモジュール１３２、及び画像管理モジュール１４４と併せて、カメラモジュール１４３は、静止画像又はビデオ（ビデオストリームを含む）をキャプチャしてメモリ１０２にそれらを記憶する、静止画像又はビデオの特徴を変更する、又はメモリ１０２から静止画像若しくはビデオを削除するための実行可能命令を含む。

タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィクモジュール１３２、テキスト入力モジュール１３４、及びカメラモジュール１４３と併せて、画像管理モジュール１４４は、静止画像及び／又はビデオ画像を配置したり、修正したり（例えば、編集し）又は別の方法で操作したり、ラベルを付けたり、削除し、提示し（例えば、デジタルスライドショー又はアルバム内で）、並びに記憶するための実行可能命令を含む。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、ブラウザモジュール１４７は、ウェブページ又はそれらの一部、並びにウェブページにリンクされた添付及び他のファイルを検索し、リンク付けし、受信し、表示することを含むユーザの指示に従い、インターネットをブラウズするための実行可能命令を含む。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、テキスト入力モジュール１３４、電子メールクライアントモジュール１４０、及びブラウザモジュール１４７と併せて、カレンダーモジュール１４８は、ユーザの指示に従い、カレンダー及びカレンダーに関連付けられたデータ（例えば、カレンダーアイテム、ＴｏＤｏリストなど）を作成し、表示し、変更し、記憶するための実行可能命令を含む。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、テキスト入力モジュール１３４、及びブラウザモジュール１４７と併せて、ウィジェットモジュール１４９は、ユーザによって任意選択的にダウンロードされて使用されるミニアプリケーション（例えば、気象ウィジェット１４９－１、株式ウィジェット１４９－２、計算機ウィジェット１４９－３、アラーム時計ウィジェット１４９－４、及び辞書ウィジェット１４９－５）、又はユーザによって作成されるミニアプリケーション（例えば、ユーザ作成ウィジェット１４９－６）である。一部の実施形態では、ウィジェットは、ＨＴＭＬ（ハイパーテキストマークアップ言語）ファイル、ＣＳＳ（カスケーディングスタイルシート）ファイル、及びＪａｖａＳｃｒｉｐｔ（登録商標）ファイルを含む。一部の実施形態では、ウィジェットは、ＸＭＬ（拡張可能マークアップ言語）ファイル及びＪａｖａＳｃｒｉｐｔファイル（例えば、Ｙａｈｏｏ！（登録商標）ウィジェット）を含む。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、テキスト入力モジュール１３４、及びブラウザモジュール１４７と併せて、ウィジェットクリエータモジュール（図示せず）は、ウィジェットを作成する（例えば、ウェブページのユーザ指定箇所をウィジェットに変える）ために、ユーザによって任意選択的に使用される。

タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、検索モジュール１５１は、ユーザの指示に従い、１つ以上の検索基準（例えば、１つ以上のユーザ指定の検索語句）と一致する、メモリ１０２内のテキスト、音楽、音、画像、ビデオ、及び／又は他のファイルを検索するための実行可能命令を含む。一部の実施形態では、検索モジュール１５１は、検索エントリ部分及び予測部分を表示するための実行可能命令を更に含む（例えば、図９Ｂ及び、図６Ａ～９Ｃに関連して以下に詳述する検索エントリ部分９２０及び予測部分９３０）。一部の実施形態では、検索モジュール１５１はまた、プロアクティブモジュール１６３と併せて、検索エントリ部分にてユーザ入力を受信する前に、予測部分を、提案された又は予測された人、アプリケーション内のアクション、アプリケーション、近隣の場所、及び／又はニュース記事に対するアフォーダンスでポピュレートする（図３Ａ～９Ｃに関連して以下に詳述するように）。

タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィクモジュール１３２、オーディオ回路１１０、スピーカ１１１、ＲＦ回路１０８、及びブラウザモジュール１４７と併せて、ビデオ及び音楽プレーヤモジュール１５２は、ＭＰ３又はＡＡＣファイルなどの１つ以上のファイル形式で記憶された録音済みの音楽又は他のサウンドファイルをユーザがダウンロード及び再生できるようにする実行可能命令、並びに、ビデオを（例えば、タッチスクリーン１１２上又は外部ポート１２４を介して接続された外部のディスプレイ上に）表示、提示、又は別の方法で再生するための実行可能命令を含む。一部の実施形態では、デバイス１００は、任意選択的に、ＡＰＰＬＥ Ｉｎｃ．からのＩＰＯＤ（登録商標）などのＭＰ３プレーヤの機能を備える。

タッチスクリーン１１２、ディスプレイコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、及びテキスト入力モジュール１３４と併せて、メモモジュール１５３は、ユーザの指示に従って、メモ、ＴｏＤｏリストなどを作成及び管理するための実行可能命令を含む。

ＲＦ回路１０８、タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、テキスト入力モジュール１３４、ＧＰＳモジュール１３５、及びブラウザモジュール１４７と併せて、地図モジュール１５４は任意選択的に、ユーザの指示に従って、地図及び地図に関連付けられたデータ（例えば、運転指示、特定の場所若しくはその付近の店舗及び関心対象の他の地点についてのデータ、並びに場所に基づく他のデータ）を受信し、表示し、修正し、記憶するために使用することができる。

タッチスクリーン１１２、ディスプレイシステムコントローラ１５６、接触モジュール１３０、グラフィックモジュール１３２、オーディオ回路１１０、スピーカ１１１、ＲＦ回路１０８、テキスト入力モジュール１３４、電子メールクライアントモジュール１４０、及びブラウザモジュール１４７と併せて、オンラインビデオモジュール１５５は、ユーザがＨ．２６４などの１つ以上のファイル形式のオンラインビデオにアクセスし、ブラウズし、受信し（例えば、ストリーミング及び／又はダウンロードにより）、再生し（例えば、タッチスクリーン上で又は外部ポート１２４を介して接続された外部のディスプレイ上で）、特定のオンラインビデオへのリンクを含む電子メールを送信し、別の方法で管理できるようにする命令を含む。一部の実施形態では、特定のオンラインビデオへのリンクを送信するために、電子メールクライアントモジュール１４０ではなく、インスタントメッセージモジュール１４１が用いられる。

図１Ａに示すように、ポータブル多機能デバイス１００はまた、関連コンテンツを先見的に特定し、表面化（例えば、アプリケーション内のアクションに対応するユーザインタフェースオブジェクト（例えば、音楽ａｐｐ内のプレイリストを再生するためのＵＩオブジェクト）を、ロックスクリーンに、又は検索インタフェース内に表面化）させるためのプロアクティブモジュール１６３も含む。プロアクティブモジュール１６３は任意選択的に以下のモジュール（又は命令のセット）、又はサブセット又はスーパーセットを含む。
●アプリケーション使用テーブル３３５
●トリガー条件テーブル４０２
●トリガー確立モジュール１６３－１
●使用データ収集モジュール１６３－２
●プロアクティブ提案モジュール１６３－３
●（音声通信）コンテンツ抽出モジュール１６３－４

アプリケーション１３６、ＧＰＳモジュール１３５、オペレーティングシステム１２６、Ｉ／Ｏサブシステム１０６、ＲＦ回路１０８、外部ポート１２４、近接センサ１６６、オーディオ回路１１０、加速度計１６８、スピーカ１１１、マイクロフォン１１３、及び周辺機器インタフェース１１８と併せて、アプリケーション使用テーブル３３５及び使用データ収集モジュール１６３－２は、アプリケーション使用データを（例えば、上の図１Ａに特定されるデバイス１００の構成要素から）受信及び／又は記憶する。一部の実施形態では、アプリケーションの使用は、使用データ収集モジュール１６３－２に報告され、続いてアプリケーション使用テーブル３３５に記憶される。一部の実施形態では、アプリケーション使用データは、特定のアプリケーション１３６のユーザの使用に対応する全ての（又は、最も重要な、関連する、若しくは予測する）コンテキスト使用情報を含む。一部の実施形態では、各特定のアプリケーションは、ユーザがそのアプリケーションと相互作用している間に、使用データを記憶し、その使用データは続いて、記憶のためにアプリケーション使用データテーブル３３５に報告される（例えば、図３Ｂの、特定のアプリケーション１３６－１に対する使用データ１９３は、全てのセンサの読み値、実行されたアプリケーション内アクション、デバイス連結情報などを含み、この使用データ１９３は、テーブル内の記録としての記憶のために、アプリケーション使用テーブル３３５に送信される）。例えば、ユーザがブラウザモジュール１４７と相互作用する間に、アプリケーション使用データは、アプリケーション使用テーブル３３５により受信され、記憶された他のセンサデータ及び他のコンテキスト使用情報の中で、デバイス１００の現在のＧＰＳ座標（例えば、ＧＰＳモジュール１３５により判定される）、動きデータ（例えば、加速度計１６８により判定される）、環境光データ（例えば、光センサ１６４により判定される）、及びブラウザモジュール１４７内にてユーザによって実行されるアプリケーション内アクション（例えば、訪問先ＵＲＬ、訪問した各ページの閲覧時間量）、を含む全てのコンテキスト使用情報を受信し、記憶する。アプリケーション使用テーブル３３５に関する追加情報は、図３Ａ～３Ｂに関連して以下に提供される。図５に関連して以下に説明するように、一部の実施形態では、アプリケーション使用データはリモートに（例えば、図５の１つ以上のサーバ５０２に）記憶される。

トリガー条件テーブル４０２及びトリガー確立モジュール１６３－１は、アプリケーション使用テーブル３３５に記憶された使用データに基づいて確立されたトリガー条件を受信及び／又は記憶する。一部の実施形態では、トリガー確立モジュール１６３－１は、パターンを特定するために、アプリケーション使用テーブル３３５に記憶されたデータをマイニングし、分析する。例えば、ユーザが毎日、午後３：００と午後４：００の間に音楽アプリケーションをいつも起動することをアプリケーション使用データが示す場合、続いてトリガー確立モジュール１６３－１は、満たされると（例えば、現在時刻が、午後３：００から午後４：００の所定の時間量内であると）、デバイス１００に音楽アプリケーションを起動させる（又は、少なくとも、音楽アプリケーションが利用可能であることのインジケーションをユーザに提供する（例えば、ユーザが音楽アプリケーションに容易にアクセスできるＵＩオブジェクトをロックスクリーン上に表示する））トリガー条件を作成し、トリガー条件テーブル４０２に記憶する。トリガー条件テーブル４０２に関する追加情報は、図４Ａ～４Ｂに関連して以下に提供される。図５に関連して以下に説明するように、一部の実施形態では、パターンの特定、及びその特定されたパターンに基づくトリガー条件の確立は、リモートサーバにて（例えば、図５の１つ以上のサーバ５０２にて）行われる。

プロアクティブ提案モジュール１６３－３は、デバイス１００の他の構成要素と併せて機能し、電子デバイス上で利用可能な様々な異なるアプリケーションでの使用のために、コンテンツをユーザに先見的に提供する。例えば、プロアクティブ提案モジュール１６３－３は、検索インタフェース内の含有のために、提案された検索クエリ及び他の提案されたコンテンツを提供し（例えば、図１０Ａ～１０Ｃに関連して以下に説明するように）、駐車した車の位置を特定するためにユーザを補助する情報を提供し（例えば、図１４を参照して以下に説明するように）、近隣の対象地点についての情報を提供し（例えば、図１６Ａ～１６Ｂに関連して以下に説明するように）、音声通信中に提供されたスピーチから抽出されたコンテンツアイテムを提供し（例えば、図１８Ａ～１８Ｂに関連して以下に説明するように）、及び、多くの他の提案を提供することを補助し（例えば、図２０、２１Ａ～２１Ｂ、２４Ａ～２４Ｂ、２６Ａ～２６Ｂ、２７、及び２９に関連して以下に説明するように）、これは、最小の入力数以下にて所望するコンテンツに効率よくたどり着くようユーザを補助する（例えば、そのコンテンツを検索することなく、プロアクティブ提案モジュール１６３－３は、コンテンツが、ユーザによる選択のために適切な時間に確実に提供されるよう補助する）。

（音声通信）コンテンツ抽出モジュール１６３－４は、デバイス１００の他の構成要素と併せて機能し、新たなコンテンツアイテムに関するスピーチを特定し、新たなコンテンツアイテムを音声通信から抽出する（例えば、図１８Ａ～１８Ｂ及び２０に関連して以下に詳述するように、連絡先情報、イベントについての情報、及び位置についての情報）。

上記で特定されたモジュール及びアプリケーションのそれぞれは、１つ以上の上記の機能を実行する実行可能な命令セット及び本出願に記載の方法（例えば、コンピュータにより実行される方法及び本明細書に記載の他の情報処理方法）に対応する。これらのモジュール（例えば、命令セット）は、別個のソフトウェアプログラム、手順、又はモジュールとして実装される必要はなく、従って、これらのモジュールの様々なサブセットは、様々な実施形態において任意選択的に、組み合わせ、又は再配置される。一部の実施形態では、メモリ１０２は、上述の識別されたモジュール及びデータ構造のサブセットを任意選択的に記憶する。更に、メモリ１０２は、上述されていない追加のモジュール及びデータ構造を任意選択的に記憶する。

一部の実施形態では、デバイス１００は、デバイス上の機能の所定のセットの動作が排他的にタッチスクリーン及び／又はタッチパッドを介して実行されるデバイスである。デバイス１００の動作のための主要入力制御デバイスとしてタッチスクリーン及び／又はタッチパッドを使用することにより、デバイス１００上の物理的な入力制御デバイス（プッシュボタン、ダイヤル、など）の数を、任意選択的に低減する。

排他的にタッチスクリーン及び／又はタッチパッドを介して実行される、所定の機能のセットは、任意選択的に、ユーザインタフェース間のナビゲーションを含む。一部の実施形態では、タッチパッドは、ユーザによってタッチされると、デバイス１００上に表示される任意のユーザインタフェースから、メインメニュー、ホームメニュー、又はルートメニューへデバイス１００をナビゲートする。そのような実施形態では、「メニューボタン」はタッチパッドを使って実装される。一部の他の実施形態では、メニューボタンは、タッチパッドの代わりに、物理プッシュボタン又は他の物理入力制御デバイスである。

図１Ｂは、一部の実施形態に係る、イベント処理のための構成要素例を示すブロック図である。一部の実施形態では、メモリ１０２（図１Ａ内）は、イベントソート部１７０（例えば、オペレーティングシステム１２６内）と、ポータブル多機能デバイス１００（図１Ａ）のアプリケーション１３６から選択された、対応するアプリケーション１３６－１（例えば、アプリケーション１３６と共にメモリ１０２内に記憶された前述のアプリケーションのいずれか）と、を含む。

イベントソート部１７０は、イベント情報を受信し、イベント情報が配信されるアプリケーション１３６－１及びアプリケーション１３６－１のアプリケーションビュー１９１を決定する。イベントソート部１７０は、イベントモニタ１７１及びイベントディスパッチャモジュール１７４を含む。一部の実施形態では、アプリケーション１３６－１は、アプリケーションがアクティブ又は実行中の時、タッチ感知ディスプレイ１１２上に表示される現在のアプリケーションビュー（単数又は複数）を示す、アプリケーション内部状態１９２を含む。一部の実施形態では、デバイス／グローバル内部状態１５７は、いずれのアプリケーションが現在アクティブであるかを判定するために、イベントソート部１７０によって使用され、アプリケーション内部状態１９２は、イベント情報が配信されるアプリケーションビュー１９１を決定するために、イベントソート部１７０によって使用される。

一部の実施形態では、アプリケーション内部状態１９２は、アプリケーション１３６－１が実行を再開する際に使用される再開情報、アプリケーション１３６－１によって情報が表示されているか又は表示の準備が整っていることを示すユーザインタフェース状態情報、ユーザがアプリケーション１３６－１の以前の状態又はビューに戻ることを可能にするための状態待ち行列、及びユーザが以前に行ったアクションのリドゥ／アンドゥ待ち行列、のうちの１つ以上などの追加情報を含む。

イベントモニタ１７１は、周辺機器インタフェース１１８からイベント情報を受信する。イベント情報は、サブイベント（例えば、マルチタッチジェスチャの一部としての、タッチ感知ディスプレイ１１２上のユーザタッチ）についての情報を含む。周辺機器インタフェース１１８は、Ｉ／Ｏサブシステム１０６、又は近接センサ１６６、加速度計（単数又は複数）１６８、及び／若しくは（オーディオ回路１１０を介する）マイクロフォン１１３などのセンサから受信する情報を送信する。周辺機器インタフェース１１８がＩ／Ｏサブシステム１０６から受信する情報には、タッチ感知ディスプレイ１１２又はタッチ感知面からの情報が含まれる。

一部の実施形態では、イベントモニタ１７１は、所定の間隔で周辺機器インタフェース１１８に要求を送信する。これに応じて、周辺機器インタフェース１１８はイベント情報を送信する。他の実施形態では、周辺機器インタフェース１１８は、重要なイベント（例えば、所定のノイズ閾値を上回り、かつ／又は所定の持続時間を超えた入力を受けること）が存在する場合にのみ、イベント情報を送信する。

一部の実施形態では、イベントソート部１７０はまた、ヒットビュー判定モジュール１７２及び／又はアクティブイベント認識部判定モジュール１７３も含む。

ヒットビュー判定モジュール１７２は、タッチ感知ディスプレイ１１２が２つ以上のビューを表示した際に、１つ以上のビュー内のどこにおいてサブイベントが発生したかを判定するためのソフトウェア手続きを提供する。ビューは、制御部及びユーザがディスプレイ上で見ることが可能な他の要素で構成される。

アプリケーションに関連付けられたユーザインタフェースの別の態様は、本明細書では、アプリケーションビュー又はユーザインタフェースウィンドウと呼ばれる場合があるビューのセットであり、それらの中で情報が表示され、タッチに基づくジェスチャが生じる。タッチが検出される（それぞれのアプリケーションの）アプリケーションビューは、アプリケーションのプログラム階層又はビュー階層内のプログラムレベルに任意選択的に、対応する。例えば、タッチが検出される最低レベルのビューは任意選択的に、ヒットビューと呼ばれ、適切な入力として認識されるイベントのセットは、少なくとも部分的に、タッチベースのジェスチャを開始する最初のタッチのヒットビューに基づいて任意選択的に、判定される。

ヒットビュー判定モジュール１７２は、タッチベースのジェスチャのサブイベントと関連付けられた情報を受信する。アプリケーションが、階層として編成された複数のビューを有する場合、ヒットビュー判定モジュール１７２は、そのサブイベントを処理すべき階層内の最下位のビューとしての、ヒットビューを特定する。ほとんどの状況では、ヒットビューは、最初のサブイベント（例えば、イベント又は潜在的なイベントを形成するサブイベントのシーケンスにおける最初のサブイベント）が発生する最下位レベルのビューである。ヒットビューがヒットビュー判定モジュールによって特定されると、ヒットビューは、典型的には、それがヒットビューとして特定された、同じタッチ又は入力ソースに関連する全てのサブイベントを受信する。

アクティブイベント認識部判定モジュール１７３は、ビュー階層内のどのビュー（単数又は複数）がサブイベントの特定のシーケンスを受信すべきかを判定する。一部の実施形態では、アクティブイベント認識部判定モジュール１７３は、ヒットビューのみがサブイベントの特定のシーケンスを受信すべきであると判定する。他の実施形態では、アクティブイベント認識部判定モジュール１７３は、サブイベントの物理的位置を含む全てのビューはアクティブに関わっているビューであると判定し、従って、全てのアクティブに関わっているビューは、サブイベントの特定のシーケンスを受信すべきであると判定する。他の実施形態では、タッチサブイベントがある特定のビューに関連付けられた領域に完全に限定されたとしても、階層の上位のビューは、依然としてアクティブに関わっているビューであり続ける。

イベントディスパッチャモジュール１７４は、イベント情報をイベント認識部（例えば、イベント認識部１８０）に送信する。アクティブイベント認識部判定モジュール１７３を含む実施形態では、イベントディスパッチャモジュール１７４は、アクティブイベント認識部判定モジュール１７３により判定されたイベント認識部にイベント情報を配信する。一部の実施形態では、イベントディスパッチャモジュール１７４は、対応するイベント受信部１８２により取り出されるイベント情報をイベント待ち行列に記憶する。

一部の実施形態では、オペレーティングシステム１２６は、イベントソート部１７０を含む。あるいは、アプリケーション１３６－１が、イベントソート部１７０を含む。更に他の実施形態では、イベントソート部１７０は、独立型のモジュール、又は接触／動きモジュール１３０などの、メモリ１０２に記憶された別のモジュールの一部である。

一部の実施形態では、アプリケーション１３６－１は、それぞれがアプリケーションのユーザインタフェースのそれぞれのビュー内で発生するタッチイベントを処理する命令を含む、複数のイベント処理部１９０及び１つ以上のアプリケーションビュー１９１を含む。アプリケーション１３６－１の各アプリケーションビュー１９１は、１つ以上のイベント認識部１８０を含む。通常は、それぞれのアプリケーションビュー１９１に複数のイベント認識部１８０が含まれる。他の実施形態では、イベント認識部１８０のうちの１つ以上は、ユーザインタフェースキット（図示せず）又はアプリケーション１３６－１が方法及び他の特性を継承する上位レベルのオブジェクトなどの、別個のモジュールの一部である。一部の実施形態では、それぞれのイベント処理部１９０は、データ更新部１７６、オブジェクト更新部１７７、ＧＵＩ更新部１７８、及び／又はイベントソート部１７０から受信したイベントデータ１７９、のうちの１つ以上を含む。イベント処理部１９０は、アプリケーション内部状態１９２を更新するために、データ更新部１７６、オブジェクト更新部１７７、又はＧＵＩ更新部１７８を任意選択的に、利用若しくは呼び出す。あるいは、アプリケーションビュー１９１のうちの１つ以上は、１つ以上の対応するイベント処理部１９０を含んでいる。また、一部の実施形態では、データ更新部１７６、オブジェクト更新部１７７、及びＧＵＩ更新部１７８のうちの１つ以上は、対応するアプリケーションビュー１９１に含まれる。

対応するイベント認識部１８０は、イベントソート部１７０からイベント情報（例えば、イベントデータ１７９）を受信して、そのイベント情報からイベントを特定する。イベント認識部１８０は、イベント受信部１８２及びイベント比較部１８４を含む。一部の実施形態では、イベント認識部１８０は更に、メタデータ１８３及びイベント配信命令１８８（任意選択的に、サブイベント配信命令を含む）の少なくともサブセットを含む。

イベント受信部１８２は、イベントソート部１７０からイベント情報を受信する。このイベント情報は、サブイベントについての情報、例えば、タッチ又はタッチの動きについての情報を含む。サブイベントによっては、イベント情報はまた、サブイベントの場所などの追加情報も含む。サブイベントが、タッチの動きに関わる時、イベント情報は、サブイベントの速度及び方向を任意選択的に、更に含む。一部の実施形態では、イベントは、１つの向きから別の向きへの（例えば、縦向きから横向きへの、又はその逆の）デバイスの回転を含み、そのイベント情報は、デバイスの現在の向き（デバイスの姿勢とも呼ばれる）についての対応する情報を含む。

イベント比較部１８４は、イベント情報を所定のイベント又はサブイベントの定義と比較し、その比較に基づいて、イベント又はサブイベントを判定する、あるいはイベント又はサブイベントの状態を判定若しくは更新する。一部の実施形態では、イベント比較部１８４は、イベント定義１８６を含む。イベント定義１８６は、例えば、イベント１（１８７－１）、イベント２（１８７－２）などの、イベントの定義（例えば、サブイベントの所定のシーケンス）を含む。一部の実施形態では、イベント１８７内のサブイベントは、例えば、タッチ開始、タッチ終了、タッチの移動、タッチの取り消し、及び複数のタッチを含む。ある実施例では、イベント１（１８７－１）の定義は、表示されたオブジェクト上のダブルタップである。ダブルタップは、例えば、表示されたオブジェクト上の所定の段階についての第１のタッチ（タッチ開始）、所定の段階についての第１のリフトオフ（タッチ終了）、表示されたオブジェクト上の所定の段階についての第２のタッチ（タッチ開始）、及び所定の段階についての第２のリフトオフ（タッチ終了）を含む。別の実施例では、イベント２（１８７－２）の定義は、表示されたオブジェクト上のドラッグ操作である。ドラッグは、例えば、表示されたオブジェクト上の所定の段階についてのタッチ（又は接触）、タッチ感知ディスプレイ１１２にわたるタッチの動き、及びタッチのリフトオフ（タッチ終了）を含む。一部の実施形態では、イベントはまた、１つ以上の関連付けられたイベント処理部１９０に関する情報も含む。

一部の実施形態では、イベント定義１８６は、各ユーザインタフェースオブジェクトに関するイベントの定義を含む。一部の実施形態では、イベント比較部１８４は、サブイベントに関連付けられたユーザインタフェースオブジェクトを判定するヒットテストを実行する。例えば、３つのユーザインタフェースオブジェクトがタッチ感知ディスプレイ１１２に表示されるアプリケーションビューにおいて、タッチ感知ディスプレイ１１２上でタッチが検出されると、イベント比較部１８４は、３つのユーザインタフェースオブジェクトのうちのどれがタッチ（サブイベント）に関連付けられたかを判定するためのヒットテストを実行する。表示された各オブジェクトが、対応するイベント処理部１９０に関連付けられた場合、イベント比較部は、ヒットテストの結果を用いて、どのイベント処理部１９０をアクティブにすべきかを判定する。例えば、イベント比較部１８４は、サブイベント及びヒットテストのトリガーとなるオブジェクトに関連付けられたイベント処理部を選択する。

一部の実施形態では、各イベント１８７の定義は、サブイベントのシーケンスが、イベント認識部のイベントタイプに対応するか対応しないかが判定されるまで、イベント情報の配信を遅延させる遅延作用も含む。

それぞれのイベント認識部１８０が、一連のサブイベントがイベント定義１８６のイベントのいずれかとも一致しないと判定した場合、それぞれのイベント認識部１８０は、イベント不可能、イベント失敗、又はイベント終了の状態に移行し、その後は、タッチに基づくジェスチャの次のサブイベントを無視する。この状況では、ヒットビューに関してアクティブのまま維持される他のイベント認識部があれば、進行中のタッチに基づくジェスチャのサブイベントを、引き続き追跡及び処理する。

一部の実施形態では、それぞれのイベント認識部１８０は、構成変更可能なプロパティと、フラグと、及び／又はイベント配信システムがアクティブに関わっているイベント認識部にどのようにサブイベント配信を実行するかについて示すリストと、を有するメタデータ１８３を含む。一部の実施形態では、メタデータ１８３は、構成変更可能なプロパティと、フラグと、及び／又はイベント認識部が互いにどのように相互作用し得るか又は相互作用が可能になるかについて示すリストと、を含む。一部の実施形態では、メタデータ１８３は、構成変更可能なプロパティと、フラグと、及び／又はサブイベントがビュー階層又はプログラム階層内の様々なレベルに配信されるか否かを示すリストと、を含む。

一部の実施形態では、それぞれのイベント認識部１８０は、イベントの１つ以上の特定のサブイベントが認識された時に、イベントに関連付けられたイベント処理部１９０をアクティブにする。一部の実施形態では、それぞれのイベント認識部１８０は、イベントに関連付けられたイベント情報をイベント処理部１９０に配信する。イベント処理部１９０をアクティブにすることは、対応するヒットビューにサブイベントを送信（及び送信を延期する）することとは異なる。一部の実施形態では、イベント認識部１８０は、認識されたイベントに関連付けられたフラグをスローし、フラグに関連付けられたイベント処理部１９０は、フラグをキャッチし、所定の処理を実行する。

一部の実施形態では、イベント配信命令１８８は、イベント処理部をアクティブにせずに、サブイベントに関するイベント情報を配信するサブイベント配信命令を含む。その代わりに、サブイベント配信命令は、一連のサブイベントに関連付けられたイベント処理部又はアクティブに関わっているビューにイベント情報を配信する。一連のサブイベント又はアクティブに関わっているビューに関連付けられたイベント処理部は、イベント情報を受信し、所定の処理を実行する。

一部の実施形態では、データ更新部１７６は、アプリケーション１３６－１で使用されるデータを作成及び更新する。例えば、データ更新部１７６は、連絡先モジュール１３７で使用される電話番号を更新、又はビデオ及び音楽プレーヤモジュール１４５で使用されるビデオファイルを記憶する。一部の実施形態では、オブジェクト更新部１７７は、アプリケーション１３６－１で使用されるオブジェクトを作成及び更新する。例えば、オブジェクト更新部１７６は、新たなユーザインタフェースオブジェクトを作成するか、又はユーザインタフェースオブジェクトの位置を更新する。ＧＵＩ更新部１７８は、ＧＵＩを更新する。例えば、ＧＵＩ更新部１７８は、表示情報を準備し、タッチ感知ディスプレイ上に表示するために表示情報をグラフィックモジュール１３２に送る。

一部の実施形態では、イベント処理部（単数又は複数）１９０は、データ更新部１７６、オブジェクト更新部１７７、及びＧＵＩ更新部１７８を含むか、若しくはそれらにアクセスすることができる。一部の実施形態では、データ更新部１７６、オブジェクト更新部１７７、及びＧＵＩ更新部１７８は、対応するアプリケーション１３６－１又はアプリケーションビュー１９１の単一モジュールに含まれる。他の実施形態では、それらは、２つ以上のソフトウェアモジュールに含まれる。

一部の実施形態では、各特定のアプリケーション１３６－１は、ユーザがそのアプリケーションと相互作用する間に、使用データを記憶し、その使用データは続いて、記憶のためにアプリケーション使用データテーブル３３５に報告される（例えば、図３Ｂの、特定のアプリケーション１３６－１に対する使用データ１９３は、全てのセンサの読み値、実行されたアプリケーション内アクション、デバイス連結情報などを含み、この使用データ１９３は、テーブル内の記録としての記憶のために、特定のアプリケーションのための、対応するアプリケーション使用テーブル３３５に送信される）。一部の実施形態では、使用データ１９３は、特定のアプリケーション１３６－１の使用（例えば、ユーザは特定のアプリケーション１３６－１と能動的に相互作用している）中に、使用データ収集モジュール１６３－２により報告されたものとしてデータを記憶する。

タッチ感知ディスプレイ上のユーザのタッチのイベント処理に関する前述の論考はまた、入力デバイスを使用して多機能デバイス１００を動作させるための他の形態のユーザ入力にも適用されるが、その全てがタッチスクリーン上で開始されるわけではないことが理解されよう。例えば、単一又は複数のキーボードの押下又は保持に任意選択的に合わせたマウスの移動及びマウスボタンの押下、タッチパッド上でのタップ、ドラッグ、スクロールなどの接触移動、ペンスタイラス入力、デバイスの移動、口頭による指示、検出された眼球運動、バイオメトリック入力、及び／又はこれらの任意の組み合わせが、認識対象のイベントを定義するサブイベントに対応する入力として任意選択的に利用される。

図１Ｃは、一部の実施形態に係る、タッチ感知ディスプレイ（例えば、タッチスクリーン１１２）を有するポータブル多機能デバイス（例えば、ポータブル多機能デバイス１００）の概要である。この実施形態では、後述する他の実施形態と同様に、ユーザは、例えば、１本以上の指又は１つ以上のスタイラスを用いて、スクリーン上でジェスチャを行うことにより、グラフィックのうちの１つ以上を選択し得る。一部の実施形態では、１つ以上のグラフィックの選択は、ユーザが１つ以上のグラフィックとの接触を断つと生じる（例えば、指をスクリーンから離すことにより）。一部の実施形態では、ジェスチャは、１回以上のタップジェスチャ（例えば、スクリーン上での一連のタッチの後に指を離す）、１回以上のスワイプジェスチャ（スクリーンの表面に沿う、ジェスチャ中の連続する接触、例えば、左から右へ、右から左へ、上方向へ、及び／又は下方向へ）、及び／又は、デバイス１００と接触した指のローリング（例えば、右から左へ、左から右へ、上方向へ、及び／又は下方向へ）を、任意選択的に含む。一部の実装又は状況では、グラフィックとの不測の接触は、そのグラフィックを選択するものではない。例えば、アプリケーションを起動するためのジェスチャがタップジェスチャである場合、アプリケーションアフォーダンス（例えば、アイコン）上をスワイプするスワイプジェスチャは、対応するアプリケーションを任意選択的に起動しない（例えば、開かない）。

デバイス１００はまた、「ホーム」又はメニューボタン２０４などの、１つ以上の物理ボタンも任意選択的に含む。前述のように、メニューボタン２０４は、デバイス１００上で任意選択的に、実行するアプリケーションのセット内の任意のアプリケーション１３６へのナビゲーションに任意選択的に、使用される。あるいは、一部の実施形態では、メニューボタンは、タッチスクリーン１１２に表示されたＧＵＩにおけるソフトキーとして実装されている。

ある実施形態では、デバイス１００は、タッチスクリーン１１２、メニューボタン２０４、デバイスへの電源をオン／オフしてデバイスをロックするためのプッシュボタン２０６、音量調整ボタン（単数又は複数）２０８、加入者識別モジュール（ＳＩＭ）カードスロット２１０、ヘッドセットジャック２１２、及びドッキング／充電用外部ポート１２４を含む。プッシュボタン２０６は、任意選択的に、ボタンを押し下げて、所定の時間にわたってボタンを押し下げた状態で保持することによって、デバイス上にて電源をオン／オフし、ボタンを押し下げて、所定の時間が経過する前にボタンを解放することによってデバイスをロックし、及び／又は、デバイスのロックを解除する、若しくは、ロック解除処理を開始する。別の実施形態では、デバイス１００はまた、マイクロフォン１１３を通して、一部の機能をアクティブ又は非アクティブにするための口頭入力を受け入れる。デバイス１００はまた、タッチスクリーン１１２上の接触の強度を検出するための１つ以上の接触強度センサ１６５、及び／又は、デバイス１００のユーザに対するタクタイル出力を生成するための１つ以上のタクタイル出力生成器１６７も、任意選択的に含む。

図１Ｄは、ディスプレイ１９４（例えば、タッチスクリーン１１２）とは別個のタッチ感知面１９５（例えば、タブレット又はタッチパッド）を備えるデバイス（例えば、図１Ａのデバイス１００）上のユーザインタフェースを示すために使用される概要である。一部の実施形態では、タッチ感知面１９５は、タッチ感知面１９５上の接触の強度を検出するための１つ以上の接触強度センサ（例えば、接触強度センサ（単数又は複数）３５９のうちの１つ以上）及び／又はタッチ感知面１９５のユーザに対してタクタイル出力を生成するための１つ以上のタクタイル出力生成器（単数又は複数）３５７を含む。

以下の実施例のうちの一部はタッチスクリーン１１２上での入力（タッチ感知面とディスプレイとが組み合わされている場合）を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示されるように、ディスプレイとは別個のタッチ感知面上での入力を検出する。一部の実施形態では、このタッチ感知面（例えば、図１Ｄの１９５）は、ディスプレイ（例えば、１９４）上の主軸（例えば、図１Ｄの１９８）に対応する主軸（例えば、図１Ｄの１９９）を有する。これらの実施形態によれば、デバイスは、タッチ感知面１９５との接触（例えば、図１Ｄの１９７－１及び１９７－２）を、ディスプレイ上のそれぞれの場所に対応する場所（例えば、図１Ｄでは、１９７－１は１９６－１に対応し、１９７－２は１９６－２に対応する）にて検出する。このように、タッチ感知面がディスプレイとは別個のものである場合、タッチ感知面（例えば、図１Ｄの１９５）上でデバイスによって検出されたユーザ入力（例えば、接触１９７－１及び１９７－２、並びにそれらの移動）が、多機能デバイスのディスプレイ（例えば、図１Ｄでの１９４）上のユーザインタフェースを操作するために、デバイスによって使用される。同様の方法が、本明細書に記載の他のユーザインタフェースに任意選択的に使用されることを理解されたい。

更に加えて、以下の実施例は主に指入力（例えば、指の接触、指のタップジェスチャ、指のスワイプジェスチャ）を参照して説明されるが、一部の実施形態では、それらの指入力のうちの１つ以上は、別の入力デバイスからの入力（例えば、マウスに基づく入力、又はスタイラス入力）で置き換えられることを理解されたい。例えば、スワイプジェスチャは、任意選択的に、（例えば、接触の代わりに）マウスクリックと置き換えられ、その後、（例えば、接触の移動の代わりに）スワイプの経路に沿ってカーソルの移動が行われる。別の例として、タップジェスチャは、（例えば、接触の検出に続いて接触の検出を停止する代わりに）カーソルがタップジェスチャの位置上に配置されている間、任意選択的に、マウスクリックで置き換えられる。同様に、複数のユーザ入力が同時に検出されるとき、複数のコンピュータマウスが同時に、任意選択的に用いられているか、又はマウスと指接触が任意選択的に同時に用いられていることが理解されよう。

本明細書で使用する時、用語「フォーカスセレクタ」とは、ユーザが相互作用しているユーザインタフェースの現在の部分を示す入力要素を指す。カーソル又は他の位置マーカを含む一部の実装では、タッチ感知面（例えば、図１Ｄのタッチ感知面１９５（タッチ感知面１９５は、一部の実施形態では、タッチパッドである））上で入力（例えば、押圧入力）が検出された時に、カーソルが特定のユーザインタフェース要素（例えば、ボタン、ウィンドウ、スライダ、又は他のユーザインタフェース要素）の上にある時、カーソルは「フォーカスセレクタ」として機能し、特定のユーザインタフェース要素が、検出された入力に従って調整される。タッチスクリーンディスプレイ上のユーザインタフェース要素との直接的な相互作用を可能にする、タッチスクリーンディスプレイ（例えば、図１Ａのタッチ感知ディスプレイシステム１１２、又はタッチスクリーン１１２）を含む一部の実装では、タッチスクリーン上で検出される接触が「フォーカスセレクタ」の役割を果たすため、入力（例えば、接触による押圧入力）が、タッチスクリーンディスプレイ上の特定のユーザインタフェース要素（例えば、ボタン、ウィンドウ、スライダ、又は他のユーザインタフェース要素）の場所で検出されると、その特定のユーザインタフェース要素が、検出された入力に従って調整される。一部の実装では、（例えば、タブキー又は矢印キーを使ってフォーカスを１つのボタンから別のボタンに移動させることにより）タッチスクリーンディスプレイ上の対応するカーソルの移動又は接触の移動なしに、フォーカスが、ユーザインタフェースの１つの領域からユーザインタフェースの別の領域に移動される。これらの実装では、フォーカスセレクタは、ユーザインタフェースの異なる領域間でのフォーカスの移動に従って移動する。フォーカスセレクタが採用する具体的な形態とは関わりなく、フォーカスセレクタは、全般的に、ユーザが意図するユーザインタフェースとの相互作用を（例えば、ユーザが相互作用することを意図しているユーザインタフェースの要素をデバイスに示すことによって）通信するために、ユーザによって制御されるユーザインタフェース要素（又は、タッチスクリーンディスプレイ上での接触）である。例えば、押圧入力がタッチ感知面（例えば、タッチパッド又はタッチ感知ディスプレイ）上で検出されたときに、対応するボタンの上にあるフォーカスセレクタ（例えば、カーソル、接触又は選択ボックス）の位置は、（デバイスのディスプレイ上に示されている他のユーザインタフェース要素ではなく）対応するボタンをユーザがアクティブにしようとしていることを示すものである。

図４Ｃは、ディスプレイ１９４及びタッチ感知面１９５と通信する電子デバイス例を示す。電子デバイスの少なくともサブセットについて、ディスプレイ１９４及び／又はタッチ感知面１９５は、一部の実施形態に係る電子デバイスに一体化されている。以下に詳述する実施例は、電子デバイス（例えば、図１Ａ～１Ｂのポータブル多機能デバイス１００）と通信するタッチ感知面１９５及びディスプレイ１９４を参照して説明されるが、一部の実施形態に係る、タッチ感知面及び／又はディスプレイは電子デバイスと一体化されており、他の実施形態では、タッチ感知面及びディスプレイのうちの１つ以上は、電子デバイスとは別個であるということが理解されるべきである。更に、一部の実施形態では、電子デバイスは一体型ディスプレイ及び／又は一体型タッチ感知面を有し、電子デバイスとは別個の１つ以上の追加ディスプレイ及び／又はタッチ感知面と通信する。

一部の実施形態では、図６Ａ～６Ｂ、７Ａ～７Ｂ、８Ａ～８Ｂ、９Ａ～９Ｄ、１０Ａ～１０Ｃ、１１Ａ～１１Ｊ、１２、１３Ａ～１３Ｂ、１４、１５Ａ～１５Ｂ、１６Ａ～１６Ｂ、１７Ａ～１７Ｅ、１８Ａ～１８Ｂ、１９Ａ～１９Ｆ、２０、２１Ａ～２１Ｂ、２２Ａ～２２Ｃ、２３Ａ～２３Ｏ、２４Ａ～２４Ｂ、２５Ａ～２５Ｊ、２６Ａ～２６Ｂ、２７、２８、２９、３０Ａ～３０Ｄを参照して以下に説明する動作の全ては、ユーザインタフェースナビゲートロジック４８０を備える単一の電子デバイス上にて実行される（例えば、図４Ｃを参照して以下に説明するコンピューティングデバイスＡ）。しかし、しばしば複数の異なる電子デバイスが互いにリンクされ、図６Ａ～６Ｂ、７Ａ～７Ｂ、８Ａ～８Ｂ、９Ａ～９Ｄ、１０Ａ～１０Ｃ、１１Ａ～１１Ｊ、１２、１３Ａ～１３Ｂ、１４、１５Ａ～１５Ｂ、１６Ａ～１６Ｂ、１７Ａ～１７Ｅ、１８Ａ～１８Ｂ、１９Ａ～１９Ｆ、２０、２１Ａ～２１Ｂ、２２Ａ～２２Ｃ、２３Ａ～２３Ｏ、２４Ａ～２４Ｂ、２５Ａ～２５Ｊ、２６Ａ～２６Ｂ、２７、２８、２９、３０Ａ～３０Ｄを参照して以下に説明する動作を実行するということが理解されるべきである（例えば、ユーザインタフェースナビゲートロジック４８０を備える電子デバイスは、ディスプレイ１９４を備える別個の電子デバイス及び／又はタッチ感知面１９５を備える別個の電子デバイスと通信する）。これらの実施形態のいずれかでは、図６Ａ～６Ｂ、７Ａ～７Ｂ、８Ａ～８Ｂ、９Ａ～９Ｄ、１０Ａ～１０Ｃ、１１Ａ～１１Ｊ、１２、１３Ａ～１３Ｂ、１４、１５Ａ～１５Ｂ、１６Ａ～１６Ｂ、１７Ａ～１７Ｅ、１８Ａ～１８Ｂ、１９Ａ～１９Ｆ、２０、２１Ａ～２１Ｂ、２２Ａ～２２Ｃ、２３Ａ～２３Ｏ、２４Ａ～２４Ｂ、２５Ａ～２５Ｊ、２６Ａ～２６Ｂ、２７、２８、２９、３０Ａ～３０Ｄを参照して以下に説明する電子デバイスは、ユーザインタフェースナビゲートロジック４８０を含む電子デバイス（単数又は複数）である。更に、ユーザインタフェースナビゲートロジック４８０は、様々な実施形態では、複数の別個のモジュール又は電子デバイスとの間で分割され得るということが理解されるべきである。しかし、本明細書で説明するために、ユーザインタフェースナビゲートロジック４８０は主に、実施形態の他の態様を不必要に不明瞭化しないよう、単一の電子デバイス内に存在するものとされる。

一部の実施形態では、ユーザインタフェースナビゲートロジック４８０は、１つ以上のモジュール（例えば、図１Ｃを参照して先に詳述するように、１つ以上のオブジェクト更新部１７７及び１つ以上のＧＵＩ更新部１７８を含む１つ以上のイベント処理部１９０）を含み、これら１つ以上のモジュールは、解釈された入力を受信し、これらの解釈された入力に応じて、グラフィカルユーザインタフェースを更新するための命令を、これらの解釈された入力に従って生成し、これらの命令は続いて、ディスプレイ上のグラフィカルユーザインタフェースを更新するために使用される。一部の実施形態では、解釈された入力は、（例えば、図１Ａ～１Ｂ及び３の接触モジュール１３０により）検出され、（例えば、図１Ｃのイベント認識部１８０により）認識され、及び／又は（例えば、図１Ｃのイベントソート部１７０により）優先された入力である。一部の実施形態では、解釈された入力は、電子デバイスでのモジュールにより生成される（例えば、電子デバイスは、生の接触入力データを受信し、その生の接触入力データからジェスチャを特定する）。一部の実施形態では、解釈された入力の一部又は全ては、解釈された入力として電子デバイスにより受信される（例えば、タッチ感知面１９５を含む電子デバイスは、生の接触入力データを処理し、その生の接触入力データからジェスチャを特定し、そのジェスチャを示す情報を、ユーザインタフェースナビゲートロジック４８０を含む電子デバイスに送信するようにする）。

一部の実施形態では、ディスプレイ１９４及びタッチ感知面１９５の両方が、ユーザインタフェースナビゲートロジック４８０を含む電子デバイス（例えば、図４ＣのコンピューティングデバイスＡ）と一体化されている。例えば、電子デバイスは、一体型ディスプレイ（例えば、図３の３４０）及びタッチパッド（例えば、図３の３５５）を備えるデスクトップコンピュータ又はラップトップコンピュータであってよい。別の実施例として、電子デバイスは、タッチスクリーン（例えば、図２の１１２）を備えるポータブル多機能デバイス１００（例えば、スマートフォン、ＰＤＡ、タブレットコンピュータなど）であってよい。

一部の実施形態では、タッチ感知面１９５が電子デバイスと一体化されている一方で、ディスプレイ１９４は、ユーザインタフェースナビゲートロジック４８０を含む電子デバイス（例えば、図４ＣのコンピューティングデバイスＢ）と一体化されていない。例えば、電子デバイスは、別個のディスプレイ（例えば、コンピュータモニタ、テレビなど）に（有線接続又は無線接続経由にて）接続された一体型タッチパッド（例えば、図３の３５５）を備えるデバイス（例えば、デスクトップコンピュータ又はラップトップコンピュータ）であってよい。別の実施例として、電子デバイスは、別個のディスプレイ（例えば、コンピュータモニタ、テレビなど）に（有線接続又は無線接続経由にて）接続されたタッチスクリーン（例えば、図２の１１２）を備えるポータブル多機能デバイス１００（例えば、スマートフォン、ＰＤＡ、タブレットコンピュータなど）であってよい。

一部の実施形態では、ディスプレイ１９４が電子デバイスと一体化されている一方で、タッチ感知面１９５は、ユーザインタフェースナビゲートロジック４８０を含む電子デバイス（例えば、図４ＣのコンピューティングデバイスＣ）と一体化されていない。例えば、電子デバイスは、別個のタッチ感知面（例えば、リモートタッチパッド、ポータブル多機能デバイスなど）に（有線接続又は無線接続経由にて）接続された一体型ディスプレイ（例えば、図３の３４０）を備えるデバイス（例えば、デスクトップコンピュータ、ラップトップコンピュータ、一体型セットトップボックス付きテレビ）であってよい。別の実施例として、電子デバイスは、別個のタッチ感知面（例えば、リモートタッチパッド、リモートタッチパッドとしてサーブするタッチスクリーンを備える別のポータブル多機能デバイスなど）に（有線接続又は無線接続経由にて）接続されたタッチスクリーン（例えば、図２の１１２）を備えるポータブル多機能デバイス１００（例えば、スマートフォン、ＰＤＡ、タブレットコンピュータなど）であってよい。

一部の実施形態では、ディスプレイ１９４もタッチ感知面１９５も、ユーザインタフェースナビゲートロジック４８０を含む電子デバイス（例えば、図４ＣのコンピューティングデバイスＤ）と一体化されていない。例えば、電子デバイスは、別個のタッチ感知面（例えば、リモートタッチパッド、ポータブル多機能デバイスなど）及び別個のディスプレイ（例えば、コンピュータモニタ、テレビなど）に（有線接続又は無線接続経由にて）接続された独立型の電子デバイス（例えば、デスクトップコンピュータ、ラップトップコンピュータ、コンソール、セットトップボックスなど）であってよい。別の実施例として、電子デバイスは、別個のタッチ感知面（例えば、リモートタッチパッド、リモートタッチパッドとしてサーブするタッチスクリーンを備える別のポータブル多機能デバイスなど）に（有線接続又は無線接続経由にて）接続されたタッチスクリーン（例えば、図２の１１２）を備えるポータブル多機能デバイス１００（例えば、スマートフォン、ＰＤＡ、タブレットコンピュータなど）であってよい。

一部の実施形態では、コンピューティングデバイスは、一体型オーディオシステムを有する。一部の実施形態では、コンピューティングデバイスは、コンピューティングデバイスとは別個のオーディオシステムと通信する。一部の実施形態では、オーディオシステム（例えば、テレビユニットと一体化されたオーディオシステム）は、別個のディスプレイ１９４と一体化されている。一部の実施形態では、オーディオシステム（例えば、ステレオシステム）は、コンピューティングデバイス及びディスプレイ１９４とは別個の独立型のシステムである。

ここで、デバイス１００などの、ディスプレイ及びタッチ感知面を有する電子デバイスに実装することができるユーザインタフェース（「ＵＩ」）の実施形態及び関連プロセスに注目する。

図２は、一部の実施形態に係る、アプリケーションのメニューのためのユーザインタフェースを示すために使用されるタッチスクリーンの概要である。同様のユーザインタフェースがデバイス１００上に、任意選択的に、実装される（図１Ａ）。一部の実施形態では、タッチスクリーン１１２上に表示されたユーザインタフェースは、以下の要素、又はそのサブセット若しくはスーパーセットを含む。
●セルラー及びＷｉ－Ｆｉ信号などの無線通信（単数又は複数）のための信号強度インジケータ（単数又は複数）２０２、
●時間２０３、
●Ｂｌｕｅｔｏｏｔｈインジケータ２０５、
●バッテリ状態インジケータ２０６、
●下記などの、頻繁に使用されるアプリケーションのアイコンを含むトレイ２０９、
○不在着信又は音声メールメッセージの数のインジケータ２１４を任意選択的に含む、「電話」とラベル付けされる、電話モジュール１３８のアイコン２１６、
○未読電子メールの数のインジケータ２１０を任意選択的に含む、「メール」とラベル付けされる、電子メールクライアントモジュール１４０のアイコン２１８、
○「ブラウザ」とラベル付けされる、ブラウザモジュール１４７のアイコン２２０、及び
○「ｉＰｏｄ」とラベル付けされる、ＩＰＯＤ（ＡＰＰＬＥ Ｉｎｃ．の商標）モジュール１５２とも称されるビデオ及び音楽プレーヤモジュール１５２のアイコン２２２、及び
●下記などの、その他のアプリケーションのアイコン、
○「メッセージ」とラベル付けされる、ＩＭモジュール１４１のアイコン２２４、
○「カレンダー」とラベル付けされる、カレンダーモジュール１４８のアイコン２２６、
○「写真」とラベル付けされる、画像管理モジュール１４４のアイコン２２８、
○「カメラ」とラベル付けされる、カメラモジュール１４３のアイコン２３０、
○「オンラインビデオ」とラベル付けされる、オンラインビデオモジュール１５５のアイコン２３２、
○「株式」とラベル付けされる、株式ウィジェット１４９－２のアイコン２３４、
○「地図」とラベル付けされる、地図モジュール１５４のアイコン２３６、
○「気象」とラベル付けされる、気象ウィジェット１４９－１のアイコン２３８、
○「時計」とラベル付けされる、アラーム時計ウィジェット１４９－４のアイコン２４０、
○「ヘルス」とラベル付けされる、ヘルスモジュール１４２のアイコン２４２、
○「メモ」とラベル付けされる、メモモジュール１５３のアイコン２４４、
○デバイス１００及びその様々なアプリケーションに関する設定へのアクセスを提供する、設定アプリケーション若しくはモジュールのアイコン２４６、及び
○Ａｐｐ Ｓｔｏｒｅ、ｉＴｕｎｅ、Ｖｏｉｃｅ Ｍｅｍｏ、及びユーティリティなどの、追加アプリケーションの他のアイコン。

図２に示されているアイコンのラベルは、単に実施例であることに留意されたい。他のラベルが、様々なアプリケーションアイコンのために、任意選択的に使用される。例えば、ヘルスモジュール１４２のアイコン２４２は、「フィットネスサポート」、「トレーニング」、「トレーニングサポート」、「エクササイズ」、「エクササイズサポート」、又は「フィットネス」と代替的にラベル付けされる。一部の実施形態では、それぞれのアプリケーションアイコンに関するラベルは、それぞれのアプリケーションアイコンに対応するアプリケーションの名前を含む。一部の実施形態では、特定のアプリケーションアイコンのラベルは、特定のアプリケーションアイコンに対応するアプリケーションの名前とは異なる。

図３Ａ～３Ｂは、一部の実施形態に係る、アプリケーション使用データを記憶するためのデータ構造を示すブロック図である。図３Ａに示すように、アプリケーション使用データテーブル３３５は、電子デバイスにインストールされた対応するそれぞれのアプリケーションに関連付けられた使用データをそれぞれが記憶する、デバイス１００にインストールされた各アプリケーションに対するテーブルの集合として任意選択的に実装されたデータ構造３３５の集合を含む（例えば、アプリケーション１の使用データテーブル３３５－１は、アプリケーション１に対する使用データを記憶し、アプリケーション使用データテーブル３３５－２は、アプリケーション２に対する使用データを記憶する）。一部の実施形態では、アプリケーション使用データテーブルの集合内の各テーブル（例えば、表３３５－１、３３５－２、３３５－３～３３５－Ｎ）は、電子デバイスにインストールされた１つを超えるアプリケーションに対する使用データを記憶する（例えば、表３３５－１は、潜在的な関連するデータの効率的な記憶のために、共通アプリケーションデベロッパ又はアプリケーションベンダによりそれぞれが提供された、関連アプリケーションに対する使用データを記憶する）。

一部の実施形態では、１つ以上のアプリケーション使用データテーブル３３５（例えば、アプリケーション１の使用データテーブル３３５－１）が、デバイス１００にインストールされたアプリケーションに関連付けられた使用データを記憶するために使用される。図３Ｂに示すように、アプリケーション１の使用データテーブル３３５－１は、多くの使用エントリを含む。一部の実施形態では、使用エントリは、個々の記録３４０－１から３４０－ｚに記憶され、任意選択的に、ヘッダ３４０－０に記憶される。ヘッダ３４０－０は、一部の実施形態では、テーブル内に記憶された情報の各フィールド（例えば、記録のそれぞれに関連付けられた各フィールド）の簡易説明を含む。例えば、ヘッダ３４０－０は、記録３４０－１から３４０－ｚのそれぞれが、使用エントリを一意的に特定するエントリＩＤを含むことを示す。一部の実施形態では、アプリケーション１の使用データテーブル３３５－１は、エントリＩＤフィールドに加えて、使用エントリがいつ作成され、及び／又は、表３３５－１に記憶されたかを特定するタイムスタンプフィールド、及び、他のアプリケーション使用データテーブル３３５に記憶されてよい、関連する使用エントリを特定する関連使用エントリフィールドなどの、追加フィールドを含む。

一部の実施形態では、アプリケーション１の使用データテーブル３３５－１の各記録は、ユーザがアプリケーション１と相互作用する間に収集された使用データを含む１つ以上の使用エントリを含む（例えば、ユーザがアプリケーション１を起動する度に、新たな使用エントリが作成され、収集された使用データを記憶する）。一部の実施形態では、テーブル内の各使用エントリは、以下の情報及びデータ構造、又はそれらのサブセット又はスーパーセットを記憶する。
●アプリケーション内でユーザにより実行されたａｐｐ内アクション（例えば、実行されたａｐｐ内アクション３４０－１（ａ））を特定する情報。（一部の実施形態では、これらのアクションは、そのアプリケーションによりデバイスに報告される。）例えば、アプリケーションは、ユーザが特定のプレイリスト内の特定の歌を再生したことを使用データ収集モジュール１６３－２に報告する。
●他のアプリケーション（例えば、システムレベルアプリケーション）内でユーザにより実行された他のアクション（例えば、実行された他のアクション３４０－１（ｂ））を特定する情報。例えば、口頭命令をバーチャルアシスタントアプリケーションに提供すること、又は、検索アプリケーションで情報のアイテムを検索すること（例えば、図１Ａの検索モジュール１５１）。
●使用エントリに関連付けられたアプリケーションとユーザが相互作用する間に、デバイス１００のセンサにより収集されたデータを含むセンサデータ（例えば、使用データ３４０－１（ｃ））。これは、任意選択的に以下を含む。
○時刻（例えば、時刻３４０－１（ｄ））情報
○ユーザがアプリケーションを起動した際の現在地、及び、（例えば、ＧＰＳモジュール１３２により報告される）アプリケーションの実行中にユーザが訪れた他の位置を特定する位置データ（例えば、位置データ３４０－１（ｅ））
○ユーザがアプリケーションと相互作用している間に収集された他のセンサデータ（例えば、他のセンサデータ３４０－１（ｆ））（例えば、環境光データ、標高データ、気圧値、動きデータなど）
●ユーザがアプリケーションと相互作用している間にデバイス１００に連結された外部デバイスを特定するデバイス連結情報（例えば、デバイス連結情報３４０－１（ｇ））。（例えば、外部デバイス例は、ヘッドホンジャックに接続されたセットのヘッドホンであり得、又は、別のデバイス例は、ＢＬＵＥＴＯＯＴＨを介して接続されたデバイス（例えば、自動車内のスピーカ又は自動車に関連付けられたハンズフリーシステム）であり得る。）
●ユーザがアプリケーションと相互作用している間に収集された他の情報（例えば、他の情報３４０－１（ｈ））（例えば、ＡＰＰＬＥ ＰＡＹのユーザの使用についての情報などの、完了した取引についての情報）。

一部の実施形態では、アプリケーションの各使用エントリが、ユーザによって実行されるアクションタイプを特定する情報を更に含む一方で、他の実施形態では、実行されたａｐｐ内アクションを特定する情報は、アクションタイプを判定又は導くために使用される。

一部の実施形態では、アプリケーション使用データテーブル３３５はまた、デバイス１００のユーザに関連付けられたプライバシー設定についての情報も記憶する。例えば、デバイス１００のユーザは、各アプリケーションに対する使用データの収集に関連付けられたプライバシー設定を構成することができる。一部の実施形態では、ユーザは、各使用エントリに含まれる全ての情報に対するデータ収集設定を管理できる（例えば、実行されたａｐｐ内アクション、実行された他のアクション、センサデータ、デバイス連結情報、及び他の情報）。例えば、ユーザは、プライバシー設定を構成し、デバイス１００（又は、使用データ収集モジュール１６３－２などの、その構成要素）が、位置データを収集しないものの、ブラウザモジュール１４７に対して実行されたａｐｐ内アクションについての情報を収集するようにできる。別の実施例として、ユーザは、プライバシー設定を構成し、デバイス１００が、実行されたａｐｐ内アクションについての情報を収集しないものの、オンラインビデオモジュール１５５に対する位置データを収集するようにできる。このようにして、ユーザは、デバイス１００上の使用データの収集を管理でき、デバイス１００で利用可能な各アプリケーションに対する使用データの収集に関する個人の好みに基づいて、適切なプライバシー設定を構成できる。

図４Ａ～４Ｂは、一部の実施形態に係る、トリガー条件を記憶するためのデータ構造を示すブロック図である。図４Ａに示すように、プロアクティブトリガー条件テーブル４０２は、デバイス１００にインストールされた各それぞれのアプリケーションに対する表の集合として任意選択的に実装された、対応するアプリケーションに関連付けられたトリガー条件をそれぞれが記憶する、データ構造４０２の集合を含む（例えば、アプリケーション１のトリガー条件テーブル４０２－１は、アプリケーション１に関連付けられたトリガー条件を記憶する（例えば、満たされると、デバイス１００にアプリケーション１を起動させる又は使用させるトリガー条件））。一部の実施形態では、アプリケーション使用データテーブルの集合内の各テーブル（例えば、表３３５－１、３３５－２、３３５－３～３３５－Ｎ）は、電子デバイスにインストールされた１つを超えるアプリケーションに関連付けられたトリガー条件を記憶する（例えば、表３３５－１は、潜在的な関連するデータの効率的な記憶のために、共通アプリケーションデベロッパ又はアプリケーションベンダによりそれぞれが提供された、関連アプリケーションに対するトリガー条件を記憶する）。

一部の実施形態では、１つ以上のプロアクティブトリガー条件テーブル４０２（例えば、アプリケーション１のトリガー条件テーブル４０２－１）が、デバイス１００にインストールされたアプリケーションに関連付けられたトリガー条件を記憶するために使用される。例えば、図４Ｂに示すように、アプリケーション１のトリガー条件テーブル４０２－１は、アプリケーション１に関連付けられた各トリガー条件に対する多くの前提条件及び関連付けられたアクションを特定する情報を含む。図４Ｂに示すように、アプリケーション１のトリガー条件テーブル４０２－１は、記録４１４－１から４１４－ｚを含み、任意選択的に、ヘッダ４１４－０を含む。ヘッダ４１４－０は、一部の実施形態では、テーブル内に記憶された情報の各フィールド（例えば、記録のそれぞれに関連付けられた各フィールド）の簡易説明を含む。各記録（例えば、記録４１４－１）は、デバイス１００が、各トリガー条件を満たすための前提条件を決定できる情報を含む。一部の実施形態では、記録４１４－１の前提条件１は、検出されると、デバイス１００に、関連付けられたアクション（例えば、アクション４）を実行させる多くの前提条件（例えば、センサの読み値）を含む又は特定する。

具体的な実施例として、前提条件１は以下であってよい。時刻が午後４：００から午後４：３０の間であるか、（例えば、ＧＰＳモジュール１３５により報告される）位置データが、ユーザがまだオフィス付近に居ることを示す（例えば、職場住所の所定の距離内）、及び、ユーザが移動中であることを、（例えば、加速度計１６８により報告される）加速度計データが示し、続いてデバイス１００が、前提条件１に関連付けられたトリガー条件を検出し、アクション４を実行する（例えば、アクション４は、インスタントメッセージモジュール１４１に関連付けられており、モジュール１４１に、会社から自宅に向かっていることを示すメッセージをユーザの配偶者に送らせる（又は、メッセージを送るかユーザに尋ねるダイアログを提示する））。一部の実施形態では、前提条件は、トリガー確立モジュール１６３－１により特定されたユーザの行動のパターンに基づいて特定される（図１Ａ）。一部の実施形態では、トリガー確立モジュール１６３－１は、使用データ収集モジュール１６３－２及びアプリケーション使用データテーブル３３５と併せて、アプリケーション使用データテーブルに記憶されているデータをマイニングして、ユーザの行動のパターンを特定する。先の実施例を続けると、ユーザが職場の所定の距離内にあって移動中に、午後４：００から午後４：３０の間にユーザが配偶者にメッセージを送った別個の三日間の観察後、続いてトリガー確立モジュール１６３－１は、対応するトリガー条件を作成し、前提条件が観察されると、メッセージを自動で送る（又は、メッセージを自動で送ってよいかユーザに尋ねる）。一部の実施形態では、トリガー確立モジュール１６３－１は、アプリケーション使用データテーブル３３５を所定の間隔（例えば、１時間毎、４時間毎、毎日、又はデバイスが外部電源に接続された時）で分析又はマイニングし、それらの所定の間隔にてのみトリガー条件を作成する。一部の実施形態では、ユーザは、トリガー条件が作成されるべきか確認する（例えば、デバイス１００が、前提条件及び関連付けられたアクションを説明するダイアログをユーザに提示し、ユーザは続いて、トリガー条件の作成を確認又は拒否する）。例えば、あるダイアログ例では、以下のテキストを含む「いつもこの時刻の帰宅時に奥様にテキストでお伝えしているようです。（I've noticed that you always text your wife that you are on your way home at this time of day.）「今から帰る」というテキストを送りますか？（Would you like to send her a text saying: I'm heading home now?）」。

図５は、一部の実施形態に係る、トリガー条件確立システム例を示すブロック図である。図５に示すように、トリガー条件確立システム５００は、ポータブル多機能デバイス１００を含み、また、１つ以上のサーバ５０２も含む。ポータブル多機能デバイス１００は、１つ以上のネットワークを介して１つ以上のサーバ５０２と通信する。１つ以上のネットワーク（例えば、ネットワーク（単数又は複数）５２０）は、トリガー条件確立システム５００の各構成要素を、トリガー条件確立システム５００の他の構成要素と通信可能に接続する。一部の実施形態では、１つ以上のネットワーク５２０は、パブリック通信ネットワーク、プライベート通信ネットワーク、又はパブリック通信ネットワーク及びプライベート通信ネットワークの両方の組み合わせを含む。例えば、１つ以上のネットワーク５２０は、インターネット、他のワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、バーチャルプライベートネットワーク（ＶＰＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ピアツーピアネットワーク、及び／又はアドホック接続などの、任意のネットワーク（又は、ネットワークの組み合わせ）であり得る。

一部の実施形態では、１つ以上のプロアクティブトリガー条件テーブル４０２は、ポータブル多機能デバイス１００に記憶され、１つ以上の他のプロアクティブトリガー条件テーブル４０２は、１つ以上のサーバ５０２に記憶される。一部の実施形態では、ポータブル多機能デバイス１００が、プロアクティブトリガー条件テーブル４０２を記憶する一方で、他の実施形態では、１つ以上のサーバ５０２が、プロアクティブトリガー条件テーブル４０２を記憶する。同様に、一部の実施形態では、１つ以上のアプリケーション使用データテーブル３３５は、ポータブル多機能デバイス１００に記憶され、１つ以上の他のアプリケーション使用データテーブル３３５は、１つ以上のサーバ５０２に記憶される。一部の実施形態では、ポータブル多機能デバイス１００が、アプリケーション使用データテーブル３３５を記憶する一方で、他の実施形態では、１つ以上のサーバ５０２が、アプリケーション使用データテーブル３３５を記憶する。

１つ以上のプロアクティブトリガー条件テーブル４０２又は１つ以上のアプリケーション使用データテーブル３３５が１つ以上のサーバ５０２に記憶されている実施形態では、続いて、トリガー確立モジュール１６３－１及び使用データ収集モジュール１６３－２により実行される機能の一部はそれぞれ、１つ以上のサーバ５０２にて実行される。これらの実施形態では、１つ以上のサーバ５０２とデバイス１００との間で、ネットワーク５２０を介して情報が交換される。例えば、１つ以上のサーバ５０２が、オンラインビデオモジュール１５５に対するプロアクティブトリガー条件テーブル４０２を記憶する場合、一部の実施形態では、デバイス１００は、オンラインビデオモジュール１５５に対応する１つ以上の使用エントリを、１つ以上のサーバ５０２に送信する。一部の実施形態では、１つ以上のサーバ５０２は続いて、受信した使用データをマイニングし、使用パターンを特定し、トリガー条件を作成し（図４Ａ～４Ｂに関連して上述するように）、作成したトリガー条件をデバイス１００に送信する。一部の実施形態では、オンラインビデオモジュール１５５に関連付けられたデータ（例えば、１つ以上のビデオストリームに対するデータ）の受信中に、デバイス１００及び１つ以上のサーバ５０２は、使用データ及びトリガー条件を交換する。一部の実施形態では、１つ以上のサーバ５０２は、作成したトリガー条件も検出することができ、トリガー条件がデバイス１００にまったく送信される必要がないようにする（例えば、１つ以上のビデオストリームに対するデータの交換中に受信した使用データに基づいて、サーバは、トリガー条件が満たされていると判定し得る）。一部の実施形態では、１つ以上のサーバ５０２に送信される使用データは限定範囲であり、オンラインビデオモジュール１５５のユーザの使用に関する情報のみを含むようにする（上述するように、ユーザはまた、使用データの収集をカバーするプライバシー設定も構成しなければならず、これらのプライバシー設定はまた、一部の実施形態では、ユーザが、１つ以上のサーバ５０２との使用データの交換を構成可能にもする（例えば、どの種類のデータを送信すべきであり、どの種類のデータを送信すべきでないかを構成可能にする））。

一部の実施形態では、セクション１～１１に関連して以下に説明するデータ構造もまた使用され、本明細書に説明する方法のいずれかの実装及び／又は改善を補助する。例えば、図１～１１に関連して以下に説明する予測エンジンが使用され、トリガー条件の確立を補助し、及び／又は、セクション１～１１に説明する他の技術もまた使用され、アプリケーションの使用履歴の監視を補助する。

図６Ａ～６Ｂは、一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させる方法６００を示すフローチャートを示す。図３Ａ～３Ｂ、４Ａ～４Ｂ、５、及び７Ａ～７Ｂは、図６Ａ～６Ｂの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法６００は、電子デバイス（例えば、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法６００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法６００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法６００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）、アプリケーション使用データテーブル（例えば、アプリケーション使用データテーブル３３５）、トリガー条件テーブル（例えば、トリガー条件テーブル４０２）、トリガー確立モジュール（例えば、トリガー確立モジュール１６３－１）、使用データ収集モジュール（例えば、使用データ収集モジュール１６３－２）、プロアクティブ提案モジュール（例えば、プロアクティブ提案モジュール１６３－３）、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、１つ以上の接触強度センサ（例えば、接触強度センサ１６５）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法６００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法６００は、タッチ感知ディスプレイを備える電子デバイス上にて関連コンテンツを先見的に特定し、表面化させる直感的な方法を提供する。この方法は、様々な機能を実行するために必要なタッチ入力数を減らすことにより、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、より速く、より効率的に、関連コンテンツを先見的に特定し、表面化させることの両方は、電力を節約し、バッテリを充電する間隔を延長する。

図６Ａに示すように、デバイスは、電子デバイスのユーザからの命令に応じて、電子デバイス上で、アプリケーションを実行する（６０２）。一部の実施形態では、ユーザからの命令は、アプリケーションに関連付けられたアイコン上のタッチ入力、又は、ユーザから受信した、バーチャルアシスタントアプリケーション（例えば、図１Ａのオペレーティングシステム１２６により管理されたバーチャルアシスタントアプリケーション）にアプリケーションを実行するよう命令する音声コマンドである。アプリケーションの実行中、デバイス（又は、使用データ収集モジュール１６３－２などの、その構成要素）は、アプリケーション内にてユーザによって実行される１つ以上のアクションを含む使用データを収集する（６０４）。一部の実施形態では、使用データはまた、１つ以上のアクションを含むことに加えて、又は、その代わりに、１つ以上のアクションのそれぞれに関連付けられたアクションタイプを特定する情報を含む。例えば、使用データは、音楽プレーヤモジュール１５２との相互作用中に、ユーザが、第１のプレイリストを検索し、第１のプレイリスト内をナビゲートし、第１のプレイリスト内の第１のトラックを選択し、続いて、第２のプレイリストを検索したことを特定する情報を含む（例えば、使用データは、音楽プレーヤモジュール１５２内でユーザによって実行される１つ以上のアクションのそれぞれを含む）。このようにして、使用データは、実行された個々のアクションのそれぞれについての情報を含み（例えば、ユーザが、第１のプレイリストの第１のトラックを検索し、再生した）、また、アクションタイプ（検索、ナビゲート、選択など）を特定する情報を含む。一部の実施形態では、使用データ取集モジュール１６３－２は、１つ以上のアクションを収集し、続いて、トリガー確立モジュール１６３－１は後に、アクションタイプを１つ以上のアクションのそれぞれに指定する。

一部の実施形態では、収集された使用データは、アプリケーションに関連付けられたアプリケーション使用データテーブルの使用エントリに（図３Ａ～３Ｂに関連して上述するように）記憶される。一部の実施形態では、収集された使用データは、ユーザによって実行されたａｐｐ内アクション、ユーザによって実行された他のアクション（例えば、バーチャルアシスタントアプリケーションとの相互作用、検索インタフェース（例えば、検索モジュール１５１）との相互作用、及び、オペレーティングシステム１２６により管理されているアプリケーションとの他の相互作用）、カレンダーイベントに関連付けられた情報、及び（図３Ｂに関連して上述するように）デバイス１００上のセンサから取得した追加データを含む。

一部の実施形態では、使用データは、アプリケーションの実行が継続されている間にユーザからバーチャルアシスタントアプリケーションに提供された口頭命令を含み、少なくとも１つのトリガー条件が更に、その口頭命令に基づいて、バーチャルアシスタントアプリケーションに提供される（６１８）。一部の実施形態では、口頭命令は、アプリケーションの現在の状態に対応する（例えば、再作成／再実行に関連する、又は、これを要求する）リマインダを作成することの要求を含み、この現在の状態は、口頭命令が提供された際のアプリケーションの状態に対応する（例えば、図１Ｂの１つ以上のアプリケーションビュー１９１）。一部の実施形態では、口頭命令が提供された際のアプリケーションの状態は、以下からなる群から選択される。口頭命令が提供された際にアプリケーション内に表示されていたページ、口頭命令が提供された際にアプリケーション内にて再生されていたコンテンツ（例えば、現在再生されているオーディオトラック）、口頭命令が提供された際にアプリケーション内に表示されていた通知（例えば、ユーザがブラウザモジュール１４７と相互作用している間に表示された、インスタントメッセージモジュール１４１からの通知）、及び口頭命令が提供された際にアプリケーション内に表示されたページのアクティブ部分（例えば、ウェブページ内で現在再生されているビデオコンテンツ）。追加的実施例として、アプリケーションの現在の状態はまた、以下に対応する場合がある。（ｉ）口頭命令が提供された際にアプリケーション内にてユーザが現在閲覧している特定のページの識別子（例えば、現在表示されているウェブページのＵＲＬ）、又は、現在のページにナビゲートする前にユーザがアプリケーション内にて行ったアクションの履歴（例えば、現在表示されているウェブページの前にユーザが訪問したＵＲＬ）。

一部の実施形態では、口頭命令は、アプリケーションの現在の状態に関連して、用語「これ（this）」又は「それ（that）」を含む。例えば、ユーザは、インスタントメッセージモジュール１４１からの通知が表示されている間に、命令「『これ（this）』を自分にリマインドする（remind me of'this'）」をバーチャルアシスタントアプリケーションに提供し、これに応じて、バーチャルアシスタントアプリケーションは、通知内に表示されたコンテンツに対応するリマインダをデバイス１００に作成させる。別の実施例として、オンラインビデオモジュール１５５にてユーザが特定のビデオコンテンツを視聴している間に、ユーザは、命令「『これ（this）』を視聴するよう自分にリマインダする（remind me to watch'this'）」をバーチャルアシスタントアプリケーションに提供し、これに応じて、バーチャルアシスタントアプリケーションは、特定のビデオコンテンツに対応するリマインダをデバイス１００に作成させる。一部の実施形態では、デバイス１００は、口頭命令がアプリケーション自体から提供された際のアプリケーションの現在の状態に関する情報を受信する（例えば、前の例を続けると、オンラインビデオモジュール１５５は、その現在の状態を、デバイス１００又はプロアクティブモジュール１６３などのその構成要素に報告し戻し、このようにして、プロアクティブモジュール１６３は、特定のビデオコンテンツを識別する情報を受信する）。

デバイスは続いて、自動的に、かつ人の介入なしに、収集された使用データに基づく少なくとも１つのトリガー条件を取得する（６０６）。一部の実施形態では、少なくとも１つのトリガー条件がデバイス上で確立される一方で、他の実施形態では、トリガー条件は、デバイスから１つ以上のサーバ５０２に送信された使用データに基づいて（図５に関連して上述するように）トリガー条件を確立したサーバ（例えば、図５の１つ以上のサーバ５０２）から取得される（６１２）。一部の実施形態では、少なくとも１つのトリガー条件は、満たされると、デバイス（又は、プロアクティブモジュール１６３などの、その構成要素）に、少なくとも１つのトリガー条件に関連付けられたアクションをユーザが容易に実行することができるようにさせる、（例えば、いずれの入力なく、又は、ユーザからのシングルタッチ若しくは口頭入力のみにて）。例えば、１つのトリガー例は、午後２：００から午後２：３０の間に、以前に訪れたＧＰＳ座標の間（例えば、職場住所付近に位置する、ユーザがよく訪れる２つの建物の間）をユーザが歩いていることを、（例えば、加速度計１６８により報告される）加速度計データが示す間に、デバイスが自動的に（及び、ユーザからのいずれの入力なく）音楽アプリケーション（例えば、図１Ａの音楽プレーヤ１５２）を開き、特定のプレイリストを再生することを示してよい。一部の実施形態では、使用データを収集し、平日の午後２：００から午後２：３０の間に、以前に訪れたＧＰＳ座標の間を歩いている間に、ユーザが音楽プレーヤ１５２を開き、特定のプレイリストを再生したことを、音楽プレーヤ１５２に関連付けられた、収集された使用データが示すことを判定した後に、このトリガー例は、（１つ以上のサーバ５０２又はデバイス１００により）確立された。このようにして、デバイス（又は、サーバ）は、収集された使用データに基づいてパターンを特定し、認識する。ユーザに対して自動的にアクションを実行する（例えば、特定のプレイリストを再生する）ことにより、ユーザは、デバイスをロック解除し、音楽プレーヤ１５２を検索し、特定のプレイリストを検索し、続いて特定のプレイリストを再生するといった時間を浪費する必要がなくなる。

一部の実施形態では、デバイスが特定の使用データを収集することをユーザが許可していることを確認し、及び／又は、デバイスがトリガー条件を確立することをユーザが許可していることを検証するために、この方法はまた、トリガー条件を確立する又は取得する前に、デバイスのユーザに関連付けられたプライバシー設定をチェックすることを含む（例えば、ユーザは、デバイスに自動的にテキストメッセージを送信させるトリガー条件をデバイスが確立することを禁止するよう設定を構成してよい）。

このデバイス（又は、トリガー条件確立モジュール１６３－１などの、その構成要素）はまた、少なくとも１つのトリガー条件を、アプリケーション内にてユーザによって実行される１つ以上のアクションの特定のアクション（又は、特定のアクションに対応する特定のアクションタイプ）に関連付ける（６０８）（例えば、図４Ａ～４Ｂの、特定のアクションと共にトリガー条件を満たすための前提条件を、プロアクティブトリガー条件テーブル４０２に記憶することにより）。少なくとも１つのトリガー条件が満たされていると判定すると、デバイスは、トリガー条件に関連付けられた特定のアクション（又は、特定のアクションタイプ）が利用可能であることのインジケーションをユーザに提供する（６１０）。一部の実施形態では、ユーザにインジケーションを提供することは、特定のアクションを起動するための（又は、特定のアクションタイプに対応するアクションを実行するための）ユーザインタフェースオブジェクト（例えば、図７ＡのＵＩオブジェクト７０２）を表面化させること、特定のアクションを実行するアプリケーションに関連付けられたアイコン（例えば、図７Ａの、タッチスクリーン１１２の左下角に示すようなアプリケーションアイコン７１０）を表面化させること、又は（特定のプレイリストの実施例にて上述したように）特定のアクションを単に実行することを含む。一部の実施形態では、デバイスは、ユーザインタフェースオブジェクト及び／又はアイコンを表面化させる一方でまた、（自動的にかつ人の介入なしに）特定のアクション（又は、特定のアクションと同じ特定のアクションタイプのアクション）を単に実行する。

一部の実施形態では、少なくとも１つのトリガー条件を取得することは、電子デバイスからリモートに位置する１つ以上のサーバ（例えば、図５のサーバ５０２）に、使用データを送信し、その１つ以上のサーバから少なくとも１つのトリガー条件を受信することを含む（６１２）。例えば、これらの実施形態と一致して、電子デバイスは、（ネットワーク５２０を介して）１つ以上の使用エントリ（例えば、図３Ｂの使用エントリ１）をサーバ５０２に送信し、その使用データに基づいて、サーバ５０２は、少なくとも１つのトリガー条件を確立する。実施例を続けると、サーバ５０２は続いて、（ネットワーク５２０を使用して）その少なくとも１つのトリガー条件（例えば、プロアクティブトリガー条件テーブル４０２－１に記憶されている前提条件及び関連付けられたアクション）をデバイス１００に送信する。

一部の実施形態では、インジケーションを提供することは、タッチ感知ディスプレイ上のロックスクリーンに、トリガー条件に関連付けられた特定のアクションに対応するユーザインタフェースオブジェクトを表示することを含む（６１４）。一部の実施形態では、ユーザインタフェースオブジェクトは、ロックスクリーンの所定の中央部に表示される（例えば、図７Ａに示すように、ＵＩオブジェクト７０２は、ロックスクリーンの実質的中央に表示される）。例えば、デバイスは、ロックスクリーン上にＵＩオブジェクト７０２を表示することで、このインジケーションを提供する（図７Ａ）。図７Ａに示すように、ＵＩオブジェクト７０２は、予測されたアクション７０６を含む。一部の実施形態では、予測されたアクション７０６は、少なくとも１つのトリガー条件に関連付けられたアクションの説明である（つまり、ユーザインタフェースオブジェクトは、「スワイプして歩行中プレイリストのトラック２を再生する（Swipe to Play Track 2 of Walking Playlist）」などの、トリガー条件に関連付けられた特定のアクションの説明を含む（６１６））。一部の実施形態では、ＵＩオブジェクト７０２はまた、任意選択的に、ＵＩオブジェクト７０２が表示されている理由についての情報をユーザに提供する追加情報７０４を含む。一部の実施形態では、追加情報７０４は、トリガー条件を検出するために使用された使用データ（例えば、センサデータ３４０－１（ｃ））の説明、及び／又は、少なくとも１つのトリガー条件に対する前提条件の説明（例えば、図４Ｂの記録４１４－１の前提条件１）を含む。例えば、追加情報７０４は、この特定の時刻にユーザが歩行中に、ユーザがよく歩行中プレイリストを聞いているため、予測されたアクション７０６が表示されていることを示す。一部の実施形態では、追加情報７０４を選択すること（例えば、追加情報７０４の上をタップすること）は、デバイス１００に、使用データの収集及びトリガー条件の作成に関連付けられたプライバシー設定をユーザが変更できるユーザインタフェースを表示させる。

一部の実施形態では、ＵＩオブジェクト７０２はまた、任意選択的に、予測されたアクション７０６に関連付けられたアプリケーションアイコン７１０を含む（６１６）。例えば、アプリケーションアイコン７１０は、音楽プレーヤ１５２のアイコンである（図７Ａに示すように）。一部の実施形態では、ＵＩオブジェクト７０２はまた、アフォーダンス７０８も含み、これは、選択されると、予測されたアクションをデバイスに実行させる（例えば、歩行中プレイリストのトラック２をデバイスに再生させる）。一部の実施形態では、ユーザインタフェースオブジェクト（例えば、ユーザインタフェースオブジェクト７０２）は、トリガー条件に関連付けられた特定のアクションの説明を含む（例えば、上述するように、予測されたアクション７０６）。一部の実施形態では、ユーザインタフェースオブジェクト７０２は、アプリケーションに関連付けられたアイコンを更に含む（例えば、ＵＩオブジェクト７０２内に表示されたアプリケーションアイコン７１０）。一部の実施形態では、ユーザインタフェースオブジェクト７０２は、スヌーズボタンを更に含み、これは、選択されると、デバイスに、ＵＩオブジェクト７０２の表示を停止させ、ユーザにより選択された又は事前に構成された期間後にＵＩオブジェクト７０２を再表示させる。例えば、ユーザは、ＵＩオブジェクト７０２が２時間にわたりスヌーズし、２時間後に、デバイスがＵＩオブジェクト７０２を再表示するよう選択する。別の実施例として、ユーザは、ＵＩオブジェクト７０２を、利用可能になるまでスヌーズするよう選択し、一部の実施形態では、デバイス１００は、カレンダーモジュール１４８を検索して、ユーザのスケジュールでの次の空きスロットを特定し、特定された次の空きスロット中にＵＩオブジェクト７０２を再表示する。

一部の実施形態では、デバイスは、ユーザインタフェースオブジェクトでの第１のジェスチャを検出する（６２２）。第１のジェスチャの検出に応じて、デバイスは、タッチ感知ディスプレイ上にアプリケーションを表示し、アプリケーションを表示する間に、トリガー条件に関連付けられた特定のアクションを実行する（６２４）。一部の実施形態では、第１のジェスチャは、ユーザインタフェースオブジェクト上のスワイプジェスチャである。一部の実施形態では、ユーザインタフェースオブジェクト上でのスワイプジェスチャの検出に応じて、デバイスはまた、アプリケーションを表示する前に自身をロック解除する（他の実施形態では、アプリケーションは、ロックスクリーンの右に表示される）。一部の実施形態では、第１のジェスチャは、ＵＩオブジェクト７０２内に表示されるテキストにより示される（例えば、予測されたアクション７０６内のテキストは、第１のジェスチャ、例えば、「～にスワイプする（Swipe to ...）」、の説明を含む）。例えば、及び、図７Ａを参照して、ユーザは、ＵＩオブジェクト７０２の上のタッチ感知面に接触し、タッチ感知面との接触を離すことなく、ユーザはその接触を、ＵＩオブジェクト７０２にわたって実質的に水平方向に移動させる。ＵＩオブジェクト７０２上のユーザからのこのスワイプジェスチャの検出に応じて、デバイスは音楽プレーヤ１５２を表示し、歩行中プレイリストのトラック２を再生する。

あるいは、第１のジェスチャを検出することの代わりに、一部の実施形態では、デバイスは、ユーザインタフェースオブジェクトでの第２のジェスチャ（例えば、ユーザインタフェースオブジェクト（例えば、アフォーダンス７０８などの再生ボタン）の所定のエリアでのシングルタップなどの、上述する第１のジェスチャとは別個のジェスチャ）を検出する（６２６）。第２のジェスチャを検出したことに応じて、かつタッチ感知ディスプレイ上にロックスクリーンを継続して表示する間に、デバイスは、トリガー条件に関連付けられた特定のアクションを実行する（６２８）。つまり、デバイスは、ロックスクリーンからまさに特定のアクションを実行し、アプリケーションを表示することなく、ロックスクリーンを継続して表示する。

一部の実施形態では、動作６２２～６２８に関連して上述する第１及び第２のジェスチャは同じジェスチャであるが、ＵＩオブジェクト７０２内に表示される異なるオブジェクト上にて実行される。例えば、第１のジェスチャが、予測されたアクション７０６上でのスワイプジェスチャである一方で、第２のジェスチャは、アフォーダンス７０８上でのスワイプジェスチャである。別の実施例として、第１のジェスチャは、予測されたアクション７０６上でのシングルタップであり、第２のジェスチャは、アフォーダンス７０８上でのシングルタップである。

一部の実施形態では、特定のアクションが利用可能であることのインジケーションをユーザに提供することは、特定のアクションが実行のために利用可能であることをユーザに知らせることを含む。一部の実施形態では、トリガー条件に関連付けられた特定のアクションが利用可能であることのインジケーションをユーザに提供することは、特定のアクションを実行することを含む。一部の実施形態では、このインジケーションは、特定のアクションを実行することにより、ユーザに提供される（例えば、ユーザは、再生中の所望するプレイリストを聞く）。一部の実施形態では、ＵＩオブジェクト７０２がロックスクリーン上に表示され、（上述する第１及び第２のジェスチャなどの）いずれのユーザ入力を受信することなく、特定のアクションもまた実行される。

一部の実施形態では、ＵＩオブジェクト７０２を表示することの代わりに（又は、これに加えて）、デバイスは、アプリケーションに関連付けられたアイコンを、実質的にロックスクリーンの角に表示する（例えば、図７Ａに示すように、アプリケーションアイコン７１０は、実質的にタッチスクリーン１１２の左下角に表示されている）。

一部の実施形態では、デバイスは、ユーザから、電子デバイスをロック解除する命令を受信する（例えば、接触がホームボタン２０４上に延長された後に、ユーザの指紋を有効と認識する）。命令を受信したことに応じて（例えば、デバイスをロック解除し、ロックスクリーンの表示を停止した後に）、デバイスは、タッチ感知ディスプレイ上に、デバイスのホームスクリーンを表示し（６２０）、そのホームスクリーン上にて、トリガー条件に関連付けられた特定のアクションが利用可能であることのインジケーションをユーザに提供する。図７Ｂに示すように、デバイスをロック解除する命令を受信した後、ホームスクリーンのスプリングボードセクション（又は、アプリケーションラウンチャ）に重ね合わせるように、ＵＩオブジェクト７０２が表示される。一部の実施形態では、ホームスクリーンの上にＵＩオブジェクト７０２を表示することの代わりに、又はこれに加えて、デバイスはまた、ホームスクリーンのドックセクションに重なる下部にアプリケーションアイコン７１０を表示する。一部の実施形態では、ホームスクリーンは、（ｉ）電子デバイス上で利用可能なアプリケーションの第１のセットを起動するための１つ以上のユーザインタフェースページを含む第１の部分（例えば、第１の部分は、ホームスクリーンのスプリングボードセクションの個々のページの全てを含む）、及び（ｉｉ）電子デバイス上で利用可能なアプリケーションの第２のセットを起動するための、第１の部分に隣接して（例えば、下に）表示される、第１の部分に含まれる全てのユーザインタフェースページ上に表示される第２の部分（例えば、第２の部分はドックセクションである）を含む。一部の実施形態では、ホームスクリーン上にインジケーションを提供することは、第２の部分上にインジケーションを表示することを含む（例えば、図７Ｂに示すように、アプリケーションアイコン７１０を含む下部は、ドック部上に表示される）。一部の実施形態では、アプリケーションの第２のセットは、アプリケーションの第１のセットとは別個であり、かつアプリケーションの第１のセットより小さい（例えば、ドックセクション内に表示されているアプリケーションの第２のセットは、ユーザのお気に入りのアプリケーションのアイコンの選択されるセットである）。

一部の実施形態では、少なくとも１つのトリガー条件が満たされていると判定することは、電子デバイスとは別個の第２のデバイスが電子デバイスに連結されていると判定することを含む。例えば、第２のデバイスは、ヘッドセットジャック２１２を介してデバイスに連結されたセットのヘッドホンであり、少なくとも１つのトリガー条件は、そのセットのヘッドホンが、デバイスに連結されていること示す前提条件を含む（例えば、ヘッドホンを接続後にユーザがいつも起動するポッドキャストアプリケーション内で、ユーザのお気に入りのポッドキャストを起動することを含む特定のアクションを実行する前に）。別の実施例として、第２のデバイスは、ユーザの自動車に関連付けられたＢｌｕｅｔｏｏｔｈスピーカ又は他のハンズフリーデバイスであり、少なくとも１つのトリガー条件は、自動車のＢｌｕｅｔｏｏｔｈスピーカがデバイスに連結されていることを示す前提条件を含む（例えば、時刻及びユーザの位置が、ユーザの母親を呼び出す特定のアクションに対する追加前提条件に一致する場合に、ユーザの母親を呼び出すことを含む特定のアクションを実行する前に）。外部デバイスを連結すること、及び、この連結に応じてアクションを実行することに関する追加詳細は、以下のセクション６に（例えば、セクション６の図３６－１に関連して）提供されている。

一部の実施形態では、少なくとも１つのトリガー条件が満たされていると判定することは、ユーザに関連付けられた自宅又は職場位置に対応する位置に電子デバイスが到着したと判定することを含む。一部の実施形態では、デバイスは、ユーザがたびたび訪れる場所（例えば、場所に関連付けられた特定のＧＰＳ座標又は通りの住所）を監視し、この情報を使用して、ユーザに関連付けられた自宅又は職場位置を確定する。一部の実施形態では、デバイスは、ユーザから受信した又はユーザが入力した情報に基づいて、これらの位置に対する住所を判定する（記憶された連絡先など）。一部の実施形態では、ユーザに関連付けられた自宅又は職場位置に対応する住所に電子デバイスが到着したと判定することは、電子デバイスの加速度計からの動きデータを監視することと、監視した動きデータに基づいて、電子デバイスが閾値時間量を超えて動いていないと判定することと、を含む（例えば、ユーザが自宅に到着し、１０分間にわたって動いていない）。このようにして、例えば、デバイスは、ユーザが自宅への私道に到着した時点の代わりに、ユーザが実際に自宅に到着した際に、少なくとも１つのトリガー条件に関連付けられた特定のアクションが実行されることを確かにする。

上述する方法６００の一部の実施形態では、この方法は取得動作６０６にて開始し、任意選択的に、実行動作６０２と、収集動作６０４と、を含む。つまり、これらの実施形態では、方法６００は以下を含む。電子デバイスのユーザに関連付けられた使用データであって、アプリケーションが電子デバイス上で実行されていた間に、アプリケーション内にてユーザによって実行される１つ以上のアクションを含む使用データに基づいて、少なくとも１つのトリガー条件を取得すること、少なくとも１つのトリガー条件を、アプリケーション内にてユーザによって実行される１つ以上のアクションの特定のアクションに関連付けること、及び、少なくとも１つのトリガー条件が満たされていると判定する際に、トリガー条件に関連付けられた特定のアクションが利用可能であることのインジケーションをユーザに提供すること。

図６Ａ～６Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法８００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図６Ａ～６Ｂに関連して上述された方法６００と類似の方式で適用可能であることに留意されたい。例えば、方法６００を参照して先述したユーザインタフェースオブジェクトは、任意選択的に、本明細書で説明する他の方法（例えば、方法８００）を参照して本明細書に記載のユーザインタフェースオブジェクトの特性のうちの１つ以上を有する。一部の実施形態では、方法６００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図８Ａ～８Ｂは、一部の実施形態に係る、関連コンテンツを先見的に特定し、表面化させる方法８００を示すフローチャートを示す。図３Ａ～３Ｂ、４Ａ～４Ｂ、５、及び９Ａ～９Ｄは、図８Ａ～８Ｂの方法及び／又はプロセスを示すために使用される。一部の実施形態では、図９Ａ～９Ｄに示すユーザインタフェースは、ゼロキーワード検索とも呼ばれる。ゼロキーワード検索は、ユーザからのいずれの入力なく行われる検索（例えば、検索エントリボックスは空欄のままである）であり、これによりユーザは、例えば、ユーザが次に検索する可能性のある（又は、と予測された）人、アプリケーション、アプリケーション内のアクション、近隣の場所、及び／又はニュース記事を閲覧できる。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法８００は、電子デバイス（例えば、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法８００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法８００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法８００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）、アプリケーション使用データテーブル（例えば、アプリケーション使用データテーブル３３５）、トリガー条件テーブル（例えば、トリガー条件テーブル４０２）、トリガー確立モジュール（例えば、トリガー確立モジュール１６３－１）、使用データ収集モジュール（例えば、使用データ収集モジュール１６３－２）、プロアクティブ提案モジュール（例えば、プロアクティブ提案モジュール１６３－３）、検索モジュール（例えば、検索モジュール１５１）、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、１つ以上の接触強度センサ（例えば、接触強度センサ１６５）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法８００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法８００は、関連コンテンツを先見的に特定し、表面化させるための自動化された方法を、タッチ感知ディスプレイを備える電子デバイス上にて提供する（ユーザが関連コンテンツを明示的に尋ねる前に、例えば、検索インタフェースに検索エントリ部分内にいずれのテキストをユーザが入力する前に）。この方法は、アプリケーションにアクセスする際のユーザの認識的負担を軽減し、それによって、より効率的なヒューマンマシンインタフェースを作り出す。

図８Ａに示すように、デバイスは、タッチ感知ディスプレイ上の検索アクティブ化ジェスチャを検出する（８０２）。例えば、図９Ａに示すように、デバイスは、検索アクティブ化ジェスチャ９０２－１を検出する（例えば、タッチ感知ディスプレイ上での接触に続く、実質的に垂直方向（例えば、下向き）の、この接触の連続する動き）。別の実施例として、図９Ａに更に示すように、デバイスは、検索アクティブ化ジェスチャ９０２－２を検出する（例えば、タッチ感知面上での接触に続く、実質的に水平方向（例えば、右向き）の、この接触の連続する動き）。一部の実施形態では、検索アクティブ化ジェスチャは、少なくとも２つの別個のユーザインタフェースから利用可能であり、少なくとも２つの別個のユーザインタフェースの第１のユーザインタフェースは、タッチ感知ディスプレイ上の一連のホームスクリーンページのそれぞれのホームスクリーンページを表示することに対応する。

一部の実施形態では、それぞれのホームスクリーンページが、一連のホームスクリーンページ内の最初のホームスクリーンページである場合（例えば、図９Ａに示すように）、検索アクティブ化ジェスチャは、（ｉ）電子デバイスのユーザに対して実質的に下向き方向に動くジェスチャ（例えば、ジェスチャ９０２－１）、又は（ｉｉ）ユーザに対して実質的に左右方向であり、下向き方向に対して実質的に直角をなす方向に動く、連続するジェスチャ（例えば、ジェスチャ９０２－２）のうちの１つを含む。一部の実施形態では、それぞれのホームスクリーンページが、一連のホームスクリーンページ内の第２のホームスクリーンページである（つまり、最初のホームスクリーンページでない）場合、検索アクティブ化ジェスチャは、電子デバイスのユーザに対して実質的に下向き方向に動く、連続するジェスチャである（つまり、検索アクティブ化ジェスチャ９０２－１のみが利用可能であり、ジェスチャ９０２－２は利用可能でない）。

一部の実施形態では、少なくとも２つの別個のユーザインタフェースの第２のユーザインタフェースは、タッチ感知ディスプレイ上にアプリケーション切り替えインタフェースを表示することに対応する（例えば、ホームボタン２０４をダブルタップするユーザに応じて）。一部の実施形態では、検索アクティブ化ジェスチャは、タッチ感知ディスプレイ上の、アプリケーション切り替えインタフェースの所定の検索アクティブ化部位での接触を含む（例えば、アプリケーション切り替えインタフェースは、アプリケーション切り替えインタフェースの上部内に表示された所定の検索アクティブ化部位（図９Ｂの検索エントリ部分９２０と同様）である検索エントリ部分を含む）。

検索アクティブ化ジェスチャを検出したことに応じて、デバイスは、タッチ感知ディスプレイ上に検索インタフェースを表示し（８０４）、この検索インタフェースは、（ａ）検索エントリ部分（例えば、図９Ｂの、検索クエリとして使用される、ユーザからの入力を受け取るための、検索エントリ部分９２０）、及び（ｂ）検索エントリ部分にていずれのユーザ入力を受信する前に表示される予測部分（例えば、図９Ｂの予測部分９３０）を含む（８０６）。予測部分は、（ａ）複数の以前に連絡した人の一人に連絡するための少なくとも１つのアフォーダンス（例えば、図９Ｂの、提案された人９４０セクション内に表示されたアフォーダンス）、及び（ｂ）電子デバイス上で利用可能な複数のアプリケーションの、あるアプリケーション（例えば、「ディープリンク」）内の予測されたアクションを実行するための少なくとも１つのアフォーダンス（例えば、図９Ｂの提案されたアクション９５０セクション）のうちの１つ以上でポピュレートされる。アプリケーション「内（Within）」とは、特定のページ、ビュー、又は状態へのリンクを表す予測されたアクションをアプリケーション内にて実行するための少なくとも１つのアフォーダンスを指す（例えば、図１Ｂのアプリケーションビュー１９１の１つ）。つまり、予測されたアクションを実行するための少なくとも１つのアフォーダンスは、選択されると、アプリケーションを起動し、既定のコンテンツ、又は、アプリケーションとの以前の相互作用からのコンテンツを単に表示するのではなく、その代わりに、ディープリンクに対応する特定のページ、ビュー、又は状態を表示する。

一部の実施形態では、人は、現在時刻に少なくとも部分的に基づいて、複数の以前に連絡した人から、自動的に選択される（例えば、デバイス１００又はプロアクティブモジュール１６３により）。例えば、毎日午後５：３０前後に、ユーザがまだ勤務中に（職場位置は、図６Ａ～６Ｂを参照して上述するように判定される）、ユーザは、自宅に向かっていることを示すテキストをルームメイトに送ると、予測部分は、そのルームメイトに関連付けられたアフォーダンスを含むようになる（例えば、Ｐ－１はルームメイト用）。

一部の実施形態では、予測されたアクションは、電子デバイスのユーザに関連付けられたアプリケーションの使用履歴に少なくとも部分的に基づいて、自動的に選択される（例えば、デバイス１００又はプロアクティブモジュール１６３により）（例えば、（図３Ａ～３Ｂの１つ以上のアプリケーション使用テーブル３３５により提供される）アプリケーションの使用履歴が、毎日午後２：１５前後に、ユーザが、（上述するように、検索アクティブ化ジェスチャを提供することで）検索インタフェースを開き、「音楽（music）」を検索し、特定の音楽ａｐｐ検索結果を選択し、続いて、「歩行中プレイリスト（walking playlist）」を再生することを示すと、このアプリケーションの使用履歴に基づいて、予測部分は、検索エントリ部分にいずれのユーザ入力を受け取る前に、音楽ａｐｐ内のプレイリストの再生を開始するアフォーダンスを含むようになる（例えば、図９Ｂの、提案されたアクション９５０セクション内に表示されたコンテンツにより示されるように））。一部の実施形態では、アプリケーション内にて予測されたアクションを実行するための少なくとも１つのアフォーダンスはまた、現在時刻に少なくとも部分的に基づいて（例えば、予測されたアクションをユーザが通常行う時間と同じ時間前後に検索アクティブ化ジェスチャを提供するユーザに基づいて）選択される（アプリケーションの使用履歴の代わりに、又はこれに加えて）。一部の実施形態では（及び、図９Ｂに示すように）、予測されたアクションを実行するための少なくとも１つのアフォーダンスはユーザインタフェースオブジェクト７０２に対応し、従って、ユーザインタフェースオブジェクト７０２に関して先に提供される詳細（図６Ａ～６Ｂ及び７Ａ～７Ｂ）もまた、提案されたアクションセクション９５０及びそこに表示されたコンテンツにも適用する。

一部の実施形態では、電子デバイスに対応する位置データに少なくとも部分的に基づいて、人が更に選択される（例えば、職場に関連付けられた住所に朝到着すると、ユーザは大切な人にたびたび連絡する）。一部の実施形態では、人に対するアプリケーションの使用履歴及び連絡先情報は、電子デバイスのメモリから取り出される（例えば、図１Ａの、デバイス１００のメモリ１０２）。一部の実施形態では、人に対するアプリケーションの使用履歴及び連絡先情報は、電子デバイスからリモートに位置するサーバから取り出される（例えば、図５の１つ以上のサーバ５０２）。

一部の実施形態では、予測部分は、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスで更にポピュレートされる（８０８）（例えば、図９Ｂの、提案されたａｐｐｓ９５５セクション）。一部の実施形態では、予測されたアプリケーションは、アプリケーションの使用履歴に少なくとも部分的に基づいて自動的に選択される（デバイス１００により）。例えば、アプリケーションの使用履歴（例えば、図３Ａ～３Ｂの、アプリケーションの使用データテーブル３３５の１つ内の１つ以上の記録）は、ユーザが、自宅住所にて、毎朝午前９：００前後に、カレンダーモジュール１４３（図１Ａ）を開くことを示し、従って、提案されたａｐｐｓ９５５セクションは、現在時刻が午前９：００前後であり、位置データが、自宅住所にあるユーザを示す場合に、カレンダーモジュール１４３に対するアフォーダンスを含む。追加的実施例として、気象アプリケーション（例えば、図１Ａの気象ウィジェット１４９－１）が３日間連続で午前５：１５前後に起動されていることを、アプリケーションの使用履歴が示し、現在が午前５：１７である（例えば、ユーザが検索アクティブ化ジェスチャを使用してスポットライトを起動した際の現在時刻が午前５：１７である）と、電子デバイスは、このアプリケーションの使用履歴に少なくとも部分的に基づいて、検索インタフェースを、予測されたアプリケーションの１つとして、気象アプリケーションで、予測部分内にポピュレートするようになる。一部の実施形態では、予測されたアプリケーション及び予測アクションは、単一のセクション内に表示され、予測されたアクションは、予測されたアプリケーションの上方に表示される。先行する実施例に記すように、一部の実施形態では、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスはまた、現在時刻に少なくとも部分的に基づいて（例えば、予測されたアプリケーションをユーザが通常使用する時間と同じ時間前後に検索アクティブ化ジェスチャを提供するユーザに基づいて）選択される（アプリケーションの使用履歴の代わりに、又はこれに加えて）。

一部の実施形態では、提案されたａｐｐｓ９５５セクションをポピュレートするために、デバイス１００（又は、プロアクティブモジュール１６３などの、その構成要素）は、トリガーのための前提条件のいずれか（例えば、図４Ａ～４Ｂの、トリガー条件テーブル４０２の１つに記憶された前提条件）が満たされているか否かを判定し、特定のトリガーが満たされているとの判定に従って、デバイス１００は続いて、提案されたａｐｐｓ９５５セクションをポピュレートする（例えば、先行する実施例での、カレンダーモジュール１４３又は気象ウィジェット１４９－１などの、トリガーに関連付けられたアプリケーションに対応するアフォーダンスを追加する）。一部の実施形態では、検索インタフェース内の他のセクション（例えば、セクション９４０、９５０、９５５、９６０、及び９９０）が、同様の判定プロセスを用いてポピュレートされる（簡潔化のため、それらの詳細は本明細書では繰り返さない）。

一部の実施形態では、予測部分は、予測された近隣の場所のカテゴリ（例えば、図９Ｂの、提案された場所９６０セクション）に対する少なくとも１つのアフォーダンスで更にポピュレートされ（８０８）、予測された場所のカテゴリ（例えば、近隣の場所）が、現在時刻及びデバイスに対応する位置データのうちの１つ以上に少なくとも部分的に基づいて自動的に選択される。例えば、現在時刻が午前７：３０前後であり、デバイスが、人気のあるコーヒーショップ（コーヒーショップの人気は、一部の実施形態では、多くの別個のユーザに関連付けられた多くのデバイス１００にわたるクラウドソーシング使用データにより判定される）（の所定の距離内）付近にあることを位置データが示すと、デバイス１００は、提案された場所９６０セクションを、「コーヒーショップ（Coffee Shops）」に対するアフォーダンスでポピュレートする。一部の実施形態では、提案された場所９６０セクションは、（予測された場所のカテゴリに加えて、又はこの代わりに）現在時刻に基づく、近隣の場所に対する予測された検索に対応する情報でポピュレートされる。つまり、ユーザにより現在時刻前後に実行された以前の検索（例えば、検索モジュール１５１又はブラウザモジュール１４７内の検索）に基づいて、デバイスは、ユーザが再び行う可能性のある検索を先見的に予測する。例えば、午前７：２０から午前８：００の間の、以前の４回の機会（又は、一部の他の閾値機会数）に、ユーザが「コーヒー（Coffee）」を検索していることに基づいて、デバイス（例えば、トリガー確立モジュール１６３－１）は、検索アクティブ化ジェスチャを検出したことに応じて、提案された場所９６０セクションを、「コーヒーショップ（Coffee Shops）」に対するアフォーダンスでポピュレートする。他の実施形態では、提案されたカテゴリは、時間ではなく、デバイスの現在地にのみ基づく。例えば、近隣のコーヒーショップにリンクされたアフォーダンスが表示される。このようにして、ユーザは、「コーヒー（Coffee）」を再度手動で検索する必要なく、その代わりに、「コーヒーショップ（Coffee Shops）」アフォーダンス又は「食べ物（Food）」アフォーダンスを単に選択し、近隣のコーヒーショップのリストを素早く閲覧し得る。一部の実施形態では、以前の検索履歴は、他の情報（例えば、図３Ｂの他の情報３４０－１（ｈ））として、及び／又は、実行された他のアクション（例えば、図３Ｂの実行された他のアクション３４０－１（ｂ））として、１つ以上の使用エントリと共に記憶される。

一部の実施形態では、デバイスは、予測部分をスクロールするユーザ入力（例えば、図９Ｂのスクロールジェスチャ９７０）を検出し、予測部分をスクロールするこのユーザ入力を検出したことに応じて、デバイスは、このユーザ入力に従って予測部分をスクロールする（例えば、検索インタフェースを下向き方向にスクロールする、又は、予測部分のみを検索インタフェース内でスクロールする）。スクロールしたことに応じて、デバイスは、予測部分内の予測されたニュース記事に対する少なくとも１つのアフォーダンスを顕示化する（例えば、図９Ｃの、提案されたニュース記事９９０セクション）。一部の実施形態では、予測されたニュース記事（単数又は複数）は、電子デバイスに対応する位置データに少なくとも部分的に基づいて、自動的に選択される（デバイス１００により）。一部の実施形態では、提案されたニュース記事９９０セクションは、スクロール入力を要求することなく表示される。一部の実施形態では、予測されたニュース記事は、現在時刻（例えば、ユーザが、現在時刻（例えば、デバイスに、検索インタフェースを、予測部分９３０と共に表示させた検索アクティブ化ジェスチャをユーザが提供した時間）前後に、閾値回数を超えて（例えば、３回）、同様の又は関連する記事を読んだ）、ユーザに対応する以前の検索履歴（例えば、閾値回数（例えば、３回）を超えて、予測されたニュース記事と同様の又は関連する記事を、ユーザが検索した）、及び、他のユーザにより、ユーザの友人により、例えば、ツイッター又はフェイスブックなどのソーシャルメディアにて実行された検索を通して、ニュースストーリーに関連付けられたトレンドデータ、に少なくとも部分的に基づいて、任意選択的に選択される（位置データに加えて、又はその代わりに）。

一部の実施形態では、予測部分９３０内に表示されるセクション９４０、９５０、９５５、９６０、及び９９０の特定の順序は構成変更可能であり、それらセクションのそれぞれに対する所望する順序をユーザが選択できるようになっている。例えば、ユーザは、提案されたａｐｐｓ９５５セクションが最初に表示され、提案された人９４０セクションが２番目に表示され、提案されたアクション９５０セクションが３番目に表示され、提案されたニュース記事９９０セクションが４番目に表示され、提案された場所９６０セクションが最後に表示されるよう、順序を構成できる。一部の実施形態では、予測部分９３０は、セクション９４０、９５０、９５５、９６０、及び９９０の任意の２つを含む。他の実施形態では、予測部分９３０は、セクション９４０、９５０、９５５、９６０、及び９９０の任意の３つを含む。更に他の実施形態では、予測部分９３０は、セクション９４０、９５０、９５５、９６０、及び９９０の任意の４つを含む。更に他の実施形態では、予測部分９３０は、セクション９４０、９５０、９５５、９６０、及び９９０の全てを含む。一部の実施形態では、ユーザは、セクション９４０、９５０、９５５、９６０、及び９９０のどれだけ及びどれを予測部分９３０内に表示させるかについての好みを構成する。

更に、ユーザは、一部の実施形態では、セクション９４０、９５０、９５５、９６０、及び９９０のそれぞれをポピュレートするために使用される、データに与えられる重み（例えば、現在時刻、アプリケーションの使用履歴、位置データ、他のセンサデータなど）を構成できる。例えば、ユーザは、予測部分９３０の提案された人９４０セクション内にアフォーダンスを表示することを決定する際に、現在時刻が、位置データよりも大きく重み付けられるよう、好みを構成する。

図８Ｂに戻ると、一部の実施形態では、前述のセクション９４０、９５０、９５５、９６０、及び９９０のそれぞれ内に表示されるアフォーダンスは選択可能であり、ユーザは、提案されたアクション、提案されたａｐｐ、提案された場所、又は提案されたニュース記事のそれぞれの１つを選択できるようになっている（それぞれを以下に順に説明する）。

提案された人９４０セクション内に表示されるアフォーダンスの選択について、一部の実施形態では、デバイスは、人に連絡するための少なくとも１つのアフォーダンスの選択を検出する（８１０）。一部の実施形態では、デバイスは、少なくとも１つのアフォーダンス上のシングルタッチ入力を検出する（例えば、提案された人９４０セクション内に表示されたＰ－１に対応するアフォーダンス上のシングルタップ）。一部の実施形態では、人に連絡するための少なくとも１つのアフォーダンスの選択を検出したことに応じて、デバイスは、その人の連絡先情報（例えば、上述するように、デバイス又は１つ以上のサーバから取り出された連絡先情報）を使用して、その人に連絡する（又は、人に連絡するための異なる通信メディア、例えば、テキスト、電子メール、電話など、を提案する）。例えば、Ｐ－１に対応するアフォーダンス上のシングルタップを検出したことに応じて、デバイスは、ユーザのルームメイトにテキストメッセージ「今から帰る（on my way home）」を送信する。一部の実施形態では、デバイスは、Ｐ－１に自動的に連絡する一方で、他の実施形態では、デバイスは、インスタントメッセージモジュール１４１を表示し、インタフェースを、メッセージ（例えば、「今から帰る（on my way home）」）で、モジュール１４１内に事前にポピュレートし、続いて、メッセージを送信する前にユーザからの要求を待つ（例えば、ユーザによる音声コマンド又は送信ボタンの選択）。このようにして、デバイスのユーザは、便利に、そして素早く人（例えば、Ｐ－１）に連絡をとることができ、検索エントリ部分内にいずれのテキストを入力する必要なく、関連する（又は、所望する）メッセージをも送信できる（従って、ユーザがテキストを入力しなければならない場合や、人を特定することができない場合の時間を節約し、フラストレーションを解消する）。

提案されたアクション９５０セクション内に表示されるアフォーダンスの選択について、一部の実施形態では、デバイスは、予測されたアクションを実行するための少なくとも１つのアフォーダンスの選択を検出する（８１２）。例えば、デバイスは、提案されたアクション９５０セクション内のシングルタッチ入力を検出する（例えば、音楽プレーヤ１５２のアイコン上のタップ、又は、テキスト「歩行中プレイリストのトラック２をタップして再生する（Tap to Play Track 2 of Walking Playlist）」上のタップ）。一部の実施形態では、予測されたアクションを実行するための少なくとも１つのアフォーダンスの選択を検出したことに応じて、デバイスは、タッチ感知ディスプレイ上にアプリケーションを表示し、表示されたアプリケーション内で、予測されたアクションを実行する。つまり、デバイスは、検索インタフェース（例えば、検索エントリ及び予測部分を伴う検索モジュール１５１）の表示を停止し、その代わりに、アプリケーションを起動して表示し、その表示されたアプリケーション内で、予測されたアクションを実行する。例えば、テキスト「歩行中プレイリストのトラック２をタップして再生する（Tap to Play Track 2 of Walking Playlist）」上のシングルタップを検出したことに応じて、デバイスは、音楽プレーヤモジュール１５２を表示し、歩行中プレイリストのトラック２を再生することにより、予測されたアクションを実行する。このようにして、デバイスのユーザは、便利に、そして素早く、関連する（又は、所望する）アプリケーション（例えば、音楽プレーヤモジュール）にアクセスでき、検索エントリ部分内にいずれのテキストを入力する必要なく、所望するアプリケーション内の所望する機能をも実行できる（従って、ユーザがテキストを入力しなければならない場合や、音楽プレーヤモジュールを特定することができない場合の時間を節約し、フラストレーションを解消する）。

提案されたａｐｐｓ９５５セクション内に表示されるアフォーダンスの選択について、一部の実施形態では、デバイスは、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスの選択を検出する（８１４）。一部の実施形態では、デバイスは、少なくとも１つのアフォーダンス上のシングルタッチ入力を検出する（例えば、ブラウザａｐｐ１４７のアイコンに対するアフォーダンス上のシングルタップ）。一部の実施形態では、予測されたアプリケーションを実行するための少なくとも１つのアフォーダンスの選択を検出したことに応じて、デバイスは、予測されたアプリケーションをタッチ感知ディスプレイ上に表示する（例えば、デバイスは、検索エントリ部分及び予測部分を伴う検索インタフェースの表示を停止し、その代わりに、予測されたアプリケーションをタッチ感知ディスプレイ上に開き、表示する）。例えば、ブラウザａｐｐ１４７のアイコンに対応するアフォーダンス上のシングルタップを検出したことに応じて、デバイスは、ブラウザａｐｐ１４７を表示する（例えば、図１Ａのブラウザモジュール１４７）。このようにして、デバイスのユーザは、便利に、そして素早く、関連する（又は、所望する）アプリケーション（例えば、ブラウザアプリケーション）に、検索エントリ部分内にいずれのテキストを入力する必要なく、アクセスできる（従って、ユーザがテキストを入力しなければならない場合や、ブラウザアプリケーションを特定することができない場合の時間を節約し、フラストレーションを解消する）。

提案された場所９６０セクション内に表示されるアフォーダンスの選択について、一部の実施形態では、デバイスは、予測された場所のカテゴリ（例えば、近隣の場所）に対する少なくとも１つのアフォーダンスの選択を検出する（８１６）。一部の実施形態では、デバイスは、少なくとも１つのアフォーダンス上のシングルタッチ入力を検出する（例えば、「コーヒーショップ（Coffee Shops）」に対するアフォーダンス上のシングルタップ）。一部の実施形態では、予測された場所のカテゴリを実行するための少なくとも１つのアフォーダンスの選択を検出したことに応じて、デバイスは、（ｉ）少なくとも１つの近隣の場所に対応するデータ（例えば、地図モジュール１５４により判定される、少なくとも１つの近隣の場所に対する住所情報又はＧＰＳ座標）を受信し、（ｉｉ）その少なくとも１つの近隣の場所に対応する受信したデータをタッチ感知ディスプレイ上に表示する（例えば、検索インタフェースの表示を停止し、地図モジュール１５４を起動し、少なくとも１つの近隣の場所に対するＧＰＳ座標を表すドットなどの、受信したデータに対応するユーザインタフェース要素を含む地図モジュール１５４を、表示された地図内に表示する）。一部の実施形態では、受信するステップ及び表示するステップは、実質的に平行して実行される。例えば、「コーヒーショップ（Coffee Shops)」に対応するアフォーダンス上のシングルタップを検出したことに応じて、デバイスは、コーヒーを提供する近隣のカフェに対するＧＰＳ座標を取り出し、平行して地図モジュール１５４を表示し、ＧＰＳ座標の受信後、そのカフェに対するＧＰＳ座標を表すドットを表示する。このようにして、デバイスのユーザは、便利に、そして素早く、関連する（又は、所望する）対象地点（例えば、上述するカフェ）を、検索エントリ部分内にいずれのテキストを入力する必要なく、特定できる（従って、ユーザがテキストを入力しなければならない場合や、カフェ又はいずれのコーヒーショップを特定することができない場合の時間を節約し、フラストレーションを解消する）。一部の実施形態では、上述する、データを受信する動作は、予測された場所のカテゴリに対する少なくとも１つのアフォーダンスの選択を受信する前に実行される（又は、少なくとも部分的に実行される）。このようにして、近隣の場所に対応するデータが事前にローディングされ、予測された場所のカテゴリに対する少なくとも１つのアフォーダンスの選択を受信した後に、地図上に素早く表示される。

提案されたニュース記事９９０セクション内に表示されるアフォーダンスの選択について、一部の実施形態では、デバイスは、予測されたニュース記事に対する少なくとも１つのアフォーダンスの選択を検出する（８１８）。一部の実施形態では、デバイスは、少なくとも１つのアフォーダンス上のシングルタッチ入力を検出する（例えば、図９Ｃの、ニュース１に対するアフォーダンス上のシングルタップ）。一部の実施形態では、予測されたニュース記事に対する少なくとも１つのアフォーダンスの選択を検出したことに応じて、デバイスは、予測されたニュース記事をタッチ感知ディスプレイ上に表示する（例えば、デバイスは、検索エントリ部分及び予測部分を伴う検索インタフェースの表示を停止し、その代わりに、予測されたニュース記事をブラウザモジュール１４７内に開き、表示する）。例えば、ニュース１に対応するアフォーダンス上のシングルタップを検出したことに応じて、デバイスは、ニュース１に対応するニュース記事をブラウザａｐｐ１４７内に表示する（例えば、図１Ａのブラウザモジュール１４７）。このようにして、デバイスのユーザは、便利に、そして素早く、関連する（又は、所望する）ニュース記事（例えば、ブラウザアプリケーション）に、検索エントリ部分内にいずれのテキストを入力する必要なく、アクセスできる（従って、ユーザがテキストを入力しなければならない場合や、予測されたニュース記事を特定することができない場合の時間を節約し、フラストレーションを解消する）。

一部の実施形態では、（例えば、方法６００及び８００、又は本明細書に説明する他の方法のいずれかと併せて）検索インタフェースに含まれる、予測された／提案されたコンテンツアイテムは、セクション１～１１に関連して以下に説明する技術に基づいて選択される。

図８Ａ～８Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法６００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図８Ａ～８Ｂに関連して上述された方法８００と類似の方式で適用可能であることに留意されたい。例えば、方法８００を参照して先述したユーザインタフェースオブジェクトは、任意選択的に、本明細書で説明する他の方法（例えば、方法６００）を参照して本記載のユーザインタフェースオブジェクトの特性の１つ以上を有する。一部の実施形態では、方法８００併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図１０Ａ～１０Ｃは、一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて現在表示されているコンテンツに基づいて、検索クエリを先見的に提案する方法１０００を示すフローチャートを示す。図１１Ａ～１１Ｊは、図１０Ａ～１０Ｃの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法１０００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法１０００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法１０００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法１０００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法１０００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法１０００は、タッチ感知ディスプレイを備える電子デバイス上にて関連コンテンツ（例えば、提案された検索クエリ）を先見的に提案する直感的な方法を提供する。この方法は、電子デバイス上で検索を実行するために要求するタッチ入力の数を減らし（例えば、ユーザは、提案された検索クエリの選択のみを必要とされ、いずれのテキストをタイプする必要がない）、従って、より効率的なヒューマンマシンインタフェースを作り出し、ユーザは、関連する検索を素早く実行できる。提案された検索クエリを提供することにより、方法１０００はまた、より素早いアクションを実行することをアシストするための、プロアクティブなアシスタントがデバイス上で利用可能であることをユーザが知ることを確かにするよう補助する（従って、デバイスでのユーザ満足度を改善する）。バッテリ動作電子デバイスの場合、このような方法１０００は、電力を節約し、バッテリを充電する間隔を延長する。

図１０Ａに示すように、デバイスは、ディスプレイ上に、電子デバイス上で実行されているアプリケーションに関連付けられたコンテンツを表示する（１００２）。例えば、図１１Ａに示すように、電子デバイス１００上で実行されている電子メールアプリケーションに関連付けられたコンテンツが、タッチスクリーン１１２上に表示される。このコンテンツは、送信者名及び／又は電子メールアドレス（例えば、「送信者：Ｊｏｈｎ Ａｐｐｌｅｃｏｒｅ」）、件名テキスト（例えば、「次はどこ？（Where to next?）」）、及び電子メールの本文を少なくとも含む。一部の実施形態では、電子メールの本文は、画像１１０８及び／又はテキスト１１１０を含んでよい。

アプリケーションを表示する間、デバイスは、検出されると、電子デバイスに、アプリケーションとは別個の検索モードへと移行させるスワイプジェスチャを、タッチ感知面を介して検出する（１００４）。一部の実施形態では、スワイプジェスチャを検出することは、現在表示されているコンテンツの少なくとも一部上のスワイプジェスチャを検出することを含む（１００６）。一部の実施形態では、スワイプジェスチャは、アプリケーション上に検索インタフェースを呼び出すために使用される（例えば、図１１Ｂに示すそれらなど）。一部の実施形態では、スワイプジェスチャは、アプリケーション上で受信され、アプリケーションに関連付けられたコンテンツ内に含まれるいずれのユーザインタフェースフィールド内では受信されていない、第１のスワイプジェスチャである（例えば、第１のスワイプジェスチャは、アプリケーション内に表示されてよい検索ボックス内でのタップではない）。一部の実施形態では、第１のスワイプジェスチャは、電子デバイスに、アプリケーションとは別個であり、検索インタフェース（例えば、図１１Ｂ及び１１Ｄ並びに図１１Ｆ～１１Ｊに示す、及び以下に詳述する検索インタフェースなど）の表示を含む、電子デバイスの検索モードに移行させる。

一部の実施形態では、第１のスワイプジェスチャは、タッチ感知ディスプレイ上を下向き方向にスワイプ（及び、少なくとも閾値距離（例えば、２、３、４ｃｍ）を移動）することによりいつでも利用可能である（例えば、図１１Ａ及び１１Ｅにそれぞれ示すように、下向きスワイプ１１０２－１及び１１０２－３）。一部の実施形態では、スワイプジェスチャは、アプリケーションがタッチ感知ディスプレイ上に現在表示されている間に検出され（例えば、上述する第１のスワイプジェスチャ）、このスワイプジェスチャは、アプリケーションに対して現在表示されているコンテンツの上で検出される。例えば、図１１Ａ及び１１Ｅでは、下向きスワイプジェスチャ１１０２－１及び１１０２－３は、電子メールアプリケーションが現在表示されている間に、電子メールコンテンツの上で検出される。

一部の実施形態では、第２のスワイプジェスチャはまた、デバイスに検索モードへと移行させ、これはまた、後にも利用可能である（例えば、アプリケーションを終了後）。一部の実施形態では、スワイプジェスチャを検出する前に、デバイスは、電子デバイスのホームスクリーンを閲覧することの要求に対応する入力を検出し、この入力を検出したことに応じて、デバイスは、アプリケーションに関連付けられたコンテンツの表示を停止し、電子デバイスのホームスクリーンのそれぞれのページを表示する（１００８）。一部の実施形態では、それぞれのページは、一連のホームスクリーンページ内の初期ページであり（例えば、一連のホームスクリーンページ内の最初のページ）、スワイプジェスチャは、ホームスクリーンの初期ページがディスプレイ上に表示されている間に検出される（例えば、第２のスワイプジェスチャ）。

例えば、図１１Ａ及び１１Ｅに示すように、ユーザはアプリケーションを終了し、アプリケーションが表示されている間の、デバイスの物理ホームボタン２０４のタッピング１１０６により、図１１Ｃに示すように、ホームスクリーンを閲覧することに切り替える。図１１Ｃでは、ホームスクリーンの最初のページが、ホームスクリーンページインジケータの強調表示された最初のドット１１１２－１により示されるように表示されており、ホームスクリーンの残りのドット１１１２－２は強調表示されていない。ホームスクリーンの最初のページを閲覧する間、ユーザは、実質的に水平方向（例えば、図１１Ｅのスワイプジェスチャ１１０４－１に対して示される左右方向）にスワイプすることにより、第２のスワイプジェスチャを提供できる。第２のスワイプジェスチャを受信したことに応じて、電子デバイスは、タッチ感知ディスプレイ上に検索インタフェースを表示することを含む、検索モードへと移行する（図１１Ｄを参照して以下に詳述するように）。

スワイプジェスチャを検出したことに応じて、デバイスは、ディスプレイ上に表示される検索インタフェースを含む検索モードへと移行する（１０１０）。検索インタフェース例を、図１１Ｂ及び１１Ｄに示す。一部の実施形態では、検索インタフェースは、例えば、図１１Ｂの検索インタフェース１１１５のように、アプリケーションに半透明に重ね合わせられるように表示される（１０１２）。一部の実施形態では、検索インタフェースは、アプリケーション上の半透明のオーバレイとして表示される（例えば、図１１Ｂの検索インタフェース１１１５に対して示すように）。一部の実施形態では、検索インタフェース１１１５は、例えば、フェーディングイン及び／又は一方からの遷移など、検索インタフェース１１１５のアニメーションの再生と共に段階的に表示される。図１１Ｂでは、検索インタフェース１１１５は、電子メールアプリケーションがタッチ感知ディスプレイ１１２上の検索インタフェース１１１５の下方に部分的に見えたままとなるように、電子メールアプリケーションに半透明に重ね合わせられるように表示される。一部の実施形態では、検索インタフェースは、上述する第２のスワイプジェスチャに応じて、図１１Ｇ～１１Ｊに示すように、ホームスクリーンに半透明に重ね合わせられるように表示される。

一部の実施形態では、検索インタフェースは、例えば、ユーザに関連付けられたソーシャルネットワークのメンバにより実行される１つ以上のトレンドタームなどの、１つ以上のトレンドクエリを更に含む（１０１４）。一部の実施形態では、１つ以上のトレンドクエリは、（ｉ）人気のニュースアイテム、（ｉｉ）電子デバイスの現在地（例えば、ユーザが自宅以外の場所を訪れている場合（東京など））、及び／又は（ｉｉｉ）旅行者の興味を引くことが既知のアイテムなど）に基づく１つ以上のトレンドタームを含む。例えば、トレンド検索１１６０は、図１１Ｂ及び１１Ｄにオプションとして示され、１つ以上のトレンドタームは、例えば、「Ｐａｔａｇｏｎｉａ」、「Ｅｃｕａｄｏｒ」、「Ｍｔ．Ｒａｉｎｉｅｒ」など、を含む。一部の実施形態では、検索インタフェースはまた、トレンドＧＩＦを含む（例えば、周りの人がＧＩＦをシェアしたいと思うような、コンテンツ内の、「おめでとう！（Congrats!）」などの、感情を表すフレーズに基づいて）。

検索モードへと移行することに関連して、デバイスは、コンテンツに関連付けられた情報に少なくとも部分的に基づいて、少なくとも１つの提案された検索クエリを判定する（１０１８）。一部の実施形態では、この判定は、検索インタフェース１１１５のアニメーションの再生と共に、例えば、検索インタフェース１１１５が段階的に顕示化されるに従って、実行される。他の実施形態では、この判定は、スワイプジェスチャが受信される前にも実行される。

一部の実施形態では、コンテンツがテキストコンテンツを含むとの判定に従って、デバイスは、そのテキストコンテンツに少なくとも部分的に基づいて、少なくとも１つの提案された検索クエリを判定する（１０２２）。一部の実施形態では、テキストコンテンツに少なくとも部分的に基づいて、少なくとも１つの提案された検索クエリを判定することは、少なくとも１つの提案された検索クエリを判定するために使用される１つ以上の所定のキーワードを検出するために、テキストコンテンツを分析することを含む（１０２４）。一部の実施形態では、１つ以上の所定のキーワードは、所定のキーワードについて少なくとも１５０，０００のエントリを伴う第１のデータ構造を含む、電子デバイス上に記憶されている、１つ以上のデータ構造内に記憶される。このようにして、デバイスは、コンテンツ内にて素早く検出され得、続いて、提案された検索クエリとしてユーザに提供され得る多くの共通タームを含み、これは全て、検索インタフェースでのユーザからのいずれの入力を要求することなく実行される。一部の実施形態では、１つ以上のデータ構造の第２のデータ構造は、第２のデータ構造を活用するコンテキストキットに関連付けられ、コンテンツに対するコンテキストを特定し、続いて、コンテンツに対する特定されたコンテキストに少なくとも部分的に基づいて、少なくとも１つの提案された検索クエリを特定する。一部の実施形態では、第２のデータ構造は、オンデバイスインデックスである（電子デバイスに特有のウィキペディアインデックスなど）。一部の実施形態では、提案された検索クエリが、第１及び第２のデータ構造の両方を使用して判定され、続いて、提案された検索クエリが集約され、ユーザに提示される（例えば、検索インタフェース内に、及び、いずれのユーザ入力を受け取る前に）。一部の実施形態では、第１及び第２のデータ構造の両方を活用することはまた、電子デバイスが、同じ名称ではあるが、住所／電話番号が異なる企業を区別できることを補助する。

例えば、図１１Ａでは、電子メールアプリケーションに関連付けられたコンテンツは、送信者及び／又は受領者情報、件名、及び、「エクアドル大好き！（I love Ecuador!）」などの電子メール本文内のテキスト、といったテキストコンテンツを含む。テキストコンテンツに少なくとも部分的に基づいて、デバイスは、少なくとも１つの提案された検索クエリを判定し、図１１Ｂに示すように、例えば、Ｅｃｕａｄｏｒ、Ｊｏｈｎ Ａｐｐｌｅｃｏｒｅ、Ｇｕｉｄｅ Ｓｅｒｖｉｃｅ、Ｃａｙａｍｂｅ、Ａｎｔｉｓａｎａなどのように、検索結果を表示する。用語「Ｅｃｕａｄｏｒ」は、第１のデータ構造内のエントリの一部として電子デバイス上に記憶された所定のキーワードであってよい一方で、他のエントリは、コンテンツに対するコンテキストに基づいて、及び、第１のデータ構造を活用中に第２のデータ構造を使用して、特定されてよい。

一部の実施形態では、少なくとも１つの提案された検索クエリを判定することは、複数の提案された検索クエリを判定することを含み、検索インタフェースをポピュレートすることは、検索インタフェースを、複数の提案された検索クエリでポピュレートすることを含む（１０２６）。図１１Ｂに示すように、１つの提案された検索クエリ「Ｅｃｕａｄｏｒ」が、提案された検索１１５０内に表示される。任意選択的に、図１１Ｂ内の点線により示されるように、提案された検索１１５０セクション内に、複数の提案された検索クエリ、例えば、「Ｊｏｈｎ Ａｐｐｌｅｃｏｒｅ」、「Ｇｕｉｄｅ Ｓｅｒｖｉｃｅ」、「Ｃａｙａｍｂｅ」、及び「Ａｎｔｉｓａｎａ」などが、「Ｅｃｕａｄｏｒ」に加えて表示される。

一部の実施形態では、検索モードへと移行することと併せて、デバイスは、電子デバイス上で利用可能な１つ以上のアクセシビリティ機能を使用することにより、（検索インタフェースを表示することの前及び／又は後に）コンテンツに関連付けられた情報を取得する（１０３６）。一部の実施形態では、電子デバイスのオペレーティングシステムは、電子デバイス上の一部のアプリケーション内に現在表示されているコンテンツへのダイレクトアクセス（又は、知識）を有さない（例えば、オペレーティングシステムのプロバイダ以外の企業により開発された第三者アプリケーション）。そのようにして、オペレーティングシステムは、ＡＰＩ（例えば、アクセシビリティＡＰＩ）と、電子デバイス上で利用可能であり、第三者アプリケーション内に表示されるコンテンツについてオペレーティングシステムに学習させることができる他の機能を使用することにより、コンテンツについての情報を取得する。

一部の実施形態では、１つ以上のアクセシビリティ機能を使用することは、１つ以上のアクセシビリティ機能を使用して、（ｉ）アプリケーション内に現在表示されているテキストコンテンツに自然言語処理アルゴリズムを適用すること、及び（ｉｉ）自然言語処理アルゴリズムから取得したデータを使用して、コンテンツを説明する１つ以上のキーワードを判定することであって、少なくとも１つの提案された検索クエリが、１つ以上のキーワードに基づいて判定されることにより、コンテンツに関連付けられた情報を生成する、ことを含む（１０３８）。（例えば、電子デバイス上で、１つ以上のアクセシビリティ機能として利用可能な、ＶｏｉｃｅＯｖｅｒ、Ｄｉｃｔａｔｉｏｎ、及びＳｐｅａｋ Ｓｃｒｅｅｎなどの機能を提供するために使用される自然言語処理アルゴリズム）。一部の実施形態では、コンテンツに関連付けられた情報は、（例えば、上述する自然言語処理アルゴリズムを使用して抽出された）氏名、住所、電話番号、インスタントメッセージハンドル、及び電子メールアドレス、を含む、アプリケーションに現在表示されているコンテンツから抽出された情報を含む。

一部の実施形態では、コンテンツを説明する１つ以上のキーワードを判定することはまた、（ｉ）アプリケーション内に現在表示されている非テキストコンテンツに対応するメタデータを取り出すこと、及び（ｉｉ）自然言語処理アルゴリズムから取得したデータに加えて、取り出したメタデータを使用し、１つ以上のキーワードを判定することを含む（１０４０）。非テキストコンテンツの一例は、アプリケーション内に表示されている画像である（例えば、図１１Ａの画像１１０８、及び、図１１Ｅの１つ以上の画像１１１２－４）。一部の実施形態では、１つ以上の情報タグ（ＨＴＭＬタグ、ＣＳＳ記述子、及び、他の同様のメタデータなど）は、画像に関連付けられており、これは、１つ以上のアクセシビリティ機能が、画像について学習することの補助に使用され得る（例えば、情報タグの１つは、画像の種類を説明し得、及び／又は、画像内に何が表示されているかについての詳細を提供し得る）。

一部の実施形態では（特に、非テキストコンテンツのみがアプリケーション内に表示されている場合）、自然言語処理アルゴリズムは使用されず、その代わりに、取り出したメタデータのみが、１つ以上のキーワードの判定のために使用される。一部の実施形態では、アプリケーション内に以前に提供されたユーザからの入力がまた、１つ以上のキーワードの判定の補助に使用される。例えば、ユーザは、住所及び／又は電話番号を特定するために、特定のレストラン名を検索し、そのレストラン名もまた、コンテンツを説明する１つ以上のキーワードの判定を補助するために使用されてよい（例えば、レストラン名がアプリケーション内に現在表示されておらず、以前の入力又は検索クエリとしてのみ使用されていた場合であっても）。

図１０Ｃに戻ると、検索インタフェースにていずれのユーザ入力を受け取る前に、デバイスは、表示された検索インタフェースを、少なくとも１つの提案された検索クエリでポピュレートする（１０２０）。一部の実施形態では、検索インタフェースは、検索入力部分（例えば、図１１Ｂ、１１Ｄ、及び１１Ｆ～１１Ｊの、検索インタフェース１１１５の上部の検索エントリ部分１１２０）と、検索結果部（例えば、図１１Ｂ、１１Ｄ、及び１１Ｆ～１１Ｊの、検索入力部分１１２０直下方の検索結果部１１３０）と、を含み、少なくとも１つの提案された検索クエリは、検索結果部内に表示される。例えば、図１１Ｂでは、提案された検索１１５０は、例えば、「Ｅｃｕａｄｏｒ」、「Ｊｏｈｎ Ａｐｐｌｅｃｏｒｅ」、「Ｇｕｉｄｅ Ｓｅｒｖｉｃｅ」、「Ｃａｙａｍｂｅ」、「Ａｎｔｉｓａｎａ」などの、少なくとも１つの提案された検索クエリを含み、少なくとも１つの提案されたクエリは、検索結果部１１３０内に表示される。

一部の実施形態では、上述する第１のスワイプジェスチャは、ホームスクリーンのいずれのページが表示されている間にも利用可能である。例えば、図１１Ａ及び１１Ｂに示すように、アプリケーション上にて、検索モードへと移行するために第１のスワイプジェスチャ１１０２－１が使用可能であることに加えて、ユーザはまた、ホームスクリーンのいずれのページ上にて、検索モードへと移行するために第１のスワイプジェスチャを使用してよい。図１１Ｃでは、実質的に垂直方向（例えば、下向き）のスワイプ１１０４－２に応じて、デバイスは検索モードへと移行し、図１１Ｄに示すように、検索インタフェース１１０５を表示する。このようにして、ユーザがいつでも、検索モードへと移行することを選択しても、ユーザは、アプリケーション内にて最近閲覧されたコンテンツに関連する、関連検索クエリが提示される。図１１Ｃは、ホームスクリーンの最初のページ上でスワイプジェスチャ１１０４－２を検出することを示すが、ホームスクリーンページインジケータの最初のドット１１１２－１を強調表示し、ホームスクリーンページインジケータの残りのドット１１１２－２を強調表示しないことにより示されるように、スワイプジェスチャ１１０４－２は、例えば、残りのドット１１１２－２の１つが強調表示され、最初のドット１１１２－１が強調表示されていない、ホームスクリーンの初期ページ以外のページ上などの、ホームスクリーンのいずれのページ上で検出され得る。

一部の実施形態では、デバイスは、タッチ感知面を介して、現在表示されている新たなコンテンツ上の新たなスワイプジェスチャを検出する（１０２８）。新たなスワイプジェスチャを検出したことに応じて、デバイスは検索モードへと移行する。一部の実施形態では、検索モードへと移行することは、ディスプレイ上に検索インタフェースを表示することを含む。検索モードへと移行することと併せて、かつ新たなコンテンツがテキストコンテンツを含まないとの判定に従って、一部の実施形態では、デバイスは、検索インタフェースを、電子デバイスのユーザからの、過去検索クエリの選択されるセットに基づく、提案された検索クエリでポピュレートする。

例えば、図１１Ａに示すように、電子メールコンテンツを閲覧後、及び、検索インタフェースを終了後、ユーザはレーニア山の写真１１１４－２（図１１Ｅ）を、エクアドルの写真１１１４－２（図１１Ｅ）と共に閲覧した。両方の画像はテキストコンテンツを含まない。続いて、図１１Ｅに示すように、新たなスワイプジェスチャ１１０２－３が検出される。新たなスワイプジェスチャ１１０２－３を検出したことに応じて、デバイスは検索モードへと移行し、図１１Ｆに示すように、ディスプレイ上に検索インタフェース１１１５を表示する。図１１Ｆでは、「Ｍｏｕｎｔ Ｒａｉｎｉｅｒ」が過去検索クエリとして示されており、最近の検索１１５２セクション内に表示されている。

一部の実施形態では、検索インタフェースが、アプリケーションとは別個の第２のアプリケーションにより提供された位置情報に基づく対象地点と共に表示される（１１３０）。例えば、先の実施例を続けると、レーニア山の位置情報は、画像に関連付けられたタグ及び／又はメタデータに基づいて、結像アプリケーションなどの第２のアプリケーションにより取得される。新たなスワイプジェスチャ１１０２－３（図１１Ｅ）に応じて、図１１Ｆに示すように、検索インタフェース１１１５が、対象地点、つまりＭｔ．Ｒａｉｎｉｅｒ１１５７－１と共に、提案された場所セクション１１５４内に表示される。

一部の実施形態では、対象地点は、非テキストコンテンツ上の新たなスワイプジェスチャに単に応答することなく表示される。対象地点は、テキストコンテンツ上の新たなスワイプジェスチャに応じて表示され得る。例えば、ユーザが第１のアプリケーション（ＹＥＬＰアプリケーションなど）内にてレストランを検索したというシナリオでは、ユーザは続いてテキストメッセージアプリケーション（例えば、アプリケーション）の使用に切り替え、ユーザは続いて、テキストメッセージアプリケーション上にてスワイプジェスチャを提供し、これに応じて、デバイスは、検索インタフェースを事前にポピュレートし、ユーザの、第１のアプリケーションとの先の相互作用に基づく、提案された検索クエリとして、対象地点を含める（例えば、図１１ＦのＢｅｓｔ Ｓｕｓｈｉ１１５７－２）。

一部の実施形態では、検索インタフェースは、１つ以上の提案されたアプリケーションを更に含む（１０３２）。提案されたアプリケーションは、ユーザに関連付けられたアプリケーションの使用履歴に基づいて、電子デバイスのユーザの対象となると予測されたアプリケーションである（アプリケーションの使用履歴は、図３Ａ及び３Ｂに関連して上述されている）。一部の実施形態では、過去検索クエリのセットは、最近の検索クエリの頻度に少なくとも部分的に基づいて（例えば、各過去検索クエリがユーザによりいつ、どれぐらいの頻度で実行されたかに基づいて）選択される。例えば、図１１Ｄに示すように、アプリケーションの使用履歴に基づいて、ヘルス２４２アプリケーション、書籍２４２アプリケーション、地図２３６アプリケーション、の各アプリケーションが、提案されたａｐｐｓ１１６２セクション内にてユーザに提案される。これらのアプリケーション提案は、最近の検索クエリの頻度に少なくとも部分的に基づいて選択されてよい。一部の実施形態では、電子デバイスにインストールされていないアプリケーションが、ユーザの対象となると予測される。インストールされていないアプリケーション２３７の名称が、他の提案されたアプリケーションと共に表示され、そのアプリケーションへのリンクが提供される。

一部の実施形態では、１つ以上の提案されたアプリケーションは、非テキストコンテンツ上の新たなスワイプに単に応答することなく表示される。例えば、図１１Ｄ及び１１Ｅに示すように、ホームスクリーン上（例えば、ホームスクリーンのいずれのページ上）のスワイプジェスチャ１１０２－３を検出したことに応じて、提案されたａｐｐｓ１１５５が、検索インタフェース１１１５の検索結果部１１３０内に、任意選択的に表示される。

図１１Ｂ、１１Ｄ、及び１１Ｆは、提案された検索結果を各カテゴリへグループ化することと、提案された検索を、検索インタフェース１１１５の異なるセクション内に表示することと、を示すが、他の表示フォーマットがユーザに示される。例えば、提案された検索結果が混合され得る。図９Ｄに示すように、対象地点、提案された場所、最近の検索、及び提案されたアプリケーションが共に、「マイロケーション＆最近の閲覧（My Location & Recently Viewed）」内に表示される。一部の実施形態では、提案された検索を混合することは、所定のルールのセットに従って実行される。例えば、最大検索結果スポット数（例えば、８）は、提案された検索に寄与するソースのそれぞれからであり得る。所定の先行順序が、提案された検索の順序を判定するために使用される（例えば、接続、過去、続いて、アンインストールされたヒーローアセット）。別の実施例では、所定のルールのセットは、以下を含む。（ｉ）提案された検索結果の各種類について、それは、寄与し得る位置及び最大結果数を有する、（ｉｉ）提案された検索結果の特定の種類について、（例えば、インストールされていないアプリケーション）、最大結果数は、混合された結果に寄与し得る（例えば、各寄与１）、（ｉｉｉ）又は、過去結果について、これはユーザによる。例えば、一部の実施形態では、過去検索クエリのセットは、最近の検索クエリの頻度に少なくとも部分的に基づいて、選択される（１０３４）。（例えば、各過去検索クエリがユーザによりいつ、どれぐらいの頻度で実行されたかに基づいて）。

一部の実施形態では、ユーザの対象となると最も予測された１つ以上の提案されたアプリケーションのみが、検索アクティブ化ジェスチャに応じて表示される。例えば、検索アクティブ化ジェスチャ（例えば、図１１Ｃのスワイプ１１０４）を受信したことに応じて、デバイスは検索モードへと移行し、図１１Ｇ～１１Ｊに示すように、半透明の検索インタフェースをタッチ感知ディスプレイ上に表示する。検索インタフェースは、検索入力部分１１２０と、検索結果部１１３０と、を含む。例えば、図１１Ｇに示すように、アプリケーションを提案することが、ユーザの対象となると最も予測される。複数のアプリケーションが、検索結果部１１３０内に表示される。

一部の実施形態では、提案されたアプリケーションは位置情報を使用し、ユーザの対象となると最も予測されたコンテンツを提案する。例えば、図１１Ｈでは、「Ｆｉｎｄ Ｍｙ Ｃａｒ」アプリケーションが、ユーザの対象となると最も予測されている。検索結果部１１３０では、「Ｆｉｎｄ Ｍｙ Ｃａｒ」アプリケーションのユーザインタフェースが表示される。このアプリケーションは、ユーザの位置情報を使用し、地図上にピンを表示し、ドットにより示された、車へのユーザの相対位置を示す。別の実施例では、ユーザの位置及び／又は上述する他の情報（例えば、使用データ、テキストコンテンツ、及び／又は非テキストコンテンツなど）に基づいて、近隣の対象地点を表示するアプリケーションが、ユーザの対象となると最も予測されている。図１１Ｉでは、検索結果部１１３０は、対象地点、例えば、「Ｇｏ Ｊａｐａｎｅｓｅ Ｆｕｓｉｏｎ」という名称の、「食べ物（Food）」カテゴリ内のレストランを含む。「食べ物（Food）」カテゴリは、二重丸内に示すように強調表示されており、近隣のレストラン「Ｇｏ Ｊａｐａｎｅｓｅ Ｆｕｓｉｏｎ」が、ユーザの位置情報及びレストランの位置に基づいて特定されている。別の実施例では、図１１Ｊに示すように、「食べ物（Food）」カテゴリ内の複数の対象地点が、ユーザの対象となると最も予測されており、食べ物カテゴリ内のこれらの対象地点、例えば、Ｃａｆｆｅ Ｍａｃｓ、Ｏｕｔ Ｓｔｅａｋｈｏｕｓｅ、及びＣｈｉｐ Ｍｅｘｉｃａｎ Ｇｒｉｌｌ、が表示され、「食べ物（Food）」カテゴリが強調表示されている。

図１０Ａ～１０Ｃでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法６００及び８００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図１０Ａ～１０Ｃに関連して上述された方法１０００と類似の方式で適用可能であることに留意されたい。例えば、方法１０００を参照して先述したユーザインタフェースオブジェクト（例えば、検索インタフェース内に表示されたそれら）は、任意選択的に、本明細書で説明する他の方法（例えば、方法６００及び８００）を参照して本記載のユーザインタフェースオブジェクトの特性の１つ以上を有する。一部の実施形態では、方法１０００の態様は、以下に説明する方法１２００の態様により、任意選択的に交換又は補足される（及び、その逆）。一部の実施形態では、方法１０００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図１２は、一部の実施形態に係る、検索モードへと移行する方法１２００を示すフローチャートを示す。図１３Ａ～１３Ｂは、図１２の方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法１２００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法１２００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法１２００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法１２００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法１２００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法１２００は、ジェスチャがどこで受信されたかに応じて、電子デバイス上にて関連コンテンツ（例えば、ユーザの現在地に関連するコンテンツを伴う、提案された検索クエリ又はアフォーダンス）を先見的に提案する直感的な方法を提供する。この方法は、ユーザが、最小のユーザ入力数にて、所望するコンテンツを効率的に特定して選択できるようにし、従って、より効率的なヒューマンマシンインタフェースを作り出す（例えば、デバイスは、近隣の対象地点に対する、提案された検索クエリ及びコンテンツを提供し、ユーザは、それらを選択のみする必要があるが、それらを検索して特定する必要はない）。バッテリ動作電子デバイスの場合、より速く、より効率的に、関連コンテンツを先見的に特定し、表面化させることの両方は、電力を節約し、バッテリを充電する間隔を延長する。

図１２に示すように、デバイスは、タッチ感知面を介して、ユーザインタフェース上のスワイプジェスチャを検出する（１２０２）。一部の実施形態では、スワイプジェスチャは、検出されると、電子デバイスに検索モードへと移行させる。スワイプジェスチャを検出したことに応じて、デバイスは検索モードへと移行する。一部の実施形態では、検索モードへと移行することは、検索インタフェース内にいずれのユーザ入力を受け取る前に、ユーザインタフェースとは別個の検索インタフェースを、第１のコンテンツアイテムでポピュレートすることを含む（例えば、検索インタフェース内の検索ボックスにはテキストが入力されず、検索ボックス内では入力が受け取られない（検索ボックス内にはタップがない）など）。

一部の実施形態では、ユーザインタフェースが、アプリケーションを呼び出すための選択可能なアイコンを含む、ホームスクリーンとは別個の、アプリケーションに関連付けられたコンテンツを含む（及び、従って、ａｐｐ特有のコンテンツ上でスワイプジェスチャが検出された）との判定に従って、デバイスは、検索インタフェースを、第１のコンテンツアイテムでポピュレートし、これは、検索インタフェースを、アプリケーションに関連付けられたコンテンツに少なくとも部分的に基づいている、少なくとも１つの提案された検索クエリで、ポピュレートすることを含む。例えば、図１１Ａ～１１Ｂを参照して上述するように、「Ｊｏｈｎ Ａｐｐｌｅｃｏｒｅ」、エクアドル画像、及び／又はテキスト「エクアドル大好き（I love Ecuador）」というコンテンツを伴う電子メールアプリケーション上でのスワイプジェスチャ１１０２に応じて（図１１Ａ）、検索インタフェース１１１５がポピュレートされる（図１１Ｂ）。検索インタフェース１１１５は、電子メールアプリケーションに関連付けられたコンテンツに少なくとも部分的に基づいて、例えば、「Ｅｃｕａｄｏｒ」及び「Ｊｏｈｎ Ａｐｐｌｅｃｏｒｅ」などの、少なくとも１つの提案された検索クエリを含む。別の実施例では、図１１Ｅ～１１Ｆを参照して上述するように、エクアドル及び／又はレーニア山の画像のコンテンツを伴う画像アプリケーション上のスワイプジェスチャ１１０２に応じて（図１１Ｅ）、検索インタフェース１１１５がポピュレートされる（図１１Ｆ）。検索インタフェース１１１５は、画像コンテンツに少なくとも部分的に基づいて、例えば、「Ｅｃｕａｄｏｒ」及び「Ｍｏｕｎｔ Ｒａｉｎｉｅｒ」などの、少なくとも１つの提案された検索クエリを含む。

一部の実施形態では、ユーザインタフェースが、ホームスクリーンのページに関連付けられているとの判定に従って（例えば、スワイプジェスチャが、図１１Ｃの初期ホームスクリーンページ上であった）、検索インタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースを、電子デバイスの現在地の閾値距離内にある少なくとも１つの対象地点の選択可能な説明を含むアフォーダンスでポピュレートすることを含む。例えば、デバイスが、いくつかのレストランのあるモールに近い場合、ユーザがモールに近いということに基づいて、レストランについての情報が、ユーザの対象となると最も予測されているため、提案された検索クエリの代わりに、それらのレストランについての情報を表示する。図１１Ｉ及び１１Ｊを参照して上述された実施例では、ホームスクリーン上のスワイプジェスチャ１１０４を検出したことに応じて（図１１Ｃ）、図１１Ｄに示すように、提案された検索クエリインタフェースを表示することの代わりに、少なくとも１つの近隣の対象地点が、例えば、「Ｇｏ Ｊａｐａｎｅｓｅ Ｆｕｓｉｏｎ」レストラン（図１１Ｉ）、「Ｃａｆｆｅ Ｍａｃｓ」、「Ｏｕｔ Ｓｔｅａｋｈｏｕｓｅ」、及び「Ｃｈｉｐ Ｍｅｘｉｃａｎ Ｇｒｉｌｌ」（図１１Ｊ）、のように、検索インタフェースの検索結果部１１３０内に表示される。図１１Ｉ及び１１Ｊでは、各対象地点はアフォーダンスを含み、及び、例えば、アイコン及び／又は対象地点の説明を選択することが、詳細、値段、メニュー、及び／又は距離情報を提供するなど、それが選択されると、対象地点についての情報を更に提供する、選択可能な説明を含む。

一部の実施形態では、検索インタフェースを、提案された検索クエリで、又は、近隣の対象地点に対するアフォーダンスでポピュレートするか否かについての決定は追加で、又は代替的に、アプリケーションに対するコンテンツを表示することから、所定の期間が経過したか否かに基づく。例えば、（ｉ）ホームスクリーンページ上でスワイプジェスチャが検出された（例えば、コンテンツ上でスワイプジェスチャは検出されていない）、及び（ｉｉ）アプリケーションに関連付けられたコンテンツを表示することからの期間が閾値期間未満である、との判定に従って、検索インタフェースが、少なくとも１つの提案された検索クエリで、依然としてポピュレートされる。従って、そのような実施形態では、コンテンツ上でスワイプジェスチャが検出されていないという判定は、コンテンツを表示することからの期間が閾値期間を満たす、又は閾値期間を超えるという判定を含み（例えば、コンテンツは、ずいぶん前、２分前、３分前、に閲覧された）、続いてデバイスは、そのコンテンツに基づく、提案された検索クエリにユーザは興味があまりない可能性があると判定し、その代わりに、検索インタフェースが、少なくとも１つの対象地点の選択可能な説明を含むアフォーダンスで、ポピュレートされる。このようにして、デバイスが、アプリケーションに関連付けられたコンテンツが最近表示されたと判定しても、ユーザには依然として、提案された検索クエリが提供される。

一部の実施形態では、検索インタフェースを、アフォーダンスでポピュレートすることは、検索インタフェースの検索エントリ部分を表示することを含む（１２０４）。一部の実施形態では、デバイスは、検索エントリ部分での入力を検出し、この、検索エントリ部分での入力（例えば、この内部でのタップ）を検出したことに応じて、電子デバイスは、アフォーダンスの表示を停止し、少なくとも１つの提案された検索クエリを、検索インタフェース内に表示する（１２０６）。例えば、図１３Ａに示すように、検索インタフェースは、検索エントリ部分１１２０と、検索結果部１１３０と、を、近隣の対象地点に対する少なくとも１つのアフォーダンスと共に含む（例えば、図１３Ａに示すように、近隣のレストラン、及び、他の近隣の対象地点に対する選択可能な対象カテゴリ）。検索インタフェースを、近隣の対象地点と共に表示する間に、検索エントリ部分１１２０での入力１３０２、例えば、図１３Ａに示すように、ユーザが、検索ボックス内を入力１３０２にてタップする、が検出される。入力１３０２を検出したことに応じて、図１３Ｂでは、デバイスは、近隣の対象地点に関連付けられた少なくとも１つのアフォーダンスの表示を停止し、提案された検索クエリ、例えば、Ｅｃｕａｄｏｒ、Ｍｏｕｎｔ Ｒａｉｎｉｅｒ、Ｂｅｓｔ Ｓｕｓｈｉなどを、検索結果部１１３０内に表示する。従って、デバイスは、提案された検索クエリと提案された対象地点との間を素早く切り替えることができる（この実施例では、検索ボックス内のユーザタップは、提案された対象地点にユーザが興味ないことを示し、従って、デバイスは、例えば、他のアプリケーションにて以前に閲覧されたコンテンツに基づく、提案された検索クエリなど、異なる種類の提案されたコンテンツを提供するよう試みる）。

少なくとも１つの対象地点の選択可能な説明に関する追加詳細は、図１６Ａ～１６Ｂ及び１７Ａ～１７Ｅに関連して以下に提供される。検索インタフェースを、少なくとも１つの提案された検索クエリでポピュレートすることに関する追加詳細は、図１０Ａ～１０Ｃ及び１１Ａ～１１Ｊに関連して先に提供されている。

図１２での動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法６００、８００、及び１０００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図１２に関連して上述された方法１２００と類似の方式で適用可能であることに留意されたい。例えば、方法１２００を参照して先述したユーザインタフェースオブジェクト及び／又は動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法６００、８００、及び１０００）を参照して本記載のユーザインタフェースオブジェクト及び／又は動作の特性の１つ以上を有する。一部の実施形態では、方法１２００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図１４は、一部の実施形態に係る、タッチ感知ディスプレイを備える電子デバイス上にて車両位置情報を先見的に提供する方法１４００を示すフローチャートを示す。図１５Ａ～１５Ｂは、図１４の方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法１４００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法１４００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法１４００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法１４００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、１つ以上の位置センサ（例えば、加速度計（単数又は複数）１６８、磁気計、及び／又はＧＰＳ受信機）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法１４００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法１４００は、ユーザが位置情報をすぐに必要とする場合に、その情報を先見的に提供する直感的な方法を提供する。この方法は、車両位置情報自体の特定を試みることをユーザに要求することなく、その情報を先見的に提供することにより、及び、駐車した車にユーザが戻るであろうと判定される時にその情報を提供することにより、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、このような方法１４００は、電力を節約し、バッテリを充電する間隔を延長する。

図１４に示すように、デバイスは自動的に、かつユーザからの命令なしに、以下に説明するステップ１４０４及び１４０６を実行する（１４０２）。ステップ１４０４では、デバイスは、電子デバイスのユーザが、ある地理的位置に止まっている車の中に居ると判定する。

一部の実施形態では、車両が地理的位置に止まっていると判定することは、電子デバイスが、閾値期間を超えて地理的位置に留まっている、例えば、デバイスが、閾値速度を超えて移動した後に、約２分間１つのスポットにある、と判定することを含み、これは、車両が駐車中であるというインジケーションを与える。一部の実施形態では、車両が地理的位置に止まっていると判定することは、電子デバイスと車両との間の通信リンクが遮断されている、例えば、デバイスが、車両とのＢｌｕｅｔｏｏｔｈ接続を失っている、及び／又は、デバイスと車両を接続するケーブルをユーザが取り外したなど、と判定することを含み、従って、車両が停止している、及び／又は、車両のエンジンが止められている、というインジケーションが提供される。一部の実施形態では、車両が地理的位置に止まっていると判定することは、地理的位置が、駐車場内の位置に対応すると判定する、例えば、現在のＧＰＳ座標を地図アプリケーションに差し込んで（又は、送信して）この判定を行い、及び、地理的位置が駐車場内にあるか否かについての判定に戻る、ことを含む。

一部の実施形態では、上記判定のうちの１つ以上は、車両が地理的位置に止まっているか否かを判定するためにのみ行われ、他の実施形態では、これらの判定のうちの２つ以上が実行される一方で、更に他の実施形態では、これらの判定の３つ全てが、車両が地理的位置に止まっているか否かを査定するために実行される。例えば、一部の実施形態では、地理的位置に止まっている車両内にユーザが居ると判定することは、以下を含む。（ｉ）上述するように、閾値速度を超えて電子デバイスが移動していると判定することにより、ユーザが車の中に居ると判定すること、及び（ｉｉ）以下のうちの１つ以上により、車両が地理的位置に止まっていると判定すること。（ａ）上述するように、閾値期間を超えて、電子デバイスが地理的位置に留まっていると判定すること、（ｂ）上述するように、電子デバイスと車両との間の通信リンクが遮断されていると判定すること、及び（ｃ）上述するように、地理的位置が、駐車場内のとある位置に対応すると判定すること。

ステップ１４０６では、デバイスは、ユーザが車両を離れたか否かを更に判定する。一部の実施形態では、デバイスは、デバイスの現在位置が、地理的位置から閾値距離を超えて離れていると判定することにより、判定を実行する。一部の実施形態では、デバイスは、ユーザが、車両との接続からデバイスを物理的に切り離した、又は、ユーザが、デバイスと車両との間の無線接続（例えば、Ｂｌｕｅｔｏｏｔｈに基づく接続又はＷｉＦｉに基づく接続）を切り離したと判定することにより、判定を実行する。ユーザが地理的位置にて車両を離れたことを、（十分に高い信頼性をもって）確立するために使用される判定に関する追加詳細を、以下に提供する。

ユーザが地理的位置にて車両を離れたと判定すると、デバイスは、地理的位置を特定するために位置センサから取り出した位置情報が、精度基準を満たすか否かを判定する（１４０８）。一部の実施形態では、精度基準は、位置情報に関連付けられたＧＰＳ読み値の精度が閾値精度レベルを超える場合に満たされる基準を含む（例えば、１０メートル以下の平均誤差半径）。

位置情報が精度基準を満たさないと判定すると（１４０８－Ｎｏ）、デバイスは、地理的位置についての情報を入力するというプロンプトをユーザに提供し、このプロンプトを提供したことに応じて、デバイスは、地理的位置についての情報をユーザから受信し、この情報を車両位置情報として記憶する（１４１０）。一部の実施形態では、このプロンプトは、電子デバイスを介して利用可能なバーチャルアシスタントにより提供されるオーディオプロンプトである。プロンプトがオーディオプロンプトである場合、ユーザから情報を受信することは、地理的位置を特定する口頭説明をユーザから受信することを含む。一部の実施形態では、バーチャルアシスタントからのプロンプトは、地理的位置にて、車の写真を撮る、及び／又は、車の周りの写真を撮るようユーザに指示する。一部の実施形態では、ユーザは、地理的位置の口頭説明を提供するよう指示される。

一部の実施形態では、位置情報が精度基準を満たすと判定すると（１４０８－Ｙｅｓ）、デバイスは、自動的に、かつユーザからの命令なしに、位置情報を車両位置情報として記憶する（１４１２）。一部の実施形態では、位置情報が十分に正確である（例えば、精度基準を満たす）場合、ユーザにはプロンプトが続いて提供されない。他の実施形態では、位置情報が十分に正確であっても、デバイスは依然として、地理的位置に関する追加詳細を、（動作１４１０に関連して上述するように、口頭、テキスト、又は、写真を撮ることにより）提供するようユーザを促す。これは、これらの追加詳細を記憶し、例えば、ユーザが車に戻る際に、デバイスが強いＧＰＳ信号を受信できない場合に、これらをユーザに提示するためである。

一部の実施形態では、デバイスは、ユーザが地理的位置に向かっているか否かを更に判定する（１４１４）。一部の実施形態では、ユーザが地理的位置に向かっているか否かを判定することは、電子デバイスが地理的位置に向かって移動していると判定するために、位置センサから受信した新たな位置情報を使用することを含む。一部の実施形態では、ユーザが地理的位置に向かっているか否かを判定することは、以下を含む。（ｉ）閾値期間を超えて異なる地理的位置に電子デバイスが留まっていると判定すること（例えば、ショッピングモール、レストラン、ユーザにとって既知の自宅又は職場住所など、に関連付けられた場所／位置）、及び（ｉｉ）電子デバイスが、異なる地理的位置から離れて、地理的位置に向かって移動していることを、新たな位置情報が示すと判定すること。一部の実施形態では、デバイスは追加で、又は代替的に、ユーザが地理的位置に向かっているか否かを判定するために、地理的位置を撮った写真を、ユーザの現在地の画像と比較する（例えば、画像内の、共通の、又は重畳するビジュアル要素を認識することにより）。一部の実施形態では、デバイスは追加で、又は代替的に、車両とのデータ接続をユーザが確立又は検索できる設定ユーザインタフェースにユーザがアクセスしていることを検出し、このようにして、デバイスは、ユーザが地理的位置に向かっていることのインジケーションを有する。

一部の実施形態では、ユーザが地理的位置に向かっているとの判定に従って、デバイスは、車両位置情報を含むユーザインタフェースオブジェクトを表示する。一部の実施形態では、ユーザインタフェースオブジェクトは、ユーザの現在地に対する識別子と、地理的位置に対する別個の識別子と、を含む地図オブジェクトである。例えば、図１５Ａに示すように、検索ユーザインタフェースは、検索入力部分１１２０と、検索結果部１１３０と、を含み、検索結果部１１３０は、ドットにより特定された地理的位置での車両位置情報と、ピンにより別々に特定された、位置ラベル「Ｉｎｆｉｎｉｔｅ Ｌｏｏｐ ２」と、ユーザの現在地と、を含む地図オブジェクトである。

一部の実施形態では、ユーザインタフェースオブジェクトは、電子デバイスのロックスクリーン上に表示される。例えば、図１５Ｂに示すように、地図オブジェクトが、ロックスクリーン上に表示される。従って、自動的に、かつユーザからの命令なしに、デバイスは、相対的に正確な位置情報に基づいて車を探すことが、ユーザの対象となると予測されていることを予測し、ユーザが電子デバイスをロック解除することなく、車の位置を示す地図を提供する。

一部の実施形態では、ユーザインタフェースオブジェクトは、電子デバイスに検索モードへと移行させるスワイプジェスチャに応じて表示される。一部の実施形態では、ユーザが地理的位置に向かっているか否かを判定することは、同じスワイプジェスチャを受信したことに応じて実行される。従って、同じスワイプジェスチャは、デバイスに、ユーザが地理的位置に向かっていると判定させ、相対的に正確な位置情報に基づいて、ユーザインタフェースオブジェクトを表示する。

一部の実施形態では、検索モードは、ユーザインタフェースオブジェクト、例えば、地理的位置に対応する識別子を含む地図オブジェクト、を含むよう事前にポピュレートされる検索インタフェースを表示することを含む。つまり、検索インタフェース内にユーザからいずれのユーザ入力を受け取る前に（例えば、ユーザがいずれの検索クエリを入力する前に）、検索インタフェースは、地図オブジェクトを含むようポピュレートされ、車を駐車した地理的位置についてのビジュアルリマインダへのクイックアクセスがユーザに提供されるようにする（例えば、図１５Ａの、ユーザインタフェースオブジェクト１１３０又はユーザインタフェースオブジェクト１５３５、若しくは両方）。一部の実施形態では、スワイプジェスチャは実質的に左右方向であり、このスワイプジェスチャは、電子デバイスが、ホームスクリーンの初期ページを表示している間に、ユーザにより提供される（例えば、図１１Ｃの１１０４－１）。一部の状況では、スワイプジェスチャは実質的に下向き方向であり、アプリケーションに関連付けられたコンテンツを閲覧中に、ユーザにより提供される（例えば、図１１Ａ及び１１Ｅの１１０２）。

一部の実施形態では、ユーザが地理的位置に向かっていると判定することと併せて（動作１４１４に関連して上述するように）、デバイスはまた、地理的位置に戻る正確な方向をデバイスが提供できるようにするために、電子デバイスの位置センサに関連付けられた現在のＧＰＳ信号が十分に強いか否かを判定し、このＧＰＳ信号が十分に強くないとの判定に従って、続いてデバイスは、位置情報及びユーザからの追加詳細の両方を提供し、駐車した車の位置の特定を補助するために、両方の情報の断片にユーザが頼ることができるようにする。

一部の実施形態では、このプロンプトは、電子デバイスを介して利用可能なバーチャルアシスタントにより提供されるオーディオプロンプトであり（動作１４１０に関連して上述するように）、ユーザから情報を受信することは、地理的位置を特定する口頭説明をユーザから受信することを含み、ユーザインタフェースオブジェクトを表示することは、選択されると、デバイスに口頭説明を再生させる、選択可能なアフォーダンス（例えば、図１５Ａ～１５Ｂのアフォーダンス１５０２）を表示することを含む。一部の実施形態では、バーチャルアシスタントからのプロンプトは、地理的位置にて車の写真を撮る、及び／又は、車の周りの１つ以上の写真／動画を撮るよう、ユーザに指示し、ユーザインタフェースオブジェクトを表示することは、選択されると、デバイスに記録したメディアを再生させる、選択可能なアフォーダンス（例えば、図１５Ａ～１５Ｂのアフォーダンス１５０２）を表示することを含む。一部の実施形態では、選択可能なアフォーダンスは、地図オブジェクトに近接して表示される一方で（アフォーダンス１５０２に対して示すように）、他の実施形態では、選択可能なアフォーダンスは、それ自体が表示される（特に、位置情報が精度基準を満たさない状況において、この他の表示フォーマットの１つの実施例を、図１５Ａ～１５Ｂのアフォーダンス１５３５に対して示す）。一部の実施形態では（ユーザにより提供された位置情報に加えて、位置情報が提供されているか否かにより）、駐車した車にユーザが向かっていると判定されると、アフォーダンス１１３０及び１５３５の１つ又は両方が表示される。

一部の実施形態では、ユーザインタフェースオブジェクト／アフォーダンス（例えば、１１３０、１５３５、又は両方）は、駐車した車に到着するまでの予測距離を含む（例えば、ユーザインタフェースオブジェクト１１３０は、右上角に「０．３ｍｉ」を含む）。

一部の実施形態では、プロンプトが電子デバイスのディスプレイ上に表示され、ユーザから情報を受信することは、地理的位置を特定するテキスト説明をユーザから受信することを含み、ユーザインタフェースオブジェクトを表示することは、ユーザからのこのテキスト説明を表示することを含む。他の実施形態では、選択可能なアフォーダンスは、テキスト説明にユーザがアクセスできるよう表示される。例えば、アフォーダンス１５３５（図１５Ａ～１５Ｂ）の選択に応じて、デバイスは、ユーザからのテキスト説明を含むメモアプリケーションを開く。

図１４での動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法６００、８００、１０００、及び１２００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図１４に関連して上述された方法１４００と類似の方式で適用可能であることに留意されたい。例えば、方法１４００を参照して先述したユーザインタフェースオブジェクトは、任意選択的に、本明細書で説明する他の方法（例えば、方法６００、８００、１０００、及び１２００）を参照して本記載のユーザインタフェースオブジェクトの特性の１つ以上を有する。更に、セクション１～１１に関連して以下に説明する詳細、動作、及びデータ構造はまた、方法１４００と合わせて使用されてよい（例えば、セクション６に関連して説明される詳細は、ユーザの駐車した車の位置を含むユーザインタフェースオブジェクトをいつ提示するかの決定を補助するために使用されてよく、セクション５に関連して説明される詳細は、ユーザがいつも車をいつ駐車し、後にいつ戻るかに関するユーザパターンの特定及び学習を補助するために使用されてよく、セクション１０に関連する詳細は、コンテキスト情報に依拠することでの車両位置情報の改善を補助するために使用されてよい）。一部の実施形態では、方法１４００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの他の関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図１６Ａ～１６Ｂは、一部の実施形態に係る、近隣の対象地点（ＰＯＩ）についての情報を先見的に提供する方法１６００を示すフローチャートを示す。図１７Ａ～１７Ｅは、図１６Ａ～１６Ｂの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法１６００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法１６００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法１６００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法１６００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、１つ以上の位置センサ（例えば、加速度計（単数又は複数）１６８、磁気計、及び／又はＧＰＳ受信機）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法１６００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法１６００は、対象地点情報自体をユーザに検索させ、特定させる必要なく、電子デバイス上にその情報を先見的に提供する（及び、続いて、ユーザが、特定のＰＯＩの特定の距離内に居る場合に、その情報を表面化させる）。この方法は従って、所望するアクションを実行するためのタッチ入力の数を減らすことにより、より効率的なヒューマンマシンインタフェースを作り出す（例えば、近隣のＰＯＩについての情報を閲覧すること）。バッテリ動作電子デバイスの場合、このような方法１６００は、電力を節約し、バッテリを充電する間隔を延長する。

図１６Ａに示すように、電子デバイスのユーザからのいずれの命令を受信することなく、デバイスは、位置センサを使用して、電子デバイスの地理的位置を監視する（１６０２）。電子デバイスのユーザからのいずれの命令も受信することなく、デバイスは、監視した地理的位置に基づいて、電子デバイスが、所定の種類の対象地点（例えば、レストラン、アミューズメントパーク、又は映画館などの、アクティビティ提案が利用可能な対象地点）の閾値距離内にあると判定する。

一部の実施形態では、所定の種類の対象地点は、ユーザがたびたび訪れる対象地点に基づいて判定される。一部の実施形態では、対象地点はまた、現在のテキストメッセージ、電子メール、及び／又はユーザのソーシャルネットワークに関連付けられた他のデータに基づいて、ユーザの対象となると予測された対象地点を含む。

電子デバイスのユーザからのいずれの命令を依然として受信することなく、電子デバイスが、対象地点の閾値距離内にあると判定することに従って、デバイスは、対象地点にて現在人気の少なくとも１つのアクティビティを特定し、対象地点にて現在人気の少なくとも１つのアクティビティについての情報を取り出することを含む、その対象地点についての情報を取り出す（例えば、現在人気の乗り物、人気のメニューアイテム、人気の映画など）。一部の実施形態では、人気は、ユーザのソーシャルネットワーク内の個々人の閾値数（例えば、５人超）又は閾値パーセンテージ（例えば、５％又は１０％）が、少なくとも１つのアクティビティに関連するどれに投稿されたか否かに基づいて査定される。一部の実施形態では、デバイスは、ユーザがたびたび訪れる所定の数の対象地点（例えば、５、１０、又は２０）のリスト（及び／又は、上述するように、テキストメッセージ、電子メール、又はユーザのソーシャルネットワーク内のアクティビティに基づいて現在の対象となると判定されている対象地点）を維持し、デバイスは、ユーザがそれらのいずれかの閾値距離内に居る際の、それらの対象地点での現在のアクティビティについての情報を取り出する（例えば、１マイル、１．５マイル、２マイル）。

図１６Ａを更に参照すると、対象地点についての情報を取り出した後、デバイスは、検出されると、電子デバイスに検索モードへと移行させる第１の入力を、タッチ感知面を介して検出する（１６１６）。一部の実施形態では、検索モードは、電子デバイス全体にわたって検索を実行することができる、システムレベルの検索モードである（例えば、単一のアプリケーション内のみでなく、アプリケーション及びコンテンツソース（オンデバイス及び全体の両方）にわたって）。一部の実施形態では、第１の入力は、ホームスクリーンの初期ページをデバイスが表示している間に受信された、タッチ感知面にわたるスワイプジェスチャ（例えば、図１１Ｃの、実質的に左右方向のスワイプジェスチャ１１０４－１）方向に対応する。

一部の実施形態では、デバイスが、対象地点の閾値距離内にあると判定することに従って、デバイスはまた、対象地点での現在のアクティビティについての情報が利用可能であることを示すアフォーダンスを、ロックスクリーン上に表示する。これらの実施形態では、第１の入力は、対象地点での現在のアクティビティについての利用可能な情報を閲覧することの要求に対応する。例えば、図１７Ｄに示すように、レストラン情報オブジェクトが、ロックスクリーン上に表示される。レストランのアイコン及び／又は説明は選択可能であり、レストランについての、メニュー情報などの更なる情報が利用可能であることを示す。第１の入力、例えば、「メニューを見る（View Menu）」リンク上のタップ、に応じて、メニューが表示される（例えば、ロックスクリーン上に直接、又は、デバイスをロック解除して、メニューを閲覧するための適切なアプリケーションを開くことにより）。一部の実施形態では、図１７Ａ～１７Ｅに示すユーザインタフェースオブジェクト／アフォーダンスのいずれか（例えば、１７１３及び１７１５、並びにそこに含まれるコンテンツ）が、検索インタフェース内又はロックスクリーン内（若しくは、両方）に提示されてよい。

図１６Ｂに戻ると、第１の入力を検出したことに応じて、デバイスは検索モードへと移行する（１６１８）。一部の実施形態では、検索モードへと移行することは、検索インタフェースにていずれのユーザ入力を受け取る前に（例えば、検索タームが入力されていない、及び、検索インタフェース内の検索ボックスにて入力を受け取らない）、ディスプレイを介して、（ｉ）少なくとも１つのアクティビティについての情報、及び（ｉｉ）対象地点にて現在人気なものとして、少なくとも１つのアクティビティが特定されていることのインジケーション、例えば、近隣のレストランでの人気のメニューアイテム（例えば、図１７Ｃ～１７Ｄのアフォーダンス１７１５）、近隣のアミューズメントパークでの乗り物の待ち時間（例えば、図１７Ａ～１７Ｂのアフォーダンス１７１３）、近隣の映画館での現在の上映時間などを含むアフォーダンスを提示することを含む。

例えば、図１７Ａに示すように、一部の実施形態では、対象地点はアミューズメントパーク（１６０４）であり、取り出した情報は、アミューズメントパークでの乗り物の現在の待ち時間を含む。一部の実施形態では、及び、図１７Ａに示すように、電子デバイスは、この取り出した情報を使用して、全ての乗り物に対する平均待ち時間（例えば、１時間）を提示し、ユーザは、各個々の乗り物に対する待ち時間を見るためのリンクを選択できる。図１７Ｂに示すように、一部の実施形態では、取り出した情報の一部は、電子デバイスの所定の距離内に位置する乗り物に対する待ち時間についての情報を含み（１６０６）、例えば、電子デバイスから約１００～１５０フィートの距離内に３つの乗り物／ゲームがあり、各乗り物／ゲームに対する待ち時間が（図１７Ａに示す「待ち時間を見る（View Wait Times）」テキスト上の入力などの、乗り物の待ち時間を閲覧することを要求するユーザからの入力を受信した後に）表示される。

別の実施例として、図１７Ｃに示すように、対象地点はレストラン（１６０８）であり、取り出した情報は、レストランでの人気のメニューアイテムについての情報を含む。一部の実施形態では、取り出した情報は、電子デバイスのユーザに関連付けられたソーシャルネットワークから取り出される（１６１０）。例えば、図１７Ｃでは、レストラン「Ｇｏ Ｊａｐａｎｅｓｅ Ｆｕｓｉｏｎ」での人気のメニューアイテム「Ｙａｋｉｎｉｋｕ Ｋｏｊｉ」が、アフォーダンス１７１５内に表示され、この人気のメニューアイテムは、電子デバイスのユーザに関連付けられたソーシャルネットワークから取り出した情報に基づいて判定されてよい。

１つの追加的実施例として、対象地点は映画館（１６１２）であってよく、取り出した情報は、映画館の上映時間についての情報を含む。一部の実施形態では、上映時間についての取り出した情報は、電子デバイスのユーザに関連付けられたソーシャルネットワークから取り出される（１６１４）（例えば、ユーザのソーシャルネットワーク内の個々人により最近投稿された情報に基づいて）。

一部の実施形態では、デバイスは、第２の入力、例えば、アフォーダンス付近（例えば、上）に表示されている「更に表示（show more）」リンク（図１７Ａ～１７Ｄのアフォーダンス１７１３及び１７１５に対して示される、「更に表示（show more）」リンクなど）の選択、を検出し（１６２０）、この第２の入力を検出したことに応じて、デバイスは、対象地点とは別個の、第２の対象地点での現在のアクティビティについての利用可能な情報を含むよう、このアフォーダンスを更新する。一部の実施形態では、第２の対象地点もまた、電子デバイスの閾値距離内にある。例えば、図１７Ｄに示す、「更に表示（show more）」リンクをユーザが選択したことに応じて、デバイスは、図１７Ｃに示すように、レストラン及び、電子デバイスの１マイル以内にある異なるレストラン「Ｏｕｔ Ｓｔｅａｋｈｏｕｓｅ」での食べ物についての利用可能な情報を含むよう、アフォーダンス１７１５を更新する。別の方法で説明すると、アフォーダンス１７１５は、「Ｇｏ Ｊａｐａｎｅｓｅ Ｆｕｓｉｏｎ」についての情報のみと共に初期的に提示され、第２の入力に応じて、アフォーダンス１７１５は、第２の対象地点についての情報（例えば、図１７Ｃの点線内に示す、「Ｏｕｔ Ｓｔｅａｋｈｏｕｓｅ」についての情報）を含めるよう更新される。一部の実施形態では、対象地点とは別個の１つを超える対象地点が、第２の入力を検出したことに応じて表示され、例えば、デバイスは、対象地点に加えて、２つ以上の新たなレストランについての利用可能な情報を含むよう、レストラン情報アフォーダンスを更新する。一部の実施形態では、同じ機能（すなわち、「更に表示（show more）」リンクの選択に応じて、追加対象地点についての情報をユーザが閲覧できる機能）もまた、ロックスクリーン上に提示されたアフォーダンスに対して利用可能である（例えば、図１７Ｄの、ロックスクリーン上に示すアフォーダンス１７１５）。

一部の実施形態では、アフォーダンスは、対象地点の選択可能なカテゴリを更に含み（１６２２）、デバイスは、それぞれの選択可能なカテゴリの選択を検出し、選択を検出したことに応じて、デバイスの第２の閾値距離内に位置する追加対象地点についての情報を含むよう、アフォーダンスを更新する（１６２４）。例えば、まだ選択されていない、ユーザの対象となる可能性のある最寄りの対象地点を取得するために、第２の閾値は、閾値距離より大きい。例えば、第１の閾値距離は１００フィートである。電子デバイスがその対象地点から約５０フィートの距離にある場合に、デバイスは、図１７Ｃ及び１７Ｄに示すように、「Ｇｏ Ｊａｐａｎｅｓｅ Ｆｕｓｉｏｎ」を対象地点として表示する。図１７Ｅに示すように、「食べ物（Food）」カテゴリの選択を検出したことに応じて、追加対象地点、例えば、デバイスから１００フィートを超えるものの、１マイル以内に位置する「Ｏｕｔ Ｓｔｅａｋｈｏｕｓｅ」及び「Ｃｈｉｐ Ｍｅｘｉｃａｎ Ｇｒｉｌｌ」、が表示される。

一部の実施形態では、電子デバイスをロック解除した後、電子デバイスのホームスクリーンの初期ページ上の実質的に水平方向（例えば、図１１Ｃの左右スワイプ１１０４－１）でのスワイプに応じて、ユーザインタフェースオブジェクトが利用可能となる（１６２６）。

図１６Ａ～１６Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法６００、８００、１０００、１２００、及び１４００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図１６に関連して上述された方法１６００と類似の方式で適用可能であることに留意されたい。例えば、方法１６００を参照して先述したユーザインタフェースオブジェクト及び／又は動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法６００、８００、１０００、１２００、及び１４００）を参照して本記載のユーザインタフェースオブジェクト及び／又は動作の特性の１つ以上を有する。一部の実施形態では、方法１６００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図１８Ａ～１８Ｂは、一部の実施形態に係る、音声通信からコンテンツアイテムを抽出し、その抽出したコンテンツアイテムと相互作用する方法１８００を示すフローチャートである。図１９Ａ～１９Ｆは、図１８Ａ～１８Ｂの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法１８００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法１８００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法１８００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法１８００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法１８００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法１８００は、音声通信からコンテンツアイテムを抽出し、タッチ感知ディスプレイを備える電子デバイス上にてそれらをユーザに提示する直感的な方法を提供する。この方法は、ユーザからの必要な入力の数を減らし（例えば、デバイスが、連絡先に対する関連情報、位置、及びイベントを自動的に抽出し、その情報を、デバイス上での記憶及び使用のために準備し）、従って、より効率的なヒューマンマシンインタフェースを作り出し、音声通信にて話された内容に基づいて、新たなコンテンツアイテムをユーザが加えることをアシストする。バッテリ動作電子デバイスの場合、この方法は、電力を節約し、バッテリを充電する間隔を延長することの両方を補助する。

図１８Ａに示すように、デバイスは、音声通信の少なくとも一部を受信し、その音声通信の一部は、電子デバイスのユーザとは別個の、リモートデバイスのリモートユーザにより提供されたスピーチを含む（１８０１）。一部の実施形態では、音声通信は、ライブの電話呼び出し、ライブのビデオ呼び出し（例えば、ＦａｃｅＴｉｍｅ呼び出し）、又は録音された音声メール（１８０３）である。一部の実施形態では、音声通信は、ユーザとリモートユーザとの間のライブの電話呼び出し（又は、ＦａｃｅＴｉｍｅ呼び出し）であり、従って、音声通信は、ユーザ及びリモートユーザの両方により提供されたスピーチを含む。他の実施形態では、音声通信は、リモートユーザによりユーザに送信された、録音された音声メールであり、録音された音声メールは、リモートデバイスから電子デバイスへ、遠距離通信ネットワークを介して配信され、録音された音声メールは続いて、後の再生のために電子デバイス上に記憶される。

一部の実施形態では、音声通信の一部は、電子デバイスのユーザからの命令に基づいて特定される（１８０５）。例えば、この部分には、ユーザの、ハードウェアボタンの選択に基づく分析のために、電子デバイスのユーザによりフラグが立てられ（例えば、ユーザが、単にボリュームボタンとしてのハードウェアボタンをタップし、これに応じて、デバイスは、所定の量の音声通信の分析を開始する（例えば、前の１０、９、８、又は７秒間））、コンテンツアイテムが検出／抽出される。一部の実施形態では、ボタンはまた、電子デバイスのディスプレイ上にユーザ選択のために提示されたボタンであってよい（例えば、テキスト「ここをタップして、新たなコンテンツについてこの音声通信を分析する（tap here to analyze this voice communication for new content）」を含む音声通信中に、図２１Ｂに示すユーザインタフェースと同様のユーザインタフェース上に表示されたボタン）。

一部の実施形態では、ユーザからの命令は、フレーズ「ヘイ、シリ（hey Siri）」を含む口頭コマンドに対応する（例えば、「ヘイ、シリ、それを記憶して（hey Siri, please save that）」、「ヘイ、シリ、それを覚えておいて（hey Siri, please remember that）」、又は「ヘイ、シリ、さっき言ったイベントを詳しく知りたい（hey Siri, please grab the event details that were just mentioned）」など）。一部の実施形態では、ユーザからの口頭命令は、デバイスに音声通信の分析を開始させ、新たなコンテンツを検出させる、いずれの所定のフレーズである（例えば、フレーズは、英語以外の一部の他の言語であり得、又は、フレーズは、「シリ、この呼び出しを分析して（Siri, please analyze this call）」、「シリ、分析を始めて（Siri, please begin analyzing）」、又は、有効な他の言葉などの、異なる単語を含み得る）。

一部の実施形態では、デバイスは、音声通信のいずれの一部も永続メモリ内に記録又は維持しないが、その代わりにデバイスは、音声通信の一部（例えば、一度に１０秒間）のみを分析し、記録されたデータの全てをすぐに削除し、分析に基づいて抽出されたコンテンツアイテムのみを記憶する（以下に詳述するように）。このようにして、抽出されたコンテンツアイテムがユーザに利用可能となるが、音声通信の実際のコンテンツは記憶されず、従って、ユーザプライバシーの保護を補助する。

一部の実施形態では、デバイスは、音声通信の一部（例えば、録音された音声メール、又は、デバイスのユーザと、異なるデバイスの、別のリモートに位置するユーザとの間のライブの電話呼び出しのユーザによりフラグが立てられた一部、又は、抽出のための新たなコンテンツを含むとして、デバイスにより自動的に特定された一部）を分析し（１８０７）所定の種類のコンテンツを検出する。一部の実施形態では、音声通信を分析することは、以下を含む（１８０９）。リモートユーザにより提供されたスピーチ（及び、該当する場合、電子デバイスのユーザにより提供されたスピーチ）をテキストに変換すること、自然言語処理アルゴリズムをテキストに適用し、そのテキストが、１つ以上の所定のキーワードを含むか否か判定すること、かつそのテキストが、それぞれの所定のキーワードを含むとの判定に従って、その音声通信が、コンテンツアイテムを説明するスピーチを含むと判定すること。

別の方法で説明すると、音声通信は、スピーチからテキストへの処理アルゴリズムに渡され、スピーチからテキストへの処理により生成されたテキストに対して自然言語処理が実行され、続いて、そのテキストが、１つ以上の所定のキーワードのいずれかを含むか否かを電子デバイスが判定する。一部の実施形態では、自動化されたスピーチ認識アルゴリズムが使用される（例えば、スピーチからテキストへの処理動作及び自然言語処理動作を実行することを補助するため）。一部の実施形態では、１つ以上の所定のキーワードは、テキスト内のキーフレーズ／文字列を特定するために使用されるデータ検出部を含み、これらは、提案された出力を提供するために使用される（例えば、上述する、選択可能な説明）。一部の実施形態では、この全体プロセス（スピーチのテキストへの変換、及び、新たなコンテンツを検出するためのそのテキストの処理）は全て、電子デバイス上で実行され、これらの動作を実行することを補助するサーバ又はいずれの外部デバイスも使用されず、このようにして、ユーザのプライバシーが維持され、保護される。一部の実施形態では、音声通信の分析中に環状バッファが使用され（例えば、１０秒以下の音声通信を含む小型環状バッファ）、環状バッファ内のデータが、スピーチの記憶及び書き出しに使用され、これもまた、プライバシーを保護する。なぜなら、会話全体が記録、監視、又は記憶されないからである。このようにして、デバイスは、素早く、効率的に、音声通信を処理し、新たなイベント、新たな連絡先情報、及び他の新たなコンテンツアイテムを検出できる。

一部の実施形態では、音声通信から抽出される可能性のある、特定の種類のコンテンツ（例えば、電話番号）について、１つ以上の所定のキーワードの検索の代わりに、又は、これに加えて、デバイスはまた、自然言語処理アルゴリズムにより生成されたテキストが、所定の桁数を含むか否かをチェックする（例えば、米国用電話番号については１０又は１１）。一部の実施形態では、両方の技術が使用される（例えば、デバイスは、「電話番号」などの所定のキーワードを探し、続いてすぐに、参照された電話番号を特定するために、テキスト内の所定の桁数を検索する）。

一部の実施形態では、分析（例えば、動作１８０７及び１８０９）は、音声通信が、電子デバイスと通信するオーディオシステムを介して出力されている間に実行される。一部の実施形態では、所定の種類のコンテンツは、音声通信上で話されている、連絡先、イベント、及び／又は位置情報に関連する情報コンテンツを含む（音声通信からの位置情報の検出及び抽出に関する追加詳細は、以下に提供される）。例えば、音声通信を分析して所定の種類のコンテンツを検出することは、新たな連絡先情報（連絡先及び既存の連絡先に対する新たな連絡先情報を含む）及び新たなイベント（又は、既存のイベントを変更することに関するコンテンツ）を分析して検出することを含む。一部の実施形態では、オーディオシステムは、デバイスの内部スピーカ、外部ヘッドホン、又は、スピーカ若しくは車両のステレオシステムなどの外部オーディオシステムである。

一部の実施形態では、デバイスは、リモートデバイスのリモートユーザにより提供されたスピーチに少なくとも部分的に基づいて、コンテンツアイテムを抽出する（１８１１）（例えば、コンテンツアイテムを特定する又は説明するスピーチ、例えば、来るイベントについての詳細（開始時間、終了時間、場所、参加者など）、連絡先情報（電話番号、連絡先氏名、雇用主名など）、レストラン名、電話番号、対象地点への道順、及び、スピーチからコンテンツアイテムを抽出するために使用され得る他の詳細説明）。一部の実施形態では、コンテンツアイテムは、電子デバイスのユーザにより提供されたスピーチに少なくとも部分的に基づいて、同様に抽出される（例えば、両方のユーザが、イベントの詳細について話しており、デバイスは、両方のユーザにより提供されたスピーチに基づいて、これらのイベントの詳細を抽出する）（１８１５）。

一部の実施形態では、コンテンツアイテムは、新たなイベント、電子デバイス上でカレンダーアプリケーションに現在関連付けられたイベントについての、新たなイベントの詳細、新たな連絡先、及び、電子デバイス上の電話アプリケーションに関連付けられた既存の連絡先についての、新たなコンテンツ情報、である（１８１３）。

一部の実施形態では、電子デバイスは、コンテンツアイテムが、電子デバイス上で現在利用可能であるか否かを判定する（１８１７）。

図１８Ｂに戻ると、コンテンツアイテムが、電子デバイス上で現在利用可能でないとの判定に従って、電子デバイスは、コンテンツアイテムに関連付けられたアプリケーションを特定し、コンテンツアイテムの選択可能な説明をディスプレイに表示する（１８２１）。図１９Ａは、ユーザが現在音声通信（例えば、ライブの電話呼び出し）に参加している間に、選択可能な説明１９０２が表示されている、１つのユーザインタフェース例を示す。図１９Ａに示すように、選択可能な説明１９０２は、特定された、関連するアプリケーションのアイコン（例えば、カレンダーアプリケーションのアイコン）、コンテンツアイテムの説明（例えば、この電話呼び出しにて新たなイベントが見つかったことを示すテキスト）、及び、コンテンツアイテムについての詳細（例えば、新たなイベントに関連付けられたイベント詳細）を含む。

一部の実施形態では、選択可能な説明を表示することは、電話アプリケーションを使用して最近実行された呼び出しを含むユーザインタフェース内に、選択可能な説明を表示することを含む（１８２３）。一部の実施形態では、最近の呼び出しを含むユーザインタフェースは、音声通信の終了後に表示される（すなわち、選択可能な説明１９０２がまず、ユーザが電話をしている間に表示され、最近の呼び出しを含むユーザインタフェースが続いて、その電話の終了後に表示される）。例えば、図１９Ｂは、音声通信から抽出されたコンテンツアイテムについての、選択可能な説明１９０１、１９０３、及び１９０５を含む、１つのユーザインタフェース例を示す。特に、選択可能な説明１９０１は、第１の電話呼び出しにて新たなイベントが見つかったことを示し、選択可能な説明１９０３は、第２の電話呼び出しにて新たな連絡先情報が見つかったことを示し、及び選択可能な説明１９０５は、第３の電話呼び出しにて場所が見つかったことを示す。上述するように、音声通信はまた、録音された音声メールであり得、従って、図１９Ｂに示すユーザインタフェースはまた、電話アプリケーションの音声メールタブ内に表示されてよい。

一部の実施形態では、選択可能な説明は、コンテンツアイテムが音声通信に関連付けられたことのインジケーションと共に表示される。例えば、選択可能な説明１９０１～１９０５のそれぞれが、それらが抽出された音声通信に隣接して表示され、それらは、各抽出されたコンテンツアイテムに関連付けられた音声通信のそれぞれの明確なインジケーションをユーザに提供する。

コンテンツアイテムが電子デバイス上で現在利用可能でないという判定に従って、電子デバイスはまた、新たなコンテンツアイテムが検出されたというフィードバックをユーザに提供する（１８２５）。一部の実施形態では、フィードバックを提供することは、選択可能な説明を表示することと併せて実行される（すなわち、フィードバックを表示して提供することは、実質的に同時に実行され、ユーザは、触覚フィードバックを受信できるようになり、これは続いてユーザを、音声通信中に選択可能な説明１９０２が表示されるディスプレイの閲覧に向ける）。一部の実施形態では、フィードバックを提供することは、電子デバイスに近接する異なる電子デバイスに、コンテンツアイテムの検出に関する情報を送信することを含む（１８２７）（例えば、近隣のラップトップ又は携帯時計に情報を送信することで、ユーザは耳から電話を離すことなく、検出された新たなコンテンツアイテムに関する詳細を見ることができる）。

一部の実施形態では、選択可能な説明の選択を検出したことに応じて（例えば、図１９Ａ又は１９Ｂのどちらかに示すユーザインタフェースにて提供されているユーザ入力）、電子デバイスは、特定されたアプリケーションでの提示のために、コンテンツアイテムを記憶する（１８２９）。選択可能な説明は、ユーザが音声通信を聞いている間に（例えば、図１９Ａの選択可能な説明１９０２上でタップすることにより）、又は、最近の呼び出しを含むユーザインタフェースから選択可能な説明を選択することにより（例えば、図１９Ｂの選択可能な説明１９０１上でタップすることにより）選択されてよい（１８３１）。この選択に応じて、コンテンツアイテムは、特定されたアプリケーション（例えば、抽出された連絡先アイテムの種類により、カレンダーアプリケーション又は連絡先アプリケーション）と共に記憶される。例えば、選択可能な説明１９０２又は１９０１のどちらかの選択に応じて、電子デバイスは、新規イベント作成ユーザインタフェースを開き、その新規イベント作成ユーザインタフェースを、音声通信の一部から抽出された詳細でポピュレートする（例えば、図１９Ｃに示すユーザインタフェースが、タイトル、場所、開始時間、及び終了時間など、を含むようポピュレートされる）。

別の実施例として、選択可能な説明１９０３の選択に応じて、電子デバイスは、連絡先アプリケーションに対するユーザインタフェースを開き（例えば、図１９Ｄ～１９Ｅのそれぞれの、新たな連絡先の作成、又は、新たな連絡先詳細の、既存の連絡先への追加、をできるようにし）、そのユーザインタフェースを、音声通信の一部から抽出された詳細でポピュレートする（例えば、図１９Ｄに示すユーザインタフェースは、苗字、名前、電話番号、電子メールアドレスなど、を含み、図１９Ｅに示すユーザインタフェースは、既存の連絡先の新たな携帯電話番号を含む）。

一部の実施形態では、電子デバイスはまた、音声通信中に言い及んだ又は話した物理的位置についての情報を検出／抽出する。特に、及び、図１８Ｂを参照して戻ると、電子デバイスは、音声通信が、第１の物理的位置（例えば、第１の地理的位置に到達するために提供された地理的位置又は道順への参照）についての情報を含むと判定する（１８３３）。電子デバイスはまた、入力（例えば、その入力）を検出し（１８３５）、その入力を検出したことに応じて、電子デバイスは、その入力が、地理的位置データを受け入れるアプリケーションを開くことの要求に対応するか否か、又は、その入力が、電子デバイス上でコンテンツを検索することの要求に対応するか否か、により、動作１８３７又は動作１８３９のどちらかを実行する（例えば、本明細書に説明する、検索有効化ジェスチャのいずれか）。

その入力が、地理的位置データを受け入れるアプリケーションを開くことの要求に対応するとの判定に従って、電子デバイスは、位置データを受け入れ可能なアプリケーションを開き、そのアプリケーションを、第１の物理的位置についての情報（ライブの電話呼び出しにて話されたレストラン名、又は、そのレストラン名を使用して電子デバイスが探した電話番号などの、音声通信内に含まれる情報又はそれに基づく情報であり得る）でポピュレートする（１８３９）。例えば、図１９Ｆに示すように、アプリケーションは地図アプリケーションであり、地図アプリケーションを、第１の物理的位置についての情報でポピュレートすることは、地図アプリケーション内に表示されている地図を、第１の物理的位置に対応する位置識別子でポピュレートすることを含む（又は、図１９Ｆに示すように、複数の位置識別子が、音声通信中に話された／抽出された各物理的位置に対して表示される）。

その入力が、検索モードに移行することの要求に対応するとの判定に従って、電子デバイスは、検索インタフェースを、第１の物理的位置についての情報でポピュレートする（１８３７）（ライブの電話呼び出しにて話されたレストラン名、又は、そのレストラン名を使用して電子デバイスが探した電話番号などの、音声通信内に含まれる情報又はそれに基づく情報であり得る）。例えば、図１３Ｂに関連して上述する検索インタフェースは、提案された検索１１５０の１つとして、第１の物理的位置についての情報を含むようポピュレートされ得る（例えば、要求が電話アプリケーション上で受信される）。

一部の実施形態では、音声通信は、（音声通信中に会話している両方のうちの、単一のユーザ又は複数のユーザからの）多くの様々なコンテンツアイテム（例えば、複数の新たな連絡先若しくは既存の連絡先についての新たな連絡先情報、複数の物理的位置、及び、新たな若しくは既存のイベントについての複数の詳細、又はその組み合わせ）を説明するスピーチを含んでよく、電子デバイスは、これらのコンテンツアイテムのそれぞれが、音声通信から抽出されることを確かにするよう構成される。例えば、方法１８００はまた、電子デバイスが音声通信の第２の部分を受信することも含む（例えば、第２の部分は、リモートデバイスのリモートユーザ及び電子デバイスのユーザのうちの１人以上により提供されたスピーチを含む）。一部の実施形態では、電子デバイスは、リモートデバイスのリモートユーザにより提供されたスピーチ及び電子デバイスのユーザにより提供されたスピーチに少なくとも部分的に基づいて、第２のコンテンツアイテムを抽出する。第２のコンテンツアイテムが電子デバイス上で現在利用可能でないとの判定に従って、電子デバイスは、第２のコンテンツアイテムに関連付けられた第２のアプリケーションを特定し、第２のコンテンツアイテムの第２の選択可能な説明をディスプレイに表示する（例えば、複数のコンテンツアイテムが、各関連する音声通信から抽出された場合に、必要に応じて、図１９Ａに示すユーザインタフェースは、１つを超える選択可能な説明１９０２を含んでよい、及び／又は、図１９Ｂに示すユーザインタフェースは、１つを超える選択可能な説明１９０１、１９０３、又は１９０５を含んでよい）。第２の選択可能な説明の選択を検出したことに応じて、電子デバイスは、特定された第２のアプリケーションでの提示のために、第２のコンテンツアイテムを記憶する（第１のコンテンツアイテムを参照して上述するように）。

一部の実施形態では、選択可能な説明又は第２の選択可能な説明が選択された後、電子デバイスは、最近の呼び出しを含むユーザインタフェース内のそれぞれの選択可能な説明の表示を停止する。一部の実施形態では、各選択可能な説明はまた、選択されると、電子デバイスに、それぞれの選択可能な説明を表示することを停止させる、リムーブアフォーダンス（例えば、「ｘ」）と共に表示される（図１９Ａ及び１９Ｂに示す選択可能な説明に対して示すように）。

図１８Ａ～１８Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２０００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図１８Ａ～１８Ｂに関連して上述された方法１８００と類似の方式で適用可能であることに留意されたい。例えば、方法１８００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２０００）を参照して本記載の動作により実装される、又は、これらの動作を組み込む。更に、以下のセクション４「構造化された提案」に提供する詳細はまた、方法２０００と併せて使用されてもよい（例えば、メッセージ内の連絡先及びイベントついての情報を検出することに関連する、セクション４に説明する詳細は、同様に、音声通信から同じ情報を抽出するために使用され得る）。一部の実施形態では、方法１８００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

一部の実施形態では、上記方法１８００及び下記方法２０００を参照して説明される技術もまた、音声通信から抽出され得る、他の種類のコンテンツを検出するためにも使用される。例えば、電話番号が、（例えば、新たな連絡先又は既存の連絡先に対する）連絡先情報としての記憶のために、又は、すぐに使用するために抽出され、ユーザに提示されてよい（例えば、ユーザは、電話呼び出しを行い、新たな電話番号を含む応答メッセージを聞き、メッセージが、この新たな電話番号を含むことを検出したことに応じて、デバイスは、この電話番号を、図２１Ｂに示すようなユーザインタフェースなどの上に提示し、ユーザが、素早く、そして容易に、その新たな電話番号を呼び出すことができるようにする）。

方法１８００及び２０００の一部の実施形態では、新たなコンテンツが利用可能であることの明確なインジケーションをユーザに提供するために、デバイスが、新たなコンテンツ（例えば、場所、電話番号、連絡先情報、又は、その他）を検出するといつでも、触覚フィードバックが提供される。

図２０は、一部の実施形態に係る、音声通信が物理的位置を特定するスピーチを含むと判定し、アプリケーションを、その物理的位置についての情報でポピュレートする方法を示すフローチャートである。図１９Ａ～１９Ｆ及び２１Ａ～２１Ｂは、図２０の方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２０００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２０００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２０００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２０００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２０００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２０００は、音声通信からコンテンツアイテムを抽出し、タッチ感知ディスプレイを備える電子デバイス上にてそれらをユーザに提示する直感的な方法を提供する。この方法は、ユーザからの必要な入力の数を減らし（例えば、デバイスが、物理的位置についての関連情報を自動的に抽出し、その情報を、デバイス上での記憶及び使用のために準備し）、従って、より効率的なヒューマンマシンインタフェースを作り出し、音声通信にて話された内容に基づく物理的位置についての情報をユーザが再度呼び出すことを補助する。バッテリ動作電子デバイスの場合、この方法は、電力を節約し、バッテリを充電する間隔を延長することの両方を補助する。

図２０に示すように、デバイスは、音声通信の少なくとも一部を受信し、その音声通信の一部は、電子デバイスのユーザとは別個の、リモートデバイスのリモートユーザにより提供されたスピーチを含む（２００１）。一部の実施形態では、音声通信は、ライブの電話呼び出し、ライブのビデオ呼び出し（例えば、ＦａｃｅＴｉｍｅ呼び出し）、又は録音された音声メール（２００３）である。音声通信の実施例に関する追加詳細（及び、その関連する部分）は、図１８Ａ～１８Ｂに関連して先に提供されている。一部の実施形態では、音声通信の一部は、電子デバイスのユーザから受信した命令に基づいて特定される（２００５）。ユーザから受信した命令の実施例に関する追加詳細は、図１８Ａ～１８Ｂに関連して先に提供されている（例えば、命令は、ハードウェアボタンの選択又はユーザからの口頭コマンドに対応し得る）。

一部の実施形態では、デバイスは、音声通信の一部を分析し、物理的位置についての情報を検出し、この分析は、電子デバイスと通信するオーディオシステムを介して音声通信を出力する間に実行される（２００７）。一部の実施形態では、オーディオシステムは、デバイスの内部スピーカ、外部ヘッドホン、スピーカ又は車両のステレオシステムなどの、外部オーディオシステムであってよい。この分析動作２００７及びスピーチからテキストへの処理の他の実施例に関する追加情報は、先に提供されている（及び、これらの技術は、同様に、物理的位置の検出にも適用する）。

一部の実施形態では、電子デバイスは、音声通信が、物理的位置を特定するスピーチを含むと判定する（２００９）。一部の実施形態では、物理的位置を特定するスピーチは、特定の対象地点への運転指示を話すスピーチ、レストラン名（又は、他の対象地点）に言及するスピーチなどを含む。一部の実施形態では、物理的位置は、いずれの対象地点（例えば、レストラン、家、アミューズメントパーク、その他）に対応してよく、物理的位置を特定するスピーチは、通りの住所に言及するスピーチ、物理的位置に対する位置情報に言及するスピーチ（ＧＰＳ座標、緯度／経度など）、及び、地図上の物理的位置を特定するために（デバイスにより）使用可能な情報を提供する、他の関連するスピーチを含んでよい。一部の実施形態では、物理的位置はまた、名前を指定された位置（named location）又は物理的に住所指定可能な位置（physically addressable location）とも呼ばれる。

一部の実施形態では、音声通信が、物理的位置を特定するスピーチを含むと判定したことに応じて、電子デバイスは、物理的位置についての情報が検出されたとのインジケーションを提供する（２０１１）（例えば、デバイスは、触覚フィードバックを提供し、及び／又は、図２１Ａ及び２１Ｂにそれぞれ示す、ユーザインタフェースオブジェクト２１０１又は２１０３などの、選択のためのＵＩオブジェクトを表示する）。一部の実施形態では、インジケーションを提供することは、物理的位置の選択可能な説明（例えば、図１９Ｂの選択可能な説明１９０５）を、電話アプリケーションを使用して実行された最近の呼び出しを含むユーザインタフェース内に、又は、音声通信（例えば、図２１Ａ～２１Ｂのそれぞれの、選択可能な説明２１０１及び２１０３）に関連付けられたユーザインタフェース内に、又は、そのようなユーザインタフェースの両方内（例えば、音声通信が継続中に、その音声通信に関連付けられたユーザインタフェース内、及び、音声通信が終了した後の、最近の呼び出しを含むユーザインタフェース内）に、表示することを含む（２０１３）。一部の実施形態では、選択可能な説明は、コンテンツアイテムが、音声通信に関連付けられたことを示す（例えば、図１９Ｂに示すように、選択可能な説明が、音声通信に対する識別子の下に表示される、又は、選択可能な説明が、音声通信に関連付けられたユーザインタフェース内に表示される（図２１Ａ～２１Ｂに示すように））。

一部の実施形態では、インジケーションを提供することは、電子デバイスのユーザに触覚フィードバックを提供することを含む（２０１５）。

一部の実施形態では、インジケーションを提供することは、電子デバイスに近接する異なる電子デバイスに、物理的位置に関する情報を送信することを含む（２０１７）（例えば、近隣のラップトップ又は携帯時計での提示のために情報を送信することで、ユーザは耳から電話を離すことなく、検出された新たなコンテンツアイテムに関する詳細を見ることができる）。

一部の実施形態では、電子デバイスは、タッチ感知面を介して入力を検出し（例えば、入力は、（音声通信の終了後にしばらくして受信された）地理的位置データを受け入れるアプリケーションを開くことの要求に対応する、又は、入力は、音声通信中又は後に表示された物理的位置の選択可能な説明の選択に対応する）、この入力を検出したことに応じて、デバイスは、地理的位置データを受け入れるアプリケーションを開き、そのアプリケーションを、物理的位置についての情報でポピュレートする（２０１９）。

一部の実施形態では、入力を検出することは、最近の呼び出しを含むユーザインタフェースが表示されている間に、選択可能な説明上の入力を検出することを含む（例えば、図１９Ａの選択可能な説明１９０５上の選択又はタップ）。例えば、図１９Ａの、選択可能な説明１９０５上の接触を検出したことに応じて、電子デバイスは、地図アプリケーション（又は、ライドシェアアプリケーションなどの、地図オブジェクトを表示可能なアプリケーション）を開き、その地図アプリケーションを、物理的位置（例えば、図１９Ｆに示すように、物理的位置を特定するピン）についての情報でポピュレートする。

一部の実施形態では、入力を検出することは、音声通信に関連付けられたユーザインタフェースが表示されている間に、選択可能な説明上の入力を検出することを含む（例えば、図２１Ａ～２１Ｂの、選択可能な説明２１０１又は２１０３上の選択又はタップ）。例えば、図２１Ａの、選択可能な説明２１０１上の接触を検出したことに応じて、電子デバイスは、地図アプリケーション（又は、ライドシェアアプリケーションなどの、地図オブジェクトを表示可能なアプリケーション）を開き、その地図アプリケーションを、物理的位置（例えば、図１９Ｆに示すように、物理的位置を特定するピン）についての情報でポピュレートする。別の実施例として、選択可能な説明２１０３上の接触を検出したことに応じて（図２１Ｂ）、デバイスは、地図アプリケーション（又は、物理的目的地への経路案内を提供可能なアプリケーション）を開き、その地図アプリケーションを、物理的位置についての情報（例えば、図１９Ｆに示すように、物理的位置を特定するピン、同様に、音声通信中に提供されたスピーチに基づいて抽出された物理的位置への道順）でポピュレートする。

一部の実施形態では、アプリケーションは、入力の検出に応じてポピュレートされるため、ポピュレートすることは、アプリケーション内でのいずれの追加ユーザ入力を受信する前に実行される（例えば、ピンは、図１９Ｆに示す地図アプリケーションが開いた際に、その地図アプリケーション内のいずれのユーザ入力を要求することなく、その地図アプリケーション内にポピュレートされる）。このようにして、ユーザは、音声通信中にスピーチから抽出された情報のみに基づく物理的位置についての情報が提示され、ユーザは、アプリケーションが情報でポピュレートされるためのいずれの追加入力も提供しない（つまり、アプリケーションは、情報で事前にポピュレートされる）。

一部の他の実施形態では、検出された地理的位置は、ユーザが後に適切なアプリケーション（例えば、地理的位置情報を受け入れ可能なアプリケーション）を開く時にいつでも、適切なアプリケーション内での表示のために記憶される、従って、音声通信中に、ユーザにはインジケーションが提供されない。

図２０での動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法１８００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２０に関連して上述された方法２０００と類似の方式で適用可能であることに留意されたい。例えば、方法２０００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法１８００）を参照して本記載の動作により実装又は補完される。更に、以下のセクション４「構造化された提案」に提供する詳細はまた、方法２０００と併せて使用されてもよい（例えば、メッセージ内の連絡先及びイベントついての情報を検出することに関連する、セクション４に説明する詳細は、同様に、音声通信から同じ情報を抽出するために使用され得る）。一部の実施形態では、方法２０００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図２２Ａ～２２Ｂは、一部の実施形態に係る、メッセージアプリケーションにて使用するための物理的位置を先見的に提案する方法を示すフローチャートである。図２３Ａ～２３Ｏは、図２２Ａ～２２Ｂの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２２００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２２００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２２００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２２００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２２００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２２００は、タッチ感知ディスプレイを備える電子デバイス上のメッセージアプリケーションにて使用するために、物理的位置を先見的に提案する直感的な方法を提供する。この方法は、物理的位置についての関連情報をメッセージアプリケーション内に追加するための、ユーザからの入力の数を減らし、従って、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、メッセージアプリケーションにて使用するための物理的位置を先見的に提案することは、電力を節約し、バッテリを充電する間隔を延長する（例えば、ユーザがこの情報を漫然と検索しなければならない場合の時間及びエネルギを消費する動作を、その情報をメッセージアプリケーションに入力する前に、節約することで）。

図２２Ａに示すように、電子デバイスは、ディスプレイ（例えば、デスクトップ、ラップトップ、スマートフォン、又はスマートウォッチ上の電子メール又はｉＭｅｓｓａｇｅアプリケーション）上のメッセージアプリケーション内に、テキスト入力フィールド及び会話記録を提示する（２２０１）。一部の実施形態では、会話記録は、１人以上のユーザとの間で交換されたメッセージを含む（例えば、電子メールメッセージ、テキストメッセージ、オーディオメッセージ、ビデオメッセージ、写真メッセージなど）。一部の実施形態では、会話記録は、テキスト入力フィールドを含む（例えば、図２３Ａに示すように、会話記録２３０１は、電子メールへの返事を新たに下書きしている間にユーザがタイプしたテキストを含む）。一部の実施形態では、会話記録及びテキスト入力フィールドは別個である（例えば、図２３Ｃに示すように、会話記録２３０３は、ユーザが新たなメッセージを下書きできる別個のテキスト入力フィールド２３０５の実質的に上方に位置する）。一部の実施形態では（例えば、デスクトップ又はスマートＴＶデバイスなどの、電子デバイスが、デバイスとは物理的に別個となっているディスプレイと通信するもの）、提示することは、ディスプレイに提示させることを含む（例えば、デバイスは、情報をディスプレイに提供し、ディスプレイが、テキスト入力フィールド及び会話記録（及び、以下に説明する他のユーザインタフェース要素）を描画できるようにする）。

メッセージアプリケーションがディスプレイ上に提示されている間に、電子デバイスは、電子デバイスのユーザからの次の可能性のある入力が、物理的位置（例えば、住所、又は、デバイスにより判定されるユーザの現在地）についての情報であると判定する（２２０３）。一部の実施形態では、電子デバイスのユーザからの次の可能性のある入力が、物理的位置についての情報であると判定することは、テキスト入力フィールド及び会話記録に関連付けられたコンテンツを処理し、会話トランスクリプションが、ユーザの現在地についての質問を含む（２２０５）ことを検出することを含む（例えば、図２３Ａ～２３Ｂ及び２３Ｃ～２３Ｄに示すように、第２のユーザが、「どこに居るの（where are you）」とユーザに尋ねるメッセージを送信する）。一部の実施形態では、コンテンツを処理することは、自然言語処理アルゴリズムを適用し、その質問を構成する１つ以上の所定のキーワードを検出することを含む。一部の実施形態では、１つ以上のキーワードは、電子デバイスにより、テキスト入力フィールド及び会話記録に関連付けられたコンテンツ内を直接検索され得る一方で、他の実施形態では、１つ以上のキーワードは、意味解析を実行し、１つ以上のキーワード（例えば、短いセマンティック距離で離れた単語）に対する同等のフレーズを探すことにより検出され、一部の実施形態では、これらの技術の両方が使用される。一部の実施形態では、質問は、ユーザとは別個の、第２のユーザから受信したメッセージに含まれる（２２０９）（図２３Ａ～２３Ｂ及び２３Ｃ～２３Ｄに示すように）。

一部の実施形態では、電子デバイスは、テキスト入力フィールド及び会話記録に関連付けられたコンテンツを分析し、分析したコンテンツ（例えば、直近に受信したメッセージからのコンテンツ）の一部に少なくとも部分的に基づいて、提案された物理的位置を判定する（２２１１）。一部の実施形態では、提案された物理的位置は、メッセージアプリケーション以外のアプリケーション内にてユーザが最近閲覧した位置に対応する（２２１３）。（例えば、ユーザが、「晩御飯は（we should grab dinner at）［最近閲覧した住所を自動挿入する］に」とタイプし始める。）例えば、ユーザが以前に、（例えば、図２５Ａに示す）レビュー検索アプリケーションを使用してレストランを検索していると、デバイスは続いて、レビュー検索アプリケーションにてレストランを検索し、提案された物理的位置を特定することに基づく情報を使用する。

一部の実施形態では、電子デバイスは、ディスプレイ上のメッセージアプリケーション内に、提案された物理的位置を特定する、選択可能なユーザインタフェース要素を提示する（２２１５）。例えば、メッセージアプリケーションは、バーチャルキーボードを含み、選択可能なユーザインタフェース要素は、バーチャルキーボードに隣接し、かつその上方の提案部分内に表示される（２２１７）。図２３Ａに示すように、提案部分２３０７は、選択されると、デバイスに、ユーザの現在地をテキスト入力フィールドに含めさせる、選択可能なユーザインタフェース要素を含む（図２３Ｂに示すように）。一部の実施形態では、２３０７に示す選択可能なＵＩ要素の選択は、デバイスに、ユーザの現在地を、新たなメッセージにてリモートユーザに直ぐに送信させる。

図２２Ｂに戻ると、一部の実施形態では、電子デバイスは、選択可能なユーザインタフェース要素の選択を受信する（２２１９）。この選択を受信したことに応じて、電子デバイスは、提案された物理的位置の表現をテキスト入力フィールド内に提示する（２２２１）。一部の実施形態では、提案された物理的位置の表現は、電子デバイスの現在の地理的位置を特定する情報を含む（２２２３）（例えば、電子デバイスの位置センサから、現在の地理的位置を特定するＧＰＳ情報が取り出され、その情報は続いて、表現内に提示される（図２３Ｂ及び２３Ｄに示すように））。図２３Ｂ及び２３Ｄに示すように、一部の実施形態では、提案された物理的位置の表現は、提案された物理的位置に対する識別子を含む地図オブジェクトである（２２２７）。

一部の実施形態では、提案された物理的位置の表現は住所である（２２２５）。例えば、図２３Ｅを参照して、提案部分２３０７に示す選択可能なユーザインタフェース要素の選択を検出したことに応じて、デバイスは、テキスト入力フィールドを更新し、提案部分２３０７に示された住所を含める。一部の実施形態では、この住所は、ユーザ自身の住所（自宅、職場など）、デバイスに記憶された連絡先の住所（図２３Ｇ～２３Ｈに示すように）、電子デバイス上でユーザにより最近閲覧された住所（例えば、図２３Ｆに示すように、一部の他のアプリケーション内にて閲覧されたレストラン位置）、この会話記録又は他の会話記録にてユーザに送信された住所、又は、ユーザと他のユーザがシェアする住所（例えば、電子メール、ソーシャルネットワークアプリケーションなどを介して）に対応してよい。

一部の実施形態では、ユーザが、タイプしており（すなわち、ユーザが、例えば、図２３Ｅに示すもののようなバーチャルキーボードを介して、メッセージアプリケーション内にテキストを継続して入力している）、及び、（例えば、２秒間、３秒間、４秒間などの、選択可能なユーザインタフェース要素をユーザが選択しようとしないことが合理的に確かな所定の期間後に）選択可能なユーザインタフェース要素を選択していないとの判定に従って、デバイスは、選択可能なユーザインタフェース要素を提示することを停止する（２２２９）。一部の実施形態では、ユーザがタイプし始めると、デバイスは、選択可能なユーザインタフェース要素を提示することを停止する。

一部の実施形態では、電子デバイスのユーザからの次の可能性のある入力が、物理的位置についての情報であると判定することは、メッセージアプリケーションのテキスト入力部分内にてユーザから受信したタイピング入力を監視することを含む。そのような実施形態では、この方法は、以下を更に含む。タイピング入力を監視する間に、タイピング入力のいずれかが、１つ以上のトリガーフレーズであって、各イベンドが、対応するコンテンツアイテムに関連付けられたトリガーフレーズに一致するか否かを判定し、一連のタイピング入力が、第１のトリガーフレーズに一致するとの判定に従って、第１のトリガーフレーズに関連付けられた、提案されたコンテンツアイテムをディスプレイ上に表示し、提案されたコンテンツアイテムの選択を検出し、この選択を検出したことに応じて、提案されたコンテンツアイテムについての情報をメッセージアプリケーションのテキスト入力部分に表示する。一部の実施形態では、選択可能なユーザインタフェース要素をユーザが選択しない（例えば、連続するキーストロークがトリガーフレーズに一致しない）ことを示す追加入力をユーザが提供したとの判定に従って、電子デバイスは、選択可能なユーザインタフェース要素を提示することを停止する（２２３１）。

一部の実施形態では、選択可能なユーザインタフェースオブジェクトを最初に表示してから、所定の期間（例えば、１０秒間）が経過したとの判定に従って、デバイスは、選択可能なユーザインタフェースオブジェクトを提示することを停止する。

一部の実施形態では、方法２２００に関連付けられた技術もまた、追加種類のアプリケーション（ドキュメントオーサリングアプリケーションなどの、メッセージアプリケーション以外）を介して利用可能であり、及び、追加オブジェクトタイプに対して利用可能である（連絡先及びイベントなどの、物理的位置に加えて）。例えば、図２３Ｉ及び２３Ｊに示すように、一部の実施形態はまた、電子デバイスに、イベントをスケジューリングするための可用性ウィンドウを先見的に提案させることができる（図２２Ｃ及び方法２２８０に関連して以下に詳述する）。更に、図２３Ｋ～２３Ｊに示すように、一部の実施形態はまた、電子デバイスに、連絡先情報を先見的に提案させることができ（例えば、デバイス上に記憶されたユーザ又は連絡先に対する電話番号）、又は、以前の会話に基づいて、適切な応答を先見的に提案させることができ（例えば、図２３Ｍに示すように）、又は、適切な参考文書を先見的に提案させることができる（例えば、図２３Ｏに示すように）。以下の方法２２８０はまた、他の種類のアプリケーション及び追加オブジェクトタイプに関する追加詳細も提供する。」一部の実施形態では、方法２２００及び２２８０の様々な態様が組み合わされ、取り替えられ、及び交換される。

図２２Ａ～２２Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２２８０及び２９００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２２Ａ～２２Ｂに関連して上述された方法２２００と類似の方式で適用可能であることに留意されたい。例えば、方法２２００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２２８０及び２９００）の動作又は特性の１つ以上を含む。一部の実施形態では、方法２２００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図２２Ｃは、一部の実施形態に係る、位置、イベント、又は連絡先に関する情報を先見的に提案する方法を示すフローチャートである。図２３Ａ～２３Ｏは、図２２Ｃの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２２８０は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２２８０は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２２８０はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２２８０の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２２８０の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２２８０は、タッチ感知ディスプレイを備える電子デバイス上にて位置、イベント、又は連絡先に関する情報を先見的に提案する直感的な方法を提供する。この方法は、連絡先、位置、又はイベントについての情報を特定するために必要なユーザからの入力の数を減らし、その情報をアプリケーションでの使用のために入力し、従って、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、位置、イベント、又は連絡先に関する情報を先見的に提案することは、電子デバイスのユーザ満足度を改善し（情報を自動的に再度呼び出し、それをユーザに近いユーザに、関連時間にて提示することにより）、電力を節約し、バッテリを充電する間隔を延長する。

図２２Ｃに示すように、電子デバイスは、ディスプレイ上に、アプリケーションに関連付けられたテキストコンテンツを提示する（２２８１）。一部の実施形態では、アプリケーションは、ドキュメントオーソライジングアプリケーション（例えば、メモアプリケーション、ワードプロセッシングアプリケーションなど）、又は、メッセージアプリケーション（例えば、電子メール又はテキストメッセージアプリケーション）、若しくは、入力受け取りフィールドにテキストを入力するためにバーチャルキーボードが表示される、いずれの他のアプリケーション）である。

一部の実施形態では、デバイスは、テキストコンテンツの一部が、（ｉ）位置（例えば、電子デバイスの位置センサを介して利用可能な現在地情報）、（ｉｉ）連絡先（例えば、電子デバイス上の連絡先アプリケーションを介して利用可能な情報）、又は（ｉｉｉ）イベント（例えば、電子デバイス上のカレンダーアプリケーションを介して利用可能な情報）に関連する（又は、テキストコンテンツの一部が、これらを参照する）と判定する（２２８３）。一部の実施形態では、テキストコンテンツの一部は、位置、連絡先、又はイベントについての情報で良好に補完されるステートメント／質問である（例えば、図２３Ａ～２３Ｏに示す実施例など）。一部の実施形態では、テキストコンテンツの一部は、アプリケーション内にて直近に提示されたテキストコンテンツに対応する（２２８５）（例えば、ユーザによりタイプされたテキストコンテンツ、又は、リモートユーザからメッセージにて受信したテキストコンテンツ）。例えば、その一部は、メモ又はメッセージａｐｐ内にユーザによりタイプされた現在のテキストである（例えば、図２３Ａの「～に今居ます（Currently I'm at）」、図２３Ｅの「住所は～（My address is）」、図２３Ｈの「ジョンの住所は（John's address is）」、図２３Ｉの「～なら時間が空いています（I'm free at）」、図２３Ｋの「私の電話番号は（my phone number is）」、図２３Ｌの「～に電話してください（Call me at）」、及び図２３Ｍの「ネオプラズムの種類は（what kind of neoplasm）」）。別の方法で説明すると、テキストコンテンツの一部は、アプリケーション内の入力受け取りフィールド（例えば、図２３Ｃの、インスタントメッセージアプリケーションのフィールド２３０５、又は、図２３Ａの、電子メールアプリケーションのフィールド２３０１）にて電子デバイスのユーザにより提供された入力（すなわち、一連のタイピング入力）である（例えば、ユーザは、バーチャルキーボードにて一連のタイピング入力を提供している、又は、ディクテーションを使用してテキストを入力受け取りフィールドに加えている）。

一部の実施形態では、テキストコンテンツの一部は、会話記録内の、一部の他のユーザから直近に受信したメッセージである。例えば、アプリケーションはメッセージアプリケーションであり、テキストコンテンツの一部は、電子デバイスとは別個のリモートデバイスのリモートユーザから、メッセージアプリケーション内で受信した質問である（例えば、図２３Ｃの「どこに居るの？（where are you?）」、図２３Ｆの「レストランはどこ？（where's the restaurant?）」、図２３Ｇの「ジョンの住所は？（What's John's addr?）」、図２３Ｊの「夕食までの時間は？（what time works for dinner?）」、及び図２３Ｏの「ネオプラズムについてご存知ですか？（Do you know about neoplasms?）」）。

一部の実施形態では、テキストコンテンツの一部が、（ｉ）位置（２２８９）、（ｉｉ）連絡先（２２９１）、又は（ｉｉｉ）イベント（２２９３）に関連すると判定すると、電子デバイスは、電子デバイス上で利用可能な、適切なコンテンツアイテムの特定（一部の実施形態では、サーバからいずれの情報を取り出す必要なく）、及び、アプリケーションでの使用のために、そのコンテンツアイテムのユーザへの提示を進める（例えば、質問に応える、又は、ユーザ自身のタイピング入力を効率的に補完する）。このようにして、現在のアプリケーションを終了し、適切なコンテンツを検索し、そのコンテンツをコピー又は記憶し、現在のアプリケーションに戻り、続いて、そのコンテンツを現在のアプリケーション内に含める必要なく、ユーザは、素早く、容易に、連絡先、イベント、及び位置についての情報をアプリケーション内に含めることができる（従って、連絡先、イベント、及び位置についての情報をアプリケーション内に含めるためにユーザに要求される入力の数を減らす）。

より具体的には、（ｉ）について、テキストコンテンツの一部が位置に関連すると判定すると、電子デバイスは、電子デバイス上の位置センサから位置情報を取得し、取得した位置情報を、予測されたコンテンツアイテムとして表示するために準備する（２２８９）。例えば、リモートユーザから受信したメッセージ内の、フレーズ「どこに居るの？（Where are you?）」を含むテキストコンテンツの一部に基づいて（図２３Ｃに示すように）、デバイスは、その一部が位置に関連すると判定し、デバイスは続いて、デバイス上のＧＰＳセンサから情報を取得し、その情報を、予測されたコンテンツアイテムとしての提示のために準備する（ユーザの現在地を含む地図オブジェクトがリモートユーザに送信される、図２３Ｄを参照されたい）。別の実施例として、ユーザが新たな電子メールをタイプする時の、フレーズ「～に居ます（I'm at）」を含むテキストコンテンツの一部に基づいて（図２３Ａに示すように）、デバイスは、その一部が位置に関連すると判定し、デバイスは続いて、デバイス上のＧＰＳセンサから情報を取得し、その情報を、予測されたコンテンツアイテムとして提示するために準備する（ユーザの現在地を含む地図オブジェクトが、ユーザが準備している新たな電子メール内に含まれる、図２３Ｂを参照されたい）。追加実施例を、図２３Ｅ（例えば、デバイスは、ユーザが「住所は～（My address is）」とタイプすることに基づいて、テキストコンテンツの一部が、位置に関する情報を含むと判定する）、及び、２３Ｆ（例えば、デバイスは、テキスト「レストランはどこ？（Where's the restaurant）」を含むメッセージを受信するユーザに基づいて、テキストコンテンツの一部が、位置に関する情報を含むと判定する）に示す。図２３Ｆに示すように、一部の実施形態では、デバイスは、異なるアプリケーションでのユーザの以前の相互作用に基づいて、位置情報を取得する（例えば、ユーザは、クラウドに基づくレビューを提供するアプリケーションなどの、異なるアプリケーションにてレストランアプリケーションを検索し、従って、情報の取得に位置センサは使われない）。２つの異なるアプリケーションの間での情報のシェアに関する追加詳細は、方法２４００、２５００、及び２８００に関連して以下に詳述し、簡潔にするために、それら詳細は本明細書では繰り返さない。

（ｉｉ）について、テキストコンテンツの一部が、連絡先に関連すると判定すると、電子デバイスは、電子デバイス上で、テキストコンテンツの一部に関連する連絡先情報の検索を行い、検索を通して取り出された、少なくとも１つの連絡先に関連付けられた情報を、予測されたコンテンツアイテムとして表示するために準備する（２２９１）。例えば、テキストコンテンツの一部は「ジョンの住所は？（What's John's addr?）」（図２３Ｇ）、「ジョンの住所は（John's address is）」（図２３Ｈ）、又は「私の電話番号は（My phone number is）」（図２３Ｋ）、若しくは「～に電話してください（Call me at）」（図２３Ｌ）であり、デバイスは、連絡先アプリケーションに記憶された連絡先情報を分析し、その一部への応答となることが予測された連絡先情報を取り出し、その取り出した連絡先情報を、予測されたコンテンツアイテムとして提供する。

（ｉｉｉ）について、テキストコンテンツの一部が、イベントに関連すると判定すると、電子デバイスは、電子デバイス上で、テキストコンテンツの一部に関連するイベント情報の新たな検索を行い、新たな検索を通して取り出された、少なくとも１つのイベントに少なくとも部分的に基づく情報を、予測されたコンテンツアイテムとして表示するために準備する（２２９３）。一部の実施形態では、少なくとも１つのイベントに少なくとも部分的に基づく情報は、イベント詳細（例えば、イベント時刻、期間、場所）、又は、イベント詳細から導かれた情報（例えば、図２３Ｉ及び２３Ｊに示すように、新たなイベントをスケジューリングするためのユーザの可用性）であり得る。例えば、テキストコンテンツの一部は、「どの会議室がミーティングに使用されていますか？（What conference room is the meeting in?）」又は「会議が始まる時間は何時ですか？（What time does the conference start at?）」であり、デバイスは、カレンダーアプリケーションに記憶されたイベントに関連付けられた情報を分析し、質問への応答となる情報を取り出し、その取り出した情報を、予測されたコンテンツアイテムとして提供する。

上述するように、電子デバイスは、アプリケーション内にて、予測されたコンテンツアイテムを含むアフォーダンスを表示する（２２９４）（例えば、図２３Ａにて、「現在地を追加する（Add Current Location）」に対するアフォーダンスが、提案部分２３０７内に示され、図２３Ｃにて、「私の現在地を送信する（Send My Current Location）」に対するアフォーダンスが、提案部分２３０９内に示され、その他、提案部分２３０７又は２３０９内に示す他のアフォーダンス例については、図２３Ｅ、２３Ｆ、２３Ｇ、２３Ｈ、２３Ｉ、２３Ｊ、２３Ｋ、２３Ｌ、２３Ｍ、２３Ｎ、及び２３Ｏに示す）。電子デバイスはまた、タッチ感知面を介して、アフォーダンスの選択を検出し（２２９５）、この選択を検出したことに応じて、デバイスは、ディスプレイ上に、予測されたコンテンツアイテムに関連付けられた情報を、テキストコンテンツに隣接して表示する（２２９７）（例えば、地図オブジェクトは、ユーザの現在地と共に、「現在地を追加する（Add Current Location）」に対するアフォーダンスの選択に応じて表示される（図２３Ｂ））。

一部の実施形態では、テキストコンテンツの一部は、テキストコンテンツの一部を含むユーザインタフェースオブジェクトを選択するユーザ入力に応じて特定される（２２８７）。例えば、アプリケーションはメッセージアプリケーションであり、ユーザインタフェースオブジェクトは、メッセージアプリケーション内に表示された会話におけるメッセージ吹き出しである。このようにして、ユーザは、アプリケーション内に表示された特定の部分に対する、予測されたコンテンツアイテムを取り出すことができ、特定の部分に返答することをもし忘れても、その特定の部分に対する予測されたコンテンツアイテムを容易に閲覧するために、その部分に関連付けられたユーザインタフェースオブジェクトを選択できるようになる。具体的な実施例として、図２３Ｍを参照して、テキストコンテンツの一部は、初期的に、直近に表示されたテキストコンテンツ（例えば、「ネオプラズムの種類は？（What kind of neoplasm?）」）であり、従って、提案部分２３０９は、その部分（例えば、「良性（benign）」及び「悪性（malignant）」）への応答である、テキスト提案に対するアフォーダンスを含む。デバイスは続いて、第２のユーザインタフェースオブジェクトの選択（例えば、図２３Ｍの入力２３５０）を検出する（例えば、直近の表示テキストコンテンツの前に受信したテキストコンテンツ「ところで、どこに居るの？（btw, where are you?）」を含む第２のメッセージ吹き出し）。この選択を検出したことに応じて、デバイスは、予測されたコンテンツアイテムを伴うアフォーダンスの表示を停止し、第２のユーザインタフェースオブジェクトに関連付けられたテキストコンテンツが、位置、連絡先、又はイベントに関連すると判定し（この実施例では、「どこに居るの？（where are you?）」は、位置に関連するとデバイスは判定する）、この判定することに従って、デバイスは、アプリケーション内に新たな、予測されたコンテンツアイテムを表示する（例えば、図２３Ｎの、提案部分２３０９内の「私の現在地を送信する（Send my current location）」を含むアフォーダンス）（２２９９）。

先行する段落に説明するように、一部の実施形態では、デバイスはまた、テキストコンテンツの一部が、電子デバイス上で利用可能な、他の種類の（連絡先、位置、及びイベントに加えて）情報に関連するか否かを判定できる。例えば、デバイスは、電子メールの交換にてユーザにより話された情報、ユーザがオーサリングする文書若しくは一部の他のユーザからユーザが受信した文書内の情報、又は、他の知識ソースからの情報、に関連する質問（例えば、ネオプラズムの種類は（what kind of neoplasm））を検出できる。更に、一部の実施形態では、電子デバイスは、アプリケーション内のテキストコンテンツの特定の部分に文書が対応することを判定する（例えば、図２３Ｏに示すように、２つの異なる文書が、質問「ネオプラズムについてご存知ですか？（Do you know about neoplasms?）」に対応しているものとして提案される）。一部の実施形態では、２つの異なる文書のいずれかの選択に応じて、デバイスは、対応する文書を開いてよく、アプリケーションに戻る前に、その文書をユーザがレビューできるようにしてよい。

一部の実施形態では、提案部分内に表示され、予測されたコンテンツアイテムを含むアフォーダンスが、アプリケーション内のバーチャルキーボードに隣接して（例えば、上に）表示される。例えば、図２３Ａに示すように、「現在地を追加する（Add Current Location）」に対するアフォーダンスが、バーチャルキーボードの上方の提案部分２３０７内に表示される。

一部の実施形態では、予測されたコンテンツアイテムに関連付けられ、テキストコンテンツに隣接して表示される情報は、入力受け取りフィールド内に表示され、入力受け取りフィールドは、バーチャルキーボードにて受け取ったタイピング入力を表示するフィールドである（例えば、メモアプリケーションに示すような文書、又は、フィールド２３０５がバーチャルキーボードの上方にある、図２３Ｄの入力受け取りフィールド２３０５に対して示すように、メッセージアプリケーション内などの、バーチャルキーボードの上方に表示される入力受け取りフィールド）。

一部の実施形態では、動作２２８３を判定することは、アプリケーションにより受信したそのままの（例えば、ユーザがタイプするそのままの、又は、メッセージがアプリケーションにより受信されるそのままの）テキストコンテンツを構文解析し、連絡先、イベント、及び／又は位置に関連すると既知の、記憶されたパターンを検出することを含む。一部の実施形態では、記憶されたパターンの検出を実行するために、ニューラルネットワークがトレーニングされ、及び／又は、有限状態文法が検出のために使用され、続いて、検出後、電子デバイスは、システムレベルサービスに情報を送り（例えば、以下のセクション９に説明する、１つ以上の予測モデルを使用して）、適切な、予測されたコンテンツアイテムを取り出す。

図２２Ｃでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２２００及び２９００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２２Ｃに関連して上述された方法２２８０と類似の方式で適用可能であることに留意されたい。例えば、方法２２８０を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２２００及び２９００）を参照して本記載の特性の１つ以上を有する、又は、動作の１つ以上を使用する。一部の実施形態では、方法２２８０と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図２４Ａ～２４Ｂは、一部の実施形態に係る、アプリケーションを、異なるアプリケーション内でユーザにより以前に閲覧された情報で、前もって先見的にポピュレートする方法を示すフローチャートである。図２５Ａ～２５Ｊは、図２４Ａ～２４Ｂの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２４００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２４００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２４００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２４００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２４００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２４００は、タッチ感知ディスプレイを備える電子デバイス上にて、アプリケーションを、異なるアプリケーションにてユーザにより以前に閲覧された情報で、前もって先見的にポピュレートする直感的な方法を提供する。この方法は、アプリケーションを、第１のアプリケーションから、第２の、異なるアプリケーションにて使用するための、ユーザからの入力の数を減らし、従って、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、アプリケーションを、異なるアプリケーションにてユーザにより以前に閲覧された情報で、前もって先見的にポピュレートすることは、電力を節約し、バッテリを充電する間隔を延長する。

図２４Ａに示すように、第１のアプリケーションを表示する間に、電子デバイスは、第１のアプリケーションにてユーザにより閲覧された第１の物理的位置を特定する情報を取得する（２４０１）。例えば、第１のアプリケーションは、タッチ感知ディスプレイ上に現在表示されているフォアグランドアプリケーションである（例えば、第１のアプリケーションは、図２５Ａに示すような、クラウドに基づくレビューを提供するアプリケーションである）。一部の実施形態では、取得することは、位置データについての情報を電子デバイスのオペレーティングシステム構成要素に送信する第１のアプリケーションを含む、又は、取得することは、情報を取得するためのアクセシビリティ機能を使用することを含む。情報を取得するためのアクセシビリティ機能の使用に関する詳細は、先に提供されている（例えば、方法１８００に関連して先に提供される説明、特に、動作１８０７及び１８０９に関連して先に提供されるそれら、を参照されたい）。

一部の実施形態では、電子デバイスは、第１のアプリケーションを終了する（２４０３）（例えば、ユーザは、ホームハードウェアボタンをタップして、第１のアプリケーションの終了と、ホームスクリーンの閲覧と、を要求する、又は、ユーザは、ホームハードウェアボタンをダブルタップして、第１のアプリケーションの終了と、アプリケーション切り替えユーザインタフェースの閲覧と、を要求する）。第１のアプリケーションの終了後、電子デバイスは、第１のアプリケーションとは別個の第２のアプリケーションを開くことの要求をユーザから受信する（２４０５）。一部の実施形態では、第２のアプリケーションを開くことの要求を受信することは、第１のアプリケーションの終了後、第２のアプリケーションに対するアフォーダンス上の入力を検出すること（２４０７）を含む（つまり、この要求は、第１のアプリケーション内のリンクをクリックすることに対応しない）。例えば、ユーザは、ホームスクリーンから第２のアプリケーションを選択する（例えば、図２５Ｂにて、ユーザは、ホームスクリーン上に表示されたライドシェアアプリケーションのアイコン（アフォーダンス）上をタップする）。一部の実施形態では、ホームスクリーンは、電子デバイス上で利用可能なアプリケーションを呼び出すためのアイコンを含む、オペレーティングシステムのシステムレベル構成要素である。

別の実施例として、ユーザは、ａｐｐ切り替えユーザインタフェースから、第２のアプリケーションを選択する（例えば、図２５Ｃにて、ユーザは、ａｐｐ切り替えユーザインタフェース内に含まれるライドシェアアプリケーションの表現をタップする）。この別の実施例にて、より具体的には、入力を検出することは、物理ホームボタン（例えば、ホーム２０４）にてダブルタップを検出すること、ダブルタップを検出したことに応じて、アプリケーション切り替えユーザインタフェースを表示すること、及び、アプリケーション切り替えユーザインタフェース内からアフォーダンスの選択を検出することを含む（２４１１）。

動作２４０５に関する１つの追加的実施例として、選択されると、デバイスに第２のアプリケーションを開かせるユーザインタフェースオブジェクトを、ユーザは選択する（例えば、図２５Ｂ及び２５Ｃのアフォーダンス２５０３）。一部の実施形態では、第１のアプリケーションにていずれの入力を受信することなく、この要求は受信される（例えば、この要求は、第１のアプリケーション内のリンク又はボタンをクリックすることを含まない）。

この要求を受信したことに応じて、電子デバイスは、第２のアプリケーションが、地理的位置情報を受け入れ可能であるか否かを判定する（２４１３）。一部の実施形態では、この判定動作２４１３は、以下のうちの１つ以上を含む（２４１５）。（ｉ）第２のアプリケーションが、地理的位置データを受け入れて処理することが可能な入力受け取りフィールドを含むと判定すること、（ｉｉ）第２のアプリケーションが、地理的位置情報を地図上に表示可能であると判定すること、（ｉｉｉ）第２のアプリケーションが、経路案内を促進するために、地理的位置情報を使用可能であると判定すること、及び（ｉｖ）第２のアプリケーションが、トランスポーテーションサービスを特定し、提供するために、地理的位置情報を使用可能であると判定すること。一部の実施形態では、第２のアプリケーションが、地理的位置情報を受け入れ可能であると判定することは、第２のアプリケーションが、地理的位置データを受け入れて処理することが可能な入力受け取りフィールドを含むと判定することを含み、入力受け取りフィールドは、第２のアプリケーション内に表示される地図内を検索できる検索ボックスである。例えば、第２のアプリケーションは、そのような入力受け取りフィールドを含むライドシェアアプリケーションである（図２５Ｅに示すように、ライドシェアアプリケーション例は、表示された地図内を検索できる入力受け取りフィールド２５０７を含む）、又は、第２のアプリケーションはまた、そのような入力受け取りフィールドを含む地図アプリケーションである（図２５Ｆに示すように）。

図２４Ｂに戻ると、一部の実施形態では、この要求を受信したことに応じて、電子デバイスは、ユーザに対するアプリケーションの使用履歴に基づいて、第２のアプリケーションが、第１のアプリケーションと関連する（例えば、第１のアプリケーションを開いた後に、閾値回数開かれた）か否かを判定し、また、第２のアプリケーションが、位置データを受け入れて処理することが可能であると判定する（上述するように）。つまり、電子デバイスは、一部の実施形態では、第２のアプリケーションが、位置データを受け入れるフィールドを有し、第１及び第２のアプリケーションが、第１のアプリケーションを開いた後に、第２のアプリケーションがユーザによりしばしば開かれることにより接続されることの両方を判定する。一部の実施形態では、第２のアプリケーションを提示する前に、電子デバイスは、第１の物理的位置を特定する情報へのアクセスを、第２のアプリケーションに提供（２４１７）し、このアクセスが提供される前には、第２のアプリケーションは、第１の物理的位置を特定する情報へのアクセスを有しない。例えば、第２のアプリケーションが以前に、ユーザが第１のアプリケーション内で何を閲覧したかについての情報へのアクセスを有さず、使用目的が制限された、第１の地理的位置を特定する情報へのアクセスがたったいま提供され、入力受け取りフィールドを第２のアプリケーション内にポピュレートする。このようにして、デバイスは、ユーザがしばしば第１及び第２のアプリケーションを共に使用することを知るため、ユーザからのいずれの入力の必要なく、デバイスは、テキストエントリフィールドを先見的にポピュレートできる（第１及び第２のａｐｐｓとの間の接続を確立するために使用されるそれらの入力以外）。

一部の実施形態では、この要求を受信したことに応じて、かつ第２のアプリケーションが、地理的位置情報を受け入れ可能であるとの判定（動作２４１３及び２４１５に関連して上述する）に従って、電子デバイスは、第２のアプリケーションを提示し、第２のアプリケーションを提示することは、第２のアプリケーションを、第１の物理的位置を特定する情報に少なくとも部分的に基づく情報でポピュレートすることを含む。一部の実施形態では、第２のアプリケーションをポピュレートすることは、第１の物理的位置を特定する情報に少なくとも部分的に基づく情報を含むユーザインタフェースオブジェクトを表示することを含む（２４２１）。例えば、図２５Ｄに示すように、ユーザインタフェースオブジェクト２５０５は、第１の物理的位置を特定する情報に少なくとも部分的に基づく情報を含む（例えば、図２５Ａに示すように、第１のアプリケーション内でユーザにより閲覧されたレストランの住所）。一部の実施形態では、ユーザインタフェースオブジェクト２５０５は、レストラン名を含んでよい（例えば、住所の代わりに、又はこれに加えて、「Ｇａｒｙ Ｄａｎｋｏ」、又は、ＵＩオブジェクト２５０５は、レストランの位置についての他の関連情報を含んでよい）。一部の実施形態では、ユーザインタフェースオブジェクトは、第１のアプリケーション内で第１の物理的位置が最近閲覧されたことをユーザに知らせるテキスト説明を含む（２４２３）（例えば、図２５Ｄに示すように、第１のアプリケーションに関連付けられたアイコンが、ユーザインタフェースオブジェクト２５０５内に含まれる）。

一部の実施形態では、このユーザインタフェースオブジェクトは、第２のアプリケーション内に表示された地図（例えば、図２５Ｄに示す地図）であり、第２のアプリケーションをポピュレートすることは、第１の物理的位置の識別子を含むよう地図をポピュレートすることを含む（２４２５）。一部の実施形態では、電子デバイスは、第１の物理的位置の名称、第１の物理的位置の電話番号、第１の物理的位置の住所、又は、第１の物理的位置を特定する（及び、第１の物理的位置についての検索を実行することができる）一部の他の情報を使用して特定の地理的位置を探し、その特定の地理的位置が、第２のアプリケーション内にポピュレートされる。一部の実施形態では、第２のアプリケーションはバーチャルキーボードと共に提示され、ユーザインタフェースオブジェクトはバーチャルキーボードの上方に表示される（２４２７）（例えば、図２５Ｄに示すように、ユーザインタフェースオブジェクト２５０５は、バーチャルキーボードの上方に表示される）。

一部の実施形態では、情報を取得することは、第２の物理的位置についての情報を取得することを含み（２４２９）、ユーザインタフェースオブジェクトを表示することは、そのユーザインタフェースオブジェクトを、第２の物理的位置についての情報と共に表示することを含む。（例えば、地図は、第１及び第２の物理的位置の両方に対する識別子を含む）、及び／又は、アフォーダンスは、第１及び第２の物理的位置についての情報を含む。一部の実施形態では、要求（例えば、動作２４０５）を受信することは、第２のアプリケーションを、第１又は第２の物理的位置の１つについての情報と共に開くことの要求を受信することを含む（例えば、図２５Ｇ及び２５Ｈに示すようなユーザインタフェースオブジェクト２５０５が示され、ユーザは、第１のアプリケーションにて以前に閲覧された物理的位置のいずれを選択できる）。

一部の実施形態では、地図アプリケーション内のユーザの検索がまた、物理的位置についての情報を取得するために使用されてよい（例えば、上述する第１及び第２の物理的位置）。図２５Ｆに示すように、ユーザは、位置を検索してよく、結果２５１１Ａ、２５１１Ｂ、２５１１Ｃ、及び２５１１Ｄを含む、多くの検索結果を受信してよい。一部の実施形態では、ユーザは、図２５Ｆに示すように、２５１１Ａなどの、結果の１つを選択でき、その位置が続いて、地図上で強調表示される。検索を行った後、ユーザは、検索結果の一部であった物理的位置を使用するためのオプションが提示されてよい（例えば、図２５Ｇに示すように、ユーザインタフェースオブジェクト２５０５は、物理的位置の少なくとも２つに基づく情報を、それらの位置のいずれへのライドを取得するために使用するためのオプションが提示される）。一部の実施形態では、図２５Ｇのユーザインタフェースオブジェクト２５０５はまた、アプリケーション切り替えユーザインタフェースを介して利用可能である（図２５Ｈに示すように）。一部の実施形態では、ユーザインタフェースオブジェクト２５０５に示す物理的位置の１つの選択を受信したことに応じて（図２５Ｇ又は２５Ｈのａｐｐ切り替え又はホームスクリーンのいずれから）、ユーザは、適切なアプリケーション（例えば、図２５Ｉのライドシェアアプリケーション）に導かれ、そのアプリケーションが、選択された物理的位置に基づく情報でポピュレートされる（例えば、ユーザインタフェースオブジェクト２５０５は、図２５Ｉに示され、これは住所を含む）。

位置データをシェアすることは、上の方法２４００の説明において、主な実施例として使用されるが、しかし、上述する同じ方法及び技術もまた、２つの異なるアプリケーションとの間で他の種類のデータをシェアすることにも適用する。例えば、ソーシャルネットワークアプリケーション（例えば、フェイスブック）とソーシャルシェアリングアプリケーション（例えば、ツイッター）との間で検索クエリをシェアすることはまた、方法２４００に関連して上述する技術を使用することにより促進される。例えば、フェイスブック内である名称をユーザが検索した後、ユーザは、その名称をツイッターでも検索するための提案が提供される。別の実施例として、来るミーティングのための出席者リストが、カレンダーと電子メールアプリケーションとの間でシェアされ得、ユーザが来るミーティングをカレンダーアプリケーション内にて閲覧し、続いて、電子メールアプリケーションの使用に切り替えて「作成（compose）」ボタンを押すと、新たな電子メールのための受領者リストが、来るミーティングのための出席者のリストを含むようポピュレートされるようになる。

図２４Ａ～２４Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２６００及び２７００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２４Ａ～２４Ｂに関連して上述された方法２４００と類似の方式で適用可能であることに留意されたい。例えば、方法２４００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２６００及び２７００）を参照して本記載の動作の特性の１つ以上を有する、又は、これらの動作を組み込む。一部の実施形態では、方法２４００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図２６Ａ～２６Ｂは、一部の実施形態に係る、第２のアプリケーションでの使用のために、第１のアプリケーション内でユーザにより以前に閲覧された情報を先見的に提案する方法を示すフローチャートである。図２５Ａ～２５Ｊは、図２６Ａ～２６Ｂの方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２６００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２６００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２６００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２６００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２６００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２６００は、タッチ感知ディスプレイを備える電子デバイス上の第２のアプリケーションにて使用するために、第１のアプリケーションにてユーザにより以前に閲覧された情報を先見的に提案する直感的な方法を提供する。この方法は、ユーザにとって有益な情報を、その情報を取り出するために多くの入力を実行することをユーザに要求することなく再度呼び出すことにより、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、第２のアプリケーションにて使用するために、第１のアプリケーションにてユーザにより以前に閲覧された情報を先見的に提案することは、電力を節約し、バッテリを充電する間隔を延長する。

図２６Ａに示すように、電子デバイスは、第１のアプリケーションにてユーザにより閲覧された第１の物理的位置を特定する情報を取得する（２６０１）。動作２４０１に関連して上述する詳細は、同様に、動作２６０１に適用される。電子デバイスは、第１の入力を検出する（２６０３）。一部の実施形態では、第１の入力は、アプリケーション切り替えユーザインタフェースを開くことの要求に対応する（２６０５）（例えば、第１の入力は、電子デバイスの物理ホームボタン上のダブルタップである）。一部の実施形態では、第１の入力は、電子デバイスのホームスクリーンを開くことの要求に対応する（２６０７）。（例えば、第１の入力は、電子デバイスの物理ホームボタン上のシングルタップである）。一部の実施形態では、第１の入力は、デバイスに、少なくとも部分的に、アプリケーションを終了又は切り替えさせる入力である。

第１の入力を検出したことに応じて、電子デバイスは、地理的位置情報を受け入れ可能な第２のアプリケーションを特定する（２６０９）。一部の実施形態では、地理的位置情報を受け入れ可能な第２のアプリケーションを特定することは、以下のうちの１つ以上を含む（２６１１）。（ｉ）第２のアプリケーションが、地理的位置データを受け入れて処理することが可能な入力受け取りフィールドを含むと判定すること、（ｉｉ）第２のアプリケーションが、地理的位置情報を地図上に表示可能であると判定すること、（ｉｉｉ）第２のアプリケーションが、経路案内を促進するために、地理的位置情報を使用可能であると判定すること、及び（ｉｖ）第２のアプリケーションが、トランスポーテーションサービスを特定し、提供するために、地理的位置情報を使用可能であると判定すること。一部の実施形態では、第２のアプリケーションが、地理的位置情報を受け入れ可能であると特定することは、第２のアプリケーションが、地理的位置データを受け入れて処理することが可能な入力受け取りフィールドを含むと判定することを含み、入力受け取りフィールドは、第２のアプリケーション内に表示される地図内を検索できる検索ボックスである。

第１の入力を検出したことに応じて、（第２のアプリケーションを特定することに加えて）、電子デバイスは、ディスプレイの少なくとも一部上に、第１のアプリケーションとは別個のアフォーダンスを、第２のアプリケーションを第１の物理的位置についての情報と共に開く提案と共に提示する（２６１３）。例えば、第１の入力が、ホームスクリーンを開くことの要求に対応する場合、続いて電子デバイスは、ホームスクリーンの一部上に提示する（２６１７）（例えば、図２５Ｂ及び２５Ｇに示すように、アフォーダンス２５０５が、ホームスクリーンの上部に表示される）。別の実施例として、第１の入力が、アプリケーション切り替えユーザインタフェースを開くことの要求に対応する場合、続いて電子デバイスは、アプリケーション切り替えユーザインタフェース内にアフォーダンスを提示する（２６１５）（例えば、アフォーダンスは、図２５Ｈ内のアフォーダンス２５０５に対して示すように、電子デバイス上で実行されているアプリケーションの表現の下方に位置するディスプレイの一領域内に提示される）。一部の実施形態では、提案は、第２のアプリケーションに関連付けられた種類に特有のテキスト説明を含む（２６１９）（例えば、第１の物理的位置を特定する情報を使用して第２のアプリケーション内にて実行されるアクションの説明、又は、第２のアプリケーション内で検索を行うことの説明のいずれ、例えば、位置Ｘまでのライドを希望しますか？（do you want a ride to location X?）、と、住所Ｘを探しますか？（do you want to look up address X?））。一部の実施形態では、第２のアプリケーションに関連付けられた種類は、第２のアプリケーションを介して利用可能な機能に基づいて判定される（例えば、第２のアプリケーションが使用する位置情報に基づいて、第２のアプリケーションが、位置情報をどのように使用するか、及び、どのような機能が利用可能であるか）。

図２５Ｂに戻ると、電子デバイスは、アフォーダンスにて第２の入力を検出する（２６２１）。アフォーダンスにて第２の入力を検出したことに応じて、電子デバイスは第２のアプリケーションを開き、第１の物理的位置を特定する情報に少なくとも部分的に基づく情報を含むように、第２のアプリケーションをポピュレートする（２６２３）。動作２６２７、２６２９、及び２６３１は、方法２４００に関連して上述する動作２４２３、２４２５、及び２４２７にそれぞれ対応し、上記説明は同様に、方法２６００に適用する（簡潔にするために、これらの詳細は本明細書では繰り返さない）。

方法２４００と比較して、第２のアプリケーションを、第１の物理的位置についての情報と共に開く提案をユーザに提供する前には、方法２６００は、第２のアプリケーションを開くユーザからの特定の要求を受信しない。このようにして、方法２４００及び２６００（及び、それらの方法のそれぞれからの一部の処理ステップを使用するそれらの組み合わせ）の両方に関連付けられた動作を実行することにより、電子デバイスは、ユーザが、地理的位置情報を受け入れ可能なアプリケーションを開く前又は後のいずれに、位置データを予測的に使用するための効率的なユーザエクスペリエンスを提供できる。更に、第２のアプリケーションが、地理的位置情報を受け入れ可能であるとの判定（方法２６００にて）は、第２のアプリケーションが開かれる前にも行われ、このようにして、アプリケーション切り替えユーザインタフェースは、ａｐｐを、以前に閲覧された位置情報と共に開くことのみを、ａｐｐが位置データを受け入れ可能であることが既知の場合に、提案する。簡潔にするために、方法２４００に関する一部の詳細は、方法２６００に対して本明細書では繰り返していないが、そのような詳細は依然として、方法２６００に適用可能である（例えば、第１及び第２のアプリケーションは、位置データを直接シェアしてよいように）。

図２６Ａ～２６Ｂでの動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２４００及び２７００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２６Ａ～２６Ｂに関連して上述された方法２６００と類似の方式で適用可能であることに留意されたい。例えば、方法２６００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２４００及び２７００）を参照して本記載の動作の特性の１つ以上を有する、又は、これらの動作を使用する。一部の実施形態では、方法２６００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図２７は、一部の実施形態に係る、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案する方法を示すフローチャートである。図２８は、図２７の方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２７００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２７００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２７００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２７００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２７００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２７００は、タッチ感知ディスプレイを備える電子デバイス上にて、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案する直感的な方法を提供する。この方法は、経路案内のための物理的位置を使用するために必要な入力数を減らす（又は、無くす）ことにより、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、車両での経路案内のための目的地として使用するための物理的位置を先見的に提案することは、電力を節約し、バッテリを充電する間隔を延長する。

図２７に示すように、電子デバイスは、電子デバイス上で実行されている第１のアプリケーションにてユーザにより閲覧された第１の物理的位置を特定する情報を取得する（２７０１）。電子デバイスは、ユーザが車に乗り込んだと判定する（２７０３）。一部の実施形態では、ユーザが車に乗り込んだと判定することは、電子デバイスが、車両との通信リンクを確立したことを検出することを含む（２７０５）。他の実施形態では、ユーザが車に乗り込んだと判定することは、ユーザが、車両に対する、記憶された位置の所定の距離内に居ることを検出することを含み、ユーザが、たとえ車に乗り込む前であっても、第１の地理的位置を、経路案内のための目的地として使用することを促されるようにしてよい。一部の実施形態では、方法１４００に関連して上述する他の判定のいずれもまた、ユーザが車に乗り込んだことを確立するために使用されてよい。

ユーザが車に乗り込んだと判定したことに応じて、電子デバイスは、第１の物理的位置を、経路案内のための目的地として使用するためのプロンプトを（例えば、図２８に示すユーザインタフェースオブジェクト２８０１などの、デバイス上のユーザインタフェースオブジェクト内にて、又は、シリ（Siri）からのプロンプトを介して、若しくはそれらの両方により）ユーザに提供する（２７０７）。プロンプトを提供したことに応じて、電子デバイスは、第１の物理的位置を経路案内のための目的地として使用する命令をユーザから受信する（２７０９）。

電子デバイスは続いて、第１の物理的位置への経路案内を促進する（２７１１）。一部の実施形態では、経路案内を促進することは、電子デバイスのディスプレイを介して経路案内を提供することを含む（２７１３）。一部の実施形態では、経路案内を促進することは、第１の物理的位置を特定する情報を車両に送信することを含む（２７１５）。一部の実施形態では、経路案内を促進することは、電子デバイスと通信するオーディオシステムを介して経路案内を提供することを含む（２７１７）（例えば、車両のスピーカ又はデバイス自体の内部スピーカ）。一部の実施形態では、動作２７１３、２７１５、及び２７１７のうちの２つ以上が、ユーザが正確に経路案内に従うことを確かにするために実行される。

一部の実施形態では、電子デバイスは、メッセージが、第２の物理的位置を特定する情報を含むことを検出することを含む、電子デバイスがメッセージ（音声メール、テキスト、電子メール、又は他のソーシャルメディアメッセージ）を受信したことを検出する（２７１９）（一部の実施形態では、方法１８００及び２０００に関連して上述する技術のうちの１つ以上が、検出を実行するために使用される）。一部の実施形態では、メッセージが第２の物理的位置を特定する情報を含むことを検出することは、電子デバイス上で利用可能なバーチャルアシスタントが、電子デバイスと通信するオーディオシステムを介して、ユーザへのメッセージを読み上げている間に、検出を実行することを含む（例えば、シリ（Siri）が、デバイスのスピーカを通して、又は、車両のオーディオシステムを通して、メッセージを読み上げている）。

一部の実施形態では、検出したことに応じて、電子デバイスは、第２の物理的位置を、経路案内のための新たな目的地として使用するという新たなプロンプトをユーザに提供する（２７２３）（例えば、第２の物理的位置は、ユーザが運転中に変更されたレストランの場所などの、新たなミーティングポイントに対応し得る一方で、他の実施形態では、第２の物理的位置は、ユーザが、第１の物理的位置に到着した後まで特定されない）。一部の実施形態では、第２の物理的位置を、新たな目的地として使用するための、ユーザからの命令を受信したことに応じて、電子デバイスは、第２の物理的位置への経路案内を促進する（２７２５）（例えば、動作２７１１、２７１３、２７１５、及び２７１７に関連して上述する促進技術のうちの１つ以上を使用して）。

図２７での動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２４００及び２６００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２７に関連して上述された方法２７００と類似の方式で適用可能であることに留意されたい。例えば、方法２７００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２４００及び２６００）を参照して本記載の動作の特性の１つ以上を有する、又は、これらの動作を使用する。一部の実施形態では、方法２７００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

図２９は、一部の実施形態に係る、貼り付けアクションを先見的に提案する方法を示すフローチャートである。図３０Ａ～３０Ｄは、図２９の方法及び／又はプロセスを示すために使用される。以下の実施例のうちの一部は、（タッチ感知面とディスプレイとが組み合わされている）タッチ感知ディスプレイ上の入力を参照して説明されるが、一部の実施形態では、デバイスは、図１Ｄに示すように、ディスプレイ１９４とは別個のタッチ感知面１９５上で入力を検出する。

一部の実施形態では、方法２９００は、電子デバイス（例えば、図１ＥのコンピューティングデバイスＡ～Ｄのいずれの１つに従って構成された、図１Ａのポータブル多機能デバイス１００）及び／又はその電子デバイスの１つ以上の構成要素（例えば、Ｉ／Ｏサブシステム１０６、オペレーティングシステム１２６など）により実行される。一部の実施形態では、方法２９００は、非一時的コンピュータ可読記憶媒体に記憶される命令であって、デバイス１００の１つ以上のプロセッサ１２２などの、デバイスの１つ以上のプロセッサにより実行される命令により管理される（図１Ａ）。説明の簡略化のため、以下では、方法２９００はデバイス１００により実行されるものとして説明する。一部の実施形態では、図１Ａを参照して、方法２９００の動作は、少なくとも部分的に、以下により、又は以下を使用して実行される。プロアクティブモジュール（例えば、プロアクティブモジュール１６３）及びその構成要素、接触／動きモジュール（例えば、接触／動きモジュール１３０）、グラフィックモジュール（例えば、グラフィックモジュール１３２）、及びタッチ感知ディスプレイ（例えば、タッチ感知ディスプレイシステム１１２）。方法２９００の一部の動作が任意選択的に、組み合わされ、かつ／又は一部の動作の順序が任意選択的に変えられる。

以下に説明するように、方法２９００は、タッチ感知ディスプレイを備える電子デバイス上にて、貼り付けアクションを先見的に提案する直感的な方法を提供する。この方法は、貼り付けアクションを実行するために要求されるユーザからの入力を減らし、従って、より効率的なヒューマンマシンインタフェースを作り出す。バッテリ動作電子デバイスの場合、貼り付けアクションを先見的に提案することは、電力を節約し、バッテリを充電する間隔を延長する。

図２９に示すように、電子デバイスは、第１のアプリケーション内にコンテンツを提示する（２９０１）（例えば、図３０Ａに示すように、デバイスは、リモートユーザからのメッセージ「ビッグタイムバンドをチェックしてみて、本当に良いから！（check out big time band, they are really good!）」を含む、メッセージアプリケーションに対応するコンテンツを提示する）。一部の実施形態では、電子デバイスは、コンテンツの少なくとも一部をコピーすることの要求を受信する（２９０３）（例えば、ユーザは、テキスト「ビッグタイムバンド（big time band）」をコピーする）。一部の実施形態では、コンテンツの一部をコピーすることの要求は全く受信されない（つまり、ユーザは、コンテンツのいずれかのコピーすることを要求することなく、第１のアプリケーション内のコンテンツを閲覧するのみである）。

電子デバイスは、第１のアプリケーションとは別個の、入力受け取りフィールドを含む第２のアプリケーションを開くことの要求をユーザから受信する（２９０５）（例えば、図３０Ｃの入力受け取りフィールド３０１１）。例えば、図３０Ｂに示すように、ユーザは、第２のアプリケーション（例えば、図３０Ｂに示す実施例内のブラウザアプリケーション）のアイコン上で、第２のアプリケーションを開くことの要求に対応する入力（例えば、接触３００３）を提供する。図３０Ｃに示すように、この要求を受信したことに応じて、電子デバイスは、入力受け取りフィールドを有する第２のアプリケーションを提示する（２９０７）（例えば、図３０Ｃの入力受け取りフィールド３０１１）。

一部の実施形態では、電子デバイスは、入力受け取りフィールドを、コンテンツの一部を受け入れ可能なフィールドとして識別する（２９０９）。一部の実施形態では、識別することは、入力受け取りフィールドの選択を検出したことに応じて実行される（２９１１）（例えば、ユーザが、図３０Ｃの入力受け取りフィールド３０１１内でタップする）。別の方法で説明すると、ユーザは、第１の入力受け取りフィールド内にフォーカスを置き、電子デバイスは続いて、第１の入力受け取りフィールドが、先見的にコピーされたコンテンツの一部を受け入れ可能であるか否かを判定する。

一部の実施形態では、入力受け取りフィールドにていずれのユーザ入力を受け取る前に、電子デバイスは、選択可能なユーザインタフェースオブジェクト（又は、図３０Ｃの提案部分３００７に示すそれらなどの、１つを超える選択可能なユーザインタフェースオブジェクト）を提供し、ユーザが、コンテンツの少なくとも一部を入力受け取りフィールド内に貼り付けできるようにする（２９１３）。例えば、第２のアプリケーション内のバーチャルキーボードの実質的に上方に表示される提案部分３００７は、コンテンツの一部に基づく２つの提案されたアイテムでポピュレートされる（例えば、「ｂｉｇ ｔｉｍｅ ｂａｎｄ」及び「ｂｉｇ ｔｉｍｅ ｂａｎｄ ｖｉｄｅｏｓ」）。選択可能なユーザインタフェースオブジェクト（例えば、図３０Ｃの入力３００９）の選択を検出したことに応じて、電子デバイスは、コンテンツの一部を、入力受け取りフィールド内に貼り付けする（２９１５）（例えば、図３０Ｄに示すように、「ｂｉｇ ｔｉｍｅ ｂａｎｄ ｖｉｄｅｏｓ」が、入力受け取りフィールド３０１１内に貼り付けされる）。この先見的な貼り付け機能を提供することにより、ユーザは、第２のアプリケーションを終了し、第１のアプリケーション再び開き、第１のアプリケーションからその一部をコピーし、第２のアプリケーションを再び開き、続いて、第２のアプリケーション内で貼り付けアクションを実行する必要がなくなる。その代わりに、ユーザは単に、ユーザが貼り付けしたいコンテンツの一部に関連付けられた、選択可能なユーザインタフェースオブジェクトを選択し、従って、同じ貼り付け機能を実行するための追加入力の数を大幅に減らし、結果として、電子デバイスのためのより効率的で、エネルギを節約するユーザインタフェースとなる。

一部の実施形態では、コンテンツの一部は、画像又はテキストコンテンツ、若しくはテキストコンテンツ及び画像に対応する（２９１５）。このようにして、電子デバイスは、第２のアプリケーションにより受け入れられ得るデータに応じて、様々なコンテンツタイプに対する貼り付けアクションを先見的に提案できる。

一部の実施形態では、選択可能なユーザインタフェースオブジェクトは、コンテンツの一部が第１のアプリケーション内で最近閲覧されたことのインジケーションと共に表示される（例えば、図３０Ｃの提案部分３００７は、「『ビッグタイムバンド』に関連するメッセージが最近閲覧されました（you recently viewed a message related to'big time band'）」などのテキスト説明を含む）。このようにして、ユーザは、貼り付け提案がなされた理由についての明確なインジケーションが提供される。

一部の実施形態では、第１のアプリケーション内で閲覧されたコンテンツに基づくアクションを実行するためのオプションをユーザに提供するユーザインタフェースオブジェクトはまた、ホームスクリーン又はアプリケーション切り替えユーザインタフェースの一部の上に提示されてよい。一部の実施形態では、このユーザインタフェースオブジェクトは、第２のアプリケーションを開くことの要求の前に提示され（動作２９０５）、第１のアプリケーション上に、ホームスクリーン上に、又は、アプリケーション切り替えユーザインタフェース上に提示され得る。ユーザインタフェースオブジェクト３００５に対する実施例を図３０Ｂに示す。ユーザインタフェースオブジェクト３００５の例では、ユーザは、第１のアプリケーション内に提示されたテキストを使用して検索を実行することができる（例えば、「big time band」についてのシステムワイド検索（例えば、スポットライト検索）を実行する、又は、特定のアプリケーション（例えば、サファリ（Safari））を開いて検索を実行する）。

上記の主な実施例としてメッセージアプリケーション及びブラウザアプリケーションが使用される一方で、多くの他の種類のアプリケーションが、方法２９００に関連付けられた技術から恩恵を受ける。例えば、第１のアプリケーションは、写真ブラウズアプリケーションであり得、第２のアプリケーションは、メッセージアプリケーションであり得る（例えば、メッセージアプリケーション内に提示された先見的な貼り付け提案が、写真ブラウズアプリケーション内でユーザにより閲覧される写真に対応するようになる）。

図２９での動作が説明されている特定の順序は、単なる１つの実施例であり、説明される順序が、それらの動作を実行することが可能な唯一の順序であることを示すことを意図するものではない点を理解されたい。当業者であれば、本明細書で説明される動作の順序換えをする様々な方法を認識するであろう。加えて、本明細書で説明される他の方法（例えば、方法２２００及び２９００）に関連して本明細書で説明される、他のプロセスの詳細もまた、図２９に関連して上述された方法２９００と類似の方式で適用可能であることに留意されたい。例えば、方法２９００を参照して先述した動作は、任意選択的に、本明細書で説明する他の方法（例えば、方法２２００及び２９００）を参照して本記載の動作の特性の１つ以上を有する、又は、これらの動作を使用する。一部の実施形態では、方法２９００と併せて、いずれの好適な目的のために、セクション１～１１からのいずれの関連詳細が使用されてよい。簡潔にするために、これらの詳細は、ここでは繰り返さない。

物理的位置についての情報を提案することに関する追加詳細がまた、以下に提供され、これらは、補足方法２２００、２２８０、２９００、２４００、２６００、及び２７００に使用されてよい。一部の実施形態では、方法２２００、２２８０、２９００、２４００、２６００、及び２７００（又は、本明細書に説明するいずれの他の方法）はまた、物理的位置についての情報（又は、他の種類のコンテンツ）を、以下から取得する。ウェブブラウズアプリケーション（例えば、ＡＰＰＬＥ ＩＮＣ（Ｃｕｐｅｒｔｉｎｏ，ＣＡ）からのサファリ（Safari））内でユーザにより閲覧された位置、ユーザにより（例えば、貼り付けボードに）コピーされた住所、来るカレンダーイベントに関連付けられた位置（例えば、イベントが、例えば、１時間、３０分などの、所定の期間内に発生するとスケジュールされている場合、続いて、イベントに関連付けられた位置はまた、ライドシェア又は他のアプリケーション内でのユーザによる使用及び容易な提案のために利用可能とされてよい）、及び、電子デバイス上のバーチャルアシスタントと相互作用するユーザにより話された位置（例えば、ＡＰＰＬＥ ＩＮＣのシリ（Siri）、例えば、ユーザがシリ（Siri）に近隣のレストランについて尋ねると、続いて、それらのレストランについての情報が、他のアプリケーションによる使用のために、又は、他のアプリケーションでの使用のためのユーザに対する提案として、利用可能となってよい）。

一部の実施形態では、位置は、他のアプリケーションによる使用のために、又は、ユーザによる使用のための提案として、位置に関連するいずれの事前のユーザ相互作用なく、利用可能となる。例えば、特定の位置が、来るカレンダーイベントに関連付けられている場合、続いて、その特定の位置は、その来るカレンダーイベント又はその特定の位置をユーザが最近見ていなくとも、ライドシェアアプリケーションでの使用のために先見的に提案されてよい。

一部の実施形態では、位置提案（例えば、本明細書に説明する技術のいずれかを使用して利用可能な位置についての）は、電子デバイス（例えば、デバイス１００）の様々なアプリケーション及び構成要素を通して提供される。例えば、位置提案は、一部の実施形態では、以下の中から利用可能である。
●例えば、図２５Ｄでのユーザインタフェースオブジェクト２５０５に関連して説明されるような、バーチャルキーボードの上方の提案部分（クイックタイプ（ＱｕｉｃｋＴｙｐｅ）バーとも呼ばれる）。
●例えば、図２５Ｃのユーザインタフェースオブジェクト２５０３に関連して説明されるような、アプリケーション切り替えユーザインタフェース。
●いずれのユーザアクションを必要としない、メインスクリーン上の地図アプリケーション。
●地図ウィジェット（例えば、ホームスクリーンの最初のページ上でユーザが実質的に左右方向にスワイプしたことに応じて利用可能となる、ホーム左インタフェース内に示すもの、など）、一部の実施形態では、ユーザが、（すなわち）地図ウィジェット上で強度を増すジェスチャを実行することにより、提案された位置の表示を、地図ウィジェット内に引き起こす。
●いずれのユーザアクションを必要としない、メインスクリーン上のＣａｒＰｌａｙ地図アプリケーション（例えば、方法２７００について説明されるように）。
●検索インタフェース（例えば、図１１Ｂに示すものなどの、検索インタフェース内の位置に対応する検索クエリ提案を示す）。
●デバイス１００のバーチャルアシスタント構成要素（例えば、「そこに案内してほしい（navigate me there）」又は「この場所に電話する（call this place）」などの、ユーザからのテキスト又は口頭質問に応じて、バーチャルアシスタントは、本明細書に説明する技術のいずれかに従って判定された、提案された位置に基づいて、「そこ（there）」及び「この（this）」への参照を明確にできる）。

一部の実施形態では、バーチャルアシスタントアプリケーションによる使用のために位置を利用可能とすることに関連して、デバイス１００は、フォアグランドアプリケーション内でユーザが現在閲覧しているデータに基づいて、「そこに案内してほしい（navigate me there）」又は「この場所に電話する（call this place）」などの質問に応答できる。一部の実施形態では、バーチャルアシスタントに提示された質問に応答するために、サーバに提出されたいずれの要求は、プライバシーを保護する形で実行される。例えば、「そこに案内してほしい（navigate me there）」に対処して応答する際に、バーチャルアシスタントに関連付けられたサーバに要求が送信され、現在のａｐｐ内で位置が利用可能であることのインジケーションのみが、いずれの他のユーザ特定情報なく、及び、位置データを明示的にアドバタイズすることなく、サーバに提供される。一部の実施形態では、サーバは、コマンド／質問を解釈して応答し、適切な位置へのナビゲーションを開始するようデバイス１００に指令する（例えば、フォアグランド位置にてユーザにより閲覧された位置、又は、来るカレンダーイベントに対する位置などの一部の他の適切な位置）。

一部の実施形態では、ユーザがテキストコンテンツをコピーすると、デバイス１００は自動的に（すなわち、ユーザからのそうするようないずれの明示的な命令なく）、コピーされたテキストコンテンツが、位置情報を含むかを判定する（例えば、住所、又は、レストラン名などの、住所を取り出するために使用され得る一部の他の情報）。コピーされたテキストコンテンツが、位置情報を含むとの判定に従って、デバイス１００は、位置情報を表示して使用することが可能な他のシステム構成要素による使用のため、その住所をアドバタイズする（例えば、多くの他の中の、クイックタイプ（QuickType）バー及びアプリケーション切り替えユーザインタフェースなどの、先に提供された実施例）。例えば、ユーザは、住所を含むテキストメッセージを受信し、ユーザは続いて、その住所をコピーし、入力（例えば、アプリケーション切り替えユーザインタフェースを起動するための、ホームボタン上のダブルタップ）を提供し、この入力に応じて、デバイス１００は、「＜ａｄｄｒｅｓｓ＞への道順を地図に表示する（Get directions to in Maps）」、又は、アプリケーションでの使用のために位置が利用可能であることの、一部の他の適切な及び教示的なフレーズ、を表示する、バナーなどの、ユーザインタフェースオブジェクト（例えば、上述するユーザインタフェース２５０３）を表示する。

一部の実施形態では、ユーザによる使用（例えば、クイックタイプ（QuickType）バー内にて、アプリケーション切り替えユーザインタフェース内にて、など）のために提案される位置情報は、位置情報を使用するアプリケーションの種類によって異なる。例えば、クラウドに基づくレビューアプリケーション（例えば、Ｙｅｌｐ）内でユーザが位置を閲覧し、ユーザが続いて、ライドシェアアプリケーション（例えば、Ｕｂｅｒ）に移動すると、ユーザは、以前に閲覧した位置に対応する完全な住所を見ることができる。しかし、その代わりに、ユーザが気象アプリケーションに移動すると、続いてユーザは、完全な住所の代わりに、以前に閲覧した位置の市及び州内のみが提示される場合がある。これは、気象アプリケーションは、市及び州情報のみを必要とし、完全な住所を必要としないからである。一部の実施形態では、アプリケーションは、位置情報が提供されるべき粒度のレベルを指定でき、提案された位置情報が続いて、これに従って提供される（例えば、ライドシェアアプリケーションに対して第１の粒度のレベルにて、及び、気象アプリケーションに対して第２の粒度のレベルにて）。

一部の実施形態では、提案された位置のユーザ選択に応じて挿入される位置情報は、トリガーフレーズに依存する。例えば、クラウドに基づくレビューアプリケーション内でユーザが位置を閲覧し、続いてメッセージアプリケーションに切り替え、「集合場所は～（let's meet at）」とタイプし始めると、続いてデバイスは、クラウドに基づくレビューアプリケーション内でユーザが以前に閲覧した位置を表示してよい（例えば、図２３Ｆのユーザインタフェースオブジェクト２３０９内に）。一部の実施形態では、ユーザが、提案された位置を選択すると（例えば、ユーザインタフェースオブジェクト２３０９上をタップすると）、続いてデバイスは、レストラン名及びレストランの住所の両方を挿入してよい（及び、メニューへのリンク、電話番号などの、他の関連情報も挿入してよい）。一部の実施形態では、ユーザが、「住所は～（the address is）」とタイプし、続いて、提案のユーザ選択に応じて、住所のみが挿入されてよい（名称又は他の詳細の代わりに、なぜなら、トリガーフレーズ「住所は～（the address is）」は、住所のみが必要であることを示すからである）。一部の実施形態では、デバイス１００は、異なるレベルの粒度にてこの情報を選択的に提供するために、提案に対して利用可能な、特定の位置の１つを超える表現を維持する。例えば、ユーザが、クラウドに基づくレビューアプリケーション内から住所をコピーすると、続いてデバイス１００は、コピーされた住所を保持してよく、クラウドに基づくレビューアプリケーションから利用可能な他の情報を更に記憶してよい（例えば、電話番号、レストラン名、メニューへのリンクなどを含め）。

一部の実施形態では、デバイス１００（又は、図１Ａのプロアクティブモジュールなどの構成要素）は、カレンダーイベントを先見的に監視し、来るイベントに関連付けられた位置を、特定のイベント又はその関連する位置とのいずれのユーザ相互作用を受信することもなく、提案する（例えば、３０分、１時間、又は１．５時間などの、開始時間が所定の時間量内のイベント）。一部の実施形態では、所定の時間量を調整するために、交通状態が考慮される。

一部の実施形態では、アプリケーションが、位置情報と共に提案されると（例えば、図２５Ｃのユーザインタフェースオブジェクト２５０３内の、Ｇａｒｙ Ｄａｎｋｏの位置を使用するために提案された、ライドシェアアプリケーションなどの、アプリケーション切り替えユーザインタフェース内）、そのアプリケーションが、アプリケーションの特定を補助する様々なコンテキスト情報／ヒューリスティックに基づいて選択される（例えば、アプリケーションの使用パターン、時刻、曜日、アプリケーションインストールのリーセンシーなどに基づいて、及び、更なる詳細が、セクション８に関連して以下に提供されている）。一部の実施形態では、それぞれのアプリケーションがどれほど最近に使用されたかは、アプリケーションを特定するために使用される追加要素である（例えば、ユーザが最近夕食に出かけ、ライドシェアアプリケーションを利用してそこに行ったとすると、続いてデバイス１００は、ユーザが、約１時間後に自宅に帰ろうとしていると判定してよく、ライドシェアアプリケーションが直近に利用されたため、それを提案する）。

上述するように、方法２２００、２２８０、２９００、２４００、２６００、及び２７００のいずれ（又は、本明細書に説明するいずれかの他の方法）が、物理的位置についての情報を特定すること、記憶すること、及び提供することと併せて、上記詳細を使用してよい。
発明を実施するための追加形態

以下のセクション１～１１に提供する追加説明は、先に提供されたそれらを補足する追加詳細を提供する。一部の状況又は実施形態では、上述する方法のいずれ（例えば、方法６００、８００、１０００、１２００、１４００、１６００、１８００、２０００、２２００、２２８０、２４００、２６００、２７００、及び２９００）は、セクション１～１１に関連して以下に提供されている詳細の一部を、これら方法のいずれかの動作を改善又は洗練するために、必要に応じて使用する場合がある。当業者は、以下のセクション１～１１での説明が本明細書に提供された開示を補足する、多くの方法を認識するであろう（例えば、図１Ａ～３０Ｄに関連して）。
セクション１：モバイルデバイスの動的調整

本セクション「モバイルデバイスの動的調整」の資料は、一部の実施形態に係る、ユーザアクティビティ、ピアイベントデータ、システムデータ、ボーターフィードバック、システムイベントの適応予測、及び／又は、熱条件、に基づいて、モバイルデバイスを動的に調整することに関連し、本明細書に提供された開示を補足する情報を提供する。例えば、以下に詳述するように、本セクションは、アプリケーションがその日のいつ使用される／呼び出されるかを予想することを説明し、また、使用統計をチェックすることを説明し、アプリケーションが、近い将来ユーザにより呼び出される可能性があるか否か判定する。これは、例えば、方法６００の動作６０４及び６０８、並びに、方法８００の動作８０８に関して本明細書に提供された開示を補足する。別の実施例として、セクション１は、属性に関連付けられたイベントが発生する可能性のある時刻を示すために使用される時間的予想（例えば、２４時間中、メールアプリケーションなどの、特定の種類のアプリケーションをユーザが起動する可能性のある時間）を説明する。これは、例えば、使用データの収集／記憶（図３Ａ～３Ｂ）及びトリガー条件の作成／記憶（図４Ａ～４Ｂ）、並びに、方法８００の動作８０８に関連するそれらなどの、本明細書に提供された開示を補足する。更なる実施例として、セクション１は、時間的予想を改善し、特定の期間中に特定のアプリケーションが起動される可能性についてのパーセンテージ値を指定するパノラマ予想を生成するための、追加データ（位置データ、動きデータなど）の使用を説明する。これは、例えば、トリガー条件の作成／記憶（図４Ａ～４Ｂ）に関連するそれらなどの、本明細書に提供された開示を補足する。更に別の実施例として、セクション１は、予想されたイベントの実行を管理するための、投票システムの使用を説明する。これは、例えば、使用データの収集／記憶（図３Ａ～３Ｂ）及びトリガー条件の作成／記憶（図４Ａ～４Ｂ）、並びに、方法８００動作８０８に関連するそれらなどの、本明細書に提供された開示を補足する。更なる実施例として、セクション１は、属性に関連付けられたイベントが、ある期間内に発生する可能性を予測することを説明する（様々な種類の予想に基づいて）。これは、例えば、使用データの収集／記憶（図３Ａ～３Ｂ）及びトリガー条件の作成／記憶（図４Ａ～４Ｂ）に関連するそれらなどの、本明細書に提供された開示を補足する。１つの追加的実施例として、セクション１は、熱条件の管理を説明する。これは、電力の節約に関する、本明細書に提供された開示を補足する（例えば、方法６００及び８００又は上述するいずれかの他の方法が、エネルギ効率良く動作することを確かにするために）。
モバイルデバイスの動的調整の概要

一部の実装では、モバイルデバイス（例えば、図１Ａのデバイス１００）は、環境、システム、及びユーザイベントを監視するよう構成され得る。モバイルデバイスは、システム設定の調整をトリガーし得る１つ以上のイベントの発生を検出するよう構成され得る。

一部の実装では、モバイルデバイスは、所定の及び／又は動的に定義された属性で構成され得る。属性は、システムイベントを追跡するために、システムにより使用され得る。属性イベントは、記憶され得、属性イベントの将来の発生を予測するために後に使用され得る。記憶された属性イベントは、モバイルデバイスにより実行される処理に関する決定するために、システムにより使用され得る。属性は、リソースを割り当て、システム上での将来のイベント又はアクティビティをサポートするための割当量が関連付けられ得る。

一部の実装では、モバイルデバイス上で実行される様々なアプリケーション、機能、及びプロセスが、属性イベントを提出し得る。アプリケーション、機能、及びプロセスは、提出したイベントに基づく予想を後に要求し得る。アプリケーション、機能、及びプロセスは、属性に関連付けられた割当量及び報告されたイベントに関連付けられたコストに基づいて、割り当てを実行し得る。アプリケーション、機能、及びプロセスは、例えば、モバイルデバイスのオペレーティングシステム又は第三者アプリケーションに関連付けられ得る。

一部の実装では、モバイルデバイスは、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。モバイルデバイスは、アプリケーションがユーザによりいつ呼び出されるかを追跡し続け得る。呼び出し情報に基づき、モバイルデバイスは、アプリケーションがその日のいつ呼び出されるか予想し得る。モバイルデバイスは続いて、先制してアプリケーションを起動して、更新をダウンロードし得、更新されたコンテンツをアプリケーションがダウンロードするのを待つ必要なく、ユーザがアプリケーションを呼び出して、現在の更新されたコンテンツを閲覧し得るようにする。

一部の実装では、モバイルデバイスは、アプリケーションに対する新たなコンテンツが利用可能で、ダウンロード可能であることを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。モバイルデバイスは、プッシュ通知に関連付けられたアプリケーションをバックグラウンドで起動し、新たなコンテンツをダウンロードし得る。コンテンツのダウンロード後、モバイルデバイスは、プッシュ通知を受信したことをユーザに示すグラフィカルインタフェースを提示し得る。ユーザは続いて、アプリケーションを呼び出し、更新されたコンテンツを閲覧し得る。

一部の実装では、モバイルデバイスは、モバイルデバイス上のアプリケーションに対するコンテンツのプロセス外ダウンロード及び／又はアップロードを実行するよう構成され得る。例えば、モバイルデバイス上のアプリケーションに対するコンテンツのダウンローディング及び／又はアップローディングのための専用プロセスが、モバイルデバイス上に構成され得る。

アプリケーションは、アップロード／ダウンロードが実行されている間に、サスペンド又は終了され得る。アプリケーションは、アップロード／ダウンロードが完了すると、呼び出され得る。

一部の実装では、アプリケーションを実行する又はネットワークインタフェースにアクセスする前に、モバイルデバイスは、バッテリ電力及びセルラーデータ使用割当量をチェックし、十分な電力及びデータがユーザ呼び出し動作に利用可能であることを確かにするよう構成され得る。アプリケーションをバックグラウンドで起動する前に、モバイルデバイスは、使用統計をチェックし、アプリケーションがユーザにより近い将来に呼び出される可能性があるか否かが判定され得る。

一部の実装では、属性イベントデータが、同じユーザが所有するモバイルデバイスとの間でシェアされ得る。モバイルデバイスは、ピアデバイスからイベントデータを受信し、ピアデバイスに関する相互作用又は動作に関して、受信したイベントデータに基づいて、決定し得る。イベントデータは、予想、統計、及び／又は生の（例えば、未処理の）イベントデータとしてシェアされ得る。モバイルデバイスは、ピアデバイスと通信するか否かを、例えば、受信したイベントデータに基づいて判定し得る。

特定の実装は、検出されたイベントに応じて、モバイルデバイスの構成要素を動的に調整することにより、バッテリ電力が節約される、という利点を少なくとも提供する。ユーザがいつアプリケーションを呼び出し、コンテンツをダウンロードするかを予期し、ユーザがアプリケーションを呼び出すとすぐに、更新されたコンテンツを閲覧できるようになることにより、ユーザエクスペリエンスが改善され得る。

１つ以上の実装の詳細は、添付の図面及び下記の説明に記載されている。その他の特徴、態様、及び潜在的な利点は、説明及び図面から、並びに特許請求の範囲から明らかになるであろう。
モバイルデバイスの動的調整の詳細説明
概説

本セクションは、様々なシステムイベントに基づいて、モバイルデバイスの適応を可能にし、バッテリ寿命、電力要件、熱管理、及び性能との間のトレードオフを促進するシステムアーキテクチャを説明する。システムは、基礎をなすイベント収集アーキテクチャ、及び、システムイベントから学習するヒューリスティックプロセスのセットを提供し、ユーザエクスペリエンスの顕著な低下なく、バッテリ寿命を最大化する。システムは、システム定義属性及びクライアント定義属性を監視し、このシステム定義属性及びクライアント定義属性を使用し、将来のイベントの発生を予測又は予想し得る。このシステムは、システムの将来の挙動、同様に、ユーザが期待するデバイス性能を、動的に収集した統計及び／又は明示的に指定されたユーザの意図に基づいて予期し得る。システムは、予期するシステム挙動に対するユーザエクスペリエンスを改善するために、どのハードウェア及びソフトウェア制御パラメータを設定し、そのパラメータにどのような値を設定するかを判定し得る。システムは、システム監視及びハードウェア制御を活用し、モバイルデバイスに利用可能なシステム及びネットワークリソースを拡張しつつ、ユーザエクスペリエンスでの総合的な改善を達成する。従って、システムは、ユーザエクスペリエンスへの影響を最小化にしつつ、システム及びネットワークリソースを最大化し得る。
データ収集－ユーザセントリック統計

図３１－１は、モバイルデバイス３１＿１００の動的調整を実行するよう構成されたモバイルデバイス例３１＿１００を示す。一部の実装では、モバイルデバイス３１＿１００は、デバイス条件、ネットワーク条件、システムサービス（例えば、デーモン）、及びユーザの行動に関連するイベントを収集するサンプリングデーモン３１＿１０２を含み得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーション、センサ、及びモバイルデバイス３１＿１００により受信したユーザ入力に関連する統計を収集し、その統計をイベントデータストア３１＿１０４に記憶し得る。統計は、モバイルデバイス３１＿１００上で実行される様々なクライアント（例えば、アプリケーション、ユーティリティ、機能、第三者アプリケーションなど）により、イベントとして報告された所定の属性又はクライアント定義属性を使用して、サンプリングデーモン３１＿１０２に報告され得る。
データ収集－イベント＆属性

一部の実装では、モバイルデバイス３１＿１００は、システム及び／又はアプリケーションイベントを収集するためのフレームワークと共に構成され得る。例えば、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の様々なアプリケーション、ユーティリティ、及び他の構成要素が、後の統計分析のためにイベントをサンプリングデーモン３１＿１０２に提出できるようにするアプリケーションプログラミングインタフェース（ＡＰＩ）と共に構成され得る。

一部の実装では、サンプリングデーモン３１＿１０２によりイベントデータストア３１＿１０４に記録された各イベントは、属性名（例えば、「ｂｕｎｄｌｅＩｄ」）、属性値（例えば、「ｃｏｎｔａｃｔｓ」）、匿名ビーコン情報、匿名位置情報、日付情報（例えば、イベントのＧＭＴ日付）、時間情報（例えば、イベントのローカルでの２４時間時刻）、ネットワーク品質情報、プロセッサ使用メトリックス、ディスク入力／出力メトリックス、現在のユーザの識別、及び／又はイベントの種類（例えば、開始、停止、発生）を含み得る。例えば、属性名は、イベントに関連付けられた属性の種類を特定し得る。属性名は、例えば、サンプリングデーモン３１＿１０２により追跡される特定のメトリックの特定に使用され得る。属性値は、属性に関連付けられた値（例えば、文字列、整数、浮動小数点）であり得る。匿名ビーコン情報は、どの無線ビーコン（例えば、Ｂｌｕｅｔｏｏｔｈ、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ、Ｗｉ－Ｆｉなど）が、モバイルデバイスの範囲内にあるかを、ビーコン情報をユーザ又はデバイスに紐付ける又は関連付けることなく示し得る。同様に、匿名位置情報は、モバイルデバイスの位置を、位置情報をユーザ又はデバイスに紐付ける又は関連付けることなく特定し得る。例えば、位置情報は、衛星データ（例えば、全地球測位システム）、セルラーデータ、Ｗｉ－Ｆｉデータ、Ｂｌｕｅｔｏｏｔｈデータから、モバイルデバイス３１＿１００上に構成された様々な送受信機を使用して、導くことができる。ネットワーク品質情報は、イベントが発生した際にモバイルデバイス３１＿１００により検出される、モバイルデバイスのネットワーク（例えば、Ｗｉ－Ｆｉ、セルラー、衛星など）接続の品質を示し得る。

一部の実装では、各イベントに対するイベントデータは、イベントが発生した、始まった、又は停止したことを示し得る。例えば、時間課金（例えば、継続時間課金）は、属性に対する開始イベント及び停止イベントを示す、同じ属性に対するイベントのペアにて実行され得る。例えば、サンプリングデーモン３１＿１０２は、値「ｃｏｎｔａｃｔｓ」を有する属性「ｂｕｎｄｌｅＩｄ」に対する開始イベントを受信し得る。その後、サンプリングデーモン１０２は、値「ｃｏｎｔａｃｔｓ」を有する属性「ｂｕｎｄｌｅＩｄ」に対する停止イベントを受信し得る。サンプリングデーモン３１＿１０２は、開始イベントの時間を停止イベントの時間と比較し、「ｃｏｎｔａｃｔｓ」アプリケーションがどれほど長くアクティブであったか（例えば、持続時間）を判定し得る。一部の実装では、時間課金の対象ではないイベントは、ポイントイベント（例えば、単一の発生）として記録され得る。例えば、イベントの時間での瞬間バッテリレベルを指定する「ｂａｔｔｅｒｙＬｅｖｅｌ」システム属性に関連付けられたイベントは単に、イベントの発生として記録され得る。

以下の表１は、サンプリングデーモン３１＿１０２によりイベントデータストア３１＿１０４に記録された属性イベントエントリの一例を提供する。第１のエントリは、「ｃｏｎｔａｃｔｓ」アプリケーションがユーザ「Ｆｒｅｄ」により呼び出されたことを示す「ｂｕｎｄｌｅＩｄ」イベントを記録する。この「ｂｕｎｄｌｅＩｄ」イベントは、Ｆｒｅｄが連絡先アプリケーションの使用を開始したことを示す開始イベントである。第２のエントリは、モバイルデバイス３１＿１００のバッテリレベルが４６％であることを示す「ｂａｔｔｅｒｙＬｅｖｅｌ」イベントエントリであり、このイベントは、発生タイプイベント（例えば、単一のポイントイベント）である。第３のエントリは、値「Ｇｅｏｒｇｅ」に関連付けられた「ｐｅｒｓｏｎＮａｍｅ」イベントである。この「ｐｅｒｓｏｎＮａｍｅ」イベントは、ユーザＦｒｅｄが、連絡先アプリケーション内で、連絡先「Ｇｅｏｒｇｅ」に対する連絡先情報にアクセスした事実を記録するために使用され、これは、発生タイプイベントである。第４のエントリは、「ｃｏｎｔａｃｔｓ」アプリケーションがユーザ「Ｆｒｅｄ」により閉じられた又は非表示にされたことを示す「ｂｕｎｄｌｅＩｄ」イベントを記録する。このｂｕｎｄｌｅＩｄイベントは、Ｆｒｅｄが連絡先アプリケーションの使用を停止したことを示す停止イベントである。「ｂｕｎｄｌｅＩｄ」属性に対する開始及び停止イベントを記録することにより、サンプリングデーモン３１＿１０２は、ユーザＦｒｅｄが、連絡先アプリケーションを２０１４年５月１２日に８分間使用したことを、開始及び停止イベントに対応するタイムスタンプに基づいて判定し得る。この属性イベント情報は、例えば、モバイルデバイス３１＿１００上のアプリケーションに関連し、連絡先アプリケーションに特に関連するユーザアクティビティの予想に使用され得る。

所定の属性

一部の実装では、イベントデータは、サンプリングデーモン３１＿１０２に、既知又は所定の属性を使用して、提出され得る。既知又は所定の属性は、モバイルデバイス３１＿１００の様々なアプリケーション、ユーティリティ、機能、又は他の構成要素により使用され、イベントデータをサンプリングデーモン３１＿１０２に提出し得る、包括的なシステム属性であり得る。属性定義（例えば、属性名、関連付けられた値のデータタイプなど）が予め定められている一方で、所定の属性に指定されたこれらの値は、イベント毎に異なり得る。例えば、モバイルデバイス３１＿１００は、アプリケーションを特定するための所定の属性「ｂｕｎｄｌｅＩｄ」及び対象人物を特定するための「ｐｅｒｓｏｎＮａｍｅ」で構成され得る。「ｂｕｎｄｌｅＩｄ」に指定された値は、どのアプリケーションがモバイルデバイス３１＿１００上でアクティブかに基づいて異なり得る。「ｐｅｒｓｏｎＮａｍｅ」に指定された値は、ユーザ入力に基づいて異なり得る。例えば、ユーザが、「Ｇｅｏｒｇｅ」からの電子メールメッセージを選択すると、続いて、「ｐｅｒｓｏｎＮａｍｅ」属性値は、「Ｇｅｏｒｇｅ」に設定され得る。ユーザが、「Ｂｏｂ」に関連付けられた連絡先エントリを選択すると、続いて、「ｐｅｒｓｏｎＮａｍｅ」属性値が、「Ｂｏｂ」に設定され得る。モバイルデバイス３１＿１００のアプリケーション、ユーティリティ、機能、又は他の構成要素が、イベントをサンプリングデーモン３１＿１０２に、所定の属性を使用して提出すると、そのアプリケーション、ユーティリティ、機能、又は他の構成要素は、そのイベントに対する所定の属性に関連付けられる値を指定し得る。所定又は既知のシステムイベントの実施例を以下の段落に説明する。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００にインストールされたアプリケーション（例えば、アプリケーションバンドル）の名称又は識別子を指定する所定の属性（例えば、「ｓｙｓｔｅｍ．ｂｕｎｄｌｅＩｄ」）で構成され得る。アプリケーションが起動されると、（例えば、アプリケーションの起動を担う）アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２のＡＰＩを使用し、アプリケーションの識別子又は名称（例えば、連絡先アプリケーションに対する「ｃｏｎｔａｃｔｓ」）を、「ｓｙｓｔｅｍ．ｂｕｎｄｌｅＩｄ」システム属性に対する値として提出し得る。サンプリングデーモン３１＿１０２は、「ｃｏｎｔａｃｔｓ」アプリケーションの起動の発生を、例えば、上述するように、イベントとして、他のイベントデータと共に、イベントデータストア３１＿１０４に記録し得る。あるいは、アプリケーションは、サンプリングデーモン３１＿１０２のＡＰＩを使用し、アプリケーション「ｃｏｎｔａｃｔｓ」がいつ呼び出され、そのアプリケーションがいつ非表示とされる又は閉じられるかのそれぞれに対応する開始及び停止イベントを示し得る。例えば、「ｂｕｎｄｌｅＩｄ」属性が使用され、モバイルデバイス３１＿１００上のアプリケーション起動イベントが記録され得る。「ｂｕｎｄｌｅＩｄ」属性が使用され、モバイルデバイス３１＿１００上のアプリケーション終了イベントが記録され得る。単なるイベントの発生ではなく、「ｂｕｎｄｌｅＩｄ」属性に関連付けられた開始及び停止イベントを指定することにより、サンプリングデーモン３１＿１０２は、「ｃｏｎｔａｃｔｓ」アプリケーションがどれほど長くモバイルデバイス３１＿１００のユーザにより使用されたかを判定し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のユーザの名称若しくは識別子、又は、モバイルデバイス３１＿１００のユーザにとっての対象人物を指定する所定の属性（例えば、「ｓｙｓｔｅｍ．ｐｅｒｓｏｎＮａｍｅ」）で構成され得る。例えば、モバイルデバイス３１＿１００にログインする、ウェイクする、又はアクセスすると、モバイルデバイス３１＿１００の現在のユーザを特定する「ｐｅｒｓｏｎＮａｍｅ」属性に関連付けられたイベントが生成され、サンプリングデーモン３１＿１０２に提出され得る。別の人物に関連付けられたデータにユーザがアクセスすると、その別の人物をユーザにとっての対象人物として特定する「ｐｅｒｓｏｎＮａｍｅ」属性イベントが生成され、サンプリングデーモン３１＿１０２に提出され得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の位置を示す所定の属性（例えば、「ｓｙｓｔｅｍ．ａｎｏｎｙｍｉｚｅｄＬｏｃａｔｉｏｎ」）で構成され得る。例えば、モバイルデバイス３１＿１００は、イベントが生成された際のモバイルデバイス３１＿１００の位置を指定する「ａｎｏｎｙｍｉｚｅｄＬｏｃａｔｉｏｎ」属性に関連付けられたイベントを生成し、サンプリングデーモン３１＿１０２に提出し得る。位置データは、その位置が特定のユーザ又はデバイスに後に紐付けられない又は関連付けされないよう、匿名とされ得る。「ａｎｏｎｙｍｉｚｅｄＬｏｃａｔｉｏｎ」属性イベントは、例えば、ユーザがモバイルデバイス３１＿１００の位置に基づくサービスを使用する際にはいつでも生成され、記憶され得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の飛行機モードがオン又はオフであることを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ａｉｒｐｌａｎｅＭｏｄｅ」）で構成され得る。例えば、ユーザが飛行機モードをオン又はオフにすると、モバイルデバイス３１＿１００は、イベント時の飛行機モード状態を示すイベントを生成し、サンプリングデーモン３１＿１０２に提出し得る。例えば、「ａｉｒｐｌａｎｅＭｏｄｅ」属性の値は、ａｉｒｐｌａｎｅＭｏｄｅがオンの場合は真（例えば、１）に設定され、飛行機モードがオフの場合は偽（例えば、０）に設定され得る。サンプリングデーモン３１＿１０２は、今度は、「ａｉｒｐｌａｎｅＭｏｄｅ」属性値を含む「ａｉｒｐｌａｎｅＭｏｄｅ」イベントを、イベントデータストア３１＿１０４に記憶し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の電源ケーブルが接続されている又は接続されていないことを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｃａｂｌｅＰｌｕｇｉｎ」）で構成され得る。例えば、電源ケーブルが接続されていないことをモバイルデバイス３１＿１００が検出すると、モバイルデバイス３１＿１００は、「ｃａｂｌｅＰｌｕｇｉｎ」属性値が偽（例えば、０）であることを示すイベントを生成し得る。電源ケーブルがモバイルデバイス３１＿１００に接続されていることをモバイルデバイス３１＿１００が検出すると、モバイルデバイス３１＿１００は、「ｃａｂｌｅＰｌｕｇｉｎ」属性が真（例えば、１）であることを示すイベントを生成し得る。モバイルデバイス３１＿１００は、「ｃａｂｌｅＰｌｕｇｉｎ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のディスプレイスクリーンがロックされているか又はロック解除されているかを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｓｃｒｅｅｎＬｏｃｋ」）で構成され得る。例えば、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のディスプレイスクリーンが（例えば、システムにより又はユーザにより）ロックされているか又は（例えば、ユーザにより）ロック解除されているかを検出し得る。ディスプレイスクリーンのロック又はロック解除を検出すると、モバイルデバイス３１＿１００は、「ｓｃｒｅｅｎＬｏｃｋ」属性を含むイベントを生成し、そのイベントに対する「ｓｃｒｅｅｎＬｏｃｋ」属性値を真（例えば、ロック、整数の１）又は偽（例えば、ロック解除、整数の０）に設定し、モバイルデバイス３１＿１００のディスプレイスクリーンがロックされたか又はロック解除されたかを示し得る。モバイルデバイス３１＿１００は、「ｓｃｒｅｅｎＬｏｃｋ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００がスリープモードにあるか否かを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｓｌｅｅｐＷａｋｅ」）で構成され得る。例えば、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００がスリープモードへと移行することを検出し得る。モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００がスリープモードを終了する（例えば、ウェイクする）ことを検出し得る。スリープモードへと移行すること又はこれを終了することを検出すると、モバイルデバイスは、「ｓｌｅｅｐＷａｋｅ」属性を含むイベントを生成し、その属性値を真又は偽（例えば、整数の１又は０のそれぞれ）に設定し、「ｓｌｅｅｐＷａｋｅ」イベント時の、モバイルデバイス３１＿１００のスリープモード状態を示し得る。モバイルデバイス３１＿１００は、「ｓｌｅｅｐＷａｋｅ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のディスプレイが点灯しているか否かを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｂａｃｋｌｉｇｈｔ」）で構成され得る。「ｂａｃｋｌｉｇｈｔ」属性は、バックライトの強度又はレベルを示す値が指定され得る。例えば、モバイルデバイス３１＿１００のユーザは、モバイルデバイス３１＿１００のディスプレイの照明（バックライト）の強度を調整し得る。ユーザは、環境光が明るい場合には、バックライトの強度を増加し得る。ユーザは、環境光が暗い場合には、バックライトの強度を減少し得る。バックライト設定の変更を検出すると、モバイルデバイス３１＿１００は、「ｂａｃｋｌｉｇｈｔ」属性を含むイベントを生成し、その属性値を、調整されたバックライト設定（例えば、強度レベル）に設定し得る。モバイルデバイス３１＿１００は、「ｂａｃｋｌｉｇｈｔ」変化イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の環境光センサにより検出される環境光強度値を示す所定の属性（例えば、「ｓｙｓｔｅｍ．ＡＬＳ」）で構成され得る。「ＡＬＳ」属性は、モバイルデバイス３１＿１００周囲の環境光の強度又はレベルを示す値が指定され得る。例えば、モバイルデバイス３１＿１００の環境光センサは、環境光の強度変化を検出し得る。モバイルデバイス３１＿１００は、強度変化が閾値をいくらか超えたかを判定し得る。閾値を超える環境光変化を検出すると、モバイルデバイス３１＿１００は、「ＡＬＳ」属性を含むイベントを生成し、その属性値を、検出された環境光強度値に設定し得る。モバイルデバイス３１＿１００は、「ＡＬＳ」変化イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のディスプレイが、オブジェクト（例えば、ユーザの顔、テーブル上など）に近いことを、モバイルデバイス３１＿１００の近接センサが検出したことを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｐｒｏｘｉｍｉｔｙ」）で構成され得る。「ｐｒｏｘｉｍｉｔｙ」属性は、モバイルデバイスのディスプレイがオブジェクトに近接するか否かを示す値が指定され得る（例えば、真、偽、０、１）。例えば、モバイルデバイス３１＿１００の近接センサは、近接の変化を検出し得る。近接の変化を検出すると、モバイルデバイス３１＿１００は、「ｐｒｏｘｉｍｉｔｙ」属性を含むイベントを生成し、その属性値を、モバイルデバイス３１＿１００がオブジェクトに近接する場合には真（例えば、１）に、モバイルデバイス３１＿１００がオブジェクトに近接しない場合には偽（例えば、０）に設定し得る。モバイルデバイス３１＿１００は、「ｐｒｏｘｉｍｉｔｙ」変化イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００により検出された動きの種類を示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｍｏｔｉｏｎＳｔａｔｅ」）で構成され得る。「ｍｏｔｉｏｎＳｔａｔｅ」属性は、モバイルデバイスが、止まっている、動いている、ランニング中である、運転中である、歩行中であるなど、か否かを示す値が指定され得る。例えば、モバイルデバイス３１＿１００の動きセンサ（例えば、加速度計）は、モバイルデバイス３１＿１００の移動を検出し得る。モバイルデバイス３１＿１００は、検出された移動にて検出された動きのパターンに基づいて、その検出された移動を分類し得る。動きのパターンは、例えばユーザが止まっている、動いている、ランニング中である、運転中である、歩いているなどの、ユーザアクティビティに分類され得る。移動の変化を検出すると、モバイルデバイス３１＿１００は、「ｍｏｔｉｏｎＳｔａｔｅ」属性を含むイベントを生成し得、その属性値を、その検出された移動の種類に設定する（例えば、止まっている、ランニング中である、歩行中である、運転中であるなど）。モバイルデバイス３１＿１００は、「ｍｏｔｉｏｎＳｔａｔｅ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００により検出されたネットワーク接続の品質を示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｎｅｔｗｏｒｋＱｕａｌｉｔｙ」）で構成され得る。「ｎｅｔｗｏｒｋＱｕａｌｉｔｙ」属性は、ｎ秒（例えば、１ミリ秒、２秒など）の期間にわたるネットワークスループット値を示す値が指定され得る。例えば、モバイルデバイス３１＿１００は、データネットワーク（例えば、セルラーデータ、衛星データ、Ｗｉ－Ｆｉ、インターネットなど）に接続し得る。モバイルデバイス３１＿１００は、ある期間（例えば、５秒）にわたるネットワーク接続のデータスループットを監視し得る。モバイルデバイスは、毎秒に送信されるデータ量を計算し得る（例えば、ビット／秒、バイト／秒など）。スループットの変化を検出すると、又は、新たなネットワーク接続を作成すると、モバイルデバイス３１＿１００は、「ｎｅｔｗｏｒｋＱｕａｌｉｔｙ」属性を含むイベントを生成し、その属性値を、その計算されたスループット値に設定し得る。モバイルデバイス３１＿１００は、「ｎｅｔｗｏｒｋＱｕａｌｉｔｙ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の内蔵バッテリの瞬間充電レベルを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｂａｔｔｅｒｙＬｅｖｅｌ」）で構成され得る。「ｂａｔｔｅｒｙＬｅｖｅｌ」属性は、バッテリの充電レベル（例えば、パーセンテージ）を示す値が指定され得る。例えば、モバイルデバイス３１＿１００は、バッテリの充電レベルを定期的に（例えば、毎５秒、毎分、毎１５分など）判定し、「ｂａｔｔｅｒｙＬｅｖｅｌ」イベントを生成し、バッテリの充電レベルを記録し得る。モバイルデバイス３１＿１００は、いつバッテリ充電レベルを監視し、充電レベルが閾値量分変化したかを判定し、「ｂａｔｔｅｒｙＬｅｖｅｌ」イベントを生成し、バッテリの充電レベルを記録し得る。モバイルデバイス３１＿１００は、「ｂａｔｔｅｒｙＬｅｖｅｌ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の熱レベルを示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｔｈｅｒｍａｌＬｅｖｅｌ」）で構成され得る。例えば、モバイルデバイス３１＿１００の熱レベルは、モバイルデバイスの現在の作動温度であり得る（例えば、摂氏）。モバイルデバイス３１＿１００の熱レベルは、温度値の範囲を示すレベルであり得る（例えば、高、中、低、正常、異常など）。例えば、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の熱状態を監視するためのユーティリティ又は機能と共に構成され得る。温度変化又は熱レベル変化を検出すると、モバイルデバイス３１＿１００の熱ユーティリティは、「ｔｈｅｒｍａｌＬｅｖｅｌ」属性を含むイベントを生成し、その属性値を、作動温度又は現在の熱レベルに設定し得る。モバイルデバイス３１＿１００は、「ｔｈｅｒｍａｌＬｅｖｅｌ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、ｎ秒（例えば、２ミリ秒、３秒など）の期間にわたるモバイルデバイス３１＿１００のエネルギ使用量を示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｅｎｅｒｇｙ」）で構成され得る。例えば、モバイルデバイス３１＿１００の機能（例えば、アプリケーションの呼び出し、ディスプレイの点灯、データの送信など）をユーザが呼び出すと、モバイルデバイス３１＿１００は、機能が実行されている期間にわたるエネルギ使用量を監視し、各アクティビティ又は機能がどれほどのエネルギを使用するかを予測し得る。モバイルデバイス３１＿１００は続いて、「ｅｎｅｒｇｙ」属性を含むイベントを生成し、その属性値を、計算された平均エネルギ使用量に設定し得る。モバイルデバイス３１＿１００は、「ｅｎｅｒｇｙ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

一部の実装では、モバイルデバイス３１＿１００は、ｎ秒（例えば、２ミリ秒、３秒など）の期間にわたるモバイルデバイス３１＿１００のネットワークデータ使用量を示す所定の属性（例えば、「ｓｙｓｔｅｍ．ｎｅｔｗｏｒｋＢｙｔｅｓ」）で構成され得る。例えば、モバイルデバイス３１＿１００のネットワーク接続を経由してデータの送信を必要とする機能をユーザが呼び出す又は動作をユーザが開始すると、モバイルデバイス３１＿１００は、ある期間にわたるネットワークデータ使用量を監視し、どれほどのネットワークデータを各アクティビティ又は機能が使用又は送信するかを予測し得る。モバイルデバイス３１＿１００は続いて、「ｎｅｔｗｏｒｋＢｙｔｅｓ」属性を含むイベントを生成し、その属性値を、計算された平均ネットワークデータ使用量に設定し得る。モバイルデバイス３１＿１００は、「ｎｅｔｗｏｒｋＢｙｔｅｓ」イベントを、イベントデータストア３１＿１０４への記憶のために、サンプリングデーモン３１＿１０２に提出し得る。

他の所定の属性としては、モバイルデバイス３１＿１００がそのバッテリを充電しているか否かを示す、真／偽（例えば、１／０）属性値を有する「ｓｙｓｔｅｍ．ｃｈａｒｇｉｎｇＳｔａｔｕｓ」属性、現在のバッテリ充電量（例えば、ｍＡｈにて、ｂａｔｔｅｒｙＬｅｖｅｌに比例）を示す属性値を有する「ｓｙｓｔｅｍ．ｂａｔｔｅｒｙＣａｐａｃｉｔｙ」属性、及び、ピアデバイスの出現を追跡するデバイス識別子（例えば、文字列）属性値を有する「ｓｙｓｔｅｍ．ｄｅｖｉｃｅＰｒｅｓｅｎｃｅ」属性、が挙げられ得る。例えば、「ｄｅｖｉｃｅＰｒｅｓｅｎｃｅ」属性は、ピアツーピアデータシェアリングをスケジューリングする際のピアデバイスの出現の予想に使用され得る。
カスタム属性

一部の実装では、クライアント特有の属性が、サンプリングデーモン３１＿１０２のクライアントにより動的に定義され得る。例えば、所定の、モバイルデバイス３１＿１００上で構成された属性を使用する代わりに（例えば、サンプリングデーモン３１＿１０２又はオペレーティングシステムにて）、クライアント（例えば、第三者アプリケーション）は、それら自身のイベント属性を動的に定義し得る。例えば、電子メールアプリケーションは、「ｍａｉｌｂｏｘ」属性を動的に（例えば、ランタイムにて）作成し得る。電子メールアプリケーション（「ｍａｉｌａｐｐ」）は、サンプリングデーモン３１＿１０２のＡＰＩを使用し、属性名（例えば、「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」）及び属性値タイプ（例えば、文字列、整数、浮動小数点）を定義し得る。クライアントが新たなカスタム属性を作成すると（登録すると）、クライアントは、その属性を使用して、イベントデータストア３１＿１０４に記憶されるイベントを生成し得る。例えば、ｍａｉｌａｐｐは、「ｍａｉｌｂｏｘ」属性を使用し、ユーザがアクセスしている電子メールアプリケーション内のメールボックスはどれかを報告し得る。ユーザが「ｗｏｒｋ」メールボックスにアクセスしている場合、続いて、ｍａｉｌａｐｐは、「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」属性を使用してイベントを作成し、属性の値を「ｗｏｒｋ」に設定し、「ｗｏｒｋ」メールボックスへのユーザのアクセスを記録し得る。サンプリングデーモン３１＿１０２及びクライアントは続いて、記憶されたメールボックスイベント情報を使用し、例えば、ユーザが将来のいつに「ｗｏｒｋ」メールボックスにアクセスする可能性があるかを予測し得る。

一部の実装では、クライアントアプリケーションがモバイルデバイス３１＿１００から消去される（例えば、削除される、アンインストールされる）と、そのクライアントアプリケーションにより作成された属性が、モバイルデバイス３１＿１００から削除され得る。更に、クライアントアプリケーションが消去されると、クライアントアプリケーションに関連付けられたイベントデータが削除され得る。例えば、ｍａｉｌａｐｐがモバイルデバイス３１＿１００から削除されると、ｍａｉｌａｐｐに関連付けられたイベントデータの全てと共に、属性「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」がモバイルデバイス３１＿１００から削除され得る。
イベントを生成するクライアントの実施例

一部の実装では、サンプリングデーモン３１＿１０２は、アプリケーションイベント（例えば、「ｓｙｓｔｅｍ．ｂｕｎｄｌｅＩｄ」イベント）を、アプリケーションマネジャプロセス３１＿１０６から受信し得る。例えば、アプリケーションマネジャ３１＿１０６は、モバイルデバイス３１＿１００上でアプリケーション（例えば、アプリケーション３１＿１０８）を開始し、停止し、及び監視するプロセスであり得る。一部の実装では、アプリケーションマネジャ３１＿１０６は、モバイルデバイス３１＿１００上で実行されるアプリケーションに対する開始及び停止時間（例えば、「ｂｕｎｄｌｅＩｄ」開始及び停止イベント）を、サンプリングデーモン３１＿１０２に報告し得る。例えば、ユーザがアプリケーションを呼び出す又は起動すると、アプリケーションマネジャ３１＿１０６は、アプリケーションの名称又は識別子を指定する、呼び出されたアプリケーションに対する「ｂｕｎｄｌｅＩｄ」開始イベントを提出することにより、アプリケーション呼び出しについてサンプリングデーモン３１＿１０２に通知し得る。一部の実装では、アプリケーションマネジャ３１＿１０６は、プッシュ通知、ユーザ呼び出し、又は予測された若しくは予想されたユーザアプリケーション呼び出しに応じて、アプリケーション起動が開始されたことをサンプリングデーモン３１＿１０２に示し得る。アプリケーションが終了すると、アプリケーションマネジャ３１＿１０６は、アプリケーションの名称又は識別子を指定する、アプリケーションに対する「ｂｕｎｄｌｅＩｄ」停止イベントを提出することにより、アプリケーションが実行されていないことについてサンプリングデーモン３１＿１０２に通知し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、アプリケーション開始及び停止イベント（例えば、「ｂｕｎｄｌｅＩｄ」属性イベント）を使用し、アプリケーション毎の使用時間の履歴を生成し得る。例えば、アプリケーション毎の使用時間の履歴は、アプリケーションの各実行に対する、アプリケーションの最後の実行から経過した時間量及び実行時間を含み得る。サンプリングデーモン３１＿１０２は、ユーザ呼び出しによるアプリケーション起動及び／又はシステムにより起動された（例えば、自動的に起動された）アプリケーションの別個の履歴を維持し得る。従って、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００上で実行された全てのアプリケーションに対する使用統計を維持し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、電力モニタプロセス３１＿１０８からパワーイベントを受信し得る。例えば、電力モニタ３１＿１０９は、モバイルデバイス３１＿１００に対するバッテリ容量、放電量、使用量、及び充電特性を監視し得る。電力モニタ３１＿１０９は、いつモバイルデバイス３１＿１００が外部電源に接続されたか、及び、モバイルデバイス３１＿１００がバッテリ電力となったかを判定し得る。電力モニタ３１＿１０９は、いつモバイルデバイス３１＿１００が外部電源に接続されるかを、サンプリングデーモン３１＿１０２に通知し得る。例えば、モバイルデバイス３１＿１００が外部電源に接続されたことを電力モニタが検出すると、電力モニタ３１＿１０９は、「ｃａｂｌｅＰｌｕｇｉｎ」イベントを、１（例えば、真）の「ｃａｂｌｅＰｌｕｇｉｎ」属性値と共に、サンプリングデーモン３１＿１０２に送信し得る。このイベントは、外部電源が接続された時点のバッテリ充電量を含み得る。電力モニタ３１＿１０９は、「ｅｎｅｒｇｙ」属性イベントをサンプリングデーモン３１＿１０２に送信して、バッテリ使用量を報告し得る。

一部の実装では、電力モニタ３１＿１０９は、モバイルデバイス３１＿１００が外部電源から遮断されたことを、サンプリングデーモン３１＿１０２に通知し得る。例えば、モバイルデバイス３１＿１００が外部電源から遮断されたことを電力モニタが検出すると、電力モニタ３１＿１０９は、「ｃａｂｌｅＰｌｕｇｉｎ」イベントを、０（例えば、偽）の「ｃａｂｌｅＰｌｕｇｉｎ」属性値と共に、サンプリングデーモン３１＿１０２に送信し得る。このメッセージは、外部電源が遮断された時点のバッテリ充電量を含み得る。従って、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００のバッテリの充電分布（例えば、経時的充電）を説明する統計を維持し得る。この充電分布統計は、最後の充電からの時間量（例えば、外部電源に接続してからの時間）及び充電に起因するバッテリ充電における変化（例えば、充電の開始レベル、充電の終了レベル）を含み得る。

一部の実装では、電力モニタ３１＿１０９は、１日を通してのバッテリ充電における変化をサンプリングデーモン３１＿１０２に通知し得る。例えば、電力モニタ３１＿１０９は、アプリケーションがいつ開始及び停止すると、通知され、この通知に応じて、その時間に放電したバッテリ電力量及びバッテリ内の残りの充電量を判定し、この情報をサンプリングデーモン３１＿１０２に送信し得る。例えば、電力モニタ３１＿１０９は、「ｓｙｓｔｅｍ．ｅｎｅｒｇｙ」イベントをサンプリングデーモン３１＿１０２に送信し、アプリケーションがアクティブであった期間中に消費したエネルギ量を示し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、デバイス温度統計を熱デーモン３１＿１１０から受信し得る。例えば、熱デーモン３１＿１１０は、モバイルデバイス３１＿１００の作動温度条件を、１つ以上の温度センサを使用して監視し得る。熱デーモン３１＿１１０は、温度変化をサンプリングデーモン３１＿１０２に定期的に報告するよう構成され得る。例えば、熱デーモン３１＿１１０は、モバイルデバイス３１＿１００の作動温度を５秒毎に判定し、モバイルデバイス３１＿１００の温度又は熱レベルをサンプリングデーモン３１＿１０２に報告し得る。例えば、熱デーモン３１＿１１０は、「ｓｙｓｔｅｍ．ｔｈｅｒｍａｌＬｅｖｅｌ」イベントをサンプリングデーモン３１＿１０２に送信し、モバイルデバイス３１＿１００の現在の作動温度又は熱レベルを報告し得る。サンプリングデーモン３１＿１０２は、報告された温度をイベントデータストア３１＿１０４に記憶し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、デバイス設定統計をデバイス設定プロセス３１＿１１２から受信し得る。例えば、デバイス設定プロセス３１＿１１２は、モバイルデバイス３１＿１００のオペレーティングシステムの機能又はプロセスであり得る。デバイス設定プロセス３１＿１１２は、例えば、ユーザ入力を受信し、例えば飛行機モードのオン／オフ、Ｗｉ－Ｆｉのオン／オフ、ローミングのオン／オフなどの、様々なデバイス設定を調整し得る。デバイス設定プロセス３１＿１１２は、デバイス設定に対する変更をサンプリングデーモン３１＿１０２に報告し得る。各デバイス設定は、対応する所定のイベント属性を有し得る。例えば、デバイス設定プロセス３１＿１１２は、ユーザがモバイルデバイス３１＿１００上で飛行機モードをオン又はオフにすると、「ｓｙｓｔｅｍ．ａｉｒｐｌａｎｅＭｏｄｅ」イベントをサンプリングデーモン３１＿１０２に送信し得る。サンプリングデーモン３１＿１０２は、受信したイベント及び属性値に基づく、デバイス設定に対する統計を生成し、記憶し得る。例えば、設定が有効（又は、無効）になる度に、サンプリングデーモン３１＿１０２は、設定が以前に有効になってから経過した時間量及び設定が有効となっていた時間量（例えば、期間）を示すデータを記憶し得る。

同様に、一部の実装では、サンプリングデーモン３１＿１０２は、他のイベントが発生すると、他のモバイルデバイス３１＿１００構成要素（例えば、デバイスセンサ３１＿１１４）から通知を受信し得る。例えば、サンプリングデーモン３１＿１０２は、モバイルデバイスのスクリーンがオン又はオフにされると（例えば、「ｓｙｓｔｅｍ．ｂａｃｋｌｉｇｈｔ」イベント）、モバイルデバイス３１＿１００がユーザの顔の横に保持されると（例えば、「ｓｙｓｔｅｍ．ｐｒｏｘｉｍｉｔｙ」イベント）、セルタワーハンドオフが検出されると、ベースバンドプロセッサが検索モードになると（例えば、「ｓｙｓｔｅｍ．ｂｔｌｅｓｃａｎ」イベント）、及び、ユーザが歩行中である、ランニング中である、及び／又は運転中であることをモバイルデバイス３１＿１００が検出すると（例えば、「ｓｙｓｔｅｍ．ｍｏｔｉｏｎＳｔａｔｅ」イベント）、通知を受信し得る。各場合では、サンプリングデーモン３１＿１０２は、イベントの開始及び終了時に通知を受信し得る。各場合では、サンプリングデーモン３１＿１０２は、イベントが最後に検出されてから経過した時間量及びイベントの期間を示す統計を生成し、記憶し得る。サンプリングデーモン３１＿１０２は、特定の使用ケース及びシナリオに関して以下に詳述するように、他のイベント通知を受信し、他の統計を生成し得る。
アプリケーションイベント

一部の実装では、サンプリングデーモン３１＿１０２は、イベント情報をモバイルデバイス３１＿１００上のアプリケーションから受信し得る。例えば、モバイルデバイス３１＿１００上のアプリケーションは、サンプリングデーモン３１＿１０２に対して、所定の又は動的に定義された属性を含むイベントを生成し、様々なアプリケーション特有イベントを追跡し得る。例えば、サンプリングデーモン３１＿１０２は、カレンダーアプリケーション３１＿１１６から（例えば、「ｃａｌｅｎｄａｒ．ａｐｐｏｉｎｔｍｅｎｔ」、「ｃａｌｅｎｄａｒ．ｍｅｅｔｉｎｇ」、又は「ｃａｌｅｎｄａｒ．ｒｅｍｉｎｄｅｒ」属性などを含む）カレンダーイベントを受信し得る。カレンダーイベントは、様々なカレンダーイベント又は機能に関連付けられた位置、時間、又は他のデータを指定する値を有する「ｃａｌｅｎｄａｒ．ａｐｐｏｉｎｔｍｅｎｔ」、「ｃａｌｅｎｄａｒ．ｍｅｅｔｉｎｇ」、又は「ｃａｌｅｎｄａｒ．ｒｅｍｉｎｄｅｒ」属性を含み得る。サンプリングデーモン３１＿１０２は、例えば、属性名、及び、属性が発生するようスケジュールされた属性期間並びに／又は時間を記憶し得る。一部の実装では、サンプリングデーモン３１＿１０２は、クロックアプリケーション３１＿１１８から（例えば、「ｃｌｏｃｋ．ａｌａｒｍ」属性を含む）クロックイベントを受信し得る。例えば、サンプリングデーモン３１＿１０２は、属性名（例えば、「ｃｌｏｃｋ．ａｌａｒｍ」）及びアラームが発生するようスケジュールされた時間を示す値を記憶し得る。サンプリングデーモン３１＿１０２は、以下に詳述するように、他のアプリケーション（例えば、メディアアプリケーション、パスブックアプリケーションなど）からイベント情報を受信し得る。
アプリケーション統計

一部の実装では、サンプリングデーモン３１＿１０２は、アプリケーション起動イベントにわたるアプリケーション統計を収集し得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーションの多くの呼び出しにわたる、各アプリケーションに対する統計（例えば、イベント、「ｂｕｎｄｌｅＩｄ」属性値）を収集し得る。例えば、各アプリケーションは、異なるバージョンの同じアプリケーションが、別個のアプリケーションとして処理され得るよう、その実行可能なファイルシステムパスのハッシュ及び実行可能なコンテンツのハッシュにて特定され得る。アプリケーションハッシュ値は、サンプリングデーモン３１＿１０２に、「ｂｕｎｄｌｅＩｄ」イベントにて、例えば、「ｂｕｎｄｌｅＩｄ」属性に対する値として、提出され得る。

一部の実装では、サンプリングデーモン３１＿１０２は、各アプリケーションに対するバックグラウンドタスク補完アサーションイベントを追跡するカウンタを維持し得る。例えば、アプリケーションがバックグラウンドタスクとして実行される度に（例えば、フォアグランドでは見ることができない、及び／又は、ユーザにより現在使用中でない）、アプリケーション又はアプリケーションマネジャ３１＿１０６は、アプリケーションが終了されたこと又はサスペンドされたことをサンプリングデーモン３１＿１０２に通知し得、サンプリングデーモン３１＿１０２はカウンタをインクリメントし得る。サンプリングデーモン３１＿１０２は、アプリケーションがバックグラウンドで実行されているアプリケーション起動にわたる累積秒数を追跡するカウンタを維持し得る。例えば、サンプリングデーモン３１＿１０２は、「ｂｕｎｄｌｅＩｄ」開始及び停止イベントを分析し、アプリケーションがいつ開始及び停止されたか判定し、開始及び停止イベントのタイムスタンプを使用し、アプリケーションがどれほど長く実行されたかを判定し得る。一部の実装では、サンプリングデーモン３１＿１０２は、データ接続数をカウントする、ネットワークデータトラフィック量を追跡（例えば、バイトにて）する、ファイルシステム動作の期間及びサイズを追跡する、及び／又は、各アプリケーションに関連付けられたスレッド数を追跡する、別個のカウンタを維持し得る。サンプリングデーモン３１＿１０２は、例えば、アプリケーション起動にわたってアプリケーションがアクティブのままである累積時間量のカウントを維持し得る。サンプリングデーモン３１＿１０２により受信され、イベントデータストア３１＿１０４に記憶されたイベント並びに属性データに基づいて、サンプリングデーモン３１＿１０２により生成され得るアプリケーション統計の種類の、ごく少数の実施例がある。他の統計は、以下に詳述するように生成又は収集され得る。
ヒューリスティック

一部の実装では、モバイルデバイス３１＿１００は、サンプリングデーモン３１＿１０２により検出されたイベントに基づいて、デバイス構成要素の設定を調整し得る、ヒューリスティックプロセスと共に構成され得る。例えば、ヒューリスティックプロセス３１＿１２０は、１つ以上のトリガーイベントに応じて及び／又はサンプリングデーモン３１＿１０２により収集又は生成された統計に基づいて、様々なシステム設定（例えば、ＣＰＵ電力、ベースバンドプロセッサ電力、ディスプレイ照明など）を調整するよう構成された（例えば、プログラムされた）１つ以上のプロセスを含み得る。

一部の実装では、ヒューリスティックプロセス３１＿１２０は、所定の基準のセットが満たされると（例えば、一部のトリガーイベントの発生）呼び出される又はアクティブにされるよう、サンプリングデーモン３１＿１０２に登録し得る。トリガーイベントは、メディアプレーヤアプリケーション（例えば、「ｂｕｎｄｌｅＩｄ」イベント）の呼び出し、又は、ユーザが歩き出した、走り出した、運転を始めたなど（例えば、「ｍｏｔｉｏｎＳｔａｔｅ」イベント）を検出することを含んでよい。トリガーイベントは一般化され、一部のプロパティ、データ、統計、イベント、属性、属性値などがイベントデータ３１＿１０４にて又はサンプリングデーモン３１＿１０２により検出されると、ヒューリスティックプロセス３１＿１２０を呼び出し得る。例えば、ヒューリスティックプロセス３１＿１２０は、サンプリングデーモン３１＿１０２が、アプリケーション開始通知（例えば、特定のアプリケーションを指定する「ｂｕｎｄｌｅＩｄ」開始イベント）又は特定の閾値を超える温度（例えば、「ｔｈｅｒｍａｌＬｅｖｅｌ」イベント）を受信すると呼び出され得る。ヒューリスティックプロセス３１＿１２０は、サンプリングデーモン３１＿１０２が、指定された属性又は属性値に関連付けられたイベントを受信すると呼び出され得る。ヒューリスティックプロセス３１＿１２０は、単一のイベントが発生する又は統計が認められると呼び出されるよう登録し得る。ヒューリスティックプロセス３１＿１２０は、イベント、データ、属性、属性値、及び／又は統計の組み合わせが認められる又は検出されると呼び出されるよう登録し得る。ヒューリスティックプロセス３１＿１２０は、特定のユーザ入力（例えば、「ａｉｒｐｌａｎｅＭｏｄｅ」イベント、「ｓｌｅｅｐＷａｋｅ」イベントなど）に応じてトリガーされ得る又は呼び出され得る。ヒューリスティックプロセス３１＿１２０が登録したイベントをサンプリングプロセス３１＿１０２が検出すると、サンプリングプロセス３１＿１０２は、ヒューリスティックプロセス３１＿１２０を呼び出し得る。

一部の実装では、ヒューリスティックプロセス３１＿１２０が呼び出されると、ヒューリスティックプロセス３１＿１２０はサンプリングデーモン３１＿１０２と通信し、イベントデータストア３１＿１０４からイベントデータを取り出し得る。ヒューリスティックプロセス３１＿１２０は、イベントデータ、及び／又は、ヒューリスティックプロセス３１＿１２０自体が収集した他のデータを処理し、システム設定をどのように調整するか判定し、モバイルデバイス３１＿１００のパフォーマンスを改善し、モバイルデバイス３１＿１００を使用しているユーザのエクスペリエンスを改善し、及び／又はモバイルデバイス３１＿１００の将来の問題を防ぎ得る。

一部の実装では、ヒューリスティックプロセス３１＿１２０は、モバイルデバイス３１＿１００の様々なデバイス構成要素３１＿１２２の設定における変化を引き起こし得る、設定推奨を実行し得る。例えば、デバイス構成要素は、ＣＰＵ、ＧＰＵ、ベースバンドプロセッサ、ディスプレイ、ＧＰＳ、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉ、振動モータ、及び他の構成要素を含み得る。

一部の実装では、ヒューリスティックプロセス３１＿１２０は、制御マルチプレクサ３１＿１２４に対する設定推奨を実行し得る。例えば、制御マルチプレクサ３１＿１２４は、ヒューリスティックプロセス３１＿１２０により提供された構成要素設定と、モバイルデバイス３１＿１００の構成要素の設定に影響を与える又は変更する、モバイルデバイス３１＿１００の他のプロセス並びに／又は機能と、の間を仲裁するプロセスであり得る。例えば、熱デーモン３１＿１１０は、モバイルデバイス３１＿１００が熱イベント中である（例えば、閾値温度を超える）ことを検出することに基づいて、ＣＰＵ電力、ディスプレイの輝度、ベースバンドプロセッサ電力、及び他の構成要素設定を調整するよう構成されたヒューリスティックプロセスであり得る。しかし、ヒューリスティックプロセス３１＿１２０は、ＣＰＵ電力、ディスプレイの輝度、ベースバンドプロセッサ電力、及び他の構成要素設定を同様に調整するよう構成され得る。従って、一部の実装では、ヒューリスティックプロセス３１＿１２０及び熱デーモン３１＿１１０は、制御マルチプレクサ３１＿１２４に対する設定調整推奨を実行し得、制御マルチプレクサ３１＿１２４は、どの設定調整を実行するか判定し得る。例えば、制御マルチプレクサ３１＿１２４は、プロセスに優先度を付け、その推奨プロセスの優先度に基づいて調整を実行し得る。従って、熱デーモン３１＿１１０が、ヒューリスティックプロセス３１＿１２０よりも優先度の高いプロセスである場合、制御マルチプレクサ３１＿１２４は、ヒューリスティックプロセス３１＿１２０の代わりに、熱デーモン３１＿１１０の推奨に従って、ＣＰＵ、ディスプレイ、ベースバンドプロセッサなどの設定を調整し得る。

一部の実装では、モバイルデバイス３１＿１００は、複数のヒューリスティックプロセス３１＿１２０と共に構成され得る。ヒューリスティックプロセス３１＿１２０は、無線経由で構成又は再構成され得る。例えば、各ヒューリスティックプロセス３１＿１２０のパラメータ（例えば、トリガー、閾値、基準、及び出力）は、ネットワーク（例えば、セルラーデータ接続、Ｗｉ－Ｆｉ接続など）経由で設定又は調整され得る。一部の実装では、新たなヒューリスティックプロセス３１＿１２０がモバイルデバイス３１＿１００に追加され得る。例えば、トリガーイベント、統計データ、及びデバイス設定との間の経時的新たな相互関係は、システムデベロッパにより決定され得る。これらの新たな相互関係が特定されるに従い、新たなヒューリスティックプロセス３１＿１２０が開発され、システム設定が調整され、新たに判定される関係が考慮され得る。一部の実装では、新たなヒューリスティックプロセス３１＿１２０は、ネットワーク経由でモバイルデバイス３１＿１００に追加され得る。例えば、新たなヒューリスティックプロセス３１＿１２０は、無線（例えば、セルラーデータ接続、Ｗｉ－Ｆｉ接続など）を経由してモバイルデバイス３１＿１００にダウンロード又はインストールされ得る。
ヒューリスティックプロセス例

一部の実装では、ヒューリスティックプロセス３１＿１２０は、モバイルデバイス３１＿１００のシステム設定を調整し、モバイルデバイス３１＿１００がユーザのポケット内にあるときに熱くなり過ぎないよう構成され得る。例えば、このホットインポケットヒューリスティックプロセスは、モバイルデバイスのディスプレイがオフであり（例えば、「ｓｙｓｔｅｍ．ｂａｃｋｌｉｇｈｔ」イベントが、０／偽の属性値を有する）、モバイルデバイス３１＿１００がいずれのエンタテインメントメディア（例えば、音楽、映画、動画など）を再生していない時に呼び出されるよう、サンプリングデーモン３１＿１０２に登録するよう構成され得る。呼び出されると、ホットインポケットヒューリスティックは、例えば、ＣＰＵ電力及びＧＰＵ電力を減らし、モバイルデバイス３１＿１００の作動温度を下げるよう推奨を実行し得る。

一部の実装では、ヒューリスティックプロセス３１＿１２０は、モバイルデバイスのディスプレイが使用されていない（例えば、「ｓｙｓｔｅｍ．ｂａｃｋｌｉｇｈｔ」イベントが、０／偽の属性値を有する）際に位置精度を調整するよう構成され得る。例えば、モバイルデバイスのディスプレイが使用されていない（例えば、上述する「ｂａｃｋｌｉｇｈｔ」属性イベントにより示されるように、ディスプレイがオフである）場合、モバイルデバイス３１＿１００は地図情報又は道順をユーザに表示できない。従って、ユーザがモバイルデバイス３１＿１００の位置サービスを使用する可能性は低く、位置サービス（例えば、ＧＰＳ位置、Ｗｉ－Ｆｉ位置、セルラー位置など）は少ない電力を使用して調整され得る。位置精度ヒューリスティックプロセスは、モバイルデバイスのディスプレイがオフの際に呼び出されるよう、サンプリングデーモン３１＿１０２に登録し得る。ヒューリスティックプロセスは、呼び出されると、モバイルデバイス３１＿１００のエネルギリソースを節約するために、ＧＰＳプロセッサ、Ｗｉ－Ｆｉトランスミッタ、セルラートランスミッタ、及びベースバンドプロセッサの電力レベルを調整し得る、又は、モバイルデバイス３１＿１００の位置を判定するために使用されたプロセスを終了し得る。

一部の実装では、ヒューリスティックプロセス３１＿１２０は、ユーザの行動に応じて、モバイルデバイスの環境光センサの設定を調整するよう構成され得る。例えば、このユーザ適応環境光センサ（ＡＬＳ）ヒューリスティックプロセスは、サンプリングデーモン３１＿１０２が、モバイルデバイス３１＿１００周囲の環境光における変化を環境光センサが検出した、ディスプレイの輝度を環境光センサシステムが調整した、及び／又は、ディスプレイの輝度を調整する入力をユーザが提供したことを示すデータ（例えば、「ＡＬＳ」属性イベント）を受信すると、サンプリングデーモン３１＿１０２により呼び出され得る。

ユーザ適応ＡＬＳヒューリスティックは、呼び出されると、サンプリングデーモン３１＿１０２からの、ＡＬＳディスプレイ調整及びユーザ開始ディスプレイ調整に関する追加情報を要求し、ＡＬＳがいつ、ディスプレイの輝度を上下に調整し、そしてユーザがディスプレイの輝度を逆方向に調整したか（例えば、「ｓｙｓｔｅｍ．ＡＬＳ」イベントの後に「ｓｙｓｔｅｍ．ｂａｃｋｌｉｇｈｔ」イベントが続く）を示すユーザ入力のパターンがあるか判定し得る。例えば、ユーザは、バス又は電車に乗って職場に向かう場合がある。乗車中は、バスの照明がオン及びオフとなっている場合がある。環境光センサは、環境光の変化を検出し、照明点灯時にはディスプレイの輝度を上げ得る。照明は一時的にのみ点灯するため、ユーザは、照明が再度消灯時には、ディスプレイの輝度を下げてよい。ユーザ入力のこのパターンは追跡され（例えば、「ｂａｃｋｌｉｇｈｔ」属性イベントを通して）、時刻、カレンダー若しくはアラームイベントエントリ、又は移動パターンに、ヒューリスティックプロセスにより相互関係し、どのような状況又はコンテキストの下で、ＡＬＳディスプレイ調整に応じて、ディスプレイの輝度をユーザは調整するかを判定し得る。ユーザ適応ＡＬＳヒューリスティックプロセスが入力のパターン及びコンテキストを判定すると、ヒューリスティックプロセスは、ＡＬＳの設定を、より強く又はより弱く調整し得る。例えば、ＡＬＳは、判定された時刻、カレンダー若しくはアラームエントリ、又は移動パターン中に、環境光のレベルを、より多くの又はより少ない頻繁にてチェックし、これに従ってディスプレイの輝度を調整するよう調整され得る。

上記のヒューリスティックプロセスはヒューリスティックプロセスの数少ない実施例であり、これらがどのようにシステム内に実装されてよいかを本セクションにて説明する。他のヒューリスティックプロセスの経時的に開発されると、これらが実装され、システムに追加され得る。例えば、追加ヒューリスティックプロセスは、モバイルデバイス上で発生し、検出された、温度測定値に関連するイベント若しくはイベントのパターン、ユーザ入力、クロックイベント（例えば、アラーム）、カレンダーイベント、及び／又は他のイベントを検出したことに応じて、モバイルデバイスのＣＰＵ、ＧＰＵ、ベースバンドプロセッサ、又は他の構成要素を調整するよう構成又はプログラムされ得る。
ヒューリスティック登録及び呼び出しプロセス例

図３１－２は、ヒューリスティックプロセスを呼び出すためのプロセス例３１＿２００を示す。ステップ３１＿２０２にて、サンプリングデーモン３１＿１０２が初期化され得る。例えば、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００の起動中に初期化され得る。

ステップ３１＿２０４にて、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００上に構成されたヒューリスティックプロセスを、サンプリングデーモン３１＿１０２の初期化中に呼び出し得る。例えば、サンプリングデーモン３１＿１０２は、各ヒューリスティックプロセス３１＿１２０にモバイルデバイス３１＿１００上で実行させ、それらの初期化サブルーチンを実行させ得る。

ステップ３１＿２０６にて、サンプリングデーモン３１＿１０２は、各ヒューリスティックプロセス３１＿１２０からイベント登録メッセージを受信し得る。例えば、ヒューリスティックプロセス３１＿１２０の初期化サブルーチン中、ヒューリスティックプロセス３１＿１２０は、どの属性イベントが、ヒューリスティックプロセス３１＿１２０の呼び出しをトリガーすべきかを示す情報をサンプリングデーモン３１＿１０２に送信し得る。サンプリングデーモン３１＿１０２は、登録情報をデータベース、例えば、イベントデータストア３１＿１０４などに記憶し得る。登録情報は、ヒューリスティックプロセスの識別（例えば、実行可能名、ファイルシステムパスなど）及びイベント基準（属性の識別、属性値、閾値、範囲など）を含み得、指定イベントが検出されると、サンプリングデーモン３１＿１０２がヒューリスティックプロセス３１＿１２０を呼び出し得るようにする。

ステップ３１＿２０８にて、サンプリングデーモン３１＿１０２は、属性イベントデータを受信し得る。例えば、サンプリングデーモン３１＿１０２は、上述するように、アプリケーションマネジャ３１＿１０６、センサ３１＿１１４、カレンダー３１＿１１６、及びクロック３１＿１１８を含む様々なシステム構成要素から、属性イベントデータを受信し得る。

ステップ３１＿２１０にて、サンプリングデーモン３１＿１０２は、受信した属性イベントデータをヒューリスティック登録データと比較し得る。例えば、属性イベントデータがサンプリングデーモン３１＿１０２に報告されると、サンプリングデーモン３１＿１０２は、イベントデータ（例えば、属性値）、又はイベントデータから生成された統計を、ヒューリスティックプロセス３１＿１２０から受信した登録情報と比較し得る。

ステップ３１＿２１２にて、サンプリングデーモン３１＿１０２は、ステップ３１＿２１０にて実行された比較に基づいて、ヒューリスティックプロセスを呼び出し得る。例えば、イベントデータ（例えば、属性データ）及び／又は統計が、ヒューリスティックプロセス３１＿１２０に対するヒューリスティック登録データに指定された基準を満たす場合、続いてサンプリングデーモン３１＿１０２が、ヒューリスティックプロセス３１＿１２０を呼び出し得る。例えば、イベントデータ及び／又は統計データが、登録中にヒューリスティックプロセスによりイベントに対して指定された閾値をいくらか超える場合、続いてヒューリスティックプロセスが、サンプリングデーモン３１＿１０２により呼び出され得る。あるいは、特定の属性イベントの単なる発生が、ヒューリスティックプロセス３１＿１２０を呼び出しさせ得る。

図３１－３は、モバイルデバイス３１＿１００の設定を、ヒューリスティックプロセス３１＿１２０を使用して調整するためのプロセス３１＿３００を示す。ステップ３１＿３０２にて、ヒューリスティックプロセス３１＿１２０が初期化される。例えば、ヒューリスティックプロセス３１＿１２０はサンプリングデーモン３１＿１０２により呼び出され得、ヒューリスティックプロセス３１＿１２０が、その初期化サブルーチンを実行し得るようにする。例えば、呼び出しはパラメータ化され、ヒューリスティックプロセス３１＿１２０が、この呼び出し中にその初期化サブルーチンを実行すべきであることを示し得る。

ステップ３１＿３０４にて、ヒューリスティックプロセス３１＿１２０は、システムイベントに対して、サンプリングデーモン３１＿１０２に登録し得る。例えば、初期化中、ヒューリスティックプロセス３１＿１２０は、ヒューリスティックプロセス３１＿１２０を呼び出すためのイベントの識別、閾値、属性、属性値、又は他の基準を含むメッセージをサンプリングデーモン３１＿１０２に送信し得る。イベントが発生する及び／又は基準が満たされると、サンプリングデーモン３１＿１０２は、ヒューリスティックプロセス３１＿１２０を呼び出し得る。

ステップ３１＿３０６にて、ヒューリスティックプロセス３１＿１２０はシャットダウン又は終了し得る。例えば、ヒューリスティックプロセス３１＿１２０は、ヒューリスティックプロセス３１＿１２０に対する登録基準が満たされるまでは、システムにより必要とされない。従って、デバイスリソース（例えば、バッテリ電力、プロセッシング電力など）を節約するため、ヒューリスティックプロセス３１＿１２０は、必要とされるまで終了される、シャットダウンされる、又はサスペンドされる（例えば、サンプリングデーモン３１＿１０２によりトリガーされる）。

ステップ３１＿３０８にて、ヒューリスティックプロセス３１＿１２０が再開始され得る。例えば、サンプリングデーモン３１＿１０２が、登録メッセージ内のヒューリスティックプロセス３１＿１２０により指定された基準が満たされることを判定すると、サンプリングデーモン３１＿１０２は、ヒューリスティックプロセス３１＿１２０を呼び出し得る。

ステップ３１＿３１０にて、ヒューリスティックプロセス３１＿１２０は、サンプリングデーモン３１＿１０２からイベントデータを取得し得る。例えば、ヒューリスティックプロセス３１＿１２０は、再開始されると、サンプリングデーモン３１＿１０２に、追加属性イベントデータについて問い合わせ得る。ヒューリスティックプロセス３１＿１２０は、他のシステムリソース、プロセス、センサなどと相互作用し、必要に応じてデータを収集するよう構成され得る。

ステップ３１＿３１２にて、ヒューリスティックプロセス３１＿１２０は、イベントデータを処理し、構成要素設定を判定し得る。例えば、ヒューリスティックプロセス３１＿１２０は、サンプリングデーモン３１＿１０２からのイベントデータ及び／又は統計、並びに／若しくは、システムの他の構成要素から収集されたデータを使用し、モバイルデバイス３１＿１００の様々な構成要素の設定をどのように調整するか判定し得る。例えば、モバイルデバイス３１＿１００が熱すぎるとヒューリスティックプロセス３１＿１２０が判定する場合、ヒューリスティックプロセス３１＿１２０は、モバイルデバイス３１＿１００のどの電力設定がモバイルデバイス３１＿１００の作動温度を下げるかを判定し得る。

ステップ３１＿３１４にて、ヒューリスティックプロセス３１＿１２０は、判定した構成要素設定を制御マルチプレクサ３１＿１２４に送信し得る。例えば、制御マルチプレクサ３１＿１２４は、ヒューリスティックプロセス３１＿１２０から受信したデバイス設定推奨及び他のシステム構成要素（例えば、熱デーモン３１＿１１０）を仲裁し得る。制御マルチプレクサ３１＿１２４は続いて、受信した設定推奨に従って、モバイルデバイス３１＿１００の様々な構成要素（例えば、ＣＰＵ、ＧＰＵ、ベースバンドプロセッサ、ディスプレイなど）を調整し得る。
イベントの予想

一部の実装では、イベントデータストア３１＿１０４（例えば、過去データ）に記憶された属性イベントデータは、サンプリングデーモン３１＿１０２により使用され、将来のイベントの発生が予測され得る。例えば、「ｂｕｎｄｌｅＩｄ」属性イベントが分析され、ユーザがアプリケーション（例えば、任意のアプリケーション又は特定のアプリケーション）をいつ呼び出すかが予測され得る。特定の電子メールフォルダを指定する「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」イベント（例えば、「ｗｏｒｋ」フォルダに設定された「ｍａｉｌｂｏｘ」属性値）が分析され、「ｍａｉｌａｐｐ」アプリケーションの特定の電子メールフォルダをユーザがいつ使用するかが予測され得る。
イベント履歴ウィンドウ指定

一部の実装では、イベント予想は、イベント履歴ウィンドウ指定に基づいて生成され得る。例えば、ウィンドウ指定はクライアントにより生成され、クライアントによるイベント予想の基礎となる対象期間又は再現対象期間を指定し得る。ウィンドウ指定は、４つの構成要素、すなわち、開始時間、終了時間、再現幅、及び再現頻度、を含み得る。開始時間は、ウィンドウを開始すべき、履歴での日付及び／又は時間を示し得る。終了時間は、ウィンドウを終了すべき、履歴での日付及び／又は時間を示し得る。再現幅は、クライアントが対象とする時間のブロック（例えば、開始時間にて始まる４時間）を示し得る。再現頻度は、開始時間にて始まる時間のブロックが、どれほどの頻度で繰り返されるべきかを示し得る（例えば、毎８時間、毎２日間、毎週、毎２週など）。

一部の実装では、指定された時間のブロック（例えば、対象期間）内に発生するイベントのみが、イベント予想の生成時に分析される。例えば、現在の日付が２０１４年５月１３日の場合、ウィンドウ指定は、２０１４年５月１１日午後１２：００の開始日、５月１２日午後１２時の終了日、１時間の再現幅、及び４時間の再現頻度を指定し得る。このウィンドウ指定は、開始が２０１４年５月１１日午後１２：００で、終了が２０１４年５月１２日午後１２：００の毎４時間に発生する各１時間ブロック（例えば、対象期間）内のイベントデータを、サンプリングデーモン３１＿１０２に分析させる（例えば、ブロック１：２０１４年５月１１日午後１２：００～１：００、ブロック２：２０１４年５月１１日午後４：００～５：００、ブロック３：２０１４年５月１１日午後８：００～９：００など）。一部の実装では、再現幅が指定されない場合、開始時間から終了時間までの全体期間が分析され、イベントが予想される。

一部の実装では、サンプリングデーモン３１＿１０２は、イベント履歴ウィンドウ指定を自動的に生成し得る。例えば、サンプリングデーモン３１＿１０２は、イベントデータストア３１＿１０４に記憶されたイベント履歴データ内のパターンを特定し得る。クライアントが「ｂｕｎｄｌｅＩｄ」イベントの予測を要求するものの、ウィンドウ指定を提供しない場合、サンプリングデーモン３１＿１０２は、例えば、アプリケーションが通常ユーザにより、午前８：００～９：００、午前１１：３０～午後１：３０、及び午後７：００～１１：００に呼び出されることを示す、「ｂｕｎｄｌｅＩｄ」属性／イベントのパターンを特定し得る。サンプリングデーモン３１＿１０２は、それらの期間を含むウィンドウ指定を自動的に生成し、他の時刻を除外し、要求された予想が、要求された属性に関連する期間に集中するようにし得る。同様に、サンプリングデーモン３１＿１０２は、特定の（例えば、指定した）属性値に対するイベント履歴ウィンドウ指定を自動的に生成し得る。例えば、「ｍａｉｌａｐｐ」の属性値を有する「ｂｕｎｄｌｅＩｄ」イベントの予測をクライアントが要求する場合、続いてサンプリングデーモン３１＿１０２は、イベント履歴データを分析し、「ｍａｉｌａｐｐ」値に関連する発生パターンを特定し得る。「ｍａｉｌａｐｐ」「ｂｕｎｄｌｅＩｄ」属性値がイベント履歴データ内に毎日、午前１０：００、午後１２：００、及び午後５：００に記録される場合、続いてサンプリングデーモン３１＿１０２は、それらの時刻前後の対象期間を指定するウィンドウ指定を生成し得る。
時間的予想

一部の実装では、属性又は属性値に対して時間的予想が生成され得る。時間的予想は、例えば、属性又は属性値に関連付けられたイベントが発生する可能性のある時刻を示し得る。例えば、サンプリングデーモン３１＿１０２のクライアントは、先週（例えば、過去７日間）にわたる、「ｂｕｎｄｌｅＩｄ」属性（例えば、アプリケーション起動）に対する時間的予想を要求し得る。予想を生成するため、１日の２４時間が、９６の１５分タイムスロットに分割され得る。過去７日間のそれぞれの特定のタイムスロット（例えば、午後１：００～１：１５）に対して、サンプリングデーモン３１＿１０２は、「ｂｕｎｄｌｅＩｄ」イベントが発生したかを判定し、そのタイムスロットに対するスコアを生成し得る。７日間の内の２日間内の特定のタイムスロット内で「ｂｕｎｄｌｅＩｄ」イベントが発生した場合、「ｂｕｎｄｌｅＩｄ」イベントが特定のタイムスロット（例えば、午後１：００～１：１５）内に発生する可能性（例えば、スコア）は０．２９（例えば、２÷７）である。７日間の内の４日間での異なるタイムスロット（例えば、午後１２：１５～１２：３０）内に「ｂｕｎｄｌｅＩｄ」イベントが発生した場合、「ｂｕｎｄｌｅＩｄ」イベントがそのタイムスロット内に発生する可能性（例えば、スコア）は０．５７（例えば、４÷７）である。

同様に、クライアントは、特定の属性値に対する時間的予想を要求し得る。例えば、「ｂｕｎｄｌｅＩｄ」属性（例えば、「ｂｕｎｄｌｅＩｄ」イベント）に対する時間的予想を要求することの代わりに、クライアントは、「ｂｕｎｄｌｅＩｄ」属性値が「ｍａｉｌａｐｐ」である「ｂｕｎｄｌｅＩｄ」イベントに対する時間的予想を要求し得る。従って、クライアントは、「ｍａｉｌａｐｐ」アプリケーションをユーザが呼び出す可能性のある時刻（例えば、１５分タイムスロット）のインジケーションを受信し得る。

一部の実装では、時間的予想は、イベント履歴ウィンドウ指定に基づいて生成され得る。例えば、クライアントが、４時間の対象期間を指定するウィンドウ指定を提供する場合、時間的予想は、その４時間の対象期間内の１５分タイムスロットに対する可能性スコアのみ生成する。例えば、対象期間が、過去３日間のそれぞれに対する午後１２：００～４：００に対応する場合、１６のタイムスロットが４時間の対象期間内に生成され、１６の１５分タイムスロットのそれぞれに対してスコアが生成される。指定された４時間の対象期間外のタイムスロットに対しては、スコアは生成されない。
ピア予想

一部の実装では、サンプリングデーモン３１＿１０２は、属性に対するピア予想を生成し得る。例えば、ピア予想は、同じ属性の全ての値（例えば、発生）に対して、対象期間中に発生する、属性に対する値の相対的可能性を示し得る。例えば、サンプリングデーモン３１＿１０２のクライアントは、要求と共に提出されたウィンドウ指定により指定される、対象期間（例えば、午前１１：００～午後１：００）にわたる、「ｂｕｎｄｌｅＩｄ」属性のピア予想を要求し得る。対象期間中、属性値「ｍａｉｌａｐｐ」、「ｃｏｎｔａｃｔｓ」、「ｃａｌｅｎｄａｒ」、「ｗｅｂｂｒｏｗｓｅｒ」、「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、及び「ｍａｉｌａｐｐ」を有する「ｂｕｎｄｌｅＩｄ」イベントが発生すると、「ｍａｉｌａｐｐ」の発生する相対的可能性（すなわち、スコア）は０．４３（例えば、３／７）であり、「ｗｅｂｂｒｏｗｓｅｒ」の発生する相対的可能性は０．２９（例えば、２／７）であり、及び、「ｃｏｎｔａｃｔｓ」又は「ｃａｌｅｎｄａｒ」の発生する相対的可能性は０．１４（例えば、１／７）である。

一部の実装では、サンプリングデーモン３１＿１０２のクライアントは、ある属性に対するピア予想を要求し得る。例えば、クライアントが、ある属性に対するピア予想を、その属性に対する値を指定することなくことの要求する場合、続いてサンプリングデーモン３１＿１０２は、ピア予想を生成し、対象期間内の、その属性の全ての値に対する様々な蓋然性スコアを返す。上記のピア予想例を使用して、サンプリングデーモン３１＿１０２は、属性値及びスコアのリストを、要求クライアントに返す。例えば、「ｍａｉｌａｐｐ」：０．４３、「ｗｅｂｂｒｏｗｓｅｒ」：０．２９、「ｃｏｎｔａｃｔｓ」：０．１４、「ｃａｌｅｎｄａｒ」：０．１４。

一部の実装では、サンプリングデーモン３１＿１０２のクライアントは、ある属性値に対するピア予想を要求し得る。例えば、クライアントは、「ｍａｉｌａｐｐ」の値を有する「ｂｕｎｄｌｅＩｄ」属性に対するピア予想を要求し得る。サンプリングデーモン３１＿１０２は、上述するように、クライアントにより提供されたウィンドウ指定に従って、「ｂｕｎｄｌｅＩｄ」属性に対するピア予想を生成し得る。例えば、サンプリングデーモン３１＿１０２は、「ｍａｉｌａｐｐ」の発生の相対的可能性（すなわち、スコア）を０．４３（例えば、３／７）、「ｗｅｂｂｒｏｗｓｅｒ」の発生の相対的可能性を０．２９（例えば、２／７）、及び、「ｃｏｎｔａｃｔｓ」又は「ｃａｌｅｎｄａｒ」の発生の相対的可能性を０．１４（例えば、１／７）と、計算し得る。サンプリングデーモン３１＿１０２は、要求された「ｍａｉｌａｐｐ」値に対するスコア（例えば、０．４３）をクライアントに返し得る。要求された値が、ウィンドウ指定により指定された対象期間内に再提示されない場合、続いて０の値がクライアントに返される。
パノラマ予想

一部の実装では、パノラマ予想が生成され、属性イベントの発生が予測され得る。例えば、上述する時間的及びピア予想は、単一の属性又は属性値に対するイベントの発生の相対頻度を使用し、その属性の将来の発生を予測する。この「頻度」予想タイプ（例えば、発生の頻度）は、予想要求に指定された属性又は属性値に関連付けられたデータのみを使用する。対照的に、「パノラマ」予想は、予想要求に指定された属性又は属性値に対して受信したイベントデータ内の他のデータ（例えば、位置データ、ビーコンデータ、ネットワーク品質など）を使用し得る。一部の実装では、パノラマ予想は、他の属性又は属性値に関連付けられたイベントからのデータを使用し得る。例えば、クライアントが、指定された属性又は属性値に対する時間的又はピア予想を要求し、また、予想タイプ（すなわち、予想フレーバ）がパノラマであることを指定すると、サンプリングデーモン３１＿１０２は、指定された属性又は属性値に対するイベントデータ及び他の属性及び属性値に対するイベントデータを分析し、指定されたイベントと、サンプリングデーモン３１＿１０２により受信された他のイベントとの間の相互関係を特定する。例えば、値「ｍａｉｌａｐｐ」を有する属性「ｂｕｎｄｌｅＩｄ」に対する頻度予想は、０．４のスコアを、午前９：００の１５分タイムスロットに指定してよい。しかし、パノラマ予想は、「ｍａｉｌａｐｐ」属性値とユーザの職場位置との間に強い相互関係があると判定してよい。例えば、パノラマ予想は、職場に関連付けられた位置にユーザが居るかを判定してよく、ｍａｉｌａｐｐが、午前９：００の１５分タイムスロット内の９０％の時間に呼び出される。従って、サンプリングデーモン３１＿１０２は、午前９：００の１５分タイムスロットに対する「ｍａｉｌａｐｐ」予想スコアに、より高いスコア（例えば、０．９）を指定し得る。

同様に、サンプリングデーモン３１＿１０２は、「ｍａｉｌａｐｐ」「ｂｕｎｄｌｅＩｄ」属性値と、「ｍｏｔｉｏｎＳｔａｔｅ」属性値「ｓｔａｔｉｏｎａｒｙ」に関連付けられたイベントの発生との間に、強い相互関係を見い出してよい。例えば、サンプリングデーモン３１＿１０２は、ｍａｉｌａｐｐアプリケーションの使用と、静止状態のモバイルデバイス３１＿１００との間の相互関係が９５％であることを判定し得る。サンプリングデーモン３１＿１０２は、ｍａｉｌａｐｐの使用と、動いているモバイルデバイス３１＿１００との間の相互関係が５％であることを判定し得る。従って、サンプリングデーモン３１＿１０２は、モバイルデバイスが動いている又は静止しているか否かに基づいて、特定のタイムスロットに対する「ｍａｉｌａｐｐ」属性値に対する予想スコア（例えば、０．９５又は０．０５）を調整し得る。
スコアボーディング－頻度対パノラマ

一部の実装では、サンプリングデーモン３１＿１０２は、どの予想タイプがイベントのよりよいプレディクタであるかを追跡し続け得る。例えば、サンプリングデーモン３１＿１０２が属性イベントを受信すると、サンプリングデーモン３１＿１０２は、受信したイベントに関連付けられた属性又は属性値に対する頻度及びパノラマ予想を生成し、どの予想タイプが、受信した属性イベントのよりよいプレディクタとなるかを判定し得る。言い換えると、サンプリングデーモン３１＿１０２は、属性イベントを受信する直前に予想が生成された場合でも、頻度予想タイプ又はパノラマ予想タイプが、受信した属性イベントのよりよいプレディクタとなるか否かを判定し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、各予想タイプ（例えば、既定、パノラマ）に対するスコアボードを維持し得る。例えば、頻度予想タイプが、受信したイベントに対するよりよいプレディクタとなると、サンプリングデーモン３１＿１０２が判定する度に、サンプリングデーモン３１＿１０２は、頻度予想タイプに対するスコア（例えば、カウンタ）をインクリメントし得る。パノラマ予想タイプが、受信したイベントに対するよりよいプレディクタとなると、サンプリングデーモン３１＿１０２が判定する度に、サンプリングデーモン３１＿１０２は、パノラマ予想タイプに対するスコア（例えば、カウンタ）をインクリメントし得る。

一部の実装では、サンプリングデーモン３１＿１０２は、各予想タイプ（例えば、頻度、パノラマ）に対して生成されたスコアに基づいて、既定予想タイプを判定し得る。例えば、スコアボーディングプロセスが、パノラマ予想タイプに対してより高いスコアを生成する場合、続いてパノラマが、既定予想タイプとして指定される。スコアボーディングプロセスが、頻度予想タイプに対してより高いスコア生成する場合、続いて頻度が、既定予想タイプとして指定される。クライアントが、ピア又は時間的予想を要求すると、クライアントは、予想タイプ（例えば、パノラマ、頻度、既定）を指定し得る。クライアントが予想タイプ指定しない場合、続いて既定予想タイプが使用され、ピア及び／又は時間的予想が生成される。
属性統計

一部の実装では、クライアントは、サンプリングデーモン３１＿１０２が、ある属性又は属性値に対する統計を生成することを要求し得る。例えば、予想の生成と同様に、クライアントは、ある属性又は属性値に対する統計が生成されるべき履歴ウィンドウを指定し得る。サンプリングデーモン３１＿１０２は、指定された属性又は属性値に対する統計を生成する際に、指定された履歴ウィンドウ内に発生する属性イベントを分析する。クライアント要求は、以降のどの統計がサンプリングデーモン３１＿１０２により生成されるべきかを指定し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、属性又は属性値に対する「ｃｏｕｎｔ」統計を生成し得る。例えば、「ｃｏｕｎｔ」統計は、指定された履歴ウィンドウ内に発生する、指定された属性又は属性値に関連付けられたイベントの数をカウントし得る。

一部の実装では、サンプリングデーモン３１＿１０２は、属性値に基づく統計を生成し得る。例えば、指定された履歴ウィンドウ内のある属性に対する最初の値及び／又は最後の値をクライアントが要求し得、サンプリングデーモン３１＿１０２がそれらを返し得る。指定された履歴ウィンドウ内の指定された属性に関連付けられた全ての値に対する、最小、最大、平均、モード、及び標準偏差をクライアントが要求し得、サンプリングデーモン３１＿１０２がそれらを返し得る。サンプリングデーモン３１＿１０２は、要求されたパーセンタイル（例えば、１０分の１、２５分の１、５０分の１、７５分の１、９０分の１など）にどの値が関連付けられているかを生成又は判定し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、期間統計を生成し得る。例えば、サンプリングデーモン３１＿１０２は、属性の開始イベントと属性の停止イベントとを比較することにより、属性値に関連付けられた期間を判定し得る。開始イベントがいつ発生したかと、停止イベントがいつ発生したかとの間の時間差が、イベントの期間となる。一部の実装では、指定された履歴ウィンドウ内の指定された属性又は属性値に関連付けられた全ての期間に対する、最小、最大、平均、モード、及び標準偏差をクライアントが要求し得、サンプリングデーモン３１＿１０２がそれらを返し得る。サンプリングデーモン３１＿１０２は、要求されたパーセンタイル（例えば、１０分の１、２５分の１、５０分の１、７５分の１、９０分の１など）にどの期間値が関連付けられているかを生成又は判定し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、イベントインターバル統計を生成し得る。例えば、サンプリングデーモン３１＿１０２は、属性イベントの最初の発生を、属性イベントの続く発生と比較することにより、属性値に関連付けられたイベントの到着又は報告に関連付けられた時間インターバルを判定し得る。最初のイベントがいつ発生したかと、続くイベントがいつ発生したかとの間の時間差が、イベントの発生間の時間インターバルとなる。一部の実装では、指定された履歴ウィンドウ内の指定された属性又は属性値に関連付けられた全ての時間インターバル値に対する、最小、最大、平均、モード、及び標準偏差をクライアントが要求し得、サンプリングデーモン３１＿１０２がそれらを返し得る。サンプリングデーモン３１＿１０２は、要求されたパーセンタイル（例えば、１０分の１、２５分の１、５０分の１、７５分の１、９０分の１など）にどのインターバル値が関連付けられているかを生成又は判定し得る。
アプリケーションを最新に維持する－更新をフェッチする

図３１－４は、アプリケーションのバックグラウンドフェッチ更新を実行するためのシステム例３１＿４００を示す。一部の実装では、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のバックグラウンドプロセスとして、アプリケーションを予測的に起動するよう構成され得、ユーザがアプリケーションを呼び出すことを見越して、アプリケーションがコンテンツをダウンロードし、それらのインタフェースを更新し得るようにする。例えば、サンプリングデーモン３１＿１０２により維持されたユーザアプリケーション起動履歴データ（例えば、「ｓｙｓｔｅｍ．ｂｕｎｄｌｅＩｄ」開始イベント）が使用され、ユーザがいつ、モバイルデバイス３１＿１００のアプリケーションを呼び出すかを予想（予測）し得る。これらの予測されたアプリケーションは、ユーザ呼び出しの前に、アプリケーションマネジャ３１＿１０６により起動され得、ユーザ呼び出しアプリケーションが現在のコンテンツをダウンロードし、アプリケーションのグラフィカルインタフェースを更新するのをユーザが待つ必要のないようにする。
アプリケーションをいつ起動するか判定する－時間的予想

一部の実装では、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２からのアプリケーション呼び出し予想を要求し得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーションマネジャ３１＿１０６が、モバイルデバイス３１＿１００上のアプリケーション起動（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）の時間的予想を要求できるインタフェースを提供し得る。サンプリングデーモン３１＿１０２は、上述するように、ユーザがアプリケーションをモバイルデバイス３１＿１００上でいつ呼び出したかを示すイベント（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）を受信し得る。アプリケーションマネジャ３１＿１０６が、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想を要求すると、サンプリングデーモン３１＿１０２は、イベントデータストア３１＿１０４に記憶された「ｂｕｎｄｌｅＩｄ」イベントを分析し、アプリケーションが通常その日（例えば、１５分タイムスロット）のいつユーザにより呼び出されるかを判定し得る。例えば、サンプリングデーモン３１＿１０２は、上述する時間的予想メカニズムを使用して、特定の時刻又は期間が、ユーザによるアプリケーション呼び出しを含む蓋然性を計算し得る。

一部の実装では、アプリケーションマネジャ３１＿１０６の初期化中に、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２からの「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想を要求し得る。例えば、アプリケーションマネジャ３１＿１０６は、モバイルデバイス３１＿１００の起動中に呼び出され又は起動され得る。アプリケーションマネジャ３１＿１０６が初期化されている間に、アプリケーションマネジャ３１＿１０６は、次の２４時間に対するアプリケーション呼び出しの時間的予想を要求し得る（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）。最初の２４時間が経過すると、アプリケーションマネジャ３１＿１０６は、別の２４時間の時間的予想を要求し得る。この２４時間の予想サイクルは、例えば、モバイルデバイス３１＿１００がオフとされるまで継続し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、２４時間に対するアプリケーション呼び出し（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）時間的予想を生成し得る。例えば、サンプリングデーモン３１＿１０２は、２４時間を、９６の１５分タイムスロットに分割し得る。サンプリングデーモン３１＿１０２は、以前の作動日数（例えば、１から７）にわたって、どのアプリケーションが呼び出されたか、及び、そのアプリケーションがいつ呼び出されたか、を、サンプリングデーモン３１＿１０２により収集され、イベントデータストア３１＿１０４に記憶された、アプリケーション起動履歴データ（例えば、「ｂｕｎｄｌｅＩｄ」開始イベントデータ）に基づいて、判定し得る。

一部の実装では、サンプリングデーモン３１＿１０２が、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想を生成すると、時間的予想セクションに上述するように、（例えば、いずれの）アプリケーションが、１５分タイムスロット内に呼び出される蓋然性に従って、各１５分タイムスロットがランク付けされ得る。

９６のタイムスロットのそれぞれに対するアプリケーション呼び出しの蓋然性が計算されると、サンプリングデーモン３１＿１０２は、最も大きい、非ゼロ蓋然性を有するある数のタイムスロット（例えば、最大６４）を選択し、そのタイムスロットを特定する情報をアプリケーションマネジャ３１＿１０６に返し得る。例えば、サンプリングデーモン３１＿１０２は、予想された、ユーザが呼び出すアプリケーション起動（例えば、０を超えるスコアを有するタイムスロット）に対応する、１５分タイムスロットの開始に対応する時間のリスト（例えば、午後１２：００、午後１：４５など）をアプリケーションマネジャ３１＿１０６に送信し得る。

一部の実装では、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２により提供されたタイムスロットに基づいて、タイマを設定し得る。例えば、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２により特定されたタイムスロットに対応する、１つ以上のタイマ（例えば、アラーム）を作成又は設定し得る。各タイマが終了すると（例えば、午後１２：００に）、アプリケーションマネジャ３１＿１０６がウェイクし（例えば、スリープ状態にあった場合、サスペンドしていた場合など）、現在の１５分タイムスロットに対してどのアプリケーションを起動すべきかを判定し得る。従って、タイマは、対応するタイムスロット内にユーザにより呼び出される可能性のあるアプリケーションに対するバックグラウンド更新フェッチをトリガーし得る。

一部の実装では、他のイベントが、アプリケーションに対するバックグラウンド更新フェッチをトリガーし得る。例えば、アプリケーションマネジャ３１＿１０６は、様々なイベント対象を、サンプリングデーモン３１＿１０２に登録し得る。例えば、アプリケーションマネジャ３１＿１０６は、セルラー無線機やベースバンドプロセッサをオンにすること、又は、ネットワーク接続（例えば、セルラー又はＷｉ－Ｆｉ）を確立することに関連するイベントにおける対象（例えば、属性）を登録し得、アプリケーションマネジャ３１＿１０６が、これらのイベントが発生すると、通知され得るようにし、及び、バックグラウンドアプリケーション起動をトリガーし得、アプリケーションの更新が、アクティブなネットワーク接続を利用し得るようにする。モバイルデバイス３１＿１００をロック解除すること、ディスプレイをオンにすること、及び／又は、他の相互作用は、以下に詳述するように、バックグラウンドアプリケーション起動をトリガーし、更新をフェッチし得る。一部の実装では、アプリケーションマネジャ３１＿１０６は、いずれのバックグラウンド更新が、以前の時間（単位：分、例えば、７分間）内に実行された場合、バックグラウンドアプリケーション起動をトリガーせず、更新をフェッチしない。
どのアプリケーションを起動するか判定する－ピア予想

一部の実装では、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２が、現在時刻に起動するアプリケーションのリストを提供することを要求し得る。例えば、タイマが、ある１５分タイムスロットに終了すると（例えば、満了する）、又は、トリガーイベントが検出されると、アプリケーションマネジャは、「ｂｕｎｄｌｅＩｄ」属性に対する、サンプリングデーモン３１＿１０２からのピア予想を要求し得、サンプリングデーモン３１＿１０２が、どのアプリケーションを、現在のタイムスロットに起動するかを判定し得るようにする。サンプリングデーモン３１＿１０２は続いて、アプリケーション識別子、及び、各アプリケーションが、現在時刻前後にユーザにより呼び出される蓋然性を示す、対応するスコアのリストを含むピア予想を生成し得る。

図３１－５は、モバイルデバイス３１＿１００上のアプリケーションに対するユーザ呼び出しの蓋然性を判定するためのピア予想を示す。例えば、ダイアグラム３１＿５００は、最近の履歴ウィンドウ指定（例えば、以前の２時間）に対するピア予想を示す。ダイアグラム３１＿５３０は、日毎履歴ウィンドウ指定（例えば、以前の７日間に対する日毎の４時間ブロック）に対するピア予想を示す。ダイアグラム３１＿５６０は、週毎履歴ウィンドウ指定（例えば、４時間ブロック、毎７日間に１度）に対するピア予想を示す。一部の実装では、サンプリングデーモン３１＿１０２は、異なる重畳ウィンドウ指定に対するピア予想を使用して時系列モデリングを実行し、アプリケーションに対するモバイルデバイス３１＿１００上でのユーザ呼び出しの蓋然性を判定し得る。アプリケーションがピア予想に現れない場合、そのアプリケーションに指定される蓋然性値は０であり得る。

一部の実装では、時系列モデリングは、異なる時間ウィンドウに対するピア予想を生成することにより実行され得る。例えば、最近の、日毎の、及び週毎のイベント履歴ウィンドウ指定に基づいて、最近の、日毎の、及び週毎のピア予想が生成され得る。最近の、日毎の、及び週毎のピア予想は続いて、以下に詳述するように組み合わされ、どのアプリケーションを現在時刻に起動するかが判定され得る。

一部の実装では、ユーザ呼び出しの蓋然性は、最近のアプリケーション呼び出しに基づいて生成され得る。例えば、ユーザ呼び出しの蓋然性は、以前の２時間を対象期間として指定するウィンドウ指定を伴う「ｂｕｎｄｌｅＩｄ」属性に対するピア予想を実行することにより生成され得る（例えば、過去２時間内の、ユーザ開始アプリケーション起動）。

ダイアグラム３１＿５００により示すように、アプリケーション起動履歴データ（例えば、「ｂｕｎｄｌｅＩｄ」イベントデータ）は、以前の２時間内に起動されたアプリケーション数（例えば、４）を示し得る。例えば、ドット及び円が、アプリケーションを表し得、中空の円は、単一の特定のアプリケーション（例えば、電子メール、ソーシャルネットワークアプリケーションなど）を表し得、これらの中空の円は、他のアプリケーションの呼び出しを表す。最近の履歴（例えば、以前の２時間）を使用する、特定のアプリケーションに関連付けられたピア予想蓋然性スコアは、特定のアプリケーションの呼び出し回数（例えば、２回）を、以前の２時間内の、アプリケーション呼び出し合計回数（例えば、４回）で除算することにより計算され得る。ここに示す場合では、最近のアプリケーション起動履歴データを使用する、特定のアプリケーションに関連付けられた蓋然性は、２／４又は５０％である。

ユーザ呼び出しの蓋然性は、アプリケーション起動の日毎の履歴に基づいて生成され得る（例えば、以前の７日間のそれぞれの、現在時刻±２時間に、どのアプリケーションが起動されたか）。例えば、ユーザ呼び出しの蓋然性は、２４時間の再現頻度（例えば、２４時間毎に再現幅を繰り返す）を伴う対象期間（例えば、最新の２時間内のユーザ開始アプリケーション起動）として、現在時刻±２時間（例えば、４時間の再現幅）を指定するウィンドウ指定を伴う「ｂｕｎｄｌｅＩｄ」属性に対するピア予想を実行することにより生成され得る。

ダイアグラム３１＿５３０は、アプリケーションに対するユーザ呼び出しの蓋然性を判定するために使用され得る、アプリケーション起動（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）の日毎の履歴を示す。例えば、ダイアグラム３１＿５３０の各ボックスは、特定のアプリケーション（例えば、中空の円）に対するユーザ呼び出しの蓋然性（例えば、ピア予想スコア）を判定するために分析され得る、（例えば、ピア予想のウィンドウ指定内に指定されるような）以前の日数（例えば、７）のそれぞれでの時間ウィンドウ（例えば、現在時刻±２時間）を示す。日毎の履歴データを使用する特定のアプリケーションに関連付けられた蓋然性は、全てのウィンドウ内の特定のアプリケーションの呼び出し回数（例えば、６）を、全てのウィンドウ内のアプリケーション呼び出し合計回数（例えば、２２）で除算することにより計算され得る。ここに示す場合では、日毎の起動履歴データを使用する、特定のアプリケーションに関連付けられた蓋然性は、６／２２又は２７％である。

ユーザ呼び出しの蓋然性は、アプリケーション起動の週毎の履歴に基づいて生成され得る（例えば、７日前の現在時刻±２時間に、どのアプリケーションが起動されたか）。例えば、ユーザ呼び出しの蓋然性は、７日間の再現頻度（例えば、７日間毎に再現幅を繰り返す）を伴う対象期間（例えば、最新の２時間内のユーザ開始アプリケーション起動）として、現在時刻±２時間（例えば、４時間の再現幅）を指定するウィンドウ指定を伴う「ｂｕｎｄｌｅＩｄ」属性に対するピア予想を実行することにより生成され得る。

ダイアグラム３１＿５６０は、アプリケーションに対するユーザ呼び出しの蓋然性を判定するために使用され得る、アプリケーション起動（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）の週毎の履歴を示す。例えば、現在の日時が水曜日の午後１時である場合、アプリケーションに対するユーザ呼び出しの蓋然性（例えば、ピア予想スコア）は、以前の水曜日中の、午後１時での、又はその前後（例えば、±２時間）の時間ウィンドウ中に起動されたアプリケーションに基づき得る。ここに示す場合では、週毎のアプリケーション起動履歴データを使用する、特定のアプリケーションに関連付けられた蓋然性（例えば、中空の円）は、１／４又は２５％である。

一部の実装では、最近の、日毎の、及び週毎のユーザ呼び出しの蓋然性は、各アプリケーションに対するスコアを生成するために組み合わせられ得る。例えば、最近の、日毎の、及び週毎の蓋然性は、最近の（ｒ）、日毎の（ｄ）、及び週毎（ｗ）の蓋然性の加重平均を計算することにより組み合わせられ得る。各蓋然性は関連するウェイトを有し得、各ウェイトは、各蓋然性の、実証的に判定された所定の重要性に対応し得る。全てのウェイトの合計は１に等しくなり得る。例えば、最近の起動に基づく蓋然性に対するウェイトは０．６であり得、日毎の蓋然性に対するウェイトは０．３であり得、週毎の蓋然性に対するウェイトは０．１であり得る。従って、組み合わされる蓋然性スコアは、０．６（ｒ）、０．３（ｄ）、及び０．１（ｗ）の合計であり得る（例えば、スコア＝０．６ｒ＋０．３ｄ＋０．１ｗ）。

図３１－４を参照して戻ると、最近の、日毎の、及び週毎の蓋然性に基づいて、各アプリケーションに対する蓋然性スコアが判定されると、サンプリングデーモン３１＿１０２は、最も高い、非ゼロ蓋然性スコアを有するアプリケーションの構成変更可能数（例えば、３）を、起動、ダウンロード／更新のバックグラウンドフェッチの実行のために、アプリケーションマネジャ３１＿１０６に推奨し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、上述する「ｗｈａｔ ｔｏ ｌａｕｎｃｈ」分析から、バックグラウンド更新（例えば、フェッチング）アプリケーション更新をサポートしないアプリケーション、ユーザがバックグラウンド更新をオフにしたアプリケーション、バックグラウンド更新以外を選択したアプリケーション、及び／又は、フォアグランドアプリケーションがすでに最新である可能性があるために、ユーザにより現在使用されているアプリケーション若しくはモバイルデバイス３１＿１００のディスプレイ上のフォアグランド内にあるアプリケーションを除外し得る。

一部の実装では、アプリケーションマネジャ３１＿１０６が、推奨されたアプリケーションをサンプリングデーモン３１＿１０２から受信すると、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２に、推奨されたアプリケーションのそれぞれを起動してもよいか尋ね得る。サンプリングデーモン３１＿１０２は、そのローカルアドミッション制御メカニズム（以下に説明する）を使用し、アプリケーションマネジャに対し、特定のアプリケーションを起動してもよいか否かを判定し得る。例えば、アプリケーションマネジャ３１＿１０６は、推奨されたアプリケーションの１つを特定する属性値を伴う「ｂｕｎｄｌｅＩｄ」属性を、サンプリングデーモン３１＿１０２に送信し、サンプリングデーモン３１＿１０２に、その属性値でのアドミッション制御を実行することを要求し得る。
ローカルアドミッション制御

一部の実装では、サンプリングデーモン３１＿１０２は、属性イベントに対するアドミッション制御を、モバイルデバイス３１＿１００上で実行し得る。例えば、アドミッション制御は、属性又は属性値について実行され、クライアントアプリケーションが、その属性に関連付けられたアクティビティ、アクション、機能、イベントなどを実行し得るか否かが判定され得る。例えば、サンプリングデーモン３１＿１０２のクライアントは、「ｍａｉｌａｐｐ」の値を有する属性「ｂｕｎｄｌｅＩｄ」のアドミッションを要求し得る。このアドミッション要求を受信したことに応じて、サンプリングデーモンは、クライアントが、「ｍａｉｌａｐｐ」属性値に関連付けられたアクティビティを実行し得るか否かを判定し得る（例えば、「ｍａｉｌａｐｐ」アプリケーションを実行する）。

一部の実装では、アドミッション制御は、ボーターからの割当量及びフィードバックに基づいて実行され得る。例えば、サンプリングデーモン３１＿１０２がアドミッション制御要求を受信する際に、この要求は、属性イベントを許可することに関連付けられたコストを含み得る（例えば、アプリケーションを起動すること、「ｂｕｎｄｌｅＩｄ」開始イベント）。サンプリングデーモン３１＿１０２は、システムワイドデータ割当量、システムワイドエネルギ割当量、及び／又は、特定の属性割当量をチェックし、属性に関連付けられた割当量が、属性イベントをカバーするための残りの十分なクレジットを有するか否かが判定され得る。属性に関連付けられた割当量がない（例えば、属性が、割当量のある属性ではない）場合、続いて属性イベントは許可され、進められ得る（例えば、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｏｋ」値を返す）。属性に関連付けられた割当量があるものの、イベントのコストをカバーすることに十分なクレジットが、関連する割当量に残っていない場合、属性イベントは許可されず、進められない（例えば、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｎｏ」値を返す）。

属性に関連付けられた割当量があり、イベントのコストをカバーすることに十分なクレジットが、割当量に残っている場合、続いてボーターは、属性を進めるための許可に投票するか尋ねられる。全てのボーターが「ｙｅｓ」に投票すると、続いて属性イベントは許可され、進められる（例えば、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｏｋ」値を返す）。いずれのボーターが「ｎｏ」に投票すると、続いて属性イベントは許可されず、進められない（例えば、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｎｏ」値を返す）。割当量及びボーターに関する詳細は、以下の段落に説明する。

一部の実装では、属性又は属性値が、イベントにて、アドミッション制御要求に先行して、ある期間（例えば、７日間、一か月など）内にサンプリングデーモン３１＿１０２に報告されていない場合、続いてサンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｎｅｖｅｒ」値を返し得る。例えば、サンプリングデーモン３１＿１０２は、時間的又はピア予想を生成し、属性又は属性値に関連付けられたイベントをいつ許可又はアドミットするかを判定し得る。例えば、発生すると予期されていないイベントを先取する必要はない（例えば、ユーザにより呼び出されないアプリケーションに対するデータをプリフェッチする必要はない）。
アドミッション制御－割当量

一部の実装では、サンプリングデーモン３１＿１０２は、属性又は属性値に関連付けられた割当量に基づいて、アドミッション制御を実行し得る。例えば、サンプリングデーモン３１＿１０２は、ある属性又は属性値に関連付けられたアクティビティ（例えば、イベント）を、その属性又は属性値に関連付けられた割当量に基づいて許可する（例えば、アドミットする）か否かを判定し得る。一部の実装では、サンプリングデーモン３１＿１０２は、属性又は属性値をアドミットしてもよいか否かを、モバイルデバイス３１＿１００に対して構成されたシステムワイドエネルギ割当量及び／又はシステムワイドデータ割当量に基づいて判定し得る。サンプリングデーモン３１＿１０２は、現在の時刻（例えば、現在時間）に対する残りのデータ及びエネルギ割当量の追跡を維持するためのカウンタを含め、課金データストア３１＿４０２に割当量を記憶し得る。ある属性又は属性値に対してアドミッション制御が実行されることをクライアントが要求すると、クライアントは、その属性又は属性値に関連付けられたイベントの発生を許可する又はアドミットするコストを表す数値を指定し得る。その属性に関連付けられた割当量に十分なクレジットがある場合、続いて属性イベントが、以下に説明するボーターにより投票される。その属性に関連付けられた割当量に十分なクレジットがない場合、続いて属性イベントは許可されず、進められない。
システムワイドエネルギ割当量

一部の実装では、サンプリングデーモン３１＿１０２は、エネルギ割当量に基づいて、属性又は属性値をアドミットしてもよいか否かを判定し得る。例えば、エネルギ割当量は、ミリアンペア時での、モバイルデバイスのバッテリの容量のパーセンテージ（例えば、５％）である。

一部の実装では、エネルギ割当量は、２４時間の各時間に分配され得る。例えば、サンプリングデーモン３１＿１０２は、収集され、イベントデータストア３１＿１０４内に記憶されたバッテリ使用統計（例えば、「ｓｙｓｔｅｍ．ｅｎｅｒｇｙ」イベント）を使用し、２４時間の各時間に対する、典型的な過去のバッテリ使用量を反映する分布を判定し得る。例えば、各時間は、上述するように、履歴的又は統計的に判定されたエネルギ使用分布又はアプリケーションの使用予想に基づいて、エネルギ割当量のパーセンテージが指定され得る。各時間は、０より大きい（例えば、０．１％、１％など）少なくとも最小量のエネルギ割当量を有することとなる。例えば、１０％のエネルギ割当量は、使用データを伴わない時間に分配され得、残りの９０％のエネルギ割当量は、過去のエネルギ又はアプリケーションの使用に従って、アクティブな使用時間に分配され得る。各時間が経過すると、現在のエネルギ割当量に、新たな／現在時間に対するエネルギ割当量が補充される。以前の時間から残ったいずれのエネルギ割当量は、現在時間の割当量に加えられる。

一部の実装では、課金データストア３１＿４０２は、エネルギ割当量がどれほど残っていて利用可能であるかを判定するためのカウンタを含み得る。例えば、課金データストア３１＿４０２は、現在時間に対するエネルギ割当量を伴って初期化される１つ以上のカウンタを含み得る。エネルギ割当量が属性イベントにより使用されると、このエネルギ割当量は、対応する量がデクリメントされ得る。例えば、アプリケーションマネジャ３１＿１０６は、「ｂｕｎｄｌｅＩｄ」開始又は停止イベントを使用して、アプリケーションがいつ起動又は終了されたかを、サンプリングデーモン３１＿１０２に通知し得る。今度は、サンプリングデーモン３１＿１０２が、アプリケーションがいつ起動されたか、及び、アプリケーションがいつ終了されたかを、電力モニタ３１＿１０９に通知し得る。開始及び停止時間に基づき、電力モニタ３１＿１０９は、アプリケーションによりエネルギがどれほど使用されたかを判定し得る。電力モニタ３１＿１０９は、アプリケーションにより使用された電力量を、サンプリングデーモン３１＿１０２に送信し得（例えば、「ｓｙｓｔｅｍ．ｅｎｅｒｇｙ」属性イベントを提出することにより）、サンプリングデーモン３１＿１０２は、使用された電力量に相当する分を、適切なカウンタからデクリメントし得る。

一部の実装では、エネルギ割当量が現在時間に対して残っていない場合、サンプリングデーモン３１＿１０２は、属性に対するアドミッション要求を断り得る。例えば、課金データストア３１＿４０２内のエネルギ割当量カウンタが０にデクリメントされると、エネルギ割当量は残らず、エネルギ割当量に紐付けられた属性に関連付けられたアクティビティ、イベントなどはアドミットされ得ない。十分なエネルギ割当量が現在時間に対して残っており、属性イベントのコストをカバーする場合、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｙｅｓ」値を返し、属性イベントを許可して進め得る。

一部の実装では、モバイルデバイス３１＿１００が外部電源に接続されていると、サンプリングデーモン３１＿１０２は、アドミッション制御決定を、エネルギ割当量に基づかない。例えば、モバイルデバイス３１＿１００が外部電源に接続されている場合、残りのエネルギ割当量が０でも、属性イベントは阻止されない。
システムワイドデータ割当量

一部の実装では、サンプリングデーモン３１＿１０２は、データ割当量に基づいて、属性をアドミットしてもよいか否かを判定し得る。例えば、サンプリングデーモン３１＿１０２は、サンプリングデーモン３１＿１０２により収集され、イベントデータストア３１＿１０４に記憶された統計データ（例えば、「ｓｙｓｔｅｍ．ｎｅｔｗｏｒｋＢｙｔｅｓ」属性イベント）に基づいて、モバイルデバイス３１＿１００により消費されたネットワークデータの平均量を判定し得る。ネットワークデータ割当量は、ユーザ／モバイルデバイス３１＿１００により消費された平均日毎ネットワークデータのパーセンテージとして計算され得る。あるいは、ネットワークデータ割当量は、所定の値又は構成変更可能な値であり得る。

一部の実装では、ネットワークデータ割当量は、２４時間の各時間に分配され得る。例えば、各時間は、最小割当量（例えば、０．２ＭＢ）が割り当てられ得る。ネットワークデータ割当量の残りの量は、過去ネットワークデータ使用量に従って、２４時間のそれぞれに分配され得る。例えば、サンプリングデーモン３１＿１０２は、過去統計データ（例えば、「ｓｙｓｔｅｍ．ｎｅｔｗｏｒｋＢｙｔｅｓ」属性イベント）に基づいて、１日の各時間にネットワークデータがどれほど消費されたか判定し、各時間に消費されたデータの量に従って、パーセンテージを指定し得る。各時間が経過すると、現在のデータ割当量に、新たな／現在時間に対するデータ割当量が補充される。以前の時間から残ったいずれのデータ割当量は、現在時間のデータ割当量に加えられ得る。

一部の実装では、課金データストア３１＿４０２は、ネットワークデータ割当量に対するデータカウンタを維持し得る。ネットワークデータが消費されると、データカウンタは、消費されたネットワークデータの量に従ってデクリメントされ得る。例えば、消費されたネットワークデータの量は、アプリケーションマネジャ３１＿１０６によりサンプリングデーモン３１＿１０２に提供されたアプリケーション開始及び停止イベント（例えば、「ｂｕｎｄｌｅＩｄ」開始又は停止イベント）に基づいて判定され得る。あるいは、消費されたネットワークデータの量は、ネットワークインタフェースを管理するプロセスにより提供され得る（例えば、ネットワークデーモン３１＿４０６、バックグラウンド転送デーモン３１＿１３０２）。例えば、ネットワークインタフェース管理プロセスは、サンプリングデーモン３１＿１０２に、アプリケーション開始及び停止イベント（例えば、「ｂｕｎｄｌｅＩｄ」イベント）と相互関係し得る「ｓｙｓｔｅｍ．ｎｅｔｗｏｒｋＢｙｔｅｓ」イベントを報告し、アプリケーションが消費したデータはどれほどかを判定し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、どのネットワークインタフェースタイプ（例えば、セルラー又はＷｉ－Ｆｉ）が使用され、ネットワークデータが消費されたかの追跡を維持し、そのネットワークインタフェースタイプに基づいて、消費されたネットワークデータの量を判定し得る。消費されたネットワークデータの量は、各インタフェースタイプに指定されたウェイト又は係数に従って調整され得る。例えば、セルラーデータインタフェース上で消費されたネットワークデータは、１の係数が指定され得る。Ｗｉ－Ｆｉインタフェース上で消費されたネットワークデータは、１０分の１（０．１）の係数が指定され得る。消費された合計ネットワークデータは、消費されたセルラーデータを、１０で除算された、消費されたＷｉ－Ｆｉデータに加算することにより計算され得る（例えば、合計データ＝１×セルラーデータ＋０．１×Ｗｉ－Ｆｉ）。従って、Ｗｉ－Ｆｉ経由で消費されたデータは、セルラーデータ接続経由で消費されたデータよりも、データ割当量に与える影響が非常に少ない。

一部の実装では、現在時間に対してデータ割当量が残っていない場合、サンプリングデーモン３１＿１０２は、アドミッション制御要求に、「ｎｏ」リプライと共に応答し得る。例えば、課金データストア３１＿４０２内のデータ割当量カウンタが０にデクリメントされると、データ割当量が残らず、データ割当量に紐付けられた属性に関連付けられたアクティビティは許可されない。現在時間内の残りのデータ割当量が十分にあり、属性イベントのデータコストをカバーする場合、続いてサンプリングデーモン３１＿１０２は、アドミッション制御要求に、「ｙｅｓ」リプライと共に応答し得る。
属性割当量

一部の実装では、属性は、割当量が関連付けられ得る。例えば、所定の属性又はカスタム（動的に定義された）属性は、サンプリングデーモン３１＿１０２のＡＰＩを通して割当量が関連付けられ得る。サンプリングデーモン３１＿１０２のクライアント（例えば、アプリケーション、ユーティリティ、機能、第三者アプリケーションなど）は、属性をクライアント定義割当量と関連付けることの要求をサンプリングデーモン３１＿１０２に実行し得る。この割当量は、例えば、クレジット数であり得る。

割当量が割り当てられると、割当量のある属性に関連付けられた、報告されたイベントは、そのイベントに関連付けられたコストを示し得、その割当量が、指定されたコストに従ってデクリメントされ得る。例えば、所定のシステム属性「ｓｙｓｔｅｍ．ｂｔｌｅｓｃａｎ」は、モバイルデバイス３１＿１００上に、他のＢｌｕｅｔｏｏｔｈ低エネルギデバイスからの信号に対するスキャンをモバイルデバイス３１＿１００がいつ実行するかを示すよう構成され得る。Ｂｌｕｅｔｏｏｔｈ ＬＥスキャンは、例えば、バックグラウンドタスクとして実行され得る。Ｂｌｕｅｔｏｏｔｈ ＬＥスキャンは、Ｂｌｕｅｔｏｏｔｈラジオをオンにする必要があり、これはつまり、モバイルデバイス３１＿１００のバッテリからのエネルギを消費する。Ｂｌｕｅｔｏｏｔｈ ＬＥスキャンが過剰にエネルギを消費しないようにするため、「ｂｔｌｅｓｃａｎ」属性は、割当量（例えば、２４クレジット）が指定され得る。「ｂｔｌｅｓｃａｎ」イベントが生成され、サンプリングデーモン３１＿１０２に報告される度に、このイベントは、コストと共に報告され得る（例えば、１）。このコストは割当量から減じられ得、「ｂｔｌｅｓｃａｎ」属性がイベントにて報告される度に、２４の割当量から１がデクリメントされる。

一部の実装では、属性割当量は、ある期間にわたって分配され得る。例えば、「ｂｔｌｅｓｃａｎ」属性割当量は、２４時間にわたって均等に分配され得、「ｂｔｌｅｓｃａｎ」属性が、１時間毎に１クレジットのみを支出し得るようにできる。一部の実装では、属性割当量は、期間の終了時に補充され得る。例えば、「ｂｔｌｅｓｃａｎ」属性割当量に対する期間が２４時間の場合、続いて「ｂｔｌｅｓｃａｎ」属性割当量は、２４時間毎に補充され得る。

一部の実装では、属性に関連付けられた割当量は、別の割当量のサブセット（例えば、下位割当量）であり得る。例えば、属性に対する割当量は、上述するシステムワイドデータ又はシステムワイドエネルギ割当量などの、別の割当量の一部として指定され得る。例えば、「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」属性は、システムに対して割り当てられたデータ割当量の５％の割当量に関連付けられ得る。「ｂｔｌｅｓｃａｎ」属性は、システムに対して割り当てられたエネルギ割当量の３％の割当量に関連付けられ得る。下位割当量（例えば、「ｍａｉｌｂｏｘ」割当量）は、上位割当量（例えば、システムデータ割当量）に紐付けられ得、下位割当量をデクリメントすることはまた、上位割当量をデクリメントすることであるようにする。一部の実装では、上位割当量が０に減じられると、続いて下位割当量もまた０に減じられる。例えば、システムデータ割当量が０である場合、「ｍａｉｌｂｏｘ」属性割当量をデクリメントするであろう、「ｍａｉｌｂｏｘ」属性についてのイベントが報告されなくとも、「ｍａｉｌｂｏｘ」属性割当量もまた０である。

一部の実装では、サンプリングデーモン３１＿１０２クライアントは、サンプリングデーモン３１＿１０２が、ある属性に対して残っている割当量を返すことを要求し得る。例えば、クライアントは、サンプリングデーモン３１＿１０２に、「ｂｔｌｅｓｃａｎ」属性に対する残りの割当量の要求を行い得る。２４の割当量のあるクレジットの３つが使用された場合、続いてサンプリングデーモン３１＿１０２は、２１の値を要求クライアントに返し得る。

一部の実装では、関連付けられた属性に対する割当量内にクレジットが残っていない場合、クライアントは、指定数の割当量のあるクレジットを費やすイベントを報告し得る。割当量内に残りのクレジットがない場合に、サンプリングデーモン３１＿１０２が、１クレジットを費やすイベント（例えば、「ｂｔｌｅｓｃａｎ」イベント）を受信すると、サンプリングデーモン３１＿１０２は、割当量をデクリメントし（例えば、－１）、イベントを報告したクライアントにエラーを返し得る。このエラーは、例えば、属性が、残りの割当量を有しないことを示し得る。
属性割当量の形成

一部の実装では、属性割当量は、過去使用情報に基づいて分配され得る。例えば、割当量のある属性に対してイベントが報告されると、その属性に対する割当量を使用することの要求（例えば、コストに関連付けられたイベント）が、経時的に追跡され得る。例えば、２４の割当量が「ｂｔｌｅｓｃａｎ」属性に割り当てられる場合、この割当量は初期的に、上述するように、２４時間にわたって均等に割り当てられ得る。割当量に関連付けられた属性に対するイベントが経時的に報告されると、サンプリングデーモン３１＿１０２は報告されたイベントを分析し、２４時間のいつ、イベントが最も発生する可能性があるかを判定し得る。例えば、「ｂｔｌｅｓｃａｎ」イベントは、午前８時、午後１２時、及び午後６時前後に頻繁に発生するが、午前２時前後にはほとんど発生しないと、サンプリングデーモン３１＿１０２は判定し得る。サンプリングデーモン３１＿１０２は、このイベント頻度情報を使用し、２４時間にわたる「ｂｔｌｅｓｃａｎ」属性の割当量の分布を形成し得る。例えば、サンプリングデーモンは、午前８時、午後１２時、及び午後６時に対応する各タイムスロットに対して２の割当量クレジットを割り当て、０の割当量クレジットを、午前２時に関連付けられたタイムスロットに対して割り当て得る。
アドミッション制御－ボーター

一部の実装では、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００上で実行されている他のソフトウェア（例えば、プラグイン、ユーティリティ、アプリケーション、ヒューリスティックプロセス）からのフィードバックに基づいて、アドミッション制御を実行し得る。例えば、他のソフトウェアは、アドミッション制御に対するボーターとして、サンプリングデーモン３１＿１０２と共に機能するよう構成され得る。例えば、種々のボーター（例えば、アプリケーション、ユーティリティ、デーモン、ヒューリスティックなど）が、サンプリングデーモン３１＿１０２に登録され、アドミッション制御決定を投票し得る。例えば、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００の熱条件を監視するボーター、モバイルデバイス３１＿１００のＣＰＵ使用量を監視するボーター、及び／又は、モバイルデバイス３１＿１００のバッテリ電力レベルを監視するボーターとのインタフェースとなるよう構成され得る。サンプリングデーモン３１＿１０２がアドミッション制御要求を受信すると、各ボーター（例えば、熱、ＣＰＵ、及びバッテリ）は、指定された属性に関連付けられたアクティビティが許可されるべきか否かについて投票するよう求められ得る。全てのボーターが「ｙｅｓ」を投票すると、続いて属性がアドミットされる（例えば、属性に関連付けられたアクティビティが生じることが許可される）。単一のボーターが「ｎｏ」を投票すると、続いて属性はアドミットされない（例えば、属性に関連付けられたアクティビティは許可されない）。一部の実装では、ボーターは、サンプリングデーモン３１＿１０２に動的に（例えば、ランタイムにて）追加され、アドミッション制御システムに追加機能を提供し得るプラグインソフトウェアとして構成され得る。一部の実装では、ボーターは、属性又は属性値に関連付けられたイベントをアドミットする又は許可するか否かを判定する時に、上述する時間的及びピア予想メカニズムを使用し得る。
ネットワークデーモン

一部の実装では、ネットワークデーモン３１＿４０６は、アドミッション制御ボーターとして構成され得る。ネットワークデーモン３１＿４０６は、ネットワークデーモン３１＿４０６が、サンプリングデーモン３１＿１０２から投票要求を受信し、投票（例えば、ｙｅｓ、ｎｏ）応答をサンプリングデーモン３１＿１０２に提供できるようにする、サンプリングデーモン３１＿１０２の投票ＡＰＩを使用するよう構成され得る。例えば、ネットワークデーモン３１＿４０６は、サンプリングデーモン３１＿１０２から、属性及び／又は属性値を含む投票要求を受信し得る。ネットワークデーモン３１＿４０６は、例えば、モバイルデバイス３１＿１００がボイスコールに接続されており、Ｗｉ－Ｆｉネットワーク接続に接続されていない場合に、サンプリングデーモン３１＿１０２が、属性又は属性値に関連付けられたイベントをアドミット又は許可すべきでないことを示し得る。ユーザがボイスコールに接続されており、Ｗｉ－Ｆｉ接続に接続されていない場合に、例えば、バックグラウンド更新プロセス（例えば、フェッチプロセス）がボイスコールの品質に悪影響を与えない又はこれを損なわないよう、ネットワークデーモン３１＿４０６は、バックグラウンド更新プロセスを起動することに関連付けられたイベント（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）を許可しない。従って、ネットワークデーモン３１＿４０６は、モバイルデバイス３１＿１００が呼び出しに接続されており、Ｗｉ－Ｆｉに接続されていない場合に、投票要求に応じて「ｎｏ」値を返し得る。

一部の実装では、モバイルデバイス３１＿１００が低品質セルラーネットワーク接続を有する場合、サンプリングデーモン３１＿１０２が属性イベントを許可又はアドミットすべきでないことを、ネットワークデーモン３１＿４０６は示し得る。低品質セルラー接続は、転送速度及び／又はスループットが既定閾値を下回ると判定され得る。例えば、モバイルデバイス３１＿１００が低品質セルラーネットワーク接続を有し、Ｗｉ－Ｆｉに接続されていない場合、ネットワークデーモン３１＿４０６は、その低品質ネットワーク接続を使用することによりバッテリエネルギ及びセルラーデータを浪費するであろう属性イベントのアドミッション又は実行（例えば、不十分なセルラー接続を経由してのデータのダウンロード又はアップロードを試みるであろうアプリケーションの起動）を、サンプリングデーモン３１＿１０２がボーター要求を行う際に「ｎｏ」値を返すことにより阻止し得る。

一部の実装では、ネットワークデーモン３１＿４０６が、不十分なネットワーク条件、又は、ネットワークデータ使用量若しくはシステムパフォーマンスに影響を与えるであろう一部の他の条件を示す情報を有しない場合、ネットワークデーモン３１＿４０６は、要求された属性のアドミッションについて「ｙｅｓ」を投票し得る。
熱デーモン

一部の実装では、熱デーモン３１＿１１０アプリケーションは、アドミッション制御ボーターとして構成され得る。熱デーモン３１＿１１０は、熱デーモン３１＿１１０が、サンプリングデーモン３１＿１０２から投票要求を受信し、投票（例えば、ｙｅｓ、ｎｏ）応答をサンプリングデーモン３１＿１０２に提供できるようにする、サンプリングデーモン３１＿１０２の投票ＡＰＩを使用するよう構成され得る。例えば、熱デーモンは、サンプリングデーモン３１＿１０２から、属性及び／又は属性値を含む投票要求を受信し得る。熱デーモン３１＿１１０が熱イベントを検出すると、サンプリングデーモン３１＿１０２が、属性又は属性値に関連付けられたイベントをアドミット又は許可すべきでないことを、熱デーモン３１＿１１０は示し得る。例えば、熱デーモン３１＿１１０は、モバイルデバイス３１＿１００の温度を監視し、「ｔｈｅｒｍａｌＬｅｖｅｌ」属性及び対応する温度値を含むイベントを生成することにより、温度値をサンプリングデーモン３１＿１０２に報告し得る。

一部の実装では、モバイルデバイス３１＿１００の温度が閾値温度値を超えていると熱デーモン３１＿１１０が判定すると、熱デーモン３１＿１１０は、モバイルデバイス３１＿１００の作動温度を更に上げる可能性のある属性イベントを熱デーモン３１＿１０２が許可することを、属性（例えば、「ｂｕｎｄｌｅＩｄ」）イベントに投票することの要求をサンプリングデーモン３１＿１０２が熱デーモン３１＿１１０に送信する際に「ｎｏ」値を返すことにより阻止し得る。

一部の実装では、異常な熱条件が現在存在すると、サンプリングデーモン３１＿１０２は、熱デーモン３１＿１１０からの投票のみを求める。例えば、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００が正常な熱条件にて作動しているか否かを示す熱条件値（例えば、真、偽）を維持し得る。モバイルデバイス３１＿１００の現在の熱条件が正常である場合、続いて熱条件値は、例えば、真であり得る。モバイルデバイス３１＿１００の現在の熱条件が異常である場合（例えば、熱すぎる、閾値温度を超える）、続いて熱条件値は偽であり得る。初期的に、熱条件値は真に設定され得る（例えば、正常な作動温度）。作動温度が閾値温度を超えて上昇したことを検出すると、熱デーモン３１＿１１０は、異常な作動温度（例えば、偽）を示す、熱条件値に対する更新された値をサンプリングデーモン３１＿１０２に送信し得る。モバイルデバイス３１＿１００が、閾値温度を下回る温度に冷めると、熱デーモン３１＿１１０は、熱条件値を更新し、正常な作動温度（例えば、真）を示し得る。

サンプリングデーモン３１＿１０２が、ある属性に対するアドミッション制御要求を受信すると、サンプリングデーモン３１＿１０２は熱条件値をチェックし、属性イベントのアドミッション（容認）について投票するよう熱デーモン３１＿１１０に求めるか否かを判定し得る。熱条件値が正常な作動温度を示す場合（例えば、値が真）、サンプリングデーモン３１＿１０２は、熱条件値を、熱デーモン３１＿１１０からの「ｙｅｓ」の投票と解釈する。

熱条件値が異常な作動温度を示す場合（例えば、値が偽）、サンプリングデーモン３１＿１０２は、属性及び／又は属性値を熱デーモン３１＿１１０に送信し、熱デーモン３１＿１１０が特定の属性又は属性値について投票できるようにする。

一部の実装では、熱デーモン３１＿１１０は、属性及び／又は属性値についてどのように投票するか（例えば、ｙｅｓ、ｎｏ）を、モバイルデバイス３１＿１００の現在の熱条件及び属性に対するピア予想に基づいて判定し得る。例えば、熱デーモン３１＿１１０は、サンプリングデーモン３１＿１０２からの属性に対するピア予想を要求し得る。熱デーモン３１＿１１０は、対象期間内の現在時刻（例えば、±１時間、２時間など）を含むウィンドウ指定を生成することにより、現在時刻に対するピア予想を要求し得る。熱デーモン３１＿１１０は、対象期間内に現れる属性の各値に対する可能性スコアを示すピア予想を、サンプリングデーモン３１＿１０２から受信する。例えば、熱デーモン３１＿１１０が、「ｂｕｎｄｌｅＩｄ」属性に対するピア予想を要求する場合、熱デーモン３１＿１１０は、「ｂｕｎｄｌｅＩｄ」値（例えば、アプリケーション識別子）及び関連する予測（例えば、蓋然性、可能性）スコアのリストを受信し得る。例えば、対象期間中、属性値「ｍａｉｌａｐｐ」、「ｃｏｎｔａｃｔｓ」、「ｃａｌｅｎｄａｒ」、「ｗｅｂｂｒｏｗｓｅｒ」、「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、及び「ｍａｉｌａｐｐ」を有する「ｂｕｎｄｌｅＩｄ」イベントが発生すると、「ｍａｉｌａｐｐ」の発生する相対的可能性（すなわち、スコア）は０．４３（例えば、３／７）であり、「ｗｅｂｂｒｏｗｓｅｒ」の発生する相対的可能性は０．２９（例えば、２／７）であり、及び、「ｃｏｎｔａｃｔｓ」又は「ｃａｌｅｎｄａｒ」の発生する相対的可能性は０．１４（例えば、１／７）である。一部の実装では、熱デーモン３１＿１１０は、スコアに従って、属性値のリストを順序付けし得る（例えば、最高スコアを最上位に、最低スコアを最下位に）。例えば、上記「ｂｕｎｄｌｅＩｄ」属性値に対して最上位から最下位に順序付けされたリストは次のようになる、すなわち、「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、「ｃｏｎｔａｃｔｓ」、及び「ｃａｌｅｎｄａｒ」。

一部の実装では、熱デーモン３１＿１１０は、属性値が、順序付けされたリスト内のどこにあるかに基づいて、属性値についてのｙｅｓをいつ投票するかを判定し得る。例えば、熱デーモン３１＿１１０により検討中の属性値が、サンプリングデーモン３１＿１０２から受信したピア予想リスト内に無い場合、続いて属性値は、熱デーモン３１＿１１０から「ｎｏ」投票を受信する。属性値がピア予想リスト内にあり、リスト内で閾値レベル（例えば、インデックス）未満（例えば、スコアに基づいて、属性の下位の２５％内）である場合、続いて熱デーモン３１＿１１０は、属性について「ｎｏ」を投票する。属性値がピア予想リスト内にあり、リスト内の閾値レベルを超える場合（例えば、スコアに基づいて、属性の上位の７５％内）、続いて熱デーモン３１＿１１０は、属性について「ｙｅｓ」を投票する。投票が判定されると、熱デーモン３１＿１１０は、「ｙｅｓ」（例えば、真）又は「ｎｏ」（例えば、偽）投票をサンプリングデーモン３１＿１０２に返す。

一部の実装では、熱デーモン３１＿１１０は、最大閾値レベルと共に構成され、全ての属性値について「ｎｏ」を投票することを回避し得る（例えば、一部の属性イベントが発生するようにする）。最大閾値レベルは、順序付けされたピア予想リスト内の属性値の５０％であり得る（例えば、上位５０％が「ｙｅｓ」投票を得て、下位５０％が「ｎｏ」投票を得る）。熱デーモン３１＿１１０は従って、「ｙｅｓ」投票を受信する属性値を、「ｎｏ」投票を受信する属性値とは別個のものとする閾値レベルを、最低スコアを伴う属性値の０％～５０％の間で調整し得る。

一部の実装では、「ｙｅｓ」又は「ｎｏ」投票を判定するための閾値レベルは、モバイルデバイス３１＿１００の熱レベル（例えば、温度）に比例し得る。例えば、熱デーモン３１＿１１０は、最大作動熱レベル（Ｌｈ）及び正常作動レベル（Ｌｎ）と共に構成され得る。熱デーモン３１＿１１０は、現在の作動熱レベル（Ｌｃ）を判定し、いくらの熱範囲のパーセンタイル（例えば、Ｌｈ－Ｌｎ）で、モバイルデバイス３１＿１００が現在作動しているかを判定し得る（例えば、Ｌｃ－Ｌｎ／Ｌｈ－Ｌｎ＝％）。熱デーモン３１＿１１０は、計算されたパーセンタイルを使用し、０～５０％の属性値のどの部分が、「ｎｏ」投票を受信するべきかを判定し得る。例えば、現在の作動熱レベルが、６５％の熱範囲となるよう計算されている場合、ピア予想スコアによる下位３２．５％の属性値が続いて、熱デーモン３１＿１１０から「ｎｏ」投票を受信する。従って、あまり重要でない属性値が「ｎｏ」投票を受信する一方で、最も重要な属性値は「ｙｅｓ」投票を受信する。上記「ｂｕｎｄｌｅＩｄ」例を参照して戻ると、上記「ｂｕｎｄｌｅＩｄ」属性値に対して最上位から最下位に順序付けされたリストが次のようになる場合、すなわち、「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、「ｃｏｎｔａｃｔｓ」、及び「ｃａｌｅｎｄａｒ」、続いて「ｃａｌｅｎｄａｒ」は「ｎｏ」投票を受信し、「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、及び「ｃｏｎｔａｃｔｓ」は「ｙｅｓ」投票を受信する（例えば、「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、及び「ｃｏｎｔａｃｔｓ」は最も使用されるアプリケーションである）。例えば、アプリケーションマネジャ３１＿１０６が、「ｂｕｎｄｌｅＩｄ」属性に対する、どのアプリケーションを起動するか判定するためのアドミッション制御要求を行うと、続いて「ｍａｉｌａｐｐ」、「ｗｅｂｂｒｏｗｓｅｒ」、及び「ｃｏｎｔａｃｔｓ」アプリケーションが起動され、「ｃａｌｅｎｄａｒ」アプリケーションは起動されない。

別の実施例として、熱デーモン３１＿１１０は、「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」属性について投票するよう求められ得る。ピア予想は、最も頻繁にアクセスされたフォルダから、頻繁にアクセスされないフォルダを示す、メールフォルダの順序付けされたリストを作る「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」属性値に対して生成され得る（例えば、「ｉｎｂｏｘ」、「ｐｅｒｓｏｎａｌ」、「ｗｏｒｋ」、「ｆａｍｉｌｙ」、「ｓｐａｍ」、及び「ｔｒａｓｈ」）。下位３２．５％の属性値が「ｎｏ」投票を受信する場合、続いて「ｓｐａｍ」及び「ｔｒａｓｈ」が「ｎｏ」投票を受信する。例えば、「ｍａｉｌｂｏｘ」アプリケーションが、「ｍａｉｌａｐｐ．ｍａｉｌｂｏｘ」属性に対する、電子メールをフェッチするフォルダを判定するためのアドミッション制御要求を行う場合、続いて「ｍａｉｌａｐｐ」アプリケーションは、「ｉｎｂｏｘ」、「ｐｅｒｓｏｎａｌ」、「ｗｏｒｋ」、及び「ｆａｍｉｌｙ」フォルダに対する電子メールをフェッチし、「ｓｐａｍ」及び「ｔｒａｓｈ」フォルダに対する電子メールをフェッチしない。一部の実装では、熱デーモン３１＿１１０から「ｎｏ」投票を受信した属性又は属性値は、サンプリングデーモン３１＿１０２により維持された熱条件値が、正常な作動温度（例えば、真値）を示すために、リセットされると、通知され得る。例えば、サンプリングデーモン３１＿１０２は、「ｎｏ」投票を受信した、クライアント、属性、及び属性値を特定するデータを記憶し得る。更新された熱条件値（例えば、真）を熱デーモン３１＿１１０から受信すると、サンプリングデーモン３１＿１０２は、「ｎｏ」投票を受信したクライアントに通知を送信し、そのクライアントに、以前に拒否された属性又は属性値に対する別のアドミッション制御要求を試みるよう促し得る。一部の実装では、クライアントは、サンプリングデーモン３１＿１０２から促されることなく、アドミッション制御要求を再送し得る。例えば、クライアントは、ある期間の経過後にアドミッション制御要求をクライアントにリトライさせる内部タイマを有してよい。
アクティビティモニタ

一部の実装では、アクティビティモニタアプリケーション４０８は、アドミッション制御ボーターとして構成され得る。アクティビティモニタ３１＿４０８は、アクティビティモニタ３１＿４０８が、サンプリングデーモン３１＿１０２から投票要求を受信し、投票（例えば、ｙｅｓ、ｎｏ）応答をサンプリングデーモン３１＿１０２に提供できる、サンプリングデーモン３１＿１０２の投票ＡＰＩを使用するよう構成され得る。例えば、アクティビティモニタ３１＿４０８は、サンプリングデーモン３１＿１０２から、属性及び／又は属性値を含む投票要求を受信し得る。アクティビティモニタ３１＿４０８は、モバイルデバイス３１＿１００が、閾値量（例えば、９０％）を超えるメモリリソース又はＣＰＵリソースを使用している場合、サンプリングデーモン３１＿１０２が、属性又は属性値に関連付けられたイベントをアドミット又は許可すべきでないことを示し得る。例えば、モバイルデバイス３１＿１００がすでに、モバイルデバイス３１＿１００のメモリリソース又はＣＰＵリソースの大半を使用する多くのアプリケーション又はプロセスを実行している場合、追加アプリケーションをバックグラウンドで起動することは、残りのメモリリソースを使用し尽くすため、モバイルデバイス３１＿１００のパフォーマンスを低下させる可能性がある。従って、メモリ又はＣＰＵ使用量が閾値（例えば、７５％）を超えるとアクティビティモニタ３１＿４０８が判定すると、アクティビティモニタ３１＿４０８は、アプリケーションマネジャ３１＿１０６が追加アプリケーションを起動することを、サンプリングデーモン３１＿１０２が、「ｂｕｎｄｌｅＩｄ」属性イベントに投票することの要求を送信する際に「ｎｏ」値を返すことにより阻止し得る。モバイルデバイス３１＿１００のメモリ及び／又はＣＰＵリソースが閾値使用量未満であるとアクティビティモニタ３１＿４０８が判定する場合、アクティビティモニタ３１＿４０８は、サンプリングデーモン３１＿１０２からの投票要求に応じて、「ｙｅｓ」値を返し得る。
バックグラウンドフェッチアプリケーションを起動する

一部の実装では、アプリケーションマネジャ３１＿１０６がサンプリングデーモン３１＿１０２にアドミッション制御要求を行い、「ｙｅｓ」リプライを受信すると、アプリケーションマネジャ３１＿１０６は、特定されたアプリケーション（例えば、「ｂｕｎｄｌｅＩｄ」属性値により特定された、アプリケーション３１＿１０８）を、モバイルデバイス３１＿１００の動作環境のバックグラウンドにて呼び出し得る又は起動し得る。例えば、アプリケーション３１＿１０８はバックグラウンドにて起動され得、アプリケーション３１＿１０８が起動されたことをユーザにわからないようにする。アプリケーション３１＿１０８は続いて、ネットワーク（例えば、インターネット）経由でコンテンツサーバ３１＿４０４と通信し、ユーザに表示するために、更新されたコンテンツをダウンロードし得る。従って、ユーザが続いて、アプリケーション３１＿１０８を選択する（例えば、アプリケーションがフォアグランドに来るようにする）と、アプリケーション３１＿１０８がサーバ３１＿４０４からコンテンツをダウンロードし、アプリケーションのユーザインタフェースをリフレッシュするのを待つ必要なく、ユーザには、現在の、最新のコンテンツが提示される。

一部の実装では、モバイルデバイス３１＿１００が充電されており、Ｗｉ－Ｆｉに接続されている際に、アプリケーションマネジャ３１＿１０６は、バックグラウンドフェッチ有効アプリケーションを起動するよう構成され得る。例えば、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００が外部電源に接続され（例えば、「ｃａｂｌｅＰｌｕｇｉｎ」属性イベントに基づいて）、Ｗｉ－Ｆｉを経由してネットワーク（例えば、インターネット）に接続され（例えば、受信したイベントに基づいて）たことを判定し、信号をアプリケーションマネジャ３１＿１０６に送信し、アプリケーションマネジャ３１＿１０６に、以前の時間量（例えば、７日間）内に使用されていたフェッチ有効アプリケーションを起動させ得る。
バックグラウンドフェッチプロセス例

図３１－６は、アプリケーションを予測的に起動してバックグラウンド更新を実行するためのプロセス例３１＿６００のフロー図である。例えば、プロセス３１＿６００は、アプリケーションマネジャ３１＿１０６及びサンプリングデーモン３１＿１０２により実行され、図３１－４のコンテンツサーバ３１＿４０４などのネットワークリソースからデータ更新をフェッチするよう構成されたバックグラウンドアプリケーションをいつ起動するかを判定し得る。プロセス３１＿６００のステップに関連する追加説明は、上記図３１－４及び図３１－５を参照して見ることができる。

ステップ３１＿６０２にて、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２からアプリケーション呼び出し予想を受信し得る。例えば、アプリケーションマネジャ３１＿１０６は、モバイルデバイス３１＿１００の起動中に起動され得る。その初期化中、アプリケーションマネジャ３１＿１０６は、次の２４時間にわたり、モバイルデバイス３１＿１００のユーザにより呼び出される可能性のあるアプリケーションの予想を要求し得る。例えば、アプリケーションマネジャ３１＿１０６は、属性「ｂｕｎｄｌｅＩｄ」に対する時間的予想を要求し得る。この予想は、アプリケーションがいつ起動されるかを示し得る。例えば、２４時間は１５分ブロックに分割され得、各１５分ブロックは、その１５分ブロック中にユーザがアプリケーションを呼び出す蓋然性に関連付けられ得る。ユーザがアプリケーションを呼び出す可能性がある場合、アプリケーションマネジャ３１＿１０６に返される予想は、最大で６４の１５分ブロック時間を特定し得る。

ステップ３１＿６０４にて、アプリケーションマネジャ３１＿１０６は、アプリケーション起動予想に基づいて、タイマを設定し得る。例えば、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２によりアプリケーションマネジャ３１＿１０６に返されたアプリケーション起動予想内に特定された１５分ブロックのそれぞれに対するタイマ又はアラームを設定し得る。

ステップ３１＿６０６にて、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２に、どのアプリケーションを起動するか特定することを要求し得る。例えば、タイマが終了すると、又は、アラームが止まると、アプリケーションマネジャは、スリープ状態にあった又はサスペンドしていた場合にウェイクし、サンプリングデーモン３１＿１０２からの、現在の１５分ブロック時間に起動するアプリケーションのリストを要求し得る。サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００上で、バックグラウンドで起動されるべきアプリケーションのリストを返し得る。例えば、アプリケーションマネジャ３１＿１０６は、属性「ｂｕｎｄｌｅＩｄ」に対するピア予想を要求し得る。このピア予想は、現在の１５分タイムスロット内に、「ｂｕｎｄｌｅＩｄ」属性のどの値が最も報告される可能性があるかを示し得る（例えば、どのアプリケーションがユーザにより最も呼び出される可能性があるか）。

ステップ３１＿６０８にて、アプリケーションマネジャ３１＿１０６は、アプリケーションを起動してもよいか尋ねる要求をサンプリングデーモン３１＿１０２に送信し得る。例えば、「ｂｕｎｄｌｅＩｄ」ピア予想要求に応じてサンプリングデーモン３１＿１０２により特定された各アプリケーションに対し、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２に、そのアプリケーションを起動してもよいか否か尋ね得る。例えば、アプリケーションマネジャ３１＿１０６が起動を試みているアプリケーションに対応する「ｂｕｎｄｌｅＩｄ」属性の特定の値でのアドミッション制御をサンプリングデーモン３１＿１０２が実行することを、アプリケーションマネジャ３１＿１０６は要求し得る。サンプリングデーモン３１＿１０２は、アドミッション制御要求から、アプリケーションを起動してもよい場合に「ｙｅｓ」を返し、アプリケーションを起動してはよくない場合に「ｎｏ」を返し、又はアプリケーションを起動してはならない場合に「ｎｅｖｅｒ」を返し得る。

ステップ３１＿６１０にて、アプリケーションマネジャ３１＿１０６はアプリケーションを起動し得る。例えば、サンプリングデーモン３１＿１０２が「ｏｋ」（例えば、ｏｋ、ｙｅｓ、真などの）応答をアドミッション制御要求に返す場合、アプリケーションマネジャ３１＿１０６は、モバイルデバイス３１＿１００のバックグラウンドプロセスとしてアプリケーションを起動する。サンプリングデーモン３１＿１０２が「ｎｏ」又は「ｎｅｖｅｒ」応答をアドミッション制御要求に返す場合、アプリケーションマネジャ３１＿１０６はアプリケーションを起動しない。

ステップ３１＿６１２にて、アプリケーションマネジャ３１＿１０６は、アプリケーション起動通知をサンプリングデーモン３１＿１０２に送信し得る。例えば、アプリケーションマネジャ３１＿１０６は、「ｂｕｎｄｌｅＩｄ」開始イベントをサンプリングデーモン３１＿１０２に送信し、起動されたアプリケーションの実行を記録し得る。

ステップ３１＿６１４にて、アプリケーションマネジャ３１＿１０６は、起動されたアプリケーションが終了したことを検出し得る。例えば、アプリケーションマネジャ３１＿１０６は、起動されたアプリケーションがいつ、モバイルデバイス３１＿１００上で実行されなくなるかを判定し得る。

ステップ３１＿６１６にて、アプリケーションマネジャ３１＿１０６は、アプリケーション終了通知をサンプリングデーモン３１＿１０２に送信し得る。例えば、アプリケーションマネジャ３１＿１０６は、「ｂｕｎｄｌｅＩｄ」終了イベントをサンプリングデーモン３１＿１０２に送信し、アプリケーションの終了を記録し得る。

図３１－７は、モバイルデバイス３１＿１００上でアプリケーションをいつ起動するかを判定するためのプロセス例３１＿７００のフロー図である。例えば、図３１－４を参照して上に詳述するように、プロセス３１＿７００は、アプリケーション使用統計（例えば、「ｂｕｎｄｌｅＩｄ」属性イベントデータ）、データ並びにエネルギ割当量、及び、モバイルデバイス動作並びに環境条件に基づいて、アプリケーションをいつ起動するか、どのアプリケーションが起動されるべきか、及び、アプリケーションを起動してもよいか、を判定するために使用され得る。

ステップ３１＿７０２にて、サンプリングデーモン３１＿１０２は、アプリケーション起動予想要求をアプリケーションマネジャ３１＿１０６から受信し得る。例えば、アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２からの、次の２４時間にわたる、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想を要求し得る。２４時間が経過すると、アプリケーションマネジャ３１＿１０６は、続く２４時間にわたる、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想を要求し得る。例えば、アプリケーションマネジャ３１＿１０６は、２４時間毎の、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想を要求し得る。

ステップ３１＿７０４にて、サンプリングデーモン３１＿１０２は、アプリケーション起動予想を判定し得る。例えば、アプリケーション起動予想（例えば、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想）は、ユーザ開始アプリケーション起動が、２４時間中にいつ発生する可能性があるかの予測に使用され得る。２４時間は、１５分の時間ブロックに分割され得る。各１５分の時間ブロック（例えば、２４時間内には、１５分の時間ブロックが９６ある）に対し、サンプリングデーモン３１＿１０２は、図３１－４を参照して上述するように、過去ユーザ呼び出し統計（例えば、「ｂｕｎｄｌｅＩｄ」開始イベント）を使用し、ユーザ開始アプリケーション起動が１５分の時間ブロック内に発生する蓋然性を判定し得る。

ステップ３１＿７０６にて、サンプリングデーモン３１＿１０２は、アプリケーション起動予想をアプリケーションマネジャ３１＿１０６に送信し得る。例えば、サンプリングデーモン３１＿１０２は、ユーザ開始アプリケーション起動の、最も高い、非ゼロ蓋然性を有する、最大で６４の１５分ブロックを選択し得る。選択された１５分ブロックのそれぞれは、１５分ブロックに対する開始時間（例えば、午後１２：４５）により特定され得る。サンプリングデーモン３１＿１０２は、１５分ブロック識別子のリストをアプリケーションマネジャ３１＿１０６に、アプリケーション起動予想（例えば、「ｂｕｎｄｌｅＩｄ」属性に対する時間的予想）として送信し得る。

ステップ３１＿７０８にて、サンプリングデーモン３１＿１０２は、現在時刻にどのアプリケーションを起動するかについての要求を受信し得る。例えば、アプリケーションマネジャ３１＿１０６は、現在時刻に又はその前後にどのアプリケーションが起動されるべきかをサンプリングデーモン３１＿１０２が判定することについての要求をサンプリングデーモン３１＿１０２に送信し得る。例えば、この要求は、現在の１５分タイムスロットにわたる、「ｂｕｎｄｌｅＩｄ」属性に対するピア予想の要求であり得る。

ステップ３１＿７１０にて、サンプリングデーモン３１＿１０２は、現在時刻にわたり、過去イベントデータに基づいて、アプリケーションをスコアし得る。サンプリングデーモン３１＿１０２は、サンプリングデーモン３１＿１０２により収集された過去ユーザ開始アプリケーション起動データ（例えば、「ｂｕｎｄｌｅＩｄ」属性開始イベントデータ）に基づいて、ユーザが近い将来に起動する可能性のあるアプリケーションはどれかを判定し得る。サンプリングデーモン３１＿１０２は、図３１－４及び図３１－５を参照して上述するように、最近のアプリケーション起動データ、日毎のアプリケーション起動データ、及び／又は週毎のアプリケーション起動データを使用し、ユーザが現在時刻に又はその前後にアプリケーションを呼び出した過去の可能性に基づいて、アプリケーションをスコアし得る。

ステップ３１＿７１２にて、サンプリングデーモン３１＿１０２は、アプリケーション及びアプリケーションスコアをアプリケーションマネジャ３１＿１０６に送信し得る。例えば、サンプリングデーモン３１＿１０２は、最高スコア（例えば、ユーザにより呼び出される最も高い蓋然性）を有するアプリケーション（例えば、「ｂｕｎｄｌｅＩｄ」属性値）の数（例えば、３）を選択し、アプリケーションマネジャ３１＿１０６に送信し得る。サンプリングデーモン３１＿１０２は、以前の期間（例えば、以前の５分）内に起動されたアプリケーションを除外し得る。サンプリングデーモン３１＿１０２は、図３１－４を参照して上述するように、最高スコアのアプリケーション及びそれぞれのスコアを特定する情報をアプリケーションマネジャ３１＿１０６に送信し得る。

ステップ３１＿７１４にて、サンプリングデーモン３１＿１０２は、アプリケーションを起動してもよいか否かを判定することの要求をアプリケーションマネジャ３１＿１０６から受信し得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーション（例えば、「ｂｕｎｄｌｅＩｄ」値）を特定するアドミッション制御要求を受信し得る。

ステップ３１＿７１６にて、サンプリングデーモン３１＿１０２は、現在のモバイルデバイス条件及び割当量がアプリケーション起動を許可すると判定し得る。例えば、アドミッション制御要求に応じて、サンプリングデーモン３１＿１０２は、図３１－４を参照して上に詳述するように、システムワイドデータ並びにエネルギ割当量、属性割当量、及びボーターフィードバックをチェックし、アプリケーションが、モバイルデバイス３１＿１００上のバックグラウンドタスクとして起動されるべきか否かを判定し得る。

ステップ３１＿７１８にて、サンプリングデーモン３１＿１０２は、特定されたアプリケーションを起動してもよいことを示すリプライをアプリケーションマネジャ３１＿１０６に送信し得る。例えば、条件がバックグラウンドアプリケーション起動に対して良好である場合、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて、「ｙｅｓ」値（例えば、ｏｋ、ｙｅｓ、真など）をアプリケーションマネジャ３１＿１０６に返し得、アプリケーションマネジャ３１＿１０６が、特定されたアプリケーションを起動し得るようにする。
短期トレンド

一部の実装では、サンプリングデーモン３１＿１０２は、属性がいつトレンドとなったかを検出するよう構成され得る。例えば、クライアントアプリケーションは、特定の属性における対象を、サンプリングデーモン３１＿１０２に登録してよい。その特定の属性がトレンドであることをサンプリングデーモン３１＿１０２が検出すると、サンプリングデーモン３１＿１０２は、その特定の属性がトレンドであることをクライアントに通知し得る。

例えば、アプリケーションマネジャ３１＿１０６は、「ｂｕｎｄｌｅＩｄ」属性における対象（又は、「ｂｕｎｄｌｅＩｄ」属性の特定の値）を登録し得る。「ｂｕｎｄｌｅＩｄ」属性（又は、その値）がトレンドであることをサンプリングデーモン３１＿１０２が判定すると、サンプリングデーモン３１＿１０２は、アプリケーションマネジャ３１＿１０６にそのトレンドを通知し得、アプリケーションマネジャ３１＿１０６が、モバイルデバイス３１＿１００上のバックグラウンドにてそのトレンドアプリケーションを予測的に起動し得るようにする。例えば、あるアプリケーションがモバイルデバイス３１＿１００のユーザにより繰り返し呼び出されている場合、そのアプリケーションはトレンドである。一部の場合には、トレンドアプリケーションは新たなアプリケーションであるか、又は、トレンドの前に、上述する「ｂｕｎｄｌｅＩｄ」属性ピア予想内に含まれない可能性のある、稀に使用されるアプリケーションである。従って、このトレンドアプリケーションは、上述するアプリケーション起動予想方法を使用して最新に維持されなくともよい。

属性トレンド検出の目的は、サンプリングデーモン３１＿１０２に繰り返し報告される属性（例えば、属性イベント）を検出することであり、より小さいケイデンスを報告することにおいて誤差が生じる、属性が起動されるおおよそのケイデンス（例えば、定期性）を判定することである。サンプリングデーモン３１＿１０２に繰り返し報告される属性は、「トレンド」と呼ばれる。この判定されたケイデンスは続いて、サンプリングデーモン３１＿１０２クライアントにより使用され、トレンド属性に関連付けられた次のイベントを見越して、機能又は作動を実行し得る。

例えば、この判定されたケイデンスは、上述するように、アプリケーションマネジャ３１＿１０６により使用され、アプリケーションマネジャ３１＿１０６をトリガーするタイマを設定し、トレンドアプリケーションがバックグラウンドで起動され得、ユーザがアプリケーションを呼び出すと、アプリケーションが更新されるようにする。例えば、アプリケーションに対してケイデンスが５分である場合、アプリケーションマネジャ３１＿１０６は、４分毎に終了するタイマを設定し、アプリケーションマネジャ３１＿１０６にアプリケーションを起動させ得、更新されたコンテンツをアプリケーションが受信し、ユーザにより再度呼び出される前に、アプリケーションのインタフェースを更新し得るようにする。

一部の実装では、本セクションに説明するトレンド検出メカニズムは、アプリケーション起動を超えて、繰り返されるソフトウェア又はネットワーク通知、アプリケーションのクラッシュなどの他のシステムイベントトレンドの検出に使用され得る。例えば、クライアントは、いずれの属性又は属性値における対象を登録し得、対象の属性がトレンドである場合の通知を受信し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、多くの属性の挙動の追跡に使用され得るトレンドテーブルを維持し得る。このトレンドテーブルは、属性値識別フィールド（ＡＴＴＩＤ）、状態フィールド（ＳＴＡＴＥ）、最終起動タイムスタンプ（ＬＬＴ）、起動間の時間量を示す起動間ケイデンス（ＩＬＣ）、及び信頼性フィールド（Ｃ）を含み得る。

図３１－８は、トレンドテーブル内のエントリ（例えば、アプリケーション）に対する状態遷移を示すフロー図３１＿８００である。初期的に、ステップ３１＿８０２にて、このトレンドテーブルは、ＡＴＴＩＤ、ＬＬＴ、ＩＬＣ、及びＣフィールドが空であり（例えば、非適用（Ｎ／Ａ））、ＳＴＡＴＥが「（無効）ｉｎｖａｌｉｄ」（Ｉ）に設定されている、空のエントリ（例えば、記録）を含み得る。時間ｔにて属性イベントが報告されると、利用可能なエントリ（例えば、状態Ｉにあるエントリ）についてトレンドテーブルがスキャンされる。潜在的な無効エントリの中から、使用するエントリを選択するために、様々な方法が使用され得る。例えば、ランダム無効エントリが選択され得る。あるいは、トレンドテーブル内の全ての空のエントリが連続して維持されるよう、無効エントリが選択され得る。無効エントリが存在しない場合、一時（Ｔ）状態にある最も古いエントリ（又は、ランダムエントリ）が、新たに起動されたアプリケーションを追跡するために選択され得る。Ｉ又はＴ状態エントリが存在しない場合、最も古い、新規（Ｎ）の状態エントリが、新たに報告された属性イベントを追跡するために選択され得る。

ステップ３１＿８０４にて、トレンドテーブルエントリが選択されると、新たに報告された属性イベントを追跡するための、選択されたエントリのＳＴＡＴＥフィールドが新規（Ｎ）に設定され得、ＡＴＴＩＤが、新たに報告された属性の属性値に設定され得、ＬＬＴフィールドが、現在時刻ｔ（例えば、ウォールクロック時間）に設定され得、及び、ＩＬＣ及びＣフィールドが、所定の最小値ＩＬＣ＿ＭＩＮ（例えば、１分）及びＣ＿ＭＩＮ（例えば、０）に設定される。

ステップ３１＿８０６にて、時間ｔ'での同じ属性イベントの次の報告にて、属性に対するテーブル内のエントリが、それが依然として存在し、排除されていなければ、見つけられる（例えば、別の属性の追跡のために選択される）。エントリのＳＴＡＴＥが一時（Ｔ）に設定され、ＩＬＣが、ＬＬＴと現在のシステム時間（例えば、ｔ'～ｔ又はｔ'～ＬＬＴ）との間の差に設定され、Ｃフィールドがインクリメントされる（例えば、所定の値Ｃ＿ＤＥＬＴＡにて）。あるいは、ＩＬＣフィールドが、実行平均などの、その旧値及び新値のあるの他の関数に設定され得る。

ステップ３１＿８０８にて、時間ｔ''での同じ属性イベントの次の報告にて、属性に対するテーブル内のエントリが、それが依然として存在し、排除されていなければ、見つけられる（例えば、別の属性の追跡のために選択される）。エントリのＳＴＡＴＥが依然として、一時（Ｔ）に設定され得、ＩＬＣが、ＬＬＴと現在の（例えば、ウォール）クロック時間（例えば、ｔ''～ｔ'又はｔ''～ＬＬＴ）との間の差に設定され、Ｃフィールドが再度インクリメントされる（例えば、所定の値Ｃ＿ＤＥＬＴＡにて）。

ステップ３１＿８１０にて、属性イベントのいくつかの報告の後、トレンドテーブルエントリのＣ値が閾値（例えば、Ｃ＿ＨＩＧＨＴＨＲＥＳＨＯＬＤ）に到達すると（例えば、等しくなると）、ステップ３１＿８１１にて、属性エントリの状態がＳＴＡＴＥ＝Ａに変更され得る。ステップ３１＿８１０にて、トレンドテーブルエントリのＣ値が閾値（例えば、Ｃ＿ＨＩＧＨＴＨＲＥＳＨＯＬＤ）に到達しないと、エントリの値は、ステップ３１＿８０８に従って更新され得る。

状態「Ａ」にある間に属性イベントが報告される時はいつでも、最後の報告と現在の報告の時間との間の時間がいくらかの時間量内にある場合（例えば、ＩＬＣ＿ＥＰＳＩＬＯＮ＝５分）、続いて属性エントリの信頼性（Ｃ）フィールドが、所定の最大値（例えば、Ｃ＿ＭＡＸ）に到達するまでインクリメントされる。トレンドテーブル内の属性エントリがアクティブ（Ａ）状態にあると、エントリのＩＬＣ値が、起動率（例えば、ケイデンス）の予測として使用され得、エントリのＡＴＴＩＤが、トレンド属性値の特定に使用され得る。

一部の実装では、サンプリングデーモン３１＿１０２は、属性値（ＡＴＴＩＤ）及びケイデンス値（ＩＬＣ）をクライアントに送信し得、クライアントが、属性値に関連付けられた次のイベントを見越して、一部のアクション又は機能を実行し得るようにする。例えば、上述するように、属性値及びケイデンス値は、アプリケーションマネジャ３１＿１０６に送信され得、アプリケーションマネジャ３１＿１０６が、アプリケーションのユーザ呼び出しを見越して、特定されたアプリケーション（例えば、ＡＴＴＩＤ、「ｂｕｎｄｌｅＩｄ」属性値）をバックグラウンドで起動し得るようにし、ユーザがアプリケーションを起動する前に、更新されたコンテンツをアプリケーションが受信し得るようにする。例えば、アプリケーションマネジャ３１＿１０６は、ケイデンス値に基づいて、アプリケーションマネジャ３１＿１０６をウェイクするタイマを開始し、ユーザがアプリケーションを呼び出すことを見越して、アプリケーションを起動し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、検出された属性トレンドに基づく、予期される次の属性イベントの発生を、クライアントに通知し得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーションマネジャ３１＿１０６によりトレンドアプリケーションが起動されるべきであることを示す信号又は通知をアプリケーションマネジャ３１＿１０６に送信し得る。アプリケーションマネジャ３１＿１０６は、サンプリングデーモン３１＿１０２にアプリケーション識別子（例えば、「ｂｕｎｄｌｅＩｄ」属性値）を送信することにより、アプリケーションにおける対象を登録し得る。サンプリングデーモン３１＿１０２は、上述するように、ユーザ呼び出しに対してアプリケーションを監視し（例えば、報告された「ｂｕｎｄｌｅＩｄ」開始イベントに基づいて）、アプリケーションがトレンドであるか否かを判定し得る。アプリケーションがトレンドである場合、サンプリングデーモン３１＿１０２は、上述するように、呼び出しのケイデンスを判定し、通知又は信号をアプリケーションマネジャ３１＿１０６に、そのケイデンスに基づいて判定された時間に送信し得る。例えば、ケイデンスが４分である場合、サンプリングデーモン３１＿１０２は、信号をアプリケーションマネジャ３１＿１０６に、３分毎に送信し（例えば、次のイベントの発生前のいくらかの期間）、アプリケーションマネジャ３１＿１０６に、アプリケーションを起動させ得る。ケイデンスが６分に変更になった場合、サンプリングデーモン３１＿１０２は、ケイデンスの変化を検出し、アプリケーションマネジャ３１＿１０６がいつ信号を送信されるかを調整し得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーションマネジャ３１＿１０６に信号を送信し、３分毎ではなく、５分毎にアプリケーションを起動し、減少したケイデンスに対して調整し得る（例えば、呼び出し間の期間の延長）。

いずれの理由による属性トレンドテーブルの各検査にて（例えば、新たなエントリの追加、既存のエントリの更新など）、ＳＴＡＴＥ＝Ｔ又はＳＴＡＴＥ＝Ａにある、最後の起動からの時間がそれらのＩＬＣよりもＩＬＣ＿ＥＰＳＩＬＯＮだけ長い全てのエントリは、それらのＣ値がデクリメントされる。その時点でのＣ値が最小閾値（例えば、Ｃ＿ＬＯＷＴＨＲＥＳＨＯＬＤ）を下回るいずれのエントリは、格下げとなる。エントリは、例えば、状態Ａから状態Ｔに、又は、状態Ｔから状態Ｉに格下げされ得る。

一部の実装では、上述するトレンド検出メカニズムは、アプリケーション呼び出し又は起動以外のトレンドイベントの検出に使用され得る。例えば、上述するトレンド検出方法及びトレンドテーブルは、モバイルデバイス３１＿１００上のいずれの再来性イベント（例えば、いずれの属性イベント）の検出及び追跡に使用され得る。トレンドイベントは、スクリーンタッチ、ネットワーク接続、アプリケーションの不具合、ネットワーク侵入の発生、及び／又は、サンプリングデーモン３１＿１０２に報告又は信号が送信され得るいずれの他のイベントを含み得る。
プッシュ通知

図３１－９は、プッシュ通知をモバイルデバイス３１＿１００に提供するためのシステムを示すブロック図３１＿９００である。一部の実装では、モバイルデバイス３１＿１００は、プッシュ通知を受信するよう構成され得る。例えば、プッシュ通知は、プッシュプロバイダ３１＿９０２により開始され、モバイルデバイス３１＿１００上で実行されるプッシュサービスデーモン３１＿９０４に、プッシュ通知サーバ３１＿９０６を通して送信されるメッセージであり得る。

一部の実装では、プッシュプロバイダ３１＿９０２は、アプリケーション３１＿９０８によりモバイルデバイス３１＿１００のユーザに提示されたユーザ許可要求を通して、プッシュ通知をモバイルデバイス３１＿１００に送信する許可を受信し得る。例えば、プッシュプロバイダ３１＿９０２は、アプリケーション３１＿９０８を作成した（例えば、プログラムした、開発した）同じベンダにより所有、運用、及び／又は維持されるサーバであり得る。アプリケーション３１＿９０８が、プッシュプロバイダ３１＿９０２に対してプッシュ通知をモバイルデバイス３１＿１００に送信する許可を要求するユーザインタフェースをモバイルデバイス３１＿１００上に提示し、プッシュ通知が許可されたことをユーザが示すと、プッシュプロバイダ３１＿９０２は、プッシュ通知をモバイルデバイス３１＿１００（例えば、プッシュサービスデーモン３１＿９０４）に送信する許可をユーザから受信し得る。例えば、ユーザは、アプリケーション３１＿９０８により提示されたユーザインタフェース上のボタンを選択し、プッシュプロバイダ３１＿９０２及び／又はアプリケーション３１＿９０８に対して、プッシュ通知が許可されたことを示し得る。プッシュプロバイダ３１＿９０２は続いて、モバイルデバイス３１＿１００を特定し、プッシュ通知のモバイルデバイス３１＿１００への経路決定に使用され得るデバイストークンを受信し得る。例えば、プッシュ通知サーバ３１＿９０６は、デバイストークンをプッシュ通知と共に受信し、そのデバイストークンを、どのモバイルデバイス３１＿１００がプッシュ通知を受信すべきかを判定することに使用し得る。

一部の実装では、モバイルデバイス３１＿１００は、許可されたプッシュアプリケーションを特定する情報をプッシュ通知サーバ３１＿９０６に送信し得る。例えば、モバイルデバイス３１＿１００は、プッシュ通知フィルタ３１＿９１４と、モバイルデバイス３１＿１００に対するデバイストークンと、を含むメッセージ３１＿９２６を、プッシュ通知サーバ３１＿９０６に送信し得る。プッシュ通知サーバ３１＿９０６は、デバイストークンのマッピング（例えば、モバイルデバイス３１＿１００に対する識別子）を、プッシュ通知サーバ３１＿９０６によりサービスされた各モバイルデバイスに対するプッシュフィルタ３１＿９１４に記憶し得る。プッシュフィルタ３１＿９１４は、例えば、モバイルデバイス３１＿１００上でプッシュ通知を受信する許可を受信したアプリケーションを特定する情報を含み得る。

一部の実装では、プッシュフィルタ３１＿９１４は、プッシュ通知サーバ３１＿９０６により使用され、モバイルデバイス３１＿１００のユーザにより許可されていないアプリケーションへのプッシュ通知をフィルタし得る（例えば、送信を阻止し得る）。プッシュプロバイダ３１＿９０２によりプッシュ通知サーバ３１＿９０６に送信された各プッシュ通知は、プッシュプロバイダ３１＿９０２及びモバイルデバイス３１＿１００（例えば、デバイストークン）に関連付けられたアプリケーション３１＿９０８を特定する情報（例えば、識別子）を含み得る。

通知サーバ３１＿９０６がプッシュ通知を受信すると、通知サーバ３１＿９０６は、モバイルデバイス識別情報（例えば、デバイストークン）を使用し、受信したプッシュ通知にどのプッシュフィルタ３１＿９１４を適用するかを判定し得る。通知サーバ３１＿９０６は、プッシュ通知内のアプリケーション識別情報を、特定されたモバイルデバイスに対するプッシュフィルタ３１＿９１４に対して比較し、プッシュプロバイダ３１＿９０２に関連付けられ、プッシュ通知内に特定されたアプリケーションが、プッシュフィルタ３１＿９１４内で特定されているかを判定し得る。プッシュ通知に関連付けられたアプリケーションがプッシュフィルタ３１＿９１４内に特定されている場合、続いて通知サーバ３１＿９０６は、プッシュプロバイダ３１＿９０２から受信したプッシュ通知をモバイルデバイス３１＿１００に送信し得る。プッシュ通知内に特定されたアプリケーションが、プッシュフィルタ３１＿９１４内に特定されていない場合、続いて通知サーバは、プッシュプロバイダ３１＿９０２から受信したプッシュ通知をモバイルデバイス３１＿１００に送信せず、そのプッシュ通知を削除し得る。
ノンウェイキングプッシュ通知

一部の実装では、通知サーバ３１＿９０６は、高優先プッシュ通知及び低優先プッシュ通知を処理するよう構成され得る。例えば、プッシュプロバイダ３１＿９０２は、高優先プッシュ通知３１＿９１０及び／又は低優先プッシュ通知３１＿９１２をプッシュ通知サーバ３１＿９０６に送信し得る。例えば、プッシュ通知サーバ３１＿９０６及びモバイルデバイス３１＿１００に送信されたプッシュ通知内に含まれるデータ内にプッシュ通知の優先度を指定することにより、プッシュプロバイダ３１＿９０２は、プッシュ通知を高優先度又は低優先度として識別し得る。

一部の実装では、プッシュ通知サーバ３１＿９０６は、低優先プッシュ通知３１＿９１２を、高優先プッシュ通知３１＿９１０とは異なって処理し得る。例えば、プッシュ通知サーバ３１＿９０６は、高優先プッシュ３１＿９１０内に含まれるアプリケーション識別情報を、プッシュフィルタ３１＿９１４内の許可されたアプリケーション識別情報と比較し、高優先プッシュ通知３１＿９１０が、モバイルデバイス３１＿１００に送信され得るかを判定するよう構成され得る。高優先プッシュ通知３１＿９１０内のアプリケーション識別情報が、プッシュフィルタ３１＿９１４内の許可されたアプリケーション識別子と一致する場合、続いてプッシュ通知サーバ３１＿９０６は、高優先プッシュ通知をモバイルデバイス３１＿１００に送信し得る。高優先プッシュ通知３１＿９１０内のアプリケーション識別情報が、プッシュフィルタ３１＿９１４内の許可されたアプリケーション識別子と一致しない場合、続いてプッシュ通知サーバ３１＿９０６は、高優先プッシュ通知をモバイルデバイス３１＿１００に送信しない。

一部の実装では、プッシュ通知サーバ３１＿９０６は、低優先プッシュ通知の配信を遅らせるよう構成され得る。例えば、モバイルデバイス３１＿１００が、プッシュ通知をプッシュ通知サーバ３１＿９０６から受信すると、プッシュ通知の受領により、モバイルデバイス３１＿１００にウェイクさせる（例えば、スリープ状態又は低電力状態にあった場合）。モバイルデバイス３１＿１００がウェイクすると、モバイルデバイス３１＿１００は、バッテリを消費し、セルラーデータを使用し、モバイルデバイス３１＿１００を熱くするか、又は、モバイルデバイス３１＿１００に影響する様々なサブシステム及びプロセッサをオンにする。モバイルデバイス３１＿１００への低優先プッシュ通知の配信を阻止又は遅延することにより、モバイルデバイス３１＿１００は例えば、ネットワーク（例えば、セルラーデータ）及びシステム（例えば、バッテリ）リソースを節約し得る。

一部の実装では、プッシュ通知フィルタ３１＿９１４は、ウェイクリスト３１＿９１６及びノーウェイクリスト３１＿９１８を含み得る。ウェイクリスト３１＿９１６は、モバイルデバイス３１＿１００に低優先プッシュ通知が配信されるべきアプリケーションを特定し得る。一部の実装では、アプリケーションが、モバイルデバイス３１＿１００にてプッシュ通知を受信することを許可されると、デフォルトで、アプリケーション識別情報がウェイクリスト３１＿９１４に追加される。ノーウェイクリスト３１＿９１８は、低優先プッシュ通知が遅延されるべき、許可されたアプリケーションを特定し得る。ノーウェイクリスト３１＿９１８をポピュレートする、及び／又は、ウェイクリスト３１＿９１６及びノーウェイクリスト３１＿９１８を操作するための特定のメカニズムを、プッシュ通知開始バックグラウンド更新を説明する場合に、以下に詳述する。一部の実装では、高優先プッシュ通知内に特定されたアプリケーションが、プッシュフィルタ３１＿９１４内に特定される限りにおいては、高優先プッシュ通知はプッシュ通知サーバ３１＿９０６にて遅延されず、モバイルデバイス３１＿１００に配信される（例えば、ウェイクリスト３１＿９１４及び／又はノーウェイクリスト３１＿９１８）。

一部の実装では、プッシュ通知サーバ３１＿９０６が低優先プッシュ通知３１＿９１２を受信すると、プッシュ通知サーバ３１＿９０６は、低優先プッシュ通知３１＿９１２内のアプリケーション識別子を、ウェイクリスト３１＿９１６及び／又はノーウェイクリスト３１＿９１８と比較し得る。例えば、低優先プッシュ通知３１＿９１２内のアプリケーション識別情報が、ウェイクリスト３１＿９１６内の許可されたアプリケーション識別子と一致する場合、低優先プッシュ通知３１＿９１２は、通知メッセージ３１＿９２０にて、モバイルデバイス３１＿１００に配信される。

一部の実装では、ノーウェイクリスト３１＿９１８内に特定されたアプリケーションに関連付けられた低優先プッシュ通知の配信は遅延され得る。例えば、低優先プッシュ通知３１＿９１２内に特定されたアプリケーションもまた、ノーウェイクリスト３１＿９１８内に特定されている場合、続いて低優先プッシュ通知３１＿９１２は、プッシュ通知データストア３１＿９２２に記憶され、モバイルデバイス３１＿１００にすぐに配信され得ない。一部の実装では、プッシュ通知（高優先又は低優先）により特定されたモバイルデバイス３１＿１００が、プッシュ通知サーバ３１＿９０６に現在接続されていない場合、遮断されたモバイルデバイス３１＿１００に対するプッシュ通知は、モバイルデバイス３１＿１００への後の配信のために、プッシュ通知データストア３１＿９２２に記憶され得る。

一部の実装では、プッシュデータストア３１＿９２２に記憶されたプッシュ通知は、記憶されたプッシュ通知に関連付けられたアプリケーション識別子が、ノーウェイクリスト３１＿９１８からウェイクリスト３１＿９１６に移動されるまで、又は、ネットワーク接続が、プッシュ通知サーバ３１＿９０６とモバイルデバイス３１＿１００との間で確立されるまで、プッシュデータストア３１＿９２２内に維持される。

例えば、別の（高優先又は低優先）プッシュ通知が、モバイルデバイス３１＿１００に配信される際に、又は、モバイルデバイス３１＿１００が、他のトランスミッション３１＿９２４（例えば、状態メッセージ、ハートビートメッセージ、生存メッセージなど）をプッシュ通知サーバ３１＿９０６に送信する際に、プッシュ通知サーバ３１＿９０６とモバイルデバイス３１＿１００との間のネットワーク接続が確立され得る。例えば、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００がある期間（例えば、５分）にわたってアクティブになることを示すメッセージ３１＿９２４をプッシュ通知サーバ３１＿９０５に送信し得、プッシュ通知サーバ３１＿９０６は、受信した全てのプッシュ通知をモバイルデバイス３１＿１００に、指定されたアクティブ期間中に送信し得る。一部の実装では、ネットワーク接続が、モバイルデバイス３１＿１００とプッシュ通知サーバ３１＿９０６との間で確立されると、プッシュ通知ストア３１＿９２２に記憶された全てのプッシュ通知が、モバイルデバイス３１＿１００に配信される。例えば、プッシュ通知データストア３１＿９２２に記憶されたプッシュ通知は、モバイルデバイス３１＿１００とプッシュ通知サーバ３１＿９０６との間の他のトランスミッションにより作成された接続を通して送信され得る。

一部の実装では、モバイルデバイス３１＿１００は、プッシュ通知サーバ３１＿９０６との２つの異なる通信チャネルを確立し得る。例えば、２つの通信チャネルは、同時に又は異なる時間に確立され得る。モバイルデバイス３１＿１００は、例えば、プッシュ通知サーバ３１＿９０６へのセルラーデータ接続及び／又はＷｉ－Ｆｉ接続を有し得る。一部の実装では、モバイルデバイス３１＿１００は、各通信チャネルに対する異なるプッシュフィルタ３１＿９１４を生成し、これらをプッシュ通知サーバ３１＿９０６に送信し得る。例えば、セルラーデータ接続は、高優先及び低優先プッシュ通知をいつ、セルラーデータ接続を経由して送信するかを判定するために、プッシュフィルタ３１＿９１４の第１のセットに関連付けられ得る。Ｗｉ－Ｆｉデータ接続は、高優先及び低優先プッシュ通知をいつ、Ｗｉ－Ｆｉデータ接続を経由して送信するかを判定するために、セルラーデータプッシュフィルタと同じ又は異なるプッシュフィルタ３１＿９１４の第２のセットに関連付けられ得る。プッシュ通知サーバ３１＿９０６がプッシュ通知を受信すると、プッシュ通知サーバは、プッシュ通知内に特定されたアプリケーションを、プッシュ通知をモバイルデバイス３１＿１００に送信するためにプッシュ通知サーバ３１＿９０６が使用する通信チャネル（例えば、Ｗｉ－Ｆｉ、セルラー）に対するプッシュ通知フィルタと比較し得る。
プッシュ開始バックグラウンド更新

一部の実装では、モバイルデバイス３１＿１００によるプッシュ通知の受領は、モバイルデバイス３１＿１００上でのアプリケーションのバックグラウンド更新をトリガーし得る。例えば、モバイルデバイス３１＿１００（例えば、プッシュサービスデーモン３１＿９０４）が、プッシュ通知メッセージ３１＿９２０をプッシュ通知サーバ３１＿９０６から受信すると、プッシュサービスデーモン３１＿９０４は、プッシュ通知メッセージ３１＿９２０内のアプリケーション識別子を、モバイルデバイス３１＿１００上に記憶されたプッシュフィルタ３１＿９２８と比較し、プッシュ通知メッセージ３１＿９２０が、プッシュ通知サーバ３１＿９０６により適切に配信されたか、又は（例えば、配信されず）フィルタされるべきかを判定し得る。例えば、プッシュフィルタ３１＿９２８、ウェイクリスト３１＿９３０、及びノーウェイクリスト３１＿９３２はそれぞれ、プッシュフィルタ３１＿９１４、ウェイクリスト３１＿９１６、及びノーウェイクリスト３１＿９１８に対応し得る。一部の実装では、プッシュサービスデーモン３１＿９０４が、プッシュ通知メッセージ３１＿９２０はモバイルデバイス３１＿１００に配信されるべきではないと判定する場合、プッシュ通知メッセージ３１＿９０２は削除される。
低優先プッシュ通知

一部の実装では、モバイルデバイス３１＿１００により受信されたプッシュ通知メッセージ３１＿９２０は、低優先プッシュ通知を含み得る。例えば、低優先プッシュ通知は、プッシュ通知に関連付けられたアプリケーションに対するコンテンツ更新が利用可能であることを示し得る。従って、低優先プッシュ通知が、アプリケーション３１＿９０８の起動を引き起こすと、アプリケーション３１＿９０８は、更新されたコンテンツを１つ以上のネットワークリソース（例えば、プッシュプロバイダ３１＿９０２）からダウンロードし得る。

一部の実装では、プッシュサービスデーモン３１＿９０４が、モバイルデバイス３１＿１００上のアプリケーション（例えば、アプリケーション３１＿９０８）に関連付けられた低優先プッシュ通知を受信すると、プッシュサービスデーモン３１＿９０４は、受信した低優先プッシュ通知に関連付けられたアプリケーションを起動してもよいか、サンプリングデーモン３１＿１０２に尋ね得る。例えば、プッシュサービスデーモン３１＿９０４は、受信した低優先プッシュ通知に関連付けられたアプリケーション（例えば、「ｂｕｎｄｌｅＩｄ」属性値）に対する識別子をサンプリングデーモン３１＿１０２に送信することにより、サンプリングデーモン３１＿１０２にアドミッション制御を実行するよう要求し得る。サンプリングデーモン３１＿１０２は、図３１－４を参照して上述するように、データ割当量、エネルギ割当量、属性割当量、及びボーターフィードバックをチェックすることにより、アドミッション制御を実行し得る。サンプリングデーモン３１＿１０２は、アドミッション制御プロセスの結果に基づく、低優先プッシュ通知により特定されたアプリケーションを起動してもよいか否かを示す値をプッシュサービスデーモン３１＿９０４に返し得る。

一部の実装では、アドミッション制御要求から返された値が「ｙｅｓ」で、アプリケーションを起動してもよいことを示す場合、プッシュサービスデーモン３１＿９０４は、低優先プッシュ通知をアプリケーションマネジャ３１＿１０６に送信し、アプリケーションマネジャ３１＿１０６は、アプリケーション（例えば、アプリケーション３１＿９０８）を呼び出し得る。アプリケーション３１＿９０８は続いて、ネットワーク（例えば、インターネット）を経由してプッシュプロバイダ３１＿９０２と通信し、更新されたコンテンツをプッシュプロバイダ３１＿９０２から受信し得る。

一部の実装では、アドミッション制御要求から返された値が「ｎｏ」で、アプリケーションを起動してはよくないことを示す場合、プッシュサービスデーモン３１＿９０４は、低優先プッシュ通知をプッシュ通知データストア３１＿９３４に記憶する。例えば、低優先プッシュ通知を記憶する時、プッシュサービスデーモン３１＿９０４は、プッシュ通知内に特定されたアプリケーションに対して受信した最後のプッシュ通知のみを記憶する。 一部の実装では、プッシュサービスデーモン３１＿９０４が今はアプリケーションを起動すべきでないことを、サンプリングデーモン３１＿１０２が示す場合（例えば、アドミッション制御リプライが「ｎｏ」）、プッシュサービスデーモン３１＿９０４は、アプリケーションに対するアプリケーション識別子を、ウェイクリスト３１＿９３０からノーウェイクリスト３１＿９３２に移動し得る。例えば、モバイルデバイスの割当量及び／又は条件が、アプリケーションを起動することを許可しないと、サンプリングデーモン３１＿１０２が判定する場合、アプリケーションに関連付けられた追加の低優先プッシュ通知に対して、プッシュ通知サーバ３１＿９０６にモバイルデバイス３１＿１００をウェイクさせることを可能にすることは、モバイルデバイス３１＿１００のデータ及びエネルギ割当量を単に更に消費するか、又は、環境条件を悪化させる（例えば、デバイスが過熱する）。従って、アプリケーション識別子をノーウェイクリスト３１＿９３２に移動し、更新されたフィルタ３１＿９２８（例えば、ウェイクリスト３１＿９３０及びノーウェイクリスト３１＿９３２）を含むメッセージ３１＿９２６をプッシュ通知サーバ３１＿９０６に送信することで、通知サーバ３１＿９０６は、それ自身のプッシュフィルタ３１＿９１４、ウェイクリスト３１＿９１６、及びノーウェイクリスト３１＿９１８を更新しプッシュフィルタ３１＿９２８への変更古典を反映し、アプリケーションに対する追加の低優先プッシュ通知がモバイルデバイス３１＿１００に配信されることを阻止し得る。

一部の実装では、アドミッション制御要求から返された値が「ｎｅｖｅｒ」で、アプリケーションを起動してはならないことを示す場合、プッシュサービスデーモン３１＿９０４は低優先プッシュ通知を削除し、プッシュ通知に関連付けられたアプリケーション識別子をプッシュフィルタ３１＿９２８から消去する。更新されたプッシュフィルタが、プッシュ通知サーバ３１＿９０６に送信され得、プッシュ通知サーバ３１＿９０６上のプッシュフィルタ３１＿９１４が更新され得、プッシュ通知サーバ３１＿９０６が、アプリケーション識別子に関連付けられたプッシュ通知をこれ以上送信することを阻止する。

一部の実装では、サンプリングデーモン３１＿１０２は、「ｓｔｏｐ」信号をプッシュサービスデーモン３１＿９０４に送信し、将来の低優先プッシュ通知が、プッシュ通知サーバ３１＿９０６からモバイルデバイス３１＿１００に送信されることを一時的に阻止し得る。例えば、現在時間に対するデータ割当量が使い果たされた、現在時間に対するエネルギ割当量が使い果たされた、システムに熱イベントが起こっている（例えば、モバイルデバイス３１＿１００が熱すぎる）、モバイルデバイス３１＿１００が十分なセルラー接続を有しない、及び、モバイルデバイス３１＿１００がＷｉ－Ｆｉに接続されていない、並びに／又は、モバイルデバイス３１＿１００がボイスコールに接続されており、Ｗｉ－Ｆｉに接続されていない、とサンプリングデーモン３１＿１０２が判定すると、サンプリングデーモン３１＿１０２は、ストップ信号をプッシュサービスデーモン３１＿９０４に送信し得る。プッシュサービスデーモン３１＿９０４が、ストップ信号を受信すると、プッシュサービスデーモン３１＿９０４は、ウェイクリスト３１＿９３０内のアプリケーション識別子をノーウェイクリスト３１＿９３２に移動し、更新されたプッシュフィルタ３１＿９２８をプッシュ通知サーバ３１＿９０６に送信し、プッシュフィルタ３１＿９１４を更新し得る。従って、プッシュ通知サーバ３１＿９０６は、将来の低優先プッシュ通知が、モバイルデバイス３１＿１００をウェイクし、モバイルデバイス３１＿１００の割当量、限度値、及び作動条件に悪影響を与えることを一時的に阻止する。

一部の実装では、サンプリングデーモン３１＿１０２は、リトライ信号をプッシュサービスデーモン３１＿９０４に送信し得る。例えば、サンプリングデーモン３１＿１０２は、割当量の状態、ネットワーク接続、限度値、及びデバイス条件を監視し得、プッシュデータ割当量が使い果たされていない、エネルギ割当量が使い果たされていない、モバイルデバイス３１＿１００に熱イベントが発生していない、モバイルデバイス３１＿１００が良好な品質セルラー接続を有している又はＷｉ－Ｆｉに接続されている、モバイルデバイス３１＿１００がボイスコールに接続されておらず、及び起動率限度値がリセットされている場合に、リトライメッセージをプッシュサービスデーモン３１＿９０４に送信する。プッシュサービスデーモン３１＿９０４がリトライ信号を受信すると、プッシュサービスデーモン３１＿９０４は、プッシュ通知データストア３１＿９３４内の各プッシュ通知に対するアドミッション制御要求をサンプリングデーモン３１＿１０２に送信し、記憶されたプッシュ通知に関連付けられた各アプリケーション（例えば、「ｂｕｎｄｌｅＩｄ」属性値）を起動してもよいかを判定する。

サンプリングデーモン３１＿１０２が、アドミッション制御要求からの「ｙｅｓ」を返す場合、プッシュサービスデーモン３１＿９０４は、上述するように、プッシュ通知をアプリケーションマネジャ３１＿１０６に送信し得、アプリケーションマネジャ３１＿１０６は、プッシュ通知に関連付けられたアプリケーションを、モバイルデバイス３１＿１００上のバックグラウンドプロセスとして起動し得る。アプリケーションが起動されると、アプリケーションはコンテンツ又はデータ更新をダウンロードし、ダウンロードされたデータに基づいて、アプリケーションユーザインタフェースを更新し得る。アプリケーションマネジャ３１＿１０６は、低優先プッシュ通知に関連付けられたアプリケーションを起動してもよいかをサンプリングデーモン３１＿１０２に尋ねない。
高優先プッシュ通知

一部の実装では、モバイルデバイス３１＿１００により受信されたプッシュ通知メッセージ３１＿９２０は、高優先プッシュ通知を含み得る。例えば、高優先プッシュ通知は、プッシュ通知に関連付けられたアプリケーションに対するコンテンツ更新が利用可能であることを示し得る。従って、高優先プッシュ通知が、アプリケーションの呼び出しを引き起こすと、アプリケーションは、更新されたコンテンツを１つ以上のネットワークリソースからダウンロードし得る。一部の実装では、高優先プッシュ通知がプッシュサービスデーモン３１＿９０４により受信されると、プッシュサービスデーモン３１＿９０４は、アドミッション制御要求をサンプリングデーモン３１＿１０２に行うことなく、その高優先プッシュ通知をアプリケーションマネジャ３１＿１０６に送信する。

一部の実装では、アプリケーションマネジャ３１＿１０６が、アプリケーションに関連付けられたプッシュ通知を受信すると、アプリケーションマネジャ３１＿１０６は、アドミッション制御要求をサンプリングデーモン３１＿１０２に行う。このアドミッション制御要求に応じて、サンプリングデーモン３１＿１０２は、上述するように、「ｙｅｓ」、「ｎｏ」、又は「ｎｅｖｅｒ」応答をリプライし得る。アプリケーションマネジャ３１＿１０６が、アドミッション制御要求に対する「ｙｅｓ」リプライを受信すると、アプリケーションマネジャ３１＿１０６は、受信した高優先プッシュ通知に関連付けられたアプリケーションを、モバイルデバイス３１＿１００上のバックグラウンドプロセスとして起動し得る。

一部の実装では、アプリケーションマネジャ３１＿１０６が、アドミッション制御要求に対する「ｎｏ」リプライを受信すると、アプリケーションマネジャ３１＿１０６は、高優先プッシュ通知を高優先プッシュ通知ストア３１＿９３６に記憶し得る。アプリケーションマネジャ３１＿１０６が、「ｎｅｖｅｒ」応答を受信すると、アプリケーションマネジャ３１＿１０６は、高優先プッシュ通知を削除し、プッシュ通知に関連付けられたアプリケーションに対する、プッシュ通知データストア３１＿９３６に記憶されたいずれのプッシュ通知を削除し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、「ｏｋ ｔｏ ｒｅｔｒｙ」信号をアプリケーションマネジャ３１＿１０６に送信し得る。例えば、アプリケーションマネジャ３１＿１０６が、「ｏｋ ｔｏ ｒｅｔｒｙ」メッセージをサンプリングデーモン３１＿１０２から受信すると、アプリケーションマネジャ３１＿１０６は、高優先プッシュ通知データストア３１＿９３６内の各高優先プッシュ通知に関連付けられたアプリケーションに対するアドミッション制御要求を行い、アドミッション制御要求に応じて「ｙｅｓ」リプライを受信すると、各アプリケーションを、バックグラウンドプロセスとして起動し得る。
プッシュ通知の表示を遅延する

一部の実装では、高優先プッシュ通知は、グラフィカルユーザインタフェースを、モバイルデバイス３１＿１００上に表示させ得る。例えば、高優先プッシュ通知の受信は、バナー、バルーン、又は他のグラフィカルオブジェクトを、モバイルデバイス３１＿１００のグラフィカルユーザインタフェース上に表示させ得る。グラフィカルオブジェクトは、例えば、受信したプッシュ通知の主題又はコンテンツを示す情報を含み得る。

一部の実装では、アプリケーションマネジャ３１＿１０６が高優先プッシュ通知を受信すると、アプリケーションマネジャ３１＿１０６は、その通知を、モバイルデバイス３１＿１００のグラフィカルユーザインタフェース上に表示させ得る。しかし、高優先プッシュ通知が、その高優先プッシュ通知に関連付けられたアプリケーションに対する、ダウンロード可能データ更新があることを示す場合、そのアプリケーションは、プッシュ通知が表示される前に、モバイルデバイス３１＿１００のバックグラウンドにて起動され得る。例えば、アプリケーションマネジャ３１＿１０６は、高優先プッシュ通知に関連付けられたアプリケーションを起動することと、プッシュ通知をユーザに知らせるグラフィカルオブジェクト（例えば、バナー）を表示することと、の間の遅延時間量（例えば、３０秒）が構成され得る。この遅延により、例えば、アプリケーションは、十分な時間をもって、コンテンツ更新をダウンロードし、ユーザにより呼び出される前に、アプリケーションのユーザインタフェースを更新できる。従って、ユーザが、グラフィカルオブジェクトに入力を提供するか、又は、高優先プッシュ通知に関連付けられたアプリケーションを呼び出すと、アプリケーションのユーザインタフェースが最新のものとなり、ユーザは、アプリケーションに対する更新を待つことを強いられなくなる。一部の実装では、アプリケーションマネジャ３１＿１０６が、高優先プッシュ通知に関連付けられたアプリケーションを起動できない場合、モバイルデバイス３１＿１００は、グラフィカルオブジェクト（例えば、バナー）を表示し、高優先プッシュ通知を受信したことをユーザに通知する。
プッシュ通知プロセス例

図３１－１０は、プッシュ通知サーバ３１＿９０６にてノンウェイキングプッシュを実行するためのプロセス例１０００のフロー図である。ステップ３１＿１００２にて、プッシュ通知サーバ３１＿９０６はプッシュ通知を受信し得る。例えば、プッシュ通知サーバ３１＿９０６は、プッシュ通知をプッシュ通知プロバイダ３１＿９０２（例えば、アプリケーションベンダにより運用されるサーバ）から受信し得る。

ステップ３１＿１００４にて、プッシュ通知サーバ３１＿９０６は、プッシュ通知が低優先プッシュ通知であると判定し得る。例えば、プッシュ通知プロバイダは、プッシュ通知の優先度を指定するデータをプッシュ通知に含み得る。プッシュ通知サーバ３１＿９０６は、プッシュ通知のコンテンツを分析し、プッシュ通知の優先度を判定し得る。

ステップ３１＿１００６にて、プッシュ通知サーバ３１＿９０６は、プッシュ通知を、プッシュ通知フィルタと比較し得る。例えば、プッシュ通知は、低優先プッシュ通知が指示される、モバイルデバイス３１＿１００上にインストール又は構成されたアプリケーションを特定し得る。このプッシュ通知は、例えば、アプリケーション識別子（例えば、「ｂｕｎｄｌｅＩｄ」属性値）を含み得る。プッシュ通知サーバ３１＿９０６は、プッシュ通知内のアプリケーション識別子を、プッシュ通知フィルタのノーウェイクリスト３１＿９１８内のアプリケーション識別子と比較し得る。

ステップ３１＿１００８にて、プッシュ通知サーバ３１＿９０６は、低優先プッシュ通知が記憶されるべきであると判定し得る。例えば、低優先プッシュ通知からのアプリケーション識別子が、プッシュ通知フィルタのノーウェイクリスト３１＿９１８にある場合、プッシュ通知サーバ３１＿９０６は、低優先プッシュがプッシュ通知データストア３１＿９２２に記憶されるべきであると判定し得る。

ステップ３１＿１０１０にて、ステップ３１＿１００８での判定に基づいて、低優先プッシュ通知が、プッシュ通知サーバ３１＿９０６のデータベース又はデータストア３１＿９２２に記憶され、モバイルデバイス３１＿１００には直ちに送信されない。

ステップ３１＿１０１２にて、プッシュ通知サーバ３１＿９０６は、モバイルデバイス３１＿１００へのネットワーク接続が確立されたと判定し得る。例えば、プッシュ通知サーバ３１＿９０６は、モバイルデバイス３１＿１００へのネットワーク接続を作成し、別の高優先又は低優先プッシュを配信し得る。モバイルデバイス３１＿１００は、プッシュ通知サーバ３１＿９０６へのネットワーク接続を確立し、通知フィルタの変更、定期状態更新、生存メッセージ、又は他のメッセージをプッシュ通知サーバ３１＿９０６に送信し得る。

ステップ３１＿１０１４にて、モバイルデバイス３１＿１００へのネットワーク接続が確立されたと判定したことに応じて、プッシュ通知サーバ３１＿９０６は、記憶されたプッシュ通知を送信し得る。例えば、プッシュ通知サーバ３１＿９０６は、プッシュ通知サーバ３１＿９０６にて記憶された低優先プッシュ通知を、モバイルデバイス３１＿１００に送信し得る。

図３１－１１は、低優先プッシュ通知に応じて、アプリケーションのバックグラウンド更新を実行するためのプロセス例１１００のフロー図である。ステップ３１＿１１０２にて、モバイルデバイス３１＿１００は、低優先プッシュ通知をプッシュ通知サーバ３１＿９０６から受信し得る。

ステップ３１＿１１０４にて、モバイルデバイス３１＿１００は、低優先プッシュ通知に関連付けられたアプリケーションを起動してもよいか判定し得る。例えば、アプリケーションは、モバイルデバイス３１＿１００上のバックグラウンドプロセスとして起動され得る。モバイルデバイス３１＿１００は、上述するアドミッション制御プロセスを使用して、アプリケーションを起動してもよいか否かを判定し得る。例えば、モバイルデバイス３１＿１００（例えば、サンプリングデーモン３１＿１０２）は、モバイルデバイス３１＿１００に対して判定されたデータ、エネルギ、及び／又は属性割当量に基づいて、アプリケーションを起動してもよいか否かを判定し得る。モバイルデバイス３１＿１００は、モバイルデバイスの条件、及び／又は、様々なボーターからの応答に基づく、モバイルデバイスのネットワーク接続の条件に基づいて、アプリケーションを起動してもよいか否かを判定し得る。アプリケーション（例えば、アドミッション制御）を起動してもよいか否かを判定するための詳細が、上の図３１－４を参照して詳述されている。

ステップ３１＿１１０６にて、デバイス条件、割当量、限度値、及び他のデータが、アプリケーションを起動してはよくないことを示すと、モバイルデバイス３１＿１００は、低優先プッシュ通知を記憶し得る。例えば、モバイルデバイス３１＿１００は、低優先プッシュ通知を、モバイルデバイス３１＿１００上のデータベース又は他のデータストアに記憶し得る。

ステップ３１＿１１０８にて、バックグラウンドアプリケーションを起動してはよくないと判定したことに応じて、モバイルデバイス３１＿１００は、そのプッシュ通知フィルタを更新し得る。例えば、モバイルデバイス３１＿１００は、低優先プッシュ通知に関連付けられたアプリケーションを、モバイルデバイス３１＿１００上のプッシュ通知フィルタのノーウェイクリストに移動し得る。

ステップ３１＿１１１０にて、モバイルデバイス３１＿１００は、更新された通知フィルタをプッシュ通知サーバ３１＿９０６に送信し得る。プッシュ通知サーバ３１＿９０６は、モバイルデバイス３１＿１００から受信したフィルタに基づいて、それ自身のプッシュ通知フィルタを更新し、低優先プッシュ通知をモバイルデバイス３１＿１００にいつ送信するか、及び、いつ送信しないかを判定し得る。

ステップ３１＿１１１２にて、モバイルデバイス３１＿１００は、低優先プッシュ通知に関連付けられたアプリケーションの起動をリトライしてもよいと判定し得る。例えば、モバイルデバイス３１＿１００は、割当量、限度値、及びデバイス条件が、上述するように、モバイルデバイス３１＿１００上での追加バックグラウンドアプリケーションの起動を可能とすると判定し得る。

ステップ３１＿１１１４にて、モバイルデバイス３１＿１００は、記憶された低優先プッシュ通知に関連付けられた特定のアプリケーションを起動してもよいか否かを判定し得る。例えば、モバイルデバイス３１＿１００のサンプリングデーモン３１＿１０２はアドミッション制御を実行し、モバイルデバイス１００上で構成された割当量がリセットされているか、又は、現在時刻に対して補充されており、モバイルデバイス３１＿１００の環境条件及びネットワーク接続が、特定のバックグラウンドアプリケーションの起動に十分であると判定し得る。

ステップ３１＿１１１６にて、モバイルデバイス３１＿１００が、特定のアプリケーションを起動してもよいと判定すると、モバイルデバイス３１＿１００はそのアプリケーションを起動し得る。例えば、特定のアプリケーションは、ユーザがアプリケーションを呼び出す前に、バックグラウンドプロセスとして起動され、新たなコンテンツをダウンロードし、アプリケーションのユーザインタフェースを更新し得る。このプロセスによりユーザは、コンテンツ更新がダウンロードされ、アプリケーションのユーザインタフェースがリフレッシュされるのを待つ必要なく、アプリケーションを呼び出すことができる。

図３１－１２は、高優先プッシュ通知に応じて、アプリケーションのバックグラウンド更新を実行するためのプロセス例１２００のフロー図である。ステップ３１＿１２０２にて、モバイルデバイス３１＿１００は、高優先プッシュ通知を受信し得る。

ステップ３１＿１２０４にて、モバイルデバイス３１＿１００は、高優先プッシュ通知に関連付けられたアプリケーションを起動してもよいか判定し得る。例えば、モバイルデバイス３１＿１００のサンプリングデーモン３１＿１０２はアドミッション制御を実行し、モバイルデバイス３１＿１００の割当量及び環境条件（例えば、デバイス条件、ネットワーク条件など）に基づいて、アプリケーションを起動してもよいか否かを判定し得る。

ステップ３１＿１２０６にて、高優先プッシュ通知に関連付けられたアプリケーションを起動してはよくない（例えば、アドミッション制御が「ｎｏ」を返す）場合、モバイルデバイス３１＿１００は、高優先プッシュ通知を記憶し得る。例えば、モバイルデバイス３１＿１００は、高優先プッシュ通知を、データベース、待ち行列、又は他の適切なデータ構造に記憶し得る。

ステップ３１＿１２０８にて、モバイルデバイス３１＿１００は、記憶された高優先プッシュ通知に関連付けられたアプリケーションの起動をリトライしてもよいと判定し得る。例えば、アドミッション制御の説明にて上述するように、データ、エネルギ、及び／又は属性割当量が補充される、デバイス条件が改善される、ネットワーク条件が改善される、又は、モバイルデバイス３１＿１００の他の条件が変更されると、モバイルデバイス３１＿１００は、アプリケーションの起動をリトライしてもよいと判定し得る。

ステップ３１＿１２１０にて、モバイルデバイス３１＿１００は、記憶された高優先プッシュ通知に関連付けられたアプリケーションを起動してもよいか判定し得る。例えば、モバイルデバイス３１＿１００は、上述する基準に基づいて、アプリケーションを起動してもよいか判定し得る。

ステップ３１＿１２１２にて、モバイルデバイス３１＿１００は、アプリケーションを、モバイルデバイス３１＿１００上のバックグラウンドにて起動し得る。例えば、アプリケーションは、モバイルデバイス３１＿１００上のバックグラウンドプロセスとして起動され得、そのアプリケーションが、更新されたコンテンツを、ネットワーク（例えば、インターネット）上のネットワークリソース（例えば、コンテンツサーバ）からダウンロードし得るようにする。

ステップ３１＿１２１４にて、モバイルデバイス３１＿１００は、プッシュ通知をユーザに提示する前に、ある期間待機し得る。例えば、モバイルデバイスは、受信した高優先プッシュ通知をユーザに通知する前に、アプリケーションが、コンテンツをある期間ダウンロードできるよう構成され得る。

ステップ３１＿１２１６にて、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００のユーザインタフェース上にプッシュ通知を提示し得る。例えば、モバイルデバイス３１＿１００は、高優先プッシュ通知を説明する情報を含むグラフィカルオブジェクト（例えば、バナー）を提示し得る。ユーザは、例えば、このグラフィカルオブジェクトを選択し、アプリケーションを呼び出し得る。アプリケーションは、ユーザに通知が提示される前に、コンテンツをダウンロードする時間を有するため、ユーザがアプリケーションを呼び出す際に、更新されたコンテンツがネットワークからダウンロードされるまでユーザに待機を強いることなく、アプリケーションは、更新されたコンテンツをユーザに表示できる。
バックグラウンドアップローディング／ダウンローディング

図３１－１３は、モバイルデバイス３１＿１００上にてデータのバックグラウンドダウンローディング及び／又はアップローディングを実行するためのシステム例３１＿１３００のブロック図である。バックグラウンドダウンロード及び／又はアップロードは、ユーザからの明示的な入力なく、アプリケーションにより開始されるネットワークデータ転送であり得る。例えば、バックグラウンドダウンロードは、ユーザがビデオゲームアプリケーションをプレイしている間に、そのビデオゲームの次のレベルを取り出するよう実行され得る。対照的に、フォアグランドダウンロード又はアップロードは、ダウンロード又はアップロードが発生すべきことのユーザからの明示的なインジケーションに応じて実行されるネットワークデータ転送であり得る。例えば、フォアグランドダウンロードは、ユーザが、写真、動画、又は文書をダウンロードするためにウェブページリンクを選択することにより開始され得る。同様に、バックグラウンドアップロードは、データをネットワークリソース（例えば、サーバ）にアップロードするための明白なユーザ要求をユーザから受信したか否かに基づいて、フォアグランドアップロードとは区別され得る。

一部の実装では、フォアグランドダウンロード／アップロード（例えば、ユーザにより明示的に要求されたダウンロード／アップロード）は、ユーザに対してすぐに実行される。例えば、ユーザ要求ダウンロード／アップロードはすぐに実行され、割当量制約条件又は他の考慮の対象とはならない。フォアグランドダウンロード／アップロードは、セルラーデータ接続経由で実行され得る。対照的に、バックグラウンドダウンロード及び／又はアップロードは、好機に応じて、かつ、割当量制約条件、及び、モバイルデバイス３１＿１００の温度などの考慮すべき環境条件内にて実行され得る。例えば、バックグラウンドダウンロード又はアップロードは、属性が、上述するアドミッション制御メカニズムにより承認される場合、その属性又は属性値に対して実行され得る。一部の実装では、バックグラウンドダウンロード及び／又はアップロードは、Ｗｉ－Ｆｉネットワーク接続に制限され得る。

一部の実装では、システム３１＿１３００は、バックグラウンド転送デーモン３１＿１３０２を含み得る。一部の実装では、バックグラウンド転送デーモン３１＿１３０２は、データ又はコンテンツのバックグラウンドダウンローディング及びアップローディングを、モバイルデバイス３１＿１００上で実行されるアプリケーション又はプロセスに代わって実行するよう構成され得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、バックグラウンドダウンロード及び／又はアップロードを、アプリケーション３１＿１３０４に代わって、アプリケーション３１＿１３０４とサーバ３１＿１３０６との間で実行し得る。従って、バックグラウンドダウンロード／アップロードは、アプリケーション３１＿１３０４からのプロセス外で実行され得る（例えば、ダウンロード／アップロードを要求するプロセスにて／により実行されない）。

一部の実装では、アプリケーション３１＿１３０４は、データをダウンロード又はアップロードするための要求をバックグラウンド転送デーモン３１＿１３０４に送信することにより、バックグラウンドダウンロード／アップロードを開始し得る。例えば、データ（例えば、コンテンツ）をダウンロードするための要求は、データがダウンロードされ得るネットワークの位置を特定し得る。データをアップロードするための要求は、データがアップロードされ得るネットワークの位置と、データが現在記憶されているモバイルデバイス３１＿１００上の位置と、を特定し得る。この要求はまた、アプリケーション３１＿１３０４を識別し得る。要求が実行されると、アプリケーション３１＿１３０４はシャットダウン又はサスペンドされ得、バックグラウンドダウンロード／アップロードがバックグラウンド転送デーモン３１＿１３０４により行われている間に、そのアプリケーションが、モバイルデバイス３１＿１００上のコンピューティング及び／又はネットワークリソースを継続して消費しないようにする。

一部の実装では、データのバックグラウンドアップロード又はダウンロードを実行することの要求を受信すると、バックグラウンド転送デーモン３１＿１３０２は、要求をサンプリングデーモン３１＿１０２に送信し、バックグラウンド転送デーモン３１＿１３０２にとって、ネットワーク経由でデータ転送を実行してもよいかを判定し得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、サンプリングデーモン３１＿１０２が、データ転送に対するアドミッション制御を実行することを要求し得る。アドミッション制御要求では、バックグラウンド転送デーモン３１＿１３０２は、バックグラウンド転送デーモン３１＿１３０２に対する識別子（例えば、「ｂｕｎｄｌｅＩｄ」属性値）、又は、バックグラウンド転送を要求するアプリケーションに対する識別子を提供し得、アドミッション制御が、バックグラウンド転送デーモン又はアプリケーション上で実行され得るようにする。アドミッション制御要求は、システムワイドデータ割当量から差し引かれる、要求のコストとして、転送されるデータ量を含み得る。

バックグラウンド転送デーモン３１＿１３０２からアドミッション制御要求を受信したことに応じて、サンプリングデーモン３１＿１０２は、システムワイドデータ及び／又はエネルギ割当量が、現在時間にわたって使い果たされたかを判定し得る。一部の実装では、モバイルデバイス３１＿１００が外部電源に接続されているとサンプリングデーモン３１＿１０２が判定する場合、サンプリングデーモン３１＿１０２は、エネルギ割当量に基づくバックグラウンドダウンロード／アップロードを阻止することをしない。サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１００がＷｉ－Ｆｉに接続されているか判定し得る。サンプリングデーモン３１＿１０２はまた、モバイルデバイス３１＿１００が熱イベント（例えば、所定の閾値を超える作動温度）のさなかにあるか否かを判定し得る。一部の実装では、サンプリングデーモン３１＿１０２が、データ割当量が使い果たされており、モバイルデバイス３１＿１００がＷｉ－Ｆｉに接続されていない、エネルギ割当量が使い果たされており、モバイルデバイス３１＿１００が外部電源に接続されていない、又は、モバイルデバイス３１＿１００が熱イベントのさなかにあることを判定する場合、続いてサンプリングデーモン３１＿１０２は、バックグラウンド転送デーモン３１＿１３０２によるアドミッション制御要求に対して「ｎｏ」リプライを返す。

一部の実装では、バックグラウンド転送デーモン３１＿１３０２が、アドミッション制御要求に対する「ｎｏ」リプライをサンプリングデーモン３１＿１０２から受信すると、バックグラウンド転送デーモン３１＿１３０２は、アプリケーション３１＿１３０４からのバックグラウンドダウンロード／アップロード要求を、要求リポジトリ３１＿１３０８に記憶し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、リトライ信号をバックグラウンド転送デーモン３１＿１３０２に送信し得る。例えば、データ及びエネルギ割当量が補充され、システムに熱イベントが発生しなくなると、サンプリングデーモン３１＿１０２は、リトライ信号をバックグラウンド転送デーモン３１＿１３０２に送信し得る。モバイルデバイス３１＿１００がＷｉ－Ｆｉに接続され、外部電源に接続され、及びシステムに熱イベントが発生していないと、サンプリングデーモン３１＿１０２は、リトライ信号をバックグラウンド転送デーモン３１＿１３０２に送信し得る。例えば、Ｗｉ－Ｆｉに接続されると、データ使用量を制御する必要がなくともよい。同様に、外部電源に接続されると、バッテリ電力を節約する必要がなくともよい。従って、アドミッション制御を実行する際に、データ及びエネルギ割当量は、サンプリングデーモン３１＿１０２により考慮されなくともよい。

一部の実装では、リトライ信号がバックグラウンド転送デーモン３１＿１３０２により受信されると、バックグラウンド転送デーモン３１＿１３０２は、アドミッション制御要求をサンプリングデーモン３１＿１０２に送信し得る。

サンプリングデーモン３１＿１０２が、アドミッション制御要求に応じて「ｏｋ」リプライを返す場合、バックグラウンド転送デーモン３１＿１３０２は、アプリケーション３１＿１３０４に対するバックグラウンドダウンロード又はアップロードを実行し得る。バックグラウンドダウンロードが完了すると、バックグラウンド転送デーモン３１＿１３０２はアプリケーション３１＿１３０４をウェイク又は呼び出し、ダウンロードされたデータをアプリケーション３１＿１３０４に提供し得る。

一部の実装では、バックグラウンド転送デーモン３１＿１３０２は、サンプリングデーモン３１＿１０２に、バックグラウンドダウンロード／アップロードがいつ開始し、いつ終了するかを通知し得、サンプリングデーモン３１＿１０２が、割当量を調整し、モバイルデバイス３１＿１００上で実行されたバックグラウンドダウンロード／アップロードについての統計を維持し得るようにする。例えば、バックグラウンド転送デーモン３１＿１３０２は、「ｂａｃｋｇｒｏｕｎｄＴｒａｎｓｆｅｒ」属性開始又は停止イベントを、サンプリングデーモン３１＿１０２に送信し得る。一部の実装では、バックグラウンド転送デーモン３１＿１３０２は、セルラーデータを経由して、Ｗｉ－Ｆｉを経由して、及び／又はそれらを合わせて、転送されたバイト（例えば、「ｓｙｓｔｅｍ．ｎｅｔｗｏｒｋＢｙｔｅｓ」属性イベント）の数を送信し得、サンプリングデーモン３１＿１０２が、割当量を調整し、モバイルデバイス３１＿１００上で実行されたバックグラウンドダウンロード／アップロードについての統計を維持し得るようにする。

一部の実装では、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて、タイムアウト値をバックグラウンド転送デーモン３１＿１３０２に返し得る。例えば、タイムアウト値は、バックグラウンド転送デーモンがバックグラウンドダウンロード又はアップロードを実行しなければならない期間（例えば、５分）を示し得る。タイムアウト期間が経過すると、バックグラウンド転送デーモン３１＿１３０２は、バックグラウンドダウンロード又はアップロードをサスペンドする。

一部の実装では、タイムアウト値は、現在時間に対する残りのエネルギ割当量に基づき得る。例えば、サンプリングデーモン３１＿１０２は、Ｗｉ－Ｆｉ経由でダウンロード又はアップロードを実行する間に、どれほどのエネルギが毎秒に消費されたかを、サンプリングデーモン３１＿１０２により収集された過去イベントデータに基づいて判定し得る。サンプリングデーモン３１＿１０２は、残りのエネルギ割当量を、バックグラウンドダウンロード又はアップロードを実行する間にエネルギが消費されるレートで除算することにより、タイムアウト期間を判定し得る（例えば、エネルギ割当量／消費されたエネルギ／時間＝タイムアウト期間）。

一部の実装では、バックグラウンドダウンロード及び／又はアップロードは再開可能である。例えば、モバイルデバイス３１＿１００がＷｉ－Ｆｉ範囲を外れて移動する場合、バックグラウンドダウンロード／アップロードはサスペンドされ得る（例えば、休止され得る）。モバイルデバイス３１＿１００がＷｉ－Ｆｉ範囲に再び入ると、サスペンドされていたダウンロード／アップロードが再開され得る。同様に、バックグラウンドダウンロード／アップロードによりエネルギ割当量が使い果たされる場合（例えば、タイムアウト期間が経過する）、バックグラウンドダウンロード／アップロードはサスペンドされ得る。追加割当量が割り当てされると（例えば、次の時間にて）、サスペンドされていたダウンロード／アップロードが再開され得る。

一部の実装では、バックグラウンドダウンロード／アップロードは、ネットワーク接続の品質に基づいてサスペンドされ得る。例えば、モバイルデバイス３１＿１００が、モバイルデバイス３１＿１００と、サービスを提供するセルラータワーとの間に良好なセルラーデータ接続を有し、セルラータワーと、モバイルデバイス３１＿１００がデータを転送する又はされるサーバとの間に良好なデータ接続を有し得ていても、モバイルデバイス３１＿１００は、サーバへの良好な接続を有しない場合がある。例えば、モバイルデバイス３１＿１００とサーバとの間の転送速度は遅い場合があり、セルラーインタフェースのスループットは低い場合がある。バックグラウンドダウンロード／アップロードの転送速度が閾値転送速度値未満となり、及び／又は、バックグラウンドダウンロード／アップロードのスループットが閾値スループット値未満となる場合、バックグラウンドダウンロード／アップロード（例えば、データ転送）は、検出された低品質ネットワーク接続に基づいて、よりよいネットワーク接続が利用可能となるまで、サスペンド又は休止され得る。例えば、Ｗｉ－Ｆｉ接続が利用可能となる場合、サスペンドされていたバックグラウンドダウンロード／アップロードが、Ｗｉ－Ｆｉ接続経由で再開され得る。

一部の実装では、バックグラウンド転送デーモン３１＿１３０２は、一度に実行され得るバックグラウンドダウンロード及び／又はアップロード数の制限値が構成され得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、同時バックグラウンドダウンロード及び／又はアップロード数を３に制限し得る。
バックグラウンドダウンロード／アップロードプロセス例

図３１－１４は、バックグラウンドダウンロード及びアップロードを実行するためのプロセス例３１＿１４００のフロー図である。例えば、バックグラウンドダウンロード及び／又はアップロードは、モバイルデバイス３１＿１００上のアプリケーションに代わって、バックグラウンド転送デーモン３１＿１３０２により実行され得る。

ステップ３１＿１４０２にて、バックグラウンド転送要求が受信され得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、バックグラウンドダウンロード／アップロード要求を、モバイルデバイス３１＿１００上で実行されているアプリケーションから受信し得る。アプリケーションが要求を行うと、アプリケーションは、例えば、終了又はサスペンドされ得る。この要求はアプリケーションを特定し、データに対するソース及び／又は宛先位置を特定し得る。例えば、データをダウンロードする場合、ソース位置はサーバのネットワークアドレスであり得、宛先位置はモバイルデバイス３１＿１００のファイルシステム内のディレクトリであり得る。データをアップロードする場合、ソース位置はファイルシステム位置であり得、宛先はネットワークの位置であり得る。

ステップ３１＿１４０４にて、モバイルデバイス３１＿１００は、割当量及びデバイス条件がデータ転送を許可しないと判定し得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、バックグラウンド転送デーモン３１＿１３０２、バックグラウンド転送が実行されるアプリケーション、及び／又は転送されるデータの量を特定するアドミッション制御要求をサンプリングデーモン３１＿１０２に行うことにより、要求されたバックグラウンド転送を実行してもよいか、サンプリングデーモン３１＿１０２に尋ね得る。サンプリングデーモン３１＿１０２は、エネルギ及びデータ割当量が使い果たされているか、かつ、モバイルデバイス３１＿１００が熱イベントのさなかにあるか判定し得る。割当量が使い果たされている場合、又は、モバイルデバイス３１＿１００が熱イベントのさなかにある場合、サンプリングデーモン３１＿１０２は、バックグラウンドデータ転送を実行してはよくないこと（例えば、アドミッション制御が「ｎｏ」を返す）を示すメッセージをバックグラウンド転送デーモン３１＿１３０２に送信し得る。

ステップ３１＿１４０６にて、モバイルデバイス３１＿１００はバックグラウンド転送要求を記憶し得る。例えば、アドミッション制御要求に応じてサンプリングデーモン３１＿１０２が「ｎｏ」値を返すと、バックグラウンド転送デーモン３１＿１３０２は、転送要求を転送要求リポジトリに記憶し得る。

ステップ３１＿１４０８にて、モバイルデバイス３１＿１００は、バックグラウンド転送をリトライしてもよいと判定し得る。例えば、サンプリングデーモン３１＿１０２は、データ及びエネルギ割当量が補充されており、モバイルデバイス３１＿１００が熱イベントのさなかにないと判定し得る。サンプリングデーモン３１＿１０２は、リトライメッセージをバックグラウンド転送デーモン３１＿１３０２に送信し得る。バックグラウンド転送デーモン３１＿１３０２は続いて、記憶された転送要求のそれぞれに対して別のアドミッション制御要求を実行することにより、転送要求リポジトリに記憶された、要求された転送を実行することを試み得る。

ステップ３１＿１４１０にて、モバイルデバイス３１＿１００は、モバイルデバイス３１＿１００の割当量及び条件が、バックグラウンドデータ転送を許可すると判定し得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、サンプリングデーモン３１＿１０２に、要求されたバックグラウンド転送を実行してもよいか尋ね得る。サンプリングデーモン３１＿１０２はアドミッション制御を実行し、エネルギ及びデータ割当量が補充されており、モバイルデバイス３１＿１００が熱イベントのさなかにないこと判定し得る。割当量が使い果たされておらず、かつモバイルデバイス３１＿１００が熱イベントのさなかにない場合、サンプリングデーモン３１＿１０２は、バックグラウンドデータ転送を実行してもよいことを示すメッセージをバックグラウンド転送デーモン３１＿１３０２に送信し得る。

ステップ３１＿１４１２にて、モバイルデバイス３１＿１００はバックグラウンド転送を実行し得る。例えば、バックグラウンド転送デーモン３１＿１３０２は、要求されたバックグラウンドダウンロード又はバックグラウンドアップロードを、要求しているアプリケーションのために実行し得る。バックグラウンド転送デーモン３１＿１３０２は、サンプリングデーモン３１＿１０２に、バックグラウンド転送がいつ開始し、いつ終了するかを通知し得る（例えば、「ｂａｃｋｇｒｏｕｎｄＴｒａｎｓｆｅｒ」属性開始及び停止イベントを使用して）。バックグラウンド転送デーモン３１＿１３０２は、バックグラウンドダウンロード又はアップロード中に転送されたバイト数をサンプリングデーモンに知らせるメッセージを送信し得る（例えば、「ｎｅｔｗｏｒｋＢｙｔｅｓ」属性イベントを使用して）。バックグラウンド転送が完了すると、バックグラウンド転送デーモン３１＿１３０２は、バックグラウンド転送要求を行ったアプリケーションを呼び出し（例えば、起動又はウェイク）、その要求しているアプリケーションに完了状態情報を送信し得る（例えば、サクセス、エラー、ダウンロードしたデータなど）。
バックグラウンド更新を有効／無効にする

図３１－１５は、モバイルデバイス上のアプリケーションに対するバックグラウンド更新を有効及び／又は無効にするためのグラフィカルユーザインタフェース（ＧＵＩ）例３１＿１５００を示す。例えば、ＧＵＩ３１＿１５００は、モバイルデバイス３１＿１００上のアプリケーションに対するバックグラウンド更新設定を調整するためのユーザ入力を受信するために、モバイルデバイス３１＿１００のディスプレイ上に提示されたインタフェースであり得る。

一部の実装では、ＧＵＩ３１＿１５００へのユーザ入力は、上述するように、ユーザ呼び出し予測に基づいて、アプリケーションに対するバックグラウンド更新が実行されることを有効又は無効にし得る。例えば、サンプリングデーモン３１＿１０２及び／又はアプリケーションマネジャ３１＿１０６は、アプリケーションに対するバックグラウンド更新が有効又は無効であるか判定し、アプリケーションマネジャ３１＿１０６によりアプリケーションが起動されることを阻止し得る、又は、サンプリングデーモン３１＿１０２により生成されるアプリケーション呼び出し予想にアプリケーションが含まれることを阻止し得る。例えば、バックグラウンド更新がアプリケーションに対して無効である場合、サンプリングデーモン３１＿１０２は、そのアプリケーションを、アプリケーションマネジャ３１＿１０６により要求されたユーザ呼び出しアプリケーション予想に含めない。従って、バックグラウンド更新が無効である場合、アプリケーションマネジャ３１＿１０６はアプリケーションを起動しない。反対に、バックグラウンド更新がアプリケーションに対して有効である場合、上述するように、ユーザ呼び出しの蓋然性に基づいて、そのアプリケーションは、サンプリングデーモン３１＿１０２により生成されるアプリケーション呼び出し予想に含まれてよい。

一部の実装では、プッシュ通知が受信されると、ＧＵＩ３１＿１５００へのユーザ入力は、上述するように、アプリケーションに対するバックグラウンド更新が実行されることを有効又は無効にし得る。例えば、サンプリングデーモン３１＿１０２、アプリケーションマネジャ３１＿１０６、及び／又はプッシュサービスデーモン３１＿９０４は、アプリケーションに対するバックグラウンド更新が有効又は無効であるかを判定し、プッシュ通知を受信したことに応じて、そのアプリケーションがアプリケーションマネジャ３１＿１０６により起動されることを阻止し得る。例えば、バックグラウンド更新がアプリケーションに対して無効であり、そのアプリケーションに対するプッシュ通知を受信する場合、アプリケーションマネジャ３１＿１０６は、プッシュ通知に応じてアプリケーションを起動せず、更新をダウンロードしない。

一部の実装では、ＧＵＩ３１＿１５００は、バックグラウンド更新を実行するよう構成されたアプリケーション３１＿１５０２～１５１４を表示し得る。例えば、アプリケーション３１＿１５０２～１５１４は、アプリケーションマネジャ３１＿１０６により起動されると、モバイルデバイス３１＿１００上でバックグラウンドプロセスとして実行されるよう構成又はプログラムされ得る。バックグラウンドプロセスとして実行されると、アプリケーション３１＿１５０２～１５１４は、様々なネットワークリソースと通信し、現在の又は更新されたコンテンツをダウンロードし得る。アプリケーション３１＿１５０２～１５１４は続いて、それらそれぞれのユーザインタフェースを更新し、モバイルデバイス３１＿１００のユーザにより呼び出されると、更新されたコンテンツを提示し得る。一部の実装では、バックグラウンド更新を実行するよう構成又はプログラムされていないアプリケーションは、ＧＵＩ３１＿１５００上に表示されない。

一部の実装では、ユーザは、入力をＧＵＩ３１＿１５００に提供し、アプリケーションに対するバックグラウンド更新を有効及び／又は無効にし得る。例えば、ユーザは、トグル３１＿１５１６に関連する入力（例えば、タッチ入力）をモバイルデバイス３１＿１００に提供し、アプリケーション３１＿１５０２に対するバックグラウンド更新をオン又はオフにし得る。ユーザは、トグル３１＿１５１８に関連する入力（例えば、タッチ入力）をモバイルデバイス３１＿１００に提供し、アプリケーション３１＿１５０８に対するバックグラウンド更新をオン又はオフにし得る。

一部の実装では、バックグラウンド更新アプリケーションに対する追加オプションが、ＧＵＩ３１＿１５００を通して指定され得る。例えば、ユーザは、アプリケーション３１＿１５１４に関連付けられたグラフィカルオブジェクト３１＿１５１０を選択し、追加バックグラウンド更新オプションを指定するためのグラフィカルユーザインタフェース（図示せず）を呼び出し得る。バックグラウンド更新オプションは、例えば、アプリケーション３１＿１５１４に対するバックグラウンド更新をオン及び／又はオフにする開始時間及び終了時間を含み得る。
ピアデバイス間でデータをシェアする

図３１－１６は、ピアデバイス間でデータをシェアするためのシステム例を示す。一部の実装では、モバイルデバイス３１＿１００は、イベントデータ、システムデータ、及び／又はイベント予想を、モバイルデバイス３１＿１６００とシェアし得る。例えば、モバイルデバイス３１＿１００及びモバイルデバイス３１＿１６００は、同じユーザにより所有されるデバイスであり得る。従って、各デバイス上でのユーザのアクティビティについての情報を、モバイルデバイス３１＿１００とモバイルデバイス３１＿１６００との間でシェアすることは有益となる可能性がある。

一部の実装では、モバイルデバイス３１＿１６００は、上述するように、モバイルデバイス３１＿１００と同様に構成され得る。例えば、モバイルデバイス３１＿１６００は、先の段落で説明された機能を提供するサンプリングデーモン３１＿１６０２と共に構成され得る（例えば、属性、属性イベント、予想すること、アドミッション制御など）。

一部の実装では、モバイルデバイス３１＿１００及びモバイルデバイス３１＿１６００はそれぞれ、識別サービスデーモン３１＿１６２０及び識別サービスデーモン３１＿１６１０と共に構成され得る。例えば、識別サービスデーモン３１＿１６２０及び３１＿１６１０は、モバイルデバイス３１＿１００とモバイルデバイス３１＿１６００との間で情報を通信するよう構成され得る。識別サービスデーモンは、様々なピアツーピア及びネットワーク接続を経由して、同じユーザにより所有されるデバイス間でデータをシェアするよう使用され得る。例えば、識別サービスデーモン３１＿１６２０及び識別サービスデーモン３１＿１６１０は、Ｂｌｕｅｔｏｏｔｈ、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ、Ｗｉ－Ｆｉ、ＬＡＮ、ＷＡＮ、及び／又はインターネット接続を経由して情報を交換し得る。

一部の実装では、サンプリングデーモン３１＿１６０２（及び、サンプリングデーモン３１＿１０２）は、イベント予想及びシステム状態情報を、同じユーザにより所有される他のデバイス上で実行される他のサンプリングデーモンとシェアするよう構成され得る。例えば、モバイルデバイス３１＿１００及びモバイルデバイス３１＿１６００が、同じユーザにより所有されている場合、サンプリングデーモン３１＿１０２及びサンプリングデーモン３１＿１６０２は、イベント予想情報及び／又はシステム状態情報（例えば、バッテリ状態）を交換し得る。例えば、サンプリングデーモン３１＿１６０２は、識別サービスデーモン３１＿１６１０を使用して、イベント予想情報及び／又はシステム状態情報を送信し得る。

識別サービスデーモン３１＿１６１０は、識別サービスデーモン３１＿１６２０への接続を確立し、イベント予想情報及び／又はモバイルデバイス３１＿１６００システム状態情報を、サンプリングデーモン３１＿１０２に、識別サービスデーモン３１＿１６２０を通して通信し得る。

一部の実装では、アプリケーション３１＿１６０８（例えば、サンプリングデーモン３１＿１６０２のクライアント）は、サンプリングデーモン３１＿１６０２が、指定された属性又は属性値に対するイベント予想をサンプリングデーモン３１＿１０２に送信することを要求し得る。例えば、アプリケーション３１＿１６０８は、モバイルデバイス３１＿１００のアプリケーション３１＿１０８と同期されているアプリケーションであり得る。例えば、アプリケーション３１＿１０８及び３１＿１６０８は、モバイルデバイス３１＿１００とモバイルデバイス３１＿１６００との間でデータ（例えば、メディアファイル、メッセージ、状態情報など）を同期するよう構成されたメディアアプリケーション（例えば、音楽ライブラリ、ビデオライブラリ、電子メールアプリケーション、メッセージアプリケーションなど）であり得る。

一部の実装では、デバイスとの間でデータをいつ同期するかをピアデバイス（例えば、モバイルデバイス３１＿１００）が判定できるようにするために、アプリケーション３１＿１６０８は、モバイルデバイス３１＿１６００により生成された属性イベントデータに基づいて、サンプリングデーモン３１＿１６０２が、「ｂｕｎｄｌｅＩｄ」属性又は特定の「ｂｕｎｄｌｅＩｄ」属性値（例えば、アプリケーション３１＿１６０８に対するアプリケーション識別子）に対する時間的及び／又はピア予想を生成し、その予測をサンプリングデーモン３１＿１０２に送信することを要求し得る。例えば、ピアデバイスは、同じユーザにより所有されるリモートデバイスであり得る（例えば、現在のローカルデバイスではない）。モバイルデバイス３１＿１００は、例えば、モバイルデバイス３１＿１６００のピアデバイスであり得る。

一部の実装では、要求クライアント（例えば、アプリケーション３１＿１６０８）は、予測データに対する配信及び期間についてのスケジュールを指定し得る。例えば、アプリケーション３１＿１６０８は、「ｂｕｎｄｌｅＩｄ」属性値「ｍａｉｌａｐｐ」に対するピア及び／又は時間的予想を要求し得る。アプリケーション３１＿１６０８は、例えば、予想が毎週生成されて交換され、各予想が、１週間のある長さ又は期間をカバーすることを要求し得る。

一部の実装では、ピアデバイス間のデータ交換は、静的にスケジュール化され得る。サンプリングデーモン３１＿１６０２は、モバイルデバイス３１＿１００が、厳密なスケジュールの下でモバイルデバイス３１＿１６００のリモート状態の一貫したビューを有するために必要な属性データを送信し得る（例えば、２４時間毎のアプリケーション予想及びバッテリ統計）。一部の実装では、クライアントは、ピアデバイスからの要求で属性予想又は統計を要求し得る。これらの交換は非再来性である。要求クライアントは、要求したデータが受信されると、通知され得る。

一部の実装では、サンプリングデーモン３１＿１６０２は、モバイルデバイス３１＿１６００に対するシステム状態データをサンプリングデーモン３１＿１０２に送信し得る。例えば、サンプリングデーモン３１＿１６０２は、バッテリ充電レベルイベント（例えば、「ｂａｔｔｅｒｙＬｅｖｅｌ」属性イベント）、バッテリ充電イベント（例えば、「ｃａｂｌｅＰｌｕｇｉｎ」イベント）、エネルギ使用量イベント（例えば、「ｅｎｅｒｇｙ」属性イベント）、及び／又は、バッテリ使用量及び充電統計を生成するために使用され得る他のイベントを受信し、バッテリ関連イベントデータをサンプリングデーモン３１＿１０２に送信し得る。例えば、バッテリ状態情報は、２４時間毎に交換され得る。バッテリ状態情報は、好機に応じて交換され得る。例えば、通信チャネル（例えば、ピアツーピア、ネットワーク化など）が、モバイルデバイス３１＿１００とモバイルデバイス３１＿１６００との間に確立されると、モバイルデバイスは、すでに開かれた通信チャネルを好機に応じて使用し、バッテリ状態又は他のシステム状態情報（例えば、現在のフォアグランドアプリケーションの識別）を交換し得る。

別の実施例として、サンプリングデーモン３１＿１６０２は、熱レベルイベント（例えば、「ｔｈｅｒｍａｌＬｅｖｅｌ」属性イベント）、ネットワークイベント（例えば、「ｎｅｔｗｏｒｋＱｕａｌｉｔｙ」属性イベント、「ｎｅｔｗｏｒｋＢｙｔｅｓ」属性イベント）を受信し、熱及び／又はネットワークイベントをサンプリングデーモン３１＿１０２に送信し得る。サンプリングデーモン３１＿１６０２は、どのアプリケーション（例えば、アプリケーション識別子）が現在、モバイルデバイス３１＿１６００のフォアグランドにあるかを示すイベント（例えば、「ｓｙｓｔｅｍ．ｆｏｒｅｇｒｏｕｎｄＡｐｐ」属性イベント）を、アプリケーションマネジャ３１＿１０６から受信し、フォアグランドアプリケーション情報をサンプリングデーモン１０２に送信し得る。一部の実装では、熱イベント及びフォアグランドアプリケーション変更情報は、イベントが発生するとすぐに、ピアデバイス間で交換され得る（例えば、ピアデバイス間の接続が確立されるとすぐに）。一部の実装では、ネットワーク状態情報は、定期的に交換され得る（例えば、１日に１度、１日に２度、毎時間など）。

サンプリングデーモン３１＿１６０２から予想及び／又はシステムイベントデータを受領すると、サンプリングデーモン３１＿１０２は、その予想及び／又はイベントデータをピアデータストア３１＿１６２２に記憶し得る。同様に、サンプリングデーモン３１＿１６０２がサンプリングデーモン３１＿１０２から受信するいずれの予想及び／又はイベントデータが、ピアデータストア３１＿１６１２に記憶され得る。一部の実装では、別のデバイスから受信した予想及び／又はイベントデータは、デバイス説明と関連付けられ得る。例えば、デバイス説明は、デバイス名、デバイス識別子、及び、デバイスのモデルを特定するモデル識別子を含み得る。デバイス説明は、ピアデータストア３１＿１６２２内の、デバイスに対する予想データ及び／又はイベントデータを探すために使用され得る。モバイルデバイス３１＿１００及びモバイルデバイス３１＿１６００が予想及び／又はイベントデータを交換すると、これらのモバイルデバイスは、以下のリモートアドミッション制御メカニズムを使用して互いにいつ通信するかを判定するために、その交換された情報を使用し得る。情報が必要な時、及び、デバイスのバッテリ状態が、情報をシェアすることをサポートし得る時にのみ、デバイスが情報をシェアできることにより、通信の電力管理が改善され得る。
リモートアドミッション制御

一部の実装では、モバイルデバイス３１＿１００（又は、モバイルデバイス３１＿１６００）は、別のデバイスから受信したデータに基づいて、アドミッション制御を実行し得る。例えば、サンプリングデーモン３１＿１０２は、サンプリングデーモン３１＿１６０２から受信し、ピアデータストア３１＿１６２２に記憶された予想及びシステムイベントデータに基づいて、アドミッション制御を実行し得る。例えば、データをアプリケーション３１＿１６０８と同期するため、アプリケーション３１＿１０８は、同期メッセージを識別サービスデーモン３１＿１６２０に送信し得る。例えば、同期メッセージは、モバイルデバイス３１＿１００の識別子、モバイルデバイス３１＿１６００の識別子、優先度識別子（例えば、高、低）、及び、メッセージペイロード（例えば、同期されるデータ）を含み得る。
低優先メッセージ

一部の実装では、アドミッション制御を行った後に、低優先メッセージが送信され得る。例えば、低優先メッセージは、任意の処理に関連付けられたメッセージであり得る（例えば、バックグラウンドアプリケーション、システムユーティリティ、予期アクティビティ、ユーザにより開始されないアクティビティ）。例えば、識別サービスデーモン３１＿１６２０は、アプリケーション３１＿１６０８のバンドル識別子である「ｂｕｎｄｌｅＩｄ」属性値（例えば、「ｂｕｎｄｌｅＩｄ」＝「１６０８」）に対するアドミッション制御要求をサンプリングデーモン３１＿１０２に送信し得る。「ｂｕｎｄｌｅＩｄ」属性名及び値（例えば、「１６０８」）に加えて、識別サービスデーモン３１＿１６２０は、アドミッション制御要求内にデバイス名（例えば、「デバイス３１＿１６００」）を提供し、アプリケーション３１＿１０８が、別のデバイスとの通信のためのアドミッション制御を要求していることを示し得る。

一部の実装では、アドミッション制御要求を受信したことに応じて、サンプリングデーモン３１＿１０２は、ローカルアドミッション制御及びリモートアドミッション制御を実行し得る。例えば、サンプリングデーモン３１＿１０２は、上述するように、ローカルアドミッション制御を実行し、指定された属性値（例えば、「ｂｕｎｄｌｅＩｄ」＝「１６０８」）に関連付けられたイベントが発生できる条件にモバイルデバイス３１＿１００があるかを判定し得る。サンプリングデーモン３１＿１０２は、例えば、ローカルエネルギ、データ、及び属性割当量をチェックし、ボーターフィードバックを求め、指定された属性値（例えば、「ｂｕｎｄｌｅＩｄ」＝「１６０８」）に関連付けられたイベントを許可する条件にモバイルデバイス３１＿１００があるか否かを判定し得る。

ローカルアドミッション制御を実行することに加えて、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１６００から受信し、ピアデータストア３１＿１６２２に記憶された「ｂｕｎｄｌｅＩｄ」属性予想、イベントデータ、及びシステムデータに基づいて、リモートアドミッション制御を実行し得る。例えば、サンプリングデーモン３１＿１０２は、デバイス識別子（例えば、「デバイス３１＿１６００」、デバイス名、固有識別子、ＵＵＩＤなど）を使用し、モバイルデバイス３１＿１６００に関連付けられたデータをピアデータストア３１＿１６２２内に特定し得る。サンプリングデーモン３１＿１０２は、サンプリングデーモン３１＿１６０２から受信した属性（例えば、「ｂｕｎｄｌｅＩｄ」）予想データを分析し、現在の１５分タイムスロット内に、モバイルデバイス３１＿１６００上で、アプリケーション３１＿１６０８がユーザにより呼び出される可能性があるか判定し得る。現在の１５分タイムスロット内に、アプリケーション３１＿１６０８が、ユーザにより呼び出される可能性がない場合、続いてサンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｎｏ」値を返し得る。例えば、アプリケーション３１＿１６０８がモバイルデバイス３１＿１６００上で使用される可能性がある時にのみ、アプリケーション３１＿１０８がアプリケーション３１＿１６０８と同期できるようにすることにより、ユーザがアプリケーション３１＿１６０８をモバイルデバイス３１＿１６００上で使用する可能性があるそのような時間まで、サンプリングデーモン３１＿１０２は同期プロセスを遅延し、システムリソース（例えば、バッテリ、ＣＰＵサイクル、ネットワークデータ）を節約し得る。

一部の実装では、アプリケーション３１＿１６０８が、モバイルデバイス３１＿１６００のユーザにより、現在の１５分タイムスロット内に呼び出される可能性がある場合、続いてサンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１６００に関連付けられ、ピアデータストア３１＿１６２２に記憶されたシステムデータをチェックし得る。例えば、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１６００に関連付けられたシステムデータをチェックし、アプリケーション３１＿１０８とアプリケーション３１＿１６０８との間の同期を実行するための残りのバッテリ充電量をモバイルデバイス３１＿１６００が十分に有しているか判定し得る。例えば、サンプリングデーモン３１＿１０２は、アプリケーション３１＿１０８とアプリケーション３１＿１６０８との間の同期を補完するための現在のバッテリ充電量が十分であるかチェックし得る。サンプリングデーモン３１＿１０２は、同期を実行し、次の予測されたバッテリ再充電までの作動を継続するためのバッテリ充電量が十分であるかチェックし得る（例えば、「ｃａｂｌｅＰｌｕｇｉｎ」属性イベント）。例えば、サンプリングデーモン３１＿１０２は、次の「ｃａｂｌｅＰｌｕｇｉｎ」属性イベントがいつ発生する可能性があるかを特定する、「ｃａｂｌｅＰｌｕｇｉｎ」属性に対する時間的予想を生成し得る。サンプリングデーモン３１＿１０２は、エネルギ使用統計（イベント）を分析し、次の「ｃａｂｌｅＰｌｕｇｉｎ」イベントまでのエネルギ使用量を予測し、アプリケーション３１＿１０８とアプリケーション３１＿１６０８との間の同期送信をサービスするための余剰エネルギが十分であるか判定し得る。モバイルデバイス３１＿１６００が、同期をサービスするためのエネルギ（例えば、バッテリ充電）を十分に有さないと、サンプリングデーモン３１＿１０２が判定する場合、サンプリングデーモン３１＿１０２は、リモートアドミッション制御要求に応じて「ｎｏ」値を返し得る。

一部の実装では、サンプリングデーモン３１＿１０２は、モバイルデバイス３１＿１６００に関連付けられたシステムデータをチェックし、モバイルデバイス３１＿１６００が正常な熱条件にあり（例えば、熱すぎない）、同期要求の処理を扱うことができるか判定し得る。例えば、モバイルデバイス３１＿１６００が現在、閾値を超える温度にて作動していることを、モバイルデバイス３１＿１６００から受信した「ｔｈｅｒｍａｌＬｅｖｅｌ」属性イベントデータが示す場合、サンプリングデーモン３１＿１０２は、リモートアドミッション制御要求に応じて「ｎｏ」値を返すことにより、同期通信を阻止し得る。

一部の実装では、ユーザがアプリケーション３１＿１６０８をモバイルデバイス３１＿１６００上で呼び出す可能性があることを予測データが示し、エネルギ、熱、及び他のシステム状態情報が、モバイルデバイス３１＿１００からの通信を処理する条件にモバイルデバイス３１＿１６００があることを示す場合、サンプリングデーモン３１＿１０２は、アドミッション制御要求に応じて「ｙｅｓ」値を、識別サービスデーモン３１＿１６２０に返し得る。アドミッション制御要求に応じて「ｙｅｓ」値を受信したことに応じて、識別サービスデーモン３１＿１６２０は、アプリケーション３１＿１０８に対する同期メッセージを、モバイルデバイス３１＿１６００上の識別サービスデーモン３１＿１６１０に送信し得る。アプリケーション３１＿１０８及びアプリケーション３１＿１６０８は続いて、識別サービスデーモン３１＿１６２０及び識別サービスデーモン３１＿１６１０を通してメッセージを交換することにより、データを同期し得る。

一部の実装では、リモートアドミッション制御を行った後に、高優先メッセージが送信され得る。例えば、高優先メッセージは、フォアグランドアプリケーションに関連付けられたメッセージ、又は、ユーザ提供入力に応じて生成されたメッセージなどの、ユーザ開始タスクに関連付けられたメッセージであり得る。一部の実装では、高優先メッセージに対するアドミッション制御は、低優先メッセージと同様に処理され得る。しかし、高優先メッセージに対してリモートアドミッション制御を実行する際には、高優先メッセージは、属性予想データ（例えば、「ｂｕｎｄｌｅＩｄ」予想データ）を考慮することなくアドミット（許可）され得る。なぜなら、高優先メッセージは通常、一部の任意のバックグラウンドタスクにより開始される代わりに、一部のユーザアクションによりトリガーされるからである。

一部の実装では、高優先メッセージに対してアドミッション制御を実行する際には、リモートデバイス（例えば、モバイルデバイス３１＿１６００）のバッテリ状態がチェックされ、高優先メッセージの処理に利用可能なバッテリ充電量をリモートデバイス（例えば、ピアデバイス）が十分有していることが確認され得る。リモートデバイス上で十分なバッテリ充電量が利用可能である場合、続いて高優先メッセージが、リモートアドミッション制御により承認される。例えば、高優先メッセージの処理に十分なバッテリ充電量が残っている場合、サンプリングデーモン３１＿１０２は、リモートアドミッション制御要求に応じて「ｙｅｓ」値を、識別サービスデーモン３１＿１６２０に送信し得る。リモートデバイス上に十分なバッテリ充電量が利用可能でない場合、続いて高優先メッセージが、リモートアドミッション制御により拒否される。例えば、高優先メッセージの処理に十分なバッテリ充電量が残っていない場合、サンプリングデーモン３１＿１０２は、リモートアドミッション制御要求に応じて「ｎｏ」値を、識別サービスデーモン３１＿１６２０に送信し得る。従って、対象メッセージの処理に十分な残りのバッテリ充電量をピアデバイスが有している場合、識別サービスデーモン３１＿１６２０は、ピアデバイス（例えば、モバイルデバイス３１＿１６００）との通信を開始する。

一部の実装では、サンプリングデーモン３１＿１０２が高優先メッセージを通知されると、サンプリングデーモン３１＿１０２は、現在のバッテリ状態情報（例えば、現在の充電レベル）を識別サービスデーモン３１＿１６２０に送信し得る。識別サービスデーモン３１＿１６２０は続いて、そのバッテリ状態情報を高優先メッセージに追加し得る。従って、バッテリ状態情報（又は、他の情報、例えば、熱レベル、フォアグランドアプリケーションなど）を、モバイルデバイス３１＿１００とモバイルデバイス３１＿１６００との間で送信される他のメッセージ上で抱き合わせで運搬することにより、システム状態情報はデバイス間で効率的にシェアされ得る。

一部の実装では、サンプリングデーモン３１＿１０２は、リトライメッセージを識別サービスデーモン３１＿１６２０に送信し得る。例えば、モバイルデバイス３１＿１００又はモバイルデバイス３１＿１６００上の条件が変わると（例えば、バッテリ条件が改善する）、サンプリングデーモン３１＿１０２は、リトライメッセージを識別サービスデーモン３１＿１６２０に送信し得る。一部の実装では、リモートフォーカルアプリケーションが変わると、リトライメッセージが生成され得る。例えば、リモートピアデバイス上のユーザが「ｍａｉｌａｐｐ」アプリケーションを使用する場合、「ｍａｉｌａｐｐ」アプリケーションがフォーカルアプリケーションとなる。ユーザが「ｗｅｂｂｒｏｗｓｅｒ」アプリケーションの使用を開始すると、フォーカルアプリケーションは「ｗｅｂｂｒｏｗｓｅｒ」アプリケーションに変わる。フォーカルアプリケーションの変更は、イベントとしてサンプリングデーモン３１＿１６０２に報告され、モバイルデバイス３１＿１００とモバイルデバイス３１＿１６００との間でピアデータが交換される際に、サンプリングデーモン３１＿１０２に送信され得る。フォーカルアプリケーションの変更を示すイベント情報がピアデバイス３１＿１６０２にて受信されると、サンプリングデーモン３１＿１０２は、リトライメッセージを識別サービスデーモン３１＿１６２０に送信し得る。識別サービスデーモン３１＿１６２０は続いて、サンプリングデーモン３１＿１０２により拒否された各メッセージに対するアドミッション制御をリトライし得る。例えば、識別サービスデーモン３１＿１６２０は、拒否されたメッセージ（例えば、送信タスク）を記憶し、リトライメッセージをサンプリングデーモン３１＿１０２から受信すると、その拒否されたメッセージを、アドミッション制御を通して送信し得る。一部の実装では、拒否されたメッセージは、ある期間の経過後に送信され得る。例えば、アドミッション制御を通過していないメッセージは、構成変更可能な期間の経過後に、ピアデバイスに送信され得る。

一部の実装では、モバイルデバイス３１＿１００又はモバイルデバイス３１＿１６００上の条件が変更されたことをサンプリングデーモン３１＿１０２が示す場合、識別サービスデーモン３１＿１６２０は、データストリーム送信を中断し得る。例えば、モバイルデバイスの１つがバッテリ電力を使い果たした可能性があるといった、モバイルデバイス３１＿１００又はモバイルデバイス３１＿１６００上のバッテリ条件が変わったことをサンプリングデーモン３１＿１０２が判定する場合、サンプリングデーモン３１＿１０２は、データストリームに関連付けられた属性イベントに対する送信を停止してアドミッション制御をリトライするよう、識別サービスデーモン３１＿１６２０に伝え得る。
ピアデバイス間でデータをシェアするためのプロセス

図３１－１７は、ピアデバイス間でデータをシェアするためのプロセス例３１＿１７００を示す。プロセス３１＿１７００についての追加詳細は、図３１－１６を参照して上記に見ることができる。ステップ３１＿１７０２にて、モバイルデバイスは、イベントデータをピアデバイスから受信し得る。例えば、イベントデータは、「ｄｉｇｅｓｔｓ」（例えば、予想、統計など）として、又は、生の（例えば、未処理の）イベントデータとして、シェアされ得る。例えば、第２のデバイス（例えば、モバイルデバイス３１＿１６００）は、その第２のデバイス及びモバイルデバイスが同じユーザにより所有されている場合、モバイルデバイス３１＿１００のピアデバイスである。モバイルデバイス３１＿１００は、モバイルデバイス３１＿１６００のシステム状態（例えば、バッテリ状態、ネットワーク状態、フォアグランドアプリケーション識別子など）に関連するイベントデータを受信し得る。モバイルデバイスは、モバイルデバイス３１＿１６００上で発生するイベントに基づく属性イベント予想、統計、又は生のイベントデータを、モバイルデバイス３１＿１６００から受信し得る。例えば、ピアデバイス３１＿１６００上のアプリケーション３１＿１６０８は、ピアデバイス３１＿１６００上のサンプリングデーモン３１＿１６０２に、特定の属性又は属性値に対する予想を生成し、モバイルデバイス３１＿１００に送信するよう指示し得る。

ステップ３１＿１７０４にて、モバイルデバイス３１＿１００上の識別サービスデーモン３１＿１６２０は、ピアデバイス３１＿１６００に送信するためのメッセージを受信し得る。例えば、モバイルデバイス上で実行されるアプリケーション３１＿１０８は、データの、ピアデバイス３１＿１６００上の対応するアプリケーション３１＿１６０８とのシェア、交換、又は同期を必要としてよい。アプリケーション３１＿１０８は、シェアされるデータを含むメッセージを、識別サービスデーモン３１＿１６２０に送信し得る。

ステップ３１＿１７０６にて、モバイルデバイス１００上のサンプリングデーモン３１＿１０２は、ピアデバイス３１＿１６００から受信したデータに基づいて、メッセージを送信するか否かを判定し得る。例えば、サンプリングデーモン３１＿１０２は、ローカルアドミッション制御チェック及びリモートアドミッション制御チェックを実行し、メッセージが現在時刻にピアデバイス３１＿１６００に送信されるべきか否かを判定し得る。ピアデバイス３１＿１６００のユーザが現在時刻にアプリケーション３１＿１６０８を呼び出す可能性があることを、ピアデバイス３１＿１６００から受信した属性イベント予想が示す場合、かつ、ピアデバイス３１＿１６００の条件（例えば、バッテリ状態、熱レベルなど）が、ピアデバイス３１＿１６００との通信を開始することがバッテリを使い果たすことはなく、又は、熱状態を悪化させないようなものであると、イベントデータが示す場合、続いてサンプリングデーモン３１＿１０２は、メッセージの送信を承認し得る。

ステップ３１＿１７０８にて、サンプリングデーモン３１＿１０２がアドミッション制御を実行し、ピアデバイス３１＿１６００との通信を開始することを承認すると、識別サービスデーモン３１＿１６２０は、ピアデバイス３１＿１６００にメッセージを送信し得る。例えば、識別サービスデーモン３１＿１６２０は、ピアデバイス３１＿１６００の識別サービスデーモン３１＿１６１０にメッセージを送信し得る。識別サービスデーモン３１＿１６１０は続いて、アプリケーション３１＿１６０８にメッセージを送信し得、アプリケーション３１＿１０８及びアプリケーション３１＿１６０８がデータを同期し得るようにする。

（例えば、図１Ａのデバイス１００の）メモリはまた、他のソフトウェア命令を記憶し、図３１－１～図３１－１７を参照して説明するような動的調整プロセス及び機能などの、セクション１に説明するプロセス及び機能を促進してよい。
モバイルデバイスの動的調整の方法、システム、及びコンピュータ可読媒体例

（例えば、図１Ａのデバイス１００の）メモリはまた、他のソフトウェア命令を記憶し、図３１－１～図３１－１７を参照して説明するような動的調整プロセス及び機能などの、セクション１に説明するプロセス及び機能を促進してよい。

１つの態様では、モバイルデバイスは、モバイルデバイス及び／又はピアデバイスに関連付けられた環境、システム、及びユーザイベントを監視するよう構成され得る。１つ以上のイベントの発生は、システム設定に対する調整をトリガーし得る。モバイルデバイスは、ユーザによる、予測された呼び出しの予想に基づいて、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。一部の実装では、モバイルデバイスは、アプリケーションに対する新たなコンテンツが利用可能で、ダウンロード可能であることを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。モバイルデバイスは、プッシュ通知に関連付けられたアプリケーションをバックグラウンドで起動し、新たなコンテンツをダウンロードし得る。一部の実装では、モバイルデバイスは、アプリケーションを実行する前に、又は、ピアデバイスと通信する前に、モバイルデバイス及び／又はピアデバイスのエネルギ及びデータ割当量並びに環境条件をチェックし、高品質なユーザエクスペリエンスを確かにするよう構成され得る。

一部の実装では、方法が提供される。この方法は、モバイルデバイスにて、ピアデバイス上で発生したイベントを説明する属性イベントデータを、ピアデバイスから受信することと、ピアイベントデータを、モバイルデバイスにて記憶することと、ピアデバイス上の対応するアプリケーションに対する識別子に対応する値を有する属性を含む要求であって、ピアデバイスと通信することの要求を、モバイルデバイス上のアプリケーションから受信することと、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することと、を含む。

一部の実装では、ピアデバイス及びモバイルデバイスは、単一のユーザにより所有される。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することは、ピアイベントデータに基づいて、属性に対する１つ以上の予想を生成することを含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することは、ピアイベントデータに基づいて、ピアデバイスのバッテリ状態を判定することを含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することは、ピアイベントデータに基づいて、ピアデバイスの熱状態を判定することを含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することは、ユーザが、現在時刻前後に、ピアデバイス上の対応するアプリケーションを呼び出す可能性があると判定することを含む。

一部の実装では、非一時的コンピュータ可読記憶媒体が提供され、この非一時的コンピュータ可読記憶媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイスに、ピアデバイス上で発生したイベントを説明する属性イベントデータをピアデバイスから受信させ、ピアイベントデータを、モバイルデバイスにて記憶させ、ピアデバイス上の対応するアプリケーションに対する識別子に対応する値を有する属性を含む要求であって、ピアデバイスと通信することの要求を、モバイルデバイス上のアプリケーションから受信させ、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定すさせる。

一部の実装では、ピアデバイス及びモバイルデバイスは、単一のユーザにより所有される。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ピアイベントデータに基づいて、属性に対する１つ以上の予想を生成することを引き起こす命令を含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ピアイベントデータに基づいて、ピアデバイスのバッテリ状態を判定することを引き起こす命令を含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ピアイベントデータに基づいて、ピアデバイスの熱状態を判定することを引き起こす命令を含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ユーザが、現在時刻前後に、ピアデバイス上の対応するアプリケーションを呼び出す可能性があると判定することを引き起こす命令を含む。

一部の実装では、システムが提供され、このシステムは、１つ以上のプロセッサと、非一時的コンピュータ可読媒体と、を含み、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイスにて、ピアデバイス上で発生したイベントを説明する属性イベントデータをピアデバイスから受信することと、ピアイベントデータを、モバイルデバイスにて記憶することと、ピアデバイス上の対応するアプリケーションに対する識別子に対応する値を有する属性を含む要求であって、ピアデバイスと通信することの要求を、モバイルデバイス上のアプリケーションから受信することと、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することと、を引き起こす。

一部の実装では、ピアデバイス及びモバイルデバイスは、単一のユーザにより所有される。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ピアイベントデータに基づいて、属性に対する１つ以上の予想を生成することを引き起こす命令を含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ピアイベントデータに基づいて、ピアデバイスのバッテリ状態を判定することを引き起こす命令を含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ピアイベントデータに基づいて、ピアデバイスの熱状態を判定することを引き起こす命令を含む。一部の実装では、ピアイベントデータに基づいて、モバイルデバイスにより、ピアデバイスと通信を開始すると判定することを引き起こす命令は、ユーザが、現在時刻前後に、ピアデバイス上の対応するアプリケーションを呼び出す可能性があると判定することを引き起こす命令を含む。

別の態様では、モバイルデバイスは、環境、システム、及びユーザイベントを監視するよう構成され得る。１つ以上のイベントの発生は、システム設定に対する調整をトリガーし得る。一部の実装では、モバイルデバイスは、ユーザによる、予測された呼び出しの予想に基づいて、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。一部の実装では、モバイルデバイスは、アプリケーションに対する新たなコンテンツが利用可能で、ダウンロード可能であることを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。モバイルデバイスは、プッシュ通知に関連付けられたアプリケーションをバックグラウンドで起動し、新たなコンテンツをダウンロードし得る。一部の実装では、モバイルデバイスは、アプリケーションを実行又はネットワークインタフェースにアクセスする前に、モバイルデバイスのエネルギ及びデータ割当量並びに環境条件をチェックし、高品質なユーザエクスペリエンスを保持するよう構成され得る。

一部の実装では、方法が提供され、この方法は、モバイルデバイス上で実行される第１のプロセスにてイベントデータを受信することと、モバイルデバイス上で実行される第２のプロセスであって、その第２のプロセスの呼び出しをトリガーするための１つ以上のイベントを特定するイベント登録データを受信した後にサスペンド又は終了される第２のプロセスから、そのイベント登録データを受信することと、第１のプロセスにより、１つ以上のイベントが発生したことを、イベントデータに基づいて判定することと、モバイルデバイス上で第２のプロセスを呼び出すことと、を含む。

一部の実装では、第２のプロセスを呼び出すことは、第２のプロセスに、モバイルデバイスの１つ以上の構成要素を調整させる。一部の実装では、１つ以上の構成要素は、モバイルデバイスの中央処理装置、グラフィック処理ユニット、ベースバンドプロセッサ、又はディスプレイを含む。一部の実装では、１つ以上のイベントは、モバイルデバイスの作動温度の変化、システム設定の変化、ユーザ入力、ディスプレイのオン又はオフ、クロックアラームを設定すること、又はカレンダーイベントを設定することを含む。一部の実装では、この方法はまた、第１のプロセスにて、第２のプロセスから、第２のプロセスにより記憶されるイベントデータについての要求を受信することと、第１のプロセスから、第２のプロセスであって、イベントデータに基づいて、モバイルデバイスの１つ以上の構成要素を調整するよう構成された第２のプロセスに、要求されたイベントデータを送信することと、を含む。一部の実装では、１つ以上のイベントは、イベントのパターンを含み、第１のプロセスは、受信したイベントデータ内のパターンを特定し、イベントのパターンが検出されると、第２のプロセスを呼び出すよう構成されている。

一部の実装では、非一時的コンピュータ可読媒体が提供され、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上で実行される第１のプロセスにてイベントデータを受信することと、モバイルデバイス上で実行される第２のプロセスであって、その第２のプロセスの呼び出しをトリガーするための１つ以上のイベントを特定するイベント登録データを受信した後にサスペンド又は終了される第２のプロセスから、そのイベント登録データを受信することと、第１のプロセスにより、１つ以上のイベントが発生したことを、イベントデータに基づいて判定することと、モバイルデバイス上で第２のプロセスを呼び出すことと、を引き起こす。

一部の実装では、第２のプロセスを呼び出すことは、第２のプロセスに、モバイルデバイスの１つ以上の構成要素を調整させる。一部の実装では、１つ以上の構成要素は、モバイルデバイスの中央処理装置、グラフィック処理ユニット、ベースバンドプロセッサ、又はディスプレイを含む。一部の実装では、１つ以上のイベントは、モバイルデバイスの作動温度の変化、システム設定の変化、ユーザ入力、ディスプレイのオン又はオフ、クロックアラームを設定すること、又はカレンダーイベントを設定することを含む。一部の実装では、これらの命令は、第１のプロセスにて、第２のプロセスから、第２のプロセスにより記憶されるイベントデータについての要求を受信することと、第１のプロセスから、第２のプロセスであって、イベントデータに基づいて、モバイルデバイスの１つ以上の構成要素を調整するよう構成された第２のプロセスに、要求されたイベントデータを送信することと、を引き起こす。一部の実装では、１つ以上のイベントは、イベントのパターンを含み、第１のプロセスは、受信したイベントデータ内のパターンを特定し、イベントのパターンが検出されると、第２のプロセスを呼び出すよう構成されている。

一部の実装では、システムが提供され、このシステムは、１つ以上のプロセッサと、非一時的コンピュータ可読媒体と、を含み、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上で実行される第１のプロセスにてイベントデータを受信することと、モバイルデバイス上で実行される第２のプロセスであって、その第２のプロセスの呼び出しをトリガーするための１つ以上のイベントを特定するイベント登録データを受信した後にサスペンド又は終了される第２のプロセスから、そのイベント登録データを受信することと、第１のプロセスにより、１つ以上のイベントが発生したことを、イベントデータに基づいて判定することと、モバイルデバイス上で第２のプロセスを呼び出すことと、を引き起こす。

一部の実装では、第２のプロセスを呼び出すことは、第２のプロセスに、モバイルデバイスの１つ以上の構成要素を調整させる。一部の実装では、１つ以上の構成要素は、モバイルデバイスの中央処理装置、グラフィック処理ユニット、ベースバンドプロセッサ、又はディスプレイを含む。一部の実装では、１つ以上のイベントは、モバイルデバイスの作動温度の変化、システム設定の変化、ユーザ入力、ディスプレイのオン又はオフ、クロックアラームを設定すること、又はカレンダーイベントを設定することを含む。一部の実装では、これらの命令は、第１のプロセスにて、第２のプロセスから、第２のプロセスにより記憶されるイベントデータについての要求を受信することと、第１のプロセスから、第２のプロセスであって、イベントデータに基づいて、モバイルデバイスの１つ以上の構成要素を調整するよう構成された第２のプロセスに、要求されたイベントデータを送信することと、を引き起こす。一部の実装では、１つ以上のイベントは、イベントのパターンを含み、第１のプロセスは、受信したイベントデータ内のパターンを特定し、イベントのパターンが検出されると、第２のプロセスを呼び出すよう構成されている。

更なる態様では、モバイルデバイスは、モバイルデバイス及び／又はピアデバイスに関連付けられた環境、システム、及びユーザイベントを監視するよう構成され得る。１つ以上のイベントの発生は、システム設定に対する調整をトリガーし得る。モバイルデバイスは、ユーザによる、予測された呼び出しの予想に基づいて、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。一部の実装では、モバイルデバイスは、その新たなコンテンツを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。

一部の実装では、方法が提供され、この方法は、モバイルデバイス上にて実行される第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベントが、複数の属性であって、複数の属性のそれぞれが割当量に関連付けられている複数の属性の１つに関連付けられたデータを含むイベントであって、対応するコストを有するイベントを受信することと、モバイルデバイスにより受信された特定の属性に関連付けられたイベントのコストに基づいて、特定の属性に対する割当量を減らすことと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、イベントのコストを、特定の属性に対する残りの割当量と比較することと、第１のプロセスにより、比較に基づいて、特定の属性に関連付けられたイベントを許可すると判定することと、を含む。

一部の実装では、複数の属性の少なくとも１つは、クライアントにより、ランタイムにて、動的に定義される。一部の実装では、イベントを許可すると判定することは、属性に関連付けられたイベントがいつ発生する可能性があるかを示す、特定の属性に対する予想を生成することを含む。一部の実装では、イベントを許可すると判定することは、イベントのコストをカバーするのに十分な割当量が残っていると判定することを含む。一部の実装では、特定の属性に対する割当量は、クライアントにより動的に定義される。一部の実装では、割当量は、システムワイドデータ割当量の一部に対応する。一部の実装では、割当量は、システムワイドエネルギ割当量の一部に対応する。

一部の実装では、非一時的コンピュータ可読媒体が提供され、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上にて実行される第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベントが、複数の属性であって、複数の属性のそれぞれが割当量に関連付けられている複数の属性の１つに関連付けられたデータを含むイベントであって、対応するコストを有するイベントを受信することと、モバイルデバイスにより受信された特定の属性に関連付けられたイベントのコストに基づいて、特定の属性に対する割当量を減らすことと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、イベントのコストを、特定の属性に対する残りの割当量と比較することと、第１のプロセスにより、比較に基づいて、特定の属性に関連付けられたイベントを許可すると判定することと、を引き起こす。

一部の実装では、複数の属性の少なくとも１つは、クライアントにより、ランタイムにて、動的に定義される。一部の実装では、イベントを許可すると判定することを引き起こす命令は、属性に関連付けられたイベントがいつ発生する可能性があるかを示す、特定の属性に対する予想を生成することを引き起こす命令を含む。一部の実装では、イベントを許可すると判定することを引き起こす命令は、イベントのコストをカバーするのに十分な割当量が残っていると判定することを引き起こす命令を含む。一部の実装では、特定の属性に対する割当量は、クライアントにより動的に定義される。一部の実装では、割当量は、システムワイドデータ割当量の一部に対応する。一部の実装では、割当量は、システムワイドエネルギ割当量の一部に対応する。

一部の実装では、システムが提供され、このシステムは、１つ以上のプロセッサと、コンピュータ可読媒体と、を含み、このコンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上にて実行される第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベントが、複数の属性であって、複数の属性のそれぞれが割当量に関連付けられている複数の属性の１つに関連付けられたデータを含むイベントであって、対応するコストを有するイベントを受信することと、モバイルデバイスにより受信された特定の属性に関連付けられたイベントのコストに基づいて、特定の属性に対する割当量を減らすことと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、イベントのコストを、特定の属性に対する残りの割当量と比較することと、第１のプロセスにより、比較に基づいて、特定の属性に関連付けられたイベントを許可すると判定することと、を引き起こす。

一部の実装では、複数の属性の少なくとも１つは、クライアントにより、ランタイムにて、動的に定義される。一部の実装では、イベントを許可すると判定することを引き起こす命令は、属性に関連付けられたイベントがいつ発生する可能性があるかを示す、特定の属性に対する予想を生成することを引き起こす命令を含む。一部の実装では、イベントを許可すると判定することを引き起こす命令は、イベントのコストをカバーするのに十分な割当量が残っていると判定することを引き起こす命令を含む。一部の実装では、特定の属性に対する割当量は、クライアントにより動的に定義される。一部の実装では、割当量は、システムワイドデータ割当量の一部に対応する。一部の実装では、割当量は、システムワイドエネルギ割当量の一部に対応する。

更に別の態様では、モバイルデバイスは、モバイルデバイス及び／又はピアデバイスに関連付けられた環境、システム、及びユーザイベントを監視するよう構成され得る。１つ以上のイベントの発生は、システム設定に対する調整をトリガーし得る。モバイルデバイスは、ユーザによる、予測された呼び出しの予想に基づいて、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。一部の実装では、モバイルデバイスは、アプリケーションに対する新たなコンテンツが利用可能で、ダウンロード可能であることを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。モバイルデバイスは、プッシュ通知に関連付けられたアプリケーションをバックグラウンドで起動し、新たなコンテンツをダウンロードし得る。一部の実装では、モバイルデバイスは、アプリケーションを実行する前に、又は、ピアデバイスと通信する前に、モバイルデバイス及び／又はピアデバイスのエネルギ及びデータ割当量並びに環境条件をチェックし、高品質なユーザエクスペリエンスを確かにするよう構成され得る。

一部の実装では、方法が提供され、この方法は、第１のプロセスにより、コンピューティングデバイス上で実行されている１つ以上のプラグインプロセスから、そのプラグインプロセスを、１つ以上の投票プロセスとして登録することの要求を受信することと、第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベンドが、複数の属性の１つに関連付けられたデータを含むイベントを受信することと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、各登録された投票プロセスに、特定の属性を識別する情報を送信することと、各登録された投票プロセスに、特定の属性を識別する情報を送信したことに応じて、登録された投票プロセスの少なくとも１つからの投票を受信することと、第１のプロセスにより、特定の属性に関連付けられたイベントを、投票に基づいて許可すると判定することと、を含む。

一部の実装では、１つ以上の投票プロセスは、ランタイムにて、第１のプロセスに動的に差し込まれる。一部の実装では、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性に関連付けられたイベントを許可すると判定することは、各投票プロセスに、特定の属性を識別する情報を送信することと、特定の属性に関連付けられたイベントの発生が許可されるべきであると、各投票プロセスが判定すると、投票プロセスのそれぞれからｙｅｓ投票を受信することと、を含む。一部の実装では、この方法は、第１のプロセスが、１つ以上の投票プロセスの少なくとも１つからｎｏ投票を受信すると、第１のプロセスにより、第２の属性に関連付けられた第２のイベントを阻止すると判定することを含む。一部の実装では、この方法は、投票プロセスの少なくとも１つから、特定の属性に関連付けられた予想についての要求を受信することと、要求された予想を生成することと、要求された予想を、その少なくとも１つの投票プロセスに返すことと、を含む。一部の実装では、この方法は、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性値に関連付けられた第３のイベントを許可すると判定することを含む。一部の実装では、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性値に関連付けられた第３のイベントを許可すると判定することは、各投票プロセスに、特定の属性値を識別する情報を送信することと、特定の属性値に関連付けられたイベントの発生が許可されるべきであると、各投票プロセスが判定すると、投票プロセスのそれぞれからｙｅｓ投票を受信することと、を含む。

一部の実装では、非一時的コンピュータ可読媒体が提供され、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、第１のプロセスにより、コンピューティングデバイス上で実行されている１つ以上のプラグインプロセスから、そのプラグインプロセスを、１つ以上の投票プロセスとして登録することの要求を受信すること、第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベンドが、複数の属性の１つに関連付けられたデータを含むイベントを受信することと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、各登録された投票プロセスに、特定の属性を識別する情報を送信することと、各登録された投票プロセスに、特定の属性を識別する情報を送信したことに応じて、登録された投票プロセスの少なくとも１つからの投票を受信することと、第１のプロセスにより、特定の属性に関連付けられたイベントを、投票に基づいて許可すると判定することと、を引き起こす。

一部の実装では、１つ以上の投票プロセスは、ランタイムにて、第１のプロセスに動的に差し込まれる。一部の実装では、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性に関連付けられたイベントを許可すると判定することを引き起こす命令は、各投票プロセスに、特定の属性を識別する情報を送信することと、特定の属性に関連付けられたイベントの発生が許可されるべきであると、各投票プロセスが判定すると、投票プロセスのそれぞれからｙｅｓ投票を受信することと、を引き起こす命令を含む。一部の実装では、これらの命令は、第１のプロセスが、１つ以上の投票プロセスの少なくとも１つからｎｏ投票を受信すると、第１のプロセスにより、第２の属性に関連付けられた第２のイベントを阻止すると判定することを引き起こす。一部の実装では、これらの命令は、投票プロセスの少なくとも１つから、特定の属性に関連付けられた予想についての要求を受信することと、要求された予想を生成することと、要求された予想を、その少なくとも１つの投票プロセスに返すことと、を引き起こす。一部の実装では、これらの命令は、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性値に関連付けられた第３のイベントを許可すると判定することを引き起こす。一部の実装では、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性値に関連付けられた第３のイベントを許可すると判定することを引き起こす命令は、各投票プロセスに、特定の属性値を識別する情報を送信することと、特定の属性値に関連付けられたイベントの発生が許可されるべきであると、各投票プロセスが判定すると、投票プロセスのそれぞれからｙｅｓ投票を受信することと、を引き起こす命令を含む。

一部の実装では、システムが提供され、このシステムは、１つ以上のプロセッサと、コンピュータ可読媒体と、を含み、このコンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、第１のプロセスにより、コンピューティングデバイス上で実行されている１つ以上のプラグインプロセスから、そのプラグインプロセスを、１つ以上の投票プロセスとして登録することの要求を受信することと、第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベンドが、複数の属性の１つに関連付けられたデータを含むイベントを受信することと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、各登録された投票プロセスに、特定の属性を識別する情報を送信することと、各登録された投票プロセスに、特定の属性を識別する情報を送信したことに応じて、登録された投票プロセスの少なくとも１つからの投票を受信することと、第１のプロセスにより、特定の属性に関連付けられたイベントを、投票に基づいて許可すると判定することと、を引き起こす。

一部の実装では、１つ以上の投票プロセスは、ランタイムにて、第１のプロセスに動的に差し込まれる。一部の実装では、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性に関連付けられたイベントを許可すると判定することを引き起こす命令は、各投票プロセスに、特定の属性を識別する情報を送信することと、特定の属性に関連付けられたイベントの発生が許可されるべきであると、各投票プロセスが判定すると、投票プロセスのそれぞれからｙｅｓ投票を受信することと、を引き起こす命令を含む。一部の実装では、これらの命令は、第１のプロセスが、１つ以上の投票プロセスの少なくとも１つからｎｏ投票を受信すると、第１のプロセスにより、第２の属性に関連付けられた第２のイベントを阻止すると判定することを引き起こす。一部の実装では、これらの命令は、投票プロセスの少なくとも１つから、特定の属性に関連付けられた予想についての要求を受信することと、要求された予想を生成することと、要求された予想を、その少なくとも１つの投票プロセスに返すことと、を引き起こす。一部の実装では、これらの命令は、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性値に関連付けられた第３のイベントを許可すると判定することを引き起こす。一部の実装では、第１のプロセスにより、１つ以上の投票プロセスからのフィードバックに基づいて、特定の属性値に関連付けられた第３のイベントを許可すると判定することを引き起こす命令は、各投票プロセスに、特定の属性値を識別する情報を送信することと、特定の属性値に関連付けられたイベントの発生が許可されるべきであると、各投票プロセスが判定すると、投票プロセスのそれぞれからｙｅｓ投票を受信することと、を引き起こす命令を含む。

１つの他の態様では、モバイルデバイスは、モバイルデバイス及び／又はピアデバイスに関連付けられた環境、システム、及びユーザイベントを監視するよう構成され得る。１つ以上のイベントの発生は、システム設定に対する調整をトリガーし得る。モバイルデバイスは、ユーザによる、予測された呼び出しの予想に基づいて、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。一部の実装では、モバイルデバイスは、アプリケーションに対する新たなコンテンツが利用可能で、ダウンロード可能であることを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。モバイルデバイスは、プッシュ通知に関連付けられたアプリケーションをバックグラウンドで起動し、新たなコンテンツをダウンロードし得る。一部の実装では、モバイルデバイスは、アプリケーションを実行する前に、又は、ピアデバイスと通信する前に、モバイルデバイス及び／又はピアデバイスのエネルギ及びデータ割当量並びに環境条件をチェックし、高品質なユーザエクスペリエンスを確かにするよう構成され得る。

一部の実装では、方法が提供され、この方法は、モバイルデバイス上にて実行される第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベンドが、複数の属性の１つに関連付けられたデータを含むイベントを受信することと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、記憶されたイベントデータ内の属性のそれぞれに対して、１つ以上のイベント予想を生成することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、第１のプロセスにより、特定の属性に対して生成された予想に基づいて、特定の属性に関連付けられたイベントを許可すると判定することと、を含む。

一部の実装では、１つ以上の予想は、ある属性に関連付けられたイベントがある期間内に発生する可能性を予測する。一部の実装では、１つ以上の予想は、ピア予想を含む。一部の実装では、１つ以上の予想は、時間的予想を含む。一部の実装では、１つ以上の予想は、イベントデータストア内の特定の属性の発生の頻度に基づく頻度予想を含む。一部の実装では、１つ以上の予想は、特定の属性とは異なる属性に関連付けられたイベントに基づくパノラマ予想を含む。一部の実装では、この方法は、複数の予想タイプのそれぞれが、受信したイベントの発生をどれほど良好に予測するかに基づいて、既定予想タイプを判定することを含む。一部の実装では、複数の予想タイプは、頻度予想タイプと、パノラマ予想タイプと、を含む。

一部の実装では、非一時的コンピュータ可読媒体が提供され、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上にて実行される第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベンドが、複数の属性の１つに関連付けられたデータを含むイベントを受信することと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、記憶されたイベントデータ内の属性のそれぞれに対して、１つ以上のイベント予想を生成することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、第１のプロセスにより、特定の属性に対して生成された予想に基づいて、特定の属性に関連付けられたイベントを許可すると判定することと、を引き起こす。

一部の実装では、１つ以上の予想は、ある属性に関連付けられたイベントがある期間内に発生する可能性を予測する。一部の実装では、１つ以上の予想は、ピア予想を含む。一部の実装では、１つ以上の予想は、時間的予想を含む。一部の実装では、１つ以上の予想は、イベントデータストア内の特定の属性の発生の頻度に基づく頻度予想を含む。一部の実装では、１つ以上の予想は、特定の属性とは異なる属性に関連付けられたイベントに基づくパノラマ予想を含む。一部の実装では、これらの命令は、複数の予想タイプのそれぞれが、受信したイベントの発生をどれほど良好に予測するかに基づいて、既定予想タイプを判定することを引き起こす。一部の実装では、複数の予想タイプは、頻度予想タイプと、パノラマ予想タイプと、を含む。

一部の実装では、システムが提供され、このシステムは、１つ以上のプロセッサと、非一時的コンピュータ可読媒体と、を含み、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上にて実行される第１のプロセスにより、１つ以上のクライアントプロセスにより生成されたイベントであって、各イベンドが、複数の属性の１つに関連付けられたデータを含むイベントを受信することと、イベントデータを、モバイルデバイス上のイベントデータストアに記憶することと、記憶されたイベントデータ内の属性のそれぞれに対して、１つ以上のイベント予想を生成することと、第１のプロセスにより、クライアントプロセスから、特定の属性に関連付けられたイベントを開始することの要求を受信することと、第１のプロセスにより、特定の属性に対して生成された予想に基づいて、特定の属性に関連付けられたイベントを許可すると判定することと、を引き起こす。

一部の実装では、１つ以上の予想は、ある属性に関連付けられたイベントがある期間内に発生する可能性を予測する。一部の実装では、１つ以上の予想は、ピア予想を含む。一部の実装では、１つ以上の予想は、時間的予想を含む。一部の実装では、１つ以上の予想は、イベントデータストア内の特定の属性の発生の頻度に基づく頻度予想を含む。一部の実装では、１つ以上の予想は、特定の属性とは異なる属性に関連付けられたイベントに基づくパノラマ予想を含む。一部の実装では、これらの命令は、複数の予想タイプのそれぞれが、受信したイベントの発生をどれほど良好に予測するかに基づいて、既定予想タイプを判定することを引き起こす。一部の実装では、複数の予想タイプは、頻度予想タイプと、パノラマ予想タイプと、を含む。

更なる追加態様では、モバイルデバイスは、モバイルデバイス及び／又はピアデバイスに関連付けられた環境、システム、及びユーザイベントを監視するよう構成され得る。１つ以上のイベントの発生は、システム設定に対する調整をトリガーし得る。モバイルデバイスは、ユーザによる、予測された呼び出しの予想に基づいて、頻繁に呼び出されるアプリケーションを最新に維持するよう構成され得る。一部の実装では、モバイルデバイスは、アプリケーションに対する新たなコンテンツが利用可能で、ダウンロード可能であることを示す、アプリケーションに関連付けられたプッシュ通知を受信し得る。モバイルデバイスは、プッシュ通知に関連付けられたアプリケーションをバックグラウンドで起動し、新たなコンテンツをダウンロードし得る。一部の実装では、モバイルデバイスは、アプリケーションを実行する前に、又は、ピアデバイスと通信する前に、モバイルデバイス及び／又はピアデバイスのエネルギ及びデータ割当量並びに環境条件をチェックし、高品質なユーザエクスペリエンスを確かにするよう構成され得る。

一部の実装では、方法が提供され、この方法は、モバイルデバイス上にて実行される熱管理デーモンにて、ある属性の指定された値に関連付けられたイベントの発生の許可について投票することの要求を受信することと、サンプリングデーモンからの、その属性についてのピア予想を要求することと、その属性に関連付けられ、現在時刻付近で発生すると予測された複数の値のそれぞれに対するスコアを受信することと、指定された属性値のスコアに基づいて、イベントを許可するよう投票することと、を含む。

一部の実装では、この方法は、複数の値の中の、ある数の最高スコアの属性値を判定することと、指定された属性値が、ある数の最高スコアの属性値の中に含まれる場合に、そのイベントを許可するよう投票することと、を含む。一部の実装では、この方法は、指定された属性値が、複数の値の中に含まれない場合に、イベントを阻止するよう投票することを含む。一部の実装では、この方法は、複数の値内の、ある数の最低スコアの属性値を判定することと、指定された属性値が、ある数の最低スコアの属性値の中に含まれる場合に、イベントを阻止するよう投票することと、を含む。一部の実装では、この方法は、モバイルデバイスの現在の作動温度に基づいて、ある数の最低スコアの属性値を判定することを含む。一部の実装では、この方法は、現在の作動温度が、作動温度の範囲内のどこにあるかに基づいて、ある数の最低スコアの属性値を判定することを含む。

一部の実装では、非一時的コンピュータ可読媒体が提供され、この非一時的コンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上にて実行される熱管理デーモンにて、ある属性の指定された値に関連付けられたイベントの発生の許可について投票することの要求を受信することと、サンプリングデーモンからの、その属性についてのピア予想を要求することと、その属性に関連付けられ、現在時刻付近で発生すると予測された複数の値のそれぞれに対するスコアを受信することと、指定された属性値のスコアに基づいて、イベントを許可するよう投票することと、を引き起こす。

一部の実装では、これらの命令は更に、複数の値の中の、ある数の最高スコアの属性値を判定することと、指定された属性値が、ある数の最高スコアの属性値の中に含まれる場合に、そのイベントを許可するよう投票することと、を引き起こす。一部の実装では、これらの命令は、指定された属性値が、複数の値の中に含まれない場合に、イベントを阻止するよう投票することを引き起こす。一部の実装では、これらの命令は、複数の値の中の、ある数の最低スコアの属性値を判定することと、指定された属性値が、ある数の最低スコアの属性値の中に含まれる場合に、イベントを阻止するよう投票することと、を引き起こす。一部の実装では、これらの命令は、モバイルデバイスの現在の作動温度に基づいて、ある数の最低スコアの属性値を判定することを引き起こす。一部の実装では、これらの命令は、現在の作動温度が、作動温度の範囲内のどこにあるかに基づいて、ある数の最低スコアの属性値を判定することを引き起こす。

一部の実装では、システムが提供され、このシステムは、１つ以上のプロセッサと、コンピュータ可読媒体と、を含み、このコンピュータ可読媒体は、１つ以上の命令のシーケンスを含み、これらの命令は、１つ以上のプロセッサにより実行されると、モバイルデバイス上にて実行される熱管理デーモンにて、ある属性の指定された値に関連付けられたイベントの発生の許可について投票することの要求を受信することと、サンプリングデーモンからの、その属性についてのピア予想を要求することと、その属性に関連付けられ、現在時刻付近で発生すると予測された複数の値のそれぞれに対するスコアを受信することと、指定された属性値のスコアに基づいて、イベントを許可するよう投票することと、を引き起こす。

一部の実装では、これらの命令は更に、複数の値の中の、ある数の最高スコアの属性値を判定することと、指定された属性値が、ある数の最高スコアの属性値の中に含まれる場合に、そのイベントを許可するよう投票することと、を引き起こす。一部の実装では、これらの命令は、指定された属性値が、複数の値の中に含まれない場合に、イベントを阻止するよう投票することを引き起こす。一部の実装では、これらの命令は、複数の値の中の、ある数の最低スコアの属性値を判定することと、指定された属性値が、ある数の最低スコアの属性値の中に含まれる場合に、イベントを阻止するよう投票することと、を引き起こす。一部の実装では、これらの命令は、モバイルデバイスの現在の作動温度に基づいて、ある数の最低スコアの属性値を判定することを引き起こす。一部の実装では、これらの命令は、現在の作動温度が、作動温度の範囲内のどこにあるかに基づいて、ある数の最低スコアの属性値を判定することを引き起こす。
セクション２：検索技術

このセクション「検索技術」における資料は、一部の実施形態に係る統合検索及びマルチドメインクエリ補完の実行、並びに引用検索インデックスにおけるユーザフィードバックの使用について説明しており、本明細書に記載されている開示内容を補足する情報を提供する。例えば、このセクションの複数部分が、複数の別個の検索ドメイン（例えば、マップ、人物、及び場所の検索）にわたるクエリから複数のランク付けされたクエリ結果を生成することについて記載しており、これらは、下記のとおり、本明細書に記載されている開示内容、例えば、方法８００及び図９Ｂ～図９Ｃの予測部分９３０をポピュレートすることに関連する開示内容を補足する。別の実施例として、このセクションの複数部分が、検索、及び検索補完の判定について記載しており、本明細書に記載されている開示内容、例えば、いずれのユーザ入力を受信せずに関連コンテンツを自動的に浮上させること（例えば、方法８００）に関連する開示内容、及び以前の検索履歴の使用と、ユーザが実施した以前の検索履歴に基づいて予測されたコンテンツを生成すること（例えば、図３Ａ～図３Ｂを参照して以下で説明）と、に関連する開示内容を補足する。もう１つの例として、このセクションの複数部分が、検索結果の提示を改善するために、検索結果とのユーザの相互作用を監視することについて記載しており、例えば、予測されたコンテンツの生成における以前の検索履歴の使用に関連する開示内容（例えば、図３Ａ～図３Ｂを参照して以下で説明）など、本明細書の開示内容を補足する。
検索技術の概要

マルチドメインクエリ検索を実行するデバイスの方法及び装置について説明する。例示的な実施形態において、このデバイスは、ユーザのクライアントからクエリプレフィックスを受信する。このデバイスは更に、複数の別個の検索ドメインにまたがる複数の検索補完を判定する。加えて、デバイスは、対応する検索ドメインによって判定された複数の検索補完の各々について計算されたスコアに基づいてこれら複数の検索補完をランク付けする。ここで、これら複数の検索補完のうちの少なくとも１つが、ユーザからのインジケーションなしで、かつクエリプレフィックスを受信したことに応答して複数の検索結果を生成するために使用される。

別の実施形態において、このデバイスは、ユーザの検索セッションからのフィードバックを使用して結果キャッシュを生成する。本実施形態において、このデバイスは、クライアントからフィードバックパッケージを受信する。フィードバックパッケージは、ユーザによって入力されたクエリプレフィックスに応答してユーザに提示される検索セッションにおける複数のクエリ結果とのユーザ相互作用を特徴付ける。デバイスは更に、検索フィードバックインデックスを使用して複数のクエリを実行し、複数の結果に到達することによって、複数のクエリに対する複数の結果を生成する。加えて、デバイスは、複数の結果から結果キャッシュを作成し、結果キャッシュは、複数の結果を複数のクエリにマッピングし、この結果キャッシュを使用してクエリ結果をクライアントにサーブする。

更なる実施形態において、デバイスは、複数の別個の検索ドメインにわたるクエリから複数のランク付けされたクエリ結果を生成する。本実施形態において、デバイスはクエリを受信し、そのクエリを使用して複数の別個の検索ドメインにまたがる複数の結果を判定する。デバイスは更に、クエリを特徴付ける。加えて、デバイスは、対応する検索ドメインと、クエリタイプを示すクエリ特徴付けと、によって判定された複数の結果の各々について計算されたスコアに基づき、複数の結果をランク付けする。

他の方法と装置についても説明する。
検索技術の詳細な説明

マルチドメインクエリ検索を実行するデバイスの方法及び装置について説明する。以下の説明では、本発明の実施形態の完全な説明を提供するために、数多くの具体的な詳細が記載される。しかしながら、本発明の実施形態は、これらの具体的な詳細を伴わずとも実践することができる点が、当業者には明らかとなるであろう。他の例では、本説明の理解を分かりにくくすることがないように、周知の構成要素、構造及び技術は、詳細には示されていない。

本明細書中での「一実施形態」又は「実施形態」への言及は、その実施形態に関連して説明される特定の機構、構造、又は特性を、本発明の少なくとも１つの実施形態に含めることができることを意味する。本明細書における様々な箇所での、語句「一実施形態では」の出現は、必ずしも全てが同じ実施形態を言及しているものではない。

以下の説明及び請求項において、「連結している」及び「接続されている」とともにこれらの派生語が使用される場合がある。これらの言葉は、互いに同義語として意図されていないことを理解すべきである。「連結している」は、相互に物理的又は電気的に直接接触していることも、していないこともある、２つ以上の要素が、互いに協働し、又は相互作用することを示すために使用される。「接続されている」は、相互に連結している２つ以上の要素間の通信の確立を示すために使用される。

以下の図で示されるプロセスは、ハードウェア（例えば、回路機構、専用論理など）、ソフトウェア（汎用コンピュータシステム、又は専用機械上で実行されるものなど）、又は両方の組み合わせを含む、処理論理によって実行される。それらのプロセスは、幾つかの逐次動作の観点から以下で説明されるが、説明される動作の一部は、異なる順序で実行することができる点を理解するべきである。

更には、一部の動作は、逐次的にではなく、並列して実行することができる。

「サーバ」、「クライアント」、「デバイス」という用語は、サーバ、クライアント及び／又はデバイスに特定のフォームファクタよりも、一般的にデータ処理システムに言及することを意図している。

マルチドメインクエリ検索を実行するデバイスの方法及び装置について説明する。一実施形態において、デバイスは、ユーザによって入力されたクライアントからのインクリメンタルクエリプレフィックスを受信し、このインクリメンタルクエリプレフィックスを使用して、クエリプレフィックスごとのクエリ補完のセットを生成する。例えば、一実施形態において、ユーザが文字列「ａｐｐｌｅ」を入力すると、デバイスは、「ａ」、「ａｐ」、「ａｐｐ」、「ａｐｐｌ」、及び「ａｐｐｌｅ」に対するインクリメンタルクエリプレフィックスを受信する。デバイスは、クエリプレフィックスごとにクエリ補完のセットを生成する。例えば、一実施形態において、「ａ」に対する補完は、「ａｐｐｌｅ．ｃｏｍ」、「Ａｍｅｒｉｃａ」、又は「Ａｎｎａｐｏｌｉｓ」であり得る。同様に、デバイスは、他のインクリメンタルクエリプレフィックスに対して異なるクエリ補完のセットを生成することができる。一実施形態において、デバイスは、複数の検索ドメインからのクエリ補完のセットを判定する。例えば、一実施形態において、デバイスは、マップ、メディア、ウィキ、サイトなどの検索ドメイン、及び他の検索ドメインにまたがってクエリ補完を検索する。一実施形態においては、これらの検索ドメインの各々が、入力されたクエリプレフィックスに対して補完候補を判定するために使用される１つ以上のクエリ補完ツリーを含む。一実施形態においては、検索ドメインの各々が、デバイスがこれらのクエリ補完をランク付けするために使用するスコアのセットを返す。例えば、一実施形態においては、検索ドメインの各々が、異なるドメインにまたがって異なる補完をランク付けするためにデバイスが使用できる生スコア、ローカルスコア、及びグローバルスコアのセットを返す。

上述のとおり、従来のシステムは、クエリ補完候補をユーザに返し、ユーザは、それらのクエリ補完候補のうちの１つを選択してクエリ検索に使用する。対照的に、かつ一実施形態においては、デバイスがクエリ補完のセットをユーザに返さない。代わりに、デバイスはクエリ補完のセットをランク付けし、クエリ補完のサブセットを使用して、クエリ補完のセットをユーザに提示したり、このクエリ補完のセットのうちのどれを使用して関連結果を判定するかを表すインジケーションを取得したりすることなく、このクエリ補完のサブセットに対する関連結果を判定する。一実施形態において、デバイスは、複数の検索ドメイン（例えば、マップ、メディア、ウィキ、サイト、その他、又は別の検索ドメイン）にまたがって関連結果の検索を実行する。デバイスは、複数の検索ドメインから結果のセットを受信し、各検索ドメイン及びクロスドメイン情報から生成されたスコアに基づいてこれらの結果をランク付けする。一実施形態において、デバイスは、これらの結果を判定するために使用されたクエリ補完のタイプに基づいて関連結果を更にランク付けする。例えば、一実施形態において、クエリ補完が場所の検索であると特徴付けられた場合には、この場所に関するウィキエントリだけでなく、マップ検索ドメインからの結果もより高くランク付けすることができる。更なる例として、このクエリ補完がアーティストに関するものであることが示された場合には、メディア検索ドメインの結果をより高くランク付けすることができる。デバイスは、このクエリ補完に対して見つかった関連結果をクライアントに返す。

一実施形態において、結果を参照したユーザは、これらの結果に関与するか、これらの結果を破棄し得る。一実施形態においては、ユーザの検索セッション中にユーザに提示されたレンダリング結果の１つとユーザが相互作用する場合に、関与イベントが発生する。例えば、一実施形態において、ユーザは、レンダリング結果の１つに対して提示されたリンクをクリックできる。別例においては、ユーザが、リンクをクリックし、そのリンクによって参照されるオブジェクト（例えば、ウェブサイト）と、所定の時間よりも長い時間を費やして相互作用し得る（例えば、参照されたオブジェクトと６０秒以上にわたって相互作用する）。この例においては、ユーザが、現在の米国大統領に対するクエリ検索に向けられた結果を受信し、最新の大統領スピーチを記載しているウェブページを参照するリンクをクリックし得る。ユーザが所定の時間（例えば、６０～９０秒）を超えてそのウェブサイトと相互作用した場合、デバイスは、ユーザがそのリンクによって表された結果を受け入れたと判定する。別の実施形態においては、ユーザが、自身に対してレンダリングされた結果を無視又は破棄し得る。例えば、一実施形態において、ユーザが、表示された結果の１つについて提示されたリンクをクリックしたものの、所定の時間内（例えば、６０～９０秒未満）にそのウェブサイトから離れた場合、デバイスは、これがその結果に対する破棄イベントであると判定する。

一実施形態において、関連結果のランク付け及びフィルタリングに影響するこのフィードバックは、検索インデックスに組み込むことができる。本実施形態において、関連結果を提示及びレンダリングするクライアントは、ユーザの検索セッションに対する関与及び破棄イベントを更に収集する。クライアントは、これらのイベントをフィードバックパッケージ内に収集し、このパッケージを処理のためにサーバに送信する。一実施形態においては、サーバが、

フィードバックパッケージを受信し、フィードバックパッケージをフィードバックインデックスエントリに変換する。一実施形態において、フィードバックインデックスエントリは、＜クエリ、結果、レンダリング回数、関与回数、破棄回数＞というフォーマットを有する。クエリは、デバイスタイプ、アプリケーション、ロケール、及び地理的位置などの入力クエリ及びコンテキスト情報であり、結果はレンダリング結果であり、レンダリング回数は、そのクエリに対して結果がレンダリングされた回数であり、関与回数はそのクエリに対して結果が関与された回数であり、破棄回数は、結果が破棄された回数である。このエントリは、フィードバック検索インデックスに組み込まれている。一実施形態において、フィードバック検索インデックスは、ユーザのフィードバックを採点結果に組み込む検索インデックスである。例えば、一実施形態においては、クエリ結果ペアに対する各関与イベントが、対応するクエリに対してその結果を促す。この例では、ユーザが特定のクエリに対する結果に関与すると、将来のユーザも同じクエリに対してこの結果に関与し得る。そのため、一実施形態においては、このクエリに対する結果が返され、同じクエリを有する将来のユーザに対して上位にランク付けされる。逆に、特定のクエリに対する結果を破棄すると、将来のユーザも同じクエリに対してこの同じ結果を破棄する可能性がある。そのため、一実施形態においては、このクエリに対する結果が返され、同じクエリを有する将来のユーザに対して下位にランク付けされ得る。

一実施形態において、サーバは、更にフィードバック検索インデックスを使用して、クエリを結果にマッピングする結果キャッシュを生成する。一実施形態において、結果キャッシュは、クエリを結果にマッピングするキャッシュであり、これを使用して、ユーザクエリに対する結果を素早く返すことができる。一実施形態において、結果キャッシュは、クエリ検索を実行する前に１つ以上の結果をサーブするために使用できるユーザのデバイスに近接しているエッジサーバに記憶されている。一実施形態において、サーバは、結果セットからクエリのセットを実行することによって結果キャッシュを生成して、更新された結果セットを生成し、これが収集されたフィードバックを更新結果セットの結果に組み込む。この更新された結果セットは、エッジサーバに送信される。

図３２－１は、入力されたクエリプレフィックスに基づいて検索結果を返すシステム３２＿１００の一実施形態のブロック図である。図３２－１において、システム３２＿１００は、デバイス３２＿１０２、スマートフォン３２＿１１４、及びタブレット３２＿１１６に連結されている検索ネットワーク３２＿１０８を含む。一実施形態において、この検索ネットワークは、様々なデバイス向けのクエリプレフィックスを受信し、クエリ結果をそれらのデバイスに返す１つ以上のサーバのネットワークである。例えば、一実施形態において、検索ネットワークは、デバイス３２＿１０２、スマートフォン３２＿１１４、及び／又はタブレット３２＿１１６からクエリプレフィックス３２＿１１０Ａ～Ｄを受信し、クエリ結果３２＿１１２Ａ～Ｄをそれぞれのデバイス（例えば、デバイス３２＿１０２、スマートフォン３２＿１１４、及び／又はタブレット３２＿１１６）に返す。一実施形態において、デバイス３２＿１０２は、パーソナルコンピュータ、ラップトップ、サーバ、モバイルデバイス（例えば、スマートフォン、ラップトップ、パーソナルデジタルアシスタント、音楽再生デバイス、ゲームデバイスなど）、並びに／又は、クエリを要求及び／又は表示するいずれかのデバイスであり得る。一実施形態において、デバイスは、物理デバイス又は仮想デバイスであり得る。一実施形態において、スマートフォン３２＿１１４は、デバイス３２＿１０２の多くの機能を実行できる携帯電話であり得る。一実施形態において、タブレット３２＿１１６は、ディスプレイ上での入力を受け入れるモバイルデバイスであり得る。

一実施形態において、これらのデバイスの各々は、ユーザがクエリプレフィックスを入力するために使用するブラウザを含む。例えば一実施形態において、デバイス３２＿１０２は、ウェブブラウザ３２＿１０４とファイルブラウザ３２＿１０６とを備える。これらのブラウザの各々は、ユーザがクエリプレフィックスを入力するために使用する検索入力フィールドを備える。一実施形態において、ウェブブラウザ３２＿１０４は、ユーザが様々な種類のウェブドキュメントを求めてウェブを検索し、取り出せるようにするプログラムである。一実施形態において、ウェブブラウザ３２＿１０４は、検索入力フィールド３２＿１２８を備える。検索入力フィールド３２＿１２８は、ユーザがクエリプレフィックス文字列を入力するために使用される。一実施形態において、クエリプレフィックス文字列は、検索ネットワーク３２＿１０８に送信されるクエリプレフィックスで使用される一続きのテキスト又は他の記号である。クエリプレフィックス文字列は、ユーザが入力した不完全又は完全な検索文字列であり得る。一実施形態において、ユーザが検索入力フィールド３２＿１２０Ａにクエリ入力文字列を入力すると、ウェブブラウザ３２＿１０４は、クエリプレフィックス文字列を捕捉し、クエリプレフィックス３２＿１１０Ａ内のこのクエリプレフィックス文字列を検索ネットワークに送信する。ウェブブラウザ３２＿１０４は、検索入力フィールド３２＿１２０Ａに入力された記号又はテキスト文字列ごとにクエリプレフィックス３２＿１１０Ａを作成し、検索ネットワーク３２＿１０８に送信する。クエリプレフィックス３２＿１１０Ａを受信したことに応答して、検索ネットワークは、複数の検索ドメインにわたる１つ以上のクエリ補完を作成し、これらのクエリ補完のうちの１つ以上を選択して関連結果のセット３２＿１１２を作成する。このセットは、ウェブブラウザ３２＿１０４に返される。例えば、一実施形態において、ユーザがテキスト「ａｐｐｌ」を入力すると、ウェブブラウザ３２＿１０４は、クエリプレフィックス文字列「ａ」、「ａｐ」、「ａｐｐ」及び「ａｐｐｌ」を使用してクエリプレフィックス３２＿１１０Ａを作成する。検索ネットワーク３２＿１０８は、これらのクエリプレフィックス３２＿１１０Ａの各々について、複数の検索ドメインからクエリ補完のセットを作成し、これらのクエリ補完を使用して関連結果を判定し、異なるクエリプレフィックス３２＿１１０Ａに対する異なる結果セットを返す。ユーザが後続の文字を入力するのに合わせてクエリプレフィックスを捕捉するこの手続きは、ファイルブラウザ３２＿１０６で行うこともできる。一実施形態において、ファイルブラウザ３２＿１０６は、ユーザがクエリプレフィックス文字列を入力するために使用できる検索入力フィールド３２＿１２０Ｂを備える。本実施形態において、ユーザがクエリプレフィックス文字列を入力すると、ファイルブラウザ３２＿１０６は、種々のクエリプレフィックス３２＿１１０Ｂを作成し、それらを検索ネットワーク３２＿１０８に送信する。検索ネットワーク３２＿１０８は、種々のクエリプレフィックス３２＿１１０Ｂを受信し、１つ以上のクエリ補完を判定して、上述のとおり関連結果を返す。加えて、クエリプレフィックスは、デバイス３２＿１０６上にローカルに記憶されたデータのメタデータデータベースを使用してクエリを実行するために使用することができる。

一実施形態においては、文字列としてクエリ入力文字列を捕捉し、１つ以上のクエリ補完を判定し、これらのクエリ補完を使用して関連結果を判定するこの同じ手続きを、スマートフォン３２＿１１４及びタブレット３２＿１１６で実行することもできる。本実施形態において、スマートフォン３２＿１１４は、ブラウザ３２＿１１６を備える。ブラウザ３２＿１１６は、検索入力フィールド３２＿１２０Ｃを備える。上述したのと同様に、検索入力フィールド３２＿１２０Ｃは、ユーザがクエリプレフィックス文字列を入力するために使用する。このクエリプレフィックス文字列は、ブラウザ３２＿１１６によって増分的に捕捉され、ひいては、検索ネットワーク３２＿１０８に送信される種々のクエリプレフィックス３２＿１１０Ｃのセットを作成する。検索ネットワーク３２＿１０８は、これら種々のクエリプレフィックス３２＿１１０Ｃの各々を受信したことに応答して、１つ以上のクエリ補完を判定し、これらのクエリ補完を使用して、ブラウザ３２＿１１６に返される関連結果３２＿１１２Ｃを判定する。加えて、タブレット３２＿１１６は、ブラウザ３２＿１１８を含む。ブラウザ３２＿１１８は、検索入力フィールド３２＿１２０Ｄを備える。上述したのと同様に、検索入力フィールド３２＿１２０Ｄは、ユーザがクエリプレフィックス文字列を入力するために使用する。このクエリプレフィックス文字列は、ブラウザ３２＿１１８によって増分的に捕捉され、ひいては、検索ネットワーク３２＿１０８に送信される種々のクエリプレフィックス３２＿１１０Ｄのセットを作成する。検索ネットワーク３２＿１０８は、これら種々のクエリプレフィックス３２＿１１０Ｄの各々を受信したことに応答して、１つ以上のクエリ補完を判定し、これらのクエリ補完を使用して、ブラウザ３２＿１１８に返される関連結果３２＿１１２Ｄを判定する。一実施形態において、検索ネットワーク３２＿１０８は、クエリ補完を処理し、関連結果を返す検索モジュール３２＿１１８を含む。クエリ補完を処理し、関連結果を返すことについては、後ほど図３２－２～図３２－７のところで更に説明する。

上述のとおり、デバイス上のブラウザが、クエリプレフィックス３２＿１１０Ａ～Ｄを検索ネットワーク３２＿１０８に送信する。一実施形態においては、クエリプレフィックス３２＿１１０Ａ～Ｄが、クエリプレフィックス文字列と、位置（例えば、緯度／経度の組み合わせ）と、デバイスタイプ識別子（例えば、コンピュータ、スマートフォン、タブレットなど）と、アプリケーションタイプ識別子（例えば、ウェブブラウザ（並びにウェブブラウザのタイプ）及びファイルブラウザ）と、ロケールと、を含む。本実施形態においては、位置、デバイスタイプ識別子、アプリケーションタイプ識別子、及びロケールを提供することにより、ユーザによってクエリプレフィックス文字列が入力されたコンテキストが、検索されたネットワーク３２＿１０８に提供される。一実施形態において、検索ネットワーク３２＿１０８は、このコンテキスト及びクエリプレフィックス文字列を使用して、クエリ補完及び関連結果を判定する。例えば、一実施形態において、検索ネットワーク３２＿１０８は、位置情報を使用して、クエリプレフィックスを提供したデバイスの位置と関連のあるクエリ補完及び結果を判定することができる。一例として、このデバイス位置は、現在のデバイス位置に近い場所の検索結果を見つけるために使用することができる。別の実施例として、かつ別の実施形態において、デバイスタイプ識別子は、検索ネットワーク３２＿１０８がそのデバイスタイプ向けの補完及び結果を判定するために使用することができる。この例においては、クエリプレフィックスがスマートフォンから来ていることをデバイスタイプ識別子が示した場合に、検索ネットワーク３２＿１０８が、パーソナルコンピュータのアプリケーションストアではなくスマートフォンのアプリケーションストアへの結果に対し、より大きな重みを与え得る。更なる例において、かつ更なる実施形態においては、アプリケーションタイプ識別子及びロケールを使用して補完及び結果に重み付けすることもできる。

一実施形態において、検索ネットワーク３２＿１０８は、マルチドメインクエリ補完を使用してクエリプレフィックスを補完する。本実施形態において、検索ネットワーク３２＿１０８は、受信した各クエリプレフィックスを、検索ネットワーク３２＿１０８によって使用される検索ドメインの各々に送信する。例えば、一実施形態において、検索ネットワーク３２＿１０８は、受信したクエリプレフィックスを、マップ検索ドメイン、メディア検索ドメイン、ウィキ検索ドメイン、サイト検索ドメイン、及び他の検索ドメインに送信する。これらの検索ドメインの各々は、その検索ドメインに格納されているデータに基づいて、そのクエリプレフィックスに対する１つ以上のクエリ補完を判定する。更に、各検索ドメインは、１つ以上のクエリ補完の各々についてのスコアのセットを返す。例えば、一実施形態において、検索ドメインは、クエリ補完ごとに生スコア、ローカルスコア、及び／又はグローバルスコアを返す。マルチドメインクエリ補完の実行については、図３～図６のところで更に説明する。

検索ネットワーク３２＿１０８は、検索ネットワーク３２＿１０８によって判定されたクエリ補完を、クエリプレフィックスを提供したデバイスに返すのではなく、それらのクエリ補完のうちの１つ以上を使用して、複数の検索ドメインにわたる関連クエリ結果のセットを判定する。一実施形態においては、クエリ補完を使用して関連クエリ結果のセットを判定することが、これらのクエリ補完のうちのどれを使用して関連結果を判定するかということについて、ユーザからのインジケーションなしで実行される。本実施形態においては、ユーザが検索入力フィールドに文字列を入力すると、検索ネットワーク３２＿１０８がその文字列を処理し、関連結果をユーザに返す。一実施形態において、検索ネットワーク３２＿１０８は、判定されたクエリ補完のうちの１つ以上を使用して、それらのクエリ補完に対するクエリ結果を見つけ、ランク付けする。一実施形態において、検索ネットワーク３２＿１０８は、検索ネットワーク３２＿１０８が利用できる複数の検索ドメインを検索する。本実施形態において、検索ネットワーク３２＿１０８は、クエリ補完に対する結果のセットを各検索ドメインから受信する。これらの結果の各々について、検索ネットワーク３２＿１０８は、その結果を特徴付けるスコアのセットを更に受信する。一実施形態において、これらのスコアは、結果を提供した検索ドメイン、別のメトリック、及び／又は後ほど図３２－７で説明する結果を提供するために使用されたクエリ補完を特徴付ける信号によって判定されたスコアを含み得る。一実施形態において、信号は、知識ベースを使用するクエリ補完の語彙の特徴付けに基づく。一実施形態においては、語彙の特徴付けにより、どの種類のクエリ補完がマルチドメインクエリ検索に使用されているかが判定される。関連結果のセットを判定するためにマルチドメインクエリ検索を実行することについては、後ほど図３２－７及び図３２－１３～図３２－１５のところで更に説明する。

図３２－２は、入力されたクエリプレフィックスに基づいてクエリ補完及び関連結果を判定するためのプロセス３２＿２００の一実施形態のフローチャートである。図３２－２において、プロセス３２＿２００は、クエリプレフィックスを受信することによって開始する。一実施形態において、クエリプレフィックスは、上記、図３２－１に記載のとおり、クエリプレフィックス文字列と、位置と、デバイスタイプ識別子と、アプリケーションタイプ識別子と、ロケールと、を含む。本実施形態において、位置、デバイスタイプ識別子、アプリケーションタイプ識別子、及び／又はロケールは、クエリプレフィックス文字列がユーザによって入力されたという、クエリプレフィックスについてのコンテキストを与える。ブロック３２＿２０４で、プロセス３２＿２００は、複数の検索ドメインにまたがるクエリ補完を判定し、クエリ補完をランク付けして選択する。一実施形態において、プロセス３２＿２００は、クエリプレフィックスを使用して、種々のかかるドメインの各々からのクエリ補完のセットを判定する。例えば、一実施形態において、クエリプレフィックス文字列が「ａｐ」である場合、プロセス３２＿２００は、このクエリプレフィックス文字列を使用して、種々の検索ドメイン（例えば、マップ、メディア、ウィキ、サイト、及び／又は他の検索ドメイン）からのクエリ補完のセットを判定する。この例において、マップ検索ドメインは「Ａｐａｃｈｅ Ｊｕｎｃｔｉｏｎ」市へのクエリ補完を返し、メディア検索ドメインは「Ａｐｐａｌａｃｈｉａｎ Ｓｐｒｉｎｇ」という音楽作品へのクエリ補完を返し、ウィキ検索ドメインはＡｐｐｌｅ社へのクエリ補完を返し、サイト検索ドメインはウェブサイトＡｐｐｌｅ．ｃｏｍへのクエリ補完を返し得る。一実施形態において、クエリプレフィックス文字列が最小数の文字（例えば、４文字）を有する場合、プロセス３２＿２００はクエリ補完のセットを作成する。

更に、プロセス３２＿２００は、かかる種々のドメインから受信したクエリ補完候補をランク付けして選択する。一実施形態において、プロセス３２＿２００は、対応する検索ドメインによって判定されたスコアに基づくクエリ補完候補と、クエリプレフィックスのコンテキストに基づく重みと、をランク付けする。本実施形態において、プロセス３２＿２００は、これらのランキングに基づいてクエリ補完のセットを選択する。一実施形態においては、クエリ補完に対して使用されたクエリプレフィックス文字列を入力したユーザにクエリ補完のセットを返すのではなく、このクエリ補完のセットを使用して関連結果のセットを判定し、その後、このセットをユーザに返す。クエリ補完のセットを判定することについては、後ほど図３２－３～図３２－６のところで更に説明する。

プロセス３２＿２００は、ブロック３２＿２０６で関連結果のセットを判定する。一実施形態において、プロセス３２＿２００は、ブロック３２＿２０４で判定されたクエリ補完に基づいて関連結果を判定する。本実施形態において、プロセス３２＿２００は、プロセス３２＿２００に対して利用できる複数の検索ドメインを検索する。本実施形態において、プロセス３２＿２００は、各検索ドメインから、クエリ補完の結果のセットを受信する。これらの結果の各々について、プロセス３２＿２００は、その結果を特徴付けるスコアのセットを更に受信する。一実施形態において、これらのスコアは、結果を提供した検索ドメイン、別のメトリック、及び／又は後ほど図３２－７のところで説明する結果を提供するために使用されたクエリ補完を特徴付ける信号によって判定されたスコアを含み得る。一実施形態において、信号は、知識ベースを使用するクエリ補完の語彙の特徴付けに基づく。一実施形態においては、語彙の特徴付けにより、どの種類のクエリ補完がマルチドメインクエリ検索に使用されているかが判定される。関連結果のセットを判定することについては、後ほど図３２－７及び図３２－１３～図３２－１５のところで更に説明する。ブロック３２＿２０８で、プロセス３２＿２００は関連結果のセットをユーザに返す。別の実施形態においては、フィードバックインデックスを、結果を重み付けするための信号ドメインとして使用することができる。本実施形態については、後ほど図３２－１４のところで更に説明する。

上述したとおり、プロセス３２＿２００は、複数の検索ドメインにわたってクエリ補完及び関連結果を判定する。一実施形態においては、これらのクエリ補完及び関連結果が、アグリゲータを使用して集約される。図３２－３は、アグリゲータ３２＿３０２と複数の検索ドメイン３２＿３０４Ａ～Ｆとを含むシステム３２＿３００の一実施形態のブロック図である。一実施形態において、アグリゲータ３２＿３０２は、入力されたクエリプレフィックスに基づいてクエリ補完の要求を受信する。入力されたクエリプレフィックスを受信したことに応答して、アグリゲータ３２＿３０２は、入力されたクエリプレフィックスを検索ドメイン３２＿３０４Ａ～Ｆの各々に送信する。検索ドメイン３２＿３０４Ａ～Ｆの各々は、入力されたクエリプレフィックスを使用して、そのドメインにおけるクエリ補完候補を判定する。例えば、一実施形態において、マップ検索ドメイン３２＿３０４Ａは、入力されたクエリプレフィックスを受信し、クエリ補完候補をこのドメインで検索する。一実施形態において、アグリゲータ３２＿３０２は、検索ドメインの各々からクエリ補完を受信し、対応する検索ドメインによって判定された補完の各々のスコアと、クエリプレフィックスコンテキストに基づく重みと、に基づいて、受信したクエリ補完をランク付けする。

一実施形態において、マップ検索ドメイン３２＿３０４Ａは、地形図に関連する情報を含む検索ドメインである。本実施形態において、マップ情報は、場所、住所、事業所、関心のある場所に関する情報、又はマップに関連する他の種類の情報を含み得る。別の実施形態において、マップ情報は、場所に関連する、営業時間、レビュー及び評価、連絡先情報、道案内並びに／又は写真など、関心のある場所に関する情報も含み得る。一実施形態において、メディア検索ドメイン３２＿３０４Ｂは、メディアに関連する検索ドメインである。一実施形態において、メディア検索ドメイン３２＿３０４Ｂは、音楽、書籍、ビデオ、クラス、話し言葉、ポッドキャスト、ラジオ、及び／又は他の種類のメディアに関連する情報を含む。更なる実施形態において、メディア検索ドメイン３２＿３０４Ｂは、図３２－１において上述したとおり、デバイス３２＿１０２、スマートフォン３２＿１１４、及びタブレット３２＿１１６など、デバイス上で実行できるアプリケーションに関連する情報を含み得る。一実施形態において、メディア検索ドメインは、購入可能な種々の種類のメディア（例えば、音楽、書籍、ビデオ、クラス、話し言葉、ポッドキャスト、ラジオ、アプリケーション、及び／又は他の種類のメディア）を含むメディアストアである。一実施形態において、ウィキ検索ドメイン３２＿３０４Ｃは、オンライン百科事典検索ドメインである。例えば、一実施形態において、ウィキ検索ドメイン３２＿３０４Ｃはウィキペディアであり得る。一実施形態において、サイト検索ドメイン３２＿３０４Ｄはウェブサイトの検索ドメインである。例えば、一実施形態において、サイト検索ドメイン３２＿３０４Ｄは、「ａｐｐｌｅ．ｃｏｍ」、「ｗｈｉｔｅｈｏｕｓｅ．ｇｏｖ」、「ｙａｈｏｏ．ｃｏｍ」など、企業、政府、公的、及び／又は民間のウェブサイトを含む。一実施形態において、他の検索ドメイン３２＿３０４Ｅは、アグリゲータ３２＿３０２（例えば、ニュース検索ドメイン）によってアクセス可能な他の検索ドメインのセットである。一実施形態において、フィードバック補完ドメイン３２＿３０４Ｆは、様々なデバイス上で動作するブラウザによって収集されたクエリフィードバックに基づく検索インデックスである。一実施形態において、フィードバック補完ドメイン３２＿３０４Ｆは、収集されたクエリフィードバックに基づいてクエリを結果にマッピングするフィードバックインデックスを含む。フィードバックインデックスについては、後ほど図３２－８～図３２－１２のところで更に説明する。

上述したとおり、各検索ドメイン３２＿３０４Ａ～Ｆは、検索ドメインの各々が、入力されたクエリプレフィックスに基づいてクエリ補完のセットを提供できるようにする情報を含む。一実施形態において、検索ドメインの各々は、クエリ補完を判定するとともに、それらのクエリ補完の各々についてのスコアを判定するためにも使用されるクエリ補完ツリーを含む。図３２－４は、クエリ補完検索ドメイン３２＿４０２に対する一実施形態の図である。図３２－４において、クエリ補完検索ドメイン３２＿４０２は、ノード３２＿４０４Ａ～Ｊを有するクエリ補完ツリー３２＿４００を含む。一実施形態において、ノード３２＿４０４Ａ～Ｊの各々は、それぞれの言語における文字を表す。本実施形態においては、ノード３２＿４０４Ａ～Ｊをたどってツリーを下りていくことにより、種々のクエリ補完を表すことができる。例えば、一実施形態において、ノード３２＿４０４Ａから開始し、ノード３２＿４０４Ｃまで下りていくと、文字「ａｐ」で始まる補完を表すことができる。各ノードには頻度も含まれており、この頻度は、入力されたクエリプレフィックスとこの補完が一致した回数のことである。一実施形態において、ノード３２＿４０４Ｃは、Ｎという頻度を有する。本実施形態において、頻度は、上記のアグリゲータ３２＿３０２に返される生スコアとして表される。一実施形態において、頻度は、ログ（例えば、マップ又はメディア検索ドメイン）、訪問されたページ（例えば、ウィキ検索ドメイン）、又は別の情報源に基づいて計算することができる。ノード３２＿４０４Ｃの下に、他のクエリ補完候補の数がある。例えば、一実施形態において、ノード３２＿４０４Ｄ～Ｆは、文字「ａｐａ」、「ａｐｔ」、及び「ａｐｐ」で始まるクエリ補完を表す。ノードの下にあるクエリ補完候補の総数は、そのノードによって表されるそのクエリ補完の近似性を示す。ノードの下に他のノード候補が多数存在する場合、そのノードによって表されるクエリ補完が良好な補完である可能性は低い。一方、そのノードの下にあるノードが比較的少ない場合、このノードは良好な補完であり得る。一実施形態において、そのノードのローカルスコアは、そのノードの頻度を、そのノード以下のサブツリーによって表される補完数で割った値によって表される。一実施形態において、ローカルスコアの式は、次式（１）によって表される。

ローカルスコア（ノード）＝頻度（ノード）／そのノード以下の補完数。

一実施形態において、各クエリ補完ツリーは、補完の総数を含む。この値は、補完（又はノード）のグローバルスコアを計算するために使用される。一実施形態において、グローバルスコアの式は、次式（２）によって表される。グローバルスコア（ノード）＝頻度（ノード）／クエリ補完ツリー内の補完数。

一実施形態において、各クエリ補完の生スコア、ローカルスコア、及びグローバルスコアは、検索ドメインによってアグリゲータに返される。

図３２－５は、マップ検索ドメイン３２＿５００の一実施形態を示す図である。図３２－５において、マップ検索ドメイン３２＿５００は、このドメインの種々のズームレベルに対するクエリ補完ツリー３２＿５０４Ａ～Ｄを含む。一実施形態において、マップ検索ドメイン３２＿５００は、市レベル３２＿５０４Ａ、郡レベル３２＿５０４Ｂ、州レベル３２＿５０４Ｃ、及び国レベル３２＿５０４Ｄのクエリ補完ツリーを含む。これらのレベルは、マップアグリゲータ３２＿５０２によって集約される。本実施形態においては、入力されたクエリプレフィックスに対するクエリ補完の判定が、マップアグリゲータ３２＿５０２によって受信され、マップアグリゲータ３２＿５０２が、マップ検索ドメイン３２＿５００の種々のズームレベル３２＿５０４Ａ～Ｄにおける、その入力されたクエリプレフィックスに対するクエリ補完を判定する。マップアグリゲータ３２＿５０２は、種々のズームレベル３２＿５０４Ａ～Ｄの各々からクエリ補完候補を取り出し、クエリ補完を集約し、これらのクエリ補完をアグリゲータ（例えば、アグリゲータ３２＿３０２）に返す。こうして、マップ探索ドメイン３２＿５００は、種々ズームレベルにまたがってクエリ補完を判定する。一実施形態において、マップ検索ドメイン３２＿５００は、住所、場所、ビジネス、関心のある場所に関する情報、及び／又はマップに関する他の情報を含む。一実施形態において、マップ検索ドメイン３２＿５００は、白又は黄色のページディレクトリなどのディレクトリ情報を含み得る。一実施形態において、メディア検索ドメインは、デバイス識別子とロケールとの組み合わせに基づくストアフロントによって編成される。本実施形態においては、ストアフロントごとにクエリ補完ツリーが存在する。図３２－６は、複数の検索ドメインからのクエリ補完を判定するためのプロセス３２＿６００の一実施形態のフローチャートである。一実施形態において、アグリゲータ３２＿３０２は、プロセス３２＿６００を実行して、複数の検索ドメインからのクエリ補完を判定する。図３２－６において、プロセス３２＿６００は、ブロック３２＿６０２でクエリプレフィックスを受信することによって開始する。一実施形態において、クエリプレフィックスは、図３２－２で上述したとおり、コンテキスト内のクエリプレフィックス文字列を含む。ブロック３２＿６０２で、プロセス３２＿６００は、クエリプレフィックスを種々の検索ドメインに送信して補完候補を判定する。一実施形態において、プロセス３２＿６００は、クエリプレフィックスをマップ、メディア、ウィキ、サイト、及び／又は他の検索ドメインに送信する。検索ドメインの各々は、先に図３２－４のところで説明したとおり、それらの検索ドメインの各々が利用できるクエリ補完ツリーに基づいて、入力されたクエリプレフィックスに対するクエリ補完候補を判定する。プロセス３２＿６００は、ブロック３２＿６０６で、検索ドメインの各々からクエリ補完候補を受信する。プロセス３２＿６００は、クエリ補完候補を受信することに加え、先に図３２－４のところで説明したとおり、生スコア、ローカルスコア、及び／又はグローバルスコアなど、補完候補の各々についてのスコアのセットも受信する。ブロック３２＿６０８で、プロセス３２＿６００は、返されたスコアと入力されたクエリプレフィックスのコンテキストとに基づいて、クエリ補完候補をランク付け及びフィルタリングする。一実施形態において、プロセス３２＿６００は、種々の検索ドメインから受信した生スコア、ローカルスコア、及びグローバルスコアと、クエリプレフィックスに含まれるコンテキストと、に基づいて、クエリ補完候補を調整する。プロセス３２＿６００は、ルールのセットに基づいてクエリ補完候補を更にフィルタリングする。例えば、一実施形態において、フィルタルールは、１又はある所定値未満の生スコアを有する補完候補をプロセス３２＿６００でフィルタリングして除外することがであり得る。プロセス３２＿６００は、ランク付け及びフィルタリングされた補完をクエリ検索モジュールに送信する。クエリ検索モジュールは、ランク付け及びフィルタリングされたクエリ補完のセットを使用して、ブロック３２＿６１０でユーザに返される関連結果のセットを判定する。

上述のとおり、プロセス３２＿６００によって判定されたクエリ補完は、これらの補完をユーザに返送することなく、関連結果を判定するために使用される。図３２－７は、判定されたクエリ補完から、複数の検索ドメインにわたって関連結果を判定するプロセス３２＿７００の一実施形態のフローチャートである。一実施形態において、フェデレータ３２＿８２４はプロセス３２＿７００を実行する。図３２－７において、プロセス３２＿７００は、ブロック３２＿７０２でコンプリータからクエリ補完を受信する。一実施形態において、受信したクエリ補完は、クエリプレフィックスを受信したことに応答してプロセス３２＿６００によって判定された補完である。ブロック３２＿７０４で、プロセス３２＿７００は、クエリ補完を種々の検索ドメインに送信して関連結果候補を判定する。一実施形態において、検索ドメインの各々は、受信したクエリ補完を使用して、その検索ドメインの関連結果を判定する。ブロック３２＿７０６で、プロセス３２＿７００は、種々の検索ドメインからクエリ結果を受信する。一実施形態において、プロセス３２＿７００は、それらの結果と、関連検索ドメインによって計算された各結果と関連付けられたスコアと、を受信する。

プロセス３２＿７００は、ブロック３２＿７０８で検索結果をランク付けし、フィルタリングする。一実施形態において、プロセス３２＿７００は、検索結果を得るために検索されたドメインの各々によって返されたスコアと、他の要因と、に基づいて検索結果をランク付けする。本実施形態においては、ドメイン依存スコア、クエリ非依存スコア、及びクエリ依存スコアに基づいて、種々のドメインからのスコアを採点することができる。一実施形態において、種々の検索ドメインの各々は、返された結果をランク付けするために使用される具体的なデータを提供することができる。例えば、一実施形態において、マップ検索ドメインは、オンラインレビューの数、平均レビュースコア、ユーザからの距離（例えば、クエリプレフィックス位置情報に基づく）、結果が、その結果と関連付けられたユニフォームリソースロケータ（ＵＲＬ）を有するかどうか（例えば、結果が事業所の所在地であるかどうか、その事業所がＵＲＬ又は他のソーシャルメディアを参照するウェブサイトを有するかどうか）、及び／又はクリック数など、結果をランク付けするための様々なクエリ非依存情報を提供することができる。別の実施例及び別の実施形態としては、メディア検索ドメインが、メディア評価件数、メディアの存続期間、人気、人気の衰退度、及び／又は結果別の購入データなど、採点のための他の種類の情報を提供することができる。更なる例及び実施形態においては、ウィキ検索ドメインが、ランク付け対象となり得るページビュー、編集履歴、及び言語の数に関する情報を提供することができる。他の検索ドメインは、引用回数や存続期間などの採点メトリクスを提供できる。

一実施形態において、プロセス３２＿７００は、各検索ドメインからスコアのセットを受信し、これらのスコアを使用して、各結果の初期スコアを判定する。プロセス３２＿７００は、各結果に信号ドメインを適用する。一実施形態においては、信号ドメインがクエリ補完特性である。本実施形態において、プロセス３２＿７００は、クエリ補完の各々を特徴付け、このクエリ補完特性を使用して結果をランク付けする。例えば、一実施形態において、プロセス３２＿７００は、知識ベースを利用した語彙特徴付けを実行して、クエリ補完のタイプを判定する。この例においては、クエリ補完タイプが、そのクエリ補完が人物、場所、モノ、及び／又は別のカテゴリを判定しているかどうかを示す。例えば、一実施形態において、プロセス３２＿７００は、クエリ補完が場所を判定するために使用されていると判断でき得る。この例においては、クエリ補完が場所を判定するために使用されるので、マップ検索ドメインからのクエリ結果が、検索結果のランク付けにおいて上位に重み付け（及びランク付け）される。クエリ補完特性については、後ほど図３２－１３～図３２－１５のところで更に説明する。

その他の別の実施形態においては、プロセス３２＿７００が、結果スコアの各々にブーストを適用する。本実施形態においては、プロセス３２＿７００が、結果の各々にＱＤＦ（Ｑｕｅｒｙ Ｄｅｓｅｒｖｅｓ Ｆｒｅｓｈｎｅｓｓ：新鮮さを優先した検索）を適用する。一実施形態において、ＱＤＦは、その結果のカウント数が最近急上昇したり、ピークを迎えていたりする場合に、この結果が「新鮮な」結果であり、ブーストが可能であり得ることを意味する。時間の経過とともにベースライン付近で変動するカウントを有する結果であれば、「新鮮な」結果ではなく、ブーストはされない。一実施形態において、このカウントは、ソーシャルメディアフィード（例えば、ツイッターなど）の分析に基づいている。

例えば、一実施形態において、クエリ補完が「ｐｕｐｐｙ ｌｏｖｅ」であり、次の４つの結果が返された場合、（１）メディア検索ドメインから、「Ｐｕｐｐｙ Ｌｏｖｅ」という歌、（２）マップ検索ドメインから、「Ｐｕｐｐｙ Ｌｏｖｅ Ｄｏｇｓ」という呼称の企業、（３）子犬への愛を謳ったコマーシャルに言及しているニュース記事、（４）「Ｐｕｐｐｙ Ｌｏｖｅ」という呼称のウィキエントリ。本実施形態においては、メディア検索ドメインからの｛存続期間、レーティング、及び生スコア｝、マップの検索ドメインからの｛ユーザからの距離、ＵＲＬの有無、レビュー数、平均レビュー数｝、ニュースドメインからの｛存続期間、ニューススコア、トラックバック数｝、ウィキ検索ドメインからの｛ページランク、生スコア｝という検索ドメイン依存メトリクスに基づいて各結果の初回採点が行われる。検索ドメインの各々は、プロセス３２＿７００を処理するために独自の採点を提供する。この例においては、各結果の採点を、最初にウィキ結果＞メディア結果＞ニュース結果＞マップ結果の順にランク付けすることができ得る。プロセス３２＿７００は更に、結果の各々に信号ドメインを適用する。この例において、「ｐｕｐｐｙ ｌｏｖｅ」というクエリは、歌として特徴付けられており、場所として特徴付けられている可能性もある。この特徴付けを適用すると、メディアストア結果が向上し、程度は劣るがマップ結果も向上する。特徴付けブーストを適用した後、結果の採点は、ウィキ結果＞メディア結果（ただしスコアは近い）マップ＞結果＞ニュース結果の順にランク付けされ得る。加えて、プロセス３２＿７００は、これらの結果にＱＤＢ（Ｑｕｅｒｙ Ｄｅｓｅｒｖｅｄ Ｂｏｏｓｔｓ）を適用する。例えば、「Ｐｕｐｐｙ Ｌｏｖｅ」というコマーシャルの最初の放映から２日後であるために、このコマーシャルのカウントが増加する。そのため、「Ｐｕｐｐｙ Ｌｏｖｅ」の結果は、ＱＤＦブーストを得ることになる。この例においては、ニュース結果「Ｐｕｐｐｙ Ｌｏｖｅ」が大きなブーストを得るので、結果はニュース結果＞ウィキ結果＞メディア結果＞マップ結果の順にランク付けされる。

一実施形態において、プロセス３２＿７００は、検索結果を更にフィルタリングする。本実施形態において、プロセス３２＿７００は、特定のルールに基づいて結果を除去する。例えば、一実施形態において、プロセス３２＿７００は、特定の総スコアを下回る結果を除去し得る。あるいは、プロセス３２＿７００は、別の基準（例えば、クエリに対する低いテキスト一致率、低いクリックスルーレート、低い人気、性的描写が露骨なコンテンツ及び／又は冒涜的な内容を有する結果、及び／又はそれらの組み合わせ）に基づいて結果をフィルタリングすることができる。ブロック３２＿７１０で、プロセス３２＿７００は、ランク付け及びフィルタリングされた結果をユーザに返す。

図３２－８は、ユーザフィードバックを検索インデックスに組み込むシステム３２＿８００のブロック図である。図３２－８において、システム３２＿８００は、クエリプレフィックス３２＿８２８をエッジサーバ３２＿８０４に送信するデバイス３２＿８０２を備え、エッジサーバ３２＿８０４はクエリ結果３２＿８３０をデバイスに戻す。加えて、エッジサーバ３２＿８０４は、コアサーバ３２＿８１６に連結されている。一実施形態において、デバイス３２＿８０２は、ユーザがクエリプレフィックスを入力すると、クエリプレフィックス３２＿８２８をエッジサーバに送信する。例えば、一実施形態において、ユーザがクエリプレフィックス「ａｐｐｌｅ」を入力すると、「ａ」、「ａｐ」、「ａｐｐ」、「ａｐｐｌ」、及び「ａｐｐｌｅ」のクエリプレフィックスが生成され、ユーザが各文字を入力した時にサーバ３２＿８０４に送信される。加えて、エッジサーバ３２＿８０４は、エッジサーバ３２＿８０４に送信されたクエリプレフィックス３２＿８２８ごとに関連結果３２＿８３０をクライアントに返す。例えば、一実施形態において、エッジサーバは、ユーザが各文字を入力すると、クエリプレフィックス３２＿８２８「ａ」、「ａｐ」、「ａｐｐ」、「ａｐｐｌ」、及び「ａｐｐｌｅ」に対する関連結果を返す。一実施形態において、エッジサーバは、クエリ補完を実行することもできる。一実施形態において、デバイス３２＿８０２は更に、ユーザの検索セッションに関するフィードバックを収集し、このフィードバックをフィードバックパッケージ３２＿８３２内に収集し、このフィードバックパッケージをエッジサーバに送信する。フィードバックの収集と送信については、後ほど図３２－１０のところで更に説明する。一実施形態において、デバイス３２＿８０２は、フィードバックを収集して送信するためのフィードバック収集モジュール３２＿８３８を含む。

一実施形態において、エッジサーバ３２＿８０４は、フィードバック検索モジュール３２＿８０８とフィードバック収集モジュール３２＿８１０とを更に含むフィードバックモジュール３２＿８０６を備える。一実施形態において、フィードバック検索モジュール３２＿８０８は、エッジサーバ３２＿８０４のエッジキャッシュ３２＿８１２に記憶されたフィードバックインデックス３２＿８１４に基づいて、クエリプレフィックス３２＿８２８の各々について検索を実行する。本実施形態においては、ユーザがクエリプレフィックス３２＿８２８を入力すると、フィードバック検索モジュール３２＿８０８及びフィードバック検索インデックス３２＿８１４を使用して、関連結果３２＿８３０の新しいセットがデバイス３２＿８０２に返される。一実施形態において、フィードバック検索インデックスは、ユーザのフィードバックを検索インデックスに組み込むインデックスである。本実施形態において、フィードバック検索インデックスは、結果３２＿８３０をデバイスに素早く戻すために使用される結果キャッシュである。一実施形態において、フィードバック検索インデックスは引用検索インデックスであり、後ほど図３２－１１を参照して更に説明している。一実施形態において、フィードバック収集モジュール３２＿８１０は、デバイス３２＿８０２から送信されたフィードバックパッケージを収集し、このフィードバックパッケージをコアサーバ３２＿８１６に転送する。

一実施形態において、コアサーバ３２＿８１６は、フィードバックフィードパイプライン３２＿８１８と、フィードバック決定パイプライン３２＿８２２と、フィードバックインデックス３２＿８２０と、フェデレータ３２＿８２４と、を備える。一実施形態において、フィードバックフィードパイプライン３２＿８１８は、エッジサーバ３２＿８０４から生フィードバックパッケージ３２＿８３４を受信し、これらの生フィードバックパッケージ３２＿８３４の各々をフィードバックインデックス３２＿８２０用のエントリに変換する。一実施形態において、フィードバックフィードパイプライン３２＿８１６は、生フィードバックパッケージの各々を、＜クエリ、結果、レンダリングカウント、関与カウント、破棄カウント＞というフォーマットを有するインデックスエントリのセットに変換する。クエリは、デバイスタイプ、アプリケーション、ロケール、地理的位置などの入力クエリ及びコンテキスト情報であり、結果はレンダリング結果であり、レンダリングカウントは、そのクエリに対する結果がレンダリングされた回数であり、関与カウントは、結果がそのクエリに対して関与された回数であり、破棄カウントは、結果が破棄された回数である。本実施形態においては、これらのインデックスエントリがフィードバックインデックス３２＿８２０に追加される。生フィードバックパッケージでフィードバックインデックスの更新については、後ほど図３２－１１のところで更に説明する。一実施形態において、フィードバックインデックス３２＿８２０は、ユーザのフィードバックを組み込む検索インデックスである。フィードバックフィードパイプライン３２＿８１８は、生フィードバックパッケージでフィードバックインデックスを更新するプロセスフィードバックモジュール３２＿８４０を更に備える。

一実施形態において、フィードバック決定パイプライン３２＿８２２は、フィードバックインデックス３２＿８２０を使用して結果セットを更新する。一実施形態において、結果セットは、クエリのセットと結果との間のマップである。本実施形態において、フィードバック決定パイプライン３２＿８２２は、フィードバックインデックス３２＿８２０に対してクエリのセットを実行して、更新された結果のセットを判定する。本実施形態においては、更新された結果のセットがフェデレータ３２＿８２４に送信される。フィードバック判定パイプライン３２＿８２２は更に、更新された結果のセット３２＿８２６をエッジサーバ３２＿８０４に送信する。更新された結果セット３２＿８２６は、更新されたフィードバックインデックス３２＿８２０を使用して判定されるクエリのセットに対する結果を含む。一実施形態において、フィードバック決定パイプライン３２＿８２２は、結果セットを更新する結果更新モジュール３２＿８４２を備える。結果セットの更新については、後ほど図３２－１２のところで更に説明する。一実施形態において、フィードバック決定パイプライン３２＿８２２は更に、更新された結果セットを、更新された結果セット３２＿８２６を記憶するフィードバックアーカイブ３２＿８３６に送信する。一実施形態において、フェデレータ３２＿８２４は、後ほど図３２－１３～図３２－１５に記載のとおり、補完されたクエリを使用してマルチドメイン検索を実行する。

上述のとおり、検索ネットワークは、ユーザの検索セッションに関するユーザのフィードバックを捕捉し、このフィードバックを使用して検索フィードバックインデックスを構築する。図３２－９は、ユーザのフィードバックを引用検索インデックスに組み込むプロセス３２＿９００の一実施形態のフローチャートである。図３２－９において、プロセス３２＿９００は、ユーザの検索セッションのユーザのフィードバックを収集することによって開始する。一実施形態において、プロセス３２＿９００は、検索ネットワークに送信されたクエリプレフィックスに応答してクエリ結果を受信したデバイスでフィードバックを収集し始める。本実施形態において、プロセス３２＿９００は、初期レンダリングイベント又は別のイベント（例えば、クエリプレフィックスの入力開始）を検出し、検索セッションにおけるユーザの相互作用を判定することによってフィードバックを収集する。一実施形態において、ユーザインタラクションは、結果によって参照されるウェブサイトにフォーカスし続けること、そのウェブサイト上にあるリンク又は他の参照をクリックすること、又は別の種類の相互作用を行うことであり得る。一実施形態において、検索セッションは、ユーザがクエリプレフィックスの入力を開始し、おおよその期間（例えば、１５分）にわたってユーザのアクションを追跡することによって開始されるイベントのセットである。一実施形態において、プロセス３２＿９００は、送出されたクエリプレフィックスと、ユーザに対してレンダリングされた関連結果と、ユーザがこれらのレンダリング結果のいずれかに関与したかどうか（「関与イベント」）と、ユーザがレンダリング結果を破棄したかどうか（「破棄イベント」）と、を記録する。一実施形態において、プロセス３２＿９００は、ユーザが代替検索オプションに関与したかどうかを記録する。

一実施形態においては、ユーザに提示されたレンダリング結果の１つとユーザが相互作用する場合に、関与イベントが発生する。例えば、一実施形態において、ユーザは、レンダリング結果の１つに対して提示されたリンクをクリックでき得る。別例においては、ユーザがリンクをクリックし、そのリンクによって参照されるオブジェクト（例えば、ウェブサイト）と、所定の時間よりも長い時間を費やして相互作用し得る（例えば、参照されたオブジェクトと６０秒以上相互作用する）。この例においては、ユーザが、現在の米国大統領に対するクエリ検索に向けられた結果を受信し、最新の大統領スピーチを記載しているウェブページを参照するリンクをクリックし得る。ユーザが所定の時間（例えば、６０～９０秒）を超えてそのウェブサイトと相互作用した場合、プロセス３２＿９００は、ユーザがそのリンクによって表示された結果に関与したと判断する。したがって、これはこの結果に対する関与イベントである。一実施形態においては、リンクの上にカーソルを置くことが関与と記録され得る。別の実施形態においては、ユーザが、表示された結果を一定期間にわたって観察することもできる。本実施形態においては、結果のタイプ及びその期間後のアクションに応じて、破棄として記録されたアクションを関与として記録することができ、その逆もまた可能である。例えば、一実施形態において、ユーザが「中国の人口」を問い合わせて結果が表示され、ユーザが１０秒間休止した後にクエリを削除した場合、このイベントは破棄イベントではなく関与イベントとして記録され得る。

別の実施形態においては、ユーザが、自身に対するレンダリング結果を無視又は破棄し得る。例えば、一実施形態において、ユーザが、レンダリング結果の１つについて提示されたリンクをクリックしたものの、所定の時間内（例えば、６０～９０秒未満）にそのウェブサイトから離れた場合、プロセス３２＿９００は、これがその結果に対する破棄イベントであると判断する。一実施形態においては、他の種類の破棄イベントが存在する。具体的には、引き続き入力して文字数を増やす（クエリプレフィックスを拡張する）こと、フォーカスを別のウィンドウ又はアプリケーションに移すこと、クエリを削除すること、バックスペースで１文字以上消去するか、他の方法でクエリを編集すること、そして、結果として提示されたもの以外のものに関与することを、その結果の破棄として記録することができる。一実施形態において、ユーザのアクションは、ユーザが費やした時間間隔とともに記録され、これにより、元来破棄となるアクションの解釈を関与に、又はその逆に変更することができる。

一実施形態においては、ユーザの検索セッションが、ユーザセッションの長さ、無操作の時間、又は他の何らかのメトリックにおいて、所定時間後に終了し得る。検索セッションが終了したことに応答して、プロセス３２＿９００は、この検索セッション用に収集されたイベントをまとめて、検索ネットワークに送信されるフィードバックパッケージにする。フィードバックの収集については、後ほど図３２－１０のところで更に説明する。

ブロック３２＿９０４で、プロセス３２＿９００は、フィードバックパッケージに含まれる受信したフィードバックを処理する。一実施形態において、プロセス３２＿９００は、受信したフィードバックパッケージをフィードバック検索インデックス用のエントリに変換する。一実施形態において、フィードバック検索インデックスは、ユーザのフィードバックを採点結果に組み込む検索インデックスである。例えば、一実施形態においては、（クエリ、結果）ペアに対する各関与イベントが、対応するクエリに対してその結果を促す。この例では、ユーザが特定のクエリに対する結果に関与すると、将来のユーザも同じクエリに対してこの結果に関与し得る。そのため、一実施形態においては、このクエリに対する結果が返され、同じクエリを有する将来のユーザに対して上位にランク付けされる。逆に、特定のクエリに対する結果を破棄すると、将来のユーザも同じクエリに対してこの同じ結果を破棄する可能性がある。そのため、一実施形態においては、このクエリに対する結果が返され、同じクエリを有する将来のユーザに対して下位にランク付けされ得る。

一実施形態において、プロセス３２＿９００は、受信したフィードバックパッケージを、＜クエリ、結果、レンダリング回数、関与回数、破棄回数＞というフォーマットを有するフィードバック検索インデックスエントリに変換する。クエリは、デバイスタイプ、アプリケーション、ロケール、及び地理的位置などの入力クエリ及びコンテキスト情報であり、結果はレンダリング結果であり、レンダリング回数は、そのクエリに対して結果がレンダリングされた回数であり、関与回数はそのクエリに対して結果が関与された回数であり、破棄回数は、結果が破棄された回数である。一実施形態において、プロセス３２＿９００は、フィードバック検索インデックス内にあるこのフィードバックインデックスエントリを更新する。更に別の実施形態においては、プライバシーを保つために識別子を難読化する方法の有無にかかわらず、各フィードバックパッケージが、ユーザ識別子、デバイス識別子、又はセッション識別子を含み得る一意のソース識別子も含む。ここで、フィードバックインデックスエントリを更新すると、この一意のソース識別子をフィードバックの引用源として、引用インデックスの形式でインデックスに付加される。その後、フィードバックインデックスを問い合わせて、個人又はユーザのグループにパーソナライズ又はカスタマイズされた結果及び重み付けを提供することができる。受信したフィードバックの処理については、後ほど図３２－１１のところで更に説明する。

プロセス３２＿９００は、ブロック３２＿９０６で結果キャッシュを更新する。一実施形態において、結果キャッシュは、クエリを結果にマッピングするキャッシュであり、これを使用して、ユーザクエリに対する結果を素早く返すことができる。一実施形態において、結果キャッシュは、クエリ検索を実行する前に１つ以上の結果をサーブするために使用できるユーザのデバイスに近接しているエッジサーバ（例えば、他のエッジサーバよりもクライアントに地理的に近いエッジサーバ）に記憶されている。一実施形態において、プロセス３２＿９００は、更新されたフィードバック検索インデックスを使用してクエリのセットを実行することによって結果を更新し、これらのクエリに対する結果のセットを判定する。更新された結果は、エッジサーバに記憶された結果キャッシュの各々に送信される。結果キャッシュの更新については、後ほど図３２－１２のところで更に説明する。

図３２－１０は、ユーザ検索セッション中にユーザフィードバックを収集するプロセス３２＿１０００の一実施形態のフローチャートである。一実施形態において、プロセス３２＿１００は、先に図３２－８のところで説明したフィードバック収集モジュール３２＿８３８など、ユーザ検索セッション中にユーザフィードバックを収集するフィードバック収集モジュールによって実行される。図３２－１０において、プロセス３２＿１０００は、フィードバック収集をトリガーするイベントを検出することによって開始する。一実施形態において、初期イベントは、別の種類のイベントのクエリプレフィックス文字列のための入力の開始であり得る。一実施形態において、ユーザがある期間（例えば、１５分）にわたって前の検索セッションに参加していた場合には、クエリプレフィックス文字列のためのこの入力開始が、新しいユーザ検索セッションの開始の合図となり、ユーザフィードバックの記録を開始する。上述したとおり、検索セッションは、ユーザがクエリプレフィックスの入力を開始し、おおよその期間（例えば、１５分）にわたってユーザのアクションを追跡することによって開始されるイベントのセットである。

ブロック３２＿１００４で、プロセス３２＿１０００は、ユーザ検索セッションと関連付けられたイベントを記録する。一実施形態において、プロセス３２＿１０００は、レンダリング、関与、及び破棄イベントを記録する。一実施形態において、レンダリングイベントは、ユーザがクエリプレフィックス又は完全なクエリを入力したことに応答してユーザに対してレンダリングされる関連結果である。一実施形態において、プロセス３２＿１０００は、各クエリプレフィックス又は補完クエリに対して提示された結果を記録することによって、レンダリングイベントを記録する。加えて、プロセス３２＿１０００は、ブロック３２＿１００４で関与イベントを記録する。一実施形態において、関与イベントは、ユーザに提示されたレンダリング結果の１つとユーザが相互作用する場合に発生するイベントである。例えば、一実施形態において、ユーザは、レンダリング結果の１つに対して提示されたリンクをクリックでき得る。別例においては、ユーザがリンクをクリックし、そのリンクによって参照されるオブジェクト（例えば、ウェブサイト）と、所定の時間よりも長い時間を費やして相互作用し得る（例えば、参照されたオブジェクトと６０秒以上相互作用する）。この例においては、ユーザが、現在の米国大統領に対するクエリ検索に向けられた結果を受信し、最新の大統領スピーチを記載しているウェブページを参照するリンクをクリックし得る。ユーザが所定の時間（例えば、６０～９０秒）を超えてそのウェブサイトと相互作用した場合、プロセス３２＿１０００は、ユーザがそのリンクによって表示された結果に関与したと判断する。したがって、これはこの結果に対する関与イベントである。

更なる実施形態において、プロセス３２＿１０００は、ユーザが、自身に対してレンダリングされた結果を無視又は破棄し得るイベントである破棄イベントを記録することができる。例えば、一実施形態において、ユーザが、レンダリングされた結果の１つについて提示されたリンクをクリックしたものの、所定の時間内（例えば、６０～９０秒未満）にそのウェブサイトから離れた場合、プロセス３２＿９００は、これがその結果に対する破棄イベントであると判断する。一実施形態において、ユーザは、ウェブサイトを提示するタブ又はウィンドウを閉じること、フォーカスを別のアプリケーションに移すこと、又は提示されたウェブサイトと自身が相互作用していないことを示す他の何らかのアクションを行うことによって離れる。

ブロック３２＿１００６で、プロセス３２＿１０００は、ユーザの検索セッションの記録済みイベントからフィードバックパッケージを作成する。一実施形態において、ユーザの検索セッションは、初期検索セッションイベントからの所定時間（例えば、１５分）、又はユーザ検索セッションに関する所定のユーザ無操作時間に基いて終了する。例えば、一実施形態において、ユーザが所定時間（例えば、１０分）にわたって、アクティビティを有しない場合、又は結果の１つによって参照される結果又は他の種類のオブジェクトと相互作用していない場合には、ユーザの検索セッションが終了する。一実施形態において、プロセス３２＿１０００は、ユーザの検索セッションの終了に応答して、記録されたイベントを収集し、このユーザ検索セッションからフィードバックパッケージを作成する。一実施形態において、フィードバックパッケージは、ユーザに対してレンダリングされた結果のセットと、それらの結果と関連付けられたクエリと、ユーザがクエリの結果に関与した関与イベントと、ユーザに対してレンダリングされた結果を自ら破棄した破棄イベントであって、各々がクエリと関連付けられている破棄イベントと、を含む。プロセス３２＿１０００は、ブロック３２＿１００８でこのフィードバックパッケージを検索ネットワークに送信する。一実施形態において、クライアントは、フィードバックパッケージをエッジサーバに送信し、エッジサーバは、フィードバックパッケージを処理のためにコアサーバに転送する。

図３２－１１は、ユーザフィードバックをフィードバックインデックスに組み込むプロセス３２＿１１００の一実施形態のフローチャートである。一実施形態において、プロセスフィードバックモジュールは、先に図３２－８のところで説明したプロセスフィードバックモジュール３２＿８４０などのプロセスフィードバックモジュールを処理する。図３２－１１において、プロセス３２＿１１００は、ブロック３２＿１１０２でフィードバックパッケージを受信することによって開始する。一実施形態において、フィードバックパッケージは、先に図３２－１０のところで説明したユーザの検索セッションのフィードバックパッケージである。ブロック３２＿１１０４で、プロセス３２＿１１００は、フィードバックパッケージを１つ以上のフィードバックインデックスエントリに変換する。一実施形態において、フィードバックインデックスエントリは、特定のクエリ、結果ペアについて記録されたイベントの数である。例えば、一実施形態において、フィードバックインデックスエントリは、＜クエリ、結果、レンダリング回数、関与回数、破棄回数＞を含む。クエリは、デバイスタイプ、アプリケーション、ロケール、及び地理的位置などの入力クエリ及びコンテキスト情報であり、結果はレンダリング結果であり、レンダリング回数は、そのクエリに対して結果がレンダリングされた回数であり、エンゲージメント回数はそのクエリに対して結果が関与された回数であり、破棄回数は、結果が破棄された回数である。

ブロック３２＿１１０６で、プロセス３２＿１１００は、フィードバックインデックスエントリをフィードバックインデックスに挿入する。一実施形態において、フィードバックインデックスは、ユーザフィードバックを検索インデックスに組み込む検索インデックスである。一実施形態において、フィードバックインデックスは引用インデックスであり、関与イベントは結果の肯定引用であり、破棄イベントはその結果の否定引用である。一実施形態において、引用検索インデックスは、２００９年１２月１日に出願され、このセクションに組み込まれる「Ｒａｎｋｉｎｇ ａｎｄ Ｓｅｌｅｃｔｉｎｇ Ｅｎｔｉｔｉｅｓ Ｂａｓｅｄ ｏｎ Ｃａｌｃｕｌａｔｅｄ Ｒｅｐｕｔａｔｉｏｎ ｏｒ Ｉｎｆｌｕｅｎｃｅ Ｓｃｏｒｅｓ」と題する米国特許出願第１２／６２８，７９１号に記載されている。一実施形態において、同じクエリ、結果ペアを有するフィードバックインデックスにエントリが存在する場合には、プロセス３２＿１１００が、このエントリをイベントカウントの数で更新する。

上述したとおり、フィードバックインデックスを組み込んだユーザフィードバックは、結果キャッシュを更新するために使用することができる。図３２－１２は、ユーザフィードバックを使用して結果キャッシュを更新するプロセス３２＿１２００の一実施形態のフローチャートである。一実施形態においては、先に図３２－８のところで説明した結果更新モジュール３２＿８４２などの結果更新モジュールが、プロセス３２＿１２００を実行して、結果キャッシュを更新する。図３２－１２において、プロセス３２＿１２００は、複数のクエリを含む結果セットＲＳを受信することによって開始する。一実施形態において、この結果セットは、クエリのセットと結果との間のマップである。この結果セットを使用することにより、先に図３２－８のところで説明したとおり、結果キャッシュがクエリプレフィックスの関連結果を素早く返すことができる。一実施形態において、結果セットは、ユーザフィードバックを含まない検索インデックスによって生成される。別の実施形態において、結果セットは、以前のユーザフィードバックを組み込んだ以前のフィードバックインデックスによって生成される。

ブロック３２＿１２０４で、プロセス３２＿１２００は、結果セットＲＳからの各クエリを現在のフィードバックインデックスに対して実行する。プロセス３２＿１２００は、ブロック３２＿１２０４で、実行されたクエリからの結果を使用し、ブロック３２＿１２０６で更新結果セットＲＳ'を作成する。一実施形態において、結果セットＲＳ'はフィードバック加重結果セットであり、大きな関与イベントを有するクエリの結果は、フィードバックインデックスにおける重み付けが大きく、大きな破棄イベントを有するクエリの結果は、フィードバックインデックスにおける重み付けが小さい。例えば、一実施形態において、結果セットＲＳ内のクエリＱがＲ１、Ｒ２、及びＲ３とランク付けされた結果を有し、更新されたフィードバックインデックスが、Ｑに対して、Ｒ１が２０件の関与イベント及び５０件の破棄イベントを有し、Ｒ２が１００件の関与イベント及び２件の破棄イベントを有し、Ｒ３が５０件の関与イベント及び１０件の破棄イベントを有するという結果を有する場合には、更新されたフィードバックインデックスに対してクエリＱを実行すると、Ｒ２、Ｒ３、及びＲ１とランク付けされた結果が返され得る。そのため、一実施形態においては、フィードバックインデックスを使用すると、更新された結果セットＲＳ'における結果のランク付けが変わる。別の実施形態においては、関連結果フィルタが、提示される結果に関して、その結果がｘ件の関与イベント又はｙ個以下の破棄イベントを必要とし得るというルールを有し得る。したがって、本実施形態においては、フィードバックインデックスを使用することにより、提示される結果と提示されない結果が変わり得る。プロセス３２＿１２００は、ブロック３２＿１２０８で、更新された結果セットＲＳ'を各エッジサーバに送信する。一実施形態において、プロセス３２＿１２００は、先に図３２－８のところで説明したとおり、更新された結果セットＲＳ'をコアサーバ３２＿８１６からエッジサーバ３２＿８０４に送信する。

図３２－１３は、特徴付けられたクエリ補完を使用してマルチドメイン検索を実行するフェデレータ３２＿８２４の一実施形態のブロック図である。一実施形態において、フェデレータは、補完モジュール３２＿１３０４と、ブレンダ／ランカ３２＿１３０６と、複数の検索ドメイン３２＿１３０８Ａ～Ｆと、及び語彙サービス３２＿１３１４と、を備える。一実施形態において、補完モジュール３２＿１３０４は、先に図３２－６のところで説明したとおり、クエリプレフィックスの各々についてのクエリ補完を判定する。判定されたクエリ補完はブレンダ／ランカ３２＿１３０６に転送され、ブレンダ／ランカ３２＿１３０６は、クエリ補完を使用して、先に図３２－７のところで説明したとおり、検索ドメイン３２＿１３０８Ａ～Ｆを使用して関連結果のマルチドメイン検索を実行する。一実施形態において、検索ドメイン３２＿１３０８Ａ～Ｆは、先に図３２－３のところで説明したとおり、検索ドメインである。例えば、一実施形態において、マップ検索ドメイン３２＿１３０８Ａは、先に図３２－３のところで説明したとおり、地形図に関連する情報を含む検索ドメインである。マップ検索ドメイン３２＿１３０８Ａは、マップデータソース３２＿１３１０Ａに情報を問い合わせる。メディア検索ドメイン３２＿１３０８Ｂは、図３２－３に記載のとおり、メディアに関連する検索ドメインである。メディア検索ドメイン３２＿１３０８Ｂは、メディアデータソース３２＿１３１０Ｂに情報を問い合わせる。ウィキ検索ドメイン３２＿１３０８Ｃは、先に図３２－３のところで説明したとおり、オンライン百科事典検索ドメインである。ウィキ検索ドメイン３２＿１３０８Ｃは、ウィキデータソース３２＿１３１０Ｃに情報を問い合わせる。サイト検索ドメイン３２＿１３０８Ｄは、先に図３２－３のところで説明したとおり、ウェブサイトの検索ドメインである。サイト検索ドメイン３２＿１３０８Ｄは、サイトデータソース３２＿１３１０Ｄに情報を問い合わせる。他の検索ドメインは、先に図３２－３のところで説明したとおり、ブレンダ／ランカ３２＿１３０６がアクセスできる他の検索ドメインのセットである。他の検索ドメイン３２＿１３０８Ｅは、他のデータソース３２＿１３１０Ｅに情報を問い合わせる。一実施形態において、フィードバック検索ドメイン３２＿１３０８Ｆは、図３２－３に記載のとおり、様々なデバイス上で動作するブラウザによって収集されたクエリフィードバックに基づく検索インデックスである。フィードバック検索ドメイン３２＿１３０８は、フィードバックデータソース３２＿１３１０Ｆ（例えば、フィードバック検索インデックス）に情報を問い合わせる。

加えて、ブレンダ／ランカ３２＿１３０６は、複数の検索ドメイン３２＿１３０８Ａ～Ｆからの結果を受信し、これらの結果をランク付けする。一実施形態において、ブレンダ／ランカ３２＿１３０６は、どの種類の検索が実行されているかを判断する語彙サービス３２＿１３０２を使用して、クエリ補完の各々を特徴付ける。例えば、一実施形態において、語彙サービス３２＿１３０２は、検索対象が人物、場所、モノなどであるかどうかを判断することができる。一実施形態において、語彙サービス３２＿１３０２は、語又は句をカテゴリにマッピングする知識ベース３２＿１３１２を使用する。本実施形態において、クエリ補完を特徴付けることは、検索ドメイン３２＿１３０８Ａ～Ｆによって返された結果を重み付けするために行われる。例えば、一実施形態において、クエリ補完が場所の検索であると特徴付けられた場合には、この場所についてのウィキエントリだけでなく、マップ検索ドメインからの結果も上位にランク付けされ得る。更なる例として、このクエリ補完がアーティストに関するものであることが示された場合には、メディア検索ドメインの結果を上位にランク付けすることができる。結果の重み付けについては、後ほど図３２－１４のところで更に説明する。

図３２－１４は、クエリ補完向けの語彙サービスを使用して関連結果を判定するプロセス３２＿１４００の一実施形態のフローチャートである。一実施形態において、ブレンダ／ランカ３２＿１３０６は、先に図３２－１３のところで説明したとおり、プロセス３２＿１４００を実行して、語彙サービスをクエリ補完に使用して関連結果を判定する。図３２－１４において、プロセス３２＿１４００は、ブロック３２＿１４０２でクエリ補完を受信することによって開始する。一実施形態において、受信したクエリ補完は、クエリプレフィックスを受信したことに応答してプロセス３２＿６００によって判定された補完である。一実施形態において、プロセス３２＿１４００は、１本の並列ストリームでブロック３２＿１４０４及び３２＿１４０８を実行し、別の並列ストリームでブロック３２＿１４０６及び３２＿１４１０を実行する。ブロック３２＿１４０４で、プロセス３２＿１４００は、クエリ補完を種々の検索ドメインに送信して関連結果候補を判定する。一実施形態において、検索ドメインの各々は、受信したクエリ補完を使用して、その検索ドメインの関連結果を判定する。一実施形態においては、複数の検索ドメインがクエリ補完の各々を並行して処理する。プロセス３２＿１４００は、クエリ補完（単数又は複数）を語彙サービスに送信して、補完の各々を特徴付ける。一実施形態において、語彙サービスは、クエリ補完が人物、場所、モノ、又は別の種類の情報に関するクエリであるかどうかを判断することによってクエリ補完の各々を特徴付ける。クエリ補完の特徴付けについては、後ほど図３２－１５で更に詳しく説明する。プロセス３２＿１４００は、ブロック３２＿１４０８で複数の検索ドメインからの検索結果を受信する。一実施形態において、検索結果の各々は、対応する検索ドメインからの結果を特徴付けるスコアのセットを含む。

ブロック３２＿１４１０で、プロセス３２＿１４００は、クエリ補完を特徴付ける語彙検索結果を受信する。一実施形態において、クエリ補完の特徴付けは、各クエリ補完が検索している情報のタイプを示す。例えば、一実施形態において、クエリ補完は、人、場所、モノ、又は別の種類の情報に関するクエリである。一実施形態においては、２本の並列ストリームが、ブロック３２＿１４１２で収束する。プロセス３２＿１４００は、ブロック３２＿１４１２で、クエリ補完の特徴付けを用いてそのクエリ補完に関する関連結果をランク付け及びフィルタリングする。一実施形態において、クエリ補完が人物の検索であることが示された場合には、その検索の結果である人物に関するウィキドメインからの結果が上位にランク付けされ得る。例えば、一実施形態において、クエリ補完が映画の検索と特徴付けられた場合には、その映画のレビュー又は現地の上映時間からの結果を上位にランク付けすることができる。別例として、クエリ補完が場所であるとことが示された場合には、この場所に関するウィキエントリだけでなく、マップ検索ドメインからの結果も上位にランク付けすることができる。更なる例として、このクエリ補完がアーティストに関するものであることが示された場合には、メディア検索ドメインの結果を上位にランク付けすることができる。クエリ補完を使用したランク付けについては、先に図３２－７のところでも説明している。別の実施形態において、フィードバックインデックスは、関連結果をランク付け及び／又はフィルタリングするために使用される信号ドメインであり得る。本実施形態においては、プロセス３２＿１４００が、関与イベントの数を用いて結果を上位にランク付けし、破棄イベントの数を用いて結果を下位にランク付けする。一実施形態において、プロセス３２＿１４００は、先に図３２－７、ブロック３２＿７０８のところで説明したとおり、結果をランク付けしてフィルタリングする。プロセス３２＿１４００は、ブロック３２＿１４１４で、ランク付け及びフィルタリングされた結果を返す。

上述のとおり、プロセス３２＿１４００は、語彙サービスを使用してクエリ補完を特徴付ける。図３２－１５は、クエリ補完を特徴付けるプロセス３２＿１５００の一実施形態のフローチャートである。図３２－１５において、プロセス３２＿１５００は、ブロック３２＿１５０２でクエリ補完を受信する。ブロック３２＿１５０４で、プロセス３２＿１５００は各クエリ補完をトークン化する。一実施形態において、補完をトークン化することは、クエリ補完を別個のトークン（例えば、語、句、複数形／単数形）に分けることである。トークン化されたクエリ補完に対して、プロセス３２＿１５００は、知識ベース内にあるトークン化された補完についての一致を判定する。一実施形態において、知識ベースは、カテゴリにマッピングされた語又は句のデータベースである。例えば、一実施形態において、知識ベースは、｛エッフェル塔→場所｝、｛マイケル・ジャクソン→アーティスト｝、｛バラク・オバマ→大統領｝、｛クロゴケグモ→クモ｝などのエントリを含み得る。一実施形態において、知識ベースは、オントロジを用いて構築される。一実施形態において、プロセス３２＿１５００は、用語頻度照合アルゴリズムを使用して、知識ベース内でのクエリ補完の一致を判定する。例えば、一実施形態において、クエリ補完が「マイケル・ジャクソンとは誰か？」である場合には、プロセス３２＿１５００が、「マイケル」、「ジャクソン」、又は「マイケル・ジャクソン」という用語で照合することができる。この例において、プロセス３２＿１５００は、ナレッジデータベースで最長一致を検索しようとする。知識ベースに「マイケル」、「ジャクソン」、及び「マイケル・ジャクソン」に対する一致が存在する場合には、「マイケル・ジャクソン」に対する一致が使用される。クエリ補完のうちの１つ以上に対する一致が存在する場合には、プロセス３２＿１５００がブロック３２＿１５０８で一致を返す。例えば、一実施形態において、プロセス３２＿１５００は、「マイケル・ジャクソンとは誰か？」というクエリ補完に対する「人物」、「アーティスト」、又は別の種類の特徴付けを返すことができる。一致が存在しない場合、プロセス３２＿１５００は、特徴付けなしで返す。

図３２－１６は、複数の検索ドメインからのクエリ補完を判定するための補完モジュール３２＿１６００の一実施形態のブロック図である。一実施形態において、補完モジュール３２＿１６００は、クエリプレフィックス受信モジュール３２＿１６０２と、プレフィックス送信モジュール３２＿１６０４と、補完受信モジュール３２＿１６０６と、補完ランク付け＆フィルタモジュール３２＿１６０８と、補完送信モジュール３２＿１６１０と、を含む。一実施形態において、クエリプリフィックス受信モジュール３２＿１６０２は、先に図３２－６、ブロック３２＿６０２のところで説明したとおり、クエリプレフィックスを受信する。プレフィックス送信モジュール３２＿１６０４は、先に図３２－６、ブロック３２＿６０４のところで説明したとおり、クエリプレフィックスを種々の検索ドメインに送信する。補完受信モジュール３２＿１６０６は、先に図３２－６、ブロック３２＿６０６のところで説明したとおり、クエリ補完を受信する。補完ランク付け＆フィルタモジュール３２＿１６０８は、上の図３２－６、ブロック３２＿６０８に記載のとおり、受信したクエリ補完をランク付けしてフィルタリングする。補完送信モジュール３２＿１６１０は、先に図３２－６、ブロック３２＿６１０のところで説明したとおり、クエリ補完を関連結果モジュールに送信する。

図３２－１７は、判定されたクエリ補完から複数の検索ドメインにわたって関連結果を判定する結果モジュール３２＿１７００の一実施形態のブロック図である。一実施形態において、結果モジュール３２＿１７００は、クエリ補完受信モジュール３２＿１７０２と、補完送信モジュール３２＿１７０４と、クエリ結果受信モジュール３２＿１７０６と、ランク付け及びフィルタモジュール３２＿１７０８と、及び結果返却モジュール３２＿１７１０と、を含む。一実施形態において、クエリ補完受信モジュール３２＿１７０２は、先に図３２－７、ブロック３２＿７０２のところで説明したとおり、クエリ補完を受信する。補完送信モジュール３２＿１７０４は、先に図３２－７、ブロック３２＿７０４のところで説明したとおり、補完を複数の検索ドメインに送信する。クエリ結果受信モジュール３２＿１７０６は、先に図３２－７、ブロック３２＿７０６のところで説明したとおり、複数の検索ドメインからクエリ結果を受信する。ランク付け及びフィルタモジュール３２＿１７０８は、先に図３２－７、ブロック３２＿７０８のところで説明したとおり、クエリ結果をランク付け及びフィルタリングする。結果返却モジュール３２＿１７１０は、先に図３２－７、ブロック３２＿７１０のところで説明したとおり、クエリ結果を返す。

図３２－１８は、ユーザ検索セッション中にユーザフィードバックを収集するフィードバック収集モジュール３２＿８３８の一実施形態のブロック図である。一実施形態において、フィードバック収集モジュール３２＿８３８は、レンダリングイベント検出モジュール３２＿１８０２と、イベント記録モジュール３２＿１８０４と、フィードバックパッケージ作成モジュール３２＿１８０６と、フィードバック送信モジュール３２＿１８０８と、を含む。一実施形態において、初期イベント検出モジュール３２＿１８０２は、先に図３２－１０、ブロック３２＿１００２のところで説明したとおり、初期イベントを検出してユーザ検索セッションを開始する。イベント記録モジュール３２＿１８０４は、先に図３２－１０、ブロック３２＿１００４上のところで説明したとおり、ユーザ検索セッション中にイベントを記録する。フィードバックパッケージ作成モジュール３２＿１８０６は、先に図３２－１０、ブロック３２＿１００６のところで説明したとおり、フィードバックパッケージを作成する。フィードバック送信モジュール３２＿１８０８は、先に図３２－１０、ブロック３２＿１００８のところで説明したとおり、フィードバックパッケージを送信する。

図３２－１９は、ユーザフィードバックをフィードバックインデックスに組み込むためのフィードバック処理モジュール３２＿８４０の一実施形態のブロック図である。一実施形態において、フィードバック処理モジュール３２＿８４０は、フィードバックパッケージ受信モジュール３２＿１９０２と、フィードバックパッケージ変換モジュール３２＿１９０４と、フィードバックエントリ挿入モジュール３２＿１９０６と、を含む。一実施形態において、フィードバックパッケージ受信モジュール３２＿１９０２は、図３２－１１、ブロック３２＿１１０２に記載のとおり、フィードバックモジュールを受信する。フィードバックパッケージ変換モジュール３２＿１９０４は、先に図３２－１１、ブロック３２＿１１０４のところで説明したとおり、フィードバックパッケージを変換する。フィードバックエントリ挿入モジュール３２＿１９０６は、先に図３２－１１、ブロック３２＿１１０６のところで説明したとおり、フィードバックインデックスエントリを挿入する。

図３２－２０は、ユーザフィードバックを使用して結果キャッシュを更新するクエリ結果更新モジュール３２＿８４２の一実施形態のブロック図である。一実施形態において、結果キャッシュ更新モジュール３２＿８４２は、結果セット受信モジュール３２＿２００２と、クエリ実行モジュール３２＿２００４と、結果セット更新モジュール３２＿２００６と、更新結果送信モジュール３２＿２００８と、を含む。一実施形態において、結果セット受信モジュール３２＿２００２は、図３２－１２、ブロック３２＿１２０２に記載のとおり、結果セットを受信する。クエリ実行モジュール３２＿２００４は、図３２－１２、ブロック３２＿１２０４に記載のとおり、フィードバックインデックスを使用してクエリを実行する。結果セット更新モジュール３２＿２００６は、図３２－１２、ブロック３２＿１２０６に記載のとおり、結果セットを更新する。更新結果送信モジュール３２＿２００８は、図３２－１２、ブロック３２＿１２０２に記載のとおり、更新された結果セットを送信する。

図３２－２１は、語彙サービスをクエリ補完に使用して関連結果を判定する関連結果モジュール３２＿２１００の一実施形態のブロック図である。一実施形態において、関連結果モジュール３２＿２１００は、補完受信モジュール３２＿２１０２と、補完送信モジュール３２＿２１０４と、語彙補完モジュール３２＿２１０６と、結果受信モジュール３２＿２１０８と、語彙結果受信モジュール３２＿２１１０と、結果ランク付けモジュール３２＿２１１２と、結果返却モジュール３２＿２１１４と、を含む。一実施形態において、補完受信モジュール３２＿２１０２は、図３２－１４、ブロック３２＿１４０２に記載のとおり、クエリ補完を受信する。補完送信モジュール３２＿２１０４は、図３２－１４、ブロック３２＿１４０４に記載のとおり、クエリ補完を複数の検索ドメインに送信してクエリ補完を受信する。語彙補完モジュール３２＿２１０６は、図３２－１４、ブロック３２＿１４０６に記載のとおり、クエリ補完を語彙サービスに送信する。結果受信モジュール３２＿２１０８は、図３２－１４、ブロック３２＿１４０８に記載のとおり、複数の検索ドメインからクエリ結果を受信する。語彙結果受信モジュール３２＿２１１０は、図３２－１４、ブロック３２＿１４１０に記載のとおり、語彙サービスの特徴付けを受信する。結果ランク付けモジュール３２＿２１１２は、図３２－１４、ブロック３２＿１４１２に記載のとおり、検索ドメイン結果をランク付けする。結果返却モジュール３２＿２１１４は、図３２－１４、ブロック３２＿１４１４に記載のとおり、ランク結果を返す。

図３２－２２は、クエリ補完を特徴付けるクエリ特徴付けモジュール３２＿２２００の一実施形態のブロック図である。一実施形態において、クエリ結果特徴付けモジュール３２＿２２００は、補完受信モジュール３２＿２２０２と、補完トークン化モジュール３２＿２２０４と、一致検索モジュール３２＿２２０６と、特徴付け返却モジュール３２＿２２０８と、を含む。一実施形態において、補完受信モジュール３２＿２２０２は、図３２－１５、ブロック３２＿１５０２に記載のとおり、補完を受信する。補完トークン化モジュール３２＿２２０４は、先に図３２－１５、ブロック３２＿１５０４に記載のところで説明したとおり、補完をトークン化する。一致検索モジュール３２＿２２０６は、図３２－１５、ブロック３２＿１５０６に記載のとおり、知識ベース内にあるトークン化された補完の一致を見つける。特徴付け返却モジュール３２＿２２０８は、先に図３２－１５、ブロック３２＿１５０８のところで説明したとおり、特徴付けを返す。

一部の実施形態においては、（図１Ａを参照して上述した）デバイス１００が、このセクションに記載の技術を実装するために使用される。
検索技術を実装するためのデバイス、方法、及びコンピュータ可読媒体例

一態様における、マルチドメインクエリ検索を実行するデバイスの方法及び装置について説明する。例示的な実施形態において、このデバイスは、ユーザのクライアントからクエリプレフィックスを受信する。このデバイスは更に、複数の別個の検索ドメインにまたがる複数の検索補完を判定する。加えて、このデバイスは、対応する検索ドメインによって判定された複数の検索補完の各々について計算されたスコアに基づいてこれら複数の検索補完をランク付けする。これら複数の検索補完のうちの少なくとも１つが、ユーザからのインジケーションなしで、かつクエリプレフィックスを受信したことに応答して複数の検索結果を生成するために使用される。

一部の実施形態においては、複数の別個の検索ドメインにわたるクエリプレフィックスを使用して、複数のランク付けされた補完を生成するための方法であって、ユーザのクライアントからクエリプレフィックスを受信することと、複数の別個の検索ドメインにまたがって複数の検索補完を判定することと、対応する検索ドメインによって判定された複数の検索補完であって、その中の少なくとも１つが、ユーザからのインジケーションなしで、かつクエリプレフィックスを受信したことに応答して複数の検索結果を生成するために使用される複数の検索補完の各々について計算されたスコアに基づいて複数の検索補完をランク付けすることと、を含む方法を１つ以上の処理ユニットに実行させる実行可能命令を有する非一時的機械可読媒体が提供される。

一部の実施形態において、この方法は、複数の検索補完をフィルタリングすることを含む。一部の実施形態において、複数の別個の検索ドメインの各々は、マップ検索ドメイン、メディアストア検索ドメイン、オンライン百科事典検索ドメイン、及びサイト検索ドメインからなる群から選択される。一部の実施形態において、複数の検索補完のうちの１つに対するスコアは、この検索補完の生スコア、即ち、この検索補完が受信された回数である。一部の実施形態において、複数の検索補完のうちの１つに対するスコアは、この検索補完生スコアと、この検索補完をプレフィックスとして使用する他の検索補完候補の数と、に基づくその検索補完のローカルスコアである。一部の実施形態において、複数の検索補完のうちの１つのスコアは、この検索補完生スコアと、検索ドメイン内の他の検索補完候補の数と、に基づく、その検索補完のグローバルスコアである。一部の実施形態において、クエリプレフィックスは、入力文字列とコンテキストとを含み、入力文字列はユーザによって入力される。一部の実施形態において、コンテキストは、位置と、デバイスタイプと、アプリケーション識別子と、ロケールと、を含む。

一部の実施形態においては、複数の別個の検索ドメインにわたるクエリプレフィックスを使用して、複数のランク付けされた補完を生成する方法であって、ユーザのクライアントからクエリプレフィックスを受信することと、複数の別個の検索ドメインにまたがって複数の検索補完を判定することと、対応する検索ドメインによって判定された複数の検索補完であって、その中の少なくとも１つが、ユーザからのインジケーションなしで、かつクエリプレフィックスを受信したことに応答して複数の検索結果を生成するために使用される複数の検索補完の各々について計算されたスコアに基づいて複数の検索補完をランク付けすることと、を含む方法が提供される。一部の実施形態において、この方法は、複数の検索補完をフィルタリングすることを含む。一部の実施形態において、複数の別個の検索ドメインの各々は、マップ検索ドメイン、メディアストア検索ドメイン、オンライン百科事典検索ドメイン、及びサイト検索ドメインからなる群から選択される。一部の実施形態において、複数の検索補完のうちの１つに対するスコアは、この検索補完の生スコア、即ち、この検索補完が受信された頻度である。一部の実施形態において、複数の検索補完のうちの１つに対するスコアは、この検索補完生スコアと、この検索補完をプレフィックスとして使用する他の検索補完候補の数と、に基づくその検索補完のローカルスコアである。一部の実施形態において、複数の検索補完のうちの１つのスコアは、この検索補完生スコアと、検索ドメイン内の他の検索補完候補の数と、に基づく、その検索補完のグローバルスコアである。一部の実施形態において、クエリプレフィックスは、入力文字列とコンテキストとを含み、入力文字列はユーザによって入力される。一部の実施形態において、コンテキストは、位置と、デバイスタイプと、アプリケーション識別子と、ロケールと、を含む。

一部の実施形態においては、複数の別個の検索ドメインにわたるクエリプレフィックスを使用して、複数のランク付けされた補完を生成するためのデバイスであって、プロセッサと、バスによってプロセッサに連結されたメモリと、プロセッサに、ユーザのクライアントからクエリプレフィックスを受信させ、複数の別個の検索ドメインにまたがって複数の検索補完を判定させ、対応する検索ドメインによって判定された複数の検索補完であって、その中の少なくとも１つが、ユーザからのインジケーションなしで、かつクエリプレフィックスを受信したことに応答して複数の検索結果を生成するために使用される複数の検索補完の各々について計算されたスコアに基づいて複数の検索補完をランク付けさせるプロセッサによってメモリから実行されるプロセスと、を備えるデバイスが提供される。一部の実施形態において、このプロセスは更に、プロセッサに複数の検索補完をフィルタリングさせる。一部の実施形態において、複数の別個の検索ドメインの各々は、マップ検索ドメイン、メディアストア検索ドメイン、オンライン百科事典検索ドメイン、及びサイト検索ドメインからなる群から選択される。一部の実施形態において、複数の検索補完のうちの１つに対するスコアは、この検索補完の生スコア、即ち、この検索補完が受信された頻度である。

別の態様においては、ユーザの検索セッションからのフィードバックを使用して結果キャッシュを生成する方法及び装置が提供される。本実施形態において、このデバイスは、クライアントからフィードバックパッケージを受信する。フィードバックパッケージが、ユーザによって入力されたクエリプレフィックスに応答してユーザに提示される検索セッションにおける複数のクエリ結果とのユーザ相互作用を特徴付ける。デバイスは更に、検索フィードバックインデックスを使用して複数のクエリを実行し、複数の結果に到達することによって、複数のクエリに対する複数の結果を生成する。加えて、デバイスは、複数の結果から結果キャッシュを作成し、結果キャッシュは、複数の結果を複数のクエリにマッピングし、この結果キャッシュを使用してクエリ結果をクライアントにサーブする。

一部の実施形態においては、検索セッションからのフィードバックを使用して結果キャッシュを生成する方法であって、ユーザによって入力されたクエリプレフィックスに応答してユーザに提示される、検索セッションにおける複数のクエリ結果とのユーザ相互作用を特徴付けるフィードバックパッケージをクライアントから受信することと、フィードバックパッケージを使用して、検索フィードバックインデックスにおいてエントリを追加することと、複数の結果に到達するために検索フィードバックインデックスを使用して複数のクエリを実行することにより、複数のクエリに対する複数の結果を生成することと、複数の結果を複数のクエリにマッピングし、クエリ結果をクライアントに渡すために使用される結果キャッシュを複数の結果から作成することと、を含む方法を１つ以上の処理ユニットに実行させる実行可能命令を有する、非一時的機械可読媒体が提供される。一部の実施形態においては、フィードバックパッケージは、クエリプレフィックスと、複数のクエリ結果と、ユーザ相互作用中に記録された複数のイベントと、を含む。一部の実施形態において、これら複数のイベントは、クエリプレフィックスからの結果がユーザに対して表示されるイベントであるレンダリングイベントを含む。一部の実施形態において、これら複数のイベントは、ユーザがそのクエリ結果に関与したことを示すイベントであるクエリ結果のうちの１つに対する関与イベントを含む。一部の実施形態において、そのクエリ結果に対する関与イベントは、クエリ結果のリンクをクリックすることである。一部の実施形態において、これら複数のイベントは、ユーザがそのクエリ結果を廃棄したことを示すイベントであるクエリ結果のうちの１つに対する廃棄イベントを含む。一部の実施形態において、結果キャッシュは、クエリ要求に対するクエリ結果を返すためにクライアントによって使用されるキャッシュである。一部の実施形態において、フィードバックインデックスエントリは、クエリプレフィックスと、クエリプレフィックスに対する結果と、その結果に対するイベントのセットと、を含む。

一部の実施形態においては、検索セッションからのフィードバックを使用して結果キャッシュを生成する方法であって、ユーザによって入力されたクエリプレフィックスに応答してユーザに提示される、検索セッションにおける複数のクエリ結果とのユーザ相互作用を特徴付けるフィードバックパッケージをクライアントから受信することと、フィードバックパッケージを使用して、検索フィードバックインデックスにおいてエントリを追加することと、複数の結果に到達するために検索フィードバックインデックスを使用して複数のクエリを実行することにより、複数のクエリに対する複数の結果を生成することと、複数の結果を複数のクエリにマッピングし、結果キャッシュは、クエリ結果をクライアントに渡すために使用される結果キャッシュを作成することと、を含む方法が提供される。一部の実施形態においては、フィードバックパッケージは、クエリプレフィックスと、複数のクエリ結果と、ユーザ相互作用中に記録された複数のイベントと、を含む。一部の実施形態において、これら複数のイベントは、クエリプレフィックスからの結果がユーザに対して表示されるイベントであるレンダリングイベントを含む。一部の実施形態において、これら複数のイベントは、ユーザがそのクエリ結果に関与したことを示すイベントであるクエリ結果のうちの１つに対する関与イベントを含む。一部の実施形態において、そのクエリ結果に対する関与イベントは、クエリ結果のリンクをクリックすることである。一部の実施形態において、これら複数のイベントは、ユーザがそのクエリ結果を廃棄したことを示すイベントであるクエリ結果のうちの１つに対する廃棄イベントを含む。一部の実施形態におい、結果キャッシュは、クエリ要求に対するクエリ結果を返すためにクライアントによって使用されるキャッシュである。一部の実施形態において、フィードバックインデックスエントリは、クエリプレフィックスと、クエリプレフィックスに対する結果と、その結果に対するイベントのセットと、を含む。

一部の実施形態においては、検索セッションからのフィードバックを使用して結果キャッシュを生成するためのデバイスであって、プロセッサと、バスによってプロセッサに連結されたメモリと、プロセッサによってメモリから実行されるプロセスであって、フィードバックパッケージを使用して検索フィードバックインデックスにおいてエントリを追加するプロセッサに、複数の結果に到達するために検索フィードバックインデックスを使用して複数のクエリを実行することによって複数のクエリに対する複数の結果を生成させ、複数の結果から結果キャッシュを作成させ、結果キャッシュは、複数の結果を複数のクエリにマッピングし、結果キャッシュを使用して、クエリ結果をクライアントに渡す、プロセスと、を備えるデバイスが提供される。一部の実施形態においては、フィードバックパッケージは、クエリプレフィックスと、複数のクエリ結果と、ユーザ相互作用中に記録された複数のイベントと、を含む。一部の実施形態において、これら複数のイベントは、クエリプレフィックスからの結果がユーザに対して表示されるイベントであるレンダリングイベントを含む。一部の実施形態において、これら複数のイベントは、ユーザがそのクエリ結果に関与したことを示すイベントであるクエリ結果のうちの１つに対する関与イベントを含む。

更に別の態様においては、複数の別個の検索ドメインにわたるクエリから複数のランク付けされたクエリ結果を生成する方法及びデバイスが提供される。本実施形態において、デバイスはクエリを受信し、そのクエリを使用して複数の別個の検索ドメインにまたがる複数の結果を判定する。デバイスは更に、クエリを特徴付ける。加えて、デバイスは、対応する検索ドメインと、クエリタイプを示すクエリ特徴付けと、によって判定された複数の結果の各々について計算されたスコアに基づき、複数の結果をランク付けする。

一部の実施形態においては、複数の別個の検索ドメインにまたがるクエリから、複数のランク付けされたクエリ結果を生成するための方法であって、クエリを受信することと、そのクエリを使用して複数の別個の検索ドメインにまたがって複数の結果を判定することと、そのクエリを特徴付けることと、対応する検索ドメインによって判定された複数の結果の各々について計算されたスコアと、クエリタイプを示すクエリ特徴付けと、に基づいて複数のクエリ結果をランク付けすることと、を含む方法を１つ以上の処理ユニットに実行させる実行可能命令を有する非一時的機械可読媒体が提供される。一部の実施形態において、クエリタイプは、人物、場所、及びモノの群から選択される。一部の実施形態において、この方法は、複数の検索結果をフィルタリングすることを含む。一部の実施形態において、複数の別個の検索ドメインの各々は、マップ検索ドメイン、メディアストア検索ドメイン、オンライン百科事典検索ドメイン、及びサイト検索ドメインからなる群から選択される。一部の実施形態においては、クエリを特徴付けることは、クエリをトークン化することと、知識ベース内にあるトークン化されたクエリに対する一致を見つけることと、を含む。一部の実施形態において、一致を見つけることは、クエリ内でトークン間の最長一致を見つけることを含む。一部の実施形態において、クエリをトークン化することは、クエリをトークンに分けることを含む。一部の実施形態において、トークンは、語及び句からなるグループに対して選択される。一部の実施形態において、クエリは、使用するクエリ補完に関するユーザからのインジケーションなしでクエリプレフィックスから補完されるクエリ補完である。

一部の実施形態においては、複数の別個の検索ドメインにわたるクエリから複数のランク付けされたクエリ結果を生成する方法であって、クエリを受信することと、そのクエリを使用して複数の別個の検索ドメインにまたがって複数の結果を判定することと、そのクエリを特徴付けることと、対応する検索ドメインによって判定された複数の結果の各々について計算されたスコアと、クエリタイプを示すクエリ特徴付けと、に基づいて複数のクエリ結果をランク付けすることと、を含む方法が提供される。一部の実施形態において、クエリタイプは、人物、場所、及びモノの群から選択される。一部の実施形態において、この方法は、複数の検索結果をフィルタリングすることを含む。一部の実施形態において、複数の別個の検索ドメインの各々は、マップ検索ドメイン、メディアストア検索ドメイン、オンライン百科事典検索ドメイン、及びサイト検索ドメインからなる群から選択される。一部の実施形態においては、クエリを特徴付けることは、クエリをトークン化することと、知識ベース内にあるトークン化されたクエリに対する一致を見つけることと、を含む。一部の実施形態において、一致を見つけることは、クエリ内でトークン間の最長一致を見つけることを含む。一部の実施形態において、クエリをトークン化することは、クエリをトークンに分けることを含む。一部の実施形態において、クエリは、使用するクエリ補完に関するユーザからのインジケーションなしでクエリプレフィックスから補完されるクエリ補完である。

一部の実施形態においては、複数の別個の検索ドメインにわたるクエリから、複数のランク付けされたクエリ結果を生成するためのデバイスであって、プロセッサと、バスによってプロセッサに連結されたメモリと、プロセッサにクエリを受信させ、そのクエリを使用して複数の別個の検索ドメインにまたがる複数の結果を判定させ、クエリを特徴付けさせ、対応する検索ドメインと、クエリタイプを示すクエリ特徴付けと、によって判定された複数の結果の各々について計算されたスコアに基づいて複数のクエリ結果をランク付けさせるプロセッサによってメモリから実行されるプロセスと、を備えるデバイスが提供される。一部の実施形態において、クエリタイプは、人物、場所、及びモノの群から選択される。一部の実施形態において、このプロセスは更に、プロセッサに複数の検索結果をフィルタリングさせる。
セクション３：マルチドメイン検索技術

このセクション「マルチドメイン検索技術」における資料は、一部の実施形態に係る、コンピューティングデバイス上でのマルチドメイン検索について説明し、本明細書に記載される開示内容を補足する情報を提供する。例えば、このセクションの複数部分が、コンピュータデバイス上でローカル学習を利用する１つ以上のドメインから取得された検索結果の改善について説明しており、例えば、ユーザ挙動のパターンを認識及び使用することに関連する図４Ａ～図４Ｂ、図５、及び他の図に関連する開示内容など、本明細書に記載される開示内容を補足する。一部の実施形態においては、このセクションの詳細が、（例えば、方法６００、８００、１０００、及び１２００に関して上述した）検索インタフェースに提示される検索結果の改善を支援するために使用される。
マルチドメイン検索技術の概要

ユーザのコンピューティングデバイス上でローカルに学習されたクエリ及び結果の特徴を利用して、プライベート情報のローカルデータベースからユーザに返される検索結果と、１つ以上の検索ドメインから返された結果と、を改善するための実施形態が記載されている。一実施形態においては、１つ以上の検索ドメインが、検索クエリに関連する１つ以上の特徴についてコンピューティングデバイスに通知することができ、これらの特徴を基に、コンピューティングデバイスはローカル学習を適用することができる。

一実施形態において、コンピューティングデバイスは、自身から取得した情報を使用して、検索クエリに関連する１つ以上の特徴を学習することができる。コンピューティングデバイスから、及びコンピューティングデバイスによって取得された情報は、検索クエリに関連する特徴、又は検索クエリから返された結果に関連する特徴を学習するように機械学習アルゴリズムをトレーニングするために、そのコンピューティングデバイス上でローカルに使用することができる。この特徴は、リモート検索エンジンに送信することができ、それによって、デバイスのユーザのプライバシーを侵害することなく、クエリに対して、関連性が高く、個々に応じた結果が返される。一実施形態において、この特徴は、クエリを拡張するために使用される。一実施形態において、この特徴は、クエリの用語にバイアスをかけるために使用される。この特徴は、検索クエリから返された結果をフィルタリングするために使用することもできる。クエリから返される結果は、ローカルの結果、リモート検索エンジンの結果、又はその両方であり得る。

一例において、コンピューティングデバイスのユーザは、スポーツのスコアに関する毎日の情報をコンピューティングデバイスにプッシュするニュースフィード、即ちＲＳＳフィードを購読し得る。ニュース又はＲＳＳフィードが購読ユーザについて知っている情報は、そのユーザがスポーツのスコアに興味を持っているということだけである。ユーザは、ＲＳＳフィードからコンピューティングデバイスによって受信された情報に、コンピューティングデバイス上のローカルクエリインタフェースを使用して「サッカーのスコア」を問い合わせることができる。米国のユーザにとって、

ｆｏｏｔｂａｌｌは、例えばダラスカウボーイズがプレーするアメリカンフットボールを意味する。欧州又は南米のユーザにとって、ｆｏｏｔｂａｌｌは、米国人がサッカーと呼んでいるものを表すことが多い。そのため、クエリ語句「ｆｏｏｔｂａｌｌ」に関する「サッカー」と「フットボール」の区別は、コンピューティングデバイスがトレーニングできる検索クエリに関連する特徴であり得る。コンピューティングデバイスのユーザがサッカーのスコアを求めてローカル結果と相互作用すれば、このデバイスのユーザがｆｏｏｔｂａｌｌのスコアを問い合わせた場合にはサッカーのスコアを意味するということを、ニュース又はＲＳＳフィードのローカルプレディクタが学習することができる。

一実施形態においては、リモート検索エンジンが、「フットボールとサッカー」という特徴を学習することができる。しかし、リモート検索エンジンは、アメリカンフットボールとサッカーとの間に明確な区別が存在することを学習できる一方で、サッカーのスコアを問い合わせる特定のユーザが、アメリカンフットボール又はサッカーに関する結果に興味があるかどうかは知らない。リモート検索エンジンがその区別を学習すると、リモート検索サービスがサッカーのスコアに関するクエリを次回受信した時に、リモート検索エンジンは、アメリカンフットボールのスコアとサッカーのスコアとの両方を返せることに加え、問い合わせているコンピューティングデバイスに特徴を送信してトレーニングさせ、そのコンピューティングデバイスの特定のユーザが興味を持っているのがアメリカンフットボールのスコアなのかサッカーのスコアなのかをそのコンピューティングデバイスが学習できるようにすることもできる。

一実施形態においては、ローカルクライアントが、コンピューティングデバイスのプライベートな情報を利用してその特徴を学習した後、そのコンピューティングデバイスのユーザが、

サッカーのスコアを求めてリモート検索サービスに次回問い合わせた時に、そのコンピューティングデバイスは、その特徴に対するバイアスをクエリと一緒にリモート検索サービスに送信することができる。例えば、このバイアスは、この特定のユーザがアメリカンフットボールとサッカーのどちらに興味があるかを示すことができる。

一実施形態において、コンピューティングデバイスは、線形回帰、ベイズ分類、又はナイーブベイズ分類のうちの１つの統計分析方法を用いて特徴について学習することができる。

一部の実施形態は、１つ以上のインタフェースを通じて呼び出される他のプログラムコードと相互作用する呼び出しプログラムコードを有する環境内に、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を含む。様々な関数コール、メッセージ、又は様々な種類のパラメータを更に含み得る他の種類の呼び出しを、呼び出すプログラムと呼び出されるコードとの間でＡＰＩを介して転送することができる。加えて、ＡＰＩは、呼び出すプログラムコードに、ＡＰＩで定義され、呼び出されるプログラムコードで実装されたデータ型又はクラスを使用できる機能を提供することができる。

少なくともいくつかの実施形態は、呼び出すソフトウェアコンポーネントが呼び出されるソフトウェアコンポーネントとＡＰＬを通じて相互作用する環境を含む。この環境でＡＰＩを通じて動作させるための方法は、ＡＰＬを介して１つ以上の関数コール、メッセージ、他の種類の呼び出し又はパラメータを転送することを含む。

その他の特徴及び利点は、添付の図面及び詳細な説明から明らかになるであろう。
マルチドメイン検索技術の詳細な説明

各種実施形態に関する以下の詳細な説明では、添付の図面を参照する。これらの図面において、同様の参照符号は同様の要素を示し、特定の実施形態が実施され得る方法が例として示されている。これらの実施形態は、当業者が本発明を実施できるように十分に詳述されている。そして、他の実施形態を利用することができ、本開示の範囲から逸脱しない限り、論理的、機械的、電気的、機能的、及びその他の変更が可能であるものと理解されるべきである。したがって、以下の詳細な説明が限定的な意味で解釈されるべきではなく、本発明の範囲は添付の特許請求の範囲によってのみ規定される。

各種実施形態は、ユーザに関するプライベート情報をリモート検索エンジンに開示することなく、コンピューティングデバイス上でローカルに利用可能な情報を使用して、ローカル及びリモートの両方の検索結果をコンピューティングデバイスのユーザのために改善するクエリ及び結果の特徴を学習するために記載されている。

図３３－１は、先行技術で公知である、コンピューティングデバイス３３＿１００上のローカル検索サブシステム３３＿１３０及びリモート検索サブシステム３３＿１３５のブロック図を示す。ローカル検索サブシステム３３＿１３０は、検索可能な情報のローカルデータベース３３＿１１１と通信するローカル検索インタフェース３３＿１１０を備え得る。

ローカルデータベース３３＿１１１は、ローカル検索インタフェース３３＿１１０を使用して検索するために、コンピューティングデバイス３３＿１００上のローカル情報にインデックスを付ける。ローカル情報はコンピューティングデバイス３３＿１００にとってプライベートであり、リモート検索サブシステム３３＿１３５とは共有されない。ローカル情報は、コンピューティングデバイス３３＿１００上のアプリケーション３３＿１１２及びデータ３３＿１１３に関するデータ、メタデータ、及び他の情報を含み得る。

ローカルデータベース３３＿１１１、アプリケーション３３＿１１２及びデータ３３＿１１３は、リモート検索サブシステム３３＿１３５がアクセスできない。ローカル検索インタフェース３３＿１１０に入力されたクエリ、ローカルクエリから返されたローカル結果、及びローカルクエリから返されたローカル結果とのユーザの相互作用は、リモート検索サブシステム３３＿１３５と共有されず、アクセスもできない。

ローカル検索インタフェース３３＿１１０は、通信インタフェース３３＿１を介してローカルデータベース３３＿１１１と通信することができる。ローカルデータベースは、通信インタフェース３３＿３を介してアプリケーション３３＿１１２及びデータ３３＿１１３と通信することができる。

リモート検索サブシステム３３＿１３５は、リモート検索インタフェース３３＿１２０とリモートクエリサービス３３＿１２１とを含み得る。リモートクエリサービス３３＿１２１は、ネットワークサービス３３＿１２２及びネットワーク３３＿１４０を介してリモート検索エンジン３３＿１５０にクエリを送信し、結果を返すことができる。リモート結果をローカル検索サブシステム３３＿１３０が利用することはできない。

リモート検索インタフェース３３＿１２０は、インタフェース２を介してリモートクエリサービス３３＿１２１と通信することができる。リモートクエリサービス３３＿１２１は、インタフェース４を介してネットワークサービス３３＿１２２と通信することができる。

図３３－２は、ローカル学習システム３３＿１１６を有するローカル検索サブシステム３３＿１３０をブロック図形式で示す。ローカル学習システム３３＿１１６を使用して、リモート検索エンジン３３＿１５０のローカル検索及びリモート検索の両方から返された検索結果を、個人情報を公開することなく改善することができる。一実施形態において、ローカル学習システム３３＿１１６は、リセットして学習内容をフラッシュすることができる。

ローカル検索サブシステム３３＿１３０は、ローカル検索インタフェース３３＿１１０と、コンピューティングデバイス３３＿１００上のアプリケーション３３＿１１２及びデータ３３＿１１３に関するデータ及びメタデータのローカルデータベース３３＿１１１と、を備え得る。ローカルデータベース３３＿１１１は、クライアントに記憶された連絡先データベース、コンピューティングデバイスに記憶されたドキュメントのタイトル又はドキュメント内の語、アプリケーションのタイトル、並びに、電子メール、インスタントメッセージ、スプレッドシート、プレゼンテーション、データベース、音楽ファイル、写真、動画、及びコンピューティングデバイスに対してローカルな他のデータなど、コンピューティングデバイス上のアプリケーションと関連付けられたデータ及びメタデータなどのデータソースに関するローカル情報を含み得る。一実施形態において、ローカルデータベース３３＿１１１は、ユーザのクラウドストレージに記憶されたデータソースに関する情報を含み得る。アプリケーション３３＿１１２は、計算機プログラムと、辞書と、メッセージングプログラムと、電子メールアプリケーションと、カレンダーと、電話と、カメラと、ワードプロセッサと、スプレッドシートアプリケーションと、プレゼンテーションアプリケーションと、連絡先管理アプリケーションと、マップアプリケーションと、音楽、ビデオ、又はメディアプレーヤーと、ローカル及びリモート検索アプリケーションと、その他のソフトウェアアプリケーションと、を含み得る。

クエリは、ローカル検索インタフェース３３＿１１０を使用して生成することができ、クエリ結果は、通信インタフェース３３＿１を介してローカルデータベース３３＿１１１から返し、ローカル検索インタフェース３３＿１１０に表示することができる。ローカル検索サブシステム３３＿１３０は更に、ローカルクエリサービス３３＿１１４と、ローカル検索及びフィードバック履歴３３＿１１５と、ローカル学習システム３３＿１１６と、を有し得る。ローカルクエリサービス３３＿１１４は、ローカル検索インタフェース３３＿１１０からクエリを受信することができる。一実施形態において、ローカル検索インタフェース３３＿１１０は、通信インタフェース３３＿７を介してリモートクエリサーバ３３＿１２１にクエリを渡して、ローカル検索インタフェース３３＿１１０がローカルデータベース３３＿１１１及びリモート検索エンジン３３＿１５０の両方から検索結果を受信するようにすることもできる。ローカルクエリサービス３３＿１１４は、余分なホワイトスペースを除去し、「ｔｈｅ」及び「ａ」など、出現頻度が高くて関連性の低いクエリ語句を削除し、そのクエリを、ローカルデータベース３３＿１１１によって使用可能な形式にパッケージ化することができる。リモートクエリサービス３３＿１２１は、リモート検索エンジン３３＿１５０に対して類似機能を実行することができる。一実施形態において、ローカル検索インタフェース３３＿１１０は、リモート検索エンジン３３＿１５０からクエリ結果を取得するために、通信インタフェース３３＿７を介してリモートクエリサービス３３＿１２１にクエリを渡すことができる。一実施形態において、リモートクエリサービス３３＿１２１は、ローカル学習システム３３＿１１６によって学習されたクエリ特徴を、通信インタフェース３３＿８を介して受信することができる。この特徴を使用して、クエリを拡張し、かつ／又はクエリ特徴をリモート検索エンジン３３＿１５０に対してバイアスすることができる。一実施形態において、リモートクエリサービス３３＿１２１は、リモート検索エンジン３３＿１５０から返されたクエリ特徴を、トレーニングのために通信インタフェース３３＿８を介してローカル学習システム３３＿１１６に渡すことができる。

ローカル検索及びフィードバック履歴３３＿１１５は、通信インタフェース３３＿７を介してリモートクエリサービス３３＿１２１に送信されるクエリなど、ローカルクエリインタフェース３３＿１１０を使用して発行された全ての検索クエリの履歴を記憶することができる。ローカル検索及びフィードバック履歴３３＿１１５は、クエリから返されたローカル結果及びリモート結果の両方と関連付けられたユーザフィードバックを記憶することもできる。フィードバックは、例えば、結果のクリックスルー、ユーザが結果の閲覧に費やした時間、ユーザが相互作用した最初の結果か、あるいは他の順序値か、ユーザが相互作用した唯一の結果であるかどうか、ユーザは結果と相互作用しなかった、即ち結果を破棄したかどうかなど、ユーザが結果に関与したかどうかのインジケーションを含み得る。ユーザのフィードバックは、符号化し、フィードバックが取得された結果を生成したクエリと関連付けて記憶することができる。一実施形態において、ローカル検索及びフィードバック履歴３３＿１１５は、クエリによって返された１つ以上の結果への参照を記憶することができる。ローカル検索及びフィードバック履歴３３＿１１５に記憶された情報は、プライベートなユーザ情報とみなされ、リモート検索サブシステム３３＿１３５が利用すること、即ちアクセスすることはできない。一実施形態において、ローカル検索及びフィードバック履歴３３＿１１５は、フラッシュすることができる。一実施形態においては、ローカル検索及びフィードバック履歴３３＿１１５をエージングアウトすることができる。エージングアウトのタイミングを分析することで、安定した傾向を示さない検索及びフィードバック履歴よりも安定した長期的傾向を長く保つことができる。

ローカル学習システム３３＿１１６は、ローカル検索及びフィードバック履歴３３＿１１５を分析して、ローカル学習システム３３＿１１６がトレーニングできる特徴を識別することができる。ある特徴が識別されると、ローカル学習システム３３＿１１６は、その特徴をトレーニングするためのローカルプレディクタを生成することができる。一実施形態において、プレディクタとは、１つ以上のデータで動作するソフトウェアコンポーネントのインスタンスのことである。一実施形態において、ローカルプレディクタは、回帰、ベイズ、又はナイーブベイズなどの統計的分類方法を用いてトレーニングすることができる。一実施形態において、プレディクタは、特定の結果カテゴリに固有であり得る。カテゴリについては、図３３－４の動作３３＿４２０：ローカルデバイス上での結果のブレンド、ランク付け、提示のところで更に詳しく説明している。

コンピューティングデバイス３３＿１００は、リモート検索インタフェース３３＿１２０とリモートクエリサービス３３＿１２１とを含むリモート検索サブシステム３３＿１３５を備え得る。リモート検索インタフェース３３＿１２０は、Ａｐｐｌｅ（登録商標）Ｓａｆａｒｉ（登録商標）、Ｍｏｚｉｌｌａ（登録商標）、又はＦｉｒｅｆｏｘ（登録商標）などのウェブブラウザを含み得る。クエリサービス３３＿１２１は、クエリに対する中間処理を実行した後に、ネットワーク３３＿１４０を介してそのクエリをネットワークサービス３３＿１２２に、そしてリモート検索エンジン３３＿１５０に渡すことができる。ネットワークサービス３３＿１２２は、リモート検索インタフェース３３＿１２０又はローカル検索インタフェース３３＿１１０上に表示するために、リモートクエリエンジン３３＿１５０から戻った結果を受信することができる。リモートクエリサービス３３＿１２１は、通信インタフェース３３＿４を介してネットワークサービス３３＿１２２に通信可能に連結することができる。

ネットワーク３３＿１４０は、インターネット、８０２．１１有線又は無線ネットワーク、セルラーネットワーク、ローカルエリアネットワーク、又はこれらの任意の組み合わせを含み得る。

インタフェース３３＿１～３３＿８は、プロセス間通信、共有メモリ、ソケット、又はアプリケーションプログラミングインタフェース（ＡＰＩ）を使用して実装することができる。ＡＰＩについては、図３３－７を参照して後ほど詳しく説明する。

図３３－３は、ローカル検索クエリ、ローカル検索結果、及びローカル検索結果に基づいたローカルフィードバック及び検索履歴３３＿１１５を利用して、クエリ及び結果の特徴をローカルで学習する方法３３＿３００をブロック図形式で示す。

動作３３＿３０５で、ユーザは、ローカルクエリインタフェース３３＿１１０を利用してクエリを発行することができる。

動作３３＿３１０では、ローカル検索履歴及びフィードバック履歴３３＿１１５にローカルクエリを記憶することができる。

動作３３＿３１５では、ローカル結果をローカルデータベース３３＿１１１からローカル検索インタフェース３３＿１１０に戻してユーザに表示することができる。ローカルデータベース３３＿１１１は、アプリケーション３３＿１１２によって生成されたか、又はデータ３３＿１１３と関連付けられたドキュメント、イメージ、音楽、オーディオ、ビデオ、計算機結果、連絡先、クエリ、ファイル名、ファイルメタデータ、及び他のデータなど、１つ以上のアプリケーション３３＿１１２によって生成又は処理されたデータ及びメタデータ３３＿１１３にインデックスを付ける。一実施形態において、ローカルデータベースは、１つ以上のアプリケーション３３＿１１２に対するクエリにローカル結果を返さない場合がある。例えば、「ハム」を求めるクエリが動作３３＿３０５でローカル検索インタフェース３３＿１１０に入力された場合、ローカルデータベース３３＿１１１は、辞書アプリケーション３３＿１１２からの結果と、単語「ハム」を含むドキュメント３３＿１１３からの結果と、「カニングハム」など「ハム」を有する連絡先と、を返し得るが、計算機アプリケーションには「ハム」に関連するデータ又はメタデータ３３＿１１３がないことから、計算機アプリケーション３３＿１１２の結果を返さない場合がある。しかし、動作３３＿３０５で「パイ」を求めるクエリがローカル検索インタフェース３３＿１１０に入力された場合には、ローカルデータベース３３＿１１１が、「３．１４１５９２６５４」、ギリシャ記号「７ｔ」、又は円周又は円の面積、あるいは球若しくは円柱の体積など、πの値を利用する式など、計算機アプリケーション３３＿１１２に関連する結果を返し得る。同様に、３３＿３０５でローカル検索インタフェース３３＿１１０に「タホ湖の写真」を求めるクエリが入力された場合には、ローカルデータベース３３＿１１１が、カメラアプリケーション３３＿１１２によって生成された可能性のあるタホ湖の写真の結果、電子メールアプリケーション３３＿１１２からダウンロードされた可能性のあるタホ湖の写真の結果、及び／又はワードプロセッシングアプリケーション３３＿１１２によって生成された、タホ湖の写真を含むドキュメント３３＿１１３の結果を返し得る。一実施形態において、ローカル結果は、そのローカル結果を取得又は生成したアプリケーション３３＿１１２に従って表示されるように分類することができる。例えば、電子メールアプリケーション３３＿１１２からダウンロードされたタホ湖の写真が表示用にまとめて分類されても良く、カメラアプリケーション３３＿１１２によって生成されたタホ湖の写真が表示用にまとめて分類されても良く、ワードプロセッシングアプリケーション３３＿１１２によって生成された１つ以上のドキュメントに組み込まれているタホ湖の写真が表示用にまとめて分類されても良い。

動作３３＿３２０で、ユーザは、表示されたローカル結果のうちの１つ以上と相互作用することができる。結果との相互作用又は非相互作用は、ローカル結果についてのフィードバックとしてローカル検索及びフィードバック履歴３３＿１１５に記憶することができる。

動作３３＿３２５で、ローカル傾斜システム３３＿１１６は、ローカル検索及びローカルフィードバック履歴３３＿１１５を分析して、クエリに関連する１つ以上の特徴を判断することができる。

動作３３＿３３０で、ローカル学習システム３３＿１１６が新しい特徴を識別すると、動作３３＿３３５で、その特徴について新しいローカルプレディクタを生成することができ、ローカル学習システム３３＿１１６は識別された特徴をトレーニングすることができる。

動作３３＿３４０で、その特徴が関連するクエリが次回発行される時に、その特徴を使用して、クエリの拡張、クエリの語句のバイアス、クエリから返された結果のフィルタリングのうちの１つ以上を行うことができる。

図３３－４は、ローカル検索クエリ及びリモート検索クエリの両方から返された検索結果と、ローカル及びリモート検索クエリ結果の両方についてのローカルフィードバックと、を利用してクエリ特徴をローカルに学習する方法３３＿４００をブロック図形式で示す。

動作３３＿４０５で、ユーザは、ローカル検索インタフェース３３＿１１０を使用してクエリを発行する。上述したとおり、ローカル検索インタフェース３３＿１１０は、ローカルクエリサービス３３＿１１４又はリモートクエリサービス３３＿１２１を介して、それぞれローカルデータベース３３＿１１１及びリモート検索エンジン３３＿１５０の一方又は両方にクエリを渡すことができる。

動作３３＿４１０で、ローカル検索履歴及びフィードバック履歴３３＿１１５にクエリを記憶することができる。

動作３３＿３１５及び３３＿４１５に示すとおり、ローカルデータベース３３＿１１１からのローカル結果及びリモート検索エンジン３３＿１５０からのリモート結果は、それぞれ、同時又は非同期的に返され得る。一実施形態においては、タイマー３３＿４１７を設定して、タイマーの満了までに受信された結果を表示する時期を決めることができる。一実施形態においては、タイマーの満了後に更に結果を受信することができる。時間値は、コンピューティングデバイス３３＿１００上でローカルに、若しくはリモート検索エンジン３３＿１５０上で設定すること、又は、ローカル検索結果とリモート検索結果とが異なる時間に表示されるように両方で設定することができる。

動作３３＿４２０では、ローカル検索結果とリモート結果とをブレンドしてランク付けし、その後ローカル検索インタフェース３３＿１１０上でユーザに提示することができる。一実施形態において、計算機結果の関連性が高いとローカル学習システム３３＿１１６が判断した場合には、その結果が最上位の方にランク付けされる。ユーザが計算機アプリケーション内からクエリを発行し、そのクエリが計算又は単位変換のように「見える」場合には、計算機結果の関連性が高い可能性がある。一実施形態において、クエリに一致するローカル結果３３＿３１５は、リモート検索エンジンの結果３３＿４１５より上位にランク付けすることができる。一実施形態においては、以前に学習された特徴を利用して結果をランク付け及び／又はフィルタリングすることができる。一実施形態においては、ローカル結果３３＿３１５を、電子メール、連絡先、ｉＴｕｎｅｓ、動画、ツイート、テキストメッセージ、ドキュメント、画像、スプレッドシートなどのカテゴリで提示し、各カテゴリ内で順序付けることができる。例えば、ローカル結果を、カテゴリ内で提示し、各カテゴリにおいて先頭に表示されている最も最近作成、変更、アクセス、又は閲覧されたローカル結果３３＿３１５によって順序付けることができる。別の実施形態においては、カテゴリをコンテキストによって順序付けることができる。例えば、ユーザが自分の音楽プレーヤアプリケーション３３＿１１２からローカルクエリを発行した場合には、ローカルデータベース３３＿１１１から返された音楽プレーヤアプリケーション３３＿１１２に関連する結果を、他のローカル結果の前に分類及び表示することができる。更に別の実施形態においては、ユーザがカテゴリからの結果と相互作用する頻度によってカテゴリを順序付けることができる。例えば、ユーザが電子メールの結果と相互作用することがほとんどない場合には、電子メールの結果が他のローカル結果よりも下位に分類及び表示される。一実施形態において、ローカルカテゴリの表示順序は固定される。ローカル結果カテゴリが変わることがほとんどないことから、これによってユーザは識別がしやすくなる。別の実施形態においては、関連性ランク付け順に従ってカテゴリを表示することができ、各カテゴリ内の結果を関連性ランク付け順に表示することができる。

一実施形態において、リモート検索エンジンから返された結果３３＿４１５は、クエリ語句が結果のタイトルに等しいかどうか、クエリ語句が結果のタイトル内にあるかどうか、クエリ語句が結果の本体内にあるかどうか、のうちの少なくとも１つに基づいたスコア、又は１つ以上のクエリ語句のＴＦ－ＩＤＦ（Ｔｅｒｍ Ｆｒｅｑｕｅｎｃｙ－Ｉｎｖｅｒｓｅ Ｄｏｃｕｍｅｎｔ Ｆｒｅｑｕｅｎｃｙ：語句の出現頻度対逆ドキュメント頻度）に基づいたスコアを含み得る。加えて、リモート検索エンジン検索結果３３＿４１５は、このクエリを発行した他のユーザが結果に関与したかどうか、即ち、ユーザがこのクエリに関連する結果を見つけたかどうかを示すクエリ依存型関与スコアを有し得る。結果は、他のユーザが結果に関与したかどうか、即ち、その結果を取り出すのに使用されたクエリに関係なく、他のユーザが該当する結果を見つけたかどうかを示すクエリ非依存型関与スコアを有し得る。結果はまた、その結果が関連性があるということに非常に多くのユーザが気づいたために、結果セットの最上位の方にランク付けされるべきであるということを示す「最上位ヒット」スコアも有し得る。一実施形態において、ローカル学習システム３３＿１１６は、その結果は関連性があるということに、このコンピューティングデバイス３３＿１１０のこのユーザも気づくであろうという蓋然性を結果ごとに生成することができる。

動作３３＿４２５で、ローカル検索インタフェースは、ユーザが結果に関与したかどうか、関与した場合には、ユーザが結果にどのくらいの期間にわたって関与したか、又はユーザが結果を破棄したかどうか、を示すユーザからのフィードバックを受信することができる。ユーザフィードバックは、結果がローカルデータベース結果であるかリモート検索エンジン結果であるかに関係なく、収集してローカル検索及びフィードバック履歴３３＿１１５に記憶することができる。クエリも、ローカル検索及びフィードバック履歴３３＿１１５に記憶することもできる。一実施形態において、クエリ及びフィードバック履歴は、コンピューティングデバイス３３＿１００の特定のユーザと関連付けることができる。一実施形態において、クエリ、フィードバック履歴３３＿１１５、及び特定のユーザとの関連付けは、ローカル学習システム３３＿１１６が、特定のユーザ向けのソーシャルグラフを生成するために使用することができる。

例えば、特定のユーザであるボブが、「ビル」及び「スティーブン」を求めて、動作３３＿４０５でローカルデバイス及びリモート検索エンジンに１つ以上のクエリを発行すると仮定する。ローカル結果３３＿３１５が、例えば、連絡先アプリケーション３３＿１１２から受信され、例えば、ビル及びスティーブンという名前の人物のＬｉｎｋｅｄＩｎ（登録商標）プロフィールを対象とするリモート結果３３＿４１５、及び他のリモート結果３３＿４１５が返され得る。動作３３＿４２０で結果がブレンドされ、ランク付けされ、ボブというユーザに提示された後に、ローカル結果３３＿３１５、リモート結果３３＿４１５、又はその両方とのボブの相互作用の検索クエリ及びフィードバック履歴３３＿１１５を動作３３＿４２５に記憶することができる。この記憶された検索履歴及びフィードバック３３＿１１５から、ボブがローカル結果３３＿３１５、リモート結果３３＿４１５、又はその両方と行った相互作用のソーシャルグラフをローカル学習システム３３＿１１６によって生成することができる。

一実施形態においては、リモート結果についてのローカル学習を用いて、ユーザに繰り返し提示されたが、ユーザが相互作用していない結果をフィルタリングすることもできる。例えば、ユーザが、動作３３＿４０５で、ローカルデバイス及びリモート検索エンジン３３＿１５０に現在の政治トピックを求めるクエリを発行することができる。クエリに応答して返されたリモート結果３３＿４１５は、Ｈｕｆｆｉｎｇｔｏｎ Ｐｏｓｔ（登録商標）及びＦｏｘ Ｎｅｗｓ（登録商標）からの結果を含み得る。動作３３＿４２５で、学習システム３３＿１１６は、ローカルに記憶された任意の／全ての結果についてのフィードバックから、ユーザがＦｏｘ Ｎｅｗｓ（登録商標）の結果と相互作用することがほとんど又はまったくないということを学習することができる。学習システム３３＿１１６は、「ニュースソース」という、トレーニングすべき新しい特徴を判定し、動作３３＿４２０で、ローカルデバイス上で結果をブレンドし、ランク付けし、提示する際に、今後のリモート結果からＦｏｘ Ｎｅｗｓ（登録商標）の結果を除外するようになり得る。

動作３３＿４３０では、リモート検索エンジン結果のみのフィードバック履歴をリモート検索エンジン３３＿１５０に返すことができる。フィードバック履歴は、特定のユーザ及び／又はマシンがリモート検索エンジン３３＿１５０に送信された情報内で特定されないように匿名化することができる。一実施形態においては、ユーザのプライバシーを保護するために、匿名化されたフィードバックと関連付けられたクエリがリモート検索エンジンに送信されない。

動作３３＿４３５で、ローカル学習システム３３＿１１６は、ローカル検索及びフィードバック履歴３３＿１１５を分析して、結果及び結果についてのフィードバックから特徴を識別できるかどうかを判断することができる。ローカル学習システム３３＿１１６は、特徴を識別できるかどうかを判定する際に、ローカル及びリモートの両方で、クエリに対する結果の全てについてのフィードバックを利用することができる。

ある特徴が動作３３＿４３５で識別された場合、ローカル学習システム３３＿１１６は、動作３３＿４４０で、その特徴についてのローカルプレディクタを生成し、その特徴をトレーニングすることができる。

動作３３＿４４５で、ローカル学習システム３３＿１１６は、任意選択で、ローカル学習システム３３＿１１６によって識別された特徴に基づき、リモート検索エンジンに特徴ベクトルを送信することができる。ニュースソースの例を再び使用すると、ユーザは、動作３３＿４０５で、現在の政治トピックを求めて、ローカルデバイス及びリモート検索エンジン３３＿１５０に問い合わせ得る。クエリに応答して返されたリモート結果３３＿４１５は、Ｈｕｆｆｉｎｇｔｏｎ Ｐｏｓｔ（登録商標）及びＦｏｘ Ｎｅｗｓ（登録商標）からの結果を含み得る。リモート検索エンジン３３＿１５０は、リモート検索エンジン３３＿１５０の多くのユーザによる相互作用に基づき、最高評価の結果としてＦｏｘ Ｎｅｗｓ（登録商標）の結果を返した可能性がある。ただし、この特定のユーザのローカルフィードバック履歴は、リモート検索エンジン３３＿１５０によってＦｏｘ Ｎｅｗｓ（登録商標）の結果が最上位にランク付けされたにもかかわらず、この特定のユーザがＦｏｘ Ｎｅｗｓ（登録商標）の結果と相互作用しないことを示している可能性がある。リモート検索エンジンが動作３３＿４３５における特徴としてＦｏｘ Ｎｅｗｓ（登録商標）結果を最上位にランク付けし、動作３３＿４４０でこの特徴に関するローカル学習を実行できる場合であっても、ローカル学習システム３３＿１１６は、このユーザがＦｏｘ Ｎｅｗｓ（登録商標）結果と相互作用しないものと特定し、動作３３＿４４５で、任意選択でリモート検索エンジン３３＿１５０にその特徴を返送する。

図３３－５は、コンピューティングデバイス３３＿１００によってリモート検索エンジン３３＿１５０に送信されたクエリに応答してリモート検索エンジン３３＿１５０によってコンピューティングデバイス３３＿１００に渡されたクエリ特徴をローカルに学習する方法３３＿５００をブロック図形式で示す。方法３３＿５００の動作の多くは、先に説明済みである。

動作３３＿４０５で、ユーザは、ローカル検索インタフェース３３＿１１０を使用してクエリを発行することができる。上述したとおり、ローカル検索インタフェース３３＿１１０は、ローカルデータベース３３＿１１１及びリモート検索エンジン３３＿１５０の一方又は両方にクエリを渡すことができる。

動作３３＿３１０では、ローカル検索履歴及びフィードバック履歴３３＿１１５にローカルクエリを記憶することができる。

動作３３＿３１５で、コンピューティングデバイス３３＿１００は、クエリに応答してローカルデータベース３３＿１１１から返されたローカル結果を受信することができる。ローカル結果は、リモート検索エンジン３３＿１５０から返された検索結果から独立して、かつ非同期で受信することができる。

動作３３＿５１５で、コンピューティングデバイス３３＿１００は、クエリに応答してリモート検索エンジン３３＿１５０から返された結果を受信することができる。動作３３＿５１５で、リモート検索エンジンは、クエリ及び結果に関連する特徴を、ローカル学習システム３３＿１１６がトレーニングするために返すこともできる。

一実施形態においては、タイマーの満了までに受信された結果を表示する時期を判定するためにタイマー３３＿４１７を設定することができる。一実施形態においては、タイマーの満了後に更に結果を受信することができる。タイマーの時間値は、コンピューティングデバイス３３＿１００上でローカルに、若しくはリモート検索エンジン３３＿１５０上で設定すること、又は、ローカル検索結果とリモート検索結果とが異なる時間に表示されるように両方で設定することができる。

動作３３＿４２０では、図３３－４を参照して動作３３＿４２０で先に説明したとおり、ローカル結果とリモート結果とをブレンドし、ランク付けすることができる。

動作３３＿４２５で、ローカル検索インタフェースは、ユーザが結果に関与したかどうか、関与した場合には、ユーザが結果にどのくらいの期間にわたって関与したか、又はユーザが結果を破棄したかどうか、を示すユーザからのフィードバックを受信することができる。ユーザフィードバックは、結果がローカルデータベース結果であるかリモート検索エンジン結果であるかに関係なく、収集してローカル検索及びフィードバック履歴３３＿１１５に記憶することができる。クエリも、ローカル検索及びフィードバック履歴３３＿１１５に記憶することもできる。一実施形態において、クエリ及びフィードバック履歴は、コンピューティングデバイス３３＿１００の特定のユーザと関連付けることができる。

動作３３＿４３０では、リモート検索エンジン結果のみのフィードバック履歴をリモート検索エンジン３３＿１５０に返すことができる。フィードバック履歴は、特定のユーザ及び／又はマシンがリモート検索エンジン３３＿１５０に送信された情報内で特定されないように匿名化することができる。一実施形態においては、ユーザのプライバシーを保護するために、匿名化されたフィードバックと関連付けられたクエリがリモート検索エンジンに送信されない。

動作３３＿５２０で、ローカル学習システム３３＿１１６は、動作３３＿５１５でリモート検索エンジン３３＿１５０から受信した特徴に関するローカルプレディクタを生成し、その特徴をトレーニングすることができる。ローカル学習システム３３＿１１６は、ローカルフィードバック及び検索履歴３３＿１１５を利用して、リモート検索エンジン３３＿１５０から受信した特徴に対するローカル検索結果及びリモート検索結果の両方と特定のユーザが相互作用する方法を決定することができる。ローカル学習システム３３＿１１６は、ローカル学習システム３３＿１１６によって特徴が判定されたかどうか、又はローカル学習システム３３＿１１６による学習のためにリモート検索エンジン３３＿１５０から特徴が受信されたかどうかを追跡することができる。後ほど図３３－６の動作３３＿６３０など、リモート検索エンジン３３＿１５０に特徴情報を送信する実施形態においては、特徴情報をリモート検索エンジン３３＿１５０に送信する前に匿名化して、そのユーザのプライバシーに配慮することができる。

図３３－６は、新しい特徴を受信又は判定し、その特徴をローカルでトレーニングし、その特徴を利用する方法３３＿６００をブロック図形式で示す。

動作３３＿６０５で、リモート検索エンジン３３＿１５０は、コンピューティングデバイス３３＿１００がローカルでトレーニングする新しい特徴をそのコンピューティングデバイスに返すことができる。リモート検索エンジン３３＿１５０は、コンピューティングデバイス３３＿１００によってクエリから返された結果と併せて、その特徴をコンピューティングデバイス３３＿１００に返すことができる。一実施形態においては、そのクエリがローカル検索インタフェース３３＿１１０から生成されたか、リモート検索インタフェース３３＿１２０から生成されたかに関係なく、その特徴をコンピューティングデバイスに返すことができる。一実施形態において、リモートクエリサーバ３３＿１２１は、その特徴をインターセプトし、通信インタフェース３３＿８を介してローカル学習システム３３＿１１６に渡すことができる。

動作３３＿６１０で、方法３３＿６００は、代替として、ローカル学習システム３３＿１１６が、ローカル検索履歴及びフィードバック履歴３３＿１１５を分析して特徴を判断することによって開始することができる。様々な方法でローカル検索履歴及びフィードバック履歴３３＿１１５を分析することにより、特徴を学習することができる。いくつかの例を以下に示す。

ユーザが「ｆｏｏｔｂａｌｌのスコア」を求めてクエリを発行し得る。リモート検索エンジン３３＿１５０は、フットボールのスコアとサッカーのスコアとの両方の結果を返し得る。リモート検索エンジン３３＿１５０は、クエリを送信したコンピューティングデバイス３３＿１００が、米国内にあるＩＰアドレスに所在すると判断した可能性がある。そのため、リモート検索エンジンは、ダラスカウボーイズなど、アメリカンフットボールのスコアを最も関連性の高い結果であると順位付けた。欧州や南米の多くの国では、ｆｏｏｔｂａｌｌがサッカーを意味する。クエリを発行したユーザがサッカー結果に興味を持っており、サッカーの結果と相互作用すると仮定する。ローカル学習システム３３＿１１６は、ローカル検索履歴及びフィードバック履歴３３＿１１５を分析して、ユーザが上位ランクのアメリカンフットボールのスコアと相互作用しなかったと判断することができる。ローカル学習システム３３＿１１６はその後、結果を分析して、ｆｏｏｔｂａｌｌには少なくとも２つの意味があり、このコンピューティングデバイス３３＿１００のユーザが、アメリカンフットボールよりもサッカーに対する選好を有するという特徴を判断することができる。

サッカーのスコアの例を改めて使用すると、ユーザは、サッカーのスコアの結果を受信した時に、なぜ自分がアメリカンフットボールのスコアを受信しているのか疑問に思った可能性がある。ローカルデータベース３３＿１１１から返されたローカル結果には、「ｆｏｏｔｂａｌｌ」という単語の辞書エントリが存在する可能性がある。そしてユーザは、「ｆｏｏｔｂａｌｌ」の辞書エントリをクリックした。それに応答して、ローカル学習システム３３＿１１６は、ｆｏｏｔｂａｌｌには代替定義が存在し、このユーザがアメリカンフットボールよりもサッカーに対する選好を有するという新たな特徴を判断することができる。

別例において、ユーザが「モンタナ」というクエリを入力し、本人のアドレス帳からのローカル結果である「メアリ・モンタナ」、本人の辞書からのローカル結果、ジョー・モンタナ（アメリカンフットボールのレジェンド）に対するリモート結果、及び米国のモンタナ州を受信すると仮定する。そしてユーザは、モンタナを問い合わせるたびに、ローカルアドレス帳からメアリ・モンタナを略毎回クリックする。ローカル学習システム３３＿１１６は、モンタナに対する特徴と、このユーザが連絡先レコード「メアリ・モンタナ」に対する選好を有することと、を判断することができる。

更に別の例においては、ユーザが「ＭＧ」を求めてクエリを出す。このユーザは、自身のローカルコンピュータに英国ＭＧ社の車の写真を多数入れており、ローカルデータベース３３＿１１１でインデックス化されている。リモート検索エンジン３３＿１５０は、「マグネシウム」（Ｍｇ）元素の結果を返し得る。ユーザはまた、自身のコンピュータに「Ｂｏｏｋｅｒ Ｔ．ａｎｄ ｔｈｅ ＭＧｓ」というバンドによる多くの曲を入れており、そのためにローカル結果を受信し得る。ローカル学習システム３３＿１１６は、これらの結果の違いを判断して、「ＭＧ」の特徴を判断することができる。

ある特徴が動作３３＿６０５で受信されるか、動作３３＿６１０で判断されると、ローカル学習システム３３＿１１６はその後、動作３３＿６２０で、その特徴に対するローカルプレディクタを生成することができる。

動作３３＿６２５で、ローカル学習システム３３＿１１６は、ローカル検索履歴及びフィードバック履歴３３＿１１５を利用して、ローカルプレディクタを使用して特徴「ＭＧ」をトレーニングすることができる。ローカル学習システム３３＿１１６は、コンピューティングデバイス３３＿１００のコンテキストを使用して特徴をトレーニングすることもできる。

上記ＭＧの例を使用すると、ユーザが計算機プログラム内からクエリＭＧを発行した場合、ローカル学習システム３３＿１１６は、そのコンテキストを利用して、そのユーザがマグネシウムの分子量又はマグネシウムの他の性質に興味を持っている可能性が最も高いということを学習し、それに応じてＭＧをトレーニングすることができる。ユーザがＭＧ車の写真を見ている時に写真閲覧アプリケーション内からクエリを発行した場合、ローカル学習システム３３＿１１６は、そのコンテキストを利用して、そのユーザが英国ＭＧの車に興味を持っている可能性が最も高いということを学習することができる。

動作３３＿６３０で、ローカル学習システム３３＿１１６によって学習された特徴、又はリモート検索エンジン３３＿１５０から受信した特徴は、いくつかの異なる方法で利用することができる。ＭＧを求めて新しいクエリを発行する時に、例えば、ＭＧに対する学習済みの選好（例えば、マグネシウム）を利用してクエリを拡張することができる。一実施形態において、ＭＧを求めて新しいクエリを発行する時には、例えば、そのクエリをマグネシウムの結果寄りにバイアスすることができる。ローカル学習システム３３＿１１６は、各クエリ特徴と関連付けられたバイアス率（学習済みの選好）を計算し、そのバイアスを特徴ベクトルとしてリモート検索エンジン３３＿１５０に提供することができる。一実施形態において、この特徴ベクトルは、その特徴と関連付けられたクエリ語句を使用してユーザがリモート検索エンジンに次回問い合わせる時にリモート検索エンジンに送信することができる。一実施形態において、この特徴を使用して、ローカルデータベース３３＿１１１又はリモート検索エンジン３３＿１５０のいずれか又は両方から返された結果をフィルタリングし、クエリＭＧに返された結果を、例えばマグネシウムの結果に制限することができる。

例示的実施形態の図３３－７（「ソフトウェアスタック」）において、アプリケーションは、いくつかのサービスＡＰＩを使用してサービスＡ又はＢを、いくつかのＡＰＩを使用してオペレーティングシステム（ＯＳ）を呼び出すことができ、Ａ及びＢは、いくつかのＡＰＩを使用して呼び出すことができる。

なお、サービス２には２つのＡＰＩがあり、そのうちの一方（サービス２ ＡＰＩ １）はアプリケーション１から呼び出しを受信してアプリケーション１に値を返し、他方（サービス２ ＡＰＩ ２）はアプリケーション２から呼び出しを受信してアプリケーション２に値を返し、サービス１（例えば、ソフトウェアライブラリであり得る）は、ＯＳ ＡＰＩ １を呼び出して、ＯＳ ＡＰＩ １からの戻り値を受信し、サービス２（例えば、ソフトウェアライブラリであり得る）は、ＡＰＩ １とＯＳ ＡＰＩ ２の両方を呼び出して、ＡＰＩ １とＯＳ ＡＰＩ ２の両方からの戻り値を受信し、アプリケーション２はＡＰＩ ２を呼び出して、ＡＰＩ ２からの戻り値を受信する。
マルチドメイン検索技術のためのシステム、方法、コンピュータ可読媒体の例

一部の実施形態においては、検索クエリに関連する特徴であって、コンピューティングデバイス上で生成された、リモートの検索エンジンには送信されない情報を少なくとも部分的に使用して学習される特徴をコンピューティングデバイスで学習することと、検索クエリとその特徴についてのインジケーションとをリモート検索エンジンに送信することと、検索クエリとその特徴についてのインジケーションとに応答して、コンピューティングデバイスによって検索結果を受信することと、を含むコンピュータ実装された方法が提供される。一部の実施形態において、特徴についてのインジケーションは、その特徴寄りのバイアス又は特徴ベクトルのうちの少なくとも１つを含む。一部の実施形態においては、コンピューティングデバイスから取得した情報が、そのコンピューティングデバイスに関する情報について、そのコンピューティングデバイス上で実行された検索クエリ、又は、そのコンピューティングデバイスのユーザが、そのコンピューティングデバイスに記憶された情報について、そのコンピューティングデバイス上で実行された検索クエリから返された結果に対して行った相互作用のフィードバック、のうちの少なくとも１つを含む。一部の実施形態において、学習は、コンピューティングデバイスから取得した情報の統計分析であって、線形回帰、ベイズ分類、又はナイーブベイズ分類のうちの１つを含む統計分析を含む。一部の実施形態において、この方法は、コンピューティングデバイスが学習するための検索クエリに関連する特徴をリモート検索エンジンから受信することを更に含む。一部の実施形態において、この方法は、リモート検索エンジンから受信した特徴をコンピューティングデバイスで学習することを更に含み、リモート検索エンジンから受信した特徴は、コンピューティングデバイス上で生成された、リモート検索エンジンには送信されない情報を少なくとも部分的に使用して学習される。一部の実施形態において、特徴を学習することは、コンピューティングデバイスから取得した情報に従って、検索クエリに関連するクエリ語句の曖昧さを解消することを含む。

一部の実施形態においては、処理システムによって実行されると、検索クエリに関連する特徴であって、コンピューティングデバイス上で生成された、リモートの検索エンジンには送信されない情報を少なくとも部分的に使用して学習される特徴をコンピューティングデバイスで学習することと、検索クエリとその特徴についてのインジケーションとをリモート検索エンジンに送信することと、検索クエリとその特徴についてのインジケーションとに応答して、コンピューティングデバイスによって検索結果を受信することと、を含む方法を実行する非一時的機械可読媒体が提供される。一部の実施形態において、特徴についてのインジケーションは、その特徴寄りのバイアス又は特徴ベクトルのうちの少なくとも１つを含む。一部の実施形態においては、コンピューティングデバイス上で取得した情報が、そのコンピューティングデバイス上で実行された、そのコンピューティングデバイスに関する情報についての検索クエリ、又は、そのコンピューティングデバイスのユーザが、そのコンピューティングデバイス上で実行された、そのコンピューティングデバイスに記憶された情報についての検索クエリから返された結果に対して行った相互作用のフィードバック、のうちの少なくとも１つを含む。一部の実施形態において、学習は、コンピューティングデバイスから取得した情報の統計分析であって、線形回帰、ベイズ分類、又はナイーブベイズ分類のうちの１つを含む統計分析を含む。一部の実施形態において、この方法は、コンピューティングデバイスが学習するための検索クエリに関連する特徴をリモート検索エンジンから受信することを更に含む。一部の実施形態において、この方法は、リモート検索エンジンから受信した特徴をコンピューティングデバイスで学習することを更に含み、リモート検索エンジンから受信した特徴は、コンピューティングデバイス上で生成された、リモート検索エンジンには送信されない情報を少なくとも部分的に使用して学習される。一部の実施形態において、特徴を学習することは、コンピューティングデバイスから取得した情報に従って、検索クエリに関連するクエリ語句の曖昧さを解消することを含む。

一部の実施形態においては、処理システムによって実行された時に、ある方法を実行する実行可能命令でプログラムされた処理システムを備えるシステムが提供される。この方法は、検索クエリに関連する特徴であって、システム上で生成された、リモート検索エンジンに送信されない情報を少なくとも部分的に使用して学習される特徴をシステム上で学習することと、検索クエリとその特徴についてのインジケーションとをリモート検索エンジンに送信することと、検索クエリとその特徴についてのインジケーションとに応答して、システムによって検索結果を受信することと、を含む。一部の実施形態において、特徴についてのインジケーションは、その特徴寄りのバイアス又は特徴ベクトルのうちの少なくとも１つを含む。一部の実施形態においては、コンピューティングデバイス上で取得した情報が、そのシステムに関する情報について、そのシステム上で実行された検索クエリ、又は、そのシステムのユーザが、そのシステムに記憶された情報について、そのシステム上で実行された検索クエリから返された結果に対して行った相互作用のフィードバック、のうちの少なくとも１つを含む。一部の実施形態において、学習は、システムから取得した情報の統計分析であって、線形回帰、ベイズ分類、又はナイーブベイズ分類のうちの１つを含む統計分析を含む。一部の実施形態において、この方法は、システムが学習するための検索クエリに関連する特徴をリモート検索エンジンから受信することを更に含む。一部の実施形態において、この方法は、リモート検索エンジンから受信した特徴をシステムで学習することを更に含み、リモート検索エンジンから受信した特徴は、システム上で生成された、リモート検索エンジンには送信されない情報を少なくとも部分的に使用して学習される。一部の実施形態において、特徴を学習することは、システムから取得した情報に従って、検索クエリに関連するクエリ語句の曖昧さを解消することを含む。
セクション４：構造化された提案

このセクション「構造化された提案」における資料は、一部の実施形態に係る、提案の構造化と、ユーザと関連付けられたコンテンツ（例えば、テキストメッセージ）の分析に基づいて、ユーザの連絡先及びカレンダーイベントを提案するためのコンテキスト認識コンピューティングの使用と、について説明し、本明細書に記載された開示内容を補足する情報を提供する。例えば、このセクションの複数部分において、新しい連絡先を識別及び提案する方法について説明している。その内容は、例えば、以下に論じる方法６００及び方法８００に関連する開示内容、特に、提案された人物を図９Ｂ～図９Ｃの予測部分９３０をポピュレートすることに言及した開示内容など、本明細書に記載される開示内容を補足するものである。加えて、コンテンツを分析するための技術は、方法１８００及び２０００に関して上述した技術にも応用され得るものであり、連絡先及びカレンダーイベントを提案するための技術は、音声通信コンテンツの分析に基づいてこれらの提案を行うためにも使用され得る。
構造化された提案の要約

一部の実施形態においては、連絡先を提案する方法が、電子デバイスで、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別することと、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在しないと判断することと、その判断に応答して、そのエンティティと関連付けられた連絡先を生成することと、を含み、生成された連絡先が、その連絡先情報と、生成された連絡先が提案された連絡先であるというインジケーションと、を含む。

一部の実施形態においては、連絡先を提案する方法が、電子デバイスで、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報項目を識別することと、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在すること、及びその連絡先が識別された連絡先情報項目を含まないと判断することと、その判定に応答して、その連絡先を更新し、その連絡先情報項目と、その連絡先情報項目が提案された連絡先情報項目であるというインジケーションと、を含めることと、を含む。

一部の実施形態においては、連絡先を提案する方法が、ディスプレイを有する電子デバイスで、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別することと、識別された連絡先情報が提案された連絡先情報であるというインジケーションを生成することと、そのエンティティと関連付けられた連絡先に対応する第１のユーザインタフェースであって、生成されたインジケーションに基づき、識別された連絡先情報が提案された連絡先情報であることを示す第１のユーザインタフェースオブジェクトを含む第１のユーザインタフェースを表示することと、を含む。

一部の実施形態においては、連絡先を提案する方法が、ディスプレイを有する電子デバイスで、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別することと、受信したメッセージに対応する第１のユーザインタフェースを表示することと、を含み、第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、識別されたエンティティに対応する第１のユーザインタフェースオブジェクトと、識別された連絡先情報に対応する第２のユーザインタフェースオブジェクトと、識別された連絡先情報と関連付けられた第３のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別された連絡先情報をデータベースに追加させる第３のユーザインタフェースオブジェクトと、を含む第２の部分と、を含む。

一部の実施形態においては、カレンダーイベントを提案する方法が、電子デバイスで、メッセージを受信することと、受信したメッセージ内でイベント情報を識別することと、識別されたイベント情報と関連付けられたカレンダーイベントを生成することと、を含み、生成されたカレンダーイベントは、そのイベント情報と、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーションと、を含む。

一部の実施形態においては、カレンダーイベントを提案する方法が、ディスプレイを有する電子デバイスで、メッセージを受信することと、受信したメッセージ内でイベント情報を識別することと、受信されたメッセージに対応する第１のユーザインタフェースを表示することとを含み、第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、識別されたイベント情報に対応する第１のユーザインタフェースオブジェクトと、識別されたイベント情報と関連付けられた第２のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別されたイベント情報を複数のカレンダーイベントを含むデータベースに追加させる第２のユーザインタフェースオブジェクトと、を含む第２の部分と、を含む。

一部の実施形態においては、複数の連絡先及び／又はカレンダーイベントを提案する方法が、ディスプレイを有する電子デバイスで、メッセージを受信することと、受信したメッセージ内で、連絡先情報又はイベント情報複数のインスタンスを識別することと、受信したメッセージに対応する第１のユーザインタフェースを表示することと、を含み、第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、選択されると、電子デバイスに、識別された連絡先又はイベント情報の複数のインスタンスのリストを備える第２のユーザインタフェースを表示させる第２の部分とを備える。
構造化された提案の詳細な説明

以下の開示及び実施形態の説明では、実施することができる特定の実施形態が実例として示されている添付の図面を参照する。本開示の範囲から逸脱することなく、他の実施形態及び実施例を実施することができ、変更を行うことができることを理解されたい。

上記のとおり、電子デバイス上の連絡先及びカレンダーイベントを管理することは、連絡先及びカレンダーのイベントを追加又は更新するのに、時間の経過とともに増えていく幾つかの手作業を要するため、ユーザにとって負担となり得る。このため、多くのユーザは、アドレス帳やカレンダーを最新の状態に保つことをどうしても怠るようになり、後に特定の連絡先又はイベント情報を求めて自身のデバイスで手動で検索する必要が生じた時に時間を犠牲にする。このことが、ユーザのストレスや生産性の低下につながり得る。

本開示は、メッセージに基づいてユーザの連絡先及びカレンダーイベントを自動的に提案する電子デバイスを提供することによってこの問題に対処する。このデバイスは、ユーザのメッセージを分析して連絡先及びイベント情報を把握し、この情報に基づいて、ユーザに対して提案される連絡先及びカレンダーイベントを自動的に生成又は更新することができる。提案された連絡先及びカレンダーイベントは、まるでユーザが手動で入力したかのように検索可能であり、ユーザは、提案された連絡先及びカレンダーイベントを追加又は無視することを選択できる。このようにして、ユーザの連絡先及びカレンダーイベントを、労せずして、又は最小限の労力で維持することができるため、ユーザの時間を節約し、生産性を高め、より効率的なヒューマンマシンインタフェースを生み出すことができる。
１．構造化された提案

本開示の実施形態において、電子デバイスは、ユーザに対して提案された連絡先及びカレンダーイベントを、そのユーザのメッセージから構造化することができる。提案された連絡先及びカレンダーイベントは、まるでユーザが手動で入力したかのように検索可能であり、ユーザは、提案された連絡先及びカレンダーイベントを追加又は無視（例えば、拒否）することを選択できる。このようにして、ユーザの連絡先及びカレンダーイベントを、労せずして、又は最小限の労力で維持することができるため、ユーザの時間を節約し、生産性を高め、より効率的なヒューマンマシンインタフェースを生み出すことができる。
２．１ 提案された連絡先情報

図３４－５Ａは、一部の実施形態に係る、提案された連絡先の例示的なデータアーキテクチャ３４＿５０２Ａを示す。図３４－５Ａに示すとおり、電子デバイス３４＿５００は、メッセージ３４＿５１０からの連絡先情報３４＿５２０Ａを、対応する連絡先３４＿５３０Ａと関連付ける（例えば、記憶する）ことができる。メッセージ３４＿５１０は、電子メール、インスタントメッセージ、デバイス３４＿５００上のアプリケーションを介したメッセージングなど、デバイス３４＿５００のユーザによって送信又は受信できる任意の種類のメッセージを含んで良く、メッセージ３４＿５１０に対する任意の添付を含んでも良い。

連絡先情報３４＿５２０Ａは、エンティティの名前、電話番号、住所、事業所又はソーシャルネットワーキングハンドルなど、アドレス帳データベース内の連絡先エントリと一般に関連付けられた情報を含み得る。連絡先エントリは、個人、グループ、組織、会社などを含み得るエンティティによって編成又はインデックス化されるのが典型的である。連絡先情報３４＿５２０Ａは、連絡先モジュール１３７など、そのアプリケーションが連絡先情報３４＿５２０Ａを処理するために認識できる任意の好適な形式で記憶することができる。連絡先情報３４＿５２０は、他のクライアントとのネットワークを介した更新又は同期を可能にするために、ＣａｒｄＤＡＶプロトコルなどの標準プロトコルに従ってフォーマットすることもできる。

一部の実施形態において、識別された連絡先情報３４＿５２０Ａは、相互に排他的な３つの状態、即ち、提案状態３４＿５４０、追加状態３４＿５５０、及び拒否状態３４＿５６０のうちのいずれか１つの状態で連絡先３４＿５３０Ａと関連付けることができる。提案状態３４＿５４０は、ユーザが連絡先への連絡先情報３４＿５２０Ａの追加をまだ確認も承認もしていない状態を反映することができる。追加状態３４＿５５０は、ユーザが連絡先への連絡先情報３４＿５２０Ａの追加を確認又は承認した状態を反映することができる。拒否状態３４＿５６０は、ユーザが連絡先への連絡先情報３４＿５２０Ａの追加を拒否した状態を反映することができる。連絡先３４＿５３０Ａは、関連付けられた全ての連絡先情報が同じ状態に属する場合に、この３つの状態のいずれか１つと関連付けることもできる。

一部の実施形態において、追加状態３４＿５５０は、デバイス３４＿５００がデフォルトの状態として扱うことができる。つまり、追加状態３４＿５５０にあることを示すために追加データをかかる連絡先と関連付ける必要はない。例えば、デバイス３４＿５００上でユーザが追加した連絡先は、デフォルトで３４＿５５０に設定することができる。

追加状態３４＿５５０がデフォルトの状態として扱われる実施形態において、デバイス３４＿５００は、連絡先情報３４＿５２０Ａが提案状態３４＿５４０又は拒否状態３４＿５６０のどちらかに属することを示すために、データを連絡先情報３４＿５２０Ａと関連付けることができる。このデータは、連絡先情報３４＿５２０Ａを処理するアプリケーションが、連絡先情報３４＿５２０Ａが提案状態３４＿５４０又は拒否状態３４＿５６０のどちらかにあることを認識するために使用できる任意の好適な形式（メタデータなど）をとることができる。

デバイス３４＿５００は、連絡先３４＿５３０Ａ及び関連付けられた全ての連絡先情報が提案状態３４＿５４０又は拒否状態３４＿５６０のどちらかに属することを示すために、データを連絡先３４＿５３０Ａと関連付けることもできる。

デバイス３４＿５００は、（例えば、デバイス３４＿５００上で実行中のアプリケーションを介して）連絡先情報３４＿５２０Ａを提案状態３４＿５４０で記憶することにより、提案された連絡先情報を連絡先の検索に含めることができる。ユーザの混乱を避けるために、デバイス３４＿５００は、（例えば、ラベル付け又は強調を介して）視覚的なインジケーションを提供することにより、及び／又は（例えば、ユーザに追加入力を提供した後でないとユーザが連絡先情報３４＿５２０Ａに働きかけられないようにすることによって）ユーザが連絡先情報３４＿５２０Ａに直接働きかけることを防ぐことにより、連絡先情報３４＿５２０Ａが提案状態３４＿５４０にあることをユーザに示すこともできる。入力は、タッチ、マウス、スピーチなど、任意の好適な入力方法を表し得る。

デバイス３４＿５００は、連絡先情報３４＿５２０Ａを拒否状態３４＿５６０で記憶することにより、以前に提案された連絡先情報であって、ユーザが拒否した連絡先情報を記憶して、ユーザに再びその連絡先を提案しないようにすることができる。拒否状態３４＿５６０の連絡先情報３４＿５２０Ａは、追加状態３４＿５５０及び提案状態３４＿５４０の連絡先情報を処理するアプリケーションによって無視することができる。

デバイス３４＿５００は、連絡先情報３４＿５２０Ａをデバイス３４＿５００上にローカルに記憶することができ、連絡先情報３４＿５２０Ａが提案状態３４＿５４０から追加状態３４＿５５０に変更されるまで、リモートデータベースに対して連絡先情報３４＿５２０Ａを同期させないようにすることができる。他の実施形態においては、連絡先情報３４＿５２０Ａを、提案状態３４＿５４０にある間にリモートデータベースに対して更新することができる。

デバイス３４＿５００は、メッセージ３４＿５１０内の構造化コンテンツ又は非構造化コンテンツから連絡先情報３４＿５２０Ａを識別することができる。構造化コンテンツとは、オンライン旅行代理店によって提供される、航空便、ホテル及び／又は自動車の予約情報を同じ定義済みの方法で（例えば、同じＨＴＭＬ構造を使用して）記載した自動電子メールなど、定義済みのフォーマットに従って配置された正式な編成又は構造を有するコンテンツのことである。一部の実施形態においては、構造化コンテンツから連絡先情報３４＿５２０Ａを識別するために、デバイス３４＿５００が、かかるメッセージによって提供される特定の形式の連絡先情報を認識するように構成されたテンプレートを使用することができる。一部の実施形態において、デバイス３４＿５００は、ネットワーク経由でこれらのテンプレートを追加及び／又は更新することができる。

非構造化コンテンツとは、自然言語のコンテンツ（例えば、彼らが新しい番号を手に入れたと誰かがメッセージの中で言っているなど）や電子メール署名など、正式な編成又は構造を持たないコンテンツのことである。非構造化コンテンツから連絡先情報３４＿５２０Ａを識別するために、デバイス３４＿５００は、「新しい番号を手に入れた、それは＜番号＞」のような特定の句など、連絡先情報への定義済みの参照を識別するように構成されているデータ検出部を使用することができる。デバイス３４＿５００は、これらのデータ検出部をネットワーク経由で追加及び／又は更新することができる。デバイス３４＿５００は、デバイス３４＿５００上（例えば、アドレス帳データベース内）の連絡先情報を、デバイス３４＿５００上（例えば、メッセージ内）の連絡先情報と関連付けられた言語と相関させることにより、データ検出部が依拠する定義済みの参照を改善することができる。その後、この相関言語を使用して、定義済みの参照を以降の使用に向けて洗練させることができる。デバイス３４＿５００によって分析されたメッセージコンテンツは、メッセージメタデータなど、デバイス３４＿５００によって認識可能な任意の情報を含み得る。
２．２ 提案されたイベント情報

図３４－５Ｂは、一部の実施形態に係る提案されたカレンダーイベントの例示的なデータアーキテクチャ３４＿５０２Ｂを示す。図３４－５Ｂに示すとおり、電子デバイス３４＿５００は、メッセージ３４＿５１０からの連絡先情報３４＿５２０Ｂを、対応するカレンダーイベント３４＿５３０Ｂと関連付ける（例えば、記憶する）ことができる。メッセージ３４＿５１０は、電子メール、インスタントメッセージ、デバイス上のアプリケーションを介したメッセージングなど、デバイス３４＿５００のユーザによって送信又は受信できる任意の種類のメッセージを含んで良く、メッセージに対する任意の添付を含み得る。

イベント情報３４＿５２０Ｂは、時間、日付、場所など、カレンダデータベース内のカレンダエントリと一般に関連付けられた情報を含み得る。イベント情報３４＿５２０Ｂは、カレンダモジュール１４８などのアプリケーションが、イベント情報３４＿５２０Ｂを処理するために認識できる任意の好適な形式で記憶することができる。イベント情報３４＿５２０Ｂは、他のクライアントとのネットワークを介した更新又は同期を可能にするために、ＣａｌＤＡＶプロトコルなどの標準プロトコルに従ってフォーマットすることもできる。

一部の実施形態において、識別されたカレンダー情報３４＿５２０Ｂは、相互に排他的な３つの状態、即ち、提案状態３４＿５４０、追加状態３４＿５５０、及び拒否状態３４＿５６０のうちのいずれか１つの状態でカレンダーイベント３４＿５３０Ｂと関連付けることができる。提案状態３４＿５４０は、ユーザがカレンダーイベントへのイベント情報３４＿５２０Ｂの追加をまだ確認も承認もしていない状態を反映することができる。追加状態３４＿５５０は、ユーザがカレンダーイベントへのイベント情報３４＿５２０Ｂの追加を確認又は承認した状態を反映することができる。拒否状態３４＿５６０は、ユーザがカレンダーイベントへのイベント情報３４＿５２０Ｂの追加を拒否した状態を反映することができる。カレンダーイベント３４＿５３０Ｂは、関連付けられた全てのカレンダーイベント情報が同じ状態に属する場合に、この３つの状態のいずれか１つと関連付けることもできる。

一部の実施形態において、追加状態３４＿５５０は、デバイス３４＿５００がデフォルトの状態として扱うことができる。つまり、追加状態３４＿５５０にあることを示すために追加データをかかるカレンダーイベントと関連付ける必要はない。例えば、デバイス３４＿５００上でユーザが追加したカレンダーイベントは、デフォルトで３４＿５５０に設定することができる。

追加状態３４＿５５０がデフォルトの状態として扱われる実施形態において、デバイス３４＿５００は、イベント情報３４＿５２０Ｂが提案状態３４＿５４０又は拒否状態３４＿５６０のどちらかに属することを示すために、データをイベント情報３４＿５２０Ｂと関連付けることができる。このデータは、イベント情報３４＿５２０Ｂを処理するアプリケーションが、イベント情報３４＿５２０Ｂが提案状態３４＿５４０又は拒否状態３４＿５６０のどちらかにあることを認識するために使用できる任意の好適な形式（メタデータなど）をとることができる。

デバイス３４＿５００は、カレンダーイベント３４＿５３０Ｂ及び関連付けられた全てのイベント情報が提案状態３４＿５４０又は拒否状態３４＿５６０のどちらかに属することを示すために、データをカレンダーイベント３４＿５３０Ｂと関連付けることもできる。

デバイス３４＿５００は、（例えば、デバイス３４＿５００上で実行中のアプリケーションを介して）イベント情報３４＿５２０Ｂを提案状態３４＿５４０で記憶することにより、提案されたイベント情報をカレンダーイベントの検索に含めることができる。ユーザの混乱を避けるために、デバイス３４＿５００は、（例えば、ラベル付け又は強調を介して）視覚的なインジケーションを提供することにより、及び／又は（例えば、ユーザに追加入力を提供した後でないとユーザがイベント情報３４＿５２０Ｂに働きかけられないようにすることによって）ユーザがイベント情報３４＿５２０Ｂに直接働きかけることを防ぐことにより、イベント情報３４＿５２０Ｂが提案状態３４＿５４０にあることをユーザに示すこともできる。入力は、タッチ、マウス、スピーチなど、任意の好適な入力方法を表し得る。

デバイス３４＿５００は、イベント情報３４＿５２０Ｂを拒否状態３４＿５６０で記憶することにより、以前に提案されたイベント情報であって、ユーザが拒否したイベント情報を記憶して、ユーザに再びそのイベントを提案しないようにすることができる。拒否状態３４＿５６０のイベント情報３４＿５２０Ｂは、追加状態３４＿５５０及び提案状態３４＿５４０のイベント情報を処理するアプリケーションによって無視することができる。

デバイス３４＿５００は、イベント情報３４＿５２０Ｂをデバイス３４＿５００上にローカルに記憶することができ、イベント情報３４＿５２０Ｂが提案状態３４＿５４０から追加状態３４＿５５０に変更されるまで、リモートデータベースに対してイベント情報３４＿５２０Ｂを同期させないようにすることができる。他の実施形態においては、イベント情報３４＿５２０Ｂを、提案状態３４＿５４０にある間にリモートデータベースに対して更新することができる。

デバイス３４＿５００は、メッセージ３４＿５１０内の構造化された内容又は構造化されていない内容からイベント情報３４＿５２０Ｂを識別することができる。構造化コンテンツとは、オンライン旅行代理店によって提供される、航空便、ホテル及び／又は自動車の予約情報を同じ定義済みの方法で（例えば、同じＨＴＭＬ構造を使用して）記載した自動電子メールなど、定義済みのフォーマットに従って配置された正式な編成又は構造を有するコンテンツのことである。一部の実施形態においては、構造化コンテンツからイベント情報３４＿５２０Ｂを識別するために、デバイス３４＿５００は、かかるメッセージによって提供される特定の形式のイベント情報を認識するように構成されたテンプレートを使用することができる。一部の実施形態において、デバイス３４＿５００は、ネットワーク経由でこれらのテンプレートを追加及び／又は更新することができる。

非構造化コンテンツとは、自然言語のコンテンツ（例えば、彼らある時にどこかであなたに会ったと誰かがメッセージの中で言っているなど）や電子メール署名など、正式な編成又は構造を持たないコンテンツのことである。非構造化コンテンツからイベント情報３４＿５２０Ｂを識別するために、デバイス３４＿５００は、「＜時期＞に＜住所＞で会いましょう」のような特定の句など、イベント情報への定義済みの参照を識別するように構成されているデータ検出部を使用することができる。デバイス３４＿５００は、これらのデータ検出部をネットワーク経由で追加及び／又は更新することができる。デバイス３４＿５００は、デバイス３４＿５００上（例えば、カレンダーデータベース内）のイベント情報を、デバイス３４＿５００上（例えば、メッセージ内）のイベント情報と関連付けられた言語と相関させることにより、データ検出部が依拠する定義済みの参照を改善することができる。その後、この相関言語を使用して、定義済みの参照を以降の使用に向けて洗練させることができる。デバイス３４＿５００によって分析されたメッセージコンテンツは、メッセージメタデータなど、デバイス３４＿５００によって認識可能な任意の情報を含み得る。

例示的なデータアーキテクチャ３４＿５２０Ａ及び３４＿５２０Ｂは同じでも異なっても良いということを認識すべきである。例えば、提案された連絡先に対し、提案されたカレンダーイベントの場合と同じ単一のデータアーキテクチャを使用することができる。代替として、あるデータアーキテクチャを、提案された連絡先に対して使用することができる一方で、別の異なるデータアーキテクチャを、提案されたカレンダーイベントに対して使用することもできる。

また、メッセージ３４＿５１０を処理できる対象が、提案された連絡先のみ、提案されたカレンダーイベントのみ、又は提案された連絡先と提案されたカレンダーイベントとの両方であることも認識すべきである。メッセージ３４＿５１０は、提案された連絡先と提案されたカレンダーイベントとの両方に対して処理される場合、提案された連絡先及び提案されたカレンダーイベントに対して連続又は並行して処理することができる。例えば、メッセージ３４＿５１０は、提案された連絡先に対して先に処理し、次に、提案されたカレンダーイベントに対して処理することができる。代替として、メッセージ３４＿５１０及びメッセージ３４＿５１０のコピーを、提案された連絡先及び提案されたカレンダーイベントに対して並行して処理することができる。
３．ユーザインタフェース及び関連プロセス

図３４－６Ａ～図３４－１３は、デバイス３４＿５００上で実装され得るユーザインタフェース（「ＵＩ」）及び関連プロセスの実施形態を示す。一部の実施形態において、デバイス３４＿５００はデバイス１００（図１Ａ）に対応する。

図３４－６Ａ及び図３４－６Ｇは、一部の実施形態に係る、提案された連絡先及びカレンダーイベントを提供するための例示的なユーザインタフェースを示す。

特に、図３４－６Ａは、例えば、上述のようにメッセージを処理した後など、提案された連絡先情報（即ち、提案状態３４＿５４０の連絡先情報）を有する連絡先に対応するユーザインタフェースの連絡先モジュール１３７などによる表示を示す。この例において、連絡先は、ジョン・アップルシードという名前の個人と関連付けられており、会社名（「エニー株式会社」）、勤務先電話番号（「４０５－５５５－１２３４」）、及び携帯番号（「４０５－１２３－６６３３」）を含む。会社名及び勤務先電話番号は確認済みの連絡先情報項目であり、追加状態３４＿５５０に属する。携帯番号は提案された連絡先情報項目であり、提案状態３４＿５４０に属する。

デバイス３４＿５００は、ユーザインタフェース内のユーザインタフェースオブジェクト３４＿６００（例えば、単語「提案」）を提供することで、携帯番号が提案された連絡先情報項目であり、ユーザによって確認された情報項目ではないことをユーザに示すことができる。携帯番号が提案された連絡先情報項目であることを示すラベル、アイコン、又は他の視覚的インジケーションなど、任意の適切なユーザインタフェースオブジェクトをこの目的で使用することができる。同じ連絡先が、図３４－６Ａの場合と同様に、提案状態３４＿５４０の連絡先情報項目と、追加状態３４＿５５０の連絡先情報項目とを含む場合、デバイス３４＿５００は、提案状態３４＿５４０の項目を、追加状態３４＿５５０の全項目の下に、又は追加状態３４＿５５０の全項目に対して優先順位の低い位置に表示することができる。

デバイス３４＿５００は、この初期ユーザインタフェースから提案された番号でジョン・アップルシードに電話をかけるためのアプリケーション（例えば、電話モジュール１３８）をユーザが直接呼び出せないようにすることもできる。例えば、デバイス３４＿５００は、グレーアウトされた外観（非図示）など、確認済みの連絡先情報項目の外観とは異なる視覚的外観を有する提案された番号と関連付けられたテキスト及び／又は領域を提供して、提案された番号をユーザが選択してもその番号に直接電話はかからないということを示すことができる。むしろ、提案された番号をユーザが選択すると、デバイス３４＿５００は、現在のユーザインタフェースを、提案された番号をユーザが確認した上で電話することのできる第２のユーザインタフェースと置き換えることができる。

図３４－６Ｂに示すとおり、第２のユーザインタフェース（「提案を確認」とラベル付けされている）は、提案された番号と関連付けられたユーザインタフェースオブジェクト３４＿６０２（「連絡先に追加」とラベル付けされている）を含むバナー形態の提案部分３４＿６０６を含む。ユーザがユーザインタフェースオブジェクト３４＿６０２を選択することにより、デバイス３４＿５００に、提案された番号を追加状態３４＿５５０の連絡先に追加させる（例えば、提案番号の状態を提案状態３４＿５４０から追加状態３４＿５５０に変更する）ことができる。この後続のユーザインタフェースにおいて、ユーザが携帯番号の隣に表示された電話アイコンなど、携帯番号又は同様のインジケーションをユーザが選択すると、デバイス３４＿５００は、アプリケーション（例えば、電話モジュール１３８）を呼び出して、提案された番号でジョン・アップルシードに電話をかけることができる。一部の実施形態において、ユーザがユーザインタフェースオブジェクト３４＿６０２を選択せず、携帯番号又は同様のインジケーションを選択した場合、デバイス３４＿５００は、携帯番号を提案状態３４＿５４０に保つことができる（例えば、提案された番号をユーザが呼び出すことが、その連絡先に対する提案された番号の暗黙的承認として扱われない）。他の実施形態においては、たとえユーザがユーザインタフェースオブジェクト３４＿６０２を選択しなかったとしても、デバイス３４＿５００は、ユーザが携帯番号を選択すると、その携帯番号の状態を追加状態３４＿５５０に変更することができる（例えば、提案された番号をユーザが呼び出すことが、その連絡先に対する提案された番号の暗黙的承認として扱われる）。

図３４－６Ｂの第２のユーザインタフェースは、提案された番号と関連付けられたユーザインタフェースオブジェクト３４＿６０４（「無視」とラベル付けされている）も含む。ユーザがユーザインタフェースオブジェクト３４＿６０４を選択することにより、デバイス３４＿５００に、ユーザインタフェースオブジェクト３４＿６０２の表示を停止させることができ、これにより、連絡先にその番号を追加するオプションが削除される。ユーザインタフェースオブジェクト３４＿６０４を選択すると、デバイス３４＿５００は、提案された番号の状態を、提案状態３４＿５４０から拒否状態３４＿５６０に変更することができる。拒否状態３４＿５６０では、デバイス３４＿５００を、この連絡先と関連付けられている提案された番号を今後は表示又は提案しないように構成することができる。

加えて、図３４－６Ｂの第２のユーザインタフェースは、デバイス３４＿５００によって提案された番号が識別される基となったメッセージの一部分を含むメッセージ部分３４＿６０８（「関連する電子メール」とラベル付けされている）を含む。そのため、提案された連絡先情報を確認するためのインタフェースを提供する際に、図３４－６Ｂのユーザーインタフェースは、提示された連絡先情報と関連付けられたメッセージコンテキストをユーザに提供することができる。図３４－６Ｂに示すとおり、デバイス３４＿５００は、携帯番号を有する部分に関連する電子メールの限られたセクションを表示することができる。ユーザがメッセージの表示部分を選択すると、デバイス３４＿５００は、メッセージアプリケーション（例えば、電子メールクライアントモジュール１４０）に、そのユーザに対して電子メール全体を開かせることができる。一部の実施形態においては、電子メール全体を、図３４－６Ｄに示すユーザインタフェースに対応するユーザインタフェースに、提案された連絡先情報と一緒に表示することができる。

図３４－６Ｃは、ユーザが図３４－６Ａの「編集」ユーザインタフェースオブジェクトを選択したことに応答して表示されるユーザインタフェースを示す。この編集ユーザインタフェースにおいて、ユーザは、ユーザインタフェースオブジェクト３４＿６１０によって表された提案番号に直接電話をかけることもできる。この番号は、強調（即ち太字で）表示されており、その番号が提案状態３４＿５４０にあることを示す。任意の好適な視覚的インジケーションを使用して、ユーザインタフェースオブジェクト３４＿６１０が提示状態３４＿５４０にあることを示すことができる。

図３４－６Ｄは、デバイス３４＿５００上のメッセージ（例えば、電子メールクライアントモジュール１４０によって表示された電子メール）を開いた時にユーザが閲覧できる画面を示しており、この画面では、デバイス３４＿５００がメッセージ内の提案された連絡先情報を識別した状態が示されている。図３４－６Ｄのユーザインタフェースは、提案部分３４＿６１２とメッセージ部分３４＿６１４とを含む。メッセージ部分３４＿６１４は、デバイス３４＿５００によって受信されたメッセージの内容を含む。提案部分３４＿６１２は、識別されたエンティティ（「ジョン・アップルシード」）に対応するユーザインタフェースオブジェクトと、識別された連絡先情報（「４０５－１２３－６６３３」）に対応するユーザインタフェースオブジェクトと、識別された連絡先情報と関連付けられたユーザインタフェースオブジェクト３４＿６１８（「連絡先に追加」とラベル付されている）と、を含み、ユーザインタフェースオブジェクト３４＿６１８が選択されると、デバイスが、提案された番号を追加状態３４＿５５０の連絡先に追加する。提案部分３４＿６１２は、識別された連絡先情報と関連付けられたユーザインタフェースオブジェクト３４＿６２０（「無視」とラベル付けされている）を含み、このユーザインタフェースオブジェクトが選択されると、デバイス３４＿５００が、識別された連絡先情報の状態を提案状態３４＿５４０から拒否状態３４＿５６０に変更する。拒否状態３４＿５６０では、デバイス３４＿５００を、この連絡先と関連付けられている提案された連絡先情報を今後は表示又は提案しないように構成することができる。「無視」及び「連絡先に追加」タイルの上にある提案部分３４＿６１２の識別された連絡先情報３４＿６１６を選択することにより、識別されたエンティティと関連付けられた連絡先に対応するユーザインタフェースを起動することができる。例えば、デバイス３４＿５００は、本実施形態の図３４－６Ａに示されているユーザインタフェースに対応するユーザインタフェース内に「ジョン・アップルシード」の連絡先情報を提示することができる。

図３４－６Ｅは、デバイス３４＿５００上のメッセージ（例えば、電子メールクライアントモジュール１４０によって表示された電子メール）を開いた時にユーザが閲覧できる画面を示しており、この画面では、デバイス３４＿５００がメッセージ内の提示されたイベント情報を識別した状態が示されている。図３４－６Ｅのユーザインタフェースは、提案部分３４＿６２０とメッセージ部分３４＿６２２とを含む。メッセージ部分３４＿６２２は、デバイス３４＿５００によって受信されたメッセージの内容を含む。提案部分３４＿６２０は、識別されたイベント情報（「Ｄｉｎｎｅｒ」、「Ａｎｙ Ｓｕｓｈｉ Ｂａｒ」、「Ｆｒｉ，Ｍａｒｃｈ ７ｔｈ」、又は「９：５０ＰＭ」とラベル付けされている）と、識別されたイベント情報と関連付けられたユーザインタフェースオブジェクト３４＿６２６（「カレンダーに追加」とラベル付けされている）と、を含み、ユーザインタフェースオブジェクト３４＿６２６が選択されると、デバイス３４＿５００が、提案されたイベント情報を追加状態３４＿５５０のカレンダーイベントに追加する。提案部分３４＿６２０は、デバイス３４＿５００に、識別されたイベント情報の状態を提案状態３４＿５４０から拒否状態３４＿５６０へと変更させるユーザインタフェースオブジェクト３４＿６２８（「無視」とラベル付けされている）を含む。拒否状態３４＿５６０では、デバイス３４＿５００を、このカレンダーイベントと関連付けられている提案されたイベント情報を今後は表示又は提案しないように構成することができる。「無視」及び「カレンダーに追加」タイルの上にある提案部分３４＿６２０の識別されたイベント情報３４＿６２４を選択することにより、（例えば、連絡先モジュール１３７によって表示された）識別されたイベント情報と関連付けられたカレンダーイベントに対応するユーザインタフェース（非図示）を呼び出すことができ、このユーザインタフェースを通じて、ユーザは、ユーザインタフェースオブジェクトを選択して、提案されたイベント情報を追加状態３４＿５５０のカレンダーイベントに追加することができる。

図３４－６Ｆは、デバイス３４＿５００上のメッセージ（例えば、電子メールクライアントモジュール１４０によって表示された電子メール）を開いた時にユーザが閲覧できる画面を示しており、この画面では、デバイス３４＿５００がメッセージ内の複数の提案された連絡先及び／又はカレンダーイベントを識別した状態が示されている。図３４－６Ｆのユーザインタフェースは、提案部分３４＿６３０とメッセージ部分３４＿６３２とを含む。メッセージ部分３４＿６３２は、デバイス３４＿５００によって受信されたメッセージの内容を含む。提案部分３４＿６３０は、選択されると、デバイス３４＿５００に、図３４－６Ｇに示す識別された連絡先又はイベント情報の複数のインスタンスのリストを有する後続のユーザインタフェースを表示させるユーザ選択可能領域を更に含む。図３４－６Ｇの提案の全てを図３４－６Ｆのユーザインタフェースに組み込むのではなく、図３４－６Ｆの提案部分３４＿６３０を単一のバナーに割り当てることにより、図３４－６Ｆの提案部分が、メッセージ部分内のメッセージをユーザが容易に閲覧・判読できることに干渉しないようになる。

図３４－６Ｇは、図３４－６Ｆのユーザインタフェースと関連付けられたメッセージ内の識別された提案された連絡先及びイベント情報のリストを有する後続のユーザインタフェースを示す。図３４－６Ｇに示すとおり、これらの提案はタイプ別に編成され（例えば、提案されたカレンダーイベントが一緒にグループ化され、提案された連絡先が一緒にグループ化される）、各提案は、上述の「無視」、「連絡先に追加」、及び「カレンダーに追加」を含む。図３４－６Ｇのユーザインタフェースは、選択されると、デバイス３４＿５００に、識別された連絡先又はイベント情報の複数のインスタンスのグループ（例えば、図３４－６Ｇに示す２つの提案されたカレンダーイベント）の各々を対応する追加状態３４＿５５０の連絡先又はカレンダーイベントに追加させるユーザインタフェースオブジェクト３４＿６３４（「全てを追加」）も含む。

図３４－７Ａ及び図３４－７Ｂは、一部の実施形態に係る、提案された連絡先を生成するための例示的なプロセスのフロー図を示す。このプロセスは、電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｄ、メッセージ部分３４＿６１４内の電子メール）を受信し（３４＿７０２）、受信したメッセージ内で、エンティティ（例えば、図３４－６Ｄの「ジョン・アップルシード」）と、エンティティと関連付けられた連絡先情報（例えば、図３４－６Ｄ、「４０５－１２３－６６３３」）と、を識別することができる（３４＿７０４）。デバイスは、識別されたエンティティと関連付けられた連絡先（例えば、図３４－５Ａ、連絡先３４＿５３０Ａ）がデータベース内の複数の連絡先（例えば、アドレス帳データベースなど、デバイス３４＿５００上のストレージ）の中に存在しないと判断することができ（３４＿７２２）、この判定に応答して（３４＿７２４）、デバイスは、エンティティと関連付けられた連絡先を生成することができ、生成された連絡先は、連絡先情報と、生成された連絡先が（例えば、提案状態３４＿５４０の）提案された連絡先であるというインジケーション（例えば、メタデータ）と、を含む。なお、デバイスが、「ジョン・アップルシード」という連絡先を提案された連絡先として生成すると、その連絡先内の連絡先情報の各項目を、連絡先情報の提案された項目としてインジケーションし、提案状態３４＿５４０で記憶すること、又は連絡先全体を提案された連絡先としてインジケーションし、提案状態３４＿５４０で記憶することができる。また、受信及び送信メッセージなど、デバイスに存在する任意のメッセージを、開示されたプロセスを使用して分析できるということにも留意されたい。

一部の実施形態において、識別されたエンティティは名前であり（３４＿７０６）、識別された連絡先情報は、電話番号、住所、ビジネス又はソーシャルネットワーキングハンドルである。

一部の実施形態において、デバイスは、メッセージ内の署名ブロックを認識することによって、メッセージ内で非構造化コンテンツを識別することができる。例えば、メッセージ内のエンティティ及び関連付けられた連絡先情報を識別するために、デバイスは、メッセージの署名ブロックを識別し（３４＿７０８）、識別された署名ブロックを分析して、そのエンティティ及び連絡先情報を把握することができる。メッセージは電子メールを含み得る（３４＿７１０）。そして署名ブロックは電子メール署名であり得る。電子メールは、電子メールスレッド内にある１つ以上の過去の電子メールを含み得る（３４＿７１２）。そして電子メール署名の識別はは、電子メールスレッド内にある１つ以上の過去の電子メールを分析することを含み得る。電子メールの引用層を除去することにより、デバイスは、電子メールスレッド内にある種々の電子メールに記載されている連絡先情報の場所を誤って関連付けることを避けることができる。

一部の実施形態において、デバイスは、データ検出部を用いて定義句を検索することにより、メッセージ内で非構造化コンテンツを識別することができる。例えば、メッセージ内のエンティティ及び関連する連絡先情報を識別するために、デバイスは、既定の句の集合に基づいてメッセージ内で１つ以上の句を識別し（３４＿７１４）、１つ以上の識別された句を分析して、そのエンティティ及び連絡先情報を把握することができる。デバイスは、ネットワーク経由で既定の句の集合を更新することができ（３４＿７１６）、これにより、デバイスは、引き続き正確な句を使用することができる。デバイスは、提案された連絡先を拒否する要求の結果として、既定の句のうちの１つ以上をダウングレードすることもできる（３４＿７１８）。言い換えると、ユーザが特定の句を使用して識別された提案を拒否し続ければ、それらの句が不正確であるというインジケーションになり得る。デバイスはまた、データベース内の連絡先情報（メッセージ、カレンダーイベントなど）を、電子デバイス上の連絡先情報と関連付けられた言葉と相関させることにより、既定の句のうちの１つ以上を生成することができる（３４＿７２０）。このようにして、デバイスは、連絡先情報を含むメッセージ内のどの言葉によって、ユーザがその連絡先情報を使用して連絡先を作成又は更新することになったのか、などを判定することができる。

一部の実施形態において、提案された連絡先は、図３４－５Ａのデータアーキテクチャを考慮して検索可能であり得る。例えば、デバイスは、（例えば、ユーザがデバイス上のアプリケーションを介して連絡先を検索することによって）連絡先を求める要求を受信し（３４＿７２６）、この連絡先要求に応答して、提案された連絡先を検索することができる。

一部の実施形態において、デバイスは、連絡先の生成に応答して、提案された連絡先をネットワーク経由でリモートデータベースに記憶するのを差し控えることができる（３４＿７２８）。例えば、提案された連絡先が提案状態３４＿５４０にある場合、デバイスは、ネットワーク経由で複数のクライアント上で連絡先を更新できるようにする更新又は同期サービス（例えば、デバイス上のアプリケーション）に連絡先をプッシュするのを差し控えることができる。

一部の実施形態において、デバイスは、提案された連絡先（例えば、図３４－６Ｄ、「連絡先に追加」３４＿６１８）をデータベースに追加する要求を受信し（３４＿７３０）、その要求に応答して、生成された連絡先が提案された連絡先であるというインジケーション（例えば、連絡先の状態を提案状態３４＿５４０から追加状態３４＿５５０に変更すること）をせずに、生成された連絡先をデータベースに記憶することができる。提案された連絡先をデータベースに追加する要求に応答して、デバイスは、生成された連絡先を、例えば、更新又は同期サービスにプッシュすることによって、生成された連絡先が提案された連絡先であるというインジケーションをせずにネットワーク経由でリモートデータベースに記憶することができる（３４＿７３２）。

一部の実施形態において、デバイスは、提案された連絡先を拒否する要求（例えば、図３４－６Ｄ、「無視」３４＿６２０）を受信し（３４＿７３４）、その要求に応答して、提案された連絡先を拒否することで、そのエンティティ及び連絡先情報が今後のメッセージ内で識別されたことによってその提案された連絡先が今後生成されることのないようにすることができる。これは、拒否された連絡先を拒否状態３４＿５６０で記憶することによって実装できるため、デバイスは、既に拒否された内容を知ることができる。

図３４－８Ａ及び図３４－８Ｂは、一部の実施形態に係る、提案された連絡先情報項目で既存の連絡先を更新するための例示的なプロセスのフロー図を示す。このプロセスは、電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｄ、メッセージ部分３４＿６１４内の電子メール）を受信し（３４＿８０２）、受信したメッセージ内で、エンティティ（例えば、図３４－６Ｄの「ジョン・アップルシード」）と、エンティティと関連付けられた連絡先情報の項目（例えば、図３４－６Ｄ、「４０５－１２３－６６３３」）と、を識別することができる（３４＿８０４）。デバイスは、識別されたエンティティと関連付けられた連絡先（例えば、図３４－５Ａ、連絡先３４＿５３０Ａ）がデータベース内の複数の連絡先の中に存在することと、その連絡先が、識別された連絡先情報項目を含まないことと、を判断することができる（３４＿８２２）。この判断に応答して（３４＿８２４）、デバイスは、連絡先を更新して、この連絡先情報項目と、この連絡先情報項目が提案された連絡先情報項目である（例えば、提案状態３４＿５４０になっている）というインジケーション（例えば、メタデータ）と、を含めることができる。また、受信及び送信メッセージなど、デバイスに存在する任意のメッセージを、開示されたプロセスを使用して分析できるということにも留意されたい。

一部の実施形態において、識別されたエンティティは名前であり（３４＿８０６）、識別された連絡先情報項目は、電話番号、住所、ビジネス又はソーシャルネットワーキングハンドルである。

一部の実施形態において、デバイスは、メッセージ内の署名を認識することにより、メッセージ内で非構造化コンテンツを識別することができる。例えば、メッセージ内のエンティティ及び関連付けられた連絡先情報項目を識別するために、デバイスは、メッセージの署名ブロックを識別し（３４＿８０８）、識別された署名ブロックを分析して、そのエンティティ及び連絡先情報項目を把握することができる。メッセージは電子メールを含み得る（３４＿８１０）。そして署名ブロックは電子メール署名であり得る。電子メールは、電子メールスレッド内にある１つ以上の過去の電子メールを含み得る（３４＿８１２）。そして電子メール署名の識別は電子メールスレッド内にある１つ以上の過去の電子メールを分析することを含み得る。電子メールの引用層を除去することにより、デバイスは、電子メールスレッド内にある種々の電子メールに記載されている連絡先情報の場所を誤って関連付けることを避けることができる。

一部の実施形態において、デバイスは、データ検出部を用いて定義句を検索することにより、メッセージ内で非構造化コンテンツを識別することができる。例えば、メッセージ内のエンティティ及び関連する連絡先情報項目を識別するために、デバイスは、既定の句の集合に基づいてメッセージ内で１つ以上の句を識別し（３４＿８１４）、１つ以上の識別された句を分析して、そのエンティティ及び連絡先情報項目を把握することができる。デバイスは、ネットワーク経由で既定の句の集合を更新することができ（３４＿８１６）、これにより、引き続き正確な句を使用することができる。デバイスは、提案された連絡先情報項目を拒否する要求の結果として、既定の句のうちの１つ以上をダウングレードすることもできる（３４＿８１８）。言い換えると、ユーザが特定の句を使用して識別された提案を拒否し続ければ、それらの句が不正確であるというインジケーションになり得る。デバイスはまた、データベース内の連絡先情報（メッセージ、カレンダーイベントなど）を、電子デバイス上の連絡先情報と関連付けられた言葉と相関させることにより、既定の句のうちの１つ以上を生成することができる（３４＿８２０）。このようにして、デバイスは、連絡先情報を含むメッセージ内のどの言葉によって、ユーザがその連絡先情報を使用して連絡先を作成又は更新することになったのか、などを判断することができる。

一部の実施形態において、提案された連絡先は、図３４－５Ａのデータアーキテクチャを考慮して検索可能であり得る。例えば、デバイスは、（例えば、ユーザがデバイス上のアプリケーションを介して連絡先を検索することによって）連絡先を求める要求を受信し（３４＿８２６）、この連絡先要求に応答して、提案された連絡先情報項目を検索することができる。

一部の実施形態において、デバイスは、連絡先の更新に応答して、提案された連絡先情報項目をネットワーク経由でリモートデータベースに記憶するのを差し控えることができる（３４＿８２８）。提案された連絡先情報項目が提案状態３４＿５４０にある場合、デバイスは、ネットワーク経由で複数のクライアント上で連絡先を更新できるようにする更新又は同期サービス（例えば、デバイス上のアプリケーション）に連絡先情報項目をプッシュするのを差し控えることができる。

一部の実施形態において、デバイスは、提案された連絡先情報項目（例えば、図３４－６Ｂ、「連絡先に追加」３４＿６０２）をデータベースに追加する要求を受信し（３４＿８３０）、その要求に応答して、その連絡先情報項目が提案された連絡先情報項目であるというインジケーション（例えば、連絡先情報の状態を提案状態３４＿５４０から追加状態３４＿５５０に変更すること）をせずに、更新された連絡先をデータベースに記憶することができる。提案された連絡先情報項目をデータベースに追加する要求に応答して、デバイスは、生成された連絡先を、例えば、更新／同期サービスにプッシュすることによって、その連絡先情報項目が提案された連絡先情報項目であるというインジケーションをせずに、更新された連絡先をネットワーク経由でリモートデータベースに記憶することができる（３４＿８３２）。

一部の実施形態において、デバイスは、提案された連絡先情報項目を拒否する要求（例えば、図３４－６Ｂ、「無視」３４＿６０４）を受信し（３４＿８３４）、その要求に応答して、提案された連絡先情報項目を拒否することで、そのエンティティ及び連絡先情報項目が今後のメッセージ内で識別された結果としてその提案された連絡先情報項目が今後更新されないようにすることができる。これは、拒否された連絡先情報を拒否状態３４＿５６０で記憶することによって実装することができるため、デバイスは、既に拒否された内容を知ることができる。

図３４－９Ａ及び図３４－９Ｂは、一部の実施形態に係る、提案された連絡先情報を有する連絡先を表示するための例示的なプロセスのフロー図を示す。このプロセスは、ディスプレイを備える電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｄ、メッセージ部分３４＿６１４内の電子メール）を受信し（３４＿９０２）、受信したメッセージ内で、エンティティ（例えば、図３４－６Ｄの「ジョン・アップルシード」）と、エンティティと関連付けられた連絡先情報（例えば、図３４－６Ｄ、「４０５－１２３－６６３３」）と、を識別することができる（３４＿９０４）。デバイスは、識別された連絡先情報が提案された連絡先情報であるというインジケーション（例えば、メタデータ）を生成し（３４＿９０６）、そのエンティティと関連付けられた連絡先に対応する第１のユーザインタフェース（例えば、図３４－６Ａ）を表示することができる（３４＿９０８）。第１のユーザインタフェースは、識別された連絡先情報が提案された連絡先情報であることを示す生成されたインジケーションに基づく第１のユーザインタフェースオブジェクト（例えば、「提案」）を含み得る。

一部の実施形態において、デバイスは、提案された連絡先情報の選択に対応する入力がアプリケーションを呼び出してエンティティと連絡をとることができない（例えば、図３４－６Ａ、提案された番号を選択してもその番号に電話をかけない）ようにすることができる（３４＿９１０）。

一部の実施形態において、デバイスは、第１のユーザインタフェース内の提案された連絡先情報の選択に対応する入力を検出することができ（３４＿９１２）、検出に応答して、識別された連絡先情報と関連付けられた第２のユーザインタフェースオブジェクト（例えば、図３４－６Ｂ、「連絡先に追加」３４＿６０２）を含む第２のユーザインタフェース（例えば、図３４－６Ｂ）を表示することができ、このユーザインタフェースが選択されると、電子デバイスは、識別された連絡先情報をデータベースに追加する。第２のユーザインタフェースは、識別された連絡先情報と関連付けられた第３のユーザインタフェースオブジェクト（例えば、図３４－６Ｂ、「無視」３４＿６０４）を含み得る（３４＿９１４）。このユーザインタフェースオブジェクトは、選択されると、電子デバイスに第２のユーザインタフェースオブジェクトの表示を停止させる。第２のユーザインタフェースを表示することにより、第１のユーザインタフェースを表示するのを停止することができる（３４＿９１６）。デバイスは、識別された連絡先情報をデータベースに追加したことに応答して、第１のユーザインタフェースオブジェクトを表示するのを停止することができる（３４＿９１８）。

一部の実施形態において、第２のユーザインタフェースは、メッセージ（例えば、図３４－６Ｂ、「関連電子メール」）の少なくとも一部分を表示することができる（３４＿９２０）。デバイスは、表示されたメッセージの選択に対応する入力を検出し（３４＿９２２）、検出に応答して、メッセージ（例えば、図３４－６Ｄ）を開くためのアプリケーション（例えば電子メールクライアントモジュール１４０）を呼び出すことができる。メッセージは電子メールであり得る（３４＿９２４）。そしてアプリケーションは電子メールアプリケーションであり得る。

一部の実施形態において、デバイスは、第２のユーザインタフェース内の提案された連絡先情報の選択に対応する入力を検出し（３４＿９２６）、検出に応答して、識別された連絡先情報を使用してそのエンティティと連絡をとるためのアプリケーション（例えば電話モジュール１３８）を呼び出すことができる。第２のユーザインタフェース内の提案された連絡先情報の選択に対応する入力の検出に応答して、デバイスは、識別された連絡先情報をデータベースに追加する（例えば、連絡先情報の状態を提案状態から３４＿５４０から追加状態３４＿５５０に変更する）ことができる（３４＿９２８）。デバイスは、識別された連絡先情報をデータベースに追加したことに応答して、第１のユーザインタフェースオブジェクトを表示するのを停止することができる（３４＿９１８）。

図３４－１０は、一部の実施形態に係る、メッセージを有する提案された連絡先情報を表示するための例示的なプロセスのフロー図を示す。このプロセスは、ディスプレイを備える電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｄ、メッセージ部分３４＿６１４内の電子メール）を受信し（３４＿１００２）、受信したメッセージ内で、エンティティ（例えば、図３４－６Ｄの「ジョン・アップルシード」）と、エンティティと関連付けられた連絡先情報（例えば、図３４－６Ｄ、「４０５－１２３－６６３３」）と、を識別することができる（３４＿１００４）。メッセージは電子メールであり得る（３４＿１００６）。識別されたエンティティは名前であり（３４＿１００８）、識別された連絡先情報は、電話番号、住所、ビジネス又はソーシャルネットワーキングハンドルであり得る。

デバイスは、受信したメッセージに対応する第１のユーザインタフェース（例えば、図３４－６Ｄ）を表示することができる（３４＿１０１０）。第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分（例えば、図３４－６Ｄ、メッセージ部分３４＿６１４）と、識別された連絡先情報に対応する第１のユーザインタフェースオブジェクト（例えば、図３４－６Ｄ、「４０５－１２３－６６３３」）と、識別された連絡先情報に対応する第２のユーザインタフェースオブジェクト（例えば、図３４－６Ｄ、「ジョン・アップルシード」）と、識別された連絡先情報と関連付けられた第３のユーザインタフェースオブジェクト（例えば、図３４－６Ｄ、「連絡先に追加」３４＿６１８）と、を含む第２の部分（例えば、図３４－６Ｄ、提案部分３４＿６１２）と、を含んでもよく、第３のユーザインタフェースオブジェクトは、選択されると、電子デバイスに、識別された連絡先情報をデータベースに追加させる（例えば、その連絡先情報を連絡先として記憶する）。第２の部分は、識別された連絡先情報と関連付けられた第４のユーザインタフェースオブジェクト（例えば、図３４－６Ｄ、「無視」３４＿６２０）を含み得る（３４＿１０１２）。このユーザインタフェースオブジェクトは、選択されると、電子デバイスに第３のユーザインタフェースオブジェクトの表示を停止させる。

図３４－１１Ａ及び図３４－１１Ｂは、一部の実施形態に係る提案されたカレンダーイベントを生成するための例示的なプロセスのフロー図を示す。このプロセスは、電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｅ、メッセージ部分３４＿６２２内の電子メール）を受信し（３４＿１１０２）、受信したメッセージ内で、イベント情報（例えば、図３４－６Ｅ、「Ｄｉｎｎｅｒ」、「Ａｎｙ Ｓｕｓｈｉ Ｂａｒ」、「Ｆｒｉ，Ｍａｒｃｈ ７ｔｈ」、又は「９：５０ ＰＭ」）を識別することができる（３４＿１１０４）。デバイスは、識別されたイベント情報と関連付けられたカレンダーイベント（例えば、図３４－５Ｂ、カレンダーイベント３４＿５３０Ｂ）を生成することができ（３４＿１１２２）、生成されたカレンダーイベントは、生成されたカレンダーイベント情報と、生成されたカレンダーイベントが提案されたカレンダーイベントである（例えば、提案状態３４＿５４０である）というインジケーション（例えば、メタデータ）と、を含む。

一部の実施形態において、識別されたイベント情報は、日付と時刻である（３４＿１１０６）。一部の実施形態において、デバイスは、かかるメッセージによって提供された特定の形式のイベント情報を認識するように構成されたテンプレートを使用することにより、メッセージ内で構造化コンテンツを識別することができる。例えば、メッセージ内のイベント情報を識別するために、デバイスは、メッセージ内のコンテンツの形式を識別し（３４＿１１０８）、メッセージ内にあるコンテンツの形式のイベント情報を認識するように構成されている定義済みのテンプレートの集合からテンプレートを識別し、識別されたテンプレートを有するコンテンツを分析して、イベント情報を把握することができる。メッセージは電子メールを含み得る（３４＿１１１０）。そしてコンテンツは予約を含み得る（例えば、図３４－６Ｅ）。デバイスは、ネットワーク経由で定義済みのテンプレートの集合を更新することができ（３４＿１１１２）、これにより、正確なテンプレートを使用し続けることができる。

一部の実施形態において、デバイスは、データ検出部を用いてイベント情報への参照を検索することにより、メッセージ内で非構造化コンテンツを識別することができる。例えば、メッセージ内のイベント情報を識別するために、デバイスは、日時に対する定義済みの参照の集合に基づいて、日時に対する１つ以上の参照をメッセージ内で識別し（３４＿１１１４）、その日時に対する１つ以上の識別された参照を分析して、イベント情報を把握することができる。

デバイスは、日時に対する定義済みの参照の集合をネットワーク経由で更新し（３４＿１１１６）、これにより、引き続き正確な参照を使用することができる。デバイスは、提案されたカレンダーイベントを拒否する要求の結果として、日時に対する定義済みの参照のうちの１つ以上をダウングレードすることができる（３４＿１１１８）。言い換えると、ユーザが日時に対する特定の参照を使用して識別された提案を拒否し続ければ、それらの参照が不正確であるというインジケーションになり得る。デバイスは、複数のカレンダーイベントを含むデータベース内のイベント情報を、電子デバイス上のイベント情報と関連付けられた言葉と相関させることにより、日時に対する定義済みの参照のうちの１つ以上を生成することができる（３４＿１１２０）。このようにして、デバイスは、イベント情報を含むメッセージ内のどの言葉によって、ユーザがそのイベント情報を使用してカレンダーイベントを作成又は更新することになったのか、などをより良好に判断することができる。

一部の実施形態において、提案されたカレンダーイベントは、図３４－５Ａ～図３４－５Ｂのデータアーキテクチャを考慮して検索可能であり得る。例えば、デバイスは、（例えば、ユーザがデバイス上のアプリケーションを介してカレンダーイベントを検索することによって）カレンダーイベントを求める要求を受信し（３４＿１１２４）、このカレンダーイベント要求に応答して、提案されたカレンダーイベントを検索することができる。

一部の実施形態において、デバイスは、カレンダーイベントの生成に応答して、提案されたカレンダーイベントをネットワーク経由でリモートデータベースに記憶するのを差し控えることができる（３４＿１１２６）。例えば、提案されたカレンダーイベントが提案状態３４＿５４０にある場合、デバイスは、ネットワーク経由で複数のクライアント上でカレンダーイベントを更新できるようにする更新又は同期サービス（例えば、デバイス上のアプリケーション）にカレンダーイベントをプッシュするのを差し控えることができる。

一部の実施形態において、デバイスは、提案されたカレンダーイベント（例えば、図３４－６Ｅ、「カレンダーに追加」３４＿６２６）を、複数のカレンダーイベントを含むデータベースに追加する要求を受信し（３４＿１１２８）、それに応答して、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーション（例えば、カレンダーイベントの状態を提案状態３４＿５４０から追加状態３４＿５５０に変更すること）をせずに、生成されたカレンダーイベントをデータベースに記憶することができる。提案されたカレンダーイベントをデータベースに追加する要求に応答して、デバイスは、生成されたカレンダーイベントを、例えば、更新又は同期サービスにプッシュすることによって、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーションをせずにネットワーク経由でリモートデータベースに記憶することができる（３４＿１１３０）。

一部の実施形態において、デバイスは、提案されたカレンダーイベントを拒否する要求（例えば、図３４－６Ｅ、「無視」３４＿６２８）を受信し（３４＿１１３２）、その拒否要求に応答して、そのイベント情報が今後のメッセージ内で識別されたことによってその提案されたカレンダーイベントが今後生成されることのないようにすることができる。これは、拒否されたイベントを拒否状態３４＿５６０で記憶することによって実装できるため、デバイスは、既に拒否された内容を知ることができる。

図３４－１２は、一部の実施形態に係る、メッセージを有する提案されたイベント情報を表示するための例示的なプロセスのフロー図を示す。このプロセスは、ディスプレイを備える電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｅ、メッセージ部分３４＿６２２内の電子メール）を受信し（３４＿１２０２）、受信したメッセージ内で、イベント情報（例えば、図３４－６Ｅ、「Ｄｉｎｎｅｒ」、「Ａｎｙ Ｓｕｓｈｉ Ｂａｒ」、「Ｆｒｉ，Ｍａｒｃｈ ７ｔｈ」、又は「９：５０ＰＭ」）を識別することができる（３４＿１２０４）。メッセージは電子メールであり得る（３４＿１２０６）。識別されたイベント情報は、日付及び時刻であり得る（３４＿１２０８）。

デバイスは、受信したメッセージに対応する第１のユーザインタフェース（例えば、図３４－６Ｅ）を表示することができる（３４＿１２１０）。第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分（例えば、図３４－６Ｅ、メッセージ部分３４＿６２２）と、識別されたイベント情報に対応する第１のユーザインタフェースオブジェクト（例えば、図３４－６Ｅ、「Ｄｉｎｎｅｒ」、「Ａｎｙ Ｓｕｓｈｉ Ｂａｒ」、「Ｆｒｉ，Ｍａｒｃｈ ７ｔｈ」、又は「９：５０ ＰＭ」）と、識別されたイベント情報と関連付けられた第２のユーザインタフェースオブジェクト（例えば、図３４－６Ｅ、「カレンダーに追加」３４＿６２６）と、を含む第２の部分（例えば、図３４－６Ｅ、提案部分３４＿６２０）と、を含んでも良く、第２のユーザインタフェースオブジェクトは、選択されると、電子デバイスに、識別されたカレンダー情報を、複数のカレンダーイベントを含むデータベースに追加させる（例えば、そのイベント情報をカレンダーイベントとして記憶する）。第２の部分は、識別されたイベント情報と関連付けられた第３のユーザインタフェースオブジェクト（例えば、図３４－６Ｅ、「無視」３４＿６２８）を含み得る（３４＿１２１２）。このユーザインタフェースオブジェクトは、選択されると、電子デバイスに第２のユーザインタフェースオブジェクトの表示を停止させる。

図３４－１３は、一部の実施形態に係る、複数の提案された連絡先又はイベント情報をメッセージとともに表示するための例示的なプロセスのフロー図を示す。

このプロセスは、ディスプレイを備える電子デバイス（例えば、デバイス３４＿５００）で実行することができる。

電子デバイスは、メッセージ（例えば、図３４－６Ｆ、メッセージ部分３４＿６３２内の電子メール）を受信し（３４＿１３０２）、受信したメッセージ内で、連絡先又はイベント情報の複数のインスタンス（例えば、図３４－６Ｆ、添付の旅程における「２件のイベント、１件の連絡先」）を識別することができる（３４＿１３０４）。

デバイスは、受信したメッセージに対応する第１のユーザインタフェース（例えば、図３４－６Ｆ）を表示することができる（３４＿１３０６）。第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分（例えば、図３４－６Ｆ、メッセージ部分３４＿６３２）と、選択されると、識別された連絡先又はイベント情報の複数のインスタンスのリストを含む第２のユーザインタフェース（図３４－６Ｇ）を電子デバイスに表示させる第２位の部分（例えば、図３４－６Ｆ、提案部分３４＿６３０）と、を含み得る。

一部の実施形態において、デバイスは、第１のユーザインタフェースの第２の部分の選択に対応する入力を検出する（３４＿１３０８）ことができ、検出に応答して、識別された連絡先又はイベント情報の複数のインスタンスのリストと、識別された連絡先又はイベント情報の複数のインスタンスの各々について、第１のユーザインタフェースオブジェクト（例えば、図３４－６Ｇ、「カレンダーに追加」又は「連絡先に追加」）であって、選択されると、電子デバイスに、識別された情報をデータベースに追加させる（例えば、イベント情報をカレンダーイベントとして、又は連絡先情報を連絡先として記憶させる）第１のユーザインタフェースオブジェクトを含む第２のユーザインタフェースと、を表示することができる。第２のユーザインタフェースは、識別された連絡先又はイベント情報の複数のインスタンスの各々に対し、第２のユーザインタフェースオブジェクト（例えば、図３４－６Ｇ、「無視」）であって、選択されると、電子デバイスに、第１のユーザインタフェースオブジェクトを表示することを停止させる第２のユーザインタフェースオブジェクトを含み得る（３４＿１３１０）。第２のユーザインタフェースは、第３のユーザインタフェースオブジェクト（例えば、図３４－６Ｇ、「全てを追加」３４＿６３４）であって、選択されると、電子デバイスに、識別された連絡先又はイベント情報の複数のインスタンスのまとまり（例えば、カレンダーイベント又は連絡先）の各々をデータベースに追加させる第３のユーザインタフェースオブジェクトを含み得る（３４＿１３１２）。第２のユーザインタフェースを表示することにより、第１のユーザインタフェースを表示することを停止することができる（３４＿１３１４）。

図３４－７Ａ～図３４－１３における動作を記載した特定の順序は例示的なものであり、説明された順序が、動作を実行できる唯一の順序であることを示すことを意図するものではないということを理解されたい。当業者であれば、このセクションで説明される動作の順序を変更する様々な方法を認識するであろう。簡潔にするために、これらの詳細は、ここでは繰り返さない。加えて、プロセス３４＿７００～３４＿１３００（図３４－７～図３４－１３）の態様を互いに組み込めるという点にも留意されたい。

上述の情報処理プロセスでの動作は、汎用プロセッサ又は特定用途向けチップなど、情報処理装置内の１つ以上の機能モジュールを実行することによって実施することができる。これらのモジュール、これらのモジュールの組み合わせ、及び／又は、それらの（例えば、図１Ａ、図１Ｂ、及び図３に関して上述されたような）一般的なハードウェアとの組み合わせは、全て本発明の保護の範囲内に含まれる。

図３４－１４は、一部の実施例において上述の機能を実行する電子デバイス３４＿１４００の例示的な機能ブロックを示す。図３４－１４に示すように、電子デバイス３４＿１４００は、グラフィカルオブジェクトを表示するように構成されたディスプレイユニット３４＿１４０２と、ユーザのジェスチャを受信するように構成されたタッチ感知面ユニット３４＿１４０４と、外部電子デバイスを検出し、これと通信するように構成された１つ以上のＲＦユニット３４＿１４０６と、ディスプレイユニット３４＿１４０２、タッチ感知面ユニット３４＿１４０４、及びＲＦユニット３４＿１４０６に連結された処理ユニット３４＿１４０８と、を備える。

一部の実施形態において、処理ユニット３４＿１４０８は、１つ以上のアプリケーション３４＿１４１２を実行するオペレーティングシステム３４＿１４１０をサポートするように構成される。一部の実施形態において、処理ユニット３４＿１４０８は、無線通信範囲内にある外部デバイスであるＲＦユニット３４＿１４０６からデータを受信し、タッチ感知面ユニット３４＿１４０４上にグラフィカルユーザインタフェースアフォーダンスを表示し、表示されたアフォーダンス上で接触を検出したことに応答して、外部デバイス上で実行しているアプリケーションに対応するデバイス３４＿１４００上でアプリケーションを起動するように構成されている。

デバイス３４＿１４００の機能ブロックは、説明された様々な実施例の原理を実行するために、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアとの組み合わせによって任意選択的に実施される。当業者であれば、図３４－１４に記載された機能ブロックが、説明されたさまざまな実施例の原理を実現するために、任意選択的に、組み合わされるか、又はサブブロックに分けられるものと理解する。したがって、このセクションにおける説明は、このセクションで説明されている機能ブロックの任意の可能な組み合わせ若しくは分離、又は更なる定義を任意選択的にサポートする。

図３４－１５は、一部の実施例において上述の機能を実行する電子デバイス３４＿１５００の例示的な機能ブロックを示す。図３４－１４に示すとおり、電子デバイス３４＿１５００は、グラフィカルオブジェクトを表示するように構成されたディスプレイユニット３４＿１４０２と、ユーザのジェスチャを受信するように構成されたタッチ感知面ユニット３４＿１５０４と、外部電子デバイスを検出し通信するように構成された１つ以上のＲＦユニット３４＿１５０６と、ディスプレイユニット３４＿１５０２、タッチ感知面ユニット３４＿１５０４、及びＲＦユニット３４＿１５０６に連結された処理ユニット３４＿１５０８と、を備える。

一部の実施形態において、処理ユニット３４＿１５０８は、上述の様々な特徴を実行するためにユニット３４＿１５１０～１５２０のうちの１つ以上をサポートするように構成される。例えば、受信ユニット３４＿１５１０は、上述の（例えば、メッセージを受信する）受信機能のうちの１つ以上を実行するように構成される。識別ユニット３４＿１５１２は、上述した識別機能（例えば、受信メッセージ内で、エンティティ及びエンティティと関連付けられた連絡先情報を識別すること、受信したメッセージ内でイベント情報を識別すること、又は受信したメッセージ内で、連絡先情報又はイベント情報の複数のインスタンスを識別すること）、のうちの１つ以上を実行するように構成される。判定ユニット３４＿１５１４は、上述した判定機能（例えば、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在しないと判断すること、及び識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在するということと、その連絡先が、連絡先情報の識別された項目を含まないということと、を判定すること）のうちの１つ以上を実行するように構成される。生成ユニット３４＿１５１６は、上述した生成ステップ（例えば、判定に応答して、エンティティと関連付けられた連絡先を生成すること、識別された連絡先情報が提案された連絡先情報であるというインジケーションを生成すること、及び識別されたイベント情報と関連付けられたイベントを生成すること）、のうちの１つ以上を実行するように構成される。更新ユニット３４＿１５１８は、上述した更新ステップ（例えば、判定したことに応答して、連絡先情報項目と、連絡先情報項目が提案された連絡先情報項目であるというインジケーションと、を含むように連絡先を更新すること）のうちの１つ以上を実行するように構成される。表示ユニット３４＿１５２０は、上述した表示ステップ（例えば、ディスプレイユニット３４＿１５０２上などに、エンティティ又は受信したメッセージと関連付けられた連絡先に対応する第１のユーザインタフェースを表示すること）のうちの１つ以上を実行するように構成される。

デバイス３４＿１５００の機能ブロックは、説明される様々な実施例の原理を実行するために、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアとの組み合わせによって任意選択的に実施される。当業者であれば、図３４－１５に記載された機能ブロックが、説明されたさまざまな実施例の原理を実現するために、任意選択的に、組み合わされるか、又はサブブロックに分離されるものと理解する。したがって、このセクションにおける説明は、このセクションで説明されている機能ブロックの任意の可能な組み合わせ若しくは分離、又は更なる定義を任意選択的にサポートする。
構造化された提案のための方法、デバイスシステム、コンピュータ可読媒体例

一態様においては、電子デバイスが、ユーザのメッセージに基づいてユーザに連絡先及びカレンダーイベントを提案する。このデバイスは、ユーザのメッセージを分析して連絡先及びイベント情報を把握し、この情報に基づいて、ユーザに対して提案される連絡先及びカレンダーイベントを自動的に生成又は更新することができる。提案された連絡先及びカレンダーイベントは、まるでユーザが手動で入力したかのように検索可能であり、ユーザは、提案された連絡先及びカレンダーイベントを追加又は無視することを選択できる。

一部の実装形態においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別することと、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在しないと判断することと、その判断に応答して、そのエンティティと関連付けられた連絡先を生成することと、を含み、生成された連絡先が、その連絡先情報と、生成された連絡先が提案された連絡先であるというインジケーションと、を含む。

一部の実装形態において、識別されたエンティティは名前を含み、識別された連絡先情報は、電話番号、住所、ビジネス又はソーシャルネットワーキングハンドルを含む。一部の実装形態において、識別することは、メッセージの署名ブロックを識別することと、識別された署名ブロックを分析して、そのエンティティ及び連絡先情報を把握することと、を含む。一部の実装形態において、メッセージは電子メールを含み、署名ブロックは電子メール署名を含む。いくつかの実装形態において、電子メールは、電子メールスレッド内に１つ以上の過去の電子メールを含み、電子メール署名を識別することは、電子メールスレッド内の１つ以上の過去の電子メールを分析することを含む。一部の実装形態において、識別することは、事前定義された句の集合に基づいて１つ以上の句をメッセージ内で識別することと、１つ以上の識別された句を分析して、そのエンティティ及び連絡先情報を把握することと、含む。一部の実装形態において、この方法は、ネットワーク経由で既定の句の集合を更新することを含む。一部の実装形態において、この方法は、提案された連絡先を拒否する要求の結果として、既定の句のうちの１つ以上をダウングレードすることを含む。一部の実装形態において、この方法は、データベース内の連絡先情報を電子デバイス上の連絡先情報と関連付けられた言葉と相関させることによって既定の句のうちの１つ以上を生成することを含む。一部の実装形態において、この方法は、連絡先を求める要求を受信することと、連絡先を求める要求に応答して、提案された連絡先を検索することと、を含む。一部の実装形態において、この方法は、連絡先の生成に応答して、提案された連絡先をネットワーク経由でリモートデータベースに記憶するのを差し控えることを含む。一部の実装形態において、この方法は、提案された連絡先をデータベースに追加する要求を受信することと、提案された連絡先をデータベースに追加する要求に応答して、生成された連絡先が提案された連絡先であるというインジケーションなしで、生成された連絡先をデータベースに記憶することと、を含む。一部の実装形態において、この方法は、提案された連絡先をデータベースに追加する要求に応答して、生成された連絡先が提案された連絡先であるというインジケーションなしで、生成された連絡先をネットワーク経由でリモートデータベースに記憶することを含む。一部の実装形態において、この方法は、提案された連絡先を拒否する要求を受信することと、提案された連絡先を拒否する要求に応答して、提案された連絡先を拒否することで、そのエンティティ及び連絡先情報が今後のメッセージ内で識別された結果としてその提案された連絡先が今後生成されないようにすることと、を含む。

一部の実装形態においては、提案された連絡先を拒否する要求を受信するための手段と、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別するための手段と、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在しないと判断するための手段と、その判定に応答して、そのエンティティと関連付けられた連絡先を生成するための手段と、を備え、生成された連絡先が、その連絡先情報と、生成された連絡先が提案された連絡先であるというインジケーションと、を含む。

別の態様においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報項目を識別することと、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在し、その連絡先が識別された連絡先情報項目を含まないと判断することと、その判断に応答して、その連絡先を更新し、その連絡先情報項目と、その連絡先情報項目が提案された連絡先情報項目であるというインジケーションと、を含めることと、を含む。

一部の実装形態において、識別されたエンティティは名前を含み、識別された連絡先情報項目は、電話番号、住所、ビジネス又はソーシャルネットワーキングハンドルを含む。一部の実装形態において、識別することは、メッセージの署名ブロックを識別することと、識別された署名ブロックを分析して、そのエンティティ及び連絡先情報項目を把握することと、を含む。一部の実装形態において、メッセージは電子メールを含み、署名ブロックは電子メール署名を含む。いくつかの実装形態において、電子メールは、電子メールスレッド内に１つ以上の過去の電子メールを含み、電子メール署名を識別することは、電子メールスレッド内の１つ以上の過去の電子メールを分析することを含む。一部の実装形態において、識別することは、既定の句の集合に基づいて１つ以上の句をメッセージ内で識別することと、１つ以上の識別された句を分析して、そのエンティティ及び連絡先情報項目を把握することと、含む。一部の実装形態において、この方法は、ネットワーク経由で既定の句の集合を更新することを含む。一部の実装形態において、この方法は、提案された連絡先情報項目を拒否する要求の結果として既定の句のうちの１つ以上をダウングレードすることを含む。一部の実装形態において、この方法は、データベース内の連絡先情報を電子デバイス上の連絡先情報と関連付けられた言葉と相関させることによって既定の句のうちの１つ以上を生成することを含む。一部の実装形態において、この方法は、連絡先を求める要求を受信することと、連絡先を求める要求に応答して、提案された連絡先情報項目を検索することと、を含む。一部の実装形態において、この方法は、連絡先の更新に応答して、提案された連絡先情報項目をネットワーク経由でリモートデータベースに記憶するのを差し控えることを含む。一部の実装形態において、この方法は、提案された連絡先情報項目をデータベースに追加する要求を受信することと、提案された連絡先情報項目をデータベースに追加する要求に応答して、更新された連絡先情報項目が提案された連絡先情報項目であるというインジケーションなしで、更新された連絡先情報項目をデータベースに記憶することと、を含む。一部の実装形態において、この方法は、提案された連絡先情報項目をデータベースに追加する要求に応答して、更新された連絡先情報項目が提案された連絡先であるというインジケーションなしで、更新された連絡先情報項目をネットワーク経由でリモートデータベースに記憶することを含む。一部の実装形態において、この方法は、提案された連絡先情報項目を拒否する要求を受信することと、その提案された連絡先情報項目を拒否する要求に応答して、そのエンティティ及び連絡先情報項目が今後のメッセージ内で識別された結果として、連絡先が提案された連絡先情報項目で今後更新されないようにすることと、を含む。

一部の実装形態においては、メッセージを受信するための手段と、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報項目を識別するための手段と、識別されたエンティティと関連付けられた連絡先がデータベース内の複数の連絡先の中に存在し、その連絡先が識別された連絡先情報項目を含まないと判断するための手段と、その判断に応答して、その連絡先を更新し、その連絡先情報項目と、その連絡先情報項目が提案された連絡先情報項目であるというインジケーションと、を含めるための手段と、を備えるシステムが提供される。

もう１つの態様においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別することと、識別された連絡先情報が提案された連絡先情報であるというインジケーションを生成することと、そのエンティティと関連付けられた連絡先に対応する第１のユーザインタフェースであって、生成されたインジケーションに基づき、識別された連絡先情報が提案された連絡先情報であることを示す第１のユーザインタフェースオブジェクトを含む第１のユーザインタフェースを表示することと、を含む。一部の実装形態において、この方法は、提案された連絡先情報の選択に対応する入力がアプリケーションを呼び出してエンティティに連絡するのを防ぐことを含む。一部の実装形態において、この方法は、第１のユーザインタフェース内の提案された連絡先情報の選択に対応する入力を検出することと、第１のユーザインタフェース内のその提案された連絡先情報の選択に対応するその入力の検出に応答して、識別された連絡先情報と関連付けられた第２のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別された連絡先情報をデータベースに追加させる第２のユーザインタフェースオブジェクトを含む第２のユーザインタフェースを表示することと、を含む。一部の実装形態において、第２のユーザインタフェースは、識別された連絡先情報と関連付けられた第３のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに第２のユーザインタフェースオブジェクトの表示を停止させる第３のユーザインタフェースオブジェクトを含む。一部の実装形態においては、第２のユーザインタフェースを表示すると、第１のユーザインタフェースの表示が停止する。一部の実装形態において、第２のユーザインタフェースは、メッセージの少なくとも一部分を表示する。一部の実装形態において、この方法は、表示されたメッセージの選択に対応する入力を検出することと、表示されたメッセージの選択に対応する入力の検出に応答して、メッセージを開くためのアプリケーションを呼び出すことと、を含む。一部の実装形態において、メッセージは電子メールを含み、アプリケーションは電子メールアプリケーションを含む。いくつかの実装形態において、この方法は、第２のユーザインタフェース内の提案された連絡先情報の選択に対応する入力を検出することと、その第２のユーザインタフェース内のその提案された連絡先情報の選択に対応する入力の検出に応答して、識別された連絡先情報を用いてのアプリケーションを呼び出し、そのエンティティに連絡すること、を含む。一部の実装形態において、この方法は、第２のユーザインタフェース内の提案された連絡先情報の選択に対応する入力の検出に応答して、識別された連絡先情報をデータベースに追加することを含む。一部の実装形態において、この方法は、識別された連絡先情報をデータベースに追加したことに応答して、第１のユーザインタフェースオブジェクトの表示を停止することを含む。

一部の実装形態においては、メッセージを受信するための手段と、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別するための手段と、識別された連絡先情報が提案された連絡先情報であるというインジケーションを生成するための手段と、そのエンティティと関連付けられた連絡先に対応する第１のユーザインタフェースであって、識別された連絡先情報が提案された連絡先情報であることを示す、生成されたインジケーションに基づき、第１のユーザインタフェースオブジェクトを含む第１のユーザインタフェースを表示するための手段と、を備えるシステムが提供される。

更なるもう１つの態様においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別することと、受信したメッセージに対応する第１のユーザインタフェースを表示することと、を含み、第１のユーザインタフェースは、電子デバイスによって受信されたメッセージのコンテンツを含む第１の部分と、識別されたエンティティに対応する第１のユーザインタフェースオブジェクトと、識別された連絡先情報に対応する第２のユーザインタフェースオブジェクトと、識別された連絡先情報と関連付けられた第３のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別された連絡先情報をデータベースに追加させる第３のユーザインタフェースオブジェクトと、を含む第２の部分と、を含む。一部の実装形態において、第２の部分は、識別された連絡先情報と関連付けられた第４のユーザインタフェースオブジェクトであって、選択されると、デバイスに第３のユーザインタフェースオブジェクトの表示を停止させる第４のユーザインタフェースオブジェクトを含む。一部の実装形態において、メッセージは電子メールを含む。一部の実装形態において、識別されたエンティティは名前を含み、識別された連絡先情報は、電話番号、住所、ビジネス又はソーシャルネットワーキングハンドルを含む。

一部の実装形態においては、メッセージを受信するための手段と、受信したメッセージ内で、エンティティ及びそのエンティティと関連付けられた連絡先情報を識別するための手段と、受信したメッセージに対応する第１のユーザインタフェースを表示するための手段と、を備え、第１のユーザインタフェースが、電子デバイスによって受信されたメッセージのコンテンツを含む第１の部分と、識別されたエンティティに対応する第１のユーザインタフェースオブジェクトと、識別された連絡先情報に対応する第２のユーザインタフェースオブジェクトと、識別された連絡先情報と関連付けられた第３のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別された連絡先情報をデータベースに追加させる第３のユーザインタフェースオブジェクトと、を含む第２の部分と、を含むるシステムが提供される。

更なるもう１つの態様においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内でイベント情報を識別することと、識別されたイベント情報と関連付けられたカレンダーイベントを生成することと、を含み、生成されたカレンダーイベントは、そのイベント情報と、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーションと、を含む。一部の実装形態において、識別されたイベント情報は、日付と時刻とを含む。一部の実装形態において、識別することは、メッセージ内のコンテンツの形式を識別することと、そのメッセージ内のそのコンテンツの形式でイベント情報を認識するように構成された定義済みのテンプレートの集合からテンプレートを識別することと、識別されたテンプレートを用いてコンテンツを分析してイベント情報を把握することと、を含む。一部の実装形態において、メッセージは電子メールを含み、コンテンツは予約を含む。一部の実装形態において、この方法は、ネットワーク経由で定義済みのテンプレートの集合を更新することを含む。一部の実装形態において、識別することは、日時に対する定義済みの参照の集合に基づいて、日時への１つ以上の参照をメッセージ内で識別することと、日時に対する１つ以上の識別された参照を分析してイベント情報を把握することと、を含む。一部の実装形態において、この方法は、日時に対する定義済みの参照の集合をネットワーク経由で更新することを含む。一部の実装形態において、この方法は、提案されたカレンダーイベントを拒否する要求の結果として、日時に対する定義済みの参照のうちの１つ以上をダウングレードすることを含む。一部の実装形態において、この方法は、複数のカレンダーイベントを含むデータベース内のイベント情報を、電子デバイス上のイベント情報と関連付けられた言葉と相関させることにより、日時に対する定義済みの参照のうちの１つ以上を生成することを含む。一部の実装形態において、この方法は、カレンダーイベントを求める要求を受信することと、カレンダーイベントを求める要求に応答して、提案されたカレンダーイベントを検索することと、を含む。一部の実装形態において、この方法は、カレンダーイベントの生成に応答して、提案されたカレンダーイベントをネットワーク経由でリモートデータベースに記憶するのを差し控えることを含む。一部の実装形態において、この方法は、複数のカレンダーイベントを含むデータベースに提案されたカレンダーイベントを追加する要求を受信することと、データベースに提案されたカレンダーイベントを追加する要求に応答して、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーションなしで、生成されたカレンダーイベントをデータベースに記憶することとを含む。一部の実装形態において、この方法は、提案されたカレンダーイベントをデータベースに追加する要求に応答して、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーションなしで、生成されたカレンダーイベントをネットワーク経由でリモートデータベースに記憶することを含む。一部の実装形態において、この方法は、提案されたカレンダーイベントを拒否する要求を受信することと、提案されたカレンダーイベントを拒否する要求に応答して、そのイベント情報が今後のメッセージ内で識別されたことによってその提案されたカレンダーイベントが今後生成されることのないようにすることと、を含む。

一部の実装形態においては、メッセージを受信するための手段と、受信したメッセージ内でイベント情報を識別するための手段と、識別されたイベント情報と関連付けられたカレンダーイベントを生成するための手段と、を備えるシステムであって、生成されたカレンダーイベントが、そのイベント情報と、生成されたカレンダーイベントが提案されたカレンダーイベントであるというインジケーションと、を含むシステムが提供される。

更なる追加態様においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内でイベント情報を識別することと、受信されたメッセージに対応する第１のユーザインタフェースを表示することとを含み、第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、識別されたイベント情報に対応する第１のユーザインタフェースオブジェクトと、識別されたイベント情報と関連付けられた第２のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別されたイベント情報を複数のカレンダーイベントを含むデータベースに追加させる第２のユーザインタフェースオブジェクトと、を含む第２の部分と、を含む。一部の実装形態において、第２の部分は、識別されたイベント情報と関連付けられた第３のユーザインタフェースオブジェクトであって、選択されると、デバイスに第２のユーザインタフェースオブジェクトの表示を停止させる第３のユーザインタフェースオブジェクトを含む。一部の実装形態において、メッセージは電子メールを含む。一部の実装形態において、識別されたイベント情報は、日付と時刻とを含む。一部の実装形態においては、メッセージを受信するための手段と、受信したメッセージ内でイベント情報を識別するための手段と、受信したメッセージに対応する第１のユーザインタフェースを表示するための手段と、を備えるシステムであって、第１のユーザインタフェースが、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、識別されたイベント情報に対応する第１のユーザインタフェースオブジェクトと、識別されたイベント情報と関連付けられた第２のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別されたイベント情報を複数のカレンダーイベントを含むデータベースに追加させる第２のユーザインタフェースオブジェクトと、を含む第２の部分と、を含むシステムが提供される。

更なるもう１つの追加態様においては、電子デバイス（例えば、図１Ｅに示す構成のいずれかに従って実装される図１Ａのデバイス１００）で実行される方法が提供される。この方法は、メッセージを受信することと、受信したメッセージ内で、連絡先情報又はイベント情報複数のインスタンスを識別することと、受信したメッセージに対応する第１のユーザインタフェースを表示することと、を含み、第１のユーザインタフェースは、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、選択されると、電子デバイスに、識別された連絡先又はイベント情報の複数のインスタンスを含む第２のユーザインタフェースを表示させる第２の部分と、を備える。一部の実装形態において、この方法は、第１のユーザインタフェースの第２の部分の選択に対応する入力を検出することと、第１のユーザインタフェースの第２の部分の選択に対応する入力の検出に応答して、識別された連絡先又はイベント情報の複数のインスタンスのリストと、識別された連絡先又はイベント情報の複数のインスタンスの各々に対する第１のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別された情報をデータベースに追加させる第１のユーザインタフェースオブジェクトと、を含む第２のユーザインタフェースを表示することと、を含む。一部の実装形態において、第２のユーザインタフェースは、識別された連絡先又はイベント情報の複数のインスタンスの各々に対する第２のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、第１のユーザインタフェースオブジェクトの表示を停止させる第２のユーザインタフェースオブジェクトを含む。一部の実装形態において、第２のユーザインタフェースは、第３のユーザインタフェースオブジェクトであって、選択されると、電子デバイスに、識別された連絡先又はイベント情報の複数のインスタンスのまとまりの各々をデータベースに追加させる第３のユーザインタフェースオブジェクトを含む。一部の実装形態においては、第２のユーザインタフェースを表示すると、第１のユーザインタフェースの表示が停止する。

一部の実装形態においては、メッセージを受信するための手段と、受信したメッセージ内で、連絡先情報又はイベント情報複数のインスタンスを識別するための手段と、受信したメッセージに対応する第１のユーザインタフェースを表示するための手段と、を備え、第１のユーザインタフェースが、電子デバイスによって受信されたメッセージの内容を含む第１の部分と、選択されると、電子デバイスに、識別された連絡先又はイベント情報の複数のインスタンスを含む第２のユーザインタフェースを表示させる第２の部分と、を含む、システムが提供される。

一部の実装形態においては、１つ以上のプロセッサと、メモリと、１つ以上のプログラムと、を備える電子デバイスであって、１つ以上のプログラムが、メモリ内に記憶され、１つ以上のプロセッサによって実行されるよう構成されており、１つ以上のプログラムが、このセクションにおける上述の方法のうちのいずれかを実行するための命令を含む、電子デバイス。一部の実装形態においては、１つ以上のプログラムを記憶するコンピュータ可読記憶媒体であって、電子デバイスによって実行されると、このセクションで上述した方法のいずれかをデバイスに実行させる命令をこの１つ以上のプログラムが含む、コンピュータ可読記憶媒体が提供される。一部の実装形態においては、このセクションで説明した方法のいずれかを実行するための手段を備えるシステムが提供される。
セクション５：データスパーシティのコンテキストにおける複合ユーザパターンを学習する生成モデルの決定木のセグメント化

本セクションにおける「データスパーシティのコンテキストにおける複合ユーザパターンを学習する生成モデルの決定木のセグメント化」という題材は、一部の実施形態により、データスパーシティのコンテキストにおける複合ユーザパターンを学習する生成モデルの決定木のセグメント化を記載し、本セクションに提供される開示を補足する情報を提供する。例えば、本セクションの部分は、本セクションにおいて提供される開示を補足するデバイス上のイベントに応答するアプリケーションを提示する方法、例えば、図９Ｂ～図９Ｃの予測部分９３０内のアプリケーション及びディープリンクに対応するアフォーダンスをポピュレートすることに関連するものを記載する。一部の実施形態では、本セクションに記載される予測モデルは、予測及びユーザへの表示のための適切なアプリケーションの識別を支援するのに用いられる（すなわち、これらの予測モデルは、方法６００、８００、１０００及び１２００と併せて用いられる）。
データスパーシティのコンテキストにおける複合ユーザパターンを学習する生成モデルの決定木のセグメント化についての概要

実施形態は、イベントに基づいてコンピューティングデバイスのユーザに１つ以上のアプリケーションを提案するシステム、方法、及び装置を提供することができる。コンピューティングデバイスの例は、電話機、タブレット、ラップトップコンピュータ、又はデスクトップコンピュータである。例示のイベントとしては、アクセサリデバイスへの接続、及び（例えば、オフ又はスリープから呼び起こすための）電力状態の変更が挙げられる。

予測モデルは、特定のイベントに対応することができる。提案されたアプリケーションは、コンピューティングデバイスの１つ以上のプロパティを用いて判定され得る。例えば、特定のサブモデルは、イベントが発生した後のユーザ相互作用に関する履歴データのサブセットであって、デバイスが１つ以上のプロパティを有する場合に収集される履歴データのサブセットから生成され得る（例えば、特定の時間帯のプロパティと共に、人の車に接続するというイベント後にどのアプリケーションが選択されたというユーザ相互作用）。サブモデルの木は、コンピューティングデバイスのプロパティの異なるコンテキストに対応して判定されてもよい。また、履歴データのサブセット内の正確な予測を提供するサブモデル内の信頼水準及び親モデルに対する履歴データの分布内の情報利得（エントロピーの低下）など、様々な基準がサブモデルをいつ生成すべきかを判定するのに使用され得る。

他の実施形態は、本セクションに記載の方法に関連するシステム、ポータブル家庭用デバイス及びコンピュータ可読媒体を対象とする。

以下の詳細な説明及び添付の図面を参照することにより、本セクションの実施形態の性質及び利点の理解をより深めることができる。
データスパーシティのコンテキストにおける複合ユーザパターンを学習する生成モデルの決定木のセグメント化についての詳細な説明

実施形態は、アプリケーションをデバイスのユーザに提案するカスタマイズされ、かつパーソナライズされたエクスペリエンスを提供でき、それによってデバイスの使用を容易にするものである。ユーザは、特定のイベント後に発生するユーザデバイスとの広範な相互作用のセット（例えば、イベントと関連してどのアプリケーションが起動され、又は動作するか）を有することができる。コンピューティングデバイスの例は、電話機、タブレット、ラップトップ、又はデスクトップコンピュータである。例示イベントとしては、アクセサリデバイスへの接続、及び（例えば、オフ又はスリープから呼び起こすための）電力状態の変更が挙げられる。

履歴データ内の各データポイントは、特定のコンテキストに対応する（例えばデバイスの１つ以上のプロパティに対応する）ことができ、特定のコンテキストに対する一層多くのデータが時間の経過と共に得られている。特定のイベントに対する履歴データは、ユーザにアプリケーションを提案するのに使用され得る。様々なユーザが様々な履歴データを有するにつれて、実施形態は、パーソナライズされたエクスペリエンスを提供することができる。

正確にパーソナライズされたエクスペリエンスを提供するには、各種実施形態は、提案を提供せずに単にトレーニングされた、又は種々のコンテキストに対するアプリケーション（単数又は複数）の同一のセットを提案する広範なモデルで始めることができる。十分な履歴データを用いて、広範なモデルは、サブモデルに、例えば、サブモデルの決定木としてセグメント化でき、各サブモデルは履歴データの異なるサブセットに対応するものである。次に、イベントが発生すると、デバイスの現在のコンテキストに対応する提案アプリケーションを提供するために特定のサブモデルが選択され得る。例えば、履歴データのサブセット内の正確な予測を提供するサブモデル内の信頼水準及び親モデルに対する履歴データの分布内の情報利得（エントロピーの低下）など、様々な基準がサブモデルをいつ生成すべきかを判定するのに使用され得る。

一部の実施形態では、「信頼水準」は、モデルが履歴データに基づいて正確な予測を行うことができる（すなわち、予測されたアプリケーション（単数又は複数）のうち少なくとも１つがイベント後に選択された）という確率に相当する。信頼水準の例は、正確な予測が行われたイベントのパーセンテージである。別の例では、正確な予測、及び不正確な予測の数から生成された確率分布（例えば、ｂｅｔａ分布）の累積分布関数（ＣＤＦ）が使用される。ＣＤＦは、確率分布を積分することによって計算することができる。様々な実装形態では、信頼水準は、入力値を過ぎたＣＤＦの増加量（例えば、０～１の間で、１は正確な予測に対応する）、又は入力値を過ぎた特定のＣＤＦを提供する入力値とすることができる。アプリケーションが選択されるという確率は、閾値確率となるように要求される場合があり、それは信頼閾値を超える信頼水準を有するモデルのための必然的結果である。信頼水準は、エントロピーの測定値に反比例する場合があるので、親モデルからサブモデルへの信頼水準の増加は、エントロピーの減少に相当する場合がある。

したがって、一部の実施形態は、ユーザ推薦のコンテキストでユーザの履歴データをいつ、どのようにセグメント化するかを決定することができる。例えば、ユーザアクティビティの期間を収集した後、実施形態は、予想されるセグメント化候補（例えば、ロケーション、曜日など）のリストを蓄積することができる。実施形態は、全データセットのモデルをトレーニングし、データセット及びモデルの合わせた分布内の信頼度のメトリックを計算することもできる。モデルのセットは、セグメント化されたデータセット（サブセット）のそれぞれに対する一つにトレーニングでき、その後、データモデル分布のそれぞれの信頼度を測定することができる。すべてのデータモデル分布の信頼度が許容される場合、実施形態はセグメント化（分割）を行い、更なるセグメント化のためにセグメント化された空間を再帰的に検査することができる。

このようにして、一部の実施形態は、セグメント化と一般化との間のトレードオフを探査するよう推論を使用でき、より別個の、複合パターンを有するユーザに対してより複合モデルを、よりノイジー（noisier）でより簡潔なパターンを有するユーザに対して簡潔で一般的なモデルを生成することができる。また、一部の実施形態は、潜在的な候補モデル間の発散分布の発見に基づいて確率的モデルの木を生成することができる。
Ｉ．イベントに基づいたアプリケーションの提案

実施形態は、いくつかの所定のイベント（トリガーイベントとも呼ばれる）に限定され得る、イベントに基づいてアプリケーションを提案することができる。例えば、音楽アプリケーションは、ヘッドホンがヘッドホンジャックに挿入されたときに提案され得る。一部の実施形態では、コンテキスト情報は、ユーザに提案するアプリケーションを識別するためにイベントと併せて使用され得る。一例として、ヘッドホンのセットがヘッドホンジャックに挿入されるとき、ロケーションに関連するコンテキスト情報を使用することができる。例えば、デバイスがジムにある場合、ヘッドホンがヘッドホンジャックに挿入されるとき、アプリケーションＡを提案することができる。あるいは、デバイスが自宅にある場合、ヘッドホンがヘッドホンジャックに挿入されるとき、アプリケーションＢを提案することができる。したがって、特定のコンテキスト下で使用されそうなアプリケーションを、ちょうどよい時刻に提案できるので、ユーザエクスペリエンスを向上させることができる。

一部の実施形態では、「コンテキスト情報」はまとめて、デバイスのコンテキストを規定するのに使用され得る任意のデータを指すものである。所与のコンテキストに対するコンテキスト情報は、それぞれデバイスの異なるプロパティに対応する、１つ以上のコンテキストデータを含むことができる。可能性のあるプロパティは、時間カテゴリ又はロケーションカテゴリなどの異なるカテゴリに属する場合がある。コンテキストデータは、モデル（又はサブモデル）の特徴として使用され、モデルをトレーニングするのに用いられるデータは、同じカテゴリの異なるプロパティを含むことができる。特定のコンテキストは、デバイスのプロパティの特定の組み合わせ、あるいはたった一つのプロパティに対応することができる。

図３５－１は、本発明の実施形態に係る、検出されたイベントに基づいてアプリケーションを提案するための方法３５＿１００のフローチャートである。方法３５＿１００を、モバイルデバイス（例えば、電話機、タブレット）又は非モバイルデバイスによって実行することができ、またその方法は、デバイスの１つ以上のユーザインタフェースを利用することができる。

一部の実施形態では、「ユーザインタフェース」は、ユーザがデバイスと相互作用するための任意のインタフェースに対応する。アプリケーション用のユーザインタフェースにより、ユーザはアプリケーションと相互作用することができる。ユーザインタフェースは、アプリケーションが動作している場合、アプリケーションのインタフェースとすることができる。別の実施例としては、ユーザインタフェースは、ユーザが選択するアプリケーションの低減されたセットを提供するシステムインタフェースとすることができ、それによってユーザがそのアプリケーションを使用するのを容易にすることができる。

ブロック３５＿１１０では、イベントが検出される。一部の実施形態では、イベントがアプリケーションを提案するトリガーイベントであるかどうかを判定することができる。一部の実装形態では、提案されたアプリケーションの判定は、特定の所定のイベント（例えば、トリガーイベント）に対してのみ行われる。他の実装形態では、提案されたアプリケーションの判定は、イベントの動的リストに対して行うことができ、それはデバイス上のアプリケーションとの履歴ユーザ相互作用に基づいて更新され得る。

一部の実施形態では、トリガーイベントは、デバイスの固有動作に相関する可能性が十分あるものとして識別され得る。トリガーイベントであるイベントのリストはデバイスに記憶され得る。かかるイベントは既定のリストとすることができ、オペレーティングシステムの一部として維持され得、ユーザによって構成変更できてもよいし、構成変更できなくてもよい。

トリガーイベントは、ユーザ及び／又は外部デバイスに誘導されたイベントとすることができる。例えば、トリガーイベントは、アクセサリデバイスがモバイルデバイスに接続された場合とすることができる。例としては、ヘッドホンをヘッドホンジャックに挿入すること、Ｂｌｕｅｔｏｏｔｈ接続を行うこと、デバイスをオンにすること、デバイスをスリープから復帰させること、特定のロケーション（例えば、頻繁に訪れるものと識別されるロケーション）に到着することなどが挙げられる。本例では、これらのイベントのそれぞれは、異なるトリガーイベントとして分類され得、又はトリガーイベント全体が、任意のアクセサリデバイスがモバイルデバイスに接続することとすることができる。他の例としては、トリガーイベントは、デバイスとのユーザの特定の相互作用とすることができる。例えば、ユーザは、モバイルデバイスをランニングと調和した方法で移動させることができ、この場合、デバイスのランニング状態はトリガーイベントである。かかるランニング状態（又は他の状態）は、デバイスのセンサに基づいて判定され得る。

ブロック３５＿１２０では、イベントに関連付けられたアプリケーションが識別される。一例として、音楽アプリケーションは、ヘッドホンがヘッドホンジャックに挿入されたときに識別され得る。一部の実施形態では、１つを超えるアプリケーションが識別され得る。予測モデルは、関連アプリケーションを識別することができ、この場合、予測モデルは特定のイベントに対して選択されてもよい。例えば、異なるアプリケーションは異なるコンテキストで使用される可能性が高いので、予測モデルはコンテキスト情報を用いてアプリケーションを識別することができる。一部の実施形態は、例えば、デバイスとのユーザの過去相互作用から判定されるので、ユーザによって選択されるという確率が十分にある場合しかアプリケーションを識別できない。

予測モデルは、サブモデルから構成され得、各サブモデルはコンテキストデータの異なる組み合わせに対するものである。異なる組み合わせは、異なる量のコンテキストデータを有することができる。サブモデルは、階層木で生成され得、より具体的な組み合わせのサブモデルは階層木の下位にある。一部の実施形態では、サブモデルが木の中の高位のモデルより高精度にアプリケーションを予測できる場合しか、サブモデルは生成できない。このように、より正確な予測は、どのアプリケーションをユーザが選択することになるかに対して行われ得る。一部の実施形態では、予測モデル及びサブモデルは、コンテキストデータの特定の組み合わせが存在するイベントの後に、ユーザによって選択される上位Ｎ個のアプリケーション（例えば、パーセンテージの固定数）を識別することができる。

コンテキスト情報は特定のコンテキストに対するデバイスの１つ以上のプロパティを特定することができる。コンテキストは、トリガーイベントが受信されたときのデバイスの周囲の環境（コンテキストのタイプ）としてもよい。例えば、コンテキスト情報はイベントが検出される時間帯としてもよい。別の実施例では、コンテキスト情報は、イベントが検出されたときのデバイスの特定のロケーションとしてもよい。更に別の実施例では、コンテキスト情報は、トリガーイベントが検出された時の年の特定の日としてもよい。かかるコンテキスト情報は、予測エンジンが正確にそのコンテキストでユーザによって使用される可能性のあるアプリケーションを提案できるようにデバイスのコンテキストについてのより有意義な情報を提供してもよい。したがって、コンテキスト情報を利用する予測エンジンは、コンテキスト情報が利用されなかった場合より正確にアプリケーションをユーザに提案することができる。

ブロック３５＿１３０では、アプリケーションと関連してアクションが行われる。一実施形態では、アクションは、ユーザがアプリケーションを実行するように選択するためにユーザインタフェースを表示することとすることができる。ユーザインタフェースは、デバイスのスクリーン上に表示すること、表面に投影すること、あるいはオーディオインタフェースを提供することなどによる、様々な方法で提供されてもよい。

他の実施形態では、アプリケーションが実行されてもよく、またアプリケーション特有のユーザインタフェースがユーザに提供されてもよい。例えば、ロックスクリーン上でのアプリケーションの識別に応答してユーザインタフェースのどちらかを提供してもよい。他の実装形態では、アプリケーションと相互作用するためのユーザインタフェースは、ユーザが（例えば、パスワード又はバイオメトリックによって）認証された後、提供されてもよいが、かかるユーザインタフェースは、実行される提案されたアプリケーションの小リストなど、ただのホームスクリーンより具体的であろう。

一部の実施形態では、「ロックスクリーン」は、ユーザが認証されなかった場合に示されるスクリーンであるので、デバイスはほとんどの使用からロックされている。一部の機能、例えば、カメラは作用を受けてもよい。一部の実施形態では、提案されたアプリケーションに対応するユーザインタフェースはロックスクリーン上で作用を受ける場合、提案されたアプリケーションに関連する一部の機能を得ることができる。例えば、そのアプリケーションを実行することができる。アプリケーションがロックスクリーンから実行される場合、機能は制限されてもよく、制限された機能はユーザが認証されると拡張されてもよい。

一部の実施形態では、「ホームスクリーン」は、デバイスを最初に電源オンした際に現れるデバイスのスクリーンである。モバイルデバイスについては、ホームスクリーンは、デバイス上で実行され得る様々なアプリケーションに対応するアイコンのアレイを示すことが多い。ホームスクリーン上に見えていない他のアプリケーションを閲覧するため、追加のスクリーンにアクセスしてもよい。
ＩＩ．セグメント化

特定のイベントが発生する（例えば、ヘッドホンを差し込むか、デバイスの電源を入れる）たびに、デバイスは、そのイベントに関連してどのアプリケーション（単数又は複数）が使用されるかを追跡することができる。特定のイベントの発生それぞれに応答して、デバイスは、選択されたアプリケーションに対応するデータポイント、アプリケーションによって行われたアクション、及びそのイベントを保存することができる。各種実施形態では、データポイントは、個々に保存するか、あるいは集約することができ、カウントは、特定のアプリケーションが選択される回数に対して判定され、それは特定のアクションに対するカウントを含んでもよい。こうして、異なるカウントが、選択された同一アプリケーションに対する異なるアクションに対して判定する。デバイスとの以前のユーザ相互作用であるこの履歴データは、予測モデルを判定するための、かつ、多くのサブモデルが生成されるかどうか、またどのように生成されるかを判定するための入力として用いられる。

特定のイベントが検出されると、特定のイベントに対応する予測モデルが選択され得る。予測モデルは、トレーニング手順への入力として、特定のイベントに対応する履歴データを用いて判定されるであろう。しかし、履歴データは異なる多くのコンテキスト（すなわち、コンテキスト情報の異なる組み合わせ）において発生する場合があり、異なるアプリケーションは異なるコンテキストで選択される。したがって、集約として、履歴データは、特定のイベントが発生する状態で明らかに選択されることになるアプリケーションを提供しない場合がある。

ニューラルネットワーク又は回帰などのモデルは、特定のコンテキストに対する特定のアプリケーションを識別するようにトレーニングされ得るが、これは、対応する履歴データのすべてを用いる場合に困難になる場合がある。すべての履歴データを用いると、結果的に、予測モデルを過剰適合することになり、精度が低くなる。本発明の実施形態は、履歴データを、それぞれは異なるコンテキストに対応する、履歴データの異なる入力セットにセグメント化することができる。異なるサブモデルは、履歴データの異なる入力セットにおいてトレーニングされ得る。

セグメント化は、機械学習システムの性能を向上させることができる。セグメント化の一ステップでは、入力空間を２つのサブ空間に分割でき、これらのサブ空間のそれぞれを、別個のサブモデルと独立して解決することができる。かかるセグメント化プロセスにより、システムが利用可能な自由パラメータの数を増加させることができ、トレーニング精度を向上させることができるが、これは、各モデル内のデータ量の希釈化を犠牲にして、システムに新しいデータを示すとき、例えば、サブモデルに対するデータ量が少ない場合、システムの精度を低下させる場合がある。実施形態は、結果として生じるサブ空間から作成されたデータ及びモデルパラメータの合わせた分布が信頼できる場合しか、入力空間をセグメント化することができない。
Ａ．異なるコンテキストデータに基づく異なるモデル

特定のイベントが発生した場合、デバイスは様々なコンテキスト、例えば、異なるロケーション、異なる時間、デバイスの異なるモーション状態（ランニング中、歩行中、ドライブ中、又は静止など）、又は電力使用量の異なる状態（スリープモードから電源が入れられる、あるいは移行中など）にあり得る。コンテキスト情報は、検出されたイベントと関連して取り出される、例えば、イベントが検出された後に取り出される場合がある。コンテキスト情報は、検出されたイベントに関連してどのアプリケーションが使用されるかという予測を支援するのに用いられる場合がある。異なるモーション状態は、加速度計、ジャイロメーター、又はＧＰＳセンサなどのモーションセンサを用いて判定することができる。

実施形態は、コンテキスト情報を様々な方法で使用することができる。一実施例では、一部のコンテキストデータ（例えば、デバイスの一つのプロパティに対応する）は、特定のサブモデルの特徴として用いられ、どのアプリケーション（単数又は複数）が最も選択されそうかを予測することができる。例えば、デバイスの特定のロケーションは、サブモデルへの入力として提供される場合がある。これらの特徴はサブモデルの構成物の一部である。

別の実施例では、コンテキスト情報のコンテキストデータのうち一部又は全部はセグメント化プロセスで使用される場合がある。特定部分のコンテキストデータは、入力履歴データをセグメント化するのに用いられ得るので、特定のサブモデルは、その部分のコンテキストデータの対応するプロパティに対応する履歴データを用いてしか判定されない。例えば、デバイスの特定のロケーションはサブモデルへの入力として用いられないが、どのサブモデルを使用するか、またそれに対応して、特定のサブモデルを生成するために、どの入力データを使用するか選択するのに使用されるであろう。

こうして、一部の実施形態では、特定のコンテキストデータがどのサブモデルを使用するかを識別するのに使用される場合があり、他のコンテキストデータは、ユーザが相互作用し得るのはどのアプリケーション（単数又は複数）かを予測するための、サブモデルへの入力として用いられる場合がある。特定のプロパティ（例えば、特定のロケーション）は、特定のサブモデルに対応せず、特定のプロパティは使用されるサブモデルに対する特徴（入力）として用いられる場合がある。特定のプロパティが特定のサブモデルに対応している場合、全モデルが特定のプロパティに割り当てられるので、そのプロパティはより多く使用され得る。

サブモデルを特定のプロパティ（又はプロパティの組み合わせ）に割り当てることの一つの欠点は、その特定のプロパティに対応する大量の履歴データが存在しない場合があることである。例えば、ユーザは、特定のロケーションで数回、特定のイベント（例えば、ヘッドホンに差し込む）を実行しただけの可能性がある。このような限定されたデータ量はまた、データが乏しい（sparse）とも言われる。プロパティの組み合わせが、例えば、特定のロケーションで特定の時刻に使用された場合、データは更に乏しくなる場合がある。この欠点を対処するため、実施形態は、新しいサブモデルをセグメント化プロセスの一部としていつ生成するかを選択して判定することができる。
Ｂ．多くのデータが得られる際のセグメント化

ユーザは最初にデバイスを使用し始める場合、特定のイベント後にアプリケーションを用いて取り得るアクションについて予測を行うための履歴データが存在しないであろう。初期モードでは、予測は提供されないが、履歴データは得られる場合がある。より多くの履歴データが得られるにつれて、予測モデルをサブモデルにセグメント化するかどうかについての判定を行うことができる。更に多くの履歴データを用いると、サブモデルは更なるサブモデルにセグメント化され得る。デバイスとのユーザ相互作用に利用可能な履歴データが限定されている場合、例として、いかなるアクションも取ることができないか、あるいはより一般的なモデルが使用される場合がある。

図３５－２は、本発明の実施形態に係る、セグメント化プロセス３５＿２００を示す。セグメント化プロセス３５＿２００は、ユーザデバイス（例えば、電話機などのモバイルデバイス）によって実行することができ、データのプライバシーを保持することができる。他の実施形態では、セグメント化プロセス３５＿２００は、ユーザデバイスと通信しているサーバによって実行することができる。セグメント化プロセス３５＿２００は、ある期間にわたって（例えば、数日、数ヶ月又は数年にわたって）部分的に実行することができ、あるいはセグメント化プロセス３５＿２００の全部を同時に実行することができ、また定期的に潜在的に再実行することができる。セグメント化プロセス３５＿２００は予測エンジンのルーチンとして実行されることができる。

図３５－２は、収集される、より多くのデータに対応するタイムライン３５＿２３０を示す。より多くのデータが収集されるにつれて、予測モデルはサブモデルにセグメント化され得る。データを収集する異なるポイントにおいて、セグメント化は発生する場合がある（例えばセグメント化３５＿２０１）。より一層多くのデータが得られるにつれて、別のセグメント化が発生する場合がある。図３５－２はタイムライン３５＿２３０に沿った異なるポイントで発生する特定のセグメント化に対する新しいサブモデルを示すが、各セグメント化は、完全にセグメント化を再実行することを伴うことができ、それは、以前のセグメント化と同じように同一のサブモデルが作成されても、作成されなくてもよい。

本例では、イベントモデル３５＿２０５は特定のイベント（例えば、車などの特定のデバイスに接続すること）に対応することができる。イベントモデル３５＿２０５は、特定のイベントの予測エンジンの最上位水準に対応することができる。開始時において、特定のイベントのたった一つのモデルしか存在しない場合があり、最小限度の履歴データしか利用できない。この時点では、イベントモデル３５＿２０５はトレーニング目的で履歴データを追跡できるだけである。イベントモデル３５＿２０５は予測を行うことができ、これらの予測を実際の結果と比較されることができる（例えば、イベントが検出された後、特定の時間内にユーザが予測されたアプリケーションと相互作用するかどうか）。閾値より高い確率を有するアプリケーションがない場合、特定のイベントが発生しても、いかなるアクションも実行されない場合がある。

一部の実施形態では、イベントモデル３５＿２０５は、特定のデバイスに対して収集されたデータのみを使用する。他の実施形態では、イベントモデル３５＿２０５は、他のユーザから集約された履歴データをシードにすることができる。かかる履歴データはイベントモデル３５＿２０５が一部の推薦を提供できるようにする場合があり、その後、追加のデータポイントを得るのを可能にすることができる。例えば、ユーザが提案されたアプリケーションとユーザインタフェースを介して相互作用するかどうかを追跡でき、それにより、単にユーザがアプリケーションを選択するかどうかより多くのデータポイントを提供することができる。

多くのデータが収集されるにつれて、セグメント化が発生すべきかどうかについて定期的に判定を行うことができる。判定は、セグメント化を介してより高精度が達成できるかどうかに基づくことができる。精度は、以下に詳細に説明するが、予測が行われ得る確率の水準として測定することができる。例えば、アプリケーションを、イベントモデル３５＿２０５を用いるより、サブモデルに対して高い水準の確率で予測できる場合、セグメント化を行ってもよい。また、１つ以上の他の基準を用いて、セグメント化プロセスの一部としてサブモデルが作成されるべきかどうかを判定することができる。例えば、基準は、サブモデルが実装される前に、サブモデルが統計的に十分な量の入力履歴データを有していなくてはいけないこととすることができる。少ないデータ量でトレーニングされたモデルは不正確となる場合があるので、データ量の要件により、サブモデルに安定性を向上させ、最終的に、精度を向上させることができる。

セグメント化３５＿２０１では、イベントモデル３５＿２０５をジムサブモデル３５＿２１０及び別のサブモデル３５＿２４０にセグメント化するように判定される。ユーザが特定のコンテキストにおいて決定的な行動をすると、このセグメント化が発生する。本例では、コンテキストが、デバイスがジム（特定のジムでも任意のジムでもよい）に位置することである場合（ある位置を事業所の復元されたロケーションと相互参照することによって判定できる）、決定的な行動が存在する。かかる相互参照はサーバ上に記憶された外部データベースを使用することができる。ジムサブモデル３５＿２１０がユーザによって選択される正確なアプリケーションを、イベントモデル３５＿２０５より高い確率で予測できる場合、決定的な行動を測定することができる。

セグメント化３５＿２０１の一部として、ジムサブモデル３５＿２１０を生成するために用いられる入力履歴データは、ジムの他のすべてのコンテキストに対応するサブモデル３５＿２４０を生成するために用いられる。その他のサブモデル３５＿２４０は、コンテキストがジム以外の何かである場合に、ユーザが相互作用し得るアプリケーションを予測するのに使用され得る。

より多くのデータが収集された後のセグメント化３５＿２０２では、イベントモデル３５＿２０５からスーパーマーケットモデル３５＿２２０を生成するように、更なるセグメント化が行われ得る。スーパーマーケットモデル３５＿２２０が十分な信頼度で予測できるように、この判定は、スーパーマーケットで十分な数のデータポイントが得られた後、行われてもよい。十分な信頼度は、その他のサブモデル３５＿２４０から得られた信頼度に対して測定することができる。スーパーマーケットサブモデル３５＿２２０はその他のサブモデル３５＿２４０より高い信頼度でアプリケーションを予測できると、セグメント化が実行され得る。セグメント化３５＿２０２の後、サブモデル３５＿２４０は、ジム及びスーパーマーケットを除いた任意の他のコンテキストに対応するであろう。

更に多くのデータが収集された後のセグメント化３５＿２０３では、ジムサブモデル３５＿２１０のセグメント化が行われ得ると判定される。本例では、アプリケーションは、履歴データ内で、より高い信頼度で予測され得ると判定されるのは、ジムが具体的な時刻、具体的には、午後の時刻（例えば、１２時～４時）にセグメントされているからである。こうして、ユーザが午後にジムにいる場合、午後ジムサブモデル３５＿２１１は、ユーザがどのアプリケーション（単数又は複数）と相互作用し得るかを予測するのに使用することができる。ユーザが任意の他の時刻にジムにいる場合、ジムサブモデル３５＿２１０が使用でき、それは、木の中のある位置では、すなわち、その他のサブモデル３５＿２４０が示されるのと同様に、いくつかのその他のサブモデルを有することに相当する。

更に多くのデータが収集された後のセグメント化３５＿２０４では、午前ジムサブモデル３５＿２１２を生成するために、ジムサブモデルモデル３５＿２１０の更なるセグメント化が行われ得ると判定される。本例では、午前の時刻に対する十分な履歴データが収集されたので、（これは午後ジムサブモデル３５＿２１１に対応しないデータのみを使用する）より一般的なジムサブモデル３５＿２１０を用いるよりも、アプリケーションをより高い精度で予測できる。
１．既定モデル

デバイスがユーザによって最初に得られた（例えば、購入された）場合、既定モデルが使用され得る。既定モデルは、イベントのグループ（例えば、トリガーイベントと指定されるすべてのイベント）に適用することができる。上述のように、既定モデルは、他のユーザからの集約データをシードとすることができる。一部の実施形態では、既定モデルは、例えば、任意の一つのコンテキストに対して利用できるデータが十分でないので、コンテキストにかかわらず、単に最も人気のあるアプリケーションを選ぶことができる。より多くのデータが収集されると、既定モデルを廃棄することができる。

一部の実施形態では、既定モデルは、提案される所定のアプリケーション（単数又は複数）及び実行されるアクションを特定するハードコードされたロジックを有することができる。このようにして、ユーザがどのように応答するか（例えば、否定的な応答はユーザが提案されたアプリケーションを選択しないことである）についてユーザは深く調査される場合があり、これは、単純に、ユーザの肯定的な応答を追跡する、追加データを提供することができる。かかる既定モデルと並列に、その予測と実際の結果を比較するため、予測モデルが実行されている場合がある。その後、予測モデルは、実際の結果に応答して精緻化され得る。予測モデルが十分な信頼度を有する場合、既定モデルから予測モデルに切り替えを行うことができる。同様に、サブモデルの性能を追跡することができる。サブモデルが十分な信頼度を有する場合、サブモデルは、所与のコンテキストに対して使用され得る。
２．初期トレーニング

予測モデル（例えば、イベントモデル３５＿２０５）は、これまで収集された履歴データを用いて初期トレーニングを受けることができ、この場合、モデルはユーザに提案を提供しない。このトレーニングは、初期トレーニングと呼ばれる場合がある。予測モデルは、定期的に（例えば、毎日）バックグラウンドプロセスの一部として更新される場合があり、それはデバイスが充電中で使用されていないときに発生してもよい。トレーニングは、正確な予測数を最適化すると共に、履歴データ内の実際の結果と比較されるようにモデルの係数を最適化することを伴う場合がある。別の実施例では、トレーニングは、実際に選択された上位Ｎ個（例えば、所定の数、所定のパーセンテージ）のアプリケーションを識別することを含んでもよい。トレーニング後、モデルの精度は、モデルが提案されたアプリケーション（及び対応する潜在的なアクション）をユーザに提供するのに用いられるべきかを判定するのに測定され得る。

モデルが十分な精度を得る（例えば、最上位選択アプリケーションが十分に高い精度で選択されている）と、モデルを実装することができる。かかる出来事は、最上位水準のモデル（例えば、イベントモデル３５＿２０５）には起こらない場合があるが、サブモデルが特定のコンテキストに対してテストされた場合は、発生する場合がある。したがって、かかる初期トレーニングは、サブモデルに対して同様に実行することができる。

モバイルデバイスの使用を通して履歴情報が蓄積されるについて、予測モデルは、新しい履歴情報を考慮して定期的にトレーニング（すなわち、更新）されてもよい。トレーニングされた後、予測モデルは、ユーザとモバイルデバイスとの間の一番最近の相互作用パターンにしたがって、より正確にアプリケーション及びアクションを提案することができる。予測モデルのトレーニングは、大量の履歴情報が記録された場合は、最も効果的となり得る。こうして、トレーニングは、モバイルデバイスがユーザとの多数の相互作用を検出できるようにするほど十分に長い間隔で発生してもよい。しかし、トレーニングセッションの間あまりに長時間待つことは、予測エンジンの適応性を妨げる場合がある。したがって、トレーニングセッションの間の好適な時間は、１５～２０時間、例えば、１８時間とすることができる。

予測モデルのトレーニングは時間がかかる場合があり、モバイルデバイスの使用と干渉する場合がある。したがって、トレーニングはユーザがデバイスを使用する可能性が最も低いときに発生してもよい。ユーザがデバイスを使用しないであろうことを予測する一つの方法は、デバイスが使用されていない期間、例えば、ボタンが押されていないとき、及びデバイスが移動していないときを一定期間待つ方法がある。これは、ユーザが近い将来に一定期間、例えば、ユーザが寝ているとき、電話機と相互作用しない状態にあることを示すことができる。任意の好適な持続時間は、１時間から３時間などの待ち時間に使用することができる。特定の実施形態では、待ち時間は２時間である。

２時間の終わりに、予測モデルは更新されてもよい。しかし、この２時間の終了前に、ユーザがモバイルデバイスと相互作用する（ボタンを押すか、又はデバイスを移動する）場合は、２時間の期間のカウントダウンが再始動してもよい。この時間が、アクティブにされていない２時間に達する前に絶えず再始動する場合は、モバイルデバイスは、絶対時間後に予測モデルのトレーニングを強制してもよい。一実施形態では、絶対時間は、旧式の予測モデルのため、ユーザによるモバイルデバイスの使用しやすさが低下し始める閾値時間であると判定されてもよい。絶対時間は、１０～１５時間である場合があり、あるいは特定の実施形態では１２時間としてもよい。したがって、トレーニング間の最大時間は、２８時間（１８＋１０時間）～３３時間（１８＋１５時間）とすることができる。特定の実施形態では、最大時間は、３０時間（１８＋１２時間）である。
ＩＩＩ．コンテキスト情報に基づいたモデルの選択

予測モデル及びあらゆるサブモデルは、例えば、図３５－２に示すように決定木として体系化され得る。決定木のサブモデルはノードとも呼ばれる場合がある。決定木の各ノードは、異なるコンテキスト、例えば、異なるコンテキストデータの組み合わせに対応することができる。コンテキスト情報のコンテキストデータを用いて決定木を横断でき、どのサブモデルを使用するかを判定することができる。
Ａ．決定木の横断

図３５－３は、本発明の実施形態にしたがって生成され得る決定木３５＿３００を示す。イベントモデル３５＿３０５は、決定木３５＿３００の最上位水準のモデルに対応する。イベントモデル３５＿３０５は、例えば、本セクションで述べるように、特定のイベントに対応することができる。イベントモデル３５＿３０５は、対応するイベントの検出に応答して選択されてもよい。イベントモデル３５＿３０５が選択されると、どのサブモデルが使用されるかについて判定が行われてもよい。各サブモデルは異なる履歴データ、例えば、相互排他的なセットのデータを使用することができる。異なるサブモデルを有する異なる決定木が検出された異なるイベントに対して存在することになる。

決定木３５＿３００の第１の階層水準は、ロケーションカテゴリに対応する。ノード３５＿３１０は、ロケーション１に対応し、それはロケーション１の境界領域（例えば、特定の半径内）として規定されてもよい。ノード３５＿３２０はロケーション２に対応する。ノード３５＿３３０はロケーション３に対応する。ノード３５＿３４０は、任意の他のロケーションに対応する。

サブモデルが、コンテキスト情報が特定のロケーションに対応するとき、より一般的なノード３５＿３４０が予測できるよりも高い信頼度でアプリケーションを予測できる場合に、ノード３５＿３１０、３５＿３２０及び３５＿３３０のそれぞれは生成され得る。ノード３５＿３１０及び３５＿３２０は更なる子ノードを有するが、ノード３５＿３３０は有しない。

実施形態は、ノード３５＿３１０，３５＿３２０及び３５＿３３０のいずれかが特定の出来事に対するコンテキスト情報と一致するかを検索することによって、決定木３５＿３００を横断することができる。イベントの特定の出来事に対するユーザデバイスのコンテキスト情報が、ロケーション３を含むコンテキストを示す場合、ノード３５＿３３０に対して一致が発見される。ノード３５＿３３０は更なる子ノードを有しないので、ノード３５＿３３０のサブモデルが使用され得る。

ノード３５＿３１０は、２つの子ノード、すなわちノード３５＿３１１及びノード３５＿３１２を有する。ノード３５＿３１１は特定の時刻（時刻１）に対応し、ノード３５＿３１２は時刻１と一致しないすべての他の時刻に対応する。イベントの現在の出来事に対するコンテキスト情報がロケーション１（かつ、それゆえに、ノード３５＿３１０との一致）を含む場合、検索が実行され、コンテキスト情報が時刻１を含むか（すなわち、ノード３５＿３１１と一致するか）を判定することができる。コンテキスト情報が時刻１を（すなわち、ロケーション１と組み合わせて）含む場合、予測を行うのにノード３５＿３１１のサブモデルを使用することができる。コンテキスト情報が時刻１を含まない場合、予測を行うのにノード３５＿３１２のサブモデルを使用することができる。

ノード３５＿３２０は、２つの子ノード、すなわちノード３５＿３２１及びノード３５＿３２２を有する。ノード３５＿３２１はユーザデバイスが特定のデバイス（デバイス１）に接続されているかどうかに対応し、ノード３５＿３２２は、ユーザデバイスがデバイス１に接続されていないときに対応する。イベントの現在の出来事に対するコンテキスト情報がロケーション２を含む（かつ、それゆえに、ノード３５＿３１０と一致する）場合、検索が実行され、コンテキスト情報がデバイスへの接続を含むか（すなわち、ノード３５＿３２１と一致するか）を判定することができる。コンテキスト情報がデバイス１への接続を（すなわち、ロケーション２と組み合わせて）含む場合、予測を行うのにノード３５＿３２１のサブモデルを使用することができる。コンテキスト情報がデバイス１への接続を含まない場合、予測を行うのにノード３５＿３２２のサブモデルが使用され得る。

したがって、木の底が検出されると、予測を行うのに最終ノードのサブモデルが使用され得る。木３５＿３００の分岐のすべては、常に同一のコンテキスト情報に対して最終ノードが選択されて、決定的となり得る。決定木３５＿３００の同じ階層水準のすべてのノードを同じカテゴリに対応させることで、適用可能なノードを選択する際の衝突を回避することができる。例えば、イベントモデル３５＿３０５の子ノードが時刻１に対応する場合、それがノード３５＿３１１と衝突し得るため、衝突が存在する可能性がある。かかる実施形態では、同じ水準だが異なる親ノードの下のノードは、ノード３５＿３１１及び３５＿３１２のセット並びにノード３５＿３２１及び３５＿３２２のセットの場合と同じように、異なるカテゴリに対応することができる。

検出されたイベント及びコンテキスト情報に基づいてサブモデルが選択されると、選択されたサブモデルは、より多くのアプリケーション及び対応するアクションは何かを予測するのに使用され得る。一部の実施形態では、予測されたアプリケーションに対してどのアクションを取るかは、アプリケーションが予測される信頼水準に依存する場合がある。
Ｂ．方法

図３５－４は、本発明の実施形態に係る、イベントに基づいてコンピューティングデバイスのユーザにアプリケーションを提案するための方法３５＿４００のフローチャートである。方法３５＿４００は、コンピューティングデバイスによって（例えば、ユーザデバイスとのユーザ相互作用を追跡しているユーザデバイスによって）実行され得る。方法３５＿４００は、コンピューティングデバイスの１つ以上のプロパティの異なるセットを有する相互作用を含む過去相互作用のセットを使用して、アプリケーションを提案することができる。

ブロック３５＿４１０では、デバイスは入力デバイスでイベントを検出する。入力デバイスの例は、ヘッドホンジャック、ネットワーク接続デバイス、タッチスクリーン、ボタンなどである。イベントは、モバイルデバイスが外部デバイス又はユーザなどの外部エンティティと相互作用するあらゆるアクションとすることができる。イベントはデバイスに対して繰り返されるタイプのものとすることができる。こうして、履歴統計データは、イベントの異なる出来事に対して得ることができる。モデル及びサブモデルは、かかる履歴データを用いてトレーニングされ得る。

ブロック３５＿４２０では、イベントに対応する予測モデルが選択される。選択された予測モデルはイベントに依存する場合がある。例えば、Ｂｌｕｅｔｏｏｔｈ接続に対して設計された予測モデルは、イベントが外部デバイスとのＢｌｕｅｔｏｏｔｈ接続の確立に関連する場合に選択されてもよい。別の実施例としては、ヘッドホン接続に対して指定された予測モデルは、イベントがヘッドホンのセットのヘッドホンジャックへの挿入に関連する場合に選択されてもよい。

ブロック３５＿４３０では、コンピューティングデバイスの１つ以上のプロパティを受信することができる。１つ以上のプロパティが、デバイス上で実行されるアプリケーション提案エンジンによって受信されてもよい。本セクションで述べるように、プロパティは時間、ロケーション、モーション状態、現在又は以前の電力状態（例えば、オン、オフ、又はスリープ）、充電状態、現在の選曲、カレンダーイベントなどに対応することができる。かかる１つ以上のプロパティは、デバイスの特定のコンテキストを規定するコンテキストデータに対応することができる。イベントを検出した頃の時刻に、例えば、ある時間内に、１つ以上のプロパティを測定することができる。時間は、イベント検出前後の時刻、イベント検出直前の時間、又はイベント検出直後の時刻を含むことができる。

ブロック３５＿４４０では、１つ以上のプロパティが予測モデルの特定のサブモデルを選択するのに使用される。例えば、決定木は横断され、特定のサブモデルを判定することができる。例えば、１つ以上のプロパティが特定のサブモデルを一意的に識別する点で、特定のサブモデルは１つ以上のプロパティに対応することができる。これは、決定木が同じ親ノードの下の異なるカテゴリのプロパティを有しないように規定されているときに、発生することができる。

特定のサブモデルは、デバイスとのユーザの過去相互作用の特定のサブセットを用いて生成することができる。特定のサブセットは、サブモデルを作成することによって精度を高くするセグメント化プロセスから生じ得る。過去相互作用の特定のサブセットを、イベントの発生後にデバイスとのユーザ相互作用を追跡することによって得ることができる。コンピューティングデバイスは、特定のサブセットが得られるとき、１つ以上のプロパティを有する。こうして、デバイスの現在のコンテキストは、過去相互作用の特定のサブセットが得られたデバイスのコンテキストに対応する。

ブロック３５＿４５０では、特定のサブモデルは、１つ以上のアプリケーションを識別し、ユーザに提案する。１つ以上のアプリケーションは、イベントと関連してユーザがアクセスしている１つ以上のアプリケーションのうち少なくとも１つの少なくとも閾値確率を有してもよい。履歴データ内の１つ以上のアプリケーションのうち１つの予測は、正確な予測として識別され得る。閾値確率は、様々な方法で測定することができ、以下に詳述するように、履歴データから測定された確率分布を使用することができる。例えば、確率分布の平均（average）（平均（mean））確率、中央（median）確率、又はピーク値は、閾値確率を超える（例えば、０．５（５０％と同等）を超える）ように要求され得る。こうして、信頼水準は、確率分布の平均値、中央値又はピーク値とすることができる。別の例は、特定の値を超える確率分布のための面積が閾値確率より大きいことである。

ブロック３５＿４６０では、１つ以上のアプリケーションと相互作用するためにユーザインタフェースがユーザに提供される。例えば、デバイスは、ユーザが識別されたアプリケーションにアクセスしたいかどうかを示すように、ユーザが相互作用し得るインタフェースを介して、識別されたアプリケーションをユーザに表示してもよい。例えば、ユーザインタフェースは、識別されたアプリケーションのうちの１つ以上をユーザに示すタッチ感知ディスプレイを含んでもよく、タッチ感知ディスプレイと相互作用することによって、ユーザは、デバイスによって識別されたアプリケーションのうち１つ以上にアクセスするのを可能にする。ユーザインタフェースは、コンピューティングデバイスのホームスクリーン上で提供されるよりも、少ないアプリケーションとディスプレイスクリーン上で相互作用するのを可能にすることができる。

一実施例としては、１つ以上の提案されたアプリケーションは、ロックスクリーン上で提供され得る。ユーザは、ロックスクリーンからアプリケーションを開くよう選択することができ、それによって、ユーザがアプリケーションと相互作用するのを容易にすることができる。ユーザインタフェースは、他のスクリーン上で提供される場合もあり、デバイスの使用を開始するためにボタンをアクティブにした後、発生してもよい。例えば、アプリケーションに特有のユーザインタフェースは、（例えば、パスワード又はバイオメトリックを介して）ユーザを認証した後に出現することができる。
Ｃ．例示のモデル

一部の実施形態では、モデルは、所与のセット（又はサブセット）のデータのための上位Ｎ個のアプリケーションを選択することができる。このＮ個のアプリケーションは過去に最も選ばれたものなので、将来の行動は過去の行動を反映するものと予測することができる。Ｎは、アプリケーションの所定の数（例えば、１、２、又は３）又はパーセンテージとすることができ、それは、イベントと関連して実際に使用されたアプリケーションのパーセンテージ（すなわち、デバイス上のすべてのアプリケーションとは限らない）であり得る。かかるモデルはユーザに提供するための上位Ｎ個のアプリケーションを選択することができる。更なる分析が実行され、例えば、信頼水準に依存し得る、Ｎ個のアプリケーションをユーザに提供するか、及びＮ個のアプリケーションをユーザにどのように提供するか（例えば、アクション）を判定するために、Ｎ個のアプリケーションのそれぞれに対して確率（信頼）水準を測定することができる。

Ｎが３である例では、コンテキスト情報が特定のサブモデルに相当する状態でイベントが発生した場合、モデルは、上位３つの最も起動されるアプリを返すであろう。

他の実施形態では、サブモデルは、合成信号を使用することができ、この場合、一部のコンテキスト情報は、単にサブモデルを選択するためにコンテキスト情報を用いるのではなく、予測されたアプリケーションを決定する際に使用される。例えば、ニューラルネットワーク又はロジスティック回帰モデルは、アプリケーションを予測するため、ロケーション（又はその他の特徴）を使用すると共に、これらの特徴のいくらかの線形重み付き組み合わせを構築することができる。このようなより複雑なモデルは、サブモデルに対するデータ量が著しく大きい場合は、より好適となり得る。一部の実施形態は、より多くのデータが特定のノードに対して得られると、その特定のノードで用いられるサブモデルのタイプ（すなわち、コンテキストデータの特定の組み合わせ）を切り替えることができる。
ＩＶ．モデル及び決定木の生成

一部の実施形態では、決定木は、再生時における履歴データに基づいて定期的に（例えば、毎日）再生され得る。こうして、決定木は、異なる日において異なる形態を有することができる。子ノード（更なるサブモデル）の生成は、アプリケーション（単数又は複数）を予測するための信頼度が増大されることによって統御することができ、これは、情報利得とも呼ばれる。子ノードの生成はまた、子ノードに対するデータが統計的に有意であるかによっても統御され得る。一部の実施形態では、所与の水準での子ノードのすべて（例えば、ジムサブモデル３５＿２１０及びその他のサブモデル３５＿２４０）は、統計的に有意となるよう要求され得、親ノードに対する情報利得を提供することができる。

決定木のノードを判定する際は、セグメント化を様々な方法で実行することができ、結果的に異なる決定木が生じ得る。例えば、特定のロケーション及び特定の時刻は両方とも使用することができる。一部の実施形態では、アプリケーションを予測するための情報利得（信頼度）の最大の増加をもたらすプロパティは、決定においてより高く生成され得る。かかるセグメント化プロセスは、ユーザが相互作用することになる正確なアプリケーションを予測する確率を確実に最も高くすることができる。
Ａ．モデルの精度分布

モデルの精度は、履歴データに照らしてテストすることができる。所与のイベントについては、履歴データは、どのアプリケーション（単数又は複数）がそのイベントと関連して（例えば、１分以内のように直前又は直後）使用されたかを識別することができる。各イベントについては、コンテキストデータを使用して特定のモデルを判定することができる。更に、コンテキストデータはモデルへの入力特徴として使用することができる。

モデル（又はサブモデル）が最上位アプリケーションを選択する実施例では、最上位アプリケーションが実際に選択（起動）された履歴データポイントの数が正確なカウントとして判定され得、また最上位アプリケーションが選択されなかった履歴データポイントの数は不正確なカウントとして判定され得る。上位Ｎを選択するモデルに対してＮが１より大きい実施形態では、正確なカウントは、上位Ｎ個のアプリケーションのうち１つが起動された任意の履歴データポイントに対応することができる。

正確なカウント及び不正確なカウントは、モデルがどれほど正確であるかを特定する分布を判定するのに使用することができる。二項分布は、精度分布として使用され得る。パラメータｍ及びｐを有する二項分布は、ひと続きのｍ個の独立したｙｅｓ／ｎｏ実験における成功数の離散確率分布である。ここで、ｙｅｓ／ｎｏ実験は、予測されたＮアプリケーションのうち１つが正確であるかどうかである。例えば、モデルは、音楽アプリケーションが起動されると予測し、そして音楽が起動された場合、データポイントがｙｅｓ（真）の実験の数を追加する。音楽アプリケーションが起動されなかった（例えば、別のアプリケーションが起動されたか、又はアプリケーションは何も起動されなかった）場合、データポイントはｎｏ（偽）の実験の数を追加する。

ベイズの定理のもとでは、

Ｂは、特定の判定された正確なカウントＴ及び不正確なカウントＦを得るイベントである。Ａは、予測されたアプリケーションが正確であるというイベントである。Ｐ（Ａ）は、正確なアプリケーションを無作為に選択する事前（期待）確率であり、少なくとも履歴データがなければ、特定のアプリケーションが他のいずれかのアプリケーションよりも多く期待されることはないので、１であると想定され得る。Ｐ（Ｂ）は、モデルが正確である確率（正確なカウントを履歴イベントの総数で割ったものに相当する）である。Ｐ（Ｂ｜Ａ）は、所与の確率ｒに対する正確なカウントＴ及び不正確なカウントＦを得る尤度関数である（すなわち、正確か不正確かを得る均等な確率を０．５とみなすことができるイベントＡ）。Ｐ（Ａ｜Ｂ）は、事後確率が判定されること、すなわち、履歴データＢが与えられたときに予測アプリケーション（単数又は複数）のうち１つが選択される確率である。

一様な事前確率が存在する場合、Ｐ（Ａ）が消えて１が残り、Ｐ（Ａ｜Ｂ）／Ｐ（Ｂ）となり、これは、ｂｅｔａ［＃ｃｏｒｒｅｃｔ，＃ｉｎｃｏｒｒｅｃｔ］、即ち、パラメータａｌｐｈａ＝＃ｃｏｒｒｅｃｔ及びｂｅｔａ＝＃ｉｎｃｏｒｒｅｃｔを有するｂｅｔａ分布に等しい。ｂｅｔａ関数はａｌｐｈａ＝０又はｂｅｔａ＝０のため、明確に定義されていないので、実施形態は＃ｃｏｒｒｅｃｔ及び＃ｉｎｃｏｒｒｅｃｔに対して初期値１と仮定することができる。ｂｅｔａ［１＋＃ｃｏｒｒｅｃｔ，１＋＃ｉｎｃｏｒｒｅｃｔ］は二項分布である。

ベイズ統計では、事後確率ｐ（θ│Ｘ）は、証拠Ｘ（例えば、履歴データの正確なカウント及び不正確なカウント）が与えられたとき、パラメータθ（例えば、実際に選択されたアプリケーションは予測されるアプリケーションのうちの１つである）の確率である。これは、パラメータが与えられたときの証拠Ｘ（例えば、履歴データの正確なカウント及び不正確なカウント）の確率（例えば、予測されるアプリケーションがイベントに対して選択されている）である、尤度関数ｐ（ｘ｜θ）とは対照的である。この２つは、以下のとおり関連している。すなわち、確率分布関数がＰ（θ）（例えば、選択されたアプリケーションが正確であるだろう期待確率）であるという事前信念、及び尤度ｐ（ｘ｜θ）を有する観察値Ｘがある場合、事後確率は

として規定される。事後確率は事前確率と尤度の積に比例すると考えることができる。

他の精度分布を使用してもよい。例えば、ディリクレ分布を使用することができ、それは、ｂｅｔａ分布の多変量一般化である。ディリクレ分布は、ｂｅｔａ分布が二項分布の共役事前であるのと同様に、カテゴリ分布及び多項分布の共役事前である。ディリクレは、その確率密度関数を有し、各イベントがα_ｉ－１回観測された場合、Ｋ個のライバルイベントの確率はｘ_ｉであるという信念を返す。ディリクレ分布は、多項分布として、アプリ起動の全ヒストグラム（すなわち、特定のイベントに対するアプリ起動の予測数）を生成するのに使用され得る。

その代わりに、実施形態は、それらを２つのクラス（正確及び不正確）に分割し、二項分布を用い、全ヒストグラムを提供する必要はない。他の実施形態は、ディリクレ分布（多項分布の共役事前）を使用して、ヒストグラム全体を記載するというより難しい問題を解決しようと試みることができるが、これは、より多くのデータが説明される必要があるから、信頼性のあるように多くのデータを取り込むことになる。
Ｂ．例示の二項分布

図３５－５Ａ～図３５－５Ｄは、本発明の実施形態に係る、様々な正確な数及び不正確な数の例示の二項分布のプロットを示す。プロットはｂｅｔａ［１＋＃ｃｏｒｒｅｃｔ，１＋＃ｉｎｃｏｒｒｅｃｔ］から生成されたものである。プロット内の横軸上には、１は正確な予測に対応し、０は不正確な予測に対応する。縦軸は、モデルがどれくらいの頻度で正確になるかについての確率を提供する。これらの分布はまた、確率密度関数（ＰＤＦ）とも呼ばれる。分布は、比較のために正規化することができる。

図３５－５Ａは、２個の正確な予測及び２個の不正確な予測についての二項分布を示す。かかるモデルは、正確と不正確が等しいので、０．５において確率が最も高くなる。０．５の最高値は、モデルが半分の回数だけ正しい予測を得る可能性が最も高いことを示す。データポイントの数が少ない場合、分布はかなり広くなる。したがって、モデルの精度についての信頼度は低いものである。モデルが回数の５０％未満は正確であるか、あるいは回数の５０％超は正確であるという確率が顕著に存在する。しかし、データポイントの数が少ないので、正確さを判定する際の信頼度は低い。

図３５－５Ｂは、２個の正確な予測及び１個の不正確な予測についての二項分布を示す。かかるモデルは、回数の６６％は正確である。したがって、分布のピークは約０．６６である。しかし、データポイントの数が少ない場合、信頼度は非常に低くなる。モデルが回数の１０又は２０％しか正確にならない確率が顕著に存在する。

図３５－５Ｃは、４個の正確な予測及び２個の不正確な予測についての二項分布を示す。かかるモデルはまた、回数の６６％は正確であるが、依然としてデータポイントの数が少ない場合は、より多くのデータが得られると、モデルが３０％しか正確にならない確率が顕著に存在する。

図３５－５Ｄは、４０個の正確な予測及び２０個の不正確な予測についての二項分布を示す。かかるモデルはまた、回数の６６％は正確である。しかし、データポイントの数がより多い場合は、モデルが３０％しか正確にならない確率が非常に低い。したがって、分布は、モデルの精度が６６％であることを判定するにあたって、より高い信頼度を示す。更に、分布下の面積の多くは０．５の右側にあるので、モデルが回数の少なくとも５０％は正確であることを、図３５－５Ｂに対して判定できるより高い信頼度で判定することができる。
Ｃ．統計的有意性

モデルが十分な信頼度で正確である場合と間違っている場合を正確に分けることができる場合、モデルは統計的に有意であると考えることができる。不正確な予測数及び正確な予測数に基づいて判定された事後確率分布は、モデルが十分に正確かを十分な信頼度で判定するのに使用することができる。

統計的有意性のために要求される信頼水準は、様々な方法で提供でき、様々な基準を有することができる。分布の平均的な精度（＃ｃｏｒｒｅｃｔ／＃ｔｏｔａｌ）、分布のピーク、又は分布の中央値は、特定の値を有することが要求され得る。例えば、モデルは、例えば、分布の平均で測定して、回数の少なくとも５０％は正確であることが要求され得る（すなわち、０．５より大きい）。＃ｃｏｒｒｅｃｔ／＃ｔｏｔａｌはまた最尤推定とも呼ばれる。

更なる基準（信頼水準）は精度の信頼度になり得る。信頼度は、下限より上にある分布の積分によって測定することができる（例えば、０．２５又はその他の値より上にある分布の面積）。分布曲線の下の面積は累積分布関数とも呼ばれる。一実施形態では、基準は、ＰＤＦの面積の９５％が０．２５を超えることとすることができる。間隔［ｘ，１．０］がＰＤＦより下の面積の９５％をカバーする点は、「信頼下限」と呼ばれる。したがって、２回正しく、１回間違っていた場合、回数のうち６６％は正しいが、それは、図５Ｂのように、分布が非常に広いので、統計的に有意ではない。

一部の実施形態では、モデルが十分に正確であり、精度を知るのに十分な信頼度がある場合のみ、モデル（例えば、最上位水準モデル又はサブモデル）を使用し始める。例えば、初期モデルは、使用される前しばらくの間はトレーニングされる場合がある。一度でも精度及び信頼度がそれぞれの閾値を超えると、実施形態は、ユーザに提案を提供するため、モデルを使用し始め得る。一部の実施形態では、面積が右側に十分にシフトされると、精度が十分に高いことが分かるため、ＰＤＦの一定量の面積の要件が、モデルを使用するかを判定するための単一の基準を提供することができる。

一部の実施形態では、初期モデルは、他の人々からのデータを用いて、少なくとも最初により多くの統計を提供することができる。その後、十分な統計が得られると、特定の人に対するデータだけが使用されてもよい。更に、そのユーザ特有のデータをより高く重み付けして、他の人々からのデータを徐々に取り除くことができる。
Ｄ．情報利得（エントロピー）

モデルの第１の確率分布とサブモデルの第２の確率分布との間で比較を行い、モデルをセグメント化するかを判定することができる。一部の実施形態では、この比較により、情報利得（例えば、カルバック・ライブラー情報量）、すなわち、これと同等の、エントロピーの低下が存在するかを判定することができる。高いエントロピーでは、多くのアプリケーションの、選択される確率は同様となり、最大のエントロピーは、すべてのアプリケーションにおいて同じ確率となる。最大エントロピーでは、アプリケーションのすべてが等しい確率を有し、あるアプリケーションが選択される確率が、他のものより高い、ということはなくなるため、正確なアプリケーションを選択する尤度は最小となる。

かかる差分メトリックを使用して、サブモデルが適用されることになる所与のコンテキストのサブモデルを用いてより正確な予測（信頼度を含む）を行うことができるかを判定することができる。差分メトリックは差分閾値を超える場合、セグメント化が実行され得る。差分メトリックは、情報が得られたことを確認するために正符号を有することができる。カルバック・ライブラー情報量は差分メトリックとして用いられることができる。他の例示のメトリックは、ジニ不純度及び分散減少を含む。

例えば、あらゆることに対して１つのモデルが存在した場合、モデルは、すべてのコンテキストに対して最上位アプリケーション（例えば、音楽アプリケーション）のみを選択する。音楽アプリケーションは、すべてのコンテキスト（例えば、ジム、車での通勤時）に対する予測となる。サブモデルがより具体的なコンテキストに対して生成されると、予測は、より具体的になることができ、例えば、ユーザがジムに行く場合、単一のアプリのみが選択される、又は特定のプレイリストのみが選択される。したがって、１つのアプリケーションの選択数にピークが存在する場合があり、他のすべてはゼロになる。こうして、決定木での目標は、情報利得を最大化する（エントロピーを最小化する）ことである。

更なるサブモデルは、より具体的なコンテキストがより多くの情報利得を提供できる場合に、識別され得る。例えば、午前中のジムは、特定のプレイリストのみが選択される場合における、より具体的なコンテキストであり得る。別の実施例としては、午前中に車に接続されると、ニュースアプリケーションのより正確な予測を提供できるのは、履歴データが、主としてニュースアプリケーション（又はニュースアプリケーションのグループ）を選択するように、より体系化されるからである（エントロピーの低下）。

図３５－６Ａ及び図３５－６Ｂは、本発明の実施形態に係る、セグメント化から生じる親モデル及びサブモデルを示す。図３５－６Ａは、８０個の正確な予測及び６０個の不正確な予測を提供する親モデルについての二項分布を示す。サブモデルを、親モデルに使用される履歴データの一部から作成することができる。図３５－６Ｂは、１４個の正確な予測及び２個の不正確な予測を提供するサブモデルについての二項分布を示す。サブモデルはデータポイントがより少ないが、より高い正確性を意味する、１に向かうシフトによって明らかであるように、より高い精度を有する。こうして、エントロピーが低下し、情報利得が得られる。
Ｅ．セグメント化する時期

上述のように、様々な実施形態は、サブモデルを生成するようモデルをセグメント化するかを判定するための１つ以上の基準を使用することができる。１つの基準は、正確な予測を行うための信頼水準（１つ以上の予測されたアプリケーションのグループのうちの１つが選択される）が信頼度閾値を超えることとすることができる。例えば、正確な予測の平均確率は、精度閾値（信頼度閾値の例）よりも高い。別の実施例としては、特定の値を超える分布のＣＤＦは、信頼水準を超えることが要求され得る。

別の基準としては、モデルの代わりにサブモデルを用いることにより、情報利得（エントロピーの低下）を提供することとすることができる。例えば、カルバック・ライブラー情報量の値は、差分閾値と比較され得る。セグメント化についての１つ以上の基準は、サブモデルがベースモデルより性能が優れていることを保証することができる。この１つ以上の基準は、親モデルのサブモデルのすべて、例えば、ジムサブモデル３５＿２１０及びその他のサブモデル３５＿２４０について要求され得る。

一部の例では、信頼下限は、親モデルに対しする２つのサブモデルにおいて、低下する場合があるが、依然として情報利得と、閾値を超える信頼下限とを有する。信頼下限は増加する場合もある。サブモデルのすべてが十分に高い信頼限界を有し、情報利得が十分に正である限り、実施形態は、より一般的なモデルをセグメント化（分割）するよう選択することができる。

一部の実施形態では、あらゆる精度及び情報利得の基準は、信頼水準がセグメント化の結果として確実に増加することによって満たすことができる。例えば、デバイスの第１のプロパティは、親モデルに関する他のプロパティを含み得る、第１のコンテキストの第１のサブモデルをテストするために選択され得る。コンピューティングデバイスが第１のプロパティを有した場合に発生した過去相互作用の第１のサブセットは、識別され得る。第１のサブセットは、親モデルの過去相互作用のセットから選択され、過去相互作用のセットより小さい。

過去相互作用の第１のサブセットに基づいて、第１のサブモデルは、イベントと関連してユーザがアクセスすることになる、１つ以上のアプリケーションからなる第１のグループのうちの少なくとも１つのアプリケーションを、第１の信頼水準で予測することができる。第１のサブモデルは、少なくとも、０以上とすることができる閾値量だけ初期信頼水準を超える第１の信頼水準に少なくとも基づいて作成され得る。この閾値量は差分閾値に対応することができる。一部の実装形態では、第１のサブモデルは作成され得、この基準が満たされたときにいつも作成されるわけではなく、更なる基準が使用されてもよい。信頼水準が初期信頼水準以下の場合は、別のプロパティがテストのために選択され得る。信頼水準のこうした比較は、情報利得のテストに対応することができる。１つ以上のアプリケーションからなる第２のグループを予測するための第１のサブモデルの（第２のプロパティのための）第２のサブモデルの第２の信頼水準を判定するために、同じプロセスを繰り返すことができる。過去相互作用の第２のサブセットは、第２のサブモデルに使用され得る。第３のプロパティ又はそれ以上のプロパティは同様の方法でテストされ得る。
Ｆ．決定木の再生

実施形態は、定期的に、例えば、毎日、モデルの決定木を生成することができる。生成はその時に利用可能な履歴データを使用することができる。こうして、決定木は、１つの生成から別の生成へ変化することができる。一部の実施形態では、決定木は、以前の決定木の知識がなくても構築される。他の実施形態では、新しい決定木が、かかる以前の知識から、例えば、どんなサブモデルが起こりそうかを知るか、又は以前の決定木から開始することによって、構築され得る。

一部の実施形態では、すべてのコンテキスト（又はコンテキストの所定のリスト）が試みられ、どのサブモデルが最大の情報利得を提供するかを判定する。例えば、ロケーションがサブモデルにセグメント化するための最大の情報利得を提供する場合、少なくとも１つの特定のロケーションのサブモデルが作成され得る。セグメント化の各水準では、コンテキストはかかる貪欲な方法でテストされ、どのコンテキストが情報利得の最大の増加を提供するかを判定することができる。

他の実施形態では、セグメント化が適切かどうかをテストするためコンテキストのサブセットが選択される（例えば、擬似ランダムを含む、ランダム選択）。かかる選択は、テストされ得る多くのコンテキストがある場合に、有利となり得る。コンテキストは、どのコンテキストがセグメント化につながりそうかについての確率を使用できる、モンテカルロベースのアプローチを用いて選択され得る。乱数を生成でき（ランダムプロセスの一例）、その後、それを使用して、（特定のプロパティに対して）どのコンテキストをテストするかを判定することができる。

確率は、重み付けがより高いコンテキストが「ランダム」選択プロセスにおいてより選択される可能性が高くなるような、重み付けとして使用することができる。確率は、どのサブモデルが過去に生成されたかに基づいて判定され得る。例えば、ジム（及び潜在的に特定の時間帯が以前は非常にうまくいった）であれば、生成プロセスは、どれくらいの頻度でコンテキストが過去に選ばれたかに応じて、かつ場合により情報利得が過去にどれくらい高かったかにも応じて、９０％、９５％又は９９％の尤度でそのコンテキストを選ぶ。特定数の分割が各水準に対して、又は木生成プロセスの全体に対して試みられるであろう。
Ｖ．確率水準に基づいたアクションの判定

予測モデルは、選択されたアプリケーションに対してだけでなく、特定のアクション、及び潜在的には、メディアコンテンツ（例えば、特定のプレイリスト）に対してテストすることができる。一部の実施形態では、アプリケーションを選択する確率が十分に正確になると、起動するオプションをただ提供するよりも、積極的なアクションが提供され得る。例えば、アプリケーションが起動される場合、コンテンツは自動的に再生することができる。あるいは、アプリケーションは自動的に起動されることができる。

アプリケーションの選択が十分な確率（例えば、信頼水準が高い閾値を超える）で予測されると、その予測はテストアクションを開始することができる。したがって、テストは、アプリケーションの予測のためだけでなく、特定のアクションが十分な精度で予測され得るかをテストするためでもある。可能性のある異なるアクション（メディアアイテムを含む）は履歴データから得ることができる。複数のアクションが、一つのアプリケーションで実行されるように選択され得る。複数のアクションのそれぞれは、第１のサブモデルの複数の異なるサブモデルのうちの１つに対応することができる。複数の異なるサブモデルのそれぞれの信頼水準がテストされ、複数のアクションのうち少なくとも１つに対して第２のサブモデルを生成するかを判定することができる。

したがって、実施形態は、より信頼度が高い場合に、実行されるアクションによって、より積極的になる場合がある。予測モデルは、特定のアクションが実行される確率が高い場合、特定のユーザインタフェースを提供してもよい。こうして、一部の実施形態では、使用確率が高くなるほど、単にアプリケーションを開くための簡単なメカニズムを提供するのではなく、対応するユーザインタフェース（例えば、視覚又は音声コマンド）で自動的にアプリケーションを開くといった、より積極的なアクションを取ることができる。

例えば、ベースモデルは、アクションがロックスクリーン上でアプリケーション（単数又は複数）を提案することであるという特定水準の統計的有意性（精度及び信頼度）を有することができる。他の実施例としては、統計的有意性の水準が高くなると、スクリーンがライトアップされ得る（それによって、そのアプリケーションに注意を促し）、たった１つのアプリケーションが選択され得、又はアプリケーションのユーザインタフェース（ＵＩ）が提供され得る（すなわち、アプリケーションを選択するためのシステムのＵＩではない）。一部の実施形態は、セグメント化するかを判定する際に取られるアクションを考慮してもよく、アクションが失われる場合はセグメント化せず、それは、一般的に情報利得を有することに対応する。

アクションは、モデルが１つのアプリケーションのみを予測するか、それともアプリケーションのグループを予測するかに依存する場合がある。例えば、１つではなく３つの推薦をする機会がある場合、その３つのうち任意の１つを選択すると正確な予測を提供することになるため、確率分布も変更されるであろう。１つのアプリケーションの推薦に対して信頼できなかったモデルが、３つに対して十分に信頼できるものとなり得る。実施形態は、別のアプリケーションをモデルによって予測されるアプリケーション（例えば、グループ内にはまだない、次に最も使用されたアプリケーション）のグループに追加することを実行でき、それによって、モデルをより信頼できるものにすることができる。モデルが２つ以上のアプリケーションの予測に基づく場合、提供されるユーザインタフェースは次いで、２つ以上のアプリケーションとの相互作用を提供することになり、それは、ＵＩの形態に影響する場合がある。例えば、アプリケーションのすべてはロックスクリーン上に提供でき、１つのアプリケーションは自動的に起動しない。

複数のアクション、及び異なるアクションに対する提案も存在する場合がある。例えば、サブモデルの一部として、ジムにおいて２つのプレイリストが存在することができる（例えば、１つのアプリケーションが識別されるが、２つのアクションが、同様の尤度で選択される場合、その２つのアクションが、そのモデル内で識別される）。２つのアクション、別々では統計的有意性を有さないが、合わせると、統計的有意性を有する場合がある。

一実施例として、あるイベント（例えば、ヘッドホンに差し込む）に対するモデルが最初にトレーニングされているときは、モデルはあらゆるアクションを実行するほど十分には信頼できない場合がある。初期水準の信頼度では、アイコン又は他のオブジェクトはロックスクリーン上に表示され得る。より高水準の信頼度では、スクリーンはライトアップしてもよい。更なる水準の信頼度では、アプリケーションの特定の機能に特有のユーザインタフェースが表示され得る（例えば、音楽を再生するコントロール、又は新しいアプリケーションのトップストーリにアクセスするためのスクロールウィンドウ）。次に高い水準は、自動的に起動されるアプリケーションの特定の機能に対応することができる。アクションは、アプリケーションの現在の動作（ある曲を再生する）を別の曲又はプレイリストの再生に換えることさえできる。これらの異なる水準は、信頼水準を規定するのに使用される様々な値とすることができる。

他の例示のアクションは、現在再生中の曲の変更、通知の提供（スクリーンの前面及び中央とすることができる）を含むことができる。アクションは、デバイスのロックを解除した後に発生することができ、例えば、アプリケーションに特有のＵＩをロック解除後に表示することができる。アクションは、アプリケーションの特定の機能を開始するための、ディープリンクを用いて規定することができる。

一部の実施形態はディスプレイスクリーン上でのユーザへの通知を表示してもよい。通知は、例えば、プッシュ通知によって送信されてもよい。通知は、提案されたアプリケーションをユーザに通知する画像及び／又はテキストを含む視覚通知とすることができる。通知は、ユーザが自身が暇なときに選択し実行するように、アプリケーションをユーザに提案することができる。選択されると、アプリケーションが実行されてもよい。一部の実施形態では、より積極的な予測については、通知は提案されたアプリケーション内に提案されたアクションを含むこともできる。つまり、通知は、ユーザに提案されたアプリケーション、並びに提案されたアプリケーション内の提案されたアクションを告知してもよい。こうして、ユーザには、提案されたアプリケーションを実行するか、又は提案されたアプリケーション内の提案されたアクションを実行するオプションが与えられ得る。一例として、通知は、提案されたアプリケーションが音楽アプリケーションであり、提案されたアクションが、その音楽アプリケーション内の特定の曲を再生することであることをユーザに告知することができる。ユーザは、提案された曲を図示するアイコンをクリックすることによって、自身がその曲を再生したいことを示すことができる。あるいは、ユーザは、スクリーン上で通知をスワイプすることによって、むしろ自身が別の曲を再生するようアプリケーションを実行したいことを示すことができる。

提案されたアプリケーション及び提案されたアクションを１つの通知としてユーザインタフェースに出力する以外に、予測エンジンは２つの提案されたアクションを１つの通知としてユーザインタフェースに出力してもよい。例えば、予測エンジンは、第１の曲を再生するよう提案されたアクションを出力し、第２の曲を再生するよう第２の提案されたアクションを出力してもよい。ユーザは、通知内のそれぞれのアイコンをクリックすることによって、どの曲を再生するかを選択することができる。実施形態では、提案されたアクションは、異なる基準に基づいて判定されてもよい。例えば、１つの提案されたアクションは、コンテキスト情報にかかわらず一番最近再生された曲を再生するためのものであってもよいが、他の提案されたアクションは同じ又は同様のコンテキスト情報において、最後に再生された曲を再生するためであってもよい。一例としては、ユーザが自身の車に入って、トリガーイベントにより予測エンジンが特定の曲の再生に関連する２つのアクションを提案する状況では、曲Ａはたまたま家で発生した最後に再生された曲としてもよく、曲Ｂはユーザが前回車の中にいたときに再生された曲としてもよい。ユーザが再生される曲を選択する場合、曲は最初から継続してもよいし、最後に停止されたところ（例えば、曲の途中）から継続してもよい。

予測エンジンがアクションを提案できるように、予測エンジン３５＿３０２はデバイスのアクティブ状態についての情報を記憶するメモリデバイスにアクセスすることができる。デバイスのアクティブ状態は、提案されたアプリケーションの選択に続いて実行されるアクションを表すことができる。例えば、音楽アプリケーションのアクティブ状態は、特定の曲を再生していることとすることができる。アクティブ状態は、曲が最後にいつ停止したかを追跡してもよい。実施形態では、履歴データベースは、デバイスのアクティブ状態に関する履歴データを記録することができる。したがって、予測エンジンは提案されたアプリケーションによって実行されるアクションを提案することができる。
ＶＩ．アーキテクチャ

図３５－７は、１つ以上のアプリケーションと相互作用するためにユーザインタフェースをユーザに提供する例示のアーキテクチャ３５＿７００を示す。アーキテクチャ３５＿７００は、イベントを検出すると共に、アプリケーションに対する提案を提供するための要素を示す。アーキテクチャ３５＿７００はまた、例えば、連絡先を提案するための他の提案を提供することもできる。アーキテクチャ３５＿７００は、ユーザデバイス（例えば、図１Ａ、デバイス１００）内に存在することができる。

上部にはＵＩ要素がある。図に示すようにロックスクリーン３５＿７１０、検索スクリーン３５＿７２０、及び音声インタフェース３５＿７２５がある。これらはユーザインタフェースをユーザに提供できる方法である。他のＵＩ要素も使用することもできる。

下部にはデータソースがある。イベントマネージャー３５＿７４２はイベントを検出しイベントについての情報をアプリケーション提案エンジン３５＿７４０に提供することができる。一部の実施形態では、イベントマネージャーは、イベントがアプリケーションの提案をトリガーするかどうかを判定することができる。アプリケーションの提案をトリガーするための所定のイベントのリストが、特定され得る。ロケーションユニット３５＿７４４は、ユーザデバイスのロケーションを提供することができる。例としては、ロケーションユニット３５＿７４４は、ＧＰＳセンサ及びモーションセンサを含むことができる。ロケーションユニット３５＿７４４はまた、ユーザの最後のロケーションを記憶できる他のアプリケーションも含むことができ、それは、アプリケーション提案エンジン３５＿７４０に送信され得る。他のコンテキストデータは他のコンテキストユニット３５＿７４６から提供され得る。

アプリケーション提案エンジン３５＿７４０は１つ以上のアプリケーション、及び対応するアクションを識別することができる。アプリケーション提案エンジン３５＿７４０と同じ水準で、連絡先提案エンジン３５＿７５０は、ユーザに提示するための提案された連絡先を提供することができる。

提案されたアプリケーションは、ディスプレイセンター３５＿７３０に提供され得、これはユーザに何を提供するかを判定することができる。例えば、ディスプレイセンター３５＿７３０は提案されたアプリケーション又は連絡先を提供するかを判定することができる。他の実施例では、アプリケーション（単数又は複数）及び連絡先（単数又は複数）が提供されてもよい。ディスプレイセンターはユーザに提供するための最良の方法を判定することができる。ユーザへの異なる提案は、異なるＵＩ要素を使用してもよい。このようにして、ディスプレイセンター３５＿７３０はユーザへの提案を制御することができるので、異なるエンジンは、他のエンジンによって提供される提案に割り込まない。各種実施形態では、エンジンは提案（推薦）をディスプレイセンター３５＿７３０にプッシュすることができ、又はディスプレイセンター３５＿７３０からの提案に対する要求を受信することができる。ディスプレイセンター３５＿７３０は、特定量の時間の提案を記憶し、その後、その提案がユーザに提供されなかった場合、又はユーザがユーザインタフェースと相互作用しなかった場合は、その提案を削除するよう判定することができる。

ディスプレイセンター３５＿７３０はまた、他のどんなアクションがユーザデバイスで発生しているかも識別することができ、デバイスにいつ提案を送信するかも識別することができる。例えば、ユーザがアプリケーションを使用している場合は、提案が提供されなくてもよい。ディスプレイセンター３５＿７３０は、例えば、デバイスのモーション状態、ロックスクリーンが１つか、又は認証されたアクセスが提供されたか、ユーザがデバイスを使用しているかなど、様々な要因に基づいて、いつ提案を送信するかを判定することができる。

一部の実施形態では、デバイス１００（図１Ａ）上に含まれるソフトウェアコンポーネントはアプリケーション提案モジュールを含む。アプリケーション提案モジュールは、例えば、図３５－７に上記したように様々なサブモジュール又はシステムを含むことができる。アプリケーション提案モジュールは方法３７＿４００の全部又は一部を実行することができる。
データスパーシティのコンテキストにおける複合ユーザパターンを学習する生成モデルの決定木のセグメント化についての例示の方法、デバイスシステム及びコンピュータ可読媒体

本セクションでは、イベントに基づいて１つ以上のアプリケーションをユーザに提案するシステム、方法及び装置が提供される。予測モデルは、特定のイベントに対応することができる。提案されたアプリケーションは、コンピューティングデバイスの１つ以上のプロパティを用いて判定され得る。例えば、特定のサブモデルは、イベント発生後のユーザ相互作用に関し、かつデバイスが１つ以上のプロパティを有する場合に収集される履歴データのサブセットから生成され得る。サブモデルの木は、コンピューティングデバイスのプロパティの異なるコンテキストに対応して判定されてもよい。また、例えば、履歴データのサブセット内の正確な予測を提供するサブモデル内の信頼水準及び親モデルに対する履歴データの分布内の情報利得（エントロピーの低下）など、様々な基準がサブモデルをいつ生成すべきかを判定するのに使用され得る。

一部の実施形態では、イベントに基づいて１つ以上のアプリケーションをコンピューティングデバイスのユーザに提案するための方法が提供され、この方法は、コンピューティングデバイスにおいて、コンピューティングデバイスの入力デバイスでイベントを検出することであって、このイベントはコンピューティングデバイスに対して繰り返されるタイプのものであることと、イベントに対応する予測モデルを選択することと、コンピューティングデバイスの１つ以上のプロパティを受信することと、１つ以上のプロパティを用いて、１つ以上のプロパティに対応する予測モデルの特定のサブモデルを選択することであって、特定のサブモデルはコンピューティングデバイスとのユーザの過去相互作用の特定のサブセットを用いて生成され、過去相互作用の特定のサブセットは、イベントが検出された後、及びコンピューティングデバイスが１つ以上のプロパティを有する場合に発生することと、特定のサブモデルによって、１つ以上のアプリケーションを識別し、ユーザに提案することであって、１つ以上のアプリケーションはイベントと関連してユーザによってアクセスされる１つ以上のアプリケーションのうちの少なくとも１つの少なくとも閾値確率を有する、ことと、１つ以上のアプリケーションと相互作用するためにユーザインタフェースをユーザに提供することと、を含む。

一部の実施形態では、ユーザインタフェースは、コンピューティングデバイスのホームスクリーン上で提供されるよりも、少ないアプリケーションを有するディスプレイスクリーン上に提供される。一部の実施形態では、特定のサブモデルは信頼度閾値を超える信頼水準で１つ以上のアプリケーションを予測する。一部の実施形態では、方法は、信頼水準に基づいてユーザインタフェースがユーザにどのように提供されるかを判定することを含む。一部の実施形態では、方法は、第１の確率分布を判定すること、及び信頼水準を得るために下限を超えるポイントに対する第１の確率分布の累積分布を計算することによって、信頼水準を判定することを含む。一部の実施形態では、方法は、第１の確率分布を判定すること、及び信頼水準を得るために第１の確率分布の平均値、中央値、又はピーク値を計算することによって、信頼水準を判定することを含む。一部の実施形態では、特定のサブモデルは、予測モデルの正確な予測のための第２の確率分布に対する情報利得を有する過去相互作用の特定のサブセットの正確な予測のための第１の確率分布を提供する。一部の実施形態では、情報利得は、差分閾値を超えるものであり、情報利得はカルバック・ライブラー情報量を用いて判定される。一部の実施形態では、方法は、イベントが検出された後、コンピューティングデバイスとのユーザの過去相互作用のセットを受信することであって、この過去相互作用のセットは過去相互作用の特定のサブセットを含み、かつ過去相互作用の特定のサブセットより大きく、この過去相互作用のセットはコンピューティングデバイスの１つ以上のプロパティの異なるセットを有する相互作用を含む、ことと、予測モデルの初期モデルを用いて、過去相互作用のセットに基づき、イベント後、ユーザがアクセスする１つ以上のアプリケーションを予測するための初期信頼水準を計算することと、コンピューティングデバイスの第１のプロパティを選択すること、コンピューティングデバイスが第１のプロパティを有した場合に発生した過去相互作用の第１サブセットを識別することであって、第１のサブセットが過去相互作用のセットから選択され、かつ過去相互作用のセットより小さいこと、第１のサブモデルを用いて、過去相互作用の第１のサブセットに基づき、イベントと関連してユーザがアクセスする１つ以上のアプリケーションからなる第１のグループのうち、少なくとも１つのアプリケーションを予測するための第１の信頼水準を計算すること、少なくとも閾値量だけ初期信頼水準より大きい第１の信頼水準に基づいて第１のサブモデルを作成すること、及び第１の信頼水準が初期信頼水準以下である場合にテストするための別のプロパティを選択することによって、予測モデルのサブモデルの木を生成することと、を含む。一部の実施形態では、方法は、第１の信頼水準が初期信頼水準以下である場合、別のアプリケーションを１つ以上のアプリケーションからなる第１のグループに追加することと、第１のサブモデルを再びテストすることと、を含む。一部の実施形態では、方法は、更に、コンピューティングデバイスの第２のプロパティを選択すること、コンピューティングデバイスが第１のプロパティ及び第２のプロパティを有した場合に発生した過去相互作用の第２のサブセットを識別することであって、第２のサブセットが過去相互作用の第１のサブセットから選択され、かつ過去相互作用の第１のセットより小さいこと、第２のサブモデルを用いて、過去相互作用の第２のサブセットに基づいて、イベントと関連してユーザがアクセスする１つ以上のアプリケーションからなる第２のグループのうち、１つのアプリケーションを予測するための第２の信頼水準を計算すること、少なくとも閾値量だけ第１の信頼水準より大きい第２の信頼水準に基づいて第２のサブモデルを作成すること、及び第２の信頼水準が第１の信頼水準以下である場合にテストするための第３のプロパティを選択することによって、予測モデルのサブモデルの木を生成することと、を含む。一部の実施形態では、予測モデルのサブモデルの木は定期的に生成される。一部の実施形態では、第１のプロパティは、ランダムプロセスを用いて選択される。一部の実施形態では、１つ以上のアプリケーションからなる第１のグループは１つのアプリケーションであり、方法は、この１つのアプリケーションで実行される複数のアクションを選択することであって、複数のアクションのそれぞれは第１のサブモデルの複数の異なるサブモデルのうち１つに対応することと、複数の異なるサブモデルのそれぞれの信頼水準をテストし、複数のアクションのうち少なくとも１つに対して第２のサブモデルを生成するかを判定することと、を含む。

一部の実施形態では、イベントに基づいて１つ以上のアプリケーションをコンピューティングデバイスのユーザに提案するための複数の命令を記憶し、コンピュータシステムの１つ以上のプロセッサ上で実行されると、コンピューティングデバイスの入力デバイスでイベントを検出することであって、このイベントはコンピューティングデバイスに対して繰り返されるタイプのものであることと、イベントに対応する予測モデルを選択することと、コンピューティングデバイスの１つ以上のプロパティを受信することと、１つ以上のプロパティを用いて、１つ以上のプロパティに対応する予測モデルの特定のサブモデルを選択することであって、特定のサブモデルはコンピューティングデバイスとのユーザの過去相互作用の特定のサブセットを用いて生成され、このユーザの過去相互作用の特定のサブセットはイベントが検出された後、及びコンピューティングデバイスが１つ以上のプロパティを有する場合に発生することと、特定のサブモデルによって、１つ以上のアプリケーションを識別し、ユーザに提案することであって、１つ以上のアプリケーションはイベントと関連してユーザによってアクセスされる１つ以上のアプリケーションのうちの少なくとも１つの少なくとも閾値確率を有することと、１つ以上のアプリケーションに対してアクションを実行することと、を実行する、非一時的コンピュータ可読記憶媒体を含むコンピュータ製品が提供される。一部の実施形態では、特定のサブモデルは、信頼度閾値を超える信頼水準で１つ以上のアプリケーションを予測し、この特定のサブモデルは、予測モデルの正確な予測のための第２の確率分布に対する情報利得を有する、過去相互作用の特定のサブセットの正確な予測のための第１の確率分布を提供する。一部の実施形態では、アクションは、１つ以上のアプリケーションと相互作用するためにユーザインタフェースをユーザに提供している。

一部の実施形態では、イベントに基づいて１つ以上のアプリケーションをコンピューティングデバイスのユーザに提案するためのコンピューティングデバイスが提供され、このコンピューティングデバイスは、入力デバイスと、コンピューティングデバイスの入力デバイスで、コンピューティングデバイスに対して繰り返されるタイプのイベントを検出し、イベントに対応する予測モデルを選択し、コンピューティングデバイスの１つ以上のプロパティを受信し、１つ以上のプロパティを用いて、１つ以上のプロパティに対応する予測モデルの特定のサブモデルを選択することであって、特定のサブモデルはコンピューティングデバイスとのユーザの過去相互作用の特定のサブセットを用いて生成され、過去相互作用の特定のサブセットはイベントが検出された後、及びコンピューティングデバイスが１つ以上のプロパティを有する場合に発生し、特定のサブモデルによって、１つ以上のアプリケーションを識別し、ユーザに提案することであって、１つ以上のアプリケーションはイベントと関連してユーザによってアクセスされる１つ以上のアプリケーションのうちの少なくとも１つの少なくとも閾値確率を有し、かつ１つ以上のアプリケーションと相互作用するためにユーザインタフェースをユーザに提供するように構成された１つ以上のプロセッサと、を備える。一部の実施形態では、特定のサブモデルは、信頼度閾値を超える信頼水準で１つ以上のアプリケーションを予測し、この特定のサブモデルは、予測モデルの正確な予測のための第２の確率分布に対する情報利得を有する過去相互作用の特定のサブセットの正確な予測のための第１の確率分布を提供する。一部の実施形態では、１つ以上のプロセッサは、イベントが検出された後、コンピューティングデバイスとのユーザの過去相互作用のセットを受信することであって、この過去相互作用のセットは過去相互作用の特定のサブセットを含み、かつ過去相互作用の特定のサブセットより大きく、この過去相互作用のセットはコンピューティングデバイスの１つ以上のプロパティの異なるセットを有する相互作用を含み、予測モデルの初期モデルを用いて、過去相互作用のセットに基づいて、イベント後、ユーザがアクセスする１つ以上のアプリケーションを予測するための初期信頼水準を計算し、コンピューティングデバイスの第１のプロパティを選択すること、コンピューティングデバイスが第１のプロパティを有した場合に発生した過去相互作用の第１サブセットを識別することであって、第１のサブセットが過去相互作用のセットから選択され、かつ過去相互作用のセットより小さいこと、第１のサブモデルを用いて、過去相互作用の第１のサブセットに基づいて、イベントと関連してユーザがアクセスすることになる１つ以上のアプリケーションからなる第１のグループのうち、少なくとも１つのアプリケーションを予測するための第１の信頼水準を計算すること、少なくとも閾値量だけ初期信頼水準より大きい第１の信頼水準に基づいて第１のサブモデルを作成すること、及び第１の信頼水準が初期信頼水準以下である場合にテストするための別のプロパティを選択することによって、予測モデルのサブモデルの木を生成する、ように更に構成される。
セクション６：検出されたトリガーイベントに基づくアプリケーションの推薦

本セクションの「検出されたトリガーイベントに基づくアプリケーションの推薦」という題材は、一部の実施形態による検出されたトリガーイベントに基づくアプリケーションの推薦を記載し、本明細書で提供された開示を補足する情報を提供する。例えば、本セクションの一部は、トリガーイベント（ヘッドホンをデバイスに差し込む、またユーザの現在のロケーションに応じて異なるアプリケーションを提案する）に基づく、使用するアプリケーションの推薦を記載し、本明細書で提供される開示、例えば、図９Ｂ～図９Ｃの予測部分９３０内の予測されたコンテンツをポピュレートすることに関すること、及びトリガー条件（図４Ａ～図４Ｂ）の作成及び検出に関することを補足する。一部の実施形態では、本セクションに記載される予測モデルは、予測及びユーザに表示するための適切なアプリケーションの識別を支援するのに用いられる（すなわち、これらの予測モデルは、方法６００、８００、１０００及び１２００と併せて用いられる）。
検出されたトリガーイベントに基づくアプリケーションの推薦についての概要

実施形態は、トリガーイベントに基づいてアプリケーションを推薦するための改良されたデバイス及び方法を提供する。例えば、特定のイベントは、デバイスによって検出でき、トリガーイベントとして識別できる。異なるトリガーイベントは、異なる予測モデルを有することができ、これにより、より正確な推薦を可能にすることができる。選択された予測モデルは、（例えば、イベントが検出される前又は検出された後に収集された）コンテキスト情報を用いて、例えば、ロックスクリーン上でアクセスを可能にするといった、より簡単にアクセスできるようにユーザに提示するためのアプリケーションを識別することができる。

一部の実施形態では、１つ以上の入力デバイスはトリガーイベントについて監視される。トリガーイベントが検出されると、コンテキスト情報は、１つ以上のソース（例えば、コンテキスト情報を既に得たデバイスの別のアプリケーション）から集めることができる。コンテキスト情報は、ロケーション又は時間帯などの、トリガーイベントの発生時の、又はその近くでのデバイスのコンテキストに関連してもよい。コンテキスト情報が受信されると、その後、履歴情報は履歴イベントデータベースから集められてもよい。データベースは、ユーザとデバイスとの間の過去相互作用の記録を維持することができる。トリガーイベントに照らして、コンテキスト情報及び履歴情報はユーザに対する１つ以上のアプリケーションのセットを識別するように利用されてもよい。その後、識別されたアプリケーションは、どのように、いつ、又はどこで識別されたアプリケーションが普通にアクセスされるより異なる方法（例えば、ホームスクリーン上で）でユーザインタフェースを提供することでユーザに提案されてもよく、それによって、所望であれば、ユーザにアプリケーションを実行するオプションを与える。

他の実施形態は本セクションに記載の方法に関連付けられたシステム、ポータブル家庭用デバイス及びコンピュータ可読媒体を対象とする。

以下の詳細な説明及び添付の図面を参照することにより、本発明の実施形態の性質及び利点の理解をより深めることができる。
検出されたトリガーイベントに基づくアプリケーションの推薦についての詳細な説明

現在のモバイルデバイスは、そのソリッドステートドライブ上に記憶された多くのアプリケーションを有することができる。一部の場合には、モバイルデバイスは、そのソリッドステートドライブ上に記憶された数百個のアプリケーションを有することができる。ユーザが自身のモバイルデバイス上でアプリケーションを実行したい場合、ユーザは、デバイスのロックを解除し、デバイス内のアプリケーションのすべてを検索し、所望のアプリケーションを識別し、その後、アプリケーションの実行を開始しなければならない。所望のアプリケーションを見つけるプロセスを経ることは、特に他よりも頻繁に繰り返し使用されるアプリケーションについてはひどく時間がかかり冗長となる場合がある。

ユーザは、デバイスを事前にプログラムして、特定の条件が満たされた（例えば、トリガーイベントが発生した）場合は所定のアプリケーションの特定のアクションを自動的に実行することができる。例えば、デバイスは、トリガーイベントが発生した場合に所定のアプリケーションを提案するようにプログラムされてもよい。しかし、かかる操作は静的であり、ユーザによる構成を必要とする。

自動的に所定のアプリケーションを提案する代わりに、本発明の実施形態は予測モデルを利用して、トリガーイベントが発生したときにユーザによって実行されそうな所与のコンテキストでアプリケーションを提案することができる。異なるアプリケーションは、同じトリガーイベントの異なるコンテキストに対して識別されてもよい。一実施例としては、１つのアプリケーションは第１のコンテキストで提案され得るが、別のアプリケーションは第２のコンテキストで提案され得る。

ユーザが使用しそうなアプリケーションを識別するのはいくつかの利益を有する。ユーザインタフェースは、時間を節約しデバイス操作を合理化できるふさわしい方法で、又はふさわしいスクリーンでユーザに提供することができる。ユーザは、使用するアプリケーションを識別するために多数のアプリケーションの中から検索する必要はない。アプリケーションのユーザインタフェースは、様々な方法で提供され得、それは、ユーザがアプリケーションを使用する可能性がどれほど高いかに依存し得る。更に、予測モデルは、特定のアクションが実行される確率が高い場合、特定のユーザインタフェースを提供してもよい。こうして、一部の実施形態では、使用確率が高くなるほど、単にアプリケーションを開くための簡単なメカニズムを提供するのではなく、対応するユーザインタフェース（例えば、視覚又は音声コマンド）で自動的にアプリケーションを開くといった、より積極的なアクションを取ることができる。
ＶＩＩ．アプリケーションの予測

実施形態はトリガーイベントに基づいてアプリケーションを提案することができる。例えば、音楽アプリケーションは、ヘッドホンがヘッドホンジャックに挿入されたときに提案される場合がある。一部の実施形態では、コンテキスト情報は、ユーザに提案するアプリケーションを識別するトリガーイベントと併せて使用され得る。一例として、ヘッドホンのセットがヘッドホンジャックに挿入された場合、ロケーションに関連するコンテキスト情報が使用されてもよい。例えば、デバイスがジムにある場合、ヘッドホンがヘッドホンジャックに挿入されているときにアプリケーションＡが提案されてもよい。あるいは、デバイスが自宅にある場合、ヘッドホンがヘッドホンジャックに挿入されているときにアプリケーションＢが提案されてもよい。したがって、特定のコンテキストの下で使用されそうなアプリケーションを、ちょうどよい時刻に提案できるので、ユーザエクスペリエンスを向上させることができる。

図３６－１は、本発明の実施形態に係る、トリガーイベントに基づいてアプリケーションを提案するための方法３６＿１００のフローチャートである。方法１００を、モバイルデバイス（例えば、電話機、タブレット）又は非モバイルデバイスによって実行することができ、またその方法は、デバイスの１つ以上のユーザインタフェースを利用することができる。

ブロック３６＿１０２では、トリガーイベントが検出される。デバイスで発生し得るすべてのイベントがトリガーイベントとは限らない。トリガーイベントは、デバイスの固有動作に相関する可能性が十分あるものとして識別され得る。トリガーイベントであるイベントのリストはデバイスに記憶され得る。かかるイベントは既定のリストとすることができ、オペレーティングシステムの一部として維持され得、ユーザによって構成変更できてもよいし、構成変更できなくてもよい。

トリガーイベントは、ユーザ及び／又は外部デバイスに誘導されたイベントとすることができる。例えば、トリガーイベントは、アクセサリデバイスがモバイルデバイスに接続された場合とすることができる。例としては、ヘッドホンのヘッドホンジャックへの挿入、Ｂｌｕｅｔｏｏｔｈ接続などが挙げられる。本例では、これらのそれぞれは、異なるトリガーイベントとして分類され得、又はトリガーイベントはまとめて、任意のアクセサリデバイスがモバイルデバイスに接続することとすることができる。他の例としては、トリガーイベントは、デバイスとのユーザの特定の相互作用とすることができる。例えば、ユーザは、モバイルデバイスをランニングと調和した方法で移動させることができ、この場合、デバイスのランニング状態はトリガーイベントである。かかるランニング状態（又は他の状態）は、デバイスのセンサに基づいて判定され得る。

ブロック３６＿１０４では、トリガーイベントに関連付けられたアプリケーションが識別される。一例として、音楽アプリケーションは、ヘッドホンがヘッドホンジャックに挿入されたときに識別される場合がある。一部の実施形態では、２つ以上のアプリケーションが識別され得る。予測モデルは、関連アプリケーションを識別することができ、この場合、予測モデルは特定のトリガーイベントに対して選択されてもよい。例えば、異なるアプリケーションは異なるコンテキストで使用される可能性が高いので、予測モデルはコンテキスト情報を用いてアプリケーションを識別することができる。一部の実施形態は、例えば、デバイスとのユーザの過去相互作用から判定して、ユーザによって選択されるという十分な可能性がある場合しかアプリケーションを識別できない。様々なタイプの予測モデルを使用することができる。予測モデルの例としては、ニューラルネットワーク、決定木、マルチラベルロジスティック回帰、及びそれらの組み合わせが挙げられる。

ブロック３６＿１０６では、アプリケーションと関連してアクションが行われる。一実施形態では、アクションは、ユーザがアプリケーションを実行するように選択するためのユーザインタフェースを提供することとすることができる。ユーザインタフェースは、デバイスのスクリーン上に表示すること、表面に投影すること、あるいはオーディオインタフェースを提供することなど、様々な方法で提供されてもよい。

他の実施形態では、アプリケーションが実行されてもよく、アプリケーション固有のユーザインタフェースがユーザに提供されてもよい。例えば、ロックスクリーン上でのアプリケーションの識別に応答してユーザインタフェースのどちらかを提供してもよい。他の実装形態では、アプリケーションと相互作用するためのユーザインタフェースは、ユーザが（例えば、パスワード又はバイオメトリックによって）認証された後に提供されてもよい。ユーザインタフェースが表示されると、かかるユーザインタフェースは単なるホームスクリーンより具体的となり、すなわち、実行するための提案されたアプリケーションのリストは、ホームスクリーン上におけるより小さくなる。ユーザインタフェースは、トリガーイベントが検出された後、デバイスのディスプレイ上に即座に表示されてもよい。他の実施形態では、ユーザインタフェースはユーザがいくつかの入力（例えば、１つ以上のクリックジェスチャ）を提供した後に表示されてもよく、それは、アプリケーションが提案されなかった場合より、依然としてユーザ入力（例えば、クリック数）が少ない場合がある。
ＶＩＩＩ．予測を開始するイベント

トリガーイベントは、ユーザに提供するための１つ以上のアプリケーションの識別をトリガーするイベントの所定のセットとすることができる。イベントはデバイスコンポーネントによって生成された信号を用いて検出することができる。どのようにトリガーイベントが検出されるかの更なる詳細は本セクションで更に詳細に検討する。

図３６－２は本発明の実施形態に係る、トリガーイベントを判定する検出システム３６＿２００の簡略ブロック図を図示する。検出システム３６＿２００はトリガーイベントが判定されているデバイス内に常駐することができる。図示するように、検出システム３６＿２００は複数の異なるイベントを検出することができる。検出されたイベントのうちの１つ以上は、検出システム３６＿２００によってトリガーイベントであることを判定され得る。その後、他の処理モジュールはトリガーイベントを用いて処理を実行することができる。
Ａ．イベントの検出

実施形態では、検出システム３６＿２００は、イベントを検出するためのハードウェア及びソフトウェアコンポーネントを含む。一実施例としては、検出システム３６＿２００は、入力デバイス３６＿２０２などの複数の入力デバイスを含むことができる。入力デバイス３６＿２０２はイベントに応答して信号を生成可能な任意の好適なデバイスとすることができる。例えば、入力デバイス３６＿２０２はデバイス接続入力デバイス３６＿２０４、ユーザ相互作用入力デバイス３６＿２０６、及びロケーション入力デバイス３６＿２０８を含むことができ、それらはそれぞれ、デバイス接続イベント、ユーザ相互作用イベント、及びロケーションのイベントを検出することができる。イベントが入力デバイスで検出されると、入力デバイスは、更に分析するために特定のイベントを示す信号を送信することができる。

一部の実施形態では、コンポーネントの集合は、単一のイベントに寄与することができる。例えば、モーションセンサ及びＧＰＳロケーションデバイスに基づいて人がランニングしていると検出され得る。
１．デバイス接続イベント

デバイス接続イベントは他のデバイスがデバイスに接続されたときに発生するイベントとすることができる。例えば、デバイス接続入力デバイス３６＿２０４は、デバイスがデバイスに通信可能に連結されるイベントを検出することができる。有線又は無線接続を外部デバイスと形成する任意の好適なデバイスコンポーネントがデバイス接続入力デバイス３６＿２０４として使用される場合がある。デバイス接続入力デバイス３６＿２０４の例としては、ヘッドホンジャック３６＿２１０及び、データ接続３６＿２１２、例えば、無線接続回路（例えば、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉなど）又は有線接続回路（例えば、イーサネットなど）が挙げられる。

ヘッドホンジャック３６＿２１０はヘッドホンのセットがデバイスに連結するのを可能にする。例えば、ヘッドホンがヘッドホンジャック３６＿２１０に挿入されて電気的接続を作成することによってヘッドホンが連結されるときに、信号が生成され得る。より複雑な実施形態では、ヘッドホンジャック３６＿２１０は、ヘッドホンジャックのタイプを識別する識別信号をデバイスに提供する回路を含むことができる。こうして、イベントは様々な方法で検出され得、また信号は様々な方法で生成かつ／又は通信され得る。

データ接続３６＿２１２は、例えば、無線接続を介して通信可能に外部デバイスと連結することができる。例えば、Ｂｌｕｅｔｏｏｔｈ接続は車両のコンピュータ、又は無線ヘッドセットのコンピュータに連結される場合がある。したがって、外部デバイスがデータ接続３６＿２１２を介してモバイルデバイスに連結されると、外部デバイスは接続されたと判定され得、対応するデバイス接続イベント信号が生成され得る。
２．ユーザ相互作用イベント

ユーザ相互作用入力デバイス３６＿２０６はユーザ相互作用イベントを検出するよう利用され得る。ユーザ相互作用イベントはユーザがデバイスと相互作用したときに発生する場合がある。一部の実施形態では、ユーザは、ユーザ相互作用入力デバイス３６＿２０６のうちの１つを介して表示されたユーザインタフェースを直接アクティブにすることができる。他の実施形態では、ユーザインタフェースは表示されなくてもよいが、依然として、例えば、ユーザがデバイスを振る、又はいくつかの他の種類のジャスチャを行うことによって、ユーザによりアクセス可能である。更に、相互作用は、例えば、状態エンジンがデバイスのセンサからの値を使用する場合は、ユーザインタフェースを含まなくてもよい。

ユーザインタフェースの任意の好適なデバイスコンポーネントは、ユーザ相互作用入力デバイス３６＿２０６として使用され得る。好適なユーザ相互作用入力デバイスの例は、ボタン３６＿２１４（例えば、ホームボタン又は電源ボタン）、タッチスクリーン３６＿２１６、及び加速度計３６＿２１８である。例えば、ホームボタン、電源ボタン、音量ボタンなどのモバイルデバイスのボタン３６＿２１４は、ユーザ相互作用入力デバイス３６＿２０４とすることができる。それに加えて、サイレントモードスイッチなどのスイッチは、ユーザ相互作用入力デバイス３６＿２０４とすることができる。ユーザがデバイスと相互作用する場合、ユーザがユーザ入力を提供したと判定されてもよく、また対応するユーザ相互作用イベントが生成されてもよい。かかるイベントは、デバイスの現在の状態、例えば、デバイスが朝（又は、他の、長期間にわたって非アクティブであるときに）、最初にオンされたとき、又はアクティブにされるときに依存する場合がある。かかる情報はまた、イベントがトリガーイベントかどうかを判定する際に使用される場合がある。

タッチスクリーン３６＿２１６はユーザがディスプレイスクリーンを介してユーザ入力を提供するのを可能にすることができる。例えば、ユーザは、ディスプレイ上で自身の指をスワイプしてユーザ入力信号を生成することができる。ユーザがアクションを実行する場合、対応するユーザ相互作用イベントは削除されてもよい。

加速度計３６＿２１８又は他のモーションセンサは、（例えば、ジャイロメーター又はコンパスを用いて）振動する及び傾く、などのモバイルデバイスの動きを検出するパッシブコンポーネントとすることができる。モバイルデバイスのかかる動きは、その動きが特定のタイプのものかを判定できるイベントマネージャー３６＿２３０によって検出することができる。イベントマネージャー３６＿２３０は、デバイスの所与の状態における特定のタイプのユーザ相互作用イベントに対応するイベント信号３６＿２３２を生成することができる。デバイスの状態は、状態エンジンによって判定でき、その更なる詳細は、「Ａｃｔｉｖｉｔｙ Ｄｅｔｅｃｔｉｏｎ」と題する米国特許公開第２０１２／０３１０５８７号、及び「Ｄｅｔｅｒｍｉｎｉｎｇ Ｅｘｉｔ Ｆｒｏｍ Ａ Ｖｅｈｉｃｌｅ」と題する米国特許公開第２０１５／００５０９２３号に見られ、その開示は全体が参照により組み込まれる。

一例は、ユーザがランニングしている場合であり、加速度計は振動を感知し、イベントマネージャー３６＿２３０に提供される信号を生成することができる。イベントマネージャー３６＿２３０は加速度計信号を分析し、イベントのタイプを判定することができる。イベントの種類が判定されると、イベントマネージャー３６＿２３０はイベントのタイプに対応するイベント信号３６＿２３２を生成することができる。モバイルデバイスはまた、ユーザがランニングしていることを示すような方法で移動することができる。こうして、この特定のユーザ相互作用はランニングイベントとして識別され得る。その後、イベントマネージャー３６＿２３０はランニングイベントが検出されたことを示すイベント信号３６＿２３２を生成及び送信することができる。
３．ロケーションイベント

ロケーション入力デバイス３６＿２０８はロケーションイベントを生成するのに使用され得る。任意の好適な測位システムはロケーションイベントを生成するのに使用され得る。例えば、全地球測位システム（ＧＰＳ）はロケーションイベントを生成するのに使用され得る。ロケーションイベントは特定の地理的ロケーションに対応するイベントとすることができる。一実施例としては、モバイルデバイスが特定のロケーションに到着した場合、ＧＰＳコンポーネントはロケーションイベントに対応する入力信号を生成することができる。典型的には、モバイルデバイスは一日当たり数十又は更に数百のロケーションまで移動する場合があり、それらの多くはロケーションイベントとして考えられるほど重要でない場合がある。したがって、すべての検出されたロケーションがロケーションイベントとあるとはでは限らない。実施形態では、ロケーションイベントは他よりも頻繁に起こるロケーションとすることができる。例えば、イベントは、ある期間に少なくとも閾値回数、例えば、６ヶ月間から１年間で５回と、頻繁に起こる場合、ロケーションイベントとすることができる。したがって、重要なロケーションは重要でないロケーションから分離され、ロケーションイベントであると判定されてもよい。
Ｂ．トリガーイベントの判定

図３６－２に更に図示するように、入力デバイス３６＿２０２は、例えば、対応するイベントのいずれかの結果として検出されたイベント３６＿２２２を出力することができる。検出されたイベントは、どの入力デバイスが検出されたイベント３６＿２２２の信号、特定のイベントのサブタイプ（例えば、ヘッドホン又はデータ接続がどのタイプか）を送信しているかについての情報を含むことができる。かかる情報は、検出されたイベント３６＿２２２はトリガーイベントであるかどうかを判定するのに使用してもよく、どの予測モデルを使用するか、又は提案されたアプリケーションに対してどのアクションを実行するかを判定するため、後のモジュールに渡すことができる。

検出されたイベント３６＿２２２はイベントマネージャー３６＿２３０によって受信され得る。イベントマネージャー３６＿２３０は入力デバイス３６＿２０２から信号を受信でき、どんなタイプのイベントが検出されたかを判定することができる。イベントのタイプに応じて、イベントマネージャー３６＿２３０は信号（例えば、イベント信号３６＿２３２）を異なるエンジンに出力することができる。異なるエンジンは、その機能にとって重要である特定のイベント信号３６＿２３２を受信するようイベントマネージャー３６＿２３０によりサブスクリプション（subscription）を有してもよい。例えば、トリガーイベントエンジン３６＿２２４は、入力デバイス３６＿２０２からの検出されたイベント３６＿２２２に応答して生成されたイベント信号３６＿２３２を受信するようにサブスクライブされてもよい。イベント信号３６＿２３２は検出されたイベント３６＿２２２から判定されたイベントのタイプに対応することができる。

トリガーイベントエンジン３６＿２２４は、検出されたイベント３６＿２２２がトリガーイベントであるかどうかを判定するように構成されてもよい。この判定を行うには、トリガーイベントエンジン３６＿２２４は、指定されたトリガーイベントデータベース３６＿２２６を参照することができ、それは、トリガーイベントエンジン３６＿２２４に連結され得る。指定されたトリガーイベントデータベース３６＿２２６はトリガーイベントとして指定された所定のイベントのリストを含むことができる。

トリガーイベントエンジン３６＿２２４は受信した検出されたイベント３６＿２２２を所定のイベントのリストと比較して、検出されたイベント３６＿２２２が指定されたトリガーイベントデータベース３６＿２２６内にリストされた所定のイベントと一致する場合、トリガーイベント３６＿２２８を出力することができる。所定のイベントのリストの例としては、以下の任意の１つ以上を含むことができる。（１）ヘッドホンをヘッドホンジャックに挿入すること、（２）Ｂｌｕｅｔｏｏｔｈ接続を介して外部デバイスを接続すること、（３）ある期間が経過した後（例えば、朝起きたときに）、ボタンを押すこと、（４）デバイスの特定のタイプの動きを感知すること、及び（５）特定のロケーションに到着すること。（５）については、指定されたトリガーイベントデータベース２２６は特定のロケーションの明細を含むことができる。

本セクションで記載したように、本技術の一態様は、ユーザにアプリケーションを提案するために、様々なソースから利用可能なデータを収集かつ使用することである。本開示は、場合によっては、この収集されたデータが、特定の人を一意的に識別するか、又はその人に連絡するか、若しくはその人のロケーションを特定するために用いられ得る個人情報データを含み得ることを企図している。このような個人情報データは、ロケーションに基づくデータ、自宅住所、又は任意のその他の識別情報を含むことができる。

本開示は、本技術における、このような個人情報データの使用は、ユーザの利益のために使用することができると認識している。例えば、個人情報データは、よりユーザの興味を引く、アプリケーションを提案するために用いられてもよい。したがって、このような個人情報データの使用は、配信されるコンテンツの意図的な制御を可能にする。更に、ユーザに利益をもたらす個人情報データの他の使用法も、本開示によって企図されている。

本開示は、このような個人情報データの収集、分析、開示、転送、記憶、又はその他の使用に関与するエンティティは、しっかり確立されたプライバシーポリシー及び／又はプライバシー慣行を遵守することを更に企図している。具体的には、そのようなエンティティは、個人情報データを秘密として厳重に保守するための業界又は政府の要件を満たすか又は上回るものとして一般に認識されている、プライバシーのポリシー及び慣行を実施し常に使用すべきである。例えば、ユーザからの個人情報は、そのエンティティの合法的かつ正当な使用のために収集されるべきであり、それらの合法的使用を除いて、共有又は販売されるべきではない。更に、そのような収集は、ユーザに告知して同意を受けた後にのみ実施するべきである。更に、そのようなエンティティは、そのような個人情報へのアクセスを保護して安全化し、その個人情報へのアクセスを有する他者が、自身のプライバシーポリシー及び手順を遵守することを保証するための、あらゆる必要な措置を講じることとなる。更には、そのようなエンティティは、広く受け入れられているプライバシーのポリシー及び慣行に対する自身の遵守を証明するために、第三者による評価を自らが受けることができる。

前述のことがらにもかかわらず、本開示はまた、ユーザが、個人情報データの使用又は個人情報データへのアクセスを選択的に阻止する実施形態も企図している。すなわち、本開示は、そのような個人情報データへのアクセスを防止又は阻止するためのハードウェア要素及び／又はソフトウェア要素を提供することができることを企図している。別の実施例では、ユーザは、的を絞ったコンテンツ配信サービスのために位置情報を提供しないことを選択することができる。更に別の例では、ユーザは正確な位置情報を提供しないが、位置領域情報の転送を許可することを選択することができる。
ＩＸ．提案されたアプリケーションの判定

トリガーイベントが検出されると、アプリケーションはトリガーイベントに基づいて識別され得る。一部の実施形態では、アプリケーションの識別は、事前にプログラムされたアクションではない。逆に、アプリケーションの識別は、追加情報に応じて変化し得る動的なアクションとすることができる。例えば、提案されたアプリケーションの識別は、コンテキスト情報及び／又は履歴情報に基づいて、並びに他の情報に基づいて判定され得る。
Ａ．トリガーイベントに基づいてアプリケーションを判定するシステム

図３６－３は、本発明の実施形態に係る、トリガーイベント及びコンテキスト情報に基づいてアプリケーション及び対応するアクションコマンドを識別する予測システム３６＿３００の簡略ブロック図を図示する。予測システム３６＿３００はアプリケーションを識別しているデバイス内に常駐する。予測システム３６＿３００はハードウェア及びソフトウェアコンポーネントを含むことができる。

予測システム３６＿３００は提案されたアプリケーションを識別する予測エンジン３６＿３０２を含む。予測エンジン３６＿３０２は、図３６－２で検討されたトリガーイベント３６＿２２８などのトリガーイベントを受信することができる。予測エンジン３６＿３０２は、提案されたアプリケーション３６＿３０４を識別するため、トリガーイベント３６＿２２８から収集された情報を使用してもよい。図示するように、予測エンジン３６＿３０２は、トリガーイベント３６＿２２８に加えてコンテキストデータ３６＿３０６を受信することができる。予測エンジン３６＿３０２は、提案されたアプリケーション３６＿３０４を識別するため、トリガーイベント３６＿２２８及びコンテキスト情報３６＿３０６の両方から収集された情報を使用してもよい。予測エンジン３６＿３０２はまた、実行されるアクション、例えば、ユーザインタフェースが、提案されたアプリケーションと相互作用するために、ユーザに対して、どのように、かついつ提供されるかを判定することもできる。

特定の実施形態では、提案されたアプリケーション３６＿３０４はモバイルデバイスのソリッドステートドライブ上に存在する任意のアプリケーションとすることができる。こうして、予測エンジン３６＿３０２は、トリガーイベントが検出されたとき、任意のアプリケーションを提案する能力を有することができる。あるいは、実施形態では、予測エンジン３６＿３０２は、トリガーイベントが検出されたとき、すべてではないアプリケーションを提案する能力を有することができる。例えば、ユーザは、予測エンジン３６＿３０２がアクセスできないいくつかのアプリケーションを選択してもよい。こうして、予測エンジン３６＿３０２は、トリガーイベントが検出されたとき、これらのアプリケーションを提案できない場合もある。
１．コンテキスト情報

コンテキスト情報はコンテキストデータ３６＿３０６から収集することができる。実施形態では、コンテキスト情報はいつでも受信することができる。例えば、コンテキスト情報はトリガーイベント３６＿２２８が検出される前及び／又は検出された後に受信することができる。また、コンテキスト情報は、トリガーイベント３６＿２２８を検出中に受信してもよい。コンテキスト情報は特定のコンテキストに対してデバイスの１つ以上のプロパティを特定することができる。コンテキストは、トリガーイベント３６＿２２８が検出されたときのデバイスの周囲の環境（コンテキストのタイプ）としてもよい。例えば、コンテキスト情報はトリガーイベント３６＿２２８が検出されたときの時間帯としてもよい。別の実施例では、コンテキスト情報は、トリガーイベント３６＿２２８が検出されたときのデバイスの特定のロケーションとしてもよい。更に別の実施例では、コンテキスト情報は、トリガーイベント３６＿２２８が検出されたときの年の特定の日としてもよい。また、コンテキスト情報は、カレンダーから収集されたデータとしてもよい。例えば、現在時刻とイベント時刻との間の時間（数日又は数時間）。かかるコンテキスト情報は、予測エンジン３６＿３０２が正確にそのコンテキストでユーザによって使用される可能性のあるアプリケーションを提案できるようにデバイスのコンテキストについてのより有意義な情報を提供してもよい。したがって、コンテキスト情報を利用する予測エンジン３６＿３０２は、コンテキスト情報が利用されない場合より正確にアプリケーションをユーザに提案することができる。

コンテキストデータ３６＿３０６はコンテキストソース３６＿３０８によって生成され得る。コンテキストソース３６＿３０８は、モバイルデバイスの現在の状況に関するデータを提供するモバイルデバイスのコンポーネントとすることができる。例えば、コンテキストソース３６＿３０８は、時間帯、デバイスのロケーション、及び日付にそれぞれ関連する情報を提供するための内部デジタル時計３６＿３１０、ＧＰＳデバイス３６＿３１２、及びカレンダー３６＿３１４として動作するハードウェアデバイス及び／又はソフトウェアコードとすることができる。他のコンテキストソースが使用されてもよい。

予測エンジン３６＿３０２に対するコンテキストデータ３６＿３０６の収集は、電力効率的な方法で実行されてもよい。例えば、デバイスのロケーションを判定するためのＧＰＳ３６＿３１２の継続的なポーリングは、過度に電力を消費し、バッテリ寿命を低下させる場合がある。バッテリ寿命の低下を回避するため、予測エンジン３６＿３０２は、ＧＰＳ３６＿３１２以外のソースからデバイスのロケーションを要求することによってデバイスのロケーションを判定することができる。ロケーション情報の別のソースは、最近、デバイスのロケーションを求めてＧＰＳ３６＿３１２をポーリングしたアプリケーションとすることができる。例えば、アプリケーションＡがデバイスのロケーションを求めてＧＰＳ３６＿３１２をポーリングした一番最近のアプリケーションである場合、予測エンジン３６＿３０２は、別々にＧＰＳ３６＿３１２をポーリングするのではなく、アプリケーションＡからロケーションデータを要求かつ受信することができる。
２．履歴情報

コンテキストソース３６＿３０８に加えて、履歴イベントデータベース３６＿３１６も、特定の実施形態における予測エンジン３６＿３０２によって利用されてもよい。履歴イベントデータベース３６＿３１６は、トリガーイベントが検出された後のユーザとモバイルデバイスとの間の前の相互作用からなる履歴情報を含むことができる。

履歴イベントデータベース３６＿３１６は、特定のトリガーイベントに続いてアプリケーションが開かれた回数の記録を保持することができる。例えば、データベース３６＿３１６は、ヘッドホンがヘッドホンジャックに差し込まれた後、ユーザがアプリケーションＡを１０回中８回開くことを示す記録を保持することができる。したがって、予測エンジン３６＿３０２は、ヘッドホンのセットがヘッドホンジャックに挿入されたとき、アプリケーションＡがユーザのために識別されるべきかを判定するために、この情報を履歴データ３６＿３１８として受信することができる。

履歴イベントデータベース３６＿３１６はまた、トリガーイベントが検出されたときに、アプリケーションが異なるコンテキスト下で開かれた回数の記録を保持することもできる。例えば、データベース３６＿３１６は、ユーザが自宅にいるとき、ヘッドホンをヘッドホンジャックに挿入した後、ユーザがアプリケーションＡを１０回中９回開き、ユーザがジムにいるとき、１０回中１回開くことを示す記録を保持することができる。したがって、予測エンジン３６＿３０２は、この情報を履歴データ３６＿３１８として受信し、ヘッドホンがジムではなく、自宅でヘッドホンジャックに挿入されたとき、アプリケーションＡが識別されるべきであると判定することができる。本セクションで検討した例は「自宅」又は「ジム」としてロケーションを参照するが、「自宅」又は「ジム」を表すコンテキストデータ３６＿３０６は数値座標の形式にすることができることを、理解すべきである。当業者は、時間帯及び日付に関連する情報が、他のアプリケーションを識別するために、ロケーションの代わりに、これと同じ方法で利用され得ることを理解するものである。

履歴イベントデータベース３６＿３１６はまた、どれくらいの頻度で、かつどんな状況下でユーザが識別されたアプリケーションを実行しないように決めるかという記録を保持することができる。例えば、データベース３６＿３１６は、ユーザが自宅でヘッドホンをデバイスに挿入したとき、ユーザに提案されたアプリケーションＢを、ユーザが１０回中２回選択しなかったことを示す記録を保持することができる。したがって、予測エンジン３６＿３０２は、この情報を履歴データ３６＿３１８として受信し、ユーザが自宅でヘッドホンをデバイスに挿入するとき、アプリケーションＢを提案する確率を調整することができる。

一部の実施形態では、コンテキスト情報３６＿３０６及び／又は履歴情報（本セクションで更に検討する）は、トリガーイベントが検出されたとき、利用できなくてもよく、又は制限されてもよい。このような場合は、既定のアプリケーションが、トリガーイベントが検出されたときに提案されてもよい。既定のアプリケーションは、トリガーイベントのタイプと一般に関連付けられたアプリケーションのタイプとすることができる。例えば、音楽アプリケーションは、ヘッドホンのセットがヘッドホンジャックに挿入されたときに提案されてもよい。あるいは、地図アプリケーションは、車とＢｌｕｅｔｏｏｔｈ接続を行うときに提案されてもよい。より多くの履歴情報が得られると、提案されたアプリケーションは、既定のアプリケーションの代わりに提供され得る。
Ｂ．複数の予測モデル

異なるトリガーイベントにより提案されたアプリケーションが異なることになり得るにつれて、実施形態は、異なるトリガーイベントに対して異なる予測モデルを使用することができる。このようにして、予測モデルは、特定のトリガーイベントに対してより正確な提案を提供するように精緻化され得る。

図３６－４は、本発明の実施形態に係る、予測エンジン３６＿３０２をより詳細に図示する。予測エンジン３６＿３０２は、メモリデバイスに記憶されたプログラムコードとすることができる。実施形態では、予測エンジン３６＿３０２は１つ以上の予測モデルを含む。例えば、予測エンジン３６＿３０２は、予測モデル１～Ｎを含むことができる。各予測モデルは、特定のトリガーイベント３６＿２２８のアプリケーションを識別するように具体的に設計されたコード及び／又はデータのセクションとすることができる。例えば、予測モデル１は、ヘッドホンのセットがヘッドホンジャックに挿入されるトリガーイベントのアプリケーションを識別するように具体的に設計されてもよい。予測モデル２は、Ｂｌｕｅｔｏｏｔｈデバイスが接続されるトリガーイベントのアプリケーションを識別するように設計されてもよい。

予測モデル３は、長期間後にユーザがデバイスのユーザインタフェースと相互作用するトリガーイベント（例えば、ユーザが朝起きた後、最初にモバイルデバイスと相互作用するとき）のアプリケーションを識別するように設計されてもよい。他の予測モデルは、検出されたモーション（例えば、ユーザがモバイルデバイスと共にランニングしているとき）の特定のパターン、特定のロケーションへの到着、及び特定のアプリケーションの選択（例えば、車のコンピュータと通信するアプリケーションを選択する）と関連付けられたトリガーイベントのアプリケーションを識別するように設計されてもよい。任意の数の予測モデルは、トリガーイベント３６＿２２８の数に応じて予測エンジン３６＿３０２内に含まれ得る。

図示するように、各予測モデル１～Ｎは、コンテキストデータ３６＿３０６及び履歴データ３６＿３１８を受信するようにコンテキストソース及び履歴イベントデータベースに連結され得る。したがって、各予測モデルは、コンテキストデータ３６＿３０６及び履歴データ３６＿３１８を利用して、本セクションで検討する実施形態によって、提案されたアプリケーション３６＿３０４を識別することができる。

図３６－３に戻って参照すると、予測エンジン３６＿３０２は、提案されたアプリケーション３６＿３０４をエキスパートセンターモジュール３６＿３２０に送信することができる。実施形態では、イベントマネージャー３６＿３２０は、検索スクリーン又は他のスクリーンが開かれたとき、デバイス上に、例えば、ロックスクリーン上に何が表示されるかを管理するコードのセクションとすることができる。例えば、エキスパートセンター３６＿３２０はどの情報が、例えば、提案されたアプリケーション、提案された連絡先及び／又は他の情報がユーザに表示されるかを調整することができる。エキスパートセンター３６＿３２０は、このような情報をいつユーザに提供するかを判定することもできる。
Ｘ．ユーザインタフェース

イベントマネージャー３６＿３２０が提案されたアプリケーションをユーザに出力するちょうどよい時刻であると判定した場合、イベントマネージャー３６＿３２０は、アプリケーション３６＿３２２をユーザインタフェース３６＿３２４に出力することができる。実施形態では、出力アプリケーション３６＿３２２は提案されたアプリケーション３６＿３０４に対応することができる。ユーザインタフェース３６＿３２４は、出力アプリケーション３６＿３２２をユーザに伝え、出力アプリケーション３６＿３２２に関してユーザから応答を請うことができる。

実施形態では、ユーザインタフェース３６＿３２４は、ユーザが相互作用できるデバイスコンポーネントの組み合わせとすることができる。例えば、ユーザインタフェース３６＿３２４は、情報をユーザに出力する、かつ／又はユーザがデバイスへ信号を入力するのを可能にする能力を有するデバイスコンポーネントの組み合わせとすることができる。
Ａ．ディスプレイ

ユーザインタフェース３６＿３２４はデバイスのディスプレイに表示することができる。ディスプレイは入力信号がディスプレイとの物理的な相互作用によって生成できるようにタッチにを感知し得る。かかる実施形態では、ディスプレイは、ディスプレイに対するユーザのタッチを検出する画像表示層上に重ね合わされたタッチ感知層を含むことができる。したがって、ディスプレイは、情報をユーザに出力すると共に情報をユーザから入力することができるユーザインタフェース３６＿３２４の一部とすることができる。一例としては、ディスプレイは、提案されたアプリケーションについてのアイコンを示し、ユーザがディスプレイパネルの対応するロケーションをタップした場合、アプリケーションを実行するために信号を入力することができる。

現代のデバイスは、デバイスの認証されていない使用を防止するセキュリティ対策を有している。かかるデバイスは、ユーザがデバイス上に記憶されたアプリケーションのすべてにアクセスすることができる前に、ユーザにデバイスのロック解除を要求することができる。デバイスは、デバイスのセキュリティ状態に応じて、すべてのアプリケーションのアクセシビリティを制限することができる。例えば、デバイスは、デバイスがそのアプリケーションのすべてへのアクセスを可能にする前に、ユーザにデバイスのロック解除を要求することができる。ロック解除されたデバイスはホームスクリーンを示すディスプレイを有する場合がある。ホームスクリーンはデバイスのすべてのアプリケーションへのアクセスを表示かつ／又は提供することができる。しかし、ロックされたデバイスがロックスクリーンを示すディスプレイを有する場合がある。ディスプレイの一部の領域は、デバイスのロックを解除するプロンプトによって占められてもよい。したがって、ロックスクリーンは、デバイスセキュリティの高められた状態及び限定されたディスプレイスペースのため、ホームスクリーンより少ないアプリケーションとしか相互作用できない場合がある。例えば、ロックスクリーンは、１つ～３つのアプリケーションなど、デバイスのアプリケーションのすべてはアクセスできないようにしてもよい。一部の実施形態では、図３６－３に関して本セクションで検討するような提案されたアプリケーション３６＿３０４はロックスクリーン上に表示されてもよい。
Ｂ．他の入出力デバイスコンポーネント

ディスプレイは、情報をユーザに出力すると共に情報をユーザから入力することが可能なユーザインタフェース３６＿３２４の一部とすることができるが、ユーザインタフェース３６＿３２４の他の部分はそのように限定されない。例えば、ユーザから情報を入力できる他のデバイスコンポーネントが本セクションの実施形態でも想定される。一例としては、ボタン及びスイッチがユーザインタフェース３６＿３２４の一部とすることができる。ボタンは、ユーザがその上に圧力をかけると入力を生成するデバイスコンポーネントとすることができる。スイッチは、ユーザがレバーを別の位置に指ではじくと入力を生成するデバイスコンポーネントとすることができる。したがって、ボタン及び／又はスイッチは、本セクションで検討された実施形態によって、提案されたアプリケーション３６＿３０４を実行するためにユーザによってアクティブにされ得る。

ユーザから情報を出力できるデバイスコンポーネントが、本セクションの実施形態でも想定される。一例として、スピーカ又は触覚デバイスは、情報をユーザに出力するユーザインタフェースの一部とすることができる。スピーカはオーディオ通知を出力し、識別されたアプリケーションが提案されたことを示すことができる。触覚デバイスは触覚通知を出力し、識別されたアプリケーションが提案されたことを示すことができる。このようなデバイスは単なる実施形態であり、他の実施形態は、このようなデバイスに限定されるものではないことを理解すべきである。
Ｃ．相互作用の水準

ユーザインタフェース３６＿３２４は、ユーザが出力アプリケーション３６＿３２２を実行するために異なる水準の相互作用を要求することができる。様々な水準は、ユーザが提案されたアプリケーション３６＿３０４を実行することになる確率の度合いに対応することができる。例えば、予測エンジン３６＿３０２は提案されたアプリケーション３６＿３０４が、ユーザによって実行される確率が閾値確率を超えると判定する場合には、ユーザインタフェース３６＿３２４は、ユーザが、中間工程をスキップすることによって、より迅速にアプリケーションを実行できるようにするプロンプトを出力することができる。

一例として、予測エンジン３６＿３０２はユーザが提案された音楽アプリケーションを実行する確率が高閾値確率を超えると判定する場合には、提案された音楽アプリケーションは自動的に実行されてもよいので、ユーザインタフェース３６＿３２４は、音楽アプリケーションに対する制御、例えば、再生、一時停止、早送り／巻き戻しを表示することができる。それゆえに、ユーザはアプリケーションを実行するためにクリックする中間工程を実行する必要はない場合がある。

あるいは、予測エンジン３６＿３０２がユーザが音楽アプリケーションを実行する確率が高閾値確率より低いが低閾値確率より依然として高いと判定する場合は、音楽アプリケーションがアイコンとして表示されてもよい。低閾値確率はベースライン閾値確率より高い場合がある。ベースライン閾値確率は対応するアプリケーションが提案されることになる最小確率を設定することができる。こうして、ユーザは提案された音楽アプリケーションを実行するためにアイコンをクリックする余分な工程を実行する必要があることがある。しかし、クリック数は依然としてアプリケーションがユーザに提案されない場合に要求されるクリック数より少ない場合がある。実施形態では、閾値確率はアプリケーションのタイプによって異なる場合がある。各種実施形態では、高閾値確率は７５％～１００％の範囲にすることができ、低閾値確率は５０％～７５％の範囲にすることができ、ベースライン閾値は２５％～５０％の範囲にすることができる。特定の実施形態では、高閾値確率は７５％であり、低閾値確率は５０％であり、ベースライン確率は２５％である。

実施形態では、確率が高くなると、アプリケーションの提案がより積極的になり得る。例えば、アプリケーションが約９０％の高い確率を有する場合、予測エンジン３６＿３０２はデバイスのロックスクリーン上にアイコンを提供し、ユーザがアイコンを１クリックすることでアプリケーションにアクセスすることが可能にすることができる。アプリケーションが約９５％の更に高い確率を有する場合、予測エンジン３６＿３０２は更に、ユーザが何もクリックしなくても、自動的に、ユーザに対して提案されたアプリケーションを実行することができる。このような場合には、予測エンジン３６＿３０２は、提案されたアプリケーションを出力するだけでなく、音楽アプリケーション内の選択された音楽を再生するコマンド、又は地図アプリケーション内の特定のルートのガイダンスを開始するコマンドなどの、そのアプリケーションに特有のコマンドを出力することができる。

本発明の実施形態によれば、予測エンジン３６＿３０２はどんなレベルの相互作用が要求されるかを判定し、その後、その情報をイベントマネージャー３６＿３２０に出力することができる。その後、イベントマネージャー３６＿３２０はこの情報をユーザインタフェース３６＿３２４に送信し、ユーザに出力することができる。

実施形態では、ユーザインタフェース３６＿３２４はディスプレイスクリーン上にユーザへの通知を表示してもよい。通知は、例えば、プッシュ通知によって送信されてもよい。通知は、提案されたアプリケーションをユーザに通知する画像及び／又はテキストを含む視覚通知とすることができる。通知は、ユーザが暇なときに選択し実行するように、アプリケーションをユーザに提案することができる。選択されると、アプリケーションが実行してもよい。一部の実施形態において、より積極的な予測については、通知は提案されたアプリケーション内に提案されたアクションも含むことができる。つまり、通知は、ユーザに提案されたアプリケーション、並びに提案されたアプリケーション内の提案されたアクションを告知してもよい。こうして、ユーザには、提案されたアプリケーションを実行する、又は提案されたアプリケーション内の提案されたアクションを実行するという、オプションが与えられる。一例としては、通知は、ユーザに提案されたアプリケーションが音楽アプリケーションであり、提案されたアクションは、その音楽アプリケーション内の特定の曲を再生することであることを告知してもよい。ユーザは、提案された曲を示すアイコンをクリックすることによって、自身がその曲を再生したいことを示すことができる。あるいは、ユーザは、スクリーン上で通知をスワイプすることによって、自身が別の曲を再生するためにアプリケーションを実行しようとすることを示すことができる。

提案されたアプリケーション及び提案されたアクションを１つの通知内のユーザインタフェース３６＿３２４に出力する以外に、予測エンジン３６＿３０２は２つの提案されたアクションを１つの通知内のユーザインタフェース３６＿３２４に出力してもよい。例えば、予測エンジン３６＿３０２は、第１の曲を再生するよう提案されたアクションを出力し、第２の曲を再生するよう第２の提案されたアクションを出力してもよい。ユーザは、通知内のそれぞれのアイコンをクリックすることによって、どの曲を再生するかを選択することができる。実施形態では、提案されたアクションは、異なる基準に基づいて判定されてもよい。例えば、１つの提案されたアクションは、コンテキスト情報にかかわらず一番最近再生された曲を再生するためのものであってもよいが、他の提案されたアクションは同じ又は同様のコンテキスト情報下で、最後に再生された曲を再生するためであってもよい。一例としては、ユーザが自身の車に入って、トリガーイベントにより予測エンジン３６＿３０２が特定の曲の再生に関連する２つのアクションを提案する状況では、曲Ａは最後に、たまたま家で再生された曲としてもよく、曲Ｂはユーザが前回車の中にいたときに再生された曲としてもよい。ユーザが再生される曲を選択する場合、曲は最初から継続してもよいし、最後に停止されたところ（例えば、曲の途中）から継続してもよい。

予測エンジン３６＿３０２がアクションを提案できるように、予測エンジン３６＿３０２はデバイスのアクティブ状態についての情報を記憶するメモリデバイスにアクセスすることができる。デバイスのアクティブ状態は、提案されたアプリケーションの選択に続いて実行されるアクションを表すことができる。例えば、音楽アプリケーションのアクティブ状態は、特定の曲を再生していることとすることができる。アクティブ状態は、曲が最後にいつ停止したかを絶えず追跡してもよい。実施形態では、図３６－３からの履歴データベース３６＿３１６は、デバイスのアクティブ状態に関する履歴データを記録してもよい。したがって、予測エンジン３６＿３０２は提案されたアプリケーションによって実行されるアクションを提案することができる。
ＸＩ．提案されたアプリケーションを判定する方法

図３６－５は、本発明の実施形態に係る、トリガーイベントに基づいてアプリケーションを識別する方法３６＿５００を図示するフローチャートである。方法３６＿５００はデバイスによって完全に又は部分的に実行することができる。様々な実施例としては、デバイスは、本セクションで既に検討したように、電話機、タブレット、ラップトップコンピュータ、又はその他のモバイルデバイスとすることができる。

ブロック３６＿５０２では、デバイス、例えば、モバイルデバイスはイベントを検出する。例えば、ヘッドホンのセットがデバイスのヘッドホンジャックに挿入されてもよい。別の実施例としては、無線ヘッドセットが、Ｂｌｕｅｔｏｏｔｈ接続を介してデバイスに連結されてもよい。図３６－２の入力デバイス３６＿２０２はイベントを検出するのに使用され得る。イベントは、モバイルデバイスが外部デバイス又はユーザなどの外部エンティティと相互作用するあらゆるアクションとすることができる。

ブロック３６＿５０４では、デバイスは、検出されたイベントがトリガーイベントであるかどうかを判定する。検出されたイベントがトリガーイベントかどうかを判定するため、検出されたイベントは、イベントの所定のリスト、例えば、図３６－２の指定されたトリガーイベントデータベース３６＿２２６イベントのリストと比較されてもよい。検出されたイベントがイベントの所定のリストのうちの１つと一致する場合、検出されたイベントは、トリガーイベントであると判定され得る。

ブロック３６＿５０６では、デバイスは、予測モデル、例えば、図３６－４の予測モデル１～Ｎのうちの１つを選択する。選択された予測モデルはトリガーイベントに依存する場合がある。例えば、Ｂｌｕｅｔｏｏｔｈ接続のために設計された予測モデルは、トリガーイベントが外部デバイスとのＢｌｕｅｔｏｏｔｈ接続の確立に関連する場合に選択されてもよい。別の実施例としては、ヘッドホン接続に対して指定された予測モデルは、トリガーイベントがヘッドホンのセットのヘッドホンジャックへの挿入に関連する場合に選択されてもよい。

ブロック３６＿５０８では、デバイスは、コンテキスト情報を受信する。コンテキスト情報は様々なソース、例えば、図３６－３のコンテキストソース３６＿３０８から受信することができる。実施形態では、コンテキスト情報はデバイスの周囲状況に関連してもよい。例えば、コンテキスト情報は時間帯、日付、又はデバイスのロケーションに関連してもよい。加えて、履歴情報はデバイスによっても受信されてもよい。履歴情報は、データベース内、例えば、履歴イベントデータベース３６＿３１６内に記憶された、デバイスとユーザとの間の相互作用の履歴に関連してもよい。

ブロック３６＿５１０では、デバイスは、ユーザによってアクセスされる少なくとも閾値確率を有する１つ以上のアプリケーションを識別することができる。本セクションで既に述べたように、複数の閾値があってもよい。一部の実施形態では、閾値確率は、ベースライン閾値確率、低閾値確率、又は高閾値確率とすることができる。例えば、１つ以上のアプリケーションはそれぞれ閾値確率を超える確率を有してもよい。別の実施例では、１つ以上のアプリケーションは閾値確率を超える複合確率を有してもよい。１つ以上のアプリケーションは、最上位確率を有するアプリケーションとすることができ、様々な基準（例えば、閾値を超える確率を有するすべて、閾値を超えるのに必要とされるが最大数に限定されるできるだけ多くのアプリケーションなど）に選択されてもよい。一部の実施形態では、ベースライン閾値確率未満の確率を有するアプリケーションは無視されてもよい。

ユーザによってアクセスされる確率は予測モデルによって判定されてもよい。予測モデルは、コンテキスト情報並びに履歴情報を利用することによって確率を判定することができる。実施形態では、識別されたアプリケーションは、図３６－３及び図３６－４に関して本セクションで検討されたアプリケーションである。

一部の実施形態では、アプリケーションが等しい確率を有する場合、それらは無視されてもよい、すなわち、識別されなくてもよい。これらの状況では、デバイスは、１つ以上のアプリケーションを適切に識別するために、追加の履歴情報を生成する必要がある場合がある。より多くの履歴情報が収集されるにつれて、デバイスは適切なアプリケーション、例えば、所与のコンテキストでユーザによってアクセスされるのを所望されるアプリケーションを識別する際により正確になる。他の実施形態では、２つのアプリケーションが上位２つの確率を有する場合など、両方のアプリケーションの複合確率が十分に高い場合、両方のアプリケーションが提供される場合がある。

ブロック３６＿５１２では、デバイスはユーザインタフェースをユーザに提供することができる。例えば、デバイスは、ユーザが識別されたアプリケーションにアクセスしたいかどうかを示すよう、ユーザが相互作用し得るインタフェースを介して、識別されたアプリケーションをユーザに表示してもよい。例えば、ユーザインタフェースは、識別されたアプリケーションのうちの１つ以上をユーザに示すタッチ感知ディスプレイを含んでもよく、タッチ感知ディスプレイと相互作用することによって、ユーザは、デバイスによって識別されたアプリケーションのうち１つ以上にアクセスするのを可能にする。

特定の実施形態では、ユーザインタフェースはロックスクリーン内、又はホームスクリーン内に提供されてもよい。ホームスクリーンは、アンロック状態でホームボタンを押した後に表示されるスクリーンとすることができる。ロックスクリーンは、デバイスを起動するために長い非アクティブな期間の後、ホームボタンを押した後に表示されるスクリーンとすることができる。実施形態では、ロックスクリーンは、ホームスクリーンよりもアプリケーションを表示するための利用可能なディスプレイスペースが少ないのは、ロックスクリーンの一部はデバイスのロックを解除するために確保されているからである。一部の実施形態では、ユーザインタフェースは既に実行中のアプリケーションに関連付けられてもよい。一例としては、ユーザインタフェースは、図３６－６に図示するように、実行中の音楽アプリケーションに関連付けられたオーディオ制御を有する音楽プレーヤーインタフェースとすることができる。

図３６－６は、既に実行中のアプリケーションに関連付けられたデバイス３６＿６０２の例示的なユーザインタフェース３６＿６００を図示する。異なるアプリケーションの他のユーザインタフェースが本セクションでも想定されるが、ユーザインタフェース３６＿６００は、音楽アプリケーションのユーザインタフェースとすることができる。ユーザインタフェース３６＿６００はタッチスクリーンディスプレイ３６＿６０４によって提供されてもよい。タッチスクリーンディスプレイ３６＿６０４はオーディオコントロール３６＿６０８、音量コントロール３６＿６１０、曲タイトル３６＿６１２及び／又はアルバムアート３６＿６１４を表示することができる。オーディオコントロール３６＿６０８は、曲の早送り、巻き戻し、再生、及び一時停止のためのユーザインタフェースを提供することができる。音量コントロール３６＿６１０はユーザが出力された音響の音量を調整するのを可能にする。曲タイトル３６＿６１２及びアルバムアート３６＿６１４は、現在再生中の曲についての情報を表示することができる。実施形態では、ユーザインタフェース３６＿６００がタッチスクリーンディスプレイ３６＿６０４によって表示されたとき、デバイス３６＿６０２のバックライトが照光されてもよい。バックライトの照光により、ユーザは実行中のアプリケーションを見ることができると共に、デバイス３６＿６０２が提案されたアプリケーションを実行したことに気づくことができるようになる。音楽アプリケーションを自動的に実行しユーザインタフェース３６＿６００をユーザに提供することによって、デバイス３６＿６０２は、ユーザが１つ以上のアイコンをクリックする必要なく、自身の所望のアプリケーションにアクセスできるようにして、ユーザエクスペリエンスを高めることができる。

ユーザインタフェース３６＿６００の部分は、一部の状況では隠されてもよい。例えば、デバイス３６＿６０２の図３６－３のエキスパートセンター３６＿３２０などのエキスパートセンターが別のアプリケーションが提案されたアプリケーションよりも優先されると判断する場合は、アルバムアート３６＿６１４は隠されてもよく、他のアプリケーションがその代わりに表示されてもよい。他のアプリケーションが、他のアプリケーションを実行するためのディスプレイ３６＿６０４上のアクセス可能なアイコンとして表示されてもよい。他の実施形態では、他のアプリケーションが、ユーザが通知をクリックすると、他のアプリケーションのアイコンへアクセスできるようにする通知として表示されてもよい。かかる状況では、通知はアルバムアート３６＿６１４の代わりに表示されるであろう。実施形態では、ユーザインタフェースがロックスクリーン上に表示される場合、通知もロックスクリーン上に表示されてもよい。したがって、ユーザは優先度が高いと思われるアプリケーションに気づかされ、それを実行する機会が与えられてもよい。
ＸＩＩ．アプリケーションを実行するための時間制限

実施形態では、識別されたアプリケーションが特定の期間にアクセスされない場合、まるでユーザインタフェースがそもそも提供されなかったかのように、デバイスは、ユーザインタフェースを除去することができる。ユーザが特定の期間アプリケーションにアクセスしない場合、ユーザがアプリケーションへのアクセスに興味がないとみなされる。したがって、ユーザインタフェースは、ユーザが識別されたアプリケーションにアクセスできないように除去され、ユーザの気は散らされない。

図３６－７Ａ及び図３６－７Ｂは、実施形態に係る、ユーザインタフェースを除去する方法を図示するフローチャートである。具体的には、図３６－７Ａは、一定期間の後、ユーザインタフェースを除去するための方法３６＿７００を図示するフローチャートである。図３６－７Ｂは、トリガーイベントが閾値期間内に除去された後、ユーザインタフェースを除去するための方法３６＿７０３を図示するフローチャートである。方法３６＿７００及び方法３６＿７０３はデバイスによって完全に又は部分的に実行することができる。

図３６－７Ａを参照すると、方法３６＿７００はブロック３６＿７０１でユーザインタフェースをユーザに提供して開始する。ブロック３６＿７０１は、図３６－５に関して本セクションで検討したブロック３６＿５１２で述べたように実行され得る。

ブロック３６＿７０２では、デバイスは、ユーザインタフェースが最初にユーザに提供されてから、閾値期間が経過したかを判定する。ユーザインタフェースは、ロックスクリーン又はホームスクリーンのいずれかでユーザに提供されてもよい。実施形態では、閾値期間は、ユーザがデバイスと相互作用しなかった場合の、ユーザインタフェースをユーザに提供した直後に開始する所定の期間を表す。

閾値期間はトリガーイベントのタイプに応じて異なる場合がある。例えば、トリガーイベントが直接的なユーザ相互作用を伴うイベントのタイプ（例えば、イベントを起こそうとするユーザによる認識アクション）である場合、閾値期間は相対的に短くなり得る（例えば、１５～３０秒）。かかるトリガーイベントの例としては、ヘッドホンのセットのヘッドホンジャックへの挿入が挙げられる。別の例としては、長い期間後にボタンを押すことによってデバイスを起動することが挙げられる。閾値期間は相対的に短くなり得るのは、ユーザが直接、電話機と相互作用し、出力された識別アプリケーションにすぐに気づき得ることを想定できるからである。ユーザが識別されたアプリケーションにすぐに気づくので、識別されたアプリケーションにアクセスされない短い期間が経過することで、ユーザが識別されたアプリケーションにアクセスするつもりはないことが示される。

あるいは、トリガーイベントが直接的なユーザ相互作用を伴わないイベントのタイプである場合、閾値期間は、直接的なユーザ相互作用を伴うトリガーイベントの閾値期間より長くなり得る。実施形態では、直接的なユーザ相互作用を伴わないトリガーイベントの閾値期間は、相対的に長く、例えば、１５～３０分とすることができる。かかる一つの例としては、あるロケーションに到着することが挙げられる。デバイスが特定のロケーションに到着する場合、ユーザは移動していて、デバイスに注目していないことが想定される。ユーザは、出力された識別されたアプリケーションにすぐに気づかない場合がある。したがって、ユーザがデバイスをチェックし、識別されたアプリケーションに気づく前に、より多くの時間が経過する場合がある。

ブロック３６＿７０４では、閾値期間は経過する場合、ユーザインタフェースは、ユーザがアプリケーションが提案されたことを全く認識しない可能性があるように除去されてもよい。しかし、閾値期間が経過しない場合、ブロック３６＿７０６では、デバイスはユーザがアプリケーションにアクセスしたいかを判定する。ユーザは、ユーザインタフェースを介したユーザ入力の任意の形態によって、例えば、タッチスクリーンと相互作用する、ボタンを押す、スイッチを指ではじく、又はバイオメトリックデバイスを使用することによって、自分がアプリケーションにアクセスしたいことを示すことができる。

ユーザがアプリケーションにアクセスしたいことをまだ示していないと判定される場合は、デバイスは、ブロック３６＿７０１で継続してユーザインタフェースをユーザに提供することができる。しかし、ユーザがアプリケーションにアクセスしたいというインジケーションをデバイスが受信すると、ブロック３６＿７０８では、デバイスはアプリケーションを実行することができる。したがって、デバイスは、所望のアプリケーションへのショートカットを提供することで、ユーザの時間を節約することができ、それによって、ユーザのエクスペリエンスを高めることができる。

一部の実施形態では、ユーザインタフェースは閾値期間の持続時間前に除去されてもよい。図３６－７Ｂに図示するように、ブロック３６＿７１０では、デバイスはトリガーイベントが除去されたか、例えば、トリガーイベントの反対のアクションが検出されたかを判定する。例えば、トリガーイベントがヘッドホンのセットのヘッドホンジャックへの挿入である場合、トリガーイベントの除去は、ヘッドホンのセットをヘッドホンジャックから引き抜くことである。別の実施例では、トリガーイベントがＢｌｕｅｔｏｏｔｈ接続の確立である場合、トリガーイベントの除去は、Ｂｌｕｅｔｏｏｔｈ接続を切断することである。トリガーイベントの除去は、ユーザが提案されたデバイスにアクセスするつもりはないことを意味するように、デバイスによって解釈される場合がある。したがって、トリガーイベントが除去される場合、ユーザインタフェースを、ブロック３６＿７０４で除去でき、例えば、アプリケーションはクリアでき、アプリケーションの任意のユーザインタフェースを隠すことができる。
ＸＩＩＩ．トレーニングルーチン

モバイルデバイスの使用を通して履歴情報が蓄積されるについて、予測モデル（例えば、図３６－４で検討した予測モデル１～Ｎ）は、新しい履歴情報を考慮して定期的にトレーニング（すなわち、更新）されてもよい。トレーニングされた後、予測モデル１～Ｎは、ユーザとモバイルデバイスとの間の一番最近の相互作用パターンにしたがって、より正確にアプリケーション及びアクションを提案することができる。トレーニング予測モデル１～Ｎは、大量の履歴情報が記録された場合は、最も効果的となり得る。こうして、トレーニングは、モバイルデバイスがユーザとの多数の相互作用を検出できるほど十分に長い間隔で発生することができる。しかし、トレーニングセッションの間あまりに長時間待つことは、予測エンジンの適応性を妨げる場合がある。したがって、トレーニングセッションの間の好適な時間は、１５～２０時間、例えば、１８時間とすることができる。

トレーニング予測モデル１～Ｎは時間がかかる場合があり、モバイルデバイスの使用と干渉する場合がある。したがって、トレーニングはユーザが最もデバイスを使用しそうもないときに発生してもよい。ユーザがデバイスを使用しないであろうことを予測する一つの方法は、デバイスが使用されていないときの時間、例えば、ボタンが押されていないとき、及びデバイスが移動していないときを待つ方法がある。これは、ユーザが近い将来に一定期間、例えば、ユーザが寝ているとき、電話機と相互作用しない状態にあることを示すことができる。任意の好適な持続時間は、１時間から３時間などの待ち時間に使用することができる。特定の実施形態では、待ち時間は２時間である。

２時間の終わりに、予測モデル１～Ｎは更新され得る。しかし、この２時間の終了前に、ユーザがモバイルデバイスと相互作用する（ボタンを押すか、又はデバイスを移動する）場合は、２時間の期間のカウントダウンが再始動してもよい。この時間が活動していない２時間に達する前に絶えず再始動する場合は、モバイルデバイスは、絶対時間後に予測モデル１～Ｎのトレーニングを強制してもよい。一実施形態では、絶対時間は、旧式の予測モデルのため、ユーザによるモバイルデバイスの使用しやすさが低下し始める閾値時間であると判定されてもよい。絶対時間は、１０～１５時間にわたる場合があり、あるいは特定の実施形態では１２時間としてもよい。したがって、トレーニング間の最大時間は、２８時間（１８＋１０時間）～３３時間（１８＋１５時間）とすることができる。特定の実施形態では、最大時間は、３０時間（１８＋１２時間）である。

一部の実施形態では、デバイス１００（図１Ａ）のソフトウェアコンポーネントはトリガーイベントモジュール及び予測モジュールを含む。トリガーイベントモジュールは、例えば、図３６－２に関して本セクションで記載したように、様々なサブモジュール又はシステムを含むことができる。更に、予測モジュールは、例えば、図３６－３に関して本セクションに記載したように、様々なサブモジュール又はシステムを含むことができる。
検出されたトリガーイベントに基づくアプリケーション推薦の例示の方法、デバイス、及びコンピュータ可読媒体

一部の実施形態では、イベントは入力デバイスによって検出され得る。イベントは、そのイベントをトリガーイベントからなるグループと比較することで、トリガーイベントであると判定され得る。その後、そのイベントに対応する第１の予測モデルが選択される。その後、第１のコンテキストにおいてコンピューティングデバイスの１つ以上のプロパティを特定するデバイスについてのコンテキスト情報が受信され、１つ以上のアプリケーションのセットが識別される。１つ以上のアプリケーションのセットは、イベントが第１のコンテキストで発生した場合、ユーザによってアクセスされる少なくとも閾値確率を有し得る。その後、１つ以上のアプリケーションのセットと相互作用するために、ユーザインタフェースがユーザに提供される。

一部の実施形態では、コンピューティングデバイス上で実行される提案されたアプリケーションと相互作用するためにユーザインタフェースをユーザに提供するための、コンピュータにより実行される方法が提供され、その方法は、コンピューティングデバイスにおいて、コンピューティングデバイスの入力デバイスでイベントを検出することと、このイベントが１つ以上の提案されたアプリケーションを識別するために指定されたトリガーイベントからなるグループのうちの１つに対応することを判定することと、イベントに対応する第１の予測モデルを選択することと、第１のコンテキストに対してコンピューティングデバイスの１つ以上のプロパティを特定する、コンピューティングデバイスについてのコンテキスト情報を受信することと、第１の予測モデルによって、第１のコンテキストと関連してイベントが発生したとき、ユーザによってアクセスされる少なくとも閾値確率を有する１つ以上のアプリケーションのセットを識別することであって、この第１の予測モデルはイベントが検出された後、ユーザのコンピューティングデバイスとの過去相互作用を使用する、ことと、１つ以上のアプリケーションのセットと相互作用するために、ユーザインタフェースをユーザに提供することと、を含む。一部の実施形態では、コンピューティングデバイスの入力デバイスでイベントを検出することは、コンピューティングデバイスのアクセサリデバイスへの接続を検出することを含む。一部の実施形態では、アクセサリデバイスはヘッドホン又は車両のコンピュータを含む。一部の実施形態では、コンテキスト情報はコンピューティングデバイスのロケーションを特定する。一部の実施形態では、ユーザインタフェースは、コンピューティングデバイスのホームスクリーン上で提供されるよりも、少ないアプリケーションと、スクリーン上で相互作用することを可能にする。一部の実施形態では、コンピューティングデバイスの入力デバイスでイベントを検出することは、１つ以上のモーションセンサでコンピューティングデバイスの動きを検出することと、この動きに基づいてコンピューティングデバイスのモーション状態を判定することと、を含み、１つ以上の提案されたアプリケーションを識別するために指定されたトリガーイベントからなるグループのうちの１つは、コンピューティングデバイスのモーション状態を含む。一部の実施形態では、第２の予測モデルが、イベントとは異なる別のトリガーイベントが検出されたときに選択され、第２の予測モデルは第１の予測モデルとは異なるものである。一部の実施形態では、１つ以上のアプリケーションのセットは、複数のアプリケーションを含み、１つ以上のアプリケーションのセットは全体として閾値確率を超える確率を有する。一部の実施形態では、ユーザインタフェースがコンピューティングデバイスのロックスクリーン上に提供され、ユーザインタフェースはロックスクリーンからアプリケーションのセットのうちの１つを選択できるようにする。一部の実施形態では、方法は、１つ以上のアプリケーションのセットを実行することを含み、ユーザインタフェースは実行される１つ以上のアプリケーションに特有である。一部の実施形態では、１つ以上のプロパティは、コンピューティングデバイスのロケーション、コンピューティングデバイスによって判定された時間帯、及びコンピューティングデバイスによって判定された日付のうちの少なくとも１つを含む。一部の実施形態では、方法は、閾値期間が経過したかを判定することと、閾値期間が経過したと判定された場合は、ユーザインタフェースを除去することと、閾値期間が経過していないと判定された場合は、ユーザが１つ以上のアプリケーションのセットにアクセスしようと捜し求めているかを判定することと、ユーザが１つ以上のアプリケーションのセットにアクセスしようと捜し求めていると判定された場合、１つ以上のアプリケーションのセットを実行することと、を含む。一部の実施形態では、閾値期間は、直接的なユーザ相互作用を伴わないトリガーイベントよりも直接的なユーザ相互作用を伴うトリガーイベントについては短い。

一部の実施形態では、実行されたとき、１つ以上のプロセッサを含むデバイスを制御する複数の命令を記憶する非一時的コンピュータ可読記憶媒体を含むコンピュータ製品であって、命令は、デバイスの入力デバイスでイベントを検出する、ことと、イベントが１つ以上の提案されたアプリケーションを識別するために指定されたトリガーイベントからなるグループのうちの１つに対応することを判定することと、イベントに対応する第１の予測モデルを選択することと、第１のコンテキストに対してデバイスの１つ以上のプロパティを特定する、デバイスについてのコンテキスト情報を受信することと、第１の予測モデルによって、第１のコンテキストでイベントが発生したとき、ユーザによってアクセスされる少なくとも閾値確率を有する１つ以上のアプリケーションのセットを識別することであって、この第１の予測モデルはイベントが検出された場合、デバイスとのユーザの過去相互作用を使用する、ことと、１つ以上のアプリケーションのセットと相互作用するために、ユーザインタフェースをユーザに提供することと、を含む。一部の実施形態では、デバイスの入力デバイスでイベントを検出することは、コンピューティングデバイスのアクセサリデバイスへの接続を検出することを含む。

一部の実施形態では、トリガーイベントを記憶するためのトリガーイベント記憶装置と、履歴データを記憶するための履歴記憶装置と、１つ以上の入力デバイスと、１つ以上のコンテキストソースと、１つ以上の入力デバイスでイベントを検出し、イベントが、１つ以上の提案されたアプリケーションを識別するために指定されたトリガーイベントからなるグループのうちの１つに対応することを判定し、イベントに対応する第１の予測モデルを選択し、１つ以上のコンテキスト情報から、第１のコンテキストに対してコンピューティングデバイスの１つ以上のプロパティを特定するデバイスについてのコンテキスト情報を受信し、第１の予測モデルによって、第１のコンテキストでイベントが発生したとき、ユーザによってアクセスされる少なくとも閾値確率を有する１つ以上のアプリケーションのセットを識別することであって、この第１の予測モデルはイベントが検出された場合、ユーザのコンピューティングデバイスとの過去相互作用を使用し、１つ以上のアプリケーションのセットと相互作用するためにユーザインタフェースをユーザに提供するように構成された１つ以上のプロセッサと、を備えるデバイスが提供される。一部の実施形態では、１つ以上の入力デバイスはヘッドホンジャック、Ｂｌｕｅｔｏｏｔｈデバイス、ボタン、タッチスクリーン、加速度計、及びＧＰＳのうちの少なくとも１つを含む。一部の実施形態では、トリガーイベントは所定のイベントである。一部の実施形態では、ユーザインタフェースは、コンピューティングデバイスのホームスクリーン上で提供されるよりも、少ないアプリケーションとの相互作用を可能にする。一部の実施形態では、１つ以上のアプリケーションのセットは、複数のアプリケーションを含み、複数のアプリケーションのそれぞれは閾値確率を超える確率を有する。
セクション７：人々中心の予測／デバイスのコンテキストに基づいて宛先を提案する技法

本セクションの「人々中心の予測」という題材は、一部の実施形態による、人々中心の予測及びデバイスのコンテキストに基づいて宛先を提案する技法を記載し、本明細書に提供される開示を補足する情報を提供する。例えば、本セクションの部分は連絡先を識別及び予測する方法、並びにユーザによって使用される連絡先を推薦する方法を記載し、それらは本明細書に提供される開示を補足するものであり、特に、図９Ｂ～図９Ｃの予測部分９３０内に提案された人々をポピュレートすることを参照して、例えば、以下に検討する方法６００及び方法８００に関連するものである。一部の実施形態では、本セクションに記載される連絡先の予測及び提案を支援するのに使用される予測モデル及び過去相互作用データベースは、予測、提案及び／又は、ユーザによって即座に使用できるように検索インタフェース又はロックスクリーンなどのユーザインタフェース内への包含のために適切な連絡先の識別を支援するのに使用される（すなわち、これらの予測モデルは連絡先を提案／予測するための方法６００、方法８００、方法１０００、及び方法１２００と併せて使用される）。
人々中心の予測の概要

実施形態は、デバイスの現在のコンテキストに基づいてコンピューティングデバイスのユーザと最も関連しそうな、通信及び相互作用のための宛先を提案する。コンピューティングデバイスの例は、電話機コンピュータ、タブレットコンピュータ、ラップトップコンピュータ、又はデスクトップコンピュータである。例示のシステムは、以前の相互作用の知識を収集し、この知識に基づいて予測された宛先を提案する。知識は、いつ、どこで、かつどのようにユーザが他のユーザと相互作用したかを示す情報と共に過去相互作用データベース内に記憶することができる。システムは、特定のコンテキストの場合、宛先と相互作用するメカニズムと共に宛先（例えば、人々）を推薦することができる。コンテキストは、時間、ロケーション及びアカウント識別子（例えば、電子メールアカウント）を示す状態変数に関して記載され得る。コンテキストはまた、キーワード（例えば、電子メールの件名又はカレンダーイベントのタイトルからのキーワード）及び、例えば、ユーザが過去に相互作用した宛先のセットなど他の要因に基づくものとすることもできる。特定のユーザ、アカウント、アプリケーション（例えば、通信アプリケーション）、又は相互作用のメカニズムに対する提案を絞り込むのに役立つように、追加の制約が課される場合がある。

実施形態は、イベント及びコンテキストに基づいてコンピューティングデバイスと連絡するための１つ以上の宛先を提案するシステム、方法、及び装置を提供することができる。例示のイベントとしては、検索を開始するための入力の受信、電子メールアプリケーションにアクセスするための入力の受信、電子メールの構成、テキストメッセージアプリケーションにアクセスするための入力の受信、テキストメッセージの構成、カレンダーアプリケーションにアクセスするための入力の受信、カレンダーエントリの作成、カレンダーエントリの編集、電話機通話の開始、テレビ通話の開始、及びテレビ会議の開始が挙げられる。例示のコンテキストはロケーション及び時間を含む。実施形態は、ユーザが通信を開始又は構成するのに使用しているデバイスのコンテキスト（例えば、自宅で、通勤中、仕事中など）に基づいて通信の宛先を予測することができる。例えば、通信について知られた情報（例えば、通信が電子メール、インスタントメッセージ、テキストメッセージ、テレビ会議又はカレンダーの招待かどうか）に基づいて、通信の宛先が予測される。通信の宛先はまた、以前の通信に基づいて予測される。例えば、ユーザ又はユーザが過去に、以前の電子メール、メッセージ又は通話を介して相互作用した連絡先が通信の宛先として提案され得る。

実施形態は、ユーザが特定の時間及び場所で相互作用することを望む場合がある人々を予測するために、コンテキスト情報を用いることで、連絡する宛先を提案する方法を提供することができる。一部の実施形態は、デバイス（例えば、モバイルデバイス）のユーザがアプリケーション内で通信を構成又は開始している際の、現在の状態を表す現在のコンテキストを判定する。実施形態では、現在のコンテキストは、時間、ロケーション、次のカレンダーエントリ、通信のタイトル又は件名（例えば、電子メールの件名又はカレンダーエントリのタイトル）、同様の通信における以前の宛先、及びアカウント情報（例えば、私的な電子メールアカウント又は仕事の電子メールアカウント）などのコンテキスト情報を含むことができる。一部の実施形態は、現在のコンテキストを使用し、ユーザが通信の宛先として追加する可能性の最も高い宛先は誰かを予測する。

他の実施形態は、本明細書に記載の方法に関連付けられたシステム、ポータブル家庭用デバイス及びコンピュータ可読媒体を対象とする。

以下の詳細な説明及び添付の図面を参照することにより、本発明の実施形態の性質及び利点の理解をより深めることができる。
人々中心の予測の詳細な説明

実施形態は、コンピューティングデバイスのユーザに宛先を提案するための、カスタマイズされ、かつパーソナライズされたエクスペリエンスを提供でき、それによって他のユーザと相互作用及び通信するためのデバイスの使用を容易にするものである。実施形態は、人々中心の予測を用いて連絡するための宛先を提案する方法を提供することができる。人々中心の予測は、コンテキスト情報を用いて、ユーザが特定の時間及び場所で相互作用することを望む場合がある人々を予測する。コンピューティングデバイスのユーザは他のユーザのセット（例えば、連絡先）と相互作用及び通信することができる。コンピューティングデバイスの例は、電話機コンピュータ、タブレットコンピュータ、ラップトップコンピュータ、又はデスクトップコンピュータである。他のユーザとの相互作用及び通信は、特定のイベント後に発生してもよい。例示のイベントとしては、検索の開始、通信アプリケーションへのアクセス、及び通信の構成又は開始が挙げられる。例示の通信アプリケーションとしては、電子メールアプリケーション、カレンダーアプリケーション、テレビ通話アプリケーション、インスタントメッセージアプリケーション、テキストメッセージアプリケーション、テレビ会議アプリケーション、Ｗｅｂ会議アプリケーション、及び音声通話アプリケーションが挙げられる。例示の通信としては、例えば、電子メールメッセージ、カレンダーの招待、テキストメッセージ、インスタントメッセージ、テレビ通話、音声通話、及びテレビ会議などの音声及びデータ通信が挙げられる。通信アプリケーションがデバイス上で使用される場合、通信の宛先は、デバイスの現在のコンテキストと履歴情報との比較に基づいて提案され得る。

実施形態では、過去の過去相互作用からのデータは、データベースのテーブルに記憶され、通信の宛先を提案するのに使用される。データベースは、例えば、タイムスタンプ、相互作用に使用されたアプリケーション、アカウント情報（例えば、電子メールアカウントのアカウント識別子）、及びロケーションなどの過去の相互作用のコンテキスト情報を含むことができる。過去の相互作用は、デバイスのコンテキストと比較され、デバイス上で開始される通信の宛先を提案することができる。例えば、デバイスの現在のコンテキストは、過去相互作用データと比較されて、現在のコンテキストと、以前の宛先と同様の過去の相互作用と一致させることができる。

履歴データ内の各データポイント（例えば、記録）は、特定のコンテキストに対応する（例えば、デバイスの１つ以上のプロパティに対応する）ことができ、特定のコンテキストに対する一層多くのデータが長時間にわたって得られる。特定のイベントに対する履歴データは、ユーザに宛先を提案するのに使用され得る。様々なユーザが様々な履歴データを有するにつれて、実施形態は、パーソナライズされたエクスペリエンスを提供することができる。

一部の実施形態では、以前の同様の通信の宛先が、構成又は開始される通信の宛先を提案するのに使用される。例えば、ユーザが現在の通信に対する最初の宛先を選択する場合、選択される最初の宛先と過去の通信に追加された他の宛先を使用して、現在の通信に対する追加の宛先を予測することができる。一実施形態では、宛先は、相互作用の周期性（例えば、同様の時間帯又は同じ曜日に繰り返し送信された通信）を示すコンテキストデータに基づいて提供することができる。宛先はまた、ユーザの現在のロケーションが、過去の通信が特定の連絡先に送信されたときにユーザがいたロケーションと同じであることを示すロケーション情報に基づいて提供することができる。

実施形態では、ユーザが提供した情報が宛先を予測するのに使用され得る。ユーザが提供した情報は、電子メールの件名、電子メールのコンテンツ、カレンダーエントリのタイトル、イベント時刻、及び／又はユーザが選択した宛先を含むことができる。かかるユーザが提供した情報は、過去コンテキスト情報と比較されて、宛先を予測することができる。例えば、ユーザが提供した情報と同様の特性を有する過去の通信の宛先が、現在の通信の提案された宛先としてユーザに提示される場合がある。一部の実施形態は、ユーザが通信内に入力した情報（例えば、ユーザが件名又は添付を含めた場合）を使用して、かかる情報が潜在的な宛先の識別に関連すると判定することができる。例えば、実施形態は、電子メールメッセージの件名又はカレンダーエントリを解析し、かかる情報が利用可能な場合には、潜在的な宛先の提案に関連する場合がある１つ以上のキーワードを識別することができる。

正確にパーソナライズされたエクスペリエンスを提供するため、各種実施形態は、宛先の提案を提供せずに単にトレーニングされた、又は種々のコンテキストに対する宛先（単数又は複数）の同一のセットを提案する広範なモデルで始めることができる。十分な履歴データを用いて、広範なモデルは、サブモデル、例えば、人々又は相互作用のグループにセグメント化され得、各サブモデルは過去相互作用データの異なるサブセットに対応するものである。次に、イベントが発生すると、デバイスの現在のコンテキストに対応する１つ以上の提案された宛先を提供するために特定のサブモデルが選択され得る。例えば、履歴データのサブセット内の正確な予測を提供するサブモデル内の信頼水準及び親モデルに対する履歴データの分布内の情報利得（エントロピーの低下）など、様々な基準がサブモデルをいつ生成すべきかを判定するのに使用され得る。

したがって、一部の実施形態は、宛先推薦のコンテキストで履歴データをいつ、どのようにセグメント化するかを決定することができる。例えば、ユーザ相互作用アクティビティの期間を収集した後、実施形態は、予想されるセグメント化候補（例えば、ロケーション、曜日、時間帯など）のリストを蓄積することができる。実施形態はまた、全データセットのモデルをトレーニングし、データセット及びモデルの合わせた分布内の信頼度のメトリックを計算することができる。モデルのセットは、セグメント化されたデータセット（サブセット）のそれぞれに対して１つでトレーニングでき、データモデル分布のそれぞれの信頼度を測定することができる。すべてのデータモデル分布の信頼度が許容される場合、実施形態はセグメント化（分割）を行い、更なるセグメント化のためのセグメント化された空間を再帰的に検査することができる。

このようにして、一部の実施形態は、セグメント化と一般化との間のトレードオフを探査するよう推論を使用でき、より別個の、複合パターンを有するユーザに対してより複合モデルを、よりノイジー（noisier）でより簡潔なパターンを有するユーザに対して簡潔で一般的なモデルを生成することができる。また、一部の実施形態は、可能な候補モデル間の発散分布の発見に基づいて確率的モデルの木を生成することができる。
Ｉ．イベントに基づいた宛先の提案

実施形態は、イベントに基づいて１つ以上の宛先を提案することができ、それは、特定の所定のイベント（トリガーイベントとも呼ばれる）に限定されてもよい。例示のトリガーイベントとしては、検索の開始、電子メールメッセージの構成、カレンダーエントリの作成などを含み得る。例えば、ユーザが以前に、特定の電子メールアカウントを用いて電子メールを送信したことがある連絡先が、ユーザが電子メールアカウントを用いて電子メールを構成し始める時に提案され得る。一部の実施形態では、コンテキスト情報は、ユーザに提案する宛先を識別するためにイベントと併せて使用され得る。一実施例としては、カレンダーエントリ（例えば、カレンダーイベント、ミィーティング又は約束）が作成又は修正される場合、ロケーションに関連するコンテキスト情報を使用してもよい。デバイスがオフィスのロケーションにある場合、例えば、そのロケーションにオフィスを有する宛先Ａが、カレンダーイベントの参加者として提案される場合がある。あるいは、デバイスが自宅にある場合、自宅ロケーションに関連付けられた宛先Ｂ（すなわち、家族又はルームメイト）が、カレンダーエントリの参加者として提案され得る。したがって、特定のコンテキスト下で関連すると予測されるアプリケーションをちょうどよい時刻に提案することができるので、ユーザエクスペリエンスを向上させることができる。別の実施例としては、カレンダーエントリが作成又は修正のため開かれている場合、時間に関連するコンテキスト情報が使用されてもよい。カレンダーエントリのスケジュールされた開始時刻がユーザの典型的な勤務時間に対応する場合は、同僚である宛先Ａがカレンダーイベントの参加者として提案されてもよい。あるいは、カレンダーエントリが夕方又は週末に対応する開始時刻を有する場合、友人又は家族である宛先Ｂがカレンダーイベントの参加者として提案され得る。

図３７－１は、本発明の実施形態に係る、検出されたイベントに基づいて宛先を提案する方法３７＿１００のフローチャートである。方法３７＿１００を、モバイルデバイス（例えば、電話機、タブレット）又は非モバイルデバイスによって実行することができ、またその方法は、デバイスの１つ以上のユーザインタフェースを使用することができる。

ブロック３７＿１０２では、ユーザデバイスでのユーザ入力が検出される。一部の実施形態では、入力が宛先を提案するためのトリガーイベントに対応するかを判定することができる。一部の実装形態では、提案された１つ以上の宛先（単数又は複数）の判定は、特定の所定のイベント（例えば、トリガーイベント）に対してのみ行われる。他の実装形態では、提案された１つ以上の宛先（単数又は複数）の判定は、イベントの動的リストに対して行うことができ、それはユーザデバイスを用いて行われた履歴ユーザ相互作用に基づいて更新され得る。

一部の実施形態では、トリガーイベントは、デバイスの通信アプリケーションの動作に相関する可能性が十分あるものとして識別され得る。トリガーイベントであるイベントのリストはデバイスに記憶され得る。かかるイベントは既定のリストとすることができ、オペレーティングシステムの一部として維持され得、ユーザによって構成変更できてもよいし、構成変更できなくてもよい。

トリガーイベントは、ユーザ及び／又は外部デバイスに誘導されたイベントとすることができる。例えば、トリガーイベントは、入力がモバイルデバイスで受信された場合とすることができる。例としては、検索を開始するための入力の受信、通信アプリケーションにアクセスするための入力の受信などが挙げられる。本例では、これらのイベントのそれぞれは、異なるトリガーイベントとして分類することができる。他の例としては、トリガーイベントは、デバイスとのユーザの特定の相互作用とすることができる。例えば、ユーザはデバイス上で検索を開始し、デバイス上で通信アプリケーションにアクセスし、又はデバイス上で通信メッセージの構成を開始することができる。また、例えば、ユーザは、モバイルデバイスを職場のロケーションまで移動させることができ、この場合、デバイスのロケーション状態はトリガーイベントである。かかるロケーション状態（又は他の状態）は、デバイスのセンサに基づいて判定され得る。

ブロック３７＿１０４では、デバイスの現在の状態を表すコンテキスト情報が判定される。一実施例では、コンテキスト情報はデバイス上で実行されるアプリケーションを示すことができる。例えば、コンテキスト情報は、通信を開始するのに用いられる通信アプリケーションの状態を示すことができる。コンテキスト情報はまた、通信を開始するのに用いられる検索アプリケーションの状態を示すこともできる。一実施例としては、ブロック３７＿１０４は、時間、アカウント情報（例えば、電子メールアカウント識別子）、及び／又はデバイス上で使用される通信アプリケーションに対応するロケーションを含むことができる。ブロック３７＿１０４はまた、デバイスのサブ状態を判定することも含むことができ、サブ状態は、実行中のアプリケーションのアプリケーション状態である。例えば、アプリケーション状態は、電子メールメッセージを構成するのに使用される電子メールアプリケーションの状態、カレンダーイベントを作成するのに使用されるカレンダーアプリケーションの状態、インスタントメッセージを開始するのに使用されるインスタントメッセージングクライアントの状態、テキストメッセージを構成するのに使用されるアプリケーションの状態、又は電話機通話、テレビ通話若しくはテレビ会議を開始するのに使用されるアプリケーションの状態を示すことができる。

コンテキスト情報は特定のコンテキストに対してデバイスの１つ以上のプロパティを特定することができる。コンテキストは、トリガーイベントが受信されたときのデバイスの周囲の環境（コンテキストのタイプ）としてもよい。例えば、コンテキスト情報はイベントが検出される時間帯としてもよい。別の実施例では、コンテキスト情報は、イベントが検出されたときのデバイスの特定のロケーションとしてもよい。更に別の実施例では、コンテキスト情報は、トリガーイベントが検出された時の特定の日付としてもよい。かかるコンテキスト情報は、提案エンジンがにそのコンテキストでユーザによって選択される可能性のある宛先を正確に提案できるようにデバイスのコンテキストについてのより有意義な情報を提供してもよい。したがって、コンテキスト情報を利用する予測エンジンは、コンテキスト情報が利用されない場合より、正確に宛先をユーザに提案することができる。

ブロック３７＿１０６では、ユーザと他のユーザとの間の過去の相互作用を表す履歴データが取り出される。取り出しは、コンテキスト情報に基づくものである。例えば、ブロック３７＿１０６は、過去の電子メール、メッセージ、電話機通話、カレンダーエントリ、テレビ通話、及びテレビ会議に対応するデータを取り出すことを含むことができる。履歴データは、ユーザデバイスを用いて行われた以前の通信に対応するテーブルから取り出すことができ、テーブルのそれぞれは、ユーザデバイスの異なるデバイスサブ状態に対応し、異なる宛先に対する以前の通信の複数の連絡測定値を含む。一実施例としては、ブロック３７＿１０６は、１つ以上の状態変数を用いて１つ以上の状態変数に対応するテーブルの第１のセットを識別し、その後、テーブルの第１のセットから１つ以上の潜在的な宛先に対する連絡測定値を得ることを含むことができる。

ブロック３７＿１０８では、コンテキスト情報は履歴データと比較される。ブロック３７＿１０８は、ブロック３７＿１０６で識別されたテーブルの第１のセットを問い合わせ、テーブルのセット内の履歴データとコンテキスト情報との間の相関関係を判定することを含むことができる。

ブロック３７＿１１０では、通信の１つ以上の宛先が予測される。図３７－１に示すように、宛先は、ブロック３７＿１０８で実行された比較に基づいて予測される。一実施例としては、電子メールが勤務時間中にユーザデバイスが職場ロケーションにある間に、仕事の電子メールアカウントを用いて構成されている場合は、仕事の電子メールアドレスを有する以前に使用した連絡先が、予測された宛先として識別され得る。一部の実施形態では、１つを超える宛先が識別され得る。

ブロック３７＿１１０は、予測エンジン又は予測モデルを使用して予測された宛先を識別することができる。例えば、予測モデルは、特定のトリガーイベントに対して選択されてもよい。予測モデルは、コンテキスト情報を使用して、宛先（単数又は複数）を識別することができ、例えば、異なる宛先との相互作用又は通信は、異なるコンテキストでより可能性が高い場合がある。一部の実施形態は、例えば、デバイスを使用中、デバイスとのユーザの過去相互作用から判定され、ユーザによって選択される提案された宛先の確率が十分にある場合しか宛先を提案できない。過去相互作用の例としては、ユーザが電子メールアプリケーション、テキストメッセージ（例えば、ＳＭＳベースのメッセージング）、インスタントメッセージアプリケーション、及びテレビ会議アプリケーションを用いて、宛先とやりとりした通信の少なくとも一部分を含むことができる。

一部の実施形態では、過去の通信及び相互作用に基づいた社会的要素が宛先を予測するのに使用され得る。例えば、ブロック３７＿１０６で得られた履歴データは、以前に送信された電子メールの宛先を重み付けするのに使用され得る。社会的要素は、ユーザデバイスのユーザとユーザの通信の過去の宛先のグループ（例えば、連絡先及び連絡先のグループ）との間の過去相互作用データを反映する。共起（すなわち、同じグループの宛先に送信された通信）が、電子メールの宛先を予測するのに使用され得る。例えば、社会的要素は、ユーザが電子メールを送信したことがある各宛先を重み付けすることができ、より高い重み付けは、宛先のグループ（例えば、ＣＣリスト又は連絡先の規定されたグループ）に繰り返して含まれたことがある宛先に割り当てられる。宛先は、それぞれの電子メールアドレスによって履歴データ内で個別に識別され得る。社会的要素の重み付けは、受信した電子メールに比べて送信した電子メールメッセージに対してより高い場合がある。社会的要素はまた、ユーザが電子メールメッセージを送信するのに使用したことがある電子メールアカウント（例えば、私的なアカウント又は仕事のアカウント）に基づいて重み付けされてもよい。コンテキスト情報が電子メールが構成されていることを示す場合、社会的要素は、過去の電子メールメッセージについての宛先の共起を識別するのに使用され得る。これらの共起はひいては、特にユーザが過去の電子メールメッセージ内の宛先のグループに含まれたことがある宛先を選択するときに、構成中の電子メールの宛先を予測するのに使用され得る。

ブロック３７＿１１２では、１つ以上の予測された宛先のインジケーションがユーザに提供される。ブロック３７＿１１２は、ユーザデバイスのユーザインタフェース内、又はユーザデバイス上で実行される通信アプリケーション内に１つ以上の予測された宛先のリストを提示することを含むことができる。一部の実施形態では、ブロック３７＿１１２で実行中のアプリケーションに関連してアクションが実行され得る。一実施形態では、アクションは、ユーザが１つ以上の予測された宛先を選択するためのユーザインタフェースを表示することとすることができる。ユーザインタフェースは、デバイスのスクリーン上に表示すること、表面に投影すること、あるいはオーディオインタフェースを提供することなど、様々な方法で提供されてもよい。

他の実施形態では、アプリケーションが実行されてもよく、アプリケーション固有のユーザインタフェースがユーザに提供されてもよい。宛先、例えば、通信の潜在的宛先の識別に応答してユーザインタフェースのどちらかを提供してもよい。他の実装形態では、アプリケーションと相互作用するためのユーザインタフェースは、ユーザが（例えば、パスワード又はバイオメトリックによって）認証された後、提供されてもよいが、かかるユーザインタフェースは、提案された宛先のリストを有するインタフェースなど、ただのホームスクリーンより具体的であろう。
ＩＩ．宛先予測を開始するイベント

トリガーイベントは、ユーザに提供するための１つ以上の宛先の識別をトリガーするイベントの所定のセットとすることができる。イベントはデバイスコンポーネントによって生成された信号を用いて検出することができる。トリガーイベントがどのように検出されるかについての詳細は、図３７－２を参照して以下に更に詳細に検討する。

図３７－２は本発明の実施形態に係る、トリガーイベントを判定する検出システム３７＿２００の簡略ブロック図を図示する。検出システム３７＿２００はトリガーイベントが判定されているデバイス内に常駐することができる。図示するように、検出システム３７＿２００は複数の異なるイベントを検出することができる。検出されたイベントのうちの１つ以上は、検出システム３７＿２００によってトリガーイベントであることを判定され得る。その後、他の処理モジュールはトリガーイベントを用いて処理を実行することができる。
Ａ．イベントの検出

実施形態では、検出システム３７＿２００は、トリガーイベントを検出するためのハードウェア及びソフトウェアコンポーネントを含む。一実施例としては、検出システム３７＿２００は、入力デバイス３７＿２０２などの複数の入力デバイスを含むことができる。入力デバイス３７＿２０２はイベントに応答して信号を生成可能な任意の好適なデバイスとすることができる。例えば、入力デバイス３７＿２０２はユーザ相互作用入力デバイス３７＿２０４、及びロケーション入力デバイス３７＿２０６を含むことができ、それらはそれぞれ、デバイス接続イベント、ユーザ相互作用イベント、及びロケーションのイベントを検出することができる。イベントが入力デバイスで検出されると、入力デバイスは、更に分析するために特定のイベントを示す信号を送信することができる。

一部の実施形態では、コンポーネントの集合は、単一のイベントに寄与することができる。例えば、モーションセンサ、ＧＰＳロケーションデバイス、及びタイムスタンプに基づいて人が仕事へ、又は仕事から通勤することを検出することができる。
１．ユーザ相互作用イベント

ユーザ相互作用入力デバイス３７＿２０４はユーザ相互作用イベントを検出するよう利用されてもよい。ユーザ相互作用イベントはユーザがデバイスと相互作用したときに発生する場合がある。一部の実施形態では、ユーザは、ユーザ相互作用入力デバイス３７＿２０４のうちの１つを介してアプリケーションの表示されたユーザインタフェースに入力を提供することができる。他の実施形態では、ユーザインタフェースは表示されなくてもよいが、依然として、デバイスを振る、又はいくつかの他のタイプのジャスチャを行うユーザを介してユーザにアクセス可能である。更に、相互作用は、例えば、状態エンジンがデバイスのセンサからの値を使用する場合は、ユーザインタフェースを含まなくてもよい。

ユーザインタフェースの任意の好適なデバイスコンポーネントは、ユーザ相互作用入力デバイス３７＿２０４として使用され得る。好適なユーザ相互作用入力デバイスの例は、ボタン３７＿２０８（例えば、ホームボタン又は電源ボタン）、タッチスクリーン３７＿２１０、カメラ３７＿２１２，加速度計３７＿２１４、マイクロフォン３７＿２１６及びマウス３７＿２１８である。例えば、ホームボタン、電源ボタン、及び音量ボタンなどのモバイルデバイスのボタン３７＿２０８は、ユーザ相互作用入力デバイス３７＿２０４とすることができる。それに加えて、サイレントモードスイッチなどのスイッチは、ユーザ相互作用入力デバイス３７＿２０４とすることができる。また、例えば、音声コマンドを検出するように構成された一体型マイクロフォンなどのモバイルデバイスのマイクロフォン３７＿２１６は、ユーザ相互作用入力デバイス３７＿２０４とすることができる。更に例えば、マウス３７＿２１８又はスタイラスなどのポインティングデバイスは、通信アプリケーションにユーザ入力を提供するのに使用されるユーザ相互作用入力デバイス３７＿２０４とすることができる。

ユーザがデバイスと相互作用する場合、ユーザがアプリケーションにユーザ入力を提供したと判定されてもよく、また対応するトリガーイベントが生成されてもよい。かかるイベントは、デバイスの現在の状態、例えば、デバイスが位置する場所、又はイベントが発生する時に依存する場合がある。つまり、トリガーイベントは、デバイスのロケーション状態（例えば、職場ロケーション）及び時間コンテキスト（例えば、平日の朝）と併せてユーザ相互作用入力デバイス３７＿２０４からの入力に部分的に基づいて生成され得る。かかる情報はまた、イベントがトリガーイベントかどうかを判定する際に使用される場合もある。

タッチスクリーン３７＿２１０はユーザがディスプレイスクリーンを介してユーザ入力を提供するのを可能にすることができる。例えば、ユーザは、ディスプレイを自身の指をスワイプしてユーザ入力信号を生成することができる。ユーザがアクションを実行する場合、対応するトリガーイベント３７＿２２８が検出されてもよい。

加速度計３７＿２１８又は他のモーションセンサは、（例えば、ジャイロメーター又はコンパスを用いて）振動する及び傾くなどのモバイルデバイスの動きを検出するパッシブコンポーネントとすることができる。モバイルデバイスのかかる動きは、その動きが特定のタイプのものかを判定できるイベントマネージャー３７＿２３０によって検出することができる。イベントマネージャー３７＿２３０は、デバイスの所与の状態における特定のタイプのユーザ相互作用イベントに対応するイベント信号３７＿２３２を生成することができる。デバイスの状態は、状態エンジンによって判定でき、その更なる詳細は、「Ａｃｔｉｖｉｔｙ Ｄｅｔｅｃｔｉｏｎ」と題する米国特許公開第２０１２／０３１０５８７号、及び「Ｄｅｔｅｒｍｉｎｉｎｇ Ｅｘｉｔ Ｆｒｏｍ Ａ Ｖｅｈｉｃｌｅ」と題する米国特許公開第２０１５／００５０９２３号に見られ、その開示はその全体が参照により組み込まれる。

一例は、ユーザがランニングしている場合であり、加速度計は振動を感知し、イベントマネージャー３７＿２３０に提供される信号を生成することができる。イベントマネージャー３７＿２３０は加速度計信号を分析し、イベントのタイプを判定することができる。イベントのタイプが判定されると、イベントマネージャー３７＿２３０はイベントのタイプに対応するイベント信号３７＿２３２を生成することができる。モバイルデバイスはまた、ユーザがランニングしていることを示す方法で移動することができる。こうして、この特定のユーザ相互作用はランニングイベントとして識別され得る。その後、イベントマネージャー３７＿２３０はランニングイベントが検出されたことを示すイベント信号３７＿２３２を生成かつ送信することができる。
２．ロケーションイベント

ロケーション入力デバイス３７＿２０６はロケーションイベントを生成するのに使用され得る。ロケーションイベントは、宛先の提案をトリガーするために、ユーザ相互作用イベントと組み合わせて使用され得る。任意の好適な測位システムはロケーションイベントを生成するのに使用され得る。例えば、全地球測位システム（ＧＰＳ）はロケーションイベントを生成するのに使用され得る。ロケーションイベントは特定の地理的ロケーションに対応するイベントとすることができる。一実施例としては、モバイルデバイスが特定のロケーションに到着した場合、ＧＰＳコンポーネントはロケーションイベントに対応する入力信号を生成することができる。
Ｂ．トリガーイベントの判定

図３７－２に更に図示するように、入力デバイス３７＿２０２は、例えば、対応するイベントのいずれかの結果として検出されたイベント３７＿２２２を出力することができる。検出されたイベントは、どの入力デバイスが検出されたイベント３７＿２２２に対する信号、特定のイベントに対するサブタイプ（例えば、ヘッドホン又はデータ接続がどのタイプか）についての情報を含むことができる。かかる情報は、検出されたイベント３７＿２２２はトリガーイベントであるかどうかを判定するのに使用してもよく、どの予測モデルを使用するか、又は提案された宛先に対してどのアクションを実行するか（例えば、電子メールを構成する、カレンダーの招待を作成する、音声通話又はテレビ通話を開始する）を判定するため、後のモジュールに渡すことができる。

検出されたイベント３７＿２２２はイベントマネージャー３７＿２３０によって受信することができる。イベントマネージャー３７＿２３０は入力デバイス３７＿２０２から信号を受信でき、どんなタイプのイベントが検出されるかを判定することができる。イベントのタイプに応じて、イベントマネージャー３７＿２３０は信号（例えば、イベント信号３７＿２３２）を異なるエンジンに出力してもよい。異なるエンジンは、その機能にとって重要である特定のイベント信号３７＿２３２を受信するようイベントマネージャー３７＿２３０によりサブスクリプションを有してもよい。例えば、トリガーイベントエンジン３７＿２２４は、入力デバイス３７＿２０２からの検出されたイベント３７＿２２２に応答して生成されたイベント信号３７＿２３２を受信するように加入されてもよい。イベント信号３７＿２３２は検出されたイベント３７＿２２２から判定されたイベントのタイプに対応することができる。

トリガーイベントエンジン３７＿２２４は、検出されたイベント３７＿２２２がトリガーイベントであるかどうかを判定するように構成されてもよい。この判定を行うには、トリガーイベントエンジン３７＿２２４は、指定されたトリガーイベントデータベース３７＿２２６を参照することができ、それは、トリガーイベントエンジン３７＿２２４に連結されてもよい。指定されたトリガーイベントデータベース３７＿２２６はトリガーイベントとして指定された所定のイベントのリストを含むことができる。

トリガーイベントエンジン３７＿２２４は受信した検出されたイベント３７＿２２２と所定のイベントのリストと比較して、検出されたイベント３７＿２２２が指定されたトリガーイベントデータベース３７＿２２６内にリストされた所定のイベントと一致する場合、トリガーイベント３７＿２２８を出力することができる。所定のイベントのリストの例としては、以下の任意の１つ以上を含むことができる。（１）通信アプリケーションにアクセスすること、（２）検索を開始すること、（３）通信を構成すること、（４）デバイスの特定のタイプの動きを感知すること、及び（５）特定のロケーションに到着すること。（５）については、指定されたトリガーイベントデータベース３７＿２２６は特定のロケーションの明細を含むことができる。所定のイベント（１）～（５）のそれぞれについては、イベント発生の時刻又は時間の範囲が指定されたトリガーイベントデータベース３７＿２２６に含まれてもよい。例えば、指定されたトリガーイベントデータベース３７＿２２６は、午前８時～午前１０時の間に職場のロケーションへの到着の感知に対応する指定されたトリガーイベントを記憶することができる。
ＩＩＩ．提案された宛先の判定

トリガーイベントが検出されると、１つ以上の潜在的な宛先はトリガーイベントに基づいて識別することができる。一部の実施形態では、宛先（単数又は複数）の識別は、事前にプログラムされたアクションではない。逆に、宛先（単数又は複数）の識別は、追加情報に応じて変化し得る動的なアクションとすることができる。例えば、提案された宛先（単数又は複数）の識別は、コンテキスト情報及び／又は人々中心の過去相互作用情報に基づいて、並びに他の情報に基づいて判定することができる。

特定のトリガーイベントが発生する（例えば、デバイス上で電子メールクライアント、カレンダーアプリケーション、インスタントメッセージングアプリケーション、又はテレビ会議アプリケーションにアクセスする）たびに、デバイスは、どの宛先（単数又は複数）がイベントに関連して通信の宛先として選択されるかを追跡することができる。特定のイベントの発生それぞれに応答して、デバイスは、選択された宛先に対応するデータポイント、アプリケーションを用いて実行された宛先との相互作用、及びイベントを保存することができる。各種実施形態では、データポイントは、個々に保存するか、あるいは集約することができ、カウントは、特定の宛先が選択される回数に対して判定され、それは特定のアクションに対するカウントを含んでもよい。例えば、ある宛先に送信された電子メールの数を示すカウントは、どの電子メールアカウントがその電子メールを送信するのに使用されたか、その電子メールが送信された時刻、及び電子メールが送信されたときのデバイスのロケーションを示す情報と共に保存されてもよい。本例では、データポイントはまた、宛先が電子メールの最初の受取人である回数、宛先が電子メールグループ又は分配リストの部分として含まれた回数、宛先がコピーされた（例えば、カーボンコピー／ＣＣ、又はブラインドカーボンコピー／ＢＣＣ）回数を示すこともできる。こうして、異なるカウントが、選択された同一の宛先に対する異なるアクションに対して判定される。

宛先との以前のユーザ相互作用及び通信を示す履歴データは、所与の宛先が将来の通信の宛先として提案されるべきかを予測する予測モデルへの入力として使用され得る。例えば、宛先を予測する／提案するために用いられる履歴データは、他のユーザとの過去の相互作用（すなわち、過去相互作用）の記録を含むことができる。かかる過去相互作用の例としては、音声通話、電子メール、カレンダーエントリ／イベント、インスタントメッセージ、テキストメッセージ（例えば、ＳＭＳベースのメッセージ）、テレビ会議、及びテレビ通話が挙げられる。例えば、過去相互作用は、過去の音声通話に対応する時刻、持続時間、及び（電話番号によって識別された）宛先を示す通話履歴を含むことができる。また、例えば、過去相互作用は、過去の電子メールメッセージに対応する時刻、周期性（例えば、毎日、毎週）、及び（電子メールアドレスによって識別された）宛先を示す電子メールの履歴を含むことができる。

特定のイベントが検出されると、特定のイベントに対応する予測モデルが選択され得る。予測モデルは、トレーニング手順への入力として、特定のイベントに対応する過去相互作用データを用いて判定されるであろう。しかし、異なる宛先が異なるコンテキストで選択されている状態で、履歴データは異なる多くのコンテキスト（すなわち、コンテキスト情報の異なる組み合わせ）において発生する場合がある。こうして、集約されると、過去相互作用データは、特定のイベントが発生するときに明らかにユーザによって選択されることになる宛先を提案しない場合がある。

予測モデルは、特定のイベントに対応することができる。連絡するための提案された宛先は、コンピューティングデバイスの１つ以上のプロパティを用いて判定され得る。例えば、特定のサブモデルは、イベントの出来事の後の、他のユーザとのユーザ相互作用に対応する履歴データのサブセットから生成され得る。過去相互作用データのサブセットは、デバイスが１つ以上のプロパティを有する場合に収集され得る（例えば、特定のロケーション及び／又は時間帯のプロパティを有する、電子メールアプリケーションにアクセスするイベントの後に選択された宛先との過去相互作用）。予測モデルは、サブモデルから構成され得、各サブモデルはコンテキストデータの異なる組み合わせに対するものである。異なる組み合わせは、異なる量のコンテキストデータを有することができる。サブモデルは、階層木で生成され得、より具体的な組み合わせのサブモデルは階層木の下位にある。一部の実施形態では、サブモデルが木の高位のモデルより高精度に宛先を予測できる場合しか、サブモデルは生成できない。このように、より正確な予測は、どのアプリケーションをユーザが選択することになるかに対して行われ得る。一部の実施形態では、予測モデル及びサブモデルは、特定の組み合わせのコンテキストデータが存在するイベントの後に、ユーザによって選択される上位Ｎ個の宛先（例えば、パーセンテージの固定数）を識別してもよい。

ニューラルネットワーク又は回帰などのモデルは、特定のコンテキストに対する特定のアプリケーションを識別するようにトレーニングされる場合があるが、これは、対応する履歴データのすべてを用いる場合に困難になる場合がある。すべての過去相互作用データを用いると、結果的に、予測モデルを過剰適合し精度が低くなることになる。本発明の実施形態は、履歴データを、それぞれが異なるコンテキストに対応する、履歴データの異なる入力セットにセグメント化することができる。異なるサブモデルは、履歴データの異なる入力セットにおいてトレーニングされ得る。
Ａ．異なるコンテキストデータに基づく異なるモデル

特定のイベントが発生する場合、デバイスは様々なコンテキスト、例えば、異なるロケーション（職場、自宅、又は学校など）、異なる時刻、異なる曜日（営業日又は週末など）、デバイスの異なるモーション状態（ランニング、歩行、車でドライブ、又は静止など）、又は通信アプリケーションの異なる使用状態（電子メールを構成する、又はカレンダーエントリを作成するのに使用されるなど）にあり得る。コンテキスト情報は、検出されたイベントと関連して取り出される、例えば、イベントが検出された後に取り出される場合がある。コンテキスト情報は、予測されたどの宛先が検出されたイベントに関連して通信の宛先に選択されるかの予測を支援するのに用いられる場合がある。異なるロケーションが、ＧＰＳセンサを用いて判定でき、また時刻は、前の通信が送受信された時に基づいて判定できる。異なるモーション状態は、加速度計、ジャイロメーター、又はＧＰＳセンサなどのモーションセンサを用いて判定することができる。

実施形態は、コンテキスト情報を様々な方法で使用することができる。一実施例では、１つのコンテキストデータ（例えば、デバイスの一つのプロパティに対応する）は、どの宛先（単数又は複数）が最も選択されそうかを予測するのに用いられる場合がある。例えば、デバイスの特定のロケーションは、予測モデルへの入力として提供され得る。

別の実施例では、コンテキスト情報のコンテキストデータのうち一部又は全部はセグメント化プロセスで使用される場合がある。特定の１つのコンテキストデータは、入力履歴データをセグメント化するのに用いられ得るので、特定のサブモデルは、そのコンテキストデータの対応プロパティに対応する履歴データを用いてしか判定されない。例えば、デバイスの特定のロケーションはサブモデルへの入力として用いられないが、どのサブモデルを使用するか、またそれに対応して、特定のサブモデルを生成するために、どの入力データを使用するか選択するのに使用されるであろう。

こうして、一部の実施形態では、特定のコンテキストデータはどのサブモデルを使用するかを識別するのに使用される場合があり、また他のコンテキストデータは、ユーザが相互作用し得るのはどの宛先（単数又は複数）かを予測するため、サブモデルへの入力として用いられる場合がある。特定のプロパティ（例えば、特定のロケーション）は、特定のサブモデルに対応せず、特定のプロパティは使用されるサブモデルに対する特徴（入力）として用いられる場合がある。特定のプロパティが特定のサブモデルに対応している場合、そのプロパティの使用は、全モデルが特定のプロパティに割り当てられるので、豊富になることができる。

サブモデルを特定のプロパティ（又はプロパティの組み合わせ）に割り当てることの一つの欠点は、その特定のプロパティに対応する大量の履歴データが存在しない場合があることである。例えば、ユーザは、特定のロケーションで数回、特定のイベント（例えば、電子メールを構成する）しか実行しなかった可能性がある。この限定されたデータ量はまた、データが乏しいとも言われる。データは、プロパティの組み合わせが、例えば、特定のロケーションで特定の時刻に使用された場合、更に乏しくなる場合がある。この欠点を対処するため、実施形態は、新しいサブモデルをセグメント化プロセスの一部としていつ生成するかを選択して判定することができる。
１．既定モデル

デバイスがユーザによって初めて入手（例えば、購入）されると、既定モデルが使用され得る。既定モデルは、イベントのグループ（例えば、トリガーイベントと指定されるすべてのイベント）に適用することができる。既定モデルは、ユーザに関連付けられた他のデバイスから集約されたデータをシードにすることができる。一部の実施形態では、既定モデルは、例えば、任意の一つのコンテキストに対して利用できるデータが十分でないので、コンテキストにかかわらず、単に最も人気のある宛先を選ぶことができる。より多くのデータが収集されると、既定モデルを廃棄することができる。

一部の実施形態では、既定モデルは、提案される所定の宛先（単数又は複数）及び実行されるアクションを特定するハードコードされたロジックを有することができる。このようにして、ユーザがどのように応答するか（例えば、否定的な応答はユーザが提案された宛先を選択しない）についてユーザは深く調査される場合があり、それにより、単に肯定的な応答の使用を追跡する追加データを提供することができる。かかる既定モデルと並列に、その予測と実際の結果を比較するため、予測モデルが実行される場合がある。その後、予測モデルは、実際の結果に応答して精緻化され得る。予測モデルが十分な信頼度を有する場合、既定モデルから予測モデルに切り替えを行うことができる。同様に、サブモデルの性能を追跡することができる。サブモデルが十分な信頼度を有する場合、サブモデルは、所与のコンテキストに対して使用され得る。一部の実施形態では、異なるイベントに対する異なるサブモデルが存在する。例えば、電子メールのサブモデルは、電子メールの宛先を予測する電子メールコンテキストに対して使用され得、また別個のカレンダーサブモデルは、カレンダーイベントの参加者を予測するのに使用され得る。これらの異なるサブモデルは、過去相互作用データベース内の対応するテーブルからのデータを使用して、以前の電子メール及びカレンダーの招待の宛先を識別することができる。本例では、電子メールテーブルは、ユーザが以前にメッセージに追加した宛先を示す過去の電子メールメッセージの記録を有することができる。同様に、過去相互作用データベース内のカレンダーテーブルは、カレンダーイベントに招待されたユーザを示す過去のカレンダーイベントの記録を有することができる。
２．初期トレーニング

予測モデル（例えば、イベントモデル）は、これまで収集された履歴データを用いて初期トレーニングを受けることができ、この場合モデルはユーザに宛先の提案を提供しない。トレーニングは、初期トレーニングと呼ばれる場合がある。予測モデルは、定期的に（例えば、毎日）バックグラウンドプロセスの一部として更新される場合があり、それはデバイスが充電中で使用されていないときに発生してもよい。トレーニングは、正確な予測数を最適化すると共に、過去相互作用データ内の実際の結果と比較されるようにモデルの係数を最適化することを伴う場合がある。別の実施例では、トレーニングは、実際に選択された上位Ｎ（例えば、所定の数、所定のパーセンテージ）のアプリケーションを識別することを含んでもよい。トレーニング後、モデルの精度は、モデルが提案された宛先（及び対応する潜在的なタイプの相互作用）をユーザに提供するのに用いられるべきかを判定するのに測定され得る。

モデルが十分な精度を得る（例えば、最上位選択アプリケーションが十分に高い精度で選択されている）と、モデルを実装することができる。かかる出来事は、最上位水準のモデル（例えば、最初のイベントモデル）には起こらない場合があるが、サブモデルが特定のコンテキストに対してテストされた場合は、発生する場合がある。したがって、かかる初期トレーニングは、サブモデルに対して同様に実行することができる。
Ｂ．多くのデータが得られる際のセグメント化

ユーザが最初にデバイスを使用し始めると、特定のイベント後（例えば、電子メールアプリケーション、カレンダーアプリケーション、テレビ会議アプリケーション、又はカレンダーアプリケーションにアクセスした後）にユーザが相互作用するのに選択し得る宛先についての予測を行うための過去相互作用データが存在しないであろう。初期モードでは、予測された宛先は提案されないが、過去相互作用データを得ることができる。より多くの履歴データが得られるにつれて、予測モデルをサブモデルにセグメント化するかどうかについての判定を行うことができる。更に多くの過去相互作用データを用いると、サブモデルは更なるサブモデルにセグメント化され得る。宛先とのユーザ相互作用に利用可能な履歴データが限定されている場合、いかなる宛先も提案されないことがあり、あるいはより一般的なモデルが使用される場合がある。

セグメント化プロセスは、ユーザデバイス（例えば、スマートホンなどのモバイルデバイス）によって実行され得、それは、データのプライバシーを保持することができる。他の実施形態では、セグメント化プロセスは、ユーザデバイスと通信しているサーバによって実行することができる。セグメント化プロセスは、期間にわたって（例えば、数日又は数ヶ月にわたって）部分的に実行することができ、あるいはセグメント化プロセスの全部を同時に実行することができ、また定期的に潜在的に再実行することができる。セグメント化プロセスは宛先予測エンジンのルーチンとして実行されることができる。

より多くのデータが収集されるにつれて、予測モデルはサブモデルにセグメント化され得る。データを収集する異なるポイントにおいて、セグメント化は発生する場合がある。一層多くのデータが得られるにつれて、別のセグメント化が発生する場合がある。各セグメント化は、完全にセグメント化を再実行することを伴う場合があり、それは、以前のセグメント化と同じサブモデルの作成が生じる場合も、生じない場合もある。

本例では、第１のイベントモデルは特定のイベント（例えば、電子メールを、同僚などの特定の連絡先に送信する）に対応することができる。イベントモデルは、特定のイベントの予測エンジンの最上位水準に対応することができる。初期には、特定のイベントのたった一つのモデルしか存在しない場合があり、最小限度の過去相互作用データしか利用できない。この時点では、イベントモデルはトレーニング目的で履歴データを追跡できるだけである。イベントモデルは予測を行うことができ、これらの予測を実際の結果と比較することができる（例えば、イベントが検出された後、特定の時間内にユーザが提案された宛先と相互作用するかどうか）。閾値より高い確率を有する宛先がない場合、特定のイベントが発生しても、宛先は提案されない場合がある。

一部の実施形態では、イベントモデルは、特定のデバイスに対して収集されたデータのみを使用する。他の実施形態では、イベントモデルは、ユーザに関連付けられた他のデバイスから集約された過去相互作用データをシードにすることができる。かかる過去相互作用データはイベントモデルが一部の宛先の推薦を提供できるようにする場合があり、その後、追加のデータポイントを得るのを可能にすることができる。例えば、ユーザが特定のアプリケーション（例えば、電子メール、オーディオ通話、テレビ会議、インスタントメッセージ、又はテキストメッセージ）を介して提案された宛先と相互作用するかどうかを追跡でき、それにより、単にユーザが宛先を選択するかどうかより多くのデータポイントを提供することができる。

多くのデータが収集されるにつれて、セグメント化が発生すべきかどうかについて定期的に判定を行うことができる。かかる判定は、より高精度がセグメント化を介して達成できるかどうかに基づくことができる。精度は、以下に詳細に説明するが、予測が行われ得る確率の水準として測定することができる。例えば、宛先を、イベントモデルを用いるより、サブモデルに対して高水準の確率で予測できる場合、セグメント化を行ってもよい。また、１つ以上の他の基準も用いて、サブモデルがセグメント化プロセスの一部として作成されるべきかどうかを判定することができる。例えば、基準は、サブモデルが実装される前に、サブモデルが統計的に有意な量の入力履歴データを有していなくてはいけないこととすることができる。少ないデータ量でトレーニングされたモデルは不正確となる場合があるので、データ量の要件により、サブモデルに安定性を向上させ、最終的に、精度を向上させることができる。
Ｃ．トリガーイベントに基づいて宛先を提案するシステム

図３７－３は、本発明の実施形態に係る、トリガーイベント及びコンテキスト情報に基づいて宛先及び対応するアクションコマンドを識別する予測システム３７＿３００の簡略ブロック図を図示する。予測システム３７＿３００はアプリケーションを識別しているデバイス内に常駐する。予測システム３７＿３００はハードウェア及びソフトウェアコンポーネントを含むことができる。

予測システム３７＿３００は提案された宛先（単数又は複数）を識別する予測エンジン３７＿３０２を含む。予測エンジン３７＿３０２は、トリガーイベントを受信することができる。予測エンジン３７＿３０２は、提案された宛先３７＿３０４を識別するため、トリガーイベント３７＿３２８から収集された情報を使用してもよい。図示するように、予測エンジン３７＿３０２は、トリガーイベント３７＿３２８に加えてコンテキストデータ３７＿３０６を受信することができる。予測エンジン３７＿３０２は、提案された宛先３７＿３０４を識別するため、トリガーイベント３７＿３２８及びコンテキスト情報３７＿３０６の両方から収集された情報を使用してもよい。実施形態では、受信したコンテキストデータ３７＿３０６に基づいて、予測エンジン３７＿３０２は異なるモデルを用いて、異なるタイプの通信に対して提案された宛先を識別する。例えば、予測エンジン３７＿３０２は、コンテキストデータ３７＿３０６が電子メールアプリケーションがアクセスされているか、又は電子メールが構成されていることを示す場合は、電子メールのサブモデルを使用することができる。電子メールのサブモデルは、かかるコンテキストデータ３７＿３０６を履歴イベントデータベース３７＿３１６からの履歴電子メールデータと併せて使用し、電子メールの宛先を予測することができる。電子メールのサブモデルは、電子メールの宛先を予測するのに使用され得、また別個のカレンダーサブモデルは、カレンダーイベントの参加者を予測するのに使用され得る。予測エンジン３７＿３０２はまた、実行されるアクション、例えば、ユーザインタフェースが、提案された宛先と相互作用するために、ユーザに対して、どのように、いつ提供されるかを判定することもできる。
１．コンテキスト情報

コンテキスト情報はコンテキストデータ３７＿３０６から収集することができる。実施形態では、コンテキスト情報はいつでも受信することができる。例えば、コンテキスト情報はトリガーイベント３７＿３２８が検出される前及び／又は検出された後に受信され得る。それに加えて、コンテキスト情報は、トリガーイベント３７＿３２８を検出中に受信されてもよい。コンテキスト情報は特定のコンテキストに対してデバイスの１つ以上のプロパティを特定することができる。コンテキストは、トリガーイベント３７＿３２８が検出されたときのデバイスの周囲の環境（コンテキストのタイプ）としてもよい。例えば、コンテキスト情報はトリガーイベント３７＿３２８が検出されたときの時間帯としてもよい。別の実施例では、コンテキスト情報は、トリガーイベント３７＿３２８が検出されたときのデバイスの特定のロケーションとしてもよい。更に別の実施例では、コンテキスト情報は、トリガーイベント３７＿３２８が検出されたときの年の特定の日付としてもよい。かかるコンテキスト情報は、予測エンジン３７＿３０２がそのコンテキストでユーザによって宛先として選択される可能性のある宛先を正確に提案できるようにデバイスのコンテキストについてのより有意義な情報を提供してもよい。したがって、コンテキスト情報を利用する予測エンジン３７＿３０２は、コンテキスト情報が利用されなかった場合より正確に宛先をユーザに提案することができる。

コンテキストデータ３７＿３０６はコンテキストソース３７＿３０８によって収集され得る。コンテキストソース３７＿３０８は、モバイルデバイスの現在の状況に関するデータを提供するモバイルデバイスのコンポーネントとすることができる。例えば、コンテキストソース３７＿３０８は、時間帯、デバイスのロケーション、及び日付にそれぞれ関連する情報を提供するための内部デジタル時計３７＿３１０、ＧＰＳデバイス３７＿３１２、及びカレンダー３７＿３１４として動作するハードウェアデバイス及び／又はソフトウェアコードとすることができる。他のコンテキストソースが使用されてもよい。

予測エンジン３７＿３０２に対するコンテキストデータ３７＿３０６の収集は、電力効率的な方法で実行されてもよい。例えば、デバイスのロケーションを判定するためのＧＰＳ３７＿３１２の継続的なポーリングは、過度に電力を消費する場合があり、それにより、バッテリ寿命を低下させる場合がある。バッテリ寿命の低下を回避するため、予測エンジン３７＿３０２は、ＧＰＳ３７＿３１２以外のソースからデバイスのロケーションを要求することによってデバイスのロケーションを判定することができる。ロケーション情報のための別のソースは、最近、デバイスのロケーションを求めてＧＰＳ３７＿３１２をポーリングしたアプリケーションとすることができる。例えば、アプリケーションＡがデバイスのロケーションを求めてＧＰＳ３７＿３１２をポーリングした一番最近のアプリケーションである場合、予測エンジン３７＿３０２は、別々にＧＰＳ３７＿３１２をポーリングするのではなく、アプリケーションＡからロケーションデータを要求及び受信することができる。
２．履歴情報

コンテキストソース３７＿３０８に加えて、履歴イベントデータベース３７＿３１６も、特定の実施形態において予測エンジン３７＿３０２によって利用されてもよい。履歴イベントデータベース３７＿３１６は、トリガーイベントが検出された後のユーザとモバイルデバイスとの間の前の相互作用からなる履歴情報を含むことができる。

履歴イベントデータベース３７＿３１６は、特定のトリガーイベントに続いてユーザが宛先と相互作用した回数の記録を保持することができる。例えば、データベース３７＿３１６は、ユーザが、宛先Ａを含めるときは１０回中８回宛先Ｂを電子メール又はカレンダーの招待に含めることを示す記録を保持することができる。したがって、予測エンジン３７＿３０２は、宛先Ａが電子メール又はカレンダー通信に選択されたとき、宛先Ｂがユーザに識別されるべきかを判定するために、この情報を履歴データ３７＿３１８として受信することができる。

履歴イベントデータベース３７＿３１６はまた、トリガーイベントが検出されたとき、宛先が、異なるコンテキスト下で相互作用された回数の記録を保持することもできる。例えば、データベース３７＿３１６は、ユーザが自宅にいるとき、ユーザが私的な電子メールアカウントにアクセスした後、１０回中９回宛先Ａと相互作用することの記録を保持し、ユーザが職場のロケーションにいるときは、１０回中１回、仕事の電子メールアカウントを用いて相互作用することを示す記録を保持することができる。したがって、予測エンジン３７＿３０２は、この情報を履歴データ３７＿３１８として受信し、ユーザが自宅で私的な電子メールアカウントにアクセスするときは、宛先Ａが提案されるべきであるが、職場で、仕事の電子メールアカウントにアクセスするときは、提案されるべきではないと判定することができる。本セクションで検討した例は「自宅」又は「仕事」としてロケーションを参照するが、「自宅」又は「仕事」を表すコンテキストデータ３７＿３０６は数値座標、例えば、地理座標の形式にすることができることを理解すべきである。当業者は、時間帯、曜日及び日付に関連する時間情報が、宛先を識別するのと同じ方法でロケーションの代わりに使用される場合があることを理解するものである。

履歴イベントデータベース３７＿３１６はまた、どれくらいの頻度で、かつどんな状況下でユーザが識別された宛先を通信の宛先として選択しないように決めるかの記録を保持することができる。例えば、データベース３７＿３１６は、ユーザが自宅でヘッドセットをデバイスに挿入したとき、人がユーザに提案された１０回中２回は、ユーザが電話機通話の宛先Ｂを選択しなかったことを示す記録を保持することができる。したがって、予測エンジン３７＿３０２は、この情報を履歴データ３７＿３１８として受信し、ユーザが自宅でヘッドセットをデバイスに挿入するとき、宛先Ｂを提案する確率を調整することができる。

上述のように、本技術の一態様は、あるユーザが通信に興味を持ち得るユーザの予測を向上させるために、様々なソースから利用可能なデータを収集及び使用することである。本開示は、場合によっては、この収集されたデータが、特定の人を一意的に識別するか、又はその人に連絡するのに用いることができる個人情報データを含んでよいことを企図している。かかる個人情報データはロケーションベースのデータ、電話番号、電子メールアドレス、職場の住所、自宅の住所、過去の相互作用の記録、又は任意の他の識別情報を含むことができる。

本開示は、本技術における、このような個人情報データの使用は、ユーザの利益のために使用することができると認識している。例えば、個人情報データは、あるユーザが特定の時刻及び場所で通信をとりたいことがあるユーザを予測するのに使用され得る。したがって、コンテキスト情報に含まれるかかる個人情報データを使用することは、ユーザが特定の時刻及び場所で相互作用したいことがある人々の人々中心の予測を可能にする。

本開示は、このような個人情報データの収集、分析、開示、転送、記憶、又はその他の使用に関与するエンティティは、しっかり確立されたプライバシーポリシー及び／又はプライバシー慣行を遵守することを更に企図している。具体的には、そのようなエンティティは、個人情報データを秘密として厳重に保守するための業界又は政府の要件を満たすか又は上回るものとして一般に認識されている、プライバシーのポリシー及び慣行を実施し常に使用すべきである。例えば、ユーザからの個人情報は、そのエンティティの合法的かつ正当な使用のために収集されるべきであり、それらの合法的使用を除いて、共有又は販売されるべきではない。更に、そのような収集は、ユーザに告知して同意を受けた後にのみ実施するべきである。更に、そのようなエンティティは、そのような個人情報へのアクセスを保護して安全化し、その個人情報へのアクセスを有する他者が、自身のプライバシーポリシー及び手順を遵守することを保証するための、あらゆる必要な措置を講じることとなる。更には、そのようなエンティティは、広く受け入れられているプライバシーのポリシー及び慣行に対する自身の遵守を証明するために、第三者による評価を自らが受けることができる。

前述のことがらにもかかわらず、本開示はまた、ユーザが、個人情報データの使用又は個人情報データへのアクセスを選択的に阻止する実施形態も企図している。すなわち、本開示は、そのような個人情報データへのアクセスを防止又は阻止するためのハードウェア要素及び／又はソフトウェア要素を提供することができることを企図している。例えば、人々中心の予測サービスの場合、本技術は、ユーザがサービスの登録中に個人情報データの収集への参加の「オプトイン」又は「オプトアウト」を選択することを可能にするよう構成することができる。別の実施例では、ユーザは、宛先提案サービスのためにロケーション情報を提供しないように選択することができる。更に別の例では、ユーザは正確な位置情報を提供しないが、位置領域情報の転送を許可することを選択することができる。
Ｄ．ユーザインタフェース

図３７－４及び図３７－５は、提案された宛先のリストを提示するための例示的なユーザインタフェースを図示する。特に、図３７－４は、既に実行中の電子メールアプリケーションに関連付けられたデバイス３７＿４０２の例示的なユーザインタフェース３７＿４００を図示する。ユーザインタフェース３７＿４００は、クライアント電子メールアプリケーションのユーザインタフェースとすることができるが、本セクションでは、異なるアプリケーションには他のユーザインタフェースも想定される。例えば、ユーザインタフェース３７＿４００は、インスタントメッセージングアプリケーション、テレビ会議アプリケーション、及びカレンダーアプリケーションなどの宛先と相互作用できないいずれかのアプリケーションのユーザインタフェースとすることができる。ユーザインタフェース３７＿４００はタッチスクリーンディスプレイ３７＿４０４によって提供されてもよい。タッチスクリーンディスプレイ３７＿４０４は、件名行３７＿４０８を含む電子メールインタフェース３７＿４０６を表示することができる。件名行３７＿４０８は、ユーザが電子メールメッセージの件名を入力するのを可能にすることができる。提案された宛先リスト３７＿４１０は、ユーザが１つ以上の提案された宛先を選択できるようにする。図示するように、実施形態は、件名又はタイトルが件名行３７＿４０８に入力されなくてもデバイス３７＿４０２のコンテキストに基づいて検索結果ウィンドウ３７＿４１０に提案された宛先を提示することができる。かかるゼロキーワード検索は、デバイス３７＿４０２の現在のコンテキストに基づいてデバイス３７＿４０２によって実行され得る。例えば、デバイス３７＿４０２の現在のロケーション、現在時刻、デバイス３７＿４０２上で使用している電子メールアカウントの識別子及び他のコンテキスト情報に基づいて、件名行３７＿４０８内に提供された電子メールメッセージの完全な又は部分的な件名によらず、提案された電子メールの宛先が判定され、検索結果ウィンドウ３７＿４１０内に表示されてもよい。一部の実施形態では、ユーザが件名行３７＿４０８に件名（又はその一部分）を入力する場合、提案された宛先リスト３７＿４１０は、件名行内のキーワードに基づいて更新することができる。

ユーザインタフェース３７＿４００の部分は、一部の状況では隠されてもよい。例えば、デバイス３７＿４０２の図３７－３の提案センター３７＿３２０などの提案センターが別の宛先（例えば、図３７－４に示された宛先Ｂ）が最初に提案された宛先（例えば、図３７－４に示された宛先Ａ）よりも優先されると判断する場合は、最初の宛先は隠されてもよく、他の宛先がその代わりに表示されてもよい。その後、他の宛先は、ディスプレイ３７＿４０４上の提案された宛先のリスト３７＿４１０内に初めて表示されてもよい。したがって、ユーザは優先度が高いと思われる宛先に気づかされ、それと相互作用する機会が与えられてもよい。図３７－４の例示の実施形態では、宛先に関する入力がインタフェース３７＿４００内にユーザによって提供されていない。図示するように、実施形態は、インタフェース３７＿４００内に何の宛先（又は部分的な宛先の名前）も入力されなくてもデバイス３７＿４０２のコンテキストに基づいて提案された宛先リスト３７＿４１０内に提案された宛先を提示することができる。つまり、提案された宛先は、部分的に入力された連絡先の名前又は電子メールアドレスに基づいて連絡先を予測する任意の自動完了技法を用いずに識別され、提案された宛先リスト３７＿４１０内に表示され得る。かかるゼロキーワード検索は、デバイス３７＿４０２の現在のコンテキストに基づいてデバイス３７＿４０２によって実行され得る。例えば、デバイス３７＿４０２の現在のロケーション、現在時刻、及び、デバイス３７＿４０２上で使用される電子メールアカウント（例えば、仕事の、又は私的な電子メールアカウント）などの他のコンテキスト情報に基づいて、提案された電子メールの宛先は判定でき、検索結果ウィンドウ３７＿４１０内に表示され得る。

図３７－５は、既に実行中の検索アプリケーションに関連付けられたデバイス３７＿５０２のユーザインタフェース３７＿５００を図示する。ユーザインタフェース３７＿５００はタッチスクリーンディスプレイ３７＿５０４によって提供されてもよい。タッチスクリーンディスプレイ３７＿５０４は、検索ウィンドウ３７＿５０８を含む検索インタフェース３７＿５０６を表示してもよい。検索ウィンドウ３７＿５０８はユーザが１つ以上の検索用語を入力するのを可能にすることができる。検索結果ウィンドウ３７＿５１０は提案された宛先を提示することができる。図３７－５の例では、検索ウィンドウ３７＿５０８には、ユーザによってキーワードが提供されていない。図示するように、実施形態は、何の検索用語又はキーワードも検索ウィンドウ３７＿５０８に入力されなくても、デバイス３７＿５０２のコンテキストに基づいて検索結果ウィンドウ３７＿５１０に提案された宛先を提示することができる。かかるゼロキーワード検索は、デバイス３７＿５０２の現在のコンテキストに基づいてデバイス３７＿５０２によって実行され得る。例えば、デバイスの現在のロケーション、現在時刻、及び、デバイス３７＿５０２上で使用されるユーザアカウント識別子などの他のコンテキスト情報に基づいて、提案された宛先は判定でき、検索結果ウィンドウ３７＿５１０内に表示され得る。その後、ユーザは、検索結果ウィンドウ３７＿５１０と相互作用し、１つ以上の提案された宛先を選択することができる。実施形態では、ユーザが検索ウィンドウ３７＿５０８内に検索用語（又はその一部）を入力する場合、検索結果ウィンドウ３７＿５１０内の提案された宛先は、検索用語に基づいて更新され得る。

一部の実施形態では、検索結果ウィンドウ３７＿５１０は、図３７－５に示す連絡先の例示のリストより多い場合がある。例えば、検索結果ウィンドウ３７＿５１０は、ユーザがどのように提案された宛先と相互作用することができるかを示す情報を含むことができる。検索結果ウィンドウ３７＿５１０はまた、相互作用が発生すべき理由を示すこともできる。例えば、検索結果ウィンドウ３７＿５１０はユーザが、ユーザの私的アカウントを用いて宛先の私的アカウント上の宛先Ａにテレビ通話を開始することを提案することができるのは、ユーザがこの時間帯の頃にそのようにすることが多いからである。提案は、宛先Ａに連絡するのに使用される特定の通信アプリケーションを提案するものまである場合がある。
Ｂ．方法

図３７－６は、本発明の実施形態に係る、イベントに基づいてコンピューティングデバイスのユーザに１つ以上の宛先を提案するための方法３７＿６００のフローチャートである。方法３７＿６００は、コンピューティングデバイスによって（例えば、ユーザデバイスとのユーザ相互作用を追跡しているユーザデバイスによって）実行され得る。方法３７＿６００は、コンピューティングデバイスの１つ以上のプロパティの異なるセットを有する相互作用を含む過去相互作用のセットを使用して、宛先を提案することができる。

ブロック３７＿６０２では、デバイスは入力デバイスでイベントを検出する。図示するように、ブロック３７＿６０２は、ユーザに関連付けられたユーザデバイスでユーザ入力を検出することを含むことができる。入力デバイスの例は、タッチスクリーン、音声コマンドを提供するためのマイクロフォン、カメラ、ボタン、マウス、スタイラス、キーボードなどである。イベントは、モバイルデバイスが外部デバイス又はユーザなどの外部エンティティと相互作用するあらゆるアクションとすることができる。イベントはデバイスに対して繰り返されるタイプのものとすることができる。こうして、履歴統計データを、イベントの異なる出来事に対して得ることができる。モデル及びサブモデルは、かかる履歴データを用いてトレーニングされ得る。

ブロック３７＿６０２は、ユーザデバイスの１つ以上のプロパティを受信することを含むことができる。１つ以上のプロパティが、デバイス上で実行される宛先提案エンジンによって受信されてもよい。本セクションで述べるように、プロパティは、時間、ロケーション、モーション状態、カレンダーイベントなどに対応することができる。かかる１つ以上のプロパティは、デバイスの特定のコンテキストを規定するコンテキストデータに対応することができる。イベントを検出した頃の時刻に、例えば、ある時間内に、１つ以上のプロパティを測定することができる。時間は、イベント検出前後の時間、イベント検出直前の時間、又はイベント検出直後の時間を含むことができる。

ブロック３７＿６０４では、ユーザ入力が提案エンジンを介して提案された宛先を提供するためのトリガーに対応することが判定される。例えば、電子メールアプリケーション内に電子メールを構成するためのユーザ入力が受信される場合、ブロック ３７＿６０４は、電子メールの提案された宛先が提供されるべきであると判定することができる。また、例えば、検索アプリケーション内に検索を開始するためのユーザ入力が受信される場合、ブロック３７＿６０４は予測された連絡先が検索結果内に含まれることになることを判定することを含むことができる。

ブロック３７＿６０６では、ユーザデバイスを用いて行われた以前の通信に対応する１つ以上のテーブルがポピュレートされる。図３７－６の例では、１つ以上のテーブルのそれぞれは、ユーザデバイスの異なるサブ状態に対応し、異なる宛先との以前の通信の複数の連絡測定値を含むものである。例えば、以前の通信は、例えば、以前の電子メール、音声通話、テキストメッセージ、インスタントメッセージ、テレビ通話及びカレンダーの招待などの、他のユーザとの以前の相互作用を含むことができる。

ブロック３７＿６０８では、１つ以上の状態変数は、１つ以上の状態変数に対応する１つ以上のテーブルの第１のセットを識別するのに使用される。例えば、ロケーションの状態変数がユーザデバイスがユーザの自宅にあることを示す場合、ブロック３７＿６０８は、ユーザの自宅に関連付けられた以前の通信に対応するテーブルを識別することを含むことができる。つまり、ユーザデバイスを用いて行われた以前の通信に対応するテーブルは、ユーザが自宅にいた間に開始又は実行された以前の通信に対応するテーブルのみにフィルタリングされ得る。本例では、ユーザが自宅にいた間に、構成、判読又は編集された過去の電子メールのテーブルのセットは、ロケーションの状態変数がユーザデバイスがユーザの自宅にあることを示すときに、識別され得る。また、例えば、アカウントの状態変数がユーザが仕事の電子メールアカウントを用いていることを示す場合、ブロック３７＿６０８は、仕事の電子メールアカウントを用いて行われた過去の通信に対応するテーブルのセットを識別することを含むことができる。実施形態は、複数の状態変数（例えば、ロケーション状態及びアカウント状態）を用いることができる。

ブロック３７＿６１０では、第１のセットのテーブルは、１つ以上の潜在的な宛先のための連絡測定値を得るために問い合わせられる。連絡測定値は、例えば、ユーザデバイスを用いて行われた以前のカレンダーイベントに対するカレンダーの招待の宛先、以前の電子メールメッセージが行われた（すなわち、構成又は送信された）時の時間、以前の電子メールメッセージに関連付けられた電子メールアカウントの識別子、電子メールメッセージにコピーされた他の宛先、それぞれの宛先に送信された電子メールメッセージの数、の連絡測定値を含むことができる。一実施例では、第１のセットのテーブルを問い合わせることは、１つ以上の潜在的な宛先のそれぞれに送信された以前の通信の総数を計算するように行われ得る。例えば、第１のセットのテーブルを問い合わせることは、電子メールテーブルを問い合わせ、潜在的な宛先のそれぞれに送信された、かつ潜在的な宛先のそれぞれから受信した電子メールメッセージの累積数を判定することを含むことができる。第１のセットのテーブルを問い合わせることはまた、カレンダーイベントテーブルを問い合わせ、潜在的な宛先のそれぞれに送信された、かつ潜在的な宛先のそれぞれから受信したカレンダーの招待の総数を判定することを含むこともできる。

ブロック３７＿６１０は、潜在的な宛先との個々の相互作用、並びに宛先のグループとのグループ相互作用に基づいてテーブルを問い合わせるることができる。例えば、ブロック３７＿６１０は、電子メールテーブルからのコンテキストデータがユーザと宛先との間の以前の電子メールの相互作用（例えば、送信された、又は受信した電子メールメッセージ）を示す、次の電子メールの宛先を予測することができる。ブロック３７＿６１０は、現在のコンテキストに対応する過去相互作用をランク付けすることを含むことができる。例えば、相互作用に対する重み付けは、複数の宛先の共起を示す社会的要素を含むことができる。本例では、宛先のグループとのユーザの過去相互作用に対するランクは、ユーザが以前に過去の他の相互作用においてそのグループと相互作用したかに基づいて上がる場合がある。つまりランク付けの上昇は、共通の、過去の相互作用に含まれたことがある宛先のセット（例えば、ユーザによって送信された電子メールのグループとして繰り返しコピーされた宛先）に基づいて宛先のセットのメンバーに対して与えられる場合がある。このようにして、ユーザが以前に過去の電子メールに対して２つの宛先を選択し、両方の宛先が第３の宛先に送信された電子メールにコピーされた場合、この第３の宛先は、以前に２つの宛先と共に含まれていることに基づいてランク付けが上昇することになる。しかし、ユーザがこれらの３つの宛先のうちの１つしか含まれない別の相互作用をした場合、この相互作用は、同様にランク付けが上昇することはないであろう。

ブロック３７＿６１２では、得られた連絡測定値を用いた以前の通信及び相互作用の総連絡測定値は、１つ以上の潜在的な宛先のそれぞれに対して計算される。一実施例では、以前の通信の総連絡測定値は、１つ以上の潜在的な宛先のそれぞれに送信された以前の通信の累積総数である。本例では、潜在的な宛先のそれぞれに送信された電子メール、メッセージ、通話及びカレンダーの招待の総数は、１つ以上のテーブルに問い合わせることによって計算することができる。

ブロック３７＿６１４では、予測エンジンは、１つ以上の予測された宛先を識別し、１つ以上の潜在的な宛先の総連絡測定値に基づいて、かつ１つ以上の基準を用いてユーザに提案するのに使用される。一部の実施形態では、基準は、提案するための予測された宛先の最小数（例えば、上位Ｎ個の宛先）、提案するための予測された宛先のパーセンテージ（例えば、上位２５％）及び／又は予測された宛先を提案するための閾値信頼水準を含むことができる。ブロック３７＿６１４は、基準としてハードカットオフを用いることを含むことができる。例えば、ユーザとの前の相互作用の最小数を有していた宛先しか、考えられない場合がある。一部の実施形態では、社会的基準が、宛先を提案するのに使用される。例えば、予測された宛先は、ユーザが以前に相互作用したことがある別の提案された宛先と共起を有する場合に提案される場合がある。一部の実施形態では、他の予測された宛先と同様の特性を有する宛先が提案される場合がある。例えば、同じ電子メールアドレスドメインを有し、予測された宛先と同じロケーションに関連付けられた宛先が、通信の追加の宛先として提案されてもよい。

ブロック３７＿６１４は、特定のサブモデルを使用し、１つ以上の宛先を識別し、ユーザに提案することを含むことができる。１つ以上の宛先は、トリガーイベントと関連してユーザによって相互作用される１つ以上の宛先のうち少なくとも１つの少なくとも閾値確率を有してもよい。履歴データ内の１つ以上の宛先のうち１つの予測は、正確な予測として識別され得る。閾値確率は、様々な方法で測定することができ、以下に詳述するように、履歴データから測定された確率分布を使用することができる。例えば、確率分布の平均（average）（平均（mean））確率、中央（median）確率、又はピーク値は、閾値確率を超える（例えば、０．５を超える、３７＿６０％と同等である）ように要求され得る。こうして、信頼水準は、確率分布の平均値、中央値又はピーク値とすることができる。別の例は、特定の値を超える確率分布のための面積が閾値確率より大きいことである。

ブロック３７＿６１６では、１つ以上の予測された宛先がユーザに提供される。ブロック３７＿６１４は、１つ以上の宛先と通信するためにユーザインタフェースをユーザに提供することを含むことができる。例えば、デバイスは、ユーザが識別された宛先にアクセスしたいかどうかを示すようユーザが相互作用し得るリストインタフェースを介して、識別された宛先をユーザに表示してもよい。例えば、ユーザインタフェースは、識別された宛先のうちの１つ以上をユーザに示すタッチ感知ディスプレイを含んでもよく、タッチ感知ディスプレイと相互作用することによって、ユーザは、デバイスによって識別された宛先のうち１つ以上と通信するのを可能にすることができる。ユーザインタフェースは、ユーザの宛先のすべてのリスト内に提供されるよりも、少ない宛先とディスプレイスクリーン上で相互作用するのを可能にすることができる。

一実施例としては、１つ以上の提案された宛先が、検索スクリーン上の宛先リスト内に提供されてもよい。ユーザは、宛先を選択でき、その後、検索スクリーンから、選択された宛先がどのように伝達されるかを選択し、それによって、ユーザが選択された宛先と相互作用するのを容易にすることができる。例えば、通信アプリケーション（例えば、電子メールアプリケーション）に特有のユーザインタフェースは、（例えば、パスワード又はバイオメトリックを介して）ユーザを認証した後に出現することができる。

電子メールのコンテキストでは、ブロック３７＿６１４は、電子メールメッセージの潜在的な宛先として提案された宛先を提供することができる。このコンテキストでは、図３７－４の例示の電子メールアプリケーションのインタフェースが提案された電子メールの宛先をユーザに提供するのに使用され得る。検索のコンテキストでは、ブロック３７＿６１４は、検索インタフェース内の検索結果として提案された宛先を提供することを含むことができる。例えば、図３７－５の検索インタフェースは、検索結果のリスト内に提案された宛先を提示するのに使用され得る。
Ｆ．例示のモデル

一部の実施形態では、モデルは、所与のセット（又はサブセット）のデータのための上位Ｎ個の宛先を選択することができる。このＮ個の宛先は過去に最も選ばれたものなので、将来の行動が過去の行動を映すものと予測され得る。Ｎは、宛先の所定の数（例えば、１、２、又は３）又はパーセンテージとすることができ、それは、イベントに関連付けられた実際の過去の宛先であった宛先の数としてもよい。かかるモデルはユーザに提供するための上位Ｎ個の宛先を選択することができる。更なる分析が実行され、例えば、信頼水準に依存し得る、Ｎ個の宛先をユーザに提供するか、及びＮ個の宛先をユーザにどのように提供するか（例えば、アクション）を判定するために、Ｎ個の宛先のそれぞれに対して確率（信頼）水準を測定することができる。

Ｎが３に等しい例では、コンテキスト情報が特定のサブモデルに相当する状態でイベントが発生した場合、モデルは、上位３個の最も選択された宛先を返すであろう。

他の実施形態では、サブモデルは、合成信号を使用することができ、この場合、一部のコンテキスト情報は、単にサブモデルを選択するためにコンテキスト情報を用いるのではなく、予測された宛先（単数又は複数）を判定する際に使用される。例えば、ニューラルネットワーク又はロジスティック回帰モデルは、宛先（単数又は複数）を予測するため、ロケーション（又はその他の特徴）を使用すると共に、これらの特徴のいくらかの線形重み付き組み合わせを構築することができる。このようなより複雑なモデルは、サブモデルに対するデータ量が著しく大きい場合は、より好適となり得る。一部の実施形態は、より多くのデータが特定のノードに対して得られると、その特定のノードで用いられるサブモデルのタイプ（すなわち、コンテキストデータの特定の組み合わせ）を切り替えることができる。

モデルの精度は、過去相互作用データに照らしてテストされ得る。所与のイベントについては、過去相互作用データは、そのイベントと関連して（例えば、イベントの１分以内のように直前又は直後に）ユーザがどの宛先（単数又は複数）と相互作用したかを識別することができる。各イベントについては、コンテキストデータが使用され、特定のモデルを判定することができる。更に、コンテキストデータはモデルへの入力特徴として使用することができる。

モデル（又はサブモデル）が最上位の宛先を選択する実施例では、最上位の宛先が実際に選択された（すなわち、通信を送信した）履歴データポイントの数が正確なカウントとして判定され得、また最上位の宛先が選択されなかった履歴データポイントの数は不正確なカウントとして判定され得る。上位Ｎ個の宛先を選択するモデルに対してＮが１より大きい実施形態では、正確なカウントは、上位Ｎ個の宛先のうち１つが通信の宛先として選ばれた任意の履歴データポイントに対応することができる。

過去相互作用の第１のサブセットに基づいて、第１のサブモデルは、イベントと関連してユーザが相互作用することになる１つ以上の宛先からなる第１のグループのうち少なくとも１つの宛先を、第１の信頼水準で予測することができる。第１のサブモデルは、０以上とすることができる少なくとも閾値量だけ初期信頼水準を超える第１の信頼水準に少なくとも基づいて作成され得る。この閾値量は差分閾値に対応することができる。一部の実装形態では、第１のサブモデルは作成され得、この基準が満たされたときにいつも作成されるわけではなく、更なる基準が使用されてもよい。信頼水準が初期信頼水準以下の場合は、別のプロパティがテストのために選択され得る。信頼水準のこうした比較は、情報利得のテストに対応することができる。１つ以上の宛先からなる第２のグループを予測するための第１のサブモデルの（第２のプロパティのための）第２のサブモデルの第２の信頼水準を判定するために、同じプロセスを繰り返すことができる。過去相互作用の第２のサブセットは、第２のサブモデルに使用され得る。第３のプロパティ又はそれ以上のプロパティは同様の方法でテストされ得る。
Ｇ．決定木の再生

実施形態は、定期的に、例えば、毎日、モデルの決定木を生成することができる。生成はその時に利用可能な過去相互作用データを使用することができる。こうして、決定木は、１つの生成から別の生成へ変化することができる。一部の実施形態では、決定木は、以前の決定木の知識がなくても構築される。他の実施形態では、新しい決定木が、かかる以前の知識から、例えば、どんなサブモデルが起こりそうかを知るか、又は以前の決定木から開始することによって、構築され得る。

一部の実施形態では、すべてのコンテキスト（又はコンテキストの所定のリスト）が試みられ、どのサブモデルが最大の情報利得を提供するかを判定する。例えば、ロケーションがサブモデルにセグメント化するための最大の情報利得を提供する場合、少なくとも１つの特定のロケーションのサブモデルが作成され得る。セグメント化の各水準では、コンテキストはかかる貪欲なやり方でテストされ、どのコンテキストが情報利得の最大の増加を提供するかを判定することができる。
ＩＶ．確率水準に基づいたアクションの判定

予測モデルは、選択された宛先（単数又は複数）に対してだけでなく、特定のアクション（例えば、以前に追加された宛先に基づいて宛先（単数又は複数）を電子メール上にコピーすること）をテストすることができる。一部の実施形態では、宛先を選択する確率が十分に正確になると、提案された宛先をただ提供するよりも、積極的なアクションを提供することができる。例えば、宛先が提供されると、電子メールアプリケーションは、その宛先が新しい電子メールメッセージ内に宛先として含まれた状態で自動的に起動することができる。

宛先の選択が十分な確率（例えば、信頼水準が高い閾値を超える）で予測されると、その予測はアクションのテストを開始することができる。したがって、テストは、宛先の予測のためだけでなく、特定のアクションが十分な精度で予測され得るかをテストするためでもある。異なる可能性のあるアクション（電子メール、テキストメッセージング、カレンダー、又はテレビ会議アプリケーションを起動することを含む）が過去相互作用データから得られる場合がある。

したがって、実施形態は、より信頼度が高い場合に、アクションが実行されるので、より積極的になる場合がある。予測モデルは、特定の通信手段（例えば、電子メール、テキストメッセージ、音声通話、テレビ通話、及びテレビ会議）が宛先と通信するのに使用される確率が高い場合は、通信アプリケーション用の特定のユーザインタフェースを提供することができる。例えば、ユーザが電子メールを提案された宛先に送信する確率が高い場合、電子メールアプリケーションのインタフェースが予測モデルによって提供され得る。したがって、一部の実施形態では、使用する確率が高くなるほど、ただ提案された宛先を提供するのではなく、対応する通信アプリケーション（例えば、電子メール、カレンダー、インスタントメッセージ、テキストメッセージ、音声通話、又はテレビ会議）を用いて自動的に宛先と相互作用するためのインタフェースを提供するなどの、より積極的なアクションがとられる場合がある。

例えば、ベースモデルは、アクションが検索スクリーン上で宛先（単数又は複数）を提案することであり得る特定水準の統計的有意性（精度及び信頼度）を有することができる。他の実施例としては、統計的有意性の水準が高いと、スクリーンがライトアップされ得（それによって、その宛先に注意を促し、たった１つの宛先が選択され得、又は特定のアプリケーションのユーザインタフェース（ＵＩ）が提供され得る（すなわち、電子メールアプリケーションのＵＩ）。

アクションは、モデルがたった１つの宛先を予測するか、それとも宛先のグループを予測するかに依存する場合がある。例えば、１つではなく３つの宛先の推薦をする機会がある場合、その３つの宛先のうち任意の１つを選択すると正確な予測が提供されることになるので、確率分布も変更されるであろう。１つの宛先の推薦に対して信頼できなかったモデルが、３つに対して十分に信頼できるものとなり得る。実施形態は、別の宛先（例えば、グループ内にはまだない、次に最も可能性の高い連絡先）をモデルによって予測される宛先のグループに追加することを実行でき、それによって、モデルをより信頼できるものにすることができる。モデルが１つより多い連絡先の予測に基づく場合、提供されるユーザインタフェースは次いで、ＵＩのフォームに影響する場合がある１つより多い連絡先との相互作用を提供する。例えば、連絡先のすべてはリスト内に提供することができ、１つの連絡先が自動的に選択されない。実施形態では、予測は最上位連絡先を含むことができ、その連絡先が選択された場合は、他の連絡先は、メッセージにコピーされてもよい（すなわち、過去相互作用データにおける共起のため）。図３７－４の例では、これらの他の宛先は、電子メールアプリケーションインタフェース３７＿４０６のＣＣ／ＢＣＣ部分内にリスト化され得る。

また、複数のアクション、及び異なるアクションに対する提案がある場合もある。例えば、サブモデルの一部として、ジムにおいて２つのプレイリストが存在することができる（例えば、１つのアプリケーションが識別されるが、２つのアクションが、同様の尤度で選択される場合、その２つのアクションはそのモデル内で識別される）。２つのアクションは合わせると、統計的有意性を有する場合があるが、分割すると、そうでなかった。

一実施例としては、イベント（例えば、電子メールを構成する）に対するモデルが最初にトレーニングされているときは、モデルはあらゆるアクションを実行するほどには十分に信頼できない場合がある。初期水準の信頼度では、宛先名、アイコン、又は他の宛先識別子を表示することができる。次に高い水準の信頼度では、宛先に連絡する手段が表示されてもよい（例えば、電子メールアドレス又は電話番号）。更なる水準の信頼度では、特定の通信アプリケーションに特有のユーザインタフェースが表示されてもよい（例えば、予測された宛先を新しい電子メール、インスタントメッセージ、電話機通話又はテレビ通話の宛先として追加するためのコントロール）。これらの異なる水準は、信頼水準を規定するのに使用される様々な値とすることができる。

他の例示のアクションは、現在再生中の曲の変更、通知（スクリーンの前面及び中央とすることができる）の提供を含むことができる。アクションは、デバイスのロックを解除した後に発生することができ、例えば、アプリケーションに特有のＵＩをロック解除後に表示することができる。アクションは、ディープリンクを用いて規定でき、アプリケーションの特定の機能を開始することができる。
Ｖ．データフロー及びモジュール

図３７－７は、連絡するための宛先を提案するための例示のデータフロー図３７－７００である。データフロー図３７－７００は、宛先の提案３７＿７０２を各種通信アプリケーション及び相互作用メカニズム３７＿７０１に提供する。図３７－７の例では、アプリケーション及びメカニズム３７＿７０１としては、カレンダー３７＿７０４、メール３７＿７０６、メッセージ３７＿７０８、電話機３７＿７１０、及びテレビ通話３７＿７１２が挙げられる。図３７－７に示すように、例示のメール３７＿７０６アプリケーションは電子メールアプリケーションであり、例示のメッセージ３７＿７０８アプリケーションはインスタントメッセージングアプリケーションである。図示するように、電話機アプリケーション３７＿７１０は、音声通話を開始すると共にテキストメッセージを構成するのに使用することができる。テレビ通話アプリケーションの一例は、ＦａｃｅＴｉｍｅ（登録商標）アプリケーションである。

データフロー図３７－７００は、宛先の提案３７＿７０２が各種のデータソース３７＿７１４からのデータに基づくものとすることができる。データソース３７＿７１４は過去の通信の情報を含むことができる。データソースは、イベント３７＿７１６、検索３７＿７１８、発見された連絡先３７＿７２０、最近のアクティビティ３７＿７２２、コレクションデーモン３７＿７２４、通信履歴３７＿７２６及び連絡先３７＿７２８を含むことができる。データソース３７＿７１４は、通信アプリケーション及び相互作用メカニズム３７＿７０１からのデータでポピュレートされ得る。例えば、カレンダー３７＿７０４はカレンダーイベントデータをイベント３７＿７１６に提供することができる。同様に、電話機３７＿７１０及びテレビ通話３７＿７１２は音声通話及びテレビ通話の通話履歴を、それぞれ、通信履歴３７＿７２６に提供することができる。図３７－７の例では、発見された連絡先３７＿７２０は、電子メールメッセージ及び他のタイプのメッセージ（例えば、インスタントメッセージ及びテキストメッセージ）内で発見された連絡先を含むことができる。

図３７－８は例示の相互作用モジュール３７＿８１０のブロック図である。図示するように、相互作用モジュール３７＿８１０は、記録エンジン３７＿８１４及び提案エンジン３７＿８１６を含むデーモンとして実装されてもよい。相互作用モジュール３７＿８１０は相互作用データベース３７＿８１８内の相互作用の記憶を保持することができ、提案エンジン３７＿８１６を用いて宛先の提案アルゴリズムを実行することができる。相互作用モジュール３７＿８１０は相互作用データベース３７＿８１８と通信するための相互作用記憶サービス３７＿８１７を含む。相互作用モジュール３７＿８１０は相互作用データベース３７＿８１８に問い合わせ、過去の相互作用の情報を取り出すことができる。相互作用モジュール３７＿８１０はまた、相互作用データベース３７＿８１８内のテーブルをポピュレートするために相互作用データを相互作用データベース３７＿８１８に送信することもできる。例えば、アプリケーション３７＿８００を用いて行われた以前の通信に対応する相互作用データベース３７＿８１８内のデータベーステーブルがポピュレートされてもよい。図３７－８の例では、相互作用データベース３７＿８１８内のテーブルのそれぞれは、アプリケーション３７＿８００が実行されるユーザデバイスの異なるサブ状態に対応し、デバイスを用いて実行された、以前に記録された他のユーザとの相互作用の連絡測定値を含むものである。例えば、記録された相互作用は、例えば、以前の電子メール、音声通話、テキストメッセージ、インスタントメッセージ、テレビ通話及びカレンダーの招待などの、他のユーザとの以前の相互作用を含むことができる。

相互作用モジュール３７＿８１０はまたアプリケーション３７＿８００と通信するためのＸＰＣサービス３７＿８１３も含む。アプリケーション３７＿８００は、図３７－７に示す通信アプリケーション又は相互作用メカニズムのうちの１つとすることができる。アプリケーション３７＿８００は、フレームワーク３７＿８２０を含み、それは更に、アプリケーション３７＿８００を用いて実行された相互作用及び通信を記録するための相互作用記録部３７＿８２４を含む。フレームワーク３７＿８２０はまた、相互作用アドバイザー３７＿８２６も含み、それは、提案された宛先をアプリケーション３７＿８００に提供するのに使用され得る。フレームワーク３７＿８２０は、相互作用記録部３７＿８２４を使用し、相互作用を記録するためのインタフェースを提供することができる。相互作用記録部３７＿８２４及び相互作用アドバイザー３７＿８２６インタフェースは、ＸＰＣサービス３７＿８２２を介してデータを相互作用モジュール３７＿８１０に伝達する。
ＶＩ．アーキテクチャ

図３７－９は、１つ以上の宛先と相互作用するためにユーザインタフェースをユーザに提供する例示のアーキテクチャ３７＿９００を示す。アーキテクチャ３７＿９００は、イベントを検出すると共に、宛先に提案を提供するための要素を示す。アーキテクチャ３７＿９００はまた、例えば、通信アプリケーションを提案するための他の提案を提供することもできる。宛先の提案は、提案されたアプリケーションと併せて提供されてもよい。例えば、アーキテクチャ３７＿９００は提案された宛先を提供でき、また、提案された宛先が特定の通信アプリケーションを介して連絡されるのを推薦することもできる。アーキテクチャ３７＿９００は、ユーザデバイス内に存在することができる。

上部にはＵＩ要素がある。図に示すように検索インタフェース３７＿９１０、検索スクリーン３７＿９２０、及び音声インタフェース３７＿９２５がある。これらはユーザインタフェースをユーザに提供できる方法である。他のＵＩ要素を使用することもできる。

下部には、アプリケーション提案エンジン３７＿９４０及び宛先提案エンジン３７＿９５０のデータソースがある。イベントマネージャー３７＿９４２はイベントを検出しイベントについての情報をアプリケーション提案エンジン３７＿９４０に提供することができる。一部の実施形態では、イベントマネージャー３７＿９４２は、イベントがアプリケーションの提案をトリガーするかどうかを判定することができる。アプリケーションの提案をトリガーするための所定のイベントのリストが特定され得る。ロケーションユニット３７＿９４４は、ユーザデバイスのロケーションを提供することができる。例としては、ロケーションユニット３７＿９４４は、ＧＰＳセンサ及びモーションセンサを含むことができる。ロケーションユニット３７＿９４４はまた、ユーザの最後のロケーションを記憶できる他のアプリケーションも含むことができ、それは、アプリケーション提案エンジン３７＿９４０に送信され得る。他のコンテキストデータは他のコンテキストユニット３７＿９４６から提供され得る。

アプリケーション提案エンジン３７＿９４０は１つ以上のアプリケーション、及び対応するアクションを識別することができる。アプリケーション提案エンジン３７＿９４０と同じ水準で、宛先提案エンジン３７＿９５０は、ユーザに提示するための提案された宛先を提供することができる。イベントマネージャー３７＿９５２は宛先に関連するイベントを検出し、そのイベントについての情報を宛先提案エンジン３７＿９５０に提供することができる。一部の実施形態では、イベントマネージャー３７＿９５２は、イベントが宛先の提案をトリガーするかどうかを判定することができる。所定のイベントのリストは、宛先の提案をトリガーするために特定され得る。相互作用履歴３７＿９５４は、他のユーザとの以前の相互作用及び通信のデータを提供することができる。例えば、相互作用履歴３７＿９５４は、デバイスのユーザと他のユーザとの間でやりとりされた以前の電子メールから記録された情報のデータソースとすることができる。ロケーションユニット３７＿９５６は、ユーザデバイスのロケーションを提供することができる。例えば、ロケーションユニット３７＿９５６は、ＧＰＳセンサ及びモーションセンサを含むことができる。ロケーションユニット３７＿９５６はまた、ユーザデバイスの最後のロケーションを記憶できる他のアプリケーションも含むことができ、それは、宛先提案エンジン３７＿９５０に送信され得る。他のコンテキストデータは他のコンテキストユニット３７＿９５８から提供され得る。

提案された宛先（単数又は複数）は、提案センター３７＿９３０に提供され得、それは、ユーザに何を提供するかを判定することができる。例えば、提案センター３７＿９３０は提案されたアプリケーション又は宛先を提供するかを判定することができる。他の実施例では、アプリケーション（単数又は複数）及び宛先（単数又は複数）が提供されてもよい。提案センターはユーザに提供するための最良の方法を判定することができる。ユーザへの異なる提案は、異なるＵＩ要素を使用してもよい。このようにして、提案センター３７＿９３０はユーザへの提案を制御することができるので、異なるエンジンは、他のエンジンによって提供される提案に割り込まない。各種実施形態では、エンジンは提案（推薦）を提案センター３７＿９３０にプッシュすることができ、又は提案センター３７＿９３０からの提案に対する要求を受信することができる。提案センター３７＿９３０は、特定量の時間の提案を記憶し、その後、その提案がユーザに提供されなかった場合、又はユーザがユーザインタフェースと相互作用しなかった場合は、その提案を削除するよう判定することができる。

提案センター３７＿９３０はまた、いつ提案を送信するかをデバイスに告知するために、他のどんなアクションがユーザデバイスで発生しているかも識別することができる。例えば、ユーザがアプリケーションを使用している場合は、提案された宛先が提供されてもよいが、アプリケーションに対する提案は提供されなくてもよい。提案センター３７＿９３０は、例えば、デバイスのモーション状態、ロックスクリーンがオンしているか、又はアクセスの認証が行われたか、ユーザが職場、自宅などでデバイスを使用しているかなど、様々な要因に基づいて、いつ提案を送信するかを判定することができる。

一部の実施形態では、デバイス３７＿１００（図１Ａ）のソフトウェアコンポーネントは宛先提案／予測モジュール（又は命令のセット）を含む。一部の実施形態では、宛先提案モジュールは、例えば、図３７－７～図３７－９を参照して上記したように様々なサブモジュール又はシステムを含むことができる。宛先提案モジュールは方法３７＿１００又は方法３７＿６００の全部又は部分を実行することができる。
人々中心の予測のための例示の方法、デバイス及びコンピュータ可読媒体

一部の実施形態は、宛先を提案するためのシステム及び方法を提供する。デバイスでのユーザ入力の検出が提案された宛先を提供するトリガーに対応した後、デバイスの現在の状態を表すデバイスのコンテキスト情報が判定され、この場合、現在の状態は、状態変数によって規定される。デバイスを用いて行われた以前の通信に対応するテーブルがポピュレートされ、テーブルのそれぞれは、デバイスの異なるサブ状態に対応し、異なる宛先との以前の通信の連絡測定値を含む。状態変数は、状態変数に対応するテーブルのセットを識別するのに使用され得る。潜在的な宛先の連絡測定値はテーブルのセットから得られる。以前の通信の総連絡測定値は、各潜在的な宛先に対して計算される。提案するための予測された宛先は、潜在的な宛先の総連絡測定値に基づいて、かつ基準を用いて識別され、予測された宛先はユーザに提供される。

一部の実施形態では、ユーザのユーザデバイスと連絡するために提案された宛先を提供するコンピュータにより実行される方法が提案され、この方法は、ユーザデバイスにおいて、ユーザデバイスでユーザ入力を検出することと、ユーザ入力が、提案エンジンを介して提案された宛先を提供するためのトリガーに対応することを判定することと、ユーザデバイスのコンテキスト情報を判定することであって、コンテキスト情報はユーザデバイスの現在のデバイス状態を表すものであり、現在のデバイス状態は１つ以上の状態変数によって規定されることと、ユーザデバイスを用いて行われた以前の通信に対応する１つ以上のテーブルをポピュレートすることであって、１つ以上のテーブルのそれぞれは、ユーザデバイスの異なるデバイスサブ状態に対応し、異なる宛先との以前の通信の複数の宛先測定値を含むものであることと、１つ以上の状態変数を使用して、１つ以上の状態変数に対応する１つ以上のテーブルの第１のセットを識別することと、テーブルの第１のセットから、１つ以上の潜在的な宛先の連絡測定値を得ることと、１つ以上の潜在的な宛先のそれぞれについては、得られた連絡測定値を用いて以前の通信の総連絡測定値を計算することと、１つ以上の潜在的な宛先の総連絡測定値に基づいて、かつ１つ以上の基準を用いてユーザに提案するための１つ以上の予測された宛先を識別する提案エンジンを使用することと、１つ以上の予測された宛先をユーザに提供することと、を含む。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行される通信アプリケーション内のオープンな通信の１つ以上の宛先を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態は１つ以上の宛先を含む。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行される通信アプリケーションに対応するアカウント識別子を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態はアカウント識別子を含む。一部の実施形態では、方法は、ユーザデバイスの現在のロケーションを判定することを含み、コンテキスト情報は現在のロケーションを含み、現在のデバイス状態は現在のロケーション状態を含み、現在のロケーション状態は現在のロケーションを含む。一部の実施形態では、コンテキスト情報は現在時刻及び現在の日を含み、また１つ以上の基準は提案するための予測された宛先の最小数を含む。一部の実施形態では、１つ以上の基準は閾値信頼水準を含み、方法は、ユーザデバイスにおいて、１つ以上の予測された宛先がどのようにユーザに提供されるかを、１つ以上の予測された宛先のそれぞれの各信頼水準に基づいて判定することを更に含む。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行される通信アプリケーション内のオープンな通信の件名を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態は件名を含む。一部の実施形態では、オープンな通信の件名は、電子メールメッセージの件名、カレンダーイベントの件名、及びテレビ会議の件名のうちの１つ以上である。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行されるカレンダーアプリケーション内のオープンなカレンダーイベントのスケジュールされた時刻を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態はスケジュールされた時刻を含む。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行されるカレンダーアプリケーション内のオープンなカレンダーイベントのロケーションを含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態はロケーションを含む。一部の実施形態では、１つ以上のテーブルのうちの１つは、ユーザデバイスのカレンダーサブ状態に対応するカレンダーテーブルであり、このカレンダーテーブルは、ユーザデバイスを用いて行われた以前のカレンダーイベントに対するカレンダーの招待の宛先の連絡測定値を含む。一部の実施形態では、１つ以上のテーブルのうちの１つは、ユーザデバイスの電子メールサブ状態に対応する電子メールテーブルであり、この電子メールテーブルは、ユーザデバイスを用いて行われた以前の電子メールメッセージの宛先の連絡測定値を含み、連絡測定値は、以前の電子メールメッセージが行われた時、以前の電子メールメッセージに関連付けられた電子メールアカウント識別子、以前の電子メールメッセージ上にコピーされた他の宛先、及びそれぞれの宛先に送信された電子メールメッセージの数を含む。一部の実施形態では、以前の通信の総連絡測定値を計算することは、１つ以上のテーブルに照会して、１つ以上の潜在的な宛先のそれぞれに送信された以前の通信の総数を計算することを含む。

一部の実施形態では、ユーザのユーザデバイスで連絡するために提案された宛先を提供するための複数の命令を記憶する非一時的コンピュータ可読記憶媒体を含むコンピュータ製品であって、ユーザデバイスの１つ以上のプロセッサ上で実行されると、命令は、ユーザデバイスでユーザ入力を検出することと、ユーザ入力が、提案エンジンを介して提案された宛先を提供するためのトリガーに対応することを判定することと、ユーザデバイスのコンテキスト情報を受信することであって、コンテキスト情報はユーザデバイスの現在のデバイス状態を表すものであり、現在のデバイス状態は１つ以上の状態変数によって規定されることと、ユーザデバイスを用いて行われた以前の通信に対応する１つ以上のテーブルをポピュレートすることであって、１つ以上のテーブルのそれぞれは、ユーザデバイスの異なるデバイスサブ状態に対応し、異なる宛先との以前の通信の複数の連絡測定値を含むものであることと、１つ以上の状態変数を使用して、１つ以上の状態変数に対応する１つ以上のテーブルの第１のセットを識別することと、テーブルの第１のセットから、１つ以上の潜在的な宛先の連絡測定値を得ることと、１つ以上の潜在的な宛先のそれぞれについては、得られた連絡測定値を用いて以前の通信の総連絡測定値を計算することと、１つ以上の潜在的な宛先の総連絡測定値に基づいて、かつ１つ以上の基準を用いてユーザに提案するための１つ以上の予測された宛先を識別する提案エンジンを使用することと、１つ以上の予測された宛先をユーザに提供することと、を含む、動作を実行する。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行される通信アプリケーション内のオープンな通信の１つ以上の宛先を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態は１つ以上の宛先を含む。一部の実施形態では、コンテキスト情報は、現在時刻及びユーザデバイス上で実行される通信アプリケーションに対応するアカウント識別子を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態は現在時刻及びアカウント識別子を含む。

一部の実施形態では、ユーザデバイスで連絡するために提案された宛先を提供するためのユーザデバイスが提供され、そのユーザデバイスは、入力デバイスと、入力デバイスでユーザ入力を検出し、ユーザ入力が、提案エンジンを介して提案された宛先を提供するためのトリガーに対応することを判定し、ユーザデバイスのコンテキスト情報を判定することであって、コンテキスト情報はユーザデバイスの現在のデバイス状態を表すものであり、現在のデバイス状態は１つ以上の状態変数によって規定され、ユーザデバイスを用いて行われた以前の通信に対応する１つ以上のテーブルをポピュレートすることであって、１つ以上のテーブルのそれぞれは、ユーザデバイスの異なるデバイスサブ状態に対応し、異なる宛先との以前の通信の複数の連絡測定値を含み、１つ以上の状態変数を使用して、１つ以上の状態変数に対応する１つ以上のテーブルの第１のセットを識別し、テーブルの第１のセットから、１つ以上の潜在的な宛先の連絡測定値を得て、１つ以上の潜在的な宛先のそれぞれについては、得られた連絡測定値を用いて以前の通信の総連絡測定値を計算し、１つ以上の潜在的な宛先の総連絡測定値に基づいて、かつ１つ以上の基準を用いてユーザに提案するための１つ以上の予測された宛先を識別する提案エンジンを使用することと、１つ以上の予測された宛先をユーザに提供する、ように構成された１つ以上のプロセッサと、を備える。一部の実施形態では、コンテキスト情報は、ユーザデバイス上で実行される通信アプリケーション内のオープンな通信の１つ以上の宛先を含み、現在のデバイス状態は現在のアプリケーション状態を含み、現在のアプリケーション状態は１つ以上の宛先を含む。一部の実施形態では、１つ以上のテーブルのうちの１つは、ユーザデバイスの電子メールサブ状態に対応する電子メールテーブルであり、この電子メールテーブルは、ユーザデバイスを用いて行われた以前の電子メールメッセージの宛先の連絡測定値を含み、連絡測定値は、以前の電子メールメッセージが行われた時間、以前の電子メールメッセージに関連付けられた電子メールアカウント識別子、以前の電子メールメッセージ上にコピーされた他の宛先、及びそれぞれの宛先に送信された電子メールメッセージの数を含む。一部の実施形態では、１つ以上の基準は閾値信頼水準を含み、１つ以上のプロセッサは、ユーザデバイスにおいて、１つ以上の予測された宛先がどのようにユーザに提供されるかを、１つ以上の予測された宛先のそれぞれの各信頼水準に基づいて判定するように更に構成されている。
セクション８：プロアクティブアシスタントのアプリモデル

本セクションの「プロアクティブアシスタントのアプリモデル」という題材は、一部の実施形態による、プロアクティブアシスタントのアプリケーションモデル及びコンピューティングデバイスのユーザに対して、事前に推薦を提供することに関連する詳細を記載し、本明細書に提供される開示を補足する情報を提供する。例えば、本セクションの部分は、ユーザがアクセスすることに関心を持ち得るアプリケーションの予測を記載し、本明細書で提供される開示、例えば、図９Ｂ～図９Ｃの予測部分９３０内の予測されたコンテンツをポピュレートすることに関すること、及びトリガー条件（図４Ａ～図４Ｂ）の作成及び検出に関することを補足する。一部の実施形態では、アプリケーション予測エンジン及び検索インタフェースに包含するためのアプリケーションの予測に関連する詳細も、本明細書に記載する他の方法（例えば、方法６００、８００、１０００及び１２００）に適用可能である。
プロアクティブアシスタントのアプリモデルの概要

本セクションに記載する実施形態は、ユーザがいつ自身のモバイルコンピューティングデバイス上の検索アプリケーションをアクティブにするかを識別する技法を説明する。具体的には、技法は、ユーザからの検索パラメータの入力を受信する前に、ユーザがアクセスすることに関心を持ち得る１つ以上の予測を提示することを伴い、これにより、ユーザが手動で検索パラメータを検索アプリケーションに提供しなければならない尤度又は必要性を低減することができる。一部の実施形態によれば、検索アプリケーションは、検索アプリケーションがアクティブにされる（例えば、モバイルコンピューティングデバイスのユーザインタフェース内に表示される）たびに、予測エンジン（本セクションでは、「アプリケーション予測エンジン」と呼ばれる）とインタフェース接続するように構成され得る。より具体的には、検索アプリケーションがアプリケーション予測エンジンとインタフェース接続するときは、検索アプリケーションは、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測に対する要求を発行することができる。次に、アプリケーション予測エンジンは、予測を生成するために、モバイルコンピューティングデバイスにインストールされたアプリケーションに関連付けられた情報を分析することができる。その後、検索アプリケーションは、ユーザが選択するために、検索アプリケーションのユーザインタフェース内に予測された１つ以上のアプリケーションを表示することができる。

一実施形態は、モバイルコンピューティングデバイスのユーザに予測を提供する方法を説明する。具体的には、方法は、モバイルコンピューティングデバイス上で実行されるアプリケーション予測エンジンによって実施され、（１）モバイルコンピューティングデバイス上で実行される検索アプリケーションから、モバイルコンピューティングデバイスにインストールされ、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションの予測を提供する要求を受信する工程と、（２）モバイルコンピューティングデバイスにインストールされたアプリケーションのリストを識別する工程と、（３）アプリケーションのリストに含まれる各アプリケーションに対して、（ｉ）アプリケーションに対応する１つ以上のデータ信号に１つ以上の関数を実行することによって、アプリケーションのスコアを生成し、（ｉｉ）このスコアをアプリケーションと関連付ける工程と、（４）生成されたスコアにしたがって、アプリケーションのリストをフィルタリングし、フィルタリングされたアプリケーションのリストを生成する工程と、（５）予測をフィルタリングされたアプリケーションのリストでポピュレートする工程と、（６）予測を検索アプリケーションに提供する工程と、を含む。

別の実施形態は、モバイルコンピューティングデバイスのユーザに予測を提示する方法を説明する。具体的には、方法は、モバイルコンピューティングデバイス上で実行される検索アプリケーションによって実施され、（１）検索アプリケーションのアクティブ化を検出する工程と、（２）アプリケーション予測エンジンに対して、モバイルコンピューティングデバイスにインストールされ、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションに対する要求を発行する工程と、（３）アプリケーション予測エンジンから予測を受信する工程であって、この予測は１つ以上のアプリケーションのリストを含み、アプリケーションそれぞれは各スコアに関連付けられている工程と、（４）スコアにしたがって、検索アプリケーションのユーザインタフェース内に、１つ以上のアプリケーションのうち少なくとも１つのアプリケーションのユーザインタフェースエントリを表示する工程と、を含む。

更に別の実施形態は、モバイルコンピューティングデバイスのユーザに予測を提示するように構成されたモバイルコンピューティングデバイスを説明する。具体的には、モバイルコンピューティングデバイスは、（１）検索アプリケーションのアクティブ化を検出すること、（２）検索アプリケーションのユーザインタフェース内にユーザからの入力を受信する前に、（ｉ）モバイルコンピューティングデバイス上で実行されるアプリケーション予測エンジンに対して、モバイルコンピューティングデバイスにインストールされ、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションのリストに対する要求を発行することと、（ｉｉ）アプリケーション予測エンジンからリストを受信することと、（ｉｉｉ）検索アプリケーションのユーザインタフェース内に、リストに含まれる１つ以上のアプリケーションのうち少なくとも１つのアプリケーションのユーザインタフェースエントリを表示すること、を含む工程を行うように構成された検索アプリケーションを実行するように構成されたプロセッサを含む。上に示すように、プロセッサはまた、アプリケーション予測エンジンを実行するように構成され、このアプリケーション予測エンジンは、（１）検索アプリケーションから、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションのリストに対する要求を受信することと、（２）リストを生成することと、（３）検索アプリケーションにリストを提供することと、を含む工程を行うように構成されている。

他の実施形態は、プロセッサによって実行されると、プロセッサに、本セクションで説明した前述の技法のいずれかを実施させる命令を記憶するように構成された非一時的コンピュータ可読記憶媒体を含む。

本概要は、本セクションで記載する主題のいくつかの態様の基本的理解を提供するように、一部の例示の実施形態を要約することを目的として提供されるものにすぎない。したがって、上述した特徴は単なる例にすぎず、いかなる方法でも、本セクションに記載する主題の範囲又は趣旨を狭めるものとして解釈すべきではないことが理解されよう。本セクションに記載する主題の他の特徴、態様及び利点は、以下の発明を実施するための形態、図面及び特許請求の範囲から明らかになるであろう。

本セクションに記載する実施形態の他の態様及び利点は、記述する実施形態の原理を例として図示する添付図面と併せて、以下の詳細な説明から明らかになるであろう。
プロアクティブアシスタントのアプリモデルの詳細な説明

本明細書に記載される実施形態に係る、装置及び方法の代表的な用途が、この項において提示される。これらの例は、更なる前後関係を提供し、説明する実施形態の理解を助けることのみを目的として提供される。したがって、これらの具体的な詳細のうちの一部又は全部を使用することなく、ここで説明される実施形態を実践できるということが、当業者には明らかであろう。他の例では、ここで説明される実施形態を不必要に不明瞭化することを回避するために、周知のプロセス工程は、詳細には説明されていない。他の適用例が可能であり、それゆえ以下の実施例は、限定的なものとして解釈されるべきではない。

本セクションで記載する実施形態は、ユーザがいつ自身のモバイルコンピューティングデバイス上の検索アプリケーションをアクティブにするかを識別し、ユーザからの検索アプリケーションの入力を受信する前に、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測を提示する技法を説明する。一部の実施形態によれば、検索アプリケーションは、検索アプリケーションがアクティブにされる（例えば、モバイルコンピューティングデバイスのユーザインタフェース内に表示される）たびにアプリケーション予測エンジンとインタフェース接続すると共に、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測のためにアプリケーション予測エンジンに問い合わせるように構成され得る。次に、アプリケーション予測エンジンは、予測を生成するために、モバイルコンピューティングデバイスにインストールされたアプリケーションに関連付けられた情報を分析することができる。この情報は、例えば、アプリケーションインストールタイムスタンプ、アプリケーションアクティブ化タイムスタンプ、アプリケーションアクティブ化合計、アプリケーション使用メトリック、メインユーザインタフェース内（例えば、ホームスクリーン上、フォルダ内など）におけるアプリケーションアイコンの位置、ユーザによって最近提供された検索パラメータ、以前の予測が正確であったかどうかを示す収集されたフィードバックなどを含むことができ、これにより、アプリケーション予測エンジンが有意義で関連のある予測を検索アプリケーションに提供するのを可能にすることができる。次に、検索アプリケーションは、ユーザが選択するために、検索アプリケーションのユーザインタフェース内に予測された１つ以上のアプリケーションを表示することができる。とりわけ、この技法は、ユーザが特定のアプリケーションにアクセスしようとするたびにユーザが検索パラメータを入力するという煩わしいプロセスを経る出来事を大幅に低減することができ、これにより、ユーザ自身のモバイルコンピューティングデバイスで全体としてのユーザ満足度を大幅に改善することができる。

本セクションで説明した実施形態は主に、ユーザがアクセスを望み得るアプリケーションを予測するように構成されたアプリケーション予測エンジンを伴うが、異なる種類の予測（例えば、ユーザが連絡する可能性のある人々）を提供するように作用する他の予測エンジンがモバイルコンピューティングデバイス内に実装される場合があることに留意されたい。より具体的には、一部の実施形態によれば、各予測エンジンは、それ自体を、モバイルコンピューティングデバイス内の特定の予測カテゴリに対する「エキスパート」として割り当てるように構成されてもよい。例えば、アプリケーション予測エンジンは、それ自体を、「アプリケーション」予測カテゴリに対するエキスパートとして割り当てて、アプリケーション予測エンジンが、モバイルコンピューティングデバイスのユーザがアクセスすることに関心を持ち得るアプリケーションを予測するのに特化していることを示すことができる。一部の実施形態によれば、アプリケーション予測エンジンは、アプリケーション予測エンジンにより、データ（例えば、上記の情報）を分析し、そのデータにしたがって予測を提供することを可能にする学習モデルを採用することができる。本開示は主に、学習モデルを実行するように構成されたアプリケーション予測エンジンを検討するが、行動データを分析し予測を提供する任意の技法が本セクションに記載するアプリケーション予測エンジンによって採用され得ることに留意されたい。また、アプリケーション予測エンジンは、異なるタイプのユーザデバイスに対して特化された予測を提供するために、異なるタイプのユーザデバイス（例えば、スマートホン、タブレット、ウォッチ、ラップトップコンピュータなど）にわたって機能が異なる場合があることに留意されたい。例えば、第１のタイプのアプリケーション予測エンジンは、スマートホンに割り当てられてもよく、第２のタイプのアプリケーション予測エンジンはタブレットに割り当てられてもよいなどである。

上記に説明したように、モバイルコンピューティングデバイス上に実装される各予測エンジンは、それ自体を、モバイルコンピューティングデバイス内の１つ以上の予測カテゴリ上のエキスパートとして割り当てることができる。結果として、一部の場合には、２つ以上のアプリケーション予測エンジンがそれら自体を、「アプリケーション」予測カテゴリ上のエキスパートとして割り当てることができる。このシナリオでは、本セクションで記載する検索アプリケーションが予測に対する要求を発行するとき、２つ以上のアプリケーション予測エンジンのうちの各アプリケーション予測エンジンは、それ自身の分析（例えば、アプリケーション予測エンジンによって採用される学習モデルにしたがって）を行い、その要求にしたがって予測を生成することになる。このシナリオでは、少なくとも２つの予測が予測に対する要求に応答して生成され、それにより、検索アプリケーションが解釈することができない場合がある冗長性と競合する予測を生じさせる場合がある。

したがって、実施形態はまた、アプリケーション予測エンジンと検索アプリケーションとの間の仲介として作用するように構成される「予測センター」も説明する。この機能を提供するには、予測センターは、予測エンジンが初期化し、それら自身を、１つ以上の予測カテゴリ（例えば、「アプリケーション」予測カテゴリ）に対するエキスパートとして割り当てようとするとき、予測エンジン（例えば、アプリケーション予測エンジン）のレジストラとして作用するように構成されてもよい。同様に、一部の実施形態によれば、予測センターはまた、消費者用のアプリケーション（例えば、本セクションに記載する検索アプリケーション）が提供され得る予測のカテゴリを識別するよう予測センターに問い合わせできるように、モバイルコンピューティングデバイス内に異なるタイプの予測カテゴリを管理するように構成されてもよい。このようにして、消費者用のアプリケーションが特定の予測カテゴリの予測に対する要求を発行し、２つ以上の予測エンジンがそれぞれの予測（単数又は複数）に応答する場合、予測センターは、消費者用のアプリケーションによって発行された要求に応答する前に予測を受信し処理するように構成されてもよい。予測を処理することは、例えば、予測間に存在する重複情報を除去すること、予測エンジンに関連付けられた履歴性能（すなわち、精度）メトリックにしたがって予測に重み付けを適用すること、予測を生成する際に予測エンジンによって広告されたスコアにしたがって予測を分類すること、などを伴うことができる。このようにして、予測センターは、複数の予測を最適された予測に抽出し、最適化された予測を消費者用のアプリケーションに提供することができる。したがって、こうした設計は、有益なことに、（消費者用のアプリケーションが複数の予測を処理することが可能である必要がないように）消費者用のアプリケーションの操作要件を簡略化し、困難な仕事を予測センターに統合し、消費者用のアプリケーションが対象とする予測カテゴリ上のエキスパートとして自身を割り当てた様々な予測エンジンの入力を表す予測を得るのを可能にする。

したがって、上記で説明した様々な技法は、検索アプリケーションが、潜在的に全体のユーザエクスペリエンスを向上させるのに使用され得る予測を受信するよう予測センターと相互作用できるようにする。一部の場合には、検索アプリケーションが、予測が正確だったかを示すようにフィードバックを予測センター／アプリケーション予測エンジンに提供するのは価値ある場合がある。かかるフィードバックは、例えば、学習アルゴリズムがアプリケーション予測エンジンによって実行される場合に有益となり得るのは、フィードバックが学習アルゴリズムを「トレーニングする」と共に予測の全体的な精度を向上させるのに使用され得るからである。例えば、アプリケーション予測エンジンは、特定のアプリケーションがユーザによってアクティブにされる可能性が最も高い予測を生成する場合（例えば、ユーザからの検索入力を受信する前に、検索アプリケーション内に表示される場合）、検索アプリケーションは、予測が真である（例えば、特定のアプリケーションがユーザによって選択されアクティブにされた）ことを示すフィードバックを提供することができる。次に、アプリケーション予測エンジンは、同様の、かつ後続の予測が予測エンジンによって生成されるときに広告されるスコアを増加することができる。

加えて、予測センターのアーキテクチャは、アプリケーション予測エンジンなどの本セクションで記載する様々なエンティティがモバイルコンピューティングデバイス内のモジュールコンポーネントとして機能できるように構成され得ることに留意されたい。一つのアーキテクチャのアプローチでは、各アプリケーション予測エンジンは、フォーマット（例えば、ツリー状の構造）が予測センターによって理解され、予測センターが、アプリケーション予測エンジンの機能を実装するためのプラットフォームとして機能するのを可能にするバンドルとして構成されてもよい。このアプローチによれば、予測センターは、例えば、モバイルコンピューティングデバイス内に常駐する異なるバンドルを識別するために、（例えば、初期化時に）異なるファイルシステムパスを解析するように構成されてもよい。このようにして、バンドルを、都合よく、モバイルコンピューティングデバイスのファイルシステムに追加し、その内部で更新し、またそこから除去することができ、それによって、モバイルコンピューティングデバイスに対して大幅な更新（例えば、オペレーティングシステムの更新）を要求せずに、時間の経過と共に効率的に進展できるモジュール構成を促進することができる。例えば、アプリケーション予測エンジンは、アプリケーション予測エンジンによって実装されるロジックの全部又は一部を（例えば、ＯＴＡ（over the air）更新を通して）更新できるように構成されてもよい。前述のアーキテクチャは例示的なものであり、本セクションに記載する様々なエンティティが互いに通信し、かつ異なる機能を提供するのを可能にするあらゆるアーキテクチャを使用できることに留意されたい。

それに加えて、予測センター／アプリケーション予測エンジンはまた、予測を生成する際に起こる処理量を低減するのに使用され得る１つ以上のキャッシュを実装するように構成されてもよい。一部の実施形態によれば、予測は、生成時に、予測が記憶されたキャッシュからいつ予測を除去すべきかを示す「有効性パラメータ」を伴うことがある。有効性パラメータ（本セクションでは、「有効期限情報」とも呼ばれる）は、例えば、時間ベースの有効期限、イベントベースの有効期限などを規定することができる。このようにして、アプリケーション予測エンジンが頻繁に検索アプリケーションから予測に対する要求を受信する場合、アプリケーション予測エンジンは、予測に対する、繰り返される要求を処理する際に、本来発生するであろう将来の処理量を大幅に低減するために、予測を生成し、キャッシュすることができる。予測センター／アプリケーション予測エンジンは各種アプローチを用いて予測をキャッシュするように構成され得ることに留意されたい。例えば、利用可能なキャッシュメモリが制限されている場合、予測センター／アプリケーション予測エンジンは、（例えば、時間ウィンドウ内の）閾値回数、予測を生成し、閾値が満たされたときには、（有効期限情報が予測が有効であることを示す限り）予測をキャッシュし、予測に対する後続の要求のキャッシュを参照するよう移行するように構成されてもよい。

したがって、本セクションで記載する実施形態は、ユーザがいつ自身のモバイルコンピューティングデバイス上の検索アプリケーションをアクティブにするかを識別し、ユーザからの検索アプリケーションの入力を受信する前に、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測を提示する技法を説明する。これらの技法を実行するのに使用され得るシステム、方法及びユーザインタフェースの詳細図を図示する図３８－１～図３８－４と併せて、以下に、これらの技法のより詳細な検討を説明し記載する。

図３８－１は、一部の実施形態に係る、本セクションに記載する様々な技法を実行するように構成されているモバイルコンピューティングデバイス３８＿１００の異なるコンポーネントのブロック図を図示する。より具体的には、図３８－１は、モバイルコンピューティングデバイス３８＿１００の高水準の概要を図示し、それは、図示するように、予測センター３８＿１０２、アプリケーション予測エンジン３８＿１０４、及び検索アプリケーション３８＿１１６を実装するように構成されている。一部の実施形態によれば、予測センター３８＿１０２、アプリケーション予測エンジン３８＿１０４、及び検索アプリケーション３８＿１１６は、モバイルコンピューティングデバイス３８＿１００上で実行されるように構成されたオペレーティングシステム（ＯＳ）（図３８－１には図示しない）内に実装されてもよい。図３８－１に示すように、予測センター３８＿１０２は、アプリケーション予測エンジン３８＿１０４と検索アプリケーション３８＿１１６との間の仲介として作用するように構成されてもよい。図３８－１には図示しないが、予測センター３８＿１０２は、例えば、２つ以上のアプリケーション予測エンジン３８＿１０４が実装され、２つ以上の予測が検索アプリケーション３８＿１１６によって発行された要求に応答して生成される場合には、複数の予測を統合するように構成されたアグリゲータを実装するように構成されてもよい。しかし、予測センター３８＿１０２がモバイルコンピューティングデバイス３８＿１００内に実装される必要性を低減するか、又は更に取り除くように、アプリケーション予測エンジン３８＿１０４及び検索アプリケーション３８＿１１６の両方が互いに直接通信するように構成され得ることに留意されたい。アプリケーション予測エンジン３８＿１０４及び検索アプリケーション３８＿１１６は、論理上互いに分離される必要はなく、これらのエンティティによって実装される異なる機能が、同じ結果をもたらす異なるアーキテクチャのアプローチを確立するように組み合わされてもよいことに更に留意されたい。

図３８－１に示すように、予測３８＿１１２はアプリケーション予測エンジン３８＿１０４と検索アプリケーション３８＿１１６との間で通信されることができ、例えば、予測センター３８＿１０２は、アプリケーション予測エンジン３８＿１０４によって生成された予測３８＿１１２を受信すると共に、予測３８＿１１２を検索アプリケーション３８＿１１６に転送することができる。フィードバック３８＿１１４はまた、アプリケーション予測エンジン３８＿１０４と検索アプリケーション３８＿１１６との間で通信されることができ、例えば、予測センター３８＿１０２は、アプリケーション予測エンジン３８＿１０４が経時的に予測３８＿１１２の精度を上げることができるように、検索アプリケーション３８＿１１６からフィードバック３８＿１１４を受信し、フィードバック３８＿１１４をアプリケーション予測エンジン３８＿１０４に提供することができる。

それに加えて、予測センター３８＿１０２は、モバイルコンピューティングデバイス３８＿１００における処理及びエネルギー消費効率を向上させるために、予測センター３８＿１０２／アプリケーション予測エンジン３８＿１０４が予測３８＿１１２をキャッシュできるようにするキャッシュを実装するように構成されてもよい。例えば、キャッシュは、複数のエントリを含むことができ、この場合、それぞれのエントリは予測３８＿１１２、並びに予測３８＿１１２がどれくらい有効であると考えられるかを示す有効期限情報を含む。有効期限情報は、例えば、時間ベースの有効期限、イベントベースの有効期限などを含むことができる。このようにして、アプリケーション予測エンジン３８＿１０４が頻繁に予測３８＿１１２に対する要求を受信する場合、アプリケーション予測エンジン３８＿１０４は、モバイルコンピューティングデバイス３８＿１００において本来発生するであろう処理量を大幅に低減するために、予測３８＿１１２を生成し、キャッシュすることができ、それによって、性能を向上させることができる。

本セクションで以前に説明したように、アプリケーション予測エンジン３８＿１０４は、各種アーキテクチャのアプローチを用いて実装でき、例えば、アプリケーション予測エンジン３８＿１０４は、予測センター３８＿１０２の外部にあり、予測センター３８＿１０２によってサポートされ、アプリケーション予測エンジン３８＿１０４によって利用されるアプリケーション・プログラミング・インタフェース（ＡＰＩ）コマンドを介して予測センター３８＿１０２と通信するスタンドアローンの実行可能ファイルとすることができ、アプリケーション予測エンジン３８＿１０４は、モバイルコンピューティングデバイス３８＿１００のファイルシステム内に記憶され、予測センター３８＿１０２などによって解釈され実行されるバンドルとすることができる。図３８－１に示すように、アプリケーション予測エンジン３８＿１０４は、アプリケーション予測エンジン３８＿１０４が検索アプリケーション３８＿１１６に対して予測を生成する方法を定める構成パラメータ３８＿１０６を含むことができる。特に、構成パラメータ３８＿１０６は、データ信号３８＿１１０（それは、モバイルコンピューティングデバイス３８＿１００内のアプリケーション予測エンジン３８＿１０４が利用可能なインストールされたアプリケーション情報３８＿１０８に対応する）がアプリケーション予測エンジン３８＿１０４によって受信され、アプリケーション予測エンジン３８＿１０４によって処理される方法を規定することができる。一部の実施形態によれば、データ信号３８＿１１０は、アプリケーションインストールタイムスタンプ（例えば、各アプリケーションがインストールされた時）、アプリケーションアクティブ化タイムスタンプ（例えば、各アプリケーションがアクティブにされた最後の時刻）、アプリケーションアクティブ化合計（例えば、アプリケーションがこれまでアクティブにされた総回数）、アプリケーション使用メトリック（例えば、アプリケーションがアクティブにされる頻度）などを表すことができる。データ信号３８＿１１０はまた、モバイルコンピューティングデバイス３８＿１００のメインユーザインタフェース内（例えば、ホームスクリーン上、フォルダ内など）におけるアプリケーションアイコンの位置、ユーザによって最近提供されたアプリケーション検索パラメータ、アプリケーション予測エンジン３８＿１０４によって提供された以前の予測が正確だったかを示す収集されたフィードバックなど、を含むことができる。

図３８－１には図示しないが、アプリケーション予測エンジン３８＿１０４は、アプリケーション予測エンジン３８＿１０４が、時間の経過と共に進展し、モバイルコンピューティングデバイス３８＿１００のユーザに関連したままである予測３８＿１１２を提供できるようにする学習モデルを実装するように構成されてもよい。一部の実施形態によれば、学習モデルは、情報（例えば、データ信号３８＿１１０）を分析すると共に、モバイルコンピューティングデバイス３８＿１００を動作させる際の全体的なユーザエクスペリエンスを向上させることができる予測３８＿１１２を生成するように構成されたアルゴリズムを表すことができる。一部の実施形態によれば、アプリケーション予測エンジン３８＿１０４によって処理される情報は、モバイルコンピューティングデバイス３８＿１００内の様々なソース、例えば、モバイルコンピューティングデバイス３８＿１００上で実装されるファイルシステム、検索アプリケーション３８＿１１６によって提供されたフィードバック情報、モバイルコンピューティングデバイス３８＿１００のセンサ（例えば、全地球測位システム（ＧＰＳ）センサ、マイクロフォンセンサ、温度センサ、加速度計センサなど）によって収集された情報、外部ソース（例えば、モバイルコンピューティングデバイス３８＿１００上で実行されるその他のアプリケーション、ＯＳカーネルなど）によって提供された情報などから収集することができる。

それに加えて、図３８－１に示すように、モバイルコンピューティングデバイス３８＿１００は、アプリケーション予測エンジン３８＿１０４、予測センター３８＿１０２及び検索アプリケーション３８＿１１６のうち１つ以上を部分的に又は完全に更新するのに使用され得るＯＴＡ（over the air）更新３８＿１２２を受信するために、（例えば、インターネット接続を介して）１つ以上のサーバ３８＿１２０とインタフェース接続するように構成されてもよい。したがって、図３８－１は、本セクションで説明する技法を実装するのに使用され得る様々なコンポーネントの高水準の概要を提供する。

図３８－２は、一部の実施形態に係る、アプリケーション予測エンジン３８＿１０４によって実行される方法３８＿２００を図示する。方法３８＿２００は互いに直接通信しているアプリケーション予測エンジン３８＿１０４及び検索アプリケーション３８＿１１６として記載されるが、予測センター３８＿１０２は本セクションに記載する予測センター３８＿１０２によって提供される様々な機能により、アプリケーション予測エンジン３８＿１０４と検索アプリケーション３８＿１１６との間の仲介として作用することができることに留意されたい。図示するように、方法３８＿２００は、工程３８＿２０２で開始し、ここでアプリケーション予測エンジン３８＿１０４は、検索アプリケーション３８＿１１６から、モバイルコンピューティングデバイス３８＿１００のユーザがアクセスすることに関心を持ち得る、モバイルコンピューティングデバイス３８＿１００上にインストールされた１つ以上のアプリケーションの予測３８＿１１２を提供するための要求を受信する。この要求は、例えば、モバイルコンピューティングデバイス３８＿１００のユーザが検索アプリケーションをアクティブにさせるジェスチャを入力する場合に、モバイルコンピューティングデバイス３８＿１００上で検索アプリケーションがアクティブになるのに応答して、検索アプリケーション３８＿１１６によって発行され得る。

工程３８＿２０４では、アプリケーション予測エンジン３８＿１０４は、モバイルコンピューティングデバイス３８＿１００上にインストールされているアプリケーションのリストを識別する。この情報は、例えば、インストールされたアプリケーション情報３８＿１０８及びデータ信号３８＿１１０によって得ることができる。工程３８＿２０６では、アプリケーション予測エンジン３８＿１０４は、現在のアプリケーションをアプリケーションのリスト内の最初のアプリケーションとして設定する。工程３８＿２０８では、アプリケーション予測エンジン３８＿１０４は、１つ以上の関数を、現在のアプリケーションに対応する１つ以上のデータ信号３８＿１１０に対して実行することによって現在のアプリケーションに対するスコアを生成する。一部の実施形態によれば、データ信号３８＿１１０に関数を実行することは、データ信号３８＿１１０のスコアを計算することと、データ信号３８＿１１０に関連付けられた一定の重み付けにしたがってそのスコアを調整することを伴う場合がある。例えば、データ信号３８＿１１０がアプリケーションのインストール日に対応する場合、スコアは、アプリケーションがインストールされてから経過した時間に基づく場合があり、例えば、より最近のインストール日に対しては、より高いポイントになる場合がある。一部の場合には、スコアは、減衰値（半減期）にしたがって調整され得、それは、アプリケーションに関連付けられた時間的情報（例えば、アプリケーションインストールタイムスタンプ、アプリケーションアクティブ化タイムスタンプなど）を表すデータ信号３８＿１１０に特に適用できる。次に、データ信号３８＿１１０に関連付けられた一定の重み付けは、スコアに適用され、スコアの更新形態を生成することができる。このようにして、現在のアプリケーションに対応する１つ以上のデータ信号３８＿１１０に対する１つ以上の関数が完了すると、予測エンジンは、現在のアプリケーションに対してスコアの最終形態（例えば、個々のスコアの和）を生成することができる。

工程３８＿２１０では、アプリケーション予測エンジン３８＿１０４は、追加のアプリケーションがアプリケーションのリスト内に含まれるかどうかを判定する。工程３８＿２１０で、アプリケーション予測エンジン３８＿１０４が、追加のアプリケーションがアプリケーションのリスト内に含まれると判定する場合は、方法３８＿２００は工程３８＿２１２に進む。そうでなければ、方法３８＿２００は、以下に詳細に記載する工程３８＿２１４に進む。工程３８＿２１２では、アプリケーション予測エンジン３８＿１０４は、現在のアプリケーションをアプリケーションのリスト内の次のアプリケーションとして設定する。工程３８＿２１４では、アプリケーション予測エンジン３８＿１０４は、（１）生成されたスコア、及び（２）工程３８＿２０２で受信した要求にしたがってアプリケーションのリストをフィルタリングする。例えば、要求は、たった３つのアプリケーションの提案しかモバイルコンピューティングデバイス３８＿１００のユーザインタフェース内に（例えば、スクリーンサイズ又は解像度の設定にしたがって）表示できないことを示すことができ、これにより、アプリケーション予測エンジン３８＿１０４はアプリケーションのリストから、スコアがリストの上位３つの位置にないすべてのアプリケーションを取り除くことができる。工程３８＿２１６では、アプリケーション予測エンジン３８＿１０４は予測３８＿１１２をフィルタリングされたアプリケーションのリストでポピュレートし、予測３８＿１１２を検索アプリケーション３８＿１１６に提供する。

図３８－３は、一部の実施形態に係る、検索エンジン３８＿１１６によって実行される方法３８＿３００を図示する。図示するように、方法３８＿３００は、工程３８＿３０２で開始し、そこで、検索アプリケーション３８＿１１６がアクティブにされる。工程３８＿３０４では、検索アプリケーション３８＿１１６は、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測３８＿１１２に対する要求を発行する。工程３８＿３０６では、検索アプリケーション３８＿１１６は要求に応答して予測３８＿１１２を受信し、その予測３８＿１１２は、１つ以上のアプリケーションのリストを含み、各アプリケーションはそれぞれのスコアに関連付けられている。工程３８＿３０８では、（例えば、図３８－４に図示し、以下に記載するように）検索アプリケーション３８＿１１６は、スコアにしたがって、検索アプリケーション３８＿１１６のユーザインタフェース内に、１つ以上のアプリケーションのうち少なくとも１つのアプリケーションに対するユーザインタフェースエントリを表示する。工程３８＿３１０では、検索アプリケーション３８＿１１６は、ユーザインタフェースを通してユーザ入力を受信する。

工程３８＿３１２では、検索アプリケーション３８＿１１６は、ユーザ入力がユーザインタフェースエントリに対応するかどうかを判定する。工程３８＿３１２で、検索アプリケーション３８＿１１６が、ユーザ入力がユーザインタフェースエントリに対応すると判定する場合は、方法３８＿３００は工程３８＿３１４に進む。そうでなければ、方法３８＿３００は、以下に詳細に記載する工程３８＿３１８に進む。工程３８＿３１４では、検索アプリケーション３８＿１１６は、ユーザインタフェースエントリに対応するアプリケーションをアクティブにする。工程３８＿３１６では、検索アプリケーション３８＿１１６はアプリケーションがアクティブにされたことを示すフィードバックを提供する。最後に、工程３８＿３１８では、検索アプリケーション３８＿１１６は自身を非アクティブにする。

図３８－４は、一部の実施形態に係る、本セクションに記載する検索アプリケーション３８＿１１６の例示のユーザインタフェース３８＿４０２の概念図３８－４００を図示する。図３８－４に示すように、ユーザインタフェース３８＿４０２は、モバイルコンピューティングデバイス３８＿１００のユーザが（例えば、ユーザインタフェース３８＿４０２に含まれる仮想キーボード３８＿４０８を用いて）検索パラメータを入力できるようにする検索フィールド３８＿４０４を含むことができる。また、ユーザインタフェース３８＿４０２は、ユーザがアクティブにすることに関心を持ち得るアプリケーションに対する複数のユーザインタフェースエントリ３８＿４０６のリストを含むことができ、それは、本セクションに記載するアプリケーション予測エンジン３８＿１０４によって生成される予測３８＿１１２によって得ることができる。次に、フィードバックがユーザによって提供される場合（これは、例えば、検索を取消すこと、提案されたアプリを無視し、検索パラメータを入力すること、又はユーザインタフェースエントリ３８＿４０６のうち１つを選択することを含むことができる）、フィードバックは、対処するためのアプリケーション予測エンジン３８＿１０４に転送され得る。

上記の図１Ａは、一部の実施形態に係る、本セクションに記載する様々なコンポーネントを実装するのに使用され得るコンピューティングデバイス１００の詳細図を図示する。特に、詳細図は、図３７－１に図示するモバイルコンピューティングデバイス３７＿１００に含まれ得る様々なコンポーネントを図示する。
プロアクティブアシスタントのアプリモデルの例示の方法及びデバイス

本セクションで記載する実施形態は、ユーザがいつ自身のモバイルコンピューティングデバイス上の検索アプリケーションをアクティブにするかを識別し、ユーザからの検索アプリケーションの入力を受信する前に、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測を提示する技法を説明する。一部の実施形態によれば、検索アプリケーションは、検索アプリケーションがアクティブにされるたびに「アプリケーション予測エンジン」とインタフェース接続すると共に、ユーザがアクセスすることに関心を持ち得る１つ以上のアプリケーションの予測のためにアプリケーション予測エンジンに問い合わせるように構成され得る。次に、アプリケーション予測エンジンは、予測を生成するために、モバイルコンピューティングデバイスにインストールされたアプリケーションに関連付けられた情報を分析することができる。予測を用いると、検索アプリケーションは、ユーザが選択するために、検索アプリケーションのユーザインタフェース内に予測された１つ以上のアプリケーションを表示することができる。

一部の実施形態では、モバイルコンピューティングデバイスのユーザに対して、事前に予測を提供する方法が提供され、その方法は、モバイルコンピューティングデバイス上で実行されるアプリケーション予測エンジンにおいて、モバイルコンピューティングデバイスにインストールされたアプリケーションのリスト内に含まれる各アプリケーションに対して、アプリケーションに対応する少なくとも１つのデータ信号に少なくとも１つの関数を実行し、アプリケーションに対し、アプリケーションがユーザによってアクティブにされる尤度を示すスコアを確立し、そのスコアをアプリケーションと関連付けることと、予測をモバイルコンピューティングデバイス上で実行される検索アプリケーションに提供することであって、その予測がアプリケーションのリスト及びそれらの関連するスコアを含むことと、を含む。一部の実施形態では、方法は、予測を検索アプリケーションに提供する前に、検索アプリケーションから、予測に対する要求を受信することであって、検索アプリケーションが検索アプリケーションのアクティブ化に応答して、かつユーザからの検索入力を受信する前に要求を発行することを含む。一部の実施形態では、要求は、予測に含まれるアプリケーションのリスト内に含まれるべき、特定数のアプリケーションを示す。一部の実施形態では、方法は、アプリケーションのリストに含まれるアプリケーションそれぞれに対して、少なくとも１つのデータ信号に関連付けられた重み付けにしたがってスコアを調整することを含む。一部の実施形態では、少なくとも１つのデータ信号がモバイルコンピューティングデバイス内のアプリケーションアクセスの時間的態様に対応する場合、少なくとも１つのデータ信号に少なくとも１つの関数を実行することは、少なくとも１つのデータ信号に関連付けられた重み付けにしたがってスコアを調整する前に、少なくとも１つのデータ信号に対するスコアを、少なくとも１つのデータ信号に適用する減衰要因にしたがって調整することを更に含む。一部の実施形態では、この少なくとも１つのデータ信号はアプリケーションインストールタイムスタンプ、アプリケーションアクティブ化タイムスタンプ、アプリケーションアクティブ化合計、アプリケーション使用メトリック、モバイルコンピューティングデバイスのメインユーザインタフェース内におけるアプリケーションアイコンの位置、ユーザによって最近提供された検索パラメータ、及び以前の予測が正確だったかを示す収集されたフィードバックのうちの１つ以上から選択される。一部の実施形態では、モバイルコンピューティングデバイスのメインユーザインタフェース内におけるアプリケーションアイコンの位置は、アプリケーションアイコンが含まれるメインユーザインタフェースのページ数、及びアプリケーションがメインユーザインタフェース内のフォルダ内に含まれるかどうかを示すことができる。一部の実施形態では、方法は、予測を検索アプリケーションに提供するのに続き、検索アプリケーションからフィードバックを受信することであって、フィードバックが、予測を検索アプリケーションに提供した後のユーザの行動を示すことと、検索アプリケーションから受信したフィードバックを反映するように、収集されたフィードバックを更新することと、を含む。

一部の実施形態では、モバイルコンピューティングデバイスのユーザに対して、事前に予測を提示する方法が提供され、その方法は、モバイルコンピューティングデバイス上で実行される検索アプリケーションにおいて、検索アプリケーションのアクティブ化を検出することと、アプリケーション予測エンジンに対して、モバイルコンピューティングデバイス上にインストールされ、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションの予測に対する要求を発行することと、アプリケーション予測エンジンから予測を受信することであって、予測が１つ以上のアプリケーションのリストを含み、各アプリケーションは、それぞれのスコアに関連付けられていることと、このスコアにしたがって、検索アプリケーションのユーザインタフェース内に、１つ以上のアプリケーションのうち少なくとも１つのアプリケーションに対するユーザインタフェースエントリを表示することと、を含む。一部の実施形態では、要求は、検索アプリケーションのユーザインタフェースに含まれる検索フィールドを介して検索入力を受信する前に、アプリケーション予測エンジンに対して発行される。一部の実施形態では、方法は、検索アプリケーションのユーザインタフェースを通してユーザ入力を受信することと、フィードバックの形態で、ユーザ入力に関連付けられた情報を提供することと、を含む。一部の実施形態では、フィードバックは、ユーザが少なくとも１つのアプリケーションに対するユーザインタフェースエントリを選択したか、それとも検索パラメータを入力したかを示す。一部の実施形態では、要求は、予測に含まれるべきアプリケーションの特定数を示し、このアプリケーションの特定数は、検索アプリケーションのユーザインタフェース内にユーザに対して表示可能なアプリケーションのユーザインタフェースエントリの数に基づくものである。

一部の実施形態では、モバイルコンピューティングデバイスのユーザに予測を事前に提示するように構成されたモバイルコンピューティングデバイスが提供され、モバイルコンピューティングデバイスは、検索アプリケーションのアクティブ化を検出することと、検索アプリケーションのユーザインタフェース内にユーザからの入力を受信する前に、モバイルコンピューティングデバイス上で実行されるアプリケーション予測エンジンに対して、モバイルコンピューティングデバイスにインストールされ、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションのリストに対する要求を発行することと、アプリケーション予測エンジンからリストを受信することと、検索アプリケーションのユーザインタフェース内に、リスト内に含まれる１つ以上のアプリケーションのうちの少なくとも１つのアプリケーションに対するユーザインタフェースエントリを表示することと、を含む工程を行うように構成された検索アプリケーション、及び、検索アプリケーションから、ユーザがアクティブにすることに関心を持ち得る１つ以上のアプリケーションのリストに対する要求を受信することと、リストを生成することと、リストを検索アプリケーションに提供することと、を含む工程を行うように構成されたアプリケーション予測エンジン、を実行するように構成されているプロセッサを備える。一部の実施形態では、リストを生成することは、モバイルコンピューティングデバイスにインストールされた各アプリケーションについては、１つ以上の関数を、アプリケーションに対応する１つ以上のデータ信号に実行することによって、アプリケーションに対するスコアを生成し、そのスコアをアプリケーションに関連付けることと、生成されたスコアにしたがってアプリケーションをフィルタリングすることと、フィルタリングされたアプリケーションをリストに組み込むことと、を含む。一部の実施形態では、１つ以上の関数のうちある関数を１つ以上のデータ信号のうちのあるデータ信号に実行することは、データ信号に関連付けられた情報に基づいてデータ信号に対するスコアを確立することと、データ信号に関連付けられた重み付けにしたがってスコアを調整することと、を含む。一部の実施形態では、データ信号がモバイルコンピューティングデバイス内のアプリケーションアクセスの時間的態様に対応し、データ信号に関数を実行することは、データ信号に関連付けられた重み付けにしたがってスコアを調整する前に、データ信号に対するスコアを、データ信号に適用する減衰要因にしたがって調整することを更に含む。一部の実施形態では、この１つ以上のデータ信号は、アプリケーションインストールタイムスタンプ、アプリケーションアクティブ化タイムスタンプ、アプリケーションアクティブ化合計、アプリケーション使用メトリック、モバイルコンピューティングデバイスのメインユーザインタフェース内におけるアプリケーションアイコンの位置、ユーザによって最近提供された検索パラメータ、及び以前の予測が正確だったかを示す収集されたフィードバックを含む。一部の実施形態では、モバイルコンピューティングデバイスのメインユーザインタフェース内におけるアプリケーションアイコンの位置は、アプリケーションアイコンが含まれるメインユーザインタフェースのページ数、及びアプリケーションがメインユーザインタフェース内のフォルダ内に含まれるかどうかを示すことができる。一部の実施形態では、アプリケーション予測エンジンは、リストを検索アプリケーションに提供するのに続き、検索アプリケーションからフィードバックを受信することであって、フィードバックが、リストを検索アプリケーションに提供するのに続いたユーザの行動を示すことと、検索アプリケーションから受信したフィードバックを反映するように、収集されたフィードバックを更新することと、を含む工程を行うように更に構成されている。
セクション９：エキスパートセンター（電子デバイスの構成要素に予測コンテンツアイテムを提供する）

本「エキスパートセンター」セクションの内容はエキスパートセンターを説明し、一部の実施形態による電子デバイスの構成要素（図１Ａのデバイス１００の構成要素のいずれか）に予測コンテンツアイテムを提供することを説明し、本明細書に記載する開示を補足する情報を提供する。例えば、このセクションの一部は、本明細書に記載する開示を補足する予測エンジン及び予測カテゴリの創出、例えば、トリガー条件の創出／記憶（図４Ａ～図４Ｂ）に関するもの、並びに検索インタフェースで予測コンテンツアイテムの取出し及び提示に関するもの（例えば、方法６００、８００、１０００、及び１２００）、又はメッセージングアプリケーション内での提案アイテム（例えば、方法２２００、２９００、２２８０、２４００、２６００、及び２７００）として、説明する。一部の実施形態では、本明細書に開示する方法は、第９セクションにて以下に説明する予測エンジンを利用又は活用し、多種多様な関連するコンテンツアイテムをユーザに対して適切な時に提供する（例えば、予測されたアプリケーション、予測された人／連絡先、予測された位置、様々な種類のアプリケーションにコンテンツを素早く加えるために用いられるイベント／連絡先／位置に関する情報、及びそれらの方法のいずれかを参照する上記の関連するコンテンツアイテム）。
エキスパートセンターについての概要

よう本セクションに説明する実施形態は、モバイルコンピューティングデバイス内にて異なる種類の予測を提供するように構成可能な様々な「予測エンジン」を実装するための方法を記載する。一部の実施形態では、予測エンジンはそれぞれ、モバイルコンピューティングデバイス内で１つ以上の「予測カテゴリ」についての「エキスパート」として自身を割り当てることができる。消費者向けアプリケーションが特定の予測カテゴリについての予測の要求を発行し、２つ以上の予測エンジンがそれぞれの予測で応答したとき、「予測センター」が、要求に応答する前に予測を受信して処理するように構成され得る。予測を処理することは、複数の予測にわたって存在する重複する情報を除去すること、予測エンジンによって示される信頼水準に従って予測をソートすることなどを含み得る。このようにして、予測センターは複数の予測から最適化された予測を精製して、最適化された予測を消費者向けアプリケーションに提供することができる。

一実施形態は、モバイルコンピューティングデバイス上で実行しているアプリケーションに予測を同期して提供する方法を記載する。具体的には、方法は、モバイルコンピューティングデバイス上で実行している予測センターにて実施され、（１）アプリケーションから、ある予測カテゴリについての予測を同期して提供することの要求を受信するステップと、（２）予測カテゴリに関連付けられた１つ以上の予測エンジンを特定するステップと、（３）要求に従って１つ以上の予測エンジンによって生成された１つ以上の予測を受信するステップと、（４）１つ以上の予測を集約して、アプリケーションから要求された予測を生成するステップと、（５）アプリケーションに予測を提供するステップと、を含む。

別の実施形態は、モバイルコンピューティングデバイス上で実行しているアプリケーションに非同期的に予測を提供する方法を記載する。具体的には、方法はモバイルコンピューティングデバイス上で実行している予測センターにて実装され、（１）アプリケーションから、ある予測カテゴリについての予測を非同期的に提供することの要求を受信するステップと、（２）予測カテゴリに関連付けられる１つ以上の予測エンジンを特定するステップと、（３）１つ以上の予測エンジンのうちのそれぞれの予測エンジンに、要求に従って１つ以上の予測を非同期的に提供するように通知するステップと、を含む。

更に別の実施形態は、ユーザの行動に従って予測を生成するように構成されたモバイルコンピューティングデバイスを記載する。具体的には、モバイルデバイスは、（１）１つ以上の予測エンジンと１つ以上のアプリケーションとの間でのメディエータとして機能し、複数の予測カテゴリを管理する、予測センターと、（２）それぞれが、予測センターによって管理される複数の予測カテゴリのうちの少なくとも１つの予測カテゴリに対するエキスパートとして機能する、１つ以上の予測エンジンと、（３）１つ以上のアプリケーションであって、１つ以上のアプリケーションのそれぞれが、（ｉ）予測センターに、複数の予測カテゴリのうちの特定の予測カテゴリについて予測の要求を発行するステップと、（ｉｉ）要求に従って、特定の予測カテゴリに対するエキスパートとして機能する予測エンジンによって作成された少なくとも２つの予測の集約である予測を、予測センターから受信するステップと、を含むステップを行うように構成された、１つ以上のアプリケーションと、を実施するように構成される。

他の実施形態は、プロセッサによって実行されたときに、本セクションに記載の上記の方法のいずれかをプロセッサに実装させる命令を記憶するように構成される、非一時的なコンピュータ可読記憶媒体を備える。

この概要は、本セクションで説明する主題のいくつかの態様の基本的理解を提供するように、一部の例示的実施形態を要約することを目的として提供されるものにすぎない。したがって、上述した特徴は単なる例にすぎず、いかなる方法でも、本セクションに記載する主題の範囲又は趣旨を狭めるように解釈すべきではないことが理解されよう。本セクションに記載する主題の他の特徴、態様及び利点は、後続の発明を実施するための形態、図面及び特許請求の範囲から明らかになるであろう。

本セクションに記載の実施形態の他の態様及び利点は、記述する実施形態の原理を例として例示する添付図面と併せて、以下の詳細な説明から明らかになるであろう。
エキスパートセンターの詳細な説明

本明細書に説明される実施形態に係る、装置及び方法の代表的な用途が、このセクションにおいて提示される。これらの例は、更なる前後関係を提供し、説明する実施形態の理解を助けることのみを目的として提供される。したがって、これらの具体的な詳細のうちの一部又は全てを使用することなく、ここで説明される実施形態を実践できるということが、当業者には明らかであろう。他の例では、ここで説明される実施形態を不必要に不明瞭化することを回避するために、周知のプロセスステップは、詳細には説明されていない。他の適用例が可能であり、それゆえ以下の実施例は、限定的なものとして解釈されるべきではない。

本セクションに説明する実施形態は、モバイルコンピューティングデバイスがエンドユーザに意味のある予測を提供することを可能にするように、行動データを集めて整理するための方法を記載する。一部の実施形態によれば、モバイルコンピューティングデバイスは、それぞれが異なる種類の予測をモバイルコンピューティングデバイス内で提供することができるように構成することができる，様々な「予測エンジン」を実装するように構成することができる。より具体的に、及び一部の実施形態によれば、それぞれの予測エンジンは１つ以上の「予測カテゴリ」について自身を「エキスパート」として割り当てることができ、モバイルコンピューティングデバイスの全体的な動作を向上させるために用いることができる。予測カテゴリの例としては、アプリケーション（例えば、アクティブ化／非アクティブ化）、人（例えば、通話、チャット等）、ジオデータ（例えば、モバイルコンピューティングデバイスの動き／ロケール）、通知（例えば、プッシュ通知到達）、物理入力（例えば、ヘッドホン接続／モバイルコンピューティングデバイスへの電源供給）などを挙げることができる。なお、上述の予測カテゴリは単に例示的であり、本セクションに記載する実施形態は、モバイルコンピューティングデバイスが維持することができる任意の予測カテゴリを採用することができる。一部の実施形態によれば、予測エンジンは、予測エンジンがデータ（例えば、モバイルコンピューティングデバイスのユーザの操作に関連付けられた行動データ）を分析することを可能とする学習モデルを採用し、データに従って予測を提供することができる。この開示は主に学習モデルを実施するように構成される予測エンジンについて記載するが、行動データを分析して予測を提供する任意の方法が、本セクションに説明する予測エンジンによって採用され得る。

本セクションに前述のとおり、及び一部の実施形態によれば、予測エンジンは、モバイルコンピューティングデバイス内の１つ以上の予測カテゴリに対して、エキスパートとして自身を割り当てることができる。したがって、一部の場合では、２つ以上の予測エンジンが、モバイルコンピューティングデバイス内の同一の予測カテゴリについてエキスパートとして自身を割り当ててもよい。よって、要求エンティティ（本セクションでは「消費者向けアプリケーション」と称する）が、２つ以上の予測エンジンが自身をエキスパートとして割り当てる予測カテゴリについて予測の要求を発行した場合、２つ以上の予測エンジンのうちのそれぞれの予測エンジンは自身の分析を実施し（例えば、予測エンジンによって採用される学習モデルに従って）、要求に従って（１つ又はそれ以上の）予測を生成する。このシナリオでは、少なくとも２つ以上の予測が予測の要求に応じて生成され、このことで、消費者向けアプリケーションが解釈できない可能性のある冗長性及び競合する予測を確立する可能性がある。

よって、実施形態は、予測エンジンと消費者向けアプリケーションとの間のメディエータとして機能するように構成される「予測センター」をも記載する。一部の実施形態によれば、予測センターは、予測エンジンが初期化して１つ以上の予測カテゴリについて自身をエキスパートとして割り当てることを求めるときに、予測エンジンのためのレジストラとして機能するように構成することができる。同様に、一部の実施形態によれば、予測センターはまた、消費者向けアプリケーションが予測センターに問い合わせをして提供可能な予測のカテゴリを特定することができるように、モバイルコンピューティングデバイス内の異なる種類の予測カテゴリを管理するように構成することができる。このようにして、消費者向けアプリケーションが特定の予測カテゴリについての予測の要求を発行し、２つ以上の予測エンジンがそれぞれの対応する予測で応答したときに、予測センターは、消費者向けアプリケーションから発行された要求に応答する前に、予測を受信して処理するように構成することができる。予測を処理することは、例えば、複数の予測にわたって存在する重複情報を除去すること、予測エンジンに関連付けられた過去の性能（すなわち、正確性）指標に従って予測に重みを適用すること、予測エンジンがそれらの予測を生成するときに予測エンジンが示した信頼水準に従って予測をソートすること、などを伴うことができる。このようにして、予測センターは複数の予測から最適化された予測を精製して、最適化された予測を消費者向けアプリケーションに提供することができる。よって、この設計は有利に消費者向けアプリケーションの動作要件を簡略化し（消費者向けアプリケーションは複数の予測を処理する能力を必要としないため）、難しい仕事を予測センターに集約し、消費者向けアプリケーションが、対象の予測カテゴリのエキスパートとして自身を割り当てている様々な予測エンジンの入力を表す予測を得ることを可能とする。

一部の実施形態によれば、予測センターは、消費者向けアプリケーションが「同期的な」方式で予測を受信することを可能にすることができる。より具体的には、消費者向けアプリケーションは、予測センターに１つ以上の予測エンジンと相互作用していくぶん即時的な（すなわち、同期的な）応答／予測を消費者向けアプリケーションに提供するようにさせる要求を、予測センターに発行するように構成することができる。この同期的な構成は、例えば、消費者向けアプリケーション（チャットアプリケーションなど）が、起動されつつあって、モバイルコンピューティングデバイスのユーザが（例えば、一日の現在時刻に従って）最もメッセージを送る可能性が高い連絡先を先回りして特定しようとしているときに、用いることができる。他の実施形態によれば、予測センターは、消費者向けアプリケーションが予測を「非同期的な」方式で受信することを可能とすることができる。より具体的には、消費者向けアプリケーションは、必要に応じた（すなわち、非同期的／トリガー）基準で予測を提供するように１つ以上の予測エンジンに通知する／１つ以上の予測エンジンを構成するように、予測センターにさせる要求を、予測センターに発行するように構成することができる。この非同期的な構成は、例えば、消費者向けアプリケーション（モバイルコンピューティングデバイス上のアプリケーションをアクティブ化する（すなわち、起動する）及び非アクティブ化する（すなわち、閉じる）ように構成されたＯＳカーネルなど）が、モバイルコンピューティングデバイスにおいて生じている物理入力に応じて反応的にアプリケーションをローディングしようとしているときに用いることができる。例えば、予測エンジンは、ヘッドホンが彼又は彼女のモバイルコンピューティングデバイスに差し込まれる時の大半において、特定のミュージックアプリケーションがユーザによって手動で起動されると判定することができる。これを受けて、予測エンジンは、ヘッドホンがモバイルコンピューティングデバイスに接続されるときに予測を介して、この特定のミュージックアプリケーションをＯＳカーネルに示すことができる。これを受けて、ＯＳカーネルは先回りして（予測に従って）適切なミュージックアプリケーションをローディングすることができ、そのことでユーザエクスペリエンスを改善し、モバイルコンピューティングデバイスの性能を向上させる助けとなることができる。

よって、上述の様々な方法は、消費者向けアプリケーションが、予測センターと相互作用して、全般的なユーザエクスペリエンスを向上するために用いることができる可能性のある予測を受信することを可能とする。一部の場合には、消費者向けアプリケーションが、予測エンジンが作成した予測が正確だったか否かを示すフィードバックを予測センターに提供することは、有益であり得る。かかるフィードバックは、例えば、学習アルゴリズムが予測エンジンによって実装されるときに利益となり得る。なぜなら、フィードバックを用いて、学習アルゴリズムを「トレーニング」し、その予測の全般的な正確性を向上させることができるからである。例えば、ユーザが特定のアクションを取るという予測を予測エンジンが生成し、消費者向けアプリケーションが、予測が真である（すなわち、その特定のアクションがユーザによってとられた）ことを示すフィードバックを提供したときに、予測エンジンは同様の後続の予測が予測エンジンによって作成されるときに示す信頼水準を上げることができる。信頼水準が上昇するにつれて、予測エンジンによって作成される予測は、他の予測エンジンによって作成される競合する予測（もし、あれば）より優先され得る。あるいは、ユーザが特定のアクションをとると予測エンジンが予測し、消費者向けアプリケーションが、予測が真でない（すなわち、別のアクションがユーザによってとられた）ことを示すフィードバックを提供したときに、予測エンジンは同様の後続の予測が予測エンジンによって作成されるときに示す信頼水準を下げることができる。信頼水準が下落するにつれて、この予測エンジンによって作成される予測より、他の予測エンジン（もし、あれば）によって作成される競合する予測の方がまさる可能性がある。

それに加え、及び一部の実施形態によれば、予測センター／予測エンジンは、生成された予測及びそれらの対応するフィードバックの記録を維持するロガーを実装するように構成することができる。これらの記録は様々な仕方で有益であり得る。例えば、予測エンジンの開発者は多くのモバイルコンピューティングデバイスから、予測エンジンが連続的に不正確な予測を生成していることを示す記録を受信し得る。これを受けて、予測エンジンの開発者は、その正確性を向上させるために、予測エンジンの構成に立ち返ることができる。様々なモバイルコンピューティングデバイスにわたる予測センターはまた、互いに情報を交換することで、観察されて全般的なユーザエクスペリエンスを向上させるのに用いることができる高レベルの傾向を特定することができる。例えば、複数の予測センターが、大多数のモバイルコンピューティングデバイスが特定の地理的エリア（例えば、映画館の周辺）に進入したときに、モバイルコンピューティングデバイスのユーザが手動でモバイルコンピューティングデバイスをサイレントモードにすることを、互いに識別し合うことができる。これを受けて、ユーザがその特定の地理的エリア内に入るときに、この識別を用いて、モバイルコンピューティングデバイスをサイレントモードに入れることの提案をユーザに与えることができる。この識別はまた、モバイルコンピューティングデバイスがその特定の地理的エリアに入るときに自動的にサイレントモードへと移行するように自動ルールを設定することを提案するのに用いることができ、これによってユーザが彼又は彼女のモバイルコンピューティングデバイスにアクセスして手動でモバイルコンピューティングデバイスをサイレントモードにする必要を無くすことができる。

上述の技術に加えて、予測センターはまた、予測がモバイルコンピューティングデバイス内で生成される様態を更に向上させるために用いることができる１つ以上の「フィルタ」を実装するように、構成することができる。一部の実施形態によれば、フィルタを用いて、（予測エンジンの範囲内で）正確かつ信頼できるものの、実世界でのシナリオでは実のところ非実用的かつ非効率的である予測の発生を減少させる又は無くす助けとなる追加の処理の層を提供することができる。例えば、モバイルコンピューティングデバイス上のロックスクリーンアプリケーションが消費者向けアプリケーションを表し、ロックスクリーンアプリケーションがカメラアプリケーション用の静的アイコンと、（例えば、一日の現在時刻に基づいて）最もユーザがアクセスする可能性が高いアプリケーションについての動的アイコンを表示するシナリオを検討しよう。この例では、ロックスクリーンアプリケーションは、ロックスクリーンアプリケーション内に表示される動的アイコンと関連付けられるべきであるアプリケーションを特定しようとするとき、「アプリケーション」予測カテゴリに関連付けられた予測の要求を予測センターに発行することができる。更に、この例で、単一の予測エンジンが「アプリケーション」予測カテゴリに関連付けられており、その単一の予測エンジンが、カメラアプリケーションがユーザによって最もアクセスされる可能性が高いと判定した（ロックスクリーンアプリケーションが表示されている時に非常によくあるため）と考えよう。この例では、明らかにこの予測はいくぶん意味がない。なぜなら、ロックスクリーンアプリケーション内に同一のカメラアプリケーションのための２つの異なるアイコンを表示するのが無駄だからである。よって、フィルタを用いてこれらのシナリオが起きるのを防止する助けとすることができる。例えば、フィルタは、ロックスクリーンアプリケーションがモバイルコンピューティングデバイス上でアクティブであるときいつも、「アプリケーション」予測カテゴリと関連付けられる予測からカメラアプリケーションを除外するように構成することができる。

それに加えて、予測センター／予測エンジンはまた、予測を生成するときに行われる処理の量を減らすために用いることができる１つ以上のキャッシュを実装するように構成することができる。一部の実施形態によれば、予測は、生成される際に、予測がいつ、予測が記憶されているキャッシュから削除されるべきかを示す「有効性パラメータ」を伴うことができる。有効性パラメータ（本セクションでは有効期限情報とも称する）は、例えば、時間に基づく有効期限、イベントに基づく有効期限などを定義することができる。このようにして、予測エンジンが特定の予測カテゴリについての予測の要求を頻繁に受信する場合に、予測エンジンは予測を生成し、キャッシュすることができ、それにより、繰り返される予測の要求を処理するときにさもなければ発生するであろう今後の処理量を大幅に減らすことができる。なお、予測センター／予測エンジンは、多種多様なアプローチを用いて予測をキャッシュするように構成することができる。例えば、利用可能なキャッシュメモリが限られている場合、予測センター／予測エンジンは（例えば、ある時間ウィンドウ以内に）予測を閾値回数だけ生成するように構成され得て、閾値が満たされると、予測をキャッシュすることに移行し、（有効期限情報が予測を有効と示す限り）その予測のための後続の要求のためにキャッシュを参照するように構成することができる。

更に、予測センターのアーキテクチャは、本セクションにて説明する様々なエンティティ（予測エンジン、予測カテゴリ、フィルタ、ロガーなどを含む）がモバイルコンピューティングデバイス内でモジュラー構成要素として機能することができるような態様で、構成することができる。１つの構造的なアプローチでは、それぞれのエンティティは、エンティティが予測センターと通信をして本セクションにて説明する様々な機能を提供することを可能とするアプリケーションプログラミングインタフェース（Application Programming Interface；ＡＰＩ）関数コールのセットを実装するように構成することができる。この構造的なアプローチによれば、例えば、エンティティは、予測センターの外部で動作することができ、かつ本セクションにて説明する様々な機能性を提供することができる、自己包含型実行可能ファイル（self-contained executable）として構成することができる。別の構造的アプローチでは、それぞれのエンティティは、バンドルとして構成することができ、そのフォーマット及びコンテンツが、予測センターによって理解され、予測センターがエンティティの機能性を実施するためのプラットフォームとして機能することを可能にする。このアプローチによれば、予測センターは、例えば、様々なファイルシステム経路を（例えば、初期化時に）解析して、モバイルコンピューティングデバイス内に存在する様々なバンドルを識別することができるように構成することができる。このようにすると、バンドルは、モバイルコンピューティングデバイスのファイルシステムに便利に追加、その中で更新、及びそこから除去され得て、そのことでモバイルコンピューティングデバイスに実質的な更新（例えば、オペレーティングシステムアップグレード）を必要とすることなく、経時的に効率的に発展することができるモジュラー構成を促進する。なお、上記のアーキテクチャは例示的であり、本セクションにて説明する様々なエンティティに互いに通信させてそれらの異なる機能性を提供するのを可能とする任意のアーキテクチャを利用することができる。

よって、記載の実施形態は、モバイルコンピューティングデバイスがエンドユーザに意味のある予測を提供することを可能にする、行動データの収集及び整理方法を記載する。以下にこれらの方法のより詳細な記載を、以下に記載し、図３９－１、３９＿２、３９＿３Ａ～３９＿３Ｃ、３９＿４Ａ～３９＿４Ｂ、３９＿５Ａ～３９＿５Ｃ、及び、図１Ａに示すモバイルデバイス１００と関連して説明する。これらの図は、これらの方法を実装するために用いることができるシステム及び方法の詳細図を示す。

図３９－１は、一部の実施形態による、本セクションに説明される様々な方法を実装するように構成されるモバイルコンピューティングデバイス３９＿１００の様々な構成要素のブロック図を示す。より具体的には、図３９－１はモバイルコンピューティングデバイス３９＿１００の高レベルの概要を示し、示されているように、予測センター３９＿１０２及び様々な消費者向けアプリケーション３９＿１１２を実装するように構成される。一部の実施形態によれば、予測センター３９＿１０２及び様々な消費者向けアプリケーション３９＿１１２は、モバイルコンピューティングデバイス３９＿１００上で実行するように構成されるオペレーションシステム（operating system；ＯＳ）（図３９－１には示さず）内に実装可能である。図３９－１にも示すように、予測センター３９＿１０２は様々なロガー３９＿１０５、様々な予測カテゴリ３９＿１０６、様々な予測エンジン３９＿１０８、及び様々なフィルタ３９＿１１０を管理するように構成可能である。予測センター３９＿１０２はまた、予測エンジン３９＿１０８と消費者向けアプリケーション３９＿１１２との間のメディエータとして機能するように構成されるマネジャー３９＿１０４をも、実装することができる。例えば、マネジャー３９＿１０４は予測エンジン３９＿１０８によって生成される予測（図３９－１に予測３９＿１１４として示される）を受信して予測３９＿１１４を消費者向けアプリケーション３９＿１１２に転送することができる。予測センター３９＿１０２はまた、消費者向けアプリケーション３９＿１１２からフィードバック情報３９＿１１６を受信し、そのフィードバック情報３９＿１１６を予測エンジン３９＿１０８に提供してより正確な予測３９＿１１４を経時的に作成できるようにすることができるように、構成することができる。よって、図３９－１は、本セクションに記載の技術を実装するために用いることができる様々な構成要素の高レベルの概要を提供する。

図３９－２は、一実施形態による、図３９－１のモバイルコンピューティングデバイス３９＿１００の特定の構成要素のより詳細な図３９－２００のブロック図を示す。図３９－２に示すように、それぞれの予測エンジン３９＿１０８は、１つ以上の学習モデル３９＿２０２、対応する状態３９＿２０４、及び予測エンジン３９＿１０８が自身をエキスパートとして指定した予測カテゴリ３９＿１０６のリストを含むように、構成することができる。一部の実施形態によれば、学習モデル３９＿２０２は、情報（例えば、状態３９＿２０４）を分析してユーザがモバイルコンピューティングデバイス３９＿１００を操作する時のユーザの全体的なエクスペリエンスを向上させることができる予測を生成するように構成されるアルゴリズムを、表すことができる。一部の実施形態によれば、状態３９＿２０４はモバイルコンピューティングデバイス３９＿１００内の様々なソース、例えば、消費者向けアプリケーションから提供されるフィードバック情報３９＿１１６、モバイルコンピューティングデバイス３９＿１００のセンサ（例えば、全地球測位システム（Global Positioning System；ＧＰＳ）センサ、マイクロフォンセンサ、温度センサ、加速度計センサなど）によって集められた情報、外部ソースから提供される情報（例えば、モバイルコンピューティングデバイス３９＿１００上で実行されるアプリケーション、ＯＳカーネルなど）から集めることができる。

図３９－２にも示すように、マネジャー３９＿１０４は、様々なロガー３９＿１０５、様々な予測カテゴリ３９＿１０６、様々な予測エンジン３９＿１０８、及び様々なフィルタ３９＿１１０を管理するように構成することができる。上述のように、これらのエンティティは多種多様な構造的なアプローチを用いて実装することができる。例えば、エンティティは予測センター３９＿１０２外にあって、ＡＰＩコマンドを介してマネジャー３９＿１０４と通信することができる独立した実行可能ファイルであってもよく、エンティティはモバイルコンピューティングデバイス３９＿１００のファイルシステム内に記憶され、マネジャー３９＿１０４によって解釈可能である／実装されるバンドルなどであってもよい。図３９－２にも示すように、マネジャー３９＿１０４は、複数の予測３９＿１１４を（例えば、異なる予測エンジン３９＿１０８によって作成された時に）統合するように構成されるアグリゲータ３９＿２２０を実装することができる。また、図３９－２に示すように、マネジャー３９＿１０４は、予測センター３９＿１０２と相互作用する消費者向けアプリケーション３９＿１１２の記録を維持するように構成することができる。本セクションにてより詳細に説明するように、これらの記録は、予測エンジン３９＿１０８を、登録して予測エンジン３９＿１０８から予測を非同期的に受信する消費者向けアプリケーション３９＿１１２と関連付けるように機能することができる。

それに加えて、及び図３９－２に示すように、予測センター３９＿１０２は、モバイルコンピューティングデバイス３９＿１００における処理及びエネルギー消費効率の向上を試みるために、予測センター３９＿１０２／予測エンジン３９＿１０８が生成された予測３９＿１１４をキャッシュすることを可能にするキャッシュ３９＿２０６を実装するように構成することができる。図３９－２に示すように、キャッシュ３９＿２０６はエントリ３９＿２０８を含むことができ、エントリ３９＿２０８のそれぞれは、予測３９＿１１４に加えて、予測３９＿１１４がいつまで有効であるかを示す有効期限情報３９＿２１０を含む。有効期限情報３９＿２１０は、例えば、時間に基づく有効期限、イベントに基づく有効期限などを含むことができる。このようにして、予測エンジン３９＿１０８が頻繁に、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４の要求を受信するときに、予測エンジン３９＿１０８は、モバイルコンピューティングデバイス３９＿１００にてそうでなければ発生するであろう処理量を実質的に減少させるために、予測３９＿１１４を生成してキャッシュすることができ、このことによって性能が向上する。

図３９－３Ａは、一部の実施形態による予測エンジン３９＿１０８の高レベルの初期化及び動作についての方法３９＿３００を示す。図３９－３Ａに示すように、方法３９＿３００はステップ３９＿３０２から始まり、予測エンジン３９＿１０８が１つ以上の学習モデル３９＿２０２をローディングする。任意選択的なステップ３９＿３０４では、予測エンジン３９＿１０８は、１つ以上の学習モデル３９＿２０２と関連付けられる、以前に確立された状態３９＿２０４をローディングする。一部の実施形態によれば、以前に確立された状態３９＿２０４は、予測エンジン３９＿１０８が利用可能である任意の記憶リソース、例えば、ローカル不揮発性メモリ、クラウドストレージなどから取り出すことができる。ステップ３９＿３０６では、予測エンジン３９＿１０８は、予測センター３９＿１０２に、少なくとも１つの予測カテゴリ３９＿１０６に対するエキスパートとして機能する（及びその予測カテゴリに関する予測３９＿１１４を提供する）要求を発行する。ステップ３９＿３０８では、予測エンジン３９＿１０８は、少なくとも１つの予測カテゴリ３９＿１０６について予測３９＿１１４を同期して提供する、又は予測３９＿１１４を非同期的に提供することの要求を受信する。ステップ３９＿３１０では、予測エンジン３９＿１０８は、１つ以上の学習モデル３９＿２０２に従って、予測を非同期に及び／又は同期して提供し、それぞれの予測３９＿１１４は信頼水準情報を含む。ステップ３９＿３１２では、予測エンジン３９＿１０８は、提供された予測３９＿１１４に関連付けられる正確性水準を示すフィードバック情報を受信する。かかるフィードバック情報３９＿１１６を用いて、学習モデル３９＿２０２を「トレーニング」し、それらの予測３９＿１１４の全体的な正確性を向上させることができる。例えば、予測エンジン３９＿１０８がモバイルコンピューティングデバイス３９＿１００のユーザが特定のアクションを取るという予測３９＿１１４を生成し、消費者向けアプリケーション３９＿１１２が予測３９＿１１４を真であった（すなわち、特定のアクションがユーザによって取られた）ことを示すフィードバックを提供したときに、予測エンジン３９＿１０８は、同様の後続の予測３９＿１１４が予測エンジン３９＿１０８によって作成されるときに、公言される信頼水準を上げることができる。ステップ３９＿３１４では、予測エンジン３９＿１０８は、フィードバック情報に従って１つ以上の学習モデル３９＿２０２を更新する。

図３９－３Ｂは、一部の実施形態による、予測エンジン３９＿１０８にて同期して予測３９＿１１４を提供する、方法３９＿３３０を示す。図３９－３Ｂに示すように、方法３９＿３３０はステップ３９＿３３２から始まり、予測エンジン３９＿１０８が、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を同期して提供することの要求を受信する。一部の実施形態によれば、要求は、特定の予測カテゴリ３９＿１０６について予測３９＿１１４を要求している消費者向けアプリケーション３９＿１１２の代理として、予測センター３９＿１０２によって生成されてもよい。あるいは、要求は消費者向けアプリケーション３９＿１１２によって生成されて予測エンジン３９＿１０８に直接提供されてもよい。このようにして、予測センター３９＿１０２が予測エンジン３９＿１０８と消費者向けアプリケーション３９＿１１２との間のメディエータとして機能することに関して、予測センター３９＿１０２の全体的な関与を減少させるか排除さえもすることができる。ステップ３９＿３３４では、予測エンジン３９＿１０８は、特定の予測カテゴリ３９＿１０６に関連付けられる少なくとも１つの学習モデル３９＿２０２を識別する。ステップ３９＿３３６では、予測エンジン３９＿１０８は、少なくとも１つの学習モデル３９＿２０２に従って、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を生成する。ステップ３９＿３３８では、予測エンジン３９＿１０８は予測３９＿１１４を信頼水準情報に関連付ける。ステップ３９＿３４０では、予測エンジン３９＿１０８は予測３９＿１１４を提供する。より具体的には、及び構成によっては（例えば、ステップ３９＿３３２に関連して上述したように）、予測エンジン３９＿１０８は予測３９＿１１４を、予測センター３９＿１０２に、又は直接消費者向けアプリケーション３９＿１１２に、提供することができる。これを受けて、他の予測エンジン３９＿１０８が同様の予測３９＿１１４を提供したときに、予測３９＿１１４は（あれば）他の予測３９＿１１４と共に（例えば、予測３９＿１１４が予測センター３９＿１０２に提供されたときにアグリゲータ３９＿２２０によって）集約される。

図３９－３Ｃは、一部の実施形態による、予測エンジン３９＿１０８にて非同期的に予測３９＿１１４を提供する方法３９＿３５０を示す。図３９－３Ｃに示すように、方法３９＿３５０はステップ３９＿３５２から始まり、予測エンジン３９＿１０８が、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を非同期的に提供することの要求を受信する。ステップ３９＿３５４では、予測エンジン３９＿１０８は、特定の予測カテゴリ３９＿１０６に関連付けられた少なくとも１つの学習モデル３９＿２０２を識別する。ステップ３９＿３５６では、予測エンジン３９＿１０８は、特定の予測カテゴリ３９＿１０６及び／又は少なくとも１つの学習モデル３９＿２０２に関連付けられた少なくとも１つのトリガーを識別する。ステップ３９＿３５８では、予測エンジン３９＿１０８は、トリガーがアクティブ化／発生したかどうかを判定する。もし、ステップ３９＿３５８にて、予測エンジン３９＿１０８が、トリガーがアクティブ化されたと判定した場合には、方法３９＿３５０はステップ３９＿３６０に進む。そうでない場合は、方法３９＿３５０は、トリガーがアクティブ化／発生するまで、ステップ３９＿３５８を繰り返す。ステップ３９＿３６０では、予測エンジン３９＿１０８は、少なくとも１つの学習モデル３９＿２０２に従って、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を生成する。ステップ３９＿３６２では、予測エンジン３９＿１０８は予測３９＿１１４を信頼水準情報に関連付ける。ステップ３９＿３６４では、予測エンジン３９＿１０８は予測３９＿１１４を（例えば、集約のために予測センター３９＿１０２に）提供する。

図３９－４Ａは、一部の実施形態による、消費者向けアプリケーション３９＿１１２が予測３９＿１１４を同期して受信することを要求する、方法３９＿４００を示す。図３９－４Ａに示すように、方法３９＿４００はステップ３９＿４０２から始まり、消費者向けアプリケーション３９＿１１２が、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４の要求を発行する。一部の実施形態によれば、消費者向けアプリケーション３９＿１１２は、要求を予測センター３９＿１０２に発行するように構成され得て、それを受けて、予測センター３９＿１０２は、特定の予測カテゴリ３９＿１０６に対するエキスパートとして登録されている予測エンジン３９＿１０８と接続する。あるいは、消費者向けアプリケーション３９＿１１２は、例えば、予測エンジン３９＿１０８が、モバイルコンピューティングデバイス３９＿１００内における特定の予測カテゴリ３９＿１０６に対する唯一のエキスパートであるときに、予測エンジン３９＿１０８に直接要求を発行するように構成され得る。ステップ３９＿４０４では、消費者向けアプリケーション３９＿１１２は、ステップ３９＿４０２で発行された要求に伴って、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を同期して受信する。ステップ３９＿４０６では、消費者向けアプリケーション３９＿１１２はモバイルコンピューティングデバイス３９＿１００での行動（例えば、ユーザの行動）を観察して、予測３９＿１１４が正確かどうかを判定する。ステップ３９＿４０８では、消費者向けアプリケーション３９＿１１２は、予測３９＿１１４と関連付けられた正確性水準を示すフィードバック情報３９＿１１６を提供する。

図３９－４Ｂは、一部の実施形態による、消費者向けアプリケーション３９＿１１２が予測３９＿１１４を非同期的に受信するように登録するための方法３９＿４５０を示す。図３９－４Ｂに示すように、方法３９＿４５０はステップ３９＿４５２から始まり、消費者向けアプリケーション３９＿１１２が、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を非同期的に受信することの要求を発行する。ステップ３９＿４５４では、消費者向けアプリケーション３９＿１１２は、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を非同期的に受信する。ステップ３９＿４５６では、消費者向けアプリケーション３９＿１１２はモバイルコンピューティングデバイス３９＿１００での行動（例えば、ユーザの行動）を観察して、予測３９＿１１４が正確かどうかを判定する。ステップ３９＿４５８では、消費者向けアプリケーション３９＿１１２は、予測３９＿１１４と関連付けられた正確性水準を示すフィードバック情報３９＿１１６を提供する。

図３９－５Ａは、一部の実施形態による、予測センター３９＿１０２にて予測エンジン３９＿１０８の登録を管理するための方法３９＿５００を示す。示すように、方法３９＿５００はステップ３９＿５００から始まり、予測センター３９＿１０２のマネジャー３９＿１０４が、予測エンジン３９＿１０８から、予測エンジン３９＿１０８として機能して少なくとも１つの予測カテゴリ３９＿１０６についての予測３９＿１１４を提供することの要求を受信する。ステップ３９＿５０４では、マネジャー３９＿１０４は、予測エンジン３９＿１０８を、少なくとも１つの予測カテゴリ３９＿１０６についての予測３９＿１１４を提供するように割り当てられている予測エンジン３９＿１０８のリストに加える。任意選択的なステップ３９＿５０６では、マネジャー３９＿１０４は、予測エンジン３９＿１０８と関連付けられた過去の性能指標に従って、予測エンジン３９＿１０８に重みを割り当てる。任意選択的なステップ３９＿５０８では、マネジャー３９＿１０４は、予測エンジン３９＿１０８及び／又は少なくとも１つの予測カテゴリ３９＿１０６に関連付けられたフィルタ３９＿１１０が存在する場合は、それを初期化する。ステップ３９＿５１０では、マネジャー３９＿１０４は予測センター３９＿１０２の構成を更新して、消費者向けアプリケーション３９＿１１２が、少なくとも１つの予測カテゴリ３９＿１０６に関連付けられた予測３９＿１１４を同期して及び／又は非同期的に受信することの要求を発行できるようにする。

図３９－５Ｂは、一部の実施形態による、予測センター３９＿１０２にて消費者向けアプリケーション３９＿１１２に同期して予測３９＿１１４を提供する方法３９＿５５０を示す。図３９－５Ｂに示すように、方法３９＿５５０はステップ３９＿５５２から始まり、マネジャー３９＿１０４が、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を同期して提供することの要求を、消費者向けアプリケーション３９＿１１２から受信する。一例示的なシナリオでは、モバイルコンピューティングデバイス３９＿１００にてアクティブ化されるメッセージングアプリケーションが関与し、メッセージングアプリケーションを操作するユーザによって宛て先にされる可能性の最も高い３つの連絡先について、予測３９＿１１４の要求を発行することを含むことができる。ステップ３９＿５５４では、マネジャー３９＿１０４は、特定の予測カテゴリ３９＿１０６に関連付けられた予測エンジン３９＿１０８のリストを識別する。上記の例示的なシナリオで続けると、２つの異なる予測エンジン３９＿１０８が、「人」予測カテゴリ３９＿１０６に対して自身をエキスパートとして登録したと更に考える。ステップ３９＿５５６では、マネジャー３９＿１０４は、予測３９＿１１４について、予測エンジン３９＿１０８のリストに含まれる予測エンジン３９＿１０８それぞれに問い合わせる。

ステップ３９＿５５８では、マネジャー３９＿１０４は、予測エンジン３９＿１０８のリストに含まれるそれぞれの予測エンジン３９＿１０８から、信頼水準情報に関連付けられた対応する予測３９＿１１４を受信する。上記の例示的なシナリオで続けると、２つの予測エンジン３９＿１０８が、ユーザが連絡する可能性の高い３つの連絡先の別々のリストをそれぞれ含む、予測３９＿１１４を提供すると更に考える。例えば、第１のリストは「Ｇｒｅｇ：０．７」、「Ａｍｙ：０．５」、及び「Ｍｏｍ：０．３」（なお、名前（例えば、「Ｇｒｅｇ」）は連絡される予測された個人を表し、名前に続く数字（例えば、０．７）は予測された個人が連絡される対応する信頼水準を表す）と読めるエントリを含むことができ、第２のリストは「Ｍｏｍ：０．７」、「Ｇｒｅｇ：０．４」、及び「Ｊｕｌｉｅ：０．２」と読めるエントリを含むことができる。ステップ３９＿５６０では、マネジャー３９＿１０４は、予測３９＿１１４に関連付けられた信頼水準情報を、対応する予測エンジン３９＿１０８に割り当てられた重み（あれば）に従って更新する。例えば、第１のリストを作成する予測エンジン３９＿１０８が、マネジャー３９＿１０４によって（例えば、フィードバック情報３９＿１１６を介して）常に性能が悪いと観察されていることに従って０．７５の割り当てられた重みづけを有する場合、第１のリストにおけるそれぞれのエントリの信頼水準情報は０．７５だけ低下させられる。ステップ３９＿５６２では、マネジャー３９＿１０４は、関連付けられた信頼水準情報に従って、予測３９＿１１４を（例えば、アグリゲータ３９＿２２０を用いて）集約する。上記の例で続けると、及び、ステップ３９＿５６０では重みづけがなされないと仮定して、ステップ３９＿５６２は、マネジャー３９＿１０４が以下の更新されたリスト：「Ｇｒｅｇ：１．１」（すなわち、０．７＋０．４＝１．１）、「Ｍｏｍ：１．０」（すなわち、０．３＋０．７＝１．０）、「Ａｍｙ：０．５」、及び「Ｊｕｌｉｅ：０．２」を確立することを含む（なお、「Ｊｕｌｉｅ：０．２」のエントリは、メッセージングアプリケーションが３つの連絡先のみについて予測を受信したいと望むために外されている）。ステップ３９＿５６４では、マネジャー３９＿１０４は、消費者向けアプリケーション３９＿１１２に、「Ｇｒｅｇ：１．１」、「Ｍｏｍ：１．０」、及び「Ａｍｙ：０．５」を含む、集約された予測３９＿１１４に従って予測３９＿１１４を提供する。

図３９－５Ｃは、一部の実施形態による、予測センター３９＿１０２にて消費者向けアプリケーション３９＿１１２に非同期的に予測３９＿１１４を提供するための方法３９＿５７０を示す。示すように、方法３９＿５７０はステップ３９＿５７２から始まり、マネジャー３９＿１０４が、消費者向けアプリケーション３９＿１１２から、特定の予測カテゴリ３９＿１０６についての予測３９＿１１４を非同期的に提供することの要求を受信する。ステップ３９＿５７４では、マネジャー３９＿１０４は、特定の予測カテゴリ３９＿１０６に関連付けられた予測エンジン３９＿１０８のリストを識別する。ステップ３９＿５７６では、マネジャー３９＿１０４は、予測エンジン３９＿１０８のリストに含まれるそれぞれの予測エンジン３９＿１０８に、特定の予測カテゴリ３９＿１０６に関連付けられた予測３９＿１１４を非同期的に提供するように通知する。ステップ３９＿５７８では、マネジャー３９＿１０４は、予測エンジン３９＿１０８のリストに含まれるそれぞれの予測エンジン３９＿１０８から、信頼水準情報に関連付けられた対応する予測３９＿１１４を受信する。ステップ３９＿５８０では、マネジャー３９＿１０４は、予測３９＿１１４に関連付けられた信頼水準情報を、対応する予測エンジン３９＿１０８に割り当てられた重み（あれば）に従って更新する。ステップ３９＿５８２では、マネジャー３９＿１０４は、関連付けられた信頼水準情報に従って、予測３９＿１１４を集約する。ステップ３９＿５８４では、マネジャー３９＿１０４は、消費者向けアプリケーションに３９＿１１２に、集約された予測３９＿１１４に従った予測３９＿１１４を提供する。
エキスパートセンターについての例示的な方法及びデバイス

実施形態は、モバイルコンピューティングデバイス内での様々な種類の予測を提供するように構成可能な様々な「予測エンジン」を実装するための方法を記載する。一部の実施形態では、予測エンジンはそれぞれ、モバイルコンピューティングデバイス内で１つ以上の「予測カテゴリ」についての「エキスパート」として自身を割り当てることができる。消費者向けアプリケーションが特定のカテゴリについての予測要求を発行し、２つ以上の予測エンジンがそれぞれの予測で応答したとき、「予測センター」が、要求に応答する前に予測を受信して処理するように構成され得る。予測を処理することは、予測にわたって存在する重複する情報を除去すること、予測エンジンによって公言される信頼水準に従って予測を仕分けすることなどを含み得る。このようにして、予測センターは複数の予測から最適化された予測を精製して、最適化された予測を消費者向けアプリケーションに提供することができる。

一部の実施形態では、モバイルコンピューティングデバイス上で実行しているアプリケーションに予測を同期して提供する方法を提供しており、その方法は、モバイルコンピューティングデバイス上で実行中の予測センターにおいて、アプリケーションから、予測カテゴリについての予測を同期して提供することの要求を受信することと、予測カテゴリに関連付けられた１つ以上の予測エンジンを識別することと、要求に従って、１つ以上の予測エンジンによって作成された１つ以上の予測を受信することと、１つ以上の予測を集約して、アプリケーションによって要求された予測を作成することと、アプリケーションに予測を提供することと、を含む。一部の実施形態では、１つ以上の予測を集約することは、１つ以上の予測から重複する予測を取り除くことと、１つ以上の予測を、予測センターによって実装される１つ以上のフィルタに従ってフィルタリングすることと、１つ以上の予測のそれぞれの予測について、予測を作成する予測エンジンに割り当てられる重みに従って、予測に関連付けられた信頼水準を調整することであって、予測に関連付けられた信頼水準は予測を作成する時に予測エンジンが生成する、ことと、１つ以上の予測のそれぞれの予測を、予測に関連付けられた信頼水準に従って仕分けることと、から選択される１つ以上の動作を行うことを含む。一部の実施形態では、方法は、予測の要求を受信する前に、１つ以上の予測エンジンのそれぞれの予測エンジンについて、予測エンジンから、予測エンジンが予測カテゴリのエキスパートとして機能することの要求を受信することと、予測エンジンを予測カテゴリと関連付けることと、を含む。一部の実施形態では、方法は、アプリケーションによって要求された予測を作成することに続いて、予測に関連付けられた有効性パラメータを確立することと、有効性パラメータを予測に関連付けることと、予測と有効性パラメータとをキャッシュに記憶することと、を含む。一部の実施形態では、有効性パラメータは時間に基づく有効期限又はトリガーに基づく有効期限のうちの１つ以上を定義する。一部の実施形態では、方法は、キャッシュに予測及び有効性パラメータを記憶することに続いて、第２のアプリケーションから、予測カテゴリについての予測を同期して提供することの第２の要求を受信することと、予測をキャッシュ内に配置することと、予測に関連付けられた有効性パラメータが、予測が有効であると示すときに、第２のアプリケーションに予測を提供することと、を含む。一部の実施形態では、予測カテゴリは、予測センターによって管理される複数の予測カテゴリに含められており、複数の予測カテゴリのうちの予測カテゴリはそれぞれ、モバイルコンピューティングデバイス上で実行しているアプリケーションのアクティブ化と非アクティブ化、モバイルコンピューティングデバイスが知っている連絡先、モバイルコンピューティングデバイスが利用できる全地球測位システム（ＧＰＳ）情報、モバイルコンピューティングデバイスによって処理される通知、又はモバイルコンピューティングデバイスに対して行われた物理入力、に関連付けられる。一部の実施形態では、方法は、アプリケーションに予測を提供したことに続いて、アプリケーションから、予測の正確性を示すフィードバック情報を受信することと、１つ以上の予測エンジンにフィードバック情報を提供することと、を含み、フィードバック情報は、１つ以上の予測エンジンによって作成される後続の予測の正確性を向上させるために、１つ以上の予測エンジンによって利用することができる。

一部の実施形態では、モバイルコンピューティングデバイス上で実行しているアプリケーションに予測を非同期的に提供する方法を提供しており、方法は、モバイルコンピューティングデバイス上で実行中の予測センターにおいて、アプリケーションから、予測カテゴリについての予測を非同期的に提供することの要求を受信することと、予測カテゴリに関連付けられる１つ以上の予測エンジンを識別することと、１つ以上の予測エンジンのそれぞれの予測エンジンに、要求に従って１つ以上の予測を非同期的に提供するように通知することと、を含む。一部の実施形態では、方法は、１つ以上の予測エンジンのそれぞれの予測エンジンに通知したことに続いて、１つ以上の予測を受信することと、１つ以上の予測を集約して、アプリケーションによって要求された予測を作成することと、アプリケーションに予測を提供することと、を含む。一部の実施形態では、方法は、アプリケーションによって要求された予測を作成することに続いて、予測に関連付けられた有効性パラメータを確立することと、有効性パラメータを予測に関連付けることと、予測と有効性パラメータとをキャッシュに記憶することと、を含む。一部の実施形態では、有効パラメータは１つ以上の予測エンジンによって提供され、時間に基づく有効期限又はトリガーに基づく有効期限のうちの１つ以上を定義する。一部の実施形態では、１つ以上の予測を集約することは、１つ以上の予測から重複する予測を取り除くことと、１つ以上の予測を、予測センターによって実装される１つ以上のフィルタに従ってフィルタリングすることと、１つ以上の予測のそれぞれの予測について、予測を作成する予測エンジンに割り当てられる重みに従って、予測に関連付けられた信頼水準を調整することであって、予測に関連付けられた信頼水準は予測を作成する時に予測エンジンが生成する、ことと、１つ以上の予測のそれぞれの予測を、予測に関連付けられた信頼水準に従って仕分けることと、から選択される１つ以上の動作を行うことを含む。一部の実施形態では、１つ以上の予測エンジンは１つ以上の予測を、モバイルコンピューティングデバイス上で発生するトリガーに基づくイベントに応じて、予測センターに非同期的に提供する。一部の実施形態では、方法は、予測の要求を受信する前に、１つ以上の予測エンジンのそれぞれの予測エンジンについて、予測エンジンから、予測エンジンが予測カテゴリのエキスパートとして機能することの要求を受信することと、予測エンジンを予測カテゴリと関連付けることと、を含む。一部の実施形態では、予測カテゴリは、予測センターによって管理される複数の予測カテゴリに含められており、複数の予測カテゴリのうちの予測カテゴリはそれぞれ、モバイルコンピューティングデバイス上で実行しているアプリケーションのアクティブ化と非アクティブ化、モバイルコンピューティングデバイスが知っている連絡先、モバイルコンピューティングデバイスが利用できる全地球測位システム（ＧＰＳ）情報、モバイルコンピューティングデバイスによって処理される通知、又はモバイルコンピューティングデバイスに対して行われた物理入力、に関連付けられる。

一部の実施形態では、ユーザの行動に従って予測を生成するように構成されるモバイルコンピューティングデバイスが提供され、モバイルコンピューティングデバイスは、１つ以上の予測エンジンと１つ以上のアプリケーションとの間のメディエータとして機能するように構成される予測センターであって、複数の予測カテゴリを管理する予測センターと、それぞれが、予測センターによって管理される複数の予測カテゴリのうちの少なくとも１つの予測カテゴリに対するエキスパートとして機能する、１つ以上の予測エンジンと、１つ以上のアプリケーションであって、それぞれが、予測センターに、複数の予測カテゴリのうちの特定の予測カテゴリについての予測要求を発行するステップと、要求に従って、特定の予測カテゴリに対するエキスパートとして機能する予測エンジンによって生成された少なくとも２つの予測の集約である予測を、予測センターから受信するステップと、を含むステップを実行するように構成される、１つ以上のアプリケーションと、を実行するように構成される、プロセッサを備える。一部の実施形態では、１つ以上の予測を集約することは、少なくとも２つの予測から重複する予測を取り除くことと、予測センターによって実装される１つ以上のフィルタに従って、少なくとも２つの予測をフィルタリングすることと、少なくとも２つの予測のそれぞれの予測について、予測を作成する予測エンジンに割り当てられる重みに従って、予測に関連付けられる信頼水準を調整することであって、予測に関連付けられた信頼水準は予測を作成する時に予測エンジンが生成する、ことと、少なくとも２つの予測のそれぞれの予測を予測に関連付けられた信頼水準に従って仕分けることと、から選択される１つ以上の動作を行うことを含む。一部の実施形態、予測センターは、アプリケーションに予測を提供したことに続いて、アプリケーションから、予測の正確性を示すフィードバック情報を受信するステップと、少なくとも２つの予測を生成した予測エンジンにフィードバック情報を提供するステップと、を含むステップを行うように構成され、フィードバック情報は、予測エンジンによって作成される後続の予測の正確性を向上させるために予測エンジンよって利用することができる。一部の実施形態では、複数の予測カテゴリのうちのそれぞれの予測カテゴリは、モバイルコンピューティングデバイス上で実行しているアプリケーションのアクティブ化と非アクティブ化、モバイルコンピューティングデバイスが知っている連絡先、モバイルコンピューティングデバイスが利用できる全地球測位システム（ＧＰＳ）情報、モバイルコンピューティングデバイスによって処理される通知、又はモバイルコンピューティングデバイスに対して行われた物理入力、に関連付けられる。
セクション１０：コンテキスト監視、コンテキスト通知、コンテキスト予測、及び効率的なコンテキスト監視

本セクション「コンテキスト監視、コンテキスト通知、コンテキスト予測、及び効率的なコンテキスト監視」の内容は、一部の実施形態によるデバイスコンテキスト監視、コンテキスト通知、コンテキスト予測、及び効率的なコンテキスト監視を説明し、本明細書に提供される開示を補足する情報を提供する。例えば、本セクションの一部は、コンピューティングデバイスの動作コンテキストを監視することを説明し、本明細書に提供される開示、例えば、使用データの収集／記憶に関するもの（図３Ａ～３Ｂ）、トリガー条件の作成／記憶（図４Ａ～４Ｂ）、並びに使用データ及びトリガー条件に基づくユーザに対しての該当するコンテンツの表面化（例えば、方法６００及び８００）などを補足する。一部の実施形態では、本セクションで取り上げるコンテキスト監視／予測の詳細は、本明細書に記載するいずれかの方法についての検索結果及び他の提案されるコンテンツの提示を改善するためにデータを提供するために用いられるコンテキスト情報を提供するのに用いられる（例えば、方法６００、８００、１０００、１２００、２２００、２２８０、２９００、又は追加のコンテキスト情報を用いることで利益を得ることができる本明細書に記載の任意の他の方法を補足するために）。
コンテキスト監視／予測の概要

コンピューティングデバイスの現在のコンテキストを監視するための、システム、方法、及び非一時的コンピュータ可読記憶媒体を開示する。いくつかの実装では、コンテキストデーモンは、コンピューティングデバイスについてのコンテキスト情報を集めることができる。コンテキスト情報は、現在のデバイスハードウェア状態情報を含むことができる。コンテキスト情報は、現在のソフトウェア状態情報を含むことができる。コンテキストは、ハードウェア状態情報、ソフトウェア状態情報、又は任意の他の種類の状態情報の組み合わせから導出される、又はそこから暗示されることができる。例えば、導出されたコンテキストは、ハードウェア又はソフトウェアの状態情報から導出される、又はそこから暗示されるユーザ状態（例えば、ユーザアクティビティ、睡眠中、ランニング中など）であり得る。

一部の実装では、コンテキスト情報はコンテキストモニタによってコンテキストデーモンに報告され得る。コンテキストモニタは、コンテキストデーモンによって監視されるコンテキスト情報を収集するために具体的に作られ得る。コンテキストモニタは、他の目的、使用のために作成されたアプリケーション、ユーティリティ、ツールなどであり得て、又はハードウェア若しくはソフトウェア状態情報を生成して、状態情報をコンテキストデーモンに報告する。コンテキスト情報が収集されると、コンテキストデーモンはコンピューティングデバイスの現在のコンテキストを中央の位置に記憶させて、コンテキストクライアント（例えば、ソフトウェア、アプリケーション、ユーティリティ、オペレーティングシステムなど）が現在のコンテキスト情報を単一のソースから取得できるようにする。一部の実装では、コンテキストデーモンは過去コンテキスト情報を生成及び／又は収集することができる。過去コンテキスト情報は、古い又は過去のコンテキスト情報を含み得る。過去コンテキスト情報は、コンテキスト情報から導出され得る。よって、コンテキストデーモンは、コンテキストクライアント（例えば、プロセス）がコンピューティングデバイスの現在のコンテキストを判定するのに用いることができるコンテキスト情報の中央リポジトリを提供することができる。

コンピューティングデバイスの現在のコンテキストへの変更をコンテキストクライアントに通知するための、システム、方法、及び非一時的コンピュータ可読記憶媒体を開示する。一部の実装では、コンテキストクライアントは、コンテキストデーモンが特定のコンテキストを検出した時にコールバックされるように登録することができる。例えば、コンテキストクライアントは、コンテキストクライアントが対象とするコンテキストを指定することができる。コンテキストデーモンが、コンピューティングデバイスの現在のコンテキストが登録されたコンテキストに対応すると検出したときに、コンテキストデーモンはコンテキストクライアントに、現在のコンテキストが、コンテキストクライアントが対象とするコンテキストと一致することを通知することができる。よって、コンテキストクライアントはコンテキストの更新を独立して取得してコンテキストクライアントに関係する又はコンテキストクライアントが対象とするコンテキストにおける変更を検出するのに必要なプログラミングを必要としない。

コンピューティングデバイスの動作コンテキストを効率的に監視するための、システム、方法、及び非一時的コンピュータ可読記憶媒体を開示する。一部の実装では、コンテキストデーモン及び／又はコンテキストクライアントは、システムリソースを節約するために終了されていてもよい。例えば、コンテキストデーモン及び／又はコンテキストクライアントがアイドル状態にある場合、バッテリ電源を節約する、又は他のシステムリソース（例えば、メモリ）を空けるために、コンテキストデーモン及び／又はコンテキストクライアントをシャットダウンしてもよい。コンテキストデーモン及び／又はコンテキストクライアントが稼働している必要のあるイベント（例えば、現在のコンテキストにおける変更）が生じたときに、コンテキストデーモン及び／又はコンテキストクライアントをイベントに対応するために再起動され得る。よって、関連するコンテキスト情報の収集及びコールバック通知機能を提供しながらも、システムリソースを節約することができる。

コンピューティングデバイスの今後のコンテキストを予測するための、システム、方法、及び非一時的コンピュータ可読記憶媒体を開示する。一部の実装では、コンテキストデーモンは、過去コンテキスト情報を用いて、今後のイベント及び／又はコンテキスト変更を予測することができる。例えば、コンテキストデーモンは、過去コンテキスト情報を分析して、ユーザの睡眠パターン、ユーザの運動パターン、及び／又は他のユーザアクティビティを予測することができる。一部の実装では、コンテキストクライアントは、予測された今後のコンテキストためのコールバックを登録することができる。例えば、コンテキストクライアントは、予測されるイベント及び／又はコンテキスト変更の１０分前に通知されるように、要求することができる。コンテキストデーモンは予測を用いて、予測されるイベントの前にコンテキストクライアントに通知することができる。
コンテキスト監視／予測の詳細な説明
現在のコンテキストを判定する

図４０－１は、コンピューティングデバイスの動作コンテキストにおける変更を監視し、予測し、コンテキストクライアントに通知するための、例示的なシステム４０＿１００である。コンピューティングデバイスは、例えば、デスクトップコンピュータ、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、又は任意の他の種類のコンピューティングデバイスであり得る。システム４０＿１００は、例えば、コンピューティングデバイス上で稼働するように構成することができる。一部の実装では、システム４０＿１００はコンテキストデーモン４０＿１０２を含むことができる。例えば、コンテキストデーモン４０＿１０２は、コンピューティングデバイス上で実行されるバックグラウンド処理であり得る。コンテキストデーモン４０＿１０２は、例えば、コンピューティングデバイスのオペレーティングシステムに含まれるプロセスであり得る。

一部の実装では、コンテキストデーモン４０＿１０２は、コンピューティングデバイスの現在の動作コンテキストについての情報を収集するように構成することができる。例えば、コンテキスト情報は、コンピューティングデバイスの内部及び／又は外部コンテキストを説明する情報を含むことができる。一部の実装では、内部コンテキスト情報はハードウェア状態情報を含むことができる。例えば、ハードウェア状態情報は、使用中のハードウェア識別し、そのハードウェアがどのように使用されているかを識別することができる。ハードウェアが別のデバイスと通信するのに用いられている無線トランシーバである場合、ハードウェア状態情報は、他のデバイス、いつ接続が生成されたか、どれだけのデータが送信されているか、などを識別することができる。一部の実装では、内部コンテキスト情報はソフトウェア状態情報を含むことができる。例えば、カレンダーアプリケーションについての状態情報は、カレンダーイベント、ミーティング、ミーティングに出席する連絡先の名前、ミーティングの開始及び終了時刻などを含むことができる。

一部の実装では、外部コンテキスト情報はユーザアクティビティを含むことができる。例えば、外部コンテキスト情報は、ハードウェア状態情報及び／又はソフトウェア状態情報から導出され得る。例えば、コンテキストデーモン４０＿１０２は、以下に更に説明するように、ユーザの行動（例えば、睡眠パターン、勤務パターン、食事パターン、移動パターン等）をハードウェア及び／又はソフトウェア状態情報から得ることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、様々な種類のコンテキスト情報を収集するためのモニタバンドル４０＿１０４を含むことができる。モニタバンドル４０＿１０４内のそれぞれのモニタバンドル４０＿１０６は、対応するコンテキストアイテムについてのコンテキスト情報を収集するように構成され得る。例えば、モニタバンドル４０＿１０６は、コンテキストデーモン４０＿１０２に対して外部のプロセスであり得る。モニタバンドル４０＿１０６は、コンテキストデーモン４０＿１０２内で実行することができる、動的にローディングされたソフトウェアパッケージであり得る。

一部の実装では、モニタバンドル４０＿１０６はコンテキストモニタ４０＿１０８を含むことができる。例えば、コンテキストモニタ４０＿１０８は、コンピューティングデバイスの現在のコンテキストについての情報を収集するように構成することができる。一部の実装では、モニタバンドル４０＿１０６は過去モニタ４０＿１１０を備えることができる。例えば、過去モニタ４０＿１１０は、以下に更に説明するように、コンピューティングデバイスについての過去コンテキストを収集又は判定するように構成され得る。

一部の実装では、モニタバンドル４０＿１０４内のそれぞれのモニタバンドル４０＿１０６は、特定の種類のコンテキスト情報を収集するように構成することができる。例えば、コンテキストデーモン４０＿１０２は、多くの異なるモニタバンドル４０＿１０６をローディングすることができる。モニタバンドル４０＿１０６はそれぞれ、コンピューティングデバイス内の異なるソース４０＿１３０から異なるコンテキスト情報を収集するように構成することができる。例えば、１つのモニタパンドル４０＿１０６はＢｌｕｅｔｏｏｔｈコンテキストアイテムについてのコンテキスト情報を収集することができる一方で、別のモニタバンドル４０＿１０６はロック状態コンテキストアイテムについてのコンテキスト情報を収集することができる。

一部の実装では、モニタバンドル４０＿１０６は、位置ＡＰＩ４０＿１３２から位置コンテキスト情報を収集するように構成することができる。例えば、コンテキストモニタ４０＿１０８は、位置ＡＰＩ４０＿１３２から、ＧＮＳＳ受信機から受信された現在のグローバル衛生航法システム（global navigational satellite system；ＧＮＳＳ）位置データを受信することができる。モニタバンドル４０＿１０６は、位置ＡＰＩ４０＿１３２から、現在のセルラ及び／又はＷｉＦｉから導き出された位置データを受信することができる。

一部の実装では、モニタバンドル４０＿１０６は、ロック状態ＡＰＩ４０＿１３４からロック状態コンテキスト情報を収集するように構成することができる。例えば、コンテキストモニタ４０＿１０８は、コンピューティングデバイスの現在のロック状態（例えば、ロックされている、ロック解除されているなど）を記載するロック状態コンテキスト情報を収集することができる。例えば、コンピューティングデバイスのユーザは、使用するコンピューティングデバイスをロック解除する、又はコンピューティングデバイスと相互作用する必要がある。デバイスがロックされているときは、デバイスはユーザ入力を受け入れない。デバイスがロック解除されているときは、デバイスはユーザ入力を受け入れる。タッチスクリーンディスプレイのあるハンドヘルドデバイスについては、デバイスがロック解除されているときは、ディスプレイは照明されてユーザからのタッチ入力を受け入れることができる。タッチスクリーンデバイスがロックされているときは、ディスプレイは暗い場合があり、タッチスクリーンディスプレイはタッチ入力を受け入れない。よって、コンピューティングデバイスのロック状態は、ユーザがコンピューティングデバイスと相互作用していたという証拠を提供することができる。

一部の実装では、モニタバンドル４０＿１０６は、アプリケーションマネジャーＡＰＩ４０＿１３６からアプリケーションコンテキスト情報を収集するように構成することができる。例えば、コンテキストモニタ４０＿１０８はアプリケーションマネジャーＡＰＩ４０＿１３６から、どのアプリケーションが現在コンピューティングデバイス上で稼働しているのか、どれだけ長くアプリケーションが稼働しているのか、いつアプリケーションが呼び出されたのか、及び／又はどのアプリケーションが現在のフォーカスアプリケーションなのか（例えば、前面にある、ディスプレイ上に見えている）を記述する情報を受信することができる。

一部の実装では、モニタバンドル４０＿１０６は、Ｂｌｕｅｔｏｏｔｈ ＡＰＩ４０＿１３８から、Ｂｌｕｅｔｏｏｔｈコンテキスト情報を収集するように構成することができる。例えば、コンテキストモニタ４０＿１０８はＢｌｕｅｔｏｏｔｈ ＡＰＩ４０＿１３８から、コンピューティングデバイスに接続されているＢｌｕｅｔｏｏｔｈデバイスの識別情報及び種類、いつ接続が確立されたか、及びどれだけ長く（例えば、持続時間）コンピューティングデバイスがＢｌｕｅｔｏｏｔｈデバイスに接続されているかを含む、アクティブなＢｌｕｅｔｏｏｔｈ接続を記述する情報を受信することができる。

一部の実装では、モニタバンドル４０＿１０６は、ヘッドホンＡＰＩ４０＿１４０から、ヘッドホンジャック情報を収集するように構成することができる。例えば、コンテキストモニタ４０＿１０８はヘッドホンＡＰＩ４０＿１４０から、有線のヘッドホン若しくはヘッドセット（又は他のデバイス）がコンピューティングデバイスのヘッドホンジャックに現在接続されているかを記述する情報を受信することができる。一部の実施形態では、モニタバンドル４０＿１０６は、ヘッドホンＡＰＩ４０＿１４０から、ヘッドホンジャックに接続されるデバイスの種類についての情報を受信することができる。

一部の実装では、モニタバンドル４０＿１０６は、他デバイス状態ＡＰＩ４０＿１４２から他のコンテキスト情報を収集するように構成することができる。例えば、コンテキストモニタ４０＿１０８は、他デバイス状態ＡＰＩ４０＿１４２から、ＷｉＦｉ接続、電話接続、アプリケーション使用、カレンダーイベント、写真、媒体使用情報、バッテリ充電状態、並びに／又はコンピューティングデバイスの現在の内部及び／若しくは外部コンテキストを記述又は推測するために用いることができる任意の他の状態情報を記述する情報を受信することができる。

一部の実装では、モニタバンドル４０＿１０６は、必要に応じてコンテキストデーモン４０＿１０２に動的にローディングされ得る。例えば、コンテキストデーモン４０＿１０２が位置コンテキスト情報を必要とするとき（例えば、クライアントが位置情報を要求してきたとき）は、コンテキストデーモン４０＿１０２はモニタバンドル４０＿１０４に位置特有モニタバンドル４０＿１０６をローディングさせることができる。ローディングされると、モニタバンドル４０＿１０６のコンテキストモニタ４０＿１０８は、現在の位置特有コンテキストを収集し始める。モニタバンドル４０＿１０６を必要に応じてローディングすることで、コンテキストデーモン４０＿１０２は、メモリやバッテリ電源などの、コンピューティングデバイスのシステムリソースを節約することができる。一部の実装では、モニタバンドル４０＿１０６は、報告クライアント４０＿１２４などの外部プロセスであり得る。コンテキストデーモン４０＿１０２は外部プロセスのモニタバンドル４０＿１０６を必要に応じて呼び出して、コンテキスト情報を収集することができる。例えば、コンテキストデーモン４０＿１０２は、以下に説明するように、コールバック要求を受信したことに応じて、モニタバンドル４０＿１０６をローディングする又は呼び出すことができる。

一部の実装では、コンテキストデーモン４０＿１０２は、報告クライアント４０＿１２４からコンテキスト情報を受信することができる。例えば、報告クライアント４０＿１２４（コンテキストクライアント）は、コンテキスト情報を生成又は収集してコンテキスト情報をコンテキストデーモン４０＿１０２に報告する、コンピューティングデバイス上で稼働している任意のソフトウェアであり得る。例えば、コンピューティングデバイス上で稼働しているマップアプリケーションは、位置ＡＰＩ４０＿１３２を用いて位置情報を取得し、ユーザを開始位置から目的地位置までどのように経路決めするかを判定することができる。経路を判定することに加え、マップアプリケーションは位置ＡＰＩ４０＿１３２から取得した位置情報をコンテキストデーモン４０＿１０２に報告することができる。よって、報告クライアント４０＿１２４はモニタバンドル４０＿１０６のようにコンテキスト情報を収集及び報告する目的で作られていないが、報告クライアント４０＿１２４は、報告クライアント４０＿１２４が主要機能を実行しながらコンテキスト情報を取得したときにコンテキスト情報を報告するように構成することができる。

一部の実装では、コンテキストデーモン４０＿１０２は現在のコンテキスト４０＿１１２を含むことができる。例えば、現在のコンテキスト４０＿１１２は、モニタバンドル４０＿１０４（例えば、モニタバンドル４０＿１０６）及び／又は報告クライアント４０＿１２４から受信されるコンテキスト情報のメモリ内レポジトリであることができる。モニタバンドル４０＿１０４及び／又は報告クライアント４０＿１２４がコンテキスト情報をコンテキストデーモン４０＿１０２に報告するとき、コンテキストデーモン４０＿１０２は現在のコンテキスト４０＿１１２を新しく受信されたコンテキスト情報に更新することができる。よって、現在のコンテキスト４０＿１１２は、コンピューティングデバイスの現在のコンテキストを記述するコンテキスト情報（例えば、コンテキストアイテム）を含むことができる。

図４０－２Ａ及び図４０－２Ｂは、例示的な現在のコンテキスト４０＿２００及び４０＿２５０を示す。図４０－２Ａは、現在のコンテキスト４０＿２００を構成し得るコンテキストアイテムの例を示す。例えば、現在のコンテキスト４０＿２００（例えば、現在のコンテキスト４０＿１１２）は、時間Ｔでのコンピューティングデバイスについてのコンテキスト情報を含むことができる。例えば、現在のコンテキスト４０＿２００は、現在のロック状態（偽）を表すコンテキストアイテムを含むことができる。現在のコンテキスト４０＿２００は、ヘッドホンジャックの差し込まれた状態（偽）を表すコンテキストアイテムを含むことができる。現在のコンテキスト４０＿２００は、バッテリの充電状態（偽）を表すコンテキストアイテムを含むことができる。現在のコンテキスト４０＿２００は、Ｂｌｕｅｔｏｏｔｈ送受信機の接続状態（偽）を表すコンテキストアイテムを含むことができる。現在のコンテキスト４０＿２００は、現在コンピューティングデバイス上でフォーカスされているアプリケーションを特定するコンテキストアイテムを含むことができる。現在のコンテキスト４０＿２００に示されるコンテキスト情報は、例えば、モニタバンドル４０＿１０６及び／又は報告クライアント４０＿１２４から受信され得る。

図４０－２Ｂは、現在のコンテキスト４０＿２５０に新たなコンテキストアイテムが追加される例を示す。現在のコンテキスト４０＿２５０（現在のコンテキスト４０＿１１２）は、コンピューティングデバイスのいくらか後の時間Ｔ'についてのコンテキスト情報を含むことができる。例えば、現在のコンテキスト４０＿２５０は、コンピューティングデバイスの現在の位置を特定する新たなコンテキストアイテムを含む。新たな位置コンテキストアイテムは、新たな位置モニタバンドル４０＿１０６がコンテキストデーモン４０＿１０２にローディングされ、位置コンテキスト情報をコンテキストデーモン４０＿１０２に報告し始めたときに、追加することができる。例えば、新たな位置モニタバンドル４０＿１０６を、コンテキストクライアントからの位置情報についての要求に応じてローディングすることができる。
コールバック要求

図４０－１を参照すると、一部の実装では、コンテキストデーモン４０＿１０２は、コンピューティングデバイス上で稼働しているコンテキストクライアントソフトウェアに、現在のコンテキスト４０＿１１２内の情報にアクセスすること（例えば、問い合わせる、閲覧するなど）を可能にするＡＰＩを露出させることができる。一部の実装では、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６（コンテキストクライアント）から、特定のコンテキストがコンテキストデーモン４０＿１０２によって検出されたときに、要求クライアント４０＿１２６をコールバックすることの要求を受信することができる。例えば、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２にコールバック要求を送ることができる。コールバックデーモン４０＿１０２は、コールバックレジストリ４０＿１１４にコールバック要求情報を記憶させることができる。コールバックレジストリ４０＿１１４は、コールバック情報のメモリ内リポジトリであり得る。例えば、コールバックリクエストは、要求クライアント４０＿１２６に通知するための述語（predicate）（例えば、コンテキスト条件）を指定することができる。コールバック要求は、要求クライアント４０＿１２６のクライアント識別子を含むことができる。

一部の実装では、コールバック要求が受信されたときに、コールバックレジストリ４０＿１１４はコールバック要求についての固有の識別子を生成して、コールバック要求識別子、クライアント識別子、及びコールバック述語をコールバック述語データベース４０＿１１６に記憶させることができる。コンテキストデーモン４０＿１０２は、コールバック要求を受信したことに応じて、コールバック要求識別子を要求クライアント４０＿１２６に返すことができる。現在のコンテキスト４０＿１１２内のコンテキスト情報が述語を満たすときに、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知する。例えば、コールバック通知はコールバック要求識別子を含むことができ、そのことで要求クライアント４０＿１２６は通知に対応するコールバック要求を判定することができる。例えば、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２で多くのコールバック要求を登録することができる。コールバックデーモン４０＿１０２が要求クライアント４０＿１２６にコールバック通知を送信するときに、要求クライアント４０＿１２６は、コールバック通知がどのコールバック要求に関するのかを判定する際にコールバック要求識別子を用いることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、コールバック要求を要求クライアント４０＿１２６から受信したのに応じて、モニタバンドル４０＿１０６をローディングすることができる。例えば、コンテキストデーモン４０＿１０２は、モニタバンドル４０＿１０６の遅延初期化（lazy initialization）をサポートすることができる。言い換えると、コンテキストデーモン４０＿１０２はコールバック要求にサービスする必要があるときに、モニタバンドル４０＿１０６をローディングして初期化することができる。例えば、もしどのクライアントも位置情報を対象としない場合、コンテキストデーモン４０＿１０２は、必要でないコンテキストアイテムを監視するためにシステムリソース（例えば、バッテリ、メモリなど）が無駄にされないように、位置モニタバンドル４０＿１０６をローディングしなくてもよい。しかしながら、位置コンテキストアイテムのコールバック要求を受信すると、コンテキストデーモン４０＿１０２は、位置コンテキストアイテムに関連付けられたモニタバンドル４０＿１０６をローディングする、初期化する、又は呼び出して、コンピューティングデバイスの位置に関するコンテキスト情報を受信し始めることができる。

一部の実装では、モニタバンドル４０＿１０６はコンテキストデーモン４０＿１０２用のソフトウェアプラグインであり得る。例えば、モニタバンドル４０＿１０６は、コンテキスト情報を監視するために動的にコンテキストデーモン４０＿１０２にローディングして実行できるソフトウェアコード（例えば、ライブラリ、オブジェクトコード、Ｊａｖａ ｊａｒファイルなど）であり得る。一部の実装では、モニタバンドル４０＿１０６は、コンテキストデーモン４０＿１０２に対して外部の別プロセスであり得る。例えば、モニタバンドル４０＿１０６は、コンテキスト情報を監視して報告するためにコンテキストデーモン４０＿１０２が呼び出すことができる、独立した実行可能ファイルであり得る。

図４０－３は、例示的なコールバック述語データベース４０＿３００を示す。例えば、述語データベース４０＿３００は、図１の述語データベース４０＿１１６と対応することができる。一部の実装では、述語データベース４０＿３００内のそれぞれのエントリ４０＿３０２～４０＿３１６は、コールバック要求識別子を含むことができる。例えば、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６からコールバック要求を受信したときに、コンテキストデーモン４０＿１０２はコールバック要求についての固有の要求識別子を生成することができる。上述のように、コンテキストデーモン４０＿１０２はコールバック要求識別子を、コールバック要求に応じて、要求クライアント４０＿１２６に返すことができる。コンテキストデーモン４０＿１０２は生成されたコールバック要求識別子を、クライアント識別子及びコールバックデータベース内のコールバック述語に関連付けることができる。コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６にコールバック通知を送信するときに、コンテキストデーモン４０＿１０２は通知にコールバック識別子を含むことで、なぜコンテキストデーモン４０＿１０２がコールバック通知を送信しているのか、要求クライアント４０＿１２６は判定することができる。例えば、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２に複数のコールバック要求を送信してもよい。要求クライアント４０＿１２６は、どのコールバック要求に対してコンテキストデーモン４０＿１０２がコールバック要求識別子に基づいて通知を送信しているのかを判定することができる。

一部の実装では、述語データベース４０＿３００内のそれぞれのエントリ４０＿３０２～４０＿３１６は、クライアント識別子及びコールバック述語を含むことができる。クライアント識別子は、コンピューティングデバイスの現在のコンテキストが要求クライアント４０＿１２６によって指定された対応する述語を満たしたときに、通知される（例えば、コールバックされる）ことを要求したクライアントに対応することができる。一部の実装では、クライアント識別子は、以下に更に説明するように、コンピューティングデバイス上のプロセスを起動する（例えば、実行する、呼び出すなど）ように構成される起動デーモンによって生成することができる。例えば、エントリ４０＿３０２は、コンピューティングデバイスの現在のコンテキストが、そのデバイスがロックされており、かつフォーカスアプリケーションがミュージックアプリケーションであることを示すときに、通知されることを要求しているクライアント識別子「Ｃｌｉｅｎｔ＿ＩＤ１」を有する、要求クライアント４０＿１２６に対応する。言い方を変えると、クライアント識別子「Ｃｌｉｅｎｔ＿ＩＤ１」に対応するコンテキストクライアント（例えば、要求クライアント４０＿１２６）は、コンテキストクライアントに通知する（例えば、コールバックする）ための述語は、デバイスがロックされており、ユーザによって現在使用されているアプリケーションがミュージックアプリケーションであることを指定している。例えば、要求クライアント４０＿１２６によって指定された述語は、論理（例えば、Ｂｏｏｌｅａｎ）演算子によって分けられた１つ以上のコンテキスト条件（例えば、ハードウェア状態値、ソフトウェア状態値、導出されたコンテキストなど）を識別することができる。コンピューティングデバイスの現在の状態が指定された述語と対応するときに、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知する（例えば、コールバックする）。

一部の実装では、述語は時間構成要素を含むことができる。例えば、述語は、要求クライアント４０＿１２６に、要求クライアント４０＿１２６が通知されるべきときに何かのイベント（例えば、状態変更、コンテキスト変更など）の前又は後の時間を示すことを可能とする「前」及び／又は「後」演算子（項）を含むことができる。例えば、コンテキストデーモン４０＿１０２は、今後の特定の時間にミーティングがスケジューリングされていることを示すカレンダーアプリケーション状態情報を受信することができる。要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６にミーティングの３０分前に通知すべきであると指定する述語（例えば、エントリ４０＿３１６）を登録することができる。現在時刻がミーティングの３０分前に対応する時、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知を送信することができる。同様に、コンテキストデーモン４０＿１０２は、過去コンテキスト情報に基づいて、今後のイベント（例えば、ユーザの睡眠期間、ユーザの帰宅、ユーザの出勤、ユーザの起床など）を予測することができる。例えば、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６にユーザの予測睡眠期間の３０分前に通知すべきであると指定する述語（例えば、エントリ４０＿３０６）を登録することができる。現在時刻が予測睡眠期間の３０分前に対応する時、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知を送信することができる。同様に、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６に、ユーザの予測睡眠期間に基づいてユーザが目覚めると予測される５分後に通知すべきであると指定する述語（例えば、エントリ４０＿３１０）を登録することができる。例えば、現在時刻が、ユーザが目覚めた５分後に対応する時、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知を送信することができる。
イベントストリーム

図４０－１を参照すると、一部の実装では、コンテキストデーモン４０＿１０２は過去知識リポジトリ４０＿１１８を含むことができる。例えば、現在のコンテキスト４０＿１１２が現在のコンピューティングデバイスの状態を反映するコンテキスト情報を含む一方で、上述したように、過去知識４０＿１１８は過去コンテキスト情報を含む。過去知識４０＿１１８は、過去コンテキスト情報のメモリ内リポジトリであり得る。例えば、過去知識４０＿１１８は、コンテキスト（例えば、状態）における経時的な変化を表すイベントストリームを含むことができる。例えば、現在のコンテキスト４０＿１１２にて追跡されるイベント又はコンテキストアイテムのそれぞれは、対応する値を有する。現在のコンテキスト４０＿１１２におけるコンテキストアイテムの値が変化すると、古い値は過去知識４０＿１１８に記録され得る。状態変化を分析することで、各コンテキストアイテム値について、開始時間、終了時間、及び持続時間を計算することができる。

図４０－４は、コンテキストアイテムに関連付けられる例示的な値の経時的な変化を示すグラフ４０＿４００である。例えば、グラフ４０＿４００は、ロック状態、ヘッドホン、充電、Ｂｌｕｅｔｏｏｔｈ、フォーカスアプリ、睡眠、及び位置コンテキストアイテムについての現在の値を示す、現在のコンテキスト４０＿４０２を含む。グラフ４０＿４００は、同様のコンテキストアイテムについての経時的な過去（履歴）値４０＿４０４を含む。コンテキストアイテム値での変化を分析することで、コンテキストデーモン４０＿１０２は、以下の図５に示すように、コンテキストアイテムに関連付けられるそれぞれの値についての開始時間、終了時間、及び持続時間を判定することができる。

図４０－５は、コンテキストアイテムに関連付けられた例示的なイベントストリームを示すグラフ４０＿５００である。一部の実装では、図４０－４のグラフ４０＿４００に表されるそれぞれの状態変化は、システム内に特定の状態が存在した持続時間を記述するデータ及び状態に関連付けられたメタデータを含むデータオブジェクト（例えば、オブジェクト４０＿５０２）に変換することができる。一部の実装では、過去モニタ４０＿１１０は、現在及び／又は過去コンテキスト情報を過去イベントストリームオブジェクトに変換するように構成することができる。例えば、特定のモニタバンドル４０＿１０６に対応するコンテキストアイテムについて値の変化が検出されたとき、過去モニタ４０＿１１０はコンテキストアイテムの前の値に基づいて過去イベントストリームオブジェクトを生成することができる。例えば、一部のコンテキストモニタ４０＿１０６は、コンピューティングデバイスのソフトウェア及び／又はハードウェア構成要素の状態を定期的に報告するように構成することができる。コンテキストモニタ４０＿１０６は、例えば、Ｂｌｕｅｔｏｏｔｈ状態情報を定期的に報告するように構成することができる。報告されたＢｌｕｅｔｏｏｔｈ状態情報は、連続の同一状態値を含んでもよく、次に状態変化が続いてもよい。例えば、コンテキストモニタ４０＿１０６は、Ｂｌｕｅｔｏｏｔｈの状態が「オフ、オフ、オフ、オフ、オン」であると報告することができる。過去モニタ４０＿１１０は一連の「オフ」のＢｌｕｅｔｏｏｔｈコンテキストアイテムの値を組み合わせて、「オフ」値の開始時間及び終了時間を判定し、どれだけ長くＢｌｕｅｔｏｏｔｈ構成要素が「オフ」状態であったかを計算することができる。

一部の実装では、過去モニタ４０＿１１０はイベントストリームオブジェクトについて、追加情報（例えば、メタデータ）を収集することができる。例えば、上記のＢｌｕｅｔｏｏｔｈについて続けると、過去モニタ４０＿１１０は、Ｂｌｕｅｔｏｏｔｈコンテキストアイテムが「オン」値を有していたと判定し、Ｂｌｕｅｔｏｏｔｈ ＡＰＩ４０＿１３８からの追加情報を要求することができる。例えば、過去モニタ４０＿１１０は、コンピューティングデバイスに接続されるＢｌｕｅｔｏｏｔｈデバイスの種類を識別する情報、用いられているＢｌｕｅｔｏｏｔｈプロトコル、Ｂｌｕｅｔｏｏｔｈ接続を介して送信されるデータ量、及び／又はＢｌｕｅｔｏｏｔｈ接続に関連する任意の他の情報を、Ｂｌｕｅｔｏｏｔｈ ＡＰＩ４０＿１３８から受信することができる。

別の例では、コンテキストモニタ４０＿１０８が、現在のコンテキスト情報（例えば、通話情報）を、テレフォニーＡＰＩ（例えば、掛けられた電話番号、通話が開始された時間、通話が終了した時間など）から収集するように構成することができる一方で、過去モニタ４０＿１１０は連絡先ＡＰＩ（例えば、電話を掛けられた人の名前など）又は通話履歴ＡＰＩ（例えば、電話を掛けられた人の名前、通話時間など）から、通話についてのイベントストリームメタデータを収集することができ、この追加情報をテレフォニーコンテキストアイテムについてのイベントストリームオブジェクトに追加することができる。よって、過去モニタ４０＿１１０は、過去イベント（例えば、イベントストリーム、イベントストリームオブジェクト）を過去資料として、及び今後のイベントを予測するためにより価値のあるものとするために、過去イベントについての追加データを生成又は収集するように構成することができる。過去モニタ４０＿１１０がイベントストリームメタデータを収集又は生成すると、過去モニタ４０＿１１０はイベントストリームメタデータを過去知識リポジトリ４０＿１１８に記憶させることができる。一部の実装では、コンテキストデーモン４０＿１０２及び／又は過去モニタ４０＿１１０は、イベントストリームオブジェクト（例えば、開始時間、終了時間、持続時間、及び／又はメタデータ）を履歴データベース４０＿１２０に記憶させることができる。

図４０－６は、例示的な過去イベントストリームデータベース４０＿６００を示す。例えば、過去イベントストリームデータベースは、履歴データベース４０＿１２０に対応することができる。例示的な過去イベントストリームデータベース４０＿６００は、履歴データベース４０＿６００に記憶される過去イベントストリームデータの概念図を表し、履歴データベース４０＿６００の実際の実装を反映しなくてもよい。当業者であれば、データベース４０＿６００内の過去イベントストリームデータが多くの異なる方法で編成及び記憶され得ることを認識するであろう。

一部の実装では、履歴データベース４０＿６００はイベントストリーム表４０＿６０２～４０＿６１４を含むことができる。例えば、各イベントストリーム表４０＿６０２～６１４は単一のイベントストリーム（例えば、コンテキストアイテム）に対応することができる。それぞれのイベントストリーム表（例えば、表４０＿６０２）は、イベントストリーム内のイベントストリームオブジェクトに対応する記録（例えば、４０＿６１６、４０＿６１８など）を含むことができる。例えば、「ロック状態（locked）」イベントストリーム表４０＿６０２は、「ロック状態」イベントストリームのロックされている（又はロック解除されている）状態を記述するイベントストリームオブジェクト記録４０＿６１６、４０＿６１８を含むことができる。イベントストリームオブジェクト記録は、いつイベントが開始したかを示すタイムスタンプ（timestamp；ＴＳ）値を有する「開始」フィールドを含むことができる。イベントストリームオブジェクト記録は、イベントの持続時間（duration；Ｄ）を示す「持続時間」フィールドを含むことができる。イベントストリームオブジェクト記録は、イベントに対応する状態変化を記述する状態情報（例えば、デバイスがロックされていなかったことを示す「ロック状態：偽」）を含むことができる。

一部の実装では、イベントストリームオブジェクト記録は、イベントに関連付けられた他のデータを記載するメタデータを含むことができる。例えば、過去イベントストリームデータを生成する時に、過去モニタ４０＿１１０は、イベント時のシステムの状態の追加属性、又はそれを取り囲む状況を記述するメタデータを、収集及び／又は生成することができる。例えば、「充電」イベントストリーム４０＿６０６については、過去モニタ４０＿１１０は、充電イベントの始め及び／又は終わりに、バッテリ充電の状態（例えば、充電率、充電レベルなど）に関する情報を収集することができる。Ｂｌｕｅｔｏｏｔｈイベントストリーム４０＿６０８については、過去モニタ４０＿１１０は、コンピューティングデバイスに接続されたＢｌｕｅｔｏｏｔｈデバイスの種類及び／又はＢｌｕｅｔｏｏｔｈデバイスに送信される媒体のソースに関する情報を収集することができる。位置イベントストリーム４０＿６１２については、過去モニタ４０＿１１０は生の位置データ（例えば、グリッド座標、ＧＮＳＳデータ、セルタワー識別データ、ＷｉＦｉネットワーク識別子など）を、人間のユーザが理解できる位置用語（例えば、自宅、職場、学校、食料品店、レストラン名など）に変換することができる。

一部の実装では、過去モニタ４０＿１１０はコンテキストモニタ４０＿１０８に比べて、より正確な位置情報を生成又は取得することができる。例えば、コンテキストモニタ４０＿１０８は、プロセッシングを、あったとしてもほとんど必要とすることなく、現在の（例えば、瞬間的な）位置情報を提供することができる。この初期位置データは、位置技術（例えば、信号マルチパス問題、十分な数の衛星と接続する困難性など）の多種多様な問題によって不正確であり得る。追加の時間及び追加のデータを与えられると、位置をより正確に判定することができる。過去モニタ４０＿１１０が（現在又は瞬間的なデータではなく）過去データを処理するため、過去モニタ４０＿１１０は、例えば、位置ＡＰＩ４０＿１３２からのより正確な位置情報を取得するのに時間を取ることがある。イベントを説明するこの追加のメタデータを、履歴データベース４０＿６００のイベントストリーム記録内に記憶することができる。

一部の実装では、過去モニタ４０＿１１０は、モニタバンドル４０＿１０６初期化後にコンテキストアイテムについての過去情報を取得することができる。例えば、モニタバンドル４０＿１０６が位置コンテキストを監視するように構成される場合、コンテキストデーモン４０＿１０２は、上記のとおり、必要に応じて、モニタバンドル４０＿１０６をローディングする、呼び出す、及び／又は初期化することができる。モニタバンドル４０＿１０６が初期化されるときに、コンテキストモニタ４０＿１０８は位置コンテキストアイテムについてのコンテキスト情報を収集する。しかしながら、モニタバンドル４０＿１０６が初期化されると、位置コンテキストアイテムが前に監視されていなかったために位置コンテキストアイテムの過去データがない。よって、一部の実装では、過去モニタ４０＿１１０は位置ＡＰＩ４０＿１３２からの位置履歴データを要求して、過去コンテキスト情報（例えば、イベントストリーム、イベントストリームオブジェクトなど）を、位置ＡＰＩ４０＿１３２から受信される位置履歴データに基づいて生成することができる。
イベントストリームプライバシー

一部の実装では、イベントストリームはそれぞれ、対応するプライバシーポリシーを有することができる。一部の実装では、イベントストリームはデフォルトのプライバシーポリシーで構成され得る。一部の実装では、管理者ユーザは、それぞれのイベントストリームについて（例えば、それぞれのコンテキストアイテムについて）のプライバシーポリシーを構成するために、コンピューティングデバイスに入力を提供することができる。例えば、それぞれのイベントストリームに対応するプライバシーポリシーは経時的に変化し得る。

一部の実装では、コンテキストアイテムについてのイベントストリームは、コンテキストアイテムについての過去情報を保持するのを防止するプライバシーポリシーを有することができる。例えば、位置コンテキストアイテムに対応するイベントストリームは、コンピューティングデバイスの位置の過去記録を保持するのを許可しないポリシーを有することができる。この「履歴無し」ポリシーがイベントストリームについて構成されると、過去モニタ４０＿１１０はイベントストリームについて過去コンテキスト情報（例えば、イベントストリームオブジェクト）を生成しない。

一部の実装では、コンテキストアイテムについてのイベントストリームは、過去コンテキスト情報が削除される前に記憶されるべき時間量（例えば、存続時間）を指定するプライバシーポリシーを有することができる。例えば、「フォーカスアプリ」コンテキストアイテムに対応するイベントストリームは、指定された時間量（例えば、３日、１カ月など）よりも古い「フォーカスアプリ」コンテキストアイテムについてのイベントストリームデータは削除されるべきであると指定する存続時間ポリシーを有することができる。コンテキストデーモン４０＿１０２は、イベントストリーム上でメンテナンスを定期的に実行して、存続時間ポリシーに指定された時間量よりも古いイベントストリームオブジェクトを削除することができる。

一部の実装では、コンテキストアイテムについてのイベントストリームは、タイムスタンプ解像度低下（timestamp de-resolution）ポリシーを有することができる。例えば、タイムスタンプ解像度低下ポリシーが有効であるとき、過去モニタ４０＿１１０はイベントストリーム内のイベント（例えば、状態変化）に関する精細なタイムスタンプを、より不精細にする。例えば、位置変化イベントは、ミリ秒まで正確なタイムスタンプを有することができる。解像度低下ポリシーがイベントストリームに適用されると、過去モニタ４０＿１１０は、秒又は分まで正確な、より正確性の低いタイムスタンプを用いることができる。例えば、位置イベントストリームにより正確性の低いタイムスタンプを使用することで、システムはコンテキストクライアントがユーザの動作の正確なタイミングを判定することを妨げることによって、ユーザのプライバシーを保護することができる。

一部の実装では、コンテキストアイテムについてのイベントストリームは、記憶場所ポリシーを有することができる。例えば、コンピューティングデバイスは、コンピューティングデバイスのセキュリティ状態に対応する、異なる記憶場所で構成することができる。例えば、コンピューティングデバイスは、コンピューティングデバイスがロック解除されている（例えば、ユーザがデバイスをロック解除するためにパスコードを入力した）時にのみアクセスできる、「Ａ」クラスデータベースを有することができる。コンピューティングデバイスは、コンピューティングデバイスの再起動又は起動した後の最初のロック解除の後（例えば、後続のロック解除を必要とせずに）アクセスすることができる、「Ｂ」クラスデータベースを有することができる。コンピューティングデバイスは、いつでも（例えば、パスコード入力に関わらず）アクセスすることができる、「Ｃ」クラスデータベースを有することができる。イベントストリームについての記憶場所プライバシーポリシーは、対応するイベントストリームデータをどのクラスのデータベースに記憶するかを識別することができる。
効率的なコンテキスト監視

一部の実装では、コンピューティングデバイスは、ソフトウェアが使用されていない時にコンピュータデバイス上で稼働しているソフトウェアを終了させるように構成することができる。例えば、コンピューティングデバイスのオペレーティングシステムは、アイドル状態のプロセスを識別するように構成することができる。オペレーティングシステムは、アイドル状態のプロセスをシャットダウン（例えば、終了、強制終了）して、システムの他の構成要素（例えば、ソフトウェア、ハードウェア）による使用のために、メモリを空ける、又はバッテリリソースを節約することができる。しかしながら、オペレーティングシステムがアイドル状態のコンテキストデーモン４０＿１０２を終了させた場合、コンテキストデーモン４０＿１０２はシステムの現在のコンテキストをそれ以上監視できなくなり、要求クライアント４０＿１２６にコンテキスト変更を通知することができなくなる。同様に、オペレーティングシステムがアイドル状態の要求クライアント４０＿１２６を終了させた場合、要求クライアント４０＿１２６はコンテキストデーモン４０＿１０２からのコールバック通知を受信するように稼働していないことになる。以下の段落では、コンテキストの監視及び／又はコールバック動作を対処するためにコンテキストデーモン４０＿１０２及び／又は要求クライアント４０＿１２６を再起動できる様々な機構を説明する。

図４０－７は、コンテキストコールバック通知を要求クライアント４０＿１２６に提供するための例示的なシステム４０＿７００のブロック図である。例えば、システム４０＿７００は、上記図１のシステム４０＿１００に対応することができる。一部の実装では、システム４０＿７００は起動デーモン４０＿７０２を含むことができる。例えば、起動デーモン４０＿７０２は、コンピューティングデバイス上に、アプリケーション、ユーティリティ、ツール、及び／又は他のプロセスを起動する（例えば、呼び出す、開始する、実行する、初期化するなど）ように構成することができる。起動デーモン４０＿７０２は、コンピューティングデバイス上でプロセスを監視したり、アイドル状態のプロセスを終了させたりするように構成することができる。

一部の実装では、起動デーモン４０＿７０２は要求クライアント４０＿１２６を起動することができる。例えば、コンピューティングデバイス上で稼働しているプロセス（オペレーティングシステム、ユーザアプリケーション等）は、要求クライアント４０＿１２６を呼び出すことができる。起動デーモン４０＿７０２は呼び出しに対応するメッセージを受信することができ、要求クライアント４０＿１２６を起動することができる。要求クライアント４０＿１２６を起動すると、起動デーモン４０＿７０２は、コンピューティングデバイス内で要求クライアント４０＿１２６を識別するのに用いることができるクライアント識別子４０＿７０４を要求クライアント４０＿１２６に提供することができる。

一部の実装では、クライアント識別子４０＿７０４は、起動デーモン４０＿７０２によって生成され、起動デーモン４０＿７０２によって要求クライアント４０＿１２６に割り当てられるトークン（例えば、暗号化データ）であることができる。起動デーモン４０＿７０２は、トークンと、クライアント識別子データベース４０＿７０６内の要求クライアント４０＿１２６に対応する（例えば、定義する）ソフトウェアパッケージとの間のマッピングを記憶することができる。トークンは、トークン自体は対応する要求クライアント４０＿１２６を特定しないように生成することができる。しかしながら、起動デーモン４０＿７０２が後程トークンを受信したときに、起動デーモン４０＿７０２はクライアント識別子データベース４０＿７０６内にて対応する要求クライアント４０＿１２６をルックアップするために、トークンを利用することができる。よって、トークンは、コンピューティングデバイス内で他のソフトウェアに対して不透明でありながら、起動デーモン４０＿７０２によって対応する要求クライアントを特定するためのインデックスとして用いられ得る。

一部の実装では、クライアント識別子４０＿７０４は、要求クライアント４０＿１２６の特定のインスタンスに対応するインスタンス識別子であり得る。一部の実装では、クライアント識別子４０＿７０４は、要求クライアント４０＿１２６の全てのインスタンスにわたって、ソフトウェアパッケージ（例えば、アプリケーション、ユーティリティ、ツールなど）を特定することができる。例えば、起動デーモン４０＿７０２が要求クライアント４０＿１２６の第１のインスタンスを起動したときに、クライアント識別子４０＿７０４は要求クライアント４０＿１２６の第１のインスタンスを特定することができる。要求クライアント４０＿１２６が終了すると（例えば、要求クライアント４０＿１２６がアイドル状態になったために）、同じクライアント識別子４０＿７０４を、起動デーモン４０＿７０２によって起動された要求クライアント４０＿１２６のその後のインスタンスを特定するために用いることができる。起動デーモン４０＿７０２は、要求クライアント４０＿１２６と同様の機構を用いて、コンテキストデーモン４０＿１０２を起動することができる。

一部の実装では、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２にコールバック要求４０＿７０８を送ることができる。例えば、コールバック要求４０＿７０８は、上記のとおり、クライアント識別子４０＿７０４とコールバック述語とを、含むことができる。コールバック要求４０＿７０８を受信すると、コンテキストデーモン４０＿１０２はクライアント識別子４０＿７０４及び述語を、上記のとおり、述語データベース４０＿１１６に記憶させることができる。

一部の実装では、要求クライアント４０＿１２６がコールバック要求４０＿７０８をコンテキストデーモン４０＿１０２に送るとき、要求クライアントは、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間で通信セッション４０＿７０９を確立する。一部の実装では、システム４０＿７００は、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間の通信セッションが要求クライアント４０＿１２６によってのみ、初期化できるように、構成可能である。例えば、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６との通信セッションを直接確立することができないことがある。よって、一部の実装では、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６によって確立された通信セッション４０＿７０９がまだ開いている間にしか、要求クライアント４０＿１２６と通信する（例えば、コールバック通知を送る）ことができない。

一部の実装では、コンテキストデーモン４０＿１０２は、コンピューティングデバイスで発生しているイベントについてのコンテキスト情報を収集することができる。例えば、コンテキストデーモン４０＿１０２は、上記のとおり、モニタバンドル４０＿１０６及び報告クライアント４０＿１２４からコンテキスト情報を収集することができる。一部の実装では、コンテキストデーモン４０＿１０２は、現在のコンテキストをコンテキストデータベース４０＿７１２に記憶させることができる。例えば、コンテキストデーモン４０＿１０２は、現在のコンテキストをコンテキストデータベース４０＿７１２に記憶させて、コンテキストデーモン４０＿１０２へのコンテキスト情報のリストアを容易にすることができる。コンテキストデーモン４０＿１０２が終了されて再起動されたとき、コンテキストデーモン４０＿１０２は、コンテキストデーモン４０＿１０２がモニタバンドル４０＿１０６からのコンテキスト更新を待っている間に、現在のコンテキスト（例えば、今は古いコンテキスト）をコンテキストデータベース４０＿７１２からリストアすることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、現在のコンテキストが要求クライアント４０＿１２６から受信した述語に対応するかどうかを判定することができる。例えば、現在のコンテキストを更新する（例えば、コンテキストアイテムの状態を変更する）新たなコンテキストデータが取得されたとき、コンテキストデーモン４０＿１０２は、コールバックレジストリ４０＿１１４又は述語データベース４０＿１１６内にコンテキストデーモン４０＿１０２によって記憶されたコールバック述語を現在のコンテキスト４０＿１１２内のコンテキストアイテムと比較して、現在のコンテキストが述語によって指定された条件と一致する（対応する）かどうかを判定することができる。現在のコンテキストが要求クライアント４０＿１２６によって登録された述語と一致するとき、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知４０＿７０１を送ることができる。例えば、通知４０＿７０１は、上記のように、以前に要求クライアント４０＿１２６によってコンテキストデーモン４０＿１０２に送られたコールバック要求を特定することができる。よって、コンテキストデーモン４０＿１０２は、コンテキストデーモン４０＿１０２が、要求クライアント４０＿１２６が対象とする現在のコンテキストを検出した時に、要求クライアント４０＿１２６に通知する（例えば、コールバックする）ことができる。

図４０－８Ａ及び図４０－８Ｂは、終了されている要求クライアントを再起動することを示す例示的なシステム４０＿７００のブロック図である。例えば、図４０－８Ａでは、システム４０＿７００は、要求クライアント４０＿１２６がアイドル状態にあると判定し、要求クライアント４０＿１２６を終了させている（例えば、要求クライアント４０＿１２６の破線の外枠は終了していることを示す）。図４０－８Ａでは、コンテキストデーモン４０＿１０２はまだ稼働している。しかしながら、要求クライアント４０＿１２６が終了しているため、コミュニケーションセッション４０＿７０９もまた、終了している。

図４０－８Ｂは、システム４０＿７００を用いて、要求クライアント４０＿１２６を再起動するための例示的な機構を示すブロック図である。図４０－８Ａの例で続けると、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６によって登録されたコールバック述語に一致するコンテキスト情報を受信することができる。コンテキスト情報がコールバック述語と一致すると判定したことに応じて、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知しようと試みることができる。要求クライアント４０＿１２６に通知しようと試みる間、コンテキストデーモン４０＿１０２は、コンテキストデーモン４０＿１０２と要求クライアント４０＿１２６との間の通信セッション４０＿７０９が終了していると判定することができる。通信セッション４０＿７０９が終了していると判定したことに応じて、コンテキストデーモン４０＿１０２は起動デーモン４０＿７０２が要求クライアント４０＿１２６を再起動するように要求することができる。例えば、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６を再起動する要求において、要求クライアント４０＿１２６から受信されたクライアント識別子４０＿７０４を起動デーモン４０＿７０２に送信することができる。

一部の実装では、起動デーモン４０＿７０２は、クライアント識別子４０＿７０４を受信すると、要求クライアント４０＿１２６を起動することができる。例えば、起動デーモン４０＿７０２は、コンテキストデーモン４０＿１０２には、要求クライアント４０＿１２６を再起動するように要求する権限があると、コンテキストデーモン４０＿１０２によって提供されたクライアント識別子に基づいて判定することができる。例えば、要求クライアント４０＿１２６が以前に、コンテキストデーモン４０＿１０２からのコールバックを要求し、コンテキストデーモン４０＿１０２にクライアント識別子４０＿７０４を提供していなければ、コンテキストデーモン４０＿１０２はクライアント識別子４０＿７０４（例えば、トークン）を有していないであろう。

一部の実装では、再起動の際、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２にコールバック要求４０＿７０８を送ることができる。例えば、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２にコールバック要求４０＿７０８を送ることによって、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間に新たな通信セッション４０＿８０２を確立することができる。通信セッション４０＿８０２が確立されれば、コンテキストデーモン４０＿１０２は通知４０＿７１０を要求クライアント４０＿１２６に送信して、要求クライアント４０＿１２６によって提供されたコールバック述語が現在のコンテキストによって満足されていることを要求クライアント４０＿１２６に通知することができる。

図４０－９Ａ及び図４０－９Ｂは、終了しているコンテキストデーモンを再起動することを示す、例示的なシステム４０＿７００のブロック図である。例えば、図４０－９Ａでは、システム４０＿７００は、コンテキストデーモン４０＿１０２がアイドル状態であると判定し、コンテキストデーモン４０＿１０２を終了させている（例えば、コンテキストデーモン４０＿１０２の破線の外枠は、終了していることを示す）。図４０－９Ａでは、要求クライアント４０＿１２６はまだ稼働している。しかしながら、コンテキストデーモン４０＿１０２が終了しているため、通信セッション４０＿７０９もまた、終了している。

図４０－９Ｂは、システム４０＿７００を用いて、コンテキストデーモン４０＿１０２を再起動するための例示的な機構を示すブロック図である。図４０－９Ａの例で続けると、システム４０＿７００はコンテキストデーモン４０＿１０２を、コンテキストデーモン４０＿１０２に向けられた要求クライアント４０＿１２６からのメッセージを受信したことに応じて再起動することができる。

一部の実装では、要求クライアント４０＿１２６は、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間の通信セッション４０＿７０９が終了していると検出することができる。通信セッション４０＿７０９が終了していることを検出したことに応じて、要求クライアント４０＿１２６は、終了したコンテキストデーモン４０＿１０２にメッセージを送信することで通信セッションを再確立することができる。一部の実装では、要求クライアントは、メッセージをメッセージングシステム４０＿９０２を用いてコンテキストデーモン４０＿１０２に送ることができる。システム４０＿７００のメッセージングシステム４０＿９０２は、コンテキストデーモン４０＿１０２が稼働していないと判定することができ、起動デーモン４０＿７０２にコンテキストデーモン４０＿１０２を再起動させるように、起動デーモン４０＿７０２にメッセージを送ることができる。メッセージを受信したことに応じて、起動デーモン４０＿７０２はコンテキストデーモン４０＿１０２を再起動することができる。コンテキストデーモン４０＿１０２が稼働すると、メッセージングシステム４０＿９０２は要求クライアント４０＿１２６からのメッセージをコンテキストデーモン４０＿１０２に送ることができ、そのことによって、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間の通信チャネルを再確立することができる。

一部の実装では、再起動後、コンテキストデーモン４０＿１０２はそのコールバックレジストリ４０＿１１４及び現在のコンテキスト４０＿１１２をリストアすることができる。例えば、コールバックレジストリ４０＿１１４は述語データベース４０＿１１６からリストアされ得る。現在のコンテキスト４０＿１１２は、コンテキストデータベース４０＿７１２からリストアされ得る。再起動後、コンテキストデーモン４０＿１０２は、述語データベース４０＿１１６からリストアされたコールバック要求にサービスするために、コンテキスト情報を収集するのに必要なモニタバンドル４０＿１０６をローディングすることができる。コンテキストデーモン４０＿１０２は、上記のように、現在のコンテキスト４０＿１１２を、ローディングされたモニタバンドル４０＿１０４によって報告されたコンテキスト情報で更新し、現在のコンテキスト４０＿１１２におけるコンテキストアイテムが要求クライアント４０＿１２６によって登録された述語と一致するときに、要求クライアント４０＿１２６に通知することができる。

図４０－１０Ａ及び図４０－１０Ｂは、終了しているコンテキストデーモン及び要求クライアントを再起動することを示す、例示的なシステム４０＿７００のブロック図である。例えば、図４０－１０Ａでは、システム４０＿７００は、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６の両方がアイドル状態にあると判定し、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６を終了させている（例えば、破線の外枠は終了していることを示す）。図４０－１０Ａでは、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６の両方が終了しているため、通信セッション４０＿７０９は終了している。

図４０－１０Ｂは、システム４０＿７００を用いて、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６を再起動するための例示的な機構を示すブロック図である。図４０－１０Ａの例で続けると、システム４０＿７００は、終了しているコンテキストデーモン４０＿１０２に向けられた介在クライアント４０＿１００２からのメッセージを受信したことに応じて、コンテキストデーモン４０＿１０２を再起動することができる。例えば、図４０－９Ｂにおける要求クライアント４０＿１２６と同様に、介在クライアント４０＿１００２は今は終了しているコンテキストデーモン４０＿１０２にメッセージを送ることができる。メッセージングシステム４０＿９０２はメッセージを受信して、コンテキストデーモン４０＿１０２が稼働していないと判定することができる。コンテキストデーモン４０＿１０２が稼働していないと判定したことに応じて、メッセージングシステム４０＿９０２は起動デーモン４０＿７０２にメッセージを送信して、起動デーモン４０＿７０２にコンテキストデーモン４０＿１０２を再起動させることができる。

一部の実装では、再起動後、コンテキストデーモン４０＿１０２はそのコールバックレジストリ４０＿１１４を述語データベース４０＿１１６からリストアすることができる。再起動後、コンテキストデーモン４０＿１０２はその現在のコンテキスト４０＿１１２をコンテキストデータペース４０＿７１２からリストアすることができ、上記のとおり、更新されたコンテキスト情報を収集し始めることができる。コンテキストデーモン４０＿１０２が、登録された述語が現在のコンテキスト情報と一致すると判定すると、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知しようと試みることができる。図４０－８Ｂを参照して上述したように、コンテキストデーモン４０＿１０２が、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間に通信セッション４０＿７０９が存在しないと判定すると、コンテキストデーモン４０＿１０２は、通信セッションが再確立されて、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６をコールバックすることができるように、起動デーモン４０＿７０２が要求クライアント４０＿１２６を再起動することを要求することができる。

図４０－１１は、起動デーモン４０＿７０２から受信されたデバイス状態情報に基づいて、要求クライアント４０＿１２６及び／又はコンテキストデーモン４０＿１０２を再起動するように構成される、例示的なシステム４０＿１１００のブロック図である。例えば、システム４０＿１１００はシステム４０＿７００に対応することができ、上記のように、システム４０＿７００と同様の機能を実行することができる。

一部の実装では、起動デーモン４０＿７０２は、デバイス状態４０＿１１０４を受信するように構成することができる。例えば、デバイス状態４０＿１１０４は、コンピューティングデバイスの様々なハードウェア及び／又はソフトウェア構成要素によって生成される低レベルの具体的な状態データであり得る。例えば、起動デーモン４０＿７０２は、コンピューティングデバイスの位置サービス構成要素（例えば、ＧＰＳ受信機，ＷｉＦｉ、又はセルラデータ構成要素など）によって生成された位置データを含むデバイス状態４０＿１１０４を受信することができる。一部の実装では、デバイス状態４０＿１１０４は位置の変更を示すことはできるが、高レベルの位置情報（例えば、人が読み取れる標識（label））を提供しないことがある。

例えば、要求クライアント４０＿１２６は、位置に基づく述語を有するコールバック要求４０＿７０８をコンテキストデーモン４０＿１０２に送ることができる。述語は、要求クライアント４０＿１２６が、コンピューティングデバイスの現在の位置（例えば、現在のコンテキスト）がユーザの自宅（例えば、位置＝＝自宅）であると通知される必要がある、と指定してもよい。デバイス位置がユーザの自宅であると判定するには、コンテキストデーモン４０＿１０２及び／又はモニタバンドル４０＿１０６は、位置ＡＰＩ４０＿１３２からの情報、及び、「自宅」がどこに位置するのかを定義する（例えば、「自宅」標識と関連付けられた地理的位置を定義する）ユーザのデバイス上で稼働する連絡先アプリケーションから情報を収集することができる。位置ＡＰＩ４０＿１３２からの位置情報を連絡先アプリケーションにおける「自宅」の定義と比較することで、コンテキストデーモン４０＿１０２は、コンテキストアイテム「位置」が「自宅」と等しいときを判定することができる。この例で示すように、要求クライアント４０＿１２６によって定義される位置述語（例えば、「自宅」）が満たされていると判定することは、現在の地理的位置データ（例えば、グリッド座標）と、標識（例えば、「自宅」）を地理的位置と相関させるユーザデータとの両方を組み合わせることによるものである。よって、概念的な位置コンテキスト「自宅」は、コンピューティングデバイスの位置サービス及び連絡先アプリケーションによって生成される具体的な状態データを分析することで、判定することができる。

一部の実装では、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６からコールバック要求４０＿７０８を受信したときに、コンテキストデーモン４０＿１０２は、デバイス状態要求４０＿１１０２を起動デーモン４０＿７０２に送信して、コンピューティングデバイスの特定の構成要素の状態変化への関心を登録することができる。起動デーモン４０＿７０２がデバイス状態４０＿１１０４を受信すると、起動デーモン４０＿７０２は特定構成要素について状態変化があったと判定し、コンテキストデーモン４０＿１０２及び／又は要求クライアント４０＿１２６に通知することができる。

一部の実装では、デバイス状態要求４０＿１１０２は、起動デーモン４０＿７０２がコンテキストデーモン４０＿１０２に、特定の状態変化が発生したときに通知するべきであることを指定することができる。例えば、要求クライアント４０＿１２６が、位置に基づくコールバック述語を指定するコールバック要求をコンテキストデーモン４０＿１０２に送るときに、コンテキストデーモン４０＿１０２は、位置構成要素状態変化が起動デーモン４０＿７０２によって検出されたときに、起動デーモン４０＿７０２がコンテキストデーモン４０＿１０２に通知することを要求するデバイス状態要求４０＿１１０２を起動デーモン４０＿７０２に送信することができる。

一部の実装では、デバイス状態要求４０＿１１０２は、起動デーモン４０＿７０２が、特定の状態変化が発生したときに要求クライアント４０＿１２６に通知するべきであると指定することができる。例えば、要求クライアント４０＿１２６が位置に基づくコールバック述語を指定するコールバック要求をコンテキストデーモン４０＿１０２に送るときに、コンテキストデーモン４０＿１０２は、位置構成要素の状態変化が起動デーモン４０＿７０２によって検出されたときに、起動デーモン４０＿７０２が要求クライアント４０＿１２６に通知することを要求するデバイス状態要求４０＿１１０２を、起動デーモン４０＿７０２に送信することができる。一部の実装では、デバイス状態要求４０＿１１０２は起動デーモン４０＿７０２がどの要求クライアント４０＿１２６に通知するかを判定することができるように、要求クライアント４０＿１２６に対応するクライアント識別子４０＿７０４を含むことができる。

図４０－１２Ａ及び図４０－１２Ｂは、起動デーモンを用いてコンテキストデーモンを再起動することを示す例示的なシステム４０＿１１００のブロック図である。例えば、図４０－１２Ａでは、システム４０＿１１００は、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６の両方がアイドル状態にあると判定しており、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６を終了させている（例えば、破線の外枠は終了していることを示す）。図４０－１２Ａでは、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６の両方が終了しているため、通信セッション４０＿７０９もまた、終了している。

図４０－１２Ｂは、システム４０＿１１００の起動デーモン４０＿７０２を用いて、コンテキストデーモン４０＿１０２を再起動するための例示的な機構を示すブロック図である。図４０－１１を参照して上述したように、コンテキストデーモン４０＿１０２は、コンテキストデーモン４０＿１０２から要求クライアント４０＿１２６に通知４０＿７１０を送信するためのコンテキスト述語を指定するコールバック要求を、要求クライアント４０＿１２６から受信することができる。述語を受信したことに応じて、コンテキストデーモン４０＿１０２はデバイス状態要求４０＿１１０２を起動デーモン４０＿７０２に送信して、述語と関連付けられるデバイス状態変化に関心があることを登録することができる。例えば、要求クライアント４０＿１２６が位置に基づくコールバック述語を指定する場合、コンテキストデーモン４０＿１０２は、コンピューティングデバイスの位置が変わるときをコンテキストデーモン４０＿１０２に通知するように、起動デーモン４０＿７０２に依頼することができる。起動デーモン４０＿７０２が、位置の変更を示すデバイス状態４０＿１１０４を受信したときに、起動デーモン４０＿７０２はコンテキストデーモン４０＿１０２に通知しようと試みることができる。図４０－１２Ａの例を続けると、コンテキストデーモン４０＿１０２がコンピューティングデバイス上で稼働していないため、起動デーモン４０＿７０２はコンテキストデーモン４０＿１０２が稼働していないと判定して、コンテキストデーモン４０＿１０２を起動（例えば、再起動、開始、呼び出し、実行など）することができる。コンテキストデーモン４０＿１０２が再起動されると、図４０－８Ｂを参照して上述したように、コンテキストデーモン４０＿１０２は、起動デーモン４０＿７０２が要求クライアント４０＿１２６を再起動するように要求することができる。

図４０－１３Ａ及び図４０－１３Ｂは、起動デーモンを用いて要求クライアント４０＿１２６を再起動することを示す、例示的なシステム４０＿１１００のブロック図である。例えば、図４０－１３Ａでは、システム４０＿１１００は、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６の両方がアイドル状態にあると判定しており、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６を終了させている（例えば、破線の外枠は終了していることを示す）。図４０－１３Ａでは、コンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６の両方が終了しているため、通信セッション４０＿７０９もまた、終了している。

図４０－１３Ｂは、システム４０＿１１００の起動デーモン４０＿７０２を用いて、要求クライアント４０＿１２６を再起動するための例示的な機構を示すブロック図である。図４０－１１を参照して上述したように、コンテキストデーモン４０＿１０２は、コンテキストデーモン４０＿１０２から要求クライアント４０＿１２６にコールバック通知４０＿７１０を送信するためのコンテキスト述語を指定するコールバック要求を、要求クライアント４０＿１２６から受信することができる。述語を受信したことに応じて、コンテキストデーモン４０＿１０２はデバイス状態要求４０＿１１０２を起動デーモン４０＿７０２に送信して、述語と関連付けられるデバイス状態変化に関心があることを要求クライアント４０＿１２６の代わりに登録することができる。例えば、コンテキストデーモン４０＿１０２は、述語に関連付けられるデバイス状態の変化の関心を登録するときに、クライアント識別子４０＿７０４を起動デーモン４０＿７０２に提供することができる。例えば、要求クライアント４０＿１２６が位置に基づくコールバック述語を指定する場合、コンテキストデーモン４０＿１０２は、コンピューティングデバイスの位置が変わったときを要求クライアント４０＿１２６に通知するように、起動デーモン４０＿７０２に依頼することができる。起動デーモン４０＿７０２が、位置の変更を示すデバイス状態４０＿１１０４を受信したときに、起動デーモン４０＿７０２は（例えば、クライアント識別子４０＿７０４によって特定された）要求クライアント４０＿１２６に通知しようと試みることができる。図４０－１３Ａの例に続けると、要求クライアント４０＿１２６がコンピューティングデバイス上で稼働していないため、起動デーモン４０＿７０２は、要求クライアント４０＿１２６が稼働していないと判定して、要求クライアント４０＿１２６を起動（例えば、再起動、開始、呼び出し、実行など）することができる。要求クライアント４０＿１２６が再起動されると、要求クライアント４０＿１２６は、図４０－９Ｂを参照して上述したように、コンテキストデーモン４０＿１０２にメッセージを送信することで、起動デーモン４０＿７０２にコンテキストデーモン４０＿１０２を再起動させることができる。
今後のイベントを予測する

一部の実装では、コンテキストデーモン４０＿１０２は、イベントストリーム情報に基づいて今後のイベントを予測することができる。例えば、コンテキストデーモン４０＿１０２は過去コンテキスト情報（例えば、イベントストリーム、イベントストリームオブジェクトなど）を分析してユーザの過去の行動パターンを判定することができる。コンテキストデーモン４０＿１０２は、これらの過去の行動パターンに基づいて、今後のユーザの行動を予測することができる。例えば、予測可能なユーザの行動としては、睡眠パターン、勤務パターン、運動パターン、食事パターン、及び他の繰り返されるユーザの行動を挙げることができる。コンテキストデーモン４０＿１０２は、これらのユーザの行動がいつ起きるかを、これらのユーザアクティビティ中にどのようにユーザがコンピューティングデバイスと相互作用するかを反映したイベントストリーム内の手がかりに基づいて、判定することができる。

説明を容易にするために、以下の記載は、デバイスの過去のロック状態イベントストリームデータに基づく、例示的な睡眠予測実装を説明する。しかしながら、睡眠予測のために用いられる機構を用いて、他のイベントストリームデータを分析することにより、他のユーザの行動を予測することができる。例えば、コンテキストデーモン４０＿１０２は、位置データを用いて、ユーザの勤務パターンを推論することができる。コンテキストデーモン４０＿１０２は、加速度計データを用いてユーザの運動パターンを推論することができる。コンテキストデーモン４０＿１０２は、アプリケーションデータ（例えば、ソーシャルメディアソフトウェアアプリケーション上でレストランにチェックインすること）を用いて、食事パターンを推論することができる。

一部の実装では、コンテキストデーモン４０＿１０２は、デバイスロック状態イベントストリームデータを用いて、ユーザの睡眠パターンを判定及び／又は予測することができる。例えば、コンピューティングデバイス（例えば、ハンドヘルドデバイス、スマートフォンなど）が長時間（例えば、５時間以上）ロックされたままであると、コンテキストデーモン４０＿１０２はユーザが寝ていると推論することができる。一部の実装では、他のイベントストリーム情報（例えば、加速度計データ、アプリケーション使用データなど）を用いて、睡眠パターン及び／又は睡眠予測を確認することができる。一部の実装では、コンテキストデーモン４０＿１０２は現在の日についての睡眠予測を、ユーザが前の日の睡眠から目覚めた後かつ次の予測される睡眠期間前のどこかの時間で実行することができる。例えば、コンテキストデーモン４０＿１０２は次の睡眠期間を予測するための計算を、ユーザが現在の睡眠期間から目覚めたことを検出したときに実行することができる。例えば、コンテキストデーモン４０＿１０２は、「ロック状態（locked）」コンテキストアイテムについての現在の値が偽である（例えば、ユーザがデバイスをロック解除している）、かつ現在時刻が予測睡眠期間の終了後であると判定することで、ユーザが起きていると検出することができる。
今後のイベントのスロットワイズ（slot-wise）予測

一部の実装では、コンテキストデーモン４０＿１０２は、今後のイベントを予測するためにスロットワイズの平均化を実行することができる。例えば、ユーザの睡眠パターンを予測又は判定するために、上記のようにコンテキストデーモン４０＿１０２はロック状態イベントストリームを分析することができる。コンテキストデーモン４０＿１０２は、ロック状態イベントストリームを以前の２８日にわたって連続する２４時間期間に分割することによって、ロック状態イベントストリームを分析することができる。コンテキストデーモン４０＿１０２は各２４時間期間を、９６個の１５分間の分単位スロットに分割することができる。コンテキストデーモン４０＿１０２は、２４時間期間のそれぞれについて１５分間の分単位ブロックについてのロック状態を判定することができる。例えば、コンピューティングデバイスが１５分間の分単位スロット全体でロックされたままとなると、そのスロットのロック状態は真（例えば、１）となり得る。コンピューティングデバイスが１５分間の分単位スロット中にロック解除された場合、スロットのロック状態は偽（例えば、０）となり得る。２４時間期間内のそれぞれの１５分間の分単位スロットについてのロック状態データを組み合わせて、以前の２８日のそれぞれを表す２８のデータベクトルを生成することができる。例えば、各ベクトル（例えば、長さは９６である）は、１日のうちの１５分間の分単位スロットのそれぞれに対応する９６のロック状態値を含むことができる。コンテキストデーモン４０＿１０２は次に、２８日期間にわたって１５分間の分単位スロットそれぞれを平均化して、ユーザの過去睡眠パターンを判定することができる。

図４０－１４は、今後のイベントを予測するためのスロットワイズ平均化の例を示すグラフ４０＿１４００である。例えば、グラフ４０＿１４００は、デバイスロック状態を用いて睡眠パターンを判定して今後の睡眠期間を予測することを示す。例えば、それぞれの水平の線は、２４時間期間についてのロック状態データベクトルを表す。２４時間期間はｔ－ｎ～ｔ＋ｎの範囲にあることができ、「ｔ」はユーザの睡眠サイクルのほぼ（例えば、推定される、典型的な、計算されたなど）中間に相当するある時間であり、「ｎ」は１２であり得る。例えば、典型的な人が午後１０時から午前６時まで寝る場合、「ｔ」は午前２時となり得る。グラフ４０＿１４００では、「Ｃ」は現在の日を表す。よって、Ｃ－１は昨日、Ｃ－２は一昨日、Ｃ－７は１週間前、及びＣ－２８は４週間前になる。それぞれの日には、９６の対応する１５分間の分単位スロットがある。例えば、グラフ４０＿１４００は、午前３時３０分～３時４５分、午前５時～５時１５分、及び午前６時１５分～６時３０分に対応する１５分間の分単位スロットを示す。グラフ４０＿１４００上では、グラフ４０＿１４００上の乱雑さを減らすために３つの１５分間の分単位スロットしか示していないが、各ベクトルには９６の１５分間の分単位スロットがあり、グラフ４０＿１４００上の３つの１５分間の分単位スロットを参照して説明される動作は、２４時間期間のそれぞれにて、９６のスロットのそれぞれについて実行される。

グラフ４０＿１４００上のベクトルＣ－１を参照すると、３時３０分のスロット及び５時のスロットにおける１という値（例えば、１、真）は、コンピューティングデバイスが、対応する１５分間の分単位スロット全体にわたってロックされたままであったことを示す。６時１５分のスロット中のゼロという値（例えば、０、偽）は、コンピューティングデバイスが１５分間の分単位期間中のどこかでロック解除されたことを示す。例えば、コンテキストデーモン４０＿１０２は、ユーザが６時１５分のスロットでは起きていてコンピューティングデバイスをロック解除したのであろうと推論することができる。以下により詳しく説明するように、コンテキストデーモン４０＿１０２は、閾値時間期間（例えば、５時間）にわたってデバイスがロックされていたときに、ユーザが寝ていたと推論することができる。

現在の日においてユーザが各１５分間の分単位スロットでコンピューティングデバイスをロックしたままにする（及び、よって寝たままとなる）確率を判定するために、コンテキストデーモン４０＿１０２は各１５分間の分単位スロットの値を過去２８日にわたって平均化して、現在の２４時間期間における１５分間の分単位スロットのそれぞれについて値を予測することができる。コンテキストデーモン４０＿１０２は、現在の２４時間期間について計算された１５分間の分単位スロットの平均を用いて、デバイスがロックされたままである可能性が高い、睡眠閾値（例えば、５時間）を超える現在の２４時間期間内の時間期間を特定することができる。例えば、１５分間の分単位スロットの平均値が何らかの閾値（例えば、０．５、５０％など）を超えるところでは、コンテキストデーモン４０＿１０２は、コンピューティングデバイスがその１５分間の分単位スロット内ではロックされたままとなると判定することができる。コンテキストデーモン４０＿１０２は、組み合わされると睡眠閾値時間を超える、閾値よりも大きい値の連続する（又はほぼ連続する）一連の１５分間の分単位スロットを判定することができる。一連の１５分間の分単位スロットが判定されると、コンテキストデーモン４０＿１０２は一連の１５分間の分単位スロットによってカバーされる時間期間を予測された睡眠期間として特定することができる。

一部の実装では、コンテキストデーモン４０＿１０２はロック状態データベクトルにわたって、加重平均化を実行することができる。例えば、それぞれのベクトルは、より古いロック状態データが、より新しいロック状態データよりも平均に影響を与えないように加重することができる。一部の実装では、コンテキストデーモン４０＿１０２は一連の最近の日にわたる（例えば、過去７日間それぞれにわたる）短期間での平均化、及び／又は一連の週にわたる（例えば、７日前、１４日前、２１日前、２８日前）長期間での平均化を実行することができる。例えば、短期間での平均化は日々のパターンを予測するのにより良い場合がある一方で、ユーザが特定の曜日で何をするかを予測するためには長期間での平均化がより良い場合がある。例えば、今日が土曜日である場合、今日のユーザの行動についてのプレディクタとしては、特にユーザが月曜日から金曜日まで働いている場合に、昨日のユーザのアクティビティよりも前の土曜日のユーザのアクティビティの方が良いであろう。
短期間での平均化

一部の実装では、コンテキストデーモン４０＿１０２が以下の短期間加重平均化アルゴリズムを用いて、デバイスが１５分間の分単位スロット内でロックされたままとなる確率（ＰＳ）を判定することができる。

（式中、Ｖ１はＣ－１に相当し、Ｖ２はＣ－２に相当し、などであり、Ｖ７はＣ－７に相当し、λは０から１の間の値を有する実験によって決定された重みである）。例えば、短期間での加重アルゴリズムを用いて、過去７日間にわたっての１５分間の分単位スロットそれぞれの加重平均を計算することができる。
長期間での平均化

一部の実装では、コンテキストデーモン４０＿１０２が以下の長期間加重平均化アルゴリズムを用いて、デバイスが１５分間の分単位スロット内でロックされたままとなる確率（ＰＬ）を判定することができる。

（式中、Ｖ７はＣ－７に相当し、Ｖ１４はＣ－１４に相当し、Ｖ２１はＣ－２１に相当し、Ｖ２８はＣ－２８に相当し、「λ」は０から１の間の値を有する実験によって決定された重みである）。例えば、長期間での加重アルゴリズムを用いて、過去４週間にわたる同じ曜日についての１５分間の分単位スロットそれぞれの加重平均を計算することができる。

一部の実装では、短期間での加重平均アルゴリズムと長期間での加重平均アルゴリズムとを組み合わせて、１５分間の分単位スロット内で１５分間の分単位スロットがロックされたままとなる組み合わされた（例えば、複合的、全体的など）の確率（Ｐ）を生成することができる。

（式中、「ｒ」は長期間加重平均が確率計算に与える影響を調節するために用いることができる実験によって決められた数字（例えば、０．５）である）。
比例スロット値

図４０－１５は、比例スロット値を計算することを示す、例示的なグラフ４０＿１５００及び４０＿１５５０を示す。例えば、２４時間期間Ｃ－ｎ内での１５分間の分単位スロットそれぞれに真（１）及び偽（０）の値を割り当てるのではなく、上記の説明にあるように、コンテキストデーモン４０＿１０２は、１５分間の分単位スロットそれぞれのうちのどれくらいの間でコンピューティングデバイスがロックされていた、又はロック解除されていたかを判定し、そのスロットの間でデバイスがロックされている比例的な時間量を表す比例値をスロットに割り当てることができる。

グラフ４０＿１５００を参照すると、それぞれの１５分間の分単位タイムスロットの影領域は、タイムスロット内のデバイスがロックされていた時間を表すことができる。例えば、デバイスは、午前３時３０分～３時４５分と午前５時～５時１５分とのタイムスロットの両方で、その全体にわたってロックされていた。よって、３時３０分及び５時のタイムスロットは１という値（１）を割り当てることができる。しかしながら、コンピューティングデバイスは午前６時１５分～６時３０分のタイムスロットでは一部でしかロックされていなかった。コンピューティングデバイスが６時１５分のタイムスロットの最初の１０分のみについてロックされていたのであれば、６時１５分のタイムスロットには、グラフ４０＿１５５０で示すように、１５分間の分単位スロットのデバイスがロックされていた比例量を表す１０／１５又は０．６７という値が割り当てられ得る。コンピューティングデバイスが繰り返し、ロックされたりロック解除されたりした場合（例えば、５分間ロックされ、２分間ロック解除され、１分間ロックされ、５分間ロック解除され、など）、コンピューティングデバイスはロックされていた時間期間を合計し、ロック解除されていた時間を合計し、１５分間の分単位スロットのコンピューティングデバイスがロックされていた割合を計算することができる。一部の実装では、比例値は、２４時間期間内の１５分間の分単位スロット（例えば、データベクトル）それぞれについて、比例値を決定することができる。一部の実装では、１５分間の分単位スロットそれぞれについての比例値は、上記の短期及び／又は長期の確率を計算するときに用いることができる。
睡眠曲線の生成

図４０－１６Ａは、今後のコンテキストを予測するための例示的な方法を示すグラフ４０＿１６００である。例えば、グラフ４０＿１６００によって示す方法を用いて、コンピューティングデバイスのユーザについて、今後の睡眠期間を予測することができる。例えば、グラフ４０＿１６００におけるそれぞれの棒（例えば、棒４０＿１６０２、棒４０＿１６０６）は、上述したように、１５分間の分単位タイムスロットを表すことができる。それぞれの１５分間の分単位タイムスロットの値は棒の高さによって表すことができ、上述したように、タイムスロットについての組み合わされた加重平均確率（Ｐ）に対応することができる。例えば、確率（Ｐ）はゼロ（例えば、０、０％）から１（例えば、１、１００％）の範囲であることができる。確率は、例えば、上述したように、コンピューティングデバイスが、その１５分間の分単位スロット中にロックされたままとなる確率を表すことができる。確率は、バイナリー（例えば、０、１）の１５分間の分単位タイムスロットの値に基づいて計算することができる。確率は、比例的な１５分間の分単位タイムスロット値に基づいて計算することができる。

一部の実装では、コンテキストデーモン４０＿１０２は、確率グラフ４０＿１６００を、コンピューティングデバイスのユーザの睡眠サイクルを表す確率曲線に変換することができる。例えば、コンテキストデーモン４０＿１０２は、どの１５分間の分単位スロットがユーザの睡眠期間と対応するかを判定するために、睡眠確率閾値４０＿１６０６を決定することができる。一部の実装では、睡眠確率閾値４０＿１６０６は動的に判定することができる。例えば、最小の睡眠期間（例えば、５時間、７時間など）が所与の場合、コンテキストデーモン４０＿１０２は、少なくとも最小の睡眠期間の長さでありが、かつ睡眠確率閾値４０＿１６０６を超過する（例えば、確率、平均）値を有する１５分間の分単位スロットを含む連続する１５分間の分単位スロットのブロックをもたらす、睡眠確率閾値４０＿１６０６の値（例えば、０．６５、５０％など）を決定することができる。言い換えると、コンテキストデーモン４０＿１０２は、一連の１５分間の分単位スロットが、組み合わされたときに最小睡眠期間を満たすかそれを超え、かつ睡眠確率閾値よりも高い値を有するまで、睡眠確率閾値４０＿１６０６を上下に調整することができる。

一部の実装では、睡眠確率閾値４０＿１６０６が決定されると、コンテキストデーモン４０＿１０２は、連続する１５分間の分単位スロットに基づいてユーザの睡眠期間４０＿１６０８を決定することができる。例えば、睡眠期間４０＿１６０８は、それら連続する１５分間の分単位スロットによってカバーされる時間期間に対応することができる。図４０－１６Ａを参照すると、睡眠期間は、午後１１時に始まり午前７時に終わる時間期間に対応することができる。

図４０－１６Ｂは、スロットワイズの確率を確率曲線に変換するための例示的な方法を示すグラフ４０＿１６５０である。例えば、ユーザの睡眠サイクルの一貫した予測を可能とするために、ユーザが眠りに落ちると単調に上昇し（例えば、デバイスがロックされたままとなる確率が上がる）、ユーザが目覚めると単調に下がる（例えば、デバイスがロックされたままとなる確率が下がる）確率曲線（例えば、鐘形曲線に類似する）を生成することが有用であり得る。

一部の実装では、確率曲線４０＿１６５２を生成するために、コンテキストデーモン４０＿１０２は上記にて決定された睡眠確率閾値を用いて、１５分間の分単位タイムスロットそれぞれについて計算された確率（例えば、平均）をバイナリー（例えば、１又は０）値に変換することができる。例えば、睡眠期間内の（例えば、睡眠閾値４０＿１６０６を超える）１５分間の分単位タイムスロットには１という値（１）を割り当てることができ、睡眠期間の外の１５分間の分単位タイムスロットにはゼロ（０）の値を割り当てることができる。バイナリー値が１５分間の分単位タイムスロットのそれぞれに割り当てられると、コンテキストデーモン４０＿１０２はバイナリー値に曲線（例えば、確率曲線４０＿１６５２）を適合させることができる。生成されると、コンテキストデーモン４０＿１０２は確率曲線４０＿１６５２を用いて、特定の時刻及び／又は一日の間の特定の時間期間にユーザが寝ている確率を予想することができる。例えば、コンテキストデーモン４０＿１０２は、確率曲線４０＿１６５２を用いて、ユーザが今後いつ寝ている可能性が高いかを予測することができる。図４０－１６Ｂを参照すると、グラフ４０＿１６５０で表される計算された睡眠期間が午後１１時～午前７時の間にあるため、コンテキストデーモン４０＿１０２は、ユーザが今後、午後１１時～午前７時の間は寝ているであろうと予測することができる。例えば、睡眠予測が日常的に（例えば、ユーザが朝に目覚めた後に）行われるのであれば、コンテキストデーモン４０＿１０２は現在の日の後ほどに午後１１時～午前７時の間でユーザが寝るであろうと予測することができる。
不規則部分を扱う－外れ値データと欠落データ

一部の実装では、コンテキストデーモン４０＿１０２は、過去イベントストリームデータ内の外れ値データを扱うように構成することができる。一部の実装では、コンテキストデーモン４０＿１０２は、そうでなければ睡眠期間に対応する時間ブロック内の外れ値の１５分間の分単位スロットを扱うように構成することができる。例えば、睡眠期間についての候補であり得る時間ブロック（例えば、睡眠閾値を超える値を有し、組み合わされると最小の睡眠期間を超過する、連続する１５分間の分単位スロットのブロック）には、睡眠閾値を超えない１５分間の分単位スロットを含んでいることがある。例えば、最小睡眠期間が５時間であれば、睡眠期間内には少なくとも２０の１５分間の分単位スロットがある。２０の１５分間の分単位スロットがある時、睡眠閾値を超えるものが１０スロットあり、その後に睡眠閾値を超えない（例えば、外れ値の）スロットが１つあり、その後に睡眠閾値を超えるスロットが９つあってもよい。このシナリオの例は図４０－１６Ａを参照してみることができ、ここでは、外れ値のスロット４０＿１６０８は睡眠閾値４０＿１６０６を超えず、睡眠閾値４０＿１６０６を超えるスロット（例えば、４０＿１６０４）で囲まれている。睡眠閾値を超える１５分間の分単位スロットのブロック内に少数（例えば、１、２）の外れ値の１５分間の分単位スロットがあるとき、上述したように、コンテキストデーモン４０＿１０２は、睡眠期間（例えば、睡眠曲線）を生成できるように、外れ値の１５分間の分単位スロットを睡眠閾値を超えているかのように扱うことができる。例えば、睡眠期間に対応する連続する１５分間の分単位スロットのブロックを判定するとき、コンテキストデーモン４０＿１０２は外れ値の１５分間の分単位スロットを無視することができる。１５分間の分単位スロットをバイナリー値に変換して確率曲線を生成するとき（図４０－１６Ｂにあるように）、コンテキストデーモン４０＿１０２は外れ値の１５分間の分単位スロットに１という値を割り当て、確率曲線が生成できるようにすることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、睡眠期間を予測するときに過去イベントストリーム内で外れ値の日（例えば、２４時間期間、過去データベクトルなど）を扱うように構成することができる。例えば、短期平均を計算する前に、コンテキストデーモン４０＿１０２は、過去７日間のロック状態イベントデータ（例えば、過去コンテキストデータ）を比較することができる。例えば、コンテキストデーモン４０＿１０２は、過去の７つの２４時間期間のそれぞれについて、過去データベクトルの類似分析を実行することができる。７日間のうちの１つ（例えば、外れ値の日）のデータが他の６日間と完全に異なるようであれば、コンテキストデーモン４０＿１０２は外れ値の日を短期平均計算から外すことができる。例えば、１５分間の分単位スロットについての過去のデバイスロック状態データにおける小さな日々の変動は、正常であり得る。しかしながら、ロックデータ（例えば、ユーザ睡眠期間に対応する）の大きなブロックでのずれは異常である。コンテキストデーモン４０＿１０２は、過去データ内の日々のパターンを比較し、ある１日について観察された使用パターン（例えば、ユーザの行動）がその週の他の日について観察される使用パターンに対応しないことを検出することにより、外れ値の日を検出することができる。例えば、コンテキストデーモン４０＿１０２は、外れ値の日における１５分間の分単位スロットのブロック（２４時間期間）が、１５分間の分単位スロットの同一ブロックが他の日では通常ロックされているときに、ロック解除されていると判定することができる。一度外れ値の日が検出されると、コンテキストデーモン４０＿１０２は上記の短期平均化計算から外れ値の日を外すことができる。

同様に、長期平均を計算する前に、コンテキストデーモン４０＿１０２はロック状態イベントデータ（例えば、過去コンテキストデータ）を、例えば、過去４週間について、同じ曜日について比較することができる。複数の日のうちの１日のデータが他の４日と著しく異なるようであれば（例えば、外れ値の日）、コンテキストデーモン４０＿１０２は外れ値の日を長期平均計算から外すことができる。例えば、１５分間の分単位スロットについての過去デバイスロック状態データにおける週毎の変動は通常であり得る。しかしながら、ロックデータ（例えば、ユーザ睡眠期間に対応する）の大きなブロックでのずれは異常である。コンテキストデーモン４０＿１０２は、過去データ内の週毎のパターンを比較し、ある日について観察された使用パターン（例えば、ユーザの行動）が過去の週の同じ曜日について観察された使用パターンに対応しないことを検出することで、外れ値の日を検出することができる。外れ値の日が検出されると、コンテキストデーモン４０＿１０２は上記の長期平均化計算から外れ値の日を外すことができる。

一部の実装では、コンテキストデーモン４０＿１０２は、ユーザの行動パターンのずれに基づいて外れ値の日を検出することができる。例えば、ユーザが通常午後１１時～午前７時まで寝る場合、過去のロックイベントデータは、デバイスが午後１１時～午前７時の間は（ほぼ）ロックされたままとなっていたことを示す。しかしながら、珍しい日にはユーザが一晩中、勉強又は仕事で起きているかもしれず、よって、その日の睡眠期間は別の時間期間（例えば、午前６時～午後０時）にずれる可能性がある。一部の実装では、コンテキストデーモン４０＿１０２はこの睡眠パターンのずれを過去のロック状態データに基づいて検出して、平均化計算からこの日を外すことができる。

一部の実装では、コンテキストデーモン４０＿１０２は、既知又は一般的に受け入れられる人の行動における制限に基づいて外れ値の日を検出することができる。例えば、ユーザが週末に旅行に行って、コンピューティングデバイス（例えば、スマートフォン）を誤って、週末中ずっと、自宅に置きっぱなしにするかもしれない。この場合、デバイスは週末中ずっと（例えば、２日間）ロックされたままとなり、コンテキストデーモン４０＿１０２によって睡眠期間として間違って解釈され得るロック状態データのブロックが生成されてしまう。コンテキストデーモン４０＿１０２は、ロック状態データのブロックに対応する時間期間（例えば、睡眠期間）を最大睡眠期間（例えば、１２時間、２４時間など）と比べることによって、この状況を検出することができる。例えば、最大睡眠期間は常識（例えば、人は通常、２４時間を越えて寝ない）に基づいてもよく、又は観察データ（例えば、ユーザについて観察された最大の睡眠期間は１０時間である）に基づくことができる。時間のブロックが最大睡眠期間を超過した場合、コンテキストデーモン４０＿１０２は、上記の長期及び／又は短期計算を実行するときに、この時間のブロックに対応する日又は複数の日を無視することができる。

一部の実装では、コンテキストデーモン４０＿１０２は、過去イベントストリーム内の欠落データを扱うように構成することができる。例えば、ユーザがコンピューティングデバイスをある期間にわたって電源を落とすことがある、又はデバイスは、長期間外部電源からプラグを抜かれた後にバッテリ電力を失うことがある。デバイスの電源が落ちている間、デバイスはコンテキスト情報を収集することができず、過去イベントストリームを生成することができない。再びコンピューティングデバイスの電源がオンされると、コンテキストデーモン４０＿１０２は、デバイスの電源が落とされたときの期間に対応する欠落データに基づいて今後のイベント（例えば、今後の睡眠期間）を予測しようとしてもよい。この場合、コンテキストデーモン４０＿１０２はこの期間についてイベント（例えば、コンテキストアイテム）データ値が存在しないと判定して、上記の短期及び／又は長期平均化計算を実行する時にこの期間に対応する日又は複数の日（例えば、過去データベクトル）を無視する（例えば、省く）ことができる。
予測されるイベントに基づくアクティビティのスケジューリング

図４０－１７は、予測された今後のイベントを含む例示的なイベントストリーム４０＿１７００を示す。例えば、上記の機構を用いて、コンテキストデーモン４０＿１０２は今後の睡眠期間４０＿１７０２を予測することができる。一部の実装では、予測された今後のイベントを用いて、コンピューティングデバイス内のアクティビティ（例えば、コンテキストコールバック）をスケジューリングすることができる。図４０－１を参照すると、要求クライアント４０＿１２６は、予測されるイベントの前にコールバック通知を要求することができる。例えば、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６にユーザが眠りに落ちる３０分前に通知すべきであると指定する述語を含むコールバック要求を、コンテキストデーモン４０＿１０２に送ることができる。コールバック要求が受信されたときに、コンテキストデーモン４０＿１０２は、予測される睡眠期間が始まる３０分前に通知することをスケジューリングすることができる。同様に、要求クライアントは、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６にユーザが眠りに落ちた１時間後に通知すべきであると指定する述語を含むコールバック要求を、コンテキストデーモン４０＿１０２に送ることができる。コールバック要求が受信されたときに、コンテキストデーモン４０＿１０２は、予測される睡眠期間が始まった１時間後に通知することをスケジューリングすることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、イベントの予測される時間での現在のコンテキストに基づいて、今後のイベントの予測を確認することができる。例えば、要求クライアント４０＿１２６が、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６に予測睡眠期間が始まった３０分後に通知するように要求する場合、コンテキストデーモン４０＿１０２は、現在のコンテキスト４０＿１１２（例えば、コンテキストアイテム値）を分析してデバイスがロックされているかどうかを判定することにより、ユーザがその時間に実際に寝ていることを確認することができる。予測睡眠期間が始まってから３０分後にデバイスがロック解除されている場合（例えば、ユーザが寝ていない）、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６に通知しない。一部の実装では、他のコンテキスト情報を用いて予測睡眠期間を確認することができる。例えば、加速度計状態を、睡眠期間を確認するために用いることができる。例えば、ほとんどのスマートフォンユーザが、寝る時にスマートフォンをテーブルの上か床の上に置くであろう。テーブル及び床は、通常動かないものである。よって、スマートフォンは加速度計データを、生成したとしても、ほとんど生成しない。もしスマートフォンが加速度計データを生成しているのであれば、スマートフォンはおそらく、ユーザが動いている間、ユーザのポケットの中にある可能性が高い。よって、加速度計データは、予測睡眠期間中にユーザが動いていて寝ていないことを示すことができる。

一部の実装では、コンテキストデーモン４０＿１０２は、前触れ（precursor）イベントを識別することで、今後のイベントの予測を改善することができる。例えば、コンテキストデーモン４０＿１０２は過去イベントストリームデータを分析して、ユーザアクティビティと予測されるイベントとの間の関係性を特定することができる。例えば、ユーザは、電子メールアプリケーション、ソーシャルネットワーキングアプリケーション、ニュースアプリケーション、又は別のアプリケーションを、寝る前に確認する習性があるかもしれない。コンテキストデーモン４０＿１０２はこれらのパターン（例えば、アラーム時計アプリケーションを用いてから寝る）を検出して、前触れのアプリケーション又は複数のアプリケーションを特定する（例えば、時計アプリケーション、ニュースアプリケーションなど）。前触れアプリケーション（又は複数のアプリケーション）が特定されると、コンテキストデーモン４０＿１０２は前触れアプリケーションを用いて、ユーザが間もなく寝ることを予測することができる。例えば、コンテキストデーモン４０＿１０２は、過去イベントデータに基づいて、ユーザがアラーム時計アプリケーションを用いた１０分後に典型的に眠りに落ちると判定することができる。コンテキストデーモン４０＿１０２が、ユーザが午後１１時に寝ると予測していて、ユーザがアラーム時計アプリケーションを午後１０時に使用している場合、コンテキストデーモン４０＿１０２は、前触れのアラーム時計アプリケーションアクティビティに基づいて予測睡眠期間の開始を午後１１時から午後１０時１０分に調節することができる。一部の実装では、コンテキストデーモン４０＿１０２は、予測睡眠期間の開始と終了時間を、予測睡眠期間の持続時間を調節することなく、調節することができる。一部の実装では、コンテキストデーモン４０＿１０２は、終了時間は調節せずに予測睡眠時間の開始時間を調節することで、予測睡眠期間の開始時間を調節することができ、よって、予測睡眠期間の持続時間が延長される。あるいは、ユーザが前触れアプリケーションを使用しているとコンテキストデーモン４０＿１０２が検出した（例えば、現在のコンテキストが、フォーカスアプリケーションがその前触れアプリケーションであると示す）とき、コンテキストデーモン４０＿１０２はユーザのアクティビティを監視して、ユーザがいつコンピューティングデバイスをロックして、デバイスがロックされてから現在の睡眠期間を開始するかを判定することができる。
他の使用事例

一部の実装では、コンピューティングデバイスにて稼働するコンテキストクライアントは、上記の睡眠予測を用いて、ユーザが寝ている間の背景タスクをスケジューリングすることができる。例えば、オペレーションシステムプロセス（例えば、アプリケーション更新部）は、システムメンテナンスにシステムリソースを充てることでユーザにとって不便とならないよう、ユーザが寝ている間にいくらかのシステムメンテナンスタスク（例えば、アプリケーション更新のダウンロード及び／又はインストール）をスケジューリングする必要がある場合がある。コンテキストデーモン４０＿１０２は、以下に更に説明するように、様々なデバイス構成要素（例えば、ハードウェア、ソフトウェアなど）の状態を分析して、スケジューリングされるアクティビティが何らかのユーザアクティビティと干渉する可能性があるかを判定することができる。

一部の場合では、オペレーティングシステムプロセスは、システムメンテナンスタスクを行う前にユーザのパスコード（例えば、パスワード）を必要とする可能性がある。ユーザが寝ている間はユーザがパスコートを提供することができないため、オペレーティングシステムプロセスは、ユーザの予測睡眠期間前のどこか（例えば、４０＿１０分）でコンテキストデーモン４０＿１０２からのコールバック通知を要求することができる。コールバック要求を受信すると、コンテキストデーモン４０＿１０２は、予測された睡眠期間が始まる１０分前にコールバック通知をスケジューリングすることができる。スケジューリングされた時間になる（例えば、現在時刻が予定時刻と一致する）と、コンテキストデーモン４０＿１０２はコールバック通知をオペレーティングシステムプロセスに送ることができる。オペレーティングシステムプロセスがコールバック通知を受信すると、オペレーティングシステムプロセスは、ユーザが寝ている間にオペレーティングシステムがメンテナンスタスクを実行できるように、ユーザにユーザのパスコードを入力するように促すことができる。例えば、オペレーティングシステムプロセスはユーザからパスコードを受信して、システムメンテナンスタスクを実行中にパスコードを使うために記憶することができる。システムメンテナンスタスクが完了し、パスコードがもう必要でなくなると、オペレーティングシステムはユーザのパスコードをコンピューティングデバイスから削除することができる。

ユーザが寝ている間にメンテナンスタスクを開始するために、オペレーティングシステムプロセスは、予測睡眠期間が始まったいくらか後の時間（例えば、３０分）にコールバック通知を要求することができる。コールバック要求を受信すると、コンテキストデーモン４０＿１０２は、予測睡眠期間が始まった４５分後に対するコールバック通知を、スケジューリングすることができる。スケジューリングされた時刻になったとき（例えば、現在時刻がスケジューリングされた時刻と等しい）、コンテキストデーモン４０＿１０２は、ユーザが、コールバック通知をオペレーティングシステムに送る前にコンピューティングデバイスを使用しておらず、かつ／又は使用しようとしていないことを確かめることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、ユーザがコンピューティングデバイスを使用していないことを、コンピューティングデバイスがユーザによって始められたアクティビティにサービスしているかどうかで判定することができる。例えば、コンピューティングデバイスがロックされていても（例えば、ユーザが寝ている可能性があることを示す）、コンピューティングデバイスはユーザのナビゲーション要求にサービスするナビゲーション関連のアクティビティを実行することができる。よって、コンテキストデーモン４０＿１０２が、コンピューティングデバイスのナビゲーション構成要素（例えば、グローバルナビゲーション衛生システム受信機）がオンになっていると判定したときに、コンテキストデーモン４０＿１０２はユーザがコンピューティングデバイスを使用していると判定して、予測睡眠期間中にオペレーションシステムプロセスへのコールバック通知を送信するのをキャンセル又は遅延させることができる。同様に、コンテキストデーモン４０＿１０２が、コンピューティングデバイスが、個人的なホットスポットサービスを提供している、ユーザ要求に応じて別のユーザデバイスとデータを同期させている（例えば、自動バックグラウンド同期と対照的に）、又はコールバック通知がスケジューリングされている時間に他のユーザが開始したサービスを何かしら提供していると判定すると、コンテキストデーモン４０＿１０２は、デバイスはロックされているにも関わらずユーザがまだコンピューティングデバイスを使用しているために、オペレーションシステムプロセスへのコールバック通知の送信を取り消す又は遅延させることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、ユーザがコンピューティングデバイスを使用しようとしていないことを、コンピューティングデバイスがユーザから見えるアクティビティを開始しようとしているか否かで確かめることができる。例えば、コンピューティングデバイス上で稼働する様々なプロセスが、ユーザに通知する又はユーザの注意を引くことができる。通信アプリケーション（例えば、インスタントメッセージング、テキストメッセージング、電子メール、電話など）は、受信したメッセージについてユーザに思い出させることができる。例えば、通信アプリケーションは、メッセージが受信された１０分後に、ユーザに対して受信メッセージを読む又はそれに返信するように思い出させるように構成することができる。時計アプリケーションは、どこかの今後の時間でユーザに通知する（例えば、起こす）ように構成されるアラーム時計機能を含むことができる。カレンダーアプリケーションは、今後にスケジューリングされているカレンダーイベントについて、ユーザに思い出させるように構成することができる。もしユーザが会議に出席するようにスケジューリングされているのであれば、ナビゲーションアプリケーションは、ユーザの現在地から会議場所まで移動するのにどれくらいの時間が掛かるかに基づいて、ユーザに出発時刻リマインダを提示することができる。運動アプリケーションは、ユーザに立ち上がる、歩き回る、ランニングしに行く、又は他の種類の運動をするように思い出させるよう、構成することができる。これらの通知、助言、警告などのそれぞれはユーザに向けられており、ユーザにコンピューティングデバイスと相互作用するように促す、又は相互作用させる。コンテキストデーモン４０＿１０２は、これらのユーザに見えるイベントのうちの１つが閾値時間期間内（例えば、１分、１０分、システムメンテナンスタスクを完了させるのに必要な時間など）に発生するかどうかを判定して、ユーザがコンピューティングデバイスを使い始めるところであるためにオペレーティングシステムプロセスへのコールバック通知を送るのを遅延させるか取り消すことができる。
プロセス

図４０－１８は、コンピューティングデバイス上でのコンテキスト変更をクライアントに通知するための例示的なプロセス４０＿１８００のフロー図である。例えば、上記の、システム４０＿１００に対応するコンピューティングデバイスが、プロセス４０＿１８００を実行することができる。

ステップ４０＿１８０２では、コンピューティングデバイスはコンテキストコールバック要求を受信することができる。例えば、コンテキストデーモン４０＿１０２は、上記のように、要求クライアント４０＿１２６からコールバック要求を受信することができる。コールバック要求は、要求クライアント４０＿１２６の識別子と、コンテキストデーモン４０＿１０２が要求クライアント４０＿１２６にコールバック通知を送るべきコンテキスト（例えば、デバイス状態）条件を定義する述語と、を含むことができる。一部の実装では、コールバック要求を受信した後、コンテキストデーモン４０＿１０２は、コールバック要求を特定するためにコンテキストデーモン４０＿１０２及び要求クライアント４０＿１２６が用いることのできるコールバック識別子を生成することができる。例えば、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６からコールバック要求を受信したことに応じて、要求クライアント４０＿１２６にコールバック識別子を返すことができる。コンテキストデーモン４０＿１０２は、例えば、コールバック要求を、コールバックレジストリ４０＿１１４及び／又は述語データベース４０＿１１６に記憶することができる。

ステップ４０＿１８０４では、コンピューティングデバイスはコールバック要求にサービスするためにコンテキストモニタを初期化することができる。例えば、コンテキストデーモン４０＿１０２は、上記のように、コールバック要求述語に指定されたコンテキストアイテムに対応するモニタバンドル４０＿１０６（又は複数のバンドル）をローディングすることができる。

ステップ４０＿１８０６では、コンピューティングデバイスは、コンテキストモニタバンドル４０＿１０６（コンテキストモニタ４０＿１０８）から現在のコンテキスト情報を受信することができる。例えば、コンテキストモニタ４０＿１０８のそれぞれは、様々なシステム構成要素とインタフェースして、システム構成要素の状態を取得することができる。コンテキストモニタ４０＿１０８は次に、状態をコンテキストデーモン４０＿１０２に報告することができる。あるいは、コンテキストデーモン４０＿１０２は報告クライアント４０＿１２４から状態情報を受信することができる。コンテキストデーモン４０＿１０２は、上記のように、受信された状態情報に基づいて現在のコンテキスト４０＿１１２を生成することができる。

ステップ４０＿１８０８では、コンピューティングデバイスは、現在のコンテキストが要求されたコンテキストと一致すると判定することができる。例えば、コンテキストデーモン４０＿１０２はコンテキスト要求述語を現在のコンテキストと比較して、現在のコンテキストが述語に指定された条件を満たすと判定することができる。

ステップ４０＿１８１０では、コンピューティングデバイスは要求クライアント４０＿１２６にコールバック通知を送ることができる。例えば、現在のコンテキストが要求コンテキストと一致すると判定したことに応じて、コンテキストデーモン４０＿１０２は、コールバック要求を特定するコールバック通知を要求クライアント４０＿１２６に送ることができる。要求クライアント４０＿１２６は、コールバック要求識別子を用いて、どのコールバック述語がコールバックをトリガーしたのかを（例えば、コンピューティングデバイスの現在の動作コンテキストを判定するために）判定することができる。要求クライアント４０＿１２６は次に、現在のコンテキストに適切なアクションを実行することができる。

図４０－１９は、コールバック要求にサービスするためにコンテキストデーモンを再起動するための例示的なプロセス４０＿１９００のフロー図である。例えば、コンピューティングデバイス上で稼働しているプロセスは、プロセスマネジャーが、プロセスが一定期間アイドル状態であると判定した時に、オペレーティングシステムのプロセスマネジャーサービスによって終了させられてもよい。プロセスマネジャー（又は何らかの他のプロセス）がコンテキストデーモン４０＿１０２を終了させると、コンピューティングデバイスはプロセス４０＿１９００を実行してコンテキストデーモン４０＿１０２を再起動して、コンテキストデーモン４０＿１０２がコンテキスト情報を収集して要求クライアント４０＿１２６にコールバック通知を送るようにすることができる。例えば、プロセス４０＿１９００は、図７～１３を参照して説明するコンテキストデーモン再起動機構に対応することができる。

ステップ４０＿１９０２では、コンピューティングデバイスは、コンテキストデーモン４０＿１０２と要求クライアント４０＿１２６との間で通信セッションを開始することができる。一部の実装では、要求クライアント４０＿１２６は、コンテキストデーモン４０＿１０２に、上記のように、コールバック要求を送信することにより、コンテキストデーモン４０＿１０２との通信セッションを開始することができる。コールバック要求は、上記のように、クライアント識別子とコールバック述語とを含むことができる。一部の実装では、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６によって開始された通信セッションを用いてでしか、要求クライアント４０＿１２６と通信する（例えばコールバック通知を送る）ことができない。一部の実装では、コンテキストデーモン４０＿１０２は、コールバック要求をコールバックデータベース（例えば、述語データベース４０＿１１６）に記憶させることができる。

ステップ４０＿１９０４では、コンピューティングデバイスはコンテキストデーモン４０＿１０２が非アクティブであると判定することができる。例えば、コンテキストデーモン４０＿１０２がコールバック要求又はコンテキスト情報の更新を一定期間受信しないときに、プロセスマネジャーはコンテキストデーモン４０＿１０２がアイドル状態又は非アクティブであると判定することができる。

ステップ４０＿１９０６では、コンピューティングデバイスはコンテキストデーモン４０＿１０２をシャットダウンすることができる。例えば、コンテキストデーモン４０＿１０２が非アクティブであるという判定に基づいて、プロセスマネジャーは、システムリソース（例えば、バッテリ電力、メモリなど）を節約するために、コンテキストデーモン４０＿１０２をシャットダウン又は終了することができる。コンテキストデーモン４０＿１０２をシャットダウンした後、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間の通信セッションもまた、終了する。

ステップ４０＿１９０８では、コンピューティングデバイスは、コンテキストデーモン４０＿１０２に関連付けられたイベントを検出することができる。例えば、イベントは、コンテキストクライアント（例えば、要求クライアント４０＿１２６、報告クライアント４０＿１２４など）がコンテキストデーモン４０＿１０２にメッセージを送ることであってもよい。例えば、メッセージは、要求クライアント４０＿１２６からのコールバック要求であってもよい。メッセージは、報告クライアント４０＿１２４から受信されたコンテキスト情報更新であってもよい。一部の実装では、イベントは、コンテキストデーモン４０＿１０２が関心があると登録している起動デーモン４０＿７０２によって受信されたデバイス状態更新であり得る。

ステップ４０＿１９１０では、コンピューティングデバイスはコンテキストデーモン４０＿１０２を再起動することができる。例えば、コンテキストクライアントが終了されたコンテキストデーモン４０＿１０２にメッセージを送るときに、コンピューティングデバイスはコンテキストデーモン４０＿１０２を再起動してコンテキストデーモン４０＿１０２がメッセージを受信して扱うことができるようにすることができる。起動デーモン４０＿７０２がコンテキストデーモン４０＿１０２から受信した要求に対応するデバイス状態更新を受信したときに、起動デーモン４０＿７０２はコンテキストデーモン４０＿１０２を再起動することができる。

ステップ４０＿１９１２では、コンピューティングデバイスは登録されたコールバック要求をリストアして、デーモン４０＿１０２をコールバックことができる。例えば、再起動後、コールバックデーモン４０＿１０２は、コールバックデーモン４０＿１０２が終了する前に受信されたコールバック要求をリストアすることができる。例えば、コールバックデーモン４０＿１０２は、以前に受信されたコールバックをコールバックデータベースからリストアすることができる。

ステップ４０＿１９１４では、コンピューティングデバイスはリストアされたコールバック要求にサービスするために必要なイベントモニタを初期化することができる。例えば、コンテキストデーモン４０＿１０２は、コールバック要求にサービスするのに必要なコンテキスト情報を収集するのに必要なモニタバンドル４０＿１０６をローディングすることができる。

ステップ４０＿１９１６では、コンピューティングデバイスは、コンテキストデーモン４０＿１０２と要求クライアント４０＿１２６との間での通信セッションを再確立することができる。例えば、コンテキストデーモン４０＿１０２が再度稼働すると、要求クライアント４０＿１２６はコンテキストデーモン４０＿１０２にメッセージ（例えば、コールバック要求）を送って、通信セッションを再確立することができる。コンテキストデーモン４０＿１０２は、再確立された通信セッションを用いて、コールバック要求に指定された述語に従ってクライアントへのコールバック通知を送信することができる。

図４０－２０は、コールバック要求を受信するためにコールバッククライアントを再起動するための例示的なプロセス４０＿２０００のフロー図である。例えば、コンピューティングデバイス上で稼働しているプロセスは、プロセスマネジャーが、プロセスが一定期間アイドル状態であると判定した時に、オペレーティングシステムのプロセスマネジャーサービスによって終了させられてもよい。プロセスマネジャー（又は何らかの他のプロセス）が要求クライアント４０＿１２６を終了させたときに、要求クライアント４０＿１２６がコンテキストデーモン４０＿１０２からコールバック通知を受信できるように、コンピューティングデバイスはプロセス４０＿２０００を実行して要求クライアント４０＿１２６を再起動することができる。例えば、プロセス４０＿２０００は、図７～１３を参照して説明した要求クライアント再起動機構に対応することができる。

ステップ４０＿２００２では、コンピューティングデバイスは、コンテキストデーモン４０＿１０２と要求クライアント４０＿１２６との間での通信セッションを開始することができる。一部の実装では、要求クライアント４０＿１２６はコンテキストデーモン４０＿１０２との通信セッションを、上記のように、コールバック要求をコンテキストデーモン４０＿１０２に送信することによって開始することができる。コールバック要求は、上記のように、クライアント識別子とコールバック述語とを含むことができる。一部の実装では、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６によって開始された通信セッションを用いてでしか、要求クライアント４０＿１２６と通信する（例えばコールバック通知を送る）ことができない。一部の実装では、コンテキストデーモン４０＿１０２は、コールバック要求をコールバックデータベース（例えば、述語データベース４０＿１１６）に記憶させることができる。

ステップ４０＿２００４では、コンピューティングデバイスは要求クライアント４０＿１２６が非アクティブであると判定することができる。例えば、要求クライアント４０＿１２６がコンピューティングデバイス内で著しい処理を実行していない（例えば、要求クライアント４０＿１２６についてのＣＰＵ使用が閾値レベル未満である）ときに、プロセスマネジャーは要求クライアント４０＿１２６がアイドル状態にあるか非アクティブであると判定することができる。

ステップ４０＿２００６では、コンピューティングデバイスは要求クライアント４０＿１２６をシャットダウンすることができる。例えば、要求クライアント４０＿１２６が非アクティブであるという判定に基づいて、プロセスマネジャーは、システムリソース（例えば、バッテリ電力、メモリなど）を節約するために、要求クライアント４０＿１２６をシャットダウン又は終了させることができる。要求クライアント４０＿１２６をシャットダウンした後、要求クライアント４０＿１２６とコンテキストデーモン４０＿１０２との間の通信セッションもまた、終了する。よって、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６にコールバック通知を届ける通信チャネルを有さないことになる。

ステップ４０＿２００８では、コンピューティングデバイスは要求クライアント４０＿１２６に関連付けられたイベントを検出することができる。例えば、コンテキストデーモン４０＿１０２は、コンテキストコールバック述語と一致する（例えば、述語によって指定された条件に対応する）現在のコンテキストを検出することができる。起動デーモン４０＿７０２は、コンテキストデーモン４０＿１０２から受信されコンテキストクライアント４０＿１２６のクライアント識別子に関連付けられたデバイス状態要求に対応するデバイス状態を検出することができる。

ステップ４０＿２０１０では、コンピューティングデバイスは要求クライアント４０＿１２６を再起動することができる。例えば、コンテキストデーモン４０＿１０２が、現在のコンテキストがコンテキストコールバック述語と一致すると検出すると、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６にコールバック通知を送ることを試みることができる。しかしながら、コンテキストデーモン４０＿１０２と要求クライアント４０＿１２６との間の通信セッションが終了されたために、コンテキストデーモン４０＿１０２はコールバック通知を要求クライアント４０＿１２６に送ることができない。よって、要求クライアント４０＿１２６との通信チャネルが終了されていることを検出した後、コンテキストデーモン４０＿１０２は要求クライアント４０＿１２６を再起動する要求の中に、要求クライアント４０＿１２６から受信されたクライアント識別子を入れて起動デーモン４０＿７０２に送ることができる。一部の実装では、起動デーモン４０＿７０２に要求クライアント４０＿１２６を再起動するように要求すると、コンテキストデーモン４０＿１０２は、要求クライアント４０＿１２６のクライアント識別子に関連付けられる全てのコールバック要求データ（例えば、コールバックレジストリ４０＿１１４及び／又は述語データベース４０＿１１６に記憶された）を削除することができる。クライアント識別子を受信すると、起動デーモン４０＿７０２は、要求クライアント４０＿１２６を再起動することができる。あるいは、コンテキストデーモン４０＿１０２から受信されコンテキストクライアント４０＿１２６のクライアント識別子に関連付けられたデバイス状態要求に対応するデバイス状態を検出すると、起動デーモン４０＿７０２は要求クライアント４０＿１２６を再起動することができる。

ステップ４０＿２０１２では、コンピューティングデバイスは、コンテキストデーモン４０＿１０２と要求クライアント４０＿１２６との間での通信セッションを再確立することができる。例えば、再起動後、要求クライアント４０＿１２６は新たなコールバック要求をコンテキストデーモン４０＿１０２に送り、新たな通信セッションを始めることができる。

ステップ４０＿２０１４では、コンピューティングデバイスは再起動された要求クライアント４０＿１２６からクライアントコールバック要求を受信することができる。例えば、コンテキストデーモン４０＿１０２は、ステップ４０＿２００８にて説明したように、現在のコンテキストに対応する同一のコールバック述語を指定する要求クライアント４０＿１２６からのコールバック要求を受信することができる。コールバック要求を受信すると、コンテキストデーモン４０＿１０２はコールバック要求がコンピューティングデバイスの現在のコンテキストに対応すると判定することができる。

ステップ４０＿２０１６では、コンピューティングデバイスは要求クライアント４０＿１２６にコールバック通知を送ることができる。例えば、現在のコンテキストがコールバック要求と一致すると判定すると、コンテキストデーモン４０＿１０２は、再確立された通信チャネルを用いてコールバック通知を要求クライアント４０＿１２６に送ることができる。

図４０－２１は、過去コンテキスト情報に基づいて今後のイベントを予測するための例示的なプロセス４０＿２１００のフロー図である。例えば、プロセス４０＿２１００は、図４０－１４～１７を参照して説明したイベント予測機構に対応することができる。

ステップ４０＿２１０２では、コンピューティングデバイスはコンテキストアイテムについての過去コンテキストデータを取得することができる。例えば、コンテキストデーモン４０＿１０２（例えば、過去モニタ４０＿１１０を用いて）は現在のコンテキスト４０＿１１２におけるそれぞれのコンテキストアイテムについての、経時的なデバイスコンテキスト（例えば、デバイス状態）の変化を示す過去イベントストリームを生成することができる。例えば、過去モニタ４０＿１１０は、上記のように、いつデバイスがロック又はロック解除されていたかを示す「ロック状態」コンテキストアイテムについての過去イベントストリームを生成することができる。

ステップ４０＿２１０４では、コンピューティングデバイスはコンテキストアイテムについての過去コンテキストデータベクトルを生成することができる。例えば、コンテキストデーモン４０＿１０２は、過去２８日にわたって２４時間期間でのコンテキストアイテムについての、過去コンテキストデータを分析することができる。例えば、コンテキストデーモン４０＿１０２は、過去２８の２４時間期間のそれぞれについて、２８のデータベクトルを生成することができる。２８のデータベクトルのそれぞれは、２４時間期間それぞれにおける９６の１５分間の分単位スロットに対応する、９６のデータエントリ（例えば、各ベクトルは９６の長さを有することができる）を含むことができる。コンテキストデーモン４０＿１０２は、２８の以前の２４時間期間（例えば、以前の２８日）のそれぞれの間で記録されたコンテキストアイテム（例えば、デバイス状態）の観察値に対応する確率値を９６の１５分間の分単位スロットのそれぞれに割り当てることができる。例えば、コンテキストデーモン４０＿１０２は、２８ベクトルにおける９６のデータスロットのそれぞれに、コンピューティングデバイスが過去２８日における９６の１５分間の分単位スロットのそれぞれの間でロックされたままとなる可能性を示す値（例えば、０、１、０．４５など）を割り当てることができる。

ステップ４０＿２１０６では、コンピューティングデバイスは、特定のコンテキスト値がそれぞれのタイムスロットで観察される短期の確率を判定することができる。例えば、短期の確率は、過去の何日かで収集されたデータに基づいて計算することができる。例えば、コンテキストデーモン４０＿１０２は、デバイスがロックされたままとなる短期確率（ＰＳ）を、上記「短期間での平均化」セクションにて説明したように、過去７日間にわたる１５分間の分単位スロットを平均化することで、計算することができる。

ステップ４０＿２１０８では、コンピューティングデバイスは、特定のコンテキスト値がそれぞれのタイムスロットで観察される長期の確率を判定することができる。例えば、長期の確率は、過去の数週間にわたって同じ曜日（例えば、日曜日、水曜日など）に収集されたデータに基づいて計算することができる。例えば、コンテキストデーモン４０＿１０２は、デバイスがロックされたままとなる長期確率（ＰＬ）を、上記「長期間での平均化」セクションで説明するように、過去４週間にわたる１５分間の分単位スロットを平均化することで、計算することができる。

ステップ４０＿２１１０では、コンピューティングデバイスは短期及び長期の確率を組み合わせて、組み合わされた確率を生成することができる。例えば、コンテキストデーモン４０＿１０２は短期確率（ＰＳ）と長期確率（ＰＬ）とを組み合わせて、上記のように、組み合わされた確率（Ｐ）を生成することができる。一部の実装では、コンテキストデーモン４０＿１０２は長期確率（又は短期確率）を加重して、組み合わされた確率に対する長期確率の影響を調節することができる。

ステップ４０＿２１１２では、コンピューティングデバイスはコンテキストアイテム値についての確率曲線を生成することができる。例えば、コンテキストデーモン４０＿１０２は、上記「睡眠曲線の生成」セクションで説明するように、スロットワイズの確率値を確率曲線に変換することができる。

ステップ４０＿２１１４では、コンピューティングデバイスは特定のデバイスコンテキストの今後の発生を予測することができる。例えば、確率曲線が生成されると、コンテキストデーモン４０＿１０２は今後の同一のコンテキストアイテム値の発生率を確率曲線に基づいて予測することができる。例えば、上記のロック状態コンテキストの例を用いて、コンテキストデーモン４０＿１０２は、デバイスが午後１１時～午前７時の時間中、ロックされたままとなることを予測することができる。このロック状態コンテキストアイテム予測に基づいて、コンテキストデーモン４０＿１０２は、ユーザがこの予測時間中には寝ているであろうことを推論することができる。

図４０－２２は、睡眠コンテキストコールバック要求にサービスするための例示的なプロセス４０＿２２００のフロー図である。例えば、プロセス４０＿２２００は、少なくとも上記の図４０－２２にて説明される機構に対応することができる。例えば、要求クライアント４０＿１２６（例えば、アプリケーション、ユーティリティ、オペレーティングシステムツールなど）は、ユーザが寝ている時にコンテキストデーモン４０＿１０２がプロセスを通知するべきであることを指定するコールバック要求を、コンテキストデーモン４０＿１０２に送ることができる。例えば、要求クライアント４０＿１２６は、ユーザが寝ている間にメンテナンスアクティビティをスケジューリングし、これらのメンテナンスアクティビティによってユーザがコンピュータデバイスを使用している間に不便とならないように構成されてもよい。

ステップ４０＿２２０２では、コンピューティングデバイスは睡眠コンテキストコールバック要求を受信することができる。例えば、コンテキストデーモン４０＿１０２は、ユーザが就寝した１０分後にコンテキストデーモン４０＿１０２が要求クライアント４０＿１２６に通知するべきであることを指定するコールバック要求を、要求クライアント４０＿１２６から受信することができる。

ステップ４０＿２２０４では、コンピューティングデバイスはコールバック要求にサービスするために睡眠コンテキストモニタを初期化することができる。例えば、睡眠コンテキストモニタは、コンピューティングデバイスのロック状態を監視するように構成されたコンテキストモニタ４０＿１０８を含むモニタバンドル４０＿１０６であってもよい。一部の場合では、コンテキストモニタ４０＿１０８はコンピューティングデバイスのロック状態及び睡眠コンテキストに関連付けられた他の構成要素の状態を監視するように構成することができる。例えば、コンテキストモニタ４０＿１０８は、ナビゲート構成要素、無線ネットワーキング構成要素（例えば、パーソナルホットスポット、Ｂｌｕｅｔｏｏｔｈなど）、デバイス同期構成要素、及び／又はデバイス入出力構成要素（例えば、ヘッドホンジャックコネクタなど）の状態を監視することができる。

ステップ４０＿２２０６では、コンピューティングデバイスは、コンテキストモニタから睡眠コンテキスト情報を受信することができる。例えば、コンテキストモニタ４０＿１０８はコンピューティングデバイスのロック状態及び／又は他の監視されている構成要素の状態を、コンテキストデーモン４０＿１０２に報告することができる。

ステップ４０＿２２０８では、コンピューティングデバイスは今後の睡眠期間を予測することができる。例えば、コンテキストデーモン４０＿１０２は、図４０－２１を参照して上述したように、今後の睡眠期間を予測することができる。

ステップ４０＿２２１０では、コンピューティングデバイスは睡眠コンテキストコールバックをスケジューリングすることができる。例えば、予測睡眠期間が午後１１時～午前７時であり、睡眠コンテキストコールバックが、睡眠期間が始まった１０分後に要求クライアント４０＿１２６がコールバックされるべきであると指定する場合、コンテキストデーモン４０＿１０２は、午後１１時１０分に対する睡眠コールバックをスケジューリングすることができる。

ステップ４０＿２２１２では、コンピューティングデバイスはスケジューリングされた睡眠コンテキストコールバックを処理することができる。例えば、コンテキストデーモン４０＿１０２は、現在の時刻がスケジューリングされた午前１１時１０分という時間と一致するときを検出して、要求クライアント４０＿１２６にコールバック通知を送るかどうかを判定することができる。

ステップ４０＿２２１４では、コンピューティングデバイスは、ユーザが寝ているかどうかを判定することができる。例えば、コンテキストデーモン４０＿１０２は様々なコンテキストアイテム（例えば、デバイス状態）を分析して、ユーザが寝ていることを確認することができる。一部の実装では、コンテキストデーモン４０＿１０２は、現在のデバイスロック状態が、デバイスがロックされていることを示すかどうかを判定することができる。デバイスがロックされていない場合、コンテキストデーモン４０＿１０２は睡眠コールバック通知を要求クライアント４０＿１２６に送るのを取り消すか又は遅らせることができる。

一部の実装では、コンテキストデーモン４０＿１０２は、ユーザがコンピューティングデバイスを受動的に使用しているかどうかを判定することができる。例えば、ユーザは、ユーザ入力を提供する又はデバイスをロック解除することなく、デバイスを使用して（例えば、それに頼って）いることができる。ユーザがコンピューティングデバイスを受動的に使用している場合、コンテキストデーモン４０＿１０２は睡眠コールバック通知を要求クライアント４０＿１２６に送るのを取り消すか又は遅らせることができる。例えば、ユーザは、デバイスがロックされている間に、コンピューティングデバイスのナビゲート機能を用いてもよい。よって、コンテキストデーモン４０＿１０２はナビゲート構成要素（例えば、ＧＮＳＳシステム、ＷｉＦｉ、及び／又はセルラデータ送受信機など）がオンになっているかどうかを判定することができる。もし現在のコンテキスト情報がこれらのナビゲート構成要素がオンになっていることを示す場合、コンテキストデーモン４０＿１０２はユーザがコンピューティングデバイスを受動的に使用していて寝ていないと判定することができる。

受動的な使用の別の例としては、ユーザは、コンピューティングデバイスがロックされている間、コンピューティングデバイスによって提供されるパーソナルホットスポット機能を用いている可能性がある。現在のコンテキスト情報がパーソナルホットスポット構成要素に電源が入っていることを示す場合、コンテキストデーモン４０＿１０２は、ユーザがコンピューティングデバイスを受動的に使用していて寝ていないと判定することができる。

受動的に使用している別の例としては、ユーザは別のデバイス（例えば、ラップトップ、タブレットコンピュータ、スマートウォッチなど）と同期動作を始めている可能性がある。同期動作は、コンピューティングデバイスがロックされている間に実行されてもよい。現在のコンテキスト情報が、コンピューティングデバイスが同期動作を実行していることを示す場合、コンテキストデーモン４０＿１０２は、ユーザがコンピューティングデバイスを受動的に使用していて寝ていないと判定することができる。

ステップ４０＿２２１６では、コンピューティングデバイスは、差し迫ったユーザアクティビティが起きるようにスケジューリングされていないことを確認することができる。例えば、ユーザは実際に寝ているかもしれないが、コンピューティングデバイスはユーザを目覚めさせてユーザにコンピューティングデバイスを使わせる、ユーザに見える通知が間もなく発生するとスケジューリングされている可能性がある。例えば、コンピューティングデバイスは、睡眠コールバック通知がスケジューリングされたすぐ後に起きるようにスケジューリングされている、着信通信（例えば、テキストメッセージ、インスタントメッセージ、電子メール、電話通話など）についてのリマインダをスケジューリングしていた可能性がある。コンピューティングデバイスは、睡眠コールバック通知がスケジューリングされているすぐ後に起きるようにスケジューリングされているアラーム時計のアラームをスケジューリングしていた可能性がある。コンピューティングデバイスは、睡眠コールバック通知がスケジューリングされているすぐ後に起きるようにスケジューリングされる、カレンダーリマインダ又はアラームをスケジューリングしていた可能性がある。コンピューティングデバイスは、睡眠コールバック通知がスケジューリングされているすぐ後に起きるようにスケジューリングされる、出発時刻通知をスケジューリングしていた可能性がある。コンピューティングデバイスは、睡眠コールバック通知がスケジューリングされているすぐ後に起きるようにスケジューリングされる、運動リマインダをスケジューリングしていた可能性がある。コンテキストデーモン４０＿１０２が、ユーザアクティビティが閾値時間期間内（例えば、１分、５分など）に起きるようにスケジューリングされていると判定した場合、コンテキストデーモン４０＿１０２は睡眠コールバック通知を要求クライアント４０＿１２６に送るのを取り消すか又は遅らせることができる。

一部の実装では、コンピューティングデバイスは睡眠コールバック通知をクライアントに送ることができる。例えば、コンテキストデーモン４０＿１０２が、ステップ４０＿２２１４でユーザが寝ていると確認し、差し迫ったユーザアクティビティがスケジューリングされていないことを確認すると、コンテキストデーモン４０＿１０２は睡眠コールバック通知を要求クライアント４０＿１２６に送ることができる。
例示的なシステムアーキテクチャ

図１Ａは、本セクションにて説明するシステム及びプロセスを実装するためのシステムアーキテクチャを有する例示的なデバイス１００を示す。
コンテキスト監視／予測のための例示的な方法

一部の実施形態では、コンテキスト監視の方法は、コンピューティングデバイス上で実行されるコンテキストデーモンプロセスによって、１つ以上のコンテキストモニタによって監視される１つ以上のコンテキストアイテムに対応する値を受信することと、コンテキストデーモンプロセスによって、第１のコンテキストアイテムに対応するコンテキスト情報要求をコンテキストクライアントプロセスから受信することと、コンテキストデーモンプロセスによって、第１のコンテキストアイテムがコンテキストモニタによって現在監視されていないと判定することと、コンテキストデーモンプロセスによって、第１のコンテキストアイテムに対応する新たなコンテキストモニタを初期化することと、を含む。一部の実施形態では、新たなコンテキストモニタを初期化することは、新たなコンテキストモニタに対応する新たなソフトウェアパッケージをコンテキストデーモンプロセスに動的にローディングすることを含む。一部の実施形態では、新たなコンテキストモニタを初期化することは、新たなコンテキストモニタプロセスをコンテキストデーモンとは別に呼び出すことを含み、新たなコンテキストモニタプロセスは新たなコンテキストモニタに対応する。一部の実施形態では、１つ以上のコンテキストアイテム値は、コンピューティングデバイスの１つ以上のハードウェア構成要素の現在の状態を記述する。一部の実施形態では、１つ以上のコンテキストアイテム値は、コンピューティングデバイスの１つ以上のソフトウェア構成要素の現在の状態を記述する。一部の実施形態では、方法は、新たなコンテキストモニタプロセスによって、第１のコンテキストアイテムに対応する過去イベントストリームを生成すること、を含む。一部の実施形態では、新たなコンテキストモニタプロセスは、開始時間、持続期間、及び過去イベントストリーム内のイベントを記述するコンテキストアイテム値を特定する過去イベントストリームオブジェクトを生成する。

一部の実施形態では、コンテキスト通知の方法は、コンピューティングデバイス上で実行されるコンテキストデーモンプロセスによって、コンピューティングデバイスの現在のコンテキストを記述する情報を生成することと、コンテキストデーモンプロセスによって、コンテキストクライアントプロセスに通知を送るための述語を指定するコールバック要求をコンテキストクライアントプロセスから受信することであって、その述語はコンテキストクライアントをコールバックするためのコンテキスト条件を指定する、ことと、コンテキストデーモンプロセスによって、現在のコンテキストが述語に対応することを検出することと、検出したことに応じて、コンテキストデーモンプロセスによって、上記のコンテキストクライアントにコールバック通知を送ることと、を含む。一部の実施形態では、コンテキスト条件は、現在のコンテキスト内で検出されたときにコンテキストデーモンにコールバック通知をコンテキストクライアントに送らせる、１つ以上のコンテキストアイテムの値を指定する。一部の実施形態では、コールバック要求は、コンテキストクライアント及び述語のための識別子を含み、一部の実施形態では、方法は、コンテキストデーモンによって、コールバック要求についての固有の識別子を生成することと、コンテキストデーモンによって、固有の識別子を要求クライアントに送ることと、を含む。一部の実施形態では、方法は、コンテキストデーモンによって、固有識別子、コンテキストクライアント識別子、及び述語の間の関連付けを記憶することを含む。一部の実施形態では、記憶することは、固有識別子、コンテキストクライアント識別子、及び述語を、コンテキストデーモンと関連付けてメモリに記憶することを含む。一部の実施形態では、記憶することは、固有識別子、コンテキストクライアント識別子、及び述語を、述語データベースに記憶することを含む。一部の実施形態では、方法は、コンテキストデーモンによって、コンピューティングデバイスのソフトウェア及びハードウェア構成要素の現在の状態を記述するデバイス状態情報を受信することと、コンテキストデーモンによって、受信したデバイス状態情報に基づいて現在のコンテキスト情報を生成することと、を含む。

一部の実施形態では、コンテキスト予測の方法は、コンピューティングデバイスによって、コンピューティングデバイスによって監視されるコンテキストアイテムに対応する過去イベントストリームを取得することと、コンピューティングデバイスによって、過去イベントストリーム内のそれぞれの時間期間内でコンテキストアイテムの特定の値が観察される複数の確率を計算することと、コンピューティングデバイスによって、計算された確率に基づく確率曲線を生成することと、コンピューティングデバイスによって、コンテキストアイテムの特定の値の今後の発生を確率曲線に基づいて予測することと、を含む。一部の実施形態では、方法は、ユーザアクティビティの今後の発生を確率曲線に基づいて予測すること、を含む。一部の実施形態では、予測されるユーザアクティビティは予測されるユーザ睡眠期間に対応する。一部の実施形態では、方法は、コンテキストデーモンによって、ユーザアクティビティの予測される今後の発生の前の要求された時間にコンテキストデーモンが要求クライアントに通知することを要求するコールバック要求を、要求クライアントから受信することと、コンテキストデーモンによって、要求された時間に通知を送信することをスケジューリングすることと、コンテキストデーモンによって、予測されるユーザアクティビティの今後の発生の前の要求された時間に要求クライアントに通知を送ることと、を含む。一部の実施形態では、方法は、コンテキストデーモンによって、予測されるユーザ睡眠期間中の要求された時間にコンテキストデーモンがコールバッククライアントに通知することを要求するコールバック要求を、要求クライアントから受信することと、コンテキストデーモンによって、予測されるユーザ睡眠期間中の要求された時間に通知を送信することをスケジューリングすることと、要求された時間が現在の時間に対応すると判定することと、コンテキストデーモンによって、ユーザが現在の時間に寝ているかどうかを判定することと、コンテキストデーモンによって、ユーザが現在の時間に寝ているとコンテキストデーモンが判定したときに、要求クライアントに通知が送信されることと、を含む。一部の実施形態では、ユーザが現在の時間に寝ているかどうかを判定することは、ユーザによって始められた動作がコンピューティングデバイスによって現在の時間に実行されているかどうかを判定することを含む。一部の実施形態では、ユーザが現在の時間に寝ているかどうかを判定することは、ユーザに見える動作が、現在の時間に対して閾値時間内でコンピューティングデバイスによって実行されるようにスケジューリングされているかどうかを判定することを含む。

一部の実施形態では、効率的なコンテキスト監視の方法は、コンピューティングデバイス上で実行されるコンテキストデーモンプロセスにて、コンテキストクライアントとコンテキストデーモンとの間の第１の通信セッションを開始する第１のコンテキストコールバック要求を、コンテキストクライアントから受信することと、コンテキストデーモンによって、現在のコンテキスト情報を受信することと、現在のコンテキスト情報がコンテキストコールバック要求に対応すると判定することと、判定したことに応じて、コンテキストデーモンによって、コンテキストクライアントとの第１の通信セッションが終了していることを検出することと、検出したことに応じて、コンテキストデーモンによって、起動デーモンがコンテキストクライアントを再起動することを要求する再起動メッセージを起動デーモンに送ることと、を含む。一部の実施形態では、コールバック要求はクライアント識別子を含み、コンテキストデーモンによって、メッセージ内の起動デーモンにクライアント識別子を送信することを更に含む。一部の実施形態では、現在のコンテキスト情報は、コンピューティングデバイスの現在の状態を記述する１つ以上のコンテキストアイテムを含む。一部の実施形態では、コンテキストコールバック要求は、コンテキストデーモンによって受信された現在のコンテキスト情報に基づいてコンテキストクライアントに通知するための条件を指定する。一部の実施形態では、方法は、コンテキストデーモンが第１のコンテキストコールバック要求を受信した後にコンテキストクライアントを終了させることを含む。一部の実施形態では、方法は、再起動メッセージを受信すると、起動デーモンによって、コンテキストクライアントを再起動することと、クライアントが再起動された後に、コンテキストデーモンによって、コンテキストクライアントから第２のコンテキストコールバック要求を受信することと、第２のコンテキストコールバック要求を現在のコンテキスト情報と比較することと、比較したことに応じて、現在のコンテキスト情報が第２のコンテキストコールバック要求に対応することをコンテキストクライアントに通知することと、を含む。一部の実施形態では、第２のコンテキストコールバック要求は、コンテキストクライアントとコンテキストデーモンとの間に第２の通信セッションを確立し、コンテキストデーモンは、コンテキストクライアントによって確立された第２の通信セッションを用いて、コンテキストクライアントに通知する。
セクション１１：アプリ内検索のクライアント、サーバ、及びウェブ態様

本セクション「アプリ内検索のクライアント、サーバ、及びウェブ態様」の内容は、一部の実施形態による、アプリ内検索、クラウドソーシングアプリケーション履歴検索、並びにアプリケーションビューインデックス化及び検索の、クライアント、サーバ、及びウェブベースの態様を説明し、本明細書に提供される開示を補足する情報を提供する。例えば、本セクションの一部はアプリケーション状態を検索する方法を説明し、例えば、ディープリンクの作成及び使用に関する、本明細書に提供される開示を補足する（方法６００及び８００を参照して以下に記載するように）。
アプリ内検索のクライアント、サーバ、及びウェブ態様についての概要

複数のアプリケーション状態を用いて検索を実行するデバイスの方法及び装置を説明する。例示的な実施形態では、デバイスは、デバイス上で稼働する複数のアプリケーションから複数のアプリケーション状態を受信する。デバイスは更に、複数のアプリケーション状態のインデックスを作成する。それに加え、デバイスは、デバイス上に記憶されたデータを検索するクエリを受信する。更に、デバイスは、複数のアプリケーション状態を、インデックス及びクエリを用いて検索する。デバイスは更に、複数のアプリケーション状態のうちの１つのクエリについての一致を判定し、その一致するアプリケーション状態についての一致を返す。

別の実施形態では、デバイスは、デバイス上の複数のアプリケーション状態を用いてクエリを実行する。この実施形態では、デバイスは、デバイス上に記憶されているインデックスを用いてクエリを実行する。デバイスは、クエリに一致する複数の結果を更に受信する。それに加え、デバイスは、デバイスにインストールされているネイティブアプリケーションに対応するアプリケーション状態に対応する複数の結果のサブセットを判定する。更に、デバイスは、複数の結果のサブセット内の結果のそれぞれについて、その結果と、その結果に対応するネイティブアプリケーションの表現とを提示する。

更なる実施形態では、デバイスはマルチデバイス検索にて用いるアプリケーション状態を選択する。この実施形態では、デバイスは、デバイス上において、アプリケーション状態が、そのデバイスのデバイスレベルでの検索についてのクエリ結果として選択されていることを検出する。デバイスは更にアプリケーション状態をサーバに送信し、そこでアプリケーション状態は、他のデバイスからの他のアプリケーション状態と一緒にインデックス化される。

更に別の実施形態では、デバイスは、第２のデバイスから受信したアプリケーション状態を用いて、第１のデバイスについての検索を実行する。この実施形態では、デバイスは、複数のアプリケーション状態を、複数のデバイス上において稼働している複数のアプリケーションから受信する。デバイスは更に、複数のアプリケーション状態のインデックスを作成する。デバイスは付加的に、デバイス上に記憶されたデータを検索するクエリを受信する。それに加え、デバイスはインデックス及び検索クエリを用いて複数のアプリケーション状態を検索し、その一致するアプリケーション状態についての一致を返す。

更なる実施形態では、デバイスは検索を実行する。この実施形態では、デバイスはクエリをサーバに送信し、クエリに一致する複数の結果を受信する。デバイスは更に、デバイスにインストールされているネイティブアプリケーションに対応する別のデバイス上で生成されたアプリケーション状態を含む、複数の結果のサブセットを判定する。それに加え、デバイスは、複数の結果のサブセット内の結果のそれぞれについて、ネイティブアプリケーションのリンク及び表現を提示する。

別の実施形態では、デバイスは検索クエリインデックス内にアプリケーション状態をインデックス化する。この実施形態では、サーバと連結される別のデバイスからアプリケーションのアプリケーション状態を受信する。デバイスは更に、アプリケーション状態に対応するアプリケーションのビューを生成し、このビューは、アプリケーション状態に対応する、アプリケーションのユーザインタフェースの表現である。それに加え、デバイスはビューを検索クエリインデックス内にインデックス化する。

更なる実施形態では、デバイスはクエリ結果と関連付けられたビューを有するアプリケーション状態を取り出す。この実施形態では、デバイスはサーバにクエリを送信する。デバイスは更に、クエリに対する結果をサーバから受信し、その結果は、その結果に対応するアプリケーションのアプリケーション状態のビューを含み、ビューはアプリケーション状態に対応するアプリケーションのユーザインタフェースの表現である。デバイスは付加的に、結果をビューのインジケーションと共に提示する。

他の方法と装置についても説明する。
アプリ内検索のクライアント、サーバ、及びウェブ態様についての詳細な説明

複数のアプリケーション状態を用いて検索を実行するデバイスの方法及び装置を説明する。以下の説明では、本発明の実施形態の完全な説明を提供するために、数多くの具体的な詳細が記載される。しかしながら、本発明の実施形態は、これらの具体的な詳細を伴わずとも実践することができる点が、当業者には明らかとなるであろう。他の例では、本説明の理解を分かりにくくすることがないように、周知の構成要素、構造及び技術は、詳細には示されていない。

本明細書中での「一実施形態」又は「実施形態」への言及は、その実施形態に関連して説明される特定の機構、構造、又は特性を、本発明の少なくとも１つの実施形態に含めることができることを意味する。本明細書における様々な箇所での、語句「一実施形態では」の出現は、必ずしも全てが同じ実施形態を言及しているものではない。

以下の説明及び請求項において、「連結している」及び「接続されている」と共にこれらの派生語が使用される場合がある。これらの言葉は、互いに同義語として意図されていないことを理解すべきである。「連結している」は、相互に物理的又は電気的に直接接触しているかもしれず、していないかもしれない２つ以上の要素が、互いに協働し、又は相互作用することを示すために使用される。「接続されている」は、相互に連結している２つ以上の要素間の通信の確立を示すために使用される。

以下の図で示されるプロセスは、ハードウェア（例えば、回路機構、専用論理など）、ソフトウェア（汎用コンピュータシステム、又は専用機械上で稼働されるものなど）、又は両方の組み合わせを含む、処理論理によって実行される。それらのプロセスは、幾つかの逐次動作の観点から以下で説明されるが、説明される動作の一部は、異なる順序で実行することができる点を理解するべきである。更には、一部の動作は、逐次的にではなく、並列して実行することができる。

「サーバ」、「クライアント」、「デバイス」という用語は、サーバ、クライアント及び／又はデバイスに特定のフォームファクタよりも、一般的にデータ処理システムに言及することを意図している。

複数のアプリケーション状態を用いて検索を実行するデバイスの方法及び装置を説明する。上記のように、ユーザはウェブブラウザを用いたデジタルルーチンを有するため、ウェブブラウザの履歴を検索することができるのは便利である。このデジタルルーチンは、繰り返し同じアプリケーションにアクセスし、それらのアプリケーションを同種の作業に用いることを更に含むことができる。上述のとおり、スマートフォンユーザは、平均して、８６％の時間をウェブブラウザ以外のアプリケーションに費やす。しかしながら、ウェブブラウザ以外のアプリケーションの履歴を検索できるようにすることは難しい。なぜなら、アプリケーションの利用履歴のデータには（あったとしても）アクセスすることが難しく、独自の形式をとるからである。よって、アプリケーション履歴は検索することが難しい。

一実施形態では、デバイスは実行中のアプリケーションのアプリケーション状態を生成し、記憶する。デバイスはこれらのアプリケーション状態を更にインデックス化し、デバイス上で稼働しているローカル検索サービスが、インデックス化されたアプリケーション状態を検索してクエリについての結果を提供できるようにする。この実施形態では、アプリケーション状態は、アプリケーションのある時点のスナップショットである。アプリケーション状態は、ウェブブラウザ履歴に類似する。一実施形態では、アプリケーション状態はウェブブラウザ以外のアプリケーションのためのものである。一実施形態では、アプリケーションについてのアプリケーション状態は、タイトル、ビュー、このビューに表示されている日付、関連付けられたメタデータ、及び／又はその状態についての他の状態情報を含むことができる。例えば、一実施形態では、アプリケーションは、ある地理的エリアについての様々なビジネス及びサービスのレビューを表示するレビュー型アプリケーションであり得る。この例では、それぞれのアプリケーション状態は、ビジネス又はサービスについてのレビュー及び関連情報のセット（例えば、名前、住所、連絡先情報、営業時間、ビジネス又はサービスの説明、来客者又はサービス若しくはビジネスのユーザによって提出されたレビューのセット、及び／又はそのビジネス若しくはサービスと関連付けられた他の種類の情報）であってもよい。それぞれのアプリケーション状態は、一つのユーザインタフェースページ又は複数のユーザページにわたって表示することができ、各ページはディスプレイ用にコンテンツが編成されている（一部の実施形態では、各ページは特定の時点でのアプリケーションのウィンドウである）。一実施形態では、実行中のアプリケーションのそれぞれは１つ以上のアプリケーション状態をエクスポートし、デバイスはアプリケーション状態をアプリケーション状態インデックスにインデックス化する。

アプリケーション状態をインデックス化することで、ユーザはアプリケーションの履歴を検索することができる。このことで、ユーザは以前のアプリケーション状態を検索して見つけることができるようになる。見つかったアプリケーション状態を用いて、ユーザは対応するアプリケーションをこのアプリケーション状態で起動することができ、このことで、アプリケーションがアプリケーション状態をエクスポートした時にアプリケーションが実行していた時点の状態にする。ユーザは、複数の異なるアプリケーションについての一般的な機構を介して、インデックス化されたアプリケーション状態を用いて、そのアプリケーションを以前に使用した状態に戻すことができる。例えば、一実施形態では、アプリケーション状態は、輸送システムの特定系統（route）についての乗換アプリケーションのページであり得る。この例では、ユーザは乗換アプリケーションにおいて、例えば路線バスの系統７など、特定の系統にナビゲートしてもよい。その特定の系統にナビゲートすることで、乗換アプリケーションはその路線バスの系統ページについてのアプリケーション状態をアプリケーション状態インデックスにエクスポートする。このアプリケーション状態がインデックス化されることで、ユーザはそのアプリケーション状態を、クエリを介して取り出すことができる。例えば、一実施形態では、ユーザが「バス系統７」をクエリに入力すると、路線バス系統７についてのアプリケーション状態がクエリ結果として出現することになる。このアプリケーション状態を選択すると、乗換アプリケーションが、路線バス系統７についてのアプリケーション状態と共にローディングされ、この乗換アプリケーション内の路線バス系統７のページがユーザに表示される。よって、この例では、乗換アプリケーションが以前に実行されていた時と同じ状態にされる。

別の実施形態では、デバイスは、これらのアプリケーション状態を生成しなかったデバイスからのクエリをサポートするために用いることができるリモートアプリケーション状態インデクサに、アプリケーション状態をエクスポートすることができる。この実施形態では、デバイスは、ユーザによって関与された（engaged）アプリケーション状態をエクスポートし、関与されたアプリケーション状態とは、デバイス上でのユーザによるクエリに応じてクエリ結果として返され、そのユーザがそのアプリケーション状態を選択しているという、アプリケーション状態である。それに加え、デバイスは、アプリケーション状態をエクスポートする前に個人情報を取り除くことで、アプリケーション状態をサニタイジング（sanitize）する。リモートアプリケーション状態インデクサはこのアプリケーション状態を受信し、リモートアプリケーション状態インデクサがこのアプリケーション状態を必要な回数だけ受信した場合にそのアプリケーション状態をインデックス化する。この実施形態では、必要な回数後にアプリケーション状態をインデックス化することで、このアプリケーション状態はクラウドソース化され、多くの異なるユーザ及び／又はデバイスがこのアプリケーション状態をローカル検索において関与している。一実施形態では、アプリケーション状態について一定数の関与を必要とすることは、このアプリケーション状態が他のユーザにとって便利であるという可能性を増す。インデックス化がされると、リモート検索サービスはそのリモートアプリケーション状態インデックスを検索して、クエリに一致するアプリケーション状態があるかどうか判定することができる。各一致について、リモート検索サービスは一致するアプリケーション状態（単数又は複数）をクライアントに返す。クライアント側では、ユーザはアプリケーション状態を選択することができ、ここでは対応するアプリケーションが起動されて、アプリケーションを、アプリケーションがアプリケーション状態をエクスポートした時にアプリケーションが実行していた時点の状態にする。

更なる実施形態では、デバイスは異なるアプリケーション状態についてのアプリケーション状態ビューを生成する。この実施形態では、アプリケーション状態ビューは、そのアプリケーション状態に対応するアプリケーションのユーザインタフェースの表現である。例えば、一実施形態では、ビジネス及びサービスについて何千、何百万のレビューのコンテンツにアクセスのあるレビュータイプのアプリケーションは、何千、何百万ものレビューのそれぞれについてビューを有することができる。それらのビューを用いて、アプリケーション状態及びアプリケーション一般もプレビューすることができる。一実施形態では、これらのアプリケーション状態ビューを用いて、クエリに対する結果のセットで返されたアプリケーション状態をプレビューすることができる、又はこれらのアプリケーション状態ビューを用いて、アプリケーションを一般的にプレビューすることができる。一実施形態では、１つのアプリケーションについて多数のアプリケーション状態ビューを収集することを用いて、アプリケーションストアにてそのアプリケーションをプレビューすることができる。例えば、一実施形態では、レビュー型アプリケーションは、このアプリケーションについて利用可能な数十ものアプリケーション状態ビューを有していてもよい。

図４１－１は、ローカルデバイス検索インデックスにて用いるためにアプリケーション状態をインデックス化するシステムの一実施形態のブロック図である。図４１－１では、デバイス４１＿１００は、アプリケーション状態インデクサ４１＿１０４と連結される複数のアプリケーション４１＿１０２を含む。一実施形態では、デバイス４１＿１００は別のデバイスとネットワークデータを通信できる任意の種類のデバイスである（例えば、パソコン、ラップトップ、サーバ、モバイルデバイス（例えば、電話、スマートフォン、スマートウォッチ、パーソナルゲーミングデバイスなど）、別のネットワーク要素など）。一実施形態では、デバイス４１＿１００は仮想マシンであることができ、又は１つ以上の仮想マシンをホストするデバイスであり得る。一実施形態では、デバイス４１＿１００はアプリケーション状態検索インデックス４１＿１０８を更に含む。一実施形態では、アプリケーション４１＿１０２のそれぞれは、そのアプリケーションが稼働している間に一連の状態を経て進行する実行プログラムである。例えば、一実施形態では、アプリケーション４１＿１０２は、ワードプロセッシングアプリケーション、スプレッドシート、連絡先、メール、電話、ウェブブラウザ、メディアプレーヤ、レビューアプリケーション、分類された広告アプリケーション、ソーシャルネットワーキング、生産性、ユーティリティ、ゲーム、不動産、写真、動画、電子商取引、出店（storefront）、クーポン、オペレーティングシステム、及び／又はデバイス上で稼働することができる任意の他の種類のアプリケーションであることができる。

上記のように、アプリケーション４１＿１０２のそれぞれは、そのアプリケーションが実行されている間に一連の状態経て進行する。一実施形態では、これらのアプリケーション状態のうちの１つは、アプリケーションのある時点のスナップショットである。一実施形態では、アプリケーション４１＿１０２についてのアプリケーション状態は、タイトル、ユーザインタフェース状態、このユーザインタフェースに表示されるデータ、関連付けられたメタデータ、及び／又は状態についての他の状態情報を含むことができる。更なる実施形態では、アプリケーション状態は、どのように状態が検索結果に表現するかを記述する情報を含む。例えば、一実施形態では、アプリケーション４１＿１０２は、ある地理的エリアについての様々なビジネス及びサービスのレビューを表示するレビュー型アプリケーションであり得る。この例では、それぞれのアプリケーション状態は、ビジネス又はサービスについてのレビュー及び関連情報のセット（例えば、名前、住所、連絡先情報、営業時間、ビジネス又はサービスの説明、来客者又はサービス若しくはビジネスのユーザによって提出されたレビューのセット、及び／又はそのビジネス若しくはサービスと関連付けられた他の種類の情報）であってもよい。一実施形態では、アプリケーション状態タイトルはそのアプリケーション状態について与えられたタイトルであり、例えば、レビュー型アプリケーションの場合では、そのビジネス又はサービスの名前などである。アプリケーション状態についてのユーザインタフェース状態は、そのアプリケーション状態に対応するアプリケーション４１＿１０２のユーザインタフェースの表現であり得る。この実施形態では、ユーザインタフェース状態はユーザインタフェースの表現、そのユーザインタフェースがどこにスクロールするか、又はどのユーザインタフェースの構成要素がアクティブであるか、アプリケーションが何のモードにあるか（例えば、アプリケーション４１＿１０２はユーザに情報を提示するために用いられる異なるモードを有し得る）を含むことができる。更なる実施形態では、アプリケーションは、タイトルに加えてユニフォームリソースロケータ（Uniform Resource Locator）又はアプリケーション識別子、及び状態と互換性のあるアプリケーションのバージョン番号を含められるだけの小ささであってもよい。

一実施形態では、各アプリケーション状態は、タイトル、検索可能データ及び／又はメタデータ、並びにアプリケーション特有の不透明データを含む。この実施形態では、検索可能データ及び／又はメタデータは、アプリケーション４１＿１０２によって、この検索可能データ及び／又はメタデータがアプリケーション状態をインデックス化するのに用いることができる、並びにクエリの結果としてアプリケーション状態を返すのに用いることができる、検索インデックス化サービス及び／又はクエリ検索サービスによってアクセス可能なデータであるとして指定されるデータである。例えば、一実施形態では、検索可能なデータ及び／又はメタデータは、アプリケーション状態内のコンテンツであり得る（例えば、アプリケーション状態タイトル、ユーザインタフェース状態に表示されるコンテンツ、メディアデータ、位置データ、時間データ、又は検索インデックスに用いることのできる任意の他の種類のデータ若しくはメタデータ）。一実施形態では、アプリケーション特有不透明データは、アプリケーションを以前の状態に戻すために用いられるアプリケーション特有データであり、検索可能なデータであってもなくてもよい。この実施形態では、アプリケーション状態を対応するアプリケーション４１＿１０２によってローディングすることで、そのアプリケーションをそのアプリケーション状態に戻す。例えば、一実施形態では、アプリケーション特有不透明データは、ユーザインタフェース状態、ユーザインタフェースモード、及び／又はリソースへの参照を含むことができる。ユーザインタフェースモードは、ユーザフェースが現在使用しているモードの種類であってもよい。例えば、一実施形態では、ワードプロセッシングプログラムは下書きレイアウトビュー又は印刷レイアウトビューであることができ、画像編集プログラムはライブラリモード、画像編集モード、又は印刷モードにあることができる。一実施形態では、参照されたリソースは、閲覧又は編集されているものはファイルでもよく、ネットワーク上のサーバなど、デバイス上、又は別のデバイスにあることができるリソースへのユニフォームリソースロケータであり得る。一実施形態では、アプリケーション状態の一部であるデータは、（キー、値）対を有する辞書に存在することができる。

一実施形態では、アプリケーション４１＿１０２の１つ以上はそれぞれ、１つ以上のアプリケーション状態をアプリケーション状態インデクサ４１＿１０４にエクスポートする。この実施形態では、アプリケーション４１＿１０２はそれぞれ、アプリケーション状態を固定又は可変スケジュールにエクスポートすることができる。例えば、一実施形態では、アプリケーション４１＿１０２はアプリケーション状態を決まった時間に基づいてエクスポートする、ユーザとの１つ以上の相互作用の後に、又は他の指標にて、新しいユーザインタフェース状態それぞれについてアプリケーション状態をエクスポートすることができる。別の例として、別の実施形態では、レビューアプリケーションは新たなレビュー又はレビュー検索にナビゲートしてもよい。この例では、新たなレビュー又はレビュー検索にナビゲートすることで、新たなビューが生成され、新たなアプリケーション状態が生成されてアプリケーション状態インデクサ４１＿１０４にエクスポートされる。アプリケーション状態インデクサはアプリケーション状態を受信し、アプリケーション状態をアプリケーションインデックス４１＿１０８に追加する。アプリケーション状態をインデックスに追加することにより、新しいアプリケーション状態が、ローカル検索サービスによって受信されるクエリに一致させるために、ローカル検索サービスで利用可能となる。別の実施形態では、アプリケーション状態を、以下の図４１－６～１１にて説明する、リモート検索アプリケーション状態インデックス４１＿１０８にエクスポートすることができる。

図４１－２は、オンデバイスアプリケーション状態検索インデックスを用いてアプリケーション状態を検索するシステムの一実施形態のブロック図である。図４１－２では、デバイス４１＿２００は、ローカル検索サービス４１＿２０８に連結されるアプリケーション４１＿２０４を含む。ローカル検索サービス４１＿２０８は、アプリケーション状態検索インデックス４１＿２１２及びローカル検索インデックス４１＿２１４に更に連結される。一実施形態では、デバイス４１＿２００は図４１－１にあるようなデバイスである。一実施形態では、アプリケーション４１＿２０４は検索入力フィールド４１＿２０６を含む。この実施形態では、検索入力フィールドを用いて、クエリを入力し、このクエリは、ローカル検索サービスによってこのクエリを用いて検索を実行するために用いられ得る。クエリが検索入力４１＿２０６に入力された場合、アプリケーション４１＿２０４はこのクエリをローカル検索サービス４１＿２０８に送信する。ローカル検索サービス４１＿２０８はクエリを受信し、ローカル検索インデックス４１＿２１４及び／又はアプリケーション状態検索インデックス４１＿２１２を検索することによりランキング付けした結果を生成し、クエリについての結果のセットを決定する。それに加え、ローカル検索サービス４１＿２０８は結果をランク付けし、アプリケーション４１＿２０４に送り返す。

この実施形態では、検索は、デバイス４１＿２００上に記憶されたオブジェクトの検索を含むことができる。例えば、一実施形態では、オブジェクトは、ドキュメント、画像、音楽、アプリケーション、電子メール、カレンダーエントリ、及び／又はローカル検索インデックスに記憶されている他のオブジェクトであり得る。一実施形態では、検索は、検索モジュールによって維持されるインデックスに基づく。この実施形態では、インデックスはデバイスのオブジェクトに記憶されたメタデータのインデックスである。代替的な実施形態では、ローカル検索サービス４１＿２０８はまた、クエリをアプリケーション状態検索インデックス４１＿２１２に適用することができる。この実施形態では、ローカル検索サービス４１＿２０８はクエリをアプリケーション状態検索インデックス４１＿２１２に適用し、クエリと一致するアプリケーション状態があるかを判定する。例えば、一実施形態では、ローカル検索サービス４１＿２０８は、インデックス４１＿２１２に記憶されたアプリケーション状態のそれぞれについて、クエリを検索可能データに適用する。この例では、インデックス４１＿２１２における１つ以上のアプリケーション状態についてクエリとの一致がある場合、ローカル検索サービス４１＿２０８は、これらの１つ以上のアプリケーション状態を含む結果のセットをアプリケーション４１＿２０４に返す。アプリケーション４１＿２０４はランク付けされた結果を表示する。ランク付けされた結果のうちの１つがアプリケーション状態である場合、アプリケーションはアプリケーションのアイコン、アプリケーション状態タイトル、及びアプリケーション状態概要を表示することができる。一実施形態では、表示されたアプリケーション状態を選択すると、アプリケーション状態に対応するアプリケーションはそのアプリケーション状態と共にローディングされる。この実施形態では、アプリケーションをそのアプリケーション状態と共にローディングすることにより、アプリケーションはそのアプリケーション状態に対応する実行状態でローディングされる。例えば一実施形態では、アプリケーション状態がクーポンアプリケーションについての特定のクーポン（例えば、（５０％週末車レンタル！）である場合、クーポンアプリケーションはこのアプリケーション状態と共にローディングされ、アプリケーション状態は、まるでユーザがそのクーポンにナビゲートしたかのように特定のクーポンを表示する。

図４１－３は、他のクエリ結果の中のうちから、あるアプリケーション状態クエリ結果を表示するユーザインタフェースの実施形態のブロック図である。図４１－３では、デバイス上にアプリケーション状態を表示するための、３つの異なる可能なユーザインタフェース４１＿３００Ａ～Ｃを示す。一実施形態では、ユーザインタフェース４１＿３００Ａは、検索入力４１＿３０２、アプリケーション状態ディスプレイ４１＿３１４Ａ、他のアクション４１＿３１０Ａ、及びオンスクリーンキーボード４１＿３１２Ａを含む。一実施形態では、検索入力４１＿３０２Ａは、デバイスのユーザによってクエリを入力するために用いられる。この実施形態では、クエリの一部又は全体を入力して、クエリ結果の１つ以上のセットを判定するためにローカル検索サービスに送信することができる。一実施形態では、検索の１つ以上の文字が入力されると、クエリに対する結果が返される。それに加え、アプリケーション状態ディスプレイ４１＿３１４Ａは、アプリケーションアイコン４１＿３０４Ａ、アプリケーション状態タイトル４１＿３０６Ａ、及びアプリケーション状態概要４１＿３０８Ａを含む。一実施形態では、アプリケーションアイコン４１＿３０４Ａは、アプリケーション状態に対応するアプリケーションを表すアイコンである。この実施形態では、アプリケーションアイコン４１＿３０４Ａは、クエリから返された又はアプリケーション状態に記憶された情報に基づいて取り出されたアプリケーション状態の一部であり得る。一実施形態では、アプリケーション状態タイトル４１＿３０６Ａは、アプリケーション状態に記憶されているアプリケーション状態のタイトルである。更に、アプリケーション状態概要４１＿３０８Ａはアプリケーション状態の概要である。例えば、一実施形態では、アプリケーション状態概要４１＿３０８Ａは、アプリケーション状態のコンテンツの記述など、アプリケーション状態の記述を含む。この例では、アプリケーション状態概要４１＿３０８Ａは、アプリケーション状態に関連付けられるコンテンツをユーザに対してインジケーションを与えることができる。

一実施形態では、ユーザインタフェース４１＿３００Ａは、アプリケーション状態４１＿３１４Ａを含むクエリ結果を表示することに加えて、他のアクション４１＿３１０Ａを含むことができる。例えば一実施形態では、他のアクション４１＿３１０Ａは、クエリでウェブを検索するため、又はクエリでオンラインの百科事典を検索するための、リンクを含むことができる。ユーザインタフェース４１＿３００Ａはまた、ユーザによって用いられる、検索クエリを入力するためのオンスクリーンキーボード４１＿３１２Ａも、含むことができる。あるいは、クエリは他の手段を介して入力することができる（例えば、デバイスに連結されたマイクを介して、ポータブルデバイスに連結されるスマートウォッチなど、デバイスに連結された別のデバイスによって）。一実施形態では、アイコン４１＿３０４Ａは、アプリによって提供されるアプリ状態に特有のイメージサムネイルであってもよい。それに加え、アイコン４１＿３０４Ａは動画又は動画プレビューでもあり得る。更なる実施形態では、アプリケーション状態概要は、電話アイコン、再生、方向、購入などのような「アクション」ボタンを含むことができる。

一実施形態では、クエリ結果として表示することができる多くの異なる種類のアプリケーション状態がある。例えば、一実施形態では、アプリケーション状態は、輸送システムの特定系統についての乗換アプリケーションのビューであり得る。この例では、ユーザは乗換アプリケーションにおいて、例えば路線バスの系統７など、特定の系統にナビゲートしてもよい。その特定の系統にナビゲートすることで、乗換アプリケーションはその路線バスの系統ビューについてのアプリケーション状態を、アプリケーション状態インデックスにエクスポートする。このアプリケーション状態がインデックス化されることで、ユーザはそのアプリケーション状態を、クエリを介して取り出すことができる。例えば、一実施形態では、ユーザが「バス系統７」をクエリに入力すると、路線バス系統７についてのアプリケーション状態がクエリ結果として出現することになる。このアプリケーション状態を選択すると、乗換アプリケーションは路線バス系統７についてのアプリケーション状態ともにローディングされ、この乗換アプリケーションにおける路線バス系統７のユーザインタフェースがユーザに表示される。よって、この例では、乗換アプリケーションが以前に見られていた時と同じ状態にされる。

別の例として、別の実施形態では、ユーザは食べ物宅配アプリケーションを用いてもよく、ユーザは以前の注文のうちの１つを再度注文したいだけである。この例では、ユーザは、ローカルのレストランに固有のアプリケーションを用いて、ローカルのレストランからフォースープを注文してもよい。この注文では、ローカルのレストランのアプリケーションは、フォースープの注文に対応するアプリケーション状態をエクスポートするであろう。このアプリケーション状態は、インデックス化されてローカル検索サービスによってアクセス可能とされるであろう。ユーザはその後、クエリ「フォースープ」、「ベトナムレストラン」、又はローカルのレストランの名前を入力してもよく、この注文に対応するアプリケーション状態がこの結果のうちの一つであり得る。このアプリケーション状態もまた、この結果についてのトップヒットとなり得る。このアプリケーション状態を選択すると、ローカルのレストランアプリケーションが起動され、ユーザがスープの注文を完了させられるよう、以前のフォースープの注文を表示する。

更なる例及び実施形態では、ユーザは次の荒野への旅を計画するためにピクチャーボードを保持してもよい。この例では、この次の旅行に関する写真やコメントをリンクするために、ユーザはピクチャーボードアプリケーションを用いる。ユーザは、デバイスのクリップボードからリンクを追加するために、ピクチャーボードアプリケーションを用いたこの特定のピクチャーボードに戻ってくるであろう。ピクチャーボードアプリケーションは、この荒野への旅についてのピクチャーボードのアプリケーション状態をエクスポートすることで、このアプリケーション状態はローカル検索サービスによって利用可能になる。旅行の地名など、このアプリケーション状態を検索することで、ユーザは、ピクチャーボードアプリケーションを起動してこの特定のピクチャーボードビューにナビゲートする代わりに、クエリを介してピクチャーボードアプリケーション内のこの荒野への旅のピクチャーボードに素早く行くことができる。

一実施形態では、アプリケーション状態を保存することは、ナビゲートしづらいユーティリティの特定のビューに素早くアクセスするために用いることができる。例えば、一実施形態では、デバイス設定アプリケーションは、多数レベルの深さにある多数の選択肢を有していてもよい。この例では、ユーザは設定アプリケーション内のバッテリ使用ページに行き、どのアプリケーションが最もバッテリを消費しているかを見てもよい。バッテリ使用ページは４レベル以上深い場合があり、アクセスしづらい。設定アプリケーションのより良い使用ページについてのアプリケーション状態をエクスポートすることにより、ユーザはクエリ「バッテリ使用」「バッテリ」、「バッテ（batter）」、又は言葉「バッテリ使用」の何らかの他のプレフィックスを入力することで、設定アプリケーションのバッテリ使用ページのアプリケーション状態がクエリの結果として現れるようにすることができ得る。このことで、設定アプリケーションにてナビゲートしづらい可能性のあるところへの素早いアクセスが可能となり得る。

別の実施形態では、クエリについてのアプリケーション状態結果が、上記図４１－２に説明するローカル検索インデックスなど、他のドメインからの他のクエリ結果と一緒に示されてもよい。図４１－３では、ユーザインタフェース４１＿３００Ｂは、アプリケーション状態４１＿３１４Ｂを他のクエリ結果４１＿３１０Ｂと共に表示する。このユーザインタフェース４１＿３００Ｂでは、検索入力４１＿３０２Ｂは、アプリケーション状態４１＿３１４Ｂ、他のクエリ結果４１＿３１０Ｂ、及びオンスクリーンキーボード４１＿３１２Ｂと共に表示される。一実施形態では、検索入力４１＿３０２Ｂ及びオンスクリーンキーボード４１＿３１２Ｃは、ユーザインタフェース４１＿３００Ａについて上述したものと同じである。それに加え、アプリケーション状態４１＿３１４Ｂは、アプリケーションアイコン４１＿３０４Ｂ、アプリケーション状態タイトル４１＿３０６Ｂ、及びアプリケーション状態概要４１＿３０８Ｂを含み、これらはユーザインタフェース４１＿３００Ａについて上述したアプリケーションアイコン、アプリケーション状態タイトル、及びアプリケーション状態概要と同じである。更に、ユーザインタフェース４１＿３００Ｂは他のクエリ結果４１＿３１０Ｂを含み、これらは他のドメインからの他のクエリ結果又はアプリケーション状態であり得る。例えば、一実施形態では、クエリ「バッテリ」についての他のクエリ結果４１＿３１０Ｂは、単語「バッテリ」に一致するローカル検索インデックス内のオブジェクトインデックス、単語「バッテリ」に一致する他のアプリケーション状態、又は単語「バッテリ」に一致するローカル若しくはリモート検索インデックス（例えば、ウェブ検索インデックス）に一致する他のクエリ結果を含むことができる。

上記のように、アプリケーション状態は、デバイス上で稼働しているユーティリティアプリケーションについても保存されてもよい。例えば、一実施形態では、デバイスを構成するために用いられるデバイスについてのこれらの設定アプリケーションもまた、アプリケーション状態をエクスポートすることができる。ユーザインタフェース４１＿３００Ｃは、設定アプリケーションについてのアプリケーション状態を含むクエリ結果の例である。図４１－３では、ユーザインタフェース４１＿３００Ｃ、検索入力４１＿３０２Ｃは、アプリケーション状態４１＿３１４Ｂ、他のアクション４１＿３１０Ｃ、及びオンスクリーンキーボード４１＿３１２Ｃと共に表示される。一実施形態では、ユーザインタフェース４１＿３００Ａについて上記のように同じである検索入力４１＿３０２Ｃ及びオンスクリーンキーボード４１＿３１２Ｃ。それに加え、アプリケーション状態４１＿３１４Ｃは、アプリケーションアイコン４１＿３０４Ｂ、設定アプリケーションの構成要素（例えば、バッテリ使用）についてのアプリケーション状態タイトル４１＿３０６Ｃ、及び設定アプリケーションの構成要素（バッテリ使用）についてのアプリケーション状態概要４１＿３０８Ｃを含む。

上記のように、アプリケーション状態がローカル検索サービスによってアクセス可能となるために、アプリケーション状態はローカル検索サービスによってアクセス可能なインデックスに追加される。図４１－４Ａは、デバイス上の複数の異なるアプリケーションから受信されるアプリケーション状態をインデックス化するための、プロセス４１＿４００の一実施形態のフロー図である。一実施形態では、プロセス４１＿４００は、上記図４１－１にて説明したアプリケーション状態インデクサ４１＿１０４などのアプリケーション状態インデクサによって実行される。図４１－４Ａでは、プロセス４１＿４００は、ブロック４１＿４０２にてデバイス上の複数のアプリケーションから複数のアプリケーション状態を受信することから始まる。例えば、一実施形態では、プロセス４１＿４００は、ワードプロセッシングアプリケーション、スプレッドシート、連絡先、メール、電話、ウェブブラウザ、メディアプレーヤ、レビューアプリケーション、分類された広告アプリケーション、ソーシャルネットワーキング、生産性、ユーティリティ、ゲーム、不動産、写真、動画、電子商取引、出店、クーポン、オペレーティングシステム、及び／又はデバイス上で稼働することができる任意の他の種類のアプリケーションから、アプリケーション状態を受信することができる。一実施形態では、アプリケーションはアプリケーション状態を同時に、逐次的に、及び／又はその組み合わせでプロセス４１＿４００に送ることができる。ブロック４１＿４０４では、プロセス４１＿４００が受信するアプリケーション状態それぞれについて、プロセス４１＿４００はこれらのアプリケーション状態をアプリケーション状態インデックスに加える。一実施形態では、プロセス４１＿４００は、アプリケーション状態識別子、インデックス可能テキスト、アプリケーション識別子、及び／又は挿入時間を検索インデックスデータ構造に加えることによって、アプリケーション状態をアプリケーション状態インデックスに加える（例えば、転置インデックス及び完了トライ）。

複数のアプリケーション状態をアプリケーション状態インデックスに加えることにより、これらのインデックスアプリケーション状態はローカル検索サービスによるクエリ検索について利用可能である。図４１－４Ｂは、アプリケーション状態インデックスを用いてクエリについてのクエリ結果を判定するためのプロセス４５０の一実施形態のフロー図である。一実施形態では、プロセス４５０は、例えば上記図４１－２で説明したローカル検索サービス４１＿２０８など、ローカル検索サービスによって実行され、アプリケーション状態インデックスを用いて、クエリについてのクエリ結果を判定する。図４１－４Ｂでは、プロセス４５０は、ブロック４５２でクエリを受信することによって開始される。一実施形態では、クエリは、ユーザによりアプリケーション内で入力されてプロセス４５０に送られる、検索文字列である。一実施形態では、入力は、テキスト、話された言葉、自動生成、及び／又はクエリプレフィックスを入力する何かしらの他の方法によって、入力することができる。例えば、一実施形態では、ユーザはクエリをウェブブラウザ又はファイルブラウザに入力することができる。ブロック４５４で、プロセス４５０は、ローカルアプリケーション状態インデックスを用いて、クエリについてのクエリ結果のセットを判定する。一実施形態では、プロセス４５０は、クエリ内の情報を用いて、ローカルアプリケーション状態インデックス内で一致するアプリケーション状態を判定する。ブロック４５６では、プロセス４５０はクエリ結果のセットをランク付けする。一実施形態では、ランクは、クエリに一致するアプリケーション状態のそれぞれのスコアに基づく。プロセス４５０はブロック４５８にて、クエリ結果のランクセットを返す。一実施形態では、プロセス４５０がクエリ結果のランク付けされたセットを、クエリをプロセス４５０に送ったアプリケーションに送り返す。

図４１－５は、アプリケーション状態をクエリ結果の一部として受信して提示するためのプロセス４１＿５００の一実施形態のフロー図である。一実施形態では、プロセス４１＿５００は、上記図４１－２にて説明したアプリケーション４１＿２０４など、クエリ結果の一部としてアプリケーション状態を受信して提示するために、アプリケーションによって実行される。図４１－５では、プロセス４１＿５００は、ブロック４１＿５０２でローカル検索サービスにクエリを送ることから始まる。一実施形態では、クエリは、ユーザによりアプリケーション内で入力されローカル検索サービスに送られる、検索文字列であり得る。この実施形態では、入力は、テキスト、話された言葉、自動生成、連結されたデバイス（例えば、ポータブルデバイスに連結されたスマートウォッチ）から受信、及び／又は検索文字列を入力するための何らかの他の方法によって、入力することができる。別の実施形態では、クエリは検索システムから提案されてもよく、ユーザは複数の選択肢から１つのクエリを選んでもよい。あるいは、クエリはコンテキストから抽出されてもよい。例えば、一実施形態では、ユーザはテキストメッセージを読んでいて検索しに行き、クエリはデータ検出システムによって抽出されて自動的に発行される、又はユーザに提案される。更に、クエリは別のアプリケーションからのリンクを追っていくことで発行されてもよい。ブロック４１＿５０４では、プロセス４１＿５００は結果のセットを受信し、結果にはアプリケーション状態が含まれる。一実施形態では、結果のセットはランク付けされ、最上位にランキングされた結果がトップヒットとなる。ブロック４１＿５０６では、プロセス４１＿５００はユーザインタフェース内にアプリケーション状態を提示する。この実施形態では、アプリケーション状態は、アプリケーション状態タイトル、概要、及びこのアプリケーション状態についてのアプリケーションに対応するアイコンのインジケーションを含む。一実施形態では、プロセス４１＿５００はアプリケーション状態を上記の図４１－３にて説明したように表示する。アプリケーションが選択されることに応じて、プロセス４１＿５００は、選択されたアプリケーション状態を用いて対応するアプリケーションを起動する。例えば、一実施形態では、アプリケーション状態がレビュー型アプリケーションのためのローカルのレストランのレビューである場合、プロセス４１＿５００はレビュー型アプリケーションをローカルのレストランのアプリケーション状態で起動する。この例では、レビュー型アプリケーションは、ユーザに提示されたビューがレビュー型アプリケーション内のローカルのレストランのビューであるように起動される。一実施形態では、アプリケーションがデバイスにインストールされていない場合、プロセス４１＿５００はリモートソース、例えばアプリケーションストア、ウェブページ、又は他のリモートサーバなどからアプリケーションをダウンロードすることができる。この実施形態では、プロセス４１＿５００はアプリケーションをインストールし、選択されたアプリケーション状態を用いてアプリケーションを起動する。

上記のように、複数のアプリケーションが、アプリケーション状態をエクスポートすることができ、それらアプリケーション状態は、これらのアプリケーションを実行するデバイス上にローカルにインデックス化される。一実施形態では、これらのアプリケーション状態はリモートアプリケーション状態インデクサに更にエクスポートすることができ、これらのアプリケーション状態を生成しなかったデバイスからのクエリをサポートするために用いることができる。図４１－６は、リモート検索インデックスにて用いるためにアプリケーション状態をインデックス化するシステム４１＿６１８の一実施形態のブロック図である。図４１－６では、デバイス４１＿６００はリモートアプリケーション状態インデクサ４１＿６１０に連結される。一実施形態では、デバイス４１＿６００のそれぞれは、そのデバイス４１＿６００上で実行する複数のアプリケーション４１＿６０２を含み、アプリケーション４１＿６０２のそれぞれは、デバイス上のアプリケーション状態モジュール４１＿６０４に連結される。この実施形態では、アプリケーション４１＿６０２のそれぞれは、１つ以上のアプリケーション状態４１＿６１２をアプリケーション状態モジュール４１＿６０４にエクスポートする。この実施形態では、アプリケーション状態モジュール４１＿６０４は受信されたアプリケーション状態を、図４１－１～４１＿５にて上述したように、アプリケーション状態検索インデックス４１＿６０８内にインデックス化する。別の実施形態では、これらのアプリケーション状態を、リモートアプリケーション状態インデクサ４１＿６１０に送信することができる。アプリケーション状態をリモートアプリケーション状態インデクサ４１＿６１０に送信することにより、図示されていない他のデバイスからのクエリをサポートするために、これらのアプリケーション状態を利用可能とすることができる。よって、この実施形態では、複数のデバイス上で稼働している複数のアプリケーションからインデックス化されたアプリケーション状態は、これらのアプリケーション状態を生成しなかったデバイスによって送られたクエリに応じて、クエリ結果のために用いることができる。

一実施形態では、ローカルでインデックス化されたアプリケーション状態それぞれは、リモートアプリケーション状態インデクサ４１＿６１０にもエクスポートされてもよい。この実施形態では、何千、何百万ものアプリケーション状態が、生成されてリモートアプリケーション状態インデクサ４１＿６１０に送信されてもよい。しかしながら、これだけ多くのアプリケーション状態がエクスポートされてインデックス化されることで、大きすぎる及び／又は多くの役に立たない偽のエントリを有するアプリケーション状態インデックスを生成してしまう可能性がある。それに加え、エクスポートされた１ついくつか又は全てのアプリケーション状態は、インデックス化されたアプリケーション状態４１＿６１４に含まれるのに望ましくない個人情報を含む可能性がある。

一実施形態では、アプリケーション状態モジュール４１＿６０４は、これらのアプリケーション状態がデバイスと関与されている場合に、アプリケーション状態をリモートアプリケーション状態インデクサ４１＿６１０にエクスポートする。この実施形態では、アプリケーション状態をエクスポートするために、そのアプリケーション状態がデバイスのユーザによるクエリに応じたクエリ結果として返され、そのユーザがそのアプリケーション状態を選択しているかどうかを判定する。一実施形態では、アプリケーション状態をエンゲージするとは、ユーザがローカル検索サービスにクエリを送信し、ローカル検索サービスがそのアプリケーション状態をクエリ結果のセットで返し、ユーザがそのアプリケーション状態を選択又は閲覧していることを意味する。一実施形態では、アプリケーション状態をエンゲージすることは、この特定のアプリケーション状態がデバイス４１＿６００によって生成された他のアプリケーション状態よりも重要であり得ることをアプリケーション状態モジュール４１＿６０４に示す。関与されたアプリケーション状態それぞれについて、アプリケーション状態モジュール４１＿６０４はそのアプリケーション状態をリモートアプリケーション状態インデクサ４１＿６１０にエクスポートする。

更なる実施形態では、関与されたアプリケーション状態をリモートアプリケーション状態インデクサ４１＿６１０にエクスポートする前に、アプリケーション状態モジュール４１＿６０４はアプリケーション状態を、アプリケーション状態に含まれ得るすべての可能性のある個人情報を取り除くことによって、アプリケーション状態をサニタイジングする。一実施形態では、アプリケーション状態は、ユーザネーム、個人的な連絡先情報、位置、アクセス時間、社会保障番号、銀行口座番号、及び／又はアプリケーション状態内に含まれ得る任意の他の種類の個人情報を含み得る。一実施形態では、アプリケーション状態を生成するアプリケーションは、アプリケーション状態に記憶されている特定の情報を個人的であるとマーキングしてもよい。別の実施形態では、デバイスは個人情報をアプリケーション状態に加えてもよい。あるいは、アプリケーション状態モジュール４１＿６０４は、その情報がプライベートであるとマーキングされているかどうかにかかわらず、特定の情報がプライベートであることを知っていてもよい。これらの実施形態のいずれにおいても、アプリケーション状態モジュール４１＿６０４はこれらの個人情報を取り除く。

リモートアプリケーション状態インデクサ４１＿６１０は、一実施形態では、アプリケーション状態を複数のデバイス４１＿６００から受信する。リモートアプリケーション状態インデクサ４１＿６１０は、アプリケーション状態を数個のデバイスから、又は数千、数百万の多くのデバイスから、受信することができる。それに加え、一実施形態では、リモートアプリケーション状態インデクサ４１＿６１０はアプリケーション状態の２つのセットを維持する。アプリケーション状態の一方のセットは、インデックス化されたアプリケーション状態４１＿６１４である。これらはインデックス化されているアプリケーション状態のセットであり、検索サービスによって利用可能である。アプリケーション状態の他方のセットは、インデックス化されていないアプリケーション状態４１＿６１６である。一実施形態では、リモートアプリケーション状態インデクサ４１＿６１０は、アプリケーション状態が１つ以上のデバイスによって必要回数だけ関与された後に、そのアプリケーション状態をアプリケーション状態のインデックスセットに加える。例えば、一実施形態では、アプリケーション状態は、そのアプリケーション状態が５０回関与された場合にインデックスされたアプリケーション状態のセットに加えられる。代替的な実施形態では、アプリケーション状態は、そのアプリケーション状態が多かれ少なかれ関与されている場合に、アプリケーション状態のインデックスセットに加えることができる。一実施形態では、アプリケーションインデックス内にインデックス化される前にアプリケーション状態が関与されるべき必要回数は、アプリケーション状態の種類によって変動し得る。例えば、一実施形態では、地理的にローカル化された情報（例えば、地域的なクーポンのアプリケーション状態）を含むアプリケーション状態は、地理的にローカル化されている情報を含まないアプリケーション状態と対比してより少ない回数でしか関与される必要がない場合がある。

この実施形態では、アプリケーション状態を、そのアプリケーション状態が必要回数だけ関与された後にインデックス化することは、このアプリケーションが他のユーザにとって役に立つ可能性を増加させる。例えば、一実施形態では、異なるデバイス上の多くの異なるユーザがローカルの乗換アプリケーションを使用し、路線バス系統７についてのアプリケーション状態を生成する。この例では、これは人気の系統であるため、このアプリケーションはローカル検索サービスを介してこのアプリケーション状態にアクセスすることで、ユーザによって関与される。このアプリケーション状態はリモートアプリケーション状態インデクサ４１＿６１０によってインデックス化され、リモート検索サービスに利用可能となる。

一実施形態では、リモートアプリケーションインデクサ４１＿６１０は、アプリケーション状態が以前に送信されているかを、そのアプリケーション状態についてのハッシュを計算することで判定する。もしこのハッシュがリモートアプリケーションインデクサ４１＿６１０によって記憶された他のハッシュと一致する場合、リモートアプリケーションインデクサ４１＿６１０はそのアプリケーション状態がリモートアプリケーションインデクサによって受信された回数を増分させる。もし必要回数だけ受信されている場合、リモートアプリケーションインデクサ４１＿６１０はそのアプリケーション状態をインデックス化する。アプリケーション状態をインデックス化することを、以下の図４１－８にて更に説明する。

図４１－７は、リモートアプリケーション状態検索インデックスを用いてアプリケーション状態を検索するシステムの一実施形態のブロック図である。図４１－７では、デバイス４１＿７０２はリモートアプリケーション状態検索サービス４１＿７１４に連結される。一実施形態では、デバイス４１＿７０２は、ローカル検索サービス４１＿７０８に連結されるアプリケーション４１＿７０４を含む。ローカル検索サービス４１＿７０８は、アプリケーション状態検索インデックス４１＿７１６に更に連結される。一実施形態では、デバイス４１＿７０２、アプリケーション４１＿７０４、ローカル検索サービス４１＿７０８、及びアプリケーション状態検索インデックス４１＿７１６は、上記図４１－２にて説明したデバイス、アプリケーション、ローカル検索サービス、及びアプリケーション状態検索インデックスである。別の実施形態では、ローカル検索サービス４１＿７０８はクエリをリモートアプリケーション検索サービス４１＿７１４に転送することができ、そこでリモートアプリケーション検索サービス４１＿７１４はクエリについての結果のセットがあるかを判定する。リモートアプリケーション検索サービス４１＿７１４は結果のセットをローカル検索サービス４１＿７０８に返し、ローカル検索サービス４１＿７０８はそれに続けて、アプリケーション４１＿７０４に結果のセットを返す。あるいは、アプリケーション４１＿７０４はクエリをリモートアプリケーション検索サービス４１＿７１４に送ることができ、リモートアプリケーション検索サービス４１＿７１４はそれに続けてアプリケーション４１＿７０４にクエリ結果のセットを送り返す。

上記のように、リモートアプリケーション状態検索サービス４１＿７１４はデバイス４１＿７０２からクエリを受け取り、デバイス４１＿７０２にそのクエリについてのクエリ結果のセットを返す。一実施形態では、リモートアプリケーション状態検索サービス４１＿７１４は、クエリを受信し、受信したクエリと一致するアプリケーション状態についてインデックスアプリケーション状態４１＿７１２を検索し、一致するアプリケーション状態をそれぞれスコア付けし、この結果のセットをランク付けし、ランク付けされた結果をアプリケーションに返す。アプリケーション４１＿７０４はそのアプリケーション状態を含むものの結果を表示する。一実施形態では、上記図４１－３にて説明したように、アプリケーション４１＿７０４は、アプリケーションのアイコン、アプリケーション状態タイトル、及びアプリケーション状態の概要を表示する。表示されたアプリケーション状態を選択すると、アプリケーションはそのアプリケーション状態と共にローディングされる。一実施形態では、アプリケーションは、このアプリケーション状態がこのデバイスにローカルに記憶されていた場合にユーザがこのアプリケーション状態を関与していた場合のアプリケーションの状態と同じ状態にある。

図４１－８は、アプリケーション状態をアプリケーション状態インデックスに加えるためのプロセス４１＿８００の一実施形態のフロー図である。一実施形態では、プロセス４１＿８００は、例えば上記図４１－６にて説明したアプリケーション状態エクスポータモジュール４１＿６０６などの、アプリケーション状態をアプリケーション状態インデックスに加えるアプリケーション状態エクスポータモジュールによって実行される。図４１－８では、プロセス４１＿８００は、ブロック４１＿８０２でアプリケーション状態を受信することによって始まる。一実施形態では、アプリケーション状態はプロセス４１＿８００によって、プロセス４１＿８００を実行しているデバイス上で稼働している１つ以上のアプリケーションから受信される。ブロック４１＿８０２では、プロセス４１＿８００はアプリケーション状態が関与されているかどうかを判定する。一実施形態では、アプリケーション状態は、アプリケーション状態がクエリに一致する結果のセットで返されて、ユーザがそのアプリケーション状態をアプリケーションにローディングするために選択した場合に、関与されている。アプリケーション状態が関与されていない場合、実行は上記のブロック４１＿８０２に進む。アプリケーション状態が関与されていると、プロセス４１＿８００はブロック４１＿８０６のアプリケーション状態をサニタイジングする。一実施形態では、プロセス４１＿８００は、上記図４１－６にて説明したように、アプリケーション状態に関連付けられた及び／又は記憶された個人情報を取り除くことにより、アプリケーション状態をサニタイジングする。ブロック４１＿８０８で、プロセス４１＿８００はサニタイジングされたアプリケーション状態を、リモートアプリケーション状態インデックス化サービスに送る。一実施形態では、リモートアプリケーション状態インデックス化サービスは、このアプリケーション状態をアプリケーション状態インデックスに加える可能性がある。

図４１－９は、アプリケーション状態をアプリケーション状態インデックス化サービスによってインデックス化するためのプロセス４１＿９００の一実施形態のフロー図である。一実施形態では、プロセス４１＿９００は、上記図４１－６にて説明したリモートアプリケーション状態インデクサ４１＿６１０などのような、アプリケーション状態をインデックス化するアプリケーション状態インデクサによって実行される。図４１－９では、プロセス４１＿９００は、ブロック４１＿９０２でアプリケーション状態インジケーションを受信することによって始まる。一実施形態では、アプリケーション状態インジケーションはアプリケーション状態のハッシュである。完全なアプリケーション状態を受信する代わりにアプリケーション状態ハッシュを受信することによって、プロセス４１＿９００は、アプリケーション状態が複数のクライアントにわたって一般的になるまで、又は必要回数だけ関与されるまで、アプリケーション状態を受信しない。ブロック４１＿９０４では、プロセス４１＿９００はこのアプリケーション状態の発生回数を増分させる。一実施形態では、プロセス４１＿９００はこのアプリケーション状態ハッシュのカウンタを維持する。プロセス４１＿９００がこのインジケーションを受信するのが初めての場合は、カウンタは１である。プロセス４１＿９００はブロック４１＿９０６にて、発生回数が閾値よりも大きいかどうかを判定する。一実施形態では、必要回数だけアプリケーション状態がプロセス４１＿９００によって受信されていることは、このアプリケーション状態が多数回関与されており、インデックス化されてクエリに応じるために利用可能にされるべき候補であることを意味する。例えば、一実施形態では、クーポンアプリケーションの特定のクーポンについてのアプリケーション状態は、このアプリケーション状態が５０回関与されている場合には、アプリケーション状態インデックスに利用可能にされ得る。発生回数が閾値より大きい場合、プロセス４１＿９００は、直近のアプリケーション状態インジケーションを送ったデバイスに完全なアプリケーション状態についての要求を送る。プロセス４１＿９００は、アプリケーション状態をブロック４１＿９１０で受信する。プロセス４１＿９００は、アプリケーション状態をブロック４１＿９１０でインデックス化する。アプリケーション状態をインデックス化することで、プロセス４１＿９００は、このアプリケーション状態を、クエリについての結果のセットの一部として利用可能にさせている。

別の実施形態では、アプリケーション状態インジケーションの直近の受信で完全なアプリケーション状態を要求する代わりに、プロセス４１＿９００はアプリケーション状態の最後のピースを受信してアプリケーション状態をインデックス化するまで、プロセス４１＿９００はアプリケーション状態を徐々に造り始める。例えば、一実施形態では、プロセス４１＿９００は直近のＭクライアントに、アプリケーション状態の１／Ｍ番目のプロセス９００を送信するように求める。この例では、アプリケーション状態が同じアプリケーション状態ハッシュを生成するため、これは同一のアプリケーション状態である。これは、アプリケーション状態のこれらのＭピースをプロセス４１＿９００によって結合することができることを意味する。この実施形態は、アプリケーション状態の一部が毎回送信され、それによって、プロセス４１＿９００が完全なアプリケーション状態を造ることを可能にするため、追加のプライバシーをもたらし得る。

図４１－１０は、アプリケーション状態インデックスを用いてクエリ検索を実行するための、プロセス４１＿１０００の一実施形態のフロー図である。一実施形態では、プロセス４１＿１０００は、例えば上記図４１－７にて説明したリモートアプリケーション状態検索サービス４１＿７１４などのように、リモートアプリケーション状態検索サービスによって、アプリケーション状態インデックスを用いてクエリ検索を実行するために実行される。図４１－１０では、プロセス４１＿１０００は、ブロック４１＿１００２でクライアントからクエリを受信することにより、始まる。一実施形態では、クエリは、ユーザによってアプリケーション内で入力され、上記のようにリモート検索サービスに送られる、検索文字列である。ブロック４１＿１００４では、プロセス４１＿１０００はアプリケーション状態インデックスを、クエリを用いて検索する。一実施形態では、プロセス４１＿１０００は、クエリに一致する任意のアプリケーション状態があるかどうかを判定する。プロセス４１＿１０００は、ブロック４１＿１００６にて、クエリについての結果のセットを判定する。一実施形態では、結果のセットは、クエリ内の一部又は全てのテキストに一致する１つ以上のアプリケーション状態を含む。ブロック４１＿１００８では、プロセス４１＿１０００は結果のセットをランク付けする。一実施形態では、プロセス４１＿１０００は、結果のそれぞれについてスコアを判定して、これらのスコアを用いてこれらの結果をランク付けすることで、結果のセットをランク付けする。ブロック４１＿１０１０では、プロセス４１＿１０００は、結果のセットを他の検索ドメインからの結果と組み合わせる。一実施形態では、検索が、異なるインデックスを検索するのに同じクエリが使用される統合検索である場合、プロセス４１＿１０００は他の検索ドメインからの結果を、アプリケーション状態インデックスを用いて判定される結果のセットと組み合わせる。例えば、一実施形態では、クエリは、アプリケーション状態インデックス、一般ウェブ検索インデックス、及び／又は様々なインデックス（例えば、メディアインデックス、アプリケーションストアインデックス、マップインデックス、オンライン百科事典インデックス、及び／又は別の種類のインデックス）を検索するために用いられてもよい。ブロック４１＿１０１２では、プロセス４１＿１０００はランク付けされた結果を、ブロック４１＿１０１０にて生成された他の結果と一緒に、クライアントに返す。

図４１－１１は、クエリ結果の一部としてアプリケーション状態を受信して提示するためのプロセス４１＿１１００の一実施形態のフロー図である。一実施形態では、プロセス４１＿１１００は、上記図４１－７にて説明するアプリケーション４１＿７０４などのような、クエリ結果の一部としてアプリケーション状態を受信して提示するアプリケーションによって、実行される。図４１－１１では、プロセス４１＿１１００は、ブロック４１＿１１０２でリモート検索サービスにクエリを送ることから始まる。一実施形態では、クエリは、ユーザによりアプリケーション内で入力され、リモート検索サービスに送られる検索文字列であり得る。この実施形態では、入力は、テキスト、話された言葉、自動生成、連結されたデバイス（例えば、ポータブルデバイスに連結されたスマートウォッチ）から受信、及び／又は検索文字列を入力するための何らかの他の方法によって、入力することができる。ブロック４１＿１１０４で、プロセス４１＿１１００は結果のセットを受信し、結果にはアプリケーション状態が含まれる。この実施形態では、アプリケーション状態は、上記図４１－６にて説明するように、ユーザによって必要回数だけ関与されている、サニタイジングされたアプリケーション状態である。一実施形態では、結果のセットはランク付けされ、最上位にランキングされた結果がトップヒットとなる。ブロック４１＿１１０６で、プロセス４１＿１１００はユーザインタフェース内にアプリケーション状態を提示する。この実施形態では、アプリケーション状態は、アプリケーション状態タイトル、概要、及びこのアプリケーション状態についてのアプリケーションに対応するアイコンのインジケーションを含む。一実施形態では、プロセス４１＿１１００はアプリケーション状態を上記図４１－２にて説明したように表示する。アプリケーションが選択されることに応じて、プロセス４１＿１１００は、選択されたアプリケーション状態を用いて対応するアプリケーションを起動する。例えば、一実施形態では、アプリケーション状態がレビュー型アプリケーションのためのローカルレストランのレビューである場合、プロセス４１＿１１００はレビュー型アプリケーションをローカルのレストランアプリケーション状態で起動する。この例では、レビュー型アプリケーションは、ユーザに提示されたビューがレビュー型アプリケーション内のローカルのレストランのレビューであるように起動される。一実施形態では、アプリケーションがデバイスにインストールされていない場合、プロセス４１＿１１００はリモートソース、例えばアプリケーションストア、ウェブページ、又は他のリモートサーバなどからダウンロードすることができる。この実施形態では、プリセス４１＿１１００はアプリケーションをインストールし、選択されたアプリケーション状態を用いてアプリケーションを起動する。

図４１－１２は、リモート検索インデックスにて用いるためにアプリケーション状態ビューをインデックス化するシステム４１＿１２００の一実施形態のブロック図である。図４１－１２では、デバイス４１＿１２０２はアプリケーション状態記憶４１＿１２０６及びアプリケーション状態インデックス４１＿１２０８に連結される。一実施形態では、デバイス４１＿１２０２はアプリケーション状態記憶４１＿１２０６に記憶されるアプリケーション状態を取り出し、アプリケーション状態それぞれについて、デバイス４１＿１２０２はそれらのアプリケーション状態それぞれについてビューを生成する。一実施形態では、アプリケーション状態のビューは、そのアプリケーション状態に対応するアプリケーションのユーザインタフェースの表現である。例えば、一実施形態では、ユーザインタフェースは、テキスト、画像、動画、音声、アニメーション、グラフィックス、及び／又は他の種類のユーザインタフェース構成要素を含むことができる。この例では、対応するビューはユーザインタフェースの２次元の表現である。一実施形態では、１つのアプリケーションは、このアプリケーションに関連付けられる異なるアプリケーション状態に基づいて生成される複数の異なるビューを有し得る。例えば、一実施形態では、ビジネス及びサービスについて何千、何百万のレビューのコンテンツにアクセスのあるレビュータイプのアプリケーションは、何千、何百万ものレビューのそれぞれについてビューを有することができる。ビューを、以下の図４１－１３で更に説明する。

一実施形態では、アプリケーション状態記憶４１＿１２０６に記憶されるアプリケーション状態は、図４１－６にて上述したように、ユーザによって必要回数だけ関与されているアプリケーション状態であってもよい。あるいは、アプリケーション状態記憶４１＿１２０６はインデックス化されていないアプリケーション状態をも含み得る。それに加え、アプリケーション状態インデックス４１＿１２０８は、それらのアプリケーション状態について生成されたビューを有する、インデックス化されたアプリケーション状態を含む。この実施形態では、これらのビューを、クエリの結果のセットの一部として、アプリケーション状態と共に返すことができる。サーチエンジン４１＿１２１０は、デバイス４１＿１２１４からのクエリを受信するアプリケーション状態検索サービス４１＿１２１２を含む。アプリケーション状態検索サービス４１＿１２１２はデバイス４１＿１２１４からクエリを受信し、これらのクエリを用いてアプリケーション状態インデックスを検索し、関連付けられたビューを有するクエリについて一致するアプリケーション状態を判定し、一致するアプリケーション状態をスコア付けし、一致するアプリケーション状態をランク付けし、これらの一致するアプリケーション状態を元のクエリを送ってきたデバイスに結果のセットとして返す。

上記のとおり、アプリケーション状態は関連付けられたビューを有することができる。図４１－１３は、アプリケーション状態ビュー４１＿１３０２の一実施形態のブロック図である。図４１－１３では、特定のアプリケーション状態にあるアプリケーションがデバイス４１＿１３００で実行されている。このアプリケーション状態にあるアプリケーションは、アプリケーション状態ユーザインタフェース４１＿１３０２を表示する。アプリケーション状態ユーザインタフェース４１＿１３０２は、アイコン、テキスト、画像、動画、音声、アニメーション、グラフィックス、及び／又は他の種類のユーザインタフェース構成要素などの多種多様な構成要素を含むことができる。例えば、一実施形態では、アプリケーション状態ユーザインタフェース４１＿１３０２は、画像４１＿１３０４、テキスト４１＿１３０６、及びアイコン４１＿１３０８を含む。一実施形態では、ビューは、このアプリケーション状態ユーザインタフェース４１＿１３０２から生成することができる。この環境では、ビューは、アプリケーション状態インデックス内でこのアプリケーション状態と共に保存及びインデックス化されることができるアプリケーション状態ユーザインタフェース４１＿１３０２の表現である。例えば、一実施形態では、アプリケーション状態ユーザインタフェース４１＿１３０２についてのビューは、２次元画像、例えばＧＩＦ、ＪＰＥＧ、ＰＮＧ、及び／又は他の種類の２次元画像などである。この例では、ビューの２次元画像は、アプリケーション状態インデックス内にアプリケーション状態と共に記憶され得る。

図４１－１４は、アプリケーション状態インデックスを用いてアプリケーション状態ビューを生成するための、プロセス４１＿１４００の一実施形態のフロー図である。一実施形態では、プロセス４１＿１４００は、例えば上記図４１－１２にて説明するアプリケーション状態ビュージェネレータ及びインデクサ４１＿１２０４など、アプリケーション状態ビュージェネレータ及びインデクサによって、アプリケーション状態を用いてアプリケーション状態ビューを生成するために実行される。図４１－１４では、プロセス４１＿１４００は、ブロック４１＿１４０２でアプリケーション状態を受信することから始まる。一実施形態では、プロセス４１＿１４００は、上記図４１－１２にて説明するアプリケーション状態記憶４１＿１２０６など、アプリケーション状態記憶からアプリケーション状態を受信する。ブロック４１＿１４０４では、プロセス４１＿１４００は、このアプリケーション状態を用いてアプリケーション状態ビューを生成する。一実施形態では、プロセス４１＿１４００は、そのアプリケーション状態を用いてアプリケーションをシミュレーションすることでアプリケーション状態ビューを生成する。この実施形態では、アプリケーションは、このアプリケーション状態を有するシミュレータにて実行される。プロセス４１＿１４００は、シミュレータのプライベートフレームワークを用いてこのアプリケーション状態についてのアプリケーションユーザインタフェースをキャプチャすることができる。あるいは、プロセス４１＿１４００は、仮想プラットフォーム又はデバイス自体にアプリケーションをローディングし、そのアプリケーション状態のビューを生成する機構を用いてもよい。ブロック４１＿１４０６で、プロセス４１＿１４００はアプリケーション状態ビューを、対応するアプリケーション状態について、アプリケーション状態インデックスに追加する。

これらのアプリケーション状態ビューを生成することにより、プロセス４１＿１４００は１つ以上のアプリケーションについて多数のビューを生成することができる。それらのビューを用いて、アプリケーション状態及びアプリケーション一般もプレビューすることができる。一実施形態では、これらのアプリケーション状態ビューを用いて、クエリに対する結果のセットで返されたアプリケーション状態をプレビューすることができｒ、又はアプリケーションを一般的にプレビューすることができる。クエリと共にビューを使用することを、以下の図４１－１５にて更に説明する。一実施形態では、１つのアプリケーションについて多数のアプリケーション状態ビューを収集することを用いて、そのアプリケーションをプレビューすることができる。例えば、一実施形態では、レビュー型アプリケーションは、このアプリケーションについて利用可能な数十ものアプリケーション状態ビューを有していてもよい。例えばこのアプリケーションをアプリケーションストアで閲覧している、このレビュー型アプリケーションに興味のある人のために、これらのアプリケーション状態ビューを利用可能としてもよく、それによって、ユーザがアプリケーションを購入／ダウンロードする前にアプリケーションをプレビューできる。この例では、ユーザは、アプリケーションがどんなふうに見えるのかのアイデアをつかむために、何十ものビューを前後にざっと見てもよい。

図４１－１５は、クエリ結果の一部としてアプリケーション状態ビューを含むアプリケーション状態を受信して提示するためのプロセス４１＿１５００の一実施形態のフロー図である。一実施形態では、プロセス４１＿１５００は、上記図４１－１２にて説明したデバイス４１＿１２１４などの、クエリ結果の一部としてアプリケーション状態ビューを受信して提示するデバイスによって実行される。図４１－１５では、プロセス４１＿１５００は、ブロック４１＿１５０２でリモート検索サービスにクエリを送ることから始まる。一実施形態では、クエリは、ユーザによりアプリケーション内で入力され、リモート検索サービスに送られる、検索文字列であり得る。この実施形態では、入力は、テキスト、話された言葉、自動生成、連結されたデバイス（例えば、ポータブルデバイスに連結されたスマートウォッチ）から受信、及び／又は検索文字列を入力するための何らかの他の方法によって、入力することができる。ブロック４１＿１５０４では、プロセス４１＿１５００は結果のセットを受信し、結果にはアプリケーション状態が含まれる。この実施形態では、アプリケーション状態は、上記図４１－６にて説明するように、ユーザによって必要回数だけ関与されている、サニタイジングされたアプリケーション状態である。一実施形態では、結果のセットはランク付けされ、最上位にランキングされた結果がトップヒットとなる。ブロック４１＿１５０６では、プロセス４１＿１５００はユーザインタフェース内にアプリケーション状態を提示する。この実施形態では、アプリケーション状態は、アプリケーション状態タイトル、概要、このアプリケーション状態についてのアプリケーションに対応するアイコンのインジケーション、及び対応するアプリケーションビューの利用可能性のインジケーションを含む。アプリケーション状態ビューが選択されたことに応じて、プロセス４１＿１５００はアプリケーション状態ビューを取り出して提示する。一実施形態では、アプリケーション状態ビューを表示することで、ユーザはこのアプリケーション状態にて実行されるアプリケーションのプレビューを得ることができる。これは、そのアプリケーション状態を選択するかどうかを判断する上でユーザの助けとなり得る。別の実施形態では、ビューをプレビューすることは、アプリケーションがデバイス上にインストールされていたとしても、このアプリケーション状態でアプリケーションを起動するよりも早い可能性がある。例えば、一実施形態では、アプリケーション状態ビューがレビュー型アプリケーションについてのローカルのレストランのレビューである場合、プロセス４１＿１５００はアプリケーション状態ビューを取り出して表示する。
アプリ内検索のクライアント、サーバ、ウェブ態様のための例示的な機械可読媒体、方法、及びシステム

一態様では、複数のアプリケーション状態を用いて検索を実行するデバイスの方法及び装置を提供し、説明する。例示的な実施形態では、デバイスは、デバイス上で稼働する複数のアプリケーションから複数のアプリケーション状態を受信する。デバイスは更に、複数のアプリケーション状態のインデックスを作成する。それに加え、デバイスは、デバイス上に記憶されたデータを検索するクエリを受信する。更に、デバイスは、複数のアプリケーション状態を、インデックス及びクエリを用いて検索する。デバイスは更に、複数のアプリケーション状態のうちの１つのクエリについての一致を判定し、その一致するアプリケーション状態についての一致を返す。

一部の実施形態では、複数のアプリケーション状態を用いて検索を実行する方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体が提供され、方法は、デバイス上で稼働している複数のアプリケーションから複数のアプリケーション状態を受信することと、複数のアプリケーション状態の、デバイス上に記憶されるインデックスを作成することと、デバイス上に記憶されたデータを検索するクエリを受信することと、複数のアプリケーション状態を、インデックス及びクエリを用いて検索することと、複数のアプリケーション状態のうちの１つのクエリについての一致を判定することと、その一致するアプリケーション状態についての一致を返すことと、を含む。一部の実施形態では、複数のアプリケーション状態のそれぞれは、そのアプリケーション状態についてのアプリケーションのある時点のスナップショットを表すデータを含む。一部の実施形態では、複数のアプリケーションのうちの１つについて複数のアプリケーション状態がある。一部の実施形態では、クエリは、複数のアプリケーション状態の検索に加えて、デバイス上に保存されたファイルを検索するために用いられる。一部の実施形態では、複数のアプリケーション状態のうちの１つは、複数のアプリケーションのうちの対応する１つによって用いられたユーザインタフェースデータのビュー位置を表すユーザインタフェース情報を含む。

一部の実施形態では、複数のアプリケーション状態を用いてクエリを実行する方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体が提供され、方法は、デバイス上に記憶されたインデックスを用いてデバイス上でクエリを実行することと、クエリに一致する複数の結果を受信することと、デバイス上にインストールされているネイティブアプリケーションに対応するアプリケーション状態に対応する複数の結果のサブセットを判定することと、複数の結果のサブセット内の結果のそれぞれについて、その結果と、その結果に対応するネイティブアプリケーションの表現とを提示することと、を含む。

別の態様では、マルチデバイス検索内において用いられるアプリケーション状態を選択するデバイスの方法及び装置を提供する。この実施形態では、デバイスは、デバイス上において、アプリケーション状態が、そのデバイスのデバイスレベルでの検索についてのクエリ結果として選択されていることを検出する。デバイスは更にアプリケーション状態をサーバに送信し、そこでアプリケーション状態は、他のデバイスからの他のアプリケーション状態と一緒にインデックス化される。一部の実施形態では、マルチデバイス検索において用いるためのアプリケーション状態を選択するための方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体を提供し、方法は、デバイス上にて、アプリケーション状態が、そのデバイス上のデバイスレベルでの検索についてのクエリ結果として選択されていることを検出することと、アプリケーション状態をサーバに送信することと、を含み、そのアプリケーション状態は、他のデバイスからの他のアプリケーション状態と共にインデックス化される。

一部の実施形態では、第２のデバイスから受信したアプリケーション状態を用いて第１のデバイスについての検索を実行する方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体が提供され、方法は、デバイス上で稼働している複数のアプリケーションから複数のアプリケーション状態を受信することと、複数のアプリケーション状態のインデックスを作成することと、デバイス上に記憶されたデータを検索するクエリを受信することと、複数のアプリケーション状態を、インデックス及び検索クエリを用いて検索することと、複数のアプリケーション状態のうちの１つの検索クエリについての一致を判定することと、その一致するアプリケーション状態についての一致を返すことと、を含む。一部の実施形態では、インデックスを作成することは、複数のアプリケーション状態のうちの１つを、そのアプリケーション状態が閾値を満たす回数だけ受信されている場合に、インデックスに加えることを含む。一部の実施形態では、検索を実行する方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体が提供され、方法は、デバイスからサーバにクエリを送信することと、クエリに一致する複数の結果を受信することと、デバイス上にインストールされているネイティブアプリケーションに対応する別のデバイスで生成されたアプリケーション状態をそれぞれ含む複数の結果のサブセットを判定することと、複数の結果のサブセットにおける結果のそれぞれについて、ネイティブアプリケーションのリンク及び表現を提示することと、を含む。

１つ以上の態様では、検索クエリインデックス内にアプリケーション状態をインデックス化する、デバイスの方法及び装置を提供する。この実施形態では、サーバと連結される別のデバイスからアプリケーションのアプリケーション状態を受信する。デバイスは更に、アプリケーション状態に対応するアプリケーションのビューを生成し、このビューは、アプリケーション状態に対応する、アプリケーションのユーザインタフェースの表現である。それに加え、デバイスはビューを検索クエリインデックス内にインデックス化する。一部の実施形態では、検索クエリインデックス内にアプリケーション状態ビューをインデックス化する方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体が提供され、方法は、サーバを用いて、サーバと連結されたデバイスからアプリケーションのアプリケーション状態を受信することと、アプリケーション状態に対応するアプリケーションのビューを生成することであって、ビューが、アプリケーション状態に対応する、アプリケーションのユーザインタフェースの表現である、ことと、検索クエリインデックス内にそのビューをインデックス化することと、を含む。一部の実施形態では、ビューを、アプリケーション状態についてのインデックスエントリにリンクすることを更に含む。一部の実施形態では、インデックスエントリはインデックスの一部であり、インデックスは、サーバに連結された複数のデバイスから得られた複数のアプリケーションについてのアプリケーション状態の複数のインデックスエントリを含む。一部の実施形態では、アプリケーション状態は、そのアプリケーション状態についてのアプリケーションのある時点のスナップショットを表すデータを含む。一部の実施形態では、インデックスエントリは、タイトル、検索可能データ、及びアプリケーション特有の不透明データの群から選択された情報を含む。一部の実施形態では、ビューは画像である。一部の実施形態では、ビューは複数のフレームを有する画像である。一部の実施形態では、上記の生成することは、アプリケーションを仮想デバイス上で実行することと、アプリケーション状態に対応するアプリケーションのユーザインタフェースのスクリーン画像をキャプチャすることと、を含む。一部の実施形態では、上記の生成することは、アプリケーションをアプリケーション状態でシミュレーションすることと、アプリケーション状態に対応するアプリケーションのユーザインタフェースのスクリーン画像をキャプチャすることと、を含む。

一部の実施形態では、クエリ結果と関連付けられたビューを有するアプリケーション状態を取り出すための方法を１つ以上の処理ユニットに実行させる実行可能な命令を有する機械可読媒体が提供され、方法は、サーバにクエリを送信することと、サーバからクエリへの結果を受信することであって、結果が、結果に対応するアプリケーションのアプリケーション状態のビューを含み、ビューがアプリケーション状態に対応するアプリケーションのユーザインタフェースの表現である、ことと、ビューのインジケーションと共に結果を提示することと、を含む。一部の実施形態では、ユーザによるジェスチャに応じてビューを提示することを更に含む。
例示的な電子デバイスの機能ブロック図

一部の実施形態によれば、図４２は、説明される様々な実施形態の原理に従って構成された、電子デバイス４２００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４２で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４２００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４２に示すように、電子デバイス４２００は、情報を表示するように構成されたディスプレイユニット４２０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、接触、ジェスチャ、及びタッチスクリーンディスプレイ上での他のユーザ入力を受信するように構成されたタッチ感知面ユニット４２０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット４２０１及びタッチ感知面ユニット４２０３に連結された処理ユニット４２０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４２は、ディスプレイユニット４２０１及びタッチ感知面ユニット４２０３を電子デバイス４２００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと物理的に分離された状態であるが、電子デバイスと通信状態にある。一部の実施形態では、処理ユニットは、実行ユニット（例えば、実行ユニット４２０７、図４２）と、収集ユニット（例えば、収集ユニット４２０９、図４２）と、取得ユニット（例えば、取得ユニット４２１１、図４２）と、関連付けユニット（例えば、関連付けユニット４２１３、図４２）と、提供ユニット（例えば、提供ユニット４２１５、図４２）と、送信ユニット（例えば、送信ユニット４２１７、図４２）と、受信ユニット（例えば、受信ユニット４２１９、図４２）と、表示ユニット（例えば、表示ユニット４２２１、図４２）と、検出ユニット（例えば、検出ユニット４２２３、図４２）と、実施ユニット（例えば、実施ユニット４２２５、図４２）と、判定ユニット（例えば、判定ユニット４２２７、図４２）と、監視ユニット（例えば、監視ユニット４２２９、図４２）と、を含む。

一部の実施形態では、処理ユニット４２０５（又は、ユニット４２０７～４２２９などの、その１つ以上の構成要素）は、電子デバイス上で、電子デバイスのユーザからの命令に応じてアプリケーションを（例えば、実行ユニット４２０７を用いて）実行し、アプリケーションを実行している間、ユーザによってアプリケーション内で実行された１つ以上のアクションを少なくとも含む使用データを（例えば、収集ユニット４２０９を用いて）収集し、自動的に、人の介入なしに、収集された使用データに基づいて少なくとも１つのトリガー条件を（例えば、取得ユニット４２１１を用いて）取得し、その少なくとも１つのトリガー条件を、ユーザによってアプリケーション内で実行される１つ以上のアクションのうちの特定のアクションと（例えば、関連付けユニット４２１３を用いて）関連付け、少なくとも１つのトリガー条件が満たされていると判定すると、ユーザに、トリガー状態に関連付けられた特定のアクションが利用可能であることのインジケーションを（例えば、提供ユニット４２１５を用いて）提供するように、構成される。電子デバイス４２００の一部の実施形態では、処理ユニット（又は、ユニット４２０７～４２２９などの、その１つ以上の構成要素）は、「概要」セクションにて上述したように、Ａ２～Ａ２２の任意の１つの方法を実行するように更に構成される。

一部の実施形態によれば、図４３は、説明される様々な実施形態の原理に従って構成された、電子デバイス４３００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４３で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４３００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４３に示すように、電子デバイス４３００は、情報を表示するように構成されたディスプレイユニット４３０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４３０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット４３０１及びタッチ感知面ユニット４３０３に連結された処理ユニット４３０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４３は、ディスプレイユニット４３０１及びタッチ感知面ユニット４３０３を電子デバイス４３００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。一部の実施形態では、処理ユニットは、表示ユニット（例えば、表示ユニット４３０９、図４３）と、検出ユニット（例えば、検出ユニット４３０７、図４３）と、取出しユニット（例えば、取出しユニット４３１１、図４３）と、ポピュレートユニット（例えば、ポピュレートユニット４３１３、図４３）と、スクロールユニット（例えば、スクロールユニット４３１５、図４３）と、顕示化ユニット（例えば、顕示化ユニット４３１７、図４３）と、選択ユニット（例えば、選択ユニット４３１９、図４３）と、連絡ユニット（例えば、連絡ユニット４３２１、図４３）と、受信ユニット（例えば、４３２３、図４３）と、実行ユニット（例えば、実行ユニット４３２５、図４３）と、を含む。

一部の実施形態では、処理ユニット４３０５（又は、ユニット４３０７～４３２９などの、その１つ以上の構成要素）は、電子デバイスのユーザからのタッチ感知ディスプレイ上の検索アクティブ化ジェスチャを（例えば、検出ユニット４３０７及び／又はタッチ感知面ユニット４３０３を用いて）検出し、検索アクティブ化ジェスチャを検出したことに応じて、タッチ感知ディスプレイ上に、（ｉ）検索エントリ部分、及び（ｉｉ）検索エントリ部分にて何らかのユーザを受信する前に表示される予測部分、を含む検索インタフェースを、（例えば、表示ユニット４３０９及び／又はディスプレイユニット４３０１を用いて）表示するように構成され、予測部分は、（ａ）複数の以前に連絡している人のうちのある人に連絡するための少なくとも１つのアフォーダンスであって、当該人は複数の以前に連絡した人から、少なくとも部分的に現在時刻に基づいて（例えば、選択ユニット４３１９によって）自動的に選択される、少なくとも１つのアフォーダンスと、（ｂ）電子デバイス上で利用可能な複数のアプリケーションのうちのあるアプリケーション内で予測されたアクションを実行するための少なくとも１つのアフォーダンスであって、予測されたアクションは、電子デバイスのユーザに関連付けられたアプリケーションの使用履歴に少なくとも部分的に基づいて（例えば、選択ユニット４３１９によって）自動的に選択される、少なくとも１つのアフォーダンス、の１つ以上でポピュレートされる。電子デバイス４３００の一部の実施形態では、処理ユニット（又は、ユニット４３０７～４３２５などの、その１つ以上の構成要素）は、「概要」セクションにて上述したように、Ｃ２～Ｃ１８の任意の１つの方法を実行するように更に構成される。

一部の実施形態によれば、図４４は、説明される様々な実施形態の原理に従って構成された、電子デバイス４４００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４４で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４４００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４４に示すように、電子デバイス４４００は、情報を表示するように構成されたディスプレイユニット４４０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４４０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット４４０１及びタッチ感知面ユニット４４０３に連結された処理ユニット４４０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４４は、ディスプレイユニット４４０１及びタッチ感知面ユニット４４０３を電子デバイス４４００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。一部の実施形態では、処理ユニットは、検出ユニット（例えば、検出ユニット４４０７、図４４）と、表示ユニット（例えば、表示ユニット４４０９、図４４）と、取出しユニット（例えば、取出しユニット４４１１、図４４）と、検索モード移行ユニット（例えば、検索モード移行ユニット４４１２、図４４）と、ポピュレートユニット（例えば、ポピュレートユニット４４１３、図４４）と、取得ユニット（例えば、取得ユニット４４１５、図４４）と、判定ユニット（例えば、判定ユニット４４１７、図４４）と、選択ユニット（例えば、選択ユニット４４１９、図４４）と、を含む。

処理ユニット４４０５（又は、ユニット４４０７～４４１９などの、その１つ以上の構成要素）は、ディスプレイユニット（例えば、ディスプレイユニット４４０１）上に、電子デバイス上で実行しているアプリケーションに関連付けられたコンテンツを（例えば、表示ユニット４４０９及び／又はディスプレイユニット４４０１を用いて）表示し、タッチ感知面ユニット（例えば、タッチ感知面ユニット４４０３）を介して、検出されたときに電子デバイスにアプリケーションとは異なる検出モードへと移行するようにさせるスワイプジェスチャを（例えば、検出ユニット４４０７及び／又はタッチ感知面ユニット４４０３を用いて）検出し、スワイプジェスチャを検出したことに応じて、ディスプレイユニット（例えば、ディスプレイユニット４４０７）上に表示される検索インタフェースを含む検索モードへと（例えば、検索モード移行ユニット４４１１を用いて）移行し、検索モードへと移行することに伴って、少なくとも１つの提案された検索クエリを少なくとも部分的にコンテンツと関連付けられた情報に基づいて（例えば、判定ユニット４４１７を用いて）判定し、検索インタフェースで何らかのユーザ入力を受信する前に、少なくとも１つの提案された検索クエリで表示された検索インタフェースを（例えば、ポピュレートユニット４４１３を用いて）ポピュレートするように、構成される。電子デバイス４４００の一部の実施形態では、処理ユニット（又は、ユニット４４０７～４４１９などの、その１つ以上の構成要素）は、「概要」セクションにて上述したように、Ｄ２～Ｄ１６の任意の１つの方法を実行するように更に構成される。

一部の実施形態によれば、図４５は、説明される様々な実施形態の原理に従って構成された、電子デバイス４５００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４５で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４５００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４５に示すように、電子デバイス４５００は、情報を表示するように構成されたディスプレイユニット４５０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４５０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット４５０１及びタッチ感知面ユニット４５０３に連結された処理ユニット４５０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４５は、ディスプレイユニット４５０１及びタッチ感知面ユニット４５０３を電子デバイス４５００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。一部の実施形態では、処理ユニットは、検出ユニット（例えば、検出ユニット４５０７、図４５）と、表示ユニット（例えば、表示ユニット４５０９、図４５）と、ポピュレートユニット（例えば、ポピュレートユニット４５１１、図４５）と、検索モード移行ユニット（例えば、検索モード移行ユニット４５１３、図４５）と、を備える。

処理ユニット４５０５（又は、ユニット４２０７～４２２９などの、その１つ以上の構成要素）は、タッチ感知面ユニット（例えば、タッチ感知面４５０３）を介して、検出されたときに電子デバイスに検索モードへと移行させる、ユーザインタフェース上のスワイプジェスチャを（例えば、検出ユニット４５０７及び／又はタッチ感知面ユニット４５０３を用いて）検出し、スワイプジェスチャを検出したことに応じて、（例えば、検索モード移行ユニット４５１３を用いて）検索モードへと移行するように構成され、検索モードへと移行することは、検索インタフェースインタフェース内に何らかのユーザ入力を受信する前に、ユーザインタフェースとは異なる検索インタフェースインタフェースを、第１のコンテンツアイテムで（例えば、ポピュレートユニット４５１１及び／又は表示ユニット４５０９及び／又はディスプレイユニット４５０１を用いて）ポピュレートすることを含む。一部の実施形態では、ユーザインタフェースが、アプリケーションを呼び出すための選択可能なアイコンを含むホームスクリーンとは異なる、アプリケーションに関連付けられたコンテンツを含むという判定に従って、検索インタフェースインタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースインタフェースを、アプリケーションに関連付けられたコンテンツに少なくとも部分的に基づく少なくとも１つの提案される検索クエリで（例えば、ポピュレートユニット４５１１を用いて）ポピュレートすることを含み、ユーザインタフェースがホームスクリーンのあるページと関連付けられているとの判定に従って、検索インタフェースインタフェースを第１のコンテンツアイテムでポピュレートすることは、検索インタフェースインタフェースを、電子デバイスの現在の位置の閾値距離内にある少なくとも１つの対象地点の選択可能な説明を含むアフォーダンスで（例えば、ポピュレートユニット４５１１を用いて）ポピュレートすることを含む。電子デバイス４５００の一部の実施形態では、処理ユニット（又は、ユニット４５０７～４５１３などの、その１つ以上の構成要素）は、「概要」セクションにて上述したような、Ｅ２の方法を実行するように更に構成される。

一部の実施形態によれば、図４６は、説明される様々な実施形態の原理に従って構成された、電子デバイス４６００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４６で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４６００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４６に示すように、電子デバイス４６００は、情報を表示するように構成されたディスプレイユニット４６０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４６０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、電子デバイスについての位置情報を取得するように構成された位置センサユニット４６０７と、ディスプレイユニット４６０１、タッチ感知面ユニット４６０３、及び位置センサユニット４６０７に連結された処理ユニット４６０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４６は、ディスプレイユニット４６０１及びタッチ感知面ユニット４６０３を電子デバイス４６００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。一部の実施形態では、処理ユニットは、表示ユニット（例えば、表示ユニット４６０９、図４６）と、取出しユニット（例えば、取出しユニット４６１１、図４６）と、判定ユニット（例えば、判定ユニット４６１３、図４６）と、記憶ユニット（例えば、記憶ユニット４６１５、図４６）と、特定ユニット（例えば、特定ユニット４６１７、図４６）と、選択ユニット（例えば、選択ユニット４６１９、図４６）と、受信ユニット（例えば、受信ユニット４６２１、図４６）と、提供ユニット（例えば、提供ユニット４６２３、図４６）と、再生ユニット（例えば、再生ユニット４６２５、図４６）と、を備える。

処理ユニット４６０５（又は、ユニット４６０９～４６２５などの、その１つ以上の構成要素）は、自動的に、かつユーザからの命令なしに、電子デバイスのユーザが地理的位置に停止している車両の中にいることを（例えば、判定ユニット４６１３を用いて）判定し、ユーザがその地理的位置にて車両を離れたと判定すると、位置センサユニット（例えば、位置センサユニット４６０７）から（例えば、取出しユニット４６２１を用いて）取り出された、地理的位置を（例えば、特定ユニット４６１７を用いて）特定するための位置情報が、正確性基準を満たすかを（例えば、判定ユニット４６１３を用いて）判定し、位置情報が正確性基準を満たさないと（例えば、判定ユニット４６１３を用いて）判定すると、地理的位置についての情報を入力するようにユーザにプロンプトを（例えば、提供ユニット４６２３を用いて）提供し、プロンプトを提供したことに応じて、地理的位置についての情報をユーザから（例えば、受信ユニット４６２３を用いて）受信し、その情報を車両位置情報として（例えば、記憶ユニット４６１５を用いて）記憶するように構成される。電子デバイス４６００の一部の実施形態では、処理ユニット（又は、ユニット４６０９～４６２５などの、その１つ以上の構成要素）は、「概要」セクションにて上述したような、Ｆ２～Ｆ１６のうちの任意の１つの方法を実行するように更に構成される。

一部の実施形態によれば、図４７は、説明される様々な実施形態の原理に従って構成された、電子デバイス４７００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４７で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４７００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４７に示すように、電子デバイス４７００は、情報を表示するように構成されたディスプレイユニット４７０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４７０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、電子デバイスのために位置情報を取得するように構成された位置センサユニット４７０７と、ディスプレイユニット４７０１及びタッチ感知面ユニット４７０３に連結された処理ユニット４７０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４７は、ディスプレイユニット４７０１及びタッチ感知面ユニット４７０３を電子デバイス４７００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。一部の実施形態では、処理ユニットは、検出ユニット（例えば、検出ユニット４７０９、図４７）と、表示ユニット（例えば、表示ユニット４７１１、図４７）と、取出しユニット（例えば、取出しユニット４７１３、図４７）と、判定ユニット（例えば、判定ユニット４７１５、図４７）と、特定ユニット（例えば、特定ユニット４７１７、図４７）と、ロック解除ユニット（例えば、ロック解除ユニット４７１９、図４７）と、検索モード移行ユニット（例えば、検索ユニット移行ユニット４７２１、図４７）と、を備える。

処理ユニット４７０５（又は、ユニット４７０９～４７１９などの、その１つ以上の構成要素）は、電子デバイスのユーザからいかなる命令をも受信せずに、電子デバイスの地理的位置を、位置センサユニット（例えば、位置センサユニット４７０７）を用いて監視し、監視された地理的位置に基づいて、電子デバイスが所定の種類の対象地点の閾値距離内にあることを（例えば、判定ユニット４７１５を用いて）判定し、電子デバイスが対象地点の閾値距離内にあると判定したことに従って、対象地点で現在人気のある少なくとも１つのアクティビティを（例えば、特定ユニット４７１７を用いて）特定し、対象地点についての情報を（例えば、取出しユニット４７１３を用いて）取り出し、この取り出すことは、対象地点で現在人気の少なくとも１つのアクティビティについての情報を取り出すことを含み、タッチ感知面ユニット（例えば、タッチ感知面ユニット４７０３）を介して、検出されたときに電子デバイスを検索モードへと移行させる第１の入力を（例えば、検出ユニット４７０９及び／又はタッチ感知面ユニット４７０３を用いて）検出し、第１の入力を検出したことに応じて、（例えば、検索モード移行ユニット４７２１を用いて）検索モードへと移行するように構成され、検索モードへと移行することは、検索インタフェースで何らかのユーザ入力を受信する前に、（ｉ）少なくとも１つのアクティビティについての情報、及び（ｉｉ）少なくとも１つのアクティビティが対象地点で現在人気があると特定されているというインジケーション、を含むアフォーダンスを、表示ユニット（例えば、表示ユニット４７０１）を介して（例えば、表示ユニット４７１１及び／又はディスプレイユニット４７０１を用いて）提示することを含む。電子デバイス４７００の一部の実施形態では、処理ユニット（又は、ユニット４７０９～４７１９などの、その１つ以上の構成要素）は、「概要」セクションにて上述したようなＧ２～Ｇ１０の任意の１つの方法を実行するように更に構成される。

一部の実施形態によれば、図４８は、説明される様々な実施形態の原理に従って構成された、電子デバイス４８００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４８で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４８００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４８に示すように、電子デバイス４８００は、情報を表示するように構成されたディスプレイユニット４８０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４８０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット４８０１及びタッチ感知面ユニット４８０３に連結された処理ユニット４８０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４８は、ディスプレイユニット４８０１及びタッチ感知面ユニット４８０３を電子デバイス４８００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、音声通信受信ユニット（例えば、音声通信受信ユニット４８０７、図４８）と、コンテンツアイテム抽出ユニット（例えば、コンテンツアイテム抽出ユニット４８０９、図４８）と、利用可能性判定ユニット（例えば、利用可能性判定ユニット４８１１、図４８）と、アプリケーション特定ユニット（例えば、アプリケーション特定ユニット４８１３、図４８）と、表示ユニット（例えば、表示ユニット４８１５、図４８）と、コンテンツアイテム記憶ユニット（例えば、コンテンツアイテム記憶ユニット４８１７、図４８）と、フィードバック提供ユニット（例えば、フィードバック提供ユニット４８１９、図４８）と、入力検出ユニット（例えば、入力検出ユニット４８２１、図４８）と、アプリケーションオープンユニット（例えば、アプリケーションオープンユニット４８２３、図４８）と、ポピュレートユニット（例えば、ポピュレートユニット４８２５、図４８）と、音声通信分析ユニット（例えば、音声通信分析ユニット４８２７、図４８）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット４８０７～４８２７などの、その１つ以上の構成要素）は、音声通信の少なくとも一部を（例えば、音声通信受信ユニット４８０７を用いて）受信するように構成され、音声通信の一部は、電子デバイスのユーザとは異なるリモートデバイスのリモートユーザによって提供されるスピーチを含む。処理ユニットは更に、リモートデバイスのリモートユーザによって提供されるスピーチの少なくとも一部に基づいて、コンテンツアイテムを（例えば、コンテンツアイテム抽出ユニット４８０９を用いて）抽出し、コンテンツアイテムが電子デバイス上で現在利用可能かどうかを（例えば、利用可能性判定ユニット４８１１を用いて）判定するように、構成される。コンテンツアイテムが電子デバイス上で現在利用可能でないとの判定に従って、処理ユニットは更に、（ｉ）コンテンツアイテムと関連付けられるアプリケーションを（アプリケーション特定ユニット４８１３を用いて）特定し、（ｉｉ）ディスプレイ上にコンテンツアイテムの選択可能な説明を（例えば、表示ユニット４８１５及び／又はディスプレイユニット４８０１を用いて）表示するように、構成される。選択可能な説明の選択肢を（例えば、入力検出ユニット４８２１及び／又はタッチ感知面ユニット４８０３を用いて）検出したことに応じて、処理ユニットは、特定されたアプリケーションにて提示用のコンテンツアイテムを（例えば、コンテンツアイテム記憶ユニット４８１７を用いて）記憶するように、構成される。

電子デバイス４８００の一部の実施形態では、コンテンツアイテムは新たなイベントである。

電子デバイス４８００の一部の実施形態では、コンテンツアイテムは、電子デバイス上のカレンダーアプリケーションと現在関連付けられているイベントについての新たなイベント詳細である。

電子デバイス４８００の一部の実施形態では、コンテンツアイテムは新たな連絡先である。

電子デバイス４８００の一部の実施形態では、コンテンツアイテムは、電子デバイス上の電話アプリケーションに関連付けられる既存の連絡先についての新たな連絡先情報である。

電子デバイス４８００の一部の実施形態では、音声通信は生の通話である。

電子デバイス４８００の一部の実施形態では、音声通信は生のＦａｃｅＴｉｍｅ通話である。

電子デバイス４８００の一部の実施形態では、音声通信は録音されたボイスメールである。

電子デバイス４８００の一部の実施形態では、選択可能な説明を表示することは、電話アプリケーションを用いてかけられた最近の通話を含むユーザインタフェース内に、選択可能な説明を（例えば、表示ユニット４８１５及び／又はディスプレイユニット４８０１を用いて）表示することを含む。

電子デバイス４８００の一部の実施形態では、選択可能な説明は、コンテンツアイテムが音声通信と関連付けられているとのインジケーションと共に、（例えば、表示ユニット４８１５及び／又はディスプレイユニット４８０１を用いて）表示される。

電子デバイス４８００の一部の実施形態では、選択を検出することは、最近の通話を含むユーザインタフェースが表示されている間に、（例えば、入力検出ユニット４８２１を用いて）選択を受信することを含む。

電子デバイス４８００の一部の実施形態では、処理ユニットは、コンテンツアイテムの選択可能な説明を表示することに伴って、電子デバイスのユーザにコンテンツアイテムが検出されたというフィードバックを（例えば、フィードバック提供ユニット４８１９を用いて）提供することを、更に含む。

電子デバイス４８００の一部の実施形態では、フィードバックを提供することは、コンテンツアイテムの検出に関する情報を、その電子デバイスの近傍にある異なる電子デバイスに（例えば、フィードバック提供ユニット４８１９を介して）送信することを含む。

電子デバイス４８００の一部の実施形態では、処理ユニットは、音声通信が第１の物理的位置についての情報を含むと判定し、入力を（例えば、入力検出ユニット４８２１を介して）検出し、入力を検出したことに応じて、位置データを受け付けることができるアプリケーションを開き、アプリケーションを第１の物理的位置についての情報で（例えば、アプリケーションオープンユニット４８２３を介して）ポピュレートするように、更に構成される。

電子デバイス４８００の一部の実施形態では、アプリケーションはマップアプリケーションであり、マップアプリケーションを第１の物理的位置についての情報でポピュレートすることは、マップアプリケーション内に表示されるマップを第１の物理的位置に対応する位置識別子でポピュレートすることを含む。

電子デバイス４８００の一部の実施形態では、処理ユニットは、音声通信が第１の物理的位置についての情報を含むと判定し、入力を（例えば、入力検出ユニット４８２１を介して）検出し、入力を検出したことに応じて、検索インタフェースを第１の物理的位置についての情報で（例えば、ポピュレートユニット４８２５を介して）ポピュレートするように、更に構成される。

電子デバイス４８００の一部の実施形態では、コンテンツアイテムを抽出することは、音声通信の一部を分析して所定の種類のコンテンツを検出することを含み、分析は、電子デバイスと通信するオーディオシステムを介して音声通信を出力している間に実行される。

電子デバイス４８００の一部の実施形態では、（例えば、音声通信分析ユニット４８２７を用いて）音声通信を分析することは、（ｉ）リモートデバイスのリモートユーザによって提供されるスピーチをテキストに変換することと、（ｉｉ）テキストに自然言語処理アルゴリズムを適用し、テキストが１つ以上の定義済みのキーワードを含むかどうかを判定することと、（ｉｉｉ）テキストが対応する定義済みのキーワードを含むとの判定に従って、音声通信がコンテンツアイテムを説明するスピーチを含むと判定することと、を含む。

電子デバイス４８００の一部の実施形態では、音声通信の少なくとも一部を受信することは、音声通信の一部が分析されるべきであるというインジケーション（例えば、命令）を、電子デバイスのユーザから受信することを含む。

電子デバイス４８００の一部の実施形態では、インジケーションは、ハードウェアボタンの選択に対応する。

電子デバイス４８００の一部の実施形態では、インジケーションは、「ｈｅｙ Ｓｉｒｉ」の言葉を含む、電子デバイスのユーザからのコマンドに対応する。

電子デバイス４８００の一部の実施形態では、処理ユニットは、音声通信の第２の部分を受信するように更に構成されており、第２の部分は、リモートデバイスのリモートユーザによって提供されるスピーチ、及び電子デバイスのユーザによって提供されるスピーチを含む（例えば、音声通信は生の通話であり、第２の部分はユーザとリモートユーザとの間の話し合いを含む）。処理ユニットはまた、リモートデバイスのリモートユーザによって提供されるスピーチの少なくとも一部に基づく第２のコンテンツアイテム、及び電子デバイスのユーザによって提供されるスピーチを（例えば、コンテンツアイテム抽出ユニット４８０９を用いて）抽出し、第２のコンテンツアイテムが電子デバイス上で現在利用可能でないとの判定に従って、（ｉ）第２のコンテンツアイテムと関連付けられている第２のアプリケーションを（例えば、アプリケーション特定ユニット４８１３を用いて）特定し、（ｉｉ）ディスプレイ上の第２のコンテンツアイテムの第２の選択可能な説明を（例えば、表示ユニット４８１５及び／又はディスプレイユニット４８０１を用いて）表示するように、構成される。第２の選択可能な説明の選択を検出したことに応じて、処理ユニットは、第２のコンテンツアイテムを、特定された第２のアプリケーションと共に提示するために（例えば、コンテンツアイテム記憶ユニット４８１７を用いて）記憶するように構成される。

電子デバイス４８００の一部の実施形態では、選択可能な説明及び第２の選択可能な説明は、電話アプリケーションを用いてかけられた最近の通話を含むユーザインタフェース内に表示される。

一部の実施形態によれば、図４９は、説明される様々な実施形態の原理に従って構成された、電子デバイス４９００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図４９で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス４９００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図４９に示すように、電子デバイス４９００は、情報を表示するように構成されたディスプレイユニット４９０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット４９０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット４９０１及びタッチ感知面ユニット４９０３に連結された処理ユニット４９０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図４９は、ディスプレイユニット４９０１及びタッチ感知面ユニット４９０３を電子デバイス４９００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、音声通信受信ユニット（例えば、音声通信受信ユニット４９０７、図４９）と、コンテンツアイテム抽出ユニット（例えば、コンテンツアイテム抽出ユニット４９０９、図４９）と、インジケーション提供ユニット（例えば、インジケーション提供ユニット４９１１、図４９）と、入力検出ユニット（例えば、入力検出ユニット４９１３、図４９）と、アプリケーションオープンユニット（例えば、アプリケーションオープンユニット４９１５、図４９）と、アプリケーションポピュレートユニット（例えば、アプリケーションポピュレートユニット４９１７、図４９）と、フィードバック提供ユニット（例えば、フィードバック提供ユニット４９１９、図４９）と、音声通信分析ユニット（例えば、音声通信分析ユニット４９２１、図４９）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット４９０７～４９２１などの、その１つ以上の構成要素）は、音声通信の少なくとも一部を受信するように構成され、音声通信の一部は、電子デバイスのユーザとは異なるリモートデバイスのリモートユーザによって提供されるスピーチを含む（例えば、音声通信受信ユニット４９０７を用いて）。処理ユニットは更に、音声通信が物理的位置を特定するスピーチを含むことを（例えば、コンテンツアイテム抽出ユニット４９０９を用いて）判定するように、構成される。音声通信が物理的位置を特定するスピーチを含むことを判定したことに応じて、処理ユニットは、（例えば、コンテンツアイテム抽出ユニット４９０９を用いて）物理的位置についての情報が検出されたというインジケーションを提供するように、構成される。処理ユニットはまた、タッチ感知面ユニットを介して、入力を（例えば、入力検出ユニット４９１１を用いて）検出するように、構成される。入力を検出したことに応じて、処理ユニットは、（ｉ）地理的位置データを受け付けるアプリケーションを（例えば、アプリケーションオープンユニット４９１３を用いて）開くことと、（ｉｉ）アプリケーションを物理的位置についての情報で（例えば、アプリケーションポピュレートユニット４９１５を用いて）ポピュレートするように、構成される。

電子デバイス４９００の一部の実施形態では、音声通信は生の通話である。

電子デバイス４９００の一部の実施形態では、音声通信は生のＦａｃｅＴｉｍｅ通話である。

電子デバイス４９００の一部の実施形態では、音声通信は録音されたボイスメールである。

電子デバイス４９００の一部の実施形態では、インジケーションを提供することは、物理的位置の選択可能な説明を、電話アプリケーションを用いてかけられた最近の通話を含むユーザインタフェース内に表示することを含む。

電子デバイス４９００の一部の実施形態では、選択可能な説明は、コンテンツアイテムが音声通信と関連付けられていることを示す。

電子デバイス４９００の一部の実施形態では、入力を検出することは、最近の通話を含むユーザインタフェースが表示されている間に、選択可能な説明の上での入力を検出することを含む。

電子デバイス４９００の一部の実施形態では、インジケーションを提供することは、電子デバイスのユーザに触覚フィードバックを（例えば、フィードバック提供ユニット４９１９を用いて）提供することを含む。

電子デバイス４９００の一部の実施形態では、インジケーションを提供することは、電子デバイスの近傍にある異なる電子デバイスに物理的位置に関する情報を（例えば、フィードバック提供ユニット４９１９を用いて）送信することを含む。

電子デバイス４９００の一部の実施形態では、音声通信が物理的位置を説明するスピーチを含むと判定することは、音声通信の一部を（例えば、音声通信分析ユニット４９２１を用いて）分析して物理的位置についての情報を検出することを含み、分析は、電子デバイスと通信するオーディオシステムを介して音声通信を出力している間に実行される。

電子デバイス４９００の一部の実施形態では、音声通信の少なくとも一部を受信することは、音声通信の一部が分析されるべきであるという命令を電子デバイスのユーザから受信することを含む。

電子デバイス４９００の一部の実施形態では、命令は、ハードウェアボタンの選択に対応する。

電子デバイス４９００の一部の実施形態では、命令は、「ｈｅｙ Ｓｉｒｉ」の言葉を含む、電子デバイスのユーザからのコマンドに対応する。

一部の実施形態によれば、図５０は、説明される様々な実施形態の原理に従って構成された、電子デバイス５０００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図５０で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス５０００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図５０に示すように、電子デバイス５０００は、情報を表示するように構成されたディスプレイユニット５００１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット５００３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット５００１及びタッチ感知面ユニット５００３に連結された処理ユニット５００５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図５０は、ディスプレイユニット５００１及びタッチ感知面ユニット５００３を電子デバイス５０００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、提示ユニット（例えば、提示ユニット５００７、図５０）と、次の入力判定ユニット（例えば、次の入力判定ユニット５００９、図５０）と、コンテンツ分析ユニット（例えば、コンテンツ分析ユニット５０１１、図５０）と、選択受信ユニット（例えば、選択受信ユニット５０１３、図５０）と、タイプ入力監視ユニット（例えば、タイプ入力監視ユニット５０１５、図５０）と、提示停止ユニット（例えば、提示停止ユニット５０１７、図５０）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット５００７～５０１７などの、その１つ以上の構成要素）は、ディスプレイ上のメッセージングアプリケーションにおいて、テキスト入力フィールド及び会話記録を（例えば、提示ユニット５００７及び／又はディスプレイユニット５００１を用いて）提示するように、構成される。メッセージングアプリケーションがディスプレイ上に提示されている間、処理ユニットはまた、電子デバイスのユーザが次に入力すると思われるものが物理的位置についての情報であることを（例えば、次の入力判定ユニット５００９を用いて）判定するようにも構成される。処理ユニットは付加的に、テキスト入力フィールド及び会話記録に関連付けられるコンテンツを分析して、分析されたコンテンツの少なくとも一部に基づいて、提案された物理的位置を（例えば、コンテンツ分析ユニット５０１１を用いて）判定し、ディスプレイ上のメッセージングアプリケーション内にて、提案された物理的位置を特定する選択可能なユーザインタフェース要素を（例えば、提示ユニット５００７を用いて）提示し、選択可能なユーザインタフェース要素の選択を（例えば、選択受信ユニット５０１３及び／又はタッチ感知面ユニット５００３を用いて）受信し、選択を受信したことに応じて、テキスト入力フィールドに、提案された物理的位置の表現を（例えば、提示ユニット５００７を用いて）提示するように、構成される。

電子デバイス５０００の一部の実施形態では、メッセージングアプリケーションは仮想キーボードを含み、選択可能なユーザインタフェース要素は、仮想キーボードに隣接し、かつその上にある提案部分に表示される。

電子デバイス５０００の一部の実施形態では、電子デバイスのユからの次の可能性のある入力が物理的位置についての情報であると判定することは、テキスト入力フィールド及び会話記録に関連付けられたコンテンツを処理して、会話記録がユーザの現在地についての質問を含むことを検出することを含む。

電子デバイス５０００の一部の実施形態では、コンテンツを処理することは、自然言語処理アルゴリズムを適用して、質問を形成する１つ以上の定義済みのキーワードを検出することを含む。

電子デバイス５０００の一部の実施形態では、質問は、ユーザとは異なる第２のユーザから受信されるメッセージに含まれる。

電子デバイス５０００の一部の実施形態では、電子デバイスのユーザからの次の可能性のある入力が物理的位置についての情報であると判定することは、メッセージングアプリケーションのテキスト入力部分におけるユーザから受信されるタイプ入力を（例えば、タイプ入力監視ユニット５０１５を用いて）監視することを含む。

電子デバイス５０００の一部の実施形態では、処理ユニットは、ユーザがタイピングしており選択可能なユーザインタフェース要素を選択していないことを判定したことに従って、選択可能なユーザインタフェース要素を提示するのを（例えば、提示停止ユニット５０１７を用いて）停止するように、更に構成される。

電子デバイス５０００の一部の実施形態では、処理ユニットは、ユーザが選択可能なユーザインタフェース要素を選択しないことを示す追加の入力を提供したとの判定に従って、選択可能なユーザインタフェース要素を提示するのを（例えば、提示停止ユニット５０１７を用いて）停止するように、更に構成される。

電子デバイス５０００の一部の実施形態では、提案された物理的位置の表現は、電子デバイスの現在の地理的位置を特定する情報を含む。

電子デバイス５０００の一部の実施形態では、提案された物理的位置の表現は住所である。

電子デバイス５０００の一部の実施形態では、提案された物理的位置の表現は、提案された物理的位置についての識別子を含むマップオブジェクトである。

電子デバイス５０００の一部の実施形態では、提案された物理的位置は、メッセージングアプリケーション以外のアプリケーション内でユーザが最近閲覧した位置に対応する。

電子デバイス５０００の一部の実施形態では、メッセージングアプリケーションは電子メールアプリケーションである。

電子デバイス５０００の一部の実施形態では、メッセージングアプリケーションはテキストメッセージングアプリケーションである。

一部の実施形態によれば、図５１は、説明される様々な実施形態の原理に従って構成された、電子デバイス５１００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図５１で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス５１００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図５１に示すように、電子デバイス５１００は、情報を表示するように構成されたディスプレイユニット５１０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット５１０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット５１０１及びタッチ感知面ユニット５１０３に連結された処理ユニット５１０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図５１は、ディスプレイユニット５１０１及びタッチ感知面ユニット５１０３を電子デバイス５１００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、情報取得ユニット（例えば、情報取得ユニット５１０７、図５１）と、アプリケーション終了ユニット（例えば、アプリケーション終了ユニット５１０９、図５１）と、要求受信ユニット（例えば、要求受信ユニット５１１１、図５１）と、アプリケーション能力判定ユニット（例えば、アプリケーション能力判定ユニット５１１３、図５１）と、アプリケーション提示ユニット（例えば、アプリケーション提示ユニット５１１５、図５１）と、アプリケーションポピュレートユニット（例えば、アプリケーションポピュレートユニット５１１７、図５１）と、入力検出ユニット（例えば、入力検出ユニット５１１９、図５１）と、アプリケーション切替ユーザインタフェース表示ユニット（例えば、アプリケーション切替ユーザインタフェース表示ユニット５１２１、図５１）と、アプリケーション関連付け判定ユニット（例えば、アプリケーション関連付け判定ユニット５１２３、図５１）と、アクセス提供ユニット（例えば、アクセス提供ユニット５１２５、図５１）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット５１０７～５１２５などの、その１つ以上の構成要素）は、第１のアプリケーションを表示している間に、第１のアプリケーションにおいてユーザによって閲覧された第１の物理的位置を特定する情報を（例えば、情報取得ユニット５１０７を用いて）取得するように、構成される。処理ユニットはまた、第１のアプリケーションを（例えば、アプリケーション終了ユニット５１０９を用いて）終了して、第１のアプリケーションを終了した後に、第１のアプリケーションとは異なる第２のアプリケーションを開く要求を（例えば、要求受信ユニット５１１１を用いて）ユーザから受信するように、構成される。要求を受信し、かつ第２のアプリケーションが地理的位置情報を受け付けることができるとの判定（例えば、アプリケーション能力判定ユニット５１１３によって処理又は実施される判定）に従って、第２のアプリケーションを（例えば、アプリケーション提示ユニット５１１５を用いて）提示し、第２のアプリケーションを提示することは、第１の物理的位置を特定する情報に少なくとも部分的に基づく情報で第２のアプリケーションを（例えば、アプリケーションポピュレートユニット５１１７を用いて）ポピュレートすることを含む。

電子デバイス５１００の一部の実施形態では、第２のアプリケーションを開くことの要求を受信することは、第１のアプリケーションを終了した後に、第２のアプリケーションについてのアフォーダンスへの入力を（例えば、入力検出ユニット５１１９を用いて）検出することを含む。

電子デバイス５１００の一部の実施形態では、第２のアプリケーションについてのアフォーダンスは、電子デバイスのホームスクリーン内に表示されるアイコンである。

電子デバイス５１００の一部の実施形態では、入力を検出することは、（ｉ）物理的なホームボタンでのダブルタップを検出することと、（ｉｉ）ダブルタップを検出したことに応じて、アプリケーション切替ユーザインタフェースを（例えば、アプリ切替ユーザインタフェースディスプレイユニット５１２１を用いて）表示することと、（ｉｉｉ）アフォーダンスの選択をアプリケーション切替ユーザインタフェース内から検出することと、を含む。

電子デバイス５１００の一部の実施形態では、第２のアプリケーションをポピュレートすることは、第１の物理的位置を特定する情報の少なくとも一部に基づく情報を含むユーザインタフェースオブジェクトを表示することを含む。

電子デバイス５１００の一部の実施形態では、ユーザインタフェースオブジェクトは、第１の物理的位置が第１のアプリケーションにおいて最近閲覧されたことをユーザに通知するテキスト説明を含む。

電子デバイス５１００の一部の実施形態では、ユーザインタフェースオブジェクトは第２のアプリケーション内で表示されるマップであり、第２のアプリケーションをポピュレートすることは、第１の物理的位置の識別子を含むようにマップをポピュレートすることを含む。

電子デバイス５１００の一部の実施形態では、第２のアプリケーションが仮想キーボードと共に提示され、ユーザインタフェースオブジェクトは仮想キーボードの上に表示される。

電子デバイス５１００の一部の実施形態では、情報を取得することは第２の物理的位置についての情報を取得することを含み、ユーザインタフェースオブジェクトを表示することは、ユーザインタフェースオブジェクトを第２の物理的位置についての情報と共に表示することを含む。

電子デバイス５１００の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができるとの判定は、（ｉ）第２のアプリケーションが地理的位置データを受け付け及び処理することができる入力受け取りフィールドを含むと判定することと、（ｉｉ）第２のアプリケーションが地理的位置情報をマップ上に表示することができると判定することと、（ｉｉｉ）第２のアプリケーションが地理的位置情報を用いて経路案内を容易化することができると判定することと、（ｉｖ）第２のアプリケーションが地理的位置情報を用いて交通サービスの位置を見つけて提供することができると判定することと、のうちの１つ以上（例えば、アプリケーション関連付け判定ユニット５１２３及び／又はアプリケーション能力判定ユニット５１１３によって実施される１つ以上の判定）を含む。

電子デバイス５１００の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができるとの判定は、第２のアプリケーションが、地理的位置データを受け付けかつ処理することができる入力受け取りフィールドを含むと判定することを含み、入力受け取りフィールドは、第２のアプリケーション内に表示されるマップ内を検索することを可能とする検索ボックスである。

電子デバイス５１００の一部の実施形態では、処理ユニットは、要求を受信したことに応じて、ユーザのアプリケーション使用履歴に基づいて、第２のアプリケーションが第１のアプリケーションと関連しているかを、（例えば、アプリケーション関連付け判定ユニット５１２３を用いて）判定するように、更に構成される。
電子デバイス５１００の一部の実施形態では、処理ユニットは、第２のアプリケーションを提示する前に、第２のアプリケーションに第１の物理的位置を特定する情報へのアクセスを（例えば、アクセス提供ユニット５１２５を用いて）提供するように更に構成され、アクセスを提供される前は、第２のアプリケーションは第１の物理的位置を特定する情報にアクセスできなかった。

一部の実施形態によれば、図５２は、説明される様々な実施形態の原理に従って構成された、電子デバイス５２００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図５２で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス５２００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図５２に示すように、電子デバイス５２００は、情報を表示するように構成されたディスプレイユニット５２０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット５２０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット５２０１及びタッチ感知面ユニット５２０３に連結された処理ユニット５２０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図５２は、ディスプレイユニット５２０１及びタッチ感知面ユニット５２０３を電子デバイス５２００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、情報取得ユニット（例えば、情報取得ユニット５２０７、図５２）と、入力検出ユニット（例えば、入力検出ユニット５２０９、図５２）と、アプリケーション特定ユニット（例えば、アプリケーション特定ユニット５２１１、図５２）と、アフォーダンス提示ユニット（例えば、アフォーダンス提示ユニット５２１３、図５２）と、アプリケーションオープンユニット（例えば、アプリケーションオープンユニット５２１５、図５２）、アプリケーションポピュレートユニット（例えば、アプリケーションポピュレートユニット５２１７、図５２）と、アプリケーション切替ユーザインタフェース提示ユニット（例えば、アプリケーション切替ユーザインタフェース提示ユニット５２１９、図５２）と、アプリケーション能力判定ユニット（例えば、アプリケーション能力判定ユニット５２２１、図５２）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット５２０７～５２２１などの、その１つ以上の構成要素）は、第１のアプリケーションにてユーザによって閲覧された第１の物理的位置を特定する情報を（例えば、情報取得ユニット５２０７を用いて）取得し、第１の入力を（例えば、入力検出ユニット５２０９を用いて）検出するように、構成される。第１の入力を検出したことに応じて、処理ユニットは、（ｉ）地理的位置情報を受け付けることができる第２のアプリケーションを（例えば、アプリケーション特定ユニット５２０９を用いて）特定し、（ｉｉ）ディスプレイの少なくとも一部の上に、第１のアプリケーションとは異なる、第１の物理的位置についての情報を有する第２のアプリケーションを開く提案を有するアフォーダンスを、（例えば、アフォーダンス提示ユニット５２１３を用いて）提示するように、構成される。処理ユニットはまた、アフォーダンスにて第２の入力を（例えば、入力検出ユニット５２０９を用いて）検出するように、構成される。アフォーダンスで第２の入力を検出したことに応じて、処理ユニットは、（ｉ）第２のアプリケーションを（例えば、アプリケーションオープンユニット５２１５を用いて）開き、（ｉｉ）第２のアプリケーションを、第１の物理的位置を特定する情報に少なくとも部分的に基づく情報を含むように（例えば、アプリケーションポピュレートユニット５２１７を用いて）ポピュレートするように、構成される。

電子デバイス５２００の一部の実施形態では、第１の入力は、アプリケーション切替ユーザインタフェースを開くことの要求に対応する（例えば、第１の入力は電子デバイスの物理的なホームボタン上のダブルタップである）。

電子デバイス５２００の一部の実施形態では、アフォーダンスはアプリケーション切替ユーザインタフェース内に提示される。

電子デバイス５２００の一部の実施形態では、アフォーダンスを提示することは、アフォーダンスを提示することに伴って、アプリケーション切替ユーザインタフェース内に電子デバイス上で実行している複数のアプリケーションの表現を（例えば、アプリケーション切替ユーザインタフェース提示ユニット５２１９を用いて）提示することと、アプリケーションの表現の下に位置するディスプレイの領域にアフォーダンスを提示することと、を含む。

電子デバイス５２００の一部の実施形態では、第１の入力は、電子デバイスのホームスクリーンを開くことの要求に対応する（例えば、第１の入力は電子デバイスの物理的なホームボタン上のシングルタップである）。

電子デバイス５２００の一部の実施形態では、アフォーダンスはホームスクリーンの一部の上に提示される。

電子デバイス５２００の一部の実施形態では、提案は、第２のアプリケーションに関連付けられた種類に特有のテキスト説明を含む。

電子デバイス５２００の一部の実施形態では、第２のアプリケーションをポピュレートすることは、第１の物理的位置を特定する情報の少なくとも一部に基づく情報を含むユーザインタフェースオブジェクトを表示することを含む。

電子デバイス５２００の一部の実施形態では、ユーザインタフェースオブジェクトは、第１の物理的位置が第１のアプリケーションにて最近閲覧されたことをユーザに通知するテキスト説明を含む。

電子デバイス５２００の一部の実施形態では、ユーザインタフェースオブジェクトは第２のアプリケーション内で表示されるマップであり、第２のアプリケーションをポピュレートすることは、第１の物理的位置の識別子を含むようにマップをポピュレートすることを含む。

電子デバイス５２００の一部の実施形態では、第２のアプリケーションが仮想キーボードと共に提示され、ユーザインタフェースオブジェクトは仮想キーボードの上に表示される。

電子デバイス５２００の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができるとの判定は、（ｉ）第２のアプリケーションが地理的位置データを受け付け及び処理することができる入力受け取りフィールドを含むと判定することと、（ｉｉ）第２のアプリケーションが地理的位置情報をマップ上に表示することができると判定することと、（ｉｉｉ）第２のアプリケーションが地理的位置情報を用いて経路案内を容易化することができると判定することと、（ｉｖ）第２のアプリケーションが地理的位置情報を用いて交通サービスの位置を見つけて提供することができると判定することと、のうちの１つ以上（例えば、アプリケーション能力判定ユニット５２２１によって実施される１つ以上の判定）を含む。

電子デバイス５２００の一部の実施形態では、第２のアプリケーションが地理的位置情報を受け付けることができると識別することは、第２のアプリケーションが、地理的位置情報を受け付けかつ処理することができる入力受け取りフィールドを含むことを（例えば、アプリケーション能力判定ユニット５２２１を用いて）判定することを含み、入力受け取りフィールドは、第２のアプリケーション内に表示されるマップ内を検索することを可能とする検索ボックスである。

一部の実施形態によれば、図５３は、説明される様々な実施形態の原理に従って構成された、電子デバイス５３００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図５３で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス５３００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図５３に示すように、電子デバイス５３００は、情報を表示するように構成されたディスプレイユニット５３０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット５３０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット５３０１及びタッチ感知面ユニット５３０３に連結された処理ユニット５３０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図５３は、ディスプレイユニット５３０１及びタッチ感知面ユニット５３０３を電子デバイス５３００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、情報取得ユニット（例えば、情報取得ユニット５３０７、図５３）と、車両エントリ判定ユニット（例えば、車両エントリ判定ユニット５３０９、図５３）と、プロンプト提供ユニット（例えば、プロンプト提供ユニット５３１１、図５３）と、命令受信ユニット（例えば、命令受信ユニット５３１３、図５３）と、経路案内容易化ユニット（例えば、経路案内容易化ユニット５３１５、図５３）と、メッセージ検出ユニット（例えば、メッセージ検出ユニット５３１７、図５３）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット５３０７～５３１７などの、その１つ以上の構成要素）は、電子デバイス上で実行している第１のアプリケーションにてユーザによって閲覧された第１の物理的位置を特定する情報を（例えば、情報取得ユニット５３０７を用いて）取得するように、構成される。処理ユニットはまた、ユーザが車両に乗ったと（例えば、車両エントリ判定ユニット５３０９を用いて）判定するように、構成される。ユーザが車両に乗ったと判定したことに応じて、処理ユニットは、第１の物理的位置を経路案内の目的地として用いるようにプロンプトをユーザに（例えば、プロンプト提供ユニット５３１１を用いて）提供するように、構成される。プロンプトを提供したことに応じて、ユーザから第１の物理的位置を経路案内の目的地として用いるようにする命令を（例えば、命令受信ユニット５３１３を用いて）受信する。処理ユニットは付加的に、第１の物理的位置への経路案内を（例えば、経路案内容易化ユニット５３０７を用いて）容易化するように、構成される。

電子デバイス５３００の一部の実施形態では、処理ユニットは、メッセージが第２の物理的位置を特定する情報を含むことを検出することを含む、メッセージが電子デバイスによって受信されていることを（メッセージ検出ユニット５３１７を用いて）検出し、検出したことに応じて、第２の物理的位置を経路案内の新たな目的地として用いるように、新たなプロンプトをユーザに（例えば、プロンプト提供ユニット５３１１を用いて）提供するように、更に構成される。

電子デバイス５３００の一部の実施形態では、処理ユニットは、ユーザから第２の物理的位置を新たな目的地として用いるようにする命令を受信したことに応じて、第２の物理的位置への経路案内を（例えば、経路案内容易化ユニット５３１５を用いて）容易化するように、更に構成される。

電子デバイス５３００の一部の実施形態では、メッセージが第２の物理的位置を特定する情報を含むことを検出することは、電子デバイス上で利用可能な仮想アシスタントが、電子デバイスと通信状態にあるオーディオシステムを介してユーザに対してメッセージを読んでいる間に、検出を実行することを含む。

電子デバイス５３００の一部の実施形態では、ユーザが車両に乗ったと判定することは、電子デバイスが車両との通信リンクを確立していることを検出することを含む。

電子デバイス５３００の一部の実施形態では、経路案内を容易化することは、電子デバイスのディスプレイを介して経路案内を提供することを含む。

電子デバイス５３００の一部の実施形態では、経路案内を容易化することは、第１の物理的位置を特定する情報を車両に送信することを含む。

電子デバイス５３００の一部の実施形態では、経路案内を容易化することは、電子デバイスと通信状態にあるオーディオシステム（例えば、車のスピーカ又はデバイス自身の内臓スピーカ）を介して経路案内を提供することを含む。

一部の実施形態によれば、図５４は、説明される様々な実施形態の原理に従って構成された、電子デバイス５４００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図５４で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス５４００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図５４に示すように、電子デバイス５４００は、情報を表示するように構成されたディスプレイユニット５４０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット５４０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット５４０１及びタッチ感知面ユニット５４０３に連結された処理ユニット５４０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図５４は、ディスプレイユニット５４０１及びタッチ感知面ユニット５４０３を電子デバイス５４００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。処理ユニットは、提示ユニット（例えば、提示ユニット５４０７、図５４）と、要求受信ユニット（例えば、要求受信ユニット５４０９、図５４）と、ユーザインタフェースオブジェクト提供ユニット（例えば、ユーザインタフェースオブジェクト提供ユニット５４１１、図５４）と、プロアクティブ貼り付けユニット（例えば、プロアクティブ貼り付けユニット５４１３、図５４）と、能力判定ユニット（例えば、能力判定ユニット５４１５、図５４）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット５４０７～５４１５などの、その１つ以上の構成要素）は、第１のアプリケーション内にコンテンツを（例えば、提示ユニット５４０７及び／又はディスプレイユニット５４０１を用いて）提示し、第１のアプリケーションとは異なる、入力受け取りフィールドを含む第２のアプリケーションを開くことの要求をユーザから（例えば、要求受信ユニット及び／又はタッチ感知面ユニット５４０３を用いて）受信し、要求を受信したことに応じて、入力受け取りフィールドを有する第２のアプリケーションを（例えば、提示ユニット５４０７及び／又はディスプレイユニット５４０１を用いて）提示し、入力受け取りフィールドで何らかのユーザ入力を受信する前に、選択可能なユーザインタフェースオブジェクトを提供して、ユーザがコンテンツの少なくとも一部を入力受け取りフィールドに（例えば、ユーザインタフェースオブジェクト提供ユニット５４１１及び／又はディスプレイユニット５４０１を用いて）貼付することを可能し、選択可能なユーザインタフェースオブジェクトの選択を検出したことに応じて、コンテンツの一部を入力受け取りフィールドに（例えば、プロアクティブ貼り付けユニット５４１３を用いて）貼付するように、構成される。

電子デバイス５４００の一部の実施形態では、選択可能なユーザインタフェースオブジェクトを提供する前に、処理ユニットは、入力受け取りフィールドを、コンテンツの一部を受け付けることができるフィールドとして（例えば、能力判定ユニット５４１５を用いて）特定するように、更に構成される。

電子デバイス５４００の一部の実施形態では、入力受け取りフィールドをコンテンツの一部を受け付けることができるフィールドとして特定することは、入力受け取りフィールドの選択を検出したことに応じて実行される。

電子デバイス５４００の一部の実施形態では、コンテンツの一部は画像に対応する。

電子デバイス５４００の一部の実施形態では、コンテンツの一部はテキストコンテンツに対応する。

電子デバイス５４００の一部の実施形態では、コンテンツの一部はテキストコンテンツ及び画像に対応する。

電子デバイス５４００の一部の実施形態では、第１のアプリケーションはウェブ閲覧アプリケーションであり、第２のアプリケーションはメッセージングアプリケーションである。

電子デバイス５４００の一部の実施形態では、第１のアプリケーションは写真閲覧アプリケーションであり、第２のアプリケーションはメッセージングアプリケーションである。

電子デバイス５４００の一部の実施形態では、処理ユニットは、第２のアプリケーションを開くことの要求を受信する前に、コンテンツの少なくとも一部をコピーすることの要求を受信するように、更に構成される。

電子デバイス５４００の一部の実施形態では、選択可能なユーザインタフェースオブジェクトは、コンテンツの一部が最近、第１のアプリケーションにて閲覧されたことのインジケーションと共に表示されている。

一部の実施形態によれば、図５５は、説明される様々な実施形態の原理に従って構成された、電子デバイス５５００の機能ブロック図を示す。このデバイスの機能ブロックは、説明される様々な実施形態の原理を実行するために、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせによって、任意選択的に実装される。図５５で説明される機能ブロックが、説明される様々な実施形態の原理を実施するように、任意選択的に、組み合わされ、又はサブブロックに分離されることが当業者には理解されよう。したがって、本明細書における説明は、本明細書で説明されている機能ブロックのあらゆる可能な組み合わせ若しくは分割、又は更なる定義を任意選択的に支持する。議論を容易にするために、電子デバイス５５００はポータブル多機能デバイス１００として実装される（図１Ａ～１Ｂ）。

図５５に示すように、電子デバイス５５００は、情報を表示するように構成されたディスプレイユニット５５０１（例えば、タッチ感知ディスプレイシステム１１２（タッチスクリーン、タッチスクリーンディスプレイとも称される）、図１Ａ）と、タッチスクリーンディスプレイ上の接触、ジェスチャ、及び他のユーザ入力を受信するように構成されたタッチ感知面ユニット５５０３（例えば、ディスプレイコントローラ１５６及びタッチ感知ディスプレイシステム１１２、図１Ａ）と、ディスプレイユニット５５０１及びタッチ感知面ユニット５５０３に連結された処理ユニット５５０５と、を備える。一部の実施形態では、電子デバイスは、図１Ｅに示すコンピューティングデバイス（例えば、コンピューティングデバイスＡ～Ｄ）のいずれか１つに従って構成される。図示を簡易にするために、図５５は、ディスプレイユニット５５０１及びタッチ感知面ユニット５５０３を電子デバイス５５００と一体化したものとして示しているが、一部の実施形態では、これらのユニットの片方又は両方は、電子デバイスと通信状態にあるが、ユニットは電子デバイスと物理的に分離された状態である。一部の実施形態では、処理ユニットは、提示ユニット（例えば、提示ユニット５５０７、図５５）と、判定ユニット（例えば、判定ユニット５５０９、図５５）と、取得ユニット（例えば、取得ユニット５５１１、図５５）と、検索実施ユニット（例えば、検索実施ユニット５５１３、図５５）と、情報準備ユニット（例えば、情報準備ユニット５５１５、図５５）と、アフォーダンス表示ユニット（例えば、アフォーダンス表示ユニット５５１７、図５５）と、検出ユニット（例えば、検出ユニット５５１９、図５５）と、を備える。

一部の実施形態では、処理ユニット（又は、ユニット５５０７～５５１９などの、その１つ以上の構成要素）は、ディスプレイ上に、アプリケーションに関連付けられるテキストコンテンツを（例えば、提示ユニット５５０７及び／又はディスプレイユニット５５０１を用いて）提示し、テキストコンテンツの一部が、（ｉ）位置、（ｉｉ）連絡先、又は（ｉｉｉ）イベントに関すると（例えば、判定ユニット５５０９を用いて）判定し、テキストコンテンツの一部が位置に関連すると判定すると、電子デバイス上の位置センサから位置情報を（例えば、取得ユニット５５１１を用いて）取得し、取得した位置情報を予測コンテンツアイテムとして表示するために（例えば、情報準備ユニット５５１５を用いて）準備し、テキストコンテンツの一部が連絡先に関連すると判定すると、テキストコンテンツの一部に関連する連絡先情報について電子デバイス上において（例えば、検索実施ユニット５５１３を用いて）検索を行い、検索を介して取り出された、少なくとも１つの連絡先に関連付けられた情報を、予測コンテンツアイテムとして表示するために（例えば、情報準備ユニット５５１５を用いて）準備し、テキストコンテンツの一部がイベントに関連すると判定すると、テキストコンテンツの一部に関連するイベント情報について電子デバイス上において（例えば、検索実施ユニット５５１３を用いて）検索を行い、新たな検索を介して取り出された、少なくとも１つのイベントに少なくとも部分的に基づく情報を、予測コンテンツアイテムとして表示するために（例えば、情報準備ユニット５５１５を用いて）準備し、予測コンテンツアイテムを含むアフォーダンスをアプリケーション内に（例えば、アフォーダンス表示ユニット５５１７及び／又はディスプレイユニット５５０１を用いて）表示し、タッチ感知面を介して、アフォーダンスの選択を（例えば、検出ユニット５５１９を介して）検出し、選択を検出したことに応じて、予測コンテンツアイテムに関連付けられた情報を、テキストコンテンツに隣接するディスプレイに（例えば、提示ユニット５５０７及び／又はディスプレイユニット５５０１を用いて）表示するように、構成される。

電子デバイス５５００の一部の実施形態では、テキストコンテンツの一部は、アプリケーション内で直近に提示されたテキストコンテンツに対応する。

電子デバイス５５００の一部の実施形態では、アプリケーションはメッセージングアプリケーションであり、テキストコンテンツの一部は、電子デバイスとは異なるリモートデバイスのリモートユーザからメッセージングアプリケーションの中で受信された質問である。

電子デバイス５５００の一部の実施形態では、テキストコンテンツの一部は、アプリケーション内の入力受け取りフィールドにおいて電子デバイスのユーザによって提供される入力である。

電子デバイス５５００の一部の実施形態では、テキストコンテンツの一部は、テキストコンテンツの一部を含むユーザインタフェースオブジェクトを選択するユーザ入力に応じて、特定される。

電子デバイス５５００の一部の実施形態では、アプリケーションはメッセージングアプリケーションであり、ユーザインタフェースオブジェクトはメッセージングアプリケーション内で表示された会話の中のメッセージ吹き出しである。

電子デバイス５５００の一部の実施形態では、処理ユニットは、第２のユーザインタフェースオブジェクトの選択を検出し、選択を検出したことに応じて、（ｉ）予測コンテンツアイテムを有するアフォーダンスの表示を停止し、（ｉｉ）第２のユーザインタフェースオブジェクトに関連付けられたテキストコンテンツが、位置、連絡先、又はイベントに関連していることを判定し、判定したことに従って、アプリケーション内に新たな予測コンテンツアイテムを表示するように、更に構成される。

電子デバイス５５００の一部の実施形態では、アフォーダンスはアプリケーション内の仮想キーボードに隣接して表示される。

電子デバイス５５００の一部の実施形態では、予測コンテンツアイテムに関連付けられた情報は入力受け取りフィールドに表示され、入力受け取りフィールドは仮想キーボードで受信されるタイプ入力を表示するフィールドである。

上述の情報処理方法のいずれかにおける動作は、汎用プロセッサ（例えば、図１Ａ及び３に関連して上述されたようなもの）又は特定用途向けチップなどの、情報処理装置内の１つ以上の機能モジュールを稼働させることによって、任意選択的に実施される。

図６Ａ～６Ｂ及び図８Ａ～８Ｂを参照して上述された動作は、図１Ａ～１Ｂ、又は図４２～５５に示される構成要素によって、任意選択的に実施される。例えば、実行動作６０２及び検出動作８０２は、任意選択的に、イベントソート部１７０、イベント認識部１８０、及びイベント処理部１９０により実行される。イベントソート部１７０のイベントモニタ１７１は、タッチ感知ディスプレイ１１２上の接触を検出し、イベントディスパッチャモジュール１７４は、イベント情報をアプリケーション１３６－１に配信する。アプリケーション１３６－１の対応するイベント認識部１８０は、そのイベント情報を対応するイベント定義１８６に照会し、タッチ感知面上の第１の位置での第１の接触（又は、デバイスの回転）が、ユーザインタフェース上のオブジェクトの選択、又は１つの向きから別の向きへのデバイスの回転などの、既定のイベント又はサブイベントに対応するか否かを判定する。対応する既定のイベント又はサブイベントが検出されると、イベント認識部１８０は、イベント又はサブイベントの検出に関連付けられるイベント処理部１９０をアクティブ化する。イベント処理部１９０は、アプリケーション内部状態１９２を更新するために、データ更新部１７６若しくはオブジェクト更新部１７７を、任意選択的に用いるか又は呼び出す。一部の実施形態では、イベント処理部１９０は、アプリケーションにより表示されるものを更新するために、対応するＧＵＩ更新部１７８にアクセスする。同様に、当業者にとって、他の処理が図１Ａ～１Ｂに示される構成要素に基づいてどのように実施されるかは明らかであるだろう。

上述の説明は、説明の目的上、特定の実施形態を参照して説明されている。しかしながら、上記の例示的な論考は、網羅的であること、又は本発明を、開示される厳密な形態に限定することを意図するものではない。上記の教示を鑑みて、多くの修正及び変形が可能である。本発明の原理及びその実際的な応用を最良の形で説明し、それによって他の当業者が、想到される特定の用途に好適な様々な改良で本発明及び様々な実施形態を最良の形で使用することを可能とするために、これらの実施形態を選択し説明した。

Claims (16)

1. １つ以上のプロセッサと、メモリと、タッチ感知面と、ディスプレイと、を有する電子デバイスにおいて、
   第１のアプリケーションを前記電子デバイスの前記ディスプレイ上に表示している間に、
   第１のアプリケーションの検索機能へのユーザからの入力を受信することと、
   前記入力に応じて、第１の物理的位置の地理的位置データを取得することと、
   前記第１の物理的位置の前記地理的位置データを格納することと、
   前記第１のアプリケーションへの更なる入力を受信することなしに、
   前記第１のアプリケーションを終了し、
   前記第１のアプリケーションの終了後に、前記電子デバイスの前記ディスプレイにおいて、前記第１のアプリケーションとは区別される第２のアプリケーションを開くためのユーザからの要求を受信することと、
   前記要求を受信したことに応じて、かつ、前記第２のアプリケーションが地理的位置データを受け付けることができるとの判定に従って、
   前記第２のアプリケーションを前記電子デバイスの前記ディスプレイ上に提示することであって、前記アプリケーションを前記電子デバイスの前記ディスプレイ上に提示することは、前記第１の物理的位置の前記地理的位置データで前記第２のアプリケーションをポピュレートすることを含む、ことと
   を含む、方法。
2. 前記第２のアプリケーションを開くための前記要求を受信することは、前記第１のアプリケーションを終了した後に、前記第２のアプリケーションのためのアフォーダンス上で入力を検出することを含む、請求項１に記載の方法。
3. 前記第２のアプリケーションのための前記アフォーダンスは、前記電子デバイスのホームスクリーン内に表示されるアイコンである、請求項２に記載の方法。
4. 前記入力を検出することは、
   物理的なホームボタンにおけるダブルタップを検出することと、
   前記ダブルタップを検出したことに応じて、アプリケーション切替ユーザインタフェースを表示することと、
   前記アプリケーション切替ユーザインタフェース内から前記アフォーダンスの選択を検出することと、を含む、請求項２に記載の方法。
5. 前記第２のアプリケーションをポピュレートすることは、前記第１の物理的位置の前記地理的位置データに少なくとも部分的に基づく情報を含むユーザインタフェースオブジェクトを表示することを含む、請求項１から４のいずれか１項に記載の方法。
6. 前記ユーザインタフェースオブジェクトは、前記第１の物理的位置が前記第１のアプリケーション内で最近閲覧されたことを前記ユーザに知らせるテキスト記述を含む、請求項５に記載の方法。
7. 前記ユーザインタフェースオブジェクトは、前記第２のアプリケーション内に表示される地図であり、
   前記第２のアプリケーションをポピュレートすることは、前記第１の物理的位置の識別子を含むように前記地図をポピュレートすることを含む、請求項６に記載の方法。
8. 前記第２のアプリケーションは仮想キーボードと共に提示され、前記ユーザインタフェースオブジェクトは前記仮想キーボードの上方に表示される、請求項６又は７に記載の方法。
9. 前記地理的位置データを取得することは、第２の物理的位置の地理的位置データを取得することを含み、前記ユーザインタフェースオブジェクトを表示することは前記ユーザインタフェースオブジェクトを前記第２の物理的位置の前記地理的位置データと共に表示することを含む、請求項６から８のいずれか１項に記載の方法。
10. 前記第２のアプリケーションが前記地理的位置データを受け付けることができるとの前記判定は、（i）前記第２のアプリケーションが地理的位置データを受け付けて処理することができる入力受信フィールドを含むとの判定、（ii）前記第２のアプリケーションが前記地理的位置データを地図上に表示することができるとの判定、（iii）前記第２のアプリケーションが前記地理的位置データを利用して経路案内を促進することができるとの判定、（iv）前記第２のアプリケーションが前記地理的位置データを利用して輸送サービスを位置特定し、提供することができるとの判定のうち、１つ以上を含む、請求項６から９のいずれか１項に記載の方法。
11. 前記第２のアプリケーションが前記地理的位置データを受け付けることができるとの前記判定は、前記第２のアプリケーションが地理的位置データを受け付けて処理することができる入力受信フィールドを含むとの判定を含み、
    前記入力受信フィールドは、前記第２のアプリケーション内に表示された地図内での検索を可能とする検索ボックスである、請求項１０に記載の方法。
12. 前記要求を受信したことに応じて、前記ユーザのアプリケーション利用履歴に基づき、前記第２のアプリケーションが前記第１のアプリケーションと関連付けられているかどうかを判定することを更に含む、請求項１から１１のいずれか１項に記載の方法。
13. 前記第２のアプリケーションを提示する前に、前記第２のアプリケーションに対して、前記第１の物理的位置の前記地理的位置データへのアクセスを提供することを更に含み、
    前記アクセスが提供される以前は、前記第２のアプリケーションは前記第１の物理的位置の前記地理的位置データへのアクセスを有さない、請求項１２に記載の方法。
14. 請求項１から１３のいずれか１項に記載の方法をコンピュータに実行させるためのコンピュータプログラム。
15. タッチ感知面と、
    ディスプレイと、
    請求項１４に記載のコンピュータプログラムを記憶したメモリと、
    前記メモリ内に記憶された前記コンピュータプログラムを実行可能な１以上のプロセッサと
    を備える電子デバイス。
16. 請求項１から１３のいずれか１項に記載の方法を実行するための手段を備える電子デバイス。

Images