JP6252341B2 - 電子情報記憶媒体、情報処理方法、及び情報処理プログラム - Google Patents

Description

ＴＬＶ構造のレコードを格納するデータ格納領域と書き込み保証用のバッファ領域を有する不揮発性メモリを備えるＩＣチップ等の電子情報記憶媒体の技術分野に関する。

従来から、ＩＣチップでは、不揮発性メモリへの書き込み処理中の引き抜き等による電源供給の中断に対処するため、トランザクション（Transaction）という仕組みが利用されている。トランザクションとは、特定の一連の処理の開始前もしくは終了後のどちらかの状態のみを取り得る仕組みのことをいう。この仕組みにより、不揮発性メモリのデータ格納領域に格納されるレコードが中途半端な内部状態とならないようにしている。特許文献１には、不揮発性メモリの書き込み先に対してデータの書き込み処理を行なっている途中で、ＩＣカードリーダライターからＩＣカードが引き抜かれたり、また電源瞬断などが発生するなどでデータの書き込み処理が失敗した場合でも、この書き込みデータが破壊されることがないように構成されている。

ところで、ＩＣチップでは、ＴＬＶ（タグ（Tag）、データ長（Length）、データ値（Value））構造のレコード（データオブジェクト）を不揮発性メモリに書き込む場合、データの整合性を担保するため、不揮発性メモリに格納されているレコード、及びレコード管理情報（格納済みレコード数、レコードのチェックコードなど）を１回のトランザクションで更新するようになっている。このトランザクションにおける書き込み保証機能では、当該トランザクション中、更新用のレコード（更新後のレコード）を書き込み保証用のバッファ領域に格納した後に、当該データ格納領域のレコードを更新し、当該更新をコミットするように構成されている。更新用のレコード（不揮発性メモリに書き込むレコード）のデータ長（レコード長）が上記バッファ領域の容量以下の場合、１回のトランザクションで更新が完了し、コミットするまでに更新が中断しても、レコード及びレコード数などの整合性を保証することができる。

特開２００８−９５２１号公報

しかしながら、更新用のレコードのデータ長が上記バッファ領域の容量を超える場合、複数回のコミットが行われるため、書き込み処理中の引き抜き等により更新が中断した場合、データの整合性が保証できないことがある。例えば、更新前のデータ値が途中から出力、つまり、意図しないデータ（中途半端なデータ）が外部に出力される可能性がある。

そこで、本発明は、更新用のレコードのデータ長がバッファ領域の容量を超える場合であっても、意図しないデータが外部に出力されることを回避することが可能な電子情報記憶媒体、情報処理方法、及び情報処理プログラムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、少なくともデータ値を示すデータと当該データ値のデータ長を示すデータとを含んで構成されるレコードを格納するデータ格納領域と、バッファ領域とを少なくとも有する不揮発性メモリと、更新用のレコードで前記データ格納領域のレコードを更新する際に、当該更新用のレコードの全部又は一部を前記バッファ領域に格納した後に、当該データ格納領域のレコードを更新し、当該更新をコミットするプロセッサと、を備える電子情報記憶媒体において、前記プロセッサは、前記更新用のレコードのデータ長が前記バッファ領域の容量を超える場合、前記データ格納領域のレコードに含まれる前記データ長を示すデータを、データがないことを示す値に更新し、当該更新をコミットする第１更新手段と、前記第１更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち前記バッファ領域の容量分のデータ値を示すデータで、前記データ格納領域のレコードに含まれる前記データ長を示すデータ以外の前記データを更新し、当該更新をコミットする第２更新手段と、前記第２更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータで、前記データ格納領域のレコードに含まれる更新されていない残りのデータを更新し、当該更新をコミットする第３更新手段と、前記更新用のレコードに含まれる全データが更新に利用された場合、前記更新用のレコードに含まれるデータ長を示すデータで、前記データ格納領域のレコードに含まれるデータ長を示すデータを更新し、当該更新をコミットする第４更新手段と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載の電子情報記憶媒体において、前記データがないことを示す値は０であることを特徴とする。

請求項３に記載の発明は、請求項１または２に記載の電子情報記憶媒体において、前記第３更新手段は、前記更新用のレコードに含まれるデータ値を示すデータが全てが更新に利用されるまで、更新に利用されていないデータ値を示すデータで、前記データ格納領域のレコードに含まれる更新されていないデータ値を示すデータを更新し、当該更新をコミットすることを繰り返すことを特徴とする。

請求項４に記載の発明は、少なくともデータ値を示すデータと当該データ値のデータ長を示すデータとを含んで構成されるレコードを格納するデータ格納領域と、バッファ領域とを少なくとも有する不揮発性メモリと、更新用のレコードで前記データ格納領域のレコードを更新する際に、当該データ格納領域のレコードの全部又は一部を前記バッファ領域にバックアップした後に、当該データ格納領域のレコードを更新し、当該更新をコミットするプロセッサと、を備える電子情報記憶媒体において前記プロセッサにより実行される情報処理方法であって、前記更新用のレコードのデータ長が前記バッファ領域の容量を超える場合、前記データ格納領域のレコードに含まれる前記データ長を示すデータを、データがないことを示す値に更新し、当該更新をコミットする第１更新ステップと、前記第１更新ステップによるコミット後に、前記更新用のレコードに含まれる全データのうち前記バッファ領域の容量分のデータ値を示すデータで、前記データ格納領域のレコードに含まれる前記データ長を示すデータ以外の前記データを更新し、当該更新をコミットする第２更新ステップと、前記第２更新ステップによるコミット後に、前記更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータで、前記データ格納領域のレコードに含まれる更新されていない残りのデータを更新し、当該更新をコミットする第３更新ステップと、前記更新用のレコードに含まれる全データが更新に利用された場合、前記更新用のレコードに含まれるデータ長を示すデータで、前記データ格納領域のレコードに含まれるデータ長を示すデータを更新し、当該更新をコミットする第４更新ステップと、を含むことを特徴とする。

請求項５に記載の発明は、少なくともデータ値を示すデータと当該データ値のデータ長を示すデータとを含んで構成されるレコードを格納するデータ格納領域と、バッファ領域とを少なくとも有する不揮発性メモリと、更新用のレコードで前記データ格納領域のレコードを更新する際に、当該更新用のレコードの全部又は一部を前記バッファ領域に格納した後に、当該データ格納領域のレコードを更新し、当該更新をコミットするプロセッサと、を備える電子情報記憶媒体における前記プロセッサを、前記更新用のレコードのデータ長が前記バッファ領域の容量を超える場合、前記データ格納領域のレコードに含まれる前記データ長を示すデータを、データがないことを示す値に更新し、当該更新をコミットする第１更新手段と、前記第１更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち前記バッファ領域の容量分のデータ値を示すデータで、前記データ格納領域のレコードに含まれる前記データ長を示すデータ以外の前記データを更新し、当該更新をコミットする第２更新手段と、前記第２更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータで、前記データ格納領域のレコードに含まれる更新されていない残りのデータを更新し、当該更新をコミットする第３更新手段と、前記更新用のレコードに含まれる全データが更新に利用された場合、前記更新用のレコードに含まれるデータ長を示すデータで、前記データ格納領域のレコードに含まれるデータ長を示すデータを更新し、当該更新をコミットする第４更新手段として機能させることを特徴とする。

本発明によれば、更新用のレコードのデータ長がバッファ領域の容量を超える場合であっても、意図しないデータが外部に出力されることを回避することができる。

ＩＣカード１の概要構成例を示す図である。 ＣＰＵ１０のコマンド受信時の処理の一例を示すフローチャートである。 データ格納領域のレコードの一例と、更新用のレコードの一例とを示す図である。 更新レコード長がバッファ領域の容量を超えている場合に従来の処理が行われた場合に、データ格納領域のデータが更新されていく様子と、コミットの前後で処理が中断した場合において読み出されるレコードとを示す図である。 更新レコード長がバッファ領域の容量を超えている場合に本発明の処理が行われた場合に、データ格納領域のデータが更新されていく様子と、コミットの前後で処理が中断した場合において読み出されるレコードとを示す図である。

以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、ＩＣカードに対して本発明を適用した場合の実施の形態である。

先ず、図１を参照して、本実施形態に係るＩＣカード１の構成及び機能概要について説明する。図１は、ＩＣカード１の概要構成例を示す図である。なお、ＩＣカード１は、キャッシュカード、クレジットカード、社員カード等として使用される。或いは、ＩＣカード１は、スマートフォンや携帯電話機等の通信機器に組み込まれる。ＩＣチップ１ａは通信機器の回路基板上に直接組み込んで構成するようにしてもよい。

ＩＣカード１には、図１に示すように、ＩＣチップ１ａが搭載されている。ＩＣチップ１ａは、本発明の電子情報記憶媒体の一例である。ＩＣチップ１ａは、ＣＰＵ（Central Processing Unit）１０、ＲＡＭ（Random Access Memory）１１、ＲＯＭ（Read Only Memory）１２、不揮発性メモリ１３、及びＩ／Ｏ回路１４を備えて構成される。なお、Ｉ／Ｏ回路１４は、外部端末２とのインターフェイスを担う。ＩＣカード１が接触ＩＣカードの場合、Ｉ／Ｏ回路１４には、例えばＩＳＯ／ＩＥＣ７８１６によって定められたＣ１〜Ｃ８の８個の端子が設けられている。例えば、Ｃ１端子は電源端子、Ｃ２端子はリセット端子、Ｃ３端子はクロック端子、Ｃ５端子はグランド端子、Ｃ７端子は外部端末２とのデータ通信を行う端子である。なお、この例では、接触式のＩＣカードの例を示したが、外部端末２に近づくことにより、磁界をエネルギーとして無結線状態で電源供給され（電圧印加され）、動作する非接触式のＩＣカード（アンテナ及び変復調回路を含む）であってもよい。外部端末２の例としては、ＩＣカード発行機、ＡＴＭ、改札機、認証用ゲート等が挙げられる。或いは、ＩＣカード１が通信機器に組み込まれる場合、外部端末２には通信機器の機能を担うコントローラが該当する。

ＣＰＵ１０は、ＲＯＭ１２または不揮発性メモリ１３に記憶されたプログラム（本発明の情報処理プログラムを含む）を実行するプロセッサ（コンピュータ）である。ＣＰＵ１０は、記憶されたプログラムに従って後述する処理を実行する。不揮発性メモリ１３は、例えばフラッシュメモリが適用される。なお、不揮発性メモリ１３は、「Electrically Erasable Programmable Read-Only Memory」であっても構わない。不揮発性メモリ１３には、データ格納領域、及び書き込み保証用のバッファ領域等を有する。データ格納領域には、例えばＩＳＯ／ＩＥＣ７８１６−４によって定められたＭＦ（Master File）、ＤＦ(Dedicated File)、及びＥＦ(Elementary File)などから構成される階層構造を有する複数のファイルが定義される。ＭＦは、データ格納領域におけるファイル構成において最上位に位置し、ＭＦの下位階層にはＤＦ及びＥＦが位置する。ＤＦは、例えばアプリケーションプログラムごとに設けられる。ＥＦは、例えば、ＤＦに格納されるアプリケーションプログラムで使用される複数のレコード（データオブジェクト）を格納するレコードファイルである。レコードは、レコードの識別子であるタグ（Tag）を示すデータ、データ値（Value）のデータ長（Length）を示すデータ、及びデータ値（Value）を示すデータを含んで構成される。なお、データ格納領域には、レコード管理情報として、ページごとに対応するデータ誤り検出符号（例えば、ＣＲＣ（Cyclic Redundancy Check））、及びレコード数が格納される。ページとは、データの読み書きが行われる最小単位（例えば１２８バイト、２５６バイト、または５１２バイト）をいう。

ＣＰＵ１０は、例えば外部端末２からＩ／Ｏ回路１４を介して受信されたコマンド（例えば、書き込みコマンド）により指定された更新用のレコードでデータ格納領域のレコードを更新する際に、トランザクションにより、当該更新用のレコード（更新後のレコード）の全部又は一部をバッファ領域に格納した後に当該データ格納領域のレコードを更新し、当該更新をコミットすることを前提とする。

そして、ＣＰＵ１０は、本発明における第１更新手段、第２更新手段、第３更新手段、及び第４更新手段として機能する。具体的には、ＣＰＵ１０は、コマンドにより指定された更新用のレコード（レコードデータ）のデータ長（以下、「更新レコード長」という）がバッファ領域の容量を超える場合、更新用のレコードに含まれるタグ（Tag）を示すデータで、データ格納領域のレコードに含まれるタグ（Tag）を示すデータを更新し、且つ、データ格納領域のレコードに含まれるデータ長（Length）を示すデータを、データがないことを示す値（例えば、０）に更新し、当該更新をコミット（１回目のコミット）する。

ここで、コマンドは、例えば、ＡＰＤＵ(Application Protocol Data Unit)として外部端末２から送信される。ＡＰＤＵとして送られるコマンドは、ＣＬＡ部、ＩＮＳ部、Ｐ１部、Ｐ２部、Ｌｃ部、Ｄａｔａ部、Ｌｅ部から構成される。ＣＬＡ部及びＩＮＳ部は、コマンドの種類を示す情報を格納する。Ｐ１部及びＰ２部は、コマンド処理におけるパラメータを格納する。Ｌｃ部は、Ｄａｔａ部のデータ長（本実施形態では、更新レコード長）を格納する。Ｄａｔａ部は、更新用のレコード（レコードデータ）を格納する。Ｌｅ部は、コマンドをチェックするための情報を格納する。また、コミットとは、レコードの更新を確定する処理であり、例えばレコードごとに記憶された更新完了フラグを“１”にセットする処理である。言い換えれば、コミットとは、バッファ領域に格納されたデータをデータ格納領域に反映して、更新完了フラグを“１”にセットする処理ということもできる。

ＣＰＵ１０は、１回目のコミット後に、更新用のレコードに含まれる全データのうちバッファ領域の容量分のデータ値（Value）を示すデータ（つまり、データ値（Value）を示すデータの一部）で、データ格納領域のレコードに含まれるタグ（Tag）及びデータ長（Length）を示すデータ以外のデータ（例えば、データ値（Value）を示すデータの一部）を更新し、当該更新をコミット（２回目のコミット）する。そして、ＣＰＵ１０は、２回目のコミット後に、更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータ値（Value）を示すデータで、データ格納領域のレコードに含まれる更新されていない残りのデータ値（Value）を示すデータを更新し、当該更新をコミット（３回目のコミット）する。そして、ＣＰＵ１０は、３回目のコミット後に、更新用のレコードに含まれるデータ値（Value）を示すデータの全てが更新に利用された場合、更新用のレコードに含まれるデータ長（Length）を示すデータで、データ格納領域のレコードに含まれるデータ長（Length）を示すデータを更新し、当該更新をコミット（４回目のコミット）する。なお、ＣＰＵ１０は、２回目のコミット後、更新用のレコードに含まれるデータ値（Value）を示すデータの全てが更新に利用されるまで、更新に利用されていないデータ値（Value）を示すデータで、データ格納領域のレコードに含まれる更新されていないデータ値（Value）を示すデータを更新し、当該更新をコミットすることを繰り返すことになる。

次に、図２及び図３等を参照して、ＩＣカード１ａにおけるＣＰＵ１０のコマンド受信時の処理の一例について説明する。図２は、ＣＰＵ１０のコマンド受信時の処理の一例を示すフローチャートである。図３は、データ格納領域のレコードの一例と、更新用のレコードの一例とを示す図である。図３の例では、データ格納領域のレコードのデータ長（以下、「格納済みレコード長」という）は２５バイトであり（図３（Ａ））、更新用のレコードの更新レコード長は２０バイトである（図３（Ｂ））。なお、図３の例では、データ格納領域のレコード、及び更新用のレコードそれぞれに含まれるデータを１６進数（ｈ）で表している。例えば、データ格納領域のレコードに含まれるデータ長（Length）を示すデータは１７（ｈ）となっているが、これは１０進数で２３である。従って、データ格納領域のレコードに含まれるデータ値（Value）を示すデータのデータ長は２３バイトである。一方、更新用のレコードに含まれるデータ長（Length）を示すデータは１２（ｈ）となっているが、これは１０進数で１８である。従って、データ格納領域のレコードに含まれるデータ値（Value）を示すデータのデータ長は１８バイトである。

図２に示す処理は、ＣＰＵ１０が、例えば外部端末２からＩ／Ｏ回路１４を介してコマンドを受信することにより開始される。図２に示す処理が開始されると、ＣＰＵ１０は、受信されたコマンドで指定された更新用のレコードの更新レコード長が、バッファ領域の容量を超えているか否か判定する（ステップＳ１）。ＣＰＵ１０は、更新レコード長がバッファ領域の容量を超えていないと判定した場合（ステップＳ１：ＮＯ）、ステップＳ２へ進む。なお、ステップＳ２〜Ｓ６の処理は、従来の処理と同様である。一方、ＣＰＵ１０は、更新レコード長がバッファ領域の容量を超えていると判定した場合（ステップＳ１：ＹＥＳ）、ステップＳ７へ進む。

ステップＳ２では、ＣＰＵ１０は、トランザクションを開始し、受信されたコマンドが含む更新用のレコードをバッファ領域に格納する。次いで、ＣＰＵ１０は、データ格納領域のレコード（つまり、タグ（Tag）、データ長（Length）、及びデータ値（Value）を示すデータ）を、バッファ領域に格納された更新用のレコードで更新（上書き（データ反映））する（ステップＳ３）。次いで、ＣＰＵ１０は、レコード管理情報を更新する（ステップＳ４）。レコード管理情報の更新では、例えば、更新されたレコードのＣＲＣが計算されて格納される。次いで、ＣＰＵ１０は、トランザクションを終了し（ステップＳ５）、ステップＳ３及びステップＳ４での更新をコミットし（ステップＳ６）、図２に示す処理を終了する。

ここで、更新レコード長がバッファ領域の容量を超えている場合に、従来の処理が行われた場合について説明する。図４は、更新レコード長がバッファ領域の容量を超えている場合に従来の処理が行われた場合、データ格納領域のデータが更新されていく様子と、コミットの前後で処理が中断した場合において読み出されるレコード（読み出しレコード）とを示す図である。なお、図４の例では、不揮発性メモリ１３における書き込み保証用のバッファ領域の容量を１６バイトとしている。この場合、更新用のレコードに含まれる全データのうち、その先頭からバッファ領域の容量分のデータ（つまり、更新対象のレコードの一部）で、データ格納領域のレコードに含まれる全データのうち、そのデータの先頭からバッファ領域の容量分のデータが更新される（図４（２））。そして、１回目のコミットが行われる（図４（３））。その後、更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータ（つまり、データ値（Value）を示すデータの一部）で、データ格納領域のレコードに含まれる更新されていない残りのデータが更新され（図４（４））、２回目のコミットが行われる（図４（５））。このように、従来の処理が行われる場合において、２回目のコミット完了前に処理が中断した場合の読み出しレコードに含まれるデータは、図４（Ｂ）に示すように中途半端なデータとなる。すなわち、当該レコードに含まれるデータ長（Length）を示すデータは１２（ｈ）にコミット済であるため、当該レコードに含まれるデータ値（Value）を示すデータは、更新済のデータと更新前のデータとが混在してしまうことになる。このような中途半端なデータは、ＣＲＣでは異常判定できないため（ＣＲＣ計算後にコミットがなされるため）、正しいデータとして出力されてしまうことになる。

一方、図５は、更新レコード長がバッファ領域の容量を超えている場合に本発明の処理が行われた場合に、データ格納領域のデータが更新されていく様子と、コミットの前後で処理が中断した場合において読み出されるレコードとを示す図である。なお、図５の例でも、不揮発性メモリ１３における書き込み保証用のバッファ領域の容量を１６バイトとしている。この場合、ＣＰＵ１０は、ステップＳ７において、トランザクションを開始し、受信されたコマンドが含む更新用のレコードに含まれる全データのうち、タグ（Tag）を示すデータ及びデータがないことを示す値（例えば、００（ｈ））（つまり、更新対象のレコードの一部）をバッファ領域に格納する。次いで、ＣＰＵ１０は、バッファ領域に格納されたタグ（Tag）を示すデータで、データ格納領域のレコードに含まれるタグ（Tag）を示すデータを更新し、且つ、データ格納領域のレコードに含まれるデータ長（Length）を示すデータを、例えば００（ｈ）（バッファ領域に格納された「データがないことを示す値」）に更新（００（ｈ）で上書き）する（ステップＳ８、図５（２））。次いで、ＣＰＵ１０は、トランザクションを終了し（ステップＳ９）、ステップＳ８での更新をコミット（１回目のコミット）する（ステップＳ１０、図５（３））。

次いで、ＣＰＵ１０は、未更新のデータ値（Value）を示すデータのデータ長が、バッファ領域の容量を超えているか否かを判定する（ステップＳ１１）。ここで、未更新のデータ値（Value）を示すデータとは、更新用のレコードに含まれるデータ値（Value）を示すデータのうち、更新に利用されていないデータである。ＣＰＵ１０は、未更新のデータ値（Value）を示すデータのデータ長が、バッファ領域の容量を超えていると判定した場合（ステップＳ１１：ＹＥＳ）、ステップＳ１２へ進む。一方、ＣＰＵ１０は、未更新のデータ値（Value）を示すデータのデータ長が、バッファ領域の容量を超えていないと判定した場合（ステップＳ１１：ＮＯ）、ステップＳ１６へ進む。

ステップＳ１２では、ＣＰＵ１０は、トランザクションを開始し、更新用のレコードに含まれる更新に利用されていないデータ値（Value）を示すデータのうち、バッファ領域の容量分のデータ（つまり、当該データ値（Value）を示すデータの一部）をバッファ領域に格納する。次いで、ＣＰＵ１０は、バッファ領域に格納されたデータ値（Value）を示すデータ（更新に利用されていない残りのデータ）で、データ格納領域のレコードに含まれる更新されていないデータ値（Value）を示すデータを更新する（ステップＳ１３、図５（４））。次いで、ＣＰＵ１０は、トランザクションを終了し（ステップＳ１４）、ステップＳ１３での更新をコミット（２回目のコミット）し（ステップＳ１５、図５（５））、ステップＳ１１に戻る。なお、ステップＳ１１〜Ｓ１５の処理は、更新用のレコードに含まれるデータ値（Value）を示すデータの全てが更新に利用されるまで、繰り返されることになる。

ステップＳ１６では、ＣＰＵ１０は、トランザクションを開始し、更新用のレコードに含まれる更新に利用されていないデータ値（Value）を示すデータをバッファ領域に格納する。次いで、ＣＰＵ１０は、バッファ領域に格納された残りのデータ値（Value）を示すデータで、データ格納領域のレコードに含まれる更新されていないデータ値（Value）を示すデータを更新する（ステップＳ１７、図５（６））。次いで、ＣＰＵ１０は、トランザクションを終了し（ステップＳ１８）、ステップＳ１７での更新をコミット（３回目のコミット）する（ステップＳ１９、図５（７））。

次いで、ＣＰＵ１０は、ステップＳ２０において、トランザクションを開始し、更新用のレコードに含まれるデータ長（Length）を示すデータをバッファ領域に格納する。次いで、ＣＰＵ１０は、バッファ領域に格納されたデータ長（Length）を示すデータで、データ格納領域のレコードに含まれるデータ長（Length）を示すデータを更新する（ステップＳ２１。図５（８））。次いで、ＣＰＵ１０は、上記ステップＳ４と同様、レコード管理情報を更新する（ステップＳ２２）。次いで、ＣＰＵ１０は、トランザクションを終了し（ステップＳ２３）、ステップＳ２０での更新をコミット（４回目のコミット）する（ステップＳ２４、図５（９））。

このように、本発明の処理が行われる場合において、４回目のコミット完了前に処理が中断した場合の読み出しレコードに含まれるデータは、図５（Ｂ）に示すように、当該レコードに含まれるデータ長（Length）を示すデータは００（ｈ）にコミット済であるため、当該レコードに含まれるデータ値（Value）を示すデータは無となる。そのため、中途半端なデータが出力されない。

以上説明したように、上記実施形態によれば、更新レコード長がバッファ領域の容量を超える場合、データ格納領域のレコードに含まれるデータ長（Length）を示すデータを、データがないことを示す値（例えば、０）に更新し、当該更新をコミットした後、データ格納領域のレコードに含まれるデータ値（Value）を示すデータを更新及びコミットし、更新用のレコードに含まれるデータ値（Value）を示すデータの全てが更新に利用された場合、更新用のレコードに含まれるデータ長（Length）を示すデータで、データ格納領域のレコードに含まれるデータ長（Length）を示すデータを更新し、当該更新をコミットするように構成したので、更新レコード長がバッファ領域の容量を超える場合であっても、利用者が意図しないデータ（中途半端なデータ）が外部に出力されることを回避することができる。

１ ＩＣカード
１ａ ＩＣチップ
２ 外部端末
１０ ＣＰＵ
１１ ＲＡＭ
１２ ＲＯＭ
１３ 不揮発性メモリ
１４ Ｉ／Ｏ回路

Claims (5)

1. 少なくともデータ値を示すデータと当該データ値のデータ長を示すデータとを含んで構成されるレコードを格納するデータ格納領域と、バッファ領域とを少なくとも有する不揮発性メモリと、
   更新用のレコードで前記データ格納領域のレコードを更新する際に、当該更新用のレコードの全部又は一部を前記バッファ領域に格納した後に、当該データ格納領域のレコードを更新し、当該更新をコミットするプロセッサと、を備える電子情報記憶媒体において、
   前記プロセッサは、
   前記更新用のレコードのデータ長が前記バッファ領域の容量を超える場合、前記データ格納領域のレコードに含まれる前記データ長を示すデータを、データがないことを示す値に更新し、当該更新をコミットする第１更新手段と、
   前記第１更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち前記バッファ領域の容量分のデータ値を示すデータで、前記データ格納領域のレコードに含まれる前記データ長を示すデータ以外の前記データを更新し、当該更新をコミットする第２更新手段と、
   前記第２更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータで、前記データ格納領域のレコードに含まれる更新されていない残りのデータを更新し、当該更新をコミットする第３更新手段と、
   前記更新用のレコードに含まれる全データが更新に利用された場合、前記更新用のレコードに含まれるデータ長を示すデータで、前記データ格納領域のレコードに含まれるデータ長を示すデータを更新し、当該更新をコミットする第４更新手段と、
   を備えることを特徴とする電子情報記憶媒体。
2. 前記データがないことを示す値は０であることを特徴とする請求項１に記載の電子情報記憶媒体。
3. 前記第３更新手段は、前記更新用のレコードに含まれるデータ値を示すデータが全てが更新に利用されるまで、更新に利用されていないデータ値を示すデータで、前記データ格納領域のレコードに含まれる更新されていないデータ値を示すデータを更新し、当該更新をコミットすることを繰り返すことを特徴とする請求項１または２に記載の電子情報記憶媒体。
4. 少なくともデータ値を示すデータと当該データ値のデータ長を示すデータとを含んで構成されるレコードを格納するデータ格納領域と、バッファ領域とを少なくとも有する不揮発性メモリと、
   更新用のレコードで前記データ格納領域のレコードを更新する際に、当該更新用のレコードの全部又は一部を前記バッファ領域に格納した後に、当該データ格納領域のレコードを更新し、当該更新をコミットするプロセッサと、を備える電子情報記憶媒体において前記プロセッサにより実行される情報処理方法であって、
   前記更新用のレコードのデータ長が前記バッファ領域の容量を超える場合、前記データ格納領域のレコードに含まれる前記データ長を示すデータを、データがないことを示す値に更新し、当該更新をコミットする第１更新ステップと、
   前記第１更新ステップによるコミット後に、前記更新用のレコードに含まれる全データのうち前記バッファ領域の容量分のデータ値を示すデータで、前記データ格納領域のレコードに含まれる前記データ長を示すデータ以外の前記データを更新し、当該更新をコミットする第２更新ステップと、
   前記第２更新ステップによるコミット後に、前記更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータで、前記データ格納領域のレコードに含まれる更新されていない残りのデータを更新し、当該更新をコミットする第３更新ステップと、
   前記更新用のレコードに含まれる全データが更新に利用された場合、前記更新用のレコードに含まれるデータ長を示すデータで、前記データ格納領域のレコードに含まれるデータ長を示すデータを更新し、当該更新をコミットする第４更新ステップと、
   を含むことを特徴とする情報処理方法。
5. 少なくともデータ値を示すデータと当該データ値のデータ長を示すデータとを含んで構成されるレコードを格納するデータ格納領域と、バッファ領域とを少なくとも有する不揮発性メモリと、
   更新用のレコードで前記データ格納領域のレコードを更新する際に、当該更新用のレコードの全部又は一部を前記バッファ領域に格納した後に、当該データ格納領域のレコードを更新し、当該更新をコミットするプロセッサと、を備える電子情報記憶媒体における前記プロセッサを、
   前記更新用のレコードのデータ長が前記バッファ領域の容量を超える場合、前記データ格納領域のレコードに含まれる前記データ長を示すデータを、データがないことを示す値に更新し、当該更新をコミットする第１更新手段と、
   前記第１更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち前記バッファ領域の容量分のデータ値を示すデータで、前記データ格納領域のレコードに含まれる前記データ長を示すデータ以外の前記データを更新し、当該更新をコミットする第２更新手段と、
   前記第２更新手段によるコミット後に、前記更新用のレコードに含まれる全データのうち更新に利用されていない残りのデータで、前記データ格納領域のレコードに含まれる更新されていない残りのデータを更新し、当該更新をコミットする第３更新手段と、
   前記更新用のレコードに含まれる全データが更新に利用された場合、前記更新用のレコードに含まれるデータ長を示すデータで、前記データ格納領域のレコードに含まれるデータ長を示すデータを更新し、当該更新をコミットする第４更新手段として機能させることを特徴とする情報処理プログラム。

Images