(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5940646
(24)【登録日】2016年5月27日
(45)【発行日】2016年6月29日
(54)【発明の名称】車両用ヘッドユニットとモバイル装置間のデータ交換のための装置及び方法
(51)【国際特許分類】
G06F 13/00 20060101AFI20160616BHJP
G06F 15/00 20060101ALI20160616BHJP
【FI】
G06F13/00 530A
G06F15/00 470
【請求項の数】15
【全頁数】13
(21)【出願番号】特願2014-503604(P2014-503604)
(86)(22)【出願日】2012年4月5日
(65)【公表番号】特表2014-517370(P2014-517370A)
(43)【公表日】2014年7月17日
(86)【国際出願番号】KR2012002589
(87)【国際公開番号】WO2012138156
(87)【国際公開日】20121011
【審査請求日】2015年2月18日
(31)【優先権主張番号】10-2011-0031424
(32)【優先日】2011年4月5日
(33)【優先権主張国】KR
(31)【優先権主張番号】10-2011-0038066
(32)【優先日】2011年4月22日
(33)【優先権主張国】KR
(73)【特許権者】
【識別番号】503447036
【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(72)【発明者】
【氏名】ホ−ヨン・パク
【審査官】
古河 雅輝
(56)【参考文献】
【文献】
特開2009−187533(JP,A)
【文献】
特開2009−122945(JP,A)
【文献】
特開2003−330824(JP,A)
【文献】
特開2005−236560(JP,A)
【文献】
国際公開第2003/098960(WO,A1)
【文献】
米国特許出願公開第2005/0144070(US,A1)
【文献】
米国特許出願公開第2010/0219976(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 3/01
G06F 3/048− 3/0489
G06F 3/14 − 3/153
G06F 13/00
G06F 15/00
G08G 1/00 −99/00
(57)【特許請求の範囲】
【請求項1】
制御ポイント装置における制御装置とのデータ交換のための方法であって、
前記制御装置がディスカバリされると、前記制御装置にサービスリストを要請するステップと、
前記制御装置から少なくとも一つのサービスに対してウェブアプリケーションが提供されるか否かに対する情報を含むサービスリストを受信するステップと、
前記サービスリストのうち何れか一つのサービスが選択されると、
前記制御装置が前記選択されたサービスに対してウェブアプリケーションを提供できるか否かを判断するステップと、前記選択されたサービスに対してウェブアプリケーションを前記制御装置が提供できる場合、前記選択されたサービスに対するウェブアプリケーションをウェブブラウザを通して前記制御装置に要請するステップと、
前記制御装置から受信されたウェブアプリケーションを実行するステップとを含むことを特徴とするデータ交換のための方法。
【請求項2】
前記制御ポイント装置及び前記制御装置は、
各々モバイル装置及び車両用ヘッドユニットであることを特徴とする請求項1に記載のデータ交換のための方法。
【請求項3】
前記サービスリストは、
前記少なくとも一つのサービスのID、名前及び前記少なくとも一つのサービスに対するウェブアプリケーションにアクセス可能なURLアドレスのうち少なくとも一つを含むことを特徴とする請求項1または2に記載のデータ交換のための方法。
【請求項4】
前記制御装置に要請するステップは、
前記サービスリストを受信すると、前記ウェブブラウザを駆動するステップと、
前記サービスリストから前記選択されたサービスに対するウェブアプリケーションにアクセス可能なURLアドレスを抽出するステップと、
前記抽出されたURL情報を利用することで、前記ウェブブラウザを通して前記制御装置のウェブサーバに前記選択されたサービスに対するウェブアプリケーションを要請するステップとを含むことを特徴とする請求項1乃至3のうち何れか一項に記載のデータ交換のための方法。
【請求項5】
前記サービスリストの要請は、
制御ポイント内に含まれたUPnPスタックを通して前記制御装置に伝達されることであることを特徴とする請求項1乃至4のうち何れか一項に記載のデータ交換のための方法。
【請求項6】
前記制御ポイント装置が前記ウェブアプリケーションを通して前記制御装置のウェブサーバと通信するステップをさらに含むことを特徴とする請求項1乃至5のうち何れか一項に記載のデータ交換のための方法。
【請求項7】
前記制御ポイント装置が前記選択されたサービスに対するウェブアプリケーションを前記制御装置から受信できない場合、
前記選択されたサービスと関連したネイティブアプリケーションを実行するステップと、
前記ネイティブアプリケーションを通して前記制御装置のウェブサーバと通信するためのネイティブアプリケーションUIをUIサーバに要請するステップと、
前記UIサーバから前記ネイティブアプリケーションUIを受信すると、前記ネイティブアプリケーションUIをレンダリングすることで前記ネイティブアプリケーションを通して、前記制御装置の通信モジュールの駆動を指示するステップをさらに含むことを特徴とする請求項1乃至6のうち何れか一項に記載のデータ交換のための方法。
【請求項8】
サービス終了要請に対応して中断するサービスに対するサービスIDを含む前記制御装置の通信モジュールの駆動を停止させるためのメッセージを伝送するステップをさらに含むことを特徴とする請求項1乃至7のうち何れか一項に記載のデータ交換のための方法。
【請求項9】
制御装置とのデータ交換のための制御ポイント装置であって、
隣接の制御装置をディスカバリして、前記制御装置がディスカバリされると前記制御装置にサービスリストを要請し、前記制御装置から少なくとも一つのサービスに対するウェブアプリケーションが提供されるか否かに対する情報を含むサービスリストを受信するUPnPスタックを含み、
前記UPnPスタックから前記サービスリストを受信して、前記サービスリストのうち選択された何れか一つのサービスに対してウェブアプリケーションが提供できるか否かを判断して、前記選択されたサービスに対するウェブアプリケーションを前記制御装置に要請して、前記制御装置から受信されたウェブアプリケーションを実行することを特徴とする制御ポイント装置。
【請求項10】
前記サービスリストに含まれた少なくとも一つのサービスに対するウェブアプリケーションが提供されるか否かを参照して、前記選択されたサービスに対してウェブアプリケーションを前記制御装置が提供できるか否かを判断することを特徴とする請求項9に記載の制御ポイント装置。
【請求項11】
前記制御ポイント装置及び前記制御装置は、
各々モバイル装置及び車両用ヘッドユニットであることを特徴とする請求項9または10に記載の制御ポイント装置。
【請求項12】
前記サービスリストは、
前記少なくとも一つのサービスのID、名及び前記少なくとも一つのサービスに対するウェブアプリケーションにアクセス可能なURLアドレスのうち少なくとも一つを含むことを特徴とする請求項9乃至11のうち何れか一項に記載の制御ポイント装置。
【請求項13】
前記実行されたウェブアプリケーションは、
前記制御装置のウェブサーバと通信するために利用されることであることを特徴とする請求項9乃至12のうち何れか一項に記載の制御ポイント装置。
【請求項14】
前記選択されたサービスに対するウェブアプリケーションを前記制御装置から受信できない場合に実行されるネイティブアプリケーションをさらに含むことを特徴とする請求項9乃至13のうち何れか一項に記載の制御ポイント装置。
【請求項15】
前記ネイティブアプリケーションは、
前記選択されたサービスと関連し、前記制御装置のウェブサーバと通信するためのネイティブアプリケーションUIをUIサーバに要請した後、前記UIサーバから前記ネイティブアプリケーションUIを受信すると、前記ネイティブアプリケーションUIをレンダリングして前記制御装置の通信モジュールの駆動を指示することを特徴とする請求項9乃至14のうち何れか一項に記載の制御ポイント装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ交換装置及び方法に関し、特にインフォテインメントのための車両用ヘッドユニットとモバイル装置間のデータ交換装置及び方法に関する。
【背景技術】
【0002】
ユーザにとって自動車は、単純に運転用にだけ使用されるものではなく、車の中で各種エンターテイメントを楽しめる空間として認識されている。このような流れによって、車両内にモバイル装置と連動して各種情報を受信したり音楽やビデオのようなメディアを楽しめるインフォテインメント(infotainment)が発達し始めた。
このようなインフォテインメントを提供するシステムは、ユーザに情報を提供するために利用されるが、このような情報は、通常的に音響形態、視覚的形態またはこれらの組合せの形態でユーザに提供される。車両内のモバイル装置と車両用ヘッドユニットとの相互作用はユーザの便宜性を向上させることができる。
【発明の概要】
【発明が解決しようとする課題】
【0003】
上記した通り、モバイル装置と車両用ヘッドユニット間の相互作用は、ユーザの特定要求に対応して多様な情報を提供することでユーザの便宜性を向上させることができる。しかし、情報を提供する手段及び方法において、ウェブアプリケーションあるいはネイティブアプリケーションのようにそれぞれ相異する形態のアプリケーションは、モバイル装置及び車両用ヘッドユニットの間で、例えば、HTTP通信、TCP/IPソケット通信など、各々予め規定されたデータ交換方式に基づいて動作するだけである。
【0004】
したがって、車両内のモバイル装置と車両用ヘッドユニット間の通信において、多様な形態のアプリケーションを混用して使用することができる単一化された通信方式が提供される必要性がある。
【0005】
したがって、本発明は、相異する装置間の通信において、多様な形態のアプリケーションを使用するための単一化された通信方式を提供するための装置及び方法を提供する。
【0006】
また、本発明は、ユーザの特定要求に対応して多様な情報を提供することによってユーザの便宜性を向上させるように、相異する装置間のデータ交換装置及び方法を提供する。
【0007】
また、本発明は、インフォテインメントのための車両用ヘッドユニットとモバイル装置間のデータ交換装置及び方法を提供する。
【0008】
また、本発明は、それぞれの装置ごとに、相異するユーザインターフェースを混用して使用することができる装置及び方法を提供する。
【図面の簡単な説明】
【0009】
【
図1】本発明の実施形態による車両用ヘッドユニットとモバイル装置間の通信のための内部構造図である。
【
図2】
図1のウェブサーバとウェブブラウザで実行されるウェブアプリケーションと、第2の装置内で実行されるネイティブアプリケーションとの通信を具体化した図である。
【
図3】本発明の一実施形態による制御装置(Control Device)が制御ポイント(Control Point)装置にウェブアプリケーションを提供する過程を示した図である。
【
図4】本発明の他の実施形態による制御ポイント装置が第3のユーザインターフェースサーバからネイティブアプリケーションユーザインターフェースを受信する過程を示した図である。
【
図5】本発明の実施形態による制御装置が提供するサービスリストに対する情報を示した図である。
【
図6】本発明の他の実施形態による第1の装置と第2の装置間でネイティブアプリケーションを利用した通信を具体化した図である。
【
図7】本発明のさらに他の実施形態による制御ポイント装置がネイティブアプリケーションユーザインターフェースを受信する過程を示した図である。
【発明を実施するための形態】
【0010】
以下、本発明の望ましい実施形態は、添付の図面を参照して詳細に説明する。下記説明では、具体的な構成素子などのような特定事項が示されているが、これは本発明のより全般的な理解を助けるために提供されているだけで、このような特定事項が本発明の範囲内で所定の変形あるいは変更できることはこの技術分野で通常の知識を有する者にとっては明らかである。また、本発明を説明するにあって、本発明と関連した公知技術に対する具体的な説明が本発明の要旨を必要もなく不明瞭にすることができると判断される場合にはその詳細な説明を省略する。
【0011】
本発明は、車両用ヘッドユニットとモバイル装置間の統一されたデータ交換方式を提供し、本発明の一実施形態では、このようなデータ交換方式に基づいて車両用ヘッドユニットがモバイル装置に直接ウェブユーザインターフェースを提供したり、ウェブユーザインターフェースを提供しない場合には、モバイル装置のモバイルアプリケーションを駆動してユーザインターフェースを提供する。本発明の他の実施形態では、このようなデータ交換方式に基づいて、モバイル装置に接続された第3のユーザインターフェースサーバから動的にユーザインターフェースを提供する。
【0012】
従って、モバイル装置でウェブブラウザを通して車両用ヘッドユニットと通信したり、モバイル装置内に保存されたモバイルアプリケーションを通して車両用ヘッドユニットと通信することができるようになる。特に本発明によると、モバイル装置が車両用ヘッドユニットと通信する時、ユーザは車両製造業者から提供される制御ユーザインターフェースとモバイル製造業者から提供されるモバイルアプリケーション制御ユーザインターフェースを同時に使用することができる。従って、車両に乗っているユーザが、そのユーザの特定要求に適しているインフォテインメントをモバイル装置または車両用ヘッドユニットを通して受信することで楽しむことができる。
【0013】
上記のような動作を
図1を参照して説明する。
図1は、本発明の実施形態によって第1の装置と第2の装置間の通信において、ウェブアプリケーションとネイティブアプリケーションを混用して使用できるアーキテクチャー及びインターフェースを示した図である。本発明の実施形態では、第1の装置が車両用ヘッドユニット(Head Unit)であり、第2の装置はモバイル装置である場合を例に挙げることができるが、反対に、第1の装置がモバイル装置である場合は、第2の装置は車両用ヘッドユニットになる。第1の装置100は、第2の装置130にウェブアプリケーションを提供できるウェブサーバ110及びUniversal Plugand Play(UPnP)スタック(Stack)120を含む。
【0014】
ウェブサーバ110は、第2の装置130に伝送されたウェブアプリケーションと通信する役割をする。また、第1の装置100に存在するUPnPスタック(Stack)120は、周りの第2の装置を発見でき、第2の装置130に第1の装置100が提供するサービスに対する情報を伝達する。上記サービスに対する情報は、UPnPアクション(Action)に対する応答、あるいは装置デスクリプション(Device Description)内に記述されて提供できる。
【0015】
第2の装置130は、第1の装置100からウェブアプリケーションを受信してユーザに見せることができるウェブブラウザ140を有している。
【0016】
また、第2の装置130は、第1の装置100のウェブサーバ110が上記ウェブアプリケーションを提供できない時に、第1の装置100のウェブサーバ110と通信できるネイティブアプリケーション150を有することができる。追加的に、ネイティブアプリケーション150は、自立的に定義されたプロトコルとインターフェースに基づいてウェブサーバ110ではなくネイティブアプリケーション通信モジュール190と通信できる。
【0017】
また、第2の装置130もUPnPスタック(Stack)160を含み、そのスタック160は、第1の装置100を発見でき、第1の装置100に第1の装置100が提供するサービスリストを要請できる。第1の装置100から受信したサービスリストに対する情報は、全体、あるいは部分的にウェブブラウザ140内のウェブアプリケーションか、またはネイティブアプリケーション150に伝送されることができる。
【0018】
ユーザインターフェースサーバ(UI Server)170は、ネイティブアプリケーション150が第1の装置100と通信するためのユーザインターフェースを要求する時、ネイティブアプリケーション150で表現できるユーザインターフェースに対するプロファイルを伝達できる。ユーザインターフェースサーバ170は、論理的モジュールとして、第1の装置100あるいは第2の装置130の内部に存在することができ、また、第1の装置100と第2の装置130の内部ではなく第3の外部サーバに存在することもできる。
【0019】
上記のような構造を有することによって、第1の装置100ではウェブユーザインターフェースを提供して、第2の装置130または第2の装置130に接続した第3のサーバ、例えば、ユーザインターフェースサーバ170ではネイティブアプリケーションユーザインターフェースを提供しても、このようなそれぞれのユーザインターフェースを混用して使用することが可能になる。
【0020】
以下、第1の装置100で第2の装置130にウェブアプリケーション提供に関する情報を送る方法及びステップ、上記提供された情報を第2の装置130で分析して適切なウェブあるいはネイティブアプリケーションを選択して実行する方法及びステップ、上記実行されたアプリケーションが第1の装置と通信する方法及びステップに対して説明する。このために
図2を参照して説明する。
【0021】
図2は、
図1のウェブサーバとウェブブラウザで実行されているウェブアプリケーションと第2の装置内で実行されるネイティブアプリケーション間の通信プロセスを具体化した図である。
【0022】
まず、第2の装置130を見ると、第2の装置プラットホーム(platform)200を含み、第2の装置プラットホーム200は、HTTPプロトコル通信をサポートする。上記HTTPプロトコル通信をサポートするHTTPプロトコルモジュールは、第1の装置100に情報を伝達できるプールモジュール(Pull Module)(Sender)205と第1の装置100から情報を受信することができるプッシュモジュール(Push Module)(Receiver)210を含む。
【0023】
また、第2の装置130は、ウェブブラウザ140を含み、ウェブブラウザ140は、第1の装置100のウェブサーバ110から受信したウェブアプリケーション215を実行させることができる。ウェブアプリケーション215は、ウェブブラウザ140のジャバスクリプト220のエンジンを通じて、HTTPプロトコルモジュールのプールモジュール(Pull Module)(Sender)205を通してHTTP要請メッセージを第1の装置100に伝達できる。
【0024】
また、第2の装置130内で動作するネイティブアプリケーション150は、第2の装置プラットホーム200で提供するHTTPクライアントモジュールのネイティブ(Native)API225を通して、HTTPプロトコルをハンドリングすることができる。ここで、ネイティブAPI225は、HTTPプロトコル通信のプールモジュール205を通して、第1の装置100のウェブサーバ110にネイティブアプリケーション150で要請する内容を伝達できる。上記要請メッセージは、GET、POST、PUT、DELETEのようなHTTPヘッダーメッセージに基づいて、第1の装置100内のウェブサーバ110に情報を伝達したり要請することができる。
【0025】
第1の装置100から、第2の装置130で各々実行されるウェブアプリケーションあるいはネイティブアプリケーション150に情報を伝達(Push)しようとする時、一般的に、HTML5で提供するウェブソケット(Web Socket)方式あるいはサーバイベント(Server Event)方式を通して伝えられることができる。第2の装置130内のHTTPクライアントモジュールは、必ずウェブサーバ110からプッシュ方式で伝達しようとする情報を受信できるネイティブAPI225を含まなければならない。
【0026】
以下では、本発明の他の実施形態で第1の装置と第2の装置間にネイティブアプリケーションを利用した通信を具体化して
図6に示す。
【0027】
図6では、ネイティブアプリケーション600がHTTP関連ネイティブ(Native)API605を使用して通信し、相異する特定プロトコルに対しては、相異するネイティブAPI610を使用して通信する場合を示している。ここで、ウェブブラウザ615をはじめ、他の構成部は
図2と同様に動作する。
【0028】
図3は、本発明の制御装置が制御ポイントにユーザインターフェースを有しているウェブアプリケーションを提供する時のフローチャートを示した図である。特に、
図3は、本発明の一実施形態によって制御装置が制御ポイントにウェブアプリケーションを提供する過程を示している。ここで、制御装置は第1の装置に該当して、制御ポイントは第2の装置に該当する。
【0029】
図1で示したように、制御装置と制御ポイントはUPnPスタックを含む。
図3で制御装置100はUPnP制御装置として役割をし、制御ポイント130はUPnP制御ポイントとして役割をする。
【0030】
制御ポイント130は、ステップ300で、装置ディスカバリ及びデスクリプション動作を通して制御装置100を発見する。その後、制御ポイント130は、ステップ305で、発見された制御装置100にサービスリストを要請する。このようなサービスリストの要請のために‘GetServiceList SOAP Action’を伝達する。上記SOAP Actionは、制御装置100が提供するサービスに対するリストを要請するメッセージであり、これに対する応答で、制御装置100は、ステップ310で制御ポイント130にサービスリストを提供する。このようなサービスリスト提供のために‘A_ARG_TYPE_ServiceList'を伝達する。このようなサービスリストには、ステップ315でウェブアプリケーションが提供されるか否かが含まれる。
【0031】
ここで、上記サービスリストは、
図5に示されたように、それぞれのサービスを有して、それぞれのサービスは、サービスID510、名前515、そして制御装置100が上記サービスに対してウェブアプリケーション520を提供できるか否かに対する情報525、制御装置100がウェブアプリケーションを提供できる場合に上記サービスに対するウェブアプリケーションにアクセスできるURLアドレス530も提供できる。
【0032】
ここで、制御装置100が上記サービスに対してウェブアプリケーション520を提供できるか否かに対する情報525に対するエレメント(Element)は相異する方式で表現できる。上記サービスに対するウェブアプリケーション520にアクセスできるURLアドレス530が存在する場合には、ウェブアプリケーション520の提供が可能であるという表現と考えることができるので、具現によって情報525を省略して表現することができる。
【0033】
上記サービスリスト情報を受信した制御ポイント130は、上記サービスリストのうち所望のサービスをユーザが選択できるように画面に見せる。したがって、制御ポイント130のユーザはその中一つのサービスを選択するようになる。
【0034】
ステップ320で、サービスが選択された場合、制御ポイント130は、ステップ325で、選択されたサービスがウェブアプリケーションを提供できるか否かをサービスリスト情報に基づいて判断する。すなわち、選択されたサービスに対するウェブアプリケーションを提供するか否かを判断する。
【0035】
もし、制御ポイント130からして、ウェブアプリケーションを制御装置100から受信することができると、
図5のように上記サービスリスト情報からウェブアプリケーションURL情報を抽出する。そして、ステップ330で制御ポイント130内でデフォルトとして決められたウェブブラウザ140を実行する。ウェブブラウザが駆動されることによって、制御ポイント130は、ステップ335及びステップ340で、ウェブブラウザ140に上記抽出されたURL情報を伝達して、ウェブブラウザ140が制御装置100のウェブサーバ110からウェブアプリケーションを要請して受信する。次に、ステップ345で、ウェブアプリケーションをレンダリングしてそのウェブアプリケーションをウェブブラウザ140内で実行する。したがって、実行されたウェブアプリケーションは、ユーザに表示され、制御ポイント130は、ステップ350で、上記ウェブアプリケーションを通して制御装置100と通信できるようになる。
【0036】
一方、
図4は、本発明の他の実施形態によって、制御ポイントが第3のネイティブユーザインターフェースサーバからネイティブアプリケーションユーザインターフェースを受信する過程を示している。
図4においても、上記
図3のように制御装置と制御ポイント装置はUPnPスタックを含み、ネイティブユーザインターフェースサーバは、ネイティブアプリケーションユーザインターフェースサーバとしての役割をする。
【0037】
図4を参照すると、ステップ400乃至ステップ415は、
図3のステップ300乃至ステップ315における動作と同一であるため、その具体的な説明は反復しない。従って、制御ポイント130は
図3で説明したように、制御装置100で提供する
図5で示すようなサービスリストを受信することができ、制御ポイントで、何れか一つのサービスを選択できるように受信したサービスリストを表示する。
【0038】
制御ポイント130は、ステップ420で、選択されたサービスがウェブアプリケーションを提供できるか否かを受信したサービスリスト情報に基づいて判断する。すなわち、ウェブユーザインターフェースが提供されたか否かを判断する。もし、制御ポイント130が制御装置100からウェブアプリケーションを受信できないか、あるいは、受信できてもネイティブアプリケーションを通して制御装置100と通信しようとする場合、制御ポイント130は、ステップ425で制御ポイント130が選択したサービスと関連したネイティブアプリケーションを実行する。
【0039】
次に、実行されたネイティブアプリケーションは、ユーザインターフェースサーバ170に、ステップ430のように、上記選択されたサービス情報と上記サービスを提供する制御装置100に対する情報を伝達することで、ステップ435でユーザインターフェースサーバ170にネイティブアプリケーションUIを要請する。制御装置100に対する情報は、一例としてUPnP装置デスクリプション(Device Description)内の<modelName>や<modelNumber>などのような情報があり得る。
【0040】
ネイティブアプリケーションUI要請に対応して、ユーザインターフェースサーバ170は、ステップ430のような情報に基づいてネイティブアプリケーションUIを生成してステップ440で伝送する。ここで、ユーザインターフェースサーバ170は、ネイティブアプリケーション実行によるネイティブアプリケーションユーザインターフェースを提供するサーバである。
【0041】
上記ネイティブアプリケーションUIを受信したネイティブアプリケーションは、ステップ445で上記ネイティブアプリケーションUIをレンダリングする。上記選択されたサービスに対する制御ポイント130内のネイティブアプリケーションと制御装置100が通信するためには、制御装置100内の通信モジュールが実行されなければならない。
【0042】
仮に、制御装置100内で予め実行されていないと、ステップ446でサービス開始を指示する。このために制御ポイント130は‘StartService UPnP SOAP Action’メッセージを制御装置100に伝送することで上記通信モジュールを実行させる。この時、上記SOAP Actionのパラメータとしてステップ410で受信したサービスリストのうち、
図5のように実行させようとするサービスに対するサービスID510が含まれる。上記‘SOAP Action’メッセージが制御装置100に伝えられると、制御装置100は、通信モジュール190を含んで制御ポイント130が選択したサービスに関連したもう一つのモジュールを共に駆動させる。仮に、関連したもう一つのモジュールが駆動される必要がないと駆動させなくても良い。そして、ステップ448でこのようなメッセージの伝送に対応した結果を制御ポイント130に提供する。
【0043】
一方、本発明のさらに他の実施形態によって制御ポイント装置がネイティブアプリケーションユーザインターフェースを受信する過程を示すと
図7のようになる。
【0044】
図7では、制御装置100内の通信モジュール190だけを駆動させる場合を例示している。従って、ステップ446における上記‘StartService UPnP SOAP Action’の代わりに
図7のステップ750のように通信モジュールの開始を指示するメッセージが伝えられることができる。このために‘LaunchApplication UPnP SOAP Action’メッセージが利用されることができる。このようなメッセージを通して上記制御ポイント130内のネイティブアプリケーション150が通信モジュール190と通信できる環境を用意することができ、通信モジュール内で決められた自体プロトコル及びインターフェース例えば、ネイティブAPI610を通して上記選択されたサービスに関連した他のモジュールを制御装置100内で実行させることができる。
【0045】
従って、制御ポイント130は、ステップ450で、上記ネイティブアプリケーションUIをレンダリングするネイティブアプリケーション150を通して制御装置100と通信できる。上記制御ポイント130が選択したサービスをこれ以上遂行する必要がないと、ステップ425でサービス終了を指示する。このようなサービス終了の指示のために‘StopService UPnP SOAP Action’メッセージを利用する。このようなメッセージは、上記通信モジュールを停止させることができ、上記中断されたサービスに関連した他のモジュールも停止させる役割をする。この時、上記SOAP Actionのパラメータとして、ステップ410で、受信したサービスリストのうち中断させようとするサービスに対するサービスID510が
図5で示すように挿入されるようになる。そして、ステップ454で、このようなサービス終了のための上記メッセージの伝送に対応する結果を制御ポイント130に提供する。
【0046】
一方、上記
図4のようなサービス終了のためのメッセージの代わりに、
図7では通信モジュール150だけを中止させることができるメッセージを送ることができる。従って、制御ポイント130は、通信モジュール150内で決められた自体プロトコル及びインターフェースを通して、現在、制御装置100内で実行されている上記選択されたサービスに関連した他のモジュールを中止させることができる。そして、制御ポイント130は、ステップ765で通信モジュール停止のためのメッセージを伝送する。このために制御装置100内で通信モジュール190だけを中止させることができる‘TerminateApplication UPnP SOAP Action’702を伝送する。制御ポイント130は、このような通信モジュール停止のためのメッセージ伝送に対応して、ステップ770で結果を受信する。こうして、制御ポイント130内のネイティブアプリケーション150は通信モジュール190との通信を中断できる。
【0047】
本発明によると、車両用ヘッドユニットとモバイル装置間の通信において車両製造業者から提供されるウェブアプリケーションを通したユーザインターフェース(UI)とモバイル装置製造業者から提供されるモバイルアプリケーションを通したユーザインターフェースを同時にサポートすることができる。
【0048】
従って、本発明によると、相異する装置で各々ウェブユーザインターフェース及びネイティブアプリケーションユーザインターフェースを提供してもこれを混用して使用することが可能な利点がある。
【0049】
また本発明によると、モバイルプラットホームからしては、単一サービスに対して状況によりウェブアプリケーションとモバイルアプリケーションを動的に選択して駆動できる環境を確立することができる。
【0050】
以上のように例示された図面を参照して、本発明の実施形態を説明したが、本発明が属する技術分野で通常の知識を有する者は、本発明がその技術的思想や必須な特徴を変更することなく他の具体的な形態で実施可能であることが分かる。したがって、以上で記述した実施形態はあらゆる面で例示的なことであり、限定的でないことに理解すべきである。
【符号の説明】
【0051】
100 制御装置
110 ウェブサーバ
130 制御ポイント
140 ウェブブラウザ
150 ネイティブアプリケーション
150 通信モジュール
160 スタック
170 ユーザインターフェースサーバ
190 ネイティブアプリケーション通信モジュール
200 第2の装置プラットホーム
205 プールモジュール
210 プッシュモジュール
215 ウェブアプリケーション
220 ジャバスクリプト