JP2019527403A - 通知に対するユーザ可用性又は受容性を測定する方法、装置及び機械可読媒体 - Google Patents

Abstract

本明細書に記載する様々な実施形態は、以下のうちの１つ又はそれよりも多くを含むユーザ対話に適したときを決定するための方法、システム、及び非一時的な機械可読媒体に関し、方法は、ユーザがユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信するステップと、ユーザデバイス上のユーザの最近の活動に関する使用情報を取得するステップと、ユーザの現在の文脈状態を識別するために少なくとも１つのトレーニングされた予測モデルを使用情報に適用するステップと、ユーザの文脈状態に基づいて機会表示を決定するステップと、クライアントアプリケーションに機会表示を提供するステップとを含み、現在の文脈状態は、ユーザがユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値、及びユーザがユーザ対話に注意を払う能力を表す受容性測定値のうちの少なくとも１つを含む。

Description

本明細書に記載する様々な実施形態は、ユーザ対話(ユーザインタラクション)(user interaction)に関し、より具体的には、排他的ではないが、通知、メッセージ、又は他の対話をユーザに提供するための適切な時間を決定するサービスに関する。

スマートフォン及びタブレットのようなモバイルデバイスは、人から人への通信のためだけでなく、アプリケーション及びサービスからの通信のためにも、殆どの人々にとって主要な接点となっている。これらのデバイスは、ユーザに最初に入力を求めることを要求するのではなく、通知又は他のメッセージを介してユーザに情報をプッシュするために特に強力であり得る。例えば、コーチングプログラムは、彼らが１日を通じてプログラムの目標を達成するのを助けるよう、ユーザに提案及び情報をプッシュすることができる。これはコーチングプログラムに積極的に従うことなく１日を送るようユーザを自由にする。１日の任意の時点で、ユーザはコーチングサービスからメッセージを受信し、情報を読んだり或いは提案行動（例えば、運転してランチに行くよりもむしろ歩いてランチに行くこと）を取ったりしてよい。

ユーザにメッセージをプッシュする自由は、アプリケーションの目的にとって有益であり得るが、それは、ユーザがユーザ対話に自由に参加できないか或いは他の理由で空いていないときに、ユーザに通知をプッシュするのに役立たない。例えば、ユーザが現在自動車を運転しているならば、ユーザは着信メッセージを読むことができない。他の例として、ユーザが業務会議に参加しているならば、ユーザは退席して、提案されている身体活動に参加することはできない（しかしながら、会議に依存して、メッセージを読むことができる場合がある）。

ユーザと対話するのに適切なときを識別する方法及びシステムを提供することが有益である。以下により詳細に記載するように、様々な実施形態は、ユーザが現在提案に従って行動することができるか或いは情報メッセージを読むことを受け入れることができるか判断するために、モバイルデバイス（例えば、テキストメッセージ、アプリケーションの切替え、使用されているアプリケーションの種類）によって報告される使用を活用する。

従って、本明細書に記載する様々な実施形態は、ユーザ対話に適したときを決定するために予測デバイスによって行われる方法に関し、方法は、ユーザがユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信するステップと、ユーザデバイス上のユーザの最近の活動に関する使用情報を取得するステップと、ユーザの現在の文脈状態を識別するために少なくとも１つのトレーニングされた（教え込まれた）予測モデルを使用情報に適用するステップと、ユーザの文脈状態に基づいて機会表示を決定するステップと、クライアントアプリケーションに機会表示を提供するステップとを含み、現在の文脈状態は、ユーザがユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値（可用性尺度）及びユーザがユーザ対話に注意を払う能力を表す受容性測定値（受容性尺度）のうちの少なくとも１つを含む。

本明細書に記載する様々な実施形態は、ユーザ対話に適したときを決定する予測デバイスに関し、予測デバイスは、ユーザの現在の文脈状態を識別する少なくとも１つのトレーニングされた（教え込まれた）予測モデルを格納するように構成されたメモリと、メモリと通信するプロセッサとを含み、現在の文脈状態は、ユーザがユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値（可用性尺度）及びユーザがユーザ対話に注意を払う能力を表す受容性測定値（受容性尺度）のうちの少なくとも１つを含み、プロセッサは、ユーザがユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信し、ユーザデバイス上のユーザの最近の活動に関する使用情報を取得し、少なくとも１つのトレーニングされた予測モデルを使用情報に適用し、ユーザの文脈状態に基づいて機会表示を決定し、且つ機会表示をクライアントアプリケーションに提供するように構成される。

本明細書に記載する様々な実施形態は、ユーザ対話に適したときを決定するために予測デバイスによって行われるよう符号化された非一時的な機械可読媒体に関し、非一時的な機械可読媒体は、ユーザがユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信することについての命令と、ユーザデバイス上のユーザの最近の活動に関する使用情報を取得することについての命令と、ユーザの現在の文脈状態を識別するために少なくとも１つのトレーニングされた（教え込まれた）予測モデルを使用情報に適用することについての命令と、ユーザの文脈状態に基づいて機会表示を決定することについての命令と、機会表示を前記クライアントアプリケーションに提供することについての命令とを含み、現在の文脈状態は、ユーザがユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値（可用性尺度）及びユーザがユーザ対話に注意を払う能力を表す受容性測定値（受容性尺度）のうちの少なくとも１つを含む。

機会表示は、現在の文脈状態を含む、様々な実施形態が記載される。

使用情報のうちの少なくとも一部は、ユーザデバイスのオペレーティングシステムのアプリケーションプログラマインタフェース（ＡＰＩ）を介して取得される、様々な実施形態が記載される。

受信するステップ、取得するステップ、適用するステップ、決定するステップ、及び提供するステップは、ユーザデバイスのプロセッサによって行われる、様々な実施形態が記載される。

少なくとも１つのトレーニングされた予測モデルを遠隔予測モデルトレーニングデバイスから受信するステップを追加的に含む、様々な実施形態が記載される。

クライアントアプリケーションに機会表示を提供するステップに続いて、クライアントアプリケーションに対するユーザの反応に関するフィードバック情報を取得するステップと、ユーザの可用性及び受容性のうちの少なくとも１つに関するラベルをフィードバック情報から見分けるステップと、ラベルを使用情報と関連付けることによってトレーニング例を生成するステップと、更新されたトレーニングセットを生成するために、トレーニング例を既存のトレーニングセットに少なくとも追加することによって、既存のセットを更新するステップと、更新されたトレーニングセットに基づいて少なくとも１つのトレーニングされた予測モデルを再トレーニングするステップとを追加的に含む、様々な実施形態が記載される。

見分けるステップは、トレーニングされたフィードバック解釈モデルをフィードバック情報に適用してラベルを受信するステップを含む、様々な実施形態が記載される。

フィードバック情報は、機会表示をクライアントアプリケーションに提供することに続くユーザデバイス上のユーザ活動を記述する、様々な実施形態が記載される。

見分けるステップは、ユーザがかれらの使用挙動を変更したか否かを決定するために使用情報と共にフィードバック情報を分析するステップを含む、様々な実施形態が記載される。

様々な例示的な実施形態をより良く理解するために、添付の図面を参照する。

適切な時間にユーザ対話を実行する機能システムの一例を例示している。

適切な時間にユーザ対話を実行するシステム（又はその部分を）を実施するハードウェアデバイスの一例を例示している。

適切な時間にユーザ対話を実行するシステムの第１の実施形態を例示している。

適切な時間にユーザ対話を実行するシステムの第２の実施形態を例示している。

デバイスオペレーティングシステムから使用情報を収集する方法の一例を例示している。

予測モデルトレーニング又はアプリケーションにおける使用のための構成セットを収集する方法の一例を例示している。

１つ又はそれよりも多くの予測モデルをトレーニングするトレーニングセットの一例を例示している。

構成セットを処理してトレーニング例を創成し且つ文脈状態予測を生成する方法の一例を例示している。

受信するフィードバックに基づいて予測モデルを更新する方法の一例を例示している。

モデルをトレーニングする方法の一例を例示している。

本明細書に提示する記述及び図面は様々な原理を例示している。当業者は、たとえ本明細書に明示的に記載又は図示していないとしても、これらの原理を具現し且つこの開示の範囲内に含まれる様々な構成を考案し得ることが、理解されよう。本明細書で使用するとき、本明細書で使用する「又は」という用語は、別段の断り（例えば、「さもなければ」又は「又はその代わりに」）がない限り、非排他的な又は（即ち、「及び／又は」）を指す。加えて、本明細書に記載される様々な実施形態は、必ずしも相互に排他的でなく、本明細書に記載する原理を組み込む追加的な実施形態をもたらすよう組み合わせられてよい。

図１は、適切なときにユーザ対話(ユーザインタラクション)(user interaction)を実行する機能システム１００(functional system)の一例を例示している。様々な機能デバイスが例示されており、それらの各々は物理デバイス又はその部分に実装されるが、様々な実施形態において、機能デバイスは、単一のデバイス上に並置されてよく、複数のデバイスに亘って複製されてよく、或いは複数のデバイスの間に分散されてよい。例えば、各機能デバイスは、専用の物理デバイスに実装されてよく、全ての機能デバイスは、単一の物理デバイス（例えば、タブレット又はスマートフォンのようなユーザモバイルデバイス）又はそれらの間の任意の中間構成に実装されてよい。更なる例として、複数の中断サービスデバイス１２０を地理的に分散させられた物理サーバに亘って提供して、予測デバイスの出力に基づいて様々なクライアントアプリケーションデバイス１１０に機会表示(opportunity indications)を冗長的に提供してよい。更に他の例として、文脈状態(コンテキスト状態)(contextual state)（例えば、可用性(availability)及び受容性(receptiveness)）の複数の測定値(尺度)
(measures)を使用する実施形態では、別個のトレーニングセット創成デバイス１５０、予測モデルトレーニングデバイス１６０、又は予測デバイス１７０が、各々のそのような尺度のために提供されてよく、そのような機能デバイスは、異なる物理サーバに亘って分散させられてよい。

図示されているように、クライアントアプリケーションデバイス１１０は、それ自体の動作及び目的に従って、彼らのスマートデバイス又は他のチャネルを介して（例えば、アプリ、ＳＭＳ、電子メール、電話、ウエアラブル通知などを介して）ユーザに情報又は行動提案を伴う通知を送信することのような、ユーザとの対話に関与するデバイスであってよい。クライアントアプリケーションデバイスは、例えば、ユーザの（例えば、クライアントアプリケーションをアプリとして実行する）スマートデバイス、ユーザに対して遠隔にあるサーバ（例えば、クライアントアプリケーションをウェブ又は他のサービスとして実行する仮想マシン）、又は遅延、柔軟な配信、又はそのタイミングを調整する他の能力が可能なユーザとの対話に関与するクライアントアプリケーションを実行することができる任意のデバイスである。

割込みサービスデバイス１２０(中断サービスデバイス)(interruption service device)は、予測デバイスによって提供されるユーザの文脈状態の測定値を解釈して、そのような表示をクライアントアプリケーションデバイスに戻すことができる、実質的に如何なる物理デバイス（例えば、ユーザのスマートデバイス、仮想マシンを実行する遠隔サーバなど）であってもよい。例えば、割込みサービスデバイス１２０は、複数のそのような測定値を解釈して、単一の機会表示（例えば、「開かない」、「受信可能であるが利用可能でない」、「受信可能及び利用可能の両方」など）を提供してよく、或いはそのような測定値を機会表示として単に転送してよい。割込みサービスデバイス１２０は、そのような機会指示をオンデマンドでクライアントアプリケーションデバイス１１０に（例えば、クエリサービスとして）提供してよく、或いは文脈状態の関連の変化後に、そのような更新を受信する願望を以前に示したクライアントアプリケーションデバイス１１０に（例えば、サブスクリプションサービスとして）提供してよい。次に、クライアントアプリケーションデバイス１１０は、これらの受信される表示を使用して、ユーザ対話を開始することが適切であるときを判断してよい。

クライアントアプリケーションデバイス１１０及び割込みサービスデバイス１２０が別個の物理デバイスに実装される場合、クエリ又はサブスクリプション通信は、例えば、１以上（１つ又はそれよりも多く）のネットワークチャネルを介して生じてよい。例えば、２つのデバイスが互いに物理的に近接しているならば（例えば、クライアントアプリケーションデバイス１１０がウエアラブル腕時計デバイスであり、割込みサービスデバイス１２０がユーザの携帯電話である場合）、通信は、近距離場通信（ＮＦＣ）、（ブルートゥース（登録商標）低エネルギを含む）ブルートゥース（登録商標）、Ｗｉ−Ｆｉなどのような、短距離無線通信プロトコルに従って生じることがある。２つのデバイスが互いにより遠隔である実施形態において、通信は、Ｗｉ−Ｆｉ、３Ｇ、４Ｇ、ＬＴＥ、又はイーサネット（登録商標）ネットワークのような、１以上の無線又は有線ネットワークをトラバースして(traverse)よい。これらのネットワークは、例えば、モバイルキャリアネットワーク、クラウドコンピューティングデータセンターネットワーク、インターネットなどを含んでよく或いはその部分を構成してよい。２つのデバイスが同じ物理ハードウェア内に実装される場合、本明細書に記載する通信は、ローカルデバイスのオペレーティングシステムによって提供されることがある１以上のプロセス間通信(inter-process communications)を介して生じることがある。そのようなアプローチは、他のプロセスによって読み取られるファイルを記録すること、それぞれのソケットと関連付けられるソケットにデータを転送すること、処理間に１以上のパイプを確立すること、共有メモリにデータを書き込むこと、イベントバスを通じてイベントをプッシュすることなどを含んでよい。２つのデバイスが同じプロセスの部分として実装される幾つかの実施形態において、本明細書に記載する通信は、他の機能デバイスと関連付けられる機能にデータを呼び出すこと又は送ること、処理のために取り置かれたコンフィギュレーションファイル又はメモリのような共通の場所にデータを書き込むことによって達成されることがある。機能デバイス間の通信に対する他の様々なアプローチは、機能デバイスが実装されることがある様々な物理的及び手続的な文脈において明らかであろう。加えて、これらのアプローチのうちのいずれも、実装されるシステム１００の特定の実施形態に依存して、本明細書に記載する他の機能デバイス１３０〜１７０又は例示されていない他のデバイス間の通信に適用されてよい。

スマートデバイスモニタ１３０は、例えば、現在のデバイス画面（例えば、アプリ、アプリスイッチャにおける、ロックされた画面、ロック解除されている画面、ホーム画面など）、リンガー設定（例えば、大音量、低音量、高振動、低振動、無音など）、最後のロック解除からの時間、ロック／ロック解除の履歴ログ、バッテリ状態（例えば、充電中／充電中でない、バッテリレベル、放電時間）、メッセージ（例えば、メッセージ／通知のパターン）、メッセージ／通知の数、受信者の数、所与の時間窓内の出入り通信の頻度、通話（例えば、通話中／通話中でない、行った／受け取った通話のパターン、不在着信した／拒否された通話のパターン、行った／受け取った／不在着信した／拒否された通話の数、通話が所与の時間窓内で行われた／受け取られた／不在着信された／拒否されたならば他の当事者の数、使用中の現在のアプリケーション（例えば、名前、カテゴリ［生産性、ゲーム、ユーティリティなど］、現在のアプリケーション内の時間など）、アプリケーション使用のパターン（例えば、所与の時間窓内で使用されるアプリの数及びカテゴリ）、ネットワーク接続（例えば、なし、Ｗｉ−Ｆｉ、移動体、特定キャリア／周波数など）、現在のＷｉ−Ｆｉネットワーク（例えば、ＳＳＩＤ名、信号強度、周波数など）、範囲内の現在のＷｉ−Ｆｉネットワークの署名、（例えば、ブルートゥース（登録商標）、ＮＦＣなどを介した）現在の接続デバイスの署名などのような、１以上の種類の未処理の（生の）デバイス（例えば、携帯電話又はタブレット）使用情報を監視（モニタリング）するデバイスである。幾つかの実施形態において、この情報のうちの幾つか又はそれよりも多くは、ＯＳ又は他のアプリケーションから（即ち、未加工の形態において）直接的に利用可能でなくてよく、代わりに、利用可能なその未処理の使用情報から（特徴抽出デバイス１４０(feature extraction device)に関して以下により詳細に記載するように）抽出されてよい。

幾つかの実施形態において、未処理の使用情報は、スマートデバイス自体のオペレーティングシステム（ＯＳ）によって全体的に又は部分的に集められてよく、よって、スマートデバイス自体がスマートデバイスモニタ１３０を構成することがある。幾つかのそのような実施形態において、ＯＳは、そのような未処理の使用情報を、理解されるようにプッシュ又はプルプロトコル(push or pull protocols)に従って動作することがあるアプリケーションプログラマインタフェース（ＡＰＩ）を介して特徴抽出デバイス１３０に直接的に利用可能にしてよい。幾つかの実施形態では、スマートデバイス上で動作する他のプロセス又はアプリは、アプリとのユーザ対話の直接的な観察を通じて或いはそれぞれのＡＰＩを介してＯＳ又は他のアプリから他の未処理の使用情報をポーリングすることによって、未処理の使用情報の一部又は全部を集めてよい。例えば、ＯＳ ＡＰＩは、現在のネットワーク接続の瞬間的なビューを他のプロセッサ又はアプリに提供してよく、次に、他のプロセッサ又はアプリは、ある時間期間に亘って見られるすべてのネットワーク接続状態のログをコンパイルしてよい。未処理の使用情報をコンパイルする様々な他のアプローチが明らかになるであろう。

特徴抽出デバイス１４０は、未処理の使用情報から付加的な有用な情報を抽出することができる任意のデバイスであってよい。この「抽出された使用情報」は、（例えば、ロギングすること又はＯＳ状態を観察することを通じて今までに利用可能でない）未処理の使用情報に今までに含まれていないが、そこから導み出すことができる、実質的に如何なる情報であってもよい。例えば、ネットワークスイッチングの頻度、特定のテキスト会話で費やされたメジアン時間、又は現在の通話の分類（例えば、重要、カジュアル、歓迎されていない）。そのような特徴は、統計的アルゴリズム又はトレーニングされた（教え込まれた）機械学習モデルを含む任意のアプローチに従って得られることがある。

幾つかの実施形態において、特徴抽出デバイス１４０は、抽出された特徴を変更するために展開後に拡張可能であってよい。例えば、特徴抽出デバイス１４０は、１以上のスクリプト、コンパイルされた命令、又は特徴抽出のためのアルゴリズムを定義する他のアイテムを格納してよい。特徴抽出デバイス１４０は、特徴及びトレーニングセット創成デバイス１５０又は予測デバイス１７０の下流の全ての結果として得られるデータを抽出するときに、各々のそのような利用可能なアイテムを実行し或いは解釈してよい。どの特徴が抽出されるかを修正するために、これらのアイテムのセットは修正され、簡潔にされ、或いは補充される。

特徴抽出デバイス１４０は、未加工及び抽出使用情報（即ち、１以上のトレーニングされたモデル又は少なくともそのサブセットと共に使用するための特徴）を、１以上のモデルをトレーニングするためのトレーニングセット創成デバイス１５０に、並びにユーザの現在の文脈状態の測定値を生成するためのトレーニングされたモデルの適用のための予測デバイス１７０に提供する。特徴抽出デバイス１４０は、情報を（例えば、一貫したストリームで又は利用可能なように）継続的に送信してよく、或いはより間隔の空いた時間でのバッチ送信のためにデータを収集してよい。複数の時間スロットからの使用情報がバッチ送信されるべき場合、特徴抽出デバイス１４０は、送信のためにこれらの特徴を集計して(aggregate)圧縮して(compress)よい。送信の方法は、トレーニングセット創成デバイス１５０及び予測デバイス１７０の両方に同じである必要はない。例えば、特徴抽出デバイス１４０は、集計されて圧縮された使用情報のセットをトレーニングセット創成デバイス１５０に毎時送信してよいが、使用情報が利用可能になるときに使用情報を即座に予測デバイスに送信してよい。これは、トレーニングセット創成デバイス１５０が特徴抽出デバイス１４０から遠隔に位置するが、予測デバイス１７０が特徴抽出デバイス１４０と同じハードウェアに対して局所的であるか或いは特徴抽出デバイス１４０と同じハードウェアに配置されている場合に、特に有益なことがある。

トレーニングセット創成デバイス１５０は、受信した使用情報、フィードバック、及び他の有用な文脈情報から、１以上の機械学習モデルをトレーニングするための１以上のトレーニングセットを構築することができる、任意のデバイスであってよい。よって、トレーニングセット創成デバイス１５０は、例えば、ユーザのスマートデバイス又はＶＭをホストする遠隔サーバに実装されてよい。トレーニングセット創成デバイス１５０の動作及び生成された（複数の）トレーニングセットの構成が予測モデルトレーニングデバイス１６０によって利用される機械学習アプローチ及びモデルに依存することは明らかであろう。例えば、予測モデルトレーニングデバイス１６０が監督された（又は部分的に監督された）学習アプローチを使用する場合、トレーニングセット創成デバイス１５０はラベル付きトレーニングセットを生成してよい（例えば、その場合、各特徴セットは、その特徴セットに対応すると考えられる或いは想定されるユーザの可用性(availability)、受容性(receptiveness)などを表すブール値又は数値を示すラベルと対にされる）。そのようなラベルを提供するために、人間のオペレータ（例えば、ユーザ又は他のオペレータ）は、特徴セットを検討して、これらのラベルを手動で提供してよい。代替的に、クライアントアプリケーション１１０は、そのようなラベルを、ユーザ対話を配信した後に実際に観察されたユーザ挙動に基づくフィードバックとして戻してよい。幾つかの実施形態では、部分的に監督されたアプローチが、ラベルを直接的に提供するよりもむしろ、追従されてよい。例えば、１以上の別個にトレーニングされた機械学習モデル（例えば、文脈状態の各測定値についてのロジスティック回帰モデル）を、（ユーザ対話配信前、中又は後にユーザについて観察される使用情報又は他の情報を構築することがある）フィードバック情報又は特徴セットに適用して、各トレーニング例について（例えば、別個に或いは各潜在的なラベルが適用可能である可能性として）１以上のラベルを決定してよい。特徴セットをラベル付けする幾つかの有用なフィードバックは、ユーザが配信された通知（又は他の開始されたユーザ対話）とどのように対話するか（例えば、無視する、２秒に亘って読んで却下するなど）を記述する情報、又はユーザ対話後に送信されたデータを含んでよい。そのようなモデルの適用を通じて、トレーニングセット創成デバイス１５０は、開始されたユーザ対話に応答してユーザの挙動が変化したか否か並びにどの程度変化したかを決定することにより、そのユーザ対話の成功を測定することができてよい。

幾つかの実施形態において、トレーニングセット創成デバイス１５０は、新鮮でパーソナライズされた例が集められるときに、トレーニングセットから古い又はパーソナライズされていないトレーニング例を取り除いて(prune)よい。例えば、クライアントアプリケーションデバイス１１０が特定のユーザのために割込みサービスデバイス１２０を最初に使用し始めると、そのユーザのモデル１７２，１７４は、全体的に人口から又はそのユーザに人口統計的に又はその他の仕方で類似する人口から引き出されたトレーニング例に基づいて集められてよい。そのユーザに特異なトレーニング例が集められると、古い例は、より完全にカスタマイズされたモデルを提供するために、トレーニングセットから段階的に除去されてよい（或いは新しい例よりも比較的少なく重み付けされてよい）。同様に、パーソナライズされているが古いトレーニング例も、ユーザ挙動又は態度の変化を考慮して、より新しいトレーニング例の利益となるよう段階的に除去されてよい（或いは比較的少なく重み付けされてよい）。次に、結果として得られるラベル付きデータセットは、予測モデルトレーニングデバイス１６０に提供されてよい。

予測モデルトレーニングデバイス１６０は、トレーニングセットに基づいて１以上のモデルをトレーニングすることができる任意のデバイスであってよい。例えば、予測モデルトレーニングデバイス１６０は、モバイルデバイス又は遠隔サーバであってよい。文脈状態の測定値を提供するための様々なトレーニングされたモデル及び機械学習アルゴリズムが使用されてよい。例えば、予測モデルトレーニングデバイス１６０は、トレーニングセットを分析するための勾配降下のバージョンを使用して、回帰（線形又はロジスティック）又はニューラルネットワークモデルをトレーニングしてよい。従って、結果として得られるモデルは、ユーザの文脈状態のリアルタイム予測のための現在の特徴セットへの適用のために予測デバイス１７０に送信されることができる学習された重み（例えば、シータ値(theta values)）のセットを含んでよい。

予測デバイス１７０は、１以上のトレーニングモデルを１以上の特徴抽出デバイス１４０からの入り特徴セット(incoming feature sets)に適用することができる、任意のデバイスであってよい。予測デバイス１７０は、予測モデルトレーニングデバイス１６０から受信する１以上のモデル（例えば、受容性モデル１７２及び可用性モデル１７４）を格納してよい。特徴抽出デバイス１４０から特徴セットを受信した後に、予測デバイス１７０は、（例えば、特徴をトレーニングされた回帰又はニューラルネットワーク関数に特徴を入力することによって）モデル１７２，１７４を特徴セットに適用する。次に、モデル１７２，１７４の出力（例えば、文脈状態測定値）が、上述の方法で機会通知をクライアントアプリケーションデバイス１１０に提供する際に使用するために、割込みサービスデバイス１２０に提供されてよい。

本明細書に記載する様々な実施形態において、幾つかの機能デバイスは、スマートデバイスオペレーティングシステム（例えば、スマートデバイスモニタ１３０）と協調するものとして記載されているが、他の実施形態において、機能デバイスのうちの１以上は、オペレーティングシステムの部分として実装される場合があることが理解されるであろう。例えば、スマートデバイスモニタ１３０又は特徴抽出デバイス１４０は、（例えば、オペレーティングシステムＡＰＩを介して）特徴を外部デバイス／サービスに報告するためのオペレーティングシステムコンポーネントとして作動してよい。追加的な例として、リアルタイム割込みサービスパイプライン１３０，１４０，１７０，１２０又は機能デバイス１１０〜１７０の全部は、オペレーティングシステム自体のコンポーネントとして実装されてよい。

図２は、適切な時にユーザ対話を実行するシステム（又はその一部分）を実装するハードウェアデバイス２００の例を示している。ハードウェアデバイス２００は、図１の機能デバイスのうちの１以上を実装してよく、よって、ウェアラブルデバイス、携帯電話、タブレット、又はサーバ（例えば、本明細書に記載するソフトウェアプロセスを実装する仮想マシンを実行するサーバ）のような、様々なデバイスのうちの１つを実装してよい。図示のように、デバイス２００は、１以上のシステムバス２１０を介して相互接続される、プロセッサ２２０、メモリ２３０、ユーザインタフェース２４０、ネットワークインタフェース２５０、及び記憶装置２６０（ストレージ）を含む。図２は、幾つかの態様において、抽象化を構成すること、並びにデバイス２００のコンポーネントの実際の組織化は、例示しているものよりも複雑である場合があることが理解されるであろう。更に、この例はスマートデバイスによって実施されるような様々な特徴及びサーバによって実施されるような他の特徴を記載するが、これは例示的な実施形態であるに過ぎないことが理解されるであろう。上述のように、様々な機能は、多くの異なる構成において１以上のデバイスの間で分散されてよい。そのような代替的な構成を可能にするソフトウェア及び記憶装置２６０のコンテンツ（内容）への変更は明らかであろう。

プロセッサ２２０は、メモリ２３０又は記憶装置２６０に格納された命令(instructions)を実行することができる或いはその他の方法でデータを処理することができる任意のハードウェア装置であってよい。よって、プロセッサは、マイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、又は他の類似のデバイスを含んでよい。プロセッサがハードウェア中に本明細書において記載する機能のうちの１以上を実装する１以上のＡＳＩＣ（又は他の処理デバイス）を含む実施形態において、他の実施形態におけるそのような機能性に対応するものとして記載されるソフトウェアは省略されることがある。

メモリ２３０は、例えば、Ｌ１、Ｌ２、若しくはＬ３キャッシュ又はシステムメモリのような、様々なメモリを含んでよい。よって、メモリ２３０は、スタティックランダムアクセス記憶装置（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、フラッシュメモリ、読出し専用記憶装置（ＲＯＭ）、又は他の類似のメモリデバイスを含んでよい。

ユーザインタフェース２４０は、管理者のようなユーザとの通信を可能にする１以上のデバイスを含んでよい。例えば、ユーザインタフェース２４０は、ユーザコマンドを受信するディスプレイ、マウス、及びキーボードを含んでよい。幾つかの実施形態において、ユーザインタフェース２４０は、通信インタフェース２５０を介して遠隔端末に提示されてよいコマンドラインインタフェース又はグラフィカルユーザインタフェースを含んでよい。

通信インタフェース２５０は、他のハードウェアデバイスとの通信を可能にする１以上のデバイスを含んでよい。例えば、通信インタフェース２５０は、イーサネット（登録商標）プロトコルに従って通信するように構成される有線又は無線ネットワークインタフェースカード（ＮＩＣ）を含んでよい。加えて、ネットワークインタフェース２５０は、ＴＣＰ／ＩＰプロトコルに従って通信するためにＴＣＰ／ＩＰスタックを実装してよい。追加的に又は代替的に、通信インタフェース２５０は、ＮＦＣ、ブルートゥース（登録商標）、Ｗｉ−Ｆｉ又は他のローカル無線又は有線プロトコルに従った通信のためのハードウェアのような、近くのデバイスと通信するためのハードウェアを含んでよい。通信インタフェース２５０のための様々な代替的な又は追加的なハードウェア又は構成(configuration)が明らかであろう。

記憶装置２６０は、読出し専用記憶装置（ＲＯＭ）、ランダムアクセス記憶装置（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、又は類似の記憶媒体のような、１以上の機械可読記憶媒体を含んでよい。様々な実施形態において、記憶装置２６０は、プロセッサ２２０による実効のための命令又はプロセッサ２２０が作動するデータを格納してよい。

例えば、デバイス２００がユーザのスマートデバイス（例えば、携帯電話又はタブレット）を実装する場合、記憶装置２６０は、ハードウェア２００の様々な基本動作を制御するスマートデバイスオペレーティングシステム２６１を格納してよい。例えば、スマートデバイスオペレーティングシステム２６１は、クライアントアプリケーションを実行し且つ相互作用すること、様々なネットワーク接続性を管理すること、電話及びメッセージング通信を可能にすることなどのための環境を提供してよい。図示の実施形態において、スマートデバイスオペレーティングシステム２６１は、（上述の測定学(metrics)のうちの１以上のような）ユーザによるスマートデバイスの使用を記述する様々な情報を提供する使用情報報告命令２６２を含む。よって、この例示的な実施形態において、ＯＳは、図１のスマートデバイスモニタ１３０を実施する。特徴抽出命令２６３は、特徴抽出デバイス１４０を実施してよく、よって、１以上の特徴２６４を抽出する命令と、それらの特徴２６５をトレーニングセット創成デバイス又は予測デバイス１７０に（例えば、周期的に又はリアルタイムで）報告する命令とを含んでよい。

スマートデバイスは、（クライアントアプリケーションの独立した目的及び動作の故に開始のために望ましいと見做されるような）ユーザ対話をいつ開始するかを決定するための機会指標を利用することに関心のある（図１のクライアントアプリケーションデバイス１１０を実施することがある）１つ以上のクライアントアプリケーション２６６をホストして実行してもよい。よって、クライアントアプリケーション２６６のうちの１以上は、割込みサービスデバイス１２０に問い合わせること（即ち、プル要求）のための機会クエリ命令(opportunity query instructions)又は割込みサービスデバイスからの更新を要求すること（即ち、プッシュ要求）のための機会加入命令２６８(opportunity subscription instructions)を含んでよい。例えば、クライアントアプリケーション２６６は、ユーザが実行を試みることを提案するメッセージをユーザに表示することを欲する場合がある。メッセージを表示する前に、クライアントアプリケーション２６６は、機会クエリ命令２６７を介して、割込みサービスデバイス１２０に問い合わせて、ユーザがそのようなユーザ対話に行動することに現在可用でないことを学習することがある。それに応答して、クライアントアプリケーション２６６は、メッセージを後の配信のために待ち行列に入れてよく、そして、割込みサービスデバイス１２０が、ユーザが可用になるときをクライアントアプリケーションデバイス２６６に通知することを、機会加入命令２６８を介して要求してよい。その後、そのような更新を受信した後に、クライアントアプリケーション２６６は、（例えば、スマートデバイスオペレーティングシステム２６１の通知サービスを介して）メッセージをユーザに出力してよい。クライアントアプリケーション２６６は、ユーザが可用である(available)／受容性がある(receptive)／その他であることが判明したか否か（又はそのような結論を引き出す際に有用な使用又は他のフィードバック情報）を、トレーニングセット創成デバイス１５０に報告する、フィードバック命令２６９を含んでもよい。

デバイス２００がサポートサーバを実施する場合、記憶装置２６０は、サーバオペレーティングシステムを格納してよい。サーバがクラウドコンピューティングアーキテクチャ内に配置される幾つかの実施形態において、サーバオペレーティングシステムは、１以上の仮想マシンを調整するハイパーバイザ(hypervisor)を含んでよく、次いで、ハイパーバイザは、追加的な命令及びデータ２７２〜２７９を含んでよい。トレーニングセット創成命令２７２は、トレーニングセット創成デバイス１５０を実施してよく、よって、特徴報告デバイスから特徴セットを受信し、そこから新しいトレーニング例を創成して、トレーニングセット２７４を形成してよい。フィードバック解釈命令２７３は、（例えば、図示しないトレーニングされたフィードバック解釈モデルを使用して）クライアントアプリケーションデバイス１１０又は他のソースからのフィードバックを解釈して、予測モデルをトレーニングする際に使用するためにトレーニング例にラベル（標識）を付けてよい。

予測モデルトレーニング命令２７５は、予測モデルトレーニングデバイス１６０を実施してよく、よって、トレーニングセット２７４又はその一部分に基づいて１以上の予測モデル２７６をトレーニングしてよい。例えば、予測モデルトレーニング命令２７５は、回帰又は（深部学習を含む）ニューラルネットワーク予測モデル２７６を例示化する(instantiating)１以上のシータ重み値(theta weight values)を学習する勾配降下(gradient descent)の形態を実装してよい。トレーニングされたモデル２７７を用いるならば、モデルアプリケーション命令モデル２７７は、特徴抽出デバイス１４０から特徴を受信し、次に、（複数の）モデル２７６を適用することによって、予測デバイス１７０を実施して、ユーザの文脈状態の１以上の測定値を取得してよい。次に、クエリサービス命令２７８又は加入サービス命令は、機会表示（例えば、「可用である」、「受容的であるが可用でない」、又は文脈状態測定値自体）を、プル式又はプッシュ式にクライアントアプリデバイス１１０にそれぞれ提供することによって、割込みサービスデバイス１２０を実施してよい。

記憶装置２６０に格納されるものとして記載される様々な情報は、代替的に又は追加的にメモリ２３０に格納されてよいことは明らかであろう。この点に関して、メモリ２３０は、「記憶装置」を構成すると考えられてもよく、記憶装置２６０は、「メモリ」を構成すると考えられてよい。様々な他の構成も明らかであろう。更に、メモリ２３０及び記憶装置２６０は、両方とも、「非一時的な機械可読媒体」であると考えられてよい。本明細書において使用するとき、「非一時的」という用語は、一時的な信号を排除するが、揮発性メモリ及び不揮発性メモリの両方を含む全ての形態の記憶装置を含むことが理解されるであろう。

ホストデバイス２００は、各々の記載するコンポーネントのうちの１つを含むものとして示されているが、様々なコンポーネントは、様々な実施形態において重複されてよい。例えば、プロセッサ２２０は、複数のプロセッサが協働して本明細書に記載する機能性を達成するよう、本明細書に記載する方法を独立して実行するように構成される或いは本明細書に記載する方法のステップ又はサブルーチンを実施するように構成される複数のマイクロプロセッサを含んでよい。更に、デバイス２００がクラウドコンピューティングシステムにおいて実施される場合、様々なハードウェアコンポーネントは、別個の物理システムに属してよい。例えば、プロセッサ２２０は、第１のサーバ内の第１のプロセッサと、第２のサーバ内の第２のプロセッサとを含んでよい。

図３は、適切な時にユーザ対話を行うシステム３００の第１の実施形態を例示している。システム３００は、（携帯電話又はタブレットのような）スマートデバイス３２０をクラウド仮想マシンサーバ３３０に相互接続する（キャリアネットワーク、ＬＡＮ、クラウドネットワーク、インターネット、又はそれらの組み合わせのような）ネットワーク３１０を含んでよい。システム３００は、図１の機能システム１００の実装を構成することがある。具体的には、図示のように、スマートデバイス３２０は、２つのクライアントアプリケーションデバイス１１０、スマートデバイスモニタ１３０、及び特徴抽出デバイス１４０を構成してよいのに対し、クラウドＶＭ３３０は、トレーニングセット創成デバイス１５０、予測モデルトレーニングデバイス１６０、予測デバイス１７０、及び割込みサービスデバイス１２０を構成してよい。

図示のように、スマートデバイス３２０は、（例えば、スマートデバイスＯＳのＡＰＩ内で又はＡＰＩを介して）使用モニタリング（監視）を行う使用モニタリングプロセス３２２と、（例えば、スマートデバイスＯＳのＡＰＩ内の又はそのＡＰＩを介した）使用モニタリングプロセスによって収集される未処理の使用情報から追加的な特徴を抽出する特徴抽出プロセス３２４とを含む。スマートデバイス３２０は、（生であろうと抽出されたものであろうと）関連する使用情報特徴をクラウドＶＭ３３０に送信し、トレーニングセット構築プロセス３３２が、クラウドＶＭ３３０で、それらの特徴をトレーニングセット３３４内の１以上の新しいトレーニング例として保存する(commits)。これらの記録に初めにラベルが付けられていないとしても、適切なラベルを識別するのに十分なフィードバックがひとたび得られると、トレーニングセット構築プロセス３３２は、引き続き、それらの例にラベルを付けてよい。次に、モデルトレーニングプロセス３３６は、トレーニングセット３３４を（直ちに又は後に）使用して、上述のような１以上の予測モデル３３８を創成してよく或いは更新してよい。

一方、モデルアプリケーションプロセス３４２は、予測モデル３３８の１０個の現在バージョンを入力特徴セットに適用して、ユーザの文脈状態のうちの１以上の測定値を決定し、この情報をクエリサービス３４４及び加入サービス３４６プロセスに利用可能にする。クライアントアプリケーション１ ３２６は、ユーザ対話を開始したいと思い、クエリサービス３４４にクエリを送信する。それに応答して、クエリサービス３４４は、モデルアプリケーションプロセス３４２によって提供される（複数の）測定値に基づいて、機会表示をクライアントアプリケーション１ ３２６に戻す。次に、クライアントアプリケーション１ ３２６は、この表示を使用して、ユーザ対話を開始することが適切な時であるか否かを決定してよい。ユーザ対話が開始されるならば、クライアントアプリケーション１ ３２６は、トレーニングセット構築プロセス３３２にフィードバックを報告してよい。

他方、クライアントアプリケーション２ ３２８は、ユーザ可用性に対する更新についてのプッシュ通知を受信する要望を加入サービスプロセス３４６に以前に示していることがある。例えば、クライアントアプリケーションは、機会表示に対するすべての変更に又は所定の値又は所定の値の群若しくは範囲への機会表示の変更に加入してよい。モデルアプリケーションプロセス３４２によって報告された（複数の）測定値に基づく機会表示に対する変更後に、加入サービス３４６は、新しい機会表示をクライアントアプリケーション２ ３２８にプッシュしてよい。クライアントアプリケーション２ ３２８は、この指示を使用して、ユーザ対話を開始することが適切な時であるか否かを決定してよい。ユーザ対話が開始されるならば、クライアントアプリケーション２ ３２８は、トレーニングセット構築プロセス３３２にフィードバックを報告してよい。

図４は、適切な時にユーザ対話を行うシステム４００の第２の実施形態を例示している。システム４００は、（携帯電話又はタブレットのような）スマートデバイス４２０をクラウド仮想マシンサーバ４３０に相互接続する（キャリアネットワーク、ＬＡＮ、クラウドネットワーク、インターネット、又はそれらの組み合わせのような）ネットワーク４１０を含んでよい。システム３００は、図１の機能システム１００の実装を構成することがある。具体的には、図示のように、スマートデバイス４２０は、スマートデバイスモニタ１３０、特徴抽出デバイス１４０、トレーニングセット創成デバイス１５０、予測モデルトレーニングデバイス１６０、予測デバイス１７０、及び割込みサービスデバイス１２０を構成することがある。ＶＭ１ ４４０は、クライアントアプリケーションデバイス１１０及び他の割込みサービスデバイス１２０を構成することがある。ＶＭ２ ４５０は、他のクライアントアプリケーションデバイスを構成することがある。

図示のように、この第２の実施形態において、機能デバイスの大部分は、スマートデバイス４２０自体に組み込まれている。文脈モニタリングプロセス４２２が、未処理の使用データを収集し、特徴抽出プロセス４２４は、そこから追加的な特徴を抽出する。トレーニングセット構築プロセス４２６が、これらの特徴及びフィードバック情報を使用して、トレーニングセット４２８を創成し、トレーニングセット４２８から、モデルトレーニングプロセス４３２が、ユーザの現在の文脈状態（例えば、可用性及び受容性）の１以上の測定値を決定する１以上の予測モデル４３４を創成する。モデルアプリケーションプロセス４３６が、（複数の）モデル４３４を新しい特徴セットに適用して、これらの測定値を決定し、次に、加入サービスプロセス４３８が、これらの測定値に基づく機会表示を、機会表示に対する変化についてのプッシュ通知を受信するよう以前に加入していたＶＭ１ ４４０に転送する。

ＶＭ１ ４４０は、ユーザの文脈状態を定期的に決定するスマートデバイス４２０と、スマートデバイス上で動作している通知受信アプリ（又はＯＳモジュール）に通知（又は他のユーザ対話）をプッシュするクライアントアプリケーション４５２をホストするＶＭ２ ４５０との間の媒介(intermediary)として確立される。例えば、通知プッシュアプリケーション４５２は、コーチングサービスのサーバ側にあってよいのに対し、通知受信アプリケーション４３９は、コーチングサービスのクライアント側（例えば、ダッシュボード又はメッセージセンタ）であってよい。媒介ＶＭ１ ４４０は、スマートデバイス４２０からの機会表示更新に加入して、要求に従ってＶＭ２ ４５０にそのような機会表示を提供してよい。よって、ＶＭ１ ４４０は、そのようなオンデマンド可用性を提供することをスマートデバイス４２０に要求せずに、ユーザ対話のための適切な時を決定するクエリサービスをＶＭ２ ４５０に提供する。幾つかの実施形態において、ＶＭ１ ４４０は、複数のスマートデバイス４２０から又は複数のユーザのために更新を受信して、ＶＭ２ ４５０又はクライアントアプリケーションをホストする他のサーバのための単一地点のクエリを提供してよい。よって、ＶＭ１ ４４０は、スマートデバイス４２０から機会表示を受信する加入クライアントプロセス４４２と、報告される機会表示４４４を格納することに捧げられたメモリと、要求に応じてこれらの機会表示をＶＭ２ ４５０に転送するクエリサービスプロセス４４６とを含む。上述のように、ＶＭ２ ４５０は、それ自体が機会クエリソフトウェアモジュール４５４を実装する、通知プッシュアプリケーション４５２を含む。例えば、機会クエリモジュール４５４は、クエリサービス４４６のＡＰＩによって要求される適切な手順及びフォーマットに従ったアプリケーション４５２コードの他の部分の要求で、要求機会表示を取り扱ってよい。

図３〜図４の例は図１の機能システムの２つの可能な例示化に過ぎないこと並びにその例示的なシステム１００の範囲内でより多くの構成が可能であることが理解されるであろう。例えば、第３の実施形態が、スマートデバイスモニタ１３０をウェアラブルデバイス（例えば、加速度計及びパルスセンサを備えるウエアラブル腕時計デバイス）上に配置し、他のスマートデバイスモニタ１３０、特徴抽出デバイス１４０、予測デバイス１７０、割込みサービスデバイス１２０、及びクライアントアプリケーションデバイス１１０を携帯電話上に配置し、トレーニングセット創成デバイス１５０及び予測モデルトレーニングデバイス１６０を遠隔サーバ上に配置してよい。そのような実施形態では、トレーニングセットラベル付け及び予測モデルトレーニングの比較的リソース集中的な動作のみが、携帯電話から遠隔サーバに「アウトソーシング」される。様々な追加的な実施形態が明らかであろう。更に他の実施形態において、第２の実施形態は、機会クエリモジュール４５４をスマートデバイス４２０上に移動するように修正されてよい。そのような実施形態において、通知プッシュアプリケーション４５２は、通知受信アプリケーション４３９に通知をプッシュしてよく、次に、通知受信アプリケーション４３９は、クエリを行って、受信した通知をユーザに提示するか否か又は受信した通知をユーザに提示する時を決定してよい。そのような実施形態の変形において、クエリは、遠隔ＶＭ１ ４４０上のクエリサービス４４６に対して向けられてよく、或いは（例えばスマートデバイス４２０内でもクエリサービス４４６を実施することによって）スマートデバイス４２０でローカルに行われてよい。

図５は、デバイスオペレーティングシステムから使用情報を収集する方法５００の一例を例示している。方法５００は、未処理の情報が基礎を成すＯＳによって（又は他の場所から）によって過渡的にのみ提供される未処理の使用情報を収集するためにスマートデバイスモニタ１３０によって行われる操作に対応してよい。幾つかの実施形態において、方法５００（又はそれに類似する方法）は、オペレーティングシステム２６１の部分として行われようが他のアプリケーションとして（例えば、特徴抽出命令２６３と共に）行われようが、使用情報報告命令２６２によって行われてよい。方法５００は、６個の異なる種類の未処理の使用情報を収集することを例示している。様々な他の追加的な又は代替的な未処理の使用情報、及びＯＳ、アプリ、又は他のソースから入手可能な情報からそのような未処理の使用情報を収集する方法は明らかであろう。他の実施形態において、これらの（又は他の）種類の未処理の使用情報の一部は、ＯＳ、アプリ、又は他のソースによって直接的に提供されてよいことが更に明らかであろう。例えば、幾つかの実施形態において、ＯＳは、通常動作を通じて、ＡＰＩを介して、受信された並びに送信されたメッセージのログを方法５００に提供してよい。他の実施形態では、未処理の使用情報を収集するために、方法５００はＯＳ自体によって実装されてよく、他のＯＳモジュール、アプリ、及び他のソースとインタフェース接続されてよい。これらの代替的な実施形態を可能にする方法５００に対する様々な変更は明らかであろう。

方法５００は、ステップ５０５で開始し、ステップ５０５で、方法は、（例えば、ＯＳによって提供される事象バスを介して）１つ以上のＯＳ事象の表示を受信する。ステップ５１０において、方法５００は、受信した事象が、ユーザが自分の電話をロック解除したことを示すか否かを決定する。受信した事象がどの情報を伝えるかを決定する特定のアプローチは、方法５００が相互作用するＯＳに特異である。この決定５１０（及び後続の決定）を実施するための特定のステップは、ＯＳの観点から明らかであろう。事象がロック解除事象に関連するならば、方法５００は、ステップ５１５に進み、ステップ５１５で、デバイスは、最後のデバイスロック解除の時を格納する追跡された変数を更新する。

次に、ステップ５２０において、デバイスは、ＯＳ事象が、メッセージ（例えば、テキスト又はマルチメディアメッセージ）が送信されたか或いは受信されたことを示すか否かを決定する。そうであるならば、デバイスは、メッセージ５２５（例えば、メッセージ内容、時間、送信者、又は受信者）を記録し、ステップ５２５の連続的な実行を通じて創成されるメッセージログを参照することによって最後の５分（又は何らかの他の有用な時間窓）内に受信したメッセージの実行カウントを更新する。メッセージログ及びカウントの両方は、特徴としての後の使用のために又はそこから追加的な特徴を抽出するために格納されてよい。ステップ５３５において、デバイスは、ＯＳ事象が、ユーザが異なるアプリケーションに切り替わったことを示すか否かを決定する。そうであるならば、デバイスは、ステップ５４０における実行ログ内の切替え（例えば、時間、以前のアプリケーション、及び新しいアプリケーション）を記録し、ステップ５４５における前の５分（又は他の時間窓）内のアプリケーション切替えの数を再カウントし、ステップ５４５における前の５分（又は他の時間窓）内にユーザによって開始されたアプリケーション切替えの数を再カウントし、ステップ５５０における前の５分（又は他の時間窓）内にユーザによって起動された特異なアプリケーションの数を再カウントする。切替えログ及びカウントは、特徴としての後の使用のために或いはそこから追加的な特徴を抽出するために格納されてよい。次に、方法５００は、ステップ５５５に進んで、終了する。

方法５００は未処理の使用情報を収集する方法の一例に過ぎないこと、並びに様々な代替的なアプローチが続いてよいことは明らかであろう。例えば、幾つかの実施形態では、専用のアルゴリズムがＯＳ事象の各タイプ又はその複数のグループについて定められてよい。例えば、ＯＳ事象の各種類についての事象バスと登録した後、デバイスは、その種類のＯＳ事象を処理するための専用のアルゴリズムを登録してよい。よって、事象バスは、実際には、ステップ５１０、５２０、５３５の作業を行う。何故ならば、特定のＯＳ事象を処理するためのアルゴリズムのみが呼び出されるからである。

図６は、予測モデルトレーニング又はアプリケーションにおける使用のための特徴セットを生成する方法６００の一例を例示している。方法６００は、使用情報を抽出して、未処理の使用情報及び抽出された使用情報の両方を１以上の予測モデルによって使用される特徴セット内に収集するために、特徴抽出デバイスによって行われる、操作に対応してよい。幾つかの実施形態において、方法６００は、特徴抽出命令２６３又は特徴報告命令２６５に対応してよい。方法６００は、例えば、定期的又は方法５００の実行の直後のような、様々な時に行われてよい。

方法６００は、（例えば、定期的に発生するように構成されたスケジュールタスクとしての実行に基づいて）ステップ６０５において開始し、ステップ６１０に進んで、ステップ６１０で、デバイスは、空の特徴セットデータオブジェクトを創成する。ステップ６１５において、デバイスは、（例えば、方法５００又はそれに類似する方法に従って）ＯＳ又は他のソースをモニタリングすることによって追跡された未処理の使用情報についての現在値を空の特徴セットに複製（コピー）する。例えば、最後のロック解除の時、メッセージログ、及びアプリケーションログは、特徴セットに複製されてよい。次に、ステップ６２０において、デバイスは、ＯＳ（又は他のアプリ又は他のソース）から直接的に利用可能な特徴として使用されるあらゆる未処理の使用情報についてＯＳをポーリングする。例えば、ＯＳは、現在の接続情報（例えば、ネットワーク、データ使用量）又は現在のデバイス状態のような情報を提供することができる。次に、この情報は、ステップ６２５において特徴セットに複製されてもよい。

ステップ６３０において、デバイスは、存在する使用情報から特徴を抽出するために適用されるために利用可能ないずれかのアルゴリズムがあるか否かを決定する。例えば、デバイスは、各特徴セットについて順番に実行されるべき一群のスクリプト、ＪＡＲファイルなどを格納してよい。特徴抽出を方法６００自体に単に符号化することのような様々な代替も可能である。適用する特徴抽出アルゴリズムがあるならば、これらの各々はステップ６３５において行われ（例えば、関数として呼び出される或いはスクリプトとして実行され）、その結果は、ステップ６４０において特徴セットに複製される。次に、方法はステップ６４５に進んで終了する。次に、特徴は、将来のある時点で或いは方法６００がステップ６４５で終了する前の最終ステップ（図示せず）としてトレーニングセット創成デバイス１５０又は予測デバイス１７０に送信されてよい。幾つかの実施形態において、デバイスは、複数の特徴セット（例えば、５分毎の新しい特徴セット）を収集し、それらを（例えば、１時間又は他の時間期間毎に或いは他のデバイスによる要求に応じて）他のデバイスのうちの１つにバッチとして一緒に送信してよい。送信スケジュールは、トレーニングセット創成デバイス１５０及び予測デバイス１７０への送信について同じである必要はない。例えば、特徴抽出デバイス１４０は、特徴のバッチをトレーニングセット創成デバイスに毎時送信してよいのに対し、新しい特徴セットが最新の機会表示を有効にするために使用可能になるときに、各々の新しい特徴セットを予測デバイスに送信してよい。様々な他の修正が明らかであろう。

図７は、１以上の予測モデルをトレーニングするためのトレーニングセット７００のある例を例示している。このトレーニングセット７００は、トレーニングセット２７４に対応してよく、報告された特徴セット及びフィードバックからトレーニングセット創成デバイス１５０によって創成されてよい。図示のように、セットは、複数のラベルを含み、よって、複数の予測モデル（例えば、受容性モデル及び可用性モデル）をトレーニングするために使用されてよい。１以上のトレーニングセットを格納する様々な代替的な構成が使用されてよいことが理解されるであろう。例えば、幾つかの実施形態では、各モデルがトレーニングされるために、別個のトレーニングセットが構築されてよい。そのようなトレーニングセットは、（例えば、共通の特徴を備えない或いは含められる特徴に幾らかのオーバーラップのみを備える）異なる特徴セット又は異なるラベルを含んでよい。代替的に、幾つかの実施形態において、トレーニングセット７００は（例えば、監督されていない学習或いは部分的に監督された学習について）ラベル付けられなくてよく、或いはラベルは特徴とは異なるデータ構造に格納されてよい。加えて、データセットを格納するための基礎となるデータ構造は表でなくてよく、例えば、アレイ、リスト、ツリー、又は他のデータ構造のような様々な他の形態をとってよい。特徴、ラベル、又は他の情報（例えば、一部の実施形態では、時刻のような、タイムスタンプから導き出される特徴又は複数の特徴として使用されてもよい、タイムスタンプ）についての追加的なフィールド（欄）が明らかであろう。

図示のように、トレーニングセット７００は、特徴７１０のセットと、ラベル７２０のセットとを含む。特徴７１０のセットは、各トレーニング例について報告された特徴を格納する様々なフィールドを含んでよい。一例として、トレーニングセット７００は、そのとき現在のデバイス状態を格納するデバイス状態フィールド７１２、ユーザが関与する通信（例えば、通話及びテキストメッセージ）についての情報を格納する通信フィールド７１４、ユーザによって使用されるアプリについての情報を格納するアプリ使用フィールド７１６と、デバイスのそのとき現在の接続情報を格納する接続フィールド７１８とを含む。ラベル７２０は、ユーザがユーザ対話に物理的に関与するために「可用である」とみなされたか否のラベルを格納する可用フィールド７２２と、ユーザがユーザ対話に心理的に関与するために「受容的である」とみなされた否かのラベルを格納する受容性フィールド７２４とを含む。ブールラベルが示されており、（ロジスティック回帰モデルをトレーニングするのに有益であることがあるが）、他の実施形態では、数値が（例えば、線形回帰モデルをトレーニングする際の使用のために）これら２つの測定値のラベルとして提供されてよい。これらの数値は、ラベルが当て嵌まる確率又はラベルが当て嵌まる程度に対応することがある（例えば、１００の可用性は、ユーザがジョグに行くことができることを示してよいのに対し、２０の可用性は、ユーザがジョギングに行くことができず、オフィスの周りを短時間歩くことができることを示してよい）。様々な代替的な測定値が提供されてよいことも明らかであろう。例えば、可用性は、各々のラベルが、ユーザが可用である異なる種類、グループ分け、又は身体活動の程度にそれぞれ対応する、複数のラベルに分解されてよく、それにより、複数の程度の可用性、受容性、又はユーザの文脈状態の他の測定値の各々について異なるモデルのトレーニングを可能にする。予測モデルに関して、本明細書に記載するトレーニングセット創成、モデルトレーニング、及びモデルアプリケーションへのアプローチの実質的にいずれも、ラベル付けモデルの操作を可能にするために利用されてよい。

一例として、トレーニング例７３０は、（「作業ＳＳＩＤ」と呼ばれ、「ウェブブラウザアプリ」を現在使用している、ＷｉＦｉアクセスポイントへの接続を含む）特定の機能セットについて、ユーザは入って来るユーザ対話に対して受容的であるが、それらに直ちに対応するよう可用でないと判断されたことを示している。トレーニング例７４０は、（今のところ３５分続いている通話の中に現在いるユーザを含む）異なる特徴セットについて、ユーザはユーザ対話を受け入れることについて受容的でなく可用でもないと判断されたことを示すことがある。第３のトレーニング例は、（デバイスが現在ロックされており、過去５分中にアプリが使用されていないことを含む）他の報告された特徴セットがまだラベル付けられていないことを格納する。フィードバック情報の受信後、トレーニングセット創成デバイス１５０は、この例７５０に戻って、ラベルを提供してよい。例えば、フィードバックが、ユーザ、他の人間のユーザ、又はクライアントアプリケーションからのマニュアル入力である場合、フィードバックは、例７５０に添付されるべきラベル自体を含んでよい。フィードバックが、ラベルを未だ含まない後続の使用情報又は他の情報である場合、トレーニングセット創成デバイス１５０は、フィードバックを解釈して、例７５０への添付のための（複数の）ラベルを生成してよい。例えば、トレーニングセットは、データ構造内の特徴又は各々のそれぞれのラベルがある例に当て嵌まるか否かを決定する受信されたフィードバックに適用される各々の各潜在的ラベルについて、トレーニングされたモデル（例えば、回帰モデル又はニューラルネットワーク）を含んでよい。予測デバイス１７０によって適用される予測モデルと混同されるべきでない、これらのラベル付けモデルは、人間のユーザによって手作業でラベル付けされてよい更に他のトレーニングセット（図示せず）に基づいてトレーニングされてよい。そのようなトレーニングを達成するために、勾配降下のバージョンのような様々な学習アプローチが適用されてよい。

図８は、トレーニング例を創成して文脈状態予測を生成するために特徴セットを処理する方法８００の一例を例示している。方法８００は、トレーニングセット創成デバイス１５０、予測デバイス１７０及び割込みサービスデバイス１２０によって行われる操作に対応してよい。幾つかの実施形態において、方法８００は、トレーニングセット創成命令２７２、モデルアプリケーション命令２７２又はクエリサービス命令２７８に対応してよい。様々な代替的なアプローチが実施されてよいことが明らかであろう。例えば、幾つかの実施形態では、トレーニングセットを更新し且つ予測モデルを適用するために、別個の異なるアルゴリズムが定められてよい。

方法８００は、（例えば、特徴抽出装置から又はスケジュールされたタスクに基づいて新しい特徴セットを取得することに応答して）ステップ８０５において開始し、ステップ８１０に進み、ステップ８１０で、デバイスは、トレーニングが、受信する特徴セットと関連するユーザのために現在有効にされているか否かを決定する（例えば、幾つかの実施形態において、トレーニングは、予測モデルがメモリ及び処理リソースを節約するよう十分にトレーニングされているとみなされるときに、オフにされてよい）。トレーニングがオフにされるならば、方法８００は、スキップしてステップ８２５に進んでよい。そうでないならば、デバイスは、受信する特徴セットを格納し且つ新しいトレーニング例を既存のトレーニングセットの部分として格納するトレーニング例の新しい記録を創成する。理解されるように、特徴セットは、命令を実行しているデバイスに依存して様々なソースから取得されてよい。取得することは、他のデバイスから特徴セットを受信すること（例えば、特徴抽出デバイス１４０及び予測デバイス１７０が物理的に別個のデバイスに実装される場合）又は（例えば、ソケット又は共有メモリを介して）他のローカルプロセスから特徴セットを受信すること（例えば、特徴抽出デバイス１４０及び予測デバイス１７０が同じデバイス内の別個のプロセス又はＯＳモジュールとして実装される場合）を含んでよい。

ステップ８２５において、デバイスは、受信した特徴セットに１以上の予測モデルを適用して、ユーザの現在の文脈状態の１以上の測定値を取得する。ステップ８３０において、デバイスは、（例えば、以前に利用できなかったユーザが現在利用可能であるならば、或いは受容性が６０の値から２０の値に減少したならば）決定された文脈状態が以前に決定された文脈状態と異なるか否かを決定し、そうであるならば、ステップ８３５に進み、ステップ８３５で、デバイスは、決定された文脈状態を現在の文脈状態として格納する（以前の文脈状態を潜在的に上書きする）。

ステップ８４０において、加入サービスデバイスは、任意のクライアントアプリケーションがこのユーザについての更新に以前に加入していたか否かを決定し、そうであるならば、ステップ８４５において新しい文脈状態を加入したアプリケーションにプッシュする。このアプローチは、クライアントアプリケーションが全ての更新に単に加入する実施形態にとって十分なことがある。クライアントアプリケーションが、更新がプッシュされるべきとき（例えば、ユーザが利用可能になるとき、受容性又は可用性が増加するとき、又は受容性が少なくとも５０であるとき）についての１以上の基準を特定することがある他の実施形態では、追加的な条件ブロックをステップ８４０とステップ８４５との間で実行して、更新がどのクライアントアプリケーションにプッシュされるかを決定するためにどのクライアントアプリケーションの基準が満たされたかを決定してよい。次に、方法は、ステップ８５０に進んで終了する。

図９は、受信したフィードバックに基づいて予測モデルを更新する方法９００の一例を例示している。方法９００は、トレーニングセット創成デバイス１５０及び予測モデルトレーニングデバイス１６０によって行われる操作に対応してよい。幾つかの実施形態において、方法９００は、トレーニングセット創成命令２７２（若しくはフィードバック解釈命令２７３）又は予測モデルトレーニング命令２７５に対応してよい。様々な代替的なアプローチが実施されてよいことは明らかであろう。例えば、幾つかの実施形態では、トレーニングセットを更新し且つ予測モデルをトレーニングするために、別個の異なるアルゴリズムが定められてよい。

方法は、（例えば、フィードバック情報の受信に応答して或いはスケジュールされたタスクに基づいて）ステップ９０５において開始し、ステップ９１０に進み、ステップ９１０で、デバイスは、受信したフィードバックから１以上のラベルを解釈する。例えば、ステップ９１０は、フィードバックから手作業で提供されたラベルを単に読み取ること又は別個のトレーニングモデル（例えば、ロジスティック回帰のような分類モデル）をフィードバック（及び、幾つかの実施形態では、ラベル付けされるべき関連トレーニング記録中に格納される特徴）に適用することを含んでよい。ステップ９１５において、デバイスは、（例えば、そこに格納された特徴セットが創成又は受信されたときのタイムスタンプに基づいて）フィードバックと同時に存在する任意の記録を探し出してよい。幾つかの実施形態では、未だラベル付けられていないトレーニング例のみがステップにおいて探し出されてよいのに対し、他の実施形態では、追加的なフィードバックに基づいて以前にラベル付けされた例を更新するために、ラベル付けされていない例及びラベル付けされた例が取得されてよい。ステップ９２０において、デバイスは、解釈された（複数の）ラベルに従って各抽出されたトレーニング例の記録にラベルを付ける。

ステップ９２５において、デバイスは、トレーニングセットの減衰(decay)が有効化されているか否かを決定してよい。例えば、幾つかの実施形態では、新しい記録が追加されたときに、古いトレーニング例は（少なくとも現在のフィードバックが当て嵌まるユーザに関して）トレーニングセットから除去されてよい。これは、ユーザの集団から引き出された例に基づいた一般的なトレーニングセットを最初に使用され、徐々に補充し、特定のユーザに基づいて創成された例に置き換えることにより、システムの動作をユーザの挙動及び習慣に個人化（パーソナライズ）する場合に、特に有用であることがある。減衰が有効化されるならば、デバイスは、（例えば、最も古い記録を削除することによって或いは最も古い記録が現在のユーザのトレーニングモデルとして使用されないようにフラグを立てることによって）ステップ９３５において最も古い記録をトレーニングセットから削除する。幾つかの実施形態において、１つの古いトレーニング例は、減衰が有効化されているときに各々の新しいトレーニング例について削除されてよいが、他の割合も可能である。

ステップ９３５において、デバイスは、（複数の）予測モデルがトレーニングされた最後の時間から、幾つの新しい記録が追加されたか（或いは幾つの記録がラベル付けされたか）を決定する。この数が５（又は適切とみなされる何らかの他の閾値）を超えるならば、方法９００はステップ９４５に進み、トレーニングセットの現在の反復に関する予測モデルを再トレーニングする。スケジュールされた時にモデルを再トレーニングすることのようなモデル再トレーニングのための適切な時を特定するための様々な代替的な方法が明らかであろう。次に、方法９００はステップ９５０に進んで終了する。

図１０は、モデルをトレーニングする方法１０００の一例を例示している。方法１０００は、予測モデルトレーニングデバイス１６０によって行われる操作に対応してよく、予測モデルトレーニング命令２７５によって実施されてよい。例えば、プログラマ定義アルゴリズム(programmer-defined algorithms)、ニューラルネットワーク、ベイジアンネットワーク(Bayesian network)などのような、モデルトレーニングに対する様々な代替的なアプローチが明らかであろう。

方法は、ステップ１００２において開始し、ステップ１００４に進み、ステップ１００４で、デバイスは、モデルが創成されるべき所与のパラメータのためにラベル付けされたデータセット（例えば、予測モデルをトレーニングするためのトレーニングセット７００又はラベル付けモデルをトレーニングするための他のトレーニングセット（図示せず））を取得する。ラベル付けられていないトレーニングセットからモデルをトレーニングするための様々な代替的なアプローチが明らかであろう。様々な実施形態において、トレーニングセットは、１以上の特徴（例えば、上述のような様々な使用情報又はフィードバック情報など）及びその特徴セットから引き出される適切な結論を特定するトレーニング例の多数の記録を含んでよい。

ステップ１００６において、デバイスは、データセット内で識別された特徴の数（或いはモデルがデータセット内のあらゆる特徴を利用しない場合には、トレーニングされているモデルに関連する特徴の数）を識別し、ステップ１００８において、結果として得られるモデルにおいて使用されるべき係数のセットを初期化する。様々な実施形態によれば、定数として機能する１つの追加的な係数と共に、係数が各特徴について創成される。モデルが数値を出力するようにトレーニングされている場合、線形回帰アプローチが利用されてよく、その場合、最終モデル関数は、以下の形態を取り、

ここで、Ｘは、特徴｛ｘ_１，ｘ_２，．．．｝のセットであり、係数｛θ_０，θ_１，θ_２，．．．｝を方法１１００によって調整して、トレーニングデータセットから学習される傾向と一致する適切な関連性推定(relevance estimation)を出力として提供する。幾つかの実施形態において、最終モデル関数は、以下のようなシグモイド関数を組み込んでよく、

ここで、係数の調整は、提供(offering)の関連性の推定として働く０〜１の間の値を出力する関数ｈ（Ｘ）をもたらす。様々な実施形態によれば、係数はゼロの値に全て初期化される。 幾つかの実施形態では、ｈ（Ｘ）に含めるための追加的な特徴（及び関連する係数）は、例えば、ｘ_１ ^２又はｘ_１ｘ_２のような、トレーニングセット内の特徴からを構築されてよいことが明らかであろう。

方法は、ステップ１０１０，１０１２において２つのループ変数ｉ及びｐを０にそれぞれ初期化することによって、係数をトレーニングすることを開始する。次に、ステップ１０１４において、デバイスは、現在の係数θ_ｐに関するコスト関数Ｊ（θ）(cost function)の偏導関数(partial derivative)を取得し、ここで、コスト関数は、幾つかの実施形態において、以下のように定められてよく、

ここで、ｍは、トレーニングデータセット内のトレーニング例の数であり、ｈ_θ（ｘ）は、現在の係数セットθを使用するトレーニングされた関数であり、ｘ^（ｊ）は、ｊ番目のトレーニング例についての特徴のセットであり、ｙ^（ｊ）は、ｊ番目のトレーニング例についての所望の出力（即ち、ラベル）である。よって、バッチ勾配降下アプローチに続いて、係数ｐ（θ_ｐ）に関する偏導関数は、以下の通りであり、

ここで、ｘ_ｐ ^（ｊ）は、ｊ番目のトレーニング例におけるｐ番目の特徴（又は、ｐ＝０のとき、ｘ_ｐ ^（ｊ）＝１）である。

ステップ１０１６において、デバイスは、ｐを増分し、ステップ１０１８において、デバイスは、ｐがｈ（Ｘ）に含められるべき特徴の総数を今や超えているか否かを決定することによって、全ての係数が現在のループ内でアドレス指定されているか否かを決定する。そうでないならば、方法はステップ１０１４に戻り、次の偏導関数項を見出す。

現在の反復について全ての偏導関数が見出された後に、方法１０００は、ステップ１０２０において、ループ変数ｐをゼロにリセットすることに進む。次に、ステップ１０２２において、デバイスは、ステップ１１１４において見出される対応する偏導関数に基づいて並びに事前設定された学習速度に基づいて、ｐ番目の係数θ_ｐを更新する。例えば、デバイスは、以下の更新ルールを適用してよく、

ここで、αは、例えば、０．１，０．３，１、又は各反復についての所望の変化速度のために適切に選択される任意の他の値のような、学習速度である。

ステップ１０２４において、デバイスは、ｐを増分し、ステップ１０２６において、デバイスは、ｐがｈ（Ｘ）に含められるべき特徴の総数を今や超えているか否かを決定することによって、全ての係数が現在のループ内でアドレス指定されている否かを決定する。そうでないならば、方法はステップ１０２２に戻り、次の係数を更新する。方法１０００によれば、全ての偏導関数は、偏導関数が部分的に更新された値に基づいて取られないよう、第２のループ内の係数を実際に修正する前に第１のループ内で見出されることに留意のこと。他の実施形態は、係数のそのような「同時」更新を実施しないことがある。

全ての係数が更新された後に、方法１０００は、ステップ１０２８に進み、ステップ１０２８で、変数ｉは増分される。ステップ１０３０において、デバイスは、方法１０００が無限にループしないことを保証するために、所定の最大反復回数を今や超えているか否かを決定する。１０００回、５０００回、１００００回などのような、十分に高い最大反復回数が選択されてよい。最大の反復に達していないならば、方法１０００は、ステップ１０３２に進み、ステップ１０３２で、デバイスは、トレーニングセットに基づいて、コスト関数ｊ（θ）を使用して、現在のコストを計算する。ステップ１０３４において、デバイスは、最後の反復から現在の反復までのコストの変化が最小閾値を満たさないか否かを決定することによって、関数ｈ（Ｘ）が許容可能な解に収束したか否かを決定する。変化が閾値を超えるならば、方法１０００は、ステップ１０１２に戻り、別の係数更新ループを行う。他方、最大反復に達するか、或いはコストの変化が最小閾値より下であるならば、方法１０００は、ステップ１０３６に進み、ステップ１０３６で、デバイスは、パラメータを抽出するための新しいモデルの一部として係数を格納し、方法１０００はステップ１０３８に進んで終了する。

回帰以外の後続のアプローチに加えて、他の実施形態は、バッチ勾配降下以外の回帰アプローチにおいて係数を調整するために異なる方法を利用してよいことが、明らかである。例えば、幾つかの実施形態は、確率的勾配降下を使用してよく、各々の係数更新は、単一のトレーニング例に基づいて行われ（それにより、偏導関数から合計が除去され）、方法は、更に、各々のそのような例を通じて追加的に反復する。他の実施形態では、回帰のための正規方程式を使用して、行列ベースの非反復的アプローチを使用して適切な係数を見出してよく、係数のセットは、以下のように計算され、

ここで、Ｘは、全てのトレーニング例からの特徴の行列であり、ｙは、ラベルの関連ベクトルである。

前述によれば、様々な実施形態は、クライアントアプリケーションがユーザ対話を開始するための適切なときを決定する手段を提供する。スマートフォン又は他のデバイスの使用をモニタリングすることによって、オペレーティングシステム又は他のサービスは、ユーザが様々な種類の対話を受信する用意があるときを識別することがある。更に、異なる種類の機会（例えば、物理的機会に対する精神的機会又はその段階(gradations)）の異なる機械学習モデルをトレーニングすることによって、対話のための適切なときの識別を、特定の種類、フォーマット、媒体、又はクライアントアプリケーションによって開始されるように提案される或いは望まれるユーザ対話のコンテンツに合わせて更に調整することができる。様々な追加的な利益は、前述の観点から明らかであろう。

本発明の様々な例示的実施形態がハードウェア又はファームウェアにおいて実施されてよいことが前述の記述から明らかであるはずである。更に、様々な例示的な実施形態は、本明細書に詳細に記載する動作を行うるために少なくとも１つのプロセッサによって読み取られて実行されることがある、機械可読記憶媒体に格納された命令として実装されてよい。機械可読記憶媒体は、パーソナルコンピュータ若しくはラップトップコンピュータ、サーバ、又は他のコンピューティングデバイスのような機械によって読み取り可能な形式において情報を格納する任意の機構（メカニズム）を含んでよい。よって、機械可読記憶媒体は、読出し専用記憶装置（ＲＯＭ）、ランダムアクセス記憶装置（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、及び類似の記憶媒体を含んでよい。

当業者は、本明細書中のあらゆるブロック図が本発明の原理を具現する例示的な回路構成の概念図を表すことを理解するはずである。同様に、あらゆるフローチャート、フロー図、状態遷移図、擬似コード、及び同等物は、機械可読媒体中に実質的に表され、よって、コンピュータ又はプロセッサが明示的に示されていようが示されていまいが、そのようなコンピュータ又はプロセッサによって実行されることがある、様々なプロセスを表すことが理解されるであろう。

様々な例示的な実施形態をその特定の例示的な態様を特に参照して詳細に記載したが、本発明は他の実施形態が可能であり、その詳細は様々な明らかな態様において変更可能であることが理解されるべきである。当業者には容易に明らかであるように、本発明の精神及び範囲内に留まりながら、変形及び修正をもらさすことができる。従って、前述の開示、記述及び図は、例示的な目的のためだけにあり、請求項によってのみ定められる本発明を如何様にも限定しない。

Claims (27)

1. ユーザ対話に適したときを決定するために予測デバイスによって行われる方法であって、
   ユーザが前記ユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信するステップと、
   ユーザデバイス上の前記ユーザの最近の活動に関する使用情報を取得するステップと、
   前記ユーザの現在の文脈状態を識別するために少なくとも１つのトレーニングされた予測モデルを前記使用情報に適用するステップと、
   前記ユーザの文脈状態に基づいて機会表示を決定するステップと、
   前記クライアントアプリケーションに前記機会表示を提供するステップとを含み、
   前記現在の文脈状態は、
   前記ユーザが前記ユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値、及び
   前記ユーザが前記ユーザ対話に注意を払う能力を表す受容性測定値
   のうちの少なくとも１つを含む、
   方法。
2. 前記機会表示は、前記現在の文脈状態を含む、請求項１に記載の方法。
3. 前記使用情報のうちの少なくとも一部は、前記ユーザデバイスのオペレーティングシステムのアプリケーションプログラマインタフェース（ＡＰＩ）を介して取得される、請求項１に記載の方法。
4. 前記受信するステップ、前記取得するステップ、前記適用するステップ、前記決定するステップ、及び前記提供するステップは、前記ユーザデバイスのプロセッサによって行われる、請求項１に記載の方法。
5. 前記少なくとも１つのトレーニングされた予測モデルを遠隔予測モデルトレーニングデバイスから受信するステップを更に含む、請求項１に記載の方法。
6. 前記クライアントアプリケーションに前記機会表示を提供するステップに続いて、
   前記クライアントアプリケーションに対する前記ユーザの反応に関するフィードバック情報を取得するステップと、
   前記ユーザの可用性及び受容性のうちの少なくとも１つに関するラベルを前記フィードバック情報から見分けるステップと、
   前記ラベルを前記使用情報と関連付けることによってトレーニング例を生成するステップと、
   更新されたトレーニングセットを生成するために、前記トレーニング例を既存のトレーニングセットに少なくとも追加することによって、前記既存のセットを更新するステップと、
   該更新されたトレーニングセットに基づいて前記少なくとも１つのトレーニングされた予測モデルを再トレーニングするステップとを更に含む、
   請求項１に記載の方法。
7. 前記見分けるステップは、トレーニングされたフィードバック解釈モデルを前記フィードバック情報に適用して前記ラベルを受信するステップを含む、請求項６に記載の方法。
8. 前記フィードバック情報は、前記機会表示を前記クライアントアプリケーションに提供することに続く前記ユーザデバイス上の前記ユーザ活動を記述する、請求項６に記載の方法。
9. 前記見分けるステップは、前記ユーザが自分の使用挙動を変更したか否かを決定するために前記使用情報と共に前記フィードバック情報を分析するステップを含む、請求項８に記載の方法。
10. ユーザ対話に適したときを決定する予測デバイスであって、
    ユーザの現在の文脈状態を識別する少なくとも１つのトレーニングされた予測モデルを格納するように構成されたメモリと、
    該メモリと通信するプロセッサとを含み、
    前記現在の文脈状態は、
    前記ユーザが前記ユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値、及び
    前記ユーザが前記ユーザ対話に注意を払う能力を表す受容性測定値
    のうちの少なくとも１つを含み、
    前記プロセッサは、
    ユーザがユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信し、
    ユーザデバイス上の前記ユーザの最近の活動に関する使用情報を取得し、
    少なくとも１つのトレーニングされた予測モデルを前記使用情報に適用し、
    前記ユーザの文脈状態に基づいて機会表示を決定し、且つ
    該機会表示を前記クライアントアプリケーションに提供する
    ように構成される、
    予測デバイス。
11. 前記機会表示は、前記現在の文脈状態を含む、請求項１０に記載の予測デバイス。
12. 前記使用情報のうちの少なくとも一部は、前記ユーザデバイスのオペレーティングシステムのアプリケーションプログラマインタフェース（ＡＰＩ）を介して取得される、請求項１０に記載の予測デバイス。
13. 当該予測デバイスは、前記ユーザデバイスを含み、前記メモリ及び前記プロセッサは、前記ユーザデバイスのコンポーネントである、請求項１０に記載の予測デバイス。
14. 前記プロセッサは、遠隔予測モデルトレーニングデバイスから少なくとも１つのトレーニングされた予測モデルを受信するように構成される、請求項１０に記載の予測デバイス。
15. 前記プロセッサは、
    前記クライアントアプリケーションに前記機会表示を提供するステップに続いて、
    前記クライアントアプリケーションに対する前記ユーザの反応に関するフィードバック情報を取得し、
    前記ユーザの可用性及び受容性のうちの少なくとも１つに関するラベルを前記フィードバック情報から見分け、
    前記ラベルを前記使用情報と関連付けることによってトレーニング例を生成し、
    更新されたトレーニングセットを生成するために、前記トレーニング例を既存のトレーニングセットに少なくとも追加することによって、前記既存のセットを更新し、且つ
    該更新されたトレーニングセットに基づいて前記少なくとも１つのトレーニングされた予測モデルを再トレーニングする
    ように更に構成される、
    請求項１０に記載の予測デバイス。
16. 見分ける際に、前記プロセッサは、トレーニングされたフィードバック解釈モデルを前記フィードバック情報に適用して前記ラベルを受信するように構成される、請求項１５に記載の予測デバイス。
17. 前記フィードバック情報は、前記機会表示を前記クライアントアプリケーションに提供することに続いて、前記ユーザデバイス上の前記ユーザの活動を記述する、請求項１５に記載の予測デバイス。
18. 見分ける際に、前記プロセッサは、前記使用情報と共に前記フィードバック情報を分析して、前記ユーザが自分の使用挙動を変更したか否かを決定するように構成される、請求項１７に記載の予測デバイス。
19. ユーザ対話に適したときを決定するために予測デバイスによって行われるよう符号化された非一時的な機械可読媒体であって、
    当該非一時的な機械可読媒体は、
    ユーザがユーザ対話に参加する用意があるか否かの表示についてクライアントアプリケーションから要求を受信することについての命令と、
    ユーザデバイス上の前記ユーザの最近の活動に関する使用情報を取得することについての命令と、
    前記ユーザの現在の文脈状態を識別するために少なくとも１つのトレーニングされた予測モデルを前記使用情報に適用することについての命令と、
    前記ユーザの文脈状態に基づいて機会表示を決定することについての命令と、
    該機会表示を前記クライアントアプリケーションに提供することについての命令とを含み、
    前記現在の文脈状態は、
    前記ユーザが前記ユーザ対話と関連する身体的活動を行う現在の能力を表す可用性測定値、及び
    前記ユーザが前記ユーザ対話に注意を払う能力を表す受容性測定値
    のうちの少なくとも１つを含む、
    非一時的な機械可読媒体。
20. 前記機会表示は、前記現在の文脈状態を含む、請求項１９に記載の非一時的な機械可読媒体。
21. 前記使用情報のうちの少なくとも一部は、前記ユーザデバイスのオペレーティングシステムのアプリケーションプログラマインタフェース（ＡＰＩ）を介して取得される、請求項１９に記載の非一時的な機械可読媒体。
22. 前記受信すること、前記取得すること、前記適用すること、前記決定すること、及び前記提供することは、前記ユーザデバイスのプロセッサによって行われる、請求項１９に記載の非一時的な機械可読媒体。
23. 前記少なくとも１つのトレーニングされた予測モデルを遠隔予測モデルトレーニングデバイスから受信することを更に含む、請求項１９に記載の非一時的な機械可読媒体。
24. 前記クライアントアプリケーションに前記機会表示を提供することに続いて、
    前記クライアントアプリケーションに対する前記ユーザの反応に関するフィードバック情報を取得すること、
    前記ユーザの可用性及び受容性のうちの少なくとも１つに関するラベルを前記フィードバック情報から見分けること、
    前記ラベルを前記使用情報と関連付けることによってトレーニング例を生成すること、
    更新されたトレーニングセットを生成するために、前記トレーニング例を既存のトレーニングセットに少なくとも追加することによって、前記既存のセットを更新すること、並びに
    該更新されたトレーニングセットに基づいて前記少なくとも１つのトレーニングされた予測モデルを再トレーニングすることを更に含む、
    請求項１９に記載の非一時的な機械可読媒体。
25. 前記見分けることは、トレーニングされたフィードバック解釈モデルを前記フィードバック情報に適用して前記ラベルを受信することを含む、請求項２４に記載の非一時的な機械可読媒体。
26. 前記フィードバック情報は、前記機会表示を前記クライアントアプリケーションに提供することに続く前記ユーザデバイス上の前記ユーザ活動を記述する、請求項２４に記載の非一時的な機械可読媒体。
27. 前記見分けることは、前記ユーザが自分の使用挙動を変更したか否かを決定するために前記使用情報と共に前記フィードバック情報を分析することを含む、請求項２６に記載の非一時的な機械可読媒体。

Images