(57)【要約】  本発明はプロトコル・スタックを通過するパケット・フローを制御する改良された方法及びシステムを提供する。このシステムは各スタック・レイヤのインターフェイスとなるレイヤ・マネージャーを有する。レイヤ・マネージャーはスタック・レイヤへのパケット・フローを処理する。サポートされる新規のパケット・パスに対して、スタック・レイヤではなく、レイヤ・マネージャーのみが修正される必要がある。これにより、プロトコル・スタックにおいてより容易にレイヤを実行することができる。もう一つ別の実施形態においては、レイヤ・マネージャーはサポートされるサービスに対応する複数のプロトコル記述子リストを備え、そしてこれらのリストを使用してパケットを適切なスタック・レイヤにルーティングする。この別の実施形態により、新規のスタック・レイヤをプロトコル・スタックに、現存のスタック・レイヤを修正する必要を生じることなく挿入することができる。
2005509318.tif 000002
【特許請求の範囲】
【請求項１】
プロトコル・スタックを通過するパケットをルーティングする方法であって、
（ａ）前記プロトコル・スタックの第１スタック・レイヤからパケットを前記プロトコル・スタックの各レイヤのインターフェイスとなるレイヤ・マネージャーにより受け取る工程と、
（ｂ）前記パケットのルートを前記レイヤ・マネージャーにより決定する工程と、そして（ｃ）前記パケットを前記レイヤ・マネージャーにより決定された前記ルートに従って前記プロトコル・スタックの第２スタック・レイヤにルーティングする工程と、
を有する方法。
【請求項２】
前記決定する工程（ｂ）は、
（ｂ１）前記レイヤ・マネージャーのハードコードを利用して前記パケットの前記ルートを前記レイヤ・マネージャーにより決定する工程を有する請求項１記載の方法。
【請求項３】
前記決定する工程（ｂ）は、
（ｂ１）前記パケットに関連するサービスを前記レイヤ・マネージャーにより判断する工程と、そして
（ｂ２）前記サービスに対応する前記プロトコル・スタックのレイヤのリストに前記レイヤ・マネージャーによりアクセスする工程と、を有する請求項１記載の方法。
【請求項４】
前記判断する工程（ｂ１）は、
（ｂ１ｉ）前記パケット中のプロトコル／サービス・マルチプレクサ（ＰＳＭ）フィールドを前記レイヤ・マネージャーにより調査する工程と、そして
（ｂ１ｉｉ）前記ＰＳＭフィールドが参照するプロトコル記述子リスト（ＰＤＬ）を前記レイヤ・マネージャーにより決定する工程と、を有する請求項３記載の方法。
【請求項５】
前記アクセスする工程（ｂ２）は、
（ｂ２ｉ）前記サービスに対応するＰＤＬに前記レイヤ・マネージャーによりアクセスする工程を有する請求項３記載の方法。
【請求項６】
前記決定する工程（ｂ）はさらに、
（ｂ１）インストゥルメンテーション情報を得るために前記パケットを前記レイヤ・マネージャーにより解析する工程を有する請求項１記載の方法。
【請求項７】
前記受け取る工程（ａ）は、
（ａ１）リクエストを前記レイヤ・マネージャーにより受け取って前記プロトコル・スタックの前記第２レイヤで動作を実行する工程を有する請求項１記載の方法。
【請求項８】
前記受け取る工程（ａ１）は、
（ａ１ｉ）前記リクエストを前記レイヤ・マネージャーにより受け取ってオブジェクトに対する動作をサブジェクトにより前記プロトコル・スタックの前記第２レイヤで実行する工程を有する請求項７記載の方法。
【請求項９】
前記決定する工程（ｂ）は、
（ｂ１）アクセス仲介を前記レイヤ・マネージャーにより呼び出す工程と、
（ｂ２）前記第２レイヤで動作を実行するためのリクエストが前記アクセス仲介により所定の安全方針に基づいて受け入れられるかどうかを判断する工程と、そして
（ｂ３）前記判断を前記レイヤ・マネージャーに供給する工程と、
を有する請求項１記載の方法。
【請求項１０】
前記呼び出す工程（ｂ１）は、
（ｂ１ｉ）サブジェクトの一致、オブジェクトの一致、及びリクエストされた動作を前記アクセス仲介に通す工程を有する請求項９記載の方法。
【請求項１１】
前記ルーティングする工程（ｃ）はさらに、
（ｃ１）アクセス仲介による判断により前記動作を実行するためのリクエストを受け入れようとする場合、前記第２レイヤでの前記動作を実行可能とする工程と、そして
（ｃ２）前記判断により前記リクエストを受け入れない場合、前記動作を阻止する工程と、を有する請求項１記載の方法。
【請求項１２】
複数のスタック・レイヤと、そして
前記複数のスタック・レイヤの各々のインターフェイスとなり、前記複数のスタック・レイヤを通過するパケットをルーティングするレイヤ・マネージャーと、
を備えるシステム。
【請求項１３】
前記レイヤ・マネージャーはサービスに対応するスタック・レイヤのリストを有し、前記レイヤ・マネージャーは前記リストに従ってパケットを前記複数のスタック・レイヤの内の一つにルーティングする請求項１２記載のシステム。
【請求項１４】
前記レイヤ・マネージャーによる前記パケットの前記ルーティングは、
（ａ）前記パケットを受け取る工程と、
（ｂ）前記パケットに関連する前記サービスを判断する工程と、
（ｃ）前記サービスに対応する前記プロトコル・スタックの前記レイヤリストにアクセスする工程と、そして
（ｄ）前記リストに従って前記パケットを前記複数のレイヤの内の一つにルーティングする工程と、
を有する請求項１３記載のシステム。
【請求項１５】
前記決定する工程（ｂ）は、
（ｂ１）前記パケット中のＰＳＭフィールドを調査する工程と、そして
（ｂ２）前記ＰＳＭフィールドが参照するＰＤＬを決定する工程と、
を有する請求項１４記載のシステム。
【請求項１６】
前記アクセスする工程（ｃ）は、
（ｃ１）前記サービスに対応するＰＤＬにアクセスする工程を有する請求項１４記載のシステム。
【請求項１７】
前記レイヤ・マネージャーがインストゥルメントされ、前記レイヤ・マネージャーをインストゥルメントすることにより前記複数のスタック・レイヤをインストゥルメントする請求項１２記載のシステム。
【請求項１８】
前記レイヤ・マネージャーはアクセス仲介を備え、前記レイヤ・マネージャーは前記アクセス仲介を呼び出して前記複数のスタック・レイヤの内の一つで動作を実行するためのリクエストが受け入れられるかどうかを判断する請求項１２記載のシステム。
【請求項１９】
プロトコル・スタックを通過するパケットをルーティングするプログラム命令を備えるコンピュータ読取可能な媒体であって、前記命令により、
（ａ）前記プロトコル・スタックの各レイヤのインターフェイスとなるレイヤ・マネージャーにより前記プロトコル・スタックの内の第１スタック・レイヤからパケットを受け取
り、
（ｂ）前記パケットのルートを前記レイヤ・マネージャーにより決定し、そして
（ｃ）前記レイヤ・マネージャーにより決定された前記ルートに従って、前記パケットを前記プロトコル・スタックの内の第２スタック・レイヤにルーティングする、
媒体。
【請求項２０】
前記決定する命令（ｂ）は、
（ｂ１）前記レイヤ・マネージャーのハードコードを利用して前記パケットの前記ルートを前記レイヤ・マネージャーにより決定する、命令を含む請求項１９記載の媒体。
【請求項２１】
前記決定する命令（ｂ）は、
（ｂ１）前記パケットに関連するサービスを前記レイヤ・マネージャーにより判断し、そして
（ｂ２）前記サービスに対応する前記プロトコル・スタックのレイヤのリストに前記レイヤ・マネージャーによりアクセスする、命令を含む請求項２１記載の媒体。
【請求項２２】
前記判断する命令（ｂ１）は、
（ｂ１ｉ）前記パケット中のプロトコル／サービス・マルチプレクサ（ＰＳＭ）フィールドを前記レイヤ・マネージャーにより調査し、そして
（ｂ１ｉｉ）前記ＰＳＭフィールドが参照するプロトコル記述子リスト（ＰＤＬ）を前記レイヤ・マネージャーにより決定する、命令を含む請求項２１記載の媒体。
【請求項２３】
前記アクセスする命令（ｂ２）は、
（ｂ２ｉ）前記サービスに対応するＰＤＬに前記レイヤ・マネージャーによりアクセスする、命令を含む請求項２１記載の媒体。
【請求項２４】
前記決定する命令（ｂ）はさらに、
（ｂ１）インストゥルメンテーション情報を得るために前記パケットを前記レイヤ・マネージャーにより解析する、命令を含む請求項１９記載の媒体。
【請求項２５】
前記受け取る命令（ａ）は、
（ａ１）リクエストを前記レイヤ・マネージャーにより受け取って前記プロトコル・スタックの前記第２レイヤで動作を実行する、命令を含む請求項１９記載の媒体。
【請求項２６】
前記受け取る命令（ａ１）は、
（ａ１ｉ）前記リクエストを前記レイヤ・マネージャーにより受け取ってオブジェクトに対する動作をサブジェクトにより前記プロトコル・スタックの前記第２レイヤで実行する、命令を含む請求項２５記載の媒体。
【請求項２７】
前記決定する命令（ｂ）は、
（ｂ１）アクセス仲介を前記レイヤ・マネージャーにより呼び出し、
（ｂ２）前記第２レイヤで動作を実行するためのリクエストが前記アクセス仲介により所定の安全方針に基づいて受け入れられるかどうかを判断し、そして
（ｂ３）前記判断を前記レイヤ・マネージャーに供給する、
命令を含む請求項１９記載の媒体。
【請求項２８】
前記呼び出す命令（ｂ１）は、
（ｂ１ｉ）サブジェクトの一致、オブジェクトの一致、及びリクエストされた動作を前記アクセス仲介に通す、命令を含む請求項２７記載の媒体。
【請求項２９】
前記ルーティングする命令（ｃ）はさらに、
（ｃ１）アクセス仲介による判断により前記動作を実行するためのリクエストを受け入れようとする場合、前記第２レイヤでの前記動作を実行可能とし、そして
（ｃ２）前記判断が前記リクエストを受け入れないものである場合、前記動作を阻止する、命令を含む請求項１９記載の媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークに関し、特に、ネットワーク・プロトコル・スタックに関するものである。
【背景技術】
【０００２】
ブルートゥース（ＢｌｕｅｔｏｏｔｈＴＭ）ネットワーキング・プロトコルはこの技術分野において良く知られている。図１は標準のブルートゥース・プロトコル・スタックを示す。スタック１００はホスト・コントローラ・インターフェイス（ＨＣＩ）レイヤ１０６、ロジカル・リンク・コントロール・アンド・アダプテーション・プロトコル（Ｌ２ＣＡＰ）レイヤ１０８、テレフォニー・コントロール・プロトコル・スペシフィケーション（ＴＣＳ）レイヤ１１０、サービス・ディスカバリィ・プロトコル（ＳＤＰ）レイヤ１１２、及びＲＦＣＯＭＭプロトコル・レイヤ１１４を有する。
【０００３】
ＨＣＩレイヤ１０６は物理バス（図示せず）上の通信を受け付けるコマンド・インターフェイスを提供する。Ｌ２ＣＡＰレイヤ１０８は、より高いレベルのプロトコル多重化、パケット分割及び再構築、及びサービス情報品質の伝達をサポートする。
【０００４】
ＴＣＳレイヤ１１０は音声チャネルの呼制御及びシグナリングを提供する。ＲＦＣＯＭＭプロトコル・レイヤ１１４はＬ２ＣＡＰレイヤ１０８上のシリアル・ポートのエミュレーションを提供する。
【０００５】
ＳＤＰレイヤ１１２は、どのサービスがデバイスにより提供されるか、或いは、デバイスを通して使用できるかを見付け出すためのアプリケーション手段を与える。ブルートゥースデバイスはＳＤＰクライアント・クエリー・サービス、ＳＤＰサーバ提供サービス、或いは両方のサービスとして動作する。各サービスはＳＤＰサーバに登録され、情報関連の各サービスはサービス・レコードに目録化される。ＳＤＰレイヤ１１２を通して、クライアントはリクエストをＳＤＰサーバに送信して何のサービスがリモート・デバイスにより提供されるかを問い合わせる。ＳＤＰサーバはリモート・デバイスが提供するサービスのサービス・レコードを答える。各サービス・レコードの一部はプロトコル記述子リスト（ＰＤＬ）である。ＰＤＬはプロトコル・スタック１００のレイヤのリストを含み、このリストを通して特定のサービスに対応するパケットをルーティングする。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、スタック・レイヤ１０６〜１１４は明確に定義された上下のエッジを有するので、レイヤ１０６〜１１４の各々はプロトコル・スタック１００の中でその「上」及び「下」のスタック・レイヤを詳細に認識することが要求される。スタック１００を通過するパケットの各パスに対して、スタック・レイヤ１０６〜１１４は上下のスタック・レイヤと通信するために特殊な形でコード化されなければならない。このように、新規なパスをサポートしようとする場合、一つまたは複数のスタック・レイヤ１０６〜１１４を修正しなければならない。それに加えて、一つのスタック・レイヤをスタック・レイヤ１０６〜１１４の内の２つのレイヤ間に加えようとする場合、一つまたは複数のスタック・レイヤ１０６〜１１４をまた修正しなければならない。例えば、一つのレイヤをＲＦＣＯＭＭレイヤ１１４とＬ２ＣＡＰレイヤ１０８との間に加えようとすると仮定する。ＲＦＣＯＭＭレイヤ１１４はダウンストリームの方向にＬ２ＣＡＰレイヤ１０８に代わって新規のレイヤと通信するために修正されなければならず、そして、Ｌ２ＣＡＰレイヤ１０８はアップストリームの方向にＲＦＣＯＭＭレイヤ１１４に代わって新規のレイヤと通信する
ために修正されなければならない。これはやっかいな作業であり、プロトコル・スタック１００を相当複雑にする。
【０００７】
従って、改良されたネットワーク・プロトコル・スタックの開発が求められる。本発明はこのようなニーズに応えるものである。
【課題を解決するための手段】
【０００８】
本発明はプロトコル・スタックを通過するパケット・フローを制御する改良された方法及びシステムを提供する。このシステムは各スタック・レイヤのインターフェイスとなるレイヤ・マネージャーを備える。レイヤ・マネージャーはスタック・レイヤに向かうパケット・フローを処理する。サポートすべき新規のパケット・パスに対して、スタック・レイヤではなく、レイヤ・マネージャーのみを修正する必要がある。これにより、プロトコル・スタックにおいてより容易にレイヤを実行することができる。もう一つ別の実施形態においては、レイヤ・マネージャーはサポートされるサービスに対応する複数のプロトコル記述子リストを備え、そしてこれらのリストを使用してパケットを適切なスタック・レイヤにルーティングする。この別の実施形態により、新規のスタック・レイヤをプロトコル・スタックに、現存のスタック・レイヤを修正する必要を生じることなく挿入することができる。
【発明を実施するための最良の形態】
【０００９】
本発明は改良されたネットワーク・プロトコル・スタックを提供する。次の記載はこの技術分野の当業者が本発明を実現し、そして利用することを可能にするために開示され、そして特許出願及びその要件と関連する形で提供される。好適な実施形態に対する種々の変形が可能なことはこの技術分野の当業者には容易に理解できることであり、そしてここに示される一般的な原理は他の実施形態に適用することができる。このように、本発明はここに示される実施形態に限定されるべきではなく、本発明には本明細書に記載される原理及び特徴に一致する最も広い保護範囲が与えられるべきである。
【００１０】
本発明の特徴をさらに詳細に記載するために、以下の議論と関連する形で図２〜７を参照されたい。
図２は本発明によるプロトコル・スタックの好適な実施形態を示している。プロトコル・スタック２００は、図１に関連して記載されたスタック・レイヤ１０６〜１１４に加えてレイヤ・マネージャー２０２を含み、このレイヤ・マネージャー２０２は各スタック・レイヤ１０６〜１１４とのインターフェイスとなる。レイヤ・マネージャー２０２はスタック・レイヤ１０６〜１１４へのパケット・フローを処理する。レイヤ・マネージャー２０２により各スタック・レイヤ１０６〜１１４はパケットを、どのスタック・レイヤがスタック・レイヤ１０６〜１１４のすぐ上及び下に存在するかを認識する必要無しに処理することができる。各スタック・レイヤは、パケットがスタック２００の上に向かって、または下に向かって移動すべきかどうかについてのみ注目する。各スタック・レイヤはそのパケットをレイヤ・マネージャー２０２から受け取り、そして、パケット処理を終えると、各スタック・レイヤはパケットをレイヤ・マネージャー２０２に返す。次に,レイヤ・
マネージャー２０２はパケットを次のスタック・レイヤにルーティングする。
【００１１】
好適な実施形態においては、パケット・フローはレイヤ・マネージャー２０２へのパスをハードコーディング（ｈａｒｄ−ｃｏｄｉｎｇ）することにより制御される。このようにして、サポートすべき新規のパケット・パスに対して、レイヤ・マネージャー２０２のみが修正される必要がある。スタック・レイヤ１０６〜１１４は修正する必要は無い。
【００１２】
スタック２００を通過するパケット・フローを制御する別の方法は、複数のプロトコル記述子リスト（ＰＤＬ）を有するレイヤ・マネージャー２０２に適用される。図３は、本
発明に従ってＰＤＬ３０２を有するレイヤ・マネージャー２０２を備えたプロトコル・スタック２００の好適な実施形態を示している。この好適な実施形態においては、サービスが上述のようにＳＤＰサーバに登録されると、ＳＤＰサーバはレイヤ・マネージャー２０２に知らせ、そしてそのサービスに対応するＰＤＬのコピーを供給する。また、レイヤ・マネージャー２０２はクライアントにより提供される一連の予め定義され、サービスに対応するＰＤＬを含む。例えばＲＦＣＯＭＭサービスに対しては、リストはＨＣＩレイヤ１０６、Ｌ２ＣＡＰレイヤ１０８、及びＲＦＣＯＭＭレイヤ１１４である。パケットがスタック２００を上に移動すると、順序はＨＣＩレイヤ１０６、Ｌ２ＣＡＰレイヤ１０８、及びＲＦＣＯＭＭレイヤ１１４となる。パケットがスタック２００を下に移動すると、順序はＲＦＣＯＭＭレイヤ１１４、Ｌ２ＣＡＰレイヤ１０８、そして次にＨＣＩレイヤ１０６となる。特定のサービスに対応するＰＤＬ３０２を使用することにより、レイヤ・マネージャー２０２はパケットがスタック２００の内のどのレイヤにルーティングされるべきかを認識する。
【００１３】
本発明は上述の方法でＰＤＬを受け取るレイヤ・マネージャーを記載しているが、ＰＤＬを取得する他の方法を、本発明の技術思想及び技術範囲から逸脱しない範囲で用いることができる。
【００１４】
図４はフローチャートであり、このフローチャートは、本発明に従ってプロトコル・スタックを通過するパケット・フローを制御する方法の好適な実施形態を示している。まず、レイヤ・マネージャー２０２はステップ４０２を通してパケットを受け取る。次に、レイヤ・マネージャー２０２はステップ４０４を通してパケットに関連するサービスを判断する。好適な実施形態においては、この判断はプロトコル／サービス・マルチプレクサ（ＰＳＭ）フィールドに基づく。ＰＳＭは、パケットを発信する上位プロトコルを示すパケット内のヘッダの後に来る１６ビット・フィールドである。ＰＳＭフィールドはパケットに使用されるＰＤＬ３０２を参照する。レイヤ・マネージャー２０２はステップ４０６を通してサービスに対応するＰＤＬ３０２にアクセスする。ＰＤＬ３０２はサービスに対応するプロトコル・スタック２００のレイヤのリストを含む。次に、レイヤ・マネージャー２０２はステップ４０８を通して、リストに従ってプロトコル・スタック２００の或るレイヤにパケットをルーティングする。
【００１５】
例えば、パケットがＲＦＣＯＭＭサービスのためにスタック２００を上に送信されると仮定する。パケットはステップ４０２を通してレイヤ・マネージャー２０２に受け取られる。パケットのＰＳＭフィールドにより、レイヤ・マネージャー２０２は、ステップ４０４を通してＲＦＣＯＭＭサービスがパケットに関連していると判断する。次に、レイヤ・マネージャー２０２はステップ４０６を通してＲＦＣＯＭＭサービスに対応するＰＤＬにアクセスする。ＲＦＣＯＭＭサービスのＰＤＬはＨＣＩレイヤ１０６、Ｌ２ＣＡＰレイヤ１０８、及びＲＦＣＯＭＭレイヤ１１４を含む。次に、レイヤ・マネージャー２０２はステップ４０８を通してパケットをＨＣＩレイヤ１０６にルーティングする。ＨＣＩレイヤ１０６はパケットを処理し、そしてそれをレイヤ・マネージャー２０２に返す。
【００１６】
レイヤ・マネージャー２０２はステップ４０２を通してＨＣＩレイヤ１０６からパケットを受け取る。再び、パケットのＰＳＭフィールドにより、レイヤ・マネージャー２０２はステップ４０４を通してＲＦＣＯＭＭサービスがパケットに関連していると判断し、そしてステップ４０６を通してＲＦＣＯＭＭサービスに対応するＰＤＬにアクセスする。レイヤ・マネージャー２０２はパケットをＨＣＩレイヤ１０６から受け取ったことを認識し、そしてステップ４０８を通して、パケットをＰＤＬ上の次のレイヤであるＬ２ＣＡＰレイヤ１０８にルーティングする。Ｌ２ＣＡＰレイヤ１０８はパケットを処理し、そしてそれをレイヤ・マネージャー２０２に返す。
【００１７】
レイヤ・マネージャー２０２はステップ４０２を通してＬ２ＣＡＰレイヤ１０８からパケットを受け取る。レイヤ・マネージャー２０２はステップ４０４を通してＲＦＣＯＭＭサービスがパケットに関連していると判断し、そしてステップ４０６を通してＲＦＣＯＭＭサービスに対応するＰＤＬにアクセスする。レイヤ・マネージャー２０２はパケットをＬ２ＣＡＰレイヤ１０８から受け取ったことを認識し、そしてステップ４０８を通して、パケットをＰＤＬ上の次のレイヤであるＲＦＣＯＭＭレイヤ１１２にルーティングする。
【００１８】
このようにして、各スタック・レイヤ１０６〜１１４はレイヤ・マネージャー２０２と通信し、互いには通信しない。従ってスタック・レイヤ１０６〜１１４は他のレイヤを認識する、或いは、パケットの正しいルーティングについて認識する必要が無い。パケット・フローを制御するこの別の方法は、新規のスタック・レイヤをスタック２００に一層容易に挿入できるという新たな利点を有する。新規のレイヤをスタック２００に加えようとすると、この新規のレイヤは他のスタック・レイヤ１０６〜１１４と同じ態様でレイヤ・マネージャー２０２のインターフェイスとなるように実行される。現存のスタック・レイヤ１０６〜１１４のどれも修正する必要が無い。これにより、プロトコル・スタック２００の修正が一層容易になる。
【００１９】
レイヤ・マネージャー２０２を備えるプロトコル・スタック２００により、他の利点が得られる。例えば、スタック・コンポーネントのインストゥルメンテーションがレイヤ・マネージャー２０２の使用により大幅に簡素化される。この明細書で使用される「スタック・コンポーネント」とは、プロトコル・スタック２００のレイヤを実行するソフトウェアのことである。スタック・コンポーネント１０６〜１１４をインストゥルメントして、スタック・コンポーネントが受け取る刺激の測定及び／又はスタック・コンポーネントの刺激に対する応答の測定を可能にすることが望ましい。このインストゥルメンテーションにより、問題を解決し、性能及び作用を最適化し、利用統計を集計するなどする際に役に立つ情報を提供することができる。
【００２０】
従来のプロトコル・スタック１００においてスタック・コンポーネント１０６〜１１４をインストゥルメントするためには、コードをスタック・コンポーネント１０６〜１１４に付与してそこでデータが利用できる、または情報が集められるようにしなければならない。スタック・コンポーネント１０６〜１１４がプライベート及びユニークなインターフェイスを通して互いに通信するので、各スタック・コンポーネント１０６〜１１４は別々にインストゥルメントされなければならない。これにより、繰り返しの、そして矛盾する恐れのある作業が各インターフェイスで行なわれることになる。各インターフェイスで得られるデータは異なり、解析の前にさらに処理が必要となる。
【００２１】
しかしながら、本発明によるプロトコル・スタック２００を用いることにより、レイヤ・マネージャー２０２がスタック・コンポーネント１０６〜１１４間のパケットのルーティングの役割を担うので、レイヤ・マネージャー２０２が各スタック・コンポーネント１０６〜１１４の刺激及び応答も把握する。このようにして、プロトコル・スタック２００をインストゥルメントするために、レイヤ・マネージャー２０２が、スタック・コンポーネント１０６〜１１４をインストゥルメントする必要を生じることなくインストゥルメントされる。レイヤ・マネージャー２０２は、すべての刺激及び応答が通る単一のインターフェイスを提供するので、パケットが単一のポイントで取り込まれ、そしてフォーマットが同様となる。これにより、パケット中のデータを取り込み、そして解析するために必要なコード量を減らすことができる。
【００２２】
図５はフローチャートであり、このフローチャートは、本発明に従ってスタック・コンポーネントインストゥルメンテーションを提供する方法の好適な実施形態を示している。まず、レイヤ・マネージャー２０２はステップ５０２を通してプロトコル・スタック２０
０の第１スタック・コンポーネントからのパケットの中のデータを受け取る。次に、レイヤ・マネージャー２０２はステップ５０４を通してインストゥルメンテーション情報に関するデータを解析する。続いて、レイヤ・マネージャー２０２はステップ５０６を通してデータをプロトコル・スタック２００におけるマネージャの下方か上方の第２スタック・コンポーネントにルーティングする。
【００２３】
レイヤ・マネージャー２０２を備えるプロトコル・スタック２００により実現する別の利点は、プロトコル・スタック２００内でアクセス制御を提供できることである。従来、安全機構がアクセス制御をパケット・レベルで提供する。「防火壁」はこのような安全機構の例である。防火壁はパケットをパケットのアドレス及びポート番号を基にフィルタリングする。アドレス及びポート番号の付されたすべてのパケットはブロックされる。しかしながら、これらのメカニズムはプロトコル・スタック内で、すなわち、プロトコル・スタック・レイヤ間にアクセス制御を提供しない。これらの機構ではスタック・レイヤ・レベルでユーザを認証できない。
【００２４】
しかしながら、本発明によるプロトコル・スタック２００はレイヤ・マネージャー２０２中のアクセス仲介を通してプロトコル・スタック内でアクセス制御を提供することができる。アクセス仲介は所定の安全方針のルールを実行するソフトウェアである。好適な実施形態においては、安全方針はサブジェクト（人）ベースである。安全方針のルールは、どのサブジェクトがどのオブジェクト（データ）にアクセスすることができてリクエストされる動作（例えば、読み出し／書き込み）を実行するのかを判断する。
【００２５】
図６は、本発明による、プロトコル・スタック内でアクセス制御を提供する方法を利用するプロトコル・スタックの好適な実施形態を示す。プロトコル・スタック２００は、図２と関連して記載されるレイヤ１０６〜１１４及びレイヤ・マネージャー２０２に加えて、レイヤ・マネージャー２０２において実行されるアクセス仲介６０２を備える。このように、レイヤ・マネージャー２０２がもたらす利点はスタック２００内でアクセス制御を提供する際に実現される。
【００２６】
図７はフローチャートであり、このフローチャートは、本発明に従ってプロトコル・スタックの好適な実施形態により利用されるアクセス制御を提供する方法を示している。まず、レイヤ・マネージャー２０２はステップ７０２を通してプロトコル・スタック２００の或るレイヤからリクエストを受け取ってそのレイヤで動作を行なう。この実施形態においては、この動作は特定のサブジェクトにより或るオブジェクトに対して行なわれる。次に、レイヤ・マネージャー２０２はステップ７０４を通してアクセス仲介６０２を呼び出す。アクセス仲介６０２を呼び出すに当たって、レイヤ・マネージャー２０２はサブジェクトの一致、オブジェクトの一致、及びリクエストされた動作を通す。アクセス仲介６０２はステップ７０６を通してリクエストが所定の安全方針に基づいて受け入れられるかどうかを判断する。次に、アクセス仲介６０２はステップ７０８を通してその判断をレイヤ・マネージャー２０２に返す。アクセス仲介６０２が、サブジェクトがリクエストされた動作を実行するためにオブジェクトにアクセスできると判断すると、この動作が当該レイヤで実行される。アクセス仲介６０２が、サブジェクトがオブジェクトにアクセスできず、リクエストされた動作を実行できないと判断すると、この動作が阻止される。
【００２７】
アクセス仲介６０２をレイヤ・マネージャー２０２の中で実行することにより、スタック・レイヤ１０６〜１１４はアクセス仲介６０２を把握する、或いは、安全方針が在ることさえも把握する必要が全く無い。アクセス仲介６０２の把握は、レイヤ・マネージャー２０２にのみ要求される。スタック・レイヤ１０６〜１１４はアクセス仲介６０２を把握する必要が無いので、これらのスタック・レイヤはアクセス仲介６０２を混乱させることも無く、一層セキュリティの高いプロトコル・スタックを提供する。
【００２８】
本発明はブルートゥース・プロトコル・スタックと関連する形で記載されているが、本発明は他のプロトコル・スタックに本発明の思想及び範囲を逸脱しない範囲で適用することができる。
【００２９】
プロトコル・スタックを通過するパケット・フローを制御する改良された方法及びシステムを開示してきた。このシステムは各スタック・レイヤのインターフェイスとなるレイヤ・マネージャーを備える。このレイヤ・マネージャーはスタック・レイヤに向かうパケット・フローを処理する。サポートする新規のパケット・パスに対して、スタック・レイヤではなく、レイヤ・マネージャーのみが修正される必要がある。これにより、プロトコル・スタックにおいてレイヤをより容易に実行することができる。もう一つ別の実施形態においては、レイヤ・マネージャーはサポートされるサービスに対応する複数のプロトコル記述子リストを有し、そしてこれらのリストを使用してパケットを適切なスタック・レイヤにルーティングする。この別の実施形態により、新規のスタック・レイヤを、現存のスタック・レイヤを修正する必要を生じることなくプロトコル・スタックに挿入することができる。スタック・レイヤをインストゥルメントしたり、プロトコル・スタック内でアクセス制御を提供することが一層容易になるといった他の利点が、レイヤ・マネージャーを備えるプロトコル・スタックを使用して実現することができる。
【００３０】
本発明は示した実施形態に従って記載されてきたが、この技術分野の当業者であれば、これらの実施形態に変形を加えることができ、そしてこれらの変形が本発明の思想及び範囲に含まれることは容易に理解できることである。従って、この技術分野の当業者は添付の特許請求の範囲の思想及び範囲を逸脱しない範囲で多くの変形を加えることができる。
【図面の簡単な説明】
【００３１】
【図１】標準のブルートゥース・プロトコル・スタックを示す。
【図２】本発明によるプロトコル・スタックの好適な実施形態を示す。
【図３】本発明によるレイヤ・マネージャーを備えるプロトコル・スタックの好適な実施形態を示し、このレイヤ・マネージャーはプロトコル記述子リストを有する。
【図４】フローチャートであり、このフローチャートは、本発明に従ってプロトコル・スタックを通過するパケット・フローを制御する方法の好適な実施形態を示している。
【図５】フローチャートであり、このフローチャートは、本発明に従ってスタック・コンポーネント・インストルメンテーションを提供する方法の好適な実施形態を示している。
【図６】本発明による、プロトコル・スタック内でアクセス制御を提供する方法を利用するプロトコル・スタックの好適な実施形態を示す。
【図７】フローチャートであり、このフローチャートは、本発明に従ってプロトコル・スタックの好適な実施形態により利用されるアクセス制御を提供する方法を示している。
【図１】
2005509318.tif 000003
【図２】
2005509318.tif 000004
【図３】
2005509318.tif 000005
【図４】
2005509318.tif 000006
【図５】
2005509318.tif 000007
【図６】
2005509318.tif 000008
【図７】
2005509318.tif 000009
【国際調査報告】
2005509318.tif 000010
2005509318.tif 000011
2005509318.tif 000012
2005509318.tif 000013