(57)【要約】【課題】  所定のＡＰＩに従ってアプリケーションから容易にデータソースを正常に動作させる。【解決手段】  ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上で動作するアプリケーションが所定のＡＰＩを介して受信するイベントをデータソースが扱えるか判定する。判定の結果、データソースが扱えないと判定された場合、ＯＳから、データソースの動作に必要なイベントを取得する。【選択図】  図１
2015118567.tif 000002
【特許請求の範囲】
【請求項１】
ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上で動作するアプリケーションと、周辺機器を制御するためのドライバであるデータソースとが所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を介して通信を行う情報処理装置であって、
前記アプリケーションが前記ＡＰＩを介して受信するイベントを、前記データソースが扱えるか判定する判定手段と、
前記判定手段の判定の結果、前記データソースが扱えないと判定された場合、前記ＯＳから、前記データソースの動作に必要なイベントを取得する取得手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記判定手段は、前記アプリケーションがイベントを受信したスレッドと、データソースがイベントを取得するスレッドとが異なっている場合、前記イベントを前記データソースが扱えないと判定する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判定手段は、前記イベントからウィンドウハンドルを取得し、そのウィンドウハンドルが無効なウィンドウを示している場合、前記イベントを前記データソースが扱えないと判定する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記判定手段、及び前記取得手段は、前記データソースによって実現される
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記ＡＰＩは、ＴＷＡＩＮである
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上で動作するアプリケーションと、周辺機器を制御するためのドライバであるデータソースとが所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を介して通信を行うための情報処理方法であって、
前記アプリケーションが前記ＡＰＩを介して受信するイベントを、前記データソースが扱えるか判定する判定工程と、
前記判定工程の判定の結果、前記データソースが扱えないと判定された場合、前記ＯＳから、前記データソースの動作に必要なイベントを取得する取得工程と
を備えることを特徴とする情報処理方法。
【請求項７】
請求項１乃至５のいずれか１項に記載の情報処理装置の各手段または請求項６に記載の情報処理方法をコンピュータにより実現するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上で動作するアプリケーションと周辺機器を制御するためのドライバであるデータソースと利用する情報処理技術に関するものである。
【背景技術】
【０００２】
従来、スキャナドライバ等のデータソースをアプリケーションから制御するためのインタフェース規格（ＡＰＩ）としてＴＷＡＩＮが知られている（特許文献１参照）。この場合、アプリケーションは、ＴＷＡＩＮを経由してイベントハンドリングを行う必要がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０−２７５２２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、近年では、一般的になりつつあるイベントハンドリングを意識させないプログラミング言語やフレームワーク等の実行環境では、既存のＴＷＡＩＮに対応したプログラムを実装することが難しく、従来のＣ／Ｃ＋＋言語や従来の実行環境のプログラミング知識が必要となっている。特に、イベントハンドリングを同一のスレッドで行う必要があるという制約に従った実装は困難である。これはＴＷＡＩＮ以外のＡＰＩについても同様に起こり得る課題である。
【０００５】
本発明は上記の課題を解決するためになされたものであり、所定のＡＰＩに従ってアプリケーションから容易にデータソースを正常に動作させることができる情報処理技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。即ち、
ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上で動作するアプリケーションと、周辺機器を制御するためのドライバであるデータソースとが所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を介して通信を行う情報処理装置であって、
前記アプリケーションが前記ＡＰＩを介して受信するイベントが、前記データソースが扱えるか判定する判定手段と、
前記判定手段の判定の結果、前記データソースが扱えないと判定された場合、前記ＯＳから、前記データソースの動作に必要なイベントを取得する取得手段と
を備える。
【発明の効果】
【０００７】
本発明によれば、所定のＡＰＩに従ってアプリケーションから容易にデータソースを正常に動作させることができる。
【図面の簡単な説明】
【０００８】
【図１】実施形態１のＴＷＡＩＮ構成を示す図である。
【図２】実施形態１のアプリケーション側の処理を示すフローチャートである。
【図３】実施形態１のデータソース側の処理を示すフローチャートである。
【図４】実施形態２のデータソース側の処理を示すフローチャートである。
【図５】実施形態２のデータソースマネージャ側の処理を示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１０】
＜実施形態１＞
図１はＴＷＡＩＮ規格に対応したシステムの構成図である。
【００１１】
アプリケーション１０１は、Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）の一つであるＴＷＡＩＮ規格で規定されているデータソースマネージャ１０２（以下、ＤＳＭ）にアクセスする。ＴＷＡＩＮ規格に対応しているＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）、例えば、ＯＳであるＷｉｎｄｏｗｓ（登録商標）には、ＤＳＭ１０２がプリインストールされている。また、スキャナデータソース（スキャナドライバ）であるデータソース１０３及び１０４は、ＤＳＭ１０２に複数接続することが可能である。データソース１０３及び１０４は、それぞれ対応するスキャナ機器１０５及び１０６を制御する。スキャナ機器１０５はデータソース１０３による制御により、原稿上の画像を読み取り、それによって得られた画像データをデータソース１０３に渡す。データソース１０３は受け取った画像データをアプリケーション１０１に供給する。スキャナ機器１０６はデータソース１０３により制御され、同様な処理を行う。アプリケーション１０１はスキャナ機器（データソース）の選択及びスキャナ機器によって得られた読取画像データの取得を行う。
【００１２】
これらのアプリケーション１０１、ＤＳＭ１０２、データソース１０３及び１０４は、ＯＳ上で動作するソフトウェア（プログラム）である。
【００１３】
ＤＳＭ１０２は、データソース１０３及び１０４にアクセスし、アプリケーション１０１から送信されているＴＷＡＩＮプロトコルに従ったコマンドを、選択したデータソース、例えば、データソース１０３が選択されていた場合はデータソース１０３に送信する。このような構成であるため、複数のデータソースがインストールされている環境であっても、アプリケーション１０１ではＤＳＭ１０２にアクセスすれば、複数のデータソースに選択的にアクセスすることが可能となる。ＤＳＭ１０２は、アプリケーション１０１がデータソース１０３及び１０４を選択するためのＵＩ（ユーザインタフェース）や、インストールされているデータソース１０３及び１０４を列挙する機能を有する。
【００１４】
尚、アプリケーション１０１、ＤＳＭ１０２、データソース１０３及び１０４は、汎用コンピュータ等の情報処理装置にインストールされる。この情報処理装置は、汎用コンピュータに搭載される標準的な構成要素（例えば、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスク、外部記憶装置、ネットワークインタフェース、ディスプレイ、キーボード、マウス等）を有している。そして、この情報処理装置のＣＰＵが、メモリ（ＲＡＭやＲＯＭ）に記憶されるプログラムを読み出し実行することで、アプリケーション１０１やＤＳＭ１０２、データソース１０３及び１０４を実現する。これらのプログラムは、例えば、ハードディスク等の記憶装置に記憶される。更に、情報処理装置は、ＵＳＢインタフェース等の外部インタフェースを介して、スキャナ機器１０５及び１０６と接続し、通信する。
【００１５】
情報処理装置に接続する機器は、スキャナ機器１０５及び１０６に限定されず、ＴＷＡＩＮ規格で動作可能な周辺機器（複合機、デジタルカメラ、ビデオカメラ等）を接続することが可能である。また、情報処理装置に接続する機器に対しては、情報処理装置の表示部（ディスプレイ）に表示されるＵＩを介して、その機器に対する機能の実行や設定等の各種操作を実現することができる。
【００１６】
また、本実施形態では、データソースをアプリケーションから制御するためのインタフェース規格として、ＴＷＡＩＮ規格を例に挙げているが、これに限定されない。データソースとアプリケーションの間に介在する、ＴＷＡＩＮ規格と同様の挙動を振る舞う所定のインタフェース（ＡＰＩ）であれば、他のＡＰＩ規格であっても良い。
【００１７】
次に、データソース１０３のＵＩを表示して画像を読み取らせる場合のアプリケーションの動作を図２に示すフローチャートに従って説明する。
【００１８】
尚、図２の処理は、メモリに記憶されているアプリケーション１０１を、ＣＰＵが読み出し実行することで実現される。
【００１９】
Ｓ２０１で、アプリケーション１０１は、ＤＳＭ１０２をロードする。Ｓ２０２で、アプリケーション１０１は、ＤＳＭ１０２をオープンするために、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＰＡＲＥＮＴ／ＭＳＧ＿ＯＰＥＮＤＳＭ」をＤＳＭ１０２に送信する。Ｓ２０３で、アプリケーション１０１は、画像を読み取らせるスキャナ機器のデータソースを選択し、ＤＳＭ１０２に通知する。ここで、データソースとしては、図１のデータソース１０３あるいは１０４があり、例えば、データソース１０３を選択したとする。以降の説明では、このデータソース１０３を選択した場合を例に挙げて説明する。
【００２０】
Ｓ２０４で、アプリケーション１０１は、データソース１０３との接続を行うために、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＩＤＥＮＴＩＴＹ／ＭＳＧ＿ＯＰＥＮＤＳ」をＤＳＭ１０２に送信する。Ｓ２０５で、アプリケーション１０１は、データソース１０３からのデバイス情報取得やデータソース１０３への情報設定のためのケーパビリティをＤＳＭ１０２に送信する。Ｓ２０６で、アプリケーション１０１は、データソース１０３を、Ｅｎａｂｌｅにする（データソース（スキャナドライバ）のＵＩを表示する）ために、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＵＳＥＲＩＮＴＥＲＦＡＣＥ／ＭＳＧ＿ＥＮＡＢＬＥＤＳ」をＤＳＭ１０２に送信する。
【００２１】
Ｓ２０７で、アプリケーション１０１は、ＯＳ関数（ＯＳのＡＰＩ）「ＧｅｔＭｅｓｓａｇｅ／ＰｅｅｋＭｅｓｓａｇｅ」を使用してイベントを取得する。そして、アプリケーション１０１は、取得したイベントを、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加して、ＤＳＭ１０２に送信する。
【００２２】
Ｓ２０８で、アプリケーション１０１は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」の戻り値を調べ、取得したイベントをアプリケーション１０１側でイベント処理（イベントの内容に応じた処理）し、それに応じて、データソース１０３の終了処理やスキャン（画像読取）処理へと移る。ここでは、アプリケーション１０１は、イベント処理が終了しているか否かを判定する。終了していない場合（Ｓ２０８でＮＯ）、ステップＳ２０７に戻る。一方、終了している場合（Ｓ２０８でＹＥＳ）、Ｓ２０９へ進む。Ｓ２０９で、アプリケーション１０１は、イベントの状態に応じて、終了処理、スキャン処理等の処理を実行する。
【００２３】
以上のフローは、ＴＷＡＩＮで規定されている一般的なフローであるため、アプリケーション１０１側が特別な処理を行う必要はない。
【００２４】
次の動作としては、アプリケーション１０１がＤＳＭ１０２に送信したＴＷＡＩＮプロトコルに従ったコマンドをＤＳＭ１０２からデータソース１０３へ送信する必要がある。しかしながら、Ｓ２０３以降にＤＳＭ１０２に送信する命令は、Ｓ２０２で選択したデータソース１０３へＤＳＭ１０２がそのまま送信するものでありＤＳＭ１０２とデータソース１０３間のやり取りの説明は省略する。
【００２５】
データソース１０３側の動作を図３に示すフローチャートに従って説明する。
【００２６】
尚、図３の処理は、アプリケーション１０１からスキャナ機器による画像の取り込みが指示されると開始される。
【００２７】
ここでは、データソースとして、データソース１０３が実行する場合を例に挙げて説明するが、データソース１０４についても同様である。
【００２８】
Ｓ３０１で、データソース１０３は、ＤＳＭ１０２からのデータソース列挙要求に応答する。ここで応答することで、アプリケーション１０１側にデータソースがあることが伝わる。Ｓ３０２で、データソース１０３は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＩＤＥＮＴＩＴＹ／ＭＳＧ＿ＯＰＥＮＤＳ」に応答する。ここで、ソフトウェアの初期化処理やデバイスの初期化処理を行う。
【００２９】
Ｓ３０３で、データソース１０３は、ＤＳＭ１０２から送信されるデータソース設定の取得・設定へ応答する。現在の設定値やアプリケーション１０１から送信される設定値、例えば、読み取りの際のカラーモードや解像度等を設定する。Ｓ３０４で、データソース１０３は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＵＳＥＲＩＮＴＥＲＦＡＣＥ／ＭＳＧ＿ＥＮＡＢＬＥＤＳ」に応答する。ここで、ＯＳのＷｉｎｄｏｗ関数や描画命令を使用し、データソース１０３は、自身のＵＩを表示する。
【００３０】
Ｓ３０５で、データソース１０３は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」を受信する。Ｓ３０６で、データソース１０３は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」からイベントを取得する。
【００３１】
Ｓ３０７で、データソース１０３は、取得したイベントに対し再取得が必要であるか否かを判定する。Ｓ３０６において正しいメッセージキューからイベントを取得していればイベントの再取得は不要であり、誤った（意図しない）メッセージキューからイベントを取得していればイベントの再取得が必要となる。ＴＷＡＩＮではマルチスレッドが考慮されておらず、異なるスレッドのメッセージキューからのイベントを扱うことができない。
【００３２】
ここでの判定方法は、例えば、イベントからＯＳ  ＡＰＩであるＧｅｔＷｉｎｄｏｗＴｈｒｅａｄＰｒｏｃｅｓｓＩｄ（）命令を使用して得られたスレッドＩＤと、同じくＯＳ  ＡＰＩであるＧｅｔＣｕｒｒｅｎｔＴｈｒｅａｄＩｄ（）命令を使用して得られたデータソース１０３のスレッドＩＤを比較する。このスレッドＩＤは整数値で表現されているため比較することが可能であり、比較の結果、同一のＩＤであれば、イベントの再取得は不要であると判定し、異なればイベントの再取得が必要であると判定する。
【００３３】
その他の判定方法としては、イベントからどのウィンドウでイベントが発生しているかを示すウィンドウハンドルを取り出し、ＯＳ  ＡＰＩであるＩｓＷｉｎｄｏｗ（）命令を使用して実在しているウィンドウから発生したイベントで有れば、イベントの再取得は不要であると判定し、実在しているウィンドウから発生したイベントでなければイベントの再取得が必要であると判定する。
【００３４】
更に別の判定方法としては、イベントからウィンドウハンドルを取得し、ウィンドウハンドルがＮＵＬＬ値（無効なウィンドウを示している）であれば、イベントがデータソースの動作に支障をきたすので、イベントの再取得が必要であると判定する。
【００３５】
判定の結果、イベントを再取得する必要がある場合（Ｓ３０７でＹＥＳ）、Ｓ３０８へ進む。一方、イベントを再取得する必要がない場合（Ｓ３０７でＮＯ）、Ｓ３０９へ進む。
【００３６】
Ｓ３０８で、データソース１０３は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加されているイベント情報を破棄し、ＯＳ関数を使用してイベントを取得する。Ｓ３０９で、データソース１０３は、イベントを処理する。イベント情報には発生したウィンドウハンドルが付加されているため、データソース１０３が管理しているボタン等を含むウィンドウを判定することができ、データソース１０３で必要なイベント処理を行う。
【００３７】
Ｓ３１０で、データソース１０３は、イベント処理の実行の有無や、イベント処理の結果によってデータソース動作が変化した結果を、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」の返答としてＤＳＭ１０２に送信する。
【００３８】
Ｓ３１１で、データソース１０３は、終了処理、スキャン処理等の処理を実行する。
【００３９】
アプリケーション１０１が、Ｓ３０６で正しいメッセージキューからイベントを取得した場合は、データソース１０３側のＳ３０７の判定で、イベントの再取得が不要であると判定され、Ｓ３０８を行わずにＳ３０９へと進む。このフローは、ＴＷＡＩＮで規定されているデータソースの処理フローに従ったものであるため、ＴＷＡＩＮ規格に従って動作するアプリケーションとの組み合わせで正しく動作する。
【００４０】
一方、アプリケーション１０１がＳ３０６で誤ったメッセージキューからイベントを取得した場合は、データソース１０３側のＳ３０７の判定で、イベントの再取得が必要であると判定され、Ｓ３０８でデータソース１０３の動作に必要なイベントを、ＯＳ関数を使用して取得する。このため、データソース１０３側のＳ３０９の処理が正常に動作し、データソース１０３が正しく動作する。
【００４１】
以上説明したように、実施形態１によれば、アプリケーションから送信されるイベントがデータソースの動作に支障をきたす場合は、アプリケーション外でＯＳから動作に必要なイベントを取得して動作させる。また、アプリケーションから送信されるイベントが正常であれば、通常のＴＷＡＩＮに従って処理を実行する。
【００４２】
具体的には、アプリケーション側がＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加するイベントを誤った方法で取得したとしても、データソース側で取得し直して動作することが可能となる。
【００４３】
このように、アプリケーションがＴＷＡＩＮで想定されていないイベントをデータソースに送信したとしても、例えば、データソースでＯＳから動作に必要なイベントを再取得することで正常に動作させることが可能となる。また、イベントが動作に支障をきたすかどうかを判定し処理することで、ＴＷＡＩＮ規格で動作する一般的なマルチスレッド化するアプリケーションとの組み合わせでも正常に動作させることが可能となる。
【００４４】
＜実施形態２＞
実施形態１では、データソース１０３側でＴＷＡＩＮプロトコル「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」の補正（イベントの再取得）を行っている。これに対して、実施形態２では、アプリケーション１０１とデータソース１０３間に位置するＤＳＭ１０２で補正（イベントを再取得）する構成について説明する。
【００４５】
アプリケーション１０１側の処理は、実施形態１の図２のフローチャートと同じであるため、その説明は省略する。
【００４６】
次に、実施形態２によるデータソース１０３側の動作を図４に示すフローチャートに従って説明する。
【００４７】
図４において、Ｓ４０１〜Ｓ４０６は、図３のＳ３０１〜Ｓ３０６に対応するため、その説明は省略する。また、Ｓ４０７〜Ｓ４０９は、図４のＳ３１０〜Ｓ３１１に対応するため、その説明は省略する。つまり、図４は、図３のＳ３０７〜Ｓ３０８の処理を省略した構成となっている。実施形態２の場合、後述するように、データソース１０３は、ＤＳＭ１０２から正常なイベントを取得することができるので、図３のＳ３０７〜Ｓ３０８の処理が不要となる。また、このフローは、ＴＷＡＩＮで規定されている一般的なフローであるため、データソース１０３側が特別な処理を行う必要はない。
【００４８】
実施形態２によるＤＳＭ１０２側の動作を図５に示すフローチャートに従って説明する。
【００４９】
Ｓ５０１で、ＤＳＭ１０２は、アプリケーション１０１から送信されてくるＴＷＡＩＮプロトコルに従ったコマンドを受信する。Ｓ５０２で、ＤＳＭ１０２は、ＴＷＡＩＮプロトルに従ったコマンドが特定のコマンド（「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」で有るか否かを判定する。特定のコマンドでない場合（Ｓ５０２でＮＯ）、Ｓ５０６へ進む。一方、特定のコマンドである場合（Ｓ５０２でＹＥＳ）、Ｓ５０３へ進む。
【００５０】
Ｓ５０３で、ＤＳＭ１０２は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加されているイベントを取得する。Ｓ５０４で、ＤＳＭ１０２は、取得したイベントに対し再取得が必要であるか否かを判定する。ここでの判定方法は、図３のステップＳ３０７における判定方法を利用することができる。
【００５１】
判定の結果、イベントを再取得する必要がある場合（Ｓ５０４でＹＥＳ）、Ｓ５０５へ進む。一方、イベントを再取得する必要がない場合（Ｓ５０４でＮＯ）、Ｓ５０６へ進む。
【００５２】
Ｓ５０５で、ＤＳＭ１０２は、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加されているイベント情報を破棄し、ＯＳ関数を使用してイベントを再取得し、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に再取得したイベントを付加する。Ｓ５０６で、ＤＳＭ１０２は、データソース１０３にＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」を送信する。
【００５３】
ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」以外のコマンドは、ＴＷＡＩＮ規格に従ってデータソース１０３へ送信される。また、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」であっても、それに付加されているイベントの再取得が必要でなければＴＷＡＩＮ規格に従ってデータソース１０３へ送信される。このため、図５の処理は、ＴＷＡＩＮ規格に従うアプリケーション１０１との組み合わせで正しく動作する。一方、ＴＷＡＩＮプロトコルに従ったコマンド「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加されているイベントの再取得が必要である場合、Ｓ５０５でデータソース１０３が動作するイベントを取得してデータソース１０３へ送信される。
【００５４】
以上説明したように、実施形態２によれば、アプリケーション側がＴＷＡＩＮプロトコル「ＤＧ＿ＣＯＮＴＲＯＬ／ＤＡＴ＿ＥＶＥＮＴ／ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴ」に付加するイベントをＴＷＡＩＮで想定されていない方法で取得したとしても、ＤＳＭ側でそのイベントを再取得して動作することが可能となる。例えば、マルチスレッド化するアプリケーションとの組み合わせでも正常に動作させることが可能となる。
【００５５】
尚、以上の実施形態はアプリケーションとデータソース（デバイスドライバ）のＡＰＩとしてＴＷＡＩＮを例に説明したが、ＴＷＡＩＮ以外のＡＰＩに適用してもよい。
【００５６】
また、以上の実施形態の処理は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。このとき、１つのコンピュータで処理させてもよいし、複数のコンピュータを連携させながら処理させてもよい。また、この処理の一部または全部をＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）等のハードウェアで実現させてもよい。
【図１】
2015118567.tif 000003
【図２】
2015118567.tif 000004
【図３】
2015118567.tif 000005
【図４】
2015118567.tif 000006
【図５】
2015118567.tif 000007