JP3564899B2 - Ｉｃカードおよびｉｃカードシステム - Google Patents
Ｉｃカードおよびｉｃカードシステム Download PDFInfo
- Publication number
- JP3564899B2 JP3564899B2 JP28424496A JP28424496A JP3564899B2 JP 3564899 B2 JP3564899 B2 JP 3564899B2 JP 28424496 A JP28424496 A JP 28424496A JP 28424496 A JP28424496 A JP 28424496A JP 3564899 B2 JP3564899 B2 JP 3564899B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- authentication
- card
- command
- compression
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＣカードの正当使用者であるか否か等の認証を画像データ等を用いて行い得るＩＣカードに関する。
【０００２】
【従来の技術】
従来のＩＣカードとしては、５００バイト、１Ｋバイト、２Ｋバイト、４Ｋバイト、８Ｋバイト、１６Ｋバイトまたは３２Ｋバイトの記憶容量のＥＥＰＲＯＭを内蔵するものがある。この記憶容量は、ＳＲＡＭ、ＤＲＡＭ、ＦＲＡＭ（ファーストページＲＡＭ）またはフラッシュメモリ等の他の記憶媒体と比べると小容量である。また、従来のＩＣカードは、通常、外部通信用端子が８個であるので、その通信方式として半二重通信を一般的に採用している。
【０００３】
また、従来のＩＣカードでは、大量のデータを認証用のデータとして用いる場合は、そのデータの供給源となるシステムであってＩＣカードの通信相手となる上位装置においてその認証用のデータを圧縮して、少ない情報量にしてからＩＣカード内に格納していた。
【０００４】
【発明が解決しようとする課題】
ところで、従来のＩＣカードでは、内蔵するＥＥＰＲＯＭの記憶容量が最大でも３２Ｋバイトしかなく、また半二重通信という遅い通信方式でもある。このため、上位装置が顔写真、指紋または網膜等の画像データを認証用のデータとして用いている場合は、その大量の認証用画像データをＩＣカード内に取り込むことができない。これより、その上位装置においてＩＣカードを使用することができないという問題があった。
【０００５】
また、画像データをＩＣカードの認証用のデータとして用いる場合は、その上位装置において認証用画像データを間引きするかまたは画像を入力する際にスキャン間隔を粗くして、データ量を少なくする必要があった。これにより、画像データが粗いものになってしまった。
【０００６】
さらにまた、従来の一般的なデータ圧縮方式であるランレングス法やハフマン法などを用いて画像データを圧縮する方法にも問題点がある。これらの圧縮方法で圧縮した画像データは、ＩＣカードについての正当使用者以外の第三者でもその圧縮した画像データを解凍できてしまう。これにより、認証データを不正に第三者が使用してしまうことも考えられ、セキュリティ的に問題があった。
【０００７】
本発明は、このような背景の下になされたものであり、画像データ等の大容量のデータを本人確認等の認証用のデータとして用いることができ、セキュリィティ性が高いＩＣカードを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上述した課題を解決するために、請求項１に記載の発明は、情報の書き換えが可能なメモリと、前記メモリに格納されているプログラムに基づいて当該ＩＣカードの動作を制御する中央処理装置とを具備するＩＣカードにおいて、認証の対象となるデータを含むコマンドを外部から受信し、前記データをブロックごとに分割するとともに、該コマンドに含まれるコマンド識別情報を参照することにより、該コマンドが圧縮コマンドであるか否かを判断する受信手段と、前記受信手段によって前記コマンドが圧縮コマンドであると判断された場合、前記データをブロックごとに圧縮して認証用データとしてから前記メモリに格納する圧縮手段とを具備することを特徴としている。
【０００９】
また、請求項２記載の発明は、請求項１記載のＩＣカードにおいて、前記圧縮コマンドには、圧縮に関してテーブル処理の指定若しくはレコード順の処理の指定を表す圧縮規定情報が含まれ、前記圧縮手段は、前記圧縮を行う際に前記圧縮規定情報を参照し、前記テーブル処理が指定されている場合には、予めレコード番号がランダムに並んでいるテーブルを参照し、当該テーブルにランダム並んでいるレコード番号を順次読み出し、各レコード番号に対応するデータのブロックを順次圧縮して認証用データとしてから前記メモリに格納する一方、前記レコード順の処理が指定されている場合には、前記データのレコードの順番のままに、対応するデータのブロックを順次圧縮して認証用データとしてから前記メモリに格納することを特徴としている。
【００１０】
また、請求項３記載の発明は、情報の書き換えが可能なメモリと、前記メモリに格納されているプログラムに基づいて当該ＩＣカードの動作を制御する中央処理装置とを具備するＩＣカードにおいて、認証の対象となるデータを含むコマンドを外部から受信し、前記データをブロックごとに分割するとともに、該コマンドに含まれるコマンド識別情報を参照することにより、該コマンドが認証コマンドであるか否かを判断する受信手段と、前記受信手段によって前記コマンドが認証コマンドであると判断された場合、前記データをブロックごとに圧縮して認証用データとしてから前記メモリに格納する圧縮手段と、前記コマンドに含まれる認証情報を参照することで、当該ＩＣカード内で認証処理をすべきであるか否かを判断し、該ＩＣカード内で認証処理をすべきであると判断した場合に、前記メモリに格納してある圧縮済みの認証用データと当該ＩＣカードの外部から受信して前記圧縮手段で圧縮した認証用データとを照合することで認証をする認証手段とを具備することを特徴としている。
【００１１】
また、請求項４記載の発明は、請求項３記載のＩＣカードにおいて、前記認証手段は、前記認証情報を参照した結果、当該ＩＣカード内で認証処理をすべきでないと判断した場合、前記圧縮手段で圧縮した認証用データを前記コマンドの送信元である前記外部へ送信することを特徴としている。
【００１２】
また、請求項５記載の発明は、請求項１〜４のいずれか１の請求項に記載のＩＣカードと、当該ＩＣカードの通信対象となる前記コマンドの送信元である外部装置とを有するＩＣカードシステムであって、前記外部装置は、前記ＩＣカードの前記圧縮手段によって生成された認証用データを当該ＩＣカードから受信して、この受信した認証用データと当該外部装置内ですでに登録されている認証用データとを照合することで、当該ＩＣカードについての認証をすることを特徴としている。
【００１４】
【発明の実施の形態】
以下、図面を参照して、この発明の実施形態について説明する。
【００１５】
Ａ：実施形態の構成
図１は、本発明の実施形態であるＩＣカードの構成を示すブロック図である。ここで、ＥＥＰＲＯＭ４は、データを書き換え可能に格納する不揮発性メモリである。ＲＯＭ２は、ＩＣカード１０の動作を規定するプログラムを格納した不揮発性メモリである。なお、ＩＣカード１０の動作を規定するプログラムは、ＥＥＰＲＯＭ４に格納してもよい。ＲＡＭ３は、データを一時的に格納する揮発性メモリである。ＣＰＵ１は、ＲＯＭ２に格納されているプログラムに基づいてＩＣカード１０の動作を制御する。コプロセッサ５は、ＣＰＵ１の動作を補助する制御装置である。
【００１６】
また、コプロセッサ５は、受信手段５ａと、圧縮手段５ｂと、再生手段５ｃと、テーブル操作手段５ｄと、認証手段５ｅとを具備している。ここで、受信手段５ａは、ＩＣカード１０についての認証の対象となるデータを外部から受信する。そして、その受信は、認証対象となるデータを所定量よりも小さいデータ量のブロックに分割して、１ブロックごとにＲＡＭ３に格納することで行う。このブロックは、例えば、６４バイトで表せるデータを一つのブロックとしてもよい。圧縮手段５ｂは、受信手段５ａが格納した認証の対象となるデータをブロックごとに連続して圧縮する。そして、圧縮手段５ｂは、その圧縮した認証用データをＥＥＰＲＯＭ４に格納する。再生手段５ｃは、ＥＥＰＲＯＭ４に格納した認証用データと所定の鍵とを用いて、当該認証用データを圧縮前のデータに再生する。テーブル操作手段５ｄは、圧縮手段５ｂが圧縮した各ブロックについての各認証用データをテーブルを用いて各々配置し、この各々の配置を所定の条件で変更する。認証手段５ｅは、ＩＣカード１０の外部から受信した認証用データと再生手段５ｃによって再生した認証用データとをブロックごとに照合することで認証をする。
【００１７】
圧縮手段５ｂにおけるデータ圧縮は、例えば、一方向性ハッシュ関数を用いて行うのが好ましい。一方向性ハッシュ関数とは、衝突を起こしにくい圧縮関数ｈをいう。ここで、衝突とは、異なるｘ１、ｘ２に対してｈ（ｘ１）＝ｈ（ｘ２）となることである。また、圧縮関数とは、任意ビット長のビット列をある長さのビット列に変換する関数である。したがって、一方向性ハッシュ関数とは、任意長のビット列をある長さのビット列に変換する関数ｈ（ｘ）で、ｈ（ｘ１）＝ｈ（ｘ２）を満たすｘ１、ｘ２を容易に（多項式計算量で）見いだせないものである。このとき、任意のｙからｙ＝ｈ（ｘ）を満たすｘを容易に見いだせないので、必然的に一方向性関数となる。この一方向性ハッシュ関数としては、例えば、ＭＤ４、ＭＤ５、ＳＨＡまたはＳＨＡー１（アメリカのＮＩＳＴの一方向性ハッシュ関数の標準案）等の既存の関数を用いることができる。
【００１８】
Ｂ：実施形態の動作
次に、上記構成からなるＩＣカード１０の動作を説明する。
図２は、ＩＣカード１０におけるコマンド処理を示すフローチャートである。ＩＣカード１０に対するコマンドとしては、データ圧縮コマンドと認証コマンドがある。まず、受信手段５ａは、上位装置からコマンドを受信すると、そのコマンドのデータ圧縮フラグが「０」か否かをみる（Ｓ１）。なお、データ圧縮フラグは、データ圧縮コマンドを実行中であるか否かを示すフラグであり、リセット時に「０」にクリアされる。
【００１９】
そして、データ圧縮フラグが「０」の場合は、レコード番号を保持するレジスタＲ０に初期値「１」をセットするとともに、レジスタＲ１にテーブルアドレスをセットする（Ｓ２）。これにより、データ圧縮コマンドに対する初期設定がされる。一方、データ圧縮フラグが「０」でない場合は、データ圧縮処理を実行中であるので、ステップ２の処理は行わない。
【００２０】
その後、受信手段５ａは、受信したコマンドが圧縮コマンドか否かを判断する（Ｓ３）。この判断は、図７に示す圧縮コマンドのように、コマンドにおけるＰ１が「００Ｈ」の場合は圧縮コマンドであると判断する。ここで、圧縮コマンドであると判断した場合は、データ圧縮フラグを「１」にセットする（Ｓ４）。そして、圧縮手段５ｂは、データ圧縮を実行する（Ｓ５）。
【００２１】
一方、ステップ３において圧縮コマンドではないと判断した場合は、受信手段５ａは受信したコマンドが認証コマンドか否かを判断する（Ｓ６）。ここで、認証コマンドであると判断した場合は、受信手段５ａはデータ圧縮フラグが「０」か否かを判断する。データ圧縮フラグが「０」である場合は、認証手段５ｅがデータ認証を実行する（Ｓ８）。一方、ステップ６において認証コマンドではないと判断した場合、またはステップ７においてデータ圧縮フラグが「０」ではないと判断した場合は、エラーステータスについての処理を行う（Ｓ９）。
【００２２】
図３は、図２におけるデータ圧縮（Ｓ５）の処理を詳細に示すフローチャートである。まず、圧縮手段５ｂは、レジスタＲ０に保持されているレコード番号が予め定めてあるレコード数よりも小さい値か否かを判断する（Ｓ１１）。ここで、レコード数よりもレコード番号の値の方が小さい場合は、圧縮手段５ｂはそのレジスタＲ０で示すＥＥＰＲＯＭ４上のアドレスに圧縮すべきデータを格納する（Ｓ１２）。なお、このデータの格納は、ＲＡＭ３に対して行ってもよい。そして、圧縮手段５ｂは、圧縮処理をする（Ｓ１３）。さらに、圧縮手段５ｂは、その圧縮したデータを認証データとしてＥＥＰＲＯＭ４に格納する（Ｓ１４）。その後、圧縮手段５ｂは、レジスタＲ０の値に「１」を加え（Ｓ１５）、１ブロックのデータ圧縮処理を終了する。
【００２３】
一方、ステップ１１において、レジスタＲ０に保持されているレコード番号がレコード数以上の値である場合は、圧縮手段５ｂはエラーステータスとなり、ファイルの終わりを表すＥＯＦを上位装置に返す（Ｓ１６）。そして、圧縮手段５ｂは、データ圧縮フラグを「０」にセットし（Ｓ１７）、データ圧縮処理を終了する。
【００２４】
これらにより、図３に示す実施形態では、各レコード毎、すなわち各ブロック毎にデータ圧縮処理をするので、データ圧縮処理についての作業領域を小さくすることができ、ＥＥＰＲＯＭ４およびＲＡＭ３の記憶容量を小さくすることができる。
【００２５】
Ｃ：変形例
図４は、図３における圧縮処理（Ｓ１３）を変形したものであって、それを詳細に示すフローチャートである。まず、圧縮手段５ｂは、圧縮コマンドにおいてテーブル処理が指定されているか、またはレコード順の処理が指定かを判断する（Ｓ２１）。ここで、図７に示す圧縮コマンドのフォーマットにおいて、Ｐ２が「００Ｈ」の場合はテーブル処理が、Ｐ２が「０１Ｈ」の場合はレコード順の処理が指定される。また、テーブル処理とは、圧縮した各ブロックについての各認証用データをテーブルを用いて各々配置し、この配置を所定の条件で変更する、いわゆるテーブル操作をすることをいう。また、レコード順の処理とは、各ブロック毎に圧縮処理したときのその順番のままに、その後の処理を進めていくことをいう。
【００２６】
ステップ２１において、テーブル処理が指定されていると判断した場合は、テーブル操作手段５ｄは、まず、レジスタＲ２の値がレコード数以下か否かを圧縮手段５ｂは判断する（Ｓ２２）。ここで、レジスタＲ２の値がレコード数以下の場合は、レジスタＲ１についてのアドレスの内容（レコード番号）を、レジスタＲ０にセットする。さらに、レジスタＲ１の内容に「１」を加えるとともに、レジスタＲ２の内容にも「１」を加える（Ｓ２３）。
【００２７】
その後、圧縮手段５ｂは、レジスタＲ０に保持されているレコード番号のデータを読み出して（Ｓ２４）、圧縮処理をする（Ｓ２５）。そして、圧縮したデータを認証データとして格納する（Ｓ２６）。さらに、レジスタＲ０の内容に「１」を加える（Ｓ２７）。
【００２８】
一方、ステップ２１において、レコード順の処理だと判断した場合は、まず、レジスタＲ０の値がレコード数以下か否かを圧縮手段５ｂは判断する（Ｓ２８）。ここで、レジスタＲ０の値がレコード数以下の場合は、上記ステップ２４にいく。一方、レジスタＲ０の値がレコード数よりも大きい場合は、圧縮手段５ｂはエラーステータスとなり、ファイルの終わりを表すＥＯＦを上位装置に返す（Ｓ２９）。
【００２９】
これらにより、図４に示す実施形態では、テーブル操作をすることで各認証用データのＥＥＰＲＯＭ４上の配置がランダムになるので、圧縮した認証用データを第三者が解凍することがますます困難となり、セキュリティ性を高めることができる。
【００３０】
図５は、図２におけるデータ認証（Ｓ８）を詳細に示すフローチャートである。まず、受信手段５ａは、上位装置から認証の対象となるデータを所定のブロックごとに受信する。そして、圧縮手段５ｂは、図３および図４に示す手順で受信したデータをブロックごとに圧縮処理をする（Ｓ３１）。そして、これらの受信および圧縮処理をファイルの終わり（ＥＯＦ）になるまで繰り返す（Ｓ３２）。
【００３１】
次に、認証手段５ｅは、カード認証であるか否かを判断する（Ｓ３３）。この判断は、図７に示す認証コマンド（カード認証）のように、コマンドにおけるＰ１が「０１Ｈ」の場合はカード認証コマンドであると判断する。ここで、カード認証コマンドであると判断した場合は、認証手段５ｅは認証処理をする（Ｓ３４）。すなわち、ステップ３１において圧縮処理した認証用データとすでにＥＥＰＲＯＭ４に格納してある認証用データとを比較して、両者が同一であるか否かを判断する。ここで、同一であれば、当該ＩＣカードの使用者が正当権利者であることが認証できたこととなる。その後、認証手段５ｅは、ステータスをセットし（Ｓ３５）、その認証結果を上位装置に返す。
【００３２】
一方、ステップ３３において、カード認証ではないと判断した場合は、ステップ３１において圧縮処理した認証用データをＥＥＰＲＯＭ４にセットする（Ｓ３６）。そして、認証手段５ｅは、ステータスをセットし（Ｓ３５）、圧縮処理した認証用データを上位装置に送信する。
【００３３】
これらにより、図５に示す実施形態では、画像データをもとに認証用データを生成するとともに、ＩＣカードの内部において認証用データの生成およびその認証処理をするので、認証用データを当該ＩＣカードの外部に出力することなく認証でき、セキュリティ性の更なる向上を実現することができる。
【００３４】
図６は、本実施形態における認証用データについてのファイル構造を示す説明図である。ここで、ディレクトリ構造としては、まず、データファイルの先頭アドレスと、予め定めた所定値であるレコード数が格納されている。そして、そのレコード数の次に、認証用テーブルアドレスと認証用テーブルのレコード数が格納され、その次に認証用データが格納されている。なお、本図においては、レコードが１２８個あることを示している。
【００３５】
一方、認証用テーブルには、認証するレコードの番号が記録されている。図に示すように、各レコード番号が認証用テーブル上でランダムにならんでいる。これにより、第三者が本認証用データを解読することがより困難となり、セキュリティ性がより向上している。
【００３６】
図７は、本実施形態におけるＩＣカードのコマンドフォーマットを示す説明図である。ここで、ＩＮＳは、圧縮コマンドか認証コマンドかを識別するデータである。圧縮コマンドではＩＮＳが４３Ｈに、認証コマンドではＩＮＳが５６Ｈになている。Ｐ１は、ＩＣカード内で認証処理をするか否かを識別するデータである。Ｐ１が００Ｈのときは認証用データの作成のみを行い、Ｐ１が０１Ｈのときは認証用データの作成および認証処理を行う。Ｐ２は、テーブル処理をするか否かを示すデータである。そして、Ｐ２が００Ｈのときはテーブル処理、０１Ｈのときはテーブル処理をしないレコード順処理となる。Ｌｅは、期待される認証用データの長さを示すデータである。また、圧縮コマンドには、これから圧縮すべきデータが含まれている。本図では、６４バイトで表せるデータを１つのレコード（１つのブロック）についての圧縮すべきデータとしている。一方、認証用コマンドには、認証用データが含まれている。
【００３７】
なお、上述の実施形態においては、ＩＣカード内で認証処理をしているが、本発明はこれに限定されるものではなく、認証処理を上位装置内で行ってもよい。具体的には、まず、ＩＣカード１０内で圧縮処理して生成した認証用データを上位装置に送信する。そして、当該上位装置内において、すでに登録されている認証用データとＩＣカードから受信した認証用データとを照合することで、認証する。
【００３８】
また、上述の実施形態では、圧縮処理したデータを認証用データとしたが、本発明はこれに限定されるものではなく、例えば、圧縮処理したデータと所定の鍵を用いて当該認証用データを圧縮前のデータに再生する手段を具備してもよい。
【００３９】
これらにより、本実施形態では、圧縮アルゴリズムをＩＣカード内にのみ格納することとすることができるので、第三者が認証用データを偽造または改ざんすることがほとんど不可能となり、セキュリティ性の高いＩＣカードを提供することができる。
【００４０】
【発明の効果】
以上説明したように、本発明によれば、認証の対象となるデータを量的に小さいブロックごとに分割して外部から受信して、そのブロックごとに連続して圧縮するので、データ量を少なくでき、ＩＣカード内のメモリの使用量を少なくすることができて、画像データ等の比較的容量の大きいデータを認証用のデータとして用いることができる。したがって、セキュリィティ性が高いＩＣカードを提供することができる。
【００４１】
また、本発明におけるデータ圧縮処理において、一方向性ハッシュ関数を用いれば、圧縮した認証用データを復元することが非常に困難となるので、さらにセキュリティ性を高めることができる。
【００４２】
また、本発明における認証用データの生成において、圧縮した各ブロックについての各認証用データのアドレスを、テーブルを用いて各々ランダムに再配置することで、さらに第三者がその認証用データを復元することが困難となり、さらにセキュリティ性を高めることができる。
【図面の簡単な説明】
【図１】本発明の実施形態によるＩＣカードの構成を示すブロック図である。
【図２】同実施形態におけるコマンド処理を示すフローチャートである。
【図３】同実施形態におけるデータ圧縮手順を示すフローチャートである。
【図４】図３に示すデータ圧縮手順の主要部を詳細に示すフローチャートである。
【図５】同実施形態におけるデータ認証手順を示すフローチャートである。
【図６】同実施形態における認証要データについてのファイル構造を示す説明図である。
【図７】同実施形態におけるＩＣカードのコマンドフォーマットを示す説明図である。
【符号の説明】
１ ＣＰＵ
２ ＲＯＭ
３ ＲＡＭ
４ ＥＥＰＲＯＭ
５ コプロセッサ
５ａ 受信手段
５ｂ 圧縮手段
５ｃ 再生手段
５ｄ テーブル操作手段
５ｅ 認証手段
１０ ＩＣカード
【発明の属する技術分野】
本発明は、ＩＣカードの正当使用者であるか否か等の認証を画像データ等を用いて行い得るＩＣカードに関する。
【０００２】
【従来の技術】
従来のＩＣカードとしては、５００バイト、１Ｋバイト、２Ｋバイト、４Ｋバイト、８Ｋバイト、１６Ｋバイトまたは３２Ｋバイトの記憶容量のＥＥＰＲＯＭを内蔵するものがある。この記憶容量は、ＳＲＡＭ、ＤＲＡＭ、ＦＲＡＭ（ファーストページＲＡＭ）またはフラッシュメモリ等の他の記憶媒体と比べると小容量である。また、従来のＩＣカードは、通常、外部通信用端子が８個であるので、その通信方式として半二重通信を一般的に採用している。
【０００３】
また、従来のＩＣカードでは、大量のデータを認証用のデータとして用いる場合は、そのデータの供給源となるシステムであってＩＣカードの通信相手となる上位装置においてその認証用のデータを圧縮して、少ない情報量にしてからＩＣカード内に格納していた。
【０００４】
【発明が解決しようとする課題】
ところで、従来のＩＣカードでは、内蔵するＥＥＰＲＯＭの記憶容量が最大でも３２Ｋバイトしかなく、また半二重通信という遅い通信方式でもある。このため、上位装置が顔写真、指紋または網膜等の画像データを認証用のデータとして用いている場合は、その大量の認証用画像データをＩＣカード内に取り込むことができない。これより、その上位装置においてＩＣカードを使用することができないという問題があった。
【０００５】
また、画像データをＩＣカードの認証用のデータとして用いる場合は、その上位装置において認証用画像データを間引きするかまたは画像を入力する際にスキャン間隔を粗くして、データ量を少なくする必要があった。これにより、画像データが粗いものになってしまった。
【０００６】
さらにまた、従来の一般的なデータ圧縮方式であるランレングス法やハフマン法などを用いて画像データを圧縮する方法にも問題点がある。これらの圧縮方法で圧縮した画像データは、ＩＣカードについての正当使用者以外の第三者でもその圧縮した画像データを解凍できてしまう。これにより、認証データを不正に第三者が使用してしまうことも考えられ、セキュリティ的に問題があった。
【０００７】
本発明は、このような背景の下になされたものであり、画像データ等の大容量のデータを本人確認等の認証用のデータとして用いることができ、セキュリィティ性が高いＩＣカードを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上述した課題を解決するために、請求項１に記載の発明は、情報の書き換えが可能なメモリと、前記メモリに格納されているプログラムに基づいて当該ＩＣカードの動作を制御する中央処理装置とを具備するＩＣカードにおいて、認証の対象となるデータを含むコマンドを外部から受信し、前記データをブロックごとに分割するとともに、該コマンドに含まれるコマンド識別情報を参照することにより、該コマンドが圧縮コマンドであるか否かを判断する受信手段と、前記受信手段によって前記コマンドが圧縮コマンドであると判断された場合、前記データをブロックごとに圧縮して認証用データとしてから前記メモリに格納する圧縮手段とを具備することを特徴としている。
【０００９】
また、請求項２記載の発明は、請求項１記載のＩＣカードにおいて、前記圧縮コマンドには、圧縮に関してテーブル処理の指定若しくはレコード順の処理の指定を表す圧縮規定情報が含まれ、前記圧縮手段は、前記圧縮を行う際に前記圧縮規定情報を参照し、前記テーブル処理が指定されている場合には、予めレコード番号がランダムに並んでいるテーブルを参照し、当該テーブルにランダム並んでいるレコード番号を順次読み出し、各レコード番号に対応するデータのブロックを順次圧縮して認証用データとしてから前記メモリに格納する一方、前記レコード順の処理が指定されている場合には、前記データのレコードの順番のままに、対応するデータのブロックを順次圧縮して認証用データとしてから前記メモリに格納することを特徴としている。
【００１０】
また、請求項３記載の発明は、情報の書き換えが可能なメモリと、前記メモリに格納されているプログラムに基づいて当該ＩＣカードの動作を制御する中央処理装置とを具備するＩＣカードにおいて、認証の対象となるデータを含むコマンドを外部から受信し、前記データをブロックごとに分割するとともに、該コマンドに含まれるコマンド識別情報を参照することにより、該コマンドが認証コマンドであるか否かを判断する受信手段と、前記受信手段によって前記コマンドが認証コマンドであると判断された場合、前記データをブロックごとに圧縮して認証用データとしてから前記メモリに格納する圧縮手段と、前記コマンドに含まれる認証情報を参照することで、当該ＩＣカード内で認証処理をすべきであるか否かを判断し、該ＩＣカード内で認証処理をすべきであると判断した場合に、前記メモリに格納してある圧縮済みの認証用データと当該ＩＣカードの外部から受信して前記圧縮手段で圧縮した認証用データとを照合することで認証をする認証手段とを具備することを特徴としている。
【００１１】
また、請求項４記載の発明は、請求項３記載のＩＣカードにおいて、前記認証手段は、前記認証情報を参照した結果、当該ＩＣカード内で認証処理をすべきでないと判断した場合、前記圧縮手段で圧縮した認証用データを前記コマンドの送信元である前記外部へ送信することを特徴としている。
【００１２】
また、請求項５記載の発明は、請求項１〜４のいずれか１の請求項に記載のＩＣカードと、当該ＩＣカードの通信対象となる前記コマンドの送信元である外部装置とを有するＩＣカードシステムであって、前記外部装置は、前記ＩＣカードの前記圧縮手段によって生成された認証用データを当該ＩＣカードから受信して、この受信した認証用データと当該外部装置内ですでに登録されている認証用データとを照合することで、当該ＩＣカードについての認証をすることを特徴としている。
【００１４】
【発明の実施の形態】
以下、図面を参照して、この発明の実施形態について説明する。
【００１５】
Ａ：実施形態の構成
図１は、本発明の実施形態であるＩＣカードの構成を示すブロック図である。ここで、ＥＥＰＲＯＭ４は、データを書き換え可能に格納する不揮発性メモリである。ＲＯＭ２は、ＩＣカード１０の動作を規定するプログラムを格納した不揮発性メモリである。なお、ＩＣカード１０の動作を規定するプログラムは、ＥＥＰＲＯＭ４に格納してもよい。ＲＡＭ３は、データを一時的に格納する揮発性メモリである。ＣＰＵ１は、ＲＯＭ２に格納されているプログラムに基づいてＩＣカード１０の動作を制御する。コプロセッサ５は、ＣＰＵ１の動作を補助する制御装置である。
【００１６】
また、コプロセッサ５は、受信手段５ａと、圧縮手段５ｂと、再生手段５ｃと、テーブル操作手段５ｄと、認証手段５ｅとを具備している。ここで、受信手段５ａは、ＩＣカード１０についての認証の対象となるデータを外部から受信する。そして、その受信は、認証対象となるデータを所定量よりも小さいデータ量のブロックに分割して、１ブロックごとにＲＡＭ３に格納することで行う。このブロックは、例えば、６４バイトで表せるデータを一つのブロックとしてもよい。圧縮手段５ｂは、受信手段５ａが格納した認証の対象となるデータをブロックごとに連続して圧縮する。そして、圧縮手段５ｂは、その圧縮した認証用データをＥＥＰＲＯＭ４に格納する。再生手段５ｃは、ＥＥＰＲＯＭ４に格納した認証用データと所定の鍵とを用いて、当該認証用データを圧縮前のデータに再生する。テーブル操作手段５ｄは、圧縮手段５ｂが圧縮した各ブロックについての各認証用データをテーブルを用いて各々配置し、この各々の配置を所定の条件で変更する。認証手段５ｅは、ＩＣカード１０の外部から受信した認証用データと再生手段５ｃによって再生した認証用データとをブロックごとに照合することで認証をする。
【００１７】
圧縮手段５ｂにおけるデータ圧縮は、例えば、一方向性ハッシュ関数を用いて行うのが好ましい。一方向性ハッシュ関数とは、衝突を起こしにくい圧縮関数ｈをいう。ここで、衝突とは、異なるｘ１、ｘ２に対してｈ（ｘ１）＝ｈ（ｘ２）となることである。また、圧縮関数とは、任意ビット長のビット列をある長さのビット列に変換する関数である。したがって、一方向性ハッシュ関数とは、任意長のビット列をある長さのビット列に変換する関数ｈ（ｘ）で、ｈ（ｘ１）＝ｈ（ｘ２）を満たすｘ１、ｘ２を容易に（多項式計算量で）見いだせないものである。このとき、任意のｙからｙ＝ｈ（ｘ）を満たすｘを容易に見いだせないので、必然的に一方向性関数となる。この一方向性ハッシュ関数としては、例えば、ＭＤ４、ＭＤ５、ＳＨＡまたはＳＨＡー１（アメリカのＮＩＳＴの一方向性ハッシュ関数の標準案）等の既存の関数を用いることができる。
【００１８】
Ｂ：実施形態の動作
次に、上記構成からなるＩＣカード１０の動作を説明する。
図２は、ＩＣカード１０におけるコマンド処理を示すフローチャートである。ＩＣカード１０に対するコマンドとしては、データ圧縮コマンドと認証コマンドがある。まず、受信手段５ａは、上位装置からコマンドを受信すると、そのコマンドのデータ圧縮フラグが「０」か否かをみる（Ｓ１）。なお、データ圧縮フラグは、データ圧縮コマンドを実行中であるか否かを示すフラグであり、リセット時に「０」にクリアされる。
【００１９】
そして、データ圧縮フラグが「０」の場合は、レコード番号を保持するレジスタＲ０に初期値「１」をセットするとともに、レジスタＲ１にテーブルアドレスをセットする（Ｓ２）。これにより、データ圧縮コマンドに対する初期設定がされる。一方、データ圧縮フラグが「０」でない場合は、データ圧縮処理を実行中であるので、ステップ２の処理は行わない。
【００２０】
その後、受信手段５ａは、受信したコマンドが圧縮コマンドか否かを判断する（Ｓ３）。この判断は、図７に示す圧縮コマンドのように、コマンドにおけるＰ１が「００Ｈ」の場合は圧縮コマンドであると判断する。ここで、圧縮コマンドであると判断した場合は、データ圧縮フラグを「１」にセットする（Ｓ４）。そして、圧縮手段５ｂは、データ圧縮を実行する（Ｓ５）。
【００２１】
一方、ステップ３において圧縮コマンドではないと判断した場合は、受信手段５ａは受信したコマンドが認証コマンドか否かを判断する（Ｓ６）。ここで、認証コマンドであると判断した場合は、受信手段５ａはデータ圧縮フラグが「０」か否かを判断する。データ圧縮フラグが「０」である場合は、認証手段５ｅがデータ認証を実行する（Ｓ８）。一方、ステップ６において認証コマンドではないと判断した場合、またはステップ７においてデータ圧縮フラグが「０」ではないと判断した場合は、エラーステータスについての処理を行う（Ｓ９）。
【００２２】
図３は、図２におけるデータ圧縮（Ｓ５）の処理を詳細に示すフローチャートである。まず、圧縮手段５ｂは、レジスタＲ０に保持されているレコード番号が予め定めてあるレコード数よりも小さい値か否かを判断する（Ｓ１１）。ここで、レコード数よりもレコード番号の値の方が小さい場合は、圧縮手段５ｂはそのレジスタＲ０で示すＥＥＰＲＯＭ４上のアドレスに圧縮すべきデータを格納する（Ｓ１２）。なお、このデータの格納は、ＲＡＭ３に対して行ってもよい。そして、圧縮手段５ｂは、圧縮処理をする（Ｓ１３）。さらに、圧縮手段５ｂは、その圧縮したデータを認証データとしてＥＥＰＲＯＭ４に格納する（Ｓ１４）。その後、圧縮手段５ｂは、レジスタＲ０の値に「１」を加え（Ｓ１５）、１ブロックのデータ圧縮処理を終了する。
【００２３】
一方、ステップ１１において、レジスタＲ０に保持されているレコード番号がレコード数以上の値である場合は、圧縮手段５ｂはエラーステータスとなり、ファイルの終わりを表すＥＯＦを上位装置に返す（Ｓ１６）。そして、圧縮手段５ｂは、データ圧縮フラグを「０」にセットし（Ｓ１７）、データ圧縮処理を終了する。
【００２４】
これらにより、図３に示す実施形態では、各レコード毎、すなわち各ブロック毎にデータ圧縮処理をするので、データ圧縮処理についての作業領域を小さくすることができ、ＥＥＰＲＯＭ４およびＲＡＭ３の記憶容量を小さくすることができる。
【００２５】
Ｃ：変形例
図４は、図３における圧縮処理（Ｓ１３）を変形したものであって、それを詳細に示すフローチャートである。まず、圧縮手段５ｂは、圧縮コマンドにおいてテーブル処理が指定されているか、またはレコード順の処理が指定かを判断する（Ｓ２１）。ここで、図７に示す圧縮コマンドのフォーマットにおいて、Ｐ２が「００Ｈ」の場合はテーブル処理が、Ｐ２が「０１Ｈ」の場合はレコード順の処理が指定される。また、テーブル処理とは、圧縮した各ブロックについての各認証用データをテーブルを用いて各々配置し、この配置を所定の条件で変更する、いわゆるテーブル操作をすることをいう。また、レコード順の処理とは、各ブロック毎に圧縮処理したときのその順番のままに、その後の処理を進めていくことをいう。
【００２６】
ステップ２１において、テーブル処理が指定されていると判断した場合は、テーブル操作手段５ｄは、まず、レジスタＲ２の値がレコード数以下か否かを圧縮手段５ｂは判断する（Ｓ２２）。ここで、レジスタＲ２の値がレコード数以下の場合は、レジスタＲ１についてのアドレスの内容（レコード番号）を、レジスタＲ０にセットする。さらに、レジスタＲ１の内容に「１」を加えるとともに、レジスタＲ２の内容にも「１」を加える（Ｓ２３）。
【００２７】
その後、圧縮手段５ｂは、レジスタＲ０に保持されているレコード番号のデータを読み出して（Ｓ２４）、圧縮処理をする（Ｓ２５）。そして、圧縮したデータを認証データとして格納する（Ｓ２６）。さらに、レジスタＲ０の内容に「１」を加える（Ｓ２７）。
【００２８】
一方、ステップ２１において、レコード順の処理だと判断した場合は、まず、レジスタＲ０の値がレコード数以下か否かを圧縮手段５ｂは判断する（Ｓ２８）。ここで、レジスタＲ０の値がレコード数以下の場合は、上記ステップ２４にいく。一方、レジスタＲ０の値がレコード数よりも大きい場合は、圧縮手段５ｂはエラーステータスとなり、ファイルの終わりを表すＥＯＦを上位装置に返す（Ｓ２９）。
【００２９】
これらにより、図４に示す実施形態では、テーブル操作をすることで各認証用データのＥＥＰＲＯＭ４上の配置がランダムになるので、圧縮した認証用データを第三者が解凍することがますます困難となり、セキュリティ性を高めることができる。
【００３０】
図５は、図２におけるデータ認証（Ｓ８）を詳細に示すフローチャートである。まず、受信手段５ａは、上位装置から認証の対象となるデータを所定のブロックごとに受信する。そして、圧縮手段５ｂは、図３および図４に示す手順で受信したデータをブロックごとに圧縮処理をする（Ｓ３１）。そして、これらの受信および圧縮処理をファイルの終わり（ＥＯＦ）になるまで繰り返す（Ｓ３２）。
【００３１】
次に、認証手段５ｅは、カード認証であるか否かを判断する（Ｓ３３）。この判断は、図７に示す認証コマンド（カード認証）のように、コマンドにおけるＰ１が「０１Ｈ」の場合はカード認証コマンドであると判断する。ここで、カード認証コマンドであると判断した場合は、認証手段５ｅは認証処理をする（Ｓ３４）。すなわち、ステップ３１において圧縮処理した認証用データとすでにＥＥＰＲＯＭ４に格納してある認証用データとを比較して、両者が同一であるか否かを判断する。ここで、同一であれば、当該ＩＣカードの使用者が正当権利者であることが認証できたこととなる。その後、認証手段５ｅは、ステータスをセットし（Ｓ３５）、その認証結果を上位装置に返す。
【００３２】
一方、ステップ３３において、カード認証ではないと判断した場合は、ステップ３１において圧縮処理した認証用データをＥＥＰＲＯＭ４にセットする（Ｓ３６）。そして、認証手段５ｅは、ステータスをセットし（Ｓ３５）、圧縮処理した認証用データを上位装置に送信する。
【００３３】
これらにより、図５に示す実施形態では、画像データをもとに認証用データを生成するとともに、ＩＣカードの内部において認証用データの生成およびその認証処理をするので、認証用データを当該ＩＣカードの外部に出力することなく認証でき、セキュリティ性の更なる向上を実現することができる。
【００３４】
図６は、本実施形態における認証用データについてのファイル構造を示す説明図である。ここで、ディレクトリ構造としては、まず、データファイルの先頭アドレスと、予め定めた所定値であるレコード数が格納されている。そして、そのレコード数の次に、認証用テーブルアドレスと認証用テーブルのレコード数が格納され、その次に認証用データが格納されている。なお、本図においては、レコードが１２８個あることを示している。
【００３５】
一方、認証用テーブルには、認証するレコードの番号が記録されている。図に示すように、各レコード番号が認証用テーブル上でランダムにならんでいる。これにより、第三者が本認証用データを解読することがより困難となり、セキュリティ性がより向上している。
【００３６】
図７は、本実施形態におけるＩＣカードのコマンドフォーマットを示す説明図である。ここで、ＩＮＳは、圧縮コマンドか認証コマンドかを識別するデータである。圧縮コマンドではＩＮＳが４３Ｈに、認証コマンドではＩＮＳが５６Ｈになている。Ｐ１は、ＩＣカード内で認証処理をするか否かを識別するデータである。Ｐ１が００Ｈのときは認証用データの作成のみを行い、Ｐ１が０１Ｈのときは認証用データの作成および認証処理を行う。Ｐ２は、テーブル処理をするか否かを示すデータである。そして、Ｐ２が００Ｈのときはテーブル処理、０１Ｈのときはテーブル処理をしないレコード順処理となる。Ｌｅは、期待される認証用データの長さを示すデータである。また、圧縮コマンドには、これから圧縮すべきデータが含まれている。本図では、６４バイトで表せるデータを１つのレコード（１つのブロック）についての圧縮すべきデータとしている。一方、認証用コマンドには、認証用データが含まれている。
【００３７】
なお、上述の実施形態においては、ＩＣカード内で認証処理をしているが、本発明はこれに限定されるものではなく、認証処理を上位装置内で行ってもよい。具体的には、まず、ＩＣカード１０内で圧縮処理して生成した認証用データを上位装置に送信する。そして、当該上位装置内において、すでに登録されている認証用データとＩＣカードから受信した認証用データとを照合することで、認証する。
【００３８】
また、上述の実施形態では、圧縮処理したデータを認証用データとしたが、本発明はこれに限定されるものではなく、例えば、圧縮処理したデータと所定の鍵を用いて当該認証用データを圧縮前のデータに再生する手段を具備してもよい。
【００３９】
これらにより、本実施形態では、圧縮アルゴリズムをＩＣカード内にのみ格納することとすることができるので、第三者が認証用データを偽造または改ざんすることがほとんど不可能となり、セキュリティ性の高いＩＣカードを提供することができる。
【００４０】
【発明の効果】
以上説明したように、本発明によれば、認証の対象となるデータを量的に小さいブロックごとに分割して外部から受信して、そのブロックごとに連続して圧縮するので、データ量を少なくでき、ＩＣカード内のメモリの使用量を少なくすることができて、画像データ等の比較的容量の大きいデータを認証用のデータとして用いることができる。したがって、セキュリィティ性が高いＩＣカードを提供することができる。
【００４１】
また、本発明におけるデータ圧縮処理において、一方向性ハッシュ関数を用いれば、圧縮した認証用データを復元することが非常に困難となるので、さらにセキュリティ性を高めることができる。
【００４２】
また、本発明における認証用データの生成において、圧縮した各ブロックについての各認証用データのアドレスを、テーブルを用いて各々ランダムに再配置することで、さらに第三者がその認証用データを復元することが困難となり、さらにセキュリティ性を高めることができる。
【図面の簡単な説明】
【図１】本発明の実施形態によるＩＣカードの構成を示すブロック図である。
【図２】同実施形態におけるコマンド処理を示すフローチャートである。
【図３】同実施形態におけるデータ圧縮手順を示すフローチャートである。
【図４】図３に示すデータ圧縮手順の主要部を詳細に示すフローチャートである。
【図５】同実施形態におけるデータ認証手順を示すフローチャートである。
【図６】同実施形態における認証要データについてのファイル構造を示す説明図である。
【図７】同実施形態におけるＩＣカードのコマンドフォーマットを示す説明図である。
【符号の説明】
１ ＣＰＵ
２ ＲＯＭ
３ ＲＡＭ
４ ＥＥＰＲＯＭ
５ コプロセッサ
５ａ 受信手段
５ｂ 圧縮手段
５ｃ 再生手段
５ｄ テーブル操作手段
５ｅ 認証手段
１０ ＩＣカード
Claims (5)
- 情報の書き換えが可能なメモリと、前記メモリに格納されているプログラムに基づいて当該ＩＣカードの動作を制御する中央処理装置とを具備するＩＣカードにおいて、
認証の対象となるデータを含むコマンドを外部から受信し、前記データをブロックごとに分割するとともに、該コマンドに含まれるコマンド識別情報を参照することにより、該コマンドが圧縮コマンドであるか否かを判断する受信手段と、 前記受信手段によって前記コマンドが圧縮コマンドであると判断された場合、前記データをブロックごとに圧縮して認証用データとしてから前記メモリに格納する圧縮手段と
を具備することを特徴とするＩＣカード。 - 前記圧縮コマンドには、圧縮に関してテーブル処理の指定若しくはレコード順の処理の指定を表す圧縮規定情報が含まれ、
前記圧縮手段は、前記圧縮を行う際に前記圧縮規定情報を参照し、前記テーブル処理が指定されている場合には、予めレコード番号がランダムに並んでいるテーブルを参照し、当該テーブルにランダム並んでいるレコード番号を順次読み出し、各レコード番号に対応するデータのブロックを順次圧縮して認証用データとしてから前記メモリに格納する一方、前記レコード順の処理が指定されている場合には、前記データのレコードの順番のままに、対応するデータのブロックを順次圧縮して認証用データとしてから前記メモリに格納することを特徴とする請求項１に記載のＩＣカード。 - 情報の書き換えが可能なメモリと、前記メモリに格納されているプログラムに基づいて当該ＩＣカードの動作を制御する中央処理装置とを具備するＩＣカードにおいて、
認証の対象となるデータを含むコマンドを外部から受信し、前記データをブロックごとに分割するとともに、該コマンドに含まれるコマンド識別情報を参照することにより、該コマンドが認証コマンドであるか否かを判断する受信手段と、
前記受信手段によって前記コマンドが認証コマンドであると判断された場合、前記データをブロックごとに圧縮して認証用データとしてから前記メモリに格納する圧縮手段と、
前記コマンドに含まれる認証情報を参照することで、当該ＩＣカード内で認証処理をすべきであるか否かを判断し、該ＩＣカード内で認証処理をすべきであると判断した場合に、前記メモリに格納してある圧縮済みの認証用データと当該ＩＣカードの外部から受信して前記圧縮手段で圧縮した認証用データとを照合することで認証をする認証手段と
を具備することを特徴とするＩＣカード。 - 前記認証手段は、前記認証情報を参照した結果、当該ＩＣカード内で認証処理をすべきでないと判断した場合、前記圧縮手段で圧縮した認証用データを前記コマンドの送信元である前記外部へ送信することを特徴とする請求項３に記載のＩＣカード。
- 請求項１〜４のいずれか１の請求項に記載のＩＣカードと、当該ＩＣカードの通信対象となる前記コマンドの送信元である外部装置とを有するＩＣカードシステムであって、
前記外部装置は、
前記ＩＣカードの前記圧縮手段によって生成された認証用データを当該ＩＣカードから受信して、この受信した認証用データと当該外部装置内ですでに登録されている認証用データとを照合することで、当該ＩＣカードについての認証をすることを特徴とするＩＣカードシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28424496A JP3564899B2 (ja) | 1996-10-25 | 1996-10-25 | Ｉｃカードおよびｉｃカードシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28424496A JP3564899B2 (ja) | 1996-10-25 | 1996-10-25 | Ｉｃカードおよびｉｃカードシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10124635A JPH10124635A (ja) | 1998-05-15 |
| JP3564899B2 true JP3564899B2 (ja) | 2004-09-15 |
Family
ID=17676035
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP28424496A Expired - Fee Related JP3564899B2 (ja) | 1996-10-25 | 1996-10-25 | Ｉｃカードおよびｉｃカードシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3564899B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0506570D0 (en) | 2005-03-31 | 2005-05-04 | Vodafone Plc | Facilitating and authenticating transactions |
| JP4527640B2 (ja) * | 2005-09-15 | 2010-08-18 | 株式会社ソニー・コンピュータエンタテインメント | データ読出装置 |
| US8131912B2 (en) | 2007-09-27 | 2012-03-06 | Kabushiki Kaisha Toshiba | Memory system |
-
1996
- 1996-10-25 JP JP28424496A patent/JP3564899B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10124635A (ja) | 1998-05-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9514063B2 (en) | Secure compact flash | |
| US5845066A (en) | Security system apparatus for a memory card and memory card employed therefor | |
| US20050166057A1 (en) | Digital measurement apparatus and image measurement apparatus | |
| JP4393733B2 (ja) | 携帯可能情報記録媒体 | |
| JPH04143881A (ja) | 相互認証方式 | |
| JP4212717B2 (ja) | ファイル処理ユニットの処理方法 | |
| JP2007004522A (ja) | 記憶装置 | |
| JP4869337B2 (ja) | データの安全な処理 | |
| KR19980079971A (ko) | 기록 매체 상에 데이터 보존 방법 및 이러한 장치 | |
| JPH0440587A (ja) | 携帯可能電子装置 | |
| JPH05217033A (ja) | データの認証方法 | |
| JP4101975B2 (ja) | 可搬型記憶媒体を用いたデータ記録／再生装置 | |
| CN111752894A (zh) | 一种基于数据拆分对存储设备中保密文件的写读方法、***、主机及存储介质 | |
| US20050259965A1 (en) | Video recording/reproduction method | |
| JP3564899B2 (ja) | Ｉｃカードおよびｉｃカードシステム | |
| JP4838381B2 (ja) | マイクロサーキットカード、特に非接触型カードにおける、複数の不揮発性メモリ位置を不可分的に修正する方法 | |
| US20030024976A1 (en) | Electronic apparatus, electronic apparatus operation system, authentication system, authentication method, and information storage medium | |
| JPH025158A (ja) | 拡張ｉｃカード及びそのアクセス法 | |
| KR20020086444A (ko) | 저장 및 연산 기능을 가지는 복합형 유에스비 드라이브 | |
| US20020190130A1 (en) | Portable storage device with function for preventing illegal access thereto | |
| JPH09179949A (ja) | 携帯可能情報記録媒体とそのリーダライタ装置 | |
| CN112513865A (zh) | 记录控制***、控制装置、记录控制方法和记录介质 | |
| JP4457573B2 (ja) | Ｉｃカード及びプログラム書き込み方法 | |
| JPH02187785A (ja) | 認証方式 | |
| JP2003346097A (ja) | カード認証方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040518 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040531 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080618 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090618 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100618 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100618 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110618 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110618 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120618 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120618 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130618 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140618 Year of fee payment: 10 |
|
| LAPS | Cancellation because of no payment of annual fees |