JP2004310745A

JP2004310745A - 共有リソースのための通知方法

Info

Publication number: JP2004310745A
Application number: JP2004050482A
Authority: JP
Inventors: Adina M Trufinescu; エム．トルフィンスクアディナ; Khaled S Sedky; エス．セドキハレド
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-03-27
Filing date: 2004-02-25
Publication date: 2004-11-04
Anticipated expiration: 2024-02-25
Also published as: KR20040086543A; JP4638676B2; EP1463268A2; EP1463268B1; KR101066682B1; CN1591341B; CN1591341A; ATE364956T1; EP1463268A3; DE602004006902D1; US7529823B2; DE602004006902T2; US20040193678A1

Abstract

【課題】ユーザインターフェースメッセージが、要求の責任を担うユーザに表示されないので、リソースを要求しているユーザが、リソース要求の失敗が生じたことに気付かないことがある。
【解決手段】共有リソースからの通知を、適切なクライアントに向けて送ることができる。クライアントのリスナ登録を、共有リソースの送信者登録と一致させて、共有リソースから適切なクライアントに通知を転送することができる。ターミナルサーバまたはユーザ簡易切り替え環境において、リスナ登録によって、リスナがセッションに関連する通知に関与することを指定することができる。ローカルまたはリモートセッションに関連する処理についての通知を、その処理を開始したセッションにルーティングすることができる。通知の処理を求める要求は、同じマシンからでも、異なるマシンからでも開始することができる。ユーザ名またはセキュリティコンテキストについての通知を、要望どおりに示すことができる。双方向通信をサポートすることができる。通知を使用して、ユーザインターフェース表示を生成することができる。
【選択図】図３Ｂ

Description

本技術分野は、コンピュータネットワーク上で共有されるリソースなどの共有リソースのための通知方法に関する。

組織は、費用効果の大きい高いレベルの生産性を維持するために、共有コンピューティングリソースにますます依存している。多数のリソースが共有され得るが、共有リソースの身近な例は、一般に印刷キューを用いて共有されるプリンタである。プリンタに印刷しようとする者は、キューに印刷ジョブを追加するソフトウェアを起動する。印刷ジョブは最終的に、適切なソフトウェア（印刷モニタ、印刷ドライバなど）によって処理され、印刷文書などの適切な出力が生成される。

ターミナルサーバ環境
図１に、印刷サービス１１４などのリソースを共有するための例示的な従来のシステム１００を示す。この例は、複数のユーザのためのユーザインターフェース１０４、１０６および１０８をサポートする、ターミナルサーバソフトウェア（ｔｅｒｍｉｎａｌｓｅｒｖｅｒｓｏｆｔｗａｒｅ）１０２を含む。ユーザインターフェース１０４は、ターミナルサーバソフトウェア１０２を実行するコンピュータの物理コンソール（モニタやキーボードなど）１０３に関連付けられるという点で特殊なケースである。コンソール１０３にアクセスするには一般に、ターミナルサーバソフトウェア１０２が実行されているコンピュータシステムに物理的にアクセスすることが必要なので、実際には、コンソールユーザインターフェース（ｃｏｎｓｏｌｅｕｓｅｒｉｎｔｅｒｆａｃｅ）１０４に関連する処理は、特権アクセス権に関連付けることができる。ユーザインターフェース１０６および１０８を、ネットワーク１１０を介してコンソール１０３からリモートで表示することができる。したがって、こうしたユーザインターフェースに特権アクセス権を付与することが望ましくないことがある。

図示するユーザインターフェースのいずれかを使用して、メールサービス、印刷サービス、ファイルサービスなどの共有リソースと対話することができる。こうした共有リソースに対して操作を実施する場合は、こうしたサービスが、そのタスクを遂行するために特権リソースにアクセスするので、ローカルコンソール（ｌｏｃａｌｃｏｎｓｏｌｅ）１０３（セッション０など）に関連する特別なセッション内で共有サービスを実行するのが従来のやり方である。共有リソースについてのメッセージが生成されると、そのメッセージは、適切なタスクに関連するユーザインターフェースに向けられる。したがって、共有サービスでは、こうしたメッセージが、コンソール（セッションユーザインターフェース（ｓｅｓｓｉｏｎｕｓｅｒｉｎｔｅｒｆａｃｅ）１０４など）に送られる。

たとえば、ユーザは、印刷サービスを要求するために、ネットワーク１１０を介してターミナルサーバ１０２と通信して、リモートコンソール上のユーザインターフェース１０６と対話することができる。印刷ドライバは、ローカルコンソールのもとで（すなわちセッション「０」で）実行されている印刷サービス（スプーラなど）によってホストされているため、プリンタ１１４が、プリンタの紙切れを示すメッセージを付けて印刷要求に応答する場合には、そのメッセージが、コンソール１０３に関連するグラフィカルユーザインターフェース１０４に表示される。したがって、リモートのユーザインターフェース１０６で印刷サービスを要求したユーザは、そのプリンタのメッセージを認識しない。

ユーザ簡易切り替え（ｆａｓｔ−ｕｓｅｒ−ｓｗｉｔｃｈ）
図２に、印刷サービス２２２などのリソースを共有するための別の例示的な従来システム２００を示す。この例では、コンピュータ２０６が、「ユーザ簡易切り替え」機能を提供する。ユーザ「Ｄ」用のユーザインターフェース表示２０４がコンピュータ２０６上に現在示されている場合は、ユーザ「Ｄ」をログアウトしないで、ユーザ「Ｅ」が、（たとえば適切なコマンドを用いて）ユーザインターフェース表示２０４をユーザ「Ｅ」用の表示２１２に切り替えることができる。実際には、表示を切り替える前に、パスワードが要求されることがある。同様に、ユーザ「Ｆ」がコンピュータ２０６を使用しようとする場合は、ユーザ「Ｆ」がコマンドをアクティブ化することができ、ユーザ「Ｅ」をログアウトしないで、ユーザ「Ｆ」用のユーザインターフェース表示２１４が、コンピュータ２０６上に表示される。

この例では、ユーザ「Ｄ」２０４が共有リソース（印刷キューなど）にサービスを要求し、プリンタから紙切れのメッセージが受信される場合は、印刷を要求したユーザではなく、コンピュータ２０６が紙切れのメッセージを受信するときに、どのユーザが画面を制御していようとも、そのユーザ表示上にメッセージが表示される。

こうした例では、ユーザインターフェースメッセージが、要求の責任を担うユーザに表示されないので、リソースを要求しているユーザが、リソース要求の失敗が生じたことに気付かないことがある。

ここで述べる技術によって、クライアントのために共有リソースからの通知を提供することができる。たとえば、１つまたは複数の共有リソースと対話している１人または複数のクライアントに、１つまたは複数の通知を送信することができる。

いくつかの例では、複数のクライアントが１つまたは複数の共有リソースを使用する。共有リソースを使用するクライアントは、リスナとして、通知サーバに登録することができる。共有リソースが通知を送る場合には、通知サーバによって、その通知に関連する１つまたは複数のプロパティが、登録されているクライアントに関連する１つまたは複数のプロパティに一致すると判断されたときに、その通知がクライアントに転送される。

送信者登録を用いて、プロパティを通知に関連付けることができる。プロパティは、セッション識別子、ユーザ識別子、通知タイプなどを含み得る。一致を判断するために、通知サーバ上のフィルタ方法を用いることができる。

例によっては、ターミナルサーバが複数のセッションを処理する。セッションに関連する通知を受信するため、セッションについての登録を作成することができる。共有リソースがコンソールセッションで実行されている場合、共有リソース呼び出しの責任を担うセッションに、通知をやはり送り返すことができる。この通知を使用して、そのセッションについてのユーザインターフェース表示を生成することができる。たとえば、ユーザインターフェース表示では、共有リソースの状態を示すことができる。

コンソールセッションで実行されている共有リソースが通知サーバに通知を送信すると、通知サーバは、共有リソース呼び出しの責任を担うセッションの表示を含み得る、共有リソースについての登録済みプロパティを比較する。共有リソースについて登録された適切なプロパティが、そのセッションについて登録されたプロパティと一致することが判断されると、それに従って通知が転送される。その通知を使用して、ユーザインターフェース表示を生成する（たとえば、共有リソースを要求したセッションについてのユーザインターフェースを生成する）ことができる。

複数のセッションを伴うターミナルサーバまたは他のシナリオでは、共有リソースを要求した通知用のユーザインターフェース表示を生成することによって、プライバシーを保護し、セキュリティを強化することができる。通知は、別のユーザから見られない、またはアクセスされない私的なまたはセキュリティの情報を含み得る。さらに、通知は、関連する機能（処理のキャンセルなど）を含み得る。別のユーザによってアクセス可能であり得るコンソールセッションに通知を送信するのではなく、リソースを要求したセッションによる処理のため通知が送信される。このようにして、リソース要求およびリソース制御に関する表示情報が、リソースを要求した当事者の元にとどまることになる。

通知サービスは、通知に対する返信をサポートすることができる。したがって、双方向通信をサポートすることができる。

登録に関連するプロパティを、登録側クライアントまたは共有リソース以外のソースから取得することができる。たとえば、クライアントの登録呼び出しに関する情報またはセキュリティコンテキスト（ｓｅｃｕｒｉｔｙｃｏｎｔｅｘｔ）からプロパティを取得することができる。セッション識別子の場合、呼び出し側クライアントに関連するセッション識別子を、以降の取出し（クライアントによって使用される共有リソースの登録時など）に備えて格納することができる。

通知サービスは、通知に含まれるデータに関係なく動作することができる。たとえば、通知タイプによって、通知がどのように処理されるかを示すことができる。通知サービスは、どんな通知タイプの通知をも処理し転送することができる。

追加の特徴および利点は、添付の図面を参照して行う、図示する実施形態についての以下の詳細な説明から明らかになろう。

（実施例１）
例示的なシステム概要
図３Ａに、共有リソース３０６についての通知を適切なクライアント３２６に向けて送る、例示的なシステム３００を示す。たとえば、通知３１６に関連するプロパティとクライアント３２６に関連するプロパティの比較に基づいて、通知３１６をクライアント３２６に転送することができる。１つの共有リソース３０６、１つの通知３１６、および１つのクライアント３２６だけが示されているが、実際には、システムは、複数のリソース３０６、複数の通知３１６、複数のクライアント３２６、またはその何らかの組合せを含み得る。

（実施例２）
別の例示的なシステム概要
図３Ｂに示す例示的なシステム３３０では、１つまたは複数の通知が、１つまたは複数の共有リソース３３２から通知サーバ３３４に送信され、この通知サーバは、１つまたは複数のクライアント３４０Ａ、３４０Ｂに、少なくともその通知の表示を送信する（通知の転送など）。他の仲介が通知の転送に関与することがあり、共有リソースまたはクライアントは、通知サーバによってホスト（たとえば、通知サーバと同じプロセスで実行）され得る。

この例では、通知サーバ３３４は、共有リソースに関連付けられており、通知が共有リソース３３２から受信されたときに参照される送信者登録３３６を含む。同様に、リスナ登録３３８Ａは、クライアント３４０Ａに関連付けられており、受信された通知がクライアント３４０Ａに一致し、そこに転送すべきかどうかを判断するために参照される。同様に、リスナ登録３３８Ａは、クライアント３４０Ｂに関連付けられる。

登録３３６、３３８Ａ、３３８Ｂは、プロパティ３３７、３３９Ａ、３３９Ｂをそれぞれ含む。通知ルーティングの制御のため、送信者プロパティ３３７をリスナプロパティ（ｌｉｓｔｅｎｅｒｐｒｏｐｅｒｔｙ）３３９Ａ、３３９Ｂと比較して、一致しているものがあるかどうかを判断することができる。プロパティのサブセットが同一であるかどうかなど、様々なやり方で一致を定義することができる。プロパティによっては、一致するいずれかの値として定義することができる。

（実施例３）
別の例示的なシステム概要
図３Ｃに、通知をクライアントに送信する、別の例示的なシステム３５０を示す。例示的なシステム３５０では、１つまたは複数のクライアント３５２、３５４が、１つまたは複数のサーバ３５６、３５８を使用して、１つまたは複数の共有リソース３５７、３５９に（たとえば要求３６０、３６２を介して）アクセスする。さらに、クライアント３５２は、通知サーバ３６４に、リスナとして登録して、リスナ登録３６６を作成することができ、サーバ３５６は、通知サーバ３６４に、送信者として登録して、送信者登録３６８を作成することができる。

この例では、送信者登録３６８を有する共有リソースサーバ３５６によって通知が生成されると、通知サーバ３６４のフィルタ方法３７０が、通知の表示を受信するために登録されているクライアントがいるかどうかを判断する。たとえば、クライアント３５２は、特定のサーバ３５６の共有リソースについて関連するリスナ登録３６６を有しており、フィルタ３７０によって、そのクライアントがリスナ登録３６６のプロパティに一致する通知のために登録されていると判断された場合に、通知の表示を受信する。

この例では、図３Ｃに示すエンティティ（クライアント３５２、３５４、サーバ３５６、３５８および通知サーバ３６４など）は、プロセスアドレス空間（ｐｒｏｃｅｓｓａｄｄｒｅｓｓｓｐａｃｅ）に依存しない。たとえば、エンティティは、同じプロセス空間で実行されるオブジェクトでも、同じプロセス空間で動作するスレッドでも、またネットワーク上のどこかで、異なるマシン上の異なるプロセス空間でそれぞれが動作する別個のプロセスでもよい。またシナリオは、共有された別個のプロセスまたはアドレス空間の置換えおよび組合せを含み得る。いずれの例でも、共有リソース、クライアントまたサーバは、プログラム、プロセス、スレッド、（たとえばオブジェクトモデルによる）コンポーネント、複合プログラム、（たとえば動的にリンクまたはパッケージ化された）複合コンポーネントなどであり得る。

（実施例４）
例示的な共有リソース
いずれの例でも、１つまたは複数のサーバによって、１つまたは複数のクライアントから１つまたは複数の共有リソースにアクセスできるようになる。例示的な共有リソースは、ファイルサービス、メールサービス、印刷サービス、あるいは他の任意の共有アプリケーション、プログラムまたはサービスを含む。

プリンタなどの物理デバイスは時には、共有リソースと称されるが、適切なソフトウェアの対応物（印刷キューなど）がしばしば存在する。

いずれの例でも、共有リソースは、関連するサーバに対してローカルにでも、外部的にでも実行することができる。たとえば、サーバは、共有リソースの実行をホストすることができる。

（実施例５）
印刷シナリオにおける例示的な共有リソース
いずれの例にも適用される例示的なプリンタシナリオ（ｐｒｉｎｔｅｒｓｃｅｎａｒｉｏ）では、印刷スプーラは、コンソールセッション（すなわち「０」）の、ターミナルサーバ環境で実行される通知サーバの働きをし、共有リソースは、通知サーバによってホストされる印刷ドライバであり得る。

こうしたシナリオでは、印刷スプーラ／通知サーバは、印刷ドライバ、印刷プロセッサ、印刷モニタなどスプーラによってホストされているコンポーネントが、様々なセッションおよびセキュリティコンテキストで実行されているアプリケーションに通知を送信（またそこから返信を受信する）するやり方を提供する。したがって、スプーラプロセスで実行される印刷コンポーネントは、印刷ジョブが開始されたセッションまたはコンテキストに、ユーザインターフェース通知を送信することができる。このシナリオを用いて、クライアント／コンポーネントがスプーラアドレス空間（ｓｐｏｏｌｅｒａｄｄｒｅｓｓｓｐａｃｅ）の内部に存在しようが、外部に存在しようが、登録されているどのクライアント／コンポーネントにも通知を送信することができる。

別のシナリオでは、印刷プロセッサの手差し両面コンポーネントが共有リソースになることがあり、通知システムを使用して、クライアントコンポーネントに通知を送信して、ユーザにページをめくるように伝えるユーザインターフェースを表示する。別のシナリオでは、ドライバ自動構成コンポーネントが共有リソースになることがあり、通知システムを使用して、ドライバのリッチ状態（ｒｉｃｈｓｔａｔｕｓ）を更新する。別のシナリオでは、ファックスコンポーネントが共有リソースになることがあり、通知システムを使用して、ファックスが受信されたことの通知を送信する。

（実施例６）
例示的なリスナおよび送信者プロパティ
リスナおよび送信者のプロパティは様々な形をとり得る。一実装では、少なくとも１つの識別コンテキストプロパティ（ｉｄｅｎｔｉｔｙｃｏｎｔｅｘｔｐｒｏｐｅｒｔｙ）が、通知に関連付けられる。次いで通知に関連付けられた識別コンテキストプロパティを、（たとえば登録を用いて）潜在的なリスナのプロパティ（リスナの登録に関連付けられたプロパティなど）と比較し、もしあれば、一致するものを見つけることができる。

識別コンテキストプロパティは、ユーザ識別子、セキュリティコンテキスト識別子（セキュリティｉｄすなわち「ＳＩＤ」など）、セッション識別子（ターミナルサーバセッション（ｔｅｒｍｉｎａｌｓｅｒｖｅｒｓｅｓｓｉｏｎ）の識別やユーザ簡易切り替えセッションの識別など）、またその何らかの組合せを含み得る。

ターミナルセッション識別子（ｔｅｒｍｉｎａｌｓｅｓｓｉｏｎｉｄｅｎｔｉｆｉｅｒ）は、数あるセッションからあるセッションを識別できるほど十分な１つまたは複数の識別子を含むことができる。場合によっては、こうした識別子は、複数のターミナルサーバ上の複数のセッションを区別し得る。

識別コンテキストプロパティの代わりに、またはそれに加えて使用することができる他の例示的なリスナおよび送信者プロパティは、通知タイプ（グローバル一意識別子、メッセージ形式識別子、タイプバージョン番号、タイプ有効期限など）、通信タイプまたはプロトコルタイプ（双方向チャネル、単一方向チャネル、非同期メッセージなど）、プロセス識別子、共有リソース識別子、マシン識別子、ネットワーク場所情報、別の識別またはネットワークトポロジの識別子（ｎｅｔｗｏｒｋｔｏｐｏｌｏｇｉｃａｌｉｄｅｎｔｉｆｉｅｒ）、他のメッセージルーティングまたは識別情報、あるいはその何らかの組合せを含む。

適切なプロパティを指定することによって、リスナは、どの通知を受信したいかを指定することができる。一部の場合では、（たとえばユーザの識別またはセッションを指定するときなど）プロパティを、送信者／リスナによって指定することができるが、他の場合では、送信者／リスナについてのプロパティを収集し、確認し、またその両方を行うことができる。

（実施例７）
通知を処理するための方法の例示的な概要
図４Ａに、通知の送信を遂行するための例示的な方法４００を示す。この方法および本明細書で示す他のいずれの方法も、コンピュータ実行可能命令を用いてソフトウェアで実装することができる。

４０２で、共有リソースについての通知が受信される。４２２で、通知に基づいてまたそれに応答して、少なくともその通知の表示が、（送信者とリスナなどの）プロパティの比較に基づく適切なクライアントに送信される（たとえば通知が転送される）。こうしたプロパティは、たとえば送信者（共有リソースやサーバなど）およびリスナ（サーバまたは共有リソースのクライアントなど）の登録時に判断することができる。

４２２の送信される通知は、４０２の受信された通知と同じフォームを含んでも、それと同じフォーム（たとえば通知を転送する）でも、また異なるフォームでもよい。図４Ａに示す操作は、通知サーバでも、他の何らかのソフトウェアでも実施することができる。

（実施例８）
登録を含む例示的な方法
図４Ｂに、登録を用いて通知の送信を遂行するための例示的な方法４５０を示す。４５６で、送信者（サーバや他の共有リソースなど）が、登録要求の結果として、通知送信のため（通知サーバなどに）登録される。実際は、こうした登録要求は、通知を送信しようとするエンティティ（サーバまたは他の共有リソース）によって送信されるが、送信者の代理で、（たとえば共有リソース用のサーバによって）登録を実施することができる。

送信者の登録は、送信者プロパティを取得することを含み得る。この送信者プロパティは、（たとえばパラメータを用いて）登録要求自体に設けられることも、何らかの別の方法によって（たとえば、要求のソースに関する情報を判断することによって）決定されることもある。送信者プロパティは、本明細書で述べるどの例示的な送信者プロパティをも示すことができる。

送信者の登録は、送信者プロパティを送信者に関連付けることを含み得る。ある例では、送信者登録コンポーネントが作成され、関連付けが、（たとえば識別子によって）送信者に関連付けられたプロパティおよび送信者識別子（共有リソース識別子など）を保持する、コンポーネント内に（たとえばデータ構造体として）含められる。

４５８で、登録要求の結果として登録を受信するため、リスナ（クライアントなど）を（通知サーバなどに）登録する。実際には、こうした登録要求は、リスナから送信されるが、登録をリスナの代理で実施することができる。

リスナの登録は、リスナのプロパティを取得することを含み得る。このリスナプロパティは、（たとえばパラメータを用いて）登録要求自体に設けられることも、何らかの別の方法によって（たとえば、要求のソースに関する情報を判断することによって）決定されることもある。リスナプロパティは、本明細書で述べる例示的な、どのリスナプロパティをも示すことができる。

リスナの登録は、リスナプロパティをリスナに関連付けることを含み得る。ある例では、リスナ登録コンポーネントが作成され、プロパティは、コンポーネントに（たとえばデータ構造体として）格納され、（たとえば識別子によって）リスナに関連付けられる。

４６０で、共有リソースについての通知が（たとえばそこから）受信される。いずれの例でも、通知は、共有リソースから送信されたオブジェクトを示すことを含み得る。オブジェクトは、通知を表し、通知のためのデータを含むことができる。

４６６で、通知を受信したことに応答して、この方法では、（たとえば、通知を送信する共有リソースによって登録されている）送信者プロパティを、登録されているリスナプロパティと比較する。４６８で、もしあれば、登録済みの送信者プロパティに一致する登録済みのリスナプロパティを有する１つまたは複数のリスナ（クライアントなど）に、少なくともその通知の表示が送信される（たとえば通知が転送される）。

特権を有する一部のクライアント（管理者によって実行されるコンポーネントなど）は、（たとえば特権を有するなど）特殊なタイプの通知、また他のユーザに送信される通知のために登録することができる。こうしたケースでは、プロパティ間の一致は、適切な送信者プロパティ（ユーザ識別子など）が、同じプロパティのいずれかの値（いずれかのユーザなど）または特定の値（指定されたユーザなど）のプロパティと一致するように定義することができる。

またクライアントコンポーネント自体が、こうした通知のためにプロパティを登録していないとしても、特権を有するクライアントは、他のコンポーネントにある特定の通知（他のセッションについての通知など）を受信させるために登録を作成することができる。

所望であれば、次いで登録を閉じることができ、または追加の通知を送信することができる。４７４で、送信者の登録を閉じる。４７８で、リスナの登録を閉じる。

図面では、明示的には図示されていないが、シナリオによっては、この方法は、様々な要求を受信する間は待機状態になり得る。所望であれば、操作の順序（４５６／４５８および４７４／４７８など）は並べ替えても、逆にしてもよい。したがって、非同期動作をサポートすることができる。

（実施例９）
印刷シナリオにおける登録を伴う例示的な方法
図４Ｂに示す方法を、様々な印刷シナリオで使用することができる。あるシナリオでは、クライアントコンポーネントは、そのセキュリティコンテキストで実行される間に印刷ドライバコンポーネントによって生成される通知のために登録する。別のシナリオでは、クライアントコンポーネントは、ある特定のターミナルセッション（クライアントと同じターミナルセッションなど）で実行される印刷モニタコンポーネントによって生成される通知のために登録する。別のシナリオでは、クライアントコンポーネントは、特定の通知タイプのスプーラ通知のために登録する。

このようにして、クライアントに所望の通知を提供することができる。クライアントは、印刷サーバと同じマシン上でも、異なるマシン上でも実行することができる。クライアントマシンは、ユーザがリモートでターミナルサーバセッションに接続する、ターミナルサーバであり得る。

（実施例１０）
例示的なクライアント登録および通知方法
図５に、通知サーバから通知を受信するためにリスナプロパティを登録するクライアントプログラムによって実施される例示的な方法５００を示す。あるシナリオでは、クライアントは、ターミナルサーバで実行されるセッションに関連付けられる。別のシナリオでは、クライアントは、複数のユーザ（ユーザ状態など）のうち１つに関連付けられ、ユーザは、あるコンピュータ環境で、ログオンまたはログオフを行わないで、複数ユーザ間の切り替えを行うことができる。クライアントは一般に、共有リソースにサービスを要求し、通知サーバを介して通知のために登録する複数のクライアントのうち１つである。

５０２で、クライアントは、通知サーバに、１つまたは複数のリスナプロパティを登録する。リスナプロパティは、パラメータを用いてクライアントから、または別の方法で（たとえばクライアントがどのセッションで実行されているかを判断することによって）取得することができる。上述のように、管理者の代理で実行されるコンポーネントは、追加の機能を有し得る。次いでクライアントは、通知サーバから登録済みプロパティと一致する通知を受信するまで、他の処理タスクを続けることができる。

５０４で、クライアントが通知を受信する。こうした通知は、クライアントのために登録されたプロパティと、（たとえば通知の送信者のために登録された）通知に関連するプロパティの一致に基づいてクライアントに転送することによって発信することができる。

５０６で、通知が受信されると、クライアントはその通知を処理する。この例では、クライアントコンポーネントが画面用のユーザインターフェース表示（ダイアログボックス（ｄｉａｌｏｇｂｏｘ）や他のグラフィカルユーザインターフェース要素）を生成する。たとえば、ユーザインターフェース表示では、共有リソースの状態（エラー処置のためユーザに表示されるエラー状態など）を示すことができる。しかし、適切な機能を指定することによって、他のどんな処理も可能である。

あるシナリオでは、適切なユーザインターフェースが、リスナプロパティまたは通知オブジェクト自体に置かれた通知タイプ識別子（グローバル一意識別子など）を用いて、クライアントコンポーネントによって識別される。ターミナルサーバのセッションで実行されるクライアントを伴う例では、生成されたユーザインターフェースをリモートターミナルで表示することができる。

受信５０４および処理５０６の繰り返しを、複数回、実施することができる。所望であれば、また通知サーバからの追加の通知を望まない場合には、５１２で、クライアントは、通知サーバに登録されているリスナプロパティを閉じるように要求することができる。再登録することによって、追加の通知を受信することができる。あるシナリオでは、クライアントが他のコンピューティングタスクを処理しており、コンポーネントの寿命は、クライアントが、いずれかの共有リソースから通知を受信するために、どのくらいの期間登録されているかによって限定されるものではない。

（実施例１１）
例示的な共有リソースの登録および通知方法
図６に、通知を送信するための送信者プロパティ登録のため、共有リソースによって実行される例示的な方法６００を示す。あるシナリオでは、共有リソースは、印刷スプーラで実行される印刷コンポーネントである。別のシナリオでは、スプーラは、印刷コンポーネントの共有リソースをホストする通知サーバである。別のシナリオでは、共有リソースは、複数のユーザによって共有されるコンピュータ上で実行される印刷ドライバであり、ユーザは、ログオンまたはログオフなしに、ユーザ状態の切り替えを行うことができる。共有リソースは一般に、通知サーバからの通知のために登録している複数の要求元クライアントにリソースを提供する。

６０２で、共有リソースは、通知サーバに、１つまたは複数の送信者プロパティを登録する。送信者プロパティは、（たとえばパラメータを用いて）共有リソースから、または別の方法（たとえば共有リソースがどのセッションで実行されているかを判断することによって）取得することができる。

６０４で、共有リソースは、通知サーバに通知を送信する。こうした通知を最後には、適切な登録済みプロパティを有する１つまたは複数のクライアントに転送することができる。送信６０４を繰り返すことによって、２つ以上の通知を送信することができる。

所望であれば、また追加の通知が送信されない場合には、６１０で、この方法は、通知サーバへの登録を閉じる。再登録することによって、追加の通知を送信することができる。

（実施例１２）
送信者／リスナプロパティを取得するための例示的な技術
いずれの例でも、登録のため格納されている送信者／リスナプロパティを様々なやり方で取得することができる。たとえば、プロパティを、リスナまたは送信者を登録する呼び出しに含まれるパラメータとして渡すことができる。

しかし、場合によっては、呼び出し側クライアント以外のソースからプロパティを取得することが有利であり得る。たとえば、こうした情報は、クライアントからの呼び出し（リスナまたは送信者を登録する呼び出しなど）またはクライアント呼び出し側（登録している呼び出し側など）に関する情報から、取得することができる。こうした情報は、システムサービス（セキュリティまたはＲＰＣサービスなど）から収集することができる。たとえば、識別コンテキストプロパティの場合では、こうしたプロパティをそのようにして取得することができる。

セッション識別子の場合は、通知サービス（通知サーバなど）を呼び出すクライアントは、それが実行されているのと同じセッションについての通知のために登録を望んでいることを指定することができる。こうしたセッションは、登録呼び出しまたは（たとえばＲＰＣサブシステムからの）登録している呼び出し側に関する情報を取得することによって決定することができる。ユーザ識別子またはセキュリティコンテキストについて、同様の手法を用いることができる。

サービスを要求する呼び出しが、登録している送信者（共有リソースまたは共有リソースをホストするサーバ）によって受信されると、クライアント呼び出しまたは呼び出し側クライアントに関する情報を、以降の取出しに備えて（たとえばメモリに）格納することができる。たとえば、共有リソースが引き続き、送信者としての登録を望む場合は、こうした格納済みプロパティを使用することを指定することができる。このようにして、共有リソースは、共有リソースを実行する対象であるセッションと同じセッションにその通知を送信するために登録を望むことを指定することができる。

セキュリティコンテキストなどの他のソースから、プロパティを収集することもできる。たとえば、セキュリティコンテキストでは、どのユーザのためにシステムサービスが実行されているか（たとえば、サービスがどのユーザを偽装しているか）を示すことができる。

さらに、登録呼び出しまたは登録している呼び出し側から情報を収集すると、それを使用して、別のセッション、ユーザまたはセキュリティコンテキストについての通知のためにリッスン（ｌｉｓｔｅｎ）したいことを呼び出し側が確実に指定するようにできるので、追加のセキュリティがもたらされ得る。一部の場合では（たとえば管理権限に関連する呼び出しでは）、こうしたシナリオを受け入れることができるが、他の場合では、こうした盗聴を許すことは、望ましくないセキュリティおよびプライバシーの違反であり得る。

（実施例１３）
登録を含む例示的なシステム概要
図７に、例示的な通知システム７００を示す。シナリオ７００では、１つまたは複数のクライアント７０２、７０４が１つまたは複数のサーバ７０６、７０８を使用し、これらのサーバが、クライアントに、１つまたは複数の共有リソースを提供する。この例では、複数のクライアント７０２、７０４が、共有リソースを提供する複数のサーバ７０６、７０８にサービスを要求する。さらに、クライアント７０４は、リスナ登録７１６、７１８によって、通知サーバ７２０にそれ自体を登録し、サーバ７０６は、送信者登録７２２によって、通知サーバ７２０にそれ自体を登録し、また別のサーバ７０８は、送信者登録７２４によって、通知サーバに登録する。このシナリオでは、通知が、送信者登録７２２を有するサーバ７０６によって生成されると、通知サーバ７２０は、０または１つ以上のクライアントにメッセージの表示を送信するべきかどうかを判断するために、登録７２２について格納されているプロパティと、リスナ登録７１８、７１６、７２６について格納されているプロパティを比較する。

この例では、通知サーバ７２０は、１つのサーバ７０６をホストし、関連する登録７２４を含むリモートサーバ７０８をサポートする。他のシナリオでは、通知サーバは、複数のサーバをホストし、複数のリモートサーバをサポートし、またはその両方を行う。この例では、クライアント７０４は、複数のリスナ登録７１６、７１８を含む。こうした複数のクライアント登録を使用して、（１）同じサーバから異なるタイプの通知を受信する、（２）同じサーバによってホストされる複数の異なる共有サービスから複数の異なる通知を受信する、（３）同じ通知サーバによってホストされる複数のサーバから通知を受信する、（４）複数のサーバによってホストされる共有リソースから複数の通知を受信する、またその何らかの組合せを行うことができる。

図示していないが、たとえばそれぞれ異なる通知タイプについての通知を送信するために、またはサーバによってホストされている複数の共有リソースから通知を送信するために、サーバは、同じ通知サーバに、複数の送信者登録を登録することができる。さらに、たとえば、サーバによって提供されるリソースを共有するクライアントが、潜在的に異なる通知サーバに、リスナとして登録されると予想される場合には、サーバは、複数の通知サーバ（図示せず）に、送信者として登録することができる。

（実施例１４）
例示的なターミナルサーバ通知システム
図８に、ターミナルサーバのシナリオ（ｔｅｒｍｉｎａｌｓｅｒｖｅｒｓｃｅｎａｒｉｏ）で使用する別の例示的な通知システム８００を示す。システム８００で、ターミナルサーバ８１４は、複数のセッション８０２、８０４、８０６、および（たとえば共有リソースを提供する）サーバ８２０をホストする通知サーバ８２２を実行している。あるいは、通知サーバ８２２は、ターミナルサーバ８１４の外部で実行することもできる。

ユーザが、ターミナルサーバ対応のコンピュータにログオンすると、そのユーザ用のセッションが開始される。そのセッションのために実行される処理は、一意のセッション識別子に関連付けられる。特殊なセッション識別子（すなわち「０」）がコンソールに関連付けられ、コンソールセッション８０２のためのユーザインターフェース８０８が一般に、ローカルで表示される。あるセッションで実行される特定の処理（印刷などのシステムサービス）は、別のセッションの代理で実行されている場合でも、コンソールに関連付けられる。

この例では、リモートユーザは、ネットワーク８１６を介して、リモートターミナル８１０からターミナルサーバにログオンし、セッション識別子「１」が割り当てられたセッション８０４（プロセスなど）で処理が遂行される。別のリモートユーザは、ターミナルサーバ８１４への専用接続を介して、リモートターミナル８１２からターミナルサーバにログオンし、セッション識別子「２」が割り当てられたセッション８０６（プロセスなど）で処理が遂行される。こうしたターミナルサーバシナリオでは、ターミナルサーバ８１４上で実行される複数のクライアントセッション（ｃｌｉｅｎｔｓｅｓｓｉｏｎ）８０２、８０４、８０６が、共有リソース８２０にアクセス８１８する。この例では、共有リソース８２０は、通知サーバ８２２によってホストされる。

セッション８０２、８０４、８０６は、適切な通知（セッション登録についての通知など）を受信するため、リスナ登録８３０を作成することができる。登録作成の要求を受信する際に、要求の発信元のセッションを（たとえばＲＰＣサブシステムを介して）判断することができる。このようにして、登録が管理者用に作成されない限りは、セッションが、他のセッションからの通知（たとえば他のセッションの盗聴）のために登録しないようにすることができる。またセッションは、同じユーザについての通知を受信したいことを、そのセッションとは関係なく、指定することができる。この場合も、登録が管理者用に作成されない限りは、他のユーザについての通知のため登録が行われないように、要求に関連するユーザを決めることができる。

次いで、あるセッションのための処理が、サーバ８２０にアクセスする場合は、サーバ８２０に関連する共有リソースは、通知の生成を希望することができる。通知が送信される前に、またはそのときに、適切な送信者登録８２６を作成することができる。次いで送信者登録８２６を用いて、通知を送信することができる。

サーバ８２０または共有リソースがコンソール８０２に関連付けられている（たとえば、それがシステムサービスである）場合には、それは別のセッション８０４、８０６のために開始された可能性がある。セッションが、サーバ８２０に対して呼び出しを行うときに、呼び出しを開始するそのセッションに関するセッション識別子を（たとえばスレッドローカル記憶域（ｔｈｒｅａｄｌｏｃａｌｓｔｏｒａｇｅ））に格納することができる。その呼び出しに関する情報を取得することによって、セッションを判断することができる。次いで、サーバ８２０に関する共有リソースが、送信者として登録しようとする場合には、格納されている識別子を参照することによって、適切なセッション識別子を、送信者登録に関連付けることができる。このようにして、共有リソースは、コンソールではなく、それを開始したセッションに、通知を送信することができる。

サーバ８２０のいずれかの共有リソースから通知を受信すると、通知サーバ８２２は、一致するリスナプロパティを有する登録されているセッションに、通知の表示を転送するかどうかを判断するために、送信者登録８２６内の共有リソース８２０について登録されたプロパティと、セッションによって、リスナ登録８３０に登録されたプロパティとを比較する。たとえば、リスナ登録が、リスナと同じセッションに関する通知が望まれていることを示している場合には、そうした通知が送信される。あるいは、リスナ登録が、リスナと同じユーザに関する通知が望まれていることを示している場合には、そうした通知が送信される。

これによって、複数のクライアントセッションが、共有リソースを共有し、また通知が生成されたときに、共有リソースがどのセッションで実行されているかに関係なく、通知をやはり受信することができる。たとえば、セッション８０４は、サーバ８２０によって提供される関連する共有リソース（外部リソース用のサーバなど）に、適切な要求を送信することによって、外部リソース８２８によるタスクの実施を要求することができる。外部リソース８２８が、サーバ８２０によって提供される共有リソースにメッセージを送信すると、サーバ８２０によって提供される共有リソースが、コンソールセッション８０２のもとで実行されていたとしても、メッセージの表示を適切なセッション８０４に送り返すことができる。したがって、セッション「０」コンソールにではなく、共有リソースを要求したセッション８０４に関連するユーザインターフェース８１０に、メッセージを送信することができる。

場合によっては、こうした手法によって、セキュリティを強化することができる。たとえば、セッション８０４のユーザが、他のものが外部リソース８２８に関連する動作について知ることを望まない場合には、コンソールユーザインターフェース８０８に、リソース８２８に関するメッセージを送信することが、セキュリティまたはプライバシーの違反になり得る。さらに、メッセージが、処理を開始したユーザではなく、コンソールに送信されるときには、場合によっては、コンソールユーザインターフェース８０８のユーザに、処理に関するオプション（処理のキャンセルまたは削除など）が提示され得る。処理を開始したユーザインターフェース８１０にメッセージの表示を可能にすることによって、セキュリティおよびプライバシーの強化をもたらすことができる。

（実施例１５）
印刷シナリオにおける例示的なターミナルサーバ通知システム
図８に示す例示的な通知システム８００を印刷シナリオで使用して、ターミナルサーバ環境内の適切なユーザまたはセッションに、印刷に関するメッセージをルーティングすることができる。

たとえば、新しいセッション８０４を開始するとき、シェル（デスクトップなど）のためのリスナ登録８２４を作成して、（たとえば印刷に関する通知を示す通知タイプを特定することによって）シェルが印刷に関するセッションについてのどんなメッセージも受信したいことを示すことができる。

次いで、（たとえばユーザ要求によって）印刷が開始されると、印刷サービス８２０が起動され、セッション０で実行される。しかし、印刷サービスが別のセッション８０４のために起動され、その起動セッション８０４に関する識別子を、メモリ（スレッドローカル記憶域など）に格納することができる。

外部リソース８２８は、プリンタの紙切れを示すために、（たとえばプリンタドライバを含む）プリンタサービス８２０に、メッセージ（紙切れの通知など）を送るプリンタであり得る。プリンタサービス８２０は、送信者登録８２６を作成し、（たとえば印刷に関する通知を示す通知タイプを指定することによって）印刷関連の通知を送信することができる。その通知では、（たとえば格納されているセッション識別子を取り出すことによって）どのセッション８０４のために印刷が開始されたかを示すことができる。通知は、グラフィカルメッセージの表示（「プリンタ紙切れ」ＧＵＩなど）を含むことができ、このメッセージは、（たとえば印刷を開始した同じセッションの）適切なリスナに転送される。

次いで、セッションが、通知を処理して、セッション「０」コンソールではなく、共有リソース（印刷ジョブなど）を要求したセッション８０４に関連するユーザインターフェース８１０に、適切なユーザインターフェース（ダイアログボックスなど）を送信する。ユーザインターフェース表示が、正しいセッションのユーザインターフェースに表示される。

所望であれば、以下に述べる特徴によって、双方向通信を遂行することができる。このように、ユーザは、オプションを選択することができ、通知の発信元８２０に、そのオプションを返信することができる。

（実施例１６）
ユーザシナリオ切り替えのための例示的な複数セッション通知システム
図９に、ユーザシナリオを切り替える際に使用する例示的な通知システム９００を示す。例９００では、コンピュータ９０２が現在のセッション９０４を実行しており、他のセッション９０６，９０８のために状態を保存している。ユーザは、（たとえばポインタまたはキーボード操作を介して）切り替えコマンドを呼び出すことによって、別のアクティブセッション（ａｃｔｉｖｅｓｅｓｓｉｏｎ）９０６、９０８に切り替えることができる。実際には、それぞれのセッションは、異なるユーザ名に関連付けられるが、切り替えは、現在のユーザをログオフしないで行うことができる。

コンピュータが、共有リソース９１２、９１６を使用する新しいセッションを生成したとき、セッション９０４、９０６、９０８は、（たとえばそのセッションに関する）通知を受信するために、適切なプロパティ９２２を作成する。図示するように、共有リソース９１２、９１６は、セッション９０４、９０６、９０８で使用可能である。共有リソース９１２、９１６が、セッション９０４、９０６、９０８（それを呼び出したセッションなど）のいずれかに通知を送ろうとする場合、共有リソース９１２、９１６は、適切な送信者登録９１８、９２０を作成することができる。共有リソースがメッセージを生成すると、通知サーバ９１４は、共有リソース９１２、９１６によって登録されているプロパティが、セッションによって登録されているプロパティ９２２に一致するかどうか（たとえばセッション識別子が一致するかどうか）を判断する。もしそうであれば、通知の表示（たとえば通知自体）が、対応するセッション９０４、９０６、９０８に転送される。

たとえば、アクティブセッションは、共有データベースリソースへのアクセスを要求し、次いで非アクティブになり得る（たとえば、コンピュータ９０２のユーザが切り替わる）。次いでデータベースは、結果的には非アクティブセッションについてのユーザインターフェース通知メッセージになる通知を生成することがある。このような場合、通知サーバは、登録されているプロパティから、メッセージ（通知など）が、現在のアクティブセッションに届けるためのものではなく、現在は非アクティブになっているセッションに届けられるためのものであると判断し、そのようにする。次いでその対象のセッションがアクティブになり、アクティブなディスプレイ９１０に表示され、再アクティブ化されたセッションが、メッセージ表示を表示する。

（実施例１７）
例示的なフィルタ
図１０に、例示的な通知サーバ１０００を示す。この例では、クライアント（図示せず）が、リスナ登録１００２を生成して、共有リソースから通知を受信し、共有リソース（図示せず）が送信者登録１００４を作成して、登録されているリスナに通知を送信する。本明細書に示すいずれの例でも、共有リソースによって通知が生成されたときに、フィルタ１００６を使用して、通知が対応するリスナ登録のプロパティに一致するかどうかを判断することができる。フィルタが考慮するプロパティは、本明細書で述べるリスナプロパティまたは送信者プロパティのいずれをも含み得る。

様々なやり方で、一致を定義することができる。たとえば、プロパティのサブセットが同一であれば、２つの登録を、一致するものとして定義することができる。一致は、少なくとも識別コンテキストプロパティ（登録が同一のプロパティを有しているかどうかなど）に基づくものとすることができる。ある場合では、どんなプロパティも一致すると考えられ得る。たとえば、登録が、特定のユーザについてのどんなセッションの通知をも転送すると示すことがある。こうした場合、そのユーザについてのどのセッションの登録も、一致するものとみなされる。

あるシナリオでは、クライアントコンポーネントは、（リスナ登録で、「ＮＵＬＬ」通知タイプを指定することによって）すべての通知タイプに関与することを指定することができる。その場合、フィルタは、登録されているリスナに、すべてのタイプの通知を転送する。

さらに、プロパティによっては、登録および関連する通知の動作に影響を及ぼすことができる。たとえば、送信者登録プロパティ（通知タイプなど）では、リスナがどのように受信された通知を処理するかを示すことができ、またリスナがどのように通知の登録を行うかについて影響を及ぼすことができる。たとえば、登録時に、クライアントは、（たとえばどの通知タイプが使用可能か、または望まれるかについて、送信者登録とネゴシエーション（ｎｅｇｏｔｉａｔｉｏｎ）することによって）リスナ登録をセットアップする際に、こうした情報を使用することができる。通信タイププロパティでは、クライアントと共有リソースの間の通信が、双方向かそれとも単一方向かを示すことができる。通知タイププロパティでは、通知タイプ、共有リソースが返信を望んでいるかどうか、またその両方を示すことができる。通知タイププロパティは、通知を処理するために使用される論理の識別にも役立つ。

あるシナリオでは、クライアントは、リスナプロパティを、そのクライアントのセキュリティコンテキスト識別子の形で登録する。セキュリティコンテキスト識別子は、（たとえばリモートプロシージャコール（「ＲＰＣ」：ｒｅｍｏｔｅｐｒｏｃｅｄｕｒｅｃａｌｌ）サブシステムを介した）クライアントからの呼び出しを検査することによって決めることができる。共有リソースがクライアントからのサービス要求を受け付けたときに、共有リソースが、（たとえば偽装することによって）クライアントのセキュリティコンテキストで実行されていることがある。共有リソースが通知を生成すると、その通知は、共有リソースが実行されているセキュリティコンテキスト（セキュリティコンテキスト識別子など）に、（たとえば、メッセージに識別子を含める、または共有リソースが登録のための呼び出しを行うときに、識別子を決定することによって）関連付けられる。このシナリオでは、共有リソースのセキュリティコンテキストが、サービスを要求しているクライアントのセキュリティコンテキストと一致するので、通知の表示は、クライアントに転送される。

クライアントは、通知を使用して、通知を示す画面上のユーザインターフェースを生成することができる。こうした一例では、クライアントは、メッセージに含まれる通知タイプを使用して、（たとえばダイナミックリンクライブラリ（「ＤＬＬ」：ｄｙｎａｍｉｃｌｉｎｋｌｉｂｒａｒｙ）を指定することによって）正しいメッセージを表示するルーチンを識別する。通知を示す画面上のインターフェースは、ターミナルがローカルか、それともリモートかに関係なく、クライアントに関連するターミナル上に表示することができる。

偽装とは、スレッドを所有するプロセスのセキュリティコンテキストとは異なる、スレッドのセキュリティコンテキストで、スレッドを実行できることである。サーバが、クライアントのセキュリティコンテキストで実行されている場合、そのサーバは、クライアントのように見える。これによって、アクセスチェック（ａｃｃｅｓｓｃｈｅｃｋ）をクライアントの識別に対して実施することができる。アクセスチェックのためにクライアントの識別を用いることによって、クライアントの許可レベルに応じて、アクセスを制限または拡大することができる。

別のシナリオでは、クライアントが、ターミナルセッション識別子とともに、クライアントのセキュリティコンテキストの形のリスナプロパティを登録する。（たとえばＲＰＣサブシステムを用いた）クライアントからの呼び出しに基づいて、プロパティを取得することができる。こうしたシナリオでは、共有リソースがクライアントからのサービス要求を受け付けると、共有リソースは、クライアントのセキュリティコンテキストで実行される。しかし、割り当てられているセッションは、コンソールセッションであり得る。したがって、呼び出し側クライアントのセッション識別子を、以降の取出しに備えて格納することができる。

次いで、共有リソースが通知を生成するとき、その通知メッセージおよび／または共有ソースについての送信者登録は、共有リソースが実行されているセキュリティコンテキストおよび共有リソースを要求したターミナルセッション（たとえばどのターミナルセッションのために共有リソースが実行されているかなど）を含む。共有リソースのセキュリティコンテキスト、および共有リソースについて格納されているターミナルセッションが、登録されているリスナプロパティに一致するので、通知サーバフィルタによって、通知の表示がクライアントに転送されることになる。

（実施例１８）
例示的なユーザフィルタ
以下の例では、様々な印刷シナリオにおけるフィルタが示されているが、こうした技術は、共有リソースについての通知が有用である他のシナリオに適用することができる。図１１に、例示的な通知システム１１００を示す。このシナリオ１１００では、クライアントは、印刷スプーラサーバ（ｐｒｉｎｔｓｐｏｏｌｅｒｓｅｒｖｅｒ）１１０２の形態の通知サーバによってホストされている、印刷コンポーネント（印刷ドライバ、ポートモニタ（ｐｏｒｔｍｏｎｉｔｏｒ）、言語モニタなど）の形態の共有リソースから通知を受信するためのリスナ登録１１２２、１１２４を含む。

この例では、ユーザ識別子（「Ｊｏｅ」および「Ｍａｒｙ」として示すが、ユーザを識別する他の何らかの形であり得る）の形の識別コンテキスト識別子を含む、リスナ登録１１２２、１１２４がセットアップされている。ユーザＪｏｅは、２つのターミナルセッションを実行しており、この両方のセッションは、スプーラサーバ１１０２内で、コンポーネント１１１２、１１１４を（同時または異なる時などに）実行させるサービスを要求している。コンポーネント１１１２、１１１４は、Ｊｏｅを偽装し、また「０」以外のセッションに関連付けられるが、システムサービスによってホストされているので、コンソールセッション（すなわち「０」）で実行される。この例では、コンポーネント１１１２、１１１４が通知を送信したいときに、適切な登録を作成し、通知を送信することができる。その登録では、ユーザＪｏｅが指定されているので、コンポーネント１１１２、１１１４のいずれかまたは両方についての通知が、リスナ登録１１１２に関連するクライアントに渡される。

（実施例１９）
例示的なセキュリティコンテキストフィルタ
図１２に、例示的な通知システム１２００を示す。このシナリオ１２００では、クライアントは、印刷スプーラサーバ１２０２の形態の通知サーバによってホストされている、印刷コンポーネント（印刷ドライバ、ポートモニタ、言語モニタなど）の形態の共有リソースから通知を受信するためのリスナ登録１２２２、１２２４を含む。

この例では、特定のセキュリティコンテキストについての通知を受信することを指定する、セキュリティ識別子の形の識別コンテキスト識別子（「ＡＢＣ」および「ＤＥＦ」として示すが、セキュリティコンテキストを識別する他の何らかの形であり得る、ＳＩＤなど）を含む、リスナ登録１２２２、１２２４がセットアップされている。２つのターミナルセッションが、セキュリティコンテキストＡＢＣのもとで実行されているが、その両方のセッションが、スプーラサーバ１２０２内で、コンポーネント１２１２、１２１４を（同時または異なる時などに）実行させるサービスを要求している。コンポーネント１２１２、１２１４は、セキュリティコンテキストＡＢＣで実行されているが、システムサービスによってホストされているので、コンソールセッション（すなわち「０」）に関連付けられる。

この例では、コンポーネント１２１２、１２１４が、通知を送信したいときに、適切な登録を作成し、通知を送信することができる。その登録では、セキュリティコンテキストＡＢＣが指定されているので、コンポーネント１２１２、１２１４のいずれかまたは両方についての通知が、リスナ登録１２１２に関連するクライアントに渡される。

（実施例２０）
例示的なセッションフィルタ（ｓｅｓｓｉｏｎｆｉｌｔｅｒ）
図１３に、例示的な通知システム１３００を示す。このシナリオ１３００では、クライアントは、印刷スプーラサーバ１３０２の形態の通知サーバによってホストされている、印刷コンポーネント（印刷ドライバ、ポートモニタ、言語モニタなど）の形態の共有リソースから通知を受信するためのリスナ登録１３２２、１３２４を含む。

この例では、セッション識別子の形の識別コンテキスト識別子（たとえば、ターミナルサーバについて、「１」および「２」として示されているが、特定のセッションについての通知を受信することを指定する、セッションを識別する他の何らかの形であり得る）を含む、リスナ登録１３２２、１３２４がセットアップされている。２つのコンポーネント１３１２、１３１４は、スプーラ１３０２内で実行されており、またそれらはシステムサービスに関連するので、コンソールセッションのもとで、（同時または異なる時などに）実行されている。しかし、コンポーネント１３１２、１３１４は、それぞれ異なるセッションの代理で実行されており（たとえばそのユーザインターフェースが、スプーラ１３０２が実行されているマシンと同じまたは異なるマシン上に表示される）、また（たとえば本明細書の例に示すように）どのセッションのためにコンポーネントが実行されているかが格納されている。

この例では、コンポーネント１３１２、１３１４が通知を送信したいときに、適切な登録を作成し、通知を送信することができる。登録によって、通知に関連するセッションの一致について指定されているので、第１セッションの代理で実行されているコンポーネント１３１２についての通知は、第１セッションについての登録１３２２に関連するクライアントに転送され、第２セッションの代理で実行されているコンポーネント１３１４についての通知は、第２セッションについての登録１３２４に関連するクライアントに転送される。

（実施例２１）
混合プロパティフィルタ（ｍｉｘｅｄｐｒｏｐｅｒｔｙｆｉｌｔｅｒ）の登録
フィルタによって、本明細書で示す例示的なプロパティの２つ以上の任意の組合せを指定することもできる。図１４に、例示的な通知システム１４００を示す。このシナリオ１４００では、クライアントは、印刷スプーラサーバ１４０２の形態の通知サーバによってホストされている、印刷コンポーネント（印刷ドライバ、ポートモニタ、言語モニタなど）の形態の共有リソースから通知を受信するためのリスナ登録１４２２、１４２４を含む。

この例では、セッション１で、かつタイプ「印刷」の場合に、ユーザＪｏｅに関する通知を受信するために、リスナ登録１４２２がセットアップされている。リスナ登録１４２４は、タイプ「印刷」の場合に、ユーザＭａｒｙに関する通知を受信するためにセットアップされている。実際のプロパティ値（Ｊｏｅ、Ｍａｒｙ、１、印刷など）は、それと異なる形であり得る。２つのコンポーネント１４１２、１４１４は、スプーラ１４０２内で実行されており、またそれらはシステムサービスに関連するので、コンソールセッションのもとで、（同時に、異なる時などに）実行されている。しかし、コンポーネント１４１２、１４１４は、それぞれ異なるセッションの代理で実行されており、（たとえば本明細書の例に示すように）どのセッションのためにコンポーネントが実行されているかが格納されている。

この例では、コンポーネント１４１２、１４１４が通知を送信したいときに、適切な登録を作成し、通知を送信することができる。登録プロセスの一環として、通知自体の一部として、または他の何らかの機構を介して、コンポーネント１４１２、１４１４は、通知タイプを指定することができる。この例では、コンポーネント１４１２、１４１４の両方が、タイプ「印刷」の通知を送信する。

ユーザＪｏｅの代理および第１セッションの代理で実行されているコンポーネント１４１２についての通知は、通知に関して一致しているので、第１セッションについての登録１４２２に関連するクライアントに転送される。ユーザＭａｒｙの代理および第２セッションの代理で実行されているコンポーネント１４１４に関する通知は、通知に関して一致しているので、登録１４２４に関連するクライアントに転送される。「印刷」以外のタイプの通知が送信される場合は、一致していないので、登録１４２２、１４２４については通知が転送されない。

図示していない別のシナリオでは、クライアントコンポーネントが、複数のフィルタにリスナ登録を行い、共有リソースが複数のリソースに送信者登録を行う。こうしたシナリオの１つでは、フィルタ方法によって、通知を転送する前に、複数のプロパティが一致していることが必要とされる。たとえば、クライアントは、セッション識別子、セキュリティコンテキスト識別子、コンピュータ識別子、および通知タイプのフィルタプロパティが一致している通知だけが転送されるように、登録をセットアップすることができる。

（実施例２２）
管理者およびプロパティフィルタ
図１５に、図１４の例示的な通知システム１４００を示す。しかし、この例では、管理権限を有するユーザが、どんなセッションのどんなユーザ、またどんなタイプについても通知を受信するための登録１５２６を作成している。（たとえば特定のユーザ、特定のセッションなどの通知を受信するために）別の管理者登録を作成することができる。システム１４００では、管理者が、その特権に基づいてこうした登録を作成することができる。

システム１４００では、上記と同様に進行するが、登録１５２６に関連するクライアントへも通知を送信する。このようにして、管理者は、ユーザ、セキュリティコンテキスト、セッションに関係なく、登録を監視することができる。

さらに、管理者は、他のユーザ／セッションについての通知を受信するため、非管理者クライアントを登録することが許され得る。

このようにして、通知用に生成された関連するユーザインターフェースを、こうした通知を受信するために管理者が登録しているターミナルセッションに関連するローカルまたはリモートのマシンに向けて送ることができる。

（実施例２３）
チャネルおよび独立した寿命
「チャネル」と称される機構を使用して、通知の伝達に対処することができる。所望であれば、こうしたチャネルを双方向になるようにセットアップすることができ、それによって、クライアントと共有リソースの間で双方向通信を実現することができる。送信者登録の一部として、チャネルを実装することができる。またここで述べるチャネル機能は、したがって、送信者登録（送信者登録コンポーネントなど）上で実施することができる。

いずれかのリスナ登録があるかどうかにかかわらず、共有リソースコンポーネントは、チャネルコンポーネントを開くことができる。チャネルが開かれた後、共有リソースは、チャネルコンポーネントを介して通知を送信することができる。登録されているリスナがいない場合には、チャネルコンポーネントインターフェース呼び出し（ｃｈａｎｎｅｌｃｏｍｐｏｎｅｎｔｉｎｔｅｒｆａｃｅｃａｌｌ）は、それでも成功するが、呼び出しの結果（ＨＲＥＳＵＬＴなど）には、通知を受信したリスナがいなかったことが示される。

たとえば、スプーラによってロードされた印刷コンポーネントは、開かれたチャネルがあるかどうかにかかわらず、通知を送信するためにプリンタまたはサーバ（ローカルまたはリモート）に登録することができる。同様に、クライアントコンポーネントも、開かれたチャネルがあるかどうかにかかわらず、通知を受信するためにプリンタまたはサーバ（ローカルまたはリモート）に登録することができる。チャネルが開かれ、通知が送信されたら、リッスン側のクライアントは、通知、ならびに双方向通信のため、返信を戻すためのチャネルコンポーネントインターフェースを受信する。したがって、リスナコンポーネントと、チャネルコンポーネントの寿命は、それぞれ独立している。

フィルタ処理プロセスの一環として、チャネル機能を使用することができる（たとえば特定のタイプの通知を送信するために、チャネルをセットアップすることができる）。双方向シナリオでは、フィルタを使用して、送信者が受信に関与する返信のタイプを指定することができる。

（実施例２４）
共有リソースおよびリスナ用のインターフェース
図１６に、例示的な通知システム１６００を示す。この例では、共有リソース１６０４をホストする通知サーバ１６０２が示されている。同じマシン上にあるか、それとも異なるマシン上にあるかにかかわらず、登録されているリスナプロパティとチャネルプロパティの比較に基づいて、クライアントコンポーネント１６０６、１６０８と共有リソース１６０４を一致させる。

あるシナリオでは、クライアントコンポーネントは、クライアントから受信される要求を非同期に処理するサーバの共有リソースに、サービスを要求する。クライアントコンポーネント１６０６，１６０８は、サーバに要求を送信し、次いで、サーバがサービスを実施する間は待機せずに、クライアントコンポーネント１６０６が、後でサーバから送られてくる可能性がある通知のために登録をする。ある例では、クライアントコンポーネント１６０６は、リスナプロパティを含むリスナ登録１６１０、１６１２を登録する。クライアントコンポーネントは、サーバ上でローカルでも、ネットワークを介してでも実行することができる。こうしたシナリオの１つでは、通信１６１４は、ローカルであろうと、ネットワークを介して（ＲＰＣ、ＣＯＭ、ＤＣＯＭなど）であろうと、プロセス間通信をサポートするランタイム環境によって確立される。

クライアントコンポーネントは、共有リソースのプロセス空間または別のプロセス空間で実行することができる。クライアントコンポーネントは、共有リソースと同じマシンでも、異なるマシンでも実行することができる。このようなシナリオでは、スプーラは、それがホストしているコンポーネント（印刷プロセッサ、ドライバ、モニタなど）が、異なるセッションでローカルで実行されているアプリケーションに通知を送ることができるようにするインターフェースをサポートし、別のシナリオでは、コンポーネントが、ローカルとリモートの両方のクライアントに通知を送信することができる。このようなシナリオでは、通知は、プリントハンドル（ｐｒｉｎｔｈａｎｄｌｅ）に基づいており、すなわちスプーラによってホストされているコンポーネントが、プリントハンドルを開いたセッションに通知を送信するように要求することができる。スプーラは、印刷コンポーネントが通知を送信できるようにする１組のインターフェース、およびアプリケーション（セッション、クライアントコンポーネントなど）が通知を受信するために登録できるようにする１組のインターフェースを提供する。

このシナリオでは、共有リソース１６０４は、通知サーバ１６０２によってホストされる（たとえばその内部で実行される）。共有リソース１６０４は、通知を送信したいときに、チャネルコンポーネント１６１６を作成する。クライアントコンポーネントは、通知オブジェクトを受信したいときに、リスナ登録１６１０、１６１２を生成する。共有リソースは、開かれたチャネルコンポーネントの論理リスト１６１８、および共有リソースから通知を受信するため登録されたリスナ登録（時に、「リスナコンポーネント」と称される）の論理リスト１６２０を保持する。この場合、プロセス間通信１６１４を使用して、プロセス間で通知データを送信する。

リスナコンポーネント１６１２およびチャネルコンポーネント１６１６は、それらに関連する通知タイプ、通信タイプ、ユーザ識別、セッション識別子、およびマシン識別子（たとえば登録済みのリスナ／送信者プロパティなど）を追跡する。通知サーバ１６０２は、チャネルコンポーネントとリスナコンポーネント間でこうしたプロパティを一致させる論理を実装し、チャネルのプロパティと一致したリスナだけにデータを送信する。

このシナリオでは、リスナコンポーネントは、通知サーバが通知データを渡す（ｐａｓｓｉｎ）ために呼び出すＩＣａｌｌＢａｃｋインターフェース１６２２を提示する。チャネルコンポーネントは、共有リソース１６０４が通知データを送信するために呼び出すＩＮｏｔｉｆｙＣｈａｎｎｅｌインターフェース１６２６を提示する。双方向通信をサポートするために、チャネルコンポーネントは、通知サーバがリスナから戻された通知データを渡すために呼び出すＩＣａｌｌＢａｃｋインターフェース１６２４を提示する。

このシナリオでは、共有リソースとクライアントコンポーネント間で送信される通知データが、通知タイプで識別される。共有リソースとクライアントコンポーネント間の通信は、単一方向または双方向であり、これは通信タイプによって決まる。

このシナリオでは、通知サーバは、共有リソースおよびクライアントコンポーネントが実行されているセキュリティコンテキストを認識する。こうしたシナリオでは、通知サーバは、ターミナルセッション識別子、および通知の送信または通知受信の登録のために行われる呼び出しのユーザ偽装を認識する。このシナリオでは、こうした情報が、チャネルコンポーネントおよびリスナコンポーネントに格納される。

ある具体的なシナリオでは、通知サーバは、クライアントコンポーネントが通知受信のため登録および登録解除できるようにする１組のインターフェースを定義し実装する。通知サーバ内で、登録がコンポーネントに関連付けられるが、クライアントコンポーネントは、ネットワーク上のどこにでも存在し得る。共有リソースコンポーネントごとに複数の登録がサポートされる。こうしたシナリオでは、通知サーバは、共有リソースが通知データを送信できるようにする１組のインターフェースをサポートする。通知サーバは、クライアントコンポーネントが実装し、登録時に通知する１組のインターフェースをサポートする。こうしたインターフェースが通知サーバによって呼び出され、通知データが登録されているリスナを介してクライアントコンポーネントに渡される。双方向通信では、通知サーバは、リスナを介してクライアントコンポーネントに、どのチャネルコンポーネントを介して通知データが届いたかを通知する。こうしたシナリオでは、クライアントコンポーネントが、リスナを介して共有リソースに、返信通知を返送する。

こうしたシナリオの１つでは、共有リソースは、それが潜在的リスナと確立する必要がある通信のタイプ、送信されるデータの通知タイプ、およびサービスを要求するリスナの所望のセキュリティコンテキストを指定する。このシナリオでは、クライアントコンポーネントは、リスナコンポーネントを介して、通信タイプ、通知タイプ、共有リソースのセキュリティコンテキストを指定する。通知サーバは、条件を一致させ、こうした条件に合うリスナコンポーネントだけに通知を送信する。

（実施例２５）
通知オブジェクトを送信するためのインターフェース
図１７に、例示的な通知システム１７００を示す。このシナリオでは、共有リソース１７０４をホストする通知サーバ１７０２が示されている。このシナリオでは、リスナおよびチャネルコンポーネントに登録されているプロパティの比較に基づいて、クライアントプログラム１７０６と共有リソースを一致させる。

たとえば、チャネル１７０５が登録するときに、登録で使用可能なフィルタプロパティのタイプを「通知」する。クライアントが、リスナ１７１０、１７１２を後で登録する場合は、クライアントは、こうした通知済みのフィルタプロパティを、登録時に使用することができる。ある例では、クライアントは、チャネルがそのチャネルを介してフィルタプロパティ（通知タイプなど）を使用できると通知していることを判断する。チャネルに登録している共有リソース１７０４によって通知が送信される場合に、クライアントは、この「通知された」フィルタプロパティを使用して、そのタイプの通知のために登録する。

あるシナリオでは、通知オブジェクト１７１４が、共有リソース１７０４とクライアントプログラム１７０６の間を流れる。通知オブジェクトは、ＩＮｏｔｉｆｙＣｈａｎｎｅｌインターフェース１７０８を介してチャネルコンポーネント１７０５に渡される。通知サーバ１７０２は、チャネルコンポーネント１７０５のプロパティを、リスナコンポーネント１７１２のプロパティと一致させ、リスナコンポーネント１７１０に、通知オブジェクト１７１４を転送する。以下の図面のリスナコンポーネント１７１０、１７１２は、同じ論理登録を示す。プロセス間通信を介して、通知オブジェクト１７１４がリスナコンポーネントに１７１２に渡され、このリスナコンポーネントに、クライアントプログラム１７０６からアクセスすることができる。双方向通信の場合には、クライアント側では、チャネルコンポーネント１７１８の論理表現がリスナに提示される。

上記で述べたインターフェースを用いて、通知オブジェクト１７１４が、共有リソースからクライアントプログラム１７０６に送信される。あるシナリオでは、通知サーバは、それに提示された内容は何でも、バイナリオブジェクト（バイナリラージオブジェクト（ｂｉｎａｒｙｌａｒｇｅｏｂｊｅｃｔ）すなわちＢＬＯＢなど）を指すポインタの形で送信する。このシナリオでは、クライアントおよび共有リソースの開発者は、通知オブジェクトの内容が何であるか、およびデータ形式を前もって認めることができる。この形式は、グローバル一意識別子をもつクライアントおよび共有リソースによって識別可能である。このグローバル識別子は、通知タイプの登録をし、それを受信するために使用されるフィルタプロパティであり得る。このようにして、通知サーバは、内容または形式を知らないで（たとえば、検査または認識のための論理をもたないで）、データを送信することができるが、内容または形式は、クライアントおよび共有リソースの開発者によって事前に取り決められる。こうしたシナリオでは、通知サーバは、データ内容および形式にとらわれないものであると考えられる。

あるシナリオでは、スプーラは、リスナとチャネルの間で送信されるデータ型を認識しない。クライアントコンポーネントおよび共有リソースは、チャネルを介して送信されるデータのスキーマを定義する。実際には、マークアップ言語（ＸＭＬなど）を用いて、データスキーマ（ｄａｔａｓｃｈｅｍａ）が定義されるが、スプーラは、フィルタ処理のために通知タイプ（ＧＵＩＤなど）をおそらく使用する以外には、データの整合性を検証する必要はない。これによって、コンポーネント（共有リソースコンポーネント、リスナコンポーネント、チャネルコンポーネント、クライアントコンポーネントなど）のプログラマが、様々なデータ型および形式を自由に選択できるようになる。このシナリオでは、通知データは、ＢＬＯＢとして定義され、スプーラによるデータ内容の検証は行われない。通知データを処理するために、（たとえば通知タイプに関連する）適切な論理を呼び出すことができる。たとえば、通知タイプを、通知データを処理する関数を含むコードライブラリ（ｌｉｂｒａｒｙｏｆｃｏｄｅ）（ＤＬＬなど）に関連付けることができる。

（実施例２６）
通知の返信を送信するためのインターフェース
図１８に、通知のための双方向通信をサポートする、例示的な通知システム１８００を示す。図示するように、双方向通信では、クライアントプログラム１８０１が、提示された論理チャネルコンポーネント１８０６を介して、共有リソースに返信通知を送信する。こうしたシナリオでは、クライアントコンポーネントは、チャネルコンポーネント１８０６上のＩＮｏｔｉｆｙＣｈａｎｎｅｌインターフェースを呼び出す。チャネルコンポーネントは、論理リスナコンポーネント１８０８上のＩＣａｌｌＢａｃｋインターフェースを呼び出し、通知サーバ１８０２に返信通知が送り返されるようにし、この通知サーバ上で、リスナコンポーネント１８１０が、チャネルコンポーネント１８１２上のＩＣａｌｌＢａｃｋインターフェースを呼び出し、このインターフェースによって、返信通知１８１４が共有リソース１８１６に送り届けられる。このシナリオでは、クライアントプログラム１８０１は、共有リソース１８１６をホストする通知サーバ１８０２に、返信通知オブジェクト１８０４を送信する。

（実施例２７）
登録および通知をサポートするインターフェース
例示的な通知システムは、１組のインターフェースおよびタイプを含む。ここで論じるインターフェースは、様々なオブジェクトモデル（ワシントン州レッドモンドのマイクロソフトコーポレーションによってサポートされるコンポーネントオブジェクトモデル（「ＣＯＭ」：ＣｏｍｐｏｎｅｎｔＯｂｊｅｃｔＭｏｄｅｌ）に準拠したオブジェクトなど）をサポートする環境で実装することができる。ＣＯＭをサポートする環境では、ここで論じるインターフェースは、ＩＵｎｋｎｏｗｎを継承することができる。しかし、こうした技術は同様に、インターフェースをサポートしていることも、サポートしていないこともある、他のオブジェクトモデル（任意のＣ＋＋やＣ＋＋ライクなオブジェクトモデルなど）に適用することができる。

この例では、サービスは、サービス自体の一部（たとえば、Ｓｐｏｏｌｓｖ．ｅｘｅなどのスプーラ実行可能ファイル）として、あるいはクライアントコンポーネントの一部またはリンクされた実行可能ファイル（Ｗｉｎｓｐｏｏｌ．ｄｒｖなど）として、スプーラによって実装可能な機能を指す一般名称である。印刷コンポーネントは、印刷プロセッサ、ドライバ、モニタなど、スプーラ実行可能ファイルにロードされるコンポーネントを指す。リッスン側クライアントは、印刷通知を受信するためにリスナ登録されている、クライアントコンポーネントまたはスプーラ内部コンポーネントである。通知は、印刷コンポーネントとリッスン側クライアントの間の通知チャネルを介して送られるデータである。チャネルコンポーネントは、印刷コンポーネントが通知を送信したいときに、その印刷コンポーネントによって作成されるコンポーネントである。

以下の表１に示すように、共有リソースが通知サーバにチャネルコンポーネントの作成を要求したときに、例示的なセッションフィルタが、共有リソース（たとえば、印刷プロセッサ、ドライバ、モニタなどの印刷コンポーネント）によって使用される。したがって、セッションフィルタは、印刷コンポーネントとスプーラプロセス（ｓｐｏｏｌｅｒｐｒｏｃｅｓｓ）の間の例示的なインターフェースである。

このシナリオでは、表１を参照すると、セッションフィルタが、チャネルコンポーネントの作成を要求する、共有リソース（印刷コンポーネントなど）から通知サーバ（スプーラなど）へのインターフェース呼び出しの中で指定される場合、その作成要求内で、セッションフィルタに値が割り当てられる。共有リソースがセッションフィルタ値を「１」に設定する場合（すなわちＥＳｅｓｓｉｏｎＦｉｌｔｅｒ＝１）、通知の受信時、スプーラは、プリントハンドルを開いたクライアントコンポーネントと同じセッションおよび同じユーザアカウント（ｕｓｅｒａｃｃｏｕｎｔ）で実行されている（または同じユーザアカウントを偽装している）どのリスナにも、その通知を送信する。共有リソースがセッションフィルタ値を「２」に設定する場合（すなわちＥＳｅｓｓｉｏｎＦｉｌｔｅｒ＝２）、通知の受信時、スプーラは、プリントハンドルを開いたクライアントコンポーネントと同じユーザアカウントで実行されている（または同じユーザアカウントを偽装している）どのリスナにも、その通知を送信する。共有リソースがセッションフィルタ値を「０」に設定する場合（すなわちＥＳｅｓｓｉｏｎＦｉｌｔｅｒ＝０）、通知の受信時、スプーラは、印刷コンポーネントまたはサーバからの通知の受信に関与している（すなわちその登録をしている）どのリスナにも、その通知を送信する。

このシナリオでは、表１を参照すると、セッションフィルタが、リスナコンポーネントの生成を要求するクライアントからのインターフェース呼び出しの中で指定される場合、その生成要求内で、セッションフィルタに値が割り当てられる。クライアントコンポーネントがセッションフィルタ値を「１」に設定する場合（すなわちＥＳｅｓｓｉｏｎＦｉｌｔｅｒ＝１）、セッション「１」から通知が受信されると、スプーラは、セッション「１」の登録をしているクライアントコンポーネントに、その通知を送信する。クライアントコンポーネントが、セッションフィルタ値を「２」に設定する場合（すなわちＥＳｅｓｓｉｏｎＦｉｌｔｅｒ＝２）、共有リソースから通知が受信されると、スプーラは、登録を行ったクライアントコンポーネントと同じユーザアカウントで実行されている（または同じユーザアカウントを偽装している）どのリスナにも、その通知を送信する。クライアントコンポーネントが、セッションフィルタ値を「０」に設定する場合（すなわちＥＳｅｓｓｉｏｎＦｉｌｔｅｒ＝０）、通知が受信されると、リスナは、どのセッションまたはどのリスナコンポーネントにも送信された通知を受信する。

このシナリオでは、管理者は、特定の印刷コンポーネントについて、プリンタの管理権限（ＰＲＩＮＴＥＲ＿ＡＤＭＩＮ＿ＲＩＧＨＴＳなど）を有するユーザである。したがって、管理者は、どのコンポーネントにも通知を送信し、どのコンポーネントからも通知を受信することができる。しかし、たとえばｋＰｅｒＳｅｓｓｉｏｎＦｉｌｔｅｒ値に登録されているチャネルコンポーネント上のセッション「１」から通知が送信される場合には、通知タイプフィルタがやはり適用される。ｋＰｅｒＳｅｓｓｉｏｎＦｉｌｔｅｒによれば、通知は、そうでなければ、セッション「１」に送信される。しかし、セッション「２」で実行している管理者が要求している場合は、通知タイプが同じである限りは、リッスンしている管理者が存在するので、通知がセッション「２」に送信される。しかし、管理者が通知タイププロパティを「ＮＵＬＬ」に設定する場合、管理者は、通知タイプが一致しているか否かにかかわらず、通知を受信する。

このシナリオでは、表２に示すように、印刷コンポーネントは、通信タイプを指定することによって、リスナからの返信通知を望んでいるかどうかを指定する。さらに、通信タイプによって、通知が複数のクライアントから返送される場合に、スプーラがどのようにそのケースに対処するかを指定することができる。

このシナリオでは、２つの通信タイプ、すなわち双方向および単一方向がある。単一方向の場合、リッスン側のクライアントは、返信通知を返送しない。しかし、複数のクライアントコンポーネントが、１つのチャネルコンポーネントから通知を受信する登録をすることができるので、複数の返信が、そのチャネルコンポーネントを介して共有リソースに返送される場合があり得る。

このシナリオでは、複数のクライアントコンポーネントが、通知受信の登録をする場合は、応答する最初のクライアントコンポーネントから、返信を受信する。継続しているダイアログ（通知、返信、通知など）の場合には、スプーラは、他のチャネルを閉じ、その最初のクライアントとのダイアログを続ける。別のシナリオでは、複数のクライアントコンポーネントとのダイアログがサポートされる。たとえば、通知サーバまたはチャネルコンポーネントは、複数のダイアログ／リスナの同期をとるやり方を提供することができる。

たとえば、２人のユーザ、Ｊｏｅおよび管理者が、Ｊｏｅのユーザアカウントフィルタに基づいて、通知受信の登録をしており、通知がＪｏｅと管理者の両方から受信される場合は、最初に受信された返信通知が、印刷コンポーネントに転送される。

このシナリオでは、通知タイプ（ＧＵＩＤなど）をスプーラが使用して、リスナのためにフィルタをかける。さらに、印刷コンポーネントおよび／またはクライアントコンポーネントは、通知タイプを使用して、通知オブジェクトのデータスキーマを識別する。

このシナリオでは、クライアントコンポーネント（印刷コンポーネントなど）は、通知サーバ（スプーラなど）に登録する。クライアントが通知のために登録すると、サーバ側のリスナコンポーネントは、リスナプロパティなどのクライアントコンポーネントに関する情報を含む内部テーブルを維持する。表３に示すように、登録要求に応答して、不透明な登録ハンドルポインタ（ｒｅｇｉｓｔｒａｔｉｏｎｈａｎｄｌｅｐｏｉｎｔｅｒ）がクライアントコンポーネントに戻される。クライアントコンポーネントは、この登録ハンドルを用いて、通知の登録を解除する。

このシナリオでは、表４に示すように、通知データが、ＩＮｏｔｉｆｙＤａｔａＯｂｊｅｃｔインターフェースを公開するオブジェクトとして取り扱われる。クライアントコンポーネントおよび通知サーバの共有リソースコンポーネントは、データスキーマを定義し、その定義したスキーマで、データを送受信することができる。たとえば、スプーラのクライアントは、それ自体のデータスキーマを定義し、様々なタイプにＧＵＩＤを割り当て、所与の通知システムについてどれを実装するかを知らせることができ、またどんなデータ型をも送受信することができる。スキーマは、通知サーバには必ずしも知られていないが、移送のためサイズが必要となることがあり、通知タイプ（ＧＵＩＤなど）が、リスナまたは送信者のプロパティの一部となり得る。たとえば、スプーラは、ＢＹＴＥ^＊ポインタの通知データオブジェクト、データの長さおよび通知タイプを尋ねる。通知タイプはＧＵＩＤポインタである。

このシナリオでは、印刷コンポーネントは、ＩＮｏｔｉｆｙＤａｔａＯｂｊｅｃｔにデータをパックし、リッスン側のクライアントは、ＡｑｕｉｒｅＤａｔａデータを呼び出して、通知データ、通知データのサイズ、および通知タイプを指す生ポインタを取得する。リッスン側クライアントは、このデータを使用して完了すると、ＲｅｌｅａｓｅＤａｔａを呼び出す。好ましくは、リスナコンポーネント上でＲｅｌｅａｓｅ（）を呼び出す前に、ＩＮｏｔｉｆｙＤａｔａＯｂｊｅｃｔを実装するクライアントがＲｅｌｅａｓｅＤａｔａ（）を呼び出す。このシナリオでは、ＡｑｕｉｒｅＤａｔａ呼び出しによって、オブジェクトの参照カウントが増分され、ＲｅｌｅａｓｅＤａｔａによって、オブジェクトの参照カウントが減分される。

このシナリオでは、表５に示すように、オブジェクトによっては、ＩＣａｌｌｂａｃｋインターフェースを公開する。

ＩＣａｌｌＢａｃｋインターフェースを公開するオブジェクトが、印刷コンポーネントとリッスン側アプリケーションの両方によって提供される。通知の受信に関与するコンポーネントは、ＩＣａｌｌＢａｃｋインターフェースを公開する。したがって、リッスン側クライアントは、登録時に、ＩＣａｌｌｂａｃｋインターフェースを指すポインタを提供する。このポインタを使用して通知を送信する。さらに、共有リソースは、返信通知を受信するために、ＩＣａｌｌｂａｃｋインターフェースを指すポインタを公開する。

共有リソース（印刷コンポーネントなど）からクライアントプログラムに通知が送信されると、通知を送り届けるため、チャネルのクライアントプログラム側で、サービスが、ＯｎＥｖｅｎｔＮｏｔｉｆｙメソッドを呼び出す。一方の端で、チャネルが閉じられると、もう一方の端で、サービスがＣｈａｎｎｅｌＣｌｏｓｅｄメソッドを呼び出して、チャネルが閉じられたことを知らせる。チャネルを閉じた理由は、通知として送り届けられる。共有リソースまたは通知サーバがシャットダウンした場合は、サービスがＣｈａｎｎｅｌＣｌｏｓｅｄを呼び出して、Ｎｏｔｉｆｉｃａｔｉｏｎ＿Ｄｉｅｄタイプのメッセージを送り届ける。

このシナリオでは、表６に示すように、印刷コンポーネントがＣｒｅａｔｅＮｏｔｉｆｉｃａｔｉｏｎＣｈａｎｎｅｌを呼び出すと、通知チャネルの開始に応答して、ＩＡｓｙｎｃｈＮｏｔｉｆｉｃａｔｉｏｎインターフェースを公開するコンポーネントが、サービスによって、クライアントプログラム側と通知サーバ側の両方に提供される。

ＩＡｓｙｎｃｈＮｏｔｉｆｉｃａｔｉｏｎインターフェースは、チャネルを識別し、またそれを使用して、通知を送信しまたはチャネルを閉じることができる。送信者は、ＳｅｎｄＮｏｔｉｆｉｃａｔｉｏｎを呼び出して、通知を送信する。送信者の役割は、チャネルを開き通知を送信する印刷コンポーネントによっても、また返信通知を返送しようとするときにリッスン側クライアントによっても果たすことができる。チャネルを閉じるために、送信者とリスナのどちらともが、ＣｌｏｓｅＣｈａｎｎｅｌを呼び出すことができる。チャネルを閉じた理由、または単にＮＵＬＬポインタを保持する通知を渡すことができる。チャネル作成者が、通知タイプをチャネルに関連付ける場合は、ＧｅｔＣｈａｎｎｅｌＮｏｔｉｆｉｃａｔｉｏｎＴｙｐｅによって、ＮＵＬＬデータを含むＩＮｏｔｉｆｙＤａｔａＯｂｊｅｃｔとして、チャネル通知タイプが戻される。

このシナリオでは、通知チャネル作成のため、ＣｒｅａｔｅＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｈａｎｎｅｌが印刷コンポーネントによって呼び出される。チャネルは、プリンタ単位のハンドルでも、サーバ単位のハンドルでもよい。印刷コンポーネントは、スプーラによってロードされるチャネルを開くことができる。たとえば、スプーラにロードされると、ドライバ（Ｗｉｎｓｐｏｏｌ．ｄｒｖなど）は、この機能を公開し、それによって、印刷ドライバは、チャネルを開くことができる。さらに、このシナリオでは、スプーラライブラリ（ｓｐｏｏｌｅｒｌｉｂｒａｒｙ）（Ｓｐｏｏｌｓｓ．ｌｉｂなど）は、この機能を公開し、それによって、ポートモニタおよび他の印刷コンポーネントは、チャネルを開くことができる。したがって、スプーラライブラリへのリンクを含む、スプーラサーバによってホストされているコンポーネントは、ＣｒｅａｔｅＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｈａｎｎｅｌを呼び出すことができる。

このシナリオでは、表７に示すように、ＣｒｅａｔｅＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｈａｎｎｅｌ呼び出しは、特定の入力および出力を含む。

表７に示すように、チャネルは、プリントハンドルを開いたセッション（プリンタ名など）に関連付けられる。セッションフィルタは、通知を受信するセッション（ｅＳｅｓｓｉｏｎＦｉｌｔｅｒなど）を指定する。チャネル通知タイプは、サポートされる通知のタイプを指定する。通信フィルタは、チャネルが単一／双方向かを指定する。ＩＣａｌｌｂａｃｋインターフェースは、チャネルのもう一方の端から通知が返送されたときに、何を呼び出すかを指定する。呼び出し側が応答に関与していない場合は、これはＮＵＬＬであり得る。

このメソッドは、チャネルを識別し、また通知を送信し、チャネルを閉じるために使用されるＩＡｓｙｎｃＮｏｔｉｆｉｃａｔｉｏｎオブジェクトを戻す。たとえば、チャネルを閉じるために、ＩＡｓｙｎｃｈＮｏｔｉｆｉｃａｔｉｏｎインターフェースのＣｌｏｓｅＣｈａｎｎｅｌメソッドを呼び出すことができる。

このシナリオでは、表８に示すように、ＲｅｇｉｓｔｅｒＦｏｒＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎｓ呼び出しは、特定の入力および出力を含む。

ＲｅｇｉｓｔｅｒＦｏｒＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎｓメソッドは、通知受信の登録をするリッスン側のクライアントによって呼び出される。リッスン側クライアントは、スプーラ内でも、いずれかのアプリケーション内でも生存することができる。ドライバ（Ｗｉｎｓｐｏｏｌ．ｄｒｖなど）は、どこにロードされるかに関係なく、この機能を公開する。スプーラライブラリ（Ｓｐｏｏｌｓｓ．ｌｉｂなど）は、この機能を公開し、それによって、ポートモニタは、通知のための登録をすることができる。スプーラライブラリ（Ｓｐｏｏｌｓｓ．ｌｉｂなど）にリンクするスプーラによってホストされるコンポーネントは、ＲｅｇｉｓｔｅｒＦｏｒＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎｓを呼び出すことができる。図示するように、ローカル／リモートプリンタ名またはサーバ名（プリントハンドルなど）が指定される。通知タイプは、リスナに送信する通知のタイプを示す。セッションフィルタは、どのセッションの通知をリスナに送信するかを示す。通信フィルタは、リスナが双方向通信／単一方向通信のどちらに関心があるかを指定する。ＩＣａｌｌｂａｃｋインターフェースは、どこに通知を送信するかを指定する。このメソッドは、ＵｎＲｅｇｉｓｔｅｒＦｏｒＰｒｉｎｔＮｏｔｉｆｉｃａｔｉｏｎｓを呼び出して登録を解除するため、クライアントが使用する不透明な登録ハンドルを戻す。この登録は、登録呼び出しを行うスレッドのセッションＩＤに関連付けられる。このシナリオでは、スプーラは、チャネルのセッションフィルタ、ならびにクライアントの登録セッションおよびクライアントセッションのフィルタに基づいて、リッスン側クライアントをフィルタにかける。

（実施例２８）
例示的な登録および通知サーバ方法
図１９に、通知の送信および返信通知の受信を遂行するための、通知サーバ方法による例示的な方法１９００を示す。１９０２で、この方法は、複数のクライアントのいずれからの要求を待つ。待ちを回避するために、通知サーバまたは例示的な方法１９００を、要求が生じたときに、ランタイム環境によってインスタンス化することができる。実際に、待ちが肯定の動作（ａｆｆｉｒｍａｔｉｖｅａｃｔｉｏｎ）である必要はない（たとえば、サーバは待ち命令を実行する必要はない）。前述の要求は、オブジェクトモデル（ＣＯＭ、ＤＣＯＭ、ＪＡＶＡ（登録商標）、Ｃ＋＋など）に基づくメソッド呼び出しであり得る。

１９０４で、通知を受信するためのリスナプロパティ登録の要求が、クライアントコンポーネントから受信される。１９０６で、その要求についての（たとえば要求に含まれる、またはそれから判断される）リスナプロパティが、（たとえばリスナ登録を介して）要求を送信するクライアントコンポーネントに関連付けられる。あるシナリオでは、前記の関連付けは、受信されたプロパティを、要求のソースの識別子とともに保持するデータ構造体に含められる。次いで、方法は戻り１９０８、次の要求を待つ１９０２。リスナプロパティは、本明細書で述べる例示的なプロパティのうち少なくとも１つを示す。要求がリスナの登録要求でない場合は、この方法は１９１０に続く。

１９１０で、チャネルプロパティ登録の要求が、共有リソースから受信される。１９１２で、その要求についての（たとえば要求に含まれる、またはそれから判断される）送信者プロパティが、要求を送信する共有リソース（すなわち、送信者登録）に関連付けられる。あるシナリオでは、前記の関連付けは、受信されたプロパティおよび共有リソース識別子を保持するデータ構造体に含められる。次いで、方法は戻り１９０８、次の要求を待つ１９０２。送信者プロパティは、本明細書で述べる例示的なプロパティのうち少なくとも１つを示す。要求が送信者の登録要求でない場合は、この方法は１９１４に続く。

１９１４で、通知（通知オブジェクトなど）が共有リソースから受信される。要求が通知である場合は、１９１６で、この方法は、通知を送信する共有リソースによって登録されている送信者プロパティを、登録されているリスナプロパティと比較する。比較が肯定的であれば１９１６、通知は、その肯定比較をもたらしたリスナプロパティを有するクライアントコンポーネントに転送される１９１８。あるシナリオでは、クライアントコンポーネントは、印刷ドライバコンポーネントがクライアントコンポーネントのセキュリティコンテキストで実行されている間に生成する通知のために登録をする。別のシナリオでは、クライアントコンポーネントは、特定のターミナルセッションで実行されている印刷モニタコンポーネントによって生成される通知のために登録をする。別のシナリオでは、クライアントコンポーネントは、特定の通知タイプのすべてのスプーラ通知のために登録をする。比較が肯定的であれば１９１６、その通知は、対応する肯定的なリスナプロパティを有するクライアントコンポーネントに転送される１９１８。比較が肯定的でなければ１９１６、方法は戻り１９０８、次の要求を待つ１９０２。しかし、要求が通知要求でない場合には１９１４、要求は１９２０に続く。

１９２０で、要求が、クライアントコンポーネントからの、返信通知の送信を求める要求であれば、返信通知は、その返信が応答する元になった通知を送信した共有リソース１９２２に戻され、次いで、この方法は戻り１９０８、次の方法を待つ。要求が返信要求でない場合には、方法は１９２４に続く。

１９２４で、要求が、クライアントコンポーネントからの、そのクライアントコンポーネントとリスナプロパティの間の関連付けを閉じる要求である場合には、その関連付けを閉じ１９２６、方法は戻り１９０８、次の要求を待つ１９０２。

１９２８で、要求が、共有リソースからの、その共有リソースと送信者プロパティの間の関連付けを閉じる要求である場合には、その関連付けを閉じ１９２８、方法は戻り１９０８、次の要求を待つ１９０２。

本明細書で述べる他のどんな方法とも同様に、この方法１９００はおそらく、複数のプロセス空間にわたって分散され機能する。このような場合には、この方法の操作を、複数のプロセス空間で実施することができる。たとえば、通知は一般に、通知サーバの空間で受信され、返信通知は一般に、クライアントコンポーネントの空間で受信される。他の操作は、両方のアドレス空間で実行されるコードを含み得る。たとえば、リスナ登録要求は、クライアントコンポーネントのアドレス空間で受信することができ、また部分的には、プロセス間通信を受け持つ通知サーバ空間で完了される。

実際には、比較操作（１９０４、１９１０など）は、肯定的には実行されないことがあるが、適切な実行可能メソッド（適切なインターフェースのメンバ関数など）を呼び出すことによって、様々な関数にアクセスすることができる。

（実施例２９）
例示的なクライアント登録および通知方法
図２０に、通知サーバと連携して通知を処理するために、クライアントプログラムによって実施される例示的な方法２０００を示す。あるシナリオでは、クライアントプログラムは、ターミナルサーバで実行されているセッションである。別のシナリオでは、クライアントプログラムは、単一のコンピュータ環境において、ユーザがログオフしないで切り替えることができる、複数のユーザ状態のうち１つで実行されている。クライアントプログラムは一般に、共有リソースにサービスを要求し、また共有リソースから発信され、最初に通知サーバに送り届けられる通知を受信するために通知サーバに登録をする、複数のクライアントプログラムのうち１つである。

２００２で、クライアントプログラムは、（たとえばリスナ登録を介して）通知サーバにリスナとして登録する。登録のためのリスナプロパティは、要求の中に含めることも、それから判断することもできる。次いで、登録されているプロパティに一致する通知が、通知サーバから受信されるまで、クライアントは任意選択で、他のタスクの処理を続ける。たとえば、あるシナリオでは、クライアントプログラムは、リモートターミナルでログインしているユーザのための、アプリケーション（文書処理、スプレッドシート処理など）を実行するターミナルセッションである。そのセッションは、印刷サービスを要求した後に、リモートターミナルのユーザによって生成された追加の編集要求を、続けて処理することができる。したがって、ターミナルセッションは、印刷サービスを要求した後に、処理を続ける。

通知を受信すると、２００８で、クライアントプログラムは、その通知を処理（たとえば、その通知用のユーザインターフェース表示を生成）する。次いで、クライアントは、他の処理を続けることができる。あるシナリオでは、通知がリスナプロパティと一致すると判断したことに応答して、その通知が、通知サーバによって送信される。たとえば、あるシナリオでは、クライアントプログラムは、ターミナルセッションであり、通知は、印刷コンポーネントに関する状態の変化である。あるシナリオでは、クライアントは、ターミナルセッションであり、リモートターミナルステーション（ｒｅｍｏｔｅｔｅｒｍｉｎａｌｓｔａｔｉｏｎ）で通知を表示するための制御論理が生成され、リモートターミナルに送信される。別のシナリオでは、ユーザインターフェースは、リスナプロパティ、または通知オブジェクト自体に置かれた通知タイプ識別子（グローバル一意識別子など）を用いて、クライアントプログラムによって識別される。あるシナリオでは、クライアントが、ターミナルサービスサーバ（ｔｅｒｍｉｎａｌｓｅｒｖｉｃｅｓｓｅｒｖｅｒ）上で実行されるターミナルセッションである場合に、生成されたユーザインターフェースが、リモートターミナルに表示される。

２０１２で、クライアントは判断して、２０１４で、通知サーバに返信通知を送信する。この返信は、共有リソースに転送される。たとえば、印刷シナリオでは、こうした返信は、ジョブがキャンセルまたは再度ルーティングされることを示すことがある。次いでクライアントは、他の処理に戻ることができ、他の通知を受信することがある。

所望であれば、登録済みクライアントは、複数の通知を受信するための登録を維持することができる。返信を一部に対しては送り、他に対しては送らないことができる。

２０１６で、クライアントが追加の通知の受信にもはや関与しない（たとえば、クライアントが終了する）ため、登録されているリスナを閉じる。

図示した様々な関数は、適切な実行可能メソッド（適切なインターフェースのメンバ関数など）を呼び出すことによってアクセスすることができる。

（実施例３０）
例示的な共有リソース登録および通知方法
図２１に、通知を送信するために共有リソースによって実行される例示的な方法２１００を示す。あるシナリオでは、共有リソースは、印刷スプーラで実行される印刷コンポーネントである。別のシナリオでは、スプーラは、印刷コンポーネントの共有リソースをホストする通知サーバである。別のシナリオでは、共有リソースは、複数のユーザによって共有される１つのコンピュータ上で実行される印刷ドライバであり、ユーザは、毎回ログオン／オフを行わずに、ユーザ状態を切り替えることができる。通知は一般に、共有リソースにサービスを要求し、通知サーバからの通知のために登録をしている、複数のクライアントのうち１つにルーティングされる。

２１０２で、送信者プロパティが、通知サーバに登録される。送信者プロパティは、登録要求の中に含まれても、登録要求から判断されてもよく、本明細書で述べる例示的な送信者プロパティのうち少なくとも１つを示す。次いで、共有リソースは、他の処理を続けることができる。

２１０８で、何らかの時点で（プリンタ紙切れの表示の受信時など）、通知サーバに通知を送信する。次いで、共有リソースは、他の処理を続けることができる。

（もしあれば）返信を受信後、２１１２で、その返信を処理することができる。場合によっては、返信は望まれていないので、返信の処理を実施する必要はない。次いで共有リソースは、他の処理を続けることができる。

２１１４で、チャネルを閉じる（たとえば、登録を閉じる）。別の通知を処理する場合には、チャネルを閉じる必要はない。

（実施例３１）
プリンタシナリオへの技術の例示的な適用
本明細書で述べたいずれの技術も、印刷シナリオに適用することができる。こうしたシナリオでは、プリンタがその状態を示す通知をユーザに返す（ｐｒｏｖｉｄｅｂａｃｋ）のが、しばしば有用である。本明細書で述べた技術を用いて、こうした通知を実現することができる。たとえば、印刷コンポーネントは、通知を送信することができる。

こうした通知で、プリンタの状況（プリンタの状態、エラーメッセージなど）を示すことができる。たとえば、紙切れまたは手差し給紙メッセージを、通知を介して送信することができる。任意の数の印刷に関する他のメッセージを送ることができる。

双方向通信が実装されている場合は、ユーザは、措置を講じる必要があること（印刷ジョブのキャンセルまたは再スケジューリングなど）を示す通知を返送することができる。

（実施例３２）
例示的な印刷共有リソースシステム
図２２の例示的なシステム２２００は、２つのマシン、すなわち印刷サーバ２２１８および別のマシン２２２０を備え、それぞれがターミナルセッションのユーザインターフェースを表示している。印刷サーバ２２１８は、ターミナルセッションのソフトウェア２２０４用に実行されており、もう一方のコンピュータ２２２０上の登録されているクライアントアプリケーション２２１０に通知を送信する印刷リソース２２０２を含む。この例では、通知システムを印刷スプーラ２２０８が使用して、送信されたジョブが印刷されたときに、リッスン側のアプリケーションに通知を送信する。このシナリオでは、３つの印刷アプリケーション２２１０、２２１２、２２１４が、ドメインゲストユーザ（ｄｏｍａｉｎｇｕｅｓｔｕｓｅｒ）を偽装して実行されて、別のセッション２２１６が、印刷装置の状況通知を監視する。

ゲストユーザ（ｇｕｅｓｔｕｓｅｒ）として実行されるアプリケーション２２１０、２２１２、２２１４は、装置が印刷を完了したときに、通知を受信するために登録する。それぞれのアプリケーション２２１０、２２１２、２２１４は、それぞれ異なるセッションに関連付けられる。システムサービス（印刷リソース２２０２およびスプーラ２２０８など）は、コンソールセッションに関連付けられる。

この例では、アプリケーションが、同じユーザを偽装して実行されたとしても、通知は、文書を送信したアプリケーションにだけ送信される。この場合、セッションフィルタを使用して、ジョブを送信した登録済みセッション２２１０に通知を送付する。また「紙切れ」通知２２２２は、装置状況通知に関心がある登録済みアプリケーションにだけ送信される。

（実施例３３）
ターミナルサーバ環境での例示的な実装
独立系ハードウェアベンダおよび独立系ソフトウェアベンダによって提供されるコンポーネントは、本明細書で述べた技術を使用して、印刷または他の共有リソースサービスを要求するクライアントコンポーネントに関連付けられるターミナルサーバセッションに、ユーザインターフェースを表示することができる。このようにして、ユーザインターフェースを、コンソールセッションではなく、要求の発信元である場所（リモートセッションなど）に表示することができる。

たとえば、プリンタ製造元またはプリンタドライバ開発者は、印刷ドライバに、適切な通知を生成し、ユーザと双方向通信を行う機能を含めることができる。ターミナルサーバまたはユーザ簡易切り替え環境では、メッセージ用のユーザインターフェースを、適切なセッションにでも、望まれるように適切なユーザ用にでも表示することができる。

（実施例３４）
例示的な返信の使用
返信通知機構を、本明細書で述べたいずれかの例と組み合わせて使用して、ユーザアクション（ｕｓｅｒａｃｔｉｏｎ）を、共有リソースに伝達して返すことができる。たとえば、通知を受信すると、クライアントは、ディスプレイ上の通知のユーザインターフェース表示を送信することができる。ユーザインターフェース表示は、対話型ユーザインターフェース要素（プッシュボタンなど）を含むことができる。ユーザインターフェース要素がアクティブ化された後、共有リソースに、返信通知を返信することができる。

たとえば、印刷シナリオでは、ユーザは、印刷ジョブをキャンセルし、再試行し、または再ルーティングすることを示すことができる。印刷ジョブを再ルーティングする場合には、返信通知に宛先を含めることによって、異なる宛先を伝達することができる。

こうしたシナリオは、ターミナルサーバ環境でサポートすることができる。このような場合、リモートターミナルに配置されたリモートディスプレイに、ユーザインターフェース表示を表示することができる。

（実施例３５）
コンピューティング環境
図２３および以下の議論は、実装に適したコンピューティング環境についての簡潔で一般的な説明を提供するためのものである。コンピュータおよび／またはネットワーク装置上で実行されるコンピュータプログラムのコンピュータ実行可能命令の一般的な文脈で本発明について説明するが、本発明は、他のプログラムモジュールと組み合わせて実施することもできることが当業者には理解されよう。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造体などを含む。さらに、本発明は、マルチプロセッサシステム、マイクロプロセッサベースの（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ−ｂａｓｅｄ）電子機器、ミニコンピュータ、メインフレームコンピュータ、ネットワーク装置、無線装置などを含めた、他のコンピュータシステム構成で実施できることが当業者には理解されよう。ネットワーク化されたコンピューティング環境でも、スタンドアロンコンピュータ上でも、拡張を実施することができる。

図２３を参照すると、実装のための例示的なシステムが、処理装置２３２１、システムメモリ２３２２、およびシステムメモリを含めて様々なシステムコンポーネントを処理装置２３２１に接続するシステムバス２３２３を備えた、従来型のコンピュータ２３２０（パーソナルコンピュータ、ラップトップ、サーバ、メインフレーム、他の様々なコンピュータなど）を含んでいる。処理装置は、Ｉｎｔｅｌｘ８６Ｐｅｎｔｉｕｍ（登録商標）、ならびにＩｎｔｅｌおよびＣｙｒｉｘ、ＡＭＤ、Ｎｅｘｇｅｎを含めた他からの互換性のあるマイクロプロセッサ、ＤｉｇｉｔａｌからのＡｌｐｈａ、ＭＩＰＳＴｅｃｈｎｏｌｏｇｙ、ＮＥＣ、ＩＤＴ、Ｓｉｅｍｅｎｓおよび他からのＭＩＰＳ、ならびにＩＢＭおよびＭｏｔｏｒｏｌａからのＰｏｗｅｒＰＣを含めた、様々な市販プロセッサのうちいずれかでよい。デュアルマイクロプロセッサ（ｄｕａｌｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）および他のマルチプロセッサアーキテクチュアを、処理装置２３２１として使用することもできる。

システムバスは、メモリバスまたはメモリコントローラ、周辺バス、およびいくつか例を挙げると、ＰＣＩ、ＶＥＳＡ、ＡＧＰ、Ｍｉｃｒｏｃｈａｎｎｅｌ、ＩＳＡ、ＥＩＳＡなどの、様々な従来のバスアーキテクチュアのいずれかを使用するローカルバスを含めた、いくつかのタイプのバス構造のいずれかであり得る。システムメモリは、ＲＯＭ（ｒｅａｄｏｎｌｙｍｅｍｏｒｙ：読出し専用メモリ）２３２４、およびＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ：ランダムアクセスメモリ）２３２５を含む。スタートアップ時などに、コンピュータ２３２０内の要素間で情報を転送する助けをする基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ：基本入出力システム）が、ＲＯＭ２３２４に格納される。

コンピュータ２３２０はさらに、ハードディスクドライブ２３２７、たとえば取出し可能ディスクに対して読み書きするための磁気ディスクドライブ２３２８、およびたとえばＣＤ−ＲＯＭディスク２３３１を読み出し、または他の光メディアに対して読み書きするための光ディスクドライブ２３３０を含む。ハードディスクドライブ２３２７、磁気ディスクドライブ２３２８、光ディスクドライブ２３３０はそれぞれ、ハードディスクドライブインターフェース２３３２、磁気ディスクドライブインターフェース２３３３、光ドライブインターフェース２３３４によって、システムバス２３２３に接続される。ドライブおよびその関連するコンピュータ読取り可能媒体は、コンピュータ２３２０のために、データ、データ構造体、コンピュータ実行可能命令などの不揮発性ストーレッジを提供する。前記のコンピュータ読取り可能媒体の説明は、ハードディスク、取出し可能磁気ディスクおよびＣＤに言及しているが、コンピュータ読取り可能な他のタイプの媒体、たとえば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ（Ｂｅｒｎｏｕｌｌｉｃａｒｔｒｉｄｇｅ）などを、例示的なオペレーティング環境で使用することもできることを当業者には理解されたい。

実装２３５６に加えて、オペレーティングシステム２３３５、１つまたは複数のアプリケーションプログラム２３３６、他のプログラムモジュール２３３７およびプログラムデータ２３３８を含めたいくつかのプログラムモジュールを、ドライブおよびＲＡＭ２３２５に格納することができる。

ユーザは、キーボード２３４０およびマウス２３４２などのポインティング装置を介してコンピュータ２３２０に、コマンドおよび情報を入力することができる。こうしたおよび他の入力装置はしばしば、システムバスに接続されたシリアルポートインターフェース２３４６を介して処理装置２３２１に接続されるが、他のインターフェース、たとえばパラレルポート、ゲームポート、ＵＳＢ（ｕｎｉｖｅｒｓａｌｓｅｒｉａｌｂｕｓ：ユニバーサルシリアルバス）によって接続してもよい。モニタ２３４７、または他のタイプの表示装置もまた、ビデオアダプタ２３４８などのインターフェースを介してシステムバス２３２３に接続される。モニタに加えて、コンピュータは一般に、スピーカやプリンタなどの他の周辺出力装置（図示せず）を含む。

コンピュータ２３２０は、リモートコンピュータ２３４９などの１つまたは複数のリモートコンピュータとの論理接続を使用した、ネットワーク化された環境で動作する。リモートコンピュータ２３４９は、サーバ、ルータ、ピアデバイス（ｐｅｅｒｄｅｖｉｃｅ）または他の通常のネットワークノードでよく、またメモリ記憶装置２３５０だけを示したが、コンピュータ２３２０に関して述べた要素の多数またはすべてを一般に含む。図示した論理接続は、ＬＡＮ（ｌｏｃａｌａｒｅａｎｅｔｗｏｒｋ：ローカルエリアネットワーク）２３５１、ＷＡＮ（ｗｉｄｅａｒｅａｎｅｔｗｏｒｋ：広域エリアネットワーク）２３５２を含む。こうしたネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、インターネットでは一般的なものである。

ＬＡＮネットワーキング環境で使用される場合には、コンピュータ２３２０は、ネットワークインターフェースまたはアダプタ２３５３を介してローカルネットワーク２３５１に接続される。ＷＡＮネットワーキング環境で使用される場合には、コンピュータ２３２０は一般に、モデム２３５４、または（たとえばＬＡＮ２３５１およびゲートウェイまたはプロキシサーバ２３５５を介して）インターネットなどの広域エリアネットワーク２３５２上に通信を確立するための他の手段を含む。モデム２３５４は、内部にあっても、外部にあってもよく、シリアルポートインターフェース２３４６を介してシステムバス２３２３に接続される。ネットワーク化された環境では、コンピュータ２３２０に関して示したプログラムモジュール、またはその一部を、リモートメモリ記憶装置に格納することができる。図示したネットワーク接続は、例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用できることが理解されよう。

代替方法
図示した一実施形態を参照して、本発明の原理を示し説明したが、図示した実施形態は、こうした原理から逸脱せずに、その構成および詳細を修正できることが理解されよう。本明細書で示したプログラム、プロセスまたは方法は、他に示されていない限りは、特定のタイプのコンピュータ装置に関するまたは限定されるものではないことを理解されたい。様々なタイプの汎用または専用のコンピュータ装置は、本明細書で述べた教示による操作で使用することも、それを実施することもできる。ソフトウェアにおいて図示した実施形態の要素をハードウェアで実装することも、またその逆も同様に行うことができる。

一例からの技術を、他のいずれかの例に組み入れることができる。一部の例では、通知の「転送」について述べている。こうした例は、少なくとも通知の表示を送信すること、通知自体を転送（中継など）すること、またその何らかの組合せを含み得る。

本発明の原理を適用することができる多数の可能な実施形態を考慮して、詳述した実施形態は例示的なものにすぎないことを理解すべきであり、本発明の範囲を限定するものとしてみなすべきでない。そうではなく、本発明について、こうしたすべての実施形態は、特許請求の範囲およびその等価物の、範囲および精神の内に含まれ得ることを主張する。

ターミナルサーバシステムの例を示す図である。「ユーザ簡易切り替え」シナリオの例を示す図である。共有リソースについての通知のための例示的なシステムを示す図である。共有リソースからの通知のための登録を実現する例示的なシステムを示す図である。共有リソースからの通知のための登録を実現する別の例示的なシステムを示す図である。通知を処理するための方法のフローチャートである。送信者およびリスナを登録し、通知を処理するための方法のフローチャートである。クライアントが登録し、共有リソースから通知を受信するための方法のフローチャートである。通知を送信する送信者を登録するための方法のフローチャートである。共有リソースからの通知のためのクライアント登録の例示的なシステムを示す図である。共有リソースから通知を受信するクライアントの登録を含む、例示的なターミナルサーバシステムを示す図である。共有リソースから通知を受信するためのユーザ表示の登録を含む、例示的な複数ユーザ切り替えシステムを示す図である。通知にフィルタをかけるために潜在的に使用される、１つまたは複数の登録プロパティを示す、例示的な通知サーバを示す図である。ユーザ識別子に基づいて通知にフィルタをかける、例示的なシステムを示す図である。セキュリティコンテキストに基づいて通知にフィルタをかける、例示的なシステムを示す図である。セッション識別子に基づいて通知にフィルタをかける、例示的なシステムを示す図である。複数のプロパティに基づいて通知にフィルタをかける、例示的なシステムを示す図である。管理者によって作成される登録を含む例示的なシステムを示す図である。例示的なリスナおよびチャネルの登録のためのオブジェクトおよびインターフェースを示す図である。例示的なリスナおよびチャネルの登録のためのオブジェクトおよびインターフェース、ならびに渡される通知オブジェクトを示す図である。例示的なリスナおよびチャネルの登録のためのオブジェクトおよびインターフェース、ならびに渡される返信通知オブジェクトを示す図である。クライアントおよび共有リソースを登録し、登録されたプロパティに従って通知および返信を転送するための通知方法のフローチャートである。通知を受信し、返信を送信するクライアントを登録するためのクライアント方法のフローチャートである。通知を送信し、返信を処理するチャネルを登録するための共有リソース方法のフローチャートである。通知のために登録し、印刷リソースに共有リソースを要求するクライアントを含む、例示的なシステムを示す図である。前述の通知技術を実施する方法および装置を実装するために使用することができる分散コンピュータシステムを示すブロック図である。

符号の説明

１００システム
１０２ターミナルサーバソフトウェア
１０３コンソール
１０４ユーザインターフェース
１０６ユーザインターフェース
１０８ユーザインターフェース
１１０ネットワーク
１１４印刷サービス
２００システム
２０４ユーザインターフェース表示
２０６コンピュータ
２１２ユーザインターフェース表示
２１４ユーザインターフェース表示
２２２印刷サービス
３００システム
３０６共有リソース
３１６通知
３２６クライアント
３３２共有リソース
３３４通知サーバ
３３６送信者登録
３３７送信者プロパティ
３３８Ａリスナ登録
３３９Ａリスナプロパティ
３３８Ｂリスナ登録
３３９Ｂリスナプロパティ
３４０Ａクライアント
３４０Ｂクライアント
３５２クライアント
３５４クライアント
３５６サーバ
３５７共有リソース
３５８サーバ
３５９共有リソース
３６０要求
３６２要求
３６４通知サーバ
３６６リスナ登録
３６８送信者登録
３７０フィルタ
４００方法
４５０方法
５００方法
６００方法
７００通知システム
７０２クライアント
７０４クライアント
７０６サーバ
７０８サーバ
７１６リスナ登録
７１８リスナ登録
７２０通知サーバ
７２２送信者登録
７２４送信者登録
７２６登録
８００通知システム
８０２セッション
８０４セッション
８０６セッション
８０８ユーザインターフェース
８１０リモートターミナル／ユーザインターフェース
８１２リモートターミナル
８１４ターミナルサーバ
８１６ネットワーク
８１８アクセス
８２０共有リソース
８２２通知サーバ
８２４リスナ登録
８２６送信者登録
８２８外部リソース
８３０リスナ登録
９００通知システム
９０２コンピュータ
９０４現在のセッション
９０６セッション
９０８セッション
９１０アクティブディスプレイ
９１２共有リソース
９１４通知サーバ
９１６共有リソース
９１８送信者登録
９２０送信者登録
９２２プロパティ
１０００通知サーバ
１００２リスナ登録
１００４送信者登録
１００６フィルタ
１１００通知システム
１１０２印刷スプーラサーバ
１１１２コンポーネント
１１１４コンポーネント
１１２２リスナ登録
１１２４リスナ登録
１２０２印刷スプーラサーバ
１２１２コンポーネント
１２１４コンポーネント
１２２２リスナ登録
１２２４リスナ登録
１３００通知システム
１３０２印刷スプーラサーバ
１３１２コンポーネント
１３１４コンポーネント
１３２２リスナ登録
１３２４リスナ登録
１４００通知システム
１４０２印刷スプーラサーバ
１４１２コンポーネント
１４１４コンポーネント
１４２２リスナ登録
１４２４リスナ登録
１５２６登録
１６００通知システム
１６０２通知サーバ
１６０４共有リソース
１６０６クライアントコンポーネント
１６０８クライアントコンポーネント
１６１０リスナ登録
１６１２リスナ登録
１６１４通信
１６１６チャネルコンポーネント
１６１８論理リスト
１６２０論理リスト
１６２２ＩＣａｌｌＢａｃｋインターフェース
１６２４ＩＣａｌｌＢａｃｋインターフェース
１６２６ＩＮｏｔｉｆｙＣｈａｎｎｅｌインターフェース
１７００通知システム
１７０２通知サーバ
１７０４共有リソース
１７０５チャネルコンポーネント
１７０６クライアントプログラム
１７０８ＩＮｏｔｉｆｙＣｈａｎｎｅｌインターフェース
１７１０リスナコンポーネント
１７１２リスナコンポーネント
１７１４通知オブジェクト
１７１８チャネルコンポーネント
１８００通知システム
１８０１クライアントプログラム
１８０２通知サーバ
１８０４返信通知オブジェクト
１８０６チャネルコンポーネント
１８０８リスナコンポーネント
１８１０リスナコンポーネント
１８１２チャネルコンポーネント
１８１４返信通知
１８１６共有リソース
１９００方法
２０００方法
２１００方法
２２００システム
２２０２印刷リソース
２２０４ターミナルセッションソフトウェア
２２０８印刷スプーラ
２２１０印刷アプリケーション／クライアントアプリケーション／セッション
２２１２印刷アプリケーション
２２１４印刷アプリケーション
２２１６セッション
２２１８印刷サーバ
２２２０コンピュータ
２２２２紙切れ通知
２３２０コンピュータ
２３２１処理装置
２３２２システムメモリ
２３２３システムバス
２３２４ＲＯＭ
２３２５ＲＡＭ
２３２７ハードディスクドライブ
２３２８磁気ディスクドライブ
２３３０光ディスクドライブ
２３３１ＣＤ−ＲＯＭディスク
２３３２ハードディスクドライブインターフェース
２３３３磁気ディスクドライブインターフェース
２３３４光ドライブインターフェース
２３３５オペレーティングシステム
２３３６アプリケーションプログラム
２３３７プログラムモジュール
２３３８プログラムデータ
２３４０キーボード
２３４２マウス
２３４６シリアルポートインターフェース
２３４７モニタ
２３４８ビデオアダプタ
２３４９リモートコンピュータ
２３５０メモリ記憶装置
２３５１ＬＡＮ／ローカルネットワーク
２３５２ＷＡＮ
２３５３アダプタ
２３５４モデム
２３５５ゲートウェイ／プロキシサーバ
２３５６トランスレータ

Claims

共有リソースについての通知を受信することであって、前記通知は、１つまたは複数の送信者プロパティに関連付けられ、前記送信者プロパティは、識別コンテキストプロパティを含むこと、および
少なくとも前記送信者プロパティの前記関連する識別コンテキストプロパティと、クライアントの１つまたは複数の識別コンテキストプロパティの比較に基づいて、前記クライアントに、少なくとも前記通知の表示を送信することを含むことを特徴とする方法。
前記共有リソースは、ターミナルサーバ環境において複数のセッションによって共有され、
前記クライアントは、前記共有リソースを呼び出す責任を担い、
前記送信者プロパティの前記識別コンテキストプロパティは、前記共有リソースを呼び出す責任を担う前記クライアントのセッション識別子を示すことを特徴とする請求項１に記載の方法。
前記共有リソースは、ユーザ簡易切り替え環境において複数のユーザによって共有され、
送信者の前記識別コンテキストプロパティは、前記複数のユーザのうちどれが前記共有リソースにアクセスしているかを示すことを特徴とする請求項１に記載の方法。
前記識別コンテキストプロパティはユーザ識別子を含むことを特徴とする請求項１に記載の方法。
前記識別コンテキストプロパティはセキュリティコンテキスト識別子を含むことを特徴とする請求項１に記載の方法。
前記識別コンテキストプロパティはセッション識別子を含むことを特徴とする請求項５に記載の方法。
前記送信者プロパティはさらに、通信タイプ、通知タイプおよびマシン識別子のうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
前記識別コンテキストプロパティは、セッション識別子およびセキュリティコンテキスト識別子を含むことを特徴とする請求項１に記載の方法。
前記通知は、前記共有リソースの状態条件（ｓｔａｔｅｃｏｎｄｉｔｉｏｎ）を示すユーザインターフェース表示のためのデータを含むことを特徴とする請求項１に記載の方法。
前記ユーザインターフェース表示は、対話型ユーザインターフェース要素を含み、
前記対話型ユーザインターフェース要素はアクティブ化されたという表示を受信したときに、前記共有リソースに返信通知を送信することをさらに含むことを特徴とする請求項９に記載の方法。
前記状態条件はプリンタ状態に関連することを特徴とする請求項９に記載の方法。
前記状態条件は紙切れメッセージに関連することを特徴とする請求項９に記載の方法。
前記状態条件はエラー状態を含むことを特徴とする請求項９に記載の方法。
前記状態条件はプリンタの紙リソースの状態を含むことを特徴とする請求項９に記載の方法。
前記通知は、前記共有リソースについての印刷固有のデータを示すデータを含むことを特徴とする請求項１に記載の方法。
前記クライアントによって前記通知を受信したときに、前記通知のユーザインターフェース表示を生成することをさらに含むことを特徴とする請求項１に記載の方法。
前記クライアントによって前記通知を受信したときに、前記通知のユーザインターフェース表示を生成することであって、前記ユーザインターフェース表示は、対話型ユーザインターフェース要素を含むこと、および
前記ユーザが前記対話型ユーザインターフェース要素を選択したという表示を受信したときに、前記共有リソースに返信通知を送信することをさらに含むことを特徴とする請求項１に記載の方法。
前記共有リソースは、印刷関連のコンポーネントであることを特徴とする請求項１に記載の方法。
前記クライアントについて１つまたは複数のリスナプロパティを取得することであって、前記リスナプロパティは、識別コンテキストプロパティを含むこと、および
前記クライアントを前記リスナプロパティに関連付けることをさらに含むことを特徴とする請求項１に記載の方法。
前記クライアントについて前記識別コンテキストプロパティを、前記クライアントからのＲＰＣ呼び出しに含まれる情報から取得することを特徴とする請求項１９に記載の方法。
前記共有リソースについて前記１つまたは複数の送信者プロパティを取得すること、および
前記共有リソースを前記送信者プロパティに関連付けることをさらに含むことを特徴とする請求項１９に記載の方法。
前記返信の転送は、前記送信者プロパティと前記リスナプロパティの比較に少なくとも基づくことを特徴とする請求項２１に記載の方法。
前記クライアントから返信通知を受信すること、および
前記共有リソースに前記返信通知を転送することをさらに含むことを特徴とする請求項１９に記載の方法。
前記クライアントからの呼び出しに対するプロセス間呼び出しセットアップ時に取得された情報から、前記セッション識別子を判断することをさらに含むことを特徴とする請求項８に記載の方法。
前記共有リソースは、前記クライアントのセッションとは異なるセッションに関連付けられるが、前記送信者プロパティは、前記プロセス間呼び出しセットアップから判断された前記セッション識別子を示すことを特徴とする請求項２４に記載の方法。
前記リスナプロパティはさらに、通信タイプ、通知タイプ、セッション識別子およびマシン識別子のうち少なくとも１つを含むことを特徴とする請求項１９に記載の方法。
前記リスナプロパティはさらに、通信タイプ、通知タイプおよびマシン識別子のうち少なくとも１つを含むことを特徴とする請求項１９に記載の方法。
前記リスナプロパティは、前記送信者プロパティより前に受信されることを特徴とする請求項１９に記載の方法。
前記送信者プロパティは、前記リスナプロパティより前に受信されることを特徴とする請求項１９に記載の方法。
第２のクライアントから、前記識別コンテキストプロパティを含む第２のリスナプロパティを受信すること、
前記第２のクライアントを、前記第２のリスナプロパティに関連付けること、および
前記第２のリスナプロパティと前記送信者プロパティの比較に基づいて、前記第２のクライアントに前記通知を転送することをさらに含むことを特徴とする請求項１９に記載の方法。
前記通知を受信したときに、リモートターミナルに配置されたディスプレイに、前記通知のユーザインターフェース表示を送信することをさらに含むことを特徴とする請求項１９に記載の方法。
前記リスナプロパティは、管理権限を有するクライアントによって指定され、
前記リスナプロパティは、前記クライアントに関連するユーザ以外のユーザについての通知が受信されることを示すことを特徴とする請求項１９に記載の方法。
前記リスナプロパティは、管理権限を有するクライアントによって指定され、
前記リスナプロパティは、任意のユーザについての特定の通知タイプの通知が、クライアントコンポーネントに転送されることを示すことを特徴とする請求項１９に記載の方法。
前記共有リソースは、印刷ジョブを処理するプリンタと通信するサーバ印刷システムコンポーネントであり、
前記通知は、前記プリンタが紙切れであることを示し、
前記リスナプロパティは、前記印刷ジョブを要求する前記クライアントのセッション識別子およびセキュリティコンテキストを示すことを特徴とする請求項１９に記載の方法。
前記共有リソースは、印刷ジョブを処理するプリンタと通信するプラグインコンポーネントであり、
前記通知は、前記プリンタが紙切れであることを示し、
前記リスナプロパティは、前記印刷ジョブを要求する前記クライアントのセッション識別子およびセキュリティコンテキストを示すことを特徴とする請求項１９に記載の方法。
前記共有リソースは、印刷ジョブを処理するプリンタと通信するプリンタドライバであり、
前記通知は、前記プリンタは紙切れであることを示し、
前記リスナプロパティは、前記印刷ジョブを要求する前記クライアントのセッション識別子およびセキュリティコンテキストを示すことを特徴とする請求項１９に記載の方法。
前記リスナプロパティは、複数のクライアントから受信され、前記クライアントは、それぞれのリスナプロパティに関連付けられ、
前記比較によって、前記通知は前記複数のクライアントのサブセットに転送されることを特徴とする請求項１９に記載の方法。
前記共有リソースは、コンソールに関連するセッションのスプーラプロセスで実行される印刷コンポーネントであり、
前記スプーラプロセスは、前記送信者プロパティを取得し、それを前記印刷コンポーネントに関連付け、前記スプーラプロセスは、前記リスナプロパティを取得し、それを前記クライアントに関連付け、
前記印刷コンポーネントは、前記プリンタから、プリンタの状態変化を示すメッセージを受信し、
前記印刷コンポーネントは、前記メッセージに応答して前記通知を生成し、
前記スプーラは、前記比較を実施し、前記通知を転送することを特徴とする請求項３７に記載の方法。
前記複数のクライアントは、ターミナルサーバ上で実行するターミナルセッションに関連付けられ、
前記サブセットは、特定のセッションで実行される単一のクライアントであることを特徴とする請求項３７に記載の方法。
前記共有リソースは、データベースであり、前記複数のクライアントは、前記データベースにアクセスするスレッドであることを特徴とする請求項３７に記載の方法。
ターミナルサーバ環境において、通知を処理する方法であって、
ターミナルセッションで実行するクライアントから、前記ターミナルセッションに関する通知のための登録要求を受信すること、
コンソールセッションで実行する共有リソースから、それに代って前記共有リソースが実行しているセッションに通知を送信するために要求を受信すること、および
前記ターミナルセッションで実行する前記クライアントに、前記通知を転送することを含むことを特徴とする方法。
前記通知は、印刷状態を示すことを特徴とする請求項４１に記載の方法。
前記通知は通知データを含み、
前記クライアントで前記通知を受信したことに応答して、前記通知データに基づいて前記通知用のユーザインターフェース表示を生成することをさらに含むことを特徴とする請求項４１に記載の方法。
前記転送は、前記クライアントについて登録されたターミナルセッション識別子と、前記共有リソースについて登録されたターミナルセッション識別子の比較に基づくことを特徴とする請求項４１に記載の方法。
通知を処理するためのコンピュータベースのシステムサービスであって、
１つまたは複数の送信者登録を作成する手段であって、前記送信者登録は、少なくとも識別コンテキストプロパティを含む手段と、
１つまたは複数のリスナ登録を作成する手段であって、前記リスナ登録は、少なくとも識別コンテキストプロパティを含む手段と、および
前記送信者登録のうち１つについての通知を受信したことに応答し、また前記通知に関連する前記送信者登録のプロパティに一致するプロパティを有するリスナに、前記通知を転送するために動作可能である手段とを含むことを特徴とするシステムサービス。
前記リスナ登録作成の手段は、リスナ登録の作成時に、前記リスナ登録について、同じセッションに関する通知が送信されることの表示を受信するために動作可能であることを特徴とする請求項４５に記載のシステムサービス。
前記システムサービスは、前記リスナ登録を要求しているクライアントに関連するセッション識別子を、前記クライアント以外のソースから取得するために動作可能であることを特徴とする請求項４６に記載のシステムサービス。
前記リスナ登録作成の手段は、リスナ登録の作成時に、前記リスナ登録について、同じユーザに関する通知が送信されることの表示を受信するために動作可能であることを特徴とする請求項４５に記載のシステムサービス。
前記識別コンテキストプロパティは、セッション識別子を含むことを特徴とする請求項４５に記載のシステムサービス。
前記識別コンテキストプロパティは、ユーザ識別子を含むことを特徴とする請求項４５に記載のシステムサービス。
前記通知受信に応答する手段は、前記リスナ登録に関連する返信を取り扱うために動作可能であることを特徴とする請求項４９に記載のシステムサービス。
前記送信者登録のうち少なくとも１つは、前記送信者登録に関連する通知のデータ形式を示す通知タイプをさらに含むことを特徴とする請求項４９に記載のシステムサービス。
共有リソースについての通知を受信し、登録されたセッションに前記通知を転送するコンピュータ実施方法であって、
あるセッションからある共有リソースに、サービス要求を、前記セッションに対応するセキュリティコンテキスト識別子およびセッション識別子とともに送信すること、
前記セッションの偽装されたセキュリティコンテキストで前記共有リソースを実行すること、
前記セキュリティコンテキスト識別子および前記セッション識別子を含むリスナプロパティを、前記セッションによって、通知インターフェースで登録すること、および
前記セッションによって、前記通知インターフェースを介して、前記サービス要求の状態を示す通知を受信することを含むことを特徴とするコンピュータ実施方法。
方法を実施するための実施可能命令を含むコンピュータ読取り可能媒体であって、前記方法は、
登録インターフェースを介して送信者登録の要求を受信すること、
識別コンテキストプロパティを含む送信者プロパティを、送信者登録に関連付けること、
前記送信者登録を求める前記要求に応答して、前記送信者登録に関するインターフェースへの参照を提供すること、
登録インターフェースを介してリスナ登録要求を受信することであって、前記要求はコールバック関数を含むこと、
セキュリティコンテキストプロパティを含むリスナプロパティを、リスナ登録に関連付けること、
前記リスナ登録を求める前記要求に応答して、前記リスナ登録に関するインターフェースへの参照を提供すること、
前記送信者登録に関する前記インターフェースを介して通知オブジェクトを受信すること、および
前記リスナプロパティと前記送信者プロパティの間の一致を検出したときに、前記コールバック関数を用いて前記通知オブジェクトを転送することを含むことを特徴とするコンピュータ読取り可能媒体。
前記リスナ登録に関するインターフェースを介して返信通知オブジェクトを受信すること、および
前記送信者に前記返信通知オブジェクトを転送することをさらに含むことを特徴とする請求項５４に記載のコンピュータ読取り可能媒体。
ターミナルサーバ環境において、複数のセッションに、プリンタ関連の通知をルーティングする方法であって、
前記ターミナルサーバ環境において、新しいセッションが開始されたときに、前記セッションのセッション識別子を示す、前記セッションについてのリスナ登録を作成すること、
印刷コンポーネントが呼び出される開始セッションの印刷ジョブを開始すること、
前記印刷コンポーネントの呼び出しの責任を担うセッションのセッション識別子を判断すること、
プリンタ関連の通知を生成するときに、前記プリンタ関連の通知を生成する前記印刷コンポーネントについての送信者登録を作成することであって、前記印刷コンポーネントは、コンソールセッションに関連付けられるが、前記送信者登録は、前記印刷コンポーネントの呼び出しの責任を担う前記開始セッションを示すこと、
前記送信者登録を介して前記通知を送信すること、
前記リスナ登録の前記セッション識別子と、前記送信者登録の前記セッション識別子を比較すること、
前記リスナ登録の前記セッション識別子と、前記送信者登録の前記セッション識別子の間の一致を検出したときに、前記セッション識別子に関連するセッションに通知を転送することであって、前記セッションは前記開始セッションであること、および
前記転送された通知を受信したときに、前記開始セッションのプリンタ操作に関連するメッセージを示すユーザインターフェースを表示することを含むことを特徴とする方法。
チャネルを介した通知の送信に対処するアプリケーションプログラミングインターフェース（ａｐｐｌｉｃａｔｉｏｎｐｒｏｇｒａｍｍｉｎｇｉｎｔｅｒｆａｃｅ）を実施するためのコンピュータ読取り可能命令を含む、１つまたは複数のコンピュータ読取り可能媒体であって、前記アプリケーションプログラミングインターフェースは、
前記チャネルを介して通知を送信するためのメンバ関数であって、前記通知のための通知データを含むオブジェクトを指すポインタを受け付けるメンバ関数と、
通知チャネルを閉じるためのメンバ関数であって、前記通知チャネルを閉じる理由を示すデータを含むオブジェクトを指すポインタを受け付けるメンバ関数と、
前記チャネルがサポートする通知タイプに照会するためのメンバ関数であって、サポートされる通知タイプを示すオブジェクトがどこに格納されているかを示すポインタを受け付けるメンバ関数とを含むことを特徴とするコンピュータ読取り可能媒体。