JP6160455B2 - システム移行プログラム、システム移行方法および情報処理システム - Google Patents

Description

本発明はシステム移行プログラム、システム移行方法および情報処理システムに関する。

現在、情報処理装置（例えば、コンピュータ）では種々のソフトウェア（オペレーティングシステムやアプリケーションなど）が利用されている。情報処理装置のソフトウェアを現状のまま別の情報処理装置に移行させることがある。例えば、情報処理装置を入れ替える場合である。ソフトウェアの移行は、例えばソフトウェアを動作させるためのデータ（実行可能コードやパラメータ情報など）を移行元の情報処理装置から移行先の情報処理装置に送信することで行える。ここで、装置間でのデータの移行方法が考えられている。

例えば、保安データ（デジタルコンテンツやデジタルコンテンツ使用のための権利オブジェクト）を移動させる方法の提案がある。この提案では、第１装置から第２装置へ保安データを移動させる際に、第１装置で保安データに対する状態情報（０または１で表現される情報）を使用不可状態に設定してから、保安データのコピーを第２装置に伝送する。

また、ユーザ固有鍵を用いて、交換前の携帯電話機内に保存されている端末保存データを暗号化してメモリカードに書き込み、メモリカードに書き込まれた端末保存データを交換後の携帯電話機に読み込んで復号することで、端末保存データを移動する提案もある。

更に、第１ストレージ装置の移行元ボリュームから第２ストレージ装置の移行先ボリュームへのデータコピー後、移行元／移行先ボリュームのデータが一致する場合に、ホスト計算機の接続先を第１ストレージ装置から第２ストレージ装置に切り替える提案もある。

特表２００９−５３６３９３号公報 特開２００２−３４２１６８号公報 特開２００５−２４２６９６号公報

移行元である第１の装置に移行対象のソフトウェアのデータを残して、移行先である第２の装置にそのデータを送信することが考えられる。この場合、送信中に通信で障害が発生しても、第１の装置に保持されたデータからソフトウェアを復旧できる。しかし、移行対象のソフトウェアが両方の装置で動作可能になると、当該ソフトウェアの両装置による並列動作が問題となる。システム障害の要因になり得るからである。例えば、オペレーティングシステムが移行対象の場合、オペレーティングシステムで設定された所定の識別情報がネットワーク上に重複して存在すると、その識別情報を指定して行われる通信を正常に行えないおそれがある。また、データ管理用のソフトウェアが移行対象の場合、両装置により管理対象のデータが別個に操作されると、データ不整合を生じるおそれがある。

ここで、上記のように第１の装置で送信対象のデータの状態情報を使用不可状態に設定してから、そのデータのコピーを第２の装置に送信することも考えられる。しかし、この場合、データ自体は両装置上に存在することになる。このため、状態情報が無視されたり、状態情報の設定が改変されたりするだけでソフトウェアが両装置で並列に動作し得る。

１つの側面では、本発明は、移行元および移行先の両装置で移行対象のソフトウェアが並列に動作することを抑制できるシステム移行プログラム、システム移行方法および情報処理システムを提供することを目的とする。

１つの態様では、ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へソフトウェアを移行させるシステム移行プログラムが提供される。このシステム移行プログラムは、第１の装置として用いられるコンピュータに、第１のデータを保持しながら、第１のデータをエンコードした第２のデータを第２の装置に送信し、第２の装置による第２のデータのデコードが開始される前に第１の装置により保持される第１のデータのエンコードを開始し、第２の装置によるデコードが完了される前に、第１のデータをエンコード後のデータに置き換える、処理を実行させる。

また、１つの態様では、ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へソフトウェアを移行させるシステム移行プログラムが提供される。このシステム移行プログラムは、第２の装置として用いられるコンピュータに、第１のデータをエンコードした第２のデータを第１の装置から受信し、第１の装置に格納されている第１のデータの第１の装置によるエンコードが開始された後に、受信した第２のデータのデコードを開始し、第１の装置による第１のデータのエンコード後のデータへの置き換えが完了された後に、デコードを完了する、処理を実行させる。

また、１つの態様では、ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へソフトウェアを移行させるシステム移行方法が提供される。このシステム移行方法では、第１の装置が、第１のデータを保持しながら、第１のデータをエンコードした第２のデータを第２の装置に送信し、第２の装置による第２のデータのデコードが開始される前に第１の装置により保持される第１のデータのエンコードを開始し、第２の装置によるデコードが完了される前に、第１のデータをエンコード後のデータに置き換える。

また、１つの態様では、情報処理システムが提供される。この情報処理システムは、第１の装置と第２の装置とを有する。第１の装置は、ソフトウェアを動作させるための第１のデータを保持しながら第１のデータをエンコードした第２のデータを送信する。第２の装置は、第２のデータを受信してデコードする。第１の装置は、第２の装置による第２のデータのデコードが開始される前に自身が保持する第１のデータのエンコードを開始し、第２の装置によるデコードが完了される前に、第１のデータをエンコード後のデータに置き換える。

１つの側面では、移行元および移行先の両装置で移行対象のソフトウェアが並列に動作することを抑制できる。

第１の実施の形態の情報処理システムを示す図である。 第２の実施の形態の情報処理システムを示す図である。 サーバのハードウェア例を示す図である。 サーバの機能例を示す図である。 記憶領域の例を示す図である。 ブロックの例を示す図である。 進捗テーブルの例を示す図である。 変換テーブルの例を示す図である。 復旧用データ群の例を示す図である。 移行処理の例を示すフローチャートである。 移行データの送信処理の例を示すフローチャートである。 暗号化ブロックデータの送信処理の例を示す図である。 移行元における移行データの変換処理の例を示すフローチャートである。 移行先における移行データの変換処理の例を示すフローチャートである。 移行元におけるブロックデータの暗号化の例を示す図である。 移行先における暗号化ブロックデータの復号の例を示す図である。 移行の流れの例を示す図である。 移行の流れの例（続き）を示す図である。 移行元における復旧処理の例を示すフローチャートである。 移行先における復旧処理の例を示すフローチャートである。 移行元における復旧処理の例を示す図である。 移行元における復旧処理の例（続き）を示す図である。 記憶領域の他の例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理システムを示す図である。第１の実施の形態の情報処理システムは、情報処理装置１，２を含む。情報処理装置１，２はＬＡＮ（Local Area Network）などのネットワークに接続されている。この情報処理システムでは、情報処理装置１（第１の装置）から情報処理装置２（第２の装置）へソフトウェアの移行を行う。移行前の段階では、情報処理装置１は移行対象のソフトウェアを動作させるためのデータを記憶している。情報処理装置２はそのデータを記憶していない。

情報処理装置１は、メモリ１ａ、記憶装置１ｂおよびプロセッサ１ｃを有する。情報処理装置２は、メモリ２ａ、記憶装置２ｂおよびプロセッサ２ｃを有する。メモリ１ａ，２ａは、例えば、ＲＡＭ（Random Access Memory）などの揮発性の記憶装置である。記憶装置１ｂ，２ｂは、例えば、ＨＤＤ（Hard Disk Drive）などの不揮発性の記憶装置である。

プロセッサ１ｃ，２ｃは、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）でもよいし、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路でもよい。また、プロセッサ１ｃ，２ｃは、複数のプロセッサの集合（マルチプロセッサ）でもよい。プロセッサ１ｃ，２ｃは、例えば、ＲＡＭなどの揮発性の記憶装置に記憶されたプログラムを実行する。

記憶装置１ｂは、移行対象のソフトウェアを動作させるためのデータ３を記憶する。移行対象のソフトウェアは、情報処理装置１で動作するオペレーティングシステム（ＯＳ：Operating System）でもよいし、情報処理装置１のＯＳ上で動作する所定のアプリケーションでもよい。データ３は、ソフトウェアの実行可能コードや動作用のパラメータ情報などの集合である。例えば、情報処理装置２にもデータ３を格納すれば、情報処理装置２でも、情報処理装置１と同じ設定でソフトウェアを利用できる。

プロセッサ１ｃは、記憶装置１ｂにデータ３を保持しながら、データ３をエンコードしたデータ（エンコード後データ３ａという）を情報処理装置２に送信する。例えば、プロセッサ１ｃは記憶装置１ｂからデータ３の複数の部分を、部分毎に順番にメモリ１ａに読み出す。プロセッサ１ｃは、部分毎にエンコードして情報処理装置２に送信する。

ここで、エンコード（符号化）は、所定の手順でデータ３を変換する処理であるといえる。例えば、エンコードは暗号化でもよいし、ビット反転などでもよい。なお、ここでのエンコードは可逆変換である。情報処理装置２による後述のデコードによりエンコード前のデータ３を復元できなければ、情報処理装置２によりソフトウェアを適切に動作させることができないからである。

プロセッサ２ｃは、エンコード後データ３ａを受信し、記憶装置２ｂに格納する。例えば、プロセッサ２ｃは、データ３の部分毎のエンコード結果を情報処理装置１から順次受信し、それらを結合してエンコード後データ３ａを得ることができる。その結果、情報処理装置１にデータ３が保持され、情報処理装置２にエンコード後データ３ａが保持された状態となる。その後、プロセッサ１ｃは、プロセッサ２ｃによりエンコード後データ３ａのデコードが開始される前に、データ３のエンコードを開始する。また、プロセッサ２ｃは、プロセッサ１ｃによりデータ３のエンコードが開始された後に、エンコード後データ３ａのデコードを開始する。

プロセッサ１ｃは、情報処理装置２によるエンコード後データ３ａのデコードが完了される前に、記憶装置１ｂに格納されたデータ３をエンコード後のデータ３ｂ（エンコード後データ３ｂという）に置き換える。例えば、プロセッサ１ｃは、記憶装置１ｂからデータ３の複数の部分を順番にメモリ１ａに読み出し、部分毎にエンコードする。プロセッサ１ｃは、そのエンコード結果を当該部分に対応する記憶装置１ｂの記憶領域に上書きする。プロセッサ１ｃは、これを繰り返すことで、記憶装置１ｂのデータ３をエンコード後データ３ｂに置き換えることができる。

なお、データ３をエンコード後データ３ｂに置き換えるときのエンコード方法は、エンコード後データ３ａを生成したときと同じ方法でもよいし異なる方法でもよい。例えば、可逆変換でもよいし不可逆変換でもよい。ただし、情報処理装置２でのデコード途中における障害（例えば、記憶装置２ｂの故障）に対する復旧を考えると可逆変換が好ましい。エンコード後データ３ｂを逆変換することで、データ３を復元できるからである。

また、情報処理装置２によるデコード（復号）は、所定の手順でエンコード後データ３ａを逆変換する処理であるといえる。例えば、エンコード時に暗号化が行われていれば、デコードでは暗号を復号することになる。エンコード時にビット反転が行われていれば、デコードでもビット反転を行うことになる。デコードの結果、情報処理装置２はデータ３を得る。

ここで、プロセッサ１ｃが記憶装置１ｂのデータ３をエンコード後データ３ｂに置き換える処理は、情報処理装置２の立場から表すこともできる。すなわち、プロセッサ１ｃは、情報処理装置１に格納されているデータ３のエンコード後データ３ｂへの置き換えが完了された後に、エンコード後データ３ａのデコードを完了する。

プロセッサ１ｃによるデータ３のエンコードと、プロセッサ２ｃによるエンコード後データ３ａのデコードとは並行して行われることになる。プロセッサ１ｃ，２ｃは、互いに通信して、情報処理装置１でのエンコードが、情報処理装置２でのデコードよりも先に完了するように、互いの変換処理の進行を制御する。例えば、プロセッサ１ｃ，２ｃは、エンコード後データ３ａのデコードが行われている間（記憶装置２ｂにデコード中のデータ３ｃが格納されている間）に、記憶装置１ｂ内のデータ３がエンコード後データ３ｂに置き換えられるように制御する。

情報処理装置１によれば、データ３が保持されながら、データ３をエンコードしたエンコード後データ３ａが情報処理装置２に送信される。情報処理装置２によるエンコード後データ３ａのデコードが開始される前に情報処理装置１により保持されるデータ３のエンコードが開始され、情報処理装置２による当該デコードが完了される前に、情報処理装置１により保持されるデータ３がエンコード後データ３ｂに置き換えられる。

これにより、移行元および移行先の両装置で移行対象のソフトウェアが並列に動作すること（移行対象のソフトウェアの両装置による並列動作）を抑制できる。具体的には、次の通りである。エンコード後データ３ａ，３ｂは、データ３とは異なる情報であり、エンコード後データ３ａ，３ｂからはソフトウェアを動作させることはできない。このため、情報処理装置１でデータ３を、情報処理装置２でエンコード後データ３ａを、それぞれ同時に保持したとしても、移行対象のソフトウェアが情報処理装置２で動作することはない。また、情報処理装置２でエンコード後データ３ａのデコードが完了しているときには、情報処理装置１ではエンコード後データ３ｂが保持されていることになる。このため、デコードが完了して情報処理装置２がデータ３を保持しても、情報処理装置１で移行対象のソフトウェアが動作することはない。よって、移行対象のソフトウェアが情報処理装置１，２で並列に動作することを抑制できる。

ここで、例えば、データ３に状態情報を設定可能とし、情報処理装置１でデータ３の状態情報を使用不可状態に設定してから情報処理装置２へデータ３のコピーを送信することも考えられる。しかし、この場合、データ３自体は両方の装置上に存在することになる。このため、状態情報が無視されたり（例えば、状態情報のチェックを行う機能が適切に動作しないなど）、状態情報の設定が不測の処理により改変されたりするだけで、移行対象のソフトウェアが情報処理装置１，２で並列に動作し得る。また、ユーザによる運用上のミスによって、移行対象のソフトウェアが情報処理装置１，２で並列に動作してしまうおそれもある。データ３が両方の装置上に存在する限り、これらのリスクは残る。

一方、第１の実施の形態によれば、情報処理装置１，２によりデータ３を同時に保持させないので、上記のような不測の事態においても、移行対象のソフトウェアが情報処理装置１，２で並列に動作することを抑制できる。よって、状態情報を用いる方法よりも安全にソフトウェアの移行を行える。

また、データ３のうち送信済の部分を情報処理装置１から削除しながら、情報処理装置２にデータ３を送信することも考えられる。しかし、この場合、送信中に通信障害が発生すると、情報処理装置１，２の何れにも元のデータ３が存在しないことになる。このため、移行途中であったソフトウェアの復旧が困難になり得る。

これに対し、情報処理装置１は、データ３を保持しながらエンコード後データ３ａを情報処理装置２に送信する。このため、仮にエンコード後データ３ａの送信中に通信障害が発生しても、情報処理装置１上にデータ３が残る。このデータ３を用いて、情報処理装置１上でソフトウェアを動作させたり、データ３の移動を再度行ったりすることができる。よって、第１の実施の形態の方法は、データ３を削除しながら移行先の装置に送信する方法よりも安全である。

なお、ソフトウェアの複製がライセンス違反になることもある。例えば、移行対象のソフトウェアについて装置１台につき１ライセンスという契約であれば、情報処理装置１，２上でそのソフトウェアが同時に利用可能になると、ライセンス違反になる。一方、第１の実施の形態の方法では、情報処理装置１，２上に同時にソフトウェアの複製を存在させない。このため、ライセンスにより複製が制限されているソフトウェアを移行する場合に、ライセンス違反となるリスクを低減できるという利点もある。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、サーバ１００，２００を含む。サーバ１００，２００は、ネットワーク１０に接続されている。ネットワーク１０は例えばＬＡＮなどのネットワークである。

サーバ１００は、所定のアプリケーションにより実現されるサービスをクライアントコンピュータ（図示を省略）に提供するサーバコンピュータである。サーバ１００には、提供するサービスに応じたアプリケーションが予めインストールされる。

インストールとは、サーバ１００でソフトウェアを利用可能にする際に、ソフトウェアを動作させるためのデータをサーバ１００が備える所定の記憶装置に格納することを示す。ここで、後述するように、サーバ１００は揮発性／不揮発性の両方の記憶装置を備える。以下の説明では、単にインストールという場合、あるソフトウェアを動作させるためのデータを不揮発性の記憶装置に格納することを指すものとする。あるソフトウェアを動作させるためのデータをＲＡＭなどの揮発性の記憶装置にのみ格納する場合はその旨を明示する。また、ソフトウェアを動作させるためのデータは、ソフトウェアの実行可能コードや動作用のパラメータ情報などの集合である。

サーバ１００上のアプリケーションの実行は、サーバ１００上のＯＳによって制御される。すなわち、サーバ１００にはＯＳもインストールされている。例えば、サーバ１００のＯＳは、サーバ１００上のアプリケーションに対して、サーバ１００が備えるプロセッサやＲＡＭなどのリソースの割り当てを制御する。

例えば、サーバ１００は、Ｗｅｂ３階層システムの何れかの階層の機能を実現するものでもよい。具体的には、サーバ１００は、Ｗｅｂサーバ、アプリケーションサーバおよびＤＢ（DataBase）サーバの何れかでもよい。例えば、Ｗｅｂサーバとして機能させるなら、Ｗｅｂサーバ機能を実現するアプリケーションがサーバ１００にインストールされる。アプリケーションサーバとして機能させるなら所定の業務ロジックを実現するアプリケーションがサーバ１００にインストールされる。ＤＢサーバとして機能させるなら、ＤＢ機能を実現するアプリケーションがサーバ１００にインストールされる。また、サーバ１００は、ファイルサーバやメールサーバなど他のサービスを提供するものでもよい。

なお、サーバ１００は、スタンドアロンで（他のコンピュータと連携せずに）所定のサービスをユーザに提供するコンピュータでもよい。例えば、ユーザは、サーバ１００を直接操作して、サーバ１００にインストールされた所定のアプリケーションを利用してもよい。具体的には、文書作成用のアプリケーション、表計算用のアプリケーション、データ管理用のアプリケーションおよび作図用のアプリケーションなどをサーバ１００にインストールし、これらのアプリケーションをユーザにより利用可能とすることが考えられる。

サーバ２００は、サーバ１００で動作するソフトウェアの移行先となるサーバコンピュータである。例えば、サーバ１００をサーバ２００に入れ替える場合に、サーバ１００上のソフトウェアがサーバ２００へ移行される。このとき、サーバ１００のソフトウェアの利用環境をサーバ２００でも引き継ぎたいことがある。その場合、サーバ１００にインストールされた各ソフトウェアについて、一連の移行作業（例えば、サーバ２００へのインストール作業や動作用の設定作業など）をユーザが行うとすると、ユーザにとって手間である。

そこで、サーバ１００，２００は、ソフトウェアの移行を支援する機能を提供する。移行対象のソフトウェアは、サーバ１００にインストールされたＯＳやアプリケーションを含む。以下の説明では、サーバ１００を“移行元”、サーバ２００を“移行先”と表記することで、両者を区別することがある。ここで、サーバ１００は第１の実施の形態の情報処理装置１（第１の装置）の一例である。サーバ２００は第１の実施の形態の情報処理装置２（第２の装置）の一例である。

図３は、サーバのハードウェア例を示す図である。サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、通信部１０４、画像信号処理部１０５、入力信号処理部１０６、ディスクドライブ１０７および機器接続部１０８を有する。各ユニットがサーバ１００のバスに接続されている。サーバ２００もサーバ１００と同様のユニットを用いて実現できる。

プロセッサ１０１は、サーバ１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、サーバ１００の主記憶装置である。ＲＡＭ１０２は、揮発性の記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１の処理に用いられる各種データを記憶する。

ＨＤＤ１０３は、サーバ１００の補助記憶装置である。ＨＤＤ１０３は、不揮発性の記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、サーバ１００にインストールされたＯＳのプログラム、アプリケーションのプログラム、および各種データが格納される。サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

通信部１０４は、ネットワーク１０を介してサーバ２００を含む他のコンピュータと通信を行えるインタフェースである。通信部１０４は、有線インタフェースでもよいし、無線インタフェースでもよい。通信部１０４は、例えば、プロセッサ１０１からの命令に従って、ネットワーク１０を介して接続された他のコンピュータからプログラムをダウンロードしてＲＡＭ１０２またはＨＤＤ１０３に格納することもできる。

画像信号処理部１０５は、プロセッサ１０１からの命令に従って、サーバ１００に接続されたディスプレイ１１に画像を出力する。
入力信号処理部１０６は、サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。

ディスクドライブ１０７は、レーザ光などを利用して、光ディスク１３に記録されたプログラムやデータを読み取る駆動装置である。ディスクドライブ１０７は、例えば、プロセッサ１０１からの命令に従って、光ディスク１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

機器接続部１０８は、サーバ１００に周辺機器を接続するためのインタフェースである。機器接続部１０８は、例えば、プロセッサ１０１からの命令に従って、外部記憶装置１４、または、リーダライタ装置１５などを介してメモリカード１６から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

図４は、サーバの機能例を示す図である。サーバ１００は、バッファ１１０、データ記憶部１２０および移行元処理部１３０を有する。バッファ１１０はＲＡＭ１０２に確保した記憶領域として実現できる。データ記憶部１２０はＨＤＤ１０３に確保した記憶領域として実現できる。移行元処理部１３０は、プロセッサ１０１により実行されるプログラムのモジュールとして実現できる。

バッファ１１０は、移行元処理部１３０の作業用の記憶領域である。バッファ１１０は、移行元処理部１３０によりデータ記憶部１２０から読み出されたデータを記憶する。
データ記憶部１２０は、ソフトウェアを動作させるためのデータを記憶する。当該データは、前述のようにソフトウェアの実行可能コードや動作用のパラメータ情報などを含む。データ記憶部１２０は、ＯＳ管理外領域１２１およびＯＳ管理領域１２２を含む。

ＯＳ管理外領域１２１は、サーバ１００にインストールされたＯＳの管理対象外の領域である。すなわち、当該ＯＳは、ＯＳ管理外領域１２１に格納された情報を操作することができない。ＯＳ管理外領域１２１は、移行元処理部１３０による処理の進捗管理用の情報（進捗情報）を記憶する。

ＯＳ管理領域１２２は、サーバ１００にインストールされたＯＳにより管理される領域である。当該ＯＳは、ＯＳ管理領域１２２に格納された情報を操作できる。ＯＳ管理領域１２２は、サーバ１００にインストールされたＯＳやアプリケーションのデータを記憶する。また、ＯＳ管理領域１２２は、当該ＯＳやアプリケーションを用いて作成されたユーザデータなども記憶する。ＯＳ管理領域１２２に格納されたデータは、サーバ１００からサーバ２００へＯＳやアプリケーションを移行させる際の主な移動対象である。

移行元処理部１３０は、サーバ２００と連携して、サーバ１００からサーバ２００へのソフトウェアの移行を制御する。移行元処理部１３０は、管理部１３１、暗号化部１３２およびハッシュ処理部１３３を有する。

管理部１３１は、ソフトウェアの移行処理の全体を管理する。ソフトウェアの移行処理では、次の２段階の処理を行う。第１段階は、ＯＳ管理領域１２２に格納されたデータをＯＳ管理領域１２２に保持しながら、そのデータを暗号化してサーバ２００に送信する処理である。第２段階は、ＯＳ管理領域１２２のデータを暗号化し、サーバ２００で暗号化後のデータを復号する処理である。

管理部１３１は、第１段階ではサーバ１００からサーバ２００に対して暗号化されたデータを送信し、その進捗を管理する。管理部１３１は、第２段階ではＯＳ管理領域１２２の暗号化を暗号化部１３２に実行させ、その進捗を管理する。管理部１３１は、各段階における処理の進捗情報をＯＳ管理外領域１２１に格納する。管理部１３１は、障害によりソフトウェアの移行が中断されると、ＯＳ管理外領域１２１に格納された情報に基づいて、ソフトウェアの移行を再開する。

暗号化部１３２は、ＯＳ管理領域１２２に格納されたデータの暗号化を行う。後述するように、データ記憶部１２０の記憶領域はブロックと呼ばれる固定長の単位で管理される。暗号化部１３２は、ＯＳ管理領域１２２のデータをブロック単位に順次読み出し、ブロック単位に読み出されたデータを暗号化する。以下の説明では、ブロック単位のデータをブロックデータということがある。この場合、ブロックデータは、ＯＳ管理領域１２２に記憶されたデータの一部分である。暗号化部１３２による暗号化の前後で、暗号化対象のブロックデータのサイズは変わらないものとする。

ハッシュ処理部１３３は、暗号化部１３２によって暗号化されたブロックデータのハッシュ値を計算し、ＯＳ管理外領域１２１に記録する。ハッシュ処理部１３３がハッシュ化に用いる手順（ハッシュ関数など）は、ハッシュ処理部１３３に予め与えられる。

サーバ２００は、バッファ２１０、データ記憶部２２０および移行先処理部２３０を有する。バッファ２１０は、サーバ２００が備えるＲＡＭに確保した記憶領域として実現できる。データ記憶部２２０は、サーバ２００が備えるＨＤＤに確保した記憶領域として実現できる。移行先処理部２３０は、サーバ２００が備えるプロセッサにより実行されるプログラムのモジュールとして実現できる。

バッファ２１０は、移行先処理部２３０の作業用の記憶領域である。バッファ２１０は、移行先処理部２３０によりデータ記憶部２２０から読み出されたデータを記憶する。
データ記憶部２２０は、サーバ１００から取得されたデータを記憶する。データ記憶部２２０は、ＯＳ管理外領域２２１およびＯＳ管理領域２２２を有する。

ＯＳ管理外領域２２１は、サーバ２００にインストールされるＯＳの管理対象外の領域である。すなわち、当該ＯＳは、ＯＳ管理外領域２２１に格納された情報を操作することができない。ＯＳ管理外領域２２１は、移行先処理部２３０による処理の進捗情報を記憶する。

ＯＳ管理領域２２２は、ＯＳ管理領域１２２に格納されたデータの移動先の記憶領域である。前述の第１段階では、ＯＳ管理領域１２２上のデータを暗号化したデータが、ＯＳ管理領域２２２に格納される。暗号化したデータが復号されてＯＳ管理領域２２２上に格納されると、サーバ１００にインストールされていたＯＳおよびアプリケーションと同等のＯＳおよびアプリケーションが、サーバ２００上で利用可能になる。その際に、ＯＳ管理領域２２２内の情報は、当該ＯＳによって操作可能になる（そのため、この領域を「ＯＳ管理領域」と称している）。

移行先処理部２３０は、サーバ１００と連携して、サーバ１００からサーバ２００へのソフトウェアの移行を制御する。移行先処理部２３０は、管理部２３１、復号部２３２およびハッシュ処理部２３３を有する。

管理部２３１は、管理部１３１と連携してソフトウェアの移行処理の全体を管理する。管理部２３１は、前述の第１段階ではサーバ１００から暗号化されたデータを受信し、その進捗を管理する。管理部２３１は、前述の第２段階ではＯＳ管理領域２２２のデータの復号を復号部２３２に実行させ、その進捗を管理する。管理部２３１は、各段階における処理の進捗情報をＯＳ管理外領域２２１に格納する。管理部２３１は、障害によりソフトウェアの移行が中断されると、ＯＳ管理外領域２２１に格納された情報に基づいて、ソフトウェアの移行を再開する。

復号部２３２は、ＯＳ管理領域２２２に格納されたデータの復号を行う。復号部２３２は、ＯＳ管理領域２２２のブロックデータを順次読み出し、復号する。復号部２３２による復号の前後で、復号対象のブロックデータのサイズは変わらない。

ハッシュ処理部２３３は、復号部２３２によって復号されたブロックデータのハッシュ値を計算し、ＯＳ管理外領域２２１に記録する。ハッシュ処理部２３３がハッシュ化に用いる手順（ハッシュ関数など）は、ハッシュ処理部２３３に予め与えられる。

ここで、移行元処理部１３０および移行先処理部２３０は、移行対象のＯＳとは別個に実現される。移行元処理部１３０および移行先処理部２３０からデータ記憶部１２０，２２０の全ての領域にアクセス可能とするためである。例えば、移行元処理部１３０および移行先処理部２３０は、サーバ１００，２００で動作する所定のオンメモリＯＳ上で実行されてもよい。その場合、移行元処理部１３０および移行先処理部２３０は、オンメモリＯＳが提供する機能（他のコンピュータとの通信機能などの基本的な機能）を利用できる。例えば、Ｗｉｎｄｏｗｓ（登録商標）系のオンメモリＯＳとして、Ｗｉｎｄｏｗｓ ＰＥ（Preinstallation Environment）が知られている。また、Ｌｉｎｕｘ（登録商標）系のオンメモリＯＳとして、ＫＮＯＰＰＩＸやＵｂｕｎｔｕ（登録商標）などが知られている。

オンメモリＯＳ、移行元処理部１３０および移行先処理部２３０のプログラムは、所定の記録媒体（光ディスク１３、外部記憶装置１４およびメモリカード１６など）やネットワーク１０に接続された他のコンピュータ上に格納しておくことができる。サーバ１００，２００は、記録媒体から読み取ったプログラムまたは他のコンピュータからダウンロードしたプログラムをサーバ１００，２００が備えるＲＡＭに格納し、実行することで、オンメモリＯＳ、移行元処理部１３０および移行先処理部２３０の機能を発揮できる。

図５は、記憶領域の例を示す図である。データ記憶部１２０は、ＭＢＲ（Master Boot Record）領域１２３、ＯＳ管理外領域１２１およびＯＳ管理領域１２２を含む。ＯＳ管理外領域１２１およびＯＳ管理領域１２２は、図４で説明した記憶領域である。データ記憶部２２０も、データ記憶部１２０と同様の構造により実現できる。

ＭＢＲ領域１２３は、データ記憶部１２０内の各記憶領域を管理するためのＭＢＲと呼ばれる情報を格納する記憶領域である。例えば、ＭＢＲ領域１２３は、データ記憶部１２０の先頭ブロック（あるいは、先頭セクタ）に存在している。ＯＳ管理領域１２２は、ＭＢＲ領域よりも後ろの領域に配置される。

このとき、ＭＢＲ領域１２３とＯＳ管理領域１２２との間に所定数ブロック分の空き領域（例えば、数１０ｋＢ（kilo Bytes）〜数ＭＢ（Mega Bytes）程度）が存在することがある。例えば、ＵＲＬ“ｈｔｔｐ：／／ｗｗｗ．ｋｏｚｕｐｏｎ．ｃｏｍ／ｅｔｃ／ｄｉｓｋ＿ｏｓ．ｈｔｍｌ”にこの空き領域の例示がある。そこで、この空き領域をＯＳ管理外領域１２１として利用することが考えられる。

ただし、それ以外の領域をＯＳ管理外領域１２１として利用してもよい。例えば、データ記憶部１２０において、ＯＳ管理領域１２２よりも後方の領域がサーバ１００にインストールされたＯＳにより利用されないことが明らかであれば、その領域をＯＳ管理外領域１２１として利用してもよい。例えば、データ記憶部１２０の最後のブロックから前側の所定数のブロック範囲を含む領域が当該ＯＳにより利用されないことが明らかであれば、その領域をＯＳ管理外領域１２１として利用することも考えられる。

ここで、ＯＳ管理外領域１２１は、進捗テーブル１２１ａ、変換テーブル１２１ｂおよび復旧用データ群１２１ｃを記憶する。進捗テーブル１２１ａ、変換テーブル１２１ｂおよび復旧用データ群１２１ｃは、移行の進捗をブロック単位に管理するための情報である。また、これらの情報はＯＳ管理外領域２２１にも格納される。

図６は、ブロックの例を示す図である。データ記憶部１２０の記憶領域は、ブロックと呼ばれる単位で管理される。データ記憶部２２０の記憶領域も同様に、ブロックと呼ばれる単位で管理される。一例として、１ブロックのサイズ（すなわち、１ブロックデータのサイズ）を５１２Ｂ（Bytes）とする。ただし、４ｋＢ＝４０９６Ｂなど他のサイズでもよい。

例えば、ＯＳ管理領域１２２に含まれる各ブロックの物理的な位置は、ブロック番号によって把握できる。先頭のブロックから昇順にブロック番号が対応付けられている。例えば、ＯＳ管理領域１２２には、ブロック番号“３２０”，“３２１”，“３２２”，・・・の複数のブロックが含まれる。例えば、ブロック番号“３２０”のブロックには、ブロックデータＡ１が格納されている。ブロック番号“３２１”のブロックには、ブロックデータＡ２が格納されている。ブロック番号“３２２”のブロックには、ブロックデータＡ３が格納されている。

移行元処理部１３０は、ブロック番号によって、そのブロック番号に対応するブロックのデータ記憶部１２０上の物理的な位置を特定できる。移行先処理部２３０は、ブロック番号によって、そのブロック番号に対応するブロックのデータ記憶部２２０上の物理的な位置を特定できる。

図７は、進捗テーブルの例を示す図である。図７（Ａ）は、進捗テーブル１２１ａを例示している。進捗テーブル１２１ａは、ＯＳ管理外領域１２１に格納される。図７（Ｂ）は、進捗テーブル２２１ａを例示している。進捗テーブル２２１ａは、ＯＳ管理外領域２２１に格納される。

進捗テーブル１２１ａ，２２１ａは、サーバ１００からサーバ２００へのデータ送信処理や、サーバ１００，２００でのデータ変換（暗号化／復号）処理の進捗を管理するための情報である。以下では、進捗テーブル１２１ａを説明するが、進捗テーブル２２１ａも同様のデータ構造である。進捗テーブル１２１ａは、ブロック番号および可逆変換キーの項目を含む。

ブロック番号の項目には、処理済のブロックのブロック番号が登録される。可逆変換キーの項目には、暗号化に用いる鍵が登録される。第２の実施の形態では、一例として、サーバ１００，２００は、暗号化／復号に共通鍵を用いる。サーバ１００，２００は、この共通鍵を可逆変換キーとして保持する。

例えば、進捗テーブル１２１ａには、ブロック番号が“３２２”、可逆変換キーが“ｋｅｙＸ”という情報が登録される。これは、ブロック番号“３２２”のブロックまで処理済であることを示す。また、ブロックデータの暗号化／復号に用いる共通鍵が“ｋｅｙＸ”であることを示す。

図８は、変換テーブルの例を示す図である。図８（Ａ）は、変換テーブル１２１ｂを例示している。変換テーブル１２１ｂは、ＯＳ管理外領域１２１に格納される。図８（Ｂ）は、変換テーブル２２１ｂを例示している。変換テーブル２２１ｂは、ＯＳ管理外領域２２１に格納される。

変換テーブル１２１ｂ，２２１ｂは、データ変換（暗号化／復号）の詳細を管理するため（主に、障害時の復旧）に用いられる。以下では、変換テーブル１２１ｂを説明するが、変換テーブル２２１ｂも同様である。変換テーブル１２１ｂは、リスト番号、ブロック番号およびハッシュ値の項目を含む。

リスト番号の項目には、リスト番号が登録される。リスト番号は、後述する復旧用データ群に含まれる要素を示す番号である。ブロック番号の項目には、変換の対象となったブロック番号が登録される。ハッシュ値の項目には、変換後のブロックデータに対して算出されたハッシュ値が登録される。変換後のブロックデータとは、サーバ１００であれば暗号化後のブロックデータであり、サーバ２００であれば復号後のブロックデータである。

例えば、変換テーブル１２１ｂには、リスト番号が“１”、ブロック番号が“３２１”、変換後（サーバ１００なので暗号化後）のブロックデータのハッシュ値が“ＨＡ１”という情報が登録される。これは、リスト番号が“１”であり、当該ブロックデータがブロック番号“３２１”に対応しており、変換後（暗号化後）のブロックデータに対してハッシュ値“ＨＡ１”を算出済であることを示す。

図９は、復旧用データ群の例を示す図である。図９（Ａ）は、復旧用データ群１２１ｃを例示している。復旧用データ群１２１ｃは、ＯＳ管理外領域１２１に格納される。図９（Ｂ）は、復旧用データ群２２１ｃを例示している。復旧用データ群２２１ｃは、ＯＳ管理外領域２２１に格納される。

復旧用データ群１２１ｃ，２２１ｃは、データ変換時のエラーに対する復旧用のブロックデータを格納した配列である。復旧用データ群１２１ｃ，２２１ｃでは、前述のリスト番号に対応する要素として、変換前のブロックデータが、復旧用データとして登録される。すなわち、サーバ１００であれば暗号化前のブロックデータが復旧用データとなる。また、サーバ２００であれば復号前のブロックデータが復旧用データとなる。例えば、復旧用データ群１２１ｃは、ブロック番号“３２１”に対応するブロックデータの復旧用データ（暗号化前）を含む。その復旧用データはリスト番号“１”に対応する。

例えば、変換テーブル１２１ｂおよび復旧用データ群１２１ｃは、リングバッファによって実現できる。ＯＳ管理外領域１２１の記憶領域を循環して再利用すれば、ＯＳ管理外領域１２１の全体サイズが比較的小さくても当該領域を効率的に利用できるからである。その場合、例えば、ＯＳ管理外領域１２１のサイズに応じて、リスト番号“１”から“Ｎ”（Ｎは２以上の整数）までのレコードを格納できる。リスト番号は昇順に用いられる。リスト番号“Ｎ”の次のレコードに情報を書き込むときは、リスト番号“１”に対応するレコードが上書きされる。

次に、第２の実施の形態のソフトウェアの移行処理の手順を説明する。具体的には、ＯＳ管理領域１２２に格納されたデータを、ＯＳ管理領域２２２に移行することで、ソフトウェアの利用環境をサーバ１００からサーバ２００へ移行する。移行に際して、移行対象のＯＳを起動させずに、移行元処理部１３０および移行先処理部２３０をサーバ１００，２００上に実現させる。

例えば、ユーザは、サーバ１００の起動時に、移行元処理部１３０のプログラムを格納した記録媒体をサーバ１００に挿入する。すると、サーバ１００のＢＩＯＳ（Basic Input/Output System）により記録媒体からオンメモリＯＳがブートされ、移行元処理部１３０の機能が発揮される。前述のように、サーバ１００は、起動時に他のコンピュータからプログラムをダウンロードすることで、オンメモリＯＳをネットワークブートすることもできる。サーバ２００も同様にして、オンメモリＯＳや移行先処理部２３０の機能を発揮できる。

図１０は、移行処理の例を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
（Ｓ１１）管理部１３１は、サーバ２００（移行先サーバ）のサーバ証明書を、サーバ２００に要求する。

（Ｓ１２）管理部２３１は、サーバ１００からサーバ証明書の要求を受信する。
（Ｓ１３）管理部２３１は、要求されたサーバ２００のサーバ証明書をサーバ１００に送信する（サーバ証明書の応答）。ここで、管理部２３１は、セッションキー（共通鍵）生成用の情報（例えば、乱数など）をこの応答に含める。

（Ｓ１４）管理部１３１は、サーバ２００のサーバ証明書を受信する。
（Ｓ１５）暗号化部１３２は、管理部１３１により取得された共通鍵生成用の情報を用いて共通鍵を生成する。

（Ｓ１６）暗号化部１３２は、進捗テーブル１２１ａを生成し、ＯＳ管理外領域１２１に格納する。進捗テーブル１２１ａのブロック番号の初期値は、例えば、０である。暗号化部１３２は、生成した共通鍵（“ｋｅｙＸ”）を進捗テーブル１２１ａ（可逆変換キーの項目）に登録する。

（Ｓ１７）管理部１３１は、暗号化部１３２は、ＯＳ管理領域１２２のブロックを、先頭（ブロック番号が最小のブロック）から順番に読み出し、ステップＳ１５で生成した共通鍵を用いてそのブロックデータを暗号化する。このとき、ＯＳ管理領域１２２内のデータは、ＯＳ管理領域１２２内にそのまま保持されることになる。管理部１３１は、暗号化後のブロックデータ（暗号化ブロックデータという）をサーバ２００に順次送信する。管理部２３１は、暗号化ブロックデータを順次受信する。

（Ｓ１８）管理部１３１は、ステップＳ１５で生成した共通鍵を、サーバ２００の公開鍵を用いて暗号化し、サーバ２００に送信する。例えば、サーバ２００の公開鍵は、ステップＳ１４で取得したサーバ２００のサーバ証明書に含まれる。

（Ｓ１９）管理部２３１は、サーバ１００から暗号化後の共通鍵を受信する。復号部２３２は、管理部２３１により取得された暗号化後の共通鍵を、秘密鍵で復号する。秘密鍵は、サーバ１００に提供したサーバ証明書の公開鍵に対応するものである。公開鍵と秘密鍵とを用いた暗号化の手法は公開鍵暗号方式と呼ばれることもある。復号部２３２は、復号した共通鍵（“ｋｅｙＸ”）を進捗テーブル２２１ａに登録する。

（Ｓ２０）管理部２３１は、共通鍵の取得を完了した旨（完了通知）をサーバ１００に送信する。
（Ｓ２１）管理部１３１は、サーバ２００から完了通知を受信する。

（Ｓ２２）管理部１３１は、サーバ２００と連携して、ＯＳ管理領域１２２内のデータ（移行データ）の変換を行う。具体的には、サーバ１００はＯＳ管理領域１２２の暗号化（順変換）を行う。サーバ２００はＯＳ管理領域２２２の復号（逆変換）を行う。

なお、管理部１３１は、生成された共通鍵を暗号化してサーバ２００に送信するものとしたが、鍵の交換方法は上記の方法に限られない。例えば、ステップＳ１８において、管理部１３１は、共通鍵（“ｋｅｙＸ”）生成用の情報をサーバ２００に送信し、サーバ２００に共通鍵を生成させることも考えられる。

また、サーバ１００，２００は、ステップＳ１１の前に、自身のサーバ証明書および秘密鍵を予め取得しておく。例えば、サーバ１００，２００に読み取らせるブート用の記録媒体に各サーバのサーバ証明書や秘密鍵を格納しておくことができる。あるいは、サーバ１００，２００が他のコンピュータからプログラムをダウンロードする場合、当該他のコンピュータに各サーバのサーバ証明書や秘密鍵を格納しておき、プログラムとともにダウンロード可能にしてもよい。サーバ１００，２００は、取得したサーバ証明書や秘密鍵をＯＳ管理外領域に格納する。

図１１は、移行データの送信処理の例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１０のステップＳ１７に相当する。

（Ｓ３１）管理部１３１は、ＯＳ管理領域１２２から１つのブロックデータを読み取る。管理部１３１は、ＯＳ管理領域１２２の先頭ブロック（ブロック番号が最小のブロック）から順番に読み取る。

（Ｓ３２）管理部１３１は、読み取ったブロックデータをバッファ１１０に格納する。
（Ｓ３３）暗号化部１３２は、バッファ１１０に格納されたブロックデータを、ＯＳ管理外領域１２１に記憶された進捗テーブル１２１ａに含まれる鍵（可逆変換キー）“ｋｅｙＸ”を用いて暗号化する。これにより、暗号化部１３２は、１つのブロックデータに対して１つの暗号化ブロックデータを生成する。暗号化前のブロックデータのサイズと暗号化ブロックデータのサイズとは同一である。

（Ｓ３４）管理部１３１は、生成された暗号化ブロックデータをサーバ２００に送信する。
（Ｓ３５）管理部２３１は、サーバ１００から暗号化ブロックデータを受信する。

（Ｓ３６）管理部２３１は、暗号化ブロックデータをバッファ２１０に格納する。
（Ｓ３７）管理部２３１は、バッファ２１０に格納された暗号化ブロックデータをＯＳ管理領域２２２に書き込む。管理部２３１は、ＯＳ管理領域２２２の先頭ブロックから順番に暗号化ブロックデータを書き込んでいく。ＯＳ管理領域１２２の先頭ブロックのブロック番号と、ＯＳ管理領域２２２の先頭ブロックのブロック番号とは一致とする。

（Ｓ３８）管理部２３１は、ＯＳ管理外領域２２１に記憶された進捗テーブル２２１ａを更新する。具体的には、管理部２３１は、ステップＳ３７で書き込んだブロック位置に対応するブロック番号を、進捗テーブル２２１ａに登録する。例えば、ステップＳ３７で書き込んだブロック位置がブロック番号“３２２”に対応していれば、管理部２３１は、進捗テーブル２２１ａのブロック番号に“３２２”を登録する。例えば、管理部２３１は、現在登録されているブロック番号に１（または１単位分の値）を加算したブロック番号を登録してもよい。

（Ｓ３９）管理部２３１は、暗号化ブロックデータの受信を完了した旨（完了通知）をサーバ１００に送信する。
（Ｓ４０）管理部１３１は、サーバ２００から完了通知を受信する。

（Ｓ４１）管理部１３１は、進捗テーブル１２１ａを更新する。具体的には、管理部１３１は、ステップＳ３１で読み取ったブロック位置に対応するブロック番号を、進捗テーブル１２１ａのブロック番号に登録する。例えば、ステップＳ３１で読み取ったブロック位置がブロック番号“３２２”に対応していれば、管理部１３１は、進捗テーブル１２１ａのブロック番号に“３２２”を登録する。例えば、管理部１３１は、現在登録されているブロック番号に対して１（または１単位分の値）を加算したブロック番号を登録してもよい。

（Ｓ４２）管理部１３１は、ＯＳ管理領域１２２内の全ブロックデータを（暗号化した上で）サーバ２００に送信済であるか否かを判定する。全ブロックデータを送信済である場合、処理を終了する。全ブロックを送信済でない場合、処理をステップＳ３１に進める。

このようにして、サーバ１００は、ＯＳ管理領域１２２内のデータをブロック単位に暗号化して、サーバ２００へ順次送信する。前述のように、暗号化ブロックデータは、暗号化前のブロックデータと同一のサイズである。このため、進捗テーブル１２１ａ，２２１ａに登録されるブロック番号は、ステップＳ４１の完了時には一致する。

なお、図５で例示したように、データ記憶部１２０にＭＢＲ領域１２３などの他の領域が存在している場合もある。その場合、何れかのタイミング（例えば、図１０のステップＳ１７の前やステップＳ２２の後）に、管理部１３１，２３１は、当該他の領域のデータをデータ記憶部２２０に複製してもよい。例えば、管理部１３１，２３１は、データ記憶部２２０の先頭ブロックにＭＢＲ領域１２３を複製する。

図１２は、暗号化ブロックデータの送信処理の例を示す図である。以下、図１２に示す処理をステップ番号に沿って説明する。なお、図１２では暗号化ブロックデータを、暗号化ＢＬ（BLock）データと略記している（以降の図でも同様に略記することがある）。

（ＳＴ１１）移行元処理部１３０は、ＯＳ管理領域１２２からブロックデータＡ１を読み取り、バッファ１１０に格納する。
（ＳＴ１２）移行元処理部１３０は、共通鍵“ｋｅｙＸ”を用いて、ブロックデータＡ１を暗号化し、暗号化ブロックデータＡ１ｅを生成する。前述のように、共通鍵“ｋｅｙＸ”は、ＯＳ管理外領域１２１に記憶された進捗テーブル１２１ａに登録されている。

（ＳＴ１３）移行元処理部１３０は、暗号化ブロックデータＡ１ｅをサーバ２００に送信する。移行先処理部２３０は、暗号化ブロックデータＡ１ｅを受信し、バッファ２１０に格納する。

（ＳＴ１４）移行先処理部２３０は、暗号化ブロックデータＡ１ｅをＯＳ管理領域２２２のブロック番号“３２０”のブロックに書き込む。
（ＳＴ１５）移行先処理部２３０は、暗号化ブロックデータＡ１ｅを書き込んだブロックのブロック番号“３２０”を、ＯＳ管理外領域２２１に記憶された進捗テーブル２２１ａに登録する。移行先処理部２３０は、暗号化ブロックデータＡ１ｅの受信を完了した旨（完了通知）をサーバ１００に通知する。

（ＳＴ１６）移行元処理部１３０は、サーバ２００から完了通知を受信すると、ブロックデータＡ１に対応するブロック番号“３２０”を進捗テーブル１２１ａに登録する。以降、移行元処理部１３０は、ブロックデータＡ２，・・・の送信を順次行う。

このように、サーバ１００は、ＯＳ管理領域１２２のデータを保持したまま、そのデータを暗号化してサーバ２００に送信する。全ブロックデータの送信が完了した段階において、サーバ１００では、ＯＳ管理領域１２２上のデータがそのまま残ることになる。また、サーバ２００は、暗号化後のデータをＯＳ管理領域２２２に格納した状態となる。

なお、サーバ１００からサーバ２００への暗号化ブロックデータの送信中に、通信障害により暗号化ブロックデータの送信が中断されることがある。その場合、管理部１３１，２３１は、進捗テーブル１２１ａ，２２１ａそれぞれに登録されたブロック番号を比較して、小さい方のブロック番号を起点に、サーバ１００からサーバ２００へのデータ送信を再開する。ここで、ＯＳ管理領域１２２内に移行対象のデータは残っているので、データ送信を最初からやり直してもよい。ただし、最初からやり直すよりも、途中から再開する方がデータ送信を速く完了させることができる。

図１３は、移行元における移行データの変換処理の例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１０のステップＳ２２に相当する。

（Ｓ５１）管理部１３１は、ＯＳ管理領域１２２から１つのブロックデータを読み取る。管理部１３１は、ＯＳ管理領域１２２の先頭ブロックから順番に読み取る。管理部１３１は、読み取ったブロックデータをバッファ１１０に格納する。

（Ｓ５２）管理部１３１は、ＯＳ管理外領域１２１に記憶された復旧用データ群１２１ｃに、読み取ったブロックデータを追加する（ブロックデータの退避）。これにより、当該ブロックデータにリスト番号が対応付けられる。

（Ｓ５３）管理部１３１は、読み取ったブロックデータのブロック番号を、そのリスト番号に対応付けて、ＯＳ管理外領域１２１に記憶された変換テーブル１２１ｂに登録する。

（Ｓ５４）暗号化部１３２は、ステップＳ５１でバッファ１１０に格納されたブロックデータを、ＯＳ管理外領域１２１に記憶された進捗テーブル１２１ａに含まれる鍵（可逆変換キー）“ｋｅｙＸ”を用いて暗号化し、暗号化ブロックデータを生成する。

（Ｓ５５）ハッシュ処理部１３３は、暗号化ブロックデータのハッシュ値を計算し、変換テーブル１２１ｂに記録する。
（Ｓ５６）管理部１３１は、ステップＳ５１で読み取り対象となったＯＳ管理領域１２２上のブロックデータを、ステップＳ５４で生成された暗号化ブロックデータへ置き換える。

（Ｓ５７）管理部１３１は、進捗テーブルを更新する。具体的には、管理部１３１は、ステップＳ５１で読み取ったブロックのブロック番号を、進捗テーブル１２１ａのブロック番号に登録する。例えば、ステップＳ５１で読み取ったブロックのブロック番号が“３２２”であれば、管理部１３１は進捗テーブル１２１ａのブロック番号に“３２２”を登録する。例えば、管理部１３１は、現在登録されているブロック番号に対して１（または１単位分の値）を加算したブロック番号を登録してもよい。

（Ｓ５８）管理部１３１は、サーバ２００へ進捗データを送信する。進捗データは、進捗テーブル１２１ａに登録されたブロック番号を含む。例えば、ステップＳ５７でブロック番号を“３２２”に更新したなら、進捗データに含まれるブロック番号は“３２２”である。管理部１３１は、当該進捗データに対するサーバ２００からの応答（サーバ２００からの進捗データ）の到着を待機する。

（Ｓ５９）管理部１３１は、サーバ２００から進捗データを受信する。例えば、ステップＳ５８で、ブロック番号“３２２”を含む進捗データを送信したなら、サーバ２００から受信する進捗データに含まれるブロック番号も“３２２”である。

（Ｓ６０）管理部１３１は、ＯＳ管理領域１２２に含まれる全ブロックデータの暗号化を終了したか否かを判定する。終了していない場合、処理をステップＳ５１に進める。終了した場合、処理をステップＳ６１に進める。

（Ｓ６１）管理部１３１は、移行完了通知をサーバ２００に送信する。管理部１３１は、移行完了通知を受信した旨の応答をサーバ２００から受信する。
（Ｓ６２）管理部１３１は、ＯＳ管理外領域１２１に格納されたデータ（進捗テーブル１２１ａ，変換テーブル１２１ｂおよび復旧用データ群１２１ｃ）を消去する。

なお、ステップＳ５２は、ステップＳ５４またはステップＳ５５の後に行われてもよい。その場合、少なくともステップＳ５４またはステップＳ５５の後までは、ステップＳ５１で読み取った（暗号化前の）ブロックデータをバッファ１１０に保持しておく。

サーバ２００は、ステップＳ５８で送信された進捗データを受信すると、進捗データに含まれるブロック番号と同じブロック番号の暗号化ブロックデータを復号する。サーバ１００のＯＳ管理領域１２２の暗号化に伴って、サーバ２００のＯＳ管理領域２２２の復号も進行する。

図１４は、移行先における移行データの変換処理の例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
（Ｓ７１）管理部２３１は、サーバ１００から進捗データを受信する。

（Ｓ７２）管理部２３１は、ＯＳ管理領域２２２から１つの暗号化ブロックデータを読み取る。管理部２３１は、ＯＳ管理領域２２２の先頭ブロックから順番に読み取る。管理部２３１は、読み取った暗号化ブロックデータをバッファ２１０に格納する。ここで、ステップＳ７２で読み取られるブロックのブロック番号は、受信した進捗データに含まれるブロック番号と一致する。

（Ｓ７３）管理部２３１は、ＯＳ管理外領域２２１に記憶された復旧用データ群２２１ｃに、読み取った暗号化ブロックデータを追加する（ブロックの退避）。これにより、当該暗号化ブロックデータにリスト番号が対応付けられる。

（Ｓ７４）管理部２３１は、読み取った暗号化ブロックデータのブロック番号を、そのリスト番号に対応付けて、ＯＳ管理外領域２２１に記憶された変換テーブル２２１ｂに登録する。

（Ｓ７５）復号部２３２は、ステップＳ７２でバッファ２１０に格納された暗号化ブロックデータを、ＯＳ管理外領域２２１に記憶された進捗テーブル２２１ａに含まれる鍵（可逆変換キー）“ｋｅｙＸ”を用いて復号し、ブロックデータを生成する。前述のように、暗号化ブロックデータのサイズと、復号後のブロックデータのサイズとは同一である。

（Ｓ７６）ハッシュ処理部２３３は、復号後のブロックデータのハッシュ値を計算し、変換テーブル２２１ｂに記録する。
（Ｓ７７）管理部２３１は、ステップＳ７２で読み取り対象となったＯＳ管理領域２２２上の暗号化ブロックデータを、ステップＳ７５で生成された復号後のブロックデータへ置き換える。

（Ｓ７８）管理部２３１は、進捗テーブルを更新する。具体的には、管理部２３１は、ステップＳ７２で読み取ったブロックのブロック番号を、進捗テーブル２２１ａのブロック番号に登録する。例えば、ステップＳ７２で読み取ったブロックのブロック番号が“３２２”であれば、管理部２３１は進捗テーブル２２１ａのブロック番号に“３２２”を登録する。例えば、管理部２３１は、現在登録されているブロック番号に対して１（または１単位分の値）を加算したブロック番号を登録してもよい。

（Ｓ７９）管理部２３１は、サーバ１００へ進捗データを送信する。進捗データは、進捗テーブル２２１ａに登録されたブロック番号を含む。例えば、ステップＳ７８でブロック番号を“３２２”に更新したなら、進捗データに含まれるブロック番号は“３２２”である。

（Ｓ８０）管理部２３１は、サーバ１００から移行完了通知を受信したか否かを判定する。移行完了通知を受信していない場合、処理を終了する（管理部２３１は、サーバ１００から次の進捗データを受信するまで待機する）。移行完了通知を受信した場合、管理部２３１は移行完了通知を受信した旨をサーバ１００に応答して、処理をステップＳ８１に進める。

（Ｓ８１）管理部２３１は、ＯＳ管理外領域２２１に格納されたデータ（進捗テーブル２２１ａ，変換テーブル２２１ｂおよび復旧用データ群２２１ｃ）を消去する。
その後、サーバ２００は、ステップＳ８０で移行完了通知を受信していなければ、サーバ１００からの次の進捗データの受信を待機する（ステップＳ７１の進捗データの受信を待機）。そして、サーバ２００は、サーバ１００から移行完了通知を受信するまで、上記ステップＳ７１〜Ｓ８０を繰り返し実行し、暗号化ブロックデータを順次復号する。

なお、ステップＳ７３は、ステップＳ７５またはステップＳ７６の後に行われてもよい。その場合、少なくともステップＳ７５またはステップＳ７６の後までは、ステップＳ７２で読み取った暗号化ブロックデータをバッファ２１０に保持しておく。

図１５は、移行元におけるブロックデータの暗号化の例を示す図である。以下、図１５に示す処理をステップ番号に沿って説明する。なお、ブロックデータＡ２を暗号化する（ブロックデータＡ１を暗号化ブロックデータＡ１ｅに置換済である）場合を想定する。

（ＳＴ２１）移行元処理部１３０は、ＯＳ管理領域１２２からブロックデータＡ２を読み取り、バッファ１１０に格納する。
（ＳＴ２２）移行元処理部１３０は、ＯＳ管理外領域１２１にブロックデータＡ２を書き込む（ブロックデータＡ２の退避）。

（ＳＴ２３）移行元処理部１３０は、共通鍵“ｋｅｙＸ”を用いて、ブロックデータＡ２を暗号化し、暗号化ブロックデータＡ２ｅを生成する。前述のように、共通鍵“ｋｅｙＸ”は、ＯＳ管理外領域１２１に記憶された進捗テーブル１２１ａに登録されている。

（ＳＴ２４）移行元処理部１３０は、暗号化ブロックデータＡ２ｅのハッシュ値を算出し、ＯＳ管理外領域１２１に記憶された変換テーブル１２１ｂに登録する。
（ＳＴ２５）移行元処理部１３０は、ＯＳ管理領域１２２に格納されたブロックデータＡ２を暗号化ブロックデータＡ２ｅへ置き換える。

（ＳＴ２６）移行元処理部１３０は、進捗テーブル１２１ａを更新する。そして、移行元処理部１３０は、サーバ２００へ進捗データを送信する。すると、サーバ２００はＯＳ管理領域２２２に格納された暗号化ブロックデータＡ２ｅを復号する。

ここで、前述のように、ブロックデータを退避させておく記憶領域（復旧用データ群１２１ｃを格納する領域）は、循環して再利用される。例えば、ブロックデータＡ２が当該記憶領域に書き込まれ、サーバ２００でのブロックデータＡ２ｅの復号が完了した後、サーバ１００における以降のブロックデータの暗号化が進行すると、復旧用データ群１２１ｃからブロックデータＡ２が削除されることになる。他のブロックデータによって上書きされるからである。よって、復旧用データ群１２１ｃに、ＯＳ管理領域１２２に格納された全てのブロックデータが格納されることはない。

図１６は、移行先における暗号化ブロックデータの復号の例を示す図である。以下、図１６に示す処理をステップ番号に沿って説明する。なお、暗号化ブロックデータＡ２ｅを復号する（暗号化ブロックデータＡ１ｅをブロックデータＡ１に置換済である）場合を想定する。

（ＳＴ３１）移行先処理部２３０は、ＯＳ管理領域２２２から暗号化ブロックデータＡ２ｅを読み取り、バッファ２１０に格納する。
（ＳＴ３２）移行先処理部２３０は、ＯＳ管理外領域２２１に暗号化ブロックデータＡ２ｅを書き込む（暗号化ブロックデータＡ２ｅの退避）。

（ＳＴ３３）移行先処理部２３０は、共通鍵“ｋｅｙＸ”を用いて、暗号化ブロックデータＡ２ｅを復号し、ブロックデータＡ２を生成する。前述のように、共通鍵“ｋｅｙＸ”は、ＯＳ管理外領域２２１に記憶された進捗テーブル２２１ａに登録されている。

（ＳＴ３４）移行先処理部２３０は、ブロックデータＡ２のハッシュ値を算出し、ＯＳ管理外領域２２１に記憶された変換テーブル２２１ｂに登録する。
（ＳＴ３５）移行先処理部２３０は、ＯＳ管理領域２２２に格納された暗号化ブロックデータＡ２ｅをブロックデータＡ２へ置き換える。

（ＳＴ３６）移行先処理部２３０は、進捗テーブル２２１ａを更新する。そして、移行先処理部２３０は、サーバ１００へ進捗データを送信する。すると、サーバ１００はＯＳ管理領域１２２に格納されたブロックデータＡ３を暗号化する。以降、サーバ２００における暗号化ブロックデータＡ３ｅの復号、サーバ１００における次のブロックデータの暗号化、・・・と、順番に変換が行われる。

このようにして、サーバ１００からサーバ２００へのＯＳやアプリケーションの移行が行われる。
図１７は、移行の流れの例を示す図である。データＤ１０は、移行対象のデータである。データＤ１０は、ＯＳ管理領域１２２に含まれる複数のブロックデータの集合であるともいえる。データＤ１０は、サーバ１００にインストールされたＯＳを動作させるためのデータを含む。また、サーバ１００にアプリケーションがインストールされていれば、そのアプリケーションを動作させるためのデータを含む。

データＤ１０は、移行を行う直前では、ＯＳ管理領域１２２に格納されており、ＯＳ管理領域２２２には格納されていない（ステップＳＴ１０１）。サーバ１００は、データＤ１０を保持しながら、データＤ１０をブロックデータ単位に暗号化して、サーバ２００に順次送信する（ステップＳＴ１０２）。全ブロックデータの送信が完了した段階において、サーバ１００では、ＯＳ管理領域１２２上のデータがそのまま残ることになる。また、サーバ２００は、データＤ１０の暗号化後のデータ（暗号化データＤ２０）をＯＳ管理領域２２２に格納した状態となる（ステップＳＴ１０３）。

図１８は、移行の流れの例（続き）を示す図である。変換の直前では、サーバ１００は、ＯＳ管理領域１２２にデータＤ１０を格納している。サーバ２００は、暗号化データＤ２０をＯＳ管理領域２２２に格納している（ステップＳＴ１１１）。

サーバ１００は、ＯＳ管理領域１２２に格納されたデータＤ１０の暗号化を開始する。また、サーバ２００は、ＯＳ管理領域２２２に格納された暗号化データＤ２０の復号を開始する。サーバ１００での暗号化の開始後から完了前のあるタイミングに着目すると、サーバ１００のＯＳ管理領域１２２には、暗号化中であるデータＤ１０ａが格納されている。データＤ１０ａは、暗号化済の部分Ｄ１１ａと未暗号化の部分Ｄ１２ａとを含む。他方、当該タイミングにおいて、サーバ２００のＯＳ管理領域２２２には、復号中であるデータＤ２０ａが格納されている。データＤ２０ａは、復号済の部分Ｄ２１ａと未復号の部分Ｄ２２ａとを含む（ステップＳＴ１１２）。

サーバ２００が復号を完了する前に、サーバ１００は暗号化を完了する。サーバ１００が暗号化を完了したタイミングに着目すると、サーバ１００のＯＳ管理領域１２２には、データＤ１０を暗号化した暗号化データＤ１０ｂが格納されている。本例では、暗号化に用いた鍵や手順が同じなので、暗号化データＤ１０ｂ，Ｄ２０は同一である。他方、当該タイミングにおいて、サーバ２００のＯＳ管理領域２２２には、復号中であるデータＤ２０ｂが格納されている。データＤ２０ｂは、復号済の部分Ｄ２１ｂと未復号の部分Ｄ２２ｂとを含む（ステップＳＴ１１３）。部分Ｄ２１ｂのサイズは、部分Ｄ２１ａよりも大きい。部分Ｄ２２ｂのサイズは、部分Ｄ２２ａよりも小さい。ステップＳＴ１１２に比べて復号が進んでいるからである。前述の手順に従えば、部分Ｄ２２ｂは最後の１ブロックデータに相当する。

サーバ１００が暗号化を完了した後に、サーバ２００は復号を完了する。サーバ２００が復号を完了したタイミングに着目すると、サーバ１００のＯＳ管理領域１２２には、暗号化データＤ１０ｂが格納されている。他方、当該タイミングにおいて、サーバ２００のＯＳ管理領域２２２には、暗号化データＤ２０を復号して得られたデータＤ１０が格納されている（ステップＳＴ１１４）。

ここで、移行対象のＯＳやアプリケーションがサーバ１００，２００で並列に動作してしまうと、システム障害の要因になり得る。例えば、ＯＳで設定されたＩＰ（Internet Protocol）アドレスなどの識別情報がネットワーク１０上で重複して存在すると、その識別情報を指定した通信を正常に行えないおそれがある。また、例えば、データベースやファイルサーバなどのデータ管理用のアプリケーションが移行対象であれば、サーバ１００，２００の両方により管理対象のデータベースなどが個別に操作されると、データ不整合を生じるおそれがある。また、他のアプリケーションについてもそのアプリケーションにおけるデータ不整合や他のサーバとの連携における不具合などが生じ得る。

そこで、第２の実施の形態の方法では、移行対象のソフトウェアのデータを暗号化することで、サーバ１００，２００の両方で当該ソフトウェアが並列に動作することを抑制する。

具体的には、暗号化データＤ１０ｂ，Ｄ２０はデータＤ１０とは異なる情報である。このため、サーバ１００でデータＤ１０を、サーバ２００で暗号化データＤ２０を、それぞれ同時に保持したとしても、移行対象のＯＳやアプリケーションがサーバ２００で動作することはない。また、サーバ２００で暗号化データＤ２０のデコードが完了するとき、サーバ１００では暗号化データＤ１０ｂが保持されていることになる。サーバ２００でデータＤ１０を、サーバ１００で暗号化データＤ１０ｂを、それぞれ同時に保持したとしても、移行対象のＯＳやアプリケーションがサーバ１００で動作することはない。これにより、移行対象のソフトウェアがサーバ１００，２００で並列に動作することを抑制できる。

例えば、データＤ１０に状態情報を設定可能とし、サーバ１００でデータＤ１０の状態情報を使用不可状態に設定してからサーバ２００へデータＤ１０のコピーを送信することも考えられる。しかし、この場合、データＤ１０自体はサーバ１００，２００の両方に存在することになる。このため、状態情報が無視されたり（例えば、状態情報のチェックを行う機能が適切に動作しないなど）、状態情報の設定が不測の処理により改変されたりするだけで、移行対象のＯＳやアプリケーションがサーバ１００，２００で並列に動作し得る。また、移行時のオペレーションにおける人為的なミスによって、移行対象のソフトウェアがサーバ１００，２００で並列に動作してしまうおそれもある。データＤ１０自体がサーバ１００，２００の両方に存在する限り、これらのリスクは残る。

一方、第２の実施の形態によれば、サーバ１００，２００によりデータＤ１０を同時に保持させないので、上記のような不測の事態においても、移行対象のＯＳやアプリケーションがサーバ１００，２００で並列に動作することを抑制できる。よって、ＯＳやアプリケーションの移行を安全に行える。

また、データＤ１０のうち送信済の部分をサーバ１００から削除しながら、サーバ２００にデータＤ１０を送信することも考えられる。しかし、この場合、送信中に通信障害が発生すると、サーバ１００，２００の何れにも元のデータＤ１０が存在しないことになる。このため、移行途中であったＯＳやアプリケーションの復旧が困難になり得る。

これに対し、サーバ１００は、データＤ１０を保持しながら暗号化データＤ２０をサーバ２００に送信する。このため、仮に暗号化データＤ２０の送信中に通信障害が発生しても、サーバ１００上にデータＤ１０が残るので、サーバ１００上でＯＳやアプリケーションを動作させたり、データＤ１０の送信を再度行ったりすることができる。よって、第２の実施の形態の方法は、データＤ１０を削除しながら送信する方法よりも安全である。

また、例えば、サーバ２００での復号が完了する前に、サーバ２００のＨＤＤなどの故障でデータ記憶部２２０にアクセスできなくなることもある。その場合、ＯＳ管理領域１２２の暗号化データＤ１０ｂ（あるいは、部分Ｄ１１ａ）を復号することで、元のデータＤ１０を復旧することができる。すなわち、サーバ２００での復号中に、サーバ１００で暗号化したデータを保持することで、障害に対する信頼性を向上させることができる。

特に、サーバ１００でのデータＤ１０の暗号化と、サーバ２００での暗号化データＤ２０の復号とを並行して行うことで、ソフトウェアの移行を高速化できる。例えば、ＯＳ管理領域１２２，２２２（すなわち、ＨＤＤ）に対するデータの書き込みには所定時間を要する。この点、例えば、図１３のステップＳ５６において、管理部１３１はＨＤＤ１０３に対して書き込み指示を行った後にステップＳ５７に移行できる。同様に、図１４のステップＳ７７において、管理部２３１はサーバ２００のＨＤＤに対して書き込み指示を行った後にステップＳ７８に移行できる。よって、ＨＤＤに対する書き込み完了を待たずにサーバ１００，２００で暗号化／復号を並行して進めることができ、ソフトウェアの移行を高速化できる。

更に、第２の実施の形態では、サーバ１００，２００上に同時にソフトウェアの複製を存在させない。ＯＳ管理領域２２２の暗号化ブロックデータが復号されるのは、ＯＳ管理領域１２２で当該暗号化ブロックデータに対応するブロックデータが暗号化された後だからである。このため、ライセンスにより複製が制限されているソフトウェアを移行する場合に、ライセンス違反となるリスクを低減できるという利点もある。

また、第２の実施の形態の方法では、サーバ１００，２００を用いてソフトウェアの移行を行える。このため、移行の進捗を管理するコンピュータを別個に用意しなくてもよいという利点もある。

ところで、サーバ１００での暗号化およびサーバ２００での復号が行われている間に、サーバ１００，２００で電源断やサーバの動作エラーなどの障害が発生することがある。このような障害に伴い、ＯＳ管理領域１２２，２２２に不正なブロックデータ（エラーデータということがある）が書き込まれるおそれがある。この場合、移行元処理部１３０や移行先処理部２３０は、ＯＳ管理外領域に格納された情報に基づいて、ＯＳ管理領域内のエラーデータを検索し、復旧させることができる。

図１９は、移行元における復旧処理の例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。ステップＳ９１の直前において、サーバ１００で電源断などの障害が発生し、移行元処理部１３０が再起動されたとする。

（Ｓ９１）管理部１３１は、ＯＳ管理外領域１２１に記憶された変換テーブル１２１ｂを読み取る。管理部１３１は、進捗テーブル１２１ａや変換テーブル１２１ｂに登録された情報から、変換処理が中断されていることを検出する。

（Ｓ９２）管理部１３１は、変換テーブル１２１ｂに登録された全レコードについてハッシュ値のチェックを行ったか否かを判定する。全レコードのハッシュ値をチェック済である場合、処理をステップＳ１０４に進める。未チェックのレコードがある場合、処理をステップＳ９３に進める。

（Ｓ９３）管理部１３１は、変換テーブル１２１ｂに登録されたレコードを１つ抽出する。例えば、（最小のリスト番号から）リスト番号の昇順にレコードを抽出する。あるいは、（変換テーブル１２１ｂに登録された最小のブロック番号から）ブロック番号の昇順にレコードを抽出してもよい。

（Ｓ９４）管理部１３１は、ステップＳ９３で抽出したレコード（着目するレコード）にハッシュ値の登録があるか否かを判定する。ハッシュ値の登録がある場合、処理をステップＳ９５に進める。ハッシュ値の登録がない場合、処理をステップＳ１０４に進める。

（Ｓ９５）管理部１３１は、着目するレコードに登録されたブロック番号を取得する。管理部１３１は、ＯＳ管理領域１２２の当該ブロック番号で示されるブロック位置を読み取る（当該ブロック番号に対応する暗号化ブロックデータの読み取り）。

（Ｓ９６）ハッシュ処理部１３３は、その暗号化ブロックデータのハッシュ値を計算する。
（Ｓ９７）ハッシュ処理部１３３は、計算されたハッシュ値が、着目するレコードに登録されたハッシュ値と一致しているか否かを判定する。一致している場合、処理をステップＳ９２に進める。一致していない場合、処理をステップＳ９８に進める。ハッシュ値が一致していない場合、ハッシュ処理部１３３は、その暗号化ブロックデータをエラーデータと特定できる。

（Ｓ９８）管理部１３１は、着目するレコードに登録されたリスト番号を取得する。管理部１３１は、ＯＳ管理外領域１２１に記憶された復旧用データ群１２１ｃから、そのリスト番号に対応する復旧用データを読み取る。当該復旧用データは、ステップＳ９５で取得したブロック番号に対応する暗号化前のブロックデータである。

（Ｓ９９）暗号化部１３２は、復旧用データ（暗号化前のブロックデータ）を暗号化し、暗号化ブロックデータを生成する。
（Ｓ１００）ハッシュ処理部１３３は、生成された暗号化ブロックデータのハッシュ値を計算し、変換テーブル１２１ｂの着目するレコードに登録する。

（Ｓ１０１）管理部１３１は、ＯＳ管理領域１２２のエラーデータを、新たに生成された暗号化ブロックデータへ置き換える。
（Ｓ１０２）管理部１３１は、進捗テーブルを更新する。具体的には、管理部１３１は、ステップＳ９５で取得したブロック番号を、進捗テーブル１２１ａのブロック番号に登録する。

（Ｓ１０３）管理部１３１は、サーバ２００へ進捗データを送信する。進捗データは、ステップＳ１０２で進捗テーブル１２１ａに登録されたブロック番号を含む。サーバ２００は、進捗データを受信すると、進捗データに含まれるブロック番号に対応する暗号化ブロックデータの復号を行う。

（Ｓ１０４）管理部１３１は、図１３で説明した手順による通常の変換処理を再開する。例えば、ステップＳ９２で全レコードをチェック済、または、ステップＳ９４で抽出したレコードにハッシュ値なしと判定されていれば、変換テーブル１２１ｂに登録された最大のブロック番号のブロックデータから通常の変換処理を再開すればよい。また、ステップＳ１０３で進捗データを送信したなら、それに対する応答（進捗データ）をサーバ２００から受信して、次のブロックから通常の変換処理を再開する。

このようにして、管理部１３１は、電源断などの障害が起こっても、ＯＳ管理外領域１２１に格納されたハッシュ値を用いて、ＯＳ管理領域１２２の置き換えに失敗したエラー部分（エラーデータ）を検索できる。また、ＯＳ管理外領域１２１に格納された復旧用データを用いて、エラーデータを適切な暗号化ブロックデータに復旧できる。

上記の復旧方法によれば、サーバ１００で復旧処理を行っている間、サーバ１００からサーバ２００への進捗データの送信は中断される。このため、サーバ２００での逆変換（復号）の処理も中断されることになる。よって、サーバ１００での暗号化が完了する前に、サーバ２００での復号が完了することを抑制できる。

ここで、ステップＳ９４でハッシュ値の登録がない場合に処理をステップＳ１０４に進めてよい理由は、着目するレコードにハッシュ値が登録されていなければ、そのレコードに対応するブロックは未変換（未暗号化）であると判断できるからである。すなわち、そのブロックから通常の変換（暗号化）処理を再開すればよいと判断できる。

図２０は、移行先における復旧処理の例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。ステップＳ１１１の直前において、サーバ２００で電源断などのエラーが発生し、移行先処理部２３０が再起動されたとする。

（Ｓ１１１）管理部２３１は、ＯＳ管理外領域２２１に記憶された変換テーブル２２１ｂを読み取る。管理部２３１は、進捗テーブル２２１ａや変換テーブル２２１ｂに登録された情報から、変換処理が中断されていることを検出する。

（Ｓ１１２）管理部２３１は、変換テーブル２２１ｂに登録された全レコードについてハッシュ値のチェックを行ったか否かを判定する。全レコードのハッシュ値をチェック済である場合、処理をステップＳ１２４に進める。未チェックのレコードがある場合、処理をステップＳ１１３に進める。

（Ｓ１１３）管理部２３１は、変換テーブル２２１ｂに登録されたレコードを１つ抽出する。例えば、（最小のリスト番号から）リスト番号の昇順にレコードを抽出する。あるいは、（変換テーブル２２１ｂに登録された最小のブロック番号から）ブロック番号の昇順にレコードを抽出してもよい。

（Ｓ１１４）管理部２３１は、ステップＳ１１３で抽出したレコード（着目するレコード）にハッシュ値の登録があるか否かを判定する。ハッシュ値の登録がある場合、処理をステップＳ１１５に進める。ハッシュ値の登録がない場合、処理をステップＳ１２４に進める。

（Ｓ１１５）管理部２３１は、着目するレコードに登録されたブロック番号を取得する。管理部２３１は、ＯＳ管理領域２２２の当該ブロック番号で示されるブロック位置を読み取る（当該ブロック番号に対応するブロックデータの読み取り）。

（Ｓ１１６）ハッシュ処理部２３３は、そのブロックデータのハッシュ値を計算する。
（Ｓ１１７）ハッシュ処理部２３３は、計算されたハッシュ値が、着目するレコードに登録されたハッシュ値と一致しているか否かを判定する。一致している場合、処理をステップＳ１１２に進める。一致していない場合、処理をステップＳ１１８に進める。ハッシュ値が一致していない場合、ハッシュ処理部２３３は、そのブロックデータをエラーデータと特定できる。

（Ｓ１１８）管理部２３１は、着目するレコードに登録されたリスト番号を取得する。管理部２３１は、ＯＳ管理外領域２２１に記憶された復旧用データ群２２１ｃから、そのリスト番号に対応する復旧用データを読み取る。当該復旧用データは、ステップＳ１１５で取得したブロック番号に対応する復号前の暗号化ブロックデータである。

（Ｓ１１９）復号部２３２は、復旧用データ（暗号化ブロックデータ）を復号し、復号後のブロックデータを生成する。
（Ｓ１２０）ハッシュ処理部２３３は、生成されたブロックデータのハッシュ値を計算し、変換テーブル２２１ｂの着目するレコードに登録する。

（Ｓ１２１）管理部２３１は、ＯＳ管理領域２２２のエラーデータを、新たに生成されたブロックデータへ置き換える。
（Ｓ１２２）管理部２３１は、進捗テーブルを更新する。具体的には、管理部２３１は、ステップＳ１１５で取得したブロック番号を、進捗テーブル２２１ａのブロック番号に登録する。

（Ｓ１２３）管理部２３１は、サーバ２００へ進捗データを送信する。進捗データは、ステップＳ１２２で進捗テーブル２２１ａに登録されたブロック番号を含む。サーバ２００は、進捗データを受信すると、進捗データに含まれるブロック番号の次のブロック番号に対応するブロックデータの暗号化を行う。

（Ｓ１２４）管理部２３１は、管理部２３１は、図１４で説明した手順による通常の逆変換処理を再開する。例えば、ステップＳ１１２で全レコードをチェック済、または、ステップＳ１１４で抽出したレコードにハッシュ値なしと判定されていれば、変換テーブル２２１ｂに登録された最大のブロック番号の暗号化ブロックデータから通常の逆変換処理を再開すればよい。また、ステップＳ１２３で進捗データを送信したなら、次の進捗データをサーバ１００から受信して、次のブロックから通常の逆変換処理を再開する。

このようにして、管理部２３１は、電源断などの障害が起こっても、ＯＳ管理外領域２２１に格納されたハッシュ値を用いて、ＯＳ管理領域２２２のデコード後のブロックデータの書き込みに失敗したエラー部分（エラーデータ）を検索できる。また、ＯＳ管理外領域２２１に格納された復旧用データを用いて、エラーデータを適切なブロックデータに復旧できる。

ここで、ステップＳ１１４でハッシュ値の登録がない場合に処理をステップＳ１２４に進めてよい理由は、着目するレコードにハッシュ値が登録されていなければ、そのレコードに対応するブロックは未変換（未復号）であると判断できるからである。すなわち、そのブロックから通常の逆変換（復号）処理を再開すればよいと判断できる。

なお、管理部１３１，２３１は、復旧処理を行う直前に、相手側のサーバに対して進捗データが送られてくるのを待機するよう通知しておいてもよい。そうすれば、相手側のサーバでの変換を中断し、当該サーバを待機モードとすることができる。相手側のサーバは、復旧処理を完了したサーバから進捗データを受信したときは、進捗データに含まれるブロック番号を起点に通常の変換（または、逆変換）処理を継続する。

図２１は、移行元における復旧処理の例を示す図である。以下、図２１に示す処理をステップ番号に沿って説明する。なお、サーバ１００において、エラーデータＡ２ｘを復旧する場合を想定する。

（ＳＴ４１）移行元処理部１３０は、ＯＳ管理領域から１２２からエラーデータＡ２ｘを読み取り、バッファ１１０に格納する。
（ＳＴ４２）移行元処理部１３０は、エラーデータＡ２ｘのハッシュ値Ｈｘを算出する。

（ＳＴ４３）移行元処理部１３０は、エラーデータＡ２ｘのブロック番号に対応するハッシュ値をＯＳ管理外領域１２１に記憶された変換テーブル１２１ｂから取得する。移行元処理部１３０は、ハッシュ値Ｈｘと変換テーブル１２１ｂに登録されたハッシュ値とを比較する。ここで、両ハッシュ値は一致していないものとする。このため、移行元処理部１３０は、エラーデータＡ２ｘを書き込みに失敗した部分であると特定する。

図２２は、移行元における復旧処理の例（続き）を示す図である。以下、図２２に示す処理をステップ番号に沿って説明する。以下に示す処理は、図２１のステップＳＴ４３に後続する処理である。

（ＳＴ４４）移行元処理部１３０は、エラーデータＡ２ｘのブロック番号を基に、ＯＳ管理外領域１２１に記憶された変換テーブル１２１ｂからリスト番号を取得する。移行元処理部１３０は、ＯＳ管理外領域１２１に記憶された復旧用データ群１２１ｃからそのリスト番号に対応する復旧用データを読み取る。当該復旧用データは、エラーデータＡ２ｘのブロック番号に対応する元のブロックデータＡ２である。

（ＳＴ４５）移行元処理部１３０は、共通鍵“ｋｅｙＸ”を用いて、ブロックデータＡ２を暗号化し、暗号化ブロックデータＡ２ｅを生成する。前述のように、共通鍵“ｋｅｙＸ”はＯＳ管理外領域１２１に記憶された進捗テーブル１２１ａに登録されている。

（ＳＴ４６）移行元処理部１３０は、暗号化ブロックデータＡ２ｅのハッシュ値を算出し、ＯＳ管理外領域１２１に記憶された変換テーブル１２１ｂに登録する。
（ＳＴ４７）移行元処理部１３０は、ＯＳ管理領域１２２に格納されたエラーデータＡ２ｘを暗号化ブロックデータＡ２ｅへ置き換える。そして、移行元処理部１３０は、サーバ２００へ進捗データを送信する。すると、サーバ２００はＯＳ管理領域２２２に格納された暗号化ブロックデータＡ２ｅを復号する。

このようにして、サーバ１００は、ＯＳ管理外領域１２１に格納された復旧用データ（ブロックデータＡ２）を用いて、ＯＳ管理領域１２２のエラーデータＡ２ｘを適正な暗号化ブロックデータＡ２ｅに置き換え、変換を再開できる。図２０で説明したように、サーバ２００も同様にしてエラーデータの復旧を行える。これにより、障害に対する信頼性を向上できる。

特に、サーバ１００，２００は、復旧管理用のデータ（変換テーブルおよび復旧用データ群）を不揮発性のＯＳ管理外領域１２１，２２１に保持する。したがって、電源断などの障害が発生したとしても、復旧管理用のデータを保持することができる。しかも、ＯＳ管理外領域１２１は、サーバ１００にインストールされたＯＳやアプリケーションの動作時にはアクセスされない領域である。よって、復旧管理用のデータ（未エンコードのもの）をＯＳ管理外領域１２１に格納しておいても、これらのソフトウェアがサーバ１００で動作することはない。

このようにして、サーバ１００からサーバ２００へのＯＳやアプリケーションの移行をより安全に行える。なお、サーバ１００，２００で同時に障害が発生することもある。その場合、移行元処理部１３０および移行先処理部２３０は、次の起動時に相互に通信して、進捗テーブルのブロック番号を通知し合うことが考えられる。その場合、小さい方のブロック番号を起点にして両サーバで変換処理を再開することが考えられる。

図２３は、記憶領域の他の例を示す図である。サーバ１００にインストールされたＯＳやアプリケーションを、次のようにサーバ２００に移行してもよい。例えば、データ記憶部１２０のＯＳ管理領域１２２を基本領域１２２ａおよび拡張領域１２２ｂの２つに区分できることがある。基本領域１２２ａは、ＯＳ起動用のデータを格納する領域である。例えば、基本領域１２２ａはプライマリパーティションと呼ばれることもある。

拡張領域１２２ｂは、基本領域１２２ａにインストールされたＯＳにより利用可能であるが、当該ＯＳの起動には用いられない領域である。例えば、拡張領域１２２ｂは拡張パーティションと呼ばれることもある。拡張領域１２２ｂには、ＯＳにより認識可能な論理領域を作成して、種々のアプリケーションをインストールできる。

この場合、最初に、第２の実施の形態の方法を用いて基本領域１２２ａをデータ記憶部２２０に移行させ（第１の移行）、次に、同方法を用いて拡張領域１２２ｂをデータ記憶部２２０に移行させてもよい（第２の移行）。

第１の移行では、データ記憶部２２０に、基本領域１２２ａに対応する基本領域２２２ａが作成される。すなわち、第１の移行では、基本領域１２２ａにインストールされたＯＳ（アプリケーションもインストールされていればそのアプリケーション）が移行される。第２の移行では、拡張領域１２２ｂに対応する拡張領域２２２ｂが作成される。すなわち、第２の移行では、拡張領域１２２ｂにインストールされたアプリケーションが移行される。

このように、データ記憶部１２０の記憶領域を複数の区分に分けて、区分単位に移行を行ってもよい。第１の移行では、移行対象のＯＳやアプリケーションがサーバ１００，２００で並列に動作することやライセンス違反を抑制できる。第２の移行では、移行対象のアプリケーションがサーバ１００，２００で並列に動作することやライセンス違反を抑制できる。

更に、サーバ１００でブロックデータを暗号化後のデータに置き換えている場合でも、当該ＯＳの動作用のデータが未暗号化であると、当該ＯＳが動作してしまうおそれがある（例えば、拡張領域１２２ｂを先に移行する場合）。また、サーバ２００で暗号化ブロックデータを復号後のデータに置き換えている場合でも、当該ＯＳの動作用のデータが復号済になれば、サーバ２００上で当該ＯＳが動作するおそれがある（例えば、基本領域１２２ａを先に移行する場合）。そこで、移行対象のＯＳからは使用できないＯＳ管理外領域１２１，２２１に復旧管理用のデータを格納しておくことで、サーバ１００，２００の何れか一方で当該ＯＳが動作してしまったとしても、復旧管理用のデータを保護できる。

ここで、第２の実施の形態では、所定の鍵を用いてブロックデータを暗号化する場合を例示したが、他のエンコード方法を用いてもよい。例えば、ビット反転（１ビットの情報である“０”と“１”とを逆転させる）でもよい。このとき、エンコード前後でブロックデータのサイズが同じになるエンコード方法が好ましい。ＯＳ管理領域２２２として、ＯＳ管理領域１２２と同じサイズを確保できれば移行を行えるからである。

ただし、エンコード前後でブロックデータのサイズが異なるエンコード方法を利用してもよい。例えば、サーバ１００は、エンコードとしてブロックデータの圧縮を行ってもよい。サーバ２００に送信するデータ量を低減し得るからである。その場合、サーバ２００は、圧縮後ブロックデータにダミーデータを付加して、そのサイズを所定サイズ（例えば、５１２Ｂ）に調整した上で、ＯＳ管理領域２２２に書き込む。サーバ２００は、復号時にはダミーデータを除去してから圧縮後ブロックデータの復号を行う。

また、サーバ１００における図１３のエンコード方法は、図１１のエンコード方法と異なる方法でもよい。例えば、図１１のエンコードは可逆変換としたが、図１３のエンコードは不可逆変換（または、無意味なデータの書き込み）でもよい。ただし、前述のように障害に対する信頼性の観点からは可逆変換が好ましい。仮に、サーバ２００でのデコード中にデータ記憶部２２０が故障しても、データ記憶部１２０内のエンコード後データをデコードすることでソフトウェアを復元できるからである。

以上のようにして、サーバ２００でのデコードが完了すれば、サーバ１００からサーバ２００へのソフトウェアの移行が完了する。その後は、ＯＳ管理領域１２２に格納されたエンコード後データを削除する、サーバ１００をネットワーク１０から切断するなどして、サーバ１００を撤去できる。

なお、第１の実施の形態の情報処理は、情報処理装置１，２として用いられるコンピュータにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、サーバ１００，２００にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク１３、外部記憶装置１４およびメモリカード１６など）に記録できる。記録媒体としては、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、ＦＤ（ＦＤ：Flexible Disk）およびＨＤＤが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ／ＲＷ、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷが含まれる。プログラムは、可搬型の記録媒体に記録されて配布されることがある。その場合、サーバ１００，２００は、可搬型の記録媒体からＲＡＭにプログラムを複製して実行してもよい。

以上の第１，第２の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へ前記ソフトウェアを移行させるシステム移行プログラムであって、
前記第１の装置として用いられるコンピュータに、
前記第１のデータを保持しながら、前記第１のデータをエンコードした第２のデータを前記第２の装置に送信し、
前記第２の装置による前記第２のデータのデコードが開始される前に前記第１の装置により保持される前記第１のデータのエンコードを開始し、前記第２の装置による前記デコードが完了される前に 、前記第１のデータをエンコード後のデータに置き換える、
処理を実行させるシステム移行プログラム。

（付記２）
前記第１のデータは、不揮発性の記憶装置の第１の記憶領域に格納されており、
前記置き換えでは、前記第１のデータの複数の部分を部分毎にエンコードし、前記記憶装置のうち前記ソフトウェアの動作時にはアクセスされない第２の記憶領域にエンコード前の部分を格納する、付記１記載のシステム移行プログラム。

（付記３）
前記置き換えでは、エンコード前の部分に対応付けてエンコード後の当該部分のハッシュ値を前記第２の記憶領域に格納し、障害が発生すると、前記第２の記憶領域に格納されたハッシュ値に基づいて、前記第１の記憶領域のエラー部分を検索する、付記２記載のシステム移行プログラム。

（付記４）
前記第２の記憶領域に格納されたエンコード前の部分を用いて、前記エラー部分から前記置き換えを再開する、付記３記載のシステム移行プログラム。

（付記５）
前記ソフトウェアは、オペレーティングシステムを含み、
前記第２の記憶領域は、前記オペレーティングシステムからは使用できない記憶領域である、付記２乃至４の何れか１項に記載のシステム移行プログラム。

（付記６）
前記第２のデータの複数の部分のうち、前記第２の記憶領域に格納したエンコード前の部分に対応する部分が前記第２の装置でデコードされた後に、前記第２の記憶領域から当該エンコード前の部分を削除する、付記２乃至５の何れか１項に記載のシステム移行プログラム。

（付記７）
ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へ前記ソフトウェアを移行させるシステム移行プログラムであって、
前記第２の装置として用いられるコンピュータに、
前記第１のデータをエンコードした第２のデータを前記第１の装置から受信し、
前記第１の装置に格納されている前記第１のデータの前記第１の装置によるエンコードが開始された後に、受信した前記第２のデータのデコードを開始し、前記第１の装置による前記第１のデータのエンコード後のデータへの置き換えが完了された後に、前記デコードを完了する、
処理を実行させるシステム移行プログラム。

（付記８）
受信した前記第２のデータを不揮発性の記憶装置の第１の記憶領域に格納し、
前記デコードでは、前記第２のデータの複数の部分を部分毎にデコードして置き換えてゆき、前記記憶装置の第２の記憶領域にデコード前の部分を格納する、付記７記載のシステム移行プログラム。

（付記９）
前記デコードでは、デコード前の部分に対応付けてデコード後の当該部分のハッシュ値を前記第２の記憶領域に格納し、障害が発生すると、前記第２の記憶領域に格納されたハッシュ値に基づいて、前記第１の記憶領域のエラー部分を検索する、付記８記載のシステム移行プログラム。

（付記１０）
前記第２の記憶領域に格納されたデコード前の部分を用いて、前記エラー部分からデコード後の部分への置き換えを再開する、付記９記載のシステム移行プログラム。

（付記１１）
前記ソフトウェアは、オペレーティングシステムを含み、
前記第２の記憶領域は、前記オペレーティングシステムからは使用できない記憶領域である、付記８乃至１０の何れか１項に記載のシステム移行プログラム。

（付記１２）
ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へ前記ソフトウェアを移行させるシステム移行方法であって、前記第１の装置が、
前記第１のデータを保持しながら、前記第１のデータをエンコードした第２のデータを前記第２の装置に送信し、
前記第２の装置による前記第２のデータのデコードが開始される前に前記第１の装置により保持される前記第１のデータのエンコードを開始し、前記第２の装置による前記デコードが完了される前に、前記第１のデータをエンコード後のデータに置き換える、
システム移行方法。

（付記１３）
ソフトウェアを動作させるための第１のデータを保持しながら前記第１のデータをエンコードした第２のデータを送信する第１の装置と、
前記第２のデータを受信してデコードする第２の装置と、を有し、
前記第１の装置は、前記第２の装置による前記第２のデータのデコードが開始される前に自身が保持する前記第１のデータのエンコードを開始し、前記第２の装置による前記デコードが完了される前に、前記第１のデータをエンコード後のデータに置き換える、
情報処理システム。

１，２ 情報処理装置
１ａ，２ａ メモリ
１ｂ，２ｂ 記憶装置
１ｃ，２ｃ プロセッサ
３，３ａ，３ｂ，３ｃ データ

Claims (8)

1. ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へ前記ソフトウェアを移行させるシステム移行プログラムであって、
   前記第１の装置として用いられるコンピュータに、
   前記第１のデータを保持しながら、前記第１のデータをエンコードした第２のデータを前記第２の装置に送信し、
   前記第２の装置による前記第２のデータのデコードが開始される前に前記第１の装置により保持される前記第１のデータのエンコードを開始し、前記第２の装置による前記デコードが完了される前に、前記第１のデータをエンコード後のデータに置き換える、
   処理を実行させるシステム移行プログラム。
2. 前記第１のデータは、不揮発性の記憶装置の第１の記憶領域に格納されており、
   前記置き換えでは、前記第１のデータの複数の部分を部分毎にエンコードし、前記記憶装置のうち前記ソフトウェアの動作時にはアクセスされない第２の記憶領域にエンコード前の部分を格納する、請求項１記載のシステム移行プログラム。
3. 前記置き換えでは、エンコード前の部分に対応付けてエンコード後の当該部分のハッシュ値を前記第２の記憶領域に格納し、障害が発生すると、前記第２の記憶領域に格納されたハッシュ値に基づいて、前記第１の記憶領域のエラー部分を検索する、請求項２記載のシステム移行プログラム。
4. 前記第２の記憶領域に格納されたエンコード前の部分を用いて、前記エラー部分から前記置き換えを再開する、請求項３記載のシステム移行プログラム。
5. 前記第２のデータの複数の部分のうち、前記第２の記憶領域に格納したエンコード前の部分に対応する部分が前記第２の装置でデコードされた後に、前記第２の記憶領域から当該エンコード前の部分を削除する、請求項２乃至４の何れか１項に記載のシステム移行プログラム。
6. ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へ前記ソフトウェアを移行させるシステム移行プログラムであって、
   前記第２の装置として用いられるコンピュータに、
   前記第１のデータをエンコードした第２のデータを前記第１の装置から受信し、
   前記第１の装置に格納されている前記第１のデータの前記第１の装置によるエンコードが開始された後に、受信した前記第２のデータのデコードを開始し、前記第１の装置による前記第１のデータのエンコード後のデータへの置き換えが完了された後に、前記デコードを完了する、
   処理を実行させるシステム移行プログラム。
7. ソフトウェアを動作させるための第１のデータを記憶する第１の装置から第２の装置へ前記ソフトウェアを移行させるシステム移行方法であって、前記第１の装置が、
   前記第１のデータを保持しながら、前記第１のデータをエンコードした第２のデータを前記第２の装置に送信し、
   前記第２の装置による前記第２のデータのデコードが開始される前に前記第１の装置により保持される前記第１のデータのエンコードを開始し、前記第２の装置による前記デコードが完了される前に、前記第１のデータをエンコード後のデータに置き換える、
   システム移行方法。
8. ソフトウェアを動作させるための第１のデータを保持しながら前記第１のデータをエンコードした第２のデータを送信する第１の装置と、
   前記第２のデータを受信してデコードする第２の装置と、を有し、
   前記第１の装置は、前記第２の装置による前記第２のデータのデコードが開始される前に自身が保持する前記第１のデータのエンコードを開始し、前記第２の装置による前記デコードが完了される前に、前記第１のデータをエンコード後のデータに置き換える、
   情報処理システム。

Images