(57)【特許請求の範囲】
【請求項１】
ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロード方法において、
該サーバ装置側で確認している最新のソフトウェアバージョン情報を示す一覧表であって前記各端末の各機種毎のソフトウェアのバージョンを記載した単一の一覧表を前記ネットワーク上の前記各端末に送信するステップと、
前記端末が、前記一覧表を参照して最新ソフトウェアバージョンが自端末のソフトウェアバージョンと異なるときに前記最新のソフトウェアのダウンロードのリクエストを行なうステップと、
ダウンロードのリクエストに従って最新のソフトウェア・プログラムをダウンロードするステップと、
ダウンロードされた前記ソフトウェア・プログラムに基づいてソフトウェア・プログラムをアップグレードするステップと
を順次実行することを特徴とするプログラムダウンロード方法であって、
前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記リクエストに添付されている端末に関する情報に基づいて、ダウンロードの対象の端末に優先順位をつけることを特徴とするプログラムダウンロード方法。
【請求項２】
ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロード方法において、
前記サーバ装置に対して前記端末自身の機種情報を含む最新のソフトウェアバージョン情報を前記端末から要求するステップと、
前記要求に応答して、該サーバ装置側で確認している最新のソフトウェアバージョン情報を示す一覧表であって前記端末の機種に対応するソフトウェアのバージョンを記載した単一の一覧表を前記サーバ装置から前記ネットワーク上の前記各端末に送信するステップと、
前記一覧表を参照して最新ソフトウェアバージョンが自端末のソフトウェアバージョンと異なるときに前記端末から前記サーバ装置に対して前記最新のソフトウェアのダウンロードのリクエストを行なうステップと、
ダウンロードのリクエストに従って前記サーバ装置から送られた最新のソフトウェア・プログラムを前記端末においてダウンロードするステップと、
ダウンロードされた前記ソフトウェア・プログラムに基づいてソフトウェア・プログラムをアップグレードするステップと、
を順次実行することを特徴とするプログラムダウンロード方法であって、
前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記リクエストに添付されている端末に関する情報に基づいて、ダウンロードの対象の端末に優先順位をつけることを特徴とするプログラムダウンロード方法。
【請求項３】
前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記端末側からのダウンロードのリクエストを受け付けた時点から一定時間経過後に、前記サーバ装置から最新のソフトウェア・プログラムが送られることを特徴とする請求項１又は２に記載のプログラムダウンロード方法。
【請求項４】
前記最新のソフトウェア・プログラムのダウンロードをリクエストするステップでは、ソフトウェアバージョン等の前記リクエストを発行した端末に関する情報を添付することを特徴とする請求項１又は２に記載のプログラムダウンロード方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プログラムダウンロードシステム及びプログラムダウンロード方法に関し、詳細には、少数のヘッドエンド（Ｈ／Ｅ）装置に対して、ケーブルモデム等の端末が多数存在するツリー型のネットワークにおいて、端末装置が自分自身のソフトウェアをアップグレードする際に行うプログラムダウンロードシステム及びプログラムダウンロード方法に関する。
【０００２】
【従来の技術】
ＣＡＴＶ（Cable Television）は、同軸ケーブルや光ファイバ・ケーブルを用いてＴＶ番組を分配するシステムである。ＣＡＴＶシステムで、ＴＶ信号などをＣＡＴＶケーブルに送出する設備はヘッドエンド（headend）と呼ばれる。ヘッドエンド設備では、分配する番組をそれぞれのチャンネルの周波数に並べて、アクセスネットワークと呼ばれるケーブルに送信する。ケーブルは、幹線、分岐線、分配線の多段ツリーあるいは多段スター構造となっている。
【０００３】
図８は、従来のプログラムダウンロード方式の構成を示す図である。
図８において、１はヘッドエンド（Ｈ／Ｅ）装置、２はツリー型のケーブル・ネットワーク、３〜６はケーブルモデム等からなる多数の端末Ａ，Ｂ，Ｃ，Ｄである。
【０００４】
これら端末３〜６（端末Ａ，Ｂ，Ｃ，Ｄ）には、ソフトウェアが組み込まれている。また、端末３〜６自身で、ケーブル・ネットワーク２経由で新しいソフトウェアをダウンロードして、ソフトウェアを書き換える機能を有する。ベンダー（Vendor）がこの端末を販売した後、機能の追加があったり、販売時には発見できなかったソフトウェア上の問題点を解決したりした場合、ベンダーはこれに対応した新しいソフトウェアを開発し、上記書き換え機能を用いて、各端末のソフトウェアを書き換えることができる。
【０００５】
このように、ネットワーク経由で、新しいソフトウェアをダウンロードして、ソフトウェアを書き換える場合、ヘッドエンド側から、端末の一台一台に対して、ケーブルオペレータ（管理者）が手動で、ダウンロードの指示を行っていた。指示を受けた各端末は、待つことなく、即座にイメージファイルの送信を要求していた。
【０００６】
ソフトウェア・イメージ・ファイルのダウンロードは、一般にネットワーク及びヘッドエンドに非常に負担がかかるので、一度にダウンロードを行うことのできる端末の数は限定され、それを超える数の端末は、現在ダウンロードを行っている端末のいずれかがそのダウンロードを終了しないと、新しいダウンロードに参加できない。ダウンロードを必要とする各端末は、ファイルの要求を一斉に行うとともに、それらの全てのダウンロードリクエストに対して、ヘッドエンド側が一度に答えられない場合、ヘッドエンド側が他のリクエストを受け付けられた端末へのリクエストを行っている間も、リクエストを受け付けられなかった端末は、ヘッドエンド側にリクエストのやり直しを何度も行っていた。また、受け付けられるリクエストの順位は、実際には早い者勝ちであり、早くリクエストを行ったものほど早くダウンロードが行うことができた。
【０００７】
また、一般的にあるネットワークに属する各端末の機種が全て異なるということは考え難く、端末の数は非常に多いものの、特定の機種が数多くそのネットワークに存在したり、何種類かの機種だけによって構成されていたりする。場合によっては全ての端末が同じ機種から構成されているネットワークもある。このような場合、端末一つ一つに対して、個別にソフトウェアのダウンロードを行ったとき、ヘッドエンドの側から見れば、実際には同じファイルを何度も送信しつづけている、と見ることもできる。ダウンロードは各端末とヘッドエンドとの一対一の通信で行われているので、例えば同じ端末がそのネットワークの中に存在していた場合でも、ヘッドエンド側は同じファイルの送信を各端末に何度も繰り返していた。
【０００８】
【発明が解決しようとする課題】
このような従来のプログラムダウンロードシステム及びプログラムダウンロード方法にあっては、以下のような解決課題があった。
いま、新しいソフトウェアのイメージファイルが端末のベンダーから配布されたとする。このネットワークのネットワークオペレータが、各端末のソフトウェアを、このイメージファイルで書き換えようとしている。
【０００９】
ケーブルオペレータは、各端末の一つ一つに対して、ソフトウェアのアップグレードを手動で指示していく。このネットワーク上に接続されている端末は、数が非常に多いので、このように一台一台に指示をしていくのは、非常に手間がかかる。また、ネットワークオペレータのミスにより、指示をし忘れる端末もあるかも知れず、その場合、その端末はソフトウェアのアップグレードがされないという事故も発生した。また、アップグレードの前に、そもそも端末の各々がソフトのアップグレードが必要なのかどうか、すなわち各端末のソフトウェアは最新のものであるのかないのか、ネットワークオペレータが確認するという作業が必要であった。
【００１０】
また、仮に、ケーブルオペレータの作業を減らすために、ヘッドエンド側からでなく、端末側の主導でソフトウェアをアップグレードするとしても、端末側では、自分がソフトウェアをアップグレードすべきかどうか、判断することができなかった。特開平１１−３４５１１４号，特開平９−２９２９８０号，特開平８−１７９９５１号の各公報には、ある端末装置の、最新のソフトウェア・バージョンを端末側に通知する仕組みを持つシステムが開示されている。これらの公報に記載の方法では、各機種、若しくは各端末ごとにバージョンを通知しているので、実際にヘッドエンド側が発行するパケットの数は多く、結果として非常に広いネットワークの帯域を使用してしまい、また、ヘッドエンドの負担を重くしてしまうという問題点があった。
【００１１】
ネットワークを管理するケーブルオペレータは、そのネットワークにつながっている端末に、どんな機種が存在しているか即座には判断できず、また判断するためには一台一台のモデムに対して、ネットワーク経由で機種名を参照する必要がある。これには手間がかかり、また同様に、ネットワークオペレータのミスにより、一部の端末に対して参照をし忘れてしまうという事故も発生した。
【００１２】
端末のダウンロードにかかる時間は、オペレータが一台一台の端末に対してダウンロードを指示するのにかかる時間に比較して長く、ネットワーク全体の負荷の状態にもよるが、具体的にはおよそ１分から５分程度であることから、オペレータが一度に多くの端末にダウンロードの指示を行ってしまうと、同じ瞬間にダウンロードを行っている端末の数が急激に増加し、ネットワークや、ヘッドエンド側に対して非常に大きな負荷がかかってしまっていた。
【００１３】
また、端末がファイルをリクエストすると、ヘッドエンド側は即座にそのリクエストに対するサービスを開始していたので、優先順位の高いアップグレードが、後回しになってしまうこともあった。
【００１４】
また、端末がファイルを要求していても、ヘッドエンド側がそれにサービスできないでいると、端末がファイルを再要求してしまい、ネットワークやヘッドエンド側の負荷を減らすことができなかった。また、一定の回数、リクエストにサービスできないことが続くと、ダウンロードが必要であるにもかかわらず、端末がリクエストを諦める他なく、その場合はまた改めてネットワークオペレータがダウンロードを指示し直さなくてはならなかった。
【００１５】
また、端末側が行ったダウンロードのリクエストが、相手側（ヘッドエンド側）に受け付けられたことを知ったとしても、サービスがしばらく受けられないでいると、いつまで待っていればいいのかはっきりせず、実際には再度リクエストを行う必要があったのに行わなかったり、もう少し待てばサービスが開始されたのに、無駄に再リクエストを行ってしまったりする。
【００１６】
さらに、端末がファイルをリクエストする際、その端末はリクエストだけを行っているので、ヘッドエンド側は、どのような端末が、そのファイルのダウンロードを要求しているのか、その時点では判断することができなかった。
【００１７】
ヘッドエンド側の制限として、又はネットワークに負荷をかけ過ぎないようにするために、同時には一定の数しかダウンロードのサービスを行うことができないようにしたものもある。しかし、一定の数に制限するだけで優先順位を決めないため、実際にはダウンロードリクエストの先着順でダウンロードのサービスを行っているに過ぎず、ダウンロードの必要性の高いものでも後回しになってしまうこともあった。
【００１８】
ダウンロードは各端末とヘッドエンドとの一対一の通信で行われているので、例えば同じ端末がそのネットワークの中に存在していた場合でも、ヘッドエンド側は同じソフトウェアを各端末に何度も送信を繰り返している。そのため、ヘッドエンド側で、ダウンロードのプロセスが長時間にわたって継続されてしまい、ヘッドエンドの負荷を長時間にわたって下げることができないという問題点があった。
【００１９】
また、仮にヘッドエンド側が、同じイメージファイルを複数の端末に対して同時に送信を行ったとしても、全ての端末が必ず受信に成功する訳ではなく、この場合、不成功であった端末側が再送信のリクエストを行ったり、この端末側が受信確認応答を返してこなかったりするが、この端末への送信は失敗する。この場合の再送信の手順が用意されていなかった。
【００２０】
なお、このようなブロードキャスト通信やマルチキャスト通信は、公知の技術であって、これまでも使用されていたが、ソフトウェアファイルのダウンロードでブロードキャスト通信やマルチキャスト通信が行われることがなかったのは、上記の各問題点が解決されることがなかったためである。
【００２１】
本発明は、このような課題に鑑みてなされたものであって、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らして、手作業から生じる人為的作業ミスを未然に防ぐことができるとともに、ネットワーク及びサーバ装置の負荷を下げることができるプログラムダウンロードシステム及びプログラムダウンロード方法を提供することを目的とする。
【００２２】
【課題を解決するための手段】
本発明のプログラムダウンロードシステムは、ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロードシステムにおいて、前記端末は、前記サーバ装置の指示によらず、ソフトウェア・プログラムのダウンロードのリクエスト及びアップグレードを開始することを特徴とするものである。
【００２３】
また、前記サーバ装置は、最新のソフトウェアバージョン情報を示す一覧表を前記ネットワーク上に送信し、前記端末は、前記一覧表を参照して最新ソフトウェアバージョンが自端末にないとき、ダウンロードのリクエスト及びアップグレードを開始することで、サーバ装置側が、端末側に向けて、各端末の最新ソフトウェア一覧表を送信することによって、各端末が現時点で最新のソフトウェアのバージョンと、自分が現在実行しているソフトウェアのバージョンとを比較することにより、その端末がソフトウェアのダウンロードが必要かどうか、端末自身で判断することができる。また、一覧表の形で、単一の情報をネットワーク全体に配布することで、各端末若しくは各端末機種ごとに最新のバージョン情報を通知することに比べて、ネットワークの負荷を下げ、またサーバ装置の負荷も下げることができる。
【００２４】
また、前記サーバ装置は、ケーブル・ネットワーク上でソフトウェア・プログラムを送るためのヘッドエンドであり、前記端末は、前記ネットワーク上に接続されたケーブルモデム等であることで、端末がケーブル・ネットワーク上でヘッドエンド側からソフトウェア・プログラムをダウンロードする際、端末側の判断でダウンロードを要求し、ヘッドエンド側からダウンロードのきっかけを与えるのではないことから、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らすことができ、手作業から生じる人為的作業ミスを防ぐことができる。
【００２５】
本発明のプログラムダウンロード方法は、ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロード方法において、最新のソフトウェアバージョン情報を示す一覧表を前記ネットワーク上に送信するステップと、前記端末が、前記一覧表を参照して最新ソフトウェアバージョンが自端末にないとき、ダウンロードをリクエストするステップと、ダウンロードのリクエストに従って最新のソフトウェア・プログラムをダウンロードするステップと、ダウンロードされた前記ソフトウェア・プログラムに基づいてソフトウェア・プログラムをアップグレードするステップと、を順次実行することを特徴とする。
【００２６】
また、本発明のプログラムダウンロード方法は、ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロード方法において、前記端末自身の機種情報を含む最新のソフトウェアバージョン情報を要求するステップと、前記要求に応答して、前記端末の機種に対応するソフトウェア・プログラムの最新のバージョン情報を前記端末側に送信するステップと、前記最新バージョン情報に基づいて最新のソフトウェア・プログラムのダウンロードをリクエストするステップと、ダウンロードのリクエストに従って最新のソフトウェア・プログラムをダウンロードするステップと、ダウンロードされた前記ソフトウェア・プログラムに基づいてソフトウェア・プログラムをアップグレードするステップと、を順次実行することを特徴とする。
【００２７】
このように本発明のプログラムダウンロード方法は、前記一覧表に自分の機種用のソフトウェアに関する情報が記載されていなかった場合や、一覧表が送信されないネットワークシステムであった場合でも、端末側がサーバ装置側に、自分の機種に対するソフトウェアの最新のバージョンを確認できることで、その端末がソフトウェアのダウンロードが必要であるかどうか、端末自身で判断することができる。また、端末装置が勝手にバージョン情報データベースにアクセスするのではなく、サーバ装置側に連絡するように要求することから、このバージョン情報データベースを用意するかどうかに関係なく、サーバ装置側とは別途にデータベースを用意してもよいし、サーバ装置自身にデータベースを内包させてもよく、システムの設計に自由度が増す。
【００２８】
また、前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記端末側からのダウンロードのリクエストを受け付けた時点から一定時間経過後に、ダウンロードを開始することで、サーバ装置側が、各端末からのダウンロードリクエストに対して、即座にはサービスを開始せず、一定期間待つことによって、この待ち時間の間に、集まってきたリクエストを集計して、各リクエストに、ダウンロードを優先すべき緊急度の順位が存在するか判断でき、また、存在するとすれば、その優先順位の順位付けを行うことができる。
【００２９】
また、前記最新のソフトウェア・プログラムのダウンロードをリクエストするステップを実行した後、前記リクエストを行った端末に対して該リクエストを受け付けたことを示すメッセージを通知するステップをさらに実行するようにすれば、すぐにサービスは開始しないけれども、リクエストを再度行う必要はないということを端末側で判断することができる。この場合、前記メッセージには、前記受付の有効期限を示すタイムスタンプが含まれていてもよく、タイムスタンプを付加することにより、該当リクエストに対する受付はその期間有効であってその間は待つ必要があることと、またその期間までにサービスが開始されなければ、リクエストは破棄されたので再度リクエストを行う必要があることを、端末側で判断することができる。
【００３０】
また、前記最新のソフトウェア・プログラムのダウンロードをリクエストするステップでは、ソフトウェアバージョン等の前記リクエストを発行した端末に関する情報を添付することで、サーバ装置側で、これを元に、リクエストを発行した各端末に関して、ダウンロードの緊急度を判断することができる。また、端末側からのアップグレードリクエストに、この情報を添付することで、サーバ装置側から端末側に対して、その端末の情報を連絡するようにリクエストする必要がなくなる。
【００３１】
また、前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記リクエストに添付されている端末に関する情報に基づいて、ダウンロードの対象の端末に優先順位をつけてダウンロードすることで、致命的欠点のあるソフトウェアで動作している端末から優先的にソフトウェアのアップグレードを行うことでネットワークの安全性を高めたり、料率が高くサービスレベルの高い顧客が使用している端末から優先的にアップグレードを行うことで、顧客の満足度を高めることができる。
【００３２】
【発明の実施の形態】
以下、添付図面を参照しながら本発明の好適なプログラムダウンロードシステム及びプログラムダウンロード方法の実施の形態について詳細に説明する。
図１は、本発明の実施の形態のプログラムダウンロードシステムの構成を示す図である。
【００３３】
図１において、１１はヘッドエンド（Ｈ／Ｅ）装置（サーバ装置）、１２はツリー型のケーブル・ネットワーク、１３〜１６はケーブルモデム等からなる多数の端末Ａ，Ｂ，Ｃ，Ｄ、２１はヘッドエンド装置１１によってケーブル・ネットワーク１２上に送出される最新ソフトウェア一覧表２１である。
【００３４】
各端末１３（端末Ａ）、端末１４（端末Ｂ）、端末１５（端末Ｃ）及び端末１６（端末Ｄ）は、それぞれ機種が異なるものとする。端末１３〜１６（端末Ａ，Ｂ，Ｃ，Ｄ）には、ソフトウェアが組み込まれており、端末１３〜１６自身で、ケーブル・ネットワーク２経由で新しいソフトウェアをダウンロードして、ソフトウェアを書き換える機能を有する。
ヘッドエンド装置１１は、一定の期間ごとに、最新ソフトウェア一覧表２１を各端末に向けてネットワーク上に配布している。
【００３５】
最新ソフトウェア一覧表２１は、現在ヘッドエンド側で確認している各機種に対する最新ソフトウェアバージョンを含む情報を示す固有で単一の一覧表である。このソフトウェア一覧表２１は、単一のものであり、ソフトウェアの最新ソフトウェアバージョンを通知しようとする各端末の、各機種の関する情報は、すべてこのソフトウェア一覧表２１に記載されている。例えば、図１に示すように、ソフトウェア一覧表２１は、機種名Ａ，Ｂ，Ｃ…毎に、ソフトウェアバージョン“ａ−１”“ｂ−６”…が一覧表示されている。
【００３６】
ヘッドエンド装置１１は、ネットワーク１２上の各端末に対して、マルチキャスト／ブロードキャストによりこのソフトウェア一覧表２１を送信する。各機種に対して別々のバージョン情報を通知しているものではないことに注意が必要である。ネットワークオペレータは、ある端末のベンダーから、最新ソフトウェアがリリースされた場合には、ヘッドエンド装置１１側にこのソフトウェア・イメージ・ファイルを保存した上で、このソフトウェア一覧表２１を更新する必要がある。
【００３７】
以下、上述のように構成されたプログラムダウンロードシステム及びプログラムダウンロード方法の動作を説明する。
ヘッドエンド装置１１では、ネットワーク１２上の各端末に対して、マルチキャスト／ブロードキャストにより最新ソフトウェア一覧表２１を送信する。
【００３８】
各端末１３〜１６は、常にネットワーク１２上を監視して、このソフトウェア一覧表２１の配布に注意しておく。ソフトウェア一覧表２１が配布され、受信した場合は、このソフトウェア一覧表１２を見て、自端末がソフトウェアをアップデートする必要があるかどうかを判断し、必要があればヘッドエンド装置１１側に対してダウンロードを要求（リクエスト）する。この動作について具体的に説明する。
【００３９】
まず、端末１３（端末Ａ）について、自端末のソフトウェアが既に最新のものであったとすると、端末１３（端末Ａ）は、アップデートの必要なしと判断し、ダウンロードを要求しない。一方、端末１４（端末Ｂ）及び１６（端末Ｄ）は、動作しているソフトウェアが最新のものよりも古いものであったとすると、自端末ソフトウェアのバージョンと最新のソフトウェアのバージョンを比較して、自端末のソフトウェアは最新のものではないと判断する。これにより、端末１４（端末Ｂ）及び端末１６（端末Ｄ）は、ヘッドエンド装置１１側に対して、ダウンロードをリクエストする。
【００４０】
図２は、ソフトウェア一覧表２１の配布と端末によるリクエストを説明する図であり、ヘッドエンド装置１１側がソフトウェア一覧表２１を配布し、これを見た端末側がダウンロードのリクエストを行っている様子を示す。
【００４１】
図２に示すように、端末１４（端末Ｂ）は、ヘッドエンド装置１１が配布した最新ソフトウェア一覧表２１を見て、自端末のソフトウェアのバージョンと比較する。自端末のソフトウェアのバージョンは、現在“ｂ−１”であることが分かっている。そして、現在最新のソフトウェアのバージョンは、最新ソフトウェア一覧表２１によると、バージョン“ｂ−６”であった。この最新ソフトウェア一覧表２１を見て、端末Ｂは自端末に現在搭載されているソフトウェアのバージョンは“ｂ−１”であって、ソフトウェアが最新のものではないと判断し、ダウンロードのリクエスト２２を行う。ダウンロードリクエスト２２として、例えば「ソフト“ｂ−６”を要求」「サービスクラス」「現在のソフト」「ハードウェア」を送信し、ソフトウェアのリクエストと共に優先順位の参考になる情報を送信する。以上は、端末１４（端末Ｂ）についてのリクエスト送信であるが、端末１６（端末Ｄ）についても同一である。
ヘッドエンド装置１１は、各リクエストを集計してダウンロードの優先順位を決める。
【００４２】
図１に戻って、端末１５（端末Ｃ）に関しては、最新ソフトウェア一覧表２１を見て、自端末が動作しているソフトウェアのバージョンと最新のソフトウェアのバージョンを比較しようとするが、ヘッドエンド装置１１側が配布してきた最新ソフトウェア一覧表２１の中に、この端末１５（端末Ｃ）の機種に関して、最新のソフトウェアのバージョンに関する情報が記録されていなかった。端末１５（端末Ｃ）は、最新ソフトウェア一覧表２１に自端末の機種に関する最新ソフトウェアのバージョンを知るために、ヘッドエンド装置１１に対して、自端末の機種に対する最新のソフトウェアのバージョンを連絡するように、リクエストを行う。ヘッドエンド側は、これに応答して、端末１５（端末Ｃ）の機種に該当する最新のソフトウェアバージョンを連絡する。端末１５（端末Ｃ）は、直接バージョン情報データベースにアクセスする等ではなく、ヘッドエンド側に情報を連絡するよう、リクエストを行うことに注意されたい。
【００４３】
図３は、最新ソフトウェアのバージョンのリクエストを説明する図であり、端末側が、最新のソフトウェアのバージョンを連絡するようにヘッドエンド装置１１側に連絡して、ヘッドエンド装置１１側がこれに応えて端末側に連絡している様子を表している。
【００４４】
図３に示すように、端末１５（端末Ｃ）は、ヘッドエンド装置１１側に対して、最新のソフトウェアバージョン連絡要求２３を発行する。最新ソフトウェアバージョン連絡要求２３は、自端末の機種名と共に発行される。ヘッドエンド装置１１では、これを受けて最新のソフトウェアバージョン情報２４（ここではバージョン“ｃ−４”）を端末１５（端末Ｃ）に対して連絡する。
【００４５】
ヘッドエンド装置１１側は、これ以降は、最新ソフトウェア一覧表２１に、端末１５（端末Ｃ）の欄を加えて配布してもよい。このようにすれば、端末１５（端末Ｃ）は、これ以降は自端末の機種に関して、最新のソフトウェアのバージョンを連絡するようにリクエストする必要はなくなる。また、ネットワーク内で、この機種の個体数が少ない場合（これは端末Ｃの機種によるリクエストの総数で判断できる）、ネットワークの負荷を上げないように、配布する最新ソフトウェア一覧表２１の大きさを絞る目的で、最新ソフトウェア一覧表２１にこの機種を加えないようにしてもよい。
【００４６】
端末１５（端末Ｃ）は、連絡された最新のソフトウェアバージョンを見て、自端末のバージョンよりも新しいことを知り、ヘッドエンド装置１１に対してダウンロードをリクエストする。
【００４７】
ヘッドエンド装置１１は、リクエストを受け付けるが、すぐにサービスを行うことはなく、一定の期間、このリクエストの受付だけを行う。リクエストを行った各端末に対しては、ヘッドエンド装置１１はリクエストを受け付けたことを確認するためのメッセージを送信する。リクエストを行った各端末は、ヘッドエンド装置１１からのメッセージを見てリクエストが受け付けられたことを知り、サービスが開始されるまで待つ。また、この、受け付けを行ったことを示すメッセージには、この受付が有効な期間を示すタイムスタンプが付けられており、この期間の間にサービスが開始されなければ、ヘッドエンド装置１１はリクエストに対するサービスを処理できなかったので、もう一度、該当端末はヘッドエンド装置１１側にリクエストを再送する必要がある。
【００４８】
いま、一定の時間が終了し、ヘッドエンド装置１１がダウンロードリクエスト受付期間を終了したとする。各リクエストには、そのリクエストを発行した各端末に関する情報が記録されている。例えば、その端末が現在動作中のソフトウェアのバージョン、ハードウェアのバージョン、また、顧客の料率、この機種が発揮できる性能値などが、リクエストと一緒に記録されている。ヘッドエンド装置１１は、この情報を参照するが、注目すべき点は、この情報を得るために、ヘッドエンド装置１１が各端末側に対して、この情報を送信するようにリクエストを行っているのではなく、あくまでも端末側から、ヘッドエンド装置１１側に対して送信したアップグレードリクエストに、かかる情報が添付されていることである。
【００４９】
ソフトウェア・イメージ・ファイルのダウンロードは、一般にネットワーク、及びヘッドエンドに非常に負担がかかるので、一度にダウンロードを行うことのできる端末の数は限定されてしまう。ヘッドエンド装置１１は、これらの、リクエストの際に集められた情報を元に、各端末のダウンロードの優先順位を決定する。この優先順位の決定の様子を図４に示す。
【００５０】
図４は、優先順位の決定を説明する図であり、ヘッドエンド装置１１側が、各端末から寄せられたリクエストを元に、ダウンロードの優先順位を決定している様子を示している。
図４おいて、２５はヘッドエンド装置１１により参照されるダウンロードの優先順位、２６は各端末からのリクエストである。
【００５１】
ダウンロードの優先順位２５には、優先順位２５ａ、順番２５ｂ、端末名２５ｃ、ダウンロードするソフトウェア２５ｄの各項目に従って複数の優先順位が設けられている。図４では、ダウンロードの優先順位２５の左側が優先順位が高く、右側が低い。また、一度にダウンロードできる端末の数は、例えば３（図４網がけ部分参照）であり上位から指定される。ここでは、順番「４」の端末名「Ｆ」以降がダウンロード順番待ちとなる。また、各端末からのリクエスト２６は、図２のダウンロードのリクエスト２２と同一である。
【００５２】
図４に示すように、ヘッドエンド装置１１では、リクエスト受付期間に各端末からヘッドエンドに寄せられたリクエスト２６を集計し、これらの情報を元に、ヘッドエンド装置１１はダウンロードのサービスを行う優先順位２５を決定する。ヘッドエンド装置１１が一度に対応できなかった端末は、現在ダウンロードを行っている端末のいずれかがそのダウンロードを終了しないと、新しいダウンロードに参加できない。したがって、実際には、各端末は順番を待ってダウンロードを行うことになるが、この場合、ヘッドエンド装置１１は、各端末から集められた各端末の情報を元に、各端末のダウンロードを行う優先順位を決めることができる。
【００５３】
例えば、ある機種に搭載されて動作しているソフトウェアに、非常に致命的な欠陥があることが判明し、これによりネットワーク全体に対して悪影響を及ぼすことが懸念されている場合は、ネットワークオペレータの判断で、この機種のソフトウェアのアップデートを最優先に行うように各端末のダウンロードの優先願位を決定することができる。
【００５４】
また、高い料率の顧客が使用している端末から、優先的にソフトウェアのアップデートを行うように各端末のダウンロードの優先順位を決定することができる。さらに、小さいサイズのソフトウェアファイルの端末は、その分早くダウンロードが完了することから、各端末機種のソフトウェアファイルの大きさを見て、大きさの小さいものからダウンロードを優先させることで、できるだけ早い段階で、アップグレード完了した端末の数を確保する（すなわち、早いものから先に終わらせようとする）こともできる。
【００５５】
また、各端末の事情、例えば、ダウンロードを必要とはするが、現在通信中であり、今すぐにはダウンロードを受けることはできないという場合、その端末は優先順位を下げることができる。一方、各端末からの情報とは無関係に、各端末のダウンロードの優先順位を決定してもかまわない。
【００５６】
上述したプログラムダウンロードシステム及びプログラムダウンロード方法の動作をフローチャートを参照して更に詳細に説明する。
図５は、端末側での動作を示すフローチャートであり、端末側でのダウンロードの流れを示している。図中、Ｓはフローの各ステップを示す。
【００５７】
まず、ステップＳ１で最新ソフトウェア一覧表２１（図２参照）が到着したか否かを判別し、最新ソフトウェア一覧表２１が到着していなければ到着するまで待つ。最新ソフトウェア一覧表２１が到着したときは、ステップＳ２で到着した最新ソフトウェア一覧表２１に自端末の機種について記載されているか否かを判別する。
【００５８】
自端末の機種について記載されているときは、ステップＳ３で最新ソフトウェア一覧表２１の中で最新バージョンを確認してステップＳ６に進む。自端末の機種について記載されていないときは、ステップＳ４でヘッドエンド装置１１に自端末の機種でのソフトウェア最新バージョンを通知するようにリクエストする。このとき、ソフトウェア最新バージョンのリクエストと共に優先順位の参考になる情報を送信する（図２のリクエスト２２参照）。
【００５９】
ステップＳ５でヘッドエンド装置１１からの最新バージョンの連絡を受けると、ステップＳ６で送信された最新バージョンを元にソフトウェアを更新するか否かを判別し、ソフトウェアを更新しない場合はそのまま本フローを終了する。ソフトウェアを更新する場合は、ステップＳ７でヘッドエンド装置１１に対してダウンロードをリクエストする。次いで、ステップＳ８でヘッドエンド装置１１からのメッセージにより、ダウンロードのリクエストが受け付けられたか否かを判別し、受け付けられていなければステップＳ７に戻ってダウンロードをリクエストする。
【００６０】
リクエストが受け付けられたときは、ステップＳ９でヘッドエンド装置１１からのダウンロードの開始の通知を受信したか否かを判別し、ダウンロードの開始の通知を受信していなければ受信するまで待つ。ダウンロードの開始の通知を受信したときは、ステップＳ１０でソフトウェア・イメージ・ファイルをダウンロードし、ソフトウェアをアップグレードして本フローを終了する。
【００６１】
このように、ヘッドエンド装置１１が、ネットワーク１２に接続されている各端末について、最新ソフトウェアバージョン一覧表２１を送信すると、各端末はこの最新ソフトウェアバージョン一覧表２１を閲覧し、各端末はこの最新ソフトウェアバージョン一覧表２１を元に最新ソフトウェアバージョンを確認し、ヘッドエンド装置１１側の指示ではなく、端末側の判断で、ダウンロード、アップグレードを開始する。
【００６２】
図６は、ヘッドエンド側での動作を示すフローチャートであり、ヘッドエンド側でのダウンロードの流れを示す。
まず、ステップＳ１１で最新ソフトウェア一覧表２１（図２参照）をネットワーク１２上に配布する。次いで、ステップＳ１２で最新ソフトウェア一覧表２１に載っていない端末からの確認リクエストを受信したか否かを判別し、確認リクエストを受信したときはステップＳ１３で最新ソフトウェア一覧表２１に載っていない端末にバージョンを通知してステップＳ１４に進む。ステップＳ１２で確認リクエストを受信しなかったときは、そのままステップＳ１４に進む。
【００６３】
ステップＳ１４では、ダウンロードリクエストを受信したか否かを判別し、ダウンロードリクエストを受信していなければ受信するまで待つ。ダウンロードリクエストを受信すると、ステップＳ１５でそのリクエストを記録し、ステップＳ１６で該当端末に対してリクエストを受け付けたことを通知する。
【００６４】
次いで、ステップＳ１７でリクエスト受け付け期間が終了したか否かを判別し、リクエスト受け付け期間が終了していなければステップＳ１４に戻る。リクエスト受け付け期間が終了したときは、ステップＳ１８で各リクエストを集計してダウンロードの優先順位を決定し、ステップＳ１９で優先順位の高い順にダウンロードを実行する。次いで、ステップＳ２０でリクエストした端末全数に対してダウンロードを終了したか否かを判別し、ダウンロードが終了していなければステップＳ１９に戻ってリクエストした端末全数が終了するまでダウンロードを実行する。リクエストした端末全数に対してダウンロードを終了すると本フローを終える。
【００６５】
ところで、一般的にあるネットワークに属する各端末の機種が全て異なるということは考え難く、端末の数は非常に多いが、ある機種が数多くそのネットワークに存在したり、何種類かの機種だけによって構成されていたりする。場合によっては全ての端末が同じ機種から構成されているネットワークも見られる。このような場合、端末一つ一つに対して、個別にソフトウェアのダウンロードを行った場合、ヘッドエンド側から見れば、実際には同じファイルを何度も送信しつづけていると見ることもできる。
【００６６】
本実施の形態のネットワーク１２では、同じ機種に対するダウンロードでは、一度にファイルの送信を行う。ヘッドエンド装置１１は、各端末に対して、このネットワーク１２内にブロードキャスト／マルチキャスト通信で該当ファイルを送信する。
【００６７】
各端末は、ブロードキャスト／マルチキャスト通信で送信されたファイルを受け取るが、送信対象の各端末の全てが、このファイルのダウンロードに成功して、このファイルの送信の受信に成功するとは限らない。受信に失敗した各端末は、ダウンロードが一旦終了するまで何もせず、終了してから、ダウンロードに失敗した部分の送信を、ヘッドエンド装置１１に対してもう一度要求（リクエスト）する。ヘッドエンド装置１１は、そのリクエストを受けて、端末が受信に失敗した部分だけを再度送信する。このときの様子を、図７に示す。
【００６８】
図７は、ヘッドエンド装置１１が、ブロードキャスト／マルチキャスト通信でダウンロードを行っている様子を説明する図である。
図７において、１１はヘッドエンド装置、３１，３２，３３は端末、３４はヘッドエンド装置１１によりダウンロードするソフトウェア・イメージ・ファイル、３５はダウンロードしたが、一部受信できなかったソフトウェア・イメージ・ファイル、３６はダウンロードしたが、一部受信できなかったソフトウェア・イメージ・ファイル、３７はダウンロードして、全部受信に成功したソフトウェア・イメージ・ファイル、３８はソフトウェア・イメージ・ファイル３６のうち、ダウンロードに失敗して、受信できなかった部分、３９はソフトウェア・イメージ・ファイル３６のうち、他の部分は失敗したが、ダウンロードに成功して、受信できた部分である。また、図７のソフトウェア・イメージ・ファイル３５，３６のハッチング部分は、ダウンロードしたソフトウェア・イメージ・ファイルのうち受信できなかった部分を示し、この部分だけ後でもう一度リクエストすることを示している。
【００６９】
ヘッドエンド装置１１が、同じ機種の各端末３１，３２，３３に、一度にダウンロードを行う。すなわち、各端末３１，３２，３３が同じソフトウェアを要求している場合は、送り先を複数にして、一度にダウンロードを行う。ところが、全ての端末がダウンロードに完全に成功した訳ではなくて、一部の端末が、ファイルを完全には受信できなかった。端末３３は全部受信に成功したソフトウェア・イメージ・ファイル３７を受信成功した。端末３１及び端末３２は、ファイルのある一部を受信できなかったので、これを再度リクエストを行う必要があるが、最初のダウンロードが終了しないうちにリクエストを行うと、この最初のダウンロード全体に影響を及ぼすため、この最初のダウンロードが一旦終了するまで、再送要求のリクエストは行わない。ダウンロード終了を待って、端末３１は、受信できなかった部分の再送要求リクエストを行う。端末３２に関して、ダウンロードに失敗して受信できなかった部分３８が受信できなかったので、この部分３８だけ、ヘッドエンド装置１１に対して、再度送信をリクエストする。
【００７０】
以上のように、本実施の形態のプログラムダウンロードシステムは、ソフトウェア・プログラムをネットワーク１２上に配布するヘッドエンド装置１１と、ヘッドエンド装置１１によってネットワーク１２上に送出される最新ソフトウェア一覧表２１と、ネットワーク１２に接続され、ヘッドエンド装置１１から最新のソフトウェア・プログラムがダウンロードされる多数の端末１３〜１６とを備え、各端末１３〜１６は、最新ソフトウェアバージョン一覧表２１を閲覧して、最新ソフトウェアバージョンを確認し、ヘッドエンド装置１１側の指示によらず、端末側の判断でソフトウェア・イメージ・ファイル（ソフトウェア・プログラム）のダウンロードのリクエスト及びアップグレードを開始するようにしたので、端末側の判断でダウンロードを要求し、ヘッドエンド装置１１側からダウンロードのきっかけを与えるのではないことから、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らすことができ、手作業から生じる人為的作業ミスを未然に防ぐことができる。
【００７１】
また、ヘッドエンド装置１１側が、端末側に向けて、各端末１３〜１６の最新ソフトウェア情報を一覧表２１の形で、単一の情報をネットワーク１２全体に配布することで、各端末１３〜１６若しくは各端末機種ごとに最新のバージョン情報を通知する場合に比べて、ネットワーク１２の負荷を下げ、またヘッドエンド装置１１の負荷も下げることができる。
【００７２】
また、本実施の形態では、リクエストを受け付けたことを示すメッセージを各端末１３〜１６に向けてヘッドエンド装置１１が送信することによって、すぐにサービスは開始しないけれども、リクエストを再度行う必要はないということを、端末側で判断することができる。
【００７３】
また、ダウンロードリクエストを受け付けたことを示すメッセージに、有効期限を示したタイムスタンプをつけることで、このリクエストに対する受付はその期間有効であってその間は待つ必要があることと、またその期間までにサービスが開始されなければ、リクエストは破棄されたので再度リクエストを行う必要があることを、端末側で判断することができる。
【００７４】
また、本実施の形態では、端末側がヘッドエンド装置１１側に向けて発行したダウンロード・リクエストの中に、現在のソフトウェアバージョンに加え、そのリクエストを発行した端末に関する情報を添付していることで、ヘッドエンド装置１１側で、この情報を元に、リクエストを発行した各端末に関して、ダウンロードの緊急度を判断することができる。また、端末側からのアップグレードリクエストに、この情報を添付することで、ヘッドエンド装置１１側から端末側に対して、その端末の情報を連絡するようにリクエストする必要がなくなる。
【００７５】
また、各端末からのダウンロードリクエストに添付されている端末情報を元に、ヘッドエンド装置１１が各端末へのダウンロードに優先順位を付けることから、致命的欠点のあるソフトウェアで動作している端末から優先的にソフトウェアのアップグレードを行うことでネットワークの安全性を高めたり、料率が高くサービスレベルの高い顧客が使用している端末から優先的にアップグレードを行うことで、顧客の満足度を高めたりすることができる。
【００７６】
また、ダウンロードの際、ファイルを一方的にブロードキャスト、又はマルチキャストし、複数の端末が同時にこれを受信することによって、同じファイルを、端末の数だけ、何度も送信する必要がなく、ダウンロードにかかる時間を削減することができる。
【００７７】
さらに、各端末１３〜１６に同時に送信されるブロードキャスト／マルチキャスト通信によるダウンロードを行う際、ある端末がダウンロードされてきたソフトウェア・イメージ・ファイルの一部が受信できなかった場合でも、その部分だけを送りなおすようにヘッドエンド装置１１側にリクエストすることができる。また、ブロードキャスト／マルチキャスト通信によるダウンロードの最中に再送リクエストを行わないことで、ソフトウェア・ダウンロードについてブロードキャスト・マルチキャスト通信を行うことが可能になり、ネットワーク１２及びヘッドエンド装置１１に無駄な負荷がかからないようにすることができる。
【００７８】
なお、上記実施の形態では、ＣＡＴＶシステムのプログラムダウンロードシステム及びプログラムダウンロード方法に適用した例であるが、プログラムを転送するプログラムダウンロード方法であればどのようなシステムにも適用可能である。
また、上記プログラムダウンロードシステムを構成する各装置、例えばヘッドエンドやネットワークの種類、数及び接続方法などは前述した実施の形態に限られない。
【００７９】
【発明の効果】
以上、詳述したように、本発明によれば、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らして、手作業から生じる人為的作業ミスを未然に防ぐことができるとともに、ネットワーク及びサーバ装置の負荷を下げることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態のプログラムダウンロードシステムの構成を示す図である。
【図２】本実施の形態のプログラムダウンロードシステムのソフトウェア一覧表の配布と端末によるリクエストを説明する図である。
【図３】本実施の形態のプログラムダウンロードシステムの最新ソフトウェアのバージョンのリクエストを説明する図である。
【図４】本実施の形態のプログラムダウンロードシステムの優先順位の決定を説明する図である。
【図５】本実施の形態のプログラムダウンロードシステムの端末側での動作を示すフローチャートである。
【図６】本実施の形態のプログラムダウンロードシステムのヘッドエンド側での動作を示すフローチャートである。
【図７】本実施の形態のプログラムダウンロードシステムのヘッドエンド装置が、ブロードキャスト／マルチキャスト通信でダウンロードを行っている様子を説明する図である。
【図８】従来のプログラムダウンロード方式の構成を示す図である。
【符号の説明】
１１  ヘッドエンド（Ｈ／Ｅ）装置（サーバ装置）
１２  ケーブル・ネットワーク
１３〜１６，２３〜２５  端末
２１  最新ソフトウェア一覧表
２２  ダウンロードのリクエスト
２３  最新ソフトウェア連絡リクエスト
２４  最新ソフトウェア連絡
２５  ダウンロードの優先順位
２６  端末からのリクエスト
３４  ダウンロードするソフトウェアイメージファイル
３５，３６  一部受信できなかったソフトウェア・イメージ・ファイル
３７  全部受信に成功したソフトウェア・イメージ・ファイル
３８  ダウンロードに失敗して、受信できなかった部分
３９  他の部分は失敗したが、ダウンロードに成功して、受信できた部分
【図１】
0003833045.tif 000002
【図２】
0003833045.tif 000003
【図３】
0003833045.tif 000004
【図４】
0003833045.tif 000005
【図５】
0003833045.tif 000006
【図６】
0003833045.tif 000007
【図７】
0003833045.tif 000008
【図８】
0003833045.tif 000009