JP4301465B2

JP4301465B2 - IC card with backup memory

Info

Publication number: JP4301465B2
Application number: JP29062598A
Authority: JP
Inventors: 森山明子; 山田真生; 斎藤博夫; 入澤和義; 柴田直人
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 1998-10-13
Filing date: 1998-10-13
Publication date: 2009-07-22
Anticipated expiration: 2018-10-13
Also published as: JP2000123134A

Description

【０００１】
【発明の属する技術分野】
本発明は書き込み時にデータのバックアップがとれるようにしたＩＣカードに関する。
【０００２】
【従来の技術】
図６はＩＣカードとリーダ／ライタとの通信を説明する図で、リーダ／ライタ１はＩＣカード２に対してコマンド（命令）を送信し、これを受信したＩＣカードは、コマンドを解釈して書き込み／読み出し等の処理を実行し、処理結果をレスポンスとしてリーダ／ライタ１へ返すようになっている。
【０００３】
図７に示すように、ＩＣカード２は、ＣＰＵ２ａ、ＲＡＭ２ｂ、ＲＯＭ２ｃ、ＥＥＰＲＯＭ２ｄを有しており、ＲＯＭ２ｃに記憶されているプログラムをＣＰＵ２ａに読み込み、リーダ／ライタ１から送信されるコマンドをＩ／Ｏポートを通して受信すると、コマンドとともに送信されたデータを読み込んで必要な処理を行い、結果をＥＥＰＲＯＭ２ｄの所定のファイルエリアに書き込み、Ｉ／Ｏポートを通してレスポンスを出力する。
【０００４】
図８はアプリケーションプログラムで利用されるデータ用領域とオペレーティング・システム（ＯＳ）用領域からなるＥＥＰＲＯＭ３を示したもので、データ領域の先頭アドレスから、データＡ、Ｂ、Ｃのファイルをこの順で割り当てるときに、同時に、ファイルエリアの割当て順に、アプリケーション領域の最後から先頭に向かってＡディレクトリ、Ｂディレクトリ、Ｃディレクトリが形成される。ディレクトリはファイルの制御情報であり、ファイルを識別するためのファイルＩＤ、ファイルが記憶される先頭アドレス、エリア容量、属性情報（リード／ライトのアクセス権（キー）の情報）、チェックコードからなっている。
【０００５】
図８において、アプリケーションの領域に続いたＯＳ用領域には、ディレクトリに示された先頭アドレスとエリア容量から、割り当てられたファイルエリアの最後のアドレスを示すポインタ、積み上げられた最後のディレクトリを示すポインタ等のＯＳが使うデータがセットされる。ポインタＰ、Ｐ′の間の領域がさらに割り当て可能なメモリ領域である。
【０００６】
このような従来のＩＣカードでは、ファイルのディレクトリにバックアップフラグを設定し、そのフラグを持つファイルのみがバックアップ可能とするものであった。また、そのためには、ＩＣカード発行処理時に予めファイルバックアップ専用のファイルを生成しておく必要があった。
【０００７】
図９は従来のＩＣカード発行処理フローの例を示す図である。
まず、正ファイルの生成とバックアップフラグの書き込みを行う（ステップＳ１）。この処理ではバックアップのためのエリアを作ると共に、ディレクトリ部にフラグを立てることを行う。次に、バックアップのための副ファイルを生成し（ステップＳ２）、次いで正ファイルへ初期データを書き込むとともに、副ファイルへ初期データを書き込む（ステップＳ３、ステップＳ４）。これにより発行処理が終了する。
【０００８】
【発明が解決しようとする課題】
このように、従来の方法では予めＩＣカード発行処理時にバックアップ専用のファイルを生成しておく必要があるため、発行処理に時間がかかり、コストアップ要因となっていた。
本発明は上記課題を解決するためのもので、発行処理時の煩雑な処理を省略し、時間の短縮を行って、コスト削減を図ることを目的とする。
【０００９】
【課題を解決するための手段】
本発明は、演算装置、主メモリ、読み出し専用メモリ、不揮発性メモリを有し、前記不揮発性メモリのアプリケーション領域に、バックアップ登録用のテーブルを設けてバックアップ対象のファイル／レコードを指定する情報を登録するとともに、バックアップデータの保存領域を示す情報を登録してデータのバックアップを行うようにしたＩＣカードであって、前記バックアップ対象のファイル／レコードを指定する情報はバイト１、バイト２、バイト３のデータからなり、バイト１のデータの上位ニブルによりバックアップ対象となるファイル／レコードの種別を指定するとともに、下位ニブルにより、上位ニブルで指定された種別のファイル／レコードについて部分バックアップか全体バックアップかを指定し、バイト２とバイト３のデータの内容により、バックアップ対象となるファイルの識別子／レコード番号を指定し、前記バックアップデータの保存領域を示す情報は、少なくともバックアップ領域であることを示す識別子、最上位ファイルからバックアップ対象となるファイルまでの論理的な繋がりを示すファイル識別子、データ開始先頭アドレスをもつディレクトリ部とを有することを特徴とする。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
本発明は、バックアップ指定用のテーブルを持ち、テーブルで指定したレコードを書き込み時にバックアップをとり、本ファイルが壊れた場合には読み取り時にバックアップファイルを利用できるようにしたものである。
図１はバックアップデータ登録用テーブルの例を示す図である。
一般的にファイルは、
・ＤＦ（ＤｅｄｉｃａｔｅｄＦｉｌｅ，アプリケーションを統括するもの）
・ＥＦ（ＥｌｅｍｅｎｔａｒｙＦｉｌｅ，アプリケーションに属するデータが格納されるもの）
から構成され、
レコードはＥＦ内の論理的なデータの集まりの単位である。
【００１１】
これらＤＦ、ＥＦ、レコードに関わるバックアップは、バイト１、バイト２、バイト３によって指定する。
バイト１については、上位ニブルによってバックアップ対象となるＤＦ／ＥＦ／レコードの種別指定を行うとともに、下位ニブルによって部分バックアップ／全体バックアップの指定を行う。

【００１２】
バイト２、３については
バイト１の上位ニブルがＤＦ識別子を示す時、ＤＦ識別子の値
（ＦＦＦＦｈは除く）
バイト１の上位ニブルがＥＦ識別子を示す時、ＥＦ識別子の値
（ＦＦＦＦｈは除く）
バイト１の上位ニブルがレコード番号を示す時、レコード番号の値
（ＦＦＦＦｈは除く）を示す。
あるＤＦ指定がテーブルに現れたら、後続のＥＦ情報、レコード情報はこのＤＦに属するものとし、新たにＤＦ識別子が現れるまで続く。また、あるＥＦ識別子がテーブルに現れたら、後続のレコード情報はこのＥＦに属するものとし、新たなＥＦ識別子が現れるまで続く。テーブルの最後は終端識別子ＦＦＦＦｈで表される。
【００１３】
図１の場合、先頭のＤＦ指定のバイト１が１６進表示で「１２」、即ち、２進表示で「０００１００１０」であり、上位ニブル０００１はＤＦ指定を示し、下位ニブル００１０は部分バックアップ指定である。つまり、ＤＦ下の特定のＥＦに関してバックアップを行うという意味をもつ。バイト２、バイト３はＤＦ識別子の値３００１ｈである。続いてテーブルに現れるバイト１は１６進表示で「２２」、２進表示で「００１０００１０」であり、上位ニブル００１０はＥＦ指定を示し、下位ニブル００１０は部分バックアップを示す。そして、バイト２、バイト３はＥＦ識別子の値２００１ｈである。続いてテーブルに現れるバイト１は１６進表示で「３１」、２進表示で「００１１０００１」であり、上位ニブル００１１はレコード指定、下位ニブル０００１は全体バックアップを意味する。そして、バイト２、バイト３はレコード番号の値１である。したがって、ＤＦ３００１ｈ下のＥＦ２００１、レコード１がバックアップ対象として指定される。
【００１４】
続いてテーブルに現れるバイト１は、１６進表示で「１２」、即ち、２進表示で「０００１００１０」であり、上位ニブル０００１はＤＦ指定、下位ニブル００１０は部分バックアップを示す。そして、バイト２、バイト３はＤＦ識別子の値３００２ｈである。続いてテーブルに現れるバイト１は１６進表示で「２１」、２進表示で「００１００００１」であり、上位ニブル００１０はＥＦ指定を示し、下位ニブル０００１は全体バックアップを示し、バイト２、バイト３で表されるＥＦ識別子の値２００２ｈ中の全レコードがバックアップ対象として指定される。また、次にテーブルに現れるバイト１は１６進表示で「２２」、２進表示で「００１０００１０」であり、上位ニブル００１０はＥＦ指定、下位ニブル００１０は部分バックアップを示す。そして、バイト２、バイト３はＥＦ識別子の値２００３ｈである。続いてテーブル上に現れるバイト１は１６進表示で「３２」、２進表示で「００１１００１０」であり、上位ニブル００１１はレコード指定、下位ニブル０００１は全体バックアップを示す。そして、バイト２、バイト３はレコード番号の値２である。したがって、ＤＦ３００２ｈ下のＥＦ２００２中全レコードと、ＥＦ２００３のレコード２がバックアップ対象として指定される。
【００１５】
続いてテーブルに現れるバイト１は、１６進表示で「１１」、即ち、２進表示で「０００１０００１」であり、上位ニブル０００１はＤＦ指定、下位ニブル０００１は全体バックアップを示し、バイト２、バイト３で表されるＤＦ（３００３ｈ）下の全ＥＦ、全レコードがバックアップ対象指定される。
【００１６】
次に、図２によりバックアップデータの保存領域について説明する。
最初の書き込み時にユーザーエリア内にレコードが生成される。そしてバックアップ用エリアが確保されると、本体のＤＦまたはＥＦにそのフラグがセットされる。
図２（ａ）はディレクトリ部であり、バイト１、バイト２、バイト３の３バイトでバックアップ用領域であることの識別子を示し、バイト４〜７の４バイトで、ＤＦからのパスを示している。ＤＦからのパスはＩＣカード内のファイルを統括している最も最上位のＤＦ（ＭＦ：マスターファイル）からバックアップ対象となっているデータを記録しているＥＦまでの論理的な繋がり（パス）をファイルＩＤを用いて示したものである。
これを図３を用いて説明すると、最上位のＤＦ（ＭＦ）下にＤＦ１（ファイルＩＤ３００１ｈ）、ＤＦ２（ファイルＩＤ３００２ｈ）があり、さらにＤＦ２にはＥＦ１（ファイルＩＤ２００Ｅｈ）、ＥＦ２（ファイルＩＤ２００Ｆｈ）があり、図の太線で示したパス（ＭＦ−ＤＦ２−ＥＦ１）でバックアップ対象ファイルを表している。続く２バイトでデータ開始先頭アドレスが示され、続く２バイトでチェックコード、例えばＣＲＣ等が付加される。
図２（ｂ）はデータ部であり、最初の２バイトでレコード番号、続く１バイトでタグ（レコードの識別子）、続く１バイトでデータの長さ、続く２バイトがデータの内容、続く２バイトにチェックコードが付加される。
【００１７】
ところで、バックアップ対象は基本的にＥＦ内のレコードデータを対象としているが、ＩＳＯのファイル分類ではレコード形式ファイル（ＥＦ）の他にトランスペアレント形式ファイル（ＥＦ）があり、この形式のファイル内データはレコードで区切られておらず、べた書きされる。
【００１８】
バックアップ対象ＥＦのデータがトランスペアレント形式のファイル内データである場合について図４により説明する。
図４は図２に対応するもので、ディレクトリ部（図４（ａ））は図２（ａ）と同様である。データ部（図４（ｂ））については、レコード番号を００００として番号を特定せず，続いてデータを付加し、さらに２バイトのチェックコードを付加する。
【００１９】
図５は本発明によるＩＣカード発行処理フローの例を示す図である。
まず、正ファイルを生成し（ステップＳ１１）、次いで、専用のバックアップデータ登録用テーブルにバックアップ対象のレコードを登録し（ステップＳ１２）、次いで正ファイルへ初期データを書き込み（ステップＳ１３）。この時自動的にバックアップデータも書き込まれる。
【００２０】
なお、上記説明ではレコード単位でバックアップ対象をテーブルに登録するようにしたが、レコード単位、ＥＦ単位、ＤＦ単位と発行者が必要に応じてバックアップの単位を選べるようにしてもよい。
【００２１】
【発明の効果】
以上のように本発明によれば、バックアップ指定用の専用のテーブルを設け、発行処理においては、テーブルにバックアップしたいデータの情報を登録するだけで、発行者はバックアップ用のエリアの確保を意識せずにバックアップ領域が確保され、発行時間の短縮化とコスト削減を図ることが可能となる。
【図面の簡単な説明】
【図１】本発明のバックアップデータ登録用テーブルの構成を説明する図である。
【図２】バックアップデータの保存領域について説明する図である。
【図３】バックアップ対象のデータを記録しているＥＦまでのパスを説明する図である。
【図４】トランスペアレント形式のバックアップデータの保存領域について説明する図である。
【図５】本発明の発行処理の例を説明する図である。
【図６】リーダ／ライタとＩＣカードの通信を説明する図である。
【図７】ＩＣカードの構成を示す図である。
【図８】ＥＥＰＲＯＭの構成を説明する図である。
【図９】従来の発行処理フローを説明する図である。
【符号の説明】
１…リーダ／ライタ、２…ＩＣカード、３…ＥＥＰＲＯＭ。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an IC card capable of backing up data at the time of writing.
[0002]
[Prior art]
FIG. 6 is a diagram for explaining communication between the IC card and the reader / writer. The reader / writer 1 transmits a command (command) to the IC card 2, and the IC card that receives the command interprets the command. Processing such as writing / reading is executed, and the processing result is returned to the reader / writer 1 as a response.
[0003]
As shown in FIG. 7, the IC card 2 has a CPU 2a, a RAM 2b, a ROM 2c, and an EEPROM 2d. The program stored in the ROM 2c is read into the CPU 2a, and a command transmitted from the reader / writer 1 is input to the I / O. When the data is received through the port, the data transmitted together with the command is read and necessary processing is performed, the result is written in a predetermined file area of the EEPROM 2d, and a response is output through the I / O port.
[0004]
FIG. 8 shows the EEPROM 3 composed of a data area and an operating system (OS) area used in the application program. Data A, B, and C files are assigned in this order from the start address of the data area. At the same time, the A directory, the B directory, and the C directory are formed from the end of the application area to the top in the order of file area allocation. The directory is file control information, and includes a file ID for identifying the file, a head address where the file is stored, an area capacity, attribute information (read / write access right (key) information), and a check code. Yes.
[0005]
In FIG. 8, in the OS area following the application area, a pointer indicating the last address of the allocated file area and a pointer indicating the last stacked directory are indicated based on the start address and area capacity indicated in the directory. Data used by the OS is set. The area between the pointers P and P ′ is a memory area that can be further allocated.
[0006]
In such a conventional IC card, a backup flag is set in a file directory, and only files having the flag can be backed up. For this purpose, it is necessary to generate a file backup-dedicated file in advance at the time of IC card issuance processing.
[0007]
FIG. 9 is a diagram showing an example of a conventional IC card issuing process flow.
First, a primary file is generated and a backup flag is written (step S1). In this process, an area for backup is created and a flag is set in the directory section. Next, a secondary file for backup is generated (step S2), then initial data is written to the primary file and initial data is written to the secondary file (steps S3 and S4). This completes the issuing process.
[0008]
[Problems to be solved by the invention]
As described above, in the conventional method, it is necessary to generate a backup-dedicated file in advance at the time of the IC card issuance process. Therefore, the issuance process takes time, resulting in a cost increase.
An object of the present invention is to solve the above-described problems, and it is an object of the present invention to reduce costs by omitting complicated processing at the time of issuing processing and reducing time.
[0009]
[Means for Solving the Problems]
The present invention has an arithmetic unit, a main memory, a read-only memory, and a nonvolatile memory, and registers information for specifying a file / record to be backed up by providing a backup registration table in the application area of the nonvolatile memory. In addition, the IC card is configured to perform backup of data by registering information indicating the storage area of the backup data, and the information specifying the file / record to be backed up is byte 1, byte 2, and byte 3. Specify the type of file / record to be backed up by the upper nibble of byte 1 data, and specify the partial or full backup for the file / record of the type specified by the upper nibble by the lower nibble Byte 2 and Byte 3 The identifier / record number of the file to be backed up is specified according to the contents of the data, and the information indicating the storage area of the backup data includes at least an identifier indicating the backup area, and the file to be backed up from the top-level file And a directory part having a data start head address.
[0010]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below.
The present invention has a table for specifying backups, takes a backup specified when writing a record specified in the table, and allows the backup file to be used when read if this file is corrupted.
FIG. 1 is a diagram showing an example of a backup data registration table.
Generally files are
・ DF (Dedicated File, which supervises applications)
EF (Elementary File, which stores data belonging to an application)
Consisting of
A record is a unit of logical data collection in the EF.
[0011]
The backup related to these DF, EF, and record is designated by byte 1, byte 2, and byte 3.
For byte 1, the type of DF / EF / record to be backed up is designated by the upper nibble, and partial backup / whole backup is designated by the lower nibble.

[0012]
For

bytes

2 and 3, when the upper nibble of byte 1 indicates the DF identifier, the value of the DF identifier (except for FFFFh)
When the upper nibble of byte 1 indicates an EF identifier, the value of the EF identifier (excluding FFFFh)
When the upper nibble of byte 1 indicates the record number, it indicates the value of the record number (excluding FFFFh).
When a certain DF designation appears in the table, the subsequent EF information and record information belong to this DF, and continue until a new DF identifier appears. If a certain EF identifier appears in the table, it is assumed that subsequent record information belongs to this EF and continues until a new EF identifier appears. The end of the table is represented by a termination identifier FFFFh.
[0013]
In the case of FIG. 1, the first byte DF designation byte 1 is “12” in hexadecimal display, that is, “00010010” in binary display, the upper nibble 0001 indicates the DF designation, and the lower nibble 0010 indicates the partial backup designation. is there. That is, it means that backup is performed for a specific EF under the DF. Byte 2 and byte 3 are the DF identifier value 3001h. Subsequently, byte 1 appearing in the table is “22” in hexadecimal display and “00100010” in binary display, the upper nibble 0010 indicates EF designation, and the lower nibble 0010 indicates partial backup. Byte 2 and byte 3 are an EF identifier value 2001h. Subsequently, byte 1 appearing in the table is “31” in hexadecimal display and “00110001” in binary display, the upper nibble 0011 means record designation, and the lower nibble 0001 means whole backup. Byte 2 and byte 3 are the record number value 1. Therefore, EF2001 and record 1 under DF3001h are designated as backup targets.
[0014]
Subsequently, byte 1 appearing in the table is “12” in hexadecimal display, that is, “00010010” in binary display, the upper nibble 0001 indicates DF designation, and the lower nibble 0010 indicates partial backup. Byte 2 and byte 3 are the DF identifier value 3002h. Subsequently, byte 1 appearing in the table is “21” in hexadecimal display and “00100001” in binary display, upper nibble 0010 indicates EF designation, lower nibble 0001 indicates the entire backup, and byte 2 and byte 3 All records in the represented EF identifier value 2002h are designated as backup targets. Byte 1 that appears next in the table is “22” in hexadecimal display and “00100010” in binary display, the upper nibble 0010 indicates EF designation, and the lower nibble 0010 indicates partial backup. Byte 2 and byte 3 are the EF identifier value 2003h. Subsequently, byte 1 appearing on the table is “32” in hexadecimal display and “00110010” in binary display, the upper nibble 0011 indicates the record designation, and the lower nibble 0001 indicates the entire backup. Byte 2 and byte 3 are the record number value 2. Therefore, all records in EF2002 under DF3002h and record2 of EF2003 are designated as backup targets.
[0015]
Subsequently, byte 1 appearing in the table is “11” in hexadecimal display, that is, “00010001” in binary display, the upper nibble 0001 indicates the DF designation, the lower nibble 0001 indicates the entire backup, byte 2 and byte 3 All EFs and all records under the DF (3003h) represented by
[0016]
Next, the backup data storage area will be described with reference to FIG.
A record is created in the user area at the first write. When the backup area is secured, the flag is set in the DF or EF of the main body.
FIG. 2 (a) shows the directory part, which shows the identifier of the backup area with 3 bytes of byte 1, byte 2 and byte 3, and indicates the path from the DF with 4 bytes of bytes 4-7. Yes. The path from the DF is the logical connection (path) from the highest-level DF (MF: master file) that supervises the files in the IC card to the EF that records the data to be backed up. This is shown using a file ID.
This will be described with reference to FIG. 3. DF1 (file ID 3001h) and DF2 (file ID 3002h) are located under the top DF (MF), and DF2 has EF1 (file ID 200Eh) and EF2 (file ID 200Fh). The file to be backed up is represented by a path (MF-DF2-EF1) indicated by a bold line in the figure. The next 2 bytes indicate the data start head address, and the next 2 bytes are added with a check code such as CRC.
FIG. 2B shows the data part, the first 2 bytes are the record number, the subsequent 1 byte is the tag (record identifier), the subsequent 1 byte is the length of the data, the subsequent 2 bytes are the contents of the data, and the subsequent 2 bytes A check code is added to
[0017]
By the way, the backup target is basically the record data in the EF, but the ISO file classification includes the transparent format file (EF) in addition to the record format file (EF). It is not delimited by and written in solid.
[0018]
A case where the data of the backup target EF is data in a transparent format file will be described with reference to FIG.
FIG. 4 corresponds to FIG. 2, and the directory portion (FIG. 4 (a)) is the same as FIG. 2 (a). For the data part (FIG. 4B), the record number is set to 0000, the number is not specified, data is subsequently added, and a 2-byte check code is further added.
[0019]
FIG. 5 is a diagram showing an example of an IC card issue processing flow according to the present invention.
First, a primary file is generated (step S11), a record to be backed up is registered in a dedicated backup data registration table (step S12), and initial data is then written to the primary file (step S13). At this time, backup data is also automatically written.
[0020]
In the above description, the backup target is registered in the table in units of records. However, the unit of backup may be selected by the issuer as required by the record unit, EF unit, and DF unit.
[0021]
【The invention's effect】
As described above, according to the present invention, a dedicated table for backup designation is provided, and in the issuing process, the issuer is conscious of securing a backup area only by registering data information to be backed up in the table. Thus, a backup area is secured, and it is possible to shorten the issuance time and cost.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating the configuration of a backup data registration table according to the present invention.
FIG. 2 is a diagram illustrating a storage area for backup data.
FIG. 3 is a diagram illustrating a path to an EF that records data to be backed up.
FIG. 4 is a diagram for explaining a storage area for transparent format backup data;
FIG. 5 is a diagram illustrating an example of issuance processing according to the present invention.
FIG. 6 is a diagram for explaining communication between a reader / writer and an IC card.
FIG. 7 is a diagram showing a configuration of an IC card.
FIG. 8 is a diagram illustrating a configuration of an EEPROM.
FIG. 9 is a diagram for explaining a conventional issuance process flow;
[Explanation of symbols]
1 ... reader / writer, 2 ... IC card, 3 ... EEPROM.

Claims

演算装置、主メモリ、読み出し専用メモリ、不揮発性メモリを有し、前記不揮発性メモリのアプリケーション領域に、バックアップ登録用のテーブルを設けてバックアップ対象のファイル／レコードを指定する情報を登録するとともに、バックアップデータの保存領域を示す情報を登録してデータのバックアップを行うようにしたＩＣカードであって、
前記バックアップ対象のファイル／レコードを指定する情報はバイト１、バイト２、バイト３のデータからなり、
バイト１のデータの上位ニブルによりバックアップ対象となるファイル／レコードの種別を指定するとともに、下位ニブルにより、上位ニブルで指定された種別のファイル／レコードについて部分バックアップか全体バックアップかを指定し、
バイト２とバイト３のデータの内容により、バックアップ対象となるファイルの識別子／レコード番号を指定し、
前記バックアップデータの保存領域を示す情報は、少なくともバックアップ領域であることを示す識別子、最上位ファイルからバックアップ対象となるファイルまでの論理的な繋がりを示すファイル識別子、データ開始先頭アドレスをもつディレクトリ部とを有することを特徴とするバックアップメモリを持つＩＣカード。」It has an arithmetic unit, main memory, read-only memory, and non-volatile memory. In the application area of the non-volatile memory, a table for backup registration is provided to register information specifying the file / record to be backed up and backup An IC card in which information indicating a data storage area is registered to perform data backup,
The information specifying the file / record to be backed up consists of byte 1, byte 2, and byte 3 data.
The type of file / record to be backed up is specified by the upper nibble of the data of byte 1, and the file / record of the type specified by the upper nibble is specified by the lower nibble as partial backup or full backup.
Specify the identifier / record number of the file to be backed up according to the contents of bytes 2 and 3
The information indicating the backup data storage area includes at least an identifier indicating a backup area, a file identifier indicating a logical connection from the top file to a file to be backed up, a directory portion having a data start head address, and IC card having a backup memory, comprising a. "