JP2000508101A - Chip card and usage of chip card - Google Patents

Chip card and usage of chip card

Info

Publication number
JP2000508101A
JP2000508101A JP10528242A JP52824298A JP2000508101A JP 2000508101 A JP2000508101 A JP 2000508101A JP 10528242 A JP10528242 A JP 10528242A JP 52824298 A JP52824298 A JP 52824298A JP 2000508101 A JP2000508101 A JP 2000508101A
Authority
JP
Japan
Prior art keywords
vas
data
card
key
application
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.)
Pending
Application number
JP10528242A
Other languages
Japanese (ja)
Inventor
エンゲルハルト・ホルガー
ハインツ・ミヒャエル
キッシンジャー・ステファン
ゴルナー・ミヒャエル
クッヒェルマイスター・アントン・ヨット
シュバイア・アンドレアース
ブルガー・アデルハイド
ラドノッティ・ミヒャエル
Original Assignee
ドイチェ バンク アーゲー
ベーベー−ダーター ゲゼルシャフト フュア インフォルマチオーンズ−ウント コムニカチオーンズジステーメ エムベーハー
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from DE19718115A external-priority patent/DE19718115A1/en
Application filed by ドイチェ バンク アーゲー, ベーベー−ダーター ゲゼルシャフト フュア インフォルマチオーンズ−ウント コムニカチオーンズジステーメ エムベーハー filed Critical ドイチェ バンク アーゲー
Publication of JP2000508101A publication Critical patent/JP2000508101A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/07716—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising means for customization, e.g. being arranged for personalization in batch
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Hardware Design (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)
  • Credit Cards Or The Like (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

(57)【要約】 トランザクションを実行するチップカード。このトランザクションでは金銭的価値単位または他の非金銭的権利を表す価値データがカード所持者と少なくとも一つのトランザクションパートナー（サービスプロバイダ）との間で転送されるか、または権利の検証のためにサービスプロバイダに提示される。チップカードはトランザクションを実行するために必要なデータをストアする記憶領域を有する。チップカードはさらに、カードに一または複数のカードアプリケーション（VASアプリケーション）をロードする手段、カード所持者とーまたは複数のサービスプロバイダとの間のトランザクションの実行を許可する手段が設けられる。 (57) [Summary] Chip cards that execute transactions. In this transaction, value data representing monetary units of value or other non-monetary rights are transferred between the cardholder and at least one transaction partner (service provider), or the service provider To be presented. The chip card has a storage area for storing data necessary for executing a transaction. The chip card is further provided with means for loading the card with one or more card applications (VAS applications) and with means for permitting the execution of a transaction between the cardholder and one or more service providers.

Description

【発明の詳細な説明】 チップカードおよびチップカード使用方法 技術分野 本発明はチップカード，チップカードを使用するための端末装置，チップカー ド使用方法およびチップカードシステムに関する。 従来技術 例えば電子財布，電子キャッシュ，クレジット機能のようなの支払機能を持っ たマイクロプロセッサチップカードはすでに使用されている。これらのカードは ，ZKA(Zentraler Kreditausschuss，中央カード委員会)，VISA(ビザ)またはEMV( Europay Mastercard VISA，ユーロペイマスターカードビザ)のようなの機関から その特性に従って条件をつけられて，支払手段（貨幣の代用)として使用可能と なっている。ここでは，代表的な資料してつぎのものを挙げる。 −ZKA,“Schnittstellenspezifikation fur die ec-Karte mit chip”，2 7.10.1995（中央カード委員会「チップ付き電子キャッシュカードのインターフ ェース仕様」，1995年10月27日）； −Europay International，“Integrated Circuit Card，Specification for payment Systems，EMV’96”，V3.0，30-Jun-1996（ ユーロペイインターナショナル「支払システムのためのICカード仕様，EMV'96」 ，V3.0，1996年６月30日）； −ISO/IEC 7816-4，“Information technology-Identification cards-Integrat ed circuit(s)with contacts，part4：Interindustry commands for interchang e”，01-09-1995（「情報技術―識別(ID)カード−接点付きIC，第４部 業種間 交換用命令」，1995年９月１日）； −prEN 1546−1，“Identification card systems- Inter-sector electronic p urse，Part1：Definitions，concepts and structures”，15.03.１995（「IDカ ードシステム−セクタ間電子財布，第１部 定義，概念および構造」，1995年３ 月15日）； −prEN 1546-2，“Identification card systems- Inter-sector electronicpur se，Part2：Securityarchitecture，03.07.1995（「IDカードシステムーセクタ 間電子財布，第２部 機密保持アーキテクチャ」，1995年３月15日）； −ｐrEＮ 1546−２，“Identificationcardsystems-Inter-sector electronic p urse，Part3：Dat-aelements and interchanges”，09.12.1994（「 IDカードシステム−セクタ間電子財布，第３部 データ要素および交換」 ，1994年12月９日）； チップカードの現状の概要については以下の資料に記載されている。 Technische Merkmale，Normung，Einsatzgebiet 6，ISBN 3-486-23738-1（ステファン・シュッツ，ベルト・コールグラフ「チッ プカードの技術的特徴，規格，適用分野」オルデンブルク出版，ミュンヘン/ウ ィーン，1996，ISBN 3-486-23738-1）。 従来のチップカードは，通常は，特定の使用目的のためにのみ，例えば電子財 布または電子資格（身分）証明書としてしか用いることができないものであった 。しかし，これらのチップカードに適用されたアプリケーションは一般に静的で あり，すなわち，アプリケーションはチップカード製造時に適用され（取付けら れ），カードの使用期間中は変更されることはなかった。 つまり，従来のチップカードは可変性と機能性において制限されていた。特に ，従来のチップカードはその製造処理後は機能性が固定され，以降の変更は不可 能であった。 発明の開示 したがって，本発明の目的は機能性が変更できるチップカードを提供すること にある。 本発明の他の目的は，チップカードを通して実行できるアプリケーションおよ びトランザクション(取引き)の個数および種類を該チップカード製造処理後にお いても変更できるチップカードを提供することにある。追加のアプリケーション を該チップカードにロードできなければならない。該チップカードからアプリケ ーションを消去できなければならない。さらに，個々のアプリケーションはデー タ処理技術上および機密保持技術上互いに独立して定義され，互いに独立に実行 されなければならない。 該チップカードは，例えば，ISO 7816によるデータ処理技術および機密保持技 術に関する条件を満たさなければならない。ただし，該チップカードの個々のア プリケーションは特にカードのプラットフォームそのものから独立していなけれ ばならない。 本発明のさらに他の目的は，チップカードの使用者（ユーザ）が，該カードで 利用できるアプリケーションの個数および種類を，使用者自身で決定，すなわち 組合わせ，そして変更できるチップカードを提供することにある。 本発明のさらに他の目的は，イントラサービス(すなわち，外部者（外部パー トナー）との清算処理およびサービス転送処理が不要という意味での閉じたアプ リケーション)およびインターサービス(外部者（外部パートナー）との外部関係 を追加的に伴うアプリケーション)の両方に使用でき，これらサービスが実施で きるチップカードを提供することにある。 本発明の一観点によれば，該カード上に一または複数のカードアプリケーショ ンをロードでき，これにより，カード所持者とーまたは複数のサービスプロバイ ダとの間で，各々のアプリケーションによってトランザクションを実行できる装 置が提供される。 該カードはアプリケーションのロードにより新しい機能を有するように構成さ れる。すなわち，そのロード時点まで不可能であったアプリケーションの実行が できるようになる。ロードされたデータによってアプリケーションが定義され， その時点までカードに存在しなかったカードの基本機能性，例えば，オペレーテ ィングシステムと関連してアプリケーションが実現される。したがって，該カー ドはアプリケーションのロードによって，ロードされたアプリケーション分だけ その機能が拡張される。 本発明の一実施態様によれば，本発明のチップカード上にはデータ構造（デー タベース(DF_VAS)）が設け られ，このデータ構造はそれ自身さらに部分構造と定義データセットに分けられ る。ここで，データ構造はその構造を識別するコードにより一意的に識別され， したがってカードプラットフォームから独立である。該部分構造にはいわゆるア プリケーション，すなわち，チップカードのための機能性つまりチップカードの アプリケーションがロードされる。したがって，チップカードに特定のアプリケ ーションをロードすることで，カード所持者と該アプリケーションを特に取扱う サービスプロバイダとの間で，トランザクションが実行できる。データ構造内の 定義データセットは，該部分構造にロードされたアプリケーションの種類および ／または構造を保持する。少なくとも定義データセット，望ましくは全データ構 造は，その修正に関して少なくとも一つのシステムキーによって保護されていて ，該修正はそのキーを使用してのみ可能である。このシステムキーの代わりに， 他の機密保持機構または機密保持手段も考えられる。これによって，例えば個人 識別番号(PIN)または他の機密保持手段を使用して，データを修正から保護でき る。 上記の構造によって，部分構造に各種アプリケーションをロードでき，また， この部分構造から消去できるので，該カードはその機能性においておよび該カー ドを用いて実行可能なアプリケーションに関して可変 となる。アプリケーションのロードと消去は，提供された部分構造内にアプリケ ーション用のデータとキーとを書き込むことで行われる。システムキーとデータ 構造識別コードが提供されることで，多機能（性）処理を可能とするデータ構造 はカードプラットフォームそのものに依存しなくなり，また，機密保持構成に関 してカードプラットフォームから自立していてかつ依存しない。 部分構造内にロードされたアプリケーションに従って，該カードを用いて，該 アプリケーションに依存するトランザクションがカード所持者とサービスプロバ イダとの間で実行できる。 望ましくは，チップカードはさらに転送用記憶領域を含み，この領域にはトラ ンザクション実行で交換されるデータが書き込まれ，また，この領域から該デー タが読み出される。転送用記憶領域からのデータ読み取りのためには端末装置特 有のキーが設けられているので，個々のアクセスは機密保持技術上互いに独立し ている。 カード上にある部分構造とアプリケーションとは，望ましくは互いに独立して いて各々特定のプロバイダに割り当てられている。これらは，いわば，特定なア プリケーションの実行のための，該プロバイダ占有のまたは独自のデータである 。したがって，これらはア プリケーションタイプおよびサービスプロバイダ毎に別々の情報を含む。例えば ，特定値を示すデータ(ボーナス点や預金残額等)，アプリケーションに関する情 報，サービスプロバイダに関する情報などである。しかし望ましくは，特に，ア プリケーション特有のキーを含む。これらのキーにより，該部分構造内のデータ へのアクセスは，他の部分構造とは独立した種類と方法で実行できる。これに対 して，部分構造およびアプリケーション自体のロードまたは生成は，少なくとも 一つの上位システムキーで保護される。 望ましくは，トランザクションの実行前に，チップカードと端末装置の間で相 互の認証が行われる。このために，アプリケーション個有の認証キーおよび部分 構造特有の認証キーが設けられ。 つぎに，トランザクション実行のために，各VASアプリケーションに確保され た部分構造内にデータが書き込まれ，または，該構造から読み出され，または， 転送記憶域を介して該構造内に展開（で実行）される。この書き込み時には，ア プリケーション固有のキーが使用される。展開の場合には，アプリケーション特 有のキーが，望ましくは端末装置特有のキーも使用される。端末装置固有のキー は，例えば，カード内に備えられたキー生成用キーを用いてアプリケーション特 有のデータから生成される。こうして転送記憶域に書 き込まれたデータは端末装置を介してサービスプロバイダによって読み出される 。望ましくは，転送記憶域に保存されたデータ（読み出されたデータ）に無効を 示すマークが付けられる。書き込まれたアプリケーションに特有のものでないサ ービスプロバイダの場合，ここでは，いわゆるインターサービスが実行される。 すなわち，カード所持者のために該所持者の費用負担で，金銭的価値のあるデー タが異なるサービスプロバイダ間で交換される。 他の保護手段としては，トランザクション手続きの権限を検証するためのPIN （個人識別番号）またはパスワードがさらに設けられている。 カードは可変構造なので，別々の時刻に異なった数の種々のアプリケーション をカード内に収容できる。 転送記憶領域から取り出したデータの信憑性は，望ましくは，サイン（署名） キー，ディジタルキー，または少なくとも一個のキーを用いて保護される。これ に関し特に有利な点は，取り出されたデータがその後も転送記憶領域に残ってい れば，該カードによって「取り出されたデータである」とただマーク（ラベル付 け）されることである。これにより，該トランザクションの後でも，実行された トランザクションに関する情報を入手できる。したがって，（データ）取り出し の保護によって，（データ処理が一度のみ行われたと いう）一回性も証明される。 さらに特に有利な点は，転送記憶領域に書き込まれたデータが失効となる有効 期限日付を含んでいることである。これにより，例えば，一定期間有効である切 符の手配を可能とするアプリケーションを実現できる。 望ましくはトランザクションカウンタ（取り引き計数器）を設け，これにより ，トランザクション日付および価値（数値）データを，対応するトランザクショ ンに関して一意的に決定および識別できる。 本発明によるチップカードの有利な実施例によれば，該カードは階層的な記憶 構想（概念）も有する。この構想では，各種キーによって各種レベルにおいて， （データ）修正に対する保護が得られる。また，この構想は，アプリケーション レベルでは，記憶域にロードされたアプリケーションに関して可変である。つま り，個々のアプリケーションは各々固有の特定キーによって他のアプリケーショ ンから保護され，独立している。さらに，全構造（データ）はシステムキーおよ び構造識別コード（識別子）によって保護され，カードプラットフォーム自体か ら独立している。転送記憶装置（領域）の上記構想のために，カード所持者とサ ービスプロバイダとの間で，および異なるサービスプロバイダ間でデータ交換が 可能となる。転送記憶装置 への／からの書き込み／読み出しもキーで保護される。ここで，キーは同様にカ ードに特有，アプリケーションに特有であるが，さらに端末装置にも特有である 。各トランザクションの実行前にされる認証およびオプションとしてのPIN（個 人識別番号）またはパスワードは，本発明のチップカードの安全性をさらに高め る。 請求の範囲第21項から第30項に，本発明によるチップカードを使用するための 端末装置が定義されている。該端末装置は，アプリケーションのロードや消去， トランザクションの実行，データの監視（閲覧）および各アプリケーションおよ び各トランザクションに関連するその他の機能の実行に使用される。カード保持 者とサービスプロバイダとの間のトランザクションの実行方法は特許請求の範囲 第31項から第33項に定義される。本発明によるチップカードへのデータロードは 特許請求の範囲第34項と第35項に定義される。チップカードと端末装置を含む全 体システムは特許請求の範囲第36項に定義される。 ここで，本発明の望ましい実施例をを図面に従って詳述する。図面は以下の通 りである。 図面の簡単な説明 第１図は本発明によるチップカードの概念図である 。 第２図は本発明の構成要素を含む全体システムの概念図である。 第３図は該全体システムのデータの流れを示す。 第４図は可能なアプリケーションクラスおよびトランザクションモデルによる 動作の概念図である。 第５図は本発明によるチップカードの機密保持アーキテクチャの概念図である 。 第６図はVASコンテナの一般的なインプレメンテーション（実施）クラスのデ ータ構造である。 第７図は本発明の一実施例によるVASコンテナの各種インプレメンテーション タラスである。 第８図は本発明の一実施例によるVASコンテナのデータベース（構造）である 。 第９図はインプレメンテーションクラスDF PTのデータベースの概念を示す。 第10図はインプレメンテーションクラスDF ADのデータベースの概念を示す。 発明を実施するための最良の形態 本発明を詳述する前に，以下の説明に使用する概念を定義する。 VAS：付加価値サービス VASカード：VASカードは付加価値サービスに参加可能 にするためのチップカードであり，支払アプリケーション（電子財布のような） 等の他のアプリケーションのほかに，VASコンテナを含む。 VASコンテナ：VASコンテナはVASアプリケーションの管理のための，およびVASア プリケーションの機能を利用可能にするためのデータ構造，アクセス条件，キー および（補助）命令により構成される。 VASアプリケーション：VASアプリケーションはVASデータを含む。VASデータへの アクセスはVASアプリケーションによって制御される。VASプロバイダはVASコン テナ内で一または複数のVASアプリケーションを作動させる。VASアプリケーショ ンの利用は，VASデータの設定（適用），読込みおよび処理によって定義される 。VASアプリケーションはイントラサービスまたはインターサービスのいずれか の形をとる。 VASプロバイダ：VASプロバイダは自身のVASアプリケーションに責任を持つ。該V ASアプリケーションは，ＶASプロバイダがシステムオペレータの基本条件および 自身の載量で作成したものであり，その後システムオペレータおよび端末装置を 介して，カード所持者が使用できるように用意されるものである。VASアプリケ ーションはVASカードのVASコンテナにロードされるベきものであり，ロードされ た後に使用可能になる。イントラサービス：イントラサービスはVASアプリケ ーションの一種類で，各VASプロバイダの排他的管理下で利用される。イントラ サービスアプリケーションは，外部者（外部パートナ）との清算処理またはサー ビス転送処理がないという意味での閉じたアプリケーションである。VASアプリ ケーションはイントラサービスまたはインターサービスのいずれかの形をとる。 インターサービス：インターサービスアプリケーションは外部との追加接続を介 して外部者（外部パートナ）との相互処理を伴うイントラサービスアプリケーシ ョンである。VASアプリケーションはイントラサービスまたはインターサービス のいずれかの形をとる。SO，システムオペレータ：システムオペレータはVASプ ロバイダおよびカード所持者がVASシステムを使用できるようにする。 Issuer（発行者）：発行者はカード発行者で，VASコンテナを含むVASカードを流 通させる。 CH，カード所持者（カードホルダー：カード保持者）：カード所持者またはカー ド所有者はカード（この場合，VASカード）を所持（保持）し，付加価値サービ スに参加するために該カードを使用する者である。カード所持者は必ずしも，本 来のカード所有（権）者でなくても良い。 サービス端末装置（ターミナル）：サービス端末装置は，システムオペレータに よってVASアプリケーショ ン用に設置される。カード所持者はこのサービス端末装置において，自身のVAS カード上のVASアプリケーションを管理（VASアプリケーションのロード，監視（ 閲覧），消去および転送）できる。 ディーラ端末装置（ターミナル）：ディーラ端末装置は支払機能を有し，さらに VAS機能性を提供する。カード所持者はこの端末装置にVASカードを差し入れ，一 方では支払いをし，同時に，VASの利点に与る。 AID:（アプリケーション識別子）アプリケーションを一意的に区別するための最 大16バイト長のアプリケーション名で，カードのデータ構造の知識がなくても外 部からのアプリケーション選択にも使用される。この識別子AIDは５バイトの登 録アプリケーションプロバイダ識別子(RID)とオプショナルな最大11バイトの占 有アプリケーション識別子登録（PIX）から成る。 DF：ISO 7816に従うディレクトリファイル。 EF：ISO 7816に従うエレメンタリファイル。 有効VASコンテナ：外部世界に対して認証可能なVASコンテナ。 KID：（キー識別子）。キーを含むエレメンタリファイル内のキーの番号。 R&R：ルールとレギュレーション（規則と規定）。 p：インプレメンテーション（実施）クラスDF_PTのオブジェクトの最大個数。 a：インプレメンテーションクラスDF_ADのオブジェクトの最大個数。 nrDIR：オブジェクトの最大総数：nrDIR＝p+a EF_DIR内のレコード数はnrDIRである。 nrEF_TRANSFER：EF_TRANSFERのレコードの数。 第１図は本発明によるチップカードの構造を図式的に示すものである。カード 作成（製造）処理中に設定されるマスターファイルMFや（オプションで設けられ る）財布機能DF_PURSE等の静的で不変なデータに加えて，さらに，インデックス ，すなわちデータ構造，またはデータベース構造DF_VASが本カード上に設けられ る。これは追加機能性，いわゆる付加価値サービスVASを提供するために役立つ 。アプリケーションを実施する上記追加機能性−これらは後に，すなわちカード 作成後でもカード上にロードできる−により，カードは自身の機能性およびそれ によって実行されるトランザクションに関して柔軟かつ可変である。本発明によ るチップカードに設けられた，いわゆるVASコンテナ（DF_VAS）により，カード の機能に関する可変性と柔軟性が得られる。さらに，該コンテナはカードに収容 されたアプリケーションを，機密保全技術上，カードプラットフォームから分離 している。このため，該アプリケーションはカードプラットフォームから独立し ていて，場合によっては他のカードへの転送さえ 可能である。 本発明による新規な機能性（付加価値サービスVAS）はマイクロプロセッサチ ップカードによって実現される。これらの新機能性はVASコンテナによって実施 される。マイクロプロセッサチップカード上のVASコンテナはVASアプリケーショ ンを受け入れるためのプラットフォームを形成する。VASアプリケーションは特 定の追加機能性をそれぞれ実現するものである。 電子財布において，カードでの支払い（支払機能）とVASアプリケーション（ 追加機能性）の利用とは別々の機構によって実行される。しかし，カード使用者 （カードユーザ）またはカード所持者（カードホルダー）には，これらは一つの 手続きに見える。 マイクロプロセッサチップカードは，独立した各種アプリケーションを収容で きるVASコンテナによって拡張される。コンテナはアプリケーションの適用（設 定），消去および転送のための機能を提供する。これらの機能は権限を持つシス テムオペレータによってのみ使用可能である。VASコンテナはマイクロプロセッ サチップ上の他のシステム構成要素にデータ技術的にも機密保持技術的にも依存 しない。VASコンテナは自身で完全に定義でき自身で機能できる。該コンテナに は独立した機密保持アーキテクチャ（構成）が定義されているので，VASアプリ ケーションは独自の機密保 持機能を利用できる。この機密保持アーキテクチャはカードに特有のキーを使用 する。該キーは製作者（カード作成者）に特別のものでもなく，カードプラット フォームの識別特徴にも依存しない。 VASコンテナは端末装置特有のキーを生成する機構も使用する。この機構によ り，VASコンテナは自身で積極的に端末装置の信憑性（確実性）および該端末装 置によって生成されたデータの信憑性を検証（チェック）できる。 VASコンテナにはVASアプリケーションがファイルされる。VASコンテナの機構 を介してデータが利用可能となり，これにより関連インターフェースの制御が行 なわれる。VASコンテは，パートナ間のインターサービスのための安全なデータ 交換を可能にしかつ制御する。VASコンテは積極的に制御動作をする。すなわち ，転送データ値の信憑性と唯一性（一回性）を制御する。 VASコンテはマルチアプリケーションカードへの他のアプローチと比較して， 上記概念（構想）が特定のカードプラットフォームに依存しない点で有利である 。これにより，プラットフォームに特有な機密保持機構（キー，識別データ，個 人識別番号（PIN），署名方法等）に依存しない機密保持アーキテクチャが提供 される。 VASコンテの概念の他の利点は，カード上の各種アプリケーションの個数がカ ード作成またはカード発行の時点の制限や条件によって厳しく定められないこと である。カードへの実際のアプリケーションのロードはカード所持者が自由に選 択でき，各カードの使用可能記憶領域によってのみ制限される。カードに実際に ロードできるVASアプリケーションの個数はカードの実際の使用に依存する。カ ード使用者はそのカードに個々にVASアプリケーションを集める。その後，この アプリケーションの組合せを変更しても良い。VASコンテナにより多機能カード が可能となる。カードの使用期間中，カード機能性は，アプリケーションの個数 と種類を変更して組合せたり使用したりすることができる。このため，従来個々 の特定カードが必要であった複数のアプリケーションを一枚のカードにロードし て使用できる。VASアプリケーションは他のカードにも転送可能である。これに より，VASアプリケーションはカードの使用期間を越えることができ，アプリケ ーションの使用期間の間，カード使用者に随行する。 追加サービスを有するマイクロプロセッサチップカードはサービスの流通およ び売買のために適した媒体であり，その場合には保護されたデータにアクセスせ ねばならない。これらマイクロプロセッサチップカードは支払手段，カウンティ ング・ユニット（装置）お よび数値記憶装置としても使用できる。該チップカード発行後，顧客自身の要望 にしたがって，他のサービスを柔軟的に該カード内に設定し，それらのサービス の制御のために該カードを使用することができる。マイクロプロセッサチップは 関連する端末装置の信憑性を積極的に制御し，転送されたデータの唯一性（一回 性）および信憑性を保証する。 第２図はシステム構成図を示す。ここにはシステム構成要素が示されている。 システムオペレータは本発明システムを利用できるようにする。サービス端末装 置（ST）においてはVASアプリケーションがロード，消去および転送可能である 。他の動作には，VASアプリケーションの選択，監視（閲覧），解釈等がある。 VASアプリケーションの提供者，いわゆるVASプロバイダはシステムオペレータ の基本条件に従って自身のVASアプリケーションを，可能な限り自身の構想に従 って設計する。対応する端末プログラムの信憑性はディジタル署名の締結によっ て検証（チェック）できるようになる。 第３図はシステムにおけるデータの流れを示す。 VASアプリケーションは，システムオペレータによって，カード使用者の端末 装置において利用可能にされる。VASアプリケーションは，利用（参加）可能と するためには，本発明によるチップカードのVASコン テナ(VAS-Container)にロードされなければならない。 ディーラ端末装置(HT)ではカード上にあるVASアプリケーションが利用され，V ASデータが適用（設定）されたり，または消去されたりする。 VAS機能性をもつマイクロプロセッサチップカードの実現のために，VASコンテ ナの他のアプリケーション（例えば，電子財布のような支払アプリケーション） がさらにカードに設定される。 VASコンテナは，VASアプリケーションの適用（設定），消去および転送を可能 にする機能を使用する。これらの管理機能はシステムオペレータによってのみ使 用され，他の人の使用に対してカード内で保護されている。VASコンテナは転送 記憶装置を備えていて，これにより，VASアプリケーション間のデータ交換が実 現する。 転送記憶装置を制御するために，２個の命令TRANSFERとTAKEが使用される。TR ANSFER命令は各アプリケーション特有のデータの転送記憶装置へのエントリを生 成する。このユーザデータの他に，処理の制御に必要なエントリとして日付，有 効期限および識別データ等がある。TAKE命令では，転送記憶装置からオブジェク トが取り出され，取り出されたことがマークされる。個々のアプリケーションに 従って，オブジェクトは まだ有効かまたは無効かマークされる。転送データはVASコンテナによって信憑 性と唯一性（一回性）の検査を受ける。 VASアプリケーションはアプリケーションを利用可能とし（準備，設定）制御 をするためにVASデータを使用する。VASデータへのアクセスは，このための機構 としてのVASアプリケーションによって制御される。該構成はVASコンテナ内の全 てのアプリケーションのために用意されている。VASプロバイダはVASコンテナ内 で１個または複数のVASアプリケーションを作動させる。VASアプリケーションの 使用は，VASデータの設定（入力），読込みおよび処理によって規定される。 VASコンテナはインターサービスをサポート（支援）する。インターサービス は共有（共通）データへのアクセス，サービス要求の転送および異なるパートナ 間のサービスの清算（支払い）を必要とする。 次に，本発明によるチップカードで可能となるサービスおよびアプリケーショ ンを例を挙げて説明する。 以下の説明はそれぞれ現在の技術水準での実施および機能に関する。該機能は 将来は1個または複数のVASアプリケーションによって実現されるものである。 まずイントラターサービスを説明する。 例A：顧客クラブ(Customer club) 百貨店が顧客クラブを主催している。顧客はクラブ 会員になり，その資格で，クラブ会員でない者には手に入らない特有のクラブサ ービスを受ける。現在では，クラブ会員はクラブ環境においてクラブ会員証によ って資格（身分）証明する。会員証は入会時に作成されるが，譲渡できないし， 通常は有効期限を有する。会員証によっては，特有のトランザクションを実行す ることはできない。つまり，顧客の取引高との連携がない。したがって，会員証 は，顧客のステータスと取引額が関連しているボーナスプログラムに対して制限 されている。 類似システム：卸商証明証，セネタ(senator)カード，ブッククラブ 目標：クラブ会員であることはVASコンテナ内のアプリケーションによって証明 されなければならない。 例B：ボーナスシステム 顧客はトランザクション毎にボーナス権利を受ける。ボーナス権利は累積され 顧客が決めた時点で，金銭価値に交換できる。ボーナス権利は一定期間有効で， 無記名または記名で管理される。ボーナス権利は取引高または使用頻度に応じて 発生する。 類似システム：マイルアンドモア(Miles&More)のポイントステータス 目標：ポイント残高はVASコンテナ内のアプリケーシ ョンで管理されなければならない。 例C：割引 顧客はプランに従って（取引高に対して）割引を受ける。割引は各トランザク ション毎に認められる。カードは取引履歴を管理しない。各トランザクションは それ自身で完結している。 目標：割引（要求）権利はVASアプリケーションで管理されなければならない。 例D：資格証明機能 カード内の特徴により，特定のサービスを受ける資格があることを第三者に対 して証明できる。証明書が提示者本人のものかは各トランザクションのさいに証 明されなければならない（写真，個人識別番号(PIN)，ビオメトリック（生物測 定））。証明書の信憑性は機密保持の特徴として使用される。 類似システム：インターネットアクセス，ホームバンキングアクセス，テレホン カード 目標：資格付与（認定）はVASアプリケーションで証明されなければならない。 例E：価値の単位 価値単位は購入され，一回または複数回の使用によって消費される。各トラン ザクション毎に，１単位または複数単位が減算される。使用権限は譲渡でき使用 条件をつけることもできる。 類似システム：通常乗車券，回数券，定期演奏会チケット，スクワッシュ(squas h)10点券，映画鑑賞券，電話機 目標：本トランザクションはVASアプリケーションによって合理化されなければ ならない。 例F：利用料金の清算（利用者への送り状）サービス利用は時刻，頻度および量 について登録され，料金表に従って清算される。必要とするサービスの範囲を事 前に知ることはできない。 類似システム：食事クーポン，短時間駐車券 目標：料金表による清算はVASアプリケーションによって行われる。その都度必 要な最新清算データはVASコンテナに保存されなければならない。 例G：メモ媒体（データレコード；移動データベース） 本アプリケーションによりカード所持者のデータをVASプロバイダに転送でき る。これにより，今日なお手作業で行われているトランザクションを自動化でき る。このデータからは金銭的移動は発生しない。 類似システム：くじ引き券の記入，購入品リスト，領収書，電話登録 目標：VASプロバイダはカードのデータを取出し対応するサービスを直ちに提供 できなければならない（例えば，電話の接続，要求された品物の収 集，くじ引き券の電子的記入と記録）。データはカード内に短期間または長期間 保存できる。 以上イントラサービスの例を説明したが，続いてインターサービスの数例のみ を説明する。 インターサービスは，サービスに複数のVASプロバイダが関与するときに必ず 発生する。そのさい必然的に，データはある１個のVASプロバイダの領域を離れ る。これは現時点では紙上に証明を書くこと（紙上のレコード）によって実行さ れている。 例A：乗車料金精算 顧客が来店に使用する公共交通機関の乗車料金を百貨店が払い戻す。顧客はそ の乗車券を百貨店に提示しなければならない。百貨店は払い戻しが済んでいる旨 を券上に記録する。場合によっては，百貨店は顧客に払い戻した金額の一部を該 交通機関から受け取ることもある。 目標：払い戻し手続きは電子的に実行されなければならない。 例B：乗車クーポン（voucher，バウチャ） 百貨店は，顧客が買い物したとき，帰りの交通費を乗車クーポンを発行して顧 客に支払う。顧客は切符売場に行きクーポンで乗車券を手に入れるか，不足分を 払って乗車券を求める。交通機関は百貨店との間で該クーポンを清算する。 目標：百貨店と公共交通機関との間の電子的清算処理に関するVASアプリケーシ ョンによる機構モデルの作成。 例C：顧客用駐車場 百貨店は顧客が特定の駐車場を利用した場合に，駐車料金の一部を払い戻す。 駐車場は独立した企業で経営され，百貨店から各顧客の借り分の支払いを受ける 。 目標：百貨店と駐車場との電子的清算処理に関するVASアプリケーションによる 機構モデルの作成。 例D：多重ボーナスプログラム 貿易企業グループとサービスプロバイダとの間で共通ボーナスプログラムを行 うことで意見が一致する。 目標：各パートナはカード内の共通口座のボーナス点を加算または減算できる。 パートナ間のサービスの清算はバックグラウンドシステムで実行される。 例E：サービスプロバイダ間におけるボーナス点の認知 各サービスプロバイダは自身のボーナスプログラムを作動させるが，積算され た他のボーナス点を認知することについて合意に達している。既知の例では，レ ンタカー会社と航空会社との「マイル」累積(collection of“miles”)に関する 同意が挙げられる。 目標：カードによってボーナス点を転送することをサポートする。各サービスプ ロバイダはまず，他からの介入なしに自身のボーナス点を積算する。転送のため に，安全な機構を用意しなければならない。 例F：夜間タクシー 乗車ができる（例えば午後１０時以降）。タクシー会社は清算にさいし乗車証が 提示されたことを証明せねばならない。不法使用を避けるためにタクシーを利用 したことをカードに記録する。 目標：本サービスの利用，制御および利用料金処理はVASアプリケーションで実 行されなければならない。 続いて，本発明によるチップカードの構成を詳述する。 VAS機能性を持つマイクロプロセッサチップカードは，特に，VASコンテナを有 している。 VASコンテナは独立したアプリケーションであり，基礎となるカードプラット フォーム上に，単独でまたは他のアプリケーションと共に存在する。VASコンテ ナは完全に自己定義され単独で機能できる。該コンテナは，通常同一カード内に ある支払機能なしに作動可能である。特に，VASコンテナには独立した機密保持 アーキテクチャが定義されているので，VASアプリケーションは独自の機密保持 機能を使用できる。 付加価値サービスには，VASプロバイダの端末装置にいる顧客からのトランザ クションも含まれる。VASプロバイダは，システム監視（閲覧）や統計データな どの収集等の目的で，これらのトランザクションを追跡（モニタ）する。カード 内のデータ構造を最適化および統一化するために，アプリケーション特有の識別 番号の使用を控え，システム全体で一意的なVASコンテナ識別番号（VASコンテナ ID）を使用することを推薦する。この番号は上記機能の実現のためにVASプロバ イダが使用できる。この番号によって，プロバイダは自身の番号システムを管理 する負担がなくなる。 VASコンテナの機密保持アーキテクチャは，カード特有のキーを導出（生成） するために，このシステム全体で一意的な識別番号(ID)を使用する。該カード特 有の番号の使用は原則的には可能であるが，望ましくは使用しないほうがよい。 これは，VASコンテナが異なるプラットフォーム上に設置されると，互いに矛盾 する番号システムを使用することとなる場合があるからである。 VASコンテナIDはシステムオペレータによって発行され，該VASコンテナの生成 時にカード発行者によってエンターされる。このIDは該VASコンテナの消去に よって無効となり，これによりシステムから除去される。VASコンテナがVASアプ リケーションを全く含まなくなりかつVASコンテナIDが除去されると，このVASコ ンテナは消去されたとみなされる。 古いカードのVASコンテナをそっくり新しいカードに転送するさいには，VASコ ンテナIDもVASアプリケーションと共に送られる。この転送は，VASコンテナを古 いカードから新しいカードに移送ことに対応する。この手続きの後には，古いカ ードにはVASコンテナはもはや存在しない。新カード上にあったVASコンテナは上 記処理によって上書きされ消される。VASコンテナIDは古いカードから新カード ヘ移されたので，VASプロバイダのバックグラウンドシステムでは，参照番号の 変換は不要である。 個々のVASアプリケーションは，各々のVASプロバイダの制御下でのみ，２個の 異なるVASコンテナ間で転送可能である。この機能により，VASコンテナIDとVAS アプリケーションとの（割り当て）関係が変わるが，これは場合によってはVAS プロバイダのバックグラウンドシステム内で記録されなければならない。 VASコンテナは個人的特徴の情報を持たない。VASアプリケーションは個人に関 するデータを含むことができるが，その範囲は，データ保護の観点および記憶域 の有効利用の観点から，最小限に抑えられる。必要な らば，VASアプリケーションは個人に関するデータをバックグラウンドシステム に保存し，カードとの関連をVASコンテナIDを用いて設定（構築）することにな る。 VASコンテナの本質的な特徴はインターサービスをサポートすることである。 インターサービスは，共有（共通）データへのアクセス，サービス要求の転送お よび異なったパートナ間のサービスの清算を要求する。VASコンテナはこれらを 可能とし，にもかかわらず，イントラサービスにおけるアプリケーションの安全 性を保証しなければならない。 いわゆるイントラサービスのVASアプリケーションは，VASプロバイダの排他的 制御下で作動させられるアプリケーションである。VASプロバイダはアプリケー ションの安全性を外部に依存せずに定義する。キーが他に渡されない限り，外部 の他者はVASデータを変更できない。 インターサービスを効率的に実行するためには，パートナは共有（共通）デー タにアクセスできなければならない。共有データアクセスは段階分けされた機密 保持機構を介して実現される。 共有アクセスの最初の段階（ステップ，レベル）は，公開転送領域のみを通し て行われる。VASプロバイダはこの領域を介してデータ交換できるが，互いにア プリケーションおよびキーを知る必要はない。転送領域にデータを書き込むため には端末装置は適切なキーを使用せねばならないが，読み出すときにはその必要 はない。データ読み出しは誰でも制限なしで可能である。VASプロバイダとパー トナとの間における両方向データ交換は，両者が書き込み用キーを利用（入手） 可能であれば可能である。転送データはVASプロバイダのイントラサービスVASア プリケーションが作成することもできるし，逆に，VASプロバイダが転送領域か ら自身のイントラサービスVASアプリケーションにデータを取り入れることもで きる。 第２の段階は，VASデータの形式で表された価値単位を無効に（キャンセル） することである。VASプロバイダは書き込み用特別キーを用いて価値単位をVASデ ータに取り入れる。価値単位は，全体を制御するVASプロバイダから得たキャン セル用キーを使用することが可能なインターサービス・パートナによって消費さ れる。この段階では，相互に異なる権利を有するパートナは非公開のVASデータ をアクセスする。 第３の段階は，すべてに関係するインターサービスパートナによるVASデータ への直接書き込みアクセスである。VASデータは制限なしに変更され得るので， この方法ではパートナ間にそれ相応の信頼関係が必要である。 転送領域はVASアプリケーション間の結合部（コネクティング・リンク）の働 きをする。この転送領域のデータはVASコンテナ内のVASアプリケーションよって 生成される。生成者がVASコンテナ内で自身のVASアプリケーションを作動させな ければ，データは転送領域に直接置かれてもよい。 転送領域は基本的に全てのアプリケーションによって利用され得るが，書き込 みは，その権利（キー）を有するアプリケーションのみに許される。規則，つま り，規則と規定（R&R）の観点から権利を有する受信側(アプリケーション)のみ が転送領域からデータを取り出せる。受信側は自身宛てに送られた転送データが あるかを調べ，自アプリケーション内での処理のために該データを取り出す。 転送データが公開の(データ)交換においてごまかされる(改ざんされる)のを防 ぐために，データ生成者は信憑性特徴（情報）を導入し，VASコンテナは連続番 号を導入する。これらの要素によって，転送情報の唯一性が保証され，データの 出所が証明される。 必要であれば，転送データの受信側に対して，データ生成者は信憑性検査を実 行する可能性(手段)を設定する。これを受信側が希望しない場合には，データ受 け入れはやはり忠誠と信用に従って行われる。場合によっては，信憑性特徴情報 は，データ生成VASプロバ イダのバックグラウンドシステム内において清算時に初めて検査される。 データは転送領域から，信憑性特徴情報を維持して，一度だけ取り出すことが できる。取り出しにさいして，データはマークされ，転送領域内に（写しとして ）残される。これにより，データ取り出し後も，転送手続き後の一定期間は，該 転送手続きを証明できる。 転送領域内のデータは有効期限を含む。これは必要であれば任意のアプリケー ションによって上書きされ得る。転送領域内のデータは取り出されたときにマー クされ得るので，直ちに上書きに使用できる。転送データセットの有効期限内に おいて，転送記憶域が満杯になった場合には，サービス端末装置においてカード 所有者は，既に不要となったエントリを消さなければならない。 VASアプリケーションのモデル作成には，３つの動作が定義される。これらの 動作はVASデータに対して作用する。アプリケーションのロードと消去はVASコン テナの機能であり，以下の段落では考慮されない。 獲得：一般にサービスを要求する資格の獲得およびVASアプリケーションのVASデ ータ内で(獲得の)証明をすること。 キャンセル：一般に，アプリケーションのVASデータ（無効化） の消費なしで ，またはVASデータのすべ てもしくは一部を消費して要求を実行すること。この手続きによって電子領収書 が作成され，それは転送領域に置かれる。領収書には重要な有効期限，つまりデ ータが転送領域から消去可能な期日が記述される。 取り出し：一般に，後の処理（バックグラウンドシス（移動） テムでの）のた めに，転送領域から電子領収書を取り出すこと。領収書の写しは残され，「キャ ンセル」の証拠になる。 VASデータの「獲得」は各VASプロバイダによってのみ行われる。VASデータの 「キャンセル」は，該データを「獲得」で生成したVASプロバイダによってのみ 行われるか，または，該VASプロバイダが認可したインターサービスパートナに よってのみ行われる。「取り出し」はどのVASプロバイダでも実行可能である。 同等な権利でのVASデータへのアクセスのないインターサービスでは，パートナ は状態転送「取り出し」を起動させる。その結果得られた領収書は，つぎにシス テムオペレータおよびVASプロバイダのバックグラウンドシステムを介して清算 される。「獲得」と「キャンセル」は単一ステップで実行され得る。 共通特徴をもつVASアプリケーションはさらにクラス分けされる。これらのク ラスはVASコンテナ内のデ ータ構造の基礎を成す。VASプロバイダはそのアプリケーション実施に当たって あるアプリケーションクラスを選択する。 これに関し，以下のアプリケーションクラスを定義する。 ・点数(記憶領域)データベース ・チケット ・資格(身分，識別)証明書 ・証書 ・データベース 点数データベースは点数値の口座が管理されるアプリケーションクラスを示す 。この点数口座には点数値が加算（クレジット）または減算（引出し）される。 加算はVASプロバイダによって，新口座残高をデータベースに書き込むことで行 われる。減算は「キャンセル」動作によって行われ，証拠として電子領収書が転 送領域（記憶域）に書き込まれる。これらの機能へのアクセスは２つの異なるア クセスキーを用いて実行される。 チケットは，一回ないし複数回キャンセルされ，それによって消費される数値 領域を含むアプリケーションクラスを示す。チケットでの数値の加算（クレジッ ト）は一回だけ行われる。 資格（身分，識別）証明書は，VASデータが権利認 可の証明を含むアプリケーションクラスを示す。通常，この証明は使用によって 取り消されないが，定義された基準によって，例えば時間的有効期限が切れるこ とによって無効とされる。アプリケーションの定義に従って，身分証明書の信憑 性（例えば住人用駐車証明書）または身分証明書の提示が文書化される。（例え ば，月極チケットでの相乗りタクシー:カードによる電子領収書の作成。この領 収書はタクシー会社から公共交通機関に提出され，取り分に応じて清算される。 ）オプションとして，該証明書の使用を，カード内の転送記憶域において電子領 収書によって文書化できる。 証書はサービス要求（通常は短期間）を一時的にカードに保存するアプリケー ションクラスを示す。この電子的証書はVASコンテナの転送記憶域（領域）にの み保存される。通常，証書を使用するアプリケーションは証書を作成するアプリ ケーションと異なる。転送記憶域からの証書取り出しは一度だけ可能で，カード によって文書化される。VASコンテナによって作成された信憑性特徴をバックグ ラウンドシステムでの清算に使用してもよい。 データベースは，VASプロバイダがデータをVASコンテナに保存するアプリケー ションクラスである。該クラスは顧客に追加サービスを提供する（例えば，ファ ミリーレストランの最後のメニュー，最後のくじ引き番号，サービスの好み，提 案リスト）。データは参考（情報の目的）だけのためであって，VASプロバイダ へのサービス要求を表さない。このデータへのアクセスはVASプロバイダによっ て制御される。 各アプリケーションクラスは代表的な使用サイクルで特徴づけられる。次表に ，アプリケーションクラスのVASデータに対する上記３種類の動作の適用周期を 示す（注，「獲得」は「アプリケーションのロード」ではないし，「キャンセル 」は「アプリケーション消去」ではない）。 表 １ 使用サイクル *** アプリケーションクラス「データベース」では権 利を獲得することはなく，アプリケーションはデータを入力するだけである。 第４図は上記のアプリケーションクラスおよび動作をトランザクションモデル によって示している。 つぎに，本発明によるチップカードの機密保持アーキテクチャについて詳述す る。機密保持を保証するために以下のキーが定義される。 表 ２ キー一覧 機密保持アーキテクチャはVASコンテナおよびVASアプリケーションのライフサ イクルを基礎とし，関連するインスタンスの責任に従って階層構造をなす。その 概念図を第５図に示す。 つぎに，VASコンテナの構造とそこに設置されたアプリケーションについて説 明する。 VASコンテナとVAS用補助命令は発行者から他の非VASアプリケーションと共に カード上に設定されるか，遅くともサービス端末装置で，認可されたプロバイダ によって現時点のカードプラットフォームに統合される。 第二の可能性としては次の機構が使用され得る。システムオペレータと発行者 との間で暫定キーKSO *を決める。発行者は自身のみに既知のキーでカードを開設 し，VASコンテナのフアイルを作成し，特に，暫定キ ーKSO *を(このファイル)DF_VASに書き入れる。これにより，システムオペレータ は後に（例えばこのカードが始めてサービス端末装置で使用されたとき）暫定キ ーKSO *を自身だけが知っている自分のキーKSOに置きかえることができる。これ で，システムオペレータはその他のデータたとえばKGKDECを自身で入力でき，ま たは，動的管理を有するプラットフォームの場合には，VASアプリケーション用 のファイルを自身で生成および消去できる。したがって，発行者は最初のVASカ ード使用後は，VASコンテナにはもうアクセスせず，システムオペレータのみがV ASコンテナにアクセスすることが保証される。他のアプリケーションとは共有（ 共通）データベースもデータ交換もないので，VASコンテナの機密保持アーキテ クチャはカードプラットフォームに存する他のアプリケーションに依存しない。 本発明の特別な実施例では，しかし，第一の可能性を使用しなければならない 。発行者はシステムオペレータの指示に従ってVASコンテナを全キーと共にVASカ ードに設置しなくてはならない。 VASコンテナは所定のファイル構造，所定のアクセス条件(AC)および数個のグ ローバルデータを含む。特に，グローバルデータはVASアプリケーションのロー ドと消去に用いるキーKSOを含む。このシステムオペレータのみに分かっている キーによって，許可されたVA Sアプリケーションのみがロードされ得る。このために，カードはキーKSOを通し てシステムオペレータによる外部認証を要求する。 カード保持者がサービス端末装置において，VASアプリケーションをロードし たいときには，担当VASプロバイダが，この処理を代わりに実行することをシス テムオペレータに依頼する。VASコンテナへのVASアプリケーションのロードの場 合，VASプロバイダはシステムオペレータにキーKLVASPとKRVASPを渡し，該オペ レータはこれらのキーをアプリケーションに入力する。キーKLVASPによって，VA Sプロバイダは，アプリケーションデータを書き込みアクセスから保護し，さら に内部データを読み取りアクセスから保護する。この目的のために，カードはVA SプロバイダのキーKLVASPに基づいた外部認証を要求する。すなわち，カードは 端末装置の信憑性を積極的に検査する。この機能が成功すれば，VASアプリケー ションの書き込みアクセスおよびアプリケーションの内部VASデータの読み取り アクセスが，この端末装置に許可される。内部認証，すなわちディーラ端末装置 による信憑性に関するVASアプリケーション（したがって，カード）の検査はオ プションで実行される。カード所持者によるVASアプリケーションの使用時には ，これら内部VASデータのアプリケーションへの書き込みおよびアプリケーショ ン内での 変更は，キーKLVASPを使用できる任意の端末装置から可能である。したがって「 獲得」機能は，キーKLVASPによる外部認証を条件とするUPDATE RECORD命令によ ってサポートされる。 VASアプリケーションの非内部データへの読み取りアクセスは，キーKRVASPま たはKSOによって，または個人認識番号(PIN)またはパスワードの適切な入力によ って，外部認証がシステムオペレータによって既に行われているときにのみ許可 される。個人認識番号またパスワードで保護されたアクセスは，カード所持者が 端末装置またはワレット(財布)においてデータを参照できるように設けられてい る。サービス端末装置のカード保持者は，価値データまたはステータスデータの 読み取りに関するPINまたはパスワードによる保護を，同時に全アプリケーショ ンに対して活性化（実行状態）するか，または不活性化（非実行状態）するかを 選択する。 VASコンテナ内のグローバルデータには転送領域から取り出したデータの署名 用キーKSIG_VASCが対応している。インターサービスパートナ間でトランザクシ ョンデータを清算処理のために，ごまかし保護の下で，転送しなければならない 場合に，トランザクションの完全性（ごまかしの無いこと）をこの署名によって 証明できる。インターサービスパートナによって記入され たオプションの署名に加えて，該カードが「取り出し動作」によって出力したデ ータセットに対して，KSIG_VAscとVASコンテナの管理下のトランザクションカウ ンタとに基づく署名が付加される。転送領域の読み取りは誰にも許されているが ，KSIG_VASCによるカードの署名は「取り出し動作」の呼び出しによってのみ生 成される（これはただ一回だけ可能である）ので，証書に関する許されない二重 清算処理が検出される。各インターサービスパートナは，取り出された証書の信 憑性と（処理の）一回性（唯一性）をシステムオペレータに確認してもらうこと ができる。さらに，システムオペレータは署名の検査をすることでVASコンテナ の信憑性を証明できる。 カードプラットフォームが非対称のキー手続きをサポートしていれば，カード 内の個人（秘密）キーをKSIG_VASCとして署名に使用でき，または，このような キーを個人キー生成キーから生成することができる。この場合，VASプロバイダ は，システムオペレータに相談しないで，公開（秘密でない）キーを自身の署名 検査のために使用できる。 VASコンテナのデータにはグローバルキー生成キーKGKDECがその一部として含 まれる。このキーは全てのVASプロバイダの全端末装置に対して，「取り出し」 動作の権限の検査のために，アクセスキーKDEGを生成で きる（キーの生成と検査についてはさらに後述する）。金銭的価値データのキャ ンセルでは，権利のロードまたは獲得のときとは異なった機密保持基準が使用さ れる。ここでは，アプリケーションに特有のキーの代わりに，グローバルキーを 使用すれば足りる。このグローバルキーは先ずアプリケーションキーに変換され ，つづいて，端末キーに変換される。VASプロバイダには，自身の端末キーの生 成のための，グローバルキーから得られたアプリケーションに特有なキーのみが 知らされる。つぎに，これについて簡単に説明する。 あるメッセージdおよびDESによるDESキーkのためのメッセージ認証コードの計 算をmac(k,d)で示す。情報が8バイト以下であれば，この式はエンコード(キー生 成符号化)そのものに対応する（ただしICV=0とする）。それに続いてパリティビ ットを適用したmac(k,d)の計算をmacp(k,d)で示す。その結果k’=macp(k,d)もま た有効なDESキーである。 こうして，アプリケーション特有の端末キーの計算はつぎのようになる。 1．各カードは1個のキー KGKDEC を記憶する。このキーは全カードに対して同一で，システムオペレータの秘密（ 事項）である。システムオペレータはこのキーがカード内で個人化 されるようにする。 このキーから，他のすべてのVASアプリケーションキーも端末キーも導出でき る。 2．VASプロバイダはVASアプリケーションAをAIDA=RIDVASPIXAと共に導入しよう とする。ここで，システムオペレータはキーKGKDECとPIXからアプリケーション 特有なキーを計算し， KGKDEC,PIX=macp(KGKDEC,PIXA) このキーをVASプロバイダに渡す。 3．VASプロバイダは，VASアプリケーションAにTRANSFER（転送）命令を適用しな ければならない全端末のために，KGKDEC,PIXから，各々の端末識別子(Terminal ID)を使って各々に特有なキーを生成する。 KGKDEC=macp(KGKDEC,PIX,Terminal ID) =macp(macp(KGKDEC,PIXA),Terminal ID） VASプロバイダはこれらのキーを自身の端末装置に記憶する。VASプロバイダ自 身で端末装置を操作しない場合には，VASプロバイダはキーを生成し，それを端 末装置のオペレータに与える。 4．VASカードは，TRANSFER命令が端末装置で作成された暗号Cを含んでいるとき にのみ，この命令 を実行する。暗号Cはメッセージの特定データdataを使って転送領域に形成され る。カード自身はKGKDECを知っていて，端末装置から，ユーザデータdataと暗号 Cに加えて，端末識別子(Terminal ID)とPIXを受け取る（または，カード自身はP IXを知っている。これに関しては，転送命令TRANSFERの項を参照されたい。）こ れにより，カードは暗号C'をユーザデータを使って自身で計算できる。 mac(macp(macp(KGKDEC,PIX),TerminalID),data) =mac(macp(KGKDEC,PIX,TerminalID),data) =mac(KDEC,data) =C' ここでカードは自身で計算した暗号C'と端末装置が計算した暗号Cとを比較す る。これらが異なれば，誤り発生報告を出してトランザクションを終了する。一 致すれば，VASカードは転送命令TRANSFERを実行する。 各種機密保持基準は，サービス端末装置，ディーラ端末装置（ロード用および と獲得用），および単機能ディーラ端末装置（キャンセル用）の各種構成に適応 するものである。「キャンセル」動作を実行するためには，端末装置はカードに 対して，キーKDECの知識に よって自身を認証しなければならない。キーKDECが一致すれば，侵入者(端末使 用者)はこの単一の端末装置だけの機能を実行できる。しかし，この手続きはカ ード内に文書として記録される。文書は一意的にふられた連続番号，キャンセル および端末識別子を含む。VASアプリケーションは，VASデータへのアクセスを規 制するために，VASコンテナの機密保持サービスを利用する。VAS特有の機能の実 行は，アクセス権利の定義によって，権限を与えられたパートナ（パーティ）に 制限されている。 一般に，各VASアプリケーションに対して，公にアクセス可能なデータ領域（ 例えばワレットからの数値の読み出しのための領域）および対応する（責任を有 する）VASプロバイダのプライベート（私的）なデータ領域が存在しなければな らない。該プロバイダはこの私的領域（例えば，内部管理情報）を第三者に対し て保護する。 カードは，ISO 7816-4に従って，エレメンタリファイル(EF)の個々のレコード に対して各々異なったアクセス保護を提供していないので，VASアプリケーショ ンの異なった場所を表示するには，各々1個のレコードを含む多くのファイルを 使用する必要がある。 したがって，第６図に示すように，VASデータを４個のエレメンタリファイル に分類することにより，アプ リケーションクラス「点数記憶域（データベース）」，「チケット」，「資格証 明書」および「データメモリ（データベース）」に対して異なったアクセス保護 を実現できる。 ４個のエレメンタリファイルは以下のような内容を含み以下の保護が与えられ る。 表 ３ ファイルの概要 エレメンタリファイル（EF）のこの構造は全てのアプリケーションクラスに対 して，それぞれ区別された同一のアクセス権をサポートする。 さて，同様なアプリケーションクラスがまとめられその都度１個のインプレメ ンテーション（実施）クラスに組み立てられ，このインプレメンテーションクラ スがエレメンタリファイルの個数とサイズを決定する。このため，アプリケーシ ョンに対して各種領域が要求されるので，使用される記憶領域を小さくすること ができる。アプリケーションクラス「点数記憶域」と「チケット」は同じリソー スKF_KEY，EF_INFO，EF_INTERNALおよびEF_VALUEを必要とするので，インプレメ ンテーションクラス“DF PT”にまとめられる。アプリケーションクラス「資格 証明書」と「データメモリ」に関してはエレメンタリファイルEF_KEYとEF_INFO で足りるので，インプレメンテーションクラス“DF_AD”にまとめられる。個数 で見ると，インプレメンテーションクラスDF_PTのオブジェクトがp個とインプレ メンテーションクラスDF_ADのオブジェクトがa個となり，これらにアプリケーシ ョンクラス「点数記憶」と「チケット」ならびにアプリケーションクラス「資格 証明書」と「データメモリ」をロードすることができる。 特に，共有データ交換のために全てのVAS参加者に 対して公開読み取りアクセスを含まねばならないアプリケーションクラス「証書 」のために，インプレメンテーションクラス「転送領域」が使用される。書き込 みアクセスは，正しいKDECで署名が必要なTRANSFER命令を使用して間接的にのみ 可能である。このインプレメンテーションクラスは，VASコンテナのグローバル データに属するエレメンタリファイルEF_TRANSFER内のただ１個のエントリから 成る。このクラスのオブジェクトは上記ファイル内のレコードである。これらの インプレメンテーションクラスも“EF TRANSFER”と呼ぶ。 VASコンテ内には第７図に示すインプレメンテーションクラスがある。これら のインプレメンテーションクラスはVASコンテナのメモリモデルを形成する。 メモリモデルの作成には２方法がある。いずれを取るかはカードのプラットフ ォームに依存する。 −VASコンテナのための記憶領域の固定区分 インプレメンテーションクラスDF_PTとDF_ADに対して，それそれの最大オブジ ェクト数pとaが発行者によって決定され，発行者によってCREATE FILE命令を用 いてカードにロードされる。これらのオブジェクトをDF_PTiとDF_ADiで示す。後 に，VASアプリケーションは，空いているオブジェクト，すなわち他のVASアプリ ケーションによって占められていないオブジェク トにロードできる。ここで，VASアプリケーションのロードと消去にはUPDATE RE CORD命令のみが必要である。 つまり，発行者は必要に応じて，両インプレメンテーションクラスの使用可能 オブジェクトの個数を決定する。これは，カード所持者の実際のVASユーザーパ ターン（VASの使用のされ方）とは必ずしも一致しない。区分はカードの使用期 間を通じて保持される。VASアプリケーションは，適切なインプレメンテーショ ンクラスであるオブジェクトにロードされる。そうすると，実施クラスDF_ADの いずれのオブジェクトも（もはや）使用できない場合には，例えば，資格証明書 を表すVASアプリケーションをインプレメンテーションクラスDF_PＴのオブジェ クトにロードすることができる。VASアプリケーションのオブジェクトへの割り 当ては，VASコンテナのグローバルファイルEF_DIRにトリプレット（VASアプリケ ーションのPIX，ロードオブジェクトのFID，アプリケーションのクリアテキスト ネーム）をエントリすることで実行される。アプリケーションの除去はEF_DIRか らトリプレットを取り除くことに対応し，アプリケーションがロードされたメモ リの（UPDATE RECORD命令による）読み出しによってメモリを乱すこと（破壊的 読出し）に対応する。 このバリエーションは，DF／EF構造の動的生成も消 去もサポートしないカードプラットフォームで使用される。 −インプレメンテーションクラスのオブジエクトの動的設定 ロードされるべき各VASアプリケーションに対して，基礎となるインプレメン テーションクラスに必要なファイルは，CREATE FILE命令によってセットされる 。VASアプリケーションの消去時には，このアプリケーションが占めていたDF／E Fはカードから完全に取り除かれ，メモリ空間が開放される。インプレメンテー ションクラスの最大オブジェクト数はここでは発行者から明示的には決定されず ，カード内の使用可能メモリ空間にのみ依存する。 上記バリエーションはカードオペレーティングシステムによる動的データベー ス管理を必要とする。 次に示す実施例では，第１のバリエーションを前提にする。これは，第2バリ エーションでは使用するカードプラットフォームに対する要求が高いからである 。しかし，動的データベース管理が使用でき，オブジェクトの動的セッティング により節約できるメモリが管理費を考えても有利であることが保証された場合に は，この構想を取り入れることができ，柔軟性のあるサービスをカード所持者に 提供できる。 つぎに，VAS顧客カードのVASコンテナと機能性を， 他のシステム構成要素と比較して実施する，データ構造と命令を示す。さらに， VASコンテナと端末装置間のそれぞれのやりとりを示す典型的な商取引の場合に 対してVAS動作が決定される。 以下の初期条件で実施される。 ・ディーラ端末装置において，各カードは，プラットフォームに依存せず ，同一のデータインターフェースと同一の命令インターフェースを使用できる。 したがって，必要な命令は（カードの）コーディング内に明確に記述される。 ・サービス端末装置はカードプラットフォームを認識できる。ゆえに，機 能性はプラットフォームの特定命令によって得られる。したがって，この手続き は部分的にはインフォーマルに記述される。この機能がどのように提供されるか は，カード製造者に委ねられている。 これに関し，VASコンテナの各種インプレメンテーションクラスを図式的に第 ７図に示す。第８図はVASコンテナのインプレメンテーションクラスのデータ構 造を図式的に示すもの，第９図はインプレメンテーションクラスDF_PTのデータ 構造を図式的に示すもの，第10図は実施クラスDF_ADのデータ構造を図式的に示 すものである。 VASコンテナのファイルアクセスは以下のアクセス 条件(AC)によって明示的に制限される。 表 ４ アクセス条件 ファイルのアクセス条件は以下の通りである。 ・ALW(Always)=この命令のファイルアクセスは常に許される ・NEV(Never)=この命令のファイルアクセスは常に禁じられている ・KSO=アクセス前に，キーKSOを用いてシステムオペレータの外部認証をし なければならない ・KLVASP=アクセス前に，キーKLVASPを用いてVASプロバイダの外部認証を しなければならない ・KRVASP=アクセス前に，VASプロバイダが認可した端末装置をキーKRVASP を用いて外部認証をしなければならない ・PIN=アクセス前に，正しいPINがカード所持 者によって入力され，さらに，VERIFY命令を用いて暗号化しない平文でカードに 送信されなければならない ・PINまたはKRVASPまたはKSO=アクセス前に，正しいPINがカード所持者に よって入力されなければならない，または，ＫRVASPを使ってVASプロバイダによ って，もしくは，KSOを使ってシステムオペレータによって外部認証をしなけれ ばならない。 ここで注意すべきことは，上記のように，「または」で繋がった（Or-linking ）アクセス権利は，カードのオペレーティングシステムでは通常は設けられない 。そのような場合があれば，特別な実施費用が必要になる。（代替性：明示的に 固定された機密保持属性をもつ特別なREAD命令）。 エレメンタリファイルのレコード内のデータフィールドは次の形式に従って分 類される：ASCII，二進数，BCD，データ，フォーマットストリング。 データ要素タイプ「フォーマットストリング」は，VASデータをパックされた 形式で表す。この表現形式は端末装置においてカード所持者に表示可能である。 最適なデータ記憶域使用のために，平文と二進データとが合わされて，フォー マットマクロによって表示可能にされる。 VASコンテナの全てのエレメンタリファイル（EF）は，ISO 7816-4に従って， 固定長レコードのEFファイルとしてリニア形式にされる（リニア固定長レコード ファイル）。 DF_VASのエレメンタリファイルEF_IDは，VASコンテナIDを含む一個のレコード から成る。 DF_VASのエレメンタリファイルEF DIRはnrDIRレコードから成る。VASコンテナ にロードされた各VASアプリケーションに対して，EF_DIRのレコード内に，該ア プリケーションの占有IDエクステンション（PIX）と該アプリケーションの物理 記憶域（アプリケーションがロードされたDF_XのFID）が設定される。PIXは，例 えば識別子として，アプリケーションとアプリケーションが割り当てられたサー ビスプロバイダとを識別する。 EF_DIR内のエントリはシステムオペレータのサービス端末装置で動的にセット される。エントリ無しのレコードには空TLVオブジェクト“61”がセットされる 。 VASアプリケーションのロードにさいして，適当なインプレメンテーションク ラスの空き記憶領域がまずサーチされ，特定のVASデータが該領域に書き込まれ ，最後にEF_DIR内に新レコードが生成される。 アプリケーションの消去時には，これに対応して， EF_DIR内には空TLVオブジェクトが書き込まれなければならない。 DF_VASのエレメンタリファイルEF VERSIONはVASコンテナのバージョン番号を 含む１レコードから成る。 バージョン番号は，VASコンテナの各種バリエーション（モディフィケーショ ン）および／または各種ソフトウェアバージョンを区別するために端末装置で使 用できる。 DF_VASのエレメンタリファイルEF_SEQは次の転送フィールドエントリの番号を 含む１レコードから成る。 該連続番号は補助命令TRANSFERによって読み出される。この命令は続いて転送 フィールドEF_TRANSFER内に，特に，EF_SEQから連続番号を転送するレコードを 作製する。連続番号は命令TAKEと共に，各レコードが転送フィールドから一回だ け取り出されることを保証する。TAKEはさらに，この取り出したことを連続番号 を用いて署名付きで記録する。これによって，（元の）証書（バウチャ）ないし 領収書が一回だけ取り出されたことが保証される。 つぎに，転送領域について詳述する。 転送領域はVASコンテナ内部に設定され，nEF_TRANSFERレコードを含む。この ファイルのレコードのエントリは，TRANSFER命令が生成した転送データを含む。 転送領域を介して，VASアプリケーション間でデータ交換が 行なわれ，クラス「証書（バウチャ）」のVASデータが記憶される。 転送領域は制限なく読み出しが可能だが，書き込みアクセスはVASに特有な命 令TRANSFERとTAKEでのみ可能である。 TRANSFER命令によるデータフィールドのデータのロードは，カード内の「最新 使用」アルゴリズムに従って行われる。ファイル内の最古のデータは，レコード の先頭の２バイト内の最小値を探し出すことで検出できる。 データフィールドは，TAKE命令によって，「取り出された」および／または「 移動された」と転送領域内にマークできる。いずれの場合でも，転送領域内のデ ータの消去は新データを上書きすることで実行される。 転送領域内の各レコードは，例えば有効期限，端末ID，PIX，連続番号，他の オプションデータを含む。 リストDF_X（X＝PT1,..,PTp,AD1,...,ADa）内の各エレメンタリファイルEF_IN FOは，有効期限およびVASアプリケーションの一般VASデータから成る１レコード を含む。ここでは，例えばチケット種類（普通券または回数券）または乗車場所 を挙げることができる。しかし，EF_INFOは少なくとも１個のアプリケーション の平文名を含まねばならない。この平文名は「VAS アプリケーションの（監視（閲覧））」の動作のために読み出すことができる。 VASプロバイダは重要なデータを適当な外部キーアルゴリズムで保護しなければ ならない。 外部認証がKSOまたはKRVASPを使って行われるか，カード所持者がPIN保護がア クティブ状態の場合に正しいPINを入力したときには，このEFを読み出しできる 。 リストDF_X（X＝PT1,..,PTp,AD1,...,ADa）内の各エレメンタリファイルEF_IN TERNALは，該ファイルにロードされたVASアプリケーションを介してVASプロバイ ダの内部VASデータを含むことができる１レコードから成る。カード所持者も他 のVASプロバイダもこの内部データを読むことはできない。 リストDF_X（X＝PT1,..,PTp,AD1,...,ADa）内の各エレメンタリファイルEF_VA LUEは，VASデータの整数値フィールドを含むことのできるレコードから成る。外 部認証がKSOまたはＫRVASPを用いて行われるか，カード所持者がPIN保護がアク ティブ状態の場合に正しいpINを入力したとき，または正しいパスワードを入力 したときには，このEFを読み出しできる。 これらに続くキーフィールドはVASコンテナまたはVASアプリケーションによっ て使用できる。以下の説明では完全なDESコーディングを前提とする。すなわち ，VASコンテナの全てのキーはDESキーであり，８バイ トでコーディングされる（パリティビットを含む）。 VASコンテナおよびVASアプリケーション内では，KID（キー識別子，Key Ident ifier）を用いて以下のキーを参照できる。 表 ５ VASコンテナキー 各キーはエラーカウンと結ばれている。このカウンタは認証の失敗をこれらの キーと共に登録し，カウンタに入力されたリミットに達するとそれ以降の使用を 禁止する。 VASアプリケーション内では以下のキーをそれぞれのKIDを用いて参照できる。 表 ６ VASアプリケーションキー 各キーはエラーカウンタと結ばれている。このカウンタは認証の失敗をこれら のキーと共に登録し，カウンタに入力されたリミットに達するとそれ以降の使用 を禁止する。 VASコンテナは個人識別番号またはパスワード(PIN)を記憶する。これはVERIFY 命令でカード所持者の識別に使用される。PINはエラーカウンタと接続されてい る。このカウンタは誤入力を登録し，リミットに達するとpＩＮの比較処理を禁 止する。この禁止状態はシステムオペレータが適当な管理命令を用いてリセット できる。該カウンタは正しいPINの入力によってリセットされる。 VASコンテナに対して次のパラメータがある。これらは，カードプラットフォ ーム上の使用可能空間および発行者の個人的要望に従ってカード発行者によって 選択可能である。 ・p インプレメンテーションクラスDF_PTの最大 オブジェクト個数 ＝VASコンテナに同時にロード可能なアプリケーションクラス「点 数記憶」と「チケット」のVASアプリケーションの最大個数 ・a インプリメンテーションクラスDF ADの最大オブジェクト個 数 ＝VASコンテナに同時にロード可能なアプリケーションクラス「資 格証明書」と「データメモリ」とのVASアプリケーションの最大個数 ・nrDIR オブジェクトの最大整数：nrDIR＝p＋a EF_DIＲ内のレコード 数はnrDIRである ・nrEF_TRANSFER ET_TRANSFERのレコード数 上記のエレメンタリファイルのサイズに必要な記憶領域は次の通りである。 バイト数 VASコンテナの EF ID 4 グローバルデー EF_DIR 9*(p＋a) タ EF VERSION 1 EF_SEQ 2 グローバルキー 64＋2 ，PIN 転送フィールド ER_TRANSFER 48＋nrER_TRANSFER VASプロバイダ EF_KEY (p＋a)*32 の専有データ EF_INFO (p＋a)*62 EF_INTERNAL p*10 EF_VALUE p*3 パラメータp,aおよびnrEF_TRANSFERを例えば次の値に選べば，VASコンテナに 対して少なくとも以下のような記憶領域が必要になる（補助命令用記憶域は除く ）。 パラメータ 必要領域 p= 8，a= 3，nrEF_TRANSFER=15 2030バイト p=10，a= 5，nrEF_TRANSFER=20 2758バイト 最大必要領域は，最小必要領域のおよそ１０％増しとみられる。 つぎに，本発明によるチップカードの命令を詳述する。 READ RECORD命令はリニアエレメンタリファイルからデータを読み出すために 使用される。カードは応答として，レコードの内容を送る。EFはショートファイ ル識別子(SFI)によって参照される。 ステータスコード“9000”は命令が正常に実行されたことを示す。それ以外の コードはエラー発生を示す。 UPDATE RECORD命令はリニアエレメンタリファイル(EF)のレコードにデータを 記憶するために使用される。コマンドメッセージはEF，レコードおよびデータへ の参照を含む。 カードからの返答はステータスコードを含む。ステータスコード“9000”は命 令が正常に実行されたことを示す。それ以外のコードはエラーを示す。 GET CHALLENGE命令はカードから乱数を要求する。乱数はEXTERNAL AUTHENTICA TE命令において動的認証に関して使用される。 カードからの返答メッセージは８バイトの乱数とステータスコードを含む。ス テータスコード“9000”は命令が正常に実行されたことを示す。それ以外のコー ドはエラーを示す。 EXTRERNAL AUTHENTICATE命令はカードに対する端末装置の認証を許す。この命 令はVASアプリケーションの範囲内で，システムオペレータおよびVASプロバイダ の認証のために使用される。EXTERNAL AUTHENTICATEは暗号をカードに転送する 。この暗号は，端末装置によって事前に乱数をエンコードすることで生成されて いなければならない。カードはこの暗号を，自身が同一の方法で計算した参照値 と比較する。両者が一致すれば，カードはこのキーに対してアクセス条件の認証 が行われたことを内部に記録する。異なるときには，カードはステータス「認証 不可」を返送し，内部エラーカウンタをデクリメントする。カウンタの値がゼロ になると，以降のEXTERNAL AUTENTICATEの実行はいずれもステータス「認証禁止 」で拒絶される。 カードからの返答情報はステータスコードを含む。カードに関して命令および 端末装置での認証が正常に実行されれば，それはステータスコード“9000”で示 される。それ以外のコードはエラーを示す。 INTERNAL AUTHENTICATE命令はVASコンテナの信憑性を端末装置で検査するため に使用される。このために，カードは端末装置からの参照データを用いて暗号を 計算する。端末装置は自身で暗号を生成し，カードからの値と比較する。これら が一致すれば端末装置はVASコンテナの信憑性を認める。 命令実行に対するカードからの返答は暗号と該命令の実行に対するステータス コードを含む。命令が正常に実行されたことはステータスコード“9000”で示さ れる。それ以外のコードはエラーを示す。 VERIFY命令はカード所持者のPINの検証に使用される。この命令はエンコード されていないPINデータをカードに送る。カードはPINデータを記憶してある参照 値と比較する。入力データと記憶してあった値が等しければ，アクセス条件「PI N」は満足されとみなされる。 命令実行に対するカードからの返答情報はステータスコードを含む。ステータ スコード“9000”は命令が正常に実行されたことを示す。それ以外のコードはエ ラーを示す。 TRANSFER命令は転送（記憶）領域にエントリを生成する。この命令には３種類 の動作モードが定義される。 １．クラス「チケット」または「点数記憶」のアプリケーションのEF_VAL UEフィールド内の数値を減算することによって，転送領域にエントリを作る。 ２．クラス「資格証明書」のアプリケーション内に領収書を作成すること によって，転送領域にエントリを作る。 ３．クラス「証書」のアプリケーション内に証書を作成することにより， 転送領域にエントリを作る。 このモードはカードによって自動的に選択される。すなわち，選択されたアプ リケーションDF内で命令が実行されれば，まずEF_VALUEがあるかないかのチェッ クがなされる。EF_VALUEがあればカードはモード１で命令を実行し，なければモ ード２で命令を実行する。VASコンテナ内でアプリケーションDFが選択されなけ れば，モード３が使用される。 端末装置はTRANSFER命令の呼び出し時に以下のデータをカードに供給する。 ・最新データ ・転送フィールド（領域）内のエントリのための 有効期限日付 ・該エントリを生成した端末装置のためのID ・転送フィールドのためのユーザデータ ・VASアプリケーションのPIX（モード３のみ） ・減算の減数の数値単位（モード１のみ） ・上記データに関するMAC，連続番号およびVASコンテナ番号。 カードはTRANSFER命令の呼び出し時に以下のシーケンスを実行する。 １．転送領域内に空きのエントリを探す。（既存のエントリに上書きする ときには，以下のリストのプライオリティの降番順に行う。すなわち，「移動済 みのエントリ」，「取り出されたエントリ」および「有効期限満了」，「有効期 限満了」。 ２．モード１とモード２の端末装置からのデータにPIXを付ける。 ３．ステップ２からのデータに連続番号を付ける。 ４．ステップ３からのデータにVASコンテナIDを付ける。 ５．KGKDECを使い，PIXをエンコードしてKGKDEC,PIXを生成する。 ６．KGKDEC,PIXを使い，端末IDをエンコードしてKDEC を生成する。 ７．ステップ４からのデータを用いてMACを作成する。 ８．ステップ７のMACを端末装置からのMACと比較する。両者が異なれば， カードはこの機能を中止し，KGKDECに対するエラーカウンタを減算する。 ９．モード１：アプリケーションがロードされたレジスタ内の数値フィー ルドEF_VALUEをチェックする。このフィールドの数値が充分でなければ，カード は直ちにこの機能を中止する。充分であれば，アプリケーション内の数値フィー ルドからこの数値を減算する。 10．命令情報を作成する。 11．EF_SEQの内容に１だけインクリメントする。 したがって，応答内のデータセットの表示は不要である。さらに，レコード数 は既知であると仮定してよい。 TAKE命令は以下のモードを提供する。 ・データを移動し，同時にデータが無効になったことを記録する。 ・データを移動するが，データが無効になったことは記録しない。データ はさらに有効に保たれる。 命令メッセージは端末IDと，アプリケーションのPIXと端末装置が生成した乱 数とのフィールドを含む。 命令内のPIXはデータを移動したアプリケーションを示す。これは，移動され たデータセットのPIXと異なってよい。このPIXはデータを移動したディーラ端末 のKDECの生成にのみ使用される。 カードの応答メッセージは，転送領域の命令メッセージ内に与えられたレコー ドに関するKSIG_VASCを有する暗号C1，VASコンテナID，C1を使用してデータを移 動した端末装置のKDECを有する暗号C2および命令メッセージからの乱数を含む。 応答メッセージはさらにステータスコードを含む。キーKDECは上述のように生成 される。暗号とKDECを用いて，VASコンテナによって信憑性が暗示的に証明され る。暗号Cによって，信憑性証明と唯一性証明が計算される（Cは，連続番号，転 送フィールドのレコードの移動されたビットおよびVASコンテナIDから形成され ているからである）。この証明はシステムオペレータによって検証可能である。 ステータスコード“9000”は命令が正常に実行されたことを示す。それ以外の コードはエラーの場合を示す。 ここで，SOがIS0/IEC 7816-5によるAIDVASを要求するとする。詳しくは，VAS システムのために５バイト長のRIDVASを要求するとする。 リストDF_VASのAIDVASは，AIDVAS＝RIDVASPIXDF_VASで表されるとする。 命令メッセージは，例えば，有効期限，端末ID，トランザクションデータ，動 作モード用フィールド（例えばモード３でPIX）および暗号を含む各フィールド から成る。 暗号はキーKDECを用いて計算される。このさい，MAC形成に使用するデータは ，例えばトランザクションデータおよび端末IDを含む。 TRANSFER命令の応答メッセージは，正常な実行時には，８バイト長のデータフ ィールドと２バイト長のステータスコード“9000”を含む。これ以外ステータス コードをもつ応答メッセージはエラーの場合とみなされる。応答メッセージのデ ータフィールドはエラーのない場合には（つまり，特に，命令メッセージの暗号 が正しいときには），命令メッセージのKDECでエンコードされた暗号を含む。こ れにより，VASコンテナによって暗示的に（KAUTによる内部認証の代わりに）信 憑性証明がなされる。 TAKE命令はインプレメンテーションクラスEF_TRANSFERからオブジェクトを取 り出すのに使用される。TAKE命令の実行は，技術的には，ファイルEF_TRANSFER から提供すべきレコードを読み出すことである。ここで，レコードは新エントリ のための充分な記憶域がある 限りファイル内に保持されるが，このレコード（データセット）は「取り出し済 み」とマークされる。技術的には，TAKE命令はデータセットを取り出すために誰 でも使用できるが，規則と規定（R&R）によれば，データセットが特定されてい るVASプロバイダのみが使用すべきである。 データ取り出し手続きに関し，次の事項を想定できる。証書または領収書を取 り出したいVASプロバイダは転送領域内で適当なデータセットを探す（例えば，S EEK命令を使ってまたは各レコードを明示的に読み出して探す）。いずれの場合 でも，データセットは読み出されて，その内容がチェックされる。 規則と規定（R&R）によれば，各VASアプリケーションAに対して３バイト長のP IXAが与えられ，これにより，VASコンテナ内でAIDA＝ＲIDVAS PIXAでVASアプリ ケーションを一意的に識別できる。DF_VASの選択後，VASアプリケーションAが含 まれたリストをSELECT FILE＜PIXA＞で選択できる。 UPDATE KEY（KID，K）はカードプラットフォームに依存する命令を示す。これ により，キー識別子IDを使って，あるキーを新しい値Kに置換できる。 ディーラ端末装置のカード所持者が，インプレメンテーションクラスDF_PTま たはDF_AD（アプリケーションクラス「点数記憶」，「チケット」，「資格証明 書」 または「データメモリもしくはデータベース」に対応する）からのVASアプリケ ーションを使用できるようになる前に，VASアプリケーションは担当VASプロバイ ダのサービス端末装置でVASコンテナにロードされなければならない。原理的に は，VASプロバイダおよびSOからの指示を受けたカード発行者が，VASコンテナの 設置時点において，すでに１個ないし複数個のVASアプリケーションをVASコンテ ナにロードすることも可能である。このロード手続きはここで説明する手続きの 特別なケースである。 VASアプリケーションロード経過 １．カード所持者はVASカードをサービス端末装置に挿入する。 ２．サービス端末装置はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが 報告される）。 ・READ RECORD<EF_IDのSFI,O>（VASコンテナ番号の表示）。 オプションとして，VASコンテナの有効性のチェックができる。こ のために，サービス端末装置はVASコンテナの内部認証を要求する。 ・INTERNAL AUTHENTICATE<乱数,KAUTのKID>サービス端末装置は返 答をチェックしエラー （エラー表示付き）であれば手続きを中止する。 ３．サービス端末装置はカード所持者に複数のオプションを選択可能にする。そ のひとつに，「VASアプリケーションのロード」がある。カード所持者がこれを 選択する。すると，サービス端末装置において，ロードされ得るすべてのVASア プリケーションがカード所持者に表示され，選択を待つ。このために，動作「VA Sアプリケーションの監視（閲覧）」が起動される。カード所持者はインプレメ ンテーションクラスDF_pTまたはDF_ADのVASアプリケーションAを選択する。 ４．サービス端末装置は動作「VASアプリケーションの選択」によってVASコンテ ナを調べ，選択されたPIXAをもつVASアプリケーションが既にカード内にロード されているか決定する。存在すれば，エラー信号が表示される。存在しなければ ，Aに適切なインプレメンテーションクラスのオブジェクトがVASコンテナ内で利 用可能かどうかがチェックされる。これは，EF_DIR内の使用可能レコードを（例 えばSEEK命令で）探すことで実行される。使用可能レコードがなけければ，エラ ー報告がなされる。利用可能レ コードがあれば，このレコードはVASアプリケーションがロードされていないDF_ XのFIDDF_Xを含む。 ５．Aに適切なインプレメンテーションクラスの次に使用可能なオブジェクトにV ASアプリケーションAがロードされる。このために，サービス端末装置は先ずオ フラインで，VASプロバイダ（例えばプロバイダSAM）から２個のキーKLVASpとＫRVASP を要求し，それらのキーを新しいVASアプリケーションに割り当てる。 ・SELECT FILE<FIDDF X> ・GET CHALLENGE ・EXTERNAL AUTHENTICATE<KSO(乱数),KSOのKID> ・UPDATE KEY<KLVASP,KLVASPのKID> ・UPDATE KEY<KRVASP,KRVASPのKID> ・GET CHALLENGE ・EXTERNAL AUTHENTICATE<KLVASP(乱数),KLVASPのKID＞ ・UPDATE RECORD<DF_XのEF_INFOのSFI,データ> ・UPDATE RECORD<DF XのEF INTERNALのSFI,データ ＞ ・Optional(イニシャル署名):UPDATE RECORD <DF_XのEF_VALUEのSFI，データ> ６．EF内への書き込みが正常に終了した後，サービス端末装置は動作「VAS アプリケーション<PIXA,FIDDF_X>の入力」を実行する。このアプリケーションは DF_XをＰIXAに結びつけ，これで（SELECT FILE AIDVASによる事前選択後）PIXA を使ってSELECT FILEが可能になる。 転送領域によって使用可能になったこの機構は，例えば，占有のDF構造なしで イントラサービスまたはインターサービスを実行したいVASプロバイダによって 使用できる。なお，カード所持者は特にVASアプリケーションを使用する前に， サービス端末装置にこのアプリケーションを，この時初めてロードする必要はな い。それどころか，カード所持者は証書または領収書を直接ディーラ端末装置で 発行でき，これを他の端末装置で（取り出し操作で）払い戻しさせたり，または ，証書または領収書を（読み取りを操作して）単に提示することができる。した がって，インプレメンテーションクラスET TRANSFERのVASアプリケーションのロ ードはVASデータを暗示的に入力することで実行されるか，または，そのような 操作（VASデータの入力）によってなされる。これに関して，後述するインプレ メンテーションクラスET_TRANSFERの「獲得」の説明を参照されたい。 以下に，VASアプリケーションのエントリ動作の経過を説明する。 VASアプリケーションがVASコンテナにロードされたときには，該アプリケーシ ョンがどのDF_X(X＝PT1,..,PTp,AD1,...,ADa)にロードされたのか，または本当 にロードされたのかという，物理的な位置は端末装置には分からない。カード製 造者から見ると，別々にチェック可能な２個の実施方法が考えられる。なお，ZK A（中央カード委員会）基準に準拠することは，特に遵守されねばならない。 第１ケース：EF_DIRへのアクセスが可能。 以下の条件を満足する必要がある。 ・AIDがDF_XのFIDに割り当てられている（たとえばDF_VASのもとにある） EF_DIRが，基準通りにカードプラットフォームにある。上記DF_XにはVASアプリ ケーションが現に存在する。 ・このDF_Xは誰からも読み出し可能である（READ RECORDのAC：ALW）。 ・PIXAをもつVASアプリケーションＡがシステムオペレータによって空い ている（使用されていない）DF_Xにロードされると，すなわち，現にあるエレメ ンタリファイルDF_Xにエントリが書き込まれると（CREATE FILE（ファイル作成 ）ではない!），UPDATE RECORDによってファイルEF _DIＲはエントリPIXAだけ拡張される。UPDATE RECORDがFIDXを使ってDF_Xを参 照しているからである。したがって，UPDATE RECORDのACはキーKSOによる外部 認証を要求する。 ・DF_VASが既に選択された後に，命令SELECT FILＥ<PIXA>がカードに転送されると ，VASアプリケーションAがロードされているDF_Xは直接選択可能でなる筈である 。 ・DF_Xとそれに続くエレメンタリファイルにロードされたVASアプリケーションA がカード所持者の要求でサービス端末装置で消去されなければならないときには ，対応ファイルはDELETE FILEで消去されるのでなく，書き込まれたデータがダ ミー値で上書きされるだけである。その後，EF_DIRからPIXA（厳密には，PIXAと DF_Xへの参照のペア）を（例えば，キーKSOによる外部認証後にUPDATE RECORDで ）消去することができる。 ・DF_Xの個数は固定であるので，EF_DIRのレコードの個数が分かる。 これらのアプローチが実現できれば，以下の結果となる。 ・DF_VASの選択後，SELECT FILE PIXAを使って直ちにVASアプリケーションの選 択ができる。 第２ケース：EF_DIRへのアクセスが不可能。 カードプラットフォームに使用可能なEF_DIRがないか，または，上記のように 読み取りアクセスも書き込みアクセスもEF_DIRにできない場合には，DF_VASのも とにファイルEF_VASDIRが存在せねばならない。EF_VASDIR内には，システムオペ レータによって（Ksoによる外部認証後に）明示的なUPDATE RECORD命令を使用し て，PIXAをロードしたVASアプリケーションからDF_X内の物理的記憶領域へのリ ンクが生成される。EF_VASDIRからのレコードの読み取りや消去は上述のように 可能であるものとする。 動作「VASアプリケーションのエントリ」は以下のように行われる。 PIXAをもつVASアプリケーションAは事前にFIDDF_XをもつDF_X内にロドされる 。FIDDF_Xのレコード数はサービス端末装置に記録されている。 １.SELECT FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが報告さ れる）。 ２.GET CHALLENGE ３.EXTERNAL AUTHENTICATE<KSO（乱数）,KSOのKID> ４.UPDATE RECORD<DF_VASのEF_DIRのSFI，FIDDF_x,PIXA,FIDDF_Xとともに数 値の記録> インプリメンテーションクラスDF PTまたはDF ADのVASアプリケーションは， カード保持者の要求に応じて（システムオペレータの制御下の）サービス端末装 置でのみ消去できる。インプレメンテーションクラスEF_TRANSFERのVASアプリケ ーションはどこでも誰でも消去できる。消去においては，インプレメンテーショ ンクラスDF_PTおよびDF ADのVASアプリケーションとインプレメンテーションク ラスEF TRANSFERのVASアプリケーションを区別せねばならない。 上記の実施クラスDF_PTまたはDF_ADのVASアプリケーションの消去経過 １．カード所持者はVASカードをサービス端末装置に挿入する。 ２．サービス端末装置はVASコンテナがあるかを調べる。 ・SELECT_FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが報告さ れる）。 ・READ REC0RD<EF_ID>（VASコンテナIDの表示） ３．サービス端末装置はカード所持者に複数のオプションを選択可能にし ている。そのひとつに，「VASアプリケーションの消去」がある。カード所持者 がこれを選択する。すると，VASコンテナにロードされたすべてのインプレメン テ ーションクラスのすべてのVASアプリケーションがカード所持者に表示され，選 択を待つ。このために，動作「VASアプリケーションの監視（閲覧）」が起動さ れる。カード所持者はAIDAでインプレメンテーションクラスDF PTまたはDF_ADの VASアプリケーションAを選択する。VASアプリケーションがロードされたオブジ ェクトをDF_Aと呼ぶ。 ４．DF_Aの選択後，サービス端末装置の認証が行われる。 ・SELECT FILE<PIXA> ・GET CHALLENGE ・EXTERNAL AUTHENTICATE <KSO(乱数),KSOのKID> ５．これでDF_Aからファイルの内容が消去される（EF_KEY,EF_INTERNALおよびEF _VALUEにはKLVASPが必要であるので，これらはシステムオペレータによって始め に消去される）。 ・UPDATE KEY < KLVASPのKID，“00...00”> ・UPDATE KEY<KRVASPのKID，“00...00”> ・GET CHALLENGE ・EXTERNAL AUTHENTICATE <KLVAS(乱数),KLVASのKID> ・UPDATE RECORD<DF_AのEF_INFOのSFI,“00． ..00”> ・UPDATE RECORD<DF_AのEF_INTERNALのSFI，“00...00”> ・UPDATE RECORD<DF_AのEF_VALUEのSFI，“00...00”> ６．EF内への書き込みが正常に終わると，続いて端末装置はEF_DIRからVA Sアプリケーションのエントリを消去する。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが報 告される） ・UPDATE RECORD<DF_VASのEF_DIR_のSFI,FIDDF_Aとともに数値の記録 ，“00...00”,FIDDF_A> PIXAのDF_Aへのリンクはこうして解除されるので，PIXAを使ってSELECT FILE を実行することはもはやできない。 つぎに，インプレメンテーションクラスEF_TRANSFERを説明する。 インプレメンテーションクラスEF TRANSFERのVASアプリケーションはカード所 有者の要求に応じて，規則と規定（R&R）に従ってディーラ端末装置またはサー ビス端末装置で消去される（但し，技術的にはどちらの端末装置でも可能である ）。EF_TRANSFERからオブジェクトを消去することは，新しいオブジェクト（例 えば証書または領収書）を記憶するのに転送領域に空 いた場所がないときに特に必要になる。この消去は，補助命令TAKEを介して常に 間接的に行われる。この命令は，オブジェクトに対して「移動済み」とマークす るだけである。したがって，後に続く補助命令TRANSFERによって上書きが可能で ある。 VASアプリケーション消去の経過 １．カード所持者はVASカードを端末装置に挿入する。この端末はEF_TRAN SFERの内容を表示できる（動作「VASアプリケーションの監視（閲覧）」の特殊 ケース）。 ２．端末はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが報 告される） ・READ RECORD<EF_IDのSFI,0>（VASコンテナIDの表示）。 ３．サービス端末装置はカード所持者に複数のオプションを選択可能にし ている。そのひとつに，「VASアプリケーションの消去」がある。カード所持者 がこれを選択する。すると，少なくとも，インプレメンテーションクラスEF_TRA NSFERのすべてのVASアプリケーションがカード所持者に表示され，選択を待つ。 これは，動作「VASアプリケーションの監視（閲覧）」の特殊ケースとして実現 される。カード所持者は証書 または領収書を含むインプレメンテーションクラスEF_TRANSFERのオブジェクト を選択する。このオブジェクトはレコード番号Ａを有する。カード所持者は選択 を実行する。 ４．端末装置はレコード番号Aのレコードを「取り出し済み」とマークす る。すなわち，端末装置はA，自身で計算した乱数，PIXおよび端末IDをTAKE命令 で転送する。 ・TAKE<A,乱数,PIX,端末ID> これで，「取り出し済み」とマークされたレコードが，新しい証書または領収 書受け取りのために再び使用可能になる。 以下に，VASアプリケーション選択の経過を説明する。 インプレメンテーションクラスDF PTまたはDF ADのVASアプリケーションAが， 動作「VASアプリケーションのロード」によってVASコンテナにロードされると， このアプリケーションは端末装置によって２ステップで選択できる。VASコンテ ナがまず選択される。続いてPIXAを含むVASアプリケーションが選択される。 １．SELECT FILE<AIDVAS>（VASコンテナが選択できない時にはエラーが報 告される） サービス端末装置はVASコンテナの信憑性を 検査できる。このために，サービス端末装置はVASコンテナの内部認証を要求す る。 ・READ REC0RD<EF_IDのSFI,0>（VASコンテナIDの表示) ・INTERNAL AUTHENTICATE<乱数,KAUTのKID> サービス端末装置は応答をチェックしエラーであれば（エラー表示をもって） 処理を中止する。 ２．SELECT FILE<PIXA>（VASコンテナにVASアプリケーションAがロードさ れていなければエラーが報告される）。 ディーラ端末装置（KGKAUTは使用できない）はVASアプリケーションAの信憑性 検査をして，間接的にVASコンテナの信憑性を確認できる。その理由は，VASアプ リケーションは，ロード手続き中にVASコンテナの信憑性を検査したサービス端 末装置にのみロード可能だからである。VASアプリケーションAの信憑性検査は， VASコンテナがVASアプリケーションAのためのキーKLVASPまたはKRVASPを持って いるかをディーラ端末装置でテストすることに帰すことができる。これは，例え ばディーラ端末装置で次のように検査できる。 ・INTERNAL AUTHENTICATE <乱数,KRVASPまたはKLVASPのKID> VASコンテナ内にVASアプリケーションAがロードされているかのテストは，試 しに選択することで行える 。SELECT FILEの応答メッセージ（表示）のエラー報告により，アプリケーショ ンAが存在しないことが結論できる。 インプレメンテーションクラスEF TRANSFERのVASアプリケーションの選択は， 動作「VASアプリケーションの監視（閲覧）」およびデータの端末装置への記憶 によって暗示的に行われる。端末装置は表示された各オブジェクトのレコード番 号をEF_TRANSFERから知ることができるので，該レコード番号を参照することで ，以降の処理のために（レコード番号毎に）任意のオブジェクトを選択できる。 つぎに，VASアプリケーション監視（閲覧）の経過を説明する。 動作「VASアプリケーションの監視（閲覧）」は，インプレメンテーションク ラスDF_PT，DF_AD EF_TRANSFERの全VASアプリケーションをサービス端末装置に リストとして表示する。ディーラ端末装置ではインプレメンテーションクラスEF TRANSFERのVASアプリケーションのみしか表示できない。これらのアプリケーシ ョンにはアクセス保護がないからである。また，ディーラ端末装置が読み出し権 を持つ（KRVASPを所有）インプレメンテーションクラスDF PTとDF ADのアプリケ ーションもオプションとして表示できる。 上記VASアプリケーションの経過 １．カード所有者はVASカード（有効なVASコンテナを持つチップカード）を端末 装置に挿入する。 ２．サービス端末装置はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが報告され る）。 ・READ REC0RD<EF_IDのSFI,0>（VASコンテナIDの表示） VASコンテナの有効性をオプションで検査できる。このために，サービス端末 装置はVASコンテナの内部認証を要求する。 ・INTERNAL AUTHENTICATE<乱数，KAUTのKID>サービス端末装置は応答をチェ ックしエラーであれば（エラー表示を持って）処理を中止する。 ３．サービス端末装置はカード所持者に複数のオプションを選択可能にしている 。そのひとつに，「VASアプリケーションの監視（閲覧）」がある。カード所持 者はこれを選択する。 ４．サービス端末装置は自身の認証をする。 ・GET CHALLENGE ・EXTERNAL AUTHENTICATE <KSO(乱数)，KSOのKID> ５．インプレメンテーションクラスDF PTとDF AD のVASアプリケーションに対して，EF_DIRの内容によって個々のVASアプリケーシ ョンが連続的に選択され制御される。キーKSOによる外部認証後，個々のEF_INFO （または規則と規定によりその一部）およびEF_VALUEの内容が表示される。 ・ｉ=０, ... nrDIR-1の場合 ・ READ RECORD＜ＥF_DIRのSFI,i〉 対応するDFにVASアプリケーションがロードされていなければ，応答 メッセージのPIXAは“00..00”であると表示される。EF_DIRからのREAD RECORD の代わりに，場合によっては，SEEK命令を使用できる。 ・ PIXAが“00..00”ででない場合 ・ＳＥＬＥＣＴＦＩＬＥ＜ＰＩＸ。＞ ・READ REC0RD<EF_INFOのSFI,0〉 ・応答メッセージ（場合によっては一部）の表示 ・READ RECORD<EF_VALUEのSFI,0> ・SELECT FILE<AIDVAS> ６．インプレメンテーションクラスEF TRANSFERのVASアプリケーションに対して ，各レコードのＥF_TRANSFERの内容（または規則と規定によりEF_TRANSFERの一 部）が読み出される。 ・ＳELECT FILE<AIDVAS> ・i=０, ... nrEF_TRANSFER-1の場合 ・READ RECORD<EF_TRANSFERのSFI,i> （応答メッセージはEF_TRANSFERのi番目のレコードの内容を含む） ・内容がゼロでなければ，内容が解釈され（例えば取り出された状態また は期限切れ状態）表示される。 ディーラ端末装置が読み取り権を持つ（KRVASPを所有）インプレメンテーショ ンクラスDF_PTとDF_ADのアプリケーションの監視（閲覧）は，上記のように，２ 個の異なるケースがある。外部認証のためには，システムオペレータのみが使用 できるKSOに代えて，キーKRVASPが使われる。ディーラ端末装置がKAUTを使用で きないにもかかわらず，VASアプリケーションの信憑性を検査したいときは，デ ィーラ端末装置は内部認証の代わりに（少なくとも１個の）VASアプリケーショ ンの認証を要求できる。これは，上記のように，カードが対応するキーKRVASPま たはKLVASPを知っていることで行われる。 インプレメンテーションクラスEF_TRANSFERのVASアプリケーションに対して， 上記のように，各レコードのEF_TRANSFERの内容（または規則と規定によりEF_TR ANSFERの一部）が連続的にリストされる。 動作「VASアプリケーションの解釈」も同様に実行される。このために，端末 装置はカード所持者に動作 「VASアプリケーション解釈」を選べるようにしている。動作「監視（閲覧）」 で表示されたデータに加えて，VASプロバイダによる解釈が必要なEF_INFOやEF_V ALUEからの（例えば外部でエンコードされたデータのような）データおよびEF_I NTERNALからの（例えばマイルスアンドモア（Miles & More）の過去何年かのマ イル数のような）データも表示できる。しかし，これは，端末装置のVASプロバ イダが（自身の判断で）適当なキーを使用可能にしたVASアプリケーションのみ に対して可能である。アプリケーションのEF INTERNALの読み取りためには（外 部認証用）キーKLVASPが必要である。エレメンタリファイルEF INFOやEF VALUE および転送領域EF_TRANSFER内にある外部でエンコードされたデータに対しては ，VASプロバイダの対応するキーが必要である。端末プログラムは，データ解釈 用のアプリケーションキーが使用できる，選択されたVASアプリケーションを，P IXを用いて容易に決定できる。 動作「VASアプリケーションの転送」はサービス端末装置において，転送元カ ードの全てまたは選択されたVAS動作（オペレーション）を転送先カードへ転送 することである。このさいの条件は，転送先カードのVASコンテナはVASアプリケ ーションを含まないことと，転送後には転送元カードの全てのVASアプリケーシ ョンは消去されることである。両条件とも，動作「VASアプリケーションの消去 」を連続して適用することで達成される。さらに，両カードの信憑性が検査され ねばならないし，転送先カードには充分な記憶領域がなけれはならない。転送動 作自身は，本質的には動作「VASアプリケーションの監視（閲覧）」を拡張した ものと動作「VASアプリケーションのロード」の繰り返し適用とを基礎としてい る。上記監視（閲覧）動作ではEF_INTERNALからのデータとキーKLVASPとKRVASP がさらに読み出される。 VASデータと共に，VASコンテナIDも転送先（ターゲット）カードに転送される ので，転送先カードのVASアプリケーションは転送元（ソース）カード上と同じ ように動作できる。これは，VASプロバイダによって生成されたキーはVASコンテ ナIDによってサポートされていて，それらのキーがそのまま変更なくコピーされ るからである。さらに，プロバイダは，通常はVASカードをVASコンテナIDによっ て識別するので，バックグラウンドシステムでの経理処理をそのままに保持しよ うとする。VASコンテナIDの転送において必ず遵守すべきことは，この全システ ム内でただひとつの番号を転送元カードから消去することである。 エレメンタリファイルEF_INTERNALおよびキーKLVASPとKRVASPを特別に読み出 せるようにするために，サービ ス端末装置は，キーKSOによる外部認証（動作「VASアプリケーションの消去」と 同様）の後に，まずキーKLVASPを上書きし，つぎにキーKLVASPによる認証を新た に行った後にEF_INTERNALからのデータを転送（上書き）できる。 インプレメンテーションクラスDF PTとDF ADのVASアプリケーションに加えて ，ファイルEF_TRANSFERも転送（上書き）されねばならない。このためには，動 作「移動（取り出し）」を連続的に実行して，これらの実施クラスのまだ「取り 出し済み」または「期限切れ」とマークされていないオブジェクトを移動する。 該オブジェクトの署名をKSIG_VASCを用いて検査し，該オブジェクトを転送先カ ードのEF_TRANSFERに転送する。しかし，転送先カード上ではこれらのオブジェ クトは「取り出し済み」とは記されていないので，引き続き有効な状態である。 最後に，VASコンテナのグローバルデータを転送しなくてはならない。特に， 転送先カードのシーケンスカウンタを転送元の値にセットせねばならない。 つぎに，VASデータの入力手続きを説明する。 ディーラ端末装置でのVASデータの入力には，VASアプリケーションの種類に応 じて，３種類の場合が可能である。 最初に，実施クラスDF_PTとDF_ADの場合の「獲得 」を説明する。 VASプロバイダは，インプレメンテーションクラスDF_PTとDF_ADのVASアプリケ ーションにデータを書き込む。 VASデータの入力経過 １．カード所持者はVASカードをディーラ端末装置に挿入する。 ２．ディーラ端末装置はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択できない時にはエラーが報告 される）。 ・READ RECORD<EF_IDのSFI,0>（VASコンテナIDの表示）。 ３．VASコンテナの信憑性が検査される。ディーラ端末装置自身がマスタ キーKGKAUTを持っていれば，このディーラ端末装置はVASコンテナの内部認証を 要求できる。 ・INTERNAL AUTHENTICATE <乱数,KAUTのKID> （KGKAUTを持っていない）ディーラ端末装置は，VASアプリケーションAの 信憑性を介して間接的にVASコンテナの信憑性を検査できる。その理由は，VASア プリケーションは，ロード中にVASコンテナの信憑性を検査したサービス端末装 置にのみロー ドできるからである。VASアプリケーションAの信憑性検査は，VASコンテナがVAS アプリケーションAに対するキーKLVASPとKRVASPを含むかをディーラ端末装置で テストすることに帰する。これはディーラ端末装置で例えば以下のようにチエッ クできる。 ・SELECT FILE<PIXA>（VASアプリケーションAがVASコンテナにロードされていな い場合にはエラーが報告される）。 ・INTERNAL AUTHENTICATE <乱数,KRVASPまたはKLVASPのKID> ディーラ端末装置は応答をチェックしエラー（エラー報告あり）であれば処理 を中断する。 ４．ディーラ端末装置はVASアプリケーションAを選択し，自身を認証し，トラン ザクションの実行に必要なエレメンタリファイルを記述する。 ・SELECT FILE<PIXA>（ステップ３で既に実行済みならばスキップする） ・GET CHALLENGE ・EXTERNAL AUTHENTICATE <KLVASP(乱数)，KLVASPのKID> ・オプション:UPDATE RECORD<DF XのEF INFOのSFI，データ> ・オプション:UPDATE RECORD<DF XのEF INTERN ALのSFI，データ> ・オプション:UPDATE RECORD<DF XのEF VALUEのSFI，データ> つぎに，インプレメンテーションクラスEF_TRANSFERの場合の「獲得」につい て説明する。 特に，インプレメンテーションクラスEF_TRANSFERのVASアプリケーション（ア プリケーションクラス「証書」）に対しては，VASプロバイダは自身のアプリケ ーションのための占有ファイル構造DF_Xを確保する必要がない。その結果，カー ド所持者はVASアプリケーションの証書を使用する前に，VASアプリケーションを ロードするためにサービス端末装置の前に行く必要はない。ただ，カード所持者 はディーラ端末装置から証書または領収書を直接発行し，それを他の端末装置で （動作「取り出し」で）払い戻し（弁済）するか，または，証書または領収書を （読み出しで）単に提示できる。VASデータの入力によって，インプレメンテー ションクラスEF TRANSFERのVASアプリケーションが暗示的にロードされる。これ らのアプリケーションクラスに対して，タイプレコードの個々のオブジェクトか ら成るインプレメンテーションクラスEF TRANSFERが存在する。EF_TRANSFERのエ ントリはTRANSFER命令によってのみ可能である。このためには，ディーラ端末装 置は有効な取り出しキーKDECを所有し，VASアプリケーションAのPIXAを使用でき なければならない。 VASデータの入力経過 １．カード所持者はVASカードをディーラ端末装置に挿入する。 ２．ディーラ端末装置はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能な時にはエラーが報告 される） ・READ RECORD<EF_IDのSFI,0>（VASコンテナIDの表示） ３．ディーラ端末装置は連続番号を読み出す。この番号は，さらに，ステ ップ４からMACに代入される。 ・READ RECORD<EF_SEQのSFI,0〉（連続番号の表示） ４．TRANSFER命令によって１レコードがEF_TRANSFERに書き込まれる。 ・TRANSFER<トランザクションデータ,有効期限,生成コード,データ,PIXA, KDECを持つMAC> ５．ディーラ端末は，TRANSFER命令の応答メッセージを調べることで，VA Sコンテナが正しいかどうかを（すなわち，共通秘密キーKDECを所持しているか を）検査できる。これに関し，既に説明したTRANSFER命令の応答メッセージを参 照されたい。 最後に，VASデータのキャンセルによる獲得を説明する。 VASプロバイダは，TRANSFER命令を使用してキャンセル（キャンセル）によっ て，権利（証書または領収書）を転送領域EF_TRANSFER内に作成できる。この証 書または領収書は，他のVASプロバイダによってもさらに使用され得る。データ はキャンセルを実行するVASプロバイダによってVASアプリケーションAのEF VALU EまたはEF_INFOからキャンセルされる。カード所持者はEF_TRANSFER内にオブジ ェクトの形式でこの権利を獲得する。 VASデータエントリ（入力）の経過 １．カード所持者はVASカードをディーラ端末装置に挿入する。 ２．ディーラ端末装置はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能時にはエラーが報告さ れる）。 ・READ RECORD＜EF_IDのSFI,0>（VASコンテナIDの表示）。 ３．ディーラ端末装置は連続番号を読み出す。この番号は，さらに，ステ ップ４からMACに代入される。 ・READ RECORD<EF_SEQのSFI,0>（連続番号の 表示）。 ４．ディーラ端末装置はVASアプリケーションAを選択する。 ・SELECT FILE<PIXA>（VASアプリケーションAがVASコンテナにロードされ ていない場合にはエラーが報告される）。 ５.ディーラ端末装置はEF_VALUEまたはEF_INF0からデータをキャンセルす るためにTRANSFERを使用する。 ・TRANSFER<データ，KDECを持つMAC> TRANSFERの命令メッセージの構成は既に説明した。端末装置がKDECでデ ータに対して正しい署名ができれば，キャンセル手続きの権利を得る。この署名 はVASコンテナによってチェックされる。チェックに通れば，VASコンテナによっ て，EF_TRANSFERに１個のレコードがセットされ，さらに連続番号がインクレメ ントされる。 ６．ディーラ端末装置は，TRANSFER命令の応答メッセージを調べることで ，VASコンテナが正しいかどうかを（すなわち，共通秘密キーKDECを所持してい るかを）検査できる。 ここで，VASデータのキャンセル手続きを説明する。２種類のキャンセル手続 きがある。 まず，インプレメンテーションクラスDF_PTとDF_AD のVASアプリケーションのためのVASデータは，対応するVASプロバイダによって 動作「キャンセル」でキャンセルされる，すなわち，キャンセルによるVASデー タの獲得によってキャンセル可能である。これによって１個の値（価値）が消費 され，他の値への潜在的な権利が生じる。 他の手続きでは，VASデータはTAKE補助命令によって，EF_TRANSFERから一回だ け取り出すことが可能である。この場合，権利は消費され，データは「取り出し 済み」マークを付けられて転送フィールドに残され，さらに他の用途（例えば， 払い戻しされたチケットは帰りのためにまだ必要である）のために使用可能であ る。これは，何らかの必要時に，このデータが他のオブジェクトによって上書き されるまで保たれる。 TAKE命令によるVASデータのキャンセルの経過 １．カード所持者はVASカードをディーラ端末装置に挿入する。 ２．ディーラ端末装置はVASコンテナがあるかを調べる。 ・SELECT FILE<AIDVAS>（VASコンテナが選択不可能な場合にはエラーが報 告される）。 ・READ RECORD<EF_IDのSFI,0>（VASコンテナIDの表示）。 ３．まず，ディーラ端末装置は，動作「VASアプ リケーションの監視（閲覧）」の特別ケースを使って，使用可能なオブジェクト をEF_TRANSFERから読み出し，探しているオブジェクトが求められたかを決定す る。または，SEEK命令を使用してサンプルを検索することも出来る。上記処理が 成功すれば，端末装置は検出したレコードの番号iを認識する。 ４．端末装置はTAKE命令を用いて，番号ｉ，自身が算出した乱数および自 身のPIXとIDを送信して，レコード番号iのレコードに「移動済み」のマークを付 ける。 ・TAKE<ｉ,乱数,PIX,端末ID> ディーラ端末装置は，EF_TRANSFERからのデータ読み出しのためにTAKE命令を 使う。この命令では，その処理と同時に，データが「移動済み」であるマークを 付ける。TAKE命令の実行で，さらに，２個の異なった暗号C1とC2が生成される。 暗号C1はキーKSIG_VASCを使ってVASコンテナによって計算される。これにより ，C1で署名されたこの取り出されたオブジェクトの製作者は，システムオペレー タから（処理の）唯一性と信憑性の証明を得ることができる。トランザクション の唯一性と信憑性は，オブジェクトが由来した（カードによってチェックされた （TRANSFER参照））VASプロバイダの暗号と，トランザク ションに関するシーケンスカウンタの計数値と，「取り出し」でのカードによる 暗号C1から判明する。 暗号C2は，VASコンテナがKGKDEC,PIXおよび端末IDを使って生成したキーKDEC を用いてVASコンテナによって計算される。共通秘密キーKDECを知っているので ，VASコンテナは端末装置に対してVASコンテナ自身の信憑性を直接証明できる。 TRANSFER命令においても，正しい証書または領収書のみが正しいVASコンテナに 記憶されることが同じようにチェックされるので，取り出されたオブジェクトの 信憑性を結論できる。暗号C2は連続番号，取り出しビットおよびVASコンテナID から間接的に生成されているので，VASコンテナは取り出されたオブジェクトの 唯一性をも端末装置に対して証明できる。 TAKE命令を用いる「取り出し」処理は誰にでも許されている。 さらに，サービス端末装置において，インプレメンテーションクラスDF PTとD F ADのVASアプリケーションの読み出しのために，パスワードまたはPIN保護の非 活性化または活性化をできる。また，VASコンテナのPINはPINを知っているカー ド保持者によって変更可能であり，KSOを用いて外部認証することでシステムオ ペレータによって復元可能である。PINまたはパスワードとして，任意の長さの 非数字符号またはそれら の符号の列を使用できる。DETAILED DESCRIPTION OF THE INVENTION         Chip card and usage of chip card       Technical field   The present invention relates to a chip card, a terminal device for using the chip card, and a chip car. And a chip card system.       Conventional technology   Has payment functions such as e-wallet, e-cash, credit function Microprocessor chip cards are already in use. These cards are , ZKA (Zentraler Kreditausschuss, Central Card Committee), VISA (visa) or EMV ( From institutions like Europay Mastercard VISA) It can be used as a payment instrument (substitute for money), subject to conditions according to its characteristics. Has become. The following are representative materials.       −ZKA, “Schnittstellenspezifikation fur die ec-Karte mit chip”, 2 7.10.1995 (Central Card Committee "Interface of electronic cash card with chip" Ace Specification ", October 27, 1995);       −Europay International, “Integrated Circuit Card, Specification for payment Systems, EMV'96 ", V3.0, 30-Jun-1996 ( Europay International "IC Card Specification for Payment System, EMV'96" , V3.0, June 30, 1996); −ISO / IEC 7816-4, “Information technology-Identification cards-Integrat ed circuit (s) with contacts, part4: Interindustry commands for interchang e ”, 01-09-1995 (“ Information technology-identification (ID) card-IC with contacts, Part 4 Replacement Order, "September 1, 1995); −prEN 1546-1, “Identification card systems- Inter-sector electronic p urse, Part1: Definitions, concepts and structures ”, 15.03.1995 (“ ID Card System-Sector Electronic Wallet, Part 1, Definitions, Concepts and Structures ", March 1995 March 15); −prEN 1546-2, “Identification card systems- Inter-sector electronicpur se, Part 2: Securityarchitecture, 03.07.1995 (“ID Card System Sector” Electronic Wallet, Part 2 Security Architecture, "March 15, 1995); −prEN 1546-2, “Identificationcardsystems-Inter-sector electronic p urse, Part3: Dat-aelements and interchanges ", 09.12.1994 ("       ID Card System-Sector Electronic Wallet, Part 3 Data Elements and Exchange " , December 9, 1994);   An overview of the current state of chip cards is provided in the following document.         Technische Merkmale, Normung, Einsatzgebiet 6, ISBN 3-486-23738-1 (Stephan Schutz, Belt Colegraph Technical characteristics, standards and fields of application of Old Cards, Oldenburg Press, Munich / U Gene, 1996, ISBN 3-486-23738-1).   Conventional chip cards are usually only used for a specific purpose, for example, electronic goods. Can only be used as cloth or electronic qualification (identity) certificate . However, the applications applied to these chip cards are generally static. Yes, that is, the application is applied during chip card manufacturing (installation This was not changed during the life of the card.   That is, the conventional chip card is limited in variability and functionality. In particular , Functionality of conventional chip cards is fixed after the manufacturing process, and subsequent changes are not possible Noh.       Disclosure of the invention   Accordingly, it is an object of the present invention to provide a chip card whose functionality can be changed. It is in.   Another object of the present invention is to provide applications and applications that can be executed through a chip card. And the number and type of transactions (transactions) after the chip card manufacturing process. It is an object of the present invention to provide a chip card which can be changed even if it is not. Additional applications Must be able to be loaded onto the chip card. Applied from the chip card Must be able to erase the solution. In addition, individual applications are Defined independently of each other in terms of data processing technology and confidentiality technology, and executed independently of each other It must be.   The chip card uses, for example, data processing technology and security technology according to ISO 7816. The conditions for surgery must be met. However, each individual card of the chip card Applications must be particularly independent of the card platform itself Must.   Still another object of the present invention is to enable a user of a chip card to use the card. The number and types of available applications are determined by the user, ie It is to provide a chip card which can be combined and changed.   Still another object of the present invention is to provide an intra service (ie, an external party). Closed app in the sense that clearing process and service transfer process with Application) and interservices (external relationships with external parties (external partners)) Can be used for both applications that additionally require To provide a smart chip card.   According to one aspect of the invention, one or more card applications are provided on the card. Can be loaded so that the cardholder and / or multiple service Device that can execute transactions with each application. Device is provided.   The card is configured to have new functions by loading the application It is. In other words, the execution of an application that was not possible become able to. The application is defined by the loaded data, Basic functionality of the card that was not present on the card up to that point, for example the operating An application is realized in connection with the switching system. Therefore, the car The application is loaded only by the loaded application. Its functions are extended.   According to one embodiment of the present invention, a data structure (data) is stored on the chip card of the present invention. Database (DF_VAS)) This data structure is itself further divided into substructures and definition data sets. You. Here, the data structure is uniquely identified by a code that identifies the structure, Thus it is independent of the card platform. A so-called a Application, that is, functionality for chip cards, The application is loaded. Therefore, a specific application Special handling of the cardholder and the application by loading the application Transactions can be executed with the service provider. In the data structure The definition dataset contains the type of application loaded into the substructure and And / or retain structure. At least the definition data set, preferably the entire data structure The structure is protected by at least one system key for its modification. , The modification is only possible using that key. Instead of this system key, Other security mechanisms or means are also conceivable. This allows, for example, individuals Data can be protected from modification using an identification number (PIN) or other security measure. You.   With the above structure, various applications can be loaded into the substructure. The card can be erased from this substructure so that the card is Variable for applications that can be executed using Becomes Loading and erasing of the application is performed within the provided substructure. This is done by writing data and keys for the application. System key and data Data structure that enables multi-function (sex) processing by providing a structure identification code Is no longer dependent on the card platform itself, and Independent and independent of the card platform.   Using the card according to the application loaded in the substructure, Transactions that depend on the application are performed by the cardholder and the service provider. Can be executed with Ida.   Preferably, the chip card further includes a transfer storage area, in which the Data to be exchanged by executing the transaction is written, and the data is exchanged from this area. Data is read. To read data from the transfer storage area, the terminal device special Each key has its own key so that each access is confidential and independent of each other. ing.   Substructures and applications on the card should preferably be independent of each other. And each is assigned to a specific provider. These are, so to speak, specific accounts. The provider's proprietary or proprietary data for application execution . Therefore, these are Contains separate information for each application type and service provider. For example , Data indicating specific values (such as bonus points and remaining balance), And information about the service provider. Preferably, however, Contains application specific keys. With these keys, the data in the substructure Access to the can be performed in a type and manner independent of other substructures. Against this Therefore, loading or generating the substructure and the application itself is at least Protected by one higher system key.   Preferably, a transaction between the chip card and the terminal is performed before the transaction is executed. Mutual authentication is performed. For this purpose, application-specific authentication keys and parts A structure specific authentication key is provided.   Next, each VAS application is secured for transaction execution. Data is written into or read from the substructure, or Expanded into (implemented in) the structure via transfer storage. During this writing, Application-specific keys are used. In the case of deployment, the application Existent keys, preferably terminal-specific keys, are also used. Terminal-specific keys For example, using the key generation key provided in the card, Generated from existing data. Thus, the data is written to the transfer storage area. The written data is read by the service provider via the terminal device . Desirably, invalidate the data stored in the transfer storage area (read data). Mark. Services that are not specific to the written application In the case of a service provider, a so-called inter service is executed here. In other words, for a cardholder, at the expense of the holder, Data is exchanged between different service providers.   Another safeguard is a PIN to verify the authority of the transaction procedure. (Personal identification number) or password is further provided.   Because the card is a variable structure, a different number of different applications at different times Can be stored in the card.   The authenticity of the data retrieved from the transfer storage area is preferably a signature Protected using a key, digital key, or at least one key. this A particular advantage of this is that the retrieved data remains in the transfer storage area thereafter. If it is, the card simply marks it as “extracted data” (labeled ). As a result, even after the transaction, Get information about transactions. Therefore, (data) retrieval By the protection of (the data processing was performed only once One time) is also proved.   A further particular advantage is that the data written to the transfer storage area becomes invalid. Includes an expiration date. This allows, for example, It is possible to realize an application capable of arranging marks.   Preferably, a transaction counter (transaction counter) is provided. , Transaction date and value (numerical) data to the corresponding transaction Can be uniquely determined and identified for the application.   According to an advantageous embodiment of the chip card according to the invention, the card has a hierarchical storage. It also has a concept (concept). In this concept, at various levels with various keys, (Data) Protection against modification is obtained. In addition, this concept At the level, it is variable with respect to the application loaded into storage. Toes Each application has its own specific key, and each application has its own Protected and independent. In addition, the entire structure (data) is And protected by the structure identification code (identifier), the card platform itself Independent. Due to the above concept of transfer storage (area), card holders and Data exchange with service providers and between different service providers It becomes possible. Transfer storage device Writing / reading to / from is also key protected. Here, the key is similarly Code-specific, application-specific, but also terminal-specific . Authentication and optional PIN (PIN) before each transaction Personal identification number) or password can further enhance the security of the chip card of the present invention. You.   Claims 21 to 30 describe the use of the chip card according to the invention. Terminal device is defined. The terminal can load and delete applications, Execute transactions, monitor (browse) data, and And other functions associated with each transaction. Card holding The method of executing a transaction between a customer and a service provider is defined in the claims. Defined in paragraphs 31-33. The data loading to the chip card according to the present invention It is defined in claims 34 and 35. All including chip cards and terminal devices The body system is defined in claim 36.   Here, a preferred embodiment of the present invention will be described in detail with reference to the drawings. The drawings are as follows It is.       BRIEF DESCRIPTION OF THE FIGURES   FIG. 1 is a conceptual diagram of a chip card according to the present invention. .   FIG. 2 is a conceptual diagram of an entire system including the components of the present invention.   FIG. 3 shows a data flow of the entire system.   Figure 4 shows possible application classes and transaction models It is a conceptual diagram of operation | movement.   FIG. 5 is a conceptual diagram of a security architecture of a chip card according to the present invention. .   Figure 6 shows a typical implementation class for VAS containers. Data structure.   FIG. 7 shows various implementations of a VAS container according to an embodiment of the present invention. It is Taras.   FIG. 8 is a database (structure) of a VAS container according to an embodiment of the present invention. .   FIG. 9 shows the concept of the database of the implementation class DFPT.   FIG. 10 shows the concept of the database of the implementation class DFAD.       BEST MODE FOR CARRYING OUT THE INVENTION   Before describing the invention in detail, the concepts used in the following description are defined. VAS: Value-added services VAS card: VAS card can participate in value-added services Payment card (such as an electronic wallet) In addition to other applications, such as VAS container. VAS container: The VAS container is for managing VAS applications and for VAS applications. Data structures, access conditions, and keys to enable application functions And (auxiliary) instructions. VAS application: The VAS application contains VAS data. To VAS data Access is controlled by the VAS application. VAS provider is VAS Run one or more VAS applications within the tenor. VAS application Usage is defined by setting (applying), reading and processing VAS data . VAS applications are either intra-service or inter-service In the form of VAS Provider: The VAS provider is responsible for its VAS application. The V The AS application is based on the basic conditions of the system operator It was created with its own load, and then the system operator and terminal It is prepared so that the card holder can use it. VAS applique The option is to be loaded into the VAS container of the VAS card, Will be available after use. Intra service: Intra service is VAS application Is used under the exclusive control of each VAS provider. Intra The service application performs settlement processing with the external party (external partner) or the service. It is a closed application in the sense that there is no service transfer process. VAS app Applications take the form of either intra-services or inter-services. Inter-service: Inter-service application via additional external connections Intra-service application with mutual processing with external parties (external partners) It is. VAS applications are intra-service or inter-service Take one of the forms SO, system operator: System operator is VAS Make VAS systems available to providers and cardholders. Issuer: The issuer is the card issuer and plays VAS cards including VAS containers. Let through. CH, card holder (card holder: card holder): card holder or car Card holder (in this case, a VAS card) The person who uses the card to participate in the event. Card holders are not necessarily It is not necessary to be the original card holder (right holder). Service terminal (terminal): The service terminal is provided to the system operator. Therefore VAS application Installed for The card holder uses his / her own VAS at this service terminal. Manage VAS application on card (Load and monitor VAS application ( Browsing), erasing and forwarding). Dealer terminal (terminal): The dealer terminal has a payment function, Provides VAS functionality. The card holder inserts the VAS card into this terminal device and One pays and at the same time benefits the VAS. AID: (Application Identifier) A unique identifier for the application. The application name is 16 bytes long and can be accessed without knowledge of the data structure of the card. It is also used for selecting applications from the department. This identifier AID is a 5-byte Recording Application Provider Identifier (RID) and optional up to 11 bytes Consists of Application Identifier Registration (PIX). DF: Directory file according to ISO 7816. EF: Elementary file according to ISO 7816. Effective VAS container: A VAS container that can be authenticated to the outside world. KID: (key identifier). The number of the key in the elementary file containing the key. R & R: Rules and regulations (rules and regulations). p: Maximum number of objects of the implementation (implementation) class DF_PT. a: The maximum number of objects of the implementation class DF_AD. nrDIR: Maximum number of objects: nrDIR= P + a The number of records in EF_DIR is nrDIRIt is. nrEF_TRANSFER: Number of EF_TRANSFER records.   FIG. 1 schematically shows the structure of a chip card according to the present invention. card Master file MF set during the creation (manufacturing) process (optionally provided In addition to the static and invariant data such as the wallet function DF_PURSE, That is, a data structure or database structure DF_VAS is provided on this card. You. This helps to provide additional functionality, the so-called value-added service VAS . The above additional functionality to implement the application-these will be later, ie the card It can be loaded onto the card even after it has been created-so that the card has its own functionality and Flexible and variable with respect to transactions performed by According to the invention The card is provided by a so-called VAS container (DF_VAS) provided on the chip card Variability and flexibility with regard to the function of In addition, the container is stored on a card Application separated from card platform by security technology are doing. This makes the application independent of the card platform And sometimes even transfer to another card It is possible.   The new functionality (value added service VAS) according to the present invention This is realized by the top card. These new functionalities are implemented by VAS container Is done. The VAS container on the microprocessor chip card is a VAS application Form a platform for accepting services. VAS application is special It implements certain additional functionality.   In electronic wallet, payment by card (payment function) and VAS application ( The use of additional functionality is performed by a separate mechanism. However, the card user (Card User) or Card Holder (Card Holder) Looks like a procedure.   The microprocessor chip card can accommodate various independent applications. It is extended by the VAS container that can be used. The container is the application (configuration) ), Erase and transfer functions. These functions are performed by authorized system Available only by system operators. VAS container is a microprocessor Data and confidentiality depend on other system components on the subchip do not do. VAS containers can be completely defined and function on their own. In the container Defines an independent confidentiality architecture (configuration) for VAS applications Application has its own security Function can be used. This confidentiality architecture uses card-specific keys I do. The key is not special to the producer (card creator), It does not depend on the identifying characteristics of the form.   The VAS container also uses a mechanism to generate terminal-specific keys. This mechanism In addition, the VAS container itself proactively verifies the authenticity (certainty) of the terminal device and the terminal device. Data can be verified (checked).   The VAS application is filed in the VAS container. VAS container mechanism Data is made available through the Be done. VAS Conte provides secure data for inter-services between partners Enable and control the exchange. The VAS conte actively performs control operations. Ie , Control the authenticity and uniqueness (one-timeness) of the transfer data value.   VAS Conte, compared to other approaches to multi-application cards, Advantageously, the above concept does not depend on a specific card platform . This allows platform-specific security mechanisms (keys, identification data, Provides a confidentiality architecture that does not depend on personal identification numbers (PINs, signature methods, etc.) Is done.   Another advantage of the VAS Conte concept is that the number of different applications on the card is Must not be strictly governed by restrictions or conditions at the time of card creation or card issuance It is. Loading the actual application onto the card is up to the cardholder. And is limited only by the available storage area of each card. Actually on the card The number of VAS applications that can be loaded depends on the actual use of the card. Mosquito The card user collects the VAS applications individually on the card. Then this The combination of applications may be changed. Multifunctional card by VAS container Becomes possible. During the life of the card, the card functionality is determined by the number of applications Can be combined or used by changing the type. For this reason, Load multiple applications that required a specific card on a single card Can be used. VAS applications can be transferred to other cards. to this VAS applications can extend the life of the card Accompany the card user for the duration of the option.   A microprocessor chip card with additional services is Media that are suitable for buying and selling, and in which case, accessing protected data. I have to. These microprocessor chip cards are used for payment, Unit (equipment) And can also be used as a numerical storage. After issuing the chip card, customer's own request And flexibly set other services in the card in accordance with The card can be used for the control of. Microprocessor chip Actively control the credibility of the associated terminal device and ensure the uniqueness of the transferred data (one time Gender) and credibility.   FIG. 2 shows a system configuration diagram. Here, the system components are shown. The system operator makes the system of the present invention available. Service terminal equipment VAS application can be loaded, erased and transferred in storage (ST) . Other operations include selection, monitoring (browsing), and interpretation of the VAS application.   VAS application providers, so-called VAS providers, are system operators The VAS application according to the basic conditions of the Design. The authenticity of the corresponding terminal program depends on the conclusion of the digital signature. Verification (check).   FIG. 3 shows the flow of data in the system.   The VAS application is operated by the card operator's terminal by the system operator. Made available in the device. VAS application can be used (participated) In order to achieve this, the VAS Must be loaded on the tena (VAS-Container).   The VAS application on the card is used at the dealer terminal (HT), and V AS data is applied (set) or deleted.   In order to realize a microprocessor chip card with VAS functionality, Other applications (eg, payment applications such as electronic wallets) Is further set on the card.   VAS container can apply (set), delete and transfer VAS applications Use the function to These management functions are used only by system operators. And is protected in the card against use by others. VAS container transfers Storage device, which allows data exchange between VAS applications. Manifest.   Two instructions TRANSFER and TAKE are used to control the transfer storage. TR The ANSFER instruction creates an entry in the transfer storage for each application-specific data. To achieve. In addition to this user data, date and time There is an expiration date and identification data. With the TAKE instruction, the object is Is retrieved and marked as retrieved. For individual applications So the object is Marked as still valid or invalid. Transfer data is authenticated by VAS container Have a gender and uniqueness (one-time) test.   VAS application makes application available (preparation, setting) control Use VAS data to do Access to VAS data is a mechanism for this As controlled by the VAS application. The configuration is the same for all VAS containers. Are provided for all applications. VAS provider is in VAS container Activate one or more VAS applications. VAS application Use is defined by the setting (input), reading and processing of VAS data.   The VAS container supports (supports) inter-services. Inter service Access to shared (common) data, forward service requests and different partners Requires a liquidation (payment) of services in between.   Next, services and applications enabled by the chip card according to the present invention will be described. An example will be described.   The following descriptions each relate to implementations and functions in the state of the art. The function is In the future, it will be enabled by one or more VAS applications.   First, the intrater service will be described. Example A: Customer club   Department stores host customer clubs. Customer is a club Become a member and specialize in club qualifications that are not available to non-club members. Service. Now, club members can use club membership cards in the club environment. Proof of qualification (identity). The membership card is created when you join, but it is not transferable, Usually has an expiration date. Perform a specific transaction depending on the membership card I can't do that. In other words, there is no coordination with the customer's transaction volume. Therefore, the membership card Is limited to bonus programs where customer status and transaction value are related Have been. Similar system: wholesaler certificate, senator card, book club Goal: Club membership proved by application in VAS container It must be. Example B: Bonus system   Customers receive bonus rights for each transaction. Bonus rights are cumulative At the time determined by the customer, it can be exchanged for monetary value. Bonus rights are valid for a certain period, It is managed by anonymous or registered name. Bonus rights depend on transaction volume or frequency of use appear. Similar system: Miles & More point status Goal: Point balance is calculated in the application in the VAS container. Must be managed in a different way. Example C: Discount   Customers receive discounts (for volume) according to the plan. Discount for each transaction Allowed for each session. Cards do not maintain transaction history. Each transaction is It is complete on its own. Objective: Discount (request) rights must be managed by the VAS application. Example D: Credentials feature   Depending on the features on the card, third parties may be informed that they are eligible for a particular service. You can prove it. Proof of the certificate at the time of each transaction Must be identified (photo, personal identification number (PIN), biometric Fixed)). The authenticity of the certificate is used as a security feature. Similar systems: Internet access, home banking access, telephone card Goal: Qualification (certification) must be proven in the VAS application. Example E: Unit of value   Value units are purchased and consumed by one or more uses. Each tran One or more units are subtracted for each transaction. Use rights can be transferred and used You can also set conditions. Similar systems: regular tickets, coupons, subscription concert tickets, squas h) 10-point ticket, movie ticket, telephone Goal: This transaction must be streamlined by VAS application No. Example F: Settlement of usage fee (bill to user) Service usage is time, frequency and amount Is registered and settled according to the tariff. The range of services required I can't know before. Similar system: meal coupon, short-term parking ticket Goal: Tariff clearing is done by the VAS application. Required each time The required latest clearing data must be stored in the VAS container. Example G: Memo media (data record; mobile database)   This application allows you to transfer cardholder data to a VAS provider You. This allows you to automate transactions that are still performed manually today. You. No monetary movements occur from this data. Similar system: Filling in lottery tickets, purchase list, receipt, telephone registration Goal: VAS provider retrieves card data and immediately provides corresponding service Must be able to (eg, connect telephones, collect required goods) Collections and lottery tickets electronically) Data is stored on the card for short or long term Can be saved.   The example of the intra service was explained above, but only a few examples of the inter service Will be described.   Inter-services should be used whenever a service involves multiple VAS providers. appear. Inevitably, data leaves one VAS provider domain You. This is currently performed by writing proofs on paper (records on paper) Have been. Example A: Ride fare adjustment   The department store will refund the public transportation fare used by customers to visit the store. The customer Must be presented to the department store. The department store has been refunded On the ticket. In some cases, department stores may reimburse customers for a portion of the amount refunded. You may receive it from transportation. Goal: Refund procedures must be performed electronically. Example B: Ride coupon (voucher, voucher)   Department stores issue return coupons to customers for shopping expenses when they shop. Pay customers. The customer can go to the ticket office to get a coupon ticket or Pay and ask for a ticket. The transportation will settle the coupon with the department store. Objective: VAS application for electronic checkout between department stores and public transport Create a mechanism model with the option. Example C: Customer parking   The department store will refund a portion of the parking fee if the customer uses a specific parking lot. The parking lot is managed by an independent company and receives the borrowed money of each customer from the department store . Goal: VAS application for electronic clearing of department store and parking lot Creation of mechanism model. Example D: Multiple Bonus Program   A common bonus program between a trading group and a service provider Agree. Goal: Each partner can add or subtract bonus points for the common account on the card. The settlement of services between partners is performed in a background system. Example E: Recognition of bonus points between service providers   Each service provider activates its own bonus program, but There is agreement on recognizing other bonus points. In a known example, Regarding the “collection of“ miles ”” between the car rental company and the airline Consent is mentioned. Goal: Support transferring bonus points by card. Each service group Providers first accumulate their bonus points without any intervention. For transfer A safe mechanism must be provided. Example F: Night taxi You can get on (for example, after 10:00 pm). The taxi company has a ride certificate upon settlement You have to prove it. Take a taxi to avoid illegal use Record what you did on the card. Objective: The use, control, and usage fee processing of this service are implemented using VAS applications. Must be done.   Next, the configuration of the chip card according to the present invention will be described in detail.   Microprocessor chip cards with VAS functionality, in particular, have VAS containers. are doing.   The VAS container is a stand-alone application, the underlying card platform Present alone or with other applications on a form. VAS Conte Na is completely self-defined and can function alone. The container is usually on the same card Operable without some payment features. In particular, VAS containers have independent confidentiality VAS applications have their own confidentiality due to defined architecture Function can be used.   Value-added services include transactions from customers at VAS provider terminals. Action is also included. VAS providers provide system monitoring (browsing) and statistical data. These transactions are tracked (monitored) for purposes such as collection. card Application-specific identification to optimize and unify data structures in the application Refrain from using these numbers, and use a unique VAS container identification number (VAS container ID) is recommended. This number is used by the VAS Ida can be used. This number allows providers to manage their own numbering system The burden of doing so is eliminated.   VAS container confidentiality architecture derives (generates) card-specific keys To do this, a unique identification number (ID) is used throughout this system. The card features It is possible in principle to use the existing numbers, but it is better not to use them. This is inconsistent when VAS containers are installed on different platforms This is because there is a case where a number system is used.   The VAS container ID is issued by the system operator and creates the VAS container. Sometimes entered by the card issuer. This ID is used to delete the VAS container. Thus, it becomes invalid and is thereby removed from the system. VAS container is VAS app When the VAS container ID is removed and the VAS container ID is removed, The antenna is considered erased.   When transferring a VAS container from an old card to a new card, the VAS The antenna ID is also sent with the VAS application. This transfer uses the old VAS container. Transfer from a new card to a new card. After this procedure, the old There is no longer a VAS container in the code. The VAS container on the new card is above This is overwritten and erased by this process. VAS container ID is from old card to new card In the VAS provider background system, the reference number No conversion is required.   An individual VAS application may have two copies only under the control of each VAS provider. It can be transferred between different VAS containers. With this function, VAS container ID and VAS The (assignment) relationship with the application changes, which may be VAS Must be recorded in the provider's background system.   VAS containers do not have information on personal characteristics. VAS applications are Data, but its scope depends on data protection aspects and storage Can be minimized from the viewpoint of effective use of necessary If it is, the VAS application is a background system for personal data. And use the VAS container ID to set (establish) the relationship with the card. You.   An essential feature of VAS containers is that they support interservices. Inter-services include access to shared (common) data, transfer of service requests, And require liquidation of services between different partners. The VAS container Enables and yet secures applications in intra services Sex must be guaranteed.   So-called intra-service VAS applications are exclusive to VAS providers An application that is operated under control. VAS providers are applications Define the security of the application without external dependencies. External unless key is passed elsewhere Others cannot change VAS data.   In order to execute inter-services efficiently, partners must use shared (common) data. Access to the data. Shared data access is tiered and confidential This is realized through a holding mechanism.   The first stage (step, level) of shared access is through the public transfer area only. Done. VAS providers can exchange data through this area, but they cannot access each other. You do not need to know the application and key. To write data to the transfer area The terminal must use the appropriate key for the There is no. Anyone can read data without restriction. VAS providers and par For bidirectional data exchange with Tona, both use write keys (obtain) It is possible if possible. The transferred data is based on the VAS provider's intra-service VAS Applications can be created, and vice versa They can also incorporate data into their own intra-service VAS applications. Wear.   The second step is to invalidate (cancel) the value unit expressed in the form of VAS data It is to be. The VAS provider uses a special key for writing to convert the value unit to VAS data. Data. The unit of value is the campaign obtained from the controlling VAS provider. Consumed by interservice partners who can use cell keys It is. At this stage, partners with mutually different rights will be able to use private VAS data To access.   The third stage is the VAS data from all relevant interservice partners Direct write access to Since VAS data can be changed without restrictions, This method requires a corresponding trust between partners.   The transfer area is the function of the connection (connecting link) between VAS applications. To The data in this transfer area is stored by the VAS application in the VAS container. Generated. Do not allow the creator to run his own VAS application in the VAS container If so, the data may be placed directly in the transfer area.   The transfer area can basically be used by all applications, Only the application that has that right (key) is allowed. Rules Only the receiving side (application) who has the right in terms of rules and regulations (R & R) Can retrieve data from the transfer area. The receiving side receives the transfer data sent to itself. It checks whether it exists and retrieves the data for processing in its own application.   Prevents transferred data from being tampered with (falsified) in public (data) exchanges Data creators introduce credibility features (information), and VAS containers No. is introduced. These elements ensure the uniqueness of the transfer information and the data Source proven.   If necessary, the data creator performs a credibility check on the recipient of the transferred data. Set the possibility (means) of execution. If the receiving party does not want this, Payments are still based on loyalty and trust. In some cases, credibility feature information Is a data generation VAS probe It is only checked during settlement in Ida's background system.   Data can be extracted only once from the transfer area while maintaining the authenticity feature information. it can. Upon retrieval, the data is marked and placed in the transfer area (as a copy). ) Will be left. As a result, even after the data is retrieved, the data is not We can prove transfer procedure.   The data in the transfer area includes an expiration date. This can be used for any application Can be overridden by the The data in the transfer area is marked when retrieved. Can be used immediately for overwriting. Within the expiration date of the transfer dataset When the transfer storage area becomes full, the service terminal The owner must delete entries that are no longer needed.   Three operations are defined for creating a model of a VAS application. these The operation operates on VAS data. Loading and erasing applications is done by VAS It is a tena function and is not considered in the following paragraphs. Acquisition: Acquisition of qualifications for requesting services and VAS data for VAS applications. Proof in the data. Cancel: Generally, without consumption of application VAS data (invalidation) , Or all of the VAS data To perform the request, or to consume part of it. Electronic receipt by this procedure Is created, which is placed in the transfer area. The receipt contains an important expiration date, The date when the data can be deleted from the transfer area is described. Retrieval: Generally, for later processing (in a background system (moving) system) To retrieve the electronic receipt from the transfer area. A copy of the receipt is left, Proof.   “Acquisition” of VAS data is performed only by each VAS provider. VAS data “Cancel” is only by the VAS provider that generated the data in “Acquisition” Or to an Inter-Service Partner authorized by the VAS Provider So only done. "Retrieve" can be performed by any VAS provider. For interservices without access to VAS data with equivalent rights, partners Activates the state transfer "retrieval". The resulting receipt is then Clearing via system operator and VAS provider background system Is done. "Acquire" and "Cancel" can be performed in a single step.   VAS applications with common features are further classified. These Lass is the data in the VAS container. Form the basis of the data structure. The VAS provider is responsible for implementing the application Select an application class.   In this regard, the following application class is defined. ・ Score (storage area) database ·ticket ・ Certificate (identity, identification) certificate ・ Certificate ・ Database   The point database indicates the application class for which point accounts are managed . A point value is added (credit) or subtracted (withdrawn) to this point account. The addition is made by the VAS provider by writing the new account balance into the database. Will be The subtraction is performed by a “cancel” action, and an electronic receipt is used as evidence. It is written to the transmission area (storage area). Access to these features is available in two different It is performed using Xesky.   Tickets are canceled one or more times and are consumed accordingly Indicates the application class that contains the region. Addition of numerical values on tickets (credit G) is performed only once.   The qualification (identity, identification) certificate must be recognized by VAS data. Shows the application class containing the proof of permission. Usually this proof is It is not revoked, but may be subject to defined criteria, e.g. And is invalidated by The authenticity of the ID card, as defined by the application The presentation of the gender (eg, resident parking certificate) or identification is documented. (example For example, a shared taxi on a monthly ticket: Creating an electronic receipt using a card. This territory Tax receipts are submitted by the taxi company to public transport and settled accordingly. ) Optionally, the use of the certificate may be electronically stored in the transfer storage on the card. Documented by receipt.   Certificates are applications that temporarily store service requests (usually short-term) on a card. Indicates the application class. This electronic certificate is stored in the transfer storage area of the VAS container. Only saved. Usually, the application that uses the certificate is the application that creates the certificate Application. Certificates can only be retrieved from the transfer storage once Documented by Background authenticity features created by VAS containers May be used for liquidation in a round system.   A database is an application that stores data in a VAS container by a VAS provider. Class. The class provides additional services to the customer (eg, Millie Restaurant's last menu, last lottery number, service preferences, offer Draft list). Data is for reference only (for informational purposes) and is a VAS provider Does not represent a service request to Access to this data is provided by the VAS provider. Controlled.   Each application class is characterized by a typical use cycle. In the following table , The application period of the above three types of operations for application class VAS data (Note, “Acquisition” is not “Load Application.” Is not "application erase").                         Table 1 Use cycle *** Right in application class "database" There is no profit, the application just enters the data.   FIG. 4 shows a transaction model of the above application class and operation. Indicated by   Next, the security architecture of the chip card according to the present invention will be described in detail. You. The following keys are defined to ensure confidentiality:                           Table 2 List of keys   The confidentiality architecture is the life support for VAS containers and VAS applications. It is based on a cycle and has a hierarchical structure according to the responsibilities of the related instances. That Fig. 5 shows a conceptual diagram.   Next, the structure of the VAS container and the applications installed in it are explained. I will tell.   VAS container and auxiliary instructions for VAS are issued by the publisher along with other non-VAS applications. Authorized provider set on the card or at the latest at the service terminal Will be integrated into the current card platform.   As a second possibility, the following mechanism can be used. System operators and publishers Interim key K betweenSO *Decide. Issuer opens card with key known only to himself Created a file for the VAS container, ー KSO *Into (this file) DF_VAS. This allows the system operator Later (for example, when this card is first used in a service terminal) ー KSO *Your own key K that only you knowSOCan be replaced with this And the system operator has other data such as KGKDECYou can enter your own Or, for platforms with dynamic management, for VAS applications You can create and delete files yourself. Therefore, the issuer must After using the VAS container, the VAS container is no longer accessed and only the system operator Access to the AS container is guaranteed. Share with other applications ( Common) Since there is no database or data exchange, VAS container confidentiality architect The capture is independent of other applications residing on the card platform.   In a special embodiment of the invention, however, the first possibility must be used . Issuer issues VAS container with all keys according to system operator's instructions. Must be installed on the card.   The VAS container has a predetermined file structure, predetermined access conditions (AC), and several groups. Includes global data. In particular, global data is stored in VAS application rows. Key K used for key and eraseSOincluding. Only this system operator knows VA authorized by key Only S applications can be loaded. For this, the card is key KSOThrough Request external authentication by the system operator.   Cardholder loads VAS application on service terminal If necessary, the VAS provider in charge will execute this process instead. Ask the system operator. A place for loading a VAS application into a VAS container VAS provider provides system operator with key KLVASPAnd KRVASPPass the operation The operator enters these keys into the application. Key KLVASPBy VA The S provider protects application data from write access and furthermore Protect internal data from read access. For this purpose, the card is VA S Provider Key KLVASPRequire external authentication based on That is, the card Actively check the authenticity of the terminal device. If this function is successful, the VAS application Application write access and application internal VAS data read Access is granted to this terminal. Internal authentication, ie dealer terminal equipment Inspection of VAS applications (and therefore cards) for authenticity by Option. When using the VAS application by the cardholder , Writing of these internal VAS data to the application and application Inside Change is key KLVASPIt is possible from any terminal device that can use. Therefore, " Acquisition ”function is key KLVASPUPDATE RECORD command, subject to external authentication by Is supported.   VAS application read access to non-internal data is key KRVASPMa Or KSOOr by properly entering a personal identification number (PIN) or password Only when external authentication has already been performed by the system operator. Is done. Access protected by a personal identification number or password must be provided by the cardholder. The terminal or wallet (wallet) is provided so that data can be referenced. You. The card holder of the service terminal device can check the value data or status data. PIN or password protection for reading is applied to all applications simultaneously. Whether to activate (execute) or deactivate (non-execute) the select.   Global data in the VAS container is signed with the data extracted from the transfer area Key KSIG_VASCIs supported. Transactions between interservice partners Application data must be transferred under clear-cut protection for clearing In this case, the integrity of the transaction (no deception) I can prove it. Filled out by the interservice partner In addition to the signature of the option Data set, KSIG_VAscAnd a transaction cow managed by a VAS container And a signature based on the counter is added. Everyone is allowed to read the transfer area, , KSIG_VASCCard signatures can only be generated by calling the "eject operation" (This is only possible once), so the unacceptable double A clearing process is detected. Each inter-service partner shall confirm the certificate of the retrieved certificate. Have the system operator confirm the authenticity and the one-timeness (uniqueness) of (processing) Can be. In addition, the system operator can verify the signature and use the VAS container Can prove the authenticity of   Card if the card platform supports asymmetric key procedures K personal (secret) key inSIG_VASCCan be used for signing, or A key can be generated from a personal key generation key. In this case, the VAS provider Will sign its public (non-secret) key without consulting the system operator. Can be used for inspection.   Global key generation key KGK is used for VAS container dataDECIs included as part of I will. This key is used for all terminals of all VAS providers. Access key K for checking operation authorityDEGGenerate in (Key generation and inspection will be further described below). Cash value data Different confidentiality standards than when loading or acquiring rights. It is. Here, a global key is used instead of an application-specific key. It is sufficient if used. This global key is first converted to an application key , And then converted to a terminal key. The VAS provider has to generate their own terminal keys. Only the application-specific keys derived from the global key Be informed. Next, this will be briefly described.   Total message authentication code for DES key k with certain messages d and DES The operation is indicated by mac (k, d). If the information is 8 bytes or less, this expression is encoded (key (Ie, ICV = 0). This is followed by a parity The calculation of mac (k, d) to which the cut is applied is denoted by macp (k, d). As a result, k '= macp (k, d) Is a valid DES key.   Thus, the calculation of the application-specific terminal key is as follows.       1． Each card has one key             KGKDEC Is stored. This key is the same for all cards, and the system operator's secret ( Matters). The system operator personalizes this key in the card To be done.   From this key, all other VAS application keys and terminal keys can be derived. You. 2． VAS provider AIDs VAS application AA= RIDVASPIXAIntroduce with And Here, the system operator is the key KGKDECAnd applications from PIX Calculate a unique key,   KGKDEC, PIX= macp (KGKDEC,PIXA) Give this key to your VAS provider. 3． The VAS provider does not apply the TRANSFER instruction to VAS application A. KGK for all terminals that have to beDEC, PIXFrom each terminal identifier (Terminal ID) to generate a unique key for each.   KGKDEC= macp (KGKDEC, PIX, Terminal ID)         = macp (macp (KGKDEC, PIXA), Terminal ID)   The VAS provider stores these keys on its terminal. VAS provider own If the terminal device is not operated by itself, the VAS provider generates a key and To the operator of the equipment. Four. For VAS cards, when the TRANSFER instruction contains a cipher C created at the terminal Only this instruction Execute The encryption C is formed in the transfer area using the specific data data of the message. You. The card itself is KGKDECKnows the user data and encryption from the terminal device In addition to C, it receives a Terminal ID and PIX (or the card itself Know IX. In this regard, see the section on the transfer instruction TRANSFER. This This allows the card to calculate the cipher C 'itself using the user data. mac (macp (macp (KGKDEC, PIX), TerminalID), data) = mac (macp (KGKDEC, PIX, TerminalID), data) = mac (KDEC, data) = C '   Here, the card compares the cipher C 'calculated by itself with the cipher C calculated by the terminal device. You. If they differ, an error occurrence report is issued and the transaction ends. one If they match, the VAS card executes the transfer command TRANSFER.   Various confidentiality standards include service terminal equipment, dealer terminal equipment (for loading and And acquisition) and single-function dealer terminal (for cancellation) Is what you do. To perform a “cancel” operation, the terminal device must On the other hand, key KDECKnowledge of You have to authenticate yourself. Key KDECIf the matches, the intruder (terminal The user can perform the functions of this single terminal only. However, this procedure is It is recorded as a document in the code. Document is a unique sequence number, canceled And a terminal identifier. VAS applications regulate access to VAS data. Use the VAS container's confidentiality service. Realization of VAS-specific functions The row is sent to the authorized partner (party) by the definition of the access right. Limited.   Generally, for each VAS application, a publicly accessible data area ( For example, an area for reading numerical values from a wallet) and corresponding (responsible Sure) there must be a private (private) data area for the VAS provider No. The provider may provide this private area (eg, internal management information) to third parties Protect.   A card is an individual record of an elementary file (EF) according to ISO 7816-4. Does not provide different access protection for To display different locations of a file, you can use a number of files, each containing one record. Must be used.   Therefore, as shown in Fig. 6, VAS data is stored in four elementary files. By classifying Application Class "Point storage (database)", "Ticket", "Certificate" Different access protection for "certificate" and "data memory (database)" Can be realized.   The four elementary files contain the following content and are protected by the following: You.                       Table 3 Outline of file   This structure of the elementary file (EF) is compatible with all application classes. To support the same and distinct access rights.   By the way, similar application classes are put together and one imme This implementation class is assembled into a presentation (implementation) class. Determines the number and size of elementary files. For this reason, application Since various areas are required for each application, use a smaller storage area. Can be. Application class "point storage" and "ticket" are the same resource Requires KF_KEY, EF_INFO, EF_INTERNAL and EF_VALUE. It is organized into the annotation class “DF PT”. Application Class "Qualification Elementary files EF_KEY and EF_INFO for "certificate" and "data memory" Suffices, so it is summarized in the implementation class "DF_AD". Quantity In p, there are p objects of the implementation class DF_PT and The number of objects of the mentation class DF_AD is a, and application Class "point memory" and "ticket" and application class "qualification" Certificate and data memory can be loaded.   In particular, for all VAS participants to exchange shared data The application class "Certificate, which must include public read access The implementation class "transfer area" is used. Writing Access is correct KDECOnly indirectly using the TRANSFER instruction which needs to be signed It is possible. This implementation class is a global From only one entry in the elementary file EF_TRANSFER belonging to the data Become. Objects of this class are records in the file. these The implementation class is also called "EF TRANSFER".   Within the VAS Conte there is an implementation class shown in FIG. these The implementation class of forms the memory model of the VAS container.   There are two methods for creating a memory model. Which one to take depends on the platform of the card Form. − Fixed partition of storage area for VAS container   For the implementation classes DF_PT and DF_AD, the maximum object size for each The number of objects p and a are determined by the issuer, and the issuer uses the CREATE FILE instruction. And loaded on the card. DF_PT these objectsiAnd DF_ADiIndicated by rear In addition, a VAS application is a free object, that is, another VAS application. Objects not occupied by the application Can be loaded on the Here, UPDATE RE is used to load and delete the VAS application. Only the CORD instruction is required.   That is, the publisher can use both implementation classes as needed. Determine the number of objects. This is the actual VAS user profile of the cardholder. It does not always match the turn (how VAS is used). Classification is the term of use of the card Will be kept through. VAS applications should have appropriate implementation Loaded into an object that is a class. Then, the implementation class DF_AD If none of the objects can be used (no longer), for example, credentials Object of the implementation class DF_PT Can be loaded into the event. Assign VAS application to objects Apply the triplet (VAS application) to the global file EF_DIR of the VAS container. Application PIX, load object FID, application clear text Name). Is application removal EF_DIR? Corresponding to removing the triplet from the application The memory by reading the data (by the UPDATE RECORD instruction) (destructive) Read).   This variation also eliminates the dynamic generation of DF / EF structures. Used on card platforms that do not support leaving. -Dynamic configuration of implementation class objects   For each VAS application to be loaded, the underlying imp The files needed for the creation class are set by the CREATE FILE instruction. . When erasing the VAS application, the DF / E occupied by this application F is completely removed from the card, freeing up memory space. Implementer The maximum number of objects in an application class is not explicitly determined here by the publisher , Depends only on the available memory space in the card.   The above variations are based on dynamic database by card operating system. Need resource management.   The following embodiment is based on the first variation. This is the second burr Due to high demands on the card platform used. . However, dynamic database management is available and dynamic setting of objects Saves memory when it is guaranteed to be advantageous in terms of management costs Can incorporate this initiative and provide flexible services to cardholders. Can be provided.   Next, the VAS container and functionality of the VAS customer card, Shows data structures and instructions that are implemented in comparison to other system components. further, In the case of a typical commerce showing each interaction between a VAS container and a terminal On the other hand, the VAS operation is determined. It is performed under the following initial conditions.       ・ In the dealer terminal device, each card is independent of the platform , The same data interface and the same command interface can be used. Therefore, the required instructions are clearly stated in the coding (of the card).       -The service terminal device can recognize the card platform. Therefore, the machine Performance is obtained by platform specific instructions. Therefore, this procedure Is partially informally described. How this feature is provided Is left to the card manufacturer.   In this regard, the various implementation classes of the VAS container are diagrammatically described. It is shown in FIG. Fig. 8 shows the data structure of the implementation class of the VAS container. Fig. 9 shows the data of the implementation class DF_PT. Fig. 10 schematically shows the structure. Fig. 10 shows the data structure of the implementation class DF_AD. It is something.   VAS container file access is the following access Explicitly limited by conditions (AC).                         Table 4 Access conditions The file access conditions are as follows.     ALW (Always) = File access of this instruction is always allowed     NEV (Never) = File access of this command is always prohibited      ・ KSO= Key K before accessSOExternal authentication of the system operator using There must be      ・ KLVASP= Key K before accessLVASPExternal authentication of VAS provider using Must      ・ KRVASP= Before the access, the terminal device approved by the VAS provider is key KRVASP Must be externally authenticated using       ・ PIN = The correct PIN is possessed before access Input to the card in plain text not encrypted using the VERIFY command. Must be sent       ・ PIN or KRVASPOr KSO= Before access, correct PIN is given to cardholder Must be entered, or KRVASPBy VAS provider using Or KSOMust be externally authenticated by the system operator using Must.   The thing to note here is that they are connected by "or" as described above (Or-linking ) Access rights are not normally provided by the card operating system . In such cases, special implementation costs are required. (Substitutability: explicitly Special READ instruction with fixed security attributes).   The data fields in the record of the elementary file are separated according to the following format. Classified as: ASCII, binary, BCD, data, format string.   Data element type "format string" packed VAS data Expressed in format. This expression form can be displayed to the card holder in the terminal device.   For optimal data storage use, plaintext and binary data are combined and formatted. It can be displayed by a mat macro.   All elementary files (EFs) in the VAS container are in accordance with ISO 7816-4 Converted to a linear format as a fixed-length record EF file (linear fixed-length record File).   DF_VAS elementary file EF_ID is one record including VAS container ID Consists of   DF_VAS elementary file EF DIR is nrDIRConsists of records. VAS container For each VAS application loaded in the EF_DIR, the corresponding Proprietary ID extension (PIX) of the application and the physics of the application The storage area (the FID of DF_X where the application was loaded) is set. PIX is an example For example, as an identifier, the application and the server to which the application is assigned Identify the service provider.   The entry in EF_DIR is dynamically set by the service terminal of the system operator Is done. An empty TLV object "61" is set for a record with no entry .   When loading a VAS application, a suitable implementation The empty storage area of the glass is searched first, and specific VAS data is written to the area. Finally, a new record is created in EF_DIR.   When erasing the application, An empty TLV object must be written in EF_DIR.   The elementary file EF VERSION of DF_VAS indicates the version number of the VAS container. Includes one record.   The version number is based on the VAS container variations (modifications). And / or used on the terminal to distinguish between different software versions. Can be used.   The DF_VAS elementary file EF_SEQ contains the number of the next transfer field entry. Includes one record.   The serial number is read by the auxiliary command TRANSFER. This instruction is then transferred In the field EF_TRANSFER, in particular, the record for transferring the serial number from EF_SEQ Make it. The sequence number, together with the instruction TAKE, each record is once from the transfer field Guarantee that it will be removed. TAKE further reports that this is a serial number Record with signature using. This means that the (original) certificate (voucher) It is guaranteed that the receipt has been retrieved only once.   Next, the transfer area will be described in detail.   The transfer area is set inside the VAS container and nEF_TRANSFERContains records. this The entry of the record of the file includes the transfer data generated by the TRANSFER instruction. Data exchange between VAS applications via transfer area The VAS data of the class “certificate (voucher)” is stored.   The transfer area can be read without restriction, but write access is a command unique to VAS. This is only possible with the commands TRANSFER and TAKE.   Loading of the data in the data field by the TRANSFER instruction It is done according to the "use" algorithm. The oldest data in the file is the record Can be detected by searching for the minimum value within the first two bytes of.   The data field may be "fetched" and / or "taken" by the TAKE instruction. Moved "can be marked in the transfer area. In either case, the data in the transfer area Data deletion is performed by overwriting new data.   Each record in the transfer area includes, for example, expiration date, terminal ID, PIX, serial number, other Including optional data.   List DF_X (X = PT1, .., PTp, AD1, ..., ADa) Each elementary file EF_IN FO is one record consisting of expiration date and general VAS data of VAS application including. Here, for example, ticket type (regular ticket or coupon ticket) or boarding place Can be mentioned. However, EF_INFO has at least one application Must include the plaintext name of This plain text name is "VAS It can be read for "monitoring (viewing)" operation of the application. VAS providers must protect sensitive data with appropriate foreign key algorithms No.   External authentication is KSOOr KRVASPOr PIN protection is required by the cardholder. This EF can be read when the correct PIN is entered in the active state .   List DF_X (X = PT1, .., PTp, AD1, ..., ADa) Each elementary file EF_IN TERNAL is used by the VAS application via the VAS application loaded in the file. It consists of one record that can contain the internal VAS data of the data. Other card holders No VAS provider can read this internal data.   List DF_X (X = PT1, .., PTp, AD1, ..., ADa) Each elementary file EF_VA in The LUE consists of a record that can contain an integer field of VAS data. Outside Department authentication is KSOOr KRVASPOr PIN protection is activated by the cardholder. Enter the correct pIN or the correct password in the active state When this is done, this EF can be read.   The key fields following these are set by the VAS container or VAS application. Can be used. The following description assumes complete DES coding. Ie , All keys in the VAS container are DES keys, 8 bytes (Including parity bits).   KID (Key Identifier, Key Identifier) in VAS container and VAS application ifier), the following keys can be referenced.                       Table 5 VAS container key  Each key is tied to an error count. This counter indicates authentication failures for these Register with the key, and when the limit entered in the counter is reached, use after that Ban.   Within the VAS application, the following keys can be referenced using their KIDs.                 Table 6 VAS application key   Each key is linked to an error counter. This counter indicates authentication failures Register with the key of, and use after that when the limit entered in the counter is reached Ban.   The VAS container stores a personal identification number or password (PIN). This is VERIFY Used by order to identify the cardholder. PIN is connected to the error counter You. This counter registers erroneous input and inhibits the comparison of pIN when the limit is reached. Stop. This disabled state is reset by the system operator using appropriate management commands. it can. The counter is reset by entering the correct PIN.   There are the following parameters for the VAS container. These are the card platforms By the card issuer according to the available space on the team and the personal requirements of the issuer Can be selected.       ・ Maximum of p implementation class DF_PT Number of objects             = Application class "dot" that can be simultaneously loaded into the VAS container Maximum number of VAS applications for "number memory" and "ticket"               A maximum number of objects of the implementation class DF AD number             = Application class that can be simultaneously loaded into the VAS container Maximum number of VAS applications for "certificate certificate" and "data memory"       ・ NrDIR  Maximum integer of object: nrDIR= P + a Record in EF_DIR Number is nrDIRIs       ・ NrEF_TRANSFER  Number of records in ET_TRANSFER   The storage area required for the size of the elementary file is as follows.                                                 Number of bytes   VAS container EF ID 4   Global Day EF_DIR 9 * (p + a)   TA EF VERSION 1                          EF_SEQ 2                          Global key 64 + 2                          , PIN   Transfer field ER_TRANSFER 48 + nrER_TRANSFER   VAS provider EF_KEY (p + a) * 32   Exclusive data of EF_INFO (p + a) * 62                          EF_INTERNAL p * 10                          EF_VALUE p * 3   Parameters p, a and nrEF_TRANSFERFor example, if you select On the other hand, the following storage area is required (excluding auxiliary instruction storage area) ). Parameter Required area p = 8, a = 3, nrEF_TRANSFER= 15 2030 bytes p = 10, a = 5, nrEF_TRANSFER= 20 2758 bytes   The maximum required area is expected to be approximately 10% greater than the minimum required area.   Next, the command of the chip card according to the present invention will be described in detail.   The READ RECORD instruction is used to read data from a linear elementary file. used. The card sends the contents of the record in response. EF is short fire File identifier (SFI).   The status code "9000" indicates that the instruction has been executed normally. Excluding that The code indicates that an error has occurred.   The UPDATE RECORD instruction writes data to a record in a linear elementary file (EF). Used to remember. Command message to EF, record and data Including references.   The response from the card contains the status code. Status code "9000" is life Indicates that the order was executed successfully. Any other code indicates an error.   The GET CHALLENGE command requests a random number from the card. EXTERNAL AUTHENTICA random number Used for dynamic authentication in TE instructions.   The reply message from the card contains an 8-byte random number and a status code. S The status code "9000" indicates that the instruction was executed normally. Other Indicates an error.   The EXTRERNAL AUTHENTICATE command allows authentication of the terminal to the card. This life The order is within the scope of the VAS application, the system operator and the VAS provider. Used for authentication. EXTERNAL AUTHENTICATE transfers the cipher to the card . This code is generated by the terminal device encoding the random number in advance. Must be there. The card uses this cipher as a reference value calculated by the same method. Compare with If they match, the card authenticates the access condition for this key. Is recorded internally. If they are different, the card has the status "Authentication Is returned, and the internal error counter is decremented. The counter value is zero , All subsequent executions of EXTERNAL AUTENTICATE will have the status "Authentication prohibited." Is rejected.   The response information from the card includes a status code. Instructions regarding the card and If the authentication at the terminal is successfully executed, it is indicated by status code "9000". Is done. Any other code indicates an error.   The INTERNAL AUTHENTICATE instruction is used to check the authenticity of the VAS container at the terminal. Used for For this purpose, the card encrypts the data using reference data from the terminal device. calculate. The terminal generates its own code and compares it with the value from the card. these If they match, the terminal device recognizes the authenticity of the VAS container.   The response from the card for the execution of the command is a code and the status for the execution of the command. Including code. Successful execution of the instruction is indicated by status code "9000". It is. Any other code indicates an error.   The VERIFY command is used to verify the cardholder's PIN. This instruction is encoded Send the PIN data that has not been sent to the card. The card is a reference that stores the PIN data Compare with value. If the input data and the stored value are equal, access condition "PI N "is considered satisfactory.   The response information from the card for executing the command includes a status code. Stator The code "9000" indicates that the instruction was executed normally. Other codes Show the error.   The TRANSFER instruction creates an entry in the transfer (storage) area. This instruction has three types Is defined.       1. EF_VAL for applications of class "ticket" or "point score" An entry is created in the transfer area by subtracting the value in the UE field.       2. Creating a receipt in an application of class "Credential Certificate" Creates an entry in the transfer area.       3. By creating a certificate in an application of class "certificate", Make an entry in the transfer area.   This mode is automatically selected by the card. That is, the selected app If the instruction is executed in the application DF, first check whether EF_VALUE exists. Is done. If there is EF_VALUE, the card executes the instruction in mode 1; The instruction is executed in mode 2. Application DF must be selected in VAS container If so, mode 3 is used.   The terminal device supplies the following data to the card when calling the TRANSFER command.       ・ Latest data       .For entries in the transfer field (area)         Expiration date       ID for the terminal device that generated the entry       .User data for transfer fields       ・ PIX of VAS application (mode 3 only)       ・ Numerical unit of subtraction subtraction (only mode 1)       ・ MAC, serial number and VAS container number related to the above data.   The card executes the following sequence when calling the TRANSFER command.       1. Search for a free entry in the transfer area. (Overwrite existing entry In some cases, the priority is listed in the following list in descending order. That is, "Moved Entry, retrieved entry and expiration date, expiration date Expiration ”.       2. A PIX is added to data from the mode 1 and mode 2 terminal devices.       3. A serial number is assigned to the data from step 2.       4. Attach the VAS container ID to the data from step 3.       5. KGKDECUse PIX to encode PIX and KGKDEC, PIXGenerate       6. KGKDEC, PIXUse to encode the terminal ID and use KDEC Generate       7. Create a MAC using the data from step 4.       8. The MAC in step 7 is compared with the MAC from the terminal device. If they are different, The card discontinues this function and KGKDECDecrement the error counter for.       9. Mode 1: Numeric field in the register where the application is loaded Check the field EF_VALUE. If the number in this field is not enough, the card Discontinues this function immediately. If sufficient, the numeric fee in the application Subtract this number from the field.       Ten. Create instruction information.       11． Increment EF_SEQ by one.   Therefore, it is not necessary to display the data set in the response. In addition, the number of records May be assumed to be known.   The TAKE instruction provides the following modes.       • Move the data, and at the same time record that the data has become invalid.       • Move the data, but do not record that the data has become invalid. data Is kept more effective.   The command message contains the terminal ID, the PIX of the application, and the randomness generated by the terminal device. Including fields with numbers.   The PIX in the instruction indicates the application that moved the data. This has been moved Data set may differ from the PIX. This PIX is the dealer terminal that moved the data KDECUsed only for generating   The card response message is the record given in the transfer area command message. K about CSIG_VASCC with1, VAS container ID, C1Transfer data using K of activated terminal deviceDECC withTwoAnd a random number from the instruction message. The response message further includes a status code. Key KDECIs generated as above Is done. Cryptography and KDECThe credibility is implicitly proved by the VAS container using You. A proof of authenticity and a proof of uniqueness are calculated by cipher C (C is a serial number, Formed from the moved bits of the record in the send field and the VAS container ID. Because it is). This proof can be verified by the system operator.   The status code "9000" indicates that the instruction has been executed normally. Excluding that The code indicates the case of an error.   Where SO is AID according to IS0 / IEC 7816-5VASAnd request. See VAS RID 5 bytes long for systemVASAnd request.   AID of list DF_VASVASIs AIDVAS= RIDVASPIXDF_VASLet it be represented by   The command message includes, for example, expiration date, terminal ID, transaction data, Fields for operation mode (eg PIX in mode 3) and fields including encryption Consists of   The encryption is key KDECIs calculated using In this case, the data used for MAC formation is , For example, transaction data and terminal ID.   The response message of the TRANSFER instruction contains an 8-byte data file during normal execution. Field and a 2-byte status code "9000". Other status A response message with a code is considered an error. Response message data Data field is error-free (that is, in particular, Is correct), K in the instruction messageDECIncludes ciphers encoded with. This As a result, implicit (KAUTInstead of internal authentication by Proof of authenticity is made.   The TAKE instruction takes an object from the implementation class EF_TRANSFER. Used to launch. The execution of the TAKE instruction is technically the file EF_TRANSFER Is to read the record to be provided from. Where the record is the new entry Has enough storage for As long as the record (data set) is stored in the file, Only ". Technically, the TAKE instruction is used to retrieve the dataset Can be used, but according to the rules and regulations (R & R), Only VAS providers should use it.   The following items can be assumed for the data retrieval procedure. Get a certificate or receipt The VAS provider that wants to start searching for a suitable data set in the transfer area (for example, S Search using EEK instructions or by explicitly reading each record). In any case However, the data set is read and its contents are checked.   According to the rules and regulations (R & R), a 3-byte P IXAIs given, so that the AID in the VAS containerA= RIDVAS PIXAVAS app in Application can be uniquely identified. After selecting DF_VAS, VAS application A Select list <PIXAYou can select with>.   UPDATE KEY (KID, K) indicates a command that depends on the card platform. this Allows a key to be replaced with a new value K using the key identifier ID.   The card holder of the dealer terminal device checks the implementation class DF_PT or Or DF_AD (application class "point memory", "ticket", "credential book" Or VAS application from "data memory or database") Before the VAS application becomes available, the VAS application Must be loaded into the VAS container at the service terminal device. In principle Means that the card issuer receiving instructions from the VAS provider and the SO At the time of installation, one or more VAS applications have already been It is also possible to load it into the box. This loading procedure is the same as the procedure described here. This is a special case.   VAS application load progress       1. The card holder inserts the VAS card into the service terminal device.       2. The service terminal checks whether there is a VAS container.             ・ SELECT FILE <AIDVAS> (Error when VAS container is not selectable Reported).             ・ READ RECORD <SFI, O of EF_ID> (display of VAS container number).             Optionally, you can check the validity of the VAS container. This For this purpose, the service terminal requests internal authentication of the VAS container.             ・ INTERNAL AUTHENTICATE <random number, KAUTKID> service terminal returns Check answer and error   If (with error display), cancel the procedure. 3. The service terminal allows the cardholder to select a plurality of options. So One of them is "Loading VAS application". Card holders select. Then, in the service terminal device, all the VAS The application is displayed to the cardholder and awaits selection. Therefore, the operation “VA S application monitoring (browsing) "is started. Card holder is impressed Select VAS application A of the annotation class DF_pT or DF_AD. 4. The service terminal device operates the VAS content by selecting “VAS application”. Examine the PIX and select the PIXAVAS application with load already loaded in card Determine if it is. If present, an error signal is displayed. If not , An object of the appropriate implementation class for A is used in the VAS container. The availability is checked. This uses available records in EF_DIR (eg It is executed by searching (for example, by SEEK instruction). If there are no available records, -A report is made. Available If there is a code, this record indicates that the VAS application has not been loaded X FIDDF_Xincluding. 5. A to the next available object of the appropriate implementation class for V AS application A is loaded. For this purpose, the service terminal must first be turned off. Fline, two keys K from VAS provider (eg provider SAM)LVASpAnd KRVASP And assign those keys to the new VAS application.       ・ SELECT FILE <FIDDF X>       ・ GET CHALLENGE       ・ EXTERNAL AUTHENTICATE <KSO(Random number), KSOKID>       ・ UPDATE KEY <KLVASP, KLVASPKID>       ・ UPDATE KEY <KRVASP, KRVASPKID>       ・ GET CHALLENGE       ・ EXTERNAL AUTHENTICATE <KLVASP(Random number), KLVASPKID>       ・ UPDATE RECORD <EF_INFO SFI, data of DF_X>       ・ UPDATE RECORD <EF X INTERNAL SFI, data of DFX>       ・ Optional (initial signature): UPDATE RECORD                 <DF_X EF_VALUE SFI, data>     6. After the writing to the EF is completed normally, the service terminal device starts the operation “VAS Application <PIXA, FIDDF_X> Input. This application is DF_X to PIXAWith this, (SELECT FILE AIDVASAfter pre-selection by PIX)A SELECT FILE becomes possible using.   This mechanism made available by the transfer area, for example, without an occupied DF structure Depending on the VAS provider who wants to run the intra service or inter service Can be used. In addition, the cardholder, especially before using the VAS application, It is not necessary to load this application on the service terminal for the first time. No. On the contrary, the cardholder can send the certificate or receipt directly to the dealer terminal. Can be issued and refunded at another terminal device (by removal operation), or , A certificate or receipt can simply be presented (by manipulating the reading). did Therefore, the log of the VAS application of the implementation class ET TRANSFER The code is executed by implicit input of VAS data, or such The operation is performed (input of VAS data). In this regard, the impression See the description of "Acquisition" in the mention class ET_TRANSFER.   The progress of the entry operation of the VAS application will be described below.   When a VAS application is loaded into a VAS container, the application Which DF_X (X = PT1, .., PTp, AD1, ..., ADa) Or true The terminal device does not know the physical location of whether it has been loaded. Made of card From the point of view of the manufacturer, there are two possible implementation methods that can be checked separately. Note that ZK Compliance with the A (Central Card Committee) standard must be specifically observed. Case 1: Access to EF_DIR is possible. The following conditions must be satisfied.       AID is assigned to the FID of DF_X (eg under DF_VAS) EF_DIR is on the card platform as standard. VAS application in DF_X above Application actually exists.       -This DF_X can be read by anyone (READ RECORD AC: ALW).       ・ PIXAVAS application A with vacancy by system operator Is loaded into the active (unused) DF_X, When an entry is written to the temporary file DF_X (CREATE FILE ) Not!), File EF by UPDATE RECORD   _DIR is the entry PIXAOnly expanded. UPDATE RECORD is FIDXRefer to DF_X using Because it is shining. Therefore, the AC of UPDATE RECORD is key KSOBy outside Require authentication. • After DF_VAS has already been selected, the instruction SELECT FILE <PIXA> Is transferred to the card , DF_X loaded with VAS application A should be directly selectable . VAS application A loaded in DF_X and subsequent elementary files Must be erased at the service terminal at the request of the cardholder , The corresponding file is not deleted by DELETE FILE, but the written data is downloaded. It is just overwritten with the me value. Then, PIX from EF_DIRA(Strictly speaking, PIXAWhen A pair of references to DF_X) (eg, key KSOUPDATE RECORD after external authentication by ) Can be erased. -Since the number of DF_X is fixed, the number of records in EF_DIR can be known.     If these approaches can be realized, the following results will be obtained. ・ After selecting DF_VAS, SELECT FILE PIXATo quickly select a VAS application You can choose. Second case: EF_DIR cannot be accessed.   There is no EF_DIR available on the card platform, or as described above If neither read nor write access can be made to EF_DIR, then DF_VAS And the file EF_VASDIR must exist. EF_VASDIR contains system operations. (KsoUsing an explicit UPDATE RECORD instruction (after external authentication by And PIXAFrom the VAS application that loaded the data to the physical storage area in DF_X Link is generated. Reading and erasing records from EF_VASDIR is as described above. It shall be possible.   The operation "entry of the VAS application" is performed as follows.   PIXAVAS application A with FID in advanceDF_XLoaded into DF_X with . FIDDF_XAre recorded in the service terminal device.     1. SELECT FILE <AIDVAS> (Error reported when VAS container is not available Is).     2. GET CHALLENGE     3. EXTERNAL AUTHENTICATE <KSO(Random number), KSOKID>     4. UPDATE RECORD <SFI, FID of EF_DIR of DF_VASDF_x, PIXA, FIDDF_XWith number Record value>   VAS applications with implementation class DF PT or DF AD Service terminal equipment (under control of the system operator) at the request of the cardholder Can be erased only by VAS application of the implementation class EF_TRANSFER The solution can be deleted by anyone anywhere. In erasure, implementation Class DF_PT and DF AD VAS applications and implementations We must distinguish between the RAS TRANSFER VAS applications.   Erasure process of VAS application of the above implementation class DF_PT or DF_AD       1. The card holder inserts the VAS card into the service terminal device.       2. The service terminal checks whether there is a VAS container.       ・ SELECT_FILE <AIDVAS> (Error reported when VAS container is not available Is).       ・ READ REC0RD <EF_ID> (display of VAS container ID)       3. Service terminal allows cardholder to select multiple options ing. One of them is "delete VAS application". Card holder Chooses this. Then, all the implements loaded in the VAS container Te All VAS applications in the application class are displayed to the cardholder and selected. Wait for a choice. For this purpose, the operation "monitoring (viewing) of the VAS application" is started. It is. Card holder is AIDAWith the implementation class DF PT or DF_AD Select VAS application A. The object on which the VAS application was loaded The project is called DF_A. 4. After selecting DF_A, authentication of the service terminal device is performed.   ・ SELECT FILE <PIXA>   ・ GET CHALLENGE   ・ EXTERNAL AUTHENTICATE     <KSO(Random number), KSOKID> 5. This will erase the contents of the file from DF_A (EF_KEY, EF_INTERNAL and EF K for _VALUELVASPThese are initiated by the system operator because Will be erased).   ・ UPDATE KEY <KLVASPKID, “00 ... 00”>   ・ UPDATE KEY <KRVASPKID, “00 ... 00”>   ・ GET CHALLENGE   ・ EXTERNAL AUTHENTICATE     <KLVAS(Random number), KLVASKID>   -UPDATE RECORD <SFI of EF_INFO of DF_A, "00.             ..00 ”>           -UPDATE RECORD <EF_INTERNAL SFI of DF_A, “00 ... 00”>           -UPDATE RECORD <SFI of EF_VALUE of DF_A, “00 ... 00”>       6. After the writing to EF is completed normally, the terminal device then reads VA from EF_DIR. S Clear application entries.           ・ SELECT FILE <AIDVAS> (Error is reported when VAS container cannot be selected.) Will be notified)           ・ UPDATE RECORD <SFI, FID of EF_DIR_ of DF_VASDF_ARecord numerical values with , "00 ... 00", FIDDF_A>   PIXAThe link to DF_A is released in this way, so PIXAWith SELECT FILE Can no longer be performed.   Next, the implementation class EF_TRANSFER will be described.   VAS application of the implementation class EF TRANSFER is a card place At the request of the owner, the dealer terminal or service according to the rules and regulations (R & R) Erased by the service terminal (however, technically, either terminal is possible ). Deleting an object from EF_TRANSFER will delete the new object (eg (E.g. certificate or receipt) is empty in the transfer area to store This is especially necessary when there is no place to go. This erasure is always performed via the auxiliary instruction TAKE. It is done indirectly. This instruction marks the object as “moved”. It just works. Therefore, it can be overwritten by the following auxiliary instruction TRANSFER. is there. VAS application erase process       1. The card holder inserts the VAS card into the terminal device. This terminal is EF_TRAN The contents of SFER can be displayed (special operation of "monitoring (viewing) of VAS application") Case).       2. The terminal checks whether there is a VAS container.           ・ SELECT FILE <AIDVAS> (Error is reported when VAS container cannot be selected.) Will be notified)           ・ READ RECORD <SFI, 0 of EF_ID> (display of VAS container ID).       3. Service terminal allows cardholder to select multiple options ing. One of them is "delete VAS application". Card holder Chooses this. Then, at least, the implementation class EF_TRA All VAS applications in NSFER are displayed to the cardholder, waiting for a selection. This is realized as a special case of the operation "monitoring (viewing) of VAS applications" Is done. Card holder is a certificate Or an object of the implementation class EF_TRANSFER containing the receipt Select This object has a record number A. Card holder is optional Execute       4. The terminal marks the record with record number A as "retrieved". You. That is, the terminal device takes the A, the random number calculated by itself, the PIX and the terminal ID with the TAKE instruction. Transfer with.           ・ TAKE <A, random number, PIX, terminal ID>   The record marked "Retrieved" is now ready for a new certificate or receipt. Re-enabled for receipt.   Hereinafter, the progress of the VAS application selection will be described.   VAS application A of the implementation class DF PT or DF AD When loaded into the VAS container by the action "Load VAS application", This application can be selected in two steps by the terminal device. VAS Conte Na is selected first. Then PIXAIs selected.       1. SELECT FILE <AIDVAS> (Error is reported when VAS container cannot be selected.) Will be notified)             Service terminal equipment must verify the authenticity of VAS containers Can be inspected. For this purpose, the service terminal requests internal authentication of the VAS container. You.       ・ READ REC0RD <EF_ID SFI, 0> (display of VAS container ID)       ・ INTERNAL AUTHENTICATE <random number, KAUTKID>   The service terminal checks the response and if an error occurs (with an error indication) Cancel processing.       2. SELECT FILE <PIXA> (VAS application A loaded in VAS container Otherwise, an error is reported).   Dealer terminal equipment (KGKAUTCan not be used) the authenticity of VAS application A Inspection can be used to indirectly confirm the authenticity of the VAS container. The reason is that VAS app The application is responsible for checking the authenticity of the VAS container during the loading procedure. This is because it can be loaded only to the device. The credibility check of VAS application A is VAS container is key K for VAS application ALVASPOr KRVASPholding Can be attributed to testing at the dealer terminal device. This is like For example, the following inspection can be performed by a dealer terminal device.       ・ INTERNAL AUTHENTICATE             <Random number, KRVASPOr KLVASPKID>   To test whether VAS application A is loaded in the VAS container, Can be done by selecting . The error message in the SELECT FILE response message (display) indicates that the application It can be concluded that no A exists.   The selection of the VAS application of the implementation class EF TRANSFER Operation "monitoring (viewing) of VAS application" and storage of data in terminal device Is done implicitly. The terminal device displays the record number of each displayed object. Can be known from EF_TRANSFER, so by referring to the record number , Any object can be selected (for each record number) for subsequent processing.   Next, the progress of VAS application monitoring (browsing) will be described.   The operation "monitoring (viewing) of VAS applications" is an implementation RAS DF_PT, DF_AD All VAS applications of EF_TRANSFER to service terminal Display as a list. Implementation class EF for dealer terminals  Only VAS application of TRANSFER can be displayed. These applications This is because the option does not have access protection. Also, if the dealer terminal has read permission With (KRVASPApplication) Implementation class DF PT and DF AD application Options can also be displayed as options.   Progress of the above VAS application 1. Cardholders use VAS cards (chip cards with valid VAS containers) Insert into device. 2. The service terminal checks whether there is a VAS container.     ・ SELECT FILE <AIDVAS> (Error is reported when VAS container is not available ).     ・ READ REC0RD <EF_ID SFI, 0> (Display of VAS container ID)   Optionally check the validity of the VAS container. For this, service terminals The device requires internal authentication of the VAS container.     ・ INTERNAL AUTHENTICATE <random number, KAUTKID> service terminal checks response If an error occurs, stop the process (with an error display). 3. Service terminal allows cardholder to select multiple options . One of them is "monitoring (viewing) of VAS application". Card possession Chooses this. 4. The service terminal authenticates itself. ・ GET CHALLENGE ・ EXTERNAL AUTHENTICATE     <KSO(Random number), KSOKID> 5. Implementation classes DF PT and DF AD For each VAS application, depending on the contents of EF_DIR, Options are continuously selected and controlled. Key KSOEF_INFO after external authentication by (Or part of it according to rules and regulations) and the contents of EF_VALUE are displayed. ・ I = 0, ... nrDIRIf -1     ・ READ RECORD <EF_DIR SFI, i>           Response if no VAS application is loaded in the corresponding DF Message PIXAIs displayed as "00..00". READ RECORD from EF_DIR Alternatively, you can use the SEEK instruction in some cases.     ・ PIXAIs not "00..00"     -SELECTFILE <PIX. > ・ READ REC0RD <EF_INFO SFI, 0> -Display of response message (partial in some cases) ・ READ RECORD <SFI, 0 of EF_VALUE> ・ SELECT FILE <AIDVAS> 6. For VAS applications of the implementation class EF TRANSFER , The contents of EF_TRANSFER of each record (or one of EF_TRANSFER by rules and regulations) Part) is read. ・ SELECT FILE <AIDVAS> ・ I = 0, ... nrEF_TRANSFERIf -1       ・ READ RECORD <SFI, i of EF_TRANSFER>       (The response message contains the contents of the ith record of EF_TRANSFER)       • If the content is not zero, the content is interpreted (eg, Is expired) is displayed.   The dealer terminal has read permission (KRVASPOwnership) The monitoring (browsing) of the application of the class DF_PT and DF_AD is as described above. There are different cases. Only used by system operators for external authentication K that canSOInstead of key KRVASPIs used. Dealer terminal device is KAUTIn use If you want to check the authenticity of the VAS application even though you cannot The terminal device must be able to use (at least one) VAS application instead of internal authentication. Request authentication. This is the key K that the card corresponds to, as described above.RVASPMa Or KLVASPDone by knowing.   For a VAS application of the implementation class EF_TRANSFER, As described above, the contents of EF_TRANSFER of each record (or EF_TRS ANSFER) are listed consecutively.   The operation "interpretation of the VAS application" is executed in the same way. For this, the terminal The device works for the cardholder "VAS application interpretation" can be selected. Operation "monitoring (viewing)" EF_INFO and EF_V that need to be interpreted by the VAS provider in addition to the data displayed in Data from ALUE (eg, externally encoded data) and EF_I From NTERNAL (eg Miles & More Data (like the number of files) can also be displayed. However, this is because the VAS Only VAS applications where Ida has made the appropriate key available (at my discretion) Is possible. In order to read the application EF INTERNAL (outside Key K)LVASPis necessary. Elementary file EF INFO and EF VALUE And for externally encoded data in the transfer area EF_TRANSFER , Need the corresponding key of the VAS provider. The terminal program interprets the data The selected VAS application for which the application key for It can be easily determined using IX.   The operation "transfer of VAS application" is performed on the service Transfers all or selected VAS operations to the destination card It is to be. The condition at this time is that the VAS container of the transfer destination card is a VAS application. Application is not included, and after the transfer, all VAS applications The option is to be erased. In both conditions, the operation "Delete VAS application" Is continuously applied. In addition, the authenticity of both cards is checked. The destination card must have enough storage space. Transfer The work itself essentially extends the action "monitoring (viewing) of VAS applications" It is based on things and actions "Repeat application of VAS application loading" You. In the above monitoring (viewing) operation, data from EF_INTERNAL and key KLVASPAnd KRVASP Is further read.   Along with the VAS data, the VAS container ID is also transferred to the destination (target) card Therefore, the VAS application on the destination card is the same as on the source (source) card Can work like that. This is because the key generated by the VAS provider is Key, and those keys are copied without change This is because that. In addition, providers typically identify VAS cards by VAS container ID. And keep the accounting process in the background system as it is. Try to. It is important to note that the transfer of VAS container IDs must comply with this entire system. This is to delete only one number from the transfer source card in the system.   Elementary file EF_INTERNAL and key KLVASPAnd KRVASPSpecially read Service Terminal KSOExternal authentication (operation "delete VAS application" and Same), then key KLVASPOverwrite, then key KLVASPNew certification by You can transfer (overwrite) data from EF_INTERNAL after going to.   In addition to the VAS application of the implementation classes DF PT and DF AD , The file EF_TRANSFER must also be transferred (overwritten). To do this, The work "Move (Removal)" is executed continuously, and the "Retrieve" Move objects that are not marked "released" or "expired". Sign the object's signatureSIG_VASCInspect the object using the To the EF_TRANSFER of the host. However, these objects are not displayed on the destination card. Since the event is not marked as "removed", it remains valid.   Finally, the global data of the VAS container must be transferred. In particular, The sequence counter of the destination card must be set to the value of the source.   Next, the procedure for inputting VAS data will be described.   Depending on the type of VAS application, VAS data can be input at the dealer terminal device. Thus, three types of cases are possible.   First, in the case of the implementation classes DF_PT and DF_AD, Is explained.   The VAS provider provides VAS applications for the implementation classes DF_PT and DF_AD. Write data to the application. Input process of VAS data       1. The card holder inserts the VAS card into the dealer terminal device.       2. The dealer terminal checks whether there is a VAS container.       ・ SELECT FILE <AIDVAS> (Error reported when VAS container cannot be selected Is done).       ・ READ RECORD <SFI, 0 of EF_ID> (display of VAS container ID).       3. The authenticity of the VAS container is checked. The dealer terminal itself is the master Key KGKAUTIf this is the case, this dealer terminal will use the internal authentication of the VAS container. Can request.       ・ INTERNAL AUTHENTICATE             <Random number, KAUTKID>       (KGKAUTDealer terminal device does not have VAS application A) The credibility of the VAS container can be checked indirectly via credibility. The reason is that VAS The application checks the authenticity of the VAS container during loading. Only low Because you can do it. The credibility check of VAS application A is performed by VAS container Key K for application ALVASPAnd KRVASPIs included in the dealer terminal device Attribute it to testing. This is a dealer terminal device. Can be done. ・ SELECT FILE <PIXA> (VAS application A is not loaded in the VAS container If not, an error is reported.) ・ INTERNAL AUTHENTICATE       <Random number, KRVASPOr KLVASPKID>   The dealer terminal checks the response, and if an error occurs (error reported), processes it. Interrupt. 4. The dealer terminal selects VAS application A, authenticates itself, and executes the transaction. Describe the elementary file required to execute the operation. ・ SELECT FILE <PIXA> (Skip if already executed in step 3) ・ GET CHALLENGE ・ EXTERNAL AUTHENTICATE       <KLVASP(Random number), KLVASPKID> ・ Option: UPDATE RECORD <SFI of EF INFO of DFX, data> ・ Option: UPDATE RECORD <SFI of EF INTERNAL of DFX, data>       ・ Option: UPDATE RECORD <SFI of EF VALUE of DFX, data>   Next, the “acquisition” in the case of the implementation class EF_TRANSFER is described. Will be explained.   In particular, VAS applications (applications) of the implementation class EF_TRANSFER Application class “certificate”), the VAS provider There is no need to reserve a dedicated file structure DF_X for the application. As a result, the car The owner of the VAS application must use the VAS application certificate before using the certificate. There is no need to go to the service terminal to load. Just the card holder Issues a certificate or receipt directly from the dealer terminal and sends it to another terminal. Refund (reimbursement) (with action "Removal") or issue a certificate or receipt Can simply be presented (by reading). Implementation of VAS data A VAS application of the application class EF TRANSFER is implicitly loaded. this For each application class, whether it is an individual object of the type record There is an implementation class EF TRANSFER consisting of: EF_TRANSFER d Entries are only possible with the TRANSFER instruction. For this, the dealer terminal equipment The location is a valid ejection key KDECOwns the PIX of the VAS application AACan be used There must be. Input process of VAS data       1. The card holder inserts the VAS card into the dealer terminal device.       2. The dealer terminal checks whether there is a VAS container.       ・ SELECT FILE <AIDVAS> (Error reported when VAS container is not selectable Be done)       ・ READ RECORD <SFI, 0 of EF_ID> (Display of VAS container ID)       3. The dealer terminal reads the serial number. This number is It is assigned to MAC from step 4.       ・ READ RECORD <SFI, 0 of EF_SEQ> (display of serial number)       4. One record is written to EF_TRANSFER by the TRANSFER instruction.       ・ TRANSFER <Transaction data, expiration date, generated code, data, PIXA, KDECMAC with       5. The dealer terminal checks the response message of the TRANSFER command to determine the VA Check whether the S container is correct (ie, the common secret key KDECDo you have A) can be inspected. In this regard, refer to the already explained response message of the TRANSFER command. I want to be illuminated.   Finally, the acquisition by canceling the VAS data will be described.   The VAS provider cancels (cancels) using the TRANSFER instruction. The right (certificate or receipt) can be created in the transfer area EF_TRANSFER. This proof The letter or receipt can be further used by other VAS providers. data EF VALU for VAS application A by VAS provider to perform cancellation Canceled from E or EF_INFO. The card holder must have an object in EF_TRANSFER. This right is obtained in the form of a project. Progress of VAS data entry (input)       1. The card holder inserts the VAS card into the dealer terminal device.       2. The dealer terminal checks whether there is a VAS container.       ・ SELECT FILE <AIDVAS> (Error reported when VAS container is not available Is).       READ RECORD <EF_ID SFI, 0> (display of VAS container ID).       3. The dealer terminal reads the serial number. This number is It is assigned to MAC from step 4.       ・ READ RECORD <EF_SEQ SFI, 0> (sequential number display).       4. The dealer terminal selects the VAS application A.       ・ SELECT FILE <PIXA> (VAS application A loaded into VAS container If not, an error is reported.)       5. Dealer terminal cancels data from EF_VALUE or EF_INF0 Use TRANSFER to       ・ TRANSFER <data, KDECMAC with         The structure of the TRANSFER command message has already been described. Terminal device is KDECIn de If you can sign the data correctly, you have the right to cancel. This signature Is checked by the VAS container. If the check passes, the VAS container Therefore, one record is set in EF_TRANSFER, and the serial number is incremented. Is       6. The dealer terminal checks the response message of the TRANSFER command, , Whether the VAS container is correct (ie, the common secret key KDECPossess Can be inspected).   Here, the procedure for canceling the VAS data will be described. Two types of cancellation procedures There is   First, the implementation classes DF_PT and DF_AD VAS data for a given VAS application is provided by the corresponding VAS provider. Canceled by the action "Cancel", that is, VAS data Can be canceled by acquiring the data. This consumes one value (value) Potential rights to other values.   In other procedures, VAS data is taken once from EF_TRANSFER by the TAKE auxiliary instruction It is possible to take out. In this case, the right is consumed and the data is Marked in the transfer field for further use (for example, Refunded tickets are still needed for return) You. This means that this data will be overwritten by other objects when needed. Will be kept until done. Progress of cancellation of VAS data by TAKE instruction       1. The card holder inserts the VAS card into the dealer terminal device.       2. The dealer terminal checks whether there is a VAS container.       ・ SELECT FILE <AIDVAS> (Error is reported if VAS container is not selectable Will be announced).       ・ READ RECORD <SFI, 0 of EF_ID> (display of VAS container ID).       3. First, the dealer terminal operates the VAS app. Objects that can be used using the special case of From EF_TRANSFER to determine if the object being sought was sought You. Alternatively, you can search for samples using the SEEK instruction. The above process If successful, the terminal recognizes the number i of the detected record.       4. The terminal device uses the TAKE instruction to generate the number i, the random number calculated by itself, Sends the PIX and ID of the user, and marks the record with record number i as "moved" I can.       ・ TAKE <i, random number, PIX, terminal ID>   The dealer terminal issues a TAKE instruction to read data from EF_TRANSFER. use. In this instruction, at the same time as the processing, the data is marked as “moved”. wear. By executing the TAKE instruction, two different ciphers C1And CTwoIs generated.   Cryptography C1Is the key KSIG_VASCCalculated by VAS container using. This , C1The creator of this retrieved object, signed at Proof of uniqueness (of the process) and authenticity can be obtained from the data. transaction The uniqueness and authenticity of the object originated (checked by card (See TRANSFER)) VAS provider encryption and transaction The value of the sequence counter for the application Cryptography C1It turns out from.   Cryptography CTwoThe VAS container is KGKDECK generated using, PIX and terminal IDDEC Is calculated by the VAS container using Common secret key KDECBecause I know The VAS container can directly prove the authenticity of the VAS container itself to the terminal device. Even in the TRANSFER order, only the correct certificate or receipt is in the correct VAS container. Since the memorization is checked in the same way, the Can conclude credibility. Cryptography CTwoIs the serial number, extraction bit, and VAS container ID Since the VAS container is generated indirectly from the Uniqueness can also be proved to the terminal device.   "Eject" processing using the TAKE instruction is permitted by anyone.   Furthermore, in service terminal equipment, the implementation classes DF PT and D For reading FAD VAS application, password or PIN protection Can be activated or activated. The VAS container PIN is a car that knows the PIN. Can be changed by theSOSystem authentication by external authentication using Can be restored by a perlator. PIN or password of any length Non-numeric signs or those Can be used.

【手続補正書】特許法第１８４条の８第１項 【提出日】１９９８年１２月１１日（１９９８．１２．１１） 【補正内容】 請求の範囲 １．トランザクション実行のためのチップカードにおいて、該トランザクション では金銭的価値単位または他の非金銭的権利を表す価値データがカード所持者と 少なくとも一つのトランザクションパートナ（サービスプロバイダ）との間で転 送されるか、または該サービスプロバイダに該権利の検証のために提示され、前 記チップカードは該トランザクションの実行に必要なデータを記憶するための記 憶装置を含むものであって、前記チップカードはさらに、 各々特定のサービスプロバイダにそれぞれ割り当てられた一または複数のカー ドアプリケーション（VASアプリケーション）であって、各々が該カード所持者 と該アプリケーションに割り当てられたサービスプロバイダとの間でトランザク ションの実行を可能にするアプリケーションを、カード上にロードするための手 段と、 異なるサービスプロバイダ間のトランザクション実行にさいして交換または提 示される金銭的価値単位または非金銭的権利を表すデータを収容するためのサー ビスプロバイダに非占有の転送記憶領域（EF_TRANSFER）と、 書き込み命令（TRANSFER）に応答して前記転送記憶 領域にデータを書き込むための手段とを含むことを特徴とするチップカード。 ２．前記ロード手段は、 該手段内部に記憶されたデータ構造（DF_VAS，VASコンテナ）を含み、前記デ ータ構造は、 その中に該カード所持者とサービスプロバイダとの間でのトランザクション実 行を可能にするために必要なデータ（VASデータ）をロードできる部分構造（DF_ PT，DF_AD，VASアプリケーション）と、 前記部分構造（VASアプリケーション）内に記憶されたデータの種類および／ または構造に関する情報を含む定義データセットとを含み、前記定義データセッ トはさらに、 前記データ構造（VASコンテナ）および／または前記チップカードを同定する 識別子（コンテナID）と、前記定義データセットおよび／または前記データ構造 （VASコンテナ）の整合性が変更されないことを保証する少なくとも一つのシス テムキー（KSO）とを含むことを特徴とする請求の範囲第１項に記載のチップカ ード。 ３．前記カードは、 トランザクション実行に必要なデータを、少なくとも一つのシステムキーを使 用して前記部分構造にロードするための手段、 前記部分構造にロードされたデータに前記定義データセットのデータを適応さ せるために、前記定義データセットにデータを書き込むための手段、 トランザクション実行に必要なデータをロードできるさらなる部分構造を前記 カードの前記記憶装置内に生成するための手段、および／または 前記カード上で動的にメモリー管理をするための手段、 のうちの少なくとも一つの特徴を含むことを特徴とする請求の範囲第１項また は第２項に記載のチップカード。 ４．前記部分構造（VASアプリケーション）は、各々特定のサービスプロバイダ に割り当てられた互いに独立した複数の部分構造であり、 前記定義データセットは少なくとも一つのシステムキー（KSO）によって変更 から保護されていて、該シヌテムキーよってのみ変更可能であり、 前記データ構造（VASアプリケーション）のロードは前記定義データセットに 含まれるシステムキーを使用してのみ実行できることを特徴とする請求の範囲第 １項から第３項のうちのいずれか一項に記載のチップカード。 ５．請求の範囲第１項から第４項のいずれか一項に記載のチップカードにおいて 、 前記定義データセットはさらに以下の特徴の少なくとも一つを含む： 端末装置に対して前記チップカードの権限の認証のためのおよび／または前記 チップカードに対して端末装置の権限の認証のための少なくとも一つの認証キー （KAUT）、 前記転送領域から取り出されたデータの署名のための少なくとも一つの署名キ ー（KSIG_VASC）、 前記転送領域内の書き込み手続きおよび／または価値データのキャンセル（無 効化）の権限の検証のための、端末装置またはアプリケーション特有のキーを生 成するためのキー生成キー（KGKDEC）、 カード所持者によるトランザクション手続きの権限を検証するためのPIN、 前記システムキー（KSO）、前記認証キー（KAUT）、前記署名キー（KSIG_VASC ）および前記キー生成キー（KGKDEC）は、カードに特有であるか、データ構造（ DF_VAS）に特有であるかということ、および 前記部分構造（VASアプリケーション）が少なくとも以下の特徴の一つを持つ こと； 価値データを収容するための少なくとも一つの数値記憶域（EF_VALUE）、 前記部分構造に関連した内部データを収容するための少なくとも一つの内部記 憶域（EF_INTERNAL）、 前記部分構造に関連した非内部データを収容するための少なくとも一つの情報 記憶域（EF_INFO）、および 前記数値記憶域および／または前記内部記憶域および／または前記情報記憶域 への／からの書き込み手続きおよび／または読み出し手続きに関する機密保持を する少なくとも一つのキー（KLVASP，KRVASP）を収容するためのキー記憶域（EF _KEY）；前記チップカードはさらに、 前記数値記憶域および／または前記内部記憶域および／または前記情報記憶域 への／からの書き込みおよび／または読み出しのための手段を含み；前記ロード するための手段は、 前記少なくとも一つのシステムキーの保護の下で、前記キー記憶域に前記キー を書き込むための手段を含む。 ６．請求の範囲第１項から第５項のいずれか一項に記載のチップカードにおいて 、前記部分構造は以下の特徴の少なくとも一つを含む： 前記部分構造内にデータを書き込む権限があるかを検証するためのキー（KLVA SP ）、および 前記部分構造内からデータを読み出す権限があるかを検証するためのキー（KR VASP ）。 ７．前記キー記憶域に記憶されたキーは各部分構造に 特有であり、 前記少なくとも一つの部分構造（VASアプリケーション）は、少なくとも一つ の前記特有のキー（KLVASP,KRVASP）によってトランザクションの実行を保護し 、前記キーは、前記各部分構造（VASアプリケーション）に特有であり、かつ他 の前記各部分構造（VASアプリケーション）の前記キーから独立していることを 特徴とする請求の範囲第１項から第６項のいずれか一項に記載のチップカード。 ８．前記カードは複数個の前記部分構造（VASアプリケーション）を含み、前記 部分構造の各々は特定のサービスプロバイダと前記カード保持者との間でのトラ ンザクション実行に使用され、 前記トランザクション実行は、転送記憶領域への／からのデータの書き込みお よび／または読み出しおよび／または前記数値記憶域への／からのデータの書き 込みおよび／または読み出しを含むことを特徴とする請求の範囲第１項から第７ 項のいずれか一項に記載のチップカード。 ９．個々の部分構造（VASアプリケーション）間および部分構造とサービスプロ バイダとの間でトランザクションを実行するための手段をさらに含むことを特徴 とする請求の範囲第１項から第８項のいずれか一項に記載のチップカード。 10．前記システムキー（KSO）はシステムオペレータ（SO）のみに知られていて 、カードに特有で、および／またはデータ構造（VASコンテナ）に特有のキーで あり、 前記定義デーセット内に含まれる他のキーは、カードに特有で、および／また はデータ構造（VASコンテナ）に特有なキーであることを特徴とする請求の範囲 第１項から第９項のいずれか一項に記載のチップカード。 11．請求の範囲第１項から第10項のいずれか一項に記載のチップカードにおいて 、前記定義デーセットが以下の特徴のうちの一または複数を持つことを特徴とす るチップカード： 前記データ構造に特有な識別番号（EF_ID）、 前記データ構造に含まれる部分構造（EF_DIR）のディレクトリであって、前記 データ構造（VASコンテナ）にロードされた部分構造（VASアプリケーション）に 特有な識別番号と、前記部分構造（VASコンテナ）内の、前記部分構造（VASアプ リケーション）が物理的に記憶された部分に関する情報とを含むディレクトリ、 および 前記データ構造（EF_VERSION）のバージョンナンバ。 12．請求の範囲第１項から第11項のいずれか一項に記 載のチップカードにおいて、前記カードは以下の特徴の少なくとも一つを持つ： 前記転送記憶領域からデータを取り出しおよび／またはキャンセルする取り出 し手続き（TAKE）を実行するための手段、および 前記転送記憶領域からデータを取り出しおよび／またはキャンセルするさい、 該データについての一つまたは複数の信憑性特徴を生成するための手段。 13．信憑性特徴を生成するために、 該取り出されたデータに関するディジタル署名を生成するための署名キー（KS IG_VASC ）と、 前記ディジタル署名を生成するためにも使用される、前記トランザクションの 特性を表すトランザクション番号を生成するための手段とを含むことを特徴とす る請求の範囲第１項から第12項のいずれか一項に記載のチップカード。 14．前記署名キー（KSIG_VASC）は、プライベートのキー生成キーから生成され たプライベートキーであり、サービスプロバイダによる前記署名の検証のために 公開キーが使用されることを特徴とする請求の範囲第１項から第13項のいずれか 一項に記載のチップカード。 15．請求の範囲第１項から第14項のいずれか一項に記載のチップカードにおいて 、前記カードは以下の特徴の少なくとも一つを持つ： 前記キー生成キー（KGKDEC）を用いて端末装置および部分構造に特有なキー（ KDEC）を生成するための手段、ならびに 以下の特徴の少なくとも一つを使ってトランザクションの認可および／または 保護を検証するための手段， 前記端末装置および部分構造に特有なキー（KDEC）、 少なくとも一つの前記認証キー（KAUT）、 少なくとも一つの前記システムキー（KSO）、 少なくとも一つの前記部分構造特有キー（KLVASP，KRVASP）、 前記署名キー（KSIG_VASC）、 前記PIN、 部分構造の前記識別子、および 前記端末識別子。 16．請求の範囲第１項から第15項のいずれか一項に記載のチップカードにおいて 、前記カードはさらに以下の特徴の少なくとも一つを持つ： 読み出しまたは書き込み手続きを始める前に、前記認証キーを用いて前記認可 および／または前記端末装置の認証をするための手段、および デジタル署名および／またはキー形成（エンコード）によって保護されている 読み出しまたは書き込み手続きを実行するための手段。 17．請求の範囲第１項から第16項のいずれか一項に記載のチップカードにおいて 、前記カードはさらに以下の特徴の少なくとも一つを持つ： 前記PIN保護を活性化および不活性化するための手段、および 前記PINを変更するための手段。 18．請求の範囲第１項から第17項のいずれか一項に記載の前記データ構造は前記 カードプラットフォームから独立しており、前記カードはさらに、 前記データ構造または前記データ構造の一部を他のカード上に転送するための 手段を含むことを特徴とする請求の範囲第１項から第17項のいずれか一項に記載 のチップカード。 19．サービスプロバイダの非占有記憶領域であって、異なるサービスプロバイダ によって該領域へ／からデータを書き込み／読み込みして、異なるサービスプロ バイダ間で金銭的価値単位および／または他の非金銭的権利を表す価値データを 転送するための記憶領域を含むことを特徴とするチップカード。 20．請求の範囲第１項から第19項のいずれか一項に記載のチップカードを使用す るための端末装置であって、前記端末装置は、 前記チップカードのデータ構造（VASコンテナ）の識別と、前記データ構造を 識別する識別子（コンテナ ID）の識別とをするための手段を含み、 前記端末装置はさらに以下の特徴の少なくとも一つを持つ： 少なくとも前記部分構造の一つおよび／または前記定義データセットおよび／ または前記カードの転送記憶領域からデータを読み出すための手段、 前記カードの転送記憶領域にデータを書き込むための手段、および トランザクション実行に必要なデータを前記カードの少なくとも一つの部分構 造（VASアプリケーション）にロードするための手段。 21．請求の範囲第20項に記載の端末装置において、前記端末装置はさらに以下の 特徴の少なくとも一つを持つ： サービス端末装置と前記カード所持者との間でトランザクションを実行するた めの手段、該トランザクションの実行は以下のステップの少なくとも一つを含む ； 前記数値記憶域にデータを書き込むステップ、 前記転送記憶域にデータを書き込むステップ、 前記転送記憶域からデータを取り出すおよび／またはキャンセルするステップ 、 前記部分構造からデータを読み出すステップ、および 前記転送記憶域からデータを読み出すステップ。 22．請求の範囲第20項または第21項に記載の端末装置において、端末装置はさら に、 以下の特徴の少なくとも一つを用いてトランザクションの認可および／または 保護の検証をするための手段を含む； 前記端末装置および部分構造に特有なキー（KDEC）、 カードに特有のまたはデータ構造（DF_VAS）に特有の少なくとも一つの認証キ ー（KAUT）、 カードに特有のまたはデータ構造（DF_VAS）に特有の少なくとも一つのシステ ムキー（KSO）、 少なくとも一つの部分構造特有キー（KLVASP，KRVASP）、 カードに特有の、またはデータ構造（DF_VAS）に特有の少なくとも一つの署名 キー（KSIG_VASC）、 カードに特有の、またはデータ構造（DF_VAS）に特有のPIN、 部分構造のアプリケーションに特有の識別子、および 端末装置に特有な識別子。 23．データを前記転送記憶領域に書き込むための手段が、 書き込み権の証明のために、端末装置および部分構造に特有のキー（KDEC）を 使用してデータからキー作成（エンコード）するための手段を含むことを特徴と す る請求の範囲第20項から第22項のいずれか一項に記載の端末装置。 24．データの取り出しおよび／またはキャンセルされる前記転送記憶領域からの データの取り出し手続きを実行するための手段を含むことを特徴とする請求の範 囲第20項から第23項のいずれか一項に記載の端末装置。 25．請求の範囲第20項から第24項のいずれか一項に記載の端末装置において、前 記端末装置はさらに以下の特徴の少なくとも一つを持つ： 前記転送記憶領域のデータに「取り出し済み」と特徴づけるための手段、およ び 前記転送記憶領域のデータに「期限切れ」と特徴づけるための手段。 26．請求の範囲第20項から第25項のいずれか一項に記載の端末装置において、前 記トランザクション実行のための手段はさらに以下の特徴の少なくとも一つを持 つ： 前記部分構造内の価値データを変更するための手段、および カード所持者の費用で、カード所持者の利益のために、異なるサービスプロバ イダ間のトランザクション（インターサービス）を実行するための手段。 27．少なくとも一つの認証キーを使用して、前記カー ドに対して前記端末装置の権限をおよび／または前記端末装置に対して前記カー ドの権限を認証するための手段と、 PINを用いて前記カード保持者によるトランザクションを保護するための手段 と、 PIN保護の活性化および非活性化を行うための手段を含むことを特徴とする請 求の範囲第20項から第26項のいずれか一項に記載の端末装置。 28．請求の範囲第20項から第27項のいずれか一項に記載の端末装置において、前 記端末装置はさらに以下の特徴の少なくとも一つを持つ： 端末装置に特有な識別子を前記カードに転送するための手段、 前記部分構造に特有な識別子を前記カードに転送するための手段、 端末装置および部分構造に特有なキーならびに該端末装置および部分構造に特 有な識別子を使用して、前記権限を認証するための手段、ならびに ディジタル署名および／またはキー作成（エンコード）で保護される読み出し または書き込み手続きを実行するための手段。 29．請求の範囲第20項から第28項のいずれか一項に記載の端末装置において、前 記端末装置はさらに以下の特徴の少なくとも一つを持つ： 部分構造（VASアプリケーション）を選択するための手段、 前記端末装置において部分構造を監視（閲覧）するための手段、 前記端末装置において部分構造データを監視（閲覧）するための手段、 前記カードに部分構造（VASアプリケーション）をロードするための手段、 ロードされた部分構造（VASアプリケーション）の識別子を前記カードにロー ドするための手段、 前記カードから部分構造を消去するための手段、 ある部分構造を他の部分構造で置換するための手段、 ある部分構造を他のカードに転送するための手段、ならびに 部分構造を該部分構造の機能と該部分構造に関連するサービスプロバイダとに 関して解釈し、該部分構造に記憶された情報を読み出して監視（閲覧）するため の手段。 30．チップカードと端末装置を使用してカード所持者と少なくとも一つのサービ スプロバイダとの間におけるトランザクションを実行する方法であって、前記方 法は以下のステップの一つを含む： 該チップカードに記憶されたデータ構造を準備する ステップ；該データ構造には、該チップカードとサービスプロバイダとの間のト ランザクション実行を可能にするために、該サービスプロバイダに割り当てられ たカードアプリケーション（VASデータ）のデータがロードされる、 該サービスプロバイダと該カード所持者の間でトランザクション実行をするた めに、該データ構造（VASアプリケーション）へ／からデータを書き込むまたは 読み込むステップ、 サービスプロバイダの非専用の転送記憶域（ET_TRANSFER）であって、異なる サービスプロバイダ間で該トランザクション実行時に交換または提示される金銭 的価値単位または非金銭的権利を表すデータを収容するための転送記憶域を準備 するステップ、および 該転送記憶域へ／から、データを書き込むまたはデータを読み込むステップ。 31．請求の範囲第30項に記載の方法において、前記方法はさらに以下のステップ の少なくとも一つを含む： 請求の範囲第１項から第19項に記載のチップカード を使用するステップ、 請求の範囲第20項から第29項に記載の端末装置を使用するステップ、および 前記部分構造（VASアプリケーション）のうちの少なくとも一つの前記数値記 憶域、内部記憶域または情 報記憶域へ／からデータを書き込むまたは読み込むステップ。 32．請求の範囲第30項または第31項に記載の方法において、前記方法はさらに以 下のステップの少なくとも一つを含む： 少なくとも一つのキーを使用して前記端末装置および／または前記チップカー ドの権限を認証するステップ、ならびに 少なくとも一つのキーを用い、ディジタル署名および／またはキー作成（エン コード）によりトランザクションを保護するステップ。 33．端末装置を使用してチップカードにデータをロードするための方法において 、前記方法はさらに以下のステップの少なくとも一つを含む： 該カードの部分構造（VASアプリケーション）にデータをロードするステップ 、および 該カードの該定義データセットにデータを書き込むステップ；前記方法は以下 のステップの少なくとも一つを含む； 請求の範囲第１項から第19項に記載のチップカードを使用するステップ、およ び 請求の範囲第20項から第29項に記載の端末装置を使用するステップ。 34．請求の範囲第１項から第19項に記載のチップカー ドを使用し、請求の範囲第20項から第29項に記載の端末装置を使用することを特 徴とするトランザクション実行方法。[Procedure of Amendment] Article 184-8, Paragraph 1 of the Patent Act [Submission date] December 11, 1998 (1998.12.11) [Correction contents]                               The scope of the claims 1. In a chip card for executing a transaction, the transaction The value data representing monetary value units or other non-monetary rights is Transfer with at least one transaction partner (service provider) Sent to or presented to the service provider for verification of the rights, The chip card is used to store data necessary for executing the transaction. Memory device, wherein the chip card further comprises:   One or more cars, each assigned to a particular service provider Applications (VAS applications), each of which is the card holder Transaction between the service provider assigned to the application A method for loading an application that allows the application to run on the card. Steps and   Exchange or offer to execute transactions between different service providers A service to contain data representing the indicated monetary value unit or non-monetary right A transfer storage area (EF_TRANSFER) not occupied by the service provider,   The transfer storage in response to a write command (TRANSFER) Means for writing data to the area. 2. The loading means,   A data structure (DF_VAS, VAS container) stored inside said means, The data structure is   In which the transaction between the cardholder and the service provider is performed. A substructure (DF_) that can load the data (VAS data) needed to enable the row PT, DF_AD, VAS application)   The type of data stored in the partial structure (VAS application) and / or Or a definition data set containing information about the structure, Furthermore   Identify the data structure (VAS container) and / or the chip card An identifier (container ID) and the definition data set and / or the data structure (VAS container) at least one system to ensure that the integrity of the Temukey (KSO2. The chip cap according to claim 1, further comprising: Mode. 3. The card is   Use at least one system key to store data required to execute a transaction. Means for loading said substructure using   Adapting the data of the definition data set to the data loaded in the substructure Means for writing data to the definition data set,   Additional substructures that can load the data needed to execute the transaction Means for generating in said storage of a card, and / or   Means for dynamically managing memory on the card,   Claims 1 or 2 comprising at least one of the following features: Is a chip card according to item 2. 4. Each of the partial structures (VAS application) has a specific service provider. A plurality of independent substructures assigned to   The definition data set has at least one system key (KSOChanged by) Is protected from, and can be changed only by the synute key,   Loading of the data structure (VAS application) is performed in the definition data set Claims characterized by being able to be executed only using the included system key 4. The chip card according to any one of items 1 to 3. 5. The chip card according to any one of claims 1 to 4, wherein ,   The definition dataset further includes at least one of the following features:   For authentication of the authority of said chip card to a terminal device and / or At least one authentication key for authenticating the authority of the terminal device to the chip card (KAUT),   At least one signature key for signing data retrieved from the transfer area; ー (KSIG_VASC),   Write procedure and / or cancellation of value data in the transfer area (no Terminal or application-specific key to verify the Key (KGK)DEC),   A PIN to verify the authorization of the cardholder for the transaction,   The system key (KSO), The authentication key (KAUT), The signature key (KSIG_VASC ) And the key generation key (KGK)DEC) Is specific to the card or has a data structure ( DF_VAS), and   The partial structure (VAS application) has at least one of the following features: thing;   At least one numeric storage (EF_VALUE) to hold value data,   At least one internal record for containing internal data related to said substructure Storage (EF_INTERNAL),   At least one information for accommodating non-internal data related to the partial structure Storage (EF_INFO), and   The numerical storage area and / or the internal storage area and / or the information storage area Confidentiality of write and / or read procedures to / from At least one key (KLVASP, KRVASPKey storage (EF) _KEY); The chip card further comprises:   The numerical storage area and / or the internal storage area and / or the information storage area Including means for writing to and / or reading from / to the load; The means for doing   Storing the key in the key storage under the protection of the at least one system key; Including means for writing. 6. The chip card according to any one of claims 1 to 5, Wherein the partial structure includes at least one of the following features:   Key (K) to verify that you have permission to write data in the substructureLVA SP ),and   Key (KR VASP ). 7. The key stored in the key storage area is Peculiar,   The at least one partial structure (VAS application) includes at least one The unique key (KLVASP, KRVASP) Protects the execution of the transaction by , The key is specific to each substructure (VAS application) and That each of the substructures (VAS application) is independent of the key The chip card according to any one of claims 1 to 6, characterized in that: 8. The card includes a plurality of the partial structures (VAS applications), Each of the substructures is a transaction between a particular service provider and the cardholder. Used to execute the transaction,   The transaction execution includes writing data to / from the transfer storage area and And / or reading and / or writing data to / from said numerical storage 7. The method according to claim 1, further comprising: The chip card according to any one of the above items. 9. Between individual substructures (VAS applications) and between substructures and service providers Further comprising means for executing a transaction with the binder. The chip card according to any one of claims 1 to 8, wherein Ten. The system key (KSO) Is known only to the system operator (SO) With keys that are specific to the card and / or specific to the data structure (VAS container) Yes,   Other keys included in the definition dataset are card-specific and / or Is a key specific to a data structure (VAS container). 10. The chip card according to any one of items 1 to 9. 11． The chip card according to any one of claims 1 to 10, Wherein the definition dataset has one or more of the following features: Chip card:   An identification number (EF_ID) unique to the data structure,   A directory of a partial structure (EF_DIR) included in the data structure, In the partial structure (VAS application) loaded in the data structure (VAS container) A unique identification number and the substructure (VAS app) within the substructure (VAS container) Application) contains information about the physically stored part, and   Version number of the data structure (EF_VERSION). 12． Any one of claims 1 to 11 In the above chip card, the card has at least one of the following features:   Retrieving and / or canceling data from the transfer storage area Means for performing the TAKE procedure, and   Retrieving and / or canceling data from said transfer storage area; Means for generating one or more authenticity features for the data. 13. To generate authenticity features,   A signature key (K) for generating a digital signature for the retrieved dataS IG_VASC )When,   Of the transaction, which is also used to generate the digital signature. Means for generating a transaction number representing the characteristic. The chip card according to any one of claims 1 to 12, wherein: 14. The signing key (KSIG_VASC) Is generated from a private key generation key Private key for the service provider to verify the signature. 14. A method according to claim 1, wherein a public key is used. The chip card according to claim 1. 15． The chip card according to any one of claims 1 to 14, The card has at least one of the following features:   The key generation key (KGKDEC) Using a key specific to the terminal device and the substructure ( KDECMeans for generating   Authorize transactions and / or use at least one of the following features: Means to verify protection,   A key (KDEC),   At least one of the authentication keys (KAUT),   At least one of the system keys (KSO),   At least one of said substructure-specific keys (KLVASP, KRVASP),   The signing key (KSIG_VASC),   Said PIN,   Said identifier of a substructure; and   The terminal identifier. 16． The chip card according to any one of claims 1 to 15, The card further has at least one of the following features:   Before starting the read or write procedure, use the authentication key to And / or means for authenticating the terminal device, and   Protected by digital signature and / or keying (encoding) A means for performing a read or write procedure. 17． The chip card according to any one of claims 1 to 16, The card further has at least one of the following features:   Means for activating and deactivating said PIN protection; and   Means for changing the PIN. 18． The data structure according to any one of claims 1 to 17, wherein Independent of the card platform, said card further   For transferring said data structure or a part of said data structure onto another card 18. A method according to any one of claims 1 to 17, characterized by including means. Chip card. 19. The service provider's unoccupied storage area, which is different from the service provider Write / read data to / from the area by different service Value data representing monetary value units and / or other non-monetary rights between A chip card including a storage area for transfer. 20. Use of the chip card according to any one of claims 1 to 19 Terminal device for the, the terminal device,   Identification of the data structure (VAS container) of the chip card, and Identifier to identify (container ID) and means for identifying   The terminal further has at least one of the following features:   At least one of the substructures and / or the definition data set and / or Or means for reading data from the transfer storage area of the card,   Means for writing data to a transfer storage area of the card, and   Data necessary for executing a transaction is stored in at least one partial structure of the card. The means to load into the structure (VAS application). twenty one. The terminal device according to claim 20, wherein the terminal device further comprises: Has at least one of the features:   For executing a transaction between the service terminal device and said cardholder Means for executing the transaction includes at least one of the following steps: ;   Writing data to the numeric storage area;   Writing data to the transfer storage area,   Retrieving and / or canceling data from the transfer storage ,   Reading data from the substructure; and   Reading data from the transfer storage area. twenty two. 22. The terminal device according to claim 20, wherein the terminal device further comprises: To   Authorize transactions and / or use at least one of the following features: Including means for verifying protection;   A key (KDEC) specific to said terminal device and substructure,   At least one authentication key specific to the card or specific to the data structure (DF_VAS) ー (KAUT),   At least one system specific to the card or specific to the data structure (DF_VAS) Mukey (KSO),   At least one substructure-specific key (KLVASP, KRVASP),   At least one signature specific to the card or specific to the data structure (DF_VAS) Key (KSIG_VASC),   PIN specific to the card or specific to the data structure (DF_VAS),   An identifier unique to the substructured application; and   An identifier unique to the terminal device. twenty three. Means for writing data to the transfer storage area,   For proof of write permission, a key (KDEC) Including means for generating (encoding) keys from data using You The terminal device according to any one of claims 20 to 22, wherein the terminal device comprises: twenty four. Data from the transfer storage area being retrieved and / or canceled Claims comprising means for performing a data retrieval procedure. 24. The terminal device according to any one of items 20 to 23. twenty five. The terminal device according to any one of claims 20 to 24, wherein The terminal further has at least one of the following features:   Means for characterizing the data in the transfer storage area as "retrieved"; And   Means for characterizing the data in the transfer storage area as "expired". 26. The terminal device according to any one of claims 20 to 25, wherein The means for executing a transaction further has at least one of the following features. One: Means for changing value data in the substructure; and   Different service providers at the expense of the cardholder and for the benefit of the cardholder A means for executing a transaction (interservice) between Ida. 27. Using at least one authentication key, the car The authority of the terminal device to the terminal and / or the card to the terminal device. Means for authenticating the authority of the   Means for protecting transactions by said cardholder using a PIN When,   A contract including means for activating and deactivating PIN protection. 27. The terminal device according to claim 20, wherein the terminal device is a terminal device. 28. The terminal device according to any one of claims 20 to 27, wherein The terminal further has at least one of the following features:   Means for transferring an identifier unique to a terminal device to the card,   Means for transferring an identifier unique to said partial structure to said card;   Keys specific to terminal devices and substructures and keys specific to the terminal devices and substructures Means for authenticating said authority using a unique identifier; and   Read protected with digital signature and / or key generation (encoding) Or a means for performing a write procedure. 29. The terminal device according to any one of claims 20 to 28, wherein The terminal further has at least one of the following features:   Means for selecting a substructure (VAS application),   Means for monitoring (viewing) a partial structure in the terminal device;   Means for monitoring (viewing) partial structure data in the terminal device;   Means for loading a partial structure (VAS application) on said card;   The identifier of the loaded partial structure (VAS application) is loaded into the card. Means to do   Means for erasing a partial structure from said card;   Means for replacing one substructure with another substructure;   Means for transferring one partial structure to another card, and   The substructure to the function of the substructure and the service provider associated with the substructure To read and monitor (browse) information stored in the partial structure. Means. 30. Card holder and at least one service using chip card and terminal A method for executing a transaction with a provider, the method comprising: The method involves one of the following steps:   Prepare the data structure stored on the chip card Step; The data structure includes a transaction between the chip card and a service provider. Assigned to the service provider to enable the execution of transactions Card application (VAS data) data is loaded,   Perform a transaction between the service provider and the cardholder Write data to / from the data structure (VAS application) or Reading step,   The service provider's non-dedicated transfer storage (ET_TRANSFER), which is different Money exchanged or presented between service providers when executing the transaction Provision for transfer storage to contain data representing a unit of value or non-financial rights Steps to do, and   Writing data to or reading data from the transfer storage area. 31. 31. The method according to claim 30, wherein the method further comprises the following steps: 20. A chip card according to claims 1 to 19 Steps to use   Using the terminal device according to claims 20 to 29, and   The numerical description of at least one of the partial structures (VAS application) Storage, internal storage or information Writing or reading data to / from the information storage area. 32. 32. The method according to claim 30 or claim 31, wherein the method further comprises: Including at least one of the following steps:   The terminal device and / or the chip car using at least one key Authenticating the authority of the   Digital signature and / or key generation (encryption) using at least one key Code) to protect the transaction. 33. In a method for loading data on a chip card using a terminal device The method further comprises at least one of the following steps:   Loading data into the partial structure of the card (VAS application) ,and   Writing data to the definition data set of the card; Including at least one of the following steps:   Using the chip card according to claims 1 to 19; and And   30. A step of using the terminal device according to claim 20. 34. The chip car according to any one of claims 1 to 19, Using a terminal device according to claims 20 to 29. Transaction execution method to be used.

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＫ，ＥＥ，ＥＳ，Ｆ Ｉ，ＧＢ，ＧＥ，ＧＨ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，Ｚ Ｗ (72)発明者 ハインツ・ミヒャエル ドイツ連邦共和国 デー―34277 フルダ ブリュック ダス スペングラーシュフヒ ェン11 (72)発明者 キッシンジャー・ステファン ドイツ連邦共和国 デー―10823 ベルリ ン バルトブルグシュトラッセ６ (72)発明者 ゴルナー・ミヒャエル ドイツ連邦共和国 デー―81549 ミュン ヘン シュバンドルフェルシュトラッセ３ (72)発明者 クッヒェルマイスター・アントン・ヨット ドイツ連邦共和国 デー―80995 ミュン ヘン ヨハン―エンメル―シュトラッセ５ (72)発明者 シュバイア・アンドレアース ドイツ連邦共和国 デー―32429 ミンデ ン フィロソーフェンベーグ４ (72)発明者 ブルガー・アデルハイド ドイツ連邦共和国 デー64625 ベンシャ イム グロナウエル シュトラッセ34 ア ー (72)発明者 ラドノッティ・ミヒャエル ドイツ連邦共和国 デー―85417 マルツ リング バーンホフシュトラッセ42────────────────────────────────────────────────── ─── Continuation of front page    (81) Designated countries EP (AT, BE, CH, DE, DK, ES, FI, FR, GB, GR, IE, IT, L U, MC, NL, PT, SE), OA (BF, BJ, CF) , CG, CI, CM, GA, GN, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, M W, SD, SZ, UG, ZW), EA (AM, AZ, BY) , KG, KZ, MD, RU, TJ, TM), AL, AM , AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CU, CZ, DK, EE, ES, F I, GB, GE, GH, GW, HU, ID, IL, IS , JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, M N, MW, MX, NO, NZ, PL, PT, RO, RU , SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU, Z W (72) Inventor Heinz Michael             Germany Day 34277 Fulda             Bruck das Spenglerschhi             When 11 (72) Inventor Kissinger Stefan             Federal Republic of Germany Day-10823 Berlin             Baltic Burgstrasse 6 (72) Inventor Gorner Michael             Germany Day-81549 Mün             Hen Schwandfelstrasse 3 (72) Inventor Kuchelmeister Anton Yacht             Germany Day 80995 Mün             Hen Johann-Emmel-Strasse 5 (72) Inventor Schweier Andreas             Germany Day-32429 Minde             N Philosofen Beeg 4 (72) Inventor Brugger Adelheide             Germany Day 64625 Bencha             Im Gronawel Strasse 34             ー (72) Inventor Radnotti Michael             Germany Day-85417 Maltz             Ring Bahnhofstrasse 42

Claims (1)

【特許請求の範囲】 １．トランザクション実行のためのチップカードにおいて、該トランザクション では金銭的価値単位または他の非金銭的権利を表す価値データがカード所持者と 少なくとも一つのトランザクションパートナ（サービスプロバイダ）との間で転 送されるか、または該サービスプロバイダに該権利の検証のために提示され、前 記チップカードは該トランザクションの実行に必要なデータを記憶する為の記憶 装置を含むものであって、前記チップカードが、 各々が該カード所持者と一または複数のサービスプロバイダとの間でトランザ クションの実行を可能とする一または複数のカードアプリケーション（VASアプ リケーション）をカード上にロードするための手段を含むことを特徴とするチッ プカード。 ２．前記ロード手段は、 該手段内部に記憶されたデータ構造（DF_VAS，VASコンテナ）を含み、前記デ ータ構造は、 その中に該カード所持者とサービスプロバイダとの間でのトランザクション実 行を可能にするために必要なデータ（VASデータ）をロードできる部分構造（DF_ PT，DF_AD，VASアプリケーション）と、 前記部分構造（VASアプリケーション）内に記憶さ れたデータの種類および／または構造に関する情報を含む定義データセットとを 含み、前記定義データセットはさらに、 前記データ構造（VASコンテナ）および／または前記チップカードを同定する 識別子（コンテナID）と、前記定義データセットおよび／または前記データ構造 （VASコンテナ）の整合性が変更されないことを保証する少なくとも一つのシス テムキー（KSO）とを含むことを特徴とする請求の範囲第１項に記載のチップカ ード。 ３．特許請求の範囲第１項または第２項に記載のチップカードにおいて、前記カ ードはさらに、 トランザクション実行で交換されるまたは提示されるデータであって、金銭的 価値単位または非金銭的権利を表すデータを収容するための転送記憶領域（EF_T RANSFER）と、 書き込み命令（Transfer）に応じて前記転送記憶領域にデータを書き込むため の手段とを含むことを特徴とするチップカード。 ４．前記カードは、 トランザクション実行に必要なデータを、少なくとも一つのシステムキーを使 用して前記部分構造にロードするための手段、 前記部分構造にロードされたデータに前記定義デー タセットのデータを適応させるために、前記定義データセットにデータを書き込 むための手段、 トランザクション実行に必要なデータをロードできるさらなる部分構造を前記 カードの前記記憶装置内に生成するための手段、および／または 前記カード上で動的にメモリー管理をするための手段、 のうちの少なくとも一つの特徴を含むことを特徴とする請求の範囲第１項から 第３項のいずれか一項に記載のチップカード。 ５．前記部分構造（VASアプリケーション）は、各々特定のサービスプロバイダ に割り当てられた互いに独立した複数の部分構造であり、 前記定義データセットは少なくとも一つのシステムキー（KSO）によって変更 から保護されていて、該システムキーよってのみ変更可能であり、 前記データ構造（VASアプリケーション）のロードは前記定義データセットに 含まれるシステムキーを使用してのみ実行できることを特徴とする請求の範囲第 １項から第４項のうちのいずれか一項に記載のチップカード。 ６．請求の範囲第１項から第５項のいずれか一項に記載のチップカードにおいて 、 前記定義データセットはさらに以下の特徴の少なく とも一つを含む： 端末装置に対して前記チップカードの権限の認証のためのおよび／または前記 チップカードに対して端末装置の権限の認証のための少なくとも一つの認証キー （KAUT）、 前記転送領域から取り出されたデータの署名のための少なくとも一つの署名キ ー（KSIG-VASC）、 前記転送領域内の書き込み手続きおよび／または価値データのキャンセル（無 効化）の権限の検証のための、端末装置またはアプリケーション特有のキーを生 成するためのキー生成キー（KGKDEC）、 カード所持者によるトランザクション手続きの権限を検証するためのPIN、 前記システムキー（KSO）、前記認証キー（KAUT）、前記署名キー（KSIG-VASC ）および前記キー生成キー（KGKDEC）は、カードに特有であるか、データ構造（ DF_VAS）に特有であるかということ、および 前記部分構造（VASアプリケーション）が少なくとも以下の特徴の一つを持つ こと； 価値データを収容するための少なくとも一つの数値記憶域（EF_VALUE）、 前記部分構造に関連した内部データを収容するための少なくとも一つの内部記 憶域（EF_INTERNAL）、 前記部分構造に関連した非内部データを収容するた めの少なくとも一つの情報記憶域（EF_INFO）、および 前記数値記憶域および／または前記内部記憶域および／または前記情報記憶域 への／からの書き込み手続きおよび／または読み出し手続きに関する機密保持を する少なくとも一つのキー（KLVASP，KRVASP）を収容するためのキー記憶域（EF _KEY）；前記チップカードはさらに、 前記数値記憶域および／または前記内部記憶域および／または前記情報記憶域 への／からの書き込みおよび／または読み出しのための手段を含み；前記ロード するための手段は、 前記少なくとも一つのシステムキーの保護の下で、前記キー記憶域に前記キー を書き込むための手段を含む。 ７．請求の範囲第１項から第６項のいずれか一項に記載のチップカードにおいて 、前記部分構造は以下の特徴の少なくとも一つを含む： 前記部分構造内にデータを書き込む権限があるかを検証するためのキー（KLVA SP ）、および 前記部分構造内からデータを読み出す権限があるかを検証するためのキー（KR VASP ）。 ８．前記キー記憶域に記憶されたキーは各部分構造に特有であり、 前記少なくとも一つの部分構造（VASアプリケーション）は、少なくとも一つ の前記特有のキー（KLVASP，KRVASP）によってトランザクションの実行を保護し 、前記キーは、前記各部分構造（VASアプリケーション）に特有であり、かつ他 の前記各部分構造（VASアプリケーション）の前記キーから独立していることを 特徴とする請求の範囲第１項から第７項のいずれか一項に記載のチップカード。 ９．前記カードは複数個の前記部分構造（VASアプリケーション）を含み、前記 部分構造の各々は特定のサービスプロバイダと前記カード保持者との間でのトラ ンザクション実行に使用され、 前記トランザクション実行は、転送記憶領域への／からのデータの書き込みお よび／または読み出しおよび／または前記数値記憶域への／からのデータの書き 込みおよび／または読み出しを含むことを特徴とする請求の範囲第１項から第８ 項のいずれか一項に記載のチップカード。 10．個々の部分構造（VASアプリケーション）間および部分構造とサービスプロ バイダとの間でトランザクションを実行するための手段をさらに含むことを特徴 とする請求の範囲第１項から第９項のいずれか一項に記載のチップカード。 11．前記システムキー（KSO）はシステムオペレータ（ SO）のみに知られていて、カードに特有で、および／またはデータ構造（VASコ ンテナ）に特有のキーであり、 前記定義デーセット内に含まれる他のキーは、カードに特有で、および／また はデータ構造（VASコンテナ）に特有なキーであることを特徴とする請求の範囲 第１項から第10項のいずれか一項に記載のチップカード。 12．請求の範囲第１項から第11項のいずれか一項に記載のチップカードにおいて 、前記定義デーセットが以下の特徴のうちの一または複数を持つことを特徴とす るチップカード： 前記データ構造に特有な識別番号（EF_ID）、 前記データ構造に含まれる部分構造（EF_DIR）のディレクトリであって、前記 データ構造（VASコンテナ）にロードされた部分構造（VASアプリケーション）に 特有な識別番号と、前記部分構造（VASコンテナ）内の、前記部分構造（VASアプ リケーション）が物理的に記憶された部分に関する情報とを含むディレクトリ、 および 前記データ構造（EF_VERSION）のバージョンナンバ。 13．請求の範囲第１項から第12項のいずれか一項に記載のチップカードにおいて 、前記カードは以下の特徴 の少なくとも一つを持つ： 前記転送記憶領域からデータを取り出しおよび／またはキャンセルする取り出 し手続き（TAKE）を実行するための手段、および 前記転送記憶領域からデータを取り出しおよび／またはキャンセルするさい、 該データについての一つまたは複数の信憑性特徴を生成するための手段。 14．信憑性特徴を生成するために、 該取り出されたデータに関するディジタル署名を生成するための署名キー（KS IG _VASC)と、 前記ディジタル署名を生成するためにも使用される、前記トランザクションの 特性を表すトランザクション番号を生成するための手段とを含むことを特徴とす る請求の範囲第１項から第13項のいずれか一項に記載のチップカード。 15．前記署名キー（KSIG_VASC）は、プライベートのキー生成キーから生成され たプライベートキーであり、サービスプロバイダによる前記署名の検証のために 公開キーが使用されることを特徴とする請求の範囲第１項から第14項のいずれか 一項に記載のチップカード。 16．請求の範囲第１項から第15項のいずれか一項に記載のチップカードにおいて 、前記カードは以下の特徴の少なくとも一つを持つ： 前記キー生成キー（KGKDEC）を用いて端末装置およ び部分構造に特有なキー（KDEC）を生成するための手段、ならびに 以下の特徴の少なくとも一つを使ってトランザクションの認可および／または 保護を検証するための手段； 前記端末装置および部分構造に特有なキー（KDEC）、 少なくとも一つの前記認証キー（KAUT）、 少なくとも一つの前記システムキー（KSO）、 少なくとも一つの前記部分構造特有キー（KLVASP，KRVASP）、 前記署名キー（KSIG_VASC）、 前記PIN、 部分構造の前記識別子、および 前記端末識別子。 17．請求の範囲第１項から第16項のいずれか一項に記載のチップカードにおいて 、前記カードはさらに以下の特徴の少なくとも一つを持つ： 読み出しまたは書き込み手続きを始める前に、前記認証キーを用いて前記認可 および／または前記端末装置の認証をするための手段、および デジタル署名および／またはキー形成（エンコード）によって保護されている 読み出しまたは書き込み手続きを実行するための手段。 18．請求の範囲第１項から第17項のいずれか一項に記載のチップカードにおいて 、前記カードはさらに以下の特徴の少なくとも一つを持つ： 前記PIN保護を活性化および不活性化するための手段、および 前記PINを変更するための手段。 19．請求の範囲第１項から第18項のいずれか一項に記載の前記データ構造は前記 カードプラットフオームから独立しており、前記カードはさらに、 前記データ構造または前記データ構造の一部を他のカード上に転送するための 手段を含むことを特徴とする請求の範囲第１項から第18項のいずれか一項に記載 のチップカード。 20．金銭的価値単位および／または他の非金銭的権利を表す価値データを同一の または異なるサービスプロバイダ間で転送するための記憶領域内へ／からデータ を読み出すまたは書き込むための記憶領域を含むことを特徴とするチップカード 。 21．請求の範囲第１項から第20項のいずれか一項に記載のチップカードを使用す るための端末装置であって、前記端末装置は、 前記チップカードのデータ構造（VASコンテナ）の識別と、前記データ構造を 識別する識別子（コンテナID）の識別とをするための手段を含み、 前記端末装置はさらに以下の特徴の少なくとも一つを持つ： 少なくとも前記部分構造の一つおよび／または前記定義データセットおよび／ または前記カードの転送記憶領域からデータを読み出すための手段、 前記カードの転送記憶領域にデータを書き込むための手段、および トランザクション実行に必要なデータを前記カードの少なくとも一つの部分構 造（VASアプリケーション）にロードするための手段。 22．請求の範囲第21項に記載の端末装置において、前記端末装置はさらに以下の 特徴の少なくとも一つを持つ： サービス端末装置と前記カード所持者との間でトランザクションを実行するた めの手段、該トランザクションの実行は以下のステップの少なくとも一つを含む ； 前記数値記憶域にデータを書き込むステップ、 前記転送記憶域にデータを書き込むステップ、 前記転送記憶域からデータを取り出すおよび／またはキャンセルするステップ 、 前記部分構造からデータを読み出すステップ、および 前記転送記憶域からデータを読み出すステップ。 23．請求の範囲第21項または第22項に記載の端末装置において、端末装置はさら に、 以下の特徴の少なくとも一つを用いてトランザクションの認可および／または 保護の検証をするための手段を含む； 前記端末装置および部分構造に特有なキー（KDEC）、 カードに特有のまたはデータ構造（DF_VAS）に特有の少なくとも一つの認証キ ー（KAUT）、 カードに特有のまたはデータ構造(DF_VAS)に特有の少なくとも一つのシステム キー（KSO）、 少なくとも一つの部分構造特有キー（KLVASP，KRVASP)、 カードに特有の、またはデータ構造（DF_VAS）に特有の少なくとも一つの署名 キー（KSIG_VASC）、 カードに特有の、またはデータ構造(DF_VAS)に特有のPIN、 部分構造のアプリケーションに特有な識別子、および 端末装置に特有な識別子。 24．データを前記転送記憶領域に書き込むための手段が、 書き込み権の証明のために、端末装置および部分構造に特有のキー（KDEC）を 使用してデータからキー作 成（エンコード）するための手段を含むことを特徴とする請求の範囲第21項から 第23項のいずれか一項に記載の端末装置。 25．データの取り出しおよび／またはキャンセルされる前記転送記憶領域からの データの取り出し手続きを実行するための手段を含むことを特徴とする請求の範 囲第21項から第24項のいずれか一項に記載の端末装置。 26．請求の範囲第21項から第25項のいずれか一項に記載の端末装置において、前 記端末装置はさらに以下の特徴の少なくとも一つを持つ： 前記転送記憶領域のデータに「取り出し済み」と特徴づけるための手段、およ び 前記転送記憶領域のデータに「期限切れ」と特徴づけるための手段。 27．請求の範囲第21項から第26項のいずれか一項に記載の端末装置において、前 記トランザクション実行のための手段はさらに以下の特徴の少なくとも一つを持 つ： 前記部分構造内の価値データを変更するための手段、および カード所持者の費用で、カード所持者の利益のために、異なるサービスプロバ イダ間のトランザクション（インターサービス）を実行するための手段。 28．少なくとも一つの認証キーを使用して、前記カードに対して前記端末装置の 権限をおよび／または前記端末装置に対して前記カードの権限を認証するための 手段と、 PINを用いて前記カード保持者によるトランザクションを保護するための手段 と、 PIN保護の活性化および非活性化を行うための手段を含むことを特徴とする請 求の範囲第21項から第27項のいずれか一項に記載の端末装置。 29．請求の範囲第21項から第28項のいずれか一項に記載の端末装置において、前 記端末装置はさらに以下の特徴の少なくとも一つを持つ： 端末装置に特有な識別子を前記カードに転送するための手段、 前記部分構造に特有な識別子を前記カードに転送するための手段、 端末装置および部分構造に特有なキーならびに該端末装置および部分構造に特 有な識別子を使用して、前記権限を認証するための手段、ならびに ディジタル署名および／またはキー作成（エンコード）で保護される読み出し または書き込み手続きを実行するための手段。 30．請求の範囲第21項から第29項のいずれか一項に記載の端末装置において、前 記端末装置はさらに以下の 特徴の少なくとも一つを持つ： 部分構造（VASアプリケーション）を選択するための手段、 前記端末装置において部分構造を監視（閲覧）するための手段、 前記端末装置において部分構造データを監視（閲覧）するための手段、 前記カードに部分構造（VASアプリケーション）をロードするための手段、 ロードされた部分構造（VASアプリケーション）の識別子を前記カードにロー ドするための手段、 前記カードから部分構造を消去するための手段、 ある部分構造を他の部分構造で置換するための手段、 ある部分構造を他のカードに転送するための手段、ならびに 部分構造を該部分構造の機能と該部分構造に関連するサービスプロバイダとに 関して解釈し、該部分構造に記憶された情報を読み出して監視（閲覧）するため の手段。 31．チップカードと端末装置を使用してカード所持者と少なくとも一つのサービ スプロバイタとの間におけるトランザクションを実行する方法において、前記方 法は以下のステップの一つを含む： 該チップカードに記憶されたデータ構造を準備するステップ；該データ構造に は、該チップカードとサービスプロバイダとの間のトランザクション実行を可能 にするために必要な、および該データ構造（VASアプリケーション）へ／からデ ータを書き込むまたは読み込むために必要なデータ（VASデータ）がロードされ る； 転送記憶域（ET_TRANSFER）であって、該トランザクション実行時に交換また は提示される金銭的価値単位または非金銭的権利を表すデータを収容するための 、および該転送記憶域へ／からデータを書き込むまたは読み込むための転送記憶 域を準備するステップ。 32．請求の範囲第31項に記載の方法において、前記方法はさらに以下のステップ の少なくとも一つを含む：請求の範囲第１項から第20項に記載のチップカードを 使用するステップ、 請求の範囲第21項から第30項に記載の端末装置を使用するステップ、および 前記部分構造（VASアプリケーション）のうちの少なくとも一つの前記数値記 憶域、内部記憶域または情報記憶域へ／からデータを書き込むまたは読み込むス テップ。 33．請求の範囲第31項または第32項に記載の方法において、前記方法はさらに以 下のステップの少なくとも 一つを含む： 少なくとも一つのキーを使用して前記端末装置および／または前記チップカー ドの権限を認証するステップ、ならびに 少なくとも一つのキーを用い、ディジタル署名および／またはキー作成（エン コード）を使用してトランザクションを保護するステップ。 34．端末装置を使用してチップカードにデータをロードするための方法において 、前記方法はさらに以下のステップの少なくとも一つを含む： 該カードの部分構造（VASアプリケーション）にデータをロードするステップ 、および 該カードの該定義データセットにデータを書き込むステップ。 35．請求の範囲第34項に記載のデータロード方法において、前記方法はさらに以 下のステップの少なくとも一つを含む、 請求の範囲第１項から第20項に記載のチップカードを使用するステップ、およ び 請求の範囲第21項から第30項に記載の端末装置を使用するステップ。 36．請求の範囲第１項から第20項に記載のチップカードと、請求の範囲第21項か ら第30項に記載の端末装置とによって特徴付けられるトランザクション実行方法 。[Claims] 1. In a chip card for executing a transaction, the transaction The value data representing monetary value units or other non-monetary rights is Transfer with at least one transaction partner (service provider) Sent to or presented to the service provider for verification of the rights, The chip card is a memory for storing data necessary for executing the transaction. Device, wherein the chip card comprises:   Each of which has a transaction between the cardholder and one or more service providers. One or more card applications (VAS applications) Application means for loading the application on a card. Card. 2. The loading means,   A data structure (DF_VAS, VAS container) stored inside said means, The data structure is   In which the transaction between the cardholder and the service provider is performed. A substructure (DF_) that can load the data (VAS data) needed to enable the row PT, DF_AD, VAS application)   Stored in the substructure (VAS application) Definition data set containing information on the type and / or structure of the data Wherein said definition dataset further comprises:   Identify the data structure (VAS container) and / or the chip card An identifier (container ID) and the definition data set and / or the data structure (VAS container) at least one system to ensure that the integrity of the Temukey (KSO2. The chip cap according to claim 1, further comprising: Mode. 3. 3. The chip card according to claim 1 or 2, wherein Mode further   Data exchanged or presented in the execution of a transaction that is financially Transfer storage (EF_T) to hold data representing value units or non-monetary rights RANSFER)   To write data to the transfer storage area in response to a write command (Transfer) A chip card comprising: 4. The card is   Use at least one system key to store data required to execute a transaction. Means for loading said substructure using   The definition data is added to the data loaded in the substructure. Write data to the definition data set to adapt the data in the tuset Means,   Additional substructures that can load the data needed to execute the transaction Means for generating in said storage of a card, and / or   Means for dynamically managing memory on the card,   Claims 1 to 3 including at least one of the following features: 4. The chip card according to claim 1. 5. Each of the partial structures (VAS application) has a specific service provider. A plurality of independent substructures assigned to   The definition data set has at least one system key (KSOChanged by) Protected from being changed only by the system key,   Loading of the data structure (VAS application) is performed in the definition data set Claims characterized by being able to be executed only using the included system key 5. The chip card according to any one of items 1 to 4. 6. The chip card according to any one of claims 1 to 5, ,   The definition dataset further includes the following features: Including one:   For authentication of the authority of said chip card to a terminal device and / or At least one authentication key for authenticating the authority of the terminal device to the chip card (KAUT),   At least one signature key for signing data retrieved from the transfer area; ー (KSIG-VASC),   Write procedure and / or cancellation of value data in the transfer area (no Terminal or application-specific key to verify the Key (KGK)DEC),   A PIN to verify the authorization of the cardholder for the transaction,   The system key (KSO), The authentication key (KAUT), The signature key (KSIG-VASC ) And the key generation key (KGK)DEC) Is specific to the card or has a data structure ( DF_VAS), and   The partial structure (VAS application) has at least one of the following features: thing;   At least one numeric storage (EF_VALUE) to hold value data,   At least one internal record for containing internal data related to said substructure Storage (EF_INTERNAL),   To contain non-internal data related to the substructure At least one information storage area (EF_INFO), and   The numerical storage area and / or the internal storage area and / or the information storage area Confidentiality of write and / or read procedures to / from At least one key (KLVASP, KRVASPKey storage (EF) _KEY); The chip card further comprises:   The numerical storage area and / or the internal storage area and / or the information storage area Including means for writing to and / or reading from / to the load; The means for doing   Storing the key in the key storage under the protection of the at least one system key; Including means for writing. 7. The chip card according to any one of claims 1 to 6, wherein Wherein the partial structure includes at least one of the following features:   Key (K) to verify that you have permission to write data in the substructureLVA SP ),and   Key (KR VASP ). 8. The key stored in the key storage is specific to each substructure;   The at least one partial structure (VAS application) includes at least one The unique key (KLVASP, KRVASP) Protects the execution of the transaction by , The key is specific to each substructure (VAS application) and That each of the substructures (VAS application) is independent of the key The chip card according to any one of claims 1 to 7, characterized in that: 9. The card includes a plurality of the partial structures (VAS applications), Each of the substructures is a transaction between a particular service provider and the cardholder. Used to execute the transaction,   The transaction execution includes writing data to / from the transfer storage area and And / or reading and / or writing data to / from said numerical storage 9. The method according to claim 1, further comprising: The chip card according to any one of the above items. Ten. Between individual substructures (VAS applications) and between substructures and service providers Further comprising means for executing a transaction with the binder. The chip card according to any one of claims 1 to 9, wherein 11． The system key (KSO) Is the system operator ( SO), known only to the card and specific to the card and / or the data structure (VAS Key),   Other keys included in the definition dataset are card-specific and / or Is a key specific to a data structure (VAS container). 11. The chip card according to any one of items 1 to 10. 12． The chip card according to any one of claims 1 to 11, Wherein the definition dataset has one or more of the following features: Chip card:   An identification number (EF_ID) unique to the data structure,   A directory of a partial structure (EF_DIR) included in the data structure, In the partial structure (VAS application) loaded in the data structure (VAS container) A unique identification number and the substructure (VAS app) within the substructure (VAS container) Application) contains information about the physically stored part, and   Version number of the data structure (EF_VERSION). 13. The chip card according to any one of claims 1 to 12, The card has the following features Having at least one of:   Retrieving and / or canceling data from the transfer storage area Means for performing the TAKE procedure, and   Retrieving and / or canceling data from said transfer storage area; Means for generating one or more authenticity features for the data. 14. To generate authenticity features,   A signature key (K) for generating a digital signature for the retrieved dataS IG _VASC)When,   Of the transaction, which is also used to generate the digital signature. Means for generating a transaction number representing the characteristic. 14. The chip card according to any one of claims 1 to 13, wherein: 15． The signing key (KSIG_VASC) Is generated from a private key generation key Private key for the service provider to verify the signature. 15. A method according to claim 1, wherein a public key is used. The chip card according to claim 1. 16． The chip card according to any one of claims 1 to 15, The card has at least one of the following features:   The key generation key (KGKDEC) Using terminal equipment and And keys specific to substructures (KDECMeans for generating   Authorize transactions and / or use at least one of the following features: Means for verifying protection;   A key (KDEC),   At least one of the authentication keys (KAUT),   At least one of the system keys (KSO),   At least one of said substructure-specific keys (KLVASP, KRVASP),   The signing key (KSIG_VASC),   Said PIN,   Said identifier of a substructure; and   The terminal identifier. 17． The chip card according to any one of claims 1 to 16, The card further has at least one of the following features:   Before starting the read or write procedure, use the authentication key to And / or means for authenticating the terminal device, and   Protected by digital signature and / or keying (encoding) A means for performing a read or write procedure. 18． The chip card according to any one of claims 1 to 17, The card further has at least one of the following features:   Means for activating and deactivating said PIN protection; and   Means for changing the PIN. 19. The data structure according to any one of claims 1 to 18, wherein the data structure Independent of the card platform, the card further comprises:   For transferring said data structure or a part of said data structure onto another card The method according to any one of claims 1 to 18, characterized by including means. Chip card. 20. Value data representing monetary value units and / or other non-monetary rights Or data into / from storage area for transfer between different service providers Chip card including a storage area for reading or writing data . twenty one. Use of the chip card according to any one of claims 1 to 20 Terminal device for the, the terminal device,   Identification of the data structure (VAS container) of the chip card, and Including means for identifying the identifier (container ID) to be identified,   The terminal further has at least one of the following features:   At least one of the substructures and / or the definition data set and / or Or means for reading data from the transfer storage area of the card,   Means for writing data to a transfer storage area of the card, and   Data necessary for executing a transaction is stored in at least one partial structure of the card. The means to load into the structure (VAS application). twenty two. 22. The terminal device according to claim 21, wherein the terminal device further comprises: Has at least one of the features:   For executing a transaction between the service terminal device and said cardholder Means for executing the transaction includes at least one of the following steps: ;   Writing data to the numeric storage area;   Writing data to the transfer storage area,   Retrieving and / or canceling data from the transfer storage ,   Reading data from the substructure; and   Reading data from the transfer storage area. twenty three. 23. The terminal device according to claim 21 or claim 22, further comprising: To   Authorize transactions and / or use at least one of the following features: Including means for verifying protection;   A key (KDEC),   At least one authentication key specific to the card or specific to the data structure (DF_VAS) ー (KAUT),   At least one system specific to the card or specific to the data structure (DF_VAS) Key (KSO),   At least one substructure-specific key (KLVASP, KRVASP),   At least one signature specific to the card or specific to the data structure (DF_VAS) Key (KSIG_VASC),   PIN specific to the card or specific to the data structure (DF_VAS),   An identifier unique to the substructure application; and   An identifier unique to the terminal device. twenty four. Means for writing data to the transfer storage area,   For proof of write permission, a key (KDEC) Use key data from data Claim 21 comprising means for encoding (encoding) 24. The terminal device according to claim 23. twenty five. Data from the transfer storage area being retrieved and / or canceled Claims comprising means for performing a data retrieval procedure. 25. The terminal device according to any one of items 21 to 24. 26. The terminal device according to any one of claims 21 to 25, wherein The terminal further has at least one of the following features:   Means for characterizing the data in the transfer storage area as "retrieved"; And   Means for characterizing the data in the transfer storage area as "expired". 27. The terminal device according to any one of claims 21 to 26, wherein The means for executing a transaction further has at least one of the following features. One:   Means for changing value data in the substructure; and   Different service providers at the expense of the cardholder and for the benefit of the cardholder A means for executing a transaction (interservice) between Ida. 28. Using at least one authentication key, the terminal device Authority and / or to authenticate the authority of the card to the terminal device Means,   Means for protecting transactions by said cardholder using a PIN When,   A contract including means for activating and deactivating PIN protection. 28. The terminal device according to any one of paragraphs 21 to 27. 29. The terminal device according to any one of claims 21 to 28, wherein The terminal further has at least one of the following features:   Means for transferring an identifier unique to a terminal device to the card,   Means for transferring an identifier unique to said partial structure to said card;   Keys specific to terminal devices and substructures and keys specific to the terminal devices and substructures Means for authenticating said authority using a unique identifier; and   Read protected with digital signature and / or key generation (encoding) Or a means for performing a write procedure. 30. The terminal device according to any one of claims 21 to 29, wherein The terminal device further includes: Has at least one of the features:   Means for selecting a substructure (VAS application),   Means for monitoring (viewing) a partial structure in the terminal device;   Means for monitoring (viewing) partial structure data in the terminal device;   Means for loading a partial structure (VAS application) on said card;   The identifier of the loaded partial structure (VAS application) is loaded into the card. Means to do   Means for erasing a partial structure from said card;   Means for replacing one substructure with another substructure;   Means for transferring one partial structure to another card, and   The substructure to the function of the substructure and the service provider associated with the substructure To read and monitor (browse) information stored in the partial structure. Means. 31. Card holder and at least one service using chip card and terminal A method for performing a transaction with a provider, the method comprising: The method involves one of the following steps:   Providing a data structure stored on the chip card; Can execute transactions between the chip card and the service provider To and from the data structure (VAS application) Data (VAS data) required to write or read data is loaded. The   Transfer storage area (ET_TRANSFER), which is exchanged or Is used to contain data representing the monetary unit of value or non-monetary rights presented. , And transfer storage for writing or reading data to / from the transfer storage area Preparing the area. 32. 32. The method according to claim 31, wherein the method further comprises the following steps: Including at least one of the following: a chip card according to claims 1 to 20; Steps to use,   Using the terminal device according to claims 21 to 30, and   The numerical description of at least one of the partial structures (VAS application) Write / read data to / from storage, internal storage or information storage Tep. 33. 33. The method according to claim 31 or claim 32, wherein the method further comprises: At least of the steps below Including one:   The terminal device and / or the chip car using at least one key Authenticating the authority of the   Digital signature and / or key generation (encryption) using at least one key Code) to secure the transaction. 34. In a method for loading data on a chip card using a terminal device The method further comprises at least one of the following steps:   Loading data into the partial structure of the card (VAS application) ,and   Writing data to the definition data set of the card. 35. 35. The data loading method according to claim 34, wherein the method further comprises: Including at least one of the following steps:   Using the chip card according to claims 1 to 20; and And   31. A step of using the terminal device according to claims 21 to 30. 36. The chip card according to claim 1 to claim 20, and the claim card according to claim 21. 31. A transaction execution method characterized by the terminal device according to item 30. .
JP10528242A 1996-12-23 1997-12-19 Chip card and usage of chip card Pending JP2000508101A (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE19654187.5 1996-12-23
DE19654187 1996-12-23
DE19718115A DE19718115A1 (en) 1996-12-23 1997-04-29 Smart card and method of using the smart card
DE19718115.5 1997-04-29
PCT/DE1997/003012 WO1998028718A2 (en) 1996-12-23 1997-12-19 Chip card and method for its use

Publications (1)

Publication Number Publication Date
JP2000508101A true JP2000508101A (en) 2000-06-27

Family

ID=26032753

Family Applications (1)

Application Number Title Priority Date Filing Date
JP10528242A Pending JP2000508101A (en) 1996-12-23 1997-12-19 Chip card and usage of chip card

Country Status (18)

Country Link
EP (1) EP0968485A2 (en)
JP (1) JP2000508101A (en)
AP (1) AP1062A (en)
AU (1) AU738719B2 (en)
BG (1) BG63233B1 (en)
CA (1) CA2275931A1 (en)
CZ (1) CZ225499A3 (en)
EA (1) EA001837B1 (en)
HU (1) HUP0000448A3 (en)
ID (1) ID23950A (en)
IL (1) IL130174A0 (en)
IS (1) IS5060A (en)
NO (1) NO993102L (en)
NZ (1) NZ336403A (en)
PL (1) PL334183A1 (en)
SK (1) SK86099A3 (en)
TR (1) TR199901431T2 (en)
WO (1) WO1998028718A2 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
HRP980597A2 (en) * 1998-11-18 2001-06-30 Lada Sokota Multifunctional bank card
DE19929164A1 (en) 1999-06-25 2001-01-11 Giesecke & Devrient Gmbh Method for operating a data carrier designed for executing reloadable function programs
AUPQ268999A0 (en) 1999-09-07 1999-09-30 Keycorp Limited Application management for multi application devices
DE10324996A1 (en) 2003-06-03 2005-02-17 Giesecke & Devrient Gmbh Chip card with at least one application
FR2882835B1 (en) * 2005-03-01 2007-09-07 Softway Sa SECURE TRANSFER METHOD WITH SECURE MEDIA CARD
EP2199992A1 (en) * 2008-12-19 2010-06-23 Gemalto SA Secure activation before contactless banking smart card transaction
EP2417546B1 (en) * 2009-04-10 2018-01-03 Koninklijke Philips N.V. Combined authentication of a device and a user
RU2624555C2 (en) * 2015-08-19 2017-07-04 Общество с ограниченной ответственностью "ОВЕРКОМ" Data processing system during product release and service delivery

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4816653A (en) * 1986-05-16 1989-03-28 American Telephone And Telegraph Company Security file system for a portable data carrier
DE3833241A1 (en) * 1988-09-30 1990-04-05 Deutsche Bundespost METHOD FOR PROGRAMMING CHIP CARDS
JPH02165290A (en) * 1988-12-19 1990-06-26 Hitachi Maxell Ltd Ic card and method for operating ic card
FR2673476B1 (en) * 1991-01-18 1996-04-12 Gemplus Card Int SECURE METHOD FOR LOADING MULTIPLE APPLICATIONS INTO A MICROPROCESSOR MEMORY CARD.
DE4205567A1 (en) * 1992-02-22 1993-08-26 Philips Patentverwaltung METHOD FOR CONTROLLING ACCESS TO A STORAGE AND ARRANGEMENT FOR IMPLEMENTING THE METHOD
FR2687816B1 (en) * 1992-02-24 1994-04-08 Gemplus Card International METHOD FOR PERSONALIZING A CHIP CARD.
US5544246A (en) * 1993-09-17 1996-08-06 At&T Corp. Smartcard adapted for a plurality of service providers and for remote installation of same
JP3176209B2 (en) * 1994-02-25 2001-06-11 富士通株式会社 Card-type storage medium and card-type storage medium issuing device
GB9411586D0 (en) * 1994-06-09 1994-08-03 Zeneca Ltd Coating process

Also Published As

Publication number Publication date
AU5748798A (en) 1998-07-17
IL130174A0 (en) 2000-06-01
NO993102D0 (en) 1999-06-22
TR199901431T2 (en) 1999-10-21
AP1062A (en) 2002-04-25
AP9901573A0 (en) 1999-06-30
WO1998028718A2 (en) 1998-07-02
BG103490A (en) 2000-02-29
CA2275931A1 (en) 1998-07-02
NZ336403A (en) 2001-09-28
HUP0000448A2 (en) 2000-06-28
CZ225499A3 (en) 1999-11-17
EA199900538A1 (en) 2000-06-26
BG63233B1 (en) 2001-06-29
ID23950A (en) 2000-06-08
IS5060A (en) 1999-05-28
AU738719B2 (en) 2001-09-27
HUP0000448A3 (en) 2000-08-28
SK86099A3 (en) 2000-01-18
WO1998028718A3 (en) 1998-10-08
EP0968485A2 (en) 2000-01-05
EA001837B1 (en) 2001-08-27
PL334183A1 (en) 2000-02-14
NO993102L (en) 1999-08-23

Similar Documents

Publication Publication Date Title
CA2345391C (en) Loyalty file structure for smart card
US6249869B1 (en) Integrated circuit card, secure application module, system comprising a secure application module and a terminal and a method for controlling service actions to be carried out by the secure application module on the integrated circuit card
JP4327261B2 (en) Secure multi-application card system and process
US6575372B1 (en) Secure multi-application IC card system having selective loading and deleting capability
USRE43460E1 (en) Public/private dual card system and method
US20070001000A1 (en) Method and system for providing interactive cardholder rewards image replacement
KR20000069703A (en) Chip card and method for its use
JP2009169809A (en) Biological information registration system and ic card, processing terminal, and center system
JP4942240B2 (en) Payment processing method using a credit card
JP2000508101A (en) Chip card and usage of chip card
JP2003504759A (en) System for executing transactions
JP4230820B2 (en) Electronic ticket offline authentication method and system
JP2003507824A (en) Guarantee system for performing electronic commerce and method used therefor
TW491980B (en) Chip card and its using method
JP2003317037A (en) Method and system for ic card life cycle management service
WO2005121973A1 (en) Data storage method and system
CA2624758C (en) System and method for creating activation secure module
JP2006171842A (en) Information processing method, information processing system, and server device
MXPA99005832A (en) Chip card and method for its use