携帯可能電子装置および携帯可能電子装置におけるデータ管理方法
【課題】 擬似的な２次元配列ファイルに最新のデータと更新前の複数のデータ（複数世代のデータ）を容易に保存しておくことができ、擬似的な２次元配列ファイルに格納されている複数のバックアップデータを簡単な手順で順に読み出すことができるＩＣカードを提供できる。
【解決手段】 ＩＣカード内のデータメモリに記憶されているレコードのデータを更新する場合に、当該レコードのデータ領域に記憶されているデータをバックアップ領域に退避させ、最新のデータとなる書換えデータを当該レコードのデータとしてのデータ領域に書き込む。このようなレコードをレコード番号で指定したリードコマンドに対しては、当該レコードのデータ領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンドに対しては、カレントレコードのバックアップ領域に記憶されているデータを読み出すようにしたものである。
【解決手段】 ＩＣカード内のデータメモリに記憶されているレコードのデータを更新する場合に、当該レコードのデータ領域に記憶されているデータをバックアップ領域に退避させ、最新のデータとなる書換えデータを当該レコードのデータとしてのデータ領域に書き込む。このようなレコードをレコード番号で指定したリードコマンドに対しては、当該レコードのデータ領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンドに対しては、カレントレコードのバックアップ領域に記憶されているデータを読み出すようにしたものである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、個人情報あるいは取引情報などが記憶されているＩＣチップが内蔵されているＩＣカードあるいはＩＣタグなどの携帯可能電子装置、および、上記携帯可能電子装置におけるデータ管理方法などに関する。
【背景技術】
【０００２】
近年、ＩＣカードなどの携帯可能電子装置は、様々な用途に利用されている。このようなＩＣカードには、使用用途に応じた個人情報や金銭的な取引情報などの種々のデータが記憶される。上記のようなデータは、通常、ＩＣカード内に設けられているＥＥＰＲＯＭやフラッシュＲＯＭなどの不揮発性メモリに書込まれる。また、ＩＣカードは、外部装置からのコマンドに応じて不揮発性メモリへのデータ書込み処理などを実行するようになっている。
【０００３】
また、一般的な接触式あるいは非接触式ＩＣカードでは、国際標準規格であるＩＳＯ／ＩＥＣ７８１６−４に規定されている形式でデータを取り扱う。ＩＳＯ／ＩＥＣ７８１６−４では、ＩＣカード内の不揮発性メモリ上に定義されたＥＬＥＭＥＮＴＡＲＹ ＦＩＬＥ（ＥＦ）と呼ばれるファイルにデータを記録する。また、ＩＳＯ／ＩＥＣ ７８１６−４では、種々の形式のＥＦが規定されている。ＩＳＯ／ＩＥＣ ７８１６−４で規定されているＥＦのうち一般的に使用されるのは、レコード形式のＥＦである。ＩＳＯ／ＩＥＣ ７８１６−４には、レコード形式のＥＦとして、次の３種類の形式が規定されている。
【０００４】
（１）固定長順編成レコードファイル
（２）可変長順編成レコードファイル
（３）固定長循環順編成レコードファイル
上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルのＥＦは、ファイルＩＤ及びレコード番号により１つのデータの記録場所（領域）が確定する。従って、上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルのＥＦに対して、データの読み出し、データの書き込み、若しくは、データの書き換えを行う場合、指定されたファイルＩＤ及びレコード番号により特定される領域に対して、書き込み、若しくは、書き換えなどを行う。
【０００５】
一方、固定長循環順編成レコードファイルには、データが順次追記される構成となっている。このような固定長循環順編成レコードファイルでは、一般的に、データを追記する毎にデータに対するレコード番号が付け替えられる。即ち、固定長循環順編成レコードファイルでは、順次蓄積される複数のデータに対して、新しい順（若しくは古い順）にレコード番号が割り当てられる。
従来のＩＣカードにおいては、取引履歴情報の様に、取引処理の都度データの追加が発生する様なデータは、固定長循環順編成レコードファイルに格納され、それ以外のデータは、固定長または可変長順編成レコードファイルに格納されるのが一般的である。
【０００６】
しかしながら、ＩＣカードの運用形態によっては、ＥＦ内にレコード番号で管理された複数のレコードに複数のデータを記憶させるとともに、あるレコードのデータが更新（書き換え）された後に更新前のデータを参照したいといった要求がある。
【０００７】
この様な要求を実現するには、従来のＩＣカードでは、各データ毎に、固定長循環順編成レコードファイルを個別に作成したり、管理したりする必要がある。この場合、同一ＥＦ内でのレコード管理に比べ使い勝手の悪いものとなってしまう。また、一般的な運用形態では、ＩＣカード内のＥＦは、発行処理後に追加したり、削除したりすることが出来ないものが多い。このようなＩＣカードでは、発行処理後に、上記のようなデータ管理を実現するのが難しいという問題もある。
【非特許文献１】ＩＳＯ／ＩＥＣ ７８１６−４
【発明の開示】
【発明が解決しようとする課題】
【０００８】
この発明の一形態は、データの蓄積および読出しを効率的に行うことができる携帯可能電子装置および携帯可能電子装置におけるデータ管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
この発明の一形態としての携帯可能電子装置は、外部装置から与えられるコマンドに応じて処理を行うものにおいて、１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードを記憶する記憶手段と、前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新する更新手段と、前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す読出手段とを有する。
【００１０】
この発明の一形態としての携帯可能電子装置におけるデータ管理方法は、外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置における方法であって、前記外部装置から１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードのデータの更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新し、前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す。
【発明の効果】
【００１１】
この発明の一形態によれば、データの蓄積および読出しを効率的に行うことができる携帯可能電子装置および携帯可能電子装置におけるデータ管理方法を提供できる。
【発明を実施するための最良の形態】
【００１２】
以下、この発明に係る実施の形態について図面を参照しつつ説明する。
図１は、この発明の実施の形態に係る携帯可能電子装置としてのＩＣカード１およびＩＣカード１を含むＩＣカードシステムの構成例を示すブロック図である。
上記ＩＣカード１は、外部装置としてのＩＣカード処理装置２からの電源供給により動作可能な状態となる。動作可能となったＩＣカード１は、上記ＩＣカード処理装置２からのコマンドに応じて種々の処理を行う。上記ＩＣカード処理装置２は、ＩＣカード１を動作させるための電源を供給するとともに、当該ＩＣカード１に対して種々の処理を要求するコマンドを供給する。上記ＩＣカード処理装置２がＩＣカード１に対して供給するコマンドは、用途あるいは運用形態などに応じた処理を要求するものである。
【００１３】
また、上記ＩＣカード１は、アンテナあるいは無線通信部等により上記ＩＣカード処理装置２と非接触の状態で無線通信を行う非接触式の携帯可能電子装置（非接触式ＩＣカード）であっても良し、上記ＩＣカード処理装置２と物理的に接触して通信を行う接触式の携帯可能電子装置（接触式ＩＣカード）であっても良い。さらには、上記ＩＣカード１は、非接触式ＩＣカードとしての通信機能と接触式ＩＣカードとしての通信機能とを有する複合型のＩＣカード（デュアルインターフェースＩＣカード）であっても良い。なお、この実施の形態では、主に、非接触式ＩＣカードを想定して説明する。非接触式ＩＣカードと接触式ＩＣカードとはＩＣカード処理装置２との通信方式等が異なるだけである。このため、以下に説明する実施の形態は、接触式ＩＣカードにも同様に適用できる。
【００１４】
上記ＩＣカード１の構成例について説明する。
図１に示すように、上記ＩＣカード１は、ＣＰＵ１１、プログラムメモリ１２、ワーキングメモリ１３、データメモリ１４、通信制御部１５、電源部１６、および、インターフェース（アンテナあるいはコンタクト部）１７などを有している。
また、上記ＩＣカード１は、カード状の本体Ｃにより構成される。上記ＩＣカード１を形成するカード状の本体Ｃには、１つ（あるいは複数）のＩＣチップ１ａとインターフェース１７とが埋設される。上記ＩＣチップ１ａは、ＣＰＵ１１、プログラムメモリ１２、ワーキングメモリ１３、データメモリ１４、通信制御部１５および電源部１６などを有している。上記ＩＣチップ１ａは、上記インターフェース１７に接続された状態でモジュール化され、当該ＩＣカード１を形成するカード状の本体Ｃ内に埋設される。たとえば、図２は、非接触式ＩＣカード全体の構成例を示す図である。図２に示す非接触式ＩＣカードは、カード状の本体Ｃを有している。この本体Ｃ内には、図２に点線で示すように、１つ（あるいは複数）のＩＣチップ１ａとインターフェース１７としてのアンテナとを有するモジュールＭが埋め込まれている。
【００１５】
上記ＣＰＵ１１は、ＩＣカード１全体の制御を司るものである。上記ＣＰＵ１１は、上記プログラムメモリ１２あるいはデータメモリ１４に記憶されている制御プログラムおよび制御データなどに基づいて動作する。たとえば、上記ＣＰＵ１１は、上記プログラムメモリ１２に記憶されている基本的な動作を司る制御プログラムを実行することにより、外部装置から与えられるコマンドに応じた処理を実行する。これにより、外部装置から上記データメモリ１４へのデータの書込みを要求するコマンドが与えられれば、上記ＣＰＵ１１は、上記データメモリ１４へのデータの書き込み処理を実行する。また、外部装置から上記データメモリ１４に記憶されているデータの読み出しを要求するコマンドが与えられれば、上記ＣＰＵ１１は、上記データメモリ１４からのデータの読み出し処理を実行する。さらに、上記ＣＰＵ１１は、当該ＩＣカード１の用途などに応じてインストールされる処理プログラムを実行することにより、用途に応じた処理を実現するようになっている。
【００１６】
上記プログラムメモリ１２は、読み出し専用のメモリ（ＲＯＭ：リードオンリーメモリ）により構成される。上記プログラムメモリ１２には、予め基本動作を司る制御プログラムおよび制御データなどが記憶されている。上記プログラムメモリ１２には、予め当該ＩＣカード１の仕様に応じた制御プログラム及び制御データが記憶される。たとえば、上記ＣＰＵ１１は、上記プログラムメモリ１２に記憶される制御プログラムにより外部から与えられるコマンドに応じた処理を実現する。
【００１７】
上記ワーキングメモリ１３は、揮発性のメモリ（ＲＡＭ；ランダムアクセスメモリ）により構成される。上記ワーキングメモリ１３は、データを一時保管するバッファメモリとして機能する。例えば、上記ワーキングメモリ１３には、ＩＣカード処理装置（外部装置）２との通信処理において、送受信されるデータが一時的に保管される。また、上記ワーキングメモリ１３には、種々の書込みデータなどを一時的に保持するメモリとしても利用される。
【００１８】
上記データメモリ（不揮発性メモリ）１４は、データの書き込みが可能な不揮発性のメモリである。上記データメモリ１４は、例えば、ＥＥＰＲＯＭあるいはフラッシュメモリなどにより構成される。上記データメモリ１４には、当該ＩＣカード１の使用目的に応じた種々の情報が記憶される。
たとえば、当該ＩＣカードの使用目的に応じたアプリケーション（処理プログラムおよび運用データなど）は、上記データメモリ１４に書込まれる。当該ＩＣカード１が複数の使用目的に使用される場合、上記データメモリ１４には、各使用目的に応じた複数のアプリケーションが記憶される。また、当該ＩＣカード１の使用目的に応じたアプリケーションは、上記データメモリ１４上に定義された使用目的ごとのプログラムファイル（ＤＦ；Dedicated File）およびデータファイル（ＥＦ;Elementary File）などの各ファイルに記憶される。このようなファイル構造は、たとえば、ＩＳＯ／ＩＥＣ７８１６−４に基づくものである。なお、各種のデータを記憶するためのデータファイル（ＥＦ）の構成例については、後で詳細に説明するものとする。
【００１９】
上記通信制御部１５は、上記インターフェース１７を介して外部装置（たとえば、ＩＣカード処理装置２）とのデータ通信を制御するものである。たとえば、当該ＩＣカードが非接触型のＩＣカードであれば、外部装置からデータを受信する場合、上記通信制御部１５は、インターフェース１７としてのアンテナにより受信した電波としての送信データを復調し、復調した信号を上記ＣＰＵ１１に供給する。また、外部装置へデータを送信する場合、上記通信制御部１５は、上記ＣＰＵ１１から与えられるデータを変調し、変調したデータを上記インターフェース１７としてのアンテナにより電波として発信する。なお、接触式ＩＣカードでは、インターフェース１７として、アンテナの代わりに、外部装置の接触端子部と物理的・電気的に接触するコンタクト部を介して外部装置とのデータ通信を行う。
【００２０】
上記電源部１６は、当該ＩＣカード１の各部を動作させるための上記インターフェース１７を介して受信する電力およびクロックパルスを供給する。たとえば、当該ＩＣカードが非接触型のＩＣカードであれば、上記電源部１６は、上記インターフェース１７としてのアンテナにより受信した電波から電力およびクロックパルスを生成し、当該ＩＣカード内の各部に供給するようになっている。また、上記電源部１６からの電力供給により起動した場合、上記ＣＰＵ１１は、当該ＩＣカード１の処理状態をリセットする処理を行うようになっている。なお、当該ＩＣカード１が接触型のＩＣカードであれば、上記電源部１６はインターフェース１７を介して外部装置から直接的に供給される電力およびクロックパルスにより各部へ供給するようになっている。
【００２１】
次に、上記ＩＣカード処理装置２について説明する。
上記ＩＣカード処理装置２は、図１に示すように、制御装置２１およびカードリーダライタ２２を有している。上記制御装置２１は、パーソナルコンピュータ（ＰＣ）などにより構成される。上記制御装置２１は、ＣＰＵなどの演算処理部、ＲＡＭ、ＲＯＭ、不揮発性メモリおよびハードディスクドライブなどの各種メモリ、通信インターフェースなどの各種インターフェースなどにより構成される。上記制御装置２１では、上記演算処理部がメモリに記憶されている各種の制御プログラムを実行することにより各種の処理を実現している。また、上記制御装置２１は、ＩＣカード１とのデータ通信を行う上記カードリーダライタ２２とのデータの入出力を行うようになっている。
【００２２】
たとえば、上記制御装置２１には、上記ＩＣカード１を用いた各種の処理に応じた制御プログラムが予め記憶されている。上記制御装置２１では、上記のような制御プログラムを実行することにより上記ＩＣカード１を用いた各種の処理を実行する。たとえば、上記ＩＣカード１を用いた各種の処理において、上記制御装置２１は、所定のコマンドを所定の手順で供給する。上記制御装置２１では、上記のような各コマンドに対するＩＣカード１からの各レスポンス（コマンドに対する処理結果等を示す情報）に基づいて各種の処理を行うようになっている。
【００２３】
上記カードリーダライタ２２は、上記ＩＣカード１とのデータ通信を行う通信手段として機能する。上記カードリーダライタ２２は、上記ＩＣカード１の通信方式に応じた通信方式によるデータ通信を行うためのものである。つまり、上記カードリーダライタ２２を介して制御装置２１は、上記ＩＣカード１とのデータ通信を実現している。
【００２４】
上記ＩＣカード１が非接触型のＩＣカードである場合、上記カードリーダライタ２２は、上記ＩＣカード１との無線によるデータ通信を行うためのアンテナおよび通信制御部（変復調回路等）などにより構成される。非接触型のＩＣカード１へデータを送信する場合、上記カードリーダライタ２２では、通信制御部により上記制御装置２１から与えられる送信データを変調し、変調した信号を電波としてアンテナにより発信する。また、非接触型のＩＣカード１からデータを受信する場合、上記カードリーダライタ２２では、アンテナにより受信した電波としての信号を通信制御部により復調し、復調したデータを受信データとして上記制御装置２１へ供給する。また、上記カードリーダライタ２２では、上記のようなデータの送受信とともに、上記ＩＣカード１を動作させるための電源およびクロックパルスとなる電波をアンテナにより発信するようになっている。
【００２５】
また、上記ＩＣカード１が接触型のＩＣカードである場合、上記カードリーダライタ２２は、ＩＣカード１と物理的に接触してデータ通信を行うためのコンタクト部および通信制御部などにより構成される。接触型のＩＣカードとのデータの送受信を行う場合、上記カードリーダライタ２２では、上記コンタクト部がＩＣカード１側に設けられているコンタクト部と物理的に接触して各種のデータ通信を行う。また、上記カードリーダライタ２２では、ＩＣカード１に物理的に接触しているコンタクト部を介して当該ＩＣカード１に対して電力およびクロックパルスを供給するようになっている。
【００２６】
次に、上記データメモリ１４に記憶されるファイルについて説明する。
本実施例では、上述したようにデータメモリ１４内の各ファイルがＩＳＯ／ＩＥＣ ７８１６で規定されているファイル構造となっているものとする。ＩＳＯ／ＩＥＣ ７８１６では、ＭＦ（Master File）、ＤＦ（Dedicated File）、ＥＦ（Elementary File）などからなる階層構造のファイル構成が規定されている。ＭＦは、階層構造の最上位に位置するファイルであり、ＭＦの下層にＤＦあるいはＥＦが設けられる。ＤＦは、例えば、アプリケーションごとに設定されるファイルであり、当該アプリケーションで利用するデータを格納するためのデータファイルとしてのＥＦが下層に設けられる。各ＥＦは、それぞれ実データを記憶するためのデータファイルである。また、実データは、データファイル内において、各レコードごとに記憶される。各レコードには、それぞれレコード番号が与えられる。
【００２７】
上記のような各ファイルは、それぞれが図示しない管理テーブルに記憶される定義情報により定義される。たとえば、上記のようなデータファイルとしてのＥＦは、図示しない管理テーブルに記憶されるＥＦ定義情報により定義される。ＥＦ定義情報では、当該ＥＦを特定するための情報として、ファイルＩＤ、データメモリ１４における先頭アドレス、および、データサイズなどが定義される。
【００２８】
また、ＩＳＯ／ＩＥＣ ７８１６で規定されているデータファイル（ＥＦ）には、種々の形式がある。たとえば、ＩＳＯ／ＩＥＣ ７８１６には、ＥＦの形式として、固定長順編成レコードファイル、可変長順編成レコードファイル、固定長循環順編成レコードファイルなどがある。
【００２９】
上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルは、複数のデータを格納するための複数のレコード領域（以下、単にレコードとも称する）が設定可能である。たとえば、１つのファイルに複数のデータを格納したい場合、データファイルには、複数のデータに対応する複数のレコードに各データが格納される。複数のレコードを有するファイルでは、ファイルＩＤ及びレコード番号により各レコードが特定される。たとえば、上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルの特定のレコードに対して、データの読み出し、データの書き込み、若しくは、データの書き換えを行う場合、ＩＣカード処理装置２は、書き込み、書き換え、若しくは、読出しなどを要求するコマンドにおいて、ファイルＩＤ及びレコード番号によりレコードを指定する。
【００３０】
また、アクセス対象とするレコードを指定するには、各種のコマンドにおいて、カレントレコードを指定することも可能である。カレントレコードとは、カレント状態とするレコードである。カレントレコードを示す情報（レコードポインタ）は、常時、ワーキングメモリなどに格納され、適宜更新される。たとえば、レコード番号を指定するコマンドあるいはカレントレコードの移動（たとえば、ネクストあるいはプレビアス）を指定するコマンドに応じてレコードポインタは更新される。従って、カレントレコードを指定するコマンドを受信した場合、ＣＰＵ１１は、レコードポインタが示すレコード（つまり、カレントレコード）にアクセスするようになっている。
【００３１】
なお、固定長循環順編成レコードファイルには、データが順次レコード領域に追記される。このような固定長循環順編成レコードファイルでは、一般的には、データが追記される毎に各データを格納する各レコードの領域に対するレコード番号が付け替えられる。即ち、固定長循環順編成レコードファイルでは、順次蓄積される複数のデータの各レコード領域に対して、新しい順（若しくは古い順）にレコード番号が割り当てられる。
【００３２】
以下、本実施例で処理対象とする順編成レコードファイルの構成例について説明する。
本実施例では、上記のような順編成レコードファイルの各レコードにそれぞれバックアップ領域が設定されるものとする。また、バックアップ領域の設定方法としては、１つのデータ領域に対して１つのバックアップ領域を設定する方法（第１の構成例）と、１つのデータ領域に対して複数のバックアップ領域を設定する方法（第２の構成例）とについて説明するものとする。
【００３３】
まず、レコードァイルの第１の構成例について説明する。
図３は、レコードファイルの第１の構成例を示す図である。
図３に示す第１の構成例のレコードファイルは、１つのファイルＩＤで特定され、複数のレコード領域（以下、単にレコードとも称する）を有している。各レコードは、レコード番号が割当てられ、データ領域とバックアップ領域とを有している。データ領域には当該レコードの最新のデータ（これが、当該レコードのデータとして取り扱われる）が格納され、バックアップ領域にはデータ領域のデータが現在のデータに書き換えられる前のデータ（つまり、更新前のデータ）が格納される。
【００３４】
図３に示す例では、レコード番号「０３」およびレコード番号「０５」の各レコードには、バックアップデータが記憶されている。つまり、レコード番号「０３」および「０５」の各レコードには、データ領域とバックアップ領域とにそれぞれデータが書込まれている。これは、レコード番号「０３」及び「０５」の各レコードが少なくとも１回更新されていることを示している。第１の構成例のレコードでは、データを書き換える場合、当該レコードのデータ領域に格納されているデータが当該レコードのバックアップ領域に移動され、当該レコードのデータ領域に最新のデータ（書換えデータ）が書込まれる。このような構成により、各レコードには、最新のデータと最新のデータに更新する直前のデータとが常時保存される。
【００３５】
上記のようなレコードファイルの各レコードに格納されているデータには、ファイルＩＤとレコード番号とによりアクセスが可能となっている。たとえば、図３に示す例では、ファイルＩＤ「０００１」かつレコード番号「０１」を指定することにより、レコード番号「０１」のデータ領域に格納されているデータにアクセスすることが可能となっている。同様に、バックアップデータが記憶されているレコード番号「０３」（又は「０５」）のレコードに対しても、ファイルＩＤ「０００１」かつレコード番号「０３」（又は「０５」）を指定することにより、レコード番号「０３」（又は「０５」）のデータ領域に格納されているデータにアクセスすることが可能となっている。
【００３６】
また、レコード番号「０３」（又は「０５」）のバックアップ領域に格納されているデータ（更新前のデータ）には、所定の操作によりアクセスすることが可能となっている。バックアップ領域に格納されているデータにアクセスするための手法としては、種々の手法が考えられる。たとえば、バックアップ領域のデータへのアクセスを要求するコマンドコードを定義しても良いし、コマンドにおける処理パラメータでバックアップ領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップ領域のデータへのアクセスを行うようにしても良い。
【００３７】
ここでは、カレントレコードを指定するコマンドによりカレントレコードのバックアップ領域のデータにアクセスする場合について説明する。
【００３８】
たとえば、図３に示すようなレコードファイルを有するＩＣカード１が、ファイルＩＤ「０００１」かつレコード番号「０３」のレコードを指定したデータの読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、ファイルＩＤ「０００１」かつレコード番号「０３」のレコードにおけるデータ領域のデータを読み出す処理を行う。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」かつレコード番号「０３」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。
【００３９】
この状態において、続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」かつレコード番号「０３」のレコードにおけるバックアップ領域のデータを読み出す処理を行う。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップ領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。
【００４０】
ここで、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、バックアップ領域のデータが読出し済みであるためエラーとして処理するか、あるいは、当該レコードのデータ領域のデータを読み出す処理を行うようにするものとする。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおけるバックアップ領域のデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるデータ領域のデータ、および、バックアップ領域のデータを交互に読み出すことが可能となる。
【００４１】
次に、上記第１の構成例のレコードファイルにおける各レコードに対するデータの書換え処理の流れについて説明する。
図４は、第１の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。
【００４２】
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１０）、ＣＰＵ１１は、コマンドコードなどにより受信したコマンドがデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ１１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ１１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ１２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。
【００４３】
指定されたレコードを特定すると、ＣＰＵ１１は、指定されたレコードにバックアップ領域が設定されているか否かを判断する（ステップＳ１３）。この判断は、指定されたレコードにおける更新前のデータをバックアップデータとして保存するか否かを判断するものである。上記判断により指定されたレコードにバックアップ領域が設定されていると判断した場合、ＣＰＵ１１は、当該レコードのデータ領域に格納されているデータをバックアップ領域に移動させる（ステップＳ１４）。ここで、ＣＰＵ１１は、当該レコードのデータ領域に格納されているデータを読み出し、読み出したデータをバックアップ領域に記憶する処理を行う。たとえば、上記ステップＳ１４において、既に当該レコードのバックアップ領域にデータが格納されている場合、データ領域から読み出したデータは、バックアップ領域のデータに上書きされる（すなわち、指定されたレコードにおけるバックアップ領域のデータは、データ領域から読み出したデータに書換えられる）。
【００４４】
ただし、各レコードのデータ領域とバックアップ領域とは、それぞれの意味付けが異なるだけである。従って、上記ステップＳ１４の処理としては、当該レコードにおけるデータ領域とバックアップ領域とを交換し、交換後のデータ領域にデータを書き込むようにしても良い。つまり、データ更新処理時に、データ領域をバックアップ領域に変更し、かつ、バックアップ領域をデータ領域に変更することにより、更新前のデータ領域（更新後のバックアップ領域）に格納されているデータをバックアップデータに変更するようにしても良い。
【００４５】
この場合、当該レコードにおけるデータ領域とバックアップ領域の定義付けを変更（交換）し、更新前のバックアップ領域（更新後のデータ領域）のデータを書き換えることにより、当該レコードにおけるデータ領域およびバックアップ領域の書換えが実現できる。この場合、データ領域のデータを書き換えるだけで良い（バックアップ領域のデータは書き換えなくても良い）ので、処理時間の短縮化が期待できる。
【００４６】
上記データ領域に格納されているデータをバックアップ領域に移動させると、ＣＰＵ１１は、当該レコードのデータ領域のデータを、受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ１５）。このようなデータ領域のデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ１６）、処理を終了する。
【００４７】
なお、上記ステップＳ１５においてデータ領域に対するデータの書換えが失敗した場合（あるいは、受信したコマンドに含まれる書換えデータのデータ領域への書込みがリトライできない状態となった場合）、ＣＰＵ１１は、当該レコードのバックアップ領域に移動したデータを再度、当該レコードのデータ領域に書き込むことにより、当該レコードの復旧処理を行うようにしても良い。このようにデータ領域へのデータの書込みが失敗した場合に、バックアップ領域のデータでデータ領域のデータを復旧させる（コマンドの受信前の状態に戻す）ことにより、ＩＣカードとしての動作を安定化させることが可能である。
【００４８】
上記のように、上述した第１の構成例のレコードファイルに対する書込み処理は、あるレコードのデータを更新する場合に、当該レコードの更新前のデータをバックアップ領域に退避させ、最新のデータ（書換えデータ）を当該レコードのデータとしてのデータ領域に書き込むようにしたものである。
これにより、更新前のデータを別のレコードとして保存するコマンドを与えたりすることなく、擬似的な２次元配列ファイルによって更新前のデータを随時保存しておくことが可能となる。
【００４９】
次に、上記第１の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図５は、第１の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ２０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ２１）。
【００５０】
この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ２１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップ領域の読出しを要求するものであるか否かを判定する（ステップＳ２２）。バックアップ領域の読出を要求する手法には、上述したような様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップ領域の読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出要求を示すようにしても良い。
【００５１】
また、特定のコマンドの実行手順によりバックアップ領域の読出要求を示す形態としては、特定のコマンドが連続して与えられた場合にバックアップ領域を読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合にバックアップ領域を読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出を要求する形態としては、コマンドコードあるいは処理パラメータなどでバックアップ領域の読出を指定するようにすれば良い。上記のような運用形態に従って、ＣＰＵ１１は、受信したコマンドがバックアップ領域の読出しを要求するコマンドであるか否かを判断するようになっている。
【００５２】
ここでは、図５に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードのバックアップ領域を読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、上記ステップＳ２２の処理として、当該コマンドにおいて読出対象とするレコードが、レコード番号で指定されているか、「カレントレコード」として指定されているかを判定する（ステップＳ２２）。
【００５３】
上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップ領域の読出しを要求する場合（ステップＳ２２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコード（指定されたレコード）にバックアップ領域が設定されているか否かを判断する（ステップＳ２３）。
【００５４】
この判断により指定されたレコードにバックアップ領域が設定されていると判断した場合（ステップＳ２３、ＹＥＳ）、ＣＰＵ１１は、受信したコマンドの直前に受信したリードレコードコマンドによって当該レコードのバックアップ領域のデータが読出し処理済みであるか否かを判断する（ステップＳ２４）。つまり、上記ステップＳ２４において、上記ＣＰＵ１１は、前回受信したリードコマンドによってバックアップ領域のデータを読み出したか否かを判断する。言い換えると、上記ステップＳ２４において、上記ＣＰＵ１１は、連続してバックアップ領域のデータの読出しを要求するコマンドを受信したか否かを判断している。
【００５５】
上記判断によりカレントレコードのバックアップ領域のデータが読出し済みでないと判断した場合（ステップＳ２４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）におけるバックアップ領域のデータを読み出す（ステップＳ２５）。カレントレコードのバックアップ領域のデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ２６）。このように、上記ステップＳ２０〜Ｓ２６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップ領域のデータが読み出される。
【００５６】
また、図５に示す処理例では、上記ステップＳ２２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ２２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのデータ領域のデータ（最新のデータ）の読出しを要求するものであると判定する。
【００５７】
すなわち、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ２２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ２８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、特定されたレコードをカレントレコードに設定する。
【００５８】
受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのデータ領域のデータを読出し（ステップＳ２９）、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ２６）。
【００５９】
また、図５に示す処理例では、ステップＳ２３でカレントレコードにバックアップ領域が設定されていないと判断した場合（ステップＳ２３、ＮＯ）、ＣＰＵ１１は、ステップＳ２９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うものとする。ただし、ステップＳ２３でＮＯと判断される場合は、バックアップ領域の読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）にバックアップ領域が設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ２７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。
【００６０】
また、図５に示す処理例では、ステップＳ２４でバックアップ領域のデータが直前のリードコマンドによって読出し済みであると判断した場合（ステップＳ２４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ２７）。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合であっても、連続して特定のレコード（カレントレコード）におけるバックアップ領域のデータの読出しを行わないようにする仕組みである。
【００６１】
ただし、上記ステップＳ２４でバックアップ領域のデータが直前のリードコマンドで読出し済みであると判断した場合（ステップＳ２４、ＹＥＳ）、ＣＰＵ１１は、図５に点線で示すように、ステップＳ２９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うようにしても良い。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、特定のレコード（カレントレコード）におけるバックアップ領域のデータとデータ領域のデータとを交互に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードのバックアップ領域のデータとデータ領域のデータとを交互に読み出す制御が可能となる。
【００６２】
上記のような読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのデータ領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンド（バックアップ領域のデータの読出しを要求するコマンド）に対しては、当該レコードのバックアップ領域に記憶されているデータを読み出すようになっている。
これにより、擬似的な２次元配列ファイルに格納されているデータを容易に読み出すことができ、レコード番号の管理などが複雑化することなく、取引履歴情報などの更新されることが予測されるデータについて最新のデータおよび更新前のデータを容易に読み出すことができる。
【００６３】
次に、レコードァイルの第２の構成例について説明する。
図６は、レコードファイルの第２の構成例を示す図である。
図６に示す第２の構成例のレコードファイルは、１つのファイルＩＤで特定され、複数のレコード領域（以下、単にレコードとも称する）を有している。各レコードは、レコード番号が割当てられ、１つのデータ領域と複数のバックアップ領域とを有している。データ領域には当該レコードの最新のデータ（これが、当該レコードのデータとして取り扱われる）が格納され、各バックアップ領域には上記データ領域のデータの更新時に順次古いデータ（更新前のデータ）が格納される。また、１つのレコードにおける複数のバックアップ領域には、それぞれ順に更新前のデータが書込まれる。言い換えれば、第２の構成例のファイルでは、各レコード毎に、バックアップ領域の数だけ古いデータが格納される。
【００６４】
たとえば、図６に示す例では、レコード番号「０２」のレコードには、最新のデータがデータ領域に格納され、３つのバックアップ領域に３回分の古いデータがそれぞれ順に格納されている。これは、レコード番号「０２」の各レコードが少なくとも３回更新されていることを示している。このようなレコードに対しては、データ領域のデータを更新する場合に、データ領域に格納されているデータが１世代前のデータを格納する第１のバックアップ領域に移動され、第１のバックアップ領域に格納されているデータが２世代前のデータを格納する第２のバックアップ領域に移動され、第２のバックアップ領域に格納されているデータが３世代前のデータを格納する第３のバックアップ領域に移動される。このような構成により、各レコードには、最新のデータと複数のバックアップデータが常時保存される。
【００６５】
また、上記のようなレコードファイルの各レコードのデータ領域に格納されているデータには、上記第１の構成例と同様に、ファイルＩＤとレコード番号とを指定することによりアクセスすることが可能となっている。これに対して、各レコードの各バックアップ領域に格納されているデータには、所定の操作によりアクセスすることが可能となっている。
【００６６】
各レコードの各バックアップ領域に格納されているデータにアクセスするための手法としては、種々の手法が考えられる。たとえば、バックアップ領域のデータへのアクセスを要求するコマンドコードを定義しても良いし、コマンドにおける処理パラメータでバックアップ領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップ領域のデータへのアクセスを行うようにしても良い。
【００６７】
ここでは、「カレントレコード」を指定するコマンドによりバックアップ領域のデータにアクセスする場合について説明する。
たとえば、図６に示すファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータの読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードにおけるデータ領域のデータを読み出す処理を行う。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」かつレコード番号「０２」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。
【００６８】
この状態において、カレントレコードを指定した読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」かつレコード番号「０２」のレコードにおける第１のバックアップ領域のデータを読み出す処理を行う。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップ領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。また、再度（２度連続して）、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第１のバックアップ領域のデータを読み出すようにしても良い。
【００６９】
また、続けて同じコマンドを受信した場合、つまり、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０２」のレコードにおける第２のバックアップ領域のデータを読み出す処理を行う。なお、３度連続して、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第２のバックアップ領域のデータを読み出すようにしても良い。
【００７０】
さらに、続けて同じコマンドを受信した場合、つまり、３度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０２」のレコードにおける第３のバックアップ領域のデータを読み出す処理を行う。なお、４度連続して、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第３のバックアップ領域のデータを読み出すようにしても良い。
【００７１】
ここで、バックアップ領域が各レコードに対して３つまでであるものとする。このような場合、４度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、全バックアップ領域のデータが読出し済みであるため、エラーとして処理するか、あるいは、当該レコードのデータ領域のデータを読み出す処理を行うようにするものとする。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおける全バックアップ領域のデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるデータ領域のデータ、および、各バックアップ領域のデータを順次循環させて読み出すことが可能となる。
【００７２】
次に、上記第２の構成例のレコードファイルにおける各レコードに対するデータの書換え処理について説明する。
図７は、第２の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。
【００７３】
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ３０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ３１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ３１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ３２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。
【００７４】
指定されたレコードを判定すると、ＣＰＵ１１は、指定されたレコードにバックアップ領域が設定されているか否かを判断する（ステップＳ３３）。この判断は、指定されたレコードにおいて更新前のデータをバックアップデータとして保存するように設定されているか否かを判断するものである。上記判断により指定されたレコードにバックアップ領域が設定されていると判断した場合、ＣＰＵ１１は、当該レコードのデータ領域および各バックアップ領域に格納されている各データを順次次のバックアップ領域に移動させる処理を行う（ステップＳ３４〜Ｓ３６）。
【００７５】
たとえば、ＣＰＵ１１は、まず、全バックアップ領域にデータが保存されているか否かを判断する（ステップＳ３４）。この判断により全バックアップ領域にデータが保存されていると判断した場合、ＣＰＵ１１は、最も古いデータが記憶されているバックアップ領域のデータを削除する（ステップＳ３５）。このような状態において、ＣＰＵ１１は、データ領域および各バックアップ領域のデータを順次各バックアップ領域に移動させる（ステップＳ３６）。
【００７６】
なお、上記ステップＳ３４〜Ｓ３６の処理は、当該レコードにおけるデータ領域及び各バックアップ領域のデータを順次次のバックアップ領域に上書きすることにより実現しても良いし、最古のデータが記憶されているバックアップ領域にデータ領域のデータを上書きすることにより実現するようにしても良い。何れの場合であっても、結果として、当該レコードでは、最古のデータが削除され、データ領域と各バックアップ領域の各データがぞれぞれバックアップ領域に格納される。
【００７７】
当該レコードのデータ領域および各バックアップ領域のデータを順次各バックアップ領域に移動させると、ＣＰＵ１１は、当該レコードのデータ領域のデータを、受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ３７）。このようなデータ領域のデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ３８）、処理を終了する。
【００７８】
なお、上記ステップＳ３７においてデータ領域に対するデータの書換えが失敗した場合（あるいは、受信したコマンドに含まれる書換えデータのデータ領域への書込みがリトライできない状態となった場合）、ＣＰＵ１１は、データ領域からバックアップ領域へ移動させたデータを再度、当該レコードのデータ領域に書き込むことにより、当該レコードの復旧処理を行うようにしても良い。このようにデータ領域へのデータの書込みが失敗した場合に、バックアップ領域のデータでデータ領域のデータを復旧させる（コマンドの受信前の状態に戻す）ことにより、ＩＣカード１としての動作を安定化させることが可能である。
【００７９】
上記のような書込み処理は、あるレコードのデータを更新する際に、データ領域および各バックアップ領域の各データを順次それぞれバックアップ領域に退避させ、最新のデータ（書換えデータ）を当該レコードのデータとしてのデータ領域に書き込むようにしたものである。これにより、更新前のデータを別のレコードとして保存するコマンドを与えたりすることなく、擬似的な２次元配列ファイルによって最新のデータと更新前の複数のデータ（複数世代のデータ）を容易に保存しておくことが可能となる。
【００８０】
また、上記のような書込み処理では、バックアップデータが全バックアップ領域の容量を超える場合、最古のデータを削除して、最新のデータからバックアップ領域の数の分だけ古い各データを各バックアップ領域に常時保存しておくようにしたものである。これにより、各レコードに設けられた各バックアップ領域に、最新のデータからバックアップ領域の数だけ古いデータまでの各世代のデータを各バックアップ領域に保存することが可能となる。
【００８１】
次に、上記第２の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図８は、第２の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ４０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてレコードデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ４１）。
【００８２】
この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ４１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップ領域の読出しを要求するコマンドであるか否かを判定する（ステップＳ４２）。
【００８３】
上述したように、バックアップ領域の読出を要求する手法には、様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップ領域の読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出要求するようにしても良い。また、特定のコマンドの実行手順によりバックアップ領域の読出要求を示す形態としては、特定のコマンドが連続して与えられた場合に各バックアップ領域を順次読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合に各バックアップ領域を順次読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出要求を示す形態としては、コマンドコードあるいは処理パラメータなどで各レコードの各バックアップ領域の読出を指定するようにすれば良い。上記のような運用形態に応じて、ＣＰＵ１１は、受信したコマンドがバックアップ領域の読出しを要求するコマンドであるか否かを判断するようになっている。
【００８４】
ここでは、図８に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードの各バックアップ領域を順次読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、上記ステップＳ４２の処理として、当該コマンドにおいて読出対象とするレコードが、レコード番号で指定されている（あるいは、カレント以外のレコードが指定されている）か、「カレントレコード」として指定されているかを判定する（ステップＳ４２）。
【００８５】
上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップ領域の読出しを要求する場合（ステップＳ４２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコードにバックアップ領域が設定されているか否かを判断する（ステップＳ４３）。
【００８６】
この判断によりカレントレコードにバックアップ領域が設定されていると判断した場合（ステップＳ４３、ＹＥＳ）、ＣＰＵ１１は、受信したコマンドの前までに受信したリードレコードコマンドによって当該レコードの全バックアップ領域のデータが読出し処理済みであるか否かを判断する（ステップＳ４４）。つまり、上記ステップＳ４４において、上記ＣＰＵ１１は、前回までに受信したリードコマンドによって全バックアップ領域のデータを読み出したか否かを判断する。
【００８７】
上記判断によりカレントレコードの全バックアップ領域のデータが読出し済みでないと判断した場合（ステップＳ４４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）における各バックアップ領域のデータを順次読み出す（ステップＳ４５）。たとえば、上記ＣＰＵ１１は、バックアップ領域のデータを読み出すごとに、ワーキングメモリ１３に設けた図示しないカウンタをカウントアップする。これにより、連続してカレントレコードを指定するリードレコードコマンドを受けるごとに、ＣＰＵ１１は、カウンタの値に基づいて順に各バックアップ領域のデータを読み出す。
【００８８】
カレントレコードのバックアップ領域のデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ４６）。このように、上記ステップＳ４０〜Ｓ４６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップ領域のデータが読み出される。このような処理を繰り返すことで、当該ＩＣカード１は、各バックアップ領域のデータを順に読み出すことが可能となっている。
【００８９】
また、図８に示す処理例では、上記ステップＳ４２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ４２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのデータ領域のデータ（最新のデータ）の読出しを要求するものであると判定する。ただし、カレントレコードを変更しないリードコマンドを受信した場合は、上記ステップＳ４３へ進むようにしても良い。
【００９０】
受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ４２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ４８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、指定されたレコードをカレントレコードとする。
【００９１】
受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのデータ領域のデータを読出し（ステップＳ４９）、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ４６）。
【００９２】
また、図８に示す処理例では、ステップＳ４３でカレントレコードにバックアップ領域が設定されていないと判断した場合（ステップＳ４３、ＮＯ）、ＣＰＵ１１は、ステップＳ４９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うものとする。ただし、ステップＳ４３でＮＯと判断される場合は、バックアップ領域の読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）にバックアップ領域が設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ４７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。
【００９３】
また、図８に示す処理例では、ステップＳ４４で全バックアップ領域のデータが直前のリードコマンドによって読出し済みであると判断した場合（ステップＳ４４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ４７）。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合、連続して特定のレコード（カレントレコード）における全バックアップ領域のデータが読出し済みであることをエラー通知によって通知する仕組みである。
【００９４】
ただし、上記ステップＳ４４で全バックアップ領域のデータが直前までのリードコマンドで読出し済みであると判断した場合（ステップＳ４４、ＹＥＳ）、ＣＰＵ１１は、図８に点線で示すように、ステップＳ４９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うようにしても良い。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、特定のレコード（カレントレコード）における各バックアップ領域の各データとデータ領域のデータとを順に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードの各バックアップ領域のデータとデータ領域のデータとを順に読み出す制御が可能となる。
【００９５】
上記のような読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのデータ領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンド（バックアップ領域のデータの読出しを要求するコマンド）に対しては、当該レコードのバックアップ領域に記憶されているデータを読み出すようになっている。つまり、データ領域のデータを読み出した後に連続して特定のレコードの読出しが要求される場合、各バックアップ領域のデータを順に読み出すようになっている。
【００９６】
これにより、擬似的な２次元配列ファイルに格納されている複数のバックアップデータを簡単な手順で順に読み出すことができ、レコード番号の管理などが複雑化することなく、取引履歴情報などの更新されることが予測されるデータについて最新のデータおよび更新前の複数のデータを容易に読み出すことができる。
【００９７】
なお、上述した第１あるいは第２の構成例のレコードファイルに対する更新処理あるいは読出処理は、種々の変形が可能である。以下、上述した実施の形態に対する変形例について説明する。
まず、第１の変形例として、各レコード毎に、全バックアップ領域のデータを一括して読み出す処理例について説明する。
【００９８】
すなわち、図８に示すような第２の構成例のレコードファイルに対する読出処理では、各レコードごとに各バックアップ領域のデータを順次読み出す処理について説明している。しかしながら、ＩＣカード１の運用形態によっては、各レコード毎に全バックアップ領域のデータを一括して読み出したい場合があると考えられる。このような場合、第２の構成例のようなレコードに対して全バックアップ領域のデータを一括して読み出す仕組みを設けることにより、効率的な処理が可能となると考えらえる。
【００９９】
各レコード毎に全バックアップ領域のデータを一括して読出す処理は、たとえば、リードレコードコマンドにおいて、全バックアップ領域を一括して読み出すことを要求するパラメータを定義しておくことにより実現できる。この場合、全バックアップ領域の一括読出しを指定するパラメータがカレントレコードを指定するリードレコードコマンドに含まれていれば、ＣＰＵ１１は、カレントレコードの全バックアップ領域のデータを一括して読み出し、一括して読み出した全バックアップ領域のデータをレスポンスデータとして出力するようにする。
【０１００】
また、各バックアップ領域のデータを順に読み出す必要がない運用形態である場合、つまり、常に全バックアップ領域のデータを読み出すような仕様とする場合、全バックアップ領域を１つのバックアップ領域として取り扱えば、図５に示す処理例と同様な処理が可能である。すなわち、バックアップ領域の読出しを要求するコマンドに対して全バックアップ領域のデータを読み出すようにすることにより、各レコード毎に全バックアップ領域のデータを一括して読出す処理が実現可能である。
【０１０１】
次に、第２の変形例として、１つのレコードファイル内の全レコードのバックアップ領域のデータを一括して読み出す処理例について説明する。
【０１０２】
すなわち、図５あるいは図８に示すような読出処理では、第１の構成例あるいは第２の構成例のレコードファイルに対して、各レコードごとにバックアップ領域のデータを読み出すようにしている。しかしながら、１つのレコードファイル内の各レコードは、互いに関連するデータを格納するものであることが想定される。このような場合、運用形態によっては、レコードファイル内の全レコードのバックアップ領域のデータを一括して読み出すことにより、処理が効率化できることがありうると考えられる。
【０１０３】
レコードファイル内の全レコードのバックアップ領域のデータを一括して読出す処理は、たとえば、リードコマンドにおいて、レコードファイル内の全レコードのバックアップ領域を一括して読み出すことを指定するパラメータを定義しておくことにより実現できる。この場合、レコードファイル内の全レコードのバックアップ領域の一括読出しを指定するパラメータがリードコマンドに含まれていれば、ＣＰＵ１１は、指定されるレコードファイル（たとえばカレント状態のレコードファイル）における全レコードのバックアップ領域のデータを一括して読み出し、読み出した全レコードのバックアップ領域のデータをレスポンスデータとして出力するようにする。これにより、第１の構成例あるいは第２の構成例のようなレコードであっても、レコードファイル内の全レコードのバックアップ領域を一括して読み出す処理が実現できる。
【０１０４】
次に、第３の変形例として、データ領域のデータ異常で読み出しが失敗した場合の処理例について説明する。
上述した更新処理では、データ領域のデータをバックアップ領域に移動させた後に、当該データ領域へのデータの書込みが失敗した場合、当該データ領域にバックアップ領域に移動させたデータを再度書き込むという復旧処理について説明している。同様に、読出処理においても、データ領域のデータ異常が発見された場合、バックアップ領域に格納されている最も新しいデータ（前回の更新直前のデータ）で当該データ領域を復旧させることが可能である。
【０１０５】
たとえば、図５のステップＳ２９あるいは図８のステップＳ４９として説明したデータ領域のデータの読出し処理において、データ領域のデータ異常で読出に失敗した場合、バックアップ領域に格納されている最も新しいデータをデータ領域に書き込むようにすれば良い。この場合、読出処理の結果としては、エラー通知を行うようにしても良いし、データ領域に書込んだデータを出力するようにしても良い。
【０１０６】
また、上記のようなデータ領域のデータの復旧処理は、ＩＣカード処理装置２からの復旧を要求するコマンドに応じて実行するようにしても良い。すなわち、ＩＣカード処理装置２からデータ領域のデータの読出を要求するコマンドに対して当該データ領域のデータ異常で読出に失敗した場合、ＩＣカード１は、当該データ領域のデータが異常である旨をエラー通知とともに出力し、その後、ＩＣカード処理装置２からのデータ領域の復旧を要求するコマンドに応じて、上記のようなデータ領域のデータの復旧処理を実行するようにしても良い。
【０１０７】
また、上記のような読出処理においてデータ領域のデータ異常が発見された場合、データ領域にデータを書き込むことなく、データ領域のデータの代りにバックアップ領域に格納している最も新しいデータ（前回の更新直前のデータ）を出力するようにしても良い。この場合、読み出したデータとともに、データ領域のデータの代りにバックアップ領域のデータを読み出した事を通知するようにする。これにより、データ領域がメモリ異常などにより使用不能となった場合であっても、データ領域のデータが異常であることを通知するとともに、バックアップ領域のデータをデータ領域のデータの代わりとして出力することが可能となる。
【図面の簡単な説明】
【０１０８】
【図１】本実施の形態に係るＩＣカードおよびＩＣカードを含むシステムの構成例を示すブロック図。
【図２】非接触式ＩＣカードの全体の構成例を示す図。
【図３】レコードファイルの第１の構成例を示す図。
【図４】第１の構成例のレコードファイルに対するデータ書込み処理の例を説明するためのフローチャート。
【図５】第１の構成例のレコードファイルに対するデータ読出し処理の例を説明するためのフローチャート。
【図６】レコードファイルの第２の構成例を示す図。
【図７】第２の構成例のレコードファイルに対するデータ書込み処理の例を説明するためのフローチャート。
【図８】第２の構成例のレコードファイルに対するデータ読出し処理の例を説明するためのフローチャート。
【符号の説明】
【０１０９】
Ｃ…本体、Ｍ…モジュール、１…ＩＣカード、１ａ…ＩＣチップ、２…ＩＣカード処理装置、１１…ＣＰＵ、１２…プログラムメモリ、１３…ワーキングメモリ、１４…データメモリ、１５…通信制御部、１６…電源部、１７…インターフェース、２１…制御装置、２２…カードリーダライタ。
【技術分野】
【０００１】
本発明は、例えば、個人情報あるいは取引情報などが記憶されているＩＣチップが内蔵されているＩＣカードあるいはＩＣタグなどの携帯可能電子装置、および、上記携帯可能電子装置におけるデータ管理方法などに関する。
【背景技術】
【０００２】
近年、ＩＣカードなどの携帯可能電子装置は、様々な用途に利用されている。このようなＩＣカードには、使用用途に応じた個人情報や金銭的な取引情報などの種々のデータが記憶される。上記のようなデータは、通常、ＩＣカード内に設けられているＥＥＰＲＯＭやフラッシュＲＯＭなどの不揮発性メモリに書込まれる。また、ＩＣカードは、外部装置からのコマンドに応じて不揮発性メモリへのデータ書込み処理などを実行するようになっている。
【０００３】
また、一般的な接触式あるいは非接触式ＩＣカードでは、国際標準規格であるＩＳＯ／ＩＥＣ７８１６−４に規定されている形式でデータを取り扱う。ＩＳＯ／ＩＥＣ７８１６−４では、ＩＣカード内の不揮発性メモリ上に定義されたＥＬＥＭＥＮＴＡＲＹ ＦＩＬＥ（ＥＦ）と呼ばれるファイルにデータを記録する。また、ＩＳＯ／ＩＥＣ ７８１６−４では、種々の形式のＥＦが規定されている。ＩＳＯ／ＩＥＣ ７８１６−４で規定されているＥＦのうち一般的に使用されるのは、レコード形式のＥＦである。ＩＳＯ／ＩＥＣ ７８１６−４には、レコード形式のＥＦとして、次の３種類の形式が規定されている。
【０００４】
（１）固定長順編成レコードファイル
（２）可変長順編成レコードファイル
（３）固定長循環順編成レコードファイル
上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルのＥＦは、ファイルＩＤ及びレコード番号により１つのデータの記録場所（領域）が確定する。従って、上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルのＥＦに対して、データの読み出し、データの書き込み、若しくは、データの書き換えを行う場合、指定されたファイルＩＤ及びレコード番号により特定される領域に対して、書き込み、若しくは、書き換えなどを行う。
【０００５】
一方、固定長循環順編成レコードファイルには、データが順次追記される構成となっている。このような固定長循環順編成レコードファイルでは、一般的に、データを追記する毎にデータに対するレコード番号が付け替えられる。即ち、固定長循環順編成レコードファイルでは、順次蓄積される複数のデータに対して、新しい順（若しくは古い順）にレコード番号が割り当てられる。
従来のＩＣカードにおいては、取引履歴情報の様に、取引処理の都度データの追加が発生する様なデータは、固定長循環順編成レコードファイルに格納され、それ以外のデータは、固定長または可変長順編成レコードファイルに格納されるのが一般的である。
【０００６】
しかしながら、ＩＣカードの運用形態によっては、ＥＦ内にレコード番号で管理された複数のレコードに複数のデータを記憶させるとともに、あるレコードのデータが更新（書き換え）された後に更新前のデータを参照したいといった要求がある。
【０００７】
この様な要求を実現するには、従来のＩＣカードでは、各データ毎に、固定長循環順編成レコードファイルを個別に作成したり、管理したりする必要がある。この場合、同一ＥＦ内でのレコード管理に比べ使い勝手の悪いものとなってしまう。また、一般的な運用形態では、ＩＣカード内のＥＦは、発行処理後に追加したり、削除したりすることが出来ないものが多い。このようなＩＣカードでは、発行処理後に、上記のようなデータ管理を実現するのが難しいという問題もある。
【非特許文献１】ＩＳＯ／ＩＥＣ ７８１６−４
【発明の開示】
【発明が解決しようとする課題】
【０００８】
この発明の一形態は、データの蓄積および読出しを効率的に行うことができる携帯可能電子装置および携帯可能電子装置におけるデータ管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
この発明の一形態としての携帯可能電子装置は、外部装置から与えられるコマンドに応じて処理を行うものにおいて、１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードを記憶する記憶手段と、前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新する更新手段と、前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す読出手段とを有する。
【００１０】
この発明の一形態としての携帯可能電子装置におけるデータ管理方法は、外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置における方法であって、前記外部装置から１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードのデータの更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新し、前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す。
【発明の効果】
【００１１】
この発明の一形態によれば、データの蓄積および読出しを効率的に行うことができる携帯可能電子装置および携帯可能電子装置におけるデータ管理方法を提供できる。
【発明を実施するための最良の形態】
【００１２】
以下、この発明に係る実施の形態について図面を参照しつつ説明する。
図１は、この発明の実施の形態に係る携帯可能電子装置としてのＩＣカード１およびＩＣカード１を含むＩＣカードシステムの構成例を示すブロック図である。
上記ＩＣカード１は、外部装置としてのＩＣカード処理装置２からの電源供給により動作可能な状態となる。動作可能となったＩＣカード１は、上記ＩＣカード処理装置２からのコマンドに応じて種々の処理を行う。上記ＩＣカード処理装置２は、ＩＣカード１を動作させるための電源を供給するとともに、当該ＩＣカード１に対して種々の処理を要求するコマンドを供給する。上記ＩＣカード処理装置２がＩＣカード１に対して供給するコマンドは、用途あるいは運用形態などに応じた処理を要求するものである。
【００１３】
また、上記ＩＣカード１は、アンテナあるいは無線通信部等により上記ＩＣカード処理装置２と非接触の状態で無線通信を行う非接触式の携帯可能電子装置（非接触式ＩＣカード）であっても良し、上記ＩＣカード処理装置２と物理的に接触して通信を行う接触式の携帯可能電子装置（接触式ＩＣカード）であっても良い。さらには、上記ＩＣカード１は、非接触式ＩＣカードとしての通信機能と接触式ＩＣカードとしての通信機能とを有する複合型のＩＣカード（デュアルインターフェースＩＣカード）であっても良い。なお、この実施の形態では、主に、非接触式ＩＣカードを想定して説明する。非接触式ＩＣカードと接触式ＩＣカードとはＩＣカード処理装置２との通信方式等が異なるだけである。このため、以下に説明する実施の形態は、接触式ＩＣカードにも同様に適用できる。
【００１４】
上記ＩＣカード１の構成例について説明する。
図１に示すように、上記ＩＣカード１は、ＣＰＵ１１、プログラムメモリ１２、ワーキングメモリ１３、データメモリ１４、通信制御部１５、電源部１６、および、インターフェース（アンテナあるいはコンタクト部）１７などを有している。
また、上記ＩＣカード１は、カード状の本体Ｃにより構成される。上記ＩＣカード１を形成するカード状の本体Ｃには、１つ（あるいは複数）のＩＣチップ１ａとインターフェース１７とが埋設される。上記ＩＣチップ１ａは、ＣＰＵ１１、プログラムメモリ１２、ワーキングメモリ１３、データメモリ１４、通信制御部１５および電源部１６などを有している。上記ＩＣチップ１ａは、上記インターフェース１７に接続された状態でモジュール化され、当該ＩＣカード１を形成するカード状の本体Ｃ内に埋設される。たとえば、図２は、非接触式ＩＣカード全体の構成例を示す図である。図２に示す非接触式ＩＣカードは、カード状の本体Ｃを有している。この本体Ｃ内には、図２に点線で示すように、１つ（あるいは複数）のＩＣチップ１ａとインターフェース１７としてのアンテナとを有するモジュールＭが埋め込まれている。
【００１５】
上記ＣＰＵ１１は、ＩＣカード１全体の制御を司るものである。上記ＣＰＵ１１は、上記プログラムメモリ１２あるいはデータメモリ１４に記憶されている制御プログラムおよび制御データなどに基づいて動作する。たとえば、上記ＣＰＵ１１は、上記プログラムメモリ１２に記憶されている基本的な動作を司る制御プログラムを実行することにより、外部装置から与えられるコマンドに応じた処理を実行する。これにより、外部装置から上記データメモリ１４へのデータの書込みを要求するコマンドが与えられれば、上記ＣＰＵ１１は、上記データメモリ１４へのデータの書き込み処理を実行する。また、外部装置から上記データメモリ１４に記憶されているデータの読み出しを要求するコマンドが与えられれば、上記ＣＰＵ１１は、上記データメモリ１４からのデータの読み出し処理を実行する。さらに、上記ＣＰＵ１１は、当該ＩＣカード１の用途などに応じてインストールされる処理プログラムを実行することにより、用途に応じた処理を実現するようになっている。
【００１６】
上記プログラムメモリ１２は、読み出し専用のメモリ（ＲＯＭ：リードオンリーメモリ）により構成される。上記プログラムメモリ１２には、予め基本動作を司る制御プログラムおよび制御データなどが記憶されている。上記プログラムメモリ１２には、予め当該ＩＣカード１の仕様に応じた制御プログラム及び制御データが記憶される。たとえば、上記ＣＰＵ１１は、上記プログラムメモリ１２に記憶される制御プログラムにより外部から与えられるコマンドに応じた処理を実現する。
【００１７】
上記ワーキングメモリ１３は、揮発性のメモリ（ＲＡＭ；ランダムアクセスメモリ）により構成される。上記ワーキングメモリ１３は、データを一時保管するバッファメモリとして機能する。例えば、上記ワーキングメモリ１３には、ＩＣカード処理装置（外部装置）２との通信処理において、送受信されるデータが一時的に保管される。また、上記ワーキングメモリ１３には、種々の書込みデータなどを一時的に保持するメモリとしても利用される。
【００１８】
上記データメモリ（不揮発性メモリ）１４は、データの書き込みが可能な不揮発性のメモリである。上記データメモリ１４は、例えば、ＥＥＰＲＯＭあるいはフラッシュメモリなどにより構成される。上記データメモリ１４には、当該ＩＣカード１の使用目的に応じた種々の情報が記憶される。
たとえば、当該ＩＣカードの使用目的に応じたアプリケーション（処理プログラムおよび運用データなど）は、上記データメモリ１４に書込まれる。当該ＩＣカード１が複数の使用目的に使用される場合、上記データメモリ１４には、各使用目的に応じた複数のアプリケーションが記憶される。また、当該ＩＣカード１の使用目的に応じたアプリケーションは、上記データメモリ１４上に定義された使用目的ごとのプログラムファイル（ＤＦ；Dedicated File）およびデータファイル（ＥＦ;Elementary File）などの各ファイルに記憶される。このようなファイル構造は、たとえば、ＩＳＯ／ＩＥＣ７８１６−４に基づくものである。なお、各種のデータを記憶するためのデータファイル（ＥＦ）の構成例については、後で詳細に説明するものとする。
【００１９】
上記通信制御部１５は、上記インターフェース１７を介して外部装置（たとえば、ＩＣカード処理装置２）とのデータ通信を制御するものである。たとえば、当該ＩＣカードが非接触型のＩＣカードであれば、外部装置からデータを受信する場合、上記通信制御部１５は、インターフェース１７としてのアンテナにより受信した電波としての送信データを復調し、復調した信号を上記ＣＰＵ１１に供給する。また、外部装置へデータを送信する場合、上記通信制御部１５は、上記ＣＰＵ１１から与えられるデータを変調し、変調したデータを上記インターフェース１７としてのアンテナにより電波として発信する。なお、接触式ＩＣカードでは、インターフェース１７として、アンテナの代わりに、外部装置の接触端子部と物理的・電気的に接触するコンタクト部を介して外部装置とのデータ通信を行う。
【００２０】
上記電源部１６は、当該ＩＣカード１の各部を動作させるための上記インターフェース１７を介して受信する電力およびクロックパルスを供給する。たとえば、当該ＩＣカードが非接触型のＩＣカードであれば、上記電源部１６は、上記インターフェース１７としてのアンテナにより受信した電波から電力およびクロックパルスを生成し、当該ＩＣカード内の各部に供給するようになっている。また、上記電源部１６からの電力供給により起動した場合、上記ＣＰＵ１１は、当該ＩＣカード１の処理状態をリセットする処理を行うようになっている。なお、当該ＩＣカード１が接触型のＩＣカードであれば、上記電源部１６はインターフェース１７を介して外部装置から直接的に供給される電力およびクロックパルスにより各部へ供給するようになっている。
【００２１】
次に、上記ＩＣカード処理装置２について説明する。
上記ＩＣカード処理装置２は、図１に示すように、制御装置２１およびカードリーダライタ２２を有している。上記制御装置２１は、パーソナルコンピュータ（ＰＣ）などにより構成される。上記制御装置２１は、ＣＰＵなどの演算処理部、ＲＡＭ、ＲＯＭ、不揮発性メモリおよびハードディスクドライブなどの各種メモリ、通信インターフェースなどの各種インターフェースなどにより構成される。上記制御装置２１では、上記演算処理部がメモリに記憶されている各種の制御プログラムを実行することにより各種の処理を実現している。また、上記制御装置２１は、ＩＣカード１とのデータ通信を行う上記カードリーダライタ２２とのデータの入出力を行うようになっている。
【００２２】
たとえば、上記制御装置２１には、上記ＩＣカード１を用いた各種の処理に応じた制御プログラムが予め記憶されている。上記制御装置２１では、上記のような制御プログラムを実行することにより上記ＩＣカード１を用いた各種の処理を実行する。たとえば、上記ＩＣカード１を用いた各種の処理において、上記制御装置２１は、所定のコマンドを所定の手順で供給する。上記制御装置２１では、上記のような各コマンドに対するＩＣカード１からの各レスポンス（コマンドに対する処理結果等を示す情報）に基づいて各種の処理を行うようになっている。
【００２３】
上記カードリーダライタ２２は、上記ＩＣカード１とのデータ通信を行う通信手段として機能する。上記カードリーダライタ２２は、上記ＩＣカード１の通信方式に応じた通信方式によるデータ通信を行うためのものである。つまり、上記カードリーダライタ２２を介して制御装置２１は、上記ＩＣカード１とのデータ通信を実現している。
【００２４】
上記ＩＣカード１が非接触型のＩＣカードである場合、上記カードリーダライタ２２は、上記ＩＣカード１との無線によるデータ通信を行うためのアンテナおよび通信制御部（変復調回路等）などにより構成される。非接触型のＩＣカード１へデータを送信する場合、上記カードリーダライタ２２では、通信制御部により上記制御装置２１から与えられる送信データを変調し、変調した信号を電波としてアンテナにより発信する。また、非接触型のＩＣカード１からデータを受信する場合、上記カードリーダライタ２２では、アンテナにより受信した電波としての信号を通信制御部により復調し、復調したデータを受信データとして上記制御装置２１へ供給する。また、上記カードリーダライタ２２では、上記のようなデータの送受信とともに、上記ＩＣカード１を動作させるための電源およびクロックパルスとなる電波をアンテナにより発信するようになっている。
【００２５】
また、上記ＩＣカード１が接触型のＩＣカードである場合、上記カードリーダライタ２２は、ＩＣカード１と物理的に接触してデータ通信を行うためのコンタクト部および通信制御部などにより構成される。接触型のＩＣカードとのデータの送受信を行う場合、上記カードリーダライタ２２では、上記コンタクト部がＩＣカード１側に設けられているコンタクト部と物理的に接触して各種のデータ通信を行う。また、上記カードリーダライタ２２では、ＩＣカード１に物理的に接触しているコンタクト部を介して当該ＩＣカード１に対して電力およびクロックパルスを供給するようになっている。
【００２６】
次に、上記データメモリ１４に記憶されるファイルについて説明する。
本実施例では、上述したようにデータメモリ１４内の各ファイルがＩＳＯ／ＩＥＣ ７８１６で規定されているファイル構造となっているものとする。ＩＳＯ／ＩＥＣ ７８１６では、ＭＦ（Master File）、ＤＦ（Dedicated File）、ＥＦ（Elementary File）などからなる階層構造のファイル構成が規定されている。ＭＦは、階層構造の最上位に位置するファイルであり、ＭＦの下層にＤＦあるいはＥＦが設けられる。ＤＦは、例えば、アプリケーションごとに設定されるファイルであり、当該アプリケーションで利用するデータを格納するためのデータファイルとしてのＥＦが下層に設けられる。各ＥＦは、それぞれ実データを記憶するためのデータファイルである。また、実データは、データファイル内において、各レコードごとに記憶される。各レコードには、それぞれレコード番号が与えられる。
【００２７】
上記のような各ファイルは、それぞれが図示しない管理テーブルに記憶される定義情報により定義される。たとえば、上記のようなデータファイルとしてのＥＦは、図示しない管理テーブルに記憶されるＥＦ定義情報により定義される。ＥＦ定義情報では、当該ＥＦを特定するための情報として、ファイルＩＤ、データメモリ１４における先頭アドレス、および、データサイズなどが定義される。
【００２８】
また、ＩＳＯ／ＩＥＣ ７８１６で規定されているデータファイル（ＥＦ）には、種々の形式がある。たとえば、ＩＳＯ／ＩＥＣ ７８１６には、ＥＦの形式として、固定長順編成レコードファイル、可変長順編成レコードファイル、固定長循環順編成レコードファイルなどがある。
【００２９】
上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルは、複数のデータを格納するための複数のレコード領域（以下、単にレコードとも称する）が設定可能である。たとえば、１つのファイルに複数のデータを格納したい場合、データファイルには、複数のデータに対応する複数のレコードに各データが格納される。複数のレコードを有するファイルでは、ファイルＩＤ及びレコード番号により各レコードが特定される。たとえば、上記固定長順編成レコードファイルあるいは上記可変長順編成レコードファイルの特定のレコードに対して、データの読み出し、データの書き込み、若しくは、データの書き換えを行う場合、ＩＣカード処理装置２は、書き込み、書き換え、若しくは、読出しなどを要求するコマンドにおいて、ファイルＩＤ及びレコード番号によりレコードを指定する。
【００３０】
また、アクセス対象とするレコードを指定するには、各種のコマンドにおいて、カレントレコードを指定することも可能である。カレントレコードとは、カレント状態とするレコードである。カレントレコードを示す情報（レコードポインタ）は、常時、ワーキングメモリなどに格納され、適宜更新される。たとえば、レコード番号を指定するコマンドあるいはカレントレコードの移動（たとえば、ネクストあるいはプレビアス）を指定するコマンドに応じてレコードポインタは更新される。従って、カレントレコードを指定するコマンドを受信した場合、ＣＰＵ１１は、レコードポインタが示すレコード（つまり、カレントレコード）にアクセスするようになっている。
【００３１】
なお、固定長循環順編成レコードファイルには、データが順次レコード領域に追記される。このような固定長循環順編成レコードファイルでは、一般的には、データが追記される毎に各データを格納する各レコードの領域に対するレコード番号が付け替えられる。即ち、固定長循環順編成レコードファイルでは、順次蓄積される複数のデータの各レコード領域に対して、新しい順（若しくは古い順）にレコード番号が割り当てられる。
【００３２】
以下、本実施例で処理対象とする順編成レコードファイルの構成例について説明する。
本実施例では、上記のような順編成レコードファイルの各レコードにそれぞれバックアップ領域が設定されるものとする。また、バックアップ領域の設定方法としては、１つのデータ領域に対して１つのバックアップ領域を設定する方法（第１の構成例）と、１つのデータ領域に対して複数のバックアップ領域を設定する方法（第２の構成例）とについて説明するものとする。
【００３３】
まず、レコードァイルの第１の構成例について説明する。
図３は、レコードファイルの第１の構成例を示す図である。
図３に示す第１の構成例のレコードファイルは、１つのファイルＩＤで特定され、複数のレコード領域（以下、単にレコードとも称する）を有している。各レコードは、レコード番号が割当てられ、データ領域とバックアップ領域とを有している。データ領域には当該レコードの最新のデータ（これが、当該レコードのデータとして取り扱われる）が格納され、バックアップ領域にはデータ領域のデータが現在のデータに書き換えられる前のデータ（つまり、更新前のデータ）が格納される。
【００３４】
図３に示す例では、レコード番号「０３」およびレコード番号「０５」の各レコードには、バックアップデータが記憶されている。つまり、レコード番号「０３」および「０５」の各レコードには、データ領域とバックアップ領域とにそれぞれデータが書込まれている。これは、レコード番号「０３」及び「０５」の各レコードが少なくとも１回更新されていることを示している。第１の構成例のレコードでは、データを書き換える場合、当該レコードのデータ領域に格納されているデータが当該レコードのバックアップ領域に移動され、当該レコードのデータ領域に最新のデータ（書換えデータ）が書込まれる。このような構成により、各レコードには、最新のデータと最新のデータに更新する直前のデータとが常時保存される。
【００３５】
上記のようなレコードファイルの各レコードに格納されているデータには、ファイルＩＤとレコード番号とによりアクセスが可能となっている。たとえば、図３に示す例では、ファイルＩＤ「０００１」かつレコード番号「０１」を指定することにより、レコード番号「０１」のデータ領域に格納されているデータにアクセスすることが可能となっている。同様に、バックアップデータが記憶されているレコード番号「０３」（又は「０５」）のレコードに対しても、ファイルＩＤ「０００１」かつレコード番号「０３」（又は「０５」）を指定することにより、レコード番号「０３」（又は「０５」）のデータ領域に格納されているデータにアクセスすることが可能となっている。
【００３６】
また、レコード番号「０３」（又は「０５」）のバックアップ領域に格納されているデータ（更新前のデータ）には、所定の操作によりアクセスすることが可能となっている。バックアップ領域に格納されているデータにアクセスするための手法としては、種々の手法が考えられる。たとえば、バックアップ領域のデータへのアクセスを要求するコマンドコードを定義しても良いし、コマンドにおける処理パラメータでバックアップ領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップ領域のデータへのアクセスを行うようにしても良い。
【００３７】
ここでは、カレントレコードを指定するコマンドによりカレントレコードのバックアップ領域のデータにアクセスする場合について説明する。
【００３８】
たとえば、図３に示すようなレコードファイルを有するＩＣカード１が、ファイルＩＤ「０００１」かつレコード番号「０３」のレコードを指定したデータの読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、ファイルＩＤ「０００１」かつレコード番号「０３」のレコードにおけるデータ領域のデータを読み出す処理を行う。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」かつレコード番号「０３」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。
【００３９】
この状態において、続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」かつレコード番号「０３」のレコードにおけるバックアップ領域のデータを読み出す処理を行う。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップ領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。
【００４０】
ここで、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、バックアップ領域のデータが読出し済みであるためエラーとして処理するか、あるいは、当該レコードのデータ領域のデータを読み出す処理を行うようにするものとする。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおけるバックアップ領域のデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるデータ領域のデータ、および、バックアップ領域のデータを交互に読み出すことが可能となる。
【００４１】
次に、上記第１の構成例のレコードファイルにおける各レコードに対するデータの書換え処理の流れについて説明する。
図４は、第１の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。
【００４２】
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ１０）、ＣＰＵ１１は、コマンドコードなどにより受信したコマンドがデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ１１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ１１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ１２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。
【００４３】
指定されたレコードを特定すると、ＣＰＵ１１は、指定されたレコードにバックアップ領域が設定されているか否かを判断する（ステップＳ１３）。この判断は、指定されたレコードにおける更新前のデータをバックアップデータとして保存するか否かを判断するものである。上記判断により指定されたレコードにバックアップ領域が設定されていると判断した場合、ＣＰＵ１１は、当該レコードのデータ領域に格納されているデータをバックアップ領域に移動させる（ステップＳ１４）。ここで、ＣＰＵ１１は、当該レコードのデータ領域に格納されているデータを読み出し、読み出したデータをバックアップ領域に記憶する処理を行う。たとえば、上記ステップＳ１４において、既に当該レコードのバックアップ領域にデータが格納されている場合、データ領域から読み出したデータは、バックアップ領域のデータに上書きされる（すなわち、指定されたレコードにおけるバックアップ領域のデータは、データ領域から読み出したデータに書換えられる）。
【００４４】
ただし、各レコードのデータ領域とバックアップ領域とは、それぞれの意味付けが異なるだけである。従って、上記ステップＳ１４の処理としては、当該レコードにおけるデータ領域とバックアップ領域とを交換し、交換後のデータ領域にデータを書き込むようにしても良い。つまり、データ更新処理時に、データ領域をバックアップ領域に変更し、かつ、バックアップ領域をデータ領域に変更することにより、更新前のデータ領域（更新後のバックアップ領域）に格納されているデータをバックアップデータに変更するようにしても良い。
【００４５】
この場合、当該レコードにおけるデータ領域とバックアップ領域の定義付けを変更（交換）し、更新前のバックアップ領域（更新後のデータ領域）のデータを書き換えることにより、当該レコードにおけるデータ領域およびバックアップ領域の書換えが実現できる。この場合、データ領域のデータを書き換えるだけで良い（バックアップ領域のデータは書き換えなくても良い）ので、処理時間の短縮化が期待できる。
【００４６】
上記データ領域に格納されているデータをバックアップ領域に移動させると、ＣＰＵ１１は、当該レコードのデータ領域のデータを、受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ１５）。このようなデータ領域のデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ１６）、処理を終了する。
【００４７】
なお、上記ステップＳ１５においてデータ領域に対するデータの書換えが失敗した場合（あるいは、受信したコマンドに含まれる書換えデータのデータ領域への書込みがリトライできない状態となった場合）、ＣＰＵ１１は、当該レコードのバックアップ領域に移動したデータを再度、当該レコードのデータ領域に書き込むことにより、当該レコードの復旧処理を行うようにしても良い。このようにデータ領域へのデータの書込みが失敗した場合に、バックアップ領域のデータでデータ領域のデータを復旧させる（コマンドの受信前の状態に戻す）ことにより、ＩＣカードとしての動作を安定化させることが可能である。
【００４８】
上記のように、上述した第１の構成例のレコードファイルに対する書込み処理は、あるレコードのデータを更新する場合に、当該レコードの更新前のデータをバックアップ領域に退避させ、最新のデータ（書換えデータ）を当該レコードのデータとしてのデータ領域に書き込むようにしたものである。
これにより、更新前のデータを別のレコードとして保存するコマンドを与えたりすることなく、擬似的な２次元配列ファイルによって更新前のデータを随時保存しておくことが可能となる。
【００４９】
次に、上記第１の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図５は、第１の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ２０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ２１）。
【００５０】
この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ２１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップ領域の読出しを要求するものであるか否かを判定する（ステップＳ２２）。バックアップ領域の読出を要求する手法には、上述したような様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップ領域の読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出要求を示すようにしても良い。
【００５１】
また、特定のコマンドの実行手順によりバックアップ領域の読出要求を示す形態としては、特定のコマンドが連続して与えられた場合にバックアップ領域を読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合にバックアップ領域を読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出を要求する形態としては、コマンドコードあるいは処理パラメータなどでバックアップ領域の読出を指定するようにすれば良い。上記のような運用形態に従って、ＣＰＵ１１は、受信したコマンドがバックアップ領域の読出しを要求するコマンドであるか否かを判断するようになっている。
【００５２】
ここでは、図５に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードのバックアップ領域を読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、上記ステップＳ２２の処理として、当該コマンドにおいて読出対象とするレコードが、レコード番号で指定されているか、「カレントレコード」として指定されているかを判定する（ステップＳ２２）。
【００５３】
上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップ領域の読出しを要求する場合（ステップＳ２２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコード（指定されたレコード）にバックアップ領域が設定されているか否かを判断する（ステップＳ２３）。
【００５４】
この判断により指定されたレコードにバックアップ領域が設定されていると判断した場合（ステップＳ２３、ＹＥＳ）、ＣＰＵ１１は、受信したコマンドの直前に受信したリードレコードコマンドによって当該レコードのバックアップ領域のデータが読出し処理済みであるか否かを判断する（ステップＳ２４）。つまり、上記ステップＳ２４において、上記ＣＰＵ１１は、前回受信したリードコマンドによってバックアップ領域のデータを読み出したか否かを判断する。言い換えると、上記ステップＳ２４において、上記ＣＰＵ１１は、連続してバックアップ領域のデータの読出しを要求するコマンドを受信したか否かを判断している。
【００５５】
上記判断によりカレントレコードのバックアップ領域のデータが読出し済みでないと判断した場合（ステップＳ２４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）におけるバックアップ領域のデータを読み出す（ステップＳ２５）。カレントレコードのバックアップ領域のデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ２６）。このように、上記ステップＳ２０〜Ｓ２６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップ領域のデータが読み出される。
【００５６】
また、図５に示す処理例では、上記ステップＳ２２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ２２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのデータ領域のデータ（最新のデータ）の読出しを要求するものであると判定する。
【００５７】
すなわち、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ２２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ２８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、特定されたレコードをカレントレコードに設定する。
【００５８】
受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのデータ領域のデータを読出し（ステップＳ２９）、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ２６）。
【００５９】
また、図５に示す処理例では、ステップＳ２３でカレントレコードにバックアップ領域が設定されていないと判断した場合（ステップＳ２３、ＮＯ）、ＣＰＵ１１は、ステップＳ２９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うものとする。ただし、ステップＳ２３でＮＯと判断される場合は、バックアップ領域の読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）にバックアップ領域が設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ２７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。
【００６０】
また、図５に示す処理例では、ステップＳ２４でバックアップ領域のデータが直前のリードコマンドによって読出し済みであると判断した場合（ステップＳ２４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ２７）。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合であっても、連続して特定のレコード（カレントレコード）におけるバックアップ領域のデータの読出しを行わないようにする仕組みである。
【００６１】
ただし、上記ステップＳ２４でバックアップ領域のデータが直前のリードコマンドで読出し済みであると判断した場合（ステップＳ２４、ＹＥＳ）、ＣＰＵ１１は、図５に点線で示すように、ステップＳ２９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うようにしても良い。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、特定のレコード（カレントレコード）におけるバックアップ領域のデータとデータ領域のデータとを交互に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードのバックアップ領域のデータとデータ領域のデータとを交互に読み出す制御が可能となる。
【００６２】
上記のような読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのデータ領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンド（バックアップ領域のデータの読出しを要求するコマンド）に対しては、当該レコードのバックアップ領域に記憶されているデータを読み出すようになっている。
これにより、擬似的な２次元配列ファイルに格納されているデータを容易に読み出すことができ、レコード番号の管理などが複雑化することなく、取引履歴情報などの更新されることが予測されるデータについて最新のデータおよび更新前のデータを容易に読み出すことができる。
【００６３】
次に、レコードァイルの第２の構成例について説明する。
図６は、レコードファイルの第２の構成例を示す図である。
図６に示す第２の構成例のレコードファイルは、１つのファイルＩＤで特定され、複数のレコード領域（以下、単にレコードとも称する）を有している。各レコードは、レコード番号が割当てられ、１つのデータ領域と複数のバックアップ領域とを有している。データ領域には当該レコードの最新のデータ（これが、当該レコードのデータとして取り扱われる）が格納され、各バックアップ領域には上記データ領域のデータの更新時に順次古いデータ（更新前のデータ）が格納される。また、１つのレコードにおける複数のバックアップ領域には、それぞれ順に更新前のデータが書込まれる。言い換えれば、第２の構成例のファイルでは、各レコード毎に、バックアップ領域の数だけ古いデータが格納される。
【００６４】
たとえば、図６に示す例では、レコード番号「０２」のレコードには、最新のデータがデータ領域に格納され、３つのバックアップ領域に３回分の古いデータがそれぞれ順に格納されている。これは、レコード番号「０２」の各レコードが少なくとも３回更新されていることを示している。このようなレコードに対しては、データ領域のデータを更新する場合に、データ領域に格納されているデータが１世代前のデータを格納する第１のバックアップ領域に移動され、第１のバックアップ領域に格納されているデータが２世代前のデータを格納する第２のバックアップ領域に移動され、第２のバックアップ領域に格納されているデータが３世代前のデータを格納する第３のバックアップ領域に移動される。このような構成により、各レコードには、最新のデータと複数のバックアップデータが常時保存される。
【００６５】
また、上記のようなレコードファイルの各レコードのデータ領域に格納されているデータには、上記第１の構成例と同様に、ファイルＩＤとレコード番号とを指定することによりアクセスすることが可能となっている。これに対して、各レコードの各バックアップ領域に格納されているデータには、所定の操作によりアクセスすることが可能となっている。
【００６６】
各レコードの各バックアップ領域に格納されているデータにアクセスするための手法としては、種々の手法が考えられる。たとえば、バックアップ領域のデータへのアクセスを要求するコマンドコードを定義しても良いし、コマンドにおける処理パラメータでバックアップ領域を指定するように定義しても良い。また、特定のコマンドを受信した順序、あるいは、特定のコマンドを受信した回数などに基づいて、バックアップ領域のデータへのアクセスを行うようにしても良い。
【００６７】
ここでは、「カレントレコード」を指定するコマンドによりバックアップ領域のデータにアクセスする場合について説明する。
たとえば、図６に示すファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータの読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードにおけるデータ領域のデータを読み出す処理を行う。この際、当該ＩＣカード１では、カレントレコードがファイルＩＤ「０００１」かつレコード番号「０２」のレコードとなる。このようなカレントレコードを示す情報は、たとえば、ワーキングメモリ１３に保持される。
【００６８】
この状態において、カレントレコードを指定した読出要求コマンド（リードレコードコマンド）を受信した場合、ＣＰＵ１１は、カレントレコードであるファイルＩＤ「０００１」かつレコード番号「０２」のレコードにおける第１のバックアップ領域のデータを読み出す処理を行う。なお、このようなカレントレコードを指定したリードレコードコマンドによりバックアップ領域を読出した回数は、たとえば、ワーキングメモリ１３に保持されるものとする。また、再度（２度連続して）、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第１のバックアップ領域のデータを読み出すようにしても良い。
【００６９】
また、続けて同じコマンドを受信した場合、つまり、２度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０２」のレコードにおける第２のバックアップ領域のデータを読み出す処理を行う。なお、３度連続して、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第２のバックアップ領域のデータを読み出すようにしても良い。
【００７０】
さらに、続けて同じコマンドを受信した場合、つまり、３度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、カレントレコードであるレコード番号「０２」のレコードにおける第３のバックアップ領域のデータを読み出す処理を行う。なお、４度連続して、ファイルＩＤ「０００１」かつレコード番号「０２」のレコードを指定したデータのリードレコードコマンドを受信した場合も、上記同様に、第３のバックアップ領域のデータを読み出すようにしても良い。
【００７１】
ここで、バックアップ領域が各レコードに対して３つまでであるものとする。このような場合、４度続けてカレントレコードを指定したリードレコードコマンドを受信した場合、ＣＰＵ１１は、全バックアップ領域のデータが読出し済みであるため、エラーとして処理するか、あるいは、当該レコードのデータ領域のデータを読み出す処理を行うようにするものとする。特に、前者のような形態では、ＩＣカード処理装置２は、ＩＣカード１からエラー通知を受けることにより、当該レコードにおける全バックアップ領域のデータを読み出したことを容易に識別できる。また、後者のような形態では、ＩＣカード処理装置２は、カレントレコードを指定するリードコマンドを連続してＩＣカード１に与えることにより、各レコードにおけるデータ領域のデータ、および、各バックアップ領域のデータを順次循環させて読み出すことが可能となる。
【００７２】
次に、上記第２の構成例のレコードファイルにおける各レコードに対するデータの書換え処理について説明する。
図７は、第２の構成例のレコードファイルにおけるレコードに対するデータの書換え処理を説明するためのフローチャートである。
【００７３】
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ３０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてデータの書換えを要求するコマンドであるか否かを判断する（ステップＳ３１）。この判断により受信したコマンドがデータの書換えコマンドであると判断した場合（ステップＳ３１、ＹＥＳ）、ＣＰＵ１１は、当該コマンドで指定されたレコードを特定する（ステップＳ３２）。たとえば、ファイルＩＤとレコード番号とが指定されている場合、ＣＰＵ１１は、指定されたファイルＩＤとレコード番号とにより特定されるレコードのデータを書き換えるものと判定する。
【００７４】
指定されたレコードを判定すると、ＣＰＵ１１は、指定されたレコードにバックアップ領域が設定されているか否かを判断する（ステップＳ３３）。この判断は、指定されたレコードにおいて更新前のデータをバックアップデータとして保存するように設定されているか否かを判断するものである。上記判断により指定されたレコードにバックアップ領域が設定されていると判断した場合、ＣＰＵ１１は、当該レコードのデータ領域および各バックアップ領域に格納されている各データを順次次のバックアップ領域に移動させる処理を行う（ステップＳ３４〜Ｓ３６）。
【００７５】
たとえば、ＣＰＵ１１は、まず、全バックアップ領域にデータが保存されているか否かを判断する（ステップＳ３４）。この判断により全バックアップ領域にデータが保存されていると判断した場合、ＣＰＵ１１は、最も古いデータが記憶されているバックアップ領域のデータを削除する（ステップＳ３５）。このような状態において、ＣＰＵ１１は、データ領域および各バックアップ領域のデータを順次各バックアップ領域に移動させる（ステップＳ３６）。
【００７６】
なお、上記ステップＳ３４〜Ｓ３６の処理は、当該レコードにおけるデータ領域及び各バックアップ領域のデータを順次次のバックアップ領域に上書きすることにより実現しても良いし、最古のデータが記憶されているバックアップ領域にデータ領域のデータを上書きすることにより実現するようにしても良い。何れの場合であっても、結果として、当該レコードでは、最古のデータが削除され、データ領域と各バックアップ領域の各データがぞれぞれバックアップ領域に格納される。
【００７７】
当該レコードのデータ領域および各バックアップ領域のデータを順次各バックアップ領域に移動させると、ＣＰＵ１１は、当該レコードのデータ領域のデータを、受信した書換えコマンドに含まれる書換えデータに書き換える（ステップＳ３７）。このようなデータ領域のデータの書換えが正常終了すると、ＣＰＵ１１は、受信したコマンドに対する処理が正常終了した旨のレスポンスをＩＣカード処理装置２に送信し（ステップＳ３８）、処理を終了する。
【００７８】
なお、上記ステップＳ３７においてデータ領域に対するデータの書換えが失敗した場合（あるいは、受信したコマンドに含まれる書換えデータのデータ領域への書込みがリトライできない状態となった場合）、ＣＰＵ１１は、データ領域からバックアップ領域へ移動させたデータを再度、当該レコードのデータ領域に書き込むことにより、当該レコードの復旧処理を行うようにしても良い。このようにデータ領域へのデータの書込みが失敗した場合に、バックアップ領域のデータでデータ領域のデータを復旧させる（コマンドの受信前の状態に戻す）ことにより、ＩＣカード１としての動作を安定化させることが可能である。
【００７９】
上記のような書込み処理は、あるレコードのデータを更新する際に、データ領域および各バックアップ領域の各データを順次それぞれバックアップ領域に退避させ、最新のデータ（書換えデータ）を当該レコードのデータとしてのデータ領域に書き込むようにしたものである。これにより、更新前のデータを別のレコードとして保存するコマンドを与えたりすることなく、擬似的な２次元配列ファイルによって最新のデータと更新前の複数のデータ（複数世代のデータ）を容易に保存しておくことが可能となる。
【００８０】
また、上記のような書込み処理では、バックアップデータが全バックアップ領域の容量を超える場合、最古のデータを削除して、最新のデータからバックアップ領域の数の分だけ古い各データを各バックアップ領域に常時保存しておくようにしたものである。これにより、各レコードに設けられた各バックアップ領域に、最新のデータからバックアップ領域の数だけ古いデータまでの各世代のデータを各バックアップ領域に保存することが可能となる。
【００８１】
次に、上記第２の構成例のレコードファイルにおける各レコードに対するデータの読出し処理について説明する。
図８は、第２の構成例のレコードファイルにおけるレコードに対するデータの読出し処理を説明するためのフローチャートである。
まず、ＩＣカード処理装置２からコマンドを受信した場合（ステップＳ４０）、ＣＰＵ１１は、当該コマンドのコマンドコードに基づいてレコードデータの読出しを要求するリードレコードコマンドであるか否かを判断する（ステップＳ４１）。
【００８２】
この判断により受信したコマンドがリードレコードコマンドであると判断した場合（ステップＳ４１、ＹＥＳ）、ＣＰＵ１１は、受信したリードレコードコマンドがバックアップ領域の読出しを要求するコマンドであるか否かを判定する（ステップＳ４２）。
【００８３】
上述したように、バックアップ領域の読出を要求する手法には、様々な形態が考えられる。たとえば、特定のコマンドの実行手順などによりバックアップ領域の読出要求を示すようにしても良いし、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出要求するようにしても良い。また、特定のコマンドの実行手順によりバックアップ領域の読出要求を示す形態としては、特定のコマンドが連続して与えられた場合に各バックアップ領域を順次読み出すようにしても良いし、複数種類のコマンドが特定の順序で与えられた場合に各バックアップ領域を順次読み出すようにしても良い。また、コマンドの内容（コマンドデータに含まれる情報）によって直接的にバックアップ領域の読出要求を示す形態としては、コマンドコードあるいは処理パラメータなどで各レコードの各バックアップ領域の読出を指定するようにすれば良い。上記のような運用形態に応じて、ＣＰＵ１１は、受信したコマンドがバックアップ領域の読出しを要求するコマンドであるか否かを判断するようになっている。
【００８４】
ここでは、図８に示す処理例のように、「カレントレコード」が指定されたリードレコードコマンドが与えられた場合に、カレントレコードの各バックアップ領域を順次読み出すようにするものとする。このような形態であれば、ＣＰＵ１１は、上記ステップＳ４２の処理として、当該コマンドにおいて読出対象とするレコードが、レコード番号で指定されている（あるいは、カレント以外のレコードが指定されている）か、「カレントレコード」として指定されているかを判定する（ステップＳ４２）。
【００８５】
上記リードレコードコマンドにおいてレコードの指定が「カレントレコード」である場合、つまり、受信コマンドがバックアップ領域の読出しを要求する場合（ステップＳ４２、ＹＥＳ）、ＣＰＵ１１は、現在のカレントレコードにバックアップ領域が設定されているか否かを判断する（ステップＳ４３）。
【００８６】
この判断によりカレントレコードにバックアップ領域が設定されていると判断した場合（ステップＳ４３、ＹＥＳ）、ＣＰＵ１１は、受信したコマンドの前までに受信したリードレコードコマンドによって当該レコードの全バックアップ領域のデータが読出し処理済みであるか否かを判断する（ステップＳ４４）。つまり、上記ステップＳ４４において、上記ＣＰＵ１１は、前回までに受信したリードコマンドによって全バックアップ領域のデータを読み出したか否かを判断する。
【００８７】
上記判断によりカレントレコードの全バックアップ領域のデータが読出し済みでないと判断した場合（ステップＳ４４、ＮＯ）、ＣＰＵ１１は、当該コマンドで指定されたレコード（カレントレコード）における各バックアップ領域のデータを順次読み出す（ステップＳ４５）。たとえば、上記ＣＰＵ１１は、バックアップ領域のデータを読み出すごとに、ワーキングメモリ１３に設けた図示しないカウンタをカウントアップする。これにより、連続してカレントレコードを指定するリードレコードコマンドを受けるごとに、ＣＰＵ１１は、カウンタの値に基づいて順に各バックアップ領域のデータを読み出す。
【００８８】
カレントレコードのバックアップ領域のデータを読み出すと、ＣＰＵ１１は、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ４６）。このように、上記ステップＳ４０〜Ｓ４６までの処理によって、当該ＩＣカード１では、カレントレコードのバックアップ領域のデータが読み出される。このような処理を繰り返すことで、当該ＩＣカード１は、各バックアップ領域のデータを順に読み出すことが可能となっている。
【００８９】
また、図８に示す処理例では、上記ステップＳ４２において、上記受信したコマンドにおいてレコードの指定が「カレントレコード」でない場合、つまり、受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ４２、ＮＯ）、ＣＰＵ１１は、当該リードレコードコマンドが指定レコードのデータ領域のデータ（最新のデータ）の読出しを要求するものであると判定する。ただし、カレントレコードを変更しないリードコマンドを受信した場合は、上記ステップＳ４３へ進むようにしても良い。
【００９０】
受信したコマンドにおけるレコードの指定がファイルＩＤとレコード番号とによるものである場合（ステップＳ４２、ＮＯ）、ＣＰＵ１１は、ファイルＩＤとレコード番号とにより読出対象とするレコード（指定されたレコード）を特定する（ステップＳ４８）。つまり、ＣＰＵ１１は、当該コマンドで指定されたファイルＩＤによりレコードファイルとしてのＥＦを特定し、さらに、レコード番号に基づいて当該ＥＦ内におけるレコードを特定する。この際、上記ＣＰＵ１１は、指定されたレコードをカレントレコードとする。
【００９１】
受信したコマンドで指定されているファイルＩＤ及びレコード番号によりレコードを特定すると、上記ＣＰＵ１１は、特定されたレコードのデータ領域のデータを読出し（ステップＳ４９）、当該コマンドの送信元であるＩＣカード処理装置２に読み出したデータを含むレスポンスデータを送信する（ステップＳ４６）。
【００９２】
また、図８に示す処理例では、ステップＳ４３でカレントレコードにバックアップ領域が設定されていないと判断した場合（ステップＳ４３、ＮＯ）、ＣＰＵ１１は、ステップＳ４９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うものとする。ただし、ステップＳ４３でＮＯと判断される場合は、バックアップ領域の読出しを要求するコマンドを受信したにも係らず、当該コマンドが指定するレコード（カレントレコード）にバックアップ領域が設定されていないと判断した場合である。このため、ＣＰＵ１１は、ステップＳ４７へ進み、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信するようにしても良い。
【００９３】
また、図８に示す処理例では、ステップＳ４４で全バックアップ領域のデータが直前のリードコマンドによって読出し済みであると判断した場合（ステップＳ４４、ＹＥＳ）、ＣＰＵ１１は、エラーであることを示すレスポンスを当該コマンドの送信元であるＩＣカード処理装置２に送信する（ステップＳ４７）。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合、連続して特定のレコード（カレントレコード）における全バックアップ領域のデータが読出し済みであることをエラー通知によって通知する仕組みである。
【００９４】
ただし、上記ステップＳ４４で全バックアップ領域のデータが直前までのリードコマンドで読出し済みであると判断した場合（ステップＳ４４、ＹＥＳ）、ＣＰＵ１１は、図８に点線で示すように、ステップＳ４９へ進み、カレントレコードのデータ領域のデータを読み出す処理を行うようにしても良い。これは、バックアップ領域の読出しを要求するコマンド（カレントレコードを指定したリードレコードコマンド）が連続して与えられた場合に、特定のレコード（カレントレコード）における各バックアップ領域の各データとデータ領域のデータとを順に読み出すようにする仕組みである。この場合、ＩＣカード処理装置２では、カレントレコードを指定したリードレコードコマンドを連続して与えることにより、ＩＣカード１からカレントレコードの各バックアップ領域のデータとデータ領域のデータとを順に読み出す制御が可能となる。
【００９５】
上記のような読出処理では、レコード番号を指定したリードコマンドに対しては、当該レコードのデータ領域に記憶されている最新のデータを読出し、カレントレコードを指定したリードコマンド（バックアップ領域のデータの読出しを要求するコマンド）に対しては、当該レコードのバックアップ領域に記憶されているデータを読み出すようになっている。つまり、データ領域のデータを読み出した後に連続して特定のレコードの読出しが要求される場合、各バックアップ領域のデータを順に読み出すようになっている。
【００９６】
これにより、擬似的な２次元配列ファイルに格納されている複数のバックアップデータを簡単な手順で順に読み出すことができ、レコード番号の管理などが複雑化することなく、取引履歴情報などの更新されることが予測されるデータについて最新のデータおよび更新前の複数のデータを容易に読み出すことができる。
【００９７】
なお、上述した第１あるいは第２の構成例のレコードファイルに対する更新処理あるいは読出処理は、種々の変形が可能である。以下、上述した実施の形態に対する変形例について説明する。
まず、第１の変形例として、各レコード毎に、全バックアップ領域のデータを一括して読み出す処理例について説明する。
【００９８】
すなわち、図８に示すような第２の構成例のレコードファイルに対する読出処理では、各レコードごとに各バックアップ領域のデータを順次読み出す処理について説明している。しかしながら、ＩＣカード１の運用形態によっては、各レコード毎に全バックアップ領域のデータを一括して読み出したい場合があると考えられる。このような場合、第２の構成例のようなレコードに対して全バックアップ領域のデータを一括して読み出す仕組みを設けることにより、効率的な処理が可能となると考えらえる。
【００９９】
各レコード毎に全バックアップ領域のデータを一括して読出す処理は、たとえば、リードレコードコマンドにおいて、全バックアップ領域を一括して読み出すことを要求するパラメータを定義しておくことにより実現できる。この場合、全バックアップ領域の一括読出しを指定するパラメータがカレントレコードを指定するリードレコードコマンドに含まれていれば、ＣＰＵ１１は、カレントレコードの全バックアップ領域のデータを一括して読み出し、一括して読み出した全バックアップ領域のデータをレスポンスデータとして出力するようにする。
【０１００】
また、各バックアップ領域のデータを順に読み出す必要がない運用形態である場合、つまり、常に全バックアップ領域のデータを読み出すような仕様とする場合、全バックアップ領域を１つのバックアップ領域として取り扱えば、図５に示す処理例と同様な処理が可能である。すなわち、バックアップ領域の読出しを要求するコマンドに対して全バックアップ領域のデータを読み出すようにすることにより、各レコード毎に全バックアップ領域のデータを一括して読出す処理が実現可能である。
【０１０１】
次に、第２の変形例として、１つのレコードファイル内の全レコードのバックアップ領域のデータを一括して読み出す処理例について説明する。
【０１０２】
すなわち、図５あるいは図８に示すような読出処理では、第１の構成例あるいは第２の構成例のレコードファイルに対して、各レコードごとにバックアップ領域のデータを読み出すようにしている。しかしながら、１つのレコードファイル内の各レコードは、互いに関連するデータを格納するものであることが想定される。このような場合、運用形態によっては、レコードファイル内の全レコードのバックアップ領域のデータを一括して読み出すことにより、処理が効率化できることがありうると考えられる。
【０１０３】
レコードファイル内の全レコードのバックアップ領域のデータを一括して読出す処理は、たとえば、リードコマンドにおいて、レコードファイル内の全レコードのバックアップ領域を一括して読み出すことを指定するパラメータを定義しておくことにより実現できる。この場合、レコードファイル内の全レコードのバックアップ領域の一括読出しを指定するパラメータがリードコマンドに含まれていれば、ＣＰＵ１１は、指定されるレコードファイル（たとえばカレント状態のレコードファイル）における全レコードのバックアップ領域のデータを一括して読み出し、読み出した全レコードのバックアップ領域のデータをレスポンスデータとして出力するようにする。これにより、第１の構成例あるいは第２の構成例のようなレコードであっても、レコードファイル内の全レコードのバックアップ領域を一括して読み出す処理が実現できる。
【０１０４】
次に、第３の変形例として、データ領域のデータ異常で読み出しが失敗した場合の処理例について説明する。
上述した更新処理では、データ領域のデータをバックアップ領域に移動させた後に、当該データ領域へのデータの書込みが失敗した場合、当該データ領域にバックアップ領域に移動させたデータを再度書き込むという復旧処理について説明している。同様に、読出処理においても、データ領域のデータ異常が発見された場合、バックアップ領域に格納されている最も新しいデータ（前回の更新直前のデータ）で当該データ領域を復旧させることが可能である。
【０１０５】
たとえば、図５のステップＳ２９あるいは図８のステップＳ４９として説明したデータ領域のデータの読出し処理において、データ領域のデータ異常で読出に失敗した場合、バックアップ領域に格納されている最も新しいデータをデータ領域に書き込むようにすれば良い。この場合、読出処理の結果としては、エラー通知を行うようにしても良いし、データ領域に書込んだデータを出力するようにしても良い。
【０１０６】
また、上記のようなデータ領域のデータの復旧処理は、ＩＣカード処理装置２からの復旧を要求するコマンドに応じて実行するようにしても良い。すなわち、ＩＣカード処理装置２からデータ領域のデータの読出を要求するコマンドに対して当該データ領域のデータ異常で読出に失敗した場合、ＩＣカード１は、当該データ領域のデータが異常である旨をエラー通知とともに出力し、その後、ＩＣカード処理装置２からのデータ領域の復旧を要求するコマンドに応じて、上記のようなデータ領域のデータの復旧処理を実行するようにしても良い。
【０１０７】
また、上記のような読出処理においてデータ領域のデータ異常が発見された場合、データ領域にデータを書き込むことなく、データ領域のデータの代りにバックアップ領域に格納している最も新しいデータ（前回の更新直前のデータ）を出力するようにしても良い。この場合、読み出したデータとともに、データ領域のデータの代りにバックアップ領域のデータを読み出した事を通知するようにする。これにより、データ領域がメモリ異常などにより使用不能となった場合であっても、データ領域のデータが異常であることを通知するとともに、バックアップ領域のデータをデータ領域のデータの代わりとして出力することが可能となる。
【図面の簡単な説明】
【０１０８】
【図１】本実施の形態に係るＩＣカードおよびＩＣカードを含むシステムの構成例を示すブロック図。
【図２】非接触式ＩＣカードの全体の構成例を示す図。
【図３】レコードファイルの第１の構成例を示す図。
【図４】第１の構成例のレコードファイルに対するデータ書込み処理の例を説明するためのフローチャート。
【図５】第１の構成例のレコードファイルに対するデータ読出し処理の例を説明するためのフローチャート。
【図６】レコードファイルの第２の構成例を示す図。
【図７】第２の構成例のレコードファイルに対するデータ書込み処理の例を説明するためのフローチャート。
【図８】第２の構成例のレコードファイルに対するデータ読出し処理の例を説明するためのフローチャート。
【符号の説明】
【０１０９】
Ｃ…本体、Ｍ…モジュール、１…ＩＣカード、１ａ…ＩＣチップ、２…ＩＣカード処理装置、１１…ＣＰＵ、１２…プログラムメモリ、１３…ワーキングメモリ、１４…データメモリ、１５…通信制御部、１６…電源部、１７…インターフェース、２１…制御装置、２２…カードリーダライタ。
【特許請求の範囲】
【請求項１】
外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置において、
１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードを記憶する記憶手段と、
前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新する更新手段と、
前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す読出手段と、
を有することを特徴とする携帯可能電子装置。
【請求項２】
前記レコードは、１つのデータ領域に対応して複数のデータ退避領域を有し、
前記更新手段は、前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられる毎に、前記データ領域および各データ退避領域に記憶されている各データを順次移動させ、前記データ領域のデータを更新する、
ことを特徴とする前記請求項１に記載の携帯可能電子装置。
【請求項３】
前記更新手段は、前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられた場合に、前記レコードにデータが記憶されていないデータ退避領域がなければ、前記レコードの各データ退避領域に記憶されているデータのうち最も古いデータを削除して、前記データ領域のデータを前記データ退避領域に移動させ、前記データ領域のデータを更新する、
ことを特徴とする前記請求項２に記載の携帯可能電子装置。
【請求項４】
前記読出手段は、前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが連続して与えられる毎に、前記レコードの各データ退避領域に記憶されている各データを順次読み出す、
ことを特徴とする前記請求項２又は３に記載の携帯可能電子装置。
【請求項５】
さらに、前記外部装置から前記レコードの各データ退避領域に記憶されている全データを一括して読み出すことを要求するコマンドが与えられた場合、前記レコードの全データ退避領域に記憶されている全データを一括して読み出す一括読出手段を有する、
ことを特徴とする前記請求項２乃至４の何れか１項に記載の携帯可能電子装置。
【請求項６】
前記記憶手段は、複数のレコードからなるレコードファイルを記憶し、
さらに、前記外部装置から前記記憶手段に記憶されている前記レコードファイルの全レコードの全データ退避領域に記憶されている全データを一括して読み出すことを要求するコマンドが与えられた場合、前記記憶手段に記憶されている前記レコードファイルの全レコードの全データ退避領域に記憶されている全データを一括して読み出す一括読出手段を有する、
ことを特徴とする前記請求項２乃至４の何れか１項に記載の携帯可能電子装置。
【請求項７】
さらに、前記更新手段により前記データ領域のデータを最新のデータを更新することに失敗した場合、前記データ領域から前記データ退避領域に移動させたデータを再度前記データ領域に書き込む復旧手段を有する、
ことを特徴とする前記請求項１乃至６の何れか１項に記載の携帯可能電子装置。
【請求項８】
さらに、前記データ領域に格納されているデータの異常により前記データ領域からのデータの読出しが失敗した場合、前記データ退避領域に記憶されているデータを前記データ領域に書き込む復旧手段を有する、
ことを特徴とする前記請求項１乃至６の何れか１項に記載の携帯可能電子装置。
【請求項９】
前記データ領域のデータ異常により前記データ領域からのデータの読出しが失敗した場合、前記データ領域のデータの代わりに前記データ退避領域に記憶されているデータを読出す処理手段を有する、
ことを特徴とする前記請求項１乃至８の何れか１項に記載の携帯可能電子装置。
【請求項１０】
前記処理手段は、前記データ領域のデータの代わりに前記データ退避領域に記憶されているデータを読出した場合、前記データ退避領域から読み出したデータと共に、前記データ領域のデータの読出し異常のため前記データ退避領域のデータを読み出した事を示す応答を出力する、
ことを特徴とする前記請求項９に記載の携帯可能電子装置。
【請求項１１】
外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置におけるデータ管理方法であって、
前記外部装置から１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードのデータの更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新し、
前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す、
ことを特徴とする携帯可能電子装置におけるデータ管理方法。
【請求項１】
外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置において、
１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードを記憶する記憶手段と、
前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新する更新手段と、
前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す読出手段と、
を有することを特徴とする携帯可能電子装置。
【請求項２】
前記レコードは、１つのデータ領域に対応して複数のデータ退避領域を有し、
前記更新手段は、前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられる毎に、前記データ領域および各データ退避領域に記憶されている各データを順次移動させ、前記データ領域のデータを更新する、
ことを特徴とする前記請求項１に記載の携帯可能電子装置。
【請求項３】
前記更新手段は、前記外部装置から前記レコードのデータ更新を要求するコマンドが与えられた場合に、前記レコードにデータが記憶されていないデータ退避領域がなければ、前記レコードの各データ退避領域に記憶されているデータのうち最も古いデータを削除して、前記データ領域のデータを前記データ退避領域に移動させ、前記データ領域のデータを更新する、
ことを特徴とする前記請求項２に記載の携帯可能電子装置。
【請求項４】
前記読出手段は、前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが連続して与えられる毎に、前記レコードの各データ退避領域に記憶されている各データを順次読み出す、
ことを特徴とする前記請求項２又は３に記載の携帯可能電子装置。
【請求項５】
さらに、前記外部装置から前記レコードの各データ退避領域に記憶されている全データを一括して読み出すことを要求するコマンドが与えられた場合、前記レコードの全データ退避領域に記憶されている全データを一括して読み出す一括読出手段を有する、
ことを特徴とする前記請求項２乃至４の何れか１項に記載の携帯可能電子装置。
【請求項６】
前記記憶手段は、複数のレコードからなるレコードファイルを記憶し、
さらに、前記外部装置から前記記憶手段に記憶されている前記レコードファイルの全レコードの全データ退避領域に記憶されている全データを一括して読み出すことを要求するコマンドが与えられた場合、前記記憶手段に記憶されている前記レコードファイルの全レコードの全データ退避領域に記憶されている全データを一括して読み出す一括読出手段を有する、
ことを特徴とする前記請求項２乃至４の何れか１項に記載の携帯可能電子装置。
【請求項７】
さらに、前記更新手段により前記データ領域のデータを最新のデータを更新することに失敗した場合、前記データ領域から前記データ退避領域に移動させたデータを再度前記データ領域に書き込む復旧手段を有する、
ことを特徴とする前記請求項１乃至６の何れか１項に記載の携帯可能電子装置。
【請求項８】
さらに、前記データ領域に格納されているデータの異常により前記データ領域からのデータの読出しが失敗した場合、前記データ退避領域に記憶されているデータを前記データ領域に書き込む復旧手段を有する、
ことを特徴とする前記請求項１乃至６の何れか１項に記載の携帯可能電子装置。
【請求項９】
前記データ領域のデータ異常により前記データ領域からのデータの読出しが失敗した場合、前記データ領域のデータの代わりに前記データ退避領域に記憶されているデータを読出す処理手段を有する、
ことを特徴とする前記請求項１乃至８の何れか１項に記載の携帯可能電子装置。
【請求項１０】
前記処理手段は、前記データ領域のデータの代わりに前記データ退避領域に記憶されているデータを読出した場合、前記データ退避領域から読み出したデータと共に、前記データ領域のデータの読出し異常のため前記データ退避領域のデータを読み出した事を示す応答を出力する、
ことを特徴とする前記請求項９に記載の携帯可能電子装置。
【請求項１１】
外部装置から与えられるコマンドに応じて処理を行う携帯可能電子装置におけるデータ管理方法であって、
前記外部装置から１つのデータ領域と少なくとも１つのデータ退避領域とを有するレコードのデータの更新を要求するコマンドが与えられた場合、前記レコードの前記データ領域に記憶されているデータを前記データ退避領域へ移動させ、前記データ領域のデータを更新し、
前記外部装置から前記レコードの前記データ退避領域に記憶されているデータの読出を要求するコマンドが与えられた場合、前記レコードの前記データ退避領域に記憶されているデータを読み出す、
ことを特徴とする携帯可能電子装置におけるデータ管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００９−７５８１６（Ｐ２００９−７５８１６Ａ）
【公開日】平成２１年４月９日（２００９．４．９）
【国際特許分類】
【出願番号】特願２００７−２４３５６８（Ｐ２００７−２４３５６８）
【出願日】平成１９年９月２０日（２００７．９．２０）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２１年４月９日（２００９．４．９）
【国際特許分類】
【出願日】平成１９年９月２０日（２００７．９．２０）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]