(57)【要約】配備されるネットワークデバイス（４、６、８、１０、１２、１４、１６）をアップグレードするシステム（図１）。これらのデバイスは、アップグレードプログラムを実行するサーバ（２２）を識別し、このサーバと通信することのできるインストールされたエージェントによって使用可能になる。適切な条件が満たされた場合、サーバはアップグレードをエージェントにダウンロードし、エージェントはこのアップグレードを展開されるデバイスにインストールする。デバイスは、アップグレードが利用可能であるか否かを確認するためにサーバにポーリングすることができるようになっており、あるいは、サーバがデバイスを探し出してデバイスの状態を照会し、適切な所定の条件が満たされた場合にアップグレードをデバイスにダウンロードすることができる。
2004534973.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークコンピュータ環境下にある配備されたデバイスをアップグレードする方法であって、
ａ）ネットワークサーバをポーリングする機能を前記配備されたデバイスに追加するステップと、
ｂ）前記ネットワークサーバをポーリングし、前記配備されたデバイスに対してアップグレードが有効であるか否かを判断するステップと、
ｃ）前記アップグレードが適切な条件を満たした場合、前記アップグレードを前記配備されたデバイスにダウンロードするステップと、
を含む、前記方法。
【請求項２】
前記アップグレードが適切なサーバからのものであることと、前記アップグレード自体が送信中に変更されていないことを認証し、確認するステップを更に含む、請求項１に記載の方法。
【請求項３】
前記アップグレードが、前記配備されたデバイスの１以上の特定のコンポーネントに適用される、請求項１に記載の方法。
【請求項４】
前記配備されたデバイスの前記特定のコンポーネントが、前記コンポーネントの名、バージョン、前記アップグレードを提供する前記サーバのホスト名、前記アップグレードを提供する前記サーバへの要求のためのポート番号、行われる再試行の試みの数、ポーリングスケジュール、再試行期間によって識別され、定義される、請求項３に記載の方法。
【請求項５】
前記ネットワークサーバは前記アップグレードを制御するアップグレードポリシーを含み、前記ポリシーはどの配備されたデバイスが前記アップグレードの受信に適切であるかを定義する、請求項１に記載の方法。
【請求項６】
前記ネットワークサーバの前記ポーリングが所定の基準でスケジュールされることを更に含む、請求項１に記載の方法。
【請求項７】
ネットワークコンピュータ環境下にある配備されたデバイスをアップグレードする方法であって、
ａ）ネットワークサーバによって接触され、前記ネットワークサーバからアップグレードを受信する機能を前記配備されたデバイスに追加するステップと、
ｂ）前記ネットワークサーバが、前記配備されたデバイスに対して適切なアップグレードが有効であるか否かを判断し、前記アップグレードを前記配備されたデバイスに送信するステップと、
を含む、前記方法。
【請求項８】
ネットワークコンピュータ環境下にある配備されたデバイスにアップグレードを実施するシステムであって、
ａ）前記配備されたデバイスに追加されるエージェントであって、アップグレードが前記配備されたデバイスに対して有効であるか否かを判断するためにネットワークサーバにポーリングする機能を含む、該エージェントと、
ｂ）前記アップグレードのための所定の基準がほぼ適合した場合に前記アップグレードを前記配備されたデバイスに送信するようにされた前記ネットワークサーバと、
を含む、前記システム。
【請求項９】
前記アップグレードが適切な前記ネットワークサーバからのものであることと、前記アップグレード自体が前記配備されたデバイスへの送信中に変更されていないことを認証して確認する、前記配備されたデバイスの機能を更に含む、請求項８に記載のシステム。
【請求項１０】
前記アップグレードを、前記配備されたデバイスの１以上の特定のコンポーネントに適用することができる、請求項８に記載のシステム。
【請求項１１】
前記配備されたデバイスの前記特定のコンポーネントが、前記コンポーネントの名、バージョン、前記アップグレードを提供する前記サーバのホスト名、前記アップグレードを提供する前記サーバへの要求のためのポート番号、行われる再試行の試みの数、ポーリングスケジュール、再試行期間によって識別され、定義される、請求項１０に記載のシステム。
【請求項１２】
前記ネットワークサーバは前記アップグレードの送信前に所定のアップグレードポリシーを適用し、前記アップグレードポリシーはどの特定の配備されたデバイスが前記アップグレードの受信に適切であるかをを識別し、定義する、請求項８に記載のシステム。
【請求項１３】
前記ポーリングが所定間隔で生じる、請求項８に記載のシステム。
【請求項１４】
ネットワークコンピュータ環境下にある配備されたデバイスにアップグレードを実施するシステムであって、
ａ）アップグレードが前記配備されたデバイスに対して有効であるか否かを判断するためにネットワークサーバにポーリングする機能を前記配備されたデバイスに追加する手段と、
ｂ）前記アップグレードのための所定の基準がほぼ適合した場合に、前記ネットワークサーバが前記アップグレードを前記配備されたデバイスに送信できるようにする手段と、
を含む、前記システム。
【請求項１５】
ａ）前記アップグレードが適切な前記ネットワークサーバからのものであることを認証し確認するための、前記配備されたデバイスのための手段と、
ｂ）前記アップグレード自体が前記配備されたデバイスへの送信中に変更されていないことを保証する手段と、
を更に含む、請求項１４に記載のシステム。
【請求項１６】
前記配備されたデバイスをアップグレードする前記手段が、前記配備されたデバイスの１以上の特定のコンポーネントに前記アップグレードを適用する機能を含む、請求項１４に記載のシステム。
【請求項１７】
アップグレードされる１以上の前記特定のコンポーネントが、前記アップグレードを受信してインストールするエージェントを含む、請求項１６に記載のシステム。
【請求項１８】
ネットワークコンピュータ環境下にある配備されたデバイスにアップグレードを実施するシステムであって、
ａ）ネットワークサーバからアップグレード通知を受信する、配備されたデバイス手段と、
ｂ）前記アップグレードのための所定の基準がほぼ適合した場合に、前記アップグレードを前記配備されたデバイスに送信するネットワークサーバ手段と、
を含む、前記システム。
【請求項１９】
前記配備されたデバイスが前記アップグレードの受信に適切であることを判断するネットワークサーバ手段を更に含む、請求項１８に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は展開されるコンピューティングシステムの分野に関し、より詳細にはこれらのシステムのアップグレードに関する。
【０００２】
本願には、出願日２０００年４月４日の仮出願番号６０／１９７，１２５に基づいた権利が与えられている。
【０００３】
【発明が解決しようとする課題及び課題を解決するための手段】
ネットワークデバイスの製造者及びオペレータは、これらのデバイス、特に遠隔に位置するデバイスを自動的にアップグレードする包括的な解決法を必要としている。これらのアップグレードは、新しい機能、信頼性の向上、性能の向上、更新されたアプリケーション、更新されたアプリケーションデータ、セキュリティのパッチ、及びバグ修正を、展開されるデバイスに提供する。本発明は、遠隔デバイスを手動でアップグレードするというエンドカスタマの負担を取り除き、費用のかかるサポート訪問や製品の回収にかかる製造者の経費を低減する。本発明は、製造者のサポートコストを下げ、信頼性、より向上した管理容易性、及び所有にかかるコストの削減に対してますます高まるカスタマの期待に応えることにより、展開されるデバイスの製造者に、他に負けない強力な利点を提供する。本発明は、ターゲットデバイスに組み込まれるデバイス固有エージェントの構成に用いられる開発環境、アップグレードの生成及び発行を行うサーバコンピュータ、及び固有のエージェントソフトウェアそのもの、といった３つの部分から構成される。
【０００４】
本発明はアップグレードにデバイス開始アプローチを取り入れているため、サーバによって開始されるアップグレードにより生じる多くの欠点が取り除かれる。
【０００５】
本発明によってサーバを無状態にすることができる。無状態サーバは、展開されるデバイスとのこれまでの対話を記録する必要がない。従って、サーバは、アップグレードされたデバイスや、そのデバイスがアップグレードされた時期の検出及び追跡を行う必要がない。これは、デバイスが要求を行うため、不要な通信又は記録されていない通信を取り除くネットワークファイアウォールに関しては問題はない、ということも意味する。アップグレードが中断された場合、展開されるデバイスはアップグレード要求を再度行い、中断が生じたところから続ける。
【０００６】
ターゲットデバイスのセットに対してアップグレードを利用可能にするために、デバイスの製造者はアップグレードモジュールを作成する。アップグレードモジュールは、アップグレードイメージと、認証及びデータ検証に使用される機密保護鍵からなる。また、アップグレードモジュールは、アップグレードの配布を管理するように製造者が定義するポリシーを含む。本開示内容の全体にわたり、製造者という用語は、遠隔でアップグレードすることのできる展開されるデバイスの製造を望む者を意味するように用いられる。アップグレード原則は、どのデバイスがアップグレードの受信を認可されているかを制御する。これらの原則は、ホスト名、スケジュール、又は所望のロールアウト速度など、特定の基準に基づいたものでありうる。例えば、これらの原則を製造者のサポート原則と併せて使用し、アップグレードを望むエンドカスタマのみにアップグレードを提供することができる。
【０００７】
アップグレード処理は安全で信頼性が高く、再始動可能である。この処理は、業界規格のＴＣＰ／ＩＰ及びＨＴＴＰプロトコルを用いる。デバイスは、展開されるデバイスに予めプログラムされている、特別に指定されたＵＲＬ、ポート、及び機密保護鍵を用いて、アップグレードサーバに要求を始める。サーバは、機密保護鍵を検証し、サーバにある有効なアップグレードモジュールとこの要求を照合し、アップグレードモジュールに関して定義された原則を用いて要求を有効にすることにより、この要求を処理する。要求が有効になった場合、サーバは、有効なアップグレードが利用可能であることをデバイスに通知する。デバイスは次にダウンロードを開始し、イメージの保全性を検証し、ＮＩＳＴデジタル署名規格（ＤＳＳ）を用いてソースを認証する。ダウンロードが順調に行われた後、デバイスは、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ又は実行可能プロセスによって定義されるデバイス固有メカニズムを用いて適宜アップグレードを実施し、肯定応答をサーバに送信する。
【０００８】
エージェントの生成及びパッケージ化のために、ソフトウェアは機密保護鍵の生成を始める。これらの鍵はサーバに転送され、アップグレードの発行処理に用いられる。次にエージェント自体が生成され、デバイス内に展開される。エージェントは、アップグレードコンポーネント、公開鍵、構成情報、及び任意の組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを含む。アップグレードコンポーネントは、例えばプリンタドライバのような、ターゲットデバイスのアップグレード可能なエンティティを表し、そのエンティティのアップグレード構成を定義する。エージェントは展開されるデバイスの各々に含まれ、デバイスが新しいアップグレードを自動的に見出してこれをダウンロードすることを可能にする。標準ファイル転送手順を用いた、これらのファイルのターゲットデバイスへの移動により、エージェントを構成するファイルを展開させる。オペレーティングシステムが任意の態様で提供するファイル又はバイナリの実行により、展開が完了する。通常、デバイス起動の際にこれらのファイルを実行するが、スケジューラ又は手動要求によって展開させることもできる。次に、組込エージェントを用いるデバイスに対して利用可能となるアップグレードモジュールを生成する。そして、モジュールをサーバ上に発行する。展開されるデバイスからの要求が生じると、サーバはアップグレードをデバイスに転送する。そして、組込デバイスエージェントはこのアップグレードを実施する。
【０００９】
アップグレードに使用されるサーバはウェブサーバに類似しており、同じ態様で展開される。サーバは、展開されるデバイスからＨＴＴＰベースのアップグレード要求を受信し、ＴＣＰ／ＩＰネットワークによってこれらのデバイスにアクセスすることができるようになる。インターネット、イントラネット、ＶＰＮ（バーチャルプライベートネットワーク）、又はダイヤルアップ接続によって接続することができる。
【００１０】
展開されるデバイスにおいてＪａｖａ（Ｒ）Ｓｃｒｉｐｔの組込サブセットを使用することにより、ファイルのサイズを最小にすることができる。使用される組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔの関数は、算術演算子、論理演算子、大域関数、局所変数及び大域変数、並びに「ｉｆ」、「ｅｌｓｅ」、「ｆｏｒ」、及び「ｒｅｔｕｒｎ」キーワードを含む。サポートされていない組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ関数は、浮動小数点の数、アレイ、オブジェクト、及び関数宣言である。組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔサブセットは、一般的なスクリプト機能と、組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ関数の呼出を計算量の多いＣ関数に結びつけるメカニズムとを提供する。あらゆるスクリプト言語と同様に、主な利点の１つは、展開が速く容易であり、サイクルコンパイル及びリンクが不要なことにある。欠点としては、スクリプトはソースの形で展開されるためにプライバシーが欠如していることと、近年の発達によりコードの実行はより速くなってはいるが、コンパイルされたコードよりも実行が遅いこと、が挙げられる。使用される組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔサブセットは、実行するエージェントが作動する間はアクティブである大域変数を有する。従って、これは、スクリプトの寿命よりも長く存在する。「Ｃ」言語で書かれたアプリケーションは、これらの変数を宣言し、設定することができる。次に、これらの変数は、エンジンによって評価される任意のスクリプトによってアクセス可能となる。これにより、データを１つのスクリプトから他のスクリプトに渡すことができる。組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔサブセットは「Ｃ」関数を宣言することができ、次いでこれらの関数を、エンジンによって解釈することのできる任意の組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔサブセットによって使用することができる。このことは、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ言語に関連する通常のセキュリティを侵害するが、これにより、展開されるデバイスで実行するアプリケーションは、コンパイルされた「Ｃ」の全ての利点を備える任意の動作を定義し、実行することができる。また、この結合メカニズムにより、アプリケーションは「ｌｏａｄＭｏｄｕｌｅ」などの関数を拡張することもできる。これらの関数の多くは、パスされるパラメータの数に基づいた異なる実行をもたらすように多重定義されている。使用される組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔはタイプが規定されていない言語であるため、パラメータの数は、生じるべき動作を決定する唯一の基準である。アップグレード処理を実施するために、多数の関数が、アップグレードエージェントと共に含まれるＪａｖａ（Ｒ）Ｓｃｒｉｐｔインタプリタに追加されている。アップグレードエージェント又はサーバによって使用される任意のＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを用いて、これらの関数を使用することができる。全てのＪａｖａ（Ｒ）Ｓｃｒｉｐｔ変数は、ストリングとして記憶される。従って、これらの関数は全て、ストリング値をスクリプトに戻す。用いられる「Ｃ」関数を、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔサブセット又は実行される処理によって呼び出すことができる。これらの関数により、開発者は、アップグレードエージェントの構成能力及び機能性を高めることができる。Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔサブセットは、ｃａｌｌＦｕｎｃｔｉｏｎ  Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ ＡＰＩの使用により、又は後述するようなａｄｄＪｓＦｕｎｃを用いた新しいＪａｖａ（Ｒ）Ｓｃｒｉｐｔ ＡＰＩへの関数の結合により、「Ｃ」関数のロード及び呼出を行うことができる。下記の関数の多くは、文字「ｇ」で始まる標準のシステムＡＰＩである。一般に、アップグレードエージェントのインメモリファイルシステム機能が使用されていない場合、これらのＡＰＩは標準のシステム呼出に変換される。インメモリファイルシステムが使用されている場合、これらのシステムはインメモリの同等の関数に変換され、この関数において、「ｇ」は「ｉｍ」に置き換えられ、標準名の最初の文字が大文字にされる。
【００１１】
本発明は、ネットワークサーバをポーリングする機能をネットワークコンピュータ環境において展開されるデバイスに追加し、このデバイスに対してアップグレードが利用可能か否かを判断することにより、展開されるデバイスをアップグレードするシステム及び方法を記載している。サーバにおいて展開されるデバイスに適したアップグレードが見出された場合、そのアップグレードがダウンロードされ、インストールされる。また、この方法は、アップグレードが適切なサーバからのものであり、更新自体が送信中に変更されていないことを認証し、確認する必要性も考慮している。展開されるデバイスには、多数の異なるソフトウェアコンポーネントをインストールすることができる。サーバは、変化を要するコンポーネントのみをアップグレードすることができる。他の特性のなかでも、名、バージョン、アップグレードを提供するサーバのホスト名、アップデートを提供するサーバに要求を行うためのポートナンバー、ポーリングスケジュール、再試行期間、及び行われる再試行の試みの数により、展開されるデバイスに存在するコンポーネントを識別することができる。また、ネットワークサーバは、なかでも、どのアップグレードをどのデバイスにインストールするかを決定するためにサーバによって守られるべき多数の原則を含むこともできる。展開されるデバイスがサーバをポーリングするのではなく、展開されるデバイスに対してアップグレードを押し進める際も、展開されるデバイスにアップグレードを提供する当該方法を用いることができる。展開されるデバイスは、サーバを用いて自身を登録することができ、適切な条件が満たされた場合、サーバは適切でありうるあらゆる全てのダウンロードを時宜を得て開始する。
【００１２】
本発明の他の目的及び他の利点は、添付の図面を参照し、下記の詳細な説明を読むにつれて明らかになるであろう。
【００１３】
【発明の実施の形態】
構造及び動作
本発明は、製造者が遠隔デバイスを簡潔かつ安全にアップグレードすることのできるソフトウェアの組である。これは、標準ウェブプロトコルであるＨＴＴＰ１．１を用いるクライアント／サーバモデルを使用する。
【００１４】
図１に示されるように、本発明は、標準のウェブブラウザからインターネット２０及びサーバファイアウォール１８を介して要求を受信する標準のウェブサーバ２２と全く同じように動作する。このサーバを、中央サイトに配置されるウェブサーバと考え、インストールされたデバイスエージェント２をブラウザとして考えてみる。時折、ウェブブラウザはウェブサーバからデータを要求し、ウェブサーバは要求されたデータをブラウザに送り返すことによってこれに応答する。同様に、エージェントはスケジュールされた時間にサーバからデータを要求し、サーバは要求されたデータを送り返すことによってこれに応答する。展開されるデバイスとしては、モニタ４、他のサーバ６、プリンタ８、コピー機１０、携帯電話１２、ＰＤＡ１４、又はコンパクトＰＣＩを用いたシステムもしくはあらゆる他の相互接続システム１６、といった多数の物が挙げられる。
【００１５】
本質的に、サーバは、アップグレードが発行される中央に配置されたサーバであり、エージェントは、デバイスに組み込まれ、アップグレードの際にサーバをポーリングし、アップグレードが利用可能である際にアップグレードを要求するソフトウェアコンポーネントである。本発明はアップグレードにデバイス開始アプローチを用いており、このアプローチはサーバ開始アプローチに比べて多くの利点を有する。これらの利点は、下記を含む。
【００１６】
１．サーバはシンプルで無状態である。サーバは複雑な構成を必要とせず、移動したりネットワークに時折しか接続されない可能性のある複数の遠隔エージェントを検出して追跡する必要がない。
２．アップグレードはファイアウォールを通過することができる。
３．アップグレードは、中断した場合でも再始動できる。エージェントは各アップグレードにおける更新箇所を追跡し、中断後は更新が中断された箇所から続ける。
４．サーバは、ウェブサーバが同時接続された多くのブラウザをサポートするのと同じようにして、多数のデバイスをサポートすることができる。
【００１７】
複製やロード平衡のような標準の技術を用いて、この解決法を、何百万のデバイスをサポートするように拡張させることができる。
【００１８】
アップグレードモジュール発行及びポーリング
サーバとエージェントとの間の通信は、発行／ポーリングモデルに基づいている。このモデルを、本発明の各コンポーネントの果たす役割と併せて後述する。
【００１９】
他の実施の形態では、サーバはエージェントのＵＲＬアドレスを用いてエージェントと接触し、アップグレードをエージェントに「押し進める」ことができる。
【００２０】
エージェントは、デバイス上で連続的に作動する小さなソフトウェアである。その主な機能は、アップグレード情報のためにサーバをポーリングすることと、アップグレードが利用可能である場合にアップグレードを取り込んでデバイスに適用することである。また、エージェントは、アップグレードが、認可されたサーバからのものであり、その内容が送信の際に改ざんされなかったことを確実にすることによって、アップグレードを安全に行わなくてはならない。エージェントは、アップグレードモジュールに含まれるデジタル署名によってアップグレードの認証及び確認を行うことにより、これを達成する。
【００２１】
エージェントは、多くのアップグレード可能なエンティティをサポートすることができる。例えば、エージェントがプリンタ上で作動している場合、プリンタのＴＣＰ／ＩＰスタックと、そのＰｏｓｔＳｃｒｉｐｔ（Ｒ）エンジンをアップグレードすることが必要になりうる。更に、これらのエンティティの各々のアップグレードは、異なるサーバによってもたらされる場合がある。
【００２２】
エージェントは、アップグレードコンポーネントの概念を介してこれらの機能を処理する。前述のプリンタの例では、ＴＣＰ／ＩＰスタックは１つのコンポーネントであり、ＰｏｓｔＳｃｒｉｐｔ（Ｒ）エンジンは他のコンポーネントである。アップグレードコンポーネントは、ユーザ構成モジュールにおいて定義されており、エージェントの一部としてパッケージ化されている。アップグレードコンポーネントは、下記の情報を用いて定義される。
・名
・バージョン
・このコンポーネントにアップグレードを提供するサーバのホスト名又はアドレス
・このサーバに要求を行うためのポート番号
・ポーリングスケジュール、再試行期間、及び試みる再試行数
【００２３】
アップグレードコンポーネントが定義されると、アップグレードコンポーネントはターゲットデバイスの特定のプラットフォーム用のエージェントと共にパッケージ化される。
【００２４】
サーバの主な機能は、システム管理者又は他のサポートスタッフが遠隔のエージェントからのアップグレード要求に応答する一方で新しいアップグレードを発行し、既存のアップグレードの進行を監視できるようにすることである。
【００２５】
アップグレードを発行するために、管理者は、実際のアップグレード（アップグレードペイロード）と、構成及び原則の情報とを構成するファイルを指定する。アップグレード原則により、システム管理者は、どのターゲットデバイスが特定のアップグレードを受信するのか又は受信しないのかを指定することでアップグレードロールアウトを制御することができる。そして、ペイロードがこの情報及びデジタル署名と組み合わされて、アップグレードモジュールが生成される。デジタル署名は、サーバを認証してアップグレードデータの保全性を確認するためにエージェントによって使用される。
【００２６】
アップグレードモジュールの構成情報の一部は、アップグレードがサポートをするアップグレードコンポーネントである。前述のように、アップグレードコンポーネントはユーザ構成モジュールにおいて定義されており、エージェントアプリケーションの一部としてパッケージ化されている。エージェントは、コンポーネントをサポートする発行されたアップグレードモジュールの有無をサーバにポーリングする。利用可能なものがある場合、エージェントはそれを要求する。他の実施の形態では、サーバはエージェントにアップグレードを「促す」。
【００２７】
プリンタの例を使い続けると、ネットワーク上の全てのプリンタのＴＣＰ／ＩＰスタックをバージョン６．０からバージョン６．５にアップグレードするタスクがシステム管理者に課されていると仮定する。プリンタは、スタック用のアップグレードコンポーネントでエージェントを実行する。このコンポーネントは「ｔｃｐｉｐ」という名であり、バージョンは１．０であると仮定する。
【００２８】
アップグレードを達成するために、システム管理者はサーバを用いてアップグレードモジュールを生成する。管理者は、「ｔｃｐｉｐ」コンポーネントのバージョン１．０用であることを示す名と記述をモジュールに与え、（アップグレード後の）このコンポーネントの新バージョンを２．０に設定し、アップグレードペイロードを指定する。また、システム管理者は、アップグレード原則を適用し、ＩＰアドレス、ホスト名、比率（例えば、２つ毎に１つ）、又はスケジュールによってアップグレードのロールアウトを制御してもよい。あるいは、システム管理者は更なる制御のためにＪａｖａ（Ｒ）Ｓｃｒｉｐｔ原則を適用してもよい。最後に、システム管理者はモジュールを有効にし、これでモジュールが「発行された」ことになる。
【００２９】
次に、プリンタ内のエージェントは、「ｔｃｐｉｐ」コンポーネントのバージョン１．０に対してアップグレードが利用可能であるか否かを見出すためにサーバにポーリングをする。アップグレードが利用可能であることをエージェントが確認すると、エージェントはアップグレードを要求し、これをプリンタに適用する。アップグレードが完了すると、プリンタはＴＣＰ／ＩＰスタックのバージョン６．５を実行し、「ｔｃｐｉｐ」コンポーネントのバージョンを２．０にする。
【００３０】
エージェントの実行
一般的なエージェント実行ステップを以下に列挙する。
【００３１】
１．デバイスの起動時に始動させる。
２．ｕｐｃｏｎｆｉｇ．ｔｘｔファイルを解析する。
３．セキュリティが有効な場合、セキュリティライブラリをロードする。
４．Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが有効な場合、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔライブラリをロードする。
５．開発者の任意のＪａｖａ（Ｒ）Ｓｃｒｉｐｔを実行する。
−エージェントの任意の構成のためにｃｏｎｆｉｇ．ｊｓを実行する。
−ブロードキャスティングを有効にする場合、ｂｃａｓｔ．ｊｓを実行し、ブロードキャストパケットの一部として返答を送り、これに対する応答があればそれを読み取る。エージェントによる応答待ち時間は、エージェントのメインプログラム（ｍａｉｎ．ｃ）において設定される。
−ｓｔａｒｔｕｐ．ｊｓを実行し、アップグレード処理にわたり任意のユーザ入力制御を行う。
−エージェントは完全に構成され、アップグレードを処理できる状態にある。
６．全てのコンポーネントに対するアップグレード開始時を計算する。
７．下記のループを実行する。
−次のアップグレード時まで休止する。
−休止状態から出てアップグレードを実行する。
−Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが有効な場合、アップグレード要求時にｒｅｑｄａｔａ．ｊｓを実行し、チャンクの受信時にｐｒｏｇｒｅｓｓ．ｊｓを実行する。
−アップグレードペイロードの受信後、アップグレードを適用するために、アップグレードにて受信したアップグレード実行可能物及び／又はｕｐｇｒａｄｅ．ｊｓを実行する。
−次の更新時を計算し、それに応じてアップグレードのスケジュールを変更する。
−任意のＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルｆｉｎｉｓｈ．ｊｓを実行する。
８．終了
−Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが有効な場合、ｅｘｉｔ．ｊｓを実行する。
【００３２】
アップグレード処理
ここでは、アップグレード処理に含まれるステップを示す。この処理は、特定のアップグレードコンポーネントに対してアップグレードを行う時期であるとエージェントが判断した場合に開始する。特定のコンポーネントのアップグレードスケジュールは、コンポーネントがユーザ構成モジュールにおいて初めて生成された際に、又はその実行時に定義される。
【００３３】
図２は、下記のステップの概略を述べている。
１．エージェントは任意のｒｅｑｄａｔａ．ｊｓを実行し、ＨＴＴＰ要求を起こす。
２．エージェントは要求をサーバに送信する。
３．サーバは応答する。
４．エージェントはアップグレードを取り込む。
５．エージェントはオリジナルファイルを再度作成する。
６．エージェントはセキュリティチェックを行う。
７．エージェントはオリジナルファイルをアーカイブから出す。
８．エージェントはアップグレード実行可能物を実行する。
９．エージェントは任意のｕｐｇｒａｄｅ．ｊｓを実行する。
１０．エージェントはアップグレードを完了し、サーバに通知する。
１１．エージェントは任意のｆｉｎｉｓｈ．ｊｓを実行する。
【００３４】
１．エージェントはコンポーネントの適切なＨＴＴＰ要求を起こす。
要求がどのように形成されるかは、ｕｐｃｏｎｆｉｇ．ｔｘｔのコンポーネント当たりのｓｅｒｖｅｒＮａｍｅ、ｓｅｒｖｅｒＰｏｒｔ、及びｓｅｒｖｅｒＦｏｒｍパラメータと、エージェントのプロキシ構成パラメータとに依存する。
【００３５】
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが有効で、任意のＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルｒｅｑｄａｔａ．ｊｓがその生成時にエージェントアプリケーションの一部としてパッケージされている場合、エージェントはＪａｖａ（Ｒ）Ｓｃｒｉｐｔを呼び出し、その結果を、コンポーネントの現在のバージョンを含む他の重要な情報と共に要求に追加する。
【００３６】
２．エージェントは要求を適切なサーバに送る。
要求が失敗した場合、エージェントは、ｕｐｃｏｎｆｉｇ．ｔｘｔのコンポーネント当たりのｒｅｔｒｙＰｅｒｉｏｄ及びｒｅｔｒｙＡｔｔｅｍｐｔｓパラメータに基づいて再試行する。
【００３７】
３．サーバは応答する。
応答は、利用可能なアップグレードがないことを示す場合がある。その場合、エージェントは、他のコンポーネントのアップグレードであり得る次のアップグレードの生成がスケジュールされるまで休止する。
【００３８】
応答は、アップグレードが利用可能であることを示す場合がある。その場合、サーバは、アップグレードの内容が配置される場所、アップグレードを構成するチャンクの数、検査合計のリストなどを指定する情報をエージェントに送り返す。
【００３９】
４．エージェントはアップグレードを取り込む。
エージェントは、１度に１チャンクずつアップグレードを取り込み、各チャンクを適切な検査合計と比較する。ファイルが改ざんされていた場合、エージェントはそれらを再度取り込む。
【００４０】
５．エージェントは、オリジナルアーカイブファイルを再度作成する。
エージェントが全てのチャンクを取り込むと、エージェントはそれらを結合してオリジナルアーカイブファイルを再度作成する。
【００４１】
６．エージェントはセキュリティチェックを行う。
目録ファイルは常に、受信されたペイロードの一部であり、ペイロードのためのデジタル署名を含む。署名は、ペイロードデータと、ユーザ構成モジュールにおいて生成されサーバにインポートされる秘密鍵及び公開機密保護鍵とに依存している。
【００４２】
エージェントは署名を確認し、この署名が有効である場合、アップグレードが適切なサーバから来たものであり、データの改ざんや破損が送信中に生じなかったことが保証される。
【００４３】
７．エージェントは、オリジナルの構成ファイルをアーカイブから取り出す。
次に、このファイルをアーカイブから取り出し、オリジナル構成ファイル（アップグレードのペイロード）を生成する。
【００４４】
８．エージェントはアップグレード実行可能ファイルを実行する。
アップグレード実行可能ファイルがペイロードに含まれている場合、エージェントはこれを実行する。ＶｘＷｏｒｋｓ（Ｒ）では、ファイルはｕｐｇｒａｄｅ．ｏと呼ばれる必要がある。Ｗｉｎｄｏｗｓ（Ｒ） ＮＴでは、このファイルはｕｐｇｒａｄｅ．ｅｘｅと呼ばれる必要がある。Ｌｉｎｕｘ（Ｒ）では、このファイルはｕｐｇｒａｄｅと呼ばれる必要がある。エージェントは、実行可能ファイルが首尾よく終了するまではアップグレードを実行しない。
【００４５】
９．エージェントは任意のｕｐｇｒａｄｅ．ｊｓファイルを実行する。
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔをエージェントに対して有効にし、ｕｐｇｒａｄｅ．ｊｓファイルがペイロードに含まれる場合、エージェントはこのファイルを実行する。エージェントは、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが首尾よく終了するまではアップグレードを実行しない。
【００４６】
注：ステップ８及びステップ９は、アップグレードが適用される態様を制御するように、コンポーネント固有の動作をエージェントに対して行うために使用することのできるメカニズムである。これらの動作は、古いファイルをアップグレードペイロードからの新しいものに置き換えるなど、非常に簡潔であることが多い。しかし、これらの動作は、アップグレードを適用する前にデバイスのユーザから認可を要求するなど、はるかに複雑なものになりうる。
【００４７】
１０．エージェントはアップグレード処理を完了する。
エージェントは、処理中に生成された一時的なファイルを全て除去し、コンポーネントのバージョンを新しいバージョンに変更し、アップグレードが首尾よく行われたことを示す応答をサーバに送信する。
【００４８】
１１．エージェントは任意のｆｉｎｉｓｈ．ｊｓファイルを実行する。
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔを有効にし、ｆｉｎｉｓｈ．ｊｓファイルがエージェントのｊｓディレクトリに存在する場合、エージェントはこのファイルを実行する。ｆｉｎｉｓｈ．ｊｓファイルは、ユーザ構成モジュール内に生成される際にエージェントアプリケーションと共にパッケージされる。
【００４９】
優先順位の考慮
エージェントは、ＣＰＵの使用に対するインパクトが小さくなるように設計されている。各アップグレード処理は、非常に効率的なコードを使用するほか、多くの小さなセグメントに分割され、ＣＰＵのリソースは各々のセグメント間に解放される。このアプローチは、他のタスクが同時に作動している場合に、エージェントがＣＰＵの大部分を使用することを防ぐ。（ｕｐｃｏｎｆｉｇ．ｔｘｔファイル内のユーザ構成モジュールによって設定される）ｃｈｕｎｋＰａｕｓｅ及び細分性パラメータの設定により、この動作の制御がある程度もたらされる。
【００５０】
しかしながら、タスクの一部にはＣＰＵを集中的に用いるものがある。アップグレードペイロードのチャンクが受信されると、エージェントは、これらのチャンクを結合し、ペイロードの目録及び署名を確認し、ペイロードファイルをアーカイブから取り出す。ペイロードが非常に大きい場合、このことにより数秒間でかなりの量のＣＰＵリソースを使用しうる。リソースの占有を避けるため、エージェントは、これらのタスクの間はその実行優先順位を下げる。
【００５１】
各オペレーティングシステムによって用いられる優先順位スキームは異なっている。以下では、エージェントが各オペレーティングシステムにおいてその優先順位を設定する態様を説明する。
【００５２】
Ｗｉｎｄｏｗｓ（Ｒ） ９５／９８／ＮＴ
Ｗｉｎｄｏｗｓ（Ｒ）は、実行優先順位のクラスの集合を定義している。エージェントは、ＮＯＲＭＡＬ＿ＰＲＩＯＲＩＴＹ＿ＣＬＡＳＳ処理として開始されることが期待される。ＣＰＵを集中的に用いるタスクの間、エージェントは、ＩＤＬＥ＿ＰＲＩＯＲＩＴＹ＿ＣＬＡＳＳ処理として実行するように自身を再設定する。ＣＰＵを集中的に用いるタスクが完了すると、エージェントは自身を再設定してＮＯＲＭＡＬ＿ＰＲＩＯＲＩＴＹ＿ＣＬＡＳＳに戻す。
【００５３】
ＶｘＷｏｒｋｓ（Ｒ）
ＶｘＷｏｒｋｓ（Ｒ）タスクは０乃至２５５の優先レベルで実行し、０が最も好適である。エージェントが実行する優先順位は、エージェントを立ち上げるｔａｓｋＳｐａｗｎ呼出において、ユーザにより定義される。ＣＰＵを集中的に用いるタスクに達すると、エージェントは、その優先順位を、始動時の優先順位と２５５の中間になるように設定する。ＣＰＵを集中的に用いるタスクが完了すると、エージェントはその優先順位を始動時のレベルに再設定する。
【００５４】
ＬＩＮＵＸ（Ｒ）
Ｌｉｎｕｘ（Ｒ）処理は−２０乃至＋２０の（微細な）優先レベルで実行し、−２０が最も好適で０（ゼロ）が普通である。Ｌｉｎｕｘ（Ｒ）スーパーユーザによって所有される処理のみが、その優先順位をより好適な設定値に調節することができる。従って、エージェントの処理がスーパーユーザによって所有されない限り、優先順位の調節は行われない。追跡ファイルは、優先順位を変更できなかったことを示す。スーパーユーザが所有者である場合、ＣＰＵを集中的に用いるタスクに達するとエージェントはその優先順位をレベル１０に再設定する。ＣＰＵを集中的に用いるタスクが完了すると、エージェントはその優先順位を始動時のレベルに再設定する。
【００５５】
Ｗｉｎｄｏｗｓ（Ｒ） ＣＥ
Ｗｉｎｄｏｗｓ（Ｒ） ＣＥは、優先順位を個々の実行スレッドとして処理する。前述のＷｉｎｄｏｗｓ（Ｒ） ９５／９８／ＮＴと同様に、エージェントは、ＣＰＵを集中的に用いるタスクの実行の際に、その優先順位を更に低いクラスに再設定する。
【００５６】
エージェントの構成及び制御
エージェントは、高構造化が可能なソフトウェアコンポーネントである。このセクションでは、エージェントのカスタム構成及び制御を行うために開発者が利用できる種々のメカニズムを説明する。
【００５７】
一般に、エージェントはデバイスの起動時に始動し、デバイスの電源がオフにされるまで作動する。エージェントは起動時に構成情報を取得し、その構成によって定義されるようにアップグレードを行う。
【００５８】
エージェントには、次の３つの構成情報ソースがある。
・エージェントのローカルファイルシステムに記憶されたｕｐｃｏｎｆｉｇ．ｔｘｔファイル
・エージェントのブロードキャスト要求に対するサーバの応答
・エージェントのローカルファイルシステムに記憶され、及び／又はアップグレードのペイロードの一部としてサーバからダウンロードされた任意の組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイル
【００５９】
エージェントファイルの構造
エージェントの構成及び動作をカスタマイズする態様を十分に理解するためには、開発者はそのファイル構造に精通していなければならない。開発者は、デフォルトファイルが位置する場所や、任意のファイルを配置する必要のある場所を知っていなくてはならない。
【００６０】
トップディレクトリ
ファイル構造のトップディレクトリは、下記のファイルを含む。
・デバイスのオペレーティングシステムに既にリンクされていない場合は、エージェントの実行可能なイメージ
・エージェントのデフォルト構成ファイルｕｐｃｏｎｆｉｇ．ｔｘｔ
・組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ共用ライブラリ
・ＤＳＳセキュリティ共用ライブラリ
【００６１】
コンポーネントディレクトリ
コンポーネントディレクトリは、ダウンロードされたファイルを記憶するためにエージェントによって用いられる一時的なディレクトリである。このディレクトリは、各アップグレードの後に空にされる。ペイロードファイルの存続が必要である場合、ｕｐｒａｄｅ．ｊｓファイルを用いてこれらのファイルを他のディレクトリに移動させる。
【００６２】
ｊｓディレクトリ
エージェントの構成及び動作をカスタマイズするための組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔの実施を開発者が望んでいるか否かに応じて、ｊｓディレクトリは、任意のＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを記憶するために使用される。
【００６３】
親ディレクトリは、エージェントの構成及び動作を総括して制御する大域Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを含んでいる。これらのファイルは、ｃｏｎｆｉｇ．ｊｓ、ｂｃａｓｔ．ｊｓ、ｓｔａｒｔｕｐ．ｊｓ、ｆｉｎｉｓｈ．ｊｓ、及びｅｘｉｔ．ｊｓである。
【００６４】
エージェントの個々のアップグレードコンポーネントの構成を制御するコンポーネント当たりのＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを、ｊｓディレクトリの個々のサブディレクトリに記憶する必要がある。サブディレクトリを各コンポーネント毎に生成する必要があり、サブディレクトリはコンポーネントと同じ名をもたなくてはならない。例えば、「ｔｃｐｉｐ」という名のコンポーネントを構成及び制御するためのＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルは、．．．／ｊｓ／ｔｃｐｉｐ／ｓｕｂ−ｄｉｒｅｃｔｏｒｙに配置されなければならない。２つの可能なコンポーネント当たりのＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルには、ｒｅｑｄａｔａ．ｊｓ及びｐｒｏｇｒｅｓｓ．ｊｓという名をつけなくてはならない。
【００６５】
ｕｐｃｏｎｆｉｇ．ｔｘｔファイル
エージェントの構成情報の主要ソースは、エージェントのローカルファイルシステムのトップディレクトリに位置するｕｐｃｏｎｆｉｇ．ｔｘｔファイルである。エージェントが起動すると、エージェントはｕｐｃｏｎｆｉｇ．ｔｘｔファイルを解析し、それに応じて構成される。ファイルの内容は、アップグレードコンポーネント及びエージェントアプリケーションの生成の際に、ユーザ構成モジュールにおいて定義される。
【００６６】
ｕｐｃｏｎｆｉｇ．ｔｘｔファイルは、大域及びコンポーネント当たりといった２種の構成情報を定義する。大域構成パラメータは、全体としてのエージェントアプリケーションに関するものであり、コンポーネント当たりのパラメータは１つのエージェントコンポーネントに関するものである。
【００６７】
ｕｐｃｏｎｆｉｇ．ｔｘｔファイルは、各構成パラメータの毎にキーワード＝値の対からなるプレーンなＡＳＣＩＩテキストファイルであり、各キーワード＝値の対はファイルの単一ラインを占めている。キーワードは大文字と小文字を区別したものである。
【００６８】
キーワード＝値の対の第１のセットは大域パラメータからなり、後続のセットはエージェントのコンポーネントのためのパラメータからなる。
【００６９】
ｕｐｃｏｎｆｉｇ．ｔｘｔファイルの例
ｐｒｏｘｙｓｅｒｖｅｒ＝
ｐｒｏｘｙＰｏｒｔ＝０
ｂｒｏａｄｃａｓｔ＝８０
ｓｅｃｕｒｉｔｙ＝１
ｊａｖａｓｃｒｉｐｔ＝１
ｒａｎｄｏｍｉｚｅ＝０
ｃｈｕｎｋＰａｕｓｅ＝１０
ｇｒａｎｕｌａｒｉｔｙ＝１
ＩｎＭｅｍＣａｐａｃｉｔｙ＝２００００００
ｃｏｍｐｏｎｅｎｔ＝Ｃｏｍｐｏｎｅｎｔ１
ｖｅｒｓｉｏｎ＝１．０
ｔｈｅ  ｓｅｒｖｅｒＮａｍｅ＝ｍｙ．ｔｈｅ  ｓｅｒｖｅｒ．ｃｏｍ
ｔｈｅ  ｓｅｒｖｅｒＦｏｒｍ＝／ｇｏｆｏｒｍ／ｕｐｇｒａｄｅ
ｔｈｅ  ｓｅｒｖｅｒＰｏｒｔ＝３０５７
ｓｃｈｅｄｕｌｅ＝＊９−１７＊＊１−５
ｐｅｒｉｏｄ＝８６４００
ｒｅｔｒｙＰｅｒｉｏｄ＝６０
ｒｅｔｒｙＡｔｔｅｍｐｔｓ＝５
ｅｎａｂｌｅ＝１
ｃｏｍｐｏｎｅｎｔ＝Ｃｏｍｐｏｎｅｎｔ２
ｖｅｒｓｉｏｎ＝３．０
ｔｈｅ  ｓｅｒｖｅｒＮａｍｅ＝ｃｕｓｔｏｍｅｒ．ｔｈｅ  ｓｅｒｖｅｒ．ｃｏｍ
ｔｈｅ  ｓｅｒｖｅｒＦｏｒｍ＝／ｇｏｆｏｒｍ／ｕｐｇｒａｄｅ
ｔｈｅ  ｓｅｒｖｅｒＰｏｒｔ＝３０５７
ｓｃｈｅｄｕｌｅ＝＊＊１＊＊
ｐｅｒｉｏｄ＝２４１９２００
ｒｅｔｒｙＰｅｒｉｏｄ＝６０
ｒｅｔｒｙＡｔｔｅｍｐｔｓ＝１０
ｅｎａｂｌｅ＝０
【００７０】
大域構成
表１は、ｕｐｃｏｎｆｉｇ．ｔｘｔの大域構成パラメータを列挙したものである。以下のセクションは、各パラメータに関する更なる情報を提供する。
【００７１】
【表１】
2004534973.tif 000003
【００７２】
ｐｒｏｘｙ  ｓｅｒｖｅｒ
このパラメータは、プロキシサーバのＩＰアドレスを指定する。サーバは、このエージェントと接続するために作動し続ける。サーバがプロキシサーバを介して作動する場合はフィールドを定義する必要があり、定義をしない場合はパラメータをブランクにすべきである。
【００７３】
ｐｒｏｘｙＰｏｒｔ
プロキシサーバが定義される場合、このパラメータはプロキシサーバのポート番号を指定しなくてはならない。プロキシサーバが定義されない場合、このパラメータを０に設定すべきである。
【００７４】
ｂｒｏａｄｃａｓｔ
ｂｒｏａｄｃａｓｔパラメータは、エージェントがブロードキャストパケットをサーバに送信するために用いなければならないサーバポートを指定する。このサーバに対してブロードキャスティングを有効にしない場合、パラメータを０に設定しなくてはならない。ブロードキャスティングの更なる情報に関しては、「ｂｃａｓｔ．ｊｓ及びｂｒｏａｄｃａｓｔ．ｊｓを介するブロードキャスティング」を参照のこと。
【００７５】
ｓｅｃｕｒｉｔｙ
このパラメータは、このエージェントに対してセキュリティを有効にするか否かを定義する。パラメータを１に設定すると、セキュリティが有効になる。パラメータを０に設定すると、セキュリティが無効になる。
【００７６】
ｊａｖａｓｃｒｉｐｔ
このパラメータは、このエージェントに対してＪａｖａ（Ｒ）Ｓｃｒｉｐｔを有効にするか否かを定義する。パラメータを１に設定すると、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが有効になる。パラメータを０に設定すると、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔが無効になる。
【００７７】
ｒａｎｄｏｍｉｚｅ
このパラメータは、多くのエージェントが全く同時にアップグレードを行うのを防ぐのに有用である。ｒａｎｄｏｍｉｚｅは、アップグレードの開始時を期間に関連して変更する。また、ｒａｎｄｏｍｉｚｅは、ｃｈｕｎｋＰａｕｓｅが有効である場合、アップグレードの際にチャンク間の休止に影響を及ぼす。パラメータを１に設定すると、ランダム化が有効になる。パラメータを０に設定すると、ランダム化が無効になる。
【００７８】
注：エージェントを用いる際、エージェントは一般に、割り当てられたタイムウィンドウにおいてランダム時にアップグレードを要求する（「コンポーネント当たりの構成」を参照）。しかしながら、開発者は、エージェントをテストする間はこの機能を無効にしてもよい。
【００７９】
ｃｈｕｎｋＰａｕｓｅ
エージェントは、アップグレードの各チャンクを受信した後、アップグレード速度及びシステムのロードを制御することができるように特定の時間量の間休止することができる。ｃｈｕｎｋＰａｕｓｅはその時間量を秒単位で指定し、エージェントは次のチャンクを取り込む前に待機する。ｃｈｕｎｋＰａｕｓｅを０に設定すると、エージェントはチャンク間で休止しない。ｃｈｕｎｋＰａｕｓｅ及びｒａｎｄｏｍｉｚｅの双方を有効にすると、チャンク間の休止は、ｃｈｕｎｋＰａｕｓｅに対して指定された時間量まで変化する。
【００８０】
注：エージェントが初めて（又は再起動後に）始動する際、エージェントはｃｈｕｎｋＰａｕｓｅに対して指定された時間量の間待機し、その後で最初のアップグレード要求を行う。
【００８１】
ｇｒａｎｕｌａｒｉｔｙ
ｃｈｕｎｋＰａｕｓｅと同様に、ｇｒａｎｕｌａｒｉｔｙは、説明されているこのシステムがデバイスのＣＰＵに課すロードの制御を行えるように意図されたものである。目下実行されているアップグレードがない場合、このパラメータはスケジュールの細分性（ｇｒａｎｕｌａｒｉｔｙ）を指定する。例えば、３０に設定されている場合、エージェントは３０秒間休止し、コンポーネントのアップグレードを要求したり他の事象を進める時であるかを確認する。そのような時でない場合、エージェントは更に３０秒間休止し、スケジュールの再確認などを行う。デフォルト値は５秒である。Ｗｉｎｄｏｗｓ（Ｒ） ＮＴのエージェントでは、このｇｒａｎｕｌａｒｉｔｙは、エージェントがＳｙｓｔｅｍ  Ｔｒａｙアイコンを介するユーザ入力を確認する頻度も指定する。ｇｒａｎｕｌａｒｉｔｙが大きすぎると、ユーザがアイコンをマウスでクリックした際のユーザへの応答が非常に遅くなる可能性がある。
【００８２】
ＩｎＭｅｍＣａｐａｃｉｔｙ
このパラメータは、インメモリファイルシステム用のオペレーティングシステムから割り当てられるバイト単位のメモリ量を指定するのに用いられる。
【００８３】
コンポーネント当たりの構成
各エージェントは複数のアップグレードコンポーネントをサポートすることができ、各コンポーネントは別個の構成可能エンティティである。ｕｐｃｏｎｆｉｇ．ｔｘｔファイルにおけるコンポーネントの構成パラメータの先頭には、コンポーネントのコンポーネントパラメータがある。コンポーネントパラメータの後に列挙されるパラメータは、新しいコンポーネントパラメータが列挙されるまで、全てそのコンポーネントに関連している。表２は、ｕｐｃｏｎｆｉｇ．ｔｘｔファイルのコンポーネント当たりのパラメータを列挙している。以下のセクションは、各パラメータに関する情報を提供する。
【表２】
2004534973.tif 000004
【００８４】
ｃｏｍｐｏｎｅｎｔ
ｃｏｍｐｏｎｅｎｔパラメータは、アップグレードコンポーネントの名を定義する。各コンポーネント名は、固有のストリングでなければならない、即ち、いかなるスペースも含んではならない。例えば、「ｍｙｃｏｍｐｏｎｅｎｔ」は許容できるが、「ｍｙ  ｃｏｍｐｏｎｅｎｔ」は許容できない。
【００８５】
ｖｅｒｓｉｏｎ
ｖｅｒｓｉｏｎパラメータは、アップグレードコンポーネントのバージョンを定義する。コンポーネントのバージョンのフォーマットは、ｘ．ｙ．ｚ．ｂである必要がある（ここで、ｘ、ｙ、ｚ、及びｂはバージョンセグメント数である）。バージョン数は、少なくとも１つで４以下のセグメントをもたなくてはならず、各セグメントは、少なくとも１で４以下の桁をもたなくてはならない。セグメントは、ピリオドによって分離されていなくてはならない。
【００８６】
コンポーネントのバージョンは、コンポーネントが自身の適切なバージョンを用いてのみアップグレードされることを確実にするために用いられる。アップグレードモジュールがサーバにおいて生成されると、そのモジュールを適用するコンポーネントと、コンポーネントの適用可能バージョンが指定される。アップグレードの完了後にコンポーネントがロールするバージョンも指定される。エージェントがサーバからコンポーネントのアップグレードを要求する際、エージェントはコンポーネントの現在のバージョンを認識しており、そのバージョンに適用するアップグレードのみを要求する。アップグレードが完了すると、コンポーネントのバージョンはアップグレードによって指定された新しいものにロールし、これにより、コンポーネントが新しくなったバージョンに適用可能なアップグレードのみを受信することを確実にする。
【００８７】
ｔｈｅ  ｓｅｒｖｅｒＮａｍｅ
ｔｈｅ  ｓｅｒｖｅｒＮａｍｅパラメータは、このアップグレードコンポーネントのためのアップグレードを発行するサーバのＩＰアドレス又はホスト名を定義する。このパラメータの値は、アップグレードについて問い合わせてアップグレードを取り込むためにエージェントがＨＴＴＰ  ＧＥＴコマンドを送信するＵＲＬを構成する３つの部分のうちの第１の部分である。
【００８８】
ｔｈｅ  ｓｅｒｖｅｒＰｏｒｔ
ｔｈｅ  ｓｅｒｖｅｒＰｏｒｔパラメータは、ｓｅｒｖｅｒＮａｍｅによって指定されるサーバに要求を行う際にエージェントによって使用されるポート番号を定義する。このパラメータの値は、アップグレードについて問い合わせてアップグレードを取り込むためにエージェントがＨＴＴＰ  ＧＥＴコマンドを送信するＵＲＬの第２の部分である。
【００８９】
ｔｈｅ  ｓｅｒｖｅｒＦｏｒｍ
ｔｈｅ  ｓｅｒｖｅｒＦｏｒｍパラメータの値は、アップグレードについて問い合わせてアップグレードを取り込むためにエージェントがＨＴＴＰ  ＧＥＴコマンドを送信するＵＲＬの第３の部分である。このパラメータは、「／ｇｏｆｏｒｍ／ｕｐｇｒａｄｅ」でなくてはならず、変更してはならない。
【００９０】
ｓｃｈｅｄｕｌｅ及びｐｅｒｉｏｄ
ｓｃｈｅｄｕｌｅ及びｐｅｒｉｏｄは組み合わせて動作し、これによりアップグレードの開始時に正確な制御を行うことができる。（詳細は下記のセクションを参照のこと。）アップグレードを完了するのに要する時間は、ペイロードのサイズ、及びエージェントとサーバとの間の接続の速度に依存する。
【００９１】
注：スケジュールされた時間の間にアップグレードが完了しない場合は、そのアップグレードが中止されたところから次のアップグレードを開始する。
【００９２】
ｓｃｈｅｄｕｌｅ
ｓｃｈｅｄｕｌｅは、コンポーネントがアップグレードされるタイムウィンドウを定義する。ｓｃｈｅｄｕｌｅの構文はクロン（ｃｒｏｎ）のような仕様に従っており、Ｕｎｉｘ（Ｒ）クロンによって用いられるものと同一である。しかし、その意味は多少異なっている。Ｕｎｉｘ（Ｒ）クロンでは、仕様は事象が生じる時間を定義している。本発明では、仕様はアップグレードが生じる時間のウィンドウを定義している。
【００９３】
ｓｃｈｅｄｕｌｅの構文は、スペース又はタブ文字（例えば、＊＊１＊＊）によって分離される５つのフィールドから構成された単一のラインを含む。フィールドは、下記とすることができる。
・整数
・整数の範囲――範囲内の小さい値と大きい値との間にハイフン（−）を配置する（例えば、９−１５）ことによって整数の範囲を指定する
・整数のリスト――整数のリストを示すには、例えば１，３，５，８のようにコンマで分離されたリストを使用する
・アステリスク文字（＊）――アステリスクは、フィールド内の全ての有効値を表す。
【００９４】
表３は、５つのｓｃｈｅｄｕｌｅフィールドの各々に対して可能な値を概説している。
【００９５】
【表３】
2004534973.tif 000005
【００９６】
ｐｅｒｉｏｄ
ｐｅｒｉｏｄは、ｓｃｈｅｄｕｌｅによって指定されたタイムウィンドウの間の、アップグレードが完了してから（特定のコンポーネントに対して）他のアップグレードが要求されるまでに待機する時間の量を定義する。ｐｅｒｉｏｄのフォーマットは、秒単位の時間である。例えば、ｐｅｒｉｏｄが８６４００に設定された場合、ｐｅｒｉｏｄは１日である。
【００９７】
注：ｐｅｒｉｏｄは、ｒａｎｄｏｍｉｚｅ大域構成パラメータによって変更される。ｒａｎｄｏｍｉｚｅが０に設定されて無効になると、エージェントは期間の開始時にコンポーネントをアップグレードしようとする。ｒａｎｄｏｍｉｚｅが１に設定されて有効になると、エージェントは期間の中でランダムに選択された時間にコンポーネントをアップグレードしようとする。
【００９８】
例
ｓｃｈｅｄｕｌｅ及びｐｅｒｉｏｄが一緒に動作する態様をより良く理解することを促すため、以下にいくつかの例を挙げる。
【００９９】
・月曜日から金曜日、午前９時から午後５時までの標準的な勤務時間の間、ほぼ１時間毎にアップグレードを行うためには、下記のｓｃｈｅｄｕｌｅの仕様を用い、ｐｅｒｉｏｄを３６００秒に設定する。
＊９−１７＊＊１−５
【０１００】
・同一のタイムウィンドウの間であるが、ほぼ３０分毎に前述の処理を実行するためには、単にｐｅｒｉｏｄを１８００秒に変更する。
【０１０１】
・毎日毎時間、正時の５分前と正時の５分後との間に１回アップグレードを実行するためには、６００秒のｐｅｒｉｏｄを指定し、下記の仕様を用いる。
５４−５９  ０−４＊＊＊＊
【０１０２】
・毎月１日の任意の時間にアップグレードするためには、ｐｅｒｉｏｄを８６４００（秒単位で１日に相当する）に設定すべきであり、ｓｃｈｅｄｕｌｅには下記の仕様を用いる。
＊＊１＊＊
【０１０３】
ｒｅｔｒｙＰｅｒｉｏｄ
ｒｅｔｒｙＰｅｒｉｏｄパラメータは、失敗の後でこのコンポーネントに対するアップグレードの再要求を試みる前に、エージェントが待機する秒単位の時間量を指定する。このパラメータは一般に短期間で設定される。ｒｅｔｒｙＰｅｒｉｏｄは、ｓｃｈｅｄｕｌｅ及びｐｅｒｉｏｄパラメータよりも優先される。従って、再試行の試みは正常にスケジュールされたアップグレード期間外で生じうる。
【０１０４】
ｒｅｔｒｙＡｔｔｅｍｐｔｓ
ｒｅｔｒｙＡｔｔｅｍｐｔｓパラメータは、失敗の後、エージェントがこのコンポーネントに対するアップグレードの要求を試みる最大回数を指定する。エージェントが最大再試行数に達した場合、エージェントはアップグレード処理を停止し、次にスケジュールされたアップグレードのために待機する。
【０１０５】
ｅｎａｂｌｅ
ｅｎａｂｌｅパラメータは、コンポーネントをアップグレードのために有効にするか否かを判断する。１に設定すると、コンポーネントは有効になる。０に設定すると、コンポーネントは無効になり、パラメータが１に設定されるまでアップグレードされない。
【０１０６】
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイル
必要に応じて、エージェントを、ｃｏｎｆｉｇ．ｊｓ、ｂｃａｓｔ．ｊｓ、ｓｔａｒｔｕｐ．ｊｓ、ｆｉｎｉｓｈ．ｊｓ、ｅｘｉｔ．ｊｓ、ｒｅｑｄａｔａ．ｊｓ、ｐｒｏｇｒｅｓｓ．ｊｓ、ｕｐｇｒａｄｅ．ｊｓ、及びｂｒｏａｄｃａｓｔ．ｊｓといった９つのカスタム組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを介して構成し、制御することができる。エージェントがユーザ構成モジュールにおいて生成された際にエージェントにおいてＪａｖａ（Ｒ）Ｓｃｒｉｐｔを有効にした場合、これらのファイルは一定の時点でエージェントによって自動的に呼び出される。（ｂｒｏａｄｃａｓｔ．ｊｓはこの場合は例外である。表４を参照のこと。）特に、これらのＪａｖａ（Ｒ）ＳｃｒｉｐｔファイルはＣ関数をロードして呼び出すことができるため、これらのＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルはエージェントの構成能力及び機能性を大幅に高める。
【０１０７】
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイルは、ｕｐｇｒａｄｅ．ｊｓを除いて、エージェントのローカルファイルシステムに記憶されなければならない。ｕｐｇｒａｄｅ．ｊｓは、アップグレード処理の間にサーバからエージェントにダウンロードされるように、アップグレードペイロードに含まれる必要がある。これらのファイルは全て、組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔパーサにより、エージェントにおいて局所的に解析される。
【０１０８】
表４はＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを列挙しており、これらのファイルが記憶される場所、呼び出される時期、そしてこれらのファイルがエージェント全体（大域）、特定のアップグレードコンポーネント（コンポーネント）、又は特定のアップグレード（アップグレード）に影響するか否かを示している。以下のセクションでは、更に詳細に説明される。
【０１０９】
【表４】
2004534973.tif 000006
【０１１０】
ｃｏｎｆｉｇ．ｊｓを介する構成
エージェントは、ｕｐｃｏｎｆｉｇ．ｔｘｔファイルの解析後、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイルｃｏｎｆｉｇ．ｊｓを呼び出す。ｃｏｎｆｉｇ．ｊｓファイルにより、開発者は、エージェントの構成を大幅に変えたり、組み込まれていない任意の初期化タスクを実行することができる。例えば、スクリプトは、構成情報をＬＤＡＰサーバから取得するＣコードをロードすることができる。次に、スクリプトはエージェントのＪａｖａ（Ｒ）Ｓｃｒｉｐｔ結合を呼び出して、構成を大幅に変えることができる。
【０１１１】
ｂｃａｓｔ．ｊｓ及びｂｒｏａｄｃａｓｔ．ｊｓを介するブロードキャスティング
ブロードキャスティングは、ローカルエリアネットワーク（ＬＡＮ）上のエージェント構成データを変える方法を提供し、サーバが１よりも多くあったりそれらのサーバを変更したい場合に有用になり得る。ブロードキャスティングは、本発明において実施されるように、ｂｃａｓｔ．ｊｓという名の任意のクライアント側ファイルと、ｂｒｏａｄｃａｓｔ．ｊｓという名の必須のサーバ側ファイル、といった２つの部分からなる。各ファイルに関する具体的な情報については、以下のセクションを参照のこと。
【０１１２】
ｂｃａｓｔ．ｊｓ
ｂｃａｓｔ．ｊｓにより、追加のエージェント固有データを、リスニングしているサーバに送信することができる。この任意のユーザ指定スクリプトは、生成時にエージェントと共にパッケージ化される。エージェントは、ブロードキャスト時間の間で、エージェントが十分に構成された後及びエージェントがＬＡＮを介してブロードキャストパケットを送信する前に、ｂｃａｓｔ．ｊｓを呼び出す。ブロードキャストパケットは、ＢＣＡＳＴ＿ＵＳＥＲＤＡＴＡ及びＢＣＡＳＴ＿ＩＰ＿ＡＤＤＲといった２つの変数からなる。ｂｃａｓｔ．ｊｓスクリプトの戻り値は、エージェントによってブロードキャストパケットに組み込まれる。サーバはこのデータを読み取り、サーバ上で実行するスクリプトがそのデータにアクセスするようにデータを変数ＢＣＡＳＴ＿ＵＳＥＲＤＡＴＡに入れる。また、ブロードキャストパケットは、変数ＢＣＡＳＴ＿ＩＰ＿ＡＤＤＲにおけるサーバスクリプトに対して利用可能であるブロードキャスティングエージェントのＩＰアドレスも含んでいる。
【０１１３】
注：ＢＣＡＳＴ＿ＵＳＥＲＤＡＴＡの値が設定されていない場合、エージェントはこの値を「なし」に設定する。
【０１１４】
応答を受信するために、ソケットを５秒間開いておく。この時間の間に応答が受信されない場合、ソケットを閉じ、エージェントは直ちに要求を繰り返す。応答が受信されるまで、このサイクルは永久に繰り返される。エージェント内の既存のコンポーネントは、ブロードキャスト応答が受信されるまでアップグレードされない。
【０１１５】
注：ｍａｉｎ．ｃにおけるブロードキャスト（）呼出を変えることにより、この動作を必要に応じて変更することができる。変更可能なパラメータは、要求回数、要求を繰り返す前の待機時間、及びリスニングのためにソケットを開けておく時間である。
【０１１６】
また、ｂｃａｓｔ．ｊｓは、例えば、追加の固有の構成情報をエージェントに送り返すために、ブロードキャストパケットの受信の際にサーバによって解析されるＪａｖａ（Ｒ）Ｓｃｒｉｐｔから構成することもできる（下記のｂｒｏａｄｃａｓｔ．ｊｓを参照）。
【０１１７】
ｂｒｏａｄｃａｓｔ．ｊｓ
サーバがブロードキャストパケットを受信すると、サーバはｂｒｏａｄｃａｓｔ．ｊｓという名のＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルを実行する。このファイルは必須である。ユーザはこのファイルを書き込み、このファイルは／ａｐｐｓ／ｃｏｍｐａｎｙｎａｍｅ／ｕｐｔｈｅｓｅｒｖｅｒ／ｊｓ／サーバディレクトリに記憶されなくてはならない。ｂｒｏａｄｃａｓｔ．ｊｓファイルは、ｂｃａｓｔ．ｊｓファイルを介して送信された変数ＢＣＡＳＴ＿ＵＳＥＲＤＡＴＡ及びＢＣＡＳＴ＿ＩＰ＿ＡＤＤＲＥＳＳにアクセスする。ｂｒｏａｄｃａｓｔ．ｊｓファイルが返送するものは何でも、ブロードキャストパケットを送信したエージェントに送り返される。下記は、ｂｒｏａｄｃａｓｔ．ｊｓファイルの内容の一例である。
ｒｅｔｕｒｎ（“ｃｏｍｐｏｎｅｎｔ＝ｔｅｓｔ
ｖｅｒｓｉｏｎ＝１．０．０
ｔｈｅ  ｓｅｒｖｅｒＮａｍｅ＝５７４．５２．４０．０１０“）
【０１１８】
注：構成情報及びバージョン情報に対する変更内容がエージェントの再始動後に上書きされることを望まない場合、ブロードキャストパケットがエージェントに送信されたら二度と送信されないようにｂｃａｓｔ．ｊｓ及びｂｒｏａｄｃａｓｔ．ｊｓに書き込むべきである。
【０１１９】
ｓｔａｒｔｕｐ．ｊｓ及びｆｉｎｉｓｈ．ｊｓを介するユーザ制御
ｓｔａｒｔｕｐ．ｊｓファイルは、ユーザ入力を提供するデバイスによる使用が意図されており、その目的は、ユーザがアップグレード処理を制御できるようにすることである。ｓｔａｒｔｕｐ．ｊｓは、ユーザがデフォルトのスケジューリングメカニズムを無効にできるように、デバイスのユーザインターフェースにアクセスすることができる。
【０１２０】
同様に、ｆｉｎｉｓｈ．ｊｓは、アップグレード処理に従ったユーザ制御を提供する。一般に、このスクリプトによってユーザはコンポーネントを有効にしたり無効にすることができる。スクリプトがこれらの動作を行う場合、関数ｓｔａｒｔＵｐｇｒａｄｅ及びｓｔｏｐＵｐｇｒａｄｅも必要に応じて呼び出すべきである。
【０１２１】
ｅｘｉｔ．ｊｓを介するクリーンアップ
ｅｘｉｔ．ｊｓファイルは、エージェントが実行を終了する直前に実行される。このファイルにより、開発者は必要に応じてクリーンアップ機能を実行することができる。
【０１２２】
ｒｅｑｄａｔａ．ｊｓを介する追加の要求データ
エージェントが適切なサーバから特定のコンポーネントのためのアップグレードを要求する前に、エージェントはコンポーネントのｒｅｑｄａｔａ．ｊｓファイルを呼び出す。これにより、開発者は、各要求と共に追加の情報をサーバに送信することができる。ｒｅｑｄａｔａ．ｊｓによって返送されたデータはサーバに渡され、サーバはこのデータを解析してＪａｖａ（Ｒ）Ｓｃｒｉｐｔ変数ＵＳＥＲＤＥＦＩＮＥＤに組み込む。この情報を、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔアップグレード原則などの処理のためにサーバ上のＪａｖａ（Ｒ）Ｓｃｒｉｐｔに渡すことができる（「Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔアップグレード原則」を参照）。
【０１２３】
注：ｒｅｑｄａｔａ．ｊｓファイルは特定のコンポーネントに適用されるため、このファイルを、コンポーネントと全く同名の．．．／ｊｓ／ディレクトリのサブディレクトリに記憶する必要がある。
【０１２４】
ｐｒｏｇｒｅｓｓ．ｊｓを介するチャンク受信制御
エージェントは、アップグレードの各チャンクを受信した後にコンポーネントのｐｒｏｇｒｅｓｓ．ｊｓファイルを実行する。これにより、開発者は、エージェントがコンポーネントのアップグレードをダウンロードする態様を細かく制御することができる。
【０１２５】
注：ｐｒｏｇｒｅｓｓ．ｊｓファイルは特定のコンポーネントに適用されるため、このファイルを、コンポーネントと全く同名の．．．／ｊｓ／ディレクトリのサブディレクトリに記憶する必要がある。
【０１２６】
ｕｐｇｒａｄｅ．ｊｓを介するアップグレードの適用
どのようにアップグレードが適用されるかを制御する固有のｕｐｇｒａｄｅ．ｊｓファイルを、アップグレードモジュールを介してエージェントに送信される各アップグレードペイロードに含めることができる。ｕｐｇｒａｄｅ．ｊｓファイルをペイロードに含めるには、ペイロードがサーバによりアップグレードモジュールの一部としてパッケージされる前に、ペイロードを他のペイロードと同一のディレクトリに配置しなくてはならない。エージェントによって受信されたペイロードがｕｐｇｒａｄｅ．ｊｓファイルを含む場合、ペイロードは、エージェントがそのペイロードを受信して有効にした直後にエージェントによって実行される。
【０１２７】
また、どのようにアップグレードが適用されるかを、アップグレードタスク又は処理の実行によって制御することもできる。Ｗｉｎｄｏｗｓ（Ｒ）プラットフォームでは、この実行可能物の名をｕｐｇｒａｄｅ．ｅｘｅとする必要がある。ＶｘＷｏｒｋｓ（Ｒ）では、その名をｕｐｇｒａｄｅ．ｏとしなくてはならない。Ｌｉｎｕｘ（Ｒ）では、その名をｕｐｇｒａｄｅとしなくてはならない。実行可能ファイルがペイロードに存在する場合、エージェントがペイロードを受信して有効にした後、エージェントによってそのファイルがロードされ、実行される。実行可能ファイル及びｕｐｇｒａｄｅ．ｊｓファイルの双方がペイロードに含まれている場合、まず実行可能ファイルが実行され、続いてｕｐｇｒａｄｅ．ｊｓが実行される。エージェントは、これらのファイルの一方又は双方の実行が完了するまでアップグレードを始めない。
【０１２８】
注：エージェントがＶｘＷｏｒｋｓ（Ｒ）システム上で作動する場合、ｕｐｇｒａｄｅ．ｏファイルはｕｐｍａｉｎという名の実行可能エントリポイントをもたなくてはならない。
【０１２９】
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔアップグレード原則
アップグレード原則は、サーバを実行するシステム管理者が、ターゲットデバイスのセットのどのサブセットがアップグレードを受信するかを指定することによってアップグレードのロールアウトを制御できるようにする、本発明の特徴である。原則がアップグレードに適用されると、エージェントからのアップグレードの要求が、それに応じてサーバにより是認されたり否認されたりする。アップグレード原則はサーバにおいて生成され、１つ以上のアップグレードモジュールに適用可能である。最も一般的なタイプの原則は以下の通りである。
・エージェントのＩＰアドレスによってアップグレードを制限するための「ＩＰアドレス」
・エージェントのホスト名によってアップグレードを制限するための「ホスト名」
・要求を行うエージェントのうち、ある割合のエージェントのみのアップグレードを是認するための「比率」
・指定された時間の間に行われた要求のみのアップグレードを是認するための「スケジュール」
【０１３０】
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ原則によって開発者は、上に列挙した４つのタイプの原則よりも更に正確にアップグレードのロールアウトを制御することができる。アップグレードモジュールに対してＪａｖａ（Ｒ）Ｓｃｒｉｐｔ原則を実施するには、開発者は「Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ」タイプのアップグレード原則をサーバに生成し、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔのパス名を原則タイプパラメータとして入力し、そしてＪａｖａ（Ｒ）Ｓｃｒｉｐｔ原則をアップグレードモジュールに適用する必要がある。保一貫性のために、開発者は、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ原則ファイルをｂｒｏａｄｃａｓｔ．ｊｓファイルと共に／ａｐｐｓ／ｃｏｍｐａｎｙ／ｕｐｔｈｅｓｅｒｖｅｒ／ｊｓ／サーバディレクトリに記憶することが賢明であろう。
【０１３１】
原則が満たされ、アップグレード要求が是認されるためには、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔファイルは「是認ａｐｐｒｏｖｅｄ」の値を戻さなくてはならない。Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ原則ファイルは、各アップグレード要求と共に送信されるエージェント変数にアクセスする。これらの変数は、ＨＯＳＴＮＡＭＥ、ＩＰ＿ＡＤＤＲ、ＣＯＭＰＯＮＥＮＴ、ＯＳ、ＶＥＲＳＩＯＮ、及びＵＳＥＲＤＥＦＩＮＥＤである。ＪａｖａＳｃｒｉｐｔファイルが所望の値を戻すために、開発者は、任意の論理をこれらのパラメータに適用することができる。
【０１３２】
注：ｒｅｔｕｒｎ（「ａｐｐｒｏｖｅｄ」）を挿入するだけで、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ原則ファイルはその原則を満たし、従ってアップグレードを是認する。
【０１３３】
セキュリティ
１９９８年１２月１５日、国立科学技術研究所（ｔｈｅ Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ、ＮＩＳＴ）は、連邦情報処理規格（ＦＩＰＳ）１８６−１としてデジタル署名規格（ＤＳＳ）を認定した。この規格は、ドキュメントにデジタル署名する技術を実施している。この規格は、下記の２つの要件を考慮に入れた上で本発明に適用されている。
【０１３４】
１．認証：データが信用のあるソースから来たものであることを確認し、「この  データは信用のあるソースと思われるものから来たものか」という質問に答える
２．確認：データの保全性を確認し、「このデータは送信中に改ざんされている  か」という質問に答える
【０１３５】
認証は、公開鍵及び秘密鍵といった一対の暗号化鍵を使用する非対称暗号化を介してＤＳＳによって達成される。これらの鍵は、下記の特性を有する。
・秘密鍵を公開鍵から推定することはできない。
・公開鍵は、秘密鍵を用いて符号化されたメッセージを復号することができる。
・公開鍵はメッセージを符号化することができない。
【０１３６】
アルゴリズムがメッセージ又はデータを符号化し、秘密鍵を用いてこれをデジタルで署名する。メッセージ又はデータの受信者はデジタル署名を読み取り、関連する公開鍵を用いてこのメッセージ又はデータの復号を試みる。受信者による復号がうまくいった場合、これは、メッセージ又はデータが、関連する秘密鍵へのアクセスを有するソース、従って信用のあるソースから来たものに違いない、ということを意味する。
【０１３７】
確認を達成するために、ＤＳＳはセキュアハッシュアルゴリズム（ＳＨＡ−１）を用いる。秘密鍵を用いたデジタル署名の生成の際、このアルゴリズムは、メッセージダイジェストと呼ばれるメッセージ又はデータの縮約版を取得する。このメッセージダイジェストは、デジタル署名アルゴリズムがデジタル署名を生成するとデジタル署名アルゴリズムに入力される。このデジタル署名は、データ又はメッセージと共に送信される。メッセージ又はデータの受信者がこれを受信すると、受信者はＳＨＡ１及びＤＳＳを用いて、実際のメッセージ又はデータに対してメッセージダイジェストを確認する。これらが適合しない場合、メッセージ又はデータは送信中に改ざんされている。
【０１３８】
本発明は、下記のようにＤＳＳを実施する。
【０１３９】
１．ユーザは、ユーザ構成モジュールを用いて暗号化鍵（公開及び秘密）の固有対を生成し、これをエクスポートする。
２．ユーザは、秘密鍵をサーバにインポートする。
３．公開鍵は、これらの鍵を生成したユーザ構成モジュールのコピーを用いて生成されたエージェントアプリケーションに含められる。
４．ユーザがアップグレードモジュールを生成すると、サーバは、インポートされた秘密鍵を用いてモジュールのアップグレードペイロードのためのデジタル署名を生成する。このデジタル署名は、セキュアハッシュアルゴリズム（ＳＨＡ−１）を用いて生成されたペイロードのダイジェストメッセージを含む。次に、サーバは、デジタル署名を含むペイロード用明示ファイルを生成する。そして、明示ファイル及びペイロードはアップグレードモジュールに組み込まれる。
５．エージェントがアップグレードモジュールを受信すると、エージェントはオリジナルのペイロード及び明示ファイルを複製する。
６．次に、エージェントは公開鍵を用いてデジタル署名を読み取り、実際のペイロードに対してダイジェストメッセージをチェックする。デジタル署名が認証され、データがダイジェストメッセージと一致する場合、エージェントはこのアップグレードを承認し、アップグレード処理を続ける。
【０１４０】
Ｗｉｎｄｏｗｓ（Ｒ） ＮＴサービスとしてのサーバの実行
サーバをインストールする際、サーバはＷｉｎｄｏｗｓ（Ｒ） ＮＴサービスとして自動的に登録される。Ｗｉｎｄｏｗｓ（Ｒ） ＮＴサービス管理プログラムから利用可能なオプションの他に、下記のコマンドラインのオプションを使用することができる。
−ｉ    サービスマネージャーを用いてサーバをＮＴサービスとして登録する。
−ｒ    サーバをＮＴサービス管理プログラムから除去する。
−ｓ    サーバが以前に登録されている場合はサーバをＮＴサービスとして始動させる（前述の−ｉを参照）。そうでない場合、サーバはこのオプションを用いた際に通常通りに作動する。
注：ＮＴサービス及びサービス管理プログラムの更なる情報に関しては、Ｗｉｎｄｏｗｓ（Ｒ） ＮＴドキュメンテーションを参照のこと。
【０１４１】
サーバログファイル
サーバは、サーバが追跡するエージェント及びサーバ動作に関する情報のログファイルを保持する。サーバはそのログファイルを回転させ、毎日午前０時にそのデータカウントをゼロにする。ログファイルの各セットは、／＜ｉｎｓｔａｌｌｄｉｒｅｃｔｏｒｙ＞／ａｐｐｓ／ｇｏａｈｅａｄ／ｕｐｔｈｅｓｅｒｖｅｒ／ｌｏｇ／に配置されたサブディレクトリに記憶されている。ログは、処理及び報告書作成のために表計算ツール又はデータベースツールにインポートすることのできる、タブで分離されたファイルとしてフォーマットされている。オリジナルファイルへの接続を維持することなくログファイル全体をＭｉｃｒｏｓｏｆｔ（Ｒ） Ｅｘｃｅｌにインポートしたり、ログファイルをＭｉｃｒｏｓｏｆｔ（Ｒ） Ｅｘｃｅｌのリフレッシュ可能範囲にインポートすることができる。更なる情報に関しては、Ｍｉｃｒｏｓｏｆｔ（Ｒ） Ｅｘｃｅｌヘルプを参照のこと。下記のログはサーバによって保持される。
【０１４２】
Ａｇｅｎｔｓログ
Ａｇｅｎｔｓログは、ログファイル日の午前０時以降サーバに要求を行った全てのエージェントと、各エージェントが行った要求の数のリストを提供する。Ａｇｅｎｔｓログは下記の項目を含む。
【０１４３】
【表５】
2004534973.tif 000007
【０１４４】
Ｒｅｑｕｅｓｔｓログ
Ｒｅｑｕｅｓｔｓログは、ログファイル日の午前０時以降サーバに対して行われたアップグレード要求を全て列挙する。Ｒｅｑｕｅｓｔｓログは下記の項目を含む。
【０１４５】
【表６】
2004534973.tif 000008
【０１４６】
Ｒｅｓｐｏｎｓｅｓログ
Ｒｅｓｐｏｎｓｅｓログは、ログファイル日の午前０時以降サーバによって受信されたエージェントからのアップグレード応答をすべて列挙する。エージェントは、アップグレードの是認がサーバから受信された場合のみに応答を送信する。Ｒｅｓｐｏｎｓｅｓログは下記の項目を含む。
【０１４７】
【表７】
2004534973.tif 000009
【０１４８】
ＶｘＷｏｒｋｓ（Ｒ）の考察
ＶｘＷｏｒｋｓ（Ｒ）ターゲットデバイス上で作動するエージェントは、ＴＣＰ／ＩＰ機能及びソケット機能のために標準ＶｘＷｏｒｋｓ（Ｒ）ネットワークサポートに依存する。ＮＦＳ、ＦＴＰ、及びＳＮＭＰは必須ではない。ＶｘＷｏｒｋｓ（Ｒ）ターゲットデバイスのエージェントは、標準ＶｘＷｏｒｋｓ（Ｒ） ＤＯＳファイルシステムサポートにも依存する。
【０１４９】
ユーザ構成モジュールにおいて生成されたエージェントファイルを、全てＶｘＷｏｒｋｓ（Ｒ）ターゲットデバイスに移動させなければならない。フロッピー（Ｒ）、ネットワーク、又はファイルをデバイスに配置するために用いられるあらゆる他の方法を介して、このことを行うことができる。このツリーをルートディレクトリに配置することができるが、ｇのような短いベース名を有するサブディレクトリに配置することが推奨される。
【０１５０】
ファイル名
本発明の適用に用いられるべきＶｘＷｏｒｋｓ（Ｒ）ファイルシステムのボリュームがＤＯＳ＿ＯＰＴ＿ＬＯＮＧＮＡＭＥＳオプションで初期化されていない限り、全てのファイル名及びディレクトリ名は、標準のＤＯＳの８文字の名及び３文字の拡張子に限定される。ユーザ構成モジュール及びサーバにおいて指定されるアップグレードコンポーネント名はファイルシステムのパス名に使用されるため、その長さは８文字以下でなくてはならない。
【０１５１】
スケジューリング
エージェントでは、作動前にシステムのリタルタイムクロックを初期設定し、機能しうるようにしておくことが必要である。特に、ｃｌｏｃｋ＿ｇｅｔｔｉｍｅ関数がエージェントによって呼び出され、事象のスケジューリングに使用される。
【０１５２】
エージェントは、標準のシステム呼出を有するファイルを生成する。これらのファイルが正確な日付／時間のスタンプを有するためには、時間フォーマッティング機能を備えるｄｏｓＦｓＤａｔｅ  ＴｉｍｅＩｎｓｔａｌｌ関数を使用して現在時刻をｄｏｓＦｓライブラリ関数に提供する必要がある。そうしない場合、全てのファイルが１９８０年１月１日の日付と００：００：００の時間で生成されてしまう。
【０１５３】
ファイルのローディング
エージェントオブジェクトモジュール（ｕｐｇｒａｄｅｒ．ｏ、ｅｊ．ｏ、及びｄｓｓ．ｏ）をＶｘＷｏｒｋｓ（Ｒ） ＯＳの画像にリンクし、起動時に初期設定を行うことができる。しかしながら、これらのモジュールを、ｔａｓｋＳｐａｗｎ  ＡＰＩのシェルコマンド又は呼出を介して任意の他の時間にロードし、初期設定を行うことができる。ｕｐｇｒａｄｅｒ．ｏのみがコマンドｅｊ．ｏによってロードされる必要があり、ｄｓｓ．ｏはｕｐｇｒａｄｅｒ．ｏにより、又はｕｐｃｏｎｆｉｇ．ｔｘｔの構成パラメータ次第で、必要に応じてロードされる。
【０１５４】
エージェントを引き出すための関数呼出は、ｔａｓｋＳｐａｗｎ（“ｕｐｇｒａｄｅｒ”、１００，０，６０００，ｖｘｍａｉｎ，“−ｈ／ａｔａ０／ｇ”，“−Ｔｔｒａｃｅ／ｔｘｔ”３”）のようであるべきである。スタックサイズは少なくとも６０００であるべきである。／ａｔａ０／ｇは、インストールされたエージェントへのパスによって置き換えられるべきである。ｕｐｃｏｎｆｉｇ．ｔｘｔ、ｅｊ．ｏ、ｄｓｓ．ｏ、及びｕｐｇｒａｄｅｒ．ｏは、このディレクトリに配置されるべきである。「−Ｔ」で始まる最後のストリングは、エージェントの診断追跡機能をオンにする。追跡が必要でない場合はこれを省略することができる。この例では、出力はｔｒａｃｅ．ｔｘｔという名のファイルに書き込まれる。ファイル名の代わりに「ｓｔｄｏｕｔ」を指定することにより、シェルへの出力を達成することができる。コロンの後の数字は追跡詳細レベルを指定しており、０が最小で９が最大である。
【０１５５】
必須モジュール
ＶｘＷｏｒｋｓ（Ｒ）の実行時間画像に組み込んで構成することのできる任意のライブラリ及び関数が多くある。これらの殆どはエージェントの実行には必須ではないが、いくつかは必須である。これらのうちのいくつかは前述の通りである。下記は、エージェントを実行するために構築されたＶｘＷｏｒｋｓ（Ｒ）に含まれる必要のあるモジュールのリストである。
ＡＮＳＩ＿ＳＴＤＩＯ
ＡＮＳＩ＿ＳＴＲＩＮＧ
ＡＴＡ
ＤＯＳＦＳ
ＥＬＴ（又はターゲットが使用するあらゆるネットワークアダプタ）
ＩＯ＿ＳＹＳＴＥＭ
ＬＯＡＤＥＲ（ｅｊ．ｏ、ｄｓｓ．ｏ、又は他の実行可能モジュールをロードする場合は必須）
ＳＹＭ＿ＴＢＬ
ＮＥＴＷＯＲＫ
【０１５６】
標準の出力追跡メッセージをコンソールにおいて眺めたり、シェルからエージェントをロードして初期設定したり、フロッピー（Ｒ）ディスクから再起動したりすることを望む場合、更なるモジュールが必要となりうる。これらのモジュールは、下記の通りである。
ＰＣ＿ＣＯＮＳＯＬＥ（コンソールにおいてメッセージを眺めるために必須）
ＳＨＥＬＬ（シェルからロードして実行するために必須）
ＦＤ（フロッピー（Ｒ）から再起動するために必須）
【０１５７】
ＶｘＷｏｒｋｓ（Ｒ）画像の構築及びリンクの更なる情報に関しては、ＶｘＷｏｒｋｓ（Ｒ）ドキュメンテーションを参照のこと。
【０１５８】
エージェントの終了
ＶｘＷｏｒｋｓ（Ｒ）においてエージェントを終了するには、ＳＩＧＫＩＬＬ（１５）信号をエージェントタスクに送信する。これを、ＶｘＷｏｒｋｓ（Ｒ）シェルキルコマンド又はプログラムＡＰＩを用いて行うことができる。これにより、エージェントはその目下のタスクを完了し、手際良く終了する。直ちに終了するには、代わりにＳＩＧＫＩＬＬ（９）信号を送信する。手際の良い終了の試みが直ちに行われる。ｔｄシェルコマンド又はｔａｓｋＤｅｌｅｔｅプログラムＡＰＩを使用することもできる。しかしながら、開いたファイルの中には閉じないものもあり、割り当てられたリソースの割り当て解除がなされない場合がある。特に、追跡ファイルは、このような終了の後ではおそらくアクセスが不可能になる。
【０１５９】
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔの参照
Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔは、ネットスケープコミュニケーションズ社によって開発された簡潔なクロスプラットフォームのスクリプト言語であり、標準ＥＣＭＡ−２６２：ＥＣＭＡスクリプト言語仕様として標準化されたものである。本発明は、組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔとして参照される、この言語の厳密なサブセットを実施している。Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔのサブセットを実施する目的は、スクリプトインタプリタのコードサイズを制御することである。組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔの最も顕著な関数は以下の通りである。
・算術演算子
・論理演算子
・大域関数
・局所／大域変数
・ｉｆ、ｅｌｓｅ、ｆｏｒ、及びｒｅｔｕｒｎキーワード
【０１６０】
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔの最も顕著な例外は以下の通りである。
・数字は浮動小数点ではなく整数である
・アレイ及びオブジェクトはサポートされない
・関数の宣言がない
【０１６１】
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔは、一般的なスクリプト機能と、組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ関数の呼出を計算量の多いＣ関数に結びつけるメカニズムとを提供する。あらゆるスクリプト言語と同様に、主な利点の１つは、展開が速く容易であり、サイクルコンパイル及びリンクが不要なことにある。欠点としては、スクリプトはソースの形で展開されるためにプライバシーが欠如していることと、コンパイルされたコードよりも実行が遅いこと、が挙げられる。表８は、より一般的な言語エレメントの部分的なリストを含んでいる。
【０１６２】
【表８】
2004534973.tif 000010
【０１６３】
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ大域変数は、更なる説明に値する。組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ大域変数は、エンジンの寿命の間は生変数であり（本発明では、１つのエンジンが始動時に開かれ、エージェントの終了時に閉じられる）、現行のスクリプトよりも長く存在する。Ｃアプリケーションは、これらの変数を宣言し、設定することができる。次に、これらの変数は、エンジンによって評価される任意のスクリプトによってアクセス可能となる。これにより、データを１つのスクリプトから他のスクリプトに渡すことができる。
【０１６４】
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔは、エンジンによって解釈される任意の組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔによって使用され得るＣ関数を宣言することができる。このことは、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔのセキュリティを侵害するが、これにより、アプリケーションは、コンパイルされた「Ｃ」の全ての利点を備える任意の動作を定義し、実行することができる。
【０１６５】
また、この結合メカニズムにより、アプリケーションはｌｏａｄＭｏｄｕｌｅなどの関数を拡張することもできる。これらの関数の多くは、パスされるパラメータの数に基づいた異なる実行をもたらすように多重定義されている。組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔはタイプが規定されていない言語であるため、パラメータの数は、生じるべき動作を決定する唯一の基準である。
【０１６６】
下記の関数が、本発明と共に含まれるＪａｖａ（Ｒ）Ｓｃｒｉｐｔインタプリタに追加されている。
・ａｄｄＣｏｍｐｏｎｅｎｔ
・ｃａｌｌＦｕｎｃｔｉｏｎ
・ｃｄ
・ｃｏｎｆｉｇ
・ｃｏｐｙＦｉｌｅＴｏＭｅｍｏｒｙ
・ｃｐ
・ｄｅｌｅｔｅＣｏｍｐｏｎｅｎｔ
・ｇｅｔＣｏｎｆｉｇ
・ｌｏａｄＭｏｄｕｌｅ
・Ｉｓ
・ｍｋｄｉｒ
・ｍｖ
・ｐｒｉｎｔ
・ｐｗｄ
・ｒｅｂｏｏｔ
・ｒｍ
・ｒｍｄｉｒ
・ｒｕｎＰｒｏｃｅｓｓ
・ｓｔａｒｔＵｐｇｒａｄｅ
・ｓｔｏｐＡｇｅｎｔ
・ｓｔｏｐＵｐｇｒａｄｅ
・ｔｒａｃｅ
・ｕｎｌｏａｄＭｏｄｕｌｅ
・ｗａｉｔＦｏｒＫｅｙｓｔｒｏｋｅ
【０１６７】
スクリプトされたアップグレード原則の場合のように、エージェント又はサーバによる実行のために、これらの関数を、本発明によって用いられる任意のＪａｖａ（Ｒ）Ｓｃｒｉｐｔファイルに使用することができる。全てのＪａｖａ（Ｒ）Ｓｃｒｉｐｔ変数は、ストリングとして記憶される。従って、これらの関数は全て、ストリング値をスクリプトに戻す。
【０１６８】
注：ａｄｄＪｓＦｕｎｃ  Ｃ  ＡＰＩにより、更なるユーザ定義組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ関数を追加することができる。
【０１６９】
インメモリファイルシステムエージェントに対しては、下記の関数も利用可能である。
・ｉｍＳａｖｅＤａｔａ
・ｉｍＤｅｌｅｔｅＤａｔａ
・ｕｐＣｏｐｙＴｏＰｅｒｓｉｓｔｅｎｔＳｔｏｒａｇｅ
・ｕｐＲｅｐｌａｃｅＯＳＩｍａｇｅ
ｅｎｔｒｙＰｏｉｎｔ  実行可能プログラムファイルにおけるエントリポイント（ＶｘＷｏｒｋｓ（Ｒ）のみ必要）
ｐｒｉｏｒｉｔｙ      ＶｘＷｏｒｋｓ（Ｒ） ｔａｓｋＳｐａｗｎ  ＡＰＩに定義されるような任意のＶｘＷｏｒｋｓ（Ｒ）優先順位（デフォルト値は１００）
ｏｐｔｉｏｎｓ        ＶｘＷｏｒｋｓ（Ｒ） ｔａｓｋＳｐａｗｎ  ＡＰＩに定義されるような任意のＶｘＷｏｒｋｓ（Ｒ）オプション（デフォルト値は０）
ｓｔａｃｋｓｉｚｅ    ＶｘＷｏｒｋｓ（Ｒ） ｔａｓｋＳｐａｗｎ  ＡＰＩに定義されるような任意のＶｘＷｏｒｋｓ（Ｒ）スタックサイズ（デフォルト値は５０００）
【０１７０】
説明
個別の処理を開始する。アーギュメントは、実行されるファイル名と、処理に渡すための、スペースで分離されたアーギュメントのリストを含む。
【０１７１】
Ｗｉｎｄｏｗｓ（Ｒ）では、ファイル名の拡張子が「．ｂａｔ」である場合、ファイルはネイティブＯＳスクリプトファイルとして解釈され、このスクリプトを処理するためにコマンドインタプリタが呼び出される。そうでない場合、ファイル名の拡張子は「．ｅｘｅ」のはずであり、ファイルは通常通りに実行される。
【０１７２】
Ｌｉｎｕｘ（Ｒ）では、ファイル名の拡張子は有意ではない。ファイルが実行可能なフォーマットとして認識された場合、ファイルは実行される。そうでない場合、標準シェルスクリプトインタプリタが呼び出され、ファイルはネイティブＯＳスクリプトとして処理される。
【０１７３】
ＶｘＷｏｒｋｓ（Ｒ）では、ファイルはメモリにロードされ、タスクの開始及び実行のためにＶｘＷｏｒｋｓ（Ｒ） ｔａｓｋＳｐａｗｎ  ＡＰＩが呼び出される。
【０１７４】
戻り値
処理が順調に開始された場合、ｒｕｎＰｒｏｃｅｓｓを「０」（ゼロ）に戻し、失敗した場合は「−１」に戻す。
【０１７５】
例
ｒｕｎＰｒｏｃｅｓｓ（“ＳａｍｐｌｅＡｐｐ．ｅｘｅ  ａｒｇ１  ａｒｇ２  ａｒｇ３”）；
ｒｕｎＰｒｏｃｅｓｓ（“ＳａｍＡｐｐ．ｏ  ａｒｇ１  ａｒｇ２”，“＿ＳａｍｐｌｅＭａｉｎ”，１００，０，１００００）；
【０１７６】
Ｃ関数の参照
組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ又は実行される処理によってＣ関数を呼び出すことができる。これらの関数により、開発者は、エージェントの構成能力及び機能性を高めることができる。組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔは、ｃａｌｌＦｕｎｃｔｉｏｎ  Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ ＡＰＩの使用により、又は前述のａｄｄＪｓＦｕｎｃを用いた新しいＪａｖａ（Ｒ）Ｓｃｒｉｐｔ ＡＰＩへの関数の結合により、Ｃ関数のロード及び呼出を行うことができる。これらの関数の多くは、文字「ｇ」で始まる標準のシステムＡＰＩ（ｇｃｈｄｉｒ、ｇｃｌｏｓｅなど）である。一般に、エージェントのインメモリファイルシステム機能が使用されていない場合、これらのＡＰＩは標準のシステム呼出に変換される。インメモリファイルシステムが使用されている場合、これらのシステムはインメモリの同等の関数に変換され、この関数において、「ｇ」は「ｉｍ」に置き換えられ、標準名の最初の文字が大文字にされる（例えば、ｇｏｐｅｎはｉｍＯｐｅｎになる）。
【０１７７】
下記のＣ関数はエージェントにおいて利用可能であり、組込Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔの結合を実施するためにこれらを使用することができる。
・ａｄｄＪｓＦｕｎｃ
・ｅｊＧｅｔＶａｒ
・ｅｊＳｅｔＲｅｓｕｌｔ
・ｅｊＳｅｔＶａｒ
・ｇｃｈｄｉｒ
・ｇｃｌｏｓｅ
・ｇｃｌｏｓｅｄｉｒ
・ｇｅｔＤｉｒｅｃｔｏｒｙＬｉｓｔ
・ｇｇｅｔｃｗｄ
・ｇｌｓｅｅｋ
・ｇｍｋｄｉｒ
・ｇｏｐｅｎ
・ｇｏｐｅｎｄｉｒ
・ｇｒｅａｄ
・ｇｒｅａｄｄｉｒ
・ｇｒｅｎａｍｅ
・ｇｒｍｄｉｒ
・ｇｓｔａｔ
・ｇｕｎｌｉｎｋ
・ｇｗｒｉｔｅ
・ｌｏａｄＤｌｌ
・ｓｅｔＪｓＶａｒ
・ｓｔａｒｔＵｐｇｒａｄｅ
・ｓｔｏｐＵｐｇｒａｄｅ
・ｔｒａｃｅ
・ｕｎｌｏａｄＤＬＬ
【０１７８】
本発明は、好適な実施の形態を参照して具体的に示され、説明されたが、本発明の趣意及び範囲から逸脱することなく、形式及び詳細における種々の変更が可能であることが、当業者には明らかであろう。
【図面の簡単な説明】
【図１】
示される種々の展開されるデバイスを有するシステムの全体的な構造を示す図である。
【図２】
展開されるデバイスがアップグレードダウンロードを受信するシーケンスを示す図である。
【図１】
2004534973.tif 000011
【図２】
2004534973.tif 000012
【国際公開パンフレット】
2004534973.tif 000013
2004534973.tif 000014
2004534973.tif 000015
2004534973.tif 000016
2004534973.tif 000017
2004534973.tif 000018
2004534973.tif 000019
2004534973.tif 000020
2004534973.tif 000021
2004534973.tif 000022
2004534973.tif 000023
2004534973.tif 000024
2004534973.tif 000025
2004534973.tif 000026
2004534973.tif 000027
2004534973.tif 000028
2004534973.tif 000029
2004534973.tif 000030
2004534973.tif 000031
2004534973.tif 000032
2004534973.tif 000033
2004534973.tif 000034
2004534973.tif 000035
2004534973.tif 000036
2004534973.tif 000037
2004534973.tif 000038
2004534973.tif 000039
2004534973.tif 000040
2004534973.tif 000041
2004534973.tif 000042
2004534973.tif 000043
2004534973.tif 000044
2004534973.tif 000045
2004534973.tif 000046
2004534973.tif 000047
2004534973.tif 000048
2004534973.tif 000049
2004534973.tif 000050
2004534973.tif 000051
2004534973.tif 000052
2004534973.tif 000053
2004534973.tif 000054
2004534973.tif 000055
2004534973.tif 000056
2004534973.tif 000057
2004534973.tif 000058
2004534973.tif 000059
2004534973.tif 000060
2004534973.tif 000061
2004534973.tif 000062
【国際調査報告】
2004534973.tif 000063