JP2016535895A

JP2016535895A - ソフトウェア更新方法、システム及びデバイス

Info

Publication number: JP2016535895A
Application number: JP2016533804A
Authority: JP
Inventors: ワンシンハン; ヂャンフゥイ; ルーシァォファン
Original assignee: Chigoo Interactive Technology Co Ltd
Current assignee: Chigoo Interactive Technology Co Ltd
Priority date: 2013-08-12
Filing date: 2014-08-12
Publication date: 2016-11-17
Anticipated expiration: 2034-08-12
Also published as: EP3035642A4; KR20160043020A; US9864595B2; US20160196128A1; JP6444405B2; CN104378391A; EP3035642A1; KR101882426B1; WO2015021905A1

Abstract

【課題】ソフトウェア更新プロセスで伝送速度がＯＴＡサーバーに制約される問題及びデータ伝送が輻輳する問題を解決して、ダウンロードの速度を向上し、同時に多くのデバイスのソフトウェアを更新することができ、多くのデバイスのニーズによって、サーバーが輻輳又は正常に機能しなくなるという問題を防止する。【解決手段】本発明は、ソフトウェア更新方法、デバイス及びシステムを提供する。ソフトウェア更新方法は、クライアントが他のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するステップと、更新ソフトウェアを有するという応答を受信するかどうかを判断して、応答を受信すれば、応答送信クライアントによってローカルのソフトウェアを更新して、応答を受信しなければ、リモートサーバーによってローカルのソフトウェアを更新する。【選択図】図２

Description

本発明は、データ伝送の分野に関し、特に、ソフトウェア更新方法、システム及びデバイスに関するものである。

電子通信技術の発展につれて、いっそう多くの電子デバイスが、日常生活の各々の方面に応用されている。現在、これらの電子デバイスのハードウェア及びソフトウェアの更新プロセスでは、互換性を実現できないので、ユーザーに不便をもたらしている。この問題を解決するために、再構成可能なデバイス（ＲｅｃｏｎｆｉｇｕｒａｂｌｅＤｅｖｉｃｅｓ）技術が提案されている。再構成可能なデバイス技術を実現するプロセスで、ハードウェアを改善するために、ソフトウェアの支持に基くことが必要とされる。再支持再構成可能なデバイスのハードウェアは、ＦＰＧＡ又はｒＤＰＡプロセッサを含む。これらのプロセッサは、プログラミングによって、その機能を調整することができる。

ソフトウェアの再構成は、ハードウェアの多くの機能を実現するのに効果的な方法である。通常の操作方式は、コーディングできたソフトウェアをサーバーにインストールして、再構成可能デバイスがサーバーから該ソフトウェアをダウンロードして更新することである。ダウンロードは、有線及び無線という二種類の方式によって行うことができる。スマートフォンが広く応用されているので、クラウドアプリ（Ｏｖｅｒ−Ｔｈｅ−Ａｉｒ：ＯＴＡ）を利用することが、主な方式になる。クラウドアプリには多くの利点があるので、世界の幾つかの主な機関が形成されたＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ（ＯＭＡ）と呼ばれる作業グループによって、クラウドアプリの技術標準が制定された。制定された標準のＯＭＡＤＭ（ＤｅｖｉｃｅＭａｎａｇｅｍｅｎｔ）は、ＩＢＭ、マイクロソフト、Ｍｏｔｉｖｅ及びその他のメーカーに採用されている。統計によると、最近に発行された移動デバイスで、８０％のファームウェアが再構成可能である。ＯＭＡＤＭは、ソフトウェアをダウンロードして更新すること、ソフトウェアのエラーを修正することに用いられるだけではなく、乗物を管理すること、デバイスの信号を監視すること、及び、品質を制御することに用いられる。近年、設計者は、ＯＭＡＤＭの性能を高めるために、例えば、新しい管理エージェント（ｍａｎａｇｅｍｅｎｔａｇｅｎｔ）などを設計する多くの仕事をしている。これらの全ての方法は、いずれも従来のクライアント／サーバーのモデルに基づいている。このモデルは、多くのデバイスにソフトウェアのダウンロード及び更新を同時に提供することには適していない。

中国国内のＯＴＡに関係がある特許は、主に四つの態様に集中していて、それぞれ、ＯＴＡ技術の新しい方法、ＯＴＡ実現の新しい方法、ＯＴＡの応用及びＯＴＡのテストである。

中国特許出願公開第ＣＮ１０１２４７４６１号明細書（CN101247461）に公開された「ＯＴＡに基づくファームウェアのダウンロード方法、前処理方法、完全性検証方法」では、ファームウェアのダウンロードの前処理方法、ファームウェアの完全性検証方法及びファームウェアのダウンロード方法を提案するが、やはり従来のクライアント／サーバーのモデルに基づくものである。

中国特許出願公開第ＣＮ１０２６２５２８８号明細書（CN102625288）の「マルチプロセッサ端末のクラウドアプリの方法及びマルチプロセッサ端末」には、マルチプロセッサ端末のクラウドアプリの方法及びマルチプロセッサ端末が開示されている。マルチプロセッサ端末は、アプリケーションプロセッサＡＰ、通信プロセッサＣＰ、汎用集積回路カード（ＵＩＣＣ）を含む。その中で、ＡＰがＵＩＣＣ及びＯＴＡサーバーの中継ステーションを引き受ける。ＵＩＣＣがクラウドアプリのＯＴＡサーバーにデータのダウンロード要求を出す時、データのダウンロード要求をＡＰに送信し、ＡＰがデータのダウンロード要求を受信した後、データのダウンロード要求をＯＴＡサーバーに送信し、ＡＰはＯＴＡサーバーがデータのダウンロード要求に応答するために送信された応答データを受信して、該応答データをＵＩＣＣに送信し、データのダウンロードを実現するようになる。この文献は、ＡＰによって、ＯＴＡサーバーとＵＩＣＣとの間でデータの交換をして、ＯＴＡによるダウンロード速度を向上できる。この方案は、従来のクライアント／サーバーのモデルを超えるものであり、ＯＴＡによるダウンロード効率を向上できる。

しかしながら、これらの方法及び公開特許文献と発表された研究論文とに開示されたＯＴＡによるダウンロード方法は、やはり、直接あるいは間接にＯＴＡサーバーからソフトウェアをダウンロードするので、ＯＴＡサーバーに高い要求を出すと、その性能と処理、及び、データ伝送速度は、直接各々のクライアントの使用に影響を与え、ユーザーが非常に多く、かつ、処理しようとするデータ容量が大きい場合は、この種の従来技術はユーザーを満足させることができない。

上記の従来のデータ及びソフトウェア更新方法は、ＯＴＡサーバーとデータ交換を行うことによって実現されるので、サービス端末の数が多く、データ伝送の量が多く、クライアントの要求が密集する場合には、各々のサービス端末のユーザーのニーズを満足することができない。また、インターネットに対して大量の同じデータを伝送する場合にも、システムでデータ伝送の資源を浪費するので、使用コストを向上するという問題を引き起こす。

そこで、本発明の目的の一つは、ソフトウェア更新プロセスで伝送速度がＯＴＡサーバーに制約される問題及びデータ伝送が渋滯する問題を解決することである。

上記課題を解決するために、本発明の一つの態様は、ソフトウェア更新方法を提供する。該ソフトウェア更新方法は、複数のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するステップと、更新ソフトウェア情報を含む応答情報を送信するクライアントがあるかどうかを判断して、前記応答情報を送信するクライアントがあれば、前記応答情報を送信するクライアントによって他のクライアントのローカルのソフトウェアを更新して、応答情報を送信するクライアントがなければ、リモートサーバーによってローカルのソフトウェアを更新するステップとを含む。

ある実施形態では、クライアントにＤＬエージェント及びＣＩＣ（中央情報コントローラ）モジュールを設け、クライアントがローカルのソフトウェアを更新する時、ＤＬエージェントがＣＩＣモジュールに要求を出し、ＣＩＣモジュールがローカルの更新ソフトウェアのブロードキャスト情報を送信し、応答送信クライアントを登録及び管理して、ソフトウェアをダウンロードして更新方式を確定させて、ＤＬエージェントが、ＣＩＣモジュールで確定されたソフトウェアをダウンロードして更新方式によって、対応するクライアント又はサーバーと接続して、ソフトウェアのダウンロード及び更新を行う。

本発明のもう一つの態様は、ソフトウェア更新システムを提供する。該ソフトウェア更新システムは、ブロードキャスト送信ユニット及び更新ユニットを含む。ブロードキャスト送信ユニットは、複数のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するように設定される。更新ユニットは、更新ソフトウェアを有するという応答送信クライアントが存在するかどうかを判断するように設定され、更新ソフトウェアを有するという応答送信クライアントが存在すれば、応答送信クライアントによってローカルのソフトウェアを更新し、更新ソフトウェアを有するという応答送信クライアントが存在しなければ、リモートサーバーによってローカルのソフトウェアを更新する。

本発明のもう一つの態様は、ソフトウェア更新デバイスを提供する。該ソフトウェア更新デバイスは、送信モジュールと更新モジュールとを含む。送信モジュールは、他のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するように設定される。更新モジュールは、更新ソフトウェア有するという応答を受信するかどうかを判断するように設定され、応答を受信すれば、応答送信クライアントによってローカルのソフトウェアを更新して、応答を受信しなければ、リモートサーバーによってローカルのソフトウェアを更新する。

上記方式の優れた点は、一定の地域範囲で、クライアントを互いに交流させることによって、ソフトウェアの記憶情報を確認することである。あるクライアントは、他のクライアントに必要としているソフトウェアが記憶されている時には、該クライアントからダウンロードする。そうでない時には、ＯＴＡサーバーからダウンロードする。この非集中のダウンロード方式を利用すれば、デバイスは、更新ソフトウェアを、サーバーからダウンロードこともできるし、近接するノードからダウンロードすることもできる。これによって、ダウンロードの速度を向上でき、同時に多くのデバイスのソフトウェアを更新することができ、多くのデバイスからの要求によって、サーバーが輻輳する又は正常に機能しなくなるという問題を回避することができる。

当業者は、本発明の方法は、ソフトウェアの更新を対象としているが、実際には、デバイスに存在しない新しいソフトウェアをダウンロードしてインストールすることに用いることにもできるということを理解できる。従って、本明細書に記載された「ソフトウェア更新」とは、「古いソフトウェアを更新する」ことも含まれるし、「新しいソフトウェアをダウンロードする」ことも含まれる。

本発明の実施形態におけるソフトウェア更新方法のフローチャートである。本発明の実施形態における非集中のダウンロードを示す図である。本発明の実施形態におけるクライアントデバイスにエージェントのプログラミングレベルを示す図である。本発明の実施形態におけるＦＵＭＯエージェントモジュールの設計を示す図である。本発明の実施形態におけるＤＬＡｇｅｎｔエージェントモジュールの設計を示す図である。本発明の実施形態におけるＣＩＣモジュールの設計を示す図である。本発明の実施形態におけるソフトウェア更新システムの構成を示す図である。本発明の実施形態におけるソフトウェア更新デバイスの構成を示す図である。

以下、図面及び実施例を参照して、本発明の具体的な実施形態について詳しく説明する。

図１は、本発明の実施形態におけるソフトウェア更新方法のフローチャートである。該ソフトウェア更新方法は、以下のステップを含む。

ステップＳ１０１：更新ソフトウェアのブロードキャスト情報を送信する。該ステップでは、クライアントのＣＩＣは、クライアントのＣＩＣ自体が更新ソフトウェアのブロードキャスト情報を、近接する複数のクライアントに送信する。該ブロードキャスト情報は、ソフトウェアのタイトル及びソフトウェアのバージョン情報を含む。

ステップＳ１０２：ローカルのソフトウェアの更新を行う。近接するクライアントのＣＩＣは、該ＣＩＣのブロードキャスト情報を受信した後に、直ちに応答する。ブロードキャスト情報送信クライアントのＣＩＣは、応答情報を受信すると、その応答情報から、どのクライアントデバイスが、自デバイスにとって必要なソフトウェアを記憶しているかを探し、該デバイスのＩＤを登録して、該デバイスに記憶されたソフトウェアの情報を得ることでき、該ＩＤによって該デバイスと交流する。その後、該デバイスにソフトウェアのダウンロード要求を送信して、デバイスがダウンロード要求を確認した後、直接、ダウンロードする。受信した応答情報に必要としているソフトウェアが含まれていなければ、ブロードキャスト情報送信クライアントがＯＴＡサーバーに直接連絡して、従来の方法によって、サーバーから更新ソフトウェアをダウンロードする。

ステップＳ１０２において、応答送信クライアントによってローカルのソフトウェアを更新するステップは、応答送信クライアントのアドレスを、ローカルのクライアントのソフトウェアの読み取りリストに登録して、ローカルのクライアントのソフトウェアの読み取りリストによって、ローカルのソフトウェアを更新することを含む。

応答送信クライアントによってローカルのソフトウェアを更新するステップは、更に、応答送信クライアントの数が複数であるかどうかを判断する。複数であれば、複数の応答送信クライアントの負荷によって、低負荷の応答送信クライアントを確定して、低負荷の応答送信クライアントによってローカルのソフトウェアを更新して、応答送信クライアントの数が一つだけであれば、応答送信クライアントによってローカルのソフトウェアを更新することを含む。

上記の複数の応答送信クライアントの負荷によって、低負荷の応答送信クライアントを確定するステップは、データの流量及びノードの容量を測定することによって、複数の応答送信クライアントの中から最高のデータ交換速度のものを得て、最高のデータ交換速度に対応する応答送信クライアントを、低負荷の応答送信クライアントとして確定する。これによって、更新ソフトウェアを有する応答送信クライアントの数が複数である場合に、応答送信クライアントの負荷によって、ダウンロードするクライアントを選択することができ、クライアント間の負荷のバランスを最適化する。

本実施形態では、従来のクライアント／サーバーのモデルと提案された非集中のモデルとの二種のダウンロード方式を結合する。本実施形態におけるダウンロード方法は、図２に示すようになる。クライアントデバイスに、ＤＬエージェントと称される新しいモジュールを設ける。ＤＬエージェント、ＤＭエージェント及びＦＵＭＯエージェントのうち幾つかのモジュールは、クライアントデバイスの中で共存している。実際の状況によって、ダウンロードの方式を選択することができる。

ＤＬエージェントには、ＣＩＣ（ＣｅｎｔｒａｌＩｎｆｏｒｍａｔｉｏｎＣｏｎｔｒｏｌｌｅｒ：中央情報コントローラ）モジュールを設ける。該モジュールは、他のクライアントデバイスのＣＩＣモジュールと交流することによって、クライアントデバイス間でのソフトウェアのダウンロードを実現する。ＣＩＣモジュールは、デバイスの中のソフトウェアの情報を記録して、他のクライアントデバイスに情報を送信して、ソフトウェアのダウンロードを管理する。

一つのクライアントデバイスがソフトウェアを更新する時、まず情報をブロードキャストする方式で、地域のネットワーク内の他のデバイスのＣＩＣモジュールに要求を出す。あるデバイスのＣＩＣモジュールの中に、必要としているソフトウェアが存在するならば、要求を出したデバイスは、該ソフトウェアを有するデバイスと連絡をとって、該ソフトウェアを有するデバイスから必要としているソフトウェアをダウンロードする。地域のネットワークの中のクライアントが必要としているソフトウェアがなければ、該デバイスがサーバーに接続して、サーバーからソフトウェアをダウンロードする。ここで、クライアントからソフトウェアをダウンロードする方式、及び、サーバーからソフトウェアをダウンロードする方式は、通常の手段であり、詳しく説明しない。

一つのデバイスがある区域を離れると（例えば、該デバイスとの無線接続が切断されることによって判定する）、該デバイスが持つ関連ソフトウェアの情報は、他のデバイスのＣＩＣモジュールから削除される。

以下、クライアントデバイスにおける、エージェントの実現方式を詳しく説明する。プログラミングから見れば、クライアントの論理設計は四つのレベルに分けられる。図３に示すように、頂部から底部まで、それぞれアプリケーション層、ＤＭコア層、ハードウェア抽象層及びオペレーションシステムである。

本発明の主要部は、アプリケーション層及びＤＭコア層で実現される。ハードウェア抽象層及びオペレーションシステムは、通常の基礎構造が採用されている。携帯電話の例では、携帯電話のハードウェア、Ａｎｄｒｏｉｄシステム、ｉＯＳなどが、実行されるアプリケーションソフトに操作環境を提供する。各々のシステムで別のソフトウェア開発が行われても、方法自体に影響を与えない。当業者であれば、ここで説明された本発明の方法に対して、通常の手段を用いて、異なるハードウェアとオペレーションシステムを実装することができる。従って、本明細書では、ハードウェア抽象層とオペレーションシステムという二つの部分は説明しない。

アプリケーション層は、ソフトウェアが更新される時の管理操作を直接行う。ＤＭコア層から操作指令を受信して、指定の管理操作を実現する。例えば、ソフトウェアをダウンロードし、更新することなどである。また、ＤＭコア層に操作結果を返送して、更なる処理を行うことになる。その後、その結果をサーバーに送信することができる。ＦＵＭＯ（ＦｉｒｍｗａｒｅＵｐｄａｔｅＭａｎａｇｅｍｅｎｔＯｂｊｅｃｔ：ファームウェア更新管理オブジェクト）エージェント及びＤＬエージェントは、アプリケーション層にある。

ここで、ＦＵＭＯエージェントは、ＯＭＡＤＭでファームウェアをダウンロードして更新するコアモジュールであり、標準化の固有のモジュールである。ＦＵＭＯエージェントは、主に二つのパッケージ、即ち、ｄｍ．ｃｌｉｅｎｔ．ｄｏｗｎｌｏａｄｍａｎａｇｅｒとｄｍ．ｃｌｉｅｎｔ．ｕｐｄａｔｅｍａｎａｇｅｒからなる。

ｄｍ．ｃｌｉｅｎｔ．ｄｏｗｎｌｏａｄｍａｎａｇｅｒは、ＤＭコア層で解析されたソフトウェアの更新を処理して、ＤＬエージェントとともにソフトウェアのダウンロードを管理することを担う。従来のクライアント／サーバーのダウンロード方式を採用する場合には、そのソフトウェアのダウンロードも担う。ｄｍ．ｃｌｉｅｎｔ．ｕｐｄａｔｅｍａｎａｇｅｒは、主にソフトウェアの更新を担う。図４は、これらの二つのパッケージの詳しい設計が示す。これらは、通常の設計であり、ここで詳しく説明しない。

ＤＬエージェントは、本発明で提案されたソフトウェアのダウンロードメカニズムであり、ＦＵＭＯエージェントと協同作業をして、さまざまな状況でソフトウェアのダウンロードを実現する。ＤＬエージェントは、ここでは管理者の役割を果たしており、各々のモジュールと連絡し、協調して調整することを担う、システムにおける既存のダウンロードの管理モジュールを含む。それは、ＣＩＣの中の情報によって、どの方法でソフトウェアをダウンロードするかを確定させる。従って、ＤＬエージェントは、ＣＩＣと通信する能力を有し、関連ソフトウェアの情報を得ることになる。また、近接するクライアントからソフトウェアをダウンロードすることができる。ＤＬエージェントは、一つのパッケージで実現しており、ｄｍ．ｃｌｉｅｎｔ．ｄｌａｇｅｎｔと称される。ｄｍ．ｃｌｉｅｎｔ．ｄｌａｇｅｎｔは、代表的な五つの違う機能のタイプからなる。

ＤｌＭａｎａｇｅｒのタイプは、ＤＬエージェントの主要部であり、それが他のタイプの操作を管理することを担って、ＦＵＭＯエージェントにどのダウンロードの方法を採用するかを知らせる。

ＲｓｐｆｏｒＳｗＲＱのタイプは、ＣＩＣからソフトウェアの情報を得るために用いられる。

ＤｌＭｅｔｈｏｄＤｅｃｉｄｅｒのタイプは、ＣＩＣから得られた情報によって、どのダウンロードの方法を採用するかを決める。

Ｃｏｍｍｕｎｉｃａｔｉｏｎのタイプは、ＤＬエージェントを実現すること、及び、他のデバイスと通信することを担う。

ｄｅｃｅｎｔｒａｌｉｚｅｄＤｏｗｎｌｏａｄｅｒのタイプは、非集中のダウンロード（他のクライアントからダウンロードする）する時のソフトウェアのダウンロードを担う。

各々のタイプの詳しい設計図は、図５に示されている。ＣＩＣは、ダウンロード方法を決めるコントロールセンターである。プログラミングから見れば、五つの異なる機能、即ち、Ｂｒｏａｄｃａｓｔ（ブロードキャスト）、Ｒｅｇｉｓｔｅｒ（登録）、ＤｅｖｉｃｅＭａｎａｇｅｒ（デバイス管理）、ＳｏｆｔｗａｒｅＭａｎａｇｅｒ（ソフトウェア管理）及びＣｏｍｍｕｎｉｃａｔｉｏｎ（通信）を実現するために、五種類からなる。詳しい設計は、図６に示されている。

ここで、Ｂｒｏａｄｃａｓｔは、Ｒｅｑ４ＳＷを用いて、近接するクライアントに要求するソフトウェアをブロードキャストする。近接するクライアントデバイスが、このソフトウェアを有していれば、Ｒｅｑ４Ｒｅｇｉｓｔｅｒを用いてデバイスとソフトウェアの情報とをＣＩＣに返送する。ＣＩＣは、ＲｅｇｉｓｔｅｒモジュールのＡｄｄＤｅｖ機能を用いて、該デバイスを登録する。登録した後、ＣＩＣはＤｅｖｉｃｅＭａｎａｇｅｒ及びＳｏｆｔｗａｒｅＭａｎａｇｅｒを用いて、所定のデバイス及びソフトウェアを管理する。例えば、ソフトウェア管理の例としては、登録すること、ソフトウェアの情報を取り消すこと、ソフトウェアのタイトルを得ること、及び、ソフトウェアを得ることなどを含む。

あるデバイスがソフトウェアを更新する時、Ｃｏｍｍｕｎｉｃａｔｉｏｎを用いてＣＩＣモジュールに要求情報を送信する。ＣＩＣモジュールは、該要求に応答して、Ｒｅｇｉｓｔｅｒに更新ソフトウェアに関連する情報（例えば、タイトルとバージョン番号）を見つけると、要求送信デバイスに知らせ、要求送信デバイスが更新ソフトウェアを有するデバイスに直接接続して、ＤＬエージェントによって、ソフトウェアをダウンロードして更新する。ＣＩＣは、関連情報がなければ、要求送信デバイスがコンテンツサーバーと通信して、従来のＯＭＡＤＭのダウンロード方法を採用して、ＦＵＭＯエージェントによってソフトウェアをダウンロードして更新する。

図７は、本発明の実施形態におけるソフトウェア更新システムの構成を示す図である。該ソフトウェア更新システムは、ブロードキャスト送信ユニット２０１及び更新ユニット２０２を含む。ブロードキャスト送信ユニット２０１は、他のクライアントにローカルの更新ソフトウェアというブロードキャスト情報を送信するために用いられる。更新ユニット２０２は、更新ソフトウェアがあるという応答を受信するかどうかを判断することに用いられ、応答を受信すれば、応答送信クライアントによってローカルのソフトウェアを更新して、応答を受信しなければ、リモートサーバーによってローカルのソフトウェアを更新する。

また、更新ユニット２０２は、更に、応答送信クライアントのアドレスをローカルのクライアントのソフトウェアの読み取りリストに登録して、ローカルのクライアントのソフトウェアの読み取りリストによって、ローカルのソフトウェアを更新するために用いられる。

応答送信クライアントの数が複数である時、更新ユニット２０２は、前記応答送信クライアントの数が複数であるかどうかを判断するためにも用いられる。複数であれば、複数の応答送信クライアントの負荷によって、低負荷の応答送信クライアントを確定し、低負荷の応答送信クライアントによってローカルのソフトウェアを更新し、複数でなければ、応答送信クライアントによってローカルのソフトウェアを更新する。複数の応答送信クライアントの中の最高のデータ交換速度を得て、最高のデータ交換速度に対応する応答送信クライアントを低負荷の応答送信クライアントとして確定する。

図８は、本発明の実施形態におけるソフトウェア更新デバイスの構成を示す。該ソフトウェア更新デバイスは、送信モジュール３０１と更新モジュール３０２とを含む。

送信モジュール３０１は、他のクライアントにローカルの更新ソフトウェアというブロードキャスト情報を送信するために用いられる。

更新モジュール３０２は、更新ソフトウェアがあるという応答を受信するかどうかを判断して、応答を受信すれば、応答送信クライアントによってローカルのソフトウェアを更新して、応答を受信しなければ、リモートサーバーによってローカルのソフトウェアを更新する。

更新モジュール３０２は、更に登録モジュール３０２１及び通信ダウンロードモジュール３０２２を含む。

登録モジュール３０２１は、応答送信クライアントのアドレスをローカルのクライアントのソフトウェアの読み取りリストに登録する。

通信ダウンロードモジュール３０２２は、ローカルのクライアントのソフトウェアの読み取りリストによって、ローカルのソフトウェアを更新する。

このデバイスは、更にデバイス管理モジュール３０３及びソフトウェア管理モジュール３０４を含む。デバイス管理モジュール３０３は、応答送信クライアントデバイスの情報を生成する。ソフトウェア管理モジュール３０４は、更新ソフトウェアのタイトル、バージョン及び容量の情報を生成する。

該デバイスの具体的な作動方式は、上記のソフトウェア更新方法の実施形態に述べる通りであり、詳しく説明しない。

上記は、本発明の幾つの具体的な実施形態についての説明である。本発明は、この実施形態に限定されるべきではない。当業者は、本発明の実質及び精神から遊離しない範囲において、様々な変形や変更を行なうことができ、これらは本発明の保護範囲に属する。

Claims

複数のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するステップと、
応答情報を送信するクライアントがあるかどうかを判断して、更新ソフトウェアを有する情報を含む応答情報を送信するクライアントがあれば、前記応答送信クライアントによって他のクライアントのローカルのソフトウェアを更新して、応答情報を送信するクライアントがなければ、リモートサーバーによってローカルのソフトウェアを更新するステップとを、
含むことを特徴とするソフトウェア更新方法。
前記応答送信クライアントによってローカルのソフトウェアを更新するステップは、更に、
前記応答送信クライアントのアドレスをローカルのクライアントのソフトウェアの読み取りリストに登録するステップと、
前記ローカルのクライアントのソフトウェアの読み取りリストによってローカルのソフトウェアを更新するステップとを、
含むことを特徴とする、請求項１に記載のソフトウェア更新方法。
前記応答送信クライアントによってローカルのソフトウェアを更新するステップは、更に、
前記応答送信クライアントの数が複数であるかどうかを判断して、複数であれば、複数の応答送信クライアントの負荷によって、低負荷の応答送信クライアントを確定し、低負荷の応答送信クライアントによってローカルのソフトウェアを更新し、複数でなければ、前記応答送信クライアントによってローカルのソフトウェアを更新することを含むことを特徴とする、請求項１又は請求項２に記載のソフトウェア更新方法。
前記複数の応答送信クライアントの負荷によって、低負荷の応答送信クライアントを確定するステップは、
複数の応答送信クライアントの中から最高のデータ交換速度のものを得て、最高のデータ交換速度に対応する応答送信クライアントを、低負荷の応答送信クライアントとして確定することを含むことを特徴とする、請求項３に記載のソフトウェア更新方法。
前記クライアントにＤＬエージェント及びＣＩＣモジュールを設け、
前記クライアントがローカルのソフトウェアを更新する時、前記ＤＬエージェントは、ＣＩＣモジュールに要求を出すステップと、
前記ＣＩＣモジュールがローカルの更新ソフトウェアのブロードキャスト情報を送信し、応答送信クライアントを登録及び管理して、登録された応答送信クライアントの情報によって、ソフトウェアをダウンロードして更新する方式を確定するステップと、
前記ＤＬエージェントは、前記ＣＩＣモジュールで確定されたソフトウェアをダウンロードして更新する方式によって、対応するクライアント又はサーバーと接続して、ソフトウェアのダウンロード及び更新を行うステップとを、
含むことを特徴とする、請求項１〜４のいずれかの一項に記載のソフトウェア更新方法。
ブロードキャスト送信ユニット及び更新ユニットを含むソフトウェア更新システムにおいて、
前記ブロードキャスト送信ユニットは、複数のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するように設定され、
前記更新ユニットは、更新ソフトウェアを有するという応答送信クライアントがあるかどうかを判断するように設定され、更新ソフトウェアがあるという応答送信クライアントがあれば、前記応答送信クライアントによってローカルのソフトウェアを更新して、更新ソフトウェアがあるという応答送信クライアントがなければ、リモートサーバーによってローカルのソフトウェアを更新することを特徴とするソフトウェア更新システム。
前記更新ユニットは、前記応答送信クライアントのアドレスをローカルのクライアントのソフトウェアの読み取りリストに登録し、ローカルのクライアントのソフトウェアの読み取りリストによって、ローカルのソフトウェアを更新するように設定されることを特徴とする、請求項６に記載のソフトウェア更新システム。
前記更新ユニットは、前記応答送信クライアントの数が複数であるかどうかを判断するように設定され、複数であれば、複数の応答送信クライアントの負荷によって、低負荷の応答送信クライアントを確定して、低負荷の応答送信クライアントによってローカルのソフトウェアを更新し、複数でなければ、応答送信クライアントによってローカルのソフトウェアを更新することを特徴とする、請求項６又は請求項７に記載のソフトウェア更新システム。
前記更新ユニットは、複数の応答送信クライアントの中から最高のデータ交換速度のものを得て、最高のデータ交換速度に対応する応答送信クライアントを、低負荷の応答送信クライアントとして確定するように設定されることを特徴とする、請求項８に記載のソフトウェア更新システム。
送信モジュールと更新モジュールとを含むソフトウェア更新デバイスにおいて、
前記送信モジュールは、他のクライアントにローカルの更新ソフトウェアのブロードキャスト情報を送信するように設定され、
前記更新モジュールは、更新ソフトウェアを有するという応答を受信するかどうかを判断するように設定され、応答を受信すれば、前記応答送信クライアントによってローカルのソフトウェアを更新し、応答を受信しなければ、リモートサーバーによってローカルのソフトウェアを更新することを特徴とするソフトウェア更新デバイス。
前記更新モジュールは、更に登録モジュール及び通信ダウンロードモジュールを含み、
前記登録モジュールは、前記応答送信クライアントのアドレスをローカルのクライアントのソフトウェアの読み取りリストに登録するように設定され、
前記通信ダウンロードモジュールは、ローカルのクライアントのソフトウェアの読み取りリストによってローカルのソフトウェアを更新するように設定されることを特徴とする、請求項１０に記載のソフトウェア更新デバイス。
デバイス管理モジュール及びソフトウェア管理モジュールを更に含み、
前記デバイス管理モジュールは、前記応答送信クライアントのデバイスの情報を生成するように設置され、
前記ソフトウェア管理モジュールは、更新ソフトウェアのタイトル、バージョン及び容量の情報を生成するように設置されることを特徴とする、請求項１０又は請求項１１に記載のソフトウェア更新デバイス。