JP2008542874A - リモート端末セッションにおけるアクセシビリティ・オプションを提供する技術 - Google Patents

Abstract

リモート端末セッションのシナリオにおいて、アクセシビリティ機能を使用可能にすることに関連する技術を説明する。１つの事例において、プロセスは、リモート端末セッション内の表示要素に関するアクセシビリティ機能から要求を検出する。このプロセスは、この要求に関連するクエリを、その表示要素を生成したコンピューティング・デバイス上にあるコンポーネントに送信する。このプロセスは、さらにこのクエリに対する応答を受信する。

Description

アクセシビリティ支援（Accessibility aids）は、標準的なユーザ・インターフェース構成の利用が困難な人に対してコンピュータ利用の容易化を図るものである。例えば、弱視の人は、これらの機能をより容易に見つけ出し、利用することができるように、サイズを増大させたユーザ・インターフェース機能および／または言葉による説明が付随することによって強化されたユーザ・インターフェース機能を希望するであろう。

Ｍｉｃｒｏｓｏｆｔ（商標）社が提供するターミナル・サービスなどのリモート端末セッション・サポート製品は、クライアント・コンピュータとサーバ・コンピュータとの間のリモート端末セッションを使用可能にする。このリモート端末セッション（ＲＴＳ）は、クライアント・コンピュータがネットワーク上でサーバ・コンピュータと接続し、クライアント・コンピュータを介してリモート・デスクトップを生成することを可能にする。従来のリモート・デスクトップのシナリオでは、オペレーティング・システムおよび／あるいは１つまたは複数のアプリケーションをサーバ・コンピュータ上で実行してユーザインターフェース（ＵＩ）を生成し、次いで、ビットマップ・イメージなどのＵＩ表現がネットワークを介してクライアントに送信される。このビットマップ・イメージ・データは、アクセシビリティの観点から効果が限られる。そこで、リモート端末サービス・セッションのシナリオに対するアクセシビリティ・オプションを提供するソリューションが望まれる。

リモート端末セッションのシナリオにおけるアクセシビリティ機能を使用可能にすることに関する技術が説明される。１つの事例において、あるプロセスは、リモート端末セッション内の表示要素に関するアクセシビリティ機能から要求を検出する。そのプロセスは前記要求に関連するクエリを、前記表示要素を生成したコンピューティング・デバイス上にあるコンポーネントに送信する。そのプロセスは、さらに前記クエリに対する応答を受信する。

（概要）
以下で説明する技術は、リモート端末セッションのシナリオと、リモート端末セッションにおけるアクセシビリティ支援（accessibility aids；ＡＡ）を使用可能にすることに関する。本明細書では、ＡＡは、ユーザに対して表示可能な表示要素またはオブジェクトに関わる情報へのアクセス機能に関連する。ＡＡは複数のユーザ・シナリオで利用する。例えば、ＡＡは、様々な音声指揮統制（speech command-and- control scenarios）のシナリオ、様々なテスト・シナリオ（testing scenarios）、ならびに視覚および／または聴覚障害を有するユーザを支援する様々なシナリオで利用する。

スタンドアローンのコンピュータ構成では、コンピュータは、アイコン、ツールバー等の１つまたは複数の表示要素を備えるユーザ・インターフェース（ＵＩ）を生成する。表示要素は、オブジェクト・データまたは情報と関連付けられたＵＩの任意の部分とすることができる。スタンドアローン構成で動作するＡＡは、ＵＩの特定表示要素に関する情報の一部または全てを取得することができる。このＡＡは、要求した表示要素情報の取得を容易にするアクセシビリティ支援ユーザ・インターフェースのインターフェース（ＡＡ−ＵＩ−インターフェース）などの、ＵＩと対話する手段を含み、またはその手段と通信する。次いで、表示要素に関連する情報は、何らかの方法で利用されてユーザを支援する。例えば、ユーザがカーソルをごみ箱用（recycle bin）のアイコンを表す表示要素上に置くと、ＡＡはその表示要素に関わる情報を要求する。ＡＡは、特定した表示要素に関わる情報を受信して理解する。受信した情報の種類の例にはとりわけ、ボタン、リスト、メニュー等の説明等、およびそれらの相対的関係が含まれる。次いでＡＡは、例えば視覚障害の場合などに、ほんの１例としてだが、ユーザに単語「ごみ箱」がユーザに聞こえるように生成させることで、ユーザを支援することができる。

リモート端末セッション（Remote terminal sessions；ＲＴＳ）は、サーバ上で動作するオペレーティング・システム（ＯＳ）および／またはアプリケーションが、１つまたは複数の表示要素を含むＵＩを生成することを可能にする。リモート端末セッションはさらに、ＵＩの出力またはグラフィックがクライアント・コンピュータに転送されることを可能にする。説明されている別の方法では、ＵＩ表現のみがクライアント・コンピュータに送信され、クライアント・コンピュータ上で表示される。このＵＩ表現はクライアント・コンピュータ上でユーザに対して目に見えるように表示され、クライアント・コンピュータ側のユーザは、このＵＩ表現を見て、このＵＩ表現と対話することができる。このクライアントがサーバから受信した表現を表示すること、およびユーザ入力を中継することのみを担当するという点で、クライアント・コンピュータは、サーバと比較して低減された担当レベルを有している。このサーバ・コンピュータは、ユーザ入力を処理して、ＵＩを更新してユーザ入力を反映し、更新したＵＩ表現をクライアント・コンピュータに送信する。ユーザの視覚的な観点からは、このＵＩ表現は実際のＵＩと見分けがつかないかもしれない。しかしながら、アクセシビリティの観点からは、このＵＩ表現は、実際の対応ＵＩと比較するとオブジェクト・データの低減されたレベルに関連付けられる。

本発明の技術はさらに、リモート端末セッション環境におけるＡＡが、上述のスタンドアローン構成と同様な機能を実現することを可能にする。例えば、このＡＡは、サーバのＵＩのクライアント表現のうち特定の部分に関わる情報を要求し、受信することができる。その要求は、検出され、情報が収集され、このＡＡに提供される。一部の実施態様では、このＡＡの要求を検出して、対応する情報を取得し、その情報をこのＡＡに対して透過的な形式で提示する。その結果、このＡＡは、自身がスタンドアローン構成以外で機能していることを意識する必要がない。

例として、図１を考える。この図１は、ネットワーク１０６上のサーバ１０２とクライアント１０４との間のリモート端末セッションをサポートするように構成され、そのリモート端末セッションに対してアクセシビリティ機能を使用可能にするように構成されたシステム１００を示す。サーバ１０２は。ＵＩをサーバ・デスクトップ１１０の形で生成する。このサーバ・デスクトップは、本図で示した表示要素１１１などの１つまたは複数の表示要素から構成されることができる。表示要素の例には、アイコン、ツールバー、メニュー等が含まれる。このリモート端末セッションは、ＵＩ表現をリモート・デスクトップ１１２の形でクライアント１０４上に生成する。このリモート・デスクトップは、１つまたは複数の表示要素を含むと言うよりも、単に、サーバＵＩの表示要素に関連する潜在情報の大部分、または全てを欠いた複数の表示要素からなる表現である。例えば、表示要素１１１は表現１１３が示すように表される。ユーザに対しては、表示要素の表現１１３は基本的に表示要素１１１と同一に見えるかも知れないが、アクセシビリティの観点からは、表示要素の表現１１３は、関連付けられた情報のうちの低減された量に関連付けられる。

クライアントのリモート・デスクトップ１１２と関連して機能するアクセシビリティ支援は、リモート・デスクトップの一部に関する情報を要求することができる。ＡＡの要求を満たすために、少なくとも幾つかの実施態様では、サーバＵＩの対応部分に関わるサーバ側の情報を収集する。例えば、クライアントＵＩ表現の要求部分に関わるオブジェクト・データは、サーバ側で実際のサーバＵＩから効率的に抽出され、このＡＡに送られる。例えば、このＡＡがリモート・デスクトップの表示要素に関わる情報を要求すると仮定する。この要求が検出され、このリモート・デスクトップの要求部分に関わる情報が取得され、ＡＡに提示される。例えば、前記情報はサーバ・デスクトップの対応部分に関して取得することができる。この情報は、ＡＡに提示されることができ、その結果、このリモート・デスクトップがクライアント１０４上でローカルに生成したＵＩであった場合に利用するであろう機能を超えたどのような機能もこのＡＡは所有する必要がない。

説明のために、別の例においてＡＡがカーソル１１４近傍のリモート・デスクトップ１１２の一部に関する情報を要求すると仮定する。このＡＡの要求は、検出され、カーソル１１４近傍のサーバ・デスクトップ１１０の一部に関する情報がサーバ１０２から取得される。その取得された情報、またはそれに関するある派生情報がこのＡＡに提供される。

提供した情報に応答して、このＡＡは、アクセシビリティ関連ユーザ知覚可能出力１１６がクライアント１０４側でユーザに対して生成されることを可能にすることができる。アクセシビリティ関連ユーザ知覚可能出力１１６は、リモート・デスクトップを補完するオーディオおよび／またはビデオ信号を含むことができ、これは当業界の技術者は理解するはずである。例えば、説明のために、インターネット・ブラウザ・アイコンの形で表示要素上にカーソル１１４が置かれると仮定する。当該事例などでは、アクセシビリティ関連ユーザ知覚可能出力１１６は、ユーザが聞き取れるように生成した単語「インターネットブラウザ」として明示することができる。

上述した実施態様などの、少なくとも幾つかの実施態様において、ＡＡは、ユーザ・インターフェースの表現のみがクライアント１０４上に存在すること、またはＡＡがリモート端末セッションに関連して動作していることを意識する必要はない。記載された別の方法では、一部の実施態様では、リモート・デスクトップに関する情報の重要なサブセットが、ＡＡに対してクライアント側でローカルに利用される。これら実施態様の一部においては、ＡＡに対して透過的な形式で情報を利用可能とする技術がサポートされる。例えば、ＡＡがサポートされた技術を利用して情報にアクセスするとき、この情報は透過的にローカルに利用される。この構成では、ＡＡは、リモート端末セッションの存在を意識せず、予定通りのアクセシビリティ機能パラメータ内で一貫して機能することができる。

上述および後述の実施態様は、一般的に時間内の現在時点で遭遇するように、コンピューティング環境のコンテキスト内で説明される。様々な例は、パーソナル・コンピュータまたはＰＣなどのコンピュータが実行するプログラム・モジュール等のコンピュータ実行可能命令、またはコード手段で実施することができる。一般に、プログラム・モジュールには、特定のタスクを実行または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。

様々な例は、ＰＣ以外のコンピュータ・システム構成で実施されることができる。例えば、様々な実施態様が、ハンドヘルド・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースまたはプログラム可能家電機器、ネットワークＰＣ、ミニコンピュータ、メイン・フレーム・コンピュータ、携帯電話、等で実現できる。さらに、技術が進歩し続けると、様々な実施を、まだ確認されていない部類の装置で実現することができる。例えば、処理能力の単位コストが下落し続けて、無線技術が拡大すると、今日の携帯電話に類似したコンピューティング・デバイスが、今日のＰＣ、ビデオカメラ、携帯電話、およびそれ以上の機能を単一の携帯装置で実行する可能性がある。この単一装置は、あるシナリオではサーバとして動作し、別のシナリオではクライアントとして動作する可能性がある。これは、説明した実施態様に対する多数の既存および発展過程の例の１つでしかない。

本明細書で用いるサーバおよびクライアントという用語は、２つの装置間の相対的な性能を意味しない。クライアントは、サーバを上回る処理能力、サーバを下回る処理能力、またはサーバと等しい処理能力を有することができる。むしろ本明細書では、サーバおよびクライアントという名前は２つのコンポーネントの相対的な関係を表す。例えば、第１すなわちサーバ・デバイスのコンピューティング・エクスペリエンスは第２すなわちクライアント・デバイスと切り離される。

様々な実施態様が上述で示唆したような多種類の動作環境に組み込むことができるが、ほんの１つの環境例が、一つの例示的な汎用コンピューティング・デバイスの例のコンテキストで、図４に示され、この汎用コンピューティング・デバイスは、本明細書の見出し「動作環境の例」以下でより詳細に後述される。

（実施態様およびプロセスの例）
アクセシビリティ機能がリモート端末セッションで達成されることを可能にするように構成されたシステム１００Ａを説明する図２を考察する。システム１００Ａは、ネットワーク１０６Ａ上でサーバ１０２Ａとクライアント１０４Ａとの間のリモート端末セッションをサポートするように構成されている。システム１００Ａは、さらに、アクセシビリティ機能が、クライアント１０４Ａに対してリモート端末セッション中に達成されることを可能にするように構成されている。本システムの実施態様において、サーバ１０２Ａは、ＲＴＳ−サーバ・コンポーネント２０２、ＡＡ−ＲＴＳ−サポート−サーバ・コンポーネント２０４、ＡＡ−ＵＩ−インターフェース−サーバ・コンポーネント２０６、およびサーバ・オペレーティング・システム（ＯＳ）２０８を含む。クライアント１０４Ａは、ＲＴＳ−クライアント・コンポーネント２１２、ＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４、ＡＡ−クライアント・コンポーネント２１６、およびクライアントＯＳ２１８を含む。

本構成では、サーバ１０２Ａは、説明の目的のために、サーバ・デスクトップ１１０Ａの形式で実装したＵＩを生成するよう構成される。サーバ・デスクトップは、ここでは説明の目的のために示されているが、多くのシナリオでは、サーバ・デスクトップの視覚的イメージは、実際には、サーバ上では生成されない。ＲＴＳ−サーバ・コンポーネント２０２およびＲＴＳ−クライアント・コンポーネント２１２は、リモート端末セッションに対してネットワーク１０６Ａ上でサーバ１０２Ａとクライアント１０４Ａとの間で１つまたは複数の通信チャネル２２０を確立するように構成される。ＲＴＳ−サーバ・コンポーネント２０２は、クライアント１０４Ａ上に表示させるサーバ・デスクトップ表現を生成するように構成される。この表現は、通信チャネル２２０上で送信され、本例ではリモート・デスクトップ１１２Ａとしてクライアント１０４Ａ上に表示される。本事例では、リモート・デスクトップ１１２Ａは、枠線またはウィンドウ内に置かれ、これらに取り囲まれる。枠線はリモート・デスクトップ１１２Ａを、クライアント・ディスプレイ２２４上にローカルに生成したクライアント・デスクトップ２２２から区別する役割を果たす。他の構成では、どのコンポーネントがローカルに生成されるか、およびどのコンポーネントがリモートに生成されるかを、ユーザが容易に理解できない可能性がある。

このリモート端末セッションは、ＲＴＳ−クライアント・コンポーネント２１２およびＲＴＳ−サーバ・コンポーネント２０２を介して、リモート端末セッションに関連するアクセシビリティ機能を使用可能にするようにさらに構成される。例えば、このリモート端末セッションは、クライアントおよび／またはサーバ側でアクセシビリティ・コンポーネントをホストすることができる。代りにまたは追加として、リモート端末セッションは、サーバ１０２Ａおよびクライアント１０４に置かれたＡＡコンポーネントがアクセシビリティの目的として望ましいＵＩ情報について通信するための通信手段を、提供することができる。

ＡＡ−クライアント・コンポーネント２１６は、ＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４を通してクライアント・ディスプレイ２２４を占有するＵＩから情報を要求したり、あるいはそのＵＩと対話するように構成される。ＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４は、ＵＩと相互交信してＡＡに対する情報を取得するように構成されたアプリケーション・プログラム・インターフェース（ＡＰＩ）などのインターフェースである。幾つかの構成では、ＡＡ−ＵＩ−インターフェースは、ＵＩ表示要素に関わる情報をクライアント・アプリケーションに提示するよう構成したアプリケーション・プログラム・インターフェース（ＡＰＩ）およびシステム・ライブラリである。この構成の１つにおいては、ＡＡ−ＵＩ−インターフェースは各ノードがＵＩ表示要素を表現する、複数のノードからなるツリーとしてＵＩ情報をとして提示する。少なくとも幾つかの構成においては、ＡＡ−ＵＩ−インターフェースは、ノードに関する構造、特性、双方向性、およびイベントへのアクセスを提供するように構成される。ＡＡ−ＵＩ−インターフェースとして見込まれる非制限的な例には、ＵＩ ＡｕｔｏｍａｔｉｏｎおよびＭｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ａｃｃｅｓｓｉｂｉｌｉｔｙ （ＭＳＡＡ）が含まれ、そのいずれもＭｉｃｒｏｓｏｆｔ（商標）社が提供する商標登録されている。当業界の技術者は他の適切なＡＡ−ＵＩ−インターフェースを認識するはずである。それらの幾つかは、上述または後述の概念に関わる他のものより優れている可能性がある。

本事例では、クライアント・ディスプレイ２２４は、ローカルに生成されたＵＩであるクライアント・デスクトップ部と、リモートに生成されたＵＩ表現であるリモート・デスクトップ部１１２Ａとを含む。本事例では、リモート・デスクトップ１１２Ａは、サーバのＵＩまたはサーバ・デスクトップ１１０Ａのビットマップ表現である。リモート・デスクトップ１１２Ａは、クライアント・デスクトップ２２２などのローカルに生成したＵＩと比べて、アクセシビリティの目的の情報のうちの低減された量の情報を収容する。

システム１００Ａに整合性を取って、ＡＡ−クライアント・コンポーネント２１６は、クライアント・ディスプレイ２２４の特定部分に関する情報を要求し、および受信することができる。この要求された情報がクライアント上でローカルに利用可能である場合、その情報はクライアント側で取得されて、ＡＡ−クライアント・コンポーネント２１６に提供される。この事例は、ＡＡの要求がクライアント・デスクトップ２２２に関わる場合に発生する可能性がある。リモート・デスクトップ１１２Ａの一部に向けた要求などの、この要求された情報がクライアント上で利用可能でない場合、その情報はリモートで取得される。例えば、この特別な構成においてＡＡ−クライアント２１６がリモート・デスクトップ１１２Ａに関する情報を要求する場合、その要求は、ＲＴＳ−クライアント２１２などのクライアント側コンポーネントによって検出されおよび理解されて、サーバ１０２Ａに方向付けされる。この特別な構成において、この要求はネットワーク１０６Ａを介してＡＡ−ＲＴＳ−サポート−サーバ・コンポーネント２０４に向けられる。この要求は、リモート端末セッションに関連付けられたチャネル２２０を介して送信されるか、または「帯域外」のチャネルに分離することができる。

ＡＡ−ＲＴＳ−サポート−サーバ・コンポーネント２０４は、ＡＡ−クライアント・コンポーネント２１６の代わりに動作し、サーバ・デスクトップ１１０Ａに関連する要求された情報を取得するように構成される。ＡＡ−ＲＴＳ−サポート−サーバ・コンポーネント２０４は、ＡＡ−ＵＩ−インターフェース−サーバ・コンポーネント２０６と協力し、サーバ１０２Ａで情報を取得するように動作する。ＡＡ−ＲＴＳ−サポート−サーバ・コンポーネント２０４は、クライアントに、最終的にはクライアントのＡＡ−クライアント・コンポーネント２１６に戻すように、情報を中継する。図２のシステム構成は、ＵＩ情報がクライアント１０４Ａ上に存在するかまたはサーバ１０２Ａ上に存在するかに関わらず、ＲＴＳセッションにおいてＡＡ−クライアント・コンポーネント２１６にＵＩ情報を取得することを可能とさせる構成の１つに過ぎない。

幾つかの構成において、ＡＡ−クライアント・コンポーネント２１６は、要求がローカルに生成したＵＩに関わるか、あるいはリモートまたはサーバで生成したＵＩの単なる表現に関わるかを意識する必要がない。この構成では、要求がクライアントＵＩに関わるかまたはリモートＵＩの表現に関わるかを決定する手段は、ＲＴＳ−クライアント・コンポーネント２１２内などのクライアント１０４Ａ上に存在してもよい。次いで、ＲＴＳ−クライアント・コンポーネントは情報を必要に応じてローカルまたはリモートに取得する。

図３は、上述および後述の概念と首尾一貫する、非制限的な実施態様を示す。図３は、クライアント１０４Ｂおよびサーバ１０２Ｂを含むシステム１００Ｂを表す。システム１００Ｂの内部において、ＵＩが、アクセシビリティ機能が動作中のマシンまたはリモートマシンのどちらで生成されるかどうかの、ＵＩに関する要求された情報を、クライアント１０４Ｂ上で動作するアクセシビリティ機能に提供できる。この特定のシステム構成は、１つの例を提供するものであり、その例は、ＲＴＳコンポーネントが、リモート端末セッションに関連して、ＵＩに関するアクセシビリティ関連情報を取得可能な、ＡＡが提供されたコンポーネントをホストするインフラストラクチャを、クライアント側およびサーバ側の両方に与えるかの一つの例を提供する。

本実施形態では、ＲＴＳコンポーネントは、ＡＡコンポーネントに、クライアント側からの所望のＵＩ情報を求める要求をサーバ側に渡す手段を提供することができ、取得した情報をサーバ側からクライアント側に戻す手段を提供することができる。説明のために、図３は、クライアント１０４Ｂ上で発生するプロセスを２つのプロセス・タイプ、すなわちＡＡプロセス・タイプ３０２およびＲＴＳプロセス・タイプ３０４に分割している。また、サーバ１０２Ｂ上で発生するプロセスをサーバ・プロセスタイプ３０６として示す。説明の簡潔さ、および印刷ページ数の制限のため、複数のサーバ・プロセスは、単一プロセスにグループ化される。他の構成では、サーバＵＩ３２６を、他のサーバ側コンポーネントおよび／またはプロセスと異なる分離したサーバ・プロセスに含めることができる。さらに、サーバＵＩの複数の事例が、サーバ・プロセス３０６上に列挙した他のコンポーネントと関連して存在できる。

システム１００Ｂには、ＡＡプロセス３０２に関連付けられ、ＡＡ−クライアント・コンポーネント２１６Ｂ、およびＡＡ−ＵＩ−インターフェース・コンポーネント２１４Ｂが含まれる。また、ＡＡプロセス３０２にさらに含まれるものとして、本事例ではＡＡ−ＵＩ−インターフェース・コンポーネント２１４ＢのサブコンポーネントであるＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８がある。ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８は、ＡＡ−ＵＩ機能をローカルまたはスタンドアローンのシナリオを超えて拡張するように動作する。

この特別な実施形態において、またＲＴＳクライアント・プロセス３０４と関連して、システム１００Ｂには、サーバＵＩおよびクライアント生成ＵＩ３１２のビットマップ表現３１０が表示されるクライアント・ディスプレイ２２４Ｂが含まれる。ＲＴＳクライアント・プロセス３０４には、ＲＴＳ−クライアント・コンポーネント２１２Ｂ、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４、ＲＴＳ−アクセシビリティ・サポート・コンポーネント３１６、およびＶＣ−ホスト−クライアント・コンポーネント３１８も含まれる。ＲＴＳ−アクセシビリティ・サポート・コンポーネント３１６はＲＴＳクライアント・コンポーネントとＡＡクライアント・コンポーネント間の通信を容易にするアクセシビリティ支援に関する情報を含んでいる。

サーバ・プロセス３０６に関連して、図３には、ＲＴＳ−サーバ・コンポーネント２０２Ｂ、ＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０、ＶＣ−ホスト−サーバ・コンポーネント３２２、ＡＡ−ＵＩ−インターフェース−サーバ・コンポーネント２０６Ｂ、およびサーバＵＩ３２６が含まれる。集合的には、ＲＴＳ−クライアント・コンポーネント２１２Ｂ、ＲＴＳ−アクセシビリティ・サポート・コンポーネント３１６、ＶＣ−ホスト−クライアント・コンポーネント３１８、ＲＴＳ−サーバ・コンポーネント２０２Ｂ、およびＶＣ−ホスト−サーバ・コンポーネント３２２は、ビットマップ表現３１０上に表した表示要素に関するデータをＡＡ−クライアント・コンポーネント２１６Ｂが取得可能とする役割を果たす。このビットマップ表現は、サーバＵＩ３２６の表現であるため、より広範囲のアクセシビリティ関連情報は、サーバＵＩから入手可能である。上述のコンポーネントは、アクセシビリティ関連情報が、サーバ１０２Ｂから取得されることを可能にし、さらに取得された情報は、ＡＡ−クライアント・コンポーネント２１６Ｂによる使用のために送り返すことができる。上述のコンポーネントは、以下で例を用いてより詳細に説明される。

（探索（Discovery））
この特別な構成において、ＲＴＳ−クライアント・コンポーネント２１２Ｂの起動時に、ＲＴＳ−クライアント・コンポーネントは、ＲＴＳ−アクセシビリティ・サポート・コンポーネント３１６およびＶＣ−ホスト−クライアント・コンポーネント３１８をロードし、ＶＣ−ホスト−サーバ・コンポーネント３２２がロードされることを引き起こす。さらに、ＲＴＳ−クライアント・コンポーネントは、例えばＡＡ−クライアント・コンポーネント２１６Ｂからの、通信を受信するためのウィンドウ・インターフェースを公開する。そのインターフェースは、ＡＡ−ＵＩ−インターフェース・コンポーネント２１４Ｂは、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４をＲＴＳ−クライアント・プロセス３０４にロードすることを可能にする。このインターフェースが公開されると、ＡＡ−ＵＩ−インターフェース・コンポーネント２１４Ｂは、ＲＴＳ−クライアント・コンポーネント２１２Ｂに遭遇すること、または見つけ出すことができる。例えば、１つの事例において、ＡＡ−ＵＩ−インターフェース・コンポーネント２１４Ｂは、関連するＨＷＮＤツリーのトラバース中にＲＴＳ−クライアント・ハンドルまたはＨＷＮＤに遭遇する。ＨＷＮＤはウィンドウを表現するハンドルである。Ｗｉｎｄｏｗｓ（商標）ブランドのオペレーティング・システムにおいて、ＵＩ要素の大部分はウィンドウとして実装される。各ウィンドウはハンドルまたはＨＷＮＤと関連付けられる。一般に、ＡＡクライアントには、様々なウィンドウおよびそれらの関係を表すためのこのＨＷＮＤのツリーが提供される。ＡＡクライアントはウィンドウ・ハンドルを使用して、ＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４Ｂからより多くの情報を求めるウィンドウを識別する。例えば、ＡＡクライアントはツリーをナビゲートすること、またはＲＴＳ−クライアントに対する入力フォーカスを注意すること、ＲＴＳ−クライアントに対するヒット・テストを行うことができる。ＲＴＳ−クライアントの検出に応じて、ＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４ＢまたはＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８は、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４をＲＴＳ−クライアント・プロセス３０４にロードする。これはほんの１例に過ぎず、特定のプラットフォーム上でＵＩを表現するために、どのようなデータタイプでも利用されることを認識するために他の実施形態を利用できる。

ＨＷＮＤがＲＴＳ−クライアント・プロセスに属する事例では、ＡＡ−クライアント２１６Ｂは、その代理的なＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８を通して、ＲＴＳ−クライアント２１２Ｂが提供するウィンドウ・インターフェースを用いて通信をＲＴＳ−クライアント２１２Ｂに送信することができる。この事例の１つにおいて、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８は、その公開されたインターフェースを通して、ＷＭ＿ＧＥＴＯＢＪＥＣＴなどのプロセス・メッセージをＲＴＳ−クライアント２１２Ｂに送信する。

ＲＴＳ−クライアント２１２Ｂは、ＡＡクライアントのプロセス・メッセージを、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４とアクセシビリティ・サポート・コンポーネント３１６とに転送する。それに応じて、アクセシビリティ・サポート・コンポーネントはＲＴＳ−クライアント・プロセスを公開し、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８はＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０をサーバ側にロードすることができ、関連仮想チャネルにアクセスことができる。アクセシビリティ・サポート・コンポーネントはさらに、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４が、要求の適切な処理のためにＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４により利用されるＲＴＳ−クライアント・デスクトップの様々な端末サービス・プロパティへのアクセス権を得ることができるようにする。このプロパティはとりわけ、可視で、不可視でおよび使用可能なスクロール・バーに関連付けできる。例えば、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４は後述の位置プロパティなどの様々なプロパティの後処理を担当する。この後処理を可能とするため、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４は、サーバ・デスクトップをＲＴＳ−クライアント２１２Ｂに表示するウィンドウ座標情報を利用する。例えば、ＲＴＳ−クライアント・ウィンドウがスクロール・バーを使用している場合、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４は正確にマップするためにスクロール・バーの位置を利用する。別の例では、幾つかのリモート端末セッションシナリオにおいて、ＲＴＳ−クライアント２１２Ｂによって表示されるクライアント・デスクトップはサーバ上の単一ウィンドウの表現であり、全体のデスクトップそれ自体ではない。ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４はこのＲＴＳ構成に関する情報、およびクライアント・デスクトップが対応するサーバデスクトップウィンドウに関する情報を利用する。ＲＴＳアクセシビリティ・サポート・コンポーネント３１６はこの情報をＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４に提供する。

ＡＡクライアント・プロセス・メッセージに応答して、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４はプロセス・メッセージの正当性（legitimacy）をチェックし、通信手段を開いてＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８を呼び出す。例えばＡＡ−ＵＩ−ＲＴＳ−インプロセスは、ＷＭ＿ＧＥＴＯＢＪＥＣＴメッセージが、それがＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４Ｂまたは他のアクセシビリティ・コンポーネントからであることを示すパラメータを含むことをチェックできる。ＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４は、指名されたパイプ（named pipe）を生成することによってＷＭ＿ＧＥＴＯＢＪＥＣＴを処理する。次いでＡＡ−ＵＩ−ＲＴＳ−インプロセスは、パイプに対する幾つかのキーを、呼び出し側、即ちＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８に返す。これはＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８がＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４と通信チャネルを確立する方法のほんの１例に過ぎない。当業界の技術者は他の構成を理解するはずである。

本例において、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８はＷＭ＿ＧＥＴＯＢＪＥＣＴメッセージから返されたパイプ・キーを受信し、そのパイプに接続してＡＡクライアント・プロセス３０２とＲＴＳ−クライアント・プロセス３０４との間の通信を確立する。

上述のＲＴＳ−クライアント２１２Ｂのコマンドに応答して、ＶＣ−ホスト−クライアント・コンポーネント３１８はＶＣ−ホスト−サーバ・コンポーネント３２２を開始するコマンドを送信する。ＶＣ−ホスト−サーバ・コンポーネントはＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０にＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４とのリンクを確立させる。上述のように通信手段はＡＡクライアント・プロセスからＲＴＳ−クライアント・プロセスへ拡張済みであり、次に、この通信手段はサーバ１０２Ｂ上のプロセスに効率的に拡張される。本例では、接続はＡＡ−ＵＩ−ＲＴＳローカル３０８からＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４に拡張し、次いでＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０に拡張する。

（情報の要求）
ＡＡクライアント２０４Ｂからのアクセシビリティ関連情報に対する要求は、クライアント側のＡＡ−ＵＩ−インターフェース−クライアント２１４ＢからＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８に伝達される。１事例において、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントは、要求した表示要素またはオブジェクトへの参照、取り出すべきプロパティのリスト、およびＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８に対する着目要素を識別するフィルタ、を含むバイト・メッセージを構築する。例えば、要求が特定の表示要素の子に対するものであるとき、フィルタは「可視要素のみ」と指定することができ、この方法では、その特定表示要素の子全てを返すのではなく、可視の子のみが返えされる。ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８は、次いでそのメッセージを、指名されたパイプを介してＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４に送信し、応答を待つ。

ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４はメッセージを受信し、メッセージにＩＤタグを付けて、どのＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントがそのメッセージを送信したかを識別する。ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４はメッセージをＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０に転送する。ＡＡ−ＵＩ−ＲＴＳリモート・コンポーネントはメッセージを受信し、メッセージをデシリアライズして（オブジェクト参照を調べて対象のＵＩ要素を決定することを含む）、ＡＡ−ＵＩ−インターフェース・サーバ・コンポーネント２０６ＢのＡＡ−ＵＩ−インターフェースＡＰＩを用いて要求情報を、ＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０によって公開されたインターフェース経由で収集する。ＡＡ−ＵＩ−インターフェース−サーバ・コンポーネント２０６Ｂは、ＡＡ−ＵＩ−インターフェース−サーバ・コンポーネント２０６ＢがＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４Ｂの代わりに動作できるように、ＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４Ｂの機能の一部または全部を共有することができる。ＡＡ−ＵＩ−インターフェース−サーバ・コンポーネント２０６Ｂは、サーバＵＩ３２６から要求されたアクセシビリティ情報を取得する。

ＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０は、収集した情報をバイト・メッセージにシリアライズし、そのタグＩＤの原型を維持した状態で、それを、仮想チャネルを介してＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４に送り返す。

ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネント３１４は、仮想チャネル経由でＡＡ−ＵＩ−ＲＴＳリモート・コンポーネント３２０から得たメッセージを、正確なＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントを決定するためのタグＩＤを用いて、指名されたパイプ経由で適切なＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントに転送する。説明を簡単にするため、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８を１つのみ図示するが、後述のように、幾つかの実施態様ではこれに対する複数のインスタンスおよび他のコンポーネントが実行されていてもよい。ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８は応答メッセージを受信してそのメッセージをデシリアライズする。幾つかの事例では、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８はメッセージを後処理する。例えば、プロパティ値に関してメッセージを後処理してオフセットを適用するか、またはＲＴＳホスティングにより影響されるプロパティを他の方法で調整することができる。任意の適切な後処理が完了すると、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８は処理した情報をＡＡ−ＵＩ−インターフェース−クライアント・コンポーネント２１４Ｂに送信する。

この後処理の１例は、ディスプレイ上の要求された要素の位置に関する情報に関連する。例えば、ＡＡクライアントが、ビットマップ表現３１０の最上方左の要素に関するアクセシビリティ関連情報を要求すると仮定する。その情報はサーバＵＩ３２６に関連してサーバ側で取得される。しかしながら、任意の関連位置情報は、本事例ではクライアントＵＩ３１２内部のビットマップ表現３１０で表現されるサーバＵＩに関連する。本事例では、サーバＵＩからの位置情報はクライアント・ディスプレイ２２４Ｂ全体に対して調整される。従って、本事例では、定性的に表現すると、ビットマップ表現の最上方左の要素は、一般にクライアント・ディスプレイ２２４Ｂの左上象限の中央にある。当業界の技術者は、定量的な方法で変換を行う方法を理解するはずである。相対的な位置調整および他の後処理は、クライアント・コンポーネントの任意の組合せで実現されることができる。例えば、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネント３０８またはＡＡ−ＵＩ−インターフェース・クライアント・コンポーネント２１４Ｂはこの調整を処理することができる。

さらに、幾つかの実施態様では、処理リソースは、リモート端末セッションの起動時に起動されるコンポーネント数を最小化することで節約することができる。残りのコンポーネントは、ＡＡクライアント２１６Ｂからの情報要求などの何らかの誘因に応答して起動する。他の実施態様では、起動時にコンポーネントの大部分または全てを起動または使用可能にすることができる。

クライアント・ディスプレイ２２４Ｂが単一クライアント生成ＵＩ３１２および単一ビットマップ表現３１０を含む比較的単純なシナリオで、システム１００Ｂを上述した。当業界の技術者は、本システム構成を多くの状況に渡り容易に拡張可能であることを認識するはずである。例えば、複数のＡＡクライアント・アプリケーションは、クライアント・ディスプレイ２２４Ｂに関して同時実行することができる。代わりにまたは追加として、ＡＡ−ＵＩ−ＲＴＳリモート３２０などのサーバ側コンポーネントは、多数の継続中のリモート端末セッションとの多対１の関係を処理することができる。さらに、他の実施態様はリモートＵＩの複数の表現をクライアント・ディスプレイ２２４Ｂ上で利用することができる。クライアント・マシンのユーザに対して、その表現はウィンドウなどの枠線で明確に区切るか、またはローカルに生成したＵＩから区別不能にすることができる。

ＲＴＳクライアント・ウィンドウに関して同時実行する多数のＡＡクライアントの事例では、様々なＡＡクライアントを区別する幾つかの手段が利用される。この構成の１つでは、通信手段またはパイプはそれぞれのＡＡクライアントに専用にされる。様々なパイプは、個々のＡＡクライアントを共有ＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４およびＶＣ−ホスト−クライアント３１８に接続することができる。

ＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４コンポーネントを構成して、クライアント毎のパイプと単一のＶＣ−ホスト−クライアント・コンポーネントとの間のクライアント要求およびイベントを多重化するように構成されることが可能である。この構成の１つにおいて、ＡＡ−ＵＩ−ＲＴＳ−インプロセス３１４はそれぞれのＡＡクライアントに対して一意な識別子を割当て、ＡＡ−ＵＩ−ＲＴＳリモート３２０に送信されるパケットを追加する。ＡＡ−ＵＩ−ＲＴＳリモート３２０はそれら値を不透明なものとして扱い、ＡＡ−ＵＩ−ＲＴＳ−インプロセスがどのクライアントにそのイベントを転送すべきかを知るように、それらをそのまま保持してイベントとともに返信する。

このシナリオにおいて、クライアント・ディスプレイ２２４Ｂに関わる任意の座標調整を各クライアントのＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントにより処理することができる。そのような構成は、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントに、それがパイプとＶＣとの間で転送している任意のメッセージの意味内容を理解させることを回避する。最後に、上記構成によりＡＡ−ＵＩ−ＲＴＳリモート・コンポーネントは、個々のクライアントを意識する必要がなく、または個々のクライアントの代わりにクライアント固有の状態を追跡する必要がないので、「クライアント不可知」であることができる。多重化の負担をＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントに置くことで、ＡＡ−ＵＩ−ＲＴＳリモート・コンポーネントからクライアント固有の状態を切り離すことも支援できる。

上述した実施態様などの、少なくとも幾つかの実施態様は、クライアント・ディスプレイ２２４Ｂ上の複数のビットマップ表現を含むシナリオを処理することができる。例えば、複数のリモート・アプリケーションをクライアント・ディスプレイ２２４Ｂ上の個々のビットマップ表現として表すことができる。これらの構成の幾つかにおいて、ＲＴＳ機能は、ＡＡ−ＵＩ−インターフェースが複数の仮想チャネルを生成することを可能にする。他の構成においては、単一の仮想チャネルと、およびクライアント・ディスプレイ２２４Ｂ上でビットマップとして表現される個々のサーバ側アプリケーションに対して多重化する、単一の対応ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントとを利用することができる。次いで、一部の構成は、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントとＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントとの間でパイプを、そのパイプ自体が特定のサーバ側アプリケーションで識別されるように、確立できる。別の構成は、クライアント毎に１つのパイプを、各ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントがどのＲＴＳウィンドウに対して動作しているかに関わらず、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントと会話するのに１つのパイプを使用することができるように、利用することができる。ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントは、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントが、どのウィンドウにその要求が関係するかを決定することができるパラメータをそのメッセージに追加する。他の構成は、サーバからの各アプリケーション・ウィンドウに対するハンドルまたはＨＷＮＤを、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントによってマップされることが可能なＲＴＳクライアント状態の別のマップ可能態様として利用することができる。

例えば、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントは、ローカルＲＴＳクライアント・ウィンドウのＨＷＮＤを含むメッセージをＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントに送信することができる。ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントは、ＲＴＳクライアントのウィンドウ状態（例えばそのビューポート、状態）、およびリモートＨＷＮＤに関する情報で応答することができる。そのビューポートは、ＲＴＳ−クライアント・デスクトップの位置に関する情報に関連する。ＡＡ−ＵＩ−ＲＴＳローカルは次いでこのＨＷＮＤをそのメッセージ内のパラメータとしてＡＡ−ＵＩ−ＲＴＳリモート・コンポーネントに送信できる。このアプローチは、ＡＡ−ＵＩ−ＲＴＳ−インプロセス・コンポーネントが（具体的にＲＴＳウィンドウ状態を求めるもの以外の）ほぼ全てのメッセージを不透明なものとして処理することを可能とする。これは、クライアント毎に１つのパイプを用いるアプローチが使用されることを可能にする。事実上、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントは複数のＲＴＳウィンドウ間で多重化することを担当する。この構成では、ＡＡ−ＵＩ−ＲＴＳローカル・コンポーネントがＡＡ−ＵＩ−ＲＴＳリモート・コンポーネントに対して行う呼び出しは、どのＨＷＮＤをルートまたはルート・ウィンドウとして扱うべきかを示すＨＷＮＤパラメータを含む。ルート・ウィンドウという用語はトップ・レベルのウィンドウを指す。上述のように、幾つかのシナリオでは複数のＲＴＳクライアントがサーバ・デスクトップ上の対応ウィンドウを表す。これらのウィンドウは、同一サーバセッション上のあるウィンドウを表しているけれども、トップ・レベルのＲＴＳ−クライアント・ウィンドウにより囲まれない。この事例では、ＡＡクライアントからＡＡ−ＵＩ−ＲＴＳ−インプロセスへの２つの独立した要求がありうる。このシナリオを処理するには複数の方法がある。例えば、ＡＡ−ＵＩ−ＲＴＳ−インプロセスは、ＡＡ−ＵＩ−ＲＴＳリモートを有するこのトップ・レベル・ウィンドウの各々に対して専用の仮想チャネルを使用することができる。この構成では、チャネル自体が、どのウィンドウをＡＡクライアントが参照しているかを識別する。代わりにまたは追加として、ＡＡ−ＵＩ−ＲＴＳ−インプロセスは、サーバに対して単一の仮想チャネルと、様々なトップ・レベルのＲＴＳクライアント・ウィンドウに対して到来する多重化要求を使用することができる。本アプローチでは、ＡＡ−ＵＩ−ＲＴＳ−インプロセスは各要求に対して追加のデータを利用して、どのウィンドウをＡＡ−ＵＩ−インターフェース・クライアントが参照しているかを識別する。この追加情報は、トップ・レベル・ウィンドウ（ルート・ウィンドウ）のハンドルの形式にすることができる。

システム１００Ｂは、リモート端末セッションのシナリオにおいてアクセシビリティ機能を使用可能にする構成の例のほんの１つに過ぎない。システム１００の構成は、また基本機能自体の命令を書き換えるのではなくモジュールまたはプラグイン・コンポーネントを基本機能の上に追加するようにそれ自身を適合させるシステムの例でもある。例えば本例では、ＲＴＳアクセシビリティ・サポート・コンポーネント３１６、ＶＣ−ホスト−クライアント・コンポーネント３１８などの様々なコンポーネントが、明確に識別可能な複数のモジュールまたはプラグインとしてＲＴＳ−クライアント・コンポーネント２１２Ｂの基本機能に追加される。他の利点の中でもとりわけ、このシステムは、ＲＴＳ−クライアント・コンポーネントをカスタマイズして所望の機能を提供するよりも、短い開発サイクルおよび／または高い信頼性を有することができる。さらに、上記の例が、全体のリモート・デスクトップに関連して説明される。他の事例では、クライアント・ウィンドウは全体のデスクトップとは対照的にリモート・デスクトップのサブセットを含むことができる。例えば、このサブセットは、特定のリモート・アプリケーション・ウィンドウ、およびそのアプリケーション・ウィンドウが含むＵＩとすることができる。そのアプリケーションは１つまたは複数のＵＩ要素を含むことができ、例えばＵＩ要素のサブ・ツリーを含むことができる。

（システム環境の例）
図４は、リモート端末セッションにおいてアクセシビリティ機能を使用可能にするシステムまたはコンピューティング環境例４００を表す。システム環境４００は、サーバ・デバイスまたはサーバ１０２の形式で汎用コンピューティング・システムを含む。サーバ１０２のコンポーネントは、制限されないが、１つまたは複数のプロセッサ４０４（任意のマイクロ・プロセッサ、コントローラ、等）、システム・メモリ４０６、および様々なシステム・コンポーネントを接続するシステム・バス４０８を含むことができる。１つまたは複数のプロセッサ４０４は、サーバ１０２の動作を制御し、且つ他の電子およびコンピューティング・デバイスと通信するため様々なコンピュータ実行可能命令を処理する。システム・バス４０８は、任意な数で数種類のバス構造を表し、メモリ・バスまたはメモリ・コントローラ、周辺バス、高速グラフィック・ポート、および様々なバス構造内の任意なものを用いるプロセッサ・バスまたはローカル・バスが含まれる。

コンピューティング環境４００は、サーバ１０２が利用可能な任意の媒体でありうる様々なコンピュータ可読媒体が含まれ、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体の両方が含まれる。システム・メモリ４０６は、ランダム・アクセス・メモリ（ＲＡＭ）４１０などの揮発性メモリ、および／または読取専用メモリ（ＲＯＭ）４１２などの不揮発性メモリの形式のコンピュータ可読媒体を含む。基本入出力システム（ＢＩＯＳ）４１４は、例えば起動時にサーバ１０２内部のコンポーネント間での情報転送を容易にする基本ルーチンを維持し、ＲＯＭ４１２に格納される。ＲＡＭ４１０は、典型的には、１つまたは複数のプロセッサ４０４により直接利用可能および／あるいは現在動作しているデータおよび／またはプログラム・モジュールを収容する。

サーバ１０２は、他の取り外し可能／取り外し不可能、揮発性／不揮発性コンピュータ記憶媒体を含むことができる。例として、ハードディスク・ドライブ４１６は取り外し不可能な不揮発性磁気媒体（不図示）を読み書きし、磁気ディスク・ドライブ４１８は取り外し可能な不揮発性磁気ディスク４２０（例えば、「フロッピー・ディスク」）を読み書きし、光ディスク・ドライブ４２２は、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または任意な他の種類の光媒体のような取り外し可能な不揮発性光ディスク４２４を読み書きする。本例では、ハードディスク・ドライブ４１６、磁気ディスク・ドライブ４１８、および光ディスク・ドライブ４２２を１つまたは複数のデータ媒体インターフェース４２６各々によりシステム・バス４０８に接続する。ディスク・ドライブおよび関連コンピュータ可読媒体は、サーバ１０２に対するコンピュータ可読命令、データ構造、プログラム・モジュール、および他のデータの不揮発性記憶を提供する。

任意数のプログラム・モジュールを、ハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ４１２、および／またはＲＡＭ４１０に格納することができる。そのプログラム・モジュールには、例としてオペレーティング・システム４２６、１つまたは複数のアプリケーション・プログラム４２８、他のプログラム・モジュール４３０、およびプログラム・データ４３２が含まれる。このオペレーティング・システム４２６、アプリケーション・プログラム４２８、他のプログラム・モジュール４３０、およびプログラム・データ４３２（またはそれらの任意の組合せ）の各々は、本明細書で説明したシステムおよび方法の実施形態を含むことができる。

ユーザは、キーボード４３４およびポインティング・デバイス４３６（例えば、「マウス」）などの任意な数の様々な入力装置を通してサーバ１０２と対話することができる。他の入力装置４３８（詳細には示さず）はマイクロフォン、ジョイスティック、ゲームパッド、コントローラ、パラボラ・アンテナ、シリアル・ポート、スキャナ、および／または同種のものを含むことができる。これらおよび他の入力装置は、システム・バス４０８に接続される入出力インターフェース４４０を経由してプロセッサ４０４に接続されるが、パラレル・ポート、ゲーム・ポート、および／またはユニバーサル・シリアル・バス（ＵＳＢ）などの他のインターフェースおよびバス構造で接続してもよい。

モニタ４４２または他種の表示装置を、ビデオ・アダプタ４４４などのインターフェースを経由してシステム・バス４０８に接続することができる。モニタ４４２に加えて、他の出力周辺装置は、入出力インターフェース４４０を経由してサーバ１０２に接続可能なスピーカ（不図示）およびプリンタ４４６のようなコンポーネントを含むことができる。

サーバ１０２は、リモート・クライアント・デバイスまたはクライアント１０４などの１つまたは複数のリモート・コンピュータに対する論理接続を用いてネットワーク環境で動作できる。例として、リモート・クライアント１０４はパーソナル・コンピュータ、ポータブル・コンピュータ、サーバ、ルータ、ネットワーク・コンピュータ、ピア・デバイスまたは他の共通ネットワーク・ノード、等であることができる。リモート・クライアント１０４は、サーバ１０２に関して本明細書で説明した要素および特徴の多くまたは全てを含みことが可能なポータブル・コンピュータとして示してある。

サーバ１０２とリモート・クライアント１０４との間の論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）４５０および一般的な広域ネットワーク（ＷＡＮ）４５２として示してある。上記のネットワーク環境は職場、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットで一般的である。ＬＡＮネットワーク環境で実装するとき、サーバ１０２はネットワーク・インターフェースまたはアダプタ４５４を経由してローカル・ネットワーク４５０に接続する。ＷＡＮネットワーク環境で実装するとき、サーバ１０２は、典型的には、モデム４５６または広域ネットワーク４５２上で通信を確立する他の手段を含む。モデム４５６は、サーバ１０２の内部または外部で可能であり、入出力インターフェース４４０または他の適切なメカニズムを経由してシステム・バス４０８に接続することができる。図示したネットワーク接続は例であって、コンピューティング・デバイス４０２と４４８との間の通信リンクを確立する他の手段も利用可能である。

コンピューティング環境４００で示したようなネットワーク環境において、サーバ１０２に関して示したプログラム・モジュール、またはその部分をリモート・メモリ記憶装置に格納できる。例として、リモート・アプリケーション・プログラム４５８をリモート・クライアント１０４のメモリ・デバイスで維持する。上記プログラムおよびコンポーネントは様々な時点でサーバ１０２の様々な記憶コンポーネント内に存在し、サーバのプロセッサ４０４により実行されることは理解されるが、説明のために、オペレーティング・システム４２６のようなアプリケーション・プログラムおよび他の実行可能プログラムコンポーネントを本明細書では離散ブロックとして示している。

（プロセスの例）
図５はリモート端末セッションでアクセシビリティ機能を使用可能にする例示のプロセス５００を示す。このプロセスが記述される順序は限定として解釈されるようには意図しておらず、任意数の記述したプロセス・ブロックを任意の順序で組み合わせてプロセスを実施することができる。さらに、そのプロセスを任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで実装することができる。

説明のために、以下のプロセス・ブロックを、リモート端末セッションのサーバ側とクライアント側を定義するリモート端末セッションのシナリオのコンテキストで説明する。そのため、この特別なプロセス構成では、プロセス・ブロック５０２、５０４、５１０、５１２および５１４はサーバ側で実行され、プロセス・ブロック５０６、５０８および５１６はクライアント側で実行される。

ブロック５０２で、そのプロセスはＵＩを生成する。そのＵＩはアイコン、ツールバー、メニュー等の１つまたは複数の表示要素を含むことができる。このＵＩを、ＲＴＳクライアントと関連してリモート端末セッションに利用することができる。このＵＩはサーバ・デスクトップ、単一のアプリケーション、または幾つかの他の構成などの完全なＵＩとすることが可能である。

ブロック５０４で、このプロセスは、ＵＩの表現をＲＴＳクライアントに送信する。この事例の１つにおいて、ＲＴＳ機能は、ＵＩのビットマップ表現が生成され、ＲＴＳクライアントに送信されることを引き起こす。

ブロック５０６で、そのプロセスは、リモート端末セッションにおけるＵＩの表示要素に関するアクセシビリティ機能から要求を検出する。この特別なプロセス構成において、この検出はクライアント側で行われる。他の構成において、上記の検出はサーバ側で行われてもよい。その要求は、リモート端末セッションにおいてサーバから受信したＵＩ表現の一部に関連することができる。また、その要求は、ＡＡコンポーネントから直接、またはＡＡコンポーネントと協調して動作するＡＡ−ＵＩ−インターフェースなどの何らかの中間コンポーネントから受信することもある。幾つかの構成において、アクセシビリティ機能を要求することは、その要求が、単にＵＩの表現であるＵＩの一部に関連すると認識することができる。他の構成において、アクセシビリティ機能を要求することは、実際のＵＩとＵＩ表現とを区別する能力を全く有さなくてもよい。後者の構成において、要求がローカルに生成したＵＩなどの実際のＵＩに関連するか、または（クライアント・マシンの観点から）リモートに生成したＵＩの表現に関連するかを決定する機能が含まれてもよい。次いで、この機能は要求をローカルに処理するか、または要求を必要に応じてリモート・コンポーネントに向けることで処理することができる。以下のシナリオは、その要求が、リモートに生成したＵＩまたはその表示要素に関連する、と仮定する。

ブロック５０８で、プロセスは、要求に関連するクエリを、その表示要素を生成したコンピューティング・デバイス上のコンポーネントに送信する。本事例では、その表示要素を生成したコンピューティング・デバイスはサーバとして指定される。クエリは、リモート端末セッションによって容易にされた通信手段、または独立して確立された通信手段を介して送信することができる。

ブロック５１０で、プロセスは、ＵＩに関連するクエリをサーバ側で受信する。ブロック５１２で、プロセスはクエリに応答してＵＩ情報にアクセスする。この構成の１つにおいて、この情報は、サーバ上で動作し且つアクセシビリティ関連情報をＵＩから取得するよう構成したＡＡ−ＵＩ−インターフェース機能を通して、サーバＵＩから取得する。

ブロック５１４で、取得した情報はクライアントに送信される。その情報は、ブロック５０８での要求の送信に利用される同一の通信手段または他の何らかの適切な通信手段で送信することができる。

ブロック５１６で、プロセスはクエリに対する応答をクライアント側で受信する。その応答はアクセシビリティ機能に提供されることができる。幾つかの例において、アクセシビリティ機能に対して応答を提供する前に、さらなる処理をその応答に対して行う。例えば、表示要素の相対位置に関する情報を調整して、全体のクライアント・ディスプレイの他の状況（facets）を考慮することができる。例えば、表示要素は、サーバから受信したＵＩ表現の一部であることができる。サーバはサーバＵＩに関する位置データを提供したが、そのＵＩ表現は、ローカルに生成したＵＩコンポーネントおよび／または他のリモートに生成したコンポーネントも含みうる全体のクライアント・ディスプレイのサブセットのみを備えているかも知れない。そのような場合、位置データを全体のクライアント・ディスプレイに関して調整することができる。幾つかの事例では、この情報を、ＡＡの代わりに動作するＡＡ−ＵＩ−インターフェース機能に与えることができる。このＡＡ−ＵＩ−インターフェースは、ＡＡによる使用のために情報をリファインしたり、または何らかの他の方法で下処理をしたりすることができる。

リモート端末セッションにおいて、アクセシビリティ機能を使用可能にすることに関する実施態様を、構造的特徴および／または方法に固有な用語で説明したが、請求の範囲の対象は、説明した特定の特徴または方法に必ずしも限定されないことは理解されるべきである。むしろ、特定の特徴および方法は上述の概念に対する実装態様の例を与えるものである。

リモート端末セッションのシナリオにおいてアクセシビリティ機能を使用可能にするシステムの例を示す図である。 リモート端末セッションのシナリオにおいてアクセシビリティ機能を使用可能にするシステムの例を示す図である。 リモート端末セッションのシナリオにおいてアクセシビリティ機能を使用可能にするシステムの例をより詳細に示す図である。 リモート端末セッションのシナリオにおいてアクセシビリティ機能を使用可能にする環境におけるシステム、装置、およびコンポーネントの例を示す図である。 リモート端末セッションのシナリオにおいてアクセシビリティ機能を使用可能にする１つの実施態様例のプロセス図である。

Claims (20)

1. リモート端末セッションにおいて表示要素に関するアクセシビリティ機能から要求を検出すること、
   前記要求に関連するクエリを、前記表示要素を生成したコンピューティング・デバイス上にあるコンポーネントに送信すること、および
   前記クエリに対する応答を受信すること
   を含むことを特徴とする方法。
2. 前記表示要素は、前記リモート端末セッション用に生成したリモート・デスクトップの一部を含むことを特徴とする請求項１に記載の方法。
3. 前記アクセシビリティ機能は、アクセシビリティ支援ユーザ・インターフェースのインターフェース（ＡＡ−ＵＩ−インターフェース）機能を含むことを特徴とする請求項１に記載の方法。
4. 前記送信することは、前記アクセシビリティ機能が、前記コンポーネントとの仮想チャネルを確立できるように構成されたインターフェースを公開することを含むことを特徴とする請求項１に記載の方法。
5. 前記アクセシビリティ機能が、前記表示要素を生成する前記コンピューティング・デバイス上にあるアクセシビリティ機能表現コンポーネントとの通信を確立すること可能にすることをさらに含むことを特徴とする請求項１に記載の方法。
6. 前記可能にすることは、前記アクセシビリティ機能がアクセシビリティ機能表現コンポーネントと通信できるように構成されたインターフェースを提供することを含むことを特徴とする請求項５に記載の方法。
7. 前記可能にすることは、前記アクセシビリティ機能がアクセシビリティ機能表現コンポーネントと通信できるように構成された１つまたは複数のコンポーネントを起動するための前記アクセシビリティ機能用のインターフェースを提供することを含むことを特徴とする請求項５に記載の方法。
8. 前記表示要素は、単一のユーザ・インターフェース（ＵＩ）オブジェクトを含み、前記ＵＩオブジェクトを反映するオブジェクト・ツリーのノードとして前記アクセシビリティ機能に前記応答を提示することをさらに含むことを特徴とする請求項１に記載の方法。
9. 前記提示することは、前記応答を処理して、前記リモート端末セッションに関わる少なくとも１つの要因を補償することを含むことを特徴とする請求項８に記載の方法。
10. 前記少なくとも１つの要因は、前記表示要素のソースから取得した位置データを調整して、クライアント・ディスプレイに対して前記表示要素の位置を反映することを含むことを特徴とする請求項９に記載の方法。
11. 前記送信することは、前記リモート端末セッションによって使用可能にされた仮想チャネル上で前記要求を送信することを含むことを特徴とする請求項１に記載の方法。
12. 実行されると、
    ユーザインターフェース（ＵＩ）を生成すること、
    前記ＵＩの表現をリモート端末セッション・クライアントに送信すること、
    前記ＵＩに関わるクエリを受信すること、および
    前記クエリに応答してＵＩ情報にアクセスすること
    を備える動作を実施するコンピュータ実行可能命令を備えることを特徴とするコンピュータ可読媒体。
13. 前記アクセスすることは、前記受信することに応答して開始されるアクセシビリティ支援ユーザ・インターフェース（ＡＡ−ＵＩ）のインターフェース・コンポーネントにより実現されることを特徴とする請求項１２に記載のコンピュータ可読媒体。
14. 前記受信することは、前記リモート端末セッション・クライアントからの起動要求の受信に応答して開始されるコンポーネントにより実現されることを特徴とする請求項１２に記載のコンピュータ可読媒体。
15. 前記ＵＩは、ＵＩ要素のサブ・ツリーを備えることを特徴とする請求項１２に記載のコンピュータ可読媒体。
16. 前記ＵＩ情報を、前記端末サービス・クライアントとの端末サービス・セッションにより使用可能にされた通信手段上で前記クライアントに送信することをさらに備えることを特徴とする請求項１２に記載のコンピュータ可読媒体。
17. リモート端末セッション内で表示した表示要素に対してアクセシビリティ関連情報を要求する手段と、および
    前記表示要素がリモートに生成されるか否かを決定する手段と
    を備えることを特徴とするシステム。
18. アクセシビリティ関連情報を取得可能な、前記表示要素のリモート・ソースとの通信を使用可能にする手段をさらに備えることを特徴とする請求項１７に記載のシステム。
19. 前記通信を使用可能にする手段は、前記要求する手段が前記リモート・ソースと通信するための通信手段にアクセス可能な少なくとも１つのインターフェースを提供することを特徴とする請求項１８に記載のシステム。
20. 前記インターフェースは、前記要求する手段は、前記通信を使用可能にする手段のプロセス境界内部でコンポーネントを起動させることを可能にすることを特徴とする請求項１９に記載のシステム。

Images