JP2008539484A

JP2008539484A - ユニバーサル・シリアル・バス機能のデリゲーション

Info

Publication number: JP2008539484A
Application number: JP2008508285A
Authority: JP
Inventors: デールセルフ，
Original assignee: Symbian Software Ltd
Current assignee: Symbian Software Ltd
Priority date: 2005-04-27
Filing date: 2006-04-26
Publication date: 2008-11-13
Also published as: GB0508576D0; EP1877910A1; CN101171577B; EP1877910B1; DE602006020263D1; ATE499650T1; GB2425696A; GB0608287D0; US20080195790A1; CN101171577A; WO2006114598A1

Abstract

ＵＳＢホスト機能をインプリメントする方法であり、特に、安全で柔軟性のあるＵＳＢＯｎ−Ｔｈｅ−Ｇｏのインプリメントを確実に行うように設計される。ＵＳＢホストドライバは、周辺ドライバ又は機能ドライバのコントロールに転送されるべきＵＳＢトポロジの一部分を指名することができるように構成される。この指名のプロセスは、指名された一部分に関連付けられたトークンを生成する。トークンは、ハブドライバによって周辺ドライバ又は機能ドライバに渡される。周辺ドライバ又は機能ドライバは、ＵＳＢトポロジの指名された一部分のコントロールを要求するためにトークンを用いる。トークンは、その後、必要に応じて他のソフトウエア・エンティティに転送される。
【選択図】図３

Description

本発明は、ＵＳＢＯｎ−Ｔｈｅ−Ｇｏ（ＯＴＧ）をインプリメントするために、ユニバーサル・シリアル・バス（ＵＳＢ）機能のデリゲーションを可能にする方法に関する。

ＵＳＢは、周辺デバイスをパーソナル・コンピュータ（ＰＣ）に容易に接続する方法として、１９９０年代に広く用いられていた。そのようなデバイスを接続する従前の方法は、ＰＣケースを物理的に開き、注文品のインタフェース・カードを物理的に挿入することを必要としていたか、若しくは、ＰＣ上の比較的低速なシリアル又はパラレルポートを用いていた。そのようなリソースの全ては、数が厳密に制限されていたので、比較的希少であった。その上、一般的に、それらは全て、構成するのに幾らかの技術的な専門的知識を要していた。

ＵＳＢは、本質的に、小さなローカル有線ネットワークの１つの形状であり、その中で、ＰＣは、接続された周辺デバイスと通信でき、また、接続された周辺デバイスを制御することができるホストとしてふるまう。そのことにより、高速かつ拡張性がある。また提供された「ＵＳＢネットワーク」は、ＰＣ上のＵＳＢポートに差し込まれた周辺デバイスの一般的なタイプについて知っており、自動判別を行ってデバイスを利用するように構成するだろう。

しかしながら、今日では、ＰＣにリンクするためにＵＳＢを利用するデバイスは、キーボード、マウス、スピーカ、プリンタ、スキャナ、モデムのような従来の周辺デバイスに制限されているわけではなく、極めて重要な演算能力を有する、より新しい携帯コンピューティング・デバイスにまで広がっている。そのようなデバイスとして、デジタル・カメラ、ミュージック・プレイヤ、携帯電話が含まれている。

ＵＳＢは、コンピュータが全ての周辺機器を制御する中央ホストとして常に動作する、ＰＣ中心の構成を元々想定しているため、ＰＣが存在しないと、高度なＵＳＢ周辺機器が、相互に直接通信することは、元々不可能だった。従って、全ての通信は、中心のホストＰＣを通して送られなければならなかった。しかし、そのような「よりインテリジェント」な周辺機器が、他のＵＳＢ周辺機器と独立に通信する正当な必要があるような状況が明確に存在する。
例えば、デジタル・カメラにプリンタを直接接続し通信できるようにしたり、ミュージック・プレイヤにスピーカを直接接続し通信できるようにしたりすることを望むことは不合理ではない。一方で、高度な近代の携帯電話は、プリンタ、スピーカ、ディスプレイのような出力デバイスへの直接的なアクセスからだけでなく、マイクロフォン、キーボード、スキャナのようなＵＳＢ入力デバイスの種類からも恩恵を受けているだろう。また、ＰＣだけでなく、ほとんど全ての高度な携帯コンピューティング・デバイスは、ペン・ドライブのような現代のＵＳＢストレージ・デバイスへのアクセスからも恩恵を受けることができると考えても良い。

このような高度なインテリジェント携帯周辺デバイスの発展は、元々のＵＳＢ仕様では予想されていなかった。ＵＳＢ仕様は、ホストＵＳＢ機能のより軽いインプリメンテーションを許可しておらず、また、ホストとしての機能と周辺デバイスとしての機能とを切り換えることができるデバイスを予想していなかった。

この欠陥を修正し、また、携帯コンピューティング・デバイスがＵＳＢデバイスをコントロールできるようにするために、ＵＳＢ開発者フォーラム（ＵＳＢ−ＩＦ：USB Implementers Forum,Inc.）は、ＵＳＢ用の追加仕様を発展させた。それは、「ＵＳＢＯｎ−ｔｈｅ−Ｇｏ（ＵＳＢ−ＯＴＧ）」として参照されている。この仕様は、高度な携帯コンピューティング・デバイスが、選択された他のＵＳＢ周辺機器に対して、ホストとして機能するための追加機能をインプリメントすることを可能としている。また、携帯デバイスの形状因子と限られたバッテリ寿命により適合した機械的、電気的特性（例えば、より小さなＵＳＢコネクタと低減されたバス電圧）の集合を特定している。更なる情報は、非特許文献１から見つけることができる。

ＵＳＢ−ＯＴＧ用の完全な仕様は、非特許文献２において見ることができる。この仕様の特徴の幾つかについて、図１を参照して簡単に述べる。

ＵＳＢ−ＯＴＧをサポートすることができる携帯コンピューティング・デバイスの要件は、２つの要素から成る。
・ＵＳＢホストとしてふるまい、バス上のトラフィックをコントロールする能力。
・ＵＳＢハブとしてふるまい、バスに取り付けられ、又は、取り外された機器を検出し識別する能力。

図１は、ＵＳＢ−ＯＴＧ仕様が、ＵＳＢホスト・インプリメンテーションに要求するレイヤと機能ブロックを概略的に示している。図から分かるように、ＵＳＢホスト・インプリメンテーションは、３つのブロックとして構成されている。その３つのブロックとは、ＵＳＢクライアントと、ＵＳＢシステムと、ＵＳＢバス・インタフェースである。これらのブロック間のインタフェースは、上術の仕様の範囲内において程度を変更するように定義されている。

ＵＳＢシステムのホスト・コントローラ・ドライバとＵＳＢバス・インタフェースのホスト・コントローラとの間で用いられるインタフェースは、ホスト・コントローラ・インタフェース（ＨＣＩ）として知られている。一般的に、ＨＣＩは、オープン・ホスト・コントローラ・インタフェース仕様と、ユニバーサル・ホスト・コントローラ・インタフェース仕様と、拡張ホスト・コントローラ・インタフェース仕様（ＯＨＣＩ、ＵＨＣＩ、ＥＨＣＩとして比較的それぞれ知られている）とのいずれか１つに従っている。

ホスト・コントローラ・ドライバとＵＳＢシステム機能ブロック内のＵＳＢハブドライバとの間のインタフェースは、ホスト・コントローラ・ドライバ・インタフェース（ＨＣＤＩ）として知られている任意のインタフェースである。このインタフェースは、ＵＳＢドライバ用のＨＣＩ仕様間の相違を抽象化するために用いられるオペレーティング・システム（ＯＳ）特有のインタフェースとなるように仕様において記述されている。

ＵＳＢドライバとＵＳＢクライアント間のインタフェースは、ＵＳＢドライバ・インタフェース（ＵＳＢＤＩ）として知られている。ＵＳＢＤＩは、インタフェースとデバイス構成管理のレベルへＵＳＢサービスを抽象化し、転送する。ＵＳＢＤＩは、全てのＵＳＢホスト・ソフトウエアがＵＳＢと通信する上で通るインタフェースである。

ＵＳＢＤＩは、本発明の主焦点である。

概念的には、ＵＳＢＤＩの主要なクライアントは、ハブドライバである。ハブドライバは、ＵＳＢトポロジの機能の中心であり、また、ＵＳＢ周辺機器をバスから除去し、順番に列挙することを確実にする役割を担っている。この役割には、ＵＳＢトポロジにおける変更を監視することと、それらの変更を処理するようにシステム・ソフトウエアを構成する又は構成しないこととの両方が含まれている。この関係は、図２において概念的に示されている。

ハブドライバは、ＵＳＢ管理を提供し、また、バスに取り付けられたＵＳＢ周辺機器を監視し操作するために使用可能なプリミティブを転送する。その列挙する役割の一部として、ハブドライバは、新たに取り付けられた任意のＵＳＢ周辺機器からの記述子を要求して構文分析する。これは、新たに取り付けられたＵＳＢ周辺機器の機能を利用するために、ソフトウエア・エンティティの位置を決め、ロードし活性化するために行われる。これらのソフトウエア・エンティティの位置決めとロードは、ハブドライバが、直接実行する必要はない。それは、図２にドライバ・ローダとして示されている、いくつかの他のエンティティにデリゲーション（委託）することができる。

ドライバ・ローダによってロードされたソフトウエア・エンティティは、通常、ドライバとして単純には参照されない。なぜならば、これは、既にオーバロードされた期間であるからである。それらは、図２に示すように、例えば、オペレーティング・システム（ＯＳ）のカーネルの拡張として機能するような他のタイプのドライバから識別されるために、周辺ドライバか機能ドライバのいずれかとして共通に参照される。周辺ドライバと機能ドライバとは、エンティティの２つの明確に異なるクラスであり、ＵＳＢトポロジの異なる部分を除いて、類似の役割を果たしているということも留意すべきである。

ＵＳＢトポロジの全ての部分への制限されないアクセスを許可されているハブドライバと異なり、周辺ドライバと機能ドライバは、ＵＳＢＤＩの２次的なクライアントである。なぜならば、それらは、ハブドライバによって、選択されたバスの一部分へのアクセスを許可されているからである。即ち、ＵＳＢ周辺機器全体か、若しくは、特定のＵＳＢ周辺機器の範囲内での関連インタフェース（又は、ファンクション）の集合のいずれかである。

システムにおいてＵＳＢホスト機能を有する大きな理由は、システムがＵＳＢ周辺機器を利用することを可能にするということである。しかしながら、上述のＵＳＢ入力、出力、ストレージ周辺機器の種類から明確なこととして、ＵＳＢホストシステムの範囲内において、図２で示されるような２次的なクライアントとしてでなく直接にＵＳＢと相互作用する必要があろう広範で非常に多様なオペレーティング・システム・サービスとソフトウエア・エンティティが存在する。

ＵＳＢホストと直接に相互作用する必要があるソフトウエア・エンティティの多様性は、ＵＳＢＤＩを設計する上で主要な考慮である。それは、オペレーティング・システム周りに、（特定の機能やデバイスに関する）所与のＵＳＢトポロジの様々な部分のコントロールを分配する必要を生じる。

しかしながら、ＵＳＢ仕様は、これをどのようにして実現すべきかについては、全く特定していない。期待される手法としては、単一の強力でユビキタスなＵＳＢＤＩに対してアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供することであろう。これによって、任意のデバイスの任意のインタフェースにおける任意のエンドポイントをアドレスすることが可能になり、また、それらが、どのデバイス、どのインタフェース、どのエンドポイントを制限すべきかを、様々なＵＳＢＤＩクライアントに通知することができるであろう。

あいにく、この手法は大きな欠点を有している。それは、ＵＳＢサブシステム全体を悪意があり欠陥のあるＵＳＢＤＩクライアントに公開してしまう。その結果、そのことは、ＵＳＢトポロジの所望の部分に影響を与え、サブシステムと（おそらくは）コンピューティング・デバイスの他の部分との両方を使用できなくしてしまうであろう。

もし、ＵＳＢ−ＯＴＧが設計されるための携帯型のバッテリ駆動コンピューティング・デバイスの開発が、ＰＣシステムの市場の発展と同じ経緯でなされたならば、このことはそれ程懸念事項ではないだろう。後者の場合、複数のアーキテクチャでドライバを利用できるようにするという真の商業上の必要性がなかったため、ＵＳＢは、主に、単一のコンピューティング・ハードウエア／ソフトウエア・アーキテクチャ（マイクロソフト（登録商標）ＯＳとインテル（登録商標）ＣＰＵ）用に、開発された。そのことは、ＵＳＢ周辺機器用のドライバを開発してテストする負担を軽くした。しかしながら、携帯デバイスにはその反対のことが当てはまっている。というのも、デバイスの様々なクラス（電話、カメラ、ミュージック・プレイヤを含む）においても、単一のデバイス・クラスにおける様々な製造業者においても、ソフトウエアとハードウエアのプラットフォームについて、共通の標準がないからである。

例えば、このように広範な携帯デバイスのタイプと製造業者に渡ってＵＳＢ周辺機器をサポートするように記述される必要のあるドライバが非常に多数存在するために、ＵＳＢドライバがＰＣデバイス・ドライバと同じくらい柔軟性のあるようなものになる見込みが極めて低くなっている。上述のモノリシックなアーキテクチャが根本的に安全でないことは、ＵＳＢ−ＯＴＧ仕様と勧告において、明確な欠陥を際立たせている。また、ＯＳ周辺のＵＳＢトポロジの様々な部分のコントロールの、より安全な分配を満足な形でどのように実現するかということは、即座には明らかとなっていない。
ＵＳＢ−ＩＦのウェブサイト、インターネット〈ｈｔｔｐ：／／ｗｗｗ．ｕｓｂ．ｏｒｇ／ｄｅｖｅｌｏｐｅｒｓ／ｏｎｔｈｅｇｏ／〉インターネット〈ｈｔｔｐ：／／ｗｗｗ．ｕｓｂ．ｏｒｇ／ｄｅｖｅｌｏｐｅｒｓ／ｄｏｃｓ／ｕｓｂ２０．ｚｉｐ〉

そこで、上記の点に鑑み、本発明の目的は、ＵＳＢ−ＯＴＧ機能を組み込んだ、より安全なコンピューティング・デバイスの提供を可能とすることである。

本発明の第１の態様によると、ＵＳＢルートハブを有するＵＳＢトポロジを備えたコンピューティング・デバイスに、少なくとも１つのＵＳＢ機器を接続する方法が提供される。その方法においては、ＵＳＢトポロジの一部分のコントロールは、前記ＵＳＢトポロジの一部分に関連付けられた電子トークンの提示に応じて、ソフトウエア・エンティティに許可されるのみである。

本発明の第２の態様によると、ＵＳＢルートハブを有するＵＳＢトポロジを備え、ＵＳＢトポロジの一部分のコントロールを、前記ＵＳＢトポロジの一部分に関連付けられた電子トークンの提示に応じて、ソフトウエア・エンティティに許可されるように構成されたコンピューティング・デバイスが提供される。

本発明の第３の態様によると、第１の態様の方法に従って、第２の態様についてのコンピューティング・デバイスを機能させるオペレーティング・システムが提供される。

本発明の実施形態が、更なる例によって、付随する図面を参照して、記述される。

本発明の鍵となる目的は、ＵＳＢトポロジの一部分のコントロールが、確実に、安全な方法でオペレーティング・システムにおいて動作している様々なソフトウエア・エンティティ間で分配されるようにすることである。その結果、コントロールされた方法で、正しいエンティティがＵＳＢの正しい部分をコントロールする。

このことを実現するためにハンドオーバのメカニズムが工夫されてきたこととして、ＵＳＢトポロジの定義された部分が、中央コントロール・エンティティ（即ち、図１及び２に示されるハブドライバ）から個々の機器と機能ドライバにカスケードダウンされている。

ハンドオーバのメカニズムの原理として、ＵＳＢトポロジの一部分のコントロールを現在有しているソフトウエア・エンティティが、他方のプロセスにハンドオーバされる一部分を指名することができる。このことは、ハブドライバへの要求を開始することによって実現される。それに応じて、ハブドライバは、指名された一部分を識別するために用いられる電子トークンを提示する。他のソフトウエア・エンティティ（おそらくは、デバイス上の他のプロセスで動作することができる）は、ＵＳＢトポロジの一部分のコントロールを要求するためにハブドライバに電子トークンを提示することができる。

リソースの使用の権限を与えるための電子トークンの使用は、トークンリング・ネットワーキングにおいて用いられている。トークンリング・ネットワーキングは、元々、ＩＢＭによって設計され、ＩＥＥＥ８０２．５仕様において記述されている。また、ｈｔｔｐ：／／ｓｔａｎｄａｒｄｓ．ｉｅｅｅ．ｏｒｇ／ｇｅｔｉｅｅｅ８０２／８０２．５．ｈｔｍｌから参照することができる。トークンリング・ネットワーキングにおいて、コンピュータは、共有されたネットワーク媒体上でコリジョンを回避している。それは、単一の電子トークンを現在所有するコンピュータのみがネットワーク上でデータを伝送することを許可されるという制限を実行することで実現されている。

本発明によると、トークンリング・ネットワーキングにおける単一のトークンの使用と対照的に、トークンを割り当ててコントロールを要求するという指名の原理は、システムの至るところに個別のインタフェースのコントロールを分配するための周辺ドライバのインプリメンテーションにより用いられる。このことは、単一のデバイス上での複数の機能を許可し、複合ＵＳＢ機器がサポートされることができる。

従って、ＵＳＢトポロジの一部分のコントロールを放棄することを望む所望のエンティティは、指名プロセスを繰り返して、その結果生じたトークンを他のエンティティに渡すことによって実行できる。その新しいエンティティは、元々エンティティを要求することが指名されていたものであるか、若しくは、ＵＳＢルート・ハブドライバがなることができる。

本質的に、それゆえ、ハブドライバは、周辺ドライバ又は機能ドライバのコントロールに転送されるべきＵＳＢトポロジの一部分を指名する。各指名プロセスは、指名された一部分に関連した個別のトークンを生じる。トークンは、その後、ハブドライバによって、周辺ドライバ又は機能ドライバに渡される。周辺ドライバ又は機能ドライバは、その後、ＵＳＢトポロジの指名された一部分のコントロールを要求するために、このトークンを用いることができる。

周辺ドライバと機能ドライバは、それゆえ、周辺デバイス（周辺ドライバ）を表すトークン、又は、多くのインタフェース（機能ドライバ）を表す多くのトークンが、活性化されるべきドライバに順に渡されることを通して、ハブドライバに統一されたインタフェースを提供する。

ドライバのインプリメンテーションが、ドライバのインプリメンテーションに委託されているＵＳＢトポロジの一部分を要求できるようにするために、ハブドライバは、図２に示すＵＳＢホストのドライバ・ローダを介してこれらのトークンをドライバ・インプリメンテーションに伝送することができなければならない。

このポイントについて、トークンリング・ネットワークと対照的に、本発明において、予想される２つの明確なトークンのタイプが存在することに留意すべきである。それは、周辺トークンと機能トークンである。周辺トークンは、周辺ドライバのインプリメンテーションに、特定のＵＳＢ周辺機器のコントロールを要求することを許可する。機能トークンは、機能ドライバのインプリメンテーションに、特定のＵＳＢ周辺機器上の特定のインタフェースのコントロールを要求することを許可する。

周辺ドライバは（活性化されている）、単一の有効な周辺トークンを備えていなければならない。この文脈における有効とは、ハブドライバが、転送するためのＵＳＢトポロジの一部分を既に指名していたということを意味する。

機能ドライバは（活性化されている）、少なくとも１つの有効な機能トークンを備えていなければならない。ＵＳＢ機能は、非常に多くの場合、少なくとも１つのインタフェースを含んでいる。そのような理由で、単一のトークンが常に用いられるわけではない。例えば、ＪＡＶＡ（登録商標）によって定義されているようなクラス定義のＣＤＣ（Connected Device Configuration）ファミリにおいて、常に、２つのインタフェースが存在している。１つは、コントロール・コミュニケーションにとってのインタフェースであり、１つは、データ転送にとってのインタフェースである。

これらのトークンがドライバ・コントローラからドライバ・インプリメンテーションに転送されるメカニズムは、インプリメンテーションやデバイスに大きく依存している。また、そのメカニズムは、１つのコンピューティング・デバイスと他のコンピューティング・デバイスとの間で異なっているのと同様に、単一のデバイス上でドライバ・コントローラとドライバ・コントローラとの間でも異なっている。これらのメカニズムは、それゆえ、本発明の文脈においては記述されていない。特定の構成が当業者にとって明白であり、そのようなメカニズムをインプリメントすることを望んでいることが前提とされている。しかしながら、ＵＳＢトポロジの指名された一部分を表す簡易なデータ構造を選択することが、ドライバ・コントローラからドライバ・インプリメンテーションにトークンを分配する手段を提供する好適な方法となる。

ＵＳＢのコントロールが、適切に権限を与えられたソフトウエア・エンティティに残っていることは重要である。それゆえ、例えば、ＧＢ２３８９７４７Ａに開示された能力モデルのような追加のセキュリティ・チェックは、ドライバ・インプリメンテーションがトークンを用いてコントロールを要求することによる機能に含まれている。例えば、指名の一部として、ハブドライバは、TSecurityPolicyクラスのインスタンスを有するベース・ドライバを提供する。それは、ベース・ドライバによって要求プロセスに適用され得るポリシー・チェックを表している。もし、要求プロセスがポリシー・チェックにパスすることに失敗すると、トークンを介してコントロールを担う要求は失敗するであろう。

それゆえ、上述の能力モデルの使用は、トークンの分配を実質的にリスク・フリーとするように考えられる。というのも、適切に権限が与えられたプロセスのみが、それらを利用することができるからである。それゆえ、比較的オープン型の分配メカニズムとして、例えば、「パブリッシュ・アンド・サブスクライブ（Publish and Subscribe）」は、システム周辺にトークンを分配するために好適に用いられる。

本発明における好適な実施形態において、図３に示すように、ロウ（Raw）ＵＳＢＤＩインタフェースは、３つの部分に分割される。それぞれは類似の機能を提供しているが、それぞれがＵＳＢバス・トポロジのどの部分でアドレス指定することができるかという内蔵された制約も有している。図３に示すインプリメンテーションの例においては、シンビアンソフトウエア社製の携帯電話用のシンビアンＯＳ（登録商標）用に設計されている。これらの３つのインタフェースの区分は、RRawUSBD、RRawUSBDPeripheral、RRawUSBDInterfaceとして参照される。

これらの３つのインタフェースの区分の範囲を記述する。

RRawUSBDは、ハブドライバによって単独で用いられる。それは、バス全体へのアクセスを提供するという理由で、全てのインタフェースのポーションの中で最も強力である。例えば、任意のＵＳＢ機器についてデバイス要求を実行する機能を含んでいる。ハブドライバの主要な役割の１つは、ソフトウエア構成である。それは、ＵＳＢバス・トポロジの一部分のコントロールを、ＵＳＢホスト上の他のソフトウエア・エンティティにハンドオーバすることを意味する。このことが行われることを許可するために、RRawUSBDは、どのソフトウエア・エンティティが特定の周辺機器をコントロールすべきかを指名するようにＡＰＩコールを提供する。付随的に、このソフトウエア・エンティティは、ハブドライバ自身となるであろう。

ハブドライバの他の主な役割として、ＵＳＢ機器のバスへの取り付けと取り外しを管理する。デバイス分離の管理を許可するために、ハブドライバは、特定の周辺機器に関連する全てのベースドライバのセッションを無効にするような、ベースドライバへのアクセス（RRawUSBDを介して）権限を与えられている。いくつかの他のエンティティに委任されたインタフェース又は特定の周辺デバイスのコントロールに関わらず、ハブドライバは、この能力を保有している。これは、特定の機器が、物理的又は電気的にＵＳＢトポロジから分離される場合に必要である。特に、その機器が、取り付けられた他の下流の周辺機器を伴うハブである場合に必要である。ベースドライバのセッションの無効化が意味するところとして、そのセッション上で現在未処理の全ての要求がエラーとされ、また、そのセッション上で処理されたばかりの要求もエラーとされる。

RRawUSBDPeripheralインタフェースは、ラッパークラスを通して、新しいデバイスが列挙される間、ハブドライバによって間接的に用いられる。また、例えば、ＵＳＢ周辺機器をコントロールするように指名された他のソフトウエア・エンティティによって（再度、間接的に）用いられる。それは、RRawUSBDと類似の機能を有しているが（デバイス要求を実行する能力を含む）、その使用は、特定のＵＳＢ機器に制限される。

RRawUSBDPeripheralインタフェースは、どのソフトウエア・エンティティがRRawUSBDPeripheralの特定のインスタンスが表す周辺機器をコントロールすべきかを指名するための機能を提供する。それは、また、どのソフトウエア・エンティティが同じ周辺機器に属する特定のインタフェースをコントロールすべきかを指名するための機能も提供している。

RRawUSBDInterfaceは、時折、新しいデバイスが列挙される間、ハブドライバによって、（ラッパークラスを通して間接的に）用いられる。また、ＵＳＢインタフェースをコントロールするように指名された他のソフトウエア・エンティティによって、（再度、間接的に）用いられる。それは、RRawUSBDの機能の上位集合を有している。しかしながら、その使用は、特定のＵＳＢ機器上の特定のＵＳＢインタフェースに制限される（インタフェース番号とＵＳＢ機器のアドレスとの組み合わせによって識別される）。

このインタフェースが、RRawUSBDとRRawUSBDPeripheralインタフェースのほかに提供する特別な機能として以下のものがある。それは、リード及びライト要求（ＵＳＢの専門用語では、そのような要求は、Ｉ／Ｏ要求パケット、即ち、「ＩＲＰ」として知られている）をキューイングすることに関連している。また、それは、パイプポリシーの設定（転送の前処理において特定のパイプを初期化すること）に関連しており、また、様々なインタフェースとエンドポイント関連の状態コントロール・メカニズム（例えば、ＥＰを停止する、若しくは、停止をクリアする）に関連している。

幾つかの示唆されたファンクション名と共に図３に示されたＵＳＢＩデザインを用いて、図４は、ハブドライバから別個のプロセスにおいて動作している周辺ドライバのインプリメンテーションへのＵＳＢ周辺機器のコントロールのより簡易化されたハンドオーバを示す図である。最初に、ＵＳＢホストのハブドライバは、（既に特定の周辺機器用のコントロールがどこに割り当てられるべきかということを決定している）、ファンクションコール「NominateDeviceControl()」によって、RRawIUSBDIへのデバイスコントロールを指名する。それに応じて、ハブドライバはトークンを受信する。ハブドライバは、その後、ハブドライバ・プロセスと周辺ドライバ・プロセスとの間のプロセス境界を横切るスタート（Start）コールを初期化する。周辺ドライバ・プロセスは、その後、トークンの使用を通して、周辺機器用の直接のコントロールを要求することができる。

好ましくは、周辺ドライバ又は機能ドライバは、向上された機能を提供するためにコンピューティング・デバイスのＯＳの範囲内での様々なエリアにおいて動作する必要がある。同時に、周辺ドライバ又は機能ドライバは、それらが識別されロードされ活性化される中で、標準的なインタフェースをＵＳＢのハブドライバに提供する必要がある。しかしながら、もし、ドライバが、単一のソフトウエア・エンティティと考えられる場合には、これらの要求を調整することは難しい。これら２つの要求を調整するために、ドライバは２つの部分に分割される。図５は、そのようなドライバをドライバ・コントローラとドライバ・インプリメンテーションとして参照される２つの部分に分割した例を示している。

ドライバ・コントローラは、ロードされハブドライバによって直接に用いられるドライバ部分である。ドライバのこの部分は、ドライバ検索に含まれるように、デバイスドライバ・プラグイン・メカニズムに統合する必要がある。もし、最も適切なドライバとして選択された場合には、ロード及び活性化され、非活性化及びアンロードされることができる。

ドライバ・インプリメンテーションは、幾つかの現存するＯＳフレームワークの範囲内で動作し、ＵＳＢ周辺機器の機能を全体としてＯＳに有効とするためにＵＳＢトポロジの一部分をコントロールするドライバ部分である。

図５は、ＡＣＭ（Abstract Control Model）ドライバが、どのようにして、そのような２つの部分としてインプリメントされることができるかを示している。ＡＣＭドライバは、ＵＳＢ−ＯＴＧ仕様のデータとファックス目的部分とフォーム部分との両方に用いられるデバイスクラスのプロトコルである。また、２つの部分とは、ハブドライバ・プロセスの範囲内で動作するドライバのＡＣＭホスト・ドライバ・コントローラと、Ｃ３２プロセスの範囲内で動作するＡＣＭホスト・ドライバ・コントローラである。それは、シンビアンＯＳの範囲内におけるコミュニケーション・ドライバである。ＡＣＭホスト・ドライバ・コントローラがハブドライバによって直接に用いられることを図５から見出すことができる。しかしながら、ＡＣＭホスト・ドライバ・インプリメンテーションは、ＡＣＭホスト・ドライバ・コントローラによって活性化される。従って、ＡＣＭドライバの２つの部分は、２つのプロセス間を拡張するコントロールパスによって連結されている。というのも、ドライバ・コントローラ部分は、ドライバ・インプリメンテーション部分を活性化し、非活性化する幾つかの手段を必要とするからである。それは、インプリメンテーションによって要求されたトークンをドライバ・コントローラからドライバ・インプリメンテーションに伝達することを含んでいる。ドライバ・コントローラは、それゆえ、ＯＳフレームワークの十分な知識を備えている。というのも、ドライバ・コントローラは、コントロール・パスが確立されるために、ドライバ・インプリメンテーションがどこに位置するかを知る必要があるからである。

上記の記述から見出されることとして、本発明は、ＵＳＢ−ＯＴＧテクノロジをインプリメントする好適な方法を提供する。その理由として、システム周辺において、コントロールされた機能分配を許可するからである。特に、強調されることとして、ＵＳＢ−ＯＴＧは、従来、オープン型のオペレーティング・システムにおいてインプリメントされていなかった。しかしながら、本発明は、そのようなインプリメンテーションを安全かつ確実に達成することを可能とする。上述のトークン・パッシング・メカニズムは、オペレーティング・システムの範囲内におけるプロセス間のＵＳＢトポロジの定義された一部分のコントロールを分配する手段を提供する。権限を与えられたプロセスのみが、コントロールを要求することを許可される。また、その場合においても、ＵＳＢトポロジの定義された一部分についてのみである（おそらくは、単一のＵＳＢ周辺機器又は単一のＵＳＢ機能）。

このことが、クローズ型組み込みオペレーティング・システムにとっての問題とならないであろう一方で、新しいドライバをインストールすることが可能なオープン型組み込みオペレーティング・システムにおいては、欠陥があり悪意のあるコードによるインパクトを最小限とすることは極めて重要である。ＵＳＢトポロジへのコントロールを分割し、コントロールを分配することによって、単一のＵＳＢ周辺機器又は単一のＵＳＢ機能の操作に対して、欠陥があり悪意のあるコードの有害な影響を制限することが可能となる。

本発明は、特定の実施形態を参照して記載されているが、付加された請求項により特定された本発明の範囲内において変更される場合も、本発明の範囲として考えられる。

代表的なＵＳＢホスト・インプリメンテーションの範囲内におけるレイヤと機能ブロックとを概略的に示す図である。図１に示されるＵＳＢハブドライバの役割を概略的に示す図である。本発明の実施形態に係るＵＳＢドライバ・インタフェースの機能区分を示す図である。ハブドライバから、コンピューティング・デバイス上の別個のプロセスで動作し図３に示されるＵＳＢドライバ・インタフェースの区分を用いる周辺ドライバに、ＵＳＢ周辺機器のコントロールをハンドオーバするインプリメンテーションを示す図である。ドライバ・コントローラと、本発明に係るＵＳＢ用のドライバ・インプリメンテーションとの間の区分の一例を示す図である。

Claims

ＵＳＢルートハブを有するＵＳＢトポロジを備えたコンピューティング・デバイスに少なくとも１つのＵＳＢ機器を接続する方法であって、
前記ＵＳＢトポロジの一部分のコントロールは、前記ＵＳＢトポロジの一部分に関連付けられた電子トークンの提示に応じて、ソフトウエア・エンティティに許可されるのみである方法。
前記電子トークンは、前記ＵＳＢトポロジの前記ＵＳＢルートハブから発行される、請求項１に記載の方法。
電子トークンの所有権は、
前記電子トークンを第２のソフトウエア・エンティティに提供する第１のソフトウエア・エンティティと、前記ＵＳＢルートハブに前記トークンを提示する前記第２のソフトウエア・エンティティとを用いて、
前記第１のソフトウエア・エンティティから前記第２のソフトウエア・エンティティに転送される、請求項１又は２記載の方法。
前記少なくとも１つのソフトウエア・エンティティは、プロセスと、スレッドと、クラスとを含む、請求項３に記載の方法。
第１のトークン・タイプが、ＵＳＢ周辺ドライバ用に用いられ、第２のトークン・タイプが、ＵＳＢ機能ドライバ用に用いられる、請求項１乃至４のいずれか１項に記載の方法。
エンティティは、元々指名されていた前記エンティティと、前記ＵＳＢルートハブとのいずれかに対して、前記電子トークンをハンドオーバすることにより、前記ＵＳＢトポロジの一部分のコントロールを放棄する、請求項１乃至５のいずれか１項に記載の方法。
更に、電子トークンを提示するエンティティは前記ＵＳＢトポロジの一部分のコントロールを許可されるべきということを、チェックするための能力モデルを用いる工程を備える、請求項１乃至６のいずれか１項に記載の方法。
前記電子トークンは、オープン型の分配メカニズムを使用して分配される、請求項７に記載の方法。
前記オープン型の分配メカニズムは、パブリッシュ・アンド・サブスクライブのメカニズムを含む、請求項８に記載の方法。
前記ＵＳＢトポロジは、ＵＳＢ−ＯＴＧ仕様に従ってインプリメントされる、請求項１乃至９のいずれか１項に記載の方法。
ＵＳＢルートハブを有するＵＳＢトポロジを備え、前記ＵＳＢトポロジの一部に関連付けられた電子トークンの提示に応じて、ソフトウエア・エンティティに許可されるように、前記ＵＳＢトポロジの一部分のコントロールを可能とするように構成されたコンピューティング・デバイス。
前記電子トークンは、前記ＵＳＢトポロジの前記ＵＳＢルートハブから発行される、請求項１１に記載のコンピューティング・デバイス。
電子トークンの所有権は、
前記電子トークンを第２のソフトウエア・エンティティに提供する第１のソフトウエア・エンティティと、前記ＵＳＢルートハブに前記トークンを提示する前記第２のソフトウエア・エンティティとを用いて、
前記第１のソフトウエア・エンティティから前記第２のソフトウエア・エンティティに転送される、請求項１１又は１２記載のコンピューティング・デバイス。
前記少なくとも１つのソフトウエア・エンティティは、プロセスと、スレッドと、クラスとを含む、請求項１３に記載のコンピューティング・デバイス。
第１のトークン・タイプが、ＵＳＢ周辺ドライバ用に用いられ、第２のトークン・タイプが、ＵＳＢ機能ドライバ用に用いられる、請求項１１乃至１４のいずれか１項に記載のコンピューティング・デバイス。
エンティティは、元々指名されていた前記エンティティと、前記ＵＳＢルートハブとのいずれかに対して、前記電子トークンをハンドオーバすることにより、前記ＵＳＢトポロジの一部分のコントロールを放棄する、請求項１１乃至１５のいずれか１項に記載のコンピューティング・デバイス。
電子トークンを提示するエンティティは前記ＵＳＢトポロジの一部分のコントロールを許可されるべきということをチェックするために、能力モデルが用いられる、請求項１１乃至１６のいずれか１項に記載のコンピューティング・デバイス。
前記電子トークンは、オープン型の分配メカニズムの使用を通して分配される、請求項１７に記載のコンピューティング・デバイス。
前記オープン型の分配メカニズムは、パブリッシュ・アンド・サブスクライブのメカニズムを含む、請求項１８に記載のコンピューティング・デバイス。
前記ＵＳＢトポロジは、ＵＳＢ−ＯＴＧ仕様に従ってインプリメントされる、請求項１１乃至１９のいずれか１項に記載のコンピューティング・デバイス。
携帯電話を備えた請求項１１乃至２０のいずれか１項に記載のコンピューティング・デバイス。
請求項１乃至１０のいずれか１項に記載の方法に従って、コンピューティング・デバイスを動作させるオペレーティング・システム。