(57)【特許請求の範囲】
【請求項１】
複数の携帯端末と、各携帯端末の機種別及び版数別のバージョンアップ用制御プログラムを蓄積・管理するソフトウェア管理装置とがメールにより相互に通信可能な移動通信システムの携帯端末装置であって、自己の制御プログラムを一定サイズのセクタ毎に消去及び書込可能なフラッシュメモリに保持すると共に、予め各セクタを被修正プログラムの記憶エリアと、修正用プログラムの記録エリアとに分割しておき、セクタ単位にプログラム修正を行うことを特徴とする携帯端末装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は携帯端末装置に関し、更に詳しくは複数の携帯端末と、各携帯端末の機種別及び版数別のバージョンアップ用制御プログラムを蓄積・管理するソフトウェア管理装置とがメールにより相互に通信可能な移動通信システムの携帯端末装置に関する。
【０００２】
【従来の技術】
近年、ＰＤＣやＰＨＳで代表される携帯無線電話(端末）の普及には目覚しいものがあり、既に多種多様の大量の携帯端末機が市場に投入（市場で利用）されている。一方、このような携帯端末を製造するメーカ側では、十分な機能テスト（移動機制御ソフトウェアの開発及びテスト）を行った上で、携帯端末を市場に提供するが、市場で実運用されるような過酷な環境下では、携帯端末のソフトウェアに不測の不具合が発見される場合も少なくない。
【０００３】
この場合に、従来は、通信事業者がエンドユーザに不具合のダイレクトメールを送付し、エンドユーザは事業者の小売店等に出向き、新しいソフトウェアが書き込まれた移動機に交換していた。
【０００４】
【発明が解決しようとする課題】
しかし、上記ダイレクトメールの送付や新しい移動機を製造・輸送する為のコストがメーカや事業者にとって大きな負担であった。また、移動機へのソフトウェアの書き込みは、専用のＩＤ書込端末に数十台〜数百台をシリシルケーブルで直結し、シリアル信号により制御プログラムの全てを書きかえる方法を取っているため、ソフトウェアの書き込みには長時間を要した。
【０００５】
このように、従来は，移動機を製造するメーカでの作業時間、小売店まで物理的に携帯電話を輸送すること、及びエンドユーザが小売店に出向かなくてはいけないこと等、エンドユーザの手元に新しい移動機が届くまでには相当の時間がかかるため、エンドユーザに不満を与える可能性が極めて高かった。
【０００６】
本発明は上記従来技術の問題点に鑑み成されたもので、その目的とする所は、市場に投入された携帯端末のソフトウェアバージョンアップを能率よく的確に行える移動通信システムの携帯端末装置を提供することにある。
【０００７】
【課題を解決するための手段】
上記の課題は例えば図１，図４の構成により解決される。即ち、本発明（１）の携帯端末装置は、複数の携帯端末１０と、各携帯端末の機種別及び版数別のバージョンアップ用制御プログラムを蓄積・管理するソフトウェア管理装置４０とがメールにより相互に通信可能な移動通信システムの携帯端末装置であって、自己の制御プログラムを一定サイズのセクタ毎に消去及び書込可能なフラッシュメモリに保持すると共に、予め各セクタを被修正プログラムの記憶エリアと、修正用プログラムの記録エリアとに分割しておき、セクタ単位にプログラム修正を行うものである。従って、携帯端末の制御プログラムのうちの修正の必要な部分のプログラムを含むセクタのみを、速やかに、短時間で、かつ効率よく修正できる。
好ましくは、このような携帯端末を収容する移動通信システムは、複数の携帯端末１０と、各携帯端末の機種別及び版数別のバージョンアップ用制御プログラムを蓄積・管理する遠隔のソフトウェア管理装置４０とがメールにより相互に通信可能な移動通信システムであって、前記携帯端末１０Ａは、外部装置８０からの端末ＩＤ（例えば電話番号）の書き込みを契機として、その後の電源投入時に自端末１０Ａの機種名と、制御プログラムの版数と、端末ＩＤとを含む利用登録メールを作成し、ソフトウェア管理装置４０に送信するものである。
【０００８】
このシステムにおいては、携帯端末１０Ａは、通信事業者による外部装置８０からの端末ＩＤ（例えば電話番号）の書き込みを契機として、その後の電源投入時に自端末１０Ａの機種名と、制御プログラムの版数と、端末ＩＤとを含む利用登録メールを作成し、ソフトウェア管理装置４０に送信するので、このような携帯端末１０Ａのメーカ側では、市場に投入された自メーカ製の携帯端末を、速やかに、漏れなく、かつ効率よくソフトウェア管理装置４０の管理下に置ける。
【０００９】
好ましくは、前記ソフトウェア管理装置４０は、携帯端末１０からの利用登録メールにより通知された当該端末の機種名と、制御プログラムの版数と、端末ＩＤとを記録する利用者情報データベース４３１と、保守者が入力した機種別及び版数別の各バージョンアップ用制御プログラムを記憶するバージョンアップ用プログラムデータベース４３２とを備え、保守者が入力した機種名と版数の指定に基づき、利用者情報データベース４３１から各対応する携帯端末の端末ＩＤを抽出すると共に、該抽出された端末ＩＤのリストを元に、前記入力された機種名及び版数に基づきバージョンアップ用プログラムデータベース４３２から抽出されたバージョンアップ用制御プログラムを含むバージョンアップ通知メールを作成し、これらを各携帯端末１０に送信するものである。
【００１０】
従って、保守者による携帯端末の機種名と版数を指定するだけの簡単な操作により、市場に投入された保守対象携帯端末のソフトウェアバージョンアップを能率よくかつ的確に行える。
【００１３】
【発明の実施の形態】
以下、添付図面に従って本発明に好適なる実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。
【００１４】
図２は実施の形態による移動機ソフトウェア管理システムのブロック図で、複数の移動機（図１の携帯端末に相当）１０が無線基地局（ＢＳ）６０と移動体交換局（ＭＳＣ）５０を含む移動網２００及び公衆網１００を介して遠隔の移動機ソフトウェア管理サーバ（図１のソフトウェア管理装置に相当）４０に接続するネットワーク構成を示している。なお、メールアドレスサ−バ７０については後述する．
ところで、一般に、ある通信事業者の提供する移動網２００に収容されるような移動機1０には、メーカＡの移動機１０ＡとメーカＢの移動機１０Ｂ等とが混在しているが、本実施の形態では、例えばメーカＡの移動機１０Ａが該メーカＡの提供する移動機ソフトウェア管理サーバ４０により移動機制御プログラムのバージョンアップサービスを受ける場合を説明する。但し、以下の説明では移動機１０Ａを単に移動機１０と呼ぶ。以下、主要部（移動機ソフトウェア管理サーバ４０，移動機１０）の構成を詳細に説明する。
【００１５】
移動機ソフトウェア管理サーバ４０において、４１は管理サーバ４０の主制御・処理を行うＣＰＵ（管理サーバ制御部）、４２はＣＰＵ４１が使用する主メモリ（ＭＭ）、４３は管理サーバ４０の運用に必要な各種データベース（利用者情報ＤＢ４３１，バージョンアップ用プログラムＤＢ４３２等）を記憶する２次記憶装置（ハードディスク等）、４４は公衆網１００に接続するための通信制御部、４５はＣＰＵ４１の共通バス、４６は保守者が操作をする外部の保守コンソール（ＯＣ）である。
【００１６】
図１０に実施の形態による各種データベースの記憶例を示す。図１０（Ａ）は利用者情報ＤＢ４３１の記憶例を示しており、ここには、各移動機（加入者）１〜Ｎ毎に、移動機のＩＤ情報（電話番号）、機種名、移動機に搭載されている制御プログラムのバージョン（版数）情報が記録される。これらの情報は、市場に投入された際の各移動機１０から通知される。
【００１７】
図１０（Ｂ）はバージョンアップ用プログラムＤＢ４３２の記憶例を示しており、ここには、移動機の管理情報を記憶する記憶エリア４３２Ａと、バージョン（版数）毎のバージョンアップ用プログラムファイルを記憶する記憶エリア４３２Ｂとが含まれる。管理情報の記憶エリア４３２Ａでは移動機の機種毎及び制御プログラムのバージョン毎に作成された各バージョンアップ用プログラムファイルのファイル名が管理される。またバージョンアップ用プログラムファイルの記憶エリア４３２Ｂには移動機の機種毎及びバージョン毎に作成された各バージョンアップ用プログラムファイル(本体）が記録される。
【００１８】
従って、保守者が、バージョンアップしたい移動機の機種名とバージョン(版数）を指定すると、ＣＰＵ４１は該各指定情報に基づき記憶エリア４３２Ａ、４３２Ｂを参照することで，対応するバージョンアップ用プログラムファイルを抽出できる。
【００１９】
図３は実施の形態による移動機ソフトウェア管理サーバの機能ブロック図であり、ここには上記ＣＰＵ４１のプログラム実行により実現される管理サーバ制御部の主な機能ブロックが示されている。図において、主制御部４１１は他の各機能ブロック４１２〜４１６の統括的な制御を行う。利用者情報処理部４１２は利用者情報ＤＢ４３１に対する記憶情報の追加／更新／削除を行う。バージョンアッププログラム処理部４１３はバージョンアップ用プログラムＤＢ４３２に対する記憶情報の追加／更新／削除を行う。保守入力制御部４１４は外部の操作コンソール４６と移動機ソフトウェア管理サーバ４０との間における各種保守情報入出力のインタフェース機能を提供する。メール通信処理部４１５は、移動機１０に送信するメール（バージョンアップ通知メール等）の作成処理、及び移動機１０から受信したメール（利用登録メール等）の解析処理等を行う。そして、サーバ外部通信制御部４１６は、移動機１０との間でメール通信を行うための下位レイヤプロトコル処理（例えばＴＣＰ／ＩＰ）を有し、メールの送受信機能を提供する。
【００２０】
図４は実施の形態による移動機のブロック図で、図において、１１はアンテナ、１２は送受分波スイッチ、１３はπ／４シフトＱＰＳＫ方式等による無線受信部、１４は周波数シンセサイザ、１５はπ／４シフトＱＰＳＫ方式等による無線送信部、１６はＰＤＣ方式等による通信制御部、１７は無線通信データＲＤ／ＴＤとＰＣＭデータ間の変換を行うコーデック（ＣＯＤＥＣ）、１８はＰＣＭデータと音声信号間の変換を行うベースバンド処理部（ＢＢＰ）、１９はスピーカ（ＳＰＫ）、２０はマイク（ＭＩＣ）、２１は移動機の主制御・処理（周辺デバイスの制御，呼処理，移動機制御ソフトウェアのバージョンアップ処理等）を行うＣＰＵ、２２はＣＰＵ２１が使用する主メモリ（ＭＭ）、２３は液晶等による表示部（ＤＩＳＰ）、２４はダイヤルキーやその他の各種制御キーを備えるキーボード（ＫＢＤ）、２５はＣＰＵ２１の共通バス、２６は不図示のコネクタを介して外部機器との間でシリアルデータのやり取りを可能にするシリアルインタフェース（ＳＩＦ）、８０は、外部機器の一つであり、ここでは、移動機１０にＩＤ情報(電話番号）を書き込むためのＩＤ書込端末(図１の外部装置に相当）である。
【００２１】
上記構成により、本移動機の通話時における受信部１３からの受信データＲＤはコーデック１７，ＢＢＰ１８を介して音声信号に変換され、スピーカ１９に出力される。また、マイク２０からの音声信号はＢＢＰ１８，コーデック１７を介して送信データＴＤに変換され、送信部１５により無線送信される。一方、呼の発／着信等に係る呼制御処理や、メールの送受信に係る通信データＣＤについては、通信制御部１６とＣＰＵ２１との間でやり取りされる。
【００２２】
更に、この主メモリ２２には、不揮発性のフラッシュメモリ３１と、移動機１０の電源をＯＦＦにしても一定（実運用上支障がない程度）の期間はその記憶内容が電池でバックアップ保持される不揮発性ＲＡＭ３２と、移動機１０の電源ＯＦＦと共に記憶データも失われる揮発性ＲＡＭ３３とが含まれる。なお、本明細書ではフラッシュメモリ３１のことをＲＯＭと呼ぶ場合もある。
【００２３】
フラッシュメモリ３１において、３１１は移動機１０に搭載されている制御プログラムのプログラムバージョン（版数）の記憶エリア、３１２は移動機のＩＤ情報（電話番号）の記憶エリア、３１３は移動機ソフトウェア管理サーバ４０のメールアドレスの記憶エリアである。このうちの、プログラムバージョンと管理サーバ４０のメールアドレスについては、この移動機の出荷時に既知であり、出荷時に記録可能である。一方、この移動機のＩＤ情報(電話番号）については、この移動機の市場への投入時に、ＩＤ書込端末８０から書き込まれる。更に、３１４は移動機制御プログラムの保存領域であり、ここには移動機１０の主制御・処理を行うための各種アプリケーションプログラムコードが記録されている。
【００２４】
不揮発性ＲＡＭ３２において、３２１はこの移動機を表す所定の情報｛機種名，ＩＤ（電話番号），ソフトウェアバージョン｝の登録を移動機ソフトウェア管理サーバ４０に対して行なうか否かを表すフラグ、３２２は移動機がバージョンアップ処理中（フラッシュメモリ書換中）か否かを表すバージョンアップ状態フラグ、３２３は各種の受信メール（添付のバージョンアップ用プログラムを含む）を保存するメール保存領域である。
【００２５】
揮発性ＲＡＭ３３において、３３１は、ＣＰＵ２１が使用するワークエリアであり、バージョンアップ処理の際には、一部のバージョンアップ（修正）前の制御プログラムからバージョンアップ（修正）後の制御プログラムを作成する為のワークエリアとしても使用される。
【００２６】
図５は実施の形態による移動機の機能ブロック図であり、ここには、ＣＰＵ２１のプログラム実行により実現される移動機制御部の主な機能ブロックが示されている。図において、主制御部２１１は他の各機能ブロック２１２〜２１９を統括的に制御する。
【００２７】
ＩＤ書込制御部２１２は外部のＩＤ書込端末８０からのＩＤ情報(電話番号）の書き込みをインタフェースする。バージョンアップ処理部２１３は受信メール中のバージョンアップ用プログラムコード情報に基づきフラッシュメモリ３１中のプログラムセクタの修正書き込みを行う。メール表示処理部２１４は、受信メールを画面２３に表示し、該メールに対する操作（削除／返信／転送等）のユーザインタフェースを提供すると共に、本発明に係るバージョンアップ操作のユーザインフェースを提供する。
【００２８】
利用登録処理部２１５は、市場に投入された移動機が、初回の電源ＯＮ時、及び本発明によるバージョンアップ処理を実施した際に、遠隔の移動機ソフトウェア管理サーバ４０に対して移動機の機種名，ＩＤ，バージョンを通知するための利用登録メールを作成する。この利用登録メールは、初回の電源ＯＮ時は、この移動機１０が市場に投入されたことをソフトウェア管理サーバ４０に知らせるメールであり、またバージョンアップ完了時は、この移動機１０が新たなバージョンで稼動中であることをソフトウェア管理サーバ４０に知らせるメールである。
【００２９】
無線通信制御部２１６は、移動網２００との間でＰＤＣ通信（音声／パケット）の終端を行なう。メール通信処理部２１７は、通信事業者のメールサーバとの間のメール送受信プロトコルを終端する。表示制御部２１８はメール表示処理部２１４等のアプリケーションからの表示依頼を受けて表示部２３の制御を行なう。そして、ボタン制御部２１９はキーボード部２４のボタン操作を検出し、主制御部２１１に通知する。
【００３０】
以上の構成により、以下に、本実施の形態によるソフトウェアバージョンアップサービスの動作を詳細に説明する。図６は実施の形態による利用登録処理のシーケンス図で、移動機が市場に投入される際に実行される。一般に、移動機の市場投入に際しては、自メーカや他メーカの移動機を問わず、通信サービスを提供する事業者により当該移動機に対して固有のＩＤ情報(電話番号）が書き込まれるが、本発明による移動機１０では、このＩＤ情報(電話番号）の書込を契機にして、移動機内部で利用登録フラグ＝ＯＮとされる点で、他メーカの移動機とは異なる。
【００３１】
動作を具体的に言うと、まずＩＤ書込端末８０からＩＤ情報の書込要求を送り、これに対して移動機１０が応答を返すと、ＩＤ書込端末８０からＩＤ情報（例えば電話番号「０９０１２３４５６７８」）を送る。これを受けた移動機１０では、ステップＳ１で、ＩＤ書込制御部２１２が、受信したＩＤ情報をフラッシュメモリ３１のＩＤ保存領域３１２に保存する。ステップＳ２では、ＩＤ書込制御部２１２が、不揮発性ＲＡＭ３２の利用登録フラグ３２１をＯＮにする。この利用登録フラグ＝ＯＮの状態は、この移動機１０が市場に投入（利用に供）されたことを、該移動機1０が、その後の適当な早い時期に、遠隔のソフトウェア管理サーバ４０に対して知らせるべきであることを示している。そして、ＩＤ書込制御部２１２はＩＤ書込端末８０に対して書込完了を通知する。
【００３２】
その後、この移動機１０に電源投入されると、ステップＳ１１では主制御部２１１が利用登録フラグ＝ＯＮか否かを判別し、ＯＮの場合は、ステップＳ１２で利用登録処理部２１５を付勢し、利用登録メールを作成させる。具体的に言うと、利用登録処理部２１５は、フラッシュメモリ３１から移動機ソフトウェアのバージョン（版数）情報、移動機のＩＤ情報（電話番号）、及び移動機ソフトウェア管理サーバ４０のメールアドレスを読み出し、これらの送信データ（版数情報，ＩＤ情報）及び送信先メールアドレスをメール通信処理部２１７に受け渡してメール送信を依頼する。メール通信処理部２１７はこれらの入力データを元に利用登録メールを作成し、無線通信制御部２１６に送信を依頼する。これを受けた無線通信制御部２１６は最寄の無線基地局６０を介して無線回線の接続を行い、利用登録メールを送信する。このメールは移動網２００，公衆網１００を経由し、移動機ソフトウェア管理サーバ４０に到達する。
【００３３】
移動機ソフトウェア管理サーバ４０では、移動機１０からの利用登録メールを通信制御部４４及びサーバ外部通信制御部４１６を介して受信し、メール通信処理部４１５に通知する。メール通信処理部４１５では受信メールの解析を行い、受信データを主制御部４１１に通知する。これを受けた主制御部４１１では、利用者情報処理部４１２に利用者の登録を要求する。この際の要求パラメータには、移動機のＩＤ（例えば０９０１２３４５６７８）と、移動機の機種名(例えばＦ５０４ｉ）と、移動機制御プログラムのバージョン情報(例えば０００１版）とが含まれる。これを受けた利用者情報処理部４１２は、ステップＳ１３で、利用者情報ＤＢ４３１に対して当該移動機1０のＩＤ（電話番号），機種名，ソフトウェアバージョンを登録する。こうして、市場に投入された移動機１０は移動機ソフトウェア管理サーバ４０の管理下におかれる。そして、登録が完了すると、主制御部４１１に登録完了を通知する。  主制御部４１１は、この通知を受けたことによりメール通信処理部４１５に対して、正常終了を表す登録完了メールを移動機１０に送信するように依頼する。これを受けたメール通信処理部４１５は登録完了メールを生成し、これをサーバ外部通信制御部４１６を介して移動機１０に送信する。
【００３４】
移動機１０では、登録完了メールを受信したことにより、メール通信処理部２１７が、受信メールを解析し、結果を利用登録処理部２１５に通知する。利用登録処理部２１５は、登録結果が正常終了であった場合は、ステップＳ１４で利用登録フラグ３２１をＯＦＦに設定する。なお、登録結果が異常であった場合は、上記の管理サーバ４０への利用登録処理を再起動し、正常に完了するまで処理を継続する。
【００３５】
図７は実施の形態によるバージョンアップ通知処理のシーケンス図であり、市場に投入された移動機につきソフトウェアの不具合が発見されると、この処理が行われる。図において、上記不具合を解決するためのバージョンアップ用プログラムが作成されると、保守者は、ステップＳ２１で、保守コンソール４６を介してバージョンアップ用プログラム登録の手続▲１▼を行う。これを受けたバージョンアッププログラム処理部４１３は、ステップＳ２２で、バージョンアップ用プログラムＤＢ４３２への登録▲１▼を行う。
【００３６】
図１０（Ｂ）に上記手続▲１▼及び登録▲１▼の情報例を示す。保守者の入力情報▲１▼には、機種名：Ｆ５０４ｉ，バージョン：０００３，バージョンアップ用プログラム（ファイル名：Ｆ５０４ｉ−００３．ＰＡＴ）の本体が含まれる。バージョンアッププログラム処理部４１３は、このうちの機種名：Ｆ５０４ｉ，バージョン：０００３及びバージョンアップ用プログラムファイル名：Ｆ５０４ｉ−００３．ＰＡＴの各情報を管理情報の記憶エリア４３２Ａに記録し、かつこれに対応するバージョンアップ用プログラムの本体部をバージョンアップ用ファイルの記録エリア４３２Ｂに該ファイル名でアクセス可能に記録する。
【００３７】
図７に戻り、更に、次の版（０００４）のバージョンアップ用プログラムが作成されると、保守者は、ステップＳ２３で、保守コンソール４６を介してバージョンアップ用プログラム登録の手続▲２▼を行い、これを受けたバージョンアッププログラム処理部４１３は、ステップＳ２４で、バージョンアップ用プログラムＤＢ４３２への登録▲２▼を行う。図１０（Ｂ）にこの手続▲２▼及び登録▲２▼の情報例を示す。
【００３８】
次に、保守者は，移動機ソフトウェアのバージョンアップが必要となると、バージョンアップの指示入力を行う。即ち、ステップＳ２５では、保守者が、バージョンアップの指示入力を行う。この指示は、例えば機種名：Ｆ５０４ｉ，バージョン：０００３，０００４の入力により行う。これを受けたソフトウェア管理サーバ４０では、利用者情報処理部４１２が、ステップＳ２６で、利用者情報ＤＢ４３１を参照してバージョン毎に送信先ＩＤリストを作成する。
【００３９】
図１０（Ａ）の利用者情報ＤＢ４３１を参照すると、利用者情報処理部４１２は、機種名：Ｆ５０４ｉのうちの、バージョン：０００３については２つのＩＤ：「０９０１２３４５６０２」，「０９０１２３４５６９６」を抽出し、またバージョン：０００４については３つのＩＤ：「０９０１２３４５６９７」，「０９０１２３４５６９８」，「０９０１２３４５６９９」を抽出する。本実施の形態ではこれらのＩＤに、所定のドメインネーム（例えば＠ｄｏｃｏｍｏ．ｎｅ．ｊｐ）を付すことで、送信先ＩＤリストを作成する。図１１（Ａ）に送信先ＩＤリストの例を示す。
【００４０】
ステップＳ２７では、保守者が、必要ならバージョンアップの案内文を入力すると共に、メール送信の決定を行う。なお、案内文については予めあるものを保守者が選択しても良いし、又はメール通信処理部４１５にて固定文として保持されているものを付与しても良い。
【００４１】
これを受けたソフトウェア管理サーバ４０では、メール通信処理部４１５が、ステップＳ２８で、移動機１０へのバージョンアップ通知メール（本文，案内文．セパレータ，バージョンアップ通知プログラムコード情報を含む）を作成すると共に、各対応する移動機のメールアドレスを宛先として、バージョンアップ通知メールの送信を行う。
【００４２】
図１１（Ｂ）にバージョンアップ通知メールのフォーマット例を示す。バージョンアップ通知メールは、例えば案内文，セパレータ（以降のデータがバージョンアップ用プログラムコードである事を示す固定文字列等）、バージョンアップ用プログラムコードの構成とする。
【００４３】
図１２にメールに添付されるバージョンアップ用プログラムのフォーマットを示す。「修正後バージョン」はこのバージョンアップを実行した後の移動機ソフトウェアのバージョン（版数）を示す。この情報は、バージョンアップ完了時に、フラッシュメモリのプログラムバージョンの記憶リア３１１に書き込まれると共に、移動機ソフトウェア管理サーバ４０に通知する際にも使用される。「修正ＲＯＭセクタ数」は本メールによるバージョンアップ実行時に書き換え（修正）を行うべきフラッシュメモリ３１のセクタ数を表す。「セクタ先頭アドレス」はフラッシュメモリ３１上の修正対象セクタの先頭アドレスを表す。「セクタサイズ」はセクタ先頭アドレスからの修正サイズ（バイト）を表す。「コードブロック数」は修正対象セクタ内に連続して書き込み可能な修正用プログラムコードのブロック数を表す。例えば１セクタ内の１００〜１２０番地と、２００〜２３０番地の各内容を書き換える場合はコードブロック数＝２となる。「コードアドレス」は後述のコード領域内に格納された修正用プログラムコードを１セクタ内のどの相対番地から展開するのかを表す。「コードサイズ」は１ブロック当たりの連続する修正用プログラムコードが何バイトあるかを表す。例えば１００〜１１９番地までを書き換える場合は、コードサイズ＝２０を示し、連続するコード領域には２０バイト分のプログラムコードが格納されている事を表す。そして、「コード領域」にはフラッシュメモリ３１に展開すべき修正用プログラムコードが格納されている。
【００４４】
次に、上記バージョンアップ通知メールを受信した移動機１０での動作を説明する。移動機１０では、ユーザがメールを閲覧する際、本文内にバージョンアップ用メールである事を表すセパレータがあるか否かを検索し、該セパレータを検出すると、当該メールのサブメニュー画面を表示する際には、バージョンアップを行う為のメニュー項目を表示する。また、バージョンアップ状態フラグ３２２にＯＦＦ（バージョンアップ未実施）を記憶する。そして、ユーザが当該サブメニュー画面よりバージョンアップの操作を行った場合は、バージョンアップ処理部２１３を起動し、この時入力データとしてメール本文内のバージョンアップ用プログラムコードを引き渡す。
【００４５】
このバージョンアップ処理は、できるだけ短時間で行うために、不具合のあったセクタのみを書き換える（修正する）方式とする。このためには、図４に示す如く、予めフラッシュメモリ３１の各セタク（ｉ〜ｉ＋ｎ）をプログラムコードの書込エリア（例えば６３Ｋバイト）と、プログラム修正（パッチ）のための空きエリア（例えば１Ｋバイト）とに分けておき、セクタ毎の修正用プログラムコードを各パッチエリアに書き込む方法で行う。以下、これを具体的に説明する。
【００４６】
図８は実施の形態による移動機バージョンアップ処理のフローチャートで、バージョンアップ処理部２１３により実行される。ステップＳ５１ではバージョンアップ状態フラグ３２２をＯＮ（実行中）にする。なお、この状態フラグ３２２は、後述のステップＳ５９におけるＲＯＭセクタの消去開始直前にＯＮにしても良い。上記いずれにしても、予めバージョンアップ状態フラグ３２２をＯＮにしておくのは、最初のセクタ消去実行後に予期せぬ要因により移動機１０の電源がＯＦＦにされたような場合には、該移動機１０のプログラムが不完全な状態となってしまうため、次回電源ＯＮ時にその事がプログラムより識別可能な様にバージョンアップ状態フラグ３２２をＯＮに書き換えるものである。
【００４７】
ステップＳ５２ではレジスタｉにバージョンアップ用プログラム中の修正ＲＯＭセクタ数をセットする。ステップＳ５３ではｉ＝０か否かを判別し、ｉ＝０でない場合は、ステップＳ５４に進み、バージョンアップ用プログラム中のセクタ先頭アドレスで指定されるフラッシュＲＯＭアドレスから１セクタ分の修正前のプログラムコードを読出し、これをＲＡＭ３３のワークエリア３３１にコピーする。ステップＳ５５ではレジスタｊにバージョンアップ用プログラム中のコードブロック数をセットし、かつレジスタｋに１をセットする。ステップＳ５６ではｊ＝０か否かを判別する。
【００４８】
ｊ＝０でない場合は、ステップＳ５７に進み、ｋ（最初は１）番目のコードブロックデータに基づき、前記ワークエリア３３１上にコピーされたプログラムコードを修正する。ステップＳ５８では、レジスタｊに−１し、かつレジスタｋには＋１する。そして、ステップＳ５６に戻る。こうして、１セクタにつき、コードブロック数分の修正が順次行われる。
【００４９】
図１２の挿入図（ａ）に上記プログラム修正処理のイメージを示す。この例では最初の修正セクタにつき２つの修正用コードブロック▲１▼，▲２▼が存在する。まずｋ＝１では、コードブロック▲１▼のコード領域にある修正用プログラムコード▲１▼をＲＡＭ領域３３１のパッチエリアにコピーすると共に、該ＲＡＭのプログラムコードエリア中の修正対象位置から該パッチプログラムコード▲１▼の先頭番地にジャンプし、かつ該パッチプログラムコード▲１▼の終わりの番地から前記プログラムコードエリア中の戻り位置にジャンプする(戻る）ように修正を行う。次に、ｋ＝２では、次コードブロック▲２▼について上記同様の修正処理を行う。こうして、修正の必要な個所のみが効率よく修正される。
【００５０】
図８に戻り、ステップＳ５６ではｊ＝０か否かを判別する。ｊ＝０の場合は、１セクタ分の修正準備完了であるので、ステップＳ５９に進み、当該ＲＯＭセクタのデータを消去する。ステップＳ６０では、該消去したＲＯＭセクタにワークエリア３３１上の修正後のプログラム（１セクタ分）を書き込む。そして、図示しないが、１つのセクタに書き込み完了した時点で該当セクタへ書き込み禁止設定を行う。ステップＳ６１ではレジスタｉに−１し、ステップＳ５３に戻る。
【００５１】
ステップＳ５３ではｉ＝０か否かを判別し、やがてｉ＝０になると、全ての修正対象セクタに対しての書き換えが完了したことになる。処理は、ステップＳ６２に進み、バージョンアップ状態フラグをＯＦＦ（終了）にする。ステップＳ６３では、自己の制御プログラムがバージョンアップされたことを後に管理サーバ４０に知らせるために、利用登録フラグをＯＮにする。そして、この処理を抜ける。
【００５２】
なお、移動機１０の電源ＯＮ時に上記バージョンアップ状態フラグ３２２＝ＯＮの場合には、バージョンアップ処理が何らかの要因により中断したと判断し、上記バージョンアップ処理を再度実行する。
【００５３】
図９は実施の形態によるバージョンアップ完了通知のシーケンズ図であり、上記のプログラム修正完了後、この移動機１０は出荷時（市場投入時）のプログラムバージョンとは異なるものとなる為、移動機ソフトウェア管理サーバ４０に対してバージョンアップを行った旨をメールにて通知する。
【００５４】
なお、このバージョンアップ完了通知は、移動機ソフトウェア管理サーバ４０の側から見ると、新たなバージョンを有する移動機（但し、ＩＤ同一）が新たに利用登録されるのと同様である。従って、このバージョンアップ完了通知のシーケンズは、上記図６で述べた利用登録通知のシーケンスと略同様に行える。但し、この利用登録メールに搭載されるバージョン(版数）は更新後の版数である。これを受けた移動機ソフトウェア管理サーバ４０では、ステップＳ７３で、当該端末ＩＤに対応する欄のバージョン（版数）を更新する。そして、ソフトウェア管理サーバ４０が登録完了メールを返送すると，これを受けた移動機１０は、ステップＳ７４で利用登録フラグをＯＦＦにする。
【００５５】
なお、上記実施の形態では移動機１０のＩＤ情報（電話番号）に一定のドメインネーム（例えば＠ｄｏｃｏｍｏ．ｎｅ．ｊｐ）を加えることで各移動機毎のメールアドレスを自動的に生成したが、これに限らない。他にも、例えばソフトウェア管理サーバ４０に利用登録を行う移動機１０の側から自己のメールアドレスを通知するようにしても良い。又は、例えば図２に示す如く、移動網２００の通信事業者がメールアドレスサーバ７０を設けると共に、ソウトウェア管理サーバ４０の側から移動機１０のＩＤ（電話番号）を伴ってメールアドレスサーバ７０にメールアドレスの問い合わせを行い、これを受けたメールアドレスサーバ７０からソフトウェア管理サーバ４０に当該移動機１０のメールアドレスを通知するように構成しても良い。
【００５６】
また、上記保守者によるバージョンアップ対象情報（機種名，版数等）の入力は、上記図３に示した如く、保守入力制御部４１４を介した直接的なものでも良いし、又はサーバ外部通信制御部４１６を介してのネットワーク経由による遠隔からの入力であっても良い。
【００５７】
また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、制御、処理及びこれらの組み合わせの様々な変更が行えることは言うまでも無い。
【００５８】
（付記１）  複数の携帯端末と、各携帯端末の機種別及び版数別のバージョンアップ用制御プログラムを蓄積・管理する遠隔のソフトウェア管理装置とがメールにより相互に通信可能な移動通信システムであって、前記携帯端末は、外部装置からの端末ＩＤの書き込みを契機として、その後の電源投入時に自端末の機種名と、制御プログラムの版数と、端末ＩＤとを含む利用登録メールを作成し、ソフトウェア管理装置に送信することを特徴とする移動通信システム。
【００５９】
（付記２）  前記ソフトウェア管理装置は、携帯端末からの利用登録メールにより通知された当該端末の機種名と、制御プログラムの版数と、端末ＩＤとを記録する利用者情報データベースと、保守者が入力した機種別及び版数別の各バージョンアップ用制御プログラムを記憶するバージョンアップ用プログラムデータベースとを備え、保守者が入力した機種名と版数の指定に基づき、利用者情報データベースから各対応する携帯端末の端末ＩＤを抽出すると共に、該抽出された端末ＩＤのリストを元に、前記入力された機種名及び版数に基づきバージョンアップ用プログラムデータベースから抽出されたバージョンアップ用制御プログラムを含むバージョンアップ通知メールを作成し、これらを各携帯端末に送信することを特徴とする付記１に記載の移動通信システム。
【００６０】
（付記３）  複数の携帯端末と、各携帯端末の機種別及び版数別のバージョンアップ用制御プログラムを蓄積・管理するソフトウェア管理装置とがメールにより相互に通信可能な移動通信システムの携帯端末装置であって、自己の制御プログラムを一定サイズのセクタ毎に消去及び書込可能なフラッシュメモリに保持すると共に、予め各セクタを被修正プログラムの記憶エリアと、修正用プログラムの記録エリアとに分割しておき、セクタ単位にプログラム修正を行うことを特徴とする携帯端末装置。
【００６１】
（付記４）  プログラムの修正は、まずフラッシュメモリ上の該当する１セクタ分の被修正プログラムコードをワークＲＡＭ領域上にコピーし、次に受信メール中の修正用プログラムコードを前記ワークＲＡＭ領域の被修正プログラムコード上に展開してプログラムの修正を行い、次に、前記１セクタ分のフラッシュメモリ領域を消去し、次に前記ワークＲＡＭ領域上の修正後のプロフラムコードを前記１セクタ分のフラッシュメモリ領域に書き込むことを特徴とする付記３に記載の携帯端末装置。
【００６２】
【発明の効果】
以上述べた如く本発明によれば、ユーザ所有の携帯通信端末を回収することなく、また容易な操作により端末内プログラムのバージョンアップを行うことができるため、バージョンアップに伴うユーザの利便性の向上及び製品提供側の労力、経費削減に貢献することができる。
【図面の簡単な説明】
【図１】本発明の原理を説明する図である。
【図２】実施の形態による移動機ソフトウェア管理システムのブロック図である。
【図３】実施の形態による移動機ソフトウェア管理サーバの機能ブロック図である。
【図４】実施の形態による移動機のブロック図である。
【図５】実施の形態による移動機の機能ブロック図である。
【図６】実施の形態による利用登録処理のシーケンス図である。
【図７】実施の形態によるバージョンアップ通知処理のシーケンス図である。
【図８】実施の形態による移動機バージョンアップ処理のフローチャートである。
【図９】実施の形態によるバージョンアップ完了通知のシーケンズ図である。
【図１０】実施の形態による各種データベースの記憶構造を示す図である。
【図１１】実施の形態によるバージョンアップ通知処理のイメージ図である。
【図１２】メールに添付されるバージョンアップ用プログラムのフォーマットを示す図である。
【符号の説明】
１０  移動機
４０  移動機ソフトウェア管理サーバ
４６  保守コンソール（ＯＣ）
５０  移動体交換機
６０  無線基地局
７０  メールアドレスサ−バ
８０  ＩＤ書込端末(外部装置）
１００  公衆網
２００  移動網
４３１  利用者情報データベース
４３２  バージョンアップ用プログラムデータベース
【図１】
0003782956.tif 000002
【図２】
0003782956.tif 000003
【図３】
0003782956.tif 000004
【図４】
0003782956.tif 000005
【図５】
0003782956.tif 000006
【図６】
0003782956.tif 000007
【図７】
0003782956.tif 000008
【図８】
0003782956.tif 000009
【図９】
0003782956.tif 000010
【図１０】
0003782956.tif 000011
【図１１】
0003782956.tif 000012
【図１２】
0003782956.tif 000013