(57)【要約】【課題】ＵＳＢデバイスに固有のＵＳＢクラスを駆動するドライバをＵＳＢホストにインストールすることなく、只ひとつのドライバにて複数のＵＳＢデバイスのセキュリティに対応するＵＳＢシステム装置を提供する。【解決手段】ＵＳＢ（Universal Serial Bus）インタフェースを用いて情報のやり取りをするＵＳＢシステム装置（ＵＳＢホスト１０１及びＵＳＢデバイス１０７）において、ストリングディスクリプタを用いてパスワード認証を行うようにする。これにより、ＵＳＢデバイスに固有のＵＳＢクラスを駆動するドライバをＵＳＢホストにインストールすることなく、只ひとつのドライバにて複数のＵＳＢデバイスのセキュリティに対応することができる。【選択図】図１
2010128588.tif 000002
【特許請求の範囲】
【請求項１】
ＵＳＢ（Universal Serial Bus）インタフェースを用いて情報のやり取りをするＵＳＢシステム装置において、
ストリングディスクリプタを用いてパスワード認証を行うことを特徴とするＵＳＢシステム装置。
【請求項２】
前記ストリングディスクリプタを用いたパスワード認証は、ＵＳＢホストからストリングをＵＳＢ標準リクエストを用いてＵＳＢデバイスへ伝えることを特徴とする請求項１に記載のＵＳＢシステム装置。
【請求項３】
前記ＵＳＢデバイスは、ＵＳＢホストから送られてきたパスワードが正しいもので無い場合に、その後のＵＳＢクラス動作に対して全てストール応答を行うことを特徴とする請求項２に記載のＵＳＢシステム装置。
【請求項４】
前記ＵＳＢホストは、パスワード入力機構を保有することを特徴とする請求項２または３に記載のＵＳＢシステム装置。
【請求項５】
前記ＵＳＢデバイスは、パスワード管理機構を保有することを特徴とする請求項２〜４のいずれか１項に記載のＵＳＢシステム装置。
【請求項６】
前記パスワード管理機構は、パスワード保持機構とパスワード判断機構とパスワードモード機構を保有することを特徴とする請求項５に記載のＵＳＢシステム装置。
【請求項７】
前記ＵＳＢホストは、パスワード入力機構とパスワード設定機構を保有することを特徴とする請求項２、３及び５のいずれか１項に記載のＵＳＢシステム装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＳＢインタフェースを用いて情報のやり取りをするＵＳＢシステムにおいて、ストリングディスクリプタ(String Descriptor)を用いてパスワード認証を行うことを特徴とするＵＳＢシステム装置に関する。
【背景技術】
【０００２】
近年、プリンタ、デジタルカメラ等をパーソナルコンピュータ（ＰＣ）と接続する規格としてほぼ全ての機器はＵＳＢ（Universal Serial Bus）インタフェースを保持するようになった。
【０００３】
ＵＳＢは、まさにＰＣと周辺機器を接続するために制定された規格であり、各々の機器が動作中に接続、切断が容易に行える等、利便性に優れている。
【０００４】
特にＵＳＢメモリと呼ばれているストレージ機器は、他のＰＣやデジタルカメラ、プリンタと言った機器へのデータ転送を容易にさせ、データの参照を容易にさせるために、市場における成長が著しい。
【０００５】
【特許文献１】特開２００３−１５０２８５号公報
【特許文献２】特開２００３−１８６８１９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＵＳＢメモリ等のＵＳＢ機器の発展によってデータの可搬性が向上すると共に、そのデータに対する保守性に関する要求が高まっている。すなわちＵＳＢメモリの出現により容易にデータの搬出が可能となったことで、その内部データが望まれない第三者によって簡単に閲覧される可能性が高まってしまっている。特に企業にとって前記の問題は、時に致命的な影響を及ぼすことがあり、社会的な問題となっている。
【０００７】
このような状況を鑑みて、各ＵＳＢメモリベンダはデータにアクセスする際にパスワードの入力を必要にすることで、セキュリティ対策としている。
【０００８】
特許文献１では、最初に接続される内部ＵＳＢ装置によって認証を行い、それが成功することで内部ＵＳＢ装置がストレージ機能を持ったものに切り替わることが記載されている。また、特許文献２では、ＵＳＢのインタフェースを認証用とストレージ等の実際にＵＳＢデバイス動作用の二種類を用意しておくことで、認証に成功した場合にインタフェースを切替えることが記載されている。
【０００９】
また、他にセキュリティを実現する方法としては、搭載するＵＳＢクラスに特殊なコマンドを追加して実現する方法も行われている。例えばＳＣＳＩコマンドを扱うマスストレージクラスであれば、特殊なＳＣＳＩコマンドをパスワード認証用として実装しておき、まず、そのコマンドにて認証が成功しない限りディスクデータの授受を行わない、方法がある。
【００１０】
しかし、これら前述の方法では夫々のＵＳＢデバイスで独自のＵＳＢクラスを駆動するドライバをＵＳＢホストに搭載する必要がある。すなわち、ユーザが該機能を利用するには、まず最初に夫々に対応したドライバをＵＳＢホストにインストールする必要があり、これは利用するＵＳＢデバイスの種類分必要となる。
【００１１】
本発明は前記した従来の技術の有するこのような問題に鑑みてなされたものである。その目的は、夫々のＵＳＢデバイスに固有のＵＳＢクラスを駆動するドライバをＵＳＢホストにインストールすることなく、只ひとつのドライバにて複数のＵＳＢデバイスのセキュリティに対応するＵＳＢシステム装置を提供することである。
【課題を解決するための手段】
【００１２】
本発明のＵＳＢシステム装置は、ＵＳＢ（Universal Serial Bus）インタフェースを用いて情報のやり取りをするＵＳＢシステム装置において、ストリングディスクリプタを用いてパスワード認証を行うことを特徴とする。
【発明の効果】
【００１３】
本発明によれば、夫々のＵＳＢデバイス毎にそのＵＳＢクラスを駆動するドライバをＵＳＢホストにインストールすることなく、只ひとつのドライバにて複数のＵＳＢデバイスのセキュリティに対応することが可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態を図面に基づき説明する。
（第１の実施の形態）
まず、本発明の第１の実施の形態を図１〜図７に基づき説明する。図１は、本実施の形態に係るＵＳＢ（Universal Serial Bus）ホスト／デバイスシステム装置（ＵＳＢシステム装置）における、ＵＳＢホストとＵＳＢデバイスの機器内の構成を示す概念図である。
【００１５】
同図において、１０１はＵＳＢホストである。１０２は主にソフトウェアで実装されるＵＳＢホストクラスドライバ、１０３は主にソフトウェアで実装されるＵＳＢホストドライバ、１０４はパスワード入力機構を示す。また、１０５は主にハードウェアで実装されるＵＳＢホストコントローラ、１０６はＵＳＢケーブルである。
【００１６】
１０７はＵＳＢデバイスである。１０８は主にハードウェアで実装されるＵＳＢデバイスコントローラ、１０９は主にソフトウェアで実装されるＵＳＢデバイスドライバ、１１０はパスワード保持機構、１１１はパスワード判断機構、１１２はパスワードモード機構を示す。また、１１３は１１０から１１２をまとめてパスワード管理機構、１１４は主にソフトウェアで実装されるＵＳＢデバイスクラスドライバを示している。
【００１７】
ＵＳＢホスト１０１は、ＵＳＢホストドライバ１０３がＵＳＢホストコントローラ１０５を制御することでＵＳＢホストとしての機能を提供する。この際、接続された相手機器に対してパスワード入力機構１０４が機能することでパスワードをＵＳＢ標準リクエストであるストリングディスクリプタを用いて、ＵＳＢデバイスに１０７に送信して認証を行う。認証が成功した場合にＵＳＢホストクラスドライバ１０２が動作することで実際のＵＳＢクラス機能を提供する。
【００１８】
一方、ＵＳＢデバイス１０７はＵＳＢケーブル１０６が接続されたことでＵＳＢデバイスコントローラ１０８が反応する。これをＵＳＢデバイスドライバ１０９で制御することでＵＳＢデバイスとしての機能を提供する。この際、パスワード管理機構１１３によってＵＳＢホスト１０１から受信したパスワードの認証をパスワード判断機構１１１で行い、パスワードの設定をパスワード保持機構１１０で行う。
【００１９】
これらのどちらが動作するかはパスワードモード機構１１２が制御する。以上の機構によってパスワードの認証が成功すると初めてＵＳＢデバイスクラスドライバ１１４が動作することでＵＳＢクラス機能を提供する。
【００２０】
図１は本実施の形態の一例であり、例えばＵＳＢホスト１０１に複数のＵＳＢホストクラスドライバ１０２が搭載されていても、ＵＳＢデバイス１０７に複数のＵＳＢデバイスクラスドライバ１１４が搭載されていても実施可能である。
【００２１】
また、前記各ドライバの実現方法として各々主にソフトウェアまたはハードウェアで実現する旨を記述しているが、どちらの方法で実現しても、また、その組合せで実現しても本発明に影響しない。本図に示された概念構成を取ることで本実施の形態を実現することが出来る。
【００２２】
図２は、本実施の形態に係るＵＳＢシステム装置における、パスワードの入力とパスワードの出力操作を行うＵＳＢホスト・デバイスの関係を表した概念図である。同図において２０１はＵＳＢホスト、２０２はＵＳＢケーブル、２０３はＵＳＢデバイスを示している。
【００２３】
ＵＳＢホスト２０１側のユーザインタフェースにてユーザはパスワードを入力し、それがＵＳＢケーブル２０２を介してＵＳＢデバイス２０３に送られる。ＵＳＢデバイス２０３では受信したパスワードが正しいか否かを判定することで認証を行う。この成否によってその後のＵＳＢクラス機能を提供するか否かの動作を決定することでセキュリティを実現する。
【００２４】
すなわち、ＵＳＢホスト２０１側にて最初にパスワードを入力したものを認証に用いるパスワードとしてＵＳＢデバイス２０３が保持する。さらにその保持したパスワードがＵＳＢケーブル２０２を介してＵＳＢホスト２０１へ送信されることはないことを示している。
【００２５】
図３は、本実施の形態に係るＵＳＢシステム装置における、ＵＳＢホストのハードウェア構成例を示すブロック図である。
【００２６】
同図において、３０１はＣＰＵ(中央演算処理装置)、３０２はＲＡＭ(ランダムアクセスメモリ)、３０３はＲＯＭ(リードオンリメモリ)、３０４はI／Ｏコントローラ、３０５はＵＳＢホストコントローラ、３０６はバスを示している。
【００２７】
ＵＳＢホストは、本図の３０１、および３０２、３０３、３０５、３０６により構成されるハードウェアで構成される。また必要なモジュールを自由に組み合わせることができ、例えばI／Ｏコントローラ３０４の機構等を介して他のハードウェアを付加することが
出来る。
【００２８】
また本図はあくまでも本実施の形態に係るＵＳＢホストのハードウェア構成の一例である。モジュールを単一バスで接続しない構成や、I／Ｏコントローラ３０４を介してＵＳ
Ｂホストコントローラ３０５を接続する、他のモジュールを介してモジュールを接続する等、さらには複数の演算装置にて構成する等、形態はさまざまなものが考えられる。
【００２９】
図４は、本実施の形態に係るＵＳＢホスト／デバイスシステム装置における、ＵＳＢデバイスのハードウェア構成例を示すブロック図である。
【００３０】
同図において、４０１はＣＰＵ(中央演算処理装置)、４０２はＲＡＭ(ランダムアクセスメモリ)、４０３はＲＯＭ(リードオンリメモリ)、４０４はI／Ｏコントローラ、
４０５はＵＳＢデバイスコントローラ、４０６はバスを示している。
【００３１】
ＵＳＢデバイスは本図の４０１、４０２、４０３、４０５、４０６により構成されるハードウェアで構成される。また必要なモジュールを自由に組み合わせることができ、例えば４０４の構成等を介して他のハードウェアを付加することが出来る。
【００３２】
また本図はあくまでも本実施の形態に係るＵＳＢデバイスのハードウェアの構成の例である。各モジュールを単一バスで接続しない構成やI／Ｏコントローラ４０４を介してＵ
ＳＢデバイスコントローラ４０５を接続する他のモジュールを介してモジュールを接続する等、さらには複数の演算装置にて構成する等、形態はさまざまなものが考えられる。
【００３３】
図５は、本実施の形態に係るＵＳＢシステム装置における、ＵＳＢホスト側のパスワード入力に関する処理を示している。
【００３４】
ステップＳ５０１において、ＵＳＢデバイスの接続を検知し、ステップＳ５０２へ進む。
【００３５】
ステップＳ５０２において、ＵＳＢデバイスに対してＵＳＢアドレスを割り当てるためにＳｅｔＡｄｄｒｅｓｓ標準リクエストの一連の処理を行い、ステップＳ５０３へ進む。
【００３６】
ステップＳ５０３において、ＵＳＢデバイスに対してＤｅｖｉｃｅに関するＧｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストの一連の処理を行い、ステップＳ５０４へ進む。
【００３７】
ステップＳ５０４において、ＵＳＢデバイスに対してＣｏｎｆｉｇｕｒａｔｉｏｎに関するＧｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストの一連の処理を行い、ステップＳ５０５へ進む。
【００３８】
ステップＳ５０５において、ＵＳＢホストが保有しているパスワード入力機構を介してユーザがパスワードを入力し、ステップＳ５０６へ進む。
【００３９】
ステップＳ５０６において、入力されたパスワードをＳｔｒｉｎｇに関するＳｅｔＤｅｓｃｒｉｐｔｏｒの一連の処理を行い、ステップＳ５０７へ進む。
【００４０】
ステップＳ５０７において、ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎの一連の処理を行い、ステップＳ５０８へ進む。
【００４１】
ステップＳ５０８において、ＵＳＢクラスの動作を行い、ＵＳＢホスト側のパスワード入力に関する処理を終了する。
【００４２】
本図では、ステップＳ５０２、Ｓ５０３、Ｓ５０４、Ｓ５０６、Ｓ５０７においてＵＳＢデバイスがストール(ｓｔａｌｌ)応答を行った際の処理に関しては省略してある。一般的にストール応答を受け取った後の動作は、ＵＳＢリセットの後に再接続を試みる、またはそのまま応答をしない、等のエラー処理が行われる。しかしどのようなエラー処理を行うかは本発明に係る本質に影響をあたえない。
【００４３】
また、ステップＳ５０５において、ユーザによるパスワードの入力処理を行うが、この際のエラー処理に関しては本図で言及していない。何度かのパスワード入力失敗を経てパスワード入力処理を終了してしまう方法や、何度も入力を繰り返す、またはその組合せなどのエラー処理が考えられる。さらに、ＵＳＢ接続を再接続しなければ再びパスワードを入力できなくしてしまう方法や、物理的な再接続は行わないがＵＳＢバスリセットにより再度パスワード入力処理を行うなど種々の実現方法が考えられる。これについてもどのようなエラー処理を行っても本発明に係る本質に影響をあたえない。
【００４４】
また、ステップＳ５０６において、Ｓｔｒｉｎｇに関するＳｅｔＤｅｓｃｒｉｐｔｏｒに対する一連の処理を行うが、この際に利用するストリングディスクリプタのＩＤには、幾つかの実現方法がある。そのひとつとして、ある固定のＩＤをパスワード専用のＩＤとして決め打ちそのＩＤでストリングディスクリプタを送信する方法がある。
【００４５】
この場合パスワード専用の固定のＩＤはその他の用途には利用できない。もしくはＤｅｖｉｃｅ ＤｅｓｃｒｉｐｔｏｒやＣｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ等に該当するＩＤを利用されていた場合、本発明に対応しないＵＳＢデバイスとして認識することが出来る。
【００４６】
別のひとつとして、Ｄｅｖｉｃｅ ＤｅｓｃｒｉｐｔｏｒやＣｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ等のストリングディスクリプタ ＩＤを格納する場所にパスワード専用のＩＤを記述する。そのＩＤに対してＵＳＢホストがＧｅｔＤｅｓｃｒｉｐｔｏｒを行うと、ある決められた文字列がＵＳＢホストに送られることでＵＳＢホストがそのＩＤをパスワード専用のストリングディスクリプタとして扱うように実装することもできる。
【００４７】
この場合、ステップＳ５０６において、いくつかのストリングディスクリプタＩＤに対するＧｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストをＵＳＢホストが発行することでパスワード専用のＩＤが何番であるかを調査する処理が必要になる。あるいは別のひとつとして、Ｄｅｖｉｃｅ ＤｅｓｃｒｉｐｔｏｒやＣｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ等に表れないストリングディスクリプタのＩＤをパスワード専用のＩＤとして扱う方法も考えられる。
【００４８】
ＵＳＢホストはＵＳＢデバイスのもつＤｅｓｃｒｉｐｔｏｒ全てを接続初期に取得を行い、それに対して利用されているストリングディスクリプタのＩＤを調査する。ＵＳＢホストはこれに表れないＩＤをパスワード専用のＩＤとしてステップＳ５０６にて利用する。本図では、ＵＳＢデバイス接続時のエニュメレーション処理を説明している。ＵＳＢデバイス接続時のエニュメレーションはそれぞれの機器の都合でいくつかの処理を重複させたり、他の標準リクエストを加えたり、あるいはある標準リクエストを省くことが可能である。本発明では本図と全く同じエニュメレーションを行う必要はなく、本図どおりでなくても本発明を実現可能である。重要なのはユーザによって与えられたパスワードをパスワード専用のＩＤを持つストリングディスクリプタにＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストにてＵＳＢデバイスへ伝達することである。
【００４９】
図６は、本実施の形態に係るＵＳＢシステム装置における、ＵＳＢデバイス側のパスワード受信に関する処理を示している。
【００５０】
ステップＳ６０１において、ＵＳＢホストへ接続が行われ、ステップＳ６０２へ進む。
【００５１】
ステップＳ６０２において、接続時の一連のエニュメレーションに対して応答を行い、ステップＳ６０３へ進む。
【００５２】
ステップＳ６０３において、パスワード専用のＩＤに対するストリングディスクリプタへのＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストを受信し、ステップＳ６０４へ進む。
【００５３】
ステップＳ６０４において、パスワードモード機構からパスワード設定モードか否かを判断し、パスワード設定モードの場合はステップＳ６０５へ、パスワード設定モードでない場合はステップＳ６０８へ進む。
【００５４】
ステップＳ６０５において、受信したストリングディスクリプタの文字列をパスワードとしてパスワード保持機構にデータ保存しａｃｋ応答を行い、ステップＳ６０６へ進む。
【００５５】
ステップＳ６０６において、ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ標準リクエストに対する一連の処理を行い、ステップＳ６０７へ進む。
【００５６】
ステップＳ６０７において、ＵＳＢクラス動作を行い、ＵＳＢデバイス側のパスワード受信に関する処理を終了する。
【００５７】
一方、ステップＳ６０８においては、受信したパスワードがパスワード保持機構に保持されているデータと同一か否かをパスワード判断機構にて判断する。データが同一の場合はステップＳ６０６へ進み、データが同一でない場合はステップＳ６０９へ進む。
【００５８】
ステップＳ６０９では以降のＵＳＢホストからの通信に対してＳｔａｌｌ応答を行い、ＵＳＢデバイス側のパスワード受信に関する処理を終了する。
【００５９】
なお、ステップＳ６０２、Ｓ６０３、Ｓ６０６においてストール応答を行わなければならないようなデータをＵＳＢホストが送信した際の処理に関しては省略してある。一般的にストール応答を送信した場合の動作は、ＵＳＢリセットが行われたり、またはその後の通信が行われなくなる、等のエラー処理がＵＳＢホストによって行われる。しかしどのようなエラー処理が行われても本発明に係る本質に影響を与えない。
【００６０】
また、ステップＳ６０４において利用するパスワード設定モードはＵＳＢデバイスのユーザI／Ｏ等で実現する。ユーザがパスワード設定モードに移行させるにはセキュリティ
として保護しなければならないデータは自動で消去するか、消去されることを明示する等してユーザに通告する。あるいはセキュリティ情報を作成する際に消去不可の設定を行えるようにしておき、この場合にはそのセキュリティ情報に対してＵＳＢクラスにて消去不可の設定を解除しない限りパスワード設定モードに移行できないように構築する。
【００６１】
図７は、本実施の形態に係るＵＳＢシステム装置における、パスワード処理を含めた接続時のエニュメレーション処理例を示している。
【００６２】
本図では接続時のエニュメレーションとしてＳｅｔＡｄｄｒｅｓｓ標準リクエストによりＵＳＢデバイスにアドレスを割り当てた後、デバイスディスクリプタ、コンフィギュレーションディスクリプタの順にＧｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストを発行する。これによりＵＳＢデバイス情報をＵＳＢホストが取得している。
【００６３】
前述したパスワード専用のストリングディスクリプタＩＤの決定方法によっては、この段階でＵＳＢデバイスが指定するパスワード専用のストリングディスクリプタＩＤが決定する。
【００６４】
次にパスワード専用のストリングディスクリプタに対してＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストを実行することでパスワード認証を行っている。認証に成功した後、ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ標準リクエストによってＵＳＢデバイスの動作させるコンフィギュレーションを指定することでＵＳＢクラスが機能する。
【００６５】
先に述べたように本図はパスワード処理を含めた接続時のエニュメレーション処理例であり、実際にはこの順序でなくとも、あるいは他の通信を間にはさんでいても、あるいは一部の処理が省略されていても、本発明の実施は可能である。
【００６６】
前記の意味するところは、当然パスワード専用のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストの発行タイミングも変更可能であることである。つまり先に述べたパスワード専用のストリングディスクリプタＩＤの決定方法によっては、ます最初にパスワード専用のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストを発行することも可能である。
【００６７】
以上のように実装することで、ストリングディスクリプタ（Ｓｔｒｉｎｇ Ｄｅｓｃｒｉｐｔｏｒ)を用いてパスワード認証を行うことを特徴とするＵＳＢホスト／デバイスシステム装置を構築できる。
【００６８】
さらに、ＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストによるパスワード認証で転送する文字列に暗号化を施すことも可能である。この際、言語ＩＤを無視するような形態に実装したり、逆に暗号化に利用したりすることも可能である。また、本発明に対応していないＵＳＢデバイスを本発明のＵＳＢホストに接続した場合もＵＳＢシステムとして問題はない。
【００６９】
パスワード専用のストリングディスクリプタＩＤに対してＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストが成功、不成功にかかわらず、ＵＳＢデバイスであればその後のＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ標準リクエスト、クラス動作に付いて不具合もなく動作する。
【００７０】
別の方法としては、ＵＳＢホストはＵＳＢデバイスのデバイスＩＤやプロダクトＩＤ等の情報であらかじめパスワードが必要か否かの情報を保持しておけば、本発明に対応していないＵＳＢデバイスが接続された場合にパスワード認証を行わなくて済む。
【００７１】
さらに、本発明に対応していないＵＳＢホストに本発明のＵＳＢデバイスを接続した場合もＵＳＢシステムとして問題はない。本発明に対応していないＵＳＢホストはパスワード認証に係る処理をなんらせずにＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎを経てクラス動作を行おうとする。
【００７２】
この際、本発明のＵＳＢデバイスはパスワード認証が行われていないのでＳｅｔＣｏｎｆｉｇｕｒａｉｔｏｎ及びその後のクラス動作に対するＵＳＢホストからの通信に対して全てストール応答を行うため、セキュリティは守られる。
【００７３】
（第２の実施の形態）
次に、本発明の第２の実施の形態を図８〜図１１に基づき説明する。図８は、本実施の形態に係るＵＳＢホスト／デバイスシステム装置（ＵＳＢシステム装置）における、ＵＳＢホストとＵＳＢデバイスの機器内の構成を示す概念図である。
【００７４】
同図において、８０１はＵＳＢホストである。８０２は主にソフトウェアで実装されるＵＳＢホストクラスドライバ、８０３は主にソフトウェアで実装されるＵＳＢホストドライバ、８０４はパスワード入力機構を示す。また、８０５はパスワード設定機構、８０６は主にハードウェアで実装されるＵＳＢホストコントローラ、８０７はＵＳＢケーブルである。
【００７５】
８０８はＵＳＢデバイスである。８０９は主にハードウェアで実装されるＵＳＢデバイスコントローラを示す。８１０は主にソフトウェアで実装されるＵＳＢデバイスドライバ、８１１はパスワード保持機構、８１２はパスワード判断機構を示す。また、８１３は８１１と８１２を合わせてパスワード管理機構、８１４は主にソフトウェアで実装されるＵＳＢデバイスクラスドライバを示している。
【００７６】
ＵＳＢホスト８０１は、ＵＳＢホストドライバ８０３がＵＳＢホストコントローラ８０６を制御することでＵＳＢホストとしての機能を提供する。この際、接続された相手機器に対してパスワード入力機構８０４が機能することでパスワードをストリングディスクリプタを用いてＵＳＢデバイスに送信することで認証を行う。さらにパスワード設定機構８０５が機能することで新たにパスワードを設定することが出来る。パスワード認証が成功した後にＵＳＢホストクラスドライバ８０２が動作することで実際のＵＳＢクラス機能を提供する。
【００７７】
一方、ＵＳＢデバイス８０８はＵＳＢケーブル８０７が接続されることでＵＳＢデバイスコントローラ８０９が反応する。これをＵＳＢデバイスドライバ８１０で制御することでＵＳＢデバイスとしての機能を提供する。この際、パスワード管理機構８１３によってＵＳＢホスト８０１から受信したパスワードの認証をパスワード判断機構８１２で行い、設定されたパスワードの保持をパスワード保持機構８１１で行う。パスワード認証が成功すると始めてＵＳＢデバイスクラスドライバ８１４が動作することでＵＳＢクラス機能を提供する。
【００７８】
図８は本実施の形態の一例であり、例えばＵＳＢホスト８０１に複数のＵＳＢホストクラスドライバ８０２が搭載されていても、ＵＳＢデバイス８０８に複数のＵＳＢデバイスクラスドライバ８１４が搭載されていても実施可能である。本図に示された概念構成を取ることで本実施の形態を実現することが出来る。
【００７９】
図９は、本実施の形態に係るＵＳＢシステム装置における、ＵＳＢホスト側のパスワード入力に関する処理を示している。
【００８０】
ステップＳ９０１において、ＵＳＢデバイスの接続を検知し、ステップＳ９０２へ進む。
【００８１】
ステップＳ９０２において、各標準リクエストの送信を行い、ステップＳ９０３へ進む。
【００８２】
ステップＳ９０３において、ＵＳＢホストが保有しているパスワード入力機構を介してユーザがパスワードを入力、ステップＳ９０４へ進む。
【００８３】
ステップＳ９０４において、入力されたパスワードをＳｔｒｉｎｇに関するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストの一連の処理を行い、ステップＳ９０５へ進む。
【００８４】
ステップＳ９０５において、ＳｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ標準リクエストの一連の処理を行い、ステップＳ９０６へ進む。
【００８５】
ステップＳ９０６において、ＵＳＢデバイスからストールを受信したか否かを判断する。ストールを受信した場合はステップＳ９０３へ進み、ストールを受信していない場合はステップＳ９０７へ進む。
【００８６】
ステップＳ９０７において、ＵＳＢクラス動作を行い、ＵＳＢホスト側のパスワード入力に関する処理を終了する。
【００８７】
本図では、ステップＳ９０２、ステップＳ９０６においてＵＳＢデバイスがストール応答を行った際の処理に関しては省略してある。一般的にストール応答を受け取った後の動作は、ＵＳＢリセットの後に再接続を試みる、またはそのまま応答をしない、等のエラー処理が行われる。しかしどのようなエラー処理を行うかは本発明に係る本質に影響をあたえない。
【００８８】
また、ステップＳ９０５において、ユーザによるパスワードの入力処理を行うが、この際のエラー処理に関しては本図で言及していない。何度かのパスワード入力失敗を経てパスワード入力処理を終了してしまう方法や、何度も入力を繰り返す、またはその組合せなどのエラー処理が考えられる。
【００８９】
さらに、ＵＳＢ接続を再接続しなければ再びパスワードを入力できなくしてしまう方法や、物理的な再接続は行わないがＵＳＢバスリセットにより再度パスワード入力処理を行う等、種々の実現方法が考えられる。これについてもどのようなエラー処理を行っても本発明に係る本質の何者にも影響をあたえない。
【００９０】
ステップＳ９０４において、Ｓｔｒｉｎｇに関するＳｅｔＤｅｓｃｒｉｐｔｏｒに対する一連の処理を行うが、この際に利用するストリングディスクリプタのＩＤには、幾つかの実現方法があり、これについては第１の実施形態と同様である。
【００９１】
図１０は、本実施の形態に係るＵＳＢシステム装置における、ＵＳＢホスト側のパスワードを設定に関する処理を示している。
【００９２】
ステップＳ１００１において、パスワード設定機構によってパスワードとして用いる文字列をユーザにより入力し、ステップＳ１００２へ進む。
【００９３】
ステップＳ１００２において、ステップＳ１００１で入力された文字列を持ってパスワード設定専用のストリングディスクリプタＩＤに関するＳｅｔＤｅｓｃｒｉｐｔｏｒを送信し、ステップＳ１００３へ進む。
【００９４】
ステップＳ１００３において、ＵＳＢデバイスからストールを受信したか否かを判断する。ストールを受信した場合はステップＳ１００５へ進み、ストールを受信していない場合はステップＳ１００４へ進む。
【００９５】
ステップＳ１００４において、パスワードの設定に成功したことをユーザへ通知し、ＵＳＢホスト側のパスワード設定に関する処理を終了する。
【００９６】
ステップＳ１００５において、パスワード設定に失敗したことをユーザへ通知し、ＵＳＢホスト側のパスワード設定に関する処理を終了する。
【００９７】
本図の処理は、必ず図９のＵＳＢホスト側のパスワード入力に関する処理の後に行わなければならない。それ以前に行うと、ステップＳ１００３において必ずストールをＵＳＢデバイスから受信することになる。
【００９８】
ステップＳ１００２において、Ｓｔｒｉｎｇに関するＳｅｔＤｅｓｃｒｉｐｔｏｒに対する一連の処理を行うが、この際に利用するストリングディスクリプタのＩＤには、幾つかの実現方法がある。その方法は第一の実施形態で述べたパスワード入力専用ＩＤの実現方法に同じである。ただし、パスワード設定専用のＩＤとパスワード入力専用のＩＤは別の値で実現する。
【００９９】
図１１は、本実施の形態に係るＵＳＢシステム装置における、ＵＳＢデバイス側のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストに関する処理を示している。
【０１００】
ステップＳ１１０１において、ストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒを受信し、ステップＳ１１０２へ進む。
【０１０１】
ステップＳ１１０２において、ストリングディスクリプタのＩＤがパスワード設定専用のＩＤか否かを判断する。パスワード設定専用のＩＤ場合はステップＳ１１０３へ進み、パスワード設定専用のＩＤでない場合はステップＳ１１０６へ進む。
【０１０２】
ステップＳ１１０３において、既にパスワード認証済みであるか否かを判断する。既にパスワード認証済みである場合はステップＳ１１０４へ進み、パスワード認証がなされていない場合はステップＳ１１０５へ進む。
【０１０３】
ステップＳ１１０４において、パスワード保持機構にＵＳＢデバイスから送信されたストリングディスクリプタの文字列を保持し、ＵＳＢデバイス側のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストに関する処理を終了する。
【０１０４】
ステップＳ１１０５において、ＵＳＢホストへストール応答をし、ＵＳＢデバイス側のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストに関する処理を終了する。
【０１０５】
ステップＳ１１０６において、ストリングディスクリプタのＩＤがパスワード入力専用のＩＤか否かを判断する。パスワード入力専用のＩＤの場合はステップＳ１１０８へ進み、パスワード入力専用のＩＤでない場合はステップＳ１１０７へ進む。
【０１０６】
ステップＳ１１０７において、パスワードに関連しないその他のストリングディスクリプタへの操作として動作し、ＵＳＢデバイス側のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストに関する処理を終了する。
【０１０７】
ステップＳ１１０８において、パスワード保持機構に保持されている文字列と受信したストリングディスクリプタの文字列とをパスワード判断機構で比較し、一致しているか否かを判断する。
【０１０８】
一致していない場合はステップＳ１１０５へ進み、一致している場合はＵＳＢデバイス側のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストに関する処理を終了する。
【０１０９】
以上のように実装することで、ストリングディスクリプタ(String Descriptor)を用いてパスワード認証を行うことを特徴とするＵＳＢホスト／デバイスシステム装置を構築できる。
【０１１０】
なお、本実施の形態に係るその他の構成及び動作は、前述した第１の実施の形態と同じであることから、その説明は省略する。
【産業上の利用可能性】
【０１１１】
ＵＳＢインタフェースを用いて情報のやり取りをするＵＳＢシステムにおいて、パスワード認証を行うＵＳＢホスト/デバイスシステム装置として利用できる。
【図面の簡単な説明】
【０１１２】
【図１】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢホストとＵＳＢデバイスの機器内の構成を示す概念図である。
【図２】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、パスワードの入力とパスワードの出力操作を行うＵＳＢホスト・デバイスの関係を表した概念図である。
【図３】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢホストのハードウェア構成例を示すブロック図である。
【図４】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢデバイスのハードウェア構成例を示すブロック図である。
【図５】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢホスト側のパスワード入力に関する処理を示したフローチャートである。
【図６】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢデバイス側のパスワード受信に関する処理を示したフローチャートである。
【図７】本発明の第１の実施形態に係るＵＳＢホスト/デバイスシステム装置における、パスワード処理を含めた接続時のエニュメレーション処理例を示した図である。
【図８】本発明の第２の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢホストとＵＳＢデバイスの機器内の構成を示す概念図である。
【図９】本発明の第２の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢホスト側のパスワード入力に関する処理を示したフローチャートである。
【図１０】本発明の第２の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢホスト側のパスワードの設定に関する処理を示したフローチャートである。
【図１１】本発明の第２の実施形態に係るＵＳＢホスト/デバイスシステム装置における、ＵＳＢデバイス側のストリングディスクリプタに対するＳｅｔＤｅｓｃｒｉｐｔｏｒ標準リクエストに関する処理を示したフローチャートである。
【符号の説明】
【０１１３】
１０１，８０１  ＵＳＢホスト
１０２，８０２  ＵＳＢホストクラスドライバ
１０３，８０３  ＵＳＢホストドライバ
１０４，８０４  パスワード入力機構
１０５，８０６  ＵＳＢホストコントローラ
１０６，８０７  ＵＳＢケーブル
１０７，８０８  ＵＳＢデバイス
１０８，８０９  ＵＳＢデバイスコントローラ
１０９，８１０  ＵＳＢデバイスドライバ
１１０，８１１  パスワード保持機構
１１１，８１２  パスワード判断機構
１１２  パスワードモード機構
１１３，８１３  パスワード管理機構
１１４，８１４  ＵＳＢデバイスクラスドライバ
２０１  ＵＳＢホスト
２０２  ＵＳＢケーブル
２０３  ＵＳＢデバイス
３０１  ＣＰＵ(中央演算処理装置)
８０５  パスワード設定機構
【図１】
2010128588.tif 000003
【図２】
2010128588.tif 000004
【図３】
2010128588.tif 000005
【図４】
2010128588.tif 000006
【図５】
2010128588.tif 000007
【図６】
2010128588.tif 000008
【図７】
2010128588.tif 000009
【図８】
2010128588.tif 000010
【図９】
2010128588.tif 000011
【図１０】
2010128588.tif 000012
【図１１】
2010128588.tif 000013