JP2005215841A

JP2005215841A - ソフトウエア修正機能付き携帯電話端末装置

Info

Publication number: JP2005215841A
Application number: JP2004019624A
Authority: JP
Inventors: Ryozo Kiyohara; 良三清原
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2004-01-28
Filing date: 2004-01-28
Publication date: 2005-08-11

Abstract

【課題】ソフトウエアの更新時に、フラッシュＲＯＭ装置２中のソフトウエアの書き換え途中で電源が落ちても、ソフトウエアを自動的に修復することができる携帯電話端末装置を提供する。
【解決手段】フラッシュＲＯＭ装置２に記憶された携帯電話を作動するソフトウエア中の要修正ソフトウエアのブロックをＲＡＭ装置４に記憶し、シフトウエア修正手段３がこのブロック中のソフトウエアをサーバからダウンロードされた修正データに基づいて修正し、この修正ソフトウエアをフラッシュＲＯＭ装置２に書き込み、またこの書き込みが正常に終了しなかった場合には、リカバリ手段９がフラッシュＲＯＭ装置２に記憶されたソフトウエアを修正ソフトウエアの書き込み前の状態に戻すリカバリ処理を実行する。
【選択図】図１

Description

本発明は、装置の各機能を実現するソフトウエアをユーザ自身が書き換えることができる携帯端末装置に関するものである。

近年携帯電話の機能が増大し、携帯電話の各機能を実現するためのソフトウエアの規模が大きくなっている。そのため、出荷する携帯電話のソフトウエアに不具合が生じることもあり、そのソフトウエアの不具合を修正するための方法が種々考えられている。

例えば、プログラムのデバッグ方法では、ホストコンピュータより実行形式プログラムに係るデータがダウンロードされ、該プログラムのデバッグを行なうエミュレータにおいて、ダウンロード時間の短縮を図る方法が提案されており、この方法ではプログラムの差分情報を適用する方法が示されている（例えば、特許文献１参照）。

また、オンライン中におけるロードモジュール入替方式では、論理ＩＤと物理ＩＤとを対応させたプログラム管理ファイルを設けるとともにロードモジュールを呼び出す時に論理ＩＤを呼び出すように構成した方式が示されている（例えば、特許文献２参照）。

特開２００３−３６１８７号公報特公平７−３１５９５号公報

従来のプログラムのデバッグ方法では、修正されたソースプログラムを含めたロードモジュール全体の差分情報のみをダウンロードすることによりダウンロード時間の短縮を図ることについては記載されているものの、差分情報を利用したこの処理中に電源が切れた場合に、どのように修復するかといったことについては言及されていない。
また、従来のオンライン中におけるロードモジュール入替方式では、オンライン中の処理系でのモジュール入れ替え方式として、修復したかどうかをフラグ用いた技術について記載されているが、この処理中に電源が切れた場合、どのように修復するかといったことについては言及されていない。
本発明では、携帯電話などの組込系ソフトウエアにおいて、ソフトウエアの更新時、不揮発性のメモリ領域中のソフトウエアの書き換え途中で電源が落ちても、ソフトウエアを自動的に修復することができ、また、ユーザが店などに携帯電話などを持ち込まなくてもソフトウエアを元の状態に戻すことができる、ソフトウエアの更新を目的とするものである。

この発明に係るソフトウエア修正機能付き携帯電話端末装置は、携帯電話を作動するソフトウエアが記憶され、又このソフトウエアの修正を行なう修正データが保存された不揮発性メモリと、
サーバからダウンロードされた前記修正データを前記不揮発性メモリに保存する保存手段と、
前記不揮発性メモリに記憶された前記ソフトウエア中の要修正ソフトウエアのブロックが記憶された記憶装置と、
前記ブロックを前記不揮発性メモリに記憶された前記ソフトウエア中から読み込み前記記憶装置に記憶し、又前記記憶装置に記憶された前記ブロック中のソフトウエアを前記修正データに基づいて修正し、この修正ソフトウエアを前記不揮発性メモリに書き込むソフトウエア修正手段と、
前記ソフトウエア修正手段による前記不揮発性メモリへの修正ソフトウエアの書き込みが終了したか否かの判定をするリカバリ要否判定手段と、
前記リカバリ要否判定手段により前記修正ソフトウエアの書き込みが終了したと判定されなかった場合には前記不揮発性メモリに記憶されたソフトウエアを前記修正ソフトウエアの書き込み前の状態に戻すリカバリ処理を実行するリカバリ手段と、を備えたものである。

この発明は、以上説明したように、不揮発性メモリに記憶された携帯電話作動用のソフトウエアをサーバからダウンロードされた修正データに基づいて修正し、この修正ソフトウエアを前記不揮発性メモリに書き込み、書き込みが終了しなかった場合には不揮発性メモリに記憶されたソフトウエアを修正ソフトウエアの書き込み前の状態に戻すリカバリ処理を実行することにより、携帯電話端末装置のソフトウエアの更新処理をユーザ自身が実施することができる効果を奏する。また、この更新処理が正常に終了しない異常時にも携帯電話端末装置のソフトウエアを更新前の元の状態に自動的に復帰させることができる効果を奏する。

実施の形態１．
以下、この発明の実施の形態を図を参照して説明する。
図１は、実施の形態１のソフトウエア修正機能付き携帯電話端末装置の構成図である。図において、１は携帯電話端末装置である。２は携帯電話端末装置１を作動するソフトウエアが記憶されたフラッシュＲＯＭ装置であり、フラッシュＲＯＭ装置２は電源をオフしても消えない不揮発性メモリの一種である。３はフラッシュＲＯＭ装置２に記憶されたソフトウエアを修正するためのソフトウエア修正手段である。ここで、ソフトウエアは携帯電話端末装置に命令する手順そのものを指すプログラムをも含めたものである。

４はフラッシュＲＯＭ装置２に記憶されたソフトウエアを修正するために、ソフトウエア修正手段３によりフラッシュＲＯＭ装置２から読み込まれた修正を要するソフトウエアのブロックが記憶された記憶装置としてのRAM装置４である。
フラッシュＲＯＭ装置２へのソフトウエアの書き込みは逐次可能であるが、消去はあるまとまったブロックと呼ぶ単位毎でしか行なえないという特徴がある。そのため、ソフトウエアの修正をする場合には、ブロック単位のソフトウエアをまとめて消した後に新たなソフトウエアを書き込む必要がある。

即ち、ソフトウエアの一部だけを書き換えるためには、修正するソフトウエアのブロックをRAM装置４に記憶しておき、このブロック中の要修正ソフトウエアに修正を入れることにより、フラッシュＲＯＭ装置２への書き込みのイメージ（修正済みのソフトウエアのブロック）をＲＡＭ装置４上で作成してから、修正を入れなかった部分（元のままの部分）と修正を入れた部分（書換えた部分）とを含めたブロックとしてまとめてフラッシュＲＯＭ装置２に書き込む。これにより、フラッシュＲＯＭ装置２に記憶されたソフトウエアの修正が行なわれる。なお、フラッシュＲＯＭ装置２から読み込まれた修正するためのソフトウエアのブロックはRAM装置４に記憶した後にフラッシュＲＯＭ装置２から消去する。

５は最近の携帯電話端末装置１に搭載されているデータ通信をするための無線通信手段であり、例えば、パケット通信上でのＴＣＰ／ＩＰや、ＨＴＴＰなどのさまざまなプロトコルに対応するべき手段である。６はフラッシュＲＯＭ装置２に記憶されたソフトウエアの修正を行なう修正データ（ソフトウエアを表す。以下同様。）を無線通信手段５を介してサーバから取り込むダウンロード手段である。

７はダウンロード手段６でダウンロードしたデータを電源断などがあっても消えないようにフラッシュＲＯＭ装置２に一時的に保存する一時保存手段である。このように不揮発性メモリであるフラッシュＲＯＭ装置２にダウンロードしたデータを保存すれば、電池の容量がなくなったり電池がはずされたりしても、メモリ内容、即ちフラッシュＲＯＭ装置２にダウンロードしたデータは消えないので、ダウンロードデータは電池の状態に関係なくフラッシュＲＯＭ装置２に保存されたままの状態となる。

ここで上述のソフトウエア修正手段３について再度説明すると、ソフトウエア修正手段３は、先にＲＡＭ装置４上に記憶された修正を必要とするソフトウエアのブロック中のソフトウエアを、ダウンロード手段６によりダウンロードされたソフトウエアの修正を行なう修正データ、即ち後述する差分データ（ソフトウエア）に基づいて修正を行なう。その後、この差分データを適用した後の修正ソフトウエアのイメージをＲＡＭ装置４上で作成し、この作成した修正ソフトウエアのイメージをフラッシュＲＯＭ装置２に転送して書き込み記憶することによりフラッシュＲＯＭ装置２に記憶されたソフトウエアを修正するものである。

８はフラッシュＲＯＭ装置２に記憶されたソフトウエアを修正する処理中に電源断などでソフトウエアの修正が途中状態で終わってしまった状態なのかどうか、即ちフラッシュＲＯＭ装置２に修正ソフトウエアのイメージを書き込むまでの処理が途中状態で終わってしまった状態なのかどうかを判定するリカバリ要否判定手段である。９はリカバリ要否判定手段８での判定結果に基づきフラッシュＲＯＭ装置２の状態をソフトウエアの修正前の状態に戻すリカバリ処理を実行するリカバリ手段である。

次に動作について説明する。
図２は、ソフトウエアの更新処理手順を示すフローチャートである。
図を用いて、ソフトウエアの更新処理動作について説明する。まず、ダウンロード手段６がステップＳ１０１でソフトウエアの更新が必要か否かを判定する。この判定は、無線通信手段５を利用して、更新サービスをするサーバに自己のバージョン情報を送付した上で更新が必要かを問い合わせることにより判断してもかまわないし、ユーザが最新バージョン情報を入力して更新を必要とするかどうかを判断しても良いし、バージョン情報を表示して、ユーザが更新するかどうかを選択してもかまわない。あるいは、無線通信手段５を利用して、例えば、ソフトウエアの更新データを提供するサーバから最新バージョン情報を獲得して、移動機上で更新が必要化否かを判断してもかまわない。この判断には、最新のバージョンの情報と移動機のバージョンの情報が同じかどうかで判断するか、または、最新のバージョンの情報と移動機のバージョンの情報との大小関係で判断する。

ステップＳ１０１でソフトウエアの更新が必要となると、ダウンロード手段６がステップＳ１０２でダウンロード手段６を利用してファイル（ソフトウエアの修正を行なう修正データ）をダウンロードする。このダウンロードは、例えばダウンロード手段６が無線通信手段５を介してサーバに対して自己のソフトウエアのバージョン情報を送り、サーバから最新のソフトウエアにアップデートするためのファイル名や場所を示す情報などの必要なファイル情報をもらう。この操作は、サーバからファイルのリストを送付してもらい、その中から自己のバージョンにあったファイルを選択しても良いし、ユーザがバージョンの情報を見てファイルを選択するという方法でもかまわない。

ダウンロード手段６によりダウンロードされたファイルは、電源断などがあっても消えないように一時保存手段７がフラッシュＲＯＭ装置２に記憶する。この記憶領域は不揮発性のメモリであれば、フラッシュＲＯＭでもバッテリバックアップのＲＯＭでもかまわない。

次に、ステップＳ１０３でダウンロードされたデータを解析してフラッシュＲＯＭ装置２上のソフトウエアをソフトウエア修正手段３およびＲＡＭ装置４を利用して書き換える。即ち、ソフトウエア修正手段３およびＲＡＭ装置４を利用してフラッシュＲＯＭ装置２上のソフトウエアの修正を行なう。具体的な書き換えの処理動作については後述する。
なお、ステップＳ１０３の書き換え処理の最後には、例えば、チェックサムをとるなどして正常に書き換えられたことを確認した後、ステップＳ１０４で再起動をする。

ステップＳ１０４で再起動された後、リカバリ要否判定手段８がステップＳ１０５で正常に書き換えられたか否を判定し、正常に書き換えられた場合には、例えばチェックサムが正しく、後述する書き換えの処理動作で書き換え完了の状態であれば、正常に書き換えが完了したと判定し、書き換えの処理は終了する。
一方、正常に書き換えが完了してないと判定された場合は、リカバリ処理が行なわれる。

次に、リカバリ手段９がステップＳ１０６でリカバリ処理を行なう。このリカバリ処理については後述する。ステップＳ１０７でリカバリ中のフラグやチェックサムなどを見て正しくリカバリ処理が行われたかどうかを判定し、正しくリカバリ処理が行われた判定された場合は更新処理を終了する。正常にリカバリ処理が行われなかったと判定された場合は、故障を示す情報を出して異常終了とする。

次に、ソフトウエアの書き換え処理動作について説明する。
図３は、ソフトウエアの書き換え処理の処理手順を示すフローチャートである。書き換え処理が開始されると、まず、ソフトウエア修正手段３がステップＳ２０１で書き換え中であることを示す書き換え中フラグを設定し、この設定した書き換え中フラグをフラッシュＲＯＭ装置２に記憶する。電池を抜かれた場合など電源断の後に携帯電話端末装置１が再起動された時には、リカバリ要否判定手段がフラッシュＲＯＭ装置２に記憶された書き換え中フラグを確認することによって、書き換えが正常に完了した通常の起動なのか、書き換え中になんらかの原因で起動がかかったのかを判断することができる。例えば、再起動時に、書き換え開始時に設定した書き換え中フラグが確認された場合には、書き換え処理が正規に終了しなかったと判断され、また書き換え中フラグが確認されなかった場合には、書き換え処理が正規に終了したと判断される。

次に、ソフトウエア修正手段３がステップＳ２０２で差分データを解析する。通常、フラッシュＲＯＭ装置２は書き換え対象部分と書き換え非対象部分とがある。例えば、プログラムコード部は書き換え対象となり、ユーザデータは非書き換え対象となる。
差分データは、これまでフラッシュＲＯＭ装置２に記憶されていたデータ（ソフトウエア）である旧版と新たにフラッシュＲＯＭ装置２に記憶されるデータ（ソフトウエア）である新版とを比較して、新版に追加や書き換えることが必要となるデータを示すものであり、旧版と新版とを比較して、データを換えることのない不変の部分と内容は同じであるが配置されたアドレス（位置）がずれている部分と、データが新しく挿入される部分との情報の組み合わせにより決まる。不変の部分は、開始アドレスと終了アドレスの情報、開始アドレスとその開始アドレスからのサイズの情報で示される。また、新しく挿入されるべき情報は新規に挿入したソフトウエアそのものをデータとして表現する。

次に、ソフトウエア修正手段３がステップＳ２０３で差分データの中で独立な部分に関してソフトウエアの書き換え領域即ちソフトウエアの修正領域を読み出す。ここで独立な部分とは、複数の領域間で位置がずれる、即ち、旧版から新版にコピーする領域に関して重なることがない領域のことで、旧版を書き換えてしまってもその書き換え前の情報を新版にコピーすることがないことを保証するものである。

言いかえると、独立な部分とは、ページ : 5旧版の情報から新版の情報を作成する時の基本的な部分で、新版を旧版から作成していく場合、新版を作成してメモリ上に書き込んでしまうと、旧版の情報は消えてしまうので、消えたあとで旧版の情報を利用したくてもそれができない。つまり、新版をある領域に書き込んだら、その書き込まれた領域にあった旧版の情報は使えなくなる。逆にいうと、書き込んだ後はその領域の情報を使わないことを保証する必要がある。独立な部分を示すには、全差分データを読み込んで解析しても良いし、保証することを示す情報を差分データの中に入れておいても良い。

ステップＳ２０３で書き換えの対象となる書き換え領域が読み出されると、ソフトウエア修正手段３がステップＳ２０４で、一旦書き換え領域をバックアップするためにフラッシュＲＯＭ装置２に書き換え領域を退避する。即ち、書き換え領域をフラッシュＲＯＭ装置２のバックアップ領域に記憶する。
続いて、ソフトウエア修正手段３はステップＳ２０５でリカバリフラグを設定する。リカバリフラグは、リカバリ処理中に電源断により携帯電話端末装置１が切れリカバリ処理が中断した後に、携帯電話端末装置１を再起動した時にリカバリ処理が中断したことを示すフラグであり、ソフトウエア修正手段３がステップＳ２０５で設定したリカバリフラグをフラッシュＲＯＭ装置２に記憶する。

次に、ソフトウエア修正手段３がステップＳ２０６で、差分適用を行なう。差分適用は、差分データを解析し、移動もなにもしない部分はそのままで、移動するべきものは元のデータから移動し、新しいデータに関しては挿入することにより生成イメージ、即ち修正ソフトウエアのイメージを作成し、この生成イメージをフラッシュＲＯＭ装置２に書き込むことにより行なう。

次に、ソフトウエア修正手段３がステップＳ２０７で逆差分データを生成する。逆差分データは、フラッシュＲＯＭ装置２に記憶されたデータ（ソフトウエア）を書き換え修正前のデータに復元する時に利用されるデータであり、旧版から新版に移動されたデータである。旧版から新版に移動したデータは新版から逆に旧版にもどすことにより、フラッシュＲＯＭ装置２に記憶されたデータ（ソフトウエア）を書き換え修正前のデータに復元することができる。なお、旧版から新版に移動しなかったデータは新版から旧版に戻すことはなく逆差分データにはならない。

ここでデータを挿入した部分は無視してよく、逆に、移動やデータ挿入によって消えてしまったデータに関しては図３のステップＳ２０４でフラッシュＲＯＭ装置２に退避させた書き換え領域（バックアップ領域）を参照した上で、バックアップ領域に記憶されたデータを逆差分データとして逆差分情報を生成する。これは、旧版から新版を作成する際に、新規に挿入されたデータを記載していたが、元に戻す時には挿入されたデータそのものがあっても意味がなく、逆に、旧版には存在したが、コピーや新規のデータによって消去された情報は必要になるためである。

ステップＳ２０８では、独立した部分の一つの処理を終えた段階で、全領域の書き換えが終了したかどうかを確認し、終了していなければ、テップＳ２０２からのステップを繰り返す。全部終了している場合には、リカバリ要否判定手段８がステップＳ２０９で、例えば、チェックサムなどによって正常に書き換えられていることを確認し、ステップＳ２１０で正常終了が確認された場合には、ステップＳ２１１で書き換え中フラグを消去して書き換え処理は終了する。

この書き換え処理終了時に、必要があれば、バックアップ領域や差分データを消してもかまわない。また、終了後の始めての起動のときに正常に起動が完了した段階で書き換え中フラグを消去しても構わない。
なお、ステップＳ２１０で正常終了でない場合には、後述するリカバリ処理に処理が進む。

次に、リカバリ処理動作について説明する。
図４は、リカバリ処理の処理手順を示すフローチャートである。リカバリ処理は、書き換え処理中に電池脱などにより電源が切れて書き換え処理が正常に終了されなかった場合に行なわれる処理で、図３のステップＳ２０１で設定されフラッシュＲＯＭ装置２に記憶された書き換え中フラグをリカバリ要否判定手段８が確認することにより、リカバリ処理の必要性を判定することができる。

まず、リカバリ手段９がステップＳ３０１でリカバリフラグを探索する。リカバリフラグは、リカバリ処理が中断したことを示すフラグであり、図３のステップＳ２０５で設定されるものである。リカバリフラグが設定されリカバリが必要とされている部分は、既にフラッシュＲＯＭ装置２は書き換えられ元にもどすための逆差分情報も作成されており、この逆差分情報を使って元にもどすのか、または逆差分情報は作成されていないが、旧版の元のデータはバックアップ領域に存在するのでこの旧版の元のデータを使ってフラッシュＲＯＭ装置２の状態をソフトウエアの修正前の元の状態に戻すかのいずれかを行なう。

ステップＳ３０２でリカバリフラグが全くない場合は、リカバリ処理は必要ない状態であることを示すので、処理は終了する。このような場合は、図３におけるステップＳ２０１から２０５の最初のシーケンス中に電源が切られて書き換えを全く行っていない場合か、リカバリ処理が全て終わった後に書き換え中フラグを消去していないケースでステップＳ３０７からステップＳ３０８の間に電源が切られた場合のどちらかを示すものである。

ステップＳ３０２でリカバリフラグがあった場合は、リカバリ処理が必要であることを示しており、リカバリフラグは書き換えた部分に順番に設定されていくため、順番に見ていくことにより、どの独立領域が最終かを判定することができる。
ステップＳ３０３で、最終の領域であるかどうかを判定し、最終領域であれば、そこまでの領域は既にリカバリ処理済みであるか又は書き換えてないことを示し、その領域以降は修正が不要であることを示し、その領域はバックアップ領域に元にもどすためのデータとしてのコピーがあることを示している。

ステップＳ３０３で最終領域であれば、ステップＳ３０６でバックアップ領域に存在するのでフラッシュＲＯＭ装置２の状態をソフトウエアの修正前の元の状態に戻すために、旧版の元のデータを使って元にもどすコピーをしてフラッシュＲＯＭ装置２に記憶されたソフトウエアの状態を元の状態に戻し、ステップＳ３０７でリカバリフラグを消去し、ステップＳ３０８で書き換え中フラグを消去してリカバリ処理を終える。

ステップＳ３０３で独立部分の最終領域でなければ、リカバリ処理は次の領域でも必要であることを示し、該当領域のバックアップがバックアップ領域にあるわけではないので、ステップＳ３０４で逆差分を適用し、元の状態に戻した上で、該当部分のリカバリフラグを消去して、再度ステップＳ３０１を実行する。

ステップＳ３０４における逆差分は、先に説明したように、旧版と新版とで内容が変わっていないために元の状態のままとする情報と、旧版から一部新版では内容が同じだがアドレスが変わっているために新版から元に戻すためのコピーを旧版に対して行なう情報と、新規のデータによって上書きされたり、コピーによって消去されたデータを元に戻すための旧版にあった元のデータの情報とからなる。これらは差分データとして保存されている情報で、アドレスの始点と終点をあたえる方式で、それぞれの情報を記述しても良いし、またアドレスの始点とサイズの情報を与える方式で記載してもかまわない。

以上のように本実施の形態によれば、携帯電話端末装置のソフトウエアの更新処理が携帯電話端末装置側ででき、又この更新処理が正常に終了しない異常時にも、携帯電話端末装置のソフトウエアを更新前の元の状態に自動的に復帰させることもできる。また、これらの処理は、ソフトエアを更新するサービスがあった場合などには、無線網が使えることにより、事後にサービス側に自動連絡するなどの処置を加えることができ、端末上に異常が発生したことをサービス側で把握することができる。
なお本実施の形態によれば、上述のようにソフトウエアの更新ができることから、携帯電話端末装置が発売され、ユーザが携帯電話を購入した後にソフトウエアの不具合が確認された場合でも、ユーザが店などに携帯電話などを持ち込まなくてもユーザ自身がソフトウエアの更新をすることができ、また、ソフトウエアの書き換え途中で電源が落ちてもソフトウエアの不具合を自動的に修正することができる効果が得られる。

実施の形態１のソフトウエア不具合修正機能付き携帯電話端末装置の構成図。実施の形態１におけるソフトウエアの更新処理手順を示すフローチャート。実施の形態１におけるソフトウエアの書き換え処理の処理手順を示すフローチャート。実施の形態１におけるリカバリ処理の処理手順を示すフローチャート。

符号の説明

１携帯電話端末装置、２フラッシュＲＯＭ装置、３ソフトウエア修正手段、４ＲＡＭ装置、５無線通信手段、６ダウンロード手段、７一時保存手段、８リカバリ要否判定手段、９リカバリ手段。

Claims

携帯電話を作動するソフトウエアが記憶され、又このソフトウエアの修正を行なう修正データが保存された不揮発性メモリと、
サーバからダウンロードされた前記修正データを前記不揮発性メモリに保存する保存手段と、
前記不揮発性メモリに記憶された前記ソフトウエア中の要修正ソフトウエアのブロックが記憶された記憶装置と、
前記ブロックを前記不揮発性メモリに記憶された前記ソフトウエア中から読み込み前記記憶装置に記憶し、又前記記憶装置に記憶された前記ブロック中のソフトウエアを前記修正データに基づいて修正し、この修正ソフトウエアを前記不揮発性メモリに書き込むソフトウエア修正手段と、
前記ソフトウエア修正手段による前記不揮発性メモリへの修正ソフトウエアの書き込みが終了したか否かの判定をするリカバリ要否判定手段と、
前記リカバリ要否判定手段により前記修正ソフトウエアの書き込みが終了したと判定されなかった場合には前記不揮発性メモリに記憶されたソフトウエアを前記修正ソフトウエアの書き込み前の状態に戻すリカバリ処理を実行するリカバリ手段と、を備えたことを特徴とするソフトウエア修正機能付き携帯電話端末装置。
前記ソフトウエア修正手段は、前記修正ソフトウエアを前記不揮発性メモリに書き込み中であることを示す第１のフラグを前記不揮発性メモリに記憶し、
前記リカバリ要否判定手段手段は、起動時に前記不揮発性メモリに記憶された前記第１のフラグの有無により前記不揮発性メモリへの修正ソフトウエアの書き込みが終了したか否かを判定することを特徴とする請求項１記載のソフトウエア修正機能付き携帯電話端末装置。
前記修正データは、前記ブロック中のソフトウエアと前記修正データにより修正したソフトウエアとの差分情報であることを特徴とする請求項１記載のソフトウエア修正機能付き携帯電話端末装置。
前記ソフトウエア修正手段は、前記リカバリ手段によるリカバリ処理が中断したことを示す第２のフラグを前記不揮発性メモリに記憶し、
前記リカバリ要否判定手段手段は、起動時に前記不揮発性メモリに記憶された前記第２のフラグの有無によりリカバリ処理を実行するか否か判断し、
前記リカバリ手段は、前記リカバリ要否判定手段手段の判定結果に基づいてリカバリ処理を実行することを特徴とする請求項１記載のソフトウエア修正機能付き携帯電話端末装置。
前記ソフトウエア修正手段は、前記ブロック中のソフトウエアを前記修正データに基づいて修正した前記修正ソフトウエアの修正部分を逆差分データとして生成し、
前記リカバリ手段は、前記リカバリ処理が中断した時には前記逆差分データに基づいて前記不揮発性メモリに記憶されたソフトウエアを前記修正ソフトウエアの書き込み前の状態に戻すことを特徴とする請求項１記載のソフトウエア修正機能付き携帯電話端末装置。
前記リカバリ手段は、前記記憶装置に記憶された前記ブロックに基づいて前記不揮発性メモリに記憶されたソフトウエアを前記修正ソフトウエアの書き込み前の状態に戻すことを特徴とする請求項１記載のソフトウエア修正機能付き携帯電話端末装置。