KR100886137B1

KR100886137B1 - 스마트카드에 소프트웨어 콤포넌트, 특히 애플릿을로딩하는 방법

Info

Publication number: KR100886137B1
Application number: KR1020017012941A
Authority: KR
Inventors: 위리엉빠스깔; 보도알랭; 시겔랑크리스토프
Original assignee: 쎄뻬8 테크날러지스 에스에이
Priority date: 2000-02-10
Filing date: 2001-02-09
Publication date: 2009-02-27
Also published as: CA2366556A1; EP1188116A1; CN1221893C; AU3564701A; US20080163352A1; JP3834239B2; TW501063B; US20020174071A1; JP2003523012A; CN1363064A; FR2805059A1; KR20010110736A; WO2001059563A1

Abstract

본 발명은 스마트카드(2a)에 2개의 로딩 소프트웨어, 즉 상기 카드에 저장되는 소위 인로더(IL)와 오프로더를 각각 사용하여 애플릿을 로딩하는 방법에 관한 것이다. 본 발명은 2개의 특정 통신 프로토콜 레이어, 즉 카드리더를 호스팅하는 단말기(1)에 1개와 상기 카드에 다른 1개가 제공되는 것을 특징으로 한다. 상기 레이어들은 특히 상기 카드가 웹 클라이언트/서버와 CGI 게이트웨이 함수 케이퍼빌러티를 제공할 수 있도록 하는 인텔리전트 에이전트를 포함한다. 상기 방법은 HTTP 리퀘스트가 상기 카드에 송출되어 HTML 페이지를 지정하는 적어도 1 단계, HTML 폼에 의해 전송된 파라미터 결정 데이터의 검색을 포함하는 단계, 및 상기 CGI 함수 케이퍼빌러티를 사용하여 애플릿을 로딩하는 제2 로딩 소프트웨어(IL)의 실행을 포함하는 단계를 포함한다.

Description

스마트카드에 소프트웨어 콤포넌트, 특히 애플릿을 로딩하는 방법{METHOD FOR LOADING A SOFTWARE COMPONENT IN A SMART CARD, IN PARTICULAR APPLET}

본 발명은 스마트카드 내에 소프트웨어 콤포넌트를 로딩하는 방법에 관한 것이다.

이 방법은 더 구체적으로 불어로 아플리켓(appliquette)이라고 하며 애플릿(applet)이라는 영어 용어로 더 알려진 소프트웨어의 로딩에 적용된다. 그것은 JAVA(등록상표) 언어로 작성된 응용프로그램에 관한 것이다. 일반적으로 용량이 적은 이 응용프로그램은 그것이 속해있는 시스템 구조와는 독립적이다. 그러므로 그것들은 자바 가상기계(JAVA Virtual Machine)라는 개념에 포함된 범위 내에서 어떠한 전산 시스템에 대해서도 작동할 수 있다. 자바 언어로 작성된 응용프로그램은 일반적으로 바이트 코드라는 중계어로 전환된다. 상기 자바 가상기계는 목표 시스템에 대하여 직접 실행되도록 가상기계의 핵심이 되는 상기 바이트코드 번역기를 포함하고 있다.

일반적으로 이러한 형식의 응용프로그램을 실행하는 시스템 구조는 클라이언트 서버 형태로 되어 있다. 이 경우 시스템 서버에 탑재된 응용프로그램을 서블릿(servlet)이라고 지칭하며 클라이언트 서버에 탑재된 응용프로그램을 애플릿(applet)으로 지칭한다. 이하 본 발명에서는 일반적인 용어로 애플릿을 사용하기로 한다.

상기 애플릿 형식으로 구현된 응용프로그램은 코드 용량이 과대하지 않은 범위 내에서 다른 모든 응용프로그램과 마찬가지로 스마트카드에 탑재된 삭제 불가능한 메모리 장치에 내장될 수 있다.

또한 본 발명에 따른 상기 방법은 더 구체적으로 스마트카드를 읽을 수 있는 사용자의 컴퓨터나 단말기에 관련된다.

본 발명에서 단말기이라는 용어는 일반적인 의미로 이해되어야 한다. 상기 단말기는 특히 윈도우나 유닉스(등록상표)와 같은 다양한 개발 시스템 하에서 기능하는 개인용 컴퓨터에 의해 구성될 수 있다. 그것은 또한 워크스테이션, 노트북 혹은 전용 카드 단말기로 구성될 수도 있다.

종래 기술에서 스마트카드에 애플릿을 로딩하는 과정은 특수한 2개의 로딩프로그램으로 이루어진다. 이 프로그램은 일반적으로 첫 번째 것은 오프로더라는 용어로, 두 번째 것은 인로더라는 용어로 알려져 있다. 오프로더 프로그램은 단말기에서 실행되며 인로더 프로그램은 스마트카드 안에서 실행된다. 오프로더와 인로더 로딩프로그램은 스마트카드와 스마트카드를 수용하는 단말기간의 통신 목적으로 지정된 보편적인 프로토콜인 ISO 7816-3을 통해 내부적으로 소통한다. 이 프로토콜은 애플릿 로딩을 구현하기 위하여 일반적으로 공유되는 일련의 교환체계(하기될 APDU라는 형태의 명령)를 실행한다.

도1a는 종래 기술에 따라 스마트카드 내에 애플릿을 로딩하는 작업 구조의 일 실시예이다.

단말기(1)는 첫번째 특정 로딩 프로그램을 저장한다(오프로더- OL). 그것은 스마트카드(3)의 로딩 동작을 경유하여 스마트카드(2)와 교신한다. 이러한 전송은 상기 명령을 추출하는 규격화된 통신 프로토콜에 따라 실행되며 이 프로토콜은 이후에 상술될 것이다.

스마트카드(2)는 두번째 특정 통신 프로토콜(인로더- IL)로 저장된다.

이 방식의 첫번째 문제는 인로더와 오프로더 프로그램들이 상호 교통할 수 있도록 서로 짝을 이루어야 한다는 것이다. 만약 서로 다른 위치에 있다면 인로더와 오프로더 프로그램은 양립할 수 없다. 이러한 특징으로 말미암아 결국 사용자가 불편을 겪게 된다.

두번째 문제는 통신들이 상기 ISO7816 프로토콜에 따라 실행된다는 점에 기인한다. 사실, 이것은 오프로더와 인로더 프로그램 사이의 물리적인 유사성을 제공한다. 오프로더 프로그램은 일반적으로 단말기(1)에서 직접적으로 실행되어야 하며 다른 단말기이나 원격 서버에서는 실행되지 않는다.

인터넷의 급격한 확장과 더불어 항상 단말기에 접속하는 막대한 수의 사용자가 원격 서버와 연결하기 위하여 웹이라는 형식으로 이 네트워크에 접속되어 있다. 따라서 이 네트워크에 연결된 웹서버에 애플릿을 로딩하는 프로그램인 오프로더 부분을 저장하는 것이 일차 과제가 되었다. 하나 또는 다수의 스마트카드에 로딩할 애플릿들은 또한 그 서버 혹은 동일한 형식의 하나 또는 다수의 다른 서버들에도 저장되어야 한다.

종래 기술에서 이러한 조작 방법은 두 가지 결점을 갖고 있다. 첫번째는 상술한 대로 단말기와 스마트카드 사이의 통신을 위한 프로토콜이 가능하려면 결과적으로 오프로더와 인로더 프로그램의 위치가 물리적으로 근접해야 한다는 문제이다.

두번째로, 두 시스템 간의 전송, 예를 들면 특정 단말기와 원격 서버 간의 전송은 인터넷 망을 경유하여 인터넷 형식의 프로토콜로 이루어진다. 종래 기술 수준으로 스마트카드와 인터넷 망 사이의 직접적인 통신형식을 구축하는 것은 불가능하다. 이는 호환되지 않는 서로 다른 형태이기 때문이다.

본 발명에서 인터넷 네트워크라는 용어는 기업을 비롯한 단체 및 기관에서 내부적으로 운용하는 인트라넷(intranet) 형태와, 외부로 확장되는 엑스트라넷(extranet) 형태를 모두 포함하고 있으며, 일반적으로 모든 네트워크에서의 정보교환은 인터넷 프로토콜로 실행된다. 이러한 다양한 형태의 네트워크를 종합하여 인터넷 망으로 지칭한다.

본 발명에서는 간략하게 도1b와 1c를 참조하여 인터넷 망에 연결되어 있는 스마트카드로 이루어진 응용시스템의 일반적인 구조를 살펴보고자 한다.

스마트카드로 이루어진 응용시스템은 일반적으로 다음과 같은 기본 요소:

- 하나의 스마트카드;

- 상기 단말기를 구성하는 호스트 시스템;

- 통신망, 즉 지정 애플리케이션이 연결된 인터넷 망; 및

- 기타 인터넷 망에 연결된 애플리케이션 서버

를 포함하고 있다.

도1b는 이러한 구조의 일례를 도식으로 나타내고 있다. 단말기(1), 예를 들면 개인용 컴퓨터는 스마트카드(2)의 로딩(3)을 포함한다. 상기 로딩(3)은 비물리적인 방법으로 단말기(1) 내부로 통합될 수 있다. 스마트카드(2)는 단말기(1)와의 통신과 입출력 연결장치에 전원을 공급할 수 있도록 매체의 표면에 노출되는 통합적인 서킷(20)을 포함한다. 여기에는 인터넷 망(RI)의 접속서킷(11)이 포함된다. 이 서킷들은 전환된 전화선이나 혹은 상위 통로(통합서비스 연산망-RNIS, 케이블 또는 위성 등)에 연결되기 위한 하나의 모뎀으로 구축될 수 있다. 서킷(11)은 인터넷 서비스 공급업체(Internet Service Provider, 또는 ISP)망을 경유하거나 혹은 직접적으로 인터넷 망(RI)에 연결되도록 허용한다. 또한 동일하게 프록시라는 중계시스템이나 방화벽(firewall)이라는 보안 시스템 방식을 사용할 수 있다.

단말기(1)는 일체의 서킷과 성능 구현에 필수적인 장치들을 포함한다. 도면의 단순화를 위하여 별도 표시하지 않았지만, 주기억장치, 램(RAM)과 롬(ROM), 대용량 자기디스크 기억장치, 디스크 재생장치나 CD롬 등이 이에 해당한다.

보통, 단말기(1)는 또한 통합형 또는 비통합형의 일반적 주변장치들, 즉 모니터(5), 자판(6a), 마우스(6b) 등을 포함한다.

단말기(1)는 인터넷 망(RI)에 연결된 모든 전산 시스템이나 서버(4)와 통신할 수 있으며 도1a에 나타나 있다. 접속서킷(11)은 단말기(1)를 브라우저 혹은 웹 네비게이터라는 특정 소프트웨어(10)를 이용하여 서버(4)와 통신할 수 있도록 한다. 이는 일반적으로 클라이언트 서버 모드에 의해서 전체 인터넷 망(RI)에 분배된 컴포넌트의 파일이나 다양한 응용프로그램들에 접속하도록 허용한다.

통상, 네트워크에서의 통신은 중첩된 다양한 소프트웨어 계레이어를 포함하는 규격에 부응하는 프로토콜에 의거하여 실행된다. 인터넷 망(RI)의 경우 통신은 이러한 통신 유형에 적합한 프로토콜에 의해 실행된다. 이하 상술하겠지만, 이것도 마찬가지로 다수 소프트웨어 계레이어를 포함하고 있다. 통신 프로토콜은 특수한 목적으로 설계된 응용프로그램의 기능에 따라 선택된다. 즉, 웹상의 질의, 파일 전송, 메일(e-mail), 포럼이나 뉴스 등이 이에 해당된다.

단말기를 포함하는 시스템의 논리적인 구조와 스마트카드에서 스마트카드로의 해독은 도 1C에 표시되어 있다. 그것은 자체적으로 컴포넌트를 포함하는 ISO7816 프로토콜로 구현되었다.

- ISO 7816-1과 7816-2는 카드의 규격과 마킹(marking)에 대한 것이다.

- ISO 7816-3은 단말기와 스마트카드 간 정보 전송에 관한 것이다.

- ISO 7816-4는 명령 형식과 주문형 구조에 관한 것이다.

도1c에서 단말기(1) 옆에 표시된 ISO 7816-3(101) 기준에 상응하는 계레이어과 명령어 관리 시스템 APDU(ISO 7816-4)(102)만을 제시했다. 스마트카드(2) 옆에 ISO 7816-3에 부합하는 레이어(201)에 표시했고 ADPU는 참조 210이다. 응용프로그램들은 A1,....Ai.....An으로 표시되어 있고 n은 스마트카드(2)에 표시된 응용프로그램의 최대수이다.

일부 응용프로그램 Ai는 스마트카드(2)에 등록되어 있고 주문형 방식으로 단말기(1)와 통신한다. 상기 방식은 전형적으로 로딩 명령과 기입 명령을 나타낸다. 명령어 형태는 영어로 APDU(Application Protocol Data Unit)라는 용어로 알려져 있다. 그것은 상기 ISO7816-4로 규정되어 있다. 주문형 APDU는 "APDU.command"로 기록되어 있고 응답형 APDU는 "APDU.response"로 기록되어 있다. APDU들은 상기 ISO 7816-3의 특정 프로토콜을 이용하여 스마트카드와 로딩카드 사이에서 호환된다.

도 1C에 나타난 것처럼, 스마트카드 2에 서로 다른 몇몇 애플리케이션들이 포함되어 있을 때는, 다중-응용 카드에 대해 말하는 것이다. 그러나, 단말기 1은 한번에 단 하나의 애플리케이션과만 대화한다. 예를 들어, 애플리케이션 Aj는 초기에 등록될 수 있는, 혹은 단말기 1로부터 로딩될 수 있는 '애플릿"의 형태로 나타난다. 이를 위해, 도 1A에서 보듯이, 우리는, 스마트카드 2의 애플리케이션 Aj 중 하나를 형성하며, 단말기 1 안에 등록된, "오프-로더" 프로그램과 "인-로더" 프로그램를 이용했다.

특정 애플리케이션 Aj의 선택은 선택형 ("SELECT") "APDU"의 도움으로 이루어진다. 일단 선택이 실행되면, 그 뒤를 잇는 "APDU"는 이 애플리케이션 쪽으로 향하게 된다. 이를 위해, 새로운 "APDU SELECT"는 진행중인 애플리케이션을 버리고 다른 것을 찾아야 한다. "APDU" 201의 관리 소프트웨어 일부는 스마트카드 2 안에서 특정 애플리케이션 Aj를 선택할 수 있게 하고, 이미 선택된 애플리케이션을 기억하게 하며, 이 애플리케이션 쪽으로 그리고 그것으로부터 "APDU"를 보내거나 받을 수 있게 한다.

방금 설명한 것을 요약하자면, 애플리케이션 Aj의 선택과 이것과의 대화는 "APDU" 명령들을 교환함으로써 행해진다. 이후에 "GCA"(Generic Card Application;일반 카드 애플리케이션)라고 불리게 될, 애플리케이션 Aj는 종래의 애플리케이션들이라고 가정한다.

이 동작 모드는, 교환된 "APDU" 명령들이 호환되고 이 두 애플리케이션들에 포함될 수 있도록 하기 위해, OL과 IL 프로그램들이 쌍을 이루어야 한다는 것을 설명한다.

이 호출들이 실행되면, 스마트카드 2는 상업용 표준 네비게이터들의 코드를 변경시키지 않고는, 직접 이 후자들과 통신할 수 없다는 것에 주목한다.

또한, 무엇보다도, 위의 표준 및 기준에 부합되는, 현행 스마트카드들은 인터넷 망과 직접 통신하는 것을 더 이상 허용하지 않는 하드웨어 및 소프트웨어 구성을 가진다. 특히, 이것들은, 이 인터넷 망 위에서 사용되는 프로토콜 중의 어느 하나에 따라, 데이터 패킷들을 받아들이고 전송할 수 없다. 그러므로, 단말기 1 안에, 일반적으로, 앵글로-색슨계 용어로 "플러그-인"이라고 불리는 형태로, 추가의 소프트웨어를 대비할 필요가 있다. 이 소프트웨어는, 도 1B에서 참조12로 나타난 것으로써, 네비게이터 10과 카드 2 사이, 더 정확히 말하자면 이 카드 2의 전자 회로들 20 사이에 인터페이스를 실행한다.

본 발명은 기존 기술의 단계와 장치의 불편함을 보완하고, 그에 대한 필요성에 부응하기 위한 것이다.

본 발명의 첫번째 특성에 따르면, 두 로딩 프로그램들, OL과 IL은 더 이상 서로를 의지하지 않는다. 달리 말해, 그들은 더 이상 서로 호환되지 않는 것으로 나타난다.

본 발명의 두번째 특징에 따르면, 로딩 프로그램들 중 OL 파트는 더 이상 단말기 안에, 즉, 두번째 부분 IL과 물리적으로 가까운 관계로 저장되지 않는다. 완전히 반대로, 프로그램 OL은 떨어져있는 서버 위로 저장되며, 인터넷 형태의 망을 경유하여 단말기에 연결된다.

이로써, 그리고 본 발명의 또 다른 특성에 따르면, 스마트카드는 그것에 결합된 단말기에 대해 "WEB" 형의 서버/고객으로 작용한다.

이 목적을 이루기 위해, 스마트카드 안에 특정 통신 소프트웨어 레이어, 그리고 단말기 안에 그것이 늘어져 있는 것을 예상한다. "특정"이라는 용어는 본 발명의 단계에서 특정한 것으로 이해되어야 한다. 사실, 소위 특정한 이 통신 레이어들은, 어떠한 애플리케이션이 고려된다 할지라도 평범하게 만들어진다. 이들은, 한편으로는, 스마트카드와 단말기 사이, 그리고 다른 한편으로는, 스마트카드와 망 사이에서 양방향 데이터 교환 과정에만 개입한다.

특정 통신 소프트웨어 레이어들은, 특히, 소위 "인텔리전트 에이전트(지적 요인)"라고 불리는, 소프트웨어 구성요소들을 포함하는 데, 이들은 특히 프로토콜 변환을 할 수 있게 해준다. 인텔리전트 에이전트들은 이후에, 간단히 "에이전트"라고 불릴 것이다. 단말기와 스마트카드에 각각 결합된 특정 통신 레이어들 안에는 쌍을 이룬 에이전트들이 있다. 본 발명의 방법에 따르면, 쌍을 이룬 에이전트들 간에 세션들이 구축된다.

또 다른 특성에 따르면, 본 발명의 단계는 종래 형태, 즉, 스마트카드 안에 있는 전술한 "GCA" 형태의 애플리케이션 활성화를 가능하게 하며, 그것들을 변경시킬 필요가 없다.

이를 위해, 소위 스트립트 변환기이며, 네비게이터의 요구들을 받아들이고, 그것들을 "GCA" 형 애플리케이션에 의해 포괄적인 "APDU" 명령들로 변환시키는, 몇몇 혹은 하나의 특정 인텔리전트 에이전트를 예상한다. 따라서, 종래의 "웹(WEB)" 서버들 안에서 "CGI"란 명칭으로 알려진 것과 유사한 기능을 스마트카드 안에 주입한다. 이 기능은 "HTTP"형의 인터텟 프로토콜에 의해 스마트카드 안에서 애플리케이션을 사용할 수 있게 해준다.

스마트카드 안에 "애플릿"을 로딩하는 것은 이 "CGI" 인터페이스에 의해 행해질 수 있다. 로딩 프로그램 IL 파트는 명령 스크립트로 간주되며, 이후에 "CGI-스크립트"라고 불리게 되고, 스마트카드에 의해 제공되는 "WEB" 서버 기능에 추가된다. OL과 IL 프로그램들 간의 교환은, 종래의 서식을 이용하여, 앵글로-색슨계 용어 "HTML" 또는 "forms;형식"으로 전개될 수 있다.

스마트카드의 판독기를 경유하여, 단말기와 스마트카드 간 통신을 위해 전술한 ISO 기준을 모두 유지하면서, 본 발명에 따른 방법은 "TCP/IP" 인터넷 통신 프로토콜을 이용하여 OL과 IL 로딩 프로그램 부분들 간 교환을 할 수 있게 해주며, OL 부분과 로딩할 "애플릿"들은 국소적으로 또는 떨어져있는 서버 안에 저장될 수 있다.

그러므로 본 발명의 주요 대상은 결정된 첫번째 프로토콜에 따라 통신을 허용하는 스마트카드 판독기의 중개로 상기 스마트카드에 연결된 단말기로부터 스마트카드 안에 소프트웨어 하나를 로딩하는 방법이며, 상기 로딩은 첫번째와 두번째 로딩 프로그램들을 이용하고 그것들이 협조함으로써 행해지며, 상기 두번째 로딩 프로그램은 상기 스마트카드 안에 저장되고, 적어도 다음의 방법들을 포함하는 것을 특징으로 한다 :

a/ 첫번째 예비 단계는, 상기 스마트카드 안에, 특정 통신 프로토콜 레이어를 형성하는, 첫번째 소프트웨어 하나를 주입하는 것으로 구성된다;

b/ 두번째 예비 단계는, 상기 단말기 안에, 특정 통신 프로토콜 레이어를 형성하는 두번째 소프트웨어 하나를 주입하는 것으로 구성된다;

상기의 첫번째와 두번째 소프트웨어들은 적어도 한쌍의 짝을 이룬 첫번째 소프트웨어 엔티티들을 포함하며, 각각의 상기 엔티티들은 적어도 상기 단말기와 상기 스마트카드 간에 양방향 데이터 교환 세션을 구축할 수 있게 하고, 상기 스마트카드가 고객/서버 "WEB" 기능을 제공하도록 서로 협조한다.

세번째 예비 단계는, 상기 스마트카드가 소위 "CGI" 다리 인터페이스 기능을 제공하고, 상기 스마트카드가 소위 두번째 로딩 프로그램에 결합된 일련의 명령들 중의 적어도 하나를 포함하도록 하기 위해, 연속적인 명령들을 해석하고 상기 두번째 특정 소프트웨어와 협조하도록 연속적인 명령으로 그것을 번역할 수 있는, 적어도 하나의 두번째 소프트웨어 엔티티를 스마트카드 안에 주입시키는 것으로 구성된다.

1/ 상기 첫번째 로딩 프로그램이 상기 두번째 로딩 프로그램에 의해 공급된 로딩 파라미터 데이터를 회수할 수 있도록 적어도 상기 단말기와 상기 스마트카드 간 데이터 교환의 첫번째 세션을 개방;

2/ 소위 첫번째 로딩 프로그램에 상기 로딩 파라미터 데이터들을 전달할 수 있도록 상기 스마트카드와 적어도 상기 단말기 간 두번째 데이터 교환 세션을 개방하며, 상기 파라미터 데이터는 소위 두번째 로딩 프로그램에 결합된 소위 명령들에 대한 참조를 포함한다; 그리고

3/ 상기 로딩 파라미터 데이터들을 고려하는 로딩 파일을 맡기기 위해, 적어도 상기 단말기와 상기 스마트카드 간 세번째 데이터 교환 세션을 개방하며, 상기 파일은 로딩할 상기 소프트웨어의 데이터들을 포함한다; 즉, 소위 두번째 로딩 프로그램에 전송된 일련의 명령들을 발생시키고, 이 프로그램을 실행하며 상기 소프트웨어로부터 상기 언로딩을 얻을 수 있도록, 상기 "CGI" 기능을 이용함으로써, 소위 두번째 로딩 프로그램에 결합된 상기 연속적인 명령들의 해석한다.

도 1A는 기존의 기술에 따라 스마트카드 안에 "애플릿" 로딩을 할 수 있게 해주는 구조의 실행 예를 도식적으로 나타낸 것이다;

도 1B와 1C는 기존 기술에 따라 인터넷 망에 연결된 스마트카드를 기초로한 애플리케이션 시스템을 예로 들어, 외형적인 그리고 논리적인 구조들을 각각 나타낸 것이다;

도 2 본 발명에 따라 스마트카드를 기초로 한 애플리케이션 시스템의 한 예를 도식적으로 나타내며, 이 스마트카드는 고객/서버 "WEB"으로 작용한다;

도 3은, 본 발명의 견지에서, 소위 인텔리전트 에이전트 소프트웨어 엔티티들 간 세션의 상태들을 나타낸 도해이다;

도 4는 스마트카드가 인텔리전트 에이전트를 포함하는 본 발명에 따라 시스템의 논리적인 구조를 단순하게 나타낸 것이다;

도 5는 스마트카드가 스크립트 변환 인텔리전트 에이전트들을 포함하는 본 발명에 따라 시스템의 논리적인 구조를 단순하게 나타낸 것이다;

도 6은 본 발명에 따라 스마트카드 안에 "애플릿"을 로딩할 수 있게 하는 구조의 실행 예를 도식적으로 나타낸 것이다;

도 7은 본 발명의 방법에 따른 "애플릿" 로딩 파일의 구조를 나타낸다;

도 8은 첫번째 실제 실행 예에 따라 스마트카드 안에서의 "애플릿"의 주요 로딩 방법 단계들을 도식적으로 나타낸다;

도 9는 두번째 실제 실행의 예에 따라 스마트카드 안에서 "애플릿"의 주요 로딩 방법 단계들을 도식적으로 나타낸다;

도 9와 10은 소위 "GET"와 "POST" 방법들을 각각 사용할 수 있도록, 본 발명에 따라 스마트카드 안에 "애플릿" 로딩 방법으로 사용할 수 있는 "HTML" 언어 서식의 두 예를 나타낸다; 그리고

도 12A와 12G는 본 발명에 따라 스마트카드 안에 "애플릿"을 로딩할 수있게 해주는 시스템들의 구조 실행에 대한 몇가지 실행 변이형들을 나타낸다.

이어서, 범위 제한 없이, 즉, 본 발명에서 선호되는 애플리케이션의 범주 내에서, 즉, 상반된 언급 없이, 인터넷 네트워크를 통해 하나 또는 몇몇의 원격 서버에 연결된 단말기의 경우를 알아보고자 한다.

본 발명에 따라 스마트카드 안에 있는 애플리케이션들을 활성화시키는 방법을 설명하고 도 2를 참조로 하여, 사용할 구조에 대해 상세히 설명하기 전에, 우선 망 위에서의 통신 프로토콜에 대한 주요 특징들을 간략하게 상기해 보는 것이 좋다.

통신 망의 구조는 여러 레이어로 설명된다. 예를 들어, "ISO"로 정의되는 "OSI" ("Open System Interconnection"; 개방된 시스템 상호 연결)에는 소위 하부 레이어들(예를 들면, 물리적 전송 지원과 관련된 소위 "물리적인" 레이어)로부터 소위 상부 레이어들(예를 들면, 소위 "애플리케이션" 레이어)까지 일곱개의 레이어가 있으며, 이들은 중간 레이어들, 특히 소위 "운반" 레이어를 통과한다. 해당 인터페이스들을 통해, 하나의 레이어는 그 바로 위에 있는 레이어에 서비스를 제공하며 그 바로 아래에 있는 레이어에 다른 서비스를 요구한다. 레이어들은 본래의 상태를 이용하여 통신한다. 그것들은 또한 같은 높이의 레이어들과 통신할 수 있다. 어떤 구조들에서는, 몇몇 레이어들이 존재할 수 없다.

인터넷 형의 환경에서, 레이어들은 5개이며, 더 정확하게 말하면, 상부부터 하부까지 있다: 즉, 소위 애플리케이션 레이어 ("http", "ftp", "e-mail", 등), 소위 운반 레이어("TCP"), 소위 망 어드레스 레이어 ("IP"), 소위 데이터 연결 레이어 ("PPP", "Slip", 등), 그리고 소위 물리적 레이어가 있다.

단말기(1)과 스마트카드(2a) 안에 주입된, 특정 통신 프로토콜 소프트웨어들의 레이어들, 각각 참조번호 13과 23a를 제외하고, 도 2를 다시 참조해 보자면, 하드웨어 혹은 소프트웨어의 다른 요소들은 기존의 기술과 공통되며, 상세하게 다시 설명할 필요는 없다.

단말기(1)은 예를 들면 모뎀으로 구성되는 망 RI에 접근하는 회로들(11)을 포함한다. 이 회로들은 "물리적" 그리고 "데이터 연결" 레이어에 해당하는, 하부 소프트웨어 레이어들, 제1하부 레이어인 C1과 제2하부 레이어인 C2를 다시 모은다.

우리는, "망의 어드레스" 레이어(인터넷의 경우 "IP")와 "운반"("http", "ftp", "e-mail", 등)에 해당하는, 상부 레이어들 C3과 C4도 나타냈다. 애플리케이션의 상부 레이어("http", "ftp", "e-mail" 등)은 나타내지 않았다.

하부 레이어들, C1, C2와 상부 레이어들 C3, C4 간의 인터페이스는 일반적으로 "하부 드라이버 레이어"라고 불리는 소프트웨어 레이어로 구성된다. 상부 레이어들, C3와 C4는 이 인터페이스 위로 기대며 그것들에 해당되는 특정 기능에 대한 장서 또는 망 14 장서의 중개로 사용된다. 인터넷 네트워크의 경우, "TCT/IP"는 소위 "소켓" 장서들을 이용하여 사용된다.

이 구조는, "WEB" 페이지(프로토콜 "HTTP")를 조사하도록, 파일을 전송하도록(프로토콜 "FTP") 또는 전자 우편을 발송하도록, 네비게이터(10)로 하여금 서버(4) 쪽으로 요구를 할 수 있게 하며, 이는 완전히 재래식 방식이다.

단말기(1)에는 또 통합되었거나 그렇지 않은 카드 판독기(3)가 있다. 스마트카드(2a)와 통신하기 위해, 카드 판독기(3)은, C1과 C2와 유사한 역할을 하는, 두개의 하부 레이어, CC1(물리적 레이어)과 CC2(데이터 연결 레이어)도 포함한다. CC1과 CC2와의 소프트웨어 인터페이스들은, 예를 들면, "PC/SC" 라고 명시하여 설명된다. CC1과 CC2 그 자체는, 상기된 바와 같이, 특히 ISO 7816-1부터 7816-4 기준들로 설명된다.

보충적 소프트웨어 레이어(16)은 응용 레이어들(나타나지 않음)과 하부 레이어들, CC1와 CC2 사이에 인터페이스를 형성한다. 이 레이어(16)에서 전개되는 주요 기능은 멀티플렉스(다중화)/디멀티플렉스 기능이다.

스마트카드(2a)와의 통신은 "UNIX"(등록 상표) 형의 활용 시스템 안에서 파일들을 조작하기 위해 사용된 것과 유사한 파라디금에 따라 실행된다; 즉, 열기("OPEN"), 읽기("READ"), 쓰기("WRITE"), 닫기("CLOSE") 등이다.

스마트카드(2a) 쪽에서, 유사한 구조, 즉, 완전히 16 레이어와 유사한, 인터페이스(26a)의 레이어 뿐 아니라, 하부의 두 레이어들의 존재, 참조 CCa1(물리적 레이어)와 CCa2(데이터 연결 레이어)를 발견할 수 있다.

본 발명의 첫번째 특징에 따라면, 여기저기에서, 즉 단말기(1)과 스마트카드(2a)에서, 두개의 특정 프로토콜 레이어들을 예측할 수 있다; 각각 13과 23a이다.

단말기(1)에서, 특정 레이어 13은, 멀티플렉서 레이어 16을 통해, 하부 "드라이버 레이어들(15)"에, 망 레이어들, C3과 C4의 장서(14)에, 그리고 카드 판독기(3)의 프로토콜 레이어들, 즉, 하부 레이어들, CC1과 CC2에 결합된다. 특정 레이어 13은 스마트카드(2a)로부터/쪽으로 망 패킷을 전송할 수 있게 해준다. 또한, 그것은, 스마트카드(2a)와 더불어 이용할 수 있도록, 인터넷 네비게이터(10), 전자 우편, 등.. 과 같은 기존의 애플리케이션들을 적응시킨다.

스마트카드(2a) 쪽에서, 레이어 13으로부터 매달려 있는, 참조 23a, 특정 레이어의 보충 예(instance)로 구성되는, 완전히 유사한 구조를 발견하게 된다.

더 정확하게 말해, 특정 레이어들, 13과 23a는 세개의 주요 소프트웨어 요소들로 세분된다:

- 종래의 레이어들 CC1, CC2, CCa1, CCa2를 통해, 13과 23a 레이어들 간 정보 블록을 전송하는, 130 또는 230a 모듈;

- 예를 들면, 프로토콜 변환 기능을 실행하는, 소위 "인텔리전트 에이전트" 132 또는 232a, 하나 또는 몇몇 소프트웨어;

- 그리고, 각각 131과 231a인, 특정 구성의 관리 모듈; 특별한 인텔리전트 에이전트에 동화될 수 있는 모듈이다.

이후에는, 앞서 지적한 것처럼, 인텔리전트 에이전트들을 간단하게 "에이전트"라고 부를 것이다.

그러므로, 단말기(1)와 스마트카드(2a)에서, 두 엔티티들 간 통신 프로토콜 스택을 발견할 수 있다.

두개 높이의 레이어들(데이터 연결 레이어), CC2와 CCa2는, 스마트카드(2a)와 단말기(1) 간의 교환을 보장해준다. 이 레이어들은 송신 오류들을 탐지하고 경우에 따라 교정하는 일을 맡는다. 여러 프로토콜들이 사용될 수 있으며, 대략 예를 들어보면 다음과 같다:

- 추천 ETSI GSM 11.11;

- T=0 특징 모드로 된, ISO 7816-3 기준으로 정의된 프로토콜;

- 블록 T=1 모드로 된, ISO 7816-3 기준으로 정의된 프로토콜;

- 또는, "HDLC" 트램 모드로된, ISO 3309 기준으로 정의된 프로토콜(High-Level Data Link Control procedure; 고급 데이터 링크 제어 절차).

본 발명의 범주 내에서, 블록 모드로 된, ISO 7816-3 프로토콜을 우선적으로 사용하게될 것이다.

알려진 대로, 각각의 프로토콜 레이어에는, 같은 레이어의 레이어들 간, 그리고 서로의 레이어들 간 데이터 교환을 할 수 있게 해주는 수 많은 프리미티브(원래 상태의 것)들이 결합되어 있다. 예를 들어, 두개 높이의 레이어에 결합되어 있는 프리미티브들은 "데이터 요구"형("Data.request"), 카드에 의한 "데이터 발송"("Data.response"), 그리고 "데이터 확인"("Data.confirm"), 등이다.

더 특별하게 말하자면, 13과 23a 레이어들에는 스마트카드(2a)와 호스트, 즉, 단말기(1) 간의 대화가 로드되어 있다. 이 레이어들은, 예를 들어, "HTML" 포맷에 하이퍼텍스트의 형태로 전개되는 메뉴를 통해 단말기(1)과 스마트카드(2a)의 사용자 (나타나지 않음) 간에 정보 교환을 할 수 있게 해준다. 그것들은 또 데이터 패킷의 발송과 접수에 맞도록 구성을 적응시킬 수 있게 해준다.

위에서 지적한 것처럼, 레이어들에는 세가지의 서로 다른 엔티티들이 있다.

첫번째 레이어, 130 또는 230a는 근본적으로 소프트웨어 멀티플랙서로 구성된다. 이는 프로토콜 데이터 단위 형태로, 스마트카드(2a)와 호스트 단말기(1) 간의 정보 교환을 할 수 있게 해준다. 이것은 데이터 패킷 통신자와 유사한 역할을 한다. 이 단위들은 두개 높이의 레이어를 통해 발송되거나 접수된다 (데이터 연결 레이어). 이 특정 통신 프로토콜은 적어도 한쌍의 "에이전트들"을 통신하게 할 수 있다. 각 쌍의 첫번째 에이전트(132)는 단말기(1) 쪽, 레이어 13 안에 있으며, 두번째, 232a는, 스마트카드(2a) 쪽, 레이어 23a 안에 있다. 두 "에이전트들" 간의 연결은 이후에 "S-Agent'라고 부르게 될, 하나의 세션과 결합되어 있다. 레이어, 13과 23a 중의 어느 하나가 몇개의 에이전트들을 포함하고 있다면, 같은 레이어의 에이전트들은 그들 간 또는 131과 231a 모듈들과 세션을 구축할 수 있으며, 이는 특정 에이전트들을 구성한다.

더 정확히 말해, 에이전트는, 단말기(1)에 의해 사용되는 구성에 따라, 세개 및 네개 높이 레이어들의 기능들을 전체적으로 혹은 부분적으로 실행할 수 있는 자율 소프트웨어 엔티티이다.

에이전트들은 특징이나 특별한 속성과 연결되어 있다. 생각을 정리하고, 제한없이 예를 들어 보자면, 다음의 여섯가지 특징들은 에이전트들과 결합되어 있다:

- "호스트" : 단말기 안에 있는 에이전트;

- "카드" : 스마트카드 안에 있는 에이전트;

- "로컬" : 망과 통신하지 않는 에이전트;

- "망" : 망과 통신하는 에이전트 (단말기 쪽);

- "고객" : 세션을 시작하게 하는 에이전트;

- "서버" : 세션의 요구를 받아들이는 에이전트

특정 에이전트는 하나의 참조, 예를 들면, 전체 16 비트의 수로 식별된다 (예를 들면, 0과 65535에 포함되어 있다). 큰 무게의 비트(b15=1)는 참조가 국소적(스마트카드 또는 단말기에서 국소적인 통신)이거나 멀리 떨어져 있는지를(b15=0) 가리킨다.

에이전트의 주된 종류는 두가지이다 : "서버'형의 에이전트로서, 고정된 참조로 식별되며, "고객"형 에이전트들은, 가변형 참조로 식별되고, 이는 하루살이라고 말하여지며, 관리 모듈 131 또는 231a로 전달된다.

에이전트들은, 목적지 참조와 출처 참조를 구성하는 소위 "프로토콜 데이터 유닛들" 또는 "pdu"(앵글로-색슨계 용어로는 "프로토콜 데이터 유닛", 엔티티를 이용하여 서로 통신한다. 또한, 이 특정 "pdu"를 "SmartTP pdu"라고 부를 수 있으며, 현재는 영어로 "스마트카드"라고 사용된다. 특히 "pdu"는 위에 정의된 참조들을 사용한다.

"SmartTP pdu", 더 간략하게 말해 "pdu"는 출처 참조, 목적지 출처, "pdu"의 성격을 명시하는 깃발 또는 "플래그"를 구상하는 비트 전체, 그리고 선택적인 데이터들을 포함한다:

- "OPEN"(열림) 깃발은 세션이 열려있음을 나타낸다;

- "CLOSE"(닫힘) 깃발은 세션의 닫혀있음을 나타낸다;

- "BLOCK" (막힘) 깃발은 에이전트가 상대의 응답을 기다리고 있으며 모든 활동을 보류하고 있다는 것을 가리킨다;

우리는 데이터를 포함하지 않는 "pdu"를 표(jeton)라고 부를 것이다.

"SmartTP" 엔티티는 목적지 에이전트의 존재를 조정하며 이 후자 쪽으로 패킷을 전환시킨다.

"S-Agent" 에이전트 세션은 세가지 주목할만한 상태들을 포함한다; 즉,

- 차단된 상태; 어떠한 세션도 다른 에이전트와 개방되어 있지 않다.

- 연결된 상태; 하나의 세션이 다른 에이전트와 개방되어 있으며, "S-Agent" 세션은 한쌍의 참조로 식별된다; 그리고

- 막혀진 상태 : 에이전트가 연결되어 있으며 상대방의 응답을 기다리고 있다.

"S-Agent" 세션을 구축하는 메커니즘은 다음과 같다:

-고객 에이전트의 새로운 예(instance)가 만들어진다 (스마트카드 쪽), 이 에이전트는 가짜인 단하나의 일시적 참조로 식별된다;

- 고객 에이전트는 "OPEN" 깃발을 가진 "pdu"를 서버 에이전트 목적지에 발송하며(참조가 알려져 있다), 고객 에이전트는 "BLOCK" 깃발 값에 따라 연결되어나 막혀진 상태로 통과한다; 그리고

- 서버 에이전트는 "OPEN" 깃발을 가진 "pdu"를 받으며 연결된 상태로 통과한다.

일단 세션이 개방되면, 두개의 에이전트가 "pdu"를 통해 데이터들을 교환한다.

세션이 닫히는 메커니즘은 다음과 같다:

- 에이전트가 "CLOSE" 깃발을 가진 "pdu"를 발송한다(경우에 따라 데이터들을 포함한다); 그리고

- 다른 에이전트는 "CLOSE" 깃발을 가진 "pdu" (경우에 따라 데이터들을 포함한다)를 받아들이며, "S-Agent" 세션은 차단된 상태로 통과한다.

도 3은, 방금 상기했던 바와 같은, "S-Agent" 세션들의 상태를 도식적으로 나타낸 것이다.

130과 230a 레이어들은 단말기(1)과 스마트카드(2a) 쪽에 있는 에이전트 리스트 도표들(나타나지 않음)을 관리한다.

실제로, 에이전트들은 데이터들(예를 들면, 하이퍼텍스트)을 교환하게 할 수 있을 뿐 아니라, 스마트카드(2a)와 원격 서버(4) 간의 통신을 허용하면서, 망이 서로 교섭하게 한다. (도 2).

구성 관리 모듈, 131과 231a 각각은 특정 에이전트들에 동화될 수 있다. 예를 들면, 호스트 단말기(1) 쪽, 모듈 131은 특히 이 단말기의 구성과 관련된 정보들(기능 모드들), 다른 에이전트 리스트, 등을 관리한다. 스마트카드(2a) 쪽, 모듈 231a도 유사한 기능을 가진다. 이 두 에이전트들은 세션을 구축하기 위해 서로 통신할 수 있다.

실제로, 스마트카드(2a)는, 외부 서버 위에 표하는 것이 아니라, 단말기(1) 상의 "URL" 어드레스를 사용하여 유리하게 "어드레스"된다. 예를 들어, 이 "URL" 구조는 대개 다음과 같다:

http://127.0.0.1:8080 (1)

여기에서, 127.0.0.1은 다시 막는 것의 어드레스 "IP"이며, 8080은 포트 번호이다.

도 4는 도 2에 나타났으나 상세하게 나타나지는 않은 형태에 대해, 본 발명에 따라 시스템의 논리 구조를 단순하게 나타낸 것이다. 스마트카드(2a)는 몇몇 에이전트들을 포함하는 데, 두개만이 나타나있다; 한 에이전트 형태는 명확하게 정의되지 않은 232a1이며, 또 하나는 소위 "WEB" 형의 232a2이다. 논리 스택은, ISO 7816-3 기준에 해당하는 내부 프로토콜 레이어들, 참조 200a(도 2: CCa1과 CCa2), 명령 관리자 "APDU" 201a1, 그리고 패킷 멀티플렉서 230a를 포함하고, 이 후자는 에이전트들, 특히 "WEB" 231a2 에이전트에 연결된다.

단말기 쪽에는, 두개의 스택이 있는 데, 하나는 인터넷 네트워크와 통신하고, 다른 하나는 스마트카드 2a와 통신한다. 첫번째 스택은 망에 접근(OSI 기준 1과 2)하는 기관들 11(도 2: C1과 C2) 그리고 "TCP/IP" 프로토콜 레이어들(도 2: C3과 C4), 참조 100을 포함한다.

TCP/IP 규약 프로그램 레벨들은 네비게이터(10)와 인퍼페이스 되어 있다. 다른 또 하나의 스택은 참조번호 101에 있는 규약 프로그램 하위레벨을 포함하며, 이 레벨들은 ISO 7816-3 (도2: C1과 C2)표준인, 암호 APDU 관리 소프트웨어(102)와 패킷 멀티플렉서(130)를 포함한다. 상기 멀티플렉서는 에이전트들과 인터페이스 되어 있고 그 중 312만 표시해 놓았다. 상기 멀티플렉서를 "네트워크 타입"이라 부르기로 한다. 이것은 TCP/IP 101레벨을 통해 네비게이터(10)와 통신할 수 있을 뿐 아니라 인터넷, 같은 레벨인 TCP/IP(100), 인터넷 액세스 네트워크(11)를 통해 통신할 수 있다.

암호 APDU 관리 소프트웨어(201a)도 마찬가지로 하나 또는 여러 개의 어플리케이션 프로그램 레벨들과 인터페이스 되어 있다. 우리는 이것을 간단히 애플리케이션이라 부르기도 한다. 이 애플리케이션 프로그램(A1..An)은 앞에 언급한 바와 같이 정규의 애플리케이션 프로그램이다.

요약하면, 스마트카드(2a)에 의해 공급된 클라이언트/웹서버 기능은 스마트카드 안에 있는 웹 에이전트(232a1)와 단말기 안에 있는 네트워크 에이전트(132) 간의 결합에 의해, 또한 앞에 서술한 바와 같이 에이전트들 간의 세션의 실행에 의해서 가능해질 수 있다.

따라서, 스마트카드(2a)는 클라이언트/웹서버의 기능을 잘 보여주는 것이다. 뿐만 아니라 발명과정의 특성에 따르면 앞에 언급되었던 GCA유형인 A1...An라고 하는 정규의 애플리케이션 프로그램이라면 모두 이 클라이언트/웹서버의 중개를 통해 활성화될 수 있는데, 이는 단말기(1)에 있는 네비게이터(10)에 의해 또는 에이전트들 간의 세션의 실행에 의해 인터넷 네트워크 안에 위치된 원격 서버(4)에 의한 것이다. 발명의 관점에서 애플리케이션(A1...An)은 다시 작성될 필요가 없으며 있는 그래도 사용하면 된다.

본 발명의 범위 안에서 애플리케이션 프로그램(A1...An)의 모두 또는 일부는 "애플릿"으로 구성될 수 있다. 상기 "애플릿"은 처음부터 스마트카드의 롬 메모리 안에 프로그램을 기억시키거나 또는 이와 반대로 프로그램 로딩의 2가지 소프트웨어인 OL(제1로딩 소프트웨어)과 IL(제2로딩 소프트웨어)(이것의 성질과 메모리 저장소들에 대해서는 다음 장에 명시하겠음)을 통해 프로그램을 내부 기억장치에 기억시킨다.

발명의 또 다른 관점에서 볼 때, 스마트카드에 의해 제공된 웹서버 기능은 종래의 웹서버 안에 설치된 CGI(연결을 잇는 인터 페이스)라 불리는 기능과 유사한 메카니즘을 포함하고 있다.

스마트카드 안에서 이러한 유형의 기능을 가능케 해주는 발명의 규정에 맞는 정보체계 구성에 대한 예를 들기 전에 CGI기능의 주요 특성들을 검토한다.

CGI란 오페레이팅 시스템인 UNIX (등록상표명), DOS 또는 WINDOWS(등록상표명)을 위해 작성된 애플리케이션 프로그램들을 웹서버로부터 시행하는 것을 명시하는 것이다. 예를 들면, UNIX 오페라이팅 시스템은 CGI 1.1로 표시하고 WINDOWS 95는 CGI 1.3.으로 표시한다.

또한, 예를 들면 http://www.host.com/cgi-bin/xxx.cgi 형의 URL 주소를 위한 HTTP 명령은 (이 주소에서 "host"는 호스트 컴퓨터 시스템(일반적으로 멀리 떨어져 있음)에 의뢰하여 참조한다.) 웹서버에 의해 CGI 유형의 명령어 스크립 실행에 의해 번역된다. 이 CGI 유형은 호스트 컴퓨터 시스템의 "cgi-bin" 디렉토리 안에 있으며 xxx라고 이름이 주어진다. 디렉토리 규정에 따라 미리 주어졌다고 하더라도 이 이름은 CGI 형 스크립트를 저장하고 있는 디렉토리 명이다. 스크립트란 호스트 시스템의 최종결과가 앞서 인용한 명령을 발신하는 웹 브라우저에 전달되는 오퍼레이팅 시스템의 정보명령어들을 나열해 놓은 것이다. 이 스크립트들을 작성하기 위해 사용되는 언어가 여러 가지 있을 수 있는데 그 중 하나가 PERL언어(등록상표명)이다.

실제로 명령어는 보통 HTLM 페이지 안에 들어있는 포맷으로 컴퓨터 화면 위에 나타난다. HTML언어는 이 포맷을 URL 주소로 번역 할 수 있도록 해 준다. 포맷은 하나 또는 여러 개의 특정정보를 가진 워드의 영역들을 포함하고 있으며 이 영역들은 사용자에 의해 그것이 의무든 아니든 간에 보통 쓰는 자료입력도구(텍스트를 위한 자판, 빈칸에 클릭하기 위한 마우스, 또는 레디오 버튼들 등)의 도움으로 작성된다. 이 포맷의 내용들은("히든(hidden)"이라고 하는 정보나 지시명령이 있을 경우 이들도 포함) 웹서버로 전송된다. 페이지의 HTLM 코드는 포맷의 물리적 구조(필드, 디자인, 색깔 및 그 외 모든 다른 속성들...)와 알아야 할 정보들의 워드영역들의 구조(이름, 길이, 정보의 종류구별..등)를 기술한다.

전송은 크게 두 가지의 유형의 포맷에 의해 시행된다. 하나는 POST방식을 사용하고 또 다른 포맷은 GET방식을 사용한다. 포맷형 정보는 포맷 페이지 코드 안에 있다. 그러나 이 메카니즘은 곧바로 스마트카드로 위치가 옮겨질 수는 없다. 이 카드가 발명의 특징에 의해서 클라이언트/웹서버 기능을 제공한다고 해도 그렇다.

이하, 정보체계 구성에 대한 예를 기술한다. 상기 구성은 스마트카드 위에 웹서버를 통하여 정규의 모든 애플리케이션 프로그램을 활성화시킨다(도 5참조). 발명의 특징에 적합한 인텔리전트 에이전트들 중에서 추후 소개될 "스크립트 번역 에이전트" 또는 그 약자 "ATS"라 부를 주요 인텔리전트 에이전트들을 살펴보기로 한다. 스크립트는 에이전트들에 의해서 해석된다. 상기 해석방법은:

a/ 웹 에이전트(232a1) 자체에 의한 방법(이 경우 이 에이전트는 이중능력을 갖는다);

b/ 스마트카드(2a) 안에 있는 스크립트 전체를 해석할 수 있는 유일한 스크 립트 에이전트에 의한 방법;

c/ 다음 장에서 소개할 ATSD 라고 하는 헌납제공되는 스크립트 에이전트에 의한 방법;

d/ 암호 APDU 핸들러(201a)에 의한 방법(이 경우 이 소프트웨어는 이중능력을 갖는다)

등 다양하다.

APDU 에이전트(2010a)는 암호 APDU 핸들러(201a) 레이어의 한 구성요소이다. 이 레벨은 시스템으로부터 받은 또는 전송된 모든 APDU 암호들을 한 중앙으로 집합시키고 A1...An중에서 애플리케이션 프로그램을 선별하는 능력이 있을 뿐 아니라 인텔리전트 에이전트 유형의 인터페이스를 제공할 수 있다. 그러므로, 발명의 속성에 의하면 이 레벨은 모든 인텔리전트 에이전트들과(이 에이전트들이 영역(6)에 위치하건 스마트카드(2a)에 위치해 있건 상관없이) 통신할 수 있다.

위의 c의 경우, 에이전트들 사이의 세션은 웹 에이전트(232a)와 ATSD 에이전트들 중 하나 사이에 열려진다. 도5는 번역 에이전트들이 ATSD형으로 어떻게 정보체계를 구성하고 있는지 보여준다. 이 에이전트들은 ATS1에서 ATSn까지 표기되어 있으며 애플리케이션(A1..An)에 연결되어 있다. 선별된 애플리케이션 프로그램을 애플리케이션 A라고 가정한다면 세션은 웹 에이전트(232a1)와 에이전트(ATS1) 사이에서 형성된다.

스크립트 번역 에이전트는 여러 개로 나열된 암호 APDU들을 생성시킨다. 세션은 에이전트 ATS와 같은 번역 에이전트와 APDU 에이전트(2101a) 사이에서 열린다. 암호들은 그러므로 에이전트 APDU쪽으로 전달된다. 암호 APDU 관리 소프트웨어(210a)는 GCA 애플리케이션(A1)을 선택하고 ADPU 암호들을 전달한다. 이 암호들은 규정과 일치하여 번역된 것이며, 애플리케이션 프로그램은 이것을 이해할 수 있다. 이렇게 애플리케이션 프로그램은 변경이나 재기입할 필요 없이 올바르게 활성화된다.

애플리케이션 프로그램(A)의 응답들은 APDU 핸들러(210a), APDU 에이전트 (2010a) 및 다시 ATS 에이전트로(일반적으로 스크립트 번역 에이전트에) 전달된다. 여러 다양한 방법의 경로들이 도5에 도시되어 있는데 기능 블록들을 서로 이어주는 여러 선들이 있고 또 이 블록들 안에는 점선으로 표시되어 있다. 발명에 의한 방법이란 상기된 두 속성을 이용하는 것이다(즉, "cgi"기능을 포함하는 웹서버/클라이언트로서의 스마트카드의 작동방법). "애플릿" 프로그램 내용을 스마트카드 안에서 로딩하는 것도 상기 스마트카드가 제공한 CGI 인터페이스를 통해 실행되는 것이다.

발명 특성에 따라 더 상세히 말하자면, 스마트카드(2a) 안에 위치한 IL 스크립트로 이루어져 있다. 예를 들어 도5에 애플리케이션(A)에 연결된 스크립트를 검토한다. 이 스크립트는 발명과정 특성에 의해 OL과 IL 사이의 교류가 TCP/IP 커뮤니케이션 규약에 의해 이루어지면서 명령 HTTP에 의해 시행되고 있다. 따라서, IL과 OL은 서로 호환성이 있는 것으로 간주된다. 또한, 불리적인 근접성을 알려진 종래기술(도1 참조)에서처럼 더 이상 지킬 필요가 없어졌다. OL은 이제부터 단말기 또는 되도록 멀리 떨어져 있는(서버와 단말기 사이의 연결이 이루어지므로) 서버 안에 위치 할 수 있다. 더 나아가, 바로 스마트카드 내에 저장 될 수 있는 것이다. 앞서 인용된 HTTP명령은 OL에 의해서 받아들여진다.

여기서 웹 에이전트(232a1)에 전달된 정보들이 패킷 멀티플렉서(230a)로 구성된 어느 특정한 애플리케이션 프로그램이 목적지가 되는 APDU 암호 형식으로 전달된다는 것을 주시해야 될 것이다. 암호 APDU 핸들러(201a)는 이 애플리케이션 프로그램을 스마트카드(2a) 안에 있는 A1...An GCA형 프로그램들과 완전 유사한 방법으로 선택한다. 즉, 암호 APDU 핸들러(201a)는 230a를 보통의 GCA 애플리케이션 프로그램으로 간주한다.

명령 HTTP는 웹 에이전트(232a1)에 의해 분석되는데 이 에이전트는 어느 특정한 디렉토리(우리는 이것을 다음 장에서 cgi-smart라 부를 것이다. 이것은 cgi-bin에서 유도된 것임)를 참조하며, 어느 특정한 애플리케이션 프로그램(여기에서는 IL임)을 참조하여 검색한다. 이와 같은 경로를 한 바퀴 돌면 "cgi-smart/il"가 된다.

본 발명의 일 특징에 의하면 상기 "il"은 어느 특정한 애플리케이션 프로그램 (이 경우는 IL)에 관련되어 있는 어느 특정 스크립트를 가리킨다.

세션은 ATS1 에이전트와 같은 번역 에이전트와 APDU(2010a) 사이에 열린다. 스크립트 번역 에이전트(ATS1)는 APU암호들을 여러 개로 나열하여 생성시킨다. 암호들은 APDU 에이전트(2010a) 쪽으로 전달된다. 암호 APDU 핸들러(201a)는 GCA A1 애플리케이션 프로그램을 선택하고(예를 들면 IL), APDU 암호들은 애플리케이션 프로그램이 이해할 수 있는 규약에 의해 번역해서 전달한다. 이 애플리케이션 프로그램은 이와 같이 활성화가 된다.

IL(Ai)의 응답은 반대방향으로 암호 APDU 핸들러(201a), APDU 에이전트(2010a), 및 ATSi 에이전트(일반적으로 스크립트 번역 에이전트로 )로 전달된다.

HTLM언어로 된 포맷으로 구성된 응답은 한 쌍씩 줄을 이어서 인텔리전트 에이전트들 사이에 세션들이 실행되면서 반대 경로로 나간다. 이것은 단말기(1)에 재전송 되기 위해서이며 경우에 따라 인터넷 네트워크를 경유하여 원격 서버(4)에 재전송될 때도 있는데 이는 최종적으로 OL까지 도달하기 위해서이다.

도6은 발명과정에 의해 "애플릿"이라고 하는 프로그램 로딩 가능하게 하는 기호 정보체계 구성을 도형으로 나타낸다. 이 도면을 참조하면, 스마트카드(2a)와 스마트카드의 리더인 단말기(1)로 형성된 물리적 블록(3)들을 볼 수 있다. 이것들은 앞서 인용한 ISO 7816 표준규약에 의해, 또한 APDU 암호들간의 표준방식 교류에 의해 통신을 한다.

OL과 IL은(ILs라고 표시되어있는 스크립트 형태임) 앞서 기술된 방식으로 인터넷 TCP/IP 규약에 의거한 교류들에 의해, 그리고 HTTP(SC로 표기)와 스마트카드(2a)의 CGI 서버 기능들의 시행에 의해 서로 관련된다.

여기에서 바로 이해해야 할 것은 SC와 IL이 편의를 위해 스마트카드(2a) 외부에 표시되어 있지만 이들은 이 칩의 여러 다양한 내부 모듈로 구성되어 있다는 것이다. 이 모듈들은 참고 도5에 된다.

반면 OL은 단말기(1) 안에 반드시 저장되는 것은 아니다.

이제 우리는 GET 방식 시행에 의한 스마트카드(2a)안에 애플릿의 소프트웨어 로딩의 한 예를 상세히 설명하기로 한다.

도7의 애플릿 소프트웨어 로딩 파일이 도7에 도시된 구조들을 가지고 있다고 가정하자: 즉 그 구조란 헤더(70), JAVA 언어로 된 "바이트 코드"로 구성된 중심부분(71) 및 전자 서명(72)을 말한다. 헤더 부분은 어느 특정한 애플리케이션 프로그램을 판별한다. 이 프로그램은 일반적으로 "애플리케이션 식별자" 또는 간단하게 "AID"라고 한다. 전자 서명(72)이란 코드(71)로부터 얻어진 공동 또는 개인 키와 숫자로 된 워드를 가리킨다. 파일(7) 전체(25)도 애플리케이션 프로그램과 문제될 때는 정보기밀유지 차원에서 숫자화 될 수 있다. 선택사항으로 하나 또는 여러 가지 여기에 제시 안 된 추가 전자서명(들)을 예상할 수 있다.

프로세스(과정)의 주요단계들을 도8에 도시한다.

첫 단계에서 OL은 GET방식 명령을 하여 스마트카드 (2a)로부터 로딩용 포맷, 즉 임으로 "download.html"이라 명명하는 HTML 언어로 된 포맷을 로딩한다.

이 로딩은 URL 형식이 다음과 같은

http://127.0.0.1:8080/download.html (3)

전형적인 해당 페이지를 참조하면서 시행된다.

여기서 http://127.0.0.1:8080은 식(1)에서 정의된 바에 따라 정확히, 즉 하위 URL 주소라고 한다. 또한 download.html은 로딩될 HTML 페이지이다. 이 명령은 발명의 첫 번째 관점에 따라 도2에서 4까지를 비교해면서 설명했던 바와 같이 인텔리전트 에이전트들 사이의 세션을 시행시킨다. 이렇게 스마트카드(2a)는 웹서버의 역할을 한다.

스마트카드(2a)는 download.html 포맷을 두 번째 단계 때 보낸다. 이 때도 역시 발명단계에 따르면 한 쌍씩을 짝을 지은 에이전트들 사이의 세션의 개시를 통해서 보내진다. 얻어진 포맷은 네비게이터(10)의 중개의 의해 화면(5)위에 나타날 수 있다.

이러한 포맷(8)과 같은 경우 도9와 같이 도면으로 간단하게 표현 할 수 있을 것이다. 그래픽 디자인과 텍스트(80)(타이틀, 등)의 여러 다양한 영역들 외에도 포맷은 로딩 파일(7)의 헤더(70), "바이트 코드"(71), 서명(72)을 위한 디스플레이 영역을 포함한다. 디스플레이 영역(71)은 HTML언어로 된 텍스트 영역이라고 하는 유형에 속하며 길이가 긴 텍스트들을 실행하는 디스플레이를 하는데 "엘레베이터"라고 부르는 수월함을 가지고 있다. 도9에 보이는 해당정보들은 완전히 임의적인 것들이다. 끝으로 도9에 "전송" 버튼과 다시 원상태로 되돌리는 "리셋" 버튼을 볼 수 있다. 이 버튼들은 단말기(도시 안됨)의 사용자가 원하는 대로 사용한다. 전송 버튼(81)은 포맷을 승인하고 이것을 다시 스마트카드(2a)에 보낼 수 있도록 하며( 도8 "정보 로딩 파일을 제출한다"), 리셋 버튼(82)은 디스플레이 된 정보들을 지우고 포맷을 다시 받아들이도록 해준다.

이러한 포맷을 프로그램화하기 위해 필요한 HTML코드는 널리 알려져 있고 직장인이 손쉽게 만질 수 있는 것이다.

다시 세부적으로 언급할 필요가 없다. 그러나 이 코드에 특히 HTML언어로 다음과 같은 코드 라인이 있음은 언급해야 할 것 같다:

<form action="http://127.0.01:8080/cgi-smart/loader"> (4)

여기서, http://127.0.01:8080은 상기 식의 재차단의 URL이며 (1), cgi-smart는 앞에 언급했던 "il"이라 호칭된 정보 로딩 스크립트, IL에 결합된 스크립트를 담고 있는 앞서 언급된 CGI 디렉토리를 말한다.

포맷(8)이 화면(5)위에 시각적으로 디스플레이되지 않기를 원한다면 (예를 들어 인간 조정자가 없을 경우) 정보들은 HTML의 인수(매개변수)("TYPE=hidden")를 전술한 코드 라인 내에 포함시켜 숨길 수 있다.

세 번째 단계에서 OL은 GET형 HTTP명령을 이번에도 짝을 이룬 인텔리전트 에이전트들 사이에 세션을 개시하며 스마트카드(2a)에 보낸다. 도5와 비교하며 설명된 바와 같이 스마트카드(2a)에 의해 제공된 CGI 기능에 도움을 얻어 애플리케이션 프로그램은 실행된다. 웹서버는 명령 HTTP의 인수들을 이 애플리케이션 프로그램에 보내며 스마트카드(2a)에 의해 형성된다.

앞에 언급된 명령은 다음과 같이,

Smart/loader?AID=xxx&ByteCode=yyy&Signaturezzz (5)

전형적인 코드 라인을 포함한다.

여기서 xxx는 헤더(70)(도9에서 "2001")이며, yyy는 "바이트 코드"(71)이고, zzz는 전자 서명(71)이다(도9에서 0123456789ABCDEF). 그러므로 로딩 파일의 세 부분은 파일연결 방식형태로 HTML(8) 포맷의 특정정보를 가진 워드의 세 영역안에 포함되는 것이다.

헤더(70)에 의해 식별이 된 어느 특정한 "애플릿"의 로딩은 이 때 이루어진다.

마지막 네 번째 단계에서는 반송코드가 IL에서 OL로 전해진다. 역시 한 쌍씩 짝을 이룬 에이전트들의 세션의 시행으로써 전해진다.

일반적으로 간단한 의무이행이지만, 기능이 올바로 실행되지 않은 경우 오류코드가 나올 수 있다. 오류인 경우, 1에서 4단계까지 다시 반복된다.

대체 해결책으로서, 앞서 말한 POST방식을 이용할 수 있다. 이러한 포맷(참고번호 8)을 예시된 도10처럼 표현 할 수 있다. 여기서도 마찬가지로 텍스트와 그래픽 디자인(80)의 여러 다양한 영역들, 헤더(70)의 디스플레이 영역, 전자서명(72)의 디스플레이 영역, 및 "전송" 버튼(81)과 "리셋" 버튼(82) 들이 있다. 이것들은 도9에 있는 참고요소들과 완전히 유사한 역할을 하기 때문에 여기에 다시 설명하지 않는다. 반면, 디스플레이 영역(71)은 "바이트 코드"를 더 이상 명확하게 디스플레이하지 않고 대신 정보 로딩을 해야하는 "애플릿" 코드가 저장되어 있는 디렉토리 또는 하위 디렉토리를 명확히 보여준다. 이 경우, 이 영역은 임의적으로 "APPLET.BIN"로 불리우는 파일 위에, 단말기(1)안에 있는 하드 디스크가 될 수 있는 "C"라고 하는 저장부 저장된 파일 위에 나타난다. "브라우저"(83)이라고 하는 브라우저 보조단추는 이 디스크의 여러 (하위) 디렉토리를 버리고 어느 특정한 파일("APPLET.BIN")을 선택할 수 있도록 해 준다.

POST 방식은 GET 방식처럼 널리 알려져 있으므로 여기에서 상세한 설명은 생략한다. 본 발명에 의하면, APPLET.BIN화일에 해당하는 "애플릿"의 정보 로딩은 GET 방식과 유사하게 "C"단위에서부터 시작된다.

지금부터는 "애플릿" 정보 로딩의 두 번째 예를 스마트카드(2a)의 측면에서 기술한다.

정보 로딩시 여러 포맷들을 나열하는 것도 가능하다. 간단한 규정대신(도8과 비교해서 기술된 첫 번째 예문에서 의무이행이나 오류코드를 말함) IL이 다시 돌아오는 것은 새로운 포맷을 내포한다. 이렇게 해서 OL과 IL들 사이에서 다이내믹한 통신이 형성된다.

예를 들어, 정보 로딩 파일분석 후, IL은 추가허가를 요구할 수 있다. (즉, 전자 서명) 예를 들어 정부당국의 허가가 있다. 그러므로 이 파트는 OL에 HTML구조가 전형적으로 다음과 같은 포맷을 다시 보낸다(6).

<TITLE>Authorisation form </TITLE>

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature

</FORM>

여기서 <TITLE>과 </TITLE>이라 불리는 HTLM 표지들 사이에 인증 폼은 포맷의 (임의적) 타이틀 ,"@carte"(관계(1)의 재차단 URL주소를 문자그대로 번역한 것)를 표시한 것이며 8080은 수송번호이다. 코드라인:

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature (7)

은 여러 가지로 이름을 가질 수 있는 입력(들어가기)을 표시하는데 여기서 임의로 "서명"이라고 하였다. 텍스트 방식이며 최고 8 바이트 길이로 되었다. 그리고 </FORM>은 포맷코드의 끝을 가리키는 HTML 표지이다.

따라서, 완전한 프로세스는 의무이행이나 오류코드로 끝나는 최종 단계 이전에 추가적으로 두 단계를 더 포함하는 것이다. 즉 도11에서 볼 수 있는 것처럼 다 합쳐 여섯 단계가 필요하다.

대부분 왕복 횟수는 정보 로딩 소프트웨어의 OL과 스마트카드 사이에 교환된 포맷들 중에 나타난 매개변수에 따라 달라진다.

이 정도까지 OL의 위치가 명백하게 명시된 적은 없었다. 프로세스가 OL과 IL을 호환이 되도록 해 준 것 외에도 이 위치에 대해서 아주 큰 유연성을 가져다 주었다. 왜냐면 IL이 스마트카드 안에 있는 애플리케이션 프로그램들 중 하나의 구성요소가 되듯이 스마트카드(2a)안에 저장되기 때문이다.

발명에 의한 프로세서는 특히 OL과 IL 사이에 물리적 공간거리에 대한 요구를 할 필요 없는 추가장점을 내놓고 있다. 왜냐하면 소프트웨어의 이 두 부분들 사이의 교류가 인터넷 TCP/IP 통신규약을 시행하므로 더 이상 ISO 7816 통신의 종속하에 있지 않기 때문이다.

이리하여, OL과 함께 스마트카드(2a)에 정보 로딩해야 할 "애플릿"의 정보가 어느 특정한 위치에 정해지거나 아니면 먼 거리에 떨어진 위치에 있을 수 있다. 그러나, 상기 두 가지 경우 모두, 이 두 부분들이 바로 앞에 말한 바와 같이 TCP/IP 커뮤니케이션 규약을 시행을 시키고 "애플릿"의 정보 로딩은 스마트카드(2a)에 의해 제공된 웹과 CGI 클라이언트/서버 기능부분에서와 마찬가지로 시행된다.

지금부터는 도12a에서 12g까지 참고도를 보면서 발명의 관점에서 시행될 수 있는 주요한 정보체계 구성들에 대해서 살펴보기로 한다.

도12a는 시스템 정보체계 구성을 도면으로 제시하고 있는데 이 구성에 의하면 OL이 단말기(1)위에 가까운 위치에 저장되어 있다. 이 단말기는 인터넷 네트워크를 통하여 멀리 떨어져 있는 서버(4)에 접속되어 있다. 참고부호 Da의 스마트카드 안에 로딩을 해야하는 "애플릿"의 정보(즉, 로딩 소프트웨어)들은 이 서버(4)에 저장되어 있다. HTTP명령은 인터넷 TCP/IP 커뮤니케이션 규약의 시행에 의해서 단말기(1)를 통하여 (그리고 여기에 표시되어 있지 않지만 스마트카드 해독장치에 의해서) 이것들을 스마트카드(2a) 쪽으로 전이할 수 있도록 해 준다.

도12b에서 볼 수 있는 시스템 정보체계 구성 안에는 OL과 Da 정보가 단말기 1안에 가까이 저장되어 있다. 단말기(1)와 인터넷의 접속은 선택사항이다. 적어도 이 접속은 발명과정단계에 따르면 "애플릿"의 로딩을 위해 꼭 필요한 것이 아닌 것이다. 이 접속은 점선들로 표시되었다. 그러므로 단말기는 독립적이 될 수 있는 것이다.

도12c에 있는 시스템 정보체계 구성안에는 OL과 Da 정보가 원거리에 있는 서버(4)안에 저장되어 있다. 서버(4)와 스마트카드(2a) 사이의 인터넷, 단말기(1) 그리고 스마트카드 해독장치(도시 안됨)들을 통한 커뮤니케이션들은 HTTP명령들의 의해 그리고 TCP/IP의 시행에 의해서 이루어진다.

12D에 있는 시스템 정보체계구성은 도 12C에 있는 구성과 유사하다. 단 한가지 다른 점이 있다면 그것은 O L로딩 소프트웨어 부분이 참고표시 4a인 원거리 첫 번째 서버안에 저장되어 있다는 것과 Da 정보가 참고표시 4b, 원거리 두 번째 서버안에 저장되어 있다는 것이다.

12E 도의 정보체계 구성안에는 OL'이라고 표시되어 있는 로딩 소프트웨어 부분이 네비게이터(10) 그 자체를 구성하는 요소로 이루어져있다. "애플릿"가 브라우저안에 통합되어 있다는 점이 흥미로운 점이라 하겠다. 이 경우 사용해야 할 입력(들어가기)타입은 "file" (파일)이다.

또 장점을 들자면 스마트카드 2a상에 로딩을 해야하는 "애플릿"의 Da 정보가 외부정보 9 정보저장 매체 위에 예를들어 도 12E에 그려진 디스켓같은 매체위에 저장될 수 있다는 것이다. 물론 다음과 같은 다른 매체들도 사용된다: CD-rom, 마네티크선, 등.

앞서 언급된 POST방식을 이용한다면, 저장단위 알파벳을 명시하고(예를들어 디스켓 9를 "A"로 명시), 경우에 따라서는 찾아가는 경로(디렉토리, 하위-디렉토리) 및 로딩을 해야하는 파일명을 명시하기만 하면 된다. 찾아가는 경로를 완벽히 하면 일반적으로 다음과 같다:

A:/APPLET.BIN (8)

스마트카드 2a에 의해 제공되는 웹서버/클라이언트 기능으로 인하여, 발명과정의 특성에 따르면, 네비게이터(10)은 도 2에서 4에서 보여졌듯이 이 스마트카드와 직접 커뮤니티를 할 수 있는 능력을 갖게 된다. 커뮤니케이션들은 짝을 이룬 에이전트들의 세션의 개시로서 이루어진다.

도 12F에 도시한 시스템 정보체계구성은 도 12E의 구성에서 파생된 변형이다. 이 변형을 보면 OL이 JAVA 언어로 된 "애플릿"의 형태로 스마트카드(2a(자체속에 저장되어 있음을 알 수 있다. HTTP 명령에 의해, 이 "애플릿"은 OL로 되어있는 단말기(1) 상에서 동적으로 로딩될 수 있다.

이 로딩은 앞 단계들 시행시 네비게이터(10)에 의해 이행된 명령들의 도움으로 이루어진다. OL의 정보가 로딩되고 나면, 그 후 단계들은 그 전 단계와 같다. Da 정보는 또한 디스켓(8)과 같은 외부매체위에 저장될 수 있다.

도 12G에 있는 시스템 정보체계구성은 도 12F의 구성에서 파생된 변형이다. 유일하게 다른 점이라면 OL이 원격 서버(4)에 JAVA의 언어로 된 "애플릿"형태로 저장되어 있다는 것이다.

HTTP명령에 의해서 이 "애플릿"의 정보는 OL"로 된 단말기(1) 상에서 동적으로 로딩될 수 있다. 이 로딩은 앞 단계들 시행시 네비게이터(10)에 의해 이행된 명령들의 도움으로 이루어진다. 다른 단계들은 앞 경우와 같다.

물론 정보체계구성의 또 다른 변형들이 발명이라는 범위에서 벗어나지 않고 시행될 수 있다는 것은 명확하다. 특히 Da 정보는 다른 여러 소스들에서 출발하여 단말기안에서 읽는 것은 가능성이 높다. 소스를 예를들자면 가까운 거리 네트워크 또는 다른 모든 텔레마티크 수단들에 의해서 단말기(1)에 접속된 다른 정보 시스템 같은 것이 있겠다.

앞의 글들을 읽어보면 우리는 발명의 목적들에 도달했다는 것을 충분히 알 수 있다.

"애플릿"의 로딩이 스마트카드속에 들어있는 웹서버의 CGI 인터페이스에 의해 스마트카드안에서 시행된다는 점은 상당히 이점들이 있음을 보여준다:

HTML언어로 된 포맷을 이용함은 로딩을 표준화시키고 OL과 IL를 선험적으로 호환성이 있는 것으로 만들어준다. 실제적으로 앞에서 보여주었듯이 되돌려 보내진 포맷(들)의 특정정보를 가진 워드들의 단위들 안에서 정보 로딩 파리미터 지정을 하는 것은 바로 스마트카드안에 위치한 IL이다.

또 OL과 IL의 부분들 사이의 커뮤니케이션 메카니즘은 로딩 시행시 다이나믹 한 교류연속을 복잡하지 않게 관리하도록 해 준다.

OL과 IL 로딩 소프트웨어 부분들 사이의 교류를 위하여 인터넷 HTTP와 TCP/IP 규약들을 사용하면 이것들을 물리적으로 분리할 수 있다. 패킷 "IP"들의 방향선정만 단말기에서 필요할 뿐이다. 그러므로 로딩은 ISO 7816 커뮤니케이션 규약이 있음으로 해서 일반화 되어버린 스마트카드속에서 이루어 질 수 있다. 단말기는 인터넷에 접속된 표준(10)규격 마이크로 컴퓨터에 지나지 않을 수 있다.

발명과정측면에서 또 다른 이점들을 찾아보자면, 스마트카드안에 저장된 애플리케이션 프로그램들은 표준으로 남아있으므로 다시 기재될 필요가 없다. 스마트카드와 단말기는 발명과정을 맞추기 위해 필요한 변경만 조금 하면 된다: 즉 다시말하자면 이 애플리케이션 프로그램들은 인텔리전트 에이전트들을 포함하는 기호 레벨이라는 특수하게 불리워진 커뮤니케이션 규약 기호레벨의 이 두 단위 속에 배치되면 된다.

교대방식으로, OL은 카드라는 매체를 통하여 이 카드 또는 먼거리 HTTP서버로부터 출발하여 단말기 상에서 다이나믹하게 로딩이 될 수 있다.

간단한 인터넷 브라우저는 OL로 사용될 수 있다.

그런데 발명이 도2에서 12G까지 다른 것에 비해서 명확하게 기술된 실행성공한 예에만 한정되어서는 안 됨은 명시해놓아 할 것 같다.

HTML언어대신에 이 "인터넷" 유형 코뮤니케이션 규약에 맞는 유사한 다른 언어들도 예를들면 XML언어도 사용될 수도 있다.

또한 발명이란 특정한 규약에 의거한 커뮤니케이션을 가능하게 해 주는 스마트카드 해독장치, 단말기 그리고 정보의 전산처리 도구와 정보 저장 도구을 가지고 있는 스마트카드의 중개로서 스마트카드에 접속되어 그리고 단말기에서 출발하여 스마트카드안의 소프트웨어의 정보를 읽는 과정에 관련한다. 이 로딩은 로딩 첫 번째 두 번째 소프트웨어들의 시행과 협조에 의해 시행된다. 이 두 번째 소프트웨어가란 앞에 말한 스마트카드 정보저장 도구속에 저장되어 있는 것이며 최소한 다음 아래의 단계들의 특성이 있어야 한다:

a/ 첫 번째 준비단계는 앞에 말한 스마트카드(2a)의 정보저장 도구들속에 첫 소프트웨어(23a)을 포함시키는 것, 이 소프트웨어는 특정한 커뮤니케이션의 규약에 의해 정해진 레벨을 형성한다:

b/ 두 번째 준비단계는 앞서말한 단말기의 정보저장 도구들속에(1), 두 번째 소프트웨어(13) 포함시키는 것, 이 소프트웨어는 특정한 커뮤니케이션의 규약에 의해 정해진 레벨을 형성한다;

앞서 말한 첫 번째 두 번째 소프트웨어들 (13, 23a)은 최소한 두 개씩 짝을 이룬 첫 번째 소프트웨어단위들(132, 232a)이어야 하며 이 두 단위들은 (132, 232a)서로 협조를 해야한다. 그 목적은 스마트카드와 단말기의 정보전산처리 도구들의 도움으로 최소한 단말기(1)와 스마트카드(2a)사이의 두 방향으로 나누어진 정보들의 교류 세션을 확립하기 위함이며 또한 이 스마트카드(2a)가 클라이언트/웹서버의 기능을 제공할 수 있도록 하기 위해서이다;

세 번째 준비단계는 앞서말한 스마트카드(2a)의 정보저장 도구들안에 최소한 두 번째 소프트웨어단위 (ATS1 -ATSn)를 포함시키는 일이다. 이 소프트웨어는 나열된 지시내용들을 해독하고 열거된 암호들을 번역할 수 있는 능력이 있어야 하는데 이 목적은 앞서말한 특정한 소프트웨어(23a)의 두 번째 소프트웨어와 협조를 잘 하여 앞서말한 스마트카드가 CGI라 하는 교류점 인터페이스 잠재가능 기능성을 제공하기 위해서이다. 이 스마트카드는 최소한 앞서 말한 IL에 연합되어있는 지시사항들을 포함하고 있어야 한다:

그리고 최소한 다음 단계들을 포함한다:

1/ 단말기와 스마트카드의 정보전산처리 도구의 도움으로 단말기(1)와 스마트카드(2a) 사이의 정보교류 첫 세션 개시, 이것은 OL이 IL에 의해 제공된 파라미터 지정 정보들을 찾아서 명령을 전달하기 위함이다;

2/ 단말기와 스마트카드의 정보전산처리 도구의 도움으로 스마트카드(2a)와 단말기(1)사이에 정보교류 두 번째 세션 개시, 이것은 OL에 로딩 파라미터 지정 정보들을 전달하기 위함이다. 이 파라미터 지정정보들은 IL에 연합된 지시사항들을 참고해야 한다.

그리고

3/ 단말기와 스마트카드의 정보전산처리 도구의 도움으로 스마트카드(2a)와 단말기(1)사이에 정보교류 세 번째 세션개시, 이것은 로딩 파리미터 지정 정보를 고려한 로딩 파일(7)을 제출하기 위함이다. 이 파일은 Da에 연합된 정보들 (70, 71, 72)를 포함한다; CGI 기능의 시행에 의해 IL에 연합된 지시사항들 번역하는 것이다. 이 목적은 IL에 전달된 암호들을 생성시키며 IL을 시행하고 Da의 입력장치에 자기 테이프나 펀치카드를 빼 놓기 위해서이다.

본 발명은 스마트카드 안에 소프트웨어 콤포넌트를 로딩하는 방법에 관한 것이다.

Claims

스마트카드(2a)에 접속되어 있는 단말기로부터 출발한 스마트카드(2a) 내의 소프트웨어 컴포넌트 로딩 방법으로서, 소정의 제1프로토콜에 의거한 커뮤니케이션을 가능하게 해 주는 스마트카드 리더의 중개로 이루어지며, 상기 로딩은 제1 및 제2로딩 소프트웨어(OL, IL)의 시행과 협조에 의해 실행되고, 상기 제2로딩 소프트웨어(IL)는 상기 스마트카드(2a) 내에 저장되며, 스마트카드(2a)가 클라이언트/서버 "WEB"의 기능을 제공하고,

상기 스마트카드(2a)에 일련의 지시를 해석하고 일련의 명령을 번역할 수 있는 적어도 소프트웨어 엔티티(ATS₁ -ATS_n)를 포함하고, 상기 스마트카드(2a)는 "CGI(애플릿 로딩 인터페이스)" 기능을 제공하며, 상기 스마트카드는 적어도 상기 제2로딩 소프트웨어(IL)와 관련된 일련의 지시를 포함하고,

1/ 적어도 상기 단말기(1)와 상기 스마트카드(2a) 사이의 데이터를 교환하는 제1세션 개시단계로서, 상기 제1로딩 소프트웨어(OL)가 상기 제2로딩 소프트웨어(IL)에 의해 제공된 로딩 파라미터 데이터를 복원하기 위한 리퀘스트를 전송하기 위한 제1세션 개시단계;

2/ 적어도 상기 단말기(1)와 상기 스마트카드(2a) 사이의 데이터를 교환하는 제2세션 개시단계로서, 상기 제2세션은 상기 제1로딩 소프트웨어(OL)에서 상기 로딩 파라미터 데이터를 전송하기 위한 것이고, 상기 로딩 파라미터 데이터는 상기 제2로딩 소프트웨어(IL)와 관련된 지시의 참조를 포함하는, 제2세션 개시단계; 및

3/ 적어도 상기 단말기(1)와 상기 스마트카드(2a) 사이의 데이터를 교환하는 제3세션 개시단계로서, 상기 제3세션은 상기 로딩 파라미터 데이터를 고려한 로딩 파일(7)을 제출하기 위한 것이고, 상기 파일은 로딩해야 할 소프트웨어(Da)와 관련한 데이터(70, 71, 72)를 포함하고, 상기 제2로딩 소프트웨어(IL)를 수행하고 상기 소프트웨어(Da)의 언로딩을 얻기 위해 상기 제2로딩 소프트웨어(IL)로 전송할 일련의 명령을 생성하는 방식으로 상기 제2로딩 소프트웨어(IL)와 관련된 상기 일련의 지시를 해석하는, 제2세션 개시단계를 포함하는 방법.
제1항에 있어서, 스마트카드 리더(3)와 스마트카드(2a)는 ISO 7816에 의해 정의되는, 소정의 상기 제1프로토콜에 따른 데이터의 전달을 위한 제1 및 제2프로토콜 스택을 포함하고, 각각의 프로토콜 스택은 상기 스마트카드(2a)와 상기 단말기(1) 간의 데이터의 교환을 가능하게 하는 방식으로서의 소프트웨어 통신을 위한 하부 프로토콜 레이어(101, 200a)를 포함하고, 상기 레이어는 특정 통신 프로토콜 레이어와 인터페이스를 형성하고, 상기 특정 통신 프로토콜 레이어(13, 23a)는 데이터 전달 모듈(130, 230a))로 두개의 추가 엔티티를 각각 포함하고, 상기 제1 및 제2프로토콜 스택의 하부 레이어(101, 200a)와 관리모듈(131, 231a)과 인터페이스를 형성하고, 각 쌍의 엔티티는 상기 세션들의 적어도 하나를 실행하는 인텔리전트 에이전트(132, 232a1)로 구성되는 방법.
제2항에 있어서, 상기 제2로딩 소프트웨어(IL)와 관련하여 해석하기 위한 상기 일련의 지시는 스크립트로 구성되고, 각 쌍의 소프트웨어 엔티티는 상기 제1로딩 소프트웨어(OL)에 의해 이해되는 소프트웨어 엔티티(ATS₁-ATS_n)를 번역하기 위한 인텔리전트 에이전트로 알려진 소프트웨어 모듈로 구성되는 방법.
제3항에 있어서, 상기 1/ 단계는 인터넷 유형 프로토콜에 따라 "HTTP" 유형의 리퀘스트를 상기 파라미터 데이터를 포함하는 "HTML" 언어로 된 소정 페이지의 주소를 통해 전달하는 것을 포함하고, 상기 주소는 상기 스마트카드(2a) 상의 "URL" 유형 주소인 방법.
제4항에 있어서, 상기 2/ 단계는 "HTML" 언어로 된 서식(8, 8')을 상기 스마트카드(2a)로 보내는 것을 포함하고, 상기 서식(8, 8')은 적어도 상기 스마트카드(2a) 상의 "URL" 유형 주소를 포함하며, 소정 디렉토리를 찾아가는 경로는, 상기 제1로딩 소프트웨어(OL)가 상기 파라미터 데이터를 복원하는 방식으로 상기 제2로딩 소프트웨어(IL)의 스크립트를 보유하는 방법.
제5항에 있어서, 상기 3/ 단계는 "HTTP" 유형의 리퀘스트를 상기 "URL" 주소로 보내는 것을 포함하고, 상기 주소는 제2로딩 소프트웨어와 관련한 상기 스크립트를 포함하는 디렉토리를 지정하며, 상기 리퀘스트는 상기 로딩될 소프트웨어(Da)를 나타내는 데이터를 포함하고, 스크립트의 해석과 상기 제1로딩 소프트웨어(OL)의 실행이 상기 소프트웨어(Da)의 로딩을 가능하게 하는 방법.
제6항에 있어서, 소프트웨어(Da)는 JAVA(등록상표) 언어로 기록된 애플릿인 방법.
제7항에 있어서, 상기 로딩 파일은 상기 서식(8, 8')에 포함되며, 애플릿을 식별하는 헤더(70), 데이터(71) 및 적어도 상기 데이터의 암호화로부터 얻는 전자 서명(72)을 포함하는 방법.
제8항에 있어서, 상기 3/ 단계 이후 실행되는 추가 단계를 적어도 포함하고, 상기 추가 단계는 상기 제1로딩 소프트웨어(OL)에 의해 수신된 소정의 코드의 전송을 위해 상기 스마트카드(2a)와 적어도 상기 단말기(1) 사이에 데이터를 교환하는 제1추가 세션을 개시하는 것을 포함하는 방법.
제9항에 있어서, 상기 소정의 코드는 상기 1/, 2/ 및 3/ 단계가 정확하게 실행되면 임무가 수행되는 것이고, 그 반대일 때 코드 오류가 발생되는 방법.
제10항에 있어서, 상기 3/ 단계가 이후 실행되는 적어도 두개의 추가 단계를 포함하고, 상기 적어도 두개의 추가 단계는 추가 데이터의 제출을 요구하는 추가 서식의 전송을 위해 상기 스마트카드(2a)와 상기 단말기(1) 사이의 데이터의 쌍방향 교환 세션을 개시하는 것을 포함하는 방법.
제11항에 있어서, 상기 추가 데이터는 추가 전자 서명을 포함하는 방법.
제12항에 있어서, 인터넷 네트워크를 통해, 인터넷 통신 프로토콜의 시행에 의해 단말기는 적어도 하나의 원격 서버(4)와 접속되고, 상기 인텔리전트 에이전트(132) 중 하나는 상기 인터넷 네트워크와 통신을 가능하게 하는 "네트워크"에 연관되고, 상기 제1로딩 소프트웨어(OL)는 상기 원격 서버(4, 4a) 중 하나에 저장되는 방법.
제13항에 있어서, 상기 단말기(1)는 "WEB" 유형의 네비게이터(10)를 포함하고, 상기 제1로딩 소프트웨어(OL)는 "WEB" 네비게이터(10)의 소프트웨어 구성요소가 되는 방법.
제14항에 있어서, 상기 제1로딩 소프트웨어를 구성하는 상기 소프트웨어 구성요소는 "JAVA" 언어로 쓰여지고 상기 스마트카드(2a)에 저장된 애플릿의 동적 로딩의 초기 단계에서 획득되고, 상기 로딩은 상기 스마트카드(2a)의 "URL" 유형 주소와 함께 "HTTP" 유형의 리퀘스트의 전송을 통해 얻어지는 방법.
제14항에 있어서, 상기 제1로딩 소프트웨어를 구성하는 상기 소프트웨어 구성요소는 "JAVA" 언어로 쓰여지고 상기 원격 서버(4)에 저장된 애플릿의 동적 로딩의 초기 단계에서 획득되고, 상기 로딩은 상기 원격 서버(4)의 "URL" 유형 주소와 함께 "HTTP" 유형의 리퀘스트의 전송을 통해 얻어지는 방법.