JP2010182270A - 携帯可能電子装置および携帯可能電子装置におけるデータ管理方法 - Google Patents

Abstract

【課題】データメモリの記憶領域を効率的に使用しつつ、最新のレコードデータと更新前の複数世代のレコードデータとを容易に保存したり、簡単な手順で読み出したりすることができるＩＣカードを提供する。
【解決手段】ＩＣカード１は、複数のレコードデータを格納するレコードファイルを記憶するデータメモリ１４を有し、外部装置２からレコードファイルにおける特定のレコードデータの書換えを要求するコマンドが与えられた場合、書換えが要求されたレコードデータの書換え前のレコードデータを当該レコードファイル内にバックアップデータとして保存し、書換え前のレコードデータをバックアップデータとして保存した場合、前記コマンドに従って当該レコードデータを書き換える。
【選択図】図１

Description

本発明は、例えば、個人情報あるいは取引情報などが記憶されているＩＣチップが内蔵されているＩＣカードあるいはＩＣタグなどの携帯可能電子装置、および、上記携帯可能電子装置におけるデータ管理方法などに関する。

近年、ＩＣカードなどの携帯可能電子装置は、様々な用途に利用されている。このようなＩＣカードには、使用用途に応じた個人情報や金銭的な取引情報などの種々のデータが記憶される。上記のようなデータは、通常、ＩＣカード内に設けられているＥＥＰＲＯＭやフラッシュＲＯＭなどの不揮発性メモリに書込まれる。また、ＩＣカードは、外部装置からのコマンドに応じて不揮発性メモリへのデータ書込み処理などを実行するようになっている。

また、一般的な接触式あるいは非接触式ＩＣカードでは、国際標準規格であるＩＳＯ／ＩＥＣ７８１６−４に規定されている形式でデータを取り扱う。ＩＳＯ／ＩＥＣ７８１６−４では、ＩＣカード内の不揮発性メモリ上に定義されたＥＬＥＭＥＮＴＡＲＹ ＦＩＬＥ（ＥＦ）と呼ばれるファイルにデータを記録する。また、ＩＳＯ／ＩＥＣ ７８１６−４では、種々の形式のＥＦが規定されている。ＩＳＯ／ＩＥＣ ７８１６−４で規定されているＥＦのうち一般的に使用されるのは、レコード形式のＥＦである。ＩＳＯ／ＩＥＣ ７８１６−４には、レコード形式のＥＦとして、次の３種類の形式が規定されている。

（１）固定長順編成レコードファイル
（２）可変長順編成レコードファイル
（３）固定長循環順編成レコードファイル
上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルのＥＦは、ファイルＩＤ及びレコード番号により１つのデータの記録場所（領域）が確定する。従って、上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルのＥＦに対して、データの読み出し、データの書き込み、若しくは、データの書き換えを行う場合、指定されたファイルＩＤ及びレコード番号により特定される領域に対して、書き込み、若しくは、書き換えなどを行う。

一方、固定長循環順編成レコードファイルには、データが順次追記される構成となっている。このような固定長循環順編成レコードファイルでは、一般的に、データを追記する毎にデータに対するレコード番号が付け替えられる。即ち、固定長循環順編成レコードファイルでは、順次蓄積される複数のデータに対して、新しい順（若しくは古い順）にレコード番号が割り当てられる。
従来のＩＣカードにおいては、取引履歴情報の様に、取引処理の都度データの追加が発生する様なデータは、固定長循環順編成レコードファイルに格納され、それ以外のデータは、固定長または可変長順編成レコードファイルに格納されるのが一般的である。
しかしながら、ＩＣカードの運用形態によっては、ＥＦ内にレコード番号で管理された複数のレコードに複数のデータを記憶させるとともに、あるレコードのデータが更新（書き換え）された後に更新前のデータを参照したいといった要求がある。

この様な要求を実現するには、従来のＩＣカードでは、各データ毎に、固定長循環順編成レコードファイルを個別に作成したり、管理したりする必要がある。この場合、同一ＥＦ内でのレコード管理に比べ使い勝手の悪いものとなってしまう。また、一般的な運用形態では、ＩＣカード内のＥＦは、発行処理後に追加したり、削除したりすることが出来ないものが多い。このようなＩＣカードでは、発行処理後に、上記のようなデータ管理を実現するのが難しいという問題もある。

さらに、上記したＩＣカードなどの小型電子装置では、メモリ容量に制限がある。メモリ領域に制約がある場合、上記のようなレコード管理を行うためのメモリ領域としては、大きな領域を確保することが困難である。このため、上記ＩＣカードなどの小型電子装置では、レコード管理用として使用するメモリ領域は、効率的に確保されることが要望される。

ＩＳＯ／ＩＥＣ ７８１６−４

この発明の一形態は、データの蓄積および読出しを効率的に行うことができ、かつ、メモリ領域を効率的に使用できる携帯可能電子装置および携帯可能電子装置におけるデータ管理方法を提供することを目的とする。

この発明の一形態としての携帯可能電子装置は、外部装置から与えられるコマンドに応じて処理を行うものにおいて、レコードデータを記憶するレコード領域と前記レコード領域に記憶されるレコードデータに対するバックアップデータを記憶するデータ退避領域とを有するレコードファイルを記憶する記憶手段と、前記外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、前記レコード領域に記憶されている前記レコードデータをバックアップデータとして前記データ退避領域に保存するデータ退避手段と、前記データ退避手段によりデータ退避領域にバックアップデータを保存した場合、前記レコード領域に記憶されているレコードデータを書き換える書換え手段と、を有する。

この発明の一形態としての携帯可能電子装置は、外部装置から与えられるコマンドに応じて処理を行うものにおいて、複数のレコードデータを順次格納するレコード領域を有するレコードファイルを記憶する記憶手段と、前記外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、書換え前の当該レコードデータを当該レコードファイルにおけるレコード領域の未使用領域にバックアップデータとして保存するデータ退避手段と、前記データ退避手段により書換え前のレコードデータをバックアップデータとして保存した場合、当該レコードファイルのレコード領域に記憶されているレコードデータを書き換える書換え手段とを有する。

この発明の一形態としての携帯可能電子装置におけるデータ管理方法は、レコードデータを記憶するレコード領域と前記レコード領域に記憶されるレコードデータに対するバックアップデータを記憶するデータ退避領域とを有するレコードファイルを記憶部に記憶し、外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、前記レコード領域に記憶されている前記レコードデータをバックアップデータとして前記データ退避領域に保存し、前記データ退避領域にバックアップデータを保存した場合、前記レコード領域に記憶されているレコードデータを書き換える。

この発明の一形態としての携帯可能電子装置におけるデータ管理方法は、複数のレコードデータを順次格納するレコード領域を有するレコードファイルを記憶部に記憶し、外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、書換え前の当該レコードデータを当該レコードファイルにおけるレコード領域の未使用領域にバックアップデータとして保存し、当該レコードファイル内に書換え前のレコードデータをバックアップデータとして保存した後に、当該レコードファイルのレコード領域に記憶されているレコードデータを書き換える。

この発明の一形態によれば、データの蓄積および読出しを効率的に行うことができ、かつ、メモリ領域を効率的に使用できる携帯可能電子装置および携帯可能電子装置におけるデータ管理方法を提供できる。

本実施の形態に係るＩＣカードおよびＩＣカードを含むシステムの構成例を示すブロック図。 非接触式ＩＣカードの全体の構成例を示す図。 レコードファイルの第１の構成例を示す図。 第１の構成例のレコードファイルに対するデータの書換え処理の例を説明するためのフローチャート。 第１の構成例のレコードファイルに対するデータの読出し処理の例を説明するためのフローチャート。 レコードファイルの第２の構成例を示す図。 第２の構成例のレコードファイルに対するデータの書換え処理の例を説明するためのフローチャート。 第２の構成例のレコードファイルに対するデータの読出し処理の例を説明するためのフローチャート。 レコードファイルの第３の構成例を示す図。 第３の構成例のレコードファイルに対するデータの書換え処理の例を説明するためのフローチャート。 第３の構成例のレコードファイルに対するデータの読出し処理の例を説明するためのフローチャート。 レコードファイルの第４の構成例を示す図。 第４の構成例のレコードファイルに対するデータの書換え処理の例を説明するためのフローチャート。 第４の構成例のレコードファイルに対するデータの読出し処理の例を説明するためのフローチャート。 レコードファイルの第５の構成例を示す図。 第５の構成例のレコードファイルに対するデータの書換え処理の例を説明するためのフローチャート。 第５の構成例のレコードファイルに対するデータの読出し処理の例を説明するためのフローチャート。 レコードファイルの第６の構成例を示す図。

以下、この発明に係る実施の形態について図面を参照しつつ説明する。
図１は、この発明の実施の形態に係る携帯可能電子装置としてのＩＣカード１およびＩＣカード１を含むＩＣカードシステムの構成例を示すブロック図である。
上記ＩＣカード１は、外部装置としてのＩＣカード処理装置２からの電源供給により動作可能な状態となる。動作可能となったＩＣカード１は、上記ＩＣカード処理装置２からのコマンドに応じて種々の処理を行う。上記ＩＣカード処理装置２は、ＩＣカード１を動作させるための電源を供給するとともに、当該ＩＣカード１に対して種々の処理を要求するコマンドを供給する。上記ＩＣカード処理装置２がＩＣカード１に対して供給するコマンドは、用途あるいは運用形態などに応じた処理を要求するものである。

また、上記ＩＣカード１は、アンテナあるいは無線通信部等により上記ＩＣカード処理装置２と非接触の状態で無線通信を行う非接触式の携帯可能電子装置（非接触式ＩＣカード）であっても良し、上記ＩＣカード処理装置２と物理的に接触して通信を行う接触式の携帯可能電子装置（接触式ＩＣカード）であっても良い。さらには、上記ＩＣカード１は、非接触式ＩＣカードとしての通信機能と接触式ＩＣカードとしての通信機能とを有する複合型のＩＣカード（デュアルインターフェースＩＣカード）であっても良い。なお、この実施の形態では、主に、非接触式ＩＣカードを想定して説明する。非接触式ＩＣカードと接触式ＩＣカードとはＩＣカード処理装置２との通信方式等が異なるだけである。このため、以下に説明する実施の形態は、接触式ＩＣカードにも同様に適用できる。

上記ＩＣカード１の構成例について説明する。
図１に示すように、上記ＩＣカード１は、ＣＰＵ１１、プログラムメモリ１２、ワーキングメモリ１３、データメモリ１４、通信制御部１５、電源部１６、および、インターフェース（アンテナあるいはコンタクト部）１７などを有している。
また、上記ＩＣカード１は、カード状の本体Ｃにより構成される。上記ＩＣカード１を形成するカード状の本体Ｃには、１つ（あるいは複数）のＩＣチップ１ａとインターフェース１７とが埋設される。上記ＩＣチップ１ａは、ＣＰＵ１１、プログラムメモリ１２、ワーキングメモリ１３、データメモリ１４、通信制御部１５および電源部１６などを有している。上記ＩＣチップ１ａは、上記インターフェース１７に接続された状態でモジュール化され、当該ＩＣカード１を形成するカード状の本体Ｃ内に埋設される。たとえば、図２は、非接触式ＩＣカード全体の構成例を示す図である。図２に示す非接触式ＩＣカードは、カード状の本体Ｃを有している。この本体Ｃ内には、図２に点線で示すように、１つ（あるいは複数）のＩＣチップ１ａとインターフェース１７としてのアンテナとを有するモジュールＭが埋め込まれている。

上記ＣＰＵ１１は、ＩＣカード１全体の制御を司るものである。上記ＣＰＵ１１は、上記プログラムメモリ１２あるいはデータメモリ１４に記憶されている制御プログラムおよび制御データなどに基づいて動作する。たとえば、上記ＣＰＵ１１は、上記プログラムメモリ１２に記憶されている基本的な動作を司る制御プログラムを実行することにより、外部装置から与えられるコマンドに応じた処理を実行する。これにより、外部装置から上記データメモリ１４へのデータの書込みを要求するコマンドが与えられれば、上記ＣＰＵ１１は、上記データメモリ１４へのデータの書き込み処理を実行する。また、外部装置から上記データメモリ１４に記憶されているデータの読み出しを要求するコマンドが与えられれば、上記ＣＰＵ１１は、上記データメモリ１４からのデータの読み出し処理を実行する。さらに、上記ＣＰＵ１１は、当該ＩＣカード１の用途などに応じてインストールされる処理プログラムを実行することにより、用途に応じた処理を実現するようになっている。

上記プログラムメモリ１２は、読み出し専用のメモリ（ＲＯＭ：リードオンリーメモリ）により構成される。上記プログラムメモリ１２には、予め基本動作を司る制御プログラムおよび制御データなどが記憶されている。上記プログラムメモリ１２には、予め当該ＩＣカード１の仕様に応じた制御プログラム及び制御データが記憶される。たとえば、上記ＣＰＵ１１は、上記プログラムメモリ１２に記憶される制御プログラムにより外部から与えられるコマンドに応じた処理を実現する。

上記ワーキングメモリ１３は、揮発性のメモリ（ＲＡＭ；ランダムアクセスメモリ）により構成される。上記ワーキングメモリ１３は、データを一時保管するバッファメモリとして機能する。例えば、上記ワーキングメモリ１３には、ＩＣカード処理装置（外部装置）２との通信処理において、送受信されるデータが一時的に保管される。また、上記ワーキングメモリ１３には、種々の書込みデータなどを一時的に保持するメモリとしても利用される。

上記データメモリ（不揮発性メモリ）１４は、データの書き込みが可能な不揮発性のメモリである。上記データメモリ１４は、例えば、ＥＥＰＲＯＭあるいはフラッシュメモリなどにより構成される。上記データメモリ１４には、当該ＩＣカード１の使用目的に応じた種々の情報が記憶される。
たとえば、当該ＩＣカードの使用目的に応じたアプリケーション（処理プログラムおよび運用データなど）は、上記データメモリ１４に書込まれる。当該ＩＣカード１が複数の使用目的に使用される場合、上記データメモリ１４には、各使用目的に応じた複数のアプリケーションが記憶される。また、当該ＩＣカード１の使用目的に応じたアプリケーションは、上記データメモリ１４上に定義された使用目的ごとのプログラムファイル（ＤＦ；Dedicated File）およびデータファイル（ＥＦ;Elementary File）などの各ファイルに記憶される。このようなファイル構造は、たとえば、ＩＳＯ／ＩＥＣ７８１６−４に基づくものである。なお、各種のデータを記憶するためのデータファイル（ＥＦ）の構成例については、後で詳細に説明するものとする。

上記通信制御部１５は、上記インターフェース１７を介して外部装置（たとえば、ＩＣカード処理装置２）とのデータ通信を制御するものである。たとえば、当該ＩＣカードが非接触型のＩＣカードであれば、外部装置からデータを受信する場合、上記通信制御部１５は、インターフェース１７としてのアンテナにより受信した電波としての送信データを復調し、復調した信号を上記ＣＰＵ１１に供給する。また、外部装置へデータを送信する場合、上記通信制御部１５は、上記ＣＰＵ１１から与えられるデータを変調し、変調したデータを上記インターフェース１７としてのアンテナにより電波として発信する。なお、接触式ＩＣカードでは、インターフェース１７として、アンテナの代わりに、外部装置の接触端子部と物理的・電気的に接触するコンタクト部を介して外部装置とのデータ通信を行う。

上記電源部１６は、当該ＩＣカード１の各部を動作させるための上記インターフェース１７を介して受信する電力およびクロックパルスを供給する。たとえば、当該ＩＣカードが非接触型のＩＣカードであれば、上記電源部１６は、上記インターフェース１７としてのアンテナにより受信した電波から電力およびクロックパルスを生成し、当該ＩＣカード内の各部に供給するようになっている。また、上記電源部１６からの電力供給により起動した場合、上記ＣＰＵ１１は、当該ＩＣカード１の処理状態をリセットする処理を行うようになっている。なお、当該ＩＣカード１が接触型のＩＣカードであれば、上記電源部１６はインターフェース１７を介して外部装置から直接的に供給される電力およびクロックパルスにより各部へ供給するようになっている。

次に、上記ＩＣカード処理装置２について説明する。
上記ＩＣカード処理装置２は、図１に示すように、制御装置２１およびカードリーダライタ２２を有している。上記制御装置２１は、パーソナルコンピュータ（ＰＣ）などにより構成される。上記制御装置２１は、ＣＰＵなどの演算処理部、ＲＡＭ、ＲＯＭ、不揮発性メモリおよびハードディスクドライブなどの各種メモリ、通信インターフェースなどの各種インターフェースなどにより構成される。上記制御装置２１では、上記演算処理部がメモリに記憶されている各種の制御プログラムを実行することにより各種の処理を実現している。また、上記制御装置２１は、ＩＣカード１とのデータ通信を行う上記カードリーダライタ２２とのデータの入出力を行うようになっている。

たとえば、上記制御装置２１には、上記ＩＣカード１を用いた各種の処理に応じた制御プログラムが予め記憶されている。上記制御装置２１では、上記のような制御プログラムを実行することにより上記ＩＣカード１を用いた各種の処理を実行する。たとえば、上記ＩＣカード１を用いた各種の処理において、上記制御装置２１は、所定のコマンドを所定の手順で供給する。上記制御装置２１では、上記のような各コマンドに対するＩＣカード１からの各レスポンス（コマンドに対する処理結果等を示す情報）に基づいて各種の処理を行うようになっている。

上記カードリーダライタ２２は、上記ＩＣカード１とのデータ通信を行う通信手段として機能する。上記カードリーダライタ２２は、上記ＩＣカード１の通信方式に応じた通信方式によるデータ通信を行うためのものである。つまり、上記カードリーダライタ２２を介して制御装置２１は、上記ＩＣカード１とのデータ通信を実現している。

上記ＩＣカード１が非接触型のＩＣカードである場合、上記カードリーダライタ２２は、上記ＩＣカード１との無線によるデータ通信を行うためのアンテナおよび通信制御部（変復調回路等）などにより構成される。非接触型のＩＣカード１へデータを送信する場合、上記カードリーダライタ２２では、通信制御部により上記制御装置２１から与えられる送信データを変調し、変調した信号を電波としてアンテナにより発信する。また、非接触型のＩＣカード１からデータを受信する場合、上記カードリーダライタ２２では、アンテナにより受信した電波としての信号を通信制御部により復調し、復調したデータを受信データとして上記制御装置２１へ供給する。また、上記カードリーダライタ２２では、上記のようなデータの送受信とともに、上記ＩＣカード１を動作させるための電源およびクロックパルスとなる電波をアンテナにより発信するようになっている。

また、上記ＩＣカード１が接触型のＩＣカードである場合、上記カードリーダライタ２２は、ＩＣカード１と物理的に接触してデータ通信を行うためのコンタクト部および通信制御部などにより構成される。接触型のＩＣカードとのデータの送受信を行う場合、上記カードリーダライタ２２では、上記コンタクト部がＩＣカード１側に設けられているコンタクト部と物理的に接触して各種のデータ通信を行う。また、上記カードリーダライタ２２では、ＩＣカード１に物理的に接触しているコンタクト部を介して当該ＩＣカード１に対して電力およびクロックパルスを供給するようになっている。

次に、上記データメモリ１４に記憶されるファイルについて説明する。
本実施例では、上述したようにデータメモリ１４内の各ファイルがＩＳＯ／ＩＥＣ ７８１６で規定されているファイル構造となっているものとする。ＩＳＯ／ＩＥＣ ７８１６では、ＭＦ（Master File）、ＤＦ（Dedicated File）、ＥＦ（Elementary File）などからなる階層構造のファイル構成が規定されている。ＭＦは、階層構造の最上位に位置するファイルであり、ＭＦの下層にＤＦあるいはＥＦが設けられる。ＤＦは、例えば、アプリケーションごとに設定されるファイルであり、当該アプリケーションで利用するデータを格納するためのデータファイルとしてのＥＦが下層に設けられる。各ＥＦは、それぞれ実データを記憶するためのデータファイルである。また、実データは、データファイル内において、各レコードごとに記憶される。各レコードには、それぞれレコード番号が与えられる。

上記のような各ファイルは、それぞれが図示しない管理テーブルに記憶される定義情報により定義される。たとえば、上記のようなデータファイルとしてのＥＦは、図示しない管理テーブルに記憶されるＥＦ定義情報により定義される。ＥＦ定義情報では、当該ＥＦを特定するための情報として、ファイルＩＤ、データメモリ１４における先頭アドレス、および、データサイズなどが定義される。

また、ＩＳＯ／ＩＥＣ ７８１６で規定されているデータファイル（ＥＦ）には、種々の形式がある。たとえば、ＩＳＯ／ＩＥＣ ７８１６には、ＥＦの形式として、固定長順編成レコードファイル、可変長順編成レコードファイル、固定長循環順編成レコードファイルなどがある。

上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルは、複数のデータを格納するための複数のレコード領域（以下、単にレコードとも称する）が設定可能である。たとえば、１つのファイルに複数のデータを格納したい場合、データファイルには、複数のデータに対応する複数のレコードに各データが格納される。複数のレコードを有するファイルでは、ファイルＩＤ及びレコード番号により各レコードが特定される。たとえば、上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルの特定のレコードに対して、データの読み出し、データの書き込み、若しくは、データの書き換えを行う場合、ＩＣカード処理装置２は、書き込み、書き換え、若しくは、読出しなどを要求するコマンドにおいて、ファイルＩＤ及びレコード番号によりレコードを指定する。

また、アクセス対象とするレコードを指定するには、各種のコマンドにおいて、カレントレコードを指定することも可能である。カレントレコードとは、カレント状態とするレコードである。カレントレコードを示す情報（レコードポインタ）は、常時、ワーキングメモリなどに格納され、適宜更新される。たとえば、レコード番号を指定するコマンドあるいはカレントレコードの移動（たとえば、ネクストあるいはプレビアス）を指定するコマンドに応じてレコードポインタは更新される。従って、カレントレコードを指定するコマンドを受信した場合、ＣＰＵ１１は、レコードポインタが示すレコード（つまり、カレントレコード）にアクセスするようになっている。

なお、固定長循環順編成レコードファイルには、データが順次レコード領域に追記される。このような固定長循環順編成レコードファイルでは、一般的には、データが追記される毎に各データを格納する各レコードの領域に対するレコード番号が付け替えられる。即ち、固定長循環順編成レコードファイルでは、順次蓄積される複数のデータの各レコード領域に対して、新しい順（若しくは古い順）にレコード番号が割り当てられる。

以下、本実施例で処理対象とする順編成レコードファイルの構成例について説明する。
本実施例では、上記のような順編成レコードファイルにおける各レコードは、それぞれバックアップデータが保存されるものとする。つまり、順編成レコードファイルにおける各レコードに対しては、１つ又は複数のバックアップデータが保存される。また、バックアップデータを保存するための記憶領域は、種々の手法で設定することが可能である。以下、レコードファイルの構成例について説明する。

まず、レコードァイルの第１の構成例について説明する。
第１の構成例では、当該レコードファイル内の各レコードは、識別情報（レコード番号）の記憶領域とレコードデータの記憶領域と１つのバックアップデータの記憶領域とを有している。すなわち、第１の構成例では、各レコードにおいて、１つのレコードデータと１つのバックアップデータとが記憶可能となっている。

図３は、レコードファイルの第１の構成例を示す図である。
図３に示す第１の構成例は、固定長順編成レコードファイルの構成例である。第１の構成例のレコードファイルは、ファイルＩＤで特定される。ファイルＩＤで特定されるレコードファイルは、レコード単位の複数のデータ（レコード）を記憶するレコード領域を有している。レコード領域における各レコードには、レコード番号が割当てられる。レコード番号が割り当てられた各レコードには、レコードデータの領域とバックアップデータの領域とが設けられる。レコードデータの領域には、当該レコードの最新のデータ（これが、当該レコードのレコードデータとして取り扱われる）が記憶される。バックアップデータの領域には、レコードデータの領域のデータが現在のデータに書き換えられる前のデータ（つまり、更新前のレコードデータ）が記憶される。

図３に示す例では、レコード番号「０３」およびレコード番号「０５」の各レコードには、バックアップデータが記憶されている。つまり、レコード番号「０３」および「０５」の各レコードには、レコードデータの領域とバックアップデータの領域とにそれぞれデータが書込まれている。これは、レコード番号「０３」及び「０５」の各レコードが少なくとも１回更新されていることを示している。第１の構成例のレコードでは、データを書き換える場合、当該レコードのレコードデータの領域に格納されているデータが当該レコードのバックアップデータの領域に移動され、当該レコードのレコードデータの領域に最新のデータ（書換えデータ）が書込まれる。このような構成により、各レコードには、最新のデータと最新のデータに更新する直前のデータとが常時保存される。

上記のようなレコードファイルの各レコードに格納されているデータには、ファイルＩＤとレコード番号とによりアクセスが可能となっている。たとえば、図３に示す例では、ファイルＩＤ「０００１」かつレコード番号「０１」を指定することにより、レコード番号「０１」のレコードデータの領域に格納されているデータにアクセスすることが可能となっている。同様に、バックアップデータが記憶されているレコード番号「０３」（又は「０５」）のレコードに対しても、ファイルＩＤ「０００１」かつレコード番号「０３」（又は「０５」）を指定することにより、レコード番号「０３」（又は「０５」）のレコードデータの領域に格納されているデータにアクセスすることが可能となっている。

また、レコード番号「０３」（又は「０５」）のバックアップデータの領域に格納されているデータ（更新前のデータ）には、所定の操作によりアクセスすることが可能となっている。バックアップデータの領域に格納されているデータにアクセスするための手法としては、種々の手法が考えられる。たとえば、バックアップデータの領域のデータへのアクセスを要求するコマンドコードを定義しても良いし、コマンドにおける処理パラメータでバックアップデータの領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップデータの領域のデータへのアクセスを行うようにしても良い。

ここでは、カレントレコードを指定するコマンドによりカレントレコードのバックアップデータの領域のデータにアクセスする場合について説明する。
たとえば、図３に示すようなレコードファイルを有するＩＣカード１が、ファイルＩＤ「０００１」かつレコード番号「０３」のレコードを指定したデータの読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、ファイルＩＤ「０００１」かつレコード番号「０３」のレコードにおけるレコードデータの領域のデータを読み出す処理を行う。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」かつレコード番号「０３」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。

この状態において、続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」かつレコード番号「０３」のレコードにおけるバックアップデータの領域のデータを読み出す処理を行う。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップデータの領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。

ここで、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、バックアップデータの領域のデータが読出し済みであるためエラーとして処理するか、あるいは、当該レコードのレコードデータの領域のデータを読み出す処理を行うようにするものとする。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおけるバックアップデータの領域のデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるレコードデータの領域のデータ、および、バックアップデータの領域のデータを交互に読み出すことが可能となる。

次に、上記第１の構成例のレコードファイルにおける各レコードに対するデータの書換え処理の流れについて説明する。
図４は、第１の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。

まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１０）、ＣＰＵ１１は、コマンドコードなどにより受信したコマンドがデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ１１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ１１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ１２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。

指定されたレコードを特定すると、ＣＰＵ１１は、指定されたレコードにバックアップデータの領域が設定されているか否かを判断する（ステップＳ１３）。この判断は、指定されたレコードにおける更新前のデータをバックアップデータとして保存するか否かを判断するものである。上記判断により指定されたレコードにバックアップデータの領域が設定されていると判断した場合、ＣＰＵ１１は、当該レコードのレコードデータの領域に格納されているデータをバックアップデータの領域に移動させる（ステップＳ１４）。ここで、ＣＰＵ１１は、当該レコードのレコードデータの領域に格納されているデータを読み出し、読み出したデータをバックアップデータの領域に記憶する処理を行う。たとえば、上記ステップＳ１４において、既に当該レコードのバックアップデータの領域にデータが格納されている場合、レコードデータの領域から読み出したデータは、バックアップデータの領域のデータに上書きされる（すなわち、指定されたレコードにおけるバックアップデータの領域のデータは、レコードデータの領域から読み出したデータに書換えられる）。

ただし、各レコードのレコードデータの領域とバックアップデータの領域とは、それぞれの意味付けが異なるだけである。従って、上記ステップＳ１４の処理としては、当該レコードにおけるレコードデータの領域とバックアップデータの領域とを交換し、交換後のレコードデータの領域にデータを書き込むようにしても良い。つまり、データ更新処理時に、レコードデータの領域をバックアップデータの領域に変更し、かつ、バックアップデータの領域をレコードデータの領域に変更することにより、更新前のレコードデータの領域（更新後のバックアップデータの領域）に格納されているデータをバックアップデータに変更するようにしても良い。

この場合、当該レコードにおけるレコードデータの領域とバックアップデータの領域の定義付けを変更（交換）し、更新前のバックアップデータの領域（更新後のレコードデータの領域）のデータを書き換えることにより、当該レコードにおけるレコードデータの領域およびバックアップデータの領域の書換えが実現できる。この場合、レコードデータの領域のデータを書き換えるだけで良い（バックアップデータの領域のデータは書き換えなくても良い）ので、処理時間の短縮化が期待できる。

上記レコードデータの領域に格納されているデータをバックアップデータの領域に移動させると、ＣＰＵ１１は、当該レコードのレコードデータの領域のデータを、受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ１５）。このようなレコードデータの領域のデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ１６）、処理を終了する。

なお、上記ステップＳ１５においてレコードデータの領域に対するデータの書換えが失敗した場合（あるいは、受信したコマンドに含まれる書換えデータのレコードデータの領域への書込みがリトライできない状態となった場合）、ＣＰＵ１１は、当該レコードのバックアップデータの領域に移動したデータを再度、当該レコードのレコードデータの領域に書き込むことにより、当該レコードの復旧処理を行うようにしても良い。このようにレコードデータの領域へのデータの書込みが失敗した場合に、バックアップデータの領域のデータでレコードデータの領域のデータを復旧させる（コマンドの受信前の状態に戻す）ことにより、ＩＣカードとしての動作を安定化させることが可能である。

上記のように、上述した第１の構成例のレコードファイルに対する書込み処理は、あるレコードのデータを更新する場合に、当該レコードの更新前のデータをバックアップデータの領域に退避させ、最新のデータ（書換えデータ）を当該レコードのデータとしてのレコードデータの領域に書き込むようにしたものである。
これにより、更新前のデータを別のレコードとして保存するコマンドを与えたりすることなく、擬似的な２次元配列ファイルによって更新前のデータを随時保存しておくことが可能となる。

次に、上記第１の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図５は、第１の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ２０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ２１）。

この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ２１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップデータの領域の読出しを要求するものであるか否かを判定する（ステップＳ２２）。バックアップデータの領域の読出を要求する手法には、上述したような様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップデータの領域の読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの領域の読出要求を示すようにしても良い。

また、特定のコマンドの実行手順によりバックアップデータの領域の読出要求を示す形態としては、特定のコマンドが連続して与えられた場合にバックアップデータの領域を読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合にバックアップデータの領域を読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの領域の読出を要求する形態としては、コマンドコードあるいは処理パラメータなどでバックアップデータの領域の読出を指定するようにすれば良い。上記のような運用形態に従って、ＣＰＵ１１は、受信したコマンドがバックアップデータの領域の読出しを要求するコマンドであるか否かを判断するようになっている。

ここでは、図５に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードのバックアップデータの領域を読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、上記ステップＳ２２の処理として、当該コマンドにおいて読出対象とするレコードが、レコード番号で指定されているか、「カレントレコード」として指定されているかを判定する（ステップＳ２２）。

上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップデータの領域の読出しを要求する場合（ステップＳ２２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコード（指定されたレコード）にバックアップデータの領域が設定されているか否かを判断する（ステップＳ２３）。

この判断により指定されたレコードにバックアップデータの領域が設定されていると判断した場合（ステップＳ２３、ＹＥＳ）、ＣＰＵ１１は、受信したコマンドの直前に受信したリードレコードコマンドによって当該レコードのバックアップデータの領域のデータが読出し処理済みであるか否かを判断する（ステップＳ２４）。つまり、上記ステップＳ２４において、上記ＣＰＵ１１は、前回受信したリードコマンドによってバックアップデータの領域のデータを読み出したか否かを判断する。言い換えると、上記ステップＳ２４において、上記ＣＰＵ１１は、連続してバックアップデータの領域のデータの読出しを要求するコマンドを受信したか否かを判断している。

上記判断によりカレントレコードのバックアップデータの領域のデータが読出し済みでないと判断した場合（ステップＳ２４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）におけるバックアップデータの領域のデータを読み出す（ステップＳ２５）。カレントレコードのバックアップデータの領域領域のデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ２６）。このように、上記ステップＳ２０〜Ｓ２６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップデータの領域のデータが読み出される。

また、図５に示す処理例では、上記ステップＳ２２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ２２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのレコードデータの領域のデータ（最新のデータ）の読出しを要求するものであると判定する。

すなわち、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ２２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ２８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、特定されたレコードをカレントレコードに設定する。

受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのレコードデータの領域のデータを読出し（ステップＳ２９）、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ２６）。

また、図５に示す処理例では、ステップＳ２３でカレントレコードにバックアップデータの領域が設定されていないと判断した場合（ステップＳ２３、ＮＯ）、ＣＰＵ１１は、ステップＳ２９へ進み、カレントレコードのレコードデータの領域のデータを読み出す処理を行うものとする。ただし、ステップＳ２３でＮＯと判断される場合は、バックアップデータの領域の読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）にバックアップデータの領域が設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ２７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。

また、図５に示す処理例では、ステップＳ２４でバックアップデータの領域のデータが直前のリードコマンドによって読出し済みであると判断した場合（ステップＳ２４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ２７）。これは、バックアップデータの領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合であっても、連続して特定のレコード（カレントレコード）におけるバックアップデータの領域のデータの読出しを行わないようにする仕組みである。

ただし、上記ステップＳ２４でバックアップデータの領域のデータが直前のリードコマンドで読出し済みであると判断した場合（ステップＳ２４、ＹＥＳ）、ＣＰＵ１１は、図５に点線で示すように、ステップＳ２９へ進み、カレントレコードのレコードデータの領域のデータを読み出す処理を行うようにしても良い。これは、バックアップデータの領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、特定のレコード（カレントレコード）におけるバックアップデータの領域のデータとレコードデータの領域のデータとを交互に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードのバックアップデータの領域のデータとレコードデータの領域のデータとを交互に読み出す制御が可能となる。

上記のような読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのレコードデータの領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンド（バックアップデータの領域のデータの読出しを要求するコマンド）に対しては、当該レコードのバックアップデータの領域に記憶されているデータを読み出すようになっている。
これにより、擬似的な２次元配列ファイルに格納されているデータを容易に読み出すことができ、レコード番号の管理などが複雑化することなく、取引履歴情報などの更新されることが予測されるデータについて最新のデータおよび更新前のデータを容易に読み出すことができる。

次に、レコードァイルの第２の構成例について説明する。
第２の構成例では、レコードファイル内の各レコードは、識別情報（レコード番号）の記憶領域とレコードデータの記憶領域と複数のバックアップデータの記憶領域とを有している。すなわち、第２の構成例では、各レコード内において、１つのレコードデータと複数のバックアップデータとが保存可能となっている。

図６は、レコードファイルの第２の構成例を示す図である。
図６に示す第２の構成例は、固定長順編成レコードファイルの構成例である。第２の構成例のレコードファイルは、ファイルＩＤで特定される。ファイルＩＤで特定されるレコードファイルは、レコード単位の複数のデータ（レコード）を格納するレコード領域により構成される。レコード領域内の各レコードには、レコード番号が割当てられる。レコード番号が割り当てられる各レコードは、１つのレコードデータの領域と複数のバックアップデータの領域とを有している。レコードデータの領域には当該レコードの最新のデータ（これが、当該レコードのデータとして取り扱われる）が格納され、各バックアップデータの領域には上記レコードデータの領域のデータの更新時に順次古いデータ（更新前のデータ）が格納される。また、１つのレコードにおける複数のバックアップデータの領域には、それぞれ順に更新前のデータが書込まれる。言い換えれば、第２の構成例のファイルでは、各レコード毎に、バックアップデータの領域の数だけ古いデータが格納される。

たとえば、図６に示す例では、レコード番号「０２」のレコードには、最新のデータがレコードデータの領域に格納され、３つのバックアップデータの領域に３回分の古いデータがそれぞれ順に格納されている。これは、レコード番号「０２」の各レコードが少なくとも３回更新されていることを示している。このようなレコードに対しては、レコードデータの領域のデータを更新する場合に、レコードデータの領域に格納されているデータが１世代前のデータを格納する第１のバックアップデータの領域に移動され、第１のバックアップデータの領域に格納されているデータが２世代前のデータを格納する第２のバックアップデータの領域に移動され、第２のバックアップデータの領域に格納されているデータが３世代前のデータを格納する第３のバックアップデータの領域に移動される。このような構成により、各レコードには、最新のデータと複数のバックアップデータが常時保存される。

また、上記のようなレコードファイルの各レコードのレコードデータの領域に格納されているデータには、上記第１の構成例と同様に、ファイルＩＤとレコード番号とを指定することによりアクセスすることが可能となっている。これに対して、各レコードの各バックアップデータの領域に格納されているデータには、所定の操作によりアクセスすることが可能となっている。

各レコードの各バックアップデータの領域に格納されているデータにアクセスするための手法としては、種々の手法が考えられる。たとえば、バックアップデータの領域のデータへのアクセスを要求するコマンドコードを定義しても良いし、コマンドにおける処理パラメータでバックアップデータの領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップデータの領域のデータへのアクセスを行うようにしても良い。

ここでは、「カレントレコード」を指定するコマンドによりバックアップデータの領域のデータにアクセスする場合について説明する。
たとえば、図６に示すファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータの読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードにおけるレコードデータの領域のデータを読み出す処理を行う。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」かつレコード番号「０２」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。

この状態において、カレントレコードを指定した読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」かつレコード番号「０２」のレコードにおける第１のバックアップデータの領域のデータを読み出す処理を行う。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップデータの領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。また、再度（２度連続して）、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第１のバックアップデータの領域のデータを読み出すようにしても良い。

また、続けて同じコマンドを受信した場合、つまり、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０２」のレコードにおける第２のバックアップデータの領域のデータを読み出す処理を行う。なお、３度連続して、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第２のバックアップデータの領域のデータを読み出すようにしても良い。

さらに、続けて同じコマンドを受信した場合、つまり、３度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０２」のレコードにおける第３のバックアップデータの領域のデータを読み出す処理を行う。なお、４度連続して、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第３のバックアップデータの領域のデータを読み出すようにしても良い。

ここで、バックアップデータの領域が各レコードに対して３つまでであるものとする。このような場合、４度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、全バックアップデータの領域のデータが読出し済みであるため、エラーとして処理するか、あるいは、当該レコードのレコードデータの領域のデータを読み出す処理を行うようにするものとする。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおける全バックアップデータの領域のデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるレコードデータの領域のデータ、および、各バックアップデータの領域のデータを順次循環させて読み出すことが可能となる。

次に、上記第２の構成例のレコードファイルにおける各レコードに対するデータの書換え処理について説明する。
図７は、第２の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。

まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ３０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ３１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ３１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ３２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。

指定されたレコードを判定すると、ＣＰＵ１１は、指定されたレコードにバックアップデータの領域が設定されているか否かを判断する（ステップＳ３３）。この判断は、指定されたレコードにおいて更新前のデータをバックアップデータとして保存するように設定されているか否かを判断するものである。上記判断により指定されたレコードにバックアップデータの領域が設定されていると判断した場合、ＣＰＵ１１は、当該レコードのレコードデータの領域および各バックアップデータの領域に格納されている各データを順次次のバックアップデータの領域に移動させる処理を行う（ステップＳ３４〜Ｓ３６）。

たとえば、ＣＰＵ１１は、まず、全バックアップデータの領域にデータが保存されているか否かを判断する（ステップＳ３４）。この判断により全バックアップデータの領域にデータが保存されていると判断した場合、ＣＰＵ１１は、最も古いデータが記憶されているバックアップデータの領域のデータを削除する（ステップＳ３５）。このような状態において、ＣＰＵ１１は、レコードデータの領域および各バックアップデータの領域のデータを順次各バックアップデータの領域に移動させる（ステップＳ３６）。

なお、上記ステップＳ３４〜Ｓ３６の処理は、当該レコードにおけるレコードデータの領域及び各バックアップデータの領域のデータを順次次のバックアップデータの領域に上書きすることにより実現しても良いし、最古のデータが記憶されているバックアップデータの領域にレコードデータの領域のデータを上書きすることにより実現するようにしても良い。何れの場合であっても、結果として、当該レコードでは、最古のデータが削除され、レコードデータの領域と各バックアップデータの領域の各データがぞれぞれバックアップデータの領域に格納される。

当該レコードのレコードデータの領域および各バックアップデータの領域のデータを順次各バックアップデータの領域に移動させると、ＣＰＵ１１は、当該レコードのレコードデータの領域のデータを、受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ３７）。このようなレコードデータの領域のデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ３８）、処理を終了する。

なお、上記ステップＳ３７においてレコードデータの領域に対するデータの書換えが失敗した場合（あるいは、受信したコマンドに含まれる書換えデータのレコードデータの領域への書込みがリトライできない状態となった場合）、ＣＰＵ１１は、レコードデータの領域からバックアップデータの領域へ移動させたデータを再度、当該レコードのレコードデータの領域に書き込むことにより、当該レコードの復旧処理を行うようにしても良い。このようにレコードデータの領域へのデータの書込みが失敗した場合に、バックアップデータの領域のデータでレコードデータの領域のデータを復旧させる（コマンドの受信前の状態に戻す）ことにより、ＩＣカード１としての動作を安定化させることが可能である。

上記のような書込み処理は、あるレコードのデータを更新する際に、レコードデータの領域および各バックアップデータの領域の各データを順次それぞれバックアップデータの領域に退避させ、最新のデータ（書換えデータ）を当該レコードのデータとしてのレコードデータの領域に書き込むようにしたものである。これにより、更新前のデータを別のレコードとして保存するコマンドを与えたりすることなく、擬似的な２次元配列ファイルによって最新のデータと更新前の複数のデータ（複数世代のデータ）を容易に保存しておくことが可能となる。

また、上記のような書込み処理では、バックアップデータが全バックアップデータの領域の容量を超える場合、最古のデータを削除して、最新のデータからバックアップデータの領域の数の分だけ古い各データを各バックアップデータの領域に常時保存しておくようにしたものである。これにより、各レコードに設けられた各バックアップデータの領域に、最新のデータからバックアップデータの領域の数だけ古いデータまでの各世代のデータを各バックアップデータの領域に保存することが可能となる。

次に、上記第２の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図８は、第２の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ４０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてレコードデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ４１）。

この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ４１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップデータの領域の読出しを要求するコマンドであるか否かを判定する（ステップＳ４２）。

上述したように、バックアップデータの領域の読出を要求する手法には、様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップデータの領域の読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの領域の読出要求するようにしても良い。また、特定のコマンドの実行手順によりバックアップデータの領域の読出要求を示す形態としては、特定のコマンドが連続して与えられた場合に各バックアップデータの領域を順次読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合に各バックアップデータの領域を順次読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの領域の読出要求を示す形態としては、コマンドコードあるいは処理パラメータなどで各レコードの各バックアップデータの領域の読出を指定するようにすれば良い。上記のような運用形態に応じて、ＣＰＵ１１は、受信したコマンドがバックアップデータの領域の読出しを要求するコマンドであるか否かを判断するようになっている。

ここでは、図８に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードの各バックアップデータの領域を順次読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、上記ステップＳ４２の処理として、当該コマンドにおいて読出対象とするレコードが、レコード番号で指定されている（あるいは、カレント以外のレコードが指定されている）か、「カレントレコード」として指定されているかを判定する（ステップＳ４２）。

上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップデータの領域の読出しを要求する場合（ステップＳ４２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコードにバックアップデータの領域が設定されているか否かを判断する（ステップＳ４３）。

この判断によりカレントレコードにバックアップデータの領域が設定されていると判断した場合（ステップＳ４３、ＹＥＳ）、ＣＰＵ１１は、受信したコマンドの前までに受信したリードレコードコマンドによって当該レコードの全バックアップデータの領域のデータが読出し処理済みであるか否かを判断する（ステップＳ４４）。つまり、上記ステップＳ４４において、上記ＣＰＵ１１は、前回までに受信したリードコマンドによって全バックアップデータの領域のデータを読み出したか否かを判断する。

上記判断によりカレントレコードの全バックアップデータの領域のデータが読出し済みでないと判断した場合（ステップＳ４４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）における各バックアップデータの領域のデータを順次読み出す（ステップＳ４５）。たとえば、上記ＣＰＵ１１は、バックアップデータの領域のデータを読み出すごとに、ワーキングメモリ１３に設けた図示しないカウンタをカウントアップする。これにより、連続してカレントレコードを指定するリードレコードコマンドを受けるごとに、ＣＰＵ１１は、カウンタの値に基づいて順に各バックアップデータの領域のデータを読み出す。

カレントレコードのバックアップデータの領域のデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ４６）。このように、上記ステップＳ４０〜Ｓ４６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップデータの領域のデータが読み出される。このような処理を繰り返すことで、当該ＩＣカード１は、各バックアップデータの領域のデータを順に読み出すことが可能となっている。

また、図８に示す処理例では、上記ステップＳ４２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ４２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのレコードデータの領域のデータ（最新のデータ）の読出しを要求するものであると判定する。ただし、カレントレコードを変更しないリードコマンドを受信した場合は、上記ステップＳ４３へ進むようにしても良い。

受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ４２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ４８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、指定されたレコードをカレントレコードとする。

受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのレコードデータの領域のデータを読出し（ステップＳ４９）、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ４６）。

また、図８に示す処理例では、ステップＳ４３でカレントレコードにバックアップデータの領域が設定されていないと判断した場合（ステップＳ４３、ＮＯ）、ＣＰＵ１１は、ステップＳ４９へ進み、カレントレコードのレコードデータの領域のデータを読み出す処理を行うものとする。ただし、ステップＳ４３でＮＯと判断される場合は、バックアップデータの領域の読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）にバックアップデータの領域が設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ４７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。

また、図８に示す処理例では、ステップＳ４４で全バックアップデータの領域のデータが直前のリードコマンドによって読出し済みであると判断した場合（ステップＳ４４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ４７）。これは、バックアップデータの領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合、連続して特定のレコード（カレントレコード）における全バックアップデータの領域のデータが読出し済みであることをエラー通知によって通知する仕組みである。

ただし、上記ステップＳ４４で全バックアップデータの領域のデータが直前までのリードコマンドで読出し済みであると判断した場合（ステップＳ４４、ＹＥＳ）、ＣＰＵ１１は、図８に点線で示すように、ステップＳ４９へ進み、カレントレコードのレコードデータの領域のデータを読み出す処理を行うようにしても良い。これは、バックアップデータの領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、特定のレコード（カレントレコード）における各バックアップデータの領域の各データとレコードデータの領域のデータとを順に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードの各バックアップデータの領域のデータとレコードデータの領域のデータとを順に読み出す制御が可能となる。

上記のような読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのレコードデータの領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンド（バックアップデータの領域のデータの読出しを要求するコマンド）に対しては、当該レコードのバックアップデータの領域に記憶されているデータを読み出すようになっている。つまり、レコードデータの領域のデータを読み出した後に連続して特定のレコードの読出しが要求される場合、各バックアップデータの領域のデータを順に読み出すようになっている。

これにより、擬似的な２次元配列ファイルに格納されている複数のバックアップデータを簡単な手順で順に読み出すことができ、レコード番号の管理などが複雑化することなく、取引履歴情報などの更新されることが予測されるデータについて最新のデータおよび更新前の複数のデータを容易に読み出すことができる。

次に、レコードァイルの第３の構成例について説明する。
第３の構成例は、レコードファイル内において、レコードを格納するためのレコード領域とバックアップデータを格納するためのバックアップ領域（データ退避領域）とを設けるものである。上記バックアップ領域は、レコード領域内の各レコードに対応して予め確保されているものではなく、保存すべきバックアップデータに応じて適宜確保されるものである。すなわち、第１及び第２の構成例では、各レコードの記憶領域内にバックアップデータを保存するための記憶領域を確保しておくのに対して、第３の構成例では、各レコードの記憶領域とは別の記憶領域（バックアップ領域）に各レコードに対するバックアップデータを保存する。なお、第３の構成例では、１つのレコードに対して１つのバックアップデータを保存するものとする。

図９は、レコードファイルの第３の構成例を示す図である。
図９に示す第３の構成例は、固定長順編成レコードファイルの構成例である。図９に示す第３の構成例のレコードファイルは、ファイルＩＤで特定される。ファイルＩＤで特定されるレコードファイルは、レコード領域とバックアップ領域とを有している。上記レコード領域には、複数のレコードが格納される。レコード領域に格納される各レコードは、それぞれレコード番号とレコードデータとにより構成される。各レコードには、レコード番号とレコードデータとを記憶するための記憶領域が割当てられる。

また、上記バックアップ領域には、レコード領域における何れかのレコードに対するバックアップレコードが格納される。バックアップ領域に格納される各バックアップレコードは、それぞれレコード番号とバックアップデータとにより構成される。各バックアップレコードのレコード番号は、バックアップしているレコードを示すレコード番号である。つまり、バックアップ領域における各バックアップデータは、対応するレコード番号で示されるレコードのレコードデータが更新される直前のレコードデータ（つまりバックアップされたデータ）である。

たとえば、図９に示すバックアップ領域には、レコード番号「０３」のレコードに対するバックアップデータとレコード番号「０５」のレコードに対するバックアップデータとが記憶されている。つまり、レコード番号「０３」および「０５」の各レコードには、バックアップデータがバックアップ領域に保存されている。これは、レコード番号「０３」及び「０５」の各レコードが少なくとも１回更新されていることを示している。

第３の構成例では、あるレコードを更新する場合、レコード領域に格納されている当該レコードのレコードデータが、バックアップデータとして当該レコード番号に対応づけてバックアップ領域に書き込まれる。つまり、当該レコードファイルは、バックアップデータがバックアップ領域に保存された後、レコード領域における当該レコードのレコードデータが書換えられる。これにより、最新のレコードデータがレコード領域に記憶されるとともに、最新のレコードデータに更新する直前のレコードデータがバックアップデータとしてバックアップ領域に保存される。

上記のようなレコード領域における各レコードのレコードデータには、ファイルＩＤとレコード番号とによりアクセスが可能となっている。たとえば、図９に示す例では、ファイルＩＤ「０００１」かつレコード番号「０１」を指定することにより、レコード番号「０１」のレコードデータにアクセスすることが可能となっている。同様に、バックアップデータが存在するレコード番号「０３」（又は「０５」）のレコードデータに対しても、ファイルＩＤ「０００１」とレコード番号「０３」（又は「０５」）とを指定することによりアクセスすることが可能となっている。

また、上記バックアップ領域における各レコードのバックアップデータ（更新前のデータ）には、所定の手順によりアクセスすることが可能となっている。バックアップ領域のバックアップデータにアクセスするための手法としては、たとえば、バックアップデータへのアクセスを要求するコマンドを定義しても良いし、コマンドにおける処理パラメータでバックアップデータの領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップデータへのアクセスを行うようにしても良い。

ここでは、カレントレコードを指定するコマンドによりカレントレコードに対するバックアップデータにアクセスする手法について説明する。
たとえば、ファイルＩＤ「０００１」、かつ、レコード番号「０３」を指定したデータの読出要求コマンド（リードレコードコマンド）を受信したＩＣカード１のＣＰＵ１１は、図９に示すようなファイルＩＤ「０００１」のレコードファイルにおけるレコード番号「０３」のレコードデータをレコード領域から読み出す。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」のレコードファイルにおけるレコード番号「０３」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。

この状態において、続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」のレコードファイルにおけるレコード番号「０３」のレコードに対するバックアップデータを当該レコードファイルのバックアップ領域から読み出す。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップデータの領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。

なお、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードに対するバックアップデータが読出し済みであるためエラーとして処理するか、あるいは、当該カレントレコードのレコードデータを読み出す処理を行う。前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードに対するバックアップデータを読み出したことを確実に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードレコードコマンドを連続してＩＣカード１に与えることにより、カレントレコードのレコードデータ、および、カレントレコードに対するバックアップデータを交互に読み出すことが可能となる。

次に、上記第３の構成例のレコードファイルにおける各レコードに対するデータの書換え処理の流れについて説明する。
図１０は、第３の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。

まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１１０）、ＣＰＵ１１は、コマンドコードなどにより受信したコマンドがデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ１１１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ１１１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ１１２）。たとえば、受信したコマンドにおいてファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。

指定されたレコードを特定すると、ＣＰＵ１１は、指定されたレコードにおける更新前のレコードデータをバックアップデータとして保存するか否かを判断するものである（ステップＳ１１３）。指定レコードに対するバックアップの要否は、種々の設定方法が考えられる。たとえば、各レコードに対するバックアップの要否は、レコードごとに設定しても良いし、レコードファイルごとに設定するようにしても良い。また、書換えコマンドにおけるパラメータでバックアップの要否を指定するようにしても良いし、特定の送信元からの書換えコマンドに対してのみバックアップを行うようにしても良い。

上記判断により指定されたレコードに対するバックアップが必要であると判断した場合（ステップＳ１１３、ＹＥＳ）、ＣＰＵ１１は、当該レコードのレコードデータを当該レコードのバックアップデータとしてバックアップ領域に保存する処理を行う（ステップＳ１１４）。ここで、ＣＰＵ１１は、当該レコードのレコードデータを読み出し、読み出したデータをバックアップデータとして当該レコードのレコード番号に対応づけてバックアップ領域に書き込む。たとえば、上記ステップＳ１１４において、既にバックアップ領域に当該レコードのバックアップデータが格納されている場合（つまり、当該レコード番号のバックアップデータが既に存在する場合）、ＣＰＵ１１は、読み出したレコードデータを当該レコード番号のバックアップデータに上書きする。すなわち、ＣＰＵ１１は、バックアップ領域における当該レコード番号に対応するバックアップデータを当該レコードの更新直前のレコードデータに書換える。

上記バックアップ領域にバックアップデータを書き込むと、ＣＰＵ１１は、上記レコード領域における当該レコードのレコードデータを書換えコマンドで指定される書換えデータに書き換える（ステップＳ１１５）。このようなレコードデータの書換えが正常終了すると、ＣＰＵ１１は、受信した書換えコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ１１６）、処理を終了する。

なお、上記ステップＳ１１５においてレコードデータの書換えが失敗した場合（たとえば、レコードデータの書換えがリトライできない状態となった場合）、ＣＰＵ１１は、当該レコードの復旧処理として、上記バックアップ領域に書き込んだ当該レコードのバックアップデータを再度、当該レコードのレコードデータとして書き込むようにしても良い。このように、当該ＩＣカード１では、レコードデータの書換えが失敗した場合に、バックアップ領域に保存したバックアップデータでレコードデータを復旧させる（コマンドの受信前の状態に戻す）機能も実現できる。このような機能によれば、当該ＩＣカードの動作を安定化させることが可能となる。

上記のように、第３の構成例のレコードファイルに対するレコードデータの書換え処理は、バックアップ領域に更新前のレコードデータをレコード番号と対応づけたバックアップデータとして退避させ、当該レコード領域における当該レコードのレコードデータを最新のデータ（書換えデータ）に書き換える処理を行うようにしたものである。
これにより、更新前のレコードデータを別のレコードとして保存するコマンドを与えたりすることなく、更新前のレコードデータを随時保存した状態でレコードデータの書換え処理が実行できる。

次に、上記第３の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図１１は、第３の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１２０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ１２１）。この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ１２１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップデータの読出しを要求するものであるか否かを判定する（ステップＳ１２２）。

バックアップデータの読出を要求する手法には、上述したような様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップデータの読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの読出要求を示すようにしても良い。

特定のコマンドの実行手順によりバックアップデータの読出要求を示す形態としては、特定のコマンドが連続して与えられた場合にバックアップデータを読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合にバックアップデータを読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの読出を要求する形態としては、コマンドコードあるいは処理パラメータなどでバックアップデータの読出を指定するようにすれば良い。上記のような運用形態に従って、ＣＰＵ１１は、受信したコマンドがバックアップデータの領域の読出しを要求するコマンドであるか否かを判断するようになっている。

ここでは、図１１に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードのバックアップデータを読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、受信したリードレコードコマンドにおいて読出対象とするレコードが、「カレントレコード」として指定されているか、レコード番号で指定されているかにより、バックアップデータの読出要求であるか否かを判定する（ステップＳ１２２）。

上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップデータの読出要求である場合（ステップＳ１２２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコード（指定されたレコード）に対するバックアップデータがバックアップ領域に存在するか否かを判断する（ステップＳ１２３）。これは、カレントレコードのレコード番号がバックアップ領域に存在するか否かにより判断できる。

上記判断により現在のカレントレコード（指定されたレコード）に対するバックアップデータが存在すると判断した場合（ステップＳ１２３、ＹＥＳ）、ＣＰＵ１１は、当該リードレコードコマンドの直前のコマンドによる処理として当該バックアップデータの読出し処理を行ったか否かを判断する（ステップＳ１２４）。言い換えると、上記ステップＳ１２４において、上記ＣＰＵ１１は、連続してバックアップデータの読出しを要求するコマンドを受信したか否かを判断している。

上記判断によりカレントレコードに対するバックアップデータが読出し済みでないと判断した場合（ステップＳ１２４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）に対するバックアップデータをバックアップ領域から読み出す（ステップＳ１２５）。カレントレコードに対するバックアップデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２へ読み出したデータを含むレスポンスデータを送信する（ステップＳ１２６）。このように、上記ステップＳ１２０〜Ｓ１２６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップデータが読み出される。

また、図１１に示す処理例では、上記ステップＳ１２２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ１２２、ＮＯ）、ＣＰＵ１１は、当該コマンドが指定レコードのレコードデータをレコード領域から読出すことを要求するものであると判定する。

すなわち、受信したコマンドにおいてファイルＩＤとレコード番号とによりレコードが指定されている場合（ステップＳ１２２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより指定されるレコードを読出対象として特定する（ステップＳ１２８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、特定されたレコードをカレントレコードに設定する。

受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定したレコードのレコードデータを読出し（ステップＳ１２９）、当該コマンドの送信元であるＩＣカード処理装置２へ読み出したデータを含むレスポンスデータを送信する（ステップＳ１２６）。

また、図１１に示す処理例では、カレントレコードに対するバックアップデータが存在しない場合（ステップＳ１２３、ＮＯ）、ＣＰＵ１１は、ステップＳ１２９へ進み、カレントレコードのレコードデータを読み出す処理を行うものとする。ただし、ＣＰＵ１１は、ステップＳ１２７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。この場合、エラーであることを示すレスポンスには、受信したコマンドで指定されるレコード（カレントレコード）に対するバックアップデータが存在しない旨を通知するようにしても良い。

また、図１１に示す処理例では、バックアップデータが直前のコマンドによって読出し済みであると判断した場合（ステップＳ１２４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ１２７）。これは、バックアップデータの読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合には、連続して特定のレコード（カレントレコード）におけるバックアップデータの読出しを行わないようにするための仕組みである。

ただし、上記ステップＳ１２４でバックアップデータが直前のコマンドによって読出し済みであると判断した場合（ステップＳ１２４、ＹＥＳ）、ＣＰＵ１１は、図１１に点線で示すように、ステップＳ１２９へ進み、カレントレコードのレコードデータを読み出す処理を行うようにしても良い。これは、カレントレコードを指定したリードレコードコマンドが連続して与えられた場合に、特定のレコード（カレントレコード）におけるバックアップデータとレコードデータとを交互に読み出すようにするための仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードのバックアップデータとレコードデータとを交互に読み出す制御が可能となる。

上記のような第３の構成例のレコードファイルに対する読出処理では、ＩＣカード１は、レコード番号を指定したリードコマンドに対しては、当該レコードのレコードデータを読出し、カレントレコードを指定したリードコマンド（バックアップデータの読出しを要求するコマンド）に対しては、当該レコード（カレントレコード）に対するバックアップデータを読み出すようになっている。

これにより、コマンドの内容によって特定のレコードのレコードデータを読み出したり、バックアップデータを読み出したりすることができる。すなわち、レコードファイルを第３の構成例としたＩＣカードでは、レコードデータとバックアップデータとの管理などが容易化できる。この結果として、上記ＩＣカードでは、たとえば、取引履歴情報などの更新されることが予測されるデータについて、最新のデータ（レコードデータ）および更新前のデータ（バックアップデータ）を容易に管理できる。

次に、レコードァイルの第４の構成例について説明する。
第４の構成例は、上記第３の構成例と同様に、レコードファイル内にレコードを格納するためのレコード領域とバックアップデータを格納するためのバックアップ領域とを設ける。ただし、第４の構成例では、上記バックアップ領域には、１つのレコードに対して複数のバックアップデータが保存可能となるものとする。

図１２は、レコードファイルの第４の構成例を示す図である。
図１２に示す第４の構成例は、固定長順編成レコードファイルの構成例である。図１２に示す第４の構成例のレコードファイルは、ファイルＩＤで特定されるファイルである。図１２に示すレコードファイルは、レコード領域とバックアップ領域とを有している。上記レコード領域には、複数のレコードが格納される。レコード領域に格納される各レコードは、それぞれレコード番号とレコードデータとにより構成される。つまり、各レコードには、レコード領域内において、レコード番号の記憶領域とレコードデータの記憶領域とが割当てられる。

上記バックアップ領域には、レコード領域における何れかのレコードに対するバックアップレコードが格納される。バックアップ領域に格納される各バックアップレコードは、それぞれレコード番号と世代情報（世代番号）とバックアップデータとにより構成される。つまり、各バックアップレコードには、バックアップ領域内において、レコード番号の記憶領域と世代番号の記憶領域とバックアップデータの記憶領域とが割当てられる。

バックアップレコードのレコード番号は、バックアップしているレコードを示すレコード番号である。バックアップレコードの世代番号は、対応する各レコードに対するバックアップデータの世代を示す情報である。バックアップデータは、対応するレコード番号および世代番号により、どのレコードの何世代前のレコードデータであるかが識別される。すなわち、第４の構成例では、１つのレコードに対して、複数世代のバックアップデータが保存可能となっている。これは、１つのレコードに対して、更新直前（第１世代）のレコードデータだけでなく、複数世代分のレコードデータをバックアップデータとして保存できることを意味している。

また、世代番号には、保存可能な世代の数に応じた上限値を設けても良い。たとえば、第３世代までのバックアップデータを保存する運用形態では、世代番号の上限値は、「３」と設定すれば良い。この場合、各レコードに対して最大３世代分のバックアップデータが保存可能な運用形態となる。なお、以下の説明では、世代番号の上限値が「３」であり、レコードデータの更新ごとにバックアップデータが生成されるものとする。

たとえば、図１２に示すバックアップ領域には、レコード番号「０１」のレコードに対して、世代番号「１」（第１世代）、世代番号「２」（第２世代）及び世代番号「３」（第３世代）の３つのバックアップデータが保存されている。これは、レコード番号「０１」のレコードが少なくとも３回更新されていることを示している。また、図１２に示すバックアップ領域には、レコード番号「０４」のレコードに対して、世代番号「１」（第１世代）及び世代番号「２」（第２世代）の２つのバックアップデータが保存されている。これは、レコード番号「０４」のレコードが２回更新されていることを示している。また、図１２に示すバックアップ領域には、レコード番号「０７」のレコードに対して、世代番号「１」（第１世代）の１つのバックアップデータが保存されている。これは、レコード番号「０７」のレコードが１回更新されていることを示している。

第４の構成例のレコードデータを更新する場合、更新直前のレコードデータが１世代前のバックアップデータ（世代番号「１」のバックアップデータ）としてバックアップ領域に保存される。この際、当該レコードに対するバックアップデータが既にバックアップ領域に存在している場合、それらのバックアップデータに対する世代番号がインクリメント（１世代分古く）される。これにより、当該レコードに対する複数のバックアップデータの世代番号が古い順にセットされる。

また、世代番号に上限値が設定されている場合、世代番号が上限値を超えるバックアップデータは削除される。たとえば、世代番号の上限値が「３」である場合、世代番号が「３」を超えるバックアップデータ（世代番号が「４」以上となるバックアップデータ）は削除される。このような手順により、バックアップ領域には、各レコードに対する複数世代のバックアップデータが保存される。

ここでは、第４の構成例のレコードファイルに対するアクセスの手法としては、上記第３の構成例のレコードファイルに対するアクセスの手法が適用できる。ここでは、第４の構成例のレコードファイルに対するアクセス方法の一例として、ファイルＩＤとレコード番号とを指定するコマンドに応じてレコードデータにアクセスし、「カレントレコード」を指定するコマンドによりバックアップデータにアクセスする運用形態について説明する。
このようなアクセス方法では、たとえば、ファイルＩＤ「０００１」かつレコード番号「０１」を指定することにより、図１２に示すレコード番号「０１」のレコードデータにアクセスすることが可能となる。この際、当該ＩＣカード１は、ファイルＩＤ「０００１」のレコードファイルにおけるレコード番号「０１」のレコードをカレントレコードとする。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。

この状態において、カレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」のレコードファイルにおけるレコード番号「０１」のレコードに対する１世代前（世代番号が「１」）のバックアップデータを当該レコードファイルのバックアップ領域から読み出す。このようなカレントレコードを指定したリードレコードコマンドによりバックアップデータを読出した回数は、たとえば、ワーキングメモリ１３に保持される。なお、カレントレコード指定でなくとも、２度連続してファイルＩＤ「０００１」かつレコード番号「０１」のレコードを指定したリードレコードコマンドを受信した場合も、上記同様に、１世代前のバックアップデータを読み出すようにしても良い。

さらに、続けて同じコマンドを受信した場合、つまり、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０１」のレコードにおける２世代前（世代番号が「２」）のバックアップデータを読み出す。なお、３度連続してファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したリードレコードコマンドを受信した場合も、上記同様に、２世代前のバックアップデータを読み出すようにしても良い。

さらに続けて同じコマンドを受信した場合、つまり、３度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０１」のレコードに対する３世代前（世代番号が「３」）のバックアップデータを読み出す。なお、４度連続してファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したリードレコードコマンドを受信した場合も、上記同様に、３世代前のバックアップデータを読み出すようにしても良い。

ここで、ＩＣカード１は、各レコードに対するバックアップデータが３世代前まで保存される運用形態であるものとする。このような運用形態では、４度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、当該カレントレコードに対する全バックアップデータが読出し済みである。このため、ＣＰＵ１１は、当該コマンドをエラーとして処理するか、あるいは、当該レコードのレコードデータを読み出す処理を行う。前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該カレントレコードに対する全バックアップデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるレコードデータ、および、各世代のバックアップデータを順次循環させて読み出すことが可能となる。

次に、上記第４の構成例のレコードファイルにおけるレコードデータの書換え処理について説明する。
図１３は、第４の構成例のレコードファイルにおけるレコードデータの書換え処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１３０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ１３１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ１３１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ１３２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのレコードデータを書き換えるものと判定する。

指定されたレコードを特定すると、ＣＰＵ１１は、指定されたレコードに対するバックアップが必要か否かを判断する（ステップＳ１３３）。指定レコードに対するバックアップの要否は、種々の設定方法が考えられる。たとえば、各レコードに対するバックアップの要否は、レコードごとに設定しても良いし、レコードファイルごとに設定するようにしても良い。また、書換えコマンドにおけるパラメータでバックアップの要否を指定するようにしても良いし、特定の送信元からの書換えコマンドに対してのみバックアップを行うようにしても良い。

上記判断により指定されたレコードに対するバックアップが必要であると判断した場合、ＣＰＵ１１は、当該レコードのレコードデータをバックアップデータとしてバックアップ領域に保存する処理を行う（ステップＳ１３４〜Ｓ１３６）。
すなわち、ＣＰＵ１１は、まず、バックアップ領域に当該レコードに対する上限数のバックアップデータが保存されているか否かを判断する（ステップＳ１３４）。たとえば、上限数が「３」である場合、ＣＰＵ１１は、世代番号が「３」のバックアップデータが存在するか否かを判断する。上記判断により上限数のバックアップデータが保存されていると判断した場合（ステップＳ１３４、ＹＥＳ）、ＣＰＵ１１は、最も古い世代番号のバックアップデータを削除する（ステップＳ１３５）。このような状態において、ＣＰＵ１１は、レコードデータを最新世代のバックアップデータとして書込み処理を行う（ステップＳ１３６）。すなわち、ＣＰＵ１１は、レコードデータを世代番号「１」のバックアップデータとしてバックアップ領域に書き込む。これとともに、ＣＰＵ１１は、バックアップ領域に存在している当該レコードに対する他のバックアップデータの世代番号をインクリメント（更新）する。

また、上限数のバックアップデータが既に存在する場合、上記ステップＳ１３４〜Ｓ１３６の処理は、最古のバックアップデータに更新前のレコードデータを上書きし、各バックアップデータの世代番号を更新することにより実現するようにしても良い。また、上限数のバックアップデータが存在する場合、当該レコードにおける更新前のレコードデータ及び各世代のバックアップデータを順次次の世代のバックアップデータに上書きすることにより実現しても良い。何れの実現形態であっても、結果として、当該レコードに対する上限数のバックアップデータがバックアップ領域に格納される。

更新前のレコードデータを最新のバックアップデータとして保存すると、ＣＰＵ１１は、当該レコードのレコードデータを受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ１３７）。このようなレコードデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ１３８）、処理を終了する。

なお、上記ステップＳ１３７においてレコードデータの書換えが失敗した場合（たとえば、レコードデータの書換えがリトライできない状態となった場合）、ＣＰＵ１１は、当該レコードの復旧処理として、バックアップ領域に保存した最新のバックアップデータ（更新前のレコードデータ）を再度、当該レコードのレコードデータとして書き込むようにしても良い。このように、当該ＩＣカード１では、レコードデータの書換えが失敗した場合にバックアップ領域に保存したバックアップデータでレコードデータを復旧させる（コマンドの受信前の状態に戻す）機能も実現できる。このような機能によれば、ＩＣカード１としての動作を安定化させることが可能である。

上記のような第４の構成例のレコードファイルに対する書込み処理によれば、あるレコードデータを更新する場合、更新前のレコードデータをバックアップデータとしてバックアップ領域に退避させた後、レコードデータを書き換えられる。また、バックアップ領域には、新しい順に世代番号を付与した複数のバックアップデータが保存される。これにより、更新前のレコードデータを別のレコードとして保存するコマンドを与えたりすることなく、更新前のレコードデータを複数世代分保存しておくことが可能となる。

また、上記のような書込み処理では、上限数のバックアップデータが既に保存されている場合、最古のバックアップデータを削除して、最新のバックアップデータを保存する。これにより、バックアップ領域には、各レコードに対して、新しい順に最大上限数分のバックアップデータが常時保存できる。

次に、上記第４の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図１４は、第４の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１４０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてレコードデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ１４１）。この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ１４１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップデータの読出しを要求するコマンドであるか否かを判定する（ステップＳ１４２）。

バックアップデータの読出を要求する手法には、上述したような様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップデータの読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの読出要求を示すようにしても良い。特定のコマンドの実行手順によりバックアップデータの読出要求を示す形態としては、特定のコマンドが連続して与えられた場合にバックアップデータを読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合にバックアップデータを読み出すようにしても良い。

また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップデータの読出を要求する形態としては、コマンドコードあるいは処理パラメータなどでバックアップデータの読出を指定するようにすれば良い。上記のような運用形態に従って、ＣＰＵ１１は、受信したコマンドがバックアップデータの領域の読出しを要求するコマンドであるか否かを判断するようになっている。

ここでは、図１１に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードのバックアップデータを読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、受信したリードレコードコマンドにおいて読出対象とするレコードが、「カレントレコード」として指定されているか、レコード番号で指定されているかにより、バックアップデータの読出要求であるか否かを判定する（ステップＳ１４２）。

上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップデータの読出しを要求する場合（ステップＳ１４２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコードに対するバックアップデータがバックアップ領域に保存されているか否かを判断する（ステップＳ１４３）。

この判断によりカレントレコードに対するバックアップデータが保存されていると判断した場合（ステップＳ１４３、ＹＥＳ）、ＣＰＵ１１は、当該レコードに対するバックアップデータが読出し処理済みであるか否かを判断する（ステップＳ１４４）。つまり、上記ステップＳ１４４において、上記ＣＰＵ１１は、前回までに受信したリードコマンドによって当該レコードに対する全バックアップデータが読出し済みでないかを判断する。

上記判断によりカレントレコードに対する全バックアップデータが読出し済みでないと判断した場合（ステップＳ１４４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）に対する各バックアップデータを順次読み出す（ステップＳ１４５）。たとえば、上記ＣＰＵ１１は、カレントレコードに対するバックアップデータを読み出すごとに、ワーキングメモリ１３に設けた図示しないカウンタをカウントアップする。連続してカレントレコードを指定するリードレコードコマンドを受けた場合、ＣＰＵ１１は、上記カウンタの値に応じた世代番号のバックアップデータをバックアップ領域から読み出す。

カレントレコードに対するバックアップデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ１４６）。このように、上記ステップＳ１４０〜Ｓ１４６までの処理によって、当該ＩＣカード１では、カレントレコードに対するバックアップデータが読み出される。このような処理を繰り返すことで、当該ＩＣカード１は、カレントレコードに対する複数のバックアップデータを順に読み出すことが可能となっている。

また、上記ステップＳ１４２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ１４２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのレコードデータの読出しを要求するものであると判定する。なお、ファイルＩＤとレコード番号とでカレントレコードを指定するコマンドを受信した場合には、上記ステップＳ１４３へ進むようにしても良い。

受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ１４２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ１４８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、指定されたレコードをカレントレコードとする。

受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのレコードデータを読出す（ステップＳ１４９）。指定されたレコードデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したレコードデータを含むレスポンスデータを送信する（ステップＳ１４６）。

また、ステップＳ１４３でカレントレコードに対するバックアップデータが存在しないと判断した場合（ステップＳ１４３、ＮＯ）、ＣＰＵ１１は、ステップＳ１４９へ進み、カレントレコードに対するレコードデータを読み出す処理を行うようにしても良い。ただし、上記ステップＳ１４３でＮＯと判断される場合は、バックアップデータの読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）に対するバックアップデータが設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ１４７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。

また、上記ステップＳ１４４で全バックアップデータのが読出し済みであると判断した場合（ステップＳ１４４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ１４７）。これは、カレントレコードに対する全バックアップデータが読出し済みとなったことをエラー通知によってＩＣカード１からＩＣカード処理装置２へ通知する仕組みである。

ただし、上記ステップＳ１４４で全バックアップデータが読出し済みであると判断した場合（ステップＳ１４４、ＹＥＳ）、ＣＰＵ１１は、図１４に点線で示すように、ステップＳ１４９へ進み、カレントレコードのレコードデータを読み出すようにしても良い。これは、バックアップデータの読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、カレントレコードにおける各バックアップデータとレコードデータとを順に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードの各バックアップデータとレコードデータとを順に読み出す制御が可能となる。

上記のような第４の構成例のレコードファイルに対する読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのレコードデータを読出し、カレントレコードを指定したリードコマンド（バックアップデータの読出しを要求するコマンド）に対しては、カレントレコードに対するバックアップデータをバックアップ領域から読み出すようになっている。つまり、レコードデータを読み出した後に連続してカレントレコードを指定した読出し要求が与えられる場合、カレントレコードに対する複数のバックアップデータを順に読み出すようになっている。

これにより、バックアップ領域に保存されている特定のレコードに対する複数のバックアップデータを簡単な手順で順に読み出すことができる。すなわち、第４の構成例によれば、ＩＣカード１は、バックアップデータをバックアップ領域に格納する形態であっても、各レコードに対する記憶するレコードデータおよび複数のバックアップデータを容易に管理できる。この結果として、上記ＩＣカードでは、たとえば、取引履歴情報などの更新されることが予測されるデータをメモリ領域を有効に使用しつつ、最新のデータ（レコードデータ）および更新前のデータ（バックアップデータ）を容易に管理できる。

次に、レコードァイルの第５の構成例について説明する。
第５の構成例は、レコード領域内にレコードデータとバックアップデータとを順次保存するレコードファイルの構成例である。第５の構成例のレコードファイルには、レコード領域内の未使用領域にバックアップデータが保存される。すなわち、第５の構成例では、各レコードに対するバックアップデータの記憶領域を予め確保したり、レコードファイル内にレコード領域とは別にバックアップ領域を設けたりするものではない。つまり、第５の構成例では、レコードファイル内にレコードのバックアップデータを保存するための領域を予め確保したり、定義したりする必要がない。この結果として、第５の構成例のレコードファイルでは、効率的にメモリ領域を使用できる。なお、第５の構成例では、１つのレコードに対して１つのバックアップデータが保存されるものとする。

図１５は、レコードファイルの第５の構成例を示す図である。
図１５に示す第５の構成例は、固定長順編成レコードファイルの構成例である。図１５に示す第５の構成例のレコードファイルは、ファイルＩＤで特定される。ファイルＩＤで特定されるレコードファイルは、複数のレコードおよび複数のバックアップレコードが格納されるレコード領域を有している。レコード領域に格納される各レコードおよび各バックアップレコードは、それぞれレコード番号と識別子とデータ本体（レコードデータ或いはバックアップデータ）とにより構成される。すなわち、各レコード及びバックアップレコードには、レコード番号と識別子とデータ本体とを記憶するための記憶領域が割当てられる。

上記識別子は、対応するデータ本体がレコードデータであるかバックアップデータであるかを示す情報である。なお、第５の構成例では、各レコードに対してバックアップデータが１つであることを想定している。このため、上記識別子は、対応するデータ本体がレコードデータあるいはバックアップデータの何れかであることを示す情報である。図１５に示す例では、識別子が「正規」である場合、当該識別子に対応するデータ本体は、対応するレコード番号で示されるレコードのレコードデータである。また、図１５に示す例では、識別子が「退避」である場合、当該識別子に対応するデータ本体は、対応するレコード番号で示されるレコードに対するバックアップデータ（当該レコードの更新前のレコードデータ）である。

すなわち、図１５に示す例では、レコード番号「０１」〜「０７」の各レコードにおける「正規」のレコードデータに続けて、レコード番号「０３」のレコードに対するバックアップデータとレコード番号「０５」のレコードに対するバックアップデータとが記憶されている。これらのバックアップデータは、識別子が「退避」となっていることにより識別される。

第５の構成例では、あるレコードを更新する場合、当該レコードの更新前のレコードデータがバックアップデータとして保存される。バックアップデータは、当該レコード番号と退避であることを示す識別子とに対応づけてバックアップレコードとして記憶される。更新前のレコードデータをバックアップデータとして保存した後（退避した後）、当該レコードのレコードデータ自体が更新される。これにより、最新のレコードデータがレコード領域に記憶されるとともに、最新のレコードデータに更新する直前のデータがバックアップデータとして保存される。

上記のような各レコードのレコードデータには、ファイルＩＤとレコード番号とによりアクセスが可能となっている。たとえば、図１５に示す例では、ファイルＩＤ「０００１」かつレコード番号「０１」を指定することにより、レコード番号「０１」のレコードデータにアクセスすることが可能となっている。同様に、バックアップデータが存在するレコード番号「０３」（又は「０５」）のレコードデータに対しても、ファイルＩＤ「０００１」かつレコード番号「０３」（又は「０５」）を指定することにより、アクセスすることが可能となっている。

また、各レコードに対するバックアップデータ（更新前のレコードデータ）には、所定の手順によりアクセスすることが可能となっている。バックアップデータにアクセスするための手法としては、たとえば、バックアップデータへのアクセスを要求するコマンドを定義しても良いし、コマンドにおける処理パラメータでバックアップデータの領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップデータへのアクセスを行うようにしても良い。

ここでは、カレントレコードを指定するコマンドによりカレントレコードのバックアップデータにアクセスする場合について説明する。
たとえば、ファイルＩＤ「０００１」、かつ、レコード番号「０３」を指定したデータの読出要求コマンド（リードレコードコマンド）を受信したＩＣカード１のＣＰＵ１１は、図１５に示すようなレコード領域からレコード番号が「０３」で、かつ、識別子が「正規」のデータ本体をレコードデータとして読み出す。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」のレコードファイルにおけるレコード番号「０３」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。

この状態において、続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、図１５に示すようなレコード領域からカレントレコードのレコード番号「０３」で、かつ、識別子が「退避（バックアップ）」のデータ本体をバックアップデータとして読み出す。なお、カレントレコードを指定したリードレコードコマンドによりバックアップデータを読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。

また、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、バックアップデータが読出し済みであるためエラーとして処理するか、あるいは、当該レコードのレコードデータを読み出す処理を行う。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおけるバックアップデータが読出し済みであることを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるレコードデータ、および、バックアップデータを交互に読み出すことが可能となる。

次に、上記第５の構成例のレコードファイルにおけるレコードの書換え処理の流れについて説明する。
図１６は、第５の構成例のレコードファイルにおけるレコードの書換え処理を説明するためのフローチャートである。なお、第５の構成例のレコードファイルにおけるレコードの書換え処理は、バックアップデータを保存する処理以外は、上述した第３の構成例のレコードファイルにおけるレコードの書換え処理と同様である。すなわち、図１６に示すステップＳ１６０〜Ｓ１６３及びＳ１６５〜Ｓ１６６は、図１０に示すステップＳ１１０〜Ｓ１１３及びＳ１１５〜Ｓ１１６と同様な処理手順で実現できる。このため、図１６に示すステップＳ１６０〜Ｓ１６３及びＳ１６５〜Ｓ１６６については、詳細な説明を省略するものとする。

すなわち、第５の構成例のレコードファイルを保持しているＩＣカード１が、ＩＣカード処理装置２からバックアップが必要なレコードデータの書換え処理を要求する書換えコマンドを受信したものとする（ステップＳ１６３、ＹＥＳ）。この場合、ＣＰＵ１１は、当該レコードの更新前のレコードデータをバックアップデータとして保存する処理を行う（ステップＳ１６４）。

上記ステップＳ１６４の処理において、ＣＰＵ１１は、当該レコードのレコードデータ（更新前のレコードデータ）を読み出す。当該レコードに対するバックアップデータが保存されていない場合、ＣＰＵ１１は、読み出したレコードデータにレコード番号とバックアップデータであることを示す識別子とを対応づけたバックアップレコードをレコード領域の未使用領域に記憶する。また、既に当該レコードに対するバックアップデータが保存されている場合（つまり、当該レコード番号のバックアップデータが既に存在する場合）、ＣＰＵ１１は、読み出したレコードデータを当該レコード番号のバックアップデータに上書きする。これにより、更新前のレコードデータが当該レコードのバックアップデータとしてレコード領域に保存される。

上記バックアップデータを保存した後、ＣＰＵ１１は、受信した書換えコマンドで指定されるレコードのレコードデータ（対応する識別子が「正規」となっているデータ本体）を新しいレコードデータに書き換える（ステップＳ１６５）。このようなレコードデータの書換えが正常終了すると、ＣＰＵ１１は、受信した書換えコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ１６６）、処理を終了する。なお、上記ステップＳ１６５においてレコードデータの書換えが失敗した場合、ＣＰＵ１１は、上記バックアップデータとして保存した更新前のレコードデータを再度当該レコードのレコードデータとして書き込む当該レコードの復旧処理を行うようにしても良い。

また、上記ステップＳ１６４の処理として、ＣＰＵ１１は、当該レコードのレコードデータに対応づけられている識別子（正規のレコードデータであることを示す情報）をバックアップであることを示す情報に書換えるようにしても良い。この場合、上記ステップＳ１６５の処理としては、ＣＰＵ１１は、新たなレコードデータを、レコード領域における未使用領域、あるいは、既存の当該レコードに対するバックアップデータが記憶されている領域に書き込むようにする。つまり、上記ステップＳ１６４及びＳ１６５の処理としては、識別子の書換えにより更新前のレコードデータをバックアップデータに変更し、新たなレコードデータを書き込むようにしても実現可能である。

上記のように、第５の構成例のレコードファイルに対するレコードデータの書換え処理は、更新前のレコードデータをレコード番号とバックアップである事を示す識別子とに対応づけたバックアップデータとしてレコード領域の未使用領域に保存した後、当該レコードのレコードデータの書換えを行う。これにより、更新前のレコードデータを確実に保存（バックアップ）した状態でレコードデータの書換え処理が実行できる。

次に、上記第５の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図１７は、第５の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。第５の構成例のレコードファイルにおけるレコードに対するデータの読出し処理は、レコード領域におけるレコードデータとバックアップデータとを識別子により特定する以外は、上述した第３の構成例のレコードファイルにおけるレコードに対するデータの読出し処理と同様である。

すなわち、ＩＣカード処理装置２からリードレコードコマンドを受信した場合（ステップＳ１７１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップデータの読出要求であるか否かを判定する（ステップＳ１７２）。バックアップデータの読出要求する手法には、上述したような形態が考えられる。ここでは、バックアップデータの読出要求は、カレントレコードを指定したリードレコードコマンドであり、レコードデータの読出要求は、レコード番号を指定したリードレコードコマンドであるものとする。この場合、ＣＰＵ１１は、受信したリードレコードコマンドが「カレントレコード」を指定しているか否かにより、バックアップデータの読出要求か否かを判断する。

上記判断により受信コマンドがバックアップデータの読出要求である場合（ステップＳ１７２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコードに対するバックアップデータが存在するか否かを判断する（ステップＳ１７３）。これは、カレントレコードのレコード番号で、かつ、識別子がバックアップであるデータが存在するか否かにより判断できる。

上記判断により現在のカレントレコードに対するバックアップデータが存在すると判断した場合（ステップＳ１７３、ＹＥＳ）、ＣＰＵ１１は、当該コマンドの直前のコマンドによる処理として当該バックアップデータが読出し済みか否かを判断する（ステップＳ１７４）。つまり、上記ＣＰＵ１１は、連続してバックアップデータの読出しを要求するコマンドを受信したか否かを判断する。

上記判断によりカレントレコードに対するバックアップデータが読出し済みでないと判断した場合（ステップＳ１７４、ＮＯ）、ＣＰＵ１１は、カレントレコードに対するバックアップデータを読み出す（ステップＳ１７５）。カレントレコードに対するバックアップデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２へ読み出したデータを含むレスポンスデータを送信する（ステップＳ１７６）。このように、上記ステップＳ１７０〜Ｓ１７６の処理によって、当該ＩＣカード１では、カレントレコードのバックアップデータが読み出される。

また、受信したコマンドがカレントレコードを指定するものない場合、つまり、レコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ１７２、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されるファイルＩＤとレコード番号とにより特定されるレコードのレコードデータを読出対象とする（ステップＳ１７８）。上記ＣＰＵ１１は、ファイルＩＤとレコード番号とにより特定されるレコードのレコードデータを読出す（ステップＳ１７９）。ＣＰＵ１１は、読み出したレコードデータを含むレスポンスデータを当該コマンドの送信元であるＩＣカード処理装置２へ送信する（ステップＳ１７６）。

また、カレントレコードに対するバックアップデータが存在しない場合（ステップＳ１７３、ＮＯ）、ＣＰＵ１１は、ステップＳ１７９へ進み、カレントレコードのレコードデータを読み出す。ただし、ステップＳ１７３で「ＮＯ」と判断される場合、ＣＰＵ１１は、ステップＳ１７７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。

また、バックアップデータが直前のコマンドによって読出し済みであると判断した場合（ステップＳ１７４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ１７７）。これは、連続してカレントレコードに対するバックアップデータの読出しを行わないようにするための仕組みである。

ただし、上記ステップＳ１７４でバックアップデータが直前のコマンドによって読出し済みであると判断した場合（ステップＳ１７４、ＹＥＳ）、ＣＰＵ１１は、ステップＳ１７９へ進み、カレントレコードのレコードデータを読み出す処理を行うようにしても良い。この場合、カレントレコードを指定したリードレコードコマンドが連続して与えられれば、ＣＰＵ１１は、カレントレコードのバックアップデータとレコードデータとを交互に読み出す。

上記のような第５の構成例のレコードファイルに対する読出処理では、ＩＣカード１は、レコード番号を指定したリードコマンドに対しては、当該レコードのレコードデータを読出し、カレントレコードを指定したリードコマンド（バックアップデータの読出しを要求するコマンド）に対しては、当該レコード（カレントレコード）に対するバックアップデータを読み出す。これにより、第５の構成例のレコードファイルでは、効率的にメモリ領域を使用することができ、レコードデータとバックアップデータとの管理も容易化できる。この結果として、上記ＩＣカード１では、たとえば、取引履歴情報などの更新されることが予測されるデータについても、効率的な保存および管理が実現できる。

次に、レコードァイルの第６の構成例について説明する。
第６の構成例は、第５の構成例の変形例である。第６の構成例は、第５の構成例と同様に、レコード領域内にレコードデータとバックアップデータとを順次保存するレコードファイルの構成例である。ただし、第６の構成例のレコードファイルでは、１つのレコードに対して複数のバックアップデータを保存するものである。

図１８は、レコードファイルの第６の構成例を示す図である。
図１８に示す第６の構成例は、図１５に示す第５の構成例のレコードファイルと同様な構成を有している。ただし、第６の構成例のレコードファイルでは、１つのレコードに対して複数のバックアップデータを保存するものとする。このため、図１８に示す第６の構成例のレコードファイルでは、レコードデータおよびバックアップデータとしてのデータ本体に対応する識別子が各データ本体の世代を示す情報となっている。

なお、１つのレコードに対しては、所定の上限数のバックアップデータが保存可能であるものとする。たとえば、ここでは、第４の構成例と同様に、１つのレコードに対しては、３つのバックアップデータが保存可能であるものとする。この場合、識別子は、４通りの状態を示す情報であれば良い。すなわち、識別子は、レコードデータあるいは３つのバックアップデータのどれであるかを示す情報が用いられる。

図１８に示す例では、識別子は、「０」、「１」、「２」、「３」の何れかの値となっている。図１８に示す例では、識別子「０」が正規のレコードデータであることを示し、識別子「１」が１世代前のバックアップデータであることを示し、識別子「２」が２世代前のバックアップデータであることを示し、識別子「３」が３世代前のバックアップデータであることを示しているものとする。このような識別子によれば、各レコードに対して最大３つのバックアップデータが保存でき、かつ、各バックアップデータの世代も示すことができる。

図１８に示す例は、図１２に示す各データを第６の構成例のレコードファイルに格納した状態を示している。第６の構成例のレコードファイルは、バックアップデータがレコード領域内に保存される点が、第４の構成例のレコードファイルと異なっている。このため、第６の構成例のレコードファイルにおける各レコードのレコードデータおよび複数のバックアップデータへのアクセス制御は、第４の構成例のレコードファイルに対するアクセス制御と類似している。

たとえば、第６の構成例のレコードファイルに対するレコードの書換え処理は、バックアップデータを保存する領域がレコード領域内であることを除けば、図１３を参照して説明した第４の構成例のレコードファイルに対するレコードの書換え処理と同様な手順で実現できる。また、第６の構成例のレコードファイルに対するレコードの書換え処理では、既存の各世代のバックアップデータだけでなく、更新前のレコードデータも、対応する識別子を更新（インクリメント）するだけで、１世代前のバックアップデータとして保存できる。

また、第６の構成例のレコードファイルに対するデータの読出し処理は、レコードデータおよび各世代のバックアップデータを識別子により識別してレコード領域内から読み出されることを除けば、図１４を参照して説明した第４の構成例のレコードファイルに対するデータの読出し処理と同様な手順で実現できる。

上記のような第６の構成例のレコードァイルによれば、１つのレコードに対して複数のバックアップデータを保存する形態であっても、各レコードごとにバックアップデータの記憶領域を予め確保したり、レコードファイル内にレコード領域とは別にバックアップ領域を設けたりする必要がない。すなわち、第６の構成例のレコードファイルでは、１つのレコードに対して複数のバックアップデータを保存する場合であっても、効率的にメモリ領域を使用つつ、各レコードに対するレコードデータと複数のバックアップデータとを容易に管理できる。

また、上述した第１乃至第６の構成例のレコードファイルに対する更新処理あるいは読出処理は、種々の変形が可能である。
以下、上述した実施の形態に対する変形例について説明する。
まず、第１の変形例として、各レコード毎に、全バックアップデータを一括して読み出す処理例について説明する。

すなわち、第２、第４あるいは第６の構成例のレコードファイルでは、に対する読出処理では、図８、図１２あるいは図１８に示すように、１つのレコードデータに対して複数のバックアップデータが保存可能である。このようなレコードファイルに対しては、各レコード毎に全バックアップデータを一括して読み出したい場合があると考えられる。たとえば、履歴情報としての複数世代のバックアップデータは、一括して読み出せる仕組みを設けることにより、効率的な運用が可能になると考えらえる。

上記第２、第４、第６の構成例のレコードファイルに関する説明では、各レコードごとに複数世代のバックアップデータを順次読み出す処理について説明している。これに対して、各レコード毎に全バックアップデータの領域のデータを一括して読出す処理は、たとえば、リードレコードコマンドにおいて、カレントレコードに対する全バックアップデータの一括読出しを要求するパラメータを定義しておくことにより実現できる。この場合、ＣＰＵ１１は、カレントレコードに対する全バックアップデータの一括読出しを指定するパラメータがセットされたコマンドを受信すると、カレントレコードに対する全バックアップデータを一括して読み出し、一括して読み出した全バックアップデータをレスポンスデータとして出力する。

また、各レコードに対する複数のバックアップデータを順に読み出す必要がない運用形態もありうる。このような運用形態では、常に各レコードに対する全バックアップデータを読み出すような仕様としても良い。すなわち、ＩＣカードは、バックアップデータの読出しを要求するコマンドに対して、特定のレコード（たとえば、カレントレコード）に対する全バックアップデータを読み出すようにしても良い。

次に、第２の変形例として、１つのレコードファイルにおける全レコードの全バックアップデータを一括して読み出す処理例について説明する。

上記第１乃至第６の構成例のレコードファイルでは、実際の運用形態として、互いに関連する複数のデータがそれぞれレコードとして格納される形態が多いと考えられる。このような運用形態では、１つのレコードファイルにおける全バックアップデータ（全レコードの全バックアップデータ）を一括して読み出せる仕組みを設けることにより、効率的な運用が可能となることもあると考えられる。

上記第１乃至第６の構成例のレコードファイルに関する説明では、特定のレコードに対するバックアップデータの読出し処理について説明している。これに対して、１つのレコードファイルにおける全レコードの全バックアップデータを一括して読出す処理は、たとえば、リードコマンドにおいて、レコードファイルにおける全バックアップデータ（全レコードの全バックアップデータ）を読み出すことを指定するパラメータを定義しておくことにより実現できる。この場合、ＣＰＵ１１は、特定のレコードファイル（たとえば、カレント状態のレコードファイル）における全バックアップデータの一括読出しを指定するパラメータがセットされたコマンドを受信すると、当該レコードファイル内の全バックアップデータを一括して読み出し、一括して読み出した全バックアップデータをレスポンスデータとして出力する。これにより、ＩＣカード１は、第１乃至第６の構成例のようなレコードファイルに対しても、当該ファイル内の全レコードに対する全バックアップデータを一括して読み出す処理が実現できる。

次に、第３の変形例として、レコードデータの領域のデータ異常で読み出しが失敗した場合の処理例について説明する。
上述したレコードの書換え処理では、既存のレコードデータをバックアップデータとして保存した後、当該レコードデータの書換えが失敗した場合、バックアップデータとして保存したデータをレコードデータとして再度書き込むという復旧処理について説明している。このような処理と同様に、レコードデータの読出処理においても、メモリ異常などのデータ異常によりレコードデータが読み出せない場合、当該レコードデータに対する最新のバックアップデータ（前回の更新直前のデータ）で当該レコードデータを復旧させるようにすることが可能である。

たとえば、図５のステップＳ２９、図８のステップＳ４９、図１１のステップＳ１２９、図１４のステップＳ１４９、あるいは、図１７のステップＳ１７９の処理において、データ異常によりレコードデータの読出に失敗した場合、ＩＣカード１のＣＰＵ１１は、最新のバックアップデータをレコードデータとして書き込むようにすれば良い。この場合、ＣＰＵ１１は、読出処理の結果として、エラー通知を行うようにしても良いし、レコードデータに書込んだデータを出力するようにしても良い。

また、上記のようなレコードデータの復旧処理は、ＩＣカード処理装置２からの復旧を要求するコマンドに応じて実行するようにしても良い。すなわち、ＩＣカード処理装置２からレコードデータの読出を要求するコマンドに対して当該レコードデータの領域のデータ異常で読出に失敗した場合、ＩＣカード１は、当該レコードデータがデータ異常である旨をエラー通知とともに出力する。その後、ＩＣカード処理装置２からのレコードデータの復旧を要求するコマンドを受信した場合、ＩＣカード１は、上記のようなレコードデータの復旧処理を実行する。言い換えれば、ＩＣカード処理装置２は、ＩＣカード１からデータ異常によるレコードデータの読出に失敗のエラー通知を受信した場合、当該レコードデータの復旧を要求するコマンドを当該ＩＣカード１に与えることにより、データ異常となったレコードデータを復旧させることができる。

また、ＩＣカード１は、上記のような読出処理においてレコードデータのデータ異常が発見された場合、レコードデータを読み出す代りに、当該レコードデータに対する最新のバックアップデータ（前回の更新直前のレコードデータ）を読み出すするようにしても良い。この場合、ＩＣカード１は、読み出したデータとともに、レコードデータの代りに最新のバックアップデータを読み出した事を通知するようにする。これにより、レコードデータの領域がメモリ異常などにより使用不能となった場合であっても、レコードデータが異常であることを通知するとともに、バックアップデータをレコードデータの代わりとして出力（使用）することが可能となる。

Ｃ…本体、Ｍ…モジュール、１…ＩＣカード、１ａ…ＩＣチップ、２…ＩＣカード処理装置、１１…ＣＰＵ、１２…プログラムメモリ、１３…ワーキングメモリ、１４…データメモリ、１５…通信制御部、１６…電源部、１７…インターフェース、２１…制御装置、２２…カードリーダライタ。

Claims (15)

1. 外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置において、
   レコードデータを記憶するレコード領域と前記レコード領域に記憶されるレコードデータに対するバックアップデータを記憶するデータ退避領域とを有するレコードファイルを記憶する記憶手段と、
   前記外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、前記レコード領域に記憶されている前記レコードデータをバックアップデータとして前記データ退避領域に保存するデータ退避手段と、
   前記データ退避手段により前記データ退避領域にバックアップデータを保存した場合、前記レコード領域に記憶されているレコードデータを書き換える書換え手段と、
   を有することを特徴とする携帯可能電子装置。
2. 外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置において、
   複数のレコードデータを順次格納するレコード領域を有するレコードファイルを記憶する記憶手段と、
   前記外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、書換え前の当該レコードデータを当該レコードファイルにおけるレコード領域の未使用領域にバックアップデータとして保存するデータ退避手段と、
   前記データ退避手段により書換え前のレコードデータをバックアップデータとして保存した場合、当該レコードファイルのレコード領域に記憶されているレコードデータを書き換える書換え手段と、
   を有することを特徴とする携帯可能電子装置。
3. さらに、前記外部装置から前記レコードファイルにおけるレコードデータに対するバックアップデータの読出しを要求するコマンドが与えられた場合、当該コマンドで指定されるレコードデータに対するバックアップデータを読み出す読出手段を有する、
   ことを特徴とする前記請求項１又は２の何れかに記載の携帯可能電子装置。
4. 前記データ退避手段は、各バックアップデータに退避した順序を示す世代情報を付加して保存する、
   ことを特徴とする前記請求項１又は２の何れかに記載の携帯可能電子装置。
5. 前記データ退避手段は、前記レコードデータに対するバックアップデータの保存に伴って既存のバックアップデータを削除する場合、各バックアップデータに付加されている世代情報により特定される最古のバックアップデータを削除する、
   ことを特徴とする前記請求項４に記載の携帯可能電子装置。
6. 前記データ退避手段は、バックアップデータとして保存すべきレコードデータに対する既存のバックアップデータが所定の上限数に達している場合、当該レコードデータに対するバックアップデータのうち最古のバックアップデータを削除する、
   ことを特徴とする前記請求項４に記載の携帯可能電子装置。
7. 前記外部装置から前記レコードファイルにおける特定のレコードデータに対するバックアップデータの読出しを要求するコマンドが連続して与えられる場合、当該レコードデータに対応する各バックアップデータを退避した順序を示す情報に従って順次読み出す読出手段を有する、
   ことを特徴とする前記請求項４に記載の携帯可能電子装置。
8. 前記外部装置から前記レコードファイルにおける特定のレコードデータに対する全バックアップデータの読出しを要求するコマンドが与えられる場合、当該レコードデータに対応する全バックアップデータを読み出す読出手段を有する、
   ことを特徴とする前記請求項４に記載の携帯可能電子装置。
9. 前記外部装置から前記レコードファイルにおける全バックアップデータの読出しを要求するコマンドが与えられた場合、当該レコードファイルに記憶されている全バックアップデータを読み出す読出手段を有する、
   ことを特徴とする前記請求項４に記載の携帯可能電子装置。
10. さらに、前記書換え手段により前記レコードデータの書換えに失敗した場合、前記データ退避手段により保存したバックアップデータを前記レコードデータとして書き込む復旧手段を有する、
    ことを特徴とする前記請求項１又は２の何れかに記載の携帯可能電子装置。
11. さらに、前記読出手段による前記レコードデータの読出しが失敗した場合、当該レコードデータに対するバックアップデータを前記レコードデータとして書き込む復旧手段を有する、
    ことを特徴とする前記請求項３に記載の携帯可能電子装置。
12. さらに、前記読出手段による前記レコードデータの読出しが失敗した場合、当該レコードデータに対するバックアップデータを前記レコードデータとして読み出す処理手段を有する、
    ことを特徴とする前記請求項３に記載の携帯可能電子装置。
13. 前記処理手段は、前記レコードデータの代わりに当該レコードデータに対するバックアップデータを読出した場合、読み出したバックアップデータと共に、当該レコードデータが読出し異常のためレコードデータの代りにバックアップデータを読み出した事を示す応答を出力する、
    ことを特徴とする前記請求項１２に記載の携帯可能電子装置。
14. 携帯可能電子装置におけるデータ管理方法であって、
    レコードデータを記憶するレコード領域と前記レコード領域に記憶されるレコードデータに対するバックアップデータを記憶するデータ退避領域とを有するレコードファイルを記憶部に記憶し、
    外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、前記レコード領域に記憶されている前記レコードデータをバックアップデータとして前記データ退避領域に保存し、
    前記データ退避領域にバックアップデータを保存した後に、前記レコード領域に記憶されているレコードデータを書き換える、
    ことを特徴とする携帯可能電子装置におけるデータ管理方法。
15. 携帯可能電子装置におけるデータ管理方法であって、
    複数のレコードデータを順次格納するレコード領域を有するレコードファイルを記憶部に記憶し、
    外部装置から前記レコードファイルにおけるレコードデータの書換えを要求するコマンドが与えられた場合、書換え前の当該レコードデータを当該レコードファイルにおけるレコード領域の未使用領域にバックアップデータとして保存し、
    当該レコードファイル内に書換え前のレコードデータをバックアップデータとして保存した後に、当該レコードファイルのレコード領域に記憶されているレコードデータを書き換える、
    ことを特徴とする携帯可能電子装置におけるデータ管理方法。

Images