(57)【特許請求の範囲】
【請求項１】
アンビエントコンピューティングシステムであって、
センサ信号を生成するように構成される１つ以上のセンサと、
コントローラと、
低パワー処理コンポーネント、マシンラーニングエンジン、および１つ以上の他の処理コンポーネントを含む複数の処理コンポーネントとを含み、
前記アンビエントコンピューティングシステムは、動作を行なうように構成されており、前記動作は、
前記コントローラが１つ以上のセンサ信号の存在を示す割り込みを受け取るまでモニタリング電力状態に留まることと、
前記コントローラが前記割り込みを受け取ると、前記モニタリング電力状態から処理電力状態に遷移することとを含み、前記処理電力状態に遷移することによって、前記アンビエントコンピューティングシステムは前記低パワー処理コンポーネントをアクティベートし、前記動作はさらに、
前記マシンラーニングエンジンが前記１つ以上のセンサ信号を使用して推論パスを行なうべきであると、前記１つ以上のセンサ信号を使用して前記低パワー処理コンポーネントが判断することと、
それに応答して、前記１つ以上のセンサ信号をさらに処理するためにアクティベートされるべきである前記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表わす出力を生成するよう、前記１つ以上のセンサ信号を入力として使用して前記マシンラーニングエンジンが前記推論パスを行なうことと、
前記マシンラーニングエンジンの前記出力によって表される前記１つ以上の他の処理コンポーネントをアクティベートすることと、
前記マシンラーニングエンジンの前記出力によって表される前記１つ以上の他の処理コンポーネントが前記１つ以上のセンサ信号を処理することとを含む、アンビエントコンピューティングシステム。
【請求項２】
割り込みを受け取ることは、センサが環境入力を受け取ることに応答して周辺インターフェイスによって生成される割り込みを受け取ることを含む、請求項１に記載のアンビエントコンピューティングシステム。
【請求項３】
前記低パワー処理コンポーネントは、低パワーＣＰＵである、請求項１または２に記載のアンビエントコンピューティングシステム。
【請求項４】
前記低パワー処理コンポーネントは、低パワーＤＳＰである、請求項１または２に記載のアンビエントコンピューティングシステム。
【請求項５】
前記１つ以上のセンサ信号をさらに処理するためにアクティベートされるべきである前記アンビエントコンピューティングシステムの前記１つ以上の他の処理コンポーネントは、高パワーＤＳＰ、メインＣＰＵクラスタ、またはメインマシンラーニングエンジンを含む、請求項４に記載のアンビエントコンピューティングシステム。
【請求項６】
前記動作は、前記マシンラーニングエンジンの前記出力が、前記１つ以上のセンサ信号をさらに処理するためにアクティベートされるべき前記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表すということを、前記低パワー処理コンポーネントが判断することをさらに含む、請求項１〜５のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項７】
割り込みを受け取ることは、タイマがタイムアウトすることに応答して前記タイマによって生成される割り込みを受け取ることを含む、請求項１〜６のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項８】
前記複数の処理コンポーネントは、ランダムアクセスメモリバンクを共有し、前記モニタリング電力状態から前記処理電力状態に遷移することは、前記ランダムアクセスメモリバンクをアクティベートすることを含む、請求項１〜７のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項９】
前記複数の処理コンポーネントは、通信ファブリックによって通信可能に結合され、前記モニタリング電力状態から前記処理電力状態に遷移することは、前記通信ファブリックをアクティベートすることを含む、請求項１〜７のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項１０】
前記アンビエントコンピューティングシステムが前記モニタリング電力状態にある間、前記アンビエントコンピューティングシステムは、前記低パワー処理コンポーネントおよび前記マシンラーニングエンジンを非動作状態に維持する、請求項１〜９のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項１１】
前記低パワー処理コンポーネントおよび前記マシンラーニングエンジンを前記非動作状態に維持することは、電力を供給しないこと、または、しきい値を下回るレベルの電力を供給することを含む、請求項１０に記載のアンビエントコンピューティングシステム。
【請求項１２】
前記アンビエントコンピューティングシステムが前記モニタリング電力状態にある間、前記アンビエントコンピューティングシステムは、ＳＲＡＭおよび通信ファブリックを非動作状態に維持する、請求項１０に記載のアンビエントコンピューティングシステム。
【請求項１３】
前記アンビエントコンピューティングシステムが前記モニタリング電力状態にある間、前記アンビエントコンピューティングシステムは、制御サブシステムを動作状態に維持し、処理サブシステムを非動作状態に維持する、請求項１０に記載のアンビエントコンピューティングシステム。
【請求項１４】
前記マシンラーニングエンジンは、１つ以上のセンサ信号の特徴を入力として取得するマシンラーニングモデルであって、前記１つ以上のセンサ信号をさらに処理すべき前記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表す出力を生成するマシンラーニングモデルを実現する、請求項１〜１３のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項１５】
前記動作は、前記１つ以上の他の処理コンポーネントによる前記センサ信号の処理が完了すると、前記処理電力状態から前記モニタリング電力状態に遷移することをさらに含む、請求項１〜１４のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項１６】
前記マシンラーニングエンジンは、アンビエントマシンラーニングエンジンであり、前記１つ以上の他の処理コンポーネントはメインマシンラーニングエンジンを含み、前記アンビエントマシンラーニングエンジンは、前記メインマシンラーニングエンジンより小さい処理パワーを有する、請求項１〜１５のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項１７】
アンビエントコンピューティングシステムであって、
センサ信号を生成するように構成される１つ以上のセンサと、
低パワー処理コンポーネント、マシンラーニングエンジン、および１つ以上の他の処理コンポーネントを含む複数の処理コンポーネントとを含み、
前記アンビエントコンピューティングシステムは、
前記低パワー処理コンポーネントが、特定のセンサ信号が特定の特性を有すると判断することと、
それに応答して、前記マシンラーニングエンジンをアクティベートすることと、
前記マシンラーニングエンジンが、モデル出力を生成するよう、前記センサ信号を使用してマシンラーニングモデルに対して推論パスを行うことと、
前記マシンラーニングエンジンの前記モデル出力がアプリケーション固有の条件とマッチすると判断することと、
それに応答して、前記アプリケーション固有の条件に対応する特定のアプリケーションを実行するために、前記他の処理コンポーネントのうちの１つ以上をアクティベートすることとを行うように構成される、アンビエントコンピューティングシステム。
【請求項１８】
前記マシンラーニングエンジンの前記モデル出力がアプリケーション固有の条件にマッチすると判断することは、前記低パワー処理コンポーネントによって行われる、請求項１７に記載のアンビエントコンピューティングシステム。
【請求項１９】
前記特定のセンサ信号が特定の特性を有すると判断することは、前記特定のセンサ信号が人間のスピーチに対応するオーディオ信号であると判断することを含む、請求項１７または１８に記載のアンビエントコンピューティングシステム。
【請求項２０】
前記アプリケーション固有の条件は、特定の人間のスピーチの発生であり、前記アプリケーションは、前記特定の人間のスピーチに対するテキストツースピーチオーディオ応答を生成することを含む、請求項１９に記載のアンビエントコンピューティングシステム。
【請求項２１】
前記マシンラーニングエンジンは、学習された生オーディオリカレントニューラルネットワークを使用して前記テキストツースピーチオーディオ応答を生成する、請求項２０に記載のアンビエントコンピューティングシステム。
【請求項２２】
前記アンビエントコンピューティングシステムは、人間のスピーチに対応する前記オーディオ信号を認識し、かつ、メインＣＰＵクラスタを初期化することなく前記テキストツースピーチオーディオ応答を生成するように構成される、請求項２１に記載のアンビエントコンピューティングシステム。
【請求項２３】
前記特定のセンサ信号が特定の特性を有すると判断することは、前記特定のセンサ信号がユーザの近接を示すレーダ信号であると判断することを含む、請求項１７〜２２のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項２４】
前記アンビエントコンピューティングシステムは、モバイルコンピューティングデバイスのコンポーネントであり、前記アプリケーション固有の条件は、ユーザによる特定のジェスチャの発生である、請求項２３に記載のアンビエントコンピューティングシステム。
【請求項２５】
前記アプリケーションは、前記モバイルコンピューティングデバイスのディスプレイをオンにすること、または、前記モバイルコンピューティングデバイスをアンロックすることを含む、請求項２４に記載のアンビエントコンピューティングシステム。
【請求項２６】
前記アンビエントコンピューティングシステムは、モバイルコンピューティングデバイスのコンポーネントであり、前記アプリケーション固有の条件は、特定のタイプの音の発生であり、前記アプリケーションは、前記モバイルコンピューティングデバイスの位置を記録することを含む、請求項１７〜２５のいずれか１項に記載のアンビエントコンピューティングシステム。
【請求項２７】
アンビエントコンピューティングシステムおよび付加的なコンポーネントを含む、パワードデバイスであって、前記パワードデバイスは、
センサ信号を生成するように構成される１つ以上のセンサと、
コントローラと、
低パワー処理コンポーネントと、マシンラーニングエンジンと、他の処理コンポーネントとを含む複数の処理コンポーネントを含むアンビエントコンピューティングシステムとを含み、
前記アンビエントコンピューティングシステムは、
前記コントローラが割り込みを受け取るまで、モニタリング電力状態に留まることと、
前記コントローラが前記割り込みを受け取ると、前記モニタリング電力状態から処理電力状態に遷移することとを行うように構成され、前記処理電力状態に遷移することによって、前記アンビエントコンピューティングシステムは前記低パワー処理コンポーネントをアクティベートし、前記アンビエントコンピューティングシステムはさらに、
前記マシンラーニングエンジンが１つ以上のセンサ信号をさらに処理するべきであることを特定する出力を生成するよう、前記低パワー処理コンポーネントが前記割り込みを処理することと、
前記１つ以上のセンサ信号をさらに処理するべきである前記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表わす出力を生成するよう、前記マシンラーニングエンジンが前記１つ以上のセンサ信号を処理することと、
前記出力に応答して、前記センサ信号を処理するのに十分であると前記マシンラーニングエンジンの前記出力によって識別される前記１つ以上の他の処理コンポーネントのみをアクティベートすることと、
前記マシンラーニングエンジンの前記出力によって識別される前記１つ以上の他の処理コンポーネントを使用して前記１つ以上のセンサ信号を処理することとを行うように構成され、
前記コントローラは、処理された前記センサ信号に応答して、前記パワードデバイスの付加的なコンポーネントをアクティベートするように構成される、パワードデバイス。
【請求項２８】
前記マシンラーニングエンジンはアンビエントマシンラーニングエンジンであり、前記パワードデバイスの前記付加的なコンポーネントはメインマシンラーニングエンジンを含み、前記アンビエントマシンラーニングエンジンは、前記メインマシンラーニングエンジンよりも小さい処理パワーを有する、請求項２７に記載のパワードデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
本明細書は、アンビエントコンピューティング（ambient computing）に関する。
【背景技術】
【０００２】
たとえばスマートフォン、携帯情報端末、電子タブレットおよびラップトップなどといったモバイルコンピューティングデバイスは、典型的には、１つ以上の再充電可能バッテリによって供給される電力を使用する。再充電可能バッテリは、バッテリが再充電されなければならなくなる前に、たとえばバッテリに電流を適用することによってデバイスに有限量の電力のみを供給する。モバイルコンピューティングデバイスのバッテリを再充電することは、一般に、モバイルコンピューティングデバイスを電気グリッドに接続することを必要とする。これにより、そのモビリティが低減または除去される。したがって、モバイルコンピューティングデバイスの電力消費を低減し、それによってそれらのバッテリ寿命を延ばすことは、重要な目的である。
【０００３】
モバイルコンピューティングデバイスは、１つ以上の周辺センサを含み得る。たとえば、いくつかのモバイルコンピューティングデバイスは、マイクロフォン、カメラ、および加速度計などを含む。モバイルコンピューティングデバイスはさらに、１つ以上の周辺センサによって収集されるデータを処理するために１つ以上の処理コンポーネントを含み得る。たとえば、いくつかのモバイルコンピューティングデバイスは、中央処理装置（ＣＰＵ： central processing unit）、デジタル信号プロセッサ（ＤＳＰ： digital signal processor）、または他の処理コンポーネントを含む。
【０００４】
モバイルコンピューティングデバイスは、それらの１つ以上の周辺センサによって収集されるとともにそれらの１つ以上の処理コンポーネントによって処理されるデータに基づいて、アクションを行い得る。たとえば、いくつかのモバイルコンピューティングデバイスは、マイクロフォンによって検出されるとともにＣＰＵによって処理されるボイスコマンドに応答してアクションを行い得る。しかしながら、センサデータを処理できるように処理コンポーネントをアクティブ状態に維持することは、有意な電力を消費する。
【発明の概要】
【課題を解決するための手段】
【０００５】
概要
本明細書では、コンピューティングデバイス上で低パワーアンビエントコンピューティングを実現するための技術が記載される。本明細書に記載されるアンビエントコンピューティングシステムは、任意の所与の時間において、いくつかの異なる電力状態のうちの１つで動作する。各電力状態は、電源オンされるコンポーネントの組み合わせによって定義される。電源オンされるコンポーネントの組み合わせは、センサデータを入力として取得し、センサデータをさらに処理するために処理コンポーネントのどの組み合わせがアクティベートされるべきかを判断するのに使用され得る出力を生成する学習済モデルを実現するマシンラーニングエンジンによって判断され得る。
【０００６】
たとえば、最も低い電力のモニタリング電力状態では、システムは、周辺インターフェイスと、電力制御ユニット（ＰＣＵ： power control unit）を有する制御サブシステムとのみに電力を供給し得る。モニタリング電力状態では、周辺インターフェイスは、コンピューティングデバイスの環境から入力を受け取るよう待機し得る。
【０００７】
１つ以上の周辺インターフェイスが環境から入力を受け取り、対応するセンサ信号を生成すると、システムは、一般にモニタリング電力状態よりも多くの電力を消費する電力状態である処理電力状態に入り得る。処理電力状態では、システムは、たとえば低パワーＣＰＵまたは低パワーＤＳＰといった低パワー処理コンポーネントに電力を供給し、周辺インターフェイスによって受け取られるセンサ信号の初期解釈を実行する。たとえば、低パワー処理コンポーネントは、センサ信号がマシンラーニングエンジンの補助なしで解釈され得ること、または、センサ信号がマシンラーニングエンジンによってさらに解釈されるべきであることを、センサ信号の特性に基づいて判断し得る。
【０００８】
次いで、マシンラーニングエンジンは、潜在的に複数のより高いレベルの電力状態のうちの１つを表す出力を生成するようセンサ信号を使用し得る。各電力状態は、アクティベートされるべきコンポーネントの特定の組み合わせによって定義される。本明細書では、コンポーネントがアクティベートされることは、コンポーネントがデータを処理するのを開始するのに十分な付加的な電力をコンポーネントに供給することを意味する。この文脈では、コンポーネントは、オフまたは保持状態からアクティブな処理状態に遷移することによってアクティベートされる。より高いレベルの電力状態は、システムが、より高度で、より高パワーで、おそらく特殊化された処理コンポーネントをアクティベートすることによって達成され得る。当該処理コンポーネントは、たとえば、１つ以上の高パワーＤＳＰ、メインＣＰＵクラスタ、または高パワーマシンラーニングエンジンである。たとえば、マシンラーニングエンジンは、マイクロフォンが人間のボイスコマンドに対応するオーディオデータを受け取っていることを示す出力を生成し得る。次いで、当該出力によって、システムは、オーディオデータを処理するための特殊化されたオーディオＤＳＰに電力を供給し得る。
【０００９】
これらの技術は、センサデータの継続的なモニタリングに依存するさまざまな複雑なアプリケーションが、より低い消費電力状態で実行されることを可能にする。たとえば、システムは、受け取ったレーダ信号から、システムが実現されるコンピューティングデバイスのディスプレイにユーザの顔が向いていると判断する場合、ユーザから他の入力を受け取ることなく、自動的にコンピューティングデバイスのディスプレイをオンにするよう電力状態を通じて処理を行ない得る。
【００１０】
本明細書において記載される主題は、以下の利点のうちの１つ以上を実現するように特定の実施形態において実現され得る。アンビエントコンピューティングシステムは、さまざまな複雑なタスクを行ない得るが、以前のアプローチよりも消費される電力は少ない。マシンラーニングエンジンを使用することによって、電力の節約およびバッテリ寿命の増加がさらに改善される。マシンラーニングエンジンは、コンポーネントのカスタマイズされた組み合わせを表す出力を生成し得る。これにより、チップのすべてのコンポーネントを起動することか、または、チップのコンポーネントを起動しないことのいずれかを行う必要性がなくなる。このアプローチはさらに、ハードウェア制御ロジックを過度に複雑にすることなく、可能な電力状態の数を大きく増加させる。これらのアプローチはさらに、システムが、デバイスのメインＣＰＵクラスタを起動することなく環境の継続的なモニタリングを必要とする高度なタスクを行うことを可能にする。これは、アンビエントコンピューティングシステムが、電力消費も低減しつつ、その環境における変化に対してより応答性が高くなることを可能にする。したがって、アンビエントコンピューティングシステムは、コンピューティングデバイスのバッテリ寿命に対して限られた影響でより優れた機能を提供し得、複雑なアンビエント状態を有するコンピューティングデバイスの全バッテリ寿命を増加し得る。
【００１１】
本明細書の主題の１つ以上の実施形態の詳細は、添付の図面および以下の説明に記載される。主題の他の特徴、局面、および利点は、説明、図面、および請求の範囲から明らかとなるであろう。
【図面の簡単な説明】
【００１２】
【図１】例示的なアンビエントコンピューティングシステムの図である。
【図２】例示的なアンビエントコンピューティングシステムの電力状態の状態図である。
【図３】アンビエントコンピューティングシステムにおいて付加的な処理コンポーネントを連続的にアクティベートするための例示的なプロセスのフローチャートである。
【図４】アプリケーション固有の条件に対応するアプリケーションを扱うために特定の処理コンポーネントをアクティベートするための例示的なプロセスのフローチャートである。
【図５】ボイスコマンドに対するテキストツースピーチオーディオ応答を生成するための例示的なプロセスのフローチャートである。
【図６】ジェスチャ固有のアプリケーションを実行するための例示的なプロセスのフローチャートである。
【発明を実施するための形態】
【００１３】
さまざまな図面における同様の参照番号および呼称は、同様のコンポーネントを示す。
詳細な説明
図１は、低パワーアンビエントコンピューティング能力を含む例示的なコンピューティングデバイス１００の図である。デバイス１００は、いくつかの例を挙げると、たとえば、スマートフォン、スマートウォッチ、フィットネストラッカー、携帯情報端末、電子タブレット、ラップトップといった任意の適切なコンピューティングデバイスにおいて実現されるシステムを含み得る。コンピューティングデバイス１００のシステムは、コンピューティングデバイス１００が低電力状態に留まり得るが、システムの適切な処理コンポーネントを順次起動することにより環境からの入力を継続的にモニタリングし、かつ、当該入力に継続的に応答し得るように使用され得る。本明細書では、起動およびアクティベートという用語は、特定の処理コンポーネントまたは他の電子回路に増加した量の電力を供給することを意味するように使用される。システムは、起動またはアクティベートされている処理コンポーネントまたは他の回路に電力を供給していてもよく、供給していなくてもよい。換言すると、起動またはアクティベートされているコンポーネントは、以前に完全に電源を切られていてもよく、以前に完全に電源を切られていなくてもよい。処理コンポーネントを起動またはアクティベートすることによって、処理コンポーネントがブートプロセスを実行し、処理コンポーネントのための命令およびデータがランダムアクセスメモリにロードされることになる。代替的または付加的には、処理コンポーネントを起動またはアクティベートすることは、以前にサスペンドされた状態から再開することを含み得る。
【００１４】
コンピューティングデバイス１００の１つ以上のコンポーネントは、コンピューティングデバイス内のシステムオンチップ（ＳｏＣ： system on a chip）上で実現され得る。ＳｏＣは、単一のシリコン基板上に、または、たとえばシリコンインターポーザ、積層ダイ、または相互接続ブリッジを使用する複数の相互接続されたダイ上に、システムの各コンポーネントを含む集積回路であり得る。メインＣＰＵクラスタ１４０を含むコンピューティングデバイスの他のコンポーネントは、同じダイ上または別個のダイ上に実現され得る。コンピューティングデバイス１００は、センサ１１２、１つ以上のディスプレイ、バッテリ、および他のコンポーネントを含むコンポーネントを含み得、これらのコンポーネントは、ＳｏＣとは別個かつ独立しており、たとえば、共通のハウジング上に搭載され得る。
【００１５】
簡潔に述べると、以下にさらに詳細に記載されるように、デバイス１００は、コンピューティングデバイスの環境からの入力に基づいてセンサ信号を生成するように構成される多くの周辺センサ１１２を含む。デバイス１００は、システムにおいてコンポーネントへの電力およびセンサ信号の供給を制御するための制御サブシステム１２０を含む。デバイス１００は、センサ信号を処理するとともに出力を生成するための処理サブシステム１３０を含む。
【００１６】
デバイス１００はさらに、メインＣＰＵクラスタ１４０を含む。メインＣＰＵクラスタ１４０は、処理サブシステム１３０におけるデバイスとは別個の１つ以上の汎用プロセッサを含むコンピューティングデバイスのコンポーネントである。メインＣＰＵクラスタ１４０のプロセッサは、一般に、処理サブシステム１３０におけるデバイスのうちのいずれかよりも大きなコンピューティングパワーを有するので、メインＣＰＵクラスタ１４０のプロセッサも、処理サブシステム１３０におけるデバイスのうちのいずれかよりも多くの電力を消費し得る。
【００１７】
デバイス１００は随意に、メインマシンラーニング（ＭＬ： machine learning）エンジン１５０を含み得る。メインＭＬエンジン１５０は、１つ以上のマシンラーニングモデルを通じて推論パス（inference pass）を行うように構成される特殊目的の処理デバイスである。各推論パスは、マシンラーニングモデルの入力および学習されたパラメータ値を使用して、学習されたモデルによって予測される１つ以上の出力を生成する。メインＭＬエンジン１５０は、１つ以上のコンピュートタイル（compute tile）を含み得る。一般に、コンピュートタイルは、計算のセットを独立して実行するように構成される自己完結型コンピューテーショナルコンポーネント（self-contained computational component）である。メインＭＬエンジン１５０のタイルは、ネットワークに配置され得、かつ、メインＭＬエンジン１５０の各タイルがマシンラーニングモデルを通じて推論パスの一部分の動作を行なうように構成されるようにプログラムされ得る。たとえば、マシンラーニングモデルがニューラルネットワークである場合、メインＭＬエンジン１５０における各タイルは、ニューラルネットワークの１つのレイヤーの計算を行うように構成され得る。複数のコンピュートタイルを有する好適なマシンラーニングエンジンは、本願明細書において参照により援用される米国特許番号第９，７１０，２６５号に記載されている。メインＭＬエンジン１５０はさらに、アンビエントコンピューティングシステム１１０の処理サブシステム１３０におけるデバイスのうちのいずれかよりも高いパフォーマンスのコンピューティングパワーを提供する。したがって、メインＭＬエンジン１５０も、処理サブシステム１３０におけるデバイスのうちのいずれよりも多くの電力を消費する。
【００１８】
処理サブシステム１３０は、アンビエントマシンラーニングエンジン１３４を含む。アンビエントＭＬエンジン１３４も、１つ以上のマシンラーニングモデルを通じて推論パスを行うように構成される特殊目的の処理デバイスである。デバイス１００がメインＭＬエンジン１５０およびアンビエントＭＬエンジン１３４の両方を含む場合、アンビエントＭＬエンジン１３４は、より少ないコンピュートタイルを有する。したがって、アンビエントＭＬエンジン１３４は、メインＭＬエンジン１５０よりも少ない処理パワーを有し、メインＭＬエンジン１５０よりも少ない電力を消費する。たとえば、アンビエントＭＬエンジン１３４は、１個または２個のタイルとして実現され得る一方、メインＭＬエンジン１５０は、８〜１６個またはそれ以上の相互接続されたタイルを有し得る。
【００１９】
図示されていないが、コンピューティングデバイス１００は、そのようなコンピューティングデバイス上に一般的に見つけられる１つ以上の他のコンポーネントを含み得、いくつかの例を挙げると、当該他のコンポーネントはたとえば、ディスプレイ、モデム、グラフィック処理ユニット、ディスプレイプロセッサ、または特殊目的の画像プロセッサである。これらのコンポーネントは、以下で説明される低電力状態の間に電源が切られ得、センサ信号がそれらのアクティベーションを必要とするアプリケーションにマッチするとシステムが判断する場合にアクティベートされ得る。
【００２０】
デバイス１００は、多くの周辺センサ１１２を含む。周辺センサ１１２は、１つ以上のオーディオセンサ１０２と、１つ以上のレーダセンサ１０４と、１つ以上のタッチセンサ１０６と、グローバルポジショニングシステム（ＧＰＳ： Global Positioning System）センサ１０８と、加速度計１１０とを含む。システムは、付加的な周辺センサ、より少ない周辺センサ、または、代替的な周辺センサを含み得る。たとえば、システムは、Ｗｉ−Ｆｉ（登録商標）信号検出器、セルラー信号検出器、気圧計、温度計、磁力計、または他のタイプの周辺センサを含み得る。
【００２１】
周辺センサ１１２は、環境入力に応答してセンサ信号を生成するように構成されるデバイスであり得る。たとえばマイクロフォンといった１つ以上のオーディオセンサ１０２は、環境における音に基づいて、オーディオ信号を生成し得る。たとえば、オーディオセンサ１０２は、人間のスピーチに対応するオーディオ信号を生成し得る。１つ以上のレーダセンサ１０４は、コンピューティングデバイスの送信機によって発せられる反射された電波に基づいてレーダ信号を検出し得る。反射された電波における変動は、環境における動きを示し得る。たとえば、レーダセンサ１０４は、たとえばユーザがコンピューティングデバイスに近接してジェスチャを行っている際にユーザから反射されることによって受け取られるレーダ信号を生成し得る。同様に、１つ以上のタッチセンサ１０６は、デバイスの存在感知または圧力感知インターフェイス上でコンピューティングデバイスのユーザによって行われるタッチジェスチャによる信号を生成し得る。ＧＰＳセンサ１０８は、受け取られた位置データ通信に応答して信号を生成し得る。加速度計１１０は、コンピューティングデバイスが受ける加速度による信号を生成し得る。本明細書では、センサ信号が他の処理コンポーネントへの入力であると記載される場合はいつでも、当該入力は、センサ自身によって生成されるアナログ電気信号であり得るか、センサ信号のデジタル表現であり得るか、または、オリジナルの信号の１つ以上の特性を表すセンサ信号の処理されたデジタル表現であり得る。コンピューティングデバイス１００の周辺センサはさらに、いくつかの他の例を挙げると、慣性測定センサ、気圧計、比吸収率近接センサ（specific absorption rate proximity sensor）、および、ＷｉＦｉネットワーク名センサ（WiFi network name sensor）を含み得る。
【００２２】
アンビエントコンピューティングシステム１１０は、１つ以上の周辺インターフェイス１１４を含む。周辺インターフェイス１１４は、デバイスがその最も低い電力状態にあるときでも電源オンされるコンピューティングデバイス１００のコンポーネントであり得る。周辺インターフェイス１１４は、周辺センサ１１２から受け取られた入力をアンビエントコンピューティングシステム１１０によって使用されるセンサ信号に変換するための任意の適切な周辺インターフェイスを含み得る。たとえば、周辺インターフェイス１１４は、いくつかの例を挙げると、パルス密度変調（ＰＤＭ： pulse density modulation）インターフェイス、ＩＣ間サウンド（inter-IC sound）（Ｉ２Ｓ）インターフェイス、集積回路間（inter-integrated circuit）（Ｉ２Ｃ）インターフェイス、Ｉ３Ｃインターフェイス、時分割多重化（ＴＤＭ： time division multiplexed）インターフェイス、および、シリアル周辺インターフェイス（ＳＰＩ： serial peripheral interface）を含み得る。
【００２３】
周辺インターフェイス１１４の各々は、環境入力を検出すると、それぞれの割り込みを生成するように構成される。一般に、各割り込みは、たとえば、当該割り込みを担う周辺インターフェイスまたはセンサの識別子といった、センサデータの源を識別し得る。割り込みは、１つ以上の割り込みコントローラ１２４によって受け取られて処理される。たとえば、割り込みを受け取ると、割り込みコントローラ１２４は、電力管理ユニット（ＰＭＵ： power management unit）１２２およびクロック制御ユニット１２３を含む電力制御ユニット（ＰＣＵ）１２１を起動し得る。ＰＭＵ１２２は、デバイス１００のどのコンポーネントが電力を受け取るかと、各コンポーネントがどのくらいの電力を受け取るかとを制御し得る。クロック制御ユニット１２３は、デバイス１００のコンポーネントが動作する周波数を制御し得る。いくつかの実現例では、各処理コンポーネントは、ベースクロック周波数の倍数または分数である異なるクロック周波数を有する。ベースクロック周波数の倍数または分数であるクロック周波数を有することによって、各処理コンポーネントは、他の処理コンポーネントとより効率的に信号を交換し得る。
【００２４】
割り込みを受け取ると、ＰＣＵ１２１は、割り込みの源に基づいて、割り込みを引き起こすセンサ信号をさらに処理するためにアンビエントコンピューティングシステム１１０のどの他のコンポーネントがアクティベートされるべきかを判断し得る。そのようなコンポーネントのための処理のサポートを提供するために、ＰＣＵ１２１は、スタティックランダムアクセスメモリ（ＳＲＡＭ： static random access memory）１３９およびシステム通信ファブリックを起動し得る。ファブリックは、アンビエントコンピューティングシステム１１０の内部コンポーネントを通信可能に結合する通信サブシステム、外部コンポーネントへのそれらの通信、または、これらの何らかの組み合わせである。ファブリックは、たとえばバスまたは専用の相互接続回路といった通信ハードウェアの任意の適切な組み合わせを含み得る。
【００２５】
スタティックランダムアクセスメモリ（ＳＲＡＭ）１３９は、処理サブシステム１３０の複数の処理コンポーネントによって共有され得る汎用のランダムアクセスメモリデバイスであり得る。たとえば、ＳＲＡＭ１３９は、センサ信号と、プロセッサ命令およびデータと、システム出力と、たとえばアンビエントＭＬエンジン１３４によって実現されるかまたは実現されることになるニューラルネットワークモデルのニューラルネットワークパラメータといった他のデータとを格納し得る。一般に、ＳＲＡＭは、周期的にリフレッシュされる必要がないという点で、ダイナミックランダムアクセスメモリ（ＤＲＡＭ： dynamic random-access memory）と区別可能である。以下により詳細に説明するように、ＳＲＡＭ１３９は、処理サブシステム１３０における処理コンポーネントに直接的にアクセス可能であるか、または、１つ以上のＤＭＡコントローラを介してアクセス可能である。いくつかの実現例では、ＳＲＡＭ１３９は、たとえば、各々１ＭＢ、１０ＭＢ、または１００ＭＢといった実質的に同様の量のデータを各々格納し得る複数のバンクを含む。さらに、各個々のバンクは、低電力状態に入るときに個々に電源が切られ得る複数のブロックを含み得る。４つのバンク間でブロックの電源が切られる順序を注意深く順序付けることによって、ＳＲＡＭアドレススペースは連続したままであり得る。
【００２６】
ＰＣＵ１２１がＳＲＡＭ１３９を起動すると、ＰＣＵ１２１は、ＳＲＡＭ１３９のすべてのブロックまたはすべてのメモリバンクよりも少ないブロックまたはメモリバンクを起動し得る。代わりに、ＰＣＵ１２１は、処理サブシステム１３０の次のコンポーネントがデバイス１００のコンポーネントの電源投入をさらに増加させるか否かを判断するのに十分な数のブロックのみを起動し得る。
【００２７】
ＰＣＵ１２１はさらに、ＳＲＡＭ１３９の異なるブロックに異なる電力レベルを供給し得る。たとえば、モニタリング電力状態では、ＰＭＵ１２２は、ＳＲＡＭ１３９全体に対してより低い保持電圧を供給し得、これによりその電力消費を低減し得る。ＰＭＵ１２２はさらに、処理コンポーネントがＳＲＡＭ１３９にアクセスする必要がない場合、ＳＲＡＭ１３９に保持電圧を供給し得る。処理電力状態では、ＰＭＵ１２２は、ＳＲＡＭ１３９のすべてまたは部分に通常の電圧を供給し得、ＳＲＡＭ１３９の他の部分には低下した電圧を供給するか、または電圧を供給しない。
【００２８】
割り込みを処理するプロセスの間、アンビエントコンピューティングシステム１１０はさらに、１つ以上のＤＭＡコントローラ１２８を起動し得る。ＤＭＡコントローラ１２８は、入力されるセンサ信号についてより高いデータ帯域幅を可能にするＤＭＡ経路を管理し得る。たとえば、ＤＭＡコントローラ１２８は、処理サブシステム１３０において処理コンポーネントによるアクセスのために、マイクロフォンからＳＲＡＭ１３９にオーディオデータを連続的にストリーミングするために使用され得る。反対に、ＤＭＡコントローラはさらに、ＳＲＡＭ１３９に格納されたオーディオデータを１つ以上のスピーカを通じて音として出力するために連続的にストリーミングするように使用され得る。ＤＭＡコントローラ１２８はさらに、任意の適切なセンサデータをＳＲＡＭ１３９にストリーミングするために使用され得るが、プログラムされたＩＯを使用することが、少量のデータのためにＤＭＡコントローラをアクティベートするよりも計算上安価であり得る。したがって、アンビエントコンピューティングシステム１１０は、たとえば、オーディオデータおよびレーダデータといった相対的に高帯域幅のセンサデータのためにＤＭＡコントローラ１２８をアクティベートおよび使用し得、他のタイプのセンサデータのためにプログラムされたＩＯを使用し得る。
【００２９】
ファブリックおよびＳＲＡＭ１３９を準備した後、ＰＣＵ１２１は、処理サブシステム１３０のどの他のコンポーネントを起動すべきかを判断するために、割り込みを使用し得る。たとえば、ＰＭＵ１２２は、低パワーＣＰＵ１３２、低パワーＤＳＰ１３６、または処理サブシステム１３０の他のコンポーネントに電力が供給されるか否かを、１つ以上のセンサのうちどれが割り込みを生成したかに依存して制御し得る。いくつかの実現例では、周辺インターフェイス１１４と制御サブシステム１２０のコンポーネントとのみが、モニタリング電力状態において電源オンされるデバイス１００のコンポーネントである。モニタリング電力状態は、システムがコンピューティングデバイスへの環境入力による割り込みを受け取るよう待機している電力状態である。
【００３０】
処理サブシステム１３０の処理コンポーネントは、低パワーＣＰＵ１３２、アンビエントＭＬエンジン１３４、低パワーＤＳＰ１３６、および高パワーＤＳＰ１３８を含む。いくつかの実現例では、処理サブシステムは、たとえば、複数の低パワーＤＳＰまたは複数の高パワーＤＳＰといったこれらのコンポーネントのうちの１つ以上のうちの複数のインスタンスを有する。たとえば、処理サブシステム１３０は、オーディオ信号を処理するために専用である１つの高パワーＤＳＰと、レーダ信号を処理するために専用である別個の高パワーＤＳＰとを有し得る。代替的または付加的には、処理サブシステム１３０は、画像データを処理するために専用である高パワーＤＳＰを有し得る。
【００３１】
モニタリング電力状態では、処理サブシステム１３０における処理コンポーネントは、保持モードで維持され得る。ＰＣＵ１２１は、コンポーネントに供給される電力を低減または除去することによって、コンポーネントを保持モードに維持し得る。たとえば、保持モードでは、ＰＣＵ１２１は、レジスタ状態を維持するのに十分な電力だけを処理コンポーネントに供給し得るが、レジスタにおいてデータを処理するのに十分な電力は供給しない。
【００３２】
低パワーＣＰＵ１３２は、レジスタ、制御回路、および算術論理演算装置（ＡＬＵ：arithmetic logic unit）を含む汎用のプログラマブルプロセッサであり得る。一般に、低パワーＣＰＵ１３２は、コンピューティングデバイスのメインＣＰＵクラスタ１４０よりも少ない電力を消費し、より少ない処理コアを含み得る。いくつかの実現例では、低パワーＣＰＵ１３２は、主に、単一の命令および単一のデータ入力に対して動作するスカラープロセッサである。
【００３３】
低パワーＣＰＵ１３２は、システムが処理電力状態に入ると、割り込みおよびセンサ信号を受け取り得る。低パワーＣＰＵ１３２が受け取るセンサ信号のタイプと、それらのセンサ信号の特性とに基づいて、低パワーＣＰＵ１３２は、たとえば、通信ファブリック、ＤＭＡコントローラ１２８、ＳＲＡＭ１３９、またはこれらの何らかの組み合わせといったシステムの他のコンポーネントがアクティベートされるべきと判断し得る。これらのコンポーネントをアクティベートした後、低パワーＣＰＵ１３２は随意に非動作状態に戻り得る。
【００３４】
低パワーＣＰＵ１３２は、センサ信号またはその処理されたバージョンを、さらなる解釈のためにアンビエントＭＬエンジン１３４に提供し得る。たとえば、低パワーＣＰＵ１３２が加速度計入力に対応するセンサ信号を受け取る場合、低パワーＣＰＵ１３２は、アンビエントＭＬエンジン１３４がセンサ信号をさらに処理すべきであると判断し得る。たとえば、アンビエントＭＬエンジン１３４は、センサ信号をさらに処理して、当該信号が、ウォーキング、ジョギング、バイキング（biking）、落下（falling）、または、車での移動を表すと判断し得る。
【００３５】
低パワーＣＰＵ１３２はさらに、いくつかの信号についてはアンビエントＭＬエンジン１３４をバイパスさせ得る。たとえば、低パワーＣＰＵ１３２がコンピューティングデバイスのタッチインターフェイス上の単純なタッチ入力に対応するセンサ信号を受け取る場合、低パワーＣＰＵ１３２は、たとえば、メインＣＰＵクラスタ１４０またはグラフィックプロセッサによってコンピューティングデバイスのディスプレイをオンにすることによって、他の処理コンポーネントの補助なしにタッチ入力を処理し得る。低パワーＣＰＵ１３２はさらに、コンピューティングデバイスのメインＣＰＵクラスタ１４０、またはデバイス１００の外部のコンピューティングデバイスの別のコンポーネントが、あるセンサ信号をさらに処理すべきであると判断し得る。低パワーＣＰＵ１３２は、たとえば、デバイス１００における他の処理コンポーネントがセンサ信号を適切に処理できないと判断すると、そのような判断を行ない得る。
【００３６】
アンビエントＭＬエンジン１３４の１つのタスクは、センサ信号をさらに処理するために他の処理コンポーネントを起動することをトリガし得る出力を生成するようモデルに対して推論パスを行なうためにセンサ信号を使用することである。換言すると、アンビエントＭＬエンジン１３４は、センサ信号を受け取り得るか、または、低パワーＣＰＵ１３２または別の処理コンポーネントによって生成されるその処理されたバージョンを受け取り得、アンビエントＭＬエンジン１３４は、どの他の処理コンポーネントがセンサ信号をさらに処理すべきかを表す出力を生成し得る。アンビエントＭＬエンジン１３４によって生成される出力は、センサ信号を処理すべき他のより高パワーの処理コンポーネントを識別するために、処理コンポーネントＩＤの組み合わせまたは列挙された電力状態の識別子を明示的に特定し得るか、または、たとえば低パワーＣＰＵまたは低パワーＤＳＰといった低パワー処理コンポーネントによって解釈される電力状態の表現であり得る。このプロセスの部分として、低パワー処理コンポーネントは、任意の他の処理が必要であるか否かを明示的にまたは暗黙的に判断し得る。たとえば、低パワー処理コンポーネントは、マシンラーニングエンジンの出力に基づいて、さらなる処理が必要とされないことと、システムがモニタリング電力状態に戻るよう遷移し得ることとを判断し得る。
【００３７】
最も低いレベルのモニタリング電力状態では、ＰＣＵ１２１は、アンビエントＭＬエンジン１３４を低電力状態に保ち得るか、または、完全に電源を切り得る。処理電力状態では、ＰＣＵ１２１は、周辺インターフェイス１１４においてどのセンサ信号が利用可能であるかと、低パワーＣＰＵ１３２または低パワーＤＳＰ１３６が信号をどのように解釈するかとに依存して、アンビエントＭＬエンジン１３４に電力を供給してもよく、しなくてもよい。いくつかの実現例では、低パワーＤＳＰ１３６または低パワーＣＰＵ１３２は、付加的な中間電力状態のために電力を供給するようにＰＣＵ１２１に命令するために信号を解釈する。付加的な中間電力状態では、アンビエントＭＬエンジン１３４も推論パスのために電源オンされるが、他の高パワー処理コンポーネントはまだ電源オンされない。
【００３８】
アンビエントＭＬエンジン１３４はさらに、センサ信号を処理するための他のマシンラーニングモデルを実現し得る。たとえば、アンビエントＭＬエンジン１３４は、アンビエントＭＬエンジン１３４がいくつかのボイスベースのコマンドを認識することを可能にする簡略化されたスピーチ認識モデルを実現し得る。当該モデルは、限られたメモリ容量を有するモバイルコンピューティングデバイスにインストールされ得るので、認識されるコマンドの数は、オンライン音声認識プロセスの場合よりも少なくなり得る。
【００３９】
アンビエントＭＬエンジン１３４は、代替的または付加的に、オンチップ自動スピーチ認識を提供するマシンラーニングモデルを実現し得る。換言すると、アンビエントＭＬエンジン１３４は、オーディオ信号においてキャプチャされるスピーチのライブトランスクリプション（live transcription）を生成するために、モデルを通じて推論パスを行ない得る。
【００４０】
別の例として、アンビエントＭＬエンジン１３４は、特定のテキスト入力からオーディオ出力信号を生成するテキストツースピーチモデルを実現し得る。当該テキストツースピーチモデルでは、オーディオ出力信号は、ユーザによる特定の言語の人間のスピーチとして解釈され得る。いくつかの実現例では、デバイス１００は、スピーチ認識モデルおよびテキストツースピーチモデルを併用して、低パワーダイアログエンジンを提供し得る。たとえば、アンビエントＭＬエンジン１３４が特定のコマンドを認識した後、低パワーＣＰＵ１３２は、コマンドを遂行するとともにさらにアンビエントＭＬエンジン１３４に特定のテキスト応答を返すために、特定のアクションを取り得る。次いで、アンビエントＭＬエンジン１３４は、テキストツースピーチを使用して、初期コマンドに対する応答を表すオーディオ出力を生成し得る。いくつかの実現例では、スピーチ認識、アクション実行、およびテキストツースピーチ応答の全体のデータフローは、デバイスのメインＣＰＵクラスタ１４０を起動させることなく行なわれ得る。
【００４１】
たとえば、ユーザが「もっと大きな音で」というボイスコマンドを提供する場合、アンビエントＭＬエンジン１３４は、デバイスによって再生される音楽のボリュームを増加させるために、ボイスコマンドに対応するオーディオ信号を表す出力を生成し得る。マシンラーニングエンジン１３４は、低パワーＣＰＵ１３２に出力を提供し得、低パワーＣＰＵ１３２は、１つ以上の統合されたスピーカサブシステムに信号を発行することによってコマンドを遂行し得る。次いで、低パワーＣＰＵ１３２は、「レベル５のボリューム」というテキスト応答をアンビエントＭＬエンジン１３４に提供し得る。次いで、アンビエントＭＬエンジン１３４は、テキスト応答をテキストツースピーチモデルにより処理して、１つ以上の統合されたスピーカサブシステム上でデバイスが再生し得るオーディオ出力を生成し得る。したがって、アンビエントコンピューティングシステム１１０は、デバイスのメインＣＰＵを起動することなく全ダイアログシーケンスを処理する。
【００４２】
アンビエントＭＬエンジン１３４はさらに、さまざまな他のモデルのいずれかを実現し得る。アンビエントＭＬエンジン１３４はさらに、コンピューティングデバイスのユーザによって行われるハンドジェスチャの特徴を解釈するジェスチャ認識モデルを実現し得る。たとえば、当該モデルへの入力は、コンピューティングデバイスによって受け取られた処理されたレーダ信号であり得、当該モデルの出力は、ユーザが行ったジェスチャの予測であり得る。各ハンドジェスチャは、特定のコマンドに対応し得、アンビエントＭＬエンジン１３４は、さらなるアクションのために、低パワーＣＰＵ１３２または別の処理コンポーネントに出力を提供し得る。
【００４３】
アンビエントＭＬエンジン１３４は、モデルパラメータおよび他のモデル構成情報を格納するための１つ以上のメモリバンクを含み得る。たとえば、マシンラーニングエンジン１３４は、ニューラルネットワーク接続およびニューラルネットワークパラメータを表すデータを格納し得る。アンビエントＭＬエンジン１３４は、ニューラルネットワークアクティベーションまたは他のニューラルネットワークレイヤー出力を計算するための１つ以上の積和（ＭＡＣ： multiply accumulate）ユニットおよび１つ以上の和レジスタと、メモリバンクとＭＡＣユニットとの間のデータ交換を制御するためのコントローラとを含み得る。アンビエントＭＬエンジン１３４はさらに、命令メモリ、ダイレクトメモリアクセスパス、レジスタ、および他の処理コンポーネントを含み得る。いくつかの実現例では、アンビエントＭＬエンジン１３４は、マシンラーニング推論パスの計算を促進するように構成されるマシンラーニングコンピュートタイルである。
【００４４】
低パワーＤＳＰ１３６および高パワーＤＳＰ１３８は、高度にベクトル化された信号（highly-vectorized signals）の効率的なデコーディングおよび処理のために構成される特殊目的のプロセッサである。処理サブシステム１３０は、異なる目的のために設計されたさまざまなＤＳＰを含み得る。たとえば、処理サブシステム１３０は、いくつかの例を挙げると、レーダ信号を処理するように構成されるＤＳＰと、オーディオ信号を処理するように構成されるＤＳＰと、データプレーンアルゴリズムを行うように構成されるＤＳＰと、無線通信信号を処理するように構成されるＤＳＰと、ＧＰＳ信号を処理するように構成されるＤＳＰとを含み得る。
【００４５】
上述したように、低パワーＤＳＰ１３６は、制御サブシステム１２０からのセンサ信号の初期解釈を実行し得る。低パワーＤＳＰ１３６はさらに、他の信号処理タスクも実行し得る。一般に、高パワーＤＳＰは、低パワーＤＳＰよりも高いレベルの電力を消費する。その理由は、高パワーＤＳＰは、よりアクティブなレジスタを有すること、多くのデータに並列にアクセスするとともに当該データを並列に処理すること、メモリ動作により多く依存すること、または、これらの何らかの組み合わせである。
【００４６】
制御サブシステム１２０はさらに、システム異常を検出し、それらの異常を解決し得る電子タイマであるタイマ１２９を含み得る。通常動作中、システムはタイマ１２９を定期的にリセットして、タイマ１２９がタイムアウトするのを防止し得る。たとえば、ハードウェアの故障またはプログラムエラーによりシステムがタイマをリセットするのを失敗すると、タイマは、時間経過してタイムアウト信号を生成する。タイムアウト信号は、１つ以上の修正アクションを開始するために使用され得る。修正アクションは、システムを安全な状態に置くことと、通常のシステム動作を回復することとを含み得る。
【００４７】
図２は、例示的なアンビエントコンピューティングシステムの電力状態の状態図である。図２は、各その後の電力状態でオンにされ得る付加的なコンポーネントを示す。
【００４８】
図２において、モニタリング電力状態２１０は、システムの最も低い電力状態である。モニタリング電力状態の間、最も小さい数のコンポーネントがシステムによって電源オンされる。たとえば、いくつかの実現例では、モニタリング電力状態において、制御サブシステム１２０および周辺インターフェイス１１４の１つ以上のコンポーネントのみが電力を受け取る。他のコンポーネントは、モニタリング電力状態２１０の間は電源が切られ得る。次いで、ＰＣＵ１２１は、ＰＣＵ１２１が１つ以上の周辺インターフェイス１１４において新しいセンサデータの存在を検出すると、制御サブシステム１２０の他のコンポーネントに電力を供給し得る。
【００４９】
モニタリング電力状態では、システムは、たとえば、環境からの入力に対応するセンサ信号による割り込み、または、タイマがタイムアウトすることによる割り込みを待つ。システムは、割り込みを受け取ると、モニタリング電力状態２１０から処理電力状態２２０へ遷移し得る。処理電力状態２２０では、ＰＭＵ１２２は、ＳＲＡＭ１３９と、低パワーＣＰＵ１３２、アンビエントＭＬエンジン１３４または低パワーＤＳＰ１３６の任意の組み合わせとに電力を供給し得る。
【００５０】
割り込みを受け取ると、割り込みコントローラ１２４は、低パワー処理コンポーネントのうちの１つに電力を供給するようにＰＭＵ１２２に命令し得、これによりシステムが処理電力状態２２０に遷移する。上述したように、低パワー処理コンポーネントは、割り込みが検出されると、処理サブシステムにおいて起動されるべき最初のコンポーネントであるように設計されている。低パワー処理要素は、たとえば、たとえば処理サブシステム１３０の低パワーＣＰＵ１３２といった低パワーＣＰＵ、たとえば低パワーＤＳＰ１３６といった別の低パワープロセッサ、または、これらの何らかの組み合わせであり得る。いくつかの実現例では、システムは、どの割り込みが受け取られるかに依存して、低パワーＣＰＵ１３２または低パワーＤＳＰ１３６のいずれかを使用する。たとえば、システムは、割り込みがＧＰＳセンサからであれば低パワーＣＰＵ１３２を使用し得、割り込みがオーディオセンサからであれば低パワーＤＳＰ１３６を使用し得、割り込みがタイマによるものであれば低パワーＤＳＰ１３６を使用し得る。
【００５１】
次いで、たとえば低パワーＣＰＵ１３２または低パワーＤＳＰ１３６といった低パワー処理コンポーネントは、センサ信号の特性に依存して、アンビエントＭＬエンジン１３４を起動すべきか否かを判断し得る。たとえば、低パワーＤＳＰ１３６は、オーディオ信号を人間のスピーチではなくノイズに対応するものとして分類する場合、アンビエントＭＬエンジン１３４を全く呼び出さないと判断し得る。
【００５２】
低パワー処理コンポーネントはさらに、アクティベーションプロセスの一部分としてアンビエントＭＬエンジンをプログラムし得る。たとえば、低パワー処理コンポーネントは、アンビエントＭＬエンジンに、複数のマシンラーニングモデルのうちのどのモデルを使用するべきかを示し得、当該適用可能なモデルについての命令およびパラメータデータをＳＲＡＭ内にスワップするようＤＭＡ経路を使用し得る。
【００５３】
アンビエントＭＬエンジン１３４は、１つ以上のセンサ信号を処理して、センサ信号をさらに処理すべき１つ以上の他の処理コンポーネントを表す出力を生成し得る。たとえば、アンビエントＭＬエンジン１３４は、高パワーＤＳＰ１３８またはメインＣＰＵクラスタ１４０がセンサ信号をさらに処理すべきであることを表す出力を生成し得る。低パワー処理コンポーネントは、システムをより高いレベルの電力状態２３０のうちの１つに遷移するようアンビエントＭＬエンジンの出力を解釈し得るとともに、たとえば高パワーＤＳＰ１３８といった当該より高いレベルの電力状態を実現するために必要とされるコンポーネントに電力を供給するようにＰＣＵ１２１に命令し得る。
【００５４】
システムはさらに、メインＣＰＵクラスタ１４０、メインＭＬエンジン１５０、またはその両方が電源オンされるフル電力状態２４０に遷移し得る。フル電力状態２４０は、たとえば、メインＣＰＵクラスタ１４０を使用するウェブブラウジングセッションの間、または、メインＭＬエンジン１５０上で１つ以上のスピーチ認識およびオーディオ生成ニューラルネットワークを使用するボイスダイアログセッションの間といった、ユーザがコンピューティングデバイスをアクティブに使用する間の期間である可能性がある。
【００５５】
必要とされる場合にのみコンポーネントを電源オンするこのカスケードは、システムが常時入力に対して迅速に応答することを可能にしつつ、システムの電力消費を低減する。
【００５６】
ひとたび特定の処理コンポーネントがセンサ信号を処理し終えると、ＰＣＵ１２１は、その処理コンポーネントへの電力の供給を停止し得、これにより電力消費がさらに低減される。
【００５７】
いくつかの場合では、低パワーＣＰＵ１３２、アンビエントＭＬエンジン１３４、および低パワーＤＳＰ１３６でも、あるセンサ信号を完全に処理することができない場合がある。そのような場合、システムは、システムが高パワーＤＳＰ１３８またはメインＣＰＵクラスタ１４０に電力を供給するより高いレベルの電力状態２３０に遷移し得る。
【００５８】
ひとたびすべての処理が完了すると、システムはモニタリング電力状態２１０に戻るよう遷移し得る。モニタリング電力状態２１０において、システムは新しいセンサデータからの割り込みを待つ。
【００５９】
図３は、アンビエントコンピューティングシステムにおいて、付加的な処理コンポーネントが必要とされる場合に、当該付加的な処理コンポーネントを連続的にアクティベートするための例示的なプロセスのフローチャートである。便宜上、プロセスは、アンビエントコンピューティングシステムによって、または、システムの１つ以上のコンポーネントによって行われるものとして説明される。システムは、センサ信号を生成するように構成される１つ以上の周辺インターフェイスと、割り込みコントローラと、低パワーＣＰＵ、アンビエントＭＬエンジン、１つ以上のＤＳＰまたはこれらの何らかの組み合わせを含む１つ以上の処理コンポーネントとを含む、図１を参照して説明されたコンポーネントを含み得る。
【００６０】
システムは、最初はモニタリング電力状態にあり、モニタリング電力状態は、システムが入力に応答し得る最も低い電力状態である。モニタリング電力状態では、システムは、制御サブシステムのコンポーネントを動作状態に維持し得、たとえば低パワーＣＰＵ、アンビエントＭＬエンジン、および他の処理コンポーネントといった処理サブシステムのコンポーネントを非動作状態に維持し得る。これらのコンポーネントを非動作状態に維持することは、これらのコンポーネントに電力を供給しないこと、または、しきい値を下回るレベルの電力を供給することを伴う。システムは、たとえば揮発性メモリデバイスの状態を維持するために、モニタリング電力状態においていくつかのコンポーネントに何らかの電力を供給し得る。代替的または付加的には、システムは、たとえばアンビエントＭＬエンジンといった他のコンポーネントに、モニタリング電力状態の間は電力を供給しないようにし得る。
【００６１】
システムは、１つ以上のセンサ信号が１つ以上の周辺インターフェイスにおいて利用可能であると判断するまで、モニタリング電力状態に留まる（３１０）。
【００６２】
システムは、割り込みを受け取ると、モニタリング電力状態から処理電力状態に遷移する（３２０）。上述のように、割り込みは、１つ以上のセンサ信号が１つ以上の周辺インターフェイスにより生成されることによって生成され得るか、または、タイマがタイムアウトすることによって生成され得るかのいずれかである。
【００６３】
割り込みコントローラはさらに、特定のセンサ信号を自動的に無視し得る。たとえば、アンビエントコンピューティングシステムが実現されるコンピューティングデバイスの位置サービスがオフにされた場合、割り込みコントローラは単にシステムに、処理電力状態に遷移することなく位置データ信号を無視させ得る。
【００６４】
処理電力状態に遷移することにより、システムは、たとえば低パワーＣＰＵまたは低パワーＤＳＰといった低パワー処理コンポーネントをアクティベートする。低パワー処理コンポーネントをアクティベートすることは、割り込みコントローラが、低パワー処理コンポーネントを起動する割り込み信号を発行することを伴い得る。割り込みを発行することにより、データが、後で低パワーＣＰＵが読み出して解釈し得る割り込みレジスタに格納され得る。割り込みレジスタは、センサ信号の源を記述するデータを格納し得る。割り込みコントローラはさらに、低パワーＣＰＵに電力を供給するようにＰＣＵに命令し得る。
【００６５】
低パワー処理コンポーネントは、１つ以上のセンサ信号をさらに処理するためにアンビエントＭＬエンジンを呼び出すか否かを特定する出力を生成するよう割り込みを処理する（３３０）。この判断は、たとえば、オーディオデータが人間のスピーチの特徴を有すること、または、レーダデータがハンドジェスチャの特徴を有することといったように、１つ以上のセンサ信号が特定の特性を有すると判断することを伴い得る。
【００６６】
低パワー処理要素がアンビエントＭＬエンジンを呼び出さないと判断する場合（３４０）、低パワー処理コンポーネントはそれでも、他の処理コンポーネントが１つ以上のセンサ信号を処理すべきか否かを判断し得る（３５０に分岐）。換言すると、アンビエントＭＬエンジンを通る判断経路は、多くの状況のために使用され得るが、アンビエントコンピューティングシステムはさらに、アンビエントＭＬエンジンを全く呼び出さないセンサ信号を処理するためのユースケースをサポートし得る。
【００６７】
他の処理コンポーネントが１つ以上のセンサ信号を処理すべきである場合（３５０）、アンビエントコンピューティングシステムは、１つ以上の他の処理コンポーネントにより１つ以上の信号を処理し得る（３８０に分岐）。たとえば、低パワーＤＳＰは、受け取られた気圧計信号または加速度計信号が、アンビエントＭＬエンジンの代わりに低パワーＣＰＵによってさらに処理されるべきであると判断し得る。その場合、低パワーＤＳＰは、アンビエントＭＬエンジンを起動することなく、センサ信号をさらに処理するために低パワーＣＰＵを呼び出し得る。処理後、システムは、モニタリング電力状態に戻るよう遷移し得る（３９０）。
【００６８】
低パワー処理コンポーネントはさらに、たとえばオーディオ信号またはレーダ信号が実際には単にノイズである場合、センサ信号がさらなる処理を必要としないと判断し得る。その場合、システムは、他の処理コンポーネントを呼び出すことなく、単にモニタリング電力状態に戻るよう遷移し得る（３９０に分岐）。アンビエントＭＬエンジンまたは他の処理コンポーネントをアクティベートすることなく、プロセスを早期に終了させることによって、システムは有意な電力の節約を達成し得る。
【００６９】
低パワー処理要素がアンビエントＭＬエンジンを呼び出すと判断すると（３４０）、アンビエントＭＬエンジンは、１つ以上のセンサ信号をさらに処理すべき１つ以上の他の処理コンポーネントを表す出力を生成するよう１つ以上のセンサ信号を処理する（３６０に分岐）。アンビエントＭＬエンジンは、さまざまな適切なマシンラーニングモデルを使用し得る。一般に、モデルへの入力は、１つ以上のセンサ信号の１つ以上の特徴であり、出力は、低パワー処理要素が、アンビエントコンピューティングシステムの他の処理コンポーネントによってさらなる処理が必要とされるか否かを判断するために使用し得る推論である。
【００７０】
たとえば、アンビエントＭＬエンジンは、たとえばテキストツースピーチ応答が必要とされる場合に特殊目的のオーディオＤＳＰが１つ以上のセンサ信号をさらに処理すべきであることを意味するか、または、メインＣＰＵクラスタもしくはメインＭＬエンジンが１つ以上のセンサ信号をさらに処理すべきであることを意味すると低パワー処理要素が解釈する出力を生成し得る。
【００７１】
一例として、低パワーＤＳＰは、マイクロフォン信号を処理し得、人間が生成したノイズが実際のスピーチではないことを示す出力を生成し得る。その場合、低パワーＤＳＰは、センサ信号をさらに処理するためにアンビエントＭＬエンジンをアクティベートしない。他方、低パワーＤＳＰは、他のマイクロフォン信号を処理し得、人間が生成したノイズがスピーチであることを示す出力を生成し得る。その場合、低パワーＤＳＰは、センサ信号をさらに処理するためにアンビエントＭＬエンジンをアクティベートし得る。
【００７２】
システムは、アンビエントマシンラーニングエンジンの出力によって表される１つ以上の他の処理コンポーネントをアクティベートし、アクティベートされた１つ以上の他の処理コンポーネントを使用して１つ以上のセンサ信号を処理する（３７０）。付加的なアクティベートされた処理コンポーネントは、たとえば高パワーＤＳＰといった、１つ以上のより高いレベルの電力状態の処理コンポーネントを含み得る。付加的なアクティベートされた処理コンポーネントはさらに、たとえばメインＣＰＵクラスタ、メインＭＬエンジン、またはこれらの何らかの組み合わせといった１つ以上のフル電力状態の処理コンポーネントであり得る。
【００７３】
たとえば、センサ信号の組み合わせは、ユーザがデバイスを見始めたことを示し得る。アンビエントＭＬエンジンの出力は、それらのセンサ信号の特徴を、メインＣＰＵクラスタがコンピューティングデバイスのディスプレイをオンするために従事することを要求するプログラムにマッピングするために使用され得る。別の例として、センサ信号の組み合わせは、ユーザがボイスコマンドを発したことを示し得る。アンビエントＭＬエンジンの出力は、それらのセンサ信号の特徴を、メインＭＬエンジンにテキストツースピーチ応答を生成することを要求するプログラムであって、オンライン音声認識を行うためにメインＣＰＵクラスタをアクティベートすることも要求し得るプログラムにマッピングするために使用され得る。
【００７４】
アクティベートされた処理コンポーネントがセンサ信号を処理した後、低パワー処理コンポーネントは、それらの処理コンポーネントをシャットダウンするか、または、ＰＣＵにそうするように命令し得る。その後、低パワー処理コンポーネントはさらに、モニタリング電力状態に戻るよう遷移して次の割り込みを待つようにＰＣＵに命令し得る（３９０）。
【００７５】
図４は、アプリケーション固有の条件に対応するアプリケーションを扱うためにアンビエントコンピューティングシステムにおける特定の処理コンポーネントをアクティベートするための例示的なプロセスのフローチャートである。便宜上、プロセスは、コンピューティングシステムによって実行されるものとして説明されるか、または、コンピューティングシステムの特定のコンポーネントによって実行されるものとして説明される。また、コンピューティングシステムは、センサ信号を生成するように構成される１つ以上の周辺インターフェイスと、たとえば低パワーＣＰＵ１３２または低パワーＤＳＰ１３６といった低パワー処理コンポーネント、アンビエントＭＬエンジン１３４、および、１つ以上の高パワーＤＳＰ１３８を含む１つ以上の処理コンポーネントとを含む、図１を参照して説明されたコンポーネントを含み得る。例示的なプロセスの間、システムは最初は処理電力状態にあるが、より高い電力の処理状態に遷移し得る。
【００７６】
低パワー処理コンポーネントは、１つ以上の周辺インターフェイスによって生成されたセンサ信号を処理して、特定のセンサ信号が特定の特性を有すると判断する（４１０）。特定のセンサ信号が特定の特性を有すると判断することは、たとえば、オーディオデータが人間のスピーチに対応すること、または、レーダデータがハンドジェスチャに対応することといったように、センサ信号が特定のタイプであると判断することを伴い得る。
【００７７】
センサ信号が特定の特性を有すると判断することに応答して、システムは、図３を参照して説明されるように、アンビエントＭＬエンジンをアクティベートする（４２０）。
【００７８】
アンビエントＭＬエンジンは、モデル出力を生成するよう、センサ信号を使用してマシンラーニングモデルに対して推論パスを行なう（４３０）。アンビエントＭＬエンジンは、ニューラルネットワークモデルまたは任意の他の適切なマシンラーニングモデルとして表される、スピーチ認識モデル、ジェスチャ認識モデル、およびテキストツースピーチモデルを含む、多くのマシンラーニングモデルのいずれかを実現し得る。スピーチ認識モデルは、人間のスピーチを表すセンサ信号を入力として受け取り、それらの信号を処理して対応するテキストを生成する。ジェスチャ認識モデルは、ハンドジェスチャを表すレーダ入力を受け取り、それらのハンドジェスチャを識別およびデコードする。テキストツースピーチモデルは、入力としてテキストを受け取り、そのテキストを処理して対応するスピーチを生成する。
【００７９】
いくつかの実現例では、アンビエントＭＬエンジンは、複数のマシンラーニングモデルを格納する。センサ信号の特性によって、低パワーＤＳＰまたは低パワーＣＰＵが、アンビエントＭＬエンジンが推論パスを行なうべき１つ以上のモデルを選択する。いくつかの場合では、アンビエントＭＬエンジンは、同じセンサ信号を使用して異なるモデルに対して複数回推論パスを行ない得る。
【００８０】
上述したように、第１のタイプのマシンラーニングモデルは、アンビエントコンピューティングシステムのどの他のコンポーネントをさらなる処理のためにアクティベートすべきかを識別するために使用され得るモデルである。この場合、入力はセンサ信号であり、マシンラーニング出力は、１つ以上の処理コンポーネントの各々のための１つ以上の識別子にマッピングされ得る出力であり得る。
【００８１】
アンビエントＭＬエンジンによって実現され得るマシンラーニングモデルの別のタイプは、ユーザがたとえば「Ｏｋ電話」といったホットワード（hot word）の比較的小さなセットをいつ話したかを識別するために簡易スピーチ認識を行なうホットワードモデルである。この場合、入力はオーディオ信号であり、出力はコマンドの列挙されたセットの１つ以上の識別子である。たとえば、列挙されたコマンドの１つは、たとえばより高度なメインＭＬエンジンによって扱われ得る付加的なスピーチ入力をリッスンする（listen）ことであり得る。
【００８２】
アンビエントＭＬエンジンによって実現され得る別のタイプのマシンラーニングモデルは、メディア識別モデルである。この場合、入力は、オーディオ信号であり、モデル出力は、たとえば、曲、番組、ＴＶショーもしくは映画のタイトル、または、ＴＶチャンネルもしくはラジオチャンネルの名称といったオーディオ信号についてのメディアの１つ以上の特性である。たとえば、出力は、背景のオーディオを映画「Ｂｒａｖｅｈｅａｒｔ」として識別するテキストであり得る。次いで、アンビエントコンピューティングシステムは、メインＣＰＵクラスタをアクティベートして、この情報を電話画面上に通知で表示し得る。メディア識別モデルを実現するために、デバイスは、識別されるメディアが最新かつ妥当に現在のものであるように、更新されたモデルパラメータを、たとえば、夜、週、または月に１回ダウンロードし得る。
【００８３】
アンビエントＭＬエンジンによって実現され得る別のタイプのマシンラーニングモデルは、音楽識別モデルである。この場合、入力はオーディオ信号であり、モデル出力は、たとえば、曲のタイトル、作者、作曲家、アルバムまたはトラックといった音楽作品の１つ以上の特性である。デバイスは同様に、更新されたモデルパラメータをたとえば夜、週、または月に１回といったように周期的にダウンロードし得るので、識別される音楽は、最新かつ妥当に現在のものである。
【００８４】
上述のモデルのうちの１つ以上を実現するのに必要なメモリは、デバイス上のＳＲＡＭのサイズを超えてもよい。したがって、システムは、限られたメモリスペースを有する複数のマシンラーニングモデルをサポートすることが可能であるようにメモリオーバーレイを使用し得る。たとえば、システムは、ホットワードモデルのためのモデルパラメータおよびコードをＳＲＡＭ内に周期的にスワップし、最後の数ミリ秒にわたって受け取られるオーディオについて推論パスを行ない得る。次いで、システムは、メディア識別モデルのためのモデルパラメータおよびコードをＳＲＡＭ内にスワップし、最後の数ミリ秒にわたって受け取られるオーディオについて第２の推論パスを行ない得る。システムは、音楽識別モデルのためのモデルパラメータおよびコードをスワップするために同じことを実行し得る。いくつかの実現例では、システムは、ＤＭＡコントローラを使用してオーバーレイをＳＲＡＭにスワップし、ＤＲＡＭまたはＤＲＡＭにデータをキャッシュするシステムレベルキャッシュにＤＭＡ経路をスワップする。
【００８５】
システムは、センサ信号がアプリケーション固有の条件とマッチすると判断する（４４０）。たとえば、低パワー処理コンポーネントは、アンビエントＭＬエンジンの出力を解釈して、アンビエントコンピューティングシステムが実現されるコンピューティングデバイスのディスプレイをオンにするための条件にセンサ信号がマッチすると判断し得る。別の例として、低パワー処理コンポーネントは、アンビエントＭＬエンジンの出力を解釈して、受け取られたオーディオ信号が「ＯＫコンピュータ、画面をオンにして」というボイスコマンドに対応すると判断し得る。
【００８６】
特定のセンサ信号がアプリケーション固有の条件とマッチすると判断することに応答して、システムは、アプリケーション固有の条件に対応する特定のアプリケーションを実行するように特定の処理コンポーネントをアクティベートする（４６０）。先行する段落からの例を続けると、システムは、コンピューティングデバイスのディスプレイを点灯するプログラムコードを実行するために処理コンポーネントをアクティベートし得る。
【００８７】
別の例示的なプロセスでは、低パワー処理コンポーネントは、特定のセンサ信号がオーディオ信号であると判断し得る。次いで、システムは、それらのオーディオ信号をさらに処理するためにアンビエントＭＬエンジンをアクティベートし得る。オーディオ処理ニューラルネットワークを使用するアンビエントＭＬエンジンは、マシンラーニングモデルに対して推論パスを行ない、オーディオ信号がたとえば車のドアがバタンと閉まる音といった特定のタイプの音に対応することを表す出力を生成し得る。車のドアがバタンと閉まる音の発生は、システムにモバイルコンピューティングデバイスの位置を記録させるプログラムコードを実行するために、システムに処理コンポーネントをアクティベートさせるアプリケーション固有の条件である。モバイルコンピューティングデバイスの位置を記録することは、アプリケーション固有の条件に対応するアプリケーションである。そのようなアプリケーションは、しばしば自分の車を駐車した場所を忘れるユーザに有用であり得る。
【００８８】
図５は、ボイスサーチアプリケーションを扱うための例示的なプロセスのフローチャートである。プロセスは、アンビエントコンピューティングシステムによって実行されるものとして説明されるか、または、システムの特定のコンポーネントによって実行されるものとして説明される。
【００８９】
たとえばマイクロフォンといったアンビエントコンピューティングシステムのオーディオセンサは、環境からのオーディオ入力に基づいてオーディオ信号を生成する。たとえば、オーディオセンサは、「ＯＫコンピュータ、今日の天気は何？」という質問に対応する人間のスピーチを受け取り得る。オーディオセンサは、その質問をエンコードするオーディオ信号を生成し得る。
【００９０】
システムは、オーディオ信号を受け取る（５１０）。システムがモニタリング電力状態にある場合、システムは、オーディオ信号が利用可能であると割り込みコントローラが判断すると、処理電力状態に遷移し得、これにより、システムは低パワーＤＳＰをアクティベートし得る。前述したように、低パワーＤＳＰをアクティベートすることは、低パワーＤＳＰに割り込みを送ることと、低パワーＤＳＰに電力を供給するようＰＣＵに命令することとを伴い得る。システムが既に処理電力状態にある場合、低パワーＤＳＰは、オーディオ信号を処理し得る。
【００９１】
低パワーＤＳＰは、オーディオ信号を処理し、オーディオ信号が人間のスピーチの１つ以上の特性を有するか否かを判断する（５２０）。オーディオ信号が人間のスピーチの１つ以上の特性を有すると判断することは、たとえば、オーディオ信号の周波数成分を分析すること、または、オーディオ信号を人間のスピーチの既知のサンプルと比較することを伴い得る。
【００９２】
オーディオ信号が人間のスピーチの１つ以上の特性を有さない場合（５２０）、システムは、アンビエントＭＬエンジンを呼び出して他の処理を実行し得るか、もしくは、アンビエントＭＬエンジンを呼び出すことなく他の処理を実行し得るか、または、システムは単にモニタリング電力状態に戻るよう遷移し得る（５７０に分岐）。モニタリング電力状態に戻るように遷移することによって、アンビエントＭＬエンジンまたは他の高パワー処理コンポーネントがアクティベートされず、電力が節約される。
【００９３】
上述したように、アンビエントＭＬエンジンはさらに、音楽または他のメディアを具体的に識別する他のマシンラーニングモデルを使用し得る。したがって、オーディオ信号が音楽または他のメディアの特性を有する場合、システムは、それらのオーディオタイプに固有のモデルを使用して推論パスを行なうためにアンビエントＭＬエンジンのためのパラメータおよび命令をスワップし得る。アンビエントＭＬエンジンが、マイクロフォンによってピックアップされている音楽またはメディアを識別するためにモデルを使用できる場合、システムは、音楽または他のメディアを識別する情報を、たとえば表示通知として提供し得る。表示通知を提供することは、メインＣＰＵクラスタまたは他の高パワー処理コンポーネントを起動することを必要とする場合があるので、このプロセスは、処理電力状態からフル電力状態に遷移することを伴う場合がある。しかし、システムは、受け取ったオーディオ信号が低パワーＤＳＰに従った特定の特性を有し、かつ、アンビエントＭＬエンジンに従った識別可能な音楽またはメディアに対応する場合にのみ、フル電力状態に到達することによって、電力を節約し、バッテリ寿命を延ばし得る。
【００９４】
オーディオ信号が人間のスピーチの１つ以上の特性を有する場合、システムはアンビエントＭＬエンジンをアクティベートする（５３０に分岐）。
【００９５】
アンビエントＭＬエンジンは、スピーチ認識モデルに従ってオーディオ信号を処理する（５４０）。スピーチ認識モデルのためのプログラムコードおよびパラメータは、マシンラーニングエンジンをアクティベートする前またはアクティベート中にＳＲＡＭ内にスワップされ得る。
【００９６】
次いで、アンビエントＭＬエンジンは、入力オーディオ信号によりスピーチ認識モデルに対して推論パスを行なう。スピーチ認識モデルの出力は、オーディオ信号に対応するテキストか、または、スピーチに対応するコマンドの識別子であり得る。先行する段落からの例を続けると、スピーチ認識モデルの出力は、「ＯＫコンピュータ、今日の天気は何？」の識別子またはテキスト表現であり得る。
【００９７】
システムは、モデル出力がアプリケーション固有の条件に対応するか否かを判断する（５５０）。たとえば、低パワーＤＳＰは、テキスト表現における「天気」および「今日」といった単語の存在に基づいて、オーディオ信号が天気データを抽出および提示するアプリケーションに対応すると判断し得る。換言すると、ユーザは、コンピューティングデバイスが天気予報を提供することを望み、適切なボイスコマンドを発した。
【００９８】
モデル出力がアプリケーション固有の条件に対応しない場合、システムは、他の処理を実行し得るか、または、モニタリング電力状態に戻るよう遷移し得る（５７０に分岐）。
【００９９】
モデル出力がアプリケーション固有の条件に対応する場合、システムはアプリケーション固有の条件に対応するアプリケーションを実行する（５６０）。一般に、システムは、たとえば、アプリケーション固有の条件に対応するアプリケーションを実行するために必要なプログラムコードおよびデータをＳＲＡＭ内にスワップすることによって、当該アプリケーションを実行するべき処理コンポーネントを選択し得る。たとえば、アンビエントＭＬエンジンが自動スピーチ認識を実行し得る場合、システムは、アンビエントＭＬエンジンが音声を認識するのに必要なプログラムコードおよびモデルパラメータをＳＲＡＭ内にスワップし得る。
【０１００】
代替的または付加的には、システムは、たとえばメインＣＰＵクラスタまたはメインＭＬエンジンを呼び出すことによって、アプリケーションを実行するためにアンビエントコンピューティングシステムの一部分ではない他のコンポーネントを呼び出し得る。たとえば、アプリケーション固有の条件が天気を問い合わせるボイスコマンドである場合、システムは、オンラインソースから天気を調べるアプリケーションを実行するためにメインＣＰＵクラスタを呼び出し得る。当然ながら、このアクションも、既にアクティベートされていない場合、ネットワークハードウェアに電力を供給することを必要とし得る。たとえば、システムは、要求された天気情報を抽出するよう、オンラインサーチエンジンまたは天気データベースを使用し得る。
【０１０１】
システムは、人間のスピーチの特定の発生に対するテキストツースピーチ応答を生成するために、アプリケーション固有の条件に対応するアプリケーションである特定の処理コンポーネントをアクティベートする（５８０）。いくつかの実現例では、システムは、テキストツースピーチオーディオ応答を生成するために、オーディオＤＳＰをアクティベートし得る。いくつかの他の実現例では、アンビエントＭＬエンジン自体は、テキストツースピーチマシンラーニングモデルを実現することによってテキストツースピーチアプリケーションを扱い得る。テキストツースピーチマシンラーニングモデルは、学習された生オーディオリカレントニューラルネットワーク（trained raw audio recurrent neural network）であり得る。たとえば、当該ニューラルネットワークは、Aaron van den Oordらによる、arxiv.orgにおいて利用可能であるarXiv preprint arXiv:1609.03499 (2016)における、WaveNet:生オーディオのための生成モデル（A Generative Model for Raw Audio）に記載されるニューラルネットワークであり得る。テキストツースピーチモデルの出力はたとえば、「今日は、７５度の高い温度の晴れた天気を期待できます」といったオーディオ信号である。たとえばスピーカといったコンピューティングデバイス上のオーディオ出力デバイスは、オーディオ信号からオーディオを生成し得る。
【０１０２】
いくつかの実現例では、アンビエントコンピューティングシステムは、低パワーＣＰＵをアクティベートすることなく、人間のスピーチに対応するオーディオ信号を認識し得、テキストツースピーチオーディオ応答を生成し得る。たとえば、低パワーＤＳＰは、受け取られたオーディオ信号が人間のスピーチに対応すると判断し得るだけでなく、テキストツースピーチ応答を必要とすることになる質問に対応すると判断し得る。その判断に基づき、かつ、低パワーＣＰＵがテキストツースピーチアプリケーションを扱うことができない場合があるため、低パワーＤＳＰは、低パワーＣＰＵをバイパスしてアンビエントＭＬエンジンに直接的に推論要求を送り得る。このような状況において低パワーＣＰＵをバイパスすることにより、システムのエネルギー消費が低減される。
【０１０３】
図６は、ジェスチャ固有のアプリケーションを実行するための例示的なプロセスのフローチャートである。プロセスは、アンビエントコンピューティングシステムによって実行されるものとして説明されるか、または、システムの特定のコンポーネントによって実行されるものとして説明される。
【０１０４】
システムはレーダ信号を受け取る（６１０）。たとえば、１つ以上のレーダセンサがレーダ信号を生成する。システムが現在モニタリング電力状態にある場合、システムは、レーダ信号が利用可能であると割り込みコントローラが判断すると、処理電力状態に遷移し得、これにより、システムは低パワーＤＳＰをアクティベートする。前述したように、低パワーＤＳＰをアクティベートすることは、低パワーＤＳＰに電力を供給するようにＰＣＵに命令することを含み得る。システムが既に処理電力状態にある場合、システムはレーダ信号を低パワーＤＳＰに転送し得る。
【０１０５】
低パワーＤＳＰはレーダ信号を処理し、信号がユーザの近接を示すか否かを判断する（６２０）。レーダ信号がユーザの近接を示すと判断することは、環境から反射されて戻る電波においてエンコードされるたとえばパルスといった信号パターンを検出することと、反射された信号パターンの信号対雑音比を測定することとを伴い得る。信号対雑音比がしきい値を満たす場合、システムは、信号がユーザの近接を示すと判断し得る。
【０１０６】
いくつかの実現例では、システムは、低パワーＤＳＰに対してさらなる低レベルの処理を課す。たとえば、レーダ信号がユーザの近接を示す場合、システムは、レーダ信号がジェスチャを示すか否かを判断するために異なるルーチンを実行するよう低パワーＤＳＰを使用し得る。
【０１０７】
レーダ信号がユーザの近接を示さない場合、システムは、アンビエントＭＬエンジンを呼び出すことなく他の処理を実行し得るか、または、単にモニタリング電力状態に戻るよう遷移し得る（６７０に分岐）。
【０１０８】
レーダ信号がユーザの近接を示す場合、システムはアンビエントＭＬエンジンをアクティベートする（６３０に分岐）。
【０１０９】
システムは、ジェスチャ認識モデルに従ってレーダ信号を処理する（６４０）。ジェスチャ認識モデルのためのプログラムコードおよびパラメータは、マシンラーニングエンジンをアクティベートする前またはアクティベート中にＳＲＡＭ内にスワップされ得る。次いで、アンビエントＭＬエンジンは、モデル出力を生成するよう、入力されたレーダ信号を使用してジェスチャ認識モデルに対して推論パスを行ない得る。たとえば、マシンラーニングモデルは、特定のハンドジェスチャを検出および分類するように学習されたジェスチャ認識モデルであり得る。
【０１１０】
システムはレーダ信号が特定のジェスチャに対応するか否かを判断する（６５０）。たとえば、低パワーＤＳＰは、モデル出力を解釈し得、モデル出力が特定のジェスチャに対応すると判断し得る。代替的または付加的には、システムは、アンビエントＭＬエンジンと並行して高パワーＤＳＰを利用し得る。換言すると、高パワーＤＳＰは、アンビエントＭＬエンジンがジェスチャ認識モデルを通じて推論パスを行なうのと同時に、ユーザの近接を確認するためにレーダ信号に対してより高度な信号処理を実行し得る。高パワーＤＳＰが、ユーザが存在していることを示し、かつ、モデル出力が特定のジェスチャに対応することをアンビエントＭＬエンジンが示す場合、システムは、ジェスチャ固有のアクションを行ない得る。高パワーＤＳＰの機能をアンビエントＭＬエンジン上のジェスチャ認識モデルと組み合わせることによって、システムは、ジェスチャ認識の精度を向上させ得るとともに偽陽性検出の割合を低減し得る。
【０１１１】
レーダ信号が特定のジェスチャに対応しない場合、システムは、他の処理を実行し得るか、または、モニタリング電力状態に戻るよう遷移し得る（６７０に分岐）。
【０１１２】
レーダ信号が特定のジェスチャに対応する場合、システムは、ジェスチャ固有のアプリケーションを実行する（６６０に分岐）。１つのジェスチャ固有のアプリケーションは、ユーザがデバイスの所有者であるか否かをジェスチャから判断し得る。たとえば、デバイスは、デバイスのジェスチャアンロックまたはジェスチャパスワードを可能にするようレーダ信号を使用し得る。換言すると、システムは、ジェスチャの特徴が、デバイスをロックするために以前に使用されたジェスチャの特徴とマッチするので、ユーザがデバイスの所有者であると判断し得る。
【０１１３】
別のジェスチャ固有のアプリケーションは、ユーザが特定のジェスチャを実行することに応答して、デバイスのディスプレイを点灯することであり得る。たとえば、ユーザがディスプレイを見るために前方に傾いている場合、モデル出力は、ユーザが前方に傾いていることを示し得る。それに応答して、システムは、コンピューティングデバイスのディスプレイをオンにするために処理コンポーネントをアクティベートし得る。これにより、たとえば、ユーザは、単に前方に傾くことによってか、または、たとえば手を上もしくは前後あるいはＴ字状に振るといったように単に手を特定の態様で動かすことによって、デバイス上で通知を見ることが可能になり得る。
【０１１４】
別のジェスチャ固有のアプリケーションは、顔の表情を解釈するためにカメラを使用することであり得る。たとえば、特定のジェスチャが、ユーザがデバイスに向かって前方に傾いていることである場合、システムは、ユーザの顔の画像データをキャプチャするために前面カメラをアクティベートし得る。次いで、システムは、ユーザの顔の表情を分類するために、メインＣＰＵクラスタ、メインＭＬエンジン、またはその両方をアクティベートし得る。
【０１１５】
上記の例は主に、アンビエントコンピューティングシステムが、統合された処理コンポーネントを有するシステムオンチップとして実現されるものとして説明した。しかしながら、存在するコンピューティングコンポーネントの他の構成を使用するアンビエントコンピューティングシステムを実現するためにも同じ技術が使用され得る。たとえば、アンビエントＭＬエンジンを含むアンビエントコンピューティングシステムの１つ以上の処理コンポーネントは、コプロセッサとして実現され得るか、または、スタンドアロンチップにおいて実現され得る。
【０１１６】
本明細書において説明される主題ならびにアクションおよび動作の実施形態は、デジタル電子回路、有形に具現化されるコンピュータソフトウェアもしくはファームウェア、本明細書において開示される構造およびそれらの構造的均等物を含むコンピュータハードウェア、または、それらのうちの１つ以上の組み合わせにおいて実現され得る。本明細書において説明される主題の実施形態は、１つ以上のコンピュータプログラムとして実現され得る。すなわち、データ処理装置による実行のために、または、データ処理装置の動作を制御するために、有形の一時的でない記憶媒体上にエンコードされたコンピュータプログラム命令の１つ以上のモジュールとして実現され得る。代替的または付加的には、プログラム命令は、たとえば、データ処理装置による実行のために好適なレシーバ装置への送信のために情報をエンコードするために生成されるマシンによって生成される電気信号、光学信号、または、電磁信号といった人工的に生成された伝搬信号上でエンコードされ得る。コンピュータ記憶媒体は、マシン読み取り可能ストレージデバイス、マシン読み取り可能ストレージ基板、ランダムもしくはシリアルアクセスメモリデバイス、または、それらの１つ以上の組み合わせであり得るか、またはそれらの一部分であり得る。コンピュータ記憶媒体は伝搬信号ではない。
【０１１７】
プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリ、モジュール、ソフトウェアモジュール、エンジン、スクリプト、またはコードとも称され得るまたは記載され得るコンピュータプログラムは、コンパイルされた言語もしくは解釈された言語または宣言型言語もしくは手続き型言語を含む任意の形態のプログラミング言語で記述され得、スタンドアロンプログラムまたはモジュール、コンポーネント、エンジン、サブルーチン、もしくはコンピューティング環境において実行するのに好適な他のユニットを含む任意の形態でデプロイされ得る。当該環境は、１つ以上の位置におけるデータ通信ネットワークによって相互接続された１つ以上のコンピュータを含み得る。
【０１１８】
コンピュータプログラムは、ファイルシステム内のファイルに対応し得るが、対応する必要はない。コンピュータプログラムは、たとえばマークアップ言語ドキュメントに格納される１つ以上のスクリプトといった他のプログラムまたはデータを保持するファイルの部分に格納され得るか、対象のプログラム専用の単一のファイルに格納され得るか、または、たとえば１つ以上のモジュール、サブプログラム、もしくはコードの部分を格納するファイルといった複数の協調されたファイルに格納され得る。
【０１１９】
ユーザとのインタラクションを提供するために、本明細書で説明される主題の実施形態は、たとえばＬＣＤ（液晶ディスプレイ）モニタといったユーザに情報を表示するためのディスプレイデバイスと、たとえばキーボードおよびマウス、トラックボールまたはタッチパッドのようなポインティングデバイスといった、ユーザがコンピュータに入力を提供し得る入力デバイスとを有するコンピュータ上で実現され得るか、または、当該コンピュータと通信するように構成され得る。他の種類のデバイスも、ユーザとのインタラクションを提供するために使用され得る。たとえば、ユーザに提供されるフィードバックは、たとえば視覚フィードバック、聴覚フィードバック、または触覚フィードバックといった任意の形態の感覚フィードバックであり得る。さらに、ユーザからの入力は、音響入力、スピーチ入力、または触覚入力を含む任意の形態で受け取られ得る。さらに、コンピュータは、ユーザによって使用されるデバイスにドキュメントを送り、デバイスからドキュメントを受け取ることによって、ユーザとインタラクションし得る。たとえば、ウェブブラウザから受け取られる要求に応答してユーザのデバイス上のウェブブラウザにウェブページを送ることによって、または、たとえばスマートフォンもしくは電子タブレットといったユーザデバイス上で実行されるアプリとインタラクションすることによって、ユーザとインタラクションし得る。さらに、コンピュータは、テキストメッセージまたは他の形態のメッセージを、たとえばメッセージングアプリケーションを実行しているスマートフォンといったパーソナルデバイスに送り、応答メッセージをユーザから返報として受け取ることによって、ユーザとインタラクションし得る。
【０１２０】
本明細書に記載される主題の実施形態は、たとえばデータサーバとしてバックエンドコンポーネントを含むコンピューティングシステムにおいて実現され得るか、たとえばアプリケーションサーバといったミドルウェアコンポーネントを含むコンピューティングシステムにおいて実現され得るか、たとえばクライアントデバイスといった、ユーザが本明細書に記載される主題の実現例とインタラクションし得るグラフィカルユーザインターフェイス、ウェブブラウザもしくはアプリを有するフロントエンドコンポーネントを含むコンピューティングシステムにおいて実現され得るか、または、１つ以上のそのようなバックエンドコンポーネント、ミドルウェアコンポーネント、もしくはフロントエンドコンポーネントコンポーネントの任意の組み合わせを含むコンピューティングシステムにおいて実現され得る。システムのコンポーネントは、たとえば通信ネットワークといったデジタルデータ通信の任意の形態または媒体によって相互接続され得る。通信ネットワークの例は、ローカルエリアネットワーク（ＬＡＮ： local area network）と、たとえばインターネットといったワイドエリアネットワーク（ＷＡＮ： wide area network）とを含む。
【０１２１】
コンピューティングシステムはクライアントおよびサーバを含み得る。クライアントおよびサーバは一般に互いにリモートであり、典型的に通信ネットワークを介してインタラクションする。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行されるとともに互いにクライアント−サーバ関係を有するコンピュータプログラムによって生じる。いくつかの実施形態において、サーバは、たとえば、クライアントとして機能するデバイスとインタラクションするユーザにデータを表示し、当該ユーザからのユーザ入力を受け取るために、たとえばＨＴＭＬページといったデータをユーザデバイスに送信する。たとえばユーザインタラクションの結果といったユーザデバイスにおいて生成されたデータは、サーバにおいてデバイスから受け取られ得る。
【０１２２】
上記の実施形態に加えて、以下の実施形態も革新的である。
実施形態１は、アンビエントコンピューティングシステムであって、上記アンビエントコンピューティングシステムは、
センサ信号を生成するように構成される１つ以上のセンサと、
コントローラと、
低パワー処理コンポーネント、マシンラーニングエンジン、および１つ以上の他の処理コンポーネントを含む複数の処理コンポーネントとを含み、
上記アンビエントコンピューティングシステムは、動作を行なうように構成されており、上記動作は、
上記コントローラが１つ以上のセンサ信号の存在を示す割り込みを受け取るまでモニタリング電力状態に留まることと、
上記コントローラが上記割り込みを受け取ると、上記モニタリング電力状態から処理電力状態に遷移することとを含み、上記処理電力状態に遷移することによって、上記アンビエントコンピューティングシステムは上記低パワー処理コンポーネントをアクティベートし、上記動作はさらに、
上記マシンラーニングエンジンが上記１つ以上のセンサ信号を使用して推論パスを行なうべきであると、上記１つ以上のセンサ信号を使用して上記低パワー処理コンポーネントが判断することと、
それに応答して、上記１つ以上のセンサ信号をさらに処理するためにアクティベートされるべきである上記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表わす出力を生成するよう、上記１つ以上のセンサ信号を入力として使用して上記マシンラーニングエンジンが上記推論パスを行なうことと、
上記マシンラーニングエンジンの上記出力によって表される上記１つ以上の他の処理コンポーネントをアクティベートすることと、
上記マシンラーニングエンジンの上記出力によって表される上記１つ以上の他の処理コンポーネントが上記１つ以上のセンサ信号を処理することとを含む、アンビエントコンピューティングシステムである。
【０１２３】
実施形態２は、割り込みを受け取ることは、センサが環境入力を受け取ることに応答して周辺インターフェイスによって生成される割り込みを受け取ることを含む、実施形態１のアンビエントコンピューティングシステムである。
【０１２４】
実施形態３は、上記低パワー処理コンポーネントは、低パワーＣＰＵである、実施形態１〜２のいずれか１つのアンビエントコンピューティングシステムである。
【０１２５】
実施形態４は、上記低パワー処理コンポーネントは、低パワーＤＳＰである、実施形態１〜３のいずれか１つのアンビエントコンピューティングシステムである。
【０１２６】
実施形態５は、上記１つ以上のセンサ信号をさらに処理するためにアクティベートされるべきである上記アンビエントコンピューティングシステムの上記１つ以上の他の処理コンポーネントは、高パワーＤＳＰ、メインＣＰＵクラスタ、またはメインマシンラーニングエンジンを含む、実施形態４のアンビエントコンピューティングシステムである。
【０１２７】
実施形態６は、上記動作は、上記マシンラーニングエンジンの上記出力が、上記１つ以上のセンサ信号をさらに処理するためにアクティベートされるべき上記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表すということを、上記低パワー処理コンポーネントが判断することをさらに含む、実施形態１〜５のいずれか１つのアンビエントコンピューティングシステムである。
【０１２８】
実施形態７は、割り込みを受け取ることは、タイマがタイムアウトすることに応答して上記タイマによって生成される割り込みを受け取ることを含む、実施形態１〜６のいずれか１つのアンビエントコンピューティングシステムである。
【０１２９】
実施形態８は、上記複数の処理コンポーネントは、ランダムアクセスメモリバンクを共有し、上記モニタリング電力状態から上記処理電力状態に遷移することは、上記ランダムアクセスメモリバンクをアクティベートすることを含む、実施形態１〜７のいずれか１つのアンビエントコンピューティングシステムである。
【０１３０】
実施形態９は、上記複数の処理コンポーネントは、通信ファブリックによって通信可能に結合され、上記モニタリング電力状態から上記処理電力状態に遷移することは、上記通信ファブリックをアクティベートすることを含む、実施形態１〜８のいずれか１つのアンビエントコンピューティングシステムである。
【０１３１】
実施形態１０は、上記アンビエントコンピューティングシステムが上記モニタリング電力状態にある間、上記アンビエントコンピューティングシステムは、上記低パワー処理コンポーネントおよび上記マシンラーニングエンジンを非動作状態に維持する、実施形態１〜９のいずれか１つのアンビエントコンピューティングシステムである。
【０１３２】
実施形態１１は、上記低パワー処理コンポーネントおよび上記マシンラーニングエンジンを上記非動作状態に維持することは、電力を供給しないこと、または、しきい値を下回るレベルの電力を供給することを含む、実施形態１０のアンビエントコンピューティングシステムである。
【０１３３】
実施形態１２は、上記アンビエントコンピューティングシステムが上記モニタリング電力状態にある間、上記アンビエントコンピューティングシステムは、ＳＲＡＭおよび通信ファブリックを非動作状態に維持する、実施形態１０のアンビエントコンピューティングシステムである。
【０１３４】
実施形態１３は、上記アンビエントコンピューティングシステムが上記モニタリング電力状態にある間、上記アンビエントコンピューティングシステムは、制御サブシステムを動作状態に維持し、処理サブシステムを非動作状態に維持する、実施形態１０のアンビエントコンピューティングシステムである。
【０１３５】
実施形態１４は、上記マシンラーニングエンジンは、１つ以上のセンサ信号の特徴を入力として取得するマシンラーニングモデルであって、上記１つ以上のセンサ信号をさらに処理すべき上記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表す出力を生成するマシンラーニングモデルを実現する、実施形態１〜１３のいずれか１つのアンビエントコンピューティングシステムである。
【０１３６】
実施形態１５は、上記動作は、上記１つ以上の他の処理コンポーネントによる上記センサ信号の処理が完了すると、上記処理電力状態から上記モニタリング電力状態に遷移することをさらに含む、実施形態１〜１４のいずれか１つのアンビエントコンピューティングシステムである。
【０１３７】
実施形態１６は、上記マシンラーニングエンジンは、アンビエントマシンラーニングエンジンであり、上記１つ以上の他の処理コンポーネントはメインマシンラーニングエンジンを含み、上記アンビエントマシンラーニングエンジンは、上記メインマシンラーニングエンジンより小さい処理パワーを有する、実施形態１〜１５のいずれか１つのアンビエントコンピューティングシステムである。
【０１３８】
実施形態は、アンビエントコンピューティングシステムであって、上記アンビエントコンピューティングシステムは、
センサ信号を生成するように構成される１つ以上のセンサと、
低パワー処理コンポーネント、マシンラーニングエンジン、および１つ以上の他の処理コンポーネントを含む複数の処理コンポーネントとを含み、
上記アンビエントコンピューティングシステムは、
上記低パワー処理コンポーネントが、特定のセンサ信号が特定の特性を有すると判断することと、
それに応答して、上記マシンラーニングエンジンをアクティベートすることと、
上記マシンラーニングエンジンが、モデル出力を生成するよう、上記センサ信号を使用してマシンラーニングモデルに対して推論パスを行うことと、
上記マシンラーニングエンジンの上記モデル出力がアプリケーション固有の条件とマッチすると判断することと、
それに応答して、上記アプリケーション固有の条件に対応する特定のアプリケーションを実行するために、上記他の処理コンポーネントのうちの１つ以上をアクティベートすることとを行うように構成される、アンビエントコンピューティングシステムである。
【０１３９】
実施形態１８は、上記マシンラーニングエンジンの上記モデル出力がアプリケーション固有の条件にマッチすると判断することは、上記低パワー処理コンポーネントによって行われる、実施形態１７に記載のアンビエントコンピューティングシステムである。
【０１４０】
実施形態１９は、上記特定のセンサ信号が特定の特性を有すると判断することは、上記特定のセンサ信号が人間のスピーチに対応するオーディオ信号であると判断することを含む、実施形態１７〜１８のいずれか１つのアンビエントコンピューティングシステムである。
【０１４１】
実施形態２０は、上記アプリケーション固有の条件は、特定の人間のスピーチの発生であり、上記アプリケーションは、上記特定の人間のスピーチに対するテキストツースピーチオーディオ応答を生成することを含む、実施形態１９のアンビエントコンピューティングシステムである。
【０１４２】
実施形態２１は、上記マシンラーニングエンジンは、学習された生オーディオリカレントニューラルネットワークを使用して上記テキストツースピーチオーディオ応答を生成する、実施形態２０のアンビエントコンピューティングシステムである。
【０１４３】
実施形態２２は、上記アンビエントコンピューティングシステムは、人間のスピーチに対応する上記オーディオ信号を認識し、かつ、メインＣＰＵクラスタを初期化することなく上記テキストツースピーチオーディオ応答を生成するように構成される、実施形態２１のアンビエントコンピューティングシステムである。
【０１４４】
実施形態２３は、上記特定のセンサ信号が特定の特性を有すると判断することは、上記特定のセンサ信号がユーザの近接を示すレーダ信号であると判断することを含む、実施形態１７〜２２のいずれか１つのアンビエントコンピューティングシステムである。
【０１４５】
実施形態２４は、上記アンビエントコンピューティングシステムは、モバイルコンピューティングデバイスのコンポーネントであり、上記アプリケーション固有の条件は、ユーザによる特定のジェスチャの発生である、実施形態２３のアンビエントコンピューティングシステムである。
【０１４６】
実施形態２５は、上記アプリケーションは、上記モバイルコンピューティングデバイスのディスプレイをオンにすること、または、上記モバイルコンピューティングデバイスをアンロックすることを含む、実施形態２４のアンビエントコンピューティングシステムである。
【０１４７】
実施形態２６は、上記アンビエントコンピューティングシステムは、モバイルコンピューティングデバイスのコンポーネントであり、上記アプリケーション固有の条件は、特定のタイプの音の発生であり、上記アプリケーションは、上記モバイルコンピューティングデバイスの位置を記録することを含む、実施形態１７〜２５のいずれか１つのアンビエントコンピューティングシステムである。
【０１４８】
実施形態２７は、アンビエントコンピューティングシステムおよび付加的なコンポーネントを含む、パワードデバイス（powered device）であって、上記デバイスは、
センサ信号を生成するように構成される１つ以上のセンサと、
コントローラと、
低パワー処理コンポーネントと、アンビエントマシンラーニングエンジンと、他の処理コンポーネントとを含む複数の処理コンポーネントを含むアンビエントコンピューティングシステムとを含み、
上記アンビエントコンピューティングシステムは、
上記コントローラが割り込みを受け取るまで、モニタリング電力状態に留まることと、
上記コントローラが上記割り込みを受け取ると、上記モニタリング電力状態から処理電力状態に遷移することとを行うように構成され、上記処理電力状態に遷移することによって、上記アンビエントコンピューティングシステムは上記低パワー処理コンポーネントをアクティベートし、上記アンビエントコンピューティングシステムはさらに、
上記アンビエントマシンラーニングエンジンが１つ以上のセンサ信号をさらに処理するべきであることを特定する出力を生成するよう、上記低パワー処理コンポーネントが上記割り込みを処理することと、
上記１つ以上のセンサ信号をさらに処理するべきである上記アンビエントコンピューティングシステムの１つ以上の他の処理コンポーネントを表わす出力を生成するよう、上記マシンラーニングエンジンが上記１つ以上のセンサ信号を処理することと、
上記出力に応答して、上記センサ信号を処理するのに十分であると上記マシンラーニングエンジンの上記出力によって識別される上記１つ以上の他の処理コンポーネントのみをアクティベートすることと、
上記マシンラーニングエンジンの上記出力によって識別される上記１つ以上の他の処理コンポーネントを使用して上記１つ以上のセンサ信号を処理することとを行うように構成され、
上記コントローラは、処理された上記センサ信号に応答して、パワードデバイスの付加的なコンポーネントをアクティベートするように構成される、パワードデバイスである。
【０１４９】
実施形態２８は、上記マシンラーニングエンジンはアンビエントマシンラーニングエンジンであり、パワードデバイスの上記付加的なコンポーネントはメインマシンラーニングエンジンを含み、上記アンビエントマシンラーニングエンジンは、上記メインマシンラーニングエンジンよりも小さい処理パワーを有する、実施形態２７のパワードデバイスである。
【０１５０】
実施形態２９は、実施形態１〜２８のいずれか１つのアンビエントコンピューティングシステム動作を行なうことを含む方法である。
【０１５１】
実施形態３０は、コンピュータプログラムでエンコードされるコンピュータ記憶媒体であって、上記プログラムは、アンビエントコンピューティングシステムのコンポーネントによって実行されると、上記アンビエントコンピューティングシステムに実施形態１〜２８のいずれか１つの動作を行なわせるよう動作可能である命令を含む、コンピュータ記憶媒体である。
【０１５２】
本明細書は、多くの具体的な実現例の詳細を含むが、これらは、任意の発明の範囲または請求されているかまたは請求され得るものの範囲に対する限定として解釈されるべきではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明として解釈されるべきである。別個の実施形態の文脈において本明細書に記載されているある特徴はさらに、単一の実施形態において組み合わせて実現され得る。反対に、単一の実施形態の文脈で記載されるさまざまな特徴はさらに、複数の実施形態において別々に、または任意の適切なサブコンビネーションで実現され得る。さらに、特徴は、ある組み合わせにおいて作用し、最初はそのようなものとして請求されると上で記載され得るが、請求される組み合わせからの１つ以上の特徴は、いくつかの場合、その組み合わせから取り除かれ得、請求項は、サブコンビネーションまたはサブコンビネーションの変形例に向けられ得る。
【０１５３】
同様に、動作は、図面に示され、請求の範囲において特定の順序で記載されているが、これは、望ましい結果を達成するために、そのような動作が、示された特定の順序もしくは順次の順序で実行される必要がある、または、すべての例示された動作が実行される必要があると理解されるべきではない。ある状況では、マルチタスクおよび並列処理が有利であり得る。さらに、上述の実施形態におけるさまざまなシステムモジュールおよびコンポーネントの分離は、すべての実施形態においてそのような分離を必要とすると理解されるべきではなく、記載されるプログラムコンポーネントおよびシステムは、一般に、単一のソフトウェア製品に一緒に統合され得るか、または、複数のソフトウェア製品にパッケージ化され得ると理解されるべきである。
【０１５４】
主題の特定の実施形態を説明してきた。他の実施形態は、添付の請求の範囲内である。たとえば、請求の範囲に記載されるアクションは、異なる順序で行なわれ得、それでも望ましい結果を達成し得る。一例として、添付の図面に示されるプロセスは、望ましい結果を達成するために、必ずしも、示される特定の順序または順次の順序を必要としない。いくつかの場合では、マルチタスクおよび並列処理が有利であり得る。
【図１】
0006877594.tif 000002
【図２】
0006877594.tif 000003
【図３】
0006877594.tif 000004
【図４】
0006877594.tif 000005
【図５】
0006877594.tif 000006
【図６】
0006877594.tif 000007