JP5354768B2 - ソフトウェア自動配布システム - Google Patents

Description

本発明は、ソフトウェア配布システムに広く関する。特に、本発明は、リモートサイト、例えば、航空会社のセルフチェックイン、ホテルのチェックイン、レンタカー予約、ＰＯＳ端末などを支援するために用いられるソフトウェア配布システムに関する。

集中型サービスセンターを越えて配置された、セルフサービスのキオスク端末装置および代理店端末クライアントワークステーションの数が増加するにつれて、これらのクライアントワークステーションに配置されたプログラムおよびソフトウェアアップデートまたはソフトウェアアプリケーションのアプリケーション管理および配布は、深刻さを増す問題になる。変化するビジネス要件に一貫して応じるために、クライアントがすべて同じソフトウェアバージョンを実行していることが望ましく、また、多くの場合義務的である。クライアントソフトウェアの複数の同時発生のバージョンのサポートが必要な場合、クライアントおよびサーバの両方のバージョン管理は、アプリケーション管理および分配の困難性をさらに増加させる。さらに、最小コンフィギュレーションを必要とし、全く人を介在させない自動化された無人の方法で、リモートクライアント上のソフトウェアを更新することが望ましい。

また、通常、リモートクライアントおよび集中型サーバを支援するインフラは、対処されなければならない制限を有している。例えば、集中型サーバと各リモートサイトの間の広域ネットワーク（ＷＡＮ）帯域幅は、コストを節約するために通常制限されている。特にソフトウェア配布が比較的稀少な場合、帯域幅割当は、主としてアプリケーション用法の要求に基づいて、ソフトウェア配布要求を反映できない。多くのファイルを有する大規模なアプリケーションへのアップデートは、ＷＡＮを介してリモートクライアントに多くの資源の相当量を送信するかもしれない。例えば、増加分のアプリケーションリリースは、１０００ファイルを含む１００メガバイトのファイルリストから少数のファイルを更新してもよい。しかし、多くの現在利用可能な解決法においては、全体のファイルリストはアップデート承諾を保証するために個々のリモートクライアントに送信される。ダウンロード用かつ時刻のインストール用の帯域幅要件を低減するためには、新規、もしくは最後の更新以後変更された更新ファイルのみであることが好ましい。

大規模な空港のキオスク端末装置の展開あるいは大型店のＰＯＳ端末の展開のような、いくつかのリモート展開サイトは、上記の言及する問題を何桁も増幅して、何十あるいは何百ものクライアントを含むかもしれない。例えこれらのサイトにローカルのクライアント間の高速のローカルエリアネットワークがあったとしても、ローカルエリアネットワークはソフトウェア配信プロセスの自動化を強化するためには主として利用されない。

そのような問題の組み合わせは非常に複雑な問題を引き起こす。例えば、サーバと多くのクライアントを有するリモートサイトとの間での、上で言及した広域ネットワーク帯域幅制限は、実用的でない、あるいは管理するために費用対効果がよくない状況を作るかもしれない。

いくつかの態様の中で、本発明は、広域ネットワークを介して１セットのクライアントワークステーションに集中型サーバ環境を結合する（それらはさらに相互に結合される）ことが有利であることを認める。クライアントワークステーションは、自動的に集中型サーバ環境からソフトウェアアップデートを引き出す。広域ネットワークを介してファイルチャンク署名に基づいてダウンロードする差分ファイルを用いて、ローカルエリアネットワークを介してクライアント間のファイルを転送するためにピア・ツー・ピアのクライアントコミュニケーションを用いることは、さらに有利である。

そのような分野のために、本発明の実施例は、クライアントプロセッサを更新するためソフトウェアを引き出すための自動化方法である。クライアントプロセッサは、ローカルエリアネットワークを介して相互につながれた、少なくとも１つの他のクライアントプロセッサに統合される。クライアントプロセッサは、広域ネットワークを介して相互につながれたソフトウェア配布プロセッサに統合される。そして、ソフトウェア配布プロセッサは、１セットのファイルチャンク、設定可能なサイズの各ファイルチャンク、および計算されたデジタル署名を有する各ファイルチャンクとして、ソフトウェア配布を保持する。

クライアントプロセッサのリクエストによって、クライアントプロセッサ用にローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよびソフトウェアの期待状態を得るために、クライアントプロセッサは、ソフトウェア配布プロセッサと通信し合う。クライアントプロセッサは、クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、ソフトウェア配布の少なくとも１つのファイルチャンクが必要であるかどうかを決定する。クライアントプロセッサのリクエストによって、少なくとも１つのファイルチャンクは、別のクライアントプロセッサからクライアントプロセッサにローカルエリアネットワークによって転送される。

発明の別の実施例は、ソフトウェアアップデートを引き出すためのクライアントワークステーションによって取り組む。ローカルエリアネットワークは、少なくとも１台の他のクライアントワークステーションにクライアントワークステーションを統合することに使用される少なくとも１台の他のクライアントワークステーションにクライアントワークステーションを結合する。広域ネットワークは、ソフトウェア配布サーバにクライアントワークステーションを同期させるために使用されるソフトウェア配布サーバに、クライアントワークステーションを結合する。そして、ソフトウェア配布プロセッサは、１セットのファイルチャンク、構成可能なサイズの各ファイルチャンクおよび計算されたデジタル署名を有する各ファイルチャンクとしてソフトウェア配布を保持する。

クライアントアプリケーションは、クライアントワークステーション上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、ソフトウェア配布の少なくとも１つのファイルチャンクが必要であることをクライアントワークステーション内において判定するために、およびクライアントワークステーションのリクエストによってローカルエリアネットワーク上の別のクライアントワークステーションからクライアントワークステーションに少なくとも１つのファイルチャンクを転送するために、ローカルエリアネットワークを介して相互につながれたクライアントワークステーションのリストとクライアントワークステーションのためのソフトウェアの期待状態とを取得するクライアントワークステーションのリクエストによって、ソフトウェア配布プロセッサと通信するためにクライアントワークステーション上で作動する。

発明の別の実施例は、コンピュータ読み取り可能な記憶媒体上に格納されたプログラムコードを含むコンピュータ読み取り可能な記憶媒体に取り組む。プログラムコードは、ローカルエリアネットワークを介して相互につながれた、少なくとも１つの他のクライアントプロセッサにクライアントプロセッサを統合するために用いられる。プログラムコードは、広域ネットワークを介して相互につながれたソフトウェア配布プロセッサにクライアントプロセッサを統合させる。そして、ソフトウェア配布プロセッサは、１セットのファイルチャンク、設定可能なサイズの各ファイルチャンク、および計算されたデジタル署名を有する各ファイルチャンクとしてソフトウェア配布を保持する。

プログラムコードによって管理されるように、クライアントプロセッサのリクエストによってソフトウェア配布プロセッサとのコミュニケーションは、クライアントプロセッサのためにローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよびソフトウェアの期待状態を得るために遂行される。プログラムコードはまた、クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、ソフトウェア配布の少なくとも１つのファイルチャンクが必要であることをクライアントプロセッサ内において判定することをサポートする。

プログラムコードは、さらに、ローカルエリアネットワークを介して、別のクライアントプロセッサからクライアントプロセッサに、クライアントプロセッサのリクエストによって、少なくとも１つのファイルチャンクを転送する。

本発明の他の機能および利点と同様に、本発明についてのより十分な理解も、以下の詳細な説明および添付の図面から明白になる。

添付図面を参照しながら本願発明について、より十分に記述する。そこでは、本発明のいくつかの実施例と種々相が示される。しかしながら、本発明は様々な形式で具現されることができ、本明細書に記された実施例に限定されるものとして解釈されるべきではない。もっと正確に言えば、この開示が詳細になり完全になるために、これらの実施例が提供され、当業者に発明の範囲を十分に伝えるであろう。

図１は、本発明の態様による集中型サーバシステム１００を図示している。集中型サーバシステム１００は、中央サーバ環境１０２、リモートサイト１０４、および第１のネットワークメディア１０６とともに図示されている。中央サーバ環境１０２は、中央サーバ１０８、コンセントレータ／ルーター１１０、ファイアウォール１１２、ハブ／スイッチ１１４、および他の電子機器を含んでいる。他の電子機器は、例えば、中央サーバ１０８のデータベース１１６（データベース１１６はデータベースサーバおよび他のネットワークスイッチを含むことができる）、およびローカルクライアント１１８を含んでいる。

サーバ（例えば中央サーバ１０８）は、１つ以上のプロセッサ、メモリ、大容量ディスクドライブや高速通信装置のような高容量および高パフォーマンスの入出力装置を有する処理システムであり、キーボード、ディスプレイおよびプリンタを有することができる。コンピュータ読み取り可能な媒体に格納されるようなサーバプログラムは、例えば、磁気、光学、他の型のディスクドライブあるいは不揮発性記憶素子のような記憶メディアからロードされてもよいし、通信装置を通してダウンロードされてもよい。パフォーマンス、容量および、信頼度要求事項を満たすために、中央サーバ１０８のようなサーバは、サーバのクラスタとしてさらに構成されてもよい。

例えば、コンセントレータ、ルーター、ファイアウォール、ハブおよびスイッチは、異なるネットワークあるいはプロセッシングノードの間のデータの流れをコントロールするネットワーク装置であり、仮想プライベートネットワーク（ＶＰＮ）のサポートをするこができる。ファイアウォールは、不要なコミュニケーションあるいは禁止されたコミュニケーションから、サーバやデータベースのようなネットワークおよびその内蔵装置を保護するために、ネットワークトラフィックのセキュリティポリシーを強化するハードウェア装置および／またはソフトウェアアプリケーションである。データベースは、データベースアクセス機能を提供および支援するデータベースサーバによって各々接続され管理された高容量ディスクドライブの集合から成ってもよい。

集中型サーバシステム１００は、リモートサイト１０４のような複数の顧客環境を含む。リモートサイトは、例えば、航空会社環境、ホテル、レンタカー会社、銀行、および中央サーバ環境およびリモートサイトを利用する他のそのような会社を含むことができる。リモートサイトは、１台以上のクライアントワークステーションが配置されるホテル、ショッピング・モール、銀行、大学あるいは総合大学、コーヒーショップのような店、あるいはその他同種のものを適切に象徴することができる。

航空会社環境のようなリモートサイト１０４は、例えば、１つ以上のリモートクライアントプロセッサ１２０、ハブ／スイッチ１２２、およびルーター１２４を含むことができる。リモートサイト１０４は、さらに、リモートクライアントプロセッサを連結するためのローカルエリアネットワークのような第２のネットワークメディアを含むことができる。クライアントプロセッサは、新規のクライアントプロセッサがローカルエリアネットワークに加えられる場合、およびローカルエリアネットワークが最初にオンラインに導かれる場合に生じることができるような、ローカルエリアネットワーク上に相互につながれた他のクライアントプロセッサに統合される。

本発明による、リモートクライアントプロセッサ１２０の１つのようなワークステーションあるいはキオスク端末装置は、集中型サーバシステム１００のユーザと電子的に対話するためのセルフサービス装置である。ワークステーションあるいはキオスク端末装置は、１つ以上のプロセッサ、メモリ、入出力装置、磁気および光ディスク駆動装置のようなストレージシステム、および高速通信装置を有する処理システムを適切に含み、典型的にはキーボード、ディスプレイ、およびプリンタを有する。

キオスク端末装置は、乗客予約、航空会社のチェックイン、ホテルの予約およびチェックイン、レンタカーの予約およびピックアップなどのような機能を提供するために調整することができ、またその意図した機能（航空便の乗客のチェックインなど）に助成するあらゆる環境内に配置することができる。ワークステーションプログラムあるいはキオスク端末装置プログラムは、コンピュータ読み取り可能な媒体として、例えば、ディスクドライブあるいは他のそのような不揮発性記憶素子のような記憶メディアからロードされるか、あるいは通信装置を通してダウンロードされてもよい。

第１ネットワークメディア１０６は、フレームリレー網、仮想プライベートネットワーク（ＶＰＮ：Virtual Private Network）、インターネットなどのような広域ネットワークを含んでもよい。第１ネットワークメディア１０６は、中央サーバ環境１０２と、リモートサイト１０４のような１つ以上のリモートサイトとの間の制御およびデータ通信路を提供する。

図２は、本発明の１つの態様による、リモートクライアントに有利にソフトウェアを配布するための典型的なシンクライアントバージョン管理（ＴＣＶＣ：Thin Client Version Control）システム２００を図示している。

典型的なＴＣＶＣシステム２００は、ＴＣＶＣサーバ２０２、第１のネットワークメディア２０３、ワークステーション２０４、ワークステーション２０６、および第２のネットワークメディア２０７を含んでいる。ＴＣＶＣサーバ２０２は、ＴＣＶＣサーバアプリケーション２０８、ファイルリスト２１０、マスタディレクトリ２１２、ファイルリストのセキュアハッシュアルゴリズム（ＳＨＡ：Secure Hash Algorithm）署名２１４、および登録済みのクライアントノードのリスト２１６を含む。

ワークステーション２０４は、シンクライアントバージョン管理（ＴＣＶＣ）クライアントアプリケーション２２０、ファイルリスト２２２、ステージングディレクトリ（ＳＤＩＲ：Staging Directory）２２４、プリスティンディレクトリ（ＰＤＩＲ：Pristine Directory）２２６、ファイルチャンクのＳＨＡ署名２２８、ライブディレクトリ（ＬＤＩＲ：Live
Directory）２３０、およびアップデートプログラム２３２を含む。

ワークステーション２０６は、ＴＣＶＣクライアントアプリケーション２４０、ファイルリスト２４２、ステージングディレクトリ（ＳＤＩＲ）２４４、プリスティンディレクトリ（ＰＤＩＲ）２４６、ファイルチャンクのＳＨＡ署名２４８、ライブディレクトリ（ＬＤＩＲ）２５０、およびアップデートプログラム２５２を含む。

第１ネットワークメディア２０３は、フレームリレー網、仮想プライベートネットワーク（ＶＰＮ）、インターネットなどのような広域ネットワークを適切に含んでもよい。第２のネットワークメディア２０７は、ワークステーション２０６とワークステーション２０４と、そしてＴＣＶＣサーバ２０２と直接結び付けてもよいし結び付けなくてもよいあらゆる新たなワークステーションとを結び付けるための、ローカルエリアネットワークを含んでもよい。

ＴＣＶＣサーバアプリケーション２０８は、中央サーバ１０８のような１つ以上のサーバ上で作動する。中央サーバ１０８は、個々のリモートクライアントプロセッサ１２０、キオスク端末装置あるいはワークステーション上で用いられるファイルのマスターリストにアクセスする。ＴＣＶＣサーバアプリケーション２０８は、「GetFileList」「GetFileChunk」「GetClientList」のようなトランザクションをサポートする。

最新のファイルを有しているかどうか判断するアップデート手続きでは、ＴＣＶＣクライアントアプリケーション２２０を実行するワークステーション２０４のようなワークステーションは、ＴＣＶＣサーバアプリケーション２０８に「GetFileList」トランザクションリクエストを送信する。ＴＣＶＣクライアントアプリケーション２２０は、入力としてそれが要求しているテーマリストの名前、ＴＣＶＣクライアントアプリケーション２２０が作動している遠隔ワークステーションのＩＰアドレス、および遠隔ワークステーション上のプリスティンディレクトリ（ＰＤＩＲ）２２４内に現在存在するファイルリスト全体のためのセキュアハッシュアルゴリズム（ＳＨＡ）署名を送信する。

クライアントによって送信されたＳＨＡ署名がサーバ上の対応するマスタファイルリストのＳＨＡ署名と一致する場合、ＴＣＶＣサーバアプリケーション２０８は、クライアントに警報解除信号を送信する。署名が一致しない場合、ＴＣＶＣサーバアプリケーション２０８は、マスタファイルリスト署名、関連づけられたＳＨＡ署名に加えてマスタファイルリスト内の各ファイルチャンクのリスト、除去処理の間にクライアントによって削除する必要がある如何なるファイル／ディレクトリのリスト、およびファイルチャンクを転送することを試みることができるピアのＩＰアドレスのリストを、クライアントに通知する。

サーバからファイルチャンクをダウンロードしたい場合、アップデート手続きの一部として、ＴＣＶＣクライアントアプリケーション２２０は、ＴＣＶＣサーバアプリケーション２０８に「GetFileChunk」トランザクションリクエストを送信する。ＴＣＶＣクライアントアプリケーション２２０は、入力としてそれが要求しているファイルリストの名前、およびそれが要求しているファイルチャンクのＳＨＡ署名を送信する。クライアントによって要求されたファイルチャンクのＳＨＡ署名が、現在のサーバ上のいかなるファイルチャンクのＳＨＡ署名とも一致する場合、ＴＣＶＣサーバアプリケーション２０８はクライアントにファイルチャンクを返す。クライアントによって要求されたファイルチャンクのＳＨＡ署名が、現在のサーバ上のどのファイルチャンクのＳＨＡ署名とも一致しない場合、ＴＣＶＣサーバアプリケーション２０８はエラーを返す。

複数のＴＣＶＣサーバが１セットの遠隔ワークステーションを供するために設定される場合、「GetClientList」トランザクションは、別のＴＣＶＣサーバ（図示せず）によってコールされてもよい。いくつかのサーバ中でロードの安定を保つことを可能にし、かつＴＣＶＣサーバの１つがダウンする場合にでさえ、遠隔ワークステーションの活動を可能にするために、複数のＴＣＶＣサーバは、中央サーバ１０８として構成されてもよい。要求するＴＣＶＣサーバは、入力としてクライアントリストを要求しているファイルリストの名前を送信する。ＴＣＶＣサーバアプリケーション２０８は、ＴＣＶＣサーバ２０２により登録されたすべてのクライアントのＩＰアドレスのリスト、および各ＴＣＶＣクライアントが最後にＴＣＶＣサーバ２０２とコンタクトした時刻を、応答として送信する。

ファイルリスト２１０は、マスタファイルリストと見なされ、遠隔ワークステーション上で存在する必要があり、ＴＣＶＣサーバ２０２上のマスタディレクトリ２１２内に存在する必要のあるファイルおよびディレクトリのリストを含んでいる。ＴＣＶＣサーバ２０２のためのマスタディレクトリ２１２は、マスタファイルリスト２１０を構成するファイルおよびディレクトリを含んでいる。ファイルリスト名は、ファイルリストを識別するためのキーである。

ＴＣＶＣサーバ２０２は、ファイルリスト２１０の一部であるファイルチャンクのＳＨＡ署名を含むファイルリストのＳＨＡ署名２１４を、ディスク上に保存する。ファイルチャンクを判定するために、ＴＣＶＣサーバ２０２は、マスタディレクトリ２１２からファイルチャンクサイズを含むファイルを読み込む。ファイルチャンクサイズ以下のすべてのファイルに関しては、ファイルチャンクはファイル全体を含む。

ＴＣＶＣサーバ２０２は、ファイルチャンクのためのＳＨＡ署名を生成する。ファイルチャンクサイズより大きなすべてのファイルについては、ＴＣＶＣサーバは、各ファイルを指定されたファイルチャンクサイズのチャンクに論理的に分割し、各ファイルチャンクのＳＨＡ署名を生成する。例えば、ファイルチャンクサイズが１０２４バイトであることが決定しており、ファイルリスト内のファイルが３０００バイトのサイズを有している場合、ＴＣＶＣサーバ２０２はファイルを３つのファイルチャンクに論理的に分割してもよい。すなわち、１バイト目からスタートするサイズ１０２４バイトの第１のチャンク、１０２５バイト目からスタートするサイズ１０２４バイトの第２のチャンク、および２０４９バイト目からスタートするサイズ９５２バイトの第３のチャンクである。

ファイルチャンクサイズは設定可能であり、サイズは中央サーバに結合されたクライアントプロセッサの数を考慮に入れる中央サーバに利用可能な推測された広域ネットワーク帯域幅およびそれらの結合帯域幅に依存する。

ＴＣＶＣサーバアプリケーション２０８は、クライアントがサーバとコンタクトした最終の時刻と同調してＴＣＶＣサーバアプリケーション２０８とコンタクトしたＴＣＶＣクライアントのＩＰアドレスを含む登録済みのクライアントノード２１６のリストを、ディスク上に保存する。このリストは、ダイナミックに生成され、クライアントがＴＣＶＣサーバ２０２へ「GetFileList」トランザクションを送信するごとに更新される。ＴＣＶＣサーバアプリケーション２０８は、要求するクライアントのピアをすべて判定するための「GetFileList」コール中にリスト２１６を用いる。また、それは「GetClientList」コールの一部としてリスト２１６を返す。このリスト内に保存されたＴＣＶＣクライアントは、もはやアクティブでないクライアントを考慮に入れるために老朽化する。例えば、ＴＣＶＣクライアントがＴＣＶＣサーバアプリケーション２０８とコンタクトした最終の時刻と現在時刻との間の期間が前もって定義した閾値より大きい場合、ＴＣＶＣクライアントは、無効であると見なされ、リストから外される。

ＴＣＶＣクライアントアプリケーション２２０、２４０のようなＴＣＶＣクライアントアプリケーションは、各遠隔ワークステーション上で実行され、ＴＣＶＣサーバ２０２のような１つ以上のＴＣＶＣサーバと通信するように構成される。例えば、ＴＣＶＣクライアントアプリケーション２２０は、ＴＣＶＣサーバ２０２からの遠隔ワークステーション上で用いられるファイルのリストを得る。ＴＣＶＣクライアントアプリケーション２２０、２４０は、「GetFileChunk」「CompareNotes」「QueueUpdate」のようなトランザクションをサポートする。

別のクライアントからファイルチャンクをダウンロードしたい場合、ＴＣＶＣクライアントアプリケーション２２０は、そのアップデート手続きの一部として、別のＴＣＶＣクライアントアプリケーション２４０に「GetFileChunk」トランザクションリクエストを送信する。ＴＣＶＣクライアントアプリケーション２２０は、それが要求しているファイルリストの名前、およびそれが要求しているファイルチャンクのＳＨＡ署名を送信する。クライアントによって要求されたファイルチャンクのＳＨＡ署名が、現在のクライアント上のいかなるファイルチャンクのＳＨＡ署名とも一致する場合、ＴＣＶＣクライアントアプリケーション２４０は、要求するクライアントにファイルチャンクを返す。クライアントによって要求されたファイルチャンクのＳＨＡ署名が、現在のクライアント上のどのファイルチャンクのＳＨＡ署名とも一致しない場合、別のＴＣＶＣクライアントは、エラーを返す。

例えば、ＴＣＶＣクライアント２２０上で作動する「CompareNotes」トランザクションは、どのファイルチャンクが既に存在するか、あるいは、サーバによってダウンロードされているか、もしくは別のＴＣＶＣクライアント（図示せず）から転送されているかを判定するために、ＴＣＶＣクライアント２４０のような第２の要求するＴＣＶＣクライアントによってコールされてもよい。要求するクライアント２４０は、トランザクションへの入力として、情報を望むファイルチャンク署名のリストを送信する。

ＴＣＶＣクライアント２２０は、ＴＣＶＣサーバアプリケーション２０８あるいは他の１つのＴＣＶＣクライアントから現在ダウンロードしている、そのファイルチャンク署名およびファイルに対するリストを比較する。ＴＣＶＣクライアント２２０は、既にディスク上に存在するリストからのファイルチャンク署名、およびＴＣＶＣサーバアプリケーション２０８あるいは別のクライアントから現在ダウンロードされているものを、要求するＴＣＶＣクライアント２４０に返す。

ダウンロードされている各ファイルチャンクについては、ＴＣＶＣクライアント２２０は、ダウンロードされることが完結する予定時刻（ＥＴＡ）、および「１」に設定することでファイルチャンクがＴＣＶＣサーバアプリケーション２０８からダウンロードされていることを示し、「０」に設定することでファイルチャンクが別のクライアントから転送されていることを示すサーバビットを、要求するＴＣＶＣクライアント２４０に返す。既にディスク上にある各ファイルチャンクについては、ＴＣＶＣクライアント２２０は、「０」のＥＴＡおよび「０」のサーバビットの設定の組み合わせを返す。

ワークステーションＴＣＶＣクライアント・アップデートの現在の状況を示すために、例えば、ＴＣＶＣクライアント２２０上で作動する「QueueUpdate」トランザクションは、ワークステーションユーザの状況要求に応じてコールされる。入力はこのトランザクションに必要ではなく、アイドル状態、サーバへのコンタクト、別のクライアントからのダウンロード、サーバからのダウンロード、スリープ状態、ポスト・ダウンロード・アップデートなどの実行のような、ＴＣＶＣクライアントの現在の状態を示すＨＴＭＬページを、出力として戻す。

ワークステーション２０４は、ファイルリスト２２２、ステージングディレクトリ（ＳＤＩＲ）２２４、プリスティンディレクトリ（ＰＤＩＲ）２２６、ライブディレクトリ（ＬＤＩＲ）２３０、アップデートプログラム２３２、ファイルチャンクサイズ、およびサーバアドレスを保存する。ファイルリスト２２２は、ＰＤＩＲ２２６内に存在するファイルおよびディレクトリを格納する。ファイルリスト２２２内には、他のファイルおよびディレクトリ中に含んでいるＴＣＶＣクライアントのためのコンフィギュレーションファイル（ファイルリストの名前）がある。ファイルリスト２２２は、ＴＣＶＣサーバ２０２上に存在するファイルリスト２１０に対応する。

プリスティンディレクトリ（ＰＤＩＲ）２２６は、例えば、ＴＣＶＣサーバ２０２上のファイルリスト２１０に対応して、ファイルリストを構成するテーマおよびディレクトリをすべて保持する。ＴＣＶＣクライアント２２０は、ＰＤＩＲ２２６内のファイルのファイルチャンクのためのＳＨＡ署名を生成し、ＳＨＡ署名のこのリストと、ダウンロードされるためにどのファイルチャンクを必要とするかを判定するための「GetFileList」コール上のＴＣＶＣサーバアプリケーション２０８によって返されたリストとを比較する。

ＰＤＩＲ２２６の中のファイルチャンクはまた、サーバおよび／または他のクライアントからファイルがダウンロードされるステージングディレクトリ（ＳＤＩＲ）２２４の初期のバージョンを生成するために用いられる。ＰＤＩＲ２２６がファイルリストの既知のバージョンを保持することを保証するために、ファイルは、ＰＤＩＲ２２６へ直接ダウンロードされない。ファイルチャンクがすべてステージングディレクトリ２２４にダウンロードされた場合、ファイルリストはステージングディレクトリ２２４から削除されてもよいし更新されてもよい。

ステージングディレクトリ（ＳＤＩＲ）２２４は、ＴＣＶＣサーバアプリケーション２０８および／または他のＴＣＶＣクライアント（例えばＴＣＶＣクライアント２４０）からダウンロードされるファイルおよびディレクトリをすべて保持する。ＳＤＩＲ２２４は、「GetFileList」コール中にＴＣＶＣサーバアプリケーション２０８によって返されるファイルチャンク署名と一致する署名のＰＤＩＲ２２６において、ファイルチャンクを用いて、最初に生成される。ＴＣＶＣクライアント２２０によってダウンロードされる他のいずれのファイルも、ステージングディレクトリ２２４内に保存される。ダウンロードされる必要のあるファイルチャンクが、すべて一旦ＳＤＩＲ２２４にダウンロードされたならば、プリスティンディレクトリ（ＰＤＩＲ）２２６は削除され、ＳＤＩＲ２２４のコンテンツは、新規のＰＤＩＲ２２６になるために移動される。

ＴＣＶＣクライアント２２０は、ＰＤＩＲ２２６内のファイルチャンクのＳＨＡ署名２２８を、ディスク上に保存する。ファイルチャンクは、ＴＣＶＣサーバ２０２内で用いられるような同様の方法で判定される。これらの署名は、ダウンロードされるためにファイルがどれを必要とするかを判定するための「GetFileList」コール中にＴＣＶＣサーバアプリケーション２０８によって返される署名と比較される。

ライブディレクトリ（ＬＤＩＲ）２３０は、ワークステーション２０４のためのファイルおよびディレクトリをすべて保持するワークステーションディスク上の位置にある。ワークステーション２０４上で作動する必要のある多くのプログラムは、ライブディレクトリ２３０からスタートする。一旦ファイルがすべてＴＣＶＣクライアント２２０によってダウンロードされたならば、ライブディレクトリ２３０から作動するいかなるプログラムも中断され更新される。

予定するファイルが一旦すべてダウンロードされたならば、アップデートプログラムファイル２３２は、更新処理中に実行されるプログラムを含んでいる。これらのアップデートプログラムは、それらがちょうど他のファイルのように更新されることを可能にするファイルリストの一部である。アップデートプログラムは、プリスティンディレクトリ２２６から実行される。

図３は、本発明の態様による、シンクライアントバージョン管理（ＴＣＶＣ）サーバの起動処理３００を図示している。図２からの機能要素は、以下の図における対応するステップで引用される。ステップ３０４で開始し、ＴＣＶＣサーバアプリケーション２０８は、そのコンフィギュレーションファイルを読み込む。ステップ３０６において、ＴＣＶＣサーバアプリケーション２０８はファイルリスト名、ライブディレクトリ、およびコンフィギュレーションファイルから得られた情報に基づいてファイルチャンクサイズを決定する。ファイルリスト２１０は、ライブディレクトリ下のファイルおよびサブディレクトリをすべて含んでいる。

ファイルチャンクサイズは、設定可能であり、平均ファイルサイズおよび割り当てられた広域ネットワーク帯域幅に基づく。ステップ３０８において、ＴＣＶＣサーバアプリケーション２０８は、ライブディレクトリ下の各ファイルを読み込む。ステップ３ｌ０において、ＴＣＶＣサーバアプリケーション２０８は、本明細書に参考文献として全体を援用するセキュアハッシュ標準の連邦情報処理規格（ＦＩＰＳ：Federal Information Processing Standard）刊行物１８０−１を満たすセキュアハッシュアルゴリズム（ＳＨＡ：Secure
Hash Algorithm）署名を算出する。ＳＨＡ署名も全ファイルリストのために決定される。

ステップ３１２において、ＴＣＶＣサーバアプリケーション２０８は、インターネットプロトコル（ＩＰ）アドレスのフォーマット内に格納された、登録済みのクライアントノード２１６のそのリストを読み込む。ステップ３１４において、ＴＣＶＣサーバアプリケーション２０８は、ワークステーション２０４のようなクライアントとＴＣＶＣサーバアプリケーション２０８との間の通信路のその端部に、サーバソケットを確立する。ステップ３１６において、ＴＣＶＣサーバアプリケーション２０８は、登記済みのクライアントからのハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストを処理する。

図４は、本発明の態様による、第１のクライアントリクエストに応答するための第１の応答サーバ処理４００を図示している。ステップ４０４において、「GetFileList」ハイパーテキスト転送プロトコル（ＨＴＴＰ）ポストリクエストが、ワークステーション２０４のような登記済みのクライアントから、ＴＣＶＣサーバアプリケーション２０８内に受信される。ステップ４０６において、クライアントのファイルリスト名、ＩＰアドレス、およびファイルリスト署名が、受信されたリクエストから読み込まれる。

ステップ４０８において、クライアントのファイルリスト署名が有効かどうかが判定される。ステップ４１０において、クライアントのファイルリスト署名が有効でないと判定される場合、リスト内の各ファイルチャンクおよび各ファイルチャンクの署名は、要求するクライアントに返される。クライアントが最新のファイルリストを有しておらずファイルの中で最新のレベルをダウンロードする必要があることを示すので、この判定はエラーとは見なされない。クライアントのリスト署名が有効であると判定される場合、警報解除信号が、ステップ４１２において、要求するクライアントに返される。

図５は、本発明の態様による、第２のクライアントリクエストに応答するための第２の応答サーバ処理５００を図示している。ステップ５０４において、「GetChunk」ＨＴＴＰポストリクエストが、ワークステーション２０４のような登録済みのクライアントから受信される。ステップ５０６において、クライアントのファイルリスト名およびチャンク署名が、受信されたリクエストから読み込まれる。ステップ５０８において、要求されたファイルチャンクが、ＴＣＶＣサーバの目録内に存在するかどうかが判定される。ステップ５１０において、要求されたファイルチャンクがＴＣＶＣサーバの目録において見つからない場合、問題が発見したことを示すエラーコードが報告される。ステップ５１２において、要求されたファイルチャンクは、要求するクライアントに返される。

図６は、本発明の態様による、第３のサーバリクエストに応答するための第３の応答サーバ処理６００を図示している。ステップ６０４において、「GetClientList」リクエストが、サーバクラスタ内のＴＣＶＣサーバの別の１つから受信される。ステップ６０６において、各クライアントが最後にサーバとコンタクトした時刻と同調して、すべての登録済みのクライアントのＩＰアドレスが、要求するＴＣＶＣサーバに返される。この情報は、すべてへのＴＣＶＣサーバのグループを、ロード・バランシングおよびフォールト・トレラントのセットアップで同じリストを保存することを可能にするために用いられる。

図７は、本発明の態様による、ＴＣＶＣクライアント起動処理７００を図示している。
ステップ７０４において、ＴＣＶＣクライアント２２０は、コンフィギュレーションファイルを読み込む。ステップ７０６において、ファイルリスト、ライブディレクトリ、ステージングディレクトリ、プリスティンディレクトリ（ＰＤ）、ファイルチャンクサイズ、およびサーバアドレスの名前が、コンフィギュレーションファイルにおいて読み込まれたデータから決定される。ステップ７０８において、ＴＣＶＣクライアント２２０は、ＴＣＶＣクライアント２２０とＴＣＶＣサーバ２０２との間の通信路のその端部に、サーバソケットを確立する。ステップ７１０において、ＴＣＶＣクライアント２２０は、他のＴＣＶＣクライアントからのＨＴＴＰリクエストを処理する。

図８Ａは、本発明の態様による、ＴＣＶＣクライアント更新処理８００のパートＡを図示している。ステップ８０４において、プリスティンディレクトリ（ＰＤＩＲ）がまだ存在しない場合、初期のプリスティンディレクトリ（ＰＤＩＲ）２２６が生成される。ステップ８０６において、ＰＤＩＲ２２６内の各ファイルが読み込まれる。ステップ８０８において、ＳＨＡ署名が、各ファイルの各チャンク、およびＰＤＩＲファイルリスト全体のために計算される。

ステップ８１０において、「GetFileList」ＨＴＴＰポストリクエストは、そのＰＤＩＲファイルリストおよびＳＨＡ署名を指定して、ＴＣＶＣサーバ２０２のような、クライアントの関連づけられたＴＣＶＣサーバへ送信される。ステップ８１２において、ピアのリスト、およびクライアント上で複製されるファイル署名の正統のリストを含むＴＣＶＣサーバ２０２からのレスポンスが受信される。

「正統なリスト」は、現在のサーバ上のすべてのファイルチャンクのリスト、ライブディレクトリに関するディスク上のそれらの位置、およびそれらのＳＨＡ署名である。ステップ８１４において、警報解除信号が受信されたかどうかが判定される。警報解除信号は、クライアントがサーバと同じファイルを有していて、それ以上アクションが必要でないことを示す。警報解除信号が受信されていない場合、処理はステップＡ８１６に移る。警報解除信号が受信されている場合、処理８００はステップＤ８１８に移る。

図８Ｂは、本発明の態様による、ＴＣＶＣクライアント更新処理８００のパートＢを図示している。処理８００のパートＢは、パートＡのステップ８１６から継続する。ステップ８２２において、ステージングディレクトリは、ステージングディレクトリ（ＳＤＩＲ）２２４のように、生成される。ステップ８２４において、あらゆる再使用されたチャンクが、ＰＤＩＲ２２６からＳＤＩＲ２２４にコピーされる。再使用されたチャンクは、受信されたサーバファイル署名簿から決定される。

ステップ８２６において、クライアントにそのチャンクがすべてあるかどうかが判定される。クライアントにそのチャンクがすべてあることが判定される場合、処理８００はパートＤのステップ８１８に移る。クライアントにそのチャンクがすべてあるとは限らないことが判定される場合、処理はステップ８３０に移る。ステップ８３０において、ＨＴＴＰポストは、「CompareNotes」トランザクションを要求し、現在必要とするチャンク署名のリスト内を通過する、各ピアのもとへ送信される。

ステップ８３２において、各ピア上に存在するファイルチャンクのリストが、要求するクライアント内から受信される。そのリストと同調して、ファイルチャンクが十分にダウンロードされる時のための到着予定時刻（ＥＴＡ：Estimated Time of Arrival）、およびチャンクがＴＣＶＣサーバからダウンロードされているか別のＴＣＶＣクライアントから転送されているかどうか示すビットがある。

ステップ８３４において、ＥＴＡがゼロであるチャンクはすべて、要求するクライアントに、例えば、ランダムな順序で、およびランダムなピア所有者から、ダウンロードされる。ピアからの転送のためのピアおよびファイルチャンクは、１つのピアが他のピアからリクエストを過度に負わせられる可能性を減少させるために、好ましくはアトランダムあるいは偽似乱数の方式が選ばれる。その後、処理８００は、パートＢのステップ８３６に移る。

図８Ｃは、本発明の態様による、ＴＣＶＣクライアント更新処理８００のパートＣを図示している。処理８００のパートＣは、パートＢのステップ８３６から続行する。ステップ８５２において、変数Ｄは、ＴＣＶＣサーバ２０２のような、クライアントの関連づけられたサーバから、現在ダウンロードされているチャンクの数を表現するように、計算される。すべてのＴＣＶＣクライアントは、ファイルへのアクセスのために、そのコンフィギュレーションファイル内に接続するための指定されたＴＣＶＣサーバを有している。

変数Ｄは、アップストリームの帯域幅を推測するために用いられる。ピアからダウンロードするファイルがこれ以上なく、次のファイルがＴＣＶＣサーバからダウンロードされる必要があることを示す、ＥＴＡ＝０のすべてのチャンクがすべてのピアからダウンロードされている場合、変数Ｄが計算される。ステップ８５４において、変数Ｄが、設定可能なダウンロード閾値より大きいかどうかが判定される。

ダウンロード閾値は、起動時に読み込まれるファイルリスト２２２内に含まれ、コンフィギュレーションファイル内で指定される。ダウンロード閾値は、クライアントからサーバへのネットワーク帯域幅に基づいて計算される。変数Ｄが、構成可能なダウンロード閾値より大きいと判定された場合、処理８００はステップ８６４に移る。変数Ｄが、構成可能なダウンロード閾値以下であると判定された場合、処理はステップ８５６に移る。

ステップ８５６において、存在しないチャンク、あるいはいかなるピア上でもダウンロードされないチャンクが選択される。ステップ８５８において、選択されたチャンクは、クライアントからのリクエストに際して、クライアントの関連づけられたサーバからダウンロードされる。この処理は、同じファイルチャンクがＴＣＶＣサーバから２度ダウンロードされるのを防ぐために、各クライアントによって追従される。ステップ８６０において、ダウンロードが成功したかどうかが判定される。

ダウンロードが成功した場合、処理８００は、図８ＢのパートＢのステップ８２６に戻すステップ８６２に移る。一旦ダウンロードが成功裡に終われば、ＴＣＶＣクライアントは、もう一度各ピアの「CompareNotes」をコールするステップ８２６に戻る。このステップは、サーバからファイルをダウンロードしている間、どの新規のファイルチャンクが他のピアによってダウンロードされたかを、これらのクライアントにさせる。ダウンロードが成功しなかった場合、処理はステップ８６４に移る。

ステップ８６４において、要求するクライアントは、最小限必要とされるチャンクＥＴＡの１１０％のスリープモードに置かれる。ファイルチャンクがダウンロードされるまで、他のアクションを行なうことができないので、クライアントは、スリープモードに置かれる。ＥＴＡの１１０％の値は、ダウンロードが完了した後、ピアがＳＨＡ署名の計算のようなあらゆる付加的処理を終了することを可能にするように計算される。

図８Ｄは、本発明の態様による、ＴＣＶＣクライアント更新処理８００のパートＤを図示している。処理８００のパートＤは、パートＡのステップ８１８から続行し、ステップ８８２から開始する。ステップ８８２において、プリスティンディレクトリ（ＰＤＩＲ）２２６は削除され、ステージングディレクトリ（ＳＤＩＲ）２２４のコンテンツは、新規のＰＤＩＲ２２６になるために移動される。ステージングディレクトリ２２４は、ステップ８２２において、まず生成される。それは、ステップ８２４におけるＰＤＩＲ２２６、およびステージングディレクトリ内に保存されるステップ８３４および８５８においてダウンロードされたいかなるファイルからのチャンクにより、更新される。

判定ステップ８８３において、プリスティンディレクトリ（ＰＤＩＲ）内のファイルは、ライブディレクトリ（ＬＤＩＲ）のファイルと比較される。ＰＤＩＲ内のファイルがＬＤＩＲ内のファイルと一致しない場合、処理８００はステップ８８４に移る。ステップ８８４において、リモートサイトクライアントは、ライブディレクトリの実行プログラムを中断する。ライブディレクトリは図７ステップ７０６内で紹介された。それはプログラムが実際に実行されるディレクトリである。ライブディレクトリのプログラムは、プログラムがＰＤＩＲからの、より新規のバージョンにより更新される必要があるかもしれないため、実行を止められてもよい。

ステップ８８６において、新規のＰＤＩＲは、あらゆる複製のファイルも交換するライブディレクトリにコピーされる。ステップ８８８において、クライアントの関連づけられたサーバによって指定されるようなライブディレクトリのいかなるファイルも削除するために、クリーンアップパスがなされる。中断されたプログラムは、ステップ８８８の一部として再開される。サーバは、ステップ８１２における初期のリクエストの一部として削除されるファイルのリストを送信する。これらのファイルは、もはや用いられないので、削除することができる。一旦クリーンアップパスが完結すれば、ステップ８８４において中断されたいかなるプログラムも再開されることに留意されたい。

判定ステップ８８３に戻って、プリスティンディレクトリ（ＰＤＩＲ）内のファイルが、ライブディレクトリ（ＬＤＩＲ）のファイルと比較される場合、照合判定に達することができる。ＰＤＩＲ内のファイルがＬＤＩＲ内のファイルと一致する場合、処理８００は、処理８００のこのステップが完了していることを示すステップ８９０に移る。

図９は、本発明の態様による、別のクライアントからの第１のリクエストに応答するための、第１のレスポンスクライアント処理９００を図示している。ステップ９０４において、「GetChunk」ＨＴＴＰリクエストが、別のクライアントから受信される。ステップ９０６において、チャンクの署名が、受信されたリクエストから読み込まれる。ステップ９０８において、要求されたチャンクがリクエストを受信するクライアント上に存在する場合、要求されたチャンクが返される。

図１０は、本発明の態様による、別のクライアントからの第２のリクエストに応答するための、第２のレスポンスクライアント処理１０００を図示している。ステップ１００４において、「CompareNotes」ＨＴＴＰリクエストが、別のクライアントから受信される。ステップ１００６において、ファイルチャンク署名のリストが、受信されたリクエストから読み込まれる。ステップ１００８において、存在する、あるいは、リクエストを受信するクライアントにダウンロードされるファイルチャンクのリストは、ＥＴＡと、サーバがチャンクをダウンロードしていることを示すビットとに同調して、要求するクライアントに返される。

図１１は、本発明の態様による、別のクライアントからの第３のリクエストに応答するための、第３のレスポンスクライアント処理１１００を図示している。ステップ１１０４において、「QueueUpdate」ＨＴＴＰリクエストが、別のクライアントから受信される。ステップ１１０６において、アップデートがクライアント上のキューに入れられる。ステップ１１０８において、アップデートの状況を示すハイパーテキストマークアップ言語（ＨＴＭＬ）ページが返される。

図１２は、本発明の態様による典型的な自動ソフトウェア配布システム１２００を図示している。典型的なソフトウェア配布システム１２００は、ＴＣＶＣサーバ１２０２、キオスク端末装置の第１のセット１２０４、キオスク端末装置の第２のセット１２０６、キオスク端末装置の第１のセット１２０４のサブセットであるキオスク端末装置の第２のセット１２０６、第１の結合回路網１２１０、および第２の結合回路網１２１２を含む。ＴＣＶＣサーバ１２０２は、図２のＴＣＶＣサーバ２０２と同様の方法で機能する。

キオスク端末装置１２０４の第１のセット内のキオスク端末装置の各々は、ＴＣＶＣサーバ１２０２への第１の結合回路網１２１０を通して結合パスを持つ。キオスク端末装置１２０４の第１のセットは、第２の結合回路網１２１２上で相互に連結されるキオスク端末装置１２１８〜１２２３から成る。各キオスク端末装置１２１８〜１２２３は、図２のワークステーション２０４と同様の方法で機能する。第１の結合回路網１２１０は、フレームリレー網、仮想プライベートネットワーク（ＶＰＮ）、インターネットなどのような、広域ネットワークであってもよい。第２の結合回路網１２１２は、ローカルのキオスク端末装置１２１８〜１２２３間のローカルの高速接続を提供するために、リモートサイトで作動するローカルエリアネットワークであってもよい。

ファイルセット１２３０は、４つのパーツ１２３２〜１２３５に分割される。図３〜図１１に記載されていた処理に従って、ファイルセット１２３０は、キオスク端末装置１２０６の第２のセットのキオスク端末装置１２１９〜１２２２の各々に配布される。配布は、例えば、第１の結合回路網１２０６を介して遂行される各ダウンロードするとともに、キオスク端末装置１２１９へパートＡ１２３２をダウンロードし、キオスク端末装置１２２０へパートＢ１２３３をダウンロードし、キオスク端末装置１２２１へパートＣ１２３４をダウンロードし、キオスク端末装置１２２２へパートＤ１２３５をダウンロードするクライアントキオスク端末装置のリクエストによって遂行される。

各キオスク端末装置１２１８〜１２２３がファイルセット１２３０の複製を持つまで、キオスク端末装置１２１８〜１２２３の各々は、それら自身の間の欠けているファイルを適切に転送する。例えば、キオスク端末装置１２２３はキオスク端末装置１２１９からパートＡ１２３２を受信し、キオスク端末装置１２２０からパートＢ１２３３を受信し、キオスク端末装置１２２１からパートＣ１２３４、およびキオスク端末装置１２２２からのパートＤ１２３５を受信する。すべてのファイル１２３２〜１２３５がソフトウェア配布プロセッサからダウンロードされるのを待機せず、転送が利用可能な場合、ファイルチャンク、パートＡ１２３２、パートＢ１２３３、パートＣ１２３４、およびパートＤ１２３５は、クライアントプロセッサ１２０６の第２のセットから転送されることができる。

サーバがＮクライアントを有しており、Ｍのファイルリストサイズをホストする場合（Ｍの５０％が新規あるいは変更データで、Ｍ／２データが各クライアントに送信される）、転送されたデータの平均値は（Ｍ×Ｎ）／２である。新規あるいは変更データであってもよいファイルセットからのデータのパーセンテージは、変わってもよい。

以下の議論において、Ｍは各クライアントに送信されるデータの正味量であると仮定される。Ｎ＝１０００のクライアントを有する典型的なシナリオおよびＭ＝１００Ｍバイト（１００ＭＢ）の各クライアントに送信されるファイルリストにおいて、広域ネットワークは５６のキロビット毎秒（ｋｂｐｓ）から１．５Ｍｂｐｓ以上までの範囲に応じてクライアントからクライアントまで変わるかもしれないと考慮する、大きい転送された量のデータは、（１００ＭＢ＊１０００）＝１００，０００ＭＢあるいは１００ＧＢになるであろう。本発明のＴＣＶＣアプローチを用いて、クライアントがローカルネットワークへ細分されると仮定して、広域ネットワーク（ＷＡＮ）データ転送は（Ｍ×Ｋ）に近似する（ここで、Ｋは厳密にＮ未満である）。

実際上、Ｋは、帯域幅において大幅な節約を可能にするＮと比べて比較的小さい。Ｋ＝５０のローカルネットワークが、１０００台のクライアントをサポートするために、現在の具体例に用いられる場合、各ローカルネットワーク当たり２０台のクライアントの配布により、ＷＡＮによって転送されたデータの量は、（１００ＭＢ×５０）＝５，０００ＭＢあるいは５ＧＢ（はるかにより扱いやすい数）である。５０個のローカルネットワーク上に５ＧＢを分配することによって、クライアント・ローカルネットワークへの所定のサーバも、具体例において、最小値Ｍあるいは１００ＭＢに近づく。１００ＭＢは各ローカルネットワーク内のファイルチャンクへ分割され、すべてあるいは２０台のクライアントのサブセットに配布される。

その後、１００ＭＢのファイルリストが各々のクライアント上で得られるまで、各ローカルネットワーク内の２０台のクライアントは、本発明に従って、欠けているファイルチャンクを交換してもよい。節約がメインサーバ接続中の重複データのより少ないコミュニケーションを必要とすることによる、技術はサーバとのコミュニケーションを最小限にする。

ここに開示された実施例に関して記述された方法は、ハードウェア、プロセッサによって実行されたソフトウェア、あるいは２つの組み合わせで、直接具現されることができる。ソフトウェアあるいはプログラムコードは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、電気的なプログラマブル読出専用メモリ（ＥＰＲＯＭ）、電気的な消去可能なプログラマブル読出専用メモリ（ＥＥＰＲＯＭ）、ハードディスク、リムーバブルディスク、コンパクトディスク読み取り専用メモリ（ＣＤＲＯＭ）、あるいは当該技術の既知の記憶メディアの他の形式の中に存在してもよい。プロセッサが情報を読み込むことができ、かつ記憶メディアに情報を書き出してもよいように、記憶メディアは、プロセッサに結合されてもよい。

本発明は目下好ましい文脈内に開示されているが、この開示と矛盾しない様々な文脈、および後続するクレームに現在の教示が適応してもよいことは認識されるだろう。本発明が、部門のローカルネットワークに内部のイントラネットワークを結合する業務システム、あるいはキオスク端末装置の使用が成熟し発展するようにアプリケーションをサポートした他のセルフサービスキオスク端末装置の広い多様性と同様に、家庭用ローカルネットワークに接続したインターネットにより使用されてもよいことは認識されるであろう。また、使われた特定のハードウェアおよび制御処理におけるバリエーションが実現可能であり、そして双方が時間とともにより発展するように期待されることは認識されるだろう。

本発明の１つの態様による集中型サーバシステムを示す。 本発明の１つの態様による、リモートクライアントに有利にソフトウェアを配布するための典型的なシンクライアントバージョン管理（ＴＣＶＣ）システムを示す。 本発明の態様によるＴＣＶＣサーバ起動処理を示す。 本発明の態様による、第１のクライアントリクエストに応答するための第１の応答サーバ処理を示す。 本発明の態様による、第２のクライアントリクエストに応答するための第２の応答サーバ処理を示す。 本発明の態様による、第３のクライアントリクエストに応答するための第３の応答サーバ処理を示す。 本発明の態様によるＴＣＶＣクライアント起動処理を示す。 本発明の態様による、ＴＣＶＣクライアント更新処理のパートＡを示す。 本発明の態様による、ＴＣＶＣクライアント更新処理のパートＢを示す。 本発明の態様による、ＴＣＶＣクライアント更新処理のパートＣを示す。 本発明の態様による、ＴＣＶＣクライアント更新処理のパートＤを示す。 本発明の態様による、別のクライアントからの第１のリクエストに応答するための第１の応答クライアント処理を示す。 本発明の態様による、別のクライアントからの第２のリクエストに応答するための第２の応答クライアント処理を示す。 本発明の態様による、別のクライアントからの第３のリクエストに応答するための第３の応答クライアント処理を示す。 本発明の態様による典型的な自動ソフトウェア配布システムを示す。

Claims (13)

1. 第１クライアントプロセッサおよび第２クライアントプロセッサを、ローカルエリアネットワークに接続すると共に、広域ネットワークに接続するステップと、
   １セットのファイルチャンクとしてのソフトウェア配布であって、各ファイルチャンクのサイズが設定可能であると共に各ファイルチャンクがデジタル署名を有するソフトウェア配布を保持するソフトウェア配布プロセッサを、前記広域ネットワークを介して前記第１クライアントプロセッサおよび前記第２クライアントプロセッサに接続するステップと、
   前記ローカルエリアネットワークを介して前記第１クライアントプロセッサに接続されていると共に前記ソフトウェア配布プロセッサに登録されているクライアントプロセッサのリストおよび前記第１クライアントプロセッサ用のソフトウェアの期待状態を得るための前記第１クライアントプロセッサのリクエストによって、前記第１クライアントプロセッサが前記ソフトウェア配布プロセッサと通信するステップと、
   前記第１クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、前記ソフトウェア配布の少なくとも１つのファイルチャンクが必要であることを前記第１クライアントプロセッサ内において判定するステップと、
   前記第１クライアントプロセッサのリクエストによって、前記第２クライアントプロセッサから前記第１クライアントプロセッサに前記ローカルエリアネットワークを介して前記少なくとも１つのファイルチャンクを転送するステップと、
   前記少なくとも１つのファイルチャンクが前記第２クライアントプロセッサから入手可能でないことを前記第１クライアントプロセッサ内において判定するステップと、
   前記第１クライアントプロセッサが前記ソフトウェア配布プロセッサから前記少なくとも１つのファイルチャンクをダウンロードするステップと、
   如何なるファイルチャンクが、
   （１）前記第１クライアントプロセッサに既に存在するか、
   （２）前記第１クライアントプロセッサに前記ソフトウェア配布プロセッサからダウンロードされているか、又は
   （３）前記第１クライアントプロセッサに別のクライアントプロセッサから転送されているかを、判定するために、別のクライアントプロセッサから受信した「CompareNotes」トランザクションを前記第１クライアントプロセッサ内において処理するステップと、
   の各ステップを含むクライアントプロセッサに対してソフトウェアを自動配布する方法。
2. 前記ソフトウェア配布プロセッサに接続したクライアントプロセッサの数を勘案する前記ソフトウェア配布プロセッサに入手可能な推測された広域ネットワーク帯域幅および前記第１クライアントプロセッサの結合帯域幅に基づいた各ファイルチャンクの前記設定可能なサイズを判定するステップ、
   をさらに含む、請求項１に記載の方法。
3. 前記ソフトウェア配布プロセッサに配置されたファイルチャンクのマスタファイルリストのデジタル署名と前記第１クライアントプロセッサ内のファイルチャンクのファイルリストのデジタル署名との比較に基づいたソフトウェアアップデートを前記第１クライアントプロセッサが必要とするかどうかを判定する前記第１クライアントプロセッサから受信された「GetFileList」トランザクションを前記ソフトウェア配布プロセッサ内において処理するステップを、
   さらに含み、前記マスタファイルリストは期待状態を表現する、請求項１に記載の方法。
4. 前記第１クライアントプロセッサがソフトウェアアップデートを必要とすることを示す前記比較を判定するステップと、
   前記第１クライアントプロセッサと前記ソフトウェア配布プロセッサとが、前記マスタファイルリストの前記デジタル署名と、前記マスタファイルリスト内の各ファイルチャンクのリストと、各ファイルチャンクの署名の関連づけと、ピアクライアントのためのアドレスを結合するリストとを通信するステップと、をさらに含む、請求項３に記載の方法。
5. ファイルチャンクのデジタル署名によって識別された前記ファイルチャンクをダウンロードするために、前記第１クライアントプロセッサから受信した「GetFileChunk」トランザクションを前記ソフトウェア配布プロセッサ内において処理するステップを、さらに含む、請求項１に記載の方法。
6. 前記ソフトウェア配布プロセッサは、第１配布プロセッサおよび第２配布プロセッサを有し、前記第１配布プロセッサと前記第２配布プロセッサとの仕事量の平衡を保つ目的で、前記第２配布プロセッサから受信した「GetClientList」トランザクションを前記第１配布プロセッサ内において処理するステップを、をさらに含む、請求項１に記載の方法。
7. 前記第１クライアントプロセッサは、
   ファイルチャンクを保持し前記第１クライアントプロセッサ上で動作するソフトウェアの現在状態を保持するプリスティンディレクトリと、前記ファイルチャンクのファイルリストと、
   前記ファイルリストのデジタル署名と、
   各ファイルチャンクのデジタル署名と、を備える、請求項１に記載の方法。
8. ファイルチャンクの署名によって識別された前記ファイルチャンクを転送するために別のクライアントプロセッサから受信した「GetFileChunk」トランザクションを前記第１クライアントプロセッサ内において処理するステップ、をさらに含む、請求項１に記載の方法。
9. 第１クライアントワークステーションと、
   第２クライアントワークステーションと、
   前記第１クライアントワークステーションを前記第２クライアントワークステーションに接続するためのローカルエリアネットワークであって、前記第１クライアントワークステーション及び前記第２クライアントワークステーションが接続されるローカルエリアネットワークと、
   １セットのファイルチャンクとしてのソフトウェア配布であって、各ファイルチャンクのサイズが設定可能であると共に各ファイルチャンクがデジタル署名を有するソフトウェア配布を保持し、前記第１クライアントワークステーションおよび前記第２クライアントワークステーションが接続される広域ネットワークを介して前記第１クライアントワークステーションおよび前記第２クライアントワークステーションと接続されるソフトウェア配布サーバと、
   前記第１クライアントワークステーション上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、前記ソフトウェア配布の少なくとも１つのファイルチャンクが必要であることを前記第１クライアントワークステーション内において判定するために、および第２クライアントワークステーションから前記第１クライアントワークステーションに前記ローカルエリアネットワークを介して前記少なくとも１つのファイルチャンクを転送するために、前記ローカルエリアネットワークを介して前記第１クライアントワークステーションに接続されていると共に前記ソフトウェア配布サーバに登録されているクライアントワークステーションのリストと前記第１クライアントワークステーションのためのソフトウェアの期待状態とを取得するための前記第１クライアントワークステーションのリクエストによって、前記第１クライアントワークステーションが前記ソフトウェア配布サーバと通信するために前記第１クライアントワークステーション上で作動するクライアントアプリケーションと、
   を備え、
   前記クライアントアプリケーションは、
   前記少なくとも１つのファイルチャンクが前記第２クライアントワークステーションから入手可能でないことを前記第１クライアントワークステーション内において判定し、かつ前記ソフトウェア配布サーバから前記少なくとも１つのファイルチャンクを前記第１クライアントワークステーションにダウンロードするために作動させるための機能を有し、
   どのファイルチャンクが、前記第１クライアントワークステーション内に既にあるか、又は前記ソフトウェア配布サーバから前記第１クライアントワークステーションにダウンロードされているか、又は別のクライアントワークステーションから前記第１クライアントワークステーションに転送されているかを判定するために、別のクライアントワークステーションから受信された「CompareNotes」トランザクションを前記第１クライアントワークステーションにおいて実行させるための機能を有するアップデートプログラムをさらに備える、システム。
10. 前記第１クライアントワークステーション上で現在動作しているファイルチャンクのファイルリストを保持するストレージシステムと、ファイルリストおよび前記ファイルチャンクの各々のデジタル署名と、をさらに含む、請求項９に記載のシステム。
11. 前記アップデートプログラムは、前記ソフトウェア配布サーバに配置されたファイルチャンクのマスタファイルリストのデジタル署名と前記第１クライアントワークステーション内のファイルチャンクのファイルリストのデジタル署名との比較に基づいて、前記第１クライアントワークステーションが最新のファイルを有しているかどうかを判断するための前記ソフトウェア配布サーバ内の「GetFileList」トランザクションを要求するための機能を含み、
    前記マスタファイルリストは、前記期待状態を表現する、請求項１０に記載のシステム。
12. 前記アップデートプログラムは、ファイルチャンクのデジタル署名によって識別された前記ファイルチャンクをダウンロードするための前記ソフトウェア配布サーバ内の「GetFileChunk」トランザクションを要求するための機能を含む、請求項１０に記載のシステム。
13. 前記アップデートプログラムは、前記第２クライアントワークステーションから、前記第１クライアントワークステーションに、ファイルチャンクを転送するために、前記第１クライアントワークステーションから受信された「GetFileChunk」トランザクションを実行させる機能を含み、前記ファイルチャンクはファイルチャンクのデジタル署名によって識別される、請求項１０に記載のシステム。

Images