KR20000069703A

KR20000069703A - 칩카드 및 이것의 사용을 위한 방법

Info

Publication number: KR20000069703A
Application number: KR1019997005772A
Authority: KR
Inventors: 엥엘하르트홀거; 힌츠미하엘; 키씽어쉬테판; 골너미하엘; 쿠헬마이스터안톤제이.; 쉬비어안드레아스; 부르거아델하이트; 라드노티미하엘
Original assignee: 베베-다타 게젤샤푸트 퓨어 인포르마촌스-운트 콤무니카 촌스자이스테메 엠베하; 도이체 방크 아게
Priority date: 1996-12-23
Filing date: 1997-12-19
Publication date: 2000-11-25
Also published as: DE19718115A1; ZA9711485B; YU29199A

Abstract

칩카드는 트랜잭션을 실행하는데 소용되며, 트랜잭션 동안에 화폐(monetary units) 또는 비화폐자격들(non-monetary entitlements)을 나타내는 다른 가치데이터(value data)는 카드소지자 및 적어도 하나의 트랜잭션협력자(서비스공급자) 사이에 전송되거나 또는 자격들의 검증을 위해 서비스공급자에게 제출된다. 이 칩카드는 트랜잭션들을 실행하는데 요구된 데이터가 저장되는 저장기를 포함한다. 이 칩카드는 하나 이상의 카드응용들(VAS-응용들)을 칩카드에 올려, 카드소지자 및 하나 이상의 서비스공급자들 사이의 트랜잭션들의 실행을 허락하는 수단을 더 포함한다.

Description

칩카드 및 이것의 사용을 위한 방법{Chip card and method for its use}

본 발명은 칩카드, 칩카드와 함께 사용하기 위한 단말(terminal), 및 칩카드 뿐만 아니라 칩카드시스템도 사용하기 위한 방법에 관한 것이다.

지불기능(payment function), 예를 들면 전자지갑(electronic purse), 이씨- 캐쉬(ec-cash), 대변기능(credit function) 등을 갖는 마이크로프로세서 칩카드들은 이미 사용중이고, 그것들의 성질에 의존하여 필수전제조건들이 조직체들, 예를들면 ZKA(Zentraler Kreditausschuβ), VISA 또는 EMV(Europay Mastercard VISA)에 의해, 그것들이 (현금 대용) 지불수단으로서 사용될 수 있도록 명기되었다. 예로서, 다음의 것들이 여기서 언급된다:

- ZKA, Zentraler Kreditausschuβ, "interaction specification for the ec-card with chip", 27.10.1995.;

- Europay International, "Integrated Circuit Card, Specification of Payment Systems, EMV'96", V3.0, 30-Jun-1996;

- ISO/IEC 7816-4, "information technology - Identification cards - Integrated circuit(s) cards with contacts, Part 4; Interindustry commands for interchange", 01-09-1995;

- prEN 1546-1, "Identification card systems - Inter-sector electronic purse, Part 1: Definitions, concepts and structures", 15.03.1995;

- prEN 1546-2, "Identification card systems - Inter-sector electronic purse, Part 2: Security architecture", 03.07.1995;

- prEN 1546-3, "Identification card systems - Inter-sector electronic purse, Part 3: Data elements and interchanges", 09.12.1994.

칩카드들의 최신의 개관(survey)은 다음에서 발견될 것이다:

- Stefan Schutt, Bert Kohlgraf: "Chipkarten, Technische Merkmale, Normung, Einsatzgebiete", ("Chip cards, Technical Characteristics, Standards, Fields of Employment"), R. Oldenbourg Verlag, Munich/Vienna, 1996, ISBN 3-486-23738-1.

기존의 칩카드들은 대개 특정한 목적을 위해서만, 예를 들면 전자화폐지갑(electronic money purse)으로서 또는 전자식별수단으로서 이용 가능하다. 그러나, 이러한 칩카드들에 적용되는 응용들(applications)은 대체로 정적(static)이다. 즉 그것들은 칩카드의 제조 동안에 적용되고 카드의 제품수명(life cycle)의 처음부터 끝까지 변경되지 않고 보존된다.

기존의 칩카드들은 그것들의 가변성(variability)에 관해서 뿐만 아니라 그것들의 기능성(functionality)에 대해 제한된다. 특히, 기존의 칩카드들은 그것들의 기능성에 관해서는 그것들의 제조공정에 따라 고정되고 더 이상은 변경되지 않는다.

따라서 본 발명의 목적은 그것의 기능성이 가변하는 칩카드를 제공함에 있다.

본 발명의 추가적인 목적은 제조공정의 이후에서조차 칩카드 또는 응용들 및 트랜잭션(transaction)들에 의해 수행가능한 응용의 갯수 및 성질이 여전히 가변적인 칩카드를 제공함에 있다. 이러한 칩카드들에 부가적인 응용들을 올리는(load) 것이 가능해질 것이며, 칩카드로부터 응용들을 삭제하는 것이 가능해질 것이고, 개개의 응용들은 데이터보안기술적인(data and security-technological) 관점에서 서로로부터 독립적으로 정의되어지며 서로로부터 독립적으로 진행하게 된다.

칩카드는 예를 들면, ISO 7816에 따른 데이터보안기술적인 조건들을 따르고, 이 카드의 개개의 응용들은 그러나 특히 카드플랫폼(card platform) 자체로부터 독립적이게 될 것이다.

이 발명의 추가적인 목적은 사용자 자신이 그의 칩카드에서 이용할 수 있는 응용들의 갯수 및 성질을 그의 칩카드로 결정하거나 조합하거나 변경할 수 있는 칩카드를 제공하는 것이다.

게다가, 본 발명의 목적은 칩카드에 의해 인터서비스들(즉, 외부 협력자들에 연루된 부가적인 외부 관계들을 지닌 응용들) 뿐만 아니라 인트라서비스들(즉, 외부 협력자들에 연루된 기장들(bookings) 및 서비스전송들(service transfers)이 일어나지 않는다는 의미에서의 폐루프 응용들) 양쪽이 가능하고 수행되어질 수 있는 칩카드를 제공하는 것이다.

본 발명의 한 양태(aspect)에 의하면, 카드응용들의 각각에 의해 카드소지자(cardholder) 및 하나 이상의 서비스공급자들 간의 트랜잭션들의 실행(performance)이 가능하게 되는 하나 이상의 카드응용들이 이 장치에 의해 카드에 올려질 수 있는 장치가 제공된다.

이러한 올리기(loading)에 의해, 칩카드는 새로운 기능성이 마련되도록 즉, 이전에는 이것에 대해 개방되지 않은 응용을 실행할 수 있도록 구성된다. 올려진 데이터는 이전에는 이 카드에 제공되지 않은 운영체계와 같은 카드의 기본적인 기능성들에 관련하여 응용들이 정의되어지고 실현되어지게 한다. 그 결과, 카드의 기능성은 이러한 응용의 올리기에 의해 이러한 특정한 응용까지 확장된다.

발명의 실시예에 의하면, 부분구조 및 정의데이터집합(definition data set)으로 세분화된 데이터구조(DF_VAS)가 본 발명에 따른 칩카드에 제공되고, 이 데이터구조는 이것을 식별하는 부호화에 의해 뚜렷하게 식별되어지고 그래서 카드플랫폼에 독립하게 된다. 이른바 응용들은 이제 부분구조 즉, 칩카드의 기능성들 및 응용들에 올려질 수 있다. 그 결과, 칩카드의 특정한 응용의 올리기에 의해, 카드소지자 및 이 응용에 특정한 서비스공급자 간의 트랜잭션들을 수행하는 것이 가능하게된다. 이 데이터구조내의 정의데이터집합은 부분구조 속으로 올려지는 응용들의 성질 및/또는 구조에 관련한 정보를 담고 있다. 적어도 정의데이터집합, 바람직하게는, 그러나, 전체데이터구조가 변형들에 대하여 적어도 하나의 시스템키에 의해 안전해지고 이 키를 사용함에 의해서만 변형 가능하다. 시스템키 대신에, 변형들에 대항하는 보안하기가, 예를 들면 개인식별번호(personal identity number, PIN) 또는 그러한 보안에 이바지하는 보안수단 뿐만 아니라 또는 다른 수단에 의해 제공되어지는 다른 보안메커니즘들이 생각되어질 수 있다.

위의 구조에 의해, 부분구조 속으로 다양한 응용들을 올리는 것이 가능하고 또한 이것들을 다시 한번 부분구조로부터 삭제하여 카드가 그 기능성들 또는 카드와 함께 수행되어질 응용들에 관련하여 가변적이게 하는 것이 가능하다. 응용들의 올리기 및 삭제하기(deleting)는 응용에 특별한(application specific) 데이터 및 키들을 제공된 부분구조에 기록함으로써 진행한다. 시스템키 및 데이터구조부호화의 준비에 의해, 다기능성(multi-functionality)을 허락하는 데이터구조는 카드플랫폼 그 자체로부터 독립하게 다루어지고 또한 그것의 보안구조에 대하여 카드플랫폼으로부터 자가지원적으로 및 독립적으로 다루어지게 된다.

부분구조에 올려진 응용들에 의존하여, 카드소지자 및 올려진 응용들에 의존하는 서비스공급자들 간의 트랜잭션들을 카드에 의해 수행하는 것이 가능하다.

바람직하게는, 칩카드는 트랜잭션들의 실행 동안 교환되어지는 데이터가 그속에 기록되거나 또는 그로부터 읽혀지는 전송저장지역(transfer storage region)을 더 포함한다. 전송저장지역으로부터의 데이터 읽기의 경우 단말에 특별한 키(terminal-specific key)들이 제공되어야 하는 까닭에, 개별 접근(access)들은 보안의 관점에서 서로로부터 독립적으로 다루어진다.

카드에 마련된 개개의 부분구조들 또는 응용들은 바람직하게는 상호 독립적이고 각각은 특별한 서비스공급자에 할당된다. 그것들은 말하자면, 이 서비스공급자에 독점적이거나 또는 특별하게되는, 특별한 응용을 수행하기 위한 데이터를 나타낸다. 응용유형(application type)에 의존하고 서비스공급자에 의존하여, 그것들은 그러므로 다른 정보, 예를 들면 특별한 값(specific value, 보너스포인트, 계정잔액(accoum balance) 등)을 나타내는 데이터, 응용에 관련한 정보데이터, 서비스 공급자에 관련한 정보데이터 등을 담고 있다. 바람직하게는, 그러나, 그것들은 특히 응용들에 특별한 키들을 담고 있고, 이것들에 의해 부분구조의 데이터에 대한 접근은 보안기술적으로 다른 부분구조들로부터 독립한 방식으로 가능한 것으로 다루어진다. 한편, 부분구조 또는 응용 자체의 올리기 또는 발생하기는 적어도 하나의 중첩된 시스템키에 의해 안전하게 보호된다.

바람직하게는, 트랜잭션의 실행 이전에, 칩카드 및 단말 사이에서 상호인증(mutual authentication)이 일어나야 하고, 응용인, 개별적으로 부분구조에 특별한 인증키가 그 목적을 위해 제공되어야 한다.

트랜잭션들을 실행하기 위하여, 데이터들은 특별한 VAS-응용을 위해 예약된 부분구조에 기록되거나, 그로부터 읽혀지거나 또는 전송저장지역을 통해 실행된다. 우선, 응용에 특별한 키들이 사용된다. 앞에서 언급된 경우에서, 응용에 특별하고 바람직하게는 또한 단말에 특별한 키가 사용되고 이 키는 예를 들면, 카드에 제공된 키발생키에 의해 그리고 응용에 특별한 데이터로부터 발생된다. 그렇게 전송저장지역에 기록된 데이터는 서비스공급자에 의해 단말을 통해 회수(withdrawal)되어지고, 이 회수는 바람직하게는 전송저장지역에 저장된 데이터를 무효한 것으로 표시(marking)함에 의해 일어난다. 이것이 기록된 응용에 특별하지 않은 서비스공급자에 관련된다면, 이것은 이른바 인터서비스, 즉 화폐데이터(monetary data)가 다른 서비스공급자들 사이에서 카드소지자의 이익 또는 비용을 위해 교환되는 것의 실행에 관련된다.

더욱이, 추가적인 보안을 위해, PIN 또는 패스워드가 트랜잭션절차를 수행하기 위한 권리의 검증(verification)을 위해 제공된다.

카드의 가변구조는 이 카드에 대한 다른 시간들에서의 다양한 응용들의 수용(accommodation)을 여러 번 허락한다.

전송저장지역으로부터 회수된 데이터의 정확도(veracity)는 바람직하게는 서명키(signature key)의 사용에 의해 또는 디지털서명(digital signature) 또는 적어도 하나의 키를 사용함에 의해 안전하게 된다. 그러나, 이러한 경우에 있어서, 특히 이로운 것은 회수된 데이터는 전송저장지역에 남아있고 단순히 카드를 통해 회수완료 되었음을 레이블로 표시한다는 것이다. 이 방식에서는 트랜잭션이 일어난 이후에서조차도 수행된 트랜잭션에 관련된 정보를 얻는 것이 여전히 가능하다. 이 방식으로 그리고 회수의 안전하게하기(securing)를 통해, 트랜잭션이 단지 한번 수행되었음을 입증할 수 있다.

게다가 특히 이롭기로는 전송저장지역에 기록된 데이터가, 그 이후에는 그 값어치를 잃어버리는 만료일자(expiry date)로 부호화된다는 것이다. 따라서, 예를 들면, 이용할 수 있는 표(ticket)를 특별한 기간에 대해서만 유효하게 만드는 응용들을 수행하게 하는 것이 가능하다.

바람직하게 제공되는 트랜잭션카운터에 의해, 개별적으로는 그것들의 관련된 트랜잭션에 대한 값데이터인, 트랜잭션일자들은 명확하게 결정되고 식별될 수 있다.

유익한 실시예에서, 본 발명에 따른 칩카드는 그러므로 계층데이터베이스개념을 포함하고, 이 개념의 개별 수준들(planes)에서는 데이터베이스에 저장된 응용에 관한 응용들의 레벨에서 가변하는 변형들에 대항하는 다른 키들에 의해 안전하게되며, 각각의 개별 응용은 나머지에 독립하게 되며 그것이 소유한 특별한 키에 의해 그 나머지에 관련하여 안전하게 되고, 전체 구조는 카드플랫폼 자체에 독립하게 되며 적어도 하나의 시스템키에 의해 그리고 그 구조를 식별하는 부호화에 의해 안전하게 된다. 전송저장지역의 개념은 데이터의 교환을 카드소지자 및 서비스공급자 사이에서 뿐 만 아니라 다른 서비스공급자들 사이에 허락한다. 또한, 전송저장 지역으로부터의 읽어내기 또는 그 속으로 기록하기는, 비슷하게는 카드 및 응용에 특별하고, 부가적으로는 또한 단말에 특별하게 되는 키들에 의해 안전하게 된다. 각 트랜잭션 이전에 수행된 인증 뿐만 아니라 취사선택적으로는 PIN 또는 패스워드는 본 발명에 따른 칩카드의 보안을 증진시킨다.

청구항 21 내지 30에서, 본 발명에 따른 칩카드와 함께 사용하기 위한 단말이 정의된다. 이 단말은 응용들을 올리기 또는 삭제하기 위해, 트랜잭션들을 수행하기 위해, 데이터의 보이기(view)를 위해 뿐만 아니라 개개의 응용들 및 트랜잭션들에 관련하여 추가 기능들을 수행하기 위해 소용된다. 카드소지자 및 서비스공급자들 사이의 트랜잭션들을 수행하기 위한 처리(process)는 청구항 31 내지 33에서 한정되며, 본 발명에 따른 칩카드로의 데이터 올리기는 청구항 34 및 35에서 한정되고, 청구항 36은 칩카드 및 단말을 포함하는 전체 시스템을 한정한다.

다음에서, 바람직한 예를 통하여 본 발명은 첨부한 도면들을 참조하여 설명된다.

도 1은 본 발명에 따른 칩카드를 개략적으로 보여주며,

도 2는 이 발명의 전체 시스템의 구성요소들의 개략도이며,

도 3은 전체 시스템에서의 데이터흐름을 보여주며,

도 4는 트랜잭션모형(model)을 통해 가능한 응용 클래스들 및 동작들을 개략적으로 예시하며,

도 5는 본 발명에 따른 칩카드의 보안구조의 개략적인 예시이며,

도 6은 VAS-컨테이너의 일반적인 구현클래스(implementation class)의 데이터구조를 보여주며,

도 7은 본 발명의 작업예에 따른 VAS-컨테이너의 다양한 구현클래스들을 보여주며,

도 8은 본 발명의 작업예에 따른 VAS-컨테이너의 데이터베이스구조를 보여주며,

도 9는 구현클래스인 DF_PT의 데이터베이스구조를 개략적으로 보여주고,

도 10은 구현클래스인 DF_AD의 데이터베이스구조를 개략적으로 보여준다.

이 발명을 상세히 설명하기에 앞서, 사용된 여러 용어들을 다음과 같이 정의한다:

VAS: 부가가치서비스(Value Added Services)

VAS-카드: VAS-카드는 이것에 의해 부가가치서비스에 관여(participate)하는 것이 가능한 칩카드이다. 다른 응용들 예를 들어 지불응용들(즉, 전자화폐지갑들) 같은 것들과 마찬가지로 VAS-카드는 VAS-컨테이너를 담고있다.

VAS-컨테이너: VAS-컨테이너는 VAS-응용들을 관리하기 위한 그리고 VAS-응용들의 기능성의 효용(availability)을 위한 데이터구조들, 접근조건들, 키들 및 (보충) 명령들을 포함한다.

VAS-응용: VAS-응용들은 VAS데이터를 담고 있다. VAS데이터에 대한 접근은 VAS-응용에 의하여 제어된다. VAS-공급자는 VAS-컨테이너에서 하나 이상의 VAS-응용들을 작동시킨다. VAS-응용의 이용동작(utilization)은 VAS데이터의 응용, 읽기 및 처리하기(processing)에 의해 한정된다. VAS-응용은 인트라서비스 또는 인터서비스중의 어느 하나의 형태를 취할 것이다.

VAS-공급자: VAS-공급자는 그의 VAS-응용에 대해 이것을 시스템운영자의 기본조건들에 따라 그리고 그가 지닌 재량에 따라 발전시키고 그에 따라 카드소지자에 대해 시스템운영자 및 단말들에 의하여 사용할 수 있게 할 책임이 있다. VAS-응용들은 VAS-카드가 이것들에 관여하는 것이 가능해지기 이전에 VAS-카드의 VAS-컨테이너 속으로 올려지게된다.

인트라서비스: 인트라서비스는 개별 VAS-공급자의 독점관리 하에서 이용되는 VAS-응용의 일종이다. 인트라서비스응용들은 폐루프응용들로서, 외부협력자들에 의한 회계(accounting) 또는 실행전송이 일어나지 않게 한다. VAS-응용은 인트라- 또는 인터서비스 성질들 중의 어느 하나일 것이다.

인터서비스: 인터서비스응용들은 부가적인 외부연결들에 의하여 외부협력자들과 상호작용하는 인트라서비스응용들이다. VAS-응용은 본래 인트라 또는 인터 서비스 중의 어느 하나이다.

SO, 시스템운영자: 시스템운영자는 VAS-공급자들 및 카드소지자들에게 그들에 의한 사용을 위한 VAS시스템을 제공한다.

발행인(issuer): 발행인 또는 카드발행인은 VAS-컨테이너들을 포함하여 VAS-카드들을 유통(circulation) 속으로 가져온다.

CH, 카드소지자: 카드소지자(cardholder) 또는 카드소유자(proprietor)는 부가가치서비스들에 관여하기 위하여 카드(이 경우, VAS-카드)를 소유하며 사용하는 사람이다. 이 사람은 카드의 실제 임자(owner)일 필요는 없다.

서비스단말: 서비스단말은 VAS-응용들을 위한 시스템운영자에 의해 조정된다. 서비스단말에서 카드소지자는 VAS-응용들을 그의 VAS-카드에서 관리(VAS-응용들의 올리기, 보이기, 삭제하기 및 전송)한다.

딜러(dealer)단말: 딜러단말은 지불기능을 소유하고 이에 더하여 VAS기능성을 제공한다. 이것은 카드소지자가 그의 VAS-카드를, 한편으로는 지불하는데, 그리고 다른 한편으로는 VAS의 이익에 관여하는데 사용하는 곳이다.

AID, 응용식별자: 카드의 데이터베이스에 대한 지식 없이 응용들의 모호하지 않은 구별 및 외부로부터의 응용의 선택을 위한 16바이트보다 길지 않은 응용들의 이름. AID는 5바이트 길이의 등록응용공급자(Registered application provider)ID(RID) 및 취사 선택적으로는 11바이트보다 길지 않은 소유응용식별자등록(Proprietary identifier registration; PIX)으로 구성된다.

DF: ISO 7816에 따른 디렉토리파일.

EF: ISO 7816에 따른 요소파일(elementary file).

타당한 VAS-컨테이너: 외부 세계에 관하여 그 자체를 인증하는 능력을 갖는 VAS-컨테이너.

KID, 키식별자: 키들을 담고있는 요소파일 내 키의 번호.

R&R: 규약(Rules and Regulations).

p: 구현클래스인 DF_PT의 객체(object)들의 최대갯수.

a: 구현클래스인 DF_AD의 객체들의 최대갯수.

nr_DIR: 객체들의 최대총갯수: nr_DIR= p + a.

EF_DIR에서 레코드갯수는 nr_DIR.

nr_{EF_TRANSFER}: EF_TRANSFER의 레코드 수.

도 1은 본 발명에 따른 칩카드를 개략적으로 보여준다. 제조공정 동안에 인가되는 정적이며 불변인 데이터, 이를테면 으뜸(master)파일(MF) 및 (취사 선택적으로 제공되는) 화폐지갑기능에 더하여, 본 발명에 따라서 카드에 추가로 제공되는 것으로는 색인(index) 또는 데이터구조 또는 데이터베이스구조(DF_VAS)가 있다. 이것은 부가기능성(additional functionality)들인 이른바 부가가치서비스들(VAS)을 수용하는데 소용된다. 나중의 경우, 다시 말하면 카드가 제조된 이후에, 카드에 올려질 것인 응용들을 나타내는 부가기능성들을 기초로 하여, 카드의 기능성들 및 이것과 함께 수행되어질 트랜잭션들에 관하여 카드는 적응하며(flexible) 가변적이다. 본 발명에 따라서 칩카드에 제공된 이른바 VAS-컨테이너(DF_VAS)는 그것의 기능들에 대하여 칩카드의 가변성 및 적응성(flexibility)을 허락하고, 그 외에도 칩카드에 수용된 응용들을 카드플랫폼으로부터 보안기술적으로 배포(release)시켜, 이것들을 카드플랫폼으로부터 독립하게 하고 이것들이 또 다른 카드로 전송되게 한다.

본 발명에 따른 새로운 부가기능성들(부가가치서비스들, VAS)은 마이크로프로세서칩카드들에 의하여 실현된다. 이러한 부가기능성들의 전환(conversion)은 VAS-컨테이너에 의해 일어난다. 마이크로프로세서칩카드 상의 VAS-컨테이너는 VAS-응용들을 수용하기 위한 플랫폼을 구성한다. VAS-응용들은 특별한 부가기능성들의 개별적인 실현(realization)들이다.

전자화폐지갑의 경우에, 카드(지불기능) 및 VAS-응용(부가기능성)의 이용동작에 의한 지불은 별도의 메커니즘들에 의해 수행되고, 이것들은 그러나, 카드사용자 또는 카드소지자에게는, 단일 절차(procedure)로서 보여진다.

마이크로프로세서 칩카드는 VAS-컨테이너에 의해 확장되어, 다양한 독립한 응용들을 수용할 수 있다. 이것은 응용을 위한 이용할 수 있는 기능들인, 응용들의 삭제 및 전송을 만들어 내고, 이런 것들은 허가된(authorized) 시스템운영자에 의해서만 사용된다. VAS-컨테이너는 데이터보안기술적인 관점에서 마이크로프로세서칩 상의 다른 시스템구성요소들로부터 독립한다. VAS-컨테이너는 완전히 자가정의 되고(self-defined) 단독으로 기능한다. 독립한 보안구조가 이것을 위해 정의되고, 그래서 VAS-응용들은 독립한 보안기능들을 이용한다. 보안구조는 제조자에 특별하지 않고 카드플랫폼의 식별특징(features)에 독립하는, 카드특별키(card specific key)들을 이용한다.

VAS-컨테이너는 또한 단말에 특별한 키들을 구동하기 위한 메커니즘들을 사용한다. 이것들에 의하여, VAS-컨테이너 자체는 개별적으로 데이터를 발생하는 단말들의 확실성(authenticity)을 능동적으로 점검한다.

VAS-컨테이너에서, VAS-응용들은 철해지고(filed), VAS-컨테이너의 메커니즘을 통하여 데이터를 이용할 수 있고, 그에 의해 관련된 인터페이스지점들의 제어를 일어나게 한다. VAS-컨테이너는 협력자들 간의 인터서비스들을 위해 데이터의 안전한 상호교환을 허락하고 또한 제어한다. VAS-컨테이너는 제어, 즉 전송된 데이터값들의 확실성 및 유일성(uniqueness)을 능동적으로 처리한다.

다중응용카드들에 대해 다른 접근법들과 비교되는 VAS-컨테이너의 이점은 이개념이 특별한 카드플랫폼으로부터 독립하다는 것이다. 이것은 플랫폼에 특별한 보안메커니즘들에 독립하는 보안구조(이를테면 키들, 식별데이터, PIN, 서명절차들)를 제공한다.

VAS-컨테이너 개념의 추가적인 이점은 카드 상의 다른 응용들의 갯수가 카드제조 또는 카드발행 시기에 한정 및 필수전제조건(preconditions)에 의해 엄격하게 기설정되지 않는다는 것이다. 응용들을 현재의 카드에 올리는 것은 카드사용자에 의해 자유로이 선택될 것이고 특별한 카드에서 이용할 수 있는 저장용량에 의해서만 제한된다. 임의의 주어진 시간에 카드에 올려지는 VAS-응용들의 갯수는 카드의 실제 사용에 의존한다. 카드사용자는 개별적으로 VAS-응용들을 후속하는 단계에서 그 조합을 변형시킴을 필요로 하는 그의 카드에 모은다. VAS-컨테이너는 카드의 제품수명 동안 카드기능성이 응용의 갯수 및 성질에 대해 가변하는 방식으로 모아지고 사용되어지는 다기능카드를 허락한다. 따라서 과거의 개개의 특수카드들이 필요하였던 응용들을 단일 카드에 올리고 함께 사용하는 것 또한 가능하다. VAS-응용들은 또한 다른 카드들로 전송될 것이다. 따라서, VAS-응용들은 카드의 제품수명을 지나서도 살아남을 것이고, 이와 같은 응용들의 제품수명 동안 카드사용자를 수반한다.

부가서비스들을 지닌 마이크로프로세서칩카드는 접근이 데이터를 보호해야만 하는 배포(distribution) 및 매매를 위한 적절한 매체이다. 이 마이크로프로세서칩카드는 지불의 수단, 계수장치 및 값저장을 위한 것으로서 사용될 것이다. 이 카드는 부가서비스들을 제공할 것이고, 의뢰인 자신에 의한 그리고 카드가 적응하는 방식으로 발행된 이후의 의뢰인의 요청에 따라 부가서비스들을 제어하기 위해 사용될 것이다. 이 카드는 또한 관여하는 단말들의 확실성을 능동적으로 제어하고 전송된 데이터의 유일성 및 확실성을 안전하게 한다.

도 2는 시스템도를 보여준다. 이 도면은 시스템구성요소들을 도시한다. 시스템운영자는 시스템을 이용할 수 있게 만든다. VAS-응용들은 서비스단말들(ST)에 올려지며, 삭제되고 전송될 것이고, 그 추가 동작들로는 VAS-응용들의 선택, 보이기, 해석(interpretation) 등이 있다.

VAS-응용들의 공급자들인, 이른바 VAS-공급자들은 그들이 소유한 VAS-응용들을 시스템운영자의 기본조건들에 따라, 그리고 되도록이면 그들 스스로의 요청에 따라 설계한다. 대응하는 단말프로그램들은 그 다음에는 종결에 의한 확실성을 위해 디지털서명으로 점검된다.

도 3은 시스템의 데이터흐름을 도시한다.

VAS-응용들은 카드사용자들의 단말에서 시스템운영자에 의한 사용에 이용할 수 있게 만들어진다. VAS-응용들은 이것들에 대한 관여가 가능해지기 이전에, 본 발명에 따른 칩카드의 VAS-컨테이너에 올려져야 한다.

딜러단말(HT)에서, 카드에 존재하는 VAS-응용들은 VAS-데이터의 응용 또는 삭제하기에 의해 사용된다.

마이크로프로세서칩카드에 VAS-기능성을 제공하기 위하여, VAS-컨테이너는 존재하는 응용들(예를 들면, 전자화폐지갑과 같은 지불응용들)에 더하여 카드에 인가된다.

VAS-컨테이너는 VAS-응용들의 넣기(entering), 삭제하기 및 전송하기를 허락하는 기능들을 사용한다. 이러한 관리기능들은 시스템운영자에 의해 독점적으로 사용되고 대외적인 사용에 대항하여 카드에서 안전하게 된다. VAS-컨테이너는 VAS-응용들 간에 데이터의 교환이 일어나게 하는 전송데이터저장기를 구비한다.

두 개의 명령들인 TRANSFER 및 TAKE는 전송저장기를 제어하기 위해 사용된다. 명령인 TRANSFER는 개개의 응용에 특별한 데이터를 사용하여 전송저장기에 엔트리(entry)를 발생한다. 유용한 데이터 외에도, 이것들은 더욱이 처리하기의 제어에 필요한 날짜, 만료날짜 및 식별데이터와 같은 엔트리들을 구비한다. 명령인 TAKE에 의하여, 객체들은 전송저장기로부터 회수되고 회수완료된 것으로 표시된다. 특별한 응용에 의존하여, 객체들은 타당한 것으로 남겨졌거나 또는 무효로 된 것으로 표시된다. 전송된 데이터는 VAS-컨테이너에 의해 확실성 및 유일성에 관하여 점검된다.

VAS-응용들은 응용들을 이용할 수 있게 그리고 제어하게 만들기 위해 VAS-데이터를 이용한다. VAS-데이터에 대한 접근은 VAS-응용에 의해 VAS-컨테이너에서의 모든 응용들에 대해 이용할 수 있게 만들어진 메커니즘들을 이용하여 제어된다. VAS-공급자는 VAS-컨테이너에서 하나 이상의 VAS-응용들을 운영한다. VAS-응용의 사용은 VAS-데이터의 넣기, 읽기 및 처리하기에 의해 한정된다.

VAS-컨테이너는 인터서비스들을 지원한다. 인터서비스들은 다른 협력자들 사이의 명령데이터에 대한 접근, 서비스명령들의 전송 및 서비스들의 송장발송(invoicing)을 요구한다.

다음으로, 본 발명에 따른 칩카드에 의해 가능하게 만들어진 서비스들 및 응용들은 예들에 관련하여 목록(list)에 기재된다.

각 경우에, 기술(description)은 이 기술의 현재 상태에 따른 실현 및 기능에 관련한다. 장래에는, 그 기능은 하나 이상의 VAS-응용들에 의해 흡사하게 되어질 것이다.

첫째로, 인트라서비스들이 제시되어진다.

예 A: 고객클럽(customer club)

백화점은 고객클럽을 운영한다. 고객은 클럽회원(club member)이 되고 이 신분(status)에 따라 비회원이 이용할 수 없는 특별한 클럽서비스들을 받는다. 오늘날 클럽회원은 그 자신을 클럽환경에서 클럽회원자격문서(club membership document)로 확인한다. 클럽회원자격문서는 가입할 때 준비되고, 이전할 수 없고, 대개 제한된 기간을 갖는다. 특별한 트랜잭션들이 클럽회원자격카드를 통해 실행되지 않는다. 즉, 고객 총거래액(turnover)과의 연계(linkage)가 없다. 이런 식으로 클럽회원자격카드는 신분 및 총거래액 사이에 연결이 존재하는 보너스프로그램들로부터 분리된다.

유사물(analogue): 도매(wholesaler)회원자격카드, 상원의원(senator)카드, 북클럽카드.

대상(object): 클럽회원자격은 VAS-컨테이너에서의 응용에 의해 증명되어진다.

예 B: 보너스시스템

고객은 보너스청구(bonus claim)에 의해 각 트랜잭션에 대해 신용있게 된다. 보너스청구는 누적되고 고객에 의해 결정되는 때에 화폐이익(monetary benefit)으로 환전되어진다. 보너스청구는 정해진 기간에 대해 타당하고 익명으로 관리되거나 개인에 관련 되어진다. 보너스청구는 총거래액 또는 사용횟수로부터 일어난다.

유사물: 마일의 점수상태 등등

대상: 점수계산(points account)은 VAS-컨테이너에서의 응용에 의해 관리되어진다.

예 3: 할인

고객은 일정잡힌 총거래액 할인을 받는다. 이 할인은 각각의 독특한 트랜잭션에 대해 인정된다. 카드는 총거래액 내역을 관리하지 않는다. 각 트랜잭션은 독립적이다.

대상: 할인자격(entitlement)은 VAS-응용에 의해 인증되어진다.

예 D: 신원확인문서(identity document)기능

사람은 카드에서의 특징들에 의해 제 3자들에게 기설정된 서비스들에 대한 그의 자격을 입증할 수 있게 된다. 이 사람과 신원확인문서 사이의 연관(association)은 각 트랜잭션을 위해 증명되어야 한다(사진, PIN, 생물측정학).

유사물: 인터넷접근, 홈뱅킹에 대한 접근, 전화카드

대상: 허가(authorization)는 VAS-응용에 의해 입증되어진다.

예 E: 가치단위(value units)

가치단위들은 단일 또는 다중 사용들에 의해 구입되고 소비된다. 각 트랜잭션에 의해, 그 가치는 하나 이상의 단위들만큼 감소된다. 사용자자격은 이전가능하고 사용에 따라 제한되어진다.

유사물: 단일여행티켓, 다중여행티켓, 기부자콘서트티켓, 스쿼시 10포인트티켓, 영화티켓, 전화단위량(telephone units).

대상: 트랜잭션은 VAS-응용에 의해 합리적으로 되어진다.

예 F: 사용자 송장발송

서비스의 사용자는 시간, 회수, 또는 량의 항목들로 기재되고 요금표(tariff)에 따라 송장 만들어진다. 서비스가 요청되는 범위는 미리 알려지지 않는다.

유사물: 식사전표(meals voucher), 단기주차티켓.

대상: VAS-응용에 의해, 요금표에 따른 송장발송이 허락될 것이다. 각각의 특별한 상황에 적절한 송장 데이터는 VAS-컨테이너에 저장될 것이다.

예 G: 데이터레코드(이동형 데이터베이스)

이 응용은 카드소지자 데이터의 VAS-공급자로의 전송을 허락한다. 트랜잭션들은 이에 의해 자동화되나 현재로는 여전히 수동으로 진행할 것이다. 화폐전송은 이러한 데이터로부터 유도되지 않을 것이다.

유사물: 총풀인환권의 만기(completion of numbers pool vouchers, 쇼핑리스트들, 현금영수증들(cash receipts), 전화레지스터들.

대상: VAS-공급자는 요구된 서비스를 직접 제공(예, 총풀인환권의 전화연결, 수집 원하는 구매물들, 전자적인 완성(electronic completion) 및 기록을 제공)할 수 있도록 하기 위하여 카드로부터 데이터를 끌어낸다. 이 데이터는 카드에 단기간 또는 장기간 중의 어느 하나로 저장될 것이다.

인트라서비스들의 이러한 예들은 인터서비스들을 위한 일부의 예들이 뒤따른다.

인터서비스들은 복수의 VAS-공급자들이 서비스에 관여할 때마다 일어난다. 이것은 비가변적으로 데이터에 연결되어 한 VAS-공급자의 환경을 남겨둔다. 날짜에 이것은 종이기록에 의해 수행된다.

예 A: 여행비용상환(refund)

백화점은 이 백화점으로 이동해갈 수 있도록 공공운송기업의 여행티켓을 고객에게 상환한다. 고객은 백화점에 단일 여행티켓을 내보여야 한다. 백화점은 티켓에 이 티켓이 상환되었음을 기록한다. 백화점은 다시 운송기업으로부터 고객에 대한 상환의 일부를 받을 것이다.

대상: 상환절차는 전자적으로 수행될 것이다.

예 B: 여행인환권(travel voucher)

백화점은 구매가 있을 때에 인환권을 발행함으로써 고객에게 귀가(homeward trip)를 위한 비용을 상환한다. 티켓취급소에서 고객은 공공운송기업으로부터 티켓을 받거나 저가로 그 티켓에 대해 지불한다. 운송기업은 그 백화점에 대해 그 인환권에 대하여 송장발송한다.

대상: 거래 및 공공운송기업 사이의 전자회계(electronic accounting)에 연루하는 VAS-응용들에 의한 메커니즘들의 모방(mimicking).

예 C: 고객주차

백화점은 고객에게 주차요금의 일부를 특정한 주차차고를 이용하는 경우에 상환한다. 이 주차차고는 독립한 기업에 의해 운영되고 백화점으로부터 각 고객크레디트에 대하여 화폐지불을 받는다.

대상: 거래 및 공공운송기업 사이의 전자계정에 연루하는 VAS-응용들에 의한 메커니즘들의 모방.

예 D: 다각적인(multilateral) 보너스 프로그램

일 군의 무역회사들 및 서비스공급자들은 연대(joint)보너스프로그램에 합의한다.

대상: 각 협력자는 카드의 통상의 회계에 대하여 보너스점수를 대변에 기입(credit)하거나 차변에 기입(debit)한다. 협력자들 사이의 서비스들에 대한 회계는 우선하는 시스템(underlying system)에 의해 진행한다.

예 E: 서비스공급자들 사이의 보너스점수의 인정

각 서비스공급자는 자신이 소유한 보너스프로그램을 운영하나 모아진 점수에 대해 다른 공급자들과 동의하는 것으로 취급한다. 알려진 예들로는 차임대업자들(car rentals) 및 항공회사들 사이의 모아진 "마일들"에 대한 동의들이 있다.

대상: 카드를 통한 보너스점수의 이전을 지원. 각 VAS-공급자는 초기에는 다른 사람들에 의한 간섭 없이 혼자 힘으로 그의 점수를 모은다. 어느 일정한(certain) 메커니즘들은 이 전송에 이용할 수 있게 만들어진다.

예 F: 야간택시(night taxi)

공공운송기업의 여행티켓을 구입함으로써, 공동택시(collective taxi)(예. 22시 이후)는 동시에 취득된다. 회계의 목적을 위해, 택시회사는 여행티켓이 제출되었음을 증명해야 한다. 택시의 사용은 악용을 피할 수 있도록 하기 위하여 그 티켓에 기록된다.

대상: VAS-응용은 이 서비스의 이용동작, 제어 및 회계를 허용한다.

다음으로, 본 발명에 따른 칩카드의 구성을 추가 설명한다.

보다 상세하게는, VAS-기능성을 지닌 마이크로프로세서칩카드는 VAS-컨테이너를 담고 있다.

VAS-컨테이너는 응용을 그것이 소유한 권리로 구성하고 단독으로 또는 기본카드플랫폼에 대한 다른 응용들에 병행하여서도 존재한다. VAS-컨테이너는 완전히 자기한정되고 스스로 기능한다. 이것은 동일한 카드에 통상적으로 제시된 지불기능없이 동작될 수 있다. 특히, 독립한 보안구조는 VAS-응용이 독립한 보안기능들을 이용할 수 있도록 VAS-컨테이너에 대해 정의된다.

부가가치서비스들의 일부는 VAS-공급자들의 단말들에서 수행된 의뢰인에 의한 트랜잭션들이다. VAS-공급자는 시스템제어의 목적을 위해 또는 통계치 및 다른 데이터의 수집을 위한 것으로 이러한 트랜잭션들을 모니터링하는데 흥미를 가진다. 카드에서 데이터구조들을 최적화하고 단일화하기 위하여, 응용에 특별한 식별들의 사용이 권고되지 않으며 전체 시스템에 이용할 수 있는 모호하지 않은 VAS-컨테이너ID의 사용이 권해진다. 이 번호는 전술한 기능들을 실행하기 위해 VAS-공급자에 의해 사용될 수 있고 스스로 시스템들을 번호매기는 관리의 부담으로부터 공급자를 해방시킨다.

VAS-컨테이너의 보안구조는 카드에 특별한 키들을 얻기 위하여 이 시스템을 폭??은 모호하지 않은 ID로 사용한다. 카드에 특별한 번호의 사용은 원칙적으로는 가능해지나, VAS-컨테이너가 다른 플랫폼들에 구현되어야 한다면 이것들이 어떤 경우에는 충돌하는(clashing) 번호매김시스템들을 사용하기 때문에, 바람직하게는 사용되지 않는다.

VAS-컨테이너ID는 VAS-컨테이너를 발생하는 경우 시스템운영자에 의해 발행되고 카드발행자에 의해 기입된다. 이것은 VAS-컨테이너를 삭제함에 의해 파괴되고 이에 의해 시스템으로부터 제거된다. VAS-컨테이너는 이것이 VAS-응용들을 담고있지 않고 VAS-컨테이너ID가 제거되었다면 삭제완료된 것으로 간주된다.

헌 카드로부터 새 카드로의 VAS-컨테이너의 전체 전송 동안, VAS-컨테이너ID는 VAS-응용들과 연대하여(jointly) 전송된다. 이 전송은 헌 카드로부터 새 카드로의 VAS-컨테이너의 이전(removal)에 해당한다. 이 절차 이후에, 헌 카드는 더 이상 VAS-컨테이너를 담지 않는다. 새 카드에 존재하는 VAS-컨테이너는 이 동작 동안 겹쳐 쓰여져 삭제된다. VAS-컨테이너ID는 헌 카드로부터 새 카드로 전송되므로, 참조번호들의 변형이 VAS-공급자들의 기본시스템들에 필요하지 않다.

개개의 VAS-응용들은 두 개의 다른 VAS-컨테이너들 사이에서 우세한 VAS-공급자의 제어 하에 전송될 수 있다. 이 기능 동안에, VAS-컨테이너ID 및 VAS-응용 사이의 연관은 변경되어 VAS-공급자의 기본시스템에 기록될 것이다.

VAS-컨테이너는 개인적인(personalized) 특징들을 담지 않는다. VAS-응용들은 개인적인 데이터를 담을 것이며, 그러나, 그것의 범위는 데이터보호이유를 위해 그리고 개선된 메모리이용동작을 위해 최소로 유지될 것이다. VAS-응용들은, 필요하다면, 개인에 관련된 데이터를 기본시스템에 저장할 것이고 VAS-컨테이너ID에 의하여 카드와의 연관을 만들어낼 것이다.

인터서비스들의 지원은 VAS-컨테이너의 중요한 특징을 구성한다. 인터서비스들은 공유데이터(common data)에 대한 접근, 서비스청구들의 전송 및 다른 협력자들 사이의 서비스들의 회계를 요구한다. VAS-컨테이너는 이러한 것들을 가능하게만들 것이고, 그럼에도 불구하고, 인트라서비스에서의 응용들의 보안을 보증한다.

이른바 인트라서비스 VAS-응용들은 VAS-공급자의 배타적인 제어 하에서 운영된다. VAS-공급자는 그 응용의 보안을 임의의 외부 엔티티(entity)로부터 독립적으로 정의한다. 외부 당사자(external party)는 키의 급격확증(proliferation) 없이 VAS-데이터를 변형할 수 있다.

인터서비스들의 효과적인 실행을 위해 협력자들은 공유데이터에 접근할 수 있어야 한다. 데이터에 대한 연대접근은 다중단계 보안메커니즘들에 의하여 실현된다.

연대접근의 첫 번째 단계는 공공전송필드들에 의하여 배타적으로 진행한다. VAS-공급자들은 데이터를 필요한 응용들 및 키들의 상호 이해 없이 이러한 필드들에 의하여 상호 교환할 것이다. 단말들은 오로지 데이터를 전송필드들에 넣기 위한 적절한 키들을 요구하나 읽기 위한 키를 요구하지는 않는다. 누구든지 제한없이 읽을 것이다. 데이터상호교환은, 각각이 데이터를 넣는데 이용할 수 있는 그의 키를 가진다면, VAS-공급자 및 협력자 사의의 양방향들로 진행할 것이다. 전송데이터는 VAS-공급자의 인트라서비스 VAS-응용으로부터 발생되어질 것이며, 또는 그 반대로 VAS-공급자는 전송필드로부터의 데이터를 그의 인트라서비스 VAS-응용 속으로 넣을 것이다.

두 번째 단계는 VAS-데이터에 의해 표현되는 가치단위들(value units)의 말소(cancellation)이다. VAS-공급자는 데이터를 넣기 위한 특수키에 의하여 가치단위들을 VAS-데이터 속으로 도입한다. 가치단위들은 포괄적인 책임이 있는 VAS-공급자로부터 얻어진 단위말소용 키를 이용할 수 있는 인터서비스협력자들에 의해 소비되어질 것이다. 이 단계에서, 상호 다른 권리를 갖는 협력자들은 비대중적인(non- public) VAS-데이터로 서로 영향을 끼친다.

세 번째 단계는 모든 관여하는 인터서비스 협력자들에 의한 VAS-데이터에 대한 직접데이터엔트리접근이다. 이 방법은, VAS-데이터가 제한없이 변형될 수 있기 때문에, 당사자들 사이에 적당한 정도의 신뢰를 요구한다.

전송필드는 VAS-응용들 사이의 연결로서 소용된다. 전송필드에서의 데이터는 VAS-응용들에 의해 VAS-컨테이너에서 발생된다. 데이터는 또한, 사람이 그가 소유한 VAS-응용이 VAS-컨테이너에서 운영되지 않게 한다면, 전송필드로 직접 들어갈 것이다.

전송필드는 원리적으로는 모든 응용들에 대해 이용할 수 있으며, 그러나, 엔트리들은 그것에 대해 (키에 의해) 자격있게 된 사람에 의해서만 만들어질 것이다. 오로지 규정들(regulations), 즉 규약(R&R)이라는 점에서 그것에 대해 자격있게 된 수신자들이 전송필드로부터 데이터를 제거할 것이다. 수신자는 그에게 지정된 전송 데이터의 존재에 대해 점검하고 이것들을 그가 소유한 시스템에서의 처리를 위해 회수한다(withdraw).

공개적인 상호교환에서 전송데이터의 조작을 예방하기 위하여, 발생자(generator)는 확실성특징을 도입하고 VAS-컨테이너는 순차번호(sequence number)를 도입한다. 전송보고서의 단일성은 이러한 요소들에 의해 안전하게 되고 이 데이터의 출처(origin)가 증명된다.

필요한 경우, 전송데이터의 수신자는 발생자에 의해 확실성점검을 수행하기 위한 수단이 제공받는다. 이것이 원해지지 않는다면, 데이터의 수납(acceptance)은 좋은 신용으로 일어날 것이고, 그 경우에는, 회계가 발생하는 VAS-공급자의 기본시스템에서 일어날 때 확실성특징이 점검되는 것만이 가능해진다.

전송필드로부터의 데이터의 회수는 확실성특징의 손실없이 오직 한번한 가능하다. 회수될 때에, 그 데이터는 표시되고 전송필드에 (사본으로서) 남겨진다. 이것은 이 데이터의 회수 이후에서조차도 어느 일정한 기간 동안은 전송절차의 증명을 허락한다.

전송필드에서의 데이터는 만료일자를 운반한다. 만료된 데이터는 독단적인 응용들에 의해 요구되는 때에 겹쳐 쓰여질 것이다. 전송필드의 이 데이터는 회수로 표시되어져 즉각적인 겹쳐쓰기를 위해 자유롭게 될 것이다. 전송저장기는 그럼에도 불구하고 전송데이터 세트의 만료 이전에 완전히 채워져야 하므로, 카드소지자는 서비스단말에서 더 이상 필요하지 않은 엔트리들을 삭제해야 한다.

VAS-응용들의 모형화(modelling)를 위해 3개의 동작(operation)들이 정의된다. 이러한 동작들은 VAS-데이터에 작용한다. 응용들의 올리기 및 삭제하기는 VAS-컨테이너의 기능들이고 다음의 단락들에서 고려되지 않는다.

구매하기(purchasing): 일반적으로, VAS-응용의 VAS-데이터에서의 서비스들에 대한 자격의 구매 및 그것의 증명의 철하기.

말소하기(cancelling): 일반적으로 응용의 VAS-데이터의 전부 소비로 또는 소비 없이 또는 부분적인 소비로 자격의 태환(redemption). 이 절차는 전송필드에 철해지는 전자영수증을 발생한다. 이 영수증은 그 날짜에 전송저장기로부터 삭제되어지는 적절한 만료일을 제공한다.

회수하기(withdrawing): 일반적으로 추가 처리(예. 기본시스템)를 위해 전송필드로부터의 전자영수증의 검색. 영수증의 사본은 남게되고 "말소"의 증거로서 소용된다.

VAS-데이터의 "획득하기(acquiring)"는 오로지 개별 VAS-공급자를 통하여 진행한다. VAS-데이터의 "말소"는 이러한 것을 "구매하기"에 의해서 또는 VAS-공급자에 의해 그것에 대해 허가된 인터서비스협력자에 의해서 발생하였던 VAS-공급자를 통해서만 일어난다. VAS-데이터에 대한 접근에 동등한 권리가 없는 인터서비스는 상태천이인 "회수하기"의 격발(triggering)을 협력자에 의해 야기한다. 그것에 의해 되찾아진 전자영수증은 시스템운영자 및 VAS-공급자의 기본 시스템을 통해 밝혀질 것이다. "구매하기" 및 "말소하기"는 단일 단계에서 일어날 것이다.

공유특징(common feature)들을 지닌 VAS-응용들은 클래스들로 세분될 것이다. 이러한 클래스들은 VAS-컨테이너에서의 데이터구조들을 의한 기초를 구성한다. 그의 응용의 구현 동안에 VAS-공급자는 응용클래스를 선택한다.

이 상황에서는, 다음의 응용클래스들이 정의된다:

·점수데이터베이스

·티켓

·식별문서

·인환권

·데이터베이스

점수데이터베이스는 점수값들의 계정이 관리되는 응용클래스를 표시한다. 점수계정에 대해 및 이로부터, 값들이 대변 기입되어지고 회수될 것이다. 값들의 대변기입하기(crediting)는 VAS-공급자를 통해 진행되고 데이터베이스는 그 속에 새로운 계정잔액을 넣는다. 값들의 차변기입하기(debiting)는 "말소"동작에 의해 진행하여 이 상황에서 전자영수증은 전송저장기에서 증거로서 철해진다. 두 개의 기능들에 대한 접근은 두 개의 다른 접근키들에 의해 일어난다.

티켓은 그 속에 값필드가 존재하며, 말소되어져서 한번 또는 여러 번 중의 어느 하나로 소비되어질 응용클래스를 표시한다. 응용클래스(Ticket)에서 값들의 대변기입하기는 오직 한번만 실행된다.

신원확인문서는 VAS-데이터가 자격의 증거를 수신하는 응용클래스를 표시한다. 증거는 일반적으로 사용에 의해 말소되지 않으며, 그러나, 기설정된 규준들(criteria) 이후에, 예를 들면, 시간의 경과 이후에, 이것은 무효로 된다. 응용의 정의에 의존하여, 신원확인문서(예. 근처의 주차 허가)의 확실성 또는 이 문서를 제출하는 행위는 문서화된다(예. 월간티켓을 이용한 공동택시여행: 카드에 의한 전자영수증의 발생. 이 영수증은 택시회사에 의해 공공운송회사에 제출되고 비례하여 계수된다). 취사 선택적으로는, 신원확인문서의 사용은 카드의 전송저장기에서 전자영수증들에 의해 문서화되어질 것이다.

인환권은 (대개 짧은 기간에 대한) 서비스자격이 카드의 중간(interim) 저장기에 위치하게 되는 응용클래스를 표시한다. 이러한 전자인환권들은 VAS-컨테이너의 전송저장기에 배타적으로 저장된다. 인환권을 이용하는 응용은 대체로 발생하는 응용으로부터 다르다. 전송저장기로부터의 인환권의 회수는 한번만 가능하고 카드에 의해 문서화된다. VAS-컨테이너에 의해 발생된 확실성특징은 기본시스템에서의 회계 동안에 사용되어질 것이다.

데이터기억은 VAS-공급자가 의뢰인에게 부가서비스(예. 간이음식레스토랑에서 최종메뉴, 최종번호의 풀번호들, 서비스우선권들, 제안(proposal)목록들)를 제공하도록 데이터를 VAS-컨테이너에 저장하는 응용클래스를 표시한다. 이러한 데이터는 정보 만을 위한 것이고 VAS-공급자에 대항하는 서비스들에 대한 청구를 나타내지는 않는다. 이 데이터에 대한 접근은 VAS-공급자에 의해 제어된다.

각 응용클래스는 전형적인 사용자사이클에 의해 특징지어진다. 다음의 표는 세 개의 위에서 정의된 동작들이 응용클래스의 VAS-데이터에 적용되는 경우의 회수를 설명한다(주의요망: "구매하기"는 "응용의 올리기"를 의미하지 않고 "회수하기"는 "응용의 삭제하기"를 의미하지 않는다).

[표 1]

위의 표 1에서의 응용클래스인 "데이터기억"에서의^***의 경우, 자격이 획득되지 않고, 응용은 단지 데이터를 그 응용 속으로 넣는다.

도 4는 위에서 목록으로 된 응용클래스들 및 트랜잭션모형을 통한 동작들을 도시한다.

다음으로 본 발명에 따른 칩카드의 보안구조를 더욱 상세히 설명한다. 보안을 확실하게 하기 위하여, 다음의 키들이 정의된다:

[표 2]

보안구조는 VAS-컨테이너 또는 VAS-응용들의 제품수명에 근거하고 관여하는 경우들의 책임에 따라 계층화된다. 설명을 위한 개략적인 예시는 도 1로부터 명백해진다.

뒤따르는 것에서, VAS-컨테이너들의 뿐만 아니라 거기에 적용된 응용들의 구조에 대한 약간의 해명이 제공된다.

VAS-컨테이너뿐만 아니라 VAS에 특별한 보충명령은 다른 비VAS-응용들과 연대적으로 발행자에 의해 카드에 인가되거나 또는 최후에는 서비스단말에서의 현존하는 카드플랫폼 속으로 허가된 VAS-공급자에 의해 서비스단말에서 통합된다.

두 번째 가능성에 대해 다음의 메커니즘은 응용을 발견할 것이다: 시스템운영자는 발행자와 임시키(K_SO ^*)에 대해 의견일치 한다. 발행자는 그에게만 알려진 그의 키로 카드를 열며, VAS-컨테이너의 파일들을 개설하고 특히 K_SO ^*를 DF_VAS 속으로 쓴다. 시스템운영자는 나중의 어느 순간(예. 카드가 들어가서 처음으로 서비스단말과 접촉하게 되는 순간)에 키(K_SO ^*)를 그가 소유한 키(K_SO)로 대체하고 이 키(K_SO)는 그 자신에만 알려지게 된다.

시스템운영자는 그 자신이 예를 들어 KGK_DEC와 같은 추가 데이터를 넣거나 또는 그 자신이 동적메모리관리를 지닌 플랫폼의 경우에는 VAS-응용들을 위한 파일들을 발생하거나 삭제한다. 이에 의해 VAS-카드의 처음 사용 이후에 발행자는 더 이상 VAS-컨테이너에 접근하지 않는 것과 시스템운영자 만이 VAS-컨테이너에 접근하는 것을 보증한다. 임의의 공통데이터구조들 및 다른 응용들과의 데이터 상호교환의 부재 때문에, VAS-컨테이너의 보안구조는 따라서 카드플랫폼에 존재하는 다른 응용들로부터 독립하다.

그러나, 이 발명의 특수한 실시예에서는 사용이 제 1가능성(first possibility)으로 만들어진다: 발행자는 시스템운영자의 지시에 관계하여 모든 키들을 구비한 VAS-컨테이너가 VAS-카드들에 인가되는 것이 요구된다.

VAS-컨테이너는 기설정된 데이터구조, 기설정된 접근조건들(Acs) 및 약간의 전역(global)데이터로 구성된다. 전역데이터는 그 중에서도 VAS-응용들의 올리기 또는 삭제하기를 위한 키(K_SO)를 담고 있다. 시스템운영자에게만 알려진 이 키에 의해, 오로지 허락된 VAS-응용들이 올려질 수 있게 되는 것이 확실하게 된다. 이 목적을 위해 카드는 시스템운영자에 의한 K_SO를 통한 외부 인증을 요구한다.

카드소지자가 VAS-응용을 서비스단말에 올리기를 바랄 때마다, 적절한 VAS-공급자는 그에 따라 시스템운영자에게 그를 대신하여 이것을 해달라고 지시한다. VAS-응용이 VAS-컨테이너로 올려질 때, VAS-공급자는 키들(K_LVASP및 K_RVASP)을 시스템운영자에게 전송하고, 운영자는 이 키들을 응용 속으로 넣는다. 키(K_LVASP)는 VAS-공급자가 쓰기접근에 대항하여 응용의 데이터를 그리고 이에 더하여 읽기접근에 대항하여 내부 데이터를 보호하는 것을 허락한다. 이런 목적 때문에, 카드는 K_LVASP에 근거한 VAS-공급자의 외부 인증을 요구한다. 즉, 카드는 능동적으로 단말의 확실성을 점검한다. 이 기능의 성공적인 실행 이후에, 단말은 VAS-응용에 대한 쓰기접근 및 이 응용의 VAS-데이터에 대한 읽기접근이 허용된다. 내부 인증, 즉 딜러단말을 통해 확실성에 대하여 VAS-응용(및 이에 의해 카드)을 점검하는 것은 취사 선택적으로 일어난다. VAS-응용이 카드소지자에 의해 사용되는 경우, 이러한 내부 VAS-데이터는 응용에 쓰여지거나 또는 키(K_LVASP)에 대한 접근을 갖는 옵션의 단말들에서 변형되어질 것이다. "구매하기" 기능은 키(K_LVASP)에 의한 외부 인증이 그에 앞서게 되어질 것인 UPDATE RECORD 명령에 의해 지원된다.

VAS-응용의 비내부 데이터에 대한 읽기접근은 K_RVASP에 의한 또는 K_SO에 의한 또는 시스템운영자에 의한 PIN 또는 패스워드의 올바른(correct) 엔트리에 의해 이전의 외부인증이 일어나는 경우에만 허락된다. PIN/패스워드 보호된 접근은 카드소지자가 단말에서 또는 지갑(wallet)에서 데이터를 면밀히 살피는 것을 허락하기 위하여 제공된다. 카드소지자는 서비스단말에서 값 또는 상태 데이터를 읽기 위한 PIN/패스워드를 활동적이게 또는 비활동적이게 선택할 것이다.

VAS-컨테이너의 전역데이터는 전송필드로부터 추출된 서명할(signing) 데이터를 위한 키(K_{SIG_VASC})에 연관된다. 서명에 의하여, 이러한 트랜잭션데이터의 손대지 않은 부분(intactness)이 그것들이 상호 회계를 위해 인터서비스 협력자들 사이의 조작에 대항하여 보호 전송되어져야 할 때마다 점검될 것이다. 인터서비스협력자들을 통해 취사선택적으로 도입된 서명에 더하여, K_{SIG_VASC}에 근거한 서명 및 VAS-컨테이너에 의해 관리되는 트랜잭션카운터는 카드가 "회수하기" 동작을 통해 발행하는 데이터의 세트들을 위해 추가되어진다. 한편으로는 전송필드의 읽기가 임의의 하나에 의해 허락되나 다른 한편으로는 K_{SIG_VASC}를 통한 카드의 서명이 "회수하기" 동작을 위해 호출될 때에만 발생되어질 것이(고 이것은 오직 한번만 일어날 수 있)기 때문에, 인환권들에 대한 임의의 허락되지 않은 이중 회계는 인식된다. 각각의 인터서비스협력자는 시스템운영자에 의해 수신 확인된(acknowledged) 회수된 인환권에 대하여 확실성 및 유일성을 가질 수 있을 것이다. 게다가, VAS-컨테이너의 확실성은 시스템운영자의 서명을 점검함에 의해 검증될 수 있다.

카드플랫폼이 비대칭키(asymmetrical key)절차들을 사용하는 경우에, K_{SIG_VASC}로서 서명할 목적을 위한 카드 내의 개인(비밀)키를 사용하는 것 또는 이러한 키를 개인키발생키로부터 유도하는 것 또한 가능하다. VAS-공급자들은 그러한 경우에 시스템운영자에게 의견을 묻지 않고서 그들 스스로 서명을 점검하기 위한 공개(비밀아닌)키들을 사용한다.

VAS-컨테이너의 데이터의 일부는 "말소하기" 동작을 위한 권한점검을 위해 모든 VAS-공급자들의 모든 단말들에 대한 접근키(K_DEC)를 발생하는 능력을 갖는 전역키발생키(KGK_DEC)(문제의 키 유도 및 점검하기는 다시 아래에서 추가로 다루어질 것이다)에 의해 형성된다. 화폐가치데이터의 말소는 자격의 올리기 또는 구매하기와 동일한 보안척도(security measures)에 지배를 받지 않는다. 이 목적 때문에 응용에 특별한 키 대신에 전역키를 사용하는 것이 충분하다. 이 전역키는 초기에는 응용키로의 유도에 의해 전환되고 그런 이후에 다시 시작된 유도에 의해 단말키로 전환된다. VAS-공급자는 소유한 단말키를 발생하기 위해 전역키의 응용에 특별한 유도를 알려주기만 한다. 이것은 다음에서 간략히 기술된다:

우리는 mac(k, d)로 DES에 의한 DES-키 및 메시지 d를 위한 인증코드의 계산을 표시한다. 이 메시지는 8바이트보다 길지 않는 한 코드화(codification) 그 자체에 대응한다(전제 ICV=0). 우리는 macp(k, d)로 패리티비트들의 후속하는 개작(adaptation)을 지닌 mac(k, d)의 계산을 표시한다. 그 결과인 k'=macp(k, d)는 다시 한번 타당한 DES키이다.

응용에 특별한 단말키의 계산은 다음과 같이 진행한다:

1. 각 카드는 키 KGK_DEC를 저장하고, 이 키는 모든 카드들에 대해 동일하고 시스템운영자에 의해 비밀이 유지된다. 시스템운영자는 이 키가 카드속으로 개인화되는 것을 제공한다.

이 키로부터 모든 다른 VAS-응용 및 단말키들이 유도될 수 있다.

2. VAS-공급자는 VAS-응용 A를 AID_A= RID_VAS, PIX_A로 도입하는 것을 바란다. 시스템운영자는 지금 키(KGK_DEC) 및 PIX로부터 응용에 특별한 키인

KGK_DEC,PIX= macp(KGK_DEC, PIX_A)

를 계산하고 이 키를 VAS-공급자에게 넘겨준다.

3. VAS-공급자는, 그것들의 단말ID로, TRANSFER 명령이 VAS-응용 A에 인가된다고 추측되는 모든 단말들에 대해 KGK_DEC,PIX로부터 그것들의 특별한 키들인 다음을 유도한다:

KDEC = macp(KGK_DEC,PIX, 단말ID) =

macp(macp(KGK_DEC, PIX_A), 단말ID)

VAS-공급자는 이러한 키들을 그의 단말들에 저장한다. VAS-공급자가 그 단말들을 정상적으로 운영하지 못하는 경우에, 그는 이 키들을 발생하고 이것들을 단말들의 운영자들에게 배포한다.

4. VAS-카드만이 TRANSFER 명령을, 이 명령이 전송저장기에서 메시지의 특별한 데이터(data)에 의해 형성된 단말에 의해 발생된 암호(cryptogram) C를 실행한다. 이 카드 스스로는 KGK_DEC를 인식하고 단말로부터 사용자데이터(data) 및 암호 C에 더하여 단말ID 뿐만 아니라 PIX를 얻는다(또는 다른 방안으로는 카드 스스로는 PIX를 알고, 이 때문에 또한 명령인 TRANSFER의 기술을 알게된다). 카드는 지금 암호 C'을 다음의 사용자데이터를 통해 계산할 수 있다:

mac(macp(macp(KGK_DEC,PIX), 단말ID), 데이터) =

= mac(macp(KGK_DEC,pix, 단말ID), 데이터) =

= mac(K_DEC, 데이터) =

= C'

카드는 지금 자신에 의해 계산된 암호 C'을 단말에 의해 계산된 암호 C과 비교한다. 그것들이 다르다면, 트랜잭션의 종료(termination) 및 결함(fault)보고가 일어난다. 적합(congruence)한 경우에 VAS-카드는 TRANSFER 명령을 실행할 것이다.

여러 보안척도들이 서비스단말들 또는 딜러단말들(개별적으로 올리거나 구매하는 경우) 및 단순한 딜러단말들(말소하는 경우)의 다른 구성들과 일치한다. "말소" 동작을 실행하기 위하여, 단말은 K_DEC의 지식을 가짐에 의해 카드에 대해 자신을 인증해야 한다. 그 키(K_DEC)가 손상된다면, 공격자(aggressor)는 간단히 이 단일 단말의 기능을 수행할 수 있다. 그러나, 이 절차는 카드에 기록된다. 문서화(documentation)는 모호하지 않은 순차번호, 말소 및 단말ID를 담고있다. VAS-응용들은 VAS-데이터에 대한 접근을 조직화하기 위하여 VAS-컨테이너의 보안서비스들을 이용한다. VAS에 특별한 기능들의 실행은 접근권한들의 정의에 의해 허가된 당사자들로 제한된다.

일반적으로, 각각의 VAS-응용에 대해, 책임있는 VAS-공급자의 공식적으로 접근할 수 있는 데이터지역들(예. 지갑에 의한 가치들의 읽기의 경우) 및 사적인 데이터지역들은 이용할 수 있고 후자가 제 3자들에 의한 접근에 대항하여 보호한다(예. 내부관리 데이터).

ISO 7816-4에 의하면 카드들이 요소파일들(EF)의 개별적인 레코드들에 대한 구별된 접근보호를 제공하지 않는다는 점을 감안하면, 각 파일이 VAS-응용에 대한 다른 일람(sight)들을 디스플레이하기 위한 레코드를 담고있는, 복수개의 파일들을 사용하는 것이 필요하다.

따라서, 응용클래스들인, 점수저장, 티켓, 식별문서 및 데이터기억의 경우, 구별된 접근보호는 VAS-데이터를 도 6에 도시한 것처럼 네 개의 요소파일들로 세분화함에 의해 일어날 것이다.

네 개의 요소파일들은 다음의 데이터를 담고있거나 또는 다음의 방식으로 보호된다:

[표 3]

요소파일들(EF)의 이 구조는 모든 응용클래스들에 대해 동일한 구별된 접근권한들을 지원한다.

명심할 것은, 응용클래스들이 지금, 응용들에 대한 다른 공간 요구사항들에 기인한 저장용량의 낭비가 최소화될 수 있게, 요소파일들의 갯수 및 크기를 낮추는 단일 구현클래스에 결합된다는 것이다. 응용클래스들인 점수저장기 및 티켓은 동일한 자원들인 EF_KEY, EF_INFO, EF_INTERNAL, EF_VALUE를 요구하고 그러므로 구현클래스인 "DF_PT"에 결합된다. 응용클래스들인 신원확인문서 및 데이터기억의 경우, 요소파일들인 EF_KEY 및 EF_INFO는 충분하고(suffice) 그러므로 구현클래스인 "DF_AD"에 결합된다. 갯수의 관점에서 고려하면, 개별적으로 식별문서 및 데이터저장기가 올려질 수 있는, 응용클래스들인 점수저장 및 티켓의 VAS-응용에서 구현클래스 DF_PT의 p개의 객체들 및 구현클래스 DF_AD의 a개의 객체들이 존재한다.

명백히 이것은 연계 데이터상호교환의 목적을 위해 모든 VAS-참가자(participant)들을 위한 공적인 읽기접근을 제공해야 하는, 응용클래스인 인환권의 경우, 구현클래스인 전송필드가 사용된다. 쓰기접근은 배타적으로 올바른 K_DEC로의 서명을 전제하는 TRANSFER 명령의 응용에 의해 간접적으로 가능하다. 이 구현클래스는 VAS-컨테이너의 전역데이터에 속한 요소파일인 EF_TRANSFER에서의 정확히 하나의 엔트리로 구성된다. 이 클래스의 객체들은 이 파일에서의 레코드들이다. 우리는 이 구현클래스 또한 "EF_TRANSFER"로 다룬다.

도 7에 도시된 구현클래스들은 VAS-컨테이너 내에 존재한다. 이러한 구현클래스들은 VAS-컨테이너의 저장모형(storage model)을 형성한다.

저장모형은 두 개의 방식들로 이용되게 만들어질 수 있다. 그 성질은 카드플랫폼에 의존한다:

- VAS-컨테이너를 위한 저장지역의 고정분할하기(fixed partitioning):

구현클래스들인 DF_PT 및 DF_AD의 경우, 객체들의 최대수 p 또는 a는 그 경우가 가능하다면, 발행인에 의해 고정되고 발행인에 의해 CREATE FILE 명령들을 사용하여 카드에 올려진다. 객체들은 DF_PT 및 DF_AD로 각각 표시된다. VAS-응용들은 자유 객체들, 즉 다른 VAS-응용들에 의해 점유되지 않은 객체들에 나중에 올려질 것이다. VAS-응용들의 올리기 또는 삭제하기의 경우, UPDATE RECORD 명령들만이 필요하다.

따라서, 발행인은 그가 소유한 요구조건에 따라 두 개의 구현클래스들의 가능한 객체들의 갯수를 고정한다. 그러나, 이런 것들은 카드소지자의 실제 VAS-사용자 패턴과는 다를 것이다. 세분화(subdivision)는 카드의 전체 제품수명 하에서 유지될 것이다. VAS-응용은 적절한 구현클래스에 속한 객체에 올려진다. 따라서, 예를 들면, 신원확인문서를 나타내는 VAS-응용은 또한, 구현클래스인 DF-AD의 (더 이상의) 객체들이 이용될 수 없다면, 구현클래스 DF_PT의 객체에 수용될 수 있을 것이다. 객체에 대한 VAS-응용의 배정(assignment)은 트리펠(tripel)(VAS-응용의 PIX, 올려진 객체의 FID, 응용의 소거텍스트명)을 VAS-컨테이너의 광역데이터베이스인 EF_DIR에 넣음에 의해 일어난다. 응용의 이전은 이 트리펠의 EF_DIR로부터의 이전 및 응용들로 올려진 메모리의 파괴적인 읽기(UPDATE RECORD 명령에 의함)에 대응한다.

이 변형은 DF/EF구조들의 동적인 발생하기 또는 삭제하기를 지원하지 않는 카드플랫폼들과 함께 사용된다.

- 구현클래스의 객체들의 동적인 설정:

올려져야 하는 각 VAS-응용의 경우, 파일들은 우선하는(underlying) 구현클래스에 요구된 것처럼 CREATE FILE 명령들에 의해 설정된다. VAS-응용을 삭제하는 경우, 이것에 의해 점유된 DF/EF는 카드로부터 완전히 제거되고 저장공간이 자유롭게된다. 구현클래스들의 객체들의 최소수는 여기서 발행인에 의해 명백히 결정되지 않고 이용할 수 있는 카드의 저장용량에만 의존한다.

이 변형은 카드운영시스템에 의한 동적 데이터베이스관리를 전제한다.

다음의 뒤따르는 작업예에서, 제 2의 것이 이용할 수 있는 카드플랫폼에 높은 요구사항을 만들기 때문에 우리는 제 1변형으로부터 시작할 것이다. 그러나, 동적메모리관리가 이용가능하고 그것이 더 많은 저장용량이 관리비용에 대응하는 것보다 객체들의 동적인 설정에 의해 절약될 수 있다는 것이 보장된다면, 현존하는 개념이 채용되어질 것이고 카드소지자에 대해 보다 더 많은 적응성을 제공한다.

다음으로, 데이터구조들 및 명령들은 VAS-의뢰인카드의 VAS-컨테이너 및 기능성이 다른 시스템구성요소들에 비해 실행되어질 수 있음에 의하여 제시된다. 게다가, VAS-응용들은 VAS-컨테이너 및 단말 사이의 개별적인 상호작용을 기술하는 전형적인 사업상황에 놓여진다.

다음의 필수조건(precondition)들은 구현에 적용된다:

ㆍ각 카드는, 플랫폼에 무관하게, 동일한 데이터 및 명령 인터페이스를 딜러단말에 이용할 수 있게 만든다. 따라서, 요구된 명령들은 그것들의 코드화에서 명료하게 기술된다.

ㆍ서비스단말들은 카드플랫폼을 인식할 수 있다. 기능성은 그러므로 플랫폼의 특별한 명령들에 의해 달성된다. 따라서, 이러한 트랜잭션들은 부분적으로 비공식적으로 쓰여진다. 이 기능이 제공되는 방식은 카드제조자에게 남겨진다.

도 7에서, VAS-컨테이너의 다양한 구현클래스들이 이러한 정황에 있어서 개략적으로 도시된다. 도 8은 VAS-컨테이너의 데이터구조를 개략적으로 보여주며, 도9는 구현클래스 DF_AD의 데이터구조를 보여준다.

VAS-컨테이너의 파일들에 대한 접근은 다음의 접근조건들(AC)에 의해 명백히 제한된다:

[표 4]

이러한 관계에 있어서, AC는 다음의 의미를 갖는다:

ㆍALW(항상) = 데이터베이스에 대한 명령의 접근은 항상 허락된다.

ㆍNEV(전혀) = 데이터베이스에 대한 명령의 접근은 전혀 허락되지 않는다.

ㆍK_SO= 접근 이전에 키(K_SO)를 통한 시스템운영자의 외부 인증이 일어나야 함.

ㆍK_LVASP= 접근 이전에 키(K_LVASP)를 통한 VAS-공급자의 외부 인증이 일어나야 함.

ㆍK_RVASP= 접근 이전에 VAS-공급자에 의해 허가된 단말의 외부 인증이 키(K_RVASP)를 통해 일어나야 함.

ㆍPIN = 접근 이전에 올바른 PIN이 카드소지자에 의해 넣어져야 하고 명령VERIFY에 의해 카드로 분명하게 전송되어야 함.

ㆍPIN 또는 K_RVASP또는 K_SO= 접근 이전에 올바른 PIN이 카드소지자에 의해 넣어지거나 또는 K_RVASP를 사용하는 VAS-공급자에 의해 또는 K_SO를 사용하는 시스템운영자에 의해 외부 인증이 일어나야 함.

이러한 정황에 있어서, 위에서 표시된 것 같은 접근권한들의 오아링킹(Or-linking)이, 카드운영시스템에서, 대체로, 제공되지 않는다. 적용되는 경우에, 이것은 특수한 구현비용을 포함할 것이다(다른 대안: 함축적으로 고정된 보안속성을 지닌 특수한 READ 명령).

요소파일들의 레코드들 내의 데이터필드들은 다음의 포맷들에 따라 구별된다: ASCII, 바이너리(Binary), BCD, 날짜, 포맷스트링(Format string).

유형 "포맷스트링"의 데이터요소(data element)들은 단말에서 카드소지자에 대해 디스플레이될 수 있는 패키지(packaged)프리젠테이션에 VAS-데이터을 담고 있다.

최적의 데이터저장 이용동작을 위해, 명료한 텍스트 및 바이너리 데이터가 혼합되고 포맷팅매크로들을 통해 디스플레이 가능하게 다루어진다.

VAS-컨테이너의 모든 요소파일들(EF)은 ISO 7816-4에 따라 일정한 길이의 레코드들을 지닌 선형포맷된 EF데이터베이스들(선형고정레코드파일들)로서 정의된다.

DF_VAS의 요소파일 EF_DIR은 nr_DIR레코드들로 구성된다. VAS-컨테이너에 올려진 각 VAS-응용의 경우, 그것의 소유권식별자확장(proprietary identifier extension, PIX) 및 그것의 물리적인 저장소(응용이 그 속으로 올려진 DF_X의 FID)는 EF_DIR의 레코드에 고정된다. PIX는, 예를 들면 코드번호로서, 응용이 배정되는 응용 및 서비스공급자를 식별한다.

EF_DIR에서의 엔트리들은 시스템운영자의 서비스단말에서 동적으로 설정된다. 엔트리 없는 레코드들은 공백(empty)TLV객체 '61'로 설정된다.

VAS-응용을 올리는 때에는, 적절한 구현클래스를 위한 자유저장지역이 찾아지고, 일정한 VAS-데이터는 거기에 들어가고 끝으로 새로운 레코드가 EF_DIR에서 발생된다.

응용을 삭제하는 때에는, 공백TLV객체가 그에 따라 EF_DIR에 써넣어져야 한다.

DF_VAS의 요소파일 EF_VERSION은 VAS-컨테이너의 판(version)번호를 담고있는 레코드로 이루어진다.

판번호는 다른 VAS-컨테이너 변형들 및/또는 다른 소프트웨어버전들 사이를 구별하기 위하여 단말에서 사용될 것이다.

DF_VAS의 요소파일 EF_SEQ는 다음 전송필드엔트리의 갯수를 담고있는 레코드로 이루어진다.

순차번호는 보충명령 TRANSFER에 의해 읽어내어진다. 이 명령은 전송필드 EF_TRANSFER에서, 그 중에서도 EF_SEQ로부터의 순차번호가 그 속으로 전송되어지는 레코드를 발생한다. 전송필드로부터의 각 레코드가 오직 한번만 회수되는 것을 보장하고 순차번호를 통한 서명에 의해 이 회수를 기록하는 명령 TAKE와 연대하여, (원래의) 인환권들 또는 영수증들의 오직 한번의 회수가 보장되어지게 한다.

다음으로, 전송저장이 더욱 상세히 다루어진다.

전송저장은 VAS-컨테이너 내에서 설정되고 nr_EF-TRANSFER레코드들을 포함한다. 이러한 파일들의 레코드들에서의 엔트리들은 TRANSFER 명령에 의해 발생된 전송데이터를 담고 있다. 클래스 Voucher의 VAS-데이터의 저장뿐만 아니라 VAS-응용들 사이에서 상호 교환되는 데이터는 전송저장을 통해 실행된다.

전송저장은 제한 없이 읽을 수 있으나, 쓰기접근은 VAS에 특별한 명령인 TRANSFER 및 TAKE를 통해서만 가능하다.

TRANSFER 명령에 의해 데이터필드들을 올리는 것은 카드에서의 '가장 최근에 사용된' 알고리즘에 의해 진행된다. 데이터베이스에서 가장 오래된 레코드는 그 레코드의 처음 2바이트의 최하위 값에 대한 탐색에 의해 결정될 수 있다.

데이터필드들은 전송저장기에서 명령 "TAKE"에 의해 회수 및/또는 제거된 것으로 표시되어진다. 각 경우에, 전송저장기에서의 데이터 삭제하기는 새로운 데이터로 겹쳐쓰기함에 의해 일어난다.

전송저장기에서의 각 레코드는, 예를 들면, 만료날짜, 단말-ID, PIX, 순차번호 및 선택적으로는 추가 데이터를 담는다.

목록들인 DF_X(여기서, X = PT₁, ..., PT_p, AD_1,..., AD_a) 내의 각 요소파일은 VAS-응용의 일반적인 VAS-데이터 뿐만 아니라 만료날짜를 담고있는 레코드를 포함한다. 예를 들면, 티켓의 성질(단일 또는 다중 티켓) 또는 탑승장소(boarding locality)는 여기에 넣어질 것이다. 그러나, EF_INF0는 VAS-응용들보이기(viewing) 동작을 위해 읽혀지는 응용의 적어도 하나의 명료한 텍스트이름을 담아야 한다. 민감한 데이터가 VAS-공급자에 의해 적절한 외부키 알고리즘들에 의해 먼저 보호되어야 한다.

K_SO또는 K_RVASP를 이용한 외부 인증이 일어난다면 또는 카드소지자가 활동적이게 된 PIN-보호의 경우에 올바른 PIN을 넣는 경우, EF는 읽혀질 수 있게 된다.

레코드들 DF_X(여기서, X = PT₁, ..., PT_p, AD_1,..., AD_a) 내의 각 요소파일 EF_INTERNAL은 이것의 올려진 VAS-응용에 관련한 VAS-공급자의 내부 VAS-데이터를 담고 있을 레코드로 이루어진다. 카드소지자와 임의의 다른 VAS-공급자중의 누구도 이러한 내부데이터를 읽을 수 없다.

레코드들 DF_X(여기서, X = PT₁, ..., PT_p, AD_1,..., AD_a) 내의 각 요소파일 EF_VALUE는 VAS-데이터의 정수값필드를 담고 있을 레코드를 포함한다. 이 EF는, 외부 인증이 K_SO또는 K_RVASP로 일어난다면 또는 카드소지자가 활동적이게 된 PIN-보호의 상황에서 올바른 PIN을 넣는 경우, 읽혀질 수 있게 된다.

다음의 키필드들은 VAS-컨테이너에 의해 또는 VAS-응용에 의해 사용된다. 다음으로, 우리는 순수 DES-코드화 즉, VAS-컨테이너의 모든 키들이 DES-키들이고 (패리티비트들을 포함하여) 8바이트로 부호화된 경우로부터 시작할 것이다.

VAS-컨테이너 내에서 및 VAS-응용들 내에서 다음의 키들은 그것들의 KID(키식별자)에 의해, 참조되는 것으로 언급할 것이다:

[표 5]

각 키는 결함동작카운터에 연결된다. 이것은 실패한 인증을 기재하며 이 키로 시도하고, 일단 이 카운트에 들어간 제한에 도달되기만 하면 추가 사용을 봉쇄한다.

VAS-응용 내에서 다음의 키들이 그것들의 KID에 의해 참조되어질 것이다.

[표 6]

각 키는 결함동작카운터에 연결된다. 이것은 실패한 인증을 기록하며 이 키로 시도하고 일단 이 카운터에 들어간 제한에 도달되기만 하면 임의의 추가 사용을 봉쇄한다.

VAS-컨테이너는 개인식별번호 또는 패스워드(PIN)을 담는다. 이것은 VERIFY 명령을 통한 카드소지자의 식별에 사용된다. PIN은 결함동작카운트에 연결되고 이 카운터는 각 결함입력을 기록하고 제한에 도달하자마자 PIN-비교를 봉쇄한다. 이 봉쇄는 적절한 관리 명령들을 사용하는 시스템운영자에 의해 다시 시작하게 되어진다. 결합동작카운터는 일단 올바른 PIN이 넣어지기만 하면 다시 시작된다.

다음의 매개변수들은 VAS-컨테이너를 위해 존재하며, 카드발행자에 의해 카드플랫폼에서 이용할 수 있는 공간 및 그의 개인적인 바램에 따라 선택되어질 것이다:

ㆍ 구현클래스 DF_PT의 객체들의 최대수 p

= VAS-컨테이너에 동시에 올려질 수 있는 응용클래스들인 점수저장기 및 티켓의 VAS-응용들의 최대수;

ㆍ 구현클래스 DF_AD의 객체들의 최대수 a

= VAS-컨테이너에 동시에 올려질 수 있는 응용클래스들인 신원확인문서 및 데이터저장기의 VAS-응용들의 최대수;

ㆍ 객체들의 최대총수 nr_DIR: nr_DIR= p + a

EF_DIR에서 레코드들의 갯수는 nr_DIR;

ㆍ EF_TRANSFER의 레코드들의 갯수 nr_{EF_TRANSFER}

기술된 요소파일들의 데이터에 대한 저장요구사항들은 다음과 같다:

바이트

VAS-컨테이너의 전역데이터 EF_ID 4

EF_DIR 9 * (p+a )

EF_VERSION 1

EF_SEQ 2

전역키들, PIN 64+2

전송필드: EF_TRANSFER 46*nr_{EF_TRANSFER}

VAS-공급자의 소유권데이터 EF_KEY (p+a)*32

EF_INFOR (p+a)*62

EF_INTERNAL p* 10

EF_VALUE p*3

우리가, 예를 들어 매개변수들 p, a, 및 nr_{EF_TRANSFER}에 대해 다음의 값들을 선택한다면, VAS-컨테이너를 위해 다음의 최소저장요구사항들이 (보충 명령들에 대한 저장요구사항들 없이) 발생한다:

매개변수들 저장요구사항들

p = 8, a = 3, nr_{EF_TRANSFER}= 15 2030바이트

P = 10, a = 5, nr_{EF_TRANSFER}= 20 2758바이트

최대저장요구사항은 아마 약 10% 만큼 최소저장요구사항 보다 높을 것이다.

다음으로, 본 발명에 따른 칩카드의 명령들을 보다 상세히 다룰 것이다.

READ RECORD 명령은 선형요소파일들로부터 데이터를 읽어내는데 사용된다. 카드는 이에 답하여 레코드들의 내용들을 공급한다. EF는 짧은파일식별자(SFI)에 의해 참조된다.

상태코드(status code) '9000'은 명령의 성공적인 실행을 신호로 알리나, 임의의 다른 코드는 에러로 간주된다.

UPDATE RECORD 명령은 데이터를 선형EF에 넣기 위하여 사용된다. 명령메시지는 EF, 레코드 및 데이터에 대한 참조를 담는다.

카드의 응답은 상태코드를 담는다. 상태코드 '9000'은 명령의 성공적인 결말을 신호로 알린다. 다른 상태코드들은 에러를 표시한다.

GET CHALLENGE 명령은 카드로부터 난수(random number)를 요구한다. 이 난수는 EXTERNAL AUTHENTICATE에서 동적인 인증에 관련하여 사용된다.

카드의 응답메시지는 8바이트 길이의 난수 및 상태코드를 담는다. 상태코드 '9000'은 명령의 성공적인 실행을 나타낸다. 임의의 다른 상태코드들은 에러를 나타낸다.

명령 EXTERNAL AUTHENTICATE는 카드에 대한 단말의 인증을 허락한다. EXTERNAL AUTHENTICATE는 시스템운영자 및 VAS-공급자의 인증을 위해 VAS-응용들의 정황 내에서 사용된다. EXTERNAL AUTHENTICATE는 전송에 앞서 단말에 의한 난수의 암호화에 의해 발생되어야 하는 암호를 카드 속으로 전송한다. 카드는 동일한 절차를 이용하여 계산된 바로 그것을 갖는 난수의 기준값과 암호를 비교한다. 양쪽 값들이 동일하다면, 카드는 이 키에 대한 접근조건인증이 발생하였음을 내부적으로 알아차린다. 비교가 부정적으로 간주된다면, 카드는 상태를 "비허가 된" 것으로 발행하고 내부의 결함동작카운터를 감소시킨다. 일단 이 카운터가 값 '0'에 도달하기만 하면, 임의의 추가적인 EXTERNAL, AUTHENTICATE의 실행이 "인증 봉쇄된" 상태로 봉쇄된다.

카드의 응답메시지는 상태코드를 담는다. 카드에 관련하여 단말의 명령 및 인증의 성공적인 실행은 상태코드 '9000'에 의해 표시된다. 임의의 다른 상태코드들은 에러를 나타낸다.

명령 INTERNAL AUTHENTICATE는 단말에 의한 VAS-컨테이너의 확실성을 점검하기 위하여 사용된다. 카드는 이 목적을 위해 단말로부터 유도된 기준데이터를 통하여 암호를 계산한다. 단말은 차례가 되어 암호를 형성하고 이것을 카드의 값과 비교한다. 동일하다는 상황에서는, 단말은 VAS-컨테이너의 확실성을 당연한 것으로 여길(assume) 수 있다.

카드의 응답은 명령의 실행을 위한 상태코드 및 암호를 담는다. 명령의 성공적인 실행은 상태코드 '9000'에 의해 표시된다. 임의의 다른 상태코드들은 에러를 나타낸다.

VERIFY 명령은 카드소지자의 PIN를 검증하기 위해 사용된다. 이 명령은 암호화되지 않은 PIN데이터를 카드에 전송하고, 카드에서는 저장된 기준값과의 비교가 실행된다. 넣어지고 저장된 값이 동일하다면, 접근조건들인 "PIN"은 요구에 따른다고 간주된다.

카드의 응답메시지는 상태코드를 담는다. 상태코드 '9000'은 성공적인 명령의 실행을 나타낸다. 다른 상태코드들은 에러를 나타낸다.

TRANSFER 명령은 전송저장기에 엔트리를 발생한다. 세 개의 운영모드(operating mode)들이 이 명령을 위해 정의된다:

1. 클래스인 티켓 또는 점수저장기의 응용의 EF-VALUE 필드에서의 값들의 감소에 의한 전송필드에서의 엔트리의 발생.

2. 클래스인 신원확인문서의 응용에서의 영수증 만듦에 의한 전송필드에서의 엔트리의 발생.

3. 클래스인 인환권의 응용에서 인환권을 발생함에 의한 전송필드에서의 엔트리의 발생.

운영모드는 카드에 의해 자동으로 선택된다. 명령이 선택된 응용-DF 내에서 실행된다면, EF_VALUE의 존재가 우선 점검된다. EF_VALUE가 존재한다면, 카드는 이명령을 모드 1에서, 다르게는 모드 2에서 실행한다. VAS-컨테이너 내에서 응용-DF가 선택되지 않았다면, 모드 3이 사용된다.

단말은, TRANSFER 명령을 위해 호출되는 때, 카드에 다음의 데이터를 공급하다:

ㆍ 현재날짜

ㆍ 전송필드에서의 엔트리에 대한 만료날짜

ㆍ 이 엔트리를 발생하는 단말에 대한 식별

ㆍ 전송필드를 위한 사용자데이터

ㆍ VAS-응용의 PIX(모드 3 만)

ㆍ 공제되어야 하는 단위들의 갯수(모드 1 만)

ㆍ 전술한 데이터, 순차번호 및 VAS-컨테이너번호에 관련한 MAC

카드는, 일단 TRANSFER 명령이 호출되어진다면, 다음의 순차(sequence)를 실행한다:

1. 전송저장기에서 자유엔트리에 대한 탐색. (다음의 목록은 역순으로 우선권을 제공하고 그 우선권으로 현존하는 엔트리들이 다음에는 겹쳐 쓰여진다: "제거된 것으로 표시된 엔트리", "회수된 것으로 표시된 엔트리" 및 "도달된 만료날짜").

2. PIX를 모드 1 및 2에서 단말의 데이터에 부착.

3. 순차번호를 단계 2로부터의 데이터에 부착.

4. VAS-컨테이너ID를 단계 3으로부터의 데이터에 부착.

5. PIX를 KGK_DEC하에서 부호화하여 KGK_DEC,PIX를 유도.

6. 단말ID를 KGK_DEC,PIX하에서 부호화하여 K_DEC를 유도.

7. 단계 4의 데이터를 통해 MAC을 발생.

8. 단말의 MAC와의 단계 7로부터의 MAC의 비교. 값들이 다르다면, 카드는 그기능을 인트럽트하고 결함동작카운터를 KGK_DEC만큼 줄임.

9. 모드 1의 경우: 응용이 그 속으로 올려진 레지스터의 값필드 EF_VALUE를 테스트. 불충분한 단위들이 이 필드에 나타난다면, 카드는 이 시점에 기능을 인트럽트. 그렇지 않으면 응용의 값필드는 이 양만큼 감소됨.

10. 명령메시지의 어셈블리(assembly).

11. EF_SEQ의 내용을 1만큼 증가.

명령메시지는, 예를 들면 만료날짜, 단말ID, 트랜잭션데이터, 운영모드를 위한 필드(예, 모드 3에서 PIX 담음), 뿐만 아니라 암호를 담고있는 필드들을 담는다.

암호는 예를 들면, 트랜잭션데이터 및 단말-ID를 포용하는 MAC에 의해 형성된 데이터인 키 K_DEC를 사용하여 계산된다:

TRANSFER의 응답메시지는, 성공적인 때에, 8바이트 길이의 데이터필드 및 2바이트 길이의 상태코드 '9000'을 구비한다. '9000'과는 다른 상태코드를 지닌 회답(reply)메시지들은 에러코드들로 해석된다. 회답메시지의 데이터필드는 에러로부터 자유로운 상황에서, (즉, 특히 명령메시지의 암호가 정정되었던) 명령메시지의 K_DEC로 부호화된 암호를 담는다.(K_AUT를 이용한 내부 인증 대신에) 이런 방식으로 인증은 VAS-컨테이너에 의해 내부적으로 실행된다.

명령 TAKE는 구현클래스 EF_TRANSFER로부터 객체들을 회수하는데 소용된다. 전문적으로는, 명령 TAKE 실행은 저장기 EF_TRANSFER로부터 표시되어야 하는 레코드의 읽어내기를 의미하고, 이 레코드는 저장공간이 새로운 엔트리를 위해 요구되기까지 저장기에 계속 유지되는 것이고, 이 세트의 데이터는 회수(withdrawn)된 것으로 표시된다. 기술적으로 고려하면, 누구가 한 세트의 데이터를 회수하기 위하여 명령 TAKE를 사용할 수 있으나, R&R(규약)에 따르면 이 세트의 데이터가 의도되어진 VAS-공급자만이 이것을 할 수 있다.

제거절차를 위해 다음이 당연한 것으로 여겨질 것이다. VAS-공급자는 인환권 또는 영수증을 제거하기를 바라는 사람으로, 전송저장기에서 적절한 세트의 데이터를 (예. 명령 SEEK에 의해 또는 각 레코드의 명백한 읽기에 의해) 탐색한다. 이 세트의 데이터는 여하튼 간에 읽혀지고 그것의 내용은 점검될 것이다.

이에 응답하는 데이터 세트의 디스플레이는 그러므로 필요하지 않다. 게다가 레코드 수는 알려진 것으로 가정될 수 있다.

명령 TAKE는 다음의 모드들을 제공한다:

　ㆍ 데이터가 실효되었다는 동시 주해(annotation)와 함께 제거

　ㆍ 전술한 주해 없이 제거. 이 데이터는 유효한 것으로 남는다.

명령메시지는 단말-ID, 응용의 PIX 및 단말에 의해 발생된 난수를 담는다.

명령에서의 PIX는 데이터를 제거하는 응용을 표시한다. 이것은 제거되어진 데이터 세트의 PIX와는 다르고, 배타적으로는 제거를 초래하는 딜러단말의 K_DEC의 유도를 위해 소용된다.

카드의 응답메시지는 VAS-컨테이너ID 및 명령메시지에서 보고된 전송필드의 레코드들의 데이터에 관련한 K_{SIG_VASC}를 지닌 암호 C₁, C₁을 통한 제거를 초래하는 단말의 K_EDC를 지닌 암호 C₂및 명령메시지로부터 취해진 난수를 담는다. 응답메시지는, 이에더하여, 상태코드를 담는다. 키 K_DEC는 위에서 더 기술된 것처럼 유도된다. 확실성은 함축적으로는 K_DEC를 통한 암호의 관점에서 VAS-컨테이너에 의해 증명된다. 확실성 및 유일성의 증거는 (C가 순차번호, 전송필드레코드의 제거비트 및 VAS-컨테이ID에 의해 형성되므로) 시스템운영자에 의해 검증될 수 있는 암호 C에 의하여 계산된다.

상태코드 '9000'은 명령의 성공적인 실행을 나타낸다. 다른 상태코드들은 에러들인 것으로 해석된다.

SO(시스템운영자)가 IDO/IEC 7816-5에 따른 하나의 AID_VAS를 요구하는 것으로 가정되어진다. 보다 상세하게는, 그는 VAS-시스템에 대해 5바이트 길이의 RID_VAS를 요구한다.

목록 DF_VAS의 AID_VAS는 다음과 같이 이해된다: RID_VASㆍ= AID_VAS.PIX_{DF_VASㆍ}

각 VAS-응용 A에 대해, 3바이트 길이의 PIX_A가 전자를 AID_A= AID_VAS.PIX_A를 통해 VAS-컨테이너 내에서 모호하지 않게 식별하도록 하기 위하여 R&R에 따라서 발행된다. DF_VAS의 선택 이후에, VAS-응용 A가 담겨있는 목록은 SELECT FILE <PIX_A>을 이용하여 선택되어질 것이다.

UPDATE KEY (KID, K)는, 키가 키식별자ID를 사용하여 새로운 값 K에 의해 대체되는 카드플랫폼에 의존하는 명령을 나타낸다. 구현클래스들인 DF_PT 또는 DF_AD(응용클래스들인 점수저장기, 티켓, 식별문서 또는 데이터베이스에 대응)중의 하나로부터 VAS-응용은 딜러단말에서 카드소지자에 의해 이용되어지기 이전에, 이것이 적절한 VAS-공급자의 서비스단말에서 VAS-컨테이너 속으로 올려져야 한다. 원칙적으로는, 카드발행자가 VAS-공급자에 의해 지시되고 시스템운영자(SO)는 이미 VAS-컨테이너가 탑재된 경우 VAS-컨테이너 속으로 하나 이상의 VAS-응용들을 올리는 것 또한 가능하다. 이러한 올리기처리는 여기서 기술된 특수한 경우를 구성한다.

VAS-응용의 올리기 절차는:

1. 카드소지자가 VAS-카드를 서비스단말 속으로 삽입한다.

2. 서비스단말이 VAS-컨테이너가 존재하는 지를 점검한다:

ㆍ SELECT FILE < AID_VAS> (VAS-컨테이너가 선택불가능하다면 에러보고)

ㆍ READ RECORD < EF_ID의 SFI, O > (VAS-컨테이너번호의 디스플레이)선택적으로는, VAS-컨테이너의 타당성(validity)이 점검된다. 이를 위해, 서비스단말은 VAS-컨테이너의 내부 인증을 요구한다:

ㆍ INTERNAL AUTHENTICATE < 난수, K_AUT의 KID >

서비스단말은 응답을 점검하고 (에러 디스플레이로) 에러가 있는 상황에서는 그 절차를 종료한다.

3. 서비스단말은 카드소지자에게 여러 옵션들의 선택들 제공한다. 이것들 중의 하나는 VAS-응용의 올리기를 나타낸다. 이것은 카드소지자에 의해 선택된다. 서비스단말에 올려질 수 있는 모든 VAS-응용들은 지금 카드소지자에 디스플레이되고 선택이 기다려진다. 이 목적을 위해, VAS-응용들의 보이기 동작이 활동적이게 된다. 카드소지자는 구현클래스들 DF_PT 또는 DF_AD의 VAS-응용 A를 선택한다.

4. 서비스단말은 PIX_A를 갖는 선택된 VAS-응용이 카드에 이미 올려졌는 지에 대하여 VAS-응용의 동작선택을 통해 VAS-컨테이너를 검사한다. 긍정적이라면, 에러신호가 디스플레이된다. 아니라면, 점검이 A에 적합한 구현클래스의 객체가 여전히 VAS-컨테이너에서 이용할 수 있는 지에 대하여 행해진다. 이것은 (예. 명령 SEEK를 이용하여) VAS-컨테이너에서 자유 레코드의 탐색에 의해 진행한다. 이용할 수 있는 것이 없다면, 에러신호가 디스플레이된다. 레코드가 비어있다면, 이것은 그 속으로 올려진 VAS-응용이 없는 DF_X의 FID_{DF_X}를 담는다.

5. 이 다음에 뒤따르는 A에 적절한 구현클래스의 자유로운 객체에는 VAS-응용이 올려진다. 이 목적을 위해, 서비스단말은 우선 (예. VAS-공급자 SAM을 통하여) VAS-공급자의 두 개의 키들 K_LVASP및 K_RVASP에 오프라인을 요구하고 이것들을 새로운 응용에 할당한다:

ㆍ SELECT FILE <FID_{DF_X}>

ㆍ GET CHALLENGE

ㆍ EXTERNAL, AUTHENTICATE < K_SO(난수), K_SO의 KID>

ㆍ UPDATE KEY < K_LVASP의 KID, K_LVASP>

ㆍ UPDATE KEY <K_RVASP의 KID, K_RVASP>

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE < K_LVASP의(난수), K_LVASP의 KID >

ㆍ UPDATE RECORD < DF_X의 EF_INFO의 SFI, 데이터 >

ㆍ UPDATE RECORD < DF_X의 EF_INTERNAL의 SFI, 데이터 >

ㆍ 옵션 (초기화(initialling)): UPDATE RECORD < DF_X의 EF_INFO의 SFI, 데이터 >

6. EF들에서의 성공적인 엔트리 이후에 서비스단말은 VAS-응용 넣기 <PIX_A, FID_{DF_X}> 동작을 실행하고, 이것은 DF_X를 PIX_A에 연결시켜 (SELEC FILE AID_VAS를 통한 우선 선택 이후에) PIX_A에 의하여 SELECT FILE를 허락한다.

전송저장기에 의해 이용할 수 있게 만들어진 메커니즘은, 예를 들면, 독점한 DF-구조들 없이 인트라서비스 또는 인터서비스를 실행하기 바라는 VAS-공급자들에 의해 이용되어질 것이다. 카드소지자는 특히 이러한 VAS-응용을 이용하기 이전에, 우선 이것을 서비스단말에 올리는 것을 필요로 한다. 반면에, 그는 딜러단말에서 스스로에게 직접 인환권 또는 영수증을 발행할 것이고 (제거하기 동작에 의해) 다른 단말에서 다시 되산 것을 가지거나 또는 (읽기에 의해) 인환권 또는 영수증을 단순히 제시한다. 구현클래스 EF_TRANSFER의 VAS-응용의 올리기는 그러므로 함축적으로 VAS-데이터의 넣기에 의해 실현되거나 또는 이러한 동작에 의해 일어난다. 이러한 정황에서, 기준은 구현클래스 EF_TRANSFER의 넣기에 의해 실현되거나 또는 그러한 동작에 의해 야기된다. 이런 관계에 있어서, 기준은 아래의 구현클래스 EF_TRANSFER의 구매의 기술(description)에 대해 만들어진다.

다음으로 VAS-응용의 넣기 동작의 진행을 설명한다.

VAS-응용이 VAS-컨테이너 속으로 올려진다면, 단말은 X = PT₁, ..., PT_p, AD₁, ..., AD_a인 DF_X에서의 물리적인 장소, VAS-응용이 올려졌음을 또는 이것이 어떤 식으로 올려졌는 지를 알지 못한다. 카드제조자의 관점에서, 두 개의 가능한 구현모드들이 가능하고 이 모드들은 별도로 점검되어지고, 이런 상황에 있어서, ZKA-표준과의 일관성이 특히 준수되어야 한다.

처음 상황: EF_DIR에 대한 접근이 가능하다.

다음의 필수조건들은 부합되어야 한다:

ㆍ VAS-응용들이 현재 존재하는 DF_X의 FID들과 AID들이 연관되는 (예. DF-VAS 하의) EF_DIR이 카드플랫폼에서 표준방식으로 존재한다.

ㆍ 이 EF-DIR은 누구든지 읽을 수 있다(READ RECORD의 AC: ALW).

ㆍ PIX_A을 지닌 VAS-응용 A가 시스템운영자에 의해 자유 DF_X로 올려진다면, 즉 엔트리가 현존하는 요소파일들 DF_X((CREATE FILE 없음!)로 만들어진다면, 데이터베이스 EF_DIR을 엔트리 PIX_A에 의해, FIX_A를 통해 이 DF_X를 참조하는 UPDATE RECORD를 통하여 확장되는 것이 가능해진다. UPDATE RECORD의 AC는 그러므로 키 K_SO에 의하여 외부 인증을 강화해야 한다.

ㆍ DF_VAS의 우선 선택 이후의 명령 SELECT FILE < PIX_A>가 카드로 전송된다면, VAS-응용 A가 그 속에 올려진 DF_X는 직접 선택할 수 있어야 한다.

ㆍ DF_X 및 이것의 보조 요소파일들에 올려진 VAS-응용이 서비스단말에서 카드소지자의 요구로 삭제되어진다면, 대응하는 데이터베이스들은 DELETE FILE에 의해 삭제되진 않으나, 넣어진 데이터는 단순히 더미(dummy)값들로 포개어 쓰여진다. 그에 따라 EF_DIF로부터 엔트리 PIX_A(보다 상세하게는 한 벌의 PIX_A및 DF_X에 대한 참조)를 삭제하는 것이 가능해질 것이다(예. 키 K_SO를 통한 이전의 외부 인증과 UPDATE RECORD에 의해).

ㆍ DF_X이 갯수는 고정되므로, EF_DIR의 레코드들의 갯수는 알려진다.

이 접근법이 실현가능하다면, 다음의 결과들이 있게 된다:

ㆍ SELECT FILE PIX_A를 이용한 VAS-응용의 직접 선택은 DF_VAS의 선택을 뒤따라 가능하다.

두 번째 상황: EF_DIR에 대한 접근이 불가능하다.

특정한 카드플랫폼으로 EF_DIR은 이용할 수 없거나 또는 이전 단락에서 전술한 것처럼 이 EF_DIR에 접근하는 읽기 또는 쓰기가 불가능한 경우에는, 준비(provision)가, 시스템운영자에 의해 (K_SO를 통한 앞서의 외부 인증 이후) 명백한 UPDATE RECORD 명령들에 의해 생겨난, DF_X의 물리적인 저장장소에 PIX_A로 올려진 VAS-응용으로 만들어지는 연결을 위해 데이터베이스 EF_VASDIR을 위한 EF_VAS하에서 만들어진다. EF_VASDIR로부터 레코드들의 읽기 및 삭제하기는 이전에 기술된 것처럼 가능해질 것이다.

동작 엔트리인 VAS-응용의 실행은 다음과 같이 진행한다:

PIX_A를 구비한 VAS-응용 A는 미리 자유 DF_X 속으로 FID_{DF_X}로 올려졌다. FID_{DF_X}를 구비한 레코드 수는 서비스단말에 의해 알게되어졌다.

1. SELECT FILE < AID_VAS> (VAS-컨테이너가 선택할 수 없다면 에러 디스플레이)

2. GET CHALLENGE

3. EXTERNAL AUTHENTICATE < K_SO(난수), K_SO의 KID >

4. UPDATE RECORD < DF_VAS의 EF_DIR의 SFI, FID_{DF_X}, PIX_A, FID_{DF_X}로 번호 기록 >

구현클래스 DF_PT 또는 DF_AD의 VAS-응용들은 (시스템운영자의 제어 하에 있게 된) 서비스단말에서 카드소지자의 요구로 삭제되어질 수만 있고, 구현클래스EF_TRANSFER의 VAS-응용들은 누구라도 어디서든지 삭제할 수 있다. 삭제할 때, 구현클래스들인 DF_PT 및 DF-AD 각각의 VAS-응용들 사이에서 구현클래스 EF_TRANSFER를 구별하는 것이 필요하다.

구현클래스 DF_PT 또는 DF_AD를 위한 이러한 VAS-응용의 삭제하기는 다음과 같이 진행한다:

1. 카드소지자가 VAS-카드를 서비스단말에 삽입한다.

2. 서비스단말은 VAS-컨테이너가 존재하는 지를 점검한다:

ㆍ SELECT FILE < AID_VAS> (VAS-컨테이너가 선택불가능하다면 에러 디스플레이)

ㆍ READ RECORD < EF_ID > (VAS-컨테이너ID의 디스플레이)

3. 서비스단말은 카드소지자에게 여러 옵션들의 선택을 제공한다. 그 중의 하나는 VAS-응용 삭제이다. 이것은 카드소지자에 의해 선택된다. VAS-컨테이너에 올려진 모든 구현클래스들의 모든 VAS-응용들은 지금 카드소지자에게 디스플레이되고 그의 선택이 기다려진다. 이 목적을 위해, VAS-응용들 보이기 동작이 활동적이게 된다. 카드소지자는 구현클래스 DF_PT 또는 DF_AD의 VAS-응용 A를 AID_A로 선택한다. VAS-응용이 올려진 객체는 표시된 DF_A가 되는 것으로 가정된다.

4. DF_A의 선택 이후에, 서비스단말은 스스로를 인증한다:

ㆍ SELECT FILE < PIX_A>

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE < K_SO(난수), K_SO의 KID >

5. DF_A의 파일들의 내용은 지금 삭제된다(K_LVASP는 EF_KEY, EF_INTERNAL 및 EF_VALUE에 요구되고, 이런 이유로 전자는 시스템운영자에 의해 먼저 삭제된다):

ㆍ UPDATE KEY < K_LVASP의 KID, "00...00" >

ㆍ UPDATE KEY < K_RVASP의 KID, "00...00" >

ㆍ GET CHALLENGE

ㆍ EXTERANL AUTHENTICATE < K_LVASP(난수), K_LVASP의 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" >

6. EF들로의 성공적인 엔트리들 이후에, 서비스단말은 이어서 VAS-응용의 엔트리가 EF_DIR로부터 삭제되어지게 한다.

ㆍ UPDATE RECORD < DF_VAS의 EF_DIR의 SFI, FID_{DF_A}로 번호 기록, "00...00", FID_{DF_A}>

DF_A에 대한 PIX_A의 상호연계(interlinkage)는 PIX_A를 지닌 SELECT FILE가 더 이상 가능하지 않게 취소(undo)된다.

다음으로 뒤따른 것은 구현클래스 EF_TRANSFER이다:

구현클래스 EF_TRANSFER의 VAS-응용은, R&R에 따라서, (이것이 기술적으로는 둘 중의 누구에 의해서도 실행될 수 있음에도 불구하고) 카드소지자의 명백한 요구로 딜러단말 또는 서비스단말에서 삭제되기만 할 수 있다. EF_TRANSFER로부터 객체 삭제하기는 특히 전송저장기가 새로운 객체(예. 인환권 또는 영수증)를 저장하기 위한 더 이상의 공간이 없다면 필요하게 될 것이다. 삭제하기는 보충 명령 TAKE를 통해 항상 간접적으로 진행한다. 이 명령은 객체를 제거완료된 것으로 단순 표시한다. 그 이후에 후속하는 보충 명령 TRANSFER에 의해 무시(override)되어지는 것은 자유이다.

이 VAS-응용의 삭제는 다음과 같이 진행한다:

1. 카드소지자는 VAS-카드를 EF_TRANSFERF의 내용을 디스플레이할 능력이 있는 단말에 삽입한다(VAS-응용들의 보이기 동작의 특수한 경우)

2. 단말은 VAS-컨테이너가 존재하는 지를 점검한다:

ㆍ SELECT FILE < AID_VAS> (VAS-컨테이너가 선택 불가능하다면 에러 디스플레이).

ㆍ READ RECORD < EF_ID의 SFI, 0 >(VAS-컨테이너ID의 디스플레이)

3. 단말은 카드소지자에게 여러 옵션들의 선택을 이용할 수 있게 만든다. 그중의 하나는 VAS-응용 삭제이다. 이것은 카드소지자에 의해 선택된다. 적어도 구현클래스 EF_TRANSFER의 VAS-응용들은 지금 카드소지자에게 디스플레이되고 선택이 기다려진다. 이것은 특수한 경우의 동작인 VAS-응응들 보이기에 의해 일어난다. 카드소지자는 객체를 인환권 또는 영수증을 포함하는 구현클래스로부터 선택한다. 이 객체는 레코드번호 A를 갖는다. 카드소지자는 선택을 활성화시킨다.

4. 단말은 레코드번호 A를 지닌 레코드를 제거된 것으로 표시하고, A, 그것에 의해 계산된 난수, 그것의 PIX 및 단말ID를 명령 TAKE를 사용하여 전송한다:

ㆍ TAKE < A, 난수, PIX, 단말ID >

제거완료된 것으로 표시된 레코드는 새로운 인환권 또는 영수증을 받기 위해 지금 다시 이용할 수 있다.

VAS-응용의 선택은 다음과 같이 진행한다:

구현클래스인 DF_PT 또는 DF_AD의 VAS-응용 A가 VAS-응용 올리기 동작에 의해 VAS-컨테이너에 올려진 경우에, 이는 두 단계로 단말에 의해 선택될 수 있다. 우선, VAS-컨테이너가 선택되고, 그런 다음에 그것의 PIX₄를 포함하는 VAS-응용이 선택된다:

1. SELECT FILE < AID_VAS> (VAS-컨테이너가 선택가능하지 않다면 오류표시)

서비스단말은 VAS-컨테이너의 확실성을 점검할 수 있다. 그 목적 때문에 서비스단말은 VAS-컨테이너의 내부인증(internal authentication)을 요구한다:

ㆍ READ RECORD < EF_ID의 SFI, 0 > (VAS-컨테이너 ID의 표시)

ㆍ INTERNAL AUTHENTICATE < 난수, K_AUT의 KID >

서비스단말은 응답을 점검하고 오류가 있는 경우에는 (오류표시와 함께) 동작을 중단한다.

2. SELECT FILE < PIX_A> (VAS-응용 A가 VAS-컨테이너에 올려지지 않았다면 오류표시)

(이용할 수 있는 KGK_AUT를 갖지 않는) 딜러단말은 VAS-응용 A의 확실성 점검에 의해 VAS-컨테이너의 확실성을 간접적으로 결정할 것이다. 이것은, VAS-응용이 올리기 절차 동안 VAS-컨테이너의 확실성을 점검하였던 서비스단말에 단지 올려질 수 있었기 때문이다. VAS-응용 A의 확실성점검은 VAS-컨테이너가 VAS-응용 A에 대한 키 K_LVASP또는 K_RVASP를 담는 지 여부를 딜러단말에서 시험하게 되돌아갈 수 있다. 이는 딜러단말에 의해 예를 들면 다음과 같이 점검될 수 있다:

ㆍ INTERNAL AUTHENTICATE < 난수, K_RVASP또는 K_LVASP의 KID >

VAS-응용 A는 VAS-컨테이너로 올려지는지 여부를 시험하기 위하여, 임의로 선택될 수 있다. SELECT FILE의 응답메세지의 오류표시에 근거하여, VAS-응용 A가 존재하지 않는다고 결정될 수 있다.

구현클래스 EF_TRANSFER의 VAS-응용의 선택은 함축적으로 단말에서 데이터의 저장 및 VAS-응용들 보이기 동작에 의해 일어난다. 그 단말은 EF_TRANSFER로부터 각각의 표시된 객체의 레코드번호를 알게 되므로, 그 레코드번호와 관련하여 더 처리하기 위해 어떠한 원하는 객체를 선택하는 것이 가능하다.

VAS-응용 보이기의 실행은 다음과 같이 진행한다:

VAS-응용들 보이기의 동작은 구현클래스들 DF_PT, DF_AD 및 EF_TRANSFER의 모든 VAS-응용들을 서비스단말에 목록기재한다. 구현클래스 EF_TRANSFER의 VAS-응용들만이 그에 대한 접근보호의 부재 때문에 딜러단말에 표시될 수 있으며, 또한 선택적으로는 딜러단말이 해독자 권리들(reader rights; K_RVASP의 소유)을 갖는 구현클래스 DF_PT 또는 DF_AD의 응용들이 표시될 수 있다.

그러한 VAS-응용은 다음과 같이 진행한다:

1. 카드소지자는 VAS-카드(유효한 VAS-컨테이너가 있는 칩카드)를 단말에 삽입한다.

2. 서비스단말은 VAS-컨테이너가 존재하는지 여부를 시험한다:

ㆍ SELECT FILE < AID_VAS> (VAS-컨테이너가 선택가능하지 않다는 오류표시)

ㆍ READ RECORD < EF_ID의 SFI, 0 > (VAS-컨테이너 ID의 표시)

선택적으로 VAS-컨테이너의 유효성이 점검된다. 이 목적 때문에 서비스단말은 VAS-컨테이너의 내부인증을 요구한다:

ㆍ INTERNAL AUTHENTICATE < 난수, K_AUT의 KID >

서비스단말은 응답을 점검하고 오류의 경우에는 (오류표시와 함께) 절차를 중단한다.

3. 서비스단말은 카드소지자에게 여러 옵션들의 선택을 제공한다. 이들 옵션들중의 하나는 VAS-응용들 보이기이다. 이는 카드소지자에 의해 선택된다.

4. 서비스단말은 스스로를 인증한다:

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE < K_SO(난수), K_SO의 KID >

5. 구현클래스들 DF_PT 및 DF_AD의 VAS-응용들의 경우, 개개의 VAS-응용들은 EF_DIR의 내용에 의해 연속적으로 선택, 제어되며, 키 K_SO로 외부인증한 이후에 EF_VALUE 뿐만 아니라 개개의 EF_INFO (또는 R&R에 따라 그의 일부)의 내용이 표시된다:

ㆍ i=0, ..., nr_DIR- 1에 대해

ㆍ READ RECORD < EF_DIR의 SFI, i>

응답메세지에서 대응하는 DF에 VAS-응용이 올려지지 않는다면 "00..00"인 PIX_A가 표시된다. EF_DIR으로부터 READ RECORD로의 대안으로서 또한 SEEK 명령을 사용하는 것이 가능할 것이다.

ㆍ PIX_A가 "00..00"와 동일하지 않다면

ㆍ SELECT FILE < PIX_A>

ㆍ READ RECORD < EF_INFO의 SFI, 0 >

ㆍ 응답메세지(선택적으로 일부분만)의 표시

ㆍ READ RECORD < EF_VALUE의 SFI, 0 >

ㆍ SELECT FILE < AID_VAS>

6. 구현클래스 EF_TRANSFER의 VAS-응용들에 대해 각 기록의 EF_TRANSFER의 내용들(또는 R&R에 따른 그 일부)이 표시된다:

ㆍ SELECT FILE < AID_VAS>

ㆍi=0, ..., nr_{EF_TRANSFER}- 1인 경우에

ㆍ READ RECORD < EF_TRANSFER의 SFI , i >

(응답메세지는 EF_TRANSFER의 i-번째 기록들의 내용들을 표시한다.)

ㆍ 내용이 비어있지 않다면, 내용은 해석된 형태로 표시된다(이를테면 취득된/만료된 )

딜러단말이 보기 권리들(viewing rights ;K_RVASP의 소유)을 갖기 위한 구현클래스 DF_PT 또는 DF_AD의 응용들의 보이기(viewing)가, 두 변화를 조건으로 하여 설명된 바와 같이 진행한다: 외부인증을 위해 키 K_RVASP가 시스템운영자에게만 이용가능한 K_SO대신에 사용된다. 딜러단말이 이용가능한 KGK_AUT를 갖지 않으며 VAS-응용들의 확실성을 점검하기를 결코 원하지 않는다면, 내부인증 대신에 딜러단말이 (적어도 하나의) VAS-응용의 인증을 요구할 수 있다. 이는 대응하는 K_RVASP또는 K_LVASP키의 카드의 인식에 의해 설명된 바와 같이 진행한다.

구현클래스 EF_TRANSFER의 VAS-응용들을 위해 각 기록의 EF_TRANSFER의 내용들(또는 R&R에 따른 그의 일부분)이 이전에 기재한 바와 같이 연속적으로 목록기재된다.

VAS-응용들의 해석 동작이 그에 유사하게 진행한다. 이 목적 때문에, 단말은 카드소지자에게 선택하기 위한 VAS-응용들의 해석 옵션을 제공한다. 보이기 동작으로 인해 표시되는 데이터에 부가하여, VAS-공급자에 의한 해석을 필요로 하는 EF_INFO 및 EF_VALUE로부터 데이터(이를테면 외부에서 부호화된 데이터) 및 EF_INTERNAL로부터의 데이타(이를테면 마일 및 등등(Miles & More)과 함께 이전 연도들로부터의 마일들)를 또한 표시하는 것이 가능하다. 그러나, 이는 VAS-공급자(그 자신의 선택으로)가 단말에서 적절한 키들을 이용가능하게 하기 위한 VAS-응용들에 대해서만 가능하다. 키 K_LVASP(외부인증)가 VAS-응용의 EF_INTERANL을 읽기 위해 요구된다. 전송저장 EF_TRANSFER 뿐만 아니라 EF_INFO, EF_INTERN 및 EF_VALUE인 요소화일들내에서 외부에서 부호화된 데이터를 위해, VAS-공급자의 적절한 키들이 요구된다. 단말프로그램은 선택된 VAS-응용의 PIX의 도움으로 쉽게 식별할 수 있으며, 이를 위해 응용키들은 데이터를 해석하는데 이용할 수 있다.

VAS-응용들의 전송 동작은 소스카드의 모든 또는 선택된 VAS-동작들의 전송을 서비스단말에서의 목표카드(target card)상에 표시한다. 이는, 목표카드의 VAS-컨테이너에서 VAS-응용들이 올려지지 않고, 전송 이후에 모든 VAS-응용들이 소스카드로부터 삭제되는 전제조건으로 한다. 이 둘 다는 VAS-응용을 삭제하는 동작의 연속적인 응용들에 의해 달성될 수 있다. 게다가, VAS-카드의 확실성은 점검되어야 하며, 목표카드는 적당한 저장용량을 제공해야 한다. 전송자체 동작은, 부가적으로 EP_INTERNAL로부터의 데이터 및 키들 K_LVASP및 K_RVASP가 읽혀지기 위한 VAS-응용들의 보이기 동작의 확장, 및 VAS-응용의 올리기 동작의 반복된 응용에 본질적으로 근거한다. VAS-데이타와 연대하여 VAS-컨테이너 ID도 그들이 소스카드상에 행했던 것과 마찬가지로 목표카드의 VAS-응용들이 정확하게 실행되도록 순서대로 목표카드로 전송된다. 이에 대한 이유는 VAS-공급자로부터 유도된 키들이 VAS-컨테이너 ID, 그 키들에 의해 지원되나, 변경없이 복제되기 때문이다. 더욱이, VAS-공급자는 보통VAS-컨테이너 ID에 의해 VAS-카드들을 식별하기 때문에 기본시스템에서 자신의 계정(accounting)을 바꾸기를 원하지 않는다. VAS-컨테이너 ID의 전송중에 그 시스템에 유일한 이 번호가 소스카드로부터 삭제되는 것을 확실하게 하는 것이 필수적이다.

요소화일 EF_INTERANL 및 키들 K_LVASP및 K_RVASP를 특별하게 읽을 수 있도록 하기 위해, 서비스단말은, 키 K_SO(VAS-응용을 삭제하기 동작에서 처럼)에 의한 외부 인증 이후에, 먼저 키 K_LVASP를 겹쳐쓰고 난 다음에 K_LVASP의 갱신인증 이후에 EP_INTERNAL로부터 데이터를 겹쳐쓴다.

구현클래스들 DF_PT 및 DF_AD의 VAS-응용들에 부가하여, 파일 EF_TRANSFER는 겹쳐쓰여져야 한다. 이 목적 때문에, 이전(remove) 동작은 이전되거나 만료된 대로 아직 표시되지 않은 이 구현클래스의 객체들을 이전하기 위해 연속적으로 사용되며, K_{SIG_VASC}에 의해 그들의 서명을 점검하고, 목표카드의 EF_TRANSFER로의 이전을 실행한다. 반면에, 목표카드상에, 객체들이 이전되지 않은 대로 표시되어 그들은 계속 유효하게 될 것이다.

마지막으로, VAS-컨테이너의 전체적인 데이터는 전송되어야 한다. 특별하게, 목표카드의 순차번호는 소스카드의 가치에 조정되어야 한다.

VAS-데이타에 기입하는 절차는 하기의 것에서 설명된다:

딜러단말에서 VAS-데이타에 기입이 가능한 세 경우가 있는데, 이는 VAS-응용의 성질에 의존한다.

우선, 구현클래스 DF_PT 또는 DF-AD의 경우에서의 구매

VAS-공급자는 구현클래스 DF_PT 또는 DF-AD의 VAS-응용 A로 데이터를 기입하는 것이다.

VAS-데이타의 기입은 다음과 같이 진행한다:

1. 카드소지자는 VAS-카드를 딜러단말에 삽입한다.

2. 딜러단말은 VAS-컨테이너가 존재하는지 여부를 점검한다:

ㆍ READ RECORD < EF_ID의 SFI, 0 > (VAS-컨테이너 ID의 표시)

3. VAS-컨테이너의 확실성이 점검된다.

딜러단말 자체가 마스터키 KGK_AUT를 소유한다면, VAS-컨테이너의 내부인증을 요구할 수 있다.

ㆍ INTERNAL AUTHENTICATE < 난수, K_AUT의 KID >

딜러단말(KGK_AUT가 이용가능하지 않음)은 VAS-응용 A의 확실성 점검에 의해 VAS-컨테이너의 확실성을 간접적으로 점검할 수도 있다. 이는, VAS-응용이 올리기 동안에 VAS-컨테이너의 확실성을 점검하였던 서비스단말에서만 단지 올려질 수 있었기 때문이다. VAS-응용 A의 확실성점검은 VAS-컨테이너가 VAS-응용 A를 위한 키 K_LVASP또는 키 K_RVASP를 담고 있는 지를 딜러단말에서의 시험으로 되돌아가서 참조될 수 있다. 이는 예를 들면 다음과 같이 딜러단말에 의해 점검될 수 있다:

ㆍ SELECT FILE < PIX_A> (VAS-응용 A가 VAS-컨테이너에 올려지지 않았다면 오류표시 )

ㆍ INTERNAL AUTHENTICATE < 난수, K_RVASP또는 K_LVASP의 KID >

딜러단말은 응답을 점검하고 오류의 경우에는 (오류표시와 함께) 절차를 중단한다.

4. 딜러단말은 VAS-응용 A를 선택하며, 그 자체를 인증하고, 트랜잭션을 실행하기 위해 필요한 요소화일들을 설명한다.

ㆍ SELECT FILE < PIX_A> (단계 3에서 이미 실행되었다면 제거된다)

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE < K_LVASP(난수), K_LVASP의 KID >

ㆍ 선택항목(optional): UPDATE RECORD < DF_X의 EF_INFO의 SFI, 데이터 >

ㆍ 선택항목: UPDATE RECORD < DF_X의 EF_INTERNAL의 SFI, 데이터 >

ㆍ 선택항목: UPDATE RECORD < DF_X의 EF_VALUE의 SFI, 데이터 >

지금 구현클래스 EF_TRANSFER의 경우에 구매가 뒤따른다.

특별히, 구현클래스 EF_TRANSFER의 VAS-응용들(응용부류 인환권(Voucher))을 위해 VAS-공급자는 자신의 응용에 대한 소유화일구조 DF_X를 점유할 필요할 없다. 이 결과는 카드소지자가, VAS-응용인환권을 사용하기 이전에, VAS-응용을 올리기 위하여 서비스단말으로 진행할 필요가 없다는 데 있다. 오히려 그는, 직접적으로 딜러단말에서, 인환권 또는 영수증을 발행하며, 다른 단말에서 (이전동작에 의해) 이들이 상환(reimburse)되거나 또는 단순히 인환권 또는 영수증을 (읽기로) 보여준다. 따라서, VAS-데이터의 기입은 구현클래스 EF_TRANSFER의 VAS-응용들의 함축적 인 올리기로 귀결된다. 이 응용부류에 대해 유형기록의 개별적인 객체들로 이루어진 구현클래스 EF_TRANSFER가 존재한다. EF_TRANSFER에서의 기입(entry)은 명령 TRANSFER에 의해 독점적으로 가능하다. 딜러단말은 그 목적 때문에 유효한 말소키 K_DEC를 소유하여야 하며, VAS-응용 A의 PIX_A를 사용가능하게 하여야 한다.

VAS-데이타의 기입은 다음과 같이 진행한다:

1. 카드소지자는 딜러단말에 VAS-카드를 삽입한다.

2. 딜러단말은 VAS-컨테이너가 존재하는지 여부를 점검한다:

ㆍ SELECT FILE < AID_VAS> (VAS-컨테이너가 선택가능하지 않다면 오류표시)

ㆍ READ RECORD < EF_ID의 SFI, 0 > (VAS-컨테이너 번호의 표시)

3. 딜러단말은 단계 4로부터 MAC을 부가적으로 기입하는 순차번호를 읽는다:

ㆍ READ RECORD < EF_SEQ의 SFI, 0 > (순차번호의 표시)

4. 명령 TRANSFER는 기록이 EF_TRANSFER로 기입되도록 한다:

ㆍ TRANSFER < 트랜잭션일자, 만료일자, 발생기 코드, 데이터, PIX_A, K_DEC에 의한 MAC >

5. 딜러단말은 VAS-컨테이너가 틀림없는지 [즉, 연대비밀 K_DEC(joint secret K_DEC)을 소유하고] 여부를 TRANSFER 명령의 응답메세지의 정밀점검에 의해 점검할 수 있다. 이러한 전후관계에서, 위에서 부언 설명된 명령 TRANSFER 이후의 응답메세지를 참조한다.

마지막으로, 가치말소에 의해 VAS-데이타의 구매

VAS-공급자는, EF_TRANSFER의 전송필드(transfer field)에서 명령 TRANSFER를 사용하는 가치말소단계에 의해, 다른 VAS-공급자가 더 사용할 수 있는 자격(이를 테면 인환권 또는 영수증)을 발생시킬 수 있다. 데이터는 VAS-공급자의 VAS-응용 A의 EF_VALUE 또는 EF_INFO로부터 말소되어 말소 효력을 갖는다. 카드소지자는 EF_TRANSFER에서 객체의 형태로 권리를 획득한다.

VAS-데이타의 기입은 다음과 같이 진행한다:

1. 카드소지자는 딜러단말에 VAS-카드를 삽입한다.

2. 딜러단말은 VAS-컨테이너가 존재하는지 여부를 점검한다:

ㆍ READ RECORD < EF_ID의 SFI, 0 > (VAS-컨테이너 ID의 표시)

3. 딜러단말은 단계 4의 과정에서 MAC을 부가적으로 기입하는 순차번호를 읽는다:

ㆍ READ RECORD < EF_SEQ의 SFI, 0 > (순차번호의 표시)

4. 딜러단말은 VAS-응용 A를 선택한다:

ㆍ SELECT FILE < PIX_A> (VAS-응용 A가 VAS-컨테이너에 올려지지 않았다면 오류표시)

5. 딜러단말은 다음과 같은 경우가 될 수 있으므로 EF_VALUE 또는 EF_INFO로 부터 데이터를 말소하기 위한 명령 TRANSFER를 사용한다.

ㆍ TRANSFER < 데이터, K_DEC에 의한 MAC >

TRANSFER의 명령메세지의 구성(composition)은 이미 설명되었다. 말소를 실행하는 자격은, K_DEC에 의해 데이터에 관한 정확한 서명을 만들 수 있다면 단말에 의해 얻어진다. 이 서명은 VAS-컨테이너에 의해 점점된다. 성공적이라면, 기록은 VAS-컨테이너에 의해 EF_TRANSFER에 설정되고 순차번호는 증가한다.

6. 딜러단말은 TRANSFER 명령의 응답메세지를 점검함으로써 VAS-컨테이너가 인증되었는지[즉, 공통비밀 K_DEC을 소유하는] 여부를 점검할 수 있다.

이제 VAS-데이터를 말소시키는 절차가 다루어질 것이다. 두 종류의 말소절차가 있다:

ㆍ한편, 구현클래스 DF_PT 또는 DF_AD의 VAS-응용들에 대한 VAS-데이터가 말소동작, 즉 말소로 인한 VAS-데이터의 구매로 인해 적당한 VAS-공급자에 의해 말소될수 있다. 그런 방식으로, 가치는 소멸되며, 그로써 상이한 가치에 대한 잠재적인 자격이 창출된다.

다른 한편으로는, VAS-데이터가 추가명령(supplementary command) TAKE에 의해서만 EF_TRANSFER로부터 한 번 인출될 수 있다. 그 경우에, 자격은 소멸되며, 데이터는, 요구될 때, 다른 객체들에 의해 무효로 될 때까지 이전(remove)되었던 대로 표시되며, 추후의 사용(이를테면, 상환된 티켓은 왕복여행(return trip)을 위해 여전히 요구된다)하기 위해 전송필드에 남는다.

명령 TAKE에 의한 VAS_데이터의 말소는 다음과 같이 진행된다:

1. 카드소지자는 VAS-카드를 딜러단말에 삽입한다.

2. 딜러단말은 VAS-컨테이너가 사용가능한 지 여부를 점검한다.

· SELECT FILE < AID_VAS> (VAS-컨테이너가 선택가능하지 않다면 오류표시)

· READ RECORD < EF_ID의 SFI, 0 > (VAS-컨테이너 ID의 표시)

3. 딜러단말은 우선 요구된 객체가 이용가능한 지 여부를 결정하기 위해 VAS_응용들 보이기 동작인 특별한 경우를 사용하여 이용할 수 있는 객체들을 EF_TRANSFER로부터 표시한다. 다른 대안으로서, 명령 SEEK는 견본(sample)을 검색하기위해 사용될 수 있다. 만약 성공한다면, 단말은 검색된 기록의 번호 i를 인식한다.

4. 단말은, 명령 TAKE와 함께 i, 그에 의해 계산된 난수, 그의 PIX 및 단말ID를 전송하는 데 있어서 레코드번호 i를 보여주도록 기록을 표시한다.

ㆍ TAKE < i, 난수, PIX, 단말 ID >

딜러말단은 EF_TRANSFER로부터 데이터를 읽으면서 동시에 인출되었던 대로의 데이터를 식별하기 위하여 명령 TAKE를 사용한다. 부가하여, 명령의 실행은 두 개의 상이한 암호(cryptogram) C₁및 C₂의 발생을 초래한다.

암호 C₁은 키 K_SIG-VASC를 사용하는 VAS-컨테이너에 의해 계산된다. 이런 식으로, C₁으로 서명된 이전된 객체의 생산자(producer)는 시스템 동작자(system operator)로부터 유일성 및 확실성의 증거를 얻을 수 있다. 트랜잭션의 유일성 및 확실성은 객체가 최초로 기원되었던 (카드에 의해 점검되었던, 또한 TRANSFER 참조)것에서 VAS-공급자의 암호, 및 인출시에 카드에 의해 암호 C1 뿐만 아니라 트랜잭션에 대한 순차카운터의 유지로부터 기인한다.

암호 C₂는 키 KGK_DEC를 사용하는 VAS-컨테이너에 의해 계산되며, 이는 KGK_DEC, PIX 및 단말 ID로부터 VAS-컨테이너에 의해 유도된다. 연대비밀 K_DEC를 인식함으로써, VAS-컨테이너는 그의 확실성을 직접 단말에 입증할 수 있다. TRANSFER 명령중에 원래의 인환권들 또는 영수증들만이 인증된 VAS-컨테이너에 저장된다는 것이 또한 마찬가지로 점검된다는 사실로 인하여, 회수된 객체의 확실성은 결정될 수 있다. C₂가 순차번호, 회수비트 및 VAS-컨테이너 ID에 의해 간접적으로 형성되므로, VAS-컨테이너는 회수된 객체의 유일성을 더욱 단말에 입증할 수 있다.

누구든지 명령 TAKE를 사용하여 회수시킬 권리를 가진다.

더욱이, 서비스단말에서, 구현클래스들 DF_PT 및 DF_AD의 VAS-응용들을 읽기위해 패스워드 또는 PIN-보호 각각의 비활동성 또는 활동성이 가능하다. 게다가, VAS-컨테이너의 PIN은 그 PIN을 인식하고 있는 카드소지자에 의해 변경될 수 있으며, KSO에 의한 외부인증으로 시스템운영자에 의해 복구될 수 있다. 선택길이의 비수치의 기호들 또는 기호순차들은 또한 PIN 또는 패스워드로서 사용될 수 있다.

Claims

화폐단위들(monetary units) 또는 비화폐자격들(non-monetary entitlements)을 나타내는 다른 가치데이터(value data)가 카드소지자 및 적어도 하나의 트랜잭션협력자(서비스공급자) 사이에 전송되거나 또는 자격들의 검증을 위해 서비스공급자에게 제출되는 트랜잭션들을 실행하기 위한 것으로, 트랜잭션들을 실행하는데 요구된 데이터가 저장되는 저장기를 구비한 칩카드에 있어서,

각각이 카드소시자 및 하나 이상의 서비스공급자들 사이의 트랜잭션들의 실행을 허락하는 하나 이상의 카드응용들(VAS-응용들)을 카드에 올리기 위한 수단을 포함함을 특징으로 하는 칩카드.
제 1항에 있어서, 올리기 위한 수단은 데이터구조(DF_VAS, VAS-컨테이너)를 포함하고, 이 데이터구조는 그 속에 저장된 것들로,

카드소지자 및 서비스공급자 사이의 트랜잭션의 실행을 가능하게 만드는데 요구된 데이터(VAS-데이터)가 올려질 수 있는 부분구조(DF_PT, DF_AD, VAS-응용);

부분구조(VAS-응용)에 저장된 데이터의 성질 및/또는 구조에 관련한 정보를 담고있는 정의데이터집합을 구비하고, 정의데이터집합은,

데이터구조(VAS-컨테이너) 및/또는 칩카드를 식별하는 표시(denotation; 컨테이너-ID); 및

변형들에 대항하여 정의데이터집합 및/또는 데이터구조(VAS-컨테이너)의 보전(integrity)을 안전하게 하는 적어도 하나의 시스템키(K_SO)를 더 포함하는 칩카드.
제 1항 또는 제 2항에 있어서,

트랜잭션의 실행에서 상호교환되거나 또는 제출되어지고 화폐단위들 또는 비화폐자격들을 나타내는 데이터를 수용하는 전송저장지역(EF_TRANSFER) 및

데이터를 쓰기명령(TRANSFER)에 반응하여 전송저장에 쓰기 위한 수단을 더 포함하는 칩카드.
제 1항 내지 제 3항중 어느 한 항에 있어서,

트랜잭션들의 실행에 필요한 데이터를 부분구조 속으로 적어도 하나의 시스템키의 도움으로 올리기 위한 수단;

정의데이터집합의 데이터를 부분구조 속으로 올려진 데이터에 적응시키기 위해 정의데이터집합 속으로의 데이터의 써넣기를 위한 수단;

트랜잭션을 실행하는데 요구된 데이터가 카드의 데이터베이스 속으로 올려질 수 있는 추가 부분구조를 발생하기 위한 수단; 및/또는

카드에 대한 동적메모리관리를 위한 수단 중의 적어도 하나를 포함함을 특징으로 하는 칩카드.
선행하는 청구항들중 어느 한 항에 있어서,

부분구조들(VAS-응용들)은 각각이 특정한(particular) 서비스공급자에게 할당되어지는 상호 독립한 부분구조들에 의해 나타내어지며,

정의데이터집합은 적어도 하나의 시스템키(K_SO)에 의해 변형에 대항하여 보호되고 이 키에 의해서만 변형되어질 수 있고,

부분구조들(VAS-응용들)의 올리기는 정의데이터집합에 들어있는 시스템키의 사용으로만 진행할 수 있는 것을 특징으로 하는 칩카드.
선행하는 청구항들중 어느 한 항에 있어서, 정의데이터집합은,

단말에 관하여 칩카드의 자격을 인증하기 위한, 그리고/또는 칩카드에 관하여 단말의 자격 인증을 위한 적어도 하나의 인증키(K_AUT);

전송저장기로부터 제거되는 데이터를 서명하기 위한 적어도 하나의 서 명키(K_{SIG_VASC});

전송저장기 속으로의 쓰기절차를 위한 허가(authorization) 및/또는 가치데이터의 실효(invalidation)의 검증(verification)을 위한 단말 및 응용에 특별한 키들을 발생하기 위한 키발생키(KGK_DEC);

카드소지자에 의한 트랜잭션절차의 허가의 검증을 위한 PIN이라는 특징들 중의 적어도 하나를 포함하며,

시스템키(K_SO), 인증키(K_AUT), 서명키(K_{SGN_VASC}) 및 키 발생키(KGK_DEC)는 카드들에 독특한(individual) 또는 데이터구조(DF_VAS)에 특별한 키들이고,

부분구조(VAS-응용)는,

가치데이터의 저장을 위한 적어도 하나의 값저장기(EF_VALUE);

부분구조에 관련한 내부데이터의 저장을 위한 적어도 하나의 내부저장기 (EF_INTERNAL);

부분구조에 관련한 비내부(non-internal)데이터의 수용을 위한 적어도 하나의 정보저장기(EF_INFO); 및

값저장기 및/또는 내부저장기 및/또는 정보저장기로의 또는 그로부터의 쓰기 그리고/또는 정보검색(retrieval)절차를 위한 보안을 제공하는 적어도 하나의 키(K_LVASP, K_RVASP)를 수용하기 위한 키저장기(EF_KEY)라는 특징들 중의 적어도 하나를 포함하며,

칩카드는, 값저장기, 내부저장기 또는 정보저장기로의 또는 그로부터의 쓰기 및/또는 검색하기 위한 수단을 더 구비하고,

올리기 위한 수단은, 키를 적어도 하나의 시스템키에 의해 보호된 키저장기 속으로 쓰기 위한 수단을 구비함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 부분구조는,

부분구조에 데이터를 쓰도록 하는 허가를 점검하기 위한 키(K_LVASP); 및

부분구조로부터 데이터를 검색하도록 하는 허가를 점검하기 위한 키(K_RVASP)라는 완전체(integer)들 중의 적어도 하나를 포함함을 특징으로 하는 칩카드.
선행하는 청구항들중 어느 한 항에 있어서, 키저장기에 저장된 키들은 개개의 부분구조에 특별하고,

적어도 하나의 부분구조(VAS-응용)는 트랜잭션들의 실행을, 특별한 키들(K_LVASP, K_RVASP)중에서 개개의 부분구조(VAS-응용)에 특별하고 다른 부분구조들(VAS-응용들)을 위한 키들로부터 독립하는 적어도 하나에 의하여 보호하는 것을 특징으로 하는 칩카드.
선행하는 청구항들중 어느 한 항에 있어서, 카드는, 각각이 특정한 서비스공급자 및 카드소지자 사이의 트랜잭션들의 실행을 위해 소용되는, 복수개의 부분구조들(VAS-응용들)을 포함함을 특징으로 하고,

트랜잭션들의 실행은, 전송필드 속으로, 개별적으로 그로부터 데이터의 쓰기및/또는 검색, 그리고/또는 값저장기 속으로, 개별적으로 그의 밖으로 데이터의 쓰기 및/또는 검색을 함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 부분구조 및 서비스공급자 사이 뿐만 아니라 개개의 부분구조들(VAS-응용들)사이 둘 다에 트랜잭션들을 실행하기 위한 수단을 더 구비함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서,

시스템키(K_SO)는 시스템운영자(SO)에게만 알려지고, 카드에 독특한 그리고/또는 데이터구조(VAS-컨테이너)에 특별한 키이고,

정의데이터집합에 들어있는 추가키(further key)들은 카드에 독특한 그리고/또는 데이터구조(VAS-컨테이너)에 특별한 키들인, 것을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 정의데이터집합은,

데이터구조에 들어 있는 부분구조들의 디렉토리(EF_DIR)는 데이터구조(VAS-컨테이너) 속으로 올려진 부분구조들(VAS-응용들)의 부분구조에 특별한 식별번호(partial structure specific identification number)들을 담고있고, 뿐만아니라 정보는 부분구조들(VAS-응용들)이 물리적으로 저장되는 데이터구조(VAS-컨테이너)의 그 부분(that part)을 담고있는, 데이터구조를 명기(specify)하는 식별번호(EF_ID); 및

데이터구조의 판번호(EF_VERSION), 라는 완전체들 중의 하나 이상을 구비함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서,

회수(withdrawal)절차(Take)를 데이터가 전송저장기로부터 제거 및/또는 가치말소(value-cancel)됨에 의하여 실행하는 수단; 및

전송저장기로부터 데이터의 회수 또는 말소(cancellation) 동안, 데이터의 하나 이상의 확실성특징(authenticity feature)들을 발생하는 수단, 이라는 특징들 중의 적어도 하나를 구비함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 확실성특징들을 발생하기 위한 칩카드는,

회수된 데이터를 갖는 디지털서명(digital signature)을 발생하기 위한 서명키(K_{SIG_VASC}); 및

디지털서명의 발생에도 사용되는 트랜잭션을 특징짓는 트랜잭션번호를 발생하기 위한 수단을 포함함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 서명키(K_{SIG_VASC})는 개인키발생키(private key generating key)로부터 유래되는 개인키(private key)이고, 서비스공급자에 의한 서명을 점검하는 경우 공개키(public key)가 사용되는 것임을 특징으로 하는 칩카드.
선행하는 청구항들중 어느 한 항에 있어서, 칩카드는 적어도,

단말 및 부분구조에 특별한 키들(K_DEC)을 키발생키KGK_DEC)에 의하여 발생하기 위한 수단; 및

단말 및 부분구조에 특별한 키(K_DEC),

적어도 하나의 인증키(K_AUT),

적어도 하나의 시스템키(K_SO),

적어도 하나의 부분구조에 특별한 키(K_LVASP, K_RVASP),

서명키(K_{SIG_VASC}),

PIN,

부분구조의 식별, 및

단말의 식별이라는 완전체들 중의 적어도 하나를 사용하여 트랜잭션의 허가및/또는 보호를 검증하기 위한 수단, 이라는 완전체들 중의 하나를 포함함을 특징으로 하는 칩카드.
선행하는 청구항들중 어느 한 항에 있어서, 칩카드는,

데이터 검색 또는 쓰기 절차 이전에 인증키에 의하여 권한(authority) 및/또는 단말의 인증을 위한 수단,

그것들이 디지털서명 및/또는 키 형성(formation)에 의해 보호되는 데이터 검색 또는 쓰기 절차들을 실행하기 위한 수단이라는 완전체들 중의 적어도 하나를 구비함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 칩카드는,

PIN-보호를 활동적이게 및 비활동적이게 하기 위한 수단,

PIN을 변경하기 위한 수단이라는 완전체들 중의 적어도 하나를 더 구비함을 특징으로 하는 칩카드.
선행하는 청구항들 중의 어느 한 항에 있어서, 선행하는 청구항들 중의 어느 한 항에 따른 데이터구조는 카드플랫폼으로부터 독립하고, 칩카드는,

데이터구조 또는 이 데이터구조의 부분들을 다른 카드로 전송하기 위한 수단을 더 구비함을 특징으로 하는 칩카드.
단위통화의 및/또는 동일하거나 다른 서비스공급자들 사이의 다른 비통화자격들을 나타내는 가치데이터의 전송을 위해 저장지역 속으로 또는 그 밖으로의 데이터의 쓰기 또는 검색을 위한 저장지역을 포함함을 특징으로 하는 칩카드.
제 1항 내지 제 20항중 어느 한 항에 따른 칩카드의 사용을 위한 단말에 있어서, 이 단말은,

데이터구조를 식별하는 특징묘사(characterization, 컨테이너-ID)를 식별하기 위한 뿐만 아니라 칩카드의 데이터구조(VAS-컨테이너)를 식별하기 위한 수단을 포함하고,

카드의 부분구조들 및/또는 정의데이터집합 및/또는 전송저장기 중의 적어도 하나로부터의 데이터의 검색을 위한 수단;

카드의 전송저장기 속으로의 데이터의 쓰기를 위한 수단;

트랜잭션들의 실행에 요구된 데이터를 카드의 부분구조들(VAS-응용들)의 적어도 하나 속으로 올리기 위한 수단이라는 특징들 중의 적어도 하나를 더 포함함을 특징으로 하는 단말.
제 21항에 있어서, 단말은,

트랜잭션의 실행이,

값저장기 속으로의 데이터의 쓰기,

전송저장기 속으로의 데이터의 쓰기,

전송저장기로부터의 데이터의 제거(removal) 및/또는 말소,

부분구조로부터의 데이터의 검색,

전송저장기로부터의 데이터의 검색

이라는 단계들 중의 적어도 하나를 구비하는, 서비소공급자 및 카드소지자 사이의 트랜잭션들을 실행하기 위한 수단이라는 완전체들 중의 적어도 하나를 포함함을 특징으로 하는 단말.
제 21항 또는 제 22항에 있어서, 단말은,

단말 및 부분구조에 특별한 키(K_DEC),

카드에 독특하거나 또는 데이터구조(DF_VAS)에 특별한 적어도 하나의 인증키(K_AUT),

카드에 독특하거나 또는 데이터구조(DF_VAS)에 특별한 적어도 하나의 시스템키(K_SO),

적어도 하나의 부분구조에 특별한 키(K_LVASP, K_RVASP),

카드에 독특하거나 또는 데이터구조(DF_VAS)에 특별한 적어도 하나의 서명키(K_{SIG_VASC}),

카드에 독특하거나 또는 데이터구조(DF_VAS)에 특별한 PIN,

부분구조의 응용에 특별한 특징묘사(an application-specific characterization of a partial structure),

단말의 단말에 특별한 특징묘사(a terminal-specific characterization of a terminal)라는 완전체들 중의 적어도 하나의 도움으로, 트랜잭션을 위한 허가 및/또는 이것의 보호를 검증하기 위한 수단을 더 포함함을 특징으로 하는 단말.
제 21항 내지 제 23항중 어느 한 항에 있어서, 전송저장기 속으로 데이터를 쓰기 위한 수단은,

쓰기허가의 검증을 위해 단말 및 부분구조에 특별한 키(K_DEC)의 사용으로 데이터의 부호화를 위한 수단을 포함함을 특징으로 하는 단말.
제 21항 내지 제 24항중 어느 한 항에 있어서, 전송저장기로부터 데이터를 회수하는 처리를 데이터가 전송저장기로부터 제거 및/또는 가치말소됨에 의하여 실행하기 위한 수단을 더 포함함을 특징으로 하는 단말.
제 21항 내지 제 25항중 어느 한 항에 있어서,

전송저장기의 데이터를 제거완료된 것으로 특징묘사하기 위한 수단,

전송저장기의 데이터를 만료된 것으로 특징묘사하기 위한 수단

이라는 완전체들 중의 적어도 하나를 더 포함함을 특징으로 하는 단말.
제 21항 내지 제 26항중 어느 한 항에 있어서, 트랜잭션들을 실행하기 위한 수단은,

부분구조에서의 가치데이터를 변경하기 위한 수단,

다른 서비스공급자들 사이의 트랜잭션들을 카드소지자의 비용으로, 개별적으로는 그의 이익을 위해 실행하기 위한 수단이라는 완전체들 중의 적어도 하나를 포함함을 특징으로 하는 단말.
제 21항 내지 제 27항중 어느 한 항에 있어서, 단말은,

적어도 하나의 인증키의 도움으로, 카드에 관하여 단말 및/또는 단말에 관하여 카드의 인증을 위한 수단;

카드소지자에 의한 트랜잭션을 PIN에 의하여 보호하기 위한 수단;

PIN-보호를 활동적이게 및 비활동적이게 하기 위한 수단을 더 포함함을 특징으로 하는 단말.
제 21항 내지 제 28항중 어느 한 항에 있어서, 단말은,

단말에 특별한 특징묘사를 카드에 전송하기 위한 수단;

부분구조를 명기하는 특징묘사를 카드에 전송하기 위한 수단;

단말 및 부분구조에 특별한 특징묘사 뿐만 아니라 단말 및 부분구조에 특별한 키를 사용하여 허가의 인증을 위한 수단,

디지털서명 및/또는 코드화(encodification)에 의해 보호되는 데이터 검색 또는 쓰기 절차들을 실행하기 위한 수단이라는 완전체들 중의 적어도 하나를 더 포함함을 특징으로 하는 단말.
제 21항 내지 제 29항중 어느 한 항에 있어서, 단말은,

부분구조(VAS-응용)를 선택하기 위한 수단;

부분구조를 단말에 보이기 위한 수단;

부분구조의 데이터를 단말에 보이기 위한 수단;

부분구조(VAS-응용)를 카드에 올리기 위한 수단;

특징묘사를 카드에 올려진 부분구조(VAS-응용)에 올리기 위한 수단;

카드로부터 부분구조를 삭제하기 위한 수단;

부분구조를 다른 부분구조에 의해 대체하기 위한 수단;

부분구조를 또 다른 카드로 전송하기 위한 수단;

부분구조를 이것의 기능 및 이것의 연관(associate)서비스공급자에 관하여 해석하기 위한 뿐만 아니라 거기에 저장된 정보의 데이터검색 및 보이기(viewing)위한 수단이라는 완전체들 중의 적어도 하나를 더 포함함을 특징으로 하는 단말.
카드소지자 및 단말 뿐만아니라 칩카드의 사용에 연루된 적어도 하나의 서비스공급자 사이의 트랜잭션들을 실행하기 위한 방법에 있어서,

데이터가 카드소지자 및 서비스공급자 사이의 트랜잭션의 실행을 기능하게(enabling)하기 위해 그(칩카드) 속에 올려질 수 있게 칩카드에 저장되는 데이터구조를 준비(provision)할 뿐만 아니라 카드소지자 및 서비스공급자 사이의 트랜잭션들을 실행하기 위해 데이터구조(VAS-응용) 속으로 또는 그로부터의 데이터의 쓰기 또는 읽기 단계;

트랜잭션의 실행 동안에, 단위통화 또는 교화되어지거나 제출되어지는 비통화자격들의 저장을 위해 전송저장지역(EF_TRANSFER)을 준비할 뿐만 아니라, 전송저장기 속으로의 데이터의 쓰기 또는 전송저장기로부터의 데이터의 검색 단계중의 한단계를 포함하는 방법.
제 31항에 있어서, 이 방법은,

제 1항 내지 제 20항중 어느 한 항에 따른 칩카드의 사용단계;

제 21항 내지 제 30항 중의 어느 한 항에 따른 터미널의 사용단계;

부분구조들(VAS-응용들) 중의 적어도 하나의 값저장기 또는 내부저장기 또는 정보저장기 속으로 또는 그로부터의 데이터의 쓰기 또는 검색 단계중의 적어도 한단계를 포함함을 특징으로 하는 방법.
제 31항 또는 제 32항에 있어서,

적어도 하나의 키의 사용으로 단말 및/또는 칩카드의 자격의 인증 단계;

적어도 하나의 키의 사용에 의한 디지털서명 및/또는 코드화의 사용에 의해 트랜잭션의 보호단계 중의 적어도 하나를 더 구비함을 특징으로 하는 방법.
단말을 이용하여 칩카드에 데이터를 올리는 방법에 있어서, 이 방법은,

카드의 부분구조(VAS-응용) 속으로의 데이터의 올리기 단계;

카드의 정의데이터집합 속으로의 데이터의 쓰기 단계 중의 적어도 한 단계를 포함하는 방법.
제 34항에 있어서,

제 1항 내지 제 20항중 어느 한 항에 따른 칩카드의 사용 단계;

제 21항 내지 제 30항중 어느 한 항에 따른 단말의 사용 단계 중의 적어도 하나의 단계를 포함함을 특징으로 하는 방법.
제 1항 내지 제 20항 중의 어느 한 항에 따른 칩카드 및 제 21항 내지 제 30항중 어느 한 항에 따른 단말에 의해 특징지어지는, 트랜잭션을 실행하기 위한 시스템