アプリケーションのセッション継続性に対応するシステム及び方法
【課題】２台以上の機器間でのアプリケーションのセッション継続性をユーザに提供する。
【解決手段】近距離通信によって第１の機器は第２の機器とペアとなり、次に、第１のアプリケーションの現在の状態とこのアプリケーションに関係した消費されているデータの状態をセッション・データとして保存することによって、サーバによって実行されているアプリケーションのセッションを第１の機器から第２の機器へ転送する。このセッション・データは、次に、第２の機器へ転送され、このセッション・データによって与えられた状態に基づいて、第２の機器は第２のアプリケーションを実行する。上記の機器の一方または両方がセッション転送要求をサーバへ送信し、これによりサーバは、第１のアプリケーションによる消費が転送された状態において第２のアプリケーションによって消費されることになるアプリケーションに関係したデータを第２の機器へ再ルーティングする。
【解決手段】近距離通信によって第１の機器は第２の機器とペアとなり、次に、第１のアプリケーションの現在の状態とこのアプリケーションに関係した消費されているデータの状態をセッション・データとして保存することによって、サーバによって実行されているアプリケーションのセッションを第１の機器から第２の機器へ転送する。このセッション・データは、次に、第２の機器へ転送され、このセッション・データによって与えられた状態に基づいて、第２の機器は第２のアプリケーションを実行する。上記の機器の一方または両方がセッション転送要求をサーバへ送信し、これによりサーバは、第１のアプリケーションによる消費が転送された状態において第２のアプリケーションによって消費されることになるアプリケーションに関係したデータを第２の機器へ再ルーティングする。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、２台以上の機器間でのアプリケーションのセッション継続性をユーザに提供するためのシステム及び方法に関係する。
【背景技術】
【０００２】
携帯機器がますます普及するにつれて、携帯機器で利用されるアプリケーションも増えている。例えば、携帯機器は、インターネット・ラジオ、ソーシャル・ネットワーキング、ビデオ・ストリーミング、ウェブ閲覧、及びゲーム用のアプリケーションをユーザに提供する。これらのアプリケーションをホストするための処理能力を有する携帯機器もいくつかあるが、アプリケーション・サーバでこれらのアプリケーションをホストし、アプリケーションをネットワークを介して配信する傾向が高まっている。この枠組みは、クラウド・コンピューティングと呼ばれることもある。
【０００３】
現在、ネットワーキング機能は、車両に搭載するという状況でもより実現可能になってきている。専用の移動ネットワーキング・カードを通じてまたは携帯機器を介して、車載インフォテインメント・システムが、ネットワーキング機能をもち始めてもいる。それに応じて、携帯機器に搭載されているアプリケーションと同様に、車載インフォテインメント・システム特有のアプリケーションを提供する傾向が高まっている。携帯機器での利用という状況に対応したアプリケーション・ストアの枠組みと同様に、ユーザは、自分の車載インフォテインメント・システムに合ったアプリケーションを購入できるようになるだろう。さらに、インフォテインメント・システムの製造者は、広範囲にわたる購入可能なアプリケーションをユーザに提供するために、サードパーティにＳＤＫ（ソフトウェア開発キット）を提供することになろう。これらのアプリケーションのホスティングは、クラウド中で維持することにもなりそうだ。これらのアプリケーションは、ヒューマン・マシン・インターフェース（ＨＭＩ）を使用して制御可能である。
【発明の概要】
【０００４】
上記の傾向の現実化に伴って、ユーザ機器と車載インフォテインメント・システムとの間の継続性への要望が高まっている。
【０００５】
上記の節では、必ずしも従来技術ではない、本開示に関連した背景情報を記載している。
【０００６】
図面のうちのいくつかの図中で、同じ参照番号は同じ要素を示す。ここに記述する図面は、すべての可能な実現ではなく、選ばれた実施形態だけを説明するためのものであり、本開示の範囲を限定するものと意図されていない。
【図面の簡単な説明】
【０００７】
【図１】２台の機器とアプリケーション・サーバの関係を示す図である。
【図２】アプリケーションのセッション継続性を達成するために実行可能な例示的な方法である。
【図３】アプリケーションのセッション継続を実行するように構成された機器の例示的な構成要素を示すブロック図である。
【図４Ａ】第２の機器が通信ネットワークへの接続性を有する場合におけるデータ転送を示す図である。
【図４Ｂ】第２の機器が通信ネットワークへの接続性を有しない場合におけるデータ転送を示す図である。
【図５】第２の機器への入力装置として使用されている携帯機器の例を示す図である。
【図６】例示的なユーザ・インタフェースを示す図である。
【図７】車両のインフォテインメント・システムへ転送後のアプリケーションの例示的なユーザ・インタフェースを示す図である。
【図８】インフォテインメント・アプリケーション、セッション継続アプリケーション及びサーバ間の通信を示すハードウェア図である。
【図９】セッションの転送を実施するための各機器とサーバ間の通信を示すシーケンス図である。
【図１０】セッション転送動作を理解するのに役立つシステム図である。
【図１１】セッション転送動作を理解するのに役立つセッション転送フロー図である。
【図１２】さらに詳しいセッション転送フロー図である。
【図１３】セッション継続エージェントのフロー図である。
【図１４】車両ベースの実施形態におけるドライビング・コンテクストを理解するのに役立つプロセス図である。
【図１５】本文書に記述したシステムと方法を使用して実施され得る非限定的な例としてのシナリオを示す。
【図１６】本文書に記述したシステムと方法を使用して実施され得る非限定的な例としてのシナリオを示す。
【図１７】本文書に記述したシステムと方法を使用して実施され得る非限定的な例としてのシナリオを示す。
【発明を実施するための形態】
【０００８】
添付の図面を参照して、例としての実施形態をより詳細に説明する。
【０００９】
アプリケーションのセッション継続性に対応するシステム及び方法をここに開示する。アプリケーションのセッション継続性は、携帯機器のアプリケーション環境と車載インフォテインメント・システムのアプリケーション環境との間でシームレスな移行をユーザに提供する。本文脈で使用されるアプリケーションは、特定の機器向けに設計さているソフトウェア・プログラムである。アプリケーションのセッションは、アプリケーションが再起動される度に新たなセッションが開始するようになっているアプリケーションの特定のインスタンス（状態）である。したがって、アプリケーションのセッション継続性は、複数の機器間でアプリケーションのセッションを維持することであると考えることができる。例えば、ユーザが自分の車両に乗車するときに、アプリケーション・サーバでホストされたインターネット・ラジオ・アプリケーションを利用して、ユーザは携帯機器に音楽をストリーミングしている最中である可能性がある。開示された構成を利用すれば、ユーザのセッションはインフォテインメント・システムに転送され得る。当該アプリケーション・サーバ、すなわち通信相手のアプリケーション・サーバは、続いて、オンライン・ラジオ・コンテンツを車両のインフォテインメント・システムへストリーミングする。これは、自動的に、またはほんの少しだけユーザの手を借りて、遂行され得るものとされる。アプリケーションのセッション継続性は、例えば、ユーザが車両に乗車したときに聴いていた同じトラックの同じ位置からアプリケーション・サーバがサービスをインフォテインメント・システムへ転送可能にする。他の例では、アプリケーションのセッション継続性は、前のアプリケーションからのデータを使用して、新しいアプリケーションを開始することによって実現され得る。
【００１０】
図１は、アプリケーションのセッション継続性を実現する例示的な機器を示す図である。この図には、携帯機器１２と車両によって表わされた車両のインフォテインメント・システム１４の２台の機器が示される。２台の機器は、相互間の通信機能をもっているとされる。例えば、携帯機器１２と車両のインフォテインメント・システム１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）などのＷＰＡＮを介して、ＷｉＦｉを介して、またはＵＳＢコードなどのケーブル接続を介して相互に通信できる。両機器１２と機器１４は、通信ネットワーク１０を介してアプリケーション・サーバ１６と通信できる。これらの機器は、複数のアプリケーション・サーバと通信するように構成されるものとされる。
【００１１】
上記の構成を使用して、アプリケーション・サーバ１６は、第１のアプリケーションを携帯機器１２へ、第２のアプリケーションをインフォテインメント・システム１４へ配信できる。携帯機器１２とインフォテインメント・システム１４のオペレーティング・システムは、顕著に異なるプラットフォーム向けに設計され得る。そのため、携帯機器１２で実行するように設計されたアプリケーションは、インフォテインメント・システム１４では実行できない。逆も同様である。それに応じて、アプリケーション・サーバ１６は、実質的に同様の機能を実現するたように、あるアプリケーションの修正バージョンを通信相手の各機器１２と機器１４に配信できる。
【００１２】
図２は、アプリケーションのセッション継続性を達成するための例示的な方法を示す。最初に、ステップ２０２に示すように、ユーザはセッション転送を起動する。これは、認識された携帯機器１２をインフォテインメント・システム１４の通信範囲内に持ち込むことによって自動的に、または何らかのユーザ入力によって、実行可能である。後者の場合、携帯機器を車両上の所定の箇所に触れさせるなどの、または機器のタッチ・スクリーンまたはＨＭＩに触れて所定のジェスチャーを行なうことによって、接触ジェスチャーをユーザは行なえる。接触ジェスチャーの例は、ユーザがインフォテインメント・システム１４に付属した接触感知可能な領域内に携帯機器１２を軽く打ち当てることである。本質的には、各機器内の信号が、ユーザがセッションを転送したいことをシステムに知らせる。
【００１３】
ユーザがセッション転送を起動したら、ステップ２０２に示すように、２台の機器は互いにペアをなすことになる。機器どうしをペアにすることは、２台の機器に相互通信を確立するように要求することになり得る。互いに通信が確立したら、各機器１２と機器１４は、利用可能なアプリケーションなどの情報を交換可能になる。一揃いの対応するアプリケーションのセットが各機器１２と機器１４に存在する場合には、例えば、両機器が特定のインターネット・ラジオ・サービス向けのアプリケーションをもっている場合には、ステップ２０４で、転送可能なアプリケーションのリストが生成され、ユーザに表示され得る。ユーザはセッションを転送するための所望のアプリケーションを選択できる、またはこれは自動的に実行され得る。後者の場合、自動的に転送可能なアプリケーションの所定のリストをどちらか一方の機器がもち得るか、または、「ユーザが携帯機器で地図アプリケーションを実行中である場合には、ＨＭＩ上で自動的にナビゲーション・アプリケーションを開く」または「ユーザがラジオ・アプリケーションをストリーミング中であり、車両のラジオがＯＮである場合には、ラジオ・アプリケーションのセッションを転送する」といった所定の規則が、どのアプリケーションを自動的に転送するのかを決定し得る。このような規則は、どちらか一方の機器のコンピュータで読取り可能な媒体に記憶され得るものとする。さらに、後述するように、第２の機器１４に特定のアプリケーションがないときは、当該機器１４にそのアプリケーションをダウンロードさせることができる、またはユーザにそのアプリケーションをダウンロードするように指示できる。転送する特定のセッションが指定されたら、各機器１２と機器１４の一方または両方は、ステップ２０６に示すように、アプリケーション・サーバ１６に対してセッション転送要求を起動できる。
【００１４】
アプリケーション・サーバ１６は、当該要求といずれかの追加のセッション・データ、すなわち、アプリケーションに関連した情報やセッションに固有の情報などの、当該要求を実施するために必要な転送対象の進行中のセッションに関するデータを受信する。例えば、あるアプリケーションを対象とする要求が、アプリケーション・サーバ１６に送信されることがあると、セッション識別番号とそのアプリケーションのセッションの現在の状態などの、そのアプリケーションのセッションに関するパラメータが当該要求に含まれる。アプリケーションによって異なるセッション・データの例は、カレンダー・アプリケーションではユーザが見ている特定のカレンダー項目、音楽ストリーミング・アプリケーションではトラック番号、トラック位置及びプレイリスト、または映画検索アプリケーションでは選択された映画及び映画館を含む。
【００１５】
アプリケーション・サーバ１６は当該要求を受信すると、アプリケーション・サーバ１６は、次に、ステップ２０８で示すように、携帯機器１２で実行していたセッションを再作成するために、受信したセッション・データを使用して、インフォテインメント・システム１４に対して新しいアプリケーションのセッションを開始する。このセッションは、新しく再作成されたセッションがそれ以前のセッションが転送された時点から開始するようにするセッション・データを使用して再作成される。例えば、ビデオ・ストリーム・セッションが第２の機器１４で起動され得るとき、セッション転送時に第１の機器１２で表示されていたフレームと同じフレームから開始できる。両方の機器向けの同一のアプリケーションが実行可能である場合には、携帯機器１２の代わりに転送先の機器のＩＰアドレスへデータをルーティングすることによって、サービスを再作成する必要はなくサービスを単に転送先の機器１４へ移動するだけでよいものとする。アプリケーション・サーバ１６は、次に、ステップ２０８で示すように、インフォテインメント・システム１４に当該アプリケーションを配信する。アプリケーション・サーバ１６は携帯機器１２へのサービスを継続することも、携帯機器１２へのサービスを中断することも、または携帯機器１２のセッションを完全に終了することもできるものとする。
【００１６】
上記を実行することによって、異なるコンテクスト間で、サービスのいかなる中断もなしにまたは中断を最小限にとどめて、例えば、同じ設定、同じユーザ名、同じメディア選択といったユーザのセッションの一つ以上のものが維持される。アプリケーションのコンテクストは、そのアプリケーションが使用されている設定／プラットフォームである。例えば、異なるコンテクストは、自動車設定、携帯機器、パーソナル・コンピュータ、ラップトップ、航空機、オートバイ、テレビジョン、各種の家庭用電子機器等を含み得る。上記の構成は、上にリストしたコンテクストどうしに適用可能であり、これらは本開示の範囲内に入ると見なされることが想定される。けれども、説明上の目的で、大部分の説明は携帯機器と車両のインフォテインメント・システムの間のセッション継続性を維持することについて記載されている。開示内容は、広範囲にわたるコンテクストに適用可能であると解釈される。例えば、あるユーザは、航空機に搭乗し、携帯機器１２を所持している。携帯機器は、ビデオ・ストリーミング・アプリケーションをユーザの座席のパーソナル・インフォテインメント・システムへ転送できる。同様に、ユーザが帰宅して彼女の車を車庫に駐車すると、セッションは車両のインフォテインメント・システム上で実行中のアプリケーションをユーザのパーソナル・コンピュータへ転送できる。
【００１７】
図３は、アプリケーションのセッション転送を実行するように構成された機器１４の構成要素を示す。構成要素は、自機器１４と他機器、例えば、携帯機器１２との間の通信を可能にする第１の通信モジュール３２を含む。第１の通信モジュール３２は、例えば、ＷｉＦｉまたはＷｉＭａｘ送受信器であり得る。第１の通信モジュール３２は、アプリケーション・サーバ１６からのアプリケーション・データをアプリケーション制御モジュール３４へ伝達する。いくつかの実施形態では、機器１４はＷｉＦｉまたはＷｉＭａｘ機能をもたないことがあり得る、すなわち、機器１４はインターネットに接続できないことがあり得る。これらの例では、第１の通信機器１４は携帯機器１２にテザリングで連結することが可能であり、携帯機器１２をモバイル・ルータとして使用できる。
【００１８】
アプリケーション制御モジュール３４は、各種のアプリケーションのセッションを制御する。例えば、アプリケーション制御モジュール３４は、ユーザが選択したアプリケーションのうちフォアグランドで実行するのはどのアプリケーションで、バックグランドで実行するのはどのアプリケーションかを決定できる。さらに、アプリケーション制御モジュール３４は、アプリケーション・サーバからデータを受信し、受信したデータに基づいて必要な何らかの変更をＨＭＩ３６へ伝達する。逆に、ＨＭＩ３６へ入力された何らかのユーザ入力は、アプリケーション制御モジュール３４によって受信され、アプリケーション・サーバへ送信される。さらに、アプリケーション制御モジュール３４は、各種のアプリケーションのセッションの状態を維持するために、データ格納部４８と通信する。例えば、アプリケーション制御モジュール３４は、第１の通信モジュール３２を介してアプリケーション・サーバ１６へ送信するユーザのユーザ名とパスワードを受信し得る。加えて、アプリケーション制御モジュール３４は、特定のアプリケーションへアクセス時に、アプリケーションの状態及び／またはユーザの設定を示す各種パラメータをデータ格納部へ格納することができる。アプリケーション制御モジュール３４はまた、アプリケーション市場へアクセスするように構成される。例えば、車両コンテクストでは、インフォテインメント・システムの提供者は、アプリケーション特有のルック＆フィール（画面の見た目と操作感）がその特定のインフォテインメント・システムに合うように実現可能なように、ＳＤＫを開発者に提供できる。第１の通信モジュール３２を介して、アプリケーション制御モジュール３４は、そのインフォテインメント・システム上での所望のアプリケーションをダウンロードできる。処理の大部分はクラウド中で実行されるが、それでもアプリケーションはあるソフトウェアが機器自体にインストールされるように要求することがあり得るものとする。アプリケーション制御モジュールは、機器１４のＨＭＩ３６、第２の通信装置４２、及びペア化モジュール４４とさらに通信するように構成される。
【００１９】
第２の通信モジュール４２は、自機器１４と他機器、例えば、携帯機器１２との間の、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）またはＺｉｇｂｅｅ（登録商標）といったパーソナル・エリア・ネットワークを介した通信を可能にする。他の実施形態では、ＷｉＦｉ接続などの他の通信手段も利用可能であることが想定される。第２の通信モジュール４２は、自機の近辺内の、例えば、５メートル以内にある他の通信可能な機器を感知するように構成され得る。第２の通信モジュール４２がこのような機器を感知する範囲内で、本モジュールは他の機器の通信モジュールとの通信を開始できる。他の機器は、通信を始める通信相手として自機器１４に登録されなければならない、または認めらなければならないことがあり得るものとする。この機能性は、機器発見及び同期化モジュール４０によって実行可能であると想定される。
【００２０】
機器発見及び同期化モジュール４０は、自動車内に存在する携帯機器を識別するように構成され、その携帯機器１２にセッション転送を勧めることができる。代替的に、その携帯機器が、機器発見及び同期化モジュール４０に対してセッション転送を勧めることができる。機器どうしがセッション転送に同意するとただちに、機器発見及び同期化モジュール４０は、他の機器上で実行中のアクティブなアプリケーションのリストを受信できる。ただし、この受信が起こり得る前に、２台の機器は互いにペアとなる。これはペア化モジュール４４によって実行可能である。
【００２１】
ペア化モジュール４４は、安全なやり方で自機器１４と他機器１２をペアにするように構成される。自動的に実行される場合、第２の通信モジュール４２は近隣内で信号をブロードキャストしているいずれかの機器から信号を受信する。ブロードキャスト信号は、送信機器の識別を示すインジケータを含む。ペア化モジュール４４は、この信号を受信し、その機器識別子を自機器１４のメモリーに記憶された機器識別子のリストと照合し得る。その機器が識別されれば、ペア化モジュール４４は２台の機器１２と機器１４間の通信を確立する。ペア化は自動的に実行可能であるが、ペア化モジュール４４は、ユーザ側の接触ジェスチャーに応じてペア化を実行するように構成され得る。このような構成では、ペア化モジュール４４は、ユーザのセンサー入力を確定したときにペアが要求されていることを決定する。例えば、ペア化の要求は、ユーザに機器１４の表示部のスクリーンを携帯機器１２で軽く叩かせることによって起動され得る。携帯機器１２は、機器１２に付属した加速度計が機器の突然の加速とその後の急減速を感知すると、接触行為によるサービスの転送要求を認識できる。機器１４は、表示部のタッチ・スクリーンが携帯機器１２によって触れられると、接触行為による要求を認識できる。所定のジェスチャーが両方の機器によって認識されると、機器１２と機器１４は、所定のジェスチャーをペア化の要求として受け止める。上記はペア化の例であり、機器どうしをペア化するためのその他の手段が存在すると想定される。機器どうしをペア化するより受動的な手段が存在すると想定されるが、接触行為はセッション転送を行なうよう指示する明示的な要求を示す物理的行為に相当するから、接触行為はユーザにとって便利であり得る。さらに、ペア化を指示する接触による要求は、機器１４が複数のユーザとペアを組めるようにできる。
【００２２】
機器どうしがペア化されるとただちに、機器発見及び同期化モジュール４０は、アプリケーションの同期化を実行できる。機器１４上の機器発見及び同期化モジュール４０は、ペアの相手の機器上のアクティブなアプリケーションのリストを受信できる。機器発見及び同期化モジュール４０は、次に、アプリケーション制御モジュール３４に問い合わせることによって自機器１４上の対応する非アクティブなアプリケーションを決定できる。ユーザ入力または所定のユーザ設定または規則によって、機器発見及び同期化モジュール４０はどのアプリケーションを同期させるのかを決定する。
【００２３】
あるアプリケーションが機器へダウンロードされていなかった場合には、機器発見及び同期化モジュール４０は、アプリケーション制御モジュール３４からそのアプリケーションがダウンロードされるように要求するように構成され得る。
【００２４】
アプリケーションのセッションが転送されるように設定されるとただちに、セッションの継続性を確保するために、アクティブなアプリケーションのコンテクストからセッション・データが非アクティブなコンテクストへ送信される。例えば、ユーザが車両へ乗り込む例では、ユーザの携帯機器１２が、携帯機器１２上で実行中のアクティブなアプリケーションの一つ以上についてのセッション・データを機器１４の第２の通信モジュールへ転送する。セッション・データは、アプリケーションＩＤ、セッションＩＤ、及びその特定のアプリケーションとセッションに関係し得る何らかデータ、例えば、ラジオ・アプリケーションの場合にはトラック番号と位置を含み得る。言及したとおり、アクティブなサービスまたはアプリケーションのリストが確定され、各アプリケーションのセッションの現在の状態がさらに確定される。例えば、ユーザがインターネット・ラジオ・アプリケーションからストリーミングされた音楽を聴いている場合には、現在のトラック、そのトラックの位置及びプレイリストが、携帯機器１２から機器１４へ第２の通信装置４２を介して転送される。いくつかの実施形態では、例えば、非アクティブなアプリケーションのデータといった、非アクティブなセッション・データも送信され得ると想定される。これは、機器どうしが完全な同期を行なうように構成される場合に実行され得る。同期化は、例えば、ＰＷＡＮを通じてまたはネットワーク１０を通じて、各機器の第２の通信モジュールを介して実行可能であると想定される。
【００２５】
機器発見及び同期化モジュール４０は、セッション転送を補助するために、ペアの相手の機器へ情報を送信するようにさらに構成され得る。例えば、機器１４が割り当てられたＩＰアドレスをもつ場合には、この情報がペアの相手の機器へ送信され得る。このような情報は、アプリケーション・サーバ１６が機器１４へ要求されたアプリケーションを配信できるように、アプリケーション・サーバ１６へ送信可能であるものとする。
【００２６】
セッション情報が同期されたら、アプリケーション・サーバ１６からのサービスを要求することによって、アプリケーション制御モジュール３４は、セッション転送を起動できる。代替的に、ペアの相手の機器が、セッションを機器１４へ転送するように、アプリケーション・サーバ１６へ要求を送信できる。アプリケーション・サーバ１６がセッション転送要求を受信するとただちに、アプリケーション・サーバ１６は機器１４への当該アプリケーションの配信を開始できる。アプリケーション・サーバ１６は、配信先の機器のアプリケーション制御モジュール３４からデータを受信する。当該アプリケーションに基づいて、受信したデータは入力として扱われ、アプリケーション・サーバ１６は受信したデータを使用してアプリケーションを実行する。当該アプリケーションの状態の何らかの変化が、ネットワーク１０を介して、アプリケーション・サーバ１６によって機器１４へ送信される。アプリケーション制御モジュール３４は、アプリケーション・サーバから受信した情報、すなわち、当該アプリケーションの状態の変化に基づいてＨＭＩを更新する。
【００２７】
ユーザ選択またはそのアプリケーション自体に基づいて、アプリケーション・サーバ１６はペアの相手の機器へのサービスを停止できるか、またはペアの相手の機器への配信を継続できるもとする。
【００２８】
セッションが機器１４へ転送されたら、アプリケーション制御モジュール３４は、ユーザ設定を読み出すためにデータ格納部４８へアクセスできる。さらに、アプリケーション制御モジュール３４は、特定のアプリケーションの特定の状況における実行を許可しないように構成され得る。例えば、車両設定においては、ユーザは、運転中に電子メールを続けることをアプリケーション制御モジュール３４によって禁止され得る。ある活動を禁止する決定は、ドライバにとって安全だとみなされることに、または国、地域、州、または市の統制法令に基づくものであり得る。しかし、ユーザが帰宅した時点で、電子メールを完了するようにユーザに指示するようにしてもよいし、または別のセッション転送が電子メールのアプリケーションのセッションをユーザの自宅のコンピュータへ転送してもよい。
【００２９】
第２の機器、例えば、車両のインフォテインメント・システムへのアプリケーションのセッション・サービスは、いつかの方法で実施可能であると想定される。図４Ａと図４Ｂは、アプリケーションを配信するための二つの代替的な手段を示す。図４Ａでは、アプリケーション・サーバ１６は、携帯用アプリケーション１８をネットワーク１０を介して携帯機器１２へ配信する。アプリケーション・サーバ１６はまた、車両用アプリケーション２０をネットワーク１０を介して車両のインフォテインメント・システム１４へ配信する。図４Ｂでは、車両のインフォテインメント・システム１４は、ネットワーク１０への直接の接続をもたないと仮定される。この例では、車両のインフォテインメント・システム１４は、前述したように、携帯機器１２にテザリングで連結できる。アプリケーション・サーバは、次に、携帯機器１２を仲介的な中継機として利用して、車両用アプリケーション２０を車両のインフォテインメント・システム１４へ配信する。
【００３０】
さらに、上述のアプリケーション転送は、アプリケーション・サーバ１６が実質的に同様のアプリケーションを配信することを前提としたが、関連したアプリケーションの転送を選択するように機器は構成され得る。例えば、ユーザが携帯機器１２上で第１のアプリケーションを実行している場合、例えば、レストランお勧めアプリケーションからのレストランまたはカレンダーから予約を選択したとすると、機器１４は、同期化中に、携帯機器からのセッション・データを使用して、ナビゲーション・アプリケーションのセッションを起動するように要求できる。ユーザが携帯機器１２上でレストランを選択したとすれば、インフォテインメント・システム１４は、セッションデータとして受信した、選択したレストランの住所を使用してナビゲーション・アプリケーションを起動できる。アプリケーション制御モジュール３０は、同期化中に受信したセッション・データの分析に基づいて、このようなインテリジェントな推定を実行するように構成され得る。
【００３１】
様々な異なる実施形態が可能であるが、図８と図９は、一つ以上のインフォテインメント・アプリケーションと共に機器上で実行するセッション継続アプリケーションによって、セッション継続が行なわれる例示的な実施形態を示す。追って説明するが、セッション継続アプリケーションは、インフォテインメント・アプリケーションにはそれらが本来処理するように設計されたインフォテインメント・タスクを自由に処理させながら、機器間のセッション制御と転送を調停する。
【００３２】
図８を参照すると、モバイル機器（この場合には、携帯機器１２とインフォテインメント・システム１４の両方がモバイル機器であると見なされる）は、メモリー装置１０２がそれに接続される機器ＣＰＵまたはプロセッサ１００を含む。メモリー装置１０２は、プロセッサにより読取り可能な命令と、プロセッサが記憶された命令を実行時に処理対象とするデータを記憶するように構成される。メモリー装置１０２は、したがって、コンピュータが読取り可能な命令とデータの非一時的記憶機構を提供する。
【００３３】
より具体的には、メモリー装置１０２は、プロセッサ１００によって選択的に実行され得る一つ以上のアプリケーション・プログラムをサポートすることを含む、プロセッサ１００によって実行される基本的な通信及びメモリ・アクセスを提供するオペレーティング・システム命令のセットを記憶するように構成される。この点に関し、メモリー１０２は、セッション継続アプリケーションと図示したインフォテインメント・アプリケーション１０８などの一つ以上のインフォテインメント・アプリケーションをその内部に記憶したものである。機器は、インフォテインメント・データ１１０を得るために、並びにあるセッション制御データ１１２を交換するためにサーバ１６と通信するように適合される。インフォテインメント・データは、例えば、消費されることになるストリーミング・データまたはその他のコンテンツを含み得る。必要に応じて、インフォテインメント・データは、インフォテインメント・アプリケーション１０８の実行可能なコピーなど、機器にロードして実行するための実行可能なアプリケーション・プログラム命令も含み得る。
【００３４】
セッション継続アプリケーション１０６は、一つの機器から別の機器へのアプリケーションのセッションの転送を調停するために、図９に関連してより詳しく説明するとおり、サーバ１６と通信する。この転送プロセスの一部として、セッション継続アプリケーションは、他の機器から得たセッション・データ１１４をインフォテインメント・アプリケーション１０８によって利用されるようにロードさせることによって支援する。したがって、図示のとおり、セッション・データ１１４は、セッション継続アプリケーション１０６からインフォテインメント・アプリケーション１０８へ渡されるように示される。点線で示されるように、セッション・データのこの転送は、オペレーティング・システム１０４の助けを受けて処理され得る。
【００３５】
セッション継続アプリケーション１０６は、インフォテインメント・アプリケーション１０８と同じようにロードされ、管理される単独のアプリケーションとして図８では示したが、当然のことながら、継続アプリケーション１０６はオペレーティング・システムによって管理されたある層などの異なる層で実現されてもよいものとする。このことは、図１１に示されており、セッション継続アプリケーションが、オペレーティング・システムのレンダリング層とインフォテインメント・アプリケーションなどのインストールされたアプリケーションの間に介在するセッション継続マネージャとして示される。
【００３６】
図９を参照すると、アプリケーションのセッション転送を実施するためのサーバと携帯機器１２と機器１４の間の交信は、各携帯機器１２と機器１４のセッション継続アプリケーション１０６Ａ、１０６Ｂの間の交信を含む。この場合もまた、携帯機器１２とインフォテインメント・システム１４の両方がモバイル機器であると見なされる。機器１２は、例えば、携帯型のモバイル機器であり、機器１４は移動車両のダッシュボードに取り付けられたインフォテインメント・システムであるとしてよい。
【００３７】
図９は、インフォテインメント・データ（この場合にはストリーミング・データ）とセッション制御データ（メッセージ）が、サーバとモバイル機器の個々の構成要素間でどのように受け渡されるのかを示す。１２０で先ず、サーバ１６はモバイル機器１２のインフォテインメント・アプリケーション１０８Ａへストリーミング・データを送信することが示される。もちろん、送信されるデータはストリーミング・データ以外の形式であってもよく、ここでストリーミング・データを図に示したのは、単に説明上の目的のためである。
【００３８】
さて、モバイル機器１２のユーザは、インフォテインメント・アプリケーション１０８Ａを介してストリーミング・データを楽しみながら、モバイル機器１４の近くにやってきたとしよう。例えば、携帯型のモバイル機器１２のユーザは、自分の自動車に乗り込んで、点火装置をオンにすると、モバイル機器１４がオンになり、機器１２と機器１４の間でペア化シーケンス１２２が開始される。ペア化１２２は、自動的にまたはユーザの指示によって開始され得るが、これはユーザ選択及び／または各機器のその他の制約による。
【００３９】
ペア化シーケンス１２２の一部として、セッションの転送を受信するために機器１４上で必要になるインフォテインメント・アプリケーションが何であるかを決定するために、セッション継続アプリケーション１０６Ｂはその相手であるセッション継続アプリケーション１０６Ａと通信する。必要なインフォテインメント・アプリケーションが機器１４の機器メモリー１０２内にすでに記憶されている場合は、セッション継続アプリケーション１０６Ｂは、そのインフォテインメント・アプリケーションがすでに実行していなければ、そのインフォテインメント・アプリケーションを起動するように、関連のオペレーティング・システム１０４を通じてメッセージを送信する。必要なインフォテインメント・アプリケーションが機器１４の機器メモリー内に記憶されてない場合は、セッション継続アプリケーション１０６Ｂは、１２４で示すように、ダウンロード要求をサーバ１６へ送信すると、サーバ１６は要求されたアプリケーション・プログラムを機器１４へ送信することによって応答し、機器１４のオペレーティング・システムは要求されたアプリケーション・プログラムをインストールして起動する。
【００４０】
これで今は、両方の機器１２と機器１４が適切なインフォテインメント・アプリケーションを実行させているので、セッション継続アプリケーション１０６Ａと１０６Ｂは、インフォテインメント・アプリケーション１０８Ａからインフォテインメント・アプリケーション１０８Ｂへセッション・データを転送するために協働する。図示されるように、この転送は、セッション・データ１１４として各セッション継続アプリケーションを経由して渡され得る（図８のセッションで・データ１１４も参照）。
【００４１】
次に、セッション継続アプリケーション１０６Ａ（または選択的にまたは追加的に、セッション継続アプリケーション１０６Ｂ）は、セッション制御データ１１２として、セッション転送要求メッセージをサーバに送信する（図８のセッション制御データ１１２も参照）。セッション制御データ１１２は、ユーザが現在楽しんでいるデータの特定の部分が何であるかを知るために、サーバが必要とするいずれかの適用可能なメタデータまたはセッション制御データを含み得る。例えば、ストリーミング・データが録音された必需物である場合は、セッション制御データは、曲ＩＤ、トラック番号、トラック位置カウンタ及びその他のプレイリスト情報等のメタデータを含むことになる。サーバは、新しいストリーミング・データ・セッション１２６を開始すること、または、１２８で示すように、現在のストリーミング・データ・セッションを機器１４のＩＰアドレスへ再ルーティングすることのいずかによってこの要求に応答する。
【００４２】
図１０を参照すると、サーバとモバイル機器を含んでなるシステムは、ユーザ・プロファイル、アプリケーション・プロファイル及びドライビング・プロファイルに基づいて、アプリケーションに関係したデータ（ストリーミング・データなど）を機器が消費可能にするシステムの対応のしかたを決める、一揃いのプロファイルのセットを含むことができる。例えば、携帯電話などの個人が携行する機器で開始したセッションは、車両内のインフォテインメント・システムへ転送されたときには異なって表示されることがある。ユーザは今は車両を運転していて、ユーザが携帯電話を使っていたときとは異なる必要条件をもち得ることを表わして、ある種の機能が変更または抑制されることがあり得る。
【００４３】
図１１に示すように、アプリケーションのセッションが転送されるとき、インフォテインメント・アプリケーションの適切な動作のために必要なある種の属性を定義するアプリケーション・プロファイルがモバイル機器へダウンロードされ得る。この場合にはセッション継続マネージャとして機能する、セッション継続アプリケーションは、車載ユニットを携帯機器とペアにさせて、セッション転送を開始するために同期化トリガを行なう。これは、制御されるインフォテインメント・アプリケーションに適合するようにユーザ・インタフェースを適切なモードに変更するように求める命令を車載ユニット及び／または携帯機器に送信することを含み得る。
【００４４】
セッション継続アプリケーションまたはセッション継続マネージャは、必要に応じて、ユーザ・インタフェース（ヒューマン・ユーザ・インターフェースＨＭＩ）を適応させることを補助するために、アプリケーション選択とサービス選別または大別化を実行できる。大別化は、インフォテインメント・アプリケーションの機能を特徴付けることができる異なる次元を定義することを含む。セッション継続アプリケーションまたはセッション継続マネージャは、他のアプリケーションがインフォテインメント・アプリケーションに統合可能なように、インフォテインメント・アプリケーションによって実行される個々の機能を大別化されたグループにグループ分けする。例えば、電話番号を検索する基本的機能は、住所を検索する機能と統合可能であり、その結果得られた統合機能は、インフォテインメント・アプリケーションとのユーザの対話に基づいて所望の移動先位置を検索する上で車載ナビゲーション・システムを補助するために使用され得る。
【００４５】
図１２は、セッション転送フローがどのように実行され得るかをさらに詳しく示す。図１２は、第１のモバイル（携帯）機器からのインフォテインメント・アプリケーションが存在しない場合、同等のアプリケーションをどのように、いつロードまたはダウンロードするかをシステムがどのように決定するのかをさらに具体的に示す。アプリケーションの状態とその他のコンテクスト情報がどのように利用されるのかを示す、図１３と図１４が次に続く。いくつかの使用例が、次に、図１５〜図１７に示される。
【００４６】
ここまで１台の転送側機器に関してセッション転送を説明してきたが、上記の内容は複数の機器に当てはめることができるものとする。例えば、二人のユーザが車両に乗り込むとするならば、各ユーザがそれぞれのセッションを車両のインフォテインメント・システムに同期させることができる。以下に説明するとおり、ＨＭＩはユーザが複数のアプリケーションを用いて閲覧できるようにしているので、ＨＭＩは複数の機器からの複数のセッション転送に対応するように構成され得る。
【００４７】
本開示の別の態様では、アプリケーションのコンテクストすなわち実行状況（自動車、家、携帯等）ごとに対応するユーザ・インタフェースは、それ独自のユーザ・インタフェースをもつことができる。各コンテクストは、ユーザにとって最も利用しやすい異なるユーザ・インタフェース設定をもつ。テレビジョン設定では、例えば、リモコン装置によってアプリケーションを制御することにユーザはより慣れているであろう。航空機のコンテクストでは、タッチ・スクリーンによってアプリケーションを制御することにユーザはより慣れているであろう。
【００４８】
車両側のインタフェースは異なる入力及び出力機構によって特徴付けられるので、車両側のアプリケーションは携帯側の対応するアプリケーションと同じではないものとする。したがって、規定設定構成の一部として組み込めるセッション継続機能を提供するためには、車両側のアプリケーションは「車両にうまく合う」ものである必要がある。しかし、「車両にうまく合う」ようにされていないアプリケーションでも、携帯側の対応するアプリケーションのルック＆フィールでなおもアクセスすることは可能である。
【００４９】
アプリケーションのコンテクストごとに対応するＵＩ（ユーザ・インタフェース）に関する考慮は、ユーザが最も楽しめるものまたはユーザが慣れているものだけに依存するのではなく、新しいコンテクストの環境において安全であるもの及び／または法令で許され得るものにも依存し得る。したがって、特定のコンテクストごとに合わせて設計されたアプリケーションは、国、地方、設定、及びその他の考慮事項によってカスタマイズされ得る。
【００５０】
車両コンテクストでは、ユーザ・インタフェースは、ＨＭＩとのユーザの対話をより容易にするように、かつ車両が動いているときには注意散漫になりにくくするように構成される。例えば、いくつかの実施形態では、車両が動いているときのＵＩは、車両が動いていないときとは対照的な色コードで色分けされる。さらに、例えば、ホーム画面は青色でダウンロードしたアプリケーションは他の色にするなど、使用されているアプリケーションまたはシステムの状態に応じてＵＩは追加の色コードをもつことができる。ＵＩは自動車内の光センサーの出力に基づいてコントラストを調整できる、または画面の色が光センサーの出力に基づいて反転され得る。さらに、ＵＩは、車両が動いているときの音声入力コマンドと音声フィードバックを取り入れることができる。上記に列挙したＵＩの実現は例示的であり、限定するものと意図されていない。
【００５１】
図２に戻り参照すると、機器はまた、表示部４６、ＨＭＩ３６、及び入力モジュール３８を含むものとする。これらの三つの構成要素は、ユーザと機器１４との対話を実現するために連携して機能すると想定される。車両コンテクストでは、表示部４６は、インフォテインメント・システム１４の表示ユニットである。スクリーンは、タッチ・センサー式のスクリーンを含む、当技術分野で知られているどんなスクリーンでもよい。タッチ・スクリーンの実施形態では、表示部４６は入力モジュール３８としての役目もする。入力モジュール３８は、音声入力が可能にされるようにマイクロフォンと音声分析装置であってもよい。入力モジュール３８は、例えば、タッチ入力、音声入力、またはタイピング入力といったユーザ入力を受け付けて、ユーザ入力をＨＭＩ３６へ伝達される信号に変換する。受信した信号に基づいて、ＨＭＩは受け付けた入力をアプリケーション制御モジュール３４へのコマンドに変換する。
【００５２】
車両コンテクストでは、ＨＭＩは複数のソースから入力を受け付けるようにさらに構成される。いくつかの実施形態では、ＨＭＩは、上述したように入力を受け付けることに加えて、携帯機器などのペアの相手のユーザ機器から入力を受信するようにさらに構成され得る。このような実施形態では、ユーザは入力手段として携帯機器を使用する選択ができる。ＰＷＡＮを介して、例えば、携帯機器１２は入力信号を車両のインフォテインメント・システム１４へ送信できる。入力モジュール３８は、受信したコマンドを解読してそれをＨＭＩ３６へ伝達する。
【００５３】
このような実施形態では、携帯機器のタッチ・スクリーンはインフォテインメント・システムのタッチ・スクリーンに相当し得ると想定される。図５はこの概念を図示する。図には、携帯機器１２とインフォテインメント・システム１４が示される。参照番号６２と６４は、携帯機器に対する特定のジェスチャーが、インフォテインメント・システムの表示画面上でどのように行なわれるかを示す。図に示すように、上記を使用して、ユーザは携帯機器１２を無線入力装置として利用できる。このオプションは、ユーザがＨＭＩと対話する際に、より快適に注意散漫になりにくい状態で行なえるようにできる。ユーザをさらに支援するために、携帯機器１２の入力手段またはインフォテインメント・システム１４のＨＭＩは、ユーザがタッチパッド上に文字を描いているとき、それを認識するように構成され得る。文字を描くことによって、ＨＭＩは入力された文字で始まるアプリケーションのリストを読み出せる。例えば、ユーザが「ｐｈ」というモジュールを描いたとすれば、ＨＭＩは「ｐｈｏｎｅ」に関係したアプリケーションを読み出すことができる。
【００５４】
わかるとおり、アプリケーションの大部分がクラウド中でホストされ、ネットワーク１０を介してインフォテインメント・システム１４へ配信されてきた状態で、ユーザは同時に複数のアプリケーションを実行させることができる。一つ以上の機器から転送されたか、またはインフォテインメント・システム自体によって起動された複数のアプリケーションを円滑にするために、ＨＭＩは個々のアプリケーションを及びアプリケーション・メニュー内を容易に見進めるように構成され得る。図６は、直線的なカルーセルとして構成された例示的なユーザ・インタフェースを示す。図に示すように、ユーザはアプリケーションを切り替えるために横に見進むことができ、アプリケーション・メニュー内を水平方向に見進むことができる。上記は例示的な目的で示されており、ユーザ・インタフェースの多くの異なる構成が考えられるものとする。
【００５５】
前述したとおり、ＨＭＩ３６は、車両コンテクストにおいてドライバにとっての注意散漫の量を減少させるようにさらに構成され得る。例えば、ドライバのインフォテインメント・システム１４のＵＩとの対話は、法令や条例の順守を強制するために自動車が動いている間はできないようにされ得る。これは、携帯機器１２を車載システムのコントローラとして使用する機会を提供する。ＵＩとの利用可能な対話は、ドライビング・モードに基づいて制限可能である。例えば、図７に示すように、車両が動いているときはクリック可能なボタンはＵＩから取り除かれる。右側の画面７６では、自動車が走行しているときには、自動車コンテクストのアプリケーション中で実在のボタンは消えている。この実施形態では、ユーザが画面を見なくてすみ、小さいまたは特定のアイコンを押そうとしなくてもよいように、ジェスチャー入力のみが許される。ドライバの注意散漫を回避するために、他の安全特性も車両のインフォテインメント・システムに組み込めることが想定される。
【００５６】
上述のアーキテクチャに関しては、アプリケーション・サーバが機器にアプリケーションを配信するような一般的なサーバ‐クライアント・モデルを説明した。しかし、その他のアーキテクチャも実現され得ると想定される。例えば、アプリケーションは携帯機器１２でホストされてもよい。セッション転送時に、携帯機器１２がインフォテインメント・システム１４へアプリケーションを供給する。このようなアーキテクチャでは、携帯機器１２は、インフォテインメント・システムのＨＭＩのコンフィギュレーション、コンテクスト分析を実行するためのデータ、及びサービス適応のための方法を含む、セッション転送に必要な情報を記憶しておくことができる。
【００５７】
他のアーキテクチャでは、インフォテインメント・システムのＨＭＩは、携帯機器１２から実行され得る。このような例では、アプリケーションのただ１つのコピーが存在すればよいという点で、アプリケーションは単一と見なすことができ、インフォテインメント・システムのＨＭＩはブラウザとして動作できる。このコンフィギュレーションを使用すると、アプリケーションのユーザ・インタフェースは、インフォテインメント・システムに対して、携帯機器またはアプリケーション・サーバからプッシュされる。
【００５８】
本文書で使用されるモジュールという用語は、一つ以上のソフトウェアまたはファームウェア・プログラムを実行する特定用途向け集積回路（ＡＳＩＣ）、電子回路、プロセッサ（共有、個別、またはグループ）及び／またはメモリー（共有、個別、またはグループ）、組み合わせ論理回路、及び／または説明した機能性を提供するその他の適当な構成要素を指していることもあるし、その一部であることもあるし、または含むこともある。さらに、本文書で説明した構成要素は、該当する機器に付属するプロセッサ上で実行可能なコンピュータにより読取り可能な命令として具現され得るものとする。
【００５９】
実施形態の上記の記述は、実例を示して説明する目的で記載されたものである。包括的なものまたは本発明を限定するものと意図されていない。特定の実施形態の個々の要素または機能は、概して、その特定の実施形態に限定されず、特に図示または言及されていなくても、適切な場合には、互いに置き換え可能であり、選択された実施形態において使用可能である。同一のものが、さまざまに変形されることもあり得る。このような変形は、本発明からの逸脱と見なされてはならず、すべてのこうした変形は本発明の範囲内に含まれるものと意図される。
【技術分野】
【０００１】
本開示は、２台以上の機器間でのアプリケーションのセッション継続性をユーザに提供するためのシステム及び方法に関係する。
【背景技術】
【０００２】
携帯機器がますます普及するにつれて、携帯機器で利用されるアプリケーションも増えている。例えば、携帯機器は、インターネット・ラジオ、ソーシャル・ネットワーキング、ビデオ・ストリーミング、ウェブ閲覧、及びゲーム用のアプリケーションをユーザに提供する。これらのアプリケーションをホストするための処理能力を有する携帯機器もいくつかあるが、アプリケーション・サーバでこれらのアプリケーションをホストし、アプリケーションをネットワークを介して配信する傾向が高まっている。この枠組みは、クラウド・コンピューティングと呼ばれることもある。
【０００３】
現在、ネットワーキング機能は、車両に搭載するという状況でもより実現可能になってきている。専用の移動ネットワーキング・カードを通じてまたは携帯機器を介して、車載インフォテインメント・システムが、ネットワーキング機能をもち始めてもいる。それに応じて、携帯機器に搭載されているアプリケーションと同様に、車載インフォテインメント・システム特有のアプリケーションを提供する傾向が高まっている。携帯機器での利用という状況に対応したアプリケーション・ストアの枠組みと同様に、ユーザは、自分の車載インフォテインメント・システムに合ったアプリケーションを購入できるようになるだろう。さらに、インフォテインメント・システムの製造者は、広範囲にわたる購入可能なアプリケーションをユーザに提供するために、サードパーティにＳＤＫ（ソフトウェア開発キット）を提供することになろう。これらのアプリケーションのホスティングは、クラウド中で維持することにもなりそうだ。これらのアプリケーションは、ヒューマン・マシン・インターフェース（ＨＭＩ）を使用して制御可能である。
【発明の概要】
【０００４】
上記の傾向の現実化に伴って、ユーザ機器と車載インフォテインメント・システムとの間の継続性への要望が高まっている。
【０００５】
上記の節では、必ずしも従来技術ではない、本開示に関連した背景情報を記載している。
【０００６】
図面のうちのいくつかの図中で、同じ参照番号は同じ要素を示す。ここに記述する図面は、すべての可能な実現ではなく、選ばれた実施形態だけを説明するためのものであり、本開示の範囲を限定するものと意図されていない。
【図面の簡単な説明】
【０００７】
【図１】２台の機器とアプリケーション・サーバの関係を示す図である。
【図２】アプリケーションのセッション継続性を達成するために実行可能な例示的な方法である。
【図３】アプリケーションのセッション継続を実行するように構成された機器の例示的な構成要素を示すブロック図である。
【図４Ａ】第２の機器が通信ネットワークへの接続性を有する場合におけるデータ転送を示す図である。
【図４Ｂ】第２の機器が通信ネットワークへの接続性を有しない場合におけるデータ転送を示す図である。
【図５】第２の機器への入力装置として使用されている携帯機器の例を示す図である。
【図６】例示的なユーザ・インタフェースを示す図である。
【図７】車両のインフォテインメント・システムへ転送後のアプリケーションの例示的なユーザ・インタフェースを示す図である。
【図８】インフォテインメント・アプリケーション、セッション継続アプリケーション及びサーバ間の通信を示すハードウェア図である。
【図９】セッションの転送を実施するための各機器とサーバ間の通信を示すシーケンス図である。
【図１０】セッション転送動作を理解するのに役立つシステム図である。
【図１１】セッション転送動作を理解するのに役立つセッション転送フロー図である。
【図１２】さらに詳しいセッション転送フロー図である。
【図１３】セッション継続エージェントのフロー図である。
【図１４】車両ベースの実施形態におけるドライビング・コンテクストを理解するのに役立つプロセス図である。
【図１５】本文書に記述したシステムと方法を使用して実施され得る非限定的な例としてのシナリオを示す。
【図１６】本文書に記述したシステムと方法を使用して実施され得る非限定的な例としてのシナリオを示す。
【図１７】本文書に記述したシステムと方法を使用して実施され得る非限定的な例としてのシナリオを示す。
【発明を実施するための形態】
【０００８】
添付の図面を参照して、例としての実施形態をより詳細に説明する。
【０００９】
アプリケーションのセッション継続性に対応するシステム及び方法をここに開示する。アプリケーションのセッション継続性は、携帯機器のアプリケーション環境と車載インフォテインメント・システムのアプリケーション環境との間でシームレスな移行をユーザに提供する。本文脈で使用されるアプリケーションは、特定の機器向けに設計さているソフトウェア・プログラムである。アプリケーションのセッションは、アプリケーションが再起動される度に新たなセッションが開始するようになっているアプリケーションの特定のインスタンス（状態）である。したがって、アプリケーションのセッション継続性は、複数の機器間でアプリケーションのセッションを維持することであると考えることができる。例えば、ユーザが自分の車両に乗車するときに、アプリケーション・サーバでホストされたインターネット・ラジオ・アプリケーションを利用して、ユーザは携帯機器に音楽をストリーミングしている最中である可能性がある。開示された構成を利用すれば、ユーザのセッションはインフォテインメント・システムに転送され得る。当該アプリケーション・サーバ、すなわち通信相手のアプリケーション・サーバは、続いて、オンライン・ラジオ・コンテンツを車両のインフォテインメント・システムへストリーミングする。これは、自動的に、またはほんの少しだけユーザの手を借りて、遂行され得るものとされる。アプリケーションのセッション継続性は、例えば、ユーザが車両に乗車したときに聴いていた同じトラックの同じ位置からアプリケーション・サーバがサービスをインフォテインメント・システムへ転送可能にする。他の例では、アプリケーションのセッション継続性は、前のアプリケーションからのデータを使用して、新しいアプリケーションを開始することによって実現され得る。
【００１０】
図１は、アプリケーションのセッション継続性を実現する例示的な機器を示す図である。この図には、携帯機器１２と車両によって表わされた車両のインフォテインメント・システム１４の２台の機器が示される。２台の機器は、相互間の通信機能をもっているとされる。例えば、携帯機器１２と車両のインフォテインメント・システム１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）などのＷＰＡＮを介して、ＷｉＦｉを介して、またはＵＳＢコードなどのケーブル接続を介して相互に通信できる。両機器１２と機器１４は、通信ネットワーク１０を介してアプリケーション・サーバ１６と通信できる。これらの機器は、複数のアプリケーション・サーバと通信するように構成されるものとされる。
【００１１】
上記の構成を使用して、アプリケーション・サーバ１６は、第１のアプリケーションを携帯機器１２へ、第２のアプリケーションをインフォテインメント・システム１４へ配信できる。携帯機器１２とインフォテインメント・システム１４のオペレーティング・システムは、顕著に異なるプラットフォーム向けに設計され得る。そのため、携帯機器１２で実行するように設計されたアプリケーションは、インフォテインメント・システム１４では実行できない。逆も同様である。それに応じて、アプリケーション・サーバ１６は、実質的に同様の機能を実現するたように、あるアプリケーションの修正バージョンを通信相手の各機器１２と機器１４に配信できる。
【００１２】
図２は、アプリケーションのセッション継続性を達成するための例示的な方法を示す。最初に、ステップ２０２に示すように、ユーザはセッション転送を起動する。これは、認識された携帯機器１２をインフォテインメント・システム１４の通信範囲内に持ち込むことによって自動的に、または何らかのユーザ入力によって、実行可能である。後者の場合、携帯機器を車両上の所定の箇所に触れさせるなどの、または機器のタッチ・スクリーンまたはＨＭＩに触れて所定のジェスチャーを行なうことによって、接触ジェスチャーをユーザは行なえる。接触ジェスチャーの例は、ユーザがインフォテインメント・システム１４に付属した接触感知可能な領域内に携帯機器１２を軽く打ち当てることである。本質的には、各機器内の信号が、ユーザがセッションを転送したいことをシステムに知らせる。
【００１３】
ユーザがセッション転送を起動したら、ステップ２０２に示すように、２台の機器は互いにペアをなすことになる。機器どうしをペアにすることは、２台の機器に相互通信を確立するように要求することになり得る。互いに通信が確立したら、各機器１２と機器１４は、利用可能なアプリケーションなどの情報を交換可能になる。一揃いの対応するアプリケーションのセットが各機器１２と機器１４に存在する場合には、例えば、両機器が特定のインターネット・ラジオ・サービス向けのアプリケーションをもっている場合には、ステップ２０４で、転送可能なアプリケーションのリストが生成され、ユーザに表示され得る。ユーザはセッションを転送するための所望のアプリケーションを選択できる、またはこれは自動的に実行され得る。後者の場合、自動的に転送可能なアプリケーションの所定のリストをどちらか一方の機器がもち得るか、または、「ユーザが携帯機器で地図アプリケーションを実行中である場合には、ＨＭＩ上で自動的にナビゲーション・アプリケーションを開く」または「ユーザがラジオ・アプリケーションをストリーミング中であり、車両のラジオがＯＮである場合には、ラジオ・アプリケーションのセッションを転送する」といった所定の規則が、どのアプリケーションを自動的に転送するのかを決定し得る。このような規則は、どちらか一方の機器のコンピュータで読取り可能な媒体に記憶され得るものとする。さらに、後述するように、第２の機器１４に特定のアプリケーションがないときは、当該機器１４にそのアプリケーションをダウンロードさせることができる、またはユーザにそのアプリケーションをダウンロードするように指示できる。転送する特定のセッションが指定されたら、各機器１２と機器１４の一方または両方は、ステップ２０６に示すように、アプリケーション・サーバ１６に対してセッション転送要求を起動できる。
【００１４】
アプリケーション・サーバ１６は、当該要求といずれかの追加のセッション・データ、すなわち、アプリケーションに関連した情報やセッションに固有の情報などの、当該要求を実施するために必要な転送対象の進行中のセッションに関するデータを受信する。例えば、あるアプリケーションを対象とする要求が、アプリケーション・サーバ１６に送信されることがあると、セッション識別番号とそのアプリケーションのセッションの現在の状態などの、そのアプリケーションのセッションに関するパラメータが当該要求に含まれる。アプリケーションによって異なるセッション・データの例は、カレンダー・アプリケーションではユーザが見ている特定のカレンダー項目、音楽ストリーミング・アプリケーションではトラック番号、トラック位置及びプレイリスト、または映画検索アプリケーションでは選択された映画及び映画館を含む。
【００１５】
アプリケーション・サーバ１６は当該要求を受信すると、アプリケーション・サーバ１６は、次に、ステップ２０８で示すように、携帯機器１２で実行していたセッションを再作成するために、受信したセッション・データを使用して、インフォテインメント・システム１４に対して新しいアプリケーションのセッションを開始する。このセッションは、新しく再作成されたセッションがそれ以前のセッションが転送された時点から開始するようにするセッション・データを使用して再作成される。例えば、ビデオ・ストリーム・セッションが第２の機器１４で起動され得るとき、セッション転送時に第１の機器１２で表示されていたフレームと同じフレームから開始できる。両方の機器向けの同一のアプリケーションが実行可能である場合には、携帯機器１２の代わりに転送先の機器のＩＰアドレスへデータをルーティングすることによって、サービスを再作成する必要はなくサービスを単に転送先の機器１４へ移動するだけでよいものとする。アプリケーション・サーバ１６は、次に、ステップ２０８で示すように、インフォテインメント・システム１４に当該アプリケーションを配信する。アプリケーション・サーバ１６は携帯機器１２へのサービスを継続することも、携帯機器１２へのサービスを中断することも、または携帯機器１２のセッションを完全に終了することもできるものとする。
【００１６】
上記を実行することによって、異なるコンテクスト間で、サービスのいかなる中断もなしにまたは中断を最小限にとどめて、例えば、同じ設定、同じユーザ名、同じメディア選択といったユーザのセッションの一つ以上のものが維持される。アプリケーションのコンテクストは、そのアプリケーションが使用されている設定／プラットフォームである。例えば、異なるコンテクストは、自動車設定、携帯機器、パーソナル・コンピュータ、ラップトップ、航空機、オートバイ、テレビジョン、各種の家庭用電子機器等を含み得る。上記の構成は、上にリストしたコンテクストどうしに適用可能であり、これらは本開示の範囲内に入ると見なされることが想定される。けれども、説明上の目的で、大部分の説明は携帯機器と車両のインフォテインメント・システムの間のセッション継続性を維持することについて記載されている。開示内容は、広範囲にわたるコンテクストに適用可能であると解釈される。例えば、あるユーザは、航空機に搭乗し、携帯機器１２を所持している。携帯機器は、ビデオ・ストリーミング・アプリケーションをユーザの座席のパーソナル・インフォテインメント・システムへ転送できる。同様に、ユーザが帰宅して彼女の車を車庫に駐車すると、セッションは車両のインフォテインメント・システム上で実行中のアプリケーションをユーザのパーソナル・コンピュータへ転送できる。
【００１７】
図３は、アプリケーションのセッション転送を実行するように構成された機器１４の構成要素を示す。構成要素は、自機器１４と他機器、例えば、携帯機器１２との間の通信を可能にする第１の通信モジュール３２を含む。第１の通信モジュール３２は、例えば、ＷｉＦｉまたはＷｉＭａｘ送受信器であり得る。第１の通信モジュール３２は、アプリケーション・サーバ１６からのアプリケーション・データをアプリケーション制御モジュール３４へ伝達する。いくつかの実施形態では、機器１４はＷｉＦｉまたはＷｉＭａｘ機能をもたないことがあり得る、すなわち、機器１４はインターネットに接続できないことがあり得る。これらの例では、第１の通信機器１４は携帯機器１２にテザリングで連結することが可能であり、携帯機器１２をモバイル・ルータとして使用できる。
【００１８】
アプリケーション制御モジュール３４は、各種のアプリケーションのセッションを制御する。例えば、アプリケーション制御モジュール３４は、ユーザが選択したアプリケーションのうちフォアグランドで実行するのはどのアプリケーションで、バックグランドで実行するのはどのアプリケーションかを決定できる。さらに、アプリケーション制御モジュール３４は、アプリケーション・サーバからデータを受信し、受信したデータに基づいて必要な何らかの変更をＨＭＩ３６へ伝達する。逆に、ＨＭＩ３６へ入力された何らかのユーザ入力は、アプリケーション制御モジュール３４によって受信され、アプリケーション・サーバへ送信される。さらに、アプリケーション制御モジュール３４は、各種のアプリケーションのセッションの状態を維持するために、データ格納部４８と通信する。例えば、アプリケーション制御モジュール３４は、第１の通信モジュール３２を介してアプリケーション・サーバ１６へ送信するユーザのユーザ名とパスワードを受信し得る。加えて、アプリケーション制御モジュール３４は、特定のアプリケーションへアクセス時に、アプリケーションの状態及び／またはユーザの設定を示す各種パラメータをデータ格納部へ格納することができる。アプリケーション制御モジュール３４はまた、アプリケーション市場へアクセスするように構成される。例えば、車両コンテクストでは、インフォテインメント・システムの提供者は、アプリケーション特有のルック＆フィール（画面の見た目と操作感）がその特定のインフォテインメント・システムに合うように実現可能なように、ＳＤＫを開発者に提供できる。第１の通信モジュール３２を介して、アプリケーション制御モジュール３４は、そのインフォテインメント・システム上での所望のアプリケーションをダウンロードできる。処理の大部分はクラウド中で実行されるが、それでもアプリケーションはあるソフトウェアが機器自体にインストールされるように要求することがあり得るものとする。アプリケーション制御モジュールは、機器１４のＨＭＩ３６、第２の通信装置４２、及びペア化モジュール４４とさらに通信するように構成される。
【００１９】
第２の通信モジュール４２は、自機器１４と他機器、例えば、携帯機器１２との間の、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）またはＺｉｇｂｅｅ（登録商標）といったパーソナル・エリア・ネットワークを介した通信を可能にする。他の実施形態では、ＷｉＦｉ接続などの他の通信手段も利用可能であることが想定される。第２の通信モジュール４２は、自機の近辺内の、例えば、５メートル以内にある他の通信可能な機器を感知するように構成され得る。第２の通信モジュール４２がこのような機器を感知する範囲内で、本モジュールは他の機器の通信モジュールとの通信を開始できる。他の機器は、通信を始める通信相手として自機器１４に登録されなければならない、または認めらなければならないことがあり得るものとする。この機能性は、機器発見及び同期化モジュール４０によって実行可能であると想定される。
【００２０】
機器発見及び同期化モジュール４０は、自動車内に存在する携帯機器を識別するように構成され、その携帯機器１２にセッション転送を勧めることができる。代替的に、その携帯機器が、機器発見及び同期化モジュール４０に対してセッション転送を勧めることができる。機器どうしがセッション転送に同意するとただちに、機器発見及び同期化モジュール４０は、他の機器上で実行中のアクティブなアプリケーションのリストを受信できる。ただし、この受信が起こり得る前に、２台の機器は互いにペアとなる。これはペア化モジュール４４によって実行可能である。
【００２１】
ペア化モジュール４４は、安全なやり方で自機器１４と他機器１２をペアにするように構成される。自動的に実行される場合、第２の通信モジュール４２は近隣内で信号をブロードキャストしているいずれかの機器から信号を受信する。ブロードキャスト信号は、送信機器の識別を示すインジケータを含む。ペア化モジュール４４は、この信号を受信し、その機器識別子を自機器１４のメモリーに記憶された機器識別子のリストと照合し得る。その機器が識別されれば、ペア化モジュール４４は２台の機器１２と機器１４間の通信を確立する。ペア化は自動的に実行可能であるが、ペア化モジュール４４は、ユーザ側の接触ジェスチャーに応じてペア化を実行するように構成され得る。このような構成では、ペア化モジュール４４は、ユーザのセンサー入力を確定したときにペアが要求されていることを決定する。例えば、ペア化の要求は、ユーザに機器１４の表示部のスクリーンを携帯機器１２で軽く叩かせることによって起動され得る。携帯機器１２は、機器１２に付属した加速度計が機器の突然の加速とその後の急減速を感知すると、接触行為によるサービスの転送要求を認識できる。機器１４は、表示部のタッチ・スクリーンが携帯機器１２によって触れられると、接触行為による要求を認識できる。所定のジェスチャーが両方の機器によって認識されると、機器１２と機器１４は、所定のジェスチャーをペア化の要求として受け止める。上記はペア化の例であり、機器どうしをペア化するためのその他の手段が存在すると想定される。機器どうしをペア化するより受動的な手段が存在すると想定されるが、接触行為はセッション転送を行なうよう指示する明示的な要求を示す物理的行為に相当するから、接触行為はユーザにとって便利であり得る。さらに、ペア化を指示する接触による要求は、機器１４が複数のユーザとペアを組めるようにできる。
【００２２】
機器どうしがペア化されるとただちに、機器発見及び同期化モジュール４０は、アプリケーションの同期化を実行できる。機器１４上の機器発見及び同期化モジュール４０は、ペアの相手の機器上のアクティブなアプリケーションのリストを受信できる。機器発見及び同期化モジュール４０は、次に、アプリケーション制御モジュール３４に問い合わせることによって自機器１４上の対応する非アクティブなアプリケーションを決定できる。ユーザ入力または所定のユーザ設定または規則によって、機器発見及び同期化モジュール４０はどのアプリケーションを同期させるのかを決定する。
【００２３】
あるアプリケーションが機器へダウンロードされていなかった場合には、機器発見及び同期化モジュール４０は、アプリケーション制御モジュール３４からそのアプリケーションがダウンロードされるように要求するように構成され得る。
【００２４】
アプリケーションのセッションが転送されるように設定されるとただちに、セッションの継続性を確保するために、アクティブなアプリケーションのコンテクストからセッション・データが非アクティブなコンテクストへ送信される。例えば、ユーザが車両へ乗り込む例では、ユーザの携帯機器１２が、携帯機器１２上で実行中のアクティブなアプリケーションの一つ以上についてのセッション・データを機器１４の第２の通信モジュールへ転送する。セッション・データは、アプリケーションＩＤ、セッションＩＤ、及びその特定のアプリケーションとセッションに関係し得る何らかデータ、例えば、ラジオ・アプリケーションの場合にはトラック番号と位置を含み得る。言及したとおり、アクティブなサービスまたはアプリケーションのリストが確定され、各アプリケーションのセッションの現在の状態がさらに確定される。例えば、ユーザがインターネット・ラジオ・アプリケーションからストリーミングされた音楽を聴いている場合には、現在のトラック、そのトラックの位置及びプレイリストが、携帯機器１２から機器１４へ第２の通信装置４２を介して転送される。いくつかの実施形態では、例えば、非アクティブなアプリケーションのデータといった、非アクティブなセッション・データも送信され得ると想定される。これは、機器どうしが完全な同期を行なうように構成される場合に実行され得る。同期化は、例えば、ＰＷＡＮを通じてまたはネットワーク１０を通じて、各機器の第２の通信モジュールを介して実行可能であると想定される。
【００２５】
機器発見及び同期化モジュール４０は、セッション転送を補助するために、ペアの相手の機器へ情報を送信するようにさらに構成され得る。例えば、機器１４が割り当てられたＩＰアドレスをもつ場合には、この情報がペアの相手の機器へ送信され得る。このような情報は、アプリケーション・サーバ１６が機器１４へ要求されたアプリケーションを配信できるように、アプリケーション・サーバ１６へ送信可能であるものとする。
【００２６】
セッション情報が同期されたら、アプリケーション・サーバ１６からのサービスを要求することによって、アプリケーション制御モジュール３４は、セッション転送を起動できる。代替的に、ペアの相手の機器が、セッションを機器１４へ転送するように、アプリケーション・サーバ１６へ要求を送信できる。アプリケーション・サーバ１６がセッション転送要求を受信するとただちに、アプリケーション・サーバ１６は機器１４への当該アプリケーションの配信を開始できる。アプリケーション・サーバ１６は、配信先の機器のアプリケーション制御モジュール３４からデータを受信する。当該アプリケーションに基づいて、受信したデータは入力として扱われ、アプリケーション・サーバ１６は受信したデータを使用してアプリケーションを実行する。当該アプリケーションの状態の何らかの変化が、ネットワーク１０を介して、アプリケーション・サーバ１６によって機器１４へ送信される。アプリケーション制御モジュール３４は、アプリケーション・サーバから受信した情報、すなわち、当該アプリケーションの状態の変化に基づいてＨＭＩを更新する。
【００２７】
ユーザ選択またはそのアプリケーション自体に基づいて、アプリケーション・サーバ１６はペアの相手の機器へのサービスを停止できるか、またはペアの相手の機器への配信を継続できるもとする。
【００２８】
セッションが機器１４へ転送されたら、アプリケーション制御モジュール３４は、ユーザ設定を読み出すためにデータ格納部４８へアクセスできる。さらに、アプリケーション制御モジュール３４は、特定のアプリケーションの特定の状況における実行を許可しないように構成され得る。例えば、車両設定においては、ユーザは、運転中に電子メールを続けることをアプリケーション制御モジュール３４によって禁止され得る。ある活動を禁止する決定は、ドライバにとって安全だとみなされることに、または国、地域、州、または市の統制法令に基づくものであり得る。しかし、ユーザが帰宅した時点で、電子メールを完了するようにユーザに指示するようにしてもよいし、または別のセッション転送が電子メールのアプリケーションのセッションをユーザの自宅のコンピュータへ転送してもよい。
【００２９】
第２の機器、例えば、車両のインフォテインメント・システムへのアプリケーションのセッション・サービスは、いつかの方法で実施可能であると想定される。図４Ａと図４Ｂは、アプリケーションを配信するための二つの代替的な手段を示す。図４Ａでは、アプリケーション・サーバ１６は、携帯用アプリケーション１８をネットワーク１０を介して携帯機器１２へ配信する。アプリケーション・サーバ１６はまた、車両用アプリケーション２０をネットワーク１０を介して車両のインフォテインメント・システム１４へ配信する。図４Ｂでは、車両のインフォテインメント・システム１４は、ネットワーク１０への直接の接続をもたないと仮定される。この例では、車両のインフォテインメント・システム１４は、前述したように、携帯機器１２にテザリングで連結できる。アプリケーション・サーバは、次に、携帯機器１２を仲介的な中継機として利用して、車両用アプリケーション２０を車両のインフォテインメント・システム１４へ配信する。
【００３０】
さらに、上述のアプリケーション転送は、アプリケーション・サーバ１６が実質的に同様のアプリケーションを配信することを前提としたが、関連したアプリケーションの転送を選択するように機器は構成され得る。例えば、ユーザが携帯機器１２上で第１のアプリケーションを実行している場合、例えば、レストランお勧めアプリケーションからのレストランまたはカレンダーから予約を選択したとすると、機器１４は、同期化中に、携帯機器からのセッション・データを使用して、ナビゲーション・アプリケーションのセッションを起動するように要求できる。ユーザが携帯機器１２上でレストランを選択したとすれば、インフォテインメント・システム１４は、セッションデータとして受信した、選択したレストランの住所を使用してナビゲーション・アプリケーションを起動できる。アプリケーション制御モジュール３０は、同期化中に受信したセッション・データの分析に基づいて、このようなインテリジェントな推定を実行するように構成され得る。
【００３１】
様々な異なる実施形態が可能であるが、図８と図９は、一つ以上のインフォテインメント・アプリケーションと共に機器上で実行するセッション継続アプリケーションによって、セッション継続が行なわれる例示的な実施形態を示す。追って説明するが、セッション継続アプリケーションは、インフォテインメント・アプリケーションにはそれらが本来処理するように設計されたインフォテインメント・タスクを自由に処理させながら、機器間のセッション制御と転送を調停する。
【００３２】
図８を参照すると、モバイル機器（この場合には、携帯機器１２とインフォテインメント・システム１４の両方がモバイル機器であると見なされる）は、メモリー装置１０２がそれに接続される機器ＣＰＵまたはプロセッサ１００を含む。メモリー装置１０２は、プロセッサにより読取り可能な命令と、プロセッサが記憶された命令を実行時に処理対象とするデータを記憶するように構成される。メモリー装置１０２は、したがって、コンピュータが読取り可能な命令とデータの非一時的記憶機構を提供する。
【００３３】
より具体的には、メモリー装置１０２は、プロセッサ１００によって選択的に実行され得る一つ以上のアプリケーション・プログラムをサポートすることを含む、プロセッサ１００によって実行される基本的な通信及びメモリ・アクセスを提供するオペレーティング・システム命令のセットを記憶するように構成される。この点に関し、メモリー１０２は、セッション継続アプリケーションと図示したインフォテインメント・アプリケーション１０８などの一つ以上のインフォテインメント・アプリケーションをその内部に記憶したものである。機器は、インフォテインメント・データ１１０を得るために、並びにあるセッション制御データ１１２を交換するためにサーバ１６と通信するように適合される。インフォテインメント・データは、例えば、消費されることになるストリーミング・データまたはその他のコンテンツを含み得る。必要に応じて、インフォテインメント・データは、インフォテインメント・アプリケーション１０８の実行可能なコピーなど、機器にロードして実行するための実行可能なアプリケーション・プログラム命令も含み得る。
【００３４】
セッション継続アプリケーション１０６は、一つの機器から別の機器へのアプリケーションのセッションの転送を調停するために、図９に関連してより詳しく説明するとおり、サーバ１６と通信する。この転送プロセスの一部として、セッション継続アプリケーションは、他の機器から得たセッション・データ１１４をインフォテインメント・アプリケーション１０８によって利用されるようにロードさせることによって支援する。したがって、図示のとおり、セッション・データ１１４は、セッション継続アプリケーション１０６からインフォテインメント・アプリケーション１０８へ渡されるように示される。点線で示されるように、セッション・データのこの転送は、オペレーティング・システム１０４の助けを受けて処理され得る。
【００３５】
セッション継続アプリケーション１０６は、インフォテインメント・アプリケーション１０８と同じようにロードされ、管理される単独のアプリケーションとして図８では示したが、当然のことながら、継続アプリケーション１０６はオペレーティング・システムによって管理されたある層などの異なる層で実現されてもよいものとする。このことは、図１１に示されており、セッション継続アプリケーションが、オペレーティング・システムのレンダリング層とインフォテインメント・アプリケーションなどのインストールされたアプリケーションの間に介在するセッション継続マネージャとして示される。
【００３６】
図９を参照すると、アプリケーションのセッション転送を実施するためのサーバと携帯機器１２と機器１４の間の交信は、各携帯機器１２と機器１４のセッション継続アプリケーション１０６Ａ、１０６Ｂの間の交信を含む。この場合もまた、携帯機器１２とインフォテインメント・システム１４の両方がモバイル機器であると見なされる。機器１２は、例えば、携帯型のモバイル機器であり、機器１４は移動車両のダッシュボードに取り付けられたインフォテインメント・システムであるとしてよい。
【００３７】
図９は、インフォテインメント・データ（この場合にはストリーミング・データ）とセッション制御データ（メッセージ）が、サーバとモバイル機器の個々の構成要素間でどのように受け渡されるのかを示す。１２０で先ず、サーバ１６はモバイル機器１２のインフォテインメント・アプリケーション１０８Ａへストリーミング・データを送信することが示される。もちろん、送信されるデータはストリーミング・データ以外の形式であってもよく、ここでストリーミング・データを図に示したのは、単に説明上の目的のためである。
【００３８】
さて、モバイル機器１２のユーザは、インフォテインメント・アプリケーション１０８Ａを介してストリーミング・データを楽しみながら、モバイル機器１４の近くにやってきたとしよう。例えば、携帯型のモバイル機器１２のユーザは、自分の自動車に乗り込んで、点火装置をオンにすると、モバイル機器１４がオンになり、機器１２と機器１４の間でペア化シーケンス１２２が開始される。ペア化１２２は、自動的にまたはユーザの指示によって開始され得るが、これはユーザ選択及び／または各機器のその他の制約による。
【００３９】
ペア化シーケンス１２２の一部として、セッションの転送を受信するために機器１４上で必要になるインフォテインメント・アプリケーションが何であるかを決定するために、セッション継続アプリケーション１０６Ｂはその相手であるセッション継続アプリケーション１０６Ａと通信する。必要なインフォテインメント・アプリケーションが機器１４の機器メモリー１０２内にすでに記憶されている場合は、セッション継続アプリケーション１０６Ｂは、そのインフォテインメント・アプリケーションがすでに実行していなければ、そのインフォテインメント・アプリケーションを起動するように、関連のオペレーティング・システム１０４を通じてメッセージを送信する。必要なインフォテインメント・アプリケーションが機器１４の機器メモリー内に記憶されてない場合は、セッション継続アプリケーション１０６Ｂは、１２４で示すように、ダウンロード要求をサーバ１６へ送信すると、サーバ１６は要求されたアプリケーション・プログラムを機器１４へ送信することによって応答し、機器１４のオペレーティング・システムは要求されたアプリケーション・プログラムをインストールして起動する。
【００４０】
これで今は、両方の機器１２と機器１４が適切なインフォテインメント・アプリケーションを実行させているので、セッション継続アプリケーション１０６Ａと１０６Ｂは、インフォテインメント・アプリケーション１０８Ａからインフォテインメント・アプリケーション１０８Ｂへセッション・データを転送するために協働する。図示されるように、この転送は、セッション・データ１１４として各セッション継続アプリケーションを経由して渡され得る（図８のセッションで・データ１１４も参照）。
【００４１】
次に、セッション継続アプリケーション１０６Ａ（または選択的にまたは追加的に、セッション継続アプリケーション１０６Ｂ）は、セッション制御データ１１２として、セッション転送要求メッセージをサーバに送信する（図８のセッション制御データ１１２も参照）。セッション制御データ１１２は、ユーザが現在楽しんでいるデータの特定の部分が何であるかを知るために、サーバが必要とするいずれかの適用可能なメタデータまたはセッション制御データを含み得る。例えば、ストリーミング・データが録音された必需物である場合は、セッション制御データは、曲ＩＤ、トラック番号、トラック位置カウンタ及びその他のプレイリスト情報等のメタデータを含むことになる。サーバは、新しいストリーミング・データ・セッション１２６を開始すること、または、１２８で示すように、現在のストリーミング・データ・セッションを機器１４のＩＰアドレスへ再ルーティングすることのいずかによってこの要求に応答する。
【００４２】
図１０を参照すると、サーバとモバイル機器を含んでなるシステムは、ユーザ・プロファイル、アプリケーション・プロファイル及びドライビング・プロファイルに基づいて、アプリケーションに関係したデータ（ストリーミング・データなど）を機器が消費可能にするシステムの対応のしかたを決める、一揃いのプロファイルのセットを含むことができる。例えば、携帯電話などの個人が携行する機器で開始したセッションは、車両内のインフォテインメント・システムへ転送されたときには異なって表示されることがある。ユーザは今は車両を運転していて、ユーザが携帯電話を使っていたときとは異なる必要条件をもち得ることを表わして、ある種の機能が変更または抑制されることがあり得る。
【００４３】
図１１に示すように、アプリケーションのセッションが転送されるとき、インフォテインメント・アプリケーションの適切な動作のために必要なある種の属性を定義するアプリケーション・プロファイルがモバイル機器へダウンロードされ得る。この場合にはセッション継続マネージャとして機能する、セッション継続アプリケーションは、車載ユニットを携帯機器とペアにさせて、セッション転送を開始するために同期化トリガを行なう。これは、制御されるインフォテインメント・アプリケーションに適合するようにユーザ・インタフェースを適切なモードに変更するように求める命令を車載ユニット及び／または携帯機器に送信することを含み得る。
【００４４】
セッション継続アプリケーションまたはセッション継続マネージャは、必要に応じて、ユーザ・インタフェース（ヒューマン・ユーザ・インターフェースＨＭＩ）を適応させることを補助するために、アプリケーション選択とサービス選別または大別化を実行できる。大別化は、インフォテインメント・アプリケーションの機能を特徴付けることができる異なる次元を定義することを含む。セッション継続アプリケーションまたはセッション継続マネージャは、他のアプリケーションがインフォテインメント・アプリケーションに統合可能なように、インフォテインメント・アプリケーションによって実行される個々の機能を大別化されたグループにグループ分けする。例えば、電話番号を検索する基本的機能は、住所を検索する機能と統合可能であり、その結果得られた統合機能は、インフォテインメント・アプリケーションとのユーザの対話に基づいて所望の移動先位置を検索する上で車載ナビゲーション・システムを補助するために使用され得る。
【００４５】
図１２は、セッション転送フローがどのように実行され得るかをさらに詳しく示す。図１２は、第１のモバイル（携帯）機器からのインフォテインメント・アプリケーションが存在しない場合、同等のアプリケーションをどのように、いつロードまたはダウンロードするかをシステムがどのように決定するのかをさらに具体的に示す。アプリケーションの状態とその他のコンテクスト情報がどのように利用されるのかを示す、図１３と図１４が次に続く。いくつかの使用例が、次に、図１５〜図１７に示される。
【００４６】
ここまで１台の転送側機器に関してセッション転送を説明してきたが、上記の内容は複数の機器に当てはめることができるものとする。例えば、二人のユーザが車両に乗り込むとするならば、各ユーザがそれぞれのセッションを車両のインフォテインメント・システムに同期させることができる。以下に説明するとおり、ＨＭＩはユーザが複数のアプリケーションを用いて閲覧できるようにしているので、ＨＭＩは複数の機器からの複数のセッション転送に対応するように構成され得る。
【００４７】
本開示の別の態様では、アプリケーションのコンテクストすなわち実行状況（自動車、家、携帯等）ごとに対応するユーザ・インタフェースは、それ独自のユーザ・インタフェースをもつことができる。各コンテクストは、ユーザにとって最も利用しやすい異なるユーザ・インタフェース設定をもつ。テレビジョン設定では、例えば、リモコン装置によってアプリケーションを制御することにユーザはより慣れているであろう。航空機のコンテクストでは、タッチ・スクリーンによってアプリケーションを制御することにユーザはより慣れているであろう。
【００４８】
車両側のインタフェースは異なる入力及び出力機構によって特徴付けられるので、車両側のアプリケーションは携帯側の対応するアプリケーションと同じではないものとする。したがって、規定設定構成の一部として組み込めるセッション継続機能を提供するためには、車両側のアプリケーションは「車両にうまく合う」ものである必要がある。しかし、「車両にうまく合う」ようにされていないアプリケーションでも、携帯側の対応するアプリケーションのルック＆フィールでなおもアクセスすることは可能である。
【００４９】
アプリケーションのコンテクストごとに対応するＵＩ（ユーザ・インタフェース）に関する考慮は、ユーザが最も楽しめるものまたはユーザが慣れているものだけに依存するのではなく、新しいコンテクストの環境において安全であるもの及び／または法令で許され得るものにも依存し得る。したがって、特定のコンテクストごとに合わせて設計されたアプリケーションは、国、地方、設定、及びその他の考慮事項によってカスタマイズされ得る。
【００５０】
車両コンテクストでは、ユーザ・インタフェースは、ＨＭＩとのユーザの対話をより容易にするように、かつ車両が動いているときには注意散漫になりにくくするように構成される。例えば、いくつかの実施形態では、車両が動いているときのＵＩは、車両が動いていないときとは対照的な色コードで色分けされる。さらに、例えば、ホーム画面は青色でダウンロードしたアプリケーションは他の色にするなど、使用されているアプリケーションまたはシステムの状態に応じてＵＩは追加の色コードをもつことができる。ＵＩは自動車内の光センサーの出力に基づいてコントラストを調整できる、または画面の色が光センサーの出力に基づいて反転され得る。さらに、ＵＩは、車両が動いているときの音声入力コマンドと音声フィードバックを取り入れることができる。上記に列挙したＵＩの実現は例示的であり、限定するものと意図されていない。
【００５１】
図２に戻り参照すると、機器はまた、表示部４６、ＨＭＩ３６、及び入力モジュール３８を含むものとする。これらの三つの構成要素は、ユーザと機器１４との対話を実現するために連携して機能すると想定される。車両コンテクストでは、表示部４６は、インフォテインメント・システム１４の表示ユニットである。スクリーンは、タッチ・センサー式のスクリーンを含む、当技術分野で知られているどんなスクリーンでもよい。タッチ・スクリーンの実施形態では、表示部４６は入力モジュール３８としての役目もする。入力モジュール３８は、音声入力が可能にされるようにマイクロフォンと音声分析装置であってもよい。入力モジュール３８は、例えば、タッチ入力、音声入力、またはタイピング入力といったユーザ入力を受け付けて、ユーザ入力をＨＭＩ３６へ伝達される信号に変換する。受信した信号に基づいて、ＨＭＩは受け付けた入力をアプリケーション制御モジュール３４へのコマンドに変換する。
【００５２】
車両コンテクストでは、ＨＭＩは複数のソースから入力を受け付けるようにさらに構成される。いくつかの実施形態では、ＨＭＩは、上述したように入力を受け付けることに加えて、携帯機器などのペアの相手のユーザ機器から入力を受信するようにさらに構成され得る。このような実施形態では、ユーザは入力手段として携帯機器を使用する選択ができる。ＰＷＡＮを介して、例えば、携帯機器１２は入力信号を車両のインフォテインメント・システム１４へ送信できる。入力モジュール３８は、受信したコマンドを解読してそれをＨＭＩ３６へ伝達する。
【００５３】
このような実施形態では、携帯機器のタッチ・スクリーンはインフォテインメント・システムのタッチ・スクリーンに相当し得ると想定される。図５はこの概念を図示する。図には、携帯機器１２とインフォテインメント・システム１４が示される。参照番号６２と６４は、携帯機器に対する特定のジェスチャーが、インフォテインメント・システムの表示画面上でどのように行なわれるかを示す。図に示すように、上記を使用して、ユーザは携帯機器１２を無線入力装置として利用できる。このオプションは、ユーザがＨＭＩと対話する際に、より快適に注意散漫になりにくい状態で行なえるようにできる。ユーザをさらに支援するために、携帯機器１２の入力手段またはインフォテインメント・システム１４のＨＭＩは、ユーザがタッチパッド上に文字を描いているとき、それを認識するように構成され得る。文字を描くことによって、ＨＭＩは入力された文字で始まるアプリケーションのリストを読み出せる。例えば、ユーザが「ｐｈ」というモジュールを描いたとすれば、ＨＭＩは「ｐｈｏｎｅ」に関係したアプリケーションを読み出すことができる。
【００５４】
わかるとおり、アプリケーションの大部分がクラウド中でホストされ、ネットワーク１０を介してインフォテインメント・システム１４へ配信されてきた状態で、ユーザは同時に複数のアプリケーションを実行させることができる。一つ以上の機器から転送されたか、またはインフォテインメント・システム自体によって起動された複数のアプリケーションを円滑にするために、ＨＭＩは個々のアプリケーションを及びアプリケーション・メニュー内を容易に見進めるように構成され得る。図６は、直線的なカルーセルとして構成された例示的なユーザ・インタフェースを示す。図に示すように、ユーザはアプリケーションを切り替えるために横に見進むことができ、アプリケーション・メニュー内を水平方向に見進むことができる。上記は例示的な目的で示されており、ユーザ・インタフェースの多くの異なる構成が考えられるものとする。
【００５５】
前述したとおり、ＨＭＩ３６は、車両コンテクストにおいてドライバにとっての注意散漫の量を減少させるようにさらに構成され得る。例えば、ドライバのインフォテインメント・システム１４のＵＩとの対話は、法令や条例の順守を強制するために自動車が動いている間はできないようにされ得る。これは、携帯機器１２を車載システムのコントローラとして使用する機会を提供する。ＵＩとの利用可能な対話は、ドライビング・モードに基づいて制限可能である。例えば、図７に示すように、車両が動いているときはクリック可能なボタンはＵＩから取り除かれる。右側の画面７６では、自動車が走行しているときには、自動車コンテクストのアプリケーション中で実在のボタンは消えている。この実施形態では、ユーザが画面を見なくてすみ、小さいまたは特定のアイコンを押そうとしなくてもよいように、ジェスチャー入力のみが許される。ドライバの注意散漫を回避するために、他の安全特性も車両のインフォテインメント・システムに組み込めることが想定される。
【００５６】
上述のアーキテクチャに関しては、アプリケーション・サーバが機器にアプリケーションを配信するような一般的なサーバ‐クライアント・モデルを説明した。しかし、その他のアーキテクチャも実現され得ると想定される。例えば、アプリケーションは携帯機器１２でホストされてもよい。セッション転送時に、携帯機器１２がインフォテインメント・システム１４へアプリケーションを供給する。このようなアーキテクチャでは、携帯機器１２は、インフォテインメント・システムのＨＭＩのコンフィギュレーション、コンテクスト分析を実行するためのデータ、及びサービス適応のための方法を含む、セッション転送に必要な情報を記憶しておくことができる。
【００５７】
他のアーキテクチャでは、インフォテインメント・システムのＨＭＩは、携帯機器１２から実行され得る。このような例では、アプリケーションのただ１つのコピーが存在すればよいという点で、アプリケーションは単一と見なすことができ、インフォテインメント・システムのＨＭＩはブラウザとして動作できる。このコンフィギュレーションを使用すると、アプリケーションのユーザ・インタフェースは、インフォテインメント・システムに対して、携帯機器またはアプリケーション・サーバからプッシュされる。
【００５８】
本文書で使用されるモジュールという用語は、一つ以上のソフトウェアまたはファームウェア・プログラムを実行する特定用途向け集積回路（ＡＳＩＣ）、電子回路、プロセッサ（共有、個別、またはグループ）及び／またはメモリー（共有、個別、またはグループ）、組み合わせ論理回路、及び／または説明した機能性を提供するその他の適当な構成要素を指していることもあるし、その一部であることもあるし、または含むこともある。さらに、本文書で説明した構成要素は、該当する機器に付属するプロセッサ上で実行可能なコンピュータにより読取り可能な命令として具現され得るものとする。
【００５９】
実施形態の上記の記述は、実例を示して説明する目的で記載されたものである。包括的なものまたは本発明を限定するものと意図されていない。特定の実施形態の個々の要素または機能は、概して、その特定の実施形態に限定されず、特に図示または言及されていなくても、適切な場合には、互いに置き換え可能であり、選択された実施形態において使用可能である。同一のものが、さまざまに変形されることもあり得る。このような変形は、本発明からの逸脱と見なされてはならず、すべてのこうした変形は本発明の範囲内に含まれるものと意図される。
【特許請求の範囲】
【請求項１】
第１の機器から第２の機器へアプリケーションのセッションを転送するための方法であり、
前記第１の機器上で、サーバからのアプリケーションに関係したデータを消費する第１のアプリケーションを実行することと、
前記第１のアプリケーションからセッション・データを取得することと、
前記セッション・データは、前記第１のアプリケーションの現在の状態を取り込み、前記第１のアプリケーションによって消費されている前記アプリケーションに関係したデータの状態をさらに示していて、
前記セッション・データを前記第２の機器へ転送することと、
前記第１の機器と第２の機器の少なくとも一つを使用して、前記サーバに前記アプリケーションに関係したデータを前記第２の機器へ送るようにさせるセッション転送要求を前記サーバへ送信することと、
前記第１のアプリケーションから前記セッション・データによって取り込まれた前記アプリケーションに関係したデータの状態に応じて、前記第２の機器上で、前記セッション・データを使用して、前記サーバからの前記アプリケーションに関係したデータを消費する第２のアプリケーションを実行することと、
を含んでなる方法。
【請求項２】
前記第２の機器へ前記セッション・データを転送する前記ステップは、前記第１の機器と第２の機器の間の近距離通信によって実行される、請求項１に記載の方法。
【請求項３】
前記第１のアプリケーションと第２のアプリケーションは、同じアプリケーションの別個の具体化である、請求項１に記載の方法。
【請求項４】
セッション転送要求を送信する前記ステップは、前記セッションデータの少なくとも一部を前記サーバへ伝達する、請求項１に記載の方法。
【請求項５】
セッション転送要求を送信する前記ステップは、前記アプリケーションに関係したデータを前記第１の機器のＩＰアドレスから前記第２の機器のＩＰアドレスへ宛先を変えて送ることを含む、請求項１に記載の方法。
【請求項６】
前記第１の機器と第２の機器は、携帯機器と車載機器からなるグループから選択される、請求項１に記載の方法。
【請求項７】
前記第１の機器と第２の機器の少なくとも一つはジェスチャー・インタフェースを含み、セッション・データを前記第２の機器へ転送するステップは、前記ジェスチャー・インタフェースを介したユーザ入力ジェスチャーによって制御される、請求項１に記載の方法。
【請求項８】
前記セッション・データを前記第２の機器へ転送する前に、近距離通信によって前記第１の機器と第２の機器をペアにするステップをさらに含んでなる、請求項１に記載の方法。
【請求項９】
前記第１のアプリケーションと同時に、セッション継続アプリケーションを前記第１の機器上で実行することをさらに含んでなり、前記継続アプリケーションは、前記第１のアプリケーションからセッション・データを取得し、前記セッション・データを前記第２の機器へ転送するステップを実行する、請求項１に記載の方法。
【請求項１０】
前記第１の機器と第２の機器の各々でそれぞれにセッション継続アプリケーションを実行することをさらに含んでなり、前記継続アプリケーションは、前記第１のアプリケーションからセッション・データを取得し、前記セッション・データを前記第２の機器へ転送するステップを実行する際に互いに協働する、請求項１に記載の方法。
【請求項１１】
アプリケーション・プロファイルを前記セッション継続アプリケーションへ供給することをさらに含んでなり、前記アプリケーション・プロファイルは、前記第１のアプリケーションからセッション・データを取得する際に使用される前記第１のアプリケーションに関するコンフィギュレーション情報を提供する、請求項９に記載の方法。
【請求項１２】
アプリケーション・プロファイルを前記セッション継続アプリケーションへ供給することをさらに含んでなり、前記アプリケーション・プロファイルは、前記第１のアプリケーションからのセッション・データを解釈する際に、前記セッション継続アプリケーションによって使用される前記第２のアプリケーションに関するコンフィギュレーション情報を提供する、請求項１０に記載の方法。
【請求項１】
第１の機器から第２の機器へアプリケーションのセッションを転送するための方法であり、
前記第１の機器上で、サーバからのアプリケーションに関係したデータを消費する第１のアプリケーションを実行することと、
前記第１のアプリケーションからセッション・データを取得することと、
前記セッション・データは、前記第１のアプリケーションの現在の状態を取り込み、前記第１のアプリケーションによって消費されている前記アプリケーションに関係したデータの状態をさらに示していて、
前記セッション・データを前記第２の機器へ転送することと、
前記第１の機器と第２の機器の少なくとも一つを使用して、前記サーバに前記アプリケーションに関係したデータを前記第２の機器へ送るようにさせるセッション転送要求を前記サーバへ送信することと、
前記第１のアプリケーションから前記セッション・データによって取り込まれた前記アプリケーションに関係したデータの状態に応じて、前記第２の機器上で、前記セッション・データを使用して、前記サーバからの前記アプリケーションに関係したデータを消費する第２のアプリケーションを実行することと、
を含んでなる方法。
【請求項２】
前記第２の機器へ前記セッション・データを転送する前記ステップは、前記第１の機器と第２の機器の間の近距離通信によって実行される、請求項１に記載の方法。
【請求項３】
前記第１のアプリケーションと第２のアプリケーションは、同じアプリケーションの別個の具体化である、請求項１に記載の方法。
【請求項４】
セッション転送要求を送信する前記ステップは、前記セッションデータの少なくとも一部を前記サーバへ伝達する、請求項１に記載の方法。
【請求項５】
セッション転送要求を送信する前記ステップは、前記アプリケーションに関係したデータを前記第１の機器のＩＰアドレスから前記第２の機器のＩＰアドレスへ宛先を変えて送ることを含む、請求項１に記載の方法。
【請求項６】
前記第１の機器と第２の機器は、携帯機器と車載機器からなるグループから選択される、請求項１に記載の方法。
【請求項７】
前記第１の機器と第２の機器の少なくとも一つはジェスチャー・インタフェースを含み、セッション・データを前記第２の機器へ転送するステップは、前記ジェスチャー・インタフェースを介したユーザ入力ジェスチャーによって制御される、請求項１に記載の方法。
【請求項８】
前記セッション・データを前記第２の機器へ転送する前に、近距離通信によって前記第１の機器と第２の機器をペアにするステップをさらに含んでなる、請求項１に記載の方法。
【請求項９】
前記第１のアプリケーションと同時に、セッション継続アプリケーションを前記第１の機器上で実行することをさらに含んでなり、前記継続アプリケーションは、前記第１のアプリケーションからセッション・データを取得し、前記セッション・データを前記第２の機器へ転送するステップを実行する、請求項１に記載の方法。
【請求項１０】
前記第１の機器と第２の機器の各々でそれぞれにセッション継続アプリケーションを実行することをさらに含んでなり、前記継続アプリケーションは、前記第１のアプリケーションからセッション・データを取得し、前記セッション・データを前記第２の機器へ転送するステップを実行する際に互いに協働する、請求項１に記載の方法。
【請求項１１】
アプリケーション・プロファイルを前記セッション継続アプリケーションへ供給することをさらに含んでなり、前記アプリケーション・プロファイルは、前記第１のアプリケーションからセッション・データを取得する際に使用される前記第１のアプリケーションに関するコンフィギュレーション情報を提供する、請求項９に記載の方法。
【請求項１２】
アプリケーション・プロファイルを前記セッション継続アプリケーションへ供給することをさらに含んでなり、前記アプリケーション・プロファイルは、前記第１のアプリケーションからのセッション・データを解釈する際に、前記セッション継続アプリケーションによって使用される前記第２のアプリケーションに関するコンフィギュレーション情報を提供する、請求項１０に記載の方法。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１１−１８７０５８（Ｐ２０１１−１８７０５８Ａ）
【公開日】平成２３年９月２２日（２０１１．９．２２）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−４７６８１（Ｐ２０１１−４７６８１）
【出願日】平成２３年３月４日（２０１１．３．４）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２３年９月２２日（２０１１．９．２２）
【国際特許分類】
【出願番号】特願２０１１−４７６８１（Ｐ２０１１−４７６８１）
【出願日】平成２３年３月４日（２０１１．３．４）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]