JP3833045B2

JP3833045B2 - Program download system and program download method

Info

Publication number: JP3833045B2
Application number: JP2000113813A
Authority: JP
Inventors: 城久千葉
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2000-04-14
Filing date: 2000-04-14
Publication date: 2006-10-11
Anticipated expiration: 2020-04-14
Also published as: JP2001296994A

Description

【０００１】
【発明の属する技術分野】
本発明は、プログラムダウンロードシステム及びプログラムダウンロード方法に関し、詳細には、少数のヘッドエンド（Ｈ／Ｅ）装置に対して、ケーブルモデム等の端末が多数存在するツリー型のネットワークにおいて、端末装置が自分自身のソフトウェアをアップグレードする際に行うプログラムダウンロードシステム及びプログラムダウンロード方法に関する。
【０００２】
【従来の技術】
ＣＡＴＶ（Cable Television）は、同軸ケーブルや光ファイバ・ケーブルを用いてＴＶ番組を分配するシステムである。ＣＡＴＶシステムで、ＴＶ信号などをＣＡＴＶケーブルに送出する設備はヘッドエンド（headend）と呼ばれる。ヘッドエンド設備では、分配する番組をそれぞれのチャンネルの周波数に並べて、アクセスネットワークと呼ばれるケーブルに送信する。ケーブルは、幹線、分岐線、分配線の多段ツリーあるいは多段スター構造となっている。
【０００３】
図８は、従来のプログラムダウンロード方式の構成を示す図である。
図８において、１はヘッドエンド（Ｈ／Ｅ）装置、２はツリー型のケーブル・ネットワーク、３〜６はケーブルモデム等からなる多数の端末Ａ，Ｂ，Ｃ，Ｄである。
【０００４】
これら端末３〜６（端末Ａ，Ｂ，Ｃ，Ｄ）には、ソフトウェアが組み込まれている。また、端末３〜６自身で、ケーブル・ネットワーク２経由で新しいソフトウェアをダウンロードして、ソフトウェアを書き換える機能を有する。ベンダー（Vendor）がこの端末を販売した後、機能の追加があったり、販売時には発見できなかったソフトウェア上の問題点を解決したりした場合、ベンダーはこれに対応した新しいソフトウェアを開発し、上記書き換え機能を用いて、各端末のソフトウェアを書き換えることができる。
【０００５】
このように、ネットワーク経由で、新しいソフトウェアをダウンロードして、ソフトウェアを書き換える場合、ヘッドエンド側から、端末の一台一台に対して、ケーブルオペレータ（管理者）が手動で、ダウンロードの指示を行っていた。指示を受けた各端末は、待つことなく、即座にイメージファイルの送信を要求していた。
【０００６】
ソフトウェア・イメージ・ファイルのダウンロードは、一般にネットワーク及びヘッドエンドに非常に負担がかかるので、一度にダウンロードを行うことのできる端末の数は限定され、それを超える数の端末は、現在ダウンロードを行っている端末のいずれかがそのダウンロードを終了しないと、新しいダウンロードに参加できない。ダウンロードを必要とする各端末は、ファイルの要求を一斉に行うとともに、それらの全てのダウンロードリクエストに対して、ヘッドエンド側が一度に答えられない場合、ヘッドエンド側が他のリクエストを受け付けられた端末へのリクエストを行っている間も、リクエストを受け付けられなかった端末は、ヘッドエンド側にリクエストのやり直しを何度も行っていた。また、受け付けられるリクエストの順位は、実際には早い者勝ちであり、早くリクエストを行ったものほど早くダウンロードが行うことができた。
【０００７】
また、一般的にあるネットワークに属する各端末の機種が全て異なるということは考え難く、端末の数は非常に多いものの、特定の機種が数多くそのネットワークに存在したり、何種類かの機種だけによって構成されていたりする。場合によっては全ての端末が同じ機種から構成されているネットワークもある。このような場合、端末一つ一つに対して、個別にソフトウェアのダウンロードを行ったとき、ヘッドエンドの側から見れば、実際には同じファイルを何度も送信しつづけている、と見ることもできる。ダウンロードは各端末とヘッドエンドとの一対一の通信で行われているので、例えば同じ端末がそのネットワークの中に存在していた場合でも、ヘッドエンド側は同じファイルの送信を各端末に何度も繰り返していた。
【０００８】
【発明が解決しようとする課題】
このような従来のプログラムダウンロードシステム及びプログラムダウンロード方法にあっては、以下のような解決課題があった。
いま、新しいソフトウェアのイメージファイルが端末のベンダーから配布されたとする。このネットワークのネットワークオペレータが、各端末のソフトウェアを、このイメージファイルで書き換えようとしている。
【０００９】
ケーブルオペレータは、各端末の一つ一つに対して、ソフトウェアのアップグレードを手動で指示していく。このネットワーク上に接続されている端末は、数が非常に多いので、このように一台一台に指示をしていくのは、非常に手間がかかる。また、ネットワークオペレータのミスにより、指示をし忘れる端末もあるかも知れず、その場合、その端末はソフトウェアのアップグレードがされないという事故も発生した。また、アップグレードの前に、そもそも端末の各々がソフトのアップグレードが必要なのかどうか、すなわち各端末のソフトウェアは最新のものであるのかないのか、ネットワークオペレータが確認するという作業が必要であった。
【００１０】
また、仮に、ケーブルオペレータの作業を減らすために、ヘッドエンド側からでなく、端末側の主導でソフトウェアをアップグレードするとしても、端末側では、自分がソフトウェアをアップグレードすべきかどうか、判断することができなかった。特開平１１−３４５１１４号，特開平９−２９２９８０号，特開平８−１７９９５１号の各公報には、ある端末装置の、最新のソフトウェア・バージョンを端末側に通知する仕組みを持つシステムが開示されている。これらの公報に記載の方法では、各機種、若しくは各端末ごとにバージョンを通知しているので、実際にヘッドエンド側が発行するパケットの数は多く、結果として非常に広いネットワークの帯域を使用してしまい、また、ヘッドエンドの負担を重くしてしまうという問題点があった。
【００１１】
ネットワークを管理するケーブルオペレータは、そのネットワークにつながっている端末に、どんな機種が存在しているか即座には判断できず、また判断するためには一台一台のモデムに対して、ネットワーク経由で機種名を参照する必要がある。これには手間がかかり、また同様に、ネットワークオペレータのミスにより、一部の端末に対して参照をし忘れてしまうという事故も発生した。
【００１２】
端末のダウンロードにかかる時間は、オペレータが一台一台の端末に対してダウンロードを指示するのにかかる時間に比較して長く、ネットワーク全体の負荷の状態にもよるが、具体的にはおよそ１分から５分程度であることから、オペレータが一度に多くの端末にダウンロードの指示を行ってしまうと、同じ瞬間にダウンロードを行っている端末の数が急激に増加し、ネットワークや、ヘッドエンド側に対して非常に大きな負荷がかかってしまっていた。
【００１３】
また、端末がファイルをリクエストすると、ヘッドエンド側は即座にそのリクエストに対するサービスを開始していたので、優先順位の高いアップグレードが、後回しになってしまうこともあった。
【００１４】
また、端末がファイルを要求していても、ヘッドエンド側がそれにサービスできないでいると、端末がファイルを再要求してしまい、ネットワークやヘッドエンド側の負荷を減らすことができなかった。また、一定の回数、リクエストにサービスできないことが続くと、ダウンロードが必要であるにもかかわらず、端末がリクエストを諦める他なく、その場合はまた改めてネットワークオペレータがダウンロードを指示し直さなくてはならなかった。
【００１５】
また、端末側が行ったダウンロードのリクエストが、相手側（ヘッドエンド側）に受け付けられたことを知ったとしても、サービスがしばらく受けられないでいると、いつまで待っていればいいのかはっきりせず、実際には再度リクエストを行う必要があったのに行わなかったり、もう少し待てばサービスが開始されたのに、無駄に再リクエストを行ってしまったりする。
【００１６】
さらに、端末がファイルをリクエストする際、その端末はリクエストだけを行っているので、ヘッドエンド側は、どのような端末が、そのファイルのダウンロードを要求しているのか、その時点では判断することができなかった。
【００１７】
ヘッドエンド側の制限として、又はネットワークに負荷をかけ過ぎないようにするために、同時には一定の数しかダウンロードのサービスを行うことができないようにしたものもある。しかし、一定の数に制限するだけで優先順位を決めないため、実際にはダウンロードリクエストの先着順でダウンロードのサービスを行っているに過ぎず、ダウンロードの必要性の高いものでも後回しになってしまうこともあった。
【００１８】
ダウンロードは各端末とヘッドエンドとの一対一の通信で行われているので、例えば同じ端末がそのネットワークの中に存在していた場合でも、ヘッドエンド側は同じソフトウェアを各端末に何度も送信を繰り返している。そのため、ヘッドエンド側で、ダウンロードのプロセスが長時間にわたって継続されてしまい、ヘッドエンドの負荷を長時間にわたって下げることができないという問題点があった。
【００１９】
また、仮にヘッドエンド側が、同じイメージファイルを複数の端末に対して同時に送信を行ったとしても、全ての端末が必ず受信に成功する訳ではなく、この場合、不成功であった端末側が再送信のリクエストを行ったり、この端末側が受信確認応答を返してこなかったりするが、この端末への送信は失敗する。この場合の再送信の手順が用意されていなかった。
【００２０】
なお、このようなブロードキャスト通信やマルチキャスト通信は、公知の技術であって、これまでも使用されていたが、ソフトウェアファイルのダウンロードでブロードキャスト通信やマルチキャスト通信が行われることがなかったのは、上記の各問題点が解決されることがなかったためである。
【００２１】
本発明は、このような課題に鑑みてなされたものであって、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らして、手作業から生じる人為的作業ミスを未然に防ぐことができるとともに、ネットワーク及びサーバ装置の負荷を下げることができるプログラムダウンロードシステム及びプログラムダウンロード方法を提供することを目的とする。
【００２２】
【課題を解決するための手段】
本発明のプログラムダウンロードシステムは、ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロードシステムにおいて、前記端末は、前記サーバ装置の指示によらず、ソフトウェア・プログラムのダウンロードのリクエスト及びアップグレードを開始することを特徴とするものである。
【００２３】
また、前記サーバ装置は、最新のソフトウェアバージョン情報を示す一覧表を前記ネットワーク上に送信し、前記端末は、前記一覧表を参照して最新ソフトウェアバージョンが自端末にないとき、ダウンロードのリクエスト及びアップグレードを開始することで、サーバ装置側が、端末側に向けて、各端末の最新ソフトウェア一覧表を送信することによって、各端末が現時点で最新のソフトウェアのバージョンと、自分が現在実行しているソフトウェアのバージョンとを比較することにより、その端末がソフトウェアのダウンロードが必要かどうか、端末自身で判断することができる。また、一覧表の形で、単一の情報をネットワーク全体に配布することで、各端末若しくは各端末機種ごとに最新のバージョン情報を通知することに比べて、ネットワークの負荷を下げ、またサーバ装置の負荷も下げることができる。
【００２４】
また、前記サーバ装置は、ケーブル・ネットワーク上でソフトウェア・プログラムを送るためのヘッドエンドであり、前記端末は、前記ネットワーク上に接続されたケーブルモデム等であることで、端末がケーブル・ネットワーク上でヘッドエンド側からソフトウェア・プログラムをダウンロードする際、端末側の判断でダウンロードを要求し、ヘッドエンド側からダウンロードのきっかけを与えるのではないことから、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らすことができ、手作業から生じる人為的作業ミスを防ぐことができる。
【００２５】
本発明のプログラムダウンロード方法は、ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロード方法において、最新のソフトウェアバージョン情報を示す一覧表を前記ネットワーク上に送信するステップと、前記端末が、前記一覧表を参照して最新ソフトウェアバージョンが自端末にないとき、ダウンロードをリクエストするステップと、ダウンロードのリクエストに従って最新のソフトウェア・プログラムをダウンロードするステップと、ダウンロードされた前記ソフトウェア・プログラムに基づいてソフトウェア・プログラムをアップグレードするステップと、を順次実行することを特徴とする。
【００２６】
また、本発明のプログラムダウンロード方法は、ソフトウェア・プログラムをネットワーク上に配布するサーバ装置と、前記ネットワークに接続された多数の端末とを備え、前記端末が使用するソフトウェア・プログラムを前記サーバ装置側から前記端末側にダウンロードして、前記端末側のソフトウェア・プログラムをアップグレードするプログラムダウンロード方法において、前記端末自身の機種情報を含む最新のソフトウェアバージョン情報を要求するステップと、前記要求に応答して、前記端末の機種に対応するソフトウェア・プログラムの最新のバージョン情報を前記端末側に送信するステップと、前記最新バージョン情報に基づいて最新のソフトウェア・プログラムのダウンロードをリクエストするステップと、ダウンロードのリクエストに従って最新のソフトウェア・プログラムをダウンロードするステップと、ダウンロードされた前記ソフトウェア・プログラムに基づいてソフトウェア・プログラムをアップグレードするステップと、を順次実行することを特徴とする。
【００２７】
このように本発明のプログラムダウンロード方法は、前記一覧表に自分の機種用のソフトウェアに関する情報が記載されていなかった場合や、一覧表が送信されないネットワークシステムであった場合でも、端末側がサーバ装置側に、自分の機種に対するソフトウェアの最新のバージョンを確認できることで、その端末がソフトウェアのダウンロードが必要であるかどうか、端末自身で判断することができる。また、端末装置が勝手にバージョン情報データベースにアクセスするのではなく、サーバ装置側に連絡するように要求することから、このバージョン情報データベースを用意するかどうかに関係なく、サーバ装置側とは別途にデータベースを用意してもよいし、サーバ装置自身にデータベースを内包させてもよく、システムの設計に自由度が増す。
【００２８】
また、前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記端末側からのダウンロードのリクエストを受け付けた時点から一定時間経過後に、ダウンロードを開始することで、サーバ装置側が、各端末からのダウンロードリクエストに対して、即座にはサービスを開始せず、一定期間待つことによって、この待ち時間の間に、集まってきたリクエストを集計して、各リクエストに、ダウンロードを優先すべき緊急度の順位が存在するか判断でき、また、存在するとすれば、その優先順位の順位付けを行うことができる。
【００２９】
また、前記最新のソフトウェア・プログラムのダウンロードをリクエストするステップを実行した後、前記リクエストを行った端末に対して該リクエストを受け付けたことを示すメッセージを通知するステップをさらに実行するようにすれば、すぐにサービスは開始しないけれども、リクエストを再度行う必要はないということを端末側で判断することができる。この場合、前記メッセージには、前記受付の有効期限を示すタイムスタンプが含まれていてもよく、タイムスタンプを付加することにより、該当リクエストに対する受付はその期間有効であってその間は待つ必要があることと、またその期間までにサービスが開始されなければ、リクエストは破棄されたので再度リクエストを行う必要があることを、端末側で判断することができる。
【００３０】
また、前記最新のソフトウェア・プログラムのダウンロードをリクエストするステップでは、ソフトウェアバージョン等の前記リクエストを発行した端末に関する情報を添付することで、サーバ装置側で、これを元に、リクエストを発行した各端末に関して、ダウンロードの緊急度を判断することができる。また、端末側からのアップグレードリクエストに、この情報を添付することで、サーバ装置側から端末側に対して、その端末の情報を連絡するようにリクエストする必要がなくなる。
【００３１】
また、前記最新のソフトウェア・プログラムをダウンロードするステップでは、前記リクエストに添付されている端末に関する情報に基づいて、ダウンロードの対象の端末に優先順位をつけてダウンロードすることで、致命的欠点のあるソフトウェアで動作している端末から優先的にソフトウェアのアップグレードを行うことでネットワークの安全性を高めたり、料率が高くサービスレベルの高い顧客が使用している端末から優先的にアップグレードを行うことで、顧客の満足度を高めることができる。
【００３２】
【発明の実施の形態】
以下、添付図面を参照しながら本発明の好適なプログラムダウンロードシステム及びプログラムダウンロード方法の実施の形態について詳細に説明する。
図１は、本発明の実施の形態のプログラムダウンロードシステムの構成を示す図である。
【００３３】
図１において、１１はヘッドエンド（Ｈ／Ｅ）装置（サーバ装置）、１２はツリー型のケーブル・ネットワーク、１３〜１６はケーブルモデム等からなる多数の端末Ａ，Ｂ，Ｃ，Ｄ、２１はヘッドエンド装置１１によってケーブル・ネットワーク１２上に送出される最新ソフトウェア一覧表２１である。
【００３４】
各端末１３（端末Ａ）、端末１４（端末Ｂ）、端末１５（端末Ｃ）及び端末１６（端末Ｄ）は、それぞれ機種が異なるものとする。端末１３〜１６（端末Ａ，Ｂ，Ｃ，Ｄ）には、ソフトウェアが組み込まれており、端末１３〜１６自身で、ケーブル・ネットワーク２経由で新しいソフトウェアをダウンロードして、ソフトウェアを書き換える機能を有する。
ヘッドエンド装置１１は、一定の期間ごとに、最新ソフトウェア一覧表２１を各端末に向けてネットワーク上に配布している。
【００３５】
最新ソフトウェア一覧表２１は、現在ヘッドエンド側で確認している各機種に対する最新ソフトウェアバージョンを含む情報を示す固有で単一の一覧表である。このソフトウェア一覧表２１は、単一のものであり、ソフトウェアの最新ソフトウェアバージョンを通知しようとする各端末の、各機種の関する情報は、すべてこのソフトウェア一覧表２１に記載されている。例えば、図１に示すように、ソフトウェア一覧表２１は、機種名Ａ，Ｂ，Ｃ…毎に、ソフトウェアバージョン“ａ−１”“ｂ−６”…が一覧表示されている。
【００３６】
ヘッドエンド装置１１は、ネットワーク１２上の各端末に対して、マルチキャスト／ブロードキャストによりこのソフトウェア一覧表２１を送信する。各機種に対して別々のバージョン情報を通知しているものではないことに注意が必要である。ネットワークオペレータは、ある端末のベンダーから、最新ソフトウェアがリリースされた場合には、ヘッドエンド装置１１側にこのソフトウェア・イメージ・ファイルを保存した上で、このソフトウェア一覧表２１を更新する必要がある。
【００３７】
以下、上述のように構成されたプログラムダウンロードシステム及びプログラムダウンロード方法の動作を説明する。
ヘッドエンド装置１１では、ネットワーク１２上の各端末に対して、マルチキャスト／ブロードキャストにより最新ソフトウェア一覧表２１を送信する。
【００３８】
各端末１３〜１６は、常にネットワーク１２上を監視して、このソフトウェア一覧表２１の配布に注意しておく。ソフトウェア一覧表２１が配布され、受信した場合は、このソフトウェア一覧表１２を見て、自端末がソフトウェアをアップデートする必要があるかどうかを判断し、必要があればヘッドエンド装置１１側に対してダウンロードを要求（リクエスト）する。この動作について具体的に説明する。
【００３９】
まず、端末１３（端末Ａ）について、自端末のソフトウェアが既に最新のものであったとすると、端末１３（端末Ａ）は、アップデートの必要なしと判断し、ダウンロードを要求しない。一方、端末１４（端末Ｂ）及び１６（端末Ｄ）は、動作しているソフトウェアが最新のものよりも古いものであったとすると、自端末ソフトウェアのバージョンと最新のソフトウェアのバージョンを比較して、自端末のソフトウェアは最新のものではないと判断する。これにより、端末１４（端末Ｂ）及び端末１６（端末Ｄ）は、ヘッドエンド装置１１側に対して、ダウンロードをリクエストする。
【００４０】
図２は、ソフトウェア一覧表２１の配布と端末によるリクエストを説明する図であり、ヘッドエンド装置１１側がソフトウェア一覧表２１を配布し、これを見た端末側がダウンロードのリクエストを行っている様子を示す。
【００４１】
図２に示すように、端末１４（端末Ｂ）は、ヘッドエンド装置１１が配布した最新ソフトウェア一覧表２１を見て、自端末のソフトウェアのバージョンと比較する。自端末のソフトウェアのバージョンは、現在“ｂ−１”であることが分かっている。そして、現在最新のソフトウェアのバージョンは、最新ソフトウェア一覧表２１によると、バージョン“ｂ−６”であった。この最新ソフトウェア一覧表２１を見て、端末Ｂは自端末に現在搭載されているソフトウェアのバージョンは“ｂ−１”であって、ソフトウェアが最新のものではないと判断し、ダウンロードのリクエスト２２を行う。ダウンロードリクエスト２２として、例えば「ソフト“ｂ−６”を要求」「サービスクラス」「現在のソフト」「ハードウェア」を送信し、ソフトウェアのリクエストと共に優先順位の参考になる情報を送信する。以上は、端末１４（端末Ｂ）についてのリクエスト送信であるが、端末１６（端末Ｄ）についても同一である。
ヘッドエンド装置１１は、各リクエストを集計してダウンロードの優先順位を決める。
【００４２】
図１に戻って、端末１５（端末Ｃ）に関しては、最新ソフトウェア一覧表２１を見て、自端末が動作しているソフトウェアのバージョンと最新のソフトウェアのバージョンを比較しようとするが、ヘッドエンド装置１１側が配布してきた最新ソフトウェア一覧表２１の中に、この端末１５（端末Ｃ）の機種に関して、最新のソフトウェアのバージョンに関する情報が記録されていなかった。端末１５（端末Ｃ）は、最新ソフトウェア一覧表２１に自端末の機種に関する最新ソフトウェアのバージョンを知るために、ヘッドエンド装置１１に対して、自端末の機種に対する最新のソフトウェアのバージョンを連絡するように、リクエストを行う。ヘッドエンド側は、これに応答して、端末１５（端末Ｃ）の機種に該当する最新のソフトウェアバージョンを連絡する。端末１５（端末Ｃ）は、直接バージョン情報データベースにアクセスする等ではなく、ヘッドエンド側に情報を連絡するよう、リクエストを行うことに注意されたい。
【００４３】
図３は、最新ソフトウェアのバージョンのリクエストを説明する図であり、端末側が、最新のソフトウェアのバージョンを連絡するようにヘッドエンド装置１１側に連絡して、ヘッドエンド装置１１側がこれに応えて端末側に連絡している様子を表している。
【００４４】
図３に示すように、端末１５（端末Ｃ）は、ヘッドエンド装置１１側に対して、最新のソフトウェアバージョン連絡要求２３を発行する。最新ソフトウェアバージョン連絡要求２３は、自端末の機種名と共に発行される。ヘッドエンド装置１１では、これを受けて最新のソフトウェアバージョン情報２４（ここではバージョン“ｃ−４”）を端末１５（端末Ｃ）に対して連絡する。
【００４５】
ヘッドエンド装置１１側は、これ以降は、最新ソフトウェア一覧表２１に、端末１５（端末Ｃ）の欄を加えて配布してもよい。このようにすれば、端末１５（端末Ｃ）は、これ以降は自端末の機種に関して、最新のソフトウェアのバージョンを連絡するようにリクエストする必要はなくなる。また、ネットワーク内で、この機種の個体数が少ない場合（これは端末Ｃの機種によるリクエストの総数で判断できる）、ネットワークの負荷を上げないように、配布する最新ソフトウェア一覧表２１の大きさを絞る目的で、最新ソフトウェア一覧表２１にこの機種を加えないようにしてもよい。
【００４６】
端末１５（端末Ｃ）は、連絡された最新のソフトウェアバージョンを見て、自端末のバージョンよりも新しいことを知り、ヘッドエンド装置１１に対してダウンロードをリクエストする。
【００４７】
ヘッドエンド装置１１は、リクエストを受け付けるが、すぐにサービスを行うことはなく、一定の期間、このリクエストの受付だけを行う。リクエストを行った各端末に対しては、ヘッドエンド装置１１はリクエストを受け付けたことを確認するためのメッセージを送信する。リクエストを行った各端末は、ヘッドエンド装置１１からのメッセージを見てリクエストが受け付けられたことを知り、サービスが開始されるまで待つ。また、この、受け付けを行ったことを示すメッセージには、この受付が有効な期間を示すタイムスタンプが付けられており、この期間の間にサービスが開始されなければ、ヘッドエンド装置１１はリクエストに対するサービスを処理できなかったので、もう一度、該当端末はヘッドエンド装置１１側にリクエストを再送する必要がある。
【００４８】
いま、一定の時間が終了し、ヘッドエンド装置１１がダウンロードリクエスト受付期間を終了したとする。各リクエストには、そのリクエストを発行した各端末に関する情報が記録されている。例えば、その端末が現在動作中のソフトウェアのバージョン、ハードウェアのバージョン、また、顧客の料率、この機種が発揮できる性能値などが、リクエストと一緒に記録されている。ヘッドエンド装置１１は、この情報を参照するが、注目すべき点は、この情報を得るために、ヘッドエンド装置１１が各端末側に対して、この情報を送信するようにリクエストを行っているのではなく、あくまでも端末側から、ヘッドエンド装置１１側に対して送信したアップグレードリクエストに、かかる情報が添付されていることである。
【００４９】
ソフトウェア・イメージ・ファイルのダウンロードは、一般にネットワーク、及びヘッドエンドに非常に負担がかかるので、一度にダウンロードを行うことのできる端末の数は限定されてしまう。ヘッドエンド装置１１は、これらの、リクエストの際に集められた情報を元に、各端末のダウンロードの優先順位を決定する。この優先順位の決定の様子を図４に示す。
【００５０】
図４は、優先順位の決定を説明する図であり、ヘッドエンド装置１１側が、各端末から寄せられたリクエストを元に、ダウンロードの優先順位を決定している様子を示している。
図４おいて、２５はヘッドエンド装置１１により参照されるダウンロードの優先順位、２６は各端末からのリクエストである。
【００５１】
ダウンロードの優先順位２５には、優先順位２５ａ、順番２５ｂ、端末名２５ｃ、ダウンロードするソフトウェア２５ｄの各項目に従って複数の優先順位が設けられている。図４では、ダウンロードの優先順位２５の左側が優先順位が高く、右側が低い。また、一度にダウンロードできる端末の数は、例えば３（図４網がけ部分参照）であり上位から指定される。ここでは、順番「４」の端末名「Ｆ」以降がダウンロード順番待ちとなる。また、各端末からのリクエスト２６は、図２のダウンロードのリクエスト２２と同一である。
【００５２】
図４に示すように、ヘッドエンド装置１１では、リクエスト受付期間に各端末からヘッドエンドに寄せられたリクエスト２６を集計し、これらの情報を元に、ヘッドエンド装置１１はダウンロードのサービスを行う優先順位２５を決定する。ヘッドエンド装置１１が一度に対応できなかった端末は、現在ダウンロードを行っている端末のいずれかがそのダウンロードを終了しないと、新しいダウンロードに参加できない。したがって、実際には、各端末は順番を待ってダウンロードを行うことになるが、この場合、ヘッドエンド装置１１は、各端末から集められた各端末の情報を元に、各端末のダウンロードを行う優先順位を決めることができる。
【００５３】
例えば、ある機種に搭載されて動作しているソフトウェアに、非常に致命的な欠陥があることが判明し、これによりネットワーク全体に対して悪影響を及ぼすことが懸念されている場合は、ネットワークオペレータの判断で、この機種のソフトウェアのアップデートを最優先に行うように各端末のダウンロードの優先願位を決定することができる。
【００５４】
また、高い料率の顧客が使用している端末から、優先的にソフトウェアのアップデートを行うように各端末のダウンロードの優先順位を決定することができる。さらに、小さいサイズのソフトウェアファイルの端末は、その分早くダウンロードが完了することから、各端末機種のソフトウェアファイルの大きさを見て、大きさの小さいものからダウンロードを優先させることで、できるだけ早い段階で、アップグレード完了した端末の数を確保する（すなわち、早いものから先に終わらせようとする）こともできる。
【００５５】
また、各端末の事情、例えば、ダウンロードを必要とはするが、現在通信中であり、今すぐにはダウンロードを受けることはできないという場合、その端末は優先順位を下げることができる。一方、各端末からの情報とは無関係に、各端末のダウンロードの優先順位を決定してもかまわない。
【００５６】
上述したプログラムダウンロードシステム及びプログラムダウンロード方法の動作をフローチャートを参照して更に詳細に説明する。
図５は、端末側での動作を示すフローチャートであり、端末側でのダウンロードの流れを示している。図中、Ｓはフローの各ステップを示す。
【００５７】
まず、ステップＳ１で最新ソフトウェア一覧表２１（図２参照）が到着したか否かを判別し、最新ソフトウェア一覧表２１が到着していなければ到着するまで待つ。最新ソフトウェア一覧表２１が到着したときは、ステップＳ２で到着した最新ソフトウェア一覧表２１に自端末の機種について記載されているか否かを判別する。
【００５８】
自端末の機種について記載されているときは、ステップＳ３で最新ソフトウェア一覧表２１の中で最新バージョンを確認してステップＳ６に進む。自端末の機種について記載されていないときは、ステップＳ４でヘッドエンド装置１１に自端末の機種でのソフトウェア最新バージョンを通知するようにリクエストする。このとき、ソフトウェア最新バージョンのリクエストと共に優先順位の参考になる情報を送信する（図２のリクエスト２２参照）。
【００５９】
ステップＳ５でヘッドエンド装置１１からの最新バージョンの連絡を受けると、ステップＳ６で送信された最新バージョンを元にソフトウェアを更新するか否かを判別し、ソフトウェアを更新しない場合はそのまま本フローを終了する。ソフトウェアを更新する場合は、ステップＳ７でヘッドエンド装置１１に対してダウンロードをリクエストする。次いで、ステップＳ８でヘッドエンド装置１１からのメッセージにより、ダウンロードのリクエストが受け付けられたか否かを判別し、受け付けられていなければステップＳ７に戻ってダウンロードをリクエストする。
【００６０】
リクエストが受け付けられたときは、ステップＳ９でヘッドエンド装置１１からのダウンロードの開始の通知を受信したか否かを判別し、ダウンロードの開始の通知を受信していなければ受信するまで待つ。ダウンロードの開始の通知を受信したときは、ステップＳ１０でソフトウェア・イメージ・ファイルをダウンロードし、ソフトウェアをアップグレードして本フローを終了する。
【００６１】
このように、ヘッドエンド装置１１が、ネットワーク１２に接続されている各端末について、最新ソフトウェアバージョン一覧表２１を送信すると、各端末はこの最新ソフトウェアバージョン一覧表２１を閲覧し、各端末はこの最新ソフトウェアバージョン一覧表２１を元に最新ソフトウェアバージョンを確認し、ヘッドエンド装置１１側の指示ではなく、端末側の判断で、ダウンロード、アップグレードを開始する。
【００６２】
図６は、ヘッドエンド側での動作を示すフローチャートであり、ヘッドエンド側でのダウンロードの流れを示す。
まず、ステップＳ１１で最新ソフトウェア一覧表２１（図２参照）をネットワーク１２上に配布する。次いで、ステップＳ１２で最新ソフトウェア一覧表２１に載っていない端末からの確認リクエストを受信したか否かを判別し、確認リクエストを受信したときはステップＳ１３で最新ソフトウェア一覧表２１に載っていない端末にバージョンを通知してステップＳ１４に進む。ステップＳ１２で確認リクエストを受信しなかったときは、そのままステップＳ１４に進む。
【００６３】
ステップＳ１４では、ダウンロードリクエストを受信したか否かを判別し、ダウンロードリクエストを受信していなければ受信するまで待つ。ダウンロードリクエストを受信すると、ステップＳ１５でそのリクエストを記録し、ステップＳ１６で該当端末に対してリクエストを受け付けたことを通知する。
【００６４】
次いで、ステップＳ１７でリクエスト受け付け期間が終了したか否かを判別し、リクエスト受け付け期間が終了していなければステップＳ１４に戻る。リクエスト受け付け期間が終了したときは、ステップＳ１８で各リクエストを集計してダウンロードの優先順位を決定し、ステップＳ１９で優先順位の高い順にダウンロードを実行する。次いで、ステップＳ２０でリクエストした端末全数に対してダウンロードを終了したか否かを判別し、ダウンロードが終了していなければステップＳ１９に戻ってリクエストした端末全数が終了するまでダウンロードを実行する。リクエストした端末全数に対してダウンロードを終了すると本フローを終える。
【００６５】
ところで、一般的にあるネットワークに属する各端末の機種が全て異なるということは考え難く、端末の数は非常に多いが、ある機種が数多くそのネットワークに存在したり、何種類かの機種だけによって構成されていたりする。場合によっては全ての端末が同じ機種から構成されているネットワークも見られる。このような場合、端末一つ一つに対して、個別にソフトウェアのダウンロードを行った場合、ヘッドエンド側から見れば、実際には同じファイルを何度も送信しつづけていると見ることもできる。
【００６６】
本実施の形態のネットワーク１２では、同じ機種に対するダウンロードでは、一度にファイルの送信を行う。ヘッドエンド装置１１は、各端末に対して、このネットワーク１２内にブロードキャスト／マルチキャスト通信で該当ファイルを送信する。
【００６７】
各端末は、ブロードキャスト／マルチキャスト通信で送信されたファイルを受け取るが、送信対象の各端末の全てが、このファイルのダウンロードに成功して、このファイルの送信の受信に成功するとは限らない。受信に失敗した各端末は、ダウンロードが一旦終了するまで何もせず、終了してから、ダウンロードに失敗した部分の送信を、ヘッドエンド装置１１に対してもう一度要求（リクエスト）する。ヘッドエンド装置１１は、そのリクエストを受けて、端末が受信に失敗した部分だけを再度送信する。このときの様子を、図７に示す。
【００６８】
図７は、ヘッドエンド装置１１が、ブロードキャスト／マルチキャスト通信でダウンロードを行っている様子を説明する図である。
図７において、１１はヘッドエンド装置、３１，３２，３３は端末、３４はヘッドエンド装置１１によりダウンロードするソフトウェア・イメージ・ファイル、３５はダウンロードしたが、一部受信できなかったソフトウェア・イメージ・ファイル、３６はダウンロードしたが、一部受信できなかったソフトウェア・イメージ・ファイル、３７はダウンロードして、全部受信に成功したソフトウェア・イメージ・ファイル、３８はソフトウェア・イメージ・ファイル３６のうち、ダウンロードに失敗して、受信できなかった部分、３９はソフトウェア・イメージ・ファイル３６のうち、他の部分は失敗したが、ダウンロードに成功して、受信できた部分である。また、図７のソフトウェア・イメージ・ファイル３５，３６のハッチング部分は、ダウンロードしたソフトウェア・イメージ・ファイルのうち受信できなかった部分を示し、この部分だけ後でもう一度リクエストすることを示している。
【００６９】
ヘッドエンド装置１１が、同じ機種の各端末３１，３２，３３に、一度にダウンロードを行う。すなわち、各端末３１，３２，３３が同じソフトウェアを要求している場合は、送り先を複数にして、一度にダウンロードを行う。ところが、全ての端末がダウンロードに完全に成功した訳ではなくて、一部の端末が、ファイルを完全には受信できなかった。端末３３は全部受信に成功したソフトウェア・イメージ・ファイル３７を受信成功した。端末３１及び端末３２は、ファイルのある一部を受信できなかったので、これを再度リクエストを行う必要があるが、最初のダウンロードが終了しないうちにリクエストを行うと、この最初のダウンロード全体に影響を及ぼすため、この最初のダウンロードが一旦終了するまで、再送要求のリクエストは行わない。ダウンロード終了を待って、端末３１は、受信できなかった部分の再送要求リクエストを行う。端末３２に関して、ダウンロードに失敗して受信できなかった部分３８が受信できなかったので、この部分３８だけ、ヘッドエンド装置１１に対して、再度送信をリクエストする。
【００７０】
以上のように、本実施の形態のプログラムダウンロードシステムは、ソフトウェア・プログラムをネットワーク１２上に配布するヘッドエンド装置１１と、ヘッドエンド装置１１によってネットワーク１２上に送出される最新ソフトウェア一覧表２１と、ネットワーク１２に接続され、ヘッドエンド装置１１から最新のソフトウェア・プログラムがダウンロードされる多数の端末１３〜１６とを備え、各端末１３〜１６は、最新ソフトウェアバージョン一覧表２１を閲覧して、最新ソフトウェアバージョンを確認し、ヘッドエンド装置１１側の指示によらず、端末側の判断でソフトウェア・イメージ・ファイル（ソフトウェア・プログラム）のダウンロードのリクエスト及びアップグレードを開始するようにしたので、端末側の判断でダウンロードを要求し、ヘッドエンド装置１１側からダウンロードのきっかけを与えるのではないことから、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らすことができ、手作業から生じる人為的作業ミスを未然に防ぐことができる。
【００７１】
また、ヘッドエンド装置１１側が、端末側に向けて、各端末１３〜１６の最新ソフトウェア情報を一覧表２１の形で、単一の情報をネットワーク１２全体に配布することで、各端末１３〜１６若しくは各端末機種ごとに最新のバージョン情報を通知する場合に比べて、ネットワーク１２の負荷を下げ、またヘッドエンド装置１１の負荷も下げることができる。
【００７２】
また、本実施の形態では、リクエストを受け付けたことを示すメッセージを各端末１３〜１６に向けてヘッドエンド装置１１が送信することによって、すぐにサービスは開始しないけれども、リクエストを再度行う必要はないということを、端末側で判断することができる。
【００７３】
また、ダウンロードリクエストを受け付けたことを示すメッセージに、有効期限を示したタイムスタンプをつけることで、このリクエストに対する受付はその期間有効であってその間は待つ必要があることと、またその期間までにサービスが開始されなければ、リクエストは破棄されたので再度リクエストを行う必要があることを、端末側で判断することができる。
【００７４】
また、本実施の形態では、端末側がヘッドエンド装置１１側に向けて発行したダウンロード・リクエストの中に、現在のソフトウェアバージョンに加え、そのリクエストを発行した端末に関する情報を添付していることで、ヘッドエンド装置１１側で、この情報を元に、リクエストを発行した各端末に関して、ダウンロードの緊急度を判断することができる。また、端末側からのアップグレードリクエストに、この情報を添付することで、ヘッドエンド装置１１側から端末側に対して、その端末の情報を連絡するようにリクエストする必要がなくなる。
【００７５】
また、各端末からのダウンロードリクエストに添付されている端末情報を元に、ヘッドエンド装置１１が各端末へのダウンロードに優先順位を付けることから、致命的欠点のあるソフトウェアで動作している端末から優先的にソフトウェアのアップグレードを行うことでネットワークの安全性を高めたり、料率が高くサービスレベルの高い顧客が使用している端末から優先的にアップグレードを行うことで、顧客の満足度を高めたりすることができる。
【００７６】
また、ダウンロードの際、ファイルを一方的にブロードキャスト、又はマルチキャストし、複数の端末が同時にこれを受信することによって、同じファイルを、端末の数だけ、何度も送信する必要がなく、ダウンロードにかかる時間を削減することができる。
【００７７】
さらに、各端末１３〜１６に同時に送信されるブロードキャスト／マルチキャスト通信によるダウンロードを行う際、ある端末がダウンロードされてきたソフトウェア・イメージ・ファイルの一部が受信できなかった場合でも、その部分だけを送りなおすようにヘッドエンド装置１１側にリクエストすることができる。また、ブロードキャスト／マルチキャスト通信によるダウンロードの最中に再送リクエストを行わないことで、ソフトウェア・ダウンロードについてブロードキャスト・マルチキャスト通信を行うことが可能になり、ネットワーク１２及びヘッドエンド装置１１に無駄な負荷がかからないようにすることができる。
【００７８】
なお、上記実施の形態では、ＣＡＴＶシステムのプログラムダウンロードシステム及びプログラムダウンロード方法に適用した例であるが、プログラムを転送するプログラムダウンロード方法であればどのようなシステムにも適用可能である。
また、上記プログラムダウンロードシステムを構成する各装置、例えばヘッドエンドやネットワークの種類、数及び接続方法などは前述した実施の形態に限られない。
【００７９】
【発明の効果】
以上、詳述したように、本発明によれば、端末側のソフトウェアのアップグレードに関して、ネットワークオペレータの作業を減らして、手作業から生じる人為的作業ミスを未然に防ぐことができるとともに、ネットワーク及びサーバ装置の負荷を下げることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態のプログラムダウンロードシステムの構成を示す図である。
【図２】本実施の形態のプログラムダウンロードシステムのソフトウェア一覧表の配布と端末によるリクエストを説明する図である。
【図３】本実施の形態のプログラムダウンロードシステムの最新ソフトウェアのバージョンのリクエストを説明する図である。
【図４】本実施の形態のプログラムダウンロードシステムの優先順位の決定を説明する図である。
【図５】本実施の形態のプログラムダウンロードシステムの端末側での動作を示すフローチャートである。
【図６】本実施の形態のプログラムダウンロードシステムのヘッドエンド側での動作を示すフローチャートである。
【図７】本実施の形態のプログラムダウンロードシステムのヘッドエンド装置が、ブロードキャスト／マルチキャスト通信でダウンロードを行っている様子を説明する図である。
【図８】従来のプログラムダウンロード方式の構成を示す図である。
【符号の説明】
１１ヘッドエンド（Ｈ／Ｅ）装置（サーバ装置）
１２ケーブル・ネットワーク
１３〜１６，２３〜２５端末
２１最新ソフトウェア一覧表
２２ダウンロードのリクエスト
２３最新ソフトウェア連絡リクエスト
２４最新ソフトウェア連絡
２５ダウンロードの優先順位
２６端末からのリクエスト
３４ダウンロードするソフトウェアイメージファイル
３５，３６一部受信できなかったソフトウェア・イメージ・ファイル
３７全部受信に成功したソフトウェア・イメージ・ファイル
３８ダウンロードに失敗して、受信できなかった部分
３９他の部分は失敗したが、ダウンロードに成功して、受信できた部分[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a program download system and a program download method. More specifically, the present invention relates to a tree-type network in which a large number of terminals such as cable modems exist for a small number of headend (H / E) devices. The present invention relates to a program download system and a program download method performed when upgrading its own software.
[0002]
[Prior art]
CATV (Cable Television) is a system that distributes TV programs using coaxial cables or optical fiber cables. In the CATV system, a facility for sending a TV signal or the like to a CATV cable is called a headend. In the headend equipment, the program to be distributed is arranged on the frequency of each channel and transmitted to a cable called an access network. The cable has a multi-stage tree or a multi-stage star structure of trunk lines, branch lines, and distribution lines.
[0003]
FIG. 8 is a diagram showing a configuration of a conventional program download method.
In FIG. 8, 1 is a head end (H / E) device, 2 is a tree-type cable network, and 3 to 6 are a large number of terminals A, B, C, and D, each of which is a cable modem or the like.
[0004]
Software is incorporated in these terminals 3 to 6 (terminals A, B, C, and D). The terminals 3 to 6 themselves have a function of downloading new software via the cable network 2 and rewriting the software. If a vendor (Vendor) sells this device and adds functionality or solves a software problem that could not be found at the time of sale, the vendor will develop a new software that supports this, Software of each terminal can be rewritten using the rewriting function.
[0005]
In this way, when downloading new software over the network and rewriting the software, the cable operator (administrator) manually instructs the download from the headend to each terminal. It was. Each terminal that received the instruction requested transmission of the image file immediately without waiting.
[0006]
Downloading software image files generally imposes a heavy burden on the network and headend, so the number of terminals that can be downloaded at one time is limited, and more terminals are currently downloading If one of the devices does not finish the download, it cannot participate in the new download. Each terminal that needs to download downloads all the files at the same time, and if the headend cannot answer all of these download requests at once, the headend will go to the terminal that has accepted other requests. While the request was made, the terminal that could not accept the request repeatedly sent the request to the headend side. In addition, the order of the accepted requests was actually the first-come-first-served basis, and the earlier the request was made, the faster the download was possible.
[0007]
In general, it is difficult to think that the models of each terminal belonging to a network are all different, and although there are a large number of terminals, there are many specific models in the network or depending on only a few types of models. It is composed. In some cases, there are networks in which all terminals are composed of the same model. In such a case, when downloading software individually to each terminal, seeing from the head end side, the same file is actually being sent many times. You can also. Since the download is performed by one-to-one communication between each terminal and the headend, for example, even if the same terminal exists in the network, the headend side sends the same file to each terminal many times. Also repeated.
[0008]
[Problems to be solved by the invention]
Such conventional program download systems and program download methods have the following solutions.
Suppose that a new software image file is distributed from a terminal vendor. The network operator of this network tries to rewrite the software of each terminal with this image file.
[0009]
The cable operator manually instructs each terminal individually to upgrade the software. Since there are a large number of terminals connected on this network, it is very time-consuming to give instructions to each one in this way. In addition, there may be a terminal forgetting to give an instruction due to a mistake of the network operator. In this case, an accident that the terminal is not upgraded with software has occurred. In addition, before the upgrade, it is necessary for the network operator to check whether each terminal needs software upgrade, that is, whether the software of each terminal is the latest.
[0010]
In addition, even if the software is upgraded not at the head end side but at the terminal side in order to reduce the work of the cable operator, the terminal side can determine whether or not the software should be upgraded. There wasn't. JP-A-11-345114, JP-A-9-292980, and JP-A-8-179951 disclose a system having a mechanism for notifying the terminal side of the latest software version of a terminal device. Yes. In the methods described in these publications, since the version is notified for each model or each terminal, the number of packets actually issued by the headend side is large, and as a result, a very wide network bandwidth is used. In addition, there is a problem that the burden on the head end is increased.
[0011]
The cable operator who manages the network cannot immediately determine what kind of model exists in the terminal connected to the network, and in order to make a determination, each modem needs to be connected via the network. It is necessary to refer to the model name. This took time, and there was also an accident in which it was forgotten to refer to some terminals due to a mistake of the network operator.
[0012]
The time required for downloading the terminal is longer than the time required for the operator to instruct each terminal to download, and it depends on the load state of the entire network. From 5 minutes to 5 minutes, if the operator gives instructions for downloading to many terminals at once, the number of terminals downloading at the same moment will increase rapidly, On the other hand, a very large load was applied.
[0013]
In addition, when a terminal requests a file, the headend side immediately starts a service for the request, so that a high-priority upgrade may be postponed.
[0014]
Further, even if the terminal requests a file, if the head end side cannot service it, the terminal re-requests the file, and the load on the network and the head end side cannot be reduced. If the request cannot be serviced for a certain number of times, the terminal must give up the request even though the download is necessary. In that case, the network operator must give another instruction to download again. There wasn't.
[0015]
Also, even if you know that the download request made by the device has been accepted by the other party (headend side), if you have not received the service for a while, it is not clear how long you should wait, Actually, it was necessary to make a request again, but not, or after a while, the service was started, but the request was made in vain.
[0016]
In addition, when a terminal requests a file, that terminal only makes the request, so the headend can determine at what point the terminal is requesting the file to be downloaded. could not.
[0017]
In some cases, only a certain number of download services can be provided at the same time as a limitation on the head end side or in order not to overload the network. However, since the priority is not determined just by limiting to a certain number, the download service is actually provided only on a first-come-first-served basis of download requests, and even those with high download necessity will be delayed. There was also.
[0018]
Since the download is performed by one-to-one communication between each terminal and the headend, for example, even if the same terminal exists in the network, the headend side sends the same software to each terminal many times. Is repeated. For this reason, the download process is continued on the head end side for a long time, and the load on the head end cannot be lowered for a long time.
[0019]
Also, even if the headend side transmits the same image file to multiple terminals at the same time, not all terminals will always succeed in receiving, and in this case, the unsuccessful terminal side will retransmit The terminal side does not return a reception confirmation response, but transmission to this terminal fails. There was no procedure for re-transmission in this case.
[0020]
Note that such broadcast communication and multicast communication are known techniques and have been used until now. However, the broadcast communication and multicast communication were not performed when the software file was downloaded. This is because each problem has not been solved.
[0021]
The present invention has been made in view of such problems, and it is possible to reduce the work of the network operator and prevent human error caused by manual work in advance regarding the software upgrade on the terminal side. Another object of the present invention is to provide a program download system and a program download method that can reduce the load on the network and the server device.
[0022]
[Means for Solving the Problems]
The program download system of the present invention comprises a server device that distributes a software program over a network and a number of terminals connected to the network, and the software program used by the terminal is transmitted from the server device side to the terminal. In the program download system for downloading to the terminal side and upgrading the software program on the terminal side, the terminal starts a request for downloading the software program and an upgrade regardless of an instruction from the server device. To do.
[0023]
Further, the server device transmits a list showing the latest software version information to the network, and the terminal refers to the list and download request and upgrade when the latest software version is not in its own terminal. By sending the latest software list of each terminal to the terminal side, the server device side sends the latest software version of each terminal, and the software version currently being executed by each terminal. By comparing the version, it is possible for the terminal itself to determine whether the terminal needs to download software. Also, by distributing a single piece of information to the entire network in the form of a list, the load on the network is reduced compared to notifying the latest version information for each terminal or each terminal model, and the server device Can also reduce the load.
[0024]
The server device is a head end for sending a software program on a cable network, and the terminal is a cable modem or the like connected on the network. When downloading a software program from the head end side, the download is requested at the terminal side, and the download end is not given from the head end side. It is possible to reduce human error caused by manual work.
[0025]
The program download method of the present invention comprises a server device for distributing a software program on a network and a number of terminals connected to the network, and the software program used by the terminal is transmitted from the server device side to the terminal. In the program download method for downloading to the terminal and upgrading the software program on the terminal side, a step of transmitting a list showing the latest software version information on the network, and the terminal refers to the list Requesting download when the latest software version is not in the terminal, downloading the latest software program according to the download request, and the downloaded software And to execute the steps of upgrading the software program, the sequence based on the program.
[0026]
The program download method of the present invention comprises a server device that distributes a software program on a network and a large number of terminals connected to the network, and the software program used by the terminal is transmitted from the server device side. In the program download method for downloading to the terminal side and upgrading the software program on the terminal side, requesting the latest software version information including model information of the terminal itself, and in response to the request, Sending the latest version information of the software program corresponding to the terminal model to the terminal, requesting the download of the latest software program based on the latest version information, Wherein the step of downloading the latest software program, the steps to upgrade the software program on the basis of said software program downloaded, to sequentially performed according Quest.
[0027]
Thus, in the program download method of the present invention, the terminal side is the server device side even when the information regarding the software for its model is not described in the list, or even when the list is not transmitted. In addition, since the latest version of the software for the model of the user can be confirmed, the terminal itself can determine whether the terminal needs to download the software. In addition, since the terminal device does not access the version information database without permission, it requests to contact the server device side. Therefore, regardless of whether or not this version information database is prepared, it is separately from the server device side. A database may be prepared, or the database may be included in the server device itself, increasing the degree of freedom in system design.
[0028]
In addition, in the step of downloading the latest software program, the server device side makes a download request from each terminal by starting the download after a lapse of a certain time from the time when the download request from the terminal is received. On the other hand, by not waiting for a certain period of time instead of starting the service immediately, the requests gathered during this waiting time are aggregated, and each request has a priority level of priority for download. If it exists, the priorities can be ranked.
[0029]
Further, after executing the step of requesting the download of the latest software program, further executing a step of notifying a message indicating that the request has been accepted to the terminal that has made the request, Although the service does not start immediately, it can be determined on the terminal side that it is not necessary to make the request again. In this case, the message may include a time stamp indicating the expiration date of the reception. By adding the time stamp, the reception for the corresponding request is valid for the period, and it is necessary to wait during that time. In addition, if the service is not started by that period, the terminal can determine that the request has been discarded and the request needs to be made again.
[0030]
In addition, in the step of requesting the download of the latest software program, the server device side attaches information on the terminal that issued the request such as a software version, and each terminal that issued the request based on this information is attached. The download urgency can be determined. Also, by attaching this information to the upgrade request from the terminal side, there is no need to make a request from the server device side to notify the terminal side of the terminal information.
[0031]
Further, in the step of downloading the latest software program, software having a fatal defect is obtained by prioritizing the download of the terminal to be downloaded based on the information about the terminal attached to the request. By upgrading software preferentially from devices running on the network, you can improve network security, or upgrade from devices used by customers with high rates and high service levels. Satisfaction can be increased.
[0032]
DETAILED DESCRIPTION OF THE INVENTION
DESCRIPTION OF EMBODIMENTS Hereinafter, preferred embodiments of a program download system and a program download method of the present invention will be described in detail with reference to the accompanying drawings.
FIG. 1 is a diagram showing a configuration of a program download system according to an embodiment of the present invention.
[0033]
In FIG. 1, 11 is a head end (H / E) device (server device), 12 is a tree-type cable network, 13 to 16 are a large number of terminals A, B, C, D, and 21 made up of cable modems, etc. It is the latest software list 21 sent out on the cable network 12 by the head end device 11.
[0034]
Each terminal 13 (terminal A), terminal 14 (terminal B), terminal 15 (terminal C), and terminal 16 (terminal D) are assumed to have different models. Software is incorporated in the terminals 13 to 16 (terminals A, B, C, and D), and the terminals 13 to 16 themselves have a function of downloading new software via the cable network 2 and rewriting the software. .
The head end device 11 distributes the latest software list 21 to each terminal on the network at regular intervals.
[0035]
The latest software list 21 is a unique and single list showing information including the latest software version for each model currently confirmed on the head end side. This software list 21 is a single one, and all the information regarding each model of each terminal to be notified of the latest software version of the software is described in this software list 21. For example, as shown in FIG. 1, the software list 21 displays a list of software versions “a-1”, “b-6”... For each model name A, B, C.
[0036]
The head end device 11 transmits this software list 21 to each terminal on the network 12 by multicast / broadcast. It should be noted that different version information is not notified to each model. When the latest software is released from a certain vendor of the terminal, the network operator needs to update the software list 21 after storing the software image file on the headend device 11 side.
[0037]
The operation of the program download system and program download method configured as described above will be described below.
The head end device 11 transmits the latest software list 21 to each terminal on the network 12 by multicast / broadcast.
[0038]
The terminals 13 to 16 always monitor the network 12 and pay attention to the distribution of the software list 21. When the software list 21 is distributed and received, the software list 12 is looked at to determine whether or not the terminal needs to update the software. Request download. This operation will be specifically described.
[0039]
First, regarding the terminal 13 (terminal A), if the software of the terminal itself has already been updated, the terminal 13 (terminal A) determines that no update is necessary and does not request download. On the other hand, if the terminal 14 (terminal B) and 16 (terminal D) are operating software older than the latest, the terminal software version and the latest software version are compared, Judge that the terminal software is not the latest. Thereby, the terminal 14 (terminal B) and the terminal 16 (terminal D) request download to the head end device 11 side.
[0040]
FIG. 2 is a diagram for explaining the distribution of the software list 21 and the request by the terminal, and shows that the head end device 11 distributes the software list 21 and the terminal side seeing this distributes the download request. .
[0041]
As shown in FIG. 2, the terminal 14 (terminal B) looks at the latest software list 21 distributed by the headend device 11 and compares it with the software version of its own terminal. It is known that the software version of its own terminal is currently “b-1”. According to the latest software list 21, the latest software version is version “b-6”. Looking at this latest software list 21, terminal B determines that the version of the software currently installed in its own terminal is “b-1” and the software is not the latest, and requests download 22 Do. As the download request 22, for example, “request for software“ b-6 ””, “service class”, “current software”, and “hardware” are transmitted, and information for reference of priority is transmitted together with the software request. The above is the request transmission for the terminal 14 (terminal B), but the same applies to the terminal 16 (terminal D).
The head end device 11 aggregates each request and determines the download priority.
[0042]
Returning to FIG. 1, regarding the terminal 15 (terminal C), the latest software list 21 is looked at and the version of the software on which the terminal is operating is compared with the latest software version. In the latest software list 21 distributed by the 11th side, information on the latest software version is not recorded for the model of the terminal 15 (terminal C). The terminal 15 (terminal C) informs the headend device 11 of the latest software version for the model of the terminal itself in order to know the latest software version related to the model of the terminal itself in the latest software list 21. Make a request. In response to this, the head end side notifies the latest software version corresponding to the model of the terminal 15 (terminal C). Note that terminal 15 (terminal C) does not directly access the version information database, etc., but makes a request to communicate information to the headend side.
[0043]
FIG. 3 is a diagram for explaining a request for the latest software version. The terminal side contacts the head end device 11 so as to notify the latest software version, and the head end device 11 responds to the terminal in response to the request. It shows a state of contacting the side.
[0044]
As shown in FIG. 3, the terminal 15 (terminal C) issues the latest software version communication request 23 to the headend device 11 side. The latest software version communication request 23 is issued together with the model name of the terminal itself. In response to this, the head end device 11 notifies the latest software version information 24 (here, version “c-4”) to the terminal 15 (terminal C).
[0045]
From then on, the head end device 11 side may distribute the latest software list 21 by adding the column of the terminal 15 (terminal C). In this way, the terminal 15 (terminal C) does not need to make a request to contact the latest software version regarding the model of the terminal thereafter. In addition, when the number of this model in the network is small (this can be determined by the total number of requests by the model of terminal C), the size of the latest software list 21 to be distributed is set so as not to increase the load on the network. For the purpose of narrowing down, this model may not be added to the latest software list 21.
[0046]
The terminal 15 (terminal C) looks at the latest software version that has been contacted, knows that it is newer than its own version, and requests the headend device 11 to download.
[0047]
The head end device 11 accepts the request, but does not immediately provide the service, and only accepts the request for a certain period. The head-end device 11 transmits a message for confirming that the request has been received to each terminal that has made the request. Each terminal that made the request sees the message from the head-end device 11 to know that the request has been accepted, and waits until the service is started. In addition, the message indicating that the reception has been performed has a time stamp indicating a period during which the reception is valid. If the service is not started during this period, the head end device 11 responds to the request. Since the service could not be processed, the corresponding terminal needs to retransmit the request to the headend device 11 again.
[0048]
Now, it is assumed that the fixed time has expired and the head end device 11 has finished the download request acceptance period. Each request records information about each terminal that issued the request. For example, the version of software that the terminal is currently operating, the version of hardware, the customer rate, the performance value that can be exhibited by this model, and the like are recorded together with the request. The head-end device 11 refers to this information, but it should be noted that in order to obtain this information, the head-end device 11 requests each terminal to transmit this information. Instead, the information is attached to the upgrade request transmitted from the terminal side to the headend device 11 side.
[0049]
Downloading a software image file generally imposes a heavy burden on the network and the headend, so the number of terminals that can be downloaded at a time is limited. The head-end device 11 determines the download priority of each terminal based on the information collected at the time of the request. FIG. 4 shows how the priorities are determined.
[0050]
FIG. 4 is a diagram for explaining the determination of the priority order, and shows that the head end device 11 side determines the download priority order based on the requests received from each terminal.
In FIG. 4, reference numeral 25 denotes a download priority order referred to by the headend apparatus 11, and 26 denotes a request from each terminal.
[0051]
The download priority order 25 is provided with a plurality of priority orders according to the items of priority order 25a, order 25b, terminal name 25c, and software 25d to be downloaded. In FIG. 4, the left side of the download priority order 25 is high and the right side is low. The number of terminals that can be downloaded at one time is, for example, 3 (see the shaded portion in FIG. 4), and is designated from the top. Here, the terminal name “F” after the order “4” waits for the download order. The request 26 from each terminal is the same as the download request 22 in FIG.
[0052]
As shown in FIG. 4, the headend device 11 aggregates the requests 26 sent from the terminals to the headend during the request reception period, and the headend device 11 gives priority to the download service based on these pieces of information. Rank 25 is determined. A terminal that the head-end device 11 cannot handle at one time cannot participate in a new download unless one of the currently downloading terminals completes the download. Therefore, in practice, each terminal downloads after waiting for its turn. In this case, the headend device 11 downloads each terminal based on the information of each terminal collected from each terminal. Priorities can be determined.
[0053]
For example, if software that is installed and running on a model is found to have a very fatal flaw, and there is a concern that this will adversely affect the entire network, the network operator's Based on the judgment, it is possible to determine the priority request for downloading of each terminal so that the software of this model is updated with the highest priority.
[0054]
In addition, it is possible to determine the download priority order of each terminal so that the software is preferentially updated from the terminals used by high-rate customers. Furthermore, since terminals with small software files will be downloaded as quickly as possible, look at the size of the software file for each terminal model, and give priority to the download from the smallest one as early as possible. Thus, it is possible to secure the number of terminals that have been upgraded (that is, try to finish them from the earliest).
[0055]
In addition, when a situation of each terminal, for example, download is necessary but communication is currently being performed and download cannot be received immediately, the terminal can lower the priority. On the other hand, the download priority order of each terminal may be determined irrespective of the information from each terminal.
[0056]
The operation of the above-described program download system and program download method will be described in more detail with reference to flowcharts.
FIG. 5 is a flowchart showing the operation on the terminal side, and shows the flow of download on the terminal side. In the figure, S indicates each step of the flow.
[0057]
First, in step S1, it is determined whether or not the latest software list 21 (see FIG. 2) has arrived. If the latest software list 21 has not arrived, the process waits until it arrives. When the latest software list 21 arrives, it is determined whether or not the model of the terminal itself is described in the latest software list 21 arrived at step S2.
[0058]
If the model of the own terminal is described, the latest version is confirmed in the latest software list 21 in step S3, and the process proceeds to step S6. If the model of the own terminal is not described, a request is made to notify the headend device 11 of the latest software version of the model of the own terminal in step S4. At this time, information for reference of priority is transmitted together with a request for the latest software version (see request 22 in FIG. 2).
[0059]
Upon receiving the latest version notification from the headend device 11 in step S5, it is determined whether or not to update the software based on the latest version transmitted in step S6. If the software is not updated, this flow is terminated. To do. If the software is to be updated, a download request is made to the headend device 11 in step S7. Next, in step S8, it is determined whether or not a download request has been accepted by a message from the headend device 11. If not received, the process returns to step S7 to request a download.
[0060]
When the request is accepted, it is determined in step S9 whether or not a download start notification is received from the headend device 11, and if a download start notification is not received, the process waits until it is received. When the download start notification is received, the software image file is downloaded in step S10, the software is upgraded, and this flow is terminated.
[0061]
As described above, when the headend device 11 transmits the latest software version list 21 for each terminal connected to the network 12, each terminal views the latest software version list 21, and each terminal receives the latest software version list 21. The latest software version is confirmed based on the software version list 21, and download and upgrade are started based on the determination on the terminal side, not on the instruction on the headend device 11 side.
[0062]
FIG. 6 is a flowchart showing an operation on the head end side, and shows a flow of download on the head end side.
First, in step S11, the latest software list 21 (see FIG. 2) is distributed on the network 12. Next, in step S12, it is determined whether or not a confirmation request has been received from a terminal that is not on the latest software list 21, and when a confirmation request is received, a terminal that is not on the latest software list 21 is received in step S13. The version is notified and the process proceeds to step S14. If the confirmation request is not received in step S12, the process proceeds to step S14 as it is.
[0063]
In step S14, it is determined whether or not a download request has been received. If a download request has not been received, the process waits until it is received. When the download request is received, the request is recorded in step S15, and the request is notified to the corresponding terminal in step S16.
[0064]
Next, in step S17, it is determined whether or not the request reception period has ended. If the request reception period has not ended, the process returns to step S14. When the request acceptance period ends, the requests are totaled in step S18 to determine the download priority, and the download is executed in descending order of priority in step S19. Next, in step S20, it is determined whether or not the download has been completed for all the requested terminals. If the download has not been completed, the process returns to step S19 to execute the download until the requested total number of terminals is completed. When the download is completed for all the requested terminals, this flow ends.
[0065]
By the way, it is difficult to think that the models of all terminals belonging to a network are all different, and the number of terminals is very large, but there are many models on the network, or only a few types of models are configured. Have been. In some cases, there are networks where all terminals are configured from the same model. In such a case, if you download the software individually for each terminal, you can see that the same file is actually being sent many times from the headend side. .
[0066]
In the network 12 of the present embodiment, when downloading to the same model, files are transmitted at a time. The head end device 11 transmits the corresponding file to each terminal by broadcast / multicast communication within the network 12.
[0067]
Each terminal receives a file transmitted by broadcast / multicast communication. However, not all of the transmission target terminals succeed in downloading the file and receiving the transmission of the file. Each terminal that has failed in reception does nothing until the download is completed, and after that, requests (requests) the head end device 11 to transmit the portion of the download that has failed. In response to the request, the head end device 11 transmits again only the portion where the terminal has failed to receive. The state at this time is shown in FIG.
[0068]
FIG. 7 is a diagram for explaining a state in which the head end device 11 is downloading by broadcast / multicast communication.
In FIG. 7, 11 is a head-end device, 31, 32 and 33 are terminals, 34 is a software image file downloaded by the head-end device 11, and 35 is a software image file that has been downloaded but could not be received in part. , 36 downloaded, but a software image file that could not be received in part, 37 downloaded a software image file that was successfully received, and 38 a software image file 36 that failed to download. Thus, the portion 39 that could not be received is the portion of the software image file 36 that was successfully received but successfully received the other portion. In addition, the hatched portions of the software image files 35 and 36 in FIG. 7 indicate a portion of the downloaded software image file that could not be received, and only this portion will be requested again later.
[0069]
The head end device 11 downloads to each terminal 31, 32, 33 of the same model at a time. That is, when each terminal 31, 32, 33 requests the same software, a plurality of destinations are downloaded and downloaded at a time. However, not all terminals were completely successful in downloading, and some terminals could not receive the file completely. The terminal 33 has successfully received the software image file 37 that has been successfully received. Since the terminal 31 and the terminal 32 could not receive a part of the file, it is necessary to make a request for this again. However, if the request is made before the initial download is completed, the entire initial download is affected. Therefore, a request for a retransmission request is not made until this initial download is once completed. Waiting for the end of the download, the terminal 31 makes a retransmission request request for the part that could not be received. Regarding the terminal 32, since the part 38 that could not be received due to the download failure could not be received, only the part 38 requests the headend device 11 to transmit again.
[0070]
As described above, the program download system according to the present embodiment includes a head end device 11 that distributes software programs to the network 12, the latest software list 21 that is sent to the network 12 by the head end device 11, A plurality of terminals 13 to 16 connected to the network 12 and from which the latest software program is downloaded from the head-end device 11. Each terminal 13 to 16 browses the latest software version list 21 and updates the latest software Since the version is confirmed and the download request and the upgrade of the software image file (software program) are started by the terminal side determination without depending on the instruction on the head end device 11 side, the terminal side determination down The network operator's work can be reduced with respect to the software upgrade on the terminal side, and the human error caused by manual work can be reduced. It can be prevented in advance.
[0071]
Further, the head end device 11 side distributes a single piece of information to the entire network 12 in the form of a list 21 with the latest software information of each of the terminals 13 to 16 toward the terminal side, so that each of the terminals 13 to 16 is distributed. Or, compared to the case of notifying the latest version information for each terminal model, the load on the network 12 and the load on the headend device 11 can be reduced.
[0072]
In the present embodiment, the headend device 11 transmits a message indicating that the request has been accepted to the terminals 13 to 16 so that the service does not start immediately, but the request does not need to be performed again. This can be determined on the terminal side.
[0073]
In addition, by attaching a time stamp indicating the expiration date to the message indicating that the download request has been accepted, the acceptance for this request is valid for that period, and it is necessary to wait for that period, and by that period If the service is not started, it can be determined on the terminal side that the request is discarded and it is necessary to make the request again.
[0074]
Further, in the present embodiment, in addition to the current software version, the information about the terminal that issued the request is attached to the download request issued by the terminal side to the headend device 11 side. Based on this information, the headend device 11 can determine the urgency of download for each terminal that issued the request. Further, by attaching this information to the upgrade request from the terminal side, there is no need to make a request from the head end device 11 side to notify the terminal side of the terminal information.
[0075]
Further, since the headend device 11 gives priority to the download to each terminal based on the terminal information attached to the download request from each terminal, the terminal operating with the software having a fatal defect Prioritize software upgrades to increase network security, and upgrades with priority from devices used by customers with high rates and high service levels to increase customer satisfaction. be able to.
[0076]
Also, when downloading, the file is unilaterally broadcast or multicast, and multiple terminals receive it at the same time, so it is not necessary to send the same file as many times as the number of terminals. Time can be saved.
[0077]
Furthermore, when downloading by broadcast / multicast communication that is simultaneously transmitted to each terminal 13-16, even if a part of the downloaded software image file cannot be received, only that part is sent. In addition, it is possible to make a request to the head end device 11 side. Also, by not making a retransmission request during download by broadcast / multicast communication, it becomes possible to perform broadcast / multicast communication for software download, so that no unnecessary load is placed on the network 12 and the headend device 11. Can be.
[0078]
Although the above embodiment is an example applied to the program download system and program download method of the CATV system, the present invention can be applied to any system as long as it is a program download method for transferring a program.
Further, each device constituting the program download system, for example, the type and number of headends and networks, the connection method and the like are not limited to the above-described embodiments.
[0079]
【The invention's effect】
As described above in detail, according to the present invention, the network operator and the server can be prevented in advance by reducing the work of the network operator and preventing the human error caused by the manual work with respect to the software upgrade on the terminal side. The load on the device can be reduced.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of a program download system according to a first embodiment of this invention.
FIG. 2 is a diagram for explaining distribution of a software list and a request by a terminal in the program download system according to the present embodiment.
FIG. 3 is a diagram illustrating a request for the latest software version of the program download system according to the present embodiment.
FIG. 4 is a diagram for explaining determination of priority in the program download system according to the present embodiment.
FIG. 5 is a flowchart showing the operation on the terminal side of the program download system of the present embodiment.
FIG. 6 is a flowchart showing an operation on the head end side of the program download system of the present embodiment.
FIG. 7 is a diagram for explaining a state in which the headend device of the program download system according to the present embodiment is downloading by broadcast / multicast communication.
FIG. 8 is a diagram showing a configuration of a conventional program download method.
[Explanation of symbols]
11 Headend (H / E) device (server device)
12 Cable network
13-16, 23-25 Terminal
21 List of latest software
22 Download requests
23 Latest software contact request
24 Contact the latest software
25 Download priority
26 Request from terminal
34 Software image file to download
35, 36 Software image file that could not be received in part
37 All software image files successfully received
38 Parts that could not be received due to download failure
39 Other parts failed, but downloaded successfully and received

Claims

A server device that distributes a software program on a network; and a plurality of terminals connected to the network; and the software program used by the terminal is downloaded from the server device side to the terminal side, and the terminal In the program download method to upgrade the software program on the side,
A list indicating the latest software version information confirmed on the server device side, and transmitting a single list describing the software version for each model of each terminal to each terminal on the network And steps to
The terminal makes a request for downloading the latest software when the latest software version is different from the software version of the terminal with reference to the list;
Downloading the latest software program according to the download request;
A program download method characterized by sequentially executing a step of upgrading a software program based on the downloaded software program ,
In the step of downloading the latest software program, a priority order is given to a terminal to be downloaded based on information on the terminal attached to the request.

A server device that distributes a software program on a network; and a plurality of terminals connected to the network; and the software program used by the terminal is downloaded from the server device side to the terminal side, and the terminal In the program download method to upgrade the software program on the side,
Requesting the latest software version information including model information of the terminal itself from the terminal to the server device;
In response to the request, the server apparatus displays a list indicating the latest software version information confirmed on the server apparatus side, and describing a software version corresponding to the model of the terminal. Sending to each of the terminals on the network;
Making a request for downloading the latest software from the terminal to the server device when the latest software version is different from the software version of the terminal with reference to the list;
Downloading the latest software program sent from the server device according to the download request at the terminal;
Upgrading a software program based on the downloaded software program;
The A program download method characterized by sequentially executing,
In the step of downloading the latest software program, a priority order is given to a terminal to be downloaded based on information on the terminal attached to the request.

Wherein in the step of downloading the latest software program, according to claim, characterized in that after a predetermined time has elapsed from the time point of receiving a request for download from the terminal, the latest software program from the server device is transmitted 1 Or the program download method of 2.

3. The program download method according to claim 1, wherein in the step of requesting the download of the latest software program, information on the terminal that issued the request such as a software version is attached.