JP2000517074A - 遠隔データ回復用の装置及び方法 - Google Patents

Abstract

(57)【要約】 コンピュータの記憶装置上のアクセスできないデータを遠隔的に回復するための装置及び方法が開示されている。方法としては、（１）データの回復が必要な前記記憶装置を含むローカル・コンピュータから、技術者によって動作させられる遠隔データ回復コンピュータまでの通信リンクを設定する段階と、（２）前記遠隔技術者のコンピュータに常駐する全ソフトウェア・プログラムにアクセスすらできて前記ローカ・コンピュータの前に着座しているが如くに前記技術者が相互作用することを可能とする段階と、（３）前記遠隔技術者にデータ損失を診断させ矯正させることを可能とする段階とを含む。

Description

【発明の詳細な説明】 遠隔データ回復用の装置及び方法 発明の技術分野 本発明は、一般に、コンピュータ・データ記憶装置及び／或は記憶媒体からの 情報の回復に関し、特に、正規の動作環境によってはアクセスできない情報の回 復に関すると共に、そうしたデータ損失の遠隔的診断及び遠隔的矯正を可能とす る方法に関する。 発明の背景 ユーザにとってコンピューティング・システムの真価は、そのシステムを含む ハードウェア及びソフトウェアの実際的価格に制限されることなく、そのシステ ム内で表されるデータの価値を含む。事実上、会計データ、知的財産、設計及び 製造情報、及び／成は、個人使用或はビジネス使用のコンピューティング・シス テムに保存される他の記録は、最終的にはコンピューティング設備自体の値を遙 かに超える値となることを極めて通常である。 ディスク・ドライバ等のコンピュータ記憶装置上のデータにアクセスする能力 の損失は、オペレータの誤り、誤ったソフトウェア、過渡的（一時的）な電気的 事故、妨害行動、或は、電気的／機械的故障の結果としてしばしば生じ得る。多 くの場合、そうしたデータは正規のオペレーティング環境によってアクセスする ことができないが、データ自体は記憶装置上に依然として存在しており、オペレ ーティング環境によって採用されているファイル・システムを表す媒体上のデー タ構造を操作することによってアクセスさせることができる。そうした媒体上の データ構造の操作は、高度に特殊化されたソフトウェア・ツールを備えた熟練技 術者によって最善の信頼性をもって実行される。 時折、データにアクセスできないことが相当なコスト及び／或はビジネス損失 の原因となり得て、ある時には甚大な程度に及ぶ場合がある。データの幾つかの 形態は再作成の候補となり得る一方で、この再作成のコストは些細な額から莫大 な額までの範囲であり得る。更に、データ再作成には有限の時間が費やされ、そ の間にビジネスの各種の局面がアクセスできないデータに応じて必然的に中断成 は邪魔され得る。また、一般にはリアルタイムで入手される再作成が不可能なデ ータのカテゴリーが存在し、それはそれ故に代替不可能であると考えられる。 オフライン・バックアップ等の従来の冗長機構は、データ損失状況に対して救 済を提供しようとするものである。しかしながら、オフライン・バックアップか らの回復又は再生は、時間がかかり、潜在的にはデータ回復手続を介して有効と なるデータに対して経年変化したデータを提供し得る。それ故に、オフライン・ バックアップから理論的には回復できるデータ損失ですら、潜在的なデータ回復 候補として考えられ得る。 商業的なデータ回復サービス・ビジネスは、こうした問題に様々なサービス・ カテゴリーでもって対処するものである。これらは、オン-サイト及びオフ-サイ ト・サービス双方を典型的には含む。オフ-サイト・データ回復サービス、即ち 、アクセスできないデータを含む媒体成は装置をサービス・ファシリティ（又は サービス施設）でデータ回復技術者が処理するサービスは、顧客の下から媒体或 は装置をサービス施設へ物理的に移動することが必要とされる。これは出荷に起 因する遅れ等によって、相当な稼働停止時間（ダウン・タイム）を生じ得る。ま た、データは鋭敏であり、対応保障要件としてサイトからのデータ移動は勧めら れない旨の指示がある場合もある。多くの場合、夜を徹しての運搬によって誘導 される遅延等にすら鋭敏である。オン-サイト・データ回復サービス、即ち、デ ータ回復技術者が特殊な装置を携えて顧客下へ出向いて局所的にサービスを実行 するサービスは稼働停止時間を低減できるが、技術者及び必要装置の顧客サイト への移動及び顧客サイトからの移動の追加費用が嵩む。 コンピュータを通信ハードウェアを介して通信線に取り付け、これもまた通信 ハードウェアを介して通信線に取り付けられた第２コンピュータのオペレータに よって制御させるように為すことを可能とする遠隔制御方法がある。そうしたハ ードウェア形態は典型的にはパーソナル・コンピュータであり、またそうした遠 隔制御ソフトウェアは共通のパーソナル・コンピュータ・オペレーティング・シ ステムに対して容易に利用可能である。そうした遠隔制御プログラムの例として は、「ＰＣａｎｙｗｈｅｒｅ」、「Ｒｅｍｏｔｅ２」、「Ｃａｒｂｏｎ Ｃｏｐｙ」 等々が挙げられる。このアプローチの短所は、回復されようとするコンピュータ が遠隔制御ソフトウェアを支援するオペレーティング・システムをランしなけれ ばならない。それ故に、このアプローチはそのオペレーティング・システムが遠 隔制御を支援しない場合には役に立たない。 遠隔技術者によってコンピュータ記憶媒体及び記憶装置からデータを遠隔的に 回復することを信頼性をもって可能とするシステム及び方法は、それ故に当業界 では最も必要とされている。従来の先行技術は、コンピュータ記憶媒体成は記憶 装置を、顧客サイト或は技術者側ファシリティの内の何れかで、技術者によって 処理させることを必要としている。データ回復サービスを電話線を介して遠隔的 に実行することは、オン-サイト及びオフ-サイト回復の短所を克服すべく上首尾 のうちに採用されてきたが、ターゲット又は対象となるコンピュータが遠隔制御 ソフトウェアを支援して、回復させることが望まれるデータに対するアクセスを 可能とするオペレーティング・システムをロードできることを要求している。残 念ながら、データ損失に至る各種状況は正規のオペレーティング・システムを頻 繁に不安定及び使用不能とさせたりもする。従って、正規のオペレーティング・ システムが必然的にロード可能或は依存可能でなくとも、遠隔データ回復能力を 提供する方法が当業界において特に要望されている。 本発明はこれらの問題を解決するものであり、正規のオペレーティング環境に よってアクセスできないコンピュータ・データ記憶装置及び／或は記憶媒体から 遠隔的にデータの回復を為す方法及び装置を提供するものであり、データ損失の 遠隔的診断及び遠隔的矯正を為す方法に関する。 発明の概要 本発明の目的は、限定されることはないが、正規のオペレーティング・システ ムが動作できない状況を含んで、遠隔データ回復オペレーティングを可能とする 手段を提供することである。 本発明の一実施例はデータ回復の方法に関し、該方法は、 データの回復が必要な記憶装置を有するローカル・コンピュータから技術者に よって操作される遠隔データ回復コンピュータへ、通信ハードウェアを介して、 通信線を設ける段階と、 前記技術者の前記ローカル・コンピュータとの相互作用を可能とする一方で、 前記遠隔データ回復コンピュータに常駐するデータ回復プログラムの全てとアク セスする段階と、 の諸段階を含む。 一実施例において、本発明の原理は、遠隔技術者に対して、通信ハードウェア を介しての通信を可能とする充分な機能を有するブート可能な又は立ち上がり可 能なデータ回復オペレーティング・システムを実行することによって達成される 。遠隔技術者は特殊化された遠隔制御ソフトウェアを更に備えており、それがブ ート可能なデータ回復オペレーティング・システムをランしているコンピュータ との通信ハードウェアを介しての通信を可能としている。回復下のコンピュータ 及び遠隔コンピュータがひとたび通信されると、回復下コンピュータ上でのデー タ回復オペレーションは、遠隔技術者の完全な制御の下、進行することができる 。 この好適実施例において、遠隔データ回復オペレーティング・システムはそれ 自体の分配フロッピー・ディスクから直に動作する程に充分に小さく、正規の立 ち上がり可能なオペレーティング・システムが欠如していても該データ回復オペ レーションを進行させることを可能としている。その同一の分配フロッピー・デ ィスクからでも、或は、遠隔技術者のそうしたソフトウェアの膨大なライブラリ からでも、データ回復ユーティリティ・ソフトウェアを通信ハードウェアを介し てロードすることができる。 この好適実施例において、ロードに及んでのそのブート可能な遠隔データ回復 オペレーティング・システムは、そうしたローカル・ユーザに対して制限された 数の選択肢を提示して、ユーザのデータ回復要望やユーザの個人データの実態に 関する情報に対してユーザが入力することを可能としている。この情報がひとた び入力されると、ローカル・ユーザは、取り付けられた通信ハードウェアを介し て遠隔技術者との接触設定を為すオペレーティング・システムを持ちたいとの該 ユーザの意図を確認することができる。この接触又はコンタクトで、直ちにデー タ回復オペレーションを開始することができ、或は代替的に、データ回復オペレ ーションの要求を待ち行列（キュー：ｑｕｅｕｅ）に入れて、データ回復技術者 がその要求を吟味してそのデータ回復オペレーションの準備を為す時間を持つよ うなときに、そのデータ回復オペレーションを進行させることができる。ひとた びデータ回復オペレーションが開始すると、ローカル・コンピュータの全制御が その遠隔データ回復技術者に対して開放される。それで技術者はそのローカル・ コンピュータを操作することができ、それも技術者がそのローカル・コンピュー タの前方に直に着座しているが如くに操作することができ、技術者サイトで利用 可能な全てのデータ回復ユーティリティ・ソフトウェアに対するアクセスをもた らすと共に、データ回復オペレーティング・システム・ディスク上に任意に常駐 し得る全てに対するアクセスをもたらす。 使用に際して、本発明の一実施例を用いたデータ回復はブート可能な遠隔デー タ回復オペレーティング・プログラムをユーザのローカル・コンピュータで立ち 上げるか、或は該ローカル・コンピュータのメモリ内へロードすることによって 進められる。次いで遠隔データ回復オペレーティング・プログラムは、ユーザの ローカル・コンピュータの特定ハードウェア構成を決定又は確定する。次いで遠 隔データ回復オペレーティング・プログラムはユーザに対して該ユーザの名前、 アドレス、電話番号等々を問い合わせることができる。また、ユーザに対してデ ータ回復状況の説明を問い合わせることもできる。更に遠隔データ回復オペレー ティング・プログラムは、通信ハードウェアを介して、遠隔データ回復コンピュ ータとの初期電話リンクを設定して、ユーザによって入力された情報を上記段階 においてダウンロードする。もし時間が許せば、そこで遠隔データ回復コンピュ ータ側の技術者が、その遠隔リンクを介してユーザのコンピュータの制御を為し て、遠隔データ回復プロセスを始める。さもなければ、遠隔データ回復プロセス を追って行う時間の同意を得ることができる。遠隔リンクはそれで終了して、次 いでその同意された時間に再設定され、それに及んで遠隔データ回復が開始され る。 本発明を特徴付ける新規性ある以上の長所及び特徴や、他の様々な長所及び特 徴等は、添付されると共に、この出願の一部を形成している請求の範囲で特に指 摘されている。しかしながら発明のより良好な理解のために、その使用を通じて 獲得されるその長所や達成される目的等は、更に本出願の一部を形成する添付図 面及び記述事項が参照されるべきであり、そこには、本発明の好適実施例が例示 され且つ説明されている。 図面の簡単な説明 対応する参照符号は幾つかの図面を通じて対応するパーツを全般的に指示して いるような図面において、 図１は、本発明の原理に従った装置の一実施例のブロック線図であり、 図２は、本発明の原理に従った装置の他の実施例のブロック線図であり、 図３は、本発明の実施例でのローカル環境のソフトウェア階層線図であり、 図４は、本発明の実施例におけるローカルＲＤＲのフローチャートであり、 図５は、ローカル・コンピュータの遠隔制御オペレーションを促進する、本発 明の実施例におけるローカルＲＤＲの一部のフローチャートであり、 図６は、通信チャネル事象を取り扱う、本発明の実施例におけるロ一カルＲＤ Ｒの一部のフローチャートであり、 図７は、種々雑多な入力データ・パケットを取り扱う、本発明の実施例におけ るローカルＲＤＲの一部のフローチャートであり、 図８は、外に向かう通信データ・パケットを送出する、本発明の実施例におけ るローカルＲＤＲの一部のフローチャートであり、 図９は、ファイルの作成／オープン／クローズ機能のための固有オペレーティ ング・システムＡＰＩの割り込み及び処理を為す、本発明の実施例におけるロー カルＲＤＲの一部のフローチャートであり、 図１０は、ファイルの読取り／書き込み機能のための固有オペレーティング・ システムＡＰＩの割り込み及び処理を為す、本発明の実施例におけるローカルＲ ＤＲの一部のフローチャートであり、 図１１は、表示-スクリーン読取り／書き込み機能のための固有オペレーティ ング・システムＡＰＩの割り込み及び処理を為す、本発明の実施例におけるロー カルＲＤＲの一部のフローチャートであり、 図１２は、本発明の実施例におけるＲＤＲ通信サーバ・アプリケーションのフ ローチャートであり、 図１３は、ローカル・コンピュータのユーザと呼び戻し（コールバック）時間 の交渉を促進する、本発明の実施例におけるＲＤＲ通信サーバ・アプリケーショ ンの一部のフローチャートであり、 図１４は、データ回復診断アプリケーションをローカル・コンピュータにダウ ンロードし、該データ回復診断アプリケーションを該ローカル・コンピュータで 実行させる、本発明の実施例におけるＲＤＲ通信サーバ・アプリケーションの一 部のフローチャートであり、 図１５は、正式合意書をローカル・コンピュータにダウンロードし、合意書リ ーダ・アプリケーションを該ローカル・コンピュータで実行させる、本発明の実 施例におけるＲＤＲ通信サーバ・アプリケーションの一部のフローチャートであ り、 図１６は、ローカル・コンピュータと適切なＲＤＲワークステーションの間で の論理的な接続を設定して、該論理的接続を維持する、本発明の実施例における ＲＤＲ通信サーバ・アプリケーションの一部のフローチャートであり、 図１７は、ローカル・コンピュータからのファイルのオープン／作成／クロー ズ要求パケットを取り扱う、本発明の実施例におけるＲＤＲ通信サーバ・アプリ ケーションの一部のフローチャートであり、 図１８は、ローカル・コンピュータからのファイル書き込み要求データ・パケ ットを取り扱う、本発明の実施例におけるＲＤＲ通信サーバ・アプリケーション の一部のフローチャートであり、 図１９は、ローカル・コンピュータからの種々雑多な要求データ・パケットを 取り扱う、本発明の実施例におけるＲＤＲ通信サーバ・アプリケーションの一部 のフローチャートであり、 図２０は、ＲＤＲワークステーション・コンピュータからのＴＣＰ／ＩＰメッ セージを取り扱う、本発明の実施例におけるＲＤＲ通信サーバ・アプリケーショ ンのその一部のフローチャートであり、 図２１は、本発明の実施例におけるＲＤＲワークステーションのメイン・アプ リケーションのフローチャートであり、 図２２は、ユーザの識別及び現行データ損失状況の実態に関する情報を提供す ると共に所望される対応サービスを提供すべく、ローカル・コンピュータのユー ザが記入できるフォームを表示するコンピュータ・スクリーン又はコンピュータ 画面を図示し、 図２３は、通信サーバを操作管理するために、遠隔データ回復ファシリティの 管理者に対して情報を提供するコンピュータ・スクリーンを図示し、 図２４は、遠隔データ回復ローカル・コンピュータのプログラムからの出力を 制御しモニタすると共に、遠隔データ回復ローカル・コンピュータの実際のスク リーンにおける表示を制御しモニタすることを、遠隔データ回復ワークステーシ ョンのユーザに許容するコンピュータ・スクリーンを図示し、 図２５は、ローカル遠隔データ回復アプリケーションの実施例で利用されるデ ータ構造の各種の説明的な図面を含み、 図２６は、ローカル遠隔データ回復アプリケーションの実施例で利用されるデ ータ構造の説明的な各種図面を含むと共に、遠隔データ回復通信サーバ・アプリ ケーションの実施例で利用されるデータ構造の説明的な各種図面を含む、 図２７は、ローカル・データ記憶装置２６に対して為された任意の変更の「ア ンドゥー(undoing)」機能を実行するローカルＲＤＲアプリケーション３０８内 のＩＯ論理層のフローチャートであり、 図２８は、変更の棄却、新データの実行又は記憶、並びに、オリジナル・デー タの潜在的な回復を促進するログ-ファイルを操作するアプリケーションのフロ ーチャートである。 発明の詳細な説明 次に図面を参照して、データの遠隔回復を為す装置及び方法の実施例が以下説 明される。図１には、本発明の実施例のブロック線図が示されている。ローカル 遠隔データ回復（ＲＤＲ）コンピュータ２０であって、データ回復手続が必要と されているコンピュータ２０が、中央演算処理装置（ＣＰＵ）及びメモリ２１( 典型的には共通システム・ボード上に配列されている)、ローカル入力装置２２ 、ローカル・ディスプレイ２４、ローカル記憶装置２６、並びに、リムーバブル 媒体記憶装置２８を有した状態で示されている。更に、ローカルＲＤＲコンピュ ータ２０は、他のコンピュータとの通信用の、例えばモデム或はネットワーク・ カード等のローカル通信ハードウェア・ユニット３０を有した状態で示されてい る。ローカルＲＤＲコンピュータ２０は任意のＩＢＭ互換システムであってよい し、 或は、ＧＡＴＥＷＡＹ２０００，ＩＢＭ、ＡＰＰＬＥ、Ｈｅｗｌｅｔｔ Ｐａｃ ｋａｒｄ、Ｃｏｍｐａｑ等々の様々なベンダーによって日常的に販売されている 他のタイプのコンピュータ・システムであってよい。特に、ローカルＲＤＲコン ピュータ２０のメイン・システム・ボードには、３８６，４８６，５８６等のＩ ＮＴＥＬ ＣＰＵ、或は、任意の他のマイクロプロセッサを適切量のランダム・ アクセス・メモリ（ＲＡＭ）と共に搭載することができる。ローカル入力装置２ ２は、キーボード、マウス、ポインター、触感スクリーン等々のユーザ入力装置 であってよい。２つ以上のユーザ入力装置２２を設けることもできる。ローカル ・ディスプレイ２４は、視覚的ディスプレイ・ユニット等の任意の適切なディス プレイ装置であってよい。ローカル記憶装置２６は内部的或は外部的であってよ く、様々に変動していく技術を採用することもできる。記憶装置は、ウィンチェ スター技術の従来型のハード・ドライブ、レーザ・ディスク、ＣＤ-ＲＯＭ等々 であってよい。リムーバブル（取り外し自在）媒体記憶装置２８は、従来のフロ ッピー・ドライブや任意の他の適切なリムーバブル媒体ドライブであってよい。 ローカル通信ハードウェア・ユニット３０は、Ｈａｙｅｓ互換モデム等の従来タ イプのモデム装置、ＩＳＤＮモデム、無線モデムであってよいし、或は代替的に は、従来型のローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク 、或は、インターネット（ＬＡＮ／ＷＡＮ／ＩｎｔｅｒＮｅｔ）に接続するネッ トワーク・カード等のハードウェアであってよい。 遠隔データ回復用の遠隔データ回復（ＲＤＲ）ワークステーション４０の実施 例が図１に示され、ＣＰＵ及び関連メモリ４１、遠隔入力装置４２、遠隔ディス プレイ４４、遠隔記憶装置４６、並びに、遠隔リムーバブル媒体記憶装置４８を 有している。ＲＤＲワークステーション４０は、モデム或はネットワーク・カー ド等の遠隔通信ハードウェア・ユニット５０を有するようにも示されている。理 解して頂けるように、ＲＤＲワークステーション４０及びその関連コンポーネン トは上記ローカルＲＤＲコンピュータ２０に対して説明されたものと同一であっ てよい。更に理解して頂けるように、ローカルＲＤＲコンピュータ２０及びＲＤ Ｒワークステーション４０の間のメイン通信チャネル３５は電話線であっても、 成は、従来のＬＡＮ／ＷＡＮ／ＩｎｔｅｒＮｅｔ接続通信チャネルであってもよ い。 図２には、本発明に従ったシステムの更なる他の実施例が図示されている。こ の実施例では、複数のＲＤＲワークステーション４０がローカル・エリア・ネッ トワークによって相互接続されている。図示の実施例において、ファイル・サー バ６０はそれら複数のＲＤＲワークステーション４０をネットワーク６２、より 好ましくはＴＣＰ／ＩＰネットワークによって相互に接続している。ファイル・ サーバ６０は、各種データがＲＤＲワークステーション４０や、通信サーバ６８ によってアクセス可能となるようなネットワーク共有ドライブ６５上に記憶され たデータ６４を有する。複数のＲＤＲワークステーション４０は、選択されたＲ ＤＲワークステーション４０と任意選択のネットワーク通信ハードウェア・ユニ ット６９との間の１つ以上の論理的接続の設定を可能とするように、ＴＣＰ／Ｉ Ｐネットワーク６２を介して通信サーバ６８に対して通信できる。これら複数の ネットワーク通信ハードウェア・ユニット６９は、外部の電話線とモデム接続さ せることができるか、成は、ＬＡＮ／ＷＡＮ／ＩｎｔｅｒＮｅｔとネットワーク ・ハードウェア接続させられることができるか等々が可能である。ネットワーク ・ハードウェア通信ユニット６９は、ＰＢＸ等の通信スイッチ７０を介してロー カルＲＤＲコンピュータ２０との通信を為す。従って、ＲＤＲワークステーショ ン４０の任意の１つを用いてローカルＲＤＲコンピュータ２０から通信チャネル ３５を介してデータを回復することができ、それも他の多数のＲＤＲワークステ ーション４０が異なるローカルＲＤＲコンピュータからデータを回復すべく使用 されているのと同時にである。この実施例は多数の技術者の内の任意の一人に対 してアクセスすることを可能とすべく使用できて、単一の番号のダイヤリングに 及んで或はＬＡＮ／ＷＡＮ／ＩｎｔｅｒＮｅｔ上の単一エンティティー(entity) に接続するに及んで、遠隔データ回復を提供するものである。 この好適実施例において、遠隔データ回復オペレーティング・プログラムはロ ーカルＲＤＲコンピュータ２０の持ち主／購買者に対してフロッピー・ディスク 等のリムーバブル記憶媒体上に提供される。そのプログラムはコンピュータを購 買する際に購買することができ、或は代替的に、後日に小売販路を通じてか或は 郵便注文して購買することができる。更にそれは、通信サーバ６８及びそのネッ トワーク通信ハードウェア・ユニット６９のＢＢＳ様の動作モード（「ゲスト・ モード」）を含む幾つかの電子分配機構を通じて提供され得る。 こうして、遠隔データ回復オペレーティング・プログラムによって提供された プログラムは、ローカルＲＤＲコンピュータ２０を動作させることができると共 に、ローカル通信ハードウェア・ユニット３０を介してＲＤＲワークステーショ ン４０との通信を可能とするに充分な機能を含む。 図３は、遠隔データ回復オペレーティング・プログラムを含む様々なソフトウ ェア・コンポーネントを説明するものである。様々なデータ回復アプリケーショ ン・プログラム３００は、データ回復及び／成は診断プロセスを実行すべく動作 する。そうしたプログラムは、記憶装置機能的診断ルーチン、記憶媒体分析ルー チン、十六進法、ＡＳＣＩＩ、或は、回復下のファイル・システムに関連する他 のフォーマットで作業するセクタ・エディタ、ファイル非消去ルーチン、並びに 、回復下のファイル・システムに関連するファイル・システム完全性検査／修復 ルーチンを含む。これらデータ回復アプリケーション・プログラム３００は、Ｎ ＯＲＴＯＮ ＵＴＩＬＩＴＩＥＳ(米国登録商標)、或は、オントラック社（Ｏｎ ｔｒａｃｋ）のＯＤＲ−Ｎ（米国商標）又はＤＯＳＵＴＩＬＳ（米国登録商標） に見出される各種ルーチンと一般用語において相関している。 データ回復アプリケーションＤＲＡプログラム３００は、ベーシック入力／出 力サブシステム（ＢＩＯＳ）３６０及び／或はオペレーティング・システム３４ ０と直にインターフェース接続する一組の適用業務プログラム・インターフェー ス（ＡＰＩ）３１０を介して、ローカルＲＤＲアプリケーション３０８とインタ ーフェース接続している。ローカルＲＤＲアプリケーション３０８は、ＤＲＡ３ ００の遠隔制御動作を可能とするために、これらＡＰＩを効果的に転送或は「フ ック(hook)」する。更に、ローカルＲＤＲアプリケーション３０８は、プライベ ートＡＰＩを提供して、「通過(pass throught)」を「フックされた(hooked)」 ＢＩＯＳ機能３１６及びＯＳ機能３１４へ提供することによって、「ＲＤＲ自覚 (ａｗａｒｅ)」アプリケーションを通信サブシステム３１２に直にインターフェ ース接続させることを可能としている。これはＲＤＲ自覚アプリケーションに各 種機能の転送を迂回させて、ローカルＲＤＲコンピュータ２０のオペレータに対 す ると共に通信サブシステムの制御に対するインターフェース接続を可能としてい る。ローカルＲＤＲアプリケーション３０８の残りは通信サブシステム・コード ３１８及びローカルＲＤＲアプリケーション・コード３２０を含む。ローカルＲ ＤＲアプリケーション３２０のフローチャートは図４に示されている。 こうしたシステムのソフトウェア・コンポーネントは、ローカルＲＤＲコンピ ュータ・オペレーティング・システム３４０としてデータ回復オペレーティング ・システム（ＤＲＯＳ）３０６を含み得る。このＤＲＯＳ３０６は、ローカルＲ ＤＲコンピュータの固有オペレーティング・システムが機能しない際に遠隔デー タ回復が生ずることを可能としている。ＤＲＯＳ３０６は、ローカルＲＤＲアプ リケーション３０８やデータ回復プロセスを実行するために使用される任意の所 望データ回復アプリケーション・プログラム３００を支援するために必要とされ る各種ルーチンを含む。そうした必要とされるルーチンの例にはメモリ・マネー ジメント、ファイル・システム・アクセス及びマネージメント、アプリケーショ ン・プログラムのローディング及び実行、並びに、周辺装置の制御機能が挙げら れる。これらルーチンは、一般に、ＭＳ−ＤＯＳ割り込み２１Ｈ機能の幾つかと 等しい。ローカルＲＤＲアプリケーション３０８を任意のデータ回復アプリケー ション・プログラム３００に加えて動作させるためには、ＤＲＯＳ３０６は直接 的に固有オペレーティング・システムの呼び出し規約及びプロトコル（通信規約 ）をエミュレート（模倣）する。更には、固有コマンド線インタプリタに類似す るユーザ・コマンド解釈機能が提供されてもよい。ローカルＲＤＲアプリケーシ ョン３０８は、ローカルＲＤＲコンピュータ・オペレーティング・システム３４ ０として固有オペレーティング・システムを用いてランさせてもよい。 ＩＢＭ互換パーソナル・コンピュータの例において、下側に置かれたハードウ ェア３８０に対するインターフェースはベーシック入力／出力サブシステム成は ＢＩＯＳ３６０によって実行される共通インターフェースを介して達成される。 図４のフローチャートはローカルＲＤＲアプリケーション３０８のオペレーシ ョンを説明している。プログラムがステップ４０２に入ると、プライベートＡＰ Ｉ３１２，３１４，３１６がインストールされ、適切なオペレーティング・シス テム及びＢＩＯＳ「フック」がインストールされる。これによって、任意の引き 続きロードされるプログラムが遠隔制御下で動作させられる。ステップ４０４で 、メニューがローカルＲＤＲコンピュータ２０のオペレータに対して提示され、 新ユーザ、既に登録済みユーザ、或は、ローカルＲＤＲアプリケーション３０８ のからの退出の何れかの操作を指定することを可能とされている。 もし新ユーザのオプションが選択されると、ステップ４１０で、ルーチンが発 動（呼出）され、ロ一カルＲＤＲコンピュータのハードウェア構成にアクセスす る。次いでユーザには、ステップ４１２で、ユーザＩＤ(識別)、電話番号等々を 状況の説明及びデータ回復状況の実体と共にフォーム２２１０及び２２２０内に 記入することが要求される。これらフォームが完成すると、ステップ４１４で新 ユーザとして遠隔データ回復ファシリティにダイヤルして該ファシリティとの通 信を設定する試みが為される。 もし（既に）登録済みユーザのオプションが選択されれば、ステップ４２０で 登録済みユーザとして遠隔データ回復ファシリティにダイヤルして該ファシリテ ィとの通信を設定する試みが直ちに為される。 もしステップ４３０で遠隔データ回復ファシリティとの接続の試みが不成功に 終わったと決定されたならば、失敗接続を示す対話（ダイアローグ）がステップ ４４０でローカル・コンピュータのオペレータに対して表示されて、制御がメニ ューへ戻される。 もし遠隔データ回復ファシリティとの接続が成功したとステップ４３０で決定 されると、ステップ４５０で、遠隔サイトの完全な指揮の下、遠隔制御活動が以 下に説明される論理に従って取り扱われる。完了すると、通信セッションがステ ップ４６０で終了され、通信ハードウェアがその通信セッションを終了するよう に指示される。 もし退場（又はＥＸＩＴ）のオプションが選択されると、ステップ４０６で、 ローカルＲＤＲアプリケーション３０８は、プライベートＡＰＩ３１２，３１４ ，３１６と、先行してインストールされたオペレーティング・システム、並びに 、ＢＩＯＳ「フック」を除去する。 図５は遠隔制御オペレーション中に実行するローカルＲＤＲアプリケーション ３０８の一部のフローチャートである。通信パケット受領及びファイル転送制御 を管理支配する重要なデータ構造のステップ５０４での初期化に続いて、ステッ プ５１０乃至５５０では、ローカルＲＤＲアプリケーション３０８がループに入 場する。このループは全ての通信事象をステップ５１０で連続的に取り扱い、遠 隔データ回復ファシリティから送信され得る任意のコマンドを送出する。ステッ プ５２０で、完全な遠隔コマンドが遠隔回復ファシリティから受信されて、ロー カル・キーボード・バッファ内に保存されたならば、ステップ５４０でその遠隔 コマンドがスクリーン上に表され、それがハング-アップ（停止）のコマンドで あるのかを調べる。もしハング-アップ・コマンドが受信されたならば、このル ーチンがステップ５６０で退場する。もしそのコマンドがステップ５４０で決定 されたようにハング-アップ・コマンドでなければ、そのコマンドはステップ５ ５０でオペレーティング・システムの固有コマンド線インタプリタへ通過させら れる。留意すべきことは、ローカル・キーボード・バッファが、好ましくはキー ボードである遠隔入力装置４２で発せられるコマンドで満たされる。もしステッ プ５２０でローカル・キーボード・バッファ内に完全なコマンドがあることが決 定されたならば、不活動性タイムアウトが通信の失敗をステップ５３０で検出し て、適切な退場をステップ５６０で行わせる。遠隔サイトによって指揮された対 応活動は図１２を参照して説明される。 図６に示されるフローチャートは、ローカルＲＤＲアプリケーション３０８内 の通信事象ハンドラー(handler)を説明するものである。通信事象ハンドラーは 、例えばステップ４５０等でのローカル・フック内や、オペレーティング・シス テム及びＢＩＯＳフック内の多数の点から呼び出される。通信事象ハンドラーの 目的は、通信ドライバに役立ち、ステップ６０２乃至６３０での任意の入力パケ ットを送出することである。ステップ６００での通信事象ハンドラーの初期化後 、ルーチンは任意の新キャラクタが受信されたかをステップ６０２で決定する。 もしキャラクタが受信されたならば、そのキャラクタはステップ６０５で受信バ ッファ内に配置され、ステップ６１０で受信バッファ内に完全なデータ・パケッ トがあるかが検査される。もし任意の完全なデータ・パケットが受信バッファ内 にあれば、これらの完全に形成されたパケットはパケット受信制御構造２６１０ のリストと比較される。このリストは単一でリンクされたリストとしてポインタ ・ リンク・フィールド２６１２を介して維持されている。リストが調査又はサーチ されて、符合パケット受信制御構造を見出す。もしパケットのタイプ・フィール ドがパケット受信制御構造２６１０のパケット・タイプ番号フィールド２６１４ と符合すれば、パケット・カウンタ・フィールド２６１６が増分（インクリメン ト）され、パケット・ハンドラー・ルーチン・ポインタ・フィールド２６１８に よって指摘されたルーチンが呼び出される。多数のパケット取り扱いルーチンが 、ステップ７００のファイル作成／オープン或はクローズＡＣＫパケット、ステ ップ７２０のエコー受領、ステップ７３０のスクリーン変化受領、ステップ７４ ０のディスプレイ・データ・パケット、ステップ７５０のキーストローク・パケ ット、ステップ７６０のファイル読取りパケット、並びに、ステップ７７０のエ コー要求を含んで、図７に示されている。しかしながら受信されたパケットがス テップ６２０の決定でもし符合しなければ、そのパケットはステップ６３０で無 視され、ルーチンはステップ６１０で受信バッファ内の完全パケットの調査に戻 される。もし新キャラクタがステップ６０２で何ら受信されなければ、ステップ ６５０で呼出が為され、既に生じているが予め送信させることができなかった何 らかのスクリーン更新に対して、伝送キューに到達する機会が与えられる。加え て、ステップ６５５で、伝送キュー内に外に向かうパケットがあるかを見るべく 決定が為される。ステップ６６０で決定されるようにもし伝送バッファ内に利用 可能なスペース、そして充分なスペースがあれば、ステップ６７０で、外に向か うパケットは通信ドライバの伝送バッファに添付される。伝送キューは、図２５ の２５１０で示されるような外に向かうパケット・ディスクリプタ(descriptor) の単一でリンクされたリストによって実行される。各パケット・ディスクリプタ は、細分長さ２５１２及び細分ポインタ２５１４の対の収集が伴われるリストの 次の要素に対するリンク２５１１を含む。各対は、形成され且つ伝送されるパケ ットを備えることになるメモリの領域を記載している。各種対の収集は２５１６ に示されるゼロの長さフィールドの入力で終了される。これらパケット自体は、 この「収集書込み」を用いて、且つ、ステップ６７０での伝送バッファ内へのデ ータ配置に先行して、作成者が適切であると考えたような他のコード化、フレー ム化、誤差制御方法等のあるもの全てを組み入れることで形成される。 図７は、様々なパケット・タイプを取り扱う場合の、ローカルＲＤＲアプリケ ーション３０８の動作を示す各種フローチャートを含む。 ステップ７００において、ファイル作成受領確認、ファイル・オープン受領確 認、並びに、ファイル・クローズ受領確認パケットが、ファイル作成／オープン ／クローズ動作が遠隔データ回復ファシリティで生ずるように要求すべく送信又 は送出されたこれらパケットに応じて受信され。これらファイル作成／オープン ／クローズ受領確認パケットは、ステップ７０２で、適切なファイル制御構造２ ５２０を単に更新して、その要求が受領確認された旨の事実を反映し且つファイ ル作成／オープン／クローズ動作の状況をポストすることによって取り扱われる 。これによって、受領確認されているファイル作成／オープン／クローズ動作は 進められることが可能となる。 ステップ７１０において、初期ファイル書込み要求に応じてファイル書込み要 求リスト・パケットが受信される。これらファイル書込み要求リスト・パケット は、遠隔データ回復通信サーバが受信すべく準備するそれらファイル・セグメン トを含む。ファイル書込み要求リスト・パケットは、ステップ７１２で、ファイ ル制御構造２５２０を更新することによって取り扱われて、新要求リストに反映 され、引き続き、ステップ７１４で、更新ファイル制御構造２５２０毎にファイ ル書込みデータ・パケットが送信又は送出される。加えて、ファイル制御構造２ ５２０の更新は、ステップ７１６で、タイムアウトをリセットする。ファイル読 取り及び書込みフックは図１０を参照して更に説明される。 エコー受領確認パケットが、ステップ７２０で、エコー要求に応じて受信され る。このエコーのメカニズムは通信診断機能用に提供される。エコー受領確認パ ケットは、ステップ７２２で、データ内容を専用エコー・バッファにコピーする ことによって取り扱われて、プログラムが引き続きエコー・データを更に分析す る。 スクリーン変化受領確認パケットは、ステップ７３０で、スクリーン変化パケ ットに応じて受信される。スクリーン変化受領確認パケットは、ステップ７３２ で、スクリーン変化がもはや伝送中ではないことを選別することによって取り扱 われる。 ディスプレイ・データ・パケットは、ステップ７４０で、ローカルＲＤＲコンピ ュータ・モニタ２４上にテキストを配置するための指示によって受信される。デ ィスプレイ・データ・パケットは、ステップ７４２で、ローカル・ディスプレ２ ４にパケット・データをコピーすることによって取り扱われ、次いで、ステップ ７４４で、表示データ受領確認パケットを送出して遠隔データ回復通信サーバに 対して、パケットはうまく受信されローカル・ディスプレイ２４上に付与された 旨を通知する。 キーストローク・パケットは、ステップ７５０で、ＲＤＲワークステーション ４０でキーストロークが生ずると受信され、ＲＤＲ通信サーバ６８を介して送出 される。キーストローク・パケットは、ステップ７５２で、パケット・キースト ローク情報をローカル・キーボード・バッファへコピーすることによって取り扱 われる。これによって、ローカルＲＤＲアプリケーション３０８がこれらキース トロークを非同期に検索して所望に応じてそれらをインタプリタすることを可能 としている。次いで、キーストロークがローカルＲＤＲコンピュータ２０におけ るオペレーティング・システム或はアプリケーション・プログラムによっての引 き続く解釈のためにローカル・キーボード・バッファ内に保存された後、キース トローク受領確認パケットが、ステップ７５４で戻される。 ファイル読取りデータ・パケットは、ステップ７６０で、ファイル読取り要求 リスト・パケットに応じて受信される。ファイル読取りデータ・パケットはＲＤ Ｒ通信サーバ６８によって読み込まれて送出された実際の遠隔ファイル・データ ・セグメントを含む。ファイル読取りデータ・パケットは、ステップ７６２で、 そのファイル・セグメントは予想されたセグメントの順次連続番号であるかを検 査することによって取り扱われる。もしそうでなければ、ステップ７６６で、校 正読取り要求リスト・パケットが送出される。もし入ってくるパケットがステッ プ７６２で検出されたように予想された連続的なセグメント番号を含んでいれば 、ステップ７６４、そのファイル・データがデータ・バッファにコピーされる。 エコー要求パケットは、ステップ７７０で、通信診断要求として受信される。 そうしたエコー要求パケットは、ステップ７７２で、エコー要求パケットからパ ケット・データをコピーすることを応答され、ステップ７７４でエコー返答パケ ットが送出される。 図８は、ローカルＲＤＲアプリケーション３０８内の通信パケット送信ルーチ ンのフローチャートである。このルーチンは、ステップ８１０で、伝送用パケッ トを伝送キュー内に配置することによって開始する。もしこのルーチン８００を 呼び出すローカルＲＤＲアプリケーション３０８が、ステップ８３０で決定され るように、受領確認（ＡＣＫ）を待機しないを要求したのならば、このルーチン は、ステップ８３５で、通信事象ハンドラーを呼び出し、ステップ６００で、パ ケットは伝送されるべき機会を有する旨を確認し、ステップ８９０での成功状況 を伴って退出する。もしローカルＲＤＲアプリケーション３０８が、ステップ８ ３０で決定されるように、このルーチンは受領確認（ＡＣＫ）を待機すべきと要 求したならば、ステップ８５０でＡＣＫが生じて、ステップ８９０での成功退出 か、或は、ステップ８６０でタイムアウトの決定の何れかまで通信事象を取り扱 うループに入る。タイムアウト状態の場合、パケット伝送及び受領確認待機のシ ーケンスは、ステップ８７０で決定されるように、制限又は限定された回数再試 行（リトライ）される。このリトライ・カウントが出し尽くされた後の失敗は、 ステップ８００での失敗状況退出となる。 図９は、ファイル作成／オープン／クローズ・インターセプタ或は、ローカル ＲＤＲアプリケーション３０８内の「フック」のフローチャートである。この手 続きはインストールされて、任意選択ファイルの作成或はクローズのために、ア プリケーションによる試行を先取りする。このフックの振る舞いは先ず、ステッ プ９１０でファイルは遠隔のファイルか或はローカルのファイルかを決定する。 これは、このルーチンの呼び出し主によって供給されるファイル名、即ち、それ はローカルＲＤＲアプリケーション３０８或はデータ回復アプリケーション３０ ０であるかを、遠隔ファイルを名付けてそれらをローカル・ファイルと容易に識 別できる任意の約定を利用して審査することによってのファイル・オープン／ク ローズ動作中に実行され、そして、ローカルＲＤＲアプリケーション３０８によ って供給されるファイル取り扱いを審査することによってのファイル・クローズ 動作中に実行される。もしファイルがステップ９１０での試験によってローカル であると決定されると、ステップ９１２で、システムの固有ファイル作成／オー プン／クローズ手続きへ実行が転送される。もしファイルがステップ９１０で遠 隔であると決定されると、ステップ９２０で、適切なファイル作成要求、ファイ ル・オープン要求、或は、ファイル・クローズ要求パケットが構築される。次い で、ステップ９３０で、このパケットは送出されて受領確認が待機される。戻さ れて受信された受領確認は、遠隔末端での要求状況を反映しており、それがステ ップ９４０でファイル制御構造２５２０の内容に影響する。次いでこの状況は、 固有システム・ファイルの作成／オープン／クローズの約定毎にローカルＲＤＲ コンピュータ２０のオペレータに戻される。遠隔ファイル作成及び／或はオープ ン活動の場合、ファイル取り扱いは呼び出し主へ戻され、それは、システム固有 ファイル作成或はオープン・プロセスから合法的に戻された任意のファイル取り 扱いと容易に識別される。これは将来の読取り／書込み／クローズ動作がローカ ル・ファイルを遠隔ファイルから識別することを可能としている。 図１０は、ファイル読取り及び書込みインターセプタ、或は、ローカルＲＤＲ アプリケーション３０８内の「フック」のフローチャートである。この手続きは インストールされて、任意のファイルの読取り或は書込みのために、任意のアプ リケーション試行を先取りするものである。このフックの振る舞いは先ず、ステ ップ１０１０で、ファイルが遠隔ファイルか或はローカル・ファイルかを決定す ることである。これはこのルーチンの呼び出し主によって供給されるファイル取 り扱いを、それがローカルＲＤＲアプリケーション３０８或はデータ回復アプリ ケーション３００であることを試験することによって実行される。もしファイル がステップ１０１０での試験でローカルであると決定されると、ステップ１０１ ２で、システムの固有ファイル読取り或は書込み手続きへ実行が転送される。も しファイルが遠隔であると決定されると、ファイル制御構造２５２０はステップ １２０でその要求の実態を反映すべく更新される。ファイル制御構造２５２０の 内容に基づき、適切なファイル読取り要求或は書込み要求パケットがステップ１ ０３０で構築される。次いで、ステップ１０４０でループに入場し、ステップ６ ００での通信事象取り扱いを続行し、読取り或は書込み要求が完全に満足された かをステップ１０５０で試験する。もし要求が満足されたのであれば、成功状況 が、ステップ１０９０で、固有システム・ファイルの読取り／書込み約定毎にそ の呼び出し主へ戻される。ステップ１０５０において、もし要求が完全ではなけ れば、ステップ１０６０でタイムアウト状態がモニタされる。もしタイムアウト が何等生じてなければ、ルーチンはステップ１０４０での通信取り扱いを続行し 、ステップ１０５０での完了要求を求めてモニタされる。ステップ１０６０にお いて、もしタイムアウトが生じてれば、ステップ１０３０で要求が制限されたリ トライ数再送出される。もし、ステップ１０２０でのリトライ・カウントが出し 尽くされれば、その要求を、固有システムのファイル読取り／書込み約定毎に、 ステップ１０９０でファイル失敗を戻す。 ローカルＲＤＲアプリケーション３０８のディスプレイ・スクリーン書込み及 び読取り機能の「フック」に対するフローチャートが図１１に示されいる。提案 されるメカニズムはスクリーン変化を、プログラム実行に対しての最小影響を伴 っての時機を得た状態で、記憶して遠隔サイトに伝送することが意図されている 。スクリーン書込み機能は、ステップ１１１０で、所望のスクリーン書込み情報 を内部バッファ内に先ずコピーすることによって実行され、これはディスプレイ ・スクリーンの状態を完全に記載するものである。このバッファの目的は、ステ ップ１１７０で、スクリーン読取りフックを促進すると共に、スクリーン更新パ ケットが形成され伝送されるとそれらのソースを提供することである。好適実施 例は、ローカルＲＤＲコンピュータ・ディスプレイ２４におけるキャラクタの各 ライン（行）に対してスクリーン・ライン変化ディスクリプタ・データ構造を利 用する。図２５の２５６０で示されるこれらスクリーン・ライン変化ディスクリ プタは、キャラクタの各関連ラインに対して、アプリケーション・プログラムに よって変更又は変えられたキャラクタの複数コラムから成る範囲を記述するもの であり、それら変更されたキャラクタは伝送用にキュー内に未だ配置されていな い。変更されたが未だ送出されていないコラムのこの範囲は、そのラインに対す る「ダーティ(汚濁)」範囲と呼称され、各スクリーン・ラインに対する最初（最 左翼）のダーティ・コラム２５６２及び最後（最右翼）のダーティ・コラム２５ ６４をマークする入力での、スクリーン・ライン変化ディスクリプタ２５６０に よって記述される。ステップ１１１０での、新スクリーン・キャラクタの内部バ ッファに対するコピーに続いて、影響されたディスプレイ・ラインの各々に対す るスク リーン・ライン変化ディスクリプタは変更されて、「ダーティ」範囲がこれら新 書込みコラムを含む旨を確認する。次いで、ステップ１１３０で呼び出しが為さ れて、任意の未送出スクリーン変化を伝送キュー２５１０内に配置してＲＤＲワ ークステーション４０に引き続く伝送を為す。 スクリーン変化記述を遠隔サイトへ送出する試行がステップ１１７０乃至ステ ップ１１７８に記載されている。例えばステップ１１７２で決定されるようにス クリーン変更記述が移動中である理由から、もしそれらが現在送信中であり受領 確認されていなければ、この時にスクリーン変化情報の送信は何等試行されるこ とがない。もしステップ１１７４で決定されるように、未送信変化を表す現行ス クリーン変化記述が存在しなければ、何等行動が執り行われることがない。もし 先行状態が満足されていなければ、非ゼロ・ダーティ範囲を記述する次のスクリ ーン・ライン変化ディスクリプタが利用されて、ステップ１１７８でのエントリ が内部スクリーン・バッファから関連されたダーティ・スクリーン内容を送出す ることになる伝送キューへ迫加される。スクリーン変化は現在「移動中」であり 、関連スクリーン・ライン変化ディスクリプトはクリアできる。このスクリーン ・ライン変化パケットの引き続くの受領確認は受信されると、スクリーン変化は 、ステップ７３０のように、もはや「移動中」ではないと考えられる。タイムア ウトが受領確認なしで生ずれば、スクリーン・ライン変化記述は再伝送されるこ とになる。ディスプレイ・スクリーン読取り機能フックは、ステップ１１８０で 、所望情報を、内部スクリーン訳出バッファから直にローカルＲＤＲコンピュー タ・バッファへコピーすることによって実行される。 本発明の実施例におけるＲＤＲ通信サーバ・アプリケーションを実行するメイ ン・アプリケーションが、図１２のフローチャートに説明されている。典型的に は、各ネットワーク通信ハードウェア・ユニット６９に通ずるアプリケーション は、ステップ１２１０乃至１２８０を実行して始まる。入ってくる電話呼出を受 信するに及んで、ステップ１２１０で、ＡＳＣＩＩプロンプトが伝送されローカ ルＲＤＲコンピュータ２０のオペレータに所望のサービス・タイプを供給するよ うに要求する。これは、従来の「ダム(dumb)」末端アプリケーションによると共 に、ローカルＲＤＲアプリケーション３０８からの高度に自動化された呼出ト ランザクションによって遠隔データ回復通信サーバの使用を可能としている。 ＲＤＲ通信サーバ・アプリケーションがダム末端によって任意のユーザから呼 び出される典型的な状況において、ユーザはステップ１２１０で設定されたプロ ンプト（促し）に「ゲスト」として応答できる。これは、ＲＤＲ通信サーバ・ア プリケーションを、プログラマの独創性やローカルのオペレータ末端アプリケー ションの能力だけで限定される機能を具備した古典的な掲示板サービスとして振 る舞わせることになる。サービスのこの「ゲスト」カテゴリーの有用性は、古典 的なＢＢＳのように、組織体のサービス／産物を宣伝すべく使用可能であること である。更にそれは、ローカルＲＤＲアプリケーション３０８及び関連プログラ ムの分配を可能とするダウンロード・ファシリティとしても使用可能である。 ひとたびローカルＲＤＲアプリケーション・プログラムがローカル・ユーザの 所有となると、ローカル・ユーザはそのアプリケーションをインストールして利 用することによって、ＲＤＲ通信サーバ・アプリケーションからのサービスの「 新ユーザ」カテゴリーにアクセス可能となる。ローカルＲＤＲアプリケーション ３０８はステップ１２１０で設定されたプロンプトや、ＲＤＲ通信サーバ・アプ リケーションによって予想され図４で説明された回答に関して知識がある。 ステップ１２２５で、ＲＤＲ通信サーバ・アプリケーションは、ローカルＲＤ Ｒアプリケーション３０８は、ステップ４０４でのサービスの「新ユーザ」カテ ゴリーを要求しているのかを決定する。ローカル・サイトに提供された、ステッ プ４１０及び４１２における、ハードウェア構成、ユーザ情報、並びに問題説明 を記述するファイルが、遠隔データ回復ファシリティにコピーされて、更なる分 析が行われ、ステップ１２３０で登録済みユーザ・データベースに追加される。 もしそれが遠隔データ回復で現在は進めることができないとステップ１２３４で 決定されると、メニューが提示されて、遠隔データ回復プロセスで進める時間が ステップ１２３８で交渉される。 先行して交渉されたＲＤＲ手続きが始まろうとしている時に、ローカルＲＤＲ アプリケーション３０８は、ステップ１２３５で、ＲＤＲ通信サーバ・アプリケ ーションからサービスの「登録済みユーザ」カテゴリーを要求する。そうした呼 出は、ステップ１２４０で、登録済みユーザ・データベースに対して確証をたて る。非確証呼出は終了される。個々別々の通信接続が設定され、図１２に示され る様々な段階を通るように進展すると、進展の状態は、例えば図２３に示される ような通信チャネル状況ウィンドウ２３１０内の通信サーバ６８のオペレータ・ コンソール上に記述され得る。 もし、ステップ１２３４において、「新ユーザ」サービスがＲＤＲ手続きで直 ちに進められると許容されたならば、或は代替的に、ステップ１２４０での登録 済みユーザの確証成就に及んで、ＲＤＲ診断プロセスがステップ１２５０で実行 される。この診断プロセスは、図１４を参照して詳細に説明される。任意の提案 されたデータ回復サービスの条件を記述する慣習的な法律的合意書が提供されて 、ステップ１２６０で、ローカルＲＤＲコンピュータ２０のオペレータに提示さ れる。この法律的な合意書の伝送及び手続きは、図１５に詳細に説明されている 。ローカルＲＤＲコンピュータ２０のオペレータが、ステップ１２７０で決定さ れるように、その合意書の条件に合意すると、ステップ１２８０で、遠隔データ 回復手続きが実行される。遠隔データ回復手続きは図１６で参照されるように詳 細に説明される。 図１３のフローチャートは、理由が何であろうが、初期電話呼出の後にデータ 回復プロセスが生ずるべきであるとステップ１２３４で決定されると、発動され るＲＤＲ通信サーバ・アプリケーションの一部を記述するフローチャートである 。スケジュールを維持すると共に、ファイル・サーバ６０のネットワーク供給デ ータ記憶装置６４に常駐するファイルがステップ１３１０で読取られる。このフ ァイルは、手元のこの特定データ回復状況の必要性によって、ステップ１３２０ で処理されて、ＲＤＲプロセスを処理するための適切なスケジュール時間のリス トを決定する。回復を実行する見積もり時間としてのそうした要因は、特定の技 術者能力や他の優先要因が用いられて、遠隔データ回復サービスを提供するため の適切時間にこの特注リストを作り出すことができる。ステップ１３３０で、ア プリケーションがローカル・コンピュータで起動され、その特注スケジュール・ リストの視認、そして任意選択で、遠隔データ回復を進めるための相互的に合意 可能な時間の選択を可能としてる。もしそうした時間が、ステップ１３４０で、 選択されたならば、ステップ１３５０でそれがスケジュール・ファイルに追加さ れ る。もしそうした時間がステップ１３４０で選択されなければ、更なるオプショ ンの記述が、ステップ１３６０で、ローカルＲＤＲコンピュータのオペレータに 提示される。ステップ１３６０で提示されたオプションは、従来的なオフ・サイ ト回復のために、遠隔回復ファシリティへの装置の送出、或は、オン・サイトの カテゴリーでのデータ回復サービスの要求を含むことができる。 図１４は、データ回復診断の実行促進を為す遠隔データ回復通信サーバの一部 のフローチャートである。先ず、ステップ１４１０で、ローカル・サイトの分配 媒体に現行バージョンの診断アプリケーションの有効コピーが存在するかの検査 が為される。もしこの診断アプリケーションの有効コピーが存在しなければ、或 は、適切なバージョンの診断アプリケーションがなければ、適切バージョンの診 断アプリケーションを、ステップ１４２０で、ローカル・サイトにダウンロード させる。引き続いて、或は、もし適切な診断アプリケーションがステップ１４１ ０で存在していると決定されたならば、ステップ１４３０で診断アプリケーショ ンがローカル・コンピュータで起動される。診断アプリケーションはデータ回復 状況の診断を為し、ステップ１４４０で、結果を通信サーバ６８でのファイルに 配置して、遠隔技術者及び／或は遠隔データ回復ファシリティでの他のアプリケ ーションでの更なる分析が為される。 図１５は、法的合意書の（意思）表示及びローカルＲＤＲコンピュータ２０の オペレータによる選択的な了承を促進する遠隔データ回復通信ハードウェア・ア プリケーションの一部のフローチャートである。先ず、ステップ１５１０で、現 行バージョンの法的合意書がユーザ・サイトの分配媒体に存在するかを検査する 。もし法的合意書が存在しなければ、或は、適切なバージョンでなければ、ステ ップ１５２０で、適切なバージョンの法的合意書をローカル・サイトにダウンロ ードさせる。ダウンロード１５２０に続いて、或は、適切な法的合意書がステッ プ１５１０でしかるべくあると決定されていれば、ステップ１５３０で、現行日 付及び時間が記入される。合意書リーダ・アプリケーションは、ローカルＲＤＲ コンピュータ２０のオペレータがその法的合意書を調査して、そこに含まれる状 況を選択的に了承することを可能とする。ステップ１５５０で、オペレータによ って了承／辞退の回答が為されて、現行日付及び時間が再度記入される。合意表 示 の日付及び時間と合意書了承の正確な知識を有することは、論争に係る合意書に 関して生じ得る何らかの可能性ある紛争を解決するための関連要因であり得る。 図１６は、遠隔データ回復を実行する遠隔データ回復通信サーバ・アプリケー ションの一部のフローチャートである。このプロセスは、ローカルＲＤＲコンピ ュータ２０を遠隔制御すべく、技術者を動かしＲＤＲワークステーション４０を 動作させることによって達成される。ステップ１６１０で、論理的接続が、遠隔 データ回復手続きの実行に利用可能な任意のＲＤＲワークステーション４０によ ってＴＣＰ／ＩＰを介して形成される。追加的に、ステップ１６２０で、遠隔デ ータ回復のこのセッションのために固有又は独自のサブディレクトリがファイル ・サーバ６０のネットワーク共有データ記憶装置６４に作成される。この固有の サブディレクトリは、ローカルＲＤＲコンピュータ２０のオペレータによって作 成された任意のセッション固有ファイル用の容器であると共に、ＲＤＲ通信サー バ・アプリケーション或はＲＤＲワークステーション４０が作成したい任意のロ グ・ファイルである。ステップ１６４０−１６６０でのループに入ると、ステッ プ１６４０で、ローカルＲＤＲコンピュータ２０からの任意の通信パケットを処 理すると共に、ステップ１６５０で、ＲＤＲワークステーション４０からの任意 のＴＣＰ／ＩＰメッセージを処理する。ステップ１６６０で、もし「ハング-ア ップ」メッセージがＲＤＲワークステーション４０から受信されなかったと決定 されたならば、このループは持続する。最後に、ＲＤＲワークステーションのオ ペレータは、ステップ１６６０で、「ハング-アップ」メッセージを送出させて 、このループを破壊し、ステップ１６７０で、「ハング-アップ」コマンドをロ ーカルＲＤＲコンピュータ２０へ送出させる。 図１７は、ＲＤＲ通信サーバ・アプリケーションの一部のフローチャートであ り、該アプリケーション一部は、遠隔ファイルをネットワーク通信ハードウェア ・ユニット６９を介して、ローカルＲＤＲコンピュータ２０から到着するパケッ トに応答するものであり、オープン、作成、或は、クローズさせることを要求す る。パケットは、０から同時オープン・ファイルの最大数までの範囲内のファイ ル指標と、この要求をファイル指標の独特な使用として識別すべく利用される一 連番号とを含む。それ故に、ファイル指標及び連続番号（又は一連番号）の組合 せを 利用して、これは独特な要求であるのか、或は、これは通信チャネル３５でのエ ラーによって失われた受領確認を求める要求の再試行であるのかを決定すること ができる。もし、ステップ１７２０で、これは先行する要求の繰り返しではない と決定されたならば、ステップ１７２０で、パケットの残り毎にファイルのオー プン／作成／クローズが為される。もし、ステップ１７１０で、この要求は事実 上の繰り返し要求であれば、ファイルの実際的なオープン／作成／クローズは迂 回される。もし、ステップ１７３０で、オープン／作成／クローズ要求がうまく いかなければ、ステップ１７６０で、失敗受領確認が伝送される。代替的には、 ステップ１７３０での決定で、オープン／作成／クローズ要求は成功であれば、 ステップ１７４０で、ファイル接続データ構造が、オープン／作成／クローズ要 求パケット毎に、遠隔データ回復通信サーバ内で初期化され、成功受領確認がス テップ１７５０で送出される。 図１８は、ＲＤＲ通信サーバ・アプリケーションの一部のフローチャートであ り、該アプリケーション一部は、ネットワーク通信ハードウェア・ユニット６９ を介してローカルＲＤＲコンピュータ２０から到着するパケットに応答するもの であり、ファイル書込み活動を要求する。受信された第１パケットは書込みファ イル初期化パケットであり、ステップ１８１０で、それは先行して受信された要 求の再試行であるのかを見るべく、そのファイル上の最後の活動の連続番号又は 一連番号が検査される。もし、ステップ１８１０で、これが再試行ではないと決 定されたならば、活動に対するメモリの割り当てと共に初期ファイル制御構造２ ６２０の準備を含む初期化がステップ１８５０で実行される。もし、ステップ１ ８１０で、再試行であると決定されたならば、初期化は既に実行されているが、 通信エラーによって受領確認が失われ、それで初期化がスキップされる。何れの 場合にも、フローは図１８の点Ａへ進み、ファイル書込みパケットに対してどの ように応答すべきかを決定するアルゴリズムの始まりである。ステップ１８６０ で、全ての書込みデータは受信されて書込みファイル初期化パケット全体は満足 したかを決定する検査が為される。もし全てのデータが受信されたならば、ステ ップ１８６５で、メモリ・バッファに残存する任意のデータは実際にファイルに 書き込まれる。ステップ１８５０で割り当てられたメモリがステップで１８６５ で割当解除され、ステップ１８８０でヌル要求リストが送出されて、ファイル書 込みの完了を示す。もし、ステップ１８６０での検査中、受信されるべき更なる ファイル・データがあると決定されたならば、適切な書込み要求パケットが公式 化されてステップ１８９０で送出される。この要求リストは、データが未だ受信 されていない場合や、現行、未書込みデータを現行含まない利用可能なバッファ ・スペースがある場合等のためのファイル・データ・セグメントを要求するもの である。 ファイル書込みデータ要求に応じてファイル書込みデータ・パケットが到着す ると、ステップ１８１５で、パケットにおける一連番号に基づきこれは再試行で あるか否かについての決定が為される。もし再試行であれば、処理は点Ａまで続 行する。もし再試行であるとの決定が為されなければ、ステップ１８２０で、パ ケット・データはステップ１８５０で割り当てられたバッファにコピーされる。 もし、ステップ１８２５で、そのセグメント番号が適切な一連であると決定され なければ、ステップ１８４５で、要求リストは調整されて、受信されなかった任 意のセグメントの再要求を為す。もし、ステップ１８２５で、通信エラーの欠如 の場合のように、セグメントが一連番号であると決定されたならば、ステップ１ ８３０でファイル書込み活動が現行執り行われているかが審査される。もしファ イル書込み活動がなければ、ステップ１８３５でファイル書込みが、未書込みフ ァイル・データを含むデータ・バッファに対して始動される。要求リストはステ ップ１８４０で調整されて、これまで受信されたファイル・セグメントを考慮す ると共に、更にデータを受け入れるべく現在空いている任意のファイル・データ ・バッファを考慮する。次いで処理は点Ａへ連続する。 図１９は、ＲＤＲ通信サーバ・アプリケーションの実施例に存在する様々なパ ケット・ハンドラーを記述するものである。ステップ１９００で始まるルーチン 内で、オリジナルのエコー要求パケット内である任意の選択的なエコー・データ のコピーを含むエコー受領確認パケットを送出することによって、エコー要求パ ケットが取り扱われる。ファイル読取り要求リスト・パケットはファイルの複数 セグメントのリストを含み、ローカル・ユーザはデータ受信の準備が為される。 これらファイル読取り要求リスト・パケットはステップ１９１０で始動するルー チンで、ステップ１９２０での実際の読取りを実行することによって、そして、 ステップ１９３０でファイル読取りデータ・パケットの形態でのデータを送出す ることによって取り扱われる。ステップ１９３９で始動するルーチンによって取 り扱われるスクリーン変化パケットは、ステップ１９４０で検査されてそれらが 既に処理されたパケットの再試行であるかが見られる。この検査は、他のパケッ トのように、パケット内に含まれる連続番号によって実行される。もし、ステッ プ１９４０で、パケットが再試行であると決定されなければ、ステップ１９５０ で、ＴＣＰ／ＩＰ接続を介して遠隔データ回復ワークステーションへ送出するこ とによって処理される。この行動に続いて、或は、パケットが再試行である決定 されたならば、ステップ１９６０で、スクリーン変化受領確認パケットがＲＤＲ コンピュータ２０へ送出される。 図２０は、遠隔データ回復ワークステーション接続をモニタするためのＲＤＲ 通信サーバ・アプリケーション内で連続的に動作するステップ２００２−２００ ８での実行の筋道と、ＲＤＲワークステーション４０が活動的に遠隔データ回復 動作に関わっている間、それらからメッセージを連続的に取り扱う実行の筋道と を表すフローチャートである。 ステップ２００２−２００８での接続モニタ筋道は、システムにおける全ＲＤ Ｒワークステーション４０に知られたＴＣＰ／ＩＰボートをモニタする。ＲＤＲ 通信サーバ・アプリケーションは、ステップ２００２で、任意のＲＤＲワークス テーション４０がＴＣＰ／ＩＰ接続を設定することを待機している。それ故に、 ＲＤＲワークステーション・アプリケーションを起動している任意のＲＤＲワー クステーション４０は、図２１で追って議論されるように、このポートを介して 論理的接続を設定する。ひとたびＴＣＰ／ＩＰ接続がこのポートに設定されれば 、ステップ２００６で、他の実行の筋道が生まれ、それがＲＤＲワークステーシ ョン４０からのメッセージを取り扱う。こうして接続されたＲＤＲワークステー ション４０は、ステップ２００８で、遠隔データ回復サービスの処理ができると して留意される。ステップ２００８で留意されたＲＤＲワークステーション接続 は、図２３に示されるワークステーション状況ウィンドウ２３２０における通信 サーバ６８のオペレータ・コンソール上に記述され得る。 ステップ２０１０−２０７５の筋道は、ＴＣＰ／ＩＰ接続の結果としてステッ プ２００６で生まれ、ＲＤＲワークステーション４０によって送出された全ＴＣ ＰＣ／ＩＰメッセージを取り扱う責務がある。ＲＤＲ通信サーバ・アプリケーシ ョン内には、この種類とは分離した筋道が、現行下、遠隔データ回復サービスの 潜在的なプロバイダーとして設定されている全ＲＤＲワークステーション４０に 対して存在する。ＲＤＲワークステーション４０のオペレータが遠隔データ回復 の実行における活動を行うと、これら筋道はメッセージを受信し始める。 特定のＴＣＰ／ＩＰメッセージは、これらメッセージを通信ハードウェア上の 様々なパケットを介してローカルＲＤＲコンピュータ２０へ送出することによっ て取り扱われる。キーストロークを表すＴＣＰ／ＩＰがステップ２０２０で検出 されると、ステップ２０２５でキーストローク・パケットとしてローカルＲＤＲ コンピュータ２０へ送出される。ディスプレイ・メッセージを表すＴＣＰ／ＩＰ メッセージがステップ２０３０で検出されると、ステップ２０３５でディスプレ イ・データ・メッセージとしてローカルＲＤＲコンピュータ２０へ送出される。 「ハング-アップ」ＴＣＰ／ＩＰメッセージがステップ２０４０で検出されると 、ステップ２０４５でローカルＲＤＲコンピュータ２０へ送出されて電話接続を ハング-アップ（停止）させる。残りのＴＣＰ／ＩＰメッセージ・タイプは「ロ グアウト(LOGOUT)」メッセージであり、ＲＤＲワークステーション・アプリケー ションから退出するＲＤＲワークステーション・オペレータの結果として生ずる 。「ログアウト」メッセージがステップ２０５０で検出されると、ステップ２０ ７５で、ＲＤＲ通信サーバ・アプリケーションに対して、このＲＤＲワークステ ーション４０がもはや遠隔データ回復サービスを処理する用意がないことを留意 させる。次いで、ステップ２０８０で、ＴＣＰ／ＩＰ接続は閉じられて、実行の この筋道は終了する。 図２１は、ＲＤＲワークステーション４０を制御するアプリケーションの全体 的な動作を表すフローチャートである。ステップ２１００でのＲＤＲワークステ ーション・アプリケーションの発動に及んで、ステップ２１１０で論理的接続が 、ＲＤＲ通信サーバ６８上の予め決定され固定されたＴＣＰ／ＩＰポートを介し てＲＤＲ通信サーバ・アプリケーションに対して設定される。次いで、ステップ ２ １１５−２１２０で、ワークステーション・オペレータがステップ２１１５でア プリケーションが退出することを要求するまでか、或は、ステップ２１２０で、 ＲＤＲ通信サーバ・アプリケーションからの遠隔データ回復セッションの始動を 要求するＴＣＰ／ＩＰメッセージが到着するまでかの何れかまで待機するループ に入る。通信サーバ６８は、ステップ１６１０での遠隔データ回復セッションを 始動する旨のＴＣＰ／ＩＰ要求を発する。この要求１６１０はステップ２１２０ でＲＤＲワークステーション４０によって検出され、ウィンドウ２４１０，２４ ２０及びコントロール２４３０，２４４０の集まりは、図２４に図示されるよう に、ＲＤＲワークステーション・コンソール４４上に描かれる。 マクロ制御ボタン２４３０が設けられて、「マクロ」能力が許容されて、任意 の個別のボタンの起動が多重的な、予め構成されたキーストロークと同様のもの を発するように為されている。状況制御ボタン２４４０が設けられて、ＲＤＲロ ーカル・コンピュータ・コンソール２４上のディスプレイに対して、状況メッセ ージを指定する能力を許容している。 ステップ２１３０で、ステップ１１７０でのローカルＲＤＲコンピュータ２０ によって送出された任意のスクリーン更新メッセージが、ステップ１９５０で引 き続き通信サーバ６８によって送出されて、ＴＣＰ／ＩＰを介して受信されてウ ィンドウ２４１０上に付与される。こうしてウィンドウ２４１０は、ローカルＲ ＤＲコンピュータ２０で動作しているそれらデータ回復アプリケーション・プロ グラム３００が実行する全スクリーン活動を示す。 ステップ２１３５で、ＲＤＲワークステーション・キーボード４２からの任意 のキーストロークは、ステップ２０２０，２０２５においてキーストローク・パ ケットとしてローカルＲＤＲコンピュータ２０へ送出するためにＴＣＰ／ＩＰを 介して通信サーバ６８へ送出される。これらキーストローク・パケットは、図７ におけるステップ７５０及び７５５で示されるように、ローカルＲＤＲコンピュ ータ２０によって受信されて、ＲＤＲワークステーション４０のオペレータがロ ーカルＲＤＲコンピュータ２０で動作しているデータ回復アプリケーション・プ ログラム３００を制御することを可能としている。 ステップ２１４０で、制御ボタン２４４０の起動を介して指定された任意のデ ィスプレイ・データ・メッセージは、ステップ２０３０，２０３５においてディ スプレイ・データ・パケットとしてローカルＲＤＲコンピュータ２０へ送出する ために、ＴＣＰ／ＩＰを介して通信サーバ６８へ送出される。ローカルＲＤＲコ ンピュータ２０はこれらパケットをステップ７４２でローカル・スクリーンへコ ピーすることによって、これらパケットを取り扱う。追加的にステップ２１４０ で、これらディスプレイ・データ・メッセージはウィンドウ２４２０上に付与さ れて、ウィンドウ２４２０がローカルＲＤＲコンピュータ・コンソール２４の表 情の正確な表示を維持する。 ステップ２１５０で、セッションが完了との決定が為されると、「ハング-ア ップ」メッセージが通信サーバ６８へ送出されて、ウィンドウ２４１０及び２４ ２０及びコントロール２４３０及び２４４０がステップ２１５５でクリアされる 。 図２２は、ローカル・ディスプレイ２４上に表示されるフォームを表すコンピ ュータ・スクリーンの各種描写を含み、ローカルＲＤＲコンピュータ２のユーザ がそのフォームに記入できて、該ユーザの識別、現行データ損失状況の実態、並 びに、所望の対応サービスに関しての情報を提供する。ユーザ識別及び他の関連 情報はフォーム２２１０によって明らかにされる。データ損失の適切な診断に関 連する情報や、所望サービスの記述に関連する情報はユーザが記入するフォーム ２２２０によって明らかとされる。 図２３は、通信サーバ・アプリケーションによって表示されるコンピュータ・ スクリーンの各種描写を含み、遠隔データ回復ファシリティの管理者に通信サー バ６８を管理させている。通信チャネル状況ウィンドウ２３１０は、構築された ＬＡＮ通信チャネル６６の各々の状況のモニタを促進すべく提供されている。各 ＬＡＮ通信チャネル６６は、待機モード、ゲスト・モード、新ユーザ・モード、 アクティブ・データ回復モードの何れであってよく、或、オフ-ラインであって もよい。追加的なコントロールが提供されてもよく、個別ＬＡＮ通信チャネル６ ６或は全体としての通信サーバ６８のメンテナンス及びコンフィギュレーション を促進する。追加的に、ワークステーション状況ウィンドウ２３２０が提供され て、通信サーバ６８に対してＴＣＰ／ＩＰ接続を設定した遠隔データ回復ワーク ステーション４０のモニタや、それら遠隔データ回復ワークステーション４０ で行われている現行活動状態についての指示を可能としている。 図２４は、ＲＤＲワークステーション・ディスプレイ４４上に表示可能なコン ピュータ・スクリーンの各種描写を含む。これらスクリーンは、ＲＤＲワークス テーション４０のユーザが、ローカルＲＤＲコンピュータ２０のプログラムから の出力を制御すると共にモニタすること、並びに、ローカルＲＤＲコンピュータ ・ディスプレイ２４の実際のスクリーンの映像を制御すると共にモニタすること を可能としている。ローカル・プログラム出力ウィンドウ２４１０は全ＲＤＲア プリケーション３００の出力としてのディスプレイである。この出力で、ＲＤＲ ワークステーション４０のオペレータが、ローカルＲＤＲコンピュータ２０上で ランしているアプリケーションをモニタすることができる。マクロ制御ボタン２ ４３０は、ＲＤＲワークステーション４０のオペレータが、頻繁に使用されるキ ーストロークのシーケンスをローカルＲＤＲコンピュータ２０へ送出する方法を 提供している。状況制御ボタン２４４０の使用は、ＲＤＲワークステーション４ ０のオペレータが、予め構成された状況或は特定（カスタム）状況のメッセージ をローカルＲＤＲコンピュータ・ディスプレイ２４上に表示させることを可能と している。実ローカル・ディスプレイ・ウィンドウ２４２０は、ローカル・コン ピュータ・ディスプレイ２４の内容を追従するディスプレイである。これは、Ｒ ＤＲワークステーション４０のオペレータに、表示された状況メッセージの知識 を維持させることを可能としている。 図２５は、ローカルＲＤＲアプリケーション３００の実施例で利用されたデー タ構造の模式図を含む。略図２５１０は外に向かうパケット・ディスクリプタ（ ＯＰＤ）データ構造を記述している。このＯＰＤ２５１０と、リンク・リスト・ ポインタ２５１１を介してリンクされている任意ＯＰＤとは、ローカルＲＤＲア プリケーション３０８の通信サブシステム・コード３１８内の伝送キューを備え る。このデータ構造の残りは細分長フィールド２５１２及び細分長フィールド２ ５１４の複数対から成る。細分長フィールド２５１２及び細分長フィールド２５ １４のそうした対の数は、ゼロ細分長フィールドを伴う対が、そこで対リストが 終了する２５１６に遭遇されるまで存在し得る。各対は外に向かうパケットの一 部を備えるメモリの一領域を記述している。これは古典的な「集中出力又はギャ ザ・ ライト(gather write)」アプローチであり、メモリの広範に分離された複数領域 から収集すべく外に向かうパケットの様々な部分の収集を可能としている。 略図２５２０はローカル・ファイル制御構造（ローカルＦＣＳ）を図示してい る。１つのそうしたローカルＦＣＳ２５２０は、ローカル遠隔データ回復アプリ ケーション３０８内のオープン状態の遠隔ファイルの可能性ある同時併発的な例 毎に存在する。このデータ構造使用の更なる洞察は図７、図９、並びに、図１０ のフローチャートと共に、それらフローチャートに関連された詳細な説明を参照 することによって得ることができる。ローカルＦＣＳ２５２０は、ファイルの現 行状態、例えば、現行オープン状態、現行クローズ状態、或は、通信が生じての 何らかの中間状態等々を表す状況フィールド２５２２を含む。連続番号フィール ド２５２２は、遠隔ファイルの読取り、書込み、オープン、作成、或は、クロー ズの試行毎に、処理通信に先行して変更される。それとして、遠隔データ回復通 信サーバ６８はそうした要求が新要求であるのか、或は、応答が通信エラーによ って失われた故での要求の再試行であるのかを決定することができる。再試行は 要求毎に再試行カウント・フィールド２５２６でカウントされて、限定された数 の再試行をオペレーションが立消えになる前に試すことができる。現行ファイル ポインタ・フィールド２５２８が利用されて、ストリーム・オペレーションに対 して使用されるようにファイル内のオフセットの記録を維持する。通信エラーに よって失われる要求或受領確認を保護するために、タイムアウト・フィールド２ ５３０が存在して、要求とその要求に対する応答との間に充分な実時間が経過し たかを決定することが可能としている。充分な時間が経過すれば常に、要求か或 はその要求に対する応答かが喪失されたと想定される。 ファイル読取り動作中、読取り要求リスト・パケットが送出されて、所望され ているがまだ受信されていないようなファイル・セグメントを要求する。ファイ ルはセグメントと呼称される量単位に基づき転送され、該セグメントはファイル の固定サイズの細分である。任意のファイル・データ転送パケットはせいぜい１ セグメントを含む。セグメントの固定サイズはプログラマによって予め決定され 、計算の都合やファイル・システム性能に基づくと共に、結果としてのパケット ・サイズが考慮されている。要求リストは、受信すべく次のセグメント２５３２ に 同等な初期セグメント値によって作成され、フィールド２５３４に受信すべく残 存された合計セグメントを氾濫させることなしに、できる限り多くの連続するセ グメントを要求するものである。シーケンスから受信されたセグメントは廃棄さ れ、直ちに校正読取り要求リストが作成させて、図７のステップ７６６において 伝送キュー内に配置させられる。また、タイムアウト条件は校正読取り要求リス トを作成させて、図１０のステップ１０３０において伝送キュー内に配置させら れる。 ファイル書込み動作中、書込み初期化パケットが送出され、該パケットは始動 セグメント番号及び合計バイト・カウントを含む。このパケットは通信サーバ６ ８が該通信サーバのバッファリングに伴ってファイル・セグメントを要求させる ことができ、Ｉ／Ｏサブシステムはファイル・セグメントを受信する用意ができ る。通信サーバ６８は、図７のステップ７１２で処理されるファイル書込み要求 リスト・パケットを送出することによってファイル・セグメントのそうした要求 を為す。データ構造フィールドの要求された第１セグメント２５３６及び要求さ れたセグメント・カウント２５３８はファイル書込み要求リスト・パケットから 直に採られる。送出すべき次のセグメントのフィールド２５４０が利用されて、 どのファイル・セグメントをキュー内に配置し始めるのかを決定する。送出すべ き次のセグメントが要求された第１セグメント及び要求されたセグメント・カウ ントによって記述されている範囲内である限り、送出すべき次のセグメント２５ ４０及び要求されるべき第１セグメント２５３６の間の如何なる差も移動中であ るパケットによる。ヌル要求を伴うファイル書込み要求リスト・パケットの受領 はファイル書込み動作の成功完了として解釈される。 略図２５６０は、トラックを保持すべく使用されたスクリーン・ライン変化デ ィスクリプタ(ＳＬＣＤ)・データ構造を説明しており、そのトラックの、ＲＤＲ アプリケーション３００によって書き込まれる仮想スクリーンの複数部分は、Ｒ ＤＲ通信サーバ６８に未だ首尾よく伝送されていなかったものである。このＳＬ ＣＤ内には一対のフィールド、即ち、スクリーン上のキャラクタの各ラインに対 して最初のダーティ・コラム２５６２及び最後のダーティ・コラム２５６４が存 在している。このフィールド対は変更されているが未だ伝送されていないデー タを含むコラムのいっさいを含めた範囲を記述している。 図２６は、ローカルＲＤＲアプリケーション３０８の実施例に利用される更な るデータ構造の模式図と共に、ＲＤＲ通信サーバ・アプリケーションの実施例に 利用されるデータ構造の模式図とを含む。 図２６の２６１０で記述されるデータ構造はパケット受信制御（ＰＲＣ）構造 である。このＰＲＣはＲＤＲローカル・アプリケーション３０８によって利用さ れて入力パケットをデコードし、統計を維持し、そして制御を図７のルーチンへ 転送し、入ってくるパケットの各特定タイプを取り扱う責務がある。次のパケッ ト受信構造に対するポインタのフィールド２６１２が利用されて、そうした構造 を古典的な単一でリンクされたリストの形態の収集を維持している。パケット・ タイプ番号のフィールド２６１４は入ってくるパケットのタイプ・フィールドと 符合させて、このパケットがこのＰＲＣ或は引き続くＰＲＣに従って取り扱われ るべきかを決定する。もしパケット・タイプ番号フィールドが入ってくるパケッ トのタイプ・フィールドと同等であれば、パケット・カウンタのフィールド２６ １６は増分されて統計を維持し、パケット・ハンドラー・ルーチンを指すポイン タのフィールド２６１８によってポインタが付けられたソフトウェア・ルーチン は呼び出されて、入ってくるパケットの処理を取り扱う。 データ構造２６２０はＲＤＲ通信サーバ６８内で利用されるようにファイル制 御構造（ＦＣＳ）である。１つのサーバＦＣＳ２６２０は、ＲＤＲ通信サーバ・ アプリケーション内のオープンされた遠隔ファイルの潜在的に同時併発する例毎 に存在する。このデータ構造の使用の更なる洞察は、図１８及び図１９のフロー チャートを参照すると共に、それらのフローチャートに関連された詳細な説明を 参照することによって得ることができる。サーバＦＣＳ２６２０は状況フィール ド２６２２を含み、それはファイルの現行状態、例えば、現行オープン状態、現 行クローズ状態、或は、通信が生じての何らかの中間状態等々を表す。最後の連 続番号のフィールド２６２４は、遠隔ファイルの読込み、書込み、オープン、作 成、或は、クローズの試行毎に検査される。それとして、ＲＤＲ通信サーバ・ア プリケーションはそうした要求が新要求であるのか、或は、応答が通信エラーに よって失われた故での要求の再試行であるのかを決定することができる。再試行 は要求毎に再試行カウント・フィールド２６２６でカウントされて、限定された 数の再試行をオペレーションが立消えになる前に試すことができる。通信エラー によって失われる要求或は受領確認を保護するために、タイムアウト・フィール ド２６３０が存在して、要求とその要求に対する応答との間に充分な実時間が経 過したかを決定することが可能としている。充分な時間が経過すれば常に、要求 か或はその要求に対する応答かが喪失されたと想定される。ファイルが作成され るか、オープンされるかすると、実ファイル・ハンドル・フィールド２６３６が 用いられて、システムによって利用される実ファイル・ハンドルを保持されて、 このファイルを将来の読取り、書込み、或は、クローズの要求に参照する。 ファイル読取り動作中、読取り要求リスト・パケットはその要求リストで指定 されているような実ファイル読取りを単に実行し、続いてその要求されたファイ ル・データをファイル読取りデータ・パケットとして送出することによって応答 される。ファイル読取りデータ・パケットが送出されている間、読取り要求リス ト・パケットが到着すると、読取りデータは止められ、新読取り要求リストが受 け入れられる。読取り動作中、ＦＣＳデータ構造の関連フィールドは、現行ファ イル・ポインタ２６２８、要求された第１セグメント２６３２、要求されたセグ メント・カウントである。これらフィールドは読取り要求リスト・パケットの内 容から記入され、関連されたファイル読取りデータ・パケットが伝送されるよう に調整される。 ファイル書込み動作中、書込みファイル初期化パケットが受信されて意図され た書込み動作を画成する。書込みファイル初期化パケットは、現行ファイル・ポ インタ２６２８、要求された第１セグメント２６３２，並びに、要求されたセグ メント・カウント２６３４のサーバＦＣＳ２６２０における各種フィールドの情 報を提供する。迫加的に、メモリは要求毎にシステム・リソースの利用状況を考 慮して割り当てられる。自由セグメント・バッファの数のフィールド２６３６、 セグメントの合計数のフィールド２６４０、並びに、セグメント・バッファに対 するポインタ２６４２が設定されて、割り当てられたセグメント数及びそれらの メモリ箇所に反映される。書込みファイル・データ・パケットが到着すると、そ れは利用可能なバッファに配置されて、ファイルへの書込みのためのスケジュー ルが組まれる。ファイル・セグメントの到着は自由セグメント・バッファ数２６ ３８を減分することになり、またそれらセグメントの上首尾な書込みは自由セグ メント・バッファ数２６３８を増分することになる。ファイル書込み要求リスト ・パケットはセグメント数の始動として要求された第１セグメントのフィールド ２６３２を利用して公式化され、要求されたセグメントの数は、自由セグメント ・バッファ数２６３８のフィールド、或は要求されたセグメント・カウント２６ ３４のフィールの何れかによって制限される。要求された第１セグメント２６３ ２及び要求されたセグメント・カウント２６３４の各フィールドは、ファイル・ データ・パケットの到着にで、それぞれ増分及び減分されて、それは受信が維持 され続けるファイル・データの正確な記述を維持する。 理解して頂けるように、本発明は、上述した実施例の多数の変形を受け入れる ことができる。本発明の原理は、データ記憶装置の診断及び／或はデータ回復を 遠隔データ回復コンピュータによって可能とするものである。幾つかの場合、ユ ーザが実際の回復に進行することを選択しない可能性があるので、診断のみが遠 隔的に実行される。また幾つかの場合、回復がローカル・コンピュータにおいて 実行されて、回復されたデータがローカル・ユーザの記憶装置２６に再記憶され る。多くの場合、データはＲＤＲネットワーク共有ドライブ６５にダウンロード させることが可能であり、新しい記憶媒体に再記憶及び保存させて、それからそ の記憶媒体をユーザへ送出するか、或は、ユーザが取りに行くかすることができ る。幾つかの場合、損傷されたデータはＲＤＲネットワーク供給ドライブ６５に ダウンロードさせることができ、再記憶させ、それからアップロードしてローカ ルＲＤＲコンピュータ２０へ戻す。理解して頂けるように、これらは、本発明の 原理の下、生じ得る多くのシナリオの内の幾つかである。 ご理解できるように、チャット・カンバセーション、法的合意書の了承、使用 されるデータ回復アプリケーション等々を含む注目すべき事象の自動的で詳細な ロギング(logging)は、ビジネス・トレンドの分析に価値があり、時々引き起こ される係争に対する参照資料として価値がある。それ故に、ＲＤＲの好適実施例 は以下のような事象をロギングする手段を含む。 １）接続始動：日付／時間、クライアントのジョブＩＤ及び電話番号、通信チャ ネルのタイプ及び速度； ２）データ回復診断／アプリケーション・プログラムの始動及び停止の日付／時 間と共に、そのプログラムからの報告； ３）全てのチャット或はカンバセーション(双方向)； ４）提出された全ての法的合意書、その合意書に対するクライアントの応答、全 ての添付物或は補充物； ５）変更された全データ・セクタの完全な記録及びそれらの先行状態、そして ６）接続終了日付／時間。 ご理解できるように、データ回復の実行は、その回復プロセスの続行に伴って 、不正確になると判明され得る仮説の要請を含むことができる。それ故に、ロー カル記憶装置２６に対して実行された変更を「アンドゥー(undo)」する能力を可 能とすることが望ましく、例えば、そうした変更が正しくない仮定に基づいて続 けて決定された場合のため、さもなければ不適切であった場合のためである。好 適実施例において、ＲＤＲワークステーションのオペレータが続行を決定すると きまで、或は、代替的にその変更を放棄するときまで、ローカル記憶装置に対す る全ての変更を延期するようなメカニズムが設けられている。もし変更を行うと の決定が為されたならば、変更されるとのマークが為された全データを先ず記憶 保管のためにＲＤＲファシリティに転送する。その後にだけ、新データがそのロ ーカル記憶装置２６に実際に書き込まれる。そうしたメカニズムを実行するこの 好適な方法はファイルを伴い、それはそのローカル記憶装置２６に対して実行さ れることになる全書込み活動を記憶するものである。そのファイルは遠隔データ 回復サイトでのネットワークに取り付けられた記憶装置６５に常駐する。そのフ ァイル内の各エントリは、固有セクタと代表されるローカル記憶装置とを識別す る識別子と共に、そのセクタに書き込まれた最新データを含む。それは「書込み -キャッシュ」であることが効果的である。 図２７は、ローカル・データ記憶装置２６に対して為される変更を「アンドゥ ー」する能力を実行するローカルＲＤＲアプリケーション３０８内の１０論理層 のフローチャートである。ローカル記憶装置２６に対して書き込まれる全試行は 、２７１０のこのＩＯ論理層に入る。もし要求されたセクタ（又は複数のセクタ ） が先行して書込まれていれば、ログ-ファイルに何等エントリが存在しない。も しこの状態が２７２０で検出されたならば、ログ-ファイル・エントリは２７３ ０で追加され、そして、２７３５で書込まれるべきデータがそのログ-ファイル ・エントリに書込まれる。もし２７２０で要求されたセクタ（又は複数のセクタ ）が先行して書込まれていると検出されたならば、存在するログ-ファイル・エ ントリは２７４０で書込まれるべき新データで更新される。それ故に、このログ -ファイルにはエントリと、データ回復セッション中に書込まれたセクタ毎に対 する新データとが存在する。ローカル記憶装置２６を読取る全試行は、２７５０ のこのＩＯ層に入る。もし、２７６０で、要求されたセクタ（又は複数のセクタ ）がログ-ファイルに存在しないと決定されたならば、即ち、セクタがこのセッ ション中に書込まれなかったと決定されたならば、２７７０でデータが装置から 直に読取られる。もし、２７６０で、要求されたセクタ（又は複数のセクタ）が ログ-ファイルに存在していると決定されたならば、即ち、セクタがこのセッシ ョン中に書込まれたと決定されたならば、２７８０でデータがログ-ファイルか ら読取られてこの要求を満たす。これはデータ回復アプリケーション・プログラ ム３００に対して、セクタが事実上書込まれているとの外観を付与しているが、 これら書込みは、事実上、ログ-ファイルによって効果的に保存されている。 図２８は、変更の放棄、新データ実行、並びに、オリジナル・データの潜在的 な復帰を促進すべくログ-ファイルを操作するアプリケーションのフローチャー トである。不適切に変更されていると決定されたセクタは、２８１５で対応する ログ-ファイル・エントリを削除することによって、２８１０でのように「アン ドゥー」させることができる。２８２０で、全ての変更を実行することが望まし くなる場合、上書きされようとするオリジナル・データは、２８３０でのように 、遠隔データ回復サイトでのネットワークに取り付けられた記憶装置６５上のフ ァイルに転送される。次いで、このオリジナル・データのログ-ファイルは２８ ４０でのように保管される。最終的に、オリジナル・データはここで安全に保管 されたので、２８５０のように、ログ-ファイルのデータが用いられて、ローカ ル記憶装置２６を変更する。もし、何らかの理由で、そのローカル記憶装置２６ をオリジナル状態に復帰させることが適切であると考えられたならば、２８７０ の ように、犯された全変更をアンドゥーすることが可能である。この場合、２８３ ０及び２８４０のように転送されて保管されたオリジナル・データは、それぞれ ２８８０のように、ローカル・コンピュータ・メモリへ転送されて戻され、この オリジナル・データのログ-ファイルに注記された全セクタは２８８５のように ローカル記憶装置２６に復帰されて、ローカル記憶装置２６をそのオリジナル状 態に為す。 理解して頂けるように、本発明の多数の特性及び長所が、本発明の構造及び機 能の詳細と共に、以上の記載で詳述されたが、この開示は例示的目的のみであり 、そして、添付の請求項で表現されている文言の広範な一般的意味合いによって 示される全幅にわたる発明の原理内において、様々な変更が、詳細に、特に各種 パーツの形状、寸法、並びに、配列の点で為され得る。

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

Claims (1)

1. 【特許請求の範囲】 １． 正規のオペレーティング・システムを有するローカル・コンピュータ からデータを遠隔的に回復する方法であって、 前記ローカル・コンピュータのメモリに、記憶媒体から立ち上がり可能な遠隔 データ回復オペレーティング・プログラムをロードする段階であり、前記立ち上 がり可能な遠隔データ回復オペレーティング・プログラムが前記ローカル・コン ピュータによって局所的に動作させられると共に、前記正規のオペレーティング ・システムとは独立して動作させられることから成る段階と、 前記ローカル・コンピュータと遠隔データ回復コンピュータの間に、前記ロー カル・コンピュータによる前記遠隔データ回復オペレーティング・プログラムの オペレーションを通じて通信を設定する段階と、 前記遠隔データ回復コンピュータによって前記ローカル・コンピュータを遠隔 的に制御し、データ回復が前記遠隔データ回復コンピュータのオペレーションを 通じて実行され得る段階と、 の諸段階を含む方法。 ２． 前記遠隔データ回復コンピュータとの通信を設定する前に、前記ロー カル・コンピュータによる前記遠隔データ回復オペレーティング・プログラムの オペレーションを通じて、情報を求めてローカル・コンピュータ・ユーザに質問 する段階を更に含む、請求項１に記載の方法。 ３． 前記遠隔データ回復コンピュータとの通信を設定する前に、前記ロー カル・コンピュータによる前記遠隔データ回復オペレーティング・プログラムの オペレーションを通じて、データ回復情報を求めて前記ローカル・コンピュータ ・ユーザに質問する段階を更に含む、請求項２に記載の方法。 ４． 前記遠隔データ回復コンピュータとの通信を設定する前に、前記ロー カル・コンピュータによる前記遠隔データ回復オペレーティング・プログラムの オペレーションを通じて、ユーザ識別情報を求めて前記ローカル・コンピュータ ・ユーザに質問する段階を更に含む、請求項２に記載の方法。 ５． 前記ローカル・コンピュータ上で実行しているデータ回復プログラム のオペレーションを、前記遠隔データ回復コンピュータでのディスプレイを介し てモニタする段階を更に含む、請求項１に記載の方法。 ６． 前記モニタする段階が、データ回復アプリケーション・プログラム用 の前記遠隔データ回復オペレーティング・プログラムを含む記憶媒体をモニタす ることを含む、請求項５に記載の方法。 ７． 前記遠隔データ回復コンピュータでのコンピュータ入力装置によって 、前記ローカル・コンピュータ上で実行しているデータ回復のプログラムのオペ レーションを制御する段階を更に含む、請求項１に記載の方法。 ８． 前記遠隔データ回復コンピュータによって、前記ローカル・コンピュ ータ上のローカル・ディスプレイの表示を制御する段階を更に含む、請求項１に 記載の方法。 ９． 前記遠隔データ回復コンピュータ上の遠隔ディスプレイによって、前 記ローカル・コンピュータ上のローカル・ディスプレイの表示をモニタする段階 を更に含む、請求項１に記載の方法。 １０． 前記遠隔データ回復コンピュータから前記ローカル・コンピュータへ 、データ回復アプリケーション・プログラムをダウンロードする段階を更に含む 、請求項１に記栽の方法。 １１． 前記遠隔データ回復コンピュータから前記ローカル・コンピュータへ 、データ回復診断プログラムをダウンロードする段階を更に含む、請求項１に記 載 の方法。 １２． 前記ダウンロードする段階が、前記ローカル・コンピュータにおける 記憶媒体上にデータ回復アプリケーション・プログラムをダウンロードすること を含む、請求項１１に記載の方法。 １３． データ回復アプリケーション・プログラムを前記ローカル・コンピュ ータで実行する段階を更に含む、請求項１に記載の方法。 １４． データ回復診断プログラムを前記ローカル・コンピュータで実行する 段階を更に含む、請求項１に記載の方法。 １５． 前記ローカル・コンピュータから前記遠隔データ回復コンピュータへ 、回復されるべきデータをダウンロードする段階を更に含む、請求項１に記載の 方法。 １６． 前記遠隔データ回復コンピュータから前記ローカル・コンピュータへ 、データ回復アプリケーション・プログラムをダウンロードすると共に、そのデ ータ回復アプリケーション・プログラムを実行する段階を更に含む、請求項１に 記載の方法。 １７． 前記通信を設定する段階が、通信サーバを通じて通信を設定しており 、データ回復のために、前記通信サーバを介して、第２遠隔データ回復コンピュ ータと第２ローカル・コンピュータの間に通信を設定する段階を更に含む、請求 項１に記載の方法。 １８． 前記遠隔データ回復コンピュータのオペレータが、データにおける変 更を続行するか、或は代替的に放棄するかの決定を為すときまで、前記ローカル ・コンピュータに対するデータにおける変更を遅らせる段階を含む、請求項１に 記 載の方法。 １９． 前記ローカル・コンピュータに対するデータにおける変更を行うとの 決定が為されたならば、変更される旨のマーク付けされた全データを、保管のた めに、前記遠隔データ回復コンピュータにおける保管ファシリティへ先ず転送す る段階を更に含む、請求項１８に記載の方法。 ２０． 前記ローカル・コンピュータのローカル記憶装置のセクタに対して実 行されるべき全書込み活動を、前記遠隔データ回復コンピュータにおけるファイ ルにロギングする段階を含む、請求項１９に記載の方法。 ２１． 前記セクタ及び前記ローカル記憶装置を識別すると共に、そのセクタ に書込まれた最新データを識別する識別子を前記ファイル内の各エントリに提供 する段階を更に含む、請求項２０に記載の方法。 ２２． 記憶媒体上のコンピュータ・プログラムであって、 ローカル・コンピュータの中央演算処理装置によって局所的に動作可能である と共に、該ローカル・コンピュータの正規のオペレーティング・システムとは独 立して局所的に動作可能な立ち上がり可能な遠隔データ回復オペレーティング・ プログラムと、 遠隔データ回復コンピュータとの通信を設定する通信プログラム手段と、 を備えるコンピュータ・プログラム。 ２３． 前記立ち上がり可能な遠隔データ回復オペレーティング・プログラム がデータ回復診断プログラムを含む、請求項２２に記載のコンピュータ・プログ ラム。 ２４． 前記立ち上がり可能な遠隔データ回復オペレーティング・プログラム がデータ回復アプリケーション・プログラムを含む、請求項２２に記載のコンピ ュータ・プログラム。 ２５． データ回復の方法であって、 データ回復が必要なデータ記憶装置を有するローカル・コンピュータと遠隔デ ータ回復コンピュータの間に通信リンクを設定する段階と、 前記ローカル・コンピュータと前記遠隔データ回復コンピュータの間に相互作 用を可能とする段階と、 前記遠隔データ回復コンピュータに常駐するデータ回復プログラムへのアクセ スを維持する段階と、 前記データ記憶装置を診断する段階と、 前記ローカル・コンピュータの前記データ記憶装置上のデータを回復する段階 と、 の諸段階を含む方法。 ２６． 前記通信リンクを設定する段階が、モデム、ローカル・エリア・ネッ トワーク、ワイド・エリア・ネットワーク、並びに、インターネットから成るグ ループの内の１つを介して通信リンクを設定することを含む、請求項２５に記載 の方法。 ２７． データ記憶媒体からアクセスできないデータを回復するためのデータ 回復システムであって、 前記データ記憶媒体に関連されると共に、中央演算処理装置、メモリ、並びに 、正規のオペレーティング・システムを有するローカル・コンピュータと、 遠隔データ回復コンピュータと、 前記正規オペレーティング・システムとは独立して前記ローカル・コンピュー タを動作させて、前記ローカル・コンピュータと前記遠隔データ回復コンピュー タの間に通信を設定すべく、前記ローカル・コンピュータの前記メモリへロード されるべき立ち上がり可能な遠隔データ回復プログラム手段と、を備え、 前記データ記憶媒体からデータを回復するために、前記ローカル・コンピュー タが前記遠隔データ回復コンピュータによって遠隔的に制御されることから成る データ回復システム。 ２８． 前記立ち上がり可能な遠隔データ回復プログラム手段が、前記ローカ ル・コンピュータを動作するための立ち上がり可能なオペレーティング・システ ム手段を含む、請求項２７に記載のデータ回復システム。 ２９． 前記立ち上がり可能な遠隔データ回復プログラム手段が、データ回復 診断プログラム手段を含む、請求項２７に記載のデータ回復システム。 ３０． 前記立ち上がり可能な遠隔データ回復プログラム手段が、データ回復 アプリケーション・プログラム手段を含む、請求項２７に記載のデータ回復シス テム。 ３１． 前記遠隔データ回復コンピュータが、データ回復アプリケーション・ プログラム手段を記憶する第２データ記憶媒体を含み、該データ回復アプリケー ション・プログラム手段が前記遠隔データ回復コンピュータから前記ローカル・ コンピュータへダウンロード可能である、請求項２７に記載のデータ回復システ ム。 ３２． 前記ローカル・コンピュータと前記遠隔データ回復コンピュータの間 に設定される通信を担う通信チャネルを更に含み、該通信チャネルが、電話線、 ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、並びに、イ ンターネットから成るグループの内の１つを用いている、請求項２７に記載のデ ータ回復システム。 ３３． 前記遠隔データ回復コンピュータが、前記ローカル・コンピュータで のデータ回復アプリケーション・プログラムをモニタするためのディスプレイを 備える、請求項２７に記載のデータ回復システム。 ３４． 前記立ち上がり可能な遠隔データ回復プログラム手段が、前記ローカ ル・コンピュータのユーザにユーザ情報を求める質問を為すためのプログラムを 含む、請求項２７に記載のデータ回復システム。 ３５． 前記立ち上がり可能なデータ遠隔回復プログラム手段が、前記ローカ ル・コンピュータのユーザにデータ回復情報を求める質問を為すプログラムを含 む、請求項２７に記載のデータ回復システム。 ３６． 前記立ち上がり可能な遠隔データ回復プログラム手段が、前記データ 記憶媒体からデータを回復するために、前記遠隔データ回復コンピュータから動 作可能である、請求項２７に記載のデータ回復システム。 ３７． 前記立ち上がり可能な遠隔データ回復プログラム手段が、前記遠隔デ ータ回復コンピュータに回復させるべきデータをダウンロードするために、前記 遠隔データ回復コンピュータから動作可能である、請求項２７に記栽のデータ回 復システム。 ３８． 前記立ち上がり可能な遠隔データ回復プログラム手段が、前記データ 記憶媒体上のデータ回復状況を診断するために、前記遠隔データ回復コンピュー タから動作可能である、請求項２７に記載のデータ回復システム。 ３９． ローカル・コンピュータからデータを遠隔的に回復するための方法で あって、 記憶媒体から遠隔データ回復アプリケーション・プログラムを前記ローカル・ コンピュータのメモリ内へロードする段階と、 前記ローカル・コンピュータによる前記遠隔データ回復アプリケーション・プ ログラムのオペレーションを通じて、前記ローカル・コンピュータと遠隔データ 回復コンピュータの間に通信を設定する段階と、 前記遠隔データ回復コンピュータによって前記ローカル・コンピュータを遠隔的 に制御する段階とを備え、データ回復が、前記遠隔データ回復コンピュータのオ ペレーションを通じて実行され得ることから成る方法。 ４０． 前記ローカル・コンピュータに関連されたローカル・ディスプレイ上 の選択されたデータ回復情報を表示する段階を更に含む、請求項３９に記載の方 法。 ４１． データ記憶媒体からアクセスできないデータを回復するためのデータ 回復システムであって、 前記データ記憶媒体に関連されると共に、メモリを有するローカル・コンピュ ータと、 遠隔データ回復コンピュータと、 前記ローカル・コンピュータと前記遠隔データ回復コンピュータの間に通信を 設定すべく、前記ローカル・コンピュータの前記メモリ内へロードされる遠隔デ ータ回復プログラム手段と、を備え、 前記遠隔データ回復プログラム手段が、前記データ記憶媒体からのデータの回 復のために、前記ローカル・コンピュータを前記遠隔データ回復コンピュータで 遠隔的に制御させることを可能とする成るデータ回復システム。 ４２． 前記遠隔データ回復コンピュータのオペレータがデータにおける変更 を続行するか、或は代替的に、該変更を放棄するかの決定を為すまで、前記ロー カル・コンピュータに対するデータにおける全変更を遅らせる手段を含む、請求 項４１に記載のデータ回復システム。 ４３． 前記ローカル・コンピュータに対するデータにおける変更を行うとの 決定が為されたならば、変更される旨のマーク付けされた全データを、前記ロー カル・コンピュータで前記変更を為す前に、保管のために、前記遠隔データ回復 コンピュータにおける保管ファシリティへ転送する段階を更に含む、請求項４２ に記載のデータ回復システム。 ４４． 前記ローカル・コンピュータのローカル記憶装置のセクタに対して実 行されるべき全書込み活動を、前記遠隔データ回復コンピュータにおけるファイ ルにロギングする手段を含む、請求項４３に記載のデータ回復システム。 ４５． 前記ファイル内の各エントリが、前記セクタ及び前記ローカル記憶装 置を識別すると共に、そのセクタに書込まれた最新データを識別する識別子を含 む、請求項４４に記載のデータ回復システム。 ４６． データ回復プロセス中、選択されたデータ回復事象の手段を含む、請 求項４１に記載のデータ回復システム。 ４７． 記憶媒体上のコンピュータ・プログラムであって、 ローカル・コンピュータの中央演算処理装置によって局所的に起動可能な遠隔 データ回復プログラム手段と、 遠隔データ回復コンピュータとの通信を設定して、データ回復のために、前記 遠隔データ回復コンピュータに前記ローカル・コンピュータの制御を可能とさせ る通信プログラム手段と、 を備えるコンピュータ・プログラム。