JP2016523403A - 状況に基づくユーザインターフェイス（ｕｉ）の構成 - Google Patents

Abstract

モバイル装置が、この装置が車両内に配置されているかどうかを判断し、装置が車両内に存在すると判断したことに基づいて、単純化された、及び／又は提示されたはずの第２のＵＩに比べて運転中に容易に操作できる第１のユーザインターフェイス（ＵＩ）を自動的に提示する。【選択図】図２

Description

本出願は、一般に、ユーザが何をしているかという状況に基づいてＵＩを構成することに関する。

スマートフォン及びタブレットコンピュータなどのモバイル装置の普及率上昇と共に、これらを車の運転中又は乗客として乗車中などの特定の状況で使用することが望ましくなっている。しかしながら、本原理は、運転中に有用と考えられる特定の機能を実行するためにこのようなモバイル装置上に提示できる現在のユーザインターフェイスは、（例えば、その複雑性及び／又はその「雑然とした」外観により）運転中に呼び出して操作するのが困難であり、さらには集中力を妨げると認識している。

従って、本出願は、例えば有用なモバイル装置アプリケーション／アプリケーションアイコン、通知及び／又はその他のモバイル装置機能を容易に素早く視認できるフォーマットでユーザに提示するためのシステム、装置及び方法を提供する。本出願は、車を運転中でない時の少なくとも１つのユーザインターフェイスと、車を運転中の時の少なくとも１つのユーザインターフェイスとを交互に手動で切り替える必要性があるよりも、この提示を自動化する方が望ましいということも認識しているが、本原理は、状況によっては依然としてこのような手動切り替えが望ましいこともあると認識している。

従って、１つの実施形態では、装置が、クライアント装置のクライアントプロセッサがアクセス可能な、搬送波ではないコンピュータ可読記憶媒体を含み、このコンピュータ可読記憶媒体は、クライアントプロセッサによって実行された時に、方法を実行するためのロジックを実行するようにプロセッサを構成する命令を保持し、この方法は、クライアントプロセッサが車両内に存在するとの判断に基づいて、表示する複数のアプリケーションのうちの１つを選択可能にするユーザインターフェイス（ＵＩ）を第１の構成でディスプレイ上に自動的に提示するステップを含む。この命令は、クライアントプロセッサが車両内に存在しないとの判断に基づいて、プロセッサに、表示する複数のアプリケーションのうちの１つを選択可能にするＵＩを第１の構成とは異なる第２の構成でディスプレイ上に自動的に提示させる。いくつかの実施形態では、ディスプレイをクライアント装置のディスプレイとすることができ、クライアント装置は、クライアントプロセッサを含むことができる。

さらに、いくつかの実施形態では、複数のアプリケーションを、選択可能なタイルによってＵＩ上に表示し、第１の構成が、第２の構成よりも相対的に少ないタイルを提示し、及び／又は第２の構成で提示されるタイルに比べて少なくとも１つの大きな寸法のタイルを提示するようにすることができる。さらに、必要に応じて、第１及び第２の構成は、ＵＩ上に表示される特定のアプリケーションに基づいて互いに異なることもできる。

また、いくつかの実施形態では、クライアントプロセッサが車両内に存在するとの判断だけでなく、車両のギヤが入っているとの判断に基づいて、第１の構成のＵＩをディスプレイ上に自動的に提示することもできる。

別の態様では、方法が、クライアント装置が車両内に配置されているかどうかを判断するステップと、クライアント装置が車両内に配置されているとの判断に基づいて、クライアント装置が車両に配置されていないとの判断に基づいてクライアント装置のディスプレイ上に提示できる第２のＵＩよりも相対的に少ない情報を含む第１のユーザインターフェイス（ＵＩ）をディスプレイ上に自動的に提示するステップとを含む。

さらに別の態様では、装置が、クライアントプロセッサがアクセス可能な、搬送波ではない少なくとも１つのコンピュータ可読記憶媒体を含み、このコンピュータ可読記憶媒体は、クライアントプロセッサによって実行された時に、方法を実行するためのロジックを実行するようにプロセッサを構成する命令を保持し、この方法は、クライアントプロセッサに入力された信号によって表される、クライアントプロセッサに関連するクライアント装置の動作、及び／又はクライアント装置を用いた所定のアプリケーションの実行であるユーザ活動トリガが試験を満たすかどうかを判定するステップを含む。ユーザ活動トリガが試験を満たすとの判定に応答して、クライアント装置上に第１の出力が提示され、ユーザ活動トリガが試験を満たさないとの判定に応答して、クライアント装置上に第２の出力が提示される。第２の出力は、第１の出力とは異なると理解されたい。

同じ要素を同じ参照符号で示す以下の添付図面を参照することにより、本発明の詳細をその構成及び動作の両方に関して最も良く理解することができる。

本原理によるシステム例のブロック図である。 クライアント装置が車両内に配置されている時に、クライアント装置上に「運転時」ユーザインターフェイスを提示するかどうかを判断するロジックの例示的なフローチャートである。 運転時の操作に合わせて最適化されたＵＩと「通常時」ＵＩとの対比例である。 運転時の操作に合わせて最適化されたＵＩと「通常時」ＵＩとの対比例である。 運転時の操作に合わせて最適化されたＵＩと「通常時」ＵＩとの対比例である。 運転時の操作に合わせて最適化されたＵＩと「通常時」ＵＩとの対比例である。 運転時の操作に合わせて最適化されたＵＩと「通常時」ＵＩとの対比例である。 運転時に視認又は使用するアプリケーションの特定の機能又は特徴を予測するロジックの例示的なフローチャートである。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 特定のアプリケーションの様々な運転時ＵＩと「通常時」ＵＩとの対比例である。 運転時に呼び出される可能性の高いアプリケーションを予測して提示するロジックの例示的なフローチャートである。 呼び出される可能性が高いと予測されるアプリケーションを表すアイコンを示す例示的な運転時ＵＩである。 クライアント装置によって装置が車両内に存在と判断された時に提示され、装置のユーザに運転時ＵＩを提示するか、それとも「通常時」ＵＩを提示するかを尋ねる例示的なＵＩである。

コンピュータに基づくユーザ情報のための方法、装置及びシステムを開示する。本明細書におけるシステムは、互いにデータを交換できるようにネットワークを介して接続されたサーバ要素及びクライアント要素を含むことができる。クライアント要素は、１又はそれ以上のコンピュータ装置を含むことができる。これらの装置は、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、及びスマートフォンを含むその他のモバイル装置を含むことができる。これらの装置は、様々な動作環境で動作することができる。例えば、クライアントコンピュータによっては、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを実行できるものもある。他のクライアント装置には、ＵＮＩＸ（登録商標）オペレーティングシステムの１又はそれ以上の派生物、ＩＯＳ（登録商標）オペレーティングシステムなどのＡｐｐｌｅ（登録商標）コンピュータ社製のオペレーティングシステム、又はＧｏｏｇｌｅ（登録商標）社製のＡｎｄｒｏｉｄ（登録商標）オペレーティングシステムを実行できるものもある。クライアント装置の構成例を示しているが、これらはほんの一例であり、限定する意図はない。これらの動作環境は、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）、Ｆｉｒｅｆｏｘ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）、又は当業で周知の他の多くのブラウザプログラムの１つなどの１又はそれ以上のブラウジングプログラムを含むこともできる。クライアント装置上のブラウジングプログラムは、サーバ要素によってホストされる後述のウェブアプリケーションにアクセスするために使用することができる。

サーバ要素は、１又はそれ以上のコンピュータサーバを含むことができ、このサーバは、ネットワークを介してデータを送受信するようにサーバを構成する命令を実行する。例えば、いくつかの実装では、インターネットを介してクライアント要素とサーバ要素を接続することができる。他の実装では、学校又は学区内のイントラネットなどのローカルイントラネットを介してクライアント要素とサーバ要素を接続することができる。他の実装では、クライアント要素とサーバ要素の間に仮想プライベートネットワークを実装することができる。この場合、仮想プライベートネットワークは、インターネット又はイントラネットを介して実装することもできる。

上述したクライアント装置は、サーバによって生成されたデータを受け取ることができる。クライアント装置は、サーバによって受け取られるネットワークデータを生成することもできる。サーバ要素は、ロードバランサ、ファイアウォール、キャッシュ、プロキシ、及び信頼性のあるセキュアなウェブサイトインフラを実装するための当業で周知のその他のネットワークインフラを含むこともできる。１又はそれ以上のサーバ要素は、１又はそれ以上のメンバにセキュアなコミュニティを提供する方法を実装する装置を形成することができる。これらの方法は、サーバ要素に含まれるプロセッサ上で実行されるソフトウェア命令によって実装することができる。これらの方法は、以下で追加して示すユーザインターフェイス例の１つ又はそれ以上を利用することができる。

この技術は、他の数多くの汎用又は専用コンピュータシステム環境又は構成で動作することができる。本発明との使用に適すると考えられる周知のコンピュータシステム、環境及び／又は構成の例としては、以下に限定されるわけではないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド又はラップトップ装置、マルチプロセッサシステム、プロセッサベースシステム、プログラム可能な消費者向け電子装置、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステム又は装置のいずれかを含む分散コンピュータ環境、及び同様のものが挙げられる。

本明細書で使用する命令とは、システム内の情報を処理するためのコンピュータ実行ステップのことを意味する。命令は、ソフトウェア、ファームウェア又はハードウェア内に実装することができ、システムの要素によって実行されるあらゆるタイプのプログラムステップを含むことができる。

プロセッサは、ＡＭＤ（登録商標）Ａｔｈｌｏｎ（登録商標）ＩＩ又はＰｈｅｎｏｍ（登録商標）ＩＩプロセッサ、Ｉｎｔｅｌ（登録商標）ｉ３（登録商標）／ｉ５（登録商標）／ｉ７（登録商標）プロセッサ、Ｉｎｔｅｌ Ｘｅｏｎ（登録商標）プロセッサ、又はＡＲＭ（登録商標）プロセッサのいずれかの実装などの、あらゆる従来の汎用シングルチップ又はマルチチッププロセッサとすることができる。また、プロセッサは、ＯＭＡＰプロセッサ、Ｓｎａｐｄｒａｇｏｎ（登録商標）などのＱｕａｌｃｏｍｍ（登録商標）プロセッサ、或いはデジタルシグナルプロセッサ又はグラフィックスプロセッサを含むあらゆる従来の専用プロセッサとすることもできる。通常、プロセッサは、従来のアドレス線、従来のデータ線、及び１又はそれ以上の従来の制御線を有する。

システムは、詳述するような様々なモジュールで構成される。当業者であれば理解できるように、これらのモジュールの各々は、様々なサブルーチン、プロシージャ、定義ステートメント及びマクロを含む。便宜上、各モジュールの説明を用いて好ましいシステムの機能を説明する。従って、各モジュールによって行われる処理は、任意に他のモジュールの１つに再分配し、単一のモジュール内で組み合わせ、或いは、例えば共有可能なダイナミックリンクライブラリ内で利用可能にすることができる。

システムは、Ｃ＃、Ｃ、Ｃ＋＋、ＢＡＳＩＣ、Ｐａｓｃａｌ又はＪａｖａ（登録商標）などのあらゆる従来のプログラミング言語で記述し、従来のオペレーティングシステムの下で動作することができる。Ｃ＃、Ｃ、Ｃ＋＋、ＢＡＳＩＣ、Ｐａｓｃａｌ、Ｊａｖａ（登録商標）及びＦＯＲＴＲＡＮは、多くの商用コンパイラを用いて実行可能コードを作成できる業界標準プログラミング言語である。システムは、Ｐｅｒｔ Ｐｙｔｈｏｎ又はＲｕｂｙなどのインタープリタ型言語を用いて記述することもできる。これらはほんの一例であり、限定する意図はない。

当業者であれば、本明細書に開示する実施形態に関連して説明する様々な例示的な論理ブロック、モジュール、回路及びアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、又はこれらの組み合わせとして実装できるとさらに理解するであろう。ここまで、このハードウェアとソフトウェアの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路及びステップについて、これらの機能面から一般的に説明した。このような機能をハードウェアとして実装するか、それともソフトウェアとして実装するかは、特定のアプリケーション、及びシステム全体に課せられる設計制約に依存する。当業者であれば、説明する機能を各特定のアプリケーションに見合った様々な方法で実装できると思われるが、このような実装の決定を、本開示の範囲からの逸脱を生じるものとして解釈すべきではない。

本明細書に開示する実施形態に関連して説明する様々な例示的な論理ブロック、モジュール及び回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又はその他のプログラマブルロジックデバイス、離散ゲート又はトランジスタロジック、離散ハードウェアコンポーネント、或いは本明細書で説明する機能を実行するように設計されたこれらのいずれかの組み合わせを用いて実装又は実行することができる。汎用プロセッサは、マイクロプロセッサとすることができるが、別の方法では、このプロセッサをあらゆる従来のプロセッサ、コントローラ、マイクロコントローラ又は状態機械とすることもできる。プロセッサは、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサの組み合わせ、１又はそれ以上のマイクロプロセッサとＤＳＰコアの組み合わせ、又は他のいずれかのこのような構成などの、コンピュータ装置の組み合わせとして実装することもできる。

１又はそれ以上の実施形態例では、説明する機能及び方法を、ハードウェア、ソフトウェア、又はプロセッサ上で実行されるファームウェア、或いはこれらのいずれかの組み合わせの形で実装することができる。これらの機能は、ソフトウェアで実装する場合、１又はそれ以上の命令又はコードとしてコンピュータ可読媒体に記憶し、又はコンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、コンピュータ記憶媒体と、コンピュータプログラムを１つの場所から別の場所に容易に転送できるようにするいずれかの媒体を含む通信媒体とを含む。しかしながら、コンピュータ可読記憶媒体は搬送波ではなく、コンピュータがアクセスできるいずれかの利用可能な媒体とすることができる。限定ではなく一例として、このようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又はその他の光ディスク記憶装置、磁気ディスク記憶装置又はその他の磁気ストレージデバイス、或いは所望のプログラムコードを命令又はデータ構造の形で記憶するために使用できる、コンピュータがアクセスできる他のいずれかの媒体を含むことができる。また、正しくは、あらゆる接続がコンピュータ可読媒体と呼ばれる。例えば、ウェブサイト、サーバ又はその他のリモートソースから、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線及びマイクロ波などの無線技術を用いてソフトウェアを送信する場合、これらの同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線及びマイクロ波などの無線技術が媒体の定義に含まれる。本明細書で使用するディスク（ｄｉｓｋ及びｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク及びＢｌｕ−ｒａｙディスクを含み、通常、ディスク（ｄｉｓｋ）は、データを磁気的に再生するものであり、ディスク（ｄｉｓｃｓ）は、データをレーザーで光学的に再生するものである。これらの組み合わせも、コンピュータ可読媒体の範囲に含めるべきである。

上述の説明では、本明細書に開示するシステム、装置及び方法の特定の実施形態について詳述した。しかしながら、上述の説明が文字ではいかに詳述されているように見えても、これらのシステム、装置及び方法は多くの方法で実施できると理解されたい。また、やはり上述したように、本発明のいくつかの特徴又は態様を説明する際に特定の専門用語を使用している場合、これらの用語を、その用語が関連する技術の特徴又は態様のいずれかの特定の特性を含むことに限定されるように本明細書で再定義することを示唆していると捉えるべきではない。

当業者であれば、説明する技術の範囲から逸脱することなく、様々な修正及び変更を行うことができると理解するであろう。このような修正及び変更は、実施形態の範囲内に含まれることが意図されている。当業者であれば、１つの実施形態に含まれる要素を他の実施形態でも代用することができ、図に示す実施形態からの１又はそれ以上の要素を、図に示す他の実施形態と共にあらゆる組み合わせで含めることもできると理解するであろう。例えば、本明細書で説明及び／又は図示する様々な構成要素のいずれかを組み合わせ、置き換え、又は他の実施形態から省くことができる。

本明細書におけるほぼ全ての複数形及び／又は単数形の用語の使用に関しても、当業者であれば、文脈及び／又は用途に適するように複数形から単数形に、及び／又は単数形から複数形に置き換えることができる。本明細書では、明瞭化のために様々な単数形／複数形の置換を明確に示すことができる。

一般に、当業者であれば、本明細書で使用する用語は、一般に「非限定的（ｏｐｅｎ）な」用語として意図されている（例えば、「含む（ｉｎｃｌｕｄｉｎｇ）」という用語は、「含むけれどもそれに限定されない」と解釈すべきであり、「有する（ｈａｖｉｎｇ）」という用語は、「少なくとも有する」と解釈すべきであり、「含む（ｉｎｃｌｕｄｅｓ）」という用語も、「含むけれどもそれに限定されない」と解釈すべきであり、その他も同様である）と理解するであろう。また、当業者であれば、導入された請求項の記載において特定の数が意図されている場合、このような意図はその請求項中に明確に記載され、このような記載がない場合は、そのような意図も存在しないとさらに理解するであろう。例えば、理解を促すために、以下に添付する請求項では、「少なくとも１つの（ａｔ ｌｅａｓｔ ｏｎｅ）」及び「１又はそれ以上の（ｏｎｅ ｏｒ ｍｏｒｅ）」という導入句を用いて請求項の記載を導入している場合がある。しかしながら、このような語句を使用しているからといって、「ａ」又は「ａｎ」という不定冠詞による請求項の記載を導入した場合に、たとえ「１又はそれ以上の」又は「少なくとも１つの」という導入句と、「ａ」又は「ａｎ」という不定冠詞が同じ請求項内に含まれているとしても、このような導入された請求項の記載を含むいずれかの特定の請求項がこのような記載を１つしか含まない実施形態に限定されることを意味すると解釈すべきではなく（例えば、「ａ」及び／又は「ａｎ」は、通常、「少なくとも１つの」又は「１又はそれ以上の」を意味すると解釈すべきである）、定冠詞を用いて請求項の記載を導入する場合にも同じことが当てはまる。また、導入された請求項の記載に特定の数が明示されている場合でも、当業者であれば、このような記載は、通常、少なくとも記載されている数を意味すると解釈すべきであることを認識するであろう（例えば、他に修飾語を使用せずに「２つの記載」とだけ記載されている場合、通常は少なくとも２つの記載、或いは２又はそれ以上の記載を意味する）。さらに、「Ａ、Ｂ及びＣなどのうちの少なくとも１つ」に類する規定が使用されている場合、一般にこのような構造は、当業者がこの規定を理解すると思われる意味で意図されたものである（例えば、「Ａ、Ｂ及びＣのうちの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、及び／又はＡとＢとＣ全てなどを有するシステムを含むが、これらに限定されるわけではない）。「Ａ、Ｂ又はＣなどのうちの少なくとも１つ」に類する規定が使用されている場合、一般にこのような構造は、当業者がこの規定を理解すると思われる意味で意図されたものである（例えば、「Ａ、Ｂ又はＣのうちの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、及び／又はＡとＢとＣ全てなどを有するシステムを含むが、これらに限定されるわけではない）。当業者であれば、２又はそれ以上の選択的な用語を示す事実上全ての離接語及び／又は離接句は、説明内に存在するか、請求項内に存在するか、それとも図面内に存在するかに関わらず、これらの用語のうちの１つ、これらの用語のうちのいずれか、又は両方の用語を含む可能性を意図すると理解すべきであることをさらに理解するであろう。例えば、「Ａ又はＢ」という句は、「Ａ」又は「Ｂ」又は「ＡとＢ」の可能性を含むと理解されるであろう。本明細書では、様々な態様及び実施形態を開示しているが、当業者には他の態様及び実施形態も明らかであろう。本明細書に開示する様々な態様及び実施形態は例示を目的とするものであり、限定を意図するものではない。

まず図１を参照すると、システム１０が、インターネットなどのコンピュータクラウド１４を介して１又はそれ以上のサーバコンピュータと通信する少なくとも１つの、この例では「Ｎ」個のユーザ装置又はクライアント装置１２を含む。図示の例では、気象サーバ１６、交通サーバ１８及び一般的な１又はそれ以上のサーバ２０が、クラウドを介してクライアント装置１２と通信する。

クライアント装置１２は、非限定的かつ例示的な構成要素の中でも特にプロセッサ２２を組み込むことができ、このプロセッサ２２は、プロセッサによる実行時に以下で開示する原理を実行するようにプロセッサを構成する命令を含むコンピュータ可読記憶媒体２４にアクセスする。クライアント装置１２は、限定するわけではないが、プロセッサ２２によって制御されるＢｌｕｅｔｏｏｔｈトランシーバなどの近距離無線通信インターフェイス２６を用いて他のクライアント装置と通信することができる。また、クライアント装置１２は、以下に限定されるわけではないが、プロセッサ２２によって制御されるＷｉＦｉトランシーバ、無線モデム、ワイヤレステレフォニートランシーバなどの１つ又はそれ以上などの無線ネットワークインターフェイス２８を用いてクラウド１４と通信することもできる。有線インターフェイス２６、２８も想定される。

通常、クライアント装置は、要求された画像を提示するようにプロセッサ２２によって制御される液晶ディスプレイ（ＬＣＤ）、発行ダイオード（ＬＥＤ）ディスプレイ、又はその他のタイプのディスプレイなどの視覚ディスプレイ３０を含む。ディスプレイ３０は、タッチスクリーンディスプレイとすることができる。また、プロセッサ２２にユーザコマンドを入力するための１又はそれ以上の入力装置３２を提供することもできる。入力装置の例としては、キーパッド及びキーボード、ポイントアンドクリック装置、プロセッサ２２によって実行される音声認識エンジンに音声命令を入力するマイクなどが挙げられる。位置センサ３４は、クライアント装置１２の位置を表す信号をプロセッサ２２に入力することができる。図１では、位置受信機３４を全地球測位衛星（ＧＰＳ）受信機と仮定としているが、ＧＰＳ受信機に加えて、又はその代わりに他の位置センサを使用することもできる。例えば、加速度計、ジャイロスコープ及び磁気センサなどのモーションセンサ３５を用いてプロセッサ２２に位置情報を入力することもできる。位置情報は、ＷｉＦｉ情報から取得することもでき、例えば、クライアント装置の位置は、装置が通信を行っているＷｉＦｉホットスポットの位置であると推測することができる。また、カメラ３７によってプロセッサ２２に画像信号を供給することもできる。

図１には、クライアント装置１２を携行する人物が車両３６に入り込むことを決定できることも示している。車両３６は、コンピュータ可読記憶媒体４２にアクセスする車両プロセッサ４０によって制御される通信インターフェイス３８を含むことができる。インターフェイス３８は、クライアント装置１２のインターフェイスの１つと通信するように構成することができ、Ｂｌｕｅｔｏｏｔｈトランシーバとすることができる。車両３６は、車両３６の位置を表す信号をプロセッサ４０に送信する車載ＧＰＳ受信機４４又はその他の位置受信機を含むことができる。車両プロセッサ４０は、車両内の視覚ディスプレイ４６を、例えばディスプレイ上に電子地図又はその他のユーザインターフェイスを提示するように制御することができる。他のクライアント装置のユーザも、自身の装置を他の車両内に運び込んで、その車両のプロセッサとの通信を確立することができる。

ここで図２を参照すると、上述した装置１２などのクライアント（例えば、モバイル）装置が車両内に配置された時にクライアント装置上に提示すべきユーザインターフェイスを決定するための例示的なロジックを示しており、このロジックは、クライアント装置に関連するプロセッサによって実行できると理解される。このロジックは、装置が移動中であるかどうかを判定する判定区画６０から開始する。ロジックは、装置が移動中でないと判定した場合には終了する（例えば、何の行動も起こさない）ことができ、或いはブロック６２に進んで、ＵＩを「標準」構成、デフォルト構成及び／又は「通常時」構成で提示することができる。本明細書で使用する、ＵＩに関連する「標準」、デフォルト及び「通常時」という用語は単なる例示であり、これらの用語は限定を意図するものではない。従って、このような用語の意味は、例えば「通常時」ＵＩ又はデフォルトＵＩが、ある人物が運転中の時に車内に存在している間に提示される、運転中に車両の運転手によって解読、読み取り及び／又は操作しやすいように構成された本原理による特定のＵＩ以外の、クライアント装置上に提示できるＵＩにすぎないことを伝えるものである。

いずれにせよ、判定区画６０に戻ると、ロジック内のこの時点で肯定的な判定が行われた場合、図２の例示的なロジックは、判定区画６０から判定区画６４に進む。判定区画６４において、ロジックは、装置の動きが閾値（例えば、スピード閾値、速度閾値又は移動距離閾値）に達したかどうかを判定する。従って、ロジックは、判定区画６４において、例えば装置のユーザが装置を持って歩いているだけかどうか（この場合、「通常時」ＵＩを提示することができる）、それともユーザが移動中の車両内に存在するかどうかを閾値に基づいて区別できると理解することができる。否定的な判定が行われた場合、ロジックは上述したブロック６２に進んで「通常時」ＵＩを提示する。一方、判定区画６４において肯定的な判定が行われた場合、ロジックはブロック６６に進み、例えばブロック６２において提示される「通常時」ＵＩよりも運転中の操作及び視認に合わせて最適化されたＵＩ（本明細書では「運転時」ＵＩと呼ぶ）を提示する。

引き続き図２を参照すると、ロジックは、ブロック６６の後に判定区画６８に進み、装置がいまだに動いているかどうかに関する（及び必要であれば、例えば装置がいまだに閾値又は閾値を上回る速さで動いているかどうかにも関する）次の判定を（例えば、クライアント装置のＧＰＳの加速度計からのクライアント装置の動きの変化などの入力に基づいて数秒毎、１分毎に）行う。判定区画６８において肯定的な判定が行われた場合、ロジックは、運転時の操作に合わせて最適化されたＵＩを提示し続けることによってブロック６６に戻り、（例えば所定時間後に）上述した判定区画６８に再び進むことができる。否定的な判定が行われた場合、ロジックはブロック７０に進み、「通常時」ＵＩを提示する。

また、上述した例示的なロジックの一部を構成するわけではないが、本原理によれば、動き閾値以外の「トリガ」を用いて運転時ＵＩが提示されるようにすることもできると理解されたい。例えば、アプリケーションを表す特定のアイコンの起動がトリガを構成し、これによって運転時ＵＩが提示されるようにすることもできる。一例として、交通アプリケーションアイコンが起動された場合、プロセッサは、この起動によって運転時ＵＩを提示すべきであると判断することができる。

図３〜図６に、運転中の操作に合わせて最適化されたＵＩの例を、運転中でない時の提示、視認及び／又は操作のための「通常時」ＵＩと対比させて示す。まず図３を参照すると、運転時の操作に合わせて最適化された例示的なＵＩ７２を、スマートフォンなどの例示的なクライアント装置上に提示された形で示している。従って、ＵＩ７２は、それぞれのアイコンの選択時に呼び出すことができるアプリケーションを表すたった２つの選択可能アイコン／タイル７４及び７５しか含んでおらず、運転時ＵＩから「通常時」ＵＩに切り替えるための選択可能アイコン７３を任意に含むこともできる。対照的に、図４には、例えば箱から出したばかりのクライアント装置のデフォルト構成及び／又はストック構成とすることができる、或いは単純にクライアント装置が車内に配置されていない時に複数のアプリケーションのいずれか１つにアクセスするのに役立つ４×４の格子状のアイコン７８を有する例示的なＵＩ７６を示している。また、ＵＩ７６は、必要時に運転時ＵＩに切り替えるための選択可能アイコン７７を任意に含むこともできる。図３と図４を比較すると、ＵＩ７２などのＵＩは、アイコンを区別しやすいようにＵＩ７６よりも提示するアイコンを少なくすること、及び／又は（高さ及び幅、又はアイコンが３次元形式で提示可能な場合には３次元などの）寸法が大きな１又はそれ以上のアイコンを提示することなどの、少なくとも１つの特徴が運転時の操作に合わせて最適化されていると理解することができる。

図５及び図６には、本原理による例示的な運転時ＵＩをさらに２つ示している。図５の例示的なＵＩ８０は、クライアント装置が車内に配置されていると判定した後に提示することができ、本原理によるこのような判定時にのみ、或いは以下の図２３を参照して説明するようなユーザからの入力後にさらに提示することができる「ホーム」運転時ＵＩであると理解される。いずれにせよ、ＵＩ８０は、移動中の車両の動き（例えば、起伏）などによってアイコンの選択が困難になり得る時でさえも容易に選択できる大型のアイコンを含む。ホーム運転時ＵＩ上に提示されるアイコンは、毎回同じアイコンが提示されるように、或いは本明細書で説明するような１又はそれ以上のパラメータに応じてどのアプリケーションが有用となり得るかを予測することに基づいてＵＩ８０が動的に変化できるようにユーザが決定することができる。

いずれにせよ、図５の例示的なＵＩ８０は、６つのアイコンと、ユーザがスクロールできるさらに２つの部分を示していると理解することができる。図示の６つのアイコンは、選択時に聞く特定のコンテンツに関するアイコン８２と、ＵＩ８０上に表示されているもの以外のアプリケーションを提示するために選択可能な「さらなるアプリケーション」アイコン８４と、ナビゲーションアイコン８６と、カレンダ／ミーティングアイコン８８とを含む。各アイコン８２〜８８は、それぞれのアイコンが表すそれぞれのアプリケーションに関連し、ＵＩ８０からアイコンを選択することによってこれらのアプリケーション又はその特定の機能を呼び出すことができると理解されたい。

従って、図６には、図５のホーム運転時ＵＩからのアイコンの選択に応答して提示されると理解される例示的なフォーカスされた運転時ＵＩ９４を示している。従って、「フォーカスされた」ＵＩ９４は、ＵＩ８０から選択されてＵＩ９４内でフォーカスされたアイコンに関する特定の機能、通知又はその他の情報に関する。図６の例では、ＵＩ８０からカレンダ／ミーティングアイコン８８が選択されたことに応答して、カレンダ／ミーティングの通知が表示されている。ＵＩ９４からは、ＵＩ９４を提示している装置のユーザの直近のミーティングに関する情報を含む通知９６がＵＩ９４上に提示されていると理解することができる。従って、通知９６は、ミーティング名、ミーティングの予定開始時刻及び終了時刻、ミーティングの場所、及びミーティングの主催者を含む。また、ＵＩ９４からは、通知９６に反映されるミーティング後の直近のミーティングを示す、通知９６の隣の「午後３時」セレクタ要素９８などのさらに他のセレクタ要素／アイコンをＵＩ９４上に提示できるとさらに理解することができる。従って、セレクタ要素９８を選択すると、通知９６内に表示される情報と同様の、ただし「午後３時」のミーティングの情報を含む、通知９６と同様の通知を提示させることができる。

さらに、ＵＩ９４上には、連絡先セレクタ要素１００も表示されており、この要素１００は、要素１００が表す連絡先がミーティングに実際に関連していること（例えば、別のミーティング参加者）を容易に認識することができ、運転時に容易に選択できるような形で（例えば、通知９４と部分的に重なって）提示される。従って、要素１００は、例えば電話又はテキストメッセージアプリケーションを立ち上げるように選択可能であり、或いは要素１００が表す人物と連絡をとるように別様に使用することもできる。同様に、ＵＩ９４上には、ナビゲーションセレクタ要素１０２を、選択するとナビゲーションアシスタンス（例えば、通知９６に関連するミーティング会場の方向）を提示できることを容易に認識することができ、さらには運転時に容易に選択できるような形で（例えば、通知９４と部分的に重なって）提示することもできる。また、背景画像１０６を提示して、画像１０６が重なる又は取り囲むアイコン／セレクタ及び通知が全て同じ主題（この場合、画像１０６上に中心的に配置された通知９６が関連するミーティング）に何らかの点で関連することをユーザが運転中にさらに容易に認識できるようにすることもできる。完全を期して言えば、複数のそれぞれのアイコン１０４によって別の連絡先を表すこともできるが、これらの連絡先は、必ずしも通知９６が指示する直近のミーティングに関連するものとは限らない。

一瞬だけ図５に戻ると、いくつかの実施形態では、アイコン自体がその中又はその上のアイコンを含むこともできると理解されたい。このようなアイコンは、例えばクライアント装置の感覚的出力を直接制御するために有用となり得る。従って、例えば部分８３においてリスンアイコン８２を選択すると、部分８３に１回タッチした場合には、これに応答して、スピーカを通じて関連するオーディオコンテンツが提示されるのに対し、部分８３以外の部分においてリスンアイコン８２を選択すると、アイコン８２が表すオーディオコンテンツに関する追加情報を別の運転時ＵＩに提示するようにすることができる。さらに、完全を期して言えば、ホーム運転時ＵＩ上には、さらに別のアイコンを提示することもできる。ホーム運転時ＵＩ上に提示するアイコンによって提示できるタイプのアプリケーションとしては、以下に限定されるわけではないが、人々及びユーザの連絡先、イベント、オーディオ及び／又はビデオコンテンツ、位置、さらに他のアプリケーションウィンドウ及びＵＩ、並びに「ｔｏ ｄｏリスト」項目を挙げることができる。

図７に、運転時の操作及び視認に合わせて最適化されたさらに別の例示的なＵＩを示す。クライアント装置が動いている間（例えば、装置のユーザが、運転中の車両内に装置を配置した状態で運転している間）には、クライアント装置上にＵＩ１１０が提示される。図７のＵＩ１１０には、上述した選択可能なタイル／アイコンフォーマットではなく、任意に選択可能な項目／エントリ１１２のリストに似た提示が表示される。従って、リスト項目１１２の少なくとも１つは、タッチスクリーン上に提示されている選択可能な項目のいずれかの部分にタッチすることによってその項目が呼び出され、例えばアプリケーションを立ち上げ、又はそれに関連する機能を実行できるという点で選択可能とすることができる。また、リスト内の１又はそれ以上の項目１１２は、それ自体が図示のアイコン１１４などの選択可能なアイコンを含むことができ、さらにこのような場合、アイコン１１４は選択可能であるにも関わらず、アイコン１１４を提示する項目自体は、上述したように選択可能とすることも、或いは選択不可能とすることもできる。いずれにせよ、図７のリストなどの単一のリストには、選択可能な項目及びアイコンのいずれかの組み合わせ、さらには選択可能でない項目も提示できると理解することができる。

さらに、各項目は、例えばそれを見る者が運転中に情報を読み解くのに必要以上の時間を消費し、従って安全上の問題が生じないように、項目１１２、特定のアイコン、又はこれらにそれぞれ含まれる他の特徴／情報（例えば、選択可能なテキスト）が選択可能か否かに関わらず、運転中に情報を見やすい、或いは素早く容易にユーザの注意を引くボールド体、実線の下線、点線の下線、強調表示、黒以外の文字色、イタリック体、Ｔｉｍｅｓ Ｎｅｗ Ｒｏｍａｎ又はＣａｍｂｒｉａなどのあらゆる数のフォントタイプ、及び／又は（例えば、装置が移動中の車両内に存在しない時の「通常時」ＵＩと比較して）比較的大きなフォントで情報を提示することができると理解されたい。さらに、図７から理解できるように、各項目１１２はＵＩ１１０の幅全体に及んでいるが、これらの項目の一部又は全部は、必要に応じてＵＩ１１０よりも幅を狭くすることも、さらには項目の（高さなどの）他の寸法を変化させることもできる。さらに、項目１１２は、例えば、本明細書で説明した通知及びアプリケーションに関して上述したような情報を提供することもできる。

次に、図８を参照すると、クライアント装置上のアプリケーションを実行し、ユーザが運転中に確認又は使用したいと望むことができるアプリケーションの特定の機能又は特徴を予測するようにクライアント装置のプロセッサによって実行される例示的なロジックを示している。従って、図８は、ブロック１１６から開始して、（例えば、電子メールアプリケーション、ソーシャルネットワーキングアプリケーション、電話アプリケーションなどの）本明細書で説明したようなアプリケーションが呼び出される。ブロック１１６でアプリケーションが呼び出されると、ロジックは判定区画１１８に進み、本原理に従って、車両が移動中であるかどうかを判定する。ロジックは、判定区画１１８において車両が移動中でないと判定した場合、ブロック１２０に進んで「通常時」ＵＩ又は「デフォルト」ＵＩを提示する。従って、例えばＦａｃｅｂｏｏｋアプリケーションが呼び出された場合、通常、このアプリケーションはデフォルトでＦａｃｅｂｏｏｋ「ニュースフィード」を開くが、このことは、本原理に従って「通常時」ＵＩを提示する際に当てはまる。さらに別の例として、電子メールアプリケーションが呼び出された場合、クライアント装置が車両内に存在しない時、及び／又は車両内に存在するが、車両が公園内に存在し、又はギヤが入っていない（例えば、マニュアル変速の車両ではクラッチが切られている）時に提示される「通常時」のデフォルトＵＩは、最初に電子メールアカウントの受信箱を提示する。

いずれにせよ、ロジックは、判定区画１１８において、図８のロジックを実行しているクライアント装置が配置されている車両が移動中であると判定した場合にはブロック１２２に進んで、アプリケーションを実行するロジックがアプリケーションの特定の機能を予測し、その後、ブロック１２４において１又はそれ以上のパラメータに基づいてこの機能を提示する。一例として、１つのこのようなパラメータは、以前に運転中の車両内にクライアント装置が配置されていた時に過去に呼び出されたアプリケーションの特定の機能とすることができる。このような過去の呼び出しは、過去に選択された回数に基づいて、例えば第１の機能が第２の機能よりも頻繁に呼び出されている場合、及び／又は第２の機能よりも最近呼び出された場合、及び／又は第２の機能よりも多くの回数呼び出された場合には第１の機能が運転時ＵＩ上に最初に提示されるように、又は上の階層に提示されるように、及び／又は上述した方法の１つ又はそれ以上を用いて視覚的に区別される（例えば、より頻繁に及び／又は多くの回数選択された項目をボールド体の大きなフォントで提示し、第２の要素を大きなフォントのみで提示する）ように優先させることもできる。

その他のパラメータの例としては、装置の現在位置又は予測目的地、一日、一ヶ月、一年などの時間、最近の行動、同じ又は異なるアイコン及び関連するアプリケーションの最近の選択、走行条件、さらには走行条件を考慮した際にユーザが特定の機能を使用する適切性及びその能力（例えば、交通渋滞に巻き込まれている時は、電子メールの入力に最適な時間ではないかもしれないが、ユーザに送られて来た電子メールの本文に素早く目を通すための時間はあると考えられる）が挙げられる。

従って、ロジックが判定区画１１８からブロック１２２に進む場合、電子メールアプリケーションを用いて提示できる運転時ＵＩの例としては、「通常時」ＵＩとして提示されるはずの受信箱画面ではなく、電子メール編集画面とすることができる。別の例として、電話アプリケーションが呼び出された場合、提示できる運転時ＵＩは、例えば１回のタッチを用いて連絡先に「短縮ダイヤル」するために選択可能な、ユーザの連絡先のうちの特定の１つを表すアイコンを含み、この連絡先は、例えば車両の移動方向、及び／又は、装置及び／又は電話アプリケーションがアクセスできる電子カレンダの入力に基づいて、ユーザが会いに向かっている相手であるとアプリケーションが予測した連絡先である。

ここで、本原理による、特定のアプリケーションの様々な例示的な運転時ＵＩと「通常時」ＵＩとを対比させた図９〜図２０を参照する。従って、後述する運転時ＵＩは、運転中の車両内にクライアント装置が配置されている間に呼び出せるものであり、「通常時」ＵＩは、装置が車両に配置されていない間、及び／又は移動中でない時、或いは閾値又はそれ以上で移動中でない車両内に配置されている間に呼び出せるものであると理解されたい。最初の図９には、電話アプリケーションの運転時ＵＩ１２６を示している。この運転時ＵＩ１２６は、ユーザの連絡先リスト全体、又は（「通常時」ＵＩの例とすることができる）電話番号を入力するためのキーパッドを提示するのではなく、１回のタッチで呼び出せるように比較的大型の選択可能な連絡先を２つだけ提示する。対照的に、図１０のＵＩ１２８は、さらに多くの一連の連絡先を（例えば、アルファベット順で）リスト表示する電話アプリケーションの「通常時」ＵＩを表示している。

図１１には、電子メールアプリケーションの運転時ＵＩ１３０を示す。ＵＩ１３０上に提示されている電子メールが特にユーザの直近の予定に関連する電子メールエントリ１３４であることを示すインジケータ１３２が示されており、これらの予定は、それぞれの電子メールの本文全体を提示させるように選択可能である。対照的に、図１２には「通常時」電子メールＵＩ１３６を示す。このＵＩは、電子メールアプリケーションを呼び出した時点におけるユーザの受信箱内の全ての電子メールを逆の時系列順で表示している。

次に、図１３に、地図アプリケーションの運転時ＵＩ１３８を示す。従って、ＵＩ１３８を提示する地図アプリケーションは、例えばさらなるユーザ操作を伴わずにこのアプリケーションに関連するアイコンの呼び出しのみに基づいて、装置が移動中の車両内に存在すると判断し、従って装置のユーザに次のミーティングへの道順を装置上に提示したいと望むかどうかを尋ねるプロンプト１４０を自動的に提示する。従って、ＵＩ１３８は、ユーザが肯定的又は否定的な応答を行うための２つのセレクタ１４２を含み、はい（ｙｅｓ）セレクタの選択に応答して、ユーザからのさらなる入力を伴わずに道順を自動的に提示できると理解される。さらに、ＵＩ１３８は、このアプリケーションが本発明による予測に基づいてユーザが向かっていると判断した目的地に到着するまでの推定時間を含む推定到着時刻（ＥＴＡ）インジケータ１４４も含む。対照的に、図１４には、アメリカ合衆国の画像１４８を含む地図アプリケーションの「通常時」ＵＩ１４６と、より詳細な地図を表す特定の領域を選択するようにユーザに求めるプロンプト１５０とが示されている。

次に、図１５には、テキストメッセージアプリケーションの運転時ＵＩ１５２を示している。運転時ＵＩ１５２は、本原理によってクライアント装置のユーザが会いに向かっている相手であると予測されるユーザの連絡先である「Ｊｏｅ」にテキストメッセージを送ることを目的とする。従って、ＵＩ１５２は、入力領域１５４と、領域１５４内にテキストを入力するための「ソフト」キーボード１５６とを含む。対照的に、図１６には、「通常時」ＵＩ１５８を示している。この場合、テキストメッセージアプリケーションは、装置が車両内に存在しない状態で起動されると、テキストメッセージ送信処理を開始すべき受信者名を（やはり「ソフト」キーボードを用いて）入力するための領域１６０をＵＩ１５８に提示する。

次に、図１７には、カレンダアプリケーションの運転時ＵＩ１６２を示す。運転時ＵＩ１６２は、ユーザの予定が３０分以内に迫っていることをユーザにリマインドするテキスト通知を含む。対照的に、図１８の「通常時」ＵＩ１６６は、ユーザの今後の予定のリストを時系列順に表示している。

詳細な説明を続けると、図１９には、ソーシャルネットワーキングアプリケーションの運転時ＵＩ１６８を示している。ＵＩ１６８は、プロンプトを提示し、ユーザがどこを運転中であるかをユーザのソーシャルネットワーキングの「友人」に知らせるようにユーザがソーシャルネットワーキングサービスに投稿するためのテキスト入力ボックスを提供する。対照的に、図２０の「通常時」ＵＩ１７０は、ユーザのソーシャルネットワーキングアカウントに関連する「ニュースフィード」又は「アップデートフィード」を表示している。

従って、例えばリビングルームの設定でアプリケーションを呼び出した時とは対照的に、アプリケーションの様々な特定の機能を提示して、ユーザは、車両の運転中にこれらの機能を操作できると理解することができる。しかしながら、本原理は、特定の機能を予測できるだけでなく、ユーザが起動する可能の高いアプリケーション自体も予測できると認識する。従って、図２１に、運転中に呼び出される可能性の高いアプリケーションを予測するためのロジックを示す。

従って、図２１はブロック１７２から開始し、ロジックは、本原理に従ってクライアント装置が移動中の車両内に配置されていると判断する。次に、ロジックはブロック１７４に進み、例えばこのロジックの実行よりも前の時点に装置が車両内に配置されていた間に以前に装置上で選択されたアプリケーションを特定し、データベース内のデータにアクセスし、及び／又は別様に突き止める。次に、ロジックはブロック１７６に進み、装置の位置、従って車両の位置を特定し、この位置又はその付近のユーザにとって特に有用と考えられるいずれかのアプリケーションを特定する（例えば、ロジックは、ユーザがショッピングセンター付近に存在すると判断した場合、ショッピングアプリケーションがユーザの役に立つと判断することができる）。ロジックは、ブロック１７６からブロック１７８に進んで時刻を特定し、次にこの時刻に特に有用と考えられるいずれかのアプリケーションを特定する（例えば、ロジックは、時刻が朝の時間帯のいずれかであると判断した場合、コーヒーを購入するのに最も近い店舗の場所を特定するためのスターバックスアプリケーションが役に立つと判断することができる）。次に、ロジックはブロック１８０に進み、装置の位置及び／又はその付近の道路条件、天候条件及び／又は走行条件を判断し、従ってこれらの条件下で特に有用と考えられるアプリケーションを特定する（例えば、走行中の道路の前方で事故が起きている場合、交通アプリケーションが役に立つと判断することができる）。

その後、例示的なロジックは、ブロック１８２において、上述したような特定のパラメータを考慮した時に装置のユーザにとって適切及び／又は有用であると予測される１又はそれ以上のアイコンを含む運転時ＵＩを提示して終了することができる。次の図の説明に進む前に、例えば、ブロック１７４から１８０までのステップの全てを上述した順序で実行する必要性は低く、例えばこれらのステップのいずれかの組み合わせ又はこれらのステップの１つのみを実行することもできると理解されたい。

次に、図２２を参照すると、各それぞれのアイコンに関連する対象のアプリケーションを呼び出すために選択可能なアイコンを提示する例示的な運転時ＵＩ１８４を示している。従って、ＵＩ１８４は、例えば少なくとも部分的に図２１のロジックを用いて提示することができると理解されたい。図２２から理解できるように、ＵＩ１８４には４つのアイコンしか示していないが、より多くの又はより少ないアイコンを提示することもできる。ＵＩ１８４は、交通アプリケーションアイコン１８６、電話アプリケーションアイコン１８８、ローカルニュースアプリケーションアイコン１９０、及びレストラン検索アプリケーションアイコン１９２を含み、これらは全て、上述したような様々なパラメータに基づいてユーザの役に立つと予測されたものであると理解される。

詳細な説明を続けると、図２３には、クライアント装置が、本原理に従って車両内に存在すると（例えば、最初に）判断したものの、クライアント装置が車両を運転していないユーザに関連する場合、又はこのユーザがクライアント装置を操作できる場合に提示できる例示的なＵＩ１９４を示している。例えば、ある車両の乗客であるクライアント装置のユーザは、車の後部座席に乗車している時には必ずしも運転時ＵＩの使用を望むとは限らず、代わりに「通常時」ＵＩにアクセスしたいと望むことも考えられる。従って、ＵＩ１９４は、ユーザが車両内に存在すると思われる旨を示し、ユーザが車両の運転手であるか、それとも乗客であるかに関する入力を行うようにユーザに求める２つのセレクタ要素１９８を含むプロンプト１９６を含む。ＵＩ１９４は、車両を運転中のユーザが容易に読み取ることができ、「運転手」を示すセレクタが選択された後に図２２のＵＩ１８４などの別の運転時ＵＩを提示できるように比較的大きなテキストを含み、この点でそれ自体が運転時ＵＩを構成できると理解することができる。一方、ＵＩ１９４は、ユーザが乗客である場合にも、操作後に上述した例示的な「通常時」ＵＩのいずれかのような「通常時」ＵＩを提示することができるとさらに理解することができる。

従って、本原理によれば、クライアント装置のプロセッサが、装置が車両内に存在し、例えば車両が移動中であると判断した際に、ユーザが運転中に容易に操作及び識別できる単純化したＵＩ（例えば、単純化したリスト又はグリッド）を提示できるように、ＧＰＳ受信機及び／又は加速度計、又は上述した他の例示的な位置センサのいずれかのような位置センサを使用することもできると理解することができる。さらに、この単純化したＵＩは、特定の要因、アプリケーション、状況、及び過去の挙動及び装置の使用状況、位置、使用頻度、最近の行動（例えば、装置は、最近ユーザがプロスポーツのイベント会場にいたと判断し、その後スポーツに一般的に関連するアイコン、特定のチーム、このチームの次の試合、及び／又は試合会場などを提示する）、気象条件、交通条件、道路条件、時刻などの本明細書で上述したようなパラメータに基づいて動的に変化することもできる。実際に、クライアント装置は、ユーザのカレンダだけでなく、例えば装置の移動先の地域の公開イベントに関する、装置がアクセスできる情報にも基づいて、車両内の装置の移動先の位置だけでなく、参加するイベントを予測することもでき、従って、このような状況で有用と考えられるアプリケーション／アイコンを提示することができると理解される。従って、クライアント装置がアクセスできる本明細書で開示したこのような又はその他のいずれかの情報には、例えば上述したようなサーバ、及び／又はインターネットデータベースを介してアクセスできると理解されたい。

さらに、運転時ＵＩには、音楽、オーディオブック、ポッドキャスト、及びストリーミングオーディオなどのメディアを表示し、運転時ＵＩを通じて操作することもできる。装置が配置されている車両の移動速度に基づいて、アプリケーション／アイコン自体を変化させることも、これらをフィルタ処理することもできる。このような、運転時ＵＩのフィルタ処理及び／又は動的変化、又は別の運転時ＵＩの提示は、例えば単に予定通りにミーティングに向かっている場合とは対照的にミーティングに遅れていることに基づいて、ミーティングに参加する別の人物に連絡するためのアイコンを表示してその人物に遅れる旨を通知し、例えば装置がミーティングに遅れる可能性が高いと判断した時にのみ、推定到着時刻インジケータをメッセージ内にさらに提示できるような形で行うことができる。さらに、重要フラグが付けられた到着メッセージ（例えば、テキスト又は電子メール）については、クライアント装置がそのように認識し、例えばユーザの注意を引く形で運転時ＵＩ上に提示することもできる。

本原理は、上述した図を参照して具体的に説明しなかった以下の多くの機能も認識する。まず、クライアント装置は、例えば車載コンピュータ及び車両に取り付けられた車両ディスプレイと通信して、本明細書で説明したＵＩの一部又は全部をクライアント装置のディスプレイ上に提示することに加えて、又はその代わりに、これらのＵＩを車両ディスプレイ上に提示できるようにすることができる。次に、クライアント装置のプロセッサは、上述した運転時ＵＩの機能、及び運転時ＵＩと「通常時」ＵＩの切り替え／トグリングに加え、特定の時点で、クライアント装置が配置されている車両が、例えば駐車場又は赤信号で停止したと判断し、このような判断時には、車両の停止時間の少なくとも一部、場合によっては時間全体にわたって「通常時」ＵＩを提示することもできる。クライアント装置のプロセッサは、車両が再び動き始めた時（例えば、信号機が青に切り替わった時）には、再び運転時ＵＩを提示することができる。

別の例として、クライアント装置は、クライアント装置が道路上を移動しているか、それとも例えば線路上を移動しているか、航空機、船舶などによって移動しているかを区別できる情報にアクセスし、クライアント装置のプロセッサが、たとえ車両が移動していても公道上を移動しているわけではなく、従って装置のユーザが運転中である可能性が低く、このため必ずしも装置上に運転時ＵＩが提示されることを好まない可能性があると判断することもできる。従って、例えばユーザが列車に乗っている場合、クライアント装置は、線路の地図情報などの情報にアクセスして、装置が「車両」内で移動中であって上述した移動閾値を上回ってはいるが、自動車内に存在するのではないと判断し、運転時ＵＩではなく「通常時」ＵＩを提示すべきであると判断することができる。クライアント装置のプロセッサが、装置が配置されている車両がバスであることを示す情報にアクセスすることによって行った判断に基づいて、クライアント装置のユーザが市営バス又は通勤バス内の乗客であり、従ってユーザがバスの運転手ではないと予測され、このため運転時ＵＩではなく「通常時」ＵＩを提示する方が適切であると考えられる状況にも同様の原理を適用することができる。

さらに他の応用も考えられる。例えば、クライアント装置のプロセッサは、州法（及び／又は運転に関する法律、地方の法律など）に関する情報にアクセスすることができ、このアクセスした州法情報に基づき、特定の種類の提示又は構成のみが合法であると判断したことに応じて、運転時ＵＩ、又はその特定の提示又は構成を提示し、従って装置が配置されている州の州法に基づいてこのような提示又は構成を提示することもできる。実際には、装置を有する人物が運転中に「通常時」ＵＩを表示できないように画面を運転時ＵＩのみにロックすべきであると州法に規定されている場合、装置は、このような情報にアクセスして、このような状況で「通常時」ＵＩが提示されないように運転時ＵＩ画面及び／又はそのいずれかの機能にロックすることができる。

さらに別の例を説明すると、クライアント装置は、実際に移動中の車両内に配置されているにも関わらず、車両が民間の牧場又は駐車場などの非公有地内に存在すると判断した場合、たとえ装置が車両内で移動中であっても、例えば装置に入力する際のユーザの好みに基づいて、「通常時」ＵＩを提示すべきであると判断することができる。

最後の例として、本原理による運転時ＵＩを提示するクライアント装置は、音声コマンド、音声対話、口述、及びユーザからのその他の自然言語などの情報を収集し、これらの発言に基づいて運転時ＵＩを更新することによって応答できると理解されたい。従って、例えば、ユーザと別の人物との間の会話が特定の話題に向けられた場合、クライアント装置は、話し言葉を収集して認識し、会話の状況に基づいて関連性があると予測されるアプリケーション及び情報を運転時ＵＩ上に提示する。例えば、ユーザが、「ミーティングには誰が参加するか」と口頭で尋ねた場合、装置は、この質問を、例えばミーティングの参加者に関する情報及び／又はアイコンを運転時ＵＩ上に提示するためのコマンドとして認識し、ミーティング及び／又はミーティング主催者に関するさらなる情報を表示するように選択可能なアイコンを提示し、及び／又はミーティングに参加する各人物に、これらの参加者が順番にリスト化された更新を送ることができる（例えば、クライアント装置は、クライアント装置のユーザがミーティングに遅れそうであることを他のミーティング参加者に通知する通知、テキストメッセージ、電子メール及び／又はソーシャルネットワーキングの投稿などを、装置のプロセッサがユーザからの１回の操作又はタッチ入力に基づいてさらなるユーザ入力を伴わずに自動的に送信するようにする、「あなたが遅れそうなことを全員に通知しますか？」などの語句を含む１回のみ選択可能なアイコンを提示することができ、他者へのこのようなメッセージは、ユーザのＥＴＡを含むこともできる）。

本明細書では、特定の「状況に基づくユーザインターフェイス（ＵＩ）の構成」を図示し説明したが、本発明に含まれる主題は、特許請求の範囲のみによって限定されると理解されたい。

６０ 装置が移動中か？
６２ 通常時ユーザインターフェイスを提示
６４ 装置が移動閾値に達したか？
６６ 装置が車両内に存在、単純化したユーザインターフェイスを提示
６８ 装置が依然として移動中か？
７０ 車両のギヤが入っていないか、公園内に存在し、通常のユーザインターフェイスを提示

Claims (20)

1. クライアントプロセッサがアクセス可能な、搬送波ではない少なくとも１つのコンピュータ可読記憶媒体を備えた装置であって、前記コンピュータ可読記憶媒体は、前記クライアントプロセッサによって実行された時に、方法を実行するロジックを実行するように前記プロセッサを構成する命令を保持し、前記方法は、
   前記クライアントプロセッサが車両内に存在するとの判断に基づいて、表示する複数のアプリケーションのうちの１つを選択可能にするユーザインターフェイス（ＵＩ）を第１の構成でディスプレイ上に自動的に提示するステップと、
   前記クライアントプロセッサが車両内に存在しないとの判断に基づいて、表示する複数のアプリケーションのうちの１つを選択可能にする前記ＵＩを前記第１の構成とは異なる第２の構成で前記ディスプレイ上に自動的に提示するステップと、
   を含む、
   ことを特徴とする装置。
2. 前記複数のアプリケーションは、選択可能なタイルによって前記ＵＩ上に表示され、前記第１の構成は、前記第２の構成よりも相対的に少ないタイルを提示し、及び／又は前記第２の構成で提示されるタイルに比べて大きな寸法の少なくとも１つのタイルを提示する、
   請求項１に記載の装置。
3. 前記第１の構成の前記ＵＩは、前記クライアントプロセッサが前記車両内に存在し、該車両のギヤが入っているとの判断に基づいて前記ディスプレイ上に自動的に提示される、
   請求項１に記載の装置。
4. 前記ディスプレイは、前記クライアントプロセッサを含むクライアント装置のディスプレイである、
   請求項１に記載の装置。
5. 前記第１及び第２の構成は、前記ＵＩ上に表示される特定のアプリケーションに基づいて互いに異なる、
   請求項１に記載の装置。
6. クライアント装置が車両内に配置されているかどうかを判断するステップと、
   前記クライアント装置が車両内に配置されているとの判断に基づいて、前記クライアント装置が車両に配置されていないとの判断に基づいて前記クライアント装置のディスプレイ上に提示できる第２のＵＩよりも相対的に少ない情報を含む第１のユーザインターフェイス（ＵＩ）を前記ディスプレイ上に自動的に提示するステップと、
   を含むことを特徴とする方法。
7. 前記第１及び第２のＵＩの両方に提示される情報は、関連するアプリケーションを呼び出す選択可能な少なくとも１つのアイコンを含み、前記第１のＵＩは、前記第２のＵＩよりも相対的に少ないアイコンを提示する、
   請求項６に記載の方法。
8. 前記第１のＵＩは、アプリケーションを呼び出す選択可能な少なくとも１つのアイコンを含み、前記アプリケーションは、前記車両の動きに基づいて、前記クライアント装置を用いて連絡される可能性の高い人物と、前記クライアント装置が以前に存在していたことがある、前記アプリケーションを呼び出した時点又はその前後に前記車両が向かっている目的地の推定到着時刻とのうちの少なくとも一方を予測するように構成される、
   請求項７に記載の方法。
9. 前記クライアント装置のユーザによって呼び出される可能性の高い少なくとも１つのアプリケーションを予測するステップと、前記アプリケーションに関連するそれぞれのアイコンを前記ディスプレイ上に提示するステップとをさらに含み、前記予測するステップは、前記車両の移動中に以前に呼び出された少なくとも１つのアプリケーションの過去の選択に少なくとも基づく、
   請求項７に記載の方法。
10. 前記クライアント装置のユーザによって呼び出される可能性の高い少なくとも１つのアプリケーションを予測するステップと、前記アプリケーションに関連するそれぞれのアイコンを前記ディスプレイ上に提示するステップとをさらに含み、前記予測するステップは、アプリケーションが呼び出される頻度、前記クライアント装置の位置、時刻、前記呼び出されると予測されるアプリケーション以外の少なくとも１つのアプリケーションの最近の呼び出し、及び前記予測を行う際の前記クライアント装置の位置又はその周辺の走行条件のうちの少なくとも１つに少なくとも基づく、
    請求項７に記載の方法。
11. 前記クライアント装置が車両内に配置されているとの判断後に、前記車両の変速機が、ギヤが入った状態からパーキング位置に移行したとの判断に基づいて、前記第２のＵＩを自動的に提示するステップをさらに含む、
    請求項６に記載の方法。
12. クライアントプロセッサがアクセス可能な、搬送波ではない少なくとも１つのコンピュータ可読記憶媒体を備えた装置であって、前記コンピュータ可読記憶媒体は、前記クライアントプロセッサによって実行された時に、方法を実行するロジックを実行するように前記プロセッサを構成する命令を保持し、前記方法は、
    ユーザ活動トリガが試験を満たすかどうかを判定するステップであって、前記ユーザ活動トリガは、前記クライアントプロセッサに入力された信号によって表される、前記クライアントプロセッサに関連するクライアント装置の動作であり、及び／又は、所定のアプリケーションを実行するよう前記クライアント装置を用いることである、と、
    前記ユーザ活動トリガが前記試験を満たすとの判定に応答して、前記クライアント装置上に第１の出力を提示するステップと、
    前記ユーザ活動トリガが前記試験を満たさないとの判定に応答して、前記クライアント装置上に前記第１の出力とは異なる第２の出力を提示するステップと、
    を含むことを特徴とする装置。
13. 前記クライアントプロセッサは、前記クライアント装置によってサポートされる、
    請求項１２に記載の装置。
14. 前記活動トリガは、閾値を上回る動作である、
    請求項１２に記載の装置。
15. 前記活動トリガは、前記クライアント装置を用いた前記所定のアプリケーションの実行である、
    請求項１２に記載の装置。
16. 前記第１の出力及び第２の出力は、それぞれの通知である、
    請求項１２に記載の装置。
17. 前記第１の出力は、第１のアプリケーションに関する情報を含み、前記第２の出力は、前記第１のアプリケーションとは異なる第２のアプリケーションに関する情報を含む、
    請求項１２に記載の装置。
18. 前記第１の出力は、少なくとも第１の連絡先のユーザの連絡先情報を含み、前記第２の出力は、少なくとも第２の連絡先のユーザの連絡先情報を含む、
    請求項１２に記載の装置。
19. 前記第１の出力は通知であり、前記第２の出力はアプリケーションの呼び出しである、
    請求項１２に記載の装置。
20. 前記第１の出力はアプリケーションの呼び出しであり、前記第２の出力は通知である、
    請求項１２に記載の装置。

Images