JP2008538026A - モジュール式イメージダウンロードシステム - Google Patents

Abstract

コンピュータまたはコンピュータ化された装置を構成するための、モジュール式のイメージをネットワーク経由でダウンロードするシステム及び方法である。プログラムイメージには、典型的には、基盤イメージ及びアプリケーションモジュールイメージを含む。前記システムは、構成データ内に定義されたアクションツリーへの応答により実行されるソフトウェアとして構成され、前記アクションツリーは、実行オブジェクト内には組み込まれず、構成データ内に定義される。アクションツリーは、ユーザインターフェイスを通して開始、一時停止、終了等される。実行オブジェクトは、アクションツリーの各変更に対して再コンパイルする必要が無く、モジュールは実行前に動的結合される。アクションツリーによる方法で、利用者は、再度のコーディングや追加試験を行うことなく、アクションまたはアクションツリー全体の変更、追加、削除を容易に行うことができる。
【選択図】図３

Description

関連する出願の参照

本出願は、２００５年３月２５日に出願された正規の米国特許出願第１１／０９０６３７号に基づく優先権を主張するものであり、同出願を参照として本明細書に引用する。

連邦政府による資金提供を受けた研究開発の記載

適用なし。

提出されたコンパクトディスクへの参照

適用なし。

著作権保護下にある内容に関する注意

本特許文献の内容の一部は、米国及びその他の国の著作権法による著作権保護の対象である。著作権者は、特許商標局による特許ファイルまたは記録としての特許文書または特許の開示の複製の場合を除き、著作権に関する全ての権利を留保する。著作権者は、本特許文献を秘密として維持する権利を放棄するものではなく、米国特許法施行規則１．１４条に基づく権利を制限なく保持する。

本発明は、一般的にコンピュータプログラムの構成、特にアクションツリーに基づく（ａｃｔｉｏｎ ｔｒｅｅ−ｂａｓｅｄ）ネットワーク経由のイメージダウンロードシステムに関する。

近年のコンピュータ及びコンピュータ化された装置は、あり得るモデル数、選択可能な組合せ及びその他のバリエーションが増加することにより、ますます複雑さを増してきている。例えば、受注仕様生産（ＣＴＯ）のコンピュータの販売支援において、異なる基盤（ｆｏｕｎｄａｔｉｏｎ）イメージとアプリケーションイメージの組合せを検討する際、所与のシステムについて利用可能なオプションの表は、数百万にも登るイメージの組合せを示し、それはいずれもコンピュータのハードドライブにコピーする必要のあるものである。典型的には、前記選択肢には、特定のハードウェアに関連する少数の基盤イメージの組合せに加え、それらのコンピュータ上にインストールされて実行されるアプリケーションモジュールの集合を含む。

このイメージのオプションの過剰さは、生産環境にとっての重荷であるのみならず、技術面や試験、品質保証、サービスなどといった、製造上利用できる現在または過去のいずれかの構成として、ソフトウェア及び／またはアプリケーションを構成または再構成しなければならない領域においても重荷となっている。これらのハードドライブにイメージを生成するためには、ハードドライブにインストールされるべき基盤イメージ及びアプリケーションモジュールのイメージとして事前に定義された組合せをロード（ｌｏａｄ）するための、モジュール式イメージダウンロードプログラムが開発されてきている。ハードウェア及び／またはソフトウェアの公開のどれ１つをとっても、例えば工場、技術、試験、品質保証、サービス部門の各バージョンといった多くの異なる種類のイメージプログラムが存在する。

典型的に、受注仕様生産の環境において所与のシステムに何をロードすべきかという判断は、全体としてではなく少なくとも部分的には、デスクトップ管理インターフェイス（ＤＭＩ）に含まれる情報への応答の形で行われる。ＤＭＩは、コンピュータ装置のハードウェア上の領域であって、Ｍコード（Ｍｃｏｄｅ）と呼ぶ文字列を含むものである。またＤＭＩは、装置ごとのハードウェアの通し番号を規定したＵＵＩＤと呼ばれる区域を含む。ＤＭＩにおいて保有されるＭコードのビット列は、ハードウェアの特徴、どの基盤イメージまたは他のモジュールがロードされているか、若しくはロードされるべきかといった装置に関する情報を示している。Ｍコードはハードドライブに包含されるものではないため、Ｍコードの状態に影響を与えることなく、必要に応じてハードドライブのパーティションを区切り直したりフォーマットしたりすることは可能である。Ｍコードは、ハードドライブにイメージをダウンロードする前にＤＭＩに書き込まれる。

約１０年前、産業界は、新しいシステムのハードドライブにイメージをダウンロードする手段として第一にバッチファイルの利用に頼っていた。バッチファイルは複数のデータソースを利用しており、大幅に柔軟性が欠けていて、大規模な数の異なるイメージの組合せをサポートすることを検討するのは現実的でさえなかった。加えて、構成のどのような変更も複数のデータソースとバッチファイルにわたって行わなければならず、その工程には手間がかかり、エラーを起こし易く、退屈なものであった。

より最近になって、単一のデータソースと高級言語で書かれたプログラム群による、ネットワーク経由でのモジュール式イメージ化手法（ｍｏｄｕｌａｒ ｎｅｔｗｏｒｋ ｉｍａｇｉｎｇ）が導入され、それはオペレーティングシステムのＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）の中で利用可能となるように作られた機能を典型的に活用していた。そのダウンロード工程は、別々の実行オブジェクト（ｅｘｅｃｕｔａｂｌｅ）の実行に対する応答として機能するものであった。そうした構成ダウンロード用のプログラムとしてソニーで用いられたものの１つは、ＭＩＮＤＳ（Ｍｏｄｕｌａｒ Ｎｅｔｗｏｒｋ Ｄｏｗｎｌｏａｄ Ｓｙｓｔｅｍ）バージョン１と呼ばれ、Ｐａｃｉｆｉｃ Ｔｏｏｌｓという名で知られるプログラムツールセットと組み合わせて用いられた。

別々の基盤及びアプリケーションモジュールを備えたシステムを構築する能力が、顧客に別々のソフトウェアの組合せを提供する受注仕様生産のコンピュータの販売支援において必要であることは、十分理解されるべきである。その一例は、顧客のコンピュータに搭載するワードプロセッサ及びマルチメディアソフトを顧客に選択してもらうような場合である。基盤イメージを配置し、モジュールを追加して何らかのイメージを生成する工程は、ここではソニーモジュール式テクノロジー（Ｓｏｎｙ Ｍｏｄｕｌａｒ Ｔｅｃｈｎｏｌｏｇｙ）として知られている。この技術の利点は、顧客に対して飛躍的に増加する数のイメージを提供できるところにある。例えば、基盤イメージの数をｘ、モジュールの数をｙ、提供できる一意なイメージの数をｚとすると、等式ｚ＝ｘ＊２^ｙによって別々のイメージ数の規模が表現される。例として、２３の基盤イメージと３３のモジュールがあったとすると、いずれの場合も実際に典型的に提供されるのは一部分のみとは言え、顧客に提供し得る一意なイメージ数は８７０億を超えることになる。。大規模なイメージ数を提供しサポートできる能力のある製造者は、競争上優位に立つことになる。

１つのイメージのライフサイクルにおいて、数多くの段階が存在すると考えられる。（１）計画−所定の型のＰＣ上にどのソフトウェアを配置するかをプログラム管理として決定する段階。（２）イメージコンポーネントの開発−基盤イメージ、モジュール及び回復用コンポーネントを組み合わせてソフトウェアを統合する段階。（３）イメージコンポーネントの試験−統合、ソフトウェア及び様々な受注仕様生産のオプションについて試験を行う段階。（４）イメージコンポーネントの公開と配送−コンポーネントを生産拠点に送る段階。（５）サポート−製品を維持、改良、修繕を通してサポートする段階。

典型的には、イメージのライフサイクルのうち最も手間がかかるのは試験である一方、技術的に最も困難な局面は開発である。どちらの場合も、システムは頻繁に新しいソフトウェアに置き換わる。置き換えの主な理由の１つは、様々な受注仕様生産のオプションを試験することである。他の理由としては、システムを工場出荷状態に戻すということもある。

このシステムの頻繁な置き換えの必要性により、特にテスト段階において、イメージ化の工程は、歴史的に所要時間がかかることでボトルネックとなっていた。イメージ化の工程が完了するまでシステムは使用不可能になる。さらに、システムをイメージ化するために入力値を与え、ＣＤを交換することに技術者は時間を費やし、概して非常に長い時間を消耗する工程としてエラーを起こしやすいものとなっていた。つまり、システムをイメージ化する工程はエンジニアリング時間を要求し、イメージ化が行われている間は、システムを使用不可能にする結果となっていたのである。そのため、これら時間の消耗を最小化し、またはボトルネックを解消することにより、多くの利益が生まれることが理解されるであろう。これまで解決策を求める試みが行われてきたものの、全て時間的な要求及び柔軟性の観点において不十分なものとなっていた。

以前のイメージ化手法の解決策は、“インストールＣＤ”と呼ばれるＣＤを用いて手作業によりシステムをイメージ化ことであった。こうした工程は、ＭＩＮＤＳバージョン１のような、最初のモジュール式のイメージをネットワーク経由でダウンロードする方法が開発される以前に使用されていた。インストールＣＤは、典型的にはオペレーティングシステムとしてＭＳ−ＤＯＳを利用し、より高速な媒体とは対照的なＣＤであり、通例ではシステムをイメージ化するために技術者が半日を要していた。この工程はさらに、システムがイメージ化できるようになる前にＣＤを複製しなければならず、追加的な負担と遅延が発生し、ボトルネックを一層大きくさせるものであった。さらに言えば、オプションの選択は複雑で制限もあった。

モジュール式のイメージをネットワーク経由でダウンロードする方法（即ちＭＩＮＤＳバージョン１）が初めて開発された際、システムをイメージ化する新しい方法が導入された。その方法は、ＣＤとは対照的にローカルエリアネットワーク（ＬＡＮ）を通じてシステムをイメージ化する、手作業による工程を備えたものであった。オペレーティングシステムとして用いられたのは未だＭＳ−ＤＯＳだったが、ＣＤからＬＡＮへの切り替えにより、システムをイメージ化するために要する合計時間は半日からおおよそ３時間に減少した。速度は向上したものの、様々な受注仕様生産のオプションは試験において利用可能ではなかった。

さらに、そのイメージ化の工程には、工程が手作業で行われることによる根本的な弱点があり、その弱点はシステムを二度同じようにイメージ化するのが難しいことであった。この一貫性の欠如は、イメージ化の工程において多くの手順を手作業で実施することに起因し、重大な問題をもたらしていた。これら手作業の手順を実施する必要性を解消すれば、非一貫性の問題を解消できるであろう。

イメージ化用のソフトウェアであるＭＩＮＤＳバージョン１は、ＰＣにおける新たな進歩の力を活用して作られたものであり、その工程によってシステムを約１時間でイメージ化でき、エンジニアリング時間は１０分のみ必要とし、これはインストールＣＤを用いるのと比べると相当な改善であった。ＭＩＮＤＳバージョン１は、受注仕様生産のオプションを試験するためにソフトウェア管理システム（ＳＭＳ）のデータベースと交信するように初めて構成され、イメージをＬＡＮに向けてアップロードする能力をも備えていた。ＭＩＮＤＳバージョン１の適用は、イメージが初めて一貫した方法でアップロード及びダウンロードされることを意味し、試験の正確性をも向上させるものであった。

現在のＭＩＮＤＳバージョン１のプログラムは数多くの利点を有するものであったが、産業界における同様の構成用プログラムがそうであるように、ダウンロード工程の柔軟性が低下し、ユーザとのやり取りが複雑であるといった多くの欠点にまだ悩まされてもいた。

従って、追加された柔軟性と使い易さを備えた、より高度化されたソフトウェアとしてのモジュール式のネットワークダウンロードシステムの必要性が存在し、本発明はその必要性及びそれ以外の必要性について満足させるものである。

本発明に係るネットワーク経由でモジュール式のイメージダウンロードシステム（ＭＩＮＤＳバージョン２）は、対象のコンピュータシステムにストレージエリアネットワーク（ＳＡＮ）からソフトウェアイメージをダウンロードし、及び／または対象のコンピュータシステムからＳＡＮにアップロードするソフトウェアの集合である。この新しいダウンロードシステムは、従来のダウンロードシステムの数多くの欠点を克服するために実行環境をツリー構造にまとめたものとなっている。

システムを構成する工程において、システム内のイメージの構築は、デスクトップ管理インターフェイスへの書き込み、ハードドライブの設定、基盤イメージのダウンロード、モジュールのインストール、及びクリーンアップにより行われる。システムの別の目的は、他の利用者がアクセスしてダウンロードするために、ソフトウェアイメージをコンピュータからネットワークへアップロードできるようにすることである。本発明によるＭＩＮＤＳソフトウェアは、現在または過去のイメージの組合せによるイメージの継続的な置き換えも可能にしている。

最初のＭＩＮＤＳシステム（バージョン１）は数多くの利点を有するものであったが、いくつかの他の領域については不足している点も見受けられた。特に１つ問題は、ダウンロードされるイメージの組合せが実質的に静的なものであり、何らかの変更を加える場合にはプログラムの再コンパイルが必要となる点であるとされた。システムをイメージ化する複雑な工程は急速に進化してきており、絶え間なく集中して起こる変更によって予想以上にＭＩＮＤＳバージョン１に対しても頻繁なコード変更が求められ、時には毎日変更が行われた。理想的にはこうしたソフトウェアの変更は全て試験されるべきだが、時間と資源の制約からしばしばそれは非現実的であった。さらに、こうした変更の素早い適用はしばしば不可欠であって、技術的に優れた効率的な解決策は妥協の対象になり得た。

ＭＩＮＤＳバージョン１の実装においては、異なるユーザフロー及び様々なユーザグループをサポートする機能性と共に複数の並行するプログラムのバージョンを生成することが要求された。これらの並行するバージョンは、ソフトウェアの保守に掛かる時間及び適用に掛かる時間を増大させる結果となった。

現在のモジュールダウンロードシステム（ＭＩＮＤＳバージョン１）によるダウンロード工程では、いくつかのファイルをローカルエリアネットワークを介して何度も転送しなければならず、システムをイメージ化するために必要な合計時間が増えることになり、ネットワークの負荷も増大していた。また、利用者の入力が全て集められる前に一部のイメージ化工程が実行されることから、利用者が次の入力を行う前にネットワークと対象システム間のファイル転送などのタスクの終了を待たなければならないという要因によって、システムをイメージ化するために必要以上のエンジニアリング時間が要求されていた。別の欠点としては、利用者が不正入力や不正選択といった間違いを戻って訂正できないということもあった。間違いを訂正するには、工程の全体をやり直すというただ１つの方法しかなく、工程内の間違いが発生した時点に到達するために既に費やした時間と努力を失うこととなった。

これらの欠点を克服するために、ＭＩＮＤＳバージョン２のプログラムが設計上利用者に認めたのは、アクション、特にアクションツリー（ａｃｔｉｏｎ ｔｒｅｅ）への応答としてイメージを生成することであった。工程に必要なデータは、ソニーのＶＡＩＯの環境の場合にはＶＳＭＳ（ＶＡＩＯソフトウェア管理システム）として知られる、ソフトウェア管理システム（ＳＭＳ）から取得される。ＭＩＮＤＳシステムは、好適には、システムイメージの取り込みのために構成された、コンピュータ装置の製造者、付加価値のある再販業者、またはインテグレータ等によるサブネットを運用するために構成される。利用者が所望のイメージ構成を選択する際には、ネットワーク上で利用可能なイメージのオプションのみが表示される。

アクション及びアクションツリーは、ＭＩＮＤＳの内部で利用され、工程として個別のタスク（アクション）を統合することを可能にする。タスクの順序はアクションの追加または削除によって望んだとおりに容易に変更することができる。ＭＩＮＤＳの内部のアクションツリーの構造は、同一の実行オブジェクトを所与のダウンロード工程の複数のステップにおいて実行することを可能にしている。アクションクラスの中の全てのアクションのインスタンスは、非同期に管理クラスから実行され、メッセージを管理クラスに返送するアクション（例えば、完了、エラー、警告など）を伴う。アクションは、特に長時間を要したり集中したりするような場合には、待ち時間の問題を低減するために別々のスレッドで実行される。

望ましい実施形態としては、ＭＩＮＤＳバージョン２の中で、多くの異なる実行オブジェクトを実行するのとは対照的に、外部の設定ファイルに対して単一の実行オブジェクトを制御する。他に特に指定が無い場合は、これ以降のＭＩＮＤＳについての説明は、本発明に係るＭＩＮＤＳバージョン２に関するものである。ダイナミックリンクライブラリ（ＤＬＬ）が、信頼性及び試験の容易性が高められた単一のＭＩＮＤＳの実行オブジェクトと共に使用される。過去のシステムと異なり、所定のダウンロード工程のための新しいＭＩＮＤＳシステムの構成は、それが使用される時点において、ダウンロード工程の起動前にアクションの動的結合（ｄｙｎａｍｉｃ ｂｉｎｄｉｎｇ）の実行に基づいて行われる。例えば、新しいアクションを追加する際には、文字列表（ｓｔｒｉｎｇ ｔａｂｌｅ）に情報が追加され、前記アクションのためのアクションの一覧が何らかの利用者の入出力と共に定義される。こうした結合の変更は、システム内のコード編集と同じものではないことは容易に理解されるべきである。コーディングに変更があった場合は常に、それが例えエラーの原因となった１行のコードだけだったとしても、それによりプログラムが動かなくなり、または悪くすればエラーを含んだり正しくない内容のイメージを生成する可能性があるため、完全な試験が当然に求められる。しかしながら、結合の変更のみがあった場合は、各モジュール自体は変更が無く既に完全に試験されているため、ソフトウェアの試験はもはや必要ではない。試験ステップの排除は、特に構成が頻繁に変更される環境において、大幅な資源の節約をもたらすことができる。

アクションツリーの使用は、コードを再コンパイルすることなく素早い変更を行える仕組みを提供する。１つまたはそれ以上のアクションツリーが定義可能で、各アクションツリーは、典型的には、それぞれ１つのアクションのインスタンスを含むツリーノード（ｔｒｅｅ ｎｏｄｅ）を複数有する。各ツリーノードは、アクションだけでなく、ツリー内の関係（ｒｅｌａｔｉｏｎｓｈｉｐ）を定義したポインタを有する。限定ではなく例として述べるならば、１つの実施形態として、ツリー構造内においてポインタによって子の関係と次の兄弟の関係をサポートする場合が挙げられる。各ノードはつまり、２つのポインタを持ち、１つのポインタは次の子ノードに向かう深さ方向を指し、１つのポインタはすぐ隣なりの兄弟ノードに向かう横方向を指すことになる。このツリーの設定は、メモリを節約しながら、再帰を用いることなどによりツリーの走査を簡略化する。アクションは管理クラスにより制御され、別々のスレッドで起動される。

コードは、例えばユーザインターフェイス、基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）（または管理層）及び個々のアクションの組合せといった複数の層に分けられる。この分割により、個々のアクションは他のアプリケーション内で再利用可能となり、一方ユーザインターフェイスにおいては、アクションの集合及び／または別々のアクションの単位で操作を行うことができる。管理層は、実行されるべき特定のアクションに対して、管理層からツリーに向けて走査する情報によって指示を出し、逆は発生しない。実行されるアクションによらず同じ管理用のコードが使用されることにより、ソフトウェアの改良と試験は非常に単純化されると理解されるべきである。所与の構築のためには、どのアクションツリーを実行するべきかを決定する選択の工程が発生する。例えば、ユーザインターフェイスにより利用者がアクションツリーを選択してもよく、または１つのアクションが特定されるか、十分な時間の間に利用者からの応答が無い場合には既定値を用いてもよい。

ある実施形態において、ＭＩＮＤＳシステムの機能は、ＭＩＮＤＳの中核部分の利用の柔軟性を向上させるため、ユーザインターフェイスからは分離させられる。前記システムの１つの形態によれば、ＭＩＮＤＳのセッション中に実行された各アクションは、ＶＳＭＳ等に書き込まれ、そこには、好適には日付、時間、アクション、ログオンした人物及びシステム構成に関する情報が含まれる。

ＭＩＮＤＳの装置及び方法は、開発作業用、ＭＩＳ（管理情報サービス）機能としてのソフトウェア配布用といった様々なイメージ化アプリケーションにおいて利用することができる。例えば、前記モジュールは、特別な使用許諾に対する応答であれば、ソフトウェアの選択的なイメージ化のために、システム自体に関する情報、部署情報、及び／またはイメージ生成時に利用可能な他の情報をシステムへ提供することができる。

本発明は、限定としてではなく、多くの方法により、以下の説明を含みながら具体化することができる。

本発明に係る１つの実施形態によれば、ソフトウェアプログラムのイメージを自動構成するための装置であって：（ａ）コンピュータ上でプログラムイメージを構成するためにイメージファイルにネットワーク経由でアクセスするよう構成されたモジュール式ネットワークダウンロードプログラムと；（ｂ）それぞれモジュール式ネットワークダウンロードプログラム内の特定の操作を実行するよう構成された複数のアクションルーチン（ａｃｔｉｏｎ ｒｏｕｔｉｎｅｓ）と；（ｃ）モジュール式ネットワークダウンロードプログラムによって実行されるアクションルーチンのツリーを定義する手段、を含む装置が示される。

前記アクションルーチンはモジュール式ネットワークダウンロードプログラムと動的に結合され、実行されるアクションの組合せの変更、または新たな形態や新たなＰＣの構成に関連するアクションの組合せの新規作成のために、再度のコーディング、再コンパイル及び試験は必要とされない。アクションルーチンのツリーは、テキスト形式の構成ファイルを用いて生成するのが望ましい。前記モジュール式ネットワークダウンロードプログラムは、好適には：（ｉ）アクションツリーの走査の間にアクションを実行するよう構成された管理層；（ｉｉ）望んだとおりに自動インストールが実行されるように管理層における操作を制御するよう構成されたユーザインターフェイス、を含む。

本発明に係る別の実施形態としては、ソフトウェアプログラムのイメージを自動構成するための装置であって：（ａ）動的に結合され、自動ソフトウェアインストールの間に実行され得る複数のアクションを有するアクションツリー層；（ｂ）前記アクションツリー層からアクションを指すポインタを少なくとも１つずつ含むノードを複数有する、少なくとも１つのアクションツリー；（ｃ）アクションツリーの走査の間にアクションを実行するよう構成された管理層；（ｄ）望んだとおりに自動インストールが実行されるように管理層における操作を制御するよう構成されたユーザインターフェイス、を含む装置としてもよい。前記アクションは機能的には独立しており、所与のアクションツリー内において、または異なるアクションツリーをまたがって再利用できる。加えて、アクションは異なる実行スレッド内で起動することもでき、それによりシステムは、長時間にわたるアクションステップの途中でも利用者に迅速な応答を返すことができる。

ＭＩＮＤＳソフトウェアによって生成されるプログラムイメージは、１つの基盤イメージ、またはより典型的には１つの基盤イメージと少なくとも１つのアプリケーションプログラムモジュールの組合せを含む。しなしながら、現時点では実用的な価値はあまり無いものの、ＭＩＮＤＳシステムが１つより多くの基盤イメージをサポート可能であることは理解されるであろう。

アクションツリーからは、望まれるどのような数の異なるアクションを実行することも可能である。例として言えば、本実施形態でサポートするアクションは、処理用のアクションの集合から選択可能であり、その集合は本質的に：Ｍコード用の媒体の作成、システムのデスクトップ管理インターフェイス（ＤＭＩ）からのＭコードのアップロード、システムのハードドライブへの基盤イメージのダウンロード、システムのハードドライブへのアプリケーションモジュールイメージのダウンロード、システムのハードドライブからの基盤イメージのアップロード、システムのハードドライブからのアプリケーションモジュールイメージのアップロード、回復用パーティションからの基盤イメージの回復、媒体のバージョン検証、ブリッタ（ｂｌｉｔｔｅｒ）、対象ドライブの割当て、基本単位（ｂａｓｅ ｕｎｉｔ）の選択、イメージのクリーンアップと不要なファイルの削除、回復用パーティションへのイメージのコピー、パーティションへのモジュールのコピー、イメージのＣＲＣ（巡回冗長検査）の生成、Ｍコード用のフロッピー（登録商標）の作成、起動画面の表示、デスクトップ管理インターフェイスの比較の表示、媒体の取り出し、正しい対象ドライブの検索、ハードドライブ情報の取得、ネットワークサブネット上かどうかの検証、実行記録セッションの終了、ネットワークドライブ図の表示、クエリの分割、ハードドライブの分割、再起動、制限ログイン、メインメニューへ戻る、イメージコンポーネントの存在検証、スレッドの生成、からなる。また、本発明に係る実施形態として、イメージのダウンロード若しくは他の活動をサポートするために、追加的な、または異なるアクションをいくつ生成してもよい。

他の実施形態によれば、本発明は、ソフトウェアプログラムイメージによってコンピュータを構成する方法であって：（ａ）コンピュータ上でイメージを構成するアクションを実行するための、別々に実行可能なアクションの組合せを、生成及びコンパイルするステップ；（ｂ）選択されたアクションツリー内で定義されたアクションを実行する管理層を、生成及びコンパイルするステップ；（ｃ）アクションツリーの選択とアクションツリー内の移動を制御するユーザインターフェイス層を、生成及びコンパイルするステップ：（ｄ）アクション及びアクションツリー内の他のノードを指すポインタを含むノードを複数有するアクションツリーの構造を、生成するステップ；（ｅ）利用者の入力に応じて、アクション、管理層、ユーザインターフェイス及びアクションツリーを連結し、アクションツリー内で定義されたアクションを実行できるプログラムを形成するステップ、を含む方法としてもよい。

前記ツリー構造は、好適には、子のポインタの関係、兄弟のポインタの関係、または、より望ましくは子及び兄弟のポインタの関係の相互の組合せに応じて接続したノードを含む。アクションツリー内のポインタの関係は、アクションツリー内でアクションを指すポインタが位置するところのノードの位置を含む。好適には、実行されたアクションはスタックによって追跡され、利用者が過去の工程内のどのステップにも戻ることを可能にする便利な仕組みを提供している。スタックを使用する場合は、アクションツリー内の親ノードを指すポインタを含むことが望ましい。

新しいＭＩＮＤＳシステムを実装することにより、以下の記載に限定されず、数多くの利点がもたらされる

本発明のある観点によれば、モジュール式のネットワークダウンロードシステムであって、アクションを容易に適用できるシステムが提供される。

本発明の別の観点によれば、動的に結合されるアクションツリーにアクションを追加または削除できるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、利用者による過去のアクションをバックアップすることのできるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、利用者により一時停止（ｐａｕｓｅ）、連続実行（ｓｔｅｐ ｔｈｒｏｕｇｈ）、工程の再開（ｒｅｓｕｍｅ ｐｒｏｃｅｓｓ ｓｔｅｐｓ）を行うことのできるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、エラーハンドリングが改良されたネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、より多くのオプションによってサポートされた包括的なユーザインターフェイスをサポートするネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、部署（例えば、製造現場、技術、サービス、試験、品質保証など）に依存してネットワークでプログラムをダウンロードするための媒体（即ちＣＤ）を複数のバージョンに分けて保持する必要性が解消される、ネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、ソフトウェア管理システム（ＳＭＳ）と直接交信できるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、例えば基盤イメージ、一体型のイメージ（ｍｏｎｏｌｉｔｈｉｃ ｉｍａｇｅ）、ベースプラスイメージ（ｂａｓｅ−ｐｌｕｓ ｉｍａｇｅ）及びゴースト（Ｇｈｏｓｔ）を使用したイメージといった異なるタイプのイメージをサポートできるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、Ｗｉｎｄｏｗｓ（登録商標）ＸＰの縮小版でプリインストールされるＷｉｎＰＥのような、小さなオペレーティングシステムにも適用できるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、指定されたネットワークのサブネット内でのみ実行でき、それにより製造設備の外部から間違って利用されることを防ぐネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、対象システムに完全な部品表（ＢＯＭ）をコピーするネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、システムのＵＵＩＤをＭコード用のフロッピー（登録商標）を生成するための既定値として利用できるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、Ｍコード用のフロッピー（登録商標）を生成するために独立した選択メニューをメインメニューに設けることのできるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、既存のシステムからイメージをアップロードすることのできるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、無人モード、工場用、在庫管理単位（ＳＫＵ）選択、上級モード、基盤イメージのアップロード、自由なイメージのアップロード及びダウンロードなどといった、多くの異なる操作モードをサポートするネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、どのようなアクションの実行の前にも必ず利用者を認証させるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、再コンパイル及び試験を行うことなく新たなアクションツリーを定義できるネットワーク経由のダウンロードシステムが提供される。

本発明の別の観点によれば、全ての利用者の選択と入出力が全てのアクションの実行前に行われるネットワーク経由のダウンロードシステムが提供される。

本明細書における詳細な説明は、本発明の好適な実施形態について十分に開示することを目的としており、何ら制限を課すことなく、これ以降の記述から本発明の特徴はさらに導かれるだろう。

説明のためにより具体的に図面を参照すると、本発明は一般的に、図１から図１６に示したような装置に具体化される。ここで記載する基本的な概念から外れることなく、装置における構成や部品の詳細を変更してもよく、方法における特定のステップや順序について変更してもよい。

ここでＭＩＮＤＳという名前で言及されている、モジュール式のネットワークダウンロードシステムは、ＰＣのソフトウェアに関する全ての特徴を素早く開発するための解決策として、ソニーが設計及び開発したものである。特定のＰＣにソフトウェアを配置する工程は単純なもののように思えるが、その工程を熟知した者には、現在の工程は、単純でも、静的でも、迅速な（素早い）ものでもないことは知られている。単純さ、速さ、柔軟性、オーバーヘッドの低減及び信頼性の目標を達成するために、ＭＩＮＤＳバージョン２システムは、モジュール式のダウンロードシステムであった従来のＭＩＮＤＳバージョン１の設計をゼロから完全に見直したものである。その結果として、新たな設計は、以前の解決策にあった制限や問題を持たないものとなった。

ＭＩＮＤＳの目標の１つは、アプリケーション及び／または利用者の選択に対する応答として受け入れたソフトウェアイメージの変更の工程を、高速化及び単純化することである。本発明によるこれら機能の使い易さと効率性は、ＰＣの開発、構成、品質保証、試験及び保守の各工程を通して相当な利点をもたらすことができる。本発明に係るＭＩＮＤＳバージョン２システムは、工程の変更が素早く、かつ信頼性をもって実装できるように設計されている。設計は、カプセル化、継承、及びポリモーフィズム（多態性）といったオブジェクト指向プログラミングの原理を拡張して利用している。よってＭＩＮＤＳバージョン２は、それが何を行うかだけでなく、どう行うかという点にも新しく重要な特徴を持っている。

図１は、コンピュータ（ＰＣ）システム上にダウンロードされるソフトウェアイメージ１０を示している。この実施形態において示されたイメージは、基盤イメージ１２、ソフトウェアアプリケーションモジュール１４、及び任意的な回復用モジュールイメージ１６を有している。ＰＣのハードドライブのパーティションに搭載されるソフトウェアパッケージの全体が、１つのイメージとされる。いくつかの場合においては、少なくともソニーでは、ＰＣには少なくとも２つのパーティションが定義され、うち少なくとも１つは顧客が使用し、もう１つは回復目的の隠れたパーティションであって、以降これを回復用コンポーネント１６と呼ぶ。これらのコンポーネントは、顧客向けの製造時点だけでなく、開発や試験の間にも繰り返しシステム上に配置しなければならない。イメージは、典型的にはＤＶＤの組合せであるメディアキットを用いて配置することもできる。

イメージにおける最初のコンポーネントは、基盤イメージ１２である。イメージは、特定のハードウェアの組合せに共通するものとして、オペレーティングシステム１８、ドライバ２０、アプリケーション及び／またはユーティリティ２２を含む１つの基盤イメージにより構成される。モジュール１４は、追加的なソフトウェアの部品であって、ＰＣの製造者、またはより典型的には第三の供給者（サードパーティ）によるアプリケーションとしてインストールされたものをサポートするために、ハードドライブに追加されるものである。ここでそのアプリケーションとは、ワードプロセッサ、スプレッドシート、プレゼンテーション用ソフトウェアといった製品一式や、ブラウザ、電子メールプログラム、サウンドカードアプリケーション、メディアＰＣアプリケーション及びそれに類するものが該当する。

イメージ内には、モジュールを望んだ数だけ組み込むことができ、モジュール２４ａから２４ｎとして図示されている。回復用コンポーネント１６は、顧客にＰＣを工場出荷状態に戻すことを可能にするものである。回復用コンポーネントは、例えば、基盤イメージの復元後にプロジェクトに固有のアプリケーションをハードドライブに復元するために必要な、圧縮しパッケージ化されたファイルの組合せ（一般的にはＰＡＣファイルとされる）を有する。データファイル２８は、モジュール式の実行オブジェクトであり、ＰＡＣファイルを用いたアプリケーションまたはモジュールを回復するために必要な、プロジェクト固有の設定ファイルを含んでいる。ＷｉｍＰＥファイル３０、または同様のファイルは、復元の工程において利用される小さなオペレーティングシステムである。それ故、様々なコンポーネントを配置して１つのイメージを生成するという概念は単純であっても、実際の実装は複雑で、多くのステップからなるのである。

図２は、一例として、ハードドライブ４６にイメージをダウンロードし、必須ではないがイメージをハードドライブからアップロードも行うように構成された、ＭＩＮＤＳソフトウェア４２及びユーザインターフェイス４４を持つダウンロードシステム４０を示している。より適した実施形態としては、データベースへのアクセス及びＭＩＮＤＳシステムの操作をまとめる機能を提供するために、ＭＩＮＤＳシステムはローカルネットワークまたはサブネットと接続して運用される。この場合において、ネットワーク上には、ネットワーク上のイメージ及びイメージ化工程に用いるモジュールのリポジトリ４８、デスクトップ管理インターフェイス（ＤＭＩ）用データのリポジトリ５０、ソフトウェア管理システム（ＳＭＳ）５２、製造情報５４（即ち“ＭＩＮＤＳ．ｃｓｖ”）及び暗号化されたＭコードデータ５６を含む。

図３は、一例として、ＭＩＮＤＳシステムの工程における一般的な処理フロー６０を示している。ノード６２においてメインメニューが読み込まれ、ノード６４においてシステムは利用者によるメニューの選択を待つ。ここでメニュー項目が１つしかない場合、または何も選択されないまま所定の時間が経過した場合は、既定値が選択され、ノード６４は素通りされる。ノード６６では選択されたアクションツリーが読み込まれるが、ここで利用者情報を収集することができる。もしアクション及び選択が妥当であれば、工程は、アクションツリー内で順序性を持ったアクションを実行するノード６８に移動する。本発明の１つの操作モードでは、利用者に工程の一時停止（ブレイク）と再開ができるようにし、かつ工程内のステップをまとめて実行し、または過去に実行したステップの時点に戻って、そこで行った選択を変更し、その時点から続行することまで可能にしており、つまり利用者が一連のステップの全体を繰り返さなくてもよいようになっている。一度アクションツリー内のアクションが実行されたら、アクションツリーはノード７０において工程を終了する。

図３のノード６４でのメニュー選択においては、典型的にＭＩＮＤＳプログラムの操作モードに関連して、どれだけの数のアクションツリーの選択をさせてもよい。加えて、大規模な数のモードにわたって選択させるために、例えば最初の画面上には広めの操作のカテゴリのみ表示し、そこで選択したカテゴリ内で所定のモードに導くというようにメニューを階層化してもよい。本発明に係る開示範囲から外れることなく、画面上（ｆｒｏｎｔ ｅｎｄ）でどういった選択形式を利用してもよいことが理解されるべきである。

本発明の１つの実施形態として、ＭＩＮＤＳバージョン２は、ＭＩＮＤＳバージョン１で求められたような並行するバージョンの必要性を解消するための、異なる操作モードを提供する。この多様なモードでは、完全に自動的な操作が提供され、または利用者にイメージ化工程において実行を制御したい範囲を選択させることができる。利用者がより多くを制御するモードはデバッグや障害対応を支援し、一方で利用者があまり多くを制御しないモードは、自動化された工程、及び製造などのハードドライブのイメージ化の制御が非常に重要な領域における利用により適している。さらに、工場内でのイメージ化などの様々な目的に応じて異なる操作モードを適用（ｅｍｕｌａｔｅ）することも可能である。工場におけるイメージ化が適用された場合、同一のデータソースが工場で用いられるものに依存し、それによってより正確な試験が行われ、工場へと運ばれる前に特定の型のエラーを捕捉することができる。

ここで、読み込み後に利用者が何もＭＩＮＤＳとやり取りしなかった場合（つまり図３におけるノード６４の素通りの場合）に自動的に起動する１つの操作モードを、「無人モード」と呼ぶこととする。この操作モードは、最初のＭＩＮＤＳの読み込みを除いて、利用者による入力無しでイメージ化工程の全体を実行する。用いるべきイメージコンポーネントが何かを知るために、所与のシステムのデスクトップ管理インターフェイス（ＤＭＩ）から独自のイメージコンポーネント識別子が抽出され、ＶＳＭＳのプロジェクト情報と照合される。この操作モードで価値があるのは、技術者がイメージをダウンロードするために、数秒のエンジニアリング時間しか要求されないことである。この平均的なエンジニアリング時間の減少は、特に無人モードにおいて、ＭＩＮＤＳバージョン２の重要な利点である。結果として、技術者の時間を毎年数百時間節約することができる。加えて、イメージ化に掛かる合計時間も短縮されるため、システムをより早く試験に供することができ、これは目に見える節約と同じものである。

システムをイメージ化する工程には頻繁に変更が発生するが、ＭＩＮＤＳバージョン２はこの現実を念頭に置いて設計された。コードは、変更が素早く信頼性をもって実装できるような形で構造化されている。典型的には、イメージの組合せとダウンロードされるべき構成の混成（ｍｉｘ）の変更する際に、ＭＩＮＤＳのコードの再コンパイルは要求されない。加えて、ＭＩＮＤＳの設計は柔軟で、素早い変更と保守を可能にする。

初期のＭＩＮＤＳバージョン１を使用している間に、イメージ化工程は継続的に進化し、新しいシステム及び新しいシステム構成の変更またはオプションをサポートするために、イメージをダウンロードするプログラム内のソフトウェアの頻繁な変更が求められることが見出された。多くの場合において、例えば新しいハードウェア等のどのような新しい基盤イメージが求められた場合にも、またはどのような新しいソフトウェアがシステムにおいて利用可能となった場合にも、ＭＩＮＤＳの機能は変更されなければならないことが理解されるべきである。よって、ＭＩＮＤＳバージョン２の設計の目標は、この保守を容易で素早く、かつ信頼性の高いものとすることにあった。

ＭＩＮＤＳバージョン２の基本原理は、アクションとアクションツリーの概念である。アクションは機能的に独立したコードの一部であり、例えばハードドライブの分割（ｐａｒｔｉｔｉｏｎｉｎｇ）、利用者への所定の入力の催促、またはＤＭＩの読み取りといった１つのタスクを実行する。各アクションは、好適には単一のタスクを実行するため（または、好適ではないが、密接に関連する要素の集合を実行してもよい）、各アクションの振る舞いは他のアクションからは隔離されたままであり、それらは最小限度で結合される。アクションに原子性を持つ処理を実行させることによって、結合度を大きく低減することができ、これは近年のソフトウェア工学における要所とされる目標である。

図４は、一例として、アクションの組合せにおけるクラス階層７０を示している。アクションは、好適には全て、図中でＡｂｓｔｒａｃｔＡｃｔｉｏｎ７２とした抽象型の基本クラスを元に生成される。抽象型の基本クラスを用いて、全てのアクションを通じて共通する最小限の振る舞いの組合せが保持される。これらの共通機能はＡｂｓｔｒａｃｔＡｃｔｉｏｎの中で定義され、純粋な仮想関数であり、動的結合が実行されることによって適切な機能が選択され実行される。また、アクションを他のアクションを元に生成することもできるが、これにより数多くの利点がもたらされる。第一に、他のアクションを元にアクションを生成することで、親のアクションを変えることなく機能を変更することができ、よって変更が分離されてソフトウェアの保守の技術的な優位性が向上する。さらに、アクションの階層は、アクションの集合にとって共通的な機能を、１つのアクションまたは抽象型の基本クラスのアクションにカプセル化可能なように生成することができる。

抽象型のアクションクラスの特徴を継承するのは、ＰａｒｔｉｔｉｏｎｅｄＨＤアクションクラス７４、ＧｅｔＭｏｄｕｌｅｓアクションクラス７６、及びＧｅｔＤＭＩアクションクラス７８である。ＰａｒｔｉｔｉｏｎｅｄＨＤアクションクラス７４は、ハードドライブのクリーニングと分割の処理を行う。ＧｅｔＭｏｄｕｌｅｓアクションクラス７６は、所与のシステムについて全てのモジュールの全てのバージョンの取得を行う。ＧｅｔＤＭＩアクションクラス７８は、システムに記述されたＤＭＩの読込みを行う。追加的なアクションクラスとして、ＧｅｔＭｏｄｕｌｅｓアクションクラス７６を元に生成された、モジュールの現在割当中のバージョンを取得するためのＧｅｔＳＫＵＭｏｄｕｌｅｓアクションクラス８０が示されている。以上のアクションクラスは単に例として示されているのであって、ここでの開示範囲から外れることなく、階層の中に望む通りにどういった数のクラスを定義してもよい。クラス階層は、アクションがどういった要素を共通的に有しているか、またどの程度までプログラマが継承を利用したいかに依存して、少ない層、または多くの層により定義される。

図５は、一例として、ＭＩＮＤＳの実行オブジェクト９０が、最上位のＧＵＩ層９２、中位の管理層９４、及び下位のアクション層９６によって階層化される様子を示しており、管理層９４にはアクションライブラリ、アクションツリー及びアクションを有する。ＭＩＮＤＳをこれらの異なる層に分割することにより、層の間のインターフェイスを通して情報のやり取りが制御され、一方で変更が典型的には１つの層で分離して行われることでリスクが減少し、信頼性が向上するといった数多くの利点がもたらされる。いわゆる当業者であれば、本発明の開示範囲から外れることなく、望む通りにどういった数の層にシステムを分割してもよいことを理解するであろう。

好適ではないまでも、ＧＵＩ層９２の生成は任意的であって、その機能をＭＩＮＤＳシステムの外部で供給するか、または個々のアクション内に置いてもよいことが理解されるべきである。図５の実施形態では、ＧＵＩのコンポーネントを、ステータスウィンドウＧＵＩ９８、メインメニューＧＵＩ１００、及びアクション“ｎ”ＧＵＩ１０２を有するように描いている。ＧＵＩ層９２は管理層９４と関連付けられるが、システムを厳密にイメージ化することと他の関連する処理の間で相乗効果を狙って、他の実行オブジェクトと結合させてもよい。

ＧＵＩ層９２と管理層９４の間には、利用者がステータスウィンドウを通してマネージャを制御するという例としての行動１０４と、利用者の入力を受け取るブロック１０６が示されている。

中位の層は管理層９４であり、そこにはマネージャ自体と、アクションライブラリ、及びアクションツリーが含まれる。マネージャは、ＭＩＮＤＳシステムの全ての他の部品を直接的、または間接的に制御する実行オブジェクトであり、その部品には、アクション、アクションツリー、アクションツリー内のノード及びアクションライブラリが含まれる。マネージャは、編集可能なテキストファイルから要求に応じてアクションライブラリにより生成される、アクションツリーのインスタンスを有する。

マネージャは、アクションツリー内でアクションの配列を制御し、利用者の入出力との結び付けを行う。アクションが正常に終了した際には、アクションはマネージャに終了状態を通知する。この方法で、マネージャは、アクションツリーの枝まで到達したか、さらに実行すべきアクションが無いか、またはアクションツリーが実行を終了したかどうかを判定することができる。もし実行すべきアクションが残っている場合は、マネージャは通常、ツリーに次のアクションを実行するように信号を返す。マネージャによってアクションを実行するよう通知された後は、マネージャはそのアクションが終了したという信号を待って保留状態となる。

マネージャ９４の実施形態の例が、アクションツリーの形成とアクションツリーの実行の両方を制御できるアクションマネージャのルーチン１０８と共に示されている。アクションツリーの形成は、アクションライブラリ１１２内のアクションからブロック１１０ごとに行われ、アクションツリー１１４が実行のために形作られる。アクションツリーの実行は、マネージャが所与のツリーに初期化されるブロック１１６において始まり、形成されたアクションツリーがブロック１１８ごとに実行される。ブロック１２０において判定されるように、少なくとも１つのノードがアクションツリーに残っている限り、アクションはブロック１２２ごとに選択され、各ノードはアクション層９６において小型化されたコードを持つ１つのアクションを実行する。マネージャは、利用者入力のブロック１３２を通して、ユーザインターフェイス層のＧＵＩ９２と、アクションｎのブロック１３０として描かれているアクションを接続する。

最下層はアクション層９６であり、ここにはアクションＡ１２６、アクションＢ１２８に始まり、アクションＮ１３０までとして描かれている、事前にコンパイルされたアクションが含まれる。アクション層９６内の各アクションは、好適には、単一の（原子性を持つ）アクションを含むと理解されるべきである。アクションツリーは１つまたはそれ以上のノードを有し、各ノードはアクションツリー内で１つのアクションのインスタンスを指し示している。ここで、それぞれ別々のアクションが、それ自身のＧＵＩを持ってもよいことが思い出されるべきである。これら様々なＧＵＩは、好適には、利用者がＭＩＮＤＳシステムと通信するためのインターフェイスを提供する。

図６は、図５に示した階層化構造にあてはめられたモジュール１４０の一例を示している。ここでＭＩＮＤＳ２ｘ．ｅｘｅと呼ぶところのＭＩＮＤＳの実行オブジェクトは、管理層としてのコードを含んでいる。ここで新しく生成された操作ごとにこのコードを修正する必要が無いことは、容易に理解されるべきである。ＡｃｔｉｏｎＬｉｂｒａｒｙ．ｄｌｌ１４４と呼ぶアクションライブラリは、アクションライブラリとアクションツリー、及びアクションツリーのノードクラスを含む。アクションクラス内で利用可能なアクションの組合せは、Ａｃｔｉｏｎｓ．ｄｌｌ１４６の中に描かれている。ＭＩＮＤＳシステムを通して用いられる設定用クラス（Ｓｅｔｕｐ ｃｌａｓｓｅｓ）とライブラリは、ＭｉｎｄｓＣｏｍ．ｄｌｌ１４８とし、ＡｃｔｉｏｎＬｉｂｒａｒｙ．ｄｌｌ１４４及びＡｃｔｉｏｎｓ．ｄｌｌ１４６と関連付けられる。起動されたプログラムスレッドの活動を制御するスレッドクラスは、ＭｉｎｄｓＴｈｒｅａｄｓ．ｄｌｌ１５０の中で描かれている。ＳＭＳシステムを用いてイメージ構成データベースと交信するために必要なクラスは、Ｍｉｎｄｓ２．ｄｌｌ１５２とされ、Ａｃｔｉｏｎｓ．ｄｌｌ１４６及びＭｉｎｄｓＴｈｒｅａｄｓ．ｄｌｌ１５０と関連付けられる。

図７は、マネージャがどのようにアクション１６０を制御するかを、アクションへの実行要求とアクション終了時の通知の受け取りを例として示している。マネージャは、ブロック１６２において実行中となっており、ツリー内の次のアクションをブロック１６４において起動する。ブロック１６６にて要求は付随するツリーノードに送られ、ブロック１６８にてアクションＸの実行が開始される。ユーザインターフェイスの応答性能を向上させるために、アクション用のスレッドはブロック１７０において生成してもよいが、これは特に資源や時間に影響の大きい活動（例えばネットワークとハードドライブ間のファイルのダウンロード／アップロード等）を伴う利用の場合に適している。スレッドの完了はアクションＸの完了として描かれている。アクションにおける重大なエラーは、結果としてマネージャに返却されるように示されている。実際に、１つの実施形態としては、正常終了だったのか、何らかの失敗があったのかをマネージャに通知するために、実行中の各アクションは、メッセージをマネージャに返すようになっている（メッセージがブロック１６８からブロック１６２に返されていることに注目）。重大な失敗のメッセージを受け取ると、マネージャはプログラムを続行できるか、及びアクションツリー内のさらなるアクションの処理を停止するかの判定を行う。図１２ａにあるとおり、エラーメッセージ用のダイアログボックスを表示し、これにより利用者に対してマネージャを推奨されるとおり完全に停止するか、警告にも関わらず続行するかの選択を可能にすることもできる。

前述の図から分かるとおり、マルチスレッドがＭＩＮＤＳで利用されるもう１つのソフトウェア工学の概念である。アクションが基盤イメージのダウンロードといった大きなタスクを実行しようとする場合、その大きなタスクを実行するためのスレッドが立ち上げられる。スレッドを分けて立ち上げることは、他の要求への応答を自由に行えるということである。ＭＩＮＤＳのこの実施形態では、アクションのマルチスレッド化は利用していないが、アクションの実行は非同期に行っている。ＭＩＮＤＳ内での「マルチスレッド化」の原理上の目的は、利用者の経験上の利益であって、システムの利用者への応答性がよりよくなるということである。ＭＩＮＤＳが１つのスレッドを使ってネットワークからのファイルのコピーといったアクションを実行している間、利用者はステータス情報を見ることもでき、処理を起動したり停止したりすることもできるが、それは他のスレッドが用いられるからである。反対に、もしＭＩＮＤＳが１つのスレッドしか用いていなければ、ネットワークからのファイルのコピーの最中は、プログラム全体及び表示画面が動かなくなり、利用者の入出力または画面の更新もできなくなる。スレッドが終了した際は、スレッドが完了したという通知を行うメッセージがマネージャに返却される。その最終結果として、システムは条件によってより応答性がよくなるのである。しかしながら、同じような利用者のアクションの非同期性は、真のマルチスレッド化、マルチタスク化、割込み、またはいわゆる当業者が知っている他の仕組みによっても得ることができることが理解されるべきである。

アクションのインスタンスは、アクションツリーと呼ばれる論理的なツリーにグループ化される。ＭＩＮＤＳ内の特定の操作モードは、それぞれ異なるアクションツリーに対応する。これは、ある特定のイメージ化工程が、独立したアクションツリーまたはアクションツリー内の所定の経路のいずれかになることを意味している。利用者は、どの操作モードを実行すべきかを、ＭＩＮＤＳの実行開始時に現れるメインメニューにて選択する。もし所与の時間内（例えば、３分）で選択が行われなければ、既定値の操作モードが実行される。既定値は、典型的には、共通的な操作を繰り返して行うことを認める無人モードである。

図８は、アクションツリー１８０に体系付けられたアクションの一例を示している。どのような数のアクションを利用可能としてもよいが（典型的には５以上のアクションがある）、ここでは利用可能なアクションがアクションＡ１８２からＥ１９０まで表されている。図の上部に示された利用可能なアクションは、アクションライブラリ内で利用可能なものを示す破線で描かれている。図の下部には、本発明に従って実行できるアクションツリーとなるように、ライブラリから結合されたアクションが示されている。この例では、アクションツリーは、基礎となるアクションＣ１８６を有し、そこから最初の枝としてアクションＢ１８４及び終端の前のアクションＡ１８２が分岐しており、２つ目の枝としてアクションＥ１９０、アクションＥ１９０に続くアクションＣ１８６、さらにアクションＡ１８２またはアクションＤのどちらかに分岐している。アクションライブラリ内のアクションのコーディングは再入力可能であるため、各アクションについて、望むとおりに何度でもインスタンス化されてよいことが理解されるべきである（ただし特定の機能向けに、再入力不可能なアクションもサポートすることはできる）。

アクションツリー内の各アクションは、アクションツリー内で持つことのできる子のアクションの正確な数を指定する。これら子のアクションは順番に並べられ、連番が付される。アクションが終了した際は、どの子または兄弟のアクションが次に実行されるのかの判定が求められる。この問い合わせに対して、どのアクションを次に実行すべきかを示す応答が返される。好適な実施形態においては、アクションは互いに独立しており、アクションは次に実行されるべきアクションを特定するのではなく、どの番号かだけを特定することに留意すべきである。

例えば、「はい」、「いいえ」の２つのボタンを持つダイアログであるメッセージボックスについて考えてみて欲しい。これら２つのボタンのうち１つをクリックすることで、アクションを終了することになる。アクションツリーがメッセージボックスに対してどの子アクションを次に実行すべきとして終了したかを問い合わせた際、メッセージボックスは、「はい」がクリックされれば「子１を実行」、「いいえ」がクリックされれば「子２を実行」とだけ返答する。アクションは「次にモジュールをコピーするアクションを実行」とは返答しない。その結果、アクションツリーの特定の階層構造内で所定のアクションを組合せた順列または結合とすべきということが無くなり、どのアクションも、他のどのアクションの子としても指定することができるようになる。各アクションは“共通的な”方法でマネージャに応答を返し、前述の例ではアクションツリー及びその中で定義されたポインタとして解釈される数字が提供される一方、アクションツリー自身は全ての特定のアクションへの参照を含んでいる。

各アクションは他のアクションから独立しているが、アクションは、例えば利用者の入力などの情報をアクション間で中継するための通信を行う。例えば、１つのアクションは、利用者にどのモジュールを受注仕様生産のイメージ化のために使用したいかを問合せてもよい。利用者の応答は、その後モジュールをコピーするアクションに伝えられなければならない。１つの実施形態によれば、この通信を提供する解決策としてＭＩＮＤＳの設定用クラスを介する方法がある。この設定用クラスは、全てのクラス間で中継される可能性のある情報の入れ物となる。アクションツリーは、ＭＩＮＤＳ設定用クラスを、各アクションに対してそれが実行される際に受け渡す。

図９は、単純な親子のツリー状のアクションの流れを表したアクションツリー２００を示している。ブロック２０２におけるルート（ｒｏｏｔ）へのポインタは、アクションＡ２０４と接続し、アクションＡ２０４は４つの子アクションとしてＢ２０６，Ｃ２０８，Ｄ２１０、及びＥ２１２を有している。子の選択はＤＭＩの値、利用者の入力等に依存する。図において、アクションＦ２１４及びアクションＧ２１６がアクションＢの子アクションとして実行されているように、他のアクションはそれぞれの親から順番に実行される。同様に、アクションＨ２１８、Ｉ２２０、Ｊ２２２及びＫ２２４はそれぞれの親ノードと結合している。しかしならが、図で示したこの親子関係には、例えば各アクションにどれだけの数のポインタを保持するべきなのか、またツリーを通して何回再帰を行えばいいのかが分からないという欠点があることが認識されるべきである。この例では、各アクションはアクションツリー内で持つことのできる子の数の組合せを保持し、その数は変更することができない。そうすると、例えば各アクションにとって妥当ではない数の子を持つといった、論理的に正しくないツリーが定義され得るという問題が発生する。もし論理的に正しくないツリーがＭＩＮＤＳにおいて用いられると、アクションツリーの区域（ｓｅｇｍｅｎｔ）に処理が到達しないか、悪くすれば、あるノードが次に実行すべきアクションとして存在しないものを指定し、システム停止を引き起こすかも知れない。

図１０は、アクションツリーの好適な実施形態として、アクションツリーが、最初の子と次の弟を持つ方法によって内部表現された実施形態を示している。各アクションツリーのノードは、子へのポインタ（存在しなければ空値）及び弟へのポインタ（存在しなければ空値）を保持するように構成される。この実装では、ツリー内の各ノードは２つのポインタを持つ：１つは最初の子であり、もう１つは次の弟であって、これならば小さな固定の数のポインタしか要求されない。好適な実施形態としては、例えばスタックを利用するような履歴の仕組みによって、親のポインタの利用に多くの利点をもたらしている。この方式の実装にはいくつかの利点があるが、各ノードに２つのポインタのみが求められることにより、アクションツリーのメモリが保全されることも含まれる。他の利点としては、ツリー内の経路の探索が、再帰によるツリーの走査といった単純なプロセスとなることがある。図１０に目を通せば、一般的な同じ構造が表現されている一方、プログラムにより移動を縦方向にするか横方向にするかを決められることが分かる。

これらアクションツリーは、ＭＩＮＤＳが実行時に読み込むテキストファイル内に蓄積される。そのツリーにはアクション及び他のツリーのノードへのポインタを含むが、アクションそのもの、または管理層そのものが直接アクションの参照を保持するのではないことが認識されるべきである。様々なツリーをそのファイルに蓄積することによって、ツリーの中身と順序はどんなコードをも再コンパイルする必要なく変更することができる。これにより、アクションの機能を変更しなくてもよい場合に限り、ＭＩＮＤＳに対して素早い変更が可能になる。組み立てられたツリーに対しては、論理的に正しくないツリーは許可しない方がいいため、好適には、実行前に論理的な正確性のチェックが行われる。

図１１Ａから図１１Ｅは、子−兄弟木（ｃｈｉｌｄ−ｓｉｂｌｉｎｇ ｔｒｅｅ）の走査２３０について表している。ツリーは、図１１ＡのアクションＡ２３４から出発する実行ポインタ２３６によって走査され、スタックの上端（ＴＯＳ）にはアクションＡに向けられたポインタ２３８が含まれる。図１１Ｂでは、実行はＡからＣへ進み、実行ポインタ２３６は現在アクションＣ２４６を指しており、スタックにはアクションＡへのポインタ２３８、及びＴＯＳ上にアクションＣへのポインタ２５２が含まれる。図１１Ｃでは、実行ポインタ２３６はアクションＦ２４８に位置し、アクションＦへのポインタ２５４がＴＯＳに含まれる。この例において、利用者には実行されたアクションの一覧である履歴一覧が提示され、利用者はそこから過去のいかなるアクションステップをも選択して戻ることができる。図１１Ｄでは、利用者はアクションＡ２３４に戻ることを選択し、そこでスタックからアクションＦへのポインタ２５４と、アクションＣへのポインタ２５２が取り出され、実行ポインタ２３６がスタックから再度読み込まれ、図１１ＥにおいてアクションＡの実行が再度開始される。

アクションツリーのノードは、好適には、ツリーの上を見て親を指すポインタを含まないことが認識されるべきである。スタックの仕組みは、前述したとおり、過去に実行したアクションに向けてツリーの上方向に戻る方法を提供するために利用される。スタックは、アクション名及びその特定のアクションのインスタンスへのポインタを含むが、ここでアクションは１つの所与のアクションツリー内で複数のインスタンスを持ち得るということが想起されるであろう。現在のアクションは常にスタックの上端にあり、これらポインタは過去のどのアクションにも戻れるようにスタックから取り出し得ることになっている。さらなるスタックの仕組みの利点は、データをスタック内に履歴の一部として維持できることにより、利用者が過去のどのアクションステップにも、そのステップに最後に到達した時点でのパラメータ及び構成を維持しつつ、戻ることができるという点にある。

新しいアクションをコーディングする際、前記実施形態の例によれば数多くのステップを実施しなければならないが、他の実施形態では、必ずしもそのステップは求められない。その実施形態の例においては、継承元のクラスにおいて、Ｓｔａｒｔ（）、ＳｅｔＮｕｍＣｏｉｃｅｓ（）、及びＴｅｒｍｉｎａｔｅ（）の全てを仮想関数とするべきである。この方法によって、動的結合が実現され、所望のコードがランタイムで実行される。以下がＭＩＮＤＳに新しいアクションを追加する際の基本的な手続きである：

（１）Ｍｉｎｄｓ２ｘの作業場所（ｗｏｒｋｓｐａｃｅ）が開かれているか確認する。

（２）“アクション”をアクティブプロジェクトとする（プロジェクト｜アクティブプロジェクトを設定｜アクション）。

（３）ツリーのファイル内で特定したアクションの名前として、文字列を文字列表（ｓｔｒｉｎｇ ｔａｂｌｅ）に追加する。また、画面名または当該アクションについて利用者への説明として表示する文字列を文字列表に追加する。好適には、２つの説明の１つは現在形で書き、１つは過去形で書く。このとき、新規作成した表示文字列を設定するために、コンストラクタの中でＳｅｔＤｉｓｐｌａｙＮａｍｅ（）関数を確実に呼ばなければならない。

（４）もしユーザインターフェイスを必要とするアクションを生成するのであれば、以下のことを行う；

（Ａ）使用するダイアログを生成し、所定のダイアログの識別記号を設定する（生成した各ダイアログの資源は一意の識別記号を持つ）。

（Ｂ）生成したダイアログの前記識別記号を元に、ＣＤｉａｌｏｇクラスを継承して新しいクラスを生成する。

（Ｃ）生成した前記クラスのヘッダファイルを開き、インクルードするファイルに“ＡｂｓｔｒａｃｔＡｃｔｉｏｎ．ｈ”を追加する。

（Ｄ）ヘッダファイルに、“，ｐｕｂｌｉｃ ＡｂｓｔｒａｃｔＡｃｔｉｏｎ”という記述を宣言クラスとして追記する。例として、クラス“ＵＩＡｃｔｉｏｎ：ｐｕｂｌｉｃ ＣＤｉａｌｏｇ”は“ＵＩＡｃｔｉｏｎ：ｐｕｂｌｉｃ ＣＤｉａｌｏｇ，ｐｕｂｌｉｃ ＡｂｓｔｒａｃｔＡｃｔｉｏｎ”となる。

（Ｅ）モジュールのダイアログが生成されるように、コンストラクタ内に“Ｃｒｅａｔｅ（ＩＤＤ，ｐＰａｒｅｎｔ）；”という記述を追記する。

（Ｆ）画面を消去できるように、Ｆｉｎｉｓｈｅｄ（）関数を実装し、ＡｂｓｔｒａｃｔＡｃｔｉｏｎ：：Ｆｉｎｉｓｈｅｄを呼ぶ。

もしアクションの生成においてユーザインターフェイスが必要なければ、アクションはＡｂｓｔｒａｃｔＡｃｔｉｏｎクラスから継承する。

（５）新しく生成したアクションのヘッダファイル内で、“ｒｅｓｏｕｒｃｅ．ｈ”をインクルードファイルに追加する。

（６）ＡｂｓｔｒａｃｔＡｃｔｉｏｎクラスのＳｔａｒｔ（）、Ｔｅｒｍｉｎａｔｅ（）、及びＳｅｔＮｕｍＣｈｏｉｃｅｓ（）という純粋な仮想関数を実装する。

（７）コンストラクタ内で、ＳｅｔＮｕｍＣｈｏｉｃｅｓを呼ぶ。（ここで最初の数字をゼロとするゼロ基準ではなく、最初の数字を１とする１基準（１ ｂａｓｅｄ）とする。）

（８）コンストラクタ内で、文字列表に追加された文字列から画面名（履歴及び現在の操作）を設定する。

（９）アクションが行われた際（これはゼロ基準）に、ｉＳｅｌｅｃｔｅｄＣｈｏｉｃｅ変数を設定していることを確認する。これは当該クラスのＦｉｎｉｓｈ（）関数を所定の場所またはどこか別の場所に実装することで行うことができる。

（１０）アクションがＣＤｉａｌｏｇクラスをも継承している場合は、全てのアクションは１回以上呼ばれる可能性があるため、画面が消去され、または生成されるかの動作を追跡すべきである。これは、論理型のプライベートメンバ変数を追加することによって行うのが最もよく、画面が生成または消去されたときにその変数を設定する。よって、前記変数はコンストラクタ内で設定され、Ｓｔａｒｔ（）、Ｔｅｒｍｉｎａｔｅ（）、及びＤｅｓｔｒｏｙＷｉｎｄｏｗ（）内で設定／確認される。

（１１）アクションはアクションのリストに追加される。これは、次のように行われる：

（Ａ）“ＬｉｓｔＯｆＡｃｔｉｏｎｓ．ｈ”を開く。

（Ｂ）新しく生成したクラスにインクルードを追加する。

（Ｃ）ＬｉｓｔＯｆＡｃｔｉｏｎｓ．ｃｐｐファイル内のＡｌｌｏｃａｔｅＡｃｔｉｏｎ：：Ｃｒｅａｔｅ（ＬＰＣＴＳＴＲ ｓＮａｍｅ）関数に、新しいアクションを生成するための区域を追加する。例として、アクション“ＮｅｗＡｃｔｉｏｎ”として次のコードが追加される；

もしアクションが例えばＣＲＣの生成やブリッタなどの大規模な機能を実行するのであれば、その大規模なアクションは新しいスレッドとして立ち上げられるべきである。この場合、ＷａｉｔＦｏｒＳｉｎｇｌｅＯｂｊｅｃｔ（）関数を利用するべきではない。アプリケーションスレッドが待ち状態となり、他のイベントへの応答ができず、ＭＩＮＤＳが停止したように見えるためである。その代わりに、スレッドの実行完了を待っている間に他のメッセージを処理できるように、スレッドはスレッド終了時にメッセージをアクションに返却することとすべきである。

操作モードが選択された際には、それに対応する、アクションツリーを特定するテキストファイルがアクションライブラリに渡される。ライブラリはツリーが論理的に正しいことを確認し、もし正しくなければ、ＭＩＮＤＳはエラーを表示して終了する。ツリーが論理的に正しい場合は、アクションライブラリがコンポーネントの動的割当てによってアクションツリーを生成する。その結果、アクションライブラリはツリーが論理的に正しいことを検証するだけではなく、好適には、コンポーネントの割当てと解放の責任を負い、アクションツリーの作成をも行う。つまり、ＭＩＮＤＳが用いるアクションツリーは、実行時にヒープ領域に動的に生成されるのである。

システムは、アクションツリーを生成する間、及び実行の間、数多くの検証（ｃｈｅｃｋｓ）を提供する。警告などの重大でないエラーは利用者に通知されるものの、実行は継続される。重大なエラーとは、アクションの実行時にアクションがタスクを正常に終了させられないようなエラーの発生と定義される。

図１２は、重大なエラーに関するメッセージボックス２６０の一例であり、重大なエラーが発生した際に表示されるものである。アクションは、エラーを扱うメッセージボックスを表示し、その後実行を停止すると共に、重大なエラーが発生したことをアクションツリーに通知する。アクションツリーはその後、アクションが終了して重大なエラーが起こったというメッセージをマネージャに返却する。利用者は、メッセージボックスを通して重大なエラーが起こったことを知る。この時点で、利用者はアクションを再試行するか、エラーを無視するか、またはアクションツリーの実行を中断するかを選択できる。

本発明に係る実施形態によるＭＩＮＤＳシステムを使用するために、利用者は、システムに電源を入れ、例えばＭＩＮＤＳ起動用ＣＤからシステムを起動する。ＭＩＮＤＳ起動用ＣＤは、好適には、ＣＤに含まれるＷｉｎＰＥオペレーティングシステム（または目的とする他のオペレーティングシステム）を起動する。利用者が必要とされる全ての入力を行った後、イメージ化工程は開始する。この時点で、これ以上の利用者の入力が求められることはなくなり、技術者または他の利用者はシステムの前に残らなくてもよく、選択したイメージ化工程の実行中に他の活動を行うことができる。イメージ化工程が開始した際、ハードドライブが構成され、必要なファイルがシステムに読み込まれる。システムはその後再起動し、ハードドライブに前回読み込まれたオペレーティングシステムが立ち上げられる。そしてＭＩＮＤＳは、モジュールをインストールし、システムのクリーンアップを行い、シャットダウンする。シャットダウンの後、システムは完全にイメージ化され、使用できる状態となる。

利用者が真に解放されて他のタスクを実施できるようになることを保証するため、本システムの１つの付随的な特徴として、所与のＰＣ上のイメージ化工程の状態を利用者が社内のネットワークを通して確認できる仕組みが提供されており、イメージ化工程が正常終了したのか、致命的なエラーが起こったのかを判断するために、利用者が物理的に戻る必要はなくなっている。その代わりにＭＩＮＤＳは、電子メールによるメッセージなど利用者へのメッセージを、イメージ化のエラーまたは完了に関する応答として自動生成することができる。

ＭＩＮＤＳをＷｉｎＰＥの下で運用するとき、．ＮＥＴで書かれたプログラム及びＶｉｓｕａｌＢａｓｉｃ６．０によるプログラムは動作しないことに注意すべきである。その影響で、ＭＩＮＤＳはＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＣ＋＋６．０サービスパック６によってコーディングされている。Ｃ＋＋言語を使用することにより、ＭＩＮＤＳバージョン２の設計を実装するために必要なオブジェクト指向プログラミングの特徴も提供される。

ＭＩＮＤＳの複雑なソースコードは分割され、例えば現在説明している実施形態の実装においては、２５０を超える数のファイルになっている。変更を分離し、ソースコードの管理を容易にするために、これらソースコードのファイルは、それぞれが実行オブジェクトまたはダイナミックリンクライブラリ（ＤＬＬ）に等しい６つのプロジェクトにカプセル化される。この６つのプロジェクトへのコードの分割によって、変更があった際に通常は１つのプロジェクトのみを再コンパイルすればよいため、コードのコンパイルをより素早く行うことができるという、追加的な利点を持つことになる。

ＭＩＮＤＳには、伝統的なソフトウェア工学のライフサイクルの枠組みが用いられた。従って、何らかのコーディングが始まる前に、ＭＩＮＤＳの設計の全体が文書化された。これにより、設計の不備をコーディングの開始前に発見し、修正することができた。もう１つの利点は、全ての設計時の課題が設計段階で解決されたことで、ＭＩＮＤＳのコード作成が素早い工程となった。

本発明に係る実施形態では、利用者がやり取りするための複数のＧＵＩが存在する。管理用のＧＵＩは常に表示されており、それによって利用者がＭＩＮＤＳを制御することができる。マネージャは、利用者がイメージ化工程を一時停止し、または過去のステップに戻すことを可能にするが、これは従来のＭＩＮＤＳまたは他のイメージ化システムでは不可能だったことである。加えて、利用者はコマンドプロンプト画面を開いて、ＭＩＮＤＳの設定用クラスの内容を見ることができ、または利用者の手引きを見ることができる。また、個別のアクションがＧＵＩを有してもよいことは理解されるべきである。

限定ではなく一例として、現在のシステム実装においてＭＩＮＤＳの使用時には６９個のアクションが利用可能となっている。アクションツリーは、これらのアクションをつなぎ合わせて生成される。操作モードは、典型的には別々のアクションツリーに対応し、ＭＩＮＤＳを立ち上げた際に最初に現れるメインメニューのＧＵＩから選択される。操作モードのとり得る数は無限であるが、実際には少ない数のみ実装されている。少数の操作モードは、そのモードとして利用者を認証するために、ユーザネームとパスワードを要求し、これらのモードは制限付操作モードと呼ばれる。現在の実装に従った操作モードは、９個から４１個の間のノード、つまりアクションのインスタンスを含む。イメージ化工程が４１個のアクションを含むという事実は、イメージ化が単純な工程ではないということを表している。

図１３は、メインメニュー画面２７０の一例としての実施形態であり、利用者によって選択可能な数多くのモードを示している。ここに描かれた実施形態において、メインメニュー画面は、ＭＩＮＤＳが起動した後に利用者が目にする最初のダイアログである。画面のタイトル行２７２は、説明書き２７４の表示部の隣なりに位置し、この場合はＸＸ秒以内に選択が行われないと無人モードが自動的に選択されるという、時間切れに関する付随的な通知がなされている。選択メニューの一覧２７８によって、例えば所望の一覧の項目をダブルクリックすることによって、利用者に一覧化されたどのモードを選択させることもできる。

ここでは示されていないが、特定のモードは、利用者の認証レベルまたはシステムの操作が行われているサブネット、及び他の制限に関する基準に依存して、アクセス不可とされるか、一覧化さえされないようにしてもよいことが理解されるべきである。この実施形態においては、利用者はＳＭＳ（またはソニーのＶＳＭＳ）のユーザネームとパスワードによってログインを要求される。利用者が権限の無いアクションの実行を試行した場合には、エラーを発生させることができる。代わりに、利用者に所与のアクションを実行する権限が無ければ、一覧化された項目を選択不能にし、好適には、選択不能であることを淡い縁取りや影付などに限られない方法で、画面に表示してもよい。

ＭＩＮＤＳは、イメージ化の操作モードがどれだけの数であってもサポートすることができると理解されるべきであるが、限定ではなく例として、図示されたようなモードを含む。（１）無人モード（Ｕｎａｔｔｅｎｄｅｄ Ｍｏｄｅ）−ＭＩＮＤＳバージョン２の既定値のモードであり、利用者が起動後３分の間に他を選択しなければ選択される。このモードでは、所与のシステムのＤＭＩを用いて、ＶＳＭＳ内で特定されたコンポーネントにより、システムがイメージ化される。（２）工場用モード（Ｆａｃｔｏｒｙ Ｍｏｄｅ）−無人モードに似ているが、ＶＳＭＳの代わりに工場用のデータソースが用いられるモード。（３）在庫管理単位選択（ＳＫＵ Ｓｅｌｅｃｔｉｏｎ）−利用者が選択したプロジェクトの基準によりコンポーネントを選定できるモード。（４）上級モード（Ａｄｖａｎｃｅｄ Ｍｏｄｅ）−在庫管理単位選択に似ているが、いくつかのコンポーネントについて古いバージョンも選択できるなど、利用者により多くの選択肢が与えられるモード。このモードは、全ての操作モードの中で、利用者に最も多くのカスタマイズを提供する。（５）自由ダウンロード（Ｆｒｅｅｓｔｙｌｅ Ｄｏｗｎｌｏａｄ）−利用者が全体のイメージ化工程を実施することなく基盤イメージをシステムにダウンロードできる、制限付の操作モード。（６）一体型イメージダウンロード（Ｍｏｎｏｌｉｔｈｉｃ Ｉｍａｇｅ Ｄｏｗｎｌｏａｄ）−在庫管理選択に似ているが、利用者によるイメージ化工程の制御をより多く認める制限付操作モード。（７）イメージアップロード（Ｕｐｌｏａｄ Ｉｍａｇｅ）−基盤イメージをシステムから取得してイメージ保存サーバへアップロードする、制限付操作モード。イメージはクリーンアップされ、アップロードの開始前にイメージ識別子が設定される。（８）自由アップロード（Ｆｒｅｅｓｔｙｌｅ Ｕｐｌｏａｄ）−イメージをＬＡＮ内のどこへでもアップロードできる制限付操作モード。前記イメージアップロードモードにおいてサーバへアップロードされるイメージと異なり、これらのイメージは変更されることが無い。（９）Ｍコード用フロッピー（登録商標）作成（Ｃｒｅａｔｅ Ｍｃｏｄｅ Ｆｌｏｐｐｙ）−システムのＤＭＩを記述したＭコード用のフロッピー（登録商標）を利用者が作成できるモード。なお、イメージに関連するどのような機能を実行するための他のモードも、生成することができると理解されるべきである。

図１４は、本発明に係るこの実施形態例において用いられる、ステータス画面２９０を示している。ステータス画面は、好適には、ＭＩＮＤＳモードが選択された際に表示され、ＭＩＮＤＳシステムが開いている間は表示され続ける。タイトルブロック２９２が画面内のステータス表示部の上に見えており、ステータス表示部には、一連の利用者が選択する命令２９６−３０６が、仮想的な画面上のボタンとして表示されている。そのボタンは、ウィンドウに基づくＧＵＩの枠組みによるボタンや他の選択用部品などの、伝統的などの方法によっても実装し、位置指定装置、接触型表示装置、または同様の装置によって選択することができる。典型的には、例えば選択不能な項目を薄い色で表示し、または全く非表示にするといったことにより、所定の時点で選択可能な利用者のステータス命令のみが選択できるように表示される。

“ＭＩＮＤＳの終了”ボタン２９６は、利用者がアプリケーションを終了し、システムを再起動できるようにするために表示されている。“メインメニュー”ボタン２９８は、利用者が現在の活動を破棄し、好適には一時停止し、別の操作モードを選択するために（または現在選択しているモードを再開するために）メインメニューに戻れるように表示されている。この実施形態においてメインメニューボタンを選択すると、現在使用しているデータはいずれも破棄されるか、またはその代わりに、新しいモード及び構成に干渉しないように別の場所に保存される。メインメニューを選択すると、ＭＩＮＤＳシステムは再起動することなく開始される。“ステップ”ボタン３００は、利用者がアクションツリー内のアクションといったステップごとに工程を実行できるように表示される。ステップの実行は、“中断（Ｂｒｅａｋ）”命令または直前の“ステップ”命令に対する応答時など、システムが一時停止しているときにのみ行うことができる。“ヘルプ”ボタン３０２により、モードや利用者にとって利用可能な他の選択肢に関する情報を提示することができる。

“詳細”ボタン３０４は、ＭＩＮＤＳシステムに使用されている現在のデータを表示する窓を開いたり閉じたりするために用いられる（例えば、“詳細＞＞”は開くことを、“詳細＜＜”は閉じることを示す）。ここで表示されるデータの組合せは、ソフトウェアコンポーネント、現在の操作モードなどを含んでいる。“中断”／“再開”ボタン３０６により、利用者は、現在の操作が完了した後に実行を一時停止することができる。システムが中断命令を実行して一時停止すると、ボタンには“再開”と表示され、利用者はそれにより実行を再開することができる。本実施形態においては、“メインメニュー”、“ＭＩＮＤＳの終了”及び“ステップ”ボタンは、“中断”ボタンが押されるなどして実行が一時停止していない限り表示されない。加えて利用者は、一時停止している間、一覧からステップを選択する手続によって、過去のどのステップにも戻ることを選択できる。

ステータス行３０８は、現在の操作モードを示している。履歴ステータス領域３１０は、例えば原子性を持つとされる各アクションを１行に表示するといった形で、これまでどのアクションが実行されたかの記録（ｌｏｇ）を示している。本発明に係るこの実施形態によれば、一覧の最後の項目が、一番最近行われたアクションである。工程を一時停止すると、利用者は、例えば所望の一覧の項目をダブルクリックするなどして、これらのうちどのステップを選択し、過去のそのステップに戻ることもできる。もう１つのステータス行３１２は、アクションツリー内で現在実行されている処理を表示している。

デバッグ用画面３１４は、利用者がイメージ化工程をより制御できるように表示される。この例においては、利用者は初期設定用ファイル（Ｉｎｉ ｆｉｌｅ）から設定を読み込み（３１６）、初期設定用ファイルから設定を保存し（３１８）、“ＰａｃｉｆｉｃＩｎｉ”から設定情報を取得し（３２０）、設定を消去し（３２２）、及びコマンドプロンプト画面を立ち上げることができる（３２４）。

時間ステータス表示領域３２６には、現在のシステム時間、ＭＩＮＤＳが実行を開始してからの経過時間、及び工程内の所与のステップの時間など付随的な他の時間関連の状況が表示される。

図１５Ａ及び図１５Ｂは、現在のイメージダウンロード状況下でどのイメージを一緒に用いるかを決定するための、基本単位選択画面３３０を描いている。タイトル行３３２はステータス表示ボックス３３４の上に表示され、ステータス表示ボックス３３４は説明書き及び一連の選択肢３３６を表示する。選択画面３３６の中では、コンボボックス３３８から３５０に描かれたような、基本単位を確立するための数多くのパラメータが入力できるようになっている。

例えば在庫管理単位選択や上級モード、イメージアップロード及びＭコード用フロッピー（登録商標）の作成などの特定の操作モードによって操作を行う際には、基本単位を選択しなければならない。限定としてではなく例としては、基本単位の選択は、簡単に述べているような操作モードに依存する。在庫管理単位モードでは、利用者は現在割り当てられたイメージのみをネットワーク上に存在する場合に選択できる。もし利用者がプロジェクトの選択を試行してイメージが見つからなければ、利用可能なイメージが無いという警告が表示され、他のイメージの選択に導かれる。上級モードでは、利用者は、ネットワーク上で利用できる限り基本単位に割り当てられた全てのイメージを選択できる。イメージアップロードモードでは、利用者はプロジェクトに割り当てられたことのあるイメージを選択できる。利用者は対象システムからイメージをアップロードするため、基本単位向けのイメージはネットワーク上にアップロードの前から存在する必要が無いことは理解されるであろう。Ｍコード用フロッピー（登録商標）の作成モードでは、利用者はプロジェクトに割り当てられたことのある全てのイメージを選択できる。

基本単位の選択は、多くのフィールドに対する選択実行または既定値の容認により行われ、本実施形態では、そのフィールドは、プロジェクト（Ｐｒｏｊｅｃｔｓ）３３８、基本単位モデル番号（Ｂａｓｅ Ｕｎｉｔｓ）３４０、Ｐコード（Ｐｃｏｄｅ）３４２、販売タイプ（Ｓａｌｅｓ Ｔｙｐｅ）３４４、コンポーネント（Ｃｏｍｐｏｎｅｎｔ）３４６、ＢＬＩＤ３４８及びソフトウェアリリース（Ｓｏｆｔｗａｒｅ ｒｅｌｅａｓｅ）３５０として具体化されている。利用者がダウンロードのための特定のイメージを掘り下げて選択できるように、プルダウンメニューが設計されている。そのため、選択用のユーザインターフェイス（ＵＩ）は、最上位にモデル番号／名（基本単位）３４０（例えばＰＣＧ−Ｓ２６０）を配置するところから始まり、下に向かってユニットを十分詳細化していけるように作用する。これらフィールドの大きさと構成は、本発明に係る１つの実施形態として表現されたものであって、いわゆる当業者であれば、発明としての困難さを伴うことなく容易に変更することができるものであり、その結果としての実施形態も本発明の開示の範囲に含まれることは理解されるべきである。

Ｐコード３４２は、ＰＣ（例えばＶＡＩＯモデルなど）の下位のカテゴリであり、本実施形態においては、４桁の英数字による特定記号を含む。例としては、モデル番号ＰＣＧ−Ｓ２６０に対して、ＰＣＧ−Ｓ２６０の無線ＬＡＮモジュール無しならばＰコードはＳ００１、ＰＣＧ−Ｓ２６０の無線ＬＡＮモジュール有りならばＰコードはＳ００２といった形で、２つの異なるＰコードが存在し得る。モデル番号とＰコードのフィールドは共に、好適には、イメージ化で使用するためにＢＩＯＳのＤＭＩ領域に書き込まれる。

販売タイプ３４４は、販売経路ごとに異なるソフトウェアモジュールを特定するために、ＳＭＳのデータベース内で割当てることのできるカテゴリである。例えば、受注仕様生産の小売向けの販売タイプ（“ＣＴＯ”）を持つＰＣモデルは、企業間取引用の販売タイプ（“Ｂ２Ｂ”）を持つＰＣモデルと比較して、完全に異なるオプションのソフトウェアによってイメージ化され得る。この場合、販売タイプ“ＣＴＯ”は、家庭内の利用者向けの、一般的にゲームや音楽用ソフトウェアを含む電子ソリューション（Ｅ−Ｓｏｌｕｔｉｏｎ）を通して提供され、一方販売タイプ“Ｂ２Ｂ”は、企業向けの大規模な販売チャネルを通して提供され、生産性ソフトウェア（ｐｒｏｄｕｃｔｉｖｉｔｙ ｓｏｆｔｗａｒｅ）を含むかも知れない。この方法により、製造者は、様々なアプリケーションを特定の市場のセグメントに向けて提供できる（例えば、家庭用、企業用、ゲーム愛好家用、マルチメディア用、ＣＡＤ用、サーバ用など）。つまり、様々な販売タイプによって、ＰＣの特徴を、モデル番号やＰコードを変えることなくさらに洗練させることができるのである。

コンポーネント３４６は試験時に内部的に使用できるフィールドである。このフィールドによって、例えばソフトウェアモジュールが既に１つの完全なイメージに組み立てられた際に、“一体型の（ｍｏｎｏｌｉｔｈｉｃ）”イメージが導入されるのかどうかといったような、システムに導入される選択に関する情報を提供できる。“コンポーネント”フィールドの選択によって、一般的には、例えば試験部門といったような部署において使用するイメージの組合せの選択を行うことができる。

ＢＬＩＤ３４８は“ＢＩＯＳロック識別子”を意味し、ＰＣモデルに対する特定のイメージの組合せを指定するものである。例えば、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ ＨＥ（ホームエディション）のイメージは、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ Ｐｒｏ（プロフェッショナル）のイメージとは異なるＢＬＩＤを持つだろう。いくつかの場合において、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ ＨＥと共に出荷されるＰＣは、同じハードウェアだがＷｉｎｄｏｗｓ（登録商標）ＸＰ Ｐｒｏと共に出荷されるＰＣとは異なるモデル名またはＰコードを持つかもしれない。しかしながら、いくつかの場合ではモデル名及びＰコードは同一であり、このフィールドによって、特にモデル番号の割当てが技術領域をまたがって行われたような場合において、製造者が第二の場合を制御することができる。

ＢＬＩＤは、好適には、出荷されたイメージに対する海賊行為を防ぐためにも使われる。もし利用者がシステムの回復プロセスを立ち上げたときに、回復用イメージ内のＢＬＩＤと製造者がＢＩＯＳのＤＭＩ区域に書き込んだＢＬＩＤが一致しなければ、回復プロセスは停止し、利用者に警告メッセージが表示される。この安全対策は、例えば、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ ＨＥのＰＣを購入した利用者が、その回復用媒体をＷｉｎｄｏｗｓ（登録商標）ＸＰ Ｐｒｏと共に出荷された同じモデルのＰＣに使用するといったことを防ぐことになる。

ソフトウェアリリース３５０により、同じイメージにおける異なる繰り返し（ｉｔｅｒａｔｉｏｎ）の選択を行うことができる。現代の製造者または製造部門における開発サイクルの中で、欠陥を修正し新しいバージョンを公開することにより、２つまたはそれ以上の同じイメージの繰り返しを有することは、珍しいことではない。このフィールドに対する望ましい既定値の選択肢は、試験が終わり基本単位に割り当てられた最新版になるが、プルダウンメニューによって試験の間に異なるイメージの版を選択して既定値を上書きすることができる。

従って、ＭＩＮＤＳシステムによるダウンロードすべきイメージの判定は、利用者が１つまたはそれ以上のパラメータを設定し、または規定値を許容したことに対する応答として行うことができる。

一度全てのフィールドが選択され、及び／または文字列が入力されると、基本単位の画面は図１５Ｂのように表示され、利用者はＯＫボタンを押して選択結果を受け入れるように促される。基本単位画面において、本発明の前記特徴から外れることなく、既定の要素をどういった形に選択してもよいことは理解されるべきである。例えば、フィールドの値は、最新の活動や利用傾向などに従って新しい画面で投入されてもよい。一度選択に満足したならば、利用者はＯＫボタン３５２を押下して基本単位の選択結果を実行することができる。

図１６は、一例として、本発明に係る実施形態によるモジュール及びスイッチ選択画面３７０を示している。タイトル行３７２が選択部品の組合せ３７４の上部に表示されており、選択部品はＯＫボタン（送信のための選択）を伴うコンボボックスとして描かれている。モジュール及びスイッチの選択は、特に在庫管理単位、上級モード、Ｍコード用フロッピー（登録商標）の作成モードなどの特定のＭＩＮＤＳの操作モードにおいて、必要な場合、または許可された場合にのみ行われる。チェックボックスは、該当する要素がイメージの組合せの中に含まれるべきである場合にチェックされる。基本単位のタイプに依存して、チェックボックスのいくつかは要求の通りに選択不能となる。１つの基本単位の中で現れる項目は、他の基本単位の選択画面では現れないかもしれない。というのも、基本単位の選択によってモジュール及びスイッチが同時に利用され得る範囲が決まるためである。典型的には、小売のユニットを生成する場合には、全てのコンボボックスが選択不能となる一方、上級モード及びＭコード用フロッピー（登録商標）の作成モードでは過去のバージョンと構成が利用可能となる。結果として、ＭＩＮＤＳは、対象システムに完全な部品表（ＢＯＭ）をコピーする機能を構成することとなる。

イメージ化工程は常に進化しており、その結果ＭＩＮＤＳはその変化と同期をとるために頻繁に更新される。ＭＩＮＤＳはしばしば、対象のコンピュータシステムの新しい特性に対応するためにも更新される。ＲＡＩＤはその一例である。こういった更新を行う場合に１つの要所として優先されるのは、設計文書も同時に最新化することである。これは、近年のソフトウェア工学における保守の主要な考え方の１つである。

高度にコンピュータ化されたシステムを開発、試験する間において、システムをイメージ化し直すタスクは頻繁に行われる。ＭＩＮＤＳシステムは、様々な革新的な特徴を持つと同時に、広範囲のイメージの組合せを容易にサポートできる機能を提供することにより、サポートのオーバーヘッド（工数）を削減し、イメージ化に掛かる時間の遅延を短縮し、またソフトウェア開発のコストを低減するといった投資に対する大幅な利益をもたらすことができる。ここで述べられた１つの重要な革新とは、ＭＩＮＤＳ内における、所望のプロセスを定義する、アクションツリーを形成するための交換可能な建築部品のようなアクションの使用である。本発明に係るこの特徴は、イメージ化工程を新しく生成する方法も変えるものである。ＭＩＮＤＳによって、以前はソフトウェア開発の実践であったものが、十分な量のいわゆるレゴ（登録商標）ブロックの供給によって所望のどのような小さな構造をも構築できるといったような、ブロックの組み立て工程に変化したのである。ＭＩＮＤＳのこの柔軟な枠組みは、本発明の開示範囲から外れることなく、ソフトウェアのイメージ化以外の多くの形態の工程においても利用することができる。

前述の説明は多くの詳細な記述を含んでいるものの、それにより本発明の技術的範囲を制限するように解釈するべきではなく、単に本発明に係る実施形態のうち現時点で好適ないくつかについての説明を提供しているのみである。それ故、本発明の技術的範囲は、いわゆる当業者にとって明白となる他の実施形態を広く包含するものであり、従って本発明の技術的範囲は添付した特許請求の範囲以外のいかなるものによっても制限されるべきではない。ここでの単数の要素への言及は、特にそう記述した場合を除いて“１つ、またはただ１つ”を意味するものではなく、“１つまたはそれ以上”を意味する。前述の好適な実施形態の要素と構造的かつ機能的に同等であって、いわゆる当業者に知られた全ての要素は、ここでの言及に明確に含まれ、本発明の特許請求の範囲に包含されるように意図する。さらに、任意の装置または方法は、本発明が解決しようとする各課題の全てに取り組むことを要さずとも、本特許請求の範囲に包含される。また、本開示範囲内のどのような要素、コンポーネント、または方法におけるステップも、その要素、コンポーネント、または方法におけるステップが特許請求の範囲において明記されているかに関わらず、公衆に解放されることを意図するものではない。また、ここでの特許請求の範囲のどの要素も、“する手段（ｍｅａｎｓ ｆｏｒ）”という句を用いて明記した場合でない限り、米国特許法第１１２条第６項の既定に従って解釈されるべきではない。

コンピュータのハードドライブにダウンロードされるソフトウェアイメージに関するブロック図である。 本発明に係る実施形態による、モジュール式のネットワークダウンロードシステムに対する入出力のブロック図として、図中左のネットワーク上の資源とＭＩＮＤＳプログラムのやり取りを示している。 本発明に係る実施形態による、モジュール式のネットワークダウンロードシステムのフローモデルである。 本発明に係る実施形態による、モジュール式のネットワークダウンロードシステムのクラス階層モデルである。 本発明に係る実施形態による、モジュール式のネットワークダウンロードシステムの階層に関するブロック図であり、ユーザインターフェイス（ＵＩＦ）層、管理層及びアクション層を示している。 本発明に係る実施形態による、モジュール式のネットワークダウンロードシステム内のモジュールのブロック図である。 本発明の１つの特徴に従って管理層がアクションの実行を要求する際のフローチャートである。 本発明の１つの特徴に従って相互接続したアクションツリーのモデルであり、利用可能なアクション、及びそれらアクションのインスタンスを用いるアクションツリーの実装の一例を示している。 本発明の１つの観点によるアクションツリーの一例であり、ツリー内で１つまたはそれ以上の子関係を有するツリーを示している。 本発明の１つの観点によるアクションツリーの一例であり、ツリー内で１つの子、１つの兄弟関係を有するツリーを示している。 本発明の１つの観点によるツリーの走査の一例であり、スタックの内容に関連してアクションが実行される様子を示している。 本発明の１つの観点によるツリーの走査の一例であり、スタックの内容に関連してアクションが実行される様子を示している。 本発明の１つの観点によるツリーの走査の一例であり、スタックの内容に関連してアクションが実行される様子を示している。 本発明の１つの観点によるツリーの走査の一例であり、スタックの内容に関連してアクションが実行される様子を示している。 本発明の１つの観点によるツリーの走査の一例であり、スタックの内容に関連してアクションが実行される様子を示している。に関連してアクションが実行される様子を示している。 本発明の１つの観点によるエラー画面の画面例の図である。 本発明の１つの観点によるメインメニュー画面の画面例の図であり、選択可能な操作のモデルを示している。 本発明の１つの観点によるステータス表示及び制御画面の画面例の図であり、アクション履歴、時間、現在の操作及び命令のオプションを示している。 本発明の１つの観点による基本単位選択画面の画面例の図である。 本発明の１つの観点による基本単位選択画面の画面例の図である。 本発明の１つの観点によるモジュール及びスイッチ選択画面の画面例の図である。

Claims (20)

1. コンピュータ上のソフトウェアプログラムイメージを自動的に構成する装置であって：
   コンピュータ上のプログラムイメージを構成するためのイメージファイルをネットワーク経由で入手するよう構成された、モジュール式ネットワークダウンロードプログラムと；
   前記モジュール式ネットワークダウンロードプログラム内で特定の操作を行うようにそれぞれ構成された複数のアクションルーチンと；
   前記モジュール式ネットワークダウンロードプログラムによって実行されるツリー状の前記アクションルーチンを定義する手段と；
   を備える装置。
2. 前記アクションルーチンは、前記モジュール式ネットワークダウンロードプログラムと動的に結合されることを特徴とする、請求項１に記載の装置。
3. 前記ツリー状の前記アクションルーチンは、コンパイル不要の構成ファイル内にテキスト形式で定義されることを特徴とする、請求項１に記載の装置。
4. 前記モジュール式ネットワークダウンロードプログラムは：
   前記アクションツリーの走査の間にアクションを実行するように構成された管理層と；
   所望の自動インストールを実行するための前記管理層の操作を制御するよう構成されたユーザインターフェイスと；
   を備えることを特徴とする、請求項１に記載の装置。
5. コンピュータ上のソフトウェアプログラムイメージを自動的に構成する装置であって：
   動的に結合され、ソフトウェアの自動インストールの間に実行される、複数のアクションを有するアクションツリー層と；
   前記アクションツリー層からのアクションを指す少なくとも１つのポインタをそれぞれ含むノードを、複数有する少なくとも１つのアクションツリーと；
   前記アクションツリーの走査の間にアクションを実行するように構成された管理層と；
   所望の自動インストールを実行するための前記管理層の操作を制御するよう構成されたユーザインターフェイスと；
   を備える装置。
6. 前記アクションルーチンの前記ツリーは、コンパイル不要の構成ファイル内にテキスト形式で定義されることを特徴とする、請求項５に記載の装置。
7. 前記アクションは、機能的に独立したアクションであって、所与のアクションツリー内で、及び異なるアクションツリーをまたがって使用され得ることを特徴とする、請求項５に記載の装置。
8. 前記アクションは、そのうちいずれかを別の実行スレッドとして立ち上げることができ、それによりアクションが他の要求に対して応答できることを特徴とする、請求項５に記載の装置。
9. 特定のアクションツリーは、操作モードとして前記ユーザインターフェイスにより選択可能であることを特徴とする、請求項５に記載の装置。
10. 前記ユーザインターフェイスを通して、若しくは前記アクション自体により生成されたユーザインターフェイス、または両方のユーザインターフェイスの組合せを用いて、前記アクションと利用者が対話することを特徴とする、請求項５に記載の装置。
11. 前記ソフトウェアプログラムイメージは、単一の基盤イメージ、または単一の基盤イメージの組合せと、少なくとも１つのアプリケーションプログラムモジュールを含むことを特徴とする、請求項５に記載の装置。
12. 前記管理層は、前記アクションツリー内の変更、及び前記アクションツリー層内の異なるアクションの結合と解放への応答として、再コンパイルを必要としないことを特徴とする、請求項５に記載の装置。
13. 前記アクションツリーの各々の前記ノードは、アクションを指すポインタ、アクションツリーの子ノードを指すポインタ、及びアクションツリーの兄弟ノードを指すポインタを含むことを特徴とする、請求項５に記載の装置。
14. 前記ユーザインターフェイスは、利用者に前記装置の操作モードを選択させられるように構成されることを特徴とする、請求項５に記載の装置。
15. 前記操作モードは、操作モードの集合から選択可能であり、その集合は本質的に：無人モード、工場用モード、コンポーネント選択モード、拡張されたコンポーネント選択モード、基盤イメージアップロード、及び自由イメージアップロード／ダウンロード、を含むことを特徴とする、請求項１４に記載の装置。
16. あるアクションを指す前記ポインタは、特定のアクションではなく、そのアクションに係るアクションツリー内の位置を指定し；
    アクション自体が互いに独立を保っていることを特徴とする、請求項５に記載の装置。
17. １つまたはそれ以上の前記アクションは、処理用のアクションの集合からアクションツリー内で実行のために選択可能であり、その集合は本質的に：Ｍコード用の媒体の作成、システムのデスクトップ管理インターフェイス（ＤＭＩ）からのＭコードのアップロード、システムのハードドライブへの基盤イメージのダウンロード、システムのハードドライブへのアプリケーションモジュールイメージのダウンロード、システムのハードドライブからの基盤イメージのアップロード、システムのハードドライブからのアプリケーションモジュールイメージのアップロード、回復用パーティションからの基盤イメージの回復、
    媒体のバージョン検証、ブリッタ、対象ドライブの割当て、基本単位の選択、イメージのクリーンアップと不要なファイルの削除、回復用パーティションへのイメージのコピー、パーティションへのモジュールのコピー、イメージの巡回冗長検査の生成、Ｍコード用のフロッピーの作成、起動画面の表示、デスクトップ管理インターフェイスの比較の表示、媒体の取り出し、正しい対象ドライブの検索、ハードドライブ情報の取得、ネットワークサブネット上かどうかの検証、実行記録セッションの終了、ネットワークドライブ図の表示、クエリの分割、ハードドライブの分割、再起動、制限ログイン、メインメニューへ戻る、イメージコンポーネントの存在検証、スレッドの生成、から構成されることを特徴とする、請求項５に記載の装置。
18. コンピュータをソフトウェアプログラムイメージによって構成する方法であって：
    コンピュータ上でイメージ構成アクションを実行する別々の実行可能なアクションの組合せを生成及びコンパイルし；
    選択されたアクションツリー内で定義されたアクションを実行する管理層を生成及びコンパイルし；
    アクションツリーの選択とアクションツリーの実行を制御するユーザインターフェイス層を生成及びコンパイルし；
    アクション及び前記アクションツリー内の他のノードを指すポインタを含むノードを、複数有するアクションツリー構造を生成し；
    アクション、管理層、ユーザインターフェイス層及びアクションツリーを結合して、利用者の入力に応じてアクションツリー内で定義されたアクションを実行するプログラムを生成する；
    方法。
19. 前記アクションツリーの構造は、子の関係のポインタ、兄弟の関係のポインタ、または子及び兄弟の関係のポインタの組合せに応じて互いに接続されたノードを含み；
    前記ポインタの関係は、アクションツリー内においてアクションが位置しているノードの位置を指すポインタを含むことを特徴とする；
    請求項１８に記載の方法。
20. 前記ソフトウェアプログラムイメージは、単一の基盤イメージの組合せ及び少なくとも１つのアプリケーションプログラムモジュールを含むことを特徴とする、請求項１８に記載の方法。

Images