無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする無線通信装置。前記アプリ状態記憶手段が記憶する前記アプリ状態は、リンクロス直前の現在起動中のアプリか否か、一時待機中であるか否か、現在起動中のアプリと同時動作する共存中であるか否かを含むことを特徴とする請求項1に記載の無線通信装置。前記復旧手段によって無線通信路が所定の時間内に復旧できない場合は、前記復旧手段が前記アプリ状態をクリアすることを特徴とする請求項1又は請求項2に記載の無線通信装置。自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとを同時に接続してオーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させることを特徴とする車載装置。自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルと、携帯端末のゲートウェイ機能を使用し外部のネットワークとデータ通信を実現するためのダイヤルアップ通信プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとダイヤルアップ通信プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつダイヤルアップ通信プロトコルがデータ通信状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、データ通信状態を維持させることを特徴とする車載装置。自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にある電話帳データをダウンロードするための電話帳転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルと電話帳転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつ電話帳転送プロトコルが電話帳データ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、電話帳転送状態を維持することを特徴とする車載装置。自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にあるメッセージデータをダウンロードするためのメッセージ転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとメッセージ転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつメッセージ転送プロトコルがメッセージデータ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持することを特徴とする車載装置。無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置のリンクロス復旧方法において、前記無線装置の制御部に、無線通信路のリンクロスを検知するリンクロス検知ステップと、リンクロス前の複数のアプリケーションの状態を記憶するアプリ状態記憶ステップと、前記リンクロス検知手段がリンクロスを検知した後、無線通信路を復旧する復旧ステップと、前記復旧ステップにて無線通信路を復旧した後、前記アプリ状態記憶ステップにて記憶したアプリ記憶状態に従ってアプリケーションの復旧を行うアプリ復旧ステップと、を実行させることを特徴とするリンクロス復旧方法。そこで、本発明は上記問題に鑑みてなされた。すなわち、複数機能の同時動作マルチプロファイルの作動状況で、リンクロスが発生した場合に、復旧を容易にし、ユーザ利便性を高める無線通信装置および車載装置およびリンクロス復旧方法を提供することを目的とする。上記目的を達成するために本発明の無線通信装置は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なう構成を採る。本発明によれば、Bluetooth登録商標などの無線通信に係わり、リンクロス時の復旧を容易にする無線通信装置および車載装置を提供することができる。以下、本発明の実施の形態1に係る無線通信装置について図面を参照しながら説明する。なお、各図面において、本発明に関係のない構成要素は省略している。実施の形態1図1は、本発明の実施の形態1に係る無線通信装置100の全体構成を示すブロック図である。図1において、無線通信装置100は、近距離無線通信部101、制御部102、音声入力部103、音声出力部104、映像入力部105、映像出力部106、データ入力部107、データ出力部108、記憶部109を備える。対向無線通信装置200は、無線通信装置100と近距離無線通信を確立して、複数のアプリケーション以下、アプリケーションを単にアプリと称する機能に係わる情報の通信を行う。次いで、無線通信装置100の構成要素について説明する。近距離無線通信部101は、無線通信をするためのアンテナ、無線回路、プロトコルスタック等を有し、対向無線通信装置200と近距離無線通信によるデータ通信を行う。このデータ通信で使用する無線規格として、Bluetooth登録商標を用いる。制御部102は、無線通信装置100の通信動作やデータ管理動作などの本実施形態に係わる動作全般を制御する、CPUCentralProcessingUnit又はMPUMicroProcessingUnitとROMReadOnlyMemory、RAMRandomAccessMemory及びI/Oバス等である。CPU又はMPUは、ROMに格納されるプログラムを実行することによって、各機能ブロックが相互連携し、本実施の形態に関わる処理が実現される。また、CPU又はMPUは、プログラムの実行中、RAMを作業領域として使用する。また、制御部102では対向無線通信装置200と接続し複数のアプリを実行することができる。音声入力部103は、マイクロホン非図示から入力した入力音声を処理する回路等を含んでいる。この場合、アプリによっては、入力した音声を近距離無線通信部101から送信して対向無線通信装置200へ送信することができる。音声出力部104は、スピーカ非図示へ音声を出力するために出力音声を処理するアンプ、回路等を含んでいる。この場合、アプリによっては、対向無線通信装置200側から近距離無線通信部101を介して出力音声を受信することができる。映像入力部105は、例えば、カメラなどの撮像デバイス、外部からの映像入力端子であり、画像や映像、あるいは撮像などの像を入力するための回路等を含んでいる。映像出力部106は、例えば、液晶ディスプレイ、有機ELディスプレイなどの表示デバイスであり、画像や映像、あるいは撮像などの像を表示デバイスへ描画するための回路等を含んでいる。データ入力部107は、ユーザからの操作指示を入力するもので、押圧式のキーを所定数並べた構成を採るものや、タッチパネル式のもので構成される。ユーザによる操作を検出し、その操作内容を表わす操作信号を制御部102に出力する。データ出力部108は、制御部102で処理された各種データを出力するための手段である。各種データを映像として出力する場合、データ出力部108は映像出力部106と等価となる。一方、映像として出力せず単なるデータとして記憶したい場合は、記憶部109へ出力する。記憶部109は、各種データを記憶可能に構成されるメモリ等である。例えば、後述するアプリ種別管理テーブル、アプリの共存の可能/不能の組み合わせテーブル、優先度管理テーブル、アプリ状態管理テーブル、複数のアプリが処理するデータ等を記憶する。なお、符号102~108を付した構成要素は必ずしも全て備えなければならないとは限らない。一部の構成要素のみを備える構成としても良い。映像出力部とデータ入力部は分けた構成要素として説明したが、タッチパネルディスプレイのように両方の機能を持つ1つのデバイスとすることもできる。図2は、無線通信装置100と対向無線通信装置200の通信レイヤ構造をそれぞれモデル化した階層図である。第1の通信レイヤ構造10は無線通信装置100上の構造無線通信装置100の近距離通信部101が備える通信レイヤを示す階層図を、第2の通信レイヤ構造20は対向無線通信装置200上の構造無線通信装置200の近距離通信部が備える通信レイヤを示す階層図をそれぞれ表わしている。RFRadioFrequencyは、実際に無線通信を行うレイヤであり、2.4GHz帯で通信を行うための変調モードの定義、トランスミッタの特性最大送信電力など、レシーバーの特性感度などなどを定義する。Basebandは、無線通信を実現するためにさまざまな処理リンク制御、パケット管理、誤り訂正、チャネル制御などが行われるレイヤである。RFからの信号をデジタル化して上位レイヤに引き渡す役目を持つ。両デバイス間のメディアアクセスと物理レイヤの手順を規定する。通信ミドルウェアは、上位プロトコルの多重化、パケットのセグメント化と再構築、およびサービス品質情報の送信などをサポートするレイヤである。アプリA、アプリB、アプリCは、通信ミドルウェアの上で動作する複数のアプリを示しており、近距離無線通信路を介して同じアプリ同士が連携して動作する。例えば、第1の通信レイヤ構造10のアプリAと第2の通信レイヤ構造20のアプリAがそれぞれの役割を持ち、各種通信データのやり取りを行い動作する。ここで、役割とは、例えばデータ送信側やデータ受信側といった各種アプリを実行するにあたっての役割であり、アプリ毎にそれぞれ定義される。なお、図2では一例として3つのアプリを示しているが、これに限定するものではない。RF、Basebandは近距離無線通信部101として動作し、通信ミドルウェア、アプリA、アプリB、アプリCは、制御部102で動作するプログラムとして実現される。なお、通信ミドルウェアは近距離無線通信部101上で動作するようにしてもよい。次に、無線通信装置100の起動時の初期化処理について図3を用いて説明する。図3は、無線通信装置起動時の初期化処理を示す動作フロー図である。まずS101において、アプリ種別管理テーブルを作成する。次に、アプリ種別管理テーブルを参照しアプリの共存の可能/不能組み合わせテーブルを作成するS102。そして、アプリの共存の可能/不能組み合わせテーブルを参照し優先度管理テーブルを設定するS103。次いで、図3の動作フロー図で作成する各種テーブルについて、図4~図6を用いて説明する。図4は、アプリ種別管理テーブルの一例を示す図である。アプリ種別管理テーブルは各アプリ毎にどのような入出力を伴うかをテーブル化したものである。横軸は各アプリであり、縦軸はアプリ種別として、音声出力、音声入力、映像入力、映像出力、データ入力、データ出力、となる。アプリ種別管理テーブルの入出力はこれに限らず、その他任意のものを追加することができる。アプリ種別の音声出力とは、図1の無線通信装置100の音声出力部104を使用して音声出力を伴うアプリであるかどうかを表わす。同様に、音声入力とは、音声入力部103を使用して音声入力を伴うアプリであるかどうかを表わす。映像入力は、映像入力部105を使用して映像入力を伴うアプリであるかどうかを表わす。映像出力は、映像出力部106を使用して映像出力を伴うアプリであるかどうかを表わす。データ入力は、データ入力部107を使用してデータ入力を伴うアプリであるかどうかを表わす。データ出力は、データ出力部108を使用してデータ出力を伴うアプリであるかどうかを表わす。すなわち、アプリ種別と図1の無線通信装置100の構成要素102~108がそれぞれ対応していることとなる。図4のテーブル内の○は入出力を伴うことを表わし、×は伴わないことを表わす。ここで、アプリAは音声入力と音声出力が○となっており、その他は×となっている。これは、アプリAは音声入力と音声出力が伴うアプリ例えば、電話機能を実現するアプリであることを表わしている。また、アプリBは音声出力が伴うアプリ例えば、音楽再生を実現するアプリであることを表わしている。また、アプリCは映像出力、データ入力、データ出力が伴うアプリ例えば、メール機能を実現するアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはデータをすぐに映像として出力することがあるし、データをメモリに格納し後で利用することもあることを示している。アプリ種別管理テーブルはアプリが決まれば一意に定めることができる。図5は、アプリの共存の可能/不能の組み合わせテーブルの一例を示す図である。アプリの共存の可能/不能の組み合わせテーブルは、各アプリが持つ性質アプリ種別管理テーブルで定義によって、同時動作共存が可能なもの、不能なものの組み合わせを示すテーブルである。図5のテーブル内の○は共存可能、×は共存不能を表わしている。ここで、アプリAはアプリBとは共存不能でアプリCとは共存可能となる。アプリBはアプリAと共存不能でアプリCとは共存可能となる。アプリCは、アプリAと共存可能でアプリBと共存可能である。アプリAとアプリBの共存不能の理由について説明する。アプリA、アプリBは両方とも音声出力を伴うアプリであり、同時には1つのアプリの音声しか出力できない前提で共存不能となっている。アプリAとアプリCが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。図6は、優先度管理テーブルの一例を示す図である。優先度管理テーブルは、互いに共存が不能なアプリの場合に、どのアプリを優先して動作させるかを定義したものである。例えば、無線通信装置100を車載で使用する場合、ユーザが運転中にも各種アプリを使用するため、音声ベースのアプリ、リアルタイム性の高いアプリが優先される。なお、無線通信装置100が存在する位置に応じて、アプリ優先順位の決め方を動的に変更することもできる。現在動作中のアプリに対して優先度の高いアプリから割り込みが入ると、現在動作中のアプリは一時中断し、割り込みのあった優先度の高いアプリの動作を開始する。一方、現在アプリより優先度の低いアプリからの割り込みは許可しない。図6では、お互いに共存不能なアプリA、アプリBに関して、アプリAの方が優先度が高いことを示している。また、共存可能なアプリ同士の場合例えば、アプリAとアプリCには優先度管理テーブルは作成しない。なお、無線通信装置100の初期化処理として図3の動作フロー図を説明したが、これに限らず、事前にアプリ種別管理テーブル、アプリの共存の可能/不能の組み合わせテーブル、優先度管理テーブルを作成しておき、不揮発性メモリ等に格納しておき起動時に読み出すようにしても良い。次に、アプリ起動に伴う状態管理処理の動作について、図7~図8を用いて説明する。図7はアプリ状態管理テーブル詳しくは図8で説明の更新動作を示す動作フロー図である。図7において、ステップS201にてアプリ起動要求が発生したかどうかを判定する。アプリ起動要求が発生していない場合S201:No、ステップS201の前に処理を戻す。アプリ起動要求が発生した場合S201:Yes、ステップS202にて既に起動中のアプリがなしかどうかを判定する。既に起動中のアプリがない場合S202:Yes、ステップ203にて起動要求のあったアプリを起動する。ステップS202にて、既に起動中のアプリがある場合S202:No、ステップS205へ処理を移す。ステップS205では、既に起動中のアプリと共存できるアプリであるかを判定する。ステップS205の判定は、アプリの共存の可能/不能の組み合わせテーブルを参照する。既に起動中のアプリと共存できるアプリの場合S205:Yes、ステップS206にて起動要求のあったアプリを起動する。一方、既に起動中のアプリと共存できるアプリでない場合S205:No、ステップS207へ処理を移す。ステップS207では、起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリであるかを判定する。ここでステップS207の判定は、優先度管理テーブルを参照する。起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリである場合S207:Yes、ステップS208にて現在起動中のアプリを待機状態へ遷移させ、起動要求のあったアプリを起動する。一方、起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリでない場合S207:No、ステップS209へ処理を移す。ステップS209では、起動要求を受け付けず、終了する。ステップS204では、アプリ状態管理テーブルを更新する。図8は、アプリ状態管理テーブルの一例を示す図である。アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。また図8は、アプリBが起動中、アプリCが共存中の場合に、アプリAの起動要求が発生し、アプリ状態管理テーブルが更新された場合を示している。このとき、図7の動作フローでは、S201→S202→S205→S207→S208→S204のパスで順番に処理が行われることとなる。なお、図8のアプリ状態管理テーブルは一時待機中のアプリは2つまで、共存アプリは2つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。次いで、本発明の実施の形態1に係る無線通信装置のリンクロス電波環境変化等に伴う通信途絶発生時の動作について図9を用いて説明する。図9は、本発明の実施の形態1に係る無線通信装置のリンクロス発生時の動作を示す動作フロー図である。図9において、ステップS301ではリンクロスが発生したかどうかを判定する。リンクロスは、近距離無線通信部101にて検知する。リンクロスが発生していない場合S301:No、S301の前に処理を戻す。リンクロスが発生した場合S301:Yes、ステップS302へ処理を移す。リンクロスが発生した場合にユーザへその旨を通知することもできる。ステップS302では、対向無線通信装置200とのリンクロス復旧処理を試み、復旧できたかどうかを判定する。リンクロスから復旧できなかった場合S302:No、ステップS303へ処理を移す。ステップS303では、所定時間経過したかどうかを判定する。所定時間経過していない場合S303:Noは、ステップS302の前に処理を戻す。一方、所定時間経過した場合S303:Yesは、ステップS306へ処理を移す。ステップS306では、アプリ状態管理テーブルをクリア記憶した各アプリの状態を消去する。一方、リンクロスから復旧できた場合S302:Yes、ステップS304へ処理を移す。ステップS304では、リンクロス前のアプリ状態管理テーブルを読みだす。次いで、読み出したアプリ状態管理テーブルに従い各アプリをリンクロス前の状態へ復旧させるS305。このとき、リンクロス前に起動中であったアプリ図8の例でいくとアプリAを優先して復旧させる。ステップS302→S303→S306のようなパスがあるのは、対向無線通信装置がバッテリーで駆動しているような場合にバッテリー切れ等によりリンクロス復旧ができないような場合が存在するためである。以上、説明した無線通信装置によれば、複数機能の同時動作マルチプロファイルの作動状況で、リンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従いリンクロス前に起動中であったアプリだけでなく、待機状態のアプリ、共存状態のアプリも適切に復旧するので、ユーザ利便性を高める無線通信装置を提供することができる。上記実施の形態で説明した構成は、単に具体例を示すものであり、本願発明の技術的範囲を制限するものではない。本願の効果を奏する範囲において、任意の構成を採用することが可能である。また、近距離無線通信規格としてBluetooth登録商標を例に説明したが、無線LAN等でも有用である。実施の形態2以下、本発明の実施の形態2に係る車載装置について図面を参照しながら説明する。なお、各図面において、本発明に関係のない構成要素は省略している。図10は、本発明の実施の形態2に係る車載装置300の全体構成を示すブロック図である。図10において、車載装置300は実施の形態1の無線通信装置100と同様の構成要素を有しており、省略している。また各構成要素の説明を省略する。さらに、車載装置300は図示しない道路や交差点に関するデータ等の地図情報を格納したデータベース、GPSGlobalPositioningSystemなどの測位手段、公知の経路探索、誘導案内を行うプログラム等を含んでおり、映像出力部106に地図を表示するとともに自車位置の表示更新、地図上への経路の重畳表示、案内対象交差点手前では音声による誘導案内等を行うことができる。携帯端末400は、車載装置300が搭載される車両を利用する運転者が所持している例えば携帯電話であり、車両内に持込まれる。また車載装置300と近距離無線通信路を確立して、複数のアプリケーション以下、アプリケーションを単にアプリと称する機能に係わる通信を行う。近距離無線通信路は、Bluetooth登録商標規格に準拠する通信路である。車載装置300は携帯端末400と近距離無線通信を行うことで、公衆網1の先につながるユーザと通話するためのハンズフリー通話機能、携帯端末400の電話帳データを車載装置300へ転送する電話帳転送機能、携帯端末400に蓄積されたオーディオを車載装置300でストリーミング再生するストリーミング再生機能、携帯端末400のゲートウェイ機能を使用し外部のネットワーク公衆網1とWEBブラウズ等のデータ通信を行うデータ通信ダイヤルアップ通信機能、携帯端末400のゲートウェイ機能を使用し外部のネットワークとメッセージ通信を行うメッセージ通信機能などを備える。これらの機能を実行するにあたり、Bluetooth登録商標プロファイルを用い詳細は後述する、車載装置300と携帯端末400は複数のプロファイルが同時接続可能に構成されている。図11は、車載装置300の通信レイヤ構造をそれぞれモデル化した階層図である。第3の通信レイヤ構造30車載装置300の近距離無線通信部101が備えるBluetooth登録商標プロトコルスタックの階層図と同様の構成を持つ通信レイヤが携帯端末400にも存在するが図11では省略している。図11において、RFRadioFrequencyは、実際に無線通信を行うレイヤであり、2.4GHz帯で通信を行うための変調モードの定義、トランスミッタの特性最大送信電力など、レシーバーの特性感度などなどを定義する。Basebandは、無線通信を実現するためにさまざまな処理リンク制御、パケット管理、誤り訂正、チャネル制御などが行われるレイヤである。RFからの信号をデジタル化して上位レイヤに引き渡す役目を持つ。Bluetooth登録商標デバイス間のメディアアクセスと物理レイヤの手順を規定する。LMPLinkManagerProtocolは、2台のデバイス間におけるBluetooth登録商標接続のすべての側面接続、認証、暗号化、省電力制御などを制御し、ネゴシエートするために使用する。HCIHostControllerInterfaceは、ベースバンドコントローラとリンクマネージャにコマンドインタフェースを提供し、構成パラメータにアクセスするためのインタフェースを提供する。L2CAPLogicalLinkControlandAdaptationProtocolは、上位プロトコルの多重化、パケットのセグメント化と再構築、およびサービス品質情報の送信をサポートする。RFCOMMは、シリアルケーブルの設定と、RS-232Cシリアルポートをエミュレートするために使用する。OBEXObjectExchangeは、2台のデバイスがオブジェクトの交換に使用できる通信プロトコルであり、多様なデータやコマンドを交換できるように定義されている。AVDTPAudioVideoDistributionTransportProtocolは、AVストリームのネゴシエーション手順、確認手順、および伝送手順が定義されている。AVCTPAudioVideoControlTransportProtocolは、AVデバイスの制御メッセージを交換するトランスポートメカニズムが定義されている。GAVDPGeneralAudioVideoDistributionProfileは、A2DPの基礎として機能し、ビデオストリームとオーディオストリームを配信するために使用する。A2DPAdvancedAudioDistributionProfileは、ステレオ品質のオーディオをメディアソースからメディアシンクにストリーミングするために使用する。車載装置300はシンクとして振る舞う。携帯端末400はソースとして振る舞う。AVRCPAudioVideoRemoteControlProfileは、オーディオストリーミングのリモコン制御を行うために使用する。車載装置300はコントローラとして振る舞う。携帯端末400はターゲットとして振る舞う。OPPObjectPushProfileは、オブジェクト伝送のためのプロファイルであり、電話帳データの転送のために使用する。車載装置300はサーバーとして振る舞う。携帯端末400はクライアントとして振る舞う。PBAPPhoneBookAccessProfileは、電話帳データ、発着信履歴データの転送のために使用する。車載装置300はクライアントとして振る舞う。携帯端末400はサーバーとして振る舞う。なお、電話帳転送には、OPP又はPBAPいずれか任意のプロファイルを用いることができる。MAPMessageAccessProfileは、メッセージ情報の交換のために使用する。車載装置300はクライアントとして振る舞う。携帯端末400はサーバーとして振る舞う。HFPHandsFreeProfileは、ハンズフリー通話機能を実現するために使用する。車載装置300はハンズフリーとして振る舞う。携帯端末400はオーディオゲートウェイとして振る舞う。DUNDialUpNetworkingProfileは、インターネットや他のダイヤルアップサービスにアクセスするために使用する。車載装置300はデータターミナルとして振る舞う。携帯端末400はゲートウェイとして振る舞う。SDPServiceDiscoveryProtocolは、車載装置300と携帯端末400が互いにどのようなサービスをサポートしているのか検索するために使用する。GAPGenericAccessProfileは、Bluetooth登録商標対応デバイス間のベースバンドリンクを確立するための手法が定義されている。AVPアプリは、携帯端末400に蓄積されたオーディオを車載装置300でストリーミング再生するストリーミング再生機能を実現するアプリである。PBAPアプリは、車載装置300から携帯端末400の電話帳データを取得する電話帳転送機能を実現するアプリである。OPPアプリは、携帯端末400から車載装置300へ電話帳データを送信する電話帳転送機能を実現するアプリである。MAPアプリは、携帯端末400のゲートウェイ機能を使用し外部のネットワークとメッセージ通信を行うメッセージ通信機能を実現するアプリである。HFPアプリは、公衆網1の先につながるユーザと通話するためのハンズフリー通話機能を実現するためのアプリである。DUNアプリは、携帯端末400のゲートウェイ機能を使用し外部のネットワークとWEBブラウズ等のデータ通信を行うデータ通信ダイアルアップ通信機能を実現するアプリである。管理アプリは、携帯端末400とペアリングしてデバイス登録をしたり、車載装置300周辺に存在するBluetooth登録商標相手機器を探索して、相手機器の持つサービス情報を取得したりするアプリである。管理アプリは全てのアプリの基本となるアプリであり、常時起動されている。上記説明したアプリは、近距離無線通信路を介して携帯端末400の同じアプリ同士が連携して動作する。例えば、第3の通信レイヤ構造30のHFPアプリと携帯端末400のHFPアプリがそれぞれの役割を持ち、各種通信データのやり取りを行い動作する。なお、この図では一例として7つのアプリを示しているが、これに限定するものではない。他に規定されるBluetooth登録商標プロファイルに従い、別のアプリを追加することもできる。RF、Baseband、LMP、HCIは近距離無線通信部101として動作し、L2CAP以上は、制御部102で動作するプログラムとして実現される。なお、L2CAP~各プロファイル階層までを近距離無線通信部101上で動作するようにしてもよい。次に、車載装置300の起動時の初期化処理については図3で説明した実施の形態1と同様のためその説明を省略する。ここで、HFPアプリ、AVPアプリ、DUNアプリの3つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能/不能の組み合わせテーブル、優先度管理テーブルの一例について図12~図14を用いて説明する。図12は、HFPアプリ、AVPアプリ、DUNアプリの3つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。アプリ種別管理テーブルは各アプリ毎にどのような入出力を伴うかをテーブル化したものである。横軸は各アプリであり、縦軸はアプリ種別として、音声出力、音声入力、映像入力、映像出力、データ入力、データ出力、となる。図12のテーブル内の○は入出力を伴う。×は伴わないことを表わしている。ここで、HFPアプリは音声入力と音声出力が○となっており、その他は×となっている。これは、HFPアプリは電話機能を実現するアプリであり、音声入力と音声出力が伴うアプリであることを表わしている。また、AVPアプリは音声出力のみが○となっている。これは、AVPアプリはオーディオのストリーミング再生機能を実現する音声出力が伴うアプリであることを表わしている。また、DUNアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはデータをすぐに映像として出力ブラウザ等への表示することがあるし、データをメモリに格納し後で利用することもあることを示している。なお、DUNアプリはPANアプリと代替可能である。ここではDUNアプリはインターネットへ接続しブラウザ表示するものとして説明する。アプリ種別管理テーブルはアプリが決まれば一意に定めることができる。図13は、アプリの共存の可能/不能の組み合わせテーブルの一例を示す図である。アプリの共存の可能/不能の組み合わせテーブルは、各アプリが持つ性質アプリ種別管理テーブルで定義によって、同時動作共存が可能なもの、不能なものの組み合わせを示すテーブルである。図13テーブル内の○は共存可能、×は共存不能を表わしている。ここで、HFPアプリはAVPアプリとは共存不能でDUNアプリとは共存可能となる。AVPアプリはHFPアプリと共存不能でDUNアプリとは共存可能となる。DUNアプリは、HFPアプリと共存可能でAVPアプリと共存可能である。HFPアプリとAVPアプリの共存不能の理由について説明する。これはHFPアプリ、AVPアプリ両方とも音声出力を伴うアプリであり、同時には1つのアプリの音声しか出力できない前提で共存不能となっている。HFPアプリとDUNアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。図14は、優先度管理テーブルの一例を示す図である。優先度管理テーブルは、互いに共存が不能なアプリの場合はどのアプリを優先して動作させるかを定義したものである。現在動作中のアプリに対して優先度の高いアプリから割り込みが入ると、現在動作中のアプリは一時中断し、割り込みのあった優先度の高いアプリの動作を開始する。一方、現在アプリより優先度の低いアプリからの割り込みは許可しない。図14では、お互いに共存不能なHFPアプリ、AVPアプリに関して、HFPアプリの方が優先度が高いことを示している。HFPアプリが優先されるのはAVPアプリに比べて、ハンズフリー通話という双方向の音声通信が伴うリアルタイム性の高いアプリであるためである。また、共存可能なアプリ同士の場合例えば、HFPアプリとDUNアプリの組み合わせには優先度管理テーブルは作成しない。次いで、アプリの起動に伴う状態管理処理の動作については、図7と同様のためその説明を省略する。図15は、図7の動作フロー図のステップS204にて更新されるアプリ状態管理テーブルの一例を示す図である。アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。また図15は、AVPアプリが起動中オーディオストリーミング再生中、DUNアプリが共存中データ通信中の場合に、HFPアプリの起動要求例えばハンズフリー着信が発生し、アプリ状態管理テーブルが更新された場合を示している。このとき、HFPアプリにて着信を受け付けると通話中の状態となり、AVPアプリは一時停止中状態となり、DUNアプリはデータ通信中の状態となる。図7の動作フローでは、S201→S202→S205→S207→S208→S204のパスで順番に処理が行われることとなる。ここで、管理アプリは全てのアプリの基本となるアプリであり起動されている。管理アプリは図15のアプリ状態管理テーブルの対象から外している。なお、図15のアプリ状態管理テーブルは一時待機中のアプリは2つまで、共存アプリは2つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。次いで、本発明の実施の形態2に係る無線通信装置のリンクロス発生時の動作については図9と同様のためその説明を省略する。ここで、図9の動作フロー図ステップS305における各アプリを復旧させる動作について、図16を用いてより詳細に説明する。図16は、車載装置300のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。リンクロス前のアプリ状態管理テーブルを図15に示す状態であるものとする。図16において、ステップS401にて、ハンズフリーHFPアプリをサービスレベルSLC接続状態に復旧させる。次いで、携帯端末側で通話状態が継続されているかを判定するステップS402。なお、通話状態が継続されているかの判定は携帯端末400から通知されるステータス又は車載装置300から携帯端末400への問合せに対する応答コマンドによって判定する。携帯端末側で通話状態が継続されていない場合S402:No、ステップS404へ処理を移す。携帯端末側で通話状態が継続されている場合S402:Yes、ハンズフリーを通話状態へ復旧させる。ステップS404では、オーディオストリーミングAVPアプリをサービス接続状態へ復旧させる。次いで、携帯端末側でオーディオストリーミングの一時停止状態が継続されているかを判定するステップS405。なお、一時停止状態が継続されているかの判定は携帯端末400から通知されるステータス又は車載装置300から携帯端末400への問合せに対する応答コマンドによって判定する。携帯端末側でオーディオストリーミングの一時停止状態が継続されていない場合S405:No、ステップS407へ処理を移す。携帯端末側でオーディオストリーミングの一時停止状態が継続されている場合S405:Yes、オーディオストリーミングAVPアプリを一時停止状態へ復旧させる。ステップS407では、データ通信DUNアプリをサービス接続状態へ復旧させる。次いで、携帯端末側でデータ通信の共存状態が継続されているかを判定するステップS408。なお、共存状態が継続されているかの判定は携帯端末400から通知されるステータス又は車載装置300から携帯端末400への問合せに対する応答コマンドによって判定する。携帯端末側でデータ通信の共存状態が継続されていない場合S408:No、処理を終了する。携帯端末側でデータ通信の共存状態が継続されている場合S408:Yes、データ通信DUNアプリを共存状態へ復旧させるWEBブラウズ中の継続データが受信され、WEBページが表示される。これにより、マルチプロファイル動作中HFPアプリ/AVPアプリ/DUNアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。また、図16の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にデータ通信状態を維持する。また、HFPアプリ、AVPアプリ、DUNアプリの3つのプロファイルがマルチプロファイルで動作する場合について説明したが、マルチプロファイル動作HFPアプリ/AVPアプリにおいても同様に実施できる。このとき上記説明した図15に示すアプリ状態管理テーブルの共存アプリ1に該当するアプリが何もない状態となる。そして、図16のS407~S409の処理が省かれることになる。変形例1本発明の実施の形態2の変形例1について、図17~図20を用いて説明する。まず、HFPアプリ、AVPアプリ、PBAPアプリの3つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能/不能の組み合わせテーブルの一例について図17~図18を用いて説明する。優先度管理テーブルは図14と同様のため説明を省略する。図17は、HFPアプリ、AVPアプリ、PBAPアプリの3つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。PBAPアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これは電話帳データをすぐに映像として出力例えば、電話帳のリスト表示することがあるし、電話帳データをメモリに格納し後で利用することもあることを示している。図18は、アプリの共存の可能/不能の組み合わせテーブルの一例を示す図である。ここで、HFPアプリはAVPアプリとは共存不能でPBAPアプリとは共存可能となる。AVPアプリはHFPアプリと共存不能でPBAPアプリとは共存可能となる。PBAPアプリは、HFPアプリと共存可能でAVPアプリと共存可能である。HFPアプリとAVPアプリの共存不能の理由について、これはHFPアプリ、AVPアプリ両方とも音声出力を伴うアプリであり、同時には1つのアプリの音声しか出力できない前提で共存不能となっている。HFPアプリとPBAPアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。次いで、アプリの起動に伴う状態管理処理の動作について、図7と同様のためその説明を省略する。図19は、図7の動作フロー図のステップS204にて更新されるアプリ状態管理テーブルの一例を示す図である。アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。また図19は、AVPアプリが起動中オーディオストリーミング再生中、PBAPアプリが共存中電話帳転送中の場合に、HFPアプリの起動要求例えばハンズフリー着信が発生し、アプリ状態管理テーブルが更新された場合を示している。このとき、HFPアプリにて着信を受け付けると通話中の状態となり、AVPアプリは一時停止中状態となり、PBAPアプリは電話帳転送中の状態となる。図7の動作フローでは、S201→S202→S205→S207→S208→S204のパスで順番に処理が行われることとなる。なお、図19のアプリ状態管理テーブルは一時待機中のアプリは2つまで、共存アプリは2つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。次いで、本発明の実施の形態2変形例1に係る車載装置のリンクロス発生時の動作については実施の形態1で説明した図9と同様のためその説明を省略する。ここで、図9の動作フロー図ステップS305における各アプリを復旧させる動作について、図20を用いてより詳細に説明する。図20は、車載装置300のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。リンクロス前のアプリ状態管理テーブルを図19に示す状態であるものとする。図20において、ステップS401~ステップS406までの動作については、図16と同様のためその説明を省略する。ステップS501では、電話帳転送PBAPアプリをサービス接続状態へ復旧させる。次いで、携帯端末側で電話帳転送の共存状態が継続されているかを判定するステップS502。なお、共存状態が継続されているかの判定は携帯端末400から通知されるステータス又は車載装置300から携帯端末400への問合せに対する応答コマンドによって判定する。携帯端末側で電話帳転送の共存状態が継続されていない場合S502:No、処理を終了する。この場合は、電話帳データを再度はじめから転送する必要がある。携帯端末側で電話帳転送の共存状態が継続されている場合S502:Yes、電話帳転送PBAPアプリを共存状態へ復旧させ、電話帳データの続きから転送する。これにより、マルチプロファイル動作中HFPアプリ/AVPアプリ/PBAPアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。また、図20の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共に電話帳転送状態を維持する。変形例2本発明の実施の形態2の変形例2について、図21~図24を用いて説明する。まず、HFPアプリ、AVPアプリ、MAPアプリの3つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能/不能の組み合わせテーブルの一例について図21~図22を用いて説明する。優先度管理テーブルは図14と同様のため説明を省略する。図21は、HFPアプリ、AVPアプリ、MAPアプリの3つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。MAPアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはメッセージデータをすぐに映像として出力例えば、メッセージリスト又はメッセージ本文表示することがあるし、メッセージデータをメモリに格納し後で利用することもあることを示している。ここでメッセージデータとはSMS、E-Mail等を指す。図22は、アプリの共存の可能/不能の組み合わせテーブルの一例を示す図である。ここで、HFPアプリはAVPアプリとは共存不能でMAPアプリとは共存可能となる。AVPアプリはHFPアプリと共存不能でMAPアプリアプリとは共存可能となる。MAPアプリは、HFPアプリと共存可能でAVPアプリと共存可能である。HFPアプリとAVPアプリの共存不能の理由について説明する。HFPアプリ、AVPアプリ両方とも音声出力を伴うアプリであり、同時には1つのアプリの音声しか出力できない前提で共存不能となっている。HFPアプリとMAPアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。次いで、アプリの起動に伴う状態管理処理の動作について、図7と同様のためその説明を省略する。図23は、図7の動作フロー図のステップS204にて更新されるアプリ状態管理テーブルの一例を示す図である。アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。また図23は、AVPアプリが起動中オーディオストリーミング再生中、MAPアプリが共存中メッセージ転送中の場合に、HFPアプリの起動要求例えばハンズフリー着信が発生し、アプリ状態管理テーブルが更新された場合を示している。このとき、HFPアプリにて着信を受け付けると通話中の状態となり、AVPアプリは一時停止中状態となり、MAPアプリはメッセージ転送中の状態となる。図7の動作フローでは、S201→S202→S205→S207→S208→S204のパスで順番に処理が行われることとなる。なお、図23のアプリ状態管理テーブルは一時待機中のアプリは2つまで、共存アプリは2つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。次いで、本発明の実施の形態2変形例2に係る車載装置のリンクロス発生時の動作については実施の形態1で説明した図9と同様のためその説明を省略する。ここで、図9の動作フロー図ステップS305における各アプリを復旧させる動作について、図24を用いてより詳細に説明する。図24は、車載装置300のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。リンクロス前のアプリ状態管理テーブルを図23に示す状態であるものとする。図24において、ステップS401~ステップS406までの動作については、図16と同様のためその説明を省略する。ステップS601では、メッセージ転送MAPアプリをサービス接続状態へ復旧させる。次いで、携帯端末側でメッセージ転送の共存状態が継続されているかを判定するステップS602。なお、共存状態が継続されているかの判定は携帯端末400から通知されるステータス又は車載装置300から携帯端末400への問合せに対する応答コマンドによって判定する。携帯端末側でメッセージ転送の共存状態が継続されていない場合S602:No、処理を終了する。この場合は、メッセージデータを再度一から転送する必要がある。携帯端末側でメッセージ転送の共存状態が継続されている場合S502:Yes、メッセージ転送MAPアプリを共存状態へ復旧させ、メッセージデータの続きから転送する。これにより、マルチプロファイル動作中HFPアプリ/AVPアプリ/MAPアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。また、図24の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持する。以上、説明した車載装置によれば、複数機能の同時動作マルチプロファイルの作動状況で、リンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従いリンクロス前に起動中であったアプリだけでなく、待機状態のアプリ、共存状態のアプリも適切に復旧するので、ユーザ利便性を高める車載装置を提供することができる。なお、図10では車載装置300と携帯端末400が1対1で接続されるポイントツーポイントのマルチプロファイルについて説明したが、これに限らず車載装置300と複数の携帯端末が1対多で接続されるポイントツーマルチポイントのマルチプロファイルにおいても同様に適用できる。上記説明では、マルチプロファイル動作の組み合わせとして、HFPアプリ/AVPアプリ/DUNアプリ、HFPアプリ/AVPアプリ/PBAPアプリ、HFPアプリ/AVPアプリ/MAPアプリを一例として説明したが、これに限らず、図25、図26に示すような他の組み合わせでも実施できる。図25はリンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルNo.1である。図26はリンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルNo.2No.1からの継続である。また、3つのプロファイル同士の組み合わせだけでなく、4つのプロファイルの組み合わせ、例えば、同時にHFPアプリ、AVPアプリ、DUNアプリ、PBAPアプリとを接続し、同時動作する場合のリンクロス時に対しても、同様に適用できる。また、図示しない走行状態検知手段例えば、車速センサによって車両の走行状態を判別し、リンクロスからの復旧制御をよりきめ細かく行うこともできる。また、リンクロス復旧前の状態に適切に復旧できたか否かを区別して音声等でユーザへ報知するようにしても良い。これにより、ユーザが運転中で車載ディスプレイへ視線を移動することなく、リンクロス前の状態に正常復帰したのか否かを判断することができる。また、近距離無線通信規格としてBluetooth登録商標を例に説明したが、無線LAN等でも有用である。上記実施の形態で説明した構成は、単に具体例を示すものであり、本願発明の技術的範囲を制限するものではない。本願の効果を奏する範囲において、任意の構成を採用することが可能である。以上の説明において、リンクロス検知手段は近距離無線通信部101例えば、Bluetooth登録商標モジュール及び制御部102例えば、CPUで動作するソフトウェアに対応しており、近距離無線通信部101としてのBluetooth登録商標モジュールがリンクロスを検知し制御部102としてのCPU側へ通知される。アプリ状態記憶手段は、記憶部109メモリ等に対応しており、図8に示すアプリ状態管理テーブルを記憶する。復旧手段は、近距離無線通信部101及び制御部102としてのCPUで動作するソフトウェアに対応しており、リンクロスを検知した後、無線通信路を復旧する。アプリ復旧手段は、近距離無線通信部101及び制御部102としてのCPUで動作するソフトウェアに対応しており、リンクロス前の各アプリを復旧させる。接続手段は、近距離通信部101例えば、Bluetooth登録商標モジュール及び制御部102例えば、CPUで動作するソフトウェアに対応している。制御手段は、近距離無線通信部101を制御する制御部102例えば、CPUで動作するソフトウェアに対応している。以上のとおり、本発明の無線通信装置は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする。この構成を有することにより、複数のアプリケーションがリンクロス前に動作していてもアプリ状態記憶手段に記憶されているアプリ記憶状態に従いアプリケーションの復旧を行うことができる。さらに、本発明の無線通信装置は、アプリ状態記憶手段が記憶するアプリ状態は、リンクロス直前の現在起動中のアプリか否か、一時待機中であるか否か、現在起動中のアプリと共存動作ができる共存中であるか否かを含むことを特徴とする。これにより、各アプリのリンクロス前の状態へ適切に復旧することができ、リンクロス直前に起動中のアプリだけでなく、一時待機中、共存中であったアプリも確実に復旧することができる。また、現在起動中のアプリが終了した際には一時待機中であったアプリが次に起動できるようになり、リンクロスを挟むことにより状態がおかしくなる現象を回避できる。さらに、本発明の無線通信装置は、復旧手段によって、リンクロス後無線通信路が所定の時間内で復旧できない場合にはアプリ状態をクリアすることを特徴とする。これにより、対向無線通信装置がバッテリーで駆動しているような場合にバッテリー切れ等によりいつまでもリンクロス復旧ができないような場合にはアプリ状態がクリアされるので、無線通信装置がいつまでもアプリ状態を記憶しておかずに済む。またバッテリー切れによるリンクロス後、バッテリーが充電された後に対向無線通信装置と接続確立した際に、無線通信装置がおかしな挙動をすることを回避できる。本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとを同時に接続してオーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させることを特徴とする。この構成を有することにより、マルチプロファイル動作中HFPアプリ/AVPアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルと、携帯端末のゲートウェイ機能を使用し外部のネットワークとデータ通信を実現するためのダイヤルアップ通信プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとダイヤルアップ通信プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつダイヤルアップ通信プロトコルがデータ通信状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、データ通信状態を維持させることを特徴とする。この構成を有することにより、マルチプロファイル動作中HFPアプリ/AVPアプリ/DUNアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にある電話帳データをダウンロードするための電話帳転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルと電話帳転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつ電話帳転送プロトコルが電話帳データ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、電話帳転送状態を維持することを特徴とする。この構成を有することにより、マルチプロファイル動作中HFPアプリ/AVPアプリ/PBAPアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にあるメッセージデータをダウンロードするためのメッセージ転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとメッセージ転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつメッセージ転送プロトコルがメッセージデータ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持することを特徴とする。この構成を有することにより、マルチプロファイル動作中HFPアプリ/AVPアプリ/MAPアプリにリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。本発明のリンクロス復旧方法は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置のリンクロス復旧方法において、前記無線装置の制御部に、無線通信路のリンクロスを検知するリンクロス検知ステップと、リンクロス前の複数のアプリケーションの状態を記憶するアプリ状態記憶ステップと、前記リンクロス検知手段がリンクロスを検知した後、無線通信路を復旧する復旧ステップと、前記復旧ステップにて無線通信路を復旧した後、前記アプリ状態記憶ステップにて記憶したアプリ記憶状態に従ってアプリケーションの復旧を行うアプリ復旧ステップと、を実行させることを特徴とする。この構成を有することにより、複数のアプリケーションがリンクロス前に起動していてもアプリ状態記憶手段に記憶されているアプリ記憶状態に従いアプリケーションの復旧を行うことができる。