説明

ソフトウェア自動配布システム

【課題】クライアントプロセッサを更新するために自動的にソフトウェアを引き出すためのワークステーションを提供する。
【解決手段】クライアントプロセッサは、ローカルエリアネットワークを介して相互につながれた少なくとも1つの他のクライアントプロセッサに統合される。クライアントプロセッサはまた広域ネットワークを介して相互につながれたソフトウェア配布プロセッサに統合される。ソフトウェア配布プロセッサは1セットのファイルチャンク、設定可能なサイズの各ファイルチャンクおよび計算されたデジタル署名を有する各ファイルチャンクとして、ソフトウェア配布を保持する。クライアントプロセッサのリクエストによって、クライアントプロセッサ用にローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよびソフトウェアの期待状態を得るためにクライアントプロセッサはソフトウェア配布プロセッサと通信し合う。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ソフトウェア配布システムに広く関する。特に、本発明は、リモートサイト、例えば、航空会社のセルフチェックイン、ホテルのチェックイン、レンタカー予約、POS端末などを支援するために用いられるソフトウェア配布システムに関する。
【背景技術】
【0002】
集中型サービスセンターを越えて配置された、セルフサービスのキオスク端末装置および代理店端末クライアントワークステーションの数が増加するにつれて、これらのクライアントワークステーションに配置されたプログラムおよびソフトウェアアップデートまたはソフトウェアアプリケーションのアプリケーション管理および配布は、深刻さを増す問題になる。変化するビジネス要件に一貫して応じるために、クライアントがすべて同じソフトウェアバージョンを実行していることが望ましく、また、多くの場合義務的である。クライアントソフトウェアの複数の同時発生のバージョンのサポートが必要な場合、クライアントおよびサーバの両方のバージョン管理は、アプリケーション管理および分配の困難性をさらに増加させる。さらに、最小コンフィギュレーションを必要とし、全く人を介在させない自動化された無人の方法で、リモートクライアント上のソフトウェアを更新することが望ましい。
【0003】
また、通常、リモートクライアントおよび集中型サーバを支援するインフラは、対処されなければならない制限を有している。例えば、集中型サーバと各リモートサイトの間の広域ネットワーク(WAN)帯域幅は、コストを節約するために通常制限されている。特にソフトウェア配布が比較的稀少な場合、帯域幅割当は、主としてアプリケーション用法の要求に基づいて、ソフトウェア配布要求を反映できない。多くのファイルを有する大規模なアプリケーションへのアップデートは、WANを介してリモートクライアントに多くの資源の相当量を送信するかもしれない。例えば、増加分のアプリケーションリリースは、1000ファイルを含む100メガバイトのファイルリストから少数のファイルを更新してもよい。しかし、多くの現在利用可能な解決法においては、全体のファイルリストはアップデート承諾を保証するために個々のリモートクライアントに送信される。ダウンロード用かつ時刻のインストール用の帯域幅要件を低減するためには、新規、もしくは最後の更新以後変更された更新ファイルのみであることが好ましい。
【0004】
大規模な空港のキオスク端末装置の展開あるいは大型店のPOS端末の展開のような、いくつかのリモート展開サイトは、上記の言及する問題を何桁も増幅して、何十あるいは何百ものクライアントを含むかもしれない。例えこれらのサイトにローカルのクライアント間の高速のローカルエリアネットワークがあったとしても、ローカルエリアネットワークはソフトウェア配信プロセスの自動化を強化するためには主として利用されない。
【発明の開示】
【発明が解決しようとする課題】
【0005】
そのような問題の組み合わせは非常に複雑な問題を引き起こす。例えば、サーバと多くのクライアントを有するリモートサイトとの間での、上で言及した広域ネットワーク帯域幅制限は、実用的でない、あるいは管理するために費用対効果がよくない状況を作るかもしれない。
【課題を解決するための手段】
【0006】
いくつかの態様の中で、本発明は、広域ネットワークを介して1セットのクライアントワークステーションに集中型サーバ環境を結合する(それらはさらに相互に結合される)ことが有利であることを認める。クライアントワークステーションは、自動的に集中型サーバ環境からソフトウェアアップデートを引き出す。広域ネットワークを介してファイルチャンク署名に基づいてダウンロードする差分ファイルを用いて、ローカルエリアネットワークを介してクライアント間のファイルを転送するためにピア・ツー・ピアのクライアントコミュニケーションを用いることは、さらに有利である。
【0007】
そのような分野のために、本発明の実施例は、クライアントプロセッサを更新するためソフトウェアを引き出すための自動化方法である。クライアントプロセッサは、ローカルエリアネットワークを介して相互につながれた、少なくとも1つの他のクライアントプロセッサに統合される。クライアントプロセッサは、広域ネットワークを介して相互につながれたソフトウェア配布プロセッサに統合される。そして、ソフトウェア配布プロセッサは、1セットのファイルチャンク、設定可能なサイズの各ファイルチャンク、および計算されたデジタル署名を有する各ファイルチャンクとして、ソフトウェア配布を保持する。
【0008】
クライアントプロセッサのリクエストによって、クライアントプロセッサ用にローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよびソフトウェアの期待状態を得るために、クライアントプロセッサは、ソフトウェア配布プロセッサと通信し合う。クライアントプロセッサは、クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、ソフトウェア配布の少なくとも1つのファイルチャンクが必要であるかどうかを決定する。クライアントプロセッサのリクエストによって、少なくとも1つのファイルチャンクは、別のクライアントプロセッサからクライアントプロセッサにローカルエリアネットワークによって転送される。
【0009】
発明の別の実施例は、ソフトウェアアップデートを引き出すためのクライアントワークステーションによって取り組む。ローカルエリアネットワークは、少なくとも1台の他のクライアントワークステーションにクライアントワークステーションを統合することに使用される少なくとも1台の他のクライアントワークステーションにクライアントワークステーションを結合する。広域ネットワークは、ソフトウェア配布サーバにクライアントワークステーションを同期させるために使用されるソフトウェア配布サーバに、クライアントワークステーションを結合する。そして、ソフトウェア配布プロセッサは、1セットのファイルチャンク、構成可能なサイズの各ファイルチャンクおよび計算されたデジタル署名を有する各ファイルチャンクとしてソフトウェア配布を保持する。
【0010】
クライアントアプリケーションは、クライアントワークステーション上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、ソフトウェア配布の少なくとも1つのファイルチャンクが必要であることをクライアントワークステーション内において判定するために、およびクライアントワークステーションのリクエストによってローカルエリアネットワーク上の別のクライアントワークステーションからクライアントワークステーションに少なくとも1つのファイルチャンクを転送するために、ローカルエリアネットワークを介して相互につながれたクライアントワークステーションのリストとクライアントワークステーションのためのソフトウェアの期待状態とを取得するクライアントワークステーションのリクエストによって、ソフトウェア配布プロセッサと通信するためにクライアントワークステーション上で作動する。
【0011】
発明の別の実施例は、コンピュータ読み取り可能な記憶媒体上に格納されたプログラムコードを含むコンピュータ読み取り可能な記憶媒体に取り組む。プログラムコードは、ローカルエリアネットワークを介して相互につながれた、少なくとも1つの他のクライアントプロセッサにクライアントプロセッサを統合するために用いられる。プログラムコードは、広域ネットワークを介して相互につながれたソフトウェア配布プロセッサにクライアントプロセッサを統合させる。そして、ソフトウェア配布プロセッサは、1セットのファイルチャンク、設定可能なサイズの各ファイルチャンク、および計算されたデジタル署名を有する各ファイルチャンクとしてソフトウェア配布を保持する。
【0012】
プログラムコードによって管理されるように、クライアントプロセッサのリクエストによってソフトウェア配布プロセッサとのコミュニケーションは、クライアントプロセッサのためにローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよびソフトウェアの期待状態を得るために遂行される。プログラムコードはまた、クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、ソフトウェア配布の少なくとも1つのファイルチャンクが必要であることをクライアントプロセッサ内において判定することをサポートする。
【0013】
プログラムコードは、さらに、ローカルエリアネットワークを介して、別のクライアントプロセッサからクライアントプロセッサに、クライアントプロセッサのリクエストによって、少なくとも1つのファイルチャンクを転送する。
【0014】
本発明の他の機能および利点と同様に、本発明についてのより十分な理解も、以下の詳細な説明および添付の図面から明白になる。
【発明を実施するための最良の形態】
【0015】
添付図面を参照しながら本願発明について、より十分に記述する。そこでは、本発明のいくつかの実施例と種々相が示される。しかしながら、本発明は様々な形式で具現されることができ、本明細書に記された実施例に限定されるものとして解釈されるべきではない。もっと正確に言えば、この開示が詳細になり完全になるために、これらの実施例が提供され、当業者に発明の範囲を十分に伝えるであろう。
【0016】
図1は、本発明の態様による集中型サーバシステム100を図示している。集中型サーバシステム100は、中央サーバ環境102、リモートサイト104、および第1のネットワークメディア106とともに図示されている。中央サーバ環境102は、中央サーバ108、コンセントレータ/ルーター110、ファイアウォール112、ハブ/スイッチ114、および他の電子機器を含んでいる。他の電子機器は、例えば、中央サーバ108のデータベース116(データベース116はデータベースサーバおよび他のネットワークスイッチを含むことができる)、およびローカルクライアント118を含んでいる。
【0017】
サーバ(例えば中央サーバ108)は、1つ以上のプロセッサ、メモリ、大容量ディスクドライブや高速通信装置のような高容量および高パフォーマンスの入出力装置を有する処理システムであり、キーボード、ディスプレイおよびプリンタを有することができる。コンピュータ読み取り可能な媒体に格納されるようなサーバプログラムは、例えば、磁気、光学、他の型のディスクドライブあるいは不揮発性記憶素子のような記憶メディアからロードされてもよいし、通信装置を通してダウンロードされてもよい。パフォーマンス、容量および、信頼度要求事項を満たすために、中央サーバ108のようなサーバは、サーバのクラスタとしてさらに構成されてもよい。
【0018】
例えば、コンセントレータ、ルーター、ファイアウォール、ハブおよびスイッチは、異なるネットワークあるいはプロセッシングノードの間のデータの流れをコントロールするネットワーク装置であり、仮想プライベートネットワーク(VPN)のサポートをするこができる。ファイアウォールは、不要なコミュニケーションあるいは禁止されたコミュニケーションから、サーバやデータベースのようなネットワークおよびその内蔵装置を保護するために、ネットワークトラフィックのセキュリティポリシーを強化するハードウェア装置および/またはソフトウェアアプリケーションである。データベースは、データベースアクセス機能を提供および支援するデータベースサーバによって各々接続され管理された高容量ディスクドライブの集合から成ってもよい。
【0019】
集中型サーバシステム100は、リモートサイト104のような複数の顧客環境を含む。リモートサイトは、例えば、航空会社環境、ホテル、レンタカー会社、銀行、および中央サーバ環境およびリモートサイトを利用する他のそのような会社を含むことができる。リモートサイトは、1台以上のクライアントワークステーションが配置されるホテル、ショッピング・モール、銀行、大学あるいは総合大学、コーヒーショップのような店、あるいはその他同種のものを適切に象徴することができる。
【0020】
航空会社環境のようなリモートサイト104は、例えば、1つ以上のリモートクライアントプロセッサ120、ハブ/スイッチ122、およびルーター124を含むことができる。リモートサイト104は、さらに、リモートクライアントプロセッサを連結するためのローカルエリアネットワークのような第2のネットワークメディアを含むことができる。クライアントプロセッサは、新規のクライアントプロセッサがローカルエリアネットワークに加えられる場合、およびローカルエリアネットワークが最初にオンラインに導かれる場合に生じることができるような、ローカルエリアネットワーク上に相互につながれた他のクライアントプロセッサに統合される。
【0021】
本発明による、リモートクライアントプロセッサ120の1つのようなワークステーションあるいはキオスク端末装置は、集中型サーバシステム100のユーザと電子的に対話するためのセルフサービス装置である。ワークステーションあるいはキオスク端末装置は、1つ以上のプロセッサ、メモリ、入出力装置、磁気および光ディスク駆動装置のようなストレージシステム、および高速通信装置を有する処理システムを適切に含み、典型的にはキーボード、ディスプレイ、およびプリンタを有する。
【0022】
キオスク端末装置は、乗客予約、航空会社のチェックイン、ホテルの予約およびチェックイン、レンタカーの予約およびピックアップなどのような機能を提供するために調整することができ、またその意図した機能(航空便の乗客のチェックインなど)に助成するあらゆる環境内に配置することができる。ワークステーションプログラムあるいはキオスク端末装置プログラムは、コンピュータ読み取り可能な媒体として、例えば、ディスクドライブあるいは他のそのような不揮発性記憶素子のような記憶メディアからロードされるか、あるいは通信装置を通してダウンロードされてもよい。
【0023】
第1ネットワークメディア106は、フレームリレー網、仮想プライベートネットワーク(VPN:Virtual Private Network)、インターネットなどのような広域ネットワークを含んでもよい。第1ネットワークメディア106は、中央サーバ環境102と、リモートサイト104のような1つ以上のリモートサイトとの間の制御およびデータ通信路を提供する。
【0024】
図2は、本発明の1つの態様による、リモートクライアントに有利にソフトウェアを配布するための典型的なシンクライアントバージョン管理(TCVC:Thin Client Version Control)システム200を図示している。
【0025】
典型的なTCVCシステム200は、TCVCサーバ202、第1のネットワークメディア203、ワークステーション204、ワークステーション206、および第2のネットワークメディア207を含んでいる。TCVCサーバ202は、TCVCサーバアプリケーション208、ファイルリスト210、マスタディレクトリ212、ファイルリストのセキュアハッシュアルゴリズム(SHA:Secure Hash Algorithm)署名214、および登録済みのクライアントノードのリスト216を含む。
【0026】
ワークステーション204は、シンクライアントバージョン管理(TCVC)クライアントアプリケーション220、ファイルリスト222、ステージングディレクトリ(SDIR:Staging Directory)224、プリスティンディレクトリ(PDIR:Pristine Directory)226、ファイルチャンクのSHA署名228、ライブディレクトリ(LDIR:Live
Directory)230、およびアップデートプログラム232を含む。
【0027】
ワークステーション206は、TCVCクライアントアプリケーション240、ファイルリスト242、ステージングディレクトリ(SDIR)244、プリスティンディレクトリ(PDIR)246、ファイルチャンクのSHA署名248、ライブディレクトリ(LDIR)250、およびアップデートプログラム252を含む。
【0028】
第1ネットワークメディア203は、フレームリレー網、仮想プライベートネットワーク(VPN)、インターネットなどのような広域ネットワークを適切に含んでもよい。第2のネットワークメディア207は、ワークステーション206とワークステーション204と、そしてTCVCサーバ202と直接結び付けてもよいし結び付けなくてもよいあらゆる新たなワークステーションとを結び付けるための、ローカルエリアネットワークを含んでもよい。
【0029】
TCVCサーバアプリケーション208は、中央サーバ108のような1つ以上のサーバ上で作動する。中央サーバ108は、個々のリモートクライアントプロセッサ120、キオスク端末装置あるいはワークステーション上で用いられるファイルのマスターリストにアクセスする。TCVCサーバアプリケーション208は、「GetFileList」「GetFileChunk」「GetClientList」のようなトランザクションをサポートする。
【0030】
最新のファイルを有しているかどうか判断するアップデート手続きでは、TCVCクライアントアプリケーション220を実行するワークステーション204のようなワークステーションは、TCVCサーバアプリケーション208に「GetFileList」トランザクションリクエストを送信する。TCVCクライアントアプリケーション220は、入力としてそれが要求しているテーマリストの名前、TCVCクライアントアプリケーション220が作動している遠隔ワークステーションのIPアドレス、および遠隔ワークステーション上のプリスティンディレクトリ(PDIR)224内に現在存在するファイルリスト全体のためのセキュアハッシュアルゴリズム(SHA)署名を送信する。
【0031】
クライアントによって送信されたSHA署名がサーバ上の対応するマスタファイルリストのSHA署名と一致する場合、TCVCサーバアプリケーション208は、クライアントに警報解除信号を送信する。署名が一致しない場合、TCVCサーバアプリケーション208は、マスタファイルリスト署名、関連づけられたSHA署名に加えてマスタファイルリスト内の各ファイルチャンクのリスト、除去処理の間にクライアントによって削除する必要がある如何なるファイル/ディレクトリのリスト、およびファイルチャンクを転送することを試みることができるピアのIPアドレスのリストを、クライアントに通知する。
【0032】
サーバからファイルチャンクをダウンロードしたい場合、アップデート手続きの一部として、TCVCクライアントアプリケーション220は、TCVCサーバアプリケーション208に「GetFileChunk」トランザクションリクエストを送信する。TCVCクライアントアプリケーション220は、入力としてそれが要求しているファイルリストの名前、およびそれが要求しているファイルチャンクのSHA署名を送信する。クライアントによって要求されたファイルチャンクのSHA署名が、現在のサーバ上のいかなるファイルチャンクのSHA署名とも一致する場合、TCVCサーバアプリケーション208はクライアントにファイルチャンクを返す。クライアントによって要求されたファイルチャンクのSHA署名が、現在のサーバ上のどのファイルチャンクのSHA署名とも一致しない場合、TCVCサーバアプリケーション208はエラーを返す。
【0033】
複数のTCVCサーバが1セットの遠隔ワークステーションを供するために設定される場合、「GetClientList」トランザクションは、別のTCVCサーバ(図示せず)によってコールされてもよい。いくつかのサーバ中でロードの安定を保つことを可能にし、かつTCVCサーバの1つがダウンする場合にでさえ、遠隔ワークステーションの活動を可能にするために、複数のTCVCサーバは、中央サーバ108として構成されてもよい。要求するTCVCサーバは、入力としてクライアントリストを要求しているファイルリストの名前を送信する。TCVCサーバアプリケーション208は、TCVCサーバ202により登録されたすべてのクライアントのIPアドレスのリスト、および各TCVCクライアントが最後にTCVCサーバ202とコンタクトした時刻を、応答として送信する。
【0034】
ファイルリスト210は、マスタファイルリストと見なされ、遠隔ワークステーション上で存在する必要があり、TCVCサーバ202上のマスタディレクトリ212内に存在する必要のあるファイルおよびディレクトリのリストを含んでいる。TCVCサーバ202のためのマスタディレクトリ212は、マスタファイルリスト210を構成するファイルおよびディレクトリを含んでいる。ファイルリスト名は、ファイルリストを識別するためのキーである。
【0035】
TCVCサーバ202は、ファイルリスト210の一部であるファイルチャンクのSHA署名を含むファイルリストのSHA署名214を、ディスク上に保存する。ファイルチャンクを判定するために、TCVCサーバ202は、マスタディレクトリ212からファイルチャンクサイズを含むファイルを読み込む。ファイルチャンクサイズ以下のすべてのファイルに関しては、ファイルチャンクはファイル全体を含む。
【0036】
TCVCサーバ202は、ファイルチャンクのためのSHA署名を生成する。ファイルチャンクサイズより大きなすべてのファイルについては、TCVCサーバは、各ファイルを指定されたファイルチャンクサイズのチャンクに論理的に分割し、各ファイルチャンクのSHA署名を生成する。例えば、ファイルチャンクサイズが1024バイトであることが決定しており、ファイルリスト内のファイルが3000バイトのサイズを有している場合、TCVCサーバ202はファイルを3つのファイルチャンクに論理的に分割してもよい。すなわち、1バイト目からスタートするサイズ1024バイトの第1のチャンク、1025バイト目からスタートするサイズ1024バイトの第2のチャンク、および2049バイト目からスタートするサイズ952バイトの第3のチャンクである。
【0037】
ファイルチャンクサイズは設定可能であり、サイズは中央サーバに結合されたクライアントプロセッサの数を考慮に入れる中央サーバに利用可能な推測された広域ネットワーク帯域幅およびそれらの結合帯域幅に依存する。
【0038】
TCVCサーバアプリケーション208は、クライアントがサーバとコンタクトした最終の時刻と同調してTCVCサーバアプリケーション208とコンタクトしたTCVCクライアントのIPアドレスを含む登録済みのクライアントノード216のリストを、ディスク上に保存する。このリストは、ダイナミックに生成され、クライアントがTCVCサーバ202へ「GetFileList」トランザクションを送信するごとに更新される。TCVCサーバアプリケーション208は、要求するクライアントのピアをすべて判定するための「GetFileList」コール中にリスト216を用いる。また、それは「GetClientList」コールの一部としてリスト216を返す。このリスト内に保存されたTCVCクライアントは、もはやアクティブでないクライアントを考慮に入れるために老朽化する。例えば、TCVCクライアントがTCVCサーバアプリケーション208とコンタクトした最終の時刻と現在時刻との間の期間が前もって定義した閾値より大きい場合、TCVCクライアントは、無効であると見なされ、リストから外される。
【0039】
TCVCクライアントアプリケーション220、240のようなTCVCクライアントアプリケーションは、各遠隔ワークステーション上で実行され、TCVCサーバ202のような1つ以上のTCVCサーバと通信するように構成される。例えば、TCVCクライアントアプリケーション220は、TCVCサーバ202からの遠隔ワークステーション上で用いられるファイルのリストを得る。TCVCクライアントアプリケーション220、240は、「GetFileChunk」「CompareNotes」「QueueUpdate」のようなトランザクションをサポートする。
【0040】
別のクライアントからファイルチャンクをダウンロードしたい場合、TCVCクライアントアプリケーション220は、そのアップデート手続きの一部として、別のTCVCクライアントアプリケーション240に「GetFileChunk」トランザクションリクエストを送信する。TCVCクライアントアプリケーション220は、それが要求しているファイルリストの名前、およびそれが要求しているファイルチャンクのSHA署名を送信する。クライアントによって要求されたファイルチャンクのSHA署名が、現在のクライアント上のいかなるファイルチャンクのSHA署名とも一致する場合、TCVCクライアントアプリケーション240は、要求するクライアントにファイルチャンクを返す。クライアントによって要求されたファイルチャンクのSHA署名が、現在のクライアント上のどのファイルチャンクのSHA署名とも一致しない場合、別のTCVCクライアントは、エラーを返す。
【0041】
例えば、TCVCクライアント220上で作動する「CompareNotes」トランザクションは、どのファイルチャンクが既に存在するか、あるいは、サーバによってダウンロードされているか、もしくは別のTCVCクライアント(図示せず)から転送されているかを判定するために、TCVCクライアント240のような第2の要求するTCVCクライアントによってコールされてもよい。要求するクライアント240は、トランザクションへの入力として、情報を望むファイルチャンク署名のリストを送信する。
【0042】
TCVCクライアント220は、TCVCサーバアプリケーション208あるいは他の1つのTCVCクライアントから現在ダウンロードしている、そのファイルチャンク署名およびファイルに対するリストを比較する。TCVCクライアント220は、既にディスク上に存在するリストからのファイルチャンク署名、およびTCVCサーバアプリケーション208あるいは別のクライアントから現在ダウンロードされているものを、要求するTCVCクライアント240に返す。
【0043】
ダウンロードされている各ファイルチャンクについては、TCVCクライアント220は、ダウンロードされることが完結する予定時刻(ETA)、および「1」に設定することでファイルチャンクがTCVCサーバアプリケーション208からダウンロードされていることを示し、「0」に設定することでファイルチャンクが別のクライアントから転送されていることを示すサーバビットを、要求するTCVCクライアント240に返す。既にディスク上にある各ファイルチャンクについては、TCVCクライアント220は、「0」のETAおよび「0」のサーバビットの設定の組み合わせを返す。
【0044】
ワークステーションTCVCクライアント・アップデートの現在の状況を示すために、例えば、TCVCクライアント220上で作動する「QueueUpdate」トランザクションは、ワークステーションユーザの状況要求に応じてコールされる。入力はこのトランザクションに必要ではなく、アイドル状態、サーバへのコンタクト、別のクライアントからのダウンロード、サーバからのダウンロード、スリープ状態、ポスト・ダウンロード・アップデートなどの実行のような、TCVCクライアントの現在の状態を示すHTMLページを、出力として戻す。
【0045】
ワークステーション204は、ファイルリスト222、ステージングディレクトリ(SDIR)224、プリスティンディレクトリ(PDIR)226、ライブディレクトリ(LDIR)230、アップデートプログラム232、ファイルチャンクサイズ、およびサーバアドレスを保存する。ファイルリスト222は、PDIR226内に存在するファイルおよびディレクトリを格納する。ファイルリスト222内には、他のファイルおよびディレクトリ中に含んでいるTCVCクライアントのためのコンフィギュレーションファイル(ファイルリストの名前)がある。ファイルリスト222は、TCVCサーバ202上に存在するファイルリスト210に対応する。
【0046】
プリスティンディレクトリ(PDIR)226は、例えば、TCVCサーバ202上のファイルリスト210に対応して、ファイルリストを構成するテーマおよびディレクトリをすべて保持する。TCVCクライアント220は、PDIR226内のファイルのファイルチャンクのためのSHA署名を生成し、SHA署名のこのリストと、ダウンロードされるためにどのファイルチャンクを必要とするかを判定するための「GetFileList」コール上のTCVCサーバアプリケーション208によって返されたリストとを比較する。
【0047】
PDIR226の中のファイルチャンクはまた、サーバおよび/または他のクライアントからファイルがダウンロードされるステージングディレクトリ(SDIR)224の初期のバージョンを生成するために用いられる。PDIR226がファイルリストの既知のバージョンを保持することを保証するために、ファイルは、PDIR226へ直接ダウンロードされない。ファイルチャンクがすべてステージングディレクトリ224にダウンロードされた場合、ファイルリストはステージングディレクトリ224から削除されてもよいし更新されてもよい。
【0048】
ステージングディレクトリ(SDIR)224は、TCVCサーバアプリケーション208および/または他のTCVCクライアント(例えばTCVCクライアント240)からダウンロードされるファイルおよびディレクトリをすべて保持する。SDIR224は、「GetFileList」コール中にTCVCサーバアプリケーション208によって返されるファイルチャンク署名と一致する署名のPDIR226において、ファイルチャンクを用いて、最初に生成される。TCVCクライアント220によってダウンロードされる他のいずれのファイルも、ステージングディレクトリ224内に保存される。ダウンロードされる必要のあるファイルチャンクが、すべて一旦SDIR224にダウンロードされたならば、プリスティンディレクトリ(PDIR)226は削除され、SDIR224のコンテンツは、新規のPDIR226になるために移動される。
【0049】
TCVCクライアント220は、PDIR226内のファイルチャンクのSHA署名228を、ディスク上に保存する。ファイルチャンクは、TCVCサーバ202内で用いられるような同様の方法で判定される。これらの署名は、ダウンロードされるためにファイルがどれを必要とするかを判定するための「GetFileList」コール中にTCVCサーバアプリケーション208によって返される署名と比較される。
【0050】
ライブディレクトリ(LDIR)230は、ワークステーション204のためのファイルおよびディレクトリをすべて保持するワークステーションディスク上の位置にある。ワークステーション204上で作動する必要のある多くのプログラムは、ライブディレクトリ230からスタートする。一旦ファイルがすべてTCVCクライアント220によってダウンロードされたならば、ライブディレクトリ230から作動するいかなるプログラムも中断され更新される。
【0051】
予定するファイルが一旦すべてダウンロードされたならば、アップデートプログラムファイル232は、更新処理中に実行されるプログラムを含んでいる。これらのアップデートプログラムは、それらがちょうど他のファイルのように更新されることを可能にするファイルリストの一部である。アップデートプログラムは、プリスティンディレクトリ226から実行される。
【0052】
図3は、本発明の態様による、シンクライアントバージョン管理(TCVC)サーバの起動処理300を図示している。図2からの機能要素は、以下の図における対応するステップで引用される。ステップ304で開始し、TCVCサーバアプリケーション208は、そのコンフィギュレーションファイルを読み込む。ステップ306において、TCVCサーバアプリケーション208はファイルリスト名、ライブディレクトリ、およびコンフィギュレーションファイルから得られた情報に基づいてファイルチャンクサイズを決定する。ファイルリスト210は、ライブディレクトリ下のファイルおよびサブディレクトリをすべて含んでいる。
【0053】
ファイルチャンクサイズは、設定可能であり、平均ファイルサイズおよび割り当てられた広域ネットワーク帯域幅に基づく。ステップ308において、TCVCサーバアプリケーション208は、ライブディレクトリ下の各ファイルを読み込む。ステップ3l0において、TCVCサーバアプリケーション208は、本明細書に参考文献として全体を援用するセキュアハッシュ標準の連邦情報処理規格(FIPS:Federal Information Processing Standard)刊行物180−1を満たすセキュアハッシュアルゴリズム(SHA:Secure
Hash Algorithm)署名を算出する。SHA署名も全ファイルリストのために決定される。
【0054】
ステップ312において、TCVCサーバアプリケーション208は、インターネットプロトコル(IP)アドレスのフォーマット内に格納された、登録済みのクライアントノード216のそのリストを読み込む。ステップ314において、TCVCサーバアプリケーション208は、ワークステーション204のようなクライアントとTCVCサーバアプリケーション208との間の通信路のその端部に、サーバソケットを確立する。ステップ316において、TCVCサーバアプリケーション208は、登記済みのクライアントからのハイパーテキスト転送プロトコル(HTTP)リクエストを処理する。
【0055】
図4は、本発明の態様による、第1のクライアントリクエストに応答するための第1の応答サーバ処理400を図示している。ステップ404において、「GetFileList」ハイパーテキスト転送プロトコル(HTTP)ポストリクエストが、ワークステーション204のような登記済みのクライアントから、TCVCサーバアプリケーション208内に受信される。ステップ406において、クライアントのファイルリスト名、IPアドレス、およびファイルリスト署名が、受信されたリクエストから読み込まれる。
【0056】
ステップ408において、クライアントのファイルリスト署名が有効かどうかが判定される。ステップ410において、クライアントのファイルリスト署名が有効でないと判定される場合、リスト内の各ファイルチャンクおよび各ファイルチャンクの署名は、要求するクライアントに返される。クライアントが最新のファイルリストを有しておらずファイルの中で最新のレベルをダウンロードする必要があることを示すので、この判定はエラーとは見なされない。クライアントのリスト署名が有効であると判定される場合、警報解除信号が、ステップ412において、要求するクライアントに返される。
【0057】
図5は、本発明の態様による、第2のクライアントリクエストに応答するための第2の応答サーバ処理500を図示している。ステップ504において、「GetChunk」HTTPポストリクエストが、ワークステーション204のような登録済みのクライアントから受信される。ステップ506において、クライアントのファイルリスト名およびチャンク署名が、受信されたリクエストから読み込まれる。ステップ508において、要求されたファイルチャンクが、TCVCサーバの目録内に存在するかどうかが判定される。ステップ510において、要求されたファイルチャンクがTCVCサーバの目録において見つからない場合、問題が発見したことを示すエラーコードが報告される。ステップ512において、要求されたファイルチャンクは、要求するクライアントに返される。
【0058】
図6は、本発明の態様による、第3のサーバリクエストに応答するための第3の応答サーバ処理600を図示している。ステップ604において、「GetClientList」リクエストが、サーバクラスタ内のTCVCサーバの別の1つから受信される。ステップ606において、各クライアントが最後にサーバとコンタクトした時刻と同調して、すべての登録済みのクライアントのIPアドレスが、要求するTCVCサーバに返される。この情報は、すべてへのTCVCサーバのグループを、ロード・バランシングおよびフォールト・トレラントのセットアップで同じリストを保存することを可能にするために用いられる。
【0059】
図7は、本発明の態様による、TCVCクライアント起動処理700を図示している。
ステップ704において、TCVCクライアント220は、コンフィギュレーションファイルを読み込む。ステップ706において、ファイルリスト、ライブディレクトリ、ステージングディレクトリ、プリスティンディレクトリ(PD)、ファイルチャンクサイズ、およびサーバアドレスの名前が、コンフィギュレーションファイルにおいて読み込まれたデータから決定される。ステップ708において、TCVCクライアント220は、TCVCクライアント220とTCVCサーバ202との間の通信路のその端部に、サーバソケットを確立する。ステップ710において、TCVCクライアント220は、他のTCVCクライアントからのHTTPリクエストを処理する。
【0060】
図8Aは、本発明の態様による、TCVCクライアント更新処理800のパートAを図示している。ステップ804において、プリスティンディレクトリ(PDIR)がまだ存在しない場合、初期のプリスティンディレクトリ(PDIR)226が生成される。ステップ806において、PDIR226内の各ファイルが読み込まれる。ステップ808において、SHA署名が、各ファイルの各チャンク、およびPDIRファイルリスト全体のために計算される。
【0061】
ステップ810において、「GetFileList」HTTPポストリクエストは、そのPDIRファイルリストおよびSHA署名を指定して、TCVCサーバ202のような、クライアントの関連づけられたTCVCサーバへ送信される。ステップ812において、ピアのリスト、およびクライアント上で複製されるファイル署名の正統のリストを含むTCVCサーバ202からのレスポンスが受信される。
【0062】
「正統なリスト」は、現在のサーバ上のすべてのファイルチャンクのリスト、ライブディレクトリに関するディスク上のそれらの位置、およびそれらのSHA署名である。ステップ814において、警報解除信号が受信されたかどうかが判定される。警報解除信号は、クライアントがサーバと同じファイルを有していて、それ以上アクションが必要でないことを示す。警報解除信号が受信されていない場合、処理はステップA816に移る。警報解除信号が受信されている場合、処理800はステップD818に移る。
【0063】
図8Bは、本発明の態様による、TCVCクライアント更新処理800のパートBを図示している。処理800のパートBは、パートAのステップ816から継続する。ステップ822において、ステージングディレクトリは、ステージングディレクトリ(SDIR)224のように、生成される。ステップ824において、あらゆる再使用されたチャンクが、PDIR226からSDIR224にコピーされる。再使用されたチャンクは、受信されたサーバファイル署名簿から決定される。
【0064】
ステップ826において、クライアントにそのチャンクがすべてあるかどうかが判定される。クライアントにそのチャンクがすべてあることが判定される場合、処理800はパートDのステップ818に移る。クライアントにそのチャンクがすべてあるとは限らないことが判定される場合、処理はステップ830に移る。ステップ830において、HTTPポストは、「CompareNotes」トランザクションを要求し、現在必要とするチャンク署名のリスト内を通過する、各ピアのもとへ送信される。
【0065】
ステップ832において、各ピア上に存在するファイルチャンクのリストが、要求するクライアント内から受信される。そのリストと同調して、ファイルチャンクが十分にダウンロードされる時のための到着予定時刻(ETA:Estimated Time of Arrival)、およびチャンクがTCVCサーバからダウンロードされているか別のTCVCクライアントから転送されているかどうか示すビットがある。
【0066】
ステップ834において、ETAがゼロであるチャンクはすべて、要求するクライアントに、例えば、ランダムな順序で、およびランダムなピア所有者から、ダウンロードされる。ピアからの転送のためのピアおよびファイルチャンクは、1つのピアが他のピアからリクエストを過度に負わせられる可能性を減少させるために、好ましくはアトランダムあるいは偽似乱数の方式が選ばれる。その後、処理800は、パートBのステップ836に移る。
【0067】
図8Cは、本発明の態様による、TCVCクライアント更新処理800のパートCを図示している。処理800のパートCは、パートBのステップ836から続行する。ステップ852において、変数Dは、TCVCサーバ202のような、クライアントの関連づけられたサーバから、現在ダウンロードされているチャンクの数を表現するように、計算される。すべてのTCVCクライアントは、ファイルへのアクセスのために、そのコンフィギュレーションファイル内に接続するための指定されたTCVCサーバを有している。
【0068】
変数Dは、アップストリームの帯域幅を推測するために用いられる。ピアからダウンロードするファイルがこれ以上なく、次のファイルがTCVCサーバからダウンロードされる必要があることを示す、ETA=0のすべてのチャンクがすべてのピアからダウンロードされている場合、変数Dが計算される。ステップ854において、変数Dが、設定可能なダウンロード閾値より大きいかどうかが判定される。
【0069】
ダウンロード閾値は、起動時に読み込まれるファイルリスト222内に含まれ、コンフィギュレーションファイル内で指定される。ダウンロード閾値は、クライアントからサーバへのネットワーク帯域幅に基づいて計算される。変数Dが、構成可能なダウンロード閾値より大きいと判定された場合、処理800はステップ864に移る。変数Dが、構成可能なダウンロード閾値以下であると判定された場合、処理はステップ856に移る。
【0070】
ステップ856において、存在しないチャンク、あるいはいかなるピア上でもダウンロードされないチャンクが選択される。ステップ858において、選択されたチャンクは、クライアントからのリクエストに際して、クライアントの関連づけられたサーバからダウンロードされる。この処理は、同じファイルチャンクがTCVCサーバから2度ダウンロードされるのを防ぐために、各クライアントによって追従される。ステップ860において、ダウンロードが成功したかどうかが判定される。
【0071】
ダウンロードが成功した場合、処理800は、図8BのパートBのステップ826に戻すステップ862に移る。一旦ダウンロードが成功裡に終われば、TCVCクライアントは、もう一度各ピアの「CompareNotes」をコールするステップ826に戻る。このステップは、サーバからファイルをダウンロードしている間、どの新規のファイルチャンクが他のピアによってダウンロードされたかを、これらのクライアントにさせる。ダウンロードが成功しなかった場合、処理はステップ864に移る。
【0072】
ステップ864において、要求するクライアントは、最小限必要とされるチャンクETAの110%のスリープモードに置かれる。ファイルチャンクがダウンロードされるまで、他のアクションを行なうことができないので、クライアントは、スリープモードに置かれる。ETAの110%の値は、ダウンロードが完了した後、ピアがSHA署名の計算のようなあらゆる付加的処理を終了することを可能にするように計算される。
【0073】
図8Dは、本発明の態様による、TCVCクライアント更新処理800のパートDを図示している。処理800のパートDは、パートAのステップ818から続行し、ステップ882から開始する。ステップ882において、プリスティンディレクトリ(PDIR)226は削除され、ステージングディレクトリ(SDIR)224のコンテンツは、新規のPDIR226になるために移動される。ステージングディレクトリ224は、ステップ822において、まず生成される。それは、ステップ824におけるPDIR226、およびステージングディレクトリ内に保存されるステップ834および858においてダウンロードされたいかなるファイルからのチャンクにより、更新される。
【0074】
判定ステップ883において、プリスティンディレクトリ(PDIR)内のファイルは、ライブディレクトリ(LDIR)のファイルと比較される。PDIR内のファイルがLDIR内のファイルと一致しない場合、処理800はステップ884に移る。ステップ884において、リモートサイトクライアントは、ライブディレクトリの実行プログラムを中断する。ライブディレクトリは図7ステップ706内で紹介された。それはプログラムが実際に実行されるディレクトリである。ライブディレクトリのプログラムは、プログラムがPDIRからの、より新規のバージョンにより更新される必要があるかもしれないため、実行を止められてもよい。
【0075】
ステップ886において、新規のPDIRは、あらゆる複製のファイルも交換するライブディレクトリにコピーされる。ステップ888において、クライアントの関連づけられたサーバによって指定されるようなライブディレクトリのいかなるファイルも削除するために、クリーンアップパスがなされる。中断されたプログラムは、ステップ888の一部として再開される。サーバは、ステップ812における初期のリクエストの一部として削除されるファイルのリストを送信する。これらのファイルは、もはや用いられないので、削除することができる。一旦クリーンアップパスが完結すれば、ステップ884において中断されたいかなるプログラムも再開されることに留意されたい。
【0076】
判定ステップ883に戻って、プリスティンディレクトリ(PDIR)内のファイルが、ライブディレクトリ(LDIR)のファイルと比較される場合、照合判定に達することができる。PDIR内のファイルがLDIR内のファイルと一致する場合、処理800は、処理800のこのステップが完了していることを示すステップ890に移る。
【0077】
図9は、本発明の態様による、別のクライアントからの第1のリクエストに応答するための、第1のレスポンスクライアント処理900を図示している。ステップ904において、「GetChunk」HTTPリクエストが、別のクライアントから受信される。ステップ906において、チャンクの署名が、受信されたリクエストから読み込まれる。ステップ908において、要求されたチャンクがリクエストを受信するクライアント上に存在する場合、要求されたチャンクが返される。
【0078】
図10は、本発明の態様による、別のクライアントからの第2のリクエストに応答するための、第2のレスポンスクライアント処理1000を図示している。ステップ1004において、「CompareNotes」HTTPリクエストが、別のクライアントから受信される。ステップ1006において、ファイルチャンク署名のリストが、受信されたリクエストから読み込まれる。ステップ1008において、存在する、あるいは、リクエストを受信するクライアントにダウンロードされるファイルチャンクのリストは、ETAと、サーバがチャンクをダウンロードしていることを示すビットとに同調して、要求するクライアントに返される。
【0079】
図11は、本発明の態様による、別のクライアントからの第3のリクエストに応答するための、第3のレスポンスクライアント処理1100を図示している。ステップ1104において、「QueueUpdate」HTTPリクエストが、別のクライアントから受信される。ステップ1106において、アップデートがクライアント上のキューに入れられる。ステップ1108において、アップデートの状況を示すハイパーテキストマークアップ言語(HTML)ページが返される。
【0080】
図12は、本発明の態様による典型的な自動ソフトウェア配布システム1200を図示している。典型的なソフトウェア配布システム1200は、TCVCサーバ1202、キオスク端末装置の第1のセット1204、キオスク端末装置の第2のセット1206、キオスク端末装置の第1のセット1204のサブセットであるキオスク端末装置の第2のセット1206、第1の結合回路網1210、および第2の結合回路網1212を含む。TCVCサーバ1202は、図2のTCVCサーバ202と同様の方法で機能する。
【0081】
キオスク端末装置1204の第1のセット内のキオスク端末装置の各々は、TCVCサーバ1202への第1の結合回路網1210を通して結合パスを持つ。キオスク端末装置1204の第1のセットは、第2の結合回路網1212上で相互に連結されるキオスク端末装置1218〜1223から成る。各キオスク端末装置1218〜1223は、図2のワークステーション204と同様の方法で機能する。第1の結合回路網1210は、フレームリレー網、仮想プライベートネットワーク(VPN)、インターネットなどのような、広域ネットワークであってもよい。第2の結合回路網1212は、ローカルのキオスク端末装置1218〜1223間のローカルの高速接続を提供するために、リモートサイトで作動するローカルエリアネットワークであってもよい。
【0082】
ファイルセット1230は、4つのパーツ1232〜1235に分割される。図3〜図11に記載されていた処理に従って、ファイルセット1230は、キオスク端末装置1206の第2のセットのキオスク端末装置1219〜1222の各々に配布される。配布は、例えば、第1の結合回路網1206を介して遂行される各ダウンロードするとともに、キオスク端末装置1219へパートA1232をダウンロードし、キオスク端末装置1220へパートB1233をダウンロードし、キオスク端末装置1221へパートC1234をダウンロードし、キオスク端末装置1222へパートD1235をダウンロードするクライアントキオスク端末装置のリクエストによって遂行される。
【0083】
各キオスク端末装置1218〜1223がファイルセット1230の複製を持つまで、キオスク端末装置1218〜1223の各々は、それら自身の間の欠けているファイルを適切に転送する。例えば、キオスク端末装置1223はキオスク端末装置1219からパートA1232を受信し、キオスク端末装置1220からパートB1233を受信し、キオスク端末装置1221からパートC1234、およびキオスク端末装置1222からのパートD1235を受信する。すべてのファイル1232〜1235がソフトウェア配布プロセッサからダウンロードされるのを待機せず、転送が利用可能な場合、ファイルチャンク、パートA1232、パートB1233、パートC1234、およびパートD1235は、クライアントプロセッサ1206の第2のセットから転送されることができる。
【0084】
サーバがNクライアントを有しており、Mのファイルリストサイズをホストする場合(Mの50%が新規あるいは変更データで、M/2データが各クライアントに送信される)、転送されたデータの平均値は(M×N)/2である。新規あるいは変更データであってもよいファイルセットからのデータのパーセンテージは、変わってもよい。
【0085】
以下の議論において、Mは各クライアントに送信されるデータの正味量であると仮定される。N=1000のクライアントを有する典型的なシナリオおよびM=100Mバイト(100MB)の各クライアントに送信されるファイルリストにおいて、広域ネットワークは56のキロビット毎秒(kbps)から1.5Mbps以上までの範囲に応じてクライアントからクライアントまで変わるかもしれないと考慮する、大きい転送された量のデータは、(100MB*1000)=100,000MBあるいは100GBになるであろう。本発明のTCVCアプローチを用いて、クライアントがローカルネットワークへ細分されると仮定して、広域ネットワーク(WAN)データ転送は(M×K)に近似する(ここで、Kは厳密にN未満である)。
【0086】
実際上、Kは、帯域幅において大幅な節約を可能にするNと比べて比較的小さい。K=50のローカルネットワークが、1000台のクライアントをサポートするために、現在の具体例に用いられる場合、各ローカルネットワーク当たり20台のクライアントの配布により、WANによって転送されたデータの量は、(100MB×50)=5,000MBあるいは5GB(はるかにより扱いやすい数)である。50個のローカルネットワーク上に5GBを分配することによって、クライアント・ローカルネットワークへの所定のサーバも、具体例において、最小値Mあるいは100MBに近づく。100MBは各ローカルネットワーク内のファイルチャンクへ分割され、すべてあるいは20台のクライアントのサブセットに配布される。
【0087】
その後、100MBのファイルリストが各々のクライアント上で得られるまで、各ローカルネットワーク内の20台のクライアントは、本発明に従って、欠けているファイルチャンクを交換してもよい。節約がメインサーバ接続中の重複データのより少ないコミュニケーションを必要とすることによる、技術はサーバとのコミュニケーションを最小限にする。
【0088】
ここに開示された実施例に関して記述された方法は、ハードウェア、プロセッサによって実行されたソフトウェア、あるいは2つの組み合わせで、直接具現されることができる。ソフトウェアあるいはプログラムコードは、ランダムアクセスメモリ(RAM)、フラッシュメモリ、読み取り専用メモリ(ROM)、電気的なプログラマブル読出専用メモリ(EPROM)、電気的な消去可能なプログラマブル読出専用メモリ(EEPROM)、ハードディスク、リムーバブルディスク、コンパクトディスク読み取り専用メモリ(CDROM)、あるいは当該技術の既知の記憶メディアの他の形式の中に存在してもよい。プロセッサが情報を読み込むことができ、かつ記憶メディアに情報を書き出してもよいように、記憶メディアは、プロセッサに結合されてもよい。
【0089】
本発明は目下好ましい文脈内に開示されているが、この開示と矛盾しない様々な文脈、および後続するクレームに現在の教示が適応してもよいことは認識されるだろう。本発明が、部門のローカルネットワークに内部のイントラネットワークを結合する業務システム、あるいはキオスク端末装置の使用が成熟し発展するようにアプリケーションをサポートした他のセルフサービスキオスク端末装置の広い多様性と同様に、家庭用ローカルネットワークに接続したインターネットにより使用されてもよいことは認識されるであろう。また、使われた特定のハードウェアおよび制御処理におけるバリエーションが実現可能であり、そして双方が時間とともにより発展するように期待されることは認識されるだろう。
【図面の簡単な説明】
【0090】
【図1】本発明の1つの態様による集中型サーバシステムを示す。
【図2】本発明の1つの態様による、リモートクライアントに有利にソフトウェアを配布するための典型的なシンクライアントバージョン管理(TCVC)システムを示す。
【図3】本発明の態様によるTCVCサーバ起動処理を示す。
【図4】本発明の態様による、第1のクライアントリクエストに応答するための第1の応答サーバ処理を示す。
【図5】本発明の態様による、第2のクライアントリクエストに応答するための第2の応答サーバ処理を示す。
【図6】本発明の態様による、第3のクライアントリクエストに応答するための第3の応答サーバ処理を示す。
【図7】本発明の態様によるTCVCクライアント起動処理を示す。
【図8A】本発明の態様による、TCVCクライアント更新処理のパートAを示す。
【図8B】本発明の態様による、TCVCクライアント更新処理のパートBを示す。
【図8C】本発明の態様による、TCVCクライアント更新処理のパートCを示す。
【図8D】本発明の態様による、TCVCクライアント更新処理のパートDを示す。
【図9】本発明の態様による、別のクライアントからの第1のリクエストに応答するための第1の応答クライアント処理を示す。
【図10】本発明の態様による、別のクライアントからの第2のリクエストに応答するための第2の応答クライアント処理を示す。
【図11】本発明の態様による、別のクライアントからの第3のリクエストに応答するための第3の応答クライアント処理を示す。
【図12】本発明の態様による典型的な自動ソフトウェア配布システムを示す。

【特許請求の範囲】
【請求項1】
ローカルエリアネットワークを介して相互につながれた、少なくとも1つの他のクライアントプロセッサに前記クライアントプロセッサを統合するステップと、
広域ネットワークを介して相互につながれたソフトウェア配布プロセッサに前記クライアントプロセッサを統合し、前記ソフトウェア配布プロセッサは、1セットのファイルチャンクと、設定可能なサイズの各ファイルチャンクと、および計算されたデジタル署名とを有する各ファイルチャンクとしてソフトウェア配布を保持するステップと、
前記ローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよび前記クライアントプロセッサ用のソフトウェアの期待状態を得るための前記クライアントプロセッサのリクエストによって、前記ソフトウェア配布プロセッサと通信するステップと、
前記クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、前記ソフトウェア配布の少なくとも1つのファイルチャンクが必要であることを前記クライアントプロセッサ内において判定するステップと、
前記クライアントプロセッサのリクエストによって、前記ローカルエリアネットワーク上の別のクライアントプロセッサから前記クライアントプロセッサに前記少なくとも1つのファイルチャンクを転送するステップと、
の各ステップを含むクライアントプロセッサに対してソフトウェアを自動配布する方法。
【請求項2】
前記少なくとも1つのファイルチャンクが他のクライアントプロセッサの1つから入手可能でない、もしくは他のクライアントプロセッサの1つによってダウンロードされていないということを前記クライアントプロセッサ内において判定し、
前記ソフトウェア配布プロセッサから前記少なくとも1つのファイルチャンクをダウンロードすること
をさらに含む、請求項1に記載の方法。
【請求項3】
前記ソフトウェア配布プロセッサに結合したクライアントプロセッサの数を勘案する前記ソフトウェア配布プロセッサに入手可能な推測された広域ネットワーク帯域幅および前記クライアントプロセッサの結合帯域幅に基づいた各ファイルチャンクの前記設定可能なサイズを判定すること
をさらに含む、請求項1に記載の方法。
【請求項4】
前記ソフトウェア配布プロセッサに配置されたファイルチャンクのマスタファイルリストのデジタル署名と前記クライアントプロセッサ内のファイルチャンクのファイルリストのデジタル署名との比較に基づいたソフトウェアアップデートを前記クライアントプロセッサが必要とするかどうかを判定するクライアントプロセッサから受信された「GetFileList」トランザクションを前記ソフトウェア配布プロセッサ内において処理することをさらに含み、
前記マスタファイルリストは期待状態を表現する、請求項1に記載の方法。
【請求項5】
前記クライアントプロセッサがソフトウェアアップデートを必要とすることを示す前記比較を判定し、
前記マスタファイルリストの前記デジタル署名と、前記マスタファイルリスト内の各ファイルチャンクのリストと、各ファイルチャンクの署名の関連づけと、およびピアクライアントのためのアドレスを結合するリストを通信すること
をさらに含む、請求項4に記載の方法。
【請求項6】
ファイルチャンクのデジタル署名によって識別された前記ファイルチャンクをダウンロードするために、前記クライアントプロセッサから受信した「GetFileChunk」トランザクションを前記ソフトウェア配布プロセッサ内において処理すること
をさらに含む、請求項1に記載の方法。
【請求項7】
少なくとも2つのソフトウェア配布プロセッサ内の仕事量の平衡を保つ目的で、別のソフトウェア配布プロセッサから受信した「GetClientList」トランザクションを前記ソフトウェア配布プロセッサ内において処理すること
をさらに含む、請求項1に記載の方法。
【請求項8】
前記クライアントプロセッサは、
ファイルチャンクを保持し前記クライアントプロセッサ上で動作するソフトウェアの現在状態を保持するプリスティンディレクトリと、前記ファイルチャンクのファイルリストと、
前記ファイルリストのデジタル署名と、各ファイルチャンクのデジタル署名とを備える、請求項1に記載の方法。
【請求項9】
ファイルチャンクの署名によって識別された前記ファイルチャンクを転送するために別のクライアントプロセッサから受信した「GetFileChunk」トランザクションを前記クライアントプロセッサ内において処理すること
をさらに含む、請求項1に記載の方法。
【請求項10】
どのファイルチャンクが、既に存在するか、あるいは、前記ソフトウェア配布プロセッサからダウンロードされているか、あるいは、別のクライアントプロセッサから転送されているかを、判定するために、別のクライアントプロセッサから受信した「CompareNotes」トランザクションを前記クライアントプロセッサ内において処理すること
をさらに含む、請求項1に記載の方法。
【請求項11】
ソフトウェアアップデートを引き出すためのクライアントワークステーションであって、
少なくとも1台の他のクライアントワークステーションに前記クライアントワークステーションを統合することに使用される少なくとも1台の他のクライアントワークステーションに前記クライアントワークステーションを結合するローカルエリアネットワークと、
ソフトウェア配布サーバに前記クライアントワークステーションを同期させるために使用される前記ソフトウェア配布サーバに、前記クライアントワークステーションを結合する広域ネットワークであって、前記ソフトウェア配布プロセッサは、1セットのファイルチャンク、構成可能なサイズの各ファイルチャンクおよび計算されたデジタル署名を有する各ファイルチャンクとしてソフトウェア配布を保持する、前記広域ネットワークと、
前記クライアントワークステーション上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、前記ソフトウェア配布の少なくとも1つのファイルチャンクが必要であることを前記クライアントワークステーション内において判定するために、およびクライアントワークステーションのリクエストによって前記ローカルエリアネットワーク上の別のクライアントワークステーションから前記クライアントワークステーションに前記少なくとも1つのファイルチャンクを転送するために、前記ローカルエリアネットワークを介して相互につながれたクライアントワークステーションのリストと前記クライアントワークステーションのためのソフトウェアの期待状態とを取得する前記クライアントワークステーションのリクエストによって、前記ソフトウェア配布プロセッサと通信するために前記クライアントワークステーション上で作動するクライアントアプリケーションと
を備える、クライアントワークステーション。
【請求項12】
前記クライアントアプリケーションは、
前記少なくとも1つのファイルチャンクが他のクライアントワークステーションの1つから入手可能でないか、あるいは他のクライアントワークステーションの1つによってダウンロードされていないかを前記クライアントワークステーション内において判定し、かつ前記ソフトウェア配布サーバから前記少なくとも1つのファイルチャンクをダウンロードするために作動することをさらに含む、
請求項11に記載のクライアントワークステーション。
【請求項13】
前記クライアントワークステーション上で現在動作しているファイルチャンクのファイルリストを保持するストレージシステムと、ファイルリストおよび前記ファイルチャンクの各々のデジタル署名と、ソフトウェアアップデートを引き出すためのアップデートプログラムと
をさらに含む、請求項11に記載のクライアントワークステーション。
【請求項14】
前記アップデートプログラムは、前記ソフトウェア配布サーバに配置されたファイルチャンクのマスタファイルリストのデジタル署名と前記クライアントワークステーション内のファイルチャンクのファイルリストのデジタル署名との比較に基づいて、前記クライアントワークステーションが最新のファイルを有しているかどうかを判断するための前記ソフトウェア配布サーバ内の「GetFileList」トランザクションを要求するためのサポートを含み、
前記マスタファイルリストは、前記期待状態を表現する、請求項13に記載のクライアントワークステーション。
【請求項15】
前記アップデートプログラムは、ファイルチャンクのデジタル署名によって識別された前記ファイルチャンクをダウンロードするための前記ソフトウェア配布サーバ内の「GetFileChunk」トランザクションを要求するためのサポートを含む、請求項13に記載のクライアントワークステーション。
【請求項16】
前記アップデートプログラムは、前記クライアントワークステーションから、要求するクライアントワークステーションに、ファイルチャンクを転送するために、要求するクライアントワークステーションから受信された「GetFileChunk」トランザクションのサポートを含み、前記ファイルチャンクはファイルチャンクのデジタル署名によって識別される、請求項13に記載のクライアントワークステーション。
【請求項17】
前記アップデートプログラムは、どのファイルチャンクが、前記クライアントワークステーション内に既にあるか、あるいは、前記ソフトウェア配布サーバからダウンロードされているか、あるいは別のクライアントワークステーションから転送されているかを判定するために、要求するクライアントワークステーションから受信された「CompareNotes」トランザクションのサポートを含む、請求項13に記載のクライアントワークステーション。
【請求項18】
コンピュータ読み取り可能な記憶媒体上に格納されたプログラムコードを含む前記コンピュータ読み取り可能な記憶媒体であって、前記プログラムコードは、
ローカルエリアネットワークを介して相互につながれた、少なくとも1つの他のクライアントプロセッサに前記クライアントプロセッサを統合し、
広域ネットワークを介して相互につながれたソフトウェア配布プロセッサに前記クライアントプロセッサを統合し、前記ソフトウェア配布プロセッサは、1セットのファイルチャンク、設定可能なサイズの各ファイルチャンク、および計算されたデジタル署名を有する各ファイルチャンクとしてソフトウェア配布を保持し、
前記ローカルエリアネットワークを介して相互につながれたクライアントプロセッサのリストおよび前記クライアントプロセッサ用のソフトウェアの期待状態を得るための前記クライアントプロセッサのリクエストによって、前記ソフトウェア配布プロセッサと通信し、
前記クライアントプロセッサ上で動作するソフトウェアの現在状態と期待状態との比較に基づいて、前記ソフトウェア配布の少なくとも1つのファイルチャンクが必要であることを前記クライアントプロセッサ内において判定し、
前記クライアントプロセッサのリクエストによって、前記ローカルエリアネットワーク上の別のクライアントプロセッサから前記クライアントプロセッサに前記少なくとも1つのファイルチャンクを転送するためのプログラムコードである、コンピュータ読み取り可能な記憶媒体。
【請求項19】
前記少なくとも1つのファイルチャンクが他のクライアントプロセッサの1つから入手可能でない、もしくは他のクライアントプロセッサの1つによってダウンロードされていないということを前記クライアントプロセッサ内において判定し、
前記ソフトウェア配布プロセッサから前記少なくとも1つのファイルチャンクをダウンロードするためのプログラムコードを
さらに含む、請求項18に記載のコンピュータ読み取り可能な記憶媒体。
【請求項20】
どのファイルチャンクが、既に存在するか、あるいは、前記ソフトウェア配布プロセッサからダウンロードされているか、あるいは、別のクライアントプロセッサから転送されているかを、判定するために、別のクライアントプロセッサから受信した「CompareNotes」トランザクションを前記クライアントプロセッサ内において処理し、
ファイルチャンクの署名によって識別された前記ファイルチャンクを転送するために別のクライアントプロセッサから受信した「GetFileChunk」トランザクションを前記クライアントプロセッサ内において処理するためのプログラムコードを
さらに含む、請求項18に記載のコンピュータ読み取り可能な記憶媒体。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8A】
image rotate

【図8B】
image rotate

【図8C】
image rotate

【図8D】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate


【公開番号】特開2008−159054(P2008−159054A)
【公開日】平成20年7月10日(2008.7.10)
【国際特許分類】
【出願番号】特願2007−327629(P2007−327629)
【出願日】平成19年12月19日(2007.12.19)
【出願人】(391007161)エヌ・シー・アール・コーポレイション (85)
【氏名又は名称原語表記】NCR CORPORATION
【Fターム(参考)】