(57)【特許請求の範囲】
【請求項１】
クライアントと接続するためのサーバによる方法であって、
デバイスディスカバリ手順を通して前記クライアントを発見するステップと、
前記クライアントに前記サーバのデバイス情報を伝送するかまたは前記クライアントから前記クライアントのデバイス情報を受信するステップと、
前記クライアントと接続するステップと、
前記接続を通してユニバーサルプラグアンドプレイ（ＵＰｎＰ）動作を実行するステップと、を含み、
前記デバイス情報は、カーコネクティビティーコンソーシアム（ＣＣＣ）サービスであることを示す組織的に一意な識別子（ＯＵＩ）と、ＯＵＩタイプと、サブエレメントＩＤと、TmApplicationServerサポート可否に関する情報と、TmClientProfileサポート可否に関する情報と、TmNotificationServerサポート可否に関する情報及びポートナンバーのうちの少なくとも一つを含むクライアントと接続するためのサーバによる方法。
【請求項２】
前記クライアントが要請したＵＰｎＰデバイスディスクリプション情報を伝送するステップをさらに含む
ことを特徴とする請求項１に記載のクライアントと接続するためのサーバによる方法。
【請求項３】
前記デバイス情報は、
前記クライアントのＩＰ（Internet Protocol）と前記デバイスディスカバリ手順を通して取得したポートナンバーと、デバイスディスクリプション拡張マークアップ言語（ＸＭＬ）のうちの少なくとも２個以上を結合して生成されたユニフォームリソースロケータ（ＵＲＬ）情報を含む
ことを特徴とする請求項１に記載のクライアントと接続するためのサーバによる方法。
【請求項４】
前記ＵＲＬ情報は、前記クライアントのデバイスディスクリプションの位置を指示する
ことを特徴とする請求項３に記載のクライアントと接続するためのサーバによる方法。
【請求項５】
前記サブエレメントＩＤは、ミラーリンクＵＰｎＰ関連情報を含むことを称する
ことを特徴とする請求項１に記載のクライアントと接続するためのサーバによる方法。
【請求項６】
サーバと接続するためのクライアントによる方法であって、
前記サーバとデバイスディスカバリ手順を遂行するステップと、
前記サーバから前記サーバのデバイス情報を受信するかまたは前記サーバに前記クライアントの装置情報を伝送するステップと、
前記サーバにＩＰを割り当てるステップと、
前記サーバと接続するステップと、
前記接続を通してユニバーサルプラグアンドプレイ（ＵＰｎＰ）動作を開始するステップと、を含み、
前記デバイス情報は、カーコネクティビティーコンソーシアム（ＣＣＣ）サービスであることを示す組織的に一意な識別子（ＯＵＩ）と、ＯＵＩタイプと、サブエレメントＩＤと、TmApplicationServerサポート可否に関する情報と、TmClientProfileサポート可否に関する情報と、TmNotificationServerサポート可否に関する情報及びポートナンバーのうちの少なくとも一つを含むサーバと接続するためのクライアントによる方法。
【請求項７】
前記サーバにＵＰｎＰデバイスディスクリプション情報を要請するステップをさらに含む
ことを特徴とする請求項６に記載のサーバと接続するためのクライアントによる方法。
【請求項８】
前記デバイス情報は、
前記クライアントのインターネットプロトコル（ＩＰ）と前記デバイスディスカバリ手順を通して取得したポートナンバーと、デバイスディスクリプション拡張マークアップ言語（ＸＭＬ）のうち少なくとも２個以上を結合して生成されたユニフォームリソースロケータ（ＵＲＬ）情報を含む
ことを特徴とする請求項６に記載のサーバと接続するためのクライアントによる方法。
【請求項９】
前記ＵＲＬ情報は、前記クライアントのデバイスディスクリプションの位置を示す
ことを特徴とする請求項８に記載のサーバと接続するためのクライアントによる方法。
【請求項１０】
前記サブエレメントＩＤは、ミラーリンクＵＰｎＰ関連情報を含むことを示す
ことを特徴とする請求項６に記載のサーバと接続するためのクライアントによる方法。
【請求項１１】
前記クライアントと接続するための前記サーバであって、
前記サーバは、請求項１乃至請求項５のうち何れか一項に記載の方法によって動作するように構成される
ことを特徴とするサーバ。
【請求項１２】
前記サーバと接続するための前記クライアントであって、
前記クライアントは、請求項６乃至請求項１０のうち何れか一項に記載の方法によって動作するように構成される
ことを特徴とするクライアント。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はクライアントとサーバとの間の接続方法及び装置に関する。
【背景技術】
【０００２】
インフォメーションテクノロジー（Information Technology；ＩＴ）技術を使用して車両を制御するための電子装置がますます活用されている。併せて、自動車に適用される電気及び電子装備の数と複雑度も増加している。
【０００３】
例えば、ヘッドユニットは、最も重要な装置の一つとして認識されている。ヘッドユニットは、主に車両のフロントシートの中間に位置しており、エアコン（air conditioner）及びヒータなどのような温度調節装置、エンターテイメントシステム、後方カメラディスプレイ、及びナビゲーションシステムなどが統合された総合制御装置である。
上記ヘッドユニットを操作できるボタンが安全のためにユーザハンドルに付着されていることが多く、このボタンはヘッドユニットの一部と考えられる。
【０００４】
ユーザは、運転する前、運転中、運転を終える時点に達するまで、ヘッドユニットを通して多様な車内装置を制御する。したがって、このようなヘッドユニットのユーザインターフェース（以下、‘ＵＩ’と称する）は、ユーザが運転中にも容易かつ安全に作動できるように簡素化され、特に説明がなくてもヘッドユニットの制御方法が分かるように直観的である必要がある。
【０００５】
携帯電話及びスマートフォンはヘッドユニットとは異なる。例えば、スマートフォンは、ユーザがＵＩを見られ、手を使用してＵＩを操作する。このために、ユーザは、目でスマートフォンの画面を持続的に注視する。したがって、スマートフォンのユーザは、車運転中にスマートフォンを現在安全に操作できない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、少なくとも上述した問題点及び／又は課題に取り組み、少なくとも以下の便宜を提供することにある。
本発明は、車運転中に運転者の安全を考慮してモバイルフォンを安全に操作する方法及び装置を提供する。
本発明は、移動端末とヘッドユニットとの間の接続時間及び必要とするリソースを減少させる方法及び装置を提供する。
【課題を解決するための手段】
【０００７】
本発明の実施形態によれば、サーバとクライアントとの接続方法を提供する。上記方法は、
上記サーバが、デバイスディスカバリ手順を通してクライアントを発見するステップと、上記クライアントに上記サーバの装置関連情報を伝送するかまたは上記クライアントから上記装置関連情報を受信するステップと、上記クライアントと接続するステップと、  上記接続を通して、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）動作を遂行するステップとを含む。
【０００８】
本発明の実施形態によれば、サーバとクライアントとの接続方法を提供する。上記方法は、上記クライアントが上記サーバとデバイスディスカバリ手順を遂行するステップと、上記サーバの装置関連情報を受信するかまたは上記サーバに上記装置関連情報を伝送するステップと、上記サーバにＩＰを割り当てるステップと、上記サーバと接続するステップと、
上記接続を通して、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）動作を開始するステップと、を含む。
【０００９】
本発明の実施形態によれば、サーバとクライアントとの接続装置を提供する。上記装置は、
上記サーバが、デバイスディスカバリ手順を通してクライアントを発見し、上記クライアントに上記サーバの装置関連情報を伝送するかまたは上記クライアントから上記装置関連情報を受信する受信部と、上記クライアントと接続し、上記接続を通してユニバーサルプラグアンドプレイ（ＵＰｎＰ）動作を遂行する制御部とを含む。
【００１０】
本発明の実施形態によれば、サーバとクライアントとの接続装置を提供する。上記装置は、
上記クライアントが上記サーバとデバイスディスカバリ手順を遂行し、上記サーバの装置関連情報を受信するかまたは上記サーバに上記装置関連情報を伝送する伝送部と、
上記サーバにＩＰを割り当て、上記サーバと接続し、上記接続を通してユニバーサルプラグアンドプレイ（ＵＰｎＰ）動作を開始する制御部とを含む。
【図面の簡単な説明】
【００１１】
本発明の実施形態の上述した及び他の様相、特徴、及び利点は、以下の添付図面が併用された後述の詳細な説明から、より一層明らかになるであろう。
【図１】本発明が適用されるＷｉ−Ｆｉディスプレイ（ＷＦＤ）の構造図である。
【図２】本発明が適用されるＷＦＤの設定過程を示す図である。
【図３】本発明の第１の実施形態によるＷＦＤ構造図である。
【図４】本発明の第１の実施形態によるＷＦＤの設定過程を示す図である。
【図５】本発明の第２の実施形態によるＷＦＤ構造図である。
【図６】本発明の第２の実施形態によるＷＦＤの設定過程を示す図である。
【図７】本発明の第２の実施形態によるＷＦＤシンクデバイス及びＷＦＤソースデバイス間の動作を示す図である。
【図８】本発明の第３の実施形態によるＷＦＤの設定過程を示す図である。
【図９】本発明の第４の実施形態によるＷＦＤの設定過程を示す図である。
【図１０】本発明の第４の実施形態によるＷＦＤ構造図である。  図面における同様な構成要素に対しては、他の図面に表示されても、可能な限り同一の符号及び番号を共通で使用するものとする。
【発明を実施するための形態】
【００１２】
添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供するものであり、この理解を助けるために様々な特定の詳細を含むが、単なる実施形態に過ぎない。従って、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【００１３】
本発明は、運転中の安全のために特化されたＵＩを含むヘッドユニットを使用して携帯電話を操作することがスマートフォンの持続的な使用と、運転者の安全を同時に達成できる方法になるであろう。
【００１４】
このために本発明は、自動車のヘッドユニットと携帯電話との間にネットワーク接続（例えば、有線接続、無線接続）を提供し、携帯電話の機能を、ヘッドユニットを通して制御し、携帯電話のＵＩをヘッドユニットに伝送するためのミラーリング技術を提案する。
【００１５】
図１は、本発明が適用されたＷｉ−Ｆｉダイレクト（ＷＦＤ）システムの構造図である。
ＷＦＤシステムは、ＷＦＤソース１００とＷＦＤシンクデバイス１２０で構成され、ＷＦＤソースデバイス１００のディスプレイで見られる画面と、再生されるオーディオコンテンツをリアルタイムでＷＦＤシンクデバイス１２０に伝送する。例えば、ＷＦＤソースデバイス１００を携帯電話と仮定し、ＷＦＤシンクデバイス１２０をＴＶと仮定する場合に、携帯電話を通して視聴していたＵＩまたは映画をＴＶのような大画面で視聴することが可能になる。この時、ユーザは、ＷＦＤソースデバイス１００またはＷＦＤシンクデバイス１２０を通してＵＩを制御することが可能であり、後者の場合、ユーザ入力は、ＷＦＤシンクデバイス１２０からＷＦＤソースデバイス１００に伝えられる。
図２は、本発明が適用されるＷＦＤの設定過程を示す図である。
【００１６】
まず、ＷＦＤソースデバイスは、ステップ２０１で、ＷＦＤデバイスディスカバリ過程を通して、ＷＦＤをサポートする装置（例えば、ＷＦＤシンクデバイス）を発見し、ステップ２０３で、ＷＦＤサービスディスカバリ過程を通して、追加的な情報を確認する。ＷＦＤソースデバイスは、ステップ２０５で、ＷＦＤ接続セットアップ過程を通して、ＩＰチャネルと伝送制御プロトコル（ＴＣＰ；Transmission Control Protocol）チャネルを設定し、ステップ２０７で、ＷＦＤ性能交渉（Capability Negotiation）過程をリアルタイムストリーミングプロトコル（ＲＴＳＰ；Real Time Streaming Protocol）を介して実行する。以後、ＷＦＤソースデバイスは、ステップ２０９で、ＲＴＳＰプロトコルを通してＷＦＤセッションを確立した以後に、ＷＦＤシンクデバイス１２０がＷＦＤソースデバイス１００を制御できるように、ステップ２１１でＲＴＳＰプロトコルを介してユーザ入力バックチャネル（ＵＩＢＣ；User Input Back Channel）を確立する。以後、ＷＦＤソースデバイスは、ステップ２１３でデータ伝送時に、チャネル保護のためにＲＴＳＰプロトコルを通してリンクコンテンツ保護（Link Content Protection）過程を経て、ステップ２１５及びステップ２１７で、ＷＦＤソースデバイス１００のコンテンツをＷＦＤシンクデバイス１２０に伝送する。
【００１７】
ＷＦＤは、ソースデバイス１００のディスプレイ画面をシンクデバイス１２０に伝送するために使用されたが、主に家庭内の携帯電話のコンテンツをＴＶのような大画面ディスプレイに伝達するための目的で使用されてきた。しかし、ＷＦＤを自動車に適用するには下記のような問題点がある。
【００１８】
１．自動車のヘッドユニット関連規制によって、規制に合わない特定アプリケーションは、ミラーリングされないようにする手段が必要である。
２．ＷＦＤソースデバイスのハードウェアで具現されたボタンは、ディスプレイ外部に存在するために、ＷＦＤシンクデバイスに伝送されないので、このような動作（e.g. Terminate application, Change application layer-foreground, 及びbackground）を制御できる方法が必要である。
３．ＷＦＤシンクデバイスからＷＦＤソースデバイスにデータを伝送できる共用チャネルが必要であるが、現在はこのようなチャネルが存在しない。
上記データの一例は下記の＜表１＞の通りである。
【００１９】
【表１】
0006356155.tif 000002
【００２０】
４．自動車で、ヘッドユニットを通して携帯電話で通話を利用しようとする場合、ＷＦＤシンクデバイスからＷＦＤソースデバイスに音声を送られるチャネルが必要であるが、現在はこのようなチャネルが存在しない。
【００２１】
このために本発明は、ホームネットワーク技術であるユニバーサルプラグアンドプレイ（ＵＰｎＰ）を適用して、ＵＰｎＰ技術を適用する場合に発生される技術的な障壁を除去しようとする。
【００２２】
図３は、本発明の第１の実施形態によるＷＦＤ構造図である。
図３で、任意にＷＦＤシンクデバイス３２０及びＷＦＤソースデバイス３００と表記したが、これは適当な名称（例えば、ミラーリンククライアント（Mirrolink Client）及びミラーリンクサーバ（Mirrorlink Server））に変更され得る。
【００２３】
ＵＰｎＰ TmServer ＣＰ３２２は、ＷＦＤシンクデバイス３２０内部に存在し、Ｗｉ−Ｆｉディスプレイシンクモジュール３２４とは別途存在する。ＵＰｎＰ TmServer ＣＰ３２２は、Ｗｉ−Ｆｉディスプレイシンクモジュール３２４とは別途のＷｉ−Ｆｉ  Ｐ２Ｐ接続を使用して、ＷＦＤソースデバイス３００内のＵＰｎＰ TmServer３０２を発見し、制御できる。Ｗｉ−Ｆｉディスプレイシンクモジュール３２４及びＷＦＤディスプレイソースモジュール３０４は、Ｗｉ−Ｆｉ Ｐ２Ｐ接続３２８、Ｗｉ−Ｆｉ Ｐ２Ｐ接続３０８を各々使用し、ＵＰｎＰ TmServer ＣＰ３２２及びＵＰｎＰ TmServer３０２はＷｉ−Ｆｉ Ｐ２Ｐ接続３２６、Ｗｉ−Ｆｉ Ｐ２Ｐ接続３０６を各々使用する。
【００２４】
また、ＷＦＤモジュール（例えば、Ｗｉ−Ｆｉディスプレイシンクモジュール３２４及びＷＦＤディスプレイソースモジュール３０４）とＵＰｎＰモジュール（例えば、ＵＰｎＰ TmServer ＣＰ３２２、ＵＰｎＰ TmServer３０２）は完璧に独立的なプロセスで動作するので、相互にどの情報もやり取りしない。
【００２５】
ＵＰｎＰ TmServer ＣＰ３２２は、ＵＰｎＰ TmServer３０２からアプリケーションリストを受信し、上記アプリケーションリストを参照して、特定アプリケーションを実行または中止させることができ、アプリケーションステータス（forground running or background running）を変更できる。
【００２６】
このような方法で、ＷＦＤソースデバイス３００内の共通データバス（ＣＤＢ；Common  Data Bus）３０３、ブルートゥース（登録商標）（ＢＴ；Bluetooth（登録商標））（ＢＴ）装置３０１及びその他のローカルアプリケーション３１０を実行または中止させることができ、同時にＷＦＤシンクデバイス３２０内部に存在するＢＴ３２１、ＣＤＢ３２３モジュールも制御する。これを通じて別途の音声及びデータチャネルを生成または除去できる。
【００２７】
追加的に、ローカルアプリケーション３１０には、リアルタイム伝送プロトコル（ＲＴＰ）サーバ／クライアントが含まれ、ＵＰｎＰ TmServer ＣＰ３２２は、ＷＦＤソースデバイス３００内部のＲＴＰサーバ／クライアントとＷＦＤシンクデバイス３２０のＲＴＰサーバ／クライアントを制御して、ＢＴを使用しないオーディオチャネルを生成でき、これは上記ＢＴを使用したオーディオチャネルの代わりに使用され得る。
【００２８】
図４は、本発明の第１の実施形態によるＷＦＤの設定過程を示す図である。
図４で、ＷＦＤとＵＰｎＰは各々別途に動作する。ＷＦＤプロセス４１０及びＵＰｎＰプロセス４２０は、ＷＦＤ及びＵＰｎＰ TmServerで定義されたステップに従う。ＷＦＤプロセス４１０は図２のそれと同一である。
ＵＰｎＰプロセス４２０は次のように動作する。
【００２９】
まず、ＷＦＤソースデバイスは、ステップ４２１でデバイスディスカバリ過程を通して、Ｗｉ−Ｆｉ Ｐ２Ｐをサポートする装置（例えば、ＷＦＤシンクデバイス）を発見し、ステップ４２２で、Ｗｉ−Ｆｉ Ｐ２Ｐサービスディスカバリ過程を通して、ＷＦＤシンクデバイスとＷＦＤソースデバイスとの間にサービス情報を共有できる。以後、ＷＦＤソースデバイスは、ステップ４２３で、ＷＦＤ接続セットアップ過程を通して、ＩＰとＴＣＰチャネルを設定し、ステップ４２４で、ＵＰｎＰデバイスディスカバリ／サービスディスカバリ過程を通して、ＵＰｎＰをサポートする装置を発見し、ＷＦＤシンクデバイスとＷＦＤソースデバイスとの間にＵＰｎＰサービス情報を共有できる。
ステップ４２５では、アプリケーションリストを取得し、ステップ４２６では他のアプリケーション（例えば、ＣＤＢ）を開始する。
【００３０】
ＵＰｎＰプロセス４２０のように動作するためにＵＰｎＰは、パケット伝送のためにＷｉＦｉ Ｐ２Ｐ技術を使用しているが、ＷＦＤで使用しているＷｉＦｉ Ｐ２Ｐの形式と一致しないので、複数のＭＡＣ／ＰＨＹ(Media Access Control／PHYsical) レイヤを駆動して別途に動作させなければならない短所がある。
【００３１】
要するに、既存のＷＦＤシンクデバイスとＷＦＤソースデバイス内部にＵＰｎＰ TmServerを統合して、既存技術の問題点で提示した、アプリケーションフィルタリング問題、ハードウェアで具現されたボタンの制御不可、データ及び音声チャネルが存在しないという問題を解決できる。
【００３２】
図５は、本発明の第２の実施形態によるＷＦＤ構造図である。
本発明の第１の実施形態のように、ＵＰｎＰ TmServer ＣＰ５２２は、ＷＦＤシンクデバイス５２０内部に存在し、Ｗｉ−Ｆｉディスプレイシンクモジュール５２４とは別途存在する。
【００３３】
しかし、ＵＰｎＰ TmServer ＣＰ５２２は、Ｗｉ−Ｆｉディスプレイシンクモジュール５２４と同一のＷｉ−Ｆｉ Ｐ２Ｐ接続を使用して、ＷＦＤソースデバイス５００内のＵＰｎＰ TmServer５０２をＷｉ−Ｆｉディスプレイシンクモジュール５２４とＷｉ−Ｆｉディスプレイソースモジュール５０４との間でやりとりするＲＴＳＰメッセージを使用して発見する。
発見以後のプロセスは、一般ＵＰｎＰ方式と同一である。このようにＵＰｎＰプロセスの一部を、ＲＴＳＰを使用して代替する場合に、下記のような長所がある。
【００３４】
ＵＰｎＰデバイスアーキテクチャ（ＤＡ；Device Architecture）で定義されたアドレッシング及びディスカバリ過程を省略できる。ＵＰｎＰで別途に進行しているＵＰｎＰプロセス４２０は、既にＷＦＤプロセス４１０で遂行された過程である。したがって、ＵＰｎＰプロセス４２０をＷＦＤプロセス４１０に代替することによって不必要な重複を防ぎ、二つの装置の接続時間を短縮させることができる。
【００３５】
ディスクリプションス過程におけるデバイスディスクリプションを受信するステップを省略できる。したがって、拡張マークアップ言語（ＸＭＬ；eXtensible Markup Language）をパッシングする時間及びプロセシングリソースも節約される。
【００３６】
図６は、本発明の第２の実施形態によるＷＦＤの設定過程を示す図である。
ステップ６０１は、ＷＦＤデバイスを発見する過程であり、ＷＦＤでは情報エレメント（ＩＥ；Information  Element）を通して、装置の情報を交換する過程である。ステップ６０１で装置と関連した多様なデバイス情報が交換される。ＩＥは、サブエレメント（ＳＥ；Sub Element）に細分され、それぞれのＳＥは、サブエレメントＩＤに区分される。例えば、サブエレメントＩＤが１である場合は、ＷＦＤデバイス情報を示し、上記サブエレメントＩＤが２である場合はＷＦＤオーディオフォーマット、すなわちＷＦＤデバイスがサポートするオーディオフォーマットを示す。このようにＷＦＤでは総１１個のサブエレメントＩＤを既定義した。
【００３７】
本発明の図５では、ＵＰｎＰ関連モジュールを定義し、上記モジュールは、既存ＷＦＤに定義されていない。したがって、ＷＦＤデバイスは別途の情報がない場合、上記モジュールが含まれているか否か分からない。本発明では、図６のステップ６０１で、相手方装置が上記モジュール（e.g., ＵＰｎＰ TmServer ＣＰ等）を含んでいるか否かが分かるように、新たなデバイス情報を追加した。サブエレメントＩＤの値は１１であり、具体的なフォーマットは、下記＜表２＞及び＜表３＞と同一である。
【００３８】
【表２】
0006356155.tif 000003
【００３９】
【表３】
0006356155.tif 000004
【００４０】
上記情報を交換し、サブエレメントＩＤが１１の値を有するデータを確認することで、ＷＦＤデバイスは、発見された装置が、既存ＷＦＤデバイスであるか、本発明で追加されたモジュールを有している装置であるかを確認することができる。以後、ステップ６０１では、上記情報に基づいて追加されたステップ６１３、６１５、６２３、６２５を遂行するか否かを決定できる。
【００４１】
上記＜表２＞及び＜表３＞は、本発明の実施形態によって可能なデータフォーマットの例示を書いたものであり、同様に、デバイスの特徴（例えば、製造社、モデル名、及び製造年度）も含むことができる。このために、１ビットから４７ビットまでの空間を使用することができる。
【００４２】
ステップ６０３乃至ステップ６１１は、ＷＦＤソースデバイス５００とＷＦＤシンクデバイス５２０との間のＷＦＤセッションを設定する過程を示し、ステップ６０３乃至ステップ６１１は、図２のステップ２０３乃至ステップ２１１のＷＦＤ技術説明と類似であるため、その詳細な説明を省略する。
【００４３】
ステップ６１１を終了した状態で、ＷＦＤソースデバイスとＷＦＤシンクデバイスは、ＲＴＳＰセッションが確立されており、ＵＦＤシンクデバイスの画面をユーザが操作する場合、ユーザ入力をＷＦＤソースデバイスに伝達できるＵＩＢＣチャネルも設定されている状態である。
【００４４】
ステップ６１３以後のハッチングで表記されたステップ６１５、６２３、６２５は、既存のＵＰｎＰのサービスディスクリプション送受信及びアクション制御過程と同一であり、カーコネクティビティーコンソーシアム（ＣＣＣ；Car Connectivity Consortium）で定義したミラーリンク標準のTmServerDeviceのサービスを再使用できる。
ステップ６１５以後の白色で表記されたステップ６１７、６１９、６２１は、図２のステップ２１３乃至ステップ２１７と同一である。
【００４５】
図６で、６１３ステップは、ＷＦＤシンクデバイスが以下のように、ＲＴＳＰで定義されたGET_PARAMETER Methodを使用して、ＷＦＤソースデバイスのデバイス情報の提供を受ける過程である。
上記プロセスに代替するために、図５でのそれぞれのモジュールは、図７の動作を遂行する。
【００４６】
図７は、本発明の第２の実施形態によるＷＦＤシンクデバイス及びＷＦＤソースデバイス間の動作を示す図である。
ＵＰｎＰ TmServer ＣＰは、ステップ７０１で、Ｗｉ−Ｆｉディスプレイシンクモジュールに現在接続されたＷＦＤソースデバイスのデバイス情報（すなわち、追加情報）を要請する。
【００４７】
ステップ７０３で、上記要請を受けたＷｉ−Ｆｉディスプレイシンクモジュールは、ＲＴＳＰを使用してＷｉ−Ｆｉディスプレイソースモジュールに上記追加情報を要請する。
【００４８】
ステップ７０５で、上記要請を受けたＷｉ−Ｆｉディスプレイソースモジュールは、ＷＦＤソースデバイスの追加情報をＵＰｎＰ TmServerに再要請してこれを受信する。
ステップ７０７で、Ｗｉ−Ｆｉディスプレイソースモジュールは、受信した追加情報をＲＴＳＰ形式で変換する。
【００４９】
ステップ７０９で、Ｗｉ−Ｆｉディスプレイソースモジュールは、上記変換された追加情報をＲＴＳＰ応答に含めてＷｉ−Ｆｉディスプレイシンクモジュールに伝送する。
【００５０】
ステップ７１１で、ＵＰｎＰ TmServer ＣＰは、Ｗｉ−Ｆｉディスプレイシンクモジュールから上記変換された追加情報を受信し、上記変換された追加情報に基づいてＵＰｎＰ制御プロセスを遂行する。
【００５１】
ＵＰｎＰ TmServer ＣＰはＵＰｎＰ TmServerからアプリケーションリストを受信し、上記アプリケーションリストを参照して、特定アプリケーションを実行または中止させることができ、アプリケーションステータス（forground or background 動作）を変更できる。
【００５２】
上述した追加情報及び上記情報をＲＴＳＰに伝送するためのデータフォーマットの例は下記のようである。本発明では、提示した情報の他にも既存ＷＦＤデバイスディスカバリ、サービスディスカバリ、性能交渉過程で提供しないデバイス情報は、上記過程と同一の過程を通してＷＦＤデバイスとの間に交換できる。
【００５３】
１．ブルートゥース（登録商標）ＭＡＣアドレス
ＷＦＤは、ＷｉＦｉを使用して、ＷＦＤソースデバイスの映像と音声をＷＦＤシンクデバイスに伝送する技術であるため、ＷＦＤシンクデバイスからＷＦＤソースデバイスに音声が伝えられることができない。これを補完するために、音声を伝送できるチャネルが必要である。このために、本発明では、ＢＴで定義されたＨＦＰ（Hands Free Profile）を使用して音声チャネルを伝送しようとする。そのためにはアドレスが必要であり、これをステップ６１３で伝送できる。
ブルートゥース（登録商標）ＭＡＣアドレスのシンテックスは下記の通りである。
ＲＴＳＰブルートゥース（登録商標）ＭＡＣアドレスデータフォーマット
wfd-upnp-BT-MAC-address = 12*12HEXDIG; CRLF
【００５４】
２．サービスリスト
a)SCPDURL
b)ControlURL
c)EventSubURL
ＲＴＳＰサービスリストデータフォーマットのシンテックスは下記の通りである。
ＲＴＳＰサービスリストデータフォーマット  
【００５５】
wfd-upnp-service-list = "none" / TmApplicationServer SP TmClientProfile SP Tm  NotificationServer CRLF
TmApplicationServer = "none" / SCPDURL SP ControlURL SP EnventSubURL
SCPDURL = "none" / ("http:// source-ip-address/SCPD/")
ControlURL = "none" / ("http:// source-ip-address/Control/")
EventSubURL = "none" / ("http:// source-ip-address/EventSub/")
source-ip-address = IPADDRESS
TmClientProfile = "none" / SCPDURL SP ControlURL SP EnventSubURL
TmNotificationServer = "none" / SCPDURL SP ControlURL SP EnventSubURL
【００５６】
このような方法で交換された情報に基づいて、ＵＰｎＰ TmServer ＣＰは、ＷＦＤソースデバイス内のＵＰｎＰ TmServerを、ＵＰｎＰアクションを呼び出しする方式で制御することができ、ＣＤＢ、ＢＴ及びその他のローカルアプリケーションを実行または中止させることができ、同時にＷＦＤシンクデバイス内部に存在するＢＴ、ＣＤＰモジュールも制御する。これを通じて別途の音声及びデータチャネルを生成または除去できるようになる。
【００５７】
追加的に、ローカルアプリケーションにはＲＴＰサーバ／クライアントが含まれ、ＵＰｎＰ TmServer ＣＰは、ＷＦＤソースデバイス内部のＲＴＰサーバ／クライアントとＷＦＤシンクデバイスのＲＴＰサーバ／クライアントを制御し、ＢＴを使用しないオーディオチャネルを生成でき、これは上記ＢＴを使用したオーディオチャネルの代わり使われることができる。
【００５８】
要するに、既存のＷＦＤシンクデバイスとＷＦＤソースデバイス内部にＵＰｎＰ TmServerを統合し、一部重複プロセスを除去して新規プロセスを導入することで、既存技術の問題点で提示した、アプリケーションフィルタリング問題、ハードウェアで具現されたボタンの制御不可、データ及び音声チャネルが存在しない問題を本発明の第１の実施形態に比べてより効率的に解決できる。
【００５９】
図８は、本発明の第３の実施形態によるＷＦＤの設定過程を示す図である。
本発明の第３の実施形態は、本発明の第２の実施形態と同様であるが、本発明の第２の実施形態のステップ６１３を通してやり取りした情報を、ステップ８０１の情報エレメント（ＩＥ）内のサブエレメント（ＩＤ＝１１）のペイロードを通して伝送するという点で相異する。
【００６０】
本発明の第２の実施形態と同様に、本発明では、提示した情報の他にも既存のＷＦＤデバイスディスカバー、サービスディスカバリ、性能交渉過程で提供しないデバイス情報は、本発明の第３の実施形態でＷＦＤ ＩＥ情報を通してＷＦＤデバイスとの間に交換されることができる。
【００６１】
図９は、本発明の第４の実施形態によるＷＦＤの設定過程を示す。
本発明の第４の実施形態は第３の実施形態と同様であるが、ステップ９０１で交換されるデータの種類において差異があり、既存のＷＦＤプロセスをそのまま使用し、ＵＰｎＰプロセスのうちＳＳＤＰを除外した残りのプロセスもそのまま使用して既存技術の再使用性を高めるという点で相異する。
【００６２】
アドレッシング、シンプルサービスデバイスディスカバリ（ＳＳＤＰ；Simple Service Device Discovery）、デバイスディスクリプション、サービスディスクリプションに続くＵＰｎＰ  DAの過程の中で、デバイスディスカバリ過程をＷＦＤで提供するデバイスディスカバリと併合して、不要に反復するデバイスディスカバリプロセスを除去することによって、全体セットアップ過程で必要とする時間を短縮させることができる。また、ステップ９０５で、Ｗｉ−Ｆｉ接続セットアップ過程の以後に進行されるＵＰｎＰデバイスディスカバリ過程の順序を最初のＷＦＤデバイスディスカバリ過程に操り上げて、ユーザに該当機器がＭＬ機能を使用できるか否かをステップ９０３〜ステップ９１１を遂行する前に通知し、ステップ９０３〜ステップ９１１を進行しないようにすることができる。
【００６３】
図１０は、本発明の第４の実施形態によるＷＦＤ構造図である。
図１０は、本発明の第２の実施形態の構成図（図５）と類似であるが、実際動作において若干の差異がある。
本発明の第４の実施形態において、ＳＳＤＰ情報をＷＦＤデバイスディスカバリ過程に交換するためには、下記のような２種類の技術的な問題点がある。
【００６４】
まず、ＷＦＤフレームにＵＰｎＰで使用するＳＳＤＰ情報を表示できる空間が存在しないという点である。Wifi Association（ＷＦＡ）では、ＷＦＤ技術の拡張のために予約したフィールドは定義したが、外部団体がＷＦＡの承認なしにこれを任意に使用するようになると、今後、ＷＦＡがＷＦＤを新規バージョンにアップデートする時、衝突が起こる可能性が大きい。
【００６５】
次に、ＷＦＤフレームは、レイヤ２で交換される情報であり、一般的にビット単位でメッセージが構成されており、上記ビットの値によって意味が決定される。したがって、フレームのサイズが上位レイヤプロトコル（例えば、http）のパケットに比べて相対的に小さい反面、フレームをやり取りする頻度数は頻繁である。したがって、ＷＦＤフレームのサイズが変更される場合、全体的なネットワークのオペレーションに上位レイヤプロトコルに比べて相対的に大きな影響を与えるようになる。
【００６６】
一般的に、ＳＳＤＰを通して交換されるメッセージはテキストからなり、上記テキスト情報をそのままＷＦＤフレームに入れる場合、メッセージサイズが異常に大きくなることは明らかである。
【００６７】
本発明の第４の実施形態では、上記問題を解決するために、ＷＦＤのフレームフォーマットに及ぼす影響を最小化する方案を提示し、実際に追加されるデータの量を減少させることができる方案を提示する。
【００６８】
このために、ステップ９０１でやりとりするＭＬフレームのフォーマットを定義した。ステップ９０１で、ＷＦＤソースデバイスとＷＦＤシンクデバイスは相互発見するためにデータフレームを交換するが、具体的なフォーマットは＜表４＞のようである。
【００６９】
【表４】
0006356155.tif 000005
【００７０】
＜表４＞のフォーマットは、Vendor specific usageを表すエレメントＩＤと、以後のエレメントの長さを表す長さと、ＣＣＣサービスであることを表す組織的に一意な識別子（ＯＵＩ；Organizational Unique Identifier）と、サポートするＵＰｎＰデバイスタイプを表すＵＰｎＰタイプを含む。
【００７１】
＜表４＞は、本発明の第４の実施形態によるＩＥフレームフォーマットを示し、上記フォーマットは、８０２．１１で定義したVendor specific情報エレメント（ＩＥ）のフレームフォーマットを変更したものである。
【００７２】
既存技術によれば、ＷＦＡでは上記フレームフォーマットで、ＩＥＥＥからＷＦＡのためのＯＵＩの割り当てを受け、ＷＦＡのためのＩＥを伝送するための用途で使用し、ＷＦＤのためにＯＵＩタイプを定義した。
【００７３】
上述したように、本発明の第２の実施形態のようにＷＦＡとＷＦＤのためのフレームフォーマットを、ＭＬデータを挿入するための用途で拡張する場合、一般的にＷＦＤで定義した予約されたフィールドを使用する。仮に、ＷＦＤで上記予約されたフィールドを拡張する場合、上記拡張されたＷＦＤに従う製品と本発明に基づいて生産された製品とが衝突を起こす可能性がある。
【００７４】
したがって、上述したように、新しくＯＵＩを定義し、これをＩＥＥＥから割り当てられ、ＣＣＣとＭＬのために独立的に使用することが、上述した衝突を防げる方法といえる。
【００７５】
上記ＯＵＩタイプは、ＭＬのバージョンがアップデートされることによって、値が変わり、十進数で変換する場合、十桁は主バージョン番号を示し、すなわち少数点以前の桁を示し、一桁は補助バージョン番号、すなわち少数点以後の数を表す。
【００７６】
ＭＬサブエレメントフィールドは、上記ＩＥのサブエレメントを表すフィールドであり、サブエレメント別に表現されるデータが相異なり、これは下記の表で説明する。
【００７７】
【表５】
0006356155.tif 000006
【００７８】
＜表５＞は、サブエレメントのフォーマットを示す表であり、サブエレメントＩＤでサブエレメントのデータ値を分類する。
【００７９】
【表６】
0006356155.tif 000007
【００８０】
＜表６＞は、サブエレメントのＩＤの具体的値と意味を表す。追加的な拡張のために予約されたフィールドを使用することができる。
【００８１】
【表７】
0006356155.tif 000008
【００８２】
＜表７＞は、サブエレメントのＩＤの値が０である場合、すなわちＵＰｎＰデバイス情報を表すサブエレメントのフォーマットを表す。実際情報は＜表８＞に記載されている。
【００８３】
【表８】
0006356155.tif 000009
【００８４】
＜表８＞は、ＵＰｎＰデバイス情報サブエレメントの値を通して、ＵＰｎＰ ＤＡでＳＳＤＰを通してやりとりする値を表現する。ＳＳＤＰで交換するデータのうち最も重要なことは、相手方装置がサポートするデバイスＩＤ及びサービスＩＤと、ＵＰｎＰデバイスディスクリプションドキュメントをフェッチするためのＵＲＬである。
【００８５】
上記のように、本発明は、第４の実施形態によってＷＦＤシンクデバイスとＷＦＤソースデバイスとの間にやりとりするメッセージのフォーマットを＜表４＞乃至＜表７＞で定義した。
【００８６】
本発明で、ステップ９０１がＵＰｎＰデバイスディスカバリ過程を正常に代替するためには、デバイスディスカバリ過程でやりとりするデバイスディスクリプションドキュメントの位置を表すユニフォームリソースロケータ（ＵＲＬ；Uniform Resource Locator）が必要である。しかし、ＷＦＤデバイスディスカバリ過程でＷＦＤシンクデバイスとＷＦＤソースデバイスは、まだＩＰが割り当てられない状態であるために、ＩＰを含んでいる上記情報を生成できない。したがって、ポート情報だけをフェッチした後、ＩＰが割り当てられた後に、ＩＰと上記ポート情報とを結合してＵＲＬを作らなければならない。可能な実施形態で、上記接続設定過程を通して取得したＩＰ、上記ディスカバリ手順を通して取得したポート情報、及びデバイスディスクリプションｘｍｌを結合してＵＲＬを生成できる。例えば、下記＜表９＞のようである。
【００８７】
【表９】
0006356155.tif 000010
【００８８】
また、既存のＳＳＤＰを通してデバイス情報をやり取りする場合には、上記デバイス情報を受信すること自体が、相手方ＵＰｎＰデバイス装置が駆動していることを証明する。しかし、本発明によれば、情報をやりとりする主体がＵＰｎＰ TmServerモジュールではなくＷＦＤシンク／ソースモジュールであるため、必ず情報の交換がＵＰｎＰ TmServerまたはＵＰｎＰ TmServer ＣＰの動作することを保障するものではない。
したがって、ステップ９２７で、ＵＰｎＰモジュールを駆動するステップと、上記ＵＲＬを生成するステップが追加的に必要となる。
【００８９】
ステップ９２７では、ステップ９０１を通して交換したＭＬ ＵＰｎＰデバイス情報に基づいて、図１０のＵＰｎＰ TmServer１０２２とＵＰｎＰ TmServer ＣＰ１０２２を駆動するか否かを決定する。例えば、ＷＦＤシンクデバイス１０２０の場合、相手方装置でＵＰｎＰ TmServer１０２２を提供する場合にＵＰｎＰ TmServer ＣＰ１０２２を駆動し、ＷＦＤソースデバイス１０００の場合、相手方装置がＵＰｎＰ TmServer ＣＰ１０２２を具現する場合にＵＰｎＰ TmServer１０２２を駆動する。ポリシーによって、上記ＵＰｎＰモジュールを常時駆動することができる。しかし、常時駆動する場合にリソースを効率的に使用できない短所がある。
ステップ９２７は、ＷＦＤシンクデバイスとＷＦＤソースデバイスが相異なる方式で動作する。
ＷＦＤシンクデバイスのステップ９２７の細部過程は、次のようである。
【００９０】
１．ＷＦＤシンクデバイス１０２０は、ステップ９０１を通して相手方ＷＦＤソースデバイス１０００にＵＰｎＰ TmServer１０２２が存在するということを認識する。
２．ＷＦＤシンクデバイス１０２０は、内部的にＵＰｎＰ TmServer ＣＰ１０２２を駆動する。
３．ＷＦＤシンクモジュール１０２４またはＷＦＤシンクデバイス１０２０は、ステップ９０５、すなわちＩＰの割り当てを受け、ＴＣＰ接続を行い、ＲＴＳＰセッションを確立するための過程を通して相手方のＲＴＳＰサーバのＩＰを既に知っている。
４．ＷＦＤシンクモジュール１０２４またはＷＦＤシンクデバイス１０２０は、上記ＲＴＳＰサーバのＩＰとステップ９０１によって得られたポートナンバーを結合して次のようなＵＲＬを生成する。（e.g.,http:／／IP address of RTSP: Port number by operation ９０１ステップ／)   
５．ＷＦＤシンクモジュール１０２４またはＷＦＤシンクデバイス１０２０は、上記ＵＲＬをＵＰｎＰ TmServerＣＰ１０２２に伝達する。
６．ＵＰｎＰ TmServerＣＰ１０２２は、上記ＵＲＬを介してデバイスディスクリプションをフェッチし、以後のプロセスは一般的なＭＬのＵＰｎＰプロセスと同一である。
【００９１】
ＷＦＤソースデバイスのステップ９２７の細部過程は次の通りである。
１．ＷＦＤソースデバイス１０００は、ステップ９０１で相手方ＷＦＤソースデバイス１０２０にＵＰｎＰ TmServer ＣＰ１０２２が存在するということを認識する。
２．ＷＦＤソースデバイス１０００は、内部的にＵＰｎＰ TmServer１０２２を駆動する。
３．以後のプロセスは、一般的なＭＬのＵＰｎＰプロセスと同一である。
【００９２】
本発明はＷＦＤを自動車環境に適用する方法を提供する同時に上記技術した目的を達成でき、ＷＦＤを自動車環境に適用する時、接続時間及び必要とするリソースを減少させることができる。
本発明は、車運転中に運転者の安全を考慮してモバイルフォンを操作できる。
本発明は、ＷＦＤを自動車環境に適用できる。
本発明は、ＷＦＤを自動車環境に適用する時に接続時間及び必要とするリソースを減少させることができる。
【００９３】
以上で説明した本発明は、本発明が属する技術分野で通常の知識を有する者にとって本発明の技術的思想を逸脱しない範囲内で色々な置換、変形及び変更が可能であり、前述した実施形態及び添付された図面に限定されるものではない。
【符号の説明】
【００９４】
１００  ソースデバイス
１２０  ＷＦＤシンクデバイス
３００  ＷＦＤソースデバイス
３０１  ブルートゥース（登録商標）装置
３０３  共通データバス
３０４  ＷＦＤディスプレイソースモジュール
３１０  ローカルアプリケーション
３２０  ＷＦＤシンクデバイス
３２１  ＢＴ
３２３  ＣＤＢ
３２４  Ｗｉ−Ｆｉディスプレイシンクモジュール
５００  ＷＦＤソースデバイス
５０４  Ｗｉ−Ｆｉディスプレイソースモジュール
５２０  ＷＦＤシンクデバイス
５２４  Ｗｉ−Ｆｉディスプレイシンクモジュール
１０００  ＷＦＤソースデバイス
１０２０  ＷＦＤシンクデバイス
１０２４  ＷＦＤシンクモジュール
【図１】
0006356155.tif 000011
【図２】
0006356155.tif 000012
【図３】
0006356155.tif 000013
【図４】
0006356155.tif 000014
【図５】
0006356155.tif 000015
【図６】
0006356155.tif 000016
【図７】
0006356155.tif 000017
【図８】
0006356155.tif 000018
【図９】
0006356155.tif 000019
【図１０】
0006356155.tif 000020