JP2010231781A - Ｕｒｌを利用した分散コントロール方法及び装置 - Google Patents

Abstract

【課題】 ＵＲＬを利用した分散コントロール方法及び装置を提供する。
【解決手段】 クライアントについての少なくとも一つ以上の特性情報を第１サーバーに登録するステップと、クライアントの登録された特性情報に基づいて、ＵＲＬフォーマットのアドレスを生成するステップと、第１サーバーから複製されたデータを保存する少なくとも一つ以上の第２サーバーから、ＵＲＬアドレスを利用してデータを獲得するステップと、を含む分散コントロール方法である。
【選択図】 図１

Description

本発明は、分散ネットワーク環境でＵＲＬを利用した分散コントロール方法及び装置に関する。

特許文献１には、ＵＲＬを利用してリソースを獲得する方法が開示されている。

最近、インターネット技術の成長と共に、ＣＥ（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃ）機器も急速に発展していくインターネット技術と融合されて、サーバー／クライアントからなるネットワークは、時間が流れるほど、複数のデバイス間の複雑なネットワークとしてその形態を形成している。

一方、かかるＣＥ機器の数が増加し続けて同種のサービスを提供するＣＥ機器が複数となる場合に、ネットワークでそれらの機器を担当する中央サーバーにはロードが集中して、サーバーの維持及び管理コストが増加する。

また、インターネット基盤のＣＥ機器は、ファームウェアアップグレードや、各種のアプリケーションアップグレードなどそれぞれの製品特性に対応するサービスの利用が増加している勢いである。

このとき、中央サーバー及び複数のクライアントからなるネットワーク環境では、中央サーバーが複数のクライアントをいずれも集中して管理し、それぞれのクライアントは、特定のインターフェースを通じて自身の製品特性情報を中央サーバーに伝達し、サーバーは、それをロジック処理して各特性に合うコントロール情報をリターンする。例えば、デバイスが自身の製品特性情報であるＩＤ、モデル名、ファームウェアバージョン情報、各種のトークンなどを中央サーバーへ伝送すれば、サーバーは、それを分析してデバイスに適用可能なコントロールデータを自身のＤＢで検索し、それをデバイスに戻す。デバイスは、サーバーからコントロールデータをダウンロードして実行させ、自身の状態を変更させる（例：ファームウェアバージョンアップグレード）。

すなわち、デバイスが周期的にサーバーに向かってクエリーを送れば、サーバーのロジックでは、バージョンチェック、事前スケジューリング、政策制御などを通じてコントロール命令メッセージをデバイスに送る。また、デバイスが各種のコンテンツに対するダウンロード要請メッセージをサーバーに送れば、サーバーは、トラフィック制御を通じてデバイス要請に対応するデータのバイナリーイメージを暗号化された状態に伝送する。

米国特許公開第２００６／０２０６５８６号公報（“位置基盤のＵＲＬに関する方法、装置及びシステム”）

本発明の目的は、複数のクライアントに共有可能な静的データにおいて、ＵＲＬアドレスを利用した分散コントロール方法及びその装置を提供するところにある。

前記目的を達成するために、本発明の一実施形態によれば、第１サーバーとネットワークで連結されたクライアントの分散コントロール方法は、前記クライアントについての少なくとも一つ以上の特性情報を第１サーバーに登録するステップと、前記クライアントの登録された特性情報に基づいて、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）フォーマットのアドレスを生成するステップと、前記第１サーバーから複製されたデータを保存する少なくとも一つ以上の第２サーバーから、前記生成されたＵＲＬアドレスを利用して前記データを獲得するステップと、を含む。

前記第２サーバーに保存された前記データは、静的データであって、前記第１サーバーから分散されてキャッシュされたデータであることが望ましい。

前記登録するステップは、前記クライアントの特性情報を前記第１サーバーへ伝送するステップと、前記伝送された特性情報に該当する少なくとも一つ以上のプロンプト情報を前記第１サーバーから受信するステップと、をさらに含み、前記ＵＲＬフォーマットのアドレスを生成するステップは、前記受信された少なくとも一つ以上のプロンプト情報に基づいて、前記アドレスを生成することが望ましい。

前記クライアントの特性情報は、モデル番号、Ｓ／Ｗコード、ＤＵＩＤ（Ｄｅｖｉｃｅ Ｕｎｉｑｕｅ ＩＤ）及びＩＰアドレスのうち少なくとも一つ以上を含み、前記プロンプト情報は、登録番号、地域名、グループタグ、プロンプトベースＵＲＬ及びプロンプトポーリング間隔のうち少なくとも一つ以上を含むことが望ましい。

前記データを獲得するステップは、前記第２サーバーから通知メッセージを聴取するステップと、前記聴取された通知メッセージを解釈して、前記クライアントに該当する内容が含まれているか否かを判断するステップと、前記判断結果、前記クライアントに該当する内容が含まれていない場合に、次の通知メッセージを待機するプロンプトスケジューリング作業を行うステップと、前記判断結果、前記クライアントに該当する内容が含まれている場合に、前記データを獲得するためにカウントスケジューリング作業を行うステップと、をさらに含むことが望ましい。

前記プロンプトスケジューリング作業を行うステップは、前記通知メッセージの変更如何を表すヘッダ情報（例えば、ＥＴａｇ（Ｅｎｔｉｔｙ Ｔａｇ））を確認するステップと、前記確認されたヘッダ情報が前記クライアントに既保存されたヘッダ情報と異なる場合に、前記通知メッセージの本文を獲得するステップと、前記通知メッセージの本文を解釈して、前記クライアントに該当する内容が含まれている場合に、前記カウントスケジューリング作業を行うステップと、をさらに含むことが望ましい。

前記カウントスケジューリング作業を行うステップは、前記第１サーバーから前記クライアントに割り当てられたカウント値を獲得するステップをさらに含み、前記カウント値は、第１サーバーからコントロール要請を受信する度に順次に増加する値であることが望ましい。

前記データを獲得するステップは、前記第１サーバーと同期化して第２サーバーに複製された調節情報を前記第２サーバーから受信するステップと、前記受信された調節情報と前記クライアントに割り当てられたカウント値とを比較して、前記データを受信するステップと、をさらに含むことが望ましい。

前記データを受信するステップは、前記生成されたＵＲＬフォーマットのアドレスを利用して、前記第２サーバーにキャッシュされた前記データを受信し、前記データについてのデジタル認証書を前記第２サーバーから受信するステップをさらに含むことが望ましい。

前記受信されたデジタル認証書を利用して有効性検証を行うステップと、前記有効性検証が成功した場合に、前記受信されたデータを利用して前記クライアントのソフトウェアをアップグレードするステップと、をさらに含むことが望ましい。

一方、前記目的を達成するために、本発明の他の実施形態によれば、第１サーバーとネットワークで連結されたクライアントの分散コントロール装置は、前記クライアントについての少なくとも一つ以上の特性情報を第１サーバーに登録する特性情報登録部と、前記クライアントの登録された特性情報に基づいて、ＵＲＬフォーマットのアドレスを生成するアドレス生成部と、前記第１サーバーから複製されたデータを保存する少なくとも一つ以上の第２サーバーから、前記生成されたＵＲＬアドレスを利用して前記データを獲得するデータ受信部と、を備える。

前記第２サーバーに保存された前記データは、静的データであって、前記第１サーバーから分散されてキャッシュされたデータであることが望ましい。

前記特性情報登録部は、前記クライアントの特性情報を前記第１サーバーへ伝送し、前記伝送された特性情報に該当する少なくとも一つ以上のプロンプト情報を前記第１サーバーから受信し、前記アドレス生成部は、前記受信された少なくとも一つ以上のプロンプト情報に基づいて前記アドレスを生成することが望ましい。

前記データ受信部は、前記第２サーバーから通知メッセージを聴取するメッセージリスナーと、前記聴取された通知メッセージを解釈して、前記クライアントに該当する内容が含まれていない場合に、次の通知メッセージを待機するプロンプトスケジュラと、前記クライアントに該当する内容が含まれている場合に、前記データを獲得するためにカウントスケジューリングを行うカウントスケジュラと、をさらに備えることが望ましい。

前記プロンプトスケジュラは、前記通知メッセージの変更如何を表すヘッダ情報（例えば、ＥＴａｇ（Ｅｎｔｉｔｙ Ｔａｇ））を確認し、前記確認されたヘッダ情報がクライアントに既保存されたヘッダ情報と異なる場合に、前記通知メッセージの本文を獲得して、前記クライアントに該当する内容が含まれている場合に、前記カウントスケジュラがスケジューリング作業を行うようにすることが望ましい。

前記カウントスケジュラは、前記クライアントに割り当てられたカウント値として、前記第１サーバーからコントロール要請を受信する度に順次に増加する値であるカウント値を前記第１サーバーから獲得することが望ましい。

前記データ受信部は、前記第１サーバーと同期化して第２サーバーに複製された調節情報を前記第２サーバーから受信する調節情報受信部をさらに備え、前記受信された調節情報と前記クライアントに割り当てられたカウント値とを比較して、前記データを第２サーバーから受信することが望ましい。

前記データ受信部は、前記生成されたＵＲＬフォーマットのアドレスを利用して、前記第２サーバーにキャッシュされた前記データを受信し、前記データについてのデジタル認証書を前記第２サーバーから受信することが望ましい。

前記分散コントロール装置は、前記受信されたデジタル認証書を利用して、有効性検証を行う有効性検証部と、前記有効性検証が成功した場合に、前記受信されたデータを利用して、前記クライアントのソフトウェアをアップグレードするアップグレード部と、をさらに備えることが望ましい。

一方、前記目的を達成するために、本発明のさらに他の実施形態による分散コントロールシステムは、クライアントについての少なくとも一つ以上の特性情報を登録し、前記クライアントをコントロールする第１サーバーと、前記第１サーバーから分散されてキャッシュされた静的データを保存する少なくとも一つ以上の第２サーバーと、前記特性情報に基づいたＵＲＬフォーマットのアドレスを利用して、第２サーバーから前記静的データを獲得するクライアントと、を備える。

さらに、本発明は、前記分散コントロール方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体を含む。

本発明の分散コントロール方法によれば、要請頻度の低いグループ形態のコントロールに対するサーバー負荷を除去でき、ピークタイム時にサーバーに負荷が集中する現象を緩和させ、これによってサーバー維持コストが低減する。また、Ｍｕｌｔｉ−ＣＤＮに適用可能でウェブサービス連動ＤＴＶ、モバイルホン及びその他のＣＥ製品で使用できる。

本発明の一実施形態によって、包括的な領域のデータがＵＲＬを利用してサーバー／クライアント間で伝達される関係を示す概念図である。 本発明の他の実施形態によって、ネットワークで連結されたクライアントの分散コントロール方法を説明するためのフローチャートである。 本発明の一実施形態によって、ファームウェアアップグレード過程で最初の登録及び最初の通知の聴取過程を示すフローチャートである。 本発明の一実施形態によって、ファームウェアアップグレード過程でプロンプトスケジューリング過程を示すフローチャートである。 本発明の一実施形態によって、ファームウェアアップグレード過程で事前スケジューリング過程を示すフローチャートである。 本発明の一実施形態によって、ファームウェアアップグレード過程でカウントスケジューリング及びトラフィック調節過程を示すフローチャートである。 本発明の一実施形態によって、ファームウェアアップグレード過程でデータ回収過程を示すフローチャートである。 本発明の一実施形態によって、ファームウェアアップグレード過程で有効性検査及びアップグレード過程を示すフローチャートである。 本発明の他の実施形態によって、ネットワークで連結されたクライアントの分散コントロール装置を説明するためのフローチャートである。 前記幾つの図面において、対応する図面番号は、対応する部分を指す。図面が本発明の実施形態を示しているが、図面が縮尺によって図示されたものではなく、本発明をさらによく表して説明するために、ある特徴部は誇張されうる。

本発明と本発明の動作上の利点及び本発明の実施によって達成される目的を十分に理解するためには、本発明の望ましい実施形態を例示する添付図面及び図面に記載された内容を参照せねばならない。

以下、添付した図面を参照して、本発明の望ましい実施形態について詳細に説明する。

図１は、本発明の一実施形態によって、包括的な領域のデータがＵＲＬを利用してサーバー／クライアント間で伝達される関係を示す概念図である。

一般的なコントロールサーバー／クライアント方式では、各クライアント別の状態管理がサーバーの論理演算実行により管理される。したがって、あらゆるコントロール要請メッセージに関して負荷が中央サーバーに集中する。さらに、サーバーの設計時に容量を決定することは、ピークタイム要請によらねばならないという問題も発生する。何より最も大きい問題は、共有可能な情報を伝達する場合、それを利用しがたいということである。

図１に示すように、本発明の一実施形態では、サーバー１１０が提供するデータ１１１を動的／静的に区分し、また、包括的／個別的に区分した。

ここで、包括的領域のデータ、すなわちグループに適用可能で共有できる性格のデータである場合には、ＵＲＬアドレス形式に構成して、それを分散キャッシュ１３０に配布し、クライアントであるデバイス１２０は、ＵＲＬを利用して接近可能にする。残りのデータの場合には、キャッシュされていない状態でサーバーからクライアントへ伝送される。

ここで、分散キャッシュされたデータは、ＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋｓ）またはキャッシュサーバーを利用してクライアントに提供される。したがって、クライアントのロジック１２１では、知られた特性データに基づいて要請ＵＲＬを組み合わせ、それを利用してデータを検索できる。アップグレードモジュール１２２は、獲得されたデータでクライアントデバイスのファームウェアをアップグレードする。

ファームウェアをアップグレードする場合として例を挙げれば、動作を３ステップに大別するが、１ステップは、デバイスを登録してＵＲＬを組み合わせ、タギングするなどの事前プロセスステップであり、２ステップは、ファームウェアバージョンをチェックし、通知メッセージを獲得するなどの通知待機ステップである。最後に３ステップは、伝送トラフィックを制限しつつデータをダウンロードし、ファームウェアをアップグレードするステップである。このとき、２ステップでは、キャッシュされたデータを利用し、３ステップでは、可能であればキャッシュされたデータを利用することが望ましい。これにより、あらゆる情報の伝達において最大限共有可能な形態としてサーバー／クライアント構造を設計できる。

図２は、本発明の他の実施形態によって、ネットワークで連結されたクライアントの分散コントロール方法を説明するためのフローチャートである。図２に示すように、第１サーバーとネットワークで連結されたクライアントの分散コントロール方法は、クライアントについての少なくとも一つ以上の特性情報を第１サーバー（中央サーバー）に登録するステップ２１０と、クライアントの登録された特性情報に基づいて、ＵＲＬフォーマットのアドレスを生成するステップ２２０と、第１サーバーから複製されたデータを保存する少なくとも一つ以上の第２サーバー（キャッシュサーバー）から、ＵＲＬアドレスを利用して目標データを獲得するステップ２３０と、を含む。

このとき、第２サーバーに保存された前記データは、複数のデバイスが共有可能な静的データであって、第１サーバーから分散キャッシュされたデータである。

分散キャッシュされたデータに接近するためのＵＲＬ構造は、デバイス製品別に該当特性情報を利用して組み合わせ可能であり、多重ＣＤＮアドレシングに親和的である。例えば、特定のモデルの最新のファームウェアバージョンを確認しようとする場合には、“ｈｔｔｐ：／／｛地域｝．ｏｔｎ−ｍ．ｓｅｃ．ｃｏｍ／ｔｖ／｛モデル名｝／ｃｕｒｒｅｎｔ／ｖｅｒ”でＵＲＬ組み合わせが可能である。一方、特定のモデルの特定のファームウェアバージョンに対する通知を聴取するためには、“ｈｔｔｐ：／／｛地域｝．ｏｔｎ−ｍ．ｓｅｃ．ｃｏｍ／ｔｖ／｛モデル名｝／｛デバイスＦ／Ｗコード｝／ｎｏｔｉｃｅ”となり、特定のモデルの特定のファームウェアイメージを獲得するためには、“ｈｔｔｐ：／／｛地域｝．ｏｔｎ−ｍ．ｓｅｃ．ｃｏｍ／ｔｖ／｛モデル名｝／｛目標Ｆ／Ｗコード｝／ｉｍａｇｅ”となる。また、特定のモデルの特定のファームウェアバージョンのイメージに対するファームウェア用デジタル認証書を獲得するためには、“ｈｔｔｐ：／／｛地域｝．ｏｔｎ−ｍ．ｓｅｃ．ｃｏｍ／ｔｖ／｛モデル名｝／｛目標Ｆ／Ｗコード｝／ｄｓ／｛デバイスＦ／Ｗコード｝”となる。

デバイス別に変更可能な｛地域｝、｛モデル名｝、｛目標Ｆ／Ｗコード｝、｛デバイスＦ／Ｗコード｝などに対して実際の幾つの例を挙げれば、韓国地域のＯＴＮ−ＳサーバーでＬＮ４６Ａ７５０Ｒ１ＦモデルのＴ−ＲＢＹＡＵＳＣ１００９．１バージョンのＤＴＶのための通知情報は、“ｈｔｔｐ：／／ｋｏ．ｏｔｎ−ｓ．ｓｅｃ．ｃｏｍ／ｔｖ／ＬＮ４６Ａ７５０Ｒ１Ｆ／Ｔ−ＲＢＹＡＵＳＣ１００９．１／ｎｏｔｉｃｅ”となる。さらに例を挙げれば、米国地域のＯＴＮ−ＳサーバーでＬＮ４６Ａ７５０Ｒ１ＦモデルのＴ−ＲＢＹＡＵＳＣ１００９．１バージョンのＤＴＶのためのＴ−ＲＢＹＡＵＳＣ１０１２．１バージョンのデジタル認証書は、“ｈｔｔｐ：／／ｕｓ．ｏｔｎ−ｓ．ｓｅｃ．ｃｏｍ／ｔｖ／ＬＮ４６Ａ７５０Ｒ１Ｆ／Ｔ−ＲＢＹＡＵＳＣ１０１２．１／ｄｓ／Ｔ−ＲＢＹＡＵＳＣ１００９．１”となる。

本発明の一実施形態による分散コントロール方法は、ファームウェアまたはアプリケーションアップグレードなどに適用可能であるところ、以下、ファームウェアをアップグレードする場合を例として挙げて、それぞれのステップを具体的に説明する。

図３は、本発明の一実施形態によって、ファームウェアのアップグレード過程で最初の登録及び最初の通知の聴取過程を示すフローチャートである。図３を参照するに、クライアントをコントロールしてモニタリングする第１サーバー（動的サーバー）と、ＣＤＮ適用可能な第２サーバー（静的サーバー）と、クライアントであるデバイスとでの作業順序を表す３個の水平ラインが表示されている。

まず、クライアントであるデバイスは、自身の特性情報を登録情報として第１サーバーに伝達する（ステップ３１０）。このとき、特性情報は、モデル番号、ファームウェアコード、ＤＵＩＤ、ＩＰアドレスなどとなる。

第１サーバーは、クライアントの特性情報を登録した後、プロンプト情報をリターンする（ステップ３２０）。このとき、プロンプト情報は、登録番号、地域名、グループタグ、プロンプトベースＵＲＬ及びプロンプトポーリング間隔などとなる。

クライアントは、受信したプロンプト情報のうち、プロンプトベースＵＲＬの形式によって地域名、タグ、モデル番号、ファームウェアコードなどを利用してプロンプトＵＲＬを組み合わせる（ステップ３３０）。例えば、“ｈｔｔｐ：／／｛地域名｝．ｏｔｎ−ｍ．ｓｅｃ．ｃｏｍ／ｔｖ／｛モデル番号｝／｛ファームウェアコード｝／ｎｏｔｉｃｅ”となる。ここまでが最初の登録過程である。

次いで、通知の聴取過程を見れば、プロンプトＵＲＬを利用して第２サーバーから該ファームウェアコード用通知を受信して（ステップ３５０）、該通知のＥＴａｇ（Ｅｎｔｉｔｙ Ｔａｇ）及び本文を獲得し、ＥＴａｇを保存する（ステップ３４０）。ＥＴａｇは、ＨＴＴＰ １．１互換ウェブサーバーが返還する応答ヘッダであって、リソースが変更されたかを確認するのに必要な情報を提供する。キャッシュ機能のあるアプリケーション（例：ブラウザ）で有用に使われるが、ＥＴａｇを参照して以前に受信したリソースのＥＴａｇと同じＥＴａｇであれば、重複したリソースを不要にダウンロードする場合を減らすことができる。ＥＴａｇの値は、ファイルサイズ及びファイルを修正した日付に基づいて生成するか、またはチェックサムを利用して生成することができる。

次いで、聴取した通知メッセージの内容を所定のインタープリタ法則によって解釈する（ステップ３６０）。解釈結果、デバイスに該当する通知内容が含まれているならば、通知メッセージを行い、含まれていないならば、プロンプトスケジューリング作業を行う（ステップ３７０）。プロンプトスケジューリング作業は、前記受信されたプロンプトポーリング間隔を利用する。ここまでが通知メッセージの最初の聴取過程である。

参考までに、通知メッセージのＸＭＬ基盤の具現例示コード（Ｐｒｏｇｒａｍ Ｄｅｓｉｇｎ Ｌａｎｇｕａｇｅ：ＰＤＬ）を見れば、次の通りである。

<?xml version=“1.0”?>
<edit name=“prompt_period”mode=“assign”>
<integer>86400</integer>
</edit>
<edit name=“targetfirmcode”mode=“assign”>
<string>T-RBYAWWC1012.1<string>
</edit>
<match pass_through=“false”>
<test qual=“any”name=“region”compare=“substr”>
<region>_Seoul</region>
…
</test>
<edit name=“method”mode=assign”>
<method type=“http_throttle”
image_url=“http://{otn_baseurl}/{targetfirmcode}/image”
…/>
<method…/>
</edit>
<seq>
<method>http_throttle</method>
</seq>
</match>
図４は、本発明の一実施形態によって、ファームウェアアップグレード過程でプロンプトスケジューリング過程を示すフローチャートである。図４に示すように、第１サーバーは、アップグレード進行対象デバイス、グループ及び政策を決定し、それを第２サーバーに送り出す（ステップ４１０）。

第２サーバーは、該ファームウェアコード用の通知メッセージを保存しており（ステップ４２０）、クライアントは、まず、プロンプトＵＲＬを利用して該通知のＥＴａｇを獲得し（ステップ４３０）、既保存されたＥＴａｇと同じであるか否かを判断し（ステップ４４０）、異なる場合にプロンプトＵＲＬを利用して該通知の本文を獲得する（ステップ４５０）。ここで、ファームウェアバージョンに対するアップグレードがない場合には、通知の本文を受信する過程は省略する。

聴取した通知メッセージの内容を所定のインタープリタ法則によって解釈し（ステップ４６０）、デバイスに該当する通知内容が含まれているならば、通知メッセージを行い、含まれていないならば、プロンプトスケジューリング作業を行う（ステップ４７０）。ここまでがデバイスグループの政策を受け付ける過程である。

図５は、本発明の一実施形態によって、ファームウェアアップグレード過程のうち事前スケジューリング過程を示すフローチャートである。図５に示すように、通知メッセージが行われる場合に、まず、通知内容を分析する（ステップ５１０）。次いで、通知内容に定義されたシーケンスの通りにメソッドをを行う（ステップ５２０）。ここまでが前述した例示コードＰＤＬのプロセシング過程である。

次いで、キャッシュされたデータをダウンロードするために事前スケジューリングを行うが（ステップ５３０）、通知メッセージの内容のうちメソッドに定義された変数を利用して、該デバイスのカウントスケジューリング作業を行う。

図６は、本発明の一実施形態によって、ファームウェアアップグレード過程でカウントスケジューリング及びトラフィック調節過程を示すフローチャートである。図６に示すように、まず、第１サーバーでカウントデーモンが行われて（ステップ６１０）、スロットルコントロール要請度にカウント値が順次に増加して、クライアントではカウントＵＲＬに接近して前記カウント値を獲得する（ステップ６２０）。

一方、第１サーバーでは、調節デーモンが行われて（ステップ６３０）、モニタリング情報及びダウンロード状態に基づいたクライアント別のトラフィック予想情報を送り出し、目標ファームウェアコード用の調節情報が生成される（ステップ６４０）。また、同時に第２サーバーでも複製された同じ調節情報が保存される（ステップ６５０）。調節情報は、例えば、サービス範囲、平均サービス期間、参照タイムスタンプなどである。

クライアントは、調節ＵＲＬに接近して、かかる調節情報を獲得する（ステップ６６０）。カウント値がドロップ範囲内にある場合、カウントスケジューリングが再び行われる（ステップ６７０）。

次いで、調節情報を参照して、クライアントがデータをダウンロードできる該当範囲内に属すれば、データ回収過程が行われ（ステップ６８０）、そうでない場合には、調節スケジューリング作業が行われる（ステップ６９０）。

図７は、本発明の一実施形態によって、ファームウェアアップグレード過程でデータ回収過程を示すフローチャートである。図７に示すように、目標ファームウェアバージョンのバイナリーイメージが第２サーバーに複製されており（ステップ７１０）、クライアントは、ファームウェアイメージを獲得する（ステップ７２０）。また、獲得したファームウェアイメージを実行するために必要なデジタル認証書を持たなければならないが（ステップ７４０）、これは、第２サーバーから獲得する（ステップ７３０）。デジタル認証書の獲得が成功すれば（ステップ７５０）、目標ファームウェアバージョンのバイナリーイメージを実行できる。

図８は、本発明の一実施形態によって、ファームウェアアップグレード過程で有効性検査及びアップグレード過程を示すフローチャートである。図８に示すように、獲得した目標ファームウェアバージョンのバイナリーイメージを実行するために、有効性検査及びアップグレード過程が表されているが、まず、ファームウェアイメージをハッシュして（ステップ８１０）、前記デジタル認証書のハッシュ値と比較し、内蔵された公開キーを利用して認証書を確認する（ステップ８２０）。マッチ如何を判断した結果（ステップ８３０）、有効性検査が成功すれば、ファームウェアアップグレードを行う（ステップ８４０）。このとき、必要ならばバックアップを共に行える。

もし、アップグレードが失敗すれば、復旧プロセスが動作し、アップグレードが成功すれば、前記一連の作業は最初の登録過程から再び反復される（ステップ８５０）。

図９は、本発明の他の実施形態によって、ネットワークで連結されたクライアントの分散コントロール装置を説明するためのフローチャートである。図９に示すように、本発明による分散コントロール装置９００の一実施形態は、クライアントについての少なくとも一つ以上の特性情報を第１サーバー９６０に登録する特性情報登録部９１０と、クライアントの登録された特性情報に基づいて、ＵＲＬフォーマットのアドレスを生成するアドレス生成部９２０と、複製されたデータを保存する少なくとも一つ以上の第２サーバー９７０から、ＵＲＬアドレスを利用してデータを獲得するデータ受信部９３０と、を備える。

一方、データ受信部９３０は、第２サーバー９７０から通知メッセージを聴取するメッセージリスナー９３１と、通知メッセージを解釈して、クライアントに該当する内容が含まれていない場合に、次の通知メッセージを待機するプロンプトスケジュラ９３２と、クライアントに該当する内容が含まれている場合に、前記データを獲得するためにカウントスケジューリングを行うカウントスケジュラ９３３と、をさらに備える。また、第１サーバーから第２サーバーに複製された調節情報を受信する調節情報受信部９３４をさらに備えることもある。

本発明による分散コントロール装置９００の一実施形態は、デジタル認証書を利用して有効性検証を行う有効性検証部９４０と、有効性検証が成功した場合に、受信されたデータを利用してソフトウェアアップグレードを行うアップグレード部９５０と、をさらに備える。

一方、前述した本発明の分散コントロール方法は、コンピュータで実行されるプログラムで作成可能であり、コンピュータで読み取り可能な記録媒体を利用して前記プログラムを動作させる汎用のデジタルコンピュータで具現される。

また、前述したように、本発明で使われたデータの構造は、コンピュータで読み取り可能な記録媒体に色々な手段を通じて記録される。

前記コンピュータで読み取り可能な記録媒体は、磁気記録媒体（例えば、ＲＯＭ、フロッピー（登録商標）ディスク、ハードディスクなど）、光学的読み取り媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤなど）のような記録媒体を含む。
これまで、本発明について、その望ましい実施形態を中心に述べた。当業者は、本発明が、本発明の本質的な特性から逸脱しない範囲で変形された形態に具現可能であるということを理解できるであろう。したがって、開示された実施形態は、限定的な観点ではなく、説明的な観点で考慮されねばならない。本発明の範囲は、前述した説明ではなく、特許請求の範囲に表れており、それと同等な範囲内にあるあらゆる相違点は、本発明に含まれていると解釈されねばならない。

本発明は、記録媒体関連の技術分野に適用可能である。

１１０ サーバー
１１１ データ
１１２，１２１ ロジック
１２０ クライアント
１２２ アップグレードモジュール
１３０ 分散キャッシュ

Claims (21)

1. 第１サーバーとネットワークで連結されたクライアントの分散コントロール方法において、
   前記クライアントについての少なくとも一つ以上の特性情報を第１サーバーに登録するステップと、
   前記クライアントの登録された特性情報に基づいて、ＵＲＬフォーマットのアドレスを生成するステップと、
   前記第１サーバーから複製されたデータを保存する少なくとも一つ以上の第２サーバーから、前記生成されたＵＲＬアドレスを利用して前記データを獲得するステップと、を含むことを特徴とする分散コントロール方法。
2. 前記第２サーバーに保存された前記データは、静的データであって、前記第１サーバーから分散されてキャッシュされたデータであることを特徴とする請求項１に記載の分散コントロール方法。
3. 前記登録するステップは、
   前記クライアントの特性情報を前記第１サーバーへ伝送するステップと、
   前記伝送された特性情報に該当する少なくとも一つ以上のプロンプト情報を前記第１サーバーから受信するステップと、をさらに含み、
   前記ＵＲＬフォーマットのアドレスを生成するステップは、
   前記受信された少なくとも一つ以上のプロンプト情報に基づいて、前記アドレスを生成することを特徴とする請求項２に記載の分散コントロール方法。
4. 前記クライアントの特性情報は、モデル番号、Ｓ／Ｗコード、ＤＵＩＤ（Ｄｅｖｉｃｅ Ｕｎｉｑｕｅ ＩＤ）及びＩＰアドレスのうち少なくとも一つ以上を含み、
   前記プロンプト情報は、登録番号、地域名、グループタグ、プロンプトベースＵＲＬ及びプロンプトポーリング間隔のうち少なくとも一つ以上を含むことを特徴とする請求項３に記載の分散コントロール方法。
5. 前記データを獲得するステップは、
   前記第２サーバーから通知メッセージを聴取するステップと、
   前記聴取された通知メッセージを解釈して、前記クライアントに該当する内容が含まれているか否かを判断するステップと、
   前記判断結果、前記クライアントに該当する内容が含まれていない場合に、次の通知メッセージを待機するプロンプトスケジューリング作業を行うステップと、
   前記判断結果、前記クライアントに該当する内容が含まれている場合に、前記データを獲得するためにカウントスケジューリング作業を行うステップと、をさらに含むことを特徴とする請求項３に記載の分散コントロール方法。
6. 前記プロンプトスケジューリング作業を行うステップは、
   前記通知メッセージの変更如何を表すヘッダ情報を確認するステップと、
   前記確認されたヘッダ情報が前記クライアントに既保存されたヘッダ情報と異なる場合に、前記通知メッセージの本文を獲得するステップと、
   前記通知メッセージの本文を解釈して、前記クライアントに該当する内容が含まれている場合に、前記カウントスケジューリング作業を行うステップと、をさらに含むことを特徴とする請求項５に記載の分散コントロール方法。
7. 前記カウントスケジューリング作業を行うステップは、
   前記第１サーバーから前記クライアントに割り当てられたカウント値を獲得するステップをさらに含み、
   前記カウント値は、第１サーバーからコントロール要請を受信する度に順次に増加する値であることを特徴とする請求項６に記載の分散コントロール方法。
8. 前記データを獲得するステップは、
   前記第１サーバーと同期化して第２サーバーに複製された調節情報を前記第２サーバーから受信するステップと、
   前記受信された調節情報と前記クライアントに割り当てられたカウント値とを比較して、前記データを受信するステップと、をさらに含むことを特徴とする請求項７に記載の分散コントロール方法。
9. 前記データを受信するステップは、
   前記生成されたＵＲＬフォーマットのアドレスを利用して、前記第２サーバーにキャッシュされた前記データを受信し、
   前記データについてのデジタル認証書を前記第２サーバーから受信するステップをさらに含むことを特徴とする請求項８に記載の分散コントロール方法。
10. 前記受信されたデジタル認証書を利用して有効性検証を行うステップと、
    前記有効性検証が成功した場合に、前記受信されたデータを利用して前記クライアントのソフトウェアをアップグレードするステップと、をさらに含むことを特徴とする請求項９に記載の分散コントロール方法。
11. 第１サーバーとネットワークで連結されたクライアントの分散コントロール装置において、
    前記クライアントについての少なくとも一つ以上の特性情報を第１サーバーに登録する特性情報登録部と、
    前記クライアントの登録された特性情報に基づいて、ＵＲＬフォーマットのアドレスを生成するアドレス生成部と、
    前記第１サーバーから複製されたデータを保存する少なくとも一つ以上の第２サーバーから、前記生成されたＵＲＬアドレスを利用して前記データを獲得するデータ受信部と、を備えることを特徴とする分散コントロール装置。
12. 前記第２サーバーに保存された前記データは、静的データであって、前記第１サーバーから分散されてキャッシュされたデータであることを特徴とする請求項１１に記載の分散コントロール装置。
13. 前記特性情報登録部は、前記クライアントの特性情報を前記第１サーバーへ伝送し、前記伝送された特性情報に該当する少なくとも一つ以上のプロンプト情報を前記第１サーバーから受信し、
    前記アドレス生成部は、前記受信された少なくとも一つ以上のプロンプト情報に基づいて、前記アドレスを生成することを特徴とする請求項１２に記載の分散コントロール装置。
14. 前記データ受信部は、
    前記第２サーバーから通知メッセージを聴取するメッセージリスナーと、
    前記聴取された通知メッセージを解釈して、前記クライアントに該当する内容が含まれていない場合に、次の通知メッセージを待機するプロンプトスケジュラと、
    前記クライアントに該当する内容が含まれている場合に、前記データを獲得するためにカウントスケジューリングを行うカウントスケジュラと、をさらに備えることを特徴とする請求項１３に記載の分散コントロール装置。
15. 前記プロンプトスケジュラは、
    前記通知メッセージの変更如何を表すヘッダ情報を確認し、前記確認されたヘッダ情報がクライアントに既保存されたヘッダ情報と異なる場合に、前記通知メッセージの本文を獲得して、前記クライアントに該当する内容が含まれている場合に、前記カウントスケジュラがスケジューリング作業を行うようにすることを特徴とする請求項１４に記載の分散コントロール装置。
16. 前記カウントスケジュラは、
    前記クライアントに割り当てられたカウント値として、前記第１サーバーからコントロール要請を受信する度に順次に増加する値であるカウント値を前記第１サーバーから獲得することを特徴とする請求項１５に記載の分散コントロール装置。
17. 前記データ受信部は、
    前記第１サーバーと同期化して、第２サーバーに複製された調節情報を前記第２サーバーから受信する調節情報受信部をさらに備え、
    前記受信された調節情報と前記クライアントに割り当てられたカウント値とを比較して、前記データを第２サーバーから受信することを特徴とする請求項１６に記載の分散コントロール装置。
18. 前記データ受信部は、
    前記生成されたＵＲＬフォーマットのアドレスを利用して、前記第２サーバーにキャッシュされた前記データを受信し、前記データについてのデジタル認証書を前記第２サーバーから受信することを特徴とする請求項１７に記載の分散コントロール装置。
19. 前記分散コントロール装置は、
    前記受信されたデジタル認証書を利用して有効性検証を行う有効性検証部と、
    前記有効性検証が成功した場合に、前記受信されたデータを利用して前記クライアントのソフトウェアをアップグレードするアップグレード部と、をさらに備えることを特徴とする請求項１８に記載の分散コントロール装置。
20. 分散コントロールシステムにおいて、
    クライアントについての少なくとも一つ以上の特性情報を登録し、前記クライアントをコントロールする第１サーバーと、
    前記第１サーバーから分散されてキャッシュされた静的データを保存する少なくとも一つ以上の第２サーバーと、
    前記特性情報に基づいたＵＲＬフォーマットのアドレスを利用して、第２サーバーから前記静的データを獲得するクライアントと、を備えることを特徴とする分散コントロールシステム。
21. 分散コントロール方法を利用してデバイスをアップグレードするプログラムが記録された記録媒体において、
    前記デバイスについての少なくとも一つ以上の特性情報に基づいたＵＲＬフォーマットのアドレスを生成してサーバーに登録するステップと、
    前記生成されたＵＲＬアドレスを利用して、前記サーバーから配布されたデータを備える分散されたキャッシュから前記データを獲得するステップと、
    前記獲得されたデータを利用して、前記デバイス内の少なくとも一つ以上のファームウェア及びソフトウェアをアップグレードするステップと、を含むことを特徴とするコンピュータで読み取り可能な記録媒体。

Images