JP2005327274A - 効率的なパッチ当て - Google Patents

Abstract

【課題】 対象コンピュータシステムのソフトウェアを増補する機構を説明する。
【解決手段】 本機構は、対象コンピュータシステムで増補指定を受け取る。増補指定は、（ａ）増補される機能、（ｂ）テストされる機能のパラメータ、（ｃ）指定されたパラメータに適用されるテスト、および（ｄ）指定されたテストが指定されたパラメータによって満足されない場合に機能の挙動に対して実行される変更を指定する。指定された機能が、対象コンピュータシステムで呼び出される時、指定されたテストが指定されたパラメータによって満足されない場合、本機構は、指定された機能の挙動の指定された変更を実行する。
【選択図】 図６

Description

本発明は、インストールされたコンピュータプログラムの動作の更新の分野に関する。

パッチ当てとは、アプリケーションプログラム、ユーティリティプログラム、オペレーティングシステムおよびオペレーティングシステムコンポーネント、装置ドライバなどを含む既にインストールされているプログラムを変更する処理である。パッチ当ては、プログラミングエラーの訂正、セキュリティリスクの減少または除去、または変更されたプログラムによって使用される論理の改善を含む様々な目的のためのプログラムの変更に有用であり得る。パッチ当ては、通常、パッチを当てられるプログラムを最初に供給した会社または他の組織によって開始される。

インストールされたプログラムは、主に、実行可能コードモジュールからなる。一例として、米国ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ社のＷＩＮＤＯＷＳ（登録商標）ＸＰオペレーティングシステムで実行されるように設計された多くのプログラムが、主に「ＤＬＬ」と称する実行可能コードモジュールからなる。パッチ当ての１つのよく知られている従来の手法は、パッチをあてられるインストール済みのプログラムを構成する実行コードモジュールの中から、パッチによって変更することが望まれるプログラムコードを含む実行可能コードモジュールを識別し；所望の変更が行われた、識別された実行可能コードモジュールの新しいバージョンを作成し；識別された実行可能コードモジュールの新しいバージョンを、インストーラプログラムと共に、パッチの適用を望む可能性があるユーザに配布することである。各ユーザは、パッチの適用を望むかどうかを判定し、適用を望む場合、インストーラプログラムを実行する。これによって、識別された実行可能コードモジュールのオリジナルバージョンが、識別された実行コードモジュールの新しいバージョンに置換される。

米国特許出願公開第１０／３０７，９０２号明細書

パッチ当ての従来の手法は、複数の重要な不利益を有する。多くの場合、パッチの受け取りおよび適用に関連する負担を増すという不利益をもたらす。ある場合には、負担の増加が、一部のユーザによる一部のパッチの適用を遅らせ、一部のユーザによる一部のパッチの適用を妨げもする。そのようなパッチ適用の遅延および阻害は、ある場合には、特にセキュリティリスクを減少しまたは除去するために設計されたパッチの場合には、ユーザにとって深刻で否定的な結果をもたらす可能性がある。

パッチ当てに関する従来の手法の１つの不利益は、単一のプログラムに対する単一の変更をもたらすために複数のパッチを作成し、配布しなければならない一般的な状況に関連する。ある場合、パッチをあてられるプログラムは、プログラムがそこで実行されるように設計されたオペレーティングシステムまたはオペレーティングシステムバージョンごとにおよび／またはプログラムの自然言語バージョンごとに異なる「フレイバ（ｆｌａｖｏｒ）」など、特定の実行可能コードモジュールの複数の異なるフレイバを有する。識別された実行可能コードモジュールが、そのような実行可能コードモジュールである場合、前述したパッチ作成配布プロセスを、識別された実行可能コードモジュールのフレイバごとに繰り返さなければならない。ユーザは、識別された実行可能コードモジュールの適当なフレイバ用のパッチを選択し、適用しなければならない。結果として生じた多数のパッチをソートし、各ユーザのコンピュータシステムのアプリケーションに正しいパッチ群を選択することは、非常に負担になる可能性がある。この状態は、時折「パッチ地獄」と呼ばれる。ある場合には、管理者は、各対象システムにインストールされた実行可能モジュールバージョン群を識別するインベントリデータベースを維持しなければない。これは、各対象システムに適当な従来のパッチを選択するのに使用される。

パッチ当てに対する従来の手法のもう１つの不利益は、配布されるパッチのサイズが大きいことに関する。実行可能コードモジュールが、メガバイト単位のサイズを有することがめずらしくない。その故、単一のパッチが匹敵するサイズを有し、配布と保管が手に負えなくなり、一部のユーザにとって配布および保管が不可能になる。この問題は、複数のフレイバを有するパッチのために、複合的になる可能性がある。さらに、各従来のパッチに、通常は、置換実行可能モジュール全体が含まれるので、従来のパッチの適用は、コードチャーン（ｃｏｄｅ ｃｈｕｒｎ）の問題に寄与する可能性がある。

パッチ当てに対する従来の手法のさらにもう１つの不利益は、一部のユーザが、実動コンピュータシステムに適用する前にパッチをテストする必要に関する。ある場合、コンピュータシステムへのパッチのインストールは、パッチに含まれる識別された実行可能コードモジュールの新しいバージョンが新しいプログラミングエラーを導入する場合、またはそれが適用されるコンピュータシステムで動作する別のプログラムとの新しい予期されない相互作用を引き起こす場合など、悪い結果を有する可能性がある。したがって、多くの場合、そのデータおよび動作の維持が重要である実動システムにパッチを適用する前に、ユーザは、まず、テストシステムにパッチを適用して、そのパッチを実動ステムに適用しても安全であるか否かを評価する。パッチのそのような別々のテストは、パッチ当てに関連する負担を増やす。さらに、パッチが適用されてから十分に後に、従来のパッチが（アプリケーション互換性の問題または新しいエクスプロイト脆弱性など）問題を起こす場合に、その問題をパッチまでさかのぼって追跡することが困難になる可能性がある。

パッチ当てに対する従来の手法のさらなる不利益は、パッチに含まれるインストーラの動作に関する。多くの場合、実行プログラムの一部である実行可能コードモジュールを置換するために、インストーラは、まずそのプログラムの実行を終わらせなければならない。また、ある場合、そのような置換は、コンピュータシステムを再起動しなければ完了することができない。この両ステップは、パッチをあてられるコンピュータシステムの使用にかなりの混乱を引き起こす可能性がある。

パッチ当てに対する従来の手法のもう１つの不利益は、「ホットフィックス」とも称する「プライベートフィックス（ｐｒｉｖａｔｅ ｆｉｘ）」が、その実行可能モジュールの顧客の正しいサブセットに以前に発行された実行可能モジュールにパッチを当てることに関する。その場合、ユーザがそのホットフィックスを適用したか否かによって各ユーザに依存する実行可能コードモジュールを、異なる新しいバージョンに置換する従来のパッチの配布で出会う問題のために、それに替えて、ユーザがホットフィックスを適用したか否かに無関係に実行可能モジュールの単一の新しいバージョンに置換する単純な従来のパッチの配布が通常である。その新しいバージョンがホットフィックスを実装する場合、そのパッチは、ホットフィックスを受け取ることを意図されていない顧客にホットフィックスを課す。その一方で、新しいバージョンがホットフィックスを実施しない場合、ホットフィックスを受け取ることが意図された顧客にホットフィックスを与えない。

パッチ当てに対する従来の手法のもう１つの不利益は、特定のダイナミックリンクライブラリなど、特定の実行可能モジュールに頼るソフトウェア製品のインストーラが、多くの場合、対象コンピュータシステムのファイルシステムにおいて標準的でない位置にその実行可能モジュールを保管することにより、その実行可能モジュールを「隠す」という事実に関する。したがって、特定の対象システムに、パッチをあてるべき実行可能モジュールのコピーが含まれるか否かを判定し、そうである場合にそれが対象コンピュータシステムのファイルシステムの何処にあるかを判定することが、しばしば困難または不可能である。また、いくつかのソフトウェア製品は、そのインストーラによってインストールされた実行可能モジュールバージョンの「カタログ」を維持する。ソフトウェア製品は、特定の実行可能モジュールのバージョンのカタログ内の表示の正しさに頼る可能性がある。そのような信用は、従来のパッチが、カタログを更新せずに、カタログで識別される実行可能モジュールのバージョンをその実行可能モジュールの新しいバージョンに置換する場合に失われる。

パッチ当てに対する従来の手法のもう１つの不利益は、パッチを当てられる実行可能モジュールが対象コンピュータシステムにインストールされる前に、そのパッチを適用することが不可能であるという事実から生じる。その結果、パッチをあてられる実行可能モジュールが、その実行可能モジュールの従来のパッチが受け取られた後に対象コンピュータシステムにインストールされる場合、そのパッチが実行可能モジュールに適用される可能性は低い。

パッチ当てに対する従来の手法のもう１つの不利益は、そのようなパッチが、通常、対象コンピュータシステムにログインしたユーザによって、自由な変更の許可を有する管理アカウントを使用してのみ適用できることである。この目的で管理アカウントにログインすることは、対象コンピュータシステムの諸態様を変更することを試み、それを行う自由な許可を必要とする対象コンピュータシステムに存在するウィルスに対して、対象コンピュータシステムを脆弱にする可能性がある。

パッチ当てに対する従来の手法のもう１つの不利益は、従来のパッチが、使用不能にすることが困難または不可能である可能性があり、実行可能モジュールの置換を逆転するか、またはシステムレジストリに対する１つまたは複数の変更を逆転することを必要とすることである。

したがって、上で述べたパッチ当てに対する従来の手法の不利益の一部またはすべてを克服する、パッチ当てに対する新しい手法が、高い有用性を有するはずである。

インストールされたコンピュータプログラムコードにパッチをあてるソフトウェア機構（「本機構」）を提供する。ある態様において、本機構は、インストールされた機能にパラメータテストおよびテスト結果ハンドリングを追加する。他の態様では、本機構は、ある場合に、インストールされた機能の実行の流れの任意の位置で、インストールされた機能に様々な他の種類の機能性を追加する。

ある態様において、パッチごとに、本機構は、パッチをあてられる各コンピュータシステム（すなわち、各「対象コンピュータシステム」）に、テストを実行すべき点、実行されるテストの識別、および１つまたは複数の異なるテスト結果に応答して行動する方法の指定を配布する。ある態様において、本機構は、その使用をパッチで指定できるパラメータ検証および他のテストの標準的な集合を提供する。例えば、パッチは、特定の機能について、その機能の特定のパラメータにある値が含まれない場合、その実質的な実行が開始される前に、その機能の呼出しが失敗すべきであることを指定することができる。もう１つのパッチが、特定の機能について、特定のパラメータが指定された最大の長さを超える長さを有する場合、その機能の実行が進行を許可される前に、そのパラメータを指定された最大の長さまでに切り詰めるべきであることを指定することができる。多くのセキュリティエクスプロイトは、一機能のコードのオリジナルバージョンでは阻まれなかったが、その機能が危険な状態を作り、またはこれを利用させるパラメータ値を用いて機能を呼び出させることを当てにする。多くの場合、そのようなエクスプロイトは、そのようなパッチを使用して、機能がそのようなパラメータ値を用いて実行されないようにすることにより防ぐことができる。ある態様において、パッチは、ファイルから読み取られる値またはユーザによって入力される値など、機能パラメータ以外の値のテストを指定する。

ある態様では、自動化されたパッチ当てエージェントが、自動的に各パッチを受け取り、検証し、可能なアプリケーションに関するパッチテーブルに保管する。ある態様において、各パッチは、パッチが受け取られた時に対象コンピュータシステムに既に読み込まれている、パッチを当てられる実行可能モジュールのすべてのインスタンスに適用される。この手法を、本明細書では「ホットパッチ当て」と称し、これによって、パッチが受け取られた直後にパッチを有効にすることが可能になり、パッチを当てられる実行可能モジュールがディスクに保管されているか否かを本機構が判定できる必要はない。ある態様において、各受け取られたパッチは、パッチを当てられる実行可能モジュールのディスクイメージに適用され、その結果、ディスクイメージが将来読み込まれる時に、読み込まれるディスクイメージにパッチが含まれるようになる。この手法を、本明細書では「コールドパッチ当て」と称し、これによって、パッチが、複数のセッションにまたがって持続できるようになる。ある態様において、本機構は、ホットパッチ当てとコールドパッチ当ての両方を実行する。ある態様において、各パッチは、パッチを当てられる実行可能モジュールがオペレーティングシステムのローダによって読み込まれるたびに、パッチを当てられる実行可能モジュールに適用される。この手法を、本明細書では「読み込み時パッチ当て」と称する。ある態様において、各パッチは、パッチを当てられる機能が呼び出されるたびに、パッチをあてられる実行可能モジュールに適用される。この手法を、本明細書では「呼出しインターセプトパッチ当て」と称する。読み込み時パッチ当ておよび呼出しインターセプトパッチ当ての両方が、（１）パッチを当てられる実行可能モジュールがディスクのどこに保管されているかを本機構が判定できることを必要とせず、（２）特定のパッチの即座の可逆性を容易にし、かつ（３）実行可能モジュールのディスクイメージの変更を必要としない。

ある態様において、本機構は、ユーザまたは管理者が適用されるパッチの動作を構成できるようにする。例として、そのような構成に、特定の適用されるパッチに関して：パッチによって指定されたテストを、実行がパッチについて指定された点に達したときに実行するか否か；パッチによって指定されたテスト結果ハンドリングを実行するか、または無視するか；ならびに／あるいはテストの実行および／またはその結果をログ記録し、警告メッセージで表示するか否かなどを含めることができる。これらの態様で、本機構は、まずロギングを使用可能にし、結果ハンドリングを使用不能にすることによって、実動コンピュータシステムでパッチをテストできるようにする。これらの態様で、本機構は、さらに、その結果ハンドリングを使用可能にした後にパッチの動作を「冗長モード」でログ記録できるようにして、パッチが、アプリケーション互換性問題または他のＩＴ問題などの問題を引き起こしている実例を識別するのを支援する。これらの態様は、パッチが問題を起こしていることが発見された場合、適用された後にパッチを素早く使用不能にすることも可能にする。本機構のいくつかの態様は、受け取られ、対象コンピュータシステムに保管されたパッチ群から単純にパッチを削除することによって、パッチを素早く使用不能にすることも可能にする。

ある態様において、本機構は、「データドリブン」パッチ当て手法を使用する。この手法では、パッチに、コードではなく、小さい人間読取り可能なテキストまたはＸＭＬ文書などのデータが含まれる。このデータは、テストを実行すべき点、実行すべきテストの識別、および１つまたは複数のテスト結果に応答して行動する方法を指定する。そのような態様において、パッチ当てエージェントが、データドリブンパッチを受け取り、パッチによって指定されたテストおよびテストハンドリングを追加する。ある態様において、本機構は、「コードドリブン」パッチ当て手法を使用する。この手法では、各パッチに、パッチをあてられる実行可能モジュールに追加される短いプログラムが含まれる。このプログラム自体は、本機構の標準パラメータテスト機能を呼び出すことによってテストを実行し、テストハンドリングを実行する。データドリブンパッチ当てまたはコードドリブンパッチ当てを使用することによって、時折、パッチを当てられる実行可能モジュールのすべてのフレイバに単一のパッチで対処することが可能になる。

ある態様において、本機構は、各パッチに署名して、（１）パッチが承認されたソースからであること、および（２）パッチが承認されたソースによって作成された時以降、パッチの内容が変更されていないことの両方を実証する。

ある態様において、本機構は、すべてのパッチをすべての対象コンピュータシステムに配布し、対象コンピュータシステムのパッチ当てエージェントが、その対象コンピュータシステムでどのパッチを適用すべきか、および適用する方法を、対象コンピュータシステムの特性に基づいて自動的に判定する。これによって、ユーザおよび管理者が、従来、パッチの選択および適用に関連した多くの負担、および正確な現在のインベントリデータベースの維持の負担から解放される。例えば、この特性に、パッチをあてられる実行可能モジュールのどのバージョンが対象コンピュータシステムにインストールされているかを含めることができる。これらの態様において、本機構は、特定の実行可能モジュールのホットフィックスされたフレイバおよびホットフィックスされていないフレイバの異なる処理を指定するパッチを配布し、特定の実行可能モジュールのホットフィックスを犠牲にすることも、実行可能モジュールにパッチを当てる時にホットフィックスを遍在させることも必要としなくすることによって、通常、ホットフィックスによって引き起こされる類の問題を克服することができる。

ある態様において、パッチ当てエージェントは、特定のパッチによってパッチを当てられる実行可能モジュールが、そのパッチを受け取った時に対象システムにインストールされているか否かに無関係に、受け取られたすべてのパッチを対象システムに保管する。本機構は、多くの場合、パッチを当てられる実行可能モジュールの読み込み、またはパッチを当てられる機能の呼出しに応答してパッチを適用する。そのため、本機構は、パッチが対象システムで受け取られた後に対象システムにインストールされた実行可能モジュールにパッチを適用することができる。また、パッチは、パッチを当てられる実行可能モジュールのアンインストールおよびその後の再インストールを超えて残存することができる。

ある態様において、パッチ当てエージェントは、オペレーティングシステムサービスで実施される。これらの態様で、本機構は、パッチを適用するのに必要なすべての許可をパッチ当てエージェントに与える。これらの態様は、ユーザが広範囲の変更許可を有する管理者アカウントを使用して対象コンピュータシステムにログインする必要を無くし、これによって、対象コンピュータシステムに存在するすべてのウィルスに、対象コンピュータシステムの重要な態様を変更するより大きな機会を与えない。そのため、従来のパッチが適用される時に通常は課せられるセキュリティリスクを減らす。

本機構によって使用されるパッチは、通常、比較的小さく、したがって、伝送および保管に関して適度なリソース要件を課す。また、本機構によって使用されるパッチは、パッチをあてられるソフトウェアの挙動を少数の明確に定義された形で変更するので、本機構は、コードチャーンの問題を減らすことに資する。

図１に、本機構を実施できる適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本機構の使用または機能性の範囲に関する制限を提案することを意図されたものではない。コンピューティング環境１００を、例示的なオペレーティング環境１００に示された構成要素のいずれかまたはその組合せに関する依存性または要件を有するものと解釈すべきでない。

本機構は、多数の他の汎用または特殊目的のコンピューティングシステム環境またはコンピューティングシステム構成と共に動作する。本機構と共に使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例に、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置、ラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサに基づくシステム、セットトップボックス、プログム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに限定されない。

本機構を、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行し、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本機構は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよび／またはリモートのコンピュータ記憶媒体に配置することができる。

図１を参照すると、本機構を実装する例示的なシステムに、コンピュータ１１０の形の汎用コンピューティング装置が含まれる。コンピュータ１１０のコンポーネントに、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む複数の種類のバス構造のいずれかとすることができる。限定ではなく例として、そのようなアーキテクチャに、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称するＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。

コンピュータ１１０に、通常は、様々なコンピュータ読取り可能な媒体が含まれる。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセスできるすべての使用可能な媒体とすることができ、揮発性および不揮発性、取外し可能および固定の両方を含む使用可能な媒体を含む。限定ではなく例として、コンピュータ読取り可能な媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体に、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータなどの情報を保管する任意の方法またはテクノロジで実施された、揮発性および不揮発性、取外し可能および固定の媒体が含まれる。コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、あるいは所望の情報の保管に使用でき、コンピュータ１１０によってアクセスできる他のすべての媒体が含まれるが、これに限定されない。通信媒体によって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータが実装され、通信媒体には、すべての情報配布媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形でその特性の１つまたは複数を設定または変更された信号を意味する。限定ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれの組合せも、コンピュータ読取り可能な媒体の範囲に含まれなければならない。

システムメモリ１３０に、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１１０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ １３１に保管される。ＲＡＭ １３２には、通常は、処理装置１２０から即座にアクセス可能、かつ／または処理装置１２０によって現在操作中のデータおよび／またはプログラムモジュールが含まれる。限定ではなく例として、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０に、他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体も含めることができる。単に例として、図１に、固定の不揮発性磁気媒体から読み取られ、またはこれに書き込むハードディスクドライブ１４１、取外し可能不揮発性磁気ディスク１５２から読み取られ、またはこれに書き込む磁気ディスクドライブ１５１、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能不揮発性光ディスク１５６から読み取られ、またはこれに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境で使用できる他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体に、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定されない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。

前述し、図１に示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１１０のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、および他のデータの記憶を提供する。図１では、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一のまたは異なるもののいずれとすることもできることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくとも異なるコピーであることを示すために、異なる符号を与えられている。ユーザは、タブレットまたは電子デジタイザ１６４、マイクロホン１６３、キーボード１６２および、一般にマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力装置を介してコンピュータ１１０にコマンドおよび情報を入力することができる。図１に示されていない他の入力装置に、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、または類似物を含めることができる。上記のおよび他の入力装置は、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他の種類のディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１を、タッチスクリーンパネルまたは類似物と一体化することもできる。モニタおよび／またはタッチスクリーンパネルを、タブレットタイプパーソナルコンピュータのように、コンピューティング装置１１０が組み込まれるハウジングに物理的に結合できることに留意されたい。さらに、コンピューティング装置１１０などのコンピュータに、スピーカ１９５およびプリンタ１９６など、出力周辺インターフェース１９４または類似物を介して接続できる他の周辺出力装置も含めることができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般的なネットワークノードとすることができ、通常、上でコンピュータ１１０に関して説明した要素の多くまたはすべてが含まれるが、図１には、メモリ記憶装置１８１だけを示した。図示の論理接続に、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング環境は、オフィス、会社規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。例えば、本機構で、コンピュータシステム１１０に、そこからデータが移行されるソースマシンを含めることができ、リモートコンピュータ１８０に、宛先マシンを含めることができる。しかし、ソースマシンおよび宛先マシンを、ネットワークまたは他の手段によって接続する必要がなく、その代わりに、データを、ソースプラットフォームによる書き込みと宛先プラットフォームによる読み取りが可能な任意の媒体を介して移行できることに留意されたい。

ＬＡＮネットワーキング環境で使用される時に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ １７１に接続される。ＷＡＮネットワーキング環境で使用される時に、コンピュータ１１０に、通常は、インターネットなどのＷＡＮ １７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当な手段を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して図示されたプログラムモジュールまたはその一部を、リモートメモリ記憶装置に保管することができる。限定ではなく例として、図１に、メモリ装置１８１に常駐するものとしてリモートアプリケーションプログラム１８５を示す。図示のネットワーク接続が例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることを理解されたい。

様々な機能性およびデータが、特定の形で配置された特定のコンピュータシステムにあるものとして図１に示されているが、当業者は、そのような機能性およびデータを、異なる配置のコンピュータシステムにまたがって様々な他の形で分散できることを理解するであろう。前述したように構成されたコンピュータシステムが、通常は本機構の動作をサポートするのに使用されるが、当業者は、本機構を、様々な種類および構成の、様々なコンポーネントを有する装置を使用して実施できることを理解するであろう。

図２に、本機構によるコンピュータシステム間の通常のデータ交換を示すデータフローを示す。図２に示すコンピュータシステム（コンピュータシステム２１０、２２０、２２１、２２２、２３０、２３１、および２３２）は、通常、図１に示され、図１に関して述べたコンポーネントのいくつかまたはすべてを有する。パッチ配布サーバにおいて、本機構が、１つまたは複数のパッチを生成する。これらのパッチ２０１は、パッチ配布サーバから、管理サーバ２２０および２３０などの１つまたは複数の管理サーバに送信される。各管理サーバは、そのパッチを、対象コンピュータシステム２２１、２２２、２３１、および２３２などの１つまたは複数の対象コンピュータシステムに転送する。ある実施形態（図示せず）において、パッチ配布サーバは、１つまたは複数の対象コンピュータシステムに直接に、または単一の管理サーバを介するよりも間接的なルートを介して、パッチを送信する。対象コンピュータシステムで受け取られたパッチは、下記で詳細に説明するように、対象コンピュータシステムで処理される。管理サーバは、１つまたは複数の対象コンピュータシステムにパッチ構成コマンド２０２を送信することができ、対象コンピュータシステムは、そのパッチ構成コマンドを適用して、特定のパッチの動作を再構成する。下記で詳細に述べるように、パッチは、完全に使用不能にすることができ、あるパッチが使用不能にされない場合、その動作の通知およびそのテスト結果ハンドリングのそれぞれを、独立に使用可能または使用不能にすることができる。その動作の通知が使用可能にされるとき、通知は、対象コンピュータシステムでローカルに表示もしくは保管することができ、または、通知２０３として適当な管理サーバに送信することができる。

図３に、通常、新しいパッチを受け取り、および処理するために本機構によって実行されるステップの流れ図を示す。ステップ３０１で、本機構は、パッチを受け取る。ステップ３０１で受け取られたパッチは、データドリブンパッチまたはコードドリブンパッチのいずれかとすることができる。データドリブンパッチのサンプルを、下の表１に示す。

行１に、パッチの一意識別子が含まれる。行２によって、このパッチによって影響されるアプリケーションが識別される。行３によって、このパッチによって影響されるアプリケーションバージョンが識別される。行４によって、このパッチによって影響される実行可能モジュールが識別される。行５によって、パッチ当ての指示が提供される、影響される実行可能モジュールの２つのバージョン（バージョン８．０．^＊および９．^＊）が識別される。行６〜１０に、実行可能モジュールのこの２つのバージョンに関するパッチ当て指示が含まれる。行６〜７によって、パッチをあてられる機能、実行可能モジュール内のそのアドレス、パッチによってテストされるパラメータ、およびテストされるパラメータの型が識別される。行８によって、行６〜７で識別されたパラメータに対し、その長さが６０バイトを超えるか否かを判定するためにテストを行うべきであることが示される。行９によって、テストが成功の場合にこの機能の呼出しが失敗すべきであることが示される。行１２によって、パッチ当て指示が提供される、影響される実行可能モジュールのもう２つのバージョン（バージョン１０．^＊および１１．^＊）が識別される。行１３〜１７に、実行可能モジュールのこの２つのバージョンに関するパッチ当て指示が含まれる。行１３〜１４によって、パッチを当てられる機能、実行可能モジュール内のそのアドレス、パッチによってテストされるパラメータ、およびテストされるパラメータの型が識別される。バージョン１０．^＊および１１．^＊について行１３〜１４で識別される実行可能モジュール内のパッチを当てられる機能のアドレスが、バージョン８．０．^＊および９．^＊について行６〜７で識別されたパッチを当てられる機能のアドレスと異なることが分かる。行１５によって、行１３〜１４で識別されたパラメータをテストして、その長さが１２８バイトを超えないか否かを判定すべきであることが示される。行１６によって、テストが成功する場合、この機能の呼出しが失敗すべきであることが示される。パッチは、パッチを当てられる機能の呼出しの失敗、例外の送出、パッチを当てられた実行可能モジュールが実行されているプロセスの終了、または誤った値の訂正（長すぎるストリングの切詰など）を含む様々な結果ハンドリングアクション型を指定することができる。行２３〜２５に、パッチのソースを識別すると同時に、ソースから出た後にパッチが変更されていないことを検証するパッチの署名が含まれる。

下記の表２に、上記の表１に示すパッチのコードドリブンバージョンが含まれる。

行１〜３で、テスト機能のパラメータをスタックにプッシュする。行４で、テスト機能を呼び出す。行５〜８で、テスト機能の戻りコードに基づいて分岐する。テスト機能が成功の場合に、行９で、ジャンプして、パッチをあてられた機能の本体の実行を開始する。テスト機能が失敗する場合に、行１０〜１１で、失敗の結果コードをスタックにプッシュし、パッチを当てられた機能からパッチを当てられた機能の呼出し元に戻る。読み易くするため、表２では、検証可能な署名、パッチ構成フラグの現在の値についてテストする命令、およびパッチを当てられた機能のコードの先頭から再配置された命令を含む、一部のコードドリブンパッチに存在する詳細が省略されている。

ある実施形態において、両方の型のパッチは、パッチを当てられる実行可能モジュールの１つまたは複数のバージョンごとに、実行可能モジュールの特定のインスタンスがそのバージョンの正しいコピーであることを検証するのに使用できるファイル署名を含む追加情報を含むことができる。そのようなファイル署名は、例えば、実行可能モジュールバージョン全体のサイズもしくはチェックサム、または、実行可能モジュールがパッチを当てられるオフセットなどの実行可能モジュール内の特定の点にあると期待されるコードとすることができる。

ステップ３０２で、パッチに有効な署名が署名されている場合、本機構は、ステップ３０３で継続する。そうでない場合、本機構は、ステップ３０１で継続して、次のパッチを受け取る。ステップ３０３で、本機構は、パッチをローカルパッチテーブルに追加する。ステップ３０４で、本機構は、デフォルト構成に送ることによるなどのように、パッチの初期構成を初期化する。

図４は、本機構によって使用されるものに典型的なサンプルパッチテーブルを示すデータ構造図である。パッチテーブル４００に、行４０１および４０２などの行が含まれ、これらの行の各々は、パッチから抽出されたパッチ識別子を含むパッチ識別子列４１１、名前など、パッチを当てられる実行可能モジュールを識別する情報を含む実行可能モジュール列４１２、パッチが適用される、列４１２で識別された実行可能モジュールのバージョンのすべてを識別する実行可能モジュールバージョン列４１３、パッチを当てられる機能が呼び出されるたびに、このパッチによって指定されるテストを実行されるべきか否かの現在の構成値を含むテスト実行可能列４１４、このパッチのテストが実行されるたびに通知を生成されるべきか否かの現在の構成値を含むテスト実行通知可能列４１５、このパッチのテストが成功するたびに通知を生成されるべきか否かの現在の構成値を含むテスト結果通知実行可能列４１６、このパッチのテストが失敗した時にパッチの結果ハンドリングを実施されるべきか否かの現在の構成値を含むテスト結果ハンドリング実行可能列４１７、ならびにテストおよびテストが失敗するたびに実行されるテスト結果ハンドリングを指定する、パッチ自体へのポインタを含むパッチ列４１８に分割される。ある実施形態において、図に示すようにパッチへのポインタを含むのではなく、パッチ列４１８にパッチ自体が直接に含まれる。特定のパッチテーブルは、すべてのコードドリブンパッチ、すべてのデータドリブンパッチ、またはコードドリブンパッチとデータドリブンパッチの組合せなど、様々な型のパッチを含み、またはこれを指すことができる。

ステップ３０５で、本機構が、受け取ったパッチをパッチテーブルに追加し、その構成を初期化したならば、そのパッチは、本機構による実行可能モジュールへの自動的適用に使用可能である。ステップ３０５で、本機構は、参照によって組み込まれた本特許明細書に記載のもの、ならびにリアルタイム機能呼出しインターセプション、および／または（１）既に読み込まれた実行可能モジュール、（２）実行可能モジュールの１つまたは複数のディスクイメージ、もしくは（３）オペレーティングシステムのローダによって読み込まれる実行可能モジュールのインスタンスのコード書き換えを含むパッチを適用する様々な手法を使用することができる。ステップ３０５の後に、本機構は、ステップ３０１において継続して、次のパッチを受け取る。

図５は、通常、特定のパッチの構成命令を更新するために本機構によって実行されるステップを示す流れ図である。ステップ５０１で、本機構は、管理者からなど、特定のパッチの構成命令を受け取る。ある実施形態において、そのような構成命令は、グループポリシを使用して管理者が生成することができる。ステップ５０２で、本機構は、受け取った命令に従って、パッチテーブル内のパッチの構成を更新する。ステップ５０２の後に、本機構は、ステップ５０１で継続して、次の構成命令を受け取る。

図６は、通常、パッチによって指定されるパラメータ検証を実行するために本機構によって実行されるステップを示す流れ図である。ステップ６０１で、パッチを当てられた機能を呼び出す。ステップ６０２で、呼び出された機能に影響するパッチについてテストが実行可能にされている場合、本機構は、ステップ６０３で継続し、そうでない場合には、本機構は、ステップ６０１で継続して、パッチを当てられた機能の次の呼出しを処理する。ステップ６０３で、テスト実行通知がこのパッチについて実行可能にされている場合に、本機構は、ステップ６０４で継続し、そうでない場合に、本機構は、ステップ６０５で継続する。ステップ６０４で、本機構は、テストが実行されたことの通知を生成する。ステップ６０４、６０８、および６１０に、テストが満足されたことを表示する対象コンピュータシステムでの表示または保管、および／あるいはリモートコンピュータシステムでの表示またはログ記録に関するリモートコンピュータシステムへのそのような表示の送信を含むことができる。

ステップ６０５で、本機構は、パッチによって指定される検証テストを実行する。ある実施形態において、ステップ６０５に、本機構によってテストに使用される標準ルーチンのグループの１つを呼び出すことが含まれる。ステップ６０６で、ステップ６０５で実行されたテストが満足される場合、本機構は、ステップ６０１で継続する。そうでない場合、本機構は、ステップ６０７で継続する。ステップ６０７で、テスト結果通知がこのパッチについて実行可能にされている場合、本機構は、ステップ６０８で継続する。そうでない場合、本機構は、ステップ６０９で継続する。ステップ６０８において、本機構は、テストが満足されなかったことの通知を生成する。ステップ６０９で、このパッチについてテスト結果ハンドリングが実行可能にされている場合、本機構は、ステップ６１０で継続する。そうでない場合、本機構は、ステップ６０１で継続する。ステップ６１０において、本機構は、パッチによって指定されるテスト結果ハンドリングを実行する。ステップ６１０の後に、本機構は、ステップ６０１で継続する。

当業者は、上記で説明した機構を、様々な形で簡単に適合または拡張できることを理解されたい。例えば、本機構を使用して、様々な異なる種類のパッチを様々な形で様々な目的の様々な型の実行可能モジュールの様々な位置に適用することができる。また、本明細書では、失敗する時に問題を示す値検証テストを含むものとしてパッチを説明したが、本機構は、成功する時に問題を示す値検証テストを使用して実施することもできる。いくつかの実施形態において、各テストに、その成功または失敗が問題を示すか否かの表示が付随する。前述の説明では、好ましい実施形態を参照したが、本発明の範囲は、請求項およびこれに記載された要素によってのみ定義される。

本機構を実施できる適切なコンピューティングシステム環境の例を示す図である。 本機構によるコンピュータシステムの間のデータの通常の交換を示すデータフロー図である。 通常、新しいパッチを受け取り、処理するために本機構によって実行されるステップを示す流れ図である。 本機構によって使用されるものに典型的なサンプルパッチテーブルを示すデータ構造図である。 通常、特定のパッチの構成命令を更新するために本機構によって実行されるステップを示す流れ図である。 通常、パッチによって指定されるパラメータ検証を実行するために本機構によって実行されるステップを示す流れ図である。

符号の説明

１４１ ハードディスクドライブ
１５１ 磁気ディスクドライブ
１５５ 光ディスクドライブ
１８１ メモリ記憶装置

Claims (42)

1. ソフトウェアを増補するコンピューティングシステムにおける方法であって、
   （ａ）前記コンピューティングシステムにおいて実行されるソフトウェアの中にある増補される機能を指定し、（ｂ）テストされる前記機能のパラメータを指定し、（ｃ）前記指定されたパラメータに適用されるテストを指定し、および（ｄ）前記指定されたテストが前記指定されたパラメータによって満足されない場合に前記機能の挙動に対して実行される変更を指定する増補指定を対象コンピュータシステムで受け取るステップと、
   前記指定された機能が前記対象コンピュータシステムで呼び出されるとき、前記指定されたテストが前記指定されたパラメータによって満足されない場合、前記指定された機能の挙動に対する前記指定された変更を実行するステップと
   を備えたことを特徴とする方法。
2. 前記増補指定によって指定される前記変更は、前記指定された機能の前記実行を防止することを特徴とする請求項１に記載の方法。
3. 前記増補指定によって指定される前記変更は、前記指定されたパラメータの変更の後に前記指定された機能を実行していることを特徴とする請求項１に記載の方法。
4. 複数の増補指定は、前記対象コンピュータシステムで受け取られることを特徴とする請求項１に記載の方法。
5. 前記受け取られた増補指定のすべてをデータ構造内で維持することをさらに備えたことを特徴とする請求項４に記載の方法。
6. 前記増補指定の受け取りの後に、前記指定された機能の挙動に対する前記指定された変更を実行するためにユーザ介入が必要でないことを特徴とする請求項１に記載の方法。
7. 前記増補指定は、コードが前記増補指定に含まれない、呼び出されるパラメータテスト機能を識別することによって、前記指定されたパラメータに適用されるテストを指定することを特徴とする請求項１に記載の方法。
8. 前記増補指定は、前記増補指定が受け取られる前にインストールされた呼び出すパラメータテスト機能を識別することによって、前記指定されたパラメータに適用されるテストを指定することを特徴とする請求項１に記載の方法。
9. 前記増補指定は、コードを含むことを特徴とする請求項１に記載の方法。
10. 前記増補指定に含まれる前記コードは、コードが前記増補指定に含まれないパラメータテスト機能を呼び出すコードを含むことを特徴とする請求項９に記載の方法。
11. 前記増補指定は、コードが前記増補指定に含まれないパラメータテスト機能を識別するテキストを含むことを特徴とする請求項１に記載の方法。
12. 前記増補指定に含まれるテキストによって識別される前記パラメータテスト機能のコードは、前記増補指定に含まれることを特徴とする請求項１１に記載の方法。
13. 前記増補指定に含まれないテキストによって識別される前記パラメータテスト機能のコードは、前記増補指定に含まれないことを特徴とする請求項１１に記載の方法。
14. 前記増補指定の動作を制御する状態を構成するインターフェースを提供することをさらに備え、および前記指定された機能の挙動に対する前記指定された変更は、前記状態が実行可能な状態であるときに限って実行されることを特徴とする請求項１に記載の方法。
15. 前記提供されるインターフェースは、前記増補指定の動作のローカルな構成を可能にすることを特徴とする請求項１４に記載の方法。
16. 前記提供されるインターフェースは、前記増補指定の動作のリモートからの構成を可能にすることを特徴とする請求項１４に記載の方法。
17. 前記提供されるインターフェースは、前記増補指定の動作のポリシに従った構成を可能にすることを特徴とする請求項１４に記載の方法。
18. 前記指定されたテストは、前記指定された機能の実質的なコードが実行される前に実行されることを特徴とする請求項１４に記載の方法。
19. 前記増補指定に関連する警告を構成するインターフェースを提供するステップと、前記提供されるインターフェースが警告を実行可能にするために用いられる場合、前記増補指定によって指定される前記テストが失敗するたびに警告を生成するステップとをさらに備えたことを特徴とする請求項１に記載の方法。
20. 前記増補指定に関連する通知を構成するインターフェースを提供するステップと、前記提供されるインターフェースが通知を実行可能にするために用いられる場合、前記増補指定によって指定される前記テストが実行されるたびに通知を生成することとをさらに含むことを特徴とする請求項１に記載の方法。
21. 前記生成された通知を単一の統合された通知に統合することをさらに含むことを特徴とする請求項２０に記載の方法。
22. 前記受け取られた増補指定は、署名され、
    前記方法は、前記増補指定の前記署名を検証するステップをさらに備え、および
    前記指定された機能の挙動に対する前記指定された変更は、前記増補指定の署名の検証が成功した場合に限って実行される
    ことを特徴とする請求項１に記載の方法。
23. 前記指定された機能の挙動に対する前記指定された変更は、前記増補指定の署名の署名者が前記指定された機能を含む前記ソフトウェアの署名者と一致する場合に限って実行されることを特徴とする請求項２２に記載の方法。
24. 前記指定された機能のコードを変更せずに、前記指定された機能が呼び出されたことの検出に応答して前記指定されたテストを実行することをさらに備えたことを特徴とする請求項１に記載の方法。
25. 前記指定された機能が呼び出されるとき、前記指定された機能のコードを変更して、前記指定されたテストを実行することをさらに備えたことを特徴とする請求項１に記載の方法。
26. 前記指定された機能のコードは、前記指定されたテストを実行する個別のルーチンへのジャンプを前記指定された機能のコードに挿入することによって変更されることを特徴とする請求項２５に記載の方法。
27. 前記指定された機能は、ローダを用いて読み込み可能な区別される実行可能モジュールにおいて提供され、前記方法は、前記指定された機能の各呼出しに応答して前記指定された機能が実行される前に呼び出される前記指定されたテストを実行するルーチンを有するようにローダに登録することをさらに備えたことを特徴とする請求項１に記載の方法。
28. コンピューティングシステムに存在するソフトウェアの増補を可能にするコンピューティングシステムであって、
    ソフトウェアを含む記憶装置と、
    （ａ）前記ソフトウェアが増補される点を指定し、（ｂ）前記指定された点でテストされる機能に関連する値を指定し、（ｃ）前記指定された値に適用されるテストを指定し、および（ｄ）前記指定されたテストが前記指定された値によって満足されない場合に前記ソフトウェアの挙動に対して実行される変更を指定するパッチを前記コンピューティングシステム内で受け取るパッチレシーバと、
    前記ソフトウェアの実行が前記対象コンピュータシステムで前記指定された点に達したとき、前記指定されたテストが前記指定された値によって満足されない場合、前記ソフトウェアの挙動に対する前記指定された変更が実行されるように、前記指定された点で前記ソフトウェアにコードを注入するパッチ当てエージェントと
    を備えたことを特徴とするコンピューティングシステム。
29. 対象コンピューティングシステムに前記対象コンピューティングシステム内で使用可能なソフトウェアに対して値検証を追加する方法を実行させる内容を有するコンピュータ読取り可能な媒体であって、
    （ａ）前記コンピューティングシステムで使用可能なソフトウェアの中の、値検証が追加される機能を指定し、（ｂ）前記機能の実行中に前記対象コンピューティングシステムに存在するテストされるデータを指定し、（ｃ）前記指定されたデータに適用されるテストを指定し、および（ｄ）前記指定されたテストが前記指定されたデータによって満足されない場合に前記機能の挙動に対して実行される変更を指定する増補指定を前記コンピューティングシステム内で受け取るステップと、
    前記指定された機能が前記対象コンピュータシステムで呼び出されるとき、前記指定されたテストが前記指定されたデータによって満足されない場合、前記指定された機能の挙動に対する前記指定された変更を実行するステップと
    を備えたことを特徴とするコンピュータ読取り可能な媒体。
30. 前記指定されたテストは、前記指定されたデータの値に無関係に、必ず満足されるテストであることを特徴とする請求項２２に記載のコンピュータ読取り可能な媒体。
31. パッチデータ構造を伝える生成されたデータ信号であって、
    値検証が追加される機能を識別する情報と、
    前記機能の実行中に存在するテストされるデータを識別する情報と、
    前記指定されたデータに適用されるテストを識別する情報と、
    前記データ信号が、前記指定された機能が実行される対象コンピュータシステムで受け取られる場合、前記指定された機能が前記対象コンピュータシステム上で呼び出されるとき、前記指定されたテストが前記指定されたデータによって満足されない場合に、前記指定された機能の挙動に対する指定された変更を実行するために前記データ構造の内容を使用できるように、前記指定されたテストが前記指定されたデータによって満足されない場合に、前記機能の挙動に対して実行される前記変更を識別する情報と
    を備えたことを特徴とする生成されたデータ信号。
32. 前記生成されたデータ信号は、コンピュータシステム間で伝送されることを特徴とする請求項３１に記載の生成されたデータ信号。
33. 前記生成されたデータ信号は、コンピュータシステム内で伝送されることを特徴とする請求項３１に記載の生成されたデータ信号。
34. 対象コンピューティングシステム内で使用可能なソフトウェアに値検証を追加する方法であって、
    （ａ）値検証が追加されるソフトウェアを指定し、（ｂ）値検証が追加される、前記指定されたソフトウェア内の点を指定し、（ｃ）前記指定されたソフトウェアの前記指定された点での実行中に前記対象コンピューティングシステムに存在するテストされるデータを指定し、（ｄ）指定されたデータに適用されるテストを使用し、および（ｅ）前記指定されたテストが前記指定されたデータによって満足されない場合に前記ソフトウェアの挙動に対して実行される変更を指定する増補指定を前記コンピューティングシステムで受け取るステップと、
    前記受け取られた増補指定に関する動作モードをユーザが構成できるようにするステップと、
    前記指定されたソフトウェアが前記対象コンピュータシステムの前記指定された点で実行されるとき、前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップと
    を備えたことを特徴とする方法。
35. 前記ユーザは、前記増補指定のアクティブ動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、前記指定されたテストが前記指定されたデータによって満足されない場合、前記指定されたソフトウェアの前記挙動に対する前記指定された変更を実行するステップを含むことを特徴とする請求項３４に記載の方法。
36. 前記ユーザは、前記増補指定に関するアクティブ診断動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、前記指定されたテストが前記指定されたデータによって満足されない場合、（１）前記指定されたソフトウェアの挙動に対して前記指定された変更を実行するステップと、（２）前記指定されたテストが前記指定されたデータによって満足されないことの通知を生成するステップとの両方を含むことを特徴とする請求項３４に記載の方法。
37. 前記ユーザは、前記増補指定に関する冗長アクティブ動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、
    前記指定されたテストが前記指定されたデータによって満足されない場合、前記指定されたソフトウェアの前記挙動に対して前記指定された変更を実行するステップと、
    前記指定されたテストが実行されたことの通知を生成するステップと
    を含むことを特徴とする請求項３４に記載の方法。
38. 前記ユーザは、前記増補指定に関するアクティブ冗長診断動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、
    前記指定されたテストが前記指定されたデータによって満足されない場合、（１）前記指定されたソフトウェアの挙動に対して前記指定された変更を実行するステップ、および（２）前記指定されたテストが前記指定されたデータによって満足されないことの通知を生成するステップの両方と、
    前記指定されたテストが実行されたことの通知を生成するステップと
    を含むことを特徴とする請求項３４に記載の方法。
39. 前記ユーザは、前記増補指定に関するインアクティブ動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、前記指定されたテストが前記指定されたデータによって満足されたか否かに無関係に、前記指定されたソフトウェアの挙動に対する前記指定された変更の実行を省略することを含むことを特徴とする請求項３４に記載の方法。
40. 前記ユーザは、前記増補指定に関するインアクティブ診断動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、
    前記指定されたテストが前記指定されたデータによって満足されたか否かに無関係に、前記指定されたソフトウェアの前記挙動に対する前記指定された変更の実行を省略するステップと、
    前記指定されたテストが前記指定されたデータによって満足されない場合、前記指定されたテストが前記指定されたデータによって満足されないことの通知を生成するステップと
    を含むことを特徴とする請求項３４に記載の方法。
41. 前記ユーザは、前記増補指定に関するインアクティブ診断動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、
    前記指定されたテストが前記指定されたデータによって満足されたか否かに無関係に、前記指定されたソフトウェアの挙動に対する前記指定された変更の実行を省略するステップと、
    前記指定されたテストが実行されたことの通知を生成するステップと
    を含むことを特徴とする請求項３４に記載の方法。
42. 前記ユーザは、前記増補指定に関するインアクティブ診断動作モードを構成し、および前記受け取られた増補指定に関して構成された前記動作モードと一貫する形で前記受け取られた増補指定を適用するステップは、
    前記指定されたテストが前記指定されたデータによって満足されたか否かに無関係に、前記指定されたソフトウェアの挙動に対する前記指定された変更の実行を省略するステップと、
    前記指定されたテストが実行されたことの通知を生成するステップと、
    前記指定されたテストが前記指定されたデータによって満足されない場合、前記指定されたテストが前記指定されたデータによって満足されないことの通知を生成するステップと
    を含むことを特徴とする請求項３４に記載の方法。
    

Images