(57)【要約】【課題】リモートデバイスの状態によって当該リモートデバイスから応答が返らない場合であっても初期化の必要がない通信を実行することを可能とする。【解決手段】送受信部１２は、通信制御装置１０とリモートデバイス２０との間の第１の通信状態を通知するための第１のＭＳＣ通知を当該リモートデバイス２０に対して送信する。制御部１３は、第１のＭＳＣがリモートデバイス２０に対して送信されると、当該第１のＭＳＣ通知に対する応答待ちであることを示すフラグをフラグ格納部１４に格納する。制御部１３は、第１の通信状態から第２の通信状態に変更された場合、フラグ格納部１４に格納されたフラグが第１のＭＳＣ通知に対する応答待ちであることを示すかを判定する。送受信部１２は、フラグが応答待ちであることを示すと判定された場合、第２の通信状態を通知するための第２のＭＳＣのリモートデバイスに対する送信を抑止する。【選択図】      図２
2010088043.tif 000002
【特許請求の範囲】
【請求項１】
他の通信機器との通信において当該他の通信機器からのデータを受信可能であるかを含む当該他の通信機器との間の通信状態の変更に応じて当該通信状態を当該他の通信機器に対して通知する通信制御装置のコンピュータによって実行される通信制御プログラムであって、
前記コンピュータに、
前記他の通信機器との間の第１の通信状態を通知するための第１のメッセージを当該他の通信機器に対して送信するステップと、
前記第１のメッセージが前記他の通信機器に対して送信されると、当該第１のメッセージに対する応答待ちであることを示すフラグをフラグ格納手段に格納するステップと、
前記第１の通信状態が第２の通信状態に変更された場合、前記フラグ格納手段に格納されたフラグが前記第１のメッセージに対する応答待ちであることを示すかを判定するステップと、
前記フラグが前記第１のメッセージ対する応答待ちであることを示すと判定された場合、前記第２の通信状態を通知するための第２のメッセージの前記他の通信機器に対する送信を抑止するステップと
を実行させるための通信制御プログラム。
【請求項２】
前記コンピュータに、
前記フラグが前記第１のメッセージに対する応答待ちであることを示すと判定された場合、前記第２のメッセージをメッセージ格納手段に格納するステップと、
前記他の通信機器から前記第１のメッセージに対する応答を受信するステップと、
前記第１のメッセージに対する応答が受信されると、前記メッセージ格納手段に格納された第２のメッセージを前記他の通信機器に送信するステップと
を更に実行させるための請求項１記載の通信制御プログラム。
【請求項３】
前記コンピュータに、
前記第１のメッセージが前記他の通信機器に対して送信された後、予め定められた第１の時間内に前記他の通信機器から当該第１のメッセージに対する応答が受信されない場合、当該第１のメッセージを当該他の通信機器に対して再送するステップと、
前記第１のメッセージが前記他の通信機器に対して再送された後、予め定められた第２の時間内に前記他の通信機器から当該第１のメッセージに対する応答が受信されない場合、前記通信制御装置と前記他の通信機器との間の通信を切断するステップと
を更に実行させるための請求項２記載の通信制御プログラム。
【請求項４】
前記コンピュータに、
前記フラグが前記第１のメッセージ対する応答待ちであることを示すと判定された場合、前記第２のメッセージをメッセージ格納手段に格納するステップと、
前記第２の通信状態が第３の通信状態に変更された場合、前記フラグ格納手段に格納されたフラグが前記第１のメッセージ対する応答待ちであることを示すかを判定するステップと、
前記フラグが前記第１のメッセージに対する応答待ちであることを示すと判定された場合、前記第３の通信状態を通知するための第３のメッセージを前記メッセージ格納手段に格納された第２のメッセージに上書きするステップと、
前記他の通信機器から前記第１のメッセージに対する応答を受信するステップと、
前記第１のメッセージ対する応答が受信されると、前記メッセージ格納手段に格納された第３のメッセージを前記他の通信機器に送信するステップと
を更に実行させるための請求項１記載の通信制御プログラム。
【請求項５】
他の通信機器との通信において当該他の通信機器からのデータを受信可能であるかを含む当該他の通信機器との間の通信状態の変更に応じて当該通信状態を当該他の通信機器に対して通知する通信制御装置において、
前記他の通信機器との間の第１の通信状態を通知するための第１のメッセージを当該他の通信機器に対して送信する送信手段と、
前記第１のメッセージが前記他の通信機器に対して送信されると、当該第１のメッセージに対する応答待ちであることを示すフラグを格納するフラグ格納手段と、
前記第１の通信状態が第２の通信状態に変更された場合、前記フラグ格納手段に格納されたフラグが前記第１のメッセージ対する応答待ちであることを示すかを判定する判定手段と、
前記フラグが前記第１のメッセージ対する応答待ちであることを示すと判定された場合、前記第２の通信状態を通知するための第２のメッセージの前記他の通信機器に対する送信を抑止する抑止手段と
を具備することを特徴とする通信制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、比較的近距離の無線通信を行うための通信制御プログラム及び通信制御装置に関する。
【背景技術】
【０００２】
近年、比較的近距離の無線通信方式として、Ｂｌｕｅｔｏｏｔｈ（登録商標）が知られている。このＢｌｕｅｔｏｏｔｈに対応する機器（Ｂｌｕｅｔｏｏｔｈ対応デバイス）として、例えば携帯電話、ノートパソコン（ノートＰＣ）及びカーナビゲーションシステム等がある。
【０００３】
ここで、例えばカーナビゲーションシステム及び携帯電話のような２つのＢｌｕｅｔｏｏｔｈ対応デバイスがＢｌｕｅｔｏｏｔｈによりデータ送受信の通信を行う場合を想定する。以下、２つのＢｌｕｅｔｏｏｔｈ対応デバイスのうち、一方を自デバイス、他方をリモートデバイスと称する。
【０００４】
このとき、自デバイス及びリモートデバイス間においては、Ｂｌｕｅｔｏｏｔｈにおける機器の種類毎に策定されたプロトコルであるプロファイルのうちの１つである、例えばＳＰＰ（Serial Port Profile）により通信が行われるものとする。このＳＰＰは、Ｂｌｕｅｔｏｏｔｈ対応デバイスを仮想シリアルポート化するためのプロファイルである。
【０００５】
上記したようにＳＰＰによって自デバイスとリモートデバイスとの間で通信が行われる場合、当該自デバイスは、当該リモートデバイスとの通信のネゴシエーションにおいて自身の状態（自デバイスとリモートデバイスとの間の通信状態）をリモートデバイスへ通知する制御を行う。
【０００６】
この制御においては、所定のＲＦＣＯＭＭ（シリアルポートのエミュレーションを行う適合プロトコル）コマンドが発行され、リモートデバイスへ所定のメッセージが送信（通知）される。ＲＦＣＯＭＭコマンドには、例えばＢｌｕｅｔｏｏｔｈ対応デバイス（自デバイス）の状態を通知するためのＭＳＣ（Modem Status Command）が含まれる。
【０００７】
この発行されたＭＳＣを通知するためのメッセージ（ＭＳＣ通知）がリモートデバイスに対して送信されることにより、例えば自デバイスの状態（例えば、リモートデバイスからのデータを受信可能な状態であること）が当該リモートデバイスに対して通知される。
【０００８】
この場合、自デバイスは、リモートデバイスに対して送信されたＭＳＣ通知に対する応答（ＭＳＣ通知応答）を当該リモートデバイスから受け取る。自デバイスにおいてリモートデバイスからのＭＳＣ通知応答が受け取られた後、自デバイス及びリモートデバイス間では実際のデータ送受信等が行われる。
【０００９】
上記したような技術に関連して、例えばＢｌｕｅｔｏｏｔｈを代表とする無線通信を行う場合において、簡単かつ適切な機器間の通信サービスを実施できる技術（以下、先行技術と表記）が開示されている（例えば、特許文献１を参照）。この先行技術によれば、周期的に通信到達範囲を変化させながら周囲にある機器へ問合せメッセージを送信することによって、それに応答した機器の距離関係を知ることができるため、この情報に基づいて例えばできるだけ近い距離にある機器と接続することができ、ユーザにとって自然に簡単に機器間の通信を行うことができる。
【特許文献１】特願２００４−１５６５４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上記したように自デバイスからリモートデバイスに対してＭＳＣ通知が送信された場合、当該リモートデバイスは、当該自デバイスに対して当該ＭＳＣ通知に対する応答を返す。
【００１１】
しかしながら、ＭＳＣ通知が送信されるリモートデバイスの状態または電波の劣悪状況によっては、ＭＳＣ通知に対するリモートデバイスからの応答が自デバイスに返されない（応答が遅れる）場合がある。
【００１２】
自デバイスとリモートデバイスとの通信は、例えば自デバイスにおいてＲＦＣＯＭＭコマンド（ＭＳＣ）が発行されると、以後はベースバンド層間でのネゴシエーションである。このため、例えば自デバイスからのＭＳＣ通知に対する応答がリモートデバイスから返らない場合であっても、当該自デバイスの状態が変更する度にＭＳＣが発行され、リモートデバイスにＭＳＣ通知が送信される。
【００１３】
ここで、例えば自デバイスからＭＳＣ通知（以下、第１のＭＳＣ通知と表記）が送信され、その後、リモートデバイスから第１のＭＳＣ通知に対する応答が自デバイスに返される前に、新たなＭＳＣ通知（以下、第２のＭＳＣ通知と表記）が自デバイスからリモートデバイスに対して送信された場合を想定する。
【００１４】
この場合、リモートデバイスでは第１及び第２のＭＳＣ通知を区別することはできないため、当該リモートデバイスは、自デバイスから後に送信されたＭＳＣ通知（第２のＭＳＣ通知）が先に送信された第１のＭＳＣ通知の再送であると誤認し、当該第１のＭＳＣ通知に対する１つの応答を自デバイスに対して返すことで処理を終了する。
【００１５】
これにより、自デバイスからは第１及び第２のＭＳＣ通知（２つのＭＳＣ通知）がリモートデバイスに対して送信されているのに対し、リモートデバイスからは１つの応答しか返らない状態となる。
【００１６】
このような状態になると、自デバイス及びリモートデバイス間におけるインターオペラビリティが悪くなることが懸念され、結果的に、以後の動作ができなくなる可能性がある。この場合、自デバイス及びリモートデバイスの両者の動作を復帰させ、当該両者間で無線通信を行うためには、当該両者に対して初期化（処理）を行うことが必要となる。
【００１７】
そこで、本発明の目的は、リモートデバイスの状態により当該リモートデバイスから応答が返らない場合であっても初期化の必要がない通信を実行するための通信制御プログラム及び通信制御装置を提供することにある。
【課題を解決するための手段】
【００１８】
本発明の１つの態様によれば、他の通信機器との通信において当該他の通信機器からのデータを受信可能であるかを含む当該他の通信機器との間の通信状態の変更に応じて当該通信状態を当該他の通信機器に対して通知する通信制御装置のコンピュータによって実行される通信制御プログラムであって、前記コンピュータに、前記通信制御装置と前記他の通信機器との間の第１の通信状態を通知するための第１のメッセージを当該他の通信機器に対して送信するステップと、前記第１のメッセージが前記他の通信機器に対して送信されると、当該第１のメッセージに対する応答待ちであることを示すフラグを前記フラグ格納手段に格納するステップと、前記第１の通信状態が第２の通信状態に変更された場合、前記フラグ格納手段に格納されたフラグが前記第１のメッセージ対する応答待ちであることを示すかを判定するステップと、前記フラグが前記第１のメッセージに対する応答待ちであることを示すと判定された場合、前記第２の通信状態を通知するための第２のメッセージの前記他の通信機器に対する送信を抑止するステップとを実行させるための通信制御プログラムが提供される。
【発明の効果】
【００１９】
本発明によれば、リモートデバイスの状態によって当該リモートデバイスから応答が返らない場合であっても初期化の必要がない通信を実行することができる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を参照して、本発明の各実施形態について説明する。
【００２１】
［第１の実施形態］
まず、図１及び図２を参照して、本発明の第１の実施形態について説明する。図１は、本実施形態に係る通信制御装置を含む通信システムについて説明するための図である。
【００２２】
図１に示す通信制御装置１０は、リモートデバイス２０（他の通信機器）と無線通信可能に接続されている。この通信制御装置１０及びリモートデバイス２０間では、比較的近距離の無線通信方式の１つであるＢｌｕｅｔｏｏｔｈ（方式）３０で無線通信が行われる。
【００２３】
つまり、通信制御装置１０及びリモートデバイス２０は、それぞれＢｌｕｅｔｏｏｔｈ３０に対応する機器（Ｂｌｕｅｔｏｏｔｈ対応デバイス）である。このＢｌｕｅｔｏｏｔｈ対応デバイスには、例えば携帯電話、ノートパソコン（ノートＰＣ）及びカーナビゲーションシステム等が含まれる。
【００２４】
通信制御装置１０及びリモートデバイス２０間においては、Ｂｌｕｅｔｏｏｔｈ３０における機器の種類毎に策定されたプロトコルであるプロファイルにより通信が行われる。ここでは、通信制御装置１０及びリモートデバイス２０は、例えばＢｌｕｅｔｏｏｔｈ対応デバイスを仮想シリアルポート化するためのプロファイルであるＳＰＰ（Serial Port Profile）により通信を行うものとする。
【００２５】
例えばＳＰＰによる通信制御装置１０及びリモートデバイス２０間での通信（無線通信）のネゴシエーションにおいて、通信制御装置１０は、自身の状態（通信制御装置１０とリモートデバイス２０との間の通信状態）をリモートデバイス２０に対して通知する制御を行う。
【００２６】
これにより、リモートデバイス２０は、例えば通信制御装置１０が当該リモートデバイス２０からのデータを受信可能な状態であること等を認識することができる。この処理の後に、通信制御装置１０及びリモートデバイス２０間において実際のデータのやり取りが行われる。
【００２７】
図２は、図１に示す通信制御装置１０の主として機能構成の概略を示すブロック図である。
【００２８】
通信制御装置１０は、当該通信制御装置１０の各機能を実現するためのハードウェア構成、またはハードウェアとソフトウェアとの組み合わせ構成として実現されている。ソフトウェアは、予め記憶媒体またはネットワークからインストールされ、通信制御装置１０にその機能を実現させるためのプログラムからなる。
【００２９】
図２に示す通信制御装置１０は、コマンド発行部１１、送受信部１２、制御部１３及びフラグ格納部１４を含む。
【００３０】
上記したように通信制御装置１０及びリモートデバイス２０間においてＳＰＰによる通信が行われる場合には、当該通信制御装置１０とリモートデバイス２０との通信のネゴシエーションにおいて通信制御装置１０の状態をリモートデバイス２０に対して通知する制御が行われる。
【００３１】
コマンド発行部１１は、この制御において、所定のＲＦＣＯＭＭ（シリアルポートのエミュレーションを行う適合プロトコル）コマンドを発行する。このＲＦＣＯＭＭコマンドには、例えばＢｕｌｕｅｔｏｏｔｈ対応デバイス間の通信状態（ここでは、通信制御装置１０とリモートデバイス２０との間の通信状態）を通知するためのＭＳＣ（Modem Status Command）が含まれる。通信制御装置１０とリモートデバイス２０との間の通信状態には、例えば通信制御装置１０がリモートデバイス２０からのデータを受信できる状態にあるか否か（通信制御装置１０の状態）等が含まれる。コマンド発行部１１は、例えば通信制御装置１０の状態が変更される都度、ＭＳＣを発行する。
【００３２】
なお、ＲＦＣＯＭＭコマンドには、ＭＳＣ以外にも、例えば通信相手となるＢｌｕｅｔｏｏｔｈ対応デバイス（ここでは、リモートデバイス２０）のポートの状態を確認するためのＲＰＮ（Remote Port Negotiation）及びリモート・ポートの回線状態を示すＲＬＳ（Remote Line Status）等が含まれる。
【００３３】
送受信部１２は、コマンド発行部１１によって発行されたＭＳＣを通知するための所定のメッセージ（ＭＳＣ通知）をリモートデバイス２０に対して送信（通知）する。また、送受信部１２は、リモートデバイス２０に対して送信されたＭＳＣ通知に対する応答（ＭＳＣ通知応答）を、当該リモートデバイス２０から受信する。
【００３４】
制御部１３は、送受信部１２によってＭＳＣ通知が送信されると、当該ＭＳＣ通知に対する応答待ち（ＭＳＣ通知の送信中）であることを示すフラグをフラグ格納部１４に格納する。制御部１３は、送受信部１２によって送信されたＭＳＣ通知に対する応答がリモートデバイス２０から返される（送受信部１２によって受信される）と、フラグ格納部１４に格納されているフラグを、ＭＳＣ通知に対する応答を受信済みであることを示すフラグに変更する。
【００３５】
また、制御部１３は、例えば通信制御装置１０の状態が変更された場合、つまり、コマンド発行部１１によって新たなＭＳＣ（ＲＦＣＯＭＭコマンド）が発行された場合、フラグ格納部１４に格納されているフラグを確認する。制御部１３は、フラグ格納部１４に格納されているフラグがＭＳＣ通知に対する応答待ちであることを示すフラグである場合、コマンド発行部１１によって発行された新たなＭＳＣを通知するためのＭＳＣ通知のリモートデバイス２０に対する送信を抑止する旨の指示を、送受信部１３に対して出力する。制御部１３は、フラグ格納部１４に格納されているフラグがＭＳＣ通知に対する応答を受信済みであることを示すフラグである場合、コマンド発行部１１によって発行されたＭＳＣを通知するための新たなＭＳＣを通知するためのＭＳＣ通知をリモートデバイス２０に対して送信する旨の指示を、送受信部１３に対して出力する。
【００３６】
図３は、通信制御装置１０に実装されるＢｌｕｅｔｏｏｔｈスタック（以下、ＢＴスタックと表記）の一例を示す。図３に示すように、ＢＴスタックは、物理層（ＲＦ）１０１、ベースバンド（ＢＢ）層１０２、ＨＣＩ（Host Control Interface）１０３、ＲＦＣＯＭＭ（適合プロトコル層）１０４、ＳＰＰ（，ＨＦＰ）１０５及びＡＰＩ（Application Program Interface）１０６を含む。図３に示すように、物理層１０１及びベースバンド層１０２を下位ＢＴスタックと呼び、ＲＦＣＯＭＭ１０４、ＳＰＰ１０５及びＡＰＩを上位ＢＴスタックと呼ぶ。
【００３７】
以下、これら物理層１０１、ベースバンド層１０２、ＨＣＩ１０３、ＲＦＣＯＭＭ１０４、ＳＰＰ１０５及びＡＰＩ１０６をファームウェア（Ｆ／Ｗ）と称する。
【００３８】
また、ＡＰＩ１０６の上位には、アプリケーション層（図示せず）が存在する。以下、このアプリケーション層を含むＡＰＩより上位をＨＯＳＴ（ホスト）と称する。
【００３９】
通信制御装置１０においては、ＨＯＳＴから上記したＭＳＣが発行され、ＡＰＩ１０６、ＳＰＰ１０５、ＲＦＣＯＭＭ１０４、ＨＣＩ１０３、ベースバンド層１０２及び物理層１０１を介してリモートデバイス２０に対してＭＳＣを通知するためのＭＳＣ通知が送信される。このように、ＭＳＣ通知は、Ｆ／Ｗからリモートデバイス２０に対して送信される。
【００４０】
つまり、上記した図２に示すコマンド発行部１１はＨＯＳＴ側で実現される機能であり、送受信部１２及び制御部１３は、Ｆ／Ｗ側で実現される機能である。送受信部１２及び制御部１３は、例えば上位スタックであるＡＰＩ１０６の下位に存在するＢＴ制御ソフトウェア（図示せず）によって実現される。
【００４１】
次に、図４のシーケンスチャートを参照して、本実施形態に係る通信制御装置１０の処理手順について説明する。ここでは、上記したように通信制御装置１０及びリモートデバイス２０がＢｌｕｅｔｏｏｔｈ３０で通信を行う場合について説明する。
【００４２】
なお、図４においては、通信制御装置１０に含まれるコマンド発行部１１の処理についてはＨＯＳＴの処理として示されている。また、通信制御装置１０に含まれる送受信部１２及び制御部１３の処理についてはＦ／Ｗの処理として示されている。
【００４３】
まず、コマンド発行部１１（ＨＯＳＴ）は、例えばＳＰＰによってリモートデバイス２０とＢｌｕｅｔｏｏｔｈ３０で通信が行われる際に、通信制御装置１０の状態（通信制御装置１０及びリモートデバイス２０間の通信状態）を通知するためのＭＳＣ（ＲＦＣＯＭＭコマンド）をＦ／Ｗに対して発行する（ステップＳ１）。
【００４４】
次に、送受信部１２（Ｆ／Ｗ）は、コマンド発行部１１によって発行されたＭＳＣを通知するためのメッセージである第１のＭＳＣ通知（第１のメッセージ）をリモートデバイス２０に対して送信する（ステップＳ２）。
【００４５】
このとき、制御部１３（Ｆ／Ｗ）は、送受信部１２によって第１のＭＳＣ通知がリモートデバイス２０に対して送信されたため、当該リモートデバイス２０からの当該第１のＭＳＣ通知に対する応答待ち（ＭＳＣ通知の送信中）であることを示すフラグを立てる（ステップＳ３）このフラグは、フラグ格納部１４に格納される。
【００４６】
ここで、送受信部１２によって送信された第１のＭＳＣ通知に対する応答がリモートデバイス２０から返されない場合を想定する（ステップＳ４）。この応答がリモートデバイス２０から返されない要因としては、例えば当該リモートデバイス２０の状態または電波の劣悪状況等が挙げられる。
【００４７】
このように送受信部１２によって送信された第１のＭＳＣ通知に対する応答がリモートデバイス２０から返されていない場合において、通信制御装置１０の状態が変更されたものとする。
【００４８】
この場合、コマンド発行部１１は、上記したように通信制御装置１０の状態を通知するための新たなＭＳＣを発行する（ステップＳ５）。
【００４９】
コマンド発行部１１によって新たなＭＳＣが発行されると、制御部１３は、フラグ格納部１４に格納されているフラグを確認する（ステップＳ６）。
【００５０】
これにより、制御部１３は、フラグ格納部１４に格納されているフラグが第１のＭＳＣ通知に対する応答待ちであることを示すか否かを判定する。
【００５１】
フラグが第１のＭＳＣ通知に対する応答待ちであることを示すと判定された場合、制御部１３は、コマンド発行部１１によって発行された新たなＭＳＣを通知するためのメッセージである第２のＭＳＣ通知（第２のメッセージ）の送信を抑止する旨の指示を、送受信部１２に対して出力する。
【００５２】
送受信部１２は、制御部１３から出力された指示に応じて、第２のＭＳＣ通知をリモートデバイス２０に対して送信することを抑止する（ステップＳ７）。
【００５３】
ここで、例えばステップＳ７に示すように第２のＭＳＣ通知の送信を抑止するのではなく、送受信部１２によって当該第２のＭＳＣ通知が送信された場合について説明する。
【００５４】
新たなＭＳＣが発行されると、以降はＢｌｕｅｔｏｏｔｈスタックにおけるベースバンド層間でのネゴシエーションとなる。このため、上記したように第２のＭＳＣ通知が送信された場合には、リモートデバイス２０では上記したステップＳ２において送信された第１のＭＳＣ通及び当該第２のＭＳＣ通知を区別することができない。したがって、リモートデバイス２０は、第２のＭＳＣ通知がステップＳ２において送信された第１のＭＳＣ通知の再送であると誤認する。
【００５５】
この場合、リモートデバイス２０は、第１のＭＳＣ通知に対する１つの応答を通信制御装置１０に返すことで処理を終了する。つまり、通信制御装置１０からは第１及び第２のＭＳＣ通知（２つのＭＳＣ通知）が送信されているにもかかわらず、リモートデバイス２０からは第１のＭＳＣ通知に対する応答（１つのＭＳＣ通知応答）しか返らない状態となる。このような状態になると、通信制御装置１０及びリモートデバイス２０は以後の動作ができなくなる可能性があり、当該通信制御装置１０及びリモートデバイス２０の動作を復帰させるためには両者の初期化が必要となる。
【００５６】
上記したステップＳ７において第２のＭＳＣ通知をリモートデバイス２０に対して送信することを抑止することで、上記したような通信制御装置１０及びリモートデバイス２０の初期化をしなければならないような状況を回避することができる。
【００５７】
第２のＭＳＣ通知の送信が抑止された場合には、制御部１３は、ＨＯＳＴに対して第２のＭＳＣ通知を送信することができない旨のエラー通知を返す（ステップＳ８）。
【００５８】
なお、リモートデバイス２０から例えば第１のＭＳＣ通知に対する応答が返された場合には、制御部１３は、上記した第１のＭＳＣ通知に対する応答待ちであることを示すフラグを、当該第１のＭＳＣ通知に対する応答を受信済みであることを示すフラグに変更する。
【００５９】
また、上記ステップＳ５において第２のＭＳＣが発行された際に、既に第１のＭＳＣ通知に対する応答がリモートデバイス２０から返っており、フラグ格納部１４に格納されているフラグが第１のＭＳＣ通知に対する応答を受信済みであることを示す場合には、上記したステップＳ２と同様にして第２のＭＳＣ通知がリモートデバイス２０に対して送信される。
【００６０】
上記したように本実施形態においては、ＭＳＣが発行され、当該ＭＳＣを通知するためのＭＳＣ通知（第１のＭＳＣ通知）がリモートデバイス２０に対して送信された後であって、当該リモートデバイス２０から当該第１のＭＳＣ通知に対する応答が返される前に、新たなＭＳＣが発行された場合には当該新たなＭＳＣを通知するためのＭＳＣ通知（第２のＭＳＣ通知）はリモートデバイス２０には送信されない。
【００６１】
つまり、本実施形態においては、通信制御装置１０のＨＯＳＴからＲＦＣＯＭＭコマンド（ＭＳＣ）が発行された場合、Ｆ／Ｗ内部でＲＦＣＯＭＭコマンド送信中であるか否かをチェックし、送信中であれば当該コマンドを受け付けず、ＨＯＳＴに対してコマンドエラーが通知される。
【００６２】
これにより、本実施形態においては、第１のＭＳＣ通知に対する応答が返される前に第２のＭＳＣ通知がリモートデバイス２０に送信されることによって、通信制御装置１０及びリモートデバイス２０が動作できなくなることを防止することが可能となる。
【００６３】
したがって、本実施形態においては、上記したようにリモートデバイス２０から第１のＭＳＣ通知に対する応答が返されない（遅れる）場合であっても、通信制御装置１０及びリモートデバイス２０が動作できなくなることがないので、通信制御装置１０及びリモートデバイス２０の動作を復帰させるための初期化処理を行う必要がない通信を実行することができる。
【００６４】
なお、本実施形態においては、通信制御装置１０及びリモートデバイス２０間における無線通信方式としてＢｌｕｅｔｏｏｔｈ方式を適用した場合について説明したが、その他の無線通信方式を適用しても構わない。
【００６５】
［第２の実施形態］
次に、図５を参照して、本発明の第２の実施形態について説明する。図５は、本実施形態に係る通信制御装置の主として機能構成の概略を示すブロック図である。なお、前述した図２と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図２と異なる部分について主に述べる。
【００６６】
図５に示す通信制御装置１００は、当該通信制御装置１００の各機能を実現するためのハードウェア構成、またはハードウェアとソフトウェアとの組み合わせ構成として実現されている。ソフトウェアは、予め記憶媒体またはネットワークからインストールされ、通信制御装置１００にその機能を実現させるためのプログラムからなる。
【００６７】
図５に示すように、通信制御装置１００は、制御部１０１及びメッセージ格納部１０２を含む。
【００６８】
制御部１０１は、前述した制御部１３と同様に、コマンド発行部１１によって新たなＭＳＣが発行された場合、フラグ格納部１４に格納されているフラグを確認する。これにより、制御部１０１は、フラグ格納部１４に格納されているフラグがＭＳＣ通知に対する応答待ちであることを示すフラグである場合、コマンド発行部１１によって発行された新たなＭＳＣを通知するためのＭＳＣ通知をメッセージ格納部１０２に格納する。
【００６９】
制御部１０１は、リモートデバイス２０に対して送信されたＭＳＣ通知に対する応答が送受信部１２によって当該リモートデバイス２０から受信された場合、メッセージ格納部１０２に格納されたＭＳＣ通知を、送受信部１２を介してリモートデバイス２０に対して送信する。
【００７０】
次に、図６のシーケンスチャートを参照して、本実施形態に係る通信制御装置１００の処理手順について説明する。
【００７１】
前述した図４と同様に、図６においては、通信制御装置１００に含まれるコマンド発行部１１の処理についてはＨＯＳＴの処理として示されている。また、通信制御装置１００に含まれる送受信部１２及び制御部１０１の処理についてはＦ／Ｗの処理として示されている。
【００７２】
まず、前述した図４に示すステップＳ１〜ステップＳ６の処理に相当するステップＳ１１〜ステップＳ１６の処理が実行される。なお、ステップＳ１２においてリモートデバイス２０に対して送信されたＭＳＣ通知を第１のＭＳＣ通知（第１のメッセージ）と称する。
【００７３】
フラグ格納部１４に格納されているフラグを確認することにより第１のＭＳＣ通知に対する応答待ちであることを示すと判定された場合、制御部１０１（Ｆ／Ｗ）は、ステップＳ１５においてコマンド発行部１１によって発行された新たなＭＳＣ通知を通知するための第２のＭＳＣ通知（第２のメッセージ）をメッセージ格納部１０２に格納（保存）する（ステップＳ１７）。
【００７４】
ステップＳ１７の処理が実行されると、制御部１０１は、リモートデバイス２０からの第１のＭＳＣ通知に対する応答（第１のＭＳＣ通知応答）が送受信部１２によって受信されるまで待機する。
【００７５】
ここで、リモートデバイス２０からの第１のＭＳＣ通知応答が送受信部１２によって受信された場合を想定する（ステップＳ１８）。
【００７６】
この場合、制御部１０１は、メッセージ格納部１０２に格納されている第２のＭＳＣ通知を取り出す。制御部１０１は、取り出された第２のＭＳＣ通知を、送受信部１２を介してリモートデバイス２０に対して送信する（ステップＳ１９）。
【００７７】
ここでは、１つのＭＳＣ通知（第２のＭＳＣ通知）がメッセージ格納部１０２に格納されるものとして説明したが、例えばリモートデバイス２０からの第１のＭＳＣ通知応答が送受信部１２によって受信されるまでに複数の新たなＭＳＣが発行された場合には、当該複数のＭＳＣを通知するための複数の第２のＭＳＣ通知がメッセージ格納部１０２に格納される。この後に、リモートデバイス２０からの第１のＭＳＣ通知応答が送受信部１２によって受信された場合には、メッセージ格納部１０２に格納されている全ての第２のＭＳＣ通知がリモートデバイス２０に対して送信される。
【００７８】
上記したように本実施形態においては、ＭＳＣが発行され、当該ＭＳＣを通知するためのＭＳＣ通知（第１のＭＳＣ通知）がリモートデバイス２０に対して送信された後であって、当該リモートデバイス２０から当該第１のＭＳＣ通知に対する応答が返される前に、新たなＭＳＣが発行された場合には当該新たなＭＳＣを通知するためのＭＳＣ通知（第２のＭＳＣ通知）がメッセージ格納部１０２に格納される。本実施形態においては、第１のＭＳＣ通知に対する応答がリモートデバイス２０から返された場合には、メッセージ格納部１０２に格納された第２のＭＳＣ通知がリモートデバイス２０に対して送信される。
【００７９】
つまり、本実施形態においては、通信制御装置１００のＨＯＳＴからＲＦＣＯＭＭコマンド（ＭＳＣ）が発行された場合、Ｆ／Ｗ内部でＲＦＣＯＭＭコマンド送信中であるか否かをチェックし、送信中であれば当該コマンドを通知するためのメッセージ（第２のＭＳＣ通知）を保存し、リモートデバイスからの応答受信後に当該保存されたメッセージがリモートデバイス２０に対して送信される。
【００８０】
これにより、本実施形態においては、第１の実施形態における効果に加えて、第１のＭＳＣ通知に対する応答が返される前に発行されたＭＳＣを通知するための第２のＭＳＣ通知を、当該第１のＭＳＣ通知に対する応答がリモートデバイス２０から返された後に当該リモートデバイス２０に対して送信することが可能となる。
【００８１】
［第３の実施形態］
次に、本発明の第３の実施形態について説明する。なお、本実施形態に係る通信制御装置の構成は、前述した第２の実施形態に係る通信制御装置１００の構成と同様であるため、適宜、図５を用いて説明する。
【００８２】
図７のシーケンスチャートを参照して、本実施形態に係る通信制御装置１００の処理手順について説明する。
【００８３】
前述した図４及び図６と同様に、図７においては、通信制御装置１００に含まれるコマンド発行分１１の処理についてはＨＯＳＴの処理として示されている。また、通信制御装置１００に含まれる送受信部１２及び制御に１０１の処理についてはＦ／Ｗの処理として示されている。
【００８４】
まず、前述した図６に示すステップＳ１１〜ステップＳ１７の処理に相当するステップＳ２１〜ステップＳ２７の処理が実行される。なお、ステップＳ２２においてリモートデバイス２０に対して送信されたＭＳＣ通知を第１のＭＳＣ通知（第１のメッセージ）と称する。
【００８５】
次に、第１のＭＳＣ通知に対する応答（第１のＭＳＣ通知応答）が送受信部１２によって受信される（リモートデバイス２０から返される）前に、前述したＭＳＣとは異なるＲＦＣＯＭＭコマンドである例えばＲＰＮがコマンド発行部１１から新たに発行された場合を想定する（ステップＳ２８）。
【００８６】
コマンド発行部１１によってＲＰＮが発行されると、制御部１０１は、フラグ格納部１４に格納されているフラグを確認する（ステップＳ２９）。これにより、制御部１０１は、フラグ格納部１４に格納されているフラグが第１のＭＳＣ通知に対する応答待ちであることを示すか否かを判定する。
【００８７】
フラグが第１のＭＳＣ通知に対する応答待ちであることを示すと判定された場合、制御部１０１は、コマンド発行部１１によって発行されたＲＰＮを通知するためのメッセージであるＲＰＮ通知をメッセージ格納部１０２に格納（保存）する（ステップＳ３０）。このとき、メッセージ格納部１０２には既に第２のＭＳＣ通知が格納されているが、制御部１０１は、各通知を時系列順にメッセージ格納部１０２に格納する。
【００８８】
ステップＳ３０の処理が実行されると、制御部１０３は、リモートデバイス２０からの第１のＭＳＣ通知応答が送受信部１２によって受信されるまで待機する。
【００８９】
第１のＭＳＣ通知応答が送受信部１２によって受信される前に、更にコマンド発行部１１から前述したＭＳＣ及びＲＰＮとは異なるＲＦＣＯＭＭコマンドである例えばＲＬＳが新たに発行された場合を想定する（ステップＳ３１）。
【００９０】
コマンド発行部１１によってＲＬＳが発行されると、制御部１０１は、フラグ格納部１４に格納されているフラグを確認する（ステップＳ３２）。これにより、制御部１０１は、フラグ格納部１４に格納されているフラグが第１のＭＳＣ通知に対する応答待ちであることを示すか否かを判定する。
【００９１】
フラグが第１のＭＳＣ通知に対する応答待ちであることを示すと判定された場合、制御部１０１は、コマンド発行部１１によって発行されたＲＬＳを通知するためのメッセージであるＲＬＳ通知をメッセージ格納部１０２に格納（保存）する（ステップＳ３３）。
【００９２】
ステップＳ３３の処理が実行されると、制御部１０３は、リモートデバイス２０からの第１のＭＳＣ通知応答が送受信部１２によって受信されるまで待機する。
【００９３】
第１のＭＳＣ通知応答が送受信部１２によって受信される前に例えば通信制御装置１００の状態が変更され、更にコマンド発行部１１から新たなＭＳＣが発行された場合を想定する（ステップＳ３４）。
【００９４】
コマンド発行部１１によって新たなＭＳＣが発行されると、制御部１０１は、フラグ格納部１４に格納されているフラグを確認する（ステップＳ３５）。これにより、制御部１０１は、フラグ格納部１４に格納されているフラグが第１のＭＳＣ通知に対する応答待ちであることを示すか否かを判定する。
【００９５】
フラグが第１のＭＳＣ通知に対する応答待ちであることを示すと判定された場合、制御部１０１は、コマンド発行部１１によって発行された新たなＭＳＣを通知するためのメッセージであるＭＳＣ通知（第３のＭＳＣ通知）をメッセージ格納部１０２に格納（保存）する（ステップＳ３６）。このとき、メッセージ格納部１０２には、ステップＳ２７において第２のＭＳＣ通知が、ステップＳ３０においてＲＰＮ通知が、ステップＳ３３においてＲＬＳが既に格納されている。この場合、制御部１０１は、第３のＭＳＣ通知をメッセージ格納部１０２に格納する際に、既にメッセージ格納部１０２に格納されている第２のＭＳＣ通知に当該第３のＭＳＣ通知を上書きする。
【００９６】
つまり、本実施形態においては、メッセージ格納部１０２には、ＲＦＣＯＭＭコマンド（の種類）毎に最新の１メッセージ（通知）分のみが格納される。
【００９７】
ステップＳ３６の処理が実行されると、制御部１０３は、リモートでバース２０からの第１のＭＳＣ通知応答が送受信部１２よって受信されるまで待機する。
【００９８】
ここで、リモートデバイス２０からの第１のＭＳＣ通知応答が送受信部１２によって受信された場合を想定する（ステップＳ３７）。
【００９９】
この場合、制御部１０１は、メッセージ格納部１０２に格納されている各通知（ここでは、ＲＰＮ通知、ＲＬＳ通知及び第３のＭＳＣ通知）を時系列順に取り出す。制御部１０１は、取り出されたＲＰＮ通知、ＲＬＳ通知及び第３のＭＳＣ通知を、送受信部１２を介してリモートデバイス２０に対して送信する。つまり、制御部１０１は、取り出されたＲＰＮ通知、ＲＬＳ通知及び第３のＭＳＣ通知を時系列順に送信する。
【０１００】
上記したように本実施形態においては、例えばＭＳＣ通知の送信中に、新たなＲＦＣＯＭＭコマンドが発行された場合には、当該ＲＦＣＯＭＭコマンドの種類毎に１メッセージ分に限りメッセージ格納部１０２に格納される。本実施形態においては、リモートデバイス２０からＭＳＣ通知応答が返された場合、メッセージ格納部１０２に格納されている各メッセージ（例えば、ＭＳＣ通知、ＲＰＮ通知及びＲＬＳ通知）が当該メッセージ格納部１０２に格納された順（時系列順）にリモートデバイス２０に送信される。
【０１０１】
これにより、第１のＭＳＣ通知応答が送受信部１２によって受信される前に発行されたＲＦＣＯＭＭコマンド（例えば、ＭＳＣ）を通知するためのメッセージを全てメッセージ格納部１０２に格納（保存）する前述した第２の実施形態と比較して、本実施形態においては、当該メッセージ格納部１０２のメモリ領域を必要最小限に抑えることが可能となる。
【０１０２】
［第４の実施形態］
次に、図８を参照して、本発明の第４の実施形態について説明する。図８は、本実施形態に係る通信制御装置の主として機能構成の概略を示すブロック図である。なお、前述した図２及び図５と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図２及び図５と異なる部分について主に述べる。
【０１０３】
図８に示す通信制御装置１１０は、当該通信制御装置１１０の各機能を実現するためのハードウェア構成、またはハードウェアとソフトウェアとの組み合わせ構成として実現されている。ソフトウェアは、予め記憶媒体またはネットワークからインストールされ、通信制御装置１１０にその機能を実現させるためのプログラムからなる。
【０１０４】
図８に示すように、通信制御装置１１０は、タイマ監視部１１１及び制御部１１２を含む。
【０１０５】
タイマ監視部１１１は、送受信部１２によってＭＳＣ通知がリモートデバイス２０に対して送信されると、再送タイマ監視を開始する。タイマ監視部１１１は、送受信部１２によってＭＳＣ通知がリモートデバイス２０に対して送信された後、予め定められた時間（第１の時間）の経過を監視する。
【０１０６】
また、タイマ監視部１１１は、ＭＳＣ通知がリモートデバイス２０に対して再送された後、予め定められた時間（第２の時間）の経過を監視する。
【０１０７】
タイマ監視部１１１は、上記した第１の時間及び第２の時間が経過した場合、その旨を制御部１１２に対して通知する。
【０１０８】
制御部１１２は、タイマ監視部１１１から第１の時間が経過した旨の通知を受けると、既に送受信部１２によってリモートデバイス２０に対して送信されているＭＳＣ通知を、当該送受信部１２を介して再送する。
【０１０９】
また、制御部１１２は、タイマ監視部１１１から第２の時間が経過した旨の通知を受けると、通信制御装置１１０及びリモートデバイス２０間のＢｌｕｅｔｏｏｔｈ３０における通信（ＳＰＰ）を切断する。このとき、メッセージ格納部１０２に例えばＭＳＣ通知が格納されている場合には、制御部１１２は、当該メッセージ格納部１０２に格納されているＭＳＣ通知を全て解放する。
【０１１０】
次に、図９のシーケンスチャートを参照して、本実施形態に係る通信制御装置１１０の処理手順について説明する。なお、本実施形態においては、前述した第１〜第３の実施形態とは異なり、リモートデバイス２０からＭＳＣ通知に対する応答が返らない場合を想定している。
【０１１１】
前述した図４、図６及び図７と同様に、図９においては、通信制御装置１１０に含まれるコマンド発行部１１の処理についてはＨＯＳＴの処理として示されている。また、通信制御装置１１０に含まれる送受信部１２、タイマ監視部１１１及び制御部１１２の処理についてはＦ／Ｗの処理として示されている。
【０１１２】
まず、前述した図４に示すステップＳ１〜ステップＳ３の処理に相当するステップＳ５１〜ステップＳ５３の処理が実行される。なお、ステップＳ５２においてリモートデバイス２０に対して送信されたＭＳＣ通知を第１のＭＳＣ通知（第１のメッセージ）と称する。また、本実施形態においては、ステップＳ５２においてリモートデバイス２０に対して送信された第１のＭＳＣ通知は例えばメッセージ格納部１０２に格納される。
【０１１３】
次に、タイマ監視部１１１は、再送タイマ監視を開始する（ステップＳ５４）。タイマ監視部１１１は、第１のＭＳＣ通知がリモートデバイス２０に対して送信された後、予め定められた第１の時間（例えば、Ｔ秒）の経過を監視する。
【０１１４】
ここで、上記ステップＳ５２において送受信部１２によって送信された第１のＭＳＣ通知に対する応答がリモートデバイス２０から返されず、当該第１のＭＳＣ通知がリモートデバイス２０に送信された後、Ｔ秒が経過した場合を想定する（ステップＳ５５）。
【０１１５】
この場合、タイマ監視部１１１は、第１のＭＳＣ通知が送信された後、Ｔ秒が経過した（つまり、Ｔ秒の間にリモートデバイス２０からの第１のＭＳＣ通知に対する応答が返されていない）旨を制御部１１２に対して通知する。
【０１１６】
制御部１１２は、タイマ監視部１１１からの通知を受けると、リモートデバイス２０に対して第１のＭＳＣ通知の再送を行う（ステップＳ５６）。この第１のＭＳＣ通知の再送は、送受信部１２を介して行われる。なお、第１のＭＳＣ通知は、上記したように例えばメッセージ格納部１０２に格納されている。
【０１１７】
次に、タイマ監視部１１１は、第１のＭＳＣ通知がリモートデバイス２０に対して再送された後、予め定められた第２の時間（例えば、Ｔ´秒）の経過を監視する。
【０１１８】
なお、図９に示すように制御部１１２（送受信部１２）によって再送された第１のＭＳＣ通知に対する応答がリモートデバイス２０から返されないものとする（ステップＳ５７）。
【０１１９】
ここで、第１のＭＳＣ通知がリモートデバイス２０に対して再送された後、Ｔ´秒が経過する前に、通信制御装置１１０の状態を通知するための新たなＭＳＣがコマンド発行部１１によって発行された場合を想定する（ステップＳ５８）。
【０１２０】
この場合、前述した図６に示すステップＳ１６及びステップＳ１７の処理に相当するステップＳ５９及びステップＳ６０の処理が実行される。これにより、コマンド発行部１１によって発行された新たなＭＳＣを通知するためのＭＳＣ通知（第２のＭＳＣ通知）がメッセージ格納部１０２に格納される。
【０１２１】
第１のＭＳＣ通知がリモートデバイス２０に対して再送された後、Ｔ´が経過した（つまり、Ｔ´秒の間にリモートデバイス２０からの第１のＭＳＣ通知に対する応答が返されていない）場合、タイマ監視部１１１は、制御部１１２に対してその旨を通知する。
【０１２２】
制御部１１２は、タイマ監視部１１１からの通知を受けると、通信制御装置１１０及びリモートデバイス２０間の通信（ＳＰＰ）を切断する（ステップＳ６１）。
【０１２３】
制御部１１２は、通信制御装置１１０及びリモートデバイス２０間の通信の切断が完了した場合、メッセージ格納部１０２に格納されている第２のＭＳＣ通知を全て解放する。
【０１２４】
制御部１１２は、通信制御装置１１０のＨＯＳＴに対して、通信制御装置１１０及びリモートデバイス２０間の通信の切断が完了した旨を通知する（ステップＳ６２）。
【０１２５】
上記したように本実施形態においては、リモートデバイス２０からの応答がない場合を想定しており、第１のＭＳＣ通知の送信後、所定時間（第１の時間）が経過した場合には、当該第１のＭＳＣ通知の再送が行われ、当該再送後、所定時間（第２の時間）が経過した場合には、通信制御装置１１０及びリモートデバイス２０間の通信が切断される。
【０１２６】
これにより、前述した第１〜第３の実施形態のようにリモートデバイス２０からのＭＳＣ通知応答が遅れているのではなく当該リモートデバイス２０が当該ＭＳＣ通知応答を返すことができないような状態である場合には、ＭＳＣ通知応答が返されるまで待機するのではなく、通信制御装置１１０及びリモートデバイス２０間の通信を切断することができる。
【０１２７】
なお、通信制御装置１１０及びリモートデバイス２０間の通信を再度行う場合には、例えば通信制御装置１１０のＨＯＳＴが接続要求を発行し、当該要求がリモートデバイス２０に対して送信されることで、当該通信制御装置１１０及びリモートデバイス２０が再度接続される。
【０１２８】
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
【図面の簡単な説明】
【０１２９】
【図１】本発明の第１の実施形態に係る通信制御装置を含む通信システムについて説明するための図。
【図２】図１に示す通信制御装置１０の主として機能構成の概略を示すブロック図。
【図３】通信制御装置１０に実装されるＢｌｕｅｔｏｏｔｈスタックの一例を示す図。
【図４】本実施形態に係る通信制御装置１０の処理手順を示すシーケンスチャート。
【図５】本発明の第２の実施形態に係る通信制御装置の主として機能構成の概略を示すブロック図。
【図６】本実施形態に係る通信制御装置１００の処理手順を示すシーケンスチャート。
【図７】本発明の第３の実施形態に係る通信制御装置１００の処理手順を示すシーケンスチャート。
【図８】本発明の第４の実施形態に係る通信制御装置の主として機能構成の概略を示すブロック図。
【図９】本実施形態に係る通信制御装置１１０の処理手順を示すシーケンスチャート。
【符号の説明】
【０１３０】
１０，１００，１１０…通信制御装置、１１…コマンド発行部、１２…送受信部、１３，１０１，１１２…制御部、１４…フラグ格納部、２０…リモートデバイス、１０２…メッセージ格納部、１１１…タイマ監視部。
【図１】
2010088043.tif 000003
【図２】
2010088043.tif 000004
【図３】
2010088043.tif 000005
【図４】
2010088043.tif 000006
【図５】
2010088043.tif 000007
【図６】
2010088043.tif 000008
【図７】
2010088043.tif 000009
【図８】
2010088043.tif 000010
【図９】
2010088043.tif 000011