JP2001296994A - プログラムダウンロードシステム及びプログラムダウンロード方法 - Google Patents

Abstract

(57)【要約】 【課題】 端末側のソフトウェアのアップグレードに関
して、ネットワークオペレータの作業を減らして、手作
業から生じる人為的作業ミスを未然に防ぐことができる
とともに、ネットワーク及びサーバ装置の負荷を下げる
ことができるプログラムダウンロードシステム及びプロ
グラムダウンロード方法を提供する。 【解決手段】 プログラムダウンロードシステムは、ソ
フトウェア・プログラムをネットワーク１２上に配布す
るヘッドエンド装置１１と、ヘッドエンド装置１１によ
ってネットワーク１２上に送出される最新ソフトウェア
一覧表２１と、ネットワーク１２に接続され、ヘッドエ
ンド装置１１から最新のソフトウェア・プログラムがダ
ウンロードされる多数の端末１３〜１６とを備え、各端
末１３〜１６は、最新ソフトウェアバージョン一覧表２
１を閲覧して、最新ソフトウェアバージョンを確認し、
ヘッドエンド装置１１側の指示によらず、端末側の判断
でソフトウェア・イメージ・ファイルのダウンロードの
リクエスト及びアップグレードを開始する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、プログラムダウン
ロードシステム及びプログラムダウンロード方法に関
し、詳細には、少数のヘッドエンド（Ｈ／Ｅ）装置に対
して、ケーブルモデム等の端末が多数存在するツリー型
のネットワークにおいて、端末装置が自分自身のソフト
ウェアをアップグレードする際に行うプログラムダウン
ロードシステム及びプログラムダウンロード方法に関す
る。

【０００２】

【従来の技術】ＣＡＴＶ（Cable Television）は、同軸
ケーブルや光ファイバ・ケーブルを用いてＴＶ番組を分
配するシステムである。ＣＡＴＶシステムで、ＴＶ信号
などをＣＡＴＶケーブルに送出する設備はヘッドエンド
（headend）と呼ばれる。ヘッドエンド設備では、分配
する番組をそれぞれのチャンネルの周波数に並べて、ア
クセスネットワークと呼ばれるケーブルに送信する。ケ
ーブルは、幹線、分岐線、分配線の多段ツリーあるいは
多段スター構造となっている。

【０００３】図８は、従来のプログラムダウンロード方
式の構成を示す図である。図８において、１はヘッドエ
ンド（Ｈ／Ｅ）装置、２はツリー型のケーブル・ネット
ワーク、３〜６はケーブルモデム等からなる多数の端末
Ａ，Ｂ，Ｃ，Ｄである。

【０００４】これら端末３〜６（端末Ａ，Ｂ，Ｃ，Ｄ）
には、ソフトウェアが組み込まれている。また、端末３
〜６自身で、ケーブル・ネットワーク２経由で新しいソ
フトウェアをダウンロードして、ソフトウェアを書き換
える機能を有する。ベンダー（Vendor）がこの端末を販
売した後、機能の追加があったり、販売時には発見でき
なかったソフトウェア上の問題点を解決したりした場
合、ベンダーはこれに対応した新しいソフトウェアを開
発し、上記書き換え機能を用いて、各端末のソフトウェ
アを書き換えることができる。

【０００５】このように、ネットワーク経由で、新しい
ソフトウェアをダウンロードして、ソフトウェアを書き
換える場合、ヘッドエンド側から、端末の一台一台に対
して、ケーブルオペレータ（管理者）が手動で、ダウン
ロードの指示を行っていた。指示を受けた各端末は、待
つことなく、即座にイメージファイルの送信を要求して
いた。

【０００６】ソフトウェア・イメージ・ファイルのダウ
ンロードは、一般にネットワーク及びヘッドエンドに非
常に負担がかかるので、一度にダウンロードを行うこと
のできる端末の数は限定され、それを超える数の端末
は、現在ダウンロードを行っている端末のいずれかがそ
のダウンロードを終了しないと、新しいダウンロードに
参加できない。ダウンロードを必要とする各端末は、フ
ァイルの要求を一斉に行うとともに、それらの全てのダ
ウンロードリクエストに対して、ヘッドエンド側が一度
に答えられない場合、ヘッドエンド側が他のリクエスト
を受け付けられた端末へのリクエストを行っている間
も、リクエストを受け付けられなかった端末は、ヘッド
エンド側にリクエストのやり直しを何度も行っていた。
また、受け付けられるリクエストの順位は、実際には早
い者勝ちであり、早くリクエストを行ったものほど早く
ダウンロードが行うことができた。

【０００７】また、一般的にあるネットワークに属する
各端末の機種が全て異なるということは考え難く、端末
の数は非常に多いものの、特定の機種が数多くそのネッ
トワークに存在したり、何種類かの機種だけによって構
成されていたりする。場合によっては全ての端末が同じ
機種から構成されているネットワークもある。このよう
な場合、端末一つ一つに対して、個別にソフトウェアの
ダウンロードを行ったとき、ヘッドエンドの側から見れ
ば、実際には同じファイルを何度も送信しつづけてい
る、と見ることもできる。ダウンロードは各端末とヘッ
ドエンドとの一対一の通信で行われているので、例えば
同じ端末がそのネットワークの中に存在していた場合で
も、ヘッドエンド側は同じファイルの送信を各端末に何
度も繰り返していた。

【０００８】

【発明が解決しようとする課題】このような従来のプロ
グラムダウンロードシステム及びプログラムダウンロー
ド方法にあっては、以下のような解決課題があった。い
ま、新しいソフトウェアのイメージファイルが端末のベ
ンダーから配布されたとする。このネットワークのネッ
トワークオペレータが、各端末のソフトウェアを、この
イメージファイルで書き換えようとしている。

【０００９】ケーブルオペレータは、各端末の一つ一つ
に対して、ソフトウェアのアップグレードを手動で指示
していく。このネットワーク上に接続されている端末
は、数が非常に多いので、このように一台一台に指示を
していくのは、非常に手間がかかる。また、ネットワー
クオペレータのミスにより、指示をし忘れる端末もある
かも知れず、その場合、その端末はソフトウェアのアッ
プグレードがされないという事故も発生した。また、ア
ップグレードの前に、そもそも端末の各々がソフトのア
ップグレードが必要なのかどうか、すなわち各端末のソ
フトウェアは最新のものであるのかないのか、ネットワ
ークオペレータが確認するという作業が必要であった。

【００１０】また、仮に、ケーブルオペレータの作業を
減らすために、ヘッドエンド側からでなく、端末側の主
導でソフトウェアをアップグレードするとしても、端末
側では、自分がソフトウェアをアップグレードすべきか
どうか、判断することができなかった。特開平１１−３
４５１１４号，特開平９−２９２９８０号，特開平８−
１７９９５１号の各公報には、ある端末装置の、最新の
ソフトウェア・バージョンを端末側に通知する仕組みを
持つシステムが開示されている。これらの公報に記載の
方法では、各機種、若しくは各端末ごとにバージョンを
通知しているので、実際にヘッドエンド側が発行するパ
ケットの数は多く、結果として非常に広いネットワーク
の帯域を使用してしまい、また、ヘッドエンドの負担を
重くしてしまうという問題点があった。

【００１１】ネットワークを管理するケーブルオペレー
タは、そのネットワークにつながっている端末に、どん
な機種が存在しているか即座には判断できず、また判断
するためには一台一台のモデムに対して、ネットワーク
経由で機種名を参照する必要がある。これには手間がか
かり、また同様に、ネットワークオペレータのミスによ
り、一部の端末に対して参照をし忘れてしまうという事
故も発生した。

【００１２】端末のダウンロードにかかる時間は、オペ
レータが一台一台の端末に対してダウンロードを指示す
るのにかかる時間に比較して長く、ネットワーク全体の
負荷の状態にもよるが、具体的にはおよそ１分から５分
程度であることから、オペレータが一度に多くの端末に
ダウンロードの指示を行ってしまうと、同じ瞬間にダウ
ンロードを行っている端末の数が急激に増加し、ネット
ワークや、ヘッドエンド側に対して非常に大きな負荷が
かかってしまっていた。

【００１３】また、端末がファイルをリクエストする
と、ヘッドエンド側は即座にそのリクエストに対するサ
ービスを開始していたので、優先順位の高いアップグレ
ードが、後回しになってしまうこともあった。

【００１４】また、端末がファイルを要求していても、
ヘッドエンド側がそれにサービスできないでいると、端
末がファイルを再要求してしまい、ネットワークやヘッ
ドエンド側の負荷を減らすことができなかった。また、
一定の回数、リクエストにサービスできないことが続く
と、ダウンロードが必要であるにもかかわらず、端末が
リクエストを諦める他なく、その場合はまた改めてネッ
トワークオペレータがダウンロードを指示し直さなくて
はならなかった。

【００１５】また、端末側が行ったダウンロードのリク
エストが、相手側（ヘッドエンド側）に受け付けられた
ことを知ったとしても、サービスがしばらく受けられな
いでいると、いつまで待っていればいいのかはっきりせ
ず、実際には再度リクエストを行う必要があったのに行
わなかったり、もう少し待てばサービスが開始されたの
に、無駄に再リクエストを行ってしまったりする。

【００１６】さらに、端末がファイルをリクエストする
際、その端末はリクエストだけを行っているので、ヘッ
ドエンド側は、どのような端末が、そのファイルのダウ
ンロードを要求しているのか、その時点では判断するこ
とができなかった。

【００１７】ヘッドエンド側の制限として、又はネット
ワークに負荷をかけ過ぎないようにするために、同時に
は一定の数しかダウンロードのサービスを行うことがで
きないようにしたものもある。しかし、一定の数に制限
するだけで優先順位を決めないため、実際にはダウンロ
ードリクエストの先着順でダウンロードのサービスを行
っているに過ぎず、ダウンロードの必要性の高いもので
も後回しになってしまうこともあった。

【００１８】ダウンロードは各端末とヘッドエンドとの
一対一の通信で行われているので、例えば同じ端末がそ
のネットワークの中に存在していた場合でも、ヘッドエ
ンド側は同じソフトウェアを各端末に何度も送信を繰り
返している。そのため、ヘッドエンド側で、ダウンロー
ドのプロセスが長時間にわたって継続されてしまい、ヘ
ッドエンドの負荷を長時間にわたって下げることができ
ないという問題点があった。

【００１９】また、仮にヘッドエンド側が、同じイメー
ジファイルを複数の端末に対して同時に送信を行ったと
しても、全ての端末が必ず受信に成功する訳ではなく、
この場合、不成功であった端末側が再送信のリクエスト
を行ったり、この端末側が受信確認応答を返してこなか
ったりするが、この端末への送信は失敗する。この場合
の再送信の手順が用意されていなかった。

【００２０】なお、このようなブロードキャスト通信や
マルチキャスト通信は、公知の技術であって、これまで
も使用されていたが、ソフトウェアファイルのダウンロ
ードでブロードキャスト通信やマルチキャスト通信が行
われることがなかったのは、上記の各問題点が解決され
ることがなかったためである。

【００２１】本発明は、このような課題に鑑みてなされ
たものであって、端末側のソフトウェアのアップグレー
ドに関して、ネットワークオペレータの作業を減らし
て、手作業から生じる人為的作業ミスを未然に防ぐこと
ができるとともに、ネットワーク及びサーバ装置の負荷
を下げることができるプログラムダウンロードシステム
及びプログラムダウンロード方法を提供することを目的
とする。

【００２２】

【課題を解決するための手段】本発明のプログラムダウ
ンロードシステムは、ソフトウェア・プログラムをネッ
トワーク上に配布するサーバ装置と、前記ネットワーク
に接続された多数の端末とを備え、前記端末が使用する
ソフトウェア・プログラムを前記サーバ装置側から前記
端末側にダウンロードして、前記端末側のソフトウェア
・プログラムをアップグレードするプログラムダウンロ
ードシステムにおいて、前記端末は、前記サーバ装置の
指示によらず、ソフトウェア・プログラムのダウンロー
ドのリクエスト及びアップグレードを開始することを特
徴とするものである。

【００２３】また、前記サーバ装置は、最新のソフトウ
ェアバージョン情報を示す一覧表を前記ネットワーク上
に送信し、前記端末は、前記一覧表を参照して最新ソフ
トウェアバージョンが自端末にないとき、ダウンロード
のリクエスト及びアップグレードを開始することで、サ
ーバ装置側が、端末側に向けて、各端末の最新ソフトウ
ェア一覧表を送信することによって、各端末が現時点で
最新のソフトウェアのバージョンと、自分が現在実行し
ているソフトウェアのバージョンとを比較することによ
り、その端末がソフトウェアのダウンロードが必要かど
うか、端末自身で判断することができる。また、一覧表
の形で、単一の情報をネットワーク全体に配布すること
で、各端末若しくは各端末機種ごとに最新のバージョン
情報を通知することに比べて、ネットワークの負荷を下
げ、またサーバ装置の負荷も下げることができる。

【００２４】また、前記サーバ装置は、ケーブル・ネッ
トワーク上でソフトウェア・プログラムを送るためのヘ
ッドエンドであり、前記端末は、前記ネットワーク上に
接続されたケーブルモデム等であることで、端末がケー
ブル・ネットワーク上でヘッドエンド側からソフトウェ
ア・プログラムをダウンロードする際、端末側の判断で
ダウンロードを要求し、ヘッドエンド側からダウンロー
ドのきっかけを与えるのではないことから、端末側のソ
フトウェアのアップグレードに関して、ネットワークオ
ペレータの作業を減らすことができ、手作業から生じる
人為的作業ミスを防ぐことができる。

【００２５】本発明のプログラムダウンロード方法は、
ソフトウェア・プログラムをネットワーク上に配布する
サーバ装置と、前記ネットワークに接続された多数の端
末とを備え、前記端末が使用するソフトウェア・プログ
ラムを前記サーバ装置側から前記端末側にダウンロード
して、前記端末側のソフトウェア・プログラムをアップ
グレードするプログラムダウンロード方法において、最
新のソフトウェアバージョン情報を示す一覧表を前記ネ
ットワーク上に送信するステップと、前記端末が、前記
一覧表を参照して最新ソフトウェアバージョンが自端末
にないとき、ダウンロードをリクエストするステップ
と、ダウンロードのリクエストに従って最新のソフトウ
ェア・プログラムをダウンロードするステップと、ダウ
ンロードされた前記ソフトウェア・プログラムに基づい
てソフトウェア・プログラムをアップグレードするステ
ップと、を順次実行することを特徴とする。

【００２６】また、本発明のプログラムダウンロード方
法は、ソフトウェア・プログラムをネットワーク上に配
布するサーバ装置と、前記ネットワークに接続された多
数の端末とを備え、前記端末が使用するソフトウェア・
プログラムを前記サーバ装置側から前記端末側にダウン
ロードして、前記端末側のソフトウェア・プログラムを
アップグレードするプログラムダウンロード方法におい
て、前記端末自身の機種情報を含む最新のソフトウェア
バージョン情報を要求するステップと、前記要求に応答
して、前記端末の機種に対応するソフトウェア・プログ
ラムの最新のバージョン情報を前記端末側に送信するス
テップと、前記最新バージョン情報に基づいて最新のソ
フトウェア・プログラムのダウンロードをリクエストす
るステップと、ダウンロードのリクエストに従って最新
のソフトウェア・プログラムをダウンロードするステッ
プと、ダウンロードされた前記ソフトウェア・プログラ
ムに基づいてソフトウェア・プログラムをアップグレー
ドするステップと、を順次実行することを特徴とする。

【００２７】このように本発明のプログラムダウンロー
ド方法は、前記一覧表に自分の機種用のソフトウェアに
関する情報が記載されていなかった場合や、一覧表が送
信されないネットワークシステムであった場合でも、端
末側がサーバ装置側に、自分の機種に対するソフトウェ
アの最新のバージョンを確認できることで、その端末が
ソフトウェアのダウンロードが必要であるかどうか、端
末自身で判断することができる。また、端末装置が勝手
にバージョン情報データベースにアクセスするのではな
く、サーバ装置側に連絡するように要求することから、
このバージョン情報データベースを用意するかどうかに
関係なく、サーバ装置側とは別途にデータベースを用意
してもよいし、サーバ装置自身にデータベースを内包さ
せてもよく、システムの設計に自由度が増す。

【００２８】また、前記最新のソフトウェア・プログラ
ムをダウンロードするステップでは、前記端末側からの
ダウンロードのリクエストを受け付けた時点から一定時
間経過後に、ダウンロードを開始することで、サーバ装
置側が、各端末からのダウンロードリクエストに対し
て、即座にはサービスを開始せず、一定期間待つことに
よって、この待ち時間の間に、集まってきたリクエスト
を集計して、各リクエストに、ダウンロードを優先すべ
き緊急度の順位が存在するか判断でき、また、存在する
とすれば、その優先順位の順位付けを行うことができ
る。

【００２９】また、前記最新のソフトウェア・プログラ
ムのダウンロードをリクエストするステップを実行した
後、前記リクエストを行った端末に対して該リクエスト
を受け付けたことを示すメッセージを通知するステップ
をさらに実行するようにすれば、すぐにサービスは開始
しないけれども、リクエストを再度行う必要はないとい
うことを端末側で判断することができる。この場合、前
記メッセージには、前記受付の有効期限を示すタイムス
タンプが含まれていてもよく、タイムスタンプを付加す
ることにより、該当リクエストに対する受付はその期間
有効であってその間は待つ必要があることと、またその
期間までにサービスが開始されなければ、リクエストは
破棄されたので再度リクエストを行う必要があること
を、端末側で判断することができる。

【００３０】また、前記最新のソフトウェア・プログラ
ムのダウンロードをリクエストするステップでは、ソフ
トウェアバージョン等の前記リクエストを発行した端末
に関する情報を添付することで、サーバ装置側で、これ
を元に、リクエストを発行した各端末に関して、ダウン
ロードの緊急度を判断することができる。また、端末側
からのアップグレードリクエストに、この情報を添付す
ることで、サーバ装置側から端末側に対して、その端末
の情報を連絡するようにリクエストする必要がなくな
る。

【００３１】また、前記最新のソフトウェア・プログラ
ムをダウンロードするステップでは、前記リクエストに
添付されている端末に関する情報に基づいて、ダウンロ
ードの対象の端末に優先順位をつけてダウンロードする
ことで、致命的欠点のあるソフトウェアで動作している
端末から優先的にソフトウェアのアップグレードを行う
ことでネットワークの安全性を高めたり、料率が高くサ
ービスレベルの高い顧客が使用している端末から優先的
にアップグレードを行うことで、顧客の満足度を高める
ことができる。

【００３２】

【発明の実施の形態】以下、添付図面を参照しながら本
発明の好適なプログラムダウンロードシステム及びプロ
グラムダウンロード方法の実施の形態について詳細に説
明する。図１は、本発明の実施の形態のプログラムダウ
ンロードシステムの構成を示す図である。

【００３３】図１において、１１はヘッドエンド（Ｈ／
Ｅ）装置（サーバ装置）、１２はツリー型のケーブル・
ネットワーク、１３〜１６はケーブルモデム等からなる
多数の端末Ａ，Ｂ，Ｃ，Ｄ、２１はヘッドエンド装置１
１によってケーブル・ネットワーク１２上に送出される
最新ソフトウェア一覧表２１である。

【００３４】各端末１３（端末Ａ）、端末１４（端末
Ｂ）、端末１５（端末Ｃ）及び端末１６（端末Ｄ）は、
それぞれ機種が異なるものとする。端末１３〜１６（端
末Ａ，Ｂ，Ｃ，Ｄ）には、ソフトウェアが組み込まれて
おり、端末１３〜１６自身で、ケーブル・ネットワーク
２経由で新しいソフトウェアをダウンロードして、ソフ
トウェアを書き換える機能を有する。ヘッドエンド装置
１１は、一定の期間ごとに、最新ソフトウェア一覧表２
１を各端末に向けてネットワーク上に配布している。

【００３５】最新ソフトウェア一覧表２１は、現在ヘッ
ドエンド側で確認している各機種に対する最新ソフトウ
ェアバージョンを含む情報を示す固有で単一の一覧表で
ある。このソフトウェア一覧表２１は、単一のものであ
り、ソフトウェアの最新ソフトウェアバージョンを通知
しようとする各端末の、各機種の関する情報は、すべて
このソフトウェア一覧表２１に記載されている。例え
ば、図１に示すように、ソフトウェア一覧表２１は、機
種名Ａ，Ｂ，Ｃ…毎に、ソフトウェアバージョン“ａ−
１”“ｂ−６”…が一覧表示されている。

【００３６】ヘッドエンド装置１１は、ネットワーク１
２上の各端末に対して、マルチキャスト／ブロードキャ
ストによりこのソフトウェア一覧表２１を送信する。各
機種に対して別々のバージョン情報を通知しているもの
ではないことに注意が必要である。ネットワークオペレ
ータは、ある端末のベンダーから、最新ソフトウェアが
リリースされた場合には、ヘッドエンド装置１１側にこ
のソフトウェア・イメージ・ファイルを保存した上で、
このソフトウェア一覧表２１を更新する必要がある。

【００３７】以下、上述のように構成されたプログラム
ダウンロードシステム及びプログラムダウンロード方法
の動作を説明する。ヘッドエンド装置１１では、ネット
ワーク１２上の各端末に対して、マルチキャスト／ブロ
ードキャストにより最新ソフトウェア一覧表２１を送信
する。

【００３８】各端末１３〜１６は、常にネットワーク１
２上を監視して、このソフトウェア一覧表２１の配布に
注意しておく。ソフトウェア一覧表２１が配布され、受
信した場合は、このソフトウェア一覧表１２を見て、自
端末がソフトウェアをアップデートする必要があるかど
うかを判断し、必要があればヘッドエンド装置１１側に
対してダウンロードを要求（リクエスト）する。この動
作について具体的に説明する。

【００３９】まず、端末１３（端末Ａ）について、自端
末のソフトウェアが既に最新のものであったとすると、
端末１３（端末Ａ）は、アップデートの必要なしと判断
し、ダウンロードを要求しない。一方、端末１４（端末
Ｂ）及び１６（端末Ｄ）は、動作しているソフトウェア
が最新のものよりも古いものであったとすると、自端末
ソフトウェアのバージョンと最新のソフトウェアのバー
ジョンを比較して、自端末のソフトウェアは最新のもの
ではないと判断する。これにより、端末１４（端末Ｂ）
及び端末１６（端末Ｄ）は、ヘッドエンド装置１１側に
対して、ダウンロードをリクエストする。

【００４０】図２は、ソフトウェア一覧表２１の配布と
端末によるリクエストを説明する図であり、ヘッドエン
ド装置１１側がソフトウェア一覧表２１を配布し、これ
を見た端末側がダウンロードのリクエストを行っている
様子を示す。

【００４１】図２に示すように、端末１４（端末Ｂ）
は、ヘッドエンド装置１１が配布した最新ソフトウェア
一覧表２１を見て、自端末のソフトウェアのバージョン
と比較する。自端末のソフトウェアのバージョンは、現
在“ｂ−１”であることが分かっている。そして、現在
最新のソフトウェアのバージョンは、最新ソフトウェア
一覧表２１によると、バージョン“ｂ−６”であった。
この最新ソフトウェア一覧表２１を見て、端末Ｂは自端
末に現在搭載されているソフトウェアのバージョンは
“ｂ−１”であって、ソフトウェアが最新のものではな
いと判断し、ダウンロードのリクエスト２２を行う。ダ
ウンロードリクエスト２２として、例えば「ソフト“ｂ
−６”を要求」「サービスクラス」「現在のソフト」
「ハードウェア」を送信し、ソフトウェアのリクエスト
と共に優先順位の参考になる情報を送信する。以上は、
端末１４（端末Ｂ）についてのリクエスト送信である
が、端末１６（端末Ｄ）についても同一である。ヘッド
エンド装置１１は、各リクエストを集計してダウンロー
ドの優先順位を決める。

【００４２】図１に戻って、端末１５（端末Ｃ）に関し
ては、最新ソフトウェア一覧表２１を見て、自端末が動
作しているソフトウェアのバージョンと最新のソフトウ
ェアのバージョンを比較しようとするが、ヘッドエンド
装置１１側が配布してきた最新ソフトウェア一覧表２１
の中に、この端末１５（端末Ｃ）の機種に関して、最新
のソフトウェアのバージョンに関する情報が記録されて
いなかった。端末１５（端末Ｃ）は、最新ソフトウェア
一覧表２１に自端末の機種に関する最新ソフトウェアの
バージョンを知るために、ヘッドエンド装置１１に対し
て、自端末の機種に対する最新のソフトウェアのバージ
ョンを連絡するように、リクエストを行う。ヘッドエン
ド側は、これに応答して、端末１５（端末Ｃ）の機種に
該当する最新のソフトウェアバージョンを連絡する。端
末１５（端末Ｃ）は、直接バージョン情報データベース
にアクセスする等ではなく、ヘッドエンド側に情報を連
絡するよう、リクエストを行うことに注意されたい。

【００４３】図３は、最新ソフトウェアのバージョンの
リクエストを説明する図であり、端末側が、最新のソフ
トウェアのバージョンを連絡するようにヘッドエンド装
置１１側に連絡して、ヘッドエンド装置１１側がこれに
応えて端末側に連絡している様子を表している。

【００４４】図３に示すように、端末１５（端末Ｃ）
は、ヘッドエンド装置１１側に対して、最新のソフトウ
ェアバージョン連絡要求２３を発行する。最新ソフトウ
ェアバージョン連絡要求２３は、自端末の機種名と共に
発行される。ヘッドエンド装置１１では、これを受けて
最新のソフトウェアバージョン情報２４（ここではバー
ジョン“ｃ−４”）を端末１５（端末Ｃ）に対して連絡
する。

【００４５】ヘッドエンド装置１１側は、これ以降は、
最新ソフトウェア一覧表２１に、端末１５（端末Ｃ）の
欄を加えて配布してもよい。このようにすれば、端末１
５（端末Ｃ）は、これ以降は自端末の機種に関して、最
新のソフトウェアのバージョンを連絡するようにリクエ
ストする必要はなくなる。また、ネットワーク内で、こ
の機種の個体数が少ない場合（これは端末Ｃの機種によ
るリクエストの総数で判断できる）、ネットワークの負
荷を上げないように、配布する最新ソフトウェア一覧表
２１の大きさを絞る目的で、最新ソフトウェア一覧表２
１にこの機種を加えないようにしてもよい。

【００４６】端末１５（端末Ｃ）は、連絡された最新の
ソフトウェアバージョンを見て、自端末のバージョンよ
りも新しいことを知り、ヘッドエンド装置１１に対して
ダウンロードをリクエストする。

【００４７】ヘッドエンド装置１１は、リクエストを受
け付けるが、すぐにサービスを行うことはなく、一定の
期間、このリクエストの受付だけを行う。リクエストを
行った各端末に対しては、ヘッドエンド装置１１はリク
エストを受け付けたことを確認するためのメッセージを
送信する。リクエストを行った各端末は、ヘッドエンド
装置１１からのメッセージを見てリクエストが受け付け
られたことを知り、サービスが開始されるまで待つ。ま
た、この、受け付けを行ったことを示すメッセージに
は、この受付が有効な期間を示すタイムスタンプが付け
られており、この期間の間にサービスが開始されなけれ
ば、ヘッドエンド装置１１はリクエストに対するサービ
スを処理できなかったので、もう一度、該当端末はヘッ
ドエンド装置１１側にリクエストを再送する必要があ
る。

【００４８】いま、一定の時間が終了し、ヘッドエンド
装置１１がダウンロードリクエスト受付期間を終了した
とする。各リクエストには、そのリクエストを発行した
各端末に関する情報が記録されている。例えば、その端
末が現在動作中のソフトウェアのバージョン、ハードウ
ェアのバージョン、また、顧客の料率、この機種が発揮
できる性能値などが、リクエストと一緒に記録されてい
る。ヘッドエンド装置１１は、この情報を参照するが、
注目すべき点は、この情報を得るために、ヘッドエンド
装置１１が各端末側に対して、この情報を送信するよう
にリクエストを行っているのではなく、あくまでも端末
側から、ヘッドエンド装置１１側に対して送信したアッ
プグレードリクエストに、かかる情報が添付されている
ことである。

【００４９】ソフトウェア・イメージ・ファイルのダウ
ンロードは、一般にネットワーク、及びヘッドエンドに
非常に負担がかかるので、一度にダウンロードを行うこ
とのできる端末の数は限定されてしまう。ヘッドエンド
装置１１は、これらの、リクエストの際に集められた情
報を元に、各端末のダウンロードの優先順位を決定す
る。この優先順位の決定の様子を図４に示す。

【００５０】図４は、優先順位の決定を説明する図であ
り、ヘッドエンド装置１１側が、各端末から寄せられた
リクエストを元に、ダウンロードの優先順位を決定して
いる様子を示している。図４おいて、２５はヘッドエン
ド装置１１により参照されるダウンロードの優先順位、
２６は各端末からのリクエストである。

【００５１】ダウンロードの優先順位２５には、優先順
位２５ａ、順番２５ｂ、端末名２５ｃ、ダウンロードす
るソフトウェア２５ｄの各項目に従って複数の優先順位
が設けられている。図４では、ダウンロードの優先順位
２５の左側が優先順位が高く、右側が低い。また、一度
にダウンロードできる端末の数は、例えば３（図４網が
け部分参照）であり上位から指定される。ここでは、順
番「４」の端末名「Ｆ」以降がダウンロード順番待ちと
なる。また、各端末からのリクエスト２６は、図２のダ
ウンロードのリクエスト２２と同一である。

【００５２】図４に示すように、ヘッドエンド装置１１
では、リクエスト受付期間に各端末からヘッドエンドに
寄せられたリクエスト２６を集計し、これらの情報を元
に、ヘッドエンド装置１１はダウンロードのサービスを
行う優先順位２５を決定する。ヘッドエンド装置１１が
一度に対応できなかった端末は、現在ダウンロードを行
っている端末のいずれかがそのダウンロードを終了しな
いと、新しいダウンロードに参加できない。したがっ
て、実際には、各端末は順番を待ってダウンロードを行
うことになるが、この場合、ヘッドエンド装置１１は、
各端末から集められた各端末の情報を元に、各端末のダ
ウンロードを行う優先順位を決めることができる。

【００５３】例えば、ある機種に搭載されて動作してい
るソフトウェアに、非常に致命的な欠陥があることが判
明し、これによりネットワーク全体に対して悪影響を及
ぼすことが懸念されている場合は、ネットワークオペレ
ータの判断で、この機種のソフトウェアのアップデート
を最優先に行うように各端末のダウンロードの優先願位
を決定することができる。

【００５４】また、高い料率の顧客が使用している端末
から、優先的にソフトウェアのアップデートを行うよう
に各端末のダウンロードの優先順位を決定することがで
きる。さらに、小さいサイズのソフトウェアファイルの
端末は、その分早くダウンロードが完了することから、
各端末機種のソフトウェアファイルの大きさを見て、大
きさの小さいものからダウンロードを優先させること
で、できるだけ早い段階で、アップグレード完了した端
末の数を確保する（すなわち、早いものから先に終わら
せようとする）こともできる。

【００５５】また、各端末の事情、例えば、ダウンロー
ドを必要とはするが、現在通信中であり、今すぐにはダ
ウンロードを受けることはできないという場合、その端
末は優先順位を下げることができる。一方、各端末から
の情報とは無関係に、各端末のダウンロードの優先順位
を決定してもかまわない。

【００５６】上述したプログラムダウンロードシステム
及びプログラムダウンロード方法の動作をフローチャー
トを参照して更に詳細に説明する。図５は、端末側での
動作を示すフローチャートであり、端末側でのダウンロ
ードの流れを示している。図中、Ｓはフローの各ステッ
プを示す。

【００５７】まず、ステップＳ１で最新ソフトウェア一
覧表２１（図２参照）が到着したか否かを判別し、最新
ソフトウェア一覧表２１が到着していなければ到着する
まで待つ。最新ソフトウェア一覧表２１が到着したとき
は、ステップＳ２で到着した最新ソフトウェア一覧表２
１に自端末の機種について記載されているか否かを判別
する。

【００５８】自端末の機種について記載されているとき
は、ステップＳ３で最新ソフトウェア一覧表２１の中で
最新バージョンを確認してステップＳ６に進む。自端末
の機種について記載されていないときは、ステップＳ４
でヘッドエンド装置１１に自端末の機種でのソフトウェ
ア最新バージョンを通知するようにリクエストする。こ
のとき、ソフトウェア最新バージョンのリクエストと共
に優先順位の参考になる情報を送信する（図２のリクエ
スト２２参照）。

【００５９】ステップＳ５でヘッドエンド装置１１から
の最新バージョンの連絡を受けると、ステップＳ６で送
信された最新バージョンを元にソフトウェアを更新する
か否かを判別し、ソフトウェアを更新しない場合はその
まま本フローを終了する。ソフトウェアを更新する場合
は、ステップＳ７でヘッドエンド装置１１に対してダウ
ンロードをリクエストする。次いで、ステップＳ８でヘ
ッドエンド装置１１からのメッセージにより、ダウンロ
ードのリクエストが受け付けられたか否かを判別し、受
け付けられていなければステップＳ７に戻ってダウンロ
ードをリクエストする。

【００６０】リクエストが受け付けられたときは、ステ
ップＳ９でヘッドエンド装置１１からのダウンロードの
開始の通知を受信したか否かを判別し、ダウンロードの
開始の通知を受信していなければ受信するまで待つ。ダ
ウンロードの開始の通知を受信したときは、ステップＳ
１０でソフトウェア・イメージ・ファイルをダウンロー
ドし、ソフトウェアをアップグレードして本フローを終
了する。

【００６１】このように、ヘッドエンド装置１１が、ネ
ットワーク１２に接続されている各端末について、最新
ソフトウェアバージョン一覧表２１を送信すると、各端
末はこの最新ソフトウェアバージョン一覧表２１を閲覧
し、各端末はこの最新ソフトウェアバージョン一覧表２
１を元に最新ソフトウェアバージョンを確認し、ヘッド
エンド装置１１側の指示ではなく、端末側の判断で、ダ
ウンロード、アップグレードを開始する。

【００６２】図６は、ヘッドエンド側での動作を示すフ
ローチャートであり、ヘッドエンド側でのダウンロード
の流れを示す。まず、ステップＳ１１で最新ソフトウェ
ア一覧表２１（図２参照）をネットワーク１２上に配布
する。次いで、ステップＳ１２で最新ソフトウェア一覧
表２１に載っていない端末からの確認リクエストを受信
したか否かを判別し、確認リクエストを受信したときは
ステップＳ１３で最新ソフトウェア一覧表２１に載って
いない端末にバージョンを通知してステップＳ１４に進
む。ステップＳ１２で確認リクエストを受信しなかった
ときは、そのままステップＳ１４に進む。

【００６３】ステップＳ１４では、ダウンロードリクエ
ストを受信したか否かを判別し、ダウンロードリクエス
トを受信していなければ受信するまで待つ。ダウンロー
ドリクエストを受信すると、ステップＳ１５でそのリク
エストを記録し、ステップＳ１６で該当端末に対してリ
クエストを受け付けたことを通知する。

【００６４】次いで、ステップＳ１７でリクエスト受け
付け期間が終了したか否かを判別し、リクエスト受け付
け期間が終了していなければステップＳ１４に戻る。リ
クエスト受け付け期間が終了したときは、ステップＳ１
８で各リクエストを集計してダウンロードの優先順位を
決定し、ステップＳ１９で優先順位の高い順にダウンロ
ードを実行する。次いで、ステップＳ２０でリクエスト
した端末全数に対してダウンロードを終了したか否かを
判別し、ダウンロードが終了していなければステップＳ
１９に戻ってリクエストした端末全数が終了するまでダ
ウンロードを実行する。リクエストした端末全数に対し
てダウンロードを終了すると本フローを終える。

【００６５】ところで、一般的にあるネットワークに属
する各端末の機種が全て異なるということは考え難く、
端末の数は非常に多いが、ある機種が数多くそのネット
ワークに存在したり、何種類かの機種だけによって構成
されていたりする。場合によっては全ての端末が同じ機
種から構成されているネットワークも見られる。このよ
うな場合、端末一つ一つに対して、個別にソフトウェア
のダウンロードを行った場合、ヘッドエンド側から見れ
ば、実際には同じファイルを何度も送信しつづけている
と見ることもできる。

【００６６】本実施の形態のネットワーク１２では、同
じ機種に対するダウンロードでは、一度にファイルの送
信を行う。ヘッドエンド装置１１は、各端末に対して、
このネットワーク１２内にブロードキャスト／マルチキ
ャスト通信で該当ファイルを送信する。

【００６７】各端末は、ブロードキャスト／マルチキャ
スト通信で送信されたファイルを受け取るが、送信対象
の各端末の全てが、このファイルのダウンロードに成功
して、このファイルの送信の受信に成功するとは限らな
い。受信に失敗した各端末は、ダウンロードが一旦終了
するまで何もせず、終了してから、ダウンロードに失敗
した部分の送信を、ヘッドエンド装置１１に対してもう
一度要求（リクエスト）する。ヘッドエンド装置１１
は、そのリクエストを受けて、端末が受信に失敗した部
分だけを再度送信する。このときの様子を、図７に示
す。

【００６８】図７は、ヘッドエンド装置１１が、ブロー
ドキャスト／マルチキャスト通信でダウンロードを行っ
ている様子を説明する図である。図７において、１１は
ヘッドエンド装置、３１，３２，３３は端末、３４はヘ
ッドエンド装置１１によりダウンロードするソフトウェ
ア・イメージ・ファイル、３５はダウンロードしたが、
一部受信できなかったソフトウェア・イメージ・ファイ
ル、３６はダウンロードしたが、一部受信できなかった
ソフトウェア・イメージ・ファイル、３７はダウンロー
ドして、全部受信に成功したソフトウェア・イメージ・
ファイル、３８はソフトウェア・イメージ・ファイル３
６のうち、ダウンロードに失敗して、受信できなかった
部分、３９はソフトウェア・イメージ・ファイル３６の
うち、他の部分は失敗したが、ダウンロードに成功し
て、受信できた部分である。また、図７のソフトウェア
・イメージ・ファイル３５，３６のハッチング部分は、
ダウンロードしたソフトウェア・イメージ・ファイルの
うち受信できなかった部分を示し、この部分だけ後でも
う一度リクエストすることを示している。

【００６９】ヘッドエンド装置１１が、同じ機種の各端
末３１，３２，３３に、一度にダウンロードを行う。す
なわち、各端末３１，３２，３３が同じソフトウェアを
要求している場合は、送り先を複数にして、一度にダウ
ンロードを行う。ところが、全ての端末がダウンロード
に完全に成功した訳ではなくて、一部の端末が、ファイ
ルを完全には受信できなかった。端末３３は全部受信に
成功したソフトウェア・イメージ・ファイル３７を受信
成功した。端末３１及び端末３２は、ファイルのある一
部を受信できなかったので、これを再度リクエストを行
う必要があるが、最初のダウンロードが終了しないうち
にリクエストを行うと、この最初のダウンロード全体に
影響を及ぼすため、この最初のダウンロードが一旦終了
するまで、再送要求のリクエストは行わない。ダウンロ
ード終了を待って、端末３１は、受信できなかった部分
の再送要求リクエストを行う。端末３２に関して、ダウ
ンロードに失敗して受信できなかった部分３８が受信で
きなかったので、この部分３８だけ、ヘッドエンド装置
１１に対して、再度送信をリクエストする。

【００７０】以上のように、本実施の形態のプログラム
ダウンロードシステムは、ソフトウェア・プログラムを
ネットワーク１２上に配布するヘッドエンド装置１１
と、ヘッドエンド装置１１によってネットワーク１２上
に送出される最新ソフトウェア一覧表２１と、ネットワ
ーク１２に接続され、ヘッドエンド装置１１から最新の
ソフトウェア・プログラムがダウンロードされる多数の
端末１３〜１６とを備え、各端末１３〜１６は、最新ソ
フトウェアバージョン一覧表２１を閲覧して、最新ソフ
トウェアバージョンを確認し、ヘッドエンド装置１１側
の指示によらず、端末側の判断でソフトウェア・イメー
ジ・ファイル（ソフトウェア・プログラム）のダウンロ
ードのリクエスト及びアップグレードを開始するように
したので、端末側の判断でダウンロードを要求し、ヘッ
ドエンド装置１１側からダウンロードのきっかけを与え
るのではないことから、端末側のソフトウェアのアップ
グレードに関して、ネットワークオペレータの作業を減
らすことができ、手作業から生じる人為的作業ミスを未
然に防ぐことができる。

【００７１】また、ヘッドエンド装置１１側が、端末側
に向けて、各端末１３〜１６の最新ソフトウェア情報を
一覧表２１の形で、単一の情報をネットワーク１２全体
に配布することで、各端末１３〜１６若しくは各端末機
種ごとに最新のバージョン情報を通知する場合に比べ
て、ネットワーク１２の負荷を下げ、またヘッドエンド
装置１１の負荷も下げることができる。

【００７２】また、本実施の形態では、リクエストを受
け付けたことを示すメッセージを各端末１３〜１６に向
けてヘッドエンド装置１１が送信することによって、す
ぐにサービスは開始しないけれども、リクエストを再度
行う必要はないということを、端末側で判断することが
できる。

【００７３】また、ダウンロードリクエストを受け付け
たことを示すメッセージに、有効期限を示したタイムス
タンプをつけることで、このリクエストに対する受付は
その期間有効であってその間は待つ必要があることと、
またその期間までにサービスが開始されなければ、リク
エストは破棄されたので再度リクエストを行う必要があ
ることを、端末側で判断することができる。

【００７４】また、本実施の形態では、端末側がヘッド
エンド装置１１側に向けて発行したダウンロード・リク
エストの中に、現在のソフトウェアバージョンに加え、
そのリクエストを発行した端末に関する情報を添付して
いることで、ヘッドエンド装置１１側で、この情報を元
に、リクエストを発行した各端末に関して、ダウンロー
ドの緊急度を判断することができる。また、端末側から
のアップグレードリクエストに、この情報を添付するこ
とで、ヘッドエンド装置１１側から端末側に対して、そ
の端末の情報を連絡するようにリクエストする必要がな
くなる。

【００７５】また、各端末からのダウンロードリクエス
トに添付されている端末情報を元に、ヘッドエンド装置
１１が各端末へのダウンロードに優先順位を付けること
から、致命的欠点のあるソフトウェアで動作している端
末から優先的にソフトウェアのアップグレードを行うこ
とでネットワークの安全性を高めたり、料率が高くサー
ビスレベルの高い顧客が使用している端末から優先的に
アップグレードを行うことで、顧客の満足度を高めたり
することができる。

【００７６】また、ダウンロードの際、ファイルを一方
的にブロードキャスト、又はマルチキャストし、複数の
端末が同時にこれを受信することによって、同じファイ
ルを、端末の数だけ、何度も送信する必要がなく、ダウ
ンロードにかかる時間を削減することができる。

【００７７】さらに、各端末１３〜１６に同時に送信さ
れるブロードキャスト／マルチキャスト通信によるダウ
ンロードを行う際、ある端末がダウンロードされてきた
ソフトウェア・イメージ・ファイルの一部が受信できな
かった場合でも、その部分だけを送りなおすようにヘッ
ドエンド装置１１側にリクエストすることができる。ま
た、ブロードキャスト／マルチキャスト通信によるダウ
ンロードの最中に再送リクエストを行わないことで、ソ
フトウェア・ダウンロードについてブロードキャスト・
マルチキャスト通信を行うことが可能になり、ネットワ
ーク１２及びヘッドエンド装置１１に無駄な負荷がかか
らないようにすることができる。

【００７８】なお、上記実施の形態では、ＣＡＴＶシス
テムのプログラムダウンロードシステム及びプログラム
ダウンロード方法に適用した例であるが、プログラムを
転送するプログラムダウンロード方法であればどのよう
なシステムにも適用可能である。また、上記プログラム
ダウンロードシステムを構成する各装置、例えばヘッド
エンドやネットワークの種類、数及び接続方法などは前
述した実施の形態に限られない。

【００７９】

【発明の効果】以上、詳述したように、本発明によれ
ば、端末側のソフトウェアのアップグレードに関して、
ネットワークオペレータの作業を減らして、手作業から
生じる人為的作業ミスを未然に防ぐことができるととも
に、ネットワーク及びサーバ装置の負荷を下げることが
できる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態のプログラムダウン
ロードシステムの構成を示す図である。

【図２】本実施の形態のプログラムダウンロードシステ
ムのソフトウェア一覧表の配布と端末によるリクエスト
を説明する図である。

【図３】本実施の形態のプログラムダウンロードシステ
ムの最新ソフトウェアのバージョンのリクエストを説明
する図である。

【図４】本実施の形態のプログラムダウンロードシステ
ムの優先順位の決定を説明する図である。

【図５】本実施の形態のプログラムダウンロードシステ
ムの端末側での動作を示すフローチャートである。

【図６】本実施の形態のプログラムダウンロードシステ
ムのヘッドエンド側での動作を示すフローチャートであ
る。

【図７】本実施の形態のプログラムダウンロードシステ
ムのヘッドエンド装置が、ブロードキャスト／マルチキ
ャスト通信でダウンロードを行っている様子を説明する
図である。

【図８】従来のプログラムダウンロード方式の構成を示
す図である。

【符号の説明】

１１ ヘッドエンド（Ｈ／Ｅ）装置（サーバ装置） １２ ケーブル・ネットワーク １３〜１６，２３〜２５ 端末 ２１ 最新ソフトウェア一覧表 ２２ ダウンロードのリクエスト ２３ 最新ソフトウェア連絡リクエスト ２４ 最新ソフトウェア連絡 ２５ ダウンロードの優先順位 ２６ 端末からのリクエスト ３４ ダウンロードするソフトウェアイメージファイル ３５，３６ 一部受信できなかったソフトウェア・イメ
ージ・ファイル ３７ 全部受信に成功したソフトウェア・イメージ・フ
ァイル ３８ ダウンロードに失敗して、受信できなかった部分 ３９ 他の部分は失敗したが、ダウンロードに成功し
て、受信できた部分

Claims (8)

【特許請求の範囲】
1. 【請求項１】 ソフトウェア・プログラムをネットワー
   ク上に配布するサーバ装置と、前記ネットワークに接続
   された多数の端末とを備え、 前記端末が使用するソフトウェア・プログラムを前記サ
   ーバ装置側から前記端末側にダウンロードして、前記端
   末側のソフトウェア・プログラムをアップグレードする
   プログラムダウンロードシステムにおいて、 前記端末は、前記サーバ装置の指示によらず、ソフトウ
   ェア・プログラムのダウンロードのリクエスト及びアッ
   プグレードを開始することを特徴とするダウンロードシ
   ステム。
2. 【請求項２】 前記サーバ装置は、最新のソフトウェア
   バージョン情報を示す一覧表を前記ネットワーク上に送
   信し、 前記端末は、前記一覧表を参照して最新ソフトウェアバ
   ージョンが自端末にないとき、ダウンロードのリクエス
   ト及びアップグレードを開始することを特徴とする請求
   項１記載のプログラムダウンロードシステム。
3. 【請求項３】 前記サーバ装置は、ケーブル・ネットワ
   ーク上でソフトウェア・プログラムを送るためのヘッド
   エンドであり、前記端末は、前記ネットワーク上に接続
   されたケーブルモデム等であることを特徴とする請求項
   １又は２のいずれかに記載のプログラムダウンロードシ
   ステム。
4. 【請求項４】 ソフトウェア・プログラムをネットワー
   ク上に配布するサーバ装置と、前記ネットワークに接続
   された多数の端末とを備え、前記端末が使用するソフト
   ウェア・プログラムを前記サーバ装置側から前記端末側
   にダウンロードして、前記端末側のソフトウェア・プロ
   グラムをアップグレードするプログラムダウンロード方
   法において、 最新のソフトウェアバージョン情報を示す一覧表を前記
   ネットワーク上に送信するステップと、 前記端末が、前記一覧表を参照して最新ソフトウェアバ
   ージョンが自端末にないとき、ダウンロードをリクエス
   トするステップと、 ダウンロードのリクエストに従って最新のソフトウェア
   ・プログラムをダウンロードするステップと、 ダウンロードされた前記ソフトウェア・プログラムに基
   づいてソフトウェア・プログラムをアップグレードする
   ステップと、 を順次実行することを特徴とするプログラムダウンロー
   ド方法。
5. 【請求項５】 ソフトウェア・プログラムをネットワー
   ク上に配布するサーバ装置と、前記ネットワークに接続
   された多数の端末とを備え、前記端末が使用するソフト
   ウェア・プログラムを前記サーバ装置側から前記端末側
   にダウンロードして、前記端末側のソフトウェア・プロ
   グラムをアップグレードするプログラムダウンロード方
   法において、 前記端末自身の機種情報を含む最新のソフトウェアバー
   ジョン情報を要求するステップと、 前記要求に応答して、前記端末の機種に対応するソフト
   ウェア・プログラムの最新のバージョン情報を前記端末
   側に送信するステップと、 前記最新バージョン情報に基づいて最新のソフトウェア
   ・プログラムのダウンロードをリクエストするステップ
   と、 ダウンロードのリクエストに従って最新のソフトウェア
   ・プログラムをダウンロードするステップと、 ダウンロードされた前記ソフトウェア・プログラムに基
   づいてソフトウェア・プログラムをアップグレードする
   ステップと、 を順次実行することを特徴とするプログラムダウンロー
   ド方法。
6. 【請求項６】 前記最新のソフトウェア・プログラムを
   ダウンロードするステップでは、前記端末側からのダウ
   ンロードのリクエストを受け付けた時点から一定時間経
   過後に、ダウンロードを開始することを特徴とする請求
   項４又は５のいずれかに記載のプログラムダウンロード
   方法。
7. 【請求項７】 前記最新のソフトウェア・プログラムの
   ダウンロードをリクエストするステップでは、ソフトウ
   ェアバージョン等の前記リクエストを発行した端末に関
   する情報を添付することを特徴とする請求項５記載のプ
   ログラムダウンロード方法。
8. 【請求項８】 前記最新のソフトウェア・プログラムを
   ダウンロードするステップでは、前記リクエストに添付
   されている端末に関する情報に基づいて、ダウンロード
   の対象の端末に優先順位をつけてダウンロードすること
   を特徴とする請求項４、５又は７のいずれかに記載のプ
   ログラムダウンロード方法。