(57)【要約】【課題】端末で未サポートの周辺機器を新たに制御する場合であっても、その周辺機器を制御するための機能を追加するコストを削減できる周辺機器制御装置を提供する。【解決手段】制御手段８０は、搭載されるオペレーティングシステムにおいて周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する。このとき、制御手段８０は、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理に応じて、周辺機器を制御する。【選択図】図９
2015049600.tif 000002
【特許請求の範囲】
【請求項１】
接続される周辺機器を制御する周辺機器制御装置であって、
搭載されるオペレーティングシステムにおいて前記周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御手段を備え、
前記制御手段は、前記アプリケーション層から前記カーネル層へアクセスする方法として予め前記オペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じて当該制御ごとに定義される処理とを含む独自処理に応じて、前記周辺機器を制御する
ことを特徴とする周辺機器制御装置。
【請求項２】
オペレーティングシステムとしてＡｎｄｏｒｏｉｄを搭載し、
制御手段は、ＵＳＢＨｏｓｔＡＰＩに規定されている処理の一部と、所望する制御の内容に応じて当該制御ごとに定義される処理とを含む独自処理に応じて、接続されるＵＳＢデバイスを制御する
請求項１記載の周辺機器制御装置。
【請求項３】
制御手段は、独自処理として、ＵＳＢデバイスから取得可能な情報を変数に保持し、当該変数を解析することによって、標準処理以外の制御をＵＳＢデバイスに対して行う
請求項２記載の周辺機器制御装置。
【請求項４】
制御手段は、アプリケーション層において独自処理としてアイソクロナス転送処理を実装する
請求項２または請求項３記載の周辺機器制御装置。
【請求項５】
制御手段は、標準処理として、ＵＳＢデバイスに対するパーミッションを確保する処理を行う
請求項２から請求項４のうちのいずれか１項に記載の周辺機器制御装置。
【請求項６】
端末に接続される周辺機器を制御する周辺機器制御方法であって、
前記端末に搭載されるオペレーティングシステムにおいて前記周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御ステップを含み、
前記制御ステップで、前記アプリケーション層から前記カーネル層へアクセスする方法として予め前記オペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じて当該制御ごとに定義される処理とを含む独自処理に応じて、前記周辺機器を制御する
ことを特徴とする周辺機器制御方法。
【請求項７】
端末にオペレーティングシステムとしてＡｎｄｏｒｏｉｄが搭載され、
制御ステップで、ＵＳＢＨｏｓｔＡＰＩに規定されている処理の一部と、所望する制御の内容に応じて当該制御ごとに定義される処理とを含む独自処理に応じて、接続されるＵＳＢデバイスを制御する
請求項６記載の周辺機器制御方法。
【請求項８】
接続される周辺機器を制御するコンピュータに適用される周辺機器制御プログラムであって、
前記コンピュータに、
搭載されるオペレーティングシステムにおいて前記周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御処理を実行させ、
前記制御処理で、前記アプリケーション層から前記カーネル層へアクセスする方法として予め前記オペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じて当該制御ごとに定義される処理とを含む独自処理に応じて、前記周辺機器を制御させる
ための周辺機器制御プログラム。
【請求項９】
コンピュータには、オペレーティングシステムとしてＡｎｄｏｒｏｉｄが搭載され、
前記コンピュータに、
制御処理で、ＵＳＢＨｏｓｔＡＰＩに規定されている処理の一部と、所望する制御の内容に応じて当該制御ごとに定義される処理とを含む独自処理に応じて、接続されるＵＳＢデバイスを制御させる
請求項８記載の周辺機器制御プログラム。
【請求項１０】
コンピュータに、
制御処理で、独自処理として、ＵＳＢデバイスから取得可能な情報を変数に保持させ、当該変数を解析させことによって、標準処理以外の制御をＵＳＢデバイスに対して行わせる
請求項９記載の周辺機器制御プログラム。
【請求項１１】
制御処理に、アプリケーション層における独自処理としてアイソクロナス転送処理を含む
請求項９または請求項１０記載の周辺機器制御プログラム。
【請求項１２】
コンピュータに、
制御処理で、標準処理として、ＵＳＢデバイスに対するパーミッションを確保する処理を行わせる
請求項９から請求項１１のうちのいずれか１項に記載の周辺機器制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器に接続して使用される周辺機器を制御する周辺機器制御装置、周辺機器制御方法および周辺機器制御プログラムに関する。
【背景技術】
【０００２】
近年、ＩＰ（Internet Protocol ）ネットワークが広帯域化しており、ＵＳＢ（Universal Serial Bus）などの周辺機器についても、ＩＰネットワーク上に位置付ける試みが行われている。
【０００３】
このような周辺機器をＩＰネットワーク上に位置付ける手法が非特許文献１に記載されている。非特許文献１に記載された手法では、ＵＳＢ  ｏｖｅｒ  ＩＰによるＵＳＢ仮想化技術を用いてデバイス制御が行われる。なお、ＵＳＢ  ｏｖｅｒ  ＩＰは、ＵＳＢにおいて用いられるＵＳＢコマンドをＩＰパケットにカプセル化する手法である。以下の説明では、ＵＳＢ  ｏｖｅｒ  ＩＰのことを、ＵＳＢＩＰと記す。
【０００４】
また、Ａｎｄｒｏｉｄ（登録商標）端末の普及により、オープンソースのＵＳＢＩＰを利用して、一般的なＡｎｄｒｏｉｄ端末でＵＳＢ仮想化を実現することも行われている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】広渕 崇宏、外４名、「IPデバイス空間実現にむけたUSB over IP によるデバイス制御機構の提案」、情報処理学会研究報告．UBI,［ユビキタスコンピューティングシステム］2003(115) 、一般社団法人情報処理学会、p.117-122 、2003-11-18
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、オープンソースのＵＳＢＩＰを活用してＵＳＢ仮想化を実現する場合、カーネル層の改変が必要になるという問題がある。そのため、一般に、メーカーが対応していない（未サポートの）ＵＳＢ機器をＡｎｄｒｏｉｄ端末に接続しただけでは、そのＵＳＢ機器に対してＵＳＢ仮想化を実現することは困難である。
【０００７】
このような未サポートの周辺機器のＵＳＢ仮想化を実現しようとする場合、例えば、ＲＯＭ（Read Only Memory）を更新するなど、端末への組み込みを行うことも考えられる。しかし、未サポートの周辺機器が現れるたびにＲＯＭ更新を行うのは現実的ではない。
【０００８】
一方、Ａｎｄｏｒｏｉｄの標準ＡＰＩ（Application Programming Interface ）として、ＵＳＢＨｏｓｔＡＰＩが提供されており、このＡＰＩを用いてデバイス制御を行うことも考えられる。しかし、Ａｎｄｏｒｏｉｄ標準のＵＳＢＨｏｓｔＡＰＩで提供されている機能は制限されているため、必ずしも所望の機能を実現できるとは限らない。
【０００９】
そこで、本発明は、端末で未サポートの周辺機器を新たに制御する場合であっても、その周辺機器を制御するための機能を追加するコストを削減できる周辺機器制御装置、周辺機器制御方法および周辺機器制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明による周辺機器接続装置は、接続される周辺機器を制御する周辺機器制御装置であって、搭載されるオペレーティングシステムにおいて周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御手段を備え、制御手段が、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理に応じて、周辺機器を制御することを特徴とする。
【００１１】
本発明による周辺機器制御方法は、端末に接続される周辺機器を制御する周辺機器制御方法であって、端末に搭載されるオペレーティングシステムにおいて周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御ステップを含み、制御ステップで、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理に応じて、周辺機器を制御することを特徴とする。
【００１２】
本発明による周辺機器制御プログラムは、接続される周辺機器を制御するコンピュータに適用される周辺機器制御プログラムであって、コンピュータに、搭載されるオペレーティングシステムにおいて周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御処理を実行させ、制御処理で、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される処理である標準処理の一部と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理に応じて、周辺機器を制御させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、端末で未サポートの周辺機器を新たに制御する場合であっても、その周辺機器を制御するための機能を追加するコストを削減できる。
【図面の簡単な説明】
【００１４】
【図１】本発明による周辺機器制御プログラムを利用した情報端末の一実施形態を示すブロック図である。
【図２】ＵＳＢデバイスを制御する一般的なＡｎｄｏｒｏｉｄアプリケーションの例を示す説明図である。
【図３】実施形態で用いられるＡｎｄｏｒｏｉｄアプリケーションの例を示す説明図である。
【図４】実施例のアプリケーション構造の例を示す説明図である。
【図５】ＵＳＢ転送に用いられる構造の例を示す説明図である。
【図６】エラーコードの例を示す説明図である。
【図７】ＵＳＢ転送処理の動作例を示すシーケンス図である。
【図８】ＵＳＢ転送処理の動作例を示すシーケンス図である。
【図９】本発明による周辺機器制御装置の概要を示すブロック図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施形態を図面を参照して説明する。
【００１６】
図１は、本発明による周辺機器制御プログラムを利用した情報端末の一実施形態を示すブロック図である。図１に例示する情報端末１００は、制御手段１０を備えている。制御手段１０は、プログラム（周辺機器制御プログラム）に従って動作するコンピュータのＣＰＵによって実現される。
【００１７】
情報端末１００は、例えば、オペレーティングシステムとしてＡｎｄｒｏｉｄを搭載した端末により実現される。
【００１８】
情報端末１００（より具体的には、制御手段１０）は、周辺機器２０およびクライアント３０に接続される。制御手段１０は、例えば、クライアント３０の指示に応じて情報端末１００に接続された周辺機器２０を制御する。なお、クライアント３０は、端末であってもよく、例えば、端末に搭載されたＷｉｎｄｏｗｓ（登録商標）のオペレーティングシステムに含まれるプログラムであってもよい。
【００１９】
周辺機器２０は、例えば、ＵＳＢ機器（ＵＳＢデバイス）である。以下、情報端末１００に接続される周辺機器としてＵＳＢ機器を例に説明する。ただし、周辺機器２０は、ＵＳＢ機器のように物理的に接続される機器に限定されない。周辺機器２０は、例えば、赤外線や、Ｂｌｕｅｔｏｏｔｈ（登録商標）を介して情報端末１００に接続される機器であってもよい。このため、情報端末１００は、周辺機器２０が接続されるため、周辺機器接続装置ということもできる。
【００２０】
具体的には、制御手段１０は、クライアント通信部１１、クライアント用データ作成部１２、コマンド解析部１３、処理制御部１４、標準制御処理部１５および独自制御処理部１６で定義されるプログラムに従って動作する。以下、各部で定義されるプログラムに従って、制御手段１０が動作することを、各部自身がプログラムに従って動作する、または、単に各部自身が動作する、と記すこともある。
【００２１】
クライアント通信部１１は、クライアント３０とデータの送受信を行う。本実施形態では、クライアント３０は、ＵＳＢＩＰの規格に従って動作するプログラムであるとし、以下の説明では、ＵＳＢＩＰクライアントと記すこともある。クライアント通信部１１は、ＵＳＢＩＰの規格に従って動作するクライアント３０と、ＴＣＰ（Transmission Control Protocol ）／ＩＰプロトコルでＵＳＢＩＰのデータを送受信する。すなわち、クライアント通信部１１は、例えば、ソケット通信でＵＳＢＩＰの規格に沿った情報をパケットで送信する機能を有するとも言える。
【００２２】
クライアント用データ作成部１２は、周辺機器２０からのデータを取得して、クライアント３０へ送信するためのデータを作成する。具体的には、クライアント用データ作成部１２は、周辺機器２０であるＵＳＢデバイスからデータを取得し、ＵＳＢＩＰクライアント（クライアント３０）へ送信するデータを作成する。なお、クライアント用データ作成部１２は、オープンソースのＵＳＢＩＰの規格に応じて動作する。
【００２３】
コマンド解析部１３は、クライアント３０から受信したコマンドを解析し、周辺機器２０に対して送信するパケットを作成し、処理制御部１４に送信する。具体的には、コマンド解析部１３は、クライアント３０から受信したＵＳＢＩＰのコマンドを解析して、ＵＲＢ（USB Request Block ）を作成し、ＵＳＢデバイス側（処理制御部１４）に送信する。なお、コマンド解析部１３も、オープンソースのＵＳＢＩＰの規格に応じて動作する。
【００２４】
処理制御部１４は、標準制御処理部１５と、独自制御処理部１６の少なくとも一方に、周辺機器２０にアクセスするための処理を振り分ける。具体的には、処理制御部１４は、ＵＳＢデバイスにアクセスするための抽象的なラッパ（Wrapper ）であり、ＵＳＢデバイス制御の処理を集めた部分といえる。
【００２５】
具体的には、本実施形態では、後述する独自制御処理部１６の中で標準処理制御部１５が実行する標準機能の一部が使用される。そのため、処理制御部１４は、標準処理制御部１５および独自制御処理部１６が行う処理を振り分ける制御を行う。
【００２６】
標準制御処理部１５は、情報端末１００に搭載されるオペレーティングシステムで予め提供される処理（以下、標準処理と記す。）を実行する。例えば、情報端末１００がオペレーティングシステムとしてＡｎｄｒｏｉｄを搭載している場合、標準処理として、ＵＳＢＨｏｓｔＡＰＩに基づく処理が挙げられる。
【００２７】
なお、標準制御処理部１５は、全ての標準処理を実行できなくてもよい。標準制御処理部１５は、後述する独自制御処理部１６が周辺機器２０を制御するために必要な処理のみ実行できればよい。言い換えると、例えば、標準制御処理部１５および独自制御処理部１６がライブラリ群で構成されている場合、標準制御処理部１５には、独自制御処理部１６に含まれるライブラリ群を実行するために必要なＵＳＢＨｏｓｔＡＰＩが含まれていればよい。標準制御処理部１５は、例えば、パーミッションの取得やデバイスの名称を取得するなどの標準的な処理を行う。
【００２８】
独自制御処理部１６は、標準制御処理部１５だけでは実行できない独自の制御処理（以下、独自処理と記す。）を実行する。すなわち、独自制御処理部１６は、上述する標準処理と、クライアント３０が所望する制御の内容に応じて定義される処理とを含む独自処理に従って、周辺機器２０を制御する。
【００２９】
本実施形態では、未サポートの周辺機器が現れるたびにＲＯＭ更新を伴うような変更を情報端末１００に及ぼすことを避けるために、独自制御処理部１６がアプリケーションの変更のみで対応できるようにする。
【００３０】
具体的には、独自制御処理部１６は、情報端末１００に搭載されるオペレーティングシステム（例えば、Ａｎｄｒｏｉｄ）において、周辺機器２０に対してカーネル層で行われる処理をアプリケーション層の処理で制御する。
【００３１】
独自制御処理部１６は、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される標準処理（例えば、ＵＳＢＨｏｓｔＡＰＩ）と、所望する制御の内容に応じてその制御ごとに定義される処理で周辺機器２０を制御する。
【００３２】
すなわち、ＵＳＢデバイスを制御する処理はカーネル層で定義されるため、新たなＵＳＢデバイスの処理を追加する場合、一般にカーネル層に処理が定義される。しかし、この場合、ＲＯＭの更新など、機能追加に伴う多くのコストが発生してしまう。一方、本実施形態では、アプリケーション層からカーネル層へ直接アクセスするルートを独自処理として作成し、独自制御処理部１６が、アプリケーション層でその独自処理を実行する。そのため、カーネル層自体を変更することなく、新たな周辺機器（ＵＳＢデバイス）の制御を行うことが可能になる。
【００３３】
また、アプリケーション層に処理を追加することは比較的容易に行うことができる。そのため、本実施形態によれば、Ａｎｄｏｒｏｉｄ標準のＵＳＢＨｏｓｔＡＰＩで提供されている以外の機能を実現する際、端末で未サポートの周辺機器を新たに制御する場合であっても、その周辺機器を制御するための機能を追加するコストを削減できる
【００３４】
以下、具体例を挙げて、標準処理と独自処理とを説明する。図２は、ＵＳＢデバイスを制御する一般的なＡｎｄｏｒｏｉｄアプリケーションの例を示す説明図である。また、図３は、本実施形態で用いられるＡｎｄｏｒｏｉｄアプリケーションの例を示す説明図である。図２に例示するように、Ａｎｄｏｒｏｉｄアプリケーションを作成する場合には、Ｊａｖａ（登録商標）によるＵｓｂＨｏｓｔＡＰＩと、Ｃ／Ｃ＋＋によるｌｉｂｕｓｂ．ｓｏが用いられる。
【００３５】
図２に例示するように、一般的なＵＳＢＨｏｓｔＡＰＩでは、その仕様により、例えば、以下のような処理（以下、標準未対応処理と記す。）を実現することは困難である。
・非同期のＵＳＢ転送で失敗したＵＲＢを特定する
・ＵＳＢ転送の正しいエラーコードを取得する
・インタラプト転送の返却するバッファ長を測定する
・アイソクロナス転送をサポートする
【００３６】
しかし、本実施形態では、図３に例示するように、ＵｓｂＨｏｓｔＡＰＩおよびｌｉｂｕｓｂ．ｓｏを用いて新たなＡＰＩを作成するため、これらの処理も実現できる。なお、図３に例示するＪＩＮ．ｌｉｂは、上述する独自処理を実現可能なＡＰＩをライブラリ化したものである。なお、これらの内容については、実施例にて詳述する。
【００３７】
このように、Ａｎｄｏｒｏｉｄアプリケーション層でＵＳＢＩＰ機能を作り込み、またその実現のためにＡｎｄｏｒｏｉｄ上でのＵＳＢデバイスアクセス制御機能を拡張することで、機能追加に伴うコストを削減できる。すなわち、ＵＳＢ仮想化機能をＡｎｄｏｒｏｉｄアプリケーションの配布によって実現できる。
【００３８】
以上のように、本実施形態によれば、制御手段１０は、情報端末１００に搭載されるオペレーティングシステムにおいて周辺機器２０に対してカーネル層で行われる処理をアプリケーション層の処理で制御する。ここで、制御手段１０は、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される標準処理と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理で情報端末１００に接続される周辺機器２０を制御する。
【００３９】
具体的には、制御手段１０は、ＡｎｄｒｏｉｄにおいてＵＳＢ機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する。ここで、制御手段１０は、ＵＳＢＨｏｓｔＡＰＩと、一般的なＵＳＢＨｏｓｔＡＰＩだけでは実現できない制御の内容に応じて追加される独自処理で、Ａｎｄｒｏｉｄ端末に接続されるＵＳＢ機器を制御する。
【００４０】
よって、端末で未サポートの周辺機器を新たに制御する場合であっても、その周辺機器を制御するための機能を追加するコストを削減できる。
【実施例】
【００４１】
以下、具体的な実施例により本発明を説明するが、本発明の範囲は以下に説明する内容に限定されない。本実施例では、上記実施形態の制御手段１０を動作させるアプリケーションの具体例を説明する。
【００４２】
図４は、本実施例のアプリケーション構造の例を示す説明図である。本実施例のANDROID APK （application package file）６０は、TCPIP Host６１と、Usbip USB transfer worker ６２と、Usbip Command Processor ６３と、UsbipStubDriver ６４と、UsbHostApi６５と、JNI libusb６６とを含む。
【００４３】
本実施例のANDROID APK ６０、TCPIP Host６１、Usbip USB transfer worker ６２、Usbip Command Processor ６３、UsbipStubDriver ６４、UsbHostApi６５およびJNI libusb６６は、上記実施形態の制御手段１０、クライアント通信部１１、クライアント用データ作成部１２、コマンド解析部１３、処理制御部１４、標準制御処理部１５および独自制御処理部１６にそれぞれ対応する。
【００４４】
また、ANDROID APK ６０は、Windows client６８からの指示に応じて、USB Device６７を制御する。なお、本実施例のWindows client６８およびUSB Device６７は、上記実施形態のクライアント３０および周辺機器２０にそれぞれ対応する。
【００４５】
まず、USB Device６７にアクセスするため、ＵＳＢＨｏｓｔＡＰＩのUsbManagerService クラスを使用して、USB Device６７のＦＤ（ファイルディスクリプタ）が取得される。このＦＤがJNI libusb６６に渡され、通信が行われる。本実施例では、すべてのＵＳＢ転送（CONTROL,INTERRUPT,BULK,ISOCHRONOUS）は、非同期的にJNI libusb６６経由で実行される。
【００４６】
図５は、ＵＳＢ転送に用いられる構造の例を示す説明図である。図５に例示するUsbIpRequest構造には、転送結果を解析するための変数群Ｖと、アイソクロナス転送をサポートするための関数群Ｆが含まれる。なお、mSeqNum を、ＵＳＢ転送ＩＤとして使用し、mStatus をＵＳＢ転送ステータスとして使用した。
【００４７】
また、図５に例示する変数mLength 、mNumPacket、mBuffer 、mIsocDesc 、mIsocDescLenには、ＵＳＢデバイスから取得可能な情報として、それぞれOUT （出力）形式の転送データ（パケット）のバッファサイズ、データ（パケット）番号、OUT （出力）形式の転送データ（パケット）のバッファ、アイソクロナス転送データ（パケット）のバッファ、アイソクロナス転送データ（パケット）のバッファサイズが格納される。これらの変数群Ｖを返却することで、エラーの内容の解析が可能になるとともに、後述するアイソクロナス転送をサポートすることが可能になる。
【００４８】
すなわち、ANDROID APK ６０が、独自処理として、ＵＳＢデバイスから取得可能な情報を変数群Ｖに保持し、その変数を解析することによって、USB Device６７に対し、ＵＳＢＨｏｓｔＡＰＩに規定される処理以外の制御を行う。具体的には、ANDROID APK ６０は、変数群Ｖを解析することにより、上述する「非同期のＵＳＢ転送で失敗したＵＲＢを特定する」、「ＵＳＢ転送の正しいエラーコードを取得する」、「インタラプト転送の返却するバッファ長を測定する」ことが可能になる。
【００４９】
また、本実施例では、エラーコードを新たに定義した。図６は、エラーコードの例を示す説明図である。図６に例示するように、ＵＳＢエラーコードとして、正常に完了した状態を含む７種類のコードが定義され、ＵＳＢＩＰエラーコードとして、２種類のコードが定義される。
【００５０】
次に、図５に例示する関数群Ｆの内容を説明する。UsbIpRequest構造には、nativeQueueXXXXTransfer 関数（XXXXは、Control 、Int 、Bulk、Isocであり、それぞれ、コントロール転送、インタラプト転送、バルク転送、アイソクロナス転送に対応）が含まれる。この関数は、デバイスに対してＵＳＢ転送をするために用いられる。
【００５１】
この関数は、ＵＲＢが正しく処理された場合に０を返却し、そうでない場合、ＵＳＢエラーコードを返却する。引数であるsbip_reqには、ＵＳＢＩＰコマンドへの参照ＩＤとＵＳＢ転送に関する全ての情報が保持される。具体的には、mSeqnumには、ＵＳＢＩＰコマンドのシーケンス番号が保持され、mStatusには、ＵＳＢ転送のステータスが保持される。なお、エラーが発生した場合、mStatusには、ＵＳＢエラーコードが保持される。
【００５２】
さらに、UsbIpRequest構造には、nativeWaitForUrb関数が含まれる。この関数は、上述するnativeQueueXXXXTransfer 関数を経由する前に処理された完成したＵＲＢを待つために使用される。引数であるsbip_reqは、完成されたＵＲＢの返却情報である。
【００５３】
また、この関数は、ＵＲＢがエラーなく完成した場合には０を返却し、そうでない場合には、mStatus のＵＳＢエラーコードが判定される。なお、いずれの場合も、少なくともmSeqnum とmStatus の２つのフィールドには、情報が設定される。具体的には、mSeqnum には、完成したＵＲＢのシーケンス番号から変換されたＵＳＢＩＰコマンドが設定され、mStatus には、ＵＳＢエラーコードが設定される。なお、アプリケーション内で定義されたＵＳＢＩＰコマンドとシーケンス番号との紐付けは、Usbip Cmd Listモジュール（図示せず）で行われる。
【００５４】
このように、ANDROID APK ６０が、アプリケーション層において独自処理としてアイソクロナス転送を行うための処理を実装することにより、ＵＳＢＨｏｓｔＡＰＩに実装されていない処理を行うことが可能になる。
【００５５】
次に、本実施例の動作を説明する。図７および図８は、ＵＳＢ転送処理の動作例を示すシーケンス図である。ここでは、Usbip Command Processor ６３から処理が開始されるものとする（図７におけるステップＳ１）。TCPIP Host６１は、Usbip Command Processor ６３からの通知を受けて、ＵＳＢＩＰメッセージを返却する（ステップＳ２〜Ｓ３）。
【００５６】
Usbip Command Processor ６３は、ＵＲＢをUsbipStubDriver ６４に送信すると（ステップＳ４）、UsbipStubDriver ６４は、ＵＲＢをJNI libusb６６に送信し、JNI libusb６６は、ＵＲＢをUSB Device６７に送信する（ステップＳ５〜Ｓ６）。なお、このとき、JNI libusb６６は、ＵＳＢエラーコードをUsbipStubDriver ６４に返却し（ステップＳ７）、USB Device６７はＵＳＢエラーコードをJNI libusb６６に返却する（ステップＳ８）。
【００５７】
ＵＲＢの送信が成功した場合、UsbipStubDriver ６４は、Usbip Request とシーケンス番号をUsbipCmd List モジュールに送信する（ステップＳ９）。一方、エラーが発生した場合、UsbipStubDriver ６４は、Usbip Command Processor ６３にＵＳＢエラーコードを通知し（ステップＳ１０）、Usbip Command Processor ６３は、ＵＳＢＩＰエラーコードをTCPIP Host６１に通知する（ステップＳ１１）。
【００５８】
次に、Windows client６８に送信するデータを作成する処理を説明する。Usbip USB transfer worker ６２から処理が開始される（図８におけるステップＳ１２〜Ｓ１３）。Usbip USB transfer worker ６２から指示を受けたUsbipStubDriver ６４は、独自処理にてＵＳＢ転送を行う（ステップＳ１４）。
【００５９】
具体的には、JNI libusb６６が、USB Device６７に対してＵＲＢを転送し、USB Device６７からＵＳＢデータとともにＵＳＢエラーコードおよびシーケンス番号を取得し（ステップＳ１５〜Ｓ１６）、取得した情報をUsbipStubDriver ６４に送信する（ステップＳ１７）。
【００６０】
UsbipStubDriver ６４は、シーケンス番号をUsbipCmd List モジュールに送信して、Usbip Request を取得する（ステップＳ１８〜Ｓ１９）。UsbipStubDriver ６４は、Usbip Request、シーケンス番号、ＵＳＢエラーコードおよびＵＳＢデータをUsbip USB transfer worker ６２に送信し、Usbip USB transfer worker ６２は、Usbip Request、シーケンス番号、ＵＳＢＩＰエラーコードおよびＵＳＢＩＰデータを、TCPIP Host６１に送信する。（ステップＳ２０〜Ｓ２１）。
【００６１】
これらの処理をすることにより、非同期のＵＳＢ転送で失敗したＵＲＢを特定することもでき、また、ＵＳＢ転送の正しいエラーコードを取得することもできる。
【００６２】
次に、本発明の概要を説明する。図９は、本発明による周辺機器制御装置の概要を示すブロック図である。本発明による周辺機器制御装置（例えば、情報端末１００）は、接続される周辺機器（例えば、周辺機器２０）を制御する周辺機器制御装置であって、搭載されるオペレーティングシステム（例えば、Ａｎｄｒｏｉｄ）において周辺機器に対してカーネル層で行われる処理をアプリケーション層の処理で制御する制御手段８０（例えば、制御手段１０）を備えている。
【００６３】
制御手段８０は、アプリケーション層からカーネル層へアクセスする方法として予めオペレーティングシステムで提供される処理である標準処理（例えば、ＵＳＢＨｏｓｔＡＰＩ）の一部と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理に応じて、周辺機器を制御する。
【００６４】
そのような構成により、端末で未サポートの周辺機器を新たに制御する場合であっても、その周辺機器を制御するための機能を追加するコストを削減できる。
【００６５】
具体的には、周辺機器制御装置が、オペレーティングシステムとしてＡｎｄｏｒｏｉｄを搭載し、制御手段８０が、ＵＳＢＨｏｓｔＡＰＩに規定されている処理の一部（例えば、パーミッション処理）と、所望する制御の内容に応じてその制御ごとに定義される処理とを含む独自処理に応じて、接続されるＵＳＢデバイスを制御してもよい。
【００６６】
また、制御手段８０は、独自処理として、ＵＳＢデバイスから取得可能な情報を変数（例えば、変数群Ｖ）に保持し、その変数を解析することによって、標準処理以外の制御（例えば、標準未対応処理）をＵＳＢデバイスに対して行ってもよい。
【００６７】
また、制御手段８０は、アプリケーション層において独自処理としてアイソクロナス転送処理を実装してもよい。
【００６８】
また、制御手段８０は、標準処理として、ＵＳＢデバイスに対するパーミッションを確保する処理を行ってもよい。
【産業上の利用可能性】
【００６９】
本発明は、機器に接続して使用される周辺機器を制御する周辺機器制御装置に好適に適用される。例えば、教育の分野では、この周辺機器制御装置に新たに電子ペンを接続することが考えられる。また、例えば、様々な製品等を管理する場面において、この周辺機器制御装置に新たにＲＦＩＤ（Radio Frequency IDentification）リーダを接続することが考えられる。また、科学の分野では、この周辺機器制御装置に新たに顕微鏡を接続することが考えられる。
【符号の説明】
【００７０】
１０  制御手段
１１  クライアント通信部
１２  クライアント用データ作成部
１３  コマンド解析部
１４  処理制御部
１５  標準制御処理部
１６  独自制御処理部
２０  周辺機器
３０  クライアント
１００  情報端末
【図１】
2015049600.tif 000003
【図２】
2015049600.tif 000004
【図３】
2015049600.tif 000005
【図４】
2015049600.tif 000006
【図５】
2015049600.tif 000007
【図６】
2015049600.tif 000008
【図７】
2015049600.tif 000009
【図８】
2015049600.tif 000010
【図９】
2015049600.tif 000011