多数のクライアント−サーバ・セッションおよび以前のセッションへのユーザのダイナミック再接続をサポートするサーバ・オペレーティング・システム
【課題】ユーザが２つの異なったクライアント・コンピュータを使用する場合でも、ユーザが１つのセッションを開始し、その後でそのセッションに再接続できるサーバ・オペレーティング・システムを提供する。
【解決手段】ユーザがサーバに対し第１のクライアントを介して接続したとき、サーバのセッション・マネージャは、そのユーザに対する第１のセッションを作成する。その後ユーザが、サーバに第２のクライアントを使って再接続したとき、第２のセッションの作成を開始する。しかし、そのユーザが第１のセッションに関係があることを認識すると、第１のセッションを、第２クライアントのシステム・コンフィギュレーションに合うように適合させる。次に、第２のセッションを、再構成した第１セッションに再関連させて、そのユーザが、たとえ異なったクライアントからログオンしたときでも、このユーザの元のセッションに戻るようにする。
【解決手段】ユーザがサーバに対し第１のクライアントを介して接続したとき、サーバのセッション・マネージャは、そのユーザに対する第１のセッションを作成する。その後ユーザが、サーバに第２のクライアントを使って再接続したとき、第２のセッションの作成を開始する。しかし、そのユーザが第１のセッションに関係があることを認識すると、第１のセッションを、第２クライアントのシステム・コンフィギュレーションに合うように適合させる。次に、第２のセッションを、再構成した第１セッションに再関連させて、そのユーザが、たとえ異なったクライアントからログオンしたときでも、このユーザの元のセッションに戻るようにする。
【発明の詳細な説明】
【技術分野】
【０００１】
（技術分野）
本発明は、クライアント−サーバ・コンピュータ・システムに関するものである。詳細には、本発明は、クライアント−サーバ・コンピュータ・システムにおけるサーバ上で実行するサーバ・オペレーティング・システムに関する。
【背景技術】
【０００２】
（発明の背景）
ほとんどの人は、コンピュータ・オペレーティング・システムに通常慣れている。オペレーティング・システムとは、他のコンピュータ・プログラムが走ることができる環境を提供するものである。このオペレーティング・システムは、処理リソース、メモリ割当、Ｉ／Ｏデバイスのようなシステム・リソースを管理することにより、他のプログラムがそれらリソースを容易に利用できるようにする。オペレーティング・システムのあるものは、マルチタスキングであり、これは、それらが２以上のタスクの同時動作をサポートすることを意味する。マルチタスキングのオペレーティング・システムは、それらリソースを種々のプロセス間で分割し、各プロセスに対し、メモリ、処理リソースおよび少なくとも１つの実行スレッドへのアクセスを与える。
【０００３】
このクライアント−サーバ環境においては、サーバ・オペレーティング・システムはまた、クライアント・ベースのアプリケーションとの通信相互作用を取り扱うためにも呼び出す。クライアント・オペレーティング・システムは、サーバを見つけ、そしてそのサーバとの接続を要求し、そしてこのサーバは、リソースを割り当てることによってそのクライアントからの要求を取り扱う。
【０００４】
１つの周知のサーバ・オペレーティング・システムは、マイクロソフト社からのWindows（登録商標） NTサーバ・オペレーティング・システムである。このWindows（登録商標） NTサーバ・オペレーティング・システムは、マルチタスキングで、拡張可能であり、スケーラブルなオペレーティング・システムであり、これは、標準のパーソナル・コンピュータ上に実装することができる。このWindows（登録商標） NTサーバ・オペレーティング・システムは、十分に文書化されている。背景知識として、読者は、クラスタ（Helen Custer）著でマイクロソフト・プレスから出版された“Ｗｉｎｄｏｗｓ（登録商標） NTの内部（Inside Windows（登録商標） NT）”と題する書籍を参照されたい(copyright 1993)。
この書籍は、この言及により本文に含めるものとする。
【０００５】
多くのクライアント−サーバ・システムにおいては、クライアント・コンピュータは、それ自体、完全に機能する汎用コンピュータであって、それ自身のオペレーティング・システム、処理リソース、メモリ・リソース等を有している。このようなクライアントの例には、ワークステーション、デスクトップ・コンピュータ、ラップトップ等が含まれる。しかし、クライアント−サーバ・システムのあるものにおいては、このクライアント・コンピュータは、単純なマシンであって、汎用コンピュータよりも少ない機能が実装されている。例えば、クライアントは、端末として実現することもでき、これは、代表的には、サーバ・コンピュータへのアクセスをネットワークを介して可能にするのに十分な機能しか提供していない。この端末は、オペレーティング・システムを有しておらず、そのオペレーティング・システムとアプリケーションとは、サーバに常駐し、そして処理はサーバにおいて生ずる。
【０００６】
より最近になって、“ネットワーク・コンピュータ”あるいは“ＮＣ”として知られている低コストのコンピュータは、ネットワークへのアクセスを提供するための手段として導入されてきている。ネットワーク・コンピュータは、ディスプレイと、キーボードと、ネットワーク・ポートと、そして限られた処理能力とを有している。ネットワーク・コンピュータは、ある程度の限られたローカル処理を提供することができるが、ほとんどの処理に関してはサーバに主として頼っている。現在利用可能なネットワーク・コンピュータは、主として、Java（登録商標）（サン・マイクロシステムズ社が導入した言語）で書かれたアプリケーションを走らせるように構成されている。これらＮＣに近いものとしては、“Ｎｅｔ ＰＣ”として知られた別のタイプの低コストのコンピュータがあり、これは、ウィンドウズ（登録商標）（Windows（登録商標））ベースのアプリケーションとJava（登録商標）ベースのアプリケーションの双方を走らせることができる。
【０００７】
シトリックス・システムズ社（Citrix Systems Inc.）から“ウィンフレーム（WinFrame）”の名称で売られている技術は、Windows（登録商標） NTサーバ・オペレーティング・システムを拡張することによって、接続されたクライアントに対する多数のクライアント−サーバ・ウィンドウ処理セッション（clientserver windowing sessions）をサポートし、これにおいて、各セッションは、それら接続されたクライアントに対するウィンドウ処理環境を提供する。このWinFrame技術は、本質的には、USER，CONSOLEおよびGDIドライバのような低カーネル・レベル・サポート・ルーチンを複製して、その同じサーバ上で多数のウィンドウ処理セッションを提供する。各セッションは、ある１つの特定のクラッチのシステム・コンフィギュレーション（すなわち、ディスプレイ、マウス、キーボード）をサポートするように適合可能である。
【０００８】
このWinFrame技術では、１つのクライアントは、Windows（登録商標） NTサーバに接続しそしてウィンドウ処理セッションを開始することができる。このユーザに対しては、これは、このクライアントが、それ自身のWindows（登録商標）ブランドのオペレーティング・システムを走らせているスタンドアロンのWindowイネーブル式のコンピュータであるかのように見える。しかし、このセッションは、実際には、クライアントとかリモートのサーバ・コンピュータ上で生じており、そしてクライアントは、単にこのセッションに対するエントリを提供するローカルのグラフィカル・ユーザインターフェースを走らせているに過ぎない。この点で、WinFrame技術は、端末、ネットワーク中心のコンピュータのような低インテリジェントのクライアント・コンピュータにとっては特にうまく適しているが、それは、このクライアントが、それ自身のオペレーティング・システムを走らせることができることを必要としないからである。しかし、WinFrame技術は、十分にイネーブルされたクライアントに対しても同等にうまく適している。
【０００９】
シトリックスのWinFrame技術に関する１つの問題は、ユーザの視点からの使い易さが欠けていることである。各セッションは、ある１つの特定のクライアント・マシンに拘束され、したがって異なった物理的マシンからそのサーバに実際にログオンすることのあるユーザの要求を考慮していない。
【００１０】
この問題を例示するため、ある一般的なシナリオについて考える。あるユーザは、ユーザの職場にあるクライアント・コンピュータからWindows（登録商標） NTサーバにログオンするとする。この職場のクライアントは、デスクトップＰＣであって、1024 x 768の解像度の大きな２０″ＶＧＡディスプレイを有している。退社時刻に、このユーザは、一時的にそのセッションをホールトし、そしてサーバとの接続を断つ。その夜遅く、このユーザは、64０ ｘ ４８０の解像度の１１″カラー・ディスプレイをもつラップトップ・コンピュータである家庭のコンピュータからそのサーバへ再接続する。このラップトップがサーバに接続すると、シトリックスWinFrame技術は、この新たなクライアント・マシンに対し新たなセッションを作成する。このユーザは、異なったクライアントを用いているため、その古いセッションに再接続することが許されない。その結果、このユーザの職場のコンピュータで開始した以前のセッションは、そのラップトップ・コンピュータにポートされないが、それは、サーバが、それらを２つの区別できるマシンで開始した２つの区別できるセッションとして理解するからである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
したがって、この問題を克服しそしてこのユーザのニーズによりうまく対処できるようにサーバ・オペレーティング・システムを改良する必要がある。
【図面の簡単な説明】
【００１２】
【図１】図１は、クライアント−サーバ・コンピュータ・システムを示す図。
【図２】図２は、クライアント−サーバ・コンピュータ・システムにおけるサーバ・コンピュータのブロック図。
【図３】図３は、サーバ・オペレーティング・システムの１部分を示すブロック図であって、単一のクライアント−サーバ・ウィンドウ処理セッションを示している。
【図４】図４は、図３と同様のブロック図であるが、多数のクライアント−サーバ・ウィンドウ処理セッションをさらに示している。
【図５】図５は、図３と同様のブロック図であるが、ユーザがサーバに異なったクライアントからログオンする場合でも、そのユーザを以前のウィンドウ処理セッションと再関連させるダイナミック再関連プロセスをさらに示している。
【図６】図６は、図３と同様のブロック図であるが、ユーザがサーバに異なったクライアントからログオンする場合でも、そのユーザを以前のウィンドウ処理セッションと再関連させるダイナミック再関連プロセスをさらに示している。
【図７】図７は、この再関連プロセスにおけるステップを示すフロー図。
【図８】図８は、サーバ・オペレーティング・システムの部分のブロック図であって、このオペレーティング・システムが、サーバに対し同じクライアントからアクセスする多数のユーザに対し、どのように多数のセッションをサポートするかを示している。
【発明を実施するための形態】
【００１３】
（発明の摘要）
本発明は、多数のクライアント−サーバ・セッションをサポートしそしてユーザがあるセッションを開始し、そしてその後に、ユーザが２つの異なったクライアントを用いる場合でもそのセッションにダイナミックに再接続できるようにするサーバ・オペレーティング・システムに関係している。
【００１４】
１つの実現例によれば、オペレーティング・システムは、サーバ上における多数のクライアント−サーバ・セッションを可能にするマルチユーザ・セッション・マネージャを有する。さらに、このオペレーティング・システムは、１つ以上のプロトコル・スタックを管理するマルチユーザ・スタック・プロトコル・マネージャとを有し、各プロトコル・スタックは、クライアント−サーバ・セッションの間に、対応するクライアントとの通信を容易にする。
【００１５】
ユーザがサーバに対し第１のクライアントを介して接続したとき、スタック・プロトコル・マネージャは、この第１のクライアント−サーバ接続に対し第１のプロトコル・スタックを割り当てる。次に、該セッション・マネージャは、そのユーザに対する第１のセッションを作成する。記述する実現例においては、前記セッションは、リモート・クライアント上でウィンドウ処理グラフィカル・ユーザインターフェース環境をサポートするウィンドウ処理セッションである。このセッションは、１つのウィンドウ処理セッション環境をサポートする種々のソフトウェア・モジュールから成り、そしてキーボード・ドライバ、ディスプレイ・ドライバ、プロトコル・ドライバのような種々のハードウェア・ドライバを含む。第１のセッションにおいて用いるこれらドライバは、第１のクライアントのシステム・コンフィギュレーションに合うように選択する。
【００１６】
しばらくして後、このユーザが、第１のセッションを止め、そして第１のクライアントをサーバから切断する。サーバは、ユーザのこのセッションをサーバにおいて保持し、これにより、このユーザが後でこれに戻ることができるようにする。しかし、ユーザが第１コンピュータをサーバから切断する前にこのセッションを明らかに終了させた場合、このセッションを終わらせることができる。
【００１７】
後の時点で、ユーザがサーバに第２のクライアントを使って再接続する。この第２クライアントは、第１クライアントのものとは異なったシステム・コンフィギュレーションを有する。１例のシナリオとして、ユーザは、最初にユーザの職場のデスクトップ・コンピュータを介してそして後で、ユーザの家庭のラップトップ・コンピュータを介して、サーバにログオンすることがある。第２クライアントは、サーバに対し第２のクライアント−サーバ接続を介して接続し、そしてスタック・マネージャは、第２のプロトコル・スタックを第２のクライアント−サーバ接続に割り当てる。このセッション・マネージャは、次に、このユーザに対し新たな第２のセッションの作成を開始する。
【００１８】
しかし、このプロセスの間、セッション・マネージャは、このユーザが第１セッションに関係があることを認識する。セッション・マネージャは、第１セッションを、第２クライアントのシステム・コンフィギュレーションに合うように適合させる。すなわち、第１セッションは、１つ以上のコンフィギュレーション・パラメータから成る新たなセットで再構成することによって、第２クライアントの異なったシステム・コンフィギュレーションをサポートする。
【００１９】
次に、セッション・マネージャは、第２プロトコル・スタックをその再構成した第１セッションと再関連させ、これにより、たとえユーザが異なったクライアントからログオンしたときでも、ユーザがこのユーザの元のセッションに戻れるようにする。この適合は、サーバにおいてのみ生起し、したがってユーザには不可視である。この結果、ユーザは、単に同じセッションを見るに過ぎない。例えば、変更したディスプレイ・ドライバの場合には、ユーザは、同じセッションを、第２クライアントのディスプレイに対し再フォーマットしているものであるが、それを見ることになる。
【００２０】
本発明の別の面は、ダイナミック再関連を使用して、サーバに対し単一のクライアント・コンピュータから接続する多数のユーザを収容することに関係している。この状況の１例として、２人の銀行金銭出納係が同時に単一のコンピュータを使用することが一般的である。この場合、サーバは、異なったユーザがサーバに対し同じクライアントを介してログオンするとき検出する。この検出時に、サーバは、このクライアント−サーバ接続を取り扱うプロトコル・スタックを、現在のユーザと関係があるセッションに再関連させる。このようにして、サーバは、同じコンピュータを使用する多数のユーザをサポートすることができる。
【００２１】
（好ましい実施形態の詳細な説明）
図面においては、同じコンポーネントおよび特徴に対しては同じ参照番号を用いる。
【００２２】
図１は、クライアント−サーバ・コンピュータ・システム２０を示しており、これは、サーバ・コンピュータ２２を備え、これは、多数のクライアント２４（１）−２４（５）に対しネットワーク２６を介して接続している。クライアント−サーバ・コンピュータ・システム２０は、モデムを介するダイレクト・ダイアルアップ、企業ＬＡＮ（ローカル・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）およびインターネットを含む多くの異なったアーキテクチャを代表するものである。ネットワーク２６は、多くの方法で実現して、有線ベースに技術、無線技術の両方を含む、そのようなネットワーキング・コンテキストをサポートすることができる。本発明の種々の面は、１つの特定のネットワーク・アーキテクチャあるいはネットワーク技術に限定されるものではない。
【００２３】
サーバ２２は、好ましくはWindows（登録商標） NTサーバとして実現し、これは、ウィンドウ処理ユーザ・インターフェース環境をサポートする。サーバ２２は、説明の都合上このコンテキストで説明する。サーバ２２のより詳細な説明は、図２を参照して以下で行う。しかし、分かるように、サーバ２２は、Windows（登録商標） NT以外のオペレーティング・システムを使って実現することもできる。
【００２４】
クライアント２４（１）−２４（５）は、サーバ２２にネットワーク２６を介して接続することがある種々の種類のコンピュータを表している。クライアント２４（１）は、在来のデスクトップ・パーソナル・コンピュータ（ＰＣ）であり、これは、ローカルのオペレーティング・システムと、処理ユニットと、そしてストレージ・システムとを所有している。１つの例として、デスクトップ・クライアント２４（１）は、Windows（登録商標） 95またはWindows（登録商標） 98のような、マイクロソフト社からのWindows（登録商標）ブランドのオペレーティング・システムを実装した汎用ＰＣである。デスクトップ・クライアント２４（１）は、スタンドアロンのコンピュータであって、これは、主として、サーバとインターフェースすることにより、ローカルに格納されていないファイルまたは他の情報にアクセスする。
【００２５】
クライアント２４（２）は、ポータブルのラップトップ・コンピュータとして示しており、これは、ネットワーク２６に対し、在来のネットワーク・カードまたはダイアルアップ・モデム接続を介して接続することができる。このラップトップ・コンピュータ２４（２）もまた、完全な装備をもつスタンドアロンのコンピュータであって、それ自身のオペレーティング・システム、処理ユニットおよびストレージ・システムを有するように構成することができる。このラップトップ・コンピュータ２４（２）も同様に、Windows（登録商標） 95またはWindows（登録商標） 98のようなWindows（登録商標）ブランドのオペレーティング・システムを走らせるように構成することができる。
【００２６】
クライアント２４（３）は、ハンドヘルドのＰＣであり、これは、一般に汎用コンピュータよりも少ない機能しか備えていない。しかし、ハンドヘルドＰＣ２４（３）は、好ましくは、マイクロソフト社からのWindows（登録商標） CEのようなWindows（登録商標）ブランドのオペレーティング・システムを装備している。
【００２７】
クライアント２４（４）は、端末コンピュータであり、これは、最小のローカル処理でしかもローカル・メモリがほとんどない低コストのマシンである。この端末コンピュータは、ディスプレイと、キーボードと、マウス（オプション）と、そしてサーバに接続するのに十分なインテリジェンスとを備えている。全てのアプリケーションはサーバにおいて走り、そしてこの端末は、単に、サーバ・ベースの処理に対する接続ポイントを提供するだけである。
【００２８】
クライアント２４（５）は、ネットワーク・コンピュータ（Network Computer又はNC）またはNet PCのようなネットワーク中心のコンピュータ（networkcentric computer）を表している。このネットワーク中心コンピュータ・クライアント２４（５）は、主として、サーバ・ベースのアプリケーションの実行を容易にするが、Windows（登録商標）ベースのあるいはJava（登録商標）ベースのアプリケーションを走らせるため、ある程度の限られた処理能力しか有していない。
【００２９】
サーバ・コンピュータ
図２は、サーバ・コンピュータ２２の例示的実現例を示しており、これは、Windows（登録商標） NTオペレーティング・システムを装備して構成した汎用コンピュータとして実現している。サーバ２２は、処理ユニット（ＣＰＵ）３２、システム・メモリ３４、およびシステム・メモリ３４から処理ユニット３２までを含む種々のシステム・コンポーネントを結合するシステム・バス３６を含む。システム・バス３６は、種々のバス・アーキテクチャのいずれかとして実現することができ、これは、メモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含む、種々のバス・アーキテクチャの内の任意のものを使用する。
【００３０】
システム・メモリ３４は、リード・オンリ・メモリ（ＲＯＭ）３８、およびランダム・アクセス・メモリ（ＲＡＭ）４０を含む。基本入出力システム４２（ＢＩＯＳ）は、ＲＯＭ３８に格納してある。
【００３１】
サーバ２２は、ハード・ディスクまたはハード・ディスク・アレイの読み取りおよび書き込みを行うハード・ディスク・ドライブ４４、リムーバブル磁気ディスク４８の読み取りおよび書き込みを行う磁気ディスク・ドライブ４６、並びにＣＤ−ＲＯＭまたはその他の光媒体のようなリムーバブル光ディスク５２の読み取りおよび書き込みを行う光ディスク・ドライブ５０、の内の１つ以上を有する。ハード・ディスク・ドライブ４４、磁気ディスク・ドライブ４６、および光ディスク・ドライブ５０は、ハード・ディスク・ドライブ・インターフェース５４、磁気ディスク・ドライブ・インターフェース５６、および光ドライブ・インターフェース５８によって、それぞれシステム・バス３６に接続してある。これらのドライブおよびそれに関連するコンピュータ読み取り可能媒体は、コンピュータ読み取り可能の命令、データ構造、プログラム・モジュール、およびサーバ２２用のその他のデータの不揮発性記憶を行う。
【００３２】
ハード・ディスク、リムーバブル磁気ディスク４８およびリムーバブル光ディスク５２について記述したが、データを格納するのに他のタイプのコンピュータ読み取り可能媒体を使用することができる。このような他の媒体は、磁気カセット、フラッシュ・メモリ・カード、ディジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）等を含む。さらに、サーバ２２は、ＲＡＩＤ（独立ディスクの冗長アレイ）ストレージ・システムのような独立のストレージ・システム上に格納したデータを供給するように構成することもできる。
【００３３】
多数のプログラム・モジュールは、ハード・ディスク、磁気ディスク４８、光ディスク５２、ＲＯＭ３８またはＲＡＭ４０上に格納することができる。これらプログラムは、サーバ・オペレーティング・システム６０、１つ以上のアプリケーション・プログラム６２、その他のプログラム・モジュール６４、およびプログラム・データ６６を含む。
【００３４】
ユーザは、キーボード６８およびマウス７０のような入力デバイスによって、コマンドおよび情報をサーバ２２に入力することができる。他の入力デバイス（図示せず）として、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星パラボラアンテナ、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バス３６に結合したシリアル・ポート・インターフェース７２を介して、処理ユニット３２に接続しているが、代替的には、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ）のようなその他のインターフェースによって接続することもできる。
【００３５】
モニタ７４または別のタイプのディスプレイ・デバイスも、ビデオ・アダプタ７６のようなインターフェースを介して、システム・バス３６に接続する。サーバ・コンピュータ２２は、Ｔ１またはＴ３のインターネット接続のような、ネットワーク２６を介する通信を確立するため、ネットワーク・インターフェースまたはアダプタ７８，モデム７９または他の手段を有する。モデム７９は、クライアントからダイアルアップ接続を容易にする。
【００３６】
概略のソフトウェア・アーキテクチャ
コンピュータ・システム２０は、クライアント２４（１）−２４（５）がサーバ２２上でWindows（登録商標） ブランドのオペレーティング・システム並びにアプリケーションを走らせることができるようにするソフトウェア・アーキテクチャを実装している。このソフトウェア・アーキテクチャは、サーバ・ベースのマルチクライアント・コア、クライアント・ベースのモジュール、およびサーバとクライアントとの間の通信を可能にするリモート・プロトコルを備えている。
【００３７】
サーバ・ベースのマルチクライアント・コアは、サーバが、多数の同時のクライアント・セッションをホスト（host）することができるようにする。マルチクライアント・コアは、オペレーティング・システム６０の１部分として常駐し、そしてプロセッサ３２上で実行する。このマルチクライアント・コアは、ウィンドウ処理イネーブル式のクライアント（すなわち、デスクトップ・クライアント２４（１）、ラップトップ・クライアント２４（２）、ハンドヘルドＰＣクライアント２４（３）のような、ローカルのウィンドウ処理オペレーティング・システムを走らせることができるクライアント）、並びに非ウィンドウ処理クライアント（すなわち、端末クライアント２４（４）およびネットワーク中心クライアント２４（５）のような、ローカルのウィンドウ処理オペレーティング・システムを走らせることができないクライアント）との双方をサポートする。
【００３８】
このマルチクライアント・サーバ・コアは、それらクライアントの内の任意のものが、サーバにログインしウィンドウ処理セッションをサーバにて走らせることができるようにする。１実施形態においては、マルチクライアント・サーバ・コアは、シトリックスWinFrame技術を実装し、これは、Windows（登録商標） NTサーバ・オペレーティング・システムを拡張することにより、多数のクライアントに対し多数のウィンドウ処理環境をサポートする。WinFrame技術は、図３および図４を参照して以下に詳述する、クライアント−サーバ・ウィンドウ処理セッションを複製する手段を提供する。しかし、マルチクライアント・サーバ・コアは、その基本のWinFrame技術を超えるものであって、サーバにおけるウィンドウ処理セッションを維持し、かつユーザが異なったクライアントを使って再接続したときでもユーザをダイナミックにそれらのセッションに再接続する手段を提供する。
【００３９】
このクライアント・ベースのモジュールは、クライアントのメモリ内に常駐し、そしてクライアントの処理ユニット上で実行する。このクライアント・ベース・モジュールは、グラフィカルのウィンドウ処理ユーザ・インターフェース（ＵＩ）を走らせるコードを含んでいる。このコードは、端末、ネットワーク中心コンピュータ、Windows（登録商標）イネーブル式コンピュータ（Windows（登録商標）enabled computers）、UNIX（登録商標）ベースのコンピュータ、DOSベースのコンピュータを含む、広範なハードウェア上で走ることができる。ユーザに対しては、クライアントは、ウィンドウ処理オペレーティング・システムのローカル・バージョンを走らせているかのように見えるが、ただしこのオペレーティング・システムの機能は全てサーバにおいて発生している。
【００４０】
本ソフトウェア・アーキテクチャのプロトコル・コンポーネントは、クライアントが、ネットワークに接続するのを可能にし、そしてウィンドウ処理ＵＩをユーザに対し提示する。システム２０において使用できる１つの適当なプロトコルは、ＭＳリモート・デスクトップ・プロトコル（MS Remote Desktop Protocol）であり、これは、T.128/T.120プロトコル（国際標準マルチチャンネル会議プロトコル）の高度にスケーラブルな派生物である。T.128/T.120は、周知のプロトコルであり、したがって詳細な説明はしない。T.128/T.120に関する更なる情報については、読者は、国際電気通信連合（ＩＴＵ）からのT.128/T.120標準を参照されたい。尚、これは、言及により本文に含めるものとする。
【００４１】
従来技術のクライアント−サーバ・システムとは対照的に、コンピュータ・システム２０は、特定のクライアント・コンピュータをサポートするのではなく、ユーザのニーズをサービスするものとしてサーバ・ネットワークのビューを行うように適合させてある。この概念シフトは、コンピュータ・システム２０が、どのクライアント２４をユーザがサーバ２２をアクセスするのに用いていようともそのユーザをサポートすることを意味している。従来技術のクライアント−サーバ・システムは、代表的には、マシン中心の見方を強調したものであり、各々の接続を、特定のクライアント・コンフィギュレーションのニーズに関して扱う。
【００４２】
この二分法の１例として、背景部分で示したシナリオでは、職場のクライアント・コンピュータからサーバにログオンしたユーザが、セッションを開始し、そしてこのセッションをこれを終了させずに止め、そして後で家庭のコンピュータからログオンする場合を記述している。従来技術のアーキテクチャでは、サーバは、各クライアントに対し新たなセッションを作成するが、それは、これらが、異なったシステム・コンフィギュレーションをもつ２つの異なったクライアントから生じたものだからである。ユーザが第１のクライアントからログオンしたとき、サーバは、この特定のクライアント・コンピュータをサポートするのに特有のディスプレイ・ドライバ、キーボード・ドライバ等を利用するセッションを作成する。サーバはまた、このクライアント・コンピュータと通信するのに適した１つのタイプのプロトコルを使用することになる。
【００４３】
ユーザが第２のクライアントからログオンしたとき、サーバは、この第２のクライアント・コンピュータをサポートするのに特有の、異なったディスプレイ・ドライバ、キーボード・ドライバ等をロードする別のセッションを作成する。サーバはまた、異なったタイプの通信プロトコルを用いることもできる。こうして、サーバは、同じユーザがこのユーザがサーバに接続するマシンに無関係に同じセッションを続行したい場合でも、マシン依存性のセッションを作成する。この従来技術は、マシン中心のアーキテクチャを表している。
【００４４】
一方、コンピュータ・システム２０は、ユーザ中心のものである。上記のシナリオにおいて、コンピュータ・システム２０は、ユーザがサーバに対し１つのクライアントから接続し、セッションを開始そしてこれを終了せずに停止し、そして後でこの同じセッションに異なったクライアントから戻るのを可能にする。サーバは、この新たなクライアントに対し新たなセッションを作成することはせず、むしろ、元のセッションを、第２のクライアントをサポートするため適当なドライバ、プロトコルおよびコンフィギュレーション・パラメータと適合させる。
【００４５】
例えば、ユーザが最初に、1024 x 768の解像度の大きな２０″ＶＧＡディスプレイをもつ職場のコンピュータからログオンするとする。サーバは、1024 x 768の解像度の２０″ＶＧＡディスプレイをサービスする適当なディスプレイ・ドライバでウィンドウ処理セッションを確立する。ユーザがその後でユーザ自身の64０ ｘ ４８０の解像度の１１″ディスプレイをもつラップトップ・コンピュータからログオンするとき、サーバは、新たなセッションの確立を開始する。しかし、このセッション開始プロセスの間において、サーバは、このユーザが以前のセッションと関係があったことを認識する。このとき、サーバは、64０ ｘ ４８０の解像度の１１″ディスプレイに適した新たなディスプレイ・ドライバを用いるように以前のセッションを変更する。次に、サーバは、このユーザを、その以前のセッションに自動的に再関連させる。進行中の作業は、ダイナミックにその新たな１１″ディスプレイにリサイズし、そしてユーザは、このユーザが職場のコンピュータでの作業を止めた所から続行することができる。
【００４６】
サーバ・オペレーティング・システム６０は、ユーザが異なった動作特性をもつ異なったマシンからログオンする場合でも、ユーザをそれらのそれぞれのセッションに対し有利に再関連させることができるようにする。この再関連プロセスは、完全にサーバにて生じ、サーバは自動的にクライアントに適合する。このプロセスは、ユーザとクライアント・コンピュータからは見えない。
【００４７】
サーバ・オペレーティング・システムを実装する１つの好ましい方法は、図３ないし図６を参照して以下に説明する。この説明に続き、本発明の別の面について説明するが、これは、単一のクライアント・マシンからのサーバにおいて走っている多数のウィンドウ処理セッション間でのスイッチングを含んでいる。
【００４８】
サーバ・ベースのダイナミック再関連
本発明の１つの面は、ユーザを、彼らのそれぞれのウィンドウ処理セッションに再関連させ、そしてこれらウィンドウ処理セッションを自動的に調節することによって任意の新たなクライアント・システム・コンフィギュレーションに対処することに関している。このダイナミック再関連は、完全にサーバにおいて起きるものである。
【００４９】
図３は、サーバ・オペレーティング・システム６０の１部分を示しており、これは、多数のウィンドウ処理セッションを形成するためウィンドウ処理モジュールの複製を可能にするマルチクライアント・コアを含んでいる。オペレーティング・システム６０は、特権プロセッサ・モードで走るコード（これは“カーネル・モード”とも呼ぶ）と、非特権プロセッサ・モード（一般に“ユーザ・モード”と呼ぶ）で走るアプリケーションまたはその他のサービス・ルーチンとを含む。
【００５０】
オペレーティング・システム６０は、ユーザ・モードで実施するマルチユーザ・セッション・マネージャ９０を含んでいる。このマルチユーザ・セッション・マネージャ９０は、クライアントによる使用のためサーバ上に常駐する多数のクライアント−サーバ・ウィンドウ処理セッションの作成を可能にする。さらに、オペレーティング・システム６０は、カーネル・モードで実施しそしてセッション・マネージャ９０と緊密にインターフェースするプロトコル・スタック・マネージャ９２を含む。マルチユーザ・セッション・マネージャの指揮の下、プロトコル・スタック・マネージャ９２は、図３においてプロトコル・スタック９４により表すように、１つ以上のプロトコル・スタックを作成しそして管理することにより、クライアント−サーバ・ウィンドウ処理セッションの間において対応する外部クライアントとの通信を容易にする。これらプロトコル・スタックは、ある種のタイプの通信プロトコルにしたがって実現し、例えば、TCP/IPトランスポート上のRDP、IPX上のRDP、非同期シリアル接続（モデム）のトップ上のRDP等である。
【００５１】
セッション・マネージャ９０とプロトコル・スタック・マネージャ９２の１つの例示的な実現例は、シトリックス・システムズ社からのインテリジェント・コンソール・アーキテクチャ（ＩＣＡ：Intelligent Console Architecture）を使用することである。このシトリックスＩＣＡは、Windows（登録商標） NTサーバ・オペレーティング・システムを拡張して、接続したクライアントに対し多数のウィンドウ処理セッションを提供する。
【００５２】
説明の都合上、ここで、クライアント２４（１）がサーバ・ベースのウィンドウ処理セッションを走らせたいとする。クライアント２４（１）は、Windows（登録商標） イネーブル式のデスクトップ・コンピュータとして示している。しかし、他のタイプのクライアントも使用でき、これには、端末クライアント、ネットワーク中心クライアントが含まれる。クライアント２４（１）は、接続要求を周知の接続ポートに対し送る。サーバ・オペレーティング・システム６０は、オブジェクト９６で表すように、この接続要求を受け入れそして通信ポートを作成する。この通信ポート９６は、このクライアントに対し、サーバにメッセージまたはコールバック（callback）を送るハンドルを提供する。
【００５３】
マルチユーザ・セッション・マネージャ９０は、新たな転送スレッドを作成しそして起動して、この新たなクライアント要求にサービスする。サーバ・オペレーティング・システム６０、すなわちプロトコル・スタック・マネージャ９２は、プロトコル・スタック９４を通信ポート９６に割り当てる。このプロトコル・スタックは、次に、接続クエリ・モードに入り、ここで、キーボード・レイアウト／ロケール、希望のビデオ解像度等のようなクライアント能力とサーバ能力とを、その後に交換する。
【００５４】
プロトコル・スタック９４は、最初は、通信エンドポイントをもつコンテナである。活性化の間、このスタック・コンテナには、少なくとも２つのドライバ、すなわち、WinStationドライバ（ＷＤ）とトランスポート・ドライバ（ＴＤ）をロードする。トランスポート・ドライバは、より低いレベルのドライバであって、この接続を行うのに使用する通信トランスポートを介してデータの転送を容易にするものであり、これによりトランスポート独立性を提供する。さらに、プロトコル・ドライバ（ＰＤ）を、ＷＤとＴＤとの間にレイヤとして置くことにより、圧縮、信頼性のあるデータ・フロー、暗号化、フレーム化のような追加のフィーチャを提供することもできる。１例として、WinStation、プロトコルおよびトランスポートの各ドライバは、圧縮形TCP/IPトランスポートを介するRDPデータ・ストリームを取り扱うために実装することもできる。WinStationドライバは、サーバ上で作成されている最中のウィンドウ処理セッションに対するリモート・アクセスを提供する。このWinStationドライバは、カーネル・モード・ドライバ（ＳＹＳ）として実装し、これには、リモート・マウス、キーボード、キャラクタ・モード・ディスプレイ・コマンド、および１つの仮想チャンネル集合に対するアクセスを提供する。
【００５５】
このクライアントとの接続を確立しそしてウィンドウ処理セッションに対するクライアント要求を受け取った後、オペレーティング・システム６０は、１つのウィンドウ処理セッションを作成し、これは、図３ではセッション１として示している。シトリックスWinFrame技術においては、このウィンドウ処理セッションには、クライアント−サーバ・ルーチンCSRSS.EXEを走らせることが関係し、これは、一般にCSRSSモジュール９８と呼ぶ。このオペレーティング・システムのWindows（登録商標） NT3.xバージョンにおいては、CSRSSモジュール９８は、USER，CONSOLE，GDIおよび他のサポート・ルーチンに対しマイクロソフトが書いたコードの全てを含む。加えて、モジュール９８は、ハードウェア・ディスプレイに対するハードウェア・デバイス・ドライバ、このハードウェア・ディスプレイに対するＧＤＩインターフェース（ＧＤＩドライバ）、マウス・ドライバ、キーボード・ドライバの集合を含んでいる。
【００５６】
Windows（登録商標） NT4.0または5.0のようなWindows（登録商標） NTサーバ・オペレーティング・システムの新しいバージョンでは、CSRSSモジュール９８のUSERおよびGDIの部分は、カーネル・モードに、WIN32K.SYS １００と呼ぶモジュールに移す。CSRSSモジュール９８とWin32Kモジュール１００は、ユーザ−カーネル・ラインに渡って密に一体化させている。図３は、Windows（登録商標） NTのより新しいバージョンにおいて実装しているソフトウェア・モジュールを示している。
【００５７】
クライアントがウィンドウ処理セッションを要求すると、サーバ・オペレーティング・システムは、CSRSSモジュール９８とWIN32Kモジュール１００を作成して、それらハードウェア・デバイスを開き、そしてリモートのクライアントのシステム・コンフィギュレーションとコンパチブルの適切なＧＤＩディスプレイ・ドライバ１０２およびプロトコル・ドライバ１０４をロードする。本例では、クライアント２４（１）は、デスクトップ・コンピュータであって、1024 x 768の解像度をもつＶＧＡモニタを有しており、そしてRDPプロトコルを使用するものである。これらドライバをロードした後、プロトコル・スタック９４をウィンドウ処理セッション１にバインドする。このクライアントとの通信は、プロトコル・スタック９４からプロトコル・ドライバ１０４への矢印で示すように、ウィンドウ処理セッション１に渡す。
【００５８】
セッション・スタートアップの１部分として、リモート・クライアント２４（１）にいるユーザに対し、Windows（登録商標）ログオン（ＷＬ）モジュール１０６を介して、ユーザ識別（ＩＤ）を入力するようプロンプトする。オペレーティング・システムは、このユーザＩＤをウィンドウ処理セッション１と関連させる。このことは、ウィンドウ処理セッション１に対するユーザ・モード内の“ユーザ１”のラベルを付したボックスで表している。
【００５９】
次に、サーバ・オペレーティング・システムは、クライアント・コンピュータ２４（１）上でウィンドウ処理環境を提供する。このクライアント・ベースのコードは、ウィンドウ処理のグラフィカル・ユーザインターフェースを走らせ、これは、ユーザが、サーバ上でアプリケーションを開始させ、そしてWindows（登録商標）ベースのシステムに共通の他の機能を実行することができるようにする。
【００６０】
この最初のプロトコル・スタック９４がセッション１にバインドされた状態で、サーバ・オペレーティング・システム６０は、第２のプロトコル・スタックに対するコンテナを作成することにより、別のクライアントを収容する準備を行う。第２のクライアントがこのサーバに接続してあるウィンドウ処理セッションを走らせたとき、スタック・マネージャ９２は、そのプロトコル・スタックをこの新たなクライアントに割り当てる。
【００６１】
図４は、第２のクライアント２４（４）に対する通信ポート９６（２）に接続した第２のプロトコル・スタック９４（２）を示している。マルチユーザ・セッション・マネージャ９０は、セッション２のラベルを付した新たなクライアント−サーバ・ウィンドウ処理セッションを作成して、この第２クライアント２４（４）に対応する。第２セッション２は、第１セッション１の複製であり、そしてCSRSSモジュール９８（２）とWin32Kモジュール１００（２）のコピーを含む。
図３を参照して説明したように、第２ユーザ２は、ログオンし、そしてサーバ・オペレーティング・システムは、その適当なドライバをロードしてクライアント２４（１）をサービスする。この場合、クライアントは、端末コンピュータであって、より低い解像度800 x 600のディスプレイを有しまたTCP/IPトランスポートに対するRDPディスプレイ・プロトコルを用いている。ウィンドウ処理セッション２は、第２クライアント・マシン２４（４）をサービスするプロトコル・スタックにバインドする。
【００６２】
各セッションは、それ自身の関連するプロトコル・スタックに対するコンテナを保持する。この例では、セッション１は、関連するプロトコル・スタック９４（１）を有し、そしてセッション２は、関連するプロトコル・スタック９４（２）を有する。
【００６３】
より多くのクライアントがサーバに接続するにつれ、サーバ・オペレーティング・システム６０は、より多くのウィンドウ処理セッションを複製し続ける。多数のクライアント−サーバ・ウィンドウ処理セッションを発生するためそれらモジュールを複製する能力は、背景の箇所で述べたシトリックス・システムズ社からのWinFrame技術を使用して実現する。
【００６４】
残念ながら、このシトリックスWinFrame技術に関する問題は、ユーザの視点からの使い易さの欠如である。WinFrameを使用すると、各ウィンドウ処理セッションは、特定のクライアント・マシンおよびこのマシンのシステム・コンフィギュレーションにバインドされる。図４に示したシステムを仮定すると、在来のWinFrame技術は、第１ウィンドウ処理セッション１を、1024 x 768 モニタとRDPプロトコルを有するデスクトップ・コンピュータ２４（１）のシステム・コンフィギュレーションに結び付け、そして第２ウィンドウ処理セッション２を、800 x 600モニタとRDPプロトコルを有する端末コンピュータ２４（４）のシステム・コンフィギュレーションに結び付ける。
【００６５】
シトリックスWinFrame技術は、サーバに対し物理的に異なったマシンから実際にログオンすることのあるユーザのニーズに対応するものではない。したがって、ユーザが、１つのクライアント・コンピュータからのウィンドウ処理セッションを止め、そしてサーバに別のクライアント・コンピュータからログオンするとき、WinFrame技術は、それら２つのクライアント・コンピュータが共通のビデオ解像度を共有していない場合には、新たなウィンドウ処理セッションを作成することになる。ユーザは、その古いセッションに再接続することが許されない。
【００６６】
しかし、本発明のクライアント−サーバ・システムにおいては、サーバ・オペレーティング・システムは、ユーザのこのニーズに対応し、そしてユーザが異なったマシンから再接続できるウィンドウ処理セッションをサポートするように設計する。上記の例から、ユーザ１が1024 x 768 ＶＧＡ モニタとRDPプロトコルとをもつデスクトップ・コンピュータ２４（１）を使用してサーバに接続することを想い出してもらいたい。
【００６７】
この例で続けて、ユーザ１が、ウィンドウ処理セッション１を終了せずに、サーバ６０との接続を断つと仮定する。このユーザは、職場を離れそして家庭に帰る。家庭にいる間、このユーザは、その日の早くに開始したセッションを続けることにする。ユーザは、サーバに対し、家庭にある第２のクライアント・コンピュータから接続する。
【００６８】
図５は、ユーザ１が、図３を参照して上記したように、最初にサーバに対し第１のクライアント２４（１）を使って第１のクライアント−サーバ・ウィンドウ処理セッション１を作成し、そしてこの後、第１のクライアント２４（２）を使ってサーバに対し接続する、という状況を示している。第１のセッションの中断時に、RDPおよびTCP/IPのスタック・ドライバを先にロードしたコンテナは、空にし、そしてその関連の通信エンドポイントを壊す。これは、空のプロトコル・スタック９４（１）で表している。
【００６９】
このユーザが後で第２クライアント２４（２）を使ってログオンしたとき、マルチユーザ・セッション・マネージャ９０は、最初は、ログオンした者が新たなユーザであるかのようにして、第２のセッション２を作成する。この例では、クライアント２４（２）は、640 x 480解像度をもつフラットパネルの１１″カラー・ディスプレイを備えたラップトップ・コンピュータである。クライアント２４（２）は、RDPプロトコルを使用する。したがって、第２のクライアント２４（２）は、図３で使用した第１のクライアント２４（１）とは異なったシステム・コンフィギュレーションを有している。
【００７０】
この接続プロセスは、図３で説明したのと同じである。マルチユーザ・セッション・マネージャ９０は、新たな転送スレッドを作成し起動して、この新たなクライアント要求にサービスする。プロトコル・スタック・マネージャ９２は、第２のプロトコル・スタック９４（２）を、クライアント２４（２）が接続した通信ポート９６（２）に割り当てる。この第２プロトコル・スタック９４（２）は、ある通信エンドポイントをもつ空のコンテナから成っている。このスタック・マネージャは、デフォルトのドライバをこのプロトコル・スタック９４（２）にロードし、そしてクライアント通信を（点線の矢印で示すように）セッション２に渡す。これら初期化の間においては、オペレーティング・システムは、まだこのユーザが誰であるか気づいていない。
【００７１】
ユーザ１のユーザＩＤを、このログオン・プロセスの１部分として受けると、Windows（登録商標） ログオン（ＷＬ）モジュール１０６は、ユーザ１が、以前のセッション、すなわちセッション１に関係があることを認識する。しかし、ＷＬモジュール１０６は、完全に新たなセッションの作成を続行するのではなく、ユーザ１を、（実線の矢印で表したように）このユーザの以前のセッション１に再関連させる。
【００７２】
この再関連には、サーバ・オペレーティング・システムを、このユーザの新たなクライアント・コンピュータ２４（２）のシステム・コンフィギュレーション・パラメータに適合させることが含まれる。この再関連プロセスは、ユーザまたはクライアントには可視ではない。ユーザの視点からは、ユーザは、このユーザがこのセッションの前に止めたのと同じポイントに戻っている。
【００７３】
本発明のある面によれば、サーバ・オペレーティング・システム６０は、元のセッション１におけるWin32Kモジュール１００（１）を変更することにより、クライアント・コンピュータ２４（２）に適合する異なったドライバおよびデバイスを使用するようにする。この例では、Win32Kモジュール１００（１）は、640 x 480の低い解像度の小さな１１″ディスプレイに対応するように適合させる。
サーバ・オペレーティング・システム６０は、ＧＤＩディスプレイ・ドライバ１０２（１）を、1024 x 768 ＶＧＡモニタに対するドライバから640 x 480のフラットパネルのカラー・ディスプレイへ変化させる。クライアント２４（２）は、同じRDPプロトコルを用いるため、Win32Kモジュール１００（１）は、元のプロトコル・ドライバ１０４（１）を保つ。
【００７４】
加えて、本発明の別の面は、元のクライアント−サーバ接続において使用していたプロトコル・スタックの以前のスタック・コンテンツを、以前のセッション１に再関連させることである。好ましい実現例では、第２のスタックからのスタック・コンテンツ（WinStationドライバ（ＷＤ）、プロトコル・ドライバ（ＰＤ）、およびトランスポート・ドライバ（ＴＤ））と、ライブの接続エンドポイントとは、以前のセッション１に対する第１のプロトコル・スタック９４（１）に移し戻す。
【００７５】
図６は、この新たなクライアント・コンピュータをサポートするためWin32Kモジュール１００（１）を変更した結果を示している。ディスプレイ・ドライバ１０２（１）は、このときには、640 x 480フラットパネルのカラー・ディスプレイに対するドライバとなっている。加えて、スタック・コンテンツは、セッション１のプロトコル・スタック９４（１）内にロードし戻す。この結果、サーバは、ユーザがこのときアクセス・ポイントとして用いているクライアント・コンピュータに対し、ダイナミックに適応する。セッション２とその関連のプロトコル・スタック９４（２）は、一旦この再関連が完了したときには、壊すことになる。
【００７６】
本例では、ディスプレイ・データは、ユーザの新たなクライアント・コンピュータ２４（１）に適合するようにダイナミックにリサイズする。このセッションは、ユーザにとっては同じものに見え、ユーザのより小さく解像度の低いスクリーンに対しフォーマットし直しているだけである。以前のWinFrame技術は、この再関連プロセスを可能にするものではなく、したがって元のセッションを、新たなクライアント・コンピュータ２４（１）に供給することができなかった。
【００７７】
上記の例は、サーバ・セッションを、異なったディスプレイ・サイズおよび解像度に合うように適合させることを強調したものである。これは、単なる１例に過ぎない。サーバにおいて考慮することのできる他の可能なクライアント・コンフィギュレーション・パラメータには、キーボードのタイプ、キーボード・レイアウト（QWRTYとDvorak）、プロトコル・タイプ（例えば、TCP/IP に対するRDPと非同期モデムに対するRDP）、言語（例えば、英語とスペイン語）、メモリ・ドライブおよび周辺装置がある。
【００７８】
図７は、このダイナミック再関連プロセスにおけるステップを示している。これらステップは、サーバ・オペレーティング・システム内のコードとして実現しており、好ましくは、ユーザ認証ソフトウェアをWindows（登録商標） ログオン・モジュール内に備えて有するマルチユーザ・セッション・マネージャの１部分として実現する。ステップ１２０において、ユーザは、サーバにあるクライアントを介して接続する。サーバは、この接続プロセスを開始してクライアント−サーバ接続を形成し（ステップ１２２）、そして新たなクライアント−サーバ・ウィンドウ処理セッションの作成を開始する（ステップ１２４）。
【００７９】
この初期化プロセスの間、サーバ・オペレーティング・システムは、このユーザが、まだ終了していない以前の任意の活性のセッションに関係があるがどうか解析する（ステップ１２６）。もしない場合（すなわち、ステップ１２６からの“Ｎｏ”分岐）、サーバ・オペレーティング・システムは、このユーザに対する新たなセッションの作成を完成させる（ステップ１２８）。
【００８０】
一方、このユーザが以前の活性のセッションに関係がある場合（すなわち、ステップ１２６からの“Ｙｅｓ”分岐）、サーバ・オペレーティング・システムは、このユーザを、その以前の活性のセッションに再関連させる（ステップ１３０）。これには、この現在接続したユーザのプロトコル・スタックおよび接続エンドポイントを元のセッションに再関連（すなわち、転送）させること（ステップ１３２）、並びに以前の活性のセッションを適合させることによって現在のクライアントに適した任意のシステム・コンフィギュレーション変化に対応すること（ステップ１３４）とが含まれる。
【００８１】
キオスク環境
本発明の別の面は、ダイナミック再関連を使用して、サーバに対し単一のクライアント・コンピュータから接続する多数のユーザに対処することに関係する。この状況の１つの例として、２人以上の銀行金銭出納係が同じコンピュータを利用すること、あるいは２人以上の販売員が１つのコンピュータ・レジスタを用いることが一般的である。多数のユーザが同一のコンピュータに頼るこの環境は、一般に、“キオスク”環境と呼んでいる。
【００８２】
図８は、クライアント２４（４）をサーバ・オペレーティング・システム６０にプロトコル・スタック９４を介して接続したものを示している。多数のユーザ１−Ｎは、同じクライアント２４（４）を使用している。マルチユーザ・セッション・マネージャ９０は、ユーザ１−Ｎの各々に対しクライアント−サーバ・ウィンドウ処理セッションを作成する。各ウィンドウ処理セッションは、１つのCSRSSモジュールと１つのWindows（登録商標）ログオン・モジュール（ユーザ・モードにおける“ユーザ”ブロックとして表す）と、そしてカーネル・モードにおいてWin32Kモジュールを含んでいる。各セッションはまた、関連したプロトコル・スタック９４を有している。
【００８３】
第１のユーザがサーバにログオンすると、セッション・マネージャ９０は、この第１ユーザ１に対し第１のセッション１を作成する。Win32Kモジュールは、その適当なドライバおよびデバイスを提供して、端末２４（４）上に１つのウィンドウ処理セッションを実現する。内部的には、オペレーティング・システムは、実線の矢印１４０で表すように、プロトコル・スタック９４（１）をセッション１に関連させる。
【００８４】
ユーザ１が１つのタスクを完了すると、このユーザは、そのセッションを、ログオフしたりあるいは他の場合にはこのセッションを終了させたりせずに、フリーズさせる。このとき、別のユーザが、この端末２４（４）を自由に使用できる。ここで、ユーザ２がサーバにログオンすると仮定する。この第２のユーザ２に対して、セッション・マネージャ９０は、第２のセッション２を作成する。セッション２におけるWin32Kモジュールはまた、その適当なドライバおよびデバイスを提供することにより、端末２４（４）上で１つのウィンドウ処理セッションを実現する。オペレーティング・システムは、点線の矢印１４２で表すように、この第２のプロトコル・スタック９４（２）をセッション２に関連させる。このプロセスは、Ｎ人のユーザに対し続けることができる。
【００８５】
このとき、端末が再び自由に使用できるようになったとき、ユーザ１がセッション１に戻りたいことがある。このユーザは、このユーザ自身のＩＤを再びタイプする。オペレーティング・システムは、最初は、新たなセッションおよび関連のプロトコル・スタックの作成を開始する。しかし、オペレーティング・システムが、このユーザが前に存在した中断されたセッションを有すると認識すると、このユーザをその既存のセッション１に再関連させる。スタック・コンテンツとライブの通信エンドポイントとは、セッション１との関連のため、プロトコル・スタック・コンテナ９４（１）に転送し戻す。このようにして、サーバ・オペレーティング・システムは、同じクライアント・コンピュータからの多数のユーザのセッションを収容する。
【００８６】
以上、本発明について、構造上の特徴および方法上のステップに特有の用語で説明したが、添付の特許請求の範囲に記載の本発明は、必ずしも記述したこの特定の特徴またはステップに限定されるものではない、と理解されたい。これら特定の特徴およびステップは、保護を請求する発明を実施する好ましい形態として開示したに過ぎないものである。
【技術分野】
【０００１】
（技術分野）
本発明は、クライアント−サーバ・コンピュータ・システムに関するものである。詳細には、本発明は、クライアント−サーバ・コンピュータ・システムにおけるサーバ上で実行するサーバ・オペレーティング・システムに関する。
【背景技術】
【０００２】
（発明の背景）
ほとんどの人は、コンピュータ・オペレーティング・システムに通常慣れている。オペレーティング・システムとは、他のコンピュータ・プログラムが走ることができる環境を提供するものである。このオペレーティング・システムは、処理リソース、メモリ割当、Ｉ／Ｏデバイスのようなシステム・リソースを管理することにより、他のプログラムがそれらリソースを容易に利用できるようにする。オペレーティング・システムのあるものは、マルチタスキングであり、これは、それらが２以上のタスクの同時動作をサポートすることを意味する。マルチタスキングのオペレーティング・システムは、それらリソースを種々のプロセス間で分割し、各プロセスに対し、メモリ、処理リソースおよび少なくとも１つの実行スレッドへのアクセスを与える。
【０００３】
このクライアント−サーバ環境においては、サーバ・オペレーティング・システムはまた、クライアント・ベースのアプリケーションとの通信相互作用を取り扱うためにも呼び出す。クライアント・オペレーティング・システムは、サーバを見つけ、そしてそのサーバとの接続を要求し、そしてこのサーバは、リソースを割り当てることによってそのクライアントからの要求を取り扱う。
【０００４】
１つの周知のサーバ・オペレーティング・システムは、マイクロソフト社からのWindows（登録商標） NTサーバ・オペレーティング・システムである。このWindows（登録商標） NTサーバ・オペレーティング・システムは、マルチタスキングで、拡張可能であり、スケーラブルなオペレーティング・システムであり、これは、標準のパーソナル・コンピュータ上に実装することができる。このWindows（登録商標） NTサーバ・オペレーティング・システムは、十分に文書化されている。背景知識として、読者は、クラスタ（Helen Custer）著でマイクロソフト・プレスから出版された“Ｗｉｎｄｏｗｓ（登録商標） NTの内部（Inside Windows（登録商標） NT）”と題する書籍を参照されたい(copyright 1993)。
この書籍は、この言及により本文に含めるものとする。
【０００５】
多くのクライアント−サーバ・システムにおいては、クライアント・コンピュータは、それ自体、完全に機能する汎用コンピュータであって、それ自身のオペレーティング・システム、処理リソース、メモリ・リソース等を有している。このようなクライアントの例には、ワークステーション、デスクトップ・コンピュータ、ラップトップ等が含まれる。しかし、クライアント−サーバ・システムのあるものにおいては、このクライアント・コンピュータは、単純なマシンであって、汎用コンピュータよりも少ない機能が実装されている。例えば、クライアントは、端末として実現することもでき、これは、代表的には、サーバ・コンピュータへのアクセスをネットワークを介して可能にするのに十分な機能しか提供していない。この端末は、オペレーティング・システムを有しておらず、そのオペレーティング・システムとアプリケーションとは、サーバに常駐し、そして処理はサーバにおいて生ずる。
【０００６】
より最近になって、“ネットワーク・コンピュータ”あるいは“ＮＣ”として知られている低コストのコンピュータは、ネットワークへのアクセスを提供するための手段として導入されてきている。ネットワーク・コンピュータは、ディスプレイと、キーボードと、ネットワーク・ポートと、そして限られた処理能力とを有している。ネットワーク・コンピュータは、ある程度の限られたローカル処理を提供することができるが、ほとんどの処理に関してはサーバに主として頼っている。現在利用可能なネットワーク・コンピュータは、主として、Java（登録商標）（サン・マイクロシステムズ社が導入した言語）で書かれたアプリケーションを走らせるように構成されている。これらＮＣに近いものとしては、“Ｎｅｔ ＰＣ”として知られた別のタイプの低コストのコンピュータがあり、これは、ウィンドウズ（登録商標）（Windows（登録商標））ベースのアプリケーションとJava（登録商標）ベースのアプリケーションの双方を走らせることができる。
【０００７】
シトリックス・システムズ社（Citrix Systems Inc.）から“ウィンフレーム（WinFrame）”の名称で売られている技術は、Windows（登録商標） NTサーバ・オペレーティング・システムを拡張することによって、接続されたクライアントに対する多数のクライアント−サーバ・ウィンドウ処理セッション（clientserver windowing sessions）をサポートし、これにおいて、各セッションは、それら接続されたクライアントに対するウィンドウ処理環境を提供する。このWinFrame技術は、本質的には、USER，CONSOLEおよびGDIドライバのような低カーネル・レベル・サポート・ルーチンを複製して、その同じサーバ上で多数のウィンドウ処理セッションを提供する。各セッションは、ある１つの特定のクラッチのシステム・コンフィギュレーション（すなわち、ディスプレイ、マウス、キーボード）をサポートするように適合可能である。
【０００８】
このWinFrame技術では、１つのクライアントは、Windows（登録商標） NTサーバに接続しそしてウィンドウ処理セッションを開始することができる。このユーザに対しては、これは、このクライアントが、それ自身のWindows（登録商標）ブランドのオペレーティング・システムを走らせているスタンドアロンのWindowイネーブル式のコンピュータであるかのように見える。しかし、このセッションは、実際には、クライアントとかリモートのサーバ・コンピュータ上で生じており、そしてクライアントは、単にこのセッションに対するエントリを提供するローカルのグラフィカル・ユーザインターフェースを走らせているに過ぎない。この点で、WinFrame技術は、端末、ネットワーク中心のコンピュータのような低インテリジェントのクライアント・コンピュータにとっては特にうまく適しているが、それは、このクライアントが、それ自身のオペレーティング・システムを走らせることができることを必要としないからである。しかし、WinFrame技術は、十分にイネーブルされたクライアントに対しても同等にうまく適している。
【０００９】
シトリックスのWinFrame技術に関する１つの問題は、ユーザの視点からの使い易さが欠けていることである。各セッションは、ある１つの特定のクライアント・マシンに拘束され、したがって異なった物理的マシンからそのサーバに実際にログオンすることのあるユーザの要求を考慮していない。
【００１０】
この問題を例示するため、ある一般的なシナリオについて考える。あるユーザは、ユーザの職場にあるクライアント・コンピュータからWindows（登録商標） NTサーバにログオンするとする。この職場のクライアントは、デスクトップＰＣであって、1024 x 768の解像度の大きな２０″ＶＧＡディスプレイを有している。退社時刻に、このユーザは、一時的にそのセッションをホールトし、そしてサーバとの接続を断つ。その夜遅く、このユーザは、64０ ｘ ４８０の解像度の１１″カラー・ディスプレイをもつラップトップ・コンピュータである家庭のコンピュータからそのサーバへ再接続する。このラップトップがサーバに接続すると、シトリックスWinFrame技術は、この新たなクライアント・マシンに対し新たなセッションを作成する。このユーザは、異なったクライアントを用いているため、その古いセッションに再接続することが許されない。その結果、このユーザの職場のコンピュータで開始した以前のセッションは、そのラップトップ・コンピュータにポートされないが、それは、サーバが、それらを２つの区別できるマシンで開始した２つの区別できるセッションとして理解するからである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
したがって、この問題を克服しそしてこのユーザのニーズによりうまく対処できるようにサーバ・オペレーティング・システムを改良する必要がある。
【図面の簡単な説明】
【００１２】
【図１】図１は、クライアント−サーバ・コンピュータ・システムを示す図。
【図２】図２は、クライアント−サーバ・コンピュータ・システムにおけるサーバ・コンピュータのブロック図。
【図３】図３は、サーバ・オペレーティング・システムの１部分を示すブロック図であって、単一のクライアント−サーバ・ウィンドウ処理セッションを示している。
【図４】図４は、図３と同様のブロック図であるが、多数のクライアント−サーバ・ウィンドウ処理セッションをさらに示している。
【図５】図５は、図３と同様のブロック図であるが、ユーザがサーバに異なったクライアントからログオンする場合でも、そのユーザを以前のウィンドウ処理セッションと再関連させるダイナミック再関連プロセスをさらに示している。
【図６】図６は、図３と同様のブロック図であるが、ユーザがサーバに異なったクライアントからログオンする場合でも、そのユーザを以前のウィンドウ処理セッションと再関連させるダイナミック再関連プロセスをさらに示している。
【図７】図７は、この再関連プロセスにおけるステップを示すフロー図。
【図８】図８は、サーバ・オペレーティング・システムの部分のブロック図であって、このオペレーティング・システムが、サーバに対し同じクライアントからアクセスする多数のユーザに対し、どのように多数のセッションをサポートするかを示している。
【発明を実施するための形態】
【００１３】
（発明の摘要）
本発明は、多数のクライアント−サーバ・セッションをサポートしそしてユーザがあるセッションを開始し、そしてその後に、ユーザが２つの異なったクライアントを用いる場合でもそのセッションにダイナミックに再接続できるようにするサーバ・オペレーティング・システムに関係している。
【００１４】
１つの実現例によれば、オペレーティング・システムは、サーバ上における多数のクライアント−サーバ・セッションを可能にするマルチユーザ・セッション・マネージャを有する。さらに、このオペレーティング・システムは、１つ以上のプロトコル・スタックを管理するマルチユーザ・スタック・プロトコル・マネージャとを有し、各プロトコル・スタックは、クライアント−サーバ・セッションの間に、対応するクライアントとの通信を容易にする。
【００１５】
ユーザがサーバに対し第１のクライアントを介して接続したとき、スタック・プロトコル・マネージャは、この第１のクライアント−サーバ接続に対し第１のプロトコル・スタックを割り当てる。次に、該セッション・マネージャは、そのユーザに対する第１のセッションを作成する。記述する実現例においては、前記セッションは、リモート・クライアント上でウィンドウ処理グラフィカル・ユーザインターフェース環境をサポートするウィンドウ処理セッションである。このセッションは、１つのウィンドウ処理セッション環境をサポートする種々のソフトウェア・モジュールから成り、そしてキーボード・ドライバ、ディスプレイ・ドライバ、プロトコル・ドライバのような種々のハードウェア・ドライバを含む。第１のセッションにおいて用いるこれらドライバは、第１のクライアントのシステム・コンフィギュレーションに合うように選択する。
【００１６】
しばらくして後、このユーザが、第１のセッションを止め、そして第１のクライアントをサーバから切断する。サーバは、ユーザのこのセッションをサーバにおいて保持し、これにより、このユーザが後でこれに戻ることができるようにする。しかし、ユーザが第１コンピュータをサーバから切断する前にこのセッションを明らかに終了させた場合、このセッションを終わらせることができる。
【００１７】
後の時点で、ユーザがサーバに第２のクライアントを使って再接続する。この第２クライアントは、第１クライアントのものとは異なったシステム・コンフィギュレーションを有する。１例のシナリオとして、ユーザは、最初にユーザの職場のデスクトップ・コンピュータを介してそして後で、ユーザの家庭のラップトップ・コンピュータを介して、サーバにログオンすることがある。第２クライアントは、サーバに対し第２のクライアント−サーバ接続を介して接続し、そしてスタック・マネージャは、第２のプロトコル・スタックを第２のクライアント−サーバ接続に割り当てる。このセッション・マネージャは、次に、このユーザに対し新たな第２のセッションの作成を開始する。
【００１８】
しかし、このプロセスの間、セッション・マネージャは、このユーザが第１セッションに関係があることを認識する。セッション・マネージャは、第１セッションを、第２クライアントのシステム・コンフィギュレーションに合うように適合させる。すなわち、第１セッションは、１つ以上のコンフィギュレーション・パラメータから成る新たなセットで再構成することによって、第２クライアントの異なったシステム・コンフィギュレーションをサポートする。
【００１９】
次に、セッション・マネージャは、第２プロトコル・スタックをその再構成した第１セッションと再関連させ、これにより、たとえユーザが異なったクライアントからログオンしたときでも、ユーザがこのユーザの元のセッションに戻れるようにする。この適合は、サーバにおいてのみ生起し、したがってユーザには不可視である。この結果、ユーザは、単に同じセッションを見るに過ぎない。例えば、変更したディスプレイ・ドライバの場合には、ユーザは、同じセッションを、第２クライアントのディスプレイに対し再フォーマットしているものであるが、それを見ることになる。
【００２０】
本発明の別の面は、ダイナミック再関連を使用して、サーバに対し単一のクライアント・コンピュータから接続する多数のユーザを収容することに関係している。この状況の１例として、２人の銀行金銭出納係が同時に単一のコンピュータを使用することが一般的である。この場合、サーバは、異なったユーザがサーバに対し同じクライアントを介してログオンするとき検出する。この検出時に、サーバは、このクライアント−サーバ接続を取り扱うプロトコル・スタックを、現在のユーザと関係があるセッションに再関連させる。このようにして、サーバは、同じコンピュータを使用する多数のユーザをサポートすることができる。
【００２１】
（好ましい実施形態の詳細な説明）
図面においては、同じコンポーネントおよび特徴に対しては同じ参照番号を用いる。
【００２２】
図１は、クライアント−サーバ・コンピュータ・システム２０を示しており、これは、サーバ・コンピュータ２２を備え、これは、多数のクライアント２４（１）−２４（５）に対しネットワーク２６を介して接続している。クライアント−サーバ・コンピュータ・システム２０は、モデムを介するダイレクト・ダイアルアップ、企業ＬＡＮ（ローカル・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）およびインターネットを含む多くの異なったアーキテクチャを代表するものである。ネットワーク２６は、多くの方法で実現して、有線ベースに技術、無線技術の両方を含む、そのようなネットワーキング・コンテキストをサポートすることができる。本発明の種々の面は、１つの特定のネットワーク・アーキテクチャあるいはネットワーク技術に限定されるものではない。
【００２３】
サーバ２２は、好ましくはWindows（登録商標） NTサーバとして実現し、これは、ウィンドウ処理ユーザ・インターフェース環境をサポートする。サーバ２２は、説明の都合上このコンテキストで説明する。サーバ２２のより詳細な説明は、図２を参照して以下で行う。しかし、分かるように、サーバ２２は、Windows（登録商標） NT以外のオペレーティング・システムを使って実現することもできる。
【００２４】
クライアント２４（１）−２４（５）は、サーバ２２にネットワーク２６を介して接続することがある種々の種類のコンピュータを表している。クライアント２４（１）は、在来のデスクトップ・パーソナル・コンピュータ（ＰＣ）であり、これは、ローカルのオペレーティング・システムと、処理ユニットと、そしてストレージ・システムとを所有している。１つの例として、デスクトップ・クライアント２４（１）は、Windows（登録商標） 95またはWindows（登録商標） 98のような、マイクロソフト社からのWindows（登録商標）ブランドのオペレーティング・システムを実装した汎用ＰＣである。デスクトップ・クライアント２４（１）は、スタンドアロンのコンピュータであって、これは、主として、サーバとインターフェースすることにより、ローカルに格納されていないファイルまたは他の情報にアクセスする。
【００２５】
クライアント２４（２）は、ポータブルのラップトップ・コンピュータとして示しており、これは、ネットワーク２６に対し、在来のネットワーク・カードまたはダイアルアップ・モデム接続を介して接続することができる。このラップトップ・コンピュータ２４（２）もまた、完全な装備をもつスタンドアロンのコンピュータであって、それ自身のオペレーティング・システム、処理ユニットおよびストレージ・システムを有するように構成することができる。このラップトップ・コンピュータ２４（２）も同様に、Windows（登録商標） 95またはWindows（登録商標） 98のようなWindows（登録商標）ブランドのオペレーティング・システムを走らせるように構成することができる。
【００２６】
クライアント２４（３）は、ハンドヘルドのＰＣであり、これは、一般に汎用コンピュータよりも少ない機能しか備えていない。しかし、ハンドヘルドＰＣ２４（３）は、好ましくは、マイクロソフト社からのWindows（登録商標） CEのようなWindows（登録商標）ブランドのオペレーティング・システムを装備している。
【００２７】
クライアント２４（４）は、端末コンピュータであり、これは、最小のローカル処理でしかもローカル・メモリがほとんどない低コストのマシンである。この端末コンピュータは、ディスプレイと、キーボードと、マウス（オプション）と、そしてサーバに接続するのに十分なインテリジェンスとを備えている。全てのアプリケーションはサーバにおいて走り、そしてこの端末は、単に、サーバ・ベースの処理に対する接続ポイントを提供するだけである。
【００２８】
クライアント２４（５）は、ネットワーク・コンピュータ（Network Computer又はNC）またはNet PCのようなネットワーク中心のコンピュータ（networkcentric computer）を表している。このネットワーク中心コンピュータ・クライアント２４（５）は、主として、サーバ・ベースのアプリケーションの実行を容易にするが、Windows（登録商標）ベースのあるいはJava（登録商標）ベースのアプリケーションを走らせるため、ある程度の限られた処理能力しか有していない。
【００２９】
サーバ・コンピュータ
図２は、サーバ・コンピュータ２２の例示的実現例を示しており、これは、Windows（登録商標） NTオペレーティング・システムを装備して構成した汎用コンピュータとして実現している。サーバ２２は、処理ユニット（ＣＰＵ）３２、システム・メモリ３４、およびシステム・メモリ３４から処理ユニット３２までを含む種々のシステム・コンポーネントを結合するシステム・バス３６を含む。システム・バス３６は、種々のバス・アーキテクチャのいずれかとして実現することができ、これは、メモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含む、種々のバス・アーキテクチャの内の任意のものを使用する。
【００３０】
システム・メモリ３４は、リード・オンリ・メモリ（ＲＯＭ）３８、およびランダム・アクセス・メモリ（ＲＡＭ）４０を含む。基本入出力システム４２（ＢＩＯＳ）は、ＲＯＭ３８に格納してある。
【００３１】
サーバ２２は、ハード・ディスクまたはハード・ディスク・アレイの読み取りおよび書き込みを行うハード・ディスク・ドライブ４４、リムーバブル磁気ディスク４８の読み取りおよび書き込みを行う磁気ディスク・ドライブ４６、並びにＣＤ−ＲＯＭまたはその他の光媒体のようなリムーバブル光ディスク５２の読み取りおよび書き込みを行う光ディスク・ドライブ５０、の内の１つ以上を有する。ハード・ディスク・ドライブ４４、磁気ディスク・ドライブ４６、および光ディスク・ドライブ５０は、ハード・ディスク・ドライブ・インターフェース５４、磁気ディスク・ドライブ・インターフェース５６、および光ドライブ・インターフェース５８によって、それぞれシステム・バス３６に接続してある。これらのドライブおよびそれに関連するコンピュータ読み取り可能媒体は、コンピュータ読み取り可能の命令、データ構造、プログラム・モジュール、およびサーバ２２用のその他のデータの不揮発性記憶を行う。
【００３２】
ハード・ディスク、リムーバブル磁気ディスク４８およびリムーバブル光ディスク５２について記述したが、データを格納するのに他のタイプのコンピュータ読み取り可能媒体を使用することができる。このような他の媒体は、磁気カセット、フラッシュ・メモリ・カード、ディジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）等を含む。さらに、サーバ２２は、ＲＡＩＤ（独立ディスクの冗長アレイ）ストレージ・システムのような独立のストレージ・システム上に格納したデータを供給するように構成することもできる。
【００３３】
多数のプログラム・モジュールは、ハード・ディスク、磁気ディスク４８、光ディスク５２、ＲＯＭ３８またはＲＡＭ４０上に格納することができる。これらプログラムは、サーバ・オペレーティング・システム６０、１つ以上のアプリケーション・プログラム６２、その他のプログラム・モジュール６４、およびプログラム・データ６６を含む。
【００３４】
ユーザは、キーボード６８およびマウス７０のような入力デバイスによって、コマンドおよび情報をサーバ２２に入力することができる。他の入力デバイス（図示せず）として、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星パラボラアンテナ、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バス３６に結合したシリアル・ポート・インターフェース７２を介して、処理ユニット３２に接続しているが、代替的には、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ）のようなその他のインターフェースによって接続することもできる。
【００３５】
モニタ７４または別のタイプのディスプレイ・デバイスも、ビデオ・アダプタ７６のようなインターフェースを介して、システム・バス３６に接続する。サーバ・コンピュータ２２は、Ｔ１またはＴ３のインターネット接続のような、ネットワーク２６を介する通信を確立するため、ネットワーク・インターフェースまたはアダプタ７８，モデム７９または他の手段を有する。モデム７９は、クライアントからダイアルアップ接続を容易にする。
【００３６】
概略のソフトウェア・アーキテクチャ
コンピュータ・システム２０は、クライアント２４（１）−２４（５）がサーバ２２上でWindows（登録商標） ブランドのオペレーティング・システム並びにアプリケーションを走らせることができるようにするソフトウェア・アーキテクチャを実装している。このソフトウェア・アーキテクチャは、サーバ・ベースのマルチクライアント・コア、クライアント・ベースのモジュール、およびサーバとクライアントとの間の通信を可能にするリモート・プロトコルを備えている。
【００３７】
サーバ・ベースのマルチクライアント・コアは、サーバが、多数の同時のクライアント・セッションをホスト（host）することができるようにする。マルチクライアント・コアは、オペレーティング・システム６０の１部分として常駐し、そしてプロセッサ３２上で実行する。このマルチクライアント・コアは、ウィンドウ処理イネーブル式のクライアント（すなわち、デスクトップ・クライアント２４（１）、ラップトップ・クライアント２４（２）、ハンドヘルドＰＣクライアント２４（３）のような、ローカルのウィンドウ処理オペレーティング・システムを走らせることができるクライアント）、並びに非ウィンドウ処理クライアント（すなわち、端末クライアント２４（４）およびネットワーク中心クライアント２４（５）のような、ローカルのウィンドウ処理オペレーティング・システムを走らせることができないクライアント）との双方をサポートする。
【００３８】
このマルチクライアント・サーバ・コアは、それらクライアントの内の任意のものが、サーバにログインしウィンドウ処理セッションをサーバにて走らせることができるようにする。１実施形態においては、マルチクライアント・サーバ・コアは、シトリックスWinFrame技術を実装し、これは、Windows（登録商標） NTサーバ・オペレーティング・システムを拡張することにより、多数のクライアントに対し多数のウィンドウ処理環境をサポートする。WinFrame技術は、図３および図４を参照して以下に詳述する、クライアント−サーバ・ウィンドウ処理セッションを複製する手段を提供する。しかし、マルチクライアント・サーバ・コアは、その基本のWinFrame技術を超えるものであって、サーバにおけるウィンドウ処理セッションを維持し、かつユーザが異なったクライアントを使って再接続したときでもユーザをダイナミックにそれらのセッションに再接続する手段を提供する。
【００３９】
このクライアント・ベースのモジュールは、クライアントのメモリ内に常駐し、そしてクライアントの処理ユニット上で実行する。このクライアント・ベース・モジュールは、グラフィカルのウィンドウ処理ユーザ・インターフェース（ＵＩ）を走らせるコードを含んでいる。このコードは、端末、ネットワーク中心コンピュータ、Windows（登録商標）イネーブル式コンピュータ（Windows（登録商標）enabled computers）、UNIX（登録商標）ベースのコンピュータ、DOSベースのコンピュータを含む、広範なハードウェア上で走ることができる。ユーザに対しては、クライアントは、ウィンドウ処理オペレーティング・システムのローカル・バージョンを走らせているかのように見えるが、ただしこのオペレーティング・システムの機能は全てサーバにおいて発生している。
【００４０】
本ソフトウェア・アーキテクチャのプロトコル・コンポーネントは、クライアントが、ネットワークに接続するのを可能にし、そしてウィンドウ処理ＵＩをユーザに対し提示する。システム２０において使用できる１つの適当なプロトコルは、ＭＳリモート・デスクトップ・プロトコル（MS Remote Desktop Protocol）であり、これは、T.128/T.120プロトコル（国際標準マルチチャンネル会議プロトコル）の高度にスケーラブルな派生物である。T.128/T.120は、周知のプロトコルであり、したがって詳細な説明はしない。T.128/T.120に関する更なる情報については、読者は、国際電気通信連合（ＩＴＵ）からのT.128/T.120標準を参照されたい。尚、これは、言及により本文に含めるものとする。
【００４１】
従来技術のクライアント−サーバ・システムとは対照的に、コンピュータ・システム２０は、特定のクライアント・コンピュータをサポートするのではなく、ユーザのニーズをサービスするものとしてサーバ・ネットワークのビューを行うように適合させてある。この概念シフトは、コンピュータ・システム２０が、どのクライアント２４をユーザがサーバ２２をアクセスするのに用いていようともそのユーザをサポートすることを意味している。従来技術のクライアント−サーバ・システムは、代表的には、マシン中心の見方を強調したものであり、各々の接続を、特定のクライアント・コンフィギュレーションのニーズに関して扱う。
【００４２】
この二分法の１例として、背景部分で示したシナリオでは、職場のクライアント・コンピュータからサーバにログオンしたユーザが、セッションを開始し、そしてこのセッションをこれを終了させずに止め、そして後で家庭のコンピュータからログオンする場合を記述している。従来技術のアーキテクチャでは、サーバは、各クライアントに対し新たなセッションを作成するが、それは、これらが、異なったシステム・コンフィギュレーションをもつ２つの異なったクライアントから生じたものだからである。ユーザが第１のクライアントからログオンしたとき、サーバは、この特定のクライアント・コンピュータをサポートするのに特有のディスプレイ・ドライバ、キーボード・ドライバ等を利用するセッションを作成する。サーバはまた、このクライアント・コンピュータと通信するのに適した１つのタイプのプロトコルを使用することになる。
【００４３】
ユーザが第２のクライアントからログオンしたとき、サーバは、この第２のクライアント・コンピュータをサポートするのに特有の、異なったディスプレイ・ドライバ、キーボード・ドライバ等をロードする別のセッションを作成する。サーバはまた、異なったタイプの通信プロトコルを用いることもできる。こうして、サーバは、同じユーザがこのユーザがサーバに接続するマシンに無関係に同じセッションを続行したい場合でも、マシン依存性のセッションを作成する。この従来技術は、マシン中心のアーキテクチャを表している。
【００４４】
一方、コンピュータ・システム２０は、ユーザ中心のものである。上記のシナリオにおいて、コンピュータ・システム２０は、ユーザがサーバに対し１つのクライアントから接続し、セッションを開始そしてこれを終了せずに停止し、そして後でこの同じセッションに異なったクライアントから戻るのを可能にする。サーバは、この新たなクライアントに対し新たなセッションを作成することはせず、むしろ、元のセッションを、第２のクライアントをサポートするため適当なドライバ、プロトコルおよびコンフィギュレーション・パラメータと適合させる。
【００４５】
例えば、ユーザが最初に、1024 x 768の解像度の大きな２０″ＶＧＡディスプレイをもつ職場のコンピュータからログオンするとする。サーバは、1024 x 768の解像度の２０″ＶＧＡディスプレイをサービスする適当なディスプレイ・ドライバでウィンドウ処理セッションを確立する。ユーザがその後でユーザ自身の64０ ｘ ４８０の解像度の１１″ディスプレイをもつラップトップ・コンピュータからログオンするとき、サーバは、新たなセッションの確立を開始する。しかし、このセッション開始プロセスの間において、サーバは、このユーザが以前のセッションと関係があったことを認識する。このとき、サーバは、64０ ｘ ４８０の解像度の１１″ディスプレイに適した新たなディスプレイ・ドライバを用いるように以前のセッションを変更する。次に、サーバは、このユーザを、その以前のセッションに自動的に再関連させる。進行中の作業は、ダイナミックにその新たな１１″ディスプレイにリサイズし、そしてユーザは、このユーザが職場のコンピュータでの作業を止めた所から続行することができる。
【００４６】
サーバ・オペレーティング・システム６０は、ユーザが異なった動作特性をもつ異なったマシンからログオンする場合でも、ユーザをそれらのそれぞれのセッションに対し有利に再関連させることができるようにする。この再関連プロセスは、完全にサーバにて生じ、サーバは自動的にクライアントに適合する。このプロセスは、ユーザとクライアント・コンピュータからは見えない。
【００４７】
サーバ・オペレーティング・システムを実装する１つの好ましい方法は、図３ないし図６を参照して以下に説明する。この説明に続き、本発明の別の面について説明するが、これは、単一のクライアント・マシンからのサーバにおいて走っている多数のウィンドウ処理セッション間でのスイッチングを含んでいる。
【００４８】
サーバ・ベースのダイナミック再関連
本発明の１つの面は、ユーザを、彼らのそれぞれのウィンドウ処理セッションに再関連させ、そしてこれらウィンドウ処理セッションを自動的に調節することによって任意の新たなクライアント・システム・コンフィギュレーションに対処することに関している。このダイナミック再関連は、完全にサーバにおいて起きるものである。
【００４９】
図３は、サーバ・オペレーティング・システム６０の１部分を示しており、これは、多数のウィンドウ処理セッションを形成するためウィンドウ処理モジュールの複製を可能にするマルチクライアント・コアを含んでいる。オペレーティング・システム６０は、特権プロセッサ・モードで走るコード（これは“カーネル・モード”とも呼ぶ）と、非特権プロセッサ・モード（一般に“ユーザ・モード”と呼ぶ）で走るアプリケーションまたはその他のサービス・ルーチンとを含む。
【００５０】
オペレーティング・システム６０は、ユーザ・モードで実施するマルチユーザ・セッション・マネージャ９０を含んでいる。このマルチユーザ・セッション・マネージャ９０は、クライアントによる使用のためサーバ上に常駐する多数のクライアント−サーバ・ウィンドウ処理セッションの作成を可能にする。さらに、オペレーティング・システム６０は、カーネル・モードで実施しそしてセッション・マネージャ９０と緊密にインターフェースするプロトコル・スタック・マネージャ９２を含む。マルチユーザ・セッション・マネージャの指揮の下、プロトコル・スタック・マネージャ９２は、図３においてプロトコル・スタック９４により表すように、１つ以上のプロトコル・スタックを作成しそして管理することにより、クライアント−サーバ・ウィンドウ処理セッションの間において対応する外部クライアントとの通信を容易にする。これらプロトコル・スタックは、ある種のタイプの通信プロトコルにしたがって実現し、例えば、TCP/IPトランスポート上のRDP、IPX上のRDP、非同期シリアル接続（モデム）のトップ上のRDP等である。
【００５１】
セッション・マネージャ９０とプロトコル・スタック・マネージャ９２の１つの例示的な実現例は、シトリックス・システムズ社からのインテリジェント・コンソール・アーキテクチャ（ＩＣＡ：Intelligent Console Architecture）を使用することである。このシトリックスＩＣＡは、Windows（登録商標） NTサーバ・オペレーティング・システムを拡張して、接続したクライアントに対し多数のウィンドウ処理セッションを提供する。
【００５２】
説明の都合上、ここで、クライアント２４（１）がサーバ・ベースのウィンドウ処理セッションを走らせたいとする。クライアント２４（１）は、Windows（登録商標） イネーブル式のデスクトップ・コンピュータとして示している。しかし、他のタイプのクライアントも使用でき、これには、端末クライアント、ネットワーク中心クライアントが含まれる。クライアント２４（１）は、接続要求を周知の接続ポートに対し送る。サーバ・オペレーティング・システム６０は、オブジェクト９６で表すように、この接続要求を受け入れそして通信ポートを作成する。この通信ポート９６は、このクライアントに対し、サーバにメッセージまたはコールバック（callback）を送るハンドルを提供する。
【００５３】
マルチユーザ・セッション・マネージャ９０は、新たな転送スレッドを作成しそして起動して、この新たなクライアント要求にサービスする。サーバ・オペレーティング・システム６０、すなわちプロトコル・スタック・マネージャ９２は、プロトコル・スタック９４を通信ポート９６に割り当てる。このプロトコル・スタックは、次に、接続クエリ・モードに入り、ここで、キーボード・レイアウト／ロケール、希望のビデオ解像度等のようなクライアント能力とサーバ能力とを、その後に交換する。
【００５４】
プロトコル・スタック９４は、最初は、通信エンドポイントをもつコンテナである。活性化の間、このスタック・コンテナには、少なくとも２つのドライバ、すなわち、WinStationドライバ（ＷＤ）とトランスポート・ドライバ（ＴＤ）をロードする。トランスポート・ドライバは、より低いレベルのドライバであって、この接続を行うのに使用する通信トランスポートを介してデータの転送を容易にするものであり、これによりトランスポート独立性を提供する。さらに、プロトコル・ドライバ（ＰＤ）を、ＷＤとＴＤとの間にレイヤとして置くことにより、圧縮、信頼性のあるデータ・フロー、暗号化、フレーム化のような追加のフィーチャを提供することもできる。１例として、WinStation、プロトコルおよびトランスポートの各ドライバは、圧縮形TCP/IPトランスポートを介するRDPデータ・ストリームを取り扱うために実装することもできる。WinStationドライバは、サーバ上で作成されている最中のウィンドウ処理セッションに対するリモート・アクセスを提供する。このWinStationドライバは、カーネル・モード・ドライバ（ＳＹＳ）として実装し、これには、リモート・マウス、キーボード、キャラクタ・モード・ディスプレイ・コマンド、および１つの仮想チャンネル集合に対するアクセスを提供する。
【００５５】
このクライアントとの接続を確立しそしてウィンドウ処理セッションに対するクライアント要求を受け取った後、オペレーティング・システム６０は、１つのウィンドウ処理セッションを作成し、これは、図３ではセッション１として示している。シトリックスWinFrame技術においては、このウィンドウ処理セッションには、クライアント−サーバ・ルーチンCSRSS.EXEを走らせることが関係し、これは、一般にCSRSSモジュール９８と呼ぶ。このオペレーティング・システムのWindows（登録商標） NT3.xバージョンにおいては、CSRSSモジュール９８は、USER，CONSOLE，GDIおよび他のサポート・ルーチンに対しマイクロソフトが書いたコードの全てを含む。加えて、モジュール９８は、ハードウェア・ディスプレイに対するハードウェア・デバイス・ドライバ、このハードウェア・ディスプレイに対するＧＤＩインターフェース（ＧＤＩドライバ）、マウス・ドライバ、キーボード・ドライバの集合を含んでいる。
【００５６】
Windows（登録商標） NT4.0または5.0のようなWindows（登録商標） NTサーバ・オペレーティング・システムの新しいバージョンでは、CSRSSモジュール９８のUSERおよびGDIの部分は、カーネル・モードに、WIN32K.SYS １００と呼ぶモジュールに移す。CSRSSモジュール９８とWin32Kモジュール１００は、ユーザ−カーネル・ラインに渡って密に一体化させている。図３は、Windows（登録商標） NTのより新しいバージョンにおいて実装しているソフトウェア・モジュールを示している。
【００５７】
クライアントがウィンドウ処理セッションを要求すると、サーバ・オペレーティング・システムは、CSRSSモジュール９８とWIN32Kモジュール１００を作成して、それらハードウェア・デバイスを開き、そしてリモートのクライアントのシステム・コンフィギュレーションとコンパチブルの適切なＧＤＩディスプレイ・ドライバ１０２およびプロトコル・ドライバ１０４をロードする。本例では、クライアント２４（１）は、デスクトップ・コンピュータであって、1024 x 768の解像度をもつＶＧＡモニタを有しており、そしてRDPプロトコルを使用するものである。これらドライバをロードした後、プロトコル・スタック９４をウィンドウ処理セッション１にバインドする。このクライアントとの通信は、プロトコル・スタック９４からプロトコル・ドライバ１０４への矢印で示すように、ウィンドウ処理セッション１に渡す。
【００５８】
セッション・スタートアップの１部分として、リモート・クライアント２４（１）にいるユーザに対し、Windows（登録商標）ログオン（ＷＬ）モジュール１０６を介して、ユーザ識別（ＩＤ）を入力するようプロンプトする。オペレーティング・システムは、このユーザＩＤをウィンドウ処理セッション１と関連させる。このことは、ウィンドウ処理セッション１に対するユーザ・モード内の“ユーザ１”のラベルを付したボックスで表している。
【００５９】
次に、サーバ・オペレーティング・システムは、クライアント・コンピュータ２４（１）上でウィンドウ処理環境を提供する。このクライアント・ベースのコードは、ウィンドウ処理のグラフィカル・ユーザインターフェースを走らせ、これは、ユーザが、サーバ上でアプリケーションを開始させ、そしてWindows（登録商標）ベースのシステムに共通の他の機能を実行することができるようにする。
【００６０】
この最初のプロトコル・スタック９４がセッション１にバインドされた状態で、サーバ・オペレーティング・システム６０は、第２のプロトコル・スタックに対するコンテナを作成することにより、別のクライアントを収容する準備を行う。第２のクライアントがこのサーバに接続してあるウィンドウ処理セッションを走らせたとき、スタック・マネージャ９２は、そのプロトコル・スタックをこの新たなクライアントに割り当てる。
【００６１】
図４は、第２のクライアント２４（４）に対する通信ポート９６（２）に接続した第２のプロトコル・スタック９４（２）を示している。マルチユーザ・セッション・マネージャ９０は、セッション２のラベルを付した新たなクライアント−サーバ・ウィンドウ処理セッションを作成して、この第２クライアント２４（４）に対応する。第２セッション２は、第１セッション１の複製であり、そしてCSRSSモジュール９８（２）とWin32Kモジュール１００（２）のコピーを含む。
図３を参照して説明したように、第２ユーザ２は、ログオンし、そしてサーバ・オペレーティング・システムは、その適当なドライバをロードしてクライアント２４（１）をサービスする。この場合、クライアントは、端末コンピュータであって、より低い解像度800 x 600のディスプレイを有しまたTCP/IPトランスポートに対するRDPディスプレイ・プロトコルを用いている。ウィンドウ処理セッション２は、第２クライアント・マシン２４（４）をサービスするプロトコル・スタックにバインドする。
【００６２】
各セッションは、それ自身の関連するプロトコル・スタックに対するコンテナを保持する。この例では、セッション１は、関連するプロトコル・スタック９４（１）を有し、そしてセッション２は、関連するプロトコル・スタック９４（２）を有する。
【００６３】
より多くのクライアントがサーバに接続するにつれ、サーバ・オペレーティング・システム６０は、より多くのウィンドウ処理セッションを複製し続ける。多数のクライアント−サーバ・ウィンドウ処理セッションを発生するためそれらモジュールを複製する能力は、背景の箇所で述べたシトリックス・システムズ社からのWinFrame技術を使用して実現する。
【００６４】
残念ながら、このシトリックスWinFrame技術に関する問題は、ユーザの視点からの使い易さの欠如である。WinFrameを使用すると、各ウィンドウ処理セッションは、特定のクライアント・マシンおよびこのマシンのシステム・コンフィギュレーションにバインドされる。図４に示したシステムを仮定すると、在来のWinFrame技術は、第１ウィンドウ処理セッション１を、1024 x 768 モニタとRDPプロトコルを有するデスクトップ・コンピュータ２４（１）のシステム・コンフィギュレーションに結び付け、そして第２ウィンドウ処理セッション２を、800 x 600モニタとRDPプロトコルを有する端末コンピュータ２４（４）のシステム・コンフィギュレーションに結び付ける。
【００６５】
シトリックスWinFrame技術は、サーバに対し物理的に異なったマシンから実際にログオンすることのあるユーザのニーズに対応するものではない。したがって、ユーザが、１つのクライアント・コンピュータからのウィンドウ処理セッションを止め、そしてサーバに別のクライアント・コンピュータからログオンするとき、WinFrame技術は、それら２つのクライアント・コンピュータが共通のビデオ解像度を共有していない場合には、新たなウィンドウ処理セッションを作成することになる。ユーザは、その古いセッションに再接続することが許されない。
【００６６】
しかし、本発明のクライアント−サーバ・システムにおいては、サーバ・オペレーティング・システムは、ユーザのこのニーズに対応し、そしてユーザが異なったマシンから再接続できるウィンドウ処理セッションをサポートするように設計する。上記の例から、ユーザ１が1024 x 768 ＶＧＡ モニタとRDPプロトコルとをもつデスクトップ・コンピュータ２４（１）を使用してサーバに接続することを想い出してもらいたい。
【００６７】
この例で続けて、ユーザ１が、ウィンドウ処理セッション１を終了せずに、サーバ６０との接続を断つと仮定する。このユーザは、職場を離れそして家庭に帰る。家庭にいる間、このユーザは、その日の早くに開始したセッションを続けることにする。ユーザは、サーバに対し、家庭にある第２のクライアント・コンピュータから接続する。
【００６８】
図５は、ユーザ１が、図３を参照して上記したように、最初にサーバに対し第１のクライアント２４（１）を使って第１のクライアント−サーバ・ウィンドウ処理セッション１を作成し、そしてこの後、第１のクライアント２４（２）を使ってサーバに対し接続する、という状況を示している。第１のセッションの中断時に、RDPおよびTCP/IPのスタック・ドライバを先にロードしたコンテナは、空にし、そしてその関連の通信エンドポイントを壊す。これは、空のプロトコル・スタック９４（１）で表している。
【００６９】
このユーザが後で第２クライアント２４（２）を使ってログオンしたとき、マルチユーザ・セッション・マネージャ９０は、最初は、ログオンした者が新たなユーザであるかのようにして、第２のセッション２を作成する。この例では、クライアント２４（２）は、640 x 480解像度をもつフラットパネルの１１″カラー・ディスプレイを備えたラップトップ・コンピュータである。クライアント２４（２）は、RDPプロトコルを使用する。したがって、第２のクライアント２４（２）は、図３で使用した第１のクライアント２４（１）とは異なったシステム・コンフィギュレーションを有している。
【００７０】
この接続プロセスは、図３で説明したのと同じである。マルチユーザ・セッション・マネージャ９０は、新たな転送スレッドを作成し起動して、この新たなクライアント要求にサービスする。プロトコル・スタック・マネージャ９２は、第２のプロトコル・スタック９４（２）を、クライアント２４（２）が接続した通信ポート９６（２）に割り当てる。この第２プロトコル・スタック９４（２）は、ある通信エンドポイントをもつ空のコンテナから成っている。このスタック・マネージャは、デフォルトのドライバをこのプロトコル・スタック９４（２）にロードし、そしてクライアント通信を（点線の矢印で示すように）セッション２に渡す。これら初期化の間においては、オペレーティング・システムは、まだこのユーザが誰であるか気づいていない。
【００７１】
ユーザ１のユーザＩＤを、このログオン・プロセスの１部分として受けると、Windows（登録商標） ログオン（ＷＬ）モジュール１０６は、ユーザ１が、以前のセッション、すなわちセッション１に関係があることを認識する。しかし、ＷＬモジュール１０６は、完全に新たなセッションの作成を続行するのではなく、ユーザ１を、（実線の矢印で表したように）このユーザの以前のセッション１に再関連させる。
【００７２】
この再関連には、サーバ・オペレーティング・システムを、このユーザの新たなクライアント・コンピュータ２４（２）のシステム・コンフィギュレーション・パラメータに適合させることが含まれる。この再関連プロセスは、ユーザまたはクライアントには可視ではない。ユーザの視点からは、ユーザは、このユーザがこのセッションの前に止めたのと同じポイントに戻っている。
【００７３】
本発明のある面によれば、サーバ・オペレーティング・システム６０は、元のセッション１におけるWin32Kモジュール１００（１）を変更することにより、クライアント・コンピュータ２４（２）に適合する異なったドライバおよびデバイスを使用するようにする。この例では、Win32Kモジュール１００（１）は、640 x 480の低い解像度の小さな１１″ディスプレイに対応するように適合させる。
サーバ・オペレーティング・システム６０は、ＧＤＩディスプレイ・ドライバ１０２（１）を、1024 x 768 ＶＧＡモニタに対するドライバから640 x 480のフラットパネルのカラー・ディスプレイへ変化させる。クライアント２４（２）は、同じRDPプロトコルを用いるため、Win32Kモジュール１００（１）は、元のプロトコル・ドライバ１０４（１）を保つ。
【００７４】
加えて、本発明の別の面は、元のクライアント−サーバ接続において使用していたプロトコル・スタックの以前のスタック・コンテンツを、以前のセッション１に再関連させることである。好ましい実現例では、第２のスタックからのスタック・コンテンツ（WinStationドライバ（ＷＤ）、プロトコル・ドライバ（ＰＤ）、およびトランスポート・ドライバ（ＴＤ））と、ライブの接続エンドポイントとは、以前のセッション１に対する第１のプロトコル・スタック９４（１）に移し戻す。
【００７５】
図６は、この新たなクライアント・コンピュータをサポートするためWin32Kモジュール１００（１）を変更した結果を示している。ディスプレイ・ドライバ１０２（１）は、このときには、640 x 480フラットパネルのカラー・ディスプレイに対するドライバとなっている。加えて、スタック・コンテンツは、セッション１のプロトコル・スタック９４（１）内にロードし戻す。この結果、サーバは、ユーザがこのときアクセス・ポイントとして用いているクライアント・コンピュータに対し、ダイナミックに適応する。セッション２とその関連のプロトコル・スタック９４（２）は、一旦この再関連が完了したときには、壊すことになる。
【００７６】
本例では、ディスプレイ・データは、ユーザの新たなクライアント・コンピュータ２４（１）に適合するようにダイナミックにリサイズする。このセッションは、ユーザにとっては同じものに見え、ユーザのより小さく解像度の低いスクリーンに対しフォーマットし直しているだけである。以前のWinFrame技術は、この再関連プロセスを可能にするものではなく、したがって元のセッションを、新たなクライアント・コンピュータ２４（１）に供給することができなかった。
【００７７】
上記の例は、サーバ・セッションを、異なったディスプレイ・サイズおよび解像度に合うように適合させることを強調したものである。これは、単なる１例に過ぎない。サーバにおいて考慮することのできる他の可能なクライアント・コンフィギュレーション・パラメータには、キーボードのタイプ、キーボード・レイアウト（QWRTYとDvorak）、プロトコル・タイプ（例えば、TCP/IP に対するRDPと非同期モデムに対するRDP）、言語（例えば、英語とスペイン語）、メモリ・ドライブおよび周辺装置がある。
【００７８】
図７は、このダイナミック再関連プロセスにおけるステップを示している。これらステップは、サーバ・オペレーティング・システム内のコードとして実現しており、好ましくは、ユーザ認証ソフトウェアをWindows（登録商標） ログオン・モジュール内に備えて有するマルチユーザ・セッション・マネージャの１部分として実現する。ステップ１２０において、ユーザは、サーバにあるクライアントを介して接続する。サーバは、この接続プロセスを開始してクライアント−サーバ接続を形成し（ステップ１２２）、そして新たなクライアント−サーバ・ウィンドウ処理セッションの作成を開始する（ステップ１２４）。
【００７９】
この初期化プロセスの間、サーバ・オペレーティング・システムは、このユーザが、まだ終了していない以前の任意の活性のセッションに関係があるがどうか解析する（ステップ１２６）。もしない場合（すなわち、ステップ１２６からの“Ｎｏ”分岐）、サーバ・オペレーティング・システムは、このユーザに対する新たなセッションの作成を完成させる（ステップ１２８）。
【００８０】
一方、このユーザが以前の活性のセッションに関係がある場合（すなわち、ステップ１２６からの“Ｙｅｓ”分岐）、サーバ・オペレーティング・システムは、このユーザを、その以前の活性のセッションに再関連させる（ステップ１３０）。これには、この現在接続したユーザのプロトコル・スタックおよび接続エンドポイントを元のセッションに再関連（すなわち、転送）させること（ステップ１３２）、並びに以前の活性のセッションを適合させることによって現在のクライアントに適した任意のシステム・コンフィギュレーション変化に対応すること（ステップ１３４）とが含まれる。
【００８１】
キオスク環境
本発明の別の面は、ダイナミック再関連を使用して、サーバに対し単一のクライアント・コンピュータから接続する多数のユーザに対処することに関係する。この状況の１つの例として、２人以上の銀行金銭出納係が同じコンピュータを利用すること、あるいは２人以上の販売員が１つのコンピュータ・レジスタを用いることが一般的である。多数のユーザが同一のコンピュータに頼るこの環境は、一般に、“キオスク”環境と呼んでいる。
【００８２】
図８は、クライアント２４（４）をサーバ・オペレーティング・システム６０にプロトコル・スタック９４を介して接続したものを示している。多数のユーザ１−Ｎは、同じクライアント２４（４）を使用している。マルチユーザ・セッション・マネージャ９０は、ユーザ１−Ｎの各々に対しクライアント−サーバ・ウィンドウ処理セッションを作成する。各ウィンドウ処理セッションは、１つのCSRSSモジュールと１つのWindows（登録商標）ログオン・モジュール（ユーザ・モードにおける“ユーザ”ブロックとして表す）と、そしてカーネル・モードにおいてWin32Kモジュールを含んでいる。各セッションはまた、関連したプロトコル・スタック９４を有している。
【００８３】
第１のユーザがサーバにログオンすると、セッション・マネージャ９０は、この第１ユーザ１に対し第１のセッション１を作成する。Win32Kモジュールは、その適当なドライバおよびデバイスを提供して、端末２４（４）上に１つのウィンドウ処理セッションを実現する。内部的には、オペレーティング・システムは、実線の矢印１４０で表すように、プロトコル・スタック９４（１）をセッション１に関連させる。
【００８４】
ユーザ１が１つのタスクを完了すると、このユーザは、そのセッションを、ログオフしたりあるいは他の場合にはこのセッションを終了させたりせずに、フリーズさせる。このとき、別のユーザが、この端末２４（４）を自由に使用できる。ここで、ユーザ２がサーバにログオンすると仮定する。この第２のユーザ２に対して、セッション・マネージャ９０は、第２のセッション２を作成する。セッション２におけるWin32Kモジュールはまた、その適当なドライバおよびデバイスを提供することにより、端末２４（４）上で１つのウィンドウ処理セッションを実現する。オペレーティング・システムは、点線の矢印１４２で表すように、この第２のプロトコル・スタック９４（２）をセッション２に関連させる。このプロセスは、Ｎ人のユーザに対し続けることができる。
【００８５】
このとき、端末が再び自由に使用できるようになったとき、ユーザ１がセッション１に戻りたいことがある。このユーザは、このユーザ自身のＩＤを再びタイプする。オペレーティング・システムは、最初は、新たなセッションおよび関連のプロトコル・スタックの作成を開始する。しかし、オペレーティング・システムが、このユーザが前に存在した中断されたセッションを有すると認識すると、このユーザをその既存のセッション１に再関連させる。スタック・コンテンツとライブの通信エンドポイントとは、セッション１との関連のため、プロトコル・スタック・コンテナ９４（１）に転送し戻す。このようにして、サーバ・オペレーティング・システムは、同じクライアント・コンピュータからの多数のユーザのセッションを収容する。
【００８６】
以上、本発明について、構造上の特徴および方法上のステップに特有の用語で説明したが、添付の特許請求の範囲に記載の本発明は、必ずしも記述したこの特定の特徴またはステップに限定されるものではない、と理解されたい。これら特定の特徴およびステップは、保護を請求する発明を実施する好ましい形態として開示したに過ぎないものである。
【特許請求の範囲】
【請求項１】
サーバにおけるコンピュータ読み取り可能媒体上に具体化したサーバ・オペレーティング・システムであって、該システムが、前記サーバが複数のクライアントのそれぞれに対し１つのウィンドウ処理環境を提供するようになった多数のクライアント−サーバ・セッションを可能にし、前記サーバ・オペレーティング・システムが、
前記サーバにリモート・クライアントを介して接続している第１のユーザが、該第１ユーザが先に開始した先のウィンドウ処理セッションと関連している場合、これを認識するため、サーバを指揮する第１のコンピュータ読み取り可能命令と、
前記第１ユーザを前記先のウィンドウ処理セッションに再関連させるため、前記サーバを指揮する第２のコンピュータ読み取り可能命令と、
を含み、
前記第１コンピュータ読み取り可能命令は、さらに、前記サーバに同じ前記リモート・クライアントを介して接続している第２のユーザが、該第２ユーザが先に開始した先のウィンドウ処理セッションと関連している場合、これを認識するため、サーバを指揮し、
前記第２コンピュータ読み取り可能命令は、さらに、前記第２ユーザを前記先のウィンドウ処理セッションに再関連させるため、前記サーバを指揮すること、
を特徴とするサーバ・オペレーティング・システム。
【請求項２】
サーバ・コンピュータにおいて、
コンピュータ読み取り可能媒体上に具体化されかつサーバにおいて実行されるオペレーティング・システムであって、多数のクライアントに対し多数のグラフィカル・ユーザインターフェース・ウィンドウ処理セッションを可能にする、前記オペレーティング・システムを含み、
前記オペレーティング・システムは前記ウィンドウ処理セッションに対しグラフィカル・ユーザインターフェース（ＵＩ）を走らせるクライアントと通信するように構成されていること、及び
前記オペレーティング・システムは、多数のユーザが、前記クライアントを用いてこれらユーザ自身の対応するウィンドウ処理セッションを操作できるように、
前記ウィンドウ処理セッションの種々のものと前記クライアントへの又はからの通信と関連させるように構成されていること、
を特徴とするサーバ・コンピュータ。
【請求項３】
請求項２記載のサーバ・コンピュータにおいて、前記クライアントは、前記サーバに接続することができるオペレーティング・システムを備えて実現したクライアント上で走るように構成したこと、を特徴とするサーバ・コンピュータ。
【請求項１】
サーバにおけるコンピュータ読み取り可能媒体上に具体化したサーバ・オペレーティング・システムであって、該システムが、前記サーバが複数のクライアントのそれぞれに対し１つのウィンドウ処理環境を提供するようになった多数のクライアント−サーバ・セッションを可能にし、前記サーバ・オペレーティング・システムが、
前記サーバにリモート・クライアントを介して接続している第１のユーザが、該第１ユーザが先に開始した先のウィンドウ処理セッションと関連している場合、これを認識するため、サーバを指揮する第１のコンピュータ読み取り可能命令と、
前記第１ユーザを前記先のウィンドウ処理セッションに再関連させるため、前記サーバを指揮する第２のコンピュータ読み取り可能命令と、
を含み、
前記第１コンピュータ読み取り可能命令は、さらに、前記サーバに同じ前記リモート・クライアントを介して接続している第２のユーザが、該第２ユーザが先に開始した先のウィンドウ処理セッションと関連している場合、これを認識するため、サーバを指揮し、
前記第２コンピュータ読み取り可能命令は、さらに、前記第２ユーザを前記先のウィンドウ処理セッションに再関連させるため、前記サーバを指揮すること、
を特徴とするサーバ・オペレーティング・システム。
【請求項２】
サーバ・コンピュータにおいて、
コンピュータ読み取り可能媒体上に具体化されかつサーバにおいて実行されるオペレーティング・システムであって、多数のクライアントに対し多数のグラフィカル・ユーザインターフェース・ウィンドウ処理セッションを可能にする、前記オペレーティング・システムを含み、
前記オペレーティング・システムは前記ウィンドウ処理セッションに対しグラフィカル・ユーザインターフェース（ＵＩ）を走らせるクライアントと通信するように構成されていること、及び
前記オペレーティング・システムは、多数のユーザが、前記クライアントを用いてこれらユーザ自身の対応するウィンドウ処理セッションを操作できるように、
前記ウィンドウ処理セッションの種々のものと前記クライアントへの又はからの通信と関連させるように構成されていること、
を特徴とするサーバ・コンピュータ。
【請求項３】
請求項２記載のサーバ・コンピュータにおいて、前記クライアントは、前記サーバに接続することができるオペレーティング・システムを備えて実現したクライアント上で走るように構成したこと、を特徴とするサーバ・コンピュータ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１１８９９４（Ｐ２０１２−１１８９９４Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１１−２７７１３９（Ｐ２０１１−２７７１３９）
【出願日】平成２３年１２月１９日（２０１１．１２．１９）
【分割の表示】特願２０１０−２４２５４５（Ｐ２０１０−２４２５４５）の分割
【原出願日】平成１０年１１月２日（１９９８．１１．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２３年１２月１９日（２０１１．１２．１９）
【分割の表示】特願２０１０−２４２５４５（Ｐ２０１０−２４２５４５）の分割
【原出願日】平成１０年１１月２日（１９９８．１１．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]