(57)【特許請求の範囲】
【請求項１】
移動体通信網の基地局と、基地局との間でデータ伝送が可能な移動端末と、プログラムにより制御される機器と、前記プログラムのアップデータが登録され基地局を通して機器にアップデータを伝送するサーバとからなり、機器には、プログラムが格納される書換可能な記憶手段と、記憶手段に格納されたプログラムによって機器の動作を制御する制御手段と、前記サーバから前記移動端末を通して伝送されたプログラムを記憶手段に書き込む書込手段とが設けられ、前記サーバでは、時刻を計時し指定された時刻になるとアップデータの配信を開始させる時計手段を備え、前記アップデータを送信する際に、プログラムの送信対象である機器の種類を指定する機器種別データとプログラムのバージョンを表すプログラム識別データとを少なくとも含む識別データを付加するとともに、前記アップデータを複数個のブロックに分割して各ブロックごとにブロックを識別するブロック識別データとエラーチェックデータとを付加しておき、同内容のアップデータを規定した複数回繰り返して前記移動端末に対して一斉同報により送信し、前記書込手段では、受信した機器種別データがあらかじめ書込手段に設定されている機器種別データに一致し、かつプログラム識別データにより未書換のアップデータであることが確認されたときに当該アップデータを前記記憶手段に格納するとともにアップデータを受信するとアップデータの複数回の送信が終了するまで応答を禁止し、アップデータの１回目の受信時にエラーチェックデータによってエラーが検出されたブロックがありアップデータを２回以上受信でき２回目以降に受信したアップデータによって当該ブロックを補完可能であれば補完し、応答可能になったときに未補完のブロックがあれば、その後に当該ブロックのブロック識別データを指定して前記サーバに再送を要求し、前記サーバは、機器からの再送要求に応答して当該ブロックを再送要求した機器に再送することを特徴とするダウンロードシステム。
【請求項２】
前記書込手段では前記アップデータの書換が成功したときには書換完了後の所定時間内に当該機器を個別に識別する固有識別データを前記サーバに返送し、前記サーバでは固有識別データが返送されると当該機器にプログラムのバージョンを対応付けているバージョン管理テーブルを更新することを特徴とする請求項１記載のダウンロードシステム。
【請求項３】
前記機器が前記アップデータの書換完了時から前記固有識別データを返送するまでの前記所定時間を機器ごとにランダムに設定するタイマを備えることを特徴とする請求項２記載のダウンロードシステム。
【請求項４】
前記移動端末では前記基地局からの一斉同報による前記アップデータを受信すると、前記サーバからのアップデータの送信が終了するまでは前記基地局への送信が禁止されることを特徴とする請求項１ないし請求項３のいずれか１項に記載のダウンロードシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プログラムにより制御される機器にアップデータを配信するダウンロードシステムに関するものである。
【０００２】
【従来の技術】
近年、パーソナルコンピュータ、コピー機、ＦＡＸのような事務用機器はもとより、自動販売機、カーナビゲーションシステム、携帯電話機、各種家電製品に至るまで各種機器にマイコンが組み込まれており、これらの機器ではプログラムによって動作が制御されている。
【０００３】
パーソナルコンピュータのように一般のユーザによってもプログラムの書換が可能な機器では、プログラムに不具合が存在する場合や、機能向上のためにプログラムが修正された場合などに、メーカが顧客に対して必要に応じてアップデータ（改修プログラム）の存在を告知するとともに、アップデータをＣＤ−ＲＯＭなどの媒体の形で配布したり、インターネットなどの通信回線を介してアップデータを配信しており、ユーザ自身の意思でプログラムのバージョンアップが可能になっている。
【０００４】
一方、パーソナルコンピュータを除く機器では、一般にはユーザによるプログラムの書換は不可能であって、機器の開発メーカやプログラムの開発メーカの技術者がアップデータに入れ替える作業を行うか、リコールとしてアップデート済みのプログラムを組み込んだ同等品に交換しているのが現状である。アップデータに入れ替える作業を行う場合には、指定されたサービス拠点にユーザ自身が機器を持ち込んだり、当該機器のメーカから派遣された技術者が顧客を１軒ずつ訪問して当該機器に１台ずつアップデータを組み込む作業を行っているのが現状である。
【０００５】
【発明が解決しようとする課題】
しかしながら、上述のような方法ではアップデートの対象機器に１台ずつアップデータを組み込むことになるから、対象機器が何十万台〜何百万台も稼動している場合には、対象機器の全台数に対してアップデータを組み込む作業が完了するまでの時間および費用は膨大なものになる。
【０００６】
このような事情を考慮し、通信回線を利用して対象機器のプログラムのアップデートを行うことも実施されており、技術者の派遣費用を低減する効果が得られている。もっとも、アップデータは１対１の通信によって対象機器の１台ずつに伝送しているものであるから、対象機器の台数が少ない場合には比較的短時間でプログラムのアップデートが可能であるものの、機器の台数が多くなれば短時間でアップデートを行うことは難しくなる。例えば、アップデータを配信するサーバの１回線に対してアップデートを行う対象機器が１００万台あるものとして、アップデータの配信には１台あたり５分間を要するとすると約１０年の時間を要することになる。したがって、アップデータの配信に５００回線を確保することができるとしても約７日間を要することになる。このように、従来の方法では、依然としてプログラムのアップデートに要する時間と費用が大きく、稼動台数が多い機器へのアップデータの配信方法としては不十分である。
【０００７】
本発明は上記事由に鑑みて為されたものであり、その目的は、稼働中の複数台の機器にサーバからアップデータを一度に配信可能としてプログラムのアップデートに要する時間および費用を従来よりも大幅に低減させることを可能としたダウンロードシステムを提供することにある。
【０００８】
【課題を解決するための手段】
請求項１の発明は、移動体通信網の基地局と、基地局との間でデータ伝送が可能な移動端末と、プログラムにより制御される機器と、前記プログラムのアップデータが登録され基地局を通して機器にアップデータを伝送するサーバとからなり、機器には、プログラムが格納される書換可能な記憶手段と、記憶手段に格納されたプログラムによって機器の動作を制御する制御手段と、前記サーバから前記移動端末を通して伝送されたプログラムを記憶手段に書き込む書込手段とが設けられ、前記サーバでは、前記アップデータを送信する時刻を指定する時計手段を備え、前記アップデータを送信する際に、プログラムの送信対象である機器の種類を指定する機器種別データとプログラムのバージョンを表すプログラム識別データとを少なくとも含む識別データを付加するとともに、前記アップデータを複数個のブロックに分割して各ブロックごとにブロックを識別するブロック識別データとエラーチェックデータとを付加しておき、同内容のアップデータを規定した複数回繰り返して前記移動端末に対して一斉同報により送信し、前記書込手段では、受信した機器種別データがあらかじめ書込手段に設定されている機器種別データに一致し、かつプログラム識別データにより未書換のアップデータであることが確認されたときに当該アップデータを前記記憶手段に格納するとともにアップデータを受信するとアップデータの複数回の送信が終了するまで応答を禁止し、アップデータの１回目の受信時にエラーチェックデータによってエラーが検出されたブロックがありアップデータを２回以上受信でき２回目以降に受信したアップデータによって当該ブロックを補完可能であれば補完し、応答可能になったときに未補完のブロックがあれば、その後に当該ブロックのブロック識別データを指定して前記サーバに再送を要求し、前記サーバは、機器からの再送要求に応答して当該ブロックを再送要求した機器に再送することを特徴とする。
この構成によれば、移動体通信の技術を利用してアップデータを一斉同報により複数台の機器に同時に配信するので、サーバ側が１回線のみであっても多数台の機器に一度にアップデータを配信することが可能になる。その結果、１対１通信によってアップデータを配信する場合や多数回線を用意してアップデータを配信する場合に比較すると、アップデータの配信に要する時間を大幅に短縮することができ、しかもサーバ側で多数回線を用意する場合に比較して設備費用を大幅に低減することが可能になる。また、書込手段ではアップデータとともに受信する機器種別データとプログラム識別データとによってプログラムをアップデートすべきか否かを判断し、アップデートが必要な場合にのみアップデータを記憶手段に書き込むから、一斉同報によりアップデータを伝送しても対象機器にのみアップデータが転送され、プログラムが不用意に書き換えられることが防止される。
【００１０】
さらにまた、アップデータを複数のブロックに分割して送信するから、基地局と移動端末との間の電波の伝送状況に変化が生じるなどして正しいアップデータが伝送できなかった場合でも、エラーが検出されたブロックについてのみ再送を要求すればよく、アップデータの全体を再送する場合に比較して移動体通信網のトラフィックを大幅に低減することができる。このことは、アップデートの対象となる機器の台数が多い場合にとくに有効である。しかも、アップデータの受信終了後にエラーが検出されたブロックの再送を要求するから、アップデータの送信中にはブロックの再送要求が発生せず、基地局と移動端末との間でのデータの伝送方向を単純化されて伝送制御が容易になる。
【００１１】
さらに、アップデータが複数回送信される間に同じブロックでエラーが生じる確率は小さいから、同じアップデータをサーバから複数回送信するとともに、１回目の受信時にエラーの生じたブロックについて２回目以降の受信時に補完することによって、再送を要求するブロックの個数が低減されることになり、結果的に移動体通信網のトラフィックの低減に寄与する。加えて、時計手段を備えているから、夜間のように機器が使用される可能性が低く、かつ移動体通信網のトラフィックが少ない時間帯を利用するように時刻を指定してアップデータを配信することが可能になる。
【００１２】
請求項２の発明は、請求項１の発明において、前記書込手段では前記アップデータの書換が成功したときには書換完了後の所定時間内に当該機器を個別に識別する固有識別データを前記サーバに返送し、前記サーバでは固有識別データが返送されると当該機器にプログラムのバージョンを対応付けているバージョン管理テーブルを更新するものであり、バージョン管理テーブルの内容を見ることによってアップデートの完了していない機器を確認することができるから、アップデータの配信時に電源が遮断されているなどアップデートが可能な状態ではなかった機器に対して個別に対応することができ、すべての機器について確実にプログラムのアップデートが可能になる。
【００１３】
請求項３の発明は、請求項２の発明において、前記機器が前記アップデータの書換完了時から前記固有識別データを返送するまでの前記所定時間を機器ごとにランダムに設定するタイマを備えるものであり、移動端末から基地局に対して固有識別データが集中して送信されると移動体通信網のトラフィックが増加するが、アップデータの書換完了から固有識別データを返送するまでの時間を機器ごとにランダムに設定するタイマを設けているから、各機器から固有識別データを送信するタイミングがずれることによって、固有識別データの送信の集中を抑制することができる。
【００１４】
請求項４の発明は、請求項１ないし請求項３の発明において、前記移動端末では前記基地局からの一斉同報による前記アップデータを受信すると、前記サーバからのアップデータの送信が終了するまでは前記基地局への送信が禁止されるものであり、移動端末ではアップデータの受信完了までは送信しないから、携帯電話機のような移動端末において通常行われているようにパケット単位で送信と受信とを繰り返す場合に比較すると移動端末での送信に要する電力消費を大幅に低減することができる。つまり、機器が多数存在していてもプログラムのアップデートに要する電力の総使用量は比較的小さくなる。
【００１６】
【発明の実施の形態】
本実施形態では、機器の一例としてコピー機を例示するが、コピー機に限定する趣旨ではなく、プログラムにより制御される機器であれば本発明の技術思想は適用可能である。
【００１７】
図２に示すように、コピー機（機器）１ａ〜１ｃには複数の種類があり、各コピー機１ａ〜１ｃごとに動作を制御するプログラムが異なっているものとする。コピー機１ａ〜１ｃである機器１には、図２に示すように、移動端末２が接続される。移動端末２は移動体通信網５の基地局３と無線によりデータ伝送を行うものであり、基地局３は移動体通信網５を介してサーバ４に接続される。移動体通信網５には各コピー機１ａ〜１ｃのメーカに設けたメーカ側端末６ａ〜６ｃが接続され、メーカ側端末６ａ〜６ｃにおいてコピー機１ａ〜１ｃに伝送すべきアップデータがあれば、移動体通信網５を通してサーバ４に転送できるようにしてある。図示例では各メーカ側端末６ａ〜６ｃに各コピー機１ａ〜１ｃに対応するプログラム７ａ〜７ｃが用意されている状態を表している。
【００１８】
コピー機１ａ〜１ｃである機器１は、図１に示すように、携帯電話機やＰＨＳ電話機のような移動端末２を接続するための通信インタフェース１１を備える。また、機器１には記憶手段としてのプログラム記憶部１２が設けられ、プログラム記憶部１２に格納されたプログラムに従ってマイコンからなる制御手段１０が機器１の各部の動作を制御する。プログラム記憶部１２はフラッシュＲＯＭのように書換可能であって無給電で記憶内容を保持するメモリからなり、プログラム記憶部１２へのプログラムの格納は通信インタフェース１１を介して移動端末２に接続された書込手段１３が行う。書込手段１３は、通信インタフェース１１を通して移動端末２と授受するデータのバッファとしてＲＡＭからなる作業用メモリを備える。さらに、モータ、ランプ、センサなどの各部と接続するための機器インタフェース１４も機器１に設けられる。
【００１９】
さらに、書込手段１３には、機器１の種類を表す機器種別データと、各機器１を個別に識別するための固有識別データとが設定されている。機器種別データは機器１の型番に対応するデータであり、固有識別データは機器１の製造番号、プログラムのバージョン、プログラムの最新のアップデートの日時を示すタイムスタンプを含む。一方、サーバ４から基地局３および移動端末２を通して機器１に伝送されるアップデータには、機器１に設定されている機器種別データとアップデータにより更新されるプログラムのバージョンを表すプログラム識別データとを少なくとも含む識別データがアップデータの先頭に付加される。また、アップデータには通常の通信と区別するためにアップデータの転送を示す通信パラメータを付加してもよい。
【００２０】
以下では、コピー機１ａのプログラムについてバージョンアップの必要が生じたものとして動作を説明する。この場合、コピー機１ａのメーカはメーカ側端末６ａを通してアップデート用のプログラム７ａ（アップデータ）を１ファイルとして規定のフォーマットでサーバ４に転送する。メーカ側端末６ａからはアップデータの配信を開始する時刻を指定することも可能であって、サーバ４に設けた時計手段４１で計時されている時刻がメーカ側端末６ａにより指定された時刻になると、基地局３を通してアップデータの配信を開始する。
【００２１】
ところで、基地局３はアップデータに付加されている通信パラメータによってアップデータの配信であることを認識すると、一斉同報（ブロードキャスト）によってアップデータを配信する。ここで、基地局３はアップデータの伝送を通知する報知情報としてアップデータの有無を通知する。したがって、基地局３からの電波の受信圏内に存在するすべての移動端末２は、図３に示すように、報知情報を受信すると（Ｓ１）、書込手段１３において報知情報を解析する。報知情報がアップデータの送信を示しているときには（Ｓ２）、移動端末２をアップデータの受信に対応させるための通信パラメータを移動端末２に設定する（Ｓ３）。こうして移動端末２に通信パラメータが設定されるとアップデータの受信（ダウンロード）が可能になる（Ｓ４）。ただし、アップデータの先頭には上述したように識別データである機器種別データおよびプログラム識別データが付加されているから、受信した機器種別データが書込手段１３にあらかじめ登録されている機器種別データに一致し、かつプログラム識別データにより示されたバージョンがプログラム記憶部１２に格納されているプログラムのバージョンよりも新しいものであるときにのみアップデータを読み込む。機器種別データが不一致であるかプログラムのバージョンが新しくない場合にはアップデータの受信を中止して待受け状態になる。
【００２２】
ところで、本実施形態では、プログラムを複数個のブロックに分割して送信する構成を採用し、各ブロックにはブロック識別データとしてのブロック番号を付与するとともに、各ブロックごとにエラーチェックデータを付加してある。また、アップデータの伝送開始前にアップデータを構成するブロック数が通知されるようにしてある。したがって、アップデータの受信を開始するときには通知されたブロック数をブロックカウンタとして設定し（Ｓ５）、ブロックを受信するたびにブロックカウンタをデクリメントし（Ｓ６）、最終ブロックに達したか否かを判断する（Ｓ７）。各ブロックは書込手段１３に設けた作業用メモリに格納されており、最終ブロックに達した時点で、各ブロックにおける伝送エラーの有無を判定し（Ｓ８）、エラーがない場合には書込手段１３からすべてのブロックがプログラム記憶部１２に転送され、プログラム記憶部１２に格納されたプログラムが更新（アップデート）される（Ｓ９）。こうして、プログラムのアップデートが完了すると、サーバ４に対して完了通知を行う（Ｓ１０）。
【００２３】
一方、ステップＳ８において、いずれかのブロックにエラーがあったことが検出されると、エラーの生じていたブロックについてのみサーバ４に再送を要求する（Ｓ１１）。こうして再送されたブロック（Ｓ１２）についてもエラーの有無を検証し（Ｓ１３）、エラーがなければ先に受信したブロックとともにアップデータを補完し、プログラム記憶部１２に格納されたプログラムを更新した後（Ｓ１４）、サーバ４に対して完了通知を行う（Ｓ１５）。
【００２４】
ここに、プログラムの書換が成功した時点から完了通知を送信するまでの時間は機器１に設けたタイマ（図示せず）によって機器１ごとにランダムに設定され、各機器１からの完了通知が１つの基地局３に同時に送信される可能性を低減してある。また、完了通知としては、上述した機器１の固有識別データをサーバ４に対してショートメールの形で返送する。したがって、図２に示すように移動体通信網３にはショートメールを受信するためのメールシステム８を設けてあり、メールシステム８では固有識別データを受信すると制御装置９を介して固有識別データをサーバ４に引き渡す。サーバ４にはバージョン管理テーブルが設けられており、バージョン管理テーブルでは各機器１から返送された固有識別データに基づいて、各機器１に設定されたプログラムのバージョンを管理する。また、バージョン管理テーブルの内容に基づいて、完了通知が返送されてきた機器１の一覧リストを自動作成し、機器１のメーカ側端末１ａ〜１ｃにバージョン管理情報として転送すればメーカでの管理に供することができる。このように、バージョン管理テーブルを作成することによって、アップデートが未完了である機器１を確認することができるから、アップデータの配信時に停電によって電源が遮断されている場合など、アップデートができない状態であった機器１に対して個別に対応することが可能になる。
【００２５】
上述したアップデータのフォーマットおよび各ブロックのフォーマットを表１、表２に示す。表１において「アップデート対象バージョン」は、アップデートの対象となるプログラムのバージョンである。これは、機器種別データが一致する機器１であってもプログラムが顧客専用に特化されているような場合に、他の特化されていない機器１のプログラムで不用意に置換されるのを防止するための情報として付加されている。つまり、機器１のプログラム記憶部１２に格納されたプログラムのバージョンが「アップデート対象バージョン」として指定されたバージョンに一致しなければアップデートが行われないようにしているのであって、顧客専用に特化されたプログラムには一般のプログラムとは別のバージョンを設定しておくことによって、一般のプログラムのアップデート時に特化されたプログラムが不用意にアップデートされるのを防止している。「アップデータのプログラムバージョン」はプログラム識別データに相当する。また、「ファイルサイズ」はアップデータの大きさを表し、「ブロック数」はアップデータを構成するブロック数を意味する。さらに、「アップデート通知先」はアップデートの完了後にバージョン管理情報の転送先となるメーカ側端末６ａ〜６ｃを表す。
【００２６】
【表１】
0004520671.tif 000002
【００２７】
【表２】
0004520671.tif 000003
【００２８】
また、上述した完了通知のフォーマットと再送要求のフォーマットとは、それぞれ表３、表４のようになる。完了通知はショートメールの形で伝送されるから、先頭に完了通知のメッセージが記述され、「機器種別データ」と、「アップデート対象バージョン」と、アップデータとしてのプログラムのバージョンである「アップデータのプログラムバージョン」とを含み、さらに、固有識別データである「製造番号」および「タイムスタンプ」も完了通知に含まれる。再送要求のフォーマットも完了通知とほぼ同様であるが、先頭にはブロックの再送要求のメッセージが記述され、「タイムスタンプ」に代えて「受信成否のビットパターン」が含まれる。
【００２９】
「受信成否のビットパターン」は、ブロック番号をビット位置に対応付けるとともに、各ブロックごとに受信の成否をビット値で表したビットパターンである。たとえばアップデータが１６ブロックに分割されているとすれば、１６ビットのデータの各ビット位置をブロック番号に対応付けるとともに、受信が成功したブロック番号に対応するビット位置のビット値を１とし、受信が失敗したブロック番号に対応するビット位置のビット値を０とするのである。いま、最上位ビットをブロック番号の１に対応付けるものとし、ブロック番号が３のブロックと、ブロック番号が１０のブロックとの受信に失敗したとすれば、１６ビットのデータは「１１０１１１１１１０１１１１１１」になるから、これを１６進数の４桁で表し、「ＤＦＢＦ」というデータを「受信成否のビットパターン」として伝送する。
【００３０】
【表３】
0004520671.tif 000004
【００３１】
【表４】
0004520671.tif 000005
【００３２】
上述の説明は、アップデータをサーバ４から機器１に対して１回送信する動作であるが、本実施形態では、サーバ４から機器１へはアップデータを複数回送信する。すなわち、同じアップデータを複数回送信し、すべてのアップデータの送信が終了するまで、移動端末２から基地局４への返送を禁止し、１回目のアップデータが受信したときにエラーの生じたブロックがあっても２回目以降に受信したアップデータによって当該ブロックの補完が可能であればアップデータを補完する。複数回受信したアップデータによってもエラーが解消されないブロックがあるときには、そのブロックについてのみ再送を要求するのである。このように、同じアップデータを複数回受信し、ブロック単位でアップデータを補完すれば、最終的にエラーが解消されないブロックはごく少数であり、ほとんどの機器１ではエラーが解消されると考えられるから、再送を要求する可能性が大幅に低減され、移動体通信網５のトラフィックの増加を抑制することができる。なお、データの再送を要求する場合にも完了通知と同様に、再送要求のタイミングをタイマによってランダムに設定すれば、再送要求についても移動体通信網５のトラフィックの増加を抑制することができる。
【００３３】
上述したアップデータの伝送手順について図４にまとめて示す。図示するようにメーカ側端末６（６ａ〜６ｃ）ではアップデータをサーバ４に転送する。メーカ側端末６ではアップデータの配信開始時刻および配信回数を指定することができ、サーバ４では指定された配信開始時刻になると基地局３を通して一斉同報（ブロードキャスト）によって機器１にアップデータを配信する。図示例では機器１が３台設けられている例を示している。ここに、各機器１と区別するために機器ａ、機器ｂ、機器ｃと呼ぶことにする。機器ａ、機器ｂについてはデータの受信が成功してアップデートが行われたものとし、機器ｃについてはブロック番号が５であるブロック（以下、ブロックＮｏ．５と呼ぶ）に伝送エラーが生じたものとする。アップデートの成功した機器ａ、機器ｂではランダムに設定された時間間隔Ｔａ，Ｔｂで完了を通知し、機器ｃについてはランダムに設定された時間間隔ＴｃでブロックＮｏ．５の再送を要求する。サーバ４では機器ｃからのブロックＮｏ．５の再送要求に応答してブロックＮｏ．５を再送し、これによって機器ｃにおいてもアップデートが完了する。アップデートの完了通知はショートメールの形でメールシステム８に対して伝送され、メールシステム８では完了通知をサーバ４に転送する。こうして、サーバ４からメーカ側端末６に対して各機器ａ、機器ｂ、機器ｃのバージョン管理情報を一覧するアップデート完了リストとして通知することができる。
【００３４】
なお、上述した実施形態では機器１としてコピー機を想定しているから機器１には商用電源から給電され、移動端末２についても機器１を通して商用電源から電源を供給している。一方、機器１や移動端末２では電池を電源とすることがあり、アップデートの処理中に電池が消耗して電池容量が不足するとアップデートの処理を継続できなくなる可能性がある。一方、電池を電源とする機器１あるいは移動端末２では一般に電池残量を監視する機能を備えるから、この機能を利用し、アップデータの受信を開始する前にアップデートの処理を終了するのに必要と想定して設定した基準値よりも電池残量が少ないときには、機器１においてアップデートの処理を中止する。この場合、バージョン管理テーブルにはアップデートが未完了である機器１として登録されるから、アップデータの配信時に電源が遮断されている場合と同様に、機器１ごとに個別に対応することになる。
【００３５】
【発明の効果】
請求項１の発明は、移動体通信の技術を利用してアップデータを一斉同報により複数台の機器に同時に配信するので、サーバ側が１回線のみであっても多数台の機器に一度にアップデータを配信することが可能になり、結果的に、１対１通信によってアップデータを配信する場合や多数回線を用意してアップデータを配信する場合に比較すると、アップデータの配信に要する時間を大幅に短縮することができ、しかもサーバ側で多数回線を用意する場合に比較して設備費用を大幅に低減することが可能になるという利点がある。
【００３７】
また、アップデータを複数のブロックに分割して送信するから、基地局と移動端末との間の電波の伝送状況に変化が生じるなどして正しいアップデータが伝送できなかった場合でも、エラーが検出されたブロックについてのみ再送を要求すればよく、アップデータの全体を再送する場合に比較して移動体通信網のトラフィックを大幅に低減することができるという利点がある。しかも、アップデータの受信終了後にエラーが検出されたブロックの再送を要求するから、アップデータの送信中にはブロックの再送要求が発生せず、基地局と移動端末との間でのデータの伝送方向を単純化されて伝送制御が容易になるという利点がある。
【００３８】
さらに、アップデータが複数回送信される間に同じブロックでエラーが生じる確率は小さいから、同じアップデータをサーバから複数回送信するとともに、１回目の受信時にエラーの生じたブロックについて２回目以降の受信時に補完することによって、再送を要求するブロックの個数が低減されることになり、結果的に移動体通信網のトラフィックの低減に寄与するという利点がある。加えて、時計手段を備えているから、夜間のように機器が使用される可能性が低く、かつ移動体通信網のトラフィックが少ない時間帯を利用するように時刻を指定してアップデータを配信することが可能になるという利点がある。
【００３９】
請求項２の発明は、請求項１の発明において、バージョン管理テーブルの内容を見ることによってアップデートの完了していない機器を確認することができるから、アップデータの配信時に電源が遮断されているなどアップデートが可能な状態ではなかった機器に対して個別に対応することができ、すべての機器について確実にプログラムのアップデートが可能になるという利点がある。
【００４０】
請求項３の発明は、請求項２の発明において、アップデータの書換完了から固有識別データを返送するまでの時間を機器ごとにランダムに設定するタイマを設けているから、各機器から固有識別データを送信するタイミングがずれることによって、固有識別データの送信の集中を抑制することができるという利点がある。
【００４１】
請求項４の発明は、請求項１ないし請求項３の発明において、移動端末ではアップデータの受信完了までは送信しないから、携帯電話機のような移動端末において通常行われているようにパケット単位で送信と受信とを繰り返す場合に比較すると移動端末での送信に要する電力消費を大幅に低減することができる。つまり、機器が多数存在していてもプログラムのアップデートに要する電力の総使用量は比較的小さくなるという利点がある。
【図面の簡単な説明】
【図１】本発明の実施形態の要部を示すブロック図である。
【図２】同上の全体構成を示すブロック図である。
【図３】同上の動作説明図である。
【図４】同上の動作説明図である。
【符号の説明】
１  機器
１ａ〜１ｃ  機器
２  移動端末
３  基地局
４  サーバ
５  移動体通信網
６ａ〜６ｃ  メーカ側端末
７ａ〜７ｃ  プログラム
８  メールシステム
９  制御装置
１０  制御手段
１１  通信インタフェース
１２  プログラム記憶部（記憶手段）
１３  書込手段
１４  機器インタフェース
４１  時計手段
【図１】
0004520671.tif 000006
【図２】
0004520671.tif 000007
【図３】
0004520671.tif 000008
【図４】
0004520671.tif 000009