(57)【要約】  本発明によれば、アプリケーションがソフトウェア故障及びアタックから自動的に回復できるようにするコンピュータ実施方法及びシステムが提供される。１つ以上のセンサを使用して、アプリケーションにおいて故障が検出される。故障の検出に応答して、その故障を引き起こしたアプリケーションコードに部分が分離される。故障を引き起こした入力ベクトル、故障に関する情報（例えば、故障の形式）、コアダンプファイル（例えば、スタックトレース）、等を使用して、故障を修理するエミュレータベースのワクチンが構成される。ワクチンが故障を修理したことを検証するのに応答して、アプリケーションは、ユーザの介在なく、エミュレータベースのワクチンで自動的に更新される。ソフトウェアモノカルチャーにおいて利用できるリソースを効率的に使用するアプリケーションコミュニティ特徴も提供される。複数の装置を含むアプリケーションコミュニティが定義され、そしてアプリケーションコードが、より小さなコード部分に分割され、複数の装置の各々に監視のために指定される。各装置は、他の装置に故障を通知する。【選択図】図１
2008547070.tif 000002
【特許請求の範囲】
【請求項１】
コードを含むアプリケーションをソフトウェア故障から修理するための方法において、
前記アプリケーションの故障を検出するステップと、
前記故障の検出に応答して、その故障を生じさせたコードの一部分を分離させるステップと、
前記故障を修理するエミュレータベースのワクチンを構成するステップと、
インストラクションレベルのエミュレータを使用して、前記コードの分離された部分のインスツルーメントバージョンにおいて前記エミュレータベースのワクチンをテストするステップと、
前記ワクチンが前記故障を修理したことを検証するのに応答して、前記アプリケーションを前記エミュレータベースのワクチンで更新するステップと、
を備えた方法。
【請求項２】
前記故障は、コンピュータウイルス、ワーム、トロイ、敵意のある実行、プローブ、サービス拒否アタック、リソース欠乏アタック、バッファオーバーフロー、バッファアンダーフロー、不当なメモリアクセス、ゼロによる除算、チェック時間・対・使用時間違反、及びプログラミングエラー、のうちの少なくとも１つである、請求項１に記載の方法。
【請求項３】
前記検出は、少なくとも１つのセンサを使用して実行され、この少なくとも１つのセンサは、ホストベースのセンサ、ネットワークベースのセンサ、及びハニーポットのうちの１つを含む、請求項１に記載の方法。
【請求項４】
前記アプリケーションは、サーバーにおいて実行され、前記検出は、更に、前記アプリケーションを模擬する個別のサーバーにおいてハニーポットを実施することを含む、請求項１に記載の方法。
【請求項５】
アプリケーションを終了させる故障に応答してコアダンプファイル又は他のレポート情報を発生するステップを更に備えた、請求項１に記載の方法。
【請求項６】
前記コアダンプファイル又は他の情報は、発生した故障の形式と、スタックトレースと、影響を受け易いコードのアプリケーション部分に関して故障を局所化する上で助けとなる他の情報とを含む、請求項５に記載の方法。
【請求項７】
故障を生じさせたコードの一部分を分離させる前記ステップは、故障の検出に応答して発生されたコアダンプファイル又は他の情報に少なくとも一部分基づく、請求項５に記載の方法。
【請求項８】
前記故障は、入力ベクトルを露出させる、請求項１に記載の方法。
【請求項９】
前記エミュレータベースのワクチンは、入力ベクトル、及び／又はアプリケーションの実行に対するその作用に少なくとも一部分基づいて構成される、請求項８に記載の方法。
【請求項１０】
エミュレータベースのワクチンをテストする前記ステップは、前記コードの分離された部分のインスツルーメントバージョンへ前記入力ベクトルを入力することを更に含む、請求項８に記載の方法。
【請求項１１】
前記コードの分離された部分のインスツルーメントバージョンの実行中にメモリの変更を記録するステップを更に備えた、請求項１に記載の方法。
【請求項１２】
前記分離された部分のインスツルーメントバージョンは、オリジナル状態を有するメモリスタックを備え、前記方法は、更に、メモリスタックをオリジナル状態へ戻して、エラー復帰を生成するステップを備えた、請求項１に記載の方法。
【請求項１３】
前記故障を模擬するエラーコードを返送するステップを更に備えた、請求項１に記載の方法。
【請求項１４】
前記コードの分離された部分からエラーコードを模擬するステップを更に備えた、請求項１に記載の方法。
【請求項１５】
アプリケーションの実行中に生じる故障と、ハンドリングするようにアプリケーションがプログラムされた故障のセットとの間をマッピングするステップを更に備えた、請求項１に記載の方法。
【請求項１６】
アプリケーションを更新する前記ステップは、前記コードの分離された部分に付加的なコードを自動的に挿入することを更に含む、請求項１に記載の方法。
【請求項１７】
ソフトウェア故障からアプリケーションを修理するための方法において、
コードを含むアプリケーションを、少なくとも１つのセンサを使用して、故障に対して監視するステップと、
前記コードが故障の影響を受け易いところを識別するステップと、
前記識別に少なくとも一部分基づいて前記コードの一部分を分離するステップと、
前記コードの一部分のインスツルーメントバージョンを生成するステップと、
前記コードの一部分及び予想に少なくとも一部分基づいてワクチンを構成するステップと、
前記インスツルーメントバージョンのセグメントを前記ワクチンでエミュレートするステップと、
前記エミュレーションに少なくとも一部分基づいて前記アプリケーションを更新するステップと、
を備えた方法。
【請求項１８】
ソフトウェア故障からアプリケーションを修理するためのシステムにおいて、
アプリケーション及びそれに対応するコードを故障に対して監視し、そして故障を検出するのに応答して、その故障を生じさせたコードの一部分を分離させるセンサと、
前記コードの一部分をエミュレートするために選択的に呼び出されるインストラクションレベルのエミュレータと、
前記エミュレータを使用して前記コードの一部分に対する１つ以上の潜在的なワクチンを評価するように構成されたテストシステムであって、前記コードの一部分に故障を生じさせた１つ以上の入力変数を適用し、そしてユーザ入力なしに前記コードの一部分を修理するのに応答して前記アプリケーションを更新するテストシステムと、
を備えたシステム。
【請求項１９】
前記故障は、コンピュータウイルス、ワーム、トロイ、敵意のある実行、プローブ、サービス拒否アタック、リソース欠乏アタック、バッファオーバーフロー、バッファアンダーフロー、不当なメモリアクセス、ゼロによる除算、チェック時間・対・使用時間違反、及びプログラミングエラー、のうちの少なくとも１つである、請求項１８に記載のシステム。
【請求項２０】
前記センサは、ホストベースのセンサ、ネットワークベースのセンサ、及びハニーポットのうちの１つである、請求項１８に記載のシステム。
【請求項２１】
前記アプリケーションはサーバーにおいて実施され、前記システムは、更に、アプリケーションを模擬する個別のサーバーにおいて実施されるハニーポットを備えた、請求項１８に記載のシステム。
【請求項２２】
前記テストシステムは、更に、前記コードの分離された部分の評価中にメモリの変更を記録するように構成される、請求項１８に記載のシステム。
【請求項２３】
前記テストシステムは、更に、故障を模擬するエラー返送を発生するように構成される、請求項１８に記載のシステム。
【請求項２４】
前記テストシステムは、更に、アプリケーションの実行中に生じる故障と、ハンドリングするようにアプリケーションがプログラムされた故障のセットとの間のマップを生成するように構成される、請求項１８に記載のシステム。
【請求項２５】
前記インストラクションレベルのエミュレータは、更に、前記コードの一部分に付加的なコードを自動的に挿入するように構成される、請求項１８に記載のシステム。
【請求項２６】
ソフトウェア故障からアプリケーションを修理するための方法において、
複数の装置を含むアプリケーションコミュニティを定義するステップと、
アプリケーションの部分を前記複数の装置の各々に指定するステップと、
前記複数の装置の１つが故障を検出したという指示を受け取るステップと、
前記複数の装置の１つが故障を検出したという指示を受け取るのに応答して、前記アプリケーションコミュニティにその故障を通知するステップと、
を備えた方法。
【請求項２７】
前記指定するステップは、更に、前記複数の装置の各々における利用可能なメモリの量に基づいて前記複数の装置の各々に前記アプリケーションの部分を指定することを含む、請求項２６に記載の方法。
【請求項２８】
前記指定するステップは、更に、前記アプリケーションコミュニティの合計ワークロードに基づいて前記複数の装置の各々に前記アプリケーションの部分を指定することを含む、請求項２６に記載の方法。
【請求項２９】
前記指定するステップは、更に、前記複数の装置の各々に前記アプリケーションの部分を任意に指定することを含む、請求項２６に記載の方法。
【請求項３０】
前記指定するステップは、更に、各装置が他の装置と駆け引きすることによりそのワークロードを調整することを許す、請求項２６に記載の方法。
【請求項３１】
コードを含むアプリケーションをソフトウェア故障から修理するための方法において、
複数の装置を含むアプリケーションコミュニティを定義するステップと、
監視すべき故障を前記複数の装置の各々に指定するステップと、
前記複数の装置の１つが指定の故障を検出したという指示を受け取るステップと、
前記複数の装置の１つが指定の故障を検出したという指示を受け取るのに応答して、前記アプリケーションコミュニティに故障を通知するステップと、
を備えた方法。
【請求項３２】
前記指定するステップは、更に、前記複数の装置の各々における利用可能なメモリの量に基づいて前記複数の装置の各々に前記監視すべき故障を指定することを含む、請求項３１に記載の方法。
【請求項３３】
前記指定するステップは、更に、前記アプリケーションコミュニティの合計ワークロードに基づいて前記複数の装置の各々に前記監視すべき故障を指定することを含む、請求項３１に記載の方法。
【請求項３４】
前記指定するステップは、更に、前記複数の装置の各々に監視すべき故障を任意に指定することを含む、請求項３１に記載の方法。
【請求項３５】
前記指定するステップは、更に、各装置が他の装置と駆け引きすることによりそのワークロードを調整することを許す、請求項３１に記載の方法。
【請求項３６】
コードを含むアプリケーションをソフトウェア故障から修理するための方法において、
アプリケーションのソースコードの一部分が故障の影響を受け易いことを識別するステップと、
前記識別に応答して前記ソースコードの一部分を分離するステップと、
前記ソースコードの分離された部分に付加的なコードを自動的に挿入するステップであって、付加的なコードは、前記故障を、エラーコードを与えるようにアプリケーションがプログラムされた他の故障と共にマップし、且つ付加的なコードは、前記アプリケーションが終了せずに実行し続けるのを許すものであるステップと、
を備えた方法。
【請求項３７】
アプリケーションを修理するための方法において、
アプリケーションの故障を検出するステップと、
前記故障の検出に応答して、その故障に関連したアプリケーションの部分を分離するステップと、
前記故障を修理するためのエミュレータベースのワクチンを生成するステップと、
前記アプリケーションの分離された部分に前記エミュレータベースのワクチンを適用するのに応答して、前記エミュレータベースのワクチンが前記故障を修理するかどうか決定するステップと、
前記エミュレータベースのワクチンが前記故障を修理するという決定に応答して、前記エミュレータベースのワクチンで前記アプリケーションを更新するステップと、
を備えた方法。
【請求項３８】
前記故障の検出は、更に、少なくとも１つのセンサを使用して故障についてアプリケーションを監視することを含む、請求項３７に記載の方法。
【請求項３９】
前記故障の検出は、更に、前記アプリケーションの１つ以上の部分が外部のアタックを受け易いかどうか決定することを含む、請求項３７に記載の方法。
【請求項４０】
前記故障の検出は、更に、前記アプリケーションの１つ以上の部分が欠陥インストラクションを含むかどうか決定することを含む、請求項３７に記載の方法。
【請求項４１】
アプリケーションコミュニティの第１及び第２メンバーに対して動作するアプリケーションを修理するための方法において、
前記アプリケーションを第１及び第２部分に分離するステップと、
前記第１部分を、前記第１部分における故障の評価のために前記第１メンバーに指定するステップと、
前記第２部分を、前記第２部分における故障の評価のために前記第２メンバーに指定するステップと、
前記第１部分における故障の指示と、修理された第１部分とを前記第１メンバーから受け取るステップと、
前記第１部分における故障の指示と、前記修理された第１部分とを前記第２メンバーへ送信するステップと、
を備えた方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、種々様々なソフトウェア故障に反応するための解決策に係る。より詳細には、本発明は、ソフトウェア欠陥及びアタックから自動的に回復するための方法及びシステムに係る。
【０００２】
関連出願へのクロスレファレンス：本出願は、参考としてここに全体を援用する２００５年６月１日出願の米国特許出願第１１／１４２，７４３号の利益を請求する。
【背景技術】
【０００３】
アプリケーションは、多数の脅威、プログラムエラー、ソフトウェア欠陥、アタック、又は他の適当なソフトウェア故障のために終了することがある。コンピュータウイルス、ワーム、トロイ、ハッカー、キー回復アタック、敵意のある実行、プローブ等は、パブリックコンピュータネットワーク（インターネットのような）及び／又はプライベートネットワーク（会社のコンピュータネットワークのような）に接続されたコンピュータのユーザとって恒常的に厄介なものである。これらの脅威に応答して、多数のコンピュータは、ウイルス防止ソフトウェア及びファイアウオールにより保護されている。しかしながら、これらの予防策は、常に充分なものではない。例えば、多くのサービスは、リモートアタック、大量事象（スラマー及びブラスターのような高速拡散ワームのような）、又は単純なアプリケーションレベルのサービス拒否（ＤｏＳ）アタックに直面したときにも、高い利用性を維持しなければならない。
【０００４】
これらの脅威とは別に、アプリケーションは、一般に、プログラマーのエラーから通常生じるオペレーション中のエラーを含む。アプリケーションが、上述した脅威の１つによりアタックされるか、又はオペレーション中のエラーを含むかに関らず、これらのソフトウェア欠陥及び故障は、不当なメモリアクセスエラー、ゼロで割り算するエラー、バッファオーバーフローアタック、等を引き起こす。これらのエラーは、アプリケーションがその実行を終了させ、即ち「クラッシュ」を生じさせる。
【０００５】
例えば、安全な言語、ライブラリー及びコンパイラー、コード分析ツール、及び開発メソッドの使用によりコードをできるだけ信頼可能にすることを求める先見的アプローチを実施する解決策が提案されている。又、欠陥後の分析及び回復をプログラマーにとってできるだけ容易にするよう試みるデバッグ支援も提案されている。更に、正しい解答を選択するために多数のサービスインスタンスの中で投票を使用するビザンチン欠陥許容機構も提案されている。しかしながら、これらの欠陥許容機構は、欠陥の振舞いを示すのは少数のレプリカだけであるという仮定のもとで動作する。実際には、この問題を解決するこれらアプローチの多くは、一般に先を見越したものではあるが、これらの戦略は、エラーのないコードを生じるものではない。これらの解決策は、典型的に、システム性能が低く、ユーザの相互作用が単調で面倒であり、サービス拒否が自己誘起的である（即ち、オーバーフローが検出されたときに、唯一の別の仕方は、アプリケーションを終了することである）といった問題を示す。更に、サーバーアプリケーションについては、サーバーアプリケーションを簡単に再スタートできないことがしばしばある。というのは、それらは、典型的に、長期実行であり（かなりの量の状態を蓄積し）、そして通常、多くのリモートユーザに作用する多数の脅威を含む。サーバーを再スタートすると、他のユーザへのサービスが否定される。その結果、ソフトウェアは、悪評のバグ及びクラッシュ傾向のままとなる。更に、これらの解決策は、頻繁に訪問されるｅ−コマースウェブサーバーのような高性能、高利用性環境に対して適していない。
【０００６】
更に、これらのアプリケーションは、パーソナルデジタルアシスタント（ＰＤＡ）、セルラー電話、又は自動車用パーソナルコンピュータのような多数のプラットホームにインストールすることができる。例えば、自動車用パーソナルコンピュータでは、プラットホームに対して設計された第三者アプリケーションをユーザがインストールするのを許すためにオープンプラットホームオペレーティングシステムが使用されている。これらのアプリケーションも、ソフトウェア故障の影響を受け易い。このような故障からアプリケーションを保護するためにこれらプラットホームに対してウイルス防止プログラムが現在開発されているが、それらは、しばしば、ユーザの相互作用（例えば、パッチ又は別のアプリケーションをダウンロードし、装置をパーソナルコンピュータに接続し、等々）を必要とし、そしてプラットホームの予め限定されたスペース、メモリ、及び送信帯域巾を占有することでシステム性能を低下させる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
それ故、この技術では、種々のソフトウェア故障を取り扱うためのもので、ユーザ介入を必要とせず且つシステム性能を低下せずにアプリケーションがこのような故障から回復できるように反応性の高い自動アプローチを与える方法及びシステムが要望される。
【０００８】
従って、従来技術のこれら及び他の欠点を克服する方法及びシステムを提供することが望まれる。
【課題を解決するための手段】
【０００９】
本発明のある実施形態によれば、アプリケーションがソフトウェア故障及びアタックから自動的に回復するのを許す自己治癒システム及び方法が提供される。アプリケーションコードの全部又は一部分を選択的にエミュレートし、さもなければ、欠陥が生じたことを検出することにより、このシステムは、検出された欠陥を直ちに取り巻き、マシンインストラクションに対するオペランドを、欠陥の形式に対して適当なものとして確認する。このシステムは、アプリケーションコードのその部分をフィックス(fix)でエミュレートする。これは、アプリケーションコードを更新するか、又は非侵襲的手段により（例えば、ラッパー又はデバッガー型のプロセス制御により）行うことができる。これは、一般的なソフトウェアバグ、ソフトウェア故障、及びアタック（例えば、コンピュータウイルス、ワーム、トロイ、敵意のある実行、プローブ、サービス拒否アタック、リソース欠乏アタック、バッファオーバーフロー、バッファアンダーフロー、不当メモリアクセス、ゼロによる除算、チェック時間・対・使用時間（ＴＯＣＴＴＯＵ）違反、及び／又はプログラミングエラー）の存在中でサービス利用性を高める。
【００１０】
ある実施形態では、ソフトウェア故障を検出してそこからアプリケーションを修理するための方法及びシステムが提供される。１つ以上のセンサ（例えば、ホストベースセンサ、受動的センサ、ハニーポット、等）を使用して、アプリケーションが故障に対して監視される。本発明のある実施形態によれば、センサは、アプリケーションをシミュレートする個別サーバーにおいて実施されるハニーポットである。
【００１１】
故障を検出するのに応答して、故障を生じさせたアプリケーションコードの部分が分離される。故障を生じさせた入力ベクトル、故障に関する情報（例えば、故障の形式）、コアダンプファイル（例えば、スタックトレース）、等を使用して、故障を修理するエミュレータベースのワクチンが構成される。ワクチンが故障を修理したという確認に応答して、アプリケーションがエミュレータベースのワクチンで更新される。
【００１２】
或いは又、センサは、アプリケーションのコードを分析し、そしてコードのどの部分が故障の影響を受け易いか、又はコードのどの部分が特定の故障を示す確率が高いかを予想してもよい。
【００１３】
本発明のある実施形態によれば、ソフトウェアモノカルチャーで得られるリソースを効率的に使用するためのアプリケーションコミュニティを生成するシステム及び方法が提供される。これらの結合されたリソースを使用して、アプリケーションコミュニティの各メンバーを保護する一方、故障を検出し分析するコスト（例えば、計算、メモリ、ディスク等）をコミュニティの全メンバーにわたって分散させることができる。
【００１４】
ある実施形態では、複数の装置（例えば、ワークステーション、サーバー、等）を含むアプリケーションコミュニティが定義される。アプリケーションのコードは、より小さなコード部分に分割され、これらは、複数の装置の各々に監視のために指定される。コードのこれら部分は、スタティックな割り当て、ランダムな割り当て、重み付けされた割り当て、ボランティア割り当て、及びバーゲン式の割り当てにより指定されることに注意されたい。又、監視のためにコード部分を指定するための他の適当なアプローチを、上述したアプローチと共に、又はそれに代わって、使用してもよいことに注意されたい。或いは、コードの部分を指定するのではなく、複数の装置の各々に特定の故障を指定してもよい。
【００１５】
コードの指定部分を受け取るのに応答して、各装置は、アプリケーションのコードの指定部分をアプリケーションのローカルインスタンスにおける故障について監視し、故障の検出に応答してコードの指定部分を分析し、そして故障を修理するエミュレータベースのワクチンを構成する。ワクチンが故障を修理したことを確認するのに応答して、各装置は、エミュレータベースのワクチンでアプリケーションを更新し、そして他の装置に故障を通知する。
【００１６】
以上、本発明の重要な特徴を若干広範囲に要約し、以下の詳細な説明が良く理解できるようにすると共に、この技術に対する本発明の貢献が明らかとなるようにした。もちろん、特許請求の範囲の要旨を形成する本発明の付加的な特徴も以下に説明する。
【００１７】
この点に関して、本発明の少なくとも１つの実施形態を詳細に説明する前に、本発明は、添付図面に示されて以下に説明された構造の細部及びコンポーネントの配列に制限されないことを理解されたい。本発明は、他の実施も可能であり、又、種々の仕方で実施することもできる。又、ここで使用する表現及び用語は、説明のためのものであり、それに限定されるものではないことを理解されたい。
【００１８】
従って、当業者であれば、この開示の基礎となる概念は、本発明の多数の目的を果たすための他の構造、方法及びシステムを構成する基礎として容易に利用できることが明らかであろう。それ故、特許請求の範囲は、本発明の精神及び範囲から逸脱しない同等の構造を包含するとみなすことが重要である。
【００１９】
これらの目的、及び本発明の他の目的は、本発明を特徴付ける新規性の種々の特徴と共に、本開示の一部分を形成する特許請求の範囲に特に指摘される。本発明、その使用により達せられる動作上の効果及び特定の目的を良く理解するために、本発明の好ましい実施形態が図示された添付図面を参照して説明する。
【００２０】
本発明の種々の目的、特徴、及び効果は、同じ要素が同じ参照番号で示された添付図面を参照した以下の詳細な説明から完全に明らかとなろう。
【発明を実施するための最良の形態】
【００２１】
以下の説明では、本発明を完全に理解するために、本発明の方法及びシステム、並びにこのような方法及びシステムが動作する環境、等に関して多数の特定の細部を述べる。しかしながら、当業者であれば、このような特定の細部を伴わずに本発明を実施できることが明らかであると共に、本発明の要旨が複雑になるのを回避するために、この技術で良く知られた幾つかの特徴は詳細に説明しない。それに加えて、以下に述べる実施例は、例示に過ぎず、本発明の範囲内で他の方法及びシステムも意図されることが理解されよう。
【００２２】
図１は、本発明のある実施形態に基づき、他のアプリケーションを監視し、修理し、そして更新するアプリケーションの実施に適した例示的システム１００の概略図である。図１を参照すれば、本発明を実施するための例示的システム１００が示されている。図示されたように、システム１００は、１つ以上のワークステーション１０２を備えている。ワークステーション１０２は、互いにローカルであっても互いにリモートであってもよく、そして１つ以上の通信リンク１０４により通信ネットワーク１０６に接続され、この通信ネットワークは、通信リンク１０８によりサーバー１１０にリンクされる。
【００２３】
システム１００において、サーバー１１０は、アプリケーションを実行するための適当なサーバー、例えば、プロセッサ、コンピュータ、データ処理装置、又はこのような装置の組み合せでよい。通信ネットワーク１０６は、インターネット、イントラネット、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイヤレスネットワーク、デジタル加入者ライン（ＤＳＬ）ネットワーク、フレームリレーネットワーク、非同期転送モード（ＡＴＭ）ネットワーク、バーチャルプライベートネットワーク（ＶＰＮ）、又はそれらの組み合せを含む適当なコンピュータネットワークでよい。通信リンク１０４及び１０８は、ワークステーション１０２とサーバー１１０との間でデータを通信するのに適した通信リンク、例えば、ネットワークリンク、ダイヤルアップリンク、ワイヤレスリンク、ハードワイヤードリンク、等でよい。ワークステーション１０２は、パーソナルコンピュータ、ラップトップコンピュータ、メインフレームコンピュータ、ダンプターミナル、データディスプレイ、インターネットブラウザ、パーソナルデジタルアシスタント（ＰＤＡ）、２方向ページャー、ワイヤレスターミナル、ポータブル電話、等、又はそれらの組み合せでよい。ワークステーション及びサーバー１１０は、任意の適当な位置に配置されてもよい。一実施形態では、ワークステーション１０２及びサーバー１１０は、ある組織内に配置される。或いは又、ワークステーション１０２及びサーバー１１０は、多数の組織間に分散されてもよい。
【００２４】
図１に示されたサーバー及び１つのワークステーションが図２に詳細に示されている。図２を参照すれば、ワークステーション１０２は、プロセッサ２０２、ディスプレイ２０４、入力装置２０６、及びメモリ２０８を備え、これらは相互接続される。好ましい実施形態では、メモリ２０８は、プロセッサ２０２を制御するためのワークステーションプログラムを記憶する記憶装置を含む。又、メモリ２０８は、本発明により欠陥を検出してそこからアプリケーションを修理するためのアプリケーションも含む。ある実施形態では、このアプリケーションは、ワークステーション１０２又はサーバー１１０のメモリに常駐されてもよい。
【００２５】
１つの特定の実施形態では、アプリケーションは、クライアント側ソフトウェア、ハードウェア、又はその両方を含む。例えば、アプリケーションは、１つ以上のウェブページ又はウェブページ部分を包含する（例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ）、ダイナミックハイパーテキストマークアップ言語（ＤＨＴＭＬ）、拡張可能なマークアップ言語（ＸＭＬ）、Ｊａｖａサーバーページ（ＪＳＰ）、アクティブサーバーページ（ＡＳＰ）、コールドヒュージョンのような適当なエンコーディング、又は他の適当なアプローチを経て）。
【００２６】
アプリケーションは、ここでは、ワークステーションにおいて実施されるとして説明するが、これは、単なる例示に過ぎない。アプリケーションは、このような特徴を発揮するように適当なプラットホーム（例えば、パーソナルコンピュータ（ＰＣ）、メインフレームコンピュータ、ダンプターミナル、データディスプレイ、２方向ページャー、ワイヤレスターミナル、ポータブル電話、ポータブルコンピュータ、パルムトップコンピュータ、Ｈ／ＰＣ、自動車用ＰＣ、ラップトップコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、複合セルラー電話及びＰＤＡ、等）で実施されてもよい。
【００２７】
プロセッサ２０２は、ワークステーションプログラムを使用して、ディスプレイ２０４に、通信リンク１０４を経て受け取ったアプリケーション及びデータと、ワークステーション１０２のユーザにより送信されたコマンド及び値とを与えることができる。又、通信リンク１０４又は他の通信リンクを経て受け取られるデータは、ウェブサービスのような適当なソースから受け取られてもよいことに注意されたい。入力装置２０６は、コンピュータキーボード、カーソル−コントローラ、ダイヤル、スイッチバンク、レバー、或いは入力システム又はプロセス制御システムの設計者により使用される他の適当な入力装置でよい。
【００２８】
サーバー１１０は、プロセッサ２２０、ディスプレイ２２２、入力装置２２４、及びメモリ２２６を備え、これらは相互接続される。好ましい実施形態では、メモリ２２６は、通信リンク１０８又は他のリンクを経て受け取られるデータを記憶するための記憶装置を含み、又、１人以上のユーザにより送信されるコマンド及び値も受け取る。記憶装置は、更に、プロセッサ２２０を制御するためのサーバープログラムも含む。
【００２９】
一般的に述べると、本発明は、アプリケーションにおける欠陥を検出し、そして欠陥を検出したときに、アプリケーションの将来の実行時に欠陥が発生するのを禁止及び／又は防止するための方法及びシステムに向けられる。「アプリケーション」及び「サービス」という語は、ここでは、交換可能に使用されることに注意されたい。例えば、以下に述べるように、アプリケーション又はサービスは、欠陥の特定形式に対して１つ以上のソフトウェアプローブを使用して監視することができる。又、「欠陥」、「アタック」及び「故障」という語も、交換可能に使用されることに注意されたい。例えば、以下に述べるように、システムは、種々様々なソフトウェア故障、欠陥及びアタックに反応するように使用される。これらのソフトウェア欠陥及びアタックは、例えば、不当なメモリアクセス、ゼロによる除算、及びバッファオーバーフロー（より一般的には、制御ハイジャック）アタックを含む。
【００３０】
本発明のある実施形態によれば、アプリケーションがソフトウェア故障及びアタックから自動的に回復するのを許す自己治癒システムが提供される。欠陥が生じたことをシステムが検出したときにアプリケーションコードの少なくとも一部分又は全部を選択的にエミュレートすることにより、システムは、検出された欠陥を包囲し、マシンインストラクションに対するオペランドを、欠陥の形式に対して適当であると確認する。システムは、アプリケーションコードのその部分をフィックスでエミュレートし、そしてアプリケーションを更新する。これは、一般的なソフトウェアバグ、ソフトウェア故障、アタックの存在中で、サービスの利用を高める。
【００３１】
図３及び４は、本発明のある実施形態に基づきアプリケーションの欠陥を検出してアプリケーションをフィックスする際に遂行される種々のステップを示す簡単なフローチャートである。これらは、一般化されたフローチャートである。図３及び４に示すステップは、適当な順序で遂行することができ、あるものを削除し、他のものを追加してもよいことを理解されたい。
【００３２】
一般に、プロセス３００は、ステップ３１０において、１つ以上のアプリケーション内で種々の形式の故障を検出することで始まる。ある実施形態では、故障の検出は、１つ以上のアプリケーションを故障について監視することを含む。ある実施形態では、故障の監視又は検出は、ステップ３１０において、１つ以上のセンサを使用して遂行される。上述したように、故障は、プログラミングエラー、例外、ソフトウェア欠陥（例えば、不当なメモリアクセス、ゼロによる除算、バッファオーバーフローアタック、チェック時間・対・使用時間（ＴＯＣＴＴＯＵ）違反、等）、脅威（例えば、コンピュータウイルス、ワーム、トロイ、ハッカー、キー回復アタック、敵意のある実行、プローブ等）、及び異常なアプリケーションの終了を生じるか又は１つ以上のアプリケーションに悪影響を及ぼす他の適当な欠陥を含む。例えば、センサのセットは、ウェブサーバー上で実行されるアプリケーションを故障について監視することができる。
【００３３】
適当なセンサを使用して、故障を検出し、又は１つ以上のアプリケーションを監視することができる。ある実施形態では、配備されたアプリケーション及びサーバーの振舞いを監視するホストベースのセンサを使用することができる。別の適当な実施形態では、ファイアウオールにおける受動的センサを使用して、サーバー（例えば、図１のサーバー１１０）へ及びサーバーから進行するトラフィックを立ち聞き又は聴取することができる。ある実施形態では、ターゲットアプリケーションの振舞いを模擬しそして通信を捕獲するハニーポットを使用することもできる。ハニーポットとは、例えば、潜在的なハッカーにおいて誘惑するおとりとして働く一方、ネットワークへの限定されたアクセスだけを潜在的なハッカーに与え、これにより、ハニーポットがハッカーを監視すると共に、ハッカーがシステムにどのように侵入できるか決定できるようにする個別のサーバーである。ハニーポットは、ファイアウオール内にインストールされてもよいが、ハニーポットは、ファイアウオールの外部にもインストールできることに注意されたい。又、センサを組み合せて同時に使用してもよいことにも注意されたい。これらのセンサは、互いに通信し、サーバーと通信し、又は１つ以上のワークステーションと通信することができる。
【００３４】
ステップ３２０において、センサからのフィードバックを使用して、所与のアプリケーションコードのどの部分が特定クラスのアタック（例えば、遠隔利用可能なバッファオーバーフロー）の影響を受け易いか予想することができる。ある実施形態では、センサは、欠陥が生じたことも検出できる。ステップ３３０において、欠陥が生じ得ると予想するか、又は欠陥が生じたことを検出すると、欠陥のあるインストラクション又は影響を受け易いファンクションを有するアプリケーションコードの部分が分離され、これにより、予想される欠陥を局所化する。
【００３５】
或いは又、図４に示すように、アプリケーションが異常に終了させられるまで１つ以上のセンサがアプリケーションを監視してもよい。システムは、欠陥が生じたことを検出し、実際のアプリケーションを終了させることができる。図４に示すように、ステップ４１０において、システムは、正常に動かないアプリケーションを強制的に中止させる。アプリケーションの終了に応答して、システムは、ステップ４２０において、コアダンプファイルを発生するか、又は他の故障関連情報を形成する。コアダンプファイルは、例えば、その故障が生じたときに故障の形式及びスタックトレースを含むことができる。コアダンプファイルに少なくとも一部分基づいて、システムは、ステップ４３０において、欠陥インストラクションを含むアプリケーションコードの部分を分離する。コアダンプファイルを使用して、システムは、アプリケーションの分離された部分又はスライスに選択的エミュレーションを適用することができる。例えば、システムは、スタックトレースにおける最上位ファンクションでスタートすることができる。
【００３６】
図３に戻ると、ある実施形態において、システムは、アプリケーションのインスツルーメントバージョンを発生することができる（ステップ３４０）。例えば、アプリケーションのインスツルーメントバージョンは、アプリケーションコードの一部分又はアプリケーションコードの全部のコピーでよい。システムは、アプリケーションのインスツルーメント部分を観察することができる。アプリケーションのこれら部分は、特定クラスのアタックの影響の受け易さに基づいて選択される。インスツルーメントアプリケーションは、１つ以上のアプリケーションを現在実行しているサーバー、個別のサーバー、ワークステーション、又は他の適当な装置において実行されてもよい。
【００３７】
アプリケーションコードの一部分を分離しそしてその部分にエミュレータを使用することで、システムは、免疫化されたアプリケーションに対する性能の影響を減少及び／又は最小にできることに注意されたい。しかしながら、この実施形態は、アプリケーションコードの一部分又はスライスを分離するが、アプリケーション全体をエミュレートすることもできる。エミュレータは、ソフトウェアで完全に実施することもできるし、或いはシステムプロセッサ又はアーキテクチャー、又はオペレーティングシステムによりオファーされる他のファシリティのハードウェア特徴の利点を取り入れて、監視及びエミュレーションの性能の影響を減少及び／又は最小にし、且つ故障取り扱いの精度及び有効性を改善することができる。
【００３８】
このような影響の受け易さを利用する試みは、アタック又は入力ベクトル及び他の関連情報（例えば、アタックを受けるバッファ、影響を受け易いファンクション、スタックトレース、等）を露呈させる。次いで、アタック又は入力ベクトル及び他の関連情報を使用して、ステップ３５０において、エミュレータベースのワクチン、又はマシン−インストラクションレベルでアレー境界チェックを実施するフィックス、或いは検出された形式の故障に適した他のフィックスを構成する。次いで、ワクチンを、インスツルーメントアプリケーションにおいて、インストラクション−レベルエミュレータ（例えば、ｌｉｂｔａｓｖｍ  ｘ８６エミュレータ、ＳＴＥＭ  ｘ８６エミュレータ、等）を使用して、欠陥がフィックスされたかどうか、及び他のファンクション（例えば、臨界ファンクション）がフィックスの影響を受けたかどうか決定する。
【００３９】
インストラクション−レベルエミュレータを使用して種々のワクチンを連続的にテストすることにより、システムは、特定の欠陥を生じた事象シーケンス（例えば、入力ベクトル）に対してインスツルーメントアプリケーションを実行することによって特定の欠陥が修理されたかどうか検証することができる。例えば、フィックスの有効性を検証するために、アプリケーションは、テスト環境において、又はインスツルーメンテーションがイネーブルされたサンドボックスにおいて再スタートされ、そして故障を生じさせた１つ以上の入力ベクトルが供給される。サンドボックスは、一般に、インスツルーメントアプリケーション又はアプリケーションのファンクションが要求し又はアクセスするシステムリソースに厳密な制約が課せられる環境を生成する。
【００４０】
ステップ３６０において、インストラクション−レベルエミュレータがアプリケーションコードのセグメントに対して選択的に呼び出され、システムが、エミュレートされたコード及び非エミュレートのコードを同じコード実行内で混合するのを許す。エミュレータを使用して、例えば、インストラクションの実行前に特定形式の故障を検出し及び／又は監視し、インストラクションの実行中にメモリ変更（例えば、グローバル変数、ライブラリー内部状態、ｌｉｂｃ規格Ｉ／Ｏ構造、等）及びオリジナル値を記録し、メモリスタックをそのオリジナル状態に復帰させ、そしてアプリケーションのファンクションからのエラー返送をシミュレーションすることができる。即ち、アプリケーションコードの、影響を受け易い区分に入るときに、インストラクション−レベルエミュレータは、プログラム状態を捕獲して記憶し、そしてエミュレーションのために指定されたエリア内でファンクションコールを含む全てのインストラクションを処理する。プログラムカウンタが、エミュレーションの境界外の第１インストラクションを参照するときに、バーチャルプロセッサは、その内部状態を装置プロセッサレジスタへコピーして戻す。レジスタが更新される間に、エミュレーションの実行を通じてメモリの更新も適用される。バーチャルプロセッサによって実行されるインストラクションに気付かないプログラムは、実際のプロセッサにおいて通常の実行を継続する。
【００４１】
ある実施形態では、インストラクション−レベルエミュレータは、前もってアプリケーションにリンクすることができる。或いは又、検出された故障に応答して、インストラクション−レベルエミュレータは、コードがコンパイルされてもよい。別の適当な実施形態では、インストラクション−レベルエミュレータは、特定のプログラムインストラクションが実行されるときに近代的なデバッガーに類似した仕方で呼び出される。これは、システムプロセッサ及びアーキテクチャーが所有するブレークポイントレジスタ及び／又は他のプログラムデバッグファシリティの利点を取り入れることもできるし、或いは本発明が実施される装置のオペレーティングシステム及びハードウェアに適した純粋なソフトウェアアプローチであってもよい。
【００４２】
エミュレータを使用すると、システムは、広範囲なソフトウェア故障、例えば、不当なメモリデレファレンス、バッファオーバーフロー、及びバッファアンダーフロー、並びにより一般的な欠陥、例えば、ゼロによる除算を検出し及び／又は監視することができる。エミュレータは、欠陥を検出した１つ以上のセンサによって与えられるベクトル及び関連情報を少なくとも部分的に使用して、それがエミュレートしようとするインストラクションのオペランドをチェックする。例えば、ゼロによる除算の場合には、エミュレータは、ｄｉｖインストラクションに対してオペランドの値をチェックする。別の例では、不当なメモリデレファレンスの場合に、エミュレータは、メモリアクセスのソース及び行先アドレス（又はインストラクションフェッチのためのプログラムカウンタ）が、ｍｉｎｃｏｒｅ（）システムコール、又はオペレーティングシステムにより与えられる適当なファシリティを使用してプロセスアドレススペースへマップされたページを指すかどうか検証する。更に別の例では、バッファオーバーフロー検出の場合に、１つ以上のセンサにより識別された、影響を受け易いバッファを取り巻くメモリは、１バイト詰め込まれる。次いで、エミュレータは、これらメモリ位置へのメモリ書き込みをウオッチする。これは、特定の変数（例えば、それ自体周期的に起動し、そしてある典型的なユーザトランザクションを行なって、２４時間ぶっ通しのトランザクション待ち時間評価を行なえるようにするカナリー変数）を挿入するためにソースコードの利用を必要とすることに注意されたい。又、エミュレータは、メモリスタックの残りの位置にオーバーライトする前にオーバーフローを防止し、そして実行を回復することにも注意されたい。これらファシリティを検出する他のアプローチを、システムの高レベルオペレーション及び特性に影響を及ぼさずに、モジュラー式にシステムに合体することができる。
【００４３】
例えば、インストラクション−レベルエミュレータは、選択的エミュレーションの開始及び終了をマークする特殊なタグ（例えば、マクロ及びファンクションコールの組み合せ）を定義するスタティックにリンクされたＣライブラリーとして実施されてもよい。インストラクション−レベルエミュレータによりエミュレーションするためにアプリケーションコードのセグメントの周りに配置されるタグの一例が図５に示されている。図５に示すように、Ｃマクロｅｍｕｌａｔｅ＿ｉｎｔ（）は、プログラム状態（一般、セグメント、ｅｆｌａｇｓ、及びＦＰＵレジスタ）を、エミュレータアクセス可能なグローバルデータ構造体へと移動し、エミュレータが制御を行なう直前に状態を捕獲する。このデータ構造体を使用して、バーチャルレジスタを初期化する。ｅｍｕｌａｔｅ＿ｂｅｇｉｎ（）は、それ自身へのコールに続く第１インストラクションのメモリ位置を得る。インストラクションアドレスは、復帰アドレスと同じであり、そのベーススタックポインタより４バイト上で、ｅｍｕｌａｔｅ＿ｂｅｇｉｎ（）のアクチベーションレコードに見つけることができる。インストラクションのフェッチ／デコード／実行／リタイヤサイクルは、ｅｍｕｌａｔｅ＿ｅｎｄ（）に到達するまで、又は制御が親ファンクションへ復帰することをエミュレータが検出するときまで続けられる。エミュレータがその実行中にエラーに遭遇しない場合には、エミュレータのインストラクションポインタは、完了時に、ｅｍｕｌａｔｅ＿ｔｅｒｍ（）マクロを参照する。このアドレスにおいてインスツルーメントアプリケーションの実行を継続できるようにするために、ｅｍｕｌａｔｅ＿ｂｅｇｉｎ（）アクチベーションレコードの復帰アドレスが、インストラクションポインタの現在値に置き換えられる。ｅｍｕｌａｔｅ＿ｔｅｒｍ（）を実行することにより、エミュレータの環境がプログラムレジスタにコピーされ、通常の条件の下で実行が続けられる。
【００４４】
本発明の実施形態は、エミュレータが、影響を受け易いアプリケーションにリンクされること、及び／又は影響を受け易いアプリケーションのソースコードを利用できることを述べるが、本発明は、実行中のプロセスが、それが現在エミュレータのもとで実行していることを検出できるようにしなくとも、プロセッサのプログラム可能なブレークポイントレジスタを使用してエミュレータを呼び出せるものであることに注意されたい。
【００４５】
インストラクションを実行する前に故障を監視し、そして故障が生じたときに、特定のファンクションによりなされたメモリ変化を元に戻す（例えば、エミュレータ記憶メモリ変更をその実行中に行なわせることにより）のに加えて、エミュレータは、ファンクションからのエラー復帰もシミュレーションする。本発明を使用すると、システムは、アプリケーションの実行中に生じ得るエラーのセットと、アプリケーションコードによって明確に取り扱われるエラーの限定セットとの間のマップを生成することができる（ここでは、「エラーバーチャル化(error virtualization)」とも称される）。以下に述べるように、本発明のエラーバーチャル化特徴は、発見的解決法に基づくものでよい。しかしながら、あるファンクションに対する復帰値を決定するための適当なアプローチが使用されてもよい。例えば、あるファンクションに適した復帰値を決定するための積極的ソースコード分析技術が使用されてもよい。別の例では、特定ファンクションのコードの部分がフェイルセーフとしてマークされ、そしてエラー復帰が強制されるときに特定値を返送することができる（例えば、ユーザ許可をチェックするコードに対して）。更に別の例では、故障したファンクションに対して返送されるエラー値は、プログラマー、システムアドミニストレータ、又は他の適当なユーザによって与えられる情報を使用して決定される。
【００４６】
これらのエラーバーチャル化特徴は、欠陥の発生を許容したプログラマーにより最初に予想されなかった境界条件でも、アプリケーションが実行を継続できるようにする。特に、エラーバーチャル化特徴は、プログラマーにより予想されない欠陥に対して、アプリケーションコードが例外キャッチメカニズムで改造されるのを許す。エラーバーチャル化は、プログラマーがプログラムコードに例外を慎重に生成し且つそれら例外を取り扱うためのコードを追加しなければならない、あるプログラミング言語で実施される慣習的な例外ハンドリングとは異なる点に注意されたい。エラーバーチャル化のもとでは、本発明は、例えば、プログラマーにより予想されなかった故障及び例外をキャッチし、そして本発明は、既存のアプリケーションコードを使用して、それらをハンドリングする。本発明のある実施形態では、エラーバーチャル化は、インストラクション−レベルエミュレータを経て実施される。或いは又、エラーバーチャル化は、アプリケーションのソースコードで直接的に挿入される付加的なソースコードにより実施されてもよい。このような付加的なソースコードのこの挿入は、上述したように故障の検出に続いて、又は故障の予想に続いて自動的に遂行されてもよいし、或いはアプリケーションのソースコードにアクセスできるプログラマー、システムオペレータ、又は他の適当なユーザの指示のもとで行われてもよい。
【００４７】
エラーバーチャル化を使用すると、エミュレーション中に例外が生じたとき、又は欠陥が生じたことをシステムが検出した場合に、システムは、プログラムの状態をそのオリジナル設定に復帰させ、そして現在実行中のファンクションからのエラー復帰を強制する。適切なエラー値を決定するために、システムは、ファンクションの宣言された形式を分析する。ある実施形態では、システムは、例えば、ＴＸＬスクリプトを使用して、ファンクションの宣言された形式を分析することができる。一般的に、ＴＸＬは、ハイブリッドファンクションで且つルールベースの言語であり、ソース／ソース変換を遂行すると共に、新たな言語及び言語プロセッサを迅速に試作するのに使用できるものである。ファンクションの宣言された形式に基づき、システムは、適切なエラー値を決定し、それを復帰ファンクションのスタックフレームに入れる。適切なエラー値は、発見的解決法に少なくとも一部分基づいて決定されてもよい。例えば、復帰形式がｉｎｔである場合には、−１の値が戻される。復帰形式が非符号のｉｎｔである場合には、システムは、０を返送する。ファンクションがポインタを返送する場合には、システムは、返送されたポインタが親ファンクションにより更にデレファレンスされるかどうか決定する。返送されたポインタが更にデレファレンスされる場合には、システムは、親ファンクションを含むようにエミュレーションの範囲を拡張する。別の例では、復帰エラーコードは、アプリケーションのソースコードに埋め込まれた情報を使用して決定されるか、或いはアプリケーションプログラマー、システムアドミニストレータ又は第三者によりシステムに与えられる付加的な情報により決定される。
【００４８】
ある実施形態では、ｅｍｕｌａｔｅ＿ｅｎｄ（）が探索され、エミュレーションが終了する。エミュレータは、スタート前にアプリケーションの状態をセーブし、そしてアプリケーションの実行中にメモリの変更を追跡するので、システムは、欠陥が内部に生じたコードファンクションによりなされたメモリ変化を、それをオリジナル設定に復帰させることで逆転させ、これにより、エミュレーションを通して処理されるインストラクションの作用をナル化することができる。即ち、コードのエミュレートされた部分は、スライス除去され、そしてコードの実行が、メモリへの変化に関するその副作用と共に、ロールバックされる。
【００４９】
例えば、エミュレータは、カーネルレベルの許可なしにシステムコールを直接的に遂行することはできない。それ故、エミュレータが０ｘ８０の中間値での割り込みをデコードするときには、エミュレータがカーネルへ制御を解放する。しかしながら、カーネルがシステムコールを実行する前に、エミュレータが真のレジスタをバックアップし、そしてそれらをそれ自身の値に置き換える。ＩＮＴ０ｘ８０はエミュレータにより発行され、そしてカーネルがシステムコールを処理する。制御がエミュレータに復帰すると、エミュレータは、そのレジスタを更新し、そしてアプリケーションレジスタにオリジナル値を回復させる。
【００５０】
インスツルーメントアプリケーションが強制復帰後にクラッシュしない場合には、システムは、サーバーにおいて実行される実際のアプリケーションに使用できる特定欠陥に対するワクチンを首尾良く見つける。ステップ３７０において、システムは、エミュレーションに少なくとも一部分基づいてアプリケーションを更新する。
【００５１】
本発明のある実施形態によれば、ソフトウェアモノカルチャーのセキュリティリスクを軽減するために人為的ダイバーシティ特徴を設けることができる。
【００５２】
ソフトウェアモノカルチャーは、ネットワーク化されたコンピューティング環境に対する問題として識別されている。モノカルチャーは、アタッカーに対する増幅器として働き、アタッカーが、同じアプリケーションの多数のインスタンス（例えば、数千又は数百万のインスタンス）にわたり、同じ影響され易さを利用するのを許す。このようなアタックは、多数の最近の出来事により証明されるように、広範な混乱を急速に生じさせる潜在性がある。
【００５３】
多数の他のシステムは、人為的ダイバーシティを導入するように試みるが、既存のソフトウェアモノカルチャーの利点を使用して、ソフトウェアモノカルチャーのセキュリティリスクを軽減することができる。ある実施形態では、アプリケーションコミュニティを生成して、大きなモノカルチャーにおいて入手できるリソースを効率的に使用し、各アプリケーションコミュニティメンバーを保護することができる。ここで使用するアプリケーションコミュニティとは、欠点及びアタックに対するそれらの実行を協力的に監視しそしてそのような事象が検出されたときにコミュニティに通知する同じアプリケーションの独立したインスタンスの集合である。例えば、上述したシステムでは、１つ以上のワークステーションと、ワイドエリアネットワーク（例えば、インターネット）にわたって１つ以上のアプリケーションを実行するサーバーとが、アプリケーションコミュニティのメンバーである。各ワークステーションは、アプリケーションコードの異なる部分を監視することにより協働し、これにより、アプリケーションを監視するために各ワークステーションにより割り当てられるメモリを分散させることができる。別の適当な実施形態では、各ワークステーションは、異なる故障に対してアプリケーションを監視することにより協働してもよい。コードの監視された部分が故障の影響を受け易いことを検出するのに応答して、又はアプリケーションコードの監視された部分における故障の発生を検出するのに応答して、ワークステーションは、他のワークステーション及びサーバーに故障を通知することができる。
【００５４】
図６は、本発明のある実施形態により、アプリケーションコミュニティを使用してアプリケーションを欠陥について監視し、そしてアプリケーションを修理する上で遂行される種々のステップを示す簡単なフローチャートである。これは、一般化されたフローチャートである。図６に示すステップは、適当な順序で遂行されてもよく、あるものが削除されてもよく、そして他のものが追加されてもよいことを理解されたい。
【００５５】
一般的に、システムは、ステップ６１０において、アプリケーションコードをコードの部分に分割することができる。アプリケーションコードの各部分又はスライスは、例えば、アプリケーションコミュニティのメンバーの１つ（例えば、ワークステーション、サーバー、等）に指定される。アプリケーションコミュニティの各メンバーは、ステップ６２０において、種々の形式の故障についてコードの部分を監視する。上述したように、故障は、プログラミングエラー、例外、ソフトウェア欠陥（例えば、不当なメモリアクセス、ゼロによる除算、バッファオーバーフローアタック、ＴＯＣＴＴＯＵ違反、等）、脅威（例えば、コンピュータウイルス、ワーム、トロイ、ハッカー、キー回復アタック、敵意のある実行、プローブ等）、及び異常なアプリケーションの終了を生じるか又は１つ以上のアプリケーションに悪影響を及ぼす他の適当な欠陥を含む。
【００５６】
例えば、システムは、アプリケーションコミュニティにおけるアプリケーションのサイズ及びメンバーの数（即ち、アプリケーションコミュニティにおけるアプリケーション／メンバーのサイズ）に基づいてコードの部分を分割する。或いは又、システムは、アプリケーションコミュニティの各メンバーにおける利用可能なメモリの量に基づいてコードの部分を分割してもよい。アプリケーションコードをどのように分割するか決定するのに適したアプローチも使用できる。幾つかの適当なアプローチについて以下に説明する。
【００５７】
例えば、システムは、アプリケーションコードの個別スライスを実行するコストを検査することにより、アプリケーションコミュニティＷにおけるトータルワークを検査する。アプリケーションのコールグラフを構成するファンクションＦのセットを仮定すれば、Ｆのｉ番目のメンバーがｆiとして示される。各ｆiを実行するコストは、ｆiに存在する計算の量（即ち、ｘi）及びｆiにおけるリスクの量（即ち、ｖi）の関数である。ｘiの計算は、少なくとも２つのメトリック、即ちｆiの部分として実行されるマシンインストラクションの数ｏi、及びｆiの実行に費やされる時間の量ｔi、により推進される。ｏi及びｔiは、両方とも、アプリケーションの内部ロジックに基づき時間又はアプリケーションワークロードの関数として変化する。例えば、アプリケーションは、そのアプリケーションがスレッシュホールド数の要求にパスした後に、ロギング又はクリーンアップデューティを遂行する。
【００５８】
ある実施形態では、コスト関数を２つの段階で設けることができる。第１の段階は、各ｆiに対する計算の量によるコストを計算する。第２の段階は、このコストを正規化し、リスクファクタｖiを適用して、各ｆiの最終コスト、及びシステムの全ワーク量を決定する。例えば、次のようになる。
2008547070.tif 000003
Ｃ(ｆi、ｘi)＝ｘi／Ｔ＊１００である場合には、各コストは、ワークの１単位を表わすようにＦのサブセットをグループ分けすることにより正規化される。
【００５９】
ある実施形態では、システムは、関数の、影響され易さの尺度を考慮することができる。例えば、システムは、ｖiをαの値と共に離散的変数として処理し、ここで、αは、次のようにリスクの量に基づき値の範囲をとる。
2008547070.tif 000004
各関数に対してｖiが与えられると、システムは、システムにおける全ワーク量及び監視に必要な全メンバー数を決定することができる。
2008547070.tif 000005
【００６０】
システム（例えば、コントローラ）又は各アプリケーションコミュニティメンバーがシステム内のワーク量を計算した後に、ワーク単位が分散される。一例において、中央コントローラ又は１つのワークステーションは、各ノードにほぼＷ／Ｎのワーク単位を指定する。別の適当な例では、アプリケーションコミュニティの各メンバーは、それ自身のワークセットを決定する。各メンバーは、値ｖi＊ｔiで重み付けされたコインをひっくり返してワーク単位のリストを繰り返し通る。それ故、ひっくり返しの結果が「真」である場合には、メンバーがそのワーク単位をワークセットに追加する。
【００６１】
或いは又、システムは、ｎ＊Ｗのスロットを有するリストを作成することができる。各関数は、リストにおける多数のエントリー（例えば、ｖi＊ｒi）により表わされる。アプリケーションコミュニティの各メンバーは、例えば、コインをトスすることにより繰り返しリストを通る。コインが「ヘッド」又は「真」である場合には、アプリケーションコミュニティのメンバーは、所与のタイムスライスに対してアプリケーションの関数を監視する。重たく重み付けされた関数は、より多くのエントリーをリストに有するので、アプリケーションをカバーするために、より多くのユーザが指定される。メンバーは、その合計ワークがＷ／Ｎに達したときに停止する。このようなアプローチは、アプリケーションの統計学的カバレージをオファーする。
【００６２】
ある実施形態では、分散型入札アプローチを使用して、アプリケーションを監視し及び修理するワークロードを分散することができる。コールグラフＧにおける各ノードは、重みｖi＊ｒiを有する。Ｆにおけるノードのあるサブセットが各アプリケーションコミュニティメンバーに指定され、各メンバーは、Ｗ／Ｎワークより多くのワークを行なわない。スレッシュホールドは、Ｗ／Ｎのある範囲
2008547070.tif 000006
内に入るように弛緩され、ここで、
2008547070.tif 000007
は、システムの公平さの尺度である。ワークＷ／Ｎの全体的に公平な量を計算するときに、各アプリケーションコミュニティメンバーは、分散型入札アプローチを使用して他のメンバーと駆け引きをすることによりそのワークロードを調整することができる。
【００６３】
アプリケーションコミュニティメンバーへのワーク単位の指定に影響する２つの事柄がある。第１に、システムは、ワーク単位に優先的に高い重みを割り当てる。というのは、これらワーク単位は、おそらく、高いｖiのために大きな重みを有するからである。たとえ重みが単に性能コストから導出される場合でも、より高い重みをもつワーク単位に、より多くのメンバーを指定するのが有益である。というのは、これらのメンバーは、１つのメンバーが全コストを引き受けなくてもよいように、監視タスクをラウンドロビンすることができるからである。第２に、ある状況では、ｖi＊ｒiは、平均ワーク量Ｗ／Ｎより大きいことがある。公平性を得ることは、ｖi＊ｒiが、それに指定されるアプリケーションコミュニティメンバーの量を定義し、そしてこれらの量の和が、アプリケーションコミュニティにおけるメンバーの最小数を定義することを意味する。
【００６４】
ある実施形態では、各アプリケーションコミュニティメンバーがテーブルを計算する。このようなテーブルの一例が図７に示されている。テーブルを作成するときに、アプリケーションコミュニティメンバーは、各ワークロードを調整するために入札を行なう。例えば、システムは、入札のためのトークンを使用する。トークンは、アプリケーションコミュニティメンバーがワーク単位又はアプリケーションの関数を監視する役割を果たすところの時間量子の数へ直接マップされる。システムは、各ノードが、
2008547070.tif 000008
の選択により許された全トークン数より多くを累積しないよう保証する。
【００６５】
アプリケーションコミュニティメンバーがその分担以上を監視する場合には、システムがカバレージを増加し、そして欠陥をできるだけ迅速に検出することを保証する。ステップ６３０及び６４０に示すように、各アプリケーションコミュニティメンバーは、欠陥がコードの指定部分に生じることを予想するか、又はアプリケーションを中止する欠陥が生じたことを検出し、この場合、コードの指定部分が欠陥のソースである。欠陥が検出されたときに、アプリケーションメンバーの各々は、欠陥を含むコードの指定部分を先見的に監視し、アプリケーションが更に故障するのを防止する。上述したように、アプリケーションコミュニティメンバーは、欠陥を生じたコードの部分を分離し、エミュレータを使用して、ワクチン又はフィックスをテストする。ステップ６５０において、欠陥を検出又は予想するアプリケーションコミュニティメンバーは、他のアプリケーションコミュニティメンバーに通知する。欠陥に屈服した他のアプリケーションメンバーは、欠陥を検出したアプリケーションメンバーにより生成された保護メカニズム又はフィックスで再スタートすることができる。
【００６６】
アプリケーションコミュニティメンバーにわたり新たな欠陥が均一にランダムに分布すると仮定すれば、メンバーｋに生じる欠陥の確率は、Ｐ（欠陥）＝１／Ｎである。従って、ｋが新たな欠陥を検出する確率は、ｋに欠陥が生じ且つｋが欠陥を検出する確率Ｐ（ｋにおける欠陥Λ検出）＝１／Ｎ＊ｋiであり、ここで、ｋiは、ｋにおけるカバレージのパーセンテージである。アプリケーションコミュニティが欠陥を検出する確率は、次の通りである。
2008547070.tif 000009
各ｋiが１００％になるときに、前記式は、
2008547070.tif 000010
又はＮ／Ｎとなり、欠陥が検出される確率が１であるのは、それが最初に生じるときである。
【００６７】
本発明によれば、種々のソフトウェア故障を監視しそしてそこからアプリケーションを修理するための方法及びシステムが提供される。
【００６８】
又、ここに述べる詳細な説明は、コンピュータ又はコンピュータのネットワークで実行されるプログラム手順に関して表現されることも理解されたい。これら手順の説明及び表現は、当業者が彼等の仕事の実体を他の等業者に最も効率的に伝えるために使用する手段である。
【００６９】
手順とは、ここでは、そして一般的には、望ましい結果を招くステップの自己一貫性シーケンスであると考えられる。これらステップは、物理量の物理的操作を必要とするものである。通常、必ずしもそうでないが、これらの量は、記憶、転送、合成、比較及びその他操作することのできる電気又は磁気信号の形態をとる。時々、主として通常使用の理由で、これらの信号をビット、値、エレメント、記号、キャラクタ、用語、数字、等として参照するのが便利である。しかしながら、これら及び同様の用語は、全て、適当な物理量に関連付けられるべきであり、且つこれらの量に適用される単なる便利な表現に過ぎないことに注意されたい。
【００７０】
更に、行なわれる操作は、人間のオペレータにより遂行される知能的操作に一般に関連した加算又は比較のような用語をしばしば指す。本発明の部分を形成する、ここに述べるいずれの操作においても、人間のオペレータのこのような能力はほとんどの場合に必要とされず、又、望まれない。即ち、操作は、マシンオペレーションである。本発明の操作を遂行するための有用なマシンは、汎用デジタルコンピュータ又は同様の装置を含む。
【００７１】
又、本発明は、これらオペレーションを遂行するための装置にも係る。この装置は、要求される目的に対して特に構成されてもよいし、又はコンピュータに記憶されたコンピュータプログラムにより選択的にアクチベートされ又は再構成される汎用コンピュータを含んでもよい。ここに示す手順は、特定のコンピュータ又は他の装置に固有に関係していない。種々の汎用マシンを、ここに示す教示に基づいて書かれたプログラムで使用してもよいし、或いは必要な方法ステップを遂行するように、より特殊な装置を構成するのがより便利であることが示される。種々様々なこれらマシンに必要な構造は、前記説明から明らかとなろう。
【００７２】
本発明によるシステムは、汎用コンピュータを備えてもよいし、特別にプログラムされた特殊目的のコンピュータを備えてもよい。ユーザは、例えば、パーソナルコンピュータ、ＰＤＡ、インターネット、イントラネット等を経てシステムと対話することができる。これらは、いずれも、単一コンピュータではなく分散型コンピュータシステムとして実施されてもよい。同様に、通信リンクは、専用リンクでもよいし、モデム・オーバー・ＰＯＴＳラインでもよいし、インターネットでもよいし、及び／又はコンピュータ及び／又はユーザ間で通信する他の方法でもよい。更に、処理は、１つ以上のコンピュータシステム又はプロセッサにおいてソフトウェアプログラムで制御することもできるし、或いはハードウェアで部分的に又は全体的に実施されてもよい。
【００７３】
単一のコンピュータを使用できるが、本発明の１つ以上の実施形態によるシステムは、複数のプロセッサ又は記憶装置或いはそれらの組み合せを適宜装備するのも任意である。例えば、コンピュータは、本発明の実施形態の概念に基づいて動作する適当な処理システムに置き換えられてもよいし又はそれと組み合わされてもよく、これは、精巧な計算器、ハンドヘルド、ラップトップ／ノートブック、ミニ、メインフレーム及びスーパーコンピュータ、並びにそれらの処理システムネットワーク組み合せを含む。更に、システムの一部分は、適当な電子的フォーマットで設けられてもよく、例えば、電子信号として通信ラインを経て供給されてもよいし、ＣＤ及び／又はＤＶＤに設けられてもよいし、光学ディスクメモリに設けられてもよいし、等々である。
【００７４】
本発明のこのような実施形態には、現在入手できる又は将来開発されるコンピュータソフトウェア言語及び／又はハードウェアコンポーネントを使用することができる。例えば、上述したファンクションの少なくとも幾つかは、使用するプロセッサの観点で適したビジュアルベーシック、Ｃ、Ｃ＋＋、又はアッセンブリー言語を使用して実施することができる。又、これは、Ｊａｖａのようなオブジェクト指向及び／又は解釈環境で書いて、種々のユーザに対して多数の行先へ搬送することができる。
【００７５】
本発明は、添付図面を参照してここに述べた構造の細部やコンポーネントの配列に限定されないことを理解されたい。本発明は、他の実施形態も考えられ、又、種々の仕方で実施することもできる。又、ここで使用する表現及び用語は、説明のためのものであり、これに限定されないことを理解されたい。
【００７６】
当業者であれば、本開示の基礎となる概念は、本発明の多数の目的を達成するための他の構造、方法、及びシステムを設計する基礎として容易に利用できることが明らかであろう。それ故、本発明の精神及び範囲を逸脱しない限りこのような同等の構造が特許請求の範囲に包含されるとみなすことが重要である。
【００７７】
本発明は、その実施形態について説明したが、本開示は、一例としてなされたものに過ぎず、本発明の精神及び範囲から逸脱せずに本発明の実施の細部に多数の変更がなされ得ることを理解されたい。
【００７８】
次の参考文献は、その全体をここに参照として援用するものである。
CERT Advisory CA-2003-21: W32/Blaster Worm.
http://www.cert.org/advisories/
CA-2003-20.html, August 2003
The Spread of the Sapphire/Slammer Worm. http://www.silicondefense.com/research/worms/slammer.php, February 2003
A. Avizienis. The n-version approach to fault-tolerant software. IEEE Transactions on Software Engineering, 11(12): 1491n1501, 1985.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In proceedings of the USENIX Annual Technical Conference, June 2000.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In proceedings of the USENIX Annual Technical Conference, June 2000.
E. G. Barrantes, D. H. Ackley, S. Forrest, T. S. Palmer, D. Stefanovic, and D. D. Zovi. Randomized Instruction set Emulation to Disrupt Binary Code Injection Attacks. In 10th ACM Conference on Computer and Communications Secrity (CCS), October 2003.
S. Bhatkar, D. C. DuVarney, and R. Sekar. Address Obfuscation: an Efficient Approach to Combat a Broad Range of Memory Error Exploits. In Proceedings of the 12th USENIX Security Symposium, pages 105n120, August 2003.
S. Brilliant, J. C. Knight, and N. G. Leveson. Analysis of Faults in an N-Version Software Experiment. IEEE Transactions on Software Engineering, 16(2), February 1990.
D. Bruening, T. Garnett, and S. Amarasinghe. An Infrastructure for Adaptive Dynamic Optimization. In Proceedings of the International Symposium on Code Generation and Optimization, pages 265-275, 2003.
G. Canadea and A. Fox. Crash-Only Software. In Proceedings of the 9th Workshop on Hot Topics in Operating Systems, May 2003.
【００７９】
H. Chen and D. Wagner. MOPS: an Infrastructure for Examining Security Properties of Software. In proceedings of the ACM computer and Communications Security (CCS) Conference, pages 235-244, November 2002.
M. Chew and D. Song. Mitigating Buffer Overflows by Operating System Randomization. Technical Report CMU-CS-02-197, Carnegie Mellon University, December 2002.
S. A. Crosby and D. S. Wallach. Denial of Service via Algorithmic Complexity Attacks. In Proceedings of the 12th USENIX Security Symposium, pages 29-44, August 2003.
B. Demsky and M. C. Rinard. Automatic Detection and Repair of Errors in Data Structure.  In Proceedings of the 18th Annual ACM SIGPLAN Conference on Object Oriented Programming, Systems, Languages, and Applications, October 2003.
E. Duesterwald and S. P. Amarsinghe. On the Run-Building Dynamic Program Modifiers for Optimization, Introspection, and Security. In Conference on Programming Language Design and Implementation (PLDI), 2002.
G. W. Dunlap, S. King, S. Cinar, M. A. Basrai, and P. M. Chen. ReVirt: Enabling Intrusion Analysis Through Virtual-Machine Logging and Replay. In Proceedings of the Symposium on Operating Systems Design and Implementation (OSDI), February 2002.
【００８０】
C. C. et al. StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. In Proceedings of the 7th USENIX Security Symposium, January 1998.
T. Garfinkel and M. Rosenblum. A Virtual Machine Introspection Based Architecture for Intrusion Detection.  In 10th ISOC Symposium on Network and Distributed Systems Security (SNDSS), February 2003.
D. E. Geer. Monopoly Considered Harmful. IEEE Security & Privacy, 1(6): 14&17, November/December 2003.
G. Goth. Addressing the Monoculture. IEEE Security & Privacy, 1(6): 8-10, November/December 2003.
T. Jim, G. Morrisett, D. Grossman, M. Hicks, J. Cheney, and Y. Wang. Cyclone: A safe dialect of C. In Proceedings of the USENIX Annual Technical Conference, pages 275-288, June 2002.
G. S. Kc, A. D. Keromytis, and V. Prevelakis. Countering Code-Injection Attacks With Instruction-Set Randomization. In 10th ACM Conference on Computer and Communications Security (CCS), October 2003.
【００８１】
S. T. King and P. M. Chen. Backtracking Intrusions. In 19th ACM Symposium on Operating Systems Principles (SOSP), October 2003.
S. T. King, G. Dunlap, and P. Chen. Operating System Support for Virtual Machines. In Proceedings of the USENIX Annual Technical Conference, June 2003.
V. Kiriansky, D. Bruening, and S. Amarasinghe. Secure Execution Via Program Shepherding. In Proceedings of the 11th USENIX Security Symposium, August 2002.
D. Mosberger and T. Jin. Httperf: A tool for measuring web serber performance. In First Workshop on Internet Server Performance, pages 59-67. ACM, June 1998.
N. Nethercote and J. Seward. Valgrind: A Program Supervision Framework. In Electronic Notes in Theoretical Computer Science, volume 89, 2003.
J. Newsome and D. Dong. Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software. In The 12th Annual Network and Distributed System Security Symposium, February 2005.
J. Oplinger and M. S. Lam. Enhancing Software Reliability with Speculative Threads. In proceedings of the 10th International Conference on Architectural Support for Programming Language and Operating Systems (ASPLOS X), October 2002.
V. Prevelakis. A Secure Station for Network Monitoring and Control. In Proceedings of the 8th USENIX Security Symposium, August 1999.
N. Provos. Improving Host Security with System Call Policies. In Proceedings of the 12th USENIX Security Symposium, pages 257-272, August 2003.
【００８２】
J. C. Reynolds, J. Just, L. Clough, and R. Maglich. On-Line Intrusion Detection and Attack Prevention Using Diversity, Generate-and-Test, and Generalization. In Proceedings of the 36th Annual Hawaii International Conference on System Sciences (HICSS), January 2003.
M. Rinard, C. Cadar, D. Dumitran, D. Roy, and T. Leu. A Dynamic Technique for Eliminating Buffer Overflow Vulnerabilities (and Other Memory Errors). In Proceedings 20th Annual Computer Security Applications Conference (ACSAC), Decomber 2004.
M. Rinard, C. Cadar, D. Dumitran, D. Roy, T. Leu, and J. W. Beebee. Enhancing Server Availability and Security Through Failure-Oblivious Computing. In Proceedings 6th Symposium on Operating Systems Design and Implementation (OSDI), Decomber 2004.
A. Rudys and D. S. Wallach. Transactional Rollback for Language-Based Systems. In ISOC Symposium on Network and Distributed Systems Security (SNDSS), February 2001.
【００８３】
A. Rudys and D. S. Wallach. Termination in Language-based Systems. ACM Transactions on Information and System Security, 5(2), May 2002.
H. Shacham, M. Page, B. Pfaff, E. Goh, N. Modadugu, and D. Boneh. On the Effectiveness of Address-Space Randomization. In Proceedings of the 11th ACM Conference on Computer and Communications Security (CCS), pages 298-307, October 2004.
S. Sidiroglou and A. D. Keromytis. A Network Worm Vaccine Architecture. In Proceedings of the IEEE Workshop on Enterprise Technologies: Infrastructure for Collaborative Enterprise (WETICE), Workshop on Enterprise Security, pages 220-225, June 2003.
S. Sidiroglou, M. E. Locasto, S. W. Boyd, and A. D. Keromytis. Building A Reactive Immune System for Software Services. In Proceedings of the 11th USENIX Annual Technical Conference (to appear), April 2005.
A. Smirnov and T. Chiueh. DIRA: Automatic Detection, Identification, and Repair of Control-Hijacking Attacks. In The 12th Annual Network and Distributed System Security Symposium, February 2005.
M. Stamp. Risks of Monoculture. Communications of the ACM, 47(3): 120, March 2004.
【００８４】
G. E. Suh, J. W. Lee, D. Zhang, and S. Devadas. Secure program execution via dynamic information flow tracking. SIGOPS Oper. Syst. Rev., 38(5): 85-96, 2004.
T. Toth and C. Kruegel. Accurate Buffer Overflow Detection via Abstract Payload Execution. In Proceedings of the 5th Symposium on Recent Advances in Intrusion Detection (RAID), October 2002.
N. Wang, M. Fertig, and S. Patel. Y-Branches: When You Come to a Fork in the Road, Take It. In Proceedings of the 12th International Conference on Parallel Architectures and Compilation Techniques, September 2003.
J. A. Whittaker. No Clear Answers on Monoculture Issues. IEEE Security & Privacy, 1(6): 18-19, November/December 2003.
J. Yin, J.-P. Martin, A. Venkataramani, L. Alvisi, and M. Dahlin. Separating Agreement from Execution for Byzantine Fault Tolerant Services. In Proceedings of ACM SOSP, October 2003.
【図面の簡単な説明】
【００８５】
【図１】本発明のある実施形態に基づき、他のアプリケーションを監視し、それらアプリケーションを欠陥に対して保護するアプリケーションを実施するのに適したシステムを示す概略図である。
【図２】本発明のある実施形態に基づき使用できる図１のサーバー及び１つのワークステーションを詳細に示す図である。
【図３】本発明のある実施形態に基づき、アプリケーションの欠陥を修理しそしてアプリケーションを更新するところを示す簡単なフローチャートである。
【図４】本発明のある実施形態に基づき、欠陥の発生に応答してアプリケーションを検出し修理するところを示す簡単なフローチャートである。
【図５】本発明のある実施形態に基づき、既存のアプリケーションのコードに一体化されるエミュレートされたコードを示す図である。
【図６】本発明のある実施形態に基づき、アプリケーションコミュニティを使用してアプリケーションを検出し修理するところを示す簡単なフローチャートである。
【図７】本発明のある実施形態に基づき、分散型入札に対してアプリケーションコミュニティのメンバーにより計算できるテーブルを例示する図である。
【図１】
2008547070.tif 000011
【図２】
2008547070.tif 000012
【図３】
2008547070.tif 000013
【図４】
2008547070.tif 000014
【図５】
2008547070.tif 000015
【図６】
2008547070.tif 000016
【図７】
2008547070.tif 000017
【手続補正書】
【提出日】平成20年2月6日(2008.2.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソフトウェア故障からアプリケーションを修理するための方法において、
複数の装置を含むアプリケーションコミュニティを定義するステップと、
アプリケーションの部分を前記複数の装置の各々に指定するステップと、
前記複数の装置の１つが故障を検出したという指示を受け取るステップと、
前記複数の装置の１つが故障を検出したという指示を受け取るのに応答して、前記アプリケーションコミュニティにその故障を通知するステップと、
を備えた方法。
【請求項２】
前記指定するステップは、更に、前記複数の装置の各々における利用可能なメモリの量に基づいて前記複数の装置の各々に前記アプリケーションの部分を指定することを含む、請求項１に記載の方法。
【請求項３】
前記指定するステップは、更に、前記アプリケーションコミュニティの合計ワークロードに基づいて前記複数の装置の各々に前記アプリケーションの部分を指定することを含む、請求項１に記載の方法。
【請求項４】
前記指定するステップは、更に、前記複数の装置の各々に前記アプリケーションの部分を任意に指定することを含む、請求項１に記載の方法。
【請求項５】
前記指定するステップは、更に、各装置が他の装置と駆け引きすることによりそのワークロードを調整することを許す、請求項１に記載の方法。
【請求項６】
プロセッサにより実行されたときに、プロセッサが、ソフトウェア故障からアプリケーションを修理するための方法であって、
複数の装置を含むアプリケーションコミュニティを定義するステップと、
アプリケーションの部分を前記複数の装置の各々に指定するステップと、
前記複数の装置の１つが故障を検出したという指示を受け取るステップと、
前記複数の装置の１つが故障を検出したという指示を受け取るのに応答して、前記アプリケーションコミュニティにその故障を通知するステップと、
を備えた方法を遂行するようにさせるコンピュータ実行可能なインストラクションを含むコンピュータ読み取り可能なメディア。
【請求項７】
前記指定するステップは、更に、前記複数の装置の各々における利用可能なメモリの量に基づいて前記複数の装置の各々に前記アプリケーションの部分を指定することを含む、請求項６に記載のコンピュータ読み取り可能なメディア。
【請求項８】
前記指定するステップは、更に、各装置が他の装置との駆け引きによりそのワークロードを調整することを許す、請求項６に記載のコンピュータ読み取り可能なメディア。
【請求項９】
前記指定するステップは、更に、前記複数の装置の各々に前記アプリケーションの部分を任意に指定することを含む、請求項６に記載のコンピュータ読み取り可能なメディア。
【請求項１０】
前記指定するステップは、更に、各装置が他の装置との駆け引きによりそのワークロードを調整することを許す、請求項６に記載のコンピュータ読み取り可能なメディア。
【請求項１１】
ソフトウェア故障からアプリケーションを修理するためのアプリケーションコミュニティにおいて、
ネットワークを通して互いに通信する複数の装置を備え、
前記複数の装置の各々に前記アプリケーションの部分が指定され、
前記複数の装置のうちの特定の装置が、その特定の装置に指定されたアプリケーションの部分に故障を検出するのに応答して、その特定の装置が前記複数の装置に故障を通知するようにしたアプリケーションコミュニティ。
【請求項１２】
コードを含むアプリケーションをソフトウェア故障から修理するための方法において、
複数の装置を含むアプリケーションコミュニティを定義するステップと、
監視すべき故障を前記複数の装置の各々に指定するステップと、
前記複数の装置の１つが指定の故障を検出したという指示を受け取るステップと、
前記複数の装置の１つが指定の故障を検出したという指示を受け取るのに応答して、前記アプリケーションコミュニティにその故障を通知するステップと、
を備えた方法。
【請求項１３】
前記指定するステップは、更に、前記複数の装置の各々における利用可能なメモリの量に基づいて前記複数の装置の各々に前記監視すべき故障を指定することを含む、請求項１２に記載の方法。
【請求項１４】
前記指定するステップは、更に、前記アプリケーションコミュニティの合計ワークロードに基づいて前記複数の装置の各々に前記監視すべき故障を指定することを含む、請求項１２に記載の方法。
【請求項１５】
前記指定するステップは、更に、前記複数の装置の各々に前記監視すべき故障を任意に指定することを含む、請求項１２に記載の方法。
【請求項１６】
前記指定するステップは、更に、各装置が他の装置との駆け引きによりそのワークロードを調整することを許す、請求項１２に記載の方法。
【請求項１７】
プロセッサにより実行されたときに、プロセッサが、コードを含むアプリケーションをソフトウェア故障から修理するための方法であって、
複数の装置を含むアプリケーションコミュニティを定義するステップと、
監視すべき故障を前記複数の装置の各々に指定するステップと、
前記複数の装置の１つが指定の故障を検出したという指示を受け取るステップと、
前記複数の装置の１つが指定の故障を検出したという指示を受け取るのに応答して、前記アプリケーションコミュニティにその故障を通知するステップと、
を備えた方法を遂行するようにさせるコンピュータ実行可能なインストラクションを含むコンピュータ読み取り可能なメディア。
【請求項１８】
前記指定するステップは、更に、前記複数の装置の各々における利用可能なメモリの量に基づいて前記複数の装置の各々に前記監視すべき故障を指定することを含む、請求項１７に記載のコンピュータ読み取り可能なメディア。
【請求項１９】
前記指定するステップは、更に、前記アプリケーションコミュニティの合計ワークロードに基づいて前記複数の装置の各々に前記監視すべき故障を指定することを含む、請求項１７に記載のコンピュータ読み取り可能なメディア。
【請求項２０】
前記指定するステップは、更に、前記複数の装置の各々に前記監視すべき故障を任意に指定することを含む、請求項１７に記載のコンピュータ読み取り可能なメディア。
【請求項２１】
前記指定するステップは、更に、各装置が他の装置との駆け引きによりそのワークロードを調整することを許す、請求項１７に記載のコンピュータ読み取り可能なメディア。
【請求項２２】
ソフトウェア故障からアプリケーションを修理するためのアプリケーションコミュニティにおいて、
ネットワークを通して互いに通信する複数の装置を備え、
前記複数の装置の各々に監視すべき故障が指定され、
前記複数の装置のうちの特定の装置が、その特定の装置に指定された故障を検出するのに応答して、その特定の装置が前記複数の装置に故障を通知するようにしたアプリケーションコミュニティ。