ホーム > 特許ランキング > 株式会社デンソーウェーブ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-08-29
(45)【発行日】2022-09-06
(54)【発明の名称】コンピュータプログラム、及び、制御方法
(51)【国際特許分類】
G06F 13/10 20060101AFI20220830BHJP
G06F 13/38 20060101ALI20220830BHJP
G06F 3/00 20060101ALI20220830BHJP
G06F 9/445 20180101ALI20220830BHJP
【ＦＩ】
G06F13/10 330C
G06F13/38 350
G06F3/00 A
G06F13/38 320Z
G06F9/445 120
【請求項の数】
5
(21)【出願番号】P 2018103306
(22)【出願日】2018-05-30
(65)【公開番号】P2019207605
(43)【公開日】2019-12-05
【審査請求日】2021-02-05
(73)【特許権者】
【識別番号】501428545
【氏名又は名称】株式会社デンソーウェーブ
(74)【代理人】
【識別番号】110000110
【氏名又は名称】弁理士法人 快友国際特許事務所
(72)【発明者】
【氏名】三和 剛
【審査官】田名網 忠雄
(56)【参考文献】
【文献】特許第５２８１４０２（ＪＰ，Ｂ１）
【文献】特開２０１２－１７３９５６（ＪＰ，Ａ）
【文献】特開２０１１－０１４１２４（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １３／１０－１３／１４
Ｇ０６Ｆ １３／３８－１３／４２
Ｇ０６Ｆ ３／００
Ｇ０６Ｆ ９／４４５
(57)【特許請求の範囲】
【請求項1】
ＵＳＢ（Universal Serial Busの略）ポートと、コンピュータと、を備えるホスト機器のためのコンピュータプログラムであって、前記コンピュータは、
ＯＳ（Operating Systemの略）と、
ユーザ領域で動作するユーザアプリケーションと、
前記ＯＳの機能の一部を利用することを可能にするためのインターフェースであるＡＰＩ（Application Programming Interfaceの略）と、
カーネル領域で動作するＣＤＣ（Communication Device Classの略）ドライバと、を備え、
前記ＯＳは、
前記ＵＳＢポートに、ＣＤＣクラスのＵＳＢデバイスである周辺装置が接続される場合に、前記ＣＤＣドライバを前記カーネル領域内においてロードすることによって仮想シリアルポートを生成し、
前記ＵＳＢポートと前記周辺装置の接続が解除される場合に、前記ＣＤＣドライバをアンロードすることによって前記仮想シリアルポートを消滅させ、
前記仮想シリアルポートは、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達するために利用される仮想的なポートであり、
前記コンピュータプログラムは、前記ユーザ領域のうち、前記ユーザアプリケーションと前記ＡＰＩとの間で動作するプログラムであって、前記コンピュータに、以下の各処理、即ち、
前記仮想シリアルポートが存在する間に、前記ＣＤＣドライバがアンロードされたことを検知する、アンロード検知処理であって、前記ＣＤＣドライバがアンロードされると、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達不可能な状態が構築され、前記ＣＤＣドライバがアンロードされて、前記仮想シリアルポートが消滅した後に、前記ＡＰＩから受信される異常通知は、前記ユーザアプリケーションに送信されない、前記アンロード検知処理と、
前記アンロード検知処理の後に、前記周辺装置が前記ＵＳＢポートに再接続されることに伴って、前記ＣＤＣドライバが前記カーネル領域内で再ロードされることを検知する、再ロード検知処理と、
前記ＣＤＣドライバの再ロードが検知される場合に、前記仮想シリアルポートが再生成されることに伴って、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達可能な状態を再び構築する、再構築処理と、
を実行させる、
コンピュータプログラム。
【請求項2】
前記アンロード検知処理は、前記ＯＳから、前記ＣＤＣドライバがアンロードされたことに関係する第１のイベント通知を取得することにより、前記ＣＤＣドライバがアンロードされたことを検知することを含み、前記再ロード検知処理は、前記ＯＳから、前記ＣＤＣドライバが再ロードされることに関係する第２のイベント通知を取得することにより、前記ＣＤＣドライバが再ロードされたことを検知することを含む、
請求項１に記載のコンピュータプログラム。
【請求項3】
前記アンロード検知処理は、前記ＯＳから定期的に第１の状態情報を取得し、取得済みの前記第１の状態情報が、前記ＣＤＣドライバがアンロードされたことに関係する状態を示す場合に、前記ＣＤＣドライバがアンロードされたことを検知することを含み、前記再ロード検知処理は、前記ＯＳから定期的に第２の状態情報を取得し、取得済みの前記第２の状態情報が、前記ＣＤＣドライバが再ロードされたことに関係する状態を示す場合に、前記ＣＤＣドライバが再ロードされたことを検知することを含む、
請求項１に記載のコンピュータプログラム。
【請求項4】
前記アンロード検知処理は、前記ＯＳから、前記ＣＤＣドライバがアンロードされたことに関係する第１の割り込み通知を取得することにより、前記ＣＤＣドライバがアンロードされたことを検知することを含み、前記再ロード検知処理は、前記ＯＳから、前記ＣＤＣドライバが再ロードされることに関係する第２の割り込み通知を取得することにより、前記ＣＤＣドライバが再ロードされたことを検知することを含む、
請求項１に記載のコンピュータプログラム。
【請求項5】
ＵＳＢ（Universal Serial Busの略）ポートと、コンピュータと、を備えるホスト機器の制御方法であって、前記コンピュータは、
ＯＳ（Operating Systemの略）と、
ユーザ領域で動作するユーザアプリケーションと、
前記ＯＳの機能の一部を利用することを可能にするためのインターフェースであるＡＰＩ（Application Programming Interfaceの略）と、
カーネル領域で動作するＣＤＣ（Communication Device Classの略）ドライバと、を備え、
前記ＯＳは、
前記ＵＳＢポートに、ＣＤＣクラスのＵＳＢデバイスである周辺装置が接続される場合に、前記ＣＤＣドライバを前記カーネル領域内においてロードすることによって仮想シリアルポートを生成し、
前記ＵＳＢポートと前記周辺装置の接続が解除される場合に、前記ＣＤＣドライバをアンロードすることによって前記仮想シリアルポートを消滅させ、
前記仮想シリアルポートは、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達するために利用される仮想的なポートであり、
前記制御方法は、前記コンピュータが実行する以下の各ステップ、即ち、
前記仮想シリアルポートが存在する間に、前記ＣＤＣドライバがアンロードされたことを検知する、アンロード検知ステップであって、前記ＣＤＣドライバがアンロードされると、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達不可能な状態が構築され、前記ＣＤＣドライバがアンロードされて、前記仮想シリアルポートが消滅した後に、前記ＡＰＩから受信される異常通知は、前記ユーザアプリケーションに送信されない、前記アンロード検知ステップと、
前記アンロード検知ステップの後に、前記周辺装置が前記ＵＳＢポートに再接続されることに伴って、前記ＣＤＣドライバが前記カーネル領域内で再ロードされることを検知する、再ロード検知ステップと、
前記ＣＤＣドライバの再ロードが検知される場合に、前記仮想シリアルポートが再生成されることに伴って、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達可能な状態を再び構築する、再構築ステップと、
を含む、
制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書で開示する技術は、ＵＳＢ（Universal Serial Busの略）ポートと、コンピュータと、を備えるホスト機器のためのコンピュータプログラム、及び、当該ホスト機器の制御方法に関する。
【背景技術】
【0002】
ＵＳＢポートと、コンピュータと、を備えるホスト機器が知られている。そして、このようなホスト機器のＵＳＢポートに、周辺装置（例えば情報コード読取装置）を接続して使用する場合があることも知られている。ホスト機器のコンピュータは、ユーザ領域で動作するユーザアプリケーションと、少なくとも一部がユーザ領域で動作するＡＰＩ（Application Programming Interfaceの略）と、カーネル領域で動作するＣＤＣ（Communication Device Classの略）ドライバと、を備え、ＵＳＢポートに周辺装置が接続される場合に、ＣＤＣドライバをカーネル領域内においてロードすることによって仮想シリアルポートを生成し、ユーザアプリケーションと周辺装置とが仮想シリアルポートを利用して相互に情報を伝達可能な状態を構築する。
【0003】
このようなホスト機器において、仮想シリアルポートが使用されている間に、ＵＳＢポートと周辺装置との接続が解除される場合がある。その場合、ＣＤＣドライバがアンロードされ、それに伴って仮想シリアルポートが消滅し、ユーザアプリケーションと周辺装置とが仮想シリアルポートを利用して相互に情報を伝達することができなくなる。この際、予期せず仮想シリアルポートが消滅することにより、ユーザアプリケーションが正常に動作できなくなる事態が発生する可能性がある。
【0004】
そのため、従来、特許文献１に示すような、ユーザアプリケーションが正常に動作できなくなることを抑制するための特別なＣＤＣドライバが開発されている。特許文献１に開示されているＣＤＣドライバは、ＵＳＢポートに周辺装置が接続される場合に、ＣＯＭポートインターフェース部と、ドライバポート部と、によって構成される機能ドライバを構築する。ＣＯＭポートインターフェース部は、ユーザアプリケーションに対する仮想シリアルポートとして機能し、ドライバポート部は、周辺装置に対するリンクを提供する。特許文献１の技術によると、ＵＳＢポートと周辺装置との接続が解除される場合には、ＣＯＭポートインターフェース部は、ドライバポート部との接続を解除する。ただし、ＣＯＭポートインターフェース部は、ユーザアプリケーションが正常に動作できなくなることを避けるために、ユーザアプリケーションからの伝達情報に対して適切な応答を提供する。その後、周辺装置がＵＳＢポートに再接続される場合に、ＣＯＭポートインターフェース部は、ドライバポート部との接続を再確立させる。
【先行技術文献】
【特許文献】
【0005】
【文献】特許第５２８１４０２号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
特許文献１の技術では、ユーザアプリケーションが正常に動作できなくなることを抑制するためのＣＤＣドライバは、カーネル領域で動作する。カーネル領域で動作するＣＤＣドライバは、ＯＳ（Operating Systemの略）の構成の影響を受けやすく、ＣＤＣドライバを提供する提供者（例えば周辺装置のベンダ等）は、ＯＳの種類、各ＯＳのバージョンに合わせた専用のＣＤＣドライバをその都度準備する必要がある。また、ホスト機器の利用者も、その都度、専用のＣＤＣドライバをコンピュータに記憶させておく必要がある。そのため、ＣＤＣドライバの提供者及びホスト機器の利用者の負担が大きかった。
【0007】
本明細書では、従来に比べて、プログラムの提供者及びホスト機器の利用者の負担を軽減し得る技術を提供する。
【課題を解決するための手段】
【0008】
本明細書は、ＵＳＢ（Universal Serial Busの略）ポートと、コンピュータと、を備えるホスト機器のためのコンピュータプログラムを開示する。前記コンピュータは、ＯＳ（Operating Systemの略）と、ユーザ領域で動作するユーザアプリケーションと、前記ＯＳの機能の一部を利用することを可能にするためのインターフェースであるＡＰＩ（Application Programming Interfaceの略）と、カーネル領域で動作するＣＤＣ（Communication Device Classの略）ドライバと、を備える。前記ＯＳは、前記ＵＳＢポートに、ＣＤＣクラスのＵＳＢデバイスである周辺装置が接続される場合に、前記ＣＤＣドライバを前記カーネル領域内においてロードすることによって仮想シリアルポートを生成し、前記ＵＳＢポートと前記周辺装置の接続が解除される場合に、前記ＣＤＣドライバをアンロードすることによって前記仮想シリアルポートを消滅させる。前記仮想シリアルポートは、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達するために利用される仮想的なポートであって、オープン状態とクローズ状態のうちの一方の状態に設定され、前記オープン状態の間は、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達可能であり、前記クローズ状態の間は、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達不可能である。前記コンピュータプログラムは、前記ユーザ領域のうち、前記ユーザアプリケーションと前記ＡＰＩとの間で動作するプログラムであって、前記コンピュータに、以下の各処理、即ち、前記仮想シリアルポートが前記オープン状態である間に、前記ＣＤＣドライバがアンロードされたことを検知する、アンロード検知処理と、前記ＣＤＣドライバのアンロードが検知される場合に、前記ＡＰＩから受信される異常通知を前記ユーザアプリケーションに送信することなく、前記仮想シリアルポートの状態を前記クローズ状態に設定する、クローズ処理と、前記仮想シリアルポートの状態が前記クローズ状態である間に、前記周辺装置が前記ＵＳＢポートに再接続されることに伴って、前記ＣＤＣドライバが前記カーネル領域内で再ロードされることを検知する、再ロード検知処理と、前記ＣＤＣドライバの再ロードが検知される場合に、前記仮想シリアルポートの状態を前記オープン状態に設定する、再オープン処理と、を実行させる。
【0009】
上記のコンピュータプログラムによると、前記仮想シリアルポートが前記オープン状態である間に、周辺装置とＵＳＢポートとの接続が解除されることに伴って、ユーザアプリケーションが正常に動作しなくなる事態を抑制することができる。また、上記のコンピュータプログラムは、ユーザ領域のうち、ユーザアプリケーションとＡＰＩとの間で動作する。一般的に、ＯＳが更新される場合であっても、ユーザ領域内で動作するユーザアプリケーション及びＡＰＩの仕様が変更されることは少ない。そのため、上記のコンピュータプログラムによると、ユーザアプリケーションが正常に動作できなくなることを抑制するためにカーネル領域で動作する従来のＣＤＣドライバに比べて、ＯＳの更新等に伴って、コンピュータプログラムの提供者（例えば周辺装置のベンダ等）が、当該バージョンのＯＳのための専用のコンピュータプログラムをその都度準備しなければならない可能性は低い。また、ホスト機器の利用者が、その都度、専用のプログラムをコンピュータに記憶させておく必要もない。そのため、上記のコンピュータプログラムによると、従来に比べて、プログラムの提供者及びホスト機器の利用者の負担を軽減し得る。
【0010】
前記アンロード検知処理は、前記ＯＳから、前記ＣＤＣドライバがアンロードされたことに関係する第１のイベント通知を取得することにより、前記ＣＤＣドライバがアンロードされたことを検知することを含んでもよい。前記再ロード検知処理は、前記ＯＳから、前記ＣＤＣドライバが再ロードされることに関係する第２のイベント通知を取得することにより、前記ＣＤＣドライバが再ロードされたことを検知することを含んでもよい。
【0011】
この構成によると、ＣＤＣドライバのアンロード及び再ロードが適切なタイミングで検知され得る。
【0012】
前記アンロード検知処理は、前記ＯＳから定期的に第１の状態情報を取得し、取得済みの前記第１の状態情報が、前記ＣＤＣドライバがアンロードされたことに関係する状態を示す場合に、前記ＣＤＣドライバがアンロードされたことを検知することを含んでもよい。前記再ロード検知処理は、前記ＯＳから定期的に第２の状態情報を取得し、取得済みの前記第２の状態情報が、前記ＣＤＣドライバが再ロードされたことに関係する状態を示す場合に、前記ＣＤＣドライバが再ロードされたことを検知することを含んでもよい。
【0013】
この構成による場合も、ＣＤＣドライバのアンロード及び再ロードが適切なタイミングで検知され得る。
【0014】
前記アンロード検知処理は、前記ＯＳから、前記ＣＤＣドライバがアンロードされたことに関係する第１の割り込み通知を取得することにより、前記ＣＤＣドライバがアンロードされたことを検知することを含んでもよい。前記再ロード検知処理は、前記ＯＳから、前記ＣＤＣドライバが再ロードされることに関係する第２の割り込み通知を取得することにより、前記ＣＤＣドライバが再ロードされたことを検知することを含んでもよい。
【0015】
この構成によると、アンロード検知処理に続く各処理、及び、再ロード検知処理に続く各処理が優先的に実行され得る。
【0016】
また、本明細書は、ＵＳＢ（Universal Serial Busの略）ポートと、コンピュータと、を備えるホスト機器の制御方法も開示する。前記コンピュータは、ＯＳ（Operating Systemの略）と、ユーザ領域で動作するユーザアプリケーションと、前記ＯＳの機能の一部を利用することを可能にするためのインターフェースであるＡＰＩ（Application Programming Interfaceの略）と、カーネル領域で動作するＣＤＣ（Communication Device Classの略）ドライバと、を備える。前記ＯＳは、前記ＵＳＢポートに、ＣＤＣクラスのＵＳＢデバイスである周辺装置が接続される場合に、前記ＣＤＣドライバを前記カーネル領域内においてロードすることによって仮想シリアルポートを生成し、前記ＵＳＢポートと前記周辺装置の接続が解除される場合に、前記ＣＤＣドライバをアンロードすることによって前記仮想シリアルポートを消滅させる。前記仮想シリアルポートは、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達するために利用される仮想的なポートであって、オープン状態とクローズ状態のうちの一方の状態に設定され、前記オープン状態の間は、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達可能であり、前記クローズ状態の間は、前記ユーザアプリケーションと前記周辺装置とが相互に情報を伝達不可能である。前記制御方法は、以下の各ステップ、即ち、前記仮想シリアルポートが前記オープン状態である間に、前記ＣＤＣドライバがアンロードされたことを検知する、アンロード検知ステップと、前記ＣＤＣドライバのアンロードが検知される場合に、前記ＡＰＩから受信される異常通知を前記ユーザアプリケーションに送信することなく、前記仮想シリアルポートの状態を前記クローズ状態に設定する、クローズステップと、前記仮想シリアルポートの状態が前記クローズ状態である間に、前記周辺装置が前記ＵＳＢポートに再接続されることに伴って、前記ＣＤＣドライバが前記カーネル領域内で再ロードされることを検知する、再ロード検知ステップと、前記ＣＤＣドライバの再ロードが検知される場合に、前記仮想シリアルポートの状態を前記オープン状態に設定する、再オープンステップと、を含む。
【0017】
上記の制御方法による場合も、前記仮想シリアルポートが前記オープン状態である間に、周辺装置とＵＳＢポートとの接続が解除されることに伴って、ユーザアプリケーションが正常に動作しなくなる事態を抑制することができる。また、上記の制御方法に含まれる各ステップは、ユーザ領域のうち、ユーザアプリケーションとＡＰＩとの間の情報の伝達に関係するステップである。そのため、ＯＳの更新等に伴って、各ステップの実行手法が変更される可能性が少なく、各ステップの実行手法の更新の負担が軽減され得る。そのため、上記の制御方法によると、従来に比べて、各ステップの実行手法の提供者及びホスト機器の利用者の負担を軽減し得る。
【図面の簡単な説明】
【0018】
【図1】第１実施例の機能実行システム２のブロック図を示す。
【図2】第１実施例のホスト機器１０の状態の遷移を表わす構成図を示す。
【図4】第１、第３実施例において、ホスト機器１０のＣＰＵ２０がミドルウェアプログラム３６に従って実行するポート管理処理のフローチャートを示す。
【図5】ＣＰＵ２０が実行するデータ送信処理のフローチャートを示す。
【図6】ＣＰＵ２０が実行するデータ受信処理のフローチャートを示す。
【図7】比較例のホスト機器の状態の遷移を表わす構成図を示す。
【図9】第２実施例において、ホスト機器１０のＣＰＵ２０がミドルウェアプログラム３６に従って実行するポート管理処理のフローチャートを示す。
【図10】第２実施例において、ＣＰＵ２０が実行する状態移行処理のフローチャートを示す。
【発明を実施するための形態】
【0019】
（第１実施例）
（システムの構成；図１）
図１に示される機能実行システム２は、ホスト機器１０に周辺装置５０を通信可能な態様で接続し、周辺装置５０を利用して所望の機能（例えば情報コードの読み取り機能）を実行するためのシステムである。図１に示されるように、機能実行システム２は、ホスト機器１０と、周辺装置５０と、を備えている。ホスト機器１０と周辺装置５０とはＵＳＢ（Universal Serial Busの略）ケーブル６０を介して相互に通信可能な態様で有線接続されている。
（システムの構成；図１）
図１に示される機能実行システム２は、ホスト機器１０に周辺装置５０を通信可能な態様で接続し、周辺装置５０を利用して所望の機能（例えば情報コードの読み取り機能）を実行するためのシステムである。図１に示されるように、機能実行システム２は、ホスト機器１０と、周辺装置５０と、を備えている。ホスト機器１０と周辺装置５０とはＵＳＢ（Universal Serial Busの略）ケーブル６０を介して相互に通信可能な態様で有線接続されている。
【0020】
（ホスト機器１０の構成）
ホスト機器１０は、デスクトップＰＣ等の据置型の機器であってもよいし、ノートＰＣ、タブレットＰＣ等の可搬型の機器であってもよい。ホスト機器１０は、ＣＰＵ２０と、メモリ３０と、ＵＳＢポート４０と、を備えている。
ホスト機器１０は、デスクトップＰＣ等の据置型の機器であってもよいし、ノートＰＣ、タブレットＰＣ等の可搬型の機器であってもよい。ホスト機器１０は、ＣＰＵ２０と、メモリ３０と、ＵＳＢポート４０と、を備えている。
【0021】
ＣＰＵ２０は、メモリ３０に記憶されている各種プログラム（ＯＳ（Operating Systemの略）プログラム３２、ユーザアプリケーションプログラム３４、ミドルウェアプログラム３６等）に従って、様々な処理を実行する。
【0022】
メモリ３０は、上記の通り、ＯＳプログラム３２、ユーザアプリケーションプログラム３４、及び、ミドルウェアプログラム３６を記憶している。以下では、ユーザアプリケーションプログラム３４、ミドルウェアプログラム３６のことを、それぞれ、「アプリケーション３４」、「ミドルウェア３６」と呼ぶ場合がある。
【0023】
ＯＳプログラム３２は、ホスト機器１０の動作全般を制御するための制御プログラムである。ＯＳプログラム３２は、ホスト機器１０の出荷時点で既にホスト機器１０にインストールされている。以下、本明細書では、ＣＰＵ２０がＯＳプログラム３２に従って処理を実行することを、単にＯＳの動作として説明する場合がある。
【0024】
アプリケーション３４は、周辺装置５０等の各種装置を利用してユーザが所望の機能（例えば情報コードの読み取り）を実行するための制御プログラムである。アプリケーション３４は、当該プログラムのベンダ（例えば、アプリケーションプログラムの開発業者）によって提供されるサーバ（図示省略）からインターネットを介してホスト機器１０にインストールされる。他の例では、アプリケーション３４は、他の方法でホスト機器１０にインストールされてもよい。
【0025】
ミドルウェア３６は、ＣＰＵ２０が、アプリケーション３４に従って周辺装置５０を利用した所望の機能を実行する際に、補助的に機能する制御プログラムである。本実施例のミドルウェア３６が請求項の「コンピュータプログラム」の一例である。ミドルウェア３６は、例えば、周辺装置５０のベンダによって提供されるサーバ（図示省略）からインターネットを介してホスト機器１０にインストールされる。他の例では、ミドルウェア３６は、周辺装置５０と共に出荷されるメディアからホスト機器１０にインストールされてもよい。ＣＰＵ２０がミドルウェア３６に従って実行する処理（図４～図６等参照）については後で詳しく説明する。
【0026】
メモリ３０は、さらに、処理の過程で取得、生成等される各種情報を記憶させるための記憶領域（図示省略）も備えている。
【0027】
ＵＳＢポート４０は、ＵＳＢケーブル６０を接続するためのポートである。ＣＰＵ２０は、ＵＳＢケーブル６０を介して外部装置（例えば周辺装置５０）との間で有線通信を実行することができる。
【0028】
（周辺装置５０の構成）
本実施例の周辺装置５０は、バーコード、二次元コード等の情報コードに記録されているデータを読み取るための情報コード読取装置である。他の例では、周辺装置５０は、プリンタ、スキャナ等、情報コード読取装置以外のホスト機器１０の周辺機器であってもよい。本実施例では、周辺装置５０は、ＵＳＢケーブル６０を介してホスト機器１０のＵＳＢポート４０に接続されることで、周辺装置５０を利用して読み取ったデータをホスト機器１０に出力すること等ができる。
本実施例の周辺装置５０は、バーコード、二次元コード等の情報コードに記録されているデータを読み取るための情報コード読取装置である。他の例では、周辺装置５０は、プリンタ、スキャナ等、情報コード読取装置以外のホスト機器１０の周辺機器であってもよい。本実施例では、周辺装置５０は、ＵＳＢケーブル６０を介してホスト機器１０のＵＳＢポート４０に接続されることで、周辺装置５０を利用して読み取ったデータをホスト機器１０に出力すること等ができる。
【0029】
（本実施例におけるホスト機器１０の状況の遷移；図２、図３）
図２、図３を参照して、本実施例の機能実行システム２において、ホスト機器１０に有線接続されていた周辺装置５０の接続が解除され、再度接続される場合における、ホスト機器１０の状況の遷移を説明する。ここで、図２、図３は、ホスト機器１０にインストールされたＯＳプログラム３２によって管理される各要素の構成および配置を模式的に示している。図２、図３はメモリ空間内の各要素間の情報伝達経路を示す構成図であると理解してもよい。
図２、図３を参照して、本実施例の機能実行システム２において、ホスト機器１０に有線接続されていた周辺装置５０の接続が解除され、再度接続される場合における、ホスト機器１０の状況の遷移を説明する。ここで、図２、図３は、ホスト機器１０にインストールされたＯＳプログラム３２によって管理される各要素の構成および配置を模式的に示している。図２、図３はメモリ空間内の各要素間の情報伝達経路を示す構成図であると理解してもよい。
【0030】
図２、図３に示されるように、ＯＳプログラム３２によって実現されるメモリ空間は、ユーザ領域２００と、カーネル領域３００と、を含む。ユーザ領域２００は、アプリケーション領域とも呼ばれ、ホスト機器１０のユーザが自身で変更可能な領域である。カーネル領域３００は、ＯＳのカーネルが存在する領域である。カーネルとは、コンピュータを構成するハードウェア資源と、アプリケーションソフトウェアとの間のやりとりを中継するためのプログラム部分である。カーネルのことを、ＯＳの中核的部分と理解してもよい。
【0031】
図２の（ａ）に示すように、ユーザ領域２００には、アプリケーション１００と、ミドルウェア１１０と、が含まれる。アプリケーション１００及びミドルウェア１１０は、ユーザ領域２００で動作すると言い換えてもよい。そして、図２の（ａ）に示すように、周辺装置５０とＵＳＢポートとが通信可能な態様で有線接続されている場合には、カーネル領域３００には、仮想シリアルポート１３０と、ＣＤＣ（Communication Device Classの略）ドライバ１４０と、ＵＳＢコントローラ１５０と、ＵＳＢポート４０の一部と、が含まれる。仮想シリアルポート１３０、ＣＤＣドライバ１４０、ＵＳＢコントローラ１５０、及び、ＵＳＢポート４０の一部は、カーネル領域３００で動作すると言い換えてもよい。また、ＡＰＩはＯＳの機能の一部を利用することを可能にするためのインターフェースであり、構成および配置の便宜上、カーネル領域とユーザ領域の境界に位置する。ＵＳＢポートはＵＳＢコントローラと周辺装置を接続するコネクタまたはＨＵＢであり、構成および配置の便宜上、カーネル領域と外部との境界に位置する。
【0032】
アプリケーション１００は、図１のアプリケーション３４に相当するプログラムである。アプリケーション１００は、ユーザ領域２００の最上位の範囲に配置され、この範囲で動作する。
【0033】
ミドルウェア１１０は、図１のミドルウェア３６に相当するプログラムである。ミドルウェア１１０は、ユーザ領域２００のうちのアプリケーション１００とＡＰＩ１２０との間の範囲に配置され、アプリケーション１００とＡＰＩ１２０との間で動作する。
【0034】
ＡＰＩ１２０は、ＯＳが提供するＡＰＩであって、アプリケーション１００、ミドルウェア１１０等の他のプログラムが、ＯＳの機能の一部を利用することを可能にするためのインターフェースである。ＡＰＩ１２０は、一部が、ユーザ領域２００のうちのミドルウェア１１０より下位の範囲に配置され、他の一部が、カーネル領域３００の最上位の範囲に配置される。
【0035】
仮想シリアルポート１３０は、ＯＳによってＣＤＣドライバ１４０がカーネル領域３００内にロードされることに伴って、ＯＳによって生成される仮想的なシリアルポートである。仮想シリアルポート１３０とは、アプリケーション１００と周辺装置５０とが相互に情報を伝達するために利用される仮想的なポートである。仮想シリアルポート１３０は、オープン状態とクローズ状態のうちの一方の状態に設定され、オープン状態の間は、アプリケーション１００と周辺装置５０とが相互に情報を伝達可能な状態を構築し、クローズ状態の間は、アプリケーション１００と周辺装置５０とが相互に情報を伝達不可能な状態を構築する。仮想シリアルポート１３０は、カーネル領域３００のうちのＡＰＩ１２０の下位であってＣＤＣドライバ１４０の上位の範囲に配置され、動作する。
【0036】
ＣＤＣドライバ１４０は、仮想シリアルポート１３０を制御するためのドライバプログラムである。ＣＤＣドライバ１４０は、周辺装置５０とＵＳＢポート４０とが通信可能な態様で有線接続される場合に、ＯＳによってカーネル領域３００内にロードされる。ＣＤＣドライバ１４０は、ＯＳプログラム３２に含まれている。そのため、ＣＤＣドライバ１４０のことを、「ＯＳ標準ＣＤＣドライバ」と呼んでもよい。ＣＤＣドライバ１４０は、カーネル領域３００のうちの仮想シリアルポート１３０の下位であって、ＵＳＢコントローラ１５０の上位の範囲に配置され、動作する。
【0037】
ＵＳＢコントローラ１５０は、ＵＳＢポート４０へのＵＳＢケーブル６０の接続及び非接続の検出、ＵＳＢポート４０との間のデータの伝達等を制御するためのプログラムである。ＵＳＢコントローラ１５０は、カーネル領域３００のうちのＣＤＣドライバ１４０の下位であって、ＵＳＢポート４０の上位の範囲に配置され、動作する。
【0038】
ＵＳＢポート４０は、図１に示すように、ＵＳＢケーブル６０を介して周辺装置５０と有線接続可能なポートである。ＵＳＢポート４０の一部はカーネル領域３００の最下位の範囲に配置され、他の一部は外部（周辺装置）と対する形で配置される。
【0039】
図２の（ａ）に示すように、周辺装置５０とＵＳＢポート４０とが通信可能な態様で有線接続されている場合、カーネル領域３００内にＣＤＣドライバ１４０がロードされ、それに伴ってカーネル領域３００内に仮想シリアルポート１３０が生成されている。そして、ミドルウェア１１０によって、仮想シリアルポート１３０の状態がオープン状態に設定されている。これにより、アプリケーション１００と周辺装置５０とが相互に情報を伝達可能な状態が構築される。そのため、周辺装置５０からアプリケーション１００に情報を伝達させる場合（例えば、アプリケーション１００が、周辺装置５０から情報コードの読み取り結果を受信する場合）、周辺装置５０、ＵＳＢポート４０、ＵＳＢコントローラ１５０、ＣＤＣドライバ１４０、仮想シリアルポート１３０、ＡＰＩ１２０、ミドルウェア１１０、アプリケーション１００、の順に情報を伝達させることが可能になる。反対に、アプリケーション１００から周辺装置５０に情報が伝達される場合には、アプリケーション１００、ミドルウェア１１０、ＡＰＩ１２０、仮想シリアルポート１３０、ＣＤＣドライバ１４０、ＵＳＢコントローラ１５０、ＵＳＢポート４０、周辺装置５０の順に伝達させることが可能になる。即ち、図２の（ａ）の時点では、周辺装置５０とホスト機器１０とが正常に接続されていると言うことができる。
【0040】
この例では、その後、図２の（ｂ）に示すように、周辺装置５０とＵＳＢポート４０との接続が解除される。ここで、「周辺装置５０とＵＳＢポート４０との接続が解除される」ことは、ＵＳＢポート４０と周辺装置５０との接続が物理的に解除される（例えばＵＳＢポート４０からＵＳＢケーブル６０が物理的に引き抜かれる等）ことと、ＵＳＢポート４０と周辺装置５０との接続が電気的に解除される（例えばＵＳＢポート４０とＵＳＢケーブル６０との接続が物理的には解除されていない状態で両者の接続が電気的に解除される等）ことと、の両方を含む。
【0041】
図２の（ｂ）に示すように、周辺装置５０とＵＳＢポート４０との接続が解除されると、ＯＳが、ＵＳＢポート４０から周辺装置５０が離脱したことを検出する。そして、ＯＳは、カーネル領域３００にロードされているＣＤＣドライバ１４０のアンロードを実行する。
【0042】
この結果、図２の（ｃ）に示すように、カーネル領域３００からＣＤＣドライバ１４０がアンロードされる。これに伴い、ＯＳは、カーネル領域３００内に生成されていた仮想シリアルポート１３０を消滅させる。そして、ＯＳは、ＣＤＣドライバ１４０がアンロードされたことを示すアンロード完了通知を、ミドルウェア１１０に対して送信する。アンロード完了通知は、イベント通知である。なお、他の例では、ＯＳは、アンロード完了通知を、ＡＰＩ１２０を介して（即ちＡＰＩ１２０経由で）ミドルウェア１１０に送信するようにしてもよい。
【0043】
ミドルウェア１１０は、アンロード完了通知を受信することにより、ＣＤＣドライバ１４０がアンロードされたことを検知する。ミドルウェア１１０は、ＣＤＣドライバ１４０がアンロードされたことを検知すると、オープン状態に設定していた仮想シリアルポート１３０（即ち、この時点で既に消滅済み）の状態をクローズ状態に移行させる。なお、この時点で仮想シリアルポート１３０は既に消滅しているため、ミドルウェア１１０は、オープン状態に設定していた仮想シリアルポート１３０の状態をクローズ状態に移行させることにより、仮想シリアルポート１３０を利用不可能な状態に切り替える。これにより、アプリケーション１００と周辺装置５０とが相互に情報を伝達不可能な状態が構築される。
【0044】
また、同時に、ＡＰＩ１２０も、ＣＤＣドライバ１４０がアンロードされたことを示すエラーを検出する。ＡＰＩ１２０は、例えば、ＯＳからアンロード完了通知を受けることによって、エラーを検出する。ＡＰＩ１２０がエラーを検出する手法はこれに限られず、任意の手法によってエラーを検出してもよい。例えば、他の例では、ＡＰＩ１２０は、仮想シリアルポート１３０との間で定期的に行っている通信可能状態確認通信が失敗する場合にエラーを検出してもよい。ＡＰＩ１２０は、エラーを検出すると、上位要素であるミドルウェア１１０にエラー通知を送信する。エラー通知は、ＣＤＣドライバ１４０がアンロードされたこと、及び、仮想シリアルポート１３０が消滅したことに関係する情報を含む。
【0045】
この場合、ミドルウェア１１０は、ＡＰＩ１２０からエラー通知を受信するが、上位要素であるアプリケーション１００に対してはエラー通知を送信しない。この結果、アプリケーション１００は、仮想シリアルポート１３０が消滅したことを認識していない状態（即ち、仮想シリアルポート１３０が存在していると認識している状態）を維持する。
【0046】
そのため、アプリケーション１００は、周辺装置５０との間で情報の伝達を行うべき場合、正常時と同様にミドルウェア１１０に情報を伝達する。ただし、この場合、ミドルウェア１１０は、下位のＡＰＩ１２０に情報を伝達せず、アプリケーション１００から受信した情報を、再び周辺装置５０が接続され、仮想シリアルポート１３０が生成されるまで保持する。
【0047】
その後、図３の（ｄ）に示すように、周辺装置５０とＵＳＢポート４０とが再接続されると、ＯＳが、ＵＳＢポート４０に周辺装置５０が再接続されたことを検出する。その場合、ＯＳは、カーネル領域３００において、ＣＤＣドライバ１４０の再ロードを実行する。
【0048】
その結果、図３の（ｅ）に示すように、カーネル領域３００にＣＤＣドライバ１４０が再ロードされる。即ち、カーネル領域３００内にＣＤＣドライバ１４０が読み込まれた状態に移行する。そして、ＯＳは、カーネル領域３００内に仮想シリアルポート１３０を生成する。また、ＯＳは、ＣＤＣドライバ１４０が再ロードされたことを示すロード完了通知を、ミドルウェア１１０に対して送信する。ロード完了通知も、上記のアンロード完了通知と同様にイベント通知である。なお、他の例では、ＯＳは、ロード完了通知を、ＡＰＩ１２０を介して（即ちＡＰＩ１２０経由で）ミドルウェア１１０に送信するようにしてもよい。
【0049】
ミドルウェア１１０は、ロード完了通知を受信することにより、ＣＤＣドライバ１４０が再ロードされたことを検知する。ミドルウェア１１０は、ＣＤＣドライバ１４０が再ロードされたことを検知すると、クローズ状態だった仮想シリアルポート１３０（即ち、この時点では再度生成済み）の状態をオープン状態に移行させる。即ち、ミドルウェア１１０は、クローズ状態に設定していた仮想シリアルポート１３０の状態をオープン状態に移行させることにより、仮想シリアルポート１３０を利用可能な状態に復旧させる。これにより、アプリケーション１００と周辺装置５０とが相互に情報を伝達可能な状態が再び構築される。
【0050】
これに伴い、ＡＰＩ１２０も、ＣＤＣドライバ１４０が再ロードされ、仮想シリアルポート１３０が再生成されたことを検出する。ＡＰＩ１２０は、例えば、ＯＳからロード完了通知を受けることによって、ＣＤＣドライバ１４０の再ロード及び仮想シリアルポート１３０の再生成を検出する。ＡＰＩ１２０がＣＤＣドライバ１４０の再ロード及び仮想シリアルポート１３０の再生成を検出する手法はこれに限られず、任意の手法によってエラーを検出してもよい。例えば、他の例では、ＡＰＩ１２０は、仮想シリアルポート１３０との間で定期的に行っている通信可能状態確認通信が再度成功する場合に、ＣＤＣドライバ１４０の再ロード及び仮想シリアルポート１３０の再生成を検出してもよい。ＡＰＩ１２０は、ＣＤＣドライバ１４０の再ロード及び仮想シリアルポート１３０の再生成を検出すると、上位要素であるミドルウェア１１０に復旧通知を送信する。復旧通知は、ＣＤＣドライバ１４０が再ロードされたこと、及び、仮想シリアルポート１３０が再生成されたことに関係する情報を含む。
【0051】
以上の処理が行われることにより、図２の（ａ）と同様に、周辺装置５０とホスト機器１０とが正常に接続されている状態が復旧される。ミドルウェア１１０は、周辺装置５０の離脱後にアプリケーション１００から受信し、保持していた情報を、ＡＰＩ１２０を介して周辺装置５０に伝達させる。この際、上記のようにミドルウェア１１０が動作したために、アプリケーション１００は、仮想シリアルポート１３０が一度消滅したことを認識することがない。そのため、アプリケーション１００が、周辺装置５０とＵＳＢポート４０との接続が解除されたことによるエラー（即ち仮想シリアルポート１３０が消滅したこと）に伴う異常動作をすることを抑制することができる。また、アプリケーション１００において（即ち、ユーザにおいて）、異常解消のための操作等を行う必要もない。
【0052】
なお、図２の（ｂ）で周辺装置５０が離脱した後、周辺装置５０が再接続されるまでに所定期間（例えば３０秒）以上が経過した場合等には、ミドルウェア１１０はアプリケーション１００にエラー通知を送信する。この場合、アプリケーション１００は仮想シリアルポート１３０が消滅したことを認識する。その場合は、アプリケーション１００は、エラー時の動作を行う。
【0053】
上記の通り、本実施例では、ミドルウェア１１０が動作することにより、仮想シリアルポート１３０がオープン状態である間に、周辺装置５０とＵＳＢポート４０との接続が解除されることに伴って、アプリケーション１００が正常に動作しなくなる事態を抑制することができる。また、アプリケーション１００において（即ち、ユーザにおいて）、異常解消のための操作等を行う必要もない。
【0054】
（ホスト機器１０のＣＰＵ２０が実行するポート管理処理；図４）
次いで、図４を参照して、ＣＰＵ２０がミドルウェア３６（１１０）（図１、図２及び図３参照）に従って実行するポート管理処理の内容を説明する。ここで、図４の各ステップは、非同期的に行われ得ることに留意すべきである。例えば、後で説明するＳ２２やＳ２３等の処理が実行されている間に、Ｓ５０やＳ６０でＹＥＳと判断されるべき状況は発生し得る。
次いで、図４を参照して、ＣＰＵ２０がミドルウェア３６（１１０）（図１、図２及び図３参照）に従って実行するポート管理処理の内容を説明する。ここで、図４の各ステップは、非同期的に行われ得ることに留意すべきである。例えば、後で説明するＳ２２やＳ２３等の処理が実行されている間に、Ｓ５０やＳ６０でＹＥＳと判断されるべき状況は発生し得る。
【0055】
ホスト機器１０が起動されると、ＣＰＵ２０は、ミドルウェア３６（１１０）に従って、Ｓ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視を開始する。
【0056】
Ｓ１０では、ＣＰＵ２０は、アプリケーション１００からオープン指示を受信することを監視する。オープン指示は、カーネル領域３００に生成されている仮想シリアルポート１３０の状態をオープン状態（即ち、アプリケーション１００と周辺装置５０が相互に情報を伝達可能な状態）に移行させることをミドルウェア１１０に要求するための指示である。アプリケーション１００は、周辺装置５０との間で通信（周辺装置５０へのデータの送信、又は、周辺装置５０からのデータの受信）を開始すべき場合に、通信開始に先立って、ミドルウェア１１０にオープン指示を送信する。即ち、オープン指示は、通信開始指示であると理解してもよい。ＣＰＵ２０は、アプリケーション１００からオープン指示を受信すると、Ｓ１０でＹＥＳと判断し、Ｓ１２に進む。
【0057】
Ｓ１２では、ＣＰＵ２０は、周辺装置５０が接続中であるか否かを判断する。ＣＰＵ２０は、ＵＳＢポート４０の状態を参照し、周辺装置５０が有線接続されているか否かを判断する。Ｓ１２の時点で、周辺装置５０がＵＳＢポート４０に接続されていると判断される場合、ＣＰＵ２０は、Ｓ１２でＹＥＳと判断し、Ｓ１４に進む。Ｓ１２でＹＥＳの場合、ＯＳによってカーネル領域３００内にＣＤＣドライバ１４０がロードされ、カーネル領域３００内に仮想シリアルポート１３０が生成されていることを意味する。
【0058】
Ｓ１４では、ＣＰＵ２０は、カーネル領域３００に生成されている仮想シリアルポート１３０の状態をオープン状態に移行する。
【0059】
続くＳ１８では、ＣＰＵ２０は、周辺装置接続状態を確立する。周辺装置接続状態とは、アプリケーション１００と周辺装置５０とが、仮想シリアルポート１３０を介して相互に情報を伝達可能な状態である。Ｓ１８を終えると、ＣＰＵ２０は、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0060】
一方、Ｓ１２の時点において、周辺装置５０がＵＳＢポート４０に接続されていないと判断される場合、ＣＰＵ２０は、Ｓ１２でＮＯと判断し、Ｓ１６に進む。Ｓ１２でＮＯの場合、カーネル領域３００内にＣＤＣドライバ１４０がロードされておらず、カーネル領域３００内に仮想シリアルポート１３０が生成されていないことを意味する。その場合、Ｓ１６では、ＣＰＵ２０は、所定のエラー処理を行う。Ｓ１６を終えると、ＣＰＵ２０は、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0061】
Ｓ２０では、ＣＰＵ２０は、アプリケーション１００からデータ送信リクエストを受信することを監視する。データ送信リクエストは、アプリケーション１００が周辺装置５０へのデータの送信を開始することを通知するための信号である。アプリケーション１００は、周辺装置５０にデータを送信すべき場合に、データの送信開始に先立ってミドルウェア１１０にデータ送信リクエストを送信する。アプリケーション１００は、上述のオープン指示をミドルウェア１１０に送信した後で、データ送信リクエストをミドルウェア１１０に送信する。ＣＰＵ２０は、アプリケーション１００からデータ送信リクエストを受信すると、Ｓ２０でＹＥＳと判断し、Ｓ２２に進む。
【0062】
Ｓ２２では、ＣＰＵ２０は、データ送信処理（図５参照）を開始する。データ送信処理の内容は、図５を参照して後で詳しく説明する。ＣＰＵ２０は、Ｓ２２でデータ送信処理を開始すると、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0063】
Ｓ３０では、ＣＰＵ２０は、アプリケーション１００からデータ受信リクエストを受信することを監視する。データ受信リクエストは、アプリケーション１００が周辺装置５０からのデータの受信を開始することを通知するための信号である。アプリケーション１００は、周辺装置５０からデータを受信すべき場合に、データの受信開始に先立ってミドルウェア１１０にデータ受信リクエストを送信する。アプリケーション１００は、上述のオープン指示をミドルウェア１１０に送信した後で、データ受信リクエストをミドルウェア１１０に送信する。ＣＰＵ２０は、アプリケーション１００からデータ受信リクエストを受信すると、Ｓ３０でＹＥＳと判断し、Ｓ３２に進む。
【0064】
Ｓ３２では、ＣＰＵ２０は、データ受信処理（図６参照）を開始する。データ受信処理の内容は、図６を参照して後で詳しく説明する。ＣＰＵ２０は、Ｓ３２でデータ送信処理を開始すると、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0065】
Ｓ４０では、ＣＰＵ２０は、アプリケーション１００からクローズ指示を受信することを監視する。クローズ指示は、カーネル領域３００に生成されている仮想シリアルポート１３０の状態をクローズ状態（即ち、アプリケーション１００と周辺装置５０が相互に情報を伝達不可能な状態）に移行させることをミドルウェア１１０に要求するための指示である。アプリケーション１００は、周辺装置５０との間での通信（周辺装置５０へのデータの送信、又は、周辺装置５０からのデータの受信）を完了した場合に、ミドルウェア１１０にクローズ指示を送信する。即ち、クローズ指示は、通信終了指示であると理解してもよい。ＣＰＵ２０は、アプリケーション１００からクローズ指示を受信すると、Ｓ４０でＹＥＳと判断し、Ｓ４２に進む。
【0066】
Ｓ４２では、ＣＰＵ２０は、カーネル領域３００に生成されている仮想シリアルポート１３０の状態をクローズ状態に移行する。Ｓ４２を終えると、ＣＰＵ２０は、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0067】
Ｓ５０では、ＣＰＵ２０は、ＯＳからロード完了通知を受信することを監視する。上記の通り、ロード完了通知は、ＣＤＣドライバ１４０が再ロードされたことを示す通知である。上記の通り、ＯＳは、周辺装置５０とＵＳＢポート４０との接続が解除されることに伴って一旦アンロードされたＣＤＣドライバ１４０が再ロードされると、ミドルウェア１１０に対してロード完了通知を送信する。ＣＰＵ２０は、ＯＳからロード完了通知を受信すると、Ｓ５０でＹＥＳと判断し、Ｓ５２に進む。
【0068】
Ｓ５２では、ＣＰＵ２０は、この時点でカーネル領域３００に生成されている仮想シリアルポート１３０の状態をオープン状態に移行する。
【0069】
次いで、Ｓ５４では、ＣＰＵ２０は、周辺装置接続状態を確立する。Ｓ５４を終えると、ＣＰＵ２０は、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0070】
Ｓ６０では、ＣＰＵ２０は、ＯＳからアンロード完了通知を受信することを監視する。上記の通り、アンロード完了通知は、ＣＤＣドライバ１４０がアンロードされたことを示す通知である。上記の通り、ＯＳは、周辺装置５０とＵＳＢポート４０との接続が解除されることに伴って、ＣＤＣドライバ１４０をアンロードすると、ミドルウェア１１０に対してアンロード完了通知を送信する。ＣＰＵ２０は、ＯＳからアンロード完了通知を受信すると、Ｓ６０でＹＥＳと判断し、Ｓ６２に進む。
【0071】
Ｓ６２では、ＣＰＵ２０は、この時点で仮想シリアルポート１３０の状態がオープン状態であるか否かを判断する。仮想シリアルポート１３０が既に消滅済みか否かに関わらず、Ｓ６２の時点で仮想シリアルポート１３０がオープン状態に設定されている場合、ＣＰＵ２０は、Ｓ６２でＹＥＳと判断し、Ｓ６４に進む。Ｓ６４では、ＣＰＵ２０は、仮想シリアルポート１３０（即ち、この時点で既に消滅済み）の状態をクローズ状態に移行させる。Ｓ６４を終えると、ＣＰＵ２０は、Ｓ６６に進む。一方、Ｓ６２の時点で仮想シリアルポート１３０が既にクローズ状態に設定されている場合、ＣＰＵ２０は、Ｓ６２でＮＯと判断し、Ｓ６４をスキップしてＳ６６に進む。
【0072】
Ｓ６６では、ＣＰＵ２０は、周辺装置離脱状態を確立する。周辺装置離脱状態とは、周辺装置５０とＵＳＢポート４０との接続が解除されており、アプリケーション１００と周辺装置５０とが、仮想シリアルポート１３０を介して相互に情報を伝達不可能な状態である。Ｓ６６を終えると、ＣＰＵ２０は、再びＳ１０，Ｓ２０，Ｓ３０，Ｓ４０，Ｓ５０，Ｓ６０の各監視に戻る。
【0073】
【0074】
（データ送信処理；図５）
次いで、図５を参照して、図４のＳ２２においてＣＰＵ２０が開始するデータ送信処理の内容を説明する。図５のデータ送信処理は、図４のポート管理処理と並行して実行される。データ送信処理が開始されると（図４のＳ２２）、図５のＳ７２において、離脱確認タイマのカウントを開始する。ここで、「離脱確認タイマ」とは、ＵＳＢポート４０と周辺装置５０との状態が周辺装置離脱状態である場合に、周辺装置５０がＵＳＢポート４０から完全に離脱した状態（即ち、一時的な離脱ではない状態）であると判断するために必要な所定期間をカウントするタイマである。本実施例では、後で説明するように、離脱確認タイマのカウントを開始してから所定期間を経過した時点で、周辺装置離脱状態が継続している場合、ＣＰＵ２０は、周辺装置５０がＵＳＢポート４０から完全に離脱した状態であると判断する。反対に、離脱確認タイマのカウントを開始してから所定期間を経過した時点で、周辺装置接続状態であれば、仮に、タイマのカウント開始から所定期間が経過するまでの間に周辺装置離脱状態であった期間が一部に存在したとしても、その離脱状態は、周辺装置５０がＵＳＢポート４０から一時的に離脱したことによる離脱状態に過ぎない、と判断することができる。
次いで、図５を参照して、図４のＳ２２においてＣＰＵ２０が開始するデータ送信処理の内容を説明する。図５のデータ送信処理は、図４のポート管理処理と並行して実行される。データ送信処理が開始されると（図４のＳ２２）、図５のＳ７２において、離脱確認タイマのカウントを開始する。ここで、「離脱確認タイマ」とは、ＵＳＢポート４０と周辺装置５０との状態が周辺装置離脱状態である場合に、周辺装置５０がＵＳＢポート４０から完全に離脱した状態（即ち、一時的な離脱ではない状態）であると判断するために必要な所定期間をカウントするタイマである。本実施例では、後で説明するように、離脱確認タイマのカウントを開始してから所定期間を経過した時点で、周辺装置離脱状態が継続している場合、ＣＰＵ２０は、周辺装置５０がＵＳＢポート４０から完全に離脱した状態であると判断する。反対に、離脱確認タイマのカウントを開始してから所定期間を経過した時点で、周辺装置接続状態であれば、仮に、タイマのカウント開始から所定期間が経過するまでの間に周辺装置離脱状態であった期間が一部に存在したとしても、その離脱状態は、周辺装置５０がＵＳＢポート４０から一時的に離脱したことによる離脱状態に過ぎない、と判断することができる。
【0075】
続くＳ７４では、ＣＰＵ２０は、アプリケーション１００から受信されたデータ（即ち、周辺装置５０に送信されるべきデータ）の送信を開始する。具体的には、Ｓ７４では、ＣＰＵ２０は、ミドルウェア１１０の下位要素であるＡＰＩ１２０に対してデータの送信を開始する。
【0076】
続くＳ７６では、ＣＰＵ２０は、データの送信が成功したか否かを判断する。この時点で、送信すべきデータの送信が完了している場合、ＣＰＵ２０は、Ｓ７６でＹＥＳと判断し、図５のデータ送信処理を終了（正常終了）する。一方、この時点で、送信すべきデータの送信が未完了である場合、ＣＰＵ２０は、Ｓ７６でＮＯと判断し、Ｓ７７に進む。
【0077】
Ｓ７７では、ＣＰＵ２０は、この時点における周辺装置５０とＵＳＢポート４０との状態が、上記の「周辺装置離脱状態」であるか否かを判断する。ＣＰＵ２０は、ＵＳＢポート４０、及び、カーネル領域３００の状態を確認し、周辺装置５０とＵＳＢポート４０との接続状態が周辺装置離脱状態であるか否かを判断する。この時点において、周辺装置５０とＵＳＢポート４０との間の状態が周辺装置離脱状態である場合、ＣＰＵ２０は、Ｓ７７でＹＥＳと判断し、Ｓ７８に進む。一方、この時点において、周辺装置５０とＵＳＢポート４０との間の状態が周辺装置接続状態である場合、ＣＰＵ２０は、Ｓ７７でＮＯと判断し、図５のデータ送信処理をエラー終了する。Ｓ７７でＮＯと判断される場合は、周辺装置５０とＵＳＢポート４０との間の状態が周辺装置接続状態であるにもかかわらず、データの送信が成功しない場合であり、何らかのエラーが発生している可能性が高いと言える。
【0078】
Ｓ７８では、ＣＰＵ２０は、Ｓ７２で離脱確認タイマのカウントを開始してから、所定期間（タイムアウト期間。例えば３０秒間）が経過したか否かを判断する。この時点で、所定期間が未経過の場合、ＣＰＵ２０は、Ｓ７８でＮＯと判断し、Ｓ８０に進む。即ち、Ｓ７８でＮＯと判断される場合、周辺装置離脱状態は発生しているがまだ所定期間が未経過であり、その後、周辺装置接続状態に復帰する可能性もあるため、ＣＰＵ２０は、所定期間が経過するまではエラー終了を待つ、という処理を行うことになる。一方、この時点で、所定期間が既に経過している場合、ＣＰＵ２０は、Ｓ７８でＹＥＳと判断し、図５のデータ送信処理をエラー終了する。即ち、Ｓ７８でＮＯと判断される場合は、周辺装置離脱状態が発生し、所定期間も経過したため、ＣＰＵ２０は、周辺装置５０がＵＳＢポート４０から完全に離脱した状態（即ち、一時的な離脱ではない状態）であると判断し、図５のデータ送信処理をエラー終了する。
【0079】
Ｓ８０では、ＣＰＵ２０は、アプリケーション１００から受信されたデータ（即ち、周辺装置５０に送信されるべきデータ）の再送信を開始する。Ｓ８０で再送信を開始すると、続いて、ＣＰＵ２０は再びＳ７６の判断を行う。
【0080】
このように、ＣＰＵ２０は、図５の処理が正常終了（Ｓ７６でＹＥＳ）するか、エラー終了（Ｓ７７でＮＯ、又はＳ７８でＹＥＳ）するまで、Ｓ７６～Ｓ８０の処理を繰り返し実行する。
【0081】
（データ受信処理；図６）
次いで、図６を参照して、図４のＳ３２においてＣＰＵ２０が開始するデータ受信処理の内容を説明する。図６のデータ受信処理も、図４のポート管理処理と並行して実行される。データ受信処理が開始されると（図４のＳ３２）、図５のＳ９２において、離脱確認タイマのカウントを開始する。離脱確認タイマについては、上述の通りである。
次いで、図６を参照して、図４のＳ３２においてＣＰＵ２０が開始するデータ受信処理の内容を説明する。図６のデータ受信処理も、図４のポート管理処理と並行して実行される。データ受信処理が開始されると（図４のＳ３２）、図５のＳ９２において、離脱確認タイマのカウントを開始する。離脱確認タイマについては、上述の通りである。
【0082】
続くＳ９４では、ＣＰＵ２０は、アプリケーション１００によるデータの受信を開始する。具体的に言うと、Ｓ９４では、ＣＰＵ２０は、アプリケーション１００が受信すべきデータ（即ち、周辺装置５０からＡＰＩ１２０を経由してミドルウェア１１０に伝達されたデータ）のアプリケーション１００への送信を開始する。
【0083】
続くＳ９６では、ＣＰＵ２０は、アプリケーション１００によるデータの受信（即ち、アプリケーション１００へのデータの送信）が成功したか否かを判断する。この時点で、アプリケーション１００によるデータの受信が完了している場合、ＣＰＵ２０は、Ｓ９６でＹＥＳと判断し、図６のデータ受信処理を終了（正常終了）する。一方、この時点で、アプリケーション１００によるデータの受信が未完了である場合、ＣＰＵ２０は、Ｓ９６でＮＯと判断し、Ｓ９７に進む。
【0084】
Ｓ９７では、ＣＰＵ２０は、この時点における周辺装置５０とＵＳＢポート４０との状態が、上記の「周辺装置離脱状態」であるか否かを判断する。ＣＰＵ２０は、ＵＳＢポート４０、及び、カーネル領域３００の状態を確認し、周辺装置５０とＵＳＢポート４０との接続状態が周辺装置離脱状態であるか否かを判断する。この時点において、周辺装置５０とＵＳＢポート４０との間の状態が周辺装置離脱状態である場合、ＣＰＵ２０は、Ｓ９７でＹＥＳと判断し、Ｓ９８に進む。一方、この時点において、周辺装置５０とＵＳＢポート４０との間の状態が周辺装置接続状態である場合、ＣＰＵ２０は、Ｓ９７でＮＯと判断し、図６のデータ受信処理をエラー終了する。Ｓ９７でＮＯと判断される場合は、周辺装置５０とＵＳＢポート４０との間の状態が周辺装置接続状態であるにもかかわらず、アプリケーション１００によるデータの受信が成功しない場合であり、何らかのエラーが発生している可能性が高いと言える。
【0085】
Ｓ９８では、ＣＰＵ２０は、Ｓ９２で離脱確認タイマのカウントを開始してから、所定の期間（タイムアウト期間。例えば３０秒間）が経過したか否かを判断する。この時点で、所定期間が未経過の場合、ＣＰＵ２０は、Ｓ９８でＮＯと判断し、Ｓ１００に進む。即ち、Ｓ９８でＮＯと判断される場合、周辺装置離脱状態は発生しているがまだ所定期間が未経過であり、その後、周辺装置接続状態に復帰する可能性もあるため、ＣＰＵ２０は、所定期間が経過するまではエラー終了を待つ、という処理を行うことになる。一方、この時点で、所定期間が既に経過している場合、ＣＰＵ２０は、Ｓ９８でＹＥＳと判断し、図６のデータ受信処理をエラー終了する。即ち、Ｓ９８でＮＯと判断される場合は、周辺装置離脱状態が発生し、所定期間も経過したため、ＣＰＵ２０は、周辺装置５０がＵＳＢポート４０から完全に離脱した状態（即ち、一時的な離脱ではない状態）であると判断し、図６のデータ受信処理をエラー終了する。
【0086】
Ｓ１００では、ＣＰＵ２０は、アプリケーション１００が受信すべきデータ（即ち、周辺装置５０からＡＰＩ１２０を経由してミドルウェア１１０に伝達されたデータ）の再送信を開始する。Ｓ１００で再送信を開始すると、続いて、ＣＰＵ２０は再びＳ９６の判断を行う。
【0087】
このように、ＣＰＵ２０は、図６の処理が正常終了（Ｓ９６でＹＥＳ）するか、エラー終了（Ｓ９７でＮＯ、又はＳ９８でＹＥＳ）するまで、Ｓ９６～Ｓ１００の処理を繰り返し実行する。
【0088】
以上、本実施例の機能実行システム２の構成、及び、ホスト機器１０の動作について詳しく説明した。
【0089】
（比較例；図７、図８）
本実施例のホスト機器１０の利点を明確に説明するために、図７、図８を参照して、本実施例のミドルウェア３６（１１０）が存在しない場合のホスト機器１０の動作を想定した比較例を説明する。図７、図８に示すように、比較例では、アプリケーション１００とＡＰＩ１２０との間にミドルウェア１１０（図２、図３参照）が存在しない点が本実施例とは異なる。
本実施例のホスト機器１０の利点を明確に説明するために、図７、図８を参照して、本実施例のミドルウェア３６（１１０）が存在しない場合のホスト機器１０の動作を想定した比較例を説明する。図７、図８に示すように、比較例では、アプリケーション１００とＡＰＩ１２０との間にミドルウェア１１０（図２、図３参照）が存在しない点が本実施例とは異なる。
【0090】
図７の（ａ）に示すように、周辺装置５０とホスト機器１０とが正常に接続されている場合においては、アプリケーション１００が、仮想シリアルポート１３０の状態をオープン状態に設定することにより、アプリケーション１００と周辺装置５０とが相互に情報を伝達可能な状態が構築されている。
【0091】
その後、図７の（ｂ）に示すように、周辺装置５０とＵＳＢポート４０との接続が解除されると、ＯＳが、ＵＳＢポート４０の状態に基づいて、ＵＳＢポート４０から周辺装置５０が離脱したことを検出する。そして、ＯＳは、カーネル領域３００にロードされているＣＤＣドライバ１４０のアンロードを実行する。
【0092】
その結果、図７の（ｃ）に示すように、カーネル領域３００からＣＤＣドライバ１４０がアンロードされ、カーネル領域３００内に生成されていた仮想シリアルポート１３０が消滅する。この場合、ＡＰＩ１２０も、例えば、ＯＳからアンロード完了通知を受けることによって、ＣＤＣドライバ１４０がアンロードされたことを示すエラーを検出する。ＡＰＩ１２０は、ＡＰＩ１２０は、エラーを検出すると、上位要素であるアプリケーション１００にエラー通知を送信する。これにより、アプリケーション１００は、異常が発生したことを認識する。
【0093】
この比較例では、その後、図８の（ｄ）に示すように、周辺装置５０とＵＳＢポート４０とが再接続されると、図８の（ｅ）に示すように、カーネル領域３００にＣＤＣドライバ１４０が再ロードされる。そして、ＯＳは、カーネル領域３００内に仮想シリアルポート１３０を生成する。ただし、比較例では、この時点では、アプリケーション１００は、異常発生を認識した状態（エラー状態）が解除されていない。エラー状態の解消のためには、ユーザが、アプリケーション１００を再起動させ、アプリケーション１００を操作して仮想シリアルポート１３０を再度オープン状態に設定する等、所定のエラー解消操作を行わなければならない。
【0094】
（本実施例の効果）
上記の比較例に対し、本実施例では、ＣＰＵ２０は、データ送信処理（図５参照）及びデータ受信処理（図６参照）が開始された際に、仮想シリアルポート１３０がオープン状態でなくなった場合（図５のＳ７０でＮＯ、図６のＳ９０でＮＯ）に、仮想シリアルポート１３０が再びオープン状態に戻る（即ち、図４のＳ５２が実行される）まで、Ｓ７０及びＳ９０の判断を繰り返し実行する。そして、ＣＰＵ２０は、この間にＡＰＩ１２０からエラー通知を受信した場合であっても、仮想シリアルポート１３０が再びオープン状態に戻る（即ち、図４のＳ５２が実行される）まで、エラー通知をアプリケーション１００に送信することなく、仮想シリアルポート１３０をクローズ状態に設定したまま、Ｓ７０及びＳ９０の判断を繰り返し実行する（図２の（ｃ）参照）。これにより、アプリケーション１００は、ＵＳＢポート４０と周辺装置５０との接続が解除されたことに伴って、仮想シリアルポート１３０が一度消滅したことを認識しない。そのため、アプリケーション１００がエラー（即ち仮想シリアルポート１３０が消滅したこと）に伴う異常動作をすることを抑制することができる。また、アプリケーション１００において（即ち、ユーザにおいて）、異常解消のための操作等を行う必要もない。
上記の比較例に対し、本実施例では、ＣＰＵ２０は、データ送信処理（図５参照）及びデータ受信処理（図６参照）が開始された際に、仮想シリアルポート１３０がオープン状態でなくなった場合（図５のＳ７０でＮＯ、図６のＳ９０でＮＯ）に、仮想シリアルポート１３０が再びオープン状態に戻る（即ち、図４のＳ５２が実行される）まで、Ｓ７０及びＳ９０の判断を繰り返し実行する。そして、ＣＰＵ２０は、この間にＡＰＩ１２０からエラー通知を受信した場合であっても、仮想シリアルポート１３０が再びオープン状態に戻る（即ち、図４のＳ５２が実行される）まで、エラー通知をアプリケーション１００に送信することなく、仮想シリアルポート１３０をクローズ状態に設定したまま、Ｓ７０及びＳ９０の判断を繰り返し実行する（図２の（ｃ）参照）。これにより、アプリケーション１００は、ＵＳＢポート４０と周辺装置５０との接続が解除されたことに伴って、仮想シリアルポート１３０が一度消滅したことを認識しない。そのため、アプリケーション１００がエラー（即ち仮想シリアルポート１３０が消滅したこと）に伴う異常動作をすることを抑制することができる。また、アプリケーション１００において（即ち、ユーザにおいて）、異常解消のための操作等を行う必要もない。
【0095】
また、従来、アプリケーションが正常に動作できなくなることを抑制するためにカーネル領域で動作する専用のＣＤＣドライバも開発されている。従来のＣＤＣドライバは、ＵＳＢポートと周辺装置との接続が解除される場合、仮想シリアルポートをクローズ状態に移行させる。その上で、この従来のＣＤＣドライバは、アプリケーションが正常に動作できなくなることを避けるために、アプリケーションからの伝達情報に対して適切な応答を提供する。その後、周辺装置がＵＳＢポートに再接続される場合に、仮想シリアルポートを再度オープン状態に切り替える。しかしながら、このような従来のＣＤＣドライバは、カーネル領域で動作することを特徴とする。そのため、ＯＳの更新等の影響を受けやすく、ＣＤＣドライバを提供する提供者（例えば周辺装置のベンダ等）は、当該バージョンのＯＳのための専用のＣＤＣドライバをその都度準備する必要があった。また、ホスト機器の利用者も、その都度、専用のＣＤＣドライバをコンピュータに記憶させておく必要がある。そのため、ＣＤＣドライバの提供者及びホスト機器の利用者の負担が大きかった。
【0096】
これに対し、上述の通り、本実施例のミドルウェア１１０（３６）は、ユーザ領域２００のうち、アプリケーション１００とＡＰＩ１２０との間で動作する（図２、図３参照）。一般的に、ＯＳが更新される場合であっても、アプリケーション１００及びＡＰＩ１２０の仕様が変更されることは少ない。そのため、本実施例のミドルウェア１１０によると、ユーザアプリケーションが正常に動作できなくなることを抑制するためにカーネル領域で動作する従来のＣＤＣドライバに比べて、ＯＳの更新等に伴って、ミドルウェア１１０の提供者（例えば周辺装置５０のベンダ等）が、当該バージョンのＯＳのための専用のミドルウェアをその都度準備しなければならない可能性は低い。また、ホスト機器１０の利用者が、その都度、専用のプログラムをコンピュータに記憶させておく必要もない。そのため、本実施例では、ミドルウェア１１０を備えることにより、従来に比べて、プログラムの提供者及びホスト機器の利用者の負担を軽減し得る。
【0097】
また、上記の通り、本実施例では、ＣＰＵ２０は、ＯＳからイベント通知であるアンロード通知を受信することにより、ＣＤＣドライバ１４０がアンロードされたことを検知する（図４のＳ６０参照）。そして、ＣＰＵ２０は、ＯＳからイベント通知であるロード通知を受信することにより、ＣＤＣドライバ１４０が再ロードされたことを検知する（図４のＳ５０参照）。そのため、本実施例では、ミドルウェア１１０によって、ＣＤＣドライバのアンロード及び再ロードが適切なタイミングで検知され得る。
【0098】
本実施例と請求項の対応関係を説明しておく。本実施例のミドルウェア３６が「コンピュータプログラム」の一例である。アンロード完了通知（図４のＳ５０参照）が、「第１のイベント通知」の一例である。ロード完了通知（Ｓ６０参照）が、「第２のイベント通知」の一例である。
【0099】
（第２実施例）
図９、図１０を参照して、第２実施例について、第１実施例と異なる点を中心に説明する。本実施例の機能実行システム２も、その基本的構成は第１実施例と共通する。第１実施例では、ＣＰＵ２０が、ＯＳからアンロード通知を受信することにより、ＣＤＣドライバ１４０がアンロードされたことを検知する（図４のＳ６０参照）。そして、ＣＰＵ２０は、ＯＳからロード通知を受信することにより、ＣＤＣドライバ１４０が再ロードされたことを検知する（図４のＳ５０参照）。しかしながら、本実施例では、ミドルウェア３６（１１０）に従って動作するＣＰＵ２０は、ＯＳから、ＵＳＢポート４０と周辺装置５０の接続状態を示す情報を含む状態情報を定期的に取得し、取得された状態情報に基づいて、ＣＤＣドライバ１４０がアンロードされているか否か、及び、ＣＤＣドライバ１４０がロード（より詳しくは再ロード）されているか否か、を判断する点が第１実施例とは異なる。そのため、本実施例では、図９、図１０に示すように、ポート管理処理の内容の一部も第１実施例とは異なる。
図９、図１０を参照して、第２実施例について、第１実施例と異なる点を中心に説明する。本実施例の機能実行システム２も、その基本的構成は第１実施例と共通する。第１実施例では、ＣＰＵ２０が、ＯＳからアンロード通知を受信することにより、ＣＤＣドライバ１４０がアンロードされたことを検知する（図４のＳ６０参照）。そして、ＣＰＵ２０は、ＯＳからロード通知を受信することにより、ＣＤＣドライバ１４０が再ロードされたことを検知する（図４のＳ５０参照）。しかしながら、本実施例では、ミドルウェア３６（１１０）に従って動作するＣＰＵ２０は、ＯＳから、ＵＳＢポート４０と周辺装置５０の接続状態を示す情報を含む状態情報を定期的に取得し、取得された状態情報に基づいて、ＣＤＣドライバ１４０がアンロードされているか否か、及び、ＣＤＣドライバ１４０がロード（より詳しくは再ロード）されているか否か、を判断する点が第１実施例とは異なる。そのため、本実施例では、図９、図１０に示すように、ポート管理処理の内容の一部も第１実施例とは異なる。
【0100】
（ホスト機器１０のＣＰＵ２０が実行するポート管理処理；図９）
図９を参照して、本実施例のＣＰＵ２０がミドルウェア３６（１１０）（図１、図２及び図３参照）に従って実行するポート管理処理の内容を説明する。ここで、図９の各ステップも、図４の各ステップと同様に、非同期的に行われ得ることに留意すべきである。ホスト機器１０が起動されると、ＣＰＵ２０は、ミドルウェア３６（１１０）に従って、図９のＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視を開始する。
図９を参照して、本実施例のＣＰＵ２０がミドルウェア３６（１１０）（図１、図２及び図３参照）に従って実行するポート管理処理の内容を説明する。ここで、図９の各ステップも、図４の各ステップと同様に、非同期的に行われ得ることに留意すべきである。ホスト機器１０が起動されると、ＣＰＵ２０は、ミドルウェア３６（１１０）に従って、図９のＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視を開始する。
【0101】
Ｓ１１０では、ＣＰＵ２０は、アプリケーション１００からオープン指示を受信することを監視する。Ｓ１１０の処理の内容は図４のＳ１０と同様である。ＣＰＵ２０は、アプリケーション１００からオープン指示を受信すると、Ｓ１１０でＹＥＳと判断し、Ｓ１１２に進む。
【0102】
Ｓ１１２では、ＣＰＵ２０は、周辺装置５０が接続中であるか否かを判断する。ＣＰＵ２０は、ＵＳＢポート４０の状態を参照し、周辺装置５０が有線接続されているか否かを判断する。Ｓ１１２の時点で、周辺装置５０がＵＳＢポート４０に接続されていると判断される場合、ＣＰＵ２０は、Ｓ１１２でＹＥＳと判断し、Ｓ１１４に進む。Ｓ１１２でＹＥＳの場合、ＯＳによってカーネル領域３００内にＣＤＣドライバ１４０がロードされ、カーネル領域３００内に仮想シリアルポート１３０が生成されていることを意味する。
【0103】
Ｓ１１４では、ＣＰＵ２０は、カーネル領域３００に生成されている仮想シリアルポート１３０の状態をオープン状態に移行する。
【0104】
続くＳ１１８では、ＣＰＵ２０は、周辺装置接続状態を確立する。
【0105】
続くＳ１１９では、ＣＰＵ２０は、ＣＰＵ２０は、ポーリングを開始する。ここでいう「ポーリング」とは、所定の処理タイミングの到来をトリガとして、定期的に後述の状態移行処理（図１０参照）を実行する一連の動作のことを言う。ＣＰＵ２０は、Ｓ１１９でポーリングを開始すると、再びＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
【0106】
一方、Ｓ１１２の時点において、周辺装置５０がＵＳＢポート４０に接続されていないと判断される場合、ＣＰＵ２０は、Ｓ１１２でＮＯと判断し、Ｓ１１６に進む。Ｓ１１２でＮＯの場合、カーネル領域３００内にＣＤＣドライバ１４０がロードされておらず、カーネル領域３００内に仮想シリアルポート１３０が生成されていないことを意味する。その場合、Ｓ１１６では、ＣＰＵ２０は、所定のエラー処理を行う。Ｓ１１６を終えると、ＣＰＵ２０は、再びＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
【0107】
Ｓ１２０では、ＣＰＵ２０は、ポーリングが開始されており、かつ、所定の処理タイミングが到来したか否かを判断する。ポーリングが開始されており（Ｓ１１９）、かつ、前回の状態移行処理（図１０参照）の実行から所定期間経過後の処理タイミングが到来すると、ＣＰＵ２０は、Ｓ１２０でＹＥＳと判断し、Ｓ１２２に進む。
【0108】
Ｓ１２２では、ＣＰＵ２０は、状態移行処理（図１０参照）を開始する。状態移行処理の内容は、図１０を参照して後で詳しく説明する。ＣＰＵ２０は、Ｓ１２２で状態移行処理を開始すると、再び、Ｓ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
【0109】
Ｓ１３０では、ＣＰＵ２０は、アプリケーション１００からデータ送信リクエストを受信することを監視する。Ｓ１３０の処理の内容は図４のＳ２０と同様である。ＣＰＵ２０は、アプリケーション１００からデータ送信リクエストを受信すると、Ｓ１３０でＹＥＳと判断し、Ｓ１２２に進む。
【0110】
Ｓ１３２では、ＣＰＵ２０は、データ送信処理（図５参照）を開始する。データ送信処理の内容は、第１実施例と同様であるため、詳しい説明を省略する。ＣＰＵ２０は、Ｓ１３２でデータ送信処理を開始すると、再びＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
【0111】
Ｓ１４０では、ＣＰＵ２０は、アプリケーション１００からデータ受信リクエストを受信することを監視する。Ｓ１４０の処理の内容は図４のＳ３０と同様である。ＣＰＵ２０は、アプリケーション１００からデータ受信リクエストを受信すると、Ｓ１４０でＹＥＳと判断し、Ｓ１４２に進む。
【0112】
Ｓ１４２では、ＣＰＵ２０は、データ受信処理（図６参照）を開始する。データ受信処理の内容も、第１実施例と同様であるため、詳しい説明を省略する。ＣＰＵ２０は、Ｓ１
４２でデータ受信処理を開始すると、再びＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
４２でデータ受信処理を開始すると、再びＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
【0113】
Ｓ１５０では、ＣＰＵ２０は、アプリケーション１００からクローズ指示を受信することを監視する。Ｓ１５０の処理の内容は図４のＳ４０と同様である。ＣＰＵ２０は、アプリケーション１００からクローズ指示を受信すると、Ｓ１５０でＹＥＳと判断し、Ｓ１５２に進む。
【0114】
Ｓ１５２では、ＣＰＵ２０は、ＣＰＵ２０は、上記のポーリングを停止する。続くＳ１５４では、ＣＰＵ２０は、カーネル領域３００に生成されている仮想シリアルポート１３０の状態をクローズ状態に移行する。Ｓ１５４を終えると、ＣＰＵ２０は、再びＳ１１０，Ｓ１２０，Ｓ１３０，Ｓ１４０，Ｓ１５０の各監視に戻る。
【0115】
（状態移行処理；図１０）
次いで、図１０を参照して、図９のＳ１２２においてＣＰＵ２０が開始する状態移行処理の内容を説明する。図１０の状態移行処理も、図９のポート管理処理と並行して実行される。状態移行処理が開始されると（図９のＳ１２２）、Ｓ１６０において、ＣＰＵ２０は、ＯＳに対して所定のポーリング信号を送信し、ＯＳから、ＵＳＢポート４０と周辺装置５０との接続状態を示す情報を含む状態情報を取得する。ポーリング信号の送信先は、レジストリ、デバイスファイル、レジスタ等、状態情報を取得可能な場所であればよい。
次いで、図１０を参照して、図９のＳ１２２においてＣＰＵ２０が開始する状態移行処理の内容を説明する。図１０の状態移行処理も、図９のポート管理処理と並行して実行される。状態移行処理が開始されると（図９のＳ１２２）、Ｓ１６０において、ＣＰＵ２０は、ＯＳに対して所定のポーリング信号を送信し、ＯＳから、ＵＳＢポート４０と周辺装置５０との接続状態を示す情報を含む状態情報を取得する。ポーリング信号の送信先は、レジストリ、デバイスファイル、レジスタ等、状態情報を取得可能な場所であればよい。
【0116】
続くＳ１６４では、ＣＰＵ２０は、Ｓ１６０で取得された状態情報が、ＵＳＢポート４０に周辺装置５０が接続されていることを示すか否かを判断する。状態情報が、ＵＳＢポート４０に周辺装置５０が接続されていることを示す場合、ＣＰＵ２０は、Ｓ１６４でＹＥＳと判断し、Ｓ１６６に進む。Ｓ１６４でＹＥＳの場合、ＣＰＵ２０は、ＵＳＢポート４０に周辺装置５０が接続されていることに伴い、カーネル領域３００にＣＤＣドライバ１４０がロードされていると判断する。一方、状態情報が、ＵＳＢポート４０に周辺装置５０が接続されていないことを示す場合、ＣＰＵ２０は、Ｓ１６４でＮＯと判断し、Ｓ１６８に進む。Ｓ１６４でＹＥＳの場合、ＣＰＵ２０は、カーネル領域３００においてＣＤＣドライバ１４０がアンロードされていると判断する。
【0117】
Ｓ１６６では、ＣＰＵ２０は、この時点でカーネル領域３００に生成されている仮想シリアルポート１３０の状態をオープン状態に移行する。続くＳ１６７では、ＣＰＵ２０は、周辺装置接続状態を確立する。Ｓ１６７を終えると、ＣＰＵ２０は、図１０の状態移行処理を終了する。
【0118】
Ｓ１６８では、ＣＰＵ２０は、この時点で仮想シリアルポート１３０が消滅済みか否かに関わらず、仮想シリアルポート１３０の状態をクローズ状態に移行させる。続くＳ１６９では、ＣＰＵ２０は、周辺装置離脱状態を確立する。Ｓ１６９を終えると、ＣＰＵ２０は、図１０の状態移行処理を終了する。
【0119】
上記の通り、本実施例では、ＣＰＵ２０は、ポーリングを実行することによって、定期的に図１０の状態移行処理を実行し、ＯＳから、ＵＳＢポート４０と周辺装置５０の接続状態を示す情報を含む状態情報を定期的に取得し、取得された状態情報に基づいて、ＣＤＣドライバ１４０がアンロードされているか否か、及び、ＣＤＣドライバ１４０がロード（より詳しくは再ロード）されているか否か、を判断する。本実施例による場合も、ＣＤＣドライバのアンロード及び再ロードが適切なタイミングで検知され得る。ＵＳＢポート４０に周辺装置５０が接続されていないことを示す状態情報（Ｓ１６４でＮＯ）が「第１の状態情報」の一例である。ＵＳＢポート４０に周辺装置５０が接続されていることを示す状態情報（図１０のＳ１６４でＹＥＳ）が「第２の状態情報」の一例である。
【0120】
（第３実施例）
第３実施例について、第１実施例と異なる点を中心に説明する。本実施例の機能実行システム２も、その基本的構成は第１実施例と共通する。また、ＣＰＵ２０が実行するポート管理処理（図４）の内容も、基本的には第１実施例と共通する。しかしながら、本実施例では、ＯＳから受信されるアンロード通知（図４のＳ６０参照）、ロード通知（図４のＳ５０参照）は、いずれも、イベント通知ではなく、イベント通知よりも処理優先度の高い割り込み通知である点において、第１実施例とは異なる。
第３実施例について、第１実施例と異なる点を中心に説明する。本実施例の機能実行システム２も、その基本的構成は第１実施例と共通する。また、ＣＰＵ２０が実行するポート管理処理（図４）の内容も、基本的には第１実施例と共通する。しかしながら、本実施例では、ＯＳから受信されるアンロード通知（図４のＳ６０参照）、ロード通知（図４のＳ５０参照）は、いずれも、イベント通知ではなく、イベント通知よりも処理優先度の高い割り込み通知である点において、第１実施例とは異なる。
【0121】
本実施例による場合、ＣＰＵ２０は、ＣＤＣドライバ１４０のアンロードの検知に続く各処理、及び、ＣＤＣドライバ１４０の再ロードの検知に続く各処理を優先的に実行し得る。本実施例のアンロード通知が「第１の割り込み通知」の一例であり、本実施例のロード通知が「第２の割り込み通知」の一例である。
【0122】
以上、本明細書で開示する技術の具体例を説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【0123】
２：機能実行システム
１０：ホスト機器
２０：ＣＰＵ
３０：メモリ
３２：ＯＳプログラム
３４：アプリケーション
３６：ミドルウェア
４０：ＵＳＢポート
５０：周辺装置
６０：ＵＳＢケーブル
１００：アプリケーション
１１０：ミドルウェア
１２０：ＡＰＩ
１３０：仮想シリアルポート
１４０：ＣＤＣドライバ
１５０：ＵＳＢコントローラ
２００：ユーザ領域
３００：カーネル領域
１０：ホスト機器
２０：ＣＰＵ
３０：メモリ
３２：ＯＳプログラム
３４：アプリケーション
３６：ミドルウェア
４０：ＵＳＢポート
５０：周辺装置
６０：ＵＳＢケーブル
１００：アプリケーション
１１０：ミドルウェア
１２０：ＡＰＩ
１３０：仮想シリアルポート
１４０：ＣＤＣドライバ
１５０：ＵＳＢコントローラ
２００：ユーザ領域
３００：カーネル領域
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】