JP2007515708A - 携帯端末内のデータ更新方法 - Google Patents

Abstract

携帯端末に格納されたデータを第１のデータバージョンから更新データバージョン
に差分的に更新する方法であって、携帯端末に差分的更新命令をロードし、携帯端末
により格納されたデータおよびロードされた差分的更新命令から更新データバージョ
ンを生成することから成り、さらに、携帯端末内に格納されたデータが第１のデータ
バージョンと一致しない１または２以上の汚染された部分を含むかどうかを検出し、
更新データバージョンを生成し、検出された汚染部分を修復することから成ることを
特徴とする。

Description

本発明は携帯端末内に格納されたデータを第１のデータバージョンから更新データバージョンに差分的に更新する方法に関する。

携帯電話、ページャー（pager）、エレクトロニック・オーガナイザー（electronic organiser）、スマートフォン（smart phone）、ＰＤＡ（personal digital assistant）などの携帯端末は、ソフトウェア依存型の装置であり、その傾向はますます強まっている。その結果、携帯端末に格納されたソフトウェアの適切なバージョン管理と機能の更新が必要となっている。将来においては、ソフトウェアバグの修正とスタンダードな更新が携帯端末のライフサイクルの当たり前の部分となり、端末の機能を適切に保つための要求項目となるであろう。現在、このような携帯端末のユーザは、新しいシステムのバージョンをアップロードし更新するためには、典型的には、端末をワイヤケーブルでコンピュータに接続できる更新センターを訪問する必要がある。

多くの点から見て、これは満足の行く解決策ではない。端末メーカーにとっては高価につくものであり、ユーザにとっては迷惑な話である。したがって、顧客が実際に更新センターを訪問しなければならないような事態を回避できることが好ましい。さらに、上記解決策は更新時間に不必要に時間がかかるという不利益もある。というのも、現状では、更新のたびに必要であるか、あるいは好ましい作業として、携帯端末のメモリの完全なイメージがロードされているからである。

最近では、携帯端末のＯＴＡ（over-the-air）ファームウェアを用いた更新方法の導入が指摘されており、それにより、ユーザは、家の中あるいは街中で、システムのソフトウェアの最新バージョンを取得することが可能となる。更新作業は、ユーザがわざわざ行動を起こす必要はなく、代わりにネットワークオペレータなどがネットワークを通じて開始することができる。たとえば、特定モデルの携帯電話を有するすべてのユーザに対して、重要なパッチ（critical patch）が配布され、ユーザ自身が実際にそれらのパッチを探しに行く必要はない。

このように、ＯＴＡによる解決策によれば、追加的な機能やバグの修正を提供する更新を行うソフトウェアや他のデータの更新は、無線インタフェース（air interface）を通じて配布される。なお、本明細書において、携帯端末上に存在する古いソフトウェア版を「ベースバージョン」と称し、新しい更新されたソフトウェア版を「更新バージョン」または「ニューバージョン」と称することにする。単に新しいソフトウェア版のイメージを配布するだけでは、少なくとも二つの理由から満足行くものではないし、あるいは配布自体ができない場合がある。すなわち、ロード時間が非常に長くなる可能性があるし、さらには電話が同時に二つのコピーを保持しなければならならず、メモリの負担が倍になるおそれもある。これらの問題を解決するために、いわゆるデルタファイル内の必要な変更だけを転送する方法も指摘されている。デルタファイルは、携帯端末がベースバージョンとデルタファイルからニューバージョン生成する指示を含むように構成される。かかる指示はベースバージョンのデータの差分的更新に関するもので、それにより、ソフトウェア更新をロードするために必要な帯域幅と携帯端末に要求される記憶装置の容量を減じることが可能となる。

米国特許第６０１８７４７号は、ターゲットシステム上のソフトウェアのインプレース（in-place）デルタ更新を生成する方法が開示されている。そこでは、デルタファイルは、ソフトウェアのニューバージョンに到達するためのベースバージョンに対する変更を識別するための「コピー（copy）」コマンドと「追加（add）」コマンドから構成される。すなわち、上記従来方法によれば、ニューバージョンのソフトウェアをリリースする時に、デルタファイルはニューバージョンと以前のバージョンから生成される。デルタファイルは、狭い帯域幅のチャネルでも効果的に配布することができる。

米国特許第６０１８７４７号明細書

しかしながら、上記従来システムの問題は、ＯＴＡソフトウェア更新に関するいくつかのセキュリティ上の問題に目を向けていない点にある。ソフトウェア更新を安全に行うための要求項目の一つは、更新されるソフトウェアのバージョンが真正なものであることである。すなわち、更新されるソフトウェアがロードされることが予定されたソフトウェアに対応している必要がある。真正でない、あるいは汚染された（corrupted）ソフトウェアは、携帯端末に誤動作を引き起こす可能性があり、最悪、携帯端末を機能不全に陥らせる可能性がある。汚染されたソフトウェアは、ウィルスやウォームなどの悪意の攻撃の結果物であるかもしれないし、ライセンス機能の不正操作のようなハッキングの結果物であるかもしれないし、メモリエラーのようなソフトウェアやハードウェア上のエラーの結果物であるかもしれない。

したがって、本発明の目的は、ハイレベルのセキュリティが確保された携帯端末の更新メカニズムを提供することにある。

上記のおよび他の課題は、携帯端末内において、ソフトウェア上のコマンドを表すデータのような格納されたデータを第１のデータバージョンから更新データバージョンに差分的に更新する方法により解決される。この方法は、差分的な更新命令を携帯端末にロードし、格納されたデータとロードされた差分的更新命令から携帯端末によって更新データバージョンを生成し、その際に、携帯端末内に格納されたデータが第１のデータバージョンと一致しない１または２以上の汚染された部分を含むかどうかを検出し、更新データバージョンを生成する際に検出された汚染された部分を修復することから成る。

この結果、ベースバージョンが汚染されていたとしても、格納されたデータの汚染された部分を検出することにより、ニューバージョンを後続生成する時に、ニューバージョンが真正のニューバージョンであることが保証される。

ここで、「格納されたデータの汚染部分を修復する」という用語は、真正の更新バージョンの対応する部分を生成することを含む。

好適な実施形態において、上記方法は、さらに、検出されたデータの汚染部分についての情報に基づいて差分的更新命令を生成することを含む。すなわち、この実施形態によれば、修正されたデルタファイルは、ベースバージョンと、更新バージョンと、格納されたデータのどの部分が汚染されているかに関する情報、すなわち格納されたデータのどの部分が真正のベースバージョンに対応しないか、あるいは少なくとも真正のベースバージョンに対応しないおそれがあるかに関する情報に基づいて生成される。

たとえば、ソフトウェアのベースバージョンがウィルスプログラムに汚染されていたり、あるいはベースバージョンがライセンス保護メカニズムを出し抜くために不正操作されたものであったりした場合には、ソフトウェアの更新により、携帯端末を誤動作させたり、最悪機能不全に陥らせるおそれがある汚染されたメモリイメージが生成される可能性がある。

理解すべきは、汚染された部分が検出されない場合には、標準のデルタファイルが生成されるか、あるいはそのような標準のデルタファイルが以前のある時点においてすでに生成されている場合には、そのデルタファイルが取得されるという点である。かかる標準データファイルは、たとえば米国特許第６０１８７４７号に開示されている方法により、デルタファイルを生成する好適な方法を用いて生成される。

さらに好適な実施形態において、差分的更新命令は更新データを含み、更新データバージョンの生成は、前記更新データにより格納されたデータのうち予め決められた部分を置換することを含む。好ましくは、データに汚染された部分が検出された場合に、更新データは更新データバージョンと一致した修正されたデータ部分を含み、修正されたデータ部分は検出されたデータの汚染部分に対応する。

差分的更新命令の生成が、携帯端末に検出された汚染されたデータ部分を除いた格納されたデータからおよび差分的更新命令から更新データバージョンを生成させるコマンドを含む場合、ベースバージョンの汚染されていない部分だけが、差分的更新プロセスのソースとして用いられる。結果として、汚染された部分が更新バージョンの部分に広まってしまうリスクを減じることができる。

ここで、データ部分という用語は、所定のアドレス範囲内のデータとして識別可能なデータ部分や、メモリのセクションや、メモリブロックなどを含む。

好ましくは、差分的更新命令は、ソフトウェア更新サーバなどのような遠隔データ処理システム上で生成される。好ましくは、遠隔データ処理システムと携帯端末との間の通信は、ＧＳＭネットワークや、ＧＰＲＳネットワークや、ＵＭＴＳネットワークやその他の３Ｇネットワークのようなセルラー通信ネットワークのような無線通信リンクを介して行われる。また、上記通信は、ＴＣＰ／ＩＰのようなインターネットプロトコル（ＩＰ）や、ショートメッセージサービス（ＳＭＳ）や、その他の好適なデータ伝送メカニズムなどの好適な通信プロトコルにより行われる。

好適な実施形態において、汚染部分の検出は携帯端末により行われ、検出の結果は遠隔処理システムに報告され、その結果、携帯端末と遠隔データ処理システム間の無線インタフェースを介して通信をする必要があるデータ総量を減じることができる。

他の好適な実施形態において、汚染された部分の検出は、携帯端末と遠隔データ処理システムと協働して行われる。この実施形態によれば、方法は、格納されたデータについて情報を携帯端末から遠隔処理システムに伝送することを含み、伝送された情報から遠隔データ処理システムにより検出が行われる。この実施形態の利点は、携帯端末側において要求される計算能力とメモリ資源を減じることができる点である。この実施形態のさらなる利点は、潜在的に汚染されたデータまたはソフトウェアを含んでいる可能性がある携帯端末側において実施される処理に基づいて検出が行われないので、安全性が増す点である。

さらに好適な実施形態において、検出は、形態端末によりチェックサム数を計算し、その際に、各チェックサムは携帯端末内に格納されたデータの対応部分に対応し、さらに、計算されたチェックサムを汚染されたデータ部分を識別するための参照チェックサム数と比較することにより行われる。

かかる構成により、ベースバージョンの汚染された部分の検出を効果的にかつ高い信頼度で実施できるメカニズムが提供される。たとえば、チェックサムを、所定の寸法の各メモリブロックについてブロック基準で（block wise）で計算することができる。チェックサムの計算を暗号的に強化された一方向ハッシュ関数に基づいて行えば、検出メカニズムの信頼性がさらに高まる。

ある実施形態において、参照チェックサムは携帯端末に格納され、携帯端末において比較動作が行われる。この実施形態によれば、携帯端末はチェックサムを計算して照合し、照合結果が遠隔データ処理システムに送られる。

携帯端末によりそして携帯端末上に格納された参照チェックサムに基づいてすべての検出処理が行われるということは、参照チェックサム自体が不正行為などにより汚染されている可能性があるためセキュリティ上のリスクを含む。この問題は、携帯端末に格納された参照チェックサムがメッセージ真正コードにより完全な状態で保護されている場合に、解決される。

他の好ましい実施形態において、参照チェックサムは遠隔データ処理システム上に格納される。その場合に、伝送される情報には、計算されたチェックサムが含まれる。さらに検出処理には、遠隔データ処理システムが伝送され計算されたチェックサムを遠隔データ処理システム上に格納された参照チェックサム数と比較する処理が含まれる。この場合、参照チェックサムの格納が、携帯端末の記憶容量に負担をかけることはなく、参照チェックサムが、携帯端末に格納されたデータの汚染あるいは不正操作に対して攻撃を受けにくくなる。

さらに好ましい実施形態が従属請求項に開示されている。

上述のまたは以下に説明する方法の特徴は、ソフトウェアに組み込まれ、データ処理システム、その他、コンピュータ上で実行可能なコマンド群のようなプログラムコードを実行する処理手段により実行される。本明細書において、処理手段という用語には、上記機能を実行するように好適に調整されたすべての回路および／またはデバイスを含まれる。特に、処理手段の用語には、一般的なまたは特定用途にプログラムされたマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックアレイ（ＰＬＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け電子回路などおよびそれらの組み合わせが含まれる。

たとえば、プログラムコード手段は、格納媒体から、または他のコンピュータから、コンピュータネットワークを介して、ＲＡＭなどのメモリ内にロード可能である。代替手段として、上述の特徴は、ソフトウェアの変わりにハードウェアに制御された回路およびそれらとソフトウェアとの組み合わせにより実行可能である。

本発明の目的は、上述のおよび以下に述べる方法を含むさまざまな方法により実行することが可能であり、携帯端末、データ処理システムその他の製品手段は、それぞれ、上述した方法に関連して説明する利益および利点のうち１つまたは２以上をもたらすものであり、それぞれ、上述した方法に関連して説明する好適な実施形態に対応する１または２以上の好適な実施形態に実現するものである。

本発明は、さらに、以下の特徴を備えた携帯端末に関連する。この携帯端末は、データを格納するデータメモリと、データメモリ内に格納されたデータを第１のデータバージョンから更新データバージョン更新するための差分的更新命令をデータ処理システムから受信するように構成された通信手段と、格納されたデータからおよび受信した差分的更新データバージョンから更新データバージョンを生成するように構成された処理手段とを含み、処理手段は、さらに、格納されたデータのうち第１のデータバージョンと一致しない１または２以上の部分の存在または不存在の示す情報を格納されたデータから生成し、さらに生成された情報を、通信手段を介して、データ処理システムに通信して差分的更新命令を生成するように構成されている。

本発明は、さらに第１のデータバージョンから更新データバージョンに携帯端末内に格納されたデータを差分的に更新するに適したデータ処理システムに関連する。このデータ処理システムは、差分的更新命令を携帯端末にロードし、差分的更新命令によって携帯端末に格納されたデータとロードされた差分的更新命令から更新データバージョンを生成させる。その場合に、データ処理システムは、さらに、格納されたデータのうち第１のデータバージョンと一致しない１または２以上の部分の存在または不存在を示す情報を携帯端末から受信する手段と、第１のデータバージョンと更新データバージョンと受信した情報から差分的更新命令を生成し、その際に、差分的更新命令に修正コマンドを含ませるように構成され、その場合に、修正コマンドは携帯端末に検出された各汚染部分を修復させるように構成されている。

本発明は、さらに、以下の特徴を備えたコンピュータプログラムに関する。このコンピュータプログラムは、以下に述べるステップを実行して、データ処理システムをして、携帯端末に格納されたデータを第１のデータバージョンから更新データバージョンに差分的更新させるように構成されている。このプログラムがデータ処理システム上で実行される際には、第１のデータバージョンと更新データバージョンと携帯端末から受信した情報から差分的更新命令を生成する処理が行われる。その場合に、受信した情報は格納されたデータのうち第１のデータバージョンと一致しない１または２以上の部分の存在または不存在を示すものであり、さらに、差分的更新命令の生成処理には差分的更新命令に修正コマンドを含ませる処理が含まれ、その修正コマンドは携帯端末に検出された各汚染部分を修正させるように構成されている。さらに、このプログラムがデータ処理システム上で実行される際には、生成された差分的更新命令を携帯端末内にロードする処理が行われる。その場合に、差分的更新命令は、携帯端末に格納されたデータおよびロードした差分的更新命令から更新データバージョンを生成させるように構成されている。

携帯端末という用語には、無線通信用信号などの通信用信号を受信しおよび／または送信してデータ通信を行うための好適な回路を含む、すべての携帯用デバイスが含まれる。かかるデバイスには、携帯用無線通信装置その他の手で保持可能な携帯用デバイスが含まれる。携帯用無線通信という用語には、携帯電話、ページャー、その他の電子オーガナイザー、スマートフォン、パーソナル・デジタル・アシスタント（ＰＤＡ）などのコミュニケータが含まれる。

上述のおよび他の本発明の観点については、図面に関連して以下において説明される実施形態において明らかに説明される。なお、図面において：
図１は、携帯端末内のソフトウェアを更新するためのシステムの一実施形態にかかるブロック図の概略を示しており；
図２は、本発明の一実施形態による携帯端末のブロック図の概略を示しており；
図３は、ソフトウェア更新プロセスの一実施形態の流れ図を示しており；
図４は、チェックサムの計算と整合性保護の概略を示しており；
図５は、本発明の他の実施形態による携帯端末のブロック図の概略を示しており、
図６は、ソフトウェア更新プロセスの他の実施形態の流れ図を示しており；
図７ａ−ｂは、それぞれ、汚染されたメモリブロックが存在しない場合と存在する場合のデルタファイルの生成の一実施形態の概略を示している。

図１は、携帯端末内のソフトウェアを更新するためのシステムの一実施形態のブロック図の概略を示している。このシステムは携帯端末１０１、たとえば携帯電話などと、ソフトウェア更新システム１０２と、通信ネットワーク１０３から構成されている。

ソフトウェア更新システム１０２は、通信ネットワークにアクセス可能なサーバコンピュータから成る。ある実施形態においては、サーバコンピュータの機能は、複数のコンピュータ、たとえば、ＬＡＮ（local area network）やＷＡＮ（wide area network）やインターネットなどのコンピュータネットワークを介して接続されるコンピュータ群に分散される。ソフトウェア更新システム１０２は、通信ネットワーク１０３を介してデータ通信を可能にするネットワークインタフェース１０４を備えている。たとえば、ネットワークインタフェースは、ネットワークカード、ＤＳＬモデム、ゲートウェイコンピュータなどから構成することができる。

ソフトウェア更新システムは、さらに、処理ユニット１０５、たとえばデルタファイルの生成を含む更新プロセスを制御し実行するように好適にプログラムされたサーバコンピュータのＣＰＵなどから構成される。処理ユニットは、さらに、少なくとも更新されるソフトウェアのベースバージョンと更新バージョンのメモリイメージが格納されたバージョンデータベース１０６を備えている。ある実施形態においては、バージョンデータベースはさらに、異なる顧客群などに対応するために、異なる携帯端末のモデル用の複数のベースバージョンおよび／または更新バージョンなどの追加的情報を備えることができる。

通信ネットワーク１０３は、無線通信ベアラ（wireless communications bearer）を用いて、ソフトウェア更新システム１０２と携帯端末１０１との間でデータ通信をするに好適な通信ネットワークとして構成される。たとえば、ＧＳＭネットワークやＵＭＴＳネットワークやＧＰＲＳネットワークなどのセルラー通信ネットワークを介して通信を行うように調整された携帯電話の場合には、ソフトウェア更新に関連するソフトウェア更新システムと携帯端末間の通信は好ましくはセルラー通信ネットワークを介して行われ、それにより携帯端末側に追加的な通信インタフェースを設ける必要を回避できる。さらに、理解すべきは、携帯端末とソフトウェア更新システム間の通信には一以上の通信ネットワークが含まれうる点である。たとえば、携帯電話は、ソフトウェア更新システムとインターネットを介して順次通信を行うゲートウェイシステムと、基地局とセルラーテレコムネットワークを介して、通信を行うことも可能である。

このように、携帯端末１０１上でソフトウェア、すなわち、携帯端末のファームウェアまたはオペレーティングシステムを更新するために、携帯端末はソフトウェア更新システム１０２に接続する。代わりに、更新ソフトウェアバージョンが有効になると、ソフトウェア更新システムが携帯端末に接続するように構成しても良い。ソフトウェア更新システムに接続すると、携帯端末はソフトウェア更新システムに、現在のソフトウェアバージョンに関する情報とメモリ内に現在格納されているソフトウェアに関する情報を送信する。かかる情報により、ソフトウェア更新システムは汚染されているあるいは少なくとも汚染されるおそれのあるメモリブロックを認識する。通信は、好適な更新プロトコル、たとえばＴＣＰ／ＩＰ上で構築されたプロトコルにより実行される。携帯端末から受け取った情報に基づいて、ソフトウェア更新システムは、携帯端末に対する差分的更新命令からなる専用の更新メッセージを生成する。差分的更新命令は、携帯端末がすでに携帯端末に格納されている現存のバージョンからおよび更新命令内に含まれる追加的情報から更新ソフトウェアバージョンを生成することができるように、生成される。さらに差分的更新命令は携帯端末内のすべての汚染されたメモリブロックが更新バージョンの真正なブロックに更新されるように、さらにすべての汚染されたメモリ内容が更新バージョンの生成時に携帯端末により使用されないように、生成される。

デルタファイルは必要なものだけ供給されてもよい。かかる構成により、追加的な格納を最小限に抑えることができる。さらに、デルタファイルだけをロードする必要があり、デルタファイルは通常はニューバージョンをかなり小さいものなので、上述の方法によれば、ロード時間を短縮できる。

ある実施形態では、更新プロセスは、携帯端末上で動作する更新エージェントにより起動される。更新エージェントは、デルタファイルの受け入れと検証を制御する。さらに、更新エージェントはパッチモードで携帯端末をネットワークから切り離したりリブートしたりする。パッチモードでは、デルタファイル内の変化は新しいメモリイメージが完了するまで追加的に供給される。

更新プロセスの実施形態の詳細については以下に説明される。

図２は、本発明の一実施形態にかかる携帯端末の概略的なブロック図を示している。携帯端末２０１は、通信ブロック２１０と処理ユニット２１１とメモリユニット２１２、２１３、２１４から構成されている。

通信ブロック２１０は、セルラー通信ネットワークを介して無線ベースでデータ通信を可能にする回路および／またはデバイスを含んでいる。本発明の目的のためには、通信ブロック２１０は、データ信号を送受信するために、受信回路と送信回路を備えている。通信ブロックは、さらに、変調、復調、増幅などのように無線通信分野において知られた好適な技法により信号を好適に処理するための回路も備えている。

携帯端末は、さらに好適にプログラムされたマイクロプロセッサなどの処理ユニット２１１を備えている。処理ユニットは、携帯端末に格納されたソフトウェアのバージョンを決定し、格納されたソフトウェアのチェックサムを計算し、対応する更新命令の受信時にソフトウェアの更新バージョンを生成するように調整されている。

メモリユニット２１２は、所定のバージョンのソフトウェアおよび／またはその他のデータを格納する。たとえばメモリ２１２は、処理ユニット２１０によりロードされ実行された場合に、携帯端末の基本機能を実行する携帯端末のファームウェアを記憶している。ファームウェアは、さらに、ソフトウェアを実行するためのオペレーティングシステムを含んでいる。メモリ２１２は、さらに追加的な機能を供給するための応用ソフトウェアを記憶することが可能である。メモリ２１２は、好適なアドレス空間を用いて番地付けされており、それにより処理ユニットはメモリ所定の部分にアクセスすることが可能である。ある実施形態においては、メモリ２１２は論理的にまたは物理的に複数のメモリブロックに分割されている。たとえば、メモリ２１２は所定寸法のブロックにデータを書き込むことが可能なフラッシュメモリから構成される。

以下では、メモリ２１２は、Ｂ１、Ｂ２、Ｂ３、…、ＢＮとして表現される所定寸法の複数のブロックに分割されているものと仮定する。しかし、代わりに、メモリの他のアドレス方法を用いることが可能であることは言うまでもない。さらに、ここで言及される更新処理は、携帯電話のフラッシュメモリの全イメージが更新されるような場合には、メモリ２１２全体に適用されるし、一または２以上のアプリケーションだけが更新される場合には、メモリの所定部分だけに適用される。

携帯端末２０１は、さらにメモリブロックが汚染されたかどうかを決定する際に使用される参照チェックサムのリストを格納するためのメモリセクション２１３を備えている。チェックサムの生成および使用については以下において詳細に説明する。メモリセクション２１２、２１３は、物理的に同一のメモリの一部として構成することも可能であるし、物理的に異なるメモリとして構成することも可能であることはもちろんである。

好適な実施形態において、携帯端末は、さらに下記に詳述するように、格納されたチェックサムの整合性保護のために使用される秘密キーをセキュアに保護するためのメモリセクション２１４を備えることができる。たとえば、秘密キーは、携帯端末の所定回路の外部からはアクセス不能なＲＯＭやＥＰＲＯＭなどの内部メモリ内に格納することが可能である。他の実施形態においては、携帯端末は、たとえば電子融合手段により携帯端末の回路に焼き付けられた固有のチップＩＤを備えている。他の実施形態においては、秘密キーはフラッシュキーのような保護されていないメモリ上に暗号化された格納される。

図３は、ソフトウェア更新プロセスの一実施形態を示す流れ図である。符号３２１で示す右側の流れ図は、携帯端末により実行されるステップを示しており、符号３２２で示される左側の流れ図は、ソフトウェア更新システム側に実行されるステップを示している。

図３の流れ図において、ソフトウェア更新システムが更新プロセスを起動するものと仮定する。すなわち、初期化ステップ３３１において、ソフトウェア更新システムは、ソフトウェアのニューバージョンが使用可能になったことを、たとえばＩＤ Ｖ２を携帯端末に知らせるメッセージを携帯端末に送信する。ソフトウェア更新システムから受信したこのメッセージに応答して、携帯端末はメモリ３１２の対応するメモリブロックの内容、あるいは更新されるソフトウェアを含むメモリ部分のチェックサムを計算する。

ステップ３３３において、携帯端末は、計算されたチェックサムと携帯端末のメモリセクション３１３内に格納された参照チェックサムのリストを比較する。参照チェックサムは、携帯端末内に現在組み込まれているベースバージョンに対応する真正なメモリ内容のメモリブロックに対応するチェックサムである。どのようにチェックサムが格納され計算されるかについては、図４に関連して以下に説明する。

図４は、チェックサムの計算と整合性保護の様子を示す説明図である。図４は、更新される携帯デバイスのメモリ４１３を概略的に示している。メモリは、Ｂ１、Ｂ２、…、ＢＮで示されるようにＮブロックに分割されている。この実施形態によれば、携帯端末は、さらに、メモリ４１３のＮメモリブロックの真正なメモリイメージ相当するＮ＋１のメモリブロックが格納されたメモリセクション４１３を備えている。Ｎ＋１のＮは、各メモリブロックＢ１、Ｂ２、…ＢＮの参照チェックサムが格納されるように、Ｎメモリブロックのそれぞれについて計算される。個々のメモリブロックのチェックサムはＣＲＣ１、ＣＲＣ２、…、ＣＲＣＮとして表示されている。好ましくは、各チェックサムは、ＣＲＣｉ＝ｈ（Ｂｉ）により表現されるハッシュ関数ｈを用いて対応するメモリブロックから演算される。「暗号的に強い一方向ハッシュ関数」という用語は、関数Ｍ→ｈ（Ｍ）を含むことを意図するものである。関数Ｍ→ｈ（Ｍ）は、メッセージ空間から小さなハッシュ空間にメッセージＭを誰もコンピュータ的に実行不可能なようにマップすることを意味する。すなわち、ＭとＭ’は、ｈ（Ｍ）＝ｈ（Ｍ’）として表現され、任意のｍを与えれば、メッセージＭは、ｈ（Ｍ）＝ｍとして表現される。好適なハッシュ関数としてはＳＨＡ−１やＭＤ５を例示できる。

Ｎ＋１チェックサムの残りの一つは、ＣＲＣＴと表現され、すべてのメモリ４１２について計算されるものであり、ＣＲＣＴ＝ｈ（Ｂ１、Ｂ２、…、ＢＮ）と表現される。一つの実施形態においては、この総チェックサムは、総チェックサムを計算し比較する初期チェックを実行するために使用される。総チェックサムの検証が成功すると、システムは、汚染されたメモリブロックがないと仮定する。総チェックサムの整合性がとれない場合にのみ、どのブロックが汚染されているか識別するために、個々のチェックサムの計算と比較が行われる。

ある実施形態において、チェックサムリストの不正操作の検出が可能な整合性保護機能を有する携帯端末の場合には、真正なメモリ内容のチェックサムリストが携帯端末内に格納されている。たとえば、チェックサムのリスクは、携帯端末のセキュアなメモリセクション４１４に格納された秘密キーｋを用いたＭＡＣ（message authentication code）によって保護することが可能である。ＭＡＣの一例はＨＭＡＣである。ある実施形態においては、タグ値ｔ＝ＭＡＣｋ（ＣＲＣ１、…、ＣＲＣＮ、ＣＲＣＴ）がＭＡＣアルゴリズムと秘密キーｋを用いてチェックサムから計算される。計算されたタグ値は参照チェックサムリストに追加され、参照番号４１５で示されるように、メモリセクション４１３に格納される。更新プロセスの間、携帯端末は秘密キーｋを用いてタグ値を再計算し、計算された値がメモリに格納されたタグ値４１５と比較される。

ＭＡＣに基づく整合性保護の高い安全性を十分に得るために、キーｋは、図２に関連して既に説明したように、信頼のあるプロセス／ユーザによってのみアクセスまたは読み出しができるようにメモリ４１４内に格納されることが好ましい。

再び図３を参照すると、ステップ３３３において、携帯端末は、携帯端末に格納された参照チェックサムと計算されたチェックサムが異なる場合には、そのメモリブロックを識別する。

ステップ３３４において、携帯端末は、ＩＤ＿Ｄ１で示される現在組み込まれているソフトウェアバージョンの識別子と汚染されたメモリブロックのリストをソフトウェア更新システムに送信する。図３の例では、このリストは、ブロック識別子ＢＣ１、…、ＢＣＫ、０≦Ｋ≦Ｎから成る。

この情報を受け取ると、ソフトウェア更新システムは、好適なデルタファイルを生成する。図３の実施形態において、ステップ３３５において、ソフトウェア更新システムは、携帯端末が汚染されたブロックを識別したかどうかを決定する。汚染に該当しない場合、すなわち、メモリ内容が、真正なベースバージョンであると携帯端末により検証された場合には、ソフトウェア更新システムは専用デルタフィルを生成する必要はない。この場合、真正なベースバージョンから所望の更新バージョンに更新するための差分的更新命令から成る標準デルタファイルは、ソフトウェア更新システムのバージョンデータベース３０６内において予め生成し格納しておくことも可能である。このように、汚染されたブロックが識別されない場合には、プロセスはステップ３３６に進み、ソフトウェア更新システムは、データベース３０６から対応する標準デルタファイルを取り出し、ステップ３３８に進む。

１または２以上の汚染されたブロックが識別された場合には、プロセスは３３７に進み、ソフトウェア更新システムは、専用デルタファイルを生成し、ステップ３３８に進む。詳細についてはすでに説明したように、専用デルタファイルは、携帯端末に真正な更新バージョンを生成させる更新命令から成る。特に、更新命令は、更新バージョンの生成の間に、汚染されたブロックが再使用されないようにする。このようにして、ソフトウェア更新システムはベースバージョンとニューバージョンをバージョンデータベース３０６から取り出し、これら二つのバージョンと汚染されたメモリブロックの情報からデルタファイルを生成する。汚染されたブロックが存在している中で専用デルタファイルを生成する例については、図７ａ〜ｂに関連して説明する。

ステップ３３８において、ソフトウェア更新システムは、生成されたデルタファイルを携帯端末に送信する。ステップ３３９において、携帯端末はメモリ３１２の内容とデルタファイルから取得したコマンドからソフトウェアの更新バージョンを生成する。

図３に示す実施形態において、メモリ３１３に格納された参照チェックサムについても更新されたメモリ内容を反映するために更新される。このように、ステップ３３９において、携帯端末は、さらに更新された参照チェックサムを計算し格納し、その際に、整合性保護が適用される場合には、秘密キーｋを用いた更新されたＭＡＣについても、計算し格納する。他の実施形態としては、上記構成の代わりに、更新された参照チェックサムとＭＡＣ値はソフトウェア更新システムにおいて計算され、携帯端末に送信される。

さらに、ある実施形態においては、携帯端末は、受け取ったデルタファイルを実行する前に受け取ったデルタファイルの検証、たとえば、受け取ったデルタファイルに対して整合性保護を適用したり、ソフトウェア更新システムのユーザ識別（authentication）を適用したりする。

さらに、更新が成功裏に完了した場合には、ステップ３４０において、携帯端末は、ソフトウェア更新システムに対して成功確認証（an acknowledgment of the successful receipt）を送信する。ステップ３４１において、ソフトウェア更新システムが確認証を受領すると更新プロセスは完了する。

以下においては、更新プロセスの第２の実施形態について、図５および図６を参照しながら説明する。この実施形態は、汚染されたブロックの検出を携帯端末とソフトウェア更新システムとが協働して実行するものである。

図５は、本発明の別の実施形態に基づく携帯端末のブロック図を概略的に示している。携帯端末５０１は、図２に関連した実施形態とほぼ同様に、通信ブロック５１０と、処理ユニット５１１と、メモリユニと５１２とを含んでいる。しかし、携帯端末５０１は、図２の携帯端末とは異なり、参照チェックサムや参照チェックサムの整合性保護のためのキーパラメータを格納するメモリセクションを備えていない。

図５の携帯端末に関連して使用される更新プロセスについては、図６に関連して説明する。図６のプロセスは、図３のプロセスとほぼ同様であるが、図６のプロセスにおいて、携帯端末は、計算されたチェックサムを、チェックサムと参照チェックサムとの比較を行うソフトウェア更新システムに送信することはない。かかる構成により、携帯端末側の記憶容量要求および計算資源を減じることができる。

図６において、符号６２１で示す右側の部分は、携帯端末によって実行されるステップを示し、符号６２２で示す左側の部分は、ソフトウェア更新システムによって実行されるステップを示している。

図６において、ソフトウェア更新システムが更新プロセスを開始するものとする仮定する。したがって、最初のステップ６３１において、ソフトウェア更新システムは、ソフトウェアのニューバージョンが使用可能になったことを携帯端末に知らせるメッセージを携帯端末に送る。ステップ６３２において、ソフトウェア更新プログラムから受け取ったメッセージに応答して、携帯端末は、詳細についてはすでに説明したように、メモリ６１２の対応するメモリブロックの内容または更新されるソフトウェアを含むメモリ部分のチェックサムを計算する。

ステップ６３４において、携帯端末は、現在組み込まれているソフトウェアバージョンの識別子と符号ＣＲＣ１、…、ＣＲＣＮで示す計算されたチェックサムのリストをソフトウェア更新システムに送信する。

この情報を受信すると、ステップ６３３において、ソフトウェア更新システムは、受信したチェックサムをバージョンデータベース６０６に格納された参照チェックサムのリストと比較する。代わりに、参照チェックサムを別の場所に格納したり、ソフトウェア更新システムが、バージョンデータベース６０６内に格納された真正のベースバージョンからチェックサムを計算したりするように構成しても良い。参照チェックサム構造およびそれらを計算する方法の詳細についてはすでに説明した。

別の実施形態によれば、携帯端末がソフトウェア更新システムにチェックサムを送信するために整合性保護処理を行うように、たとえば、上述のようにＭＡＣタグを追加したり、暗号化処理を施したりするように構成される。

ステップ６３５においては、ソフトウェア更新システムは、ステップ６３３の比較により汚染されたブロックが明らかになったかどうかを決定する。汚染されたブロックが同定されない場合には、プロセスはステップ６３６に進み、ソフトウェア更新システムは、データベース６０６から対応する標準デルタファイルを引き出し、ステップ６３８に進む。

１または２以上の汚染されたブロックが同定された場合には、プロセスはステップ６３７に進み、ソフトウェア更新システムは専用デルタファイルを生成し、ステップ６３８に進む。

ステップ６３８において、ソフトウェア更新システムは、データファイルを携帯端末に送信する。ステップ６３９において、携帯端末は、メモリ６１２の内容およびデルタファイル内のコマンドからソフトウェアの更新バージョンを生成する。携帯端末は更新バージョンをメモリ６１２に格納する。

ある実施形態において、携帯端末は、受け取ったデルタファイルを適用する前に受け取ったデルタファイルの検証、たとえば、受け取ったデルタファイルに対して整合性保護を適用したり、ソフトウェア更新システムのユーザ識別（authentication）を適用したりする。

さらに、更新が成功裏に完了した場合には、ステップ６４０において、携帯端末は、ソフトウェア更新システムに対して成功確認証（an acknowledgment of the successful receipt）を送信する。ステップ６４１において、ソフトウェア更新システムが確認証を受領すると更新プロセスは完了する。

図６のプロセスの変更例において、携帯端末は、更新すべきすべてのメモリの総チェックサムを最初に計算し、総チェックサムを検証のためにソフトウェア更新サーバに伝送する。総チェックサムの検証が成功すると、ソフトウェア更新システムは、携帯端末に標準更新ファイルを送信する処理を進める。少なくとも１つの汚染されたブロックの存在により総チェックサムの検証が失敗すると、ソフトウェア更新システムは、携帯端末に対して、どのブロックが汚染されているかを同定するために、各ブロックのチェックサムリストを送るように要求する。

図７ａ−ｂは、それぞれ、汚染されたブロックが存在しない場合と存在する場合のデルタファイルの生成の実施形態を概略的に示している。

上述のように、デルタファイルはそのファイルのベースラインからファイルの更新バージョンまたは他のメモリ内容を生成するための差分的更新命令を含んでいる。ある実施形態において、デルタファイル生成処理は、ベースラインバージョンと更新バージョンのバイトレベルでの比較として行われる。以下においては、ベースラインバージョンをＶ１として示し、更新バージョンをＶ２と示すことにする。

いくつかのデルタファイル生成アルゴリズムは、たとえば米国特許第６０１８７４７号に示されている。典型的には、アルゴリズムは、二つのバージョンＶ１とＶ２とをスキャンして、可能な限り類似点を見つけ出す。共通データセクションの位置と寸法が記録され格納される。デルタファイルは典型的には、コマンド、たとえば追加コマンドとコピーコマンドの数から成る。コピーコマンドはバージョンＶ１から再使用されるデータを同定するのに対して、追加コマンドはバージョンＶ２に導入された、すなわち追加されたデータを表す。

図７ａ−ｂの単純な例においては、符号７５１で示されるファイルまたはメモリエリアのベースラインバージョンは、それぞれ、符号Ｂ１、Ｂ２、Ｂ３、Ｂ４およびＢ５で示される５つのデータブロックから構成される。これらのブロックに格納されるデータは、それぞれ、符号Ａ、Ｂ、Ｃ、ＤおよびＥとして表示される。符号７５２で概略的に示されるファイルの更新バージョンは、それぞれ、符号Ｂ１、Ｂ２、Ｂ３、Ｂ４およびＢ５で示される５つのデータブロックから構成される。しかし、各ブロックの内容は対応するベースラインバージョンの内容とは異なっている。更新バージョンにおいて、５つのブロックはそれぞれ、符号Ｄ、Ａ、Ｆ、ＧおよびＢとして表示される。ここで同じ文字は同一のデータに対応し、異なる文字は異なるデータを示している。

図７ａ−ｂにおいて、点線の矢印は、２つのバージョンで共通のブロックを示している。このように、図７ａ−ｂの例では、更新ブロックＢ１が、元のバージョンのブロックＢ４と同じデータから成り、更新ブロックＢ２は、元のバージョンのブロックＢ１と同じデータから成り、更新ブロックＢ５は、元のバージョンのブロックＢ２と同じデータから成る。

更新処理の間、バージョンＶ１はデルタファイル内のコマンドを適用することによってバージョンＶ２に転送される。デルタファイルには、一例として、ブロックごとのコピーと追加操作を用いてバージョンＶ１からバージョンＶ２をどのように構築するかの記述が含まれる。たとえば、図７に示す例では、デルタファイル７５３は以下の５つのコマンドから成る。
1. B5: CP B2
2. B2: CP B1
3. B1: CP B4
4. B3: AD<F>
5. B4: AD<G>
各コマンドは、更新されるバージョンのブロックとそのブロックをどのように生成するかついてのコマンドを識別する。この例では、第１のコマンドによりブロックＢ５がブロックＢ２の元の内容をコピーすることにより生成される。同様に第２および第３のコマンドにより、ブロックＢ２およびＢ１がそれぞれ元のブロックＢ１およびＢ４のコピーとして生成される。第４および第５のコマンドは、それぞれ、データＦをブロックＢ３に追加し、データＧをブロックＢ４に追加することを特定する追加コマンドである。上記コマンドシーケンスの順番は、ブロックの元の内容が読み出される前にブロックの書き込みが行われてしまうような読み出し／書き込みのコンフリクトを回避するように選択される。

上記更新処理は、デルタ生成アルゴリズムに使用されるバージョンＶ１のイメージが携帯端末上のバージョンＶ１のイメージと一致しているという事実によっている。ターゲットノードのイメージが不正操作されていたり、ウィルスに犯されていたり上記場合に該当しない場合には、更新処理が失敗し、完全には機能しないターゲットノードがもたらされるという大きなリスクが存在する。かかる事態を避けるために、デルタファイルが作成される前に、ターゲットイメージのステータスがチェックされ、報告がソフトウェア更新システムに送られる。一致しないブロックが発見された場合、デルタファイルの生成は行われない。これは、汚染されたブロックの新しいコピーを含む追加コマンドがコピーコマンド代わりに使用される可能性があるため、デルタファイルが標準デルタファイルよりも大きい可能性があることを意味する。

図７ｂは、汚染されたブロックを含むデルタファイル生成の例を示している。図７ｂにおいては、ブロックＢ２が汚染されたものと検出されたと仮定することを除き、図７ａと同じシナリオを想定することができる。

結果として、修正されたデルタファイルの生成において、汚染されたブロックＢ２は、バージョンが同じかどうかを比較される際に、除かれ、汚染されたＢ２は更新ブロックＢ５の生成には再使用されない。したがって、この場合には、結果として生じるデルタファイル７５４は、デルタファイル７５４がブロックＢ５を更新するための異なるコマンドから成る場合には、以前のデルタファイルは異なる。すなわち、ここでは、コマンドは下記のようになる。
1. B5: AD<B>
ここで、コピーコマンドの代わりに、真正の更新データＢは、正確にブロックＢ５に追加される。さらに、この記述の目的のために、コマンドの順番は維持されることに留意する必要がある。しかしながら、図７ｂの例において、上述のステップＢ５：ＡＤ＜Ｂ＞は、ブロックＢ５を修正するためのコマンドは他のブロックの内容には依存していないため、ブロックのシーケンスに沿って、最後のステップとして実行されるように構成することも可能である。ここで、他の実施形態においては、コマンドのシーケンスは（２、３、４、５、１）と成る。

図７ａ−ｂのシナリオは、更新処理時の汚染されたイメージの影響を説明するための単なる例示に過ぎないことに留意されたい。

特に、更新ステップはブロックごとの更新とは異なる実行単位で行うことも可能である。コピーと追加コマンドは、より小さいメモリセクションとして構成することも、より大きいメモリセクションとして構成することも可能である。特に、追加コマンドとコピーコマンドの実行単位は、汚染の有無が検出されたブロックのブロック寸法に限定されるものではない。追加コマンドおよびコピーコマンドは、さまざまな寸法のメモリセクションを含むことが可能である。たとえば、各コピーコマンドまたは追加コマンドは、コピーまたは追加される開始アドレスとデータ領域の長さを示すことも可能である。

さらに、デルタファイルは別のコマンドや代わりのコマンド、たとえば削除コマンドなどを含むように構成することも可能である。

さらにデルタファイルは、更新ファイル内のメモリセクションのシーケンスとは異なる更新ステップの順番を指定することも可能である。たとえば、更新ステップのコンフリクトを避けるために、メモリブロックが最初のステップで更新され、メモリブロックの元の内容は後続の更新ステップにおいて再使用されるように構成することもできる。

さらに、別の実施形態においては、別の新しいデータを、コマンドファイルとデータファイルが転送されるように、別のファイルとして送信するように構成することもできる。

以上、本発明の好適な実施形態について説明したが、本発明はこれらに限定されず、特許請求の範囲に規定される主題の範囲内において別の方法で実施することも可能である。たとえば、本発明は、単に、ソフトウェアの更新に関連して説明したが、当業者であれば、本発明を携帯端末に格納された他のデータの更新に適用することも可能である。

ここで説明する更新プロセスの他の修正例によれば、汚染されたメモリブロックが検出された場合に、ソフトウェア更新プログラムは、ライセンス関連データを含むメモリブロックが汚染されている場合には、安全上の理由から、ソフトウェア更新システムがソフトウェアの更新を拒否するように、代替的なまたは追加的なステップを実行するように構成することもできる。

ここで説明する更新プロセスのさらに別の修正例によれば、更新プロセスはソフトウェア更新システムの代わりに携帯端末により起動される。たとえば、携帯端末はソフトウェア更新システムに使用可能な更新があるかどうか照会することができる。ある実施形態においては、この照会には、現在組み込まれているソフトウェアのバージョン情報が含まれる。たとえば、携帯端末は、かかる照会を、規則的な時間間隔で送信したり、ユーザのコマンドに応じて送信したり、その他のイベントに応じて送信したりすることができる。ある実施形態においては、携帯端末は、規則的な時間間隔またはユーザのコマンドなどのイベントをトリガとしてメモリチェックを行うように構成することができる。たとえばメモリチェックは、上述のように、チェックサムを計算し、そのチェックサムと携帯端末に格納された参照チェックサムと比較することにより行うように構成することができる。メモリチェックの結果、汚染されたブロックが明らかになった場合には、ニューバージョンが有効であるかどうかにかかわらず、携帯端末は無条件にソフトウェアの更新を要求するように構成することができる。かかる構成により、汚染されたメモリ内容の修復が可能となる。他の実施形態においては、携帯端末は、規則的にチェックサムを計算し、ソフトウェア更新システムにそれらを送信し、そこで上述のようにそれらを検証するように構成することができる。汚染されたメモリブロックが見つかった場合、あるいはソフトウェアのニューバージョンが使用可能となった場合には、更新システムによりソフトウェアの更新が起動される。

更新プロセスのさらに別の修正例によれば、ソフトウェア更新システムは、それぞれが汚染された単一のブロックに対応するデルタファイルから成るような複数の代替デルタファイルを予め計算するように構成することができる。予め計算された代替デルタファイルは格納され、実際の更新プロセス時に取り出すように構成することができる。かかる構成により、実際の更新プロセス時に必要な処理を減じることができる。代替として、あるいは追加的に、ソフトウェア更新システムは、更新プロセス時に計算されたデルタファイルをキャッシュしたり格納したりするように構成することができる。かかる構成により、同様な汚染ブロックが識別されたような場合の将来の更新時にそれらを利用することができる。かかる構成は、汚染されたメモリがウィルスなどによって引き起こされた場合には、複数の携帯端末が対応する汚染ブロックを含むことが想定されるので、特に有効である。

本発明は、複数の異なる要素から成るハードウェア手段によって、および好適にプログラムされたコンピュータによって実行することが可能である。装置の請求項においては、いくつかの手段を列挙しているが、これらの手段のいくつかは、すでに説明したように、一つのまたは同一構成のハードウェア、たとえば好適にプログラムされたマイクロプロセッサやコンピュータおよび／または１または２以上の通信インタフェースにより実施することが可能であることは言うまでもない。ある手段が、相互に異なる従属請求項において引用されたり、異なる実施形態において記述されたりしている事実は、これらの手段を組み合わせてさらに有利にすることができないということを示すものではない。

特に、明細書において使用される「から成る／を含む」という用語は、言及された特徴、完成品、ステップ、要素を特徴付けるために使用されるものであり、１または２以上の特徴、完成体、ステップ、要素またはそれらの組み合わせの存在または追加を排除するものではないことが強調される。

図１は、携帯端末内のソフトウェアを更新するためのシステムの一実施形態にかかる概略ブロック図である。 本発明の一実施形態による携帯端末の概略ブロック図である。 ソフトウェア更新プロセスの一実施形態の流れ図である。 チェックサムの計算と整合性保護の概略の説明図である。 本発明の他の実施形態による携帯端末の概略ブロック図である。 ソフトウェア更新プロセスの他の実施形態の流れ図である。 それぞれ、汚染されたメモリブロックが存在しない場合と存在する場合のデルタファイルの生成の一実施形態の概略を示す説明図である。

符号の説明

１０１ 携帯端末
１０２ ソフトウェア更新システム
１０３ 通信ネットワーク
２０１ 携帯端末
２１１ 処理ユニット
２１２ メモリユニット
２１３ メモリユニット
２１４ メモリユニット
２１０ 通信ブロック

Claims (21)

1. 携帯端末に格納されたデータを第１のデータバージョンから更新データバージョンに差分的に更新する方法であって、前記方法は、前記携帯端末に差分的更新命令をロードし、前記携帯端末により前記格納されたデータおよび前記ロードされた差分的更新命令から前記更新データバージョンを生成することから成り、
   前記方法は、さらに、前記携帯端末内に格納された前記データが前記第１のデータバージョンと一致しない１または２以上の汚染された部分を含むかどうかを検出し、前記更新データバージョンを生成し、検出された前記汚染部分を修復することから成ることを特徴とする方法。
2. さらに、前記データに汚染部分が検出された場合に、前記検出された汚染部分についての情報に基づいて前記差分的更新命令が生成されることを特徴とする、請求項１に記載の方法。
3. 前記差分的更新命令が更新データを含み、前記更新データバージョンの生成は前記更新データにより前記格納データの所定部分を置き換えることから成ることを特徴とする、請求項２に記載の方法。
4. 前記更新データは前記更新データバージョンと一致するデータの修正部分を含み、前記データの修正部分は前記検出されたデータの汚染部分に対応することを特徴とする、請求項３に記載の方法。
5. 前記差分的更新命令の生成は、前記携帯電話に、前記検出されたデータの汚染部分がある場合には、前記差分的更新命令からその汚染部分を除いて、前記格納されたデータから前記更新データバージョンを生成するように仕向ける命令を生成することを特徴とする、請求項２〜４のいずれかに記載の方法。
6. 前記差分的更新命令の生成は、遠隔データ処理システムにより実行されることを特徴とする、請求項２〜４のいずれかに記載の方法。
7. 前記携帯端末と前記遠隔データ処理システムは無線通信リンクを介して通信を行うことを特徴とする、請求項６に記載の方法。
8. 前記携帯端末と前記遠隔データ処理システムはインターネットプロトコルを介して通信を行うことを特徴とする、請求項６または７に記載の方法。
9. 前記検出は、前記携帯端末により実行され、前記検出は、さらに、前記携帯端末から前記検出された汚染部分についての情報を前記遠隔データ処理システムに送信することを含むことを特徴とする、請求項６〜８のいずれかに記載の方法。
10. 前記方法は、さらに、前記携帯端末から前記格納されたデータについての情報を前記遠隔データ処理システムに送信し、その場合に、前記検出は前記データ処理システムにより前記送信された情報に基づいて実行されることを特徴とする、請求項６〜８のいずれかに記載の方法。
11. 前記検出は、前記携帯端末により複数のチェックサムを計算し、その場合に、各チェックサムは前記携帯端末に格納された前記データの対応する部分に対応し、前記計算されたチェックサムを複数の参照チェックサムと比較して汚染されたデータを識別することを特徴とする、請求項１〜１０のいずれかに記載の方法。
12. 前記参照チェックサムは前記携帯端末に格納されており、前記比較は前記携帯端末により実行されることを特徴とする、請求項９に従属する請求項１１に記載の方法。
13. 前記携帯端末に格納された前記参照チェックサムはＭＡＣ（message authentication code）により整合性保護されていることを特徴とする、請求項１２に記載の方法。
14. 前記参照チェックサムは前記遠隔データ処理システム上に格納されており、前記送信される情報は前記計算されたチェックサムを含み、前記検出は、さらに、前記遠隔データ処理システムにより前記送信された計算されたチェックサムを前記遠隔データ処理システム上に格納された参照チェックサムの数と比較することを含むことを特徴とする、請求項１０に従属する請求項１１に記載の方法。
15. 前記計算は、前記チェックサムを前記格納されたデータの対応する部分の暗号的に強化された一方向ハッシュ関数として計算することを含むことを特徴とする、請求項１１〜１４のいずれかに記載の方法。
16. データを格納するデータメモリと、
    データ処理システムから差分的更新命令を受信し、前記データメモリ内に格納されたデータを第１のデータバージョンから更新データバージョンに更新するように構成された通信手段と、
    前記更新データバージョンを前記格納されたデータと前記受信された差分的更新命令とから生成するように構成された処理手段と、から成る携帯端末であって、
    前記処理手段は、さらに、前記格納されたデータから、前記第１のデータと一致しない１または２以上の前記データの汚染された部分の存在または不存在を示す情報を生成し、前記生成された情報を、前記通信手段を介して、前記処理システムに送信して前記差分的更新命令を生成するように構成されていることを特徴とする、携帯端末。
17. 携帯端末内に格納されたデータを第１のデータバージョンから更新データバージョンに差分的に更新させるデータ処理システムであって、前記携帯端末に差分的更新命令をロードする手段と、前記差分的更新命令により前記携帯端末に前記格納されたデータと前記ロードされた差分的更新命令から前記更新データバージョンを生成させることを含むデータ処理システムにおいて、
    前記データ処理システムは、さらに、
    前記第１のデータバージョンと一致しない１または２以上の前記格納されたデータの汚染部分の存在または不存在を示す情報を前記携帯端末から取得する手段と、
    前記第１のデータバージョンと前記更新データバージョンとからおよび前記取得した情報から前記差分的更新命令を生成し、前記差分的更新命令に修正命令を含ませ、その場合に、前記修正命令は前記携帯端末に検出された汚染部分を修正させるものであるように構成された処理手段とを含むことを特徴とするデータ処理システム。
18. 携帯端末に前記携帯端末内に格納されたデータを第１のデータバージョンから更新データバージョンに以下のステップにより差分的に更新させるように構成されたプログラムコード手段を含むことを特徴とするコンピュータプログラムであって、
    前記プログラムが前記携帯端末上で実行される場合に、前記ステップは、
    前記第１のデータバージョンと一致しない１または２以上の前記格納されたデータの汚染部分の存在または不存在を示す情報を前記格納されたデータから生成し、
    前記携帯端末に差分的更新命令をロードし、
    前記携帯端末により、前記格納されたデータと検出された汚染部分を修正することを含む前記ロードされた差分的更新命令とから更新されたデータバージョンを生成させることを特徴とする、コンピュータプログラム。
19. データ処理システムに、携帯端末内に格納されたデータを第１のデータバージョンから更新データバージョンに以下のステップにより差分的に更新させるように構成されたプログラムコード手段を含むことを特徴とするコンピュータプログラムであって、
    前記プログラムが前記データ処理システム上で実行される場合に、前記ステップは、
    前記第１のデータバージョンおよび前記更新データバージョンと前記携帯端末から取得した情報から差分的更新命令を生成し、その場合に、前記取得した情報は、前記第１のデータバージョンと一致しない１または２以上の前記格納されたデータの汚染部分の存在または不存在を示すものであり、前記差分的更新命令の生成は、前記差分的更新命令に修正命令を含ませ、その場合に、前記修正命令は前記携帯端末に検出された汚染部分を修正させるものであるように構成されており、
    前記生成された差分的更新命令を携帯端末にロードし、前記差分的更新命令により前記携帯端末に前記格納されたデータと前記ロードされた差分的更新命令から前記更新データバージョンを生成させることを特徴とする、コンピュータプログラム。
20. 請求項１８または１９に記載のコンピュータプログラムを含むコンピュータ読み取り可能な記録媒体。
21. 前記携帯端末に格納されたデータを第１のデータバージョンから更新データバージョンに差分的更新することを特徴とする、請求項１６に記載された携帯端末の使用方法。
    
    
    
    
    
    

Images