JP2005100464A - 旅行関連マルチ機能スマートカードのための方法および装置 - Google Patents

Abstract

【課題】 重要な旅行関連アプリケーションを安全かつ都合良く集積する、スマートカードシステム用の方法および装置が提供される。
【解決手段】 一実施形態において、スマートカードシステムは、カード所有者特定アプリケーション、および特に旅行に関連して有用な様々なさらなるアプリケーション、例えば、航空会社、ホテル、レンタカー、および支払いに関連するアプリケーションを含む。さらに、特定のアプリケーション内のメモリ空間およびセキュリティに関する特徴が、提携先機関（例えば、航空会社、ホテルチェーン、およびレンタカー代理店）に、特別仕様のセキュリティの高いファイル構造を構築する能力を提供する。
【選択図】 図４

Description

（技術分野）
本発明は、一般に商業取引用の集積回路カードすなわち「スマートカード」の使用に関し、そしてより詳細には、分散された取引システム環境下におけるカード所有者の旅行情報に関連するデータを便利に格納、取り出し、および更新するための方法および装置に関する。

（背景技術および技術的問題）
情報技術の進歩および旅行手配に対する処理合理化にもかかわらず、現代の旅行者にとって、無駄な遅れ、つまらない不都合、面倒な事務手続きを被ることが多い。このような旅行者の負担が最も顕在しているのは、航空、ホテル、およびレンタカー産業であり、このような産業では、サービスおよび宿泊の手配および支払いの際に、連絡ミス、記録のまずさ、および他の多くの管理不手際によって、著しい時間の遅れが生じ得る。

以下に記述するようなスマートカード技術によって、これらの問題のいくつかの対策に限定的ながらも成功を収めてきた。「スマートカード」という用語は、一般に財布サイズ以下のカードであって、カード内にデータを格納および管理するためのマイクロプロセッサまたはマイクロコントローラを組み込んだカードのことをいう。スマートカードは、磁気ストリップカードおよび金額記憶カードよりも複雑であり、高度な記憶管理機能および安全機能を特徴とする。一般的なスマートカードは、カードのプラスチック内に埋め込まれたマイクロコントローラを含み、このマイクロコントローラは、カード外部に提供された外部接触アレイに電気的に接続される。スマートカードコントローラは一般に、ユーザのデータを格納するための電気的に消去可能および書き込み可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、作業格納のためのランダムアクセスメモリ（ＲＡＭ）、およびカードオペレーティングシステムを格納するための読み取り専用メモリ（ＲＯＭ）を含む。これらの機能を制御するには、比較的簡単なマイクロコントローラで十分である。したがって、８ＫのＥＥＰＲＯＭメモリを有する８ビット５ＭＨｚのマイクロコントローラを利用するスマートカードも珍しくない（例えば、Ｍｏｔｏｒｏｌａ６８０５またはＩｎｔｅｌ８０５１マイクロコントローラ）。

多くの規格が集積回路カードの一般的な局面に対応して開発されてきた、例えば、ＩＳＯ７８１６−１、Ｐａｒｔ １：Ｐｈｙｓｉｃａｌ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ（１９８７年）；ＩＳＯ ７８１６−２、Ｐａｒｔ ２：Ｄｉｍｅｎｓｉｏｎｓ ａｎｄ ｌｏｃａｔｉｏｎ ｏｆ ｔｈｅ ｃｏｎｔａｃｔｓ（１９８８年）；ＩＳＯ ７８１６−３、Ｐａｒｔ ３：Ｅｌｅｃｔｒｏｎｉｃ
ｓｉｇｎａｌｓ ａｎｄ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｒｏｔｏｃｏｌｓ（１９８９年、Ａｍｄ．１ １９９２年、Ａｍｄ．２ １９９４年）；ＩＳＯ ７８１６−４、Ｐａｒｔ ４：Ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ ｃｏｍｍａｎｄｓ ｆｏｒ ｉｎｔｅｒｃｈａｎｇｅ（１９９５年）；ＩＳＯ ７８１６−５、Ｐａｒｔ ５ Ｎｕｍｂｅｒｉｎｇ ｓｙｓｔｅｍ ａｎｄ ｒｅｇｉｓｔｒａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ ｆｏｒ ａｐｐｌｉｃａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒｓ（１９９４年、Ａｍｄ．１ １９９５年）；ＩＳＯ／ＩＥＣ ＤＩＳ ７８１６−６、Ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ ｄａｔａ ｅｌｅｍｅｎｔｓ（１９９５年）；ＩＳＯ／ＩＥＣ ＷＤ ７８１６−７、Ｐａｒｔ ７：Ｅｎｈａｎｃｅｄ ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ ｃｏｍｍａｎｄｓ（１９９５年）；およびＩＳＯ／ＩＥＣ ＷＤ ７８１６−８、Ｐａｒｔ ８：Ｉｎｔｅｒ−ｉｎｄｕｓｔｒｙ ｓｅｃｕｒｉｔｙ ａｒｃｈｉｔｅｃｔｕｒｅ（１９９５年）。これらの規格は、本明細書中で参考として援用される。さらに、磁気ストリップカードおよびチップカードに関する一般的な情報は、多くの規格テキスト、例えば、Ｚｏｒｅｄａ＆Ｏｔｏｎ、ＳＭＡＲＴ ＣＡＲＤＳ（１９９４年）、およびＲａｎｋｌ＆Ｅｆｆｉｎｇ、ＳＭＡＲＴ ＣＡＲＤ ＨＡＮＤＢＯＯＫ（１９９７年）において見られ得、その内容は、本明細書中で参考として援用される。

スマートカード技術の使用を介して旅行に関連する不都合を軽減するための種々の試みがなされてきた。例えば、１９９５年に米国航空産業は、「チケットなし旅行」のための規格を策定することによってチケット配布コストを削減する試みに取り組んだ。その後まもなく、ＩＡＴＡとＡＴＡとの合同会議は、Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ ｆｏｒ Ａｉｒｌｉｎｅ Ｉｎｄｕｓｔｒｙ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄｓ（以後、「ＩＡＴＡ規格」）と題される一組の仕様を採用した。同様に、金銭支払いシステムの分野において、ＥＭＶ 第２．０版、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ ｆｏｒ Ｐａｙｍｅｎｔ Ｓｙｓｔｅｍｓ、Ｐａｒｔｓ
１−３（１９９５年）と題される規格が策定されてきた。これらの仕様の両方は、本明細書中で参考として援用される。

これらの規格を広く発布したにもかかわらず、スマートカードの試行は、断片的にとどまる傾向であり、そしてその結果得られる顧客への利点−特に、旅行する顧客−は、極めて最小限のままである。最近の１つの調査の推定では、約９百万枚のスマートカードが１９９６年に輸送および旅行産業において発行されたが、なおも主として、これらのカードは互換性のないままである；すなわち、異なるファイル構造および／または通信プロトコルが使用されることによって、一般にカードデータは、アプリケーションを介してまたは産業参加者間で容易に共有され得ない。

したがって、従来技術におけるこれらおよび他の欠点を克服するためのシステムおよび方法が必要とされる。

（発明の要旨）
本発明は、重要な旅行関連アプリケーションを安全にかつ便利に統合するスマートカードシステムのための方法および装置を提供し、これによって従来技術の限界を克服する。本発明の一局面によると、スマートカードシステムは、特定の旅行環境下（例えば、航空、ホテル、レンタカー、および支払関連アプリケーション）において有用なカード所有者識別アプリケーションおよび種々のさらなるアプリケーションを含む。本発明の別の局面によると、スマートカードシステムはさらに、提携機関に顧客および安全ファイル構造を構築する能力を提供する、特定アプリケーション内のスペースおよび安全機能を含む。

（詳細な説明）
以下に、本発明を添付の図面とともに説明する。なお同様の要素は同様の参照記号で示される。

ここで図１および２を参照する。ここで本発明の実施に適切な例示的スマートカードシステムを説明する。スマートカード１００は一般に、外部デバイス（カードリーダなど）とカード本体１０２内に封入された集積回路１１０との接触または非接触通信を提供するための通信領域１０４を有するカード本体１０２を含む。通信領域１０４は好ましくは、配置および大きさがＩＳＯ７８１６−２に準拠する６つの導電パッド１０６を含む。より詳細には、ＩＳＯ−７８１６−２に準拠する通信領域１０４は好ましくは、ＶＣＣ端子１０６（ａ）（電源）、ＲＳＴ端子１０６（ｂ）（リセット）、ＣＬＫ端子１０６（ｃ）（外部クロック）、ＧＮＤ端子１０６（ｄ）（接地）、ＶＰＰ端子１０６（ｅ）（プログラミング電圧）、およびＩ／Ｏ端子１０６（ｆ）（データライン）を含む。

ＶＣＣ１０６（ａ）は、電力をＩＣ１１０に適切に提供する（通常、５．０Ｖ＋／−１０％）。ＣＬＫ１０６（ｃ）は、データ送信基準として動作する外部クロック供給源を提供するために適切に使用される。ＲＳＴ１０６（ｂ）は、ブートシーケンス中にリセット信号をＩＣ１１０に送信するために適切に使用される。ＶＰＰ端子１０６（ｅ）は、ＩＣ１１０中のＥＥＰＲＯＭ２１２のプログラミングのために使用され得る。しかし、従来技術において公知のように、この端子は、一般に使用されない。なぜなら、現代のＩＣが供給電圧（ＶＣＣ１０６（ａ））から電力をとるＥＥＰＲＯＭのプログラミングに適切な電荷ポンプを通常組み込むからである。Ｉ／Ｏ１０６（ｆ）は、外部デバイスとのシリアルデータ通信のためのラインを適切に提供し、そしてＧＮＤ１０６（ｄ）は、接地基準を提供するために適切に使用される。封入された集積回路１１０は、端子１０６と電気的に通信するために、任意の数の公知のパッケージング技術を介して構成される。そのような公知のパッケージング技術は、例えば熱音波的に結合された金ワイヤ、テープ自動化結合（ＴＡＢ）などを含む。

上記されたスマートカードの一例は、複数の外部端子の環境下にあるが、無端子カードを利用してもまた本発明を実施し得ることが理解され得る。すなわち、容量性結合、誘導性結合などの技術を使用して、非接触通信方法が用いられ得る。従来技術において公知のように、容量性結合は、カードリーダを用いたデータ転送が結合された表面の対称対を介して提供されるようにカード本体に容量性プレートを組み込むことに関する。ここで容量値は、通常１０〜５０ピコファラドであり、動作範囲は、通常１ミリメートルより小さい。誘導性結合は、位相、周波数、または振幅変調を用いる弱結合変圧器構成において配置される結合要素または導電ループを用いる。この場合、カード１００上または内に配置される通信領域１０４の位置は、カード構成に依存して変化し得ることが理解され得る。非接触技術に関するさらなる情報については、例えば、無端子カード規格ＩＳＯ／ＩＥＣ １０５３６およびＩＳＯ／ＩＥＣ １４４４３を参照のこと。これらは、本明細書中で参考として援用される。

スマートカード本体１０２は好ましくは、種々の環境因子（例えば、物理的劣化、異常過熱、およびＥＳＤ（静電荷））に抵抗性のある十分な剛性の材料から製造される。本発明の環境下に適切な材料は、例えば、ＰＶＣ（塩化ポリビニル）、ＡＢＳ（アクリロニトリル−ブタジエン−スチロール）、またはＰＥＴ（ポリエチレンテレフタレート）などを含む。好ましい実施形態において、チップカード１００は、ＩＳＯ ７８１０、７８１３、および７８１６において記載される機械的要求に準拠する。本体１０２は、種々の形状、例えばＩＳＯ−７８１０において記載される長方形状のＩＤ−１、ＩＤ−００、またはＩＤ−０００寸法を含み得る。好ましい実施形態において、本体１０２は、おおよそ一般のクレジットカードの大きさおよび形状であり、そして実質的にＩＤ−１仕様に準拠する。

ここで図２を参照して、ＩＣ１１０は好ましくは、ランダムアクセスメモリ（ＲＡＭ）２１６、読み取り専用メモリ（ＲＯＭ）２１４、中央演算部（ＣＰＵ）２０２、データバス２１０、入力／出力（Ｉ／Ｏ）２０８、および電気的に消去可能および書き込み可能読み取り専用メモリ（ＥＥＰＲＯＭ）２１２のための領域を含む。

ＲＡＭ２１６は、主として、例えば中間演算結果を格納するためのスクラッチメモリ、およびデータ暗号化プロセスのために、カードによって使用される揮発性メモリを含む。ＲＡＭ２１６は、好適には、少なくとも２５６バイトを含む。

ＥＥＰＲＯＭ２１２は、電気的に消去および再書き込み可能であり、特にユーザデータ、システムデータおよびアプリケーションファイルを格納するのに用いられる不揮発性メモリ領域を提供する。本発明のコンテクストでは、ＥＥＰＲＯＭ２１２は、相応しくは、（図３を参照してより詳細に後述する）カード所用者の旅行情報に関する複数のファイルを格納するのに使用される。ＥＥＰＲＯＭ２１２は、好適には、少なくとも８Ｋバイトを含む。

好適な実施形態では、ＣＰＵ２０２は、ＲＯＭ２０２に格納される命令の設定を実施し、メモリ管理を取り扱い（即ち、ＲＡＭ２１６およびＥＥＰＲＯＭ２１２）、入出力動作（即ち、Ｉ／Ｏ２０８）を調整する。

ＲＯＭ２１４は、好適には、スマートカードオペレーティングシステム（ＳＣＯＳ）を含むか、または、ＳＣＯＳにより「マスク」される。即ち、ＳＣＯＳは、好適には、当該分野で周知の標準マスク設計および半導体プロセス方法（例えば、フォトリソグラフィ、拡散、酸化、イオン注入等）を用いて、ＲＯＭ２１４内のハードワイヤード論理として実施される。従って、ＲＯＭ２１４は、一般的には、製造後変更することはできない。そのような実行の目的は、マスクされたＲＯＭにより提供される高速アクセス時間を利用することである。ＲＯＭ２１４は、相応しくは、約４Ｋ〜２０Ｋバイトのメモリを含み、好適には少なくとも１６Ｋバイトを含む。この点に関し、ＲＯＭ２１４の代わりに代替メモリデバイスが使用され得ることを理解されたい。実際、半導体技術が発達するにつれて、より小型の形態のメモリ、例えば、フラッシュＥＥＰＲＯＭを使用するのが有利であり得る。

ＳＣＯＳ制御情報はカードを往復して流れ、より詳細には、ＥＥＰＲＯＭ２１２へのデータの格納およびＥＥＰＲＯＭ２１２の格納されたデータの検索を容易にする。任意のオペレーティングシステム同様、ＳＣＯＳは、明確な命令の設定に従い動作する。この点に関し、様々な公知のスマートカードオペレーティングシステム、例えば、ＩＢＭのＭｕｌｔｉ−Ｆｕｎｃｔｉｏｎ Ｃａｒｄ（ＭＦＣ）Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ ３．５１が、本発明の目的に相応しく、その詳細を本願に参照として援用する。ＩＢＭのＭＦＣオペレーティングシステムは、ＩＳＯ７８１６−４による標準のツリー構造のファイルおよびディレクトリ（後に詳述する）を使用しているが、他のオペレーティングシステムモデルも本発明の実施のために同様に相応しいことは、当業者により理解される。さらに、オペレーティングシステム機能の所定の局面がカード外、即ち取引の間にスマートカードによりダウンロードおよび実行され得る実行可能コードのブロックの形（例えば、ＪＡＶＡ（登録商標）アプレット、ＡｃｔｉｖｅＸオブジェクト等）で、存在できるようにすると有利であり得る。

スマートカード１００の一般的特徴を上記概説したが、当該分野で公知の広範なマイクロコントローラおよびコンタクトベースのスマートカード製品を、本発明の様々な実施形態を実行するのに使用し得ることは明白である。相応しいスマートカードは、例えば、ＳＧＳ−Ｔｈｏｍｓｏｎ Ｍｉｃｒｏｅｌｅｃｔｒｏｎｉｃｓにより製造され、１６ＫのＲＯＭ、８ＫのＥＥＰＲＯＭ、および３４８バイトのＲＡＭを備えるＭｏｔｏｒｏｌａ６８０５マイクロコントローラを組み込んだＳＴ１６ＳＦ４８型カードを含む。しかしながら、本発明の特定の実施形態は、より大きなＥＥＰＲＯＭ容量（即ち、約１２〜１６Ｋの範囲）を備える、より進歩したマイクロコントローラを必要とし得ることを理解されたい。そのようなシステムは、当該分野で周知である。

例示的スマートカード１００およびＩＣ１１０を上述したが、以下に、本発明によるスマートカードファイル構造の概略を説明する。図４を参照して、ファイル構造４００は、好適には、カード所有者の選好、ならびに飛行機旅行、レンタカー、ホテルの予約等を確保して支払を行うために役立つ様々なデータに関する情報を格納するのに使用される。より詳細には、ファイル構造４００は、好適には、カード所有者のＩＤアプリケーション４０６、支払システムアプリケーション４０８、航空会社アプリケーション４１０、ホテルシステムアプリケーション４１２、レンタカーアプリケーション４１４、およびカード所有者証明データ４０４を含む。本文において「アプリケーション」なる用語はすべて、実行可能なソフトウェアコードのブロックであるよりも、むしろ特定の機能（例えば、航空会社、ホテル等）に関するデータの独立領域を意味するが、任意の特定アプリケーションの部分としての実行可能モジュールの使用は、本発明の範囲内であることを当業者は理解されたい。

カード所有者証明データ４０４は、好適には、取引中にカード所有者のアイデンティティを証明するのに役立つ情報を収納する。好適な実施形態では、カード所有者証明データ４０４は、ＣＨＶ１およびＣＨＶ２と呼ばれる８バイトのカード所有者証明番号（即ち、ＰＩＮ番号）を２つ含む。

カード所有者ＩＤアプリケーション４０６は、相応しくは、カード所有者の個人情報（例えば、名前、住所、支払カード、免許証、個人的選好等）に関する様々なファイルを含む。カード所有者ＩＤアプリケーション４０６は、図５を参照してより詳細に後述する。

支払システムアプリケーション４０８は、相応しくは、商業取引を遂行するのに役立つ情報、例えば、従来は磁気ストリップクレジットカードに格納されていた口座番号および有効期限情報を含む。あるいは、支払システムアプリケーション４０８は、広範な財政的取引に相応した完全にＥＭＶコンプライアントなアプリケーションを含む。支払システムアプリケーション４０８は、図６を参照してさらに後述する。

航空会社アプリケーション４１０は、相応しくは、商業的航空会社旅行を簡素化するのに役立つデータ、例えば、関連する個人的選好、電子チケット、および得意旅客情報を含む。航空会社アプリケーション４１０は、図７を参照してさらに後述する。

ホテルアプリケーション４１２は、相応しくは、好適なホテルのリストに関する一連の情報および選好を含む、ホテル予約を確保して支払を行うために役立つ情報、ならびに電子鍵のためのスペースを含む。ホテルアプリケーション４１２は、図９を参照してより詳細に後述する。

レンタカーアプリケーション４１４は、相応しくは、例えば、自動車の選好、および常連レンタル情報を含む、自動車のレンタルおよび返却のプロセスを促進するのに役立つデータを含む。レンタカーアプリケーション４１４は、図８を参照してより詳細に後述する。

上記のアプリケーションのそれぞれにおいて、複数の当事者が所定のファイル構造を利用できるが、他者への非認証のエントリは防止できるように、高度なアクセスおよび暗号化スキームが好適に活用される。より詳細には、提携機関（例えば、ホテルチェーン、航空会社、およびレンタカー営業所）が、カード１００内に、独自の特殊ファイル構造（即ち、「提携者ファイル構造」）を作成する。使用される様々なセキュリティ手段の詳細は、表４０を参照してより詳細に後述する。

図１０を参照して、スマートカード１００が、相応しくは、分配取引システムのコンテクストで使用される。簡潔には、カード所有者は、スマートカード１００を、ネットワーク１９を介して発行者１０、および少なくとも１つの提携機関１２に接続された様々なアクセスポイント１５において使用し得る。発行者１０は、相応しくは、クライアントホスト通信およびデータベースシステム１１に相応しい様々なハードウェアおよびソフトウェア要素を含む。本文では、「発行者」なる用語は、スマートカードを実際に発行し、ファイル構造４００（後に詳述する）の所定領域への何らかの高次アクセスを保持する組織を意味する。

提携機関１２（ａ）、１２（ｂ）等は、スマートカード１００内の適切なデータ領域にアクセスを有する様々なホテルチェーン、レンタカー営業所、航空会社等を含む。各提携機関１２は、相応しくは、ネットワーク１９上での取引を完了するのに必要なデータベース１３、ならびに適切なハードウェアおよびソフトウェア要素を含む。ネットワーク１９は、１つ以上の通信モード、例えば、公衆交換電話回線網（ＰＳＴＮ）、インターネット、デジタルおよびアナログ無線ネットワーク等を含み得る。

各アクセスポイント１５は、相応しくは、スマートカード１００とインターフェイスを取るためのカードリーダ、ならびにカード所有者とインターフェイスを取り、ネットワーク１９上で取引を実行するためのハードウェアおよびソフトウェアを含む。アクセスポイント１５は、好適には、旅行中のカード所有者、または旅行計画を準備中のカード所有者に便利なアクセスを提供する場所に位置する。そのようなアクセスポイント１５は、例えば、航空会社の発券および搭乗場所、レンタカー施設、ホテルロビー、旅行代理店、およびモール内の独立型キオスクに位置し得る。さらに、企業は、従業員の出張を簡略化するために、アクセスポイント１５を主催するのが適切であると考え得る。さらに、個々のカード所有者は、適切なソフトウェアおよび周辺ハードウェアを用いて、自身のパソコンをアクセスポイントとして構成し得る。

本発明の好適な実施形態では、データファイルおよびディレクトリが、図３に示すように「ツリー」構造で格納されている。即ち、スマートカードファイル構造は、周知のＭＳ−ＤＯＳ（Ｍｉｃｒｏｓｏｆｔ Ｄｉｓｋ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）ファイル構造に類似しており、ファィルがディレクトリの階層内に論理的に組織されている。詳細には、ＩＳＯ７８１６−４において、３種類のファイルが定義されている。即ち、専用ファイル（ＤＦ）、基本ファイル（ＥＦ）、およびマスタファイル（ＭＦ）である。マスタファイルは、ＭＳ−ＤＯＳの「ルート」ディレクトリに類似し、他のすべてのファイルおよびディレクトリを含む。専用ファイルは、実際には、他のＤＦまたはＥＦを収納するディレクトリまたは「フォルダ」である。従って、ＭＦ３０２は、任意の数のＤＦ３０６を含み、これらのＤＦ（例えば、ＤＦ３０６（ａ））は、他のＤＦ（例えば、ＤＦ３０８）を含み得るか否かのいずれかである。基本ファイルは、ユーザデータを格納するのに使用され、専用ファイル内（例えば、ＤＦ３０６（ａ）内のＥＦ３１０）、またはマスタファイル内（例えば、ＭＦ３０２内のＥＦ３０４）に存在し得る。より高次のＤＦ（即ち、特定のアプリケーションを収納するＤＦ）は、しばしばアプリケーション専用ファイル（ＡＤＦ）と呼ばれる。

ＭＦならびに各ＤＦおよびＥＦのそれぞれは、独自の２バイトファイル識別子（ＦＩＤ）を割り当てられる。慣例として、ＭＦは、従来は、「３Ｆ００」１６進法のＦＩＤを割り当てられる。次に、オペレーティングシステムによるＥＦまたはＤＦの選択が、ＭＦから開始する全通路を追跡することにより実行され得る。従って、ＦＩＤ「Ａ１００」を有するＤＦをＭＦが含み、続いてこのＤＦがＦＩＤ「Ａ１０１」を有するＥＦを含む場合、このＥＦは、３Ｆ００、Ａ１００、およびＡ１０１のＦＩＤの連続的選択により絶対的に照合され得る。基本的にＦＩＤは、このオペレーティングシステムによりディレクトリおよびファイルを選択するのに使用されるファイル名であり、ＥＥＰＲＯＭ２１２内の物理アドレスを示すことを意図しない旨を理解されたい。当業者により理解されるように、低レベルのＥＥＰＲＯＭアドレシングは、好適には、ＣＰＵ２０２に関連してＳＣＯＳによって取り扱われる。

各ファイルは、好適には、特定のＥＦ、ＤＦ、またはＭＦの様々なしるしを含む関連ファイルヘッダを有する。より詳細には、特定のファイルに関連するファイルヘッダは、好適には、ファイル識別子（ＦＩＤ）、ファイルサイズ、アクセス条件、およびファイル構造を含む。この点に関し、スマートカード１００は、相応しくは、透過、線形固定、線形可変、または循環の４ファイル構造のうちの１つを使用する。完全を期するために、これらのファイル構造の本質を簡単に概観する。

透過ファイル構造は、オフセットおよびバイトカウントを特定することによりアクセスされるバイトのストリングを含む。例えば、以下の表１を参照して、ｎバイトストリングのデータがある場合、バイト７〜バイト１０は、６つのオフセットおよび４バイト長を用いてアクセスされる。

線形固定ファイル構造は、複数の、同じ長さのレコード（例えば、電話番号のリスト）を含み、個々のレコードへのアクセスは、レコード番号を参照することにより行われる。さらに、「現在」のレコード（つまり、最も最近にアクセスされたレコード）に対して「次」または「前」のレコードを参照することができる。対照的に、線形可変ファイル構造は、任意であるが公知の長さのレコードを含み、したがって、通常、線形固定データ構造よりもコンパクトである。

環状ファイル構造は、１種の線形固定ファイルであり、書き込まれた最後のデータセットを指し示すためにポインタを用いる。最後のデータレコードが書き込まれた後、ポインタは第１のレコードに戻る。つまり、環状ファイルは、「リング」状に構成された一連のレコードを含む。

スマートカードアプリケーションにおける安全なメッセージ交換（ｍｅｓｓａｇｉｎｇ）に加えて、レコードを格納する点について特に重要であるデータ構造は、ＢＥＲタグ長値、またはＩＳＯ／ＩＥＣ ８８２５に基づく「ＴＬＶ」構造であり、これを本明細書中で参考として援用する。ＴＬＶオブジェクトにおいて、情報のタイプおよび長さに関する情報が、実際のデータと共に含まれる。したがって、ＴＬＶオブジェクトは、（適切な仕様によって呼び出される）データのタイプを識別するタグ、次のデータの長さをバイトで示すレングスフィールド、および一次データを含むバリューフィールドを含む。例えば、以下の表２に示すＴＬＶオブジェクトは、７バイトの長さを有するテキスト「フェニックス（ｐｈｏｅｎｉｘ）」を暗号化し、「８Ｃ」１６進数の「ｃｉｔｙ」タグ（仮定的なタグ記号）に対応する。

システムは、さまざまなタグ値の意味を事前に知っておく必要がある。つまり、タグフィールドを有用にするために、スマートカードおよびスマートカードと通信する任意の外部システムは、同じタグの仕様に適合する必要がある。この点について、ＩＳＯ／ＩＥＣ ７８１６−６は、ＩＢＭ ＭＦＣ ３．２仕様が行うように、本発明の文脈において有用な一連のタグを規定する。ＩＳＯ／ＩＥＣ
８８２５は、ＴＬＶシステムについての基本的な暗号化規則を記載し、多重ＴＬＶオブジェクトのためのコンテナとして使用され得る「テンプレート」データオブジェクトを規定している。つまり、それ自体がＴＬＶオブジェクトであるより大きなテンプレート内に、プリミティブＴＬＶオブジェクトをコード化することがしばしば有利である。

ここで図４を参照して、本発明による好適なスマートカードデータ構造を詳細に説明する。データ構造４００は、好適には、ＭＦ４０２および５つのＤＦ（カード所有者ＩＤアプリケーション４０６、支払システムアプリケーション４０８、航空会社アプリケーション４１０、ホテルアプリケーション４１２、およびレンタカーアプリケーション４１４）を含む。

以下の詳細な説明において、特定のデータタイプ、フォーマット等について言及するのに、頭字語および略語を用いる。これらの頭字語および略語への鍵を以下の表３に示す。

以下の説明において、好適なデータ構造のさまざまな特徴を、いくつかのケースにおいて、特定のファイル構造タイプ（つまり、透過的、固定等）を用いて説明する。しかし、当業者は、通常のスマートカードファイル構造タイプのいずれかが、通常、ある特定のデータ構造を実行するのに適していることを理解する。例えば、「複数のレコード」を含むものとしてファイル構造を説明する場合、このような構造が、例えば、各レコードがそれ自体透過ファイルである（そして、オフセット値がさまざまなフィールドに対応する）線形固定ファイル内に集められたレコードのリストを用いて設計され得ることが理解される。あるいは、このような構造は、線形固定ファイル内またはより大きなテンプレートＴＬＶ内に集められたＴＬＶストリングを用いて設計され得る。これは特定のタグ値（そのほとんどが任意である）が以下の表に明示されていないという事実にも関わらず起こるケースである。

（カード所有者ＩＤアプリケーション）
図５を参照すると、カード所有者ＩＤアプリケーション４０６が、カード所有者に関するさまざまな情報を格納するために使用される。この情報のいくつかの部分は、関連機構にとって自由に利用可能であり、そのことにより、重複した情報の格納が防止される。

より特定的には、カード所有者ＩＤアプリケーション４０６は、好適には、ディレクトリＥＦ５３２、所有者ＩＤ ＤＦ５０２、および雑ＤＦ（ｍｉｓｃｅｌｌａｎｅｏｕｓ ＤＦ）５３０を含む。所有者ＩＤ ＤＦ５０２は、好適には、ＩＤ ＥＦ５０４、ホームＥＦ５０６、ビジネスＥＦ５０８、選好ＥＦ５１４、パスポートＥＦ５１６、認証ＥＦ５２０、生物測定ＥＦ５２２、およびドライバＥＦ５１８を含む。雑ＥＦ５３０は、好適には、支払カードＥＦ５１０、シーケンスＥＦ５１２、発行ＥＦ５１１、好適なプログラムＥＦ５２８、およびカード番号ＥＦ５２６を含む。これらのファイルおよびこれらファイルのそれぞれの機能を以下に説明する。

ディレクトリＥＦ５３２は、カード所有者ＩＤアプリケーション４０６の下に存在するさまざまなハイレベルＤＦについての、アプリケーション識別子およびラベルのリストを提供する。つまり、このファイルは、各ＤＦについてのロケーション（つまりＦＩＤ）およびアプリケーションラベル（この場合、所有者ＩＤ
ＤＦ５０２および雑ＤＦ５３０）を特定するハイレベルディレクトリリスティングの機能を果たす。特に好適な実施形態において、ディレクトリＥＦ５３２は、以下の表４に示すＥＭＶ３．０に基づいて構築される。好適には、各主要アプリケーション（例えば、ホテル、航空会社等）が、実質的に同じファイル構造を有する、関連するディレクトリファイルを有する。

ＩＤ ＥＦ５０４は、好適には、カード所有者に関する個人情報（例えば、名前、誕生日、緊急連絡先、一般選好等）を含む。特に好適な実施形態において、会員ＥＦ５０４は、以下の表５に示すフィールドを含む。斜体字のフィールド名は、特定のフィールド内のサブカテゴリを示す。

この表および以下の表に、内部データフォーマットおよび外部データフォーマットの両方を列挙する。ＥＥＰＲＯＭ空間の維持が最重要である場合、データ（つまりＥＥＰＲＯＭ２１２内のデータ）の「内部」フォーマットは、データ（つまりアクセスポイント１５においてカードリーダによって読み取られるデータ）の「外部」フォーマットと異なる。したがって、例えば、データフィールドは、カード内の４バイトのＢＣＤレコードからなり得るが、端末によって読み取られて処理されると、このデータは、より簡単に処理するために、８バイトの十進数の値に変換され得る。

ホームＥＦ５０６は、好適には、１つ以上のカード所有者のホームアドレスに関連するデータを含む。特に好適な実施形態において、ホームＥＦ５０６は、以下の表６に記載のフィールドを含む。個人旅行料金アカウントポインタは、好適には、好適な支払カードを指定するために使用され、支払カードＥＦ５１０（以下に詳細に示す）内の支払カードレコードの１つに対応する番号からなる。

ビジネスＥＦ５０８は、好適には、カード所有者のビジネスに関するさまざまなデータ（つまり、アドレス、電話番号等）を含む。特に好適な実施形態において、ビジネスＥＦ５０８は、以下の表７に記載のフィールドを含む。この点について、クレジットカードポインタフィールドが、好適には、支払カードＥＦ５１０（以下に詳細に示す）内の支払カードレコードを指し示すために使用される。原価部門、部署、部門、および従業員ＩＤフィールドは、従業員に固有であり、所定のケースにおいて適用され得るか、または、適用され得ない。

選好ＥＦ５１４は、好適には、カード所有者のデフォルト個人選好に関するデータを含む。特に好適な実施形態において、選好ＥＦ５１４は、以下の表８に記載の選好のアレイを含むフィールドを含む。選好値は、好適には、表３９に記載の選好タグのリストから選択される。

パスポートＥＦ５１６は、好適には、カード所有者パスポート情報を格納するために使用される。特に好適な実施形態において、パスポートＥＦ５１６は以下の表９に記載のフィールドを含む。

ドライバＥＦ５１６は、好適には、カード所有者ドライバライセンスデータを含む。特に好適な実施形態において、ドライバＥＦ５１８は以下の表１０に記載のフィールドを含む。

生物測定ＥＦ５２２は、指紋データ、角膜スキャンデータ、または、他の固有性の十分なしるし（カード所有者の身体的特徴または行動的特徴）等の生物測定データ（好ましくはコード化された）を格納するために使用される。特に好適な実施形態において、生物測定ＥＦ５２２は、以下の表１１に記載の単一のデータストリングを含む。

認証ＥＦ５２０は、好適には、カード所有者ＩＤ４０６アプリケーションの静的認証のための情報を含む。このデータは各カードについて固有であり、偽造値の生成が不可能である十分な複雑性を有する。このことが、「新たな」偽造カード（つまり、新たな認証データを有するカード）の生成を防止するが、現在のカードの多重コピーは防止しない。

特に好適な実施形態において、認証ＥＦ５２０は、以下の表１２に示す公開鍵証明書フィールドを含む。ここで、外部フォーマットは、内部フォーマットと同一である。好適には、発行者ＲＳＡ鍵は６４０ビットの長さであり、ＣＡ鍵は７６８ビットの長さである。

ここで雑ＤＦ５３０の下でのファイルを見ると、好適なプログラムＥＦ５２８は、好適には、航空会社、ホテル、およびレンタカー代理店について、カード所有者選好に関するデータを含む。詳細には、特に好適な実施形態において、このＥＦは、表１３に示す旅行提携機関の各タイプについての好適な会社を示す複数（例えば３つ）のレコードを含む。実際のデータ値は、任意の規則に適合する。つまり、各航空会社、ホテル、およびレンタカー代理店は、割り当てられた任意の３バイトコードである。

支払カードＥＦ５１０は、好適には、カード所有者のさまざまな支払カード（つまり、デビットカード、クレジットカード等）に関する情報をカタログ化するために使用される。特に好適な実施形態において、支払カードＥＦは、表１４に示す２枚のカードについてのカード番号および期限満了日を含む。「ＩＳＯ」および「非ＩＳＯ」の記号は、ＩＳＯ−７８１３について言及しており、特定の支払カード番号フォーマットを特定する。したがって、好適な実施形態において、ＩＳＯまたは非ＩＳＯのカード番号スキームが使用され得る。さらに、このデータセットは、「カード非提示」取引（例えば、取引を遂行するためにカード番号および期限満了日データのみが要求される場合に間接的に行われる取引）についてのみ十分であることが理解される。支払システムアプリケーション４０８（以下に詳細に説明する）に格納されたデータは、「カード提示」取引を遂行するために使用する必要がある。

シーケンスＥＦ５１２は、好適には、ホストとスマートカードデータベースとの同期を提供するために使用される情報を含む。特に好適な実施形態において、シーケンスＥＦ５１２は、以下の表１５に記載のフィールドを含む複数のレコードを含む。この番号は、アプリケーションに格納されたデータについての「バージョン」番号に類似している。

カード番号ＥＦ５２６は、そのスマートカードを識別する固有の番号を記録するために用いられ、また、（以下に詳細に説明するように）鍵派生のためにも用いられ得る。好ましくは、カード番号ＥＦ５２６は、以下の表１６に示す８バイトストリングを含む。

発行ＥＦ５１１は、アプリケーション（即ち、カード所有者ＩＤ ＤＦ４０６）の作成方法に関する様々な詳細事項を記録するために用いられる。このファイルは、そのアプリケーションを作成した機関の身元に関する情報、および、そのアプリケーション自体に関する情報を含む。特に好ましい実施形態において、発行ＥＦ５１１は、以下の表１７に示すフィールドを含む。

表１７に示すパーソナライザーコードフィールドは、ファイルを実際に「パーソナライズ」する機関を示す。即ち、スマートカードがカード所有者に対して発行され得る前に、ＥＥＰＲＯＭ２１２（図２）内にこのデータベース構造を作成し、様々なＥＦ内の適切なフィールド内に初期データ値（即ち、デフォルト選好、カード所有者の名前、ＰＩＮ番号、等）を入れなければならない。本発明の性質が分かれば、あらゆる所与のアプリケーションについて、スマートカード「発行者」と「パーソナライザー」とは同じでなくてもよいことが理解される。従って、スマートカード１００自体に、パーソナライズ処理の様々な詳細事項を記録することは有利である。他の主なアプリケーションについても、同様の発行ファイル構造が提供され得る。

（支払システムアプリケーション）
次に図６を参照して、支払システムアプリケーション４０８は、好ましくは、ディレクトリＥＦ６１０、発行者ＤＦ６０２、および、提携先金融機関が使用する複数のオプションＤＦ６０３（ａ）〜（ｎ）を含む。

ディレクトリＥＦ６１０は、好ましくは、カード所有者ＩＤアプリケーション４０６のコンテクストにおいて上述したアプリケーション識別子およびラベルのリストを含む。

発行者ＤＦ６０２は、支払１ＤＦ６０４を含む。支払１ＤＦ６０４は、従来、磁気ストリップカード（即ち、デビットカード、クレジットカード、等）上のトラック内に格納されるデータを含む。好適な実施形態の一例において、支払１ＤＦ６０４は、以下の表１８に示す周知の磁気ストリップフィールドを有する複数のレコードを含む。

（航空会社アプリケーション）
次に図７を参照して、航空会社アプリケーション４１０は、好ましくは、ディレクトリＥＦ７３０、共通ＤＦ７０２および発行者ＤＦ７０４、ならびに、さらなる航空会社アプリケーション７０３（ａ）、７０３（ｂ）等を含む。

ディレクトリＥＦ７３０は、好ましくはカード所有者ＩＤアプリケーション４０６のコンテクストにおいて上述したアプリケーションの識別子およびラベルのリストを含む。

共通ＤＥ７０２は、概して、全ての参加航空会社にアクセス可能なデータを含み、一方、発行者ＤＦ７０４は、概して、そのスマートカード発行者しか読み出しまたは書き込みできないデータを含む。航空会社アプリケーション４１０は、好ましくは、航空会社提携先機関が使用する少なくとも１つ（好ましくは、３つ）のさらなるＤＦ７０３をさらに含む。即ち、ある航空会社提携先は、ＤＦ７０３（ａ）（ならびに共通ＥＦ７０２）内に格納されたデータの構造にアクセスし、これを特定することができ、別の航空会社は、ＤＦ７０３（ｂ）に対してこれと同様のアクセスを有し得る。これらの提携先ＤＦは、好ましくは、ＩＡＴＡ仕様の関連部分に準拠する。

共通ＤＦ７０２は、好適には、様々な提携先航空会社のいずれもが使用できる共通データ、即ち、乗客ＥＦ７０６、得意旅客ＥＦ７０８、ＩＥＴ ＥＦ７１０、搭乗ＥＦ７１２、および生物測定ＥＦ７１４を含む。

これに対して、発行者ＤＦ７０４は、全員が読み出すことができるが、カード発行者しか更新できない情報、即ち、選好ＥＦ７１６、ＰＩＮ ＥＦ７１８および発行ＥＦ７２０を含む。

次に、共通ＥＦ７０２内に格納される情報を参照して、乗客ＥＦ７０６は、好ましくは、以下の表１９に示す乗客に関する様々なレコードを含む。

特に好ましい実施形態において、得意旅客ＥＦ７０８は、以下の表２０に示す構造を有する複数の得意旅客番号（例えば、１０個の番号）を含む。

ＩＥＴ ＥＦ７１０は、好ましくは、以下の表２１に示す複数の電子チケットレコードを含む。これらの電子チケットのフォーマットは、好ましくは、ＩＡＴＡ規格に準拠する。

特に好ましい実施形態において、搭乗ＥＦ７１２は、表２２に示す、チェックインの際に使用される搭乗データを含む。このデータのフォーマットは、好ましくは、ＩＡＴＡ仕様に準拠する。

生物測定ＥＦ７１４は、好適には、カード所有者に関連付けられた生物測定データ、例えば、網膜スキャンデータ、指紋データ、または、他のあらゆる、カード所有者の身体的または行動上の特徴を表す十分に固有なしるしを格納するために使用される。特に好ましい実施形態において、生物測定ＥＦ７１４は、以下の表２３に示すデータを含む。

発行ＥＦ７２０は、好適には、様々なアプリケーションの発行に関連するデータを保持するために使用される。特に好ましい実施形態において、発行ＥＦ７２０は、以下の表２４に示すデータ構造を含む。

ＰＩＮ ＥＦ７１８は、好適には、参加航空会社提携先のそれぞれに対応するＰＩＮ値を格納するために用いられる。特に好ましい実施形態において、ＰＩＮ
ＥＦ７１８は、以下の表２５に示す構造を有する複数のレコードを含む。各レコードは、得意旅客ＥＦ７０８内の対応するエントリ（即ち、ＥＦ７１８のレコード１はＥＦ７０８のレコード１に対応する、等）に関連する。

選好ＥＦ７１６は、特に好ましい実施形態において、以下の表２６に示す選好アレイを含む。このファイルに格納される選好値は、表３８に関連して以下に説明するものと対応している。

（レンタカーアプリケーション）
次に図８を参照して、レンタカーアプリケーション４１４は、好ましくは、共通ＤＦ８０２、ディレクトリＥＦ８２０、および、個々のレンタカー代理店に対応する１つ以上のレンタ＿カーＤＦ８０３（即ち、８０３（ａ）、８０３（ｂ）、等）を含む。

共通ＤＦは、以下に詳細に説明する選好ＥＦ８０５を含む。レンタ＿カーＤＦ８０３は、それぞれ、レンタ＿カー＿ｉｄ ＥＦ８０７、予約ＥＦ８０９、および費用ＥＦ８１１を含む。

ディレクトリＥＦ８２０は、レンタ＿カーアプリケーション４１４における様々なＤＦのアプリケーション識別子およびラベルのリストを含む。このＥＦの構造は、好ましくは、カード所有者ＩＤアプリケーション４０６のコンテクストにおいて上述したものに準拠する。

特に好ましい実施形態において、選好ＥＦ８０５は、以下の表２７に示す１組の選好アレイのファイル構造を含む。これらのアレイのそれぞれにおいて使用される選好コードの好適なリストは、表３８に関連して後述する。

レンタ＿カー＿ｉｄ８０７は、得意レンタル情報、アップグレード情報、保険情報、等を格納するために使用される。特に好ましい実施形態において、レンタ＿カー＿ｉｄ８０７は、以下の表２８に示すファイル構造を含む。

予約ＥＦ８０９は、１つ以上のレンタカー予約に対応する確認番号を格納するために用いられる。特に好ましい実施形態において、予約ＥＦ８０９は、以下の表２９に示すファイル構造を有する複数のレコード（例えば、２つ）を含む。

費用ＥＦ８１１は、車をレンタルする際に、カード所有者が発生させた費用（例えば、合計レンタル料金）を記録するために使用される。特に好ましい実施形態において、費用ＥＦ８１１は、以下の表３０に示すようなファイル構造を有する複数のレコード（例えば、５つ）を含む。

（ホテルアプリケーション）
次に図９を参照して、ホテルシステムアプリケーション４１２は、好ましくは、ディレクトリＥＦ９２０、共通ＤＦ９１４、１つ以上のホテルチェーンＤＦ９０２、および１つ以上の所有権ＤＦ９０３を含む。

共通ＤＦ９１４は、予約ＥＦ９１８、費用ＥＦ９１６、部屋の鍵ＥＦ９１０および選好ＥＦ９１２を含む。

ホテルチェーンＥＦ９０２（ａ）、９０２（ｂ）、等は、個々のホテルチェーンに関連付けられた選好ＥＦ９０４および滞在者ＩＤ ＥＦ９０６を含む。これに対して、所有権ＥＦ９０３（ａ）、９０３（ｂ）、等は、個々のホテルの所有権に関連付けられた（即ち、その特定のホテルが全国規模のチェーンの加盟店であるかどうかとに関係なく）同様のファイル構造を含む。

特に好ましい実施形態において、予約ＥＦ９１８は、以下の表３１に示す構造を有する複数のレコードを含む。概して、このＥＦは、カード所有者が（所有権コードフィールドにおいて指定された）所与のホテルで予約をしたときに、スマートカード１００に送信される確認番号を格納するために用いられる。日付フィールドは、確認番号が出された日の日付を格納する。

選好ＥＦ９１２は、好ましくは、３組のアレイ選好を含む。これらのアレイにおいて用いられる特定のコードは、表３８に関連して後述する。

費用ＥＦ９１６は、好ましくは、最近のホテル費用、例えば、部屋代、夕食の費用、等のリストを含む。特に好ましい実施形態において、費用ＥＦ９１６は、循環ファイル構造を用いて構成され、かつ以下の表３３に示すフィールドを含む複数のレコード（例えば、１５個）を含む。従って、カード所有者は、最近発生した費用のリストを、種類（慣習的に決められたコード）、日付、量、所有権コード別に調査および印刷することができる。

部屋の鍵ＥＦ９１０は、好ましくは、特定のホテルの部屋へのアクセスを与えるためにカードリーダとともに用いられる電子鍵の値を含む。特に好ましい実施形態において、部屋の鍵ＥＦ９１０は、以下の表３４に示す複数の英数字鍵値を含む。

滞在者ＩＤ ＥＦ９０６は、好ましくは、特定のホテルチェーンに関する得意滞在者データを含む。特に好ましい実施形態において、滞在者ＩＤ ＥＦ９０６は、以下の表３５に示す得意滞在者情報を含む。

選好ＥＦ９０４は、好ましくは、表３６に示す３組のアレイ選好を含む。これらのアレイにおいて用いられる特定のコードは、表３８に関連して後述する。

所有権ＤＦ９０３（ａ）、９０３（ｂ）、等は、提携先ホテルが大型チェーンの一部ではない場合、または、そのホテルが、その系列から独立して独自のデータ組を採用することを選択した場合に用いられる。ある実施形態において、これらの所有権ＤＦは、得意滞在者ＩＤ情報の多くは除去されることを除いて、ホテルチェーンＤＦ９０２と構造的に同一である。より具体的には、典型的な所有権ＤＦ９０３は、表３３に関連して上述したＣＤＰ、イベントカウンタ、およびホテル得意滞在者ＰＩＮフィールドのみを含む滞在者ＩＤ ＥＦ９３４とともに、上記の選好９０４と同一の選好ＥＦ９３８を含む。あるいは、特定のホテルチェーンまたは所有権が、上記のものとは異なるファイル構造を実現することを選択してもよい。

（選好コード）
簡単に前述したように、選好がスマートカード１００中に分配されたいくつかのファイル（すなわち選好ＥＦ５１４、航空会社選好ＥＦ７１６、ホテル選好ＥＦ９１２および９０４、ならびに自動車選好ＥＦ８１０）内に位置しているような、好適な実施形態が構成される。これにより、一見コンフリクトする選好が、場面によってはカード内に共存することを可能にする。例えば、カード所有者ＩＤアプリケーションにおいては禁煙を所望する一方で、ホテルアプリケーション中においては喫煙オプションを選択することが可能である。コンフリクトする場合には、選好は上位レベルから下位レベルに向かって読み出され、各レベルはその前のレベルに取って代わる。

コード化ルールの例示的セットの１例を下記の表３７に述べる：

より詳細には、好適な実施形態において、選好フラグは下記の表３８に述べるようにコード化される。

（セキュリティ）
スマートカード取引の場合において、データセキュリティは５つの主要な次元を有する。すなわち、１）データ秘匿性、２）データ完全性、３）アクセス制御、４）認証、および５）不否認である。様々なセキュリティ機構を通じて、これらの次元の各々に対処する。情報を秘密に保つこと（すなわち鍵を入手し得ない者にとって非可読性であること）に関するデータ秘匿性は、暗号化技術を用いることによって実質的に確保される。データ完全性（およびデータソース確認）は、データが転送中に変更されないことを確実にすることを中心とし、典型的にはメッセージ認証技術を用いる。アクセス制御は、ある者が特定のファイルを読み出しまたは更新するために必要な、カード所有者確認およびその他の要求事項を含む。認証は、カードおよび／または外部装置が所期のものであることを確実にすることを含み、不否認は、これに関連したタスクとして、データまたはメッセージのソースが正式なものであることを確実にすること、すなわち消費者がある取引を許可を得ていない者によって「署名」されたものだからとして取引を否認することができないことを確実にすることに関する。

認証は好ましくは、「チャレンジ／応答」アルゴリズムを用いて行われる。一般に、チャレンジ／応答システムを介した認証は以下を含む。すなわち、１）第１の者による乱数の発生；２）第２の者へのこの乱数の送信（「チャレンジ」）、３）両者に知られた鍵に従った、第２の者による乱数の暗号化、４）暗号化された乱数の第１の者への送信（「応答」）、５）第１の者による乱数の暗号化、および６）第１の者による、得られた２つの数の比較である。２つの数が一致する場合は認証は成功であり、そうでない場合は認証は失敗である。認証は両方向に機能し得ることに留意されたい。すなわち、外界がスマートカードの認証を要求し（内部認証）、スマートカードは外界の認証を要求し得る（外部認証）。好適なチャレンジ／応答アルゴリズムのより詳細な説明は、ＩＢＭ ＭＦＣ仕様書中に見出すことが出来る。

好適な実施形態において、ＤＥＳアルゴリズム（データ暗号化標準）が、さまざまなセキュリティ機能について用いられるが、任意の数のその他の対称的技術または非対称的技術を本発明のコンテクストにおいて用い得ることが、理解される。より詳細には、暗号化アルゴリズムには、対称および非対称の２つの一般的なカテゴリーが存在する。対称的アルゴリズムは、暗号化および復号化に対して同じ鍵、例えば５６ビット鍵を用いて６４ビットのデータブロックを暗号化するＤＥＡ（データ暗号化アルゴリズム）を用いる。逆に非対称アルゴリズムは、２つの異なる鍵、すなわち１つの秘密鍵および１つの公開鍵を用いる。ＲＳＡアルゴリズムは例えば、そのような２つの鍵を用い、非常に大きな素数に因数分解する複雑な計算を用いる。これらおよびその他の暗号化原則に関するさらなる情報は、標準的な文献、例えばＳｅｂｅｒｒｙ＆Ｐｉｅｐｒｚｙｋ、ＣＲＹＰＴＯＧＲＡＰＨＹ：ＡＮ ＩＮＴＲＯＤＵＣＴＩＯＮ ＴＯ ＣＯＭＰＵＴＥＲ ＳＥＣＵＲＩＴＹ （１９８９）；Ｒｈｅｅ、ＣＲＹＰＴＯＧＲＡＰＨＹ ＡＮＤ ＳＥＣＵＲＥ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ（１９９４）；Ｓｔｉｎｓｏｎ、ＣＲＹＰＴＯＧＲＡＰＨＹ：ＴＨＥＯＲＹ ＡＮＤ ＰＲＡＣＴＩＣＥ（１９９５）；ＣＯＮＴＥＭＰＯＲＡＲＹ ＣＲＹＰＴＯＧＲＡＰＨＹ：ＴＨＥ ＳＣＩＥＮＣＥ ＯＦ ＩＮＦＯＲＭＡＴＩＯＮ ＩＮＴＥＧＲＩＴＹ（１９９２）；
およびＳｃｈｎｅｉｅｒ、ＡＰＰＬＩＥＤ ＣＲＹＰＴＯＧＲＡＰＨＹ（２ｄ
ｅｄ．１９９６）において見出すことができる。これらの文献の内容を本明細書において参考のために援用する。

アクセス制御は、各ＥＦおよびＤＦのヘッダ内にアクセス条件を含めることによって適切に提供される。このことにより、要求されたアクセス条件が満たされない限りは、特定の動作（例えば読み出しまたは更新）がファイルに対して実行されることが防がれる。スマートカードの場合においては多くの異なるアクセス条件が適切である。例えばスマートカードは、ファイル動作が許可される前にカード所有者の確認（すなわちカード所有者がＰＩＮを入力することの要求）を要求し得る。同様に、上述の内部および／外部認証を要求してもよい。

別の重要なアクセス条件（本明細書においてＳＩＧＮ条件と呼ぶ）は、特定のファイルが「保護されて」おり、レコードの更新にはメッセージ認証コード（ＭＡＣ）を用いてデータに「署名」することが要求される場合に相当する。ＭＡＣは、メッセージの内容を認証するために用いられる電子的印章の一形態と考えられ得る。モデル的な署名手順において、メッセージ認証アルゴリズム（ＭＡＡ）をカードおよび外部装置の両方が知っている鍵とともに用いて、短縮され、暗号化されたメッセージの表現物（ＭＡＣ）が作成される。そしてＭＡＣがメッセージに付加され、カード（または場合によっては外部装置）に送られ、カード自体が受け取ったメッセージおよび既知の鍵に基づいてＭＡＣを生成する。そしてカードは受け取られたＭＡＣを自身の有する内部生成されたＭＡＣに対して比較する。メッセージまたはＭＡＣが送信中に変更されていた場合、あるいは送信者側が正しい鍵を用いなかった場合、２つのＭＡＣは一致しないため、アクセス条件は満たされない。２つのＭＡＣが一致するとき、アクセス条件が満たされため、その特定のファイル動作は進行し得る。

ＭＡＣは、例えば８バイト鍵を用いるＡＮＳＩＸ９．９法または１６バイト鍵を用いるＡＮＳＩＸ９．１９法などの、様々なＭＡＡを用いて生成され得る。さらに、実際の鍵は、乱数またはその他の適切な値を用いた暗号化によって「多様化」されてもよい。ＭＡＣ生成に関するこれらおよびその他の詳細は、前述の参考文献ならびにＩＢＭ ＭＦＣ仕様書において見出すことが出来る。

他の２つの重要なアクセス条件は、ＮＥＶＥＲ条件およびＦＲＥＥ条件である。ＮＥＶＥＲ条件は、特定のファイル動作（典型的には更新）が決して許可されない場合に相当する。一方、ＦＲＥＥ条件は、ファイルレコードの更新または読み出しが、アクセスのための追加的な前提条件なしに常に許可される場合に相当する。

簡単に前述したＭＡＣ技術とは対照的に、不否認は、必然的に非対称的技術を用いて実行される。すなわち、ＭＡＣ「捺印」などの対称的技術は、１者以上に知られた鍵を用いるため、これらの技術はメッセージのソースが正しいか否かを第３者が確定するためには用いられ得ない。従って典型的には不否認は、送り手が秘密鍵を用いてメッセージに「署名」し、受け手側が対応する公開鍵を用いて署名を認証する、公開鍵暗号化スキーム（例えばＺｉｍｍｅｒｍａｎのＰＧＰシステムなど）を用いる。本発明において、この機能は、あるＥＦを公開鍵および秘密鍵リング（これらは当該分野において周知である）に割り当て、署名されたメッセージをアセンブルするためのカードに内在化された適切な暗号化ソフトウェアとともに用いることによって、適切に実行される。

典型的なスマートカードセキュリティ手順を以上のように簡単な俯瞰したが、アクセス条件セット例を以下の表４０に述べる。この点に関して、各ＥＦについての様々なアクセス条件を、そのファイルが読み出し中であるか更新中であるかについて表記している。各場合において、アクセス条件（ＦＲＥＥ、ＳＩＧＮなど）鍵の「所有者」（発行者、提携先、ユーザなど）、および鍵名称を挙げている。この点に関して、鍵名称は任意のものであり、完全を期するために挙げているためのものであることが理解される。

（取引）
例示的なスマートカード１００および好適なデータ構造４００の詳細な説明を行い、次にスマートカード１００が関与する取引についての様々な詳細を説明する。一般に、典型的なスマートカードセッションは、（１）接触の起動（あるいはそれに匹敵する非接触手段）；（２）カードリセット；（３）カードによるリセットへの応答（ＡＴＲ）；（４）カードとホストとの間の情報交換；および、セッションの終了時における、（５）接触の解除を含む。

まず、カード１００をアクセスポイント１５において設けられているカードリーダに挿入し、カード１００上の通信１０４領域とカードリーダとの間に適切な接続を確立する。好適な実施形態において、物理的な接触（図１における接触１０６）を用い、ＤＡＴＡ接続、ＣＬＯＣＫ接続、ＲＥＳＥＴ接続、ＶＤＤ接続、およびＧＮＤ接続を確立する。これらの接触は、特定のシーケンスを用いて電気的に起動される。好ましくは、ＩＳＯ７８１６−３（ＲＳＴがロー状態にされ、ＶＤＤが供給され、ＤＡＴＡが受信モードにされ、そしてＣＬＫが印加される）に従う。

次にカードリーダはリセットを開始し（すなわちＲＳＴをハイ状態にする）、カードはＤＡＴＡ線上のリセットストリング（ＡＴＲ）に対する応答を、好ましくはＩＳＯ７８１６の適切な部分に指定された内容およびタイミングの詳細に従って返す。好適な実施形態において、Ｔ−１プロトコルを反映するようにインタフェースキャラクタが選ばれる（非同期、半二重、ブロック型モード）。さらにＩＳＯ７８１６−３に従い、カードがＡＴＲストリングを送り、適切なプロトコルが選択された後（好適な実施形態においてはＴ＝１モード）、ホスト３１４およびカード１００は、特定の取引を構成するコマンドおよび応答の交換を開始する。これらのコマンドの性質はさらに詳細に後述される。

スマートカードセッションの終わりにおいて、接触１０６を解除する。接触１０６の解除は、好ましくはＩＳＯ７８１６−３に指定された順で行われる（すなわちＲＳＴをロー状態にし、ＣＬＫをロー状態にし、ＤＡＴＡをロー状態にし、ＶＤＤを非アクティブ状態にする）。上述のように、好適な実施形態においてＶＰＰ接触は用いられない。

本発明のコンテクストにおいて、１）アプリケーションデータとの作業（すなわち様々なアプリケーション内に格納されたファイル）、２）データセキュリティの確実化、３）カード管理、および４）その他の機能を実行するためのコマンドクラスおよび命令が提供される。

アプリケーションデータコマンドは、ファイル内の個々のレコードまたはレコードのグループの選択、読み出し、および更新用に適切に設計される。セキュリティコマンドには、チャレンジ／応答認証プロセスを実行するためのコマンド、乱数を発生するためのコマンド、暗号化鍵をローディングまたは更新するためのコマンド、およびカード所有者確認コードを変更および確認するためのコマンド（ＣＨＶ１およびＣＨＶ２）が適切に含まれる。カード管理コマンドには、ディレクトリ（ＤＦ）および基本ファイル（ＥＦ）の作成および削除を可能にするコマンドが適切に含まれる。ボードレートを変更し、また様々なカード統計値を読み出すための（例えばカードの製造中にログされたデータ）その他のコマンドが、適切に提供される。これらの基本的な機能を実現するために多くの異なるコマンドセットが設計され得ることが理解される。そのようなコマンドセットの１つは、ＩＢＭ Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｃａｒｄ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ ３．５１により提供される（本明細書において参考のため援用する）。

図１０を再び参照して、アクセスポイント１５は好ましくは、ユーザインターフェース（例えばグラフィカルユーザインターフェースなど）を提供し、実行中の特定の取引に応じて適切なＳＣＯＳコマンドを実行することができるソフトウェアを含む。例えば、カード所有者が、レンタカーアプリケーション４１４内の自動車選好ＥＦ８１０に選好を追加したい場合を考える（図８に示す）。この場合、カード所有者は便利なアクセスポイント１５（例えば、モール内の単独で存在するキオスクを探し）、取引を開始するために、設けられたカードリーダにカード１００を挿入する。カード１００とカードリーダとの間に適切なハンドシェークが成立した後、かつカード所有者が正しく認証された後（すなわち自動車選好ＥＦ８１０を更新するための正しいアクセス条件が満たされた場合）、アクセスポイント１５におけるアプリケーションプログラムは、ユーザに選好コードの選択（例えば前述の表３９に挙げたもの）の問い合わせを行う。するとユーザはテキストまたはグラフィカル手段を用いて選択を表示し、適切な値がアプリケーションプログラムによってコマンドストリングの一部としてカード１００に送られる。この値はネットワーク１９を介して適切な提携機関１２（すなわちレンタカー提携先）および発行者１０に送られ得、それぞれのデータベース１３および１１中に格納される。あるいは、このデータは後にカード／データベース同期手順の一部として、例えば元の取引がオフラインで進行するときに送られてもよい。

別の実施例として、典型的なホテル取引を考える。上記に詳細に述べたように、カード所有者が適切なアクセスポイント１５に位置するカードリーダにカード１００を挿入する。適切な初期化手順が行われた後、グラフィカル・ユーザ・インターフェースを用いて、ホテル予約を行うというオプションがカード所有者に提供される。このオプションが選択されると、ソフトウェアは、カード所有者ＩＤアプリケーション４０６内の好適なプログラムＥＦ５２４のホテル選好フィールドを調査して、これらのホテルをまず、可能性のある選択肢のリスト内に表示する。

カード所有者が特定のホテルを選択した後、ソフトウェアはネットワーク１９を介して適切な提携先１２に接触し、特定の日付けセットに対してホテルの客室を要求する。このステップは、上記特定のホテルがアクセスを有するホテルシステムアプリケーション４１２内の様々なファイル（すなわち、ホテルチェーンＤＦ９０２または所有権ＤＦ９０３）の調査を含み得る。あるいは、このステップは（後述するように）チェックインまで延期され得る。

一旦予約がなされると、ホテルによって提供される関連する確認番号が、日付けおよびホテルの所有権コードと共に、予約ＥＦ９１８内の確認番号フィールドにダウンロードされる。このステップは、カード所有者が適切なクレジットカード情報を伝送することを必要とし得、適切なクレジットカード情報は支払１ＥＦ６０４から適切に引き出される。

カード所有者は、ホテルに到着すると、キオスクまたはチェックイン用に提供された他の都合のよいアクセスポイントにアクセスするためにスマードカード１００を用い得る。チェックインは、このようにホテル職員によって補助されることなく行われてもよいし、より伝統的な人どうしのやりとりを含んでもよい。後者の場合、カード１００は主に、フロントデスクの職員によって開始されるチェックインプロセスを合理化するために用いられる。

チェックインにおいて、確認番号情報が予約ＥＦ９１８から引き出され、特定の客室が割り当てられる（事前に割り当てられていない場合）。このステップは典型的には、適切な選好ファイル（すなわち、選好ＥＦ９０４または９１２）から、ベッドサイズおよび客室タイプなどに関する選好のリストを引き出すことを含む。このリストは、使用可能な客室に関するホテルのデータベースと照合され得、それによって客室割り当てプロセスの合理化を補助する。

一旦客室が割り当てられると、割り当てられた客室に対応するデジタルキー（例えば、数値または、ひとまとまりの英数字）が部屋の鍵ＥＦ９１０内に保存され得る。次いでカードリーダが、各客室用のドアロック装置の一部として採用される。ドアロック装置は正しい鍵を受け取ったときのみ開くように構成されている。

チェックアウト時には、支払いカードＥＦ５１０および支払１ＥＦ６０４内に保存されている支払いカード情報を用いて支払いが行われ得る。この場合も、適切なスマートカードリーダ（すなわちアクセスポイント１５）が、チェックアウトに都合の良い任意の場所、例えば，ホテルのロビーまたは個々のホテル客室内自体に提供され得る。その後カード所有者は、得意滞在者ポイントを獲得し得る。これは、滞在者ＩＤ ＥＦ９０６（または９３６）のうちの１つを更新することを含む。ホテルでの滞在中、カード所有者は、ルームサービス、ホテル内施設での食事、および映画鑑賞などに関連する出費を何度でも行い得る。これらの費用、またはその小計は、後の引き出し、プリントアウト、または保管用に費用ＥＦ９１６に都合良くダウンロードされ得る。

レンタカーコンテクストに関連するカード１００の使用は必ず、上述したものと同一のステップのうちの多くを含む。車を割り当てるタスクは、選好ＥＦ８０５内に保存された車に関する選好を引き出し、それを使用可能な車のデータベースと比較することを含む。車を返却すると、カード所有者は、得意レンタルポイントを獲得し得（得意賃借者ＥＦ８０７の更新による）、出費記録が費用ＥＦ８１１内に保存され得る。

航空会社関連では、カード１００は、予約を行うため、好みの事項を記録するため、および上述したような支払い手段を提供するために用いられ得る。さらに、電子チケットがダウンロードされ得（ＥＦ ＩＥＴ ７１０）、搭乗情報が搭乗ＥＦ７１２を介して供給され得る。その後カード所有者の得意旅客マイルを更新するために、得意旅客ＥＦ７０８が用いられ得る。

上述した例としての取引は一般的な用語を用いて説明したが、カード内の適切なメモリ位置への、および適切なメモリ位置からのデータフローの特定の性質は当業者には明らかである。

さらに、本明細書に記載の発明を、添付の図面を参照して説明してきたが、当業者であれば、本発明の範囲はそれに限定されないことを理解する。例えば、本発明の好適な実施形態は、外部接触を有する標準のクレジットカードサイズのスマートカードに関して述べられているが、本発明を実施するためには適切な構造を有する携帯メモリデバイスであれば実質的にいずれの携帯メモリデバイスでも利用され得、例えば、非接触カード、オプティカルカード、ミニカード、および「スーパースマート」カードなどが利用され得ることが理解される。従って、本明細書中で述べた構成要素およびステップの設計および構成の様々な改変が、添付の特許請求の範囲に記載の本発明の範囲から逸脱することなく、なされ得る。

例示的なスマートカード装置を示す。 例示的なスマートカード集積回路の模式図であり、種々の機能的ブロックを示す。 一般のツリー構造において配置されたファイルおよびディレクトリの例示的な図である。 本発明の好ましい実施形態による例示的なデータベース構造を記載する。 本発明による好ましいカード所有者ＩＤデータ構造を記載する。 本発明による好ましい支払システムデータ構造を記載する。 本発明による好ましい航空会社データ構造を記載する。 本発明による好ましいレンタカーデータ構造を記載する。 本発明による好ましいホテルシステムデータ構造を記載する。 本発明を実施する際に有用な例示的分散取引を示す。

Claims (12)

1. 取引を行う外部デバイスと通信するように構成されたタイプのスマートカード装置であって、
   スマートカード本体と、
   該スマートカード本体内に設けられて該外部デバイスと通信するように構成された集積回路デバイスであって、該集積回路デバイスは共通のアプリケーションと第２のアプリケーションとを含み、該共通のアプリケーションはカード所有者の身元を示すしるしを保存するように構成されており、該第２のアプリケーションは該カード所有者に関する旅行関連情報を保存するように構成されている、集積回路デバイスと、
   該集積回路デバイスと該外部デバイスとの間のデータ通信を提供し、かつ、該集積回路デバイスと第１および第２の提携機関との間のデータ通信を提供する通信手段と
   を含み、
   該第２のアプリケーションが共通ファイル構造と提携先ファイル構造とを含み、該提携先ファイル構造が、該第１の提携機関用の該提携先ファイル構造内のフィールドへの書込みアクセスを提供するとともに該第２の提携機関用の該フィールドへの書込みアクセスを拒絶し、該共通ファイル構造が、該第１および第２の提携機関の両方に関して、該共通ファイル構造内の少なくとも１つのフィールドへの書込みアクセスを提供し、該第２のアプリケーションが少なくとも１つのコンテクスト・ベースの選好をさらに含む、スマートカード装置。
2. 前記通信手段が、前記スマードカードボディの表面上に設けられた複数の外部接触を含む、請求項１に記載のスマートカード装置。
3. 前記第２のアプリケーションが、支払いシステムアプリケーションを含む、請求項１に記載のスマートカード装置。
4. 前記支払いシステムアプリケーションが、支払い口座に関連する口座番号と期限満了日とを保存するように構成されている、請求項３に記載のスマートカード装置。
5. 前記第２のアプリケーションが、航空会社アプリケーションを含む、請求項１に記載のスマートカード装置。
6. 前記航空会社アプリケーションが、電子チケットを保存するように構成されている、請求項５に記載のスマートカード装置。
7. 前記第２のアプリケーションが、ホテルアプリケーションを含む、請求項１に記載のスマートカード装置。
8. 前記ホテルアプリケーションが、ホテル予約に関連するデータを保存するように構成されている、請求項７に記載のスマートカード装置。
9. 前記第２のアプリケーションが、レンタカーアプリケーションを含む、請求項１に記載のスマートカード装置。
10. 前記レンタカーアプリケーションが、車の選好に関連するデータを保存するように構成されている、請求項９に記載のスマートカード装置。
11. 前記カード所有者の身元を示す前記しるしが、名前と住所とを含む、請求項１に記載のスマートカード装置。
12. 前記共通のアプリケーションが、汎用読出しアクセスを提供する、請求項１に記載のスマートカード装置。

Images