JPH11511874A

JPH11511874A - リモート・サーバの単純で安全な管理を提供するための装置および方法

Info

Publication number: JPH11511874A
Application number: JP8519188A
Authority: JP
Inventors: ニコレット，ジム
Original assignee: ノベル，インコーポレイテッド
Priority date: 1994-12-13
Filing date: 1995-12-12
Publication date: 1999-10-12
Anticipated expiration: 2015-12-12
Also published as: DE69508431T2; WO1996018948A1; DE69508431D1; CA2207849C; AU4597196A; CA2207849A1; EP0797801B1; JP3071469B2; EP0797801A1; US5671414A

Abstract

(57)【要約】安全なリモート・プロシージャ・コールのセットは、ネットワークにおいて、ローカルおよびリモート・マシンのネイティブ通信プロトコルのターム(term)を使用して実装される。リモート・プロシージャ・コールは、クライアント・コンピュータから作業をするシステム管理者が、直接インタラクトすること、および、ネットワーク・オペレーティング・システムを管理することができるようにさせる。１つもしくは複数のリモート・プロシージャ・コールは、ネットワーク・クライアント・コンピュータ・オペレーティング・システム内に組み込まれ、対応するリモート・プロシージャ・コールはサーバ・コンピュータ・オペレーティング・システム内に組込まれる。その結果として、開発者は、ネットワーク・クライアント・コンピュータを使用して、その呼び出しをサポートするサーバ・コンピュータ・オペレーティング・システムに指示を出して、リモート・サーバ・アプリケーションをロード、アンロードもしくは構成することができるクライアント・ソフトウェアを開発することができる。

Description

【発明の詳細な説明】リモート・サーバの単純で安全な管理を提供するための装置および方法関連出願のクロス・リファレンス本出願は、１９９４年１２月１３日に出願された「リモート・サーバの単純で安全な管理を提供するための装置および方法」という発明の名称の米国特許出願第０８／３５５，３６９号の継続出願である。背景技術と技術上の問題本願発明は、一般に、ファイル・サーバの構成(configuration)設定をリモート・コンピュータから制御するための方法および装置に関し、特に、ファイル・サーバをクライアント・サーバ・ネットワーク・オペレーティング環境内のクライアント・コンピュータから再構成するための方法に関する。マイクロエレクトロニクスおよびディジタル・コンピューティング・システムの技術的進展によって、ネットワーキング・サービスの、ネットワーク内にパーティション(partition)されているコンピュータの広い範囲に及ぶ分配(distribu tion)、および、さまざまな通信メディアを通じた分配が可能になっている。アプリケーションを分配することにおける進展は、また、アプリケーションのクライアント・サーバ・アーキテクチャにも帰着する。典型的なクライアント・サーバ・アーキテクチャにおいては、ユーザとインタラクトするアプリケーションの部分は、クライアント・プロセス・リクエストを遂行するアプリケーションの部分とは分離されているのが典型的である。典型的には、ユーザとインタラクトするアプリケーションの部分は、クライアント(client)またはクライアント・ソフトウェアと呼ばれ、その一方で、クライアント・ソフトウェアによってなされたリクエストにサービスするアプリケーションの部分は「サーバ(server)」もしくはサーバ・ソフトウェアと呼ばれる。しかし、サーバは他のサーバのクライアントとして動作することもある。ネットワーク環境においては、クライアントおよびサーバは一般に、異なるコンピュータ上で実行される。ファイル・サーバとして頻繁に参照されるようなホスト・コンピュータ上で動作しているサーバ・ソフトウェアの管理は、様々な問題を発生させる。歴史的には、サーバ・ソフトウェアをアンロードしたり、再構成したりする必要がある場合は、（または、リロードする必要がある場合には、システム管理者等ネットワーク・アプリケーションを管理する貴任を負う人間）またはクライアント・ソフトウェアのユーザが物理的にサーバ・コンピュータの所へ行って、サーバ・コンピュータの入力および表示装置（たとえば、キーボードおよびモニタ）を使用してリロードしなければならなかった。クライアント・ソフトウェアが、まだロードされていない、あるいは、適切に構成されていないサーバにアクセスする必要がある場合は、システム管理者またはクライアント・ソフトウェアのユーザが物理的にサーバ・コンピュータの所へ行って、所望のソフトウェアをロードしなければならなかった。クライアントがサーバ・コンピュータに問い合わせ(interro gate)してどのサーバ・ソフトウェアが利用できるかを決める場合、または、サーバ・コンピュータに問い合わせしてサーバ・コンピュータによりサポートされているデバイスを決める場合には、システム管理者またはユーザが物理的にサーバの所へ行って、サーバ上で動作しているプロセスを検査(inspect)したり、または、リモート・コンピュータに付加されているデバイスを物理的に検査しなければならなかった。以前は、リモート・コンピュータの管理は、典型的には、１つまたは２つのスキームに基づいていた。第１のスキームは、リモート・コンソールまたはログ・イン・スキームとして知られているもので、たとえばディジタル・パケットの作成、分配(distribution)および配信(delivery)を提供するプロトコルなどの単純なネットワーク・プロトコルを使用するクライアント・ソフトウェアを使用(emp loy)する。クライアント・ソフトウェアは、オープン・システムズ・インターコネクト(Open Systems Interconnect)、つまり「ＯＳＩ」モデルの「ネットワーク」レベルで動作する。対応するサーバ・ソフトウェアは、直接クライアント・ソフトウェアとインタラクトする。このスキームによれば、クライアント・ソフトウェアはローカル・コンピュータ（たとえばクライアント）からの入力を受け付けて、その入力をリモート・サーバ・ソフトウェアに送信し、今度はこれがそのキーストロークをを直接サーバ・コンピュータ・オペレーティング・システムに渡す。このスキームの特徴によれば、ローカル・コンピュータ上で入力されたキーストロークがネットワークを介してリモート・サーバ・ソフトウェアを通って、直接リモート・オペレーティング・システムに渡されるので、使用されているセキュリティは、リモート・セキュリティ・アプリケーションへのアクセス用のものだけである。第２のよく使用されるスキームは、シンプル・ネットワーク・マネージメント・プロトコル(Simple Network Management Protocol)（「ＳＮＭＰ」）およびシンプル・マネージメント・プロトコル(Simple Management Protocol)（「ＳＭＰ」）を使用する。これらはいずれも関連し、同じ歴史的起源を有する。このスキームは、異種(heterogeneous)の環境における使用のために、２つのプロトコルを基本的に定義する。このスキームの主要な焦点は、どのようにしてリモート・コンピュータを管理するかではなく、どのようにして管理目的のための異種システムの通信およびインタラクション(interaction)を処理すべきか、に集中している。今日では、このスキームの仕様書は、４００ページを超えるドキュメントから構成されている。この第２のスキームは、大きな異種ネットワークにおいては便利であるが、このスキームは、特定のリモート・ネットワーク・サーバを既存のネットワーク・プロトコルを介してネイティブ・セッション・レベル、すなわち、ＯＳＩモデルの「セッション(Session)」レベルにおいて管理する機能のクライアント・サーバ開発のためのエレガントな機構を提供することはできない。一般に、全リモート・コンピュータは、ネットワーク内で他のクライアント・コンピュータと、ネットワーク通信を実装するネットワーク・オペレーティング・システムという手段によって、ＯＳＩモデルの「トランスポート(transport) レベル（「ネイティブ通信プロトコル(native communications protocol)」）、たとえば、トランスミッション・コントロール・プロシージャ (Transmission Control Procedure)（「ＴＣＰ」）、サーバ・メッセージ・ブロック(Server Message Block)（「ＳＭＢ」）、あるいは、ネットウェア・コア・プロトコル(NetWare Core Protocol)(「ＮＣＰ」）などにおいて動作するネイティブ接続ベースのプロトコルを使用して通信する。ネットワーク・オペレーティング・システムの開発者は、ローカル・コンピュータ(「ネットワーク・クライアント」）上でネイティブ通信プロトコルを実装するクライアントを提供し、および、リモート・コンピュータ上でネイティブ通信プロトコルを実装するオペレーティング・システムを提供する。このようなネットワーク・オペレーティング・システム用のクライアント・サーバ・ソフトウェアを書く開発者は、現在は、リモート・コンソール・システムを使用してリモート・コンピュータとインタラクトする方法を知るためにクライアント・ソフトウェアのユーザによることができるか、または、異種ネットワーク管理プロトコルを使用してアソシエート(ass ociate)・クライアント・サーバ・アプリケーションを開発して、ローカル・コンピュータだけではなく、さまざまなリモート・異種コンピュータをも管理することができるかのいずれかである。いずれも満足のいくものではない。リモート・コンソール・アプローチは、ユーザが大変多くのことを知る必要があり、強い(robust)セキュリティを欠いている。異種プロトコルは開発者がしなければならないことが多すぎる。開発者は、プロトコルを実装し、クライアントおよびサーバ・アプリケーションを書き、１つまたは複数のリモート・オペレーティング・システムのシステム・インターナル(internal)にアクセスして必要な機能を実装しなければならない。このように、ネットワーク管理者は、ネットワーク化されたコンピュータのリモート管理を実装する単純な手段、特に、クライアント・サーバ・コンピューティング環境におけるネットワーク・サーバのリモート管理用の手段を必要としていた。発明の要約本願発明の一側面によれば、ネットワーク・オペレーティング・システムは、クライアント・コンピュータ内に常駐(resident)するクライアント・ソフトウェア・モジュール、および、サーバ・コンピュータ上に常駐するサーバ・ソフトウェア・モジュールを備え、これらが一緒になると、ユーザは動的にサーバ・コンピュータをリモートのクライアント・コンピュータ端末から再構成できるが、これによって、ユーザは物理的にサーバ・コンピュータの所へ行ってサーバ制御および再構成機能を実行する必要がなくなる。本願発明の好適実施の形態によれば、安全なリモート・プロシージャ・コールのセットが、ネットワーク内に、ローカル（例えばクライアント）およびリモート（例えばサーバ）のコンピュータのネイティブ通信プロトコルのタームを使用して実装される。リモート・プロシージャ・コールは、クライアント・ソフトウェアが直接リモート・コンピュータのオペレーティング・システムとインタラクトできるようにさせるため、現在利用できるスキーム固有(inherent)の問題を避けることができる。１つまたは複数のリモート・プロシージャ・コールは、ネットワーク・クライアント内へ組込まれ、対応するリモート・プロシージャ・コールはサーバ・オペレーティング・システム内へ組込まれる。したがって、自分のリモート・サーバ・アプリケーションをロード、アンロード、または構成することができるクライアント・ソフトウェアを開発したいと思う開発者は、ネットワーク・クライアントおよびこの呼び出しをサポートするサーバ・オペレーティング・システムを使用することによって、これを行うことができる。図面の簡単な説明本願発明については、以降に、付加された図面と組み合わせて説明するが、同じ番号は同じ要素を意味している。図１は、１つのサーバ・コンピュータおよび複数のクライアント・コンピュータを示す本発明の例示的なネットワークの概略ブロック図である。図２は、本発明により構成されトランスミット(transmit)される例示的なメッセージ・パケットの概略図である。図３は、本発明の一側面による例示的な方法の処理を示すフロー図である。好適な例示的実施の形態の詳細な説明では、図１を参照すると、例示的ネットワーク１０は、好ましくは、複数のコンピュータを備え、そのそれぞれは、それに関連づけられたユニークな「ネットワーク・アドレス」を有し、これによってネットワーク上のさまざまなハードウェア・ノード（たとえばコンピュータ）の間の通信が容易になる。典型的なネットワークは、ＰＣ、プリンタ、サーバ、ＣＤＲＯＭドライバ、および、さまざまな他の適切なハードウェア・ノードを含むことができるが、ここでは簡単のため、クライアントおよびサーバ・コンピュータのみが図１に示されている。ネットワーク１０は、好ましくは、１つまたは複数のクライアント・コンピュータ２０および１つまたは複数のサーバ・コンピュータ４０を備え、これらは好ましくは、ネットワーク通信バス５４によって適切なネットワーク構成内において相互接続(interconnect)されている。好適な例示的実施の形態によれば、少なくとも１つのクライアント・コンピュータ２０は、キーボード２４およびモニタ（例えばスクリーン）２２を備え、ユーザがクライアント・コンピュータとインタラクトできるようにしている。クライアント・コンピュータ２０は、さらに、ディスク・ドライブ２６、クライアント・コンピュータ・プロセッサ２８、ＲＡＭ３０、およびＲＯＭ３２、例えば従来のハード・ドライブなど、を備えている。あるクライアント・コンピュータ２０へのユーザ・アクセスは、好ましくは、様々な既知のセキュリティ・スキームによって制御することができ、このスキームは、あるセキュリティのレベルを有しこれに関連づけられたユーザ・パスワードの使用を含み、このユーザ・パスワードによってユーザは、ハード・ドライブ３２にストアされたさまざまなファイルにアクセスしたり、また、さまざまな他のクライアント・ステーションのユーザがサーバ４０とインタラクトするのと同じ方法で、サーバ・コンピュータ４０とインターフェースをしたりできるようになる。対照的に、サーバ・コンピュータ４０へのアクセスは、好ましくは、スーパーユーザ・パスワードの使用を通じて制御され、スーパーユーザ・パスワードは典型的には、各ユーザ・パスワードに関連づけられたセキュリティ・レベルよりも高いレベルに関連づけられている。さらに続けて図１を参照すると、サーバ・コンピュータ４０は、好ましくは、キーボード４２、モニタ４４、サーバ・ディスク・ドライブ５２、サーバ・プロセッサ４６、ＲＡＭ４８、および、１つまたは複数のハード・ドライブ５０を備えている。図に示した通り、本発明の好適実施の形態は、好ましくは、複数のリモート・プロシージャ・コールの観点から実装され、そのそれぞれは、サーバ・コンピュータにおける制御機能を実装するために設計されている。異なるリモート・プロシージャ・コールは、異なるタスクを実行するために実装できる。このように、システム管理者は、簡単に、特定のタスクをリモート・ロケーションから実行することができる。本発明の１実施の形態において、リモート・プロシージャ・コールは、リモート・プロセスのロード、リモート・プロセスのアンロード、リモート・ボリュームのマウント、リモート・ボリュームのアンマウント、名前空間(name space)のボリュームへの追加、リモート・オペレーティング・システムへのセット・プロシージャの発行(issue)、および、リモート・バッチ・ファイルの実行のために、実装されている。ネットワーク・クライアントにおいて、コードであって、リモート・プロシージャ・コールの構造をサーバにおいて、および、基礎となるネットワーク通信プロトコルによって必要とされる形態(form)において、確認するためのパケットを作成するコードが、実装されている。たとえば、ＮＣＰプロトコルをサポートするクライアント・サーバ環境において、クライアントおよびサーバ・リモート・プロシージャ・コールは一般的なＮＣＰパケット構造に好都合に従う。ＮＣＰプロトコルの各ビア(veer)は、好ましくは、固定パケット・ヘッダ(fix ed packet header)および可変データ・ブロックを備える。各バーブ(verb)は３つのフィールドを有し、これは名前および番号によってわかる。たとえば「RPC Load an NLM」（これは、「ネットウェア・ローダブル・モジュールをロードするためのリモート・プロシージャ・コール」を意味する）などの名前自体は、バーブが実行するタスクを記述するためにだけ役に立つ。RPC Load an NM 用に３つのフィールドに関連づけられた番号は、好ましくは、0x2222、１３１、および、０１である。バーブ番号（例えば全３フィールド）は、そのバーブに対するユニークな識別子として働く。番号の最初のフィールドは、サービス・カテゴリーを識別する。例えば、サービス指向のＮＣＰ(service oriented NCP)は、典型的には、0x2222を使用する。固定パケット・ヘッダは、リクエストのタイプと、クライアントおよびサーバがリクエストについての通信を継続するために必要な他のパラメータ、例えば、トランザクション・シーケンス番号、サービス接続番号、およびタスク番号等、を含む。ＮＣＰプロトコル環境基礎となるネットワーク通信プロトコルの理解は、本発明の実装に役立つためと、ここで論ずる本発明のさまざまな実施の形態は、本発明を、ＮＣＰ環境内におけるリモート・プロシージャ・コールのセットとして実装することを与えられているので、典型的な本発明に対するクライアント・サーバ・リクエスト・セッションについて説明する。しかし、本発明は他のオペレーティング環境においても実装可能であることが理解されるだろう。このセッションは、クライアント・ソフトウェアが最初にリモート・サーバ・オペレーティング・システムへリモート・プロセスをロードするようリクエストしたときから、イベントのシーケンスを追跡する。リクエストをする前に、クライアントはリモート・コンピュータに接続されて認証(authenticate)されなければならないし、リクエストをするユーザは適切なセキュリティのレベルを有していなければならない。本発明の１実施の形態の基本ステップ、すなわち、ネットウェア・コア・プロトコル(NetWare Core Protocol)環境内のいわゆる「RPC Loa d an NLM」は、リモートにサーバ・プロセス（いわゆるＮＬＭ、つまり、ネットウェア・ローダブル・モジュール(NetWare Loadable Module)）ロードするためのものであり、一般的には以下のように説明できる。１．リモート・サーバ・ソフトウェア・プロセスのサービスが必要なクライアント・ソフトウェアは、そのローカル・コンピュータ内でも動作していなければならないネットワーク・クライアントへリクエストを発行する。このリクエストは、ネットウェア環境内で、ネットウェア・シェル(NetWare shell)として知られているローカル・ネットワーク・クライアント内のモジュールを通じて、インターセプト(intercept)される。２．ネットウェア・シェルは、そのリクエストをＮＣＰリクエストとして解釈し、そのリクエストをネットワーク・クライアントの別のモジュールであってＮＣＰパケットを作成することができるものに渡す。ＮＣＰパケット作成モジュールは、すなわちネットウェア環境においてはNCP.VLM であるが、RPC Load an NL M バーブを作成して、これお基礎となるトランスポートの上に置く。３．RPC Load an NLM リクエストは、次に、ＮＣＰパケットの形態で送信される。RPC Load an NLM バーブの構造は、表１に提供されている。４．各ＮＣＰパケットは、小さなメッセージ・ヘッダから始まるが、これは、クライアントとサーバとの間の接続の現在の状態の一般的なステータス情報を運ぶ。クライアント・リクエスト・ヘッダは７バイト長であり、一方、サーバのリプライ・ヘッダは８バイト長である。表１に示す通り、RequestType 変数は、ネットワーク・リクエストのタイプを定義する。 0x1111というタイプは、接続アロケーション・サービスのために予約されている。0x2222というタイプは、サーバ・リクエスト・サービスのために予約されている。3333というタイプは、サーバ・レスポンスのために予約されている。0x5555 というタイプは、接続のデストロイ(destroy)のために予約されている。0x9999 というタイプは、作業進行中のレスポンスのために予約されている。５．シーケンス番号は、入ってくるリクエストすべてに対する数値によるカウンタであり、リプライのプライオリタイゼーション(prioritization)を提供する。ConnectionNumberLow、および、ConnectionNumberHighなる数は、クライアントとサーバとの間の特定のサービス接続を識別する。 TaskNumberは、どのクライアント・プロセスまたはスレッドがそのサーバに対するリクエストを行っているのかを区別する。６．ネットウェア環境内においては、SubFuncStrucLen は、２１に、ヌル(nul l)で終わるPathAndName（ASCII）の大きさを足した数となる。NLMLoadOptionsは、サーバ・プロセスを、リング０、１、２、または３などのプロセッサ・リング内にロードするためのオプションを含む。この構造のPathAndName 変数は、実行されるサーバ・ソフトウェアのロケーションのパスおよびファイル名をASCII で含み、｛ボリューム名：｝｛パス＼... ｝ファイル名＼0 というフォーマットである。７．サーバ・オペレーティング・システムは、「RPC Load an NLM」バーブに、表２に提供されたリプライ・フォーマットを通して応答する。パケットに含まれた一般的メッセージ・ヘッダ情報に加えて、レスポンス・パケットはCompleti onCodeを含み、これはリクエストが成功裏に完了する場合は０、サーバが無効なサブファンクション・リクエスト、すなわち「RPC Load an NLM」バーブ構造にマッチしないようなものを受信する場合は２５１となる。８．ＲＰＣcodeは、サーバ・プロセスをロードするためのリクエストについての情報を含む。サーバ・プロセスのロードと実行が成功した場合には、RPCcode は０含むことになる。リクエストに対するレスポンスにおいてロードすべきサーバ・ソフトウェア・モジュールが見つからなかった場合や、その名前がリクエストによって提供されていなかった場合は、サーバは１５８というRPCcode 値を返すことになる。それでは、図２と図３を参照して、動的にサーバ・コンピュータ・ファイル・サーバをリモート・クライアントから再構成するための例示的な方法について説明する。ユーザはまず、ネットワーク１０に関連づけられたクライアント・コンピュータ２０へログ・オンすることにより、セッション（ステップ３０２）を確立(est ablish)する（図１を参照）。これに関して、ネットワーク上の「セッション(se ssion)」では、典型的には、ユーザがユーザ・パスワードを入力することを要求するが、これによって、ユーザはクライアント・コンピュータ２０を利用してコンピュータ４０に常駐しているサーバ・ファンクション(function)のためにサーバ・コンピュータ４０にアクセスすることができるようになる。ユーザがサーバ・オペレーティング・システムを、例えばソフトウェア・モジュールをオペレーティング・システムの上へクライアント・コンピュータからロードすることによって、再構成することを望む場合は、クライアント・アプリケーションは、所望通りに、サーバ・オペレーティング・システムを再構成するために設計された一連のステップを始める。図示した実施の形態のコンテキスト(context)においては、ユーザはソフトウェア・モジュールをサーバ・コンピュータ・ファイル・サーバに追加したいと考えることもありうる。ネットウェア・プロトコルを使用するネットウェア環境では、ユーザは、ネットウェア・ローダブル・モジュール（ＮＬＭ）をサーバ・ハード・ドライブに追加したいと望むこともありうる。より一般的なコンテキストでは、ユーザはサーバ・オペレーティング・システム・モジュール（ＳＯＳＭ）をサーバ・ハード・ドライブに追加したいと望むこともありうる。このようなファンクションを実装するための最初のステップは、クライアント・アプリケーションがサーバ上のロードすべきＳＯＳＭをリトリーブ(retrieve)することである（ステップ３０４）。これに関して、ＳＯＳＭはディスク・ドライブ２６からロードすることも、ＲＯＭ３２からリトリーブすることも、あるいは、クライアント・アプリケーションがＳＯＳＭをリトリーブできるようにする他の好ましい機構によることもできる。図２および図３の参照を続けると、クライアント・ソフトウェアは、次に、クライアント・コンピュータによってサーバへトランスミット(transmit)されるメッセージ・パケットのコンストラクト(construct)を始める。サーバ・コンピュータがこのメッセージ・パケットをリトリーブする場合、サーバ・コンピュータは、それがクライアント・コンピュータからサーバ・コンピュータのハード・ドライブへ受信したＳＯＳＭをロードするが、これについては、以下で詳しく説明する。このようなメッセージ・パケットをビルド(build)する際の最初のステップは、例示的なメッセージ・パケット２００（図２を参照）のデータ・ポーション２０２をビルドすること（ステップ３０６）を含む。サーバ・ソフトウェアは、次に、ファンクション・ヘッダ２０４をメッセージ・パケットに追加する（ステップ３０８）。ファンクション・ヘッダは、好ましくは、サーバ・コンピュータへのインストラクションのインディシア(indicia) を備えるが、これは、サーバ・コンピュータによって実行され、メッセージ・パケット（この例では、クライアント・コンピュータからサーバ・コンピュータへトランスミットされるＳＯＳＭ）のデータ・ポーション２０２の上にある１つまたは複数のファンクションに関するものである。本発明の好適実施の形態によれば、ファンクション・ヘッダ２０４は、クライアント・ソフトウェアによって、クライアント・ソフトウェア内に常駐するファンクション・ライブラリ、すなわち、ＮＣＰヘッダのライブラリからセレクトされるが、そのそれぞれは、あらかじめ定めたファンクションの処理を表現するものである。クライアント・ソフトウェアは、その後、ＳＯＳＭをロードするためのリクエストを発行する。しかし、図示された実施の形態のコンテキストでは、このリクエストは、好ましくは、ネットウェア・シェルまたは他の適切なＩＰＸインターフェースによって「インターセプト」され（ステップ３１０）、その際に、クライアント・ソフトウェアは適切なＩＰＸヘッダ２０６をメッセージ・パケット２００に追加する（ステップ３１２）。図示された実施の形態においては、ＩＰＸヘッダは、サーバ・コンピュータであってそのリクエストがクライアント・ソフトウェアにより向けられているサーバ・コンピュータのネットワーク・アドレスのインディシアを備える。メッセージをネットワークＢＵＳ上に置く前に、ワイヤ・フレーム・ヘッダ (wire frame header)２０８をメッセージに追加して（ステップ３１４）、クライアントからサーバへのメッセージ・パケットのトランスミッションができるようにすることが望ましい。本発明の一側面によれば、好ましいワイヤ・フレーム・ヘッダ・タイプは、IEEE 802.2、802.3 、およびこれに類似するものを含むことができる。それでは図３を参照すると、一度メッセージ・パケット２００がすべてコンストラクトされると、クライアント・コンピュータ２０は好ましくはこのメッセージ・パケットをネットワークＢＵＳ５４に加える（ステップ３１６）。サーバ・コンピュータ４０によってメッセージ・パケット２００が受信されると（ステップ３１８）、サーバ・コンピュータ４０に関連づけられた物理的なドライバ・インターフェース（図示せず）は、ワイヤ・フレーム・ヘッダ２０８をストリップ・オフ(strip off)する（ステップ３２０）。それからサーバ・コンピュータ４０は、ＩＰＸヘッダ２０６をインタロゲートして、そのメッセージが適切にその目的とする宛先(intended destination)（たとえば、サーバ・コンピュータ４０）に到着していることを確認して、ＩＰＸヘッダ２０６をストリップ・オフする（ステップ３２２）。サーバ・コンピュータ４０に常駐しているサーバ・ソフトウェアは、それから、ＮＣＰヘッダ・フィールド２０４をインタロゲートして、データ２０２上のサーバ・コンピュータ４０によって実行されるタスクを確認(ascertain)する。ネットウェア環境において動作する典型的なサーバ・コンピュータにおいては、ファンクション・ヘッダ２０４は、好ましくはサーバ・コンピュータ４０に関連づけられたＮＣＰインターフェースによってアクセスされおよび解釈される。要求されたファンクションが決定されると、サーバ・コンピュータ４０は、データ２０２上の所望のファンクションを実装する。図示された例のコンテキストにおいては、リクエストされたファンクションは「ＳＯＳＭをロード(load SOSM)」することである。ここで、サーバ・コンピュータ４０は、好ましくは、ＳＯＳＭをハード・ドライブ５０上にサーバのオペレーティング・システム・プロトコルにしたがってロードする（ステップ３２６）。ここで、図３を参照すると、サーバ・コンピュータ４０が、クライアント・コンピュータ２０にトランスミットして戻すレスポンス・メッセージをコンストラクトすることが望ましいことがある。これは、たとえば、そのＳＯＳＭが適切にロードされたことを確認するため、サーバ・コンピュータによってそのＳＯＳＭに割り当てられたファイル名および／またはアドレスをクライアント・ソフトウェアに知らせるため、などのためである。このプロセスの第１のステップとして、サーバ・コンピュータ４０に常駐するサーバ・ソフトウェアが、レスポンス・メッセージをビルドすることを始める（ステップ３２８）。図示された実施の形態においては、そのようなレスポンス・メッセージの「データ」部２０２は、例えば、ＳＯＳＭが適切にＳＯＳＭロードされたという結果に対するメッセージや、サーバのハード・ドライブのアドレスなどを含むことができる。サーバ・ソフトウェアは、それから、ファンクション・ヘッダ２０４をメッセージにアペンド(append)する（ステップ３３０）。例えば、データ２０２の性質を識別するファンクション・ヘッダである。このコンテキストにおいては、ファンクション・ヘッダは、単に、データ部２０２がリプライ・メッセージに対応していることを示すことができる。サーバ・ソフトウェアは、その後、例えば、クライアント・コンピュータ２０に関連づけられたネットワーク・アドレスのインディカティブ(indicative)などのＩＰＸヘッダをアペンドし（ステップ３３２）、その語に、適切なワイヤ・フレーム・ヘッダ２０８をそのメッセージに追加する（ステップ３３４）。サーバ・コンピュータは、それから、好ましくはメッセージ・パケットをネットワーク・ワイヤ上にトランスミットする（ステップ３３６）。レスポンス・メッセージがクライアント・コンピュータによって受信される場合は（ステップ３３８）、クライアント・コンピュータに関連づけられた物理的ドライバ・インターフェース（図示せず）がメッセージ・パケットを受信してワイヤ・フレーム・ヘッダ２０８をストリップ・オフする（ステップ３４０）。クライアント・コンピュータに関連づけられたリディレクター(redirector)ＩＰＸインターフェースは、それから、レスポンス・メッセージを受信して、ＩＰＸヘッダをストリップ・オフし（ステップ３４２）、このようにして、レスポンス・メッセージがネットワーク上の適切なノード（例えばクライアント・コンピュータ２０）によって受信されていることを確認する。クライアント・コンピュータに関連づけられているＮＣＰインターフェースは、それから、そのファンクション・リクエストを受信して、ファンクション・ヘッダ２０４をストリップ・オフし（ステップ３４４）、その上で、クライアント・ソフトウェアがそのデータを解釈する。ここで提示したケースにおいては、リプライ・メッセージ２００のデータ部２０２は、事実上、ユーザ・アンプリケーション(user amplication)のコンテキストにおいて適切な情報であれば、いかなるものをも備えることができる。たとえば、ＳＯＳＭが正しくロードされたことや、サーバ・コンピュータのハード・ドライブ上のＳＯＳＭアドレスなどを示すユーザへのメッセージである。この点に関して、クライアント・ソフトウェアがデータ・フィールド２０２を解釈して所定のファンクションをそれにしたがって実行することができるようなファンクション・ライブラリを利用することが所望である。これは、たとえば、メッセージをユーザへ表示すること、または、サーバのハード・ドライブにクライアント・ソフトウェアによって常駐することとなったＳＯＳＭへのアクセスができるようにすること（ステップ３４６）、によって行う。図３から図６において示された方法論は、ＳＯＳＭ（例えばＮＬＭ）のロードを、対応するレスポンス・メッセージのコンストラクションにおいて説明するが、添付した図面に示された一般的なスキームを使用すれば、サーバ・ハード・ドライブ、オペレーティング・システム、または、関連づけられたハードウェア・デバイスを、リモート・クライアント・コンピュータから制御、再構成、操作(m anipulate)、あるいは、その他のアクセスをすることができる。実際、クライアント・コンピュータの所にいるユーザが、典型的にはサーバ・コンピュータオペレーティング・システムへのアクセスを得るのに必要とされるシステム管理者のスーパー・パスワードを利用しなくとも、あるいは知っていない場合ですら、これを達成することができる。本発明を実装するクライアント・ソフトウェア開発者は、本発明を利用して、ネットワーク・クライアントとインタラクトして適切なリモート・プロシージャ・コールを発行するクライアント・ソフトウェアを開発することができる。このリモート・プロシージャ・コールは、そのクライアント・ソフトウェアの所望のファンクションに依存する。以下の例示的なソフトウェア・プログラムは、現在の実施の形態において識別されるリモート・プロシージャ・コールのそれぞれを行う(exercise)ものである。リモート・サービスたくさんのリモート・サービスがありうるが、現在の実施の形態においては７つが実装されており、これは「RPC Load an NLM」、「RPC Unload an NLM」、「 RPC Mount a Volume」、「RPC Dismount a Volume」、「RPC Add Name Space to Volume」、「RPC Set Set Command Value」および「RPC Execute NCF File」を含む。「RPC Load and NLM」は上述してある。残りについては、以下に説明する。RPC NLM をアンロード(RPC Unload an NLM) 本発明のこの側面は、リモート・コンピュータにおいて動作しているプロセスをアンロードするためのクライアント・リクエストを処理する。このリモート・プロシージャ・コールに対する好ましいリクエスト／リプライ・フォーマット(r equest/reply format)は、以下のように実装することができる。 SubFuncStrucLen サブ・ファンクションの長さは、好ましくは、２１に文字列の最後を表わすヌルを含むPathAndName(ASCIIZ)のサイズを加算したものである。 PathAndName ASCII で表わしたロードすべきパスおよびファイル名。フォーマット：{ボリューム名:}{パス＼...}ファイル名＼0 RPC ボリュームをマウント(RPC Mount Volume) 本発明のこの面は、クライアント・ソフトウェアがリモート・ストレージ・ボリュームをマウントできるようにさせる。このリクエスト／リプライのフォーマットは以下の通りである。 SubFuncStrucLen サブ・ファンクションの長さは、２１に文字列の最後を意味するヌルを含むVo lumeName（ASCIIZ）のサイズを加算したものとなる。 VolumeName マウントすべきボリューム名(ASCIIZ フォーマットで)。フォーマット：ボリューム名＼0 RPC ボリュームをディスマウント(RPC Dismount Volume) 本発明のこの側面は、リモート・コンピュータ上のボリュームをディスマウントする。リクエスト／リプライのフォーマットは以下の通りである。 VolumeName ディスマウントすべきボリューム名(ASCIIZ フォーマットで)。フォーマット：ボリューム名＼0 RPC ボリュームへ名前空間を追加(RPC Add Name Space to Volume) 本発明のこの側面は、ユーザが、指定した名前空間をリモート・コンピュータ上にマウントされたボリュームに動的に追加することができるようにさせる。名前空間は、あるクライアントに対する特定の属性、たとえば、ファイル名の長さ、ファイル・キャラクタ、ケース・センシティビティ(case sensitivity)、マルチプル(multiple)・ファイル（たとえばフォーマッティング情報を含むリソース・ファイルなど）、ベクタ(vector)グラフィックスなどのようなファンクションをサポートしている。ネットウェア・コア・プロトコルにおけるリクエスト／リプライのフォーマットは以下の通りである。リクエスト・フォーマット SubFuncStrucLen サブ・ファンクションの長さは、２１に、文字列の終了を示すヌルを含むAddN ameSpace文字列（ASCIIZ）の大きさを加算したものである。 AddNameSpace 選択したボリューム名に名前空間を追加するためのAddNameSpace文字列(ASCII Zフォームで)である。フォーマット：名前空間名｛TO｝｛VOLUME｝ボリューム名＼0 RPC セット・コマンド値のセット(RPC Set Set Command Value) 本発明のこの側面は、クライアントが、リモート・コンピュータ上のセット・コマンドの現在の値を変更することができるようにさせる。ネットウェア環境においては、セット・コマンドは、通信パラメータ、メモリ・アロケーション、ファイル・キャッシング(file caching)、ディレクトリ・キャッシング、ファイル・システム・パラメータ、ファイル・ロッキング・パラメータ、トランザクション・トラッキング、およびディスク管理などを決定する。リクエスト／リプライのフォーマットは以下の通りである。リクエスト・フォーマット SubFuncStrucLen サブファンクションの長さは、２１に、文字列の終了を示すヌルを含むSetCmd Nameのサイズを加算したものである。typeFlagが0 の場合は、ヌルを含むオプション文字列は、SubFuncStrucLen フィールドに含まれていなければならない。 typeFlag ０の場合は、SetCmdNameの次にあるオプション文字列は、セット・コマンドの新しい値である。１の場合は、Value フィールドがセット・コマンドの新しい値を含む。 Value セット・コマンド・パラメータの新しい値(typeFlag が１に等しい場合）。 SetCmdName ASCIIZフォーマットのパラメータ・コマンド名をセットする。｛オプション文字列｝ typeFlagが０の場合、この文字列は、新しいセット・コマンド・パラメータの値用に使われる。セット・コマンド・パラメータのタイプ(SP_TYPE_STRING & SP _TYPE_TIME_OFFSET)は、数値ではなく文字列を必要とする。 RPC Execute NCF File 本発明のこの側面は、リモート・コンピュータ上の選択されたバッチ・ファイルの実行をできるようにさせる。したがって、クライアント・ソフトウェアは、バッチ・ファイルをサーバへコピーしてから、サーバへそのバッチ・ファイルを実行するようリクエストすることができる。このバッチ・ファイルは、基礎となるサーバ・オペレーティング・システムの要求に従うものでなければならない。ネットウェア・コア・プロトコルに実装された本実施の形態においては、リクエスト／リプライのフォーマットは以下の通りである。リクエスト・フォーマット SubFuncStrucLen サブファンクションの長さは、２１に、文字列の終了を示すヌルを含むPathAn dName（ASCIIZ）のサイズを加算したものである。 PathAndName 実行すべきASCIIZのパスおよびファイル名。フォーマット:{ボリューム名:}{パス＼...}ファイル名＼0 セキュリティ本発明の一側面は、ネットワーク通信プロトコルに固有のセキュリティに頼ることができることである。ネットウェア環境においては、ＮＣＰプロトコルにおけるセキュリティは、ディジタル・パケット署名(signing)を介して提供される。ＮＣＰネットワーク通信プロトコルにおいて使用される方法および装置は、１９９４年９月２０日に発行された米国特許第５，３４９，６４２号に詳細が記載されており、ここではこれを参照することにより、この特許の開示は本明細書の一部を構成する。サーバの実装サーバ内におけるリモート・プロシージャ・コールの実装は、呼び出しを適切なサーバ・オペレーティング・システム・ファンクションにマップする。この形式においては、このサーバ実装は、リモート・コンソール・ログインをしなくてもすむようになる。ここでは、クライアントからの各キー・ストロークがキャプチャされ、パッケージされてサーバへ送られてから、システム・コンソールを介して入力される。一実施の形態においては、本発明のこの側面は、ネットウェア・サーバ環境において以下のように実装される。このプロシージャの実装の結果として、自分のリモート・サーバ・アプリケーションをロード、アンロード、またはさもなくば構成する機能を有するクライアント・ソフトウェアを開発しようと考える開発者は、その呼び出しをサポートするネットワーク・クライアントおよびサーバ・オペレーティング・システムを使用することによりこれを行うことができる。本発明の一実施の形態を示して説明してきたが、当業者によれば、本発明の精神および範囲から逸脱することなく、種々の修正や変更を行うことが可能である。

【手続補正書】【提出日】１９９８年５月１２日【補正内容】請求の範囲１．（ａ）コンピュータ・プログラムを実行するための少なくとも１つのプロセッサを有するデバイスと、該デバイスのユーザが入力を提供しおよび該デバイスから出力を受け取ることができるようにする手段と、ネットワーク・サービスをディジタル・パケットの手段によってリクエストしおよび受け取るための手段とを備えたネットワーク・クライアント・コンピュータと、（ｂ）コンピュータ・プログラムを実行するための少なくとも１つのプロセッサを有するデバイスと、ネットワーク・サービスをディジタル・パケットの手段によってリクエストしおよび受け取るための手段とを有する少なくとも１つのネットワーク・サーバ・コンピュータと、（ｃ）ネイティブな通信プロトコルを使用するネットワーク・オペレーティング・システムとを含むコンピュータ・ネットワークにおける該サーバ・コンピュータのそれぞれを該クライアント・コンピュータの１つからリモートに管理する方法において、ａ．ネットワーク・クライアント・アプリケーションを、ネットワーク・オペレーティング・システムによって提供される該クライアント・ベースのプログラムとインタラクトさせて、該ネットワーク・クライアント・アプリケーションのネットワーク管理呼び出しが、該クライアント・ベースのプログラムへ、該ネットワーク・オペレーティング・システムによって、渡されるステップと、ｂ．該ネットワーク・クライアント・アプリケーションの該ネットワーク管理呼び出しを、該ネットワーク・サーバへ、ネイティブな通信プロトコルによって、トランスミットするステップと、ｃ．ネットワーク・サーバに直接、該ネットワーク管理呼び出しをネイティブなオペレーティング・システム呼び出しとして実行させるステップとを備えたことを特徴とする方法。２．（ａ）ネットワーク・サービスをディジタル・メッセージ・パケットの使用を介してリクエストしおよび受け取るように構成されたネットワーク・クライアント・コンピュータであって、該クライアント・コンピュータは、コンピュータ・プログラムを実行するための第１のプロセッサと、ユーザ入力および出力ハードウェアを備え、ユニークなユーザ・アクセス・パスワードによって特徴づけられる前記クライアント・コンピュータは、それに関連づけられたセキュリティの第１のレベルを有し、（ｂ）ネットワーク・サービスをディジタル・メッセージ・パケットの使用を介してリクエストしおよび受け取るように構成されたネットワーク・サーバ・コンピュータであって、該サーバ・コンピュータは、コンピュータ・プログラムを実行するためのプロセッサと、複数のソフトウェア・モジュールをストアするためのハード・ドライブと、ＲＡＭとを備え、管理者アクセス・パスワードによって特徴づけられる前記サーバ・コンピュータは、それに関連づけらえたセキュリティの第２のレベルを有し、セキュリティの第２のレベルは、前記セキュリティの第１のレベルより高いものであり、（ｃ）サーバ・オペレーティング・システムであって、ネイティブな通信プロトコルを含み、前記サーバ・コンピュータに常駐するものを含むコンピュータ・ネットワークにおける方法において、リモートに前記サーバ・オペレーティング・システムを前記クライアント・コンピュータから再構成する方法であって、前記ユーザ・アクセス・パスワードを前記ユーザ入力ハードウェアへ入力し、それによって、前記クライアント・コンピュータにおけるユーザ・セッションを確立するステップと、サーバ・プロセスを前記クライアント・コンピュータから前記サーバ・コンピュータへトランスミットするステップと、前記サーバ・プロセスを、前記サーバ・コンピュータの前記ハード・ドライブ上の第１のアドレスにストアするステップと、前記サーバ・コンピュータから前記クライアント・コンピュータへ前記第１のアドレスのインディシアをトランスミットするステップと、前記クライアント・コンピュータにより、ソフトウェア・モジュールをロードするリクエストを示す第１のフィールドと、および、前記第１のアドレスを示す第２のフィールドとを備えた第１のディジタル・メッセージ・パケットをコンストラクトするステップと、前記第１のパケットを前記クライアント・コンピュータから前記サーバ・コンピュータへトランスミットするステップと、前記第１および第２のフィールドを前記サーバ・オペレーティング・システムによって処理するステップと、前記サーバ・プロセスを前記ハード・ドライブ上の前記第１のアドレスからリトリーブするステップと、前記サーバ・プロセスを前記ＲＡＭへロードして、それによって、動的に前記サーバ・オペレーティング・システムを、前記管理者アクセス・パスワードを使用せずに再構成するステップと、レスポンス・メッセージを、前記サーバ・コンピュータにより、コンストラクトし、および、前記レスポンス・メッセージを前記クライアント・コンピュータへ前記ロードするステップの後にトランスミットするステップであって、前記レスポンス・メッセージは、前記サーバ・プロセスが前記ＲＡＭにロードされていることを示すステップとを備えたことを特徴とする方法。３．請求項２に記載の方法において、前記コンストラクトするステップは、ＩＰＸヘッダを前記第１および第２のフィールドと共に含むメッセージ・パケットをビルドするステップを備えたことを特徴とする方法。４．請求項２に記載の方法において、前記コンストラクトするステップは、部分的にコンストラクトされたディジタル・メッセージ・パケットを、前記クライアント・コンピュータ内のルックアップ・テーブルからリトリーブするステップと、前記第１および第２のフィールドを前記入力ハードウェアから受け取ったユーザ・リクエストにしたがって操作するステップとを備えたことを特徴とする方法。５．請求項２に記載の方法において、前記コンストラクトするステップは、前記第１および第２のフィールドに加えて前記第１のディジタル・メッセージ・パケットへの複数のナビゲート用フィールドを追加するステップをさらに備え、前記処理するステップは、前記複数のフィールドをストリップ・オフして前記サーバ・オペレーティング・システムが前記第１および第２のフィールドのみを処理するようにするステップを備えたことを特徴とする方法。６．請求項２に記載の方法において、クライアント・アプリケーションを前記クライアント・コンピュータにロードして前記アプリケーションを動作させるステップと、前記アプリケーション・プログラムにより、前記サーバ・プロセスに、前記アプリケーション・プログラムのオペレーションの間にアクセスするステップとをさらに備えたことを特徴とする方法。７．クライアント／サーバ・コンピュータ・システムにおいて、ネットワーク・サービスをディジタル・メッセージ・パケットの使用を介してリクエストしおよび受け取るために構成されたネットワーク・クライアント・コンピュータを備え、前記クライアント・コンピュータはコンピュータ・プログラムを実行するための第１のプロセス・サーバと、ネットワーク・サービス・リクエストをディジタル・メッセージ・パケットの使用を介して前記クライアント・コンピュータから受け取るために構成されたネットワーク・サーバ・コンピュータとを備え、該サーバ・コンピュータはコンピュータ・プログラムを実行するための第２のプロセッサと、複数のソフトウェア・モジュールをストアするためのハード・ドライブと、ＲＡＭと、前記サーバ・コンピュータに常駐するネイティブな通信プロトコルを含むサーバ・オペレーティング・システムとを備え、前記クライアント／サーバ・コンピュータ・システムは、サーバ・アプリケーションを前記クライアント・コンピュータから前記サーバ・コンピュータへトランスミットする手段と、前記サーバ・アプリケーションを前記サーバ・コンピュータの前記ハード・ドライブ上の第１のアドレスへストアする手段と、前記サーバ・コンピュータから前記クライアント・コンピュータヘ前記第１のアドレスのインディシアをトランスミットする手段と、前記クライアント・コンピュータによって、ソフトウェア・モジュールをロードするためのリクエストのインディシアおよび前記第１のアドレスのインディシアを備えた第１のディジタル・メッセージ・パケットをコンストラクトする手段と、前記第１のメッセージ・パケットを前記クライアント・コンピュータから前記サーバ・コンピュータへトランスミットする手段と、前記第１のパケットへのレスポンスとして、前記サーバ・アプリケーションを前記ハード・ドライブ上の前記第１のアドレスからリトリーブする手段と、前記サーバ・アプリケーションを前記ＲＡＭへロードして、それによって動的に前記サーバ・オペレーティング・システムを前記クライアント・コンピュータから再構成する手段とを備えたことを特徴とするクライアント・サーバ・コンピュータ・システム。８．請求項７に記載のコンピュータ・システムにおいて、ユーザがユニークなユーザ・アクセス・パスワードを前記クライアント・コンピュータに入力できるように構成されたキーボードであって、該パスワードはそれに関連づけられたセキュリティの第１のレベルを有するものと、前記サーバ・コンピュータに関連づけられた管理者アクセス・パスワードであって、前記管理者アクセス・パスワードはそれに関連づけられたセキュリティの第２のレベルを有するものと、前記クライアント・コンピュータに前記ユーザ・アクセス・パスワードを入力した上でユーザ・セッションを前記クライアント・コンピュータにおいて確立する手段と、動的に前記サーバ・オペレーティング・システムを前記クライアント・コンピュータから前記管理者アクセス・パスワードを使用せずに再構成する手段とをさらに備えたことを特徴とするコンピュータ・システム。９．請求項７に記載のコンピュータ・システムにおいて、前記サーバ・コンピュータは、レスポンス・メッセージをコンストラクトして、前記レスポンス・メッセージを前記クライアント・コンピュータへ前記サーバ・アプリケーションが前記ＲＡＭ内へロードされたことを示すためにトランスミットする手段をさらに備えたことを特徴とするコンピュータ・システム。１０．請求項７に記載のコンピュータ・システムであって、データ・パケットを前記クライアント・コンピュータと前記サーバ・コンピュータとの間で前記再構成されたサーバ・オペレーティング・システムを使用してトランスミットする手段をさらに備えたことを特徴とするコンピュータ・システム。１１．請求項７に記載のコンピュータ・システムにおいて、前記サーバ・アプリケーションはネットワーク・オペレーティング・システム・モジュールを備えたことを特徴とするコンピュータ・システム。１２．請求項７に記載のコンピュータ・システムにおいて、クライアント・アプリケーションを前記クライアント・コンピュータ上にロードして、前記クライアント・アプリケーションを前記サーバ・アプリケーションとインタラクティブに動作させる手段をさらに備えたことを特徴とするるコンピュータ・システム。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．（ａ）コンピュータ・プログラムを実行するための少なくとも１つのプロセッサを有するデバイスと、該デバイスのユーザが入力を提供しおよび該デバイスから出力を受け取ることができるようにする手段と、ネットワーク・サービスをディジタル・パケットの手段によってリクエストしおよび受け取るための手段とを備えたネットワーク・クライアント・コンピュータと、（ｂ）コンピュータ・プログラムを実行するための少なくとも１つのプロセッサを有するデバイスと、ネットワーク・サービスをディジタル・パケットの手段によってリクエストしおよび受け取るための手段とを有する少なくとも１つのネットワーク・サーバ・コンピュータと、（ｃ）ネイティブな通信プロトコルを使用するネットワーク・オペレーティング・システムとを含むコンピュータ・ネットワークにおいて、該サーバ・コンピュータのそれぞれを該クライアント・コンピュータの１つからリモートに管理する方法であって、ａ．ネットワーク・クライアント・アプリケーションを、ネットワーク・オペレーティング・システムによって提供される該クライアント・ベースのプログラムとインタラクトさせて、該ネットワーク・クライアント・アプリケーションのネットワーク管理呼び出しが、該クライアント・ベースのプログラムへ、該ネットワーク・オペレーティング・システムによって、渡されるステップと、ｂ．該ネットワーク・クライアント・アプリケーションの該ネットワーク管理呼び出しを、該ネットワーク・サーバへ、ネイティブな通信プロトコルによって、トランスミットするステップと、ｃ．ネットワーク・サーバに直接、該ネットワーク管理呼び出しをネイティブなオペレーティング・システム呼び出しとして実行させるステップとを備えたことを特徴とする方法。２．（ａ）ネットワーク・サービスをディジタル・メッセージ・パケットの使用を介してリクエストしおよび受け取るように構成されたネットワーク・クライアント・コンピュータであって、コンピュータ・プログラムを実行するための第１のプロセッサと、ユーザ入力および出力ハードウェアを備え、ユニークなユーザ・アクセス・パスワードによって特徴づけられる前記クライアント・コンピュータは、それに関連づけられたセキュリティの第１のレベルを有し、（ｂ）ネットワーク・サービスをディジタル・メッセージ・パケットの使用を介してリクエストしおよび受け取るように構成されたネットワーク・サーバ・コンピュータであって、コンピュータ・プログラムを実行するためのプロセッサと、複数のソフトウェア・モジュールをストアするためのハード・ドライブと、ＲＡＭとを備え、管理者アクセス・パスワードによって特徴づけられる前記サーバ・コンピュータは、それに関連づけらえたセキュリティの第２のレベルを有し、セキュリティの第２のレベルは、前記セキュリティの第１のレベルより高いものであり、（ｃ）サーバ・オペレーティング・システムであって、ネイティブな通信プロトコルを含み、前記サーバ・コンピュータに常駐するものを含むコンピュータ・ネットワークにおける方法であって、リモートに前記サーバ・オペレーティング・システムを前記クライアント・コンピュータから再構成する方法であって、前記ユーザ・アクセス・パスワードを前記ユーザ入力ハードウェアへ入力し、それによって、前記クライアント・コンピュータにおけるユーザ・セッションを確立するステップと、サーバ・オペレーティング・システム・モジュール（ＳＯＳＭ）を前記クライアント・コンピュータから前記サーバ・コンピュータへトランスミットするステップと、前記ＳＯＳＭを、前記サーバ・コンピュータの前記ハード・ドライブ上の第１のアドレスにストアするステップと、前記サーバ・コンピュータから前記クライアント・コンピュータへ前記第１のアドレスのインディシアをトランスミットするステップと、前記クライアント・コンピュータにより、ソフトウェア・モジュールをロードするリクエストの第１のフィールド・インディカティブ、および、前記第１のアドレスの第２のフィールド・インディカティブとを備えた第１のディジタル・メッセージ・パケットをコンストラクトするステップと、前記第１のパケットを前記クライアント・コンピュータから前記サーバ・コンピュータへトランスミットするステップと、前記第１および第２のフィールドを前記サーバ・オペレーティング・システムによって処理するステップと、前記ＳＯＳＭを前記ハード・ドライブ上の前記第１のアドレスからリトリーブするステップと、前記ＳＯＳＭを前記ＲＡＭへロードして、それによって、動的に前記サーバ・オペレーティング・システムを、前記管理者アクセス・パスワードを使用せずに再構成するステップと、レスポンス・メッセージを、前記サーバ・コンピュータにより、コンストラクトし、および、前記レスポンス・メッセージを前記クライアント・コンピュータへ前記ロードするステップの後にトランスミットするステップであって、前記レスポンス・メッセージは、前記ＳＯＳＭが前記ＲＡＭにロードされていることを示すステップとを備えたことを特徴とする方法。３．請求項２に記載の方法において、クライアント・アプリケーションを前記クライアント・コンピュータ上にロードするステップをさらに備えたことを特徴とする方法。４．請求項３に記載の方法において、前記クライアント・アプリケーションを前記クライアント・コンピュータ上で前記ＳＯＳＭとインタラクティブに動作させるステップをさらに備えたことを特徴とする方法。５．請求項４に記載の方法において、データ・パケットを前記クライアント・コンピュータと前記サーバ・コンピュータとの間で前記再構成されたサーバ・オペレーティング・システムを使用してトランスミットするステップをさらに備えたことを特徴とする方法。６．請求項２に記載の方法において、前記コンストラクトするステップは、ＩＰＸヘッダを前記第１および第２のフィールドと共に含むメッセージ・パケットをビルドするステップを備えたことを特徴とする方法。７．請求項２に記載の方法において、前記コンストラクトするステップは、部分的にコンストラクトされたディジタル・メッセージ・パケットを、前記クライアント・コンピュータ内のルックアップ・テーブルからリトリーブするステップと、前記第１および第２のフィールドを前記入力ハードウェアから受け取ったユーザ・リクエストにしたがって操作するステップとを備えたことを特徴とする方法。８．請求項２に記載の方法において、前記ＳＯＳＭは、ネットウェア・ローダブル・モジュールを備えたことを特徴とする方法。９．請求項２に記載の方法において、前記第１のフィールドは、所定のリモート・プロシージャ・コールのインディシアを備えたことを特徴とする方法。１０．請求項９に記載の方法において、前記リモート・プロシージャ・コールは、 RPC load and NLMと、 RPC unload and NLMと、 RPC mount a volume と、 RPC dismount a volume と、 RPC add name space to volume と、 RPC set command value と、 RPC execute NCF fileとの中の１つを備えたことを特徴とする方法。１１．請求項２に記載の方法において、前記第２のフィールドは、論理アドレスのインディシアを備えたことを特徴とする方法。１２．請求項２に記載の方法において、前記第２のフィールドは、ファイル名のインディシアを備えたことを特徴とする方法。１３．請求項２に記載の方法において、前記コンストラクトするステップは、前記第１および第２のフィールドに加えて前記第１のディジタル・メッセージ・パケットへの複数のナビゲート用フィールドを追加するステップを備え、および、前記処理するステップは、前記複数のフィールドをストリップ・オフして前記サーバ・オペレーティング・システムが前記第１および第２のフィールドのみを処理するようにするステップをさらに備えたことを特徴とする方法。１４．請求項２に記載の方法において、クライアント・アプリケーションを前記クライアント・コンピュータにロードして前記アプリケーションを動作させるステップと、前記アプリケーション・プログラムにより、前記ＳＯＳＭに、前記アプリケーション・プログラムのオペレーションの間にアクセスするステップとをさらに備えたことを特徴とする方法。