JP2014517370A

JP2014517370A - 車両用ヘッドユニットとモバイル装置間のデータ交換のための装置及び方法

Info

Publication number: JP2014517370A
Application number: JP2014503604A
Authority: JP
Inventors: ホ−ヨン・パク
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2011-04-05
Filing date: 2012-04-05
Publication date: 2014-07-17
Anticipated expiration: 2032-04-05
Also published as: WO2012138156A2; EP2695082A2; JP5940646B2; US9276988B2; WO2012138156A3; EP2695082A4; EP2695082B1; KR20120113642A; US20120259947A1

Abstract

本発明は、車両用ヘッドユニットとモバイル装置間の統一されたデータ交換方式を提供して、本発明の一実施形態ではこのようなデータ交換方式に基づいて車両用ヘッドユニットがモバイル装置に直接ウェブユーザインターフェースを提供するか、またはウェブユーザインターフェースを提供しない場合にはモバイル装置のモバイルアプリケーションを駆動してユーザインターフェースを提供する。本発明の他の実施形態ではこのようなデータ交換方式に基づいてモバイル装置に接続された第３のユーザインターフェースサーバから動的にユーザインターフェースを提供する。

Description

本発明は、データ交換装置及び方法に関し、特にインフォテインメントのための車両用ヘッドユニットとモバイル装置間のデータ交換装置及び方法に関する。

ユーザにとって自動車は、単純に運転用にだけ使用されるものではなく、車の中で各種エンターテイメントを楽しめる空間として認識されている。このような流れによって、車両内にモバイル装置と連動して各種情報を受信したり音楽やビデオのようなメディアを楽しめるインフォテインメント(infotainment）が発達し始めた。
このようなインフォテインメントを提供するシステムは、ユーザに情報を提供するために利用されるが、このような情報は、通常的に音響形態、視覚的形態またはこれらの組合せの形態でユーザに提供される。車両内のモバイル装置と車両用ヘッドユニットとの相互作用はユーザの便宜性を向上させることができる。

上記した通り、モバイル装置と車両用ヘッドユニット間の相互作用は、ユーザの特定要求に対応して多様な情報を提供することでユーザの便宜性を向上させることができる。しかし、情報を提供する手段及び方法において、ウェブアプリケーションあるいはネイティブアプリケーションのようにそれぞれ相異する形態のアプリケーションは、モバイル装置及び車両用ヘッドユニットの間で、例えば、ＨＴＴＰ通信、ＴＣＰ／ＩＰソケット通信など、各々予め規定されたデータ交換方式に基づいて動作するだけである。

したがって、車両内のモバイル装置と車両用ヘッドユニット間の通信において、多様な形態のアプリケーションを混用して使用することができる単一化された通信方式が提供される必要性がある。

したがって、本発明は、相異する装置間の通信において、多様な形態のアプリケーションを使用するための単一化された通信方式を提供するための装置及び方法を提供する。

また、本発明は、ユーザの特定要求に対応して多様な情報を提供することによってユーザの便宜性を向上させるように、相異する装置間のデータ交換装置及び方法を提供する。

また、本発明は、インフォテインメントのための車両用ヘッドユニットとモバイル装置間のデータ交換装置及び方法を提供する。

また、本発明は、それぞれの装置ごとに、相異するユーザインターフェースを混用して使用することができる装置及び方法を提供する。

本発明の実施形態による車両用ヘッドユニットとモバイル装置間の通信のための内部構造図である。図１のウェブサーバとウェブブラウザで実行されるウェブアプリケーションと、第２の装置内で実行されるネイティブアプリケーションとの通信を具体化した図である。本発明の一実施形態による制御装置(Control Device）が制御ポイント(Control Point）装置にウェブアプリケーションを提供する過程を示した図である。本発明の他の実施形態による制御ポイント装置が第３のユーザインターフェースサーバからネイティブアプリケーションユーザインターフェースを受信する過程を示した図である。本発明の実施形態による制御装置が提供するサービスリストに対する情報を示した図である。本発明の他の実施形態による第１の装置と第２の装置間でネイティブアプリケーションを利用した通信を具体化した図である。本発明のさらに他の実施形態による制御ポイント装置がネイティブアプリケーションユーザインターフェースを受信する過程を示した図である。

以下、本発明の望ましい実施形態は、添付の図面を参照して詳細に説明する。下記説明では、具体的な構成素子などのような特定事項が示されているが、これは本発明のより全般的な理解を助けるために提供されているだけで、このような特定事項が本発明の範囲内で所定の変形あるいは変更できることはこの技術分野で通常の知識を有する者にとっては明らかである。また、本発明を説明するにあって、本発明と関連した公知技術に対する具体的な説明が本発明の要旨を必要もなく不明瞭にすることができると判断される場合にはその詳細な説明を省略する。

本発明は、車両用ヘッドユニットとモバイル装置間の統一されたデータ交換方式を提供し、本発明の一実施形態では、このようなデータ交換方式に基づいて車両用ヘッドユニットがモバイル装置に直接ウェブユーザインターフェースを提供したり、ウェブユーザインターフェースを提供しない場合には、モバイル装置のモバイルアプリケーションを駆動してユーザインターフェースを提供する。本発明の他の実施形態では、このようなデータ交換方式に基づいて、モバイル装置に接続された第３のユーザインターフェースサーバから動的にユーザインターフェースを提供する。

従って、モバイル装置でウェブブラウザを通して車両用ヘッドユニットと通信したり、モバイル装置内に保存されたモバイルアプリケーションを通して車両用ヘッドユニットと通信することができるようになる。特に本発明によると、モバイル装置が車両用ヘッドユニットと通信する時、ユーザは車両製造業者から提供される制御ユーザインターフェースとモバイル製造業者から提供されるモバイルアプリケーション制御ユーザインターフェースを同時に使用することができる。従って、車両に乗っているユーザが、そのユーザの特定要求に適しているインフォテインメントをモバイル装置または車両用ヘッドユニットを通して受信することで楽しむことができる。

上記のような動作を図１を参照して説明する。図１は、本発明の実施形態によって第１の装置と第２の装置間の通信において、ウェブアプリケーションとネイティブアプリケーションを混用して使用できるアーキテクチャー及びインターフェースを示した図である。本発明の実施形態では、第１の装置が車両用ヘッドユニット(Head Unit）であり、第２の装置はモバイル装置である場合を例に挙げることができるが、反対に、第１の装置がモバイル装置である場合は、第２の装置は車両用ヘッドユニットになる。第１の装置１００は、第２の装置１３０にウェブアプリケーションを提供できるウェブサーバ１１０及びUniversal Plugand Play(ＵＰｎＰ）スタック(Stack）１２０を含む。

ウェブサーバ１１０は、第２の装置１３０に伝送されたウェブアプリケーションと通信する役割をする。また、第１の装置１００に存在するＵＰｎＰスタック(Stack）１２０は、周りの第２の装置を発見でき、第２の装置１３０に第１の装置１００が提供するサービスに対する情報を伝達する。上記サービスに対する情報は、ＵＰｎＰアクション(Action）に対する応答、あるいは装置デスクリプション(Device Description）内に記述されて提供できる。

第２の装置１３０は、第１の装置１００からウェブアプリケーションを受信してユーザに見せることができるウェブブラウザ１４０を有している。

また、第２の装置１３０は、第１の装置１００のウェブサーバ１１０が上記ウェブアプリケーションを提供できない時に、第１の装置１００のウェブサーバ１１０と通信できるネイティブアプリケーション１５０を有することができる。追加的に、ネイティブアプリケーション１５０は、自立的に定義されたプロトコルとインターフェースに基づいてウェブサーバ１１０ではなくネイティブアプリケーション通信モジュール１９０と通信できる。

また、第２の装置１３０もＵＰｎＰスタック(Stack）１６０を含み、そのスタック１６０は、第１の装置１００を発見でき、第１の装置１００に第１の装置１００が提供するサービスリストを要請できる。第１の装置１００から受信したサービスリストに対する情報は、全体、あるいは部分的にウェブブラウザ１４０内のウェブアプリケーションか、またはネイティブアプリケーション１５０に伝送されることができる。

ユーザインターフェースサーバ(ＵＩ Server）１７０は、ネイティブアプリケーション１５０が第１の装置１００と通信するためのユーザインターフェースを要求する時、ネイティブアプリケーション１５０で表現できるユーザインターフェースに対するプロファイルを伝達できる。ユーザインターフェースサーバ１７０は、論理的モジュールとして、第１の装置１００あるいは第２の装置１３０の内部に存在することができ、また、第１の装置１００と第２の装置１３０の内部ではなく第３の外部サーバに存在することもできる。

上記のような構造を有することによって、第１の装置１００ではウェブユーザインターフェースを提供して、第２の装置１３０または第２の装置１３０に接続した第３のサーバ、例えば、ユーザインターフェースサーバ１７０ではネイティブアプリケーションユーザインターフェースを提供しても、このようなそれぞれのユーザインターフェースを混用して使用することが可能になる。

以下、第１の装置１００で第２の装置１３０にウェブアプリケーション提供に関する情報を送る方法及びステップ、上記提供された情報を第２の装置１３０で分析して適切なウェブあるいはネイティブアプリケーションを選択して実行する方法及びステップ、上記実行されたアプリケーションが第１の装置と通信する方法及びステップに対して説明する。このために図２を参照して説明する。

図２は、図１のウェブサーバとウェブブラウザで実行されているウェブアプリケーションと第２の装置内で実行されるネイティブアプリケーション間の通信プロセスを具体化した図である。

まず、第２の装置１３０を見ると、第２の装置プラットホーム(platform）２００を含み、第２の装置プラットホーム２００は、ＨＴＴＰプロトコル通信をサポートする。上記ＨＴＴＰプロトコル通信をサポートするＨＴＴＰプロトコルモジュールは、第１の装置１００に情報を伝達できるプールモジュール(Pull Module）(Sender）２０５と第１の装置１００から情報を受信することができるプッシュモジュール(Push Module）(Receiver）２１０を含む。

また、第２の装置１３０は、ウェブブラウザ１４０を含み、ウェブブラウザ１４０は、第１の装置１００のウェブサーバ１１０から受信したウェブアプリケーション２１５を実行させることができる。ウェブアプリケーション２１５は、ウェブブラウザ１４０のジャバスクリプト２２０のエンジンを通じて、ＨＴＴＰプロトコルモジュールのプールモジュール(Pull Module）(Sender）２０５を通してＨＴＴＰ要請メッセージを第１の装置１００に伝達できる。

また、第２の装置１３０内で動作するネイティブアプリケーション１５０は、第２の装置プラットホーム２００で提供するＨＴＴＰクライアントモジュールのネイティブ(Native）ＡＰＩ２２５を通して、ＨＴＴＰプロトコルをハンドリングすることができる。ここで、ネイティブＡＰＩ２２５は、ＨＴＴＰプロトコル通信のプールモジュール２０５を通して、第１の装置１００のウェブサーバ１１０にネイティブアプリケーション１５０で要請する内容を伝達できる。上記要請メッセージは、GET、POST、PUT、DELETEのようなＨＴＴＰヘッダーメッセージに基づいて、第１の装置１００内のウェブサーバ１１０に情報を伝達したり要請することができる。

第１の装置１００から、第２の装置１３０で各々実行されるウェブアプリケーションあるいはネイティブアプリケーション１５０に情報を伝達(Push）しようとする時、一般的に、ＨＴＭＬ５で提供するウェブソケット(Web Socket）方式あるいはサーバイベント(Server Event）方式を通して伝えられることができる。第２の装置１３０内のＨＴＴＰクライアントモジュールは、必ずウェブサーバ１１０からプッシュ方式で伝達しようとする情報を受信できるネイティブＡＰＩ２２５を含まなければならない。

以下では、本発明の他の実施形態で第１の装置と第２の装置間にネイティブアプリケーションを利用した通信を具体化して図６に示す。

図６では、ネイティブアプリケーション６００がＨＴＴＰ関連ネイティブ(Native）ＡＰＩ６０５を使用して通信し、相異する特定プロトコルに対しては、相異するネイティブＡＰＩ６１０を使用して通信する場合を示している。ここで、ウェブブラウザ６１５をはじめ、他の構成部は図２と同様に動作する。

図３は、本発明の制御装置が制御ポイントにユーザインターフェースを有しているウェブアプリケーションを提供する時のフローチャートを示した図である。特に、図３は、本発明の一実施形態によって制御装置が制御ポイントにウェブアプリケーションを提供する過程を示している。ここで、制御装置は第１の装置に該当して、制御ポイントは第２の装置に該当する。

図１で示したように、制御装置と制御ポイントはＵＰｎＰスタックを含む。図３で制御装置１００はＵＰｎＰ制御装置として役割をし、制御ポイント１３０はＵＰｎＰ制御ポイントとして役割をする。

制御ポイント１３０は、ステップ３００で、装置ディスカバリ及びデスクリプション動作を通して制御装置１００を発見する。その後、制御ポイント１３０は、ステップ３０５で、発見された制御装置１００にサービスリストを要請する。このようなサービスリストの要請のために‘GetServiceList ＳＯＡＰ Action’を伝達する。上記ＳＯＡＰ Actionは、制御装置１００が提供するサービスに対するリストを要請するメッセージであり、これに対する応答で、制御装置１００は、ステップ３１０で制御ポイント１３０にサービスリストを提供する。このようなサービスリスト提供のために‘Ａ＿ＡＲＧ＿ＴＹＰＥ_ServiceList'を伝達する。このようなサービスリストには、ステップ３１５でウェブアプリケーションが提供されるか否かが含まれる。

ここで、上記サービスリストは、図５に示されたように、それぞれのサービスを有して、それぞれのサービスは、サービスＩＤ５１０、名前５１５、そして制御装置１００が上記サービスに対してウェブアプリケーション５２０を提供できるか否かに対する情報５２５、制御装置１００がウェブアプリケーションを提供できる場合に上記サービスに対するウェブアプリケーションにアクセスできるＵＲＬアドレス５３０も提供できる。

ここで、制御装置１００が上記サービスに対してウェブアプリケーション５２０を提供できるか否かに対する情報５２５に対するエレメント(Element）は相異する方式で表現できる。上記サービスに対するウェブアプリケーション５２０にアクセスできるＵＲＬアドレス５３０が存在する場合には、ウェブアプリケーション５２０の提供が可能であるという表現と考えることができるので、具現によって情報５２５を省略して表現することができる。

上記サービスリスト情報を受信した制御ポイント１３０は、上記サービスリストのうち所望のサービスをユーザが選択できるように画面に見せる。したがって、制御ポイント１３０のユーザはその中一つのサービスを選択するようになる。

ステップ３２０で、サービスが選択された場合、制御ポイント１３０は、ステップ３２５で、選択されたサービスがウェブアプリケーションを提供できるか否かをサービスリスト情報に基づいて判断する。すなわち、選択されたサービスに対するウェブアプリケーションを提供するか否かを判断する。

もし、制御ポイント１３０からして、ウェブアプリケーションを制御装置１００から受信することができると、図５のように上記サービスリスト情報からウェブアプリケーションＵＲＬ情報を抽出する。そして、ステップ３３０で制御ポイント１３０内でデフォルトとして決められたウェブブラウザ１４０を実行する。ウェブブラウザが駆動されることによって、制御ポイント１３０は、ステップ３３５及びステップ３４０で、ウェブブラウザ１４０に上記抽出されたＵＲＬ情報を伝達して、ウェブブラウザ１４０が制御装置１００のウェブサーバ１１０からウェブアプリケーションを要請して受信する。次に、ステップ３４５で、ウェブアプリケーションをレンダリングしてそのウェブアプリケーションをウェブブラウザ１４０内で実行する。したがって、実行されたウェブアプリケーションは、ユーザに表示され、制御ポイント１３０は、ステップ３５０で、上記ウェブアプリケーションを通して制御装置１００と通信できるようになる。

一方、図４は、本発明の他の実施形態によって、制御ポイントが第３のネイティブユーザインターフェースサーバからネイティブアプリケーションユーザインターフェースを受信する過程を示している。図４においても、上記図３のように制御装置と制御ポイント装置はＵＰｎＰスタックを含み、ネイティブユーザインターフェースサーバは、ネイティブアプリケーションユーザインターフェースサーバとしての役割をする。

図４を参照すると、ステップ４００乃至ステップ４１５は、図３のステップ３００乃至ステップ３１５における動作と同一であるため、その具体的な説明は反復しない。従って、制御ポイント１３０は図３で説明したように、制御装置１００で提供する図５で示すようなサービスリストを受信することができ、制御ポイントで、何れか一つのサービスを選択できるように受信したサービスリストを表示する。

制御ポイント１３０は、ステップ４２０で、選択されたサービスがウェブアプリケーションを提供できるか否かを受信したサービスリスト情報に基づいて判断する。すなわち、ウェブユーザインターフェースが提供されたか否かを判断する。もし、制御ポイント１３０が制御装置１００からウェブアプリケーションを受信できないか、あるいは、受信できてもネイティブアプリケーションを通して制御装置１００と通信しようとする場合、制御ポイント１３０は、ステップ４２５で制御ポイント１３０が選択したサービスと関連したネイティブアプリケーションを実行する。

次に、実行されたネイティブアプリケーションは、ユーザインターフェースサーバ１７０に、ステップ４３０のように、上記選択されたサービス情報と上記サービスを提供する制御装置１００に対する情報を伝達することで、ステップ４３５でユーザインターフェースサーバ１７０にネイティブアプリケーションＵＩを要請する。制御装置１００に対する情報は、一例としてＵＰｎＰ装置デスクリプション(Device Description）内の<modelName>や<modelNumber>などのような情報があり得る。

ネイティブアプリケーションＵＩ要請に対応して、ユーザインターフェースサーバ１７０は、ステップ４３０のような情報に基づいてネイティブアプリケーションＵＩを生成してステップ４４０で伝送する。ここで、ユーザインターフェースサーバ１７０は、ネイティブアプリケーション実行によるネイティブアプリケーションユーザインターフェースを提供するサーバである。

上記ネイティブアプリケーションＵＩを受信したネイティブアプリケーションは、ステップ４４５で上記ネイティブアプリケーションＵＩをレンダリングする。上記選択されたサービスに対する制御ポイント１３０内のネイティブアプリケーションと制御装置１００が通信するためには、制御装置１００内の通信モジュールが実行されなければならない。

仮に、制御装置１００内で予め実行されていないと、ステップ４４６でサービス開始を指示する。このために制御ポイント１３０は‘StartService ＵＰｎＰＳＯＡＰ Action’メッセージを制御装置１００に伝送することで上記通信モジュールを実行させる。この時、上記ＳＯＡＰ Actionのパラメータとしてステップ４１０で受信したサービスリストのうち、図５のように実行させようとするサービスに対するサービスＩＤ５１０が含まれる。上記‘ＳＯＡＰ Action’メッセージが制御装置１００に伝えられると、制御装置１００は、通信モジュール１９０を含んで制御ポイント１３０が選択したサービスに関連したもう一つのモジュールを共に駆動させる。仮に、関連したもう一つのモジュールが駆動される必要がないと駆動させなくても良い。そして、ステップ４４８でこのようなメッセージの伝送に対応した結果を制御ポイント１３０に提供する。

一方、本発明のさらに他の実施形態によって制御ポイント装置がネイティブアプリケーションユーザインターフェースを受信する過程を示すと図７のようになる。

図７では、制御装置１００内の通信モジュール１９０だけを駆動させる場合を例示している。従って、ステップ４４６における上記‘StartService ＵＰｎＰＳＯＡＰ Action’の代わりに図７のステップ７５０のように通信モジュールの開始を指示するメッセージが伝えられることができる。このために‘LaunchApplication ＵＰｎＰＳＯＡＰ Action’メッセージが利用されることができる。このようなメッセージを通して上記制御ポイント１３０内のネイティブアプリケーション１５０が通信モジュール１９０と通信できる環境を用意することができ、通信モジュール内で決められた自体プロトコル及びインターフェース例えば、ネイティブＡＰＩ６１０を通して上記選択されたサービスに関連した他のモジュールを制御装置１００内で実行させることができる。

従って、制御ポイント１３０は、ステップ４５０で、上記ネイティブアプリケーションＵＩをレンダリングするネイティブアプリケーション１５０を通して制御装置１００と通信できる。上記制御ポイント１３０が選択したサービスをこれ以上遂行する必要がないと、ステップ４２５でサービス終了を指示する。このようなサービス終了の指示のために‘StopService ＵＰｎＰＳＯＡＰ Action’メッセージを利用する。このようなメッセージは、上記通信モジュールを停止させることができ、上記中断されたサービスに関連した他のモジュールも停止させる役割をする。この時、上記ＳＯＡＰ Actionのパラメータとして、ステップ４１０で、受信したサービスリストのうち中断させようとするサービスに対するサービスＩＤ５１０が図５で示すように挿入されるようになる。そして、ステップ４５４で、このようなサービス終了のための上記メッセージの伝送に対応する結果を制御ポイント１３０に提供する。

一方、上記図４のようなサービス終了のためのメッセージの代わりに、図７では通信モジュール１５０だけを中止させることができるメッセージを送ることができる。従って、制御ポイント１３０は、通信モジュール１５０内で決められた自体プロトコル及びインターフェースを通して、現在、制御装置１００内で実行されている上記選択されたサービスに関連した他のモジュールを中止させることができる。そして、制御ポイント１３０は、ステップ７６５で通信モジュール停止のためのメッセージを伝送する。このために制御装置１００内で通信モジュール１９０だけを中止させることができる‘TerminateApplication ＵＰｎＰＳＯＡＰ Action’７０２を伝送する。制御ポイント１３０は、このような通信モジュール停止のためのメッセージ伝送に対応して、ステップ７７０で結果を受信する。こうして、制御ポイント１３０内のネイティブアプリケーション１５０は通信モジュール１９０との通信を中断できる。

本発明によると、車両用ヘッドユニットとモバイル装置間の通信において車両製造業者から提供されるウェブアプリケーションを通したユーザインターフェース(ＵＩ）とモバイル装置製造業者から提供されるモバイルアプリケーションを通したユーザインターフェースを同時にサポートすることができる。

従って、本発明によると、相異する装置で各々ウェブユーザインターフェース及びネイティブアプリケーションユーザインターフェースを提供してもこれを混用して使用することが可能な利点がある。

また本発明によると、モバイルプラットホームからしては、単一サービスに対して状況によりウェブアプリケーションとモバイルアプリケーションを動的に選択して駆動できる環境を確立することができる。

以上のように例示された図面を参照して、本発明の実施形態を説明したが、本発明が属する技術分野で通常の知識を有する者は、本発明がその技術的思想や必須な特徴を変更することなく他の具体的な形態で実施可能であることが分かる。したがって、以上で記述した実施形態はあらゆる面で例示的なことであり、限定的でないことに理解すべきである。

１００制御装置
１１０ウェブサーバ
１３０制御ポイント
１４０ウェブブラウザ
１５０ネイティブアプリケーション
１５０通信モジュール
１６０スタック
１７０ユーザインターフェースサーバ
１９０ネイティブアプリケーション通信モジュール
２００第２の装置プラットホーム
２０５プールモジュール
２１０プッシュモジュール
２１５ウェブアプリケーション
２２０ジャバスクリプト

Claims

制御ポイント装置における制御装置とのデータ交換のための方法であって、
前記制御装置がディスカバリされると、前記制御装置にサービスリストを要請するステップと、
前記制御装置から少なくとも一つのサービスに対してウェブアプリケーションが提供されるか否かに対する情報を含むサービスリストを受信するステップと、
前記サービスリストのうち何れか一つのサービスが選択されると、
前記制御装置が前記選択されたサービスに対してウェブアプリケーションを提供できるか否かを判断するステップと、前記選択されたサービスに対してウェブアプリケーションを前記制御装置が提供できる場合、前記選択されたサービスに対するウェブアプリケーションをウェブブラウザを通して前記制御装置に要請するステップと、
前記制御装置から受信されたウェブアプリケーションを実行するステップとを含むことを特徴とするデータ交換のための方法。
前記制御ポイント装置及び前記制御装置は、
各々モバイル装置及び車両用ヘッドユニットであることを特徴とする請求項１に記載のデータ交換のための方法。
前記サービスリストは、
前記少なくとも一つのサービスのＩＤ、名前及び前記少なくとも一つのサービスに対するウェブアプリケーションにアクセス可能なＵＲＬアドレスのうち少なくとも一つを含むことを特徴とする請求項１または２に記載のデータ交換のための方法。
前記制御装置に要請するステップは、
前記サービスリストを受信すると、前記ウェブブラウザを駆動するステップと、
前記サービスリストから前記選択されたサービスに対するウェブアプリケーションにアクセス可能なＵＲＬアドレスを抽出するステップと、
前記抽出されたＵＲＬ情報を利用することで、前記ウェブブラウザを通して前記制御装置のウェブサーバに前記選択されたサービスに対するウェブアプリケーションを要請するステップとを含むことを特徴とする請求項１乃至３のうち何れか一項に記載のデータ交換のための方法。
前記サービスリストの要請は、
制御ポイント内に含まれたＵＰｎＰスタックを通して前記制御装置に伝達されることであることを特徴とする請求項１乃至４のうち何れか一項に記載のデータ交換のための方法。
前記制御ポイント装置が前記ウェブアプリケーションを通して前記制御装置のウェブサーバと通信するステップをさらに含むことを特徴とする請求項１乃至５のうち何れか一項に記載のデータ交換のための方法。
前記制御ポイント装置が前記選択されたサービスに対するウェブアプリケーションを前記制御装置から受信できない場合、
前記選択されたサービスと関連したネイティブアプリケーションを実行するステップと、
前記ネイティブアプリケーションを通して前記制御装置のウェブサーバと通信するためのネイティブアプリケーションＵＩをＵＩサーバに要請するステップと、
前記ＵＩサーバから前記ネイティブアプリケーションＵＩを受信すると、前記ネイティブアプリケーションＵＩをレンダリングすることで前記ネイティブアプリケーションを通して、前記制御装置の通信モジュールの駆動を指示するステップをさらに含むことを特徴とする請求項１乃至６のうち何れか一項に記載のデータ交換のための方法。
サービス終了要請に対応して中断するサービスに対するサービスＩＤを含む前記制御装置の通信モジュールの駆動を停止させるためのメッセージを伝送するステップをさらに含むことを特徴とする請求項１乃至７のうち何れか一項に記載のデータ交換のための方法。
制御装置とのデータ交換のための制御ポイント装置であって、
隣接の制御装置をディスカバリして、前記制御装置がディスカバリされると前記制御装置にサービスリストを要請し、前記制御装置から少なくとも一つのサービスに対するウェブアプリケーションが提供されるか否かに対する情報を含むサービスリストを受信するＵＰｎＰスタックと、
前記ＵＰｎＰスタックから前記サービスリストを受信して、前記サービスリストのうち選択された何れか一つのサービスに対してウェブアプリケーションが提供できるか否かを判断して、前記選択されたサービスに対するウェブアプリケーションを前記制御装置に要請して、前記制御装置から受信されたウェブアプリケーションを実行するウェブブラウザとを含むことを特徴とする制御ポイント装置。
前記ウェブブラウザは、
前記サービスリストに含まれた少なくとも一つのサービスに対するウェブアプリケーションが提供されるか否かを参照して、前記選択されたサービスに対してウェブアプリケーションを前記制御装置が提供できるか否かを判断することを特徴とする請求項９に記載の制御ポイント装置。
前記制御ポイント装置及び前記制御装置は、
各々モバイル装置及び車両用ヘッドユニットであることを特徴とする請求項９または１０に記載の制御ポイント装置。
前記サービスリストは、
前記少なくとも一つのサービスのＩＤ、名及び前記少なくとも一つのサービスに対するウェブアプリケーションにアクセス可能なＵＲＬアドレスのうち少なくとも一つを含むことを特徴とする請求項９乃至１１のうち何れか一項に記載の制御ポイント装置。
前記実行されたウェブアプリケーションは、
前記制御装置のウェブサーバと通信するために利用されることであることを特徴とする請求項９乃至１２のうち何れか一項に記載の制御ポイント装置。
前記選択されたサービスに対するウェブアプリケーションを前記制御装置から受信できない場合に実行されるネイティブアプリケーションをさらに含むことを特徴とする請求項９乃至１３のうち何れか一項に記載の制御ポイント装置。
前記ネイティブアプリケーションは、
前記選択されたサービスと関連し、前記制御装置のウェブサーバと通信するためのネイティブアプリケーションＵＩをＵＩサーバに要請した後、前記ＵＩサーバから前記ネイティブアプリケーションＵＩを受信すると、前記ネイティブアプリケーションＵＩをレンダリングして前記制御装置の通信モジュールの駆動を指示することを特徴とする請求項９乃至１４のうち何れか一項に記載の制御ポイント装置。