無線通信装置および車載装置およびリンクロス復旧方法
【課題】リンクロス（電波環境変化等に伴う通信途絶）時の復旧を容易にする無線通信装置および車載装置およびリンクロス復旧方法を提供すること。
【解決手段】無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする。
【解決手段】無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信に係わり、リンクロス（電波環境変化等に伴う通信途絶）時の復旧を容易にする無線通信装置および車載装置およびリンクロス復旧方法に関する。
【背景技術】
【０００２】
従来より、近距離での無線通信により、各種機器間でデータを送受信する技術としてＢｌｕｅｔｏｏｔｈ（登録商標）がある。Ｂｌｕｅｔｏｏｔｈ（登録商標）は２．４ＧＨｚの周波数帯を用いる規格であり、十メートル程度の範囲内で無線通信が可能である。
【０００３】
一例として、携帯電話とカーナビゲーションに代表される車載装置とがＢｌｕｅｔｏｏｔｈ（登録商標）を用いて接続し、ハンズフリー通話やオーディオ転送を行う機能が実現されている（例えば、特許文献１参照）。
【０００４】
Ｂｌｕｅｔｏｏｔｈ（登録商標）規格では、プロファイルというアプリケーションとして作動するために必要な機能、振る舞いが規定されており、例えばハンズフリー機能を実現するためのハンズフリープロファイル（ＨＦＰ）、オーディオ転送を行うオーディオプロファイル（Ａ２ＤＰ／ＡＶＲＣＰ）、電話回線を用いたダイヤルアップ接続によるデータ通信を実現するためのダイヤルアップネットワークプロファイル（ＤＵＮ）等がある。
【０００５】
無線通信装置同士で複数のプロファイルを同時に接続して、複数のアプリケーション機能を同時利用する場合（所謂、マルチプロファイル）がある。
【０００６】
一方、このような複数のアプリケーションを同時利用する場合において、アプリケーションが持つ性質によって、同時動作が可能なもの、不能なものの組み合わせがあることが一般的に知られている。同時動作可能とは、例えば、アプリＡ、アプリＢがあったときに、アプリＡ、Ｂ共に動作できる組み合わせであることを表わし、同時動作不能とは例えば、アプリＡ、アプリＣがあったときにどちらか一方のアプリしか同時には作動できないことを表わす。
【０００７】
また、通信路が無線であるためにリンクロス（電波環境変化等に伴う通信途絶）が発生することが想定される。
【０００８】
マルチプロファイルの作動状況で、リンクロスが発生した場合に、無線通信装置は上記アプリケーションの同時動作可能／不能な組み合わせがあるために、どの状態にまで復旧すればよいのか判断できないといった問題がある。このため、同時動作不能のアプリＡ、アプリＣがあり、アプリＡが現在動作中のアプリで、アプリＣが現在一時停止中のアプリであるときに、リンクロスが発生すると、直前に起動していたアプリであるアプリＡの復旧は行えても、それ以前に起動しており、リンクロス直前には一時停止状態であったアプリＣの復旧までは行うことができないという問題があった。
【０００９】
また、以上のような問題は単にＢｌｕｅｔｏｏｔｈ（登録商標）とプロファイルとの関係のみならず近距離無線通信装置と、当該近距離無線通信装置が相手との通信によって実現する機能との関係においても発生しうる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００６−１４８８６４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
そこで、本発明は上記問題に鑑みてなされた。すなわち、複数機能の同時動作（マルチプロファイル）の作動状況で、リンクロスが発生した場合に、復旧を容易にし、ユーザ利便性を高める無線通信装置および車載装置およびリンクロス復旧方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するために本発明の無線通信装置は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なう構成を採る。
【発明の効果】
【００１３】
本発明によれば、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信に係わり、リンクロス時の復旧を容易にする無線通信装置および車載装置を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施の形態１に係る無線通信装置の全体構成を示すブロック図
【図２】無線通信装置１００と対向無線通信装置２００の通信レイヤ構造をモデル化した階層図
【図３】無線通信装置起動時の初期化処理を示す動作フロー図
【図４】本発明の実施の形態１に係るアプリ種別管理テーブルの一例を示す図
【図５】本発明の実施の形態１に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図６】本発明の実施の形態１に係る優先度管理テーブルの一例を示す図
【図７】本発明の実施の形態１に係るアプリ状態管理テーブルの更新動作を示す動作フロー図
【図８】本発明の実施の形態１に係るアプリ状態管理テーブルの一例を示す図
【図９】本発明の実施の形態１に係る無線通信装置のリンクロス発生時の動作を示す動作フロー図
【図１０】本発明の実施の形態２に係る車載装置３００と携帯端末４００の全体構成を示す模式図
【図１１】車載装置の近距離無線通信部１０１及び携帯端末４００の近距離無線通信部が備えるＢｌｕｅｔｏｏｔｈ（登録商標）プロトコルスタックの階層図
【図１２】本発明の実施の形態２に係るアプリ種別管理テーブルの一例を示す図
【図１３】本発明の実施の形態２に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図１４】本発明の実施の形態２に係る優先度管理テーブルの一例を示す図
【図１５】本発明の実施の形態２に係るアプリ状態管理テーブルの一例を示す図
【図１６】本発明の実施の形態２に係る車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図
【図１７】本発明の実施の形態２（変形例１）に係るアプリ種別管理テーブルの一例を示す図
【図１８】本発明の実施の形態２（変形例１）に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図１９】本発明の実施の形態２（変形例１）に係るアプリ状態管理テーブルの一例を示す図
【図２０】本発明の実施の形態２（変形例１）に係る車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図
【図２１】本発明の実施の形態２（変形例２）に係るアプリ種別管理テーブルの一例を示す図
【図２２】本発明の実施の形態２（変形例２）に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図２３】本発明の実施の形態２（変形例２）に係るアプリ状態管理テーブルの一例を示す図
【図２４】本発明の実施の形態２（変形例２）に係る車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図
【図２５】リンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルを示す図
【図２６】リンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルを示す図
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態１に係る無線通信装置について図面を参照しながら説明する。なお、各図面において、本発明に関係のない構成要素は省略している。
（実施の形態１）
図１は、本発明の実施の形態１に係る無線通信装置１００の全体構成を示すブロック図である。
【００１６】
図１において、無線通信装置１００は、近距離無線通信部１０１、制御部１０２、音声入力部１０３、音声出力部１０４、映像入力部１０５、映像出力部１０６、データ入力部１０７、データ出力部１０８、記憶部１０９を備える。
【００１７】
対向無線通信装置２００は、無線通信装置１００と近距離無線通信を確立して、複数のアプリケーション（以下、アプリケーションを単にアプリと称する）機能に係わる情報の通信を行う。
【００１８】
次いで、無線通信装置１００の構成要素について説明する。
【００１９】
近距離無線通信部１０１は、無線通信をするためのアンテナ、無線回路、プロトコルスタック等を有し、対向無線通信装置２００と近距離無線通信によるデータ通信を行う。このデータ通信で使用する無線規格として、Ｂｌｕｅｔｏｏｔｈ（登録商標）を用いる。
【００２０】
制御部１０２は、無線通信装置１００の通信動作やデータ管理動作などの本実施形態に係わる動作全般を制御する、ＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro Processing Unit）とＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びI／Oバス等である。
【００２１】
ＣＰＵ又はＭＰＵは、ＲＯＭに格納されるプログラムを実行することによって、各機能ブロックが相互連携し、本実施の形態に関わる処理が実現される。また、ＣＰＵ又はＭＰＵは、プログラムの実行中、ＲＡＭを作業領域として使用する。また、制御部１０２では対向無線通信装置２００と接続し複数のアプリを実行することができる。
【００２２】
音声入力部１０３は、マイクロホン（非図示）から入力した入力音声を処理する回路等を含んでいる。この場合、アプリによっては、入力した音声を近距離無線通信部１０１から送信して対向無線通信装置２００へ送信することができる。
【００２３】
音声出力部１０４は、スピーカ（非図示）へ音声を出力するために出力音声を処理するアンプ、回路等を含んでいる。この場合、アプリによっては、対向無線通信装置２００側から近距離無線通信部１０１を介して出力音声を受信することができる。
【００２４】
映像入力部１０５は、例えば、カメラなどの撮像デバイス、外部からの映像入力端子であり、画像や映像、あるいは撮像などの像を入力するための回路等を含んでいる。
【００２５】
映像出力部１０６は、例えば、液晶ディスプレイ、有機ＥＬディスプレイなどの表示デバイスであり、画像や映像、あるいは撮像などの像を表示デバイスへ描画するための回路等を含んでいる。
【００２６】
データ入力部１０７は、ユーザからの操作指示を入力するもので、押圧式のキーを所定数並べた構成を採るものや、タッチパネル式のもので構成される。ユーザによる操作を検出し、その操作内容を表わす操作信号を制御部１０２に出力する。
【００２７】
データ出力部１０８は、制御部１０２で処理された各種データを出力するための手段である。各種データを映像として出力する場合、データ出力部１０８は映像出力部１０６と等価となる。一方、映像として出力せず単なるデータとして記憶したい場合は、記憶部１０９へ出力する。
【００２８】
記憶部１０９は、各種データを記憶可能に構成されるメモリ等である。例えば、後述するアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブル、優先度管理テーブル、アプリ状態管理テーブル、複数のアプリが処理するデータ等を記憶する。
【００２９】
なお、符号１０２〜１０８を付した構成要素は必ずしも全て備えなければならないとは限らない。一部の構成要素のみを備える構成としても良い。映像出力部とデータ入力部は分けた構成要素として説明したが、タッチパネルディスプレイのように両方の機能を持つ１つのデバイスとすることもできる。
【００３０】
図２は、無線通信装置１００と対向無線通信装置２００の通信レイヤ構造をそれぞれモデル化した階層図である。
【００３１】
第１の通信レイヤ構造１０は無線通信装置１００上の構造（無線通信装置１００の近距離通信部１０１が備える通信レイヤを示す階層図）を、第２の通信レイヤ構造２０は対向無線通信装置２００上の構造（無線通信装置２００の近距離通信部が備える通信レイヤを示す階層図）をそれぞれ表わしている。
【００３２】
ＲＦ（Radio Frequency）は、実際に無線通信を行うレイヤであり、２．４ＧＨｚ帯で通信を行うための変調モードの定義、トランスミッタの特性（最大送信電力など）、レシーバーの特性（感度など）などを定義する。
【００３３】
Ｂａｓｅ ｂａｎｄは、無線通信を実現するためにさまざまな処理（リンク制御、パケット管理、誤り訂正、チャネル制御など）が行われるレイヤである。ＲＦからの信号をデジタル化して上位レイヤに引き渡す役目を持つ。両デバイス間のメディア アクセスと物理レイヤの手順を規定する。
【００３４】
通信ミドルウェアは、上位プロトコルの多重化、パケットのセグメント化と再構築、およびサービス品質情報の送信などをサポートするレイヤである。
【００３５】
アプリＡ、アプリＢ、アプリＣは、通信ミドルウェアの上で動作する複数のアプリを示しており、近距離無線通信路を介して同じアプリ同士が連携して動作する。
【００３６】
例えば、第１の通信レイヤ構造１０のアプリＡと第２の通信レイヤ構造２０のアプリＡがそれぞれの役割を持ち、各種通信データのやり取りを行い動作する。
【００３７】
ここで、役割とは、例えばデータ送信側やデータ受信側といった各種アプリを実行するにあたっての役割であり、アプリ毎にそれぞれ定義される。
【００３８】
なお、図２では一例として３つのアプリを示しているが、これに限定するものではない。
【００３９】
ＲＦ、Ｂａｓｅ ｂａｎｄは近距離無線通信部１０１として動作し、通信ミドルウェア、アプリＡ、アプリＢ、アプリＣは、制御部１０２で動作するプログラムとして実現される。なお、通信ミドルウェアは近距離無線通信部１０１上で動作するようにしてもよい。
【００４０】
次に、無線通信装置１００の起動時の初期化処理について図３を用いて説明する。図３は、無線通信装置起動時の初期化処理を示す動作フロー図である。
【００４１】
まずＳ１０１において、アプリ種別管理テーブルを作成する。次に、アプリ種別管理テーブルを参照しアプリの共存の可能／不能組み合わせテーブルを作成する（Ｓ１０２）。そして、アプリの共存の可能／不能組み合わせテーブルを参照し優先度管理テーブルを設定する（Ｓ１０３）。
【００４２】
次いで、図３の動作フロー図で作成する各種テーブルについて、図４〜図６を用いて説明する。
【００４３】
図４は、アプリ種別管理テーブルの一例を示す図である。アプリ種別管理テーブルは各アプリ毎にどのような入出力を伴うかをテーブル化したものである。横軸は各アプリであり、縦軸はアプリ種別として、音声出力、音声入力、映像入力、映像出力、データ入力、データ出力、・・・となる。
【００４４】
アプリ種別管理テーブルの入出力はこれに限らず、その他任意のものを追加することができる。
【００４５】
アプリ種別の音声出力とは、図１の無線通信装置１００の音声出力部１０４を使用して音声出力を伴うアプリであるかどうかを表わす。同様に、音声入力とは、音声入力部１０３を使用して音声入力を伴うアプリであるかどうかを表わす。映像入力は、映像入力部１０５を使用して映像入力を伴うアプリであるかどうかを表わす。映像出力は、映像出力部１０６を使用して映像出力を伴うアプリであるかどうかを表わす。データ入力は、データ入力部１０７を使用してデータ入力を伴うアプリであるかどうかを表わす。データ出力は、データ出力部１０８を使用してデータ出力を伴うアプリであるかどうかを表わす。
【００４６】
すなわち、アプリ種別と図１の無線通信装置１００の構成要素１０２〜１０８がそれぞれ対応していることとなる。
【００４７】
図４のテーブル内の「○」は入出力を伴うことを表わし、「×」は伴わないことを表わ
す。
【００４８】
ここで、アプリＡは音声入力と音声出力が○となっており、その他は×となっている。これは、アプリＡは音声入力と音声出力が伴うアプリ（例えば、電話機能を実現するアプリ）であることを表わしている。
【００４９】
また、アプリＢは音声出力が伴うアプリ（例えば、音楽再生を実現するアプリ）であることを表わしている。
【００５０】
また、アプリＣは映像出力、データ入力、データ出力が伴うアプリ（例えば、メール機能を実現するアプリ）であることを表わしている。映像出力、データ出力共に○が付いているが、これはデータをすぐに映像として出力することがあるし、データをメモリに格納し後で利用することもあることを示している。アプリ種別管理テーブルはアプリが決まれば一意に定めることができる。
【００５１】
図５は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。アプリの共存の可能／不能の組み合わせテーブルは、各アプリが持つ性質（アプリ種別管理テーブルで定義）によって、同時動作（共存）が可能なもの、不能なものの組み合わせを示すテーブルである。
【００５２】
図５のテーブル内の「○」は共存可能、「×」は共存不能を表わしている。
【００５３】
ここで、アプリＡはアプリＢとは共存不能でアプリＣとは共存可能となる。アプリＢはアプリＡと共存不能でアプリＣとは共存可能となる。アプリＣは、アプリＡと共存可能でアプリＢと共存可能である。
【００５４】
アプリＡとアプリＢの共存不能の理由について説明する。アプリＡ、アプリＢは両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【００５５】
アプリＡとアプリＣが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。
【００５６】
図６は、優先度管理テーブルの一例を示す図である。優先度管理テーブルは、互いに共存が不能なアプリの場合に、どのアプリを優先して動作させるかを定義したものである。例えば、無線通信装置１００を車載で使用する場合、ユーザが運転中にも各種アプリを使用するため、音声ベースのアプリ、リアルタイム性の高いアプリが優先される。
【００５７】
なお、無線通信装置１００が存在する位置に応じて、アプリ優先順位の決め方を動的に変更することもできる。
【００５８】
現在動作中のアプリに対して優先度の高いアプリから割り込みが入ると、現在動作中のアプリは一時中断し、割り込みのあった優先度の高いアプリの動作を開始する。一方、現在アプリより優先度の低いアプリからの割り込みは許可しない。
【００５９】
図６では、お互いに共存不能なアプリＡ、アプリＢに関して、アプリＡの方が優先度が高いことを示している。
【００６０】
また、共存可能なアプリ同士の場合（例えば、アプリＡとアプリＣ）には優先度管理テーブルは作成しない。
【００６１】
なお、無線通信装置１００の初期化処理として図３の動作フロー図を説明したが、これに限らず、事前にアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブル、優先度管理テーブルを作成しておき、不揮発性メモリ等に格納しておき起動時に読み出すようにしても良い。
【００６２】
次に、アプリ起動に伴う状態管理処理の動作について、図７〜図８を用いて説明する。
【００６３】
図７はアプリ状態管理テーブル（詳しくは図８で説明）の更新動作を示す動作フロー図である。
【００６４】
図７において、ステップＳ２０１にてアプリ起動要求が発生したかどうかを判定する。
【００６５】
アプリ起動要求が発生していない場合（Ｓ２０１：Ｎｏ）、ステップＳ２０１の前に処理を戻す。
【００６６】
アプリ起動要求が発生した場合（Ｓ２０１：Ｙｅｓ）、ステップＳ２０２にて既に起動中のアプリがなしかどうかを判定する。
【００６７】
既に起動中のアプリがない場合（Ｓ２０２：Ｙｅｓ）、ステップ２０３にて起動要求のあったアプリを起動する。
【００６８】
ステップＳ２０２にて、既に起動中のアプリがある場合（Ｓ２０２：Ｎｏ）、ステップＳ２０５へ処理を移す。
【００６９】
ステップＳ２０５では、既に起動中のアプリと共存できるアプリであるかを判定する。
【００７０】
ステップＳ２０５の判定は、アプリの共存の可能／不能の組み合わせテーブルを参照する。
【００７１】
既に起動中のアプリと共存できるアプリの場合（Ｓ２０５：Ｙｅｓ）、ステップＳ２０６にて起動要求のあったアプリを起動する。
【００７２】
一方、既に起動中のアプリと共存できるアプリでない場合（Ｓ２０５：Ｎｏ）、ステップＳ２０７へ処理を移す。
【００７３】
ステップＳ２０７では、起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリであるかを判定する。
【００７４】
ここでステップＳ２０７の判定は、優先度管理テーブルを参照する。
【００７５】
起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリである場合（Ｓ２０７：Ｙｅｓ）、ステップＳ２０８にて現在起動中のアプリを待機状態へ遷移させ、起動要求のあったアプリを起動する。
【００７６】
一方、起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリでない場合（Ｓ２０７：Ｎｏ）、ステップＳ２０９へ処理を移す。ステップＳ２０９では、起動要求を受け付けず、終了する。ステップＳ２０４では、アプリ状態管理テーブルを更新する。
【００７７】
図８は、アプリ状態管理テーブルの一例を示す図である。アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【００７８】
また図８は、アプリＢが起動中、アプリＣが共存中の場合に、アプリＡの起動要求が発生し、アプリ状態管理テーブルが更新された場合を示している。このとき、図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【００７９】
なお、図８のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【００８０】
次いで、本発明の実施の形態１に係る無線通信装置のリンクロス（電波環境変化等に伴う通信途絶）発生時の動作について図９を用いて説明する。
【００８１】
図９は、本発明の実施の形態１に係る無線通信装置のリンクロス発生時の動作を示す動作フロー図である。
【００８２】
図９において、ステップＳ３０１ではリンクロスが発生したかどうかを判定する。リンクロスは、近距離無線通信部１０１にて検知する。
【００８３】
リンクロスが発生していない場合（Ｓ３０１：Ｎｏ）、Ｓ３０１の前に処理を戻す。リンクロスが発生した場合（Ｓ３０１：Ｙｅｓ）、ステップＳ３０２へ処理を移す。リンクロスが発生した場合にユーザへその旨を通知することもできる。
【００８４】
ステップＳ３０２では、対向無線通信装置２００とのリンクロス復旧処理を試み、復旧できたかどうかを判定する。
【００８５】
リンクロスから復旧できなかった場合（Ｓ３０２：Ｎｏ）、ステップＳ３０３へ処理を移す。
【００８６】
ステップＳ３０３では、所定時間経過したかどうかを判定する。所定時間経過していない場合（Ｓ３０３：Ｎｏ）は、ステップＳ３０２の前に処理を戻す。
【００８７】
一方、所定時間経過した場合（Ｓ３０３：Ｙｅｓ）は、ステップＳ３０６へ処理を移す。
【００８８】
ステップＳ３０６では、アプリ状態管理テーブルをクリア（記憶した各アプリの状態を消去）する。
【００８９】
一方、リンクロスから復旧できた場合（Ｓ３０２：Ｙｅｓ）、ステップＳ３０４へ処理を移す。ステップＳ３０４では、リンクロス前のアプリ状態管理テーブルを読みだす。
【００９０】
次いで、読み出したアプリ状態管理テーブルに従い各アプリをリンクロス前の状態へ復旧させる（Ｓ３０５）。このとき、リンクロス前に起動中であったアプリ（図８の例でいくとアプリＡ）を優先して復旧させる。
【００９１】
ステップＳ３０２→Ｓ３０３→Ｓ３０６のようなパスがあるのは、対向無線通信装置がバッテリーで駆動しているような場合にバッテリー切れ等によりリンクロス復旧ができな
いような場合が存在するためである。
【００９２】
以上、説明した無線通信装置によれば、複数機能の同時動作（マルチプロファイル）の作動状況で、リンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従いリンクロス前に起動中であったアプリだけでなく、待機状態のアプリ、共存状態のアプリも適切に復旧するので、ユーザ利便性を高める無線通信装置を提供することができる。
【００９３】
上記実施の形態で説明した構成は、単に具体例を示すものであり、本願発明の技術的範囲を制限するものではない。本願の効果を奏する範囲において、任意の構成を採用することが可能である。
【００９４】
また、近距離無線通信規格としてＢｌｕｅｔｏｏｔｈ（登録商標）を例に説明したが、無線ＬＡＮ等でも有用である。
（実施の形態２）
以下、本発明の実施の形態２に係る車載装置について図面を参照しながら説明する。なお、各図面において、本発明に関係のない構成要素は省略している。
【００９５】
図１０は、本発明の実施の形態２に係る車載装置３００の全体構成を示すブロック図である。
【００９６】
図１０において、車載装置３００は実施の形態１の無線通信装置１００と同様の構成要素を有しており、省略している。また各構成要素の説明を省略する。
【００９７】
さらに、車載装置３００は図示しない道路や交差点に関するデータ等の地図情報を格納したデータベース、ＧＰＳ（Global Positioning System）などの測位手段、公知の経路探索、誘導案内を行うプログラム等を含んでおり、映像出力部１０６に地図を表示するとともに自車位置の表示更新、地図上への経路の重畳表示、案内対象交差点手前では音声による誘導案内等を行うことができる。
【００９８】
携帯端末４００は、車載装置３００が搭載される車両を利用する運転者が所持している例えば携帯電話であり、車両内に持込まれる。また車載装置３００と近距離無線通信路を確立して、複数のアプリケーション（以下、アプリケーションを単にアプリと称する）機能に係わる通信を行う。近距離無線通信路は、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格に準拠する通信路である。
【００９９】
車載装置３００は携帯端末４００と近距離無線通信を行うことで、公衆網１の先につながるユーザと通話するためのハンズフリー通話機能、携帯端末４００の電話帳データを車載装置３００へ転送する電話帳転送機能、携帯端末４００に蓄積されたオーディオを車載装置３００でストリーミング再生するストリーミング再生機能、携帯端末４００のゲートウェイ機能を使用し外部のネットワーク（公衆網１）とＷＥＢブラウズ等のデータ通信を行うデータ通信（ダイヤルアップ通信）機能、携帯端末４００のゲートウェイ機能を使用し外部のネットワークとメッセージ通信を行うメッセージ通信機能などを備える。
【０１００】
これらの機能を実行するにあたり、Ｂｌｕｅｔｏｏｔｈ（登録商標）プロファイルを用い（詳細は後述する）、車載装置３００と携帯端末４００は複数のプロファイルが同時接続可能に構成されている。
【０１０１】
図１１は、車載装置３００の通信レイヤ構造をそれぞれモデル化した階層図である。第３の通信レイヤ構造３０（車載装置３００の近距離無線通信部１０１が備えるＢｌｕｅｔｏｏｔｈ（登録商標）プロトコルスタックの階層図）と同様の構成を持つ通信レイヤが携
帯端末４００にも存在するが図１１では省略している。
【０１０２】
図１１において、ＲＦ（Radio Frequency）は、実際に無線通信を行うレイヤであり、２．４ＧＨｚ帯で通信を行うための変調モードの定義、トランスミッタの特性（最大送信電力など）、レシーバーの特性（感度など）などを定義する。
【０１０３】
Ｂａｓｅ ｂａｎｄは、無線通信を実現するためにさまざまな処理（リンク制御、パケット管理、誤り訂正、チャネル制御など）が行われるレイヤである。ＲＦからの信号をデジタル化して上位レイヤに引き渡す役目を持つ。Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイス間のメディア アクセスと物理レイヤの手順を規定する。
【０１０４】
ＬＭＰ（Link Manager Protocol）は、２台のデバイス間における Ｂｌｕｅｔｏｏｔｈ（登録商標）接続のすべての側面（接続、認証、暗号化、省電力制御など）を制御し、ネゴシエートするために使用する。
【０１０５】
ＨＣＩ（Host Controller Interface）は、ベースバンドコントローラとリンクマネージャにコマンドインタフェースを提供し、構成パラメータにアクセスするためのインタフェースを提供する。
【０１０６】
Ｌ２ＣＡＰ（Logical Link Control and Adaptation Protocol）は、上位プロトコルの多重化、パケットのセグメント化と再構築、およびサービス品質情報の送信をサポートする。
【０１０７】
ＲＦＣＯＭＭは、シリアルケーブルの設定と、ＲＳ−２３２Ｃシリアルポートをエミュレートするために使用する。
【０１０８】
ＯＢＥＸ（Object Exchange）は、２台のデバイスがオブジェクトの交換に使用できる通信プロトコルであり、多様なデータやコマンドを交換できるように定義されている。
【０１０９】
ＡＶＤＴＰ（Audio/Video Distribution Transport Protocol）は、Ａ/Ｖ ストリームのネゴシエーション手順、確認手順、および伝送手順が定義されている。
【０１１０】
ＡＶＣＴＰ（Audio/Video Control Transport Protocol）は、Ａ/Ｖデバイスの制御メッセージを交換するトランスポート メカニズムが定義されている。
【０１１１】
ＧＡＶＤＰ（General Audio/Video Distribution Profile）は、Ａ２ＤＰの基礎として機能し、ビデオ ストリームとオーディオ ストリームを配信するために使用する。
【０１１２】
Ａ２ＤＰ（Advanced Audio Distribution Profile）は、ステレオ品質のオーディオをメディア ソースからメディア シンクにストリーミングするために使用する。車載装置３００はシンクとして振る舞う。携帯端末４００はソースとして振る舞う。
【０１１３】
ＡＶＲＣＰ（Audio/Video Remote Control Profile）は、オーディオストリーミングのリモコン制御を行うために使用する。車載装置３００はコントローラとして振る舞う。携帯端末４００はターゲットとして振る舞う。
【０１１４】
ＯＰＰ（Object Push Profile）は、オブジェクト伝送のためのプロファイルであり、電話帳データの転送のために使用する。車載装置３００はサーバーとして振る舞う。携帯端末４００はクライアントとして振る舞う。
【０１１５】
ＰＢＡＰ（Phone Book Access Profile）は、電話帳データ、発着信履歴データの転送のために使用する。車載装置３００はクライアントとして振る舞う。携帯端末４００はサーバーとして振る舞う。
【０１１６】
なお、電話帳転送には、ＯＰＰ又はＰＢＡＰいずれか任意のプロファイルを用いることができる。
【０１１７】
ＭＡＰ（Message Access Profile）は、メッセージ情報の交換のために使用する。車載装置３００はクライアントとして振る舞う。携帯端末４００はサーバーとして振る舞う。
【０１１８】
ＨＦＰ（Hands Free Profile）は、ハンズフリー通話機能を実現するために使用する。車載装置３００はハンズフリーとして振る舞う。携帯端末４００はオーディオゲートウェイとして振る舞う。
【０１１９】
ＤＵＮ（Dial-Up Networking Profile）は、インターネットや他のダイヤルアップ サービスにアクセスするために使用する。車載装置３００はデータターミナルとして振る舞う。携帯端末４００はゲートウェイとして振る舞う。
【０１２０】
ＳＤＰ（Service Discovery Protocol）は、車載装置３００と携帯端末４００が互いにどのようなサービスをサポートしているのか検索するために使用する。
【０１２１】
ＧＡＰ（Generic Access Profile）は、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応デバイス間のベースバンドリンクを確立するための手法が定義されている。
【０１２２】
ＡＶＰアプリは、携帯端末４００に蓄積されたオーディオを車載装置３００でストリーミング再生するストリーミング再生機能を実現するアプリである。
【０１２３】
ＰＢＡＰアプリは、車載装置３００から携帯端末４００の電話帳データを取得する電話帳転送機能を実現するアプリである。
【０１２４】
ＯＰＰアプリは、携帯端末４００から車載装置３００へ電話帳データを送信する電話帳転送機能を実現するアプリである。
【０１２５】
ＭＡＰアプリは、携帯端末４００のゲートウェイ機能を使用し外部のネットワークとメッセージ通信を行うメッセージ通信機能を実現するアプリである。
【０１２６】
ＨＦＰアプリは、公衆網１の先につながるユーザと通話するためのハンズフリー通話機能を実現するためのアプリである。
【０１２７】
ＤＵＮアプリは、携帯端末４００のゲートウェイ機能を使用し外部のネットワークとＷＥＢブラウズ等のデータ通信を行うデータ通信（ダイアルアップ通信）機能を実現するアプリである。
【０１２８】
管理アプリは、携帯端末４００とペアリングしてデバイス登録をしたり、車載装置３００周辺に存在するＢｌｕｅｔｏｏｔｈ（登録商標）相手機器を探索して、相手機器の持つサービス情報を取得したりするアプリである。
【０１２９】
管理アプリは全てのアプリの基本となるアプリであり、常時起動されている。
【０１３０】
上記説明したアプリは、近距離無線通信路を介して携帯端末４００の同じアプリ同士が
連携して動作する。
【０１３１】
例えば、第３の通信レイヤ構造３０のＨＦＰアプリと携帯端末４００のＨＦＰアプリがそれぞれの役割を持ち、各種通信データのやり取りを行い動作する。
【０１３２】
なお、この図では一例として７つのアプリを示しているが、これに限定するものではない。他に規定されるＢｌｕｅｔｏｏｔｈ（登録商標）プロファイルに従い、別のアプリを追加することもできる。
【０１３３】
ＲＦ、Ｂａｓｅ ｂａｎｄ、ＬＭＰ、ＨＣＩは近距離無線通信部１０１として動作し、Ｌ２ＣＡＰ以上は、制御部１０２で動作するプログラムとして実現される。なお、Ｌ２ＣＡＰ〜各プロファイル階層までを近距離無線通信部１０１上で動作するようにしてもよい。
【０１３４】
次に、車載装置３００の起動時の初期化処理については図３で説明した実施の形態１と同様のためその説明を省略する。
【０１３５】
ここで、ＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブル、優先度管理テーブルの一例について図１２〜図１４を用いて説明する。
【０１３６】
図１２は、ＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。アプリ種別管理テーブルは各アプリ毎にどのような入出力を伴うかをテーブル化したものである。横軸は各アプリであり、縦軸はアプリ種別として、音声出力、音声入力、映像入力、映像出力、データ入力、データ出力、・・・となる。
【０１３７】
図１２のテーブル内の「○」は入出力を伴う。「×」は伴わないことを表わしている。
【０１３８】
ここで、ＨＦＰアプリは音声入力と音声出力が○となっており、その他は×となっている。これは、ＨＦＰアプリは電話機能を実現するアプリであり、音声入力と音声出力が伴うアプリであることを表わしている。
【０１３９】
また、ＡＶＰアプリは音声出力のみが○となっている。これは、ＡＶＰアプリはオーディオのストリーミング再生機能を実現する音声出力が伴うアプリであることを表わしている。
【０１４０】
また、ＤＵＮアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはデータをすぐに映像として出力（ブラウザ等への表示）することがあるし、データをメモリに格納し後で利用することもあることを示している。なお、ＤＵＮアプリはＰＡＮアプリと代替可能である。
【０１４１】
ここではＤＵＮアプリはインターネットへ接続しブラウザ表示するものとして説明する。アプリ種別管理テーブルはアプリが決まれば一意に定めることができる。
【０１４２】
図１３は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。
【０１４３】
アプリの共存の可能／不能の組み合わせテーブルは、各アプリが持つ性質（アプリ種別管理テーブルで定義）によって、同時動作（共存）が可能なもの、不能なものの組み合わせを示すテーブルである。
【０１４４】
図１３テーブル内の「○」は共存可能、「×」は共存不能を表わしている。
【０１４５】
ここで、ＨＦＰアプリはＡＶＰアプリとは共存不能でＤＵＮアプリとは共存可能となる。ＡＶＰアプリはＨＦＰアプリと共存不能でＤＵＮアプリとは共存可能となる。ＤＵＮアプリは、ＨＦＰアプリと共存可能でＡＶＰアプリと共存可能である。
【０１４６】
ＨＦＰアプリとＡＶＰアプリの共存不能の理由について説明する。これはＨＦＰアプリ、ＡＶＰアプリ両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【０１４７】
ＨＦＰアプリとＤＵＮアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。
【０１４８】
図１４は、優先度管理テーブルの一例を示す図である。優先度管理テーブルは、互いに共存が不能なアプリの場合はどのアプリを優先して動作させるかを定義したものである。
【０１４９】
現在動作中のアプリに対して優先度の高いアプリから割り込みが入ると、現在動作中のアプリは一時中断し、割り込みのあった優先度の高いアプリの動作を開始する。一方、現在アプリより優先度の低いアプリからの割り込みは許可しない。
【０１５０】
図１４では、お互いに共存不能なＨＦＰアプリ、ＡＶＰアプリに関して、ＨＦＰアプリの方が優先度が高いことを示している。ＨＦＰアプリが優先されるのはＡＶＰアプリに比べて、ハンズフリー通話という双方向の音声通信が伴うリアルタイム性の高いアプリであるためである。
【０１５１】
また、共存可能なアプリ同士の場合（例えば、ＨＦＰアプリとＤＵＮアプリの組み合わせ）には優先度管理テーブルは作成しない。
【０１５２】
次いで、アプリの起動に伴う状態管理処理の動作については、図７と同様のためその説明を省略する。
【０１５３】
図１５は、図７の動作フロー図のステップＳ２０４にて更新されるアプリ状態管理テーブルの一例を示す図である。
【０１５４】
アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【０１５５】
また図１５は、ＡＶＰアプリが起動中（オーディオストリーミング再生中）、ＤＵＮアプリが共存中（データ通信中）の場合に、ＨＦＰアプリの起動要求（例えばハンズフリー着信）が発生し、アプリ状態管理テーブルが更新された場合を示している。
【０１５６】
このとき、ＨＦＰアプリにて着信を受け付けると通話中の状態となり、ＡＶＰアプリは一時停止中状態となり、ＤＵＮアプリはデータ通信中の状態となる。図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【０１５７】
ここで、管理アプリは全てのアプリの基本となるアプリであり起動されている。管理アプリは図１５のアプリ状態管理テーブルの対象から外している。
【０１５８】
なお、図１５のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【０１５９】
次いで、本発明の実施の形態２に係る無線通信装置のリンクロス発生時の動作については図９と同様のためその説明を省略する。
【０１６０】
ここで、図９の動作フロー図ステップＳ３０５における各アプリを復旧させる動作について、図１６を用いてより詳細に説明する。
【０１６１】
図１６は、車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。リンクロス前のアプリ状態管理テーブルを図１５に示す状態であるものとする。
【０１６２】
図１６において、ステップＳ４０１にて、ハンズフリー（ＨＦＰアプリ）をサービスレベル（ＳＬＣ）接続状態に復旧させる。
【０１６３】
次いで、携帯端末側で通話状態が継続されているかを判定する（ステップＳ４０２）。なお、通話状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１６４】
携帯端末側で通話状態が継続されていない場合（Ｓ４０２：Ｎｏ）、ステップＳ４０４へ処理を移す。
【０１６５】
携帯端末側で通話状態が継続されている場合（Ｓ４０２：Ｙｅｓ）、ハンズフリーを通話状態へ復旧させる。
【０１６６】
ステップＳ４０４では、オーディオストリーミング（ＡＶＰアプリ）をサービス接続状態へ復旧させる。
【０１６７】
次いで、携帯端末側でオーディオストリーミングの一時停止状態が継続されているかを判定する（ステップＳ４０５）。なお、一時停止状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１６８】
携帯端末側でオーディオストリーミングの一時停止状態が継続されていない場合（Ｓ４０５：Ｎｏ）、ステップＳ４０７へ処理を移す。
【０１６９】
携帯端末側でオーディオストリーミングの一時停止状態が継続されている場合（Ｓ４０５：Ｙｅｓ）、オーディオストリーミング（ＡＶＰアプリ）を一時停止状態へ復旧させる。
【０１７０】
ステップＳ４０７では、データ通信（ＤＵＮアプリ）をサービス接続状態へ復旧させる。
【０１７１】
次いで、携帯端末側でデータ通信の共存状態が継続されているかを判定する（ステップＳ４０８）。なお、共存状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１７２】
携帯端末側でデータ通信の共存状態が継続されていない場合（Ｓ４０８：Ｎｏ）、処理を終了する。
【０１７３】
携帯端末側でデータ通信の共存状態が継続されている場合（Ｓ４０８：Ｙｅｓ）、データ通信（ＤＵＮアプリ）を共存状態へ復旧させる（ＷＥＢブラウズ中の継続データが受信され、ＷＥＢページが表示される）。
【０１７４】
これにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＤＵＮアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。
【０１７５】
また、図１６の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にデータ通信状態を維持する。
【０１７６】
また、ＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリの３つのプロファイルがマルチプロファイルで動作する場合について説明したが、マルチプロファイル動作（ＨＦＰアプリ／ＡＶＰアプリ）においても同様に実施できる。このとき上記説明した図１５に示すアプリ状態管理テーブルの共存アプリ１に該当するアプリが何もない状態となる。そして、図１６のＳ４０７〜Ｓ４０９の処理が省かれることになる。
（変形例１）
本発明の実施の形態２の変形例１について、図１７〜図２０を用いて説明する。
【０１７７】
まず、ＨＦＰアプリ、ＡＶＰアプリ、ＰＢＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブルの一例について図１７〜図１８を用いて説明する。
【０１７８】
優先度管理テーブルは図１４と同様のため説明を省略する。
【０１７９】
図１７は、ＨＦＰアプリ、ＡＶＰアプリ、ＰＢＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。
【０１８０】
ＰＢＡＰアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これは電話帳データをすぐに映像として出力（例えば、電話帳のリスト表示）することがあるし、電話帳データをメモリに格納し後で利用することもあることを示している。
【０１８１】
図１８は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。
【０１８２】
ここで、ＨＦＰアプリはＡＶＰアプリとは共存不能でＰＢＡＰアプリとは共存可能となる。ＡＶＰアプリはＨＦＰアプリと共存不能でＰＢＡＰアプリとは共存可能となる。ＰＢＡＰアプリは、ＨＦＰアプリと共存可能でＡＶＰアプリと共存可能である。
【０１８３】
ＨＦＰアプリとＡＶＰアプリの共存不能の理由について、これはＨＦＰアプリ、ＡＶＰアプリ両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【０１８４】
ＨＦＰアプリとＰＢＡＰアプリが共存可能であるのは、アプリ種別管理テーブルからも
分かる通り、アプリが持つ性質の重複が無いためである。
【０１８５】
次いで、アプリの起動に伴う状態管理処理の動作について、図７と同様のためその説明を省略する。
【０１８６】
図１９は、図７の動作フロー図のステップＳ２０４にて更新されるアプリ状態管理テーブルの一例を示す図である。
【０１８７】
アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【０１８８】
また図１９は、ＡＶＰアプリが起動中（オーディオストリーミング再生中）、ＰＢＡＰアプリが共存中（電話帳転送中）の場合に、ＨＦＰアプリの起動要求（例えばハンズフリー着信）が発生し、アプリ状態管理テーブルが更新された場合を示している。
【０１８９】
このとき、ＨＦＰアプリにて着信を受け付けると通話中の状態となり、ＡＶＰアプリは一時停止中状態となり、ＰＢＡＰアプリは電話帳転送中の状態となる。図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【０１９０】
なお、図１９のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【０１９１】
次いで、本発明の実施の形態２（変形例１）に係る車載装置のリンクロス発生時の動作については実施の形態１で説明した図９と同様のためその説明を省略する。
【０１９２】
ここで、図９の動作フロー図ステップＳ３０５における各アプリを復旧させる動作について、図２０を用いてより詳細に説明する。
【０１９３】
図２０は、車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。
【０１９４】
リンクロス前のアプリ状態管理テーブルを図１９に示す状態であるものとする。
【０１９５】
図２０において、ステップＳ４０１〜ステップＳ４０６までの動作については、図１６と同様のためその説明を省略する。
【０１９６】
ステップＳ５０１では、電話帳転送（ＰＢＡＰアプリ）をサービス接続状態へ復旧させる。
【０１９７】
次いで、携帯端末側で電話帳転送の共存状態が継続されているかを判定する（ステップＳ５０２）。なお、共存状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１９８】
携帯端末側で電話帳転送の共存状態が継続されていない場合（Ｓ５０２：Ｎｏ）、処理を終了する。この場合は、電話帳データを再度はじめから転送する必要がある。
【０１９９】
携帯端末側で電話帳転送の共存状態が継続されている場合（Ｓ５０２：Ｙｅｓ）、電話
帳転送（ＰＢＡＰアプリ）を共存状態へ復旧させ、電話帳データの続きから転送する。
【０２００】
これにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＰＢＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。
【０２０１】
また、図２０の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共に電話帳転送状態を維持する。
（変形例２）
本発明の実施の形態２の変形例２について、図２１〜図２４を用いて説明する。
【０２０２】
まず、ＨＦＰアプリ、ＡＶＰアプリ、ＭＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブルの一例について図２１〜図２２を用いて説明する。
【０２０３】
優先度管理テーブルは図１４と同様のため説明を省略する。
【０２０４】
図２１は、ＨＦＰアプリ、ＡＶＰアプリ、ＭＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。
【０２０５】
ＭＡＰアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはメッセージデータをすぐに映像として出力（例えば、メッセージリスト又はメッセージ本文表示）することがあるし、メッセージデータをメモリに格納し後で利用することもあることを示している。ここでメッセージデータとはＳＭＳ、Ｅ−Ｍａｉｌ等を指す。
【０２０６】
図２２は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。
【０２０７】
ここで、ＨＦＰアプリはＡＶＰアプリとは共存不能でＭＡＰアプリとは共存可能となる。ＡＶＰアプリはＨＦＰアプリと共存不能でＭＡＰアプリアプリとは共存可能となる。ＭＡＰアプリは、ＨＦＰアプリと共存可能でＡＶＰアプリと共存可能である。
【０２０８】
ＨＦＰアプリとＡＶＰアプリの共存不能の理由について説明する。ＨＦＰアプリ、ＡＶＰアプリ両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【０２０９】
ＨＦＰアプリとＭＡＰアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。
【０２１０】
次いで、アプリの起動に伴う状態管理処理の動作について、図７と同様のためその説明を省略する。
【０２１１】
図２３は、図７の動作フロー図のステップＳ２０４にて更新されるアプリ状態管理テーブルの一例を示す図である。
【０２１２】
アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【０２１３】
また図２３は、ＡＶＰアプリが起動中（オーディオストリーミング再生中）、ＭＡＰアプリが共存中（メッセージ転送中）の場合に、ＨＦＰアプリの起動要求（例えばハンズフリー着信）が発生し、アプリ状態管理テーブルが更新された場合を示している。
【０２１４】
このとき、ＨＦＰアプリにて着信を受け付けると通話中の状態となり、ＡＶＰアプリは一時停止中状態となり、ＭＡＰアプリはメッセージ転送中の状態となる。図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【０２１５】
なお、図２３のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【０２１６】
次いで、本発明の実施の形態２（変形例２）に係る車載装置のリンクロス発生時の動作については実施の形態１で説明した図９と同様のためその説明を省略する。
【０２１７】
ここで、図９の動作フロー図ステップＳ３０５における各アプリを復旧させる動作について、図２４を用いてより詳細に説明する。
【０２１８】
図２４は、車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。
【０２１９】
リンクロス前のアプリ状態管理テーブルを図２３に示す状態であるものとする。
【０２２０】
図２４において、ステップＳ４０１〜ステップＳ４０６までの動作については、図１６と同様のためその説明を省略する。
【０２２１】
ステップＳ６０１では、メッセージ転送（ＭＡＰアプリ）をサービス接続状態へ復旧させる。
【０２２２】
次いで、携帯端末側でメッセージ転送の共存状態が継続されているかを判定する（ステップＳ６０２）。なお、共存状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０２２３】
携帯端末側でメッセージ転送の共存状態が継続されていない場合（Ｓ６０２：Ｎｏ）、処理を終了する。この場合は、メッセージデータを再度一から転送する必要がある。
【０２２４】
携帯端末側でメッセージ転送の共存状態が継続されている場合（Ｓ５０２：Ｙｅｓ）、メッセージ転送（ＭＡＰアプリ）を共存状態へ復旧させ、メッセージデータの続きから転送する。
【０２２５】
これにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＭＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。
【０２２６】
また、図２４の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持する。
【０２２７】
以上、説明した車載装置によれば、複数機能の同時動作（マルチプロファイル）の作動状況で、リンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従いリンクロス前に起動中であったアプリだけでなく、待機状態のアプリ、共存状態のアプリも適切に復旧するので、ユーザ利便性を高める車載装置を提供することができる。
【０２２８】
なお、図１０では車載装置３００と携帯端末４００が１対１で接続されるポイントツーポイントのマルチプロファイルについて説明したが、これに限らず車載装置３００と複数の携帯端末が１対多で接続されるポイントツーマルチポイントのマルチプロファイルにおいても同様に適用できる。
【０２２９】
上記説明では、マルチプロファイル動作の組み合わせとして、ＨＦＰアプリ／ＡＶＰアプリ／ＤＵＮアプリ、ＨＦＰアプリ／ＡＶＰアプリ／ＰＢＡＰアプリ、ＨＦＰアプリ／ＡＶＰアプリ／ＭＡＰアプリを一例として説明したが、これに限らず、図２５、図２６に示すような他の組み合わせでも実施できる。
【０２３０】
図２５はリンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルＮｏ．１である。
【０２３１】
図２６はリンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルＮｏ．２（Ｎｏ．１からの継続）である。
【０２３２】
また、３つのプロファイル同士の組み合わせだけでなく、４つのプロファイルの組み合わせ、例えば、同時にＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリ、ＰＢＡＰアプリとを接続し、同時動作する場合のリンクロス時に対しても、同様に適用できる。
【０２３３】
また、図示しない走行状態検知手段（例えば、車速センサ）によって車両の走行状態を判別し、リンクロスからの復旧制御をよりきめ細かく行うこともできる。
【０２３４】
また、リンクロス復旧前の状態に適切に復旧できたか否かを区別して音声等でユーザへ報知するようにしても良い。これにより、ユーザが運転中で車載ディスプレイへ視線を移動することなく、リンクロス前の状態に正常復帰したのか否かを判断することができる。
【０２３５】
また、近距離無線通信規格としてＢｌｕｅｔｏｏｔｈ（登録商標）を例に説明したが、無線ＬＡＮ等でも有用である。
【０２３６】
上記実施の形態で説明した構成は、単に具体例を示すものであり、本願発明の技術的範囲を制限するものではない。本願の効果を奏する範囲において、任意の構成を採用することが可能である。
【０２３７】
以上の説明において、リンクロス検知手段は近距離無線通信部１０１（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール）及び制御部１０２（例えば、ＣＰＵ）で動作するソフトウェアに対応しており、近距離無線通信部１０１としてのＢｌｕｅｔｏｏｔｈ（登録商標）モジュールがリンクロスを検知し制御部１０２としてのＣＰＵ側へ通知される。
【０２３８】
アプリ状態記憶手段は、記憶部１０９（メモリ等）に対応しており、図８に示すアプリ状態管理テーブルを記憶する。
【０２３９】
復旧手段は、近距離無線通信部１０１及び制御部１０２としてのＣＰＵで動作するソフトウェアに対応しており、リンクロスを検知した後、無線通信路を復旧する。
【０２４０】
アプリ復旧手段は、近距離無線通信部１０１及び制御部１０２としてのＣＰＵで動作するソフトウェアに対応しており、リンクロス前の各アプリを復旧させる。
【０２４１】
接続手段は、近距離通信部１０１（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール）及び制御部１０２（例えば、ＣＰＵ）で動作するソフトウェアに対応している。
【０２４２】
制御手段は、近距離無線通信部１０１を制御する制御部１０２（例えば、ＣＰＵ）で動作するソフトウェアに対応している。
【０２４３】
以上のとおり、本発明の無線通信装置は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする。
【０２４４】
この構成を有することにより、複数のアプリケーションがリンクロス前に動作していてもアプリ状態記憶手段に記憶されているアプリ記憶状態に従いアプリケーションの復旧を行うことができる。
【０２４５】
さらに、本発明の無線通信装置は、アプリ状態記憶手段が記憶するアプリ状態は、リンクロス直前の現在起動中のアプリか否か、一時待機中であるか否か、現在起動中のアプリと共存動作ができる共存中であるか否かを含むことを特徴とする。
【０２４６】
これにより、各アプリのリンクロス前の状態へ適切に復旧することができ、リンクロス直前に起動中のアプリだけでなく、一時待機中、共存中であったアプリも確実に復旧することができる。また、現在起動中のアプリが終了した際には一時待機中であったアプリが次に起動できるようになり、リンクロスを挟むことにより状態がおかしくなる現象を回避できる。
【０２４７】
さらに、本発明の無線通信装置は、復旧手段によって、リンクロス後無線通信路が所定の時間内で復旧できない場合にはアプリ状態をクリアすることを特徴とする。
【０２４８】
これにより、対向無線通信装置がバッテリーで駆動しているような場合にバッテリー切れ等によりいつまでもリンクロス復旧ができないような場合にはアプリ状態がクリアされるので、無線通信装置がいつまでもアプリ状態を記憶しておかずに済む。またバッテリー切れによるリンクロス後、バッテリーが充電された後に対向無線通信装置と接続確立した際に、無線通信装置がおかしな挙動をすることを回避できる。
【０２４９】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとを同時に接続してオーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオ
ストリーミング音声を一時停止状態から再生状態へ遷移させることを特徴とする。
【０２５０】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５１】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルと、携帯端末のゲートウェイ機能を使用し外部のネットワークとデータ通信を実現するためのダイヤルアップ通信プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとダイヤルアップ通信プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつダイヤルアップ通信プロトコルがデータ通信状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、データ通信状態を維持させることを特徴とする。
【０２５２】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＤＵＮアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５３】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にある電話帳データをダウンロードするための電話帳転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルと電話帳転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつ電話帳転送プロトコルが電話帳データ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、電話帳転送状態を維持することを特徴とする。
【０２５４】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＰＢＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５５】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にあるメッセージデータをダウンロードするためのメッセージ転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制
御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとメッセージ転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつメッセージ転送プロトコルがメッセージデータ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持することを特徴とする。
【０２５６】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＭＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５７】
本発明のリンクロス復旧方法は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置のリンクロス復旧方法において、前記無線装置の制御部に、無線通信路のリンクロスを検知するリンクロス検知ステップと、リンクロス前の複数のアプリケーションの状態を記憶するアプリ状態記憶ステップと、前記リンクロス検知手段がリンクロスを検知した後、無線通信路を復旧する復旧ステップと、前記復旧ステップにて無線通信路を復旧した後、前記アプリ状態記憶ステップにて記憶したアプリ記憶状態に従ってアプリケーションの復旧を行うアプリ復旧ステップと、を実行させることを特徴とする。
【０２５８】
この構成を有することにより、複数のアプリケーションがリンクロス前に起動していてもアプリ状態記憶手段に記憶されているアプリ記憶状態に従いアプリケーションの復旧を行うことができる。
【産業上の利用可能性】
【０２５９】
本発明の無線通信装置は、車両内に搭載するハンズフリー装置、カーナビゲーション装置、カーマルチメディア端末、携帯電話、ＰＨＳなどの携帯端末等として有用である。
【符号の説明】
【０２６０】
１ 公衆網
１０ 第１の通信レイヤ構造
２０ 第２の通信レイヤ構造
３０ 第３の通信レイヤ構造
１００ 無線通信装置
１０１ 近距離無線通信部
１０２ 制御部
１０３ 音声入力部
１０４ 音声出力部
１０５ 映像入力部
１０６ 映像出力部
１０７ データ入力部
１０８ データ出力部
１０９ 記憶部
２００ 対向無線通信装置
３００ 車載装置
４００ 携帯端末
【技術分野】
【０００１】
本発明は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信に係わり、リンクロス（電波環境変化等に伴う通信途絶）時の復旧を容易にする無線通信装置および車載装置およびリンクロス復旧方法に関する。
【背景技術】
【０００２】
従来より、近距離での無線通信により、各種機器間でデータを送受信する技術としてＢｌｕｅｔｏｏｔｈ（登録商標）がある。Ｂｌｕｅｔｏｏｔｈ（登録商標）は２．４ＧＨｚの周波数帯を用いる規格であり、十メートル程度の範囲内で無線通信が可能である。
【０００３】
一例として、携帯電話とカーナビゲーションに代表される車載装置とがＢｌｕｅｔｏｏｔｈ（登録商標）を用いて接続し、ハンズフリー通話やオーディオ転送を行う機能が実現されている（例えば、特許文献１参照）。
【０００４】
Ｂｌｕｅｔｏｏｔｈ（登録商標）規格では、プロファイルというアプリケーションとして作動するために必要な機能、振る舞いが規定されており、例えばハンズフリー機能を実現するためのハンズフリープロファイル（ＨＦＰ）、オーディオ転送を行うオーディオプロファイル（Ａ２ＤＰ／ＡＶＲＣＰ）、電話回線を用いたダイヤルアップ接続によるデータ通信を実現するためのダイヤルアップネットワークプロファイル（ＤＵＮ）等がある。
【０００５】
無線通信装置同士で複数のプロファイルを同時に接続して、複数のアプリケーション機能を同時利用する場合（所謂、マルチプロファイル）がある。
【０００６】
一方、このような複数のアプリケーションを同時利用する場合において、アプリケーションが持つ性質によって、同時動作が可能なもの、不能なものの組み合わせがあることが一般的に知られている。同時動作可能とは、例えば、アプリＡ、アプリＢがあったときに、アプリＡ、Ｂ共に動作できる組み合わせであることを表わし、同時動作不能とは例えば、アプリＡ、アプリＣがあったときにどちらか一方のアプリしか同時には作動できないことを表わす。
【０００７】
また、通信路が無線であるためにリンクロス（電波環境変化等に伴う通信途絶）が発生することが想定される。
【０００８】
マルチプロファイルの作動状況で、リンクロスが発生した場合に、無線通信装置は上記アプリケーションの同時動作可能／不能な組み合わせがあるために、どの状態にまで復旧すればよいのか判断できないといった問題がある。このため、同時動作不能のアプリＡ、アプリＣがあり、アプリＡが現在動作中のアプリで、アプリＣが現在一時停止中のアプリであるときに、リンクロスが発生すると、直前に起動していたアプリであるアプリＡの復旧は行えても、それ以前に起動しており、リンクロス直前には一時停止状態であったアプリＣの復旧までは行うことができないという問題があった。
【０００９】
また、以上のような問題は単にＢｌｕｅｔｏｏｔｈ（登録商標）とプロファイルとの関係のみならず近距離無線通信装置と、当該近距離無線通信装置が相手との通信によって実現する機能との関係においても発生しうる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００６−１４８８６４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
そこで、本発明は上記問題に鑑みてなされた。すなわち、複数機能の同時動作（マルチプロファイル）の作動状況で、リンクロスが発生した場合に、復旧を容易にし、ユーザ利便性を高める無線通信装置および車載装置およびリンクロス復旧方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するために本発明の無線通信装置は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なう構成を採る。
【発明の効果】
【００１３】
本発明によれば、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信に係わり、リンクロス時の復旧を容易にする無線通信装置および車載装置を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施の形態１に係る無線通信装置の全体構成を示すブロック図
【図２】無線通信装置１００と対向無線通信装置２００の通信レイヤ構造をモデル化した階層図
【図３】無線通信装置起動時の初期化処理を示す動作フロー図
【図４】本発明の実施の形態１に係るアプリ種別管理テーブルの一例を示す図
【図５】本発明の実施の形態１に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図６】本発明の実施の形態１に係る優先度管理テーブルの一例を示す図
【図７】本発明の実施の形態１に係るアプリ状態管理テーブルの更新動作を示す動作フロー図
【図８】本発明の実施の形態１に係るアプリ状態管理テーブルの一例を示す図
【図９】本発明の実施の形態１に係る無線通信装置のリンクロス発生時の動作を示す動作フロー図
【図１０】本発明の実施の形態２に係る車載装置３００と携帯端末４００の全体構成を示す模式図
【図１１】車載装置の近距離無線通信部１０１及び携帯端末４００の近距離無線通信部が備えるＢｌｕｅｔｏｏｔｈ（登録商標）プロトコルスタックの階層図
【図１２】本発明の実施の形態２に係るアプリ種別管理テーブルの一例を示す図
【図１３】本発明の実施の形態２に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図１４】本発明の実施の形態２に係る優先度管理テーブルの一例を示す図
【図１５】本発明の実施の形態２に係るアプリ状態管理テーブルの一例を示す図
【図１６】本発明の実施の形態２に係る車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図
【図１７】本発明の実施の形態２（変形例１）に係るアプリ種別管理テーブルの一例を示す図
【図１８】本発明の実施の形態２（変形例１）に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図１９】本発明の実施の形態２（変形例１）に係るアプリ状態管理テーブルの一例を示す図
【図２０】本発明の実施の形態２（変形例１）に係る車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図
【図２１】本発明の実施の形態２（変形例２）に係るアプリ種別管理テーブルの一例を示す図
【図２２】本発明の実施の形態２（変形例２）に係るアプリの共存の可能／不能の組み合わせテーブルの一例を示す図
【図２３】本発明の実施の形態２（変形例２）に係るアプリ状態管理テーブルの一例を示す図
【図２４】本発明の実施の形態２（変形例２）に係る車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図
【図２５】リンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルを示す図
【図２６】リンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルを示す図
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態１に係る無線通信装置について図面を参照しながら説明する。なお、各図面において、本発明に関係のない構成要素は省略している。
（実施の形態１）
図１は、本発明の実施の形態１に係る無線通信装置１００の全体構成を示すブロック図である。
【００１６】
図１において、無線通信装置１００は、近距離無線通信部１０１、制御部１０２、音声入力部１０３、音声出力部１０４、映像入力部１０５、映像出力部１０６、データ入力部１０７、データ出力部１０８、記憶部１０９を備える。
【００１７】
対向無線通信装置２００は、無線通信装置１００と近距離無線通信を確立して、複数のアプリケーション（以下、アプリケーションを単にアプリと称する）機能に係わる情報の通信を行う。
【００１８】
次いで、無線通信装置１００の構成要素について説明する。
【００１９】
近距離無線通信部１０１は、無線通信をするためのアンテナ、無線回路、プロトコルスタック等を有し、対向無線通信装置２００と近距離無線通信によるデータ通信を行う。このデータ通信で使用する無線規格として、Ｂｌｕｅｔｏｏｔｈ（登録商標）を用いる。
【００２０】
制御部１０２は、無線通信装置１００の通信動作やデータ管理動作などの本実施形態に係わる動作全般を制御する、ＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro Processing Unit）とＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びI／Oバス等である。
【００２１】
ＣＰＵ又はＭＰＵは、ＲＯＭに格納されるプログラムを実行することによって、各機能ブロックが相互連携し、本実施の形態に関わる処理が実現される。また、ＣＰＵ又はＭＰＵは、プログラムの実行中、ＲＡＭを作業領域として使用する。また、制御部１０２では対向無線通信装置２００と接続し複数のアプリを実行することができる。
【００２２】
音声入力部１０３は、マイクロホン（非図示）から入力した入力音声を処理する回路等を含んでいる。この場合、アプリによっては、入力した音声を近距離無線通信部１０１から送信して対向無線通信装置２００へ送信することができる。
【００２３】
音声出力部１０４は、スピーカ（非図示）へ音声を出力するために出力音声を処理するアンプ、回路等を含んでいる。この場合、アプリによっては、対向無線通信装置２００側から近距離無線通信部１０１を介して出力音声を受信することができる。
【００２４】
映像入力部１０５は、例えば、カメラなどの撮像デバイス、外部からの映像入力端子であり、画像や映像、あるいは撮像などの像を入力するための回路等を含んでいる。
【００２５】
映像出力部１０６は、例えば、液晶ディスプレイ、有機ＥＬディスプレイなどの表示デバイスであり、画像や映像、あるいは撮像などの像を表示デバイスへ描画するための回路等を含んでいる。
【００２６】
データ入力部１０７は、ユーザからの操作指示を入力するもので、押圧式のキーを所定数並べた構成を採るものや、タッチパネル式のもので構成される。ユーザによる操作を検出し、その操作内容を表わす操作信号を制御部１０２に出力する。
【００２７】
データ出力部１０８は、制御部１０２で処理された各種データを出力するための手段である。各種データを映像として出力する場合、データ出力部１０８は映像出力部１０６と等価となる。一方、映像として出力せず単なるデータとして記憶したい場合は、記憶部１０９へ出力する。
【００２８】
記憶部１０９は、各種データを記憶可能に構成されるメモリ等である。例えば、後述するアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブル、優先度管理テーブル、アプリ状態管理テーブル、複数のアプリが処理するデータ等を記憶する。
【００２９】
なお、符号１０２〜１０８を付した構成要素は必ずしも全て備えなければならないとは限らない。一部の構成要素のみを備える構成としても良い。映像出力部とデータ入力部は分けた構成要素として説明したが、タッチパネルディスプレイのように両方の機能を持つ１つのデバイスとすることもできる。
【００３０】
図２は、無線通信装置１００と対向無線通信装置２００の通信レイヤ構造をそれぞれモデル化した階層図である。
【００３１】
第１の通信レイヤ構造１０は無線通信装置１００上の構造（無線通信装置１００の近距離通信部１０１が備える通信レイヤを示す階層図）を、第２の通信レイヤ構造２０は対向無線通信装置２００上の構造（無線通信装置２００の近距離通信部が備える通信レイヤを示す階層図）をそれぞれ表わしている。
【００３２】
ＲＦ（Radio Frequency）は、実際に無線通信を行うレイヤであり、２．４ＧＨｚ帯で通信を行うための変調モードの定義、トランスミッタの特性（最大送信電力など）、レシーバーの特性（感度など）などを定義する。
【００３３】
Ｂａｓｅ ｂａｎｄは、無線通信を実現するためにさまざまな処理（リンク制御、パケット管理、誤り訂正、チャネル制御など）が行われるレイヤである。ＲＦからの信号をデジタル化して上位レイヤに引き渡す役目を持つ。両デバイス間のメディア アクセスと物理レイヤの手順を規定する。
【００３４】
通信ミドルウェアは、上位プロトコルの多重化、パケットのセグメント化と再構築、およびサービス品質情報の送信などをサポートするレイヤである。
【００３５】
アプリＡ、アプリＢ、アプリＣは、通信ミドルウェアの上で動作する複数のアプリを示しており、近距離無線通信路を介して同じアプリ同士が連携して動作する。
【００３６】
例えば、第１の通信レイヤ構造１０のアプリＡと第２の通信レイヤ構造２０のアプリＡがそれぞれの役割を持ち、各種通信データのやり取りを行い動作する。
【００３７】
ここで、役割とは、例えばデータ送信側やデータ受信側といった各種アプリを実行するにあたっての役割であり、アプリ毎にそれぞれ定義される。
【００３８】
なお、図２では一例として３つのアプリを示しているが、これに限定するものではない。
【００３９】
ＲＦ、Ｂａｓｅ ｂａｎｄは近距離無線通信部１０１として動作し、通信ミドルウェア、アプリＡ、アプリＢ、アプリＣは、制御部１０２で動作するプログラムとして実現される。なお、通信ミドルウェアは近距離無線通信部１０１上で動作するようにしてもよい。
【００４０】
次に、無線通信装置１００の起動時の初期化処理について図３を用いて説明する。図３は、無線通信装置起動時の初期化処理を示す動作フロー図である。
【００４１】
まずＳ１０１において、アプリ種別管理テーブルを作成する。次に、アプリ種別管理テーブルを参照しアプリの共存の可能／不能組み合わせテーブルを作成する（Ｓ１０２）。そして、アプリの共存の可能／不能組み合わせテーブルを参照し優先度管理テーブルを設定する（Ｓ１０３）。
【００４２】
次いで、図３の動作フロー図で作成する各種テーブルについて、図４〜図６を用いて説明する。
【００４３】
図４は、アプリ種別管理テーブルの一例を示す図である。アプリ種別管理テーブルは各アプリ毎にどのような入出力を伴うかをテーブル化したものである。横軸は各アプリであり、縦軸はアプリ種別として、音声出力、音声入力、映像入力、映像出力、データ入力、データ出力、・・・となる。
【００４４】
アプリ種別管理テーブルの入出力はこれに限らず、その他任意のものを追加することができる。
【００４５】
アプリ種別の音声出力とは、図１の無線通信装置１００の音声出力部１０４を使用して音声出力を伴うアプリであるかどうかを表わす。同様に、音声入力とは、音声入力部１０３を使用して音声入力を伴うアプリであるかどうかを表わす。映像入力は、映像入力部１０５を使用して映像入力を伴うアプリであるかどうかを表わす。映像出力は、映像出力部１０６を使用して映像出力を伴うアプリであるかどうかを表わす。データ入力は、データ入力部１０７を使用してデータ入力を伴うアプリであるかどうかを表わす。データ出力は、データ出力部１０８を使用してデータ出力を伴うアプリであるかどうかを表わす。
【００４６】
すなわち、アプリ種別と図１の無線通信装置１００の構成要素１０２〜１０８がそれぞれ対応していることとなる。
【００４７】
図４のテーブル内の「○」は入出力を伴うことを表わし、「×」は伴わないことを表わ
す。
【００４８】
ここで、アプリＡは音声入力と音声出力が○となっており、その他は×となっている。これは、アプリＡは音声入力と音声出力が伴うアプリ（例えば、電話機能を実現するアプリ）であることを表わしている。
【００４９】
また、アプリＢは音声出力が伴うアプリ（例えば、音楽再生を実現するアプリ）であることを表わしている。
【００５０】
また、アプリＣは映像出力、データ入力、データ出力が伴うアプリ（例えば、メール機能を実現するアプリ）であることを表わしている。映像出力、データ出力共に○が付いているが、これはデータをすぐに映像として出力することがあるし、データをメモリに格納し後で利用することもあることを示している。アプリ種別管理テーブルはアプリが決まれば一意に定めることができる。
【００５１】
図５は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。アプリの共存の可能／不能の組み合わせテーブルは、各アプリが持つ性質（アプリ種別管理テーブルで定義）によって、同時動作（共存）が可能なもの、不能なものの組み合わせを示すテーブルである。
【００５２】
図５のテーブル内の「○」は共存可能、「×」は共存不能を表わしている。
【００５３】
ここで、アプリＡはアプリＢとは共存不能でアプリＣとは共存可能となる。アプリＢはアプリＡと共存不能でアプリＣとは共存可能となる。アプリＣは、アプリＡと共存可能でアプリＢと共存可能である。
【００５４】
アプリＡとアプリＢの共存不能の理由について説明する。アプリＡ、アプリＢは両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【００５５】
アプリＡとアプリＣが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。
【００５６】
図６は、優先度管理テーブルの一例を示す図である。優先度管理テーブルは、互いに共存が不能なアプリの場合に、どのアプリを優先して動作させるかを定義したものである。例えば、無線通信装置１００を車載で使用する場合、ユーザが運転中にも各種アプリを使用するため、音声ベースのアプリ、リアルタイム性の高いアプリが優先される。
【００５７】
なお、無線通信装置１００が存在する位置に応じて、アプリ優先順位の決め方を動的に変更することもできる。
【００５８】
現在動作中のアプリに対して優先度の高いアプリから割り込みが入ると、現在動作中のアプリは一時中断し、割り込みのあった優先度の高いアプリの動作を開始する。一方、現在アプリより優先度の低いアプリからの割り込みは許可しない。
【００５９】
図６では、お互いに共存不能なアプリＡ、アプリＢに関して、アプリＡの方が優先度が高いことを示している。
【００６０】
また、共存可能なアプリ同士の場合（例えば、アプリＡとアプリＣ）には優先度管理テーブルは作成しない。
【００６１】
なお、無線通信装置１００の初期化処理として図３の動作フロー図を説明したが、これに限らず、事前にアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブル、優先度管理テーブルを作成しておき、不揮発性メモリ等に格納しておき起動時に読み出すようにしても良い。
【００６２】
次に、アプリ起動に伴う状態管理処理の動作について、図７〜図８を用いて説明する。
【００６３】
図７はアプリ状態管理テーブル（詳しくは図８で説明）の更新動作を示す動作フロー図である。
【００６４】
図７において、ステップＳ２０１にてアプリ起動要求が発生したかどうかを判定する。
【００６５】
アプリ起動要求が発生していない場合（Ｓ２０１：Ｎｏ）、ステップＳ２０１の前に処理を戻す。
【００６６】
アプリ起動要求が発生した場合（Ｓ２０１：Ｙｅｓ）、ステップＳ２０２にて既に起動中のアプリがなしかどうかを判定する。
【００６７】
既に起動中のアプリがない場合（Ｓ２０２：Ｙｅｓ）、ステップ２０３にて起動要求のあったアプリを起動する。
【００６８】
ステップＳ２０２にて、既に起動中のアプリがある場合（Ｓ２０２：Ｎｏ）、ステップＳ２０５へ処理を移す。
【００６９】
ステップＳ２０５では、既に起動中のアプリと共存できるアプリであるかを判定する。
【００７０】
ステップＳ２０５の判定は、アプリの共存の可能／不能の組み合わせテーブルを参照する。
【００７１】
既に起動中のアプリと共存できるアプリの場合（Ｓ２０５：Ｙｅｓ）、ステップＳ２０６にて起動要求のあったアプリを起動する。
【００７２】
一方、既に起動中のアプリと共存できるアプリでない場合（Ｓ２０５：Ｎｏ）、ステップＳ２０７へ処理を移す。
【００７３】
ステップＳ２０７では、起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリであるかを判定する。
【００７４】
ここでステップＳ２０７の判定は、優先度管理テーブルを参照する。
【００７５】
起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリである場合（Ｓ２０７：Ｙｅｓ）、ステップＳ２０８にて現在起動中のアプリを待機状態へ遷移させ、起動要求のあったアプリを起動する。
【００７６】
一方、起動要求が発生したアプリが既に起動中のアプリと比べて優先度が高いアプリでない場合（Ｓ２０７：Ｎｏ）、ステップＳ２０９へ処理を移す。ステップＳ２０９では、起動要求を受け付けず、終了する。ステップＳ２０４では、アプリ状態管理テーブルを更新する。
【００７７】
図８は、アプリ状態管理テーブルの一例を示す図である。アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【００７８】
また図８は、アプリＢが起動中、アプリＣが共存中の場合に、アプリＡの起動要求が発生し、アプリ状態管理テーブルが更新された場合を示している。このとき、図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【００７９】
なお、図８のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【００８０】
次いで、本発明の実施の形態１に係る無線通信装置のリンクロス（電波環境変化等に伴う通信途絶）発生時の動作について図９を用いて説明する。
【００８１】
図９は、本発明の実施の形態１に係る無線通信装置のリンクロス発生時の動作を示す動作フロー図である。
【００８２】
図９において、ステップＳ３０１ではリンクロスが発生したかどうかを判定する。リンクロスは、近距離無線通信部１０１にて検知する。
【００８３】
リンクロスが発生していない場合（Ｓ３０１：Ｎｏ）、Ｓ３０１の前に処理を戻す。リンクロスが発生した場合（Ｓ３０１：Ｙｅｓ）、ステップＳ３０２へ処理を移す。リンクロスが発生した場合にユーザへその旨を通知することもできる。
【００８４】
ステップＳ３０２では、対向無線通信装置２００とのリンクロス復旧処理を試み、復旧できたかどうかを判定する。
【００８５】
リンクロスから復旧できなかった場合（Ｓ３０２：Ｎｏ）、ステップＳ３０３へ処理を移す。
【００８６】
ステップＳ３０３では、所定時間経過したかどうかを判定する。所定時間経過していない場合（Ｓ３０３：Ｎｏ）は、ステップＳ３０２の前に処理を戻す。
【００８７】
一方、所定時間経過した場合（Ｓ３０３：Ｙｅｓ）は、ステップＳ３０６へ処理を移す。
【００８８】
ステップＳ３０６では、アプリ状態管理テーブルをクリア（記憶した各アプリの状態を消去）する。
【００８９】
一方、リンクロスから復旧できた場合（Ｓ３０２：Ｙｅｓ）、ステップＳ３０４へ処理を移す。ステップＳ３０４では、リンクロス前のアプリ状態管理テーブルを読みだす。
【００９０】
次いで、読み出したアプリ状態管理テーブルに従い各アプリをリンクロス前の状態へ復旧させる（Ｓ３０５）。このとき、リンクロス前に起動中であったアプリ（図８の例でいくとアプリＡ）を優先して復旧させる。
【００９１】
ステップＳ３０２→Ｓ３０３→Ｓ３０６のようなパスがあるのは、対向無線通信装置がバッテリーで駆動しているような場合にバッテリー切れ等によりリンクロス復旧ができな
いような場合が存在するためである。
【００９２】
以上、説明した無線通信装置によれば、複数機能の同時動作（マルチプロファイル）の作動状況で、リンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従いリンクロス前に起動中であったアプリだけでなく、待機状態のアプリ、共存状態のアプリも適切に復旧するので、ユーザ利便性を高める無線通信装置を提供することができる。
【００９３】
上記実施の形態で説明した構成は、単に具体例を示すものであり、本願発明の技術的範囲を制限するものではない。本願の効果を奏する範囲において、任意の構成を採用することが可能である。
【００９４】
また、近距離無線通信規格としてＢｌｕｅｔｏｏｔｈ（登録商標）を例に説明したが、無線ＬＡＮ等でも有用である。
（実施の形態２）
以下、本発明の実施の形態２に係る車載装置について図面を参照しながら説明する。なお、各図面において、本発明に関係のない構成要素は省略している。
【００９５】
図１０は、本発明の実施の形態２に係る車載装置３００の全体構成を示すブロック図である。
【００９６】
図１０において、車載装置３００は実施の形態１の無線通信装置１００と同様の構成要素を有しており、省略している。また各構成要素の説明を省略する。
【００９７】
さらに、車載装置３００は図示しない道路や交差点に関するデータ等の地図情報を格納したデータベース、ＧＰＳ（Global Positioning System）などの測位手段、公知の経路探索、誘導案内を行うプログラム等を含んでおり、映像出力部１０６に地図を表示するとともに自車位置の表示更新、地図上への経路の重畳表示、案内対象交差点手前では音声による誘導案内等を行うことができる。
【００９８】
携帯端末４００は、車載装置３００が搭載される車両を利用する運転者が所持している例えば携帯電話であり、車両内に持込まれる。また車載装置３００と近距離無線通信路を確立して、複数のアプリケーション（以下、アプリケーションを単にアプリと称する）機能に係わる通信を行う。近距離無線通信路は、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格に準拠する通信路である。
【００９９】
車載装置３００は携帯端末４００と近距離無線通信を行うことで、公衆網１の先につながるユーザと通話するためのハンズフリー通話機能、携帯端末４００の電話帳データを車載装置３００へ転送する電話帳転送機能、携帯端末４００に蓄積されたオーディオを車載装置３００でストリーミング再生するストリーミング再生機能、携帯端末４００のゲートウェイ機能を使用し外部のネットワーク（公衆網１）とＷＥＢブラウズ等のデータ通信を行うデータ通信（ダイヤルアップ通信）機能、携帯端末４００のゲートウェイ機能を使用し外部のネットワークとメッセージ通信を行うメッセージ通信機能などを備える。
【０１００】
これらの機能を実行するにあたり、Ｂｌｕｅｔｏｏｔｈ（登録商標）プロファイルを用い（詳細は後述する）、車載装置３００と携帯端末４００は複数のプロファイルが同時接続可能に構成されている。
【０１０１】
図１１は、車載装置３００の通信レイヤ構造をそれぞれモデル化した階層図である。第３の通信レイヤ構造３０（車載装置３００の近距離無線通信部１０１が備えるＢｌｕｅｔｏｏｔｈ（登録商標）プロトコルスタックの階層図）と同様の構成を持つ通信レイヤが携
帯端末４００にも存在するが図１１では省略している。
【０１０２】
図１１において、ＲＦ（Radio Frequency）は、実際に無線通信を行うレイヤであり、２．４ＧＨｚ帯で通信を行うための変調モードの定義、トランスミッタの特性（最大送信電力など）、レシーバーの特性（感度など）などを定義する。
【０１０３】
Ｂａｓｅ ｂａｎｄは、無線通信を実現するためにさまざまな処理（リンク制御、パケット管理、誤り訂正、チャネル制御など）が行われるレイヤである。ＲＦからの信号をデジタル化して上位レイヤに引き渡す役目を持つ。Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイス間のメディア アクセスと物理レイヤの手順を規定する。
【０１０４】
ＬＭＰ（Link Manager Protocol）は、２台のデバイス間における Ｂｌｕｅｔｏｏｔｈ（登録商標）接続のすべての側面（接続、認証、暗号化、省電力制御など）を制御し、ネゴシエートするために使用する。
【０１０５】
ＨＣＩ（Host Controller Interface）は、ベースバンドコントローラとリンクマネージャにコマンドインタフェースを提供し、構成パラメータにアクセスするためのインタフェースを提供する。
【０１０６】
Ｌ２ＣＡＰ（Logical Link Control and Adaptation Protocol）は、上位プロトコルの多重化、パケットのセグメント化と再構築、およびサービス品質情報の送信をサポートする。
【０１０７】
ＲＦＣＯＭＭは、シリアルケーブルの設定と、ＲＳ−２３２Ｃシリアルポートをエミュレートするために使用する。
【０１０８】
ＯＢＥＸ（Object Exchange）は、２台のデバイスがオブジェクトの交換に使用できる通信プロトコルであり、多様なデータやコマンドを交換できるように定義されている。
【０１０９】
ＡＶＤＴＰ（Audio/Video Distribution Transport Protocol）は、Ａ/Ｖ ストリームのネゴシエーション手順、確認手順、および伝送手順が定義されている。
【０１１０】
ＡＶＣＴＰ（Audio/Video Control Transport Protocol）は、Ａ/Ｖデバイスの制御メッセージを交換するトランスポート メカニズムが定義されている。
【０１１１】
ＧＡＶＤＰ（General Audio/Video Distribution Profile）は、Ａ２ＤＰの基礎として機能し、ビデオ ストリームとオーディオ ストリームを配信するために使用する。
【０１１２】
Ａ２ＤＰ（Advanced Audio Distribution Profile）は、ステレオ品質のオーディオをメディア ソースからメディア シンクにストリーミングするために使用する。車載装置３００はシンクとして振る舞う。携帯端末４００はソースとして振る舞う。
【０１１３】
ＡＶＲＣＰ（Audio/Video Remote Control Profile）は、オーディオストリーミングのリモコン制御を行うために使用する。車載装置３００はコントローラとして振る舞う。携帯端末４００はターゲットとして振る舞う。
【０１１４】
ＯＰＰ（Object Push Profile）は、オブジェクト伝送のためのプロファイルであり、電話帳データの転送のために使用する。車載装置３００はサーバーとして振る舞う。携帯端末４００はクライアントとして振る舞う。
【０１１５】
ＰＢＡＰ（Phone Book Access Profile）は、電話帳データ、発着信履歴データの転送のために使用する。車載装置３００はクライアントとして振る舞う。携帯端末４００はサーバーとして振る舞う。
【０１１６】
なお、電話帳転送には、ＯＰＰ又はＰＢＡＰいずれか任意のプロファイルを用いることができる。
【０１１７】
ＭＡＰ（Message Access Profile）は、メッセージ情報の交換のために使用する。車載装置３００はクライアントとして振る舞う。携帯端末４００はサーバーとして振る舞う。
【０１１８】
ＨＦＰ（Hands Free Profile）は、ハンズフリー通話機能を実現するために使用する。車載装置３００はハンズフリーとして振る舞う。携帯端末４００はオーディオゲートウェイとして振る舞う。
【０１１９】
ＤＵＮ（Dial-Up Networking Profile）は、インターネットや他のダイヤルアップ サービスにアクセスするために使用する。車載装置３００はデータターミナルとして振る舞う。携帯端末４００はゲートウェイとして振る舞う。
【０１２０】
ＳＤＰ（Service Discovery Protocol）は、車載装置３００と携帯端末４００が互いにどのようなサービスをサポートしているのか検索するために使用する。
【０１２１】
ＧＡＰ（Generic Access Profile）は、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応デバイス間のベースバンドリンクを確立するための手法が定義されている。
【０１２２】
ＡＶＰアプリは、携帯端末４００に蓄積されたオーディオを車載装置３００でストリーミング再生するストリーミング再生機能を実現するアプリである。
【０１２３】
ＰＢＡＰアプリは、車載装置３００から携帯端末４００の電話帳データを取得する電話帳転送機能を実現するアプリである。
【０１２４】
ＯＰＰアプリは、携帯端末４００から車載装置３００へ電話帳データを送信する電話帳転送機能を実現するアプリである。
【０１２５】
ＭＡＰアプリは、携帯端末４００のゲートウェイ機能を使用し外部のネットワークとメッセージ通信を行うメッセージ通信機能を実現するアプリである。
【０１２６】
ＨＦＰアプリは、公衆網１の先につながるユーザと通話するためのハンズフリー通話機能を実現するためのアプリである。
【０１２７】
ＤＵＮアプリは、携帯端末４００のゲートウェイ機能を使用し外部のネットワークとＷＥＢブラウズ等のデータ通信を行うデータ通信（ダイアルアップ通信）機能を実現するアプリである。
【０１２８】
管理アプリは、携帯端末４００とペアリングしてデバイス登録をしたり、車載装置３００周辺に存在するＢｌｕｅｔｏｏｔｈ（登録商標）相手機器を探索して、相手機器の持つサービス情報を取得したりするアプリである。
【０１２９】
管理アプリは全てのアプリの基本となるアプリであり、常時起動されている。
【０１３０】
上記説明したアプリは、近距離無線通信路を介して携帯端末４００の同じアプリ同士が
連携して動作する。
【０１３１】
例えば、第３の通信レイヤ構造３０のＨＦＰアプリと携帯端末４００のＨＦＰアプリがそれぞれの役割を持ち、各種通信データのやり取りを行い動作する。
【０１３２】
なお、この図では一例として７つのアプリを示しているが、これに限定するものではない。他に規定されるＢｌｕｅｔｏｏｔｈ（登録商標）プロファイルに従い、別のアプリを追加することもできる。
【０１３３】
ＲＦ、Ｂａｓｅ ｂａｎｄ、ＬＭＰ、ＨＣＩは近距離無線通信部１０１として動作し、Ｌ２ＣＡＰ以上は、制御部１０２で動作するプログラムとして実現される。なお、Ｌ２ＣＡＰ〜各プロファイル階層までを近距離無線通信部１０１上で動作するようにしてもよい。
【０１３４】
次に、車載装置３００の起動時の初期化処理については図３で説明した実施の形態１と同様のためその説明を省略する。
【０１３５】
ここで、ＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブル、優先度管理テーブルの一例について図１２〜図１４を用いて説明する。
【０１３６】
図１２は、ＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。アプリ種別管理テーブルは各アプリ毎にどのような入出力を伴うかをテーブル化したものである。横軸は各アプリであり、縦軸はアプリ種別として、音声出力、音声入力、映像入力、映像出力、データ入力、データ出力、・・・となる。
【０１３７】
図１２のテーブル内の「○」は入出力を伴う。「×」は伴わないことを表わしている。
【０１３８】
ここで、ＨＦＰアプリは音声入力と音声出力が○となっており、その他は×となっている。これは、ＨＦＰアプリは電話機能を実現するアプリであり、音声入力と音声出力が伴うアプリであることを表わしている。
【０１３９】
また、ＡＶＰアプリは音声出力のみが○となっている。これは、ＡＶＰアプリはオーディオのストリーミング再生機能を実現する音声出力が伴うアプリであることを表わしている。
【０１４０】
また、ＤＵＮアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはデータをすぐに映像として出力（ブラウザ等への表示）することがあるし、データをメモリに格納し後で利用することもあることを示している。なお、ＤＵＮアプリはＰＡＮアプリと代替可能である。
【０１４１】
ここではＤＵＮアプリはインターネットへ接続しブラウザ表示するものとして説明する。アプリ種別管理テーブルはアプリが決まれば一意に定めることができる。
【０１４２】
図１３は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。
【０１４３】
アプリの共存の可能／不能の組み合わせテーブルは、各アプリが持つ性質（アプリ種別管理テーブルで定義）によって、同時動作（共存）が可能なもの、不能なものの組み合わせを示すテーブルである。
【０１４４】
図１３テーブル内の「○」は共存可能、「×」は共存不能を表わしている。
【０１４５】
ここで、ＨＦＰアプリはＡＶＰアプリとは共存不能でＤＵＮアプリとは共存可能となる。ＡＶＰアプリはＨＦＰアプリと共存不能でＤＵＮアプリとは共存可能となる。ＤＵＮアプリは、ＨＦＰアプリと共存可能でＡＶＰアプリと共存可能である。
【０１４６】
ＨＦＰアプリとＡＶＰアプリの共存不能の理由について説明する。これはＨＦＰアプリ、ＡＶＰアプリ両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【０１４７】
ＨＦＰアプリとＤＵＮアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。
【０１４８】
図１４は、優先度管理テーブルの一例を示す図である。優先度管理テーブルは、互いに共存が不能なアプリの場合はどのアプリを優先して動作させるかを定義したものである。
【０１４９】
現在動作中のアプリに対して優先度の高いアプリから割り込みが入ると、現在動作中のアプリは一時中断し、割り込みのあった優先度の高いアプリの動作を開始する。一方、現在アプリより優先度の低いアプリからの割り込みは許可しない。
【０１５０】
図１４では、お互いに共存不能なＨＦＰアプリ、ＡＶＰアプリに関して、ＨＦＰアプリの方が優先度が高いことを示している。ＨＦＰアプリが優先されるのはＡＶＰアプリに比べて、ハンズフリー通話という双方向の音声通信が伴うリアルタイム性の高いアプリであるためである。
【０１５１】
また、共存可能なアプリ同士の場合（例えば、ＨＦＰアプリとＤＵＮアプリの組み合わせ）には優先度管理テーブルは作成しない。
【０１５２】
次いで、アプリの起動に伴う状態管理処理の動作については、図７と同様のためその説明を省略する。
【０１５３】
図１５は、図７の動作フロー図のステップＳ２０４にて更新されるアプリ状態管理テーブルの一例を示す図である。
【０１５４】
アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【０１５５】
また図１５は、ＡＶＰアプリが起動中（オーディオストリーミング再生中）、ＤＵＮアプリが共存中（データ通信中）の場合に、ＨＦＰアプリの起動要求（例えばハンズフリー着信）が発生し、アプリ状態管理テーブルが更新された場合を示している。
【０１５６】
このとき、ＨＦＰアプリにて着信を受け付けると通話中の状態となり、ＡＶＰアプリは一時停止中状態となり、ＤＵＮアプリはデータ通信中の状態となる。図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【０１５７】
ここで、管理アプリは全てのアプリの基本となるアプリであり起動されている。管理アプリは図１５のアプリ状態管理テーブルの対象から外している。
【０１５８】
なお、図１５のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【０１５９】
次いで、本発明の実施の形態２に係る無線通信装置のリンクロス発生時の動作については図９と同様のためその説明を省略する。
【０１６０】
ここで、図９の動作フロー図ステップＳ３０５における各アプリを復旧させる動作について、図１６を用いてより詳細に説明する。
【０１６１】
図１６は、車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。リンクロス前のアプリ状態管理テーブルを図１５に示す状態であるものとする。
【０１６２】
図１６において、ステップＳ４０１にて、ハンズフリー（ＨＦＰアプリ）をサービスレベル（ＳＬＣ）接続状態に復旧させる。
【０１６３】
次いで、携帯端末側で通話状態が継続されているかを判定する（ステップＳ４０２）。なお、通話状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１６４】
携帯端末側で通話状態が継続されていない場合（Ｓ４０２：Ｎｏ）、ステップＳ４０４へ処理を移す。
【０１６５】
携帯端末側で通話状態が継続されている場合（Ｓ４０２：Ｙｅｓ）、ハンズフリーを通話状態へ復旧させる。
【０１６６】
ステップＳ４０４では、オーディオストリーミング（ＡＶＰアプリ）をサービス接続状態へ復旧させる。
【０１６７】
次いで、携帯端末側でオーディオストリーミングの一時停止状態が継続されているかを判定する（ステップＳ４０５）。なお、一時停止状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１６８】
携帯端末側でオーディオストリーミングの一時停止状態が継続されていない場合（Ｓ４０５：Ｎｏ）、ステップＳ４０７へ処理を移す。
【０１６９】
携帯端末側でオーディオストリーミングの一時停止状態が継続されている場合（Ｓ４０５：Ｙｅｓ）、オーディオストリーミング（ＡＶＰアプリ）を一時停止状態へ復旧させる。
【０１７０】
ステップＳ４０７では、データ通信（ＤＵＮアプリ）をサービス接続状態へ復旧させる。
【０１７１】
次いで、携帯端末側でデータ通信の共存状態が継続されているかを判定する（ステップＳ４０８）。なお、共存状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１７２】
携帯端末側でデータ通信の共存状態が継続されていない場合（Ｓ４０８：Ｎｏ）、処理を終了する。
【０１７３】
携帯端末側でデータ通信の共存状態が継続されている場合（Ｓ４０８：Ｙｅｓ）、データ通信（ＤＵＮアプリ）を共存状態へ復旧させる（ＷＥＢブラウズ中の継続データが受信され、ＷＥＢページが表示される）。
【０１７４】
これにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＤＵＮアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。
【０１７５】
また、図１６の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にデータ通信状態を維持する。
【０１７６】
また、ＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリの３つのプロファイルがマルチプロファイルで動作する場合について説明したが、マルチプロファイル動作（ＨＦＰアプリ／ＡＶＰアプリ）においても同様に実施できる。このとき上記説明した図１５に示すアプリ状態管理テーブルの共存アプリ１に該当するアプリが何もない状態となる。そして、図１６のＳ４０７〜Ｓ４０９の処理が省かれることになる。
（変形例１）
本発明の実施の形態２の変形例１について、図１７〜図２０を用いて説明する。
【０１７７】
まず、ＨＦＰアプリ、ＡＶＰアプリ、ＰＢＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブルの一例について図１７〜図１８を用いて説明する。
【０１７８】
優先度管理テーブルは図１４と同様のため説明を省略する。
【０１７９】
図１７は、ＨＦＰアプリ、ＡＶＰアプリ、ＰＢＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。
【０１８０】
ＰＢＡＰアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これは電話帳データをすぐに映像として出力（例えば、電話帳のリスト表示）することがあるし、電話帳データをメモリに格納し後で利用することもあることを示している。
【０１８１】
図１８は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。
【０１８２】
ここで、ＨＦＰアプリはＡＶＰアプリとは共存不能でＰＢＡＰアプリとは共存可能となる。ＡＶＰアプリはＨＦＰアプリと共存不能でＰＢＡＰアプリとは共存可能となる。ＰＢＡＰアプリは、ＨＦＰアプリと共存可能でＡＶＰアプリと共存可能である。
【０１８３】
ＨＦＰアプリとＡＶＰアプリの共存不能の理由について、これはＨＦＰアプリ、ＡＶＰアプリ両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【０１８４】
ＨＦＰアプリとＰＢＡＰアプリが共存可能であるのは、アプリ種別管理テーブルからも
分かる通り、アプリが持つ性質の重複が無いためである。
【０１８５】
次いで、アプリの起動に伴う状態管理処理の動作について、図７と同様のためその説明を省略する。
【０１８６】
図１９は、図７の動作フロー図のステップＳ２０４にて更新されるアプリ状態管理テーブルの一例を示す図である。
【０１８７】
アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【０１８８】
また図１９は、ＡＶＰアプリが起動中（オーディオストリーミング再生中）、ＰＢＡＰアプリが共存中（電話帳転送中）の場合に、ＨＦＰアプリの起動要求（例えばハンズフリー着信）が発生し、アプリ状態管理テーブルが更新された場合を示している。
【０１８９】
このとき、ＨＦＰアプリにて着信を受け付けると通話中の状態となり、ＡＶＰアプリは一時停止中状態となり、ＰＢＡＰアプリは電話帳転送中の状態となる。図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【０１９０】
なお、図１９のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【０１９１】
次いで、本発明の実施の形態２（変形例１）に係る車載装置のリンクロス発生時の動作については実施の形態１で説明した図９と同様のためその説明を省略する。
【０１９２】
ここで、図９の動作フロー図ステップＳ３０５における各アプリを復旧させる動作について、図２０を用いてより詳細に説明する。
【０１９３】
図２０は、車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。
【０１９４】
リンクロス前のアプリ状態管理テーブルを図１９に示す状態であるものとする。
【０１９５】
図２０において、ステップＳ４０１〜ステップＳ４０６までの動作については、図１６と同様のためその説明を省略する。
【０１９６】
ステップＳ５０１では、電話帳転送（ＰＢＡＰアプリ）をサービス接続状態へ復旧させる。
【０１９７】
次いで、携帯端末側で電話帳転送の共存状態が継続されているかを判定する（ステップＳ５０２）。なお、共存状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０１９８】
携帯端末側で電話帳転送の共存状態が継続されていない場合（Ｓ５０２：Ｎｏ）、処理を終了する。この場合は、電話帳データを再度はじめから転送する必要がある。
【０１９９】
携帯端末側で電話帳転送の共存状態が継続されている場合（Ｓ５０２：Ｙｅｓ）、電話
帳転送（ＰＢＡＰアプリ）を共存状態へ復旧させ、電話帳データの続きから転送する。
【０２００】
これにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＰＢＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。
【０２０１】
また、図２０の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共に電話帳転送状態を維持する。
（変形例２）
本発明の実施の形態２の変形例２について、図２１〜図２４を用いて説明する。
【０２０２】
まず、ＨＦＰアプリ、ＡＶＰアプリ、ＭＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブル、アプリの共存の可能／不能の組み合わせテーブルの一例について図２１〜図２２を用いて説明する。
【０２０３】
優先度管理テーブルは図１４と同様のため説明を省略する。
【０２０４】
図２１は、ＨＦＰアプリ、ＡＶＰアプリ、ＭＡＰアプリの３つのプロファイルがマルチプロファイルで動作する場合のアプリ種別管理テーブルの一例を示す図である。
【０２０５】
ＭＡＰアプリは映像出力、データ入力、データ出力が伴うアプリであることを表わしている。映像出力、データ出力共に○が付いているが、これはメッセージデータをすぐに映像として出力（例えば、メッセージリスト又はメッセージ本文表示）することがあるし、メッセージデータをメモリに格納し後で利用することもあることを示している。ここでメッセージデータとはＳＭＳ、Ｅ−Ｍａｉｌ等を指す。
【０２０６】
図２２は、アプリの共存の可能／不能の組み合わせテーブルの一例を示す図である。
【０２０７】
ここで、ＨＦＰアプリはＡＶＰアプリとは共存不能でＭＡＰアプリとは共存可能となる。ＡＶＰアプリはＨＦＰアプリと共存不能でＭＡＰアプリアプリとは共存可能となる。ＭＡＰアプリは、ＨＦＰアプリと共存可能でＡＶＰアプリと共存可能である。
【０２０８】
ＨＦＰアプリとＡＶＰアプリの共存不能の理由について説明する。ＨＦＰアプリ、ＡＶＰアプリ両方とも音声出力を伴うアプリであり、同時には１つのアプリの音声しか出力できない前提で共存不能となっている。
【０２０９】
ＨＦＰアプリとＭＡＰアプリが共存可能であるのは、アプリ種別管理テーブルからも分かる通り、アプリが持つ性質の重複が無いためである。
【０２１０】
次いで、アプリの起動に伴う状態管理処理の動作について、図７と同様のためその説明を省略する。
【０２１１】
図２３は、図７の動作フロー図のステップＳ２０４にて更新されるアプリ状態管理テーブルの一例を示す図である。
【０２１２】
アプリ状態管理テーブルは、各アプリの状態を現在起動中のアプリ、一時待機中のアプリ、共存アプリのいずれかで管理する。
【０２１３】
また図２３は、ＡＶＰアプリが起動中（オーディオストリーミング再生中）、ＭＡＰアプリが共存中（メッセージ転送中）の場合に、ＨＦＰアプリの起動要求（例えばハンズフリー着信）が発生し、アプリ状態管理テーブルが更新された場合を示している。
【０２１４】
このとき、ＨＦＰアプリにて着信を受け付けると通話中の状態となり、ＡＶＰアプリは一時停止中状態となり、ＭＡＰアプリはメッセージ転送中の状態となる。図７の動作フローでは、Ｓ２０１→Ｓ２０２→Ｓ２０５→Ｓ２０７→Ｓ２０８→Ｓ２０４のパスで順番に処理が行われることとなる。
【０２１５】
なお、図２３のアプリ状態管理テーブルは一時待機中のアプリは２つまで、共存アプリは２つまで管理できる例を示しているが、これに限らずアプリの数が増えるに従って、一時待機中のアプリと共存アプリの数を増やすことができる。
【０２１６】
次いで、本発明の実施の形態２（変形例２）に係る車載装置のリンクロス発生時の動作については実施の形態１で説明した図９と同様のためその説明を省略する。
【０２１７】
ここで、図９の動作フロー図ステップＳ３０５における各アプリを復旧させる動作について、図２４を用いてより詳細に説明する。
【０２１８】
図２４は、車載装置３００のリンクロス後に各アプリを復旧させる動作を示す動作フロー図である。
【０２１９】
リンクロス前のアプリ状態管理テーブルを図２３に示す状態であるものとする。
【０２２０】
図２４において、ステップＳ４０１〜ステップＳ４０６までの動作については、図１６と同様のためその説明を省略する。
【０２２１】
ステップＳ６０１では、メッセージ転送（ＭＡＰアプリ）をサービス接続状態へ復旧させる。
【０２２２】
次いで、携帯端末側でメッセージ転送の共存状態が継続されているかを判定する（ステップＳ６０２）。なお、共存状態が継続されているかの判定は携帯端末４００から通知されるステータス又は車載装置３００から携帯端末４００への問合せに対する応答コマンドによって判定する。
【０２２３】
携帯端末側でメッセージ転送の共存状態が継続されていない場合（Ｓ６０２：Ｎｏ）、処理を終了する。この場合は、メッセージデータを再度一から転送する必要がある。
【０２２４】
携帯端末側でメッセージ転送の共存状態が継続されている場合（Ｓ５０２：Ｙｅｓ）、メッセージ転送（ＭＡＰアプリ）を共存状態へ復旧させ、メッセージデータの続きから転送する。
【０２２５】
これにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＭＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとっての利便性を高めることができる。
【０２２６】
また、図２４の動作フローによる復旧処理後、ハンズフリー通話が通話状態から終話状態へ遷移した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持する。
【０２２７】
以上、説明した車載装置によれば、複数機能の同時動作（マルチプロファイル）の作動状況で、リンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従いリンクロス前に起動中であったアプリだけでなく、待機状態のアプリ、共存状態のアプリも適切に復旧するので、ユーザ利便性を高める車載装置を提供することができる。
【０２２８】
なお、図１０では車載装置３００と携帯端末４００が１対１で接続されるポイントツーポイントのマルチプロファイルについて説明したが、これに限らず車載装置３００と複数の携帯端末が１対多で接続されるポイントツーマルチポイントのマルチプロファイルにおいても同様に適用できる。
【０２２９】
上記説明では、マルチプロファイル動作の組み合わせとして、ＨＦＰアプリ／ＡＶＰアプリ／ＤＵＮアプリ、ＨＦＰアプリ／ＡＶＰアプリ／ＰＢＡＰアプリ、ＨＦＰアプリ／ＡＶＰアプリ／ＭＡＰアプリを一例として説明したが、これに限らず、図２５、図２６に示すような他の組み合わせでも実施できる。
【０２３０】
図２５はリンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルＮｏ．１である。
【０２３１】
図２６はリンクロス前の各アプリの状態によってリンクロス復旧後の動作を表わすテーブルＮｏ．２（Ｎｏ．１からの継続）である。
【０２３２】
また、３つのプロファイル同士の組み合わせだけでなく、４つのプロファイルの組み合わせ、例えば、同時にＨＦＰアプリ、ＡＶＰアプリ、ＤＵＮアプリ、ＰＢＡＰアプリとを接続し、同時動作する場合のリンクロス時に対しても、同様に適用できる。
【０２３３】
また、図示しない走行状態検知手段（例えば、車速センサ）によって車両の走行状態を判別し、リンクロスからの復旧制御をよりきめ細かく行うこともできる。
【０２３４】
また、リンクロス復旧前の状態に適切に復旧できたか否かを区別して音声等でユーザへ報知するようにしても良い。これにより、ユーザが運転中で車載ディスプレイへ視線を移動することなく、リンクロス前の状態に正常復帰したのか否かを判断することができる。
【０２３５】
また、近距離無線通信規格としてＢｌｕｅｔｏｏｔｈ（登録商標）を例に説明したが、無線ＬＡＮ等でも有用である。
【０２３６】
上記実施の形態で説明した構成は、単に具体例を示すものであり、本願発明の技術的範囲を制限するものではない。本願の効果を奏する範囲において、任意の構成を採用することが可能である。
【０２３７】
以上の説明において、リンクロス検知手段は近距離無線通信部１０１（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール）及び制御部１０２（例えば、ＣＰＵ）で動作するソフトウェアに対応しており、近距離無線通信部１０１としてのＢｌｕｅｔｏｏｔｈ（登録商標）モジュールがリンクロスを検知し制御部１０２としてのＣＰＵ側へ通知される。
【０２３８】
アプリ状態記憶手段は、記憶部１０９（メモリ等）に対応しており、図８に示すアプリ状態管理テーブルを記憶する。
【０２３９】
復旧手段は、近距離無線通信部１０１及び制御部１０２としてのＣＰＵで動作するソフトウェアに対応しており、リンクロスを検知した後、無線通信路を復旧する。
【０２４０】
アプリ復旧手段は、近距離無線通信部１０１及び制御部１０２としてのＣＰＵで動作するソフトウェアに対応しており、リンクロス前の各アプリを復旧させる。
【０２４１】
接続手段は、近距離通信部１０１（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール）及び制御部１０２（例えば、ＣＰＵ）で動作するソフトウェアに対応している。
【０２４２】
制御手段は、近距離無線通信部１０１を制御する制御部１０２（例えば、ＣＰＵ）で動作するソフトウェアに対応している。
【０２４３】
以上のとおり、本発明の無線通信装置は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、無線通信路のリンクロスを検知するリンクロス検知手段と、リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、リンクロスした無線通信路を復旧する復旧手段と、アプリケーションの復旧を行うアプリ復旧手段とを備え、前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする。
【０２４４】
この構成を有することにより、複数のアプリケーションがリンクロス前に動作していてもアプリ状態記憶手段に記憶されているアプリ記憶状態に従いアプリケーションの復旧を行うことができる。
【０２４５】
さらに、本発明の無線通信装置は、アプリ状態記憶手段が記憶するアプリ状態は、リンクロス直前の現在起動中のアプリか否か、一時待機中であるか否か、現在起動中のアプリと共存動作ができる共存中であるか否かを含むことを特徴とする。
【０２４６】
これにより、各アプリのリンクロス前の状態へ適切に復旧することができ、リンクロス直前に起動中のアプリだけでなく、一時待機中、共存中であったアプリも確実に復旧することができる。また、現在起動中のアプリが終了した際には一時待機中であったアプリが次に起動できるようになり、リンクロスを挟むことにより状態がおかしくなる現象を回避できる。
【０２４７】
さらに、本発明の無線通信装置は、復旧手段によって、リンクロス後無線通信路が所定の時間内で復旧できない場合にはアプリ状態をクリアすることを特徴とする。
【０２４８】
これにより、対向無線通信装置がバッテリーで駆動しているような場合にバッテリー切れ等によりいつまでもリンクロス復旧ができないような場合にはアプリ状態がクリアされるので、無線通信装置がいつまでもアプリ状態を記憶しておかずに済む。またバッテリー切れによるリンクロス後、バッテリーが充電された後に対向無線通信装置と接続確立した際に、無線通信装置がおかしな挙動をすることを回避できる。
【０２４９】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとを同時に接続してオーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオ
ストリーミング音声を一時停止状態から再生状態へ遷移させることを特徴とする。
【０２５０】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５１】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルと、携帯端末のゲートウェイ機能を使用し外部のネットワークとデータ通信を実現するためのダイヤルアップ通信プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとダイヤルアップ通信プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつダイヤルアップ通信プロトコルがデータ通信状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、データ通信状態を維持させることを特徴とする。
【０２５２】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＤＵＮアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５３】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にある電話帳データをダウンロードするための電話帳転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルと電話帳転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつ電話帳転送プロトコルが電話帳データ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、電話帳転送状態を維持することを特徴とする。
【０２５４】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＰＢＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５５】
本発明の車載装置は、自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にあるメッセージデータをダウンロードするためのメッセージ転送プロトコルとを同時に接続する接続手段と、前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制
御手段とを備え、前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとメッセージ転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつメッセージ転送プロトコルがメッセージデータ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持することを特徴とする。
【０２５６】
この構成を有することにより、マルチプロファイル動作中（ＨＦＰアプリ／ＡＶＰアプリ／ＭＡＰアプリ）にリンクロスが発生した場合に、リンクロス前のアプリ状態管理テーブルに従い適切にリンクロス前の状態へ復旧することができ、ユーザにとって不要な操作を行うことなく各アプリが復旧するので利便性を高めることができる。特にユーザが運転中の場合には、安全運転に寄与することができる。
【０２５７】
本発明のリンクロス復旧方法は、無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置のリンクロス復旧方法において、前記無線装置の制御部に、無線通信路のリンクロスを検知するリンクロス検知ステップと、リンクロス前の複数のアプリケーションの状態を記憶するアプリ状態記憶ステップと、前記リンクロス検知手段がリンクロスを検知した後、無線通信路を復旧する復旧ステップと、前記復旧ステップにて無線通信路を復旧した後、前記アプリ状態記憶ステップにて記憶したアプリ記憶状態に従ってアプリケーションの復旧を行うアプリ復旧ステップと、を実行させることを特徴とする。
【０２５８】
この構成を有することにより、複数のアプリケーションがリンクロス前に起動していてもアプリ状態記憶手段に記憶されているアプリ記憶状態に従いアプリケーションの復旧を行うことができる。
【産業上の利用可能性】
【０２５９】
本発明の無線通信装置は、車両内に搭載するハンズフリー装置、カーナビゲーション装置、カーマルチメディア端末、携帯電話、ＰＨＳなどの携帯端末等として有用である。
【符号の説明】
【０２６０】
１ 公衆網
１０ 第１の通信レイヤ構造
２０ 第２の通信レイヤ構造
３０ 第３の通信レイヤ構造
１００ 無線通信装置
１０１ 近距離無線通信部
１０２ 制御部
１０３ 音声入力部
１０４ 音声出力部
１０５ 映像入力部
１０６ 映像出力部
１０７ データ入力部
１０８ データ出力部
１０９ 記憶部
２００ 対向無線通信装置
３００ 車載装置
４００ 携帯端末
【特許請求の範囲】
【請求項１】
無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、
無線通信路のリンクロスを検知するリンクロス検知手段と、
リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、
リンクロスした無線通信路を復旧する復旧手段と、
アプリケーションの復旧を行うアプリ復旧手段とを備え、
前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする無線通信装置。
【請求項２】
前記アプリ状態記憶手段が記憶する前記アプリ状態は、リンクロス直前の現在起動中のアプリか否か、一時待機中であるか否か、現在起動中のアプリと同時動作する共存中であるか否かを含むことを特徴とする請求項１に記載の無線通信装置。
【請求項３】
前記復旧手段によって無線通信路が所定の時間内に復旧できない場合は、前記復旧手段が前記アプリ状態をクリアすることを特徴とする請求項１又は請求項２に記載の無線通信装置。
【請求項４】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとを同時に接続してオーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させることを特徴とする車載装置。
【請求項５】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルと、携帯端末のゲートウェイ機能を使用し外部のネットワークとデータ通信を実現するためのダイヤルアップ通信プロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとダイヤルアップ通信プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつダイヤルアップ通信プロトコルがデータ通信状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、データ通信状態を維持させることを特徴とする車載装置。
【請求項６】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にある電話帳データをダウンロードするための電話帳転送プロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルと電話帳転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつ電話帳転送プロトコルが電話帳データ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、電話帳転送状態を維持することを特徴とする車載装置。
【請求項７】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にあるメッセージデータをダウンロードするためのメッセージ転送プロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとメッセージ転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつメッセージ転送プロトコルがメッセージデータ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持することを特徴とする車載装置。
【請求項８】
無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置のリンクロス復旧方法において、
前記無線装置の制御部に、
無線通信路のリンクロスを検知するリンクロス検知ステップと、
リンクロス前の複数のアプリケーションの状態を記憶するアプリ状態記憶ステップと、
前記リンクロス検知手段がリンクロスを検知した後、無線通信路を復旧する復旧ステップと、
前記復旧ステップにて無線通信路を復旧した後、前記アプリ状態記憶ステップにて記憶したアプリ記憶状態に従ってアプリケーションの復旧を行うアプリ復旧ステップと、
を実行させることを特徴とするリンクロス復旧方法。
【請求項１】
無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置において、
無線通信路のリンクロスを検知するリンクロス検知手段と、
リンクロス前の複数のアプリケーションの状態をアプリ状態として記憶するアプリ状態記憶手段と、
リンクロスした無線通信路を復旧する復旧手段と、
アプリケーションの復旧を行うアプリ復旧手段とを備え、
前記アプリ復旧手段は、前記リンクロス検知手段がリンクロスを検知して前記復旧手段が無線通信路を復旧した後に前記アプリ状態記憶手段に記憶されているアプリ記憶状態に従ってアプリケーションの復旧を行なうことを特徴とする無線通信装置。
【請求項２】
前記アプリ状態記憶手段が記憶する前記アプリ状態は、リンクロス直前の現在起動中のアプリか否か、一時待機中であるか否か、現在起動中のアプリと同時動作する共存中であるか否かを含むことを特徴とする請求項１に記載の無線通信装置。
【請求項３】
前記復旧手段によって無線通信路が所定の時間内に復旧できない場合は、前記復旧手段が前記アプリ状態をクリアすることを特徴とする請求項１又は請求項２に記載の無線通信装置。
【請求項４】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとを同時に接続してオーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させることを特徴とする車載装置。
【請求項５】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から自装置へ転送するためのオーディオプロトコルと、携帯端末のゲートウェイ機能を使用し外部のネットワークとデータ通信を実現するためのダイヤルアップ通信プロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとダイヤルアップ通信プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつダイヤルアップ通信プロトコルがデータ通信状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、データ通信状態を維持させることを特徴とする車載装置。
【請求項６】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にある電話帳データをダウンロードするための電話帳転送プロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルと電話帳転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつ電話帳転送プロトコルが電話帳データ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させ、電話帳転送状態を維持することを特徴とする車載装置。
【請求項７】
自装置と携帯端末との間でハンズフリー通話を実現するためのハンズフリー通話プロトコルと、オーディオストリーミング音声を携帯端末から車載装置へ転送する機能を実現するためのオーディオプロトコルと、携帯端末にあるメッセージデータをダウンロードするためのメッセージ転送プロトコルとを同時に接続する接続手段と、
前記接続手段と前記携帯端末との間の通信プロトコルの接続及び切断、復旧を制御する制御手段とを備え、
前記制御手段は、前記接続手段と前記携帯端末との間でハンズフリー通話プロトコルとオーディオプロトコルとメッセージ転送プロトコルを同時に接続し、オーディオストリーミング音声が一時停止状態かつハンズフリーが通話状態かつメッセージ転送プロトコルがメッセージデータ転送状態であるときにリンクロスが発生した場合、リンクロス直前の状態へ復旧させるとともに、ハンズフリー通話が終了した際にはオーディオストリーミング音声を一時停止状態から再生状態へ遷移させると共にメッセージ転送状態を維持することを特徴とする車載装置。
【請求項８】
無線通信路上で複数のアプリケーションに係わる情報の通信を行う無線通信装置のリンクロス復旧方法において、
前記無線装置の制御部に、
無線通信路のリンクロスを検知するリンクロス検知ステップと、
リンクロス前の複数のアプリケーションの状態を記憶するアプリ状態記憶ステップと、
前記リンクロス検知手段がリンクロスを検知した後、無線通信路を復旧する復旧ステップと、
前記復旧ステップにて無線通信路を復旧した後、前記アプリ状態記憶ステップにて記憶したアプリ記憶状態に従ってアプリケーションの復旧を行うアプリ復旧ステップと、
を実行させることを特徴とするリンクロス復旧方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【公開番号】特開２０１３−１０６２１８（Ｐ２０１３−１０６２１８Ａ）
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１１−２４９２６７（Ｐ２０１１−２４９２６７）
【出願日】平成２３年１１月１５日（２０１１．１１．１５）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年１１月１５日（２０１１．１１．１５）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]