(57)【要約】【課題】本発明は、情報更新装置及び方法に関し、特に携帯端末のプログラムを更新することができる装置及び方法に関する。【解決手段】端末システムのシステム情報更新装置は、第１バージョン情報を格納する領域及び少なくとも一つの更新パッケージを格納する格納領域を備える第１メモリと、システム駆動用更新バージョン情報を格納する第２メモリと、更新パッケージから更新パッケージをダウンロードするダウンローダと、ダウンロードされる更新パッケージを第１メモリの設定された領域にインストールするインストーラと、更新要求時、第１メモリから更新パッケージ及び第１バージョン情報をロードし、ロードした第１バージョン情報に更新パッケージを組合せて更新バージョン情報を生成し、第２メモリに格納するトランスレータと、から構成される。【選択図】図１
2009544095.tif 000002
【特許請求の範囲】
【請求項１】
プログラムによって動作する携帯端末のプログラム更新装置において、
前記プログラムの基準バージョンと少なくとも一つの更新パッケージとを格納する第１メモリと、
前記プログラムの更新バージョンをロードする第２メモリと、
前記携帯端末が外部システムと通信することを可能にする通信部と、
前記通信部を制御して前記外部システムからの更新通知メッセージに応答して前記更新パッケージをダウンロードし、前記更新パッケージを前記第１メモリにインストールし、前記更新パッケージを前記プログラムの前記基準バージョンに結合して前記プログラムの更新バージョンを生成し、前記プログラムの前記更新バージョンを用いて前記携帯端末を動作させる制御部と、
を含むことを特徴とする携帯端末のプログラム更新装置。
【請求項２】
前記更新パッケージは、
前記プログラムの前記基準バージョンと前記更新バージョンとの差に基づいて生成される更新データと、
前記更新データを前記プログラムの前記基準バージョンに結合するための情報を提供するインストールデータと、
を含むことを特徴とする請求項１に記載のプログラム更新装置。
【請求項３】
前記インストールデータは、
前記プログラムの前記更新パッケージ及び前記基準バージョンによって表される前記更新バージョンのバージョン識別情報を含むヒストリーデータと、
前記更新データを前記プログラムの前記基準バージョンにマッピングするマップデータと、
を含むことを特徴とする請求項２に記載のプログラム更新装置。
【請求項４】
前記プログラムの前記基準バージョンは、少なくとも二つのデータブロックを含み、かつ、
前記マップデータは、コマンドと、該コマンドに従って処理されるブロックインデックスと、を含むことを特徴とする請求項３に記載のプログラム更新装置。
【請求項５】
前記コマンドは、コピーコマンド、シフトコメンド及び変更コメンドを含み、かつ、
前記インデックスによって示される前記ブロックは、前記更新データであることを特徴とする請求項４に記載のプログラム更新装置。
【請求項６】
前記第１メモリは、
前記プログラムの前記基準バージョンを格納する第１領域と、
前記少なくとも一つの更新パッケージを格納する第２領域と、
を含むことを特徴とする請求項１に記載のプログラム更新装置。
【請求項７】
前記更新パッケージは、
前記プログラムの前記基準バージョンと前記更新バージョンとの差に基づいて生成される更新データと、
前記更新データを前記基準バージョンに結合するための情報を提供するインストールデータと、
を含むことを特徴とする請求項６に記載のプログラム更新装置。
【請求項８】
前記インストールデータは、
前記プログラムの前記更新パッケージ及び前記基準バージョンによって表される前記更新バージョンのバージョン識別情報を含むヒストリーデータと、
前記更新データを前記プログラムの前記基準バージョンにマッピングするマップデータと、
を含むことを特徴とする請求項７に記載のプログラム更新装置。
【請求項９】
前記制御部は、
前記外部システムの通知があった時に前記更新パッケージをダウンロードし、前記更新パッケージを前記第１メモリの前記第２領域にインストールし、前記第１メモリから前記基準バージョンと前記更新パッケージとをロードし、前記基準バージョンと前記更新パッケージとを結合して前記更新バージョンを生成し、前記プログラムの前記更新バージョンを前記第２メモリにロードし、前記プログラムの前記更新バージョンを用いて前記携帯端末を動作させることを特徴とする請求項８に記載のプログラム更新装置。
【請求項１０】
前記制御部は、
前記更新パッケージが前記マップデータを有しているか否かを検査して、前記更新パッケージがマップデータを有していないと判断された場合、前記基準バージョンと前記更新データとを比較して前記マップデータを生成し、前記ヒストリーデータ、マップデータ及び更新データを前記第１メモリの前記第２領域内にインストールすることを特徴とする請求項９に記載のプログラム更新装置。
【請求項１１】
前記プログラムの前記基準バージョンは、製造時にインストールされるシステムのファームウェア、又はソフトウェアであることを特徴とする請求項１０に記載のプログラム更新装置。
【請求項１２】
プログラムによって動作する携帯端末のプログラム更新方法において、
外部システムから前記プログラムの更新パッケージをダウンロードするステップと、
前記更新パッケージを第１メモリにインストールするステップと、
更新要請に応答して前記プログラムの基準バージョンと前記更新パッケージとをロードするステップと、
前記プログラムの前記基準バージョンを前記更新パッケージに結合して前記プログラムの更新バージョンを生成するステップと、
前記プログラムの前記更新バージョンを第２メモリにロードするステップと、
前記プログラムの前記更新バージョンを用いて前記携帯端末を動作させるステップと、
を含むことを特徴とする携帯端末のプログラム更新方法。
【請求項１３】
前記プログラムの前記基準バージョンは、前記第１メモリの第１領域に格納され、
前記更新パッケージは、前記第１メモリの第２領域に格納され、
前記第２領域は、複数の格納領域からなることを特徴とする請求項１２に記載のプログラム更新方法。
【請求項１４】
前記更新パッケージは、
前記プログラムの前記基準バージョンと前記更新バージョンとの差に基づいて生成される更新データと、
前記プログラムの前記更新パッケージと前記基準バージョンとによって表される前記更新バージョンのバージョン識別情報を含むヒストリーデータと、
前記更新データを前記プログラムの前記基準バージョンにマッピングするマップデータと、
を含むことを特徴とする請求項１３に記載のプログラム更新方法。
【請求項１５】
前記マップデータは、コピーコマンドと、シフトコマンドと、変更コマンドと、該コマンドに従って処理されるブロックのインデックスとを含み、
前記インデックスによって示される前記ブロックは、前記更新データであることを特徴とする請求項１４に記載のプログラム更新方法。
【請求項１６】
前記更新パッケージをインストールするステップは、
前記更新パッケージから前記ヒストリーデータ、前記マップデータ及び前記更新データを抽出するステップと、
前記ヒストリーデータ、前記マップデータ及び前記更新データを前記第１メモリの前記第２領域の各々の格納部分内にインストールするステップと、
を含むことを特徴とする請求項１４に記載のプログラム更新方法。
【請求項１７】
前記更新パッケージをインストールするステップは、
前記更新パッケージから前記ヒストリーデータ、前記マップデータ及び前記更新データを生成するステップと、
前記ヒストリーデータ、前記マップデータ及び前記更新データを前記第１メモリの前記第２領域の各々の格納部分内にインストールするステップと、
を含むことを特徴とする請求項１４に記載のプログラム更新方法。
【請求項１８】
前記更新パッケージをインストールするステップは、
前記ヒストリーデータを前記第１メモリの前記第２領域にインストールするステップと、
前記マップデータが前記更新パッケージに含まれているか否かを検査するステップと、
前記更新パッケージがマップデータを有していると判断された場合、前記マップデータを前記第１メモリの前記第２領域内にインストールするステップと、
前記更新パッケージがマップデータを有していないと判断された場合、前記更新データに提供されたマップ情報に基づいてマップデータを生成し、該マップデータを前記第１メモリの前記第２領域内にインストールするステップと、
前記更新データを前記第１メモリの前記第２領域内にインストールするステップと、
を含むことを特徴とする請求項１４に記載のプログラム更新方法。
【請求項１９】
前記更新バージョンを生成するステップは、
前記第１メモリの第２領域にインストールされた前記更新パッケージをロードするステップと、
前記更新パッケージの前記更新データを前記プログラムの前記基準バージョンに結合するステップと、
を含むことを特徴とする請求項１３に記載のプログラム更新方法。
【請求項２０】
前記更新パッケージは、前記プログラムの最新バージョンのパッケージであることを特徴とする請求項１９に記載のプログラム更新方法。
【請求項２１】
前記第１メモリは、不揮発性メモリであり、かつ、
前記第２メモリは、揮発性メモリであることを特徴とする請求項２０に記載のプログラム更新方法。
【請求項２２】
前記更新要請は、システム初期化の実行により発生することを特徴とする請求項２１に記載のプログラム更新方法。
【請求項２３】
前記更新要請は、前記更新パッケージのインストールの終了後に、ユーザーインプットによって生成されることを特徴とする請求項２１に記載のプログラム更新方法。
【請求項２４】
前記プログラムの前記更新バージョンを生成するステップは、
ヒストリーデータに基づいて更新される前記プログラムの前記基準バージョンを検査するステップと、
前記更新パッケージの前記更新データを前記更新パッケージのマップデータに基づく前記プログラムの前記基準バージョンにマッピングして、前記プログラムの前記更新バージョンを生成するステップと、
を含むことを特徴とする請求項２１に記載のプログラム更新方法。
【請求項２５】
プログラムによって動作する携帯端末のプログラム更新装置において、
前記プログラムの基準バージョンを格納する第１領域と、少なくとも一つの更新パッケージを格納する少なくとも一つの第２領域とを備える第１メモリと、
前記プログラムの更新バージョンを格納する第２メモリと、
外部システムから前記更新パッケージをダウンロードするダウンローダーと、
前記ダウンローダーによってダウンロードされた前記更新パッケージを、前記第１メモリの第２領域内にインストールするインストーラと、
前記第１メモリから前記更新パッケージ及び前記プログラムの前記基準バージョンをロードし、前記更新パッケージを前記プログラムの前記基準バージョンに結合して前記プログラムの前記更新バージョンを生成し、前記プログラムの前記更新バージョンを前記第２メモリに格納するトランスレータと、
を含むことを特徴とする携帯端末のプログラム更新装置。
【請求項２６】
前記第１メモリは、不揮発性メモリであり、かつ、
前記第２メモリは、揮発性メモリであることを特徴とする請求項２５に記載のプログラム更新装置。
【請求項２７】
前記更新パッケージは、前記プログラムの前記基準バージョンと前記更新バージョンとの差に基づいて生成される更新データと、前記更新データを前記プログラムの前記基準バージョンに結合するための情報を提供するインストールデータと、を含み、
前記インストーラは、前記更新パッケージからヒストリーデータ、マップデータ及び更新データを抽出して、前記第１メモリの前記第２領域にインストールすることを特徴とする請求項２６に記載のプログラム更新装置。
【請求項２８】
前記更新パッケージは、前記プログラムの前記基準バージョンと前記更新バージョンとの差に基づいて生成される更新データと、前記更新データを前記プログラムの前記基準バージョンに結合するための情報を提供するインストールデータと、を含み、
前記インストーラは、前記更新パッケージから抽出されたヒストリーデータを前記第１メモリの前記第２領域にインストールし、前記更新データを該更新データからの前記基準バージョンにマッピングするマップデータを生成し、前記マップデータを前記第１メモリの第２領域にインストールし、前記更新データを前記第１メモリの前記第２領域内にインストールすることを特徴とする請求項２６に記載のプログラム更新装置。
【請求項２９】
前記トランスレータは、前記更新データを前記マップデータに基づく前記プログラムの前記基準バージョンに結合して前記プログラムの前記更新バージョンを生成し、前記更新バージョンを前記第２メモリに格納することを特徴とする請求項２７に記載のプログラム更新方法。
【請求項３０】
前記更新要請は、システム初期化の実行により発生することを特徴とする請求項２９に記載のプログラム更新方法。
【請求項３１】
携帯端末のプログラム更新装置において、
基準バージョンと少なくとも一つのシステムプログラムの更新パッケージとを格納する領域を備える第１メモリと、
前記システムプログラムの更新バージョンを格納する第２メモリと、
前記携帯端末が外部システムと通信することを可能にする通信部と、
前記通信部を制御して前記外部システムからの前記更新パッケージをダウンロードし、前記第１メモリを制御して前記ダウンロードされた更新パッケージを格納し、前記更新パッケージを前記基準バージョンに結合して前記システムプログラムの更新バージョンを生成し、インストールコマンドに応答して前記更新バージョンを前記第２メモリに格納し、前記プログラムの前記更新バージョンを用いて前記携帯端末を動作させる制御部と、
を含むことを特徴とするプログラム更新装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システム更新方法に関し、特に、Ｏｖｅｒ−Ｔｈｅ−Ａｉｒ（ＯＴＡ）プログラムメカニズムを用いた携帯端末のプログラム更新装置及び方法に関する。
【背景技術】
【０００２】
携帯端末やＰＤＡなどの電子端末は、製造会社や通信業者又は第三者によって提供されるファームウェアやアプリケーションソフトウェアを含む。このようなファームウェア及びアプリケーションソフトウェアは、ソフトウェアのバグを含むことがあり、時々更新が必要である。ファームウェア及びアプリケーションのバグを修正し、更新するためには、ユーザは製造会社のサービスセンターやサービスキャリアを訪問する。ＯＴＡが可能な端末のファームウェア及びソフトウェアの更新はＯＴＡメカニズムによって行うことができる。この時、更新は無線で端末に行われる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ＯＴＡを使用するために、電子端末は、更新パッケージをダウンロードするためのダウンロードモジュールと、ダウンロードされた更新パッケージと、ターゲットファームウェア及びソフトウェアの更新を行うための更新プロセシングモジュールとを必要とする。しかし、ほとんどの従来のＯＴＡが可能な端末はＯＴＡ機能の実行において安定的でない。
【課題を解決するための手段】
【０００４】
本発明は、前記問題を解決するために考案されたものであり、本発明は、プログラムの基準バージョンと無線で伝達された更新パッケージとを結合して、ＯＴＡが可能な端末のプログラムを更新する装置及び方法を提供する。
【０００５】
また、本発明は、第１メモリーに無線で伝達された更新パッケージを格納し、前記更新パッケージとプログラム基準バージョンとを結合してプログラムを更新し、前記移動端末を作動させるために前記更新パッケージを第２メモリーにロードするＯＴＡが可能な端末のプログラムを更新する装置及び方法を提供する。
【発明の効果】
【０００６】
上記のように、システムの更新バージョンを生成する時に基準バージョンと更新バージョンとの差異に基づく更新パッケージを生成し、これによって更新バージョンのプログラムを速かに生成することができる。また、前記更新バージョンをダウンロードする時、携帯端末は、第１メモリに前記基準バージョン及び更新バージョンを独立的にインストールして保管し、前記保管された基準バージョン及び更新バージョンを第２メモリで組合せて更新することにより、安定してプログラムを更新できるという利点がある。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施形態により更新パッケージを生成して伝送し、伝送される更新パッケージをダウンロードして、システムプログラムの更新動作を行うシステムの構成を示す図面。
【図２】本発明の実施形態に係る更新パッケージ処理器の構成例を示す図面。
【図３】本発明の実施形態に係る更新パッケージ処理器の他の構成例を示す図面。
【図４】更新パッケージ処理器で更新パッケージを生成する方法を説明するための図面。
【図５】更新パッケージ処理器で更新パッケージを生成する方法を説明するための図面。
【図６】更新パッケージ処理器で更新パッケージを生成する方法を説明するための図面。
【図７】更新パッケージ処理器で更新パッケージを生成する方法を説明するための図面。
【図８】更新パッケージ処理器で更新パッケージを生成する方法を説明するための図面。
【図９】更新パッケージ処理器で更新パッケージを生成する方法を説明するための図面。
【図１０】図２のような更新パッケージ処理器で発生される更新パッケージの構成を示す図面。
【図１１】図３のような更新パッケージ処理器で発生される更新パッケージの構成を示す図面。
【図１２】本発明の実施形態により更新パッケージをダウンロードし、システムプログラムのバージョンを更新する端末システムの構成を示す図面。
【図１３】本発明の実施形態に係る端末システムの第１メモリの構造を示す図面。
【図１４】第１メモリの第２格納領域に格納される更新パッケージの構造を示す図面。
【図１５】図１４のような更新パッケージにおけるヒストリーデータの構造を示す図面。
【図１６】第１メモリ及び第２メモリの構造を示す図面。
【図１７】第２バージョンの更新パッケージが第１メモリに格納されなかった場合の動作を説明するための図面。
【図１８】第２バージョンの更新パッケージが第１メモリに格納された場合の動作を説明するための図面。
【図１９】第２バージョンの更新パッケージが第１メモリに格納された場合の動作を説明するための図面。
【図２０】端末システムにおけるプログラムを更新する方法を説明するための図面。
【図２１】本発明の実施形態に係る更新パッケージ生成及び更新ステップを説明するフロー図。
【図２２】本発明の実施形態に係る端末システムが更新パッケージをダウンロードしてインストールするステップ、及びインストールされた更新パッケージを更新して運用するステップ等を示すフロー図。
【図２３】本発明の実施形態に係る端末システムからダウンロードされる更新パッケージを第１メモリにインストールするステップを示すフロー図。
【図２４】本発明の実施形態に係る端末システムにおいて、第１メモリにインストールされた更新パッケージを第１バージョンのプログラムに結合し、更新されるプログラムを第２メモリに格納した後、システムを運用するステップを示すフロー図。
【図２５】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図２６】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図２７】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図２８】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図２９】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図３０】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図３１】本発明の実施形態に係る端末システムが更新パッケージをダウンロードして、インストール及びトランスレートする処理ステップを示すフロー図。
【図３２】本発明の実施形態に係る更新パッケージをダウンロードし、インストール及びトランスレートする携帯端末の構成例を示す図面。
【発明を実施するための形態】
【０００８】
以下、本発明の好ましい実施形態を詳細に説明するために、図面を参照しながら説明する。図面中、同一構成には、なるべく同一の符号で表している。下記の説明において、よく知られている機能及び構造の説明は、本発明の要旨を逸脱しない範囲内で省略する。
【０００９】
本発明の実施形態において、「更新（ｕｐｇｒａｄｅ)」とは、システムのプログラム（ｆｉｒｍｗａｒｅ及びｓｏｆｔｗａｒｅ等）を、更新パッケージを用いて新しいシステムプログラムに生成することを意味する。「更新パッケージ」とは、基準プログラムと更新プログラム間の差異に基づいて生成され、更新プログラムの生成時、これを基準プログラムに結合して更新プログラムを生成することができるデータのパッケージを意味する。更新パッケージは、更新データ及び／又はインストールデータから構成され、インストールデータは、ヒストリーデータ及びマップデータから構成される。「更新データ（ｕｐｇｒａｄｅ ｄａｔａ）」とは、情報更新時、以前のバージョンのデータに代わって変更するためのデータを意味する。「インストールデータ」とは、情報更新時、以前のバージョンを更新バージョンに変更する時のインストール情報を意味し、インストールデータは、ヒストリー情報及びマップ（ｍａｐ）データから構成される。「マップデータ」は、ブロックアドレス（ｍａｃｒｏ−ｂｌｏｃｋ ａｄｄｒｅｓｓ）及び当該ブロックで実行するコマンドから構成される。ここで、コマンドは、コピー（Ｃ：ｃｏｐｙ）、シフト（Ｓ：ｓｈｉｆｔ）及び変更（Ｍ：ｍｏｄｉｆｙ）等であり、ブロックアドレスは、対応する基準バージョンプログラムのブロックインデックスである。「第１バージョン」は、システムの最初バージョンプログラム又はシステムの基準になるバージョンプログラムにすることができる。「第２バージョン」は、更新バージョンであり、第１バージョンプログラムを更新したプログラムである。ここで、受信側の装置は、装置製造時、第１バージョンプログラムがインストールされてあり、更新プログラムが発生される時点で、第２バージョンの更新パッケージをダウンロードして格納することができ、また、一つ又はそれ以上の第２バージョンを格納することがある。
【００１０】
「第１メモリ」とは、第１バージョン及び第２バージョンの更新パッケージを格納するメモリを意味する。「第２メモリ」とは、第１バージョンに第２バージョンの更新パッケージを結合して、更新されたプログラムを格納するメモリを意味する。ここで、第１メモリ及び第２メモリは、第１領域及び第２領域に区分される一つのメモリにするか、又は、別々の２つのメモリにすることもできる。本発明の実施形態では、第１及び第２メモリが別々の２つのメモリであると仮定し、ここで、各々「第１メモリ」は、不揮発性メモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）のフラッシュメモリであり、「第２メモリ」は、揮発性メモリ（ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）のＳＤＲＡＭであると仮定する。本発明の実施形態において、第１メモリは、第１バージョンと少なくとも一つの第２バージョンの更新パッケージを格納し、第２バージョンの更新パッケージは、各バージョンを識別するためのヒストリーデータ（そしてマップデータを含むこともある）及び更新データを各々格納する。そして、システム起動時又はユーザの命令によって、システムは、第１バージョンに第２バージョンの更新パッケージを結合して、更新されたバージョンのプログラムを第２メモリに格納した後、更新されたバージョンでシステムを運用する。更新パッケージはインストールデータ及び更新データから構成され、インストールデータはヒストリーデータ及び／又はマップデータから構成される。そして、第１バージョンはシステムの最初プログラム（又は基準プログラム）にすることができ、第２バージョンの更新パッケージは第１バージョンとの差異を有する更新データ、及びこれをインストールするためのインストールデータにすることができる。従って、第２メモリに格納されるプログラムは、第１バージョンに第２バージョンの更新パッケージを結合して生成されたプログラムである。
【００１１】
本発明の実施形態に係るプログラム更新システムは、更新パッケージを生成して伝送する伝送システム、及び更新パッケージを受信してシステムプログラムを更新する受信システム等から構成される。以下、説明する本発明の実施形態においては、受信システムが携帯端末であると仮定して説明する。ここで、携帯端末は、上記のように、携帯電話（ｍｏｂｉｌｅ ｐｈｏｎｅ）、デジタルカメラ、ノートブックパソコン、ＰＮＰ等のマルチメディア機能が実行可能な端末を意味する。
【００１２】
図１を参照すると、プログラム更新システムは、更新パッケージ処理器１０、更新パッケージサーバ２０、通知サーバ２５、及び携帯端末３０から構成される。
【００１３】
更新パッケージ処理器１０は、第２バージョンの発生時、第１バージョンと比較してその差による更新パッケージを生成した後、これを更新サーバ２０に伝送する。この時、更新パッケージ処理器１０は、更新サーバ２０との接続方法によって、無線（ａｉｒ ｐｒｏｔｏｃｏｌｓ：ＣＤＭＡ、ＵＭＴＳ等）、近距離通信（ｂｌｕｅｔｏｏｔｈ、Ｚｉｇｂｅｅ等）、近距離有線通信（ＵＳＢ、ＵＡＲＴ）、有無線インターネット（Ｗｉｂｒｏ、Ｗｉｆｉ、Ｗｉｍａｘ等）方式で伝達される。更新サーバ２０がこれを通知サーバ２５に伝達すると通知サーバ２５は更新パッケージが発生されたことを複数の携帯端末３０に通知（ｎｏｔｉｆｉｃａｔｉｏn）する。この時、更新パッケージの発生の通知を受けた携帯端末３０が応答すると、更新サーバ２０は応答した携帯端末３０に更新パッケージをダウンロードする。この時、受信システムの更新パッケージのダウンロード方法は、上記のように、更新サーバ２０及び携帯端末３０の接続方法によって、無線（ａｉｒ ｐｒｏｔｏｃｏｌｓ：ＣＤＭＡ、ＵＭＴＳ等）、近距離無線通信（ｂｌｕｅｔｏｏｔｈ、Ｚｉｇｂｅｅ等）、近距離有線通信（ＵＳＢ、ＵＡＲＴ）、有無線インターネット（Ｗｉｂｒｏ、Ｗｉｆｉ、Ｗｉｍａｘ等）方式を用いることができる。
【００１４】
携帯端末３０は、ダウンロードした更新パッケージを第２バージョンの更新パッケージとしてメモリに格納する。この時、携帯端末３０のメモリは、第１メモリ及び第２メモリを備える。ここで、第１メモリ及び第２メモリは、一つのメモリ上に領域を割り当てて区分されたメモリにするか、また、別々のメモリにすることができる。ここで、第１メモリは、ダウンロードされた更新パッケージをインストールし格納するメモリであり、第２メモリは、第１バージョンプログラムを更新パッケージによって更新して生成された、第２バージョンプログラムを格納するメモリである。携帯端末３０は、ダウンロードされる更新パッケージを第１メモリに第２バージョンの更新パッケージとして格納する。その後、更新要求時、携帯端末は、第１バージョンのプログラムにダウンロードされた第２バージョンの更新パッケージを結合（ｍｅｒｇｅ）して生成された第２バージョンプログラムを、第２メモリに格納し、その後、携帯端末３０は、第２メモリに格納された更新済みバージョンのプログラムによりシステムを運用する。
【００１５】
まず、更新パッケージ処理器１０の動作を説明する。
【００１６】
以下、説明において、更新パッケージ処理器は、プログラムの第１及び第２バージョンを圧縮し、圧縮された二つのバージョンを比較分析してマップデータ及び更新データを生成し、マップデータを含むインストールデータ及び更新データを合成して更新パッケージを生成する。
【００１７】
図３の例では、更新パッケージ処理器が、第１及び第２バージョンを圧縮し、圧縮された二つのバージョンを比較分析して更新データを生成し、マップデータを含まないインストールデータ及び更新データを合成して更新パッケージを生成する。
【００１８】
図２−図１１を参照すると、第１バージョン発生器５０はプログラムの第１バージョンを生成し、第２バージョン発生器５５はプログラムの第２バージョンを生成する。ここで、第１バージョンは、受信システム３０の最初プログラムであり、また、受信システム３０の基準になるプログラムである。そして、第１バージョンのプログラムは、受信システム３０の第１メモリにインストールされたプログラムである。第２バージョンプログラムは、第１バージョンプログラムの更新されたプログラムであり、受信システム３０にダウンロードするためのプログラムである。第１圧縮器１６０は、第１バージョンを設定されたサイズ（以下、マクロブロック（ｍａｃｒｏ ｂｌｏｃｋ）という）で分割して圧縮し、また、第２バージョンもマクロブロック単位で分割して圧縮する。第１圧縮器１６０が設定されたブロックサイズに圧縮する理由は、後段の比較器１１０が二つのバージョンをブロック単位で比較できるようにするためである。すると、比較器１１０は、圧縮された二つのバージョンのプログラムのブロックデータを比較し、同一であるか否かを表示する。この時、二つのバージョンの対応するブロックデータが同一でなければ、比較器１１０は、第１バージョン及び第２バージョンのブロックデータを設定された探索範囲内の第１バージョンブロックデータと比較する。上記のように、二つのバージョンのブロックデータを比較した後、比較器１１０は、比較結果値、及び対応する第１バージョンのブロックインデックス値をインストールデータ発生器１８０に伝達する。
【００１９】
すなわち、比較器１１０は、現在の第２バージョンブロックのデータを第１バージョンの対応するインデックスのブロックデータと比較し、同一であれば、比較結果値と共に当該ブロックのインデックスをインストールデータ発生器１８０に伝達する。しかし、第２バージョンのブロックデータと第１バージョンのブロックデータとが異れば、比較器１１０は、第１バージョンの設定区間内のブロックデータと比較しながら、同一のブロックデータがあるかを検査する。この時、同一のブロックデータがあれば、比較結果値と共に第１バージョンのブロックインデックスをインストールデータ発生器１８０に伝達する。すなわち、比較器１１０は、探索範囲のブロック数分、現在のブロックインデックスの位置で前後にスイングしながら比較する。この時、第２バージョンのブロックデータを第１ブロックの設定された探索範囲内のブロックデータと比較した結果、同一のブロックデータがない場合には、現在の第２バージョンのブロックインデックス、及びこれによる比較結果値をインストールデータ発生器１８０に伝達する。
【００２０】
インストールデータ発生器１８０は、図２に示すように、ヒストリーデータ発生器１２０及びマップデータ発生器１５０から構成され、また、図３に示すように、ヒストリーデータ発生器１２０のみから構成されることもある。ここで、ヒストリーデータ発生器１２０は第２バージョンの番号（ｖｅｒｓｉｏｎ ｎｕｍｂｅｒ）を有する。すなわち、バージョン番号が５の場合、第２バージョンはバージョン番号５となり、第１バージョン及びバージョン番号５の第２バージョンを結合して更新するという意味である。マップデータ発生器１５０は、比較器１１０の出力を分析し、更新パッケージをインストールするためのコマンド（ｉｎｓｔｒｕｃｔｉｏｎ）及びブロックインデックスを決定するマップデータを生成する。
【００２１】
図４−図８は、更新パッケージ処理器１０におけるマップデータを含む更新パッケージを生成する方法を説明するための図である。本発明の実施形態に係る更新パッケージは更新データ、ヒストリーデータ及びマップデータから構成される更新パッケージを生成することができ、また、本発明の実施形態では、第１バージョンのプログラムを用いて第２バージョンのプログラムを更新する場合、更新ステップでのシフト動作を減らすために、第１バージョンのプログラムにギャップ領域を割り当てることができる。
【００２２】
図４−図８を参照し、本発明の実施形態に係るマップデータを含む更新パッケージの生成方法を検討する。本発明の実施形態において、更新パッケージ処理器１０は、第１バージョンプログラム（以下、第１バージョン又はＶ１という）及び第２バージョンプログラム（以下、第２バージョン又はＶ２という）のデータを設定サイズのブロック（以下、マクロブロック（ｍａｃｒｏ ｂｌｏｃｋ：ＭＢ）という）として比較し、比較結果により各ブロックの属性（コピー（Ｃ：ｃｏｐｙ）、変更（Ｍ：ｍｏｄｉｆｙ））、シフト（Ｓ：ｓｈｉｆｔ））を判別し、ブロックデータの属性によって更新パッケージを生成する。更新パッケージ処理器１０がマップデータを含む更新パッケージを生成する場合、マップデータは、Ｃ（コピー）、Ｍ（変更；挿入又は同じサイズの挿入）、Ｓ（シフト）のコマンドを有し、マップデータ形態（ｍａｐ ｆｏｒｍａｔ）は下記のように構成される。
【００２３】
[Ｃｍｄ]［ｓｔａｒｔ ｂｌｏｃｋ Ｎｏ、ｎｕｍｂｅｒ ｏｆ ｂｌｏｃｋ］［ｆｌａｇ］［ｄｉｓｔａｎｃｅ］［ｄｉｆｆｅｒｅｎｃｅ］
マップデータにおいて、Ｃｍｄは、Ｃ、Ｍ、Ｓ中の一つである。そして、ｓｔａｒｔ ｂｌｏｃｋ Ｎｏは当該コマンドの開始ブロック番号を意味し、ｎｕｍｂｅｒ ｏｆ ｂｌｏｃｋは当該コマンドに対応するブロックの数を意味する。そして、フラグ（ｆｌａｇ）は０、１、２から構成され、ｆｌａｇ ０はコピー（ｊｕｓｔ ｃｏｐｙ （Ｃｍｄ：Ｃ））及びシフト（ｊｕｓｔ ｓｈｉｆｔ（Ｃｍｄ：Ｓ））の場合に使用されるフラグであり、ｆｌａｇ １はＶ１プログラムでブロックデータを生成することができる場合（ｇｅｎｅｒａｔｅ ＤＡＴＡ ｆｒｏｍ Ｖ１（Ｃｍｄ：Ｍ）)に使用されるフラグであり、ｆｌａｇ ２はＶ１プログラムでブロックデータを生成することはできず、ブロックデータがデルタパッケージ（ｄｅｌｔａ ｐａｃｋａｇｅ）になる場合（ｄａｔａ ｉｓ ｉｎ ｄｅｌｔａ ｐａｃｋａｇｅ（ｎｏｔ ｕｓｅ Ｖ１）（Ｃｍｄ：Ｍ））に用いられるフラグである。ｄｉｓｔａｎｃｅとは、Ｖ２プログラムの当該ブロックが位置するＶ１プログラムのブロックインデックス情報を意味する。ｄｉｆｆｅｒｅｎｃｅとは、Ｖ２プログラムのブロックデータとＶ１プログラムのブロックデータとの差異値を意味する。
【００２４】
本発明の実施形態において、更新パッケージ処理器１０は、Ｖ１ブロック及びＶ２ブロックのデータが互いに異なると、変更ブロックデータを生成する。この時、Ｖ２の変更ブロックデータが確認されると、更新パッケージ処理器１０は、Ｖ１の探索範囲のブロックを探索（ｓｅａｒｃｈｉｎｇ）し、Ｖ２変更ブロックデータと同一のデータがあるかを確認する。図４−図６は、探索範囲がＶ２プログラムの当該ブロックと対応するＶ１プログラムのブロック位置から前後１５個のブロックデータが設定された探索範囲内に含まれる例を示している。すなわち、Ｖ２プログラムで変更ブロックデータを確認すると、更新パッケージ処理器１０は、Ｖ１プログラムの対応するブロック位置から探索範囲内のブロックデータを探索し、同一のブロックデータがあるかを確認するということである。この時、Ｖ１プログラムの探索範囲内に同一のブロックデータがあれば、更新パッケージ処理器１０は更新データを生成せず、対応するＶ１プログラムのブロックインデックスをマップデータに含めて更新パッケージを生成する。
【００２５】
図４は、更新パッケージ処理器１０が、Ｖ２プログラムの変更ブロックデータを探索範囲内で探すことができる場合の、更新パッケージ生成例を説明するための図である。
【００２６】
図４を参照すると、更新パッケージ処理器１０はＶ１及びＶ２プログラムをマクロブロック単位で比較する。比較ステップにおいて、Ｖ２プログラムの変更されたマクロブロックデータをＶ１プログラムの探索範囲内で探すことができる場合、更新パッケージ処理器１０は、変更ブロックデータを更新データとして生成せずに、マップデータにＶ１の対応するブロックインデックス情報を含める。すなわち、更新パッケージ処理器１０は、Ｖ２プログラムの変更ブロックデータと同一のブロックデータを有するＶ１プログラムのブロックインデックスを探した後、これをマップデータに表示する。
【００２７】
図４は、Ｖ２プログラムのブロック１６−１９が変更され、ブロック２０−２４がシフトされる例を示している。この場合、更新パッケージ処理器１０はＶ１プログラムの探索範囲内で、Ｖ２プログラムのブロック１６−１９のデータと同一の値を有するＶ１ブロック１２、１３、８、９のデータを確認することができる。すなわち、更新パッケージ処理器１０は、Ｖ２プログラムのブロック１６−１７はＶ１プログラムのブロック１２−１３と同一であり、Ｖ２プログラムのブロック１８−１９はＶ１プログラムのブロック８−９と同一であることを確認する。図４のように、Ｖ１及びＶ２プログラムを用いて更新パッケージを生成する場合、更新パッケージ処理器１０は、下記表１のようなマップデータを生成する。
【００２８】
【表１】
2009544095.tif 000003
表１のマップデータは、Ｖ２ブロック０−１５はＶ１ブロック０−１５と同一であり、Ｖ２ブロック１６−１９は各々Ｖ１ブロック１２、１３、８、９と同一であり、Ｖ２ブロック２０−２４はＶ１ブロック１６−２０と同一であることを意味する。従って、図４のようにＶ１及びＶ２プログラムを用いて更新パッケージを生成する場合、更新パッケージ処理器１０は探索範囲内でＶ２の変更ブロックを探すことができる場合は、当該変更ブロックデータをＶ１の対応するブロックインデックスをマッピングして、マップデータを生成する。この場合、更新パッケージ処理器１０は、ヒストリーデータ及び表１のようなマップデータを結合して更新パッケージとして生成する。
【００２９】
図５は，更新パッケージ処理器１０が、Ｖ２プログラムの変更ブロックデータをＶ１プログラムの探索範囲内で類似のブロックデータを見つけることができる場合に、更新パッケージを生成する方法を説明するための図である。図５は，Ｖ２プログラムのブロック１６−１９が変更され、ブロック２０−２４がシフトされる例を示している。表１において、「Ｓ：２０，５，Ｆ：０，（２０−４），０」は、Ｖ２のブロック２０を含む５個のブロック（２０−２４）は、Ｖ１のブロック２０からブロック４個前のブロック（２０−４＝１６）を含む５個のブロック（１６−２０）と同一であることを意味する。また、表１において、［Ｓ：２０，５，Ｆ：０，（２０−４），０］は、Ｖ２のブロック２０がＶ１のブロック１６と同一であり、Ｖ２のブロック２０を含む５個のブロック（２０−２４）はＶ１のブロック（１６−２０）と同一であることを意味する。以下、説明する本発明の実施形態において、シフトブロックは［Ｓ：２０，５，Ｆ：０，（２０−４），０］で表すことにする。
【００３０】
図５を参照すると、更新パッケージ処理器１０は、Ｖ２プログラムのブロック１６はＶ１プログラムの探索範囲内にあるブロック１２と同一であるが、V2プログラムのブロック１７はＶ１プログラムの設定された探索範囲内で一致するブロックを探すことができず、Ｖ２プログラムのブロック１８はＶ１プログラムの設定された探索範囲内で一致するブロックを探すことができないが、ブロック１９はＶ１プログラムの探索範囲内にあるブロック６と同一であることが分かる。この場合、更新パッケージ処理器１０は、変更ブロック１６及び１７を探索範囲内のＶ１のブロック１２及び１３と類似するブロックと決定し、変更ブロック１８及び１９を探索範囲内のＶ１のブロック６及び７と類似するブロックと決定する。従って、図３ｂのように、Ｖ１及びＶ２プログラムを用いて更新パッケージを生成する場合、更新パッケージ処理器１０は下記の表２のようなマップデータを生成することができる。
【００３１】
【表２】
2009544095.tif 000004
表２のマップデータは、Ｖ２のブロック０−１５はＶ１のブロック０−１５と同一であり、Ｖ２のブロック２０−２５はＶ１のブロック１６−２０と同一であることを意味する。また、マップデータはＶ２のブロック１６及び１９がそれぞれＶ１のブロック１２及び９と同一であり、Ｖ２のブロック１７はＶ１のブロック１３との差異値でエントロピー符号化（ｃｏｄｅ（Ｂ，Ｋ））され、Ｖ２のブロック１８はＶ１のブロック８との差異値でエントロピー符号化（ｃｏｄｅ（Ｂ，Ｃ））されたことを意味する。従って、図５のようなＶ１及びＶ２プログラムを用いて更新パッケージを生成する場合、更新パッケージ処理器１０は、探索範囲内でＶ２の変更ブロックを見つけることができない場合には、当該変更ブロックデータをＶ１の対応するブロックインデックスをマッピングし、マッピングされたＶ１及びＶ２ブロックのデータの差をエントロピー符号化して、マップデータを生成する。
【００３２】
図６は、更新パッケージ処理器１０が、Ｖ２プログラムの変更ブロックデータを探索範囲内で探すことができない場合の、更新パッケージ生成例を説明するための図である。
【００３３】
更新パッケージ処理器１０は、Ｖ１及びＶ２プログラムが入力されると、探索範囲内でＶ１及びＶ２プログラムを設定されたサイズのマクロブロック単位で比較する。そして、更新パッケージ処理器１０は、二つのバージョンの比較結果によって各ブロックデータの属性（Ｃ、Ｍ、Ｓ）を判別した後、更新データを生成する。この時、変更ブロックのデータとは、更新データとして更新パッケージに含まれるべきデータを意味する。この時、Ｖ１及びＶ２のブロックデータを比較する方法は、Ｖ２ブロックデータをＶ１の前後の探索範囲内に存在するか否かを検査し、見つけることができない場合は、二つのデータの差異をそのままエントロピー符号化（ｅｎｔｒｏｐｙ ｃｏｄｉｎｇ）し、更新データとして生成する。
【００３４】
図６は、ブロック１６−１９の４個のブロックデータＺ、Ｗ、Ｐ、ＸがＶ２に挿入された場合を仮定している。この場合、更新パッケージ処理器１０は、Ｖ１プログラムの探索範囲のブロックデータを検査して新たに挿入されたＶ２プログラムのブロックと同一の値を有するブロックデータがあるかを検査する。この時、探索範囲内で同一の値を有するブロックデータがないため、当該ブロックの属性をＭに設定し、当該ブロックのデータを更新データに設定する。
【００３５】
図６に示すように、Ｖ１プログラムの探索範囲内で、Ｖ２プログラムのブロック１６−１９と一致するブロックはない。このような場合、更新パッケージ処理器１０は、Ｚ、Ｗ、Ｐ、Ｘをエントロピー符号化して下記の表３のようなマップデータを生成することができる。
【００３６】
【表３】
2009544095.tif 000005
表３のマップデータは、Ｖ２のブロック０−１５はＶ１のブロック０−１５と同一であり、Ｖ２のブロック２０−２４はＶ１のブロック１６−２０と同一であることを意味する。また、Ｖ２のブロック１６−１９は更新データのＺ、Ｗ、Ｐ、Ｘにエントロピー符号化されたことを意味する。従って、図６のようなＶ１及びＶ２プログラムを用いて更新パッケージを生成する場合、更新パッケージ処理器１０は、探索範囲内にＶ２の変更ブロックがなければ、当該変更ブロックデータのフラグを２（Ｆ＝２）に設定して、対応するＶ１プログラムのブロックがないことを表示し、別途の更新データを生成する。この場合、更新パッケージはヒストリーデータ、マップデータ及び更新データからなる。
【００３７】
また、図６のように、Ｖ２の変更ブロックデータがＶ１の探索範囲内にない場合、更新パッケージ処理器１０は、更新データを生成せずマップデータのみを用いて更新パッケージを生成することもできる。下記の表４は、Ｖ２の変更ブロックデータがＶ１の探索範囲内にない場合のマップデータの構成例を表している。
【００３８】
【表４】
2009544095.tif 000006
つまり図６のようなＶ１及びＶ２プログラムを用いて更新パッケージを生成する場合、更新パッケージ処理器１０は、Ｖ１プログラムの探索範囲内でＶ２の変更ブロックを探すことができない場合、当該変更ブロックデータをエントロピー符号化して、マップデータを生成する。表４のように、マップデータを生成する場合、更新パッケージ処理器１０は、更新データを生成せず、ヒストリーデータ及び表４のようなマップデータを生成して、更新パッケージを生成することができる。
【００３９】
図７は、Ｖ１プログラムがギャップ領域を備え、Ｖ２プログラムに更新される時のシフト動作を改善する方法を説明する図である。また、図７及び図８は、Ｖ１プログラムの一部のブロックデータがＶ２プログラムから削除される場合の、更新パッケージの生成例を説明するための図である。
【００４０】
図７を参照すると、更新パッケージ処理器１０は、Ｖ１プログラムに基づいてＶ２プログラムを比較する時、新しいデータが追加又は削除されると、当該領域の次のブロックをシフトさせる。この時、変更ブロックのサイズによって前へのシフトが発生すると、更新パッケージ処理器１０は、Ｖ１プログラムの探索範囲を探索して、変更ブロックと同一のブロックデータがあるのかを確認し、ある場合には、Ｖ１ブロックの番号をＶ２の変更ブロックにマッピングさせる。しかし、同一のデータがなければ、更新パッケージ処理器１０はＶ２の当該ブロックデータをエントロピー符号化し、更新データとして生成する。
【００４１】
上記のように、Ｖ１プログラムをＶ２プログラムに更新する場合、多くのブロックのシフトが発生する。従って、上記のようなシフトを考慮し、図７に示すように、Ｖ１プログラムにデータを格納しないギャップ（ｇａｐ）領域を割り当てることができる。ここで、Ｖ１のギャップ領域は、Ｖ２プログラムの更新データを考慮して設定することができる。従って、Ｖ２プログラムのシフト動作は、図７に示すようなギャップ領域によって、その次のコンポーネント（ｃｏｍｐｏｎｅｎｔ）に影響を及ぼさないレベルまでシフトされる。図７を例に挙げると、Ｖ２プログラムは、Ｖ１プログラムのブロック６−１０の５個のブロックデータを必要とせず、ブロック３−４、８−９、１３、１７−１９の８個のブロックが追加され、ブロック１５は同一のサイズに置き換えられる（ｒｅｐｌａｃｅｄ ａｓ ｓａｍｅ ｓｉｚｅ）構造を有する。この場合、Ｖ２プログラムは、Ｖ１プログラムから５個のブロックが削除され、８個のブロックが追加されるため、図６に示すように、最終ブロックは３個のブロックのシフトが発生する。この時、最終ブロックのシフトはＶ１プログラムのギャップ領域で発生するため、Ｖ２プログラムの次のコンポーネントはシフト動作なしで、最初のブロックからＶ１プログラムの当該コンポーネントと比較され更新動作を実行できるようになる。
【００４２】
図８を参照すると、ＦＯＴＡ（Ｆｉｒｍｗａｒｅ ｏｖｅｒ−ｔｈｅ−ａｉｒ）を支援するバイナリは物理的にギャップ領域を有しており、更新時、各コンポーネント領域間の侵犯を防止する。従って、Ｖ１プログラムは図８のような構造を有することができる。すなわち、Ｖ１プログラムは、複数のコンポーネント（図８では、５個のコンポーネントから構成された場合を仮定している）から構成される。従って、図８のように、Ｖ１プログラムを更新するＶ２プログラムが生成されると、更新パッケージ処理器１０は、変更されたブロックデータが追加される場合にも、シフトされるブロックをギャップ領域にマッピングさせることができる。従って、更新パッケージ処理器１０は、更新パッケージをコンポーネント単位で更新ステップを行うことができ、それによって、更新パッケージは各コンポーネント単位で独立的な更新パッケージを生成することができる。
【００４３】
上記のように、更新パッケージ処理器１０は、ヒストリーデータ、マップデータ及び更新データから構成された更新パッケージを生成することができる。この場合、マップデータは、Ｖ１及びＶ２プログラムの差異に基づくブロックの属性（コピー、変更、シフト）及びブロックのインデックス情報を含み、更新データは変更ブロックデータにすることができる。また、更新パッケージ処理器１０は、マップデータ及びヒストリーデータだけで更新パッケージを生成することができる。この場合、更新パッケージ処理器１０は、マップデータに、Ｖ１及びＶ２プログラムの差異に基づくブロックの属性（コピー、変更、シフト）及びブロックのインデックス情報以外に、変更されたデータ（又は、変更ブロックのインデックス情報）を含めることができる。
【００４４】
上記のように、マップデータが生成されると、パッケージ発生器１３０は、第１圧縮器１６０から出力される第２バージョンのブロックデータと、マップデータ発生器１５０で出力されたマップデータとを分析し、更新パッケージを生成する。この時、パッケージ発生器１３０は、マップデータ発生器１５０から生成されるマップデータを分析して、更新データの発生有無を決定する。すなわち、パッケージ発生器１３０は、マップデータのコマンドを分析し、コピーＣ及びシフトＳのコマンドを有するブロックの場合には、更新データを生成しない。また、マップデータのコマンドが変更Ｍの場合、パッケージ発生器１３０は、マップデータが当該ブロックのデータを含んでいる場合や、又は当該ブロックのデータをインデックスする第１バージョンのブロックインデックスを含んでいる場合には、更新データを生成しない。しかし、マップデータのコマンドが変更Ｍであり、マップデータが第２バージョンの当該ブロックデータを変更するための第１バージョンのインデックス又はエントロピーデータを含まない場合、パッケージ発生器１３０は、比較器１１０で圧縮された第２バージョンのブロックデータを入力して更新データとして設定する。すなわち、パッケージ発生器１３０は、マップデータを分析し、コピーＣ及びシフトＳのコマンドを有するマップデータであると更新データを生成せず、変更Ｍのコマンドであるとフラグを分析し、Ｆ１フラグであると更新データを生成せず、Ｆ２フラグである場合のみ更新データを生成する。
【００４５】
そして、上記のように生成される更新パッケージは、第２圧縮器１４０によって圧縮された後、更新パッケージサーバ２０に伝送される。この時、第１圧縮器１６０で第１及び第２バージョンの情報を圧縮する場合、第１圧縮解除器１６５は圧縮された第１及び第２バージョンの情報を圧縮解除する。これは、圧縮器１６０で圧縮された第１及び第２バージョン情報が正常に圧縮されたかを確認するためで、圧縮時にエラーが発生した場合、第１圧縮器１６０を制御して再圧縮するよう制御することができる。また、第２圧縮器１４０で更新された更新パッケージを圧縮する場合、圧縮解除器１４５は圧縮された更新パッケージの圧縮を解除する。これは、更新パッケージが正常に圧縮されたかを確認するためである。
【００４６】
この時、第１圧縮器１６０は省略することもできる。この場合、比較器１１０は、圧縮されていない第１及び第２バージョンプログラム５０及び５５を入力するようになる。この場合、第１及び第２バージョン５０及び５５は設定されたブロックサイズで比較器１１０に入力され、比較器１１０は第１及び第２バージョンをブロック単位で比較する動作を行う。また、更新パッケージ処理器１０が、第１圧縮器１６０によって圧縮されたバージョンを処理する場合、第２圧縮器１４０は省略することもできる。これは、更新パッケージ処理器１０で生成される第２バージョンの更新パッケージが、すでに圧縮されたデータであるためである。本発明の実施形態では、第１圧縮器１６０及び第２圧縮器１４０を両方とも使用すると仮定する。
【００４７】
また、更新パッケージ処理器１０は、マップデータを生成しないこともある。これは、受信側で第１バージョンを用いて更新データをインストールするためのマップデータを生成することができるためである。また、パッケージ発生器１３０が、第１バージョンのブロックデータと関連するコマンド及びブロックインデックスを含む更新データを生成することもできる。従って、インストールデータからマップデータ発生器１５０を省略することもできる。
【００４８】
図３を参照すると、インストールデータ発生器１８０はマップデータ発生器１５０を備えていない。この場合、パッケージ発生器１３０は、第２バージョンの各ブロックが、第１バージョンの各ブロックにマッピングされるブロックインデックス値及びブロックデータに情報を含める更新データを生成する。
【００４９】
図９は、ヒストリーデータ及び更新データから構成される更新パッケージを生成する方法を説明するための図である。この場合、更新パッケージ処理器１０はマップデータ発生器を備えず、パッケージ発生器１３０は図９のような更新データを生成する。ここで、更新データは、Ｖ２バージョンの各ブロックのインデックス情報及びブロックデータ情報を含む構造を有する。
【００５０】
図９を参照すると、Ｖ２は６、７、１３、１４、１５、１６、１７番ブロックデータが追加され、Ｖ１の９、１０、１１、１２番ブロックデータが削除された状態であることが分かる。この時、パッケージ発生器１３０は、Ｖ１及びＶ２の比較結果値を分析し、Ｖ２の各ブロックのブロックインデックス（Ｖ１のようなブロックマッピングのためのインデックス）及びブロックデータの情報を含まなければならない。本発明の実施形態に係る更新データは、マップデータと類似する構造形態を有する。すなわち、更新データのコマンドはＣ（ｃｏｐｙ）、Ｍ（ｍｏｄｉｆｙ、ｉｎｓｅｒｔ ｏｒ ｒｅｐｌａｃｅ ａｓ ｓａｍｅ ｓｉｚｅ）、Ｓ（ｓｈｉｆｔ）から構成され、各コマンドのフォーマットは下記のように構成される。
コピー（ｃｏｐｙ ｆｏｒｍａｔ）
[Ｃｍｄ][ｓｔａｒｔ ｂｌｏｃｋ ｎｏ][ｎｕｍｂｅｒ ｏｆ ｂｌｏｃｋ]
変更（ｍｏｄｉｆｙ ｆｏｒｍａｔ）
[Ｃｍｄ][ｓｔａｒｔ ｂｌｏｃｋ ｎｏ][ｎｕｍｂｅｒ ｏｆ ｂｌｏｃｋ][ｄａｔａ]
シフト（ｓｈｉｆｔ ｆｏｒｍａｔ）
[Ｃｍｄ][ｓｔａｒｔ ｂｌｏｃｋ ｎｏ][ｎｕｍｂｅｒ ｏｆ ｂｌｏｃｋ][ｐｒｅｖｉｏｕｓ ｖｅｒｓｉｏｎ ｐｏｓｉｔｉｏｎ]
上記のようなフォーマットを有する場合、コピーは開始ブロックの番号及びコピーするブロックの数を含む情報を有し、変更は開始ブロックの番号、変更ブロックの数及び各変更ブロックのデータが順次に連結される情報を有し、シフトは開始ブロックの番号、シフトブロックの数及び１番目のシフトブロックに対応するＶ１のブロックインデックス等が含まれる。
【００５１】
従って、図９の場合、Ｖ２のコピーブロックに対する更新データはＣ：０，６であり、変更ブロックに対する更新データはＭ：６，２，Ｘ，Ｙ及びＭ：１３，５，Ａ，Ｂ，Ｃ，Ｄ，Ｅであり、シフトブロックに対する更新データはＳ：８，３，６、Ｓ：１１，２，１３及びＳ：１８，７，１５である。上記のような更新データが伝送される場合、受信側では、第２バージョンのＶ２プログラムに更新する時、Ｖ２の０番ブロックから６個のブロックはＶ１の０番から５番までのブロックをコピーし、６番ブロックから２個のブロックはＸ及びＹを追加し、８番ブロックから３個のブロックはシフトされてＶ１の６、７、８番ブロックをコピーし、１１番ブロックから２個のブロックはシフトされてＶ１の１３、１４番ブロックをコピーし、１３番ブロックから５個のブロックは順次にＡ、Ｂ、Ｃ、Ｄ、Ｅを追加し、１８番ブロックから７個のブロックはシフトされて各々Ｖ１の１５、１６、１７、１８、１９、２０、２１番ブロックをコピーしなさいとの意味になる。従って、図９のようなＶ１及びＶ２データが入力されると、更新パッケージ処理器１０のパッケージ発生器１３０は、図９の更新パッケージ（ｄｅｌｔａ ｐａｃｋａｇｅ）の更新データを下記の表５のように生成するようになる。
【００５２】
【表５】
2009544095.tif 000007
その後、更新パッケージ処理器１０は、更新データとヒストリーデータとを結合し更新パッケージとして生成し、更新パッケージは更新パッケージサーバ２０に伝達される。この時、更新パッケージ処理器１０で生成される更新パッケージは、第２圧縮器１４０によって圧縮され、更新パッケージサーバ２０に伝達されることもある。上記のように、マップデータを生成せずに更新データを用いてＶ２プログラムの更新パッケージを生成する場合、更新パッケージの生成速度を向上させることができる。
【００５３】
上記のように、更新パッケージ処理器１０は、第１バージョンに基づいて第２バージョンを比較し、比較結果によりインストールデータを含む更新パッケージを生成する。この時、比較ステップにおいて、第２バージョンが第１バージョンに新しいデータを追加又は削除する変更が発生すると、第２バージョンのブロックは、第１バージョンの当該領域に続く次のブロックに比べて、シフトされる結果になる。この場合、第２バージョンのブロックは、第１バージョンで変更されたブロックに従って、前あるいは後ろにシフトされる結果になる。また、第２バージョンの変更されたブロックは第１バージョンの探索範囲内で同一のブロックが存在するのか探索され、探索結果により、同一のブロックデータを有する第１ブロックのブロックインデックスを指定するか、又は、当該ブロックのデータをエントロピー符号化するようになる。そして、上記のように、変更ブロック以後の第２バージョンのブロックデータは、第１バージョンのブロックデータにおいて挿入又は削除されたブロック数分シフトされる。従って、更新パッケージ処理器１０は、第１バージョン及び第２バージョンを比較した後、コマンドのコピーＳ、変更Ｍ及びシフトＳからなるマップデータ（マップデータを使用しない場合には、更新データにこれを含ませて生成することができる）を生成し、マップデータ、ヒストリーデータ及び更新データ（マップデータを生成しない場合には、ヒストリーデータ及び更新データ）からなる第２バージョンの更新パッケージを生成し、更新パッケージサーバ２０に伝送する。図１０及び図１１は、更新パッケージの構造を示す図である。図１０は、図２の更新パッケージ処理器によって生成された更新パッケージの構造を示す図であり、図１１は、図３の更新パッケージ処理器によって生成された更新パッケージの構成を示す図である。
【００５４】
この時、更新パッケージ処理器１０から更新パッケージを伝送する方法は、更新サーバ２０との接続方法によって無線、近距離通信又は有線通信方法を使用することができる。更新パッケージ処理器から更新パッケージを伝送されると、更新サーバ２０は、更新パッケージをダウンロードすることができる携帯端末３０に、新しい更新パッケージの発生を通知する。そして、通知結果よって応答する携帯端末３０に更新パッケージをダウンロードする。更新パッケージ発生の通知のために、更新パッケージの発生を各携帯端末に通知する通知サーバ（ｎｏｔｉｆｉｃａｔｉｏｎ ｓｅｒｖｅｒ）２５をさらに備えることができる。
【００５５】
携帯端末３０は、ダウンロードする更新パッケージの発生を通知されると、これに対する応答をし、更新サーバ２０から更新パッケージをダウンロードする。図１２は、本発明の実施形態に係る更新パッケージをダウンロードし、システムバージョンを更新する端末システムの構成を示す図である。
【００５６】
図１２を参照すると、携帯端末３０は、ダウンローダ２２０、インストーラ２３０、トランスレータ２４０、第１メモリ２５０、第２メモリ２６０を含む。ダウンローダ（ｄｏｗｎ−ｌｏａｄｅｒ）２２０は、更新サーバ２０から更新パッケージをダウンロードし、ダウンロードされる更新パッケージはメモリに一時格納される。ここで、メモリは、第２メモリのような揮発性メモリであり、更新パッケージの一時格納はインストールされる前まで維持される。インストーラ（ｉｎｓｔａｌｌｅｒ）２３０は、インストールデータ及び更新データを抽出し、第１メモリ２５０に格納する。この時、インストールデータはヒストリーデータ及びマップデータから構成され、又はヒストリーデータのみからなる。ここで、インストールデータがマップデータを含まない場合、第２バージョンの第１バージョンマッピング情報は更新データに含まれる構造を有する。この時、インストーラ２３０は、マップデータが含まれていないインストールデータを受信した場合、第１バージョンと更新データとを比較して、マップデータを生成することもあり、生成しないこともある。この時、インストーラ２３０でマップデータを生成しない場合、トランスレータ２４０で更新データのマッピング情報を用いて更新パッケージを直接第１バージョンに結合することもある。インストーラ２３０は、第１メモリ２５０の更新パッケージを格納する領域（ｐｏｏｌ）に、各々ヒストリーデータ、マップデータ及び更新データをマッピングして格納する。この時、第１メモリ２５０には、最初バージョンである第１バージョン及び第１バージョンを更新するための少なくとも一つの更新パッケージが格納されるが、ここで、更新パッケージは少なくとも一つであり、最大Ｎ個の更新パッケージを格納することができる。本発明の実施形態では、Ｎ＝６個と仮定する。
【００５７】
また、上記のように、新しいバージョンの更新パッケージをダウンロードすると、携帯端末３０は、ユーザにバージョンを更新することができることを表示する。この時、携帯端末の更新要求が発生するか、又はシステム初期化動作を実行した後、携帯端末３０のトランスレータ（ｔｒａｎｓｌａｔｏr）２４０は、第１メモリ２５０から第１バージョン及びダウンロードされた更新パッケージをロードした後、第１バージョンに更新パッケージを組合せて第２バージョンに更新した後、これを第２メモリ２６０に格納する。この時、トランスレータ２４０は、更新パッケージのインストールデータを分析してバージョン番号及び結合するバージョンを決定し、マップデータを分析して更新パッケージの更新データを結合するバージョン（ここでは、第１バージョン）に組合せてバージョンを更新する。また、インストールデータにマップデータが含まれていない場合、トランスレータ２４０はヒストリーデータを分析して結合する第１バージョンを決定し、更新データによって更新パッケージを第１バージョンに結合して、第２バージョンのプログラムを生成することもできる。上記のような動作を実行し、第１バージョンを第２バージョンに更新すると、トランスレータ２４０はこれを第２メモリ２６０に格納し、その後、携帯端末は第２メモリ２６０に格納された更新バージョンのプログラムを用いてシステムの動作を制御する。
【００５８】
上記のように、第１メモリ２５０には、第１バージョン及び少なくとも一つの第２バージョンの更新パッケージが格納される。この時、第２バージョンの更新パッケージは、インストールデータ（ヒストリー及びマップデータ）及び更新データ、又はヒストリーデータ及び更新データ、又はインストールデータ（ヒストリー及びマップデータ）だけで構成される。インストールデータは、第１バージョンに更新データを更新する時に使用するデータであって、更新パッケージのヒストリーデータと更新データのマッピング関連情報であるマップデータとから構成される。ここで、マップデータは二つのバージョン間の関係を表し、上記のように３つの形態（ｃｏｐｙ、ｍｏｄｉｆｙ、ｓｈｉｆｔ）で表示する。マップデータは、特定のデータ（ここでは、第１バージョンのプログラム）の比較によりＣＭＳ（ｃｏｐｙ、ｍｏｄｉｆｙ、ｓｈｉｆｔ）を探す生成方法で迅速なアドレス計算を目的に使用され、第１メモリ２５０に含まれている第１バージョンに基づいて、第２メモリ２６０で第２バージョンのプログラムを速かに生成するためのデータとして用いられる。
【００５９】
ダウンロードされる更新パッケージは更新パッケージ処理器１０で生成されるが、この時、インストールデータのマップデータは生成されることもあり、生成されないこともある。従って、携帯端末にダウンロードされる更新パッケージは、マップデータが含まれることもあり、含まれないこともある。従って、マップデータが含まれていない更新パッケージをダウンロードした場合、インストーラ２３０は、逆に第１メモリ２５０に格納された第１バージョンと、ダウンロードされた更新パッケージとを比較分析し、更新データを第１バージョンにマッピングするためのマップデータを生成する。このため、インストーラ２３０は、更新データを分析してマップデータを生成する。この時、更新データは、図９に示すような構造を有することができる。インストーラ２３０が、更新データからマップデータを生成する理由は、トランスレータ２４０で第２バージョンのプログラムを生成する速度を向上させるためである。また、更新データが、第１バージョンのブロックとマッピングするための情報を含んでいる場合、インストーラ２３０は、ダウンロードされた更新パッケージを第１メモリ２５０にそのまま格納し、トランスレータ２４０は、更新データを用いて第１バージョンと更新パッケージとを直接結合することもできる。
【００６０】
また、トランスレータ２４０は、第１バージョンと最も最近ダウンロードされた第２バージョンの更新パッケージとを組合せて更新することが一般的であるが、ユーザが選択する特定バージョンの更新パッケージで更新することもできる。すなわち、少なくとも一つのバージョンを格納するが、本発明の実施形態では、第２バージョンの更新パッケージは最大６個まで格納できると仮定する。この場合、特定の第２バージョンの更新パッケージが第２メモリ２６０で再組合せに失敗した場合、ユーザに現在のシステムが保有している再組合せの可能な第２バージョンの更新パッケージリストを表示し、ユーザによって第２バージョンの更新パッケージを選択し、更新バージョンを生成することもできる。
【００６１】
また、第１メモリ２５０は、複数（ここでは、最大６個と仮定する）の更新パッケージを格納できる格納領域を備える。従って、更新パッケージは必要な場合にダウンロードされ、第１メモリ２５０の格納領域に格納され、次の更新パッケージがダウンロードされたとしても、以前にダウンロードされた更新パッケージは消さない。従って、バージョンの変更によるヒストリーが累積して格納され、第１バージョンの格納状態がそのまま維持される。従って、第１及び第２バージョンの更新パッケージがそのまま維持されるため、更新の信頼性（ｆａｕｌｔ−ｔｏｌｅｒａｎｃｅ）が高い。また、特定第２バージョンがロードされない場合、ユーザの選択によって、特定バージョンの更新パッケージを用いることができ、全てのバージョンの更新パッケージロードが失敗する最悪の場合にも、最初バージョンの第１バージョンをロードして使用することができる。
【００６２】
図１３は、本実施形態に係る端末システムの第１メモリ２５０の構造を示す図である。図１３における参照番号３１０は、第１バージョンＶ１を格納する第１格納領域であり、第１バージョンＶ１は圧縮された状態又は圧縮されていない状態で格納される。参照番号３２０は、少なくとも一つの第２バージョンの更新パッケージを格納する第２格納領域であり、対応する第２バージョンの更新パッケージを格納するための領域である。すなわち、第２格納領域３２０に格納される第２バージョンの更新パッケージは、各々対応するバージョンの更新データ及びインストールデータになり、この時、更新データ（コマンド、実際のデータ等）及びブロックインデックスになる。従って、第２格納領域３２０のサイズは、第２バージョンの更新パッケージの数によって決定される。そして、参照番号３３０は、ユーザ領域でありファイルシステム（ｆｉｌｅ ｓｙｓｔｅｍ）等が格納される。
【００６３】
図１４は、第１メモリ２５０の第２格納領域３２０に格納される更新パッケージの構造を示す図であり、図１５は、図１４のような更新パッケージでのヒストリーデータの構造を示す図である。
【００６４】
図１４を参照すると、第２格納領域３２０は、設定された数（ここでは６個）の第２バージョンの更新パッケージを格納できる領域を備え、各バージョンの格納領域は対応するバージョンのヒストリーデータ、マップデータ及び更新データを格納できる構造で構成される。この時、第２バージョンの更新パッケージは、インストールデータ及び更新データから構成され、インストールデータは上記のようにヒストリーデータ、又は、ヒストリーデータ及びマップデータにすることができる。また、第２格納領域３２０には第１バージョンのヒストリーデータ及びマップデータを格納することができる。ここで、第１バージョンのヒストリーデータを格納する理由は、第１格納領域３１０に格納された第１バージョンに接続するためであり、第１バージョンのマップデータ及び更新データは省略することができ、また、その代わりにヌルデータ（ｎｕｌｌ ｄａｔａ）で埋めることもできる。図１４は、更新パッケージがヒストリーデータ、マップデータ及び更新データ等から構成された例を示している。また、更新パッケージ処理器１０において、上記のようにヒストリーデータ及びマップデータから構成される更新パッケージを生成する場合、第２格納領域３２０の各更新パッケージの格納領域は、対応するバージョンのヒストリー及びマップデータを格納する構造で構成されることもある。
【００６５】
図１５を参照すると、ヒストリーデータの構造はヒストリーデータのバージョン（ｖｅｒｓｉｏｎ）、サイズ（ｓｉｚｅ）、結合フラグ（ｃｏｍｂｉｎｅｄ ｆｌａｇ）、失敗フラグ（ｆａｉｌ ｆｌａｇ）等から構成される。ここでバージョン（ｖｅｒｓｉｏｎ）は第２バージョンのバージョン番号（図１４の場合、Ｖ＃２−Ｖ＃７中の一つ）であり、サイズ（ｓｉｚｅ）は当該バージョンのヒストリーデータのサイズであり、結合フラグ（ｃｏｍｂｉｎｅｄ ｆｌａｇ）は当該バージョンの更新パッケージを結合して更新するバージョン番号（ここでは、第１バージョンの番号Ｖ＃１）であり、失敗フラグ（ｆａｉｌ ｆｌａｇ）は、ロード中に失敗（ｆａｉｌ）の発生有無を表すためのフラグである。この場合、第１バージョンのヒストリーデータは、バージョン（ｖｅｒｓｉｏｎ）領域にＶ＃１が格納され、結合フラグ（ｃｏｍｂｉｎｅｄ ｆｌａｇ）領域にＶ＃１が接続される。また、例えば、任意の更新パッケージ領域のヒストリーデータでバージョン（ｖｅｒｓｉｏｎ）領域にＶ＃５が格納され、結合フラグ（ｃｏｍｂｉｎｅｄ ｆｌａｇ）領域にＶ＃１が格納された場合、携帯端末３０は、バージョン５の第２バージョンの更新パッケージを第１バージョンのプログラムに結合してプログラムを更新するようになる。
【００６６】
ダウンロードされる更新パッケージは、図１４のような構造であり、図１３のような第１メモリ２５０の第２格納領域３２０に格納される。この時、第２格納領域３２０にダウンロードされる更新パッケージは、更新要求時、第１格納領域３１０の第１バージョン情報に結合され更新されたプログラムを生成する。
以下の説明では、更新パッケージがマップデータ、ヒストリーデータ及び更新データから構成された場合を仮定して説明する。
【００６７】
図１６は、本発明の一実施形態に係るプログラム更新システムの動作を示す。図１６に示すように、第１メモリはフラッシュメモリのような不揮発性メモリから構成され、第２メモリはＲＡＭのような揮発性メモリである。
【００６８】
図１６を参照すると、更新要求時、ローダ（図示せず）は第２格納領域３２０で更新されるバージョンの更新パッケージをロードし、トランスレータ２４０は、ロードされた更新パッケージを第１格納領域３１０の第１バージョンに更新して、更新されたバージョンのプログラムを生成した後、これを第２メモリ２６０に格納する。この時、更新要求は携帯端末３０のユーザの応答によって決定される。すなわち、携帯端末３０は、更新パッケージをダウンロードする時点又はシステム初期化の実行後、更新されていないバージョンの更新パッケージが存在する場合、更新の有無を案内するメッセージを表示し、ユーザが更新を要求した時、上記のような動作を行いバージョンを更新した後、更新されたバージョンのプログラムを第２メモリ２６０に格納する。その後、携帯端末３０は、第２メモリ２６０に、図１６のように格納された更新バージョンのプログラムを用いて携帯端末３０を運用する。
【００６９】
また、上記のような更新動作は、携帯端末の動作を初期化した後に行われる。すなわち、図１３に示すように、第１及び第２バージョンの更新パッケージは、互いに結合されていない状態で第１メモリ２５０に格納されており、更新が要求された時点で、第１バージョンに第２バージョンの更新パッケージを結合して更新されたバージョンを生成し、この更新バージョンを第２メモリ２６０に格納して使用する。
【００７０】
図１７は、第２バージョンの更新パッケージが第１メモリ２５０に格納されていない場合の動作を説明するための図であり、図１８及び図１９は、第２バージョンの更新パッケージが第１メモリ２５０の第２領域３２０に格納された場合の動作を説明するための図である。
【００７１】
図１７を参照すると、第１メモリ２５０は第１バージョンを格納しており、ここでの第１バージョンは初期バージョン（ｉｎｉｔｉａｌ ｖｅｒｓｉｏｎ）のプログラムである。そして、第１バージョンは、ｎ個のブロック（Ｂ＃１−Ｂ＃ｎ）からなると仮定している。ここで、第１バージョンのインストールデータは、ヒストリーデータとマップデータから構成される。ここで、ヒストリーデータは、上記のように、バージョン領域にＶ＃１が格納され、結合フラグ領域にＶ＃０が格納される。マップデータ領域には、表１乃至表３のような構造を有するマップデータが格納される。
【００７２】
この時、更新要求命令が発生すると、トランスレータ２４０はインストールデータを分析する。この時、第２バージョンの更新パッケージが存在しない場合、マップデータはマップデータをヌル状態で備えることができ、また、｛Ｃ：０，ｎ，Ｆ：０，ｎｕｌｌ，ｎｕｌｌ｝構造のマップデータをも備えることができる。上記のようなマップデータは、第１メモリ２５０の第１バージョンをそのまま第２メモリ２６０にコピーしなさいという命令であるため、トランスレータ２４０は、第１メモリ２５０の第１バージョンを第２メモリ２６０にそのままコピーする。すると、携帯端末３０は、第２メモリ２６０に図１７のようにコピーされたバージョンによって携帯端末の動作を制御する。この時、第１メモリ２５０に格納されるバージョンは圧縮されて格納される。バージョンが圧縮されて格納された場合、トランスレータ２４０は、圧縮解除器２７０によって圧縮されたバージョンを解除した後、第２メモリ２６０にコピーする。また、更新パッケージ処理器１０が、第２圧縮器１４０によって更新パッケージを圧縮する場合、トランスレータ２４０は、まずロードされる更新パッケージの圧縮を解除した後、上記のようなトランスレート動作を行う。
【００７３】
図１８及び図１９を参照すると、第１メモリ２５０は第１格納領域３１０に第１バージョンを格納しており、第２格納領域３２０に第２バージョンの更新パッケージを格納している。ここで、第１バージョンは、初期バージョン（ｉｎｉｔｉａｌ ｖｅｒｓｉｏｎ）のプログラム又は基準として設定されたバージョンのプログラムであり、第２バージョンの更新パッケージは、更新データ及びインストールデータを含む。インストールデータは、上記のように、対応する第２バージョンのバージョン番号及び結合するべきバージョン（ここでは、第１バージョン）の番号等を格納するヒストリーデータ、及びマップデータから構成される。第１バージョンは、図１８及び図１９に示すように、ｎ個のブロック（Ｂ＃１−Ｂ＃ｎ）からなると仮定している。ここで、ヒストリーデータは、結合フラグ領域にＶ＃０が格納される場合を仮定しており、マップデータ領域には表１から表３のいずれかのマップデータが格納されている場合を仮定している。
【００７４】
まず、図１８を参照すると、第１メモリ２５０の第１領域３１０は、図１８に示すような第１バージョンのプログラムを格納し、第１メモリ２５０の第２領域３２０の特定更新パッケージは、表１のようなマップデータを格納していると仮定する。この時、更新パッケージのヒストリーデータは、第１バージョンのプログラムと結合するためのフラグ情報を格納している。この場合、トランスレータ２４０は、マップデータによって第１バージョンプログラムを更新し、第２バージョンプログラムを生成した後、これを第２メモリ２６０に格納する。この時、マップデータは、０番ブロックから１５番ブロックまでは第１バージョンのブロックをコピーし、１６番ブロックから１９番ブロックまでの４個のブロックは各々第１バージョンの１２、１３、８、９番ブロックをコピーして挿入し、２０番ブロックから最後のブロック（前の２０個のブロックを除く全てのブロック）はブロック４個ずつシフトさせるコマンドを含んでいる。従って、トランスレータ２４０は、図１８の第２メモリ２６０に示すように、マップデータによって第１バージョンプログラムを更新する。
【００７５】
次にに、図１９を参照すると、第１メモリ２５０の第１領域３１０は、図１９に示すような第１バージョンのプログラムを格納し、第１メモリ２５０の第２領域３２０の特定更新パッケージは、表３のようなマップデータを格納していると仮定する。この時、更新パッケージのヒストリーデータは、第１バージョンのプログラムと結合するためのフラグ情報を格納している。マップデータは、０番ブロックから１５番ブロックまでは第１バージョンのブロックをコピーし、１６番ブロックから１９番ブロックまでの４個のブロックは各々更新パッケージの更新データ｛Ｚ，Ｗ，Ｐ，Ｘ｝として挿入し、２０番ブロックから最後のブロック（前の２０個のブロックを除く全てのブロック）まではブロック４個ずつシフトさせるというコマンドを含んでいる。従って、トランスレータ２４０は、図１９の第２メモリ２６０に示すように、マップデータによって第１バージョンプログラムを更新する。
【００７６】
その後、携帯端末３０は、第２メモリ２６０に図１８または１９のように更新されたバージョンによって携帯端末３０の動作を制御する。この時、第１メモリ２５０に格納される第１バージョンのプログラム及び第２バージョンの更新パッケージは、圧縮されて格納される。バージョンが圧縮されて格納された場合、トランスレータ２４０は、圧縮解除器２７０によって圧縮された第１バージョンを解除することができる。また、第１バージョン及び第２バージョンのプログラムを圧縮した後（更新パッケージ処理器１０の第１圧縮器１６０を用いて圧縮する場合）、圧縮された第１バージョン及び第２バージョンのブロックを比較して更新パッケージを生成した場合、トランスレータ２４０でトランスレートした第２バージョンのブロックデータは、圧縮されたデータである。この場合、トランスレータ２４０は圧縮解除器２７５を用いて圧縮を解除した後、第２メモリ２６０に格納する。
【００７７】
図２０は、受信システム３０が、第１バージョンプログラムに更新パッケージを結合して第２バージョンプログラムを生成するステップを総合的に説明するための図である。
【００７８】
図２０を参照すると、第１メモリ２５０は、上記のように、第１バージョンのプログラム及び第２バージョンの更新パッケージを格納しており、更新要求時、トランスレータ２４０は、第２バージョンの更新パッケージを第１バージョンに結合して第２メモリ２６０に格納する。従って、携帯端末３０は、第１メモリ２５０に格納している第１バージョンのプログラム及び第２バージョンの更新パッケージを第２メモリ２６０で組合せて使用し、上記のような更新はシステム初期化の実行後又は更新要求によって、反復的に実行される。
【００７９】
上記のように、本発明の実施形態に係るシステムのプログラム更新方法は、更新パッケージを生成し、生成された更新パッケージを決められたネットワーク通信方法によってダウンロードし、ダウンロードされた更新パッケージをインストールして第１格納し、第１格納された更新パッケージを用いてシステムの更新プログラムを生成して第２格納した後、第２格納された更新プログラムを用いてシステムを運用する。このため、本発明の実施形態では、まず、迅速な更新のための更新パッケージ生成方法を提案し、２番目に、更新パッケージをダウンロードした後、迅速な実行のためのインストールデータ処理方法を提案し、３番目に、更新パッケージをダウンロードするシステムからダウンロードされた更新パッケージを保管及び処理する方法を提案し、４番目に、保管している更新パッケージを用いてシステム更新を行う方法を提案する。
【００８０】
まず、迅速な更新のための更新パッケージの生成方法は、第１バージョンのプログラムと第２バージョンのプログラムとを更新パッケージの生成のための入力し、二つのバージョンは、更新パッケージの生成時、圧縮された状態又は圧縮されていない状態で比較された後、二つのバージョン間の差異点を捜し出す。この時、二つのバージョン間の差異点は、これを受信するシステムで、第１バージョンに更新パッケージを再組合せするためのインストールデータ（ｉｎｓｔａｌｌ  ｄａｔａ：特にｍａｐ  ｄａｔａ）として生成される。そして、インストールデータと共に更新データを生成した後、これを更新パッケージとして生成する。
【００８１】
２番目に、上記のように生成された更新パッケージは携帯端末にダウンロードされる。この時、携帯端末は、更新パッケージをダウンロードした後、迅速な実行のための更新パッケージ処理ステップを行う。更新パッケージに含まれるインストールデータは、基準になるプログラム（ここでは、第１バージョンプログラム）との比較によって得られ、迅速なアドレス計算を目的に使用される。すなわち、第１メモリ２５０に格納された第１バージョンと、ダウンロードされた更新パッケージ２６０が結合される時、インストールデータを用いて短時間でブロック別に処理することができる。
【００８２】
３番目に、更新パッケージをダウンロードした後、迅速な実行のためのインストール処理方法を説明すると、インストールデータは、基準プログラム（ここでは、第１バージョンプログラム）との比較によって得られるマップデータを探す生成方法で、迅速なアドレス計算を目的に使用され、第１メモリ２５０に含まれている第１バージョンと更新パッケージとを第２メモリで結合するための補助として用いられる。この時、マップデータが更新パッケージに含まれていない場合、携帯端末は、逆に第１メモリに含まれた第１バージョンプログラムと更新データとを比較し、当該マップ機能のためのデータを生成することができる。また、インストールデータは更新パッケージのヒストリーデータを含んでいる。この時、ヒストリーデータは、第１メモリ２５０に格納された更新パッケージ及び更新パッケージが結合されるバージョン情報を含んでいる。本発明の実施形態では、上記のように、６個の更新パッケージを第１メモリ２５０に保管することを仮定して説明しており、この時、特定の更新パッケージが第２メモリ２６０で結合に失敗した場合、携帯端末３０が保管している他の更新パッケージのリストを表示し、ユーザの選択による更新パッケージで更新することができる。
【００８３】
４番目に、更新パッケージの保管及び処理方法を説明すると、更新パッケージは第１メモリ２５０上に構成される特定の格納領域に保管され、格納領域は複数備えられる。従って、更新パッケージは、ダウンロードされて第１メモリ２５０に格納され、その次の更新パッケージがダウンロードされる場合にも以前の更新パッケージは消されない。そして、特定の更新パッケージがロードされない場合、携帯端末３０は、ユーザに、保管している更新パッケージのリストを提供し、特定バージョンを再組合せするための選択を助ける。そして、全ての更新パッケージのロードが失敗するという最悪の場合にも、最初バージョンの第１バージョンをロードして使用することができる。
図２１は、本発明の実施形態に係る更新パッケージ生成及び更新ステップを示すフロー図である。図２１の動作は、図１において、更新パッケージ処理器１０及び携帯端末３０の動作を中心に示されている。
【００８４】
図２１を参照すると、更新パッケージ処理器１０は、４１１ステップで更新パッケージを生成するためのバージョンを受信する。更新パッケージは、新しいバージョンのプログラムが生成される場合に生成され、生成される更新パッケージは、基準になるバージョンのプログラムと比較されて生成されるデータ（更新データ及びインストールデータ）となる。第１バージョンは、最初バージョン又は他のバージョンと結合できる基準バージョンとなる。すなわち、第１バージョンは、更新されるバージョンと結合される基準バージョンとなる。第２バージョンの更新パッケージは、第１バージョンと結合されて更新された第２バージョンのプログラムを生成する情報であって、第２バージョンの更新パッケージは少なくとも一つ以上である。従って、上記のように、第１及び第２バージョンが受信されると、更新パッケージ処理器１０は４１３ステップで二つのバージョンの差異を分析し、４１５ステップで二つのバージョンの差異に基づく更新パッケージを生成する。この時、更新パッケージは、二つのバージョンの差異に基づいて第１バージョンを更新する更新データと、更新データを第１バージョンに結合するための情報であるインストールデータ等から構成される。そして、インストールデータは、第２バージョンのヒストリーを表示するヒストリーデータと、第１バージョンと第２バージョンとをマッピングするための情報を表すマップデータ等から構成される。この時、マップデータは更新パッケージから省略することができ、この場合、マップデータは携帯端末で更新パッケージをインストールする時に生成することができる。従って、インストールデータは、プログラムの更新時、更新バージョンのプログラムを速かに生成するための情報として使用される。
上記のように生成される更新パッケージは更新サーバ２０に伝達され、更新サーバ２０は携帯端末３０に更新パッケージの生成を通知する。更新パッケージの発生を感知した携帯端末３０が更新サーバ２０にダウンロードを要求すると、更新サーバ２０は対応する携帯端末３０に更新パッケージをダウンロードする。この時、ダウンロード方法は携帯端末３０の通信方法によって決定される。すなわち、携帯端末３０が無線通信機能を備える携帯端末であれば、ＣＤＭＡ、ＵＭＴＳ、ＧＳＭ等のような無線通信方法によってダウンロードされ、また、インターネットと接続されている場合には、ＵＳＢ、ブルートゥース、ワイブロ、無線ＬＡＮ等のような通信方法で更新パッケージをダウンロードすることができる。
【００８５】
携帯端末３０は、４５１ステップで更新パッケージをダウンロードした後、４５３ステップでダウンロードされた更新パッケージを第１メモリ２５０に格納する。この時、第１メモリ２５０は、第１バージョンのプログラムを格納する第１領域３１０及び更新パッケージを格納する領域で構成される第２領域３２０から構成される。第２領域３２０は、複数の領域から構成され、複数の第２バージョンの更新パッケージ情報を格納する。本実施形態では、第２領域３２０が６個の格納領域から構成されると仮定している。そして、インストールデータであるヒストリーデータ及びマップデータを格納する領域と、更新データを格納する領域等から構成される。
【００８６】
更新パッケージをインストールするステップにおいて、更新パッケージにマップデータが含まれていない場合、携帯端末３０のインストーラは、第１バージョンに更新データをマッピングし、更新するためのマップデータを抽出することができる。上記のように、更新パッケージが第１メモリ２５０に格納されると、携帯端末３０は、更新要求時、４５５ステップで第１バージョンに更新パッケージを更新し、更新されたバージョンのプログラムを第２メモリ２６０に格納し、格納された更新バージョンプログラムによってシステムを運用する。この時、第２メモリ２６０はワークメモリ（ｗｏｒｋ  ｍｅｍｏｒｙ）であり、この場合、第２メモリ２６０は揮発性メモリとして具現することができる。従って、携帯端末３０は、システム初期化ステップにおいて、第１メモリ２５０に格納された第１バージョンに、最も最近ダウンロードされた第２バージョンの更新パッケージを結合して生成された第２バージョンのプログラムを第２メモリ２６０に格納し、携帯端末３０は、第２メモリ２６０に格納されたプログラムを用いてシステムを運用する。また、携帯端末３０は、プログラムの更新が失敗した場合、以前のバージョンプログラムを用いて自動的にプログラム更新を試みることができる。また、携帯端末３０は、プログラムの更新が失敗する場合、以前のバージョンのリストを表示し、ユーザによって選択されたバージョンを用いて手動でプログラム更新を行うことができる。また、システムの初期化時、ユーザは必要とするプログラムのバージョンを選択することができ、携帯端末３０は、ユーザにより選択されたバージョンでシステムのプログラムを更新することもできる。
【００８７】
以下、携帯端末３０で更新パッケージを処理するステップを具体的に説明する。
【００８８】
図２２は、本発明の実施形態に係る携帯端末３０が更新パッケージをダウンロードしてインストールするステップ、及びインストールされた更新パッケージを更新して運用するステップ等を示すフロー図である。
【００８９】
図２２を参照すると、携帯端末３０は、５０１ステップのように、第１メモリ２５０の第１領域３１０に第１バージョンＶ１のプログラムを格納している状態である。この時、第１バージョンＶ１は、システムの製造時、第１メモリ２５０にインストールされ、また、システム製造後、基準になる新しいバージョンをダウンロードし、これを基準バージョン情報に設定することもできる。上記のような状態で更新パッケージのダウンロードを通知されると、携帯端末３０は更新サーバ２０から更新パッケージをダウンロードするようになる。すると、携帯端末３０は、５０３ステップ−５０７ステップを行い更新サーバ２０からダウンロードされる更新パッケージを受信して一時格納する。上記のように、一時格納された更新パッケージはメモリにインストールされ、その後の更新時に安定的に使用できるようにする。従って、一時格納された更新パッケージは、不揮発性メモリの第１メモリ２５０にインストールするが、この時、インストール動作は更新パッケージをダウンロードすると同時に即実行でき、また、携帯端末３０の正常の動作モードを実行した後にインストールすることもできる。従って、更新パッケージのダウンロード後、インストール命令が発生しなければ、携帯端末３０は５０９ステップでこれを感知し、５１１ステップで携帯端末３０の正常動作モードへ戻る。上記のような状態で正常モードを実行した後、インストール命令が発生すると、携帯端末３０は、一時格納中の更新パッケージを第１メモリ２５０にインストールする動作を行うようになる。
【００９０】
５０９ステップでインストール命令を感知すると、携帯端末３０は、５１３ステップで第１メモリ２５０にダウンロードされた更新パッケージをインストールする。第１メモリ２５０は、不揮発性メモリであり、バージョンの更新時に基準になる第１バージョンを格納する領域と、複数の更新パッケージを格納する領域とから構成される。すなわち、第１メモリ２５０は、図１３、図１４−図１５のように、第１バージョンのプログラム及び第２バージョンの更新パッケージを格納する第１及び第２領域に割り当てることができる。従って、更新パッケージのダウンロード時、携帯端末３０は、５１３ステップで該当する更新パッケージを格納する領域にダウンロードされた更新パッケージをインストールする。この時、更新パッケージは以前の更新パッケージとは独立的に格納されるため、第１メモリ２５０は、第１バージョンの更新パッケージが生成された順番で格納されており、従って、バージョンの更新ヒストリーを全て格納している状態になる。
【００９１】
更新パッケージを第１メモリ２５０にインストールした後、携帯端末３０はシステム初期化（ｓｙｓｔｅｍ  ｒｅｂｏｏｔ）動作を行うのかを表示する。この時、システム初期化の命令が発生しなければ、携帯端末３０は、５１５ステップでこれを感知し、５１７ステップで正常の動作モードを行う。この場合、動作モードは現在ダウンロードされた更新パッケージによるバージョン更新が実行されていない状態であるため、以前のバージョンのプログラムによって動作モードを行うようになる。
しかし、５１５ステップでシステム再起動命令を感知すると、携帯端末３０は、５２１ステップでシステム初期化動作を実行し、初期化動作の実行後、バージョン更新のため５２３ステップでトランスレータ２４０を駆動する。この時、トランスレータ２４０は、第１メモリ２５０にインストールされた更新パッケージを第１バージョンのプログラムに結合して更新されたプログラムを生成し、生成された更新プログラムを第２メモリ２６０に格納する機能を実行し、これによって携帯端末３０はこれに基づいて動作モードを制御する。携帯端末３０は、５２５ステップで更新パッケージのインストールデータを検査し、更新パッケージの状態を確認する。この時、更新パッケージの状態に異常があると、携帯端末３０は、５３３ステップで更新以前のバージョンプログラム（第２バージョン）又は第１バージョンのプログラムを第２メモリ２６０に格納し、システムの動作を制御する。しかし、更新パッケージが正常状態であれば、携帯端末３０は、５２５ステップでこれを感知し、５２７ステップで第１メモリ２５０にインストールされた当該更新パッケージをロードし、５２９ステップで第１メモリ２５０に格納している第１バージョンのプログラムに、ロードした更新パッケージを組合せて更新されたバージョンのプログラムを生成し、これを第２メモリ２６０に格納する。その後、携帯端末３０は、５３１ステップで第２メモリ２６０に格納されている更新バージョンのプログラムを用いてシステムの動作を制御する。
【００９２】
上記のように、携帯端末機３０は更新パッケージをダウンロードすると、インストールステップ（ｉｎｓｔａｌｌ  ｓｔｅｐ）及び更新ステップ（ｔｒａｎｓｌａｔｉｎｇ  ｓｔｅｐ）を行う。図２３は、携帯端末機３０からダウンロードされる更新パッケージを第１メモリ２５０にインストールするステップを示すフロー図であり、図２４は、携帯端末機３０において第１メモリ２５０にインストールされた更新パッケージを、第１バージョンに更新して第２メモリ２６０に格納した後、システムを運用するステップを示すフロー図である。
【００９３】
図２３を参照すると、ダウンロードの必要時、携帯端末３０は、６０１ステップでダウンローダ（ｄｏｗｎ  ｌｏａｄｅｒ）を実行し、６０３ステップでネットワークを介して更新サーバ２０から伝送される更新パッケージをダウンロードする。この時、更新パッケージのダウンロードは携帯端末３０の通信リンクによって変わる。すなわち、携帯端末３０が移動通信端末であれば、携帯端末３０は設定される無線リンク（例えば、ＣＤＭＡ、ＵＭＴＳ、ＧＳＭ、ＧＰＲＳ等）を介して更新パッケージをダウンロードすることができ、インターネットを介して接続される端末であれば、無線インターネット（ｗｉｂｒｏ、ｗｉｆｉ、ｗｉｍａｘ、無線ＬＡＮ等）によって更新パッケージをダウンロードすることができる。また、ＵＳＢのような有線通信リンク又はブルートゥース等のような近距離通信リンクを介してシステムに接続される端末の場合には、当該有線通信方法又は近距離無線通信方法によって更新パッケージをダウンロードすることができる。この時、ダウンロードは、更新パッケージ全体がダウンロードされる時まで続き、ダウンロード中にエラーが発生すると携帯端末３０は６０５ステップでこれを感知し、６０７ステップ及び６０９ステップを行い更新パッケージの再ダウンロードを行う。
【００９４】
６０５ステップで正常にダウンロードを完了した場合、携帯端末３０は、６１１ステップでインストーラ（ｉｎｓｔａｌｌｅｒ）をロードし、更新パッケージを第１メモリ２５０にインストールする準備をする。更新パッケージを第１メモリ２５０にインストールするステップを説明すると、携帯端末３０は、６１３ステップ−６１７ステップで更新パッケージのヒストリーデータを抽出し、抽出されたヒストリーデータを確認した後、第１メモリ２５０の当該更新パッケージ格納領域内のヒストリーテーブルに格納する。
【００９５】
その後、携帯端末３０は、更新パッケージ内にマップデータが含まれているのかを検査する。この時、更新パッケージ内にマップデータが含まれている場合、携帯端末３０は６１９ステップでこれを感知して、６３７ステップ及び６３９ステップで更新パッケージ内からマップデータを抽出し、第１メモリ２５０の当該更新パッケージ格納領域内にマップデータを格納し、６４１ステップで更新パッケージ格納領域内の更新データ格納領域に更新データを格納する。従って、６３５ステップになると、携帯端末３０は、受信された更新パッケージからヒストリーデータ、マップデータ及び更新データを各々抽出した後、第１メモリ２５０の該当する更新パッケージ格納領域内にヒストリーデータ、マップデータ及び更新データをインストールして格納している状態になる。
【００９６】
また、更新パッケージ内にマップデータが含まれていない場合、携帯端末３０は、６１９ステップでこれを感知し、６２１ステップ及び６２３ステップで圧縮解除器を駆動し更新パッケージから更新データを抽出して圧縮を解除する。その後、携帯端末３０は、６２５ステップ−６２９ステップを行いながら圧縮解除された更新データをパースした後、これを第１メモリ２５０に格納している第１バージョンと比較して差異データを求め、これに基づいて、更新データを第１バージョンにマッピングするためのマップデータを生成する。その後、携帯端末３０は、６３１ステップ及び６３３ステップで、第１メモリ２５０に割り当てられた更新パッケージの格納領域に、生成されたマップデータ及び更新データを各々格納する。
【００９７】
また、６２５ステップで圧縮解除した更新データがマップデータの情報を含む場合、インストーラ２３０はマップデータを生成しないこともある。すなわち、更新データが、図３ｆのようにマップデータを含む場合にはマップデータを生成するステップを省略することができる。図３ｆの場合、更新データは第２バージョンプログラムの各ブロックに対するコマンド（コピー、変更、シフト）及び当該ブロックのインデックス情報を含んでいる。この場合、更新データがマップデータを含んでいるため、マップデータを生成しないこともある。この場合、６２７ステップ−６３３ステップの動作は省略することができる。
【００９８】
上記のように、携帯端末３０は、更新パッケージのダウンロードが通知されると更新パッケージをダウンロードし、ダウンロードされた更新パッケージを分析して、第１メモリ２５０の対応する領域にそれぞれヒストリーデータ、マップデータ及び更新データをインストールする。この時、マップデータは、更新パッケージに含まれることもあり、含まれないこともある。更新パッケージにマップデータが含まれていない場合、携帯端末３０は、第１メモリ２５０に格納し、基準バージョンの第１バージョンとダウンロードされた更新データを比較してマップデータを生成し、生成されたデータを更新パッケージ格納領域にインストールする。また、上記のように、更新データがマップデータを含む場合、更新データからマップデータを生成せずにそのまま格納することもできる。
【００９９】
図２４は、図２２のプログラム更新方法におけるバージョン更新ステップを示したフロー図である。
【０１００】
図２４を参照すると、更新パッケージを用いて携帯端末３０のバージョンを更新するステップは、システムの電源オン又はユーザの更新要求によって実行される。すなわち、本発明の実施形態に係る携帯端末３０は、システム初期化時にハードウェア等の初期化を実行した後、第１メモリ２５０に格納された第１バージョン及び最も最近更新された更新パッケージ（又は、ユーザによって設定された更新パッケージ）を組合せて更新されたプログラムを第２メモリ２６０に格納し、これを用いてシステムの動作を制御する。ここで、第２メモリ２６０に格納されるプログラムは、システムプログラム、動作コード、ソフトウェア等、不揮発性メモリにインストールできる全てのプログラムを含む。
【０１０１】
従って、システム初期化動作が実行されると、携帯端末３０は、６５１ステップ−６５５ステップを行いながらシステム初期化を実行した後、第１メモリ２５０から第１バージョンのプログラム及び更新パッケージをロードするためのローダを実行する。その後、携帯端末３０は、６５７ステップで第１メモリ２５０内の更新パッケージ格納領域を分析し、更新パッケージが一つ以上格納されているかを検査する。この時、更新パッケージが格納されていない場合、携帯端末３０は、６５７ステップでこれを感知し、６５９ステップで更新ステップを行うためのトランスレータ２４０をロードして、６６１ステップでセキュリティを検査する。その後、携帯端末３０は、６６３ステップで第１メモリ２５０に格納されている第１バージョンが圧縮された状態であるかを検査し、圧縮された状態であれば６６５ステップで圧縮解除器を駆動して第１バージョンの圧縮を解除した後、６６７ステップで第１バージョンを第２メモリ２６０に格納し、６６９ステップで第２メモリ２６０に格納された第１バージョンのプログラムを用いてシステムを運用する。しかし、６６３ステップで第１バージョンが圧縮されていないと判定されれば、携帯端末３０は、６６７ステップ及び６６９ステップを行いながら第１バージョンのプログラムを第２メモリに格納し、これを用いてシステムを運用する。
【０１０２】
しかし、６５７ステップで一つ以上の更新パッケージが第１メモリ２５０に格納されていることを感知すると、携帯端末３０は、６７１ステップでトランスレータ２４０をロードした後、６７３ステップで最も最近更新された更新パッケージをロードする。この時、第１メモリ２５０にインストールされた更新パッケージは、ヒストリーデータ、マップデータ及び更新データ、又は、ヒストリーデータ及びマップデータ、又は、ヒストリーデータ及び更新データ等から構成される。その後、携帯端末３０は、６７５ステップで圧縮解除器を駆動してロードされた更新パッケージ（ここで、更新データのみ圧縮されていることもある）の圧縮を解除し、６７７ステップでセキュリティ検査をする。その後、携帯端末３０は、６７９ステップで第１メモリ２５０に格納されている第１バージョンのプログラムが圧縮された状態であるかを検査し、圧縮された状態であれば６８１ステップで圧縮解除器を駆動して第１バージョンプログラムの圧縮を解除した後、６８３ステップで第１バージョンのプログラムに更新パッケージを結合して更新されたバージョンのプログラムを生成した後、これを第２メモリに格納し、６６９ステップで第２メモリ２６０に更新されたバージョンのプログラムを用いてシステムを運用する。この時、６８３ステップで更新パッケージの更新データを第１バージョンに更新する時、マップデータを用いて更新データを第１バージョンにマッピングする。また、６７９ステップで第１バージョンのプログラムが圧縮されていないと判定されれば、携帯端末３０は、６８３ステップ及び６６９ステップを行いながら第１バージョンのプログラムに更新パッケージを結合して更新バージョンのプログラムを生成した後、これを第２メモリに格納し、これを用いてシステムを運用する。
【０１０３】
図２５−図３１は、本発明の他の実施形態に係るプログラム更新方法を示すフロー図である。本発明の実施形態において、携帯端末３０は更新サーバ２０から更新パッケージをダウンロードし、ダウンロードした更新パッケージを不揮発性メモリにインストールし、更新必要時、インストールされた更新パッケージを基準バージョンのプログラムに結合して更新されたプログラムを生成した後、これを用いて携帯端末３０の動作を制御する。
ここで、図２５は、更新パッケージをダウンロードしてインストールするステップを示しており、図２６は、インストールされた更新パッケージをトランスレートするステップを示しており、図２７は、最も最近インストールされた更新パッケージが正常状態でない場合に、他の更新パッケージを選択した後トランスレートするステップを示しており、図２８は、インストールされた全ての更新パッケージが正常状態でない場合に、最初バージョンの第１バージョンをトランスレートするステップを示しており、図２９は、更新パッケージのダウンロード又はインストール機能を選択しなかった場合、次のシステム初期化状態で、再び更新パッケージをダウンロード又はインストール機能を行うかを確認するステップを示しており、図３０は、更新パッケージをインストールした後トランスレートしなかった場合に、次のシステム初期化の時点で、インストール状態であることを表示するようにして、待機モードへ進行するステップを示しており、図３１は、システム初期化の後、以前の状態で要求されたダウンロード又はインストールされていない更新パッケージを処理するステップを示している。
【０１０４】
図２５−図３１を参照すると、まず、更新サーバ２０から更新パッケージが生成されたことを通知されると、携帯端末３０は７０１ステップでこれを感知し、表示部（図示せず）に更新パッケージをダウンロードするか否かを問うメッセージを表示する。この時、携帯端末のユーザがダウンロードを要求する入力をすると、携帯端末３０はこれを感知し、７０３ステップで更新サーバ２０に更新パッケージのダウンロードを要請する。すると、更新サーバ２０は更新パッケージをダウンロードし、携帯端末３０は、７０５ステップからダウンロードされる状態を表示部に表示し、更新パッケージをダウンロードする。この時、携帯端末３０は、ダウンロードされる更新パッケージをメモリに一時格納するが、この時、メモリは揮発性メモリであって第２メモリ２６０である。更新パッケージのダウンロードが完了すると、携帯端末３０は、７０７ステップでダウンロードの完了を表示し、ダウンロードされた更新パッケージをインストールするかを問うメッセージを表示する。
【０１０５】
この時、ダウンロードされた更新パッケージは一時格納された状態である。従って、更新パッケージは、第１メモリ２５０の第２領域３２０にインストールされる。上記のように、更新パッケージを第１メモリ２５０にインストールする理由は、更新の必要の度に、第１バージョンに更新パッケージを組合せて更新バージョンのプログラムを生成しなければならないためである。すなわち、更新パッケージは、安定した状態で格納されて反復的に更新バージョンのプログラムを生成する時に使用され、従って、更新パッケージは不揮発性メモリの第１メモリ２５０にインストールされるべきである。
【０１０６】
従って、７０７ステップで、携帯端末３０の表示部にインストールするかを問うメッセージを表示した状態でユーザがインストールすると設定すると、携帯端末３０はこれを感知し、７１１ステップへ進行して更新パッケージに含まれたインストールデータを確認する。この時、インストールデータは、ヒストリーデータ又はヒストリーデータ及びマップデータ等から構成される。ここで、ヒストリーデータは、図１５に示すように、該当する第２バージョンの識別情報及び更新データを結合する基準バージョン（ここでは、第１バージョン）の識別情報を含んでいる。また、マップデータは、更新データを第１バージョンにマッピングするためのコマンド及びブロックのインデックス情報である。この時、マップデータは、上記のように、更新パッケージを生成する時にマップデータを共に生成して合成することができ、また、マップデータを生成せずにヒストリーデータ及び更新データだけを合成することもできる。従って、携帯端末３０は、７１１ステップで更新パッケージをインストールする前に、バージョン（ここでは、ＶｘバージョンからＶｙバージョンに更新する場合を仮定する）、ＣＲＣ及びマップデータ等を検査する。
【０１０７】
この時、７１１ステップの検査で、更新バージョンがＶｘ→Ｖｙであり、ＣＲＣは正常であり、マップデータが存在する場合、携帯端末３０のインストーラ２３０は、７１３ステップでこれを確認し、７１５ステップで図１３及び図１４のような更新パッケージを格納する第１メモリ２５０の第２領域３２０で、該当する更新パッケージのヒストリーデータを格納する領域にダウンロードされた更新パッケージのヒストリーデータをインストールし、７１７ステップでマップデータを格納する領域にダウンロードされた更新パッケージのマップデータをインストールし、７１９ステップで更新データを格納する領域にダウンロードされた更新パッケージの更新データをインストールする。この時、更新パッケージのマップデータが更新データを含む場合、インストーラ２３０は、７１３ステップでこれを感知し、更新パッケージの格納する領域に更新データを格納しない。すなわち、ダウンロードされた更新パッケージのインストール要求が発生すると、携帯端末３０のインストーラ２３０は、更新パッケージから各々ヒストリーデータ、マップデータ及び更新データを抽出し、抽出されたデータを第１メモリ２５０の第２領域３２０の割り当てられた領域にインストールする。
【０１０８】
また、７１１ステップの検査で、更新バージョンがＶｘ→Ｖｙであり、ＣＲＣは正常で、マップデータが存在しない場合、携帯端末３０は、７２１ステップでこれを確認し、７２３ステップで図１３及び図１４のような更新パッケージの格納領域で該当する更新パッケージ格納領域のヒストリーデータを格納する領域に、ダウンロードされた更新パッケージのヒストリーデータをインストールする。そして、携帯端末３０は、７２５ステップで第１メモリ２５０に格納している第１バージョンを（ここでは、Ｖｘ）ロードし、第１バージョンに更新パッケージの更新データをマッピングしながらマップデータを生成する。その後、携帯端末３０は、７２７ステップで、第１メモリ２５０の当該更新パッケージ領域でマップデータを格納する領域に上記のように生成されたマップデータをインストールし、７２９ステップで更新データを格納する領域にダウンロードされた更新パッケージの更新データをインストールする。すなわち、ダウンロードされた更新パッケージのインストール要求が発生すると、携帯端末３０は、マップデータを生成し、ヒストリーデータ、マップデータ及び更新データを第１メモリ２５０の該当する更新パッケージ格納領域に割り当てられた各領域にインストールする。また、更新データが、図３ｆのように、マップデータの情報を含めば、携帯端末３０のインストーラ２３０はマップデータを生成せずに更新データをそのままインストールすることができる。すなわち、更新データが、第２バージョンプログラムと第１バージョンプログラム間のブロックデータのコマンド及びこれらの各々によるブロックインデックス値を含んでいる場合、インストールステップからマップデータの生成ステップを省略することができる。
【０１０９】
この時、第１メモリ２５０にインストールされる更新パッケージ（又は、更新データのみ）は圧縮されて格納される。これは、第１メモリ２５０に格納される更新パッケージのメモリ容量を減少させ、第１メモリ２５０を効率的に使用するためである。第１メモリ２５０は、図１３に示すように、携帯端末の製造時又は基準バージョンでインストールされた第１バージョンのプログラムを格納しており、複数個の更新パッケージを格納することができる更新パッケージ領域が割り当てられている。従って、上記のように、第１メモリ２５０に更新パッケージをダウンロードする時、以前にインストールされた更新パッケージ格納領域にインストールせず、空いている格納領域又は空いている更新パッケージ格納領域がなければ、最も先にインストールされた更新パッケージ格納領域にインストールする。従って、携帯端末３０は、第１バージョン及び最近インストールされた複数の第２バージョンの更新パッケージを保管することができ、バージョンプログラムの更新時にエラーが発生しても、他のバージョンを用いて更新することができるため、フォールトトレラントが良好になる。
【０１１０】
上記のように、ダウンロードされた更新パッケージを第１メモリ２６０の該当する更新パッケージ領域にインストール完了すると、携帯端末３０は、７３１ステップでこれを感知し、７３３ステップでシステム初期化動作を行い、インストールされた更新パッケージでバージョンを更新するかを表示する。この時、ユーザがシステム初期化（ｐｏｗｅｒ  ｒｅｓｅｔ）を要求すると、携帯端末３０は、７４１ステップへ進行して携帯端末３０の電源オンリセット動作を行う。
【０１１１】
図２６を参照すると、本発明の実施形態に係る携帯端末は、システム電源オン命令が発生すると、７４１ステップでシステム電源オン機能を行いながらシステム初期化機能を行う。この時、システム初期化機能は、システムのハードウェアを初期化させる状態を意味する。その後、携帯端末は、７４３ステップ及び７４５ステップを行いながらシステムプログラムの更新を表示した後、表示された更新パッケージをトランスレートして第２メモリ２７０にブーティングする。すなわち、携帯端末３０のトランスレータ２４０は、第１バージョンのプログラムに第２バージョンの更新パッケージを結合して更新された第２バージョンのプログラムを生成し、生成された第２バージョンのプログラムを第２メモリ２６０に格納する。
【０１１２】
ここで、携帯端末３０が、第２バージョンを生成するステップを説明すると、更新パッケージがマップデータを含む場合、マップデータは表１−表４のような構造を有することができる。この場合、受信システム３０のトランスレータ２４０は、表１、表２及び表４のようなマップデータの場合、第１バージョンＶ１に更新パッケージのマップデータを結合して第２バージョンＶ２のプログラムを生成する。すなわち、表１のようなマップデータ｛Ｃ：０，１５，Ｆ：０，ｎｕｌｌ，ｎｕｌｌ｝、｛Ｍ：１６，４  Ｆ：１，（１６−１２），（１７−１３），（１８−８），（１９−９），０，０，０，０｝、｛Ｓ：２０，５，Ｆ：０，（２０−４），０｝であれば、Ｃ、Ｍ、Ｓコマンドによってマップデータに含まれたブロックインデックスに対応する第１バージョンＶ１のブロックデータを、対応する第２バージョンＶ２のブロックデータとして格納する。この場合、受信システム３００は、第２バージョンＶ２の０番から１５番までのブロックは第１バージョンＶ１のブロック０番から１５番までのブロックデータを格納し、ブロック１６番から１９番までのブロックは第１バージョンＶ１のブロック１２、１３、８、９番ブロックデータを各々格納し、ブロック２０番から２４番までのブロックは第１バージョンＶ１のブロック１６番から２０番までのブロックデータを格納する。
【０１１３】
表２のマップデータ｛Ｃ：０，１５，Ｆ：０，ｎｕｌｌ，ｎｕｌｌ｝、｛Ｍ：１６，４  Ｆ：１，（１６−１２），（１７−１３），（１８−８），（１９−９），０，ｃｏｄｅ（Ｂ，Ｋ），ｃｏｄｅ（Ｅ，Ｃ），０｝、｛Ｓ：２０，５，Ｆ：０，（２０−４），０｝であれば、受信システム３０では、Ｃ及びＳコマンドによる第２バージョンＶ２のブロックは、マップデータに対応するブロックインデックスの第１バージョンＶ１のブロックデータを、対応する第２バージョンのブロックデータとして格納する。そして、Ｍコマンドによる第２バージョンのブロックは、マップデータに含まれたブロックインデックス及びエントロピー符号化されたデータを用いてブロックデータを生成する。この場合、受信システム３０は、第２バージョンＶ２の０番でから１５番ブロックは第１バージョンＶ１のブロック０番でから１５番ブロックデータを格納し、ブロック１６から１９番ブロックは第１バージョンＶ１のブロック１２、ｃｏｄｅ（Ｂ，Ｋ）、ｃｏｄｅ（Ｅ，Ｃ）、９番ブロックデータを各々格納し、ブロック２０番から２４番までのブロックは第１バージョンＶ１のブロック１６番から２０番までのブロックデータを格納する。ここで、コード（Ｂ，Ｋ）とは、第１バージョンＶ１の１３番ブロックデータと第２バージョンＶ２の１７番ブロックデータとの差異をエントロピー符号化したデータを意味し、コード（Ｅ，Ｃ）とは、第１バージョン８番のブロックデータと第２バージョンＶ２の１８番ブロックデータとの差異をエントロピー符号化したデータを意味する。
【０１１４】
そして、表３のようなマップデータ｛Ｃ：０，１５，Ｆ：０，ｎｕｌｌ，ｎｕｌｌ｝、｛Ｍ：１６，４，Ｆ：２，ｎｕｌｌ，ｎｕｌｌ｝、｛Ｓ：２０，５，Ｆ：０，（２０−４），０｝であれば、受信システム３０では、Ｃ及びＳコマンドによる第２バージョンＶ２のブロックは、マップデータに対応するブロックインデックスの第１バージョンＶ１のブロックデータを、対応する第２バージョンのブロックデータとして格納する。そして、Ｍコマンドによる第２バージョンのブロックは、マップデータに含まれたブロックインデックス値及び更新データの数を確認し、このブロックインデックス値及び更新データの数に基づいて更新データからブロックを取り出してブロックデータを生成する。この場合、受信システム３０では、第２バージョンＶ２の０番から１５番までのブロックは第１バージョンＶ１のブロック０番から１５番までのブロックデータを格納し、ブロック１６から１９番ブロックは更新データで４個のブロックデータを取り出して、各々対応するブロックインデックスのブロックデータとして格納する。この場合、第２バージョンＶ２のブロック１６、１７、１８、１９のブロックデータはＺ、Ｗ、Ｐ、Ｘになる。
【０１１５】
また、マップデータなしでヒストリーデータ及び更新データだけで構成された更新パッケージが受信された場合、受信システム３０は、更新データ及び第１バージョンＶ１のプログラムを比較分析してマップデータを生成することがあり、また、更新データが、表５のように、第１バージョンＶ１のブロックインデックス情報｛Ｃ：０，６｝、｛Ｍ：６，２，Ｘ，Ｙ｝、｛Ｓ：８，３，６，｝、｛Ｓ：１１，２，１３｝、｛Ｍ：１３，５，Ａ，Ｂ，Ｃ，Ｄ，Ｅ｝、｛Ｓ：１８，７，１５｝を含んでいる場合には、マップデータの生成を省略することもできる。この場合、受信システム３０は、更新データを用いて第２バージョンＶ２のプログラムを生成することもできる。表５のような更新データであれば、受信システム３０は、第２バージョンＶ２の０番から５番までのブロックは第１バージョンＶ１の０番から５番までのブロックデータとして格納し、６番及び７番ブロックはＸ、Ｙデータとして格納し、８番から１０番までのブロックは第１バージョンの６番から８番までのブロックデータとして格納し、１１番及び１２番ブロックデータは第１バージョンＶ１の１３番及び１４番ブロックデータとして格納し、１３番から１７番までのブロックは各々Ａ、Ｂ、Ｃ、Ｄ、Ｅとして格納し、１８番から２４番までのブロックは第１バージョンＶ１の１５番から２１番までのブロックデータとして格納する。
【０１１６】
この時、更新パッケージを第１メモリ２５０にインストールした後、最初のシステム電源オンが行われた場合、携帯端末は、７４３ステップでバージョンがＶｘからＶｚに変更されることを設定時間の間表示（ここでは、２秒と仮定する）し、７４５ステップでＶｚバージョンを有する更新パッケージを第１バージョンに適用して（すなわち、トランスレート）更新された第２バージョンを生成し、これを第２メモリ２６０に格納する。その後、携帯端末は、７４７ステップへ進行して携帯端末の待機モード（ｉｄｌｅ  ｍｏｄｅ）を実行する。
【０１１７】
上記のように、システム電源オン機能が設定されると、携帯端末３０は、第１メモリ２５０からインストールされた第１バージョンのプログラム及び第２バージョンの更新パッケージをロードし、第１バージョンのプログラム及び第２バージョンの更新パッケージを結合してプログラムを生成した後、これを第２メモリ２６０に格納し、その後、第２メモリ２６０に格納された更新プログラムによって端末の駆動を制御する。この時、携帯端末は、最も最近のバージョンの更新パッケージをロードして更新し、この時、携帯端末の更新ステップは、図２６に示すように、第１バージョン及び更新パッケージをロードし、ロードされた第１バージョンに更新パッケージを適用して、更新されたバージョンの第２バージョンを生成し、これを第２メモリ２６０に格納した後、これを用いて携帯端末の動作を制御する。
【０１１８】
しかし、最も最近のバージョンの更新パッケージに異常が発生した場合、携帯端末は、第１メモリ２５０にインストールされた他の更新パッケージを選択して更新されたバージョンのプログラムを生成する。本発明の実施形態に係る携帯端末は、ダウンロードされた更新パッケージを不揮発性メモリにインストールし、システム初期化時、インストールされた更新パッケージ中、最も最近のバージョンを有する更新パッケージ又はユーザによって設定される更新パッケージを選択して第２メモリにブーティングする。従って、本発明の実施形態では、更新パッケージに異常が発生した場合にも、最適の更新パッケージを選択して携帯端末をブーティングすることができる。従って、７５３ステップで最も最近の更新バージョンを有する更新パッケージに異常が発生した場合（図２７では、最も最近のバージョン番号５（Ｖ＃５）の場合を仮定している）、携帯端末は、７５５ステップで表示部にユーザのバージョン選択を表示し、ユーザの選択によるバージョンの更新パッケージを処理する。この時、ユーザは、更新パッケージのバージョンを選択することができるが、選択しなくても構わない。
【０１１９】
この時、携帯端末のユーザがバージョン選択機能を選択すると、７５５ステップでこれを感知し、７５７ステップでユーザが選択できるバージョンを表示部に表示する（例えばＶ＃４、Ｖ＃３、Ｖ＃２の場合）。上記のような状態で、ユーザが第２バージョンの特定のバージョン番号を選択すると、携帯端末３０は、７５９ステップでこれを感知し、７６１ステップで選択されたバージョンの更新パッケージをロードし、７６３ステップで第１バージョンにロードされた更新パッケージを結合して更新された第２バージョンのプログラムを生成する。この時、生成された第２バージョンは、第２メモリ２６０に格納され、その後、携帯端末は、第２メモリ２６０に格納された第２バージョンを用いて携帯端末の全般的な動作及び機能の実行を制御する。上記のように生成された第２バージョンのプログラムを第２メモリ２６０に格納した後、携帯端末は、７６５ステップで待機モードに切り換え、次の動作モードに備える。
【０１２０】
しかし、７５５ステップでユーザがバージョン選択命令をしなければ、携帯端末は、７６７ステップ及び７６９ステップで異常が発生したバージョンを除いた最も最近のバージョン（ここでは、ｖｅｒｓｉｏｎ＃４になる）の更新パッケージを選択及びロードした後、７７１ステップでロードしたバージョンの更新パッケージでシステムのバージョンを上記のような方法で更新して第２メモリ２６０に格納した後、７７３ステップの待機モードへ進行する。すなわち、最も最近のバージョンに異常が発生した状態でユーザのバージョン選択機能が設定されなかった場合、携帯端末は、第１メモリ２５０にインストールされた正常の更新パッケージ中、最も最近の更新パッケージをロードして更新バージョンを生成し、これを用いて携帯端末の動作を制御する。
【０１２１】
図２８は、携帯端末が、第１メモリ２５０にインストールされた全ての更新パッケージが正常でない場合の動作ステップを示すフロー図である。
【０１２２】
図２８を参照すると、携帯端末は、７８１ステップ及び７８３ステップで第１メモリ２５０にインストールされた全ての更新パッケージの異常状態を感知すると、７８５ステップ−７８９ステップを行いながら第１メモリ２５０にインストールされた第１バージョンをロードした後、これを第２メモリ２６０に格納し、これを用いて携帯端末の動作を制御する。上記のように、携帯端末にインストールされた全ての更新パッケージが正常状態でないと、携帯端末は、最初バージョンの第１バージョンをロードして第２メモリ２６０に格納した後、これを用いて携帯端末の動作及び機能を制御する。
【０１２３】
また、更新パッケージをダウンロードするか否かを表示する状態又はダウンロードされた更新パッケージを、第１メモリ２５０にインストールするか否かを問うメッセージを表示する状態で、ユーザがダウンロード又はインストール機能を選択しなかった場合、携帯端末は、これを感知し、図２９の８２１ステップで次のシステム初期化状態（ｎｅｘｔ  ｂｏｏｔ  ｕｐ  ｔｉｍｅ）で、ユーザが当該機能の実行の要否を選択できるように表示する機能を設定し、８２３ステップで待機モードに切り換える。すなわち、更新パッケージのダウンロード又はインストール機能が選択されなければ、携帯端末３０は、次のブーティング時点で、再びユーザにダウンロード又はインストールするか否かを確認するメッセージを表示するように設定した後、待機モードへ進行して次の動作に備える。すなわち、待機状態でシステム初期化機能が実行されれば、携帯端末は、更新パッケージのダウンロード又はインストールの実行の要否を案内する。
【０１２４】
また、更新パッケージを第１メモリ２５０にインストールした後、トランスレートするか否かを問う状態で、ユーザがトランスレート機能を選択しなかった場合、携帯端末は、これを感知し、図３０の８３１ステップで次のシステム初期化時、現在インストールされた更新パッケージを適用できるように設定し、８３３ステップで携帯端末の待機モードへ進行する。この時、待機モードで携帯端末の初期化動作が実行されれば、携帯端末は、インストールされた最も最近の更新パッケージを用いて携帯端末３０のシステムプログラムを更新する。従って、最も最近の更新パッケージをインストールした後、トランスレート機能を行わなかった場合、システム電源オンする時点で、最も最近の更新パッケージを用いてシステムプログラムをバージョンアップさせた後、次の機能を行うようになる。
【０１２５】
上記のように、生成された更新パッケージをダウンロード、インストール又はトランスレートしていない場合、携帯端末は、次の電源オン時点で、更新パッケージのダウンロード又はインストールの有無を案内する。図３１を参照すると、システム電源オン命令の発生時、携帯端末は、８０３ステップで携帯端末に電源を供給し、初期化機能を行う。その後、携帯端末は、８０５ステップでブーティング機能を行う。この時、携帯端末は、第１メモリ２５０にインストールされた最も最近のバージョンの更新パッケージをロードしてシステムプログラムを更新する。従って、以前の状態でインストール後、更新されていない場合、次のシステム電源オン時点で、新しい更新パッケージによってシステムプログラムが更新されるようになることが分かる。上記のようなブーティング動作を行った後、携帯端末は、８０７ステップで待機モードに切り換え、待機モードで以前の状態でダウンロード又はインストールする更新パッケージがあったか否かを検査する。この時、８０９ステップでダウンロードする更新パッケージが以前の状態であることを感知すると、携帯端末は、８１１ステップで更新パッケージをダウンロードするか否か問うメッセージを表示部に表示し、ユーザがダウンロードを選択すれば、図２５の７０５ステップへ進行して当該更新パッケージをダウンロードするステップを実行し、ユーザがダウンロードを選択しなれば、図２９の８２１ステップへ進行して次の電源オン時点で、再び問うように設定する。また、８１３ステップでインストールする更新パッケージがあることを感知すると、携帯端末は、８１５ステップでダウンロードされた更新パッケージをインストールするか否かを問うメッセージを表示部に表し、ユーザがインストールを選択すれば、図２５の７０１ステップへ進行して当該更新パッケージを第１メモリ２５０にインストールするステップを実行し、ユーザがインストール機能を選択しなければ、図２９の８２１ステップへ進行して次の電源オン時点で、再び問うように設定する。
【０１２６】
上記のように、本発明の実施形態に係る携帯端末３０は、不揮発性メモリの第１メモリ２５０を備え、第１メモリ２５０は最初バージョンである第１バージョンを格納している。この時、第１バージョンは、携帯端末の製造時に製造会社がインストールするバージョンである。その後、携帯端末は、バージョンが更新される度にダウンロードされる更新パッケージを第１メモリ２５０にインストールし、この時、第１メモリ２５０は、更新パッケージを格納できる領域が割り当てられており、このような格納領域は複数備えられており、複数の更新パッケージをインストールすることができる。この時、更新パッケージは更新されたバージョンであって、携帯端末の第１バージョンに更新データが含まれた情報であり、また、第１バージョンとの差異のある更新データを備える更新パッケージである。本発明の実施形態において、更新パッケージは後者の場合となる。
【０１２７】
また、本発明の実施形態に係る携帯端末は、第２メモリ２６０を備え、ここで、第２メモリ２６０は、揮発性メモリであり携帯端末のワークメモリ（ｗｏｒｋ  ｍｅｍｏｒｙ）である。携帯端末は、システム電源オン時、システムのハードウェア初期化動作を行い、ソフトウェアブーティングを実行する時、第１メモリ２５０から第１バージョン及び最も最近の更新パッケージをロードし、第１バージョンに更新パッケージを結合して更新されたバージョンのプログラムを生成（ｔｒａｎｓｌａｔｉｎｇ）し、これを第２メモリ２６０に格納する。その後、携帯端末は、第２メモリ２６０に格納された更新バージョンのプログラムを用いて動作及び機能を行う。
また、本発明の実施形態において、更新パッケージのダウンロード、インストール及びトランスレートは、当該イベントが発生する時点ですぐに行なうことができ、また、当該イベントの処理時点を次のシステム初期化の時点まで待機した後、行うこともできる。
図３２は、本発明の実施形態に係る更新パッケージをダウンロードしてインストール及びブーティングする携帯端末の構成例であって、携帯端末が携帯電話の場合の構成を示している。
【０１２８】
図３２を参照すると、携帯端末は、ＲＦ通信部９３０、表示部９５０、キー入力部９４０、通信インターフェース９５０、第１メモリ２５０、及び第２メモリ２６０を含む。ＲＦ通信部９３０は携帯電話の無線通信機能を行う。ＲＦ通信部９３０は、送信される信号の周波数を上昇変換及び増幅するＲＦ送信機と、受信される信号を低雑音増幅して周波数を下降変換するＲＦ受信機等を含む。キー入力部９４０は、数字及び文字情報を入力するためのキー及び各種機能を設定するための機能キーを備える。
【０１２９】
第１メモリ２５０は不揮発性メモリであり、第１バージョンを格納する第１領域及び少なくとも一つの更新パッケージを格納できる第２領域を備える。ここで、第１領域に格納される第１バージョンのプログラムは、携帯電話の製造時に製造会社でインストールする端末のファームウェア及びソフトウェア等である。第２領域に格納される更新パッケージは、第１バージョンと更新バージョンとの差異に基づく更新パッケージである。ここで、更新パッケージは、更新データ及びヒストリー及びマップデータから構成されるインストールデータを含み、また、マップデータが更新データを含む構造であれば、ヒストリーデータ及びマップデータから構成され、更新データがマップデータを含む構造であれば、ヒストリーデータ及びマップデータから構成される。第１メモリ２５０の第２領域は、一定のサイズの領域で割り当てられ、領域は更新パッケージを格納する領域である。
【０１３０】
第２メモリ２６０は、揮発性メモリであり携帯端末のワークメモリである。第２メモリ２６０は、ブーティング時、第１メモリ２５０の第１領域に格納された第１バージョンに、第２領域に格納された最も最近のバージョンを有する更新パッケージを結合させて生成された第２バージョンを格納し、制御部９００の制御下で第２バージョンのプログラムを用いて携帯端末の動作及び機能を制御する。
【０１３１】
制御部９００は、携帯端末の全般的動作を制御する。また、制御部９００は、コーデック及びモデムを備え、送信される信号を符号化及び変調し、受信される信号を復調及び復号する機能を行う。すなわち、携帯電話の場合、制御部９００がデータ処理及びオーディオ処理器能が一つのチップに集積されたＭＳＭチップになる。また、制御部９００及びデータ処理器能を独立的に構成し、携帯電話機能を制御することもできる。また、本発明の実施形態に係る制御部９００は、更新パッケージサーバ２０から伝送される更新パッケージをダウンロードするダウンローダ２２０、ダウンロードされた更新パッケージを第１メモリ２５０の第２領域の特定格納領域にインストールするインストーラ２３０と、インストールされた第１バージョンのプログラムに更新パッケージを結合して更新バージョンのプログラムを生成した後、これを第２メモリ２６０に格納するトランスレータ２４０の機能を行う。
【０１３２】
表示部９５０は、制御部９００の制御下で携帯端末の表示データを表示する。ここで、表示部９５０は、ＬＣＤを使用することができるが、この場合、表示部９５０は、ＬＣＤ制御部（ＬＣＤ  ｃｏｎｔｒｏｌｌｅｒ）、表示データを格納できるメモリ及びＬＣＤ表示素子等を備える。ここで、ＬＣＤをタッチスクリーン（ｔｏｕｃｈ  ｓｃｒｅｅｎ）方式で具現する場合、入力部として動作することもできる。
【０１３３】
通信インターフェース部９６０は、制御部９００に接続され、外部装置と有線又は無線通信インターフェース機能を行うことができる。通信インターフェース部９６０は、ＵＳＢ等のように有線でコンピュータ等の外部装置と接続され、また、ブルートゥース（ｂｌｕｅｔｏｏｔｈ）及びＩｒＤＡ等のような近距離無線通信インターフェース、Ｗｉｂｒｏ、Ｗｉｆｉ、Ｗｉｍａｘ等のような無線インターネットインターフェースも可能である。
【０１３４】
図３２のような構成を有する携帯電話において、更新パッケージをダウンロード、インストール及びブーティングするステップを説明すると、携帯電話の制御部９００は、ＲＦ通信部９３０によって基地局とＲＦ無線通信機能を実行することができ、この時のＲＦ無線通信方法は、上記のようにＣＤＭＡ、ＵＭＴＳ、ＧＳＭ等の通信方法である。そして、基地局は通信ネットワークによって更新パッケージサーバ２０と接続される。また、携帯電話の通信インターフェース部９６０は、インターネットを介して更新パッケージサーバ２０と接続される。この時、更新パッケージサーバ２０から更新パッケージが生成されたことが通知されると、制御部９００は、ＲＦ通信部９３０を介して更新パッケージのダウンロードを要求し、すると、更新パッケージサーバ２０は、生成された更新パッケージをダウンロードする。すると、更新パッケージは、基地局によって公衆無線網に適した形態の無線データ（例えば、ＣＤＭＡ、ＵＭＴＳ、ｏｒ  ＧＳＭ  ｆｏｒｍａｔのＲＦ  ｄａｔａ）に変換され、制御部９００はこれをＲＦ通信部９３０を介して受信し一時格納する。この時、制御部９００は、ダウンロードされた更新パッケージを第２メモリ２６０に一時格納する。
【０１３５】
しかし、第２メモリ２６０は揮発性メモリであるため、第２メモリ２６０に格納される更新パッケージは、不揮発性メモリの第１メモリ２５０にインストールしてこそ更新パッケージを安全に保管することができる。従って、制御部９００は、更新パッケージをダウンロードした後、表示部９５０に更新パッケージのダウンロードを表示し、インストールするか否かの選択を案内するメッセージを表示する。この時、携帯電話のユーザがインストール機能を選択すれば、制御部９００は、一時格納中の更新パッケージを第１メモリ２５０の第２領域中、空領域（空領域がなければ、最も先にインストールされた更新パッケージがインストールされた領域）にダウンロードされた更新パッケージをインストールする。この時、更新パッケージは、更新データとインストールデータとから構成され、インストールデータはヒストリーデータとマップデータとから構成される。この時、マップデータは、ダウンロードされる更新パッケージに含まれることもあり、含まれないこともある。従って、制御部９００は、更新パッケージを分析してマップデータが含まれていない更新パッケージであれば、更新パッケージと第１バージョンを比較してマップデータを生成した後、更新パッケージのインストール時に生成されたマップデータを同時にインストールする。また、マップデータを含んでいないが、更新データにマップデータの機能を含んでいる更新パッケージが受信された場合、インストーラ２３０は、マップデータを生成せずに第１メモリ２５０の当該更新パッケージ格納領域に、更新データ及びヒストリーデータを更新パッケージとしてインストールする。また、更新データを含んでいないが、マップデータが更新データを含んでいれば、インストーラ２３０は、第１メモリ２５０の該当する更新パッケージ領域にヒストリーデータ及びマップデータをインストールする。
【０１３６】
しかし、更新パッケージをダウンロードした状態で、ユーザがインストール機能を選択しなければ、制御部９００はこれを記憶して次のシステム電源オン時、ダウンロードされた更新パッケージがあることを表示する。この時、ユーザがインストール機能を選択すると、携帯電話は、更新パッケージが一時格納中の状態であれば、格納中の更新パッケージを第１メモリ２５０にインストールし、更新パッケージを格納していない状態であれば、更新パッケージサーバ２０に更新パッケージのダウンロードを要求し、ダウンロードされた更新パッケージを第１メモリ２５０にインストールする。従って、更新パッケージをダウンロードした後、更新パッケージを第１メモリ２５０にインストールしていない場合、制御部１００は、更新パッケージのインストールするのか否かを設定するように反復して案内し、ユーザは、これによって更新パッケージを公衆無線網を介してダウンロードしてインストールすることができる。
【０１３７】
更新パッケージが第１メモリ２５０にインストールされると、更新パッケージは永久的に保管できる状態になる。上記のような状態で、システム初期化の後、ブーティングステップで制御部９００は、第１メモリ２５０から第１バージョンプログラム及び最も最近の更新パッケージをロードし、ロードされた第１バージョンプログラムに更新パッケージをマッピングさせて第２バージョンの更新プログラムを生成した後、これを第２メモリ２６０に格納する。すなわち、制御部９００は、最も最近の更新パッケージをロードした後、まずヒストリーデータを分析してバージョン番号及び結合するバージョンを確認し、結合するバージョン（ここでは、第１バージョン）をロードした後、更新データをインストールデータのマップデータを用いて結合することによって、更新された第２バージョンのプログラムを生成し、生成された第２バージョンのプログラムを第２メモリ２６０に格納する。その後、携帯電話は、第２メモリ２６０に格納されたファームウェア及びソフトウェア等によって携帯電話の該当する動作及び機能等を実行する。
【０１３８】
上記のような携帯端末の更新方法は、ＲＦ通信部９３０以外に通信インターフェース部９６０によっても可能である。すなわち、携帯電話がＵＳＢ又は近距離無線通信部等によってコンピュータ等の外部装置に接続され、外部装置にダウンロードされた更新パッケージをダウンロードすれば、制御部９００は、上記のようなダウンロード、インストール及びトランスレートステップを行いながら携帯電話のプログラムを更新することができる。
【０１３９】
以上で説明したように、発明を実施するための最良の形態では具体的な実施形態について説明したが、本発明を逸脱しない範囲において、変形可能であることは当然である。従って、本発明の範囲は、説明した実施形態に限定されるものではない。
【図１】
2009544095.tif 000008
【図２】
2009544095.tif 000009
2009544095.tif 000010
【図３】
2009544095.tif 000011
2009544095.tif 000012
【図４】
2009544095.tif 000013
【図５】
2009544095.tif 000014
【図６】
2009544095.tif 000015
【図７】
2009544095.tif 000016
【図８】
2009544095.tif 000017
【図９】
2009544095.tif 000018
【図１０】
2009544095.tif 000019
【図１１】
2009544095.tif 000020
【図１２】
2009544095.tif 000021
【図１３】
2009544095.tif 000022
【図１４】
2009544095.tif 000023
【図１５】
2009544095.tif 000024
【図１６】
2009544095.tif 000025
【図１７】
2009544095.tif 000026
【図１８】
2009544095.tif 000027
【図１９】
2009544095.tif 000028
【図２０】
2009544095.tif 000029
【図２１】
2009544095.tif 000030
【図２２】
2009544095.tif 000031
【図２３】
2009544095.tif 000032
【図２４】
2009544095.tif 000033
【図２５】
2009544095.tif 000034
【図２６】
2009544095.tif 000035
【図２７】
2009544095.tif 000036
【図２８】
2009544095.tif 000037
【図２９】
2009544095.tif 000038
【図３０】
2009544095.tif 000039
【図３１】
2009544095.tif 000040
【図３２】
2009544095.tif 000041
【国際調査報告】
2009544095.tif 000042
2009544095.tif 000043