JP5227937B2

JP5227937B2 - ハンズフリーシステムの通話確認方法

Info

Publication number: JP5227937B2
Application number: JP2009254565A
Authority: JP
Inventors: 文夫渡邊; 歩川上
Original assignee: Alps Electric Co Ltd
Current assignee: Alps Alpine Co Ltd
Priority date: 2009-11-06
Filing date: 2009-11-06
Publication date: 2013-07-03
Anticipated expiration: 2029-11-06
Also published as: CN102055829A; JP2011101198A

Description

本発明は、例えば携帯電話機等の携帯機器をユーザが実際に手に持つことなく、別に用意された通話機器を介してハンズフリー通話を可能とするハンズフリーシステムの通話確認方法に関するものである。

従来、例えば車両に搭載するタイプのハンズフリーシステムとして、携帯電話機と車載ユニットとを有線接続するタイプの先行技術が知られている（例えば、特許文献１参照。）。この先行技術は、車載ユニット（システムの本体）を携帯電話機と有線接続した状態で使用することにより、その本体に内蔵されたスピーカやマイクを通じて相手先（遠端）とのハンズフリー通話を実現する。またこの先行技術では、システムの本体に「通話開始」キー及び「通話終了」キーを別々に備えることで、着信時にユーザが「通話開始」キーを操作すると、携帯電話機における通話を開始することができ、また通話中にユーザが「通話終了」キーを操作すると、携帯電話機における通話を終了することができる。

上記とは別に、携帯電話機と車載ユニットとを無線接続するタイプのハンズフリーシステムに関する先行技術もまた知られている（例えば、特許文献２参照。）。この先行技術は、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格の近距離無線通信を用いて携帯電話機と車載ユニットとを接続するものである。このため、ユーザが携帯電話機を車内に持ち込むだけでハンズフリー通話が実現可能となり、それだけユーザにとっての使い勝手がよい。

先に挙げた先行技術（特許文献１）は、システム本体と携帯電話機との接続に有線を利用するため、ノイズの影響が少なく、相互の通信が安定している。ただし、ケーブルやコネクタ等の接続インタフェースが適合する機器同士でなければハンズフリーシステムを構築することができないため、ハードウエア上の制約を受けるところが難点である。この点、後者の先行技術（特許文献２）のように汎用の近距離無線通信を利用して接続を行う場合、その通信規格に準拠した通信モジュールを車載ユニットと携帯電話機の双方が搭載していれば、比較的容易にハンズフリーシステムを構築することができる。このため今後、近距離無線通信を用いた無線接続がハンズフリーシステムの主流になるものと考えられる。

特開２００１−３０９００８号公報（第４−第５頁、図１，図２）特許第３９５４９４８号公報

しかしながら、ハンズフリーシステムに汎用の近距離無線通信（例えばＢｌｕｅｔｏｏｔｈ：登録商標）を利用する場合、その通信規格に準拠した動作を各デバイスが忠実に実行しなければ、それだけでシステム全体としての動作に不具合が生じることにも留意しなければならない。

例えば、ハンズフリー通話の実行中に携帯電話機が相手先（遠端）との通話を終了した場合、その「通話終了（終話）」を確実に車載ユニット（例えばカーオーディオ装置）に対して通知することが通信規格の仕様上で要求されている。これは、直接に電話回線と接続していない車載ユニットを「通話中」の状態から一旦解放し、その後の動作を可能とするためである。これを仮に、携帯電話機で実際に通話が終了した後も車載ユニットに対して「通話終了」を通知しないでいると、車載ユニットはいつまでも「通話中」であると認識し続けるため、次に外（遠端）から電話着信があっても着信自体を受け付けなかったり、その他の動作（例えば音楽の再生、ラジオ放送の出力等）を制限したりしてしまう。

もちろん、汎用の近距離無線通信に対応している多くのデバイス（通信モジュール）は、通常、その通信規格に準拠して正常に動作することを期待して設計されている。しかし、通信規格に定める仕様上の要求が多岐にわたる場合、デバイスによっては一部の要求を満たさないもの（例えば、特定の機種や型番の携帯電話機）も実際に存在し、それらが多く世界市場に流通しているという事実も見逃せない。このため、全てのデバイスが通信規格の仕様を常に満足することを過信して安易にハンズフリーシステムを構築すると、場合によってはシステムの動作が不安定化し、結果的にユーザの利便性を損ねてしまうという実用上の問題がある。

そこで本発明は、通信規格の仕様を一部満足しないデバイスが使用される可能性をも想定した上で、より汎用性の高いハンズフリーシステムの構築を実現できる技術の提供を課題とする。

上記の課題を解決するため、本発明は以下の解決手段を採用する。
解決手段１：本発明は、携帯機器と通話機器とハンズフリーシステムを構築した場合を想定する。携帯機器は電話回線に接続可能であり、通話機器は、携帯機器との間で相互に通信を行うことで携帯機器とは別の設備を用いて電話回線を通じたハンズフリー通話を可能とするものである。携帯機器が内蔵スピーカやマイク等を有した携帯電話機であるとすると、通話機器は別の設備としてスピーカやマイクを有したハンズフリー用のユニットに相当する。携帯機器や通話機器は、それぞれが汎用の通信規格に準拠したデバイス（通信モジュール等）を搭載していれば、両者を通信可能な距離に近接させるだけで容易にハンズフリーシステムを構築することができる。

構築されたシステムは、実際に電話回線を介して相手先（遠端）との接続を確立する機能を携帯機器のリソースで賄うが、ハンズフリー通話中における音声のやりとり（送話、受話）は通話機器が仲立ちする。この場合、基本的に携帯機器が電話回線との接続を確立している間、通話機器はハンズフリー通話を実現するために自己のリソースを確保しておく必要がある。一方、ユーザ（近端）が相手先（遠端）との通話を終了した場合、携帯機器そのものは電話回線との接続を終了するが、これに伴って通話機器にも通話の終了を通知し、システム全体をハンズフリー通話の状態から一旦は解除する必要がある。

通常、システムに汎用の近距離無線通信規格を利用する場合、原則として通話の終了を携帯機器から通信機器へ自発的に通知することが仕様上で要求されている。このため、通信規格の仕様に則って各デバイスが正しく動作していれば、通話の終了に伴い、システム全体としてハンズフリー通話の終了を自ずと確認することができる。しかしながら、そこに一部の仕様を満足しないデバイスが紛れ込んだ場合、上記のようにシステム全体として通話の確認が困難になる。

本発明は、上記のような場合にシステムによる通話の状態を安定して確認（把握）するための通話確認方法であって、以下の工程を有するものである。

（１）質問工程
この工程では、通話機器から携帯機器に対して電話回線との接続に関する動作状態を問い合わせる。なお、通話機器から携帯機器への問い合わせには、例えば汎用の通信規格に準拠した通信手段を用いることができる。

（２）確認工程
この工程では、先の問い合わせに対する携帯機器からの応答結果に基づき通話機器にてハンズフリーシステムによる通話の状態を確認する。なお携帯機器から通話機器への応答もまた、例えば汎用の通信規格に準拠した通信手段を用いることができる。

本発明の通話確認方法によれば、（１）の質問工程で携帯機器への問い合わせを行うことにより、その時点で電話回線との接続に関する動作状態を通話機器に対して応答させることができる。ここでいう「電話回線との接続に関する動作状態」には、単に「接続」か「非接続」かの状態のみならず、「待受中」や「通話中」、「非通話中（通話終了）」といった電話機としてのサービス動作状態が含まれる他、さらに細かくは、「通話中」、「三者通話の保留中」、「発信中」、「発呼中」、「着信中」、「着信保留中」等の実際に電話をかけたときの通話状態も含まれる。

このため（２）の確認工程では、携帯機器からの応答結果に基づいて現在の状態を認識し、その上でシステム全体としての通話の状態がいかなる状態であるのかを正しく確認することができる。例えば、携帯機器から既に「通話終了（終話）」の状態である旨の応答があれば、それによって通話機器ではシステム全体としてハンズフリー通話を終了するべき状態であることを確認することができる。一方、携帯機器から「通話中」や「三者通話の保留中」、「発信中」、「発呼中」、「着信中」、「着信保留中」等のいずれかの状態である旨の応答があれば、それによって通話機器ではシステム全体としてハンズフリー通話を継続するべき状態であることを確認することができる。これにより、システム全体としての動作を常に安定化させて正常な動作を保証することができる。

解決手段２：上記（１）の質問工程では、携帯機器と通話機器との間での音声リンクが切断されたことを契機として、通話機器から携帯機器に対して電話回線を用いた通話が終了したか否かの問い合わせを行うことが好ましい。

システムに近距離無線通信を用いた場合、ハンズフリー通話の開始時に音声リンク（例えばＳＣＯリンク）が確立される。音声リンクは、相手先（遠端）との通話時にその接続を確立されるものであるが、携帯機器で「通話終了」が発生すると切断される。このとき、携帯機器が自発的に「通話終了」を通話機器に対して通知しなかったとしても、音声リンクが切断されたことを契機として上記の問い合わせを行うことにより、その応答結果から「通話終了」が発生したか否かを確認することができる。

解決手段３：あるいは上記（１）の質問工程では、携帯機器と通話機器との間での音声リンクが切断されたことを契機として、通話機器から携帯機器に対して電話回線を用いた通話がいかなる状態にあるかの問い合わせを行うこととしてもよい。

この場合も同様に、音声リンクは相手先（遠端）との通話中はその接続が維持されているが、携帯機器で「通話終了」が発生すると切断される。このとき、携帯機器が自発的に「通話終了」を通話機器に対して通知しなかったとしても、音声リンクが切断されたことを契機として上記の問い合わせを行うことにより、その応答結果から「通話の状態」を確認することができる。なお、この場合の問い合わせは「通話がいかなる状態にあるのか」であるため、上記の「通話中」や「三者通話の保留中」、「発信中」、「発呼中」、「着信中」、「着信保留中」等の細かな通話状態を確認することができる他、既に「通話終了」の状態であることも確認することができる。

また音声リンクの切断は、上記のように相手先（遠端）との通話が終了した場合に発生するが、未だ携帯機器が通話中であっても、通話機器の設備を用いたハンズフリー通話を終了した場合にも発生し得る。例えば、それまでユーザが相手先（遠端）との通話をハンズフリーで行っていたところ、ある時点から携帯機器を手に持って通話を開始した場合、それまで確立されていた音声リンクは切断される。この場合、やはり携帯機器が自発的に「通話終了」を通話機器に対して通知しなかったとしても、音声リンクが切断されたことを契機として上記の問い合わせを行うことにより、その応答結果から「通話がいかなる状態にあるのか」を確認することができる。

解決手段４：上記の解決手段３において、質問工程での問い合わせに対して携帯機器から未だ通話を終了していない旨の応答があった場合、その後に携帯機器から通話を終了した旨の応答があるまで所定の待ち時間をおいて質問工程での問い合わせを繰り返すこともできる。なお、「待ち時間」は常に一定の時間でなくてもよく、例えば問い合わせを繰り返す度に短縮したり、延長したりすることができる。

この場合、待ち時間ごとに繰り返し問い合わせを行うことで、定期又は不定期に通話の終了を含む通話状態を確認することができる。したがって、問い合わせ時に未だ通話中であればその旨を確認することができるし、既に通話が終了していれば、その旨を確実に確認することができる。

解決手段５：また本発明の通話確認方法は、解決手段１において、その質問工程では携帯機器と通話機器との間での音声リンクが切断されたことを契機として、通話機器から携帯機器に対して電話回線を用いた通話が終了したか否かの第１問い合わせを行い、その結果、携帯機器から通話が終了した旨の応答がない場合、通話機器から携帯機器に対して電話回線を用いた通話がいかなる状態にあるかの第２問い合わせを行う態様であってもよい。

上記の態様であれば、先ず第１問い合わせの結果から「通話終了」が確認できれば、それでひとまずシステムとしての通話の状態は確認できたことになるので、その後に第２問い合わせを行う必要がない。これに対し、第１問い合わせに対して未だ「通話終了」の応答がなかった場合、第２問い合わせによってその後の「通話の状態」を確認することができる。これにより、第１問い合わせ後も実際に通話が継続していれば、その状態が上記の「通話中」や「三者通話の保留中」、「発信中」、「発呼中」、「着信中」、「着信保留中」等のいずれにあるのかを確認することができるし、既に通話が終了していれば、「通話終了」の状態であることを確認することができる。

解決手段６：また解決手段５において、上記の質問工程での第２問い合わせに対して携帯機器から未だ通話を終了していない旨の応答があった場合、その後に携帯機器から通話を終了した旨の応答があるまで所定の待ち時間をおいて質問工程での問い合わせを繰り返すこともできる。

すなわち、第１問い合わせに対して携帯機器から「通話中（通話が終了していない）」の応答があり、次の第２問い合わせに対して何らかの「通話中の状態」の応答があった場合、その後は待ち時間ごとに「通話終了」の応答があるまで繰り返し問い合わせを行うことで、最終的に「通話終了」を確実に確認することができる。

なお本発明は、上記の携帯機器と通話機器とを備え、これら携帯機器及び通話機器を用いて解決手段１から６の通話確認方法を実行するハンズフリーシステムであってもよい。

本発明のハンズフリーシステムの通話確認方法によれば、例えば汎用の通信規格を有効に活用しつつ、デバイスの不備に起因したシステムの不具合を防止して安定したハンズフリー通話を実現することができる。

また、デバイスの個体（機種や型番等）に依存することなく安定してハンズフリーシステムを構築できるため、より汎用性の高いハンズフリーシステムとしての動作を保証することができる。

一実施形態の通話確認方法を実行するハンズフリーシステムの構成例を概略的に示す図である。車載電装ユニットと携帯電話機との間で各デバイスが正常にＢＴ通信を行った場合の流れを示すシーケンス図である。通話確認方法の第１パターンを示すシーケンス図である。通話確認方法の第２パターンを示すシーケンス図である。通話確認方法の第３パターンを示すシーケンス図である。通話確認方法の第４，第５パターンを示すシーケンス図である。ＢＴモジュールが制御プログラムとして実行する通話確認処理の手順例を示すフローチャートである。

以下、図面を参照しながら本発明の実施形態について説明する。

図１は、一実施形態の通話確認方法を実行するハンズフリーシステム１０の構成例を概略的に示す図である。このハンズフリーシステム１０は、例えば自動車に搭載された車載電装ユニット１２をハンズフリー通話機器とし、車内に持ち込まれる携帯電話機１８を携帯機器として構成されている。これら車載電装ユニット１２や携帯電話機１８は、いずれもブルートゥース（Ｂｌｕｅｔｏｏｔｈ：登録商標）規格に準拠した無線通信機能を有している。なお、以下の説明では、Ｂｌｕｅｔｏｏｔｈ（登録商標）を「ＢＴ」と略称するものとする。

車載電装ユニット１２は、例えば走行経路誘導（ナビゲーション）機能を有するほか、オーディオ再生機能やビデオ再生機能、ラジオ、テレビ等の受信機能等を有する。このため車載電装ユニット１２には、液晶ディプレイ等を用いた表示部２０や、図示しないプッシュスイッチ、キースイッチ、回転つまみ等を有した操作部２２が付属するほか、音響出力用のスピーカ２４、集音用のマイク２６等の周辺設備が付属している。

また車載電装ユニット１２は、上記の周辺設備を制御する制御部２８を内蔵するほか、ＢＴによる無線通信機能を発揮するためにＢＴモジュール３０を内蔵している。なお制御部２８は、例えば中央処理装置であるホストＣＰＵ２８ａを内蔵する他、図示しないＲＯＭ、ＲＡＭ等のメモリデバイスを備えたマイクロコンピュータである。このためＢＴモジュール３０は、車載電装ユニット１２（ホストＣＰＵ２８ａ）をホストとしてＢＴ通信を用いたサービス（例えばＡＣＬリンク、ＳＣＯリンク等の無線接続）を提供することができる。

携帯電話機１８は、無線通信（例えばＣＤＭＡサービス）を用いて電話回線に接続することができる携帯機器である。携帯電話機１８は先ず基地局１６に無線通信で接続し、そこから有線の電話回線を通じて例えば相手先（遠端）の固定電話機１４と通話することができる。なお、ここでは相手先（遠端）として固定電話機１４を例に挙げているが、相手先（遠端）が別の携帯電話機であってもよい。いずれにしても、携帯電話機１８にもまた図示しないＢＴモジュールが内蔵されており、このＢＴモジュールを用いて携帯電話機１８はＢＴによる無線通信機能を利用することができる。

ハンズフリーシステム１０は、携帯電話機１８と車載電装ユニット１２とを無線接続により音声リンク（ＳＣＯリンク）させた状態で、いわゆる「ハンズフリー通話」機能を提供することができる。ハンズフリー通話は、例えば車両の乗員であるユーザ（運転者Ｈ１、同乗者Ｈ２等）が携帯電話機１８を手に持たずとも、車載のスピーカ２４やマイク２６を通じて固定電話機１４のユーザＨ３との通話を実現するものである。

この他にハンズフリーシステム１０は、例えば携帯電話機１８と車載電装ユニット１２とを無線接続させた状態で、携帯電話機１８に格納されているオーディオデータを車載電装ユニット１２に転送しながらリアルタイムで再生し、そのスピーカ２４から音楽を出力する機能を提供することもできる。あるいは、携帯電話機１８に格納されているアドレス帳のデータを車載電装ユニット１２に転送し、これを表示部２０に出力する機能を提供することができる。ハンズフリーシステム１０は、転送されたアドレス帳のデータを活用して電話発信を行ったり、登録アドレス帳に登録されている相手からの着信時に着信者表示をしたりすることもできる。

〔ＢＴモジュールの構成〕
ここでは特に図示していないが、ＢＴモジュール３０は例えば車載電装ユニット１２内でＢＴアンテナやアンテナマッチング回路に接続されており、これらＢＴアンテナ及びアンテナマッチング回路により他のＢＴ機器（ここでは携帯電話機１８）との間でＢＴ規格による無線通信を行うことができる。なお、ＢＴアンテナやアンテナマッチング回路はＢＴモジュール３０に内蔵されていてもよい。

またＢＴモジュール３０は、通信回路としてＲＦ処理部やベースバンド処理部及び送受信処理部を有している。このうちＲＦ処理部はＢＴアンテナ及びアンテナマッチング回路を通じてＲＦ信号（例えば２．４ＧＨｚ帯）の受信処理を行う。またベースバンド処理部は、ＲＦ処理部にて受信した信号をＩＦ信号に変換し、復調してパケットデータ（受信パケット）を生成する。送受信処理部は、ベースバンド処理部で生成された受信パケットデータを上位レイヤ向けに再構築したり、逆に上位レイヤで生成された送信用パケットデータ（送信フレーム）をベースバンド処理部に提供したりする。送信用パケットデータはベースバンド処理部で変調され、ＲＦ処理部、アンテナマッチング回路及びＢＴアンテナを通じて携帯電話機１８に送信される。

その他にＢＴモジュール３０はホストインターフェースを内蔵しており、このホストインターフェースは、上記の車載電装ユニット１２が有する制御部２８（ホストＣＰＵ２８ａ）とＢＴモジュール３０との間の通信を制御する。すなわちホストインターフェースは、例えばハンズフリー通話により受信した音声通話データ（携帯電話機１８で受信した通話音声をパケットデータ化したもの）をホスト側の制御部２８に出力したり、マイク２６で拾った音声通話データ（運転者Ｈ１，同乗者Ｈ２の音声をパケットデータ化したもの）を制御部２８から受け取ったりする際の通信を制御する。

受信した音声通話データは、車載電装ユニット１２内でアナログ信号（電圧）に変換され、図示しないアンプを通じてスピーカ２４に出力される。また、マイク２６で拾った音声通話データは、ＢＴ通信（ＳＣＯリンク）によりＢＴモジュール３０から携帯電話機１８にパケット送信される。これにより、例えば携帯電話機１８からＢＴ通信で受信した音声通話データをスピーカ２４から出力したり、逆にマイク２６で拾った音声を携帯電話機１８に転送したりすることが可能になる。

〔通話確認方法〕
次に、本実施形態のハンズフリーシステム１０において実行される通話確認方法の一例について説明する。

〔デバイス正常時〕
図２は、車載電装ユニット１２と携帯電話機１８との間で各デバイスが正常にＢＴ通信を行った場合の流れを示すシーケンス図である。図２中、左側に位置する２本のカラムには車載電装ユニット１２による処理を示し、右側に位置する１本のカラムには携帯電話機１８による処理を示す。なお以下の説明では、車載電装ユニット１２をホストＣＰＵ２８ａとＢＴモジュール３０とに分けて説明する。また携帯電話機１８については、「ＢＴオーディオゲートウェイ（ＢＴＡＧ）」と一般化して呼称する。

〔ＢＴ接続〕
ＳＴ１：先ずハンズフリーシステム１０において、ＢＴモジュール３０とＢＴＡＧ１８とがＢＴ無線接続（ＲＦＣＯＭＭ接続）を完了する。これにより、ＢＴモジュール３０とＢＴＡＧ１８との間で音声リンク（ＳＣＯリンク）やデータリンク（ＡＣＬリンク）が使用可能となる。

ＳＴ２，ＳＴ３：ＲＦＣＯＭＭ接続完了により、ＢＴモジュール３０及びＢＴＡＧ１８の各デバイスがそれぞれハンズフリー通話に必要な送受信処理を開始する。これにより、以後はＢＴモジュール３０とＢＴＡＧ１８とが相互に通信を行いつつ、車内では車載のスピーカ２４及びマイク２６を通じてＢＴＡＧ１８と固定電話機１４との間での音声通話がハンズフリーで実現可能となる。

〔終話発生時〕
ＳＴ４：この後、例えば遠端の固定電話機１４又は近端のＢＴＡＧ１８で終話（通話の終了）が発生すると、ＢＴＡＧ１８において終話処理が行われる。

ＳＴ５：また終話の発生により、ＢＴ通信規格の仕様に基づいてＢＴＡＧ１８は、ＢＴモジュール３０に対して例えば「＋ＣＩＥＶ（Ｃａｌｌ＝０）」と表記される終話イベントを発行する。

ＳＴ６：ＢＴモジュール３０は受信処理を行い、ＢＴＡＧ１８から通知された終話イベントを解釈する。
ＳＴ７：そしてＢＴモジュール３０は、受け取った終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」をホストＣＰＵ２８ａに通知する。これによりホストＣＰＵ２８ａは、ハンズフリーシステム１０において通話が終了した状態にあることを確認することができる。

以上の処理シーケンスは、一般的なＢＴ通信規格に基づいて各デバイスが正常に動作した場合に実現される。ただし、実際にはＢＴ通信規格の仕様の一部を満足しないＢＴＡＧ１８も存在しており、その場合はＢＴＡＧ１８で終話が発生しても、終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」がＢＴモジュール３０に対して通知されない。この場合、実際に通話が終了していても、ＢＴモジュール３０が終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」を受け取っていないので、そのままではホストＣＰＵ２８ａで通話の終了を確認することができない。

そこで本実施形態では、以下に挙げる複数パターンのシーケンスを採用することで、ハンズフリーシステム１０としての通話の状態を確認することとしている。

〔第１パターン〕
図３は、通話確認方法の第１パターンを示すシーケンス図である。なお、図３以降においては、既に図２を用いて説明した処理と同じものには共通の符号を付し、その重複した説明を省略するものとする。

〔ＢＴ接続から終話発生まで〕
ＳＴ１〜ＳＴ４：第１パターンにおいても、上記のＢＴ接続から終話発生までのシーケンスが実行される。

ただし、ＢＴＡＧ１８においてデバイス（内蔵モジュール）が仕様を満たしていない場合、図３中に点線の矢印で示されるように、終話が発生しても終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」を発行しない（図中「×」印を付す。）。したがって、ＢＴモジュール３０でも終話イベントを受け取らないため、同じく図３中に点線の矢印で示されるように、ＢＴモジュール３０からホストＣＰＵ２８ａへ終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」を通知することができない（図中「×」印を付す。）。

〔ＳＣＯリンク切断時〕
ＳＴ１０：ただし、通話が終了したことで、ＢＴモジュール３０とＢＴＡＧ１８との間での音声リンク（ＳＣＯリンク）は切断される。

〔質問工程〕
ＳＴ１１：音声リンク（ＳＣＯリンク）の切断を契機として、ＢＴモジュール３０が質問処理を実行し、例えば「ＡＴ＋ＣＩＮＤ？」で表記される問い合わせ用のコマンドを生成する。このコマンドは、ＢＴＡＧ１８に対して現在のサービス状態（ｓｅｒｖｉｃｅ，ｃａｌｌ，ｃａｌｌｓｅｔｕｐ，ｓｉｇｎａｌ，ｒｏａｍ）を問い合わせるものである。

ＳＴ１２：そしてＢＴモジュール３０からＢＴＡＧ１８に対し、上記の「ＡＴ＋ＣＩＮＤ？」と表記される問い合わせイベントを発行する。

ＳＴ１３：ＢＴＡＧ１８はイベント受信処理を実行し、問い合わせイベントの「ＡＴ＋ＣＩＮＤ？」で表記されるコマンドを解釈する。そしてＢＴＡＧ１８は、そのコマンドに対する応答イベントを生成する。

ＳＴ１４：そしてＢＴＡＧ１８は、生成した応答イベントをＢＴモジュール３０に対して発行する。このとき実際に通話が終了していれば、応答イベントの内容は「＋ＣＩＥＶ（Ｃａｌｌ＝０）」で表記される終話イベントとなるはずである（図の表記は異なる）。

〔確認工程〕
ＳＴ１５：この場合、ＢＴモジュール３０は受信処理を行い、ＢＴＡＧ１８から通知された終話イベントを解釈する。
ＳＴ１６：そしてＢＴモジュール３０は、受け取った終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」をホストＣＰＵ２８ａに通知する。これによりホストＣＰＵ２８ａは、ハンズフリーシステム１０において通話が終了した状態にあることを確認することができる（ここでも図の表記が異なる）。

以上のシーケンスは、問い合わせイベントの「ＡＴ＋ＣＩＮＤ？」に対してＢＴＡＧ１８のデバイスが正常に応答イベントを通知した場合の流れである。したがって第１パターンは、この段階でデバイスが正常に動作した場合の通話確認方法として有効である。

〔デバイス非正常動作時〕
ＳＴ１４：しかしながら、上記のようにＢＴＡＧ１８のデバイスがここでもＢＴ通信規格の仕様を満たしていなかった場合、実際には図３に示されるように、ここでは本来の状態（終話している状態）とは異なった内容の「＋ＣＩＥＶ（Ｃａｌｌ＝１）」で表記される通話中イベントをＢＴＡＧ１８が発行してしまうことがある。

ＳＴ１５：この場合、ＢＴモジュール３０は受信処理を行い、ＢＴＡＧ１８から通知された通話中イベントをそのまま解釈する。

ＳＴ１６：そしてＢＴモジュール３０は、受け取った通話中イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝１）」をホストＣＰＵ２８ａに通知することになる。この場合、ホストＣＰＵ２８ａは、ハンズフリーシステム１０において実際に通話が終了した状態にあることを未だ確認することができない。そこで本実施形態では、以下に挙げる通話確認方法の第２パターンを実行することができる。

〔第２パターン〕
図４は、通話確認方法の第２パターンを示すシーケンス図である。この第２パターンは、例えば上記の第１パターンで通話の確認ができなかった場合（ＢＴＡＧ１８から「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されなかった場合）に適用することができる。ただし、特にこのような条件を考慮することなく第２パターンを実行することもできる。

〔ＢＴ接続から終話発生、ＳＣＯリンク切断まで〕
ＳＴ１〜ＳＴ４，ＳＴ１０：第２パターンにおいても、上記のＢＴ接続から終話発生、及びＳＣＯリンク切断までの流れは同様に行われる。

〔質問工程〕
ＳＴ２０：第２パターンでは、音声リンクの切断を契機としてＢＴモジュール３０が質問処理を実行し、例えば「ＡＴ＋ＣＬＣＣ」で表記される問い合わせ用のコマンドを生成する。このコマンドは、このコマンドは、ＢＴＡＧ１８に対して現在の通話状態（通話中、三者通話の保留中、発信中、発呼中、着信中、着信保留中）を問い合わせるものである。

ＳＴ２１：そしてＢＴモジュール３０からＢＴＡＧ１８に対し、上記の「ＡＴ＋ＣＬＣＣ」で表記される問い合わせイベントを発行する。

ＳＴ２２：ＢＴＡＧ１８はイベント受信処理を実行し、問い合わせイベントの「ＡＴ＋ＣＬＣＣ」で表記されるコマンドを解釈する。そしてＢＴＡＧ１８は、そのコマンドに対する応答イベントを生成する。

ＳＴ２３：そしてＢＴＡＧ１８は、生成した応答イベントをＢＴモジュール３０に対して発行する。このとき実際に通話が終了していれば（通話していない状態）、応答イベントの内容は「ＯＫ」のみで表記されるものとなる。一方、実際に未だ通話が終了していなければ（通話している状態）、応答イベントの内容は「ＯＫ＋ＣＬＣＣ」で表記されるものとなり、その中の「＋ＣＬＣＣ」にて現在の状態が「通話中」、「三者通話の保留中」、「発信中」、「発呼中」、「着信中」、「着信保留中」のいずれにあるのかを通知することとなる。

〔確認工程〕
ＳＴ２４：この場合、ＢＴモジュール３０は受信処理を行い、ＢＴＡＧ１８から通知された応答イベントの内容を解釈する。

ＳＴ２５：そしてＢＴモジュール３０は、受け取った応答イベントの「ＯＫ」又は「ＯＫ＋ＣＬＣＣ」をホストＣＰＵ２８ａに通知する。これによりホストＣＰＵ２８ａは、例えば「ＯＫ」を受け取った場合はハンズフリーシステム１０において通話が終了した状態（通話していない状態）にあることを確認することができる。一方、「ＯＫ＋ＣＬＣＣ」を受け取った場合、ホストＣＰＵ２８ａは「＋ＣＬＣＣ」にて通知された現在の通話状態を確認することができる。

〔実際の終話時〕
通常、「ＳＴ１０」で音声リンク（ＳＣＯリンク）の切断時にＢＴＡＧ１８にて実際に通話が終了していれば、「ＳＴ２３」での応答イベントは「ＯＫ」のみとなる。したがって、実際の終話を契機として音声リンク（ＳＣＯリンク）が切断された場合、第２パターンのシーケンスを適用すれば、ハンズフリーシステム１０による通話が終了した状態であることをホストＣＰＵ２８ａで正しく確認することができる。

〔ＳＣＯリンク切断後の通話〕
その一方でハンズフリーシステム１０においては、ＢＴモジュール３０とＢＴＡＧ１８との間で音声リンク（ＳＣＯリンク）が切断された後も、ＢＴＡＧ１８で通話が実行されている場合もあり得る。例えば同じ近端のユーザであっても、運転者Ｈ１でない同乗者Ｈ２が車内で通話（例えばプライベートな通話）を行う場合、必ずしもハンズフリー通話を利用するとは限らない。この場合、同乗者Ｈ２は例えば車載電装ユニット１２によるハンズフリー通話機能をＯＦＦにしてＢＴＡＧ１８をキー操作して発信又は着信を行い、その後の通話はＢＴＡＧ１８（つまり携帯電話機１８）を手にとった状態で行う。

上記の場合、先の「ＳＴ１０」で音声リンクが切断された後、「ＳＴ２１」でＢＴモジュール３０からの問い合わせイベント「ＡＴ＋ＣＬＣＣ」に対し、ＢＴＡＧ１８は「ＳＴ２３」で実際に「ＯＫ＋ＣＬＣＣ（通話中）」の応答イベントを通知する。すると、これを受けてＢＴモジュール３０は、「ＳＴ２５」で「ＯＫ＋ＣＬＣＣ（通話中）」をホストＣＰＵ２８ａに通知する。この場合、ホストＣＰＵ２８ａは「音声リンク（ＳＣＯリンク）の切断後、引き続きＢＴＡＧ１８で通話中」の状態であることを確認することができる。

〔第３パターン〕
図５は、通話確認方法の第３パターンを示すシーケンス図である。この第３パターンは、例えば上記の第２パターンで音声リンク（ＳＣＯリンク）の切断後、引き続きＢＴＡＧ１８で「通話中」の確認がされた場合（ＢＴＡＧ１８から「ＯＫ＋ＣＬＣＣ」が通知された場合）に適用することができる。

〔ＢＴ接続から終話発生、ＳＣＯリンク切断まで〕
ＳＴ１〜ＳＴ４，ＳＴ１０：第３パターンにおいても、上記のＢＴ接続から終話発生、及びＳＣＯリンク切断までの流れは同様に行われる。

〔ＳＣＯリンク切断後の通話〕
この後、例えば同乗者Ｈ２がハンズフリー機能を使用することなく、ＢＴＡＧ１８を直接キー操作して電話発信を行うと、ＢＴＡＧ１８は遠端の固定電話機１４とプライベートな通話状態になる。

〔ＳＣＯリンク切断から問い合わせ・応答イベント通知まで〕
ＳＴ２０〜ＳＴ２５：一方で第３パターンにおいても、ＳＣＯリンク切断後の問い合わせイベント発行と応答イベントの通知と受領が行われる。このときＢＴＡＧ１８が実際に通話中であるため、「ＳＴ２３」での応答イベントは「ＯＫ＋ＣＬＣＣ」となり、その結果、ホストＣＰＵ２８ａにて「通話中」の状態が確認される。

〔遠端にて終話〕
ＳＴ３０：この後、例えば遠端のユーザＨ３（固定電話機１４）で通話を終了すると、それによってＢＴＡＧ１８による電話回線への接続は切断される。
ＳＴ３１：この場合、ＢＴＡＧ１８は同じく終話処理を行う。

〔デバイス非正常動作時〕
（ＳＴ３２（フェイル））：ここでも同様に、ＢＴＡＧ１８においてデバイス（内蔵モジュール）がＢＴ通信規格の仕様を満たしていない場合、図５中に点線の矢印で示されるように、終話が発生しても終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」を発行しない（図中「×」印を付す。）。

（ＳＴ３４（フェイル））：したがって、ＢＴモジュール３０でも終話イベントを受け取らないため、同じく図５中に点線の矢印で示されるように、ＢＴモジュール３０からホストＣＰＵ２８ａへ終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」を通知することができない（図中「×」印を付す。）。

したがって、このままではホストＣＰＵ２８ａにて「通話終了」の状態を確認することができない。そこで第３パターンでは、以下のシーケンスを実行することで通話の状態を確認することとしている。

〔イベントトリガ発生〕
ＳＴ３５：例えば、先の「ＳＴ２３」で応答イベントの「ＯＫ＋ＣＬＣＣ」を受け取った場合、これを受けてＢＴモジュール３０がイベントトリガを発生させる。イベントトリガは、応答イベントの「ＯＫ＋ＣＬＣＣ」を受け取ったことを条件として発生させることができる。その後もイベントトリガは、例えばタイマを用いた定期イベントとして発生させることもできるし、あるいはタイマを用いることなくランダムに発生させることもできる。なお、図５のシーケンス例では遠端での通話終了（ＳＴ３０）後にイベントトリガを発生させる流れとなっているが、通話終了（ＳＴ３０）より以前から、ＢＴモジュール３０で自発的にイベントトリガを発生させるシーケンスであってもよい。

〔質問工程〕
ＳＴ３６：いずれにしても、イベントトリガが発生すると、ＢＴモジュール３０は質問処理を実行し、上記の「ＡＴ＋ＣＬＣＣ」で表記される問い合わせ用のコマンドを生成する。

ＳＴ３７：そしてＢＴモジュール３０からＢＴＡＧ１８に対し、問い合わせイベントの「ＡＴ＋ＣＬＣＣ」を発行する。

ＳＴ３８：ＢＴＡＧ１８はイベント受信処理を実行し、問い合わせイベントの「ＡＴ＋ＣＬＣＣ」で表記されるコマンドを解釈する。そしてＢＴＡＧ１８は、そのコマンドに対する応答イベントを生成する。

ＳＴ３９：そしてＢＴＡＧ１８は、生成した応答イベントをＢＴモジュール３０に対して発行する。上記のように、このとき実際に通話が終了していれば（通話していない状態）、応答イベントの内容は「ＯＫ」のみで表記されるものとなる。一方、未だ通話が終了していなければ（通話している状態）、応答イベントの内容は「ＯＫ＋ＣＬＣＣ」で表記されるものとなる。

〔確認工程〕
ＳＴ４０：ＢＴモジュール３０は受信処理を行い、ＢＴＡＧ１８から通知された応答イベントの内容を解釈する。

ＳＴ４１：そしてＢＴモジュール３０は、受け取った応答イベントの「ＯＫ」又は「ＯＫ＋ＣＬＣＣ」をホストＣＰＵ２８ａに通知する。これによりホストＣＰＵ２８ａは、例えば「ＯＫ」を受け取った場合はハンズフリーシステム１０において通話が終了した状態（通話していない状態）にあることを確認することができる。一方、「ＯＫ＋ＣＬＣＣ」を受け取った場合、ホストＣＰＵ２８ａは「＋ＣＬＣＣ」にて通知された現在の通話状態を確認することができる。

〔問い合わせ・確認の反復〕
先の「ＳＴ４１」で「ＯＫ＋ＣＬＣＣ」を通知した場合、ＢＴモジュール３０はその後も「ＳＴ３５」でイベントトリガを発生させる。これにより、イベントトリガが発生するごとに「ＳＴ３６」〜「ＳＴ４１」までのシーケンスが繰り返し実行されることになる。

そしてこの後、例えば実際に遠端の固定電話機１４にて通話を終了した場合、「ＳＴ３９」でＢＴＡＧ１８から「ＯＫ」のみの応答イベントが通知される。これを受けて、ＢＴモジュール３０は「ＳＴ４１」で「ＯＫ」のみをホストＣＰＵ２８ａに通知する。これにより、ホストＣＰＵ２８ａはハンズフリーシステム１０による通話が終了した状態であることを確認することができる。

以上の第３パターンは、音声リンク（ＳＣＯリンク）の切断後、ＢＴモジュール３０から問い合わせイベントとして「ＡＴ＋ＣＬＣＣ」を発行する場合のシーケンスである。その上で本実施形態では、音声リンク（ＳＣＯリンク）の切断後、問い合わせイベントとして先ず「ＡＴ＋ＣＩＮＤ？」を発行し、その応答イベントとして「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されなかった場合、次に問い合わせイベントとして「ＡＴ＋ＣＬＣＣ」を発行するというシーケンスを採用することもできる。以下、この場合のシーケンスを通話確認方法の第４パターンとして説明する。

〔第４パターン〕
図６は、通話確認方法の第４パターンを示すシーケンス図である。この第４パターンは、例えば上記の第１パターンで終話の確認ができない（ＢＴＡＧ１８から自発的に「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されない）とした場合、その後、音声リンク（ＳＣＯリンク）が切断された場合に適用することができる。

〔ＢＴ接続から終話発生、ＳＣＯリンク切断まで〕
ＳＴ１〜ＳＴ４，ＳＴ１０：第４パターンにおいても、上記のＢＴ接続から終話発生、及びＳＣＯリンク切断までの流れは同様に行われる。

〔第１問い合わせ：質問工程〕
ＳＴ１１：音声リンク（ＳＣＯリンク）の切断を契機として、ＢＴモジュール３０が質問処理を実行し、第１問い合わせコマンドとして「ＡＴ＋ＣＩＮＤ？」で表記されるコマンドを生成する。

ＳＴ１２：そしてＢＴモジュール３０からＢＴＡＧ１８に対し、上記の「ＡＴ＋ＣＩＮＤ？」で表記される問い合わせイベントを発行する。

ＳＴ１４：そしてＢＴＡＧ１８は、生成した応答イベントをＢＴモジュール３０に対して発行する。このとき実際に通話が終了していなければ、応答イベントの内容は「＋ＣＩＥＶ（Ｃａｌｌ＝１）」で表記される終話イベントとなる。

〔確認工程〕
ＳＴ１５：この場合、ＢＴモジュール３０は受信処理を行い、ＢＴＡＧ１８から通知された終話イベントを解釈する。
ＳＴ１６：そしてＢＴモジュール３０は、受け取った終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝１）」をホストＣＰＵ２８ａに通知する。これによりホストＣＰＵ２８ａは、ハンズフリーシステム１０において通話中の状態であることを確認することができる。

〔イベントトリガ発生〕
ＳＴ３５：第４パターンでは、先の「ＳＴ１４」で「＋ＣＩＥＶ（Ｃａｌｌ＝０）」以外の応答イベント、つまり、「＋ＣＩＥＶ（Ｃａｌｌ＝１）」の応答イベントを受け取った場合、これを契機としてＢＴモジュール３０がイベントトリガを発生させる。その後もイベントトリガは、例えばタイマを用いた定期割り込みイベントとして発生させることもできるし、あるいはタイマを用いることなくランダムに発生させることもできる。

〔第２問い合わせ：質問工程〕
ＳＴ３６：いずれにしても、イベントトリガが発生すると、ＢＴモジュール３０は質問処理を実行し、今度は第２問い合わせコマンドとして「ＡＴ＋ＣＬＣＣ」を生成する。

第４パターンのシーケンス中、ＢＴモジュール３０が応答イベントの「ＯＫ」を受け取った場合、それによって終話を確認することができるが、「ＯＫ＋ＣＬＣＣ」の応答イベントを受け取った場合、続けて以下の第５パターンのシーケンスを実行することができる。

〔第５パターン：第２問い合わせ・確認の反復〕
すなわち、先の「ＳＴ４１」で「ＯＫ＋ＣＬＣＣ」が通知された場合、ＢＴモジュール３０はその後も「ＳＴ３５」でイベントトリガを発生させる。これにより、イベントトリガが発生するごとに「ＳＴ３６」〜「ＳＴ４１」までのシーケンスが繰り返し実行されることになる。なおイベントトリガは、定期的又は不定期に発生させることができる。

〔制御プログラムの例〕
以上に挙げた第１〜第５パターンの各シーケンスは、例えばＢＴモジュール３０に以下の制御プログラムを組み込むことで実現できる。制御プログラムは、例えばＢＴモジュール３０に内蔵されたＲＯＭに記憶しておくことができる。

〔通話確認処理〕
図７は、ＢＴモジュール３０が制御プログラムとして実行する通話確認処理の手順例を示すフローチャートである。ＢＴモジュール３０は、図７に示される通話確認処理を例えばハンズフリー通話中にタイマ割込処理として実行することができる。以下、手順例に沿って説明する。

ステップＳ１００：処理開始に伴い、ＢＴモジュール３０はＢＴＡＧ１８から終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されたか否かを確認する。
ステップＳ１０１：その結果、実際に「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されていれば（ステップＳ１００：Ｙｅｓ）、ＢＴモジュール３０はここで終話を確認し、この処理を終了する。

これに対し、ＢＴＡＧ１８から終話イベントの「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されていなければ（ステップＳ１００：Ｎｏ）、ＢＴモジュール３０は次にステップＳ１０２を実行する。

ステップＳ１０２：ＢＴモジュール３０は、ＢＴＡＧ１８との間でＳＣＯリンクが切断されたか否かを確認する。ＳＣＯリンクが未だ切断されていなければ（Ｎｏ）、ＢＴモジュール３０はステップＳ１００に戻って終話イベントの確認を繰り返す。

〔第１パターンの場合〕
一方、ＳＣＯリンクが切断されたことを確認した場合（ステップＳ１０２：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ１０４に進む。

ステップＳ１０４：ＢＴモジュール３０は、ＢＴＡＧ１８に対して問い合わせイベントの「ＡＴ＋ＣＩＮＤ？」を発行する。

ステップＳ１０６：そしてＢＴモジュール３０は、ＢＴＡＧ１８から応答イベントとして「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されたか否かを確認する。

ステップＳ１０１：その結果、実際に「＋ＣＩＥＶ（Ｃａｌｌ＝０）」の応答イベントが通知されていれば（ステップＳ１０６：Ｙｅｓ）、ＢＴモジュール３０はここで終話を確認し、この処理を終了する。

ここまでの手順により、上述した第１パターンによるシーケンス（図３）を実現することができる。次に、第２パターンによるシーケンス（図４）を実現するための手順について説明する。

〔第２パターンの場合〕
先のステップＳ１０２でＳＣＯリンクが切断されたことを確認した場合（ステップＳ１０２：（Ｙｅｓ））、今度は図７中の接続記号「Ａ」→「Ａ」に従い、ＢＴモジュール３０は次にステップＳ１０８に進む。

ステップＳ１０８：ＢＴモジュール３０は、ＢＴＡＧ１８に対して問い合わせイベントの「ＡＴ＋ＣＬＣＣ」を発行する。

ステップＳ１１０：そしてＢＴモジュール３０は、ＢＴＡＧ１８から応答イベントとして「ＯＫ＋ＣＬＣＣ」が通知されたか否かを確認する。

ステップＳ１０１：その結果、「ＯＫ」のみで表記された応答イベントが通知された場合（ステップＳ１１０：Ｎｏ）、ＢＴモジュール３０はここで終話を確認し、この処理を終了する。

ここまでの手順により、上述した第２パターンによるシーケンス（図４）を実現することができる。次に、第３パターンによるシーケンス（図５）を実現するための手順について説明する。

〔第３パターンの場合〕
先のステップＳ１１０でＢＴＡＧ１８から応答イベントとして「ＯＫ＋ＣＬＣＣ」が通知されたことを確認した場合（ステップＳ１１０：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ１１２に進む。

ステップＳ１１２：この場合、ＢＴモジュール３０はイベントタイマをカウントする。具体的には、それまで停止していたタイマカウンタを起動し、そのカウントを開始する。

ステップＳ１１４：ＢＴモジュール３０は、予め設定されたカウント値（例えば数秒〜数十秒程度）にイベントタイマの値が達したか否かを確認する。未だカウント値に達していなければ（Ｎｏ）、ＢＴモジュール３０はステップＳ１１２に戻ってタイマカウントを継続する。

この後、イベントタイマの値がカウント値に達したことを確認すると（ステップＳ１１４：Ｙｅｓ）、ＢＴモジュール３０はイベントタイマを停止し、その値をリセットした上でステップＳ１０８に戻る。

これ以降、ＢＴモジュール３０はステップＳ１０８〜ステップＳ１１４を繰り返し実行する。これにより、ＢＴモジュール３０はＢＴＡＧ１８から「ＯＫ」の応答イベントが通知されるまで問い合わせイベントの「ＡＴ＋ＣＬＣＣ」を繰り返し発行することで、上述した第３パターンによるシーケンスを実現することができる。

〔第４パターンの場合〕
図７中、ステップＳ１０２の判断が肯定（Ｙｅｓ）である場合、接続記号「Ａ」→「Ａ」に従ってステップＳ１０２からステップＳ１０８にジャンプすると第３パターンによるシーケンスとなる。これに対し、接続記号「Ａ」→「Ａ」に従わずにステップＳ１０４に進むと、上述した第４パターンによるシーケンス（図６）を実現することができる。

ステップＳ１０４：すなわちＢＴモジュール３０は、ＢＴＡＧ１８に対して問い合わせイベントの「ＡＴ＋ＣＩＮＤ？」を発行する（第１問い合わせ）。

これに対し、先のステップＳ１０６でＢＴＡＧ１８から応答イベントとして「＋ＣＩＥＶ（Ｃａｌｌ＝０）」が通知されていなければ（ステップＳ１０６：Ｎｏ）、ＢＴモジュール３０は次にステップＳ１０８を実行する。

ステップＳ１０８：ここでＢＴモジュール３０は、ＢＴＡＧ１８に対して問い合わせイベントの「ＡＴ＋ＣＬＣＣ」を発行する（第２問い合わせ）。

ここまでの手順により、上述した第４パターンによるシーケンス（図６）を実現することができる。また、ステップＳ１１２以降を実行することで、上述した第５パターンによるシーケンス（同図）を実現することができる。

〔第５パターンの場合〕
すなわち、先のステップＳ１１０でＢＴＡＧ１８から応答イベントとして「ＯＫ＋ＣＬＣＣ」が通知されたことを確認した場合（ステップＳ１１０：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ１１２に進む。

ステップＳ１１４：ＢＴモジュール３０は、上記のカウント値にイベントタイマの値が達したか否かを確認する。未だカウント値に達していなければ（Ｎｏ）、ＢＴモジュール３０はステップＳ１１２に戻ってタイマカウントを継続する。

これ以降、ＢＴモジュール３０はステップＳ１０８〜ステップＳ１１４を繰り返し実行する。これにより、ＢＴモジュール３０はＢＴＡＧ１８から「ＯＫ」の応答イベントが通知されるまで問い合わせイベントの「ＡＴ＋ＣＬＣＣ」を繰り返し発行することで、上述した第５パターンによるシーケンスを実現することができる。

以上のように、本実施形態の通話確認方法によれば、ＢＴＡＧ１８（携帯電話機１８）がＢＴ通信規格の一部の仕様を満足しないデバイスを搭載していたとしても、ＢＴモジュール３０からの問い合わせを行うことで、最終的に通話終了（終話）の状態をホストＣＰＵ２８ａで確認することができる。

したがって、ホストＣＰＵ２８ａがいつまでも終話を確認できないままハンズフリーシステム１０の動作を不安定化させることがなく、終話を確認した場合はその後の動作（次の着信・発信によるハンズフリー通話、オーディオ出力等）をスムーズに実現することができる。

また、ＢＴ通信に対応している携帯電話機１８であれば、その機種や型番に制約されることなく、これを車載電装ユニット１２と組み合わせて容易にハンズフリーシステム１０を構築することができる。したがって、ハンズフリーシステム１０としての汎用性を向上し、より実用性の高い動作を保証することができる。

なお、図７に示されるフローチャートでは、最初にステップＳ１００で「＋ＣＩＥＶ（Ｃａｌｌ＝０）」の終話イベントを受け取ったか否かを確認しているが、特にこのような条件を判断することなく、ステップＳ１０２から処理を開始してもよい。

本発明は、上述した一実施形態に制約されることなく、種々に変形して実施可能である。例えば、ハンズフリーシステム１０は携帯電話機１８と車載電装ユニット１２との組み合わせだけでなく、その他の機器同士の組み合わせで構成されていてもよい。

また、ハンズフリーシステム１０は、第１〜第５パターンの全ての通話確認方法を常に適用するのではなく、いずれかの通話確認方法を選択的に適用するだけでもよい。

１０ハンズフリーシステム
１２車載電装ユニット
１４固定電話機
１６基地局
１８携帯電話機（ＢＴＡＧ）
２４スピーカ
２６マイク
２８制御部
２８ａホストＣＰＵ
３０ＢＴモジュール

Claims

電話回線に接続可能な携帯機器と、この携帯機器との間で相互に通信を行うことで前記携帯機器とは別の設備を用いて前記電話回線を通じたハンズフリー通話を可能とする通話機器とを備えたハンズフリーシステムの通話確認方法であって、
前記通話機器から前記携帯機器に対して前記電話回線との接続に関する動作状態を問い合わせる質問工程と、
前記問い合わせに対する前記携帯機器からの応答結果に基づき前記通話機器にてハンズフリーシステムによる通話の状態を確認する確認工程とを有し、
前記質問工程では、前記携帯機器と前記通話機器との間での音声リンクが切断されたことを契機として、前記通話機器から前記携帯機器に対して前記電話回線を用いた通話がいかなる状態にあるかの問い合わせを行い、前記問い合わせに対して前記携帯機器から未だ通話を終了していない旨の応答があった場合、その後に前記携帯機器から通話を終了した旨の応答があるまで所定の待ち時間をおいて前記質問工程での問い合わせを繰り返すことを特徴とするハンズフリーシステムの通話確認方法。
電話回線に接続可能な携帯機器と、この携帯機器との間で相互に通信を行うことで前記携帯機器とは別の設備を用いて前記電話回線を通じたハンズフリー通話を可能とする通話機器とを備えたハンズフリーシステムの通話確認方法であって、
前記通話機器から前記携帯機器に対して前記電話回線との接続に関する動作状態を問い合わせる質問工程と、
前記問い合わせに対する前記携帯機器からの応答結果に基づき前記通話機器にてハンズフリーシステムによる通話の状態を確認する確認工程とを有し、
前記質問工程では、
前記携帯機器と前記通話機器との間での音声リンクが切断されたことを契機として、前記通話機器から前記携帯機器に対して前記電話回線を用いた通話が終了したか否かの第１問い合わせを行い、その結果、前記携帯機器から通話が終了した旨の応答がない場合、前記通話機器から前記携帯機器に対して前記電話回線を用いた通話がいかなる状態にあるかの第２問い合わせを行うことを特徴とするハンズフリーシステムの通話確認方法。
請求項２に記載のハンズフリーシステムの通話確認方法において、
前記質問工程での前記第２問い合わせに対して前記携帯機器から未だ通話を終了していない旨の応答があった場合、その後に前記携帯機器から通話を終了した旨の応答があるまで所定の待ち時間をおいて前記質問工程での問い合わせを繰り返すことを特徴とするハンズフリーシステムの通話確認方法。