(57)【要約】  【課題】記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するための方法およびシステムである。  【解決手段】更新コマンドを含む更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成されている。更新は、更新シーケンスに従って行なわれる。本方法は、更新の方向を決定するステップを含む。方向が順方向を示す場合、本方法は、記憶されたバージョンを更新されたバージョンに順方向に更新する。方向がロールバックを示す場合、本方法は、更新シーケンスに従って、更新シーケンスと逆のロールバック更新シーケンスを生成し、ロールバック更新シーケンスに従って、記憶されたバージョンを元のバージョンにロールバックする。
2008501180.tif 000002
【特許請求の範囲】
【請求項１】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するための方法であって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記更新パッケージは更新コマンドを含み、前記更新は更新シーケンスに従って行なわれ、前記方法は、
前記更新の方向を決定するステップを含み、
前記ステップは、前記方向が順方向を示す場合、前記更新シーケンスに従って、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新することと、
前記方向がロールバック（roll-back）を示す場合、前記更新シーケンスと逆のロールバック更新シーケンスを生成し、前記ロールバック更新シーケンスに従って、前記記憶されたバージョンを前記元のバージョンにロールバックする（rolling- back）こととを含む方法。
【請求項２】
前記記憶されたバージョンは、元のバージョン、更新されたバージョンおよび中間バージョンを含む群のうちの１つである、請求項１に記載の方法。
【請求項３】
前記更新パッケージは更新コマンドを含み、各更新コマンドは、コピー更新コマンド、削除更新コマンド、挿入更新コマンドおよび置換更新コマンドを含む群のうちの１つである、請求項１および２に記載の方法。
【請求項４】
順方向更新は、前記更新シーケンスに従って、前記更新コマンドに直接対応する更新動作を行う、先行する請求項のいずれかに記載の方法。
【請求項５】
ロールバックは、前記ロールバック更新シーケンスに従って、更新コマンドに逆に対応する更新動作を行う、先行する請求項のいずれかに記載の方法。
【請求項６】
前記記憶されたバージョンからコンテンツを削除する前に、前記更新は、削除されるコンテンツを保持することを含む、先行する請求項のいずれかに記載の方法。
【請求項７】
削除コマンドに逆に対応する更新コマンドが、保持されたコンテンツを用いる、請求項６に記載の方法。
【請求項８】
更新処理を反転させるための方法であって、前記更新処理は、記憶装置に記憶されたコンテンツの記憶されたバージョンを、更新されたバージョンおよび元のバージョンを含む群のうちの１つに更新パッケージを用いて更新するように構成され、前記方法は、
更新中に前に実行された前記更新パッケージの更新コマンドを反転させるステップを含む方法。
【請求項９】
更新は、記憶されたバージョンを更新されたバージョンに順方向に更新することである、請求項８に記載の方法。
【請求項１０】
更新は、記憶されたバージョンを元のバージョンにロールバックすることである、請求項８に記載の方法。
【請求項１１】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いてインプレース更新（in-place updating）するための方法であって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記方法は、
前記更新の方向を決定するステップと、
前記方向が順方向を示す場合、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新し、
そうでない場合、前記記憶されたバージョンを前記元のバージョンにロールバックするステップとを含む方法。
【請求項１２】
記憶されたバージョンの更新処理を実現するための方法であって、
前記記憶されたバージョンを第１のバージョンに更新するための順方向更新を実現するステップと、
前記記憶されたバージョンを第２のバージョンに更新するためのロールバック更新を実現するステップと、
前記順方向更新および前記ロールバック更新のうちのいずれかである第１の更新動作を適用するステップと、
前記順方向更新および前記ロールバック更新のうちのいずれかであって、前記第１の更新動作以外の第２の更新動作を適用するステップとを含む方法。
【請求項１３】
記憶されたバージョンの更新処理を実現するための方法であって、
前記記憶されたバージョンを元のバージョンに更新するためのロールバック更新を適用するステップを含む方法。
【請求項１４】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するためのシステムであって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記更新パッケージは更新コマンドを含み、前記更新は更新シーケンスに従って行なわれ、前記システムは、
前記更新の方向を決定するように構成された方向決定ユニットと、
前記方向決定ユニットに接続され、前記更新の方向が順方向を示す場合、前記更新シーケンスに従って、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新する順方向更新処理装置と、
前記方向決定ユニットに接続され、前記方向がロールバックを示す場合、前記更新シーケンスと逆のロールバック更新シーケンスを生成するロールバックシーケンス生成器と、
前記ロールバックシーケンス生成器に接続され、前記ロールバック更新に従って、前記記憶されたバージョンを前記元のバージョンにロールバックするロールバック更新処理装置とを備えるシステム。
【請求項１５】
前記方向決定ユニットは方向指示に従って方向を決定する、請求項１４に記載のシステム。
【請求項１６】
前記記憶されたバージョンは、元のバージョン、更新されたバージョンおよび中間バージョンを含む群のうちの１つである、請求項１４および１５のいずれかに記載のシステム。
【請求項１７】
更新処理を反転させるためのシステムであって、前記更新処理は、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新されたバージョンおよび元のバージョンを含む群のうちの１つに更新パッケージを用いて更新するように構成され、前記システムは、
更新中に前に実行された前記更新パッケージの更新コマンドを反転させる更新コマンド反転ユニットを備えるシステム。
【請求項１８】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いてインプレース更新するためのシステムであって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記システムは、
前記更新の方向を決定するように構成された方向決定ユニットと、
前記方向決定ユニットに接続され、前記方向が順方向を示す場合、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新する順方向更新処理装置と、
前記方向決定ユニットに接続され、前記方向がロールバックを示す場合、前記記憶されたバージョンを前記元のバージョンにロールバックするロールバック更新処理装置とを備えるシステム。
【請求項１９】
コンピュータ上で動作する、請求項１から７の前記ステップの全てを実行するためのコンピュータプログラムコード手段を含むコンピュータプログラム。
【請求項２０】
コンピュータで読み取り可能な媒体上に実施された、請求項１９に記載のコンピュータプログラム。
【請求項２１】
請求項８〜１０の前記ステップの全てを実行するためのコンピュータプログラムコード手段を含むコンピュータプログラムであって、コンピュータ上で動作するプログラム。
【請求項２２】
コンピュータで読み取り可能な媒体上に実施された、請求項２１に記載のコンピュータプログラム。
【請求項２３】
請求項１１の前記ステップの全てを実行するためのコンピュータプログラムコード手段を含むコンピュータプログラムであって、コンピュータ上で動作するプログラム。
【請求項２４】
コンピュータで読み取り可能な媒体上に実施された、請求項２３に記載のコンピュータプログラム。
【請求項２５】
請求項１２の前記ステップの全てを実行するためのコンピュータプログラムコード手段を含むコンピュータプログラムであって、コンピュータ上で動作するプログラム。
【請求項２６】
コンピュータで読み取り可能な媒体上に実施された、請求項２５に記載のコンピュータプログラム。
【請求項２７】
請求項１３の前記ステップの全てを実行するためのコンピュータプログラムコード手段を含むコンピュータプログラムであって、コンピュータ上で動作するプログラム。
【請求項２８】
コンピュータで読み取り可能な媒体上に実施された、請求項２７に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新することに関する。より詳細には、本発明はインプレース更新（in-place updating）に関する。
【背景技術】
【０００２】
記憶装置に記憶されたコンテンツを更新することが必要となる場合がある。例えば、コンテンツがソフトウェア（実行可能なファイル等）である場合、時としてソフトウェアをアップグレードする必要がある。しかし、注目すべきは、データベース等に記憶されたテキストやデータといったその他のタイプのコンテンツもまた時として更新が必要となるということである。以下、「旧バージョン」または「元のバージョン」という用語は更新前のコンテンツを指し、「新バージョン」または「更新されたバージョン」という用語は更新が行なわれた後のコンテンツを指す。「差分（difference）」、「差分結果（difference result）」または「デルタ」と呼ばれることもある「更新パッケージ」は、更新処理のための入力として提供されるデータを含み、更新処理は、更新パッケージに従って旧バージョンを新バージョンに更新する。
【０００３】
更新パッケージを生成し、それらをバージョンの更新に用いるいくつかの方法が当該技術分野において知られている。例えば、米国特許第６,５４６,５５２号（「内部レファレンスを含むデータ表の２つのバージヨン間の差分抽出方法（Difference extraction between two versions of data-tables containing intra-references）」、２００３年公開）には、旧プログラムと新プログラムとの間のコンパクトな差分結果を生成する方法が開示されている。各プログラムは、当該プログラムの他のエントリを参照するレファレンスを格納するレファレンスエントリを含む。米国特許第６，５４６，５５２号の方法によれば、旧プログラムは走査され、各レファレンスエントリ毎に、レファレンスは区別ラベルマーク（distinct label mark）により置換され、それにより、修正された旧プログラムが生成される。また、米国特許第６，５４６，５５２号によれば、新プログラムは走査され、各レファレンスエントリ毎に、レファレンスは区別ラベルマークにより置換され、それにより、修正された新プログラムが生成される。よって、修正された旧プログラムおよび修正された新プログラムを直接的または間接的に利用することにより、差分結果が生成される。
【０００４】
ＷＯ２００４／１１４１３０（「記憶装置に記憶されたコンテンツのバージョンの更新方法およびシステム（Method and system for updating versions of content stored in a storage device）」、２００４年公開）には、コンテンツの旧バージョンとコンテンツの新バージョンとの間のコンパクトな更新パッケージを生成するシステムおよび方法が開示されている。ＷＯ２００４／１１４１３０のシステムは、旧バージョンおよび新バージョンに対応付けられた変換要素を生成する変換要素生成器を備える。また、修正されたバージョンを生成する修正バージョン生成器、およびコンパクトな更新パッケージを生成する更新パッケージ生成器も備える。コンパクトな更新パッケージは、変換要素、および修正されたバージョンと新バージョンとに基づく修正されたデルタを含む。
【０００５】
ＷＯ２００５／００３９６３（「記憶装置に記憶されたコンテンツのバージョンの更新方法およびシステム（Method and system for updating versions of content stored in a storage device）」、２００５年公開）には、記憶装置に記憶されたコンテンツのバージョンを更新するためのシステムおよび方法が開示されている。ＷＯ２００５/００３９６３のシステムは、変換要素および小さなデルタを取得するための更新モジュールを備える。また、変換要素を旧バージョンのアイテムに適用することにより、変換された旧アイテムを生成する変換済み旧アイテム生成器、修正されたデータエントリと変換された旧アイテムとに基づいてデータエントリを生成するデータエントリ生成器、ならびにコマンドおよびデータエントリを旧バージョンに適用することにより、コンテンツの新バージョンを生成する新バージョン生成器も備える。
【０００６】
米国特許第６，８３２，３７３号（「情報の更新・配信システムおよび方法（System and method, for updating and distributing information）」、２００４年公開）には、ソフトウェア、装置、およびデータによって構成される、デジタル情報シーケンスを更新するための装置、システムおよび方法が開示されている。また、これらのデジタル情報シーケンスは、ファイル、記憶域、および／または内蔵記憶域をはじめとする様々な形態で記憶および使用され得るが、これらに限定されるものではない。さらに、米国特許第６，８３２，３７３号に記載の装置、システムおよび方法は、必要に応じて更新情報を生成する能力を当該技術分野の開発者に与え、加えて、エラーが発生しにくく、米国特許第６，８３２，３７３号が出願された時点の既存の技術を用いるよりも迅速に実行し得る簡略化された更新パスをユーザが経ることを可能にする。
【０００７】
コンテンツはディスクやメモリ等の記憶装置に記憶することができ、記憶装置の中にはブロックに組織化されているものがあることは、当業者に知られている。元のバージョンの一部であるブロックを「旧ブロック」または「元のブロック」と呼び、更新されたバージョンの一部であるブロックを「新ブロック」または「更新されたブロック」と呼ぶ。また、元のバージョンを更新し、それによって更新されたバージョンを形成する際、更新されたバージョンは、元のバージョンのブロックに前に記憶されたコンテンツを使用する場合がある。すなわち、更新されたブロックのコンテンツは、元のブロックのコンテンツに類似している場合がある。
【０００８】
さらに、入手可能な記憶装置は、限られたスペース有することがある。よって、記憶装置内のバージョンを更新している間、旧バージョンに代えて新バージョンを記憶し、それによってスペースを節減することが好ましい場合がある。旧バージョンによって前に占められていたスペースの少なくとも一部を新バージョンが占める、このような更新処理は、当該技術分野において「インプレース更新（in-place update）」または「インプレースでの更新（updating in-place）」と呼ばれる。
【０００９】
なお、更新処理は、ファイル内のブロックの連続的な順序とは必ずしも対応しない順序で旧バージョンのブロックを処理することがある。旧バージョンのブロックが更新されるこの順序を、「更新シーケンス」または「更新順序」と呼ぶ。
【００１０】
インプレース更新の結果の一つとして、一旦記憶ブロックが更新されると、元のバージョンの一部である、記憶ブロックの少なくとも一部のコンテンツ（すなわち、元のコンテンツの少なくとも一部）は場合によっては失われるということがある。したがって、一旦更新処理が開始し、一部の旧ブロックが修正されて更新されたコンテンツ（更新されたバージョンの一部である更新されたコンテンツ）が保持された後、記憶装置は、部分的にオリジナルであって、部分的に更新されたバージョンであるコンテンツを記憶していることがある。
【００１１】
また、デルタ更新においてそうであるように、更新処理で旧コンテンツが必要となる場合があることが当該技術分野で知られている。したがって、新バージョンの生成が完了する前に、更新処理が実行中に中断されると、記憶されたコンテンツ（または記憶されたバージョン）が部分的に旧バージョンであり、かつ部分的に新バージョンである場合、インプレース更新処理を最初から繰り返すことはできなくなる。
【００１２】
上記に鑑み、インプレース更新は、中断に弱い場合があることが理解される。インプレース更新の処理を、それが中断された点（再開位置）から再開しようとすると、中断位置の計算を可能にする情報が必要となる。中断位置を見つけた後、更新処理には、中断の時点で中断された処理に対して入手可能であったその他の情報を復元することも必要となりうる。
【００１３】
現在、当該技術分野においては、中断前に計算された計算結果を記憶するために、以下において「状態レコード」と呼ぶレコードが一般に用いられている。これらの結果は、現在の更新されたブロックのＩＤと共に、インプレース更新処理の状態を形成する。例えば、更新パッケージが圧縮され、各旧ブロックの更新に必要な部分だけを読み出す更新処理中にオンザフライで（on-the-fly）解凍されている場合、更新パッケージから解凍されたデータ量が更新されたブロックの旧コンテンツに依存していると、この量は、一旦ブロックが実際に更新されると再計算することはできない。
【００１４】
既に上述したように、処理を最初から再開することはできない。したがって、状態レコード内のデータの一部は、最後に更新されたレコードがわかっている場合であっても再計算することができず、他の手段で再現する必要がある、ということが考えられる。先行技術では、上記のような状態レコードを更新処理にアクセス可能な記憶装置に維持し、更新処理中にそれを周期的に更新してその進行を反映させることが一般的に行なわれており、以下において、これを「状態記録」と呼ぶ。状態記録を用いることにより、処理状態を、最後に成功した動作におけるもののように再構築することによってインプレース更新処理の再開を可能にし、完了に向けて処理を継続することが可能となる。
【００１５】
場合によっては、状態記録中に記憶された情報は、更新中のコンテンツの一部をなすことはできず、別の記憶領域に分離されなければならない。状態記録は、記憶装置に対する読み書き動作を伴うため、時間を要する。記憶装置への読み書き動作がブロック全体に対してのみ許されるような場合には、処理全体に要する時間は２倍になる（各更新されたブロックには、更新すべき別のブロック、すなわち状態レコードを保持しているブロックが存在する）。
【００１６】
中断されたインプレース更新処理を適切に再開するためには、記憶書込動作の中断の結果である破損ブロックに対処することも必要であることも当業者に知られている。ブロックの旧コンテンツが修正されているため、当該ブロック内の情報を復元するのは不可能であるかもしれず、ファイルの他のブロックを検査することだけで旧コンテンツを復元する方法はないかもしれない。この問題は、あらゆるブロックの新コンテンツが最初に記憶されるバックアップバッファを用い、更新すべき目標ブロックにそのコンテンツをコピーすることにより（以下、「アップデート・ファースト（update-first）」という）先行技術によって解決されるか、あるいは、旧ブロックがバックアップバッファにコピーされた後に、新コンテンツが生成され、その目標ブロックに記憶される（以下、「バックアップ・ファースト（backup-first）」という）。この方法は、当該技術分野において「２相コミット（2-phase commit）方式」としても知られている。
【００１７】
携帯電話等の埋め込み式機器のソフトウェアの更新は、インプレース更新手順の一例である。携帯電話の記憶容量は限られていることがあることが理解される。例えば、携帯電話は、そのソフトウェア（ファームウェアとも呼ばれる）の１つのバージョンを保持する分しか記憶容量を有していないことがある。状態記録をファームウェア自体のブロック内で維持することは明らかに非実用的である。なぜならば、これはソフトウェアの生成処理と大きく干渉することになり、したがって、別の記憶領域に記憶されなければならないからである。携帯電話のファームウェアの更新は、使用される記憶装置（フラッシュメモリ）の速度のために、比較的ゆっくりとした処理である。更新処理中、電話は動作不能であり、処理にかかる時間を最小限にする必要が生じる。
【００１８】
ソフトウェア更新中の埋め込み式機器の動作における中断の短縮を可能にする、より高速で信頼できる更新手順が当該技術分野において必要とされている。
【００１９】
記憶装置に記憶されたコンテンツのバージョンを更新するための新たな方法およびシステムを提供することが当該技術において必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
したがって、本発明は、記憶装置に記憶されたコンテンツのバージョンを更新するための新たな方法およびシステムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明は、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するための方法であって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記更新パッケージは更新コマンドを含み、前記更新は更新シーケンスに従って行なわれ、前記方法は、
前記更新の方向を決定するステップを含み、前記ステップは、前記方向が順方向を示す場合、前記更新シーケンスに従って、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新することと、前記方向がロールバック（roll-back）を示す場合、前記更新シーケンスと逆のロールバック更新シーケンスを生成し、前記ロールバック更新シーケンスに従って、前記記憶されたバージョンを前記元のバージョンにロールバックする（rolling- back）こととを含む方法を提供する。
【００２２】
本発明は、さらに、更新処理を反転させるための方法であって、前記更新処理は、記憶装置に記憶されたコンテンツの記憶されたバージョンを、更新されたバージョンおよび元のバージョンを含む群のうちの１つに更新パッケージを用いて更新するように構成され、前記方法は、更新中に前に実行された前記更新パッケージの更新コマンドを反転させるステップを含む方法を提供する。
【００２３】
さらに、本発明により、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いてインプレース更新（in-place updating）するための方法であって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記方法は、前記更新の方向を決定するステップと、前記方向が順方向を示す場合、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新し、そうでない場合、前記記憶されたバージョンを前記元のバージョンにロールバックするステップとを含む方法が提供される。
【００２４】
さらに、本発明により、記憶されたバージョンの更新処理を実現するための方法であって、前記記憶されたバージョンを第１のバージョンに更新するための順方向更新を実現するステップと、前記記憶されたバージョンを第２のバージョンに更新するためのロールバック更新を実現するステップと、前記順方向更新および前記ロールバック更新のうちのいずれかである第１の更新動作を適用するステップと、前記順方向更新および前記ロールバック更新のうちのいずれかであって、前記第１の更新動作以外の第２の更新動作を適用するステップとを含む方法が提供される。
【００２５】
さらに、本発明により、記憶されたバージョンの更新処理を実現するための方法であって、前記記憶されたバージョンを元のバージョンに更新するためのロールバック更新を適用するステップを含む方法が提供される。
【００２６】
さらに、本発明により、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するためのシステムであって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記更新パッケージは更新コマンドを含み、前記更新は更新シーケンスに従って行なわれ、前記システムは、前記更新の方向を決定するように構成された方向決定ユニットと、前記方向決定ユニットに接続され、前記更新の方向が順方向を示す場合、前記更新シーケンスに従って、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新する順方向更新処理装置と、前記方向決定ユニットに接続され、前記方向がロールバックを示す場合、前記更新シーケンスと逆のロールバック更新シーケンスを生成するロールバックシーケンス生成器と、前記ロールバックシーケンス生成器に接続され、前記ロールバック更新に従って、前記記憶されたバージョンを前記元のバージョンにロールバックするロールバック更新処理装置とを備えるシステムが提供される。
【００２７】
本発明は、更新処理を反転させるためのシステムであって、前記更新処理は、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新されたバージョンおよび元のバージョンを含む群のうちの１つに更新パッケージを用いて更新するように構成され、前記システムは、更新中に前に実行された前記更新パッケージの更新コマンドを反転させる更新コマンド反転ユニットを備えるシステムを提供する。
【００２８】
さらに、本発明により、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いてインプレース更新するためのシステムであって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記システムは、前記更新の方向を決定するように構成された方向決定ユニットと、前記方向決定ユニットに接続され、前記方向が順方向を示す場合、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新する順方向更新処理装置と、前記方向決定ユニットに接続され、前記方向がロールバックを示す場合、前記記憶されたバージョンを前記元のバージョンにロールバックするロールバック更新処理装置とを備えるシステムが提供される。
【発明を実施するための最良の形態】
【００２９】
本発明を理解し、それが実際にどのように実施され得るかを知るために、添付の図面を参照しながら、好ましい実施形態を非限定的な例としてのみ以下に説明する。
【００３０】
以下の説明において、２つ以上の図面に共通する構成要素には、同一の参照符号が付されている。
【００３１】
さらに、特に示さない限り、以下において、「更新」という用語はインプレース更新を指すものとして用いられる。
【００３２】
図１は、本発明の一実施形態に係る、セルラーネットワークにおいてバージョンを更新するためのシステム１０１の概略図である。記憶装置１０３に接続されている、または含まれる携帯電話１０２は、各自の動作を可能にするプログラムを実行する。プログラムは、通常、ファイルに記憶されている。以下において、携帯電話内で現在実行中のプログラムのバージョンを「旧バージョン」または「元のバージョン」という。
【００３３】
なお、記憶装置１０３等の記憶装置は、「記憶装置」または「メモリユニット」とも呼ばれる場合がある。
【００３４】
電話１０２がその新たなバージョンを実行するためにプログラムの更新が必要となる場合がある。このような更新されたバージョンは、電話内で動作している更新処理によって生成される。更新処理は、携帯電話が受信する更新パッケージ（「デルタファイル」を構成する）に従って動作する。
【００３５】
本発明によれば、更新パッケージは、例えばパーソナルコンピュータ（ＰＣ）またはその他のあらゆるタイプのコンピュータ内で動作している更新パッケージ生成器１０４において生成される。更新パッケージは、更新サーバ１０５に記憶され、送信機１０６を介して携帯電話１０２に送信される。
【００３６】
なお、図１に示すシステム１０１は、非限定的な例であり、本発明はプログラムの更新に限定されるものではない。データベースに記憶されたデータや記憶装置に記憶されたファイルといった、記憶装置に記憶されたその他の多くのタイプのコンテンツが更新を必要とする。したがって、以下において、「プログラム」の代わりに、「コンテンツ」という用語を用いる。
【００３７】
同様に、本発明は、セルラーネットワークおよび／または携帯電話１０２に限定されるものではない。携帯電話は、埋め込み式機器と称されるグループに属すると理解される。コンテンツを記憶するために記憶装置に接続された携帯情報端末（ＰＤＡ）、セットトップボックスおよびそれ以外の民生用電子機器といったその他の埋め込み式機器があり、それらに記憶されたコンテンツの更新が時として必要となる。しかし、ＰＣやその他のコンピュータ等の非埋め込み式機器に接続された記憶装置に記憶されたコンテンツも更新することが可能である。したがって、記憶装置１０３は、例えば、ハードディスクドライブ、フラッシュメモリ装置またはその他のあらゆる記憶装置でありうる。
【００３８】
例えば、ＰＣやその他のコンピュータは、その動作、またはその内部で実行されるプログラムの動作に必要なデータ（当業者に知られる「ｉｎｆｏファイル」または「ｄｏｔファイル」等）を含むファイルを記憶し得る。時として、例えば通信回線を介して（インターネットやその他の通信手段を介して）このデータを更新することが必要となる。
【００３９】
これをふまえ、「電話」、「ＰＤＡ」、「民生用電子機器」、「コンピュータ」、「ＰＣ」等の用語を用いる代わりに、以下においては「更新された装置（updated devices）」という用語を用いる。なお、「更新装置（update device）」という用語は、記憶装置に接続され、かつそこに記憶されたコンテンツの更新を可能にするあらゆる装置を意味し得る。
【００４０】
記憶装置に記憶されたコンテンツを更新するために、更新パッケージが生成され、更新サーバ１０５に記憶され、記憶装置またはこれらに接続されたその他の装置（携帯電話１０２等）に送られることは既に説明した。代わりに、更新パッケージを、最初に更新サーバ１０５に記憶することなく送ることが可能である。例えば、更新パッケージを、それが生成される更新パッケージ生成器から直接送ることが可能である。このような場合、更新生成器が動作する機器または更新生成器それ自体が更新サーバ１０５であると考えられる。
【００４１】
さらに、図１に示す例において、更新パッケージは、送信機１０６を介して送られる。これにもまた限らず、更新パッケージを送るために適用可能なその他のあらゆる方法を用いることができる。例えば、更新パッケージをフロッピーディスクやディスクオンキー等の携帯用記憶装置上に記憶し、それによって、更新された装置（電話１０２等）が更新パッケージをそこから読み出すことにより、これにアクセスすることを可能にすることができる。
【００４２】
携帯電話１０２は、更新パッケージを受信すると、更新パッケージに従って更新処理を動作させることができ、更新処理は、「更新されたバージョン」または「新バージョン」と呼ぶ別のバージョンを生成するために元のバージョンを更新する。なお、携帯電話１０２は、更新パッケージを受信した直後に更新処理を作動させることができる。あるいは、記憶装置１０３内というように、不揮発性メモリ内に更新パッケージを記憶し、また後で（例えば、電話が次に再起動した際に）更新処理を動作させることができる。
【００４３】
なお、記憶装置は、元のバージョンおよび／または更新されたバージョンのコンテンツを記憶することができる。当業者であれば、コンテンツは通常ファイルに記憶され、ファイルまたはそこに記憶されたコンテンツに対して更新処理によって更新が行なわれることを理解するであろう。
【００４４】
多くの場合、ファイルは論理的に連続したコンテンツで構成される。例えば、テキストが「１２３４５６７８９」であるテキストを含むファイルにおいて、文字「２」は文字「１」に論理的に連続し、文字「３」は文字「２」に論理的に連続している。しかし、当業者であれば、このファイルを記憶装置に記憶する際、ファイルが断片化し得ること、すなわち、ファイルの異なる部分が記憶装置の異なる領域に保存され得ることを理解するであろう。換言すれば、論理的に連続したコンテンツは、記憶装置において物理的に連続して記憶されるとは限らない。
【００４５】
さらに、当業者は、多くの記憶装置はその内部に個別の領域を含むことを理解するであろう。例えば、ハードドライブは、セクタを有し、フラッシュメモリモジュールもまた同様である。記憶装置内の個別の領域を、「記憶ブロック」、または単に「ブロック」と呼ぶ。しかし、ハードドライブおよびフラッシュメモリモジュールは、記憶装置の２つの例にすぎない。ランダムアクセスメモリ（ＲＡＭ）等の、それ自体が公知であるその他の記憶装置が存在している。
【００４６】
論理的に連続したコンテンツは記憶装置に物理的に連続して記憶されるとは限らないという点をふまえると、連続したコンテンツはいくつかの記憶ブロックに散在し得ることが理解される。さらに、１つの記憶ブロックは、いくつかの論理的に連続したコンテンツ（いくつかのファイル等）に属するコンテンツを含みうる。上記の例に戻り、テキスト「１２３４５６７８９」が論理的に連続したコンテンツを構成している場合、コンテンツ「１２３４」は１つの物理ブロックに記憶され得る一方、この例のコンテンツ「５６７８９」は「１２３４」が記憶されたブロックに物理的に先行する異なる物理ブロックに記憶され得ることが理解される（しかし、コンテンツ「１２３４」がコンテンツ「５６７８９」に物理的に先行することは明らかである）。
【００４７】
さらに、論理的に連続したテキスト「１２３４５６７８９」は、元のバージョンであると考えられる。本例によれば、このファイルを、更新されたバージョンを含むように更新することが可能であり、更新されたバージョンに記憶されたテキストは「１２３７５６４８９」である。この更新されたバージョンにおいて、文字「４」と「７」は、元のバージョンと比較すると、その位置が入れ替えられており、言い換えると、更新されたバージョンにおいては、文字「７」は元のバージョンに見られる文字「４」に取って代わり、文字「４」は文字「７」に取って代わる。したがって、この更新されたバージョンを生成するために、元のバージョンをいくつかのセグメントに分割することが可能である（各セグメントは「論理ブロック」を構成する）ことが理解される。例えば、第１のセグメントはコンテンツ「１２３」を含み、第２のセグメントのコンテンツは「４」であり、第３のセグメントは「５６」を含み、第４のセグメントは「７」を含み、第５のセグメントは「８９」を含む。更新されたバージョンを生成する際、第１、第３および第５のセグメントはそのままにされる一方、第２および第４のセグメントは入れ替えられる。したがって、セグメントは論理的に連続したコンテンツを含む。
【００４８】
セグメントは、更新中に一様な動作を行うコンテンツの論理的に連続したセグメントであるとさらに定義することが可能である。本例において、セグメント「１２３」は論理的に連続しており、更新されたバージョンにおいて、一様に、修正されない状態のままである。同様に、例えば、セグメント「７」もまた、論理的に連続しており（１文字のシーケンスは有効なシーケンスである）、前に「４」によって占められていた位置を占めるように一様に移動させられる。
【００４９】
各セグメントが論理的に連続したコンテンツを含み、更新中に一様な動作を行う、「１２３４５６７８９」テキストの上記の例および更新されたバージョン「１２３７５６４８９」への更新は簡略化された例である。他の例において、コンテンツを論理的に連続したセグメントに分割し、更新中に一様な動作を行ない、１つ以上の物理ブロックにおける物理的に連続した領域を占めることが可能である。したがって、第１のブロックに「１２」が記憶され、第２のブロックに「３」が記憶され、「１２」が「３」に連続的に先行しないように「１２３」が断片化されている場合、本例によれば、「１２３」は、論理的に連続してはいるが、２つのセグメント（具体的には、「１２」および「３」が存在する）に分割される。
【００５０】
しかし、後者の例において、ブロックが連続（第１のブロックは、第２のブロックに連続的に先行する）していて、かつ文字「１」が第１のブロックが終わる領域に記憶され、文字「２」が第２のブロックが始まる領域に記憶されている限り、セグメント「１２」は２つの異なるブロック上に存在することが可能である。
【００５１】
後者の例は、非限定的である。例えば、別の実施形態では、（上記例の「１つ以上」とは異なり）１つの物理ブロックにおける物理的に連続した領域を占めるようにセグメントを制限することができる。したがって、「１２」が２つの連続したブロックに連続的に記憶されている場合、これを２つのセグメントにさらに分割しなければならない（１つは「１」であり、もう１つは「２」である）。
【００５２】
更新されたバージョンにおけるセグメント（「更新されたセグメント」）のコンテンツが元のバージョンのセグメント（「元のセグメント」）のコンテンツに対応している場合、これらのセグメントは、「対応するセグメント」または「一致するセグメント」であると考えられる。対応とは、セグメント間のあらゆる論理的なつながりを指し、更新されたセグメントは元のセグメントのコピーであることがあり、それは元のセグメントの修正されたコピーであり得るか（例えば、大きいセグメントにおいては、セグメント全体をコピーし、その後、コピーされたコンテンツの一部を修正することが好ましい場合がある）、あるいは、元のセグメントに記憶されたコンテンツを用いて計算を行うことなどにより受信されたコンテンツを含みうる。
【００５３】
なお、ある１つの元のセグメントに対応して２つ以上の更新されたセグメントが存在することがある（例えば、元のセグメントのコンテンツが２度コピーされ、それにより、それに対応する２つの更新されたセグメントが生成される）。この逆も言える。１つの更新されたセグメントに対応する２つ以上の元のセグメントが存在する場合がある（例えば、１つの更新されたセグメントのコンテンツを計算するために、２つの別個の元のセグメントに記憶されたコンテンツを使用することが可能である）。
【００５４】
元のバージョンを更新されたバージョンに更新するために、更新パッケージに従って更新処理が動作することは既に述べた。一実施形態によれば、更新パッケージは更新コマンド（簡潔にいうと「コマンド」）を含み、各コマンドは、元のバージョンおよび／または更新されたバージョンにおける１つのセグメントに対応している。更新コマンドは、更新動作を示すコードを含むことができ、コードは、例えば、数字コード、ビットマスク、ストリングコードまたはこの場合に適用可能なその他のあらゆるコードでありうることが理解される。
【００５５】
元のバージョンを更新されたバージョンに更新するための異なる更新動作ひいては異なる更新コマンドが存在する。例えば、以下の様なものである。
【００５６】
「削除」コマンドは、更新されたバージョンを生成する際にコンテンツが削除された元のバージョンにおける１つのセグメントに対応する（よって、このコマンドは更新されたバージョンにおけるいかなるセグメントにも対応しない）。元のバージョンにおける削除されたセグメントは、更新されたバージョンにおいて対応するセグメントを有しない。削除コマンドにより、記憶装置内のセグメントは開放され、それにより、セグメントに他のコンテンツを書き込むことが可能になる。すなわち、更新処理は、コンテンツの物理的な削除を必要としない。更新処理は、この領域を空きであるとしてマークするだけである。
【００５７】
「挿入」コマンドは、更新バージョンにおける１つのセグメントに対応し、このセグメント内には新コンテンツが追加される。更新されたバージョンにおける挿入されたセグメントは、元のバージョンにおいて対応するセグメントを有しない。なお、一部の実施形態においては、挿入されたコンテンツが、空きでない領域（すなわち、以前に、例えば削除コマンドによって解放されなかったコンテンツを含む物理領域）に書き込まれる場合、元のコンテンツは、挿入されたコンテンツによってオーバーライドされ、したがって、削除されたものとされる。これらの実施形態において、このような挿入コマンドは、挿入コマンドを後に伴う削除コマンドと等しいと考えられる。
【００５８】
「コピー」コマンドは、元のバージョンにおける１つのセグメント（「元のセグメント」）と、更新されたバージョンにおける１つのセグメント（「更新されたセグメント」）とに対応し、元のセグメントのコンテンツは更新されたセグメントにコピーされる。元のセグメントおよび更新されたセグメントは、対応するセグメントであると考えられる。（コピーコマンドによる）コピー動作を行った後、元のセグメントによって前に占められていた領域は空きであるとされ、よって、他のコンテンツを上書きすることが許される。なお、更新処理は、コンテンツの物理的な削除（解放）を必要としない。更新処理は、この領域を空きであるとしてマークするだけである。また、挿入コマンドと同様に、一部の実施形態では、空きでない領域に書き込まれた挿入されたコンテンツ（すなわち、以前に、例えば削除コマンドによって解放されなかったコンテンツを有する物理領域）が、この解放されていないコンテンツをオーバーライドし、したがって、削除されたものとされる。これらの実施形態において、このようなコピーコマンドは、コピーコマンドを後に伴う削除コマンドと等しいと考えられる。
【００５９】
「置換」コマンドは、元のセグメントのコンテンツを更新バージョンにおける新コンテンツで置換する。よって、これは、１つの元のセグメントと、１つの更新されたセグメントとに対応する。元のセグメントのコンテンツは削除され、補足データ（以下の図４の、置換補足データ部分４１９に記憶されたデータ等）が更新されたセグメントに書き込まれる。しかし、当業者であれば、データを別のものに反転可能に変換するビット毎のＸＯＲ（排他的論理和）といった変換関数が存在することを理解するであろう。例えば、元のセグメントのコンテンツと、更新されたセグメントのコンテンツを生じさせるデータ（「変換データ」）とのビット毎の排他的論理和を取ることが可能である。当業者であれば、更新されたコンテンツと変換データとのビット毎の排他的論理和を取り、元のコンテンツを再び得ることが後に可能となることを理解するであろう（ビット毎の排他的論理和は、数学的に逆戻り可能な（revertible）関数である。すなわち、「Ａ  ＸＯＲ  Ｂ  ＝  Ｃ」である場合、「Ｃ  ＸＯＲ  Ｂ  ＝  Ａ」）である。コンテンツの置換に変換関数を用いる実施形態においては、補足データは変換データを含みうる。
【００６０】
なお、上記のコマンド例は、非限定的なものであり、追加のタイプの更新コマンド（「バックアップ」等）または更新パッケージにおいてより少数のタイプの更新コマンドが存在し得る。例えば、「置換」コマンドの代わりに、上記に説明したような「削除」と「挿入」の組み合わせを用いることが可能であることが理解される。別の例によると、例えば、更新処理に対して、１つのセグメントを削除することだけを命令する単純な更新パッケージ（よって、このパッケージは挿入コマンド、コピーコマンドおよび置換コマンドを含まない）が存在し得る。
【００６１】
１度につき、１つのブロックに記憶されたコンテンツへの（読み出しおよび／または書き込みのための）アクセスを許可する記憶装置１０３が設けられている。このような記憶装置用に適合された更新パッケージにおいては、単一のブロックに対応するコマンドは、グループに組織化されているほうが良く、各グループにおけるコマンドは、１つのブロックに対応し、間に交じった他のブロックに対応するコマンドを含まない。この更新処理を行うことにより、元のブロックから要求された全て元のコンテンツに１回の読み出し動作でアクセスすること、あるいは、更新されたブロックから要求された全ての更新されたコンテンツに１回の書込み動作でアクセスすることが可能である。このような記憶装置に適合された更新パッケージにおける異なるブロックに対応する、交じり合うコマンドは、更新処理がコマンドに従って動作を行う度にブロック全体にアクセスするが、実際にはそのセグメントへのアクセスを必要とする。
【００６２】
図２に移る前に、記憶装置に現在記憶されているバージョンを指すのに「記憶されたバージョン」という用語が用いられていることに注目されたい。記憶されたバージョンは、例えば元のバージョンである可能性があり、例えば以下の図２を参照して示す中間バージョン、あるいは、更新されたバージョンである可能性がある。
【００６３】
図２は、ブロック全体へのアクセスを許可する記憶装置における、元のバージョン２０１の更新されたバージョン２０２への更新の簡略化された段階例を示している。元のバージョン２０１は４つのブロックを含み、これらは具体的には２０３、２０４、２０５および２０６である。本例によると、更新されたバージョン２０２もまた、４つのブロック、すなわち２０７、２０８、２０９および２１０を含み、ブロック２０７はブロック２０３に取って代わり、ブロック２０８はブロック２０４に取って代わり、ブロック２０９はブロック２０５に取って代わり、ブロック２１０はブロック２０６に取って代わる。本例によれば、更新処理は、最初にブロック２０３をブロック２０７で置換する。したがって、記憶されたバージョン２１１は、元のバージョン２０１と更新されたバージョン２０２との組み合わせを含み、第１のブロックは２０７（これは更新されたバージョンに属する）であり、その他のブロック（すなわち、２０４、２０５および２０６）は、依然として元のバージョン２０１に属する。次に、本例によれば、更新処理は、ブロック２０４をブロック２０８で置換し、それにより、記憶されたバージョンは２１２となる。そして、記憶されたバージョン２１３が生成され、最後に、記憶されたバージョンは更新されたバージョン２０２となる。部分的にオリジナルであって、部分的に更新されたバージョン（例えば、バージョン２１１、２１２、２１３）を、「中間バージョン」と呼ぶ。
【００６４】
図２に示す更新処理は、正常にあるいはそうでないかに拘らず、どの段階においても終了し得ることが理解される。したがって、記憶装置に記憶されたバージョンは、バージョン２０１、２１１、２１２、２１３または２０２のいずれでもありうる。さらに、更新されたブロック内のコンテンツを記憶している間に中断が起こりうるため、中断点で最後に更新されたブロックは破損され得る。すなわち、当業者に公知のように未定義のコンテンツを含みうる。
【００６５】
なお、図２を参照して示した例は決して限定的なものではない。元のバージョン、中間バージョンおよび／または更新されたバージョンは、いかなる数のブロックを含む可能性があり、１つのブロックは、適用可能ないかなる数のビットを含む可能性があり、更新処理は、ブロックの置換とは別に、またはこれに加えて、この場合に適応可能なあらゆる動作（ブロックの削除、ブロックの挿入、ブロックの移動等）を行うことができる。
【００６６】
また、ブロックの一部へのアクセスを許可する記憶装置においても、元のバージョン、更新されたバージョンおよび中間バージョンが存在し得る。しかし、これらの場合、図２はブロックではなくセグメントを示すことになる。
【００６７】
図３は、元のバージョン３０１の例および対応する更新されたバージョン３０２の例を示している。元のバージョンは、「ソースバージョン」とも呼ぶ場合があり、更新されたバージョンは、「ターゲットバージョン」とも呼ぶ場合がある。セグメント３０３、３０４、３０５、３０６、３０７および３０８は、共に元のバージョン３０１を構成し、セグメント３０９、３１０、３１１、３１２、３１３、３１４および３１５は、共に更新されたバージョン３０２を構成している。なお、更新されたバージョンと比べて元のバージョンのセグメントの数は少ない（更新されたバージョンが７つのセグメントを有しているのに対して、元のバージョンにおいては６つのセグメント）。したがって、更新処理は、更新されたバージョンに新コンテンツ（本例においては、セグメント３１１および３１３）を挿入したことになる。また、元のバージョンにおけるセグメント３０３、３０５、３０６および３０８のコンテンツは、更新されたバージョンにおけるセグメント３０９、３１２、３１５および３１４のコンテンツとそれぞれ同一であることに注目されたい。すなわち、これらのセグメントの元のコンテンツは、更新されたバージョンにおける対応するセグメント内にコピーされている。さらに、元のバージョンのセグメント３０７のコンテンツは削除され、よって、新バージョンには現れず、セグメント３１０の更新されたコンテンツがセグメント３０４の元のコンテンツに取って代わる。
【００６８】
図３の例において、元のバージョン３０１は、記憶装置内の１つのブロック、具体的にはブロック３１６に記憶されている。更新処理はインプレース更新処理である。すなわち、更新されたバージョンが元のバージョンをオーバーライドするので、更新バージョン３０２もまたブロック３１６に記憶されている。しかし、これには限らず、バージョン（元のバージョンおよび／または更新されたバージョン）は、上記「１２３４５６７８９」の例を参照して既に説明したように、２つ以上のブロックに記憶され得る。また、３０１および３０２を、より大きい元のバージョンおよび更新されたバージョンの一部として考えることもできる。したがって、「元のバージョン３０１」および「更新されたバージョン３０２」という用語は、全体としてのバージョン、またはそこからの１つのブロックを指す。
【００６９】
同図を見ると、元のバージョン３０１の両側を埋める２つの空きセグメントが存在することが示されている。具体的には、これらはセグメント３１８および３１９である。更新されたバージョン３０２を埋める２つの空きセグメント３２０および３２１も存在する。なお、空きセグメント３１８、３１９、３２０および３２１は、元のバージョンまたは更新されたバージョンの一部ではなく、これらは、元のバージョンまたは更新されたバージョンによって占められた際の、ブロック３１６における未使用領域である。これらの空きセグメントは、その他のファイルの一部であるコンテンツを記憶するために用いられる場合がある。本例によれば、空きセグメント３２０は空きセグメント３１８よりも小さく、空きセグメント３２１は空きセグメント３１９よりも小さいことにさらに注目されたい。すなわち、元のバージョン３０１によって占められるスペースは、更新されたバージョン３０２によって占められる大きさよりも小さい。
【００７０】
セグメント３０３および３０９は対応するセグメントである。３０４と３１０、３０５と３１２、３０６と３１５、および、３０８と３１４も同様である。
【００７１】
図４は、図３の元のバージョン３０１をその更新されたバージョン３０２に更新するように構成された別の更新パッケージ４０１および４０２を示している。更新パッケージ４０１は、バージョンを更新するための更新コマンドを含む。コマンド４０３は、更新処理に対し、セグメント３０３の元のコンテンツを更新されたセグメント３０９にコピーするように命令する。更新コマンド４０４は、更新処理に対し、セグメント３０４の元のコンテンツを「置換されたデータ」で置換するように命令し、それにより、更新されたセグメント３１０の更新されたコンテンツが得られる。なお、上記に説明したように、データを置換するためにＸＯＲ等の変換関数を用いることも可能である。このような実施形態において、「置換されたデータ」は変換データを記憶することになる。
【００７２】
コマンド４０５は、セグメント３０７の元のコンテンツを削除する役割を担い、コマンド３０６は、セグメント３０８の元のコンテンツを更新されたセグメント３１４にコピーし、コマンド４０７は、セグメント３０６の元のコンテンツを更新されたセグメント３１５にコピーし、コマンド４０８は、更新処理に対し、「挿入されたデータ」を更新されたセグメント３１３に挿入するよう命令し、コマンド４０９は、更新処理に対し、セグメント３０５の元のコンテンツを更新されたセグメント３１２にコピーするよう命令し、コマンド４１０は、挿入されたデータをセグメント３１１の更新されたコンテンツとして挿入する役割を担う。なお、挿入されたデータおよび／または置換されたデータ等の更新処理に供されるデータは、更新パッケージ４０１の更新コマンドと交じり合っている。データが更新コマンドと交じり合っているこのような更新パッケージを、「データ非区別（indistinct）更新パッケージ」または「データ混交更新パッケージ」と呼ぶ。
【００７３】
なお、更新コマンドが更新パッケージに現れる順序は、元のバージョンおよび／または更新されたバージョンの各セグメントの順序と等しいとは限らない。また、３０１および３０２が元のバージョンまたは更新されたバージョンの一部である場合、更新パッケージは、さらなるブロックのさらなるセグメントを更新するためのさらなるコマンドを含む。この場合、４０１は更新パッケージの一部である。
【００７４】
なお、さらに、一部の更新コマンドに必要な「挿入されたデータ」および「置換されたデータ」等のデータを、通常、「補足データ」と呼ぶ。補足データを必要とする更新コマンドを、「データ消費更新コマンド」と呼ぶ。
【００７５】
更新パッケージ４０２は、元のバージョン３０１から更新されたバージョン３０２を生成する別の更新パッケージ（またはその一部）である。更新パッケージ４０２における更新コマンドは、更新パッケージ４０１の更新コマンドに相当し、そこに現れる順序と同様に順序づけられ、コマンド４１１はコマンド４０３に相当し、コマンド４１２はコマンド４０４に相当し、コマンド４１３はコマンド４０５に相当し、コマンド４１４はコマンド４０６に相当し、コマンド４１５はコマンド４０７に相当し、コマンド４１６はコマンド４０８に相当し、コマンド４１７はコマンド４０９に相当し、コマンド４１８はコマンド４０９に相当する。しかし、更新パッケージ４０２においては、更新パッケージ４０１とは異なり、挿入コマンドおよび置換コマンドに必要な全ての補足データは、更新パッケージの終わりに現れる。更新パッケージの部分４１９は、置換コマンドに必要な補足データを記憶するために使用され（よって、これを「置換補足データ部分」と呼ぶ）、更新パッケージの部分４２０は、挿入コマンドに必要なデータを記憶するために使用される（よって、これを「挿入補足データ部分」と呼ぶ）。補足データが補足データ部分に記憶されるこのような更新パッケージを、「データ区別（distinct）更新パッケージ」と呼ぶ。
【００７６】
なお、各補足データ部分（部分４１９および４２０等）は、２つ以上のデータ消費更新コマンドに対応する補足データアイテムを含みうる。図４の例においては、挿入補足データ部分４２０は、更新コマンド４１６および４１８の補足データを含む。
【００７７】
一実施形態によれば、データ消費更新コマンドは、更新パッケージに記憶された各補足データアイテムに対するポインタ、例えば、部分４１９および４２０のうち一方に含まれる補足データアイテムの始まりに対するポインタを含みうる。別の実施形態によれば、補足データを必要とする各更新コマンドは、各データのサイズを含むことができ、それにより、各補足データアイテムの開始位置を演算で求めることが可能となる。しかし、これには限らず、その他の実施形態もまた可能である。例えば、補足データ部分は、各補足データアイテムをこのアイテムのサイズと対応付けることができる。補足データアイテムが、更新パッケージにおけるデータ消費更新コマンドと同順序で補足データ部分に記憶されている場合、当業者であれば、この実施形態により、補足データアイテムの消費更新コマンドごとの開始位置を演算で求めることできることを理解するであろう。
【００７８】
元のバージョンが更新され、更新されたバージョンが生成されることが当業者には理解される。このような（または元のバージョンから更新されたバージョンへの）更新を、「順方向更新」と呼ぶ。また、当業者であれば、バージョンの順方向更新の間、更新パッケージは、その始まりから終わりに向かって処理されることを理解するであろう。更新パッケージをその始まりから終わりに向かって処理することを、更新パッケージの「順方向処理」と呼ぶ。
【００７９】
本発明によれば、更新の方向を反転させて、それにより、元のバージョンに復帰することが必要となることがある。このような反転は、例えば、順方向更新処理が途中で失敗し、それにより、中間バージョンである記憶されたバージョンが生成される場合に望まれる場合がある。このような失敗が起こった場合、例えば、携帯電話の操作者は、前のバージョン（元のバージョン）に復帰することを望む場合がある。
【００８０】
別の例によれば、更新処理は、開始時に、「携帯端末はソフトウェアを更新していません。更新は３０分間継続すると見込まれ、その間、電話は動作不能となります」といったメッセージをユーザに提示することができる。ユーザが、次の３０分以内に電話を使用しなければならない場合、ユーザには、更新処理をキャンセルする（したがって、これを後に延期する）オプションが与えられる。しかし、更新処理は、ユーザがキャンセルを押す前に更新タスクの一部を行うかもしれず、これにより、中間バージョンが生じる。したがって、ユーザが「キャンセル」を押すと、更新処理は反転し、元のバージョンに復帰しなくてはならない。
【００８１】
記憶されたバージョンからその対応する元のバージョンに復帰することを、「ロールバック（roll-back）」と呼び、ロールバックを行う更新処理を、「ロールバック（rolling-back）更新処理」と呼ぶ。本発明の一実施形態によれば、ロールバック更新処理は、この元のバージョンの順方向更新に用いられる更新パッケージに従って動作し得るが、詳しく後述するように、逆方向に（すなわち、その終わりから始まりに向かって）動作する。
【００８２】
示されている例は、決して限定的なものではなく、ロールバックのその他の例および理由も存在し得る。そのようなさらなる例の一つは、携帯電話の操作者が元のバージョンを更新されたバージョンに更新することに成功するが、更新されたバージョンが満足のいかないものであることが分かり、したがって、操作者は前に動作していた元のバージョンへの復帰（ロールバック）を望む場合である。すなわち、ロールバックは、記憶されたバージョンが必ずしも中間バージョンである必要はなく、記憶されたバージョンが更新されたバージョンである場合にも起こりうる。
【００８３】
図４の更新パッケージ４０２に戻ると、４２１は「方向指示」であり、「更新属性ビット」を構成している。方向指示は、更新処理が動作すべき方向および／またはこの動作の理由を示すために用いられる。例えば、異なる方向および／または動作理由には、異なるコードが存在し得る。
【００８４】
しかし、これには限らず、その他の実施形態では、必ずしも更新パッケージの一部ではないその他の記憶領域に方向指示を記憶することができる。例えば、記憶装置１０３内に「方向指示バッファ」を設けることができる。
【００８５】
ある実施形態によれば、更新方向は、２つの方向のうち一方である。具体的には、この方向は、順方向およびロールバックのうちの一方である。しかし、これには限らず、その他の実施形態は、この場合に適用可能なあらゆる方向を有し得る。
【００８６】
本発明の一実施形態に従って動作する更新処理は、動作を開始する際、動作方向および開始位置を認識する必要がある。なお、順方向更新が最初に開始すると、記憶されたバージョンは、通常、元のバージョンであり、開始位置は、元のバージョンの始まりであり、かつ更新パッケージの始まりであり、方向は（既に示したように）順方向である。しかし、記憶されたバージョンが中間バージョンである場合、開始位置は、中間バージョンのどこかであり、かつ更新パッケージのどこかであることになる。同様に、方向は、順方向またはロールバックのいずれでもありうる。
【００８７】
図３に戻り、更新処理中、いくつかのセグメントが修正された（したがって、「置換されたブロック」または「挿入されたブロック」を構成している）ことは既に述べた。修正されたセグメントのコンテンツは更新処理により更新パッケージを備えていることも図４を参照して説明した。したがって、更新されたセグメントのコンテンツがどのようなものであるかを更新パッケージに基づいて予測することが可能である。
【００８８】
したがって、一実施形態によれば、更新セグメントの修正された部分に対応するシグニチャを更新パッケージに含めることが可能である。シグニチャは、例えば、特定のブロック用に演算で求められた、それ自体が公知のチェックサムでありうる。シグニチャは、その対応するブロックと共に記憶され得る。しかし、シグニチャを、更新パッケージの始まりまたは終わりにおいて、異なるテーブル等に記憶するといった別の実施形態も可能である。
【００８９】
一部のセグメントのコンテンツは、元のバージョンから更新されたバージョンにコピーされることも（例えば、図３および図４を参照して）説明した。したがって、元のバージョンおよび更新パッケージが与えられるならば、更新されたバージョンにおける全セグメントに対するシグニチャを演算で求めることが可能である。さらに、更新されたバージョンの一部であるブロック内の全てのセグメントに対応する１つのシグニチャを演算で求めることが可能である。このようなシグニチャを、「ブロックの更新されたシグニチャ」と呼ぶ。
【００９０】
本実施形態によれば、「ブロックの元のシグニチャ」、すなわち、元のバージョンの一部であるブロック内の全てのセグメントに対応するシグニチャを計算することもさらに可能である。
【００９１】
このことを理解し、また、記憶されたバージョンが、元のバージョン、中間バージョンまたは更新されたバージョンのいずれでもありうる（例えば、図２を参照）という説明をふまえると、当業者であれば、記憶されたバージョンにおけるブロックのシグニチャを計算し、それらをブロックの元のシグニチャおよびブロックの更新されたシグニチャと比較することにより、記憶されたバージョンのＩＤを決定することが可能であることを理解するであろう。さらに、記憶されたバージョンが中間バージョンであると判断された場合、前に動作していた更新処理の中断位置を決定することが可能である。そして、中断位置に対応する更新パッケージにおける更新コマンドを見つけることが可能である。
【００９２】
ブロックの一部を占めるコンテンツへのアクセスを許可する記憶装置においては、前に動作していた更新処理の中断が起きたセグメントを決定するために、セグメントのシグニチャを比較することがさらに可能である。
【００９３】
「状態レコード」と呼ぶ更新パッケージレコードと対応付けることがさらに可能である。一実施形態によれば、状態レコードを各ブロックに対応するコマンドと対応付けることが可能であり、状態レコードは、対応するブロックの更新が完了した後にあるはずなので、更新処理の状態を反映している。例えば、状態レコードは、それ自体が公知である局所変数等の処理を維持する変数を保持するために更新処理によって用いられるブロックのコピーをＲＡＭ内に含みうる。
【００９４】
記憶されたバージョンのＩＤ、前に動作していた更新処理の中断位置および状態レコードを決定した後、本発明の一実施形態によれば、更新処理を反転（すなわち逆戻り）させ、それにより、前に動作していた更新処理の実行開始前に存在していた元のバージョンに復帰することが可能である。
【００９５】
図５は、本発明の一実施形態に係る、更新処理を反転させる前に実行される動作を示すフローチャートである。５０１において、更新パッケージに従って、更新シーケンスが決定され、５０２において、更新処理は、更新シーケンスに従って、記憶されたバージョンの最初のブロックを読み出す。５０３において、読み出されたブロックに対応するシグニチャ（例えば、これを更新パッケージから読み出すことにより）へのアクセスが行われ、５０２で読み出されたコンテンツに基づいて対応するシグニチャが５０４において計算される。５０５において、更新処理が２つのシグニチャが一致することを確認し、かつ未検査のブロック（５０６を参照）が他にある場合、５０７において、更新シーケンスに従って、次のブロックに対応するシグニチャへのアクセスが行なわれ、５０４において対応するシグニチャを計算するために、５０８において当該ブロックが読み出される。未検査のブロックが他に存在しないことが５０６で分かった場合、これは記憶されたバージョンが更新されたバージョンであることを意味し、更新処理は反転することなく終了する。しかし、これには限らず、その他の実施形態では、更新されたバージョンである記憶されたバージョンであっても反転させることができる。
【００９６】
５０５において２つのシグニチャが一致しない場合、５１０での処理状態を復元するために、５０９で行なわれたように、更新処理は、読み出されたブロックに対応する状態レコードへのアクセスを行うことができる。一旦状態が復元されると、元のバージョンに復帰するために、５１１において処理は反転する。
【００９７】
なお、一例によれば、ブロックを更新している間、更新処理は、その元のコンテンツをバックアップバッファに記憶し、ブロックの更新が完了する前に更新処理が失敗した場合にそのコンテンツの復元を可能にする（「バックアップ・ファースト」）。別の例では、ブロック自体の変化を引き起こすことなく、元のコンテンツの代わりに、更新されたブロックのコンテンツをバックアップバッファに記憶し、（「アップデート・ファースト」）、その後、更新されたコンテンツをバックアップバッファから当該ブロックにコピーすることができる。バックアップ・ファーストの場合、中断点を見つける際、このブロックのコンテンツが破損している可能性がある。この場合、バックアップバッファからコンテンツを回復することができる。あるいは、「アップデート・ファースト」の場合、新コンテンツは既にバックアップバッファに存在している。
【００９８】
なお、図５に限らないことに注意されたい。別の実施形態においては、更新パッケージにおけるシグニチャは、更新されたバージョンではなく、元のバージョン内のブロックに対応しているかもしれない。当業者は、更新パッケージの対応するシグニチャにシグニチャが一致しない記憶されたバージョンにおける最初のブロックを見ることによって、中断点を見つけるためにシグニチャを比較する代わりに、この別の実施形態においては、更新パッケージの対応するシグニチャにシグニチャが一致する記憶されたバージョンにおける最初のブロックを探すことが要求され、中断点は、更新シーケンスによる記憶されたバージョンの前のブロックであることを理解するであろう。
【００９９】
ロールバックは、ユーザ（携帯端末の所持者）の選択等により行なわれる場合があることは既に説明した。所持者によって開始されたロールバックの場合、開始位置の探索は必ずしも必要ではない。本発明の一実施形態によれば、更新処理をキャンセルする際、開始位置の指示を記憶することが可能である（指示は、例えば、方向指示と対応付けて記憶され得る）。
【０１００】
反転がどのように行なわれうるかについて説明を始める前に、ロールバック更新を反転させ、それにより、順方向更新を達成することも可能であることに注目されたい。例えば、所持者が順方向更新をキャンセルする（それにより、ロールバックを開始する）場合、所持者は、考え直し、（ロールバック更新処理をキャンセルすることにより）更新処理を再び反転させて順方向更新に復帰し、更新されたバージョンを得るかもしれない。すなわち、一実施形態によれば、更新処理をキャンセルする際、順方向方向指示とロールバック方向指示との間で「切り替えを行う」ことが可能である。
【０１０１】
なお、「反転」という用語は、順方向更新からロールバック更新への反転およびその逆を示しているため、反転の前に動作している更新処理を反転前の更新処理と呼び、反転の後に動作している更新処理を、反転後の更新処理を呼ぶ。反転前の更新処理が順方向更新を行う場合、反転後の更新処理はロールバックを行うことが理解される。この反対もまた正しく、反転前の更新処理がロールバックを行う場合、反転後の更新処理は順方向更新を行う。
【０１０２】
同様に、更新処理（順方向またはロールバック）が動作を開始する前に存在する記憶されたバージョンを、通常、ソースバージョンと呼び、更新処理後の記憶されたバージョンを、通常、「ターゲットバージョン」と呼ぶ。ソースバージョンは、元のバージョン、更新されたバージョンまたは中間バージョンでありうる。ターゲットバージョンは、元のバージョンまたは更新されたバージョンのいずれでもありうる。
【０１０３】
本発明の一実施形態によれば、反転（順方向更新からロールバックへ、およびその逆）を可能にするために、反転前の更新処理中に削除されたあらゆるコンテンツをバックアップすることが必要である。なぜならば、このコンテンツをターゲットバージョン内に再導入するために必要となるからである。図６は、本発明の一実施形態に係る、反転前の更新処理中に削除されたコンテンツの記憶の例を示している。同図においては、本例におけるソースバージョンである元のバージョン３０１（図３を参照）の１つのセグメント３０７が示されている。図４の更新パッケージ４０２の一部も示されており、図示された部分は、セグメント３０７の削除を担う削除更新コマンド４１３を含む。この部分は、置換補足データ部分４１９、挿入補足データ部分４２０および方向指示４２１も含む。
【０１０４】
また、「コンテンツ保持バッファ」６０１が示されている。「保管（save）バッファ」を構成するコンテンツ保持バッファは、更新処理にアクセス可能な記憶装置１０３内の領域であり、削除されたコンテンツの保持を可能にするために特別に割当てられている。一実施形態によれば、コンテンツ保持バッファ６０１を、更新処理の期間のみ一時的に割当て、後に任意の別のタスクのために再利用することができる。更新処理中にコンテンツを削除する前に、そのコピーをコンテンツ保持バッファに保持（６０２）することが可能である。あるいは、より大きい更新パッケージ（小さい更新パッケージと比べて、より広い帯域幅および／またはより多くの時間を伝送に要する）にして、コンテンツ保持バッファ用の専用スペースを更新パッケージ内に設け、それにより、記憶装置１０３内にこのバッファに必要なスペースを確保してもよい。
【０１０５】
なお、図６は削除動作中のコンテンツの保持を示している。しかし、これには限らず、実施形態の中には、進行中の更新処理の反転を後に可能にするために、更新処理が「置換」等のコンテンツをオーバーライドする動作を行うたびに保持が起きるものもある。なお、さらに、「置換」動作を行っている間に変換関数を演算する実施形態では、変換データを記憶されたコンテンツと同一のコンテンツに再変換するために、変換データを置換用データに再び適用することができるので、記憶されたコンテンツを置換コンテンツでオーバーライドする前に保持しなくてもよい。
【０１０６】
図６の実施形態は、非限定的なものであり、別の実施形態も可能である。例えば、更新パッケージに削除されたデータのコピーを含めることが可能である。このようにすると更新パッケージ（これはさらに大きくなる）の伝送により多くのネットワークリソースが必要となるが、保持動作が必要でないため更新処理は高速化することになる。
【０１０７】
図７は、本発明の一実施形態に係る、コンテンツ保持バッファの使用の軽減の例を示している。なお、反転前の更新処理における挿入コマンドおよび置換コマンドに対して用いられる補足データアイテムは、それらの更新コマンドの実行後、それらの補足データは既にターゲットバージョンに書き込まれているため、不要である。しかし、進行中の更新処理中に削除されたコンテンツは、例えばコンテンツ保持バッファに保持されることは既に説明した。したがって、コンテンツ保持バッファに記憶されているコンテンツを、既に使用された補足データ４２０の代わりに更新パッケージ内にコピーし（７０１）、それによりコンテンツ保持バッファを解放（および／または再利用）することができることが理解される。
【０１０８】
図７の後者の例によって示されるように、更新パッケージそれ自体をインプレース更新することができ、そのためには、更新処理が中断された場合にその記憶領域を修正するための信頼できる修正方法が必要となりうる。更新パッケージの信頼できるインプレース修正には、上記に説明したようなバックアップバッファ、パッケージシグニチャおよび状態レコードの使用といったあらゆる信頼性できる技術を用いることができる。
【０１０９】
本発明の一実施形態によれば、補足データアイテムが「空き」になるたびに（すなわち、これらのそれぞれを使用したほぼ直後に）これらを置換することが可能である。別の実施形態によれば、補足データアイテムを、後で、例えば更新処理の終了時に置換することが可能である。
【０１１０】
コンテンツ（またはそれらのコンテンツの少なくとも一部）が類似しているか、あるいは共有されている、２つ以上の削除されたセグメントが時として存在することが理解される。別の実施形態によれば、２つ以上のセグメントがコンテンツを共有している場合、このコンテンツは一度だけ保持されることができ、それ以外の場所では、保持されたコンテンツが記憶されている場所、あるいはそれをどのように検索するかについての指示を保持してもよい。
【０１１１】
反転前の更新処理が終了すると、先行する更新処理（このような更新処理が開始される場合）が動作すべき方向を示すように方向指示４２１が設定される。反転前の更新処理が失敗するかあるいは途中で停止した場合にも方向指示４２１が設定され、先行する更新処理（開始された場合）が順方向モードまたはロールバックモードで動作すべきかが示される（図５、５１１のように）。
【０１１２】
本発明によれば、順方向更新処理の反転は、順方向更新処理によって実行される各更新コマンド取り消すことにより行なわれるが、順方向更新処理によって実行された最後の更新コマンドから始まり、更新パッケージにおける最初の更新コマンドで終わるという逆の順序で行なわれる。同様に、ロールバック更新処理の反転は、ロールバック更新シーケンスによって実行された最後に反転された更新コマンドから反転コマンドがロールバック更新処理によって実行された各更新コマンドを再実行することにより行なわれる。
【０１１３】
図３および図４において上記に説明した例を参照して反転についてさらに説明する。本例によれば、順方向更新処理の動作が成功し、更新パッケージ４０２に従って元のバージョン３０１を更新することにより、更新されたバージョン３０２が得られたと仮定されている。なお、この成功した順方向更新に続いて、方向指示部４２１は、更新処理方向を反転すべきであることを指示する（すなわち、先行する更新処理（開始された場合）はロールバックで動作することになる）。
【０１１４】
本実施例によれば、ロールバック更新処理は、その先行する順方向更新処理によって実行された更新動作を取り消すが、進行中の処理の終了前に実行された最後の更新コマンドから始まり、最初の更新コマンド４１１で終わるという逆の順序でこれを行う。本例においては、ロールバック中に取り消されるべき最初の更新コマンドは４１８である。なお、更新処理を反転している間、補足データ部分（同図においては４２０および４２１）へのアクセスは逆の順序で行なわれる。
【０１１５】
本実施例によれば、補足データ部分は、順方向更新中にコンテンツを削除している間にそこに書き込まれた反転されたコンテンツを含む。ロールバック更新は順方向更新と同様（反転された進行方向およびコマンドの反転を除いて）に動作することをふまえると、ロールバック更新処理が記憶されたバージョンからコンテンツを削除するたびに、削除されたコンテンツのコピーが補足データ部分（またはコンテンツ保持バッファ）に書き込まれることが理解される。
【０１１６】
以下の例は、元の動作の結果を反転させる適切な動作（「反転更新コマンド」または「逆戻し動作」）を行うことにより、各更新コマンド例（コピー、削除、挿入および置換）がどのように取り消されるかを説明するものである。
【０１１７】
「削除」動作は、挿入動作により取り消す（ロールバックする、反転する）ことができる。前に削除コマンドによって削除されたコンテンツは、挿入コマンド用の補足データである。例えば、３０７を削除というコマンド（例えばコマンド４１３を参照）によって行なわれた削除動作は、３０７補足データを挿入によって反転させられる（補足データは、補足データ部分またはコンテンツ保持バッファに記憶され得る）。
【０１１８】
「挿入」コマンドに従って行なわれた「挿入」動作は、削除動作により取り消すことができる。例えば、コマンド４１８（３１１を挿入）は、３１１を削除を実行することにより取り消すことができる。なお、反転コマンドを実行している間にコンテンツを削除する際、削除されたコンテンツは、例えば、コンテンツ保持バッファまたは挿入補足データ部分内に記憶するとよい。
【０１１９】
「コピー」動作は、更新されたセグメントをその元の位置にコピーしなおすことにより取り消すことができる。例えば、コマンド４１７（３０５を３１２にコピー）は、３１２を３０５にコピーというコマンドにより反転させることができる。
【０１２０】
「置換」動作は、反転前の更新処理によって挿入されたコンテンツを削除し、置換補足データ部分４１９またはコンテンツ保持バッファ内に記憶されたデータをその代わりに書込むことにより取り消すことができる。換言すると、置換動作は、別の反転された置換動作により取り消すことができる。しかし、反転前の更新処理における「挿入」にビット毎のＸＯＲといった変換関数が用いられる場合、反転前のセグメントに記憶されたコンテンツを再び得るために、反転前の挿入動作によって補足データ（変換データ）を用いて前に書き込まれたコンテンツに対して、同じ変換関数を演算することにより挿入動作を反転することができることを当業者であれば理解するであろう。
【０１２１】
したがって、反転された更新コマンド（またはロールバック更新コマンド）は、更新コマンドに逆に対応することが示される。
【０１２２】
図８は、本発明の一実施形態に係る、反転可能な更新処理においてソースバージョンからターゲットバージョンへの更新の間に実行される主な手順を示すフローチャートである。なお、８０１において、方向指示部４１９の値に従って更新処理の方向が決定される。指示部が、更新処理は順方向更新であるべきであると示している場合、８０２において、更新処理は、更新パッケージに従って順方向に動作することになる。終了（正常終了または失敗）時に、８０３において、更新処理は前の更新処理（開始された場合）はロールバックを実行すべきであると指示するように方向指示部を設定する。しかし、８０１において、更新処理が、更新処理はロールバックを実行するように動作すべきであると決定する場合は、８０４において、更新処理は、更新パッケージに従ってロールバック方向に動作する。終了（正常終了または失敗）時、８０５において、更新処理は、前の更新処理（開始された場合）は順方向更新を実行すべきであると指示するように方向指示部を設定する。
【０１２３】
図９は、本発明の一実施形態に係る順方向更新を詳細に示すフローチャートである。開始時、９０１において、更新処理は、記憶されたバージョンにおいて更新を開始すべき位置を見つける必要がある。記憶されたバージョンが元のバージョンである場合、開始位置はバージョンの始まりであり、記憶されたバージョンが更新されたバージョンである場合、開始位置はバージョンの終わりであり（したがって、順方向更新処理は、更新動作を行うことなく終了することになる）、記憶されたバージョンが中間バージョンである場合、開始位置は前に動作していた更新処理の終了点であることが理解される（例えば図５を参照）。
【０１２４】
９０２において、更新処理は、その処理の状態を開始する。記憶されたバージョンが中間バージョンである場合、状態は状態レコードに従って開始される。しかし、記憶されたバージョンが元のバージョンまたは更新されたバージョンである場合、状態は新しいものとして開始される。また、この段階で、更新処理は、読み出しを開始すべき更新コマンドを見つけ、置換補足データ部分４１９、挿入補足データ部分４２０およびコンテンツ保持バッファ６０１内などにおけるポインタ位置を決定し、それにより、そこに記憶された正しいデータアイテム（読み取りおよび／または書き込みのために）へのアクセスを行うことが可能となる。
【０１２５】
記憶されたバージョンが更新されたバージョンである場合、更新処理が順方向更新処理であるので、更新シーケンスによる更新コマンドがもはや存在せず、したがって、更新処理は、更新コマンドを実行することなく終了することが９０３において示されている。しかし、記憶されたバージョンが元のバージョンまたは中間バージョンである場合、更新処理は、更新シーケンスに従って更新パッケージから次の更新コマンドを読み出し、それに応じて動作する。更新コマンドが「コピー」コマンド（９０５）である場合、９０６において、元のセグメントのコンテンツが更新されたセグメント内にコピーされる。なお、ターゲットセグメントが空きでない場合、実施形態によっては、そこに記憶されたコンテンツを、コピーコマンドの前に削除コマンドが存在するかのようにコンテンツ保持バッファ内（または、挿入補足データ部分４２０内）に保持することが必要である。
【０１２６】
コマンドが「挿入」コマンド（９０７）である場合、９０８において、データは挿入補足データ部分４２０から更新されたセグメント内にコピーされ、９０９において、挿入補足データ部分内のポインタが次のデータアイテムに進められる。ここでもまた、実施形態によっては、補足データを更新されたセグメンに挿入する前に、更新されたセグメントが空きでない場合、そこに記憶されたコンテンツは、コピーコマンドの前に削除コマンドが存在するかのようにコンテンツ保持バッファ内（または挿入補足データ部分４２０内）に保持され得る。
【０１２７】
コマンドが「削除」コマンド（９１０）である場合、９１１において、元のセグメントに記憶されたコンテンツはコンテンツ保持バッファ内（または挿入補足データ部分４２０内）にコピーされ、９１２において、コンテンツ保持バッファ内のポインタが次の利用可能なスペースに進められる。
【０１２８】
本例（「コピー」コマンド、「挿入」コマンド、「削除」コマンドおよび「削除」コマンドが存在する）によれば、当業者であれば、更新コマンドが、「コピー」でも、「挿入」でも、「削除」でもない場合、それは「置換」にちがいないことを理解するであろう。したがって、９１３において、元のセグメントのコンテンツと変換データとのビット毎の排他的論理和が取られ、その結果が更新されたセグメントに記憶され（９１４を参照）、置換補足データ部分４１９内の次のデータアイテムに対するポインタは次のデータアイテムに進められる。
【０１２９】
図１０は、本発明の一実施形態に係る、記憶されたバージョンのロールバックを詳細に示すフローチャートである。開始時、１００１において、更新処理は、記憶されたバージョンにおいて更新を開始すべき位置を見つける必要がある。記憶されたバージョンが元のバージョンである場合、開始位置はバージョンの始まりであり（したがって、ロールバック更新処理は、更新動作を行うことなく終了することになる）、記憶されたバージョンが更新されたバージョンである場合、開始位置はバージョンの終わりであり、記憶されたバージョンが中間バージョンである場合、開始位置は前に動作していた更新処理の終了点であることが理解される（例えば図５を参照）。
【０１３０】
１００２において、更新処理は、その処理の状態を開始する。記憶されたバージョンが中間バージョンである場合、状態は状態レコードに従って開始される。しかし、記憶されたバージョンが元のバージョンまたは更新されたバージョンである場合、状態は新しいものとして開始される。また、この段階で、更新処理は、読み出しを開始すべき更新コマンドを見つけ、置換補足データ部分４１９、挿入補足データ部分４２０およびコンテンツ保持バッファ６０１内などにおけるポインタ位置を決定し、それにより、そこに記憶された正しいデータアイテム（読み取りおよび／または書き込みのために）へのアクセスを行うことが可能となる。
【０１３１】
ロールバック更新処理は、更新パッケージの更新シーケンスと逆であるロールバック更新シーケンスに従って動作する。記憶されたバージョンが元のバージョンである場合、更新処理がロールバック更新処理であるので、ロールバック更新シーケンスによる更新コマンドはもはや存在せず、したがって、更新処理は更新コマンドを実行することなく終了することが１００３において示されている。しかし、記憶されたバージョンが更新されたバージョンまたは中間バージョンである場合、ロールバック更新処理は、反転された更新シーケンスに従って更新パッケージから次の更新コマンド（言い換えると、更新シーケンスによる前の更新コマンド）を読み出し、更新コマンドに逆に対応する更新動作を実行する。
【０１３２】
更新コマンドが「コピー」コマンド（１００５）である場合、１００６において、更新されたセグメントのコンテンツが元のセグメント内にコピーされ、これは、「挿入」コマンドに逆に対応する更新コマンドである。なお、元のセグメントが空きでない場合、一部の実施形態では、そこに記憶されたコンテンツを、コピーコマンドの前に削除コマンドが存在するかのようにコンテンツ保持バッファ内（または挿入補足データ部分４２０内）にロールバック更新シーケンスに従って保持することが必要である。
【０１３３】
コマンドが「挿入」コマンド（１００７）である場合、１００８において、データは記憶されたバージョンからコンテンツ保持バッファ内（または挿入補足データ部分４２０）にコピーされ、これは、「挿入」コマンドに逆に対応する更新コマンドであり、１００９において、コンテンツ保持バッファに対するポインタが次の利用可能なスペースに進められる（または、挿入補足データ部分に対するポインタが前のデータアイテムに後退させられる）。
【０１３４】
コマンドが「削除」コマンド（１０１０）である場合、１０１１において、データは挿入補足データ部分４２０から（またはコンテンツ保持バッファから）元のセグメント内にコピーされ、１０１２において、挿入補足データ部分内のポインタが前のデータアイテムに後退させられる。ここでもまた、補足データを元のセグメント内にコピーする前に、元のセグメントが空きでない場合、実施形態によっては、そこに記憶されたコンテンツは、削除コマンドの前に挿入コマンドが存在するかのようにコンテンツ保持バッファ内（または挿入補足データ部分４２０内）にロールバック更新シーケンスに従って保持され得る。
【０１３５】
本例（「コピー」コマンド、「挿入」コマンド、「削除」コマンドおよび「削除」コマンドが存在する）によれば、当業者であれば、更新コマンドが、「コピー」でも、「挿入」でも、「削除」でもない場合、それは「置換」にちがいないことを理解するであろう。したがって、１０１３において、更新されたセグメントのコンテンツと変換データとのビット毎の排他的論理和が取られ、その結果が元のセグメントに記憶される（１０１４を参照）。本実施形態によれば、変換データは置換補足データ部分４１９に記憶される。したがって、１０１５において、置換補足データ部分４１９内の次のデータアイテムに対するポインタは前のデータアイテムに後退させられる。
【０１３６】
本発明は、記憶されたバージョンの更新処理を実現するための方法を提供する。この方法は、前記記憶されたバージョンを第１のバージョンに更新するための順方向更新を実現するステップと、前記記憶されたバージョンを第２のバージョンに更新するためのロールバック更新を実現するステップと、前記順方向更新および前記ロールバック更新のうちのいずれかである第１の更新動作を適用するステップと、前記順方向更新および前記ロールバック更新のうちのいずれかであって、前記第１の更新動作以外の第２の更新動作を適用するステップとを含む。
【０１３７】
ある実施形態によれば、第１のバージョンは、元のバージョンおよび更新されたバージョンを含むいくつかのバージョンのうちの１つでありうることが理解される。しかし、これには限らず、その他の実施形態では、中間バージョン等の別のバージョンが第１のバージョンでありうる。
【０１３８】
同様に、ある実施形態によれば、第２のバージョンは、元のバージョンおよび更新されたバージョンを含むいくつかのバージョンのうちの１つでありうることが理解される。しかし、これにもまた限らず、その他の実施形態では、中間バージョン等の別のバージョンが第２のバージョンでありうる。
【０１３９】
また、ある実施形態によれば、第１の更新動作は、順方向更新動作およびロールバック更新動作等のいくつかの更新動作のうちの１つでありうることが理解される。これには限らず、その他の実施形態では、異なる更新動作が第１の更新動作でありうる。
【０１４０】
ある実施形態によれば、第２の更新動作は、順方向更新動作およびロールバック更新動作等のいくつかの更新動作のうちの１つでありうることも理解される。これには限らず、その他の実施形態では、異なる更新動作が第２の更新動作でありうる。
【０１４１】
図１１は、本発明の一実施形態に係る、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新するためのシステム１１０１を概略的に示すブロック図である。システム１１０１は、例えば方向指示４２１に従って更新方向を決定するように構成された方向決定ユニット１１０２を含む。
【０１４２】
システム１１０１は、方向決定ユニット１１０２に接続された順方向更新処理装置１１０３も含む。方向決定ユニット１１０２が更新方向は順方向を示していると判断すると、順方向更新処理装置１１０３は、更新シーケンスに従い、記憶されたバージョンを更新されたバージョンに順方向に更新する。これは、例えば、図９のフローチャートに従って行なわれる。
【０１４３】
方向決定ユニット１１０２が更新方向はロールバックを示していると判断すると、方向決定ユニット１１０２に接続されたロールバックシーケンス生成器１１０４が、更新シーケンスとは逆のロールバック更新シーケンスを生成する。ロールバックシーケンス生成器１１０４は、一度に１コマンドずつ、逆の順序で更新シーケンスに従うことができる。あるいは、全て一度に更新シーケンスに従い、それにより、ロールバック更新シーケンスを生成し、記憶装置内に、例えばリストとして記憶する。
【０１４４】
システム１１０１は、ロールバックシーケンス生成器１１０４に接続されたロールバック更新処理装置１１０５も含む。ロールバック更新処理装置１１０５は、ロールバック更新に従って、記憶されたバージョンを元のバージョンにロールバックする。これは、例えば、図１０のフローチャートに従って行なわれる。
【０１４５】
図１２は、本発明の一実施形態に係る、更新処理を反転させるためのシステムを概略的に示すブロック図である。システム１２０１は、更新コマンド反転ユニット１２０２を含む。更新コマンド反転ユニット１２０２は、更新中に前に実行された更新パッケージ内の更新コマンドを反転させる。例えば、図１０の１００６、１００８、１０１１および１０１３を参照されたい。
【０１４６】
図１３は、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新するためのシステム１３０１を概略的に示すブロック図である。システム１３０１は、方向決定ユニット１３０２を含む。一実施形態によれば、方向決定ユニット１３０２は、方向を決定するのに方向指示を用いる。
【０１４７】
方向決定ユニット１３０２には、順方向更新処理装置１３０３が接続されている。方向が順方向を示す場合、順方向更新処理装置１３０３は、例えば図９のフローチャートに従い、記憶されたバージョンを更新されたバージョンに順方向に更新する。
【０１４８】
システム１３０１は、ロールバック更新処理装置１３０４も含む。方向決定ユニット１３０２が方向はロールバックであると判断すると、ロールバック更新処理装置１３０４は、例えば図１０のフローチャートに従い、記憶されたバージョンを元のバージョンにロールバックする
本発明によるシステムは、適切にプログラムされたコンピュータでありうることも理解される。また、本発明は、本発明の方法を実施するための、コンピュータによって読み取り可能なコンピュータプログラムを想定している。本発明は、さらに、本発明の方法を実施するための、機械によって実行可能な命令プログラムを具体的に実施する機械可読メモリを想定している。
【０１４９】
本発明をある程度詳細に説明したが、以下の請求項の範囲を逸脱することなく、様々な変更と修正がなされうることを当業者は容易に理解するであろう。
【図面の簡単な説明】
【０１５０】
【図１】図１は、本発明の一実施形態に係る、セルラーネットワークにおいてバージョンを更新するためのシステムの概略図である。
【図２】図２は、元のバージョンから更新されたバージョンへの更新における簡略化された段階例を示す。
【図３】図３は、元のバージョン例および対応する更新されたバージョン例を示す。
【図４】図４は、図３の元のバージョンから、その更新されたバージョンに更新するように構成された更新パッケージ例を示す。
【図５】図５は、本発明の一実施形態に係る、更新処理を反転させる前に実行される動作を示すフローチャートである。
【図６】図６は、本発明の一実施形態に係る削除されたコンテンツの記憶の例を示す。
【図７】図７は、本発明の一実施形態に係る、コンテンツ保持バッファの使用の軽減を示す。
【図８】図８は、本発明の一実施形態に係る、反転可能な（reversible）更新処理において元のバージョンから更新されたバージョンへの更新の間に実行される主な手順を示すフローチャートである。
【図９】図９は、本発明の一実施形態に係る、記憶されたバージョンの順方向更新を詳細に示すフローチャートである。
【図１０】図１０は、本発明の一実施形態に係る、記憶されたバージョンのロールバックを詳細に示すフローチャートである。
【図１１】図１１は、本発明の一実施形態に係る、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新するためのシステムを概略的に示すブロック図である。
【図１２】図１２は、本発明の一実施形態に係る、更新処理を反転させるためのシステムを概略的に示すブロック図である。
【図１３】図１３は、本発明の一実施形態に係る、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新するためのシステムを概略的に示すブロック図である。
【図１】
2008501180.tif 000003
【図２】
2008501180.tif 000004
【図３】
2008501180.tif 000005
【図４】
2008501180.tif 000006
【図５】
2008501180.tif 000007
【図６】
2008501180.tif 000008
【図７】
2008501180.tif 000009
【図８】
2008501180.tif 000010
【図９】
2008501180.tif 000011
【図１０】
2008501180.tif 000012
【図１１】
2008501180.tif 000013
【図１２】
2008501180.tif 000014
【図１３】
2008501180.tif 000015
【手続補正書】
【提出日】平成18年3月30日(2006.3.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するための方法であって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記更新パッケージは更新コマンドを含み、前記更新は更新シーケンスに従って行なわれ、前記方法は、
前記更新の方向を決定するステップと、
前記方向が順方向を示す場合、前記更新シーケンスおよび前記更新パッケージに含まれる更新コマンドに従って、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新し、
前記方向がロールバック（roll-back）を示す場合、前記更新シーケンスと逆のロールバック更新シーケンスを生成し、前記ロールバック更新シーケンスおよび前記更新パッケージに含まれる更新コマンドに従って、前記記憶されたバージョンを前記元のバージョンにロールバックする（rolling- back）ステップとを含む方法。
【請求項２】
前記記憶されたバージョンは、元のバージョン、更新されたバージョンおよび中間バージョンのうちの１つである、請求項１に記載の方法。
【請求項３】
前記更新パッケージは更新コマンドを含み、各更新コマンドは、コピー更新コマンド、削除更新コマンド、挿入更新コマンドおよび置換更新コマンドのうちの１つである、請求項１または２に記載の方法。
【請求項４】
順方向更新は、前記更新シーケンスに従って、前記更新コマンドに直接対応する更新動作を行う、先行する請求項のいずれかに記載の方法。
【請求項５】
ロールバックは、前記ロールバック更新シーケンスに従って、更新コマンドに逆に対応する更新動作を行なう、先行する請求項のいずれかに記載の方法。
【請求項６】
前記記憶されたバージョンからコンテンツを削除する前に、前記更新は、削除されるコンテンツを保持することを含む、先行する請求項のいずれかに記載の方法。
【請求項７】
削除コマンドに逆に対応する更新コマンドが、保持されたコンテンツを用いる、請求項６に記載の方法。
【請求項８】
更新処理を反転させるための方法であって、前記更新処理は、記憶装置に記憶されたコンテンツの記憶されたバージョンを、更新されたバージョンおよび元のバージョンのうちの１つに更新パッケージを用いて更新するように構成され、前記方法は、
更新中に前に実行された前記更新パッケージに含まれる更新コマンドを反転させるステップを含む方法。
【請求項９】
更新は、記憶されたバージョンを更新されたバージョンに順方向に更新することである、請求項８に記載の方法。
【請求項１０】
更新は、記憶されたバージョンを元のバージョンにロールバックすることである、請求項８に記載の方法。
【請求項１１】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いてインプレース更新（in-place updating）するための方法であって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記方法は、
前記更新の方向を決定するステップと、
前記方向が順方向を示す場合、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新し、順方向更新は、前記更新パッケージに含まれる更新コマンドを用、
そうでない場合、前記記憶されたバージョンを前記元のバージョンにロールバックし、ロールバックは、前記更新パッケージに含まれる更新コマンドを用いるステップとを含む方法。
【請求項１２】
記憶されたバージョンの更新処理を実現するための方法であって、
前記記憶されたバージョンを第１のバージョンに更新するための順方向更新を実現するステップであって、前記順方向更新は、更新パッケージに含まれる更新コマンドを用いるステップと、
前記記憶されたバージョンを第２のバージョンに更新するためのロールバック更新を実現するステップであって、前記ロールバック更新は、前記更新パッケージに含まれる更新コマンドを用いるステップと、
前記順方向更新および前記ロールバック更新のうちのいずれかである第１の更新動作を適用するステップと、
前記順方向更新および前記ロールバック更新のうちのいずれかであって、前記第１の更新動作以外の第２の更新動作を適用するステップとを含む方法。
【請求項１３】
記憶されたバージョンの更新処理を実現するための方法であって、
前記記憶されたバージョンを元のバージョンに更新するためのロールバック更新を適用するステップであって、前記ロールバック更新は、前記元のバージョンを前記記憶されたバージョンに更新するために前に用いられた更新パッケージに含まれる更新コマンドを用いるように構成されているステップを含む方法。
【請求項１４】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いて更新するためのシステムであって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記更新パッケージは更新コマンドを含み、前記更新は更新シーケンスに従って行なわれ、前記システムは、
前記更新の方向を決定するように構成された方向決定ユニットと、
前記方向決定ユニットに接続され、前記更新の方向が順方向を示す場合、前記更新シーケンスに従って、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新する装置であって、前記更新パッケージに含まれる更新コマンドに従って動作するように構成されている順方向更新処理装置と、
前記方向決定ユニットに接続され、前記方向がロールバックを示す場合、前記更新シーケンスと逆のロールバック更新シーケンスを生成するロールバックシーケンス生成器と、
前記ロールバックシーケンス生成器に接続され、前記ロールバック更新に従って、前記記憶されたバージョンを前記元のバージョンにロールバックする装置であって、前記更新パッケージに含まれる更新コマンドに従って動作するように構成されているロールバック更新処理装置とを備えるシステム。
【請求項１５】
前記方向決定ユニットは、方向指示に従って方向を決定するように構成されている、請求項１４に記載のシステム。
【請求項１６】
前記記憶されたバージョンは、元のバージョン、更新されたバージョンおよび中間バージョンを含む群のうちの１つである、請求項１４および１５のいずれかに記載のシステム。
【請求項１７】
更新処理を反転させるためのシステムであって、前記更新処理は、記憶装置に記憶されたコンテンツの記憶されたバージョンを更新されたバージョンおよび元のバージョンのうちの１つに更新パッケージを用いて更新するように構成され、前記システムは、
更新中に前に実行された前記更新パッケージの更新コマンドを反転させる更新コマンド反転ユニットを備えるシステム。
【請求項１８】
記憶装置に記憶されたコンテンツの記憶されたバージョンを更新パッケージを用いてインプレース更新するためのシステムであって、前記更新パッケージは、コンテンツの元のバージョンを更新されたバージョンに更新するように構成され、前記システムは、
前記更新の方向を決定するように構成された方向決定ユニットと、
前記方向決定ユニットに接続され、前記方向が順方向を示す場合、前記記憶されたバージョンを前記更新されたバージョンに順方向に更新する装置であって、前記更新パッケージに含まれる更新コマンドに従って、前記記憶されたバージョンを更新するように構成されている順方向更新処理装置と、
前記方向決定ユニットに接続され、前記方向がロールバックを示す場合、前記記憶されたバージョンを前記元のバージョンにロールバックする装置であって、前記更新パッケージに含まれる更新コマンドに従って、前記記憶されたバージョンを更新するように構成されているロールバック更新処理装置とを備えるシステム。
【請求項１９】
コンピュータ上で動作する、請求項１〜１３および２１〜２５のいずれかに記載の方法を実行するためのコンピュータプログラムコード手段を含むコンピュータプログラム。
【請求項２０】
コンピュータで読み取り可能な媒体上に実施された、請求項１９に記載のコンピュータプログラム。
【請求項２１】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１に記載の方法。
【請求項２２】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項８に記載の方法。
【請求項２３】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１１に記載の方法。
【請求項２４】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１２に記載の方法。
【請求項２５】
前記更新パッケージは更新コマンドを含み、前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１３に記載の方法。
【請求項２６】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１４に記載のシステム。
【請求項２７】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１７に記載のシステム。
【請求項２８】
前記更新パッケージに含まれる各更新コマンドは、前記記憶装置内の個別のブロックに記憶されたコンテンツの更新を可能にする、請求項１８に記載のシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００６９
【補正方法】変更
【補正の内容】
【００６９】
同図を見ると、元のバージョン３０１の両側を埋める２つの空きセグメントが存在することが示されている。具体的には、これらはセグメント３１８および３１９である。更新されたバージョン３０２を埋める２つの空きセグメント３２０および３２１も存在する。なお、空きセグメント３１８、３１９、３２０および３２１は、元のバージョンまたは更新されたバージョンの一部ではなく、これらは、元のバージョンまたは更新されたバージョンによって占められた際の、ブロック３１６における未使用領域である。これらの空きセグメントは、その他のファイルの一部であるコンテンツを記憶するために用いられる場合がある。本例によれば、空きセグメント３２０は空きセグメント３１８よりも小さく、空きセグメント３２１は空きセグメント３１９よりも小さいことにさらに注目されたい。すなわち、元のバージョン３０１によって占められるスペースは、更新されたバージョン３０２によって占められる大きさよりも小さい。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００８０
【補正方法】変更
【補正の内容】
【００８０】
別の例によれば、更新処理は、開始時に、「携帯端末はソフトウェアを更新中です。更新は３０分間継続すると見込まれ、その間、電話は動作不能となります」といったメッセージをユーザに提示することができる。ユーザが、次の３０分以内に電話を使用しなければならない場合、ユーザには、更新処理をキャンセルする（したがって、これを後に延期する）オプションが与えられる。しかし、更新処理は、ユーザがキャンセルを押す前に更新タスクの一部を行なうかもしれず、これにより、中間バージョンが生じる。したがって、ユーザが「キャンセル」を押すと、更新処理は反転し、元のバージョンに復帰しなくてはならない。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０１２２
【補正方法】変更
【補正の内容】
【０１２２】
図８は、本発明の一実施形態に係る、反転可能な更新処理においてソースバージョンからターゲットバージョンへの更新の間に実行される主な手順を示すフローチャートである。なお、８０１において、方向指示部４１９の値に従って更新処理の方向が決定される。指示部が、更新処理は順方向更新であるべきであると示している場合、８０２において、更新処理は、更新パッケージに従って順方向に動作することになる。終了（正常終了または失敗）時に、８０３において、更新処理は前の更新処理（開始された場合）はロールバックを実行すべきであると指示するように方向指示部を設定する。しかし、８０１において、更新処理が、更新処理はロールバックを実行するように動作すべきであると決定する場合は、８０４において、更新処理は、更新パッケージに従ってロールバック方向に動作する。終了（正常終了または失敗）時、８０５において、更新処理は、前の更新処理（開始された場合）は順方向更新を実行すべきであると指示するように方向指示部を設定する。
【国際調査報告】
2008501180.tif 000016
2008501180.tif 000017