JP4313815B2 - コンピュータ・オペレーティング・システムにおけるカーネル・モード動作のユーザ・モード・プロキシ - Google Patents

Description

本発明は、コンピュータ・オペレーティング・システムのユーザ・モードでのソフトウェア・コンポーネントと、コンピュータ・オペレーティング・システムのカーネル・モードでのソフトウェア・コンポーネントとの間の相互作用に関する。特に、本発明は、コンピュータ・オペレーティング・システムのユーザ・モードにおけるソフトウェア・コンポーネントによる、コンピュータ・オペレーティング・システムのカーネル・モードにおけるソフトウェア・コンポーネントのプロキシ(proxy：代理）に関する。

コンピュータは、かつて主として科学者が使用するどちらかと言えば漠然とした奇妙なものだったが、今日では、コンピュータは社会の主流の不可分な部分になっている。ほとんど毎日のように、コンピュータは多くの人々の生活、仕事、遊びの方法を変化させている。コンピュータの広範な拡散によって、わずか数年前まで思いもしなかったような、広い、新規の用途や応用が開けて来た。今日、コンピュータは多くのビジネスで使用される強力なツールと言うだけではなく、一般大衆のためのレクリエーションや楽しみの供給源である。

コンピュータが進歩し、増加する一方の一連の用途に応用されてきたことで、さらに強力で洗練されるようになって来た。今日のコンピュータは各種アプリケーション・プログラムのための頑強な環境と直感的なユーザ・インタフェースを提供する複雑なオペレーティング・システムを備えている。このようなオペレーティング・システムは、オペレーティング・システムの複雑のレベルや、オペレーティング・システムで実装されるセキュリティ機能によって、異った動作レベルまたは「モード」を通常有している。たとえば、通常のアプリケーション・プログラムは最低のプライオリティで動作するのが普通で、他のアプリケーションとの、または他のオペレーティング・システム層との干渉を防止するため、適切なセキュリティ・ディバイスの全てのものを有している。ハードウェアおよびオペレーティング・システムによって提供されるその他のサービスは、単一のユーザ・アプリケーションがシステムを「クラッシュ」させる能力を制限するように制御された、インタフェースまたはメカニズムを介してだけアクセスされる。この最低プライオリティのモードは、一般に「ユーザ」モードと呼ばれており、多くのコンピュータ・ユーザに馴染みの深いモードである。

１つ以上の層またはモードを提供するオペレーティング・システムでは、アプリケーションがコンピュータのハードウェアへ直接アクセスすることは許されていないのが普通である。むしろ、オペレーティング・システムがインタフェースを提供し、ユーザ・モードのアプリケーション・プログラムはこれを経由して、ハードウェアやオペレーティング・システムにより提供されたその他のサービスにアクセスできるようになる。つまり、システム内のコンピュータ・ハードウェアの上部に、ソフトウェアの層が存在するのが典型的である。このソフトウェア層は一般にドライバまたはフィルタと呼ばれる。

ソフトウェア・ドライバは、通常、ハードウェア制御を行なうように構築され、ハードウェアを制御またはアクセスするために使用できるインタフェースを提供している。ドライバは、これが制御しているハードウェア・コンポーネントにきわめて密接にリンクされるのが典型的である。このため、ドライバがオーバヘッドの非常に少ないモードで動作できるようにするのが一般に望ましい。ドライバがハードウェアとインタフェースする時、多数の時間的にクリティカルな機能を実行するのが一般的である。たとえば、ドライバが大容量記憶装置へデータを書き込もうとする時、ドライバは大きな遅延なしに大容量記憶装置へデータを書き込みできるように、大容量記憶装置が利用可能である十分なデータを必ず有していることを保証しなければならない。

ドライバが関連ハードウェアと密接に統合されていることと、多くのドライバが実行するタスクの時間的にクリティカルな性質のために、ドライバはもっと高いプライオリティと大幅に低いセキュリティ保護を有するオペレーティング・システム・モードで動作するのが普通である。このモードは一般に「カーネル」モードと呼ばれている。カーネル・モードで利用できるセキュリティ保護が少ないことから、カーネル・モードで動作するソフトウェア・コンポーネントは、最も信頼のおけるソフトウェア・コンポーネントに制限されているのが普通である。こうしたソフトウェア・コンポーネントは、全面的にテストされ、また絶対に予測可能な方法で振舞う必要がある。

ソフトウェア・ドライバの一般概念は、特定のハードウェアを制御するか、またはユーザ・モード・アプリケーションへ特定のサービスを提供することを意図しているため、ドライバは互いに隔離した環境(isolation) で開発され、ハードウェア・メーカまたはオペレーティング・システム提供者によって提供されるのが普通である。たとえば、デバイス・インタフェースを経由して追加ハードウェア・カードに関連する特定種類のＩ／Ｏサービスを提供するソフトウェア・ドライバは、他の何らかのドライバと通信する必要も、またその存在を知る必要もない。

すでに述べたように、今日では、コンピュータは多くのビジネスで使用される強力なツールというだけではなく、一般大衆のレクリエーションや楽しみの供給源になっている。新型でもっと強力なパーソナル・コンピュータによって開かれた応用分野のひとつがマルチメディアの分野である。マルチメディアは一連の処理機能を用いたデータ・ストリームの処理を必要とするのが普通である。データは代表的には音またはビデオを表わすデジタル・サンプルから構成され、処理部ブロックまたは「フィルタ」は、圧縮データのための展開処理、特殊効果処理、変形、スケーリング、デジタル・データをアナログ・データへ変換するためのレンダリング処理などを含むことがある。各々が任意のデータ項目に対して特定の機能を実行してからそのデータ項目を別のフィルタに渡すような一連の異なるフィルタを接続する処理アーキテクチャは、ストリーミング・アーキテクチャと呼ばれるのが普通である。接続されたフィルタのシーケンスはフィルタ・グラフと呼ばれることがある。

図１を参照すると、ディスク・ドライブからのサウンド・データ・ストリームをレンダリングし、スピーカを介して聞こえるようにするための従来技術モデルによるシステム例が示してある。デジタル化したサンプルの形で音を表わす大量のデータがディスク２０に記憶してある。これ以外に、サウンド・データ・ストリームの供給源は電話回線から到着するデジタル化情報、ネットワークからの、または従来技術において知られているその他の通信パケットまたは供給源からのデジタル化情報であってもよい。

カーネル・モード・ディスク・ドライバ２２はユーザ・モード・リーダ・プロセス２４の制御下でディスク２０からデータを取り出す。リーダ・プロセス２４は、オペレーティング・システムの標準Ｉ／Ｏ制御インタフェースを用いて、ディスク・ドライバ２２と相互作用し、圧縮されたサウンド・データをディスク２０から読み取らせる。データがディスク２０から取り出されると、データはユーザ・モード・アドレス空間の一部としてユーザ・モードに割り当てられているバッファに配置されるのが普通である。

前述のように、ディスク２０からデータを取り出すと、リーダ・プロセス２４はデータをデコンプレッサ２８へ渡して、データを展開し更に処理するためにデータの準備を行なう。図１に図示した例では、このステップ全体がユーザ・モードで実行される。これにより、展開ステップをユーザ・モードの低いプライオリティの処理とし、ユーザ・モード実行にともなう安全メカニズムも提供している。

デコンプレッサ２８がデータを展開してから、データは、データを処理して何らかの特殊効果を提供する効果コンポーネント３０へ渡される。図１に図示した例では、効果コンポーネント３０はカーネル・モードで動作する効果フィルタ３２を伴っている。更に、効果フィルタ３２は、効果プロセッサ３４を使用し、または、全てソフトウェアで所望の処理を行なうことができる。効果フィルタ３２にアクセスするために、効果コンポーネント３０は、システムＩ／Ｏ制御メカニズムを用いてデータおよび制御を効果フィルタ３２に移す。これにより、効果フィルタ３２を使用するためのカーネル・モード／ユーザ・モード境界の移動が起こる。効果フィルタ３２は、機能および提示されたデータに適するように効果プロセッサ３４を使用する。

制御およびデータが、効果フィルタ３２から効果コンポーネント３０へ戻された後、データはサウンド・レンダリング・ブロック３６へ渡される。サウンド・レンダリング・ブロック３６は制御とデータをサウンド・レンダリング・ドライバ３８へ渡す。これによりカーネル・モード／ユーザ・モード境界を横断する別のモード遷移が起こる。サウンド・レンダリング・ドライバ３８はさらにデータをレンダリングし、処理およびフィルタされてスピーカ４２からの音響とするためにサウンド・カード４０を制御する。

リーダ２４、デコンプレッサ２８，効果コンポーネント３０，サウンド・レンダリング・ブロック３６を含むフィルタ・グラフの動作は、クライアントまたは制御プロセスの制御または管理の下にある。図１では、このような制御プロセスが制御エージェント２６で図示してある。制御エージェント２６は音響データのレンダリングを行なうために異なるコンポーネントを管理している。制御エージェント２６は図１に図示したフィルタ・グラフを構成するためにダイナミック・グラフ構造(dynamic graph building)を含むことができる。こうしたダイナミック・グラフ構造により、動的にソフトウェア・コンポーネントを割り当てて、エンドユーザによって指定された通りにカスタム・フィルタリングまたは処理パスの動的再構成を提供することができる。

図１の従来技術モデルに関しては、幾つかの考察を行なうことができる。第１に、フィルタ・グラフは大半または全体がユーザ・モード内部で構築また実行されている。こうしたモードは頑強なエラー検査とセキュリティを提供するものだが、ユーザ・モードでの実行では低いプライオリティとこれにともなう遅延が問題を起こすことがある。たとえば、オーディオまたはビデオ・データをレンダリングする場合、音楽またはビデオを一定のまたはほぼ一定の速度で再生するのが一般にきわめて望ましい。これはユーザ・モードで遭遇する遅延に対して十分な注意が必要とされる。ユーザ・モードを通るデータの安定で均一な流れを保証するように従来技術のモデルでは相当の努力が払われて来た。それでも未だ問題があり、十分に改善の余地が残されている。したがって、ユーザ・モードの低いプライオリティ実行および付随する遅延について懸念せずに、データ・ストリームの均一なレンダリングを提供することがきわめて望ましい。

図１に示したアーキテクチャから引き出せる別の考察としては、データのレンダリングには多数のモード遷移が必要となることが挙げられる。各々のモード遷移は遅延要素を導入してオペレーティング・システムによる調整が必要であるから、モード遷移を最小限に押えるかまたは排除し、同時にカーネル・モードで発生する高いプライオリティの実行を犠牲にしないことがきわめて望ましい。現在のところ、これらの目標に到達できるような技術は存在していない。さらに、これらの能力全部に適合しつつ、ユーザ・モードで動作する制御エージェントの能力を犠牲にせずに、高速かつ効果的にフィルタ・グラフを設定して所望の処理シーケンスを実現することがきわめて望ましい。

従来の技術における前述の問題は、カーネル・モード動作のユーザ・モード・プロキシを指向する本発明によりうまく克服された。本発明は、現時点では、カーネル・モードにおけるストリーミング・アーキテクチャを実現するオペレーティング・システムでの使用を意図している。このようなアーキテクチャでは、各種のカーネル・モード・ドライバまたはフィルタをカーネル・モード内部で接続することができ、ユーザ・モードを経由することなく、あるドライバまたはフィルタから他のドライバまたはフィルタへデータを渡すことができる。このようなアーキテクチャは、カーネル遷移の回数を最小限に押え、フィルタ・グラフにおける非能率とオーバヘッドを減少する。しかし、このようなアーキテクチャは、フィルタ・グラフを制御し設定する既存の制御エージェントに対して大幅な変更を必要とすることがある。本発明は、カーネル・モード・グラフの最上部に位置するソフトウェア層を形成して、制御エージェントが特定のカーネル・モード・フィルタのユーザ・モード・プロキシを操作することにより、その特定のカーネル・モード・フィルタを操作できるようにするものである。

本発明のひとつの態様において、汎用プロキシ・フィルタが定義される。このような汎用プロキシ・フィルタは、広範なカーネル・モード・フィルタまたはドライバのためのプロキシとして用いることができる。汎用プロキシ・フィルタは、マルチメディア・データの処理で有用なカーネル・モード・フィルタをサポートする機能を含む。しかし、このような汎用オブジェクトの機能を拡張したり、カーネル・モード・ドライバまたはフィルタの他のクラスで別の汎用オブジェクトとして使用することができる。汎用プロキシ・フィルタの新たなコピーを取得し、その汎用プロキシ・フィルタを特定のカーネル・モード・フィルタへ接続する処理によって、汎用プロキシ・フィルタを再設定し接続されたカーネル・モード・フィルタと特に動作するように適合させる。

汎用プロキシ・フィルタの固有の能力により、制御エージェントが特定のカーネル・モード・フィルタの基本となる能力へうまくアクセスすることができないような状況では、汎用プロキシ・フィルタの能力を拡張するメカニズムが設定されている。ある態様において、汎用プロキシ・フィルタは、拡張を汎用プロキシ・フィルタに取り込むことにより、拡張することができる。ある実施例において、汎用プロキシ・フィルタは複数の所定の「フックポイント」を有している。特定のカーネル・モード・ドライバの提供者は、１つまたは２つ以上の所定のフックポイントで接続される１つまたは２つ以上の拡張（エクステンション：extention ）も提供できる。このような拡張が汎用プロキシ・フィルタに組み込まれる場合、プロキシ・フィルタは、汎用プロキシ・フィルタに提供された実行可能コードの代わりに、拡張で提供されたコードを実行する。このようにすると、カーネル・モード・ドライバの提供者はフックポイントのいずれかひとつで汎用プロキシ・フィルタの挙動を上書きすることができる。このようにすると、カーネル・モード・ドライバの開発者は、汎用プロキシ・フィルタを書き直す必要無しに汎用プロキシ・フィルタの能力を拡張することができる。カーネル・モード・ドライバの提供者は、汎用プロキシ・フィルタへカーネル・モード・ドライバと何らかの適当な拡張を単に提供するだけで良い。プロキシ・フィルタへの拡張の組み込みは、幾つかの実施例において実行時に行なわれている。つまり、プロキシ・フィルタはバイナリ的に拡張可能である。

所定のフック・ポイントで汎用プロキシ・フィルタの能力を拡張することに加えて、汎用プロキシ・フィルタは他の多数の方法で拡張できる。汎用プロキシ・フィルタは変換機能を実行する拡張を組み込むこともできる。たとえば、ユーザ・モード・フィルタからカーネル・モード・フィルタへ、またはその逆に、データ・ストリームを渡すためのインタフェースを変換する必要がある場合がある。また、ボリューム設定、トーン設定、輝度制御など、オーディオおよびビデオ処理に応用可能で有用な他の複数種類の制御のような特定種類の制御機能を提供するのに適している標準制御が現在多数存在している。汎用プロキシ・フィルタは設定プロセスの間に自身に標準制御を何個でも取り込むことができる。つまり、カーネル・モード・ドライバの提供者が標準制御と互換性のあるドライバを作成する場合、このような制御を提供者の側で余分な努力なしに提供することができる。あるいはまた、カーネル・モード・ドライバ提供者はプロキシ・フィルタに組み込まれたカスタム制御を提供したいと希望することがある。

ユーザがたとえばボリューム、輝度などのカーネル・モード・ドライバの幾つかのパラメータをセットできるのが望ましいことが多い。このような能力を実現するには、一般にユーザがカーネル・モード・ドライバに各種パラメータをセットするために使用されるデータを入力できるようにするユーザ・インタフェース・コンポーネントを提供することが必要である。本発明の汎用プロキシ・フィルタは、組み込まれた各々の制御にどのユーザ・インタフェースを使用してユーザからデータを収集すべきか問い合わせる能力を組み込んでいる。汎用プロキシ・オブジェクトは識別したユーザ・インタフェースを取り込み、ユーザは識別されたユーザ・インタフェースを用いて適当なパラメータをセットすることができるようになる。

汎用ユーザ・モード・プロキシ・フィルタを設定し特定のカーネル・モード・フィルタに接続すると、単に対応するユーザ・モード・プロキシ・フィルタを相互接続することで、制御エージェントはカーネル・モード・フィルタを相互接続することができる。これは、カーネル・モード・フィルタと特に動作するように制御エージェントを変更する必要がないという顕著な利点を提供するものである。ユーザ・モード・プロキシ・フィルタは馴染み深いプロトコルを用いて制御エージェントを扱うことができ、また制御エージェントからの要求をカーネル・モード・フィルタのための適当なプロトコルに変換することができる。

初期に自己設定することに加えて、汎用プロキシ・フィルタは基本となるカーネル・モード・フィルタが変化するのに併せて自己再設定するのに対応できる。動的に自己再設定する能力は、基本となるカーネル・モード・フィルタが動的に設定を変化できるような実施例で特に重要である。

本発明の別の顕著な利点は、一方が完全にまたは部分的にユーザ・モードに存在し他方が完全にまたは部分的にカーネル・モードに存在しているような２つの処理ストリームを高速かつ簡単に同期させる能力である。フィルタ・グラフが時間に敏感なデータを処理する場合、たとえばオーディオまたはビデオのデータの場合、データが正しいレートで再生されていることを保証するように注意しなければならない。一般にこれには各処理モジュールが時間情報にアクセスできるようにして、正しいレートでデータの再生を維持するように処理を加速したりまたは減速したりできるようにする必要がある。２つの処理ストリームを同期させなければならない場合、たとえばビデオ・クリップが付随するオーディオ・ストリームを有する場合、２つのフィルタ・グラフを同期させて２つのデータ・ストリームが同期するようにしなければならない。このような状況では、両方のフィルタ・グラフがユーザ・モードに常駐していれば、単一のユーザ・モード・クロックを両方の処理ストリームに使用できる。

カーネル・モードでのストリーミング・アーキテクチャの出現により、２つのフィルタ・グラフが存在しており、一方のフィルタ・グラフはカーネル・モードに存在し、他方のフィルタ・グラフはユーザ・モードに存在しているような状況が発生し得る。このように、一つがユーザ・モードに存在し、他方がカーネル・モードに存在している場合、２つの処理ストリームを同期させる能力が必要である。本発明において、このような処理ストリームを同期させる能力を提供している。ある様態において、ユーザ・モード・クロックがユーザ・モード・フィルタ・グラフに対して定義され、カーネル・モード・クロックがカーネル・モード・フィルタ・グラフに対して定義される。一方のクロックがマスタ・クロックとして選択され、他方のクロックがスレーブ・クロックとして選択される。スレーブ・クロックは、マスタ・クロックに従属または同期している。このようなアーキテクチャを使用して、２つの処理ストリームは同期している。

カーネル・モード・クロックがマスタ・クロックとして選択されている場合、本発明は、カーネル・モード・クロックに対してユーザ・モード・プロキシを定義することで同期を達成している。ユーザ・モード・プロキシ・クロックは、カーネル・モード・クロックから時間情報を取り出して、時間情報をユーザ・モード・フィルタに提供する。カーネル・モード・フィルタは、マスタ・カーネル・モード・クロックから直接時間情報を取得する。

ユーザ・モード・クロックがマスタ・クロックとして選択されている場合、状況は多少複雑になる。このような状況では、ユーザ・モードの「フォワーダ」を定義する。ユーザ・モード・フォワーダはマスタ・ユーザ・モード・クロックから時間を取り出して時間情報をカーネル・モード・スレーブ・クロックへ転送する。つまり、フォワーダは、カーネル・モード・スレーブ・クロックに対して一種のユーザ・モード・プロキシとして機能する。あるいはまた、このような設定においては、カーネル・モード・スレーブ・クロックはユーザ・モード・マスタ・クロックのカーネル・モード・プロキシであるとみなすことができる。ユーザ・モード・フィルタは、特定の実施詳細にしたがって、マスタ・クロックまたはフォワーダのどちらかから時間情報を取り出すことができる。カーネル・モード・フィルタはカーネル・モード・スレーブ・クロックから時間情報を取り出す。

したがって、本発明の主な目的は、カーネル・モード・フィルタのためのユーザ・モード・プロキシを提供することである。本発明のその他の目的としては、ユーザ・モードで動作する制御エージェントがユーザ・モード・プロキシを操作することにより高速かつ簡単にカーネル・モード・フィルタを相互接続する方法を提供すること、変更されないかまたは各種拡張メカニズムを経由して事実上全てのカーネル・モード・フィルタで使用できるような汎用プロキシ・オブジェクトを提供すること、および、一方の処理ストリームは主としてまたは全体としてユーザ・モードに存在し、他方の処理ストリームは主としてまたは全体的にカーネル・モードに存在するような処理ストリームを同期するメカニズムを提供すること、が挙げられる。

本発明の更なる目的や利点は以下の説明に記載してあり、部分的には説明から明らかになるか、または本発明の実施することにより理解されよう。本発明の目的および利点は添付の特許請求の範囲に特に指摘された装置およびその組合せを用いて実現し、また得ることができる。本発明のこれらのまたその他の目的や特徴は以下の説明と添付の特許請求の範囲からより完全に明らかになるか、または本明細書で説明しているように本発明の実施することによって理解されよう。

本発明の前述のおよびその他の利点および目的が得られるような方法とするため、すでに簡単に説明した本発明のさらに詳しい説明は添付の図面に図示してある特定の実施例を参照して行なうものとする。これらの図面では本発明の代表的実施例だけを図示しており、本発明の範囲を限定すべきものとみなすべきではないことを理解した上で、添付の図面を用いて更に特定かつ詳細に本発明を説明し解説する。

用語
本明細書で用いている術語「ユーザ・モード」は、ユーザによって書かれた大半のプログラムが動作するオペレーティング・システムにおける動作レベルを表わしている。ユーザ・モード動作レベルは、通常もっとも安全なレベルであり、ひとつのアプリケーション・プログラムまたはプロセスが別のアプリケーション・プログラムまたはプロセスと干渉しないように相当量のオーバヘッドを有している。更に、システム資源へのアクセスは特定インタフェースを経由して高度に制御されており、動作プライオリティは一般に、最低か、そうでなければもっとも低いもののひとつである。

本明細書で用いている術語「カーネル・モード」は、ユーザ・モード動作レベルより制限が大幅に少ないオペレーティング・システムにおける動作レベルを表わしている。カーネル・モード・プログラムまたはプロセスの例としては、ハードウェア・コンポーネントを制御するためのソフトウェア・ドライバが挙げられる。代表的には、カーネル・モード・プログラムは性能に敏感であるから、ユーザ・モード・プログラムより少ない動作オーバヘッドを有している。更に、ハードウェアや多くのシステム資源へのアクセスは制限されていないか、またはユーザ・モード・プログラムに比べて大幅に制限が少ない。多くの場合、カーネル・モードで動作するプログラム・コードは、良好なシステム動作を確立するために、プログラマの統制(discipline)や約束事に従うこと（たとえば別のプログラムのアドレス空間を壊さない、など）に依存している。

本明細書で用いている術語「ドライバ」は、代表的にはカーネル・モードで動作するソフトウェア・ドライバ・プログラムを表わす。術語ドライバは、オペレーティング・システムにロードされる実際の実行可能プログラムや、または幾つかの機能を欠いたその一部も表わすことがある。ドライバは、多くの場合、必ずではないが、何らかの形でハードウェアに関連する。

本明細書で用いている術語「フィルタ」は、ドライバ自体の全体を含めて、ソフトウェア・ドライバ内部にみられる機能の一部を表わす。たとえば、ソフトウェア・ドライバは、単一機能を有する多数の異なるフィルタをサポートすることができる。また、更に一般的な意味では、術語フィルタは、カーネル・モードで動作しているソフトウェア・ドライバ・フィルタか、または、ユーザ・モードで動作している別の部分のプログラム・コードで行なわれているのかとは無関係に、たとえば展開などの実行される動作（オペレーション）を表わすことがある。

動作環境
以下の本発明では、これを実施するために用いられる１つまたは２つ以上の実施例の構造、または処理のどちらかを説明するための図面を用いることによって説明している。このように図面を用いて本発明を示すことは、本発明の範囲を制限するものと考えるべきではない。本発明はカーネル・モード動作のユーザ・モード・プロキシのための方法およびシステムの両方を意図している。本発明の実施例は、本発明を実現するためにソフトウェアを用いる汎用コンピュータを含み得る。特殊用途または専用コンピュータも本発明を実施するために用いることができ、本発明の範囲に含まれるべきものである。

本発明で用いられる特殊用途または汎用コンピュータは、標準のコンピュータ・ハードウェアたとえば中央演算処理装置（ＣＰＵ）またはコンピュータで実行可能な命令を実行するためのその他の処理手段、実行可能な命令を有するコンピュータで読み取り可能な媒体、出力情報を表示するためのディスプレイまたはその他の出力手段、情報を入力するためのキーボードまたはその他の入力手段、その他を含むことができる。本発明の動作環境は、ユーザ・モードとカーネル・モードを有する、またはその等価物を有し、更に後述するような多数のカーネル・モード・フィルタまたはドライバの相互接続を行なうのに適しているようないくつかのオペレーティング・システムを含むことができる。現時点で本発明に好適な２種類の動作環境としては、マイクロソフト・ウィンドウズ（登録商標）またはマイクロソフト・ウィンドウズＮＴ（登録商標）オペレーティング・システムが挙げられる。

本発明の範囲内の実施例は、実行可能な命令を有するコンピュータで読み取り可能な媒体も含む。このようなコンピュータで読み取り可能な媒体は汎用または特殊用途コンピュータからアクセスすることができる何らかの利用可能な媒体であり得る。例として、また制限としてではなく、このようなコンピュータで読み取り可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、またはその他の光ディスク記憶、磁気ディスク記憶、またはその他の磁気記憶装置、または所望の実行可能な命令を記憶するために使用でき、汎用または特殊用途コンピュータからアクセスすることのできる他の何らかの媒体を含むことができる。上記の組合せもコンピュータで読み取り可能な媒体の範囲内に含まれるべきものである。実行可能な命令は、たとえば、汎用コンピュータ、特殊用途コンピュータ、または特殊用途処理装置に何らかの機能または一群の機能を実行させるような少なくとも命令またおそらくはデータも含む。

発明の状況
背景の部分ですでに説明したように、図１は、従来技術の原理およびアーキテクチャにしたがって構成され実現された、オーディオ・データのストリームを処理するのに適したフィルタ・グラフを表わしている。簡単に参照すると、リーダ２４、デコンプレッサ２８、効果コンポーネント３０、サウンド・レンダリング・ブロック３６は、図示したように、フィルタ・グラフで相互に接続された一連のユーザ・モード・フィルタを形成している。制御エージェント２６はフィルタ・グラフの動作を調整し制御する。オーディオ・データはリーダ２４の制御下でディスク２０からディスク・ドライバ２２経由で取り出される。リーダ２４はデータをデコンプレッサ２８に渡し、デコンプレッサ２８はデータを展開してから効果コンポーネント３０に渡す。効果コンポーネント３０は効果フィルタ３２を使用し、効果フィルタ３２は効果プロセッサ３４を使用してデータを処理し何らかの効果を実現することができる。処理後、効果コンポーネント３０はデータをレンダリングするためにサウンド・レンダリング・ブロック３６へ渡す。サウンド・レンダリング・ブロック３６はデータをサウンド・レンダリング・ドライバ３８へ渡し、ここでデータをサウンド・カード４０へ転送してレンダリングし、スピーカ４２から再生する。

図２は、図１のフィルタ・グラフと同じ機能を実行するが、全てカーネル・モードで実現されているフィルタ・グラフを表わしている。このようなフィルタ・グラフは、カーネル・モードで当該フィルタの相互接続をサポートするオペレーティング・システムのカーネル・モード・フィルタから構成できる。マイクロソフト・ウィンドウズＮＴ（登録商標）の将来のバージョンがこのような能力を内蔵するであろうと現時点で予想されている。このようなアーキテクチャの各種の詳細は幾つかの同時出願中の特許出願に見ることができる。カーネル・モード・フィルタがどのように相互接続されるかの詳細は、「カーネル・モードでソフトウェアドライバを相互接続するための方法およびコンピュータ・プログラム製品(Method And Computer Program Product For Interconnecting Software Drivers in Kernel Mode) 」（以下では「相互接続カーネル・モード・ドライバ」出願と称する）と題する、同時出願中の、George H. J. Shaw, Bryan A. Woodruff,Thomas J. O'Rourkeの連名で受理された米国特許出願第０８／８２５，８５６号に見ることができる。この出願は本明細書において参照により含めている。同時出願中の、「メッセージ作成を認証しファイル・オブジェクトへのメッセージ転送を行なうための方法、コンピュータ・プログラム製品、およびデータ構造(Method, Computer Program Product, And Data Structure For Validating Creation Of And Routing Messages To File Objects)」（以下では「メッセージ転送」出願と称する）と題する、George H. J. Shaw とBryan a. Woodruff 連名で受理された米国特許出願第０８／８２６，６４４号は、各種カーネル・モード・フィルタへメッセージをどのように転送するかと、こうしたメッセージをどのように取り扱うかを議論している。本出願も本明細書において参照により含めている。「標準化クロック・メカニズムを使用して多数のデータ・ストリームの処理を同期し、不同処理レートを一致する方法およびコンピュータ・プログラム製品(Method And Computer Program Product For Synchronizing The Processing Of Multiple Data Streams And Matching Disparate Processing Rates Using A Standardized Clock Mechanism)」（以下では「同期」出願と称する）と題する、同時出願中の、George H. J. Shaw, Bryan A. Woodruff, Thomas J. O'Rourkeの連名で受理された米国特許出願第０８／８２６，５６０号は、多数のカーネル・モード処理ストリームをどのように同期させられるか、またフィルタ・グラフ内部のフィルタの処理レートをどのように一致させるかを議論している。本出願も参照により含めている。「別々の処理コンポーネント間におけるバッファ間のデータ転送を減少させるための方法およびコンピュータ・プログラム製品(Method AndComputer Program Product For Reducing Inter-Buffer Data Transfers Between Separate Processing Components) 」（以下では「バッファ間転送」出願と称する）と題する、同時出願中の、George H. J. Shaw, Bryan A. Woodruff, Thomas J. O'Rourkeの連名で受理された米国特許出願第０８／８２５，９５７号は、フィルタ・グラフ内のフィルタ間で効率的な処理を行ない相互接続されたフィルタ間のデータ転送を行なうためにどのようにメモリを割り当てるかを開示している。この特許出願も本明細書において参照に含めてある。

図２に戻って、同時出願中の上記の特許出願に開示されているアーキテクチャによれば、制御エージェント４４は、カーネル・モード・フィルタを相互接続するためのデータ・フォーマットおよび接続フォーマットを識別するためにドライバに問い合わせ、図２に示したように処理が全部カーネル内部で行なわれるようなフィルタ・グラフを作成する。制御エージェント４４は、重要なイベントの通知も受け取るので、必要に応じて制御を行なうことができる。こうしたイベントの例としては、処理終了、データ欠乏状態、データ・オーバラン状態、その他が挙げられる。

図２において、サウンド・データはディスク・ドライバ４８によりディスク４６から読み込まれる。この処理はリーダ・ドライバ５０の制御の下で行なわれる。リーダ・ドライバ５０はデータを接続しているデコンプレッサ５２に渡す。すでに述べたように、展開後にデータは効果フィルタ５４へ渡される。効果フィルタ５４は適切に効果プロセッサ５６を使用して効果を適用し、データをサウンド・レンダリング・ドライバ５８へ渡す。サウンド・レンダリング・ドライバ５８はサウンド・カード６０を制御して、オーディオ・データが音響としてレンダリングされ、スピーカ６２から再生される。

図１と図２に図示した処理を比較すると、同等の処理が、図２のアーキテクチャではカーネル遷移の除外によって大幅に少ないオーバヘッドで実行されるのが分かる。更に、すでに参照により含まれている同時出願中の出願において説明しているように、各種カーネル・モード・フィルタによって割り当てられたバッファ間での不必要なデータ移動などのその他の非効率性を除外することに対して大変な努力が払われている。カーネル・モードで動作するプロセスにより達成される本質的な性能の増加と組み合せると、これらの改良は現行技術を大きく越える能力の高能率フィルタ・グラフを作成することができる。

しかし、このような改良は代償を払う必要がある。たとえば、制御エージェント４４は、図１に図示したようなユーザ・モード・フィルタの代わりに、カーネル・モード・フィルタを扱うことになるので、通常、制御エージェント４４は、カーネル・モード・フィルタを使用してフィルタ・グラフを作成するために使用されるプロトコルおよび情報をどのように取り扱うかを意識(awareness) して、変更する必要がある。これはカーネル・モード・フィルタで使用される新規プロトコルを理解するために費やす必要のある時間とエネルギーの両方のため、および新規能力を利用するように既存の制御エージェントを変更するかまたは新規に制御エージェントを作成するのに必要な時間とエネルギーから、相当な努力を必然的に伴なうことになる。既存のユーザ・モード・フィルタを理解するプログラマと制御エージェントに対して、その知識を利用して、このようなアーキテクチャによって提供される能力増大を利用するのに必要な学習および努力の量を減少できるようにすることのがきわめて望ましい。本発明は、新規アーキテクチャの長所または利点のいずれも犠牲にすることなく、これらの結果を実現するように設計されている。

発明の説明
図３を次に参照すると、本発明の原理が組み込まれた図２のフィルタ・グラフを示す図面が示してある。図３に図示してあるように、本発明によって実現されたフィルタ・グラフと図２に図示したように実現されたフィルタ・グラフの間の唯一の相違点は、カーネル・モード・フィルタの各々に対してのプロキシ・フィルタの追加である。図３において、これらのプロキシ・フィルタは、リーダ・ドライバ５０のためのプロキシ（代理）として機能するリーダ・プロキシ・フィルタ６４、デコンプレッサ５２のためのプロキシとして機能するデコンプレッサ・プロキシ・フィルタ６６、効果フィルタ５４のためのプロキシとして機能する効果フィルタ・プロキシ６８、サウンド・レンダリング・ドライバ５８のためのプロキシとして機能するサウンド・レンダリング・プロキシ７０によって図示してある。つまり、ひとつの側面において、本発明の特徴は、カーネル・モード・フィルタにユーザ・モード・プロキシ・フィルタを提供することである。したがって、本発明の幾つかの実施例は、カーネル・モード・フィルタの代理に適したユーザ・モード・プロキシ・フィルタを形成するための手段を含む。図３において、リーダ・プロキシ・フィルタ６４、デコンプレッサ・プロキシ・フィルタ６６、効果フィルタ・プロキシ６８、サウンド・レンダリング・プロキシ７０は全てこうした手段の例である。

カーネル・モード・フィルタにプロキシ・フィルタを追加することで、幾つかの重要な利点を提供する。たとえば、以下に更に詳細に説明するように、制御エージェント４４は、単にカーネル・モード・フィルタのプロキシを操作し通信することにより、特定のカーネル・モード・フィルタを操作し通信できる。つまり、カーネル・モード・フィルタのユーザ・モード・プロキシは、頑強で慣れたインタフェースを特定の制御エージェントに提示すると同時に、制御エージェントがカーネル・モード・ストリーミング・アーキテクチャの利点全部を利用できるようにするものである。実際の実施によっては、制御エージェント４４は各種フィルタの特定の機能を利用するために幾らか変更を加える必要がある場合がある。しかし、これらの場合でも、これらの機能を利用するために使用されるメカニズムは、馴染みのあるプロトコルおよび技術に基づくことができる。これにより、特定のカーネル・モード・フィルタの特定の実装および特定の詳細にその程度は依存するが、特定の実施の詳細を隠蔽することができる。

図３に図示したフィルタ・グラフの動作は、図２に示したフィルタ・グラフの動作と基本的には同様に行なわれる。ディスク・ドライバ４８は、リーダ・ドライバ５０の指示のもとでディスク４６からデータを取り出す。リーダ・ドライバ５０はデータをデコンプレッサ５２に渡し、デコンプレッサ５２はデータを展開して効果フィルタ５４に渡す。効果フィルタ５４は効果プロセッサ５６を用いて所望の効果を追加してからデータをサウンド・レンダリング・ドライバ５８に渡す。サウンド・レンダリング・ドライバ５８はサウンド・カード６０を制御して、データがレンダリングされスピーカ６２から再生されるようにする。つまり、図３のフィルタ・グラフは、動作において、図２のフィルタ・グラフと実質的に同様に機能し、図２のフィルタ・グラフの利点の全部を有している。

相違点は、制御エージェント４４がカーネル・モード・フィルタ・グラフと相互作用する形態だけである。図２で要求されるような、個別のカーネル・モード・フィルタを直接扱うのではなく、制御エージェント４４は、個別のカーネル・モード・フィルタと、対応するプロキシ・フィルタ経由で相互作用することができる。つまり、プロキシ・フィルタが制御エージェント４４に通知を送出するような状況では、通知は図２のフィルタ・グラフで使用されている何らかのメカニズムを経由するのではなく、対応するプロキシ・フィルタを通って渡される。同様に、制御エージェント４４が図３のフィルタ・グラフを設定する場合、これらの設定は全て対応するプロキシ・フィルタの操作によって実現できる。たとえば、図３のカーネル・モード・フィルタ・グラフを作成する場合、制御エージェント４４は対応するプロキシ・フィルタを接続し、対応するプロキシ・フィルタが個々のカーネル・モード・フィルタを所望のフィルタ・グラフへ接続する詳細を取り扱うことになる。つまり、制御エージェント４４の観点からは、図１のそれと類似のユーザ・モード・フィルタ・グラフが提示される。これが図３では、個々のプロキシ・フィルタの間の破線接続７２で示されている。このような接続は、制御エージェント４４の観点からは、ユーザ・モード・プロキシ・フィルタが接続されてデータがこれらの間を流れるようになることから、仮想接続と考えることができる。幾つかの実施において、実際の接続が個々のプロキシ・フィルタの間に存在することがある。このような接続は、対応するカーネル・モード・フィルタの相互接続を必要に応じて行うために、プロキシ・フィルタ間の情報交換が行えるようにすることが有用である。同様の情報接続を有する他の理由も存在する。しかし、カーネル・モードに配置されたフィルタ・グラフで処理されるデータは、個々のプロキシ・フィルタ間で交換されない。

本発明のプロキシ・フィルタを実施するに、広範な技術を使用できる。どの技術を選択するかは、特定の動作環境と開発者の目標に大きく依存する。たとえば、２台のコンピュータ・ステーションの間でのビデオ会議などの単一の特定目的にあわせてカスタム・フィルタ・グラフを作成し最適化することができる。このような特化したフィルタ・グラフは、その特定の用途に特に適するようにカスタマイズしたカーネル・モード・フィルタを必要とすることがある。しかし、個々のカーネル・モード・フィルタが各種の用途で広い応用性と用途を有することを本発明では想定している。たとえば、マルチメディア用オーディオ・データを処理するのに必要な多くのフィルタはテレビ会議にも応用できる。つまり、本発明の概念はマルチメディア分野を越えて広範な応用分野での用途を有している。つまり、マルチメディアの例は本発明の各種用途を示すために本出願全体で典型的に使用されるが、このような例は本発明の範囲を制限するものと考えるべきではない。

本発明は一般的なマルチメディア環境で特に応用性を有し得る。本発明が特に有用性を有し得るような環境のひとつに、マイクロソフト社のActiveMovie(アクティブムービー）製品がある。ActiveMovie は、開発者や専門家がマルチメディア製品を製作できるようにするクロス・プラットホームのデジタル・ビデオ技術である。ActiveMovie はマルチメディア情報の再生のためのわかりやすいサービス群を提供する。ActiveMovie の柔軟なアーキテクチャは、ツールおよびコンテンツ開発者が各種データを処理するためのフィルタ・グラフを製作できる置き換え可能なフィルタのシステムに基づいている。本発明のユーザ・モード・プロキシ・フィルタはActiveMovie 環境に統合するためのActiveMovie フィルタとして製作することができる。これによりActiveMovie などの製品がカーネル・モード・フィルタを利用できるようになると同時に、それまでに開発したユーザ・モード・フィルタとの一貫性を維持することができる。

図４は対応するプロキシ・フィルタを使用して２つのカーネル・モード・フィルタを相互接続するプロセスを詳細に示している。図４において、カーネル・モード・フィルタ７４はユーザ・モード・プロキシ・フィルタ７６を有し、カーネル・モード・フィルタ７８はユーザ・モード・プロキシ・フィルタ８０を備えている。図４に図示してあるように、カーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８は複数の「ピン」８２を含む。ピンは、カーネル・モード・フィルタが別のカーネル・モード・フィルタへ接続される接続点である。２つのカーネル・モード・フィルタのピンを相互接続することによって、データフロー・パスが作成され、ひとつのカーネル・モード・フィルタから別のカーネル・モード・フィルタへデータが流れる。カーネル・モード・フィルタのピンの相互接続は図２に図示したフィルタ・グラフがどのように接続されるかによる。

図４において、接続プロセスは制御エージェント４４の制御下にある。つまり、制御エージェント４４がカーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８の間に図示した相互接続を実際に形成する。しかし、このような接続はユーザ・モード・プロキシ・フィルタ７６とユーザ・モード・プロキシ・フィルタ８０を経由して行なわれる。制御エージェント４４がカーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８内部の機能にアクセスできなければならないのであれば、対応するプロキシ・フィルタ７６および８０は対応するカーネル・モード・フィルタの機能に制御エージェント４４がアクセスできるようにするメカニズムを提供する必要がある。したがって本発明の範囲に含まれる実施例は、カーネル・モード・フィルタの機能へクライアント・プロセスからのアクセスを提供するための手段を含んでいる。言い換えれば、プロキシ・フィルタは適当な環境でカーネル・モード・フィルタの特定機能へのアクセスを提供するべきである。提供する必要のあるアクセスの程度は、明らかにフィルタが接続されるカーネル・モード・フィルタの特定機能およびフィルタ・グラフの種類に依存する。しかし、最低限でも、プロキシ・フィルタはカーネル・モード・フィルタを別のカーネル・モード・フィルタへ接続する能力を提供すべきである。

図４において、アクセスを提供するための手段は、インタフェース８４およびインタフェース８６で図示してある。インタフェース８４とインタフェース８６はプロキシ・フィルタ経由でカーネル・モード・フィルタの機能にアクセスするメカニズムの一般表現である。インタフェースが実際にどのように機能するかと、このようなインタフェースの詳細とについては、プロキシ・フィルタを実現するためにどの技術を使用するかと、対応するカーネル・モード・フィルタとに大きく依存する。これらのコンポーネントを実現するためには多様な技術を使用できる。たとえば、これらのコンポーネントは、システムに常駐する別個のソフトウェア実体から作成できる。一例として、多くのオペレーティング・システムのカーネルに現在常駐しているドライバは、クライアント・プロセスから呼び出すことができる機能を提供するコード部分でしかない。しかし、現時点ではマイクロソフトのコンポーネント・オブジェクト・モデル（Component Object Model：ＣＯＭ）技術を用いてユーザ・モード・プロキシ・フィルタを実現するのが望ましい。マイクロソフトのＣＯＭ技術はＯＬＥやActiveX を含む広範な基本技術と密接に関連している。ＣＯＭの基本と当該技術がActiveX やＯＬＥとどのように関連するかについては、本明細書に参照により含めるマイクロソフト・プレス刊David Chappell著“Understanding ActiveX and OLE ”に記載されている。

マイクロソフトのＣＯＭ技術は業界標準になっており当業者には周知である。しかし、基本的には、ＣＯＭは独立したソフトウェア・ユニットを組み合せ動作時にバイナリ・レベルで拡張するメカニズムを定義している。以下で詳細に説明するように、このような技術は本発明の幾つかの側面を実現するのに理想的である。ＣＯＭ規格によれば、ＣＯＭオブジェクトと呼ばれるソフトウェア実体がＣＯＭオブジェクト内部の機能へのアクセスを提供する１つまたは２つ以上のインタフェースを定義する。ひとつのＣＯＭオブジェクトが別のＣＯＭオブジェクトのインタフェースを取得して提示するためのメカニズムが存在することで、クライアント・プロセスからは、２つのＣＯＭオブジェクトが両方の機能を組み合わせた単一のオブジェクトのように見える。また、ひとつのＣＯＭオブジェクトがクライアント・プロセスへ何らかの追加のインタフェースを提示することなく、別のＣＯＭオブジェクトの機能を使用できるようにするメカニズムも存在する。基本的に、ＣＯＭインタフェースは、特にＣＯＭオブジェクトの特定の機能にアクセスするために、クライアント・プロセスから起動するまたは呼び出すことのできるような、メソッドと呼ばれることもある一連の関数(function)を提供している。

図４に戻って、ユーザ・モード・プロキシ・フィルタ７６とユーザ・モード・プロキシ・フィルタ８０がＣＯＭ技術を用いて実現されている場合、インタフェース８４とインタフェース８６はＣＯＭ規格に準拠したインタフェースである。これらのインタフェースは、カーネル・モード・フィルタ７４およびカーネル・モード・フィルタ７８を操作するために、制御エージェント４４によってアクセスされる。

本発明の特定のひとつの実施において、以下のようなプロセスを用いてカーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８を相互接続することができる。この実施例では、ユーザ・モード・プロキシ・フィルタ７６は、制御エージェント４４がカーネル・モード・フィルタ７４のピンを識別できる情報を有することになる。このような情報は、ユーザ・モード・プロキシ・フィルタ７６内に格納されるか、または、ユーザ・モード・プロキシ・フィルタ７６を設定してカーネル・モード・フィルタ７４のピンに対応するユーザ・モード・ピンを組み込み、制御エージェント４４からは、ユーザ・モード・プロキシ・フィルタ７６が、カーネル・モード・フィルタ７４と同じ２つの入力ピンおよび単一の出力ピンを有するように見えるようにできる。図４において、ユーザ・モード・プロキシ・フィルタ７６は、カーネル・モード・フィルタ７４の各ピン８２に対応するピン８３を設定される。ピン８３はＣＯＭ技術を用いて実現することもできる。ピン８３がＣＯＭオブジェクトの場合、各ピンは、たとえば図４に示したインタフェース８５のように、１つまたは２つ以上のインタフェースを提示できる。このようなインタフェースはまた、カーネル・モード・フィルタの機能へのアクセスを提供するための手段の一例でもある。図４の全てのピンとこれのインタフェースは共通の番号で識別されるが、各ピンは種類が異なることがあり、各々が異なるインタフェースを提示できることに注意されたい。プロキシ・フィルタにピンを設定するプロセスは以下で詳細に説明する。ユーザ・モード・プロキシ・フィルタ８０も同様に、カーネル・モード・フィルタ７８のピン８２に対応する単一の入力ピン８３と単一の出力ピン８３で設定できる。

ピン情報は、たとえば、プロキシ・フィルタ７６とプロキシ・フィルタ８０の両方から提示されたインタフェースの一方で提供できる。図４において、インタフェース８４はプロキシ・フィルタ７６とプロキシ・フィルタ８０の両方で実現される。つまり、制御エージェント４４がプロキシ・フィルタ７６とプロキシ・フィルタ８０のピンを見付けられる機能が、インタフェース８４に提供される。制御エージェント４４は、制御エージェント４４で理解されるプロトコルを用いて、プロキシ・フィルタ７６とプロキシ・フィルタ８０の適当なフィルタ・ピンを相互接続する。これが相互接続８７として図４に図示してある。この相互接続に応答して、プロキシ・フィルタ７６およびプロキシ・フィルタ８０は、カーネル・モード・フィルタ７４およびカーネル・モード・フィルタ７８を指定されたピンで相互接続することにより応答する。カーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８を接続するために使用するプロトコルはプロキシ・フィルタ７６とプロキシ・フィルタ８０を相互接続するために制御エージェント４４で使用するプロトコルとは劇的に異なることに留意されたい。更に、カーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８の間の相互接続が、プロキシ・フィルタの一方によってまたはプロキシ・フィルタの両方によって行なわれるように実装を定義できる。このような実施の詳細は、プロキシ・フィルタ７６とプロキシ・フィルタ８０を相互接続するために制御エージェント４４で使用するプロトコルと、カーネル・モード・フィルタ７４とカーネル・モード・フィルタ７８を相互接続するのに適当なプロトコルへそのプロトコルをどのように変換するかにだけ依存している。

上記の説明から、別のプロキシ・フィルタと相互接続するように制御エージェントから指示を受け取ると、応答してカーネル・モード・フィルタに相互接続する本発明の範囲内の実施例は、あるカーネル・モード・フィルタのピンを別のカーネル・モード・フィルタへ接続するための手段を含むことが明らかである。このような手段は、１つまたは２つ以上のプロキシ・フィルタで２つのカーネル・モード・フィルタを相互接続するのに必要とされる適当なプロトコルへと受信した命令を変換するために使用される何らかのメカニズムとすることができる。本発明の観点から重要なことの全ては、２つのユーザ・モード・プロキシ・フィルタを相互接続するように定義されたプロトコルを用いることで、ユーザ・モードの制御エージェントが２つのカーネル・モード・フィルタを相互接続できることである。図４において、このようなメカニズムが、プロキシ・フィルタ７６とプロキシ・フィルタ８０の相互接続８７として、または最終結果を示すカーネル・フィルタ接続８８として、図示してある。カーネル・モード・フィルタを互いに相互接続することで、実際にはたとえばハードウェア・ディバイスまたはコンポーネント、リモートマシン、またはリモートマシンのプロキシなど、他のディバイス、システム、またはソフトウェア・コンポーネントを相互接続することになる。

前述のように、本発明は、多くの利点と長所を提供するが、本発明の唯一の欠点は、ユーザ・モード・プロキシ・フィルタがカーネル・モード・フィルタに対応して存在するという概括的なアーキテクチャである。そのため、カーネル・モード・フィルタの提供者は、カーネル・モード・フィルタを提供するばかりでなく、カーネル・モード・フィルタがここで説明したように用いられる場合、ユーザ・モード・プロキシ・フィルタを提供する位置におかれている。

カーネル・モード・フィルタの提供者をユーザ・モード・プロキシ・フィルタを提供する必要がある位置に位置付けるのは望ましくない。カーネル・モード・フィルタの提供者の多くは、ユーザ・モード・ソフトウェア・コンポーネントを書き上げる上での専門性が相当に不足している。したがってカーネル・モード・フィルタの提供者がユーザ・モード・プロキシをゼロから作成する必要無しにユーザ・モード・プロキシを利用できるようにするのが非常に望ましい。このような目標は、各種のメカニズムによって再設定および拡張することのできる基本的な汎用ユーザ・モード・プロキシ・フィルタを提供して広範囲の異なるカーネル・モード・フィルタの代理とすることにより実現できる。ＣＯＭ規格は実行時に既存のソフトウェアＣＯＭオブジェクトの拡張性を提供しているので、このような技術は汎用プロキシ・フィルタを実現するのに理想的である。次に、図５を参照すると、汎用プロキシ・フィルタと特定のカーネル・モード・フィルタにそのフィルタを適合させるような設定および拡張の図が示されている。汎用ユーザ・モード・プロキシ・フィルタを特定のカーネル・モード・フィルタで動作するように適応させ拡張しなければならない場合、このようなプロキシ・フィルタは特定のカーネル・モード・フィルタに一致するように、ユーザ・モード・プロキシ・フィルタを変更するための手段を必要とする。図５との関連で説明するメカニズムと概念はこうした変更するための手段の幾つかの例である。

図５において、汎用プロキシ・フィルタを変更するプロセスは、汎用プロキシ・フィルタのインスタンスが作成されるか取得された時に始まる。汎用プロキシ・フィルタがＣＯＭオブジェクトを用いて実現されている場合、ＣＯＭ規格は、どのようにクライアント・プロセスたとえば制御エージェント４４がＣＯＭオブジェクトのインスタンスを取得または作成できるかを定義している。要するに、特定のものに適合したユーザ・モード・プロキシ・フィルタの作成は、汎用プロキシ・フィルタを最初に作成し、次に汎用プロキシ・フィルタを特定のカーネル・モード・フィルタに適合させるかまたは設定することから始まる。

図５において、作成された汎用プロキシ・フィルタのインスタンスが汎用プロキシ・フィルタ９０で図示してある。汎用プロキシ・フィルタ９０を作成すると、汎用プロキシ・フィルタ９０は、どのように設定されるべきかを識別するステップを行い、次に、特定のカーネル・フィルタにあわせて自分自身を変更するまたは適合させるステップを行う必要がある。この再設定を実現するには多くの方法が使用でき、以下に示し説明するプロセスは単なる例としてみなすべきで本発明の範囲を制限するものとみなすべきではない。以下の説明ではＣＯＭ規格が幾つかの機能を実行する方法について詳しく述べることにする。

汎用プロキシ・フィルタ９０が作成された後、汎用プロキシ・フィルタ９０は自己設定に必要な幾つかの情報を見つけ出す必要がある。こうした情報は、たとえば制御エージェントから渡されるといった、多種多様な方法で取得できるが、一般に、汎用プロキシ・フィルタ９０によって取り出されるような一定のロケーションにこうした情報を格納しておくのが好ましい。図５において、こうしたロケーションはレジストリ９２で表わされている。レジストリ９２はＣＯＭ規格で必要な全ての情報が記憶されているロケーションである。代表的には、レジストリ９２はシステム・レジストリとすることができる。図５において、レジストリ９２から必要な情報を取得するためのプロセスは、問い合わせ９４と応答９６として図示してある。図５に図示してあるように、レジストリ内の情報は、汎用プロキシ・フィルタ９０によって代理されるカーネル・フィルタ、汎用プロキシ・フィルタ９０に組み込まれるべき拡張、および、必要に応じて他の情報を含む。

レジストリは、汎用プロキシ・フィルタ９０が自己設定するのに必要とされるあらゆる情報を記憶するために使用できるが、代理されることになるカーネル・モード・フィルタから直接幾つかの情報を取得するのが好ましい。たとえば、カーネル・モード・フィルタのピンの本数および種類、ならびにその他の設定パラメータは、フィルタから直接取得できる。これがフィルタ設定パラメータ１０１として図５に図示してある。これに代わる方法として、これら全ての情報をレジストリ９２に記憶させておき問い合わせ９４によって取得することもできる。更にこれ以外では、デフォルトのフィルタ設定をカーネル・フィルタ９８から直接取得し、上書きしようとする設定パラメータをレジストリ９２から取得することができる。

情報をカーネル・モード・フィルタから直接取得する場合、汎用プロキシ・フィルタ９０は、すでに述べたようにレジストリからカーネル・フィルタの識別(identity)とロケーションを取り出す。汎用プロキシ・フィルタ９０は識別したカーネル・モード・フィルタを開くかアクセスする。これが図５ではカーネル・モード・フィルタ９８と接続１００および１０２で図示してある。汎用プロキシ・フィルタ９０がカーネル・モード・フィルタ９８から情報を取得すべき場合、汎用プロキシ・フィルタ９０はフィルタについての情報を取得するためにカーネル・モード・フィルタ９８に問い合わせるための手段を含む必要がある。接続１００および１０２はこうした手段の例である。カーネル・モード・フィルタ９８と汎用プロキシ・フィルタ９０が適当な情報を通信できるようにする何らかのメカニズムを使用できる。たとえば、メッセージに基づくアーキテクチャでは、汎用プロキシ・フィルタ９０とカーネル・モード・フィルタ９８はメッセージ交換により通信できる。他の種類のアーキテクチャでは、カーネル・モード・フィルタ９８は、汎用プロキシ・フィルタ９０によって関数同様に呼び出すことのできるアクセスまたはエントリ・ポイントを提供している。汎用プロキシ・フィルタ９０とカーネル・モード・フィルタ９８の間の通信および情報交換のための基本となるメカニズムは、コンピュータの動作環境およびオペレーティング・システムによって専ら、さもなければ主として、決定されてしまう。

以下で詳細に説明するように、幾つかの状況では、汎用プロキシ・フィルタ９０は、適当なユーザ・モード・プロキシ・フィルタとして動作するために、カーネル・モード・フィルタ９８で必要とされる全ての機能を含まないことがある。このような状況では、汎用プロキシ・フィルタ９０の能力は、１つまたは２つ以上の拡張(extention：エクステンション）を介して拡張する必要がある。図５において、このような拡張が拡張１０４で表わしてある。拡張１０４は汎用プロキシ・フィルタ９０に組み込まれた時に汎用プロキシ・フィルタ９０に追加の能力を提供するために使用できる。つまり、汎用プロキシ・フィルタ９０をこの方法で拡張すべき場合、汎用プロキシ・フィルタ９０は拡張を自分に組み込むための手段を含む必要がある。このような組み込みをどのように行なうかのプロセス例について以下で詳細に説明する。しかし、このような手段は、図５においてリンク１０６として図示してある。

すでに説明したように、幾つかの実施例においては、対応するカーネル・モード・フィルタの１つまたは２つ以上のピンに対応する１つまたは２つ以上のユーザ・モード・ピンを汎用プロキシ・フィルタ９０へ組み込むのが望ましい。図５において、このようなユーザ・モード・フィルタ・ピンはフィルタ・ピン１０８として図示してある。フィルタ・ピン１０８は、インタフェース１０９で示されているように、ＣＯＭオブジェクトを用いて実現できる。汎用プロキシ・フィルタ９０はフィルタ・ピン１０８のインスタンスを作成し、必要に応じてカーネル・モード・フィルタ９８の対応するピンと一致するように個々のピンを設定し、設定したフィルタピンを自分自身に組み込む。このような実施例において、フィルタ・ピン１０８と汎用プロキシ・フィルタ９０は、フィルタ・ピンがプロキシ・フィルタから離れて存在しないような密接な関係を有している。ある意味では、汎用プロキシ・フィルタ９０は、フィルタ・ピン１０８を保持するまたは含む容器と考えることができる。ＣＯＭ技術を汎用プロキシ・フィルタ９０の基本として用いない場合、適当なユーザ・モード・フィルタ・ピンとともに汎用プロキシ・フィルタ９０を設定する他のメカニズムを使用できる。フィルタ・ピンとともに汎用プロキシ・オブジェクト９０を取得するまたは設定するために使用されるプロセスは、ユーザ・モード・ピンを作成するための手段の一例である。

ある種のカーネル・フィルタは、カーネル・モード・フィルタの動作を変化させるように変更またはセットできる各種パラメータまたは属性を有している。たとえば、２つのチャンネルを混合するカーネル・モード・フィルタは、各入力チャンネルの相対的音量レベルを表わすバランス・パラメータを含み得る。他の種類のフィルタは変更できる何個かの異なる種類のパラメータを有し得る。どのようにカーネル・モード・フィルタ９８が機能するかを変更するために、こうしたパラメータまたは属性を操作する能力を汎用プロキシ・フィルタ９０に設定するのが望ましいような状況が発生する。フィルタの幾つかのクラスでは、こうした制御はかなり標準的である。たとえば、オーディオ・データは音量をセットできるロケーションを有するのが一般的である。同様に、ビデオには、たとえば色調、色彩、コントラスト、輝度、その他といった幾つかの標準パラメータがある。これら標準的な制御の全部をプロキシ・フィルタの統合された一部として備える汎用プロキシ・フィルタ９０を作成することは可能である。しかし、このようなアプローチは一般に汎用プロキシ・フィルタ９０のサイズの増加に継る。したがって、汎用プロキシ・フィルタ９０が必要に応じて制御を組み込むことができるような構造を作成するのが一般に良い。つまり、カーネル・モード・フィルタが音量制御を必要とする場合には、音量制御を汎用プロキシ・フィルタ９０に組み込むことができる。音量制御が必要でない場合、音量制御は組み込む必要がない。図５において、汎用プロキシ・フィルタ９０に組み込むことのできる制御が制御１１０で図示してある。本明細書で用いている術語「制御」は標準的な方法で一般的タスクを実行するソフトウェア・コンポーネントを表わしている。つまり、このような制御はすでに説明したようなパラメータをセットするために使用できる。ひとつの実施例において、制御１１０はActiveX 制御を表わしている。ActiveX は、標準的な方法で標準機能を実行するＣＯＭ技術に基づいたソフトウェア・コンポーネントである。このような制御は、ActiveMovie 製品内部でも使用され、音量、輝度、その他を設定する機能を実行するための標準化された制御が利用できる。

こうした制御を汎用プロキシ・フィルタ９０に組み込む能力は明らかな利点を形成できる。たとえば、カーネル・モード・フィルタ９８の提供者がある種の制御を要求しており、所望の機能を実行する標準制御が存在している場合、カーネル・モード・フィルタ９８の提供者は、定義されている規格に合わせてカーネル・モード・フィルタ９８を作成するだけで、こうした制御を取得し利用できる。汎用プロキシ・フィルタ９０がカーネル・モード・フィルタ９８へ接続するのに適している場合、適当な制御を汎用プロキシ・フィルタ９０に組み込むことができる。つまり、カーネル・モード・フィルタの提供者は、フィルタを作成する時間と努力を払わなくとも、制御の利点を受け取れる。

制御が汎用プロキシ・フィルタ９０に組み込まれている場合、汎用プロキシ・フィルタ９０は制御を組み込むための手段を含む必要がある。図５において、こうした手段がリンク１１２として図示してある。制御を汎用プロキシ・フィルタ９０に組み込むための手段は、こうした組み込みができる何らかのメカニズムを用いて実現できる。汎用プロキシ・フィルタ９０がＣＯＭ技術を用いて実現される場合、また制御１１０がActiveX またはＣＯＭ技術のどちらかに基づいている場合、このような組み込み手段は、アグレゲーション(aggregation) またはコンティンメント(containment) のようにActiveX 制御またはその他のＣＯＭオブジェクトに、ＣＯＭオブジェクトがアクセスするために用いられる標準メカニズムであり得る。こうした術語は当業者には馴染みのものであるが、基本的にアグレゲーションは、ひとつのＣＯＭオブジェクトが別のＣＯＭオブジェクトのインスタンスを取得することにより、取得したＣＯＭオブジェクトのインタフェースをクライアント・プロセスへ提示するプロセスである。これにより、両方のＣＯＭオブジェクトが単一の集合ＣＯＭオブジェクトであるかのように見えることになる。コンティンメントは基本的に同じプロセスだが、取得したオブジェクトのインタフェースが提示されず、単に内部的に保持され使用されるという点で異っている。汎用プロキシ・フィルタ９０が他の何らかの技術を用いて作成される場合、ダイナミック・リンク・ライブラリがロードされる方法と同様にコードを実行時にリンクする、または、ひとつのソフトウェア・コンポーネントを別のソフトウェア・コンポーネントへ実行時に組込できるように開発された幾つかの技術など、他の種類のメカニズムを使用できる。

制御が汎用プロキシ・フィルタ９０に組み込まれた場合、制御からの情報を取り出してカーネル・モード・フィルタ９８で受け入れられる状態にするための変換を実行しなければならないことがある。この概念は、以下で図７を参照して更に詳細に説明するが、ある意味で、制御１１０はユーザ・モードで受け取った情報を取り出してカーネル・モード・フィルタ９８で使用するのに適したフォーマットに変換するものと考えることができる。制御１１０で受け取った情報は制御エージェント４４などの何らかの供給源からのことも、または後述するようにユーザ・インタフェースからのこともある。

ユーザがパラメータまたはカーネル・モード・フィルタの機能に影響する属性を設定できるのが非常に望ましいことが多い。たとえば、オーディオ・データを処理するのに適したフィルタ・グラフの音量を調整できることが非常に望ましい。ユーザが音量を調節する場合、ユーザからの入力を取り出して、音量が調節されるカーネル・モード・フィルタへ最終的に情報を転送するようなユーザ・インタフェースが存在する必要がある。本発明の範囲内の実施例は、したがって、ユーザ・インタフェースを組み込むための手段を含み得る。図５において、こうした手段は、ユーザ・インタフェース１１６のひとつを汎用プロキシ・オブジェクト９０へリンクするリンク１１４で表わしてある。ユーザ・インタフェースを汎用プロキシ・オブジェクト９０へ組み込むために何らかのメカニズムが使用できる。また、正確な選択は汎用プロキシ・フィルタ９０を実現するために使用する技術に依存する。以下で詳細に説明するように、ＣＯＭ技術は、カーネル・モード・フィルタまたは制御がどのユーザ・インタフェースを使用してユーザからの入力を収集すべきかを指定できるメカニズムを提供している。このようなユーザ・インタフェースはユーザからデータを収集し、適当な制御に渡し、最終的にカーネル・フィルタへ転送することができるような方法で汎用プロキシ・フィルタに組み込むことができる。ユーザ・インタフェースをユーザ・モード・プロキシ・フィルタに組み込むひとつの方法を以下で詳細に説明する。

汎用プロキシ・フィルタ９０をカーネル・モード・フィルタ９８へ適合させるのに必要な全ての適当な拡張、制御、フィルタ・ピン、ユーザ・インタフェース、その他の何らかの特性で、汎用プロキシ・フィルタ９０が設定されると、設定プロセスが完了する。汎用プロキシ・フィルタ９０が、これらの種類のコンポーネントのどれを組み込んで特定のカーネル・モード・フィルタに適合させるべきかを識別する際に、どのコンポーネントを含めるべきかについての情報は各種の供給源から入って来る。たとえば、これら全ての情報は、汎用プロキシ・フィルタ９０にコンポーネントを識別させこれらを組み込ませる方法でレジストリに格納される。あるいはまた、何らかの情報をレジストリに記憶しておき、他の情報はカーネル・モード・フィルタ９８から取得するか、または他のコンポーネント自体の幾つかから取得するのでも良い。たとえば、汎用プロキシ・フィルタ９０がカーネル・モード・フィルタ９８の識別とロケーションを取得すると、カーネル・モード・フィルタ９８は何らかの追加の拡張、制御、ピン、またはユーザ・インタフェースを識別できる。ひとつの実施例において、拡張とあわせたカーネル・モード・フィルタ９８の識別とロケーションはレジストリ９２から得られ、一方フィルタ・ピンおよびその他の設定パラメータはカーネル・モード・フィルタ９８から得られる。レジストリ９２のエントリはカーネル・モード・フィルタ９８から受け取った設定を上書きするためにも使用できる。これらの実施例において、カーネル・モード・フィルタ９８はこの情報の一部だけを識別する。これらの設定情報がどこから入って来るかは、汎用プロキシ・フィルタ９０が正しく自己設定できるように十分な情報が取得できる限り問題にならない。

最後のポイントとして、フィルタ・ピン１０８がＣＯＭ技術を用いて実現される場合、他の設定オプションが可能になる。たとえば、ＣＯＭ技術を使用することで、フィルタ自身にではなくフィルタ・ピンへの直接的な制御または拡張のアグレゲーションが容易になる。こうした実施例では、独立した音量制御をミキサーの２つのピンへ直接アグレゲートさせることが可能である。このようなアプローチによると、ユーザ・モード・プロキシ・フィルタに新規で全く異なる設定を行なえる。こうしたアーキテクチャを使用することにより、図５の制御または拡張のいずれかがフィルタにではなくピンにアグレゲートできるようになる。また注意すべきことに、ユーザ・モード・プロキシ・フィルタをこれの対応するカーネル・モード部分がわずかに異なるように設定するのが望ましいか必要な場合が存在することがある。たとえば、ユーザ・モード・プロキシ・フィルタは特定の制御エージェントとの互換性を保証するために個数または種類の異なるピンを有しても良い。別の例として、ユーザ・モード・プロキシ・フィルタのピンがカーネル・モード・フィルタと異なるようにする方法でユーザ・モード・プロキシ・フィルタのピンに制御または他の拡張をアグレゲートさせることが望ましい場合もある。何らかの設定の相違はカーネル・フィルタとインタフェースする方法でプロキシ・フィルタが取り扱うことができる。

上記の説明では汎用プロキシ・フィルタの初期設定について焦点を当てたが、同様のプロトコルを用いてユーザ・モード・プロキシ・フィルタを動的に再設定して、対応するカーネル・モード・フィルタの設定変化に適合させることができる。ユーザ・モード・プロキシ・フィルタの動的再設定をサポートしている技術はすでに説明したマイクロソフトのＣＯＭ技術である。

図６を次に参照して、プロキシ・フィルタの拡張について詳細に説明する。図６において、ユーザ・モード・プロキシ・フィルタ１１８はカーネル・モード・フィルタ１２０のプロキシとして動作する。ユーザ・モード・プロキシ・フィルタ１１８は、たとえば図５の汎用プロキシ・フィルタ９０などの汎用プロキシ・フィルタであったり、または、カーネル・モード・フィルタ１２０の能力全部にアクセスするか提示するように拡張する必要だけがある非汎用プロキシ・フィルタのことがある。ひとつの実施例において、ユーザ・モード・プロキシ・フィルタ１１８に１つまたは２つ以上の「フック・ポイント」を定義することにより、プロキシ・フィルタ１１８へ幾つかの拡張を組み込むことができる。各々のフック・ポイントは拡張を組み込めるロケーションを表わしている。代表的には、こうしたフック・ポイントはプロキシ・フィルタ１１８を開発した時に定義しておく。これらのフック・ポイントは、将来のカーネル・モード・フィルタがどのように動作するかを知ることが困難または不可能なロケーションに配置するのが一般的である。たとえば、２つのカーネル・モード・フィルタを相互に接続するためには、各々のカーネル・モード・フィルタは同じ種類のデータを処理しなければならない。言い換えれば、ビデオ・データを処理するフィルタとオーディオ・データを想定しているフィルタを接続するのは一般に不適切である。ある種のフィルタは種類が異なる多様なデータを受け入れることができる。他のフィルタは各種の異なったデータ形式を発生できる。たとえば、スプリッタ・フィルタはオーディオとビデオ・データを組み合わせたデータ・ストリームを受け入れて、オーディオ・データをひとつのチャンネルに、またビデオ・データを別のチャンネルに振り分ける。同様に、ミキサーはひとつのピンでオーディオ・データを、また別のピンでビデオ・データを受け入れて、オーディオとビデオを合成したストリームを発生する。

カーネル・モード・フィルタが別のフィルタに接続される前に想定しているまたは発生するデータ形式を識別しなければならないことから、プロキシ・フィルタたとえばプロキシ・フィルタ１１８２より典型的に実行される機能のひとつは、カーネル・モード・フィルタたとえばカーネル・モード・フィルタ１２０に対する形式のチェックを実行することである。プロキシ・フィルタ１１８が開発される時に、プロキシ・フィルタ１１８は全ての既知のデータ形式についてカーネル・モード・フィルタ１２０をチェックするように設定できる。しかし、プロキシ・フィルタ１１８が開発された後でデータ形式が定義された場合、または別の状況で、プロキシ・フィルタ１１８に置かれているコードに依存してカーネル・モード・フィルタ１２０をチェックすることはできない。このような状況は、最新のデータ形式またはカーネル・モード・フィルタ１２０で使用されるデータ形式を識別するのに必要な他の情報を含むことができる拡張に取っては典型的である。データ形式をチェックするロケーションでプロキシ・フィルタ１１８にフック・ポイントを設定することにより、プロキシ・フィルタ１１８のデフォルト動作を上書きする拡張をプロキシ・フィルタ１１８がそのポイントに組み込める。基本的に、これらのフック・ポイントは、特定のロケーションでプロキシ・フィルタ１１８から特定の拡張へ実行を移すメカニズム以上の何ものでもない。拡張が所望の機能を実行した後、制御をプロキシ・フィルタに戻すことができる。

拡張に制御を移すプロセスがリンク１２２で図６に図示してある。リンク１２２は、拡張または制御をプロキシ・フィルタへ組み込むための手段の更に別の例を表わしている。プロキシ・フィルタ１１８に組み込まれた制御または拡張がＣＯＭオブジェクトであれば、制御または拡張の機能はインタフェース経由でアクセスまたは提示できる。このような状況が図６に図示してあり、ここで制御または拡張１２４はインタフェース１２６経由でアクセスされ、一方制御または拡張１２８はインタフェース１３０経由でアクセスされる。図６では、どちらをプロキシ・フィルタ１１８に組み込むにも同じメカニズムを使用し得ることから制御または拡張の間に区別はない。説明の目的では、制御または拡張の間の区別はほとんどまたは全く関係がない。

制御または拡張１２４に注目すると、制御または拡張１２４をインタフェース１２６経由でプロキシ・フィルタ１１８がアクセスする場合、制御または拡張１２４は更にカーネル・モード・フィルタ１２０にアクセスする。図６ではこれがリンク１３２によって表わされている。このリンクで表わしているように、カーネル・フィルタの提供者が希望するカーネル・モード・フィルタ１２０の機能へのアクセスがプロキシ・フィルタ１１８によって提示されない場合、カーネル・モード・フィルタの提供者は適当な拡張または制御を提供して、適当なメカニズムを使用して拡張または制御をプロキシ・フィルタへ組み込むことができる。プロキシ・フィルタまたは制御エージェントは提供された制御または拡張を介して機能にアクセスするか、またはこれらの機能をクライアント・プロセスに提示できる。プロキシ・フィルタ１１８がＣＯＭオブジェクトであり、かつ制御または拡張がＣＯＭオブジェクトの場合には、プロキシ・フィルタは制御または拡張を自分自身にアグレゲートさせ、制御または拡張の何らかのインタフェースを制御エージェントに提示することができる。

基本となるカーネル・フィルタにアクセスしないような制御または拡張も提供できる。この状況が図６に制御または拡張１２８で図示してある。場合によっては、制御または拡張はカーネル・フィルタの基本となる機能にアクセスする必要がないこともある。たとえば、カーネル・モード・フィルタを開発した時点でそのフィルタでサポートしているデータ形式に関する全ての情報が分かることが考えられる。十分な形式チェック能力を提供するためには、カーネル・モード・フィルタの提供者はプロキシ・フィルタ１８にフックされる拡張も提供できる。この拡張はプロキシ・フィルタ１１８によって起動された時に分かっている形式情報を返すように予めプログラムしておくことができる。このような状況では、拡張はプロキシ・フィルタ１１８へ適当な情報を提供するために基本となるカーネル・フィルタへアクセスする必要がない。

前述のようにユーザ・モード・プロキシ・フィルタへ組み込まれる拡張は何個かの機能を実行できる。提供できる機能の幾つかの例は前述した。更にひとつの例として、拡張は変換機能を実行できる。図３のフィルタ・グラフは、全てのデータ処理がカーネル・モードで実行されるように図示してあるが、カーネル・モード・フィルタを代理しない１つまたは２つ以上のユーザ・モード・フィルタも含むフィルタ・グラフを作成できることが考えられる。このようなフィルタ・グラフでは、ユーザ・モード・フィルタへ接続するインタフェースの変換をカーネル・モード・フィルタへ接続するインタフェースへ、またはその逆に、提供する必要がある。

図７をここで参照して、ユーザ・インタフェースをプロキシ・フィルタへ組み込むためのひとつのメカニズムを詳細に説明する。図７において、カーネル・モード・フィルタ１３４はユーザ・モード・プロキシ・フィルタ１３６によって代理される。図７に図示してある例では、カーネル・モード・フィルタの動作を変更するために、変更することのできる各種属性をカーネル・モード・フィルタ１３４が有していると仮定しておく。更に、これらの属性を制御または拡張１３８によって変更できると仮定する。このような状況では、制御または拡張１３８はカーネル・フィルタ１３４の提供者によって提供されるか、またはすでに説明したものなどの標準的な制御または拡張とすることができる。制御または拡張１３８はすでに説明したようにプロキシ・フィルタ１３６に組み込まれる。

本発明のひとつの側面によれば、制御または拡張１３８の実施にＣＯＭ技術を使用する場合、制御または拡張１３８はプロキシ・フィルタ１３６に対して、ユーザからの入力を集めるために使用すべきユーザ・インタフェースを通知できる。たとえば、ActiveX の制御は、クライアント・プロセスから呼び出された場合に、ユーザからの入力を収集するために使用できるユーザ・インタフェースまたはユーザ・インタフェース群を返し、入力を制御に移すことができる特定の機能を含む。

ＣＯＭ技術は、特定の制御によって選ばれたユーザ・インタフェースを識別してユーザ・インタフェースからの情報を収集し、収集した情報を制御に渡す一定の方法を提供している。図７の例はこのプロセスがどのように実現されるかを示す。マイクロソフト・ウィンドウズ（登録商標）の用語を用いると、ユーザ・インタフェース・コンポーネントはプロパティ・ページとして認識される。マイクロソフト・ウィンドウズ（登録商標）に詳しい者にはこのオペレーティング・システムで使用されるプロパティ・ページのタブ付きダイアログ・ボックスで特定の情報を収集し、幾つかの属性をセットするのは馴染み深いであろう。図７をここで参照すると、処理は、プロキシ・フィルタ１３６が所望するプロパティ・ページを制御または拡張１３８に問い合わせることから始まる。このような問い合わせと応答がリンク１４０で表わしてある。プロキシ・フィルタ１３６は、個々のプロパティ・ページを保持し表示するために使用するプロパティ・フレーム１４２を作成する。このプロセスはリンク１４４として図７に図示してある。プロパティ・フレーム１４２は表示される各々のプロパティ・ページのためにホルダ・オブジェクトを有する。図７において、これらのホルダ・オブジェクトはホルダ１４６で表わしてある。プロパティ・フレーム１４２は所望のプロパティ・ページ１４８のインスタンスを取得する。次に、ダイアログ・ボックス全体が組み立てられてユーザから収集した情報を表示する。プロパティ・ページが情報を収集すると、これらの情報はリンク１５０で図示してあるように制御１３８へ渡される。制御または拡張１３８は、リンク１５２で表わしてあるようにカーネル・モード・フィルタ１３４へ、または、リンク１５４で表わしたようにプロキシ・フィルタ１３６へ情報を転送する。この処理全体は、一例として、ユーザ・モード・プロキシ・フィルタへユーザ・インタフェースを組み込むための手段を表わしている。この説明は主としてＣＯＭ技術を使用する観点から示しているが、別の技術を用いる他のメカニズムも存在する。重要なことは、ユーザ・インタフェースを認識してこれらのユーザ・インタフェースをユーザ・モード・プロキシ・フィルタへ組み込み、データをユーザから収集しカーネル・モード・フィルタのパラメータを変更するために使用できるようにするプロキシ・フィルタ１３６の能力である。

図５との関連においてすでに説明したように、制御がユーザ・モード供給源たとえばプロパティ・ページ１４８から情報を収集する場合、データの変換または再フォーマットを行なって、データをカーネル・モード・フィルタ１３４にとって適正なフォーマットにする必要がある。機能的には、制御１３８は、受け取ったユーザ・モード・データをカーネル・モード・フィルタ１３４に理解できるフォーマットへ変換する変換器であると考えられる。制御１３８は、適切なインタフェースを介して受け取った何らかのデータを取り出して、カーネル・フィルタ１３４へ渡すことができる。つまり、幾つかの実施例において、データはプロパティ・ページ１４８以外の供給源から入って来ることもある。これは、矢印１５１で示したように、データを制御１３８に渡す制御エージェント４４で図７に図示してある。制御エージェント４４がデータを制御１３８に渡せるようにするのは、たとえば、スクリプト化したマルチメディア・ショーを自動再生するのに有用である。

図８をここで参照すると、特定のカーネル・モード・フィルタで動作するようにユーザ・モード・プロキシ・フィルタを変更するための手段の別の例が図示してある。すでに説明したように、ＣＯＭ技術はＣＯＭオブジェクトの拡張のための２つのメカニズムを提供している。一方のメカニズムはアグレゲーションで他方のメカニズムはコンティンメントである。図８では、コンティンメントの原理を用いて汎用プロキシ・フィルタを変更および拡張し、汎用プロキシ・フィルタが特定のカーネル・モード・フィルタを代理するのに適するようにするにはどうするかを示している。

図８において、カーネル・モード・フィルタ１５６は、汎用プロキシ・フィルタ１５８と包含（コンティンメント）フィルタ１６０の組み合せによって代理されている。この状況において、包含フィルタ１６０と汎用プロキシ・フィルタ１５８の組み合せがカーネル・モード・フィルタ１５６のユーザ・モード・プロキシを提供することに注意することが重要である。これが破線の囲み１６２で図８に図示してある。

コンティンメントの一般概念は、汎用プロキシ・フィルタ１５８がカーネル・モード・フィルタ１５６を代理するのに有用な何らかの機能を実行するが、もっと簡単なメカニズム、たとえばすでに説明したような拡張のフックなどによって提供することのできない追加の拡張が必要とされることである。このような状況において、汎用プロキシ・フィルタを包み込むまたは包含し、汎用プロキシ・フィルタ内部に見付からなかった追加の能力および機能を付与する第２のフィルタが書かれる。図８では、これによって包含フィルタ１６０が必要に応じて汎用プロキシ・フィルタ１５８から特定の機能を呼び出すが、必要とされるところで追加の機能を付加することになる。ＣＯＭで用いられる包含モデルでは、汎用プロキシ・フィルタ１５８のどのインタフェースも、包含フィルタ１６０経由でクライアント・プロセスへ提示されない。包含フィルタ１６０はむしろ自分自身のインタフェースをクライアント・プロセス、たとえば前述したような制御エージェントへ、提示する。図８において、包含フィルタ１６０は汎用プロキシ・フィルタ１５８経由でのみカーネル・モード・フィルタ１５６と通信するように図示してある。幾つかの実施例では、包含フィルタ１６０はカーネル・モード・フィルタ１５６と直接通信することもできる。

組み合せプロキシ・フィルタを作成するプロセスは多数の方法で進めることができる。以下で説明するプロセスは単に一例である。この例では、たとえば制御エージェントなどのクライアント・プロセスがユーザ・モード・プロキシを作成したい場合、クライアント・プロセスは包含フィルタ１６０のインスタンスを作成することから開始する。包含フィルタ１６０はレジストリ１６４から、図示したように問い合わせ１６６と応答１６８によって、特定の情報を取り出す。図８に図示してあるように、取り出される情報のひとつはカーネル・モード・フィルタ１５６の識別とロケーションである。たとえばカーネル・モード・フィルタ１５６で利用できるピンの本数と種類など、追加の情報をレジストリ１６４から取り出すこともできる。

包含フィルタ１６０は多数の機能を提供するために汎用プロキシ・フィルタのインスタンスを使用することになるので、包含フィルタ１６０は汎用プロキシ・フィルタ１５８で図示してあるように汎用プロキシ・フィルタのインスタンスを作成する。作成時に汎用プロキシ・フィルタ１５８はレジストリ１６４から、問い合わせ１７２と応答１７４で示したように、情報を取り出す。図８に図示してあるように、レジストリ１６４から汎用プロキシ・フィルタ１５８によって取り出される情報のひとつは包含フラグである。このフラグは、別のフィルタに包含されることと、スタンドアロンのフィルタとして機能しなくなることを汎用プロキシ・フィルタ１５８に通知する。このようなフラグは、たとえば図５および図６に関連して図示し説明した動作などのある種の動作を上書きするために用いることができる。

汎用プロキシ・フィルタ１５８が作成されると、包含フィルタ１６０は、汎用プロキシ・フィルタ１５８を使用してカーネル・モード・フィルタ１５６を開き、カーネル・モード・フィルタ１５６に関する情報を取り出すことができる。包含フィルタ１６０は汎用プロキシ・フィルタ１５８を制御しているので、包含フィルタ１６０はカーネル・モード・フィルタ１５６のフィルタ名称を汎用プロキシ・フィルタ１５８に渡し得ることに注意すべきである。つまり、包含フィルタ１６０はどのカーネル・モード・フィルタが汎用プロキシ・フィルタ１５８によって開かれているかを調べることができる。汎用プロキシ・フィルタ１５８と包含フィルタ１６０はフィルタ上のピンの形式と本数に関する情報をカーネル・モード・フィルタ１５６から取り出せる。汎用プロキシ・フィルタ１５８と１６０はユーザ・モード・ピン１７０を作成して、これらのピンをすでに説明したように自分自身に組み込む。さらにピン１７０は独立したＣＯＭオブジェクトとして図８に図示してある。たとえば、制御エージェントなどのクライアント・プロセスは、たとえばインタフェース１７６および１７８、または、制御エージェントに提示されていれば、ピン１７０上のインタフェースなど、特定のメカニズムを経由して組み合せユーザ・モード・プロキシ・フィルタの機能にアクセスできる。

特定の実施例は、図８に図示してあるようなコンティンメント（包含）メカニズムか、または図５に図示してあるような取り込みメカニズムを使用して、汎用プロキシ・フィルタを拡張し特定のカーネル・モード・フィルタへ適合させることができる。他の実施例は関連メカニズムの全部を実現できる。特定の汎用プロキシ・フィルタを拡張するために使用される正確な方法またはメカニズムは、汎用プロキシ・フィルタを実現するために使用される特定の種類の技術に大部分が依存している。

カーネル・モードにおけるストリーミング・アーキテクチャの出現によって、現在では全体または大部分がユーザ・モードに常駐する１つまたは２つ以上のフィルタ・グラフ、および、全体または大部分がカーネル・モードに常駐する１つまたは２つ以上のフィルタ・グラフを備えた多数のフィルタ・グラフを有することが可能である。これは、カーネル・モードにあるフィルタ・グラフがユーザ・モードにあるフィルタ・グラフと同期を取る必要のあるような状況を作り出している。ユーザ・モードにあるフィルタ・グラフはユーザ・モード・クロックから時間を受け取り、カーネル・モードにあるフィルタ・グラフはカーネル・モード・クロックから時間を受け取る。つまり、ユーザ・モード・クロックとカーネル・モード・クロックの同期を行なって、ユーザ・モード・フィルタ・グラフとカーネル・モード・フィルタ・グラフの同期が取れるようにするメカニズムを所定位置に配置する必要がある。本明細書の説明全体を通して、術語「クロック」は広い意味に取るべきである。本明細書で用いているように、この術語は時間をフィルタに提供する何らかのコンポーネントを含む。つまり、時間を生成するコンポーネント、ならびに別のコンポーネントから時間を受け取りこれを利用できるようにするコンポーネントは、どちらも術語クロックの範囲に含まれる。

図９を参照すると、同期させる必要のある２つのフィルタ・グラフの表現が図示してある。後述するように、一方のフィルタ・グラフはビデオ・データを処理し、他方のフィルタ・グラフはオーディオ・データを処理する。ビデオ・データを処理するフィルタ・グラフは全体がカーネル・モード内部に常駐する。このようなフィルタ・グラフは上記で参照により含められた特許によって作成できる。一方でオーディオ・フィルタ・グラフは、主としてカーネル・モードで動作するが単一のユーザ・モード・フィルタと、ユーザ・モード・プロキシ・フィルタによって代理される複数のカーネル・モード・フィルタを有している。

ビデオ・データを処理するカーネル・モード・フィルタ・グラフは、リーダ・ドライバ１８０、デコンプレッサ１８２、変換フィルタ１８４、照明(lighting)フィルタ１８６、およびビデオ・レンダラ１８８を含む。オーディオ・フィルタ・グラフはユーザ・モード・リーダ１９０、カーネル・モード・デコンプレッサ１９２、およびこれに付随するユーザ・モード・プロキシ１９４、カーネル・モード効果フィルタ１９６、およびこれに付随するプロキシ効果フィルタ・プロキシ１９８、およびサウンド・レンダラ１９８とこれに付随するプロキシ２００を含む。変換プロセッサ２０２は変換フィルタ１８４が自分の機能を補完するために必要に応じて使用し、照明プロセッサ２０４は照明フィルタ１８６が自分の機能を遂行するために使用する。図９に図示してあるように、ビデオ・レンダラ１８８はビデオ・データをビデオ・カード２０６へレンダリングする。効果プロセッサ２０８はカーネル・モード効果フィルタ１９６が必要に応じて使用し、サウンド・レンダラ１９８はサウンド情報をサウンド・カード２１０へレンダリングし、スピーカ２１２で再生される。ディスク・ドライバ２１４はディスク２１６から、オーディオ・データについてユーザ・モード・リーダ１９０の制御下で、またビデオ・データについてはリーダ・ドライバ１８０の制御下で、情報を取り出す。

図９の２つの処理グラフにおいては、カーネル・モード・クロックをマスタ・クロックとして選択すべきものと仮定する。つまり、図９において、カーネル・モード・クロック２２０がマスタ・クロックであると仮定する。カーネル・モード・クロック２２０は全てのカーネル・モード・フィルタにタイミング情報を提供できる。図９において、これが配給線２２２で図示してある。一方で、ユーザ・モード・フィルタはユーザ・モード・クロックから情報を受信する。ユーザ・モード・フィルタへ情報を提供するためには、カーネル・モード・クロック２２０にユーザ・モード・プロキシを設定できる。図９において、このようなプロキシがユーザ・モード・プロキシ・クロック２２４として図示してある。カーネル・モード・クロックがマスタ・クロックとして選択される場合、カーネル・モード・フィルタのユーザ・モード・プロキシに関連してすでに説明した原理がユーザ・モード・プロキシ・クロックを作成するために応用できる。このようなユーザ・モード・プロキシ・クロックはマスタ・カーネル・モード・クロックからタイミング情報を取り出し、次いでこのタイミング情報をユーザ・モード・フィルタに提供する。図９において、ユーザ・モード・プロキシ・クロック２２４はマスタ・カーネル・モード・クロック２２０からタイミング情報を取り出してこのようなタイミング情報を要求するユーザ・モード・フィルタでこれが利用できるようにする。つまり、配給線２２６がユーザ・モード・リーダ１９０にタイミング情報を提供する。

図９において、デコンプレッサ・プロキシ１９４、効果フィルタ・プロキシ１９８、サウンド・レンダラ・プロキシ２００は破線で配給線２２６に接続されている。これは、このようなプロキシ・フィルタがユーザ・モード・プロキシ・クロック２２４からタイミング情報を取り出す必要がないことを表わすものである。幾つかの実施例では、こうしたフィルタはプロキシ・クロック２２４からタイミング情報を取り出す必要があるが、他の実施例では、このようなタイミング情報が対応するカーネル・モード・フィルタによって提供される。別の例では、ユーザ・モード・プロキシ・フィルタがユーザ・モード・クロックたとえばプロキシ・クロック２２４からタイミング情報を取り出し、さらにこのようなタイミング情報を対応するカーネル・モード・フィルタへ転送することも可能である。つまり、図９において、ユーザ・モード・プロキシ・クロック２２４は、カーネル・モード・クロックのためのプロキシを形成するユーザ・モード・クロックを提供するための手段の一例ではある。同等の機能を提供する他のメカニズムも存在する。

幾つかの実施例において、カーネル・モード・クロックとユーザ・モード・クロックが時間を保持する方法の間には相違がある。たとえば、ActiveMovie クロックはメディア・ストリームが中断している時でも動作し続けている。しかし幾つかのカーネル・モード・クロックの実装において、メディア・ストリームが中断した時に一時停止する。つまり、幾つかの実施例では、カーネル・モード・クロックとユーザ・モード・クロックの間で時間の変換を実行する必要がある。このような状況は、たとえば図９のプロキシ・クロック２２４などのユーザ・モード・クロックを用いて、メディア・ストリームが中断している時でも実行し続けるために、想定するActiveMovie フィルタ・グラフへ時間を供給する場合に発生する。このような状況では、メディア・ストリームが中断した時にカーネル・モード・クロック２２０は停止するが、メディアが中断した時にプロキシ・クロック２２４は動作し続けなければならない場合、プロキシ・クロック２２４は、カーネル・モード時間を適当なユーザ・モード時間に変換するための手段を含むべきである。メディア・ストリームが中断した時にカーネル・モード・クロック２２０が停止する場合、ユーザ・モード・プロキシ・クロック２２４はカーネル・モード・クロック２２０が停止してもクロックを動作させ続けるメカニズムを含む必要がある。カーネル・モード・クロック２２０が動作を再開した時、ユーザ・モード・プロキシ・クロック２２４はカーネル・モード時間をユーザ・モード時間に変換しなければならない。カーネル・モード・クロックとユーザ・モード・クロックとの間、または、カーネル・モード・クロックとユーザ・モード・クロックとたとえばコンピュータ・システムからのハードウェア・クロックなどのマスタ・システム時間との間のいずれかで発生する何らかのクロック・ドリフトを補正するためのメカニズムを配置する必要もある。

メディア・ストリームが停止してから再開した時には、他の問題も発生する。たとえば、フィルタ・デバイスは一般的にすぐに停止または開始しない。つまり、動作を開始するように命令をフィルタ・デバイスへ与えた時、デバイスが実際に起動するまでに短い遅延が発生し得る。更に、デバイスに動作を停止するよう命令した時にも同様の現象が発生し得る。一方でクロックは、事実上瞬間的に起動停止する傾向にある。そのため、クロックの速度を上げるかクロック速度を下げるかのどちらかで、起動停止するフィルタ・デバイスを考慮することによりクロックを「バンプ(bump)」する必要がある。このようなバンプは短時間の間クロックの速度を落すか、短時間の間クロックの速度を上げるかのどちらかで行なうのが望ましい。時間が後向きに移動したり不連続的にジャンプするのは好ましくない。メディア・データのタイムスタンプを用いて、メディア時間にクロックを整列させる補助を行なうことができる。

クロックを「バンプ」させる例はActiveMovie の状況で与えたものであることに注意すべきである。このような結果を要求するものは本発明にはない。本発明を他の状況で使用する場合、クロックをバンプさせて整列させる必要はない。クロック・プロキシはバンプさせずに同期させておくように開発できる。

ここで図１０を参照すると、ユーザ・モード・フィルタ・グラフがマスタであり、カーネル・モード・フィルタ・グラフがユーザ・モード・フィルタ・グラフのスレーブであるような例が図示してある。図１０において、カーネル・モード・フィルタ・グラフは、リーダ・ドライバ２２８、デコンプレッサ２３０、効果フィルタ２３２、サウンド・レンダラ２３４を含む。前述のように、効果フィルタ２３２は効果プロセッサ２３６を使用し、サウンド・レンダラ２３４がサウンド・カード２３８に情報を転送してスピーカ２４０から再生できるようにする。

ユーザ・モード・フィルタ・グラフは、ユーザ・モード・リーダ２４２、デコンプレッサ２４４およびこれに付随するプロキシ２４６、変換フィルタ２４８とこれに付随するプロキシ２５０、照明フィルタ２５２とこれに付随するプロキシ２５４、ユーザ・モード・ビデオ・レンダラ２５６、およびカーネル・モード・ビデオ・レンダラ２５８を含む。カーネル・モード・ビデオ・レンダラ２５８はユーザへ表示するためにビデオ・カード２６０へビデオ情報を渡す。前述のように、ディスク・ドライバ２６２はユーザ・モード・リーダ２４２とリーダ・ドライバ２２８の制御下においてディスク２６４から情報を取り出す。

図１０において、ユーザ・モード・クロック２６６はマスタ・クロックとして選択され、カーネル・モード・クロック２６８はスレーブ・クロックとして選択される。タイミング情報をユーザ・モード・クロック２６６からカーネル・モード・クロック２６８へ転送しなければならないので、実施例ではユーザ・モード・クロックからカーネル・モード・クロックへ時間情報を転送するための手段を含む。図１０において、このような手段はフォワーダ２７０で図示してある。フォワーダ２７０はクロック２６６からタイミング情報を取得して、この情報をクロック２６８へ転送または渡す。クロック２６８はタイミング情報をカーネル・モード・フィルタに提供し、一方でクロック２６６はタイミング情報をユーザ・モード・フィルタへ提供する。フォワーダ２７０はタイミング情報をカーネル・モード・クロックへ転送するための手段の一例を表わしているが、他のメカニズムを使用することもできる。たとえば、クロック２６６はタイミング情報２６８を直接転送するのに適している。これ以外に、フォワーダ２７０がたとえば図９のクロック・プロキシ２２４などのユーザ・モード・プロキシの一部になることがある。このような場合、タイミング情報は、図９に示したような他の方法ではなく、ユーザ・モード・プロキシからカーネル・モード・クロックへ流れることになる。

基本的に、本発明で必要とされることの全部は、スレーブ・クロックをマスタ・クロックに同期する能力である。２つのクロックを同期するために現在利用できる技術のどれかを本発明の有益な効果とともに使用できる。しかし、このような現在の方法に対して他の考案が変更を指示することがある。メディア・ストリームが中断した時に停止するクロックと、停止しないクロックとの間のタイミング変換はこのような考案の一例ではある。

図９および図１０に図示した例は単一のユーザ・モード・クロックと単一のカーネル・モード・クロックを図示しているだけである。しかし、ある種のフィルタ・グラフでは、ユーザ・モードでおよび／またはカーネル・モードでひとつ以上のクロックがある場合がある。このようなフィルタ・グラフには、図９および図１０に図示したのと同じ原理を応用できる。マスタ・クロックが選択され、他のユーザ・モードおよびカーネル・モード・クロックは図９および図１０に図示した原理を用いて同期する。実際に、カーネル・モード・クロックを選択することで、ことなるユーザ・モード・フィルタ・グラフの間で同期を取ることができる。カーネル・モード・オブジェクトは多数のユーザ・モード・プロセスで共通に利用できることから、マスタ・カーネル・モード・クロックを多数のユーザ・モード・フィルタ・グラフの同期に使用できる。幾つかの環境において、多数のユーザ・モード・フィルタ・グラフのクロックを簡単に同期させられる能力は重要である。

本発明は、これの趣旨または基本的特性から逸脱することなく、他の特定の形態で実現することができる。説明した実施例は、あらゆる点で単なる図示であり、制限的なものとみなすべきではない。したがって本発明の範囲は、前述の説明によってではなく添付の特許請求の範囲によって示されるものである。特許請求の範囲の均等の意味するところおよび範囲内に収まる全ての変化は本発明の範囲内に包含されるべきものである。

オーディオ・データを処理するための従来技術のユーザ・モード・フィルタ・グラフを示す図である。 オーディオ・データを処理するためのカーネル・モード・フィルタ・グラフを示す図である。 カーネル・モード・フィルタのためのユーザ・モード・プロキシ・フィルタを組み込むフィルタ・グラフの例を示す図である。 対応するユーザ・モード・プロキシ・フィルタを接続することによりカーネル・モード・フィルタを接続するひとつの方法を示す図である。 特定のカーネル・フィルタを代理するための汎用プロキシ・フィルタの設定のひとつの方法を示す図である。 ユーザ・モード・プロキシ・フィルタに拡張をどのように組み込むかの例を示す図である。 ユーザ・インタフェースをユーザ・モード・プロキシ・フィルタにどのように組み込むかの例を示す図である。 包含による汎用ユーザ・モード・プロキシ・フィルタの拡張を示す図である。 カーネル・モード・マスタ・クロックにより２つのフィルタ・グラフを同期するためのひとつの実施例を示す図である。 ユーザ・モード・マスタ・クロックにより２つのフィルタ・グラフを同期する例を示す図である。

符号の説明

２０，４６，２１６，２６４ ディスク
２２，４８，２１４，２６２ ディスク・ドライバ
２４，１９０，２４２ リーダ
２６，４４ 制御エージェント
２８，５２，１８２，１９２，２３０，２４４ デコンプレッサ
３０ 効果コンポーネント
３２，５４，１９６，２３２ 効果フィルタ
３４，５６，２０８，２３６ 効果プロセッサ
３６，５８ サウンド・レンダリング
４０，６０，２１０，２３８ サウンド・カード
４２，６２，２１２，２４０ スピーカ
５０，１８０，２２８ リーダ・ドライバ
６４ リーダ・プロキシ
６６，１９４，２４６ デコンプレッサ・プロキシ
６８，１９８ 効果フィルタ・プロキシ
７０ サウンド・レンダリング・プロキシ
７４，７８，９８，１２０，１３４，１５６ カーネル・モード・フィルタ
７６，８０，１１８，１３６ プロキシ・フィルタ
９０ 汎用プロキシ・フィルタ
９２，１６４ レジストリ
９４，１６６ 問合せ
９６ カーネル・フィルタ／拡張／他の情報
１０１ フィルタ設定
１０４ 拡張
１０８ フィルタ・ピン
１１０ 制御
１１６ インタフェース
１２４，１２８ 制御／拡張
１４２ プロパティ・フレーム
１４６ ホルダ
１４８ プロパティ・ページ
１５８ 汎用プロキシ・フィルタ
１６０ 包含フィルタ
１６８ カーネル・フィルタ／他の情報
１７０ ピン
１７４ 包含／他の情報
１８４ 変換フィルタ
１８６ 照明フィルタ
１８８，２５６，２５８ ビデオ・レンダラ
１９８，２３４ サウンド・レンダラ
２００ サウンド・レンダラ・プロキシ
２０２ 変換プロセッサ
２０４ 照明プロセッサ
２０６，２６０ ビデオ・カード
２２０，２６６，２６８ クロック
２２４ プロキシ・クロック
２４８ 変換
２５０ 変換プロキシ
２５２ 照明
２５４ 照明プロキシ
２６０ ビデオ・カード
２７０ フォワーダ

Claims (7)

1. カーネル・モードにおけるデータ・ストリームの処理をユーザ・モードにおけるデータ・ストリームの処理と同期させる方法であって、
   複数のカーネル・モード・フィルタを互いに接続して、前記複数のカーネル・モード・フィルタのひとつでデータをまず処理してから、前記複数のカーネル・モード・フィルタのもうひとつへと処理したデータを渡すことにより、データを処理するのに適したカーネル・モード処理グラフを形成し、前記複数の各カーネル・モード・フィルタによりデータが順次処理されるようにするステップであって、ユーザ・モードで動作し、前記複数のカーネル・モード・フィルタの少なくとも２つに対応するユーザ・モード・プロキシ・フィルタの、対応するユーザ・モード・接続点を相互接続するクライアントプロセスに応答して、前記複数のカーネル・モード・フィルタの前記少なくとも２つが有する接続点を互いに接続するステップと、
   前記カーネル・モード処理グラフにおいて、前記複数のカーネル・モード・フィルタが時間を識別できるようにするカーネル・モード・クロックを作成するステップと、
   複数のユーザ・モードフィルタを互いに接続して、前記複数のユーザ・モードフィルタのひとつでまずデータを処理してから、前記複数のユーザ・モードフィルタのもうひとつへ処理したデータを渡すことにより、データを処理するのに適したユーザ・モード処理グラフを形成して、前記ユーザ・モード処理グラフにおいて前記複数の各ユーザ・モードフィルタによりデータが処理されるようにするステップと、
   前記ユーザ・モード処理グラフで前記複数のユーザ・モード・フィルタが時間を識別できるようにするユーザ・モード・クロックを作成するステップと、
   前記ユーザ・モード・クロックまたは前記カーネル・モード・クロックのどちらか一方をマスタ・クロックとするために選択し、前記ユーザ・モード・クロックまたは前記カーネル・モード・クロックのどちらかをスレーブ・クロックとするために選択し、次に前記スレーブ・クロックを前記マスタ・クロックに同期させることで、前記カーネル・モード処理グラフと前記ユーザ・モード処理グラフが同期するようにするステップとを備えることを特徴とする方法。
2. 前記ユーザ・モード・クロックがマスタ・クロックとして選択されたときにフォワーダを作成し、前記フォワーダは前記マスタ・クロックからの現在時刻を取得して前記現在時刻を前記スレーブ・クロックへ転送するように動作し、前記カーネル・モード・クロックが前記フォワーダから前記現在時刻を取得できるようにするステップを更に備えることを特徴とする請求項１に記載のカーネル・モードにおけるデータ・ストリームの処理をユーザ・モードにおけるデータ・ストリームの処理と同期させる方法。
3. 前記カーネル・モード・クロックがマスタ・クロックとして選択された場合に前記カーネル・モード・クロックを前記ユーザ・モード・クロックで代理するステップを更に備え、前記ユーザ・モード・クロックは前記カーネル・モード・クロックから現在時刻を取得することを特徴とする請求項１に記載のカーネル・モードにおけるデータ・ストリームの処理をユーザ・モードにおけるデータ・ストリームの処理と同期させる方法。
4. 前記カーネル・モード処理グラフを用いて前記データ・ストリームを処理するステップをさらに備えることを特徴とする請求項１に記載の方法。
5. 前記ユーザ・モード処理グラフを用いて前記データ・ストリームを処理するステップをさらに備えることを特徴とする請求項１に記載の方法。
6. 前記ユーザ・モード処理グラフに含まれる、前記ユーザ・モード・フィルタのサブセットを用いて前記データ・ストリームを処理するステップと、
   前記ユーザ・モード・フィルタのサブセットの１つを用いて、前記ユーザ・モードと前記カーネル・モードとを分離するセキュリティ境界を横断して前記データ・ストリームを、前記カーネル・モード処理グラフの前記カーネル・モード・フィルタのサブセットに含まれる前記カーネル・モード・フィルタの１つに送信するステップと、
   前記カーネル・モード処理グラフの前記カーネル・モード・フィルタのサブセットを用いて前記データ・ストリームを処理するステップとをさらに備えることを特徴とする請求項１に記載の方法。
7. コンピュータに、請求項１から６のいずれかに記載の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images