KR20120005363A

KR20120005363A - 전자문서 유통 시스템 및 전자문서 유통 방법

Info

Publication number: KR20120005363A
Application number: KR20100131935A
Authority: KR
Inventors: 안대섭; 이중구; 공성필; 임영철; 김현철; 안혜진
Original assignee: 정보통신산업진흥원
Priority date: 2010-07-08
Filing date: 2010-12-21
Publication date: 2012-01-16
Also published as: EP2592594A2; JP2013535858A; US20130117400A1; US20130110919A1; SG187005A1; JP2013535859A; KR20120005393A; KR20120005392A; WO2012005546A2; EP2602758A4; CN103080958A; SG187006A1; CN103124981A; EP2602758B1; CN103124981B; KR20120005364A; KR101364612B1; EP2592594A4; WO2012005555A3; CN103080958B

Abstract

본 발명은 기업, 기관, 개인들이 전자문서를 신뢰성 있고, 안전하게 유통할 수 있는 전자문서 유통 시스템 및 전자문서 유통 방법에 관한 것이다. 이러한 본 발명에 따른 전자문서 유통 시스템은, 전자주소체계를 기반한 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체; 및 디렉터리 서버를 통해 등록 및 관리되는 고유식별자를 가진 전자주소체계를 이용하는 전자문서 유통허브; 를 포함한다.

Description

전자문서 유통 시스템 및 전자문서 유통 방법{ELECTRONIC DOCUMENT DISTRIBUTION SYSTEM, AND ELECTRONIC DOCUMENT DISTRIBUTION METHOD}

본 발명은 기업, 기관, 개인들이 전자문서를 신뢰성 있고, 안전하게 유통할 수 있는 전자문서 유통 시스템 및 전자문서 유통 방법에 관한 것이다.

일반적으로 전자문서 유통은 기업/기관들이 개별적인 고유 규약을 기반으로 특정 산업군 또는 커뮤니티 내에서만 한정적으로 이루어져 왔다.

또한, 일반 개인들 간, 개인과 기업/기관들 간에는 신뢰적 전자유통의 개념이 없이 이메일을 보조 수단으로 활용하거나, 개인, 개인사업자, 소기업들이 대기업 사이트에 접속하는 방법을 통해서만 온라인 소통이 가능한 단점이 있어왔다.

따라서, 일정 규모의 유통 시스템을 보유할 수 있는 기업뿐만 아니라, 일반 개인, 개인사업자, 소기업들도 유통에 대한 신뢰성을 보장받을 수 있는 전자문서 유통 기반 인프라의 구축이 기대되고 있다.

본 발명은 상기와 같은 종래의 문제점을 해결하기 위한 것으로서, 본 발명의 목적은 개인, 기업, 기관들이 전자문서 유통에 대한 신뢰성을 보장받으면서 유통을 할 수 있도록 하는 전자문서 유통 시스템 및 전자 문서 유통 방법을 제공하는 것이다.

상기와 같은 목적을 달성하기 위한 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템은, 전자주소체계를 기반한 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체; 및 디렉터리 서버를 통해 등록 및 관리되는 고유식별자를 가진 전자주소체계를 이용하는 전자문서 유통허브; 를 포함한다.

상기와 같은 목적을 달성하기 위한 본 발명의 바람직한 실시예에 따른 전자 문서 유통 방법은, 송신자 또는 수신자의 역할을 하는 송수신 개체와 전자문서 유통허브를 포함하는 전자문서 유통 시스템에서 전자문서를 유통하는 방법에 있어서, (a) 송신자는 수신자의 전자주소 정보를 획득하는 단계; (b) 송신자는 송신할 문서를 미리 정해진 메시지 구조체로 패키징한 메시지를 생성한 후에 수신자의 전자주소로 전송하는 단계; (c) 상기 (b)단계에서 전송 실패한 경우에, 송신자는 전자문서 유통허브에 메시지 전송을 의뢰하며, 메시지 전송 의뢰를 받은 전자문서 유통허브는 송신증명서를 발급하여 송신자에게 전달한 후에 메시지 전송을 대행하는 단계; (d) 수신자는 송신자 또는 전자문서 유통허브로부터 수신한 메시지를 검증하여 검증이 통과되면 수신한 메시지에서 문서를 추출하고 수신증명서를 발급하여 송신자에게 전달하는 단계; (e) 송신자는 전달받은 수신증명서를 신뢰할 수 있는 제3자 보관기관을 활용하여 보관하는 단계; 및 (f) 수신자는 추출한 문서를 문서 담당자에게 전달하는 단계; 를 포함한다.

상기와 같은 구성 및 방법을 가지는 본 발명은 개인, 기업, 기관들이 전자문서 유통에 대한 신뢰성을 보장받으면서 유통을 할 수 있는 효과가 있다.

도 1은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 구성 예를 도시한 도면.
도 2는 도 1의 유통 메시징서버 시스템이 인증을 받아 공인전자주소로서 등록을 받기 위한 절차를 도시한 도면.
도 3은 도 1의 송수신 개체가 수신자로서의 역할을 할 시에 스팸메시지를 전자문서 유통허브에 신고하는 절차를 도시한 도면.
도 4는 도 1의 송수신 개체가 수신자로서의 역할을 할 시에 송신 상대방에 대하여 수신거부를 할 것인지 여부를 실시간으로 확인하는 경우의 절차를 도시한 도면.
도 5는 도 1의 송수신 개체가 수신자로서의 역할을 할 시에 송신 상대방에 대하여 수신거부를 할 것인지 여부를 주기적으로 확인하는 경우의 절차를 도시한 도면.
도 6 내지 도 20은 본 발명의 바람직한 실시예에 따른 유통 메시징서버 시스템에 대하여 설명하기 위한 도면.
도 21 내지 도 25는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 유통 프로토콜에 대하여 설명하기 위한 도면.
도 26과 도 27은 본 발명의 바람직한 실시예에 따른 전자문서 서식 등록기에 대하여 설명하기 위한 도면.
도 28은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 전자문서 패키징에 대하여 설명하기 위한 도면.
도 29 내지 도 34는 본 발명의 바람직한 실시예에 따른 유통 클라이언트 어플리케이션에 대하여 설명하기 위한 도면.

이하, 첨부한 도면 및 표를 참조하여 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 전자문서 유통 방법에 대하여 설명하면 다음과 같다.

도 1에는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 구성 예를 도시하였다.

도 1을 참조하면 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템은, 전자주소체계를 기반한 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버 시스템을 통해 전자문서를 유통하는 송수신 개체(101); 및 디렉터리 서버를 통해 등록 및 관리되는 고유식별자를 가진 전자주소체계를 이용하는 전자문서 유통허브(102); 를 포함하여 구성된다.

상기 송수신 개체(101)의 유통 메시징서버 시스템은, 송수신 개체를 사용하는 사용자에게 상기 주소 디렉터리 서버와의 연계 인터페이스를 사용하여 공인전자주소 검색과 등록과 변경 서비스를 제공하고, 메시지 송신 시에는 전자서명을 포함하는 보안 수단을 통해 전송 메시지에 대한 보안을 수행하고, 메시지 수신 시에는 수신한 메시지에 대하여 검증을 수행하여 검증에 통과한 경우에만 수신확인 메시지를 송신자에게 전송하고 통과하지 않은 경우에는 오류 메시지를 송신자에게 전송하며, 수신한 메시지는 계정별로 사서함에 저장 및 관리하며, 메시지 송수신에 대한 이력 정보를 보관 및 관리한다.

상기 송수신 개체(101)의 유통 메시징서버 시스템에서 발급된 유통증명서를 수신한 송수신 개체는 해당 유통증명서를 공인전자문서 보관소(공전소, 103)에 보관한다. 이하에서 본 발명을 설명함에 있어서 유통증명서를 공인전자문서 보관소(103)에 보관하는 것을 그 예로 하였지만 본 발명이 이에 한정되는 것은 아니며, 상기 유통증명서는 신뢰할 수 있는 제3자 보관기관이라면 어느 곳이든 보관이 가능하다.

상기 송수신 개체(101)의 유통 메시징서버 시스템은 메시지 송신을 시도하였으나 실패한 경우에 전자문서 유통허브(102)에 메시지 전송을 의뢰하며, 메시지 전송 의뢰를 받은 전자문서 유통허브(102)는 송신증명서를 발급하여 메시지 전송을 의뢰한 송수신 개체로 전달하고 메시지 전송을 대행한다.

상기 송수신 개체(101)는 송수신 개체를 사용하는 사용자가 유통 메시징서버 시스템을 통해 메시지를 송수신할 수 있도록 하는 사용자 인터페이스인 유통 클라이언트 어플리케이션을 구비하며, 상기 유통 클라이언트 어플리케이션은 송수신 개체를 사용하는 사용자에게 사용자 인증, 메시지 작성, 메시지 목록 조회 및 상세 내용 열람을 수행할 수 있도록 한다. 이때, 상기 유통 메시징서버 시스템이 유통 클라이언트 어플리케이션에게 제공하는 인터페이스 유형은, 사용자 인증, 로그 아웃, 메시지 전송 요청, 수신 메시지 겟(Get), 메시지 상세 정보 요청, 메시지 삭제를 포함한다.

상기 전자문서 유통허브(102)는 송수신 개체를 사용하는 사용자가 전자문서 생성을 용이하게 수행할 수 있도록 하는 문서 서식의 등록, 검색, 다운로드, 삭제를 포함하는 관리를 지원하는 전자문서 서식 등록기를 추가로 구비하며, 상기 전자문서 서식 등록기는, 문서 양식을 관리하는 서버 엔진; 및 송수신 개체를 사용하는 사용자가 문서 양식을 검색하고 다운로드 받아서 사용할 수 있도록 하는 표준인터페이스; 를 포함한다.

상기 유통 클라이언트 어플리케이션을 사용하는 사용자는 상기 전자문서 서식 등록기의 표준인터페이스를 통해 문서 서식을 검색하고 다운로드 받은 후에, 해당 문서 서식을 이용하여 전자문서를 생성하는 것을 특징으로 한다.

상술한 바와 같은 구성을 가지는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 이를 이용한 전자문서 유통 방법에 대하여 도 2 내지 도 34를 참조하여 상세히 설명하면 다음과 같다. 이하에서 본 발명에 대하여 상세히 설명함에 있어서 도 1의 도면 부호는 생략하도록 한다.

[전자문서 유통 시스템의 구조 및 전자문서 유통 프로세스]

전자문서 유통은 신뢰유통을 위한 규격을 준수하는 기업/기관이 직접적으로 서로 전자문서를 주고받는 P2P 통신을 기본으로 한다. 이러한 P2P 통신을 수행하기 위한 본 발명에 따른 전자문서 유통 시스템의 기본 요소는 주소정보를 관리하고 있는 주소 디렉터리 서버와 각 송수신 개체들 간 유통을 할 수 있도록 지원하는 표준규격 기반의 유통 메시징서버 시스템이다. 이와 같은 주소 디렉터리 서버와 유통 메시징서버 시스템만 있으면 기업이나 기관이 전자문서를 유통할 수 있는 기본구조는 갖춰진 상태이며, 여기에 송/수신자 간 문서유통을 증빙하기 위해 유통증명서를 발급하고, 동시에 이를 공인전자문서보관소(공전소)에 보관함으로써 유통에 대한 법적 근거를 확보할 수 있다.

본 발명에 따른 전자문서 유통 시스템은 상기 기본 요소 외에도, 일반 사용자(기업/기관, 개인)들이 쉽게 전자문서를 유통할 수 있도록 하기 위해서는 문서 송수신 기능에 대한 사용자 인터페이스를 제공하는 유통 클라이언트 어플리케이션(APP), 문서 작성의 편의성을 향상시키기 위해 표준문서양식을 제공하는 전자문서 서식 등록기, 행정기관과 전자문서를 중계하기 위한 공공부문 연계게이트웨이 등이 추가 구성 요소로서 구비된다.

상기와 같은 전자문서 유통 시스템에서 발생하는 기본적인 프로세스는 아래의 표 1과 같다.

[전자문서 유통 시스템의 각 구성 요소]

전자문서유통 시스템을 구성하는 요소를 좀 더 체계적으로 살펴보면 다음과 같다.

전자문서유통이 이루어지기 위해서는 먼저 유통의 주체가 되는 “① 송수신 개체”가 존재하여야 하며, 각 송수신 개체는 문서를 유통하기 위해 유통 메시징서버 규격을 준수하는 “② 유통 메시징서버 시스템”을 보유하여야 한다. 또한, 전자문서유통의 기본구성요소로 각 송수신 개체 및 사용자의 공인전자주소를 등록, 관리하는 “③ 주소디렉터리 서버”가 존재하여야 한다.

이러한 기본 구성요소를 바탕으로 사용자에게 유통의 편의성을 제공하기 위해 “④ 유통 클라이언트 APP”가 제공되어야 하며, 행정/공공기관 연계를 지원하는 “⑤ 공공부문 연계 게이트웨이”와 문서의 서식을 관리하는 “⑥ 전자문서 서식 등록기”가 부가적으로 제공되어야 한다.

상기와 같은 각 구성 요소에 대하여 차례로 상세히 설명하면 다음과 같다.

① 송수신 개체

전자문서유통의 기반 인프라 구성요소 중 유통의 기준이 되는 단위가 송수신 개체인데, 송수신 개체는 유통에 참여하는 역할에 따라 송신자(Sender) 또는 수신자(Receiver)을 같이 수행하게 되며, 이 개체들은 유통 메시징서버 시스템을 통해 유통 프로토콜 규격에 따라 문서(정보)를 유통한다.

유통에 참여하는 모든 송수신 개체는 유통메시징 규격에 따라 문서를 송/수신할 수 있는 유통 메시징서버 시스템을 구축한 후, 유통 메시징서버 시스템의 물리적 주소정보를 주소디렉터리 서버에 등록함으로써 전자문서유통에 참여할 수 있는 기반을 만들게 된다. 이 때, 각 송수신 개체들은 하위에 1개 이상의 공인전자주소를 갖는 실 유통 사용자를 갖게 된다.

전자문서유통에서 송수신 개체로서 인정받을 수 있는 개체는 메시징서버 규격을 준수한 시스템을 구축한 후, 정보통신산업진흥원에 의해 표준적합성과 상호운용성을 인증받은 개체로 한정되며, 유통을 증명하기 위해서는 ① 인증 받은 송수신 개체를 통해 전자문서가 유통된 후, ② 표준규격에 맞게 유통증명서를 발급하여 공인전자문서보관소에 보관하여야 한다.

이때, 송수신 개체는 전자문서에 대한 법적 소유자 및 책임자로서 직접 전자문서 전송을 책임지는 개체와, 유통되는 전자문서의 실 소유자이며 책임자인 사용자를 위해 전자문서를 대행해 주는 개체로 구분된다. 전자문서의 소유자가 직접 전자문서를 전송하는 송수신 개체인 경우에는 유통 메시징서버 시스템의 표준적합성과 상호운용성을 인증받고, 유통증명서를 안전하게 공인전자문서보관소에 보관하는 것만으로도 송수신 개체에 참여할 수 있다.

그러나 전자문서 소유자(사용자)를 대행해서 3자 전송을 책임져야 하는 송수신 개체인 경우에는 송수신 개체가 안전하고 신뢰성 있는 방법으로 전송메시지를 관리하고, 사용자 정보를 관리하고 인증하는지에 대한 부분까지 입증하여야 한다. 3자 유통의 안전성 및 신뢰성을 보장하기 위해 한시적으로 이러한 3자 유통이 가능한 송수신 개체로는 공인전자문서보관소 사업자만으로 한정한다.

② 유통 메시징서버 시스템

유통 메시징서버 시스템은 유통 메시징서버 규격을 바탕으로 전자문서(정보)를 유통하기 위해 메시지 송/수신기능과 주소 디렉터리 서버와 연계하여 수신자에 대한 주소정보 및 보안 관련한 정보를 검색하는 기능을 반드시 구축하여야 한다. 유통 메시징서버 시스템은 물리적으로 하나의 전자주소(IP Address)를 가지나 하위의 사용자를 위해 복수의 사용자 계정을 발급하고 관리할 수 있으며, 사용자 계정은 각각 하나의 공인전자주소를 갖게 된다.

유통 메시징서버 시스템은 각 사용자 계정을 관리하기 위해 사용자 계정별 전자문서 사서함을 관리하여야 하며, 유통 메시징서버 시스템은 이 사용자 계정을 대표하여 안전하고 신뢰성 있는 전자문서유통 책임을 갖게 된다.

이와 같은 유통 메시징서버 시스템이 전자문서유통 내에 송수신 개체로서 참여하기 위해서는 본 발명에 따른 요건에 적합하게 구현이 되어 있는지, 타 솔루션과 상호 운용에는 문제가 없는지를 인증 받는 과정을 거쳐야 한다.

유통 메시징서버 시스템에 대한 표준 적합성 및 상호 운용성을 인증해 주는 인증 시스템은 인증된 송수신 개체를 관리하여야 하며, 주소 디렉터리 서버가 공인전자주소를 등록하는 과정에 인증 통과 여부 확인을 요청하면 그 결과를 돌려주어야 한다.

유통 메시징서버 시스템이 인증을 받아 공인전자주소로서 등록을 하기 위해서는 도 2 및 아래와 같은 절차를 따라야 한다.

먼저, 송수신 개체가 되고자 하는 기업/기관 또는 개인사용자는 본 기술규격에 적합하게 유통 메시징서버 시스템을 구축한다.

다음으로, 인증 테스트 베드가 제공하는 자동화된 검증도구를 통해 구축된 유통 메시징서버 시스템의 표준적합성 및 상호운용성을 검증한다.

다음으로, 자체 검증을 모두 완료한 송수신 개체는 인증테스트베드에 인증시험을 요청한다.

다음으로, 인증 테스트 베드의 테스트 절차에 따라 시스템에 대한 인증을 마친 후 결과가 “통과”로 나오면 송수신 개체는 공인전자주소 등록을 위한 다음 절차를 준비한다.

다음으로, 인증 테스트 베드는 인증심사를 통과한 송수신 개체에 대한 정보를 주소 디렉터리 서버에 전달하고, 주소 디렉터리 서버는 이 정보를 주소 등록의 조건으로 활용한다.

다음으로, 송수신 개체는 인증 통과된 유통 메시징서버 시스템을 등록하기 위해 주소 디렉터리 서버에 고유의 ID 발급을 신청한다.

다음으로, 유통 메시징서버 시스템이 주소디렉터리 서버에 등록이 완료되면, 유통 메시징서버 시스템은 전자문서유통에 참여할 수 있게 된다.

다음으로, 유통 메시징서버 시스템의 인증이 완료되면 사용자 계정을 개설하고 대표 공인전자주소인 경우에 사용자 계정은 공인전자주소에 등록요청을 한다.

③ 주소디렉터리 서버

신뢰할 수 있는 전자문서유통에 참여하기 위해서 모든 사용자는 고유의 전자주소를 발급받아야 한다.

④ 유통 클라이언트 APP

유통 클라이언트 APP는 문서유통에 참여하는 사용자들을 위해 문서 송신 및 수신, 수신문서 열람 및 관리 등의 UI를 제공하는 어플리케이션을 지칭한다. 유통 클라이언트 APP는 독자적으로 문서를 송수신할 수 없으며 반드시 유통 메시징서버 시스템과 연계되어야 한다.

유통 클라이언트 APP에서 작성되거나 첨부된 문서는 유통 메시징서버 시스템에 전달되어 전송을 요청하게 되며, 유통 메시징서버 시스템을 통해 수신된 문서를 조회하게 된다. 유통 메시징서버 시스템이 사용자 계정을 통해 송수신 사서함을 관리하는 경우라면 유통 클라이언트 APP는 수신문서 중 사용자 계정정보 확인을 통해 해당 문서에만 접근이 가능하다.

유통 클라이언트 APP는 사용자의 요구에 의해 C/S 형태의 어플리케이션으로 구현될 수도, 웹 형태의 화면으로 구현될 수도 있다.

⑤ 공공부문 연계 게이트웨이

전자문서유통을 수용하기 어려운 행정 및 공공기관의 경우 공공부문 연계 게이트웨이를 통해 행정, 공공기관과 전자문서유통 체계 하의 민간기업, 기관, 개인들 간 문서를 중계하는 역할을 수행한다.

⑥ 전자문서 서식 등록기

전자문서 서식 등록기는 유통 메시징서버 시스템을 이용해서 전자문서를 전송하고자 하는 사용자들이 Office 도구를 이용해서 직접 전송문서를 작성할 수도 있으나, 사용자가 좀 더 쉽게 전자문서 생성할 수 있도록 지원하기 위해 표준문서 양식을 등록하고 관리하면서 유통 클라이언트 APP와 같은 사용자용 어플리케이션이 이용할 수 있도록 문서 양식 등록 및 관리, 문서 양식 검색, 열람 및 다운로드, 문서 양식 삭제 등의 관리를 지원하는 시스템이다.

전자문서 서식 등록기는 문서표준양식을 관리하는 서버 엔진과 클라이언트 어플리케이션(APP)이 이를 검색하고, 다운로드 받은 후에 내부 프로그램에 플러그인(Plug-In)하여 사용할 수 있도록 하는 표준인터페이스를 제공한다.

[전자문서 유통 방법]

전자문서유통에서 전자문서를 유통하기 위한 전체 프로세스는 “① 유통 전 사전 준비단계”, “② 전자문서 유통 단계”, “③ 유통을 위한 증빙 단계”의 3단계로 크게 구분해서 볼 수 있다. 이하에서는 상기 세 단계에 대한 상세한 설명과 함께, "문서 송/수신 방안"과 "유통증명 방안"과 "스팸 메시지 처리 방안"에 대하여 상세히 설명하도록 한다.

① 유통 전 사전 준비단계

- 전자문서 서식 등록기 관리자는 전자문서 시식 등록기를 이용해서 사용할 표준문서 서식을 등록한다.

- 송수신 참여자는 자체적으로 신뢰유통을 위한 유통 메시징서버 시스템을 구축할 지, 기 구축된 유통 메시징서버 시스템에 사용자 계정을 개설하고 사용할 지 여부를 결정한다. 자체적으로 신뢰유통을 위한 유통 메시징서버 시스템을 구축하는 경우에는, 전자문서 송수신을 위한 유통 메시징서버 시스템을 구축한 후에, 인증기관을 통해 유통 메시징서버 시스템의 표준적합성, 상호운용성에 대한 인증테스트를 수행한 후에, 주소 디렉터리 서버에 접속한 후 인증된 유통 메시징서버 시스템을 위한 송수신 개체 ID를 신청하고 발급받은 후에, 내부의 실 사용자를 위해 자체적으로 내부 구분자를 등록하고 관리하며, 표준문서 서식 기반의 문서 작성 기능을 이용하기 위해 일반사용자를 위한 클라이언트 어플리케이션에 표준문서 서식 작성기능을 플러그인(Plug-In)한다(선택적 사항). 반대로, 3자 유통이 가능한 유통 메시징서버 시스템을 보유한 송수신 개체를 이용하는 경우에는, 유통 메시징서버 시스템을 통해 기업/기관/개인을 위한 사용자 계정 개설을 요청한 후에, 사용자 계정에 대한 공인전자주소 정보를 주소 디렉터리 서버에 등록한 후에, 표준문서 서식 기반의 문서 작성기능을 이용하기 위해 일반사용자를 위한 클라이언트 어플리케이션에 표준문서양식 작성기능을 플러그인(Plug-In)한다(선택적 사항).

② 전자문서 유통 단계

○ 문서 송신자

- 문서 송신자는 유통할 문서를 선택하거나 문서작성기를 통해 전송할 문서를 작성한다.

- 문서 수신 상대방 주소정보 및 전달 문서, 문서 암호화여부 및 전자서명 여부를 선택한다. (암호화 및 전자 서명은 전송 메시지가 아닌 첨부하는 전달 문서를 대상으로 하며, 이 절차는 선택적 사항임)

- 유통 클라이언트 APP는 주소 디렉터리 서버에 연계하여 수신 상대방의 공인 전자주소를 기반으로 물리적 주소정보 및 암호화를 위한 공개키 정보를 획득한다. (선택적 사항으로, 유통 클라이언트 APP가 물리주소 획득을 하지 않은 경우 유통 메시징서버가 이 작업을 수행함)

- 유통 클라이언트 APP는 유통 메시징서버에 수신자의 주소정보를 기반으로 전송요청을 한다. (물리적 주소정보 또는 공인 전자주소 모두 가능)

○ 송신자의 유통 메시징 서버

- 유통 클라이언트 APP에서 요청한 전송요청 메시지가 수신자에 대한 물리적 주소정보가 아닌 경우, 유통 메시징서버는 공인전자주소를 기반으로 수신자의 송수신 개체에 대한 물리적 주소정보를 주소 디렉터리 서버에 질의한다.

- 전자문서를 유통 프로토콜 규격에서 정의한 메시지 구조체로 패키징한다.

- 송신자 유통 메시징서버의 공인인증서 기반으로 메시지에 전자서명을 한다.

- 수신자의 물리적 주소정보로 메시지를 전송한다.

○ 수신자의 유통 메시징 서버

- 메시지 수신 후, 수신메시지 검증하고 메시지에서 문서를 추출한다.

- 동기식 응답으로 수신증명서를 포함한 메시지를 송신자에게 전송한다.

③ 유통을 위한 증빙 단계

- 수신자는 문서 수신사실 확인을 위한 문서 수신시점에 “수신증명서”를 생성한 후 송신자에게 전달하여야 하며, 이를 수신한 문서 송신자는 “수신증명서”를 공인 전자문서 보관소(공전소)에 보관한다.

- 송신자가 요구할 경우, 수신자는 수신문서를 실 문서 담당자(사용자)에게 전달한 후, 담당자가 수신문서를 확인한 시점에 “열람증명서”를 생성하여 송신자에게 전달하며, "열람증명서"를 수신한 문서 송신자는 “열람증명서”를 공인전자문서보관소에 보관한다.(열람증명서의 발급은 송신자의 요청이 있을 경우에만 적용됨)

- 송신자가 수신자에게 문서전달을 시도하였으나 실패한 경우에는 송신 시도에 대해 증빙을 하고자 객관적 3자인 전자문서 유통허브에 문서 전송을 의뢰하며, 전송의뢰를 받은 전자문서 유통허브는 전송의뢰를 받았음을 입증하고자 “송신증명서”를 발급하여 송신의뢰자에게 전달하고 이를 수신한 송신의뢰자는 “송신증명서”를 공인 전자문서 보관소(공전소)에 보관한다.

○ 문서 송/수신 방안

유통 메시징서버 시스템을 통해 송신자와 수신자는 문서를 전자적으로 유통합니다. 유통 메시징서버 시스템은 유통 프로토콜에 따라 전자문서를 송수신하며, 신뢰메시지 유통을 위해서 모든 메시지는 전송과 수신확인(또는 수신증명서) 메시지의 조합으로 이루어지며, 수신자에 대한 물리적 주소정보는 주소 디렉터리 서버를 통해 획득하게 된다.

○ 유통증명 방안

"유통증명"이라 함은 전자문서 유통과 관련된 송신, 수신, 열람에 대하여 해당 사실을 신뢰성 있는 방법으로 증명하는 것을 말하는 것으로, 이때 전자문서 유통과 관련된 행위에 대하여 발급하는 증명서를 통칭하여 "유통증명서"라고 한다.

유통 메시징서버 시스템은 송신, 수신에 대한 행위 입증을 위해 송신 및 수신 시점에 유통증명서를 발급하고, 발급한 유통증명서를 공인 전자문서 보관소(공전소)에 보관함으로써 유통 행위에 대한 증빙 자료로서 활용할 수 있도록 한다.

유통 메시징서버 시스템은 전자문서 송신, 수신, 열람에 대한 사실을 증명하며 각 사실에 대한 유통증명서를 생성하며, 유통증명서는 유통증명서 식별정보, 유통증명서 생성시각 및 만료시각, 유통증명서 정책 및 유통증명 대상을 포함한다.

전자문서 송신에 대한 유통증명서는 전자문서 유통허브가 생성하며 유통증명 대상에 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 전자문서 송신의뢰 시각을 포함한다.

전자문서 수신에 대한 유통증명서는 전자문서를 수신한 수신자가 생성하며 유통증명 대상에 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 전자문서 송신 시각, 전자문서 수신 시각을 포함한다.

전자문서 열람에 대한 유통증명서는 전자문서를 수신 확인한 사용자가 생성하며 유통증명 대상에 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 전자문서 송신 시각, 전자문서 수신 시각, 전자문서 수신확인 시각를 포함하여야 한다.

이와 같이 생성된 유통증명서는 NPKI 또는 GPKI 인증서로 전자서명 되어야 하고, 생성된 유통증명서는 전자문서 송신자에게 전달되어야 하며, 모든 유통증명서는 공인전자문서보관소에 보관되는 것이 바람직하다.

○ 스팸 메시지 처리 방안

전자문서유통은 기본적으로 송신자가 인증된 유통 메시징서버 시스템을 통해 전송을 하고, 수신자 역시 이를 기본으로 수신하므로 스팸을 발송하였을 때 전송자에게 책임을 물을 수 있는 기반구조를 가진다. 그러나, 스팸 발송자가 유통 메시징서버 시스템에 사용자 계정을 개설하고 이를 이용해서 전송을 하는 경우가 있을 수 있다. 또한, 현재의 인증방식이 시스템의 기술적 내용에 대한 인증만을 대상으로 하고 있어서, 스팸발송자가 유통 메시징서버 시스템을 구축하고 이를 기술적으로 인증한 후 스팸 발송수단으로 사용하였을 때, 초기에 원천적으로 봉쇄하기가 쉽지 않은 상황이다.

따라서, 이와 같은 문제점을 해결하기 위해 본 발명에 따른 표준문서 유통 인프라에서는 인증목록 관리 기반의 화이트리스트, 사용자 신고방식에 의한 스팸대상 목록 관리 기반의 블랙리스트를 체계를 제공하며, 이러한 체계에 의해 수신자가 수신거부를 할 수 있는 프로세스를 적용하여 스팸메시지를 방지할 수 있도록 한다.

스팸메시지 신고 및 송신 상대방에 대한 확인을 위한 기능은 필수 기능으로 모든 유통 메시징서버는 이 기능을 반드시 구축하여야 한다.

수신자는 수신한 메시지가 스팸 메시지라고 판단이 되면, 도 3에 도시한 바와 같은 프로세스에 의해 스팸메시지를 전자문서 유통허브의 주소 디렉터리 서버에 신고하며, 이와 관련한 처리 절차는 다음과 같다.

먼저, 수신자가 메시지를 수신한 시점에서 스팸메시지라고 판단되면, 수신자는 유통 메시징서버 시스템을 통해 주소 디렉터리 서버에 해당 메시지를 수신 메시지로 신고한다.

다음으로, 유통 메시징서버 시스템으로부터 스팸메시지 신고를 접수한 주소 디렉터리 서버는 접수되었음에 대한 확인메시지를 되돌려준다.

다음으로, 주소 디렉터리 서버를 관리하는 주체인 정보통신산업진흥원은 해당 메시지를 분석하고, 송신자에 대한 조사를 통해 송신자의 공인전자주소에 대해 블랙리스트 추가 여부를 심사하고 판단한다.

다음으로, 최종적으로 블랙리스트 대상자로 확정이 되면, 주소 디렉터리 서버는 해당 공인전자주소를 블랙리스트에 추가한 후, 송신자에게 블랙리스트 추가에 대한 내용을 통지한다.

다음으로, 주소 디렉터리 서버는 스팸메시지 요청에 대한 처리 결과를 스팸신고자(수신자)에게 전달한다.

상기와 같은 처리 절차에 있어서 화이트리스트는 송신 유통 메시징서버 시스템이 인증을 받고 정식으로 등록된 메시징서버 시스템에 대한 정보만 기록되고, 블랙리스트는 전송자의 주소가 스팸발송자로 등록된 경우에 등록되며, 동일한 유통 메시징서버 시스템을 통해 블랙리스트에 등록되는 스팸 주소가 중복 발생되는 경우에는 전자문서 유통허브에서 해당 유통 메시징서버 시스템에 대한 인증취소 여부를 판단한 후, 인증을 취소하고 화이트리스트에서 삭제할 수 있다.

수신자는 메시지 수신 시, 송신 상대방이 신뢰할만한 정당한 사용자인지 여부를 확인하기 위해 주소디렉터리 서버의 화이트리스트와 블랙리스트를 확인한 후, 수신거부를 할지의 여부를 결정한다. 송신자에 대한 확인은 수신시점에 실시간 확인을 하거나, 수신자의 유통 메시징서버 시스템에 Cache 형태로 관리하고 있는 목록을 통해 확인하는 주기적 확인 방법이 있다.

실시간으로 송신자에 대한 확인을 수행하는 프로세스는, 도 4에 도시한 바와 같이 수신자가 메시지를 수신하는 시점에 주소 디렉터리 서버에 송신자의 주소가 화이트리스트, 블랙리스트에 등록되었는지의 여부를 판단한 후에 메시지에 대한 수신거부 여부를 결정하며, 이와 같이 실시간으로 송신자에 대한 확인을 수행하는 프로세스의 상세한 처리절차는 다음과 같다.

먼저, 수신자의 유통 메시징서버 시스템은 메시지를 수신하면 주소 디렉터리 서버에 정당한 사용자인지 여부를 확인하기 위해 확인요청 메시지를 전달한다.

다음으로, 주소 디렉터리 서버는 요청받은 사용자의 주소정보가 화이트리스트에 포함되어 있는지 여부를 확인한다.

다음으로, 해당 주소가 화이트리스트에 없으면 주소 디렉터리 서버는 바로 확인 요청자에게 등록되지 않은 사용자임을 결과메시지로 돌려주고, 화이트리스트에 있으면 다시 해당주소가 블랙리스트에 등록된 주소인지 여부를 확인한다.

다음으로, 주소 디렉터리 서버는 확인 요청자에게 블랙리스트 등록 여부에 대한 결과 메시지를 돌려준다.

다음으로, 수신자는 주소 디렉터리 서버로부터 송신자가 정당한 사용자가 아니라는(화이트리스트에 없거나 블랙리스트에 등록된 경우) 결과메시지를 받은 경우에는 수신메시지를 자체적으로 스팸메시지로 처리한 후, 주소디렉터리 서버로부터 받은 처리결과 메시지와 스팸메시지 수신이력을 기록하고 보관한다.

다음으로, 스팸메시지에 대한 처리 이력은 반드시 한 달 이상 보관함으로써, 해당 송신자에 대한 수신거부의 정당성을 확인할 수 있도록 한다.

그리고, 주기적으로 송신자에 대한 확인을 수행하는 프로세스는 도 5에 도시한 바와 같이 수신자는 사전에 주소 디렉터리 서버로부터 화이트리스트와 블랙리스트를 받아서 자체적으로 관리하고 이를 기반으로 송신자의 주소가 화이트리스트, 블랙리스트에 등록되었는지 여부를 판단한 후 메시지에 대한 수신거부 여부를 결정하며, 이와 같이 주기적으로 송신자에 대한 확인을 수행하는 프로세스의 상세한 처리절차는 다음과 같다.

먼저, 수신자의 유통 메시징서버 시스템은 미리 주소 디렉터리 서버로부터 최신의 화이트리스트와 블랙리스트를 요청한 후 자체적으로 관리한다. 이때, 리스트의 변동사항 발생 시 자동 통지 요청 여부를 같이 전달한다. 이와 같은 변동사항 발생 자동통지를 요청한 경우에도 주소 디렉터리 서버에 최신 리스트를 가져오기 위한 요청은 주기적으로 함으로써 리스트 정보가 최대한 1일 이상 차이가 나지 않도록 한다.

다음으로, 주소 디렉터리 서버는 화이트리스트 및 블랙리스트에 변동사항이 발생하면 변동 통지요청을 한 사용자에게 변동내역을 브로드캐스팅(broadcasting)한다.

다음으로, 리스트에 대한 변동사항을 받은 사용자 유통 메시징서버 시스템은 자체 관리하는 리스트의 정보를 수정함으로써 동기화를 시켜준다.

다음으로, 수신자는 메시지를 수신하면 주소 디렉터리 서버에 정당한 사용자인지 여부를 확인하기 위해 자체 관리하는 리스트를 확인한다.

다음으로, 수신자는 자체 관리하는 리스트 점검결과 송신자가 정당한 사용자가 아니라고(화이트리스트에 없거나 블랙리스트에 등록된 경우) 판단한 경우에는 수신메시지를 자체적으로 스팸메시지로 처리한 후, 스팸메시지 수신 이력을 기록하고 보관한다.

[유통 메시징서버 시스템]

이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 유통 메시징서버 시스템과 관련하여 상세히 설명하도록 한다.

유통 메시징서버 시스템은 크게 메시지 송신, 메시지 수신, 수신 메시지에 대한 사서함 관리, 메시지 보안(사용자 인증, 문서 암/복호화 등), 송수신 이력관리, 주소디렉터리 서버 연계, 메시지 검증, 내부시스템 연계인터페이스, 유통증명서 발급 및 관리, 공인전자문서보관소 연계 등으로 구성된다.

도 6에는 유통 메시징서버 시스템의 구조를 도시하였으며, 이와 같은 도 6을 참조하여 유통 메시징서버 시스템의 구성 요소 각각(①~⑨)에 대하여 상세히 설명하면 다음과 같다.

① 메시지 송/수신

- 유통 프로토콜에 따라 메시지를 송신하고 수신한다.

② 사용자 별 계정(사서함) 관리

- 송/수신한 메시지를 사용자 계정 또는 내부구분자에 따라 계정별 사서함에 보관한다.

- 사서함에 보관한 송신문서에 대하여 "송신 중", "송신 완료", "송신 실패", "담당자 수신 완료"를 포함하는 4단계의 상태정보를 관리한다. 이때, "중신 중" 상태는 문서 전송 후 수신자로부터 아무런 응답을 받지 못한 상태이며, "송신 완료" 상태는 수신자의 유통 메시징서버 시스템으로부터 "수신증명서"를 받은 상태이고, "송신 실패" 상태는 수신 유통 메시징서버 시스템 내부에서 오류가 발생하여 SOAP Fault 메시지를 리턴하거나, 송수신 과정에서 네트워크 오류가 발생한 경우이며, "담당자 수신 완료" 상태는 송신 유통 메시징서버 시스템이 수신자로부터 담당자의 문서를 확인했음을 증명하는 "열람증명서"를 받은 경우이다.

- 사용자 계정별 사서함에 보관된 수신문서에 대하여 "검증오류", "수신 확인 전", "수신 확인", "열람 확인"을 포함하는 4단계의 상태정보를 관리한다. 이때, "검증오류" 상태는 수신한 메시지에 대한 기본구조 검증에서 오류 발생한 상태이며, "수신 확인 전" 상태는 수신문서 담당자가 사서함의 수신 문서 목록을 읽기 전이고, "수신 확인" 상태는 수신문서 담당자가 사서함의 수신 문서 목록을 읽은 상태이며, "열람 확인" 상태는 수신문서 담당자가 수신문서에 대한 상세내용을 열람한 상태로서 이 시점에 수신자의 유통 메시징서버 시스템은 "열람증명서"를 발급한 후에 송신자에게 전달한다.

- 수신사용자에 의해 삭제 요청이 오면 해당 수신문서를 물리적으로 삭제 처리한다.

- 사서함에서 송신문서, 송신에 대한 수신확인 메시지, 수신담당자의 수신확인 메시지는 서로 연관될 수 있도록 연관정보를 가진다.

③ 주소 디렉터리 서버 연계

- 주소 디렉터리 서버가 제공하는 주소정보 등록 및 검색 프로세스에 따라 주소정보를 관리한다.

- 주소 디렉터리 서버가 제공하는 서비스를 호출할 수 있는 클라이언트 기능을 포함한다. 즉, 주소 디렉터리 서버가 제공하는 주소정보 등록, 검색, 수정, 삭제 기능을 원격에서 호출하는 서비스 클라이언트 기능을 제공한다.

④ 메시지 보안(사용자 인증, 문서 암/복호화 등)

- 유통 프로토콜에서 제시하는 메시지 보안 기능(메시지 전자서명, 서명 검증)을 기본적으로 수행한다.

⑤ 송수신 이력 관리

- 유통 메시징서버 시스템은 송수신 이력에 대해 최소 1년 이상은 반드시 보관/관리한다.

- 보관하는 송수신 이력에 대한 정보는 송신 이력과 수신 이력이며, 송신 이력은 메시지 id, 연관메시지 id, 송신자(사용자 계정 포함), 수신자, 송신시간, 송신 문서에 대한 해시 값을 포함하며, 수신이력은 송신자, 수신자(사용자 계정 포함), 수신시간, 수신 문서에 대한 해시 값을 포함한다.

⑥ 유통증명서 발급 및 관리

- 유통 메시징서버 시스템은 문서 송/수신 사실에 대한 내용을 증빙할 수 있도록 유통증명서를 발급하고 관리한다.

- 발급된 유통증명서는 전달받자마자 공인전자문서보관소에 보관 의뢰함으로써 그 신뢰성을 보장받는다.

- 발급된 후 공인전자문서보관소에 보관된 유통증명서 이력을 관리하며, 유통증명서 발급 이력은 유통증명서 id, 유통증명서 발급 시각, 관련 메시지 id, 유통증명서 원본(선택적), 공인전자문서보관소 보관 후 수신한 보관-key정보를 포함한다.

⑦ 메시지 패키지 처리 (Packaging, Parsing, Extracting)

- 송신 문서를 전송 전에 유통 프로토콜에 정의된 메시지구조로 패키징(Packaging) 한다.

- 수신한 문서를 유통 프로토콜에 정의된 메시지구조에 의해 파싱(Parsing)하고 필요한 정보를 추출(Extracting)한다.

⑧ 유통증명서 보관요청

- 일반 송수신 개체가 유통증명서의 보관요청을 위해서는 공인전자문서보관소의 유통 메시징서버 시스템에 공인전자문서보관소 보관요청메시지를 전송한다.(원격 보관요청)

- 공인전자문서보관소의 유통 메시징서버 시스템은 공인전자문서보관소 보관요청 메시지를 수신하면, 공인전자문서보관소에 유통증명서 보관을 위한 보관요청 Client를 호출한다.

- 공인전자문서보관소의 유통 메시징서버 시스템이 직접 유통증명서를 생성한 경우에는 생성시점에 공인전자문서보관소 보관요청 Client를 직접 호출한다.(로컬 보관요청)

- 유통증명서 보관요청을 위한 Client는 공인전자문서보관소의 송수신 연계인터페이스 규격에 따라 공인전자문서보관소에 보관을 요청한다.

⑨ 부가 서비스

- 유통 클라이언트 APP 관리의 배포, 버전 관리 등을 수행한다.

- 메시지 유통관리(이력, 통계정보 등)를 수행한다.

- 시스템 관리(시스템 모니터링, 환경정보 등)를 수행한다.

- 문서양식(Form) 관리를 수행한다.

상기와 같은 ①~⑨의 구성 요소를 가지는 본 발명에 따른 유통 메시징서버 시스템을 도 7과 같이 공인전자문서보관소에 적용한 경우에는, 유통증명서를 보관할 시에 유통증명서 보관요청 모듈은 공인전자문서보관소 연계인터페이스 규격에 따라 개발된 연계인터페이스 클라이언트를 호출하여 보관 요청을 한다.

상기와 같은 ①~⑨의 구성 요소를 가지는 본 발명에 따른 유통 메시징서버 시스템을 도 8과 같이 일반 송수신 개체(일반 사업자)에 적용한 경우에는, 유통증명서를 보관할 시에 공인전자문서보관소 사업자의 유통 메시징서버 시스템에 유통증명서 보관을 요청하는 메시지를 전송하고 처리 결과를 받아오는 방식으로 처리한다.

상기와 같은 ①~⑨의 구성 요소를 가지는 본 발명에 따른 유통 메시징서버 시스템을 이용하여 송신자와 수신자 간에 직접 메시지를 유통하는 프로세스는, "①수신자에 대한 물리적 주소 및 보안정보 획득", "② 메시지 전송 및 전송확인", "③ 업무수신자의 수신확인", "④ 유통증명서 발급 및 보관"을 포함하는 4단계로 이루어지는데, 이와 같은 4단계와 관련하여 도 9를 참조하여 상세히 설명하면 다음과 같다.

① 수신자에 대한 물리적 주소 및 보안정보 획득

- 송신자의 시스템은 상대방에 대한 주소 정보를 바탕으로 실제 메시지가 전달되어야 할 물리적 주소 정보 및 보안정보(송신메시지에 대한 수신암호를 필요로 하는 경우)를 주소 디렉터리 서버에 요청함으로써 이를 획득한다.

- 수신자에 대한 물리적 주소 및 보안 정보는 유통 클라이언트 APP가 주소 디렉터리 서버에 요청한 후에 수신자의 물리적 주소 정보를 유통 메시징 서버에 전달하도록 한다.

- 사용자에 대한 id(예: 주민등록번호, 사업자 등록번호 등)만으로 수신자에 대한 주소정보를 획득할 수도 있으나, 이 경우에는 수신자가 송신자에게 id 기반의 주소정보 검색을 허용한 경우에만 가능하다.

* 송신자가 수신자의 물리적 주소 정보 및 보안 정보를 이미 알고 있는 경우에 이 절차는 생략이 가능하다.

② 메시지 전송 및 전송확인

- 송신자는 메시지를 유통 프로토콜 규격에 맞게 패키징 한 후, 유통 메시징서버 시스템의 공인인증서를 기반으로 전자서명을 수행한다.

- 유통 메시징서버 시스템은 앞서 획득한 물리적 주소에 패키징하고 전자서명된 메시지를 전송한다.

- 메시지를 수신한 수신 유통 메시징서버 시스템은 메시지의 기본 패키징 구조, 전자서명에 대한 유효성, 송신자에 대한 적합성(검증에 대한 상세 내용은 “2.4.6 메시지 검증”부분 참조)을 검증한 후, 수신확인을 위한 수신증명서 또는 오류메시지를 생성한다.

- 수신 유통 메시징서버 시스템은 생성한 응답메시지를 송신자에게 전송한다.

- 전송과 전송확인 과정은 동기식 메시지 처리로 이루어진다.

③ 업무수신자의 수신확인

- 송신자가 메시지 전송시점에 업무 수신자의 담당자 열람확인 메시지를 요청한 경우에는 수신자는 메시지에 대한 업무적 수신확인 시점에 송신자에게 반드시 담당자 열람확인을 증빙할 수 있는 열람증명서를 생성하여 이를 전송하여야 한다.

- 수신자가 메시지 송신자에게 담당자 열람확인을 위한 열람증명서 메시지를 보내면 원 메시지 송신자를 이에 대한 수신확인 메시지를 동기식으로 보내준다.

④ 유통증명서 발급 및 보관

- 각 단계별로 유통에 대한 증빙을 받고자 하는 경우 송신자는 각 단계에 따라 수신, 열람, 송신에 대한 증명서를 발급하고 이를 공인전자문서보관소에 보관함으로써 유통에 대한 법적 증빙의 근거를 확보한다.

본 발명에 따른 유통 메시징서버 시스템을 이용하여 송신자와 수신자 간에 직접 메시지를 유통하는 프로세스는 상기와 같은 "①수신자에 대한 물리적 주소 및 보안정보 획득", "② 메시지 전송 및 전송확인", "③ 업무수신자의 수신확인", "④ 유통증명서 발급 및 보관"외에 "⑤오류 처리"도 수행하는데, 도 10 내지 도 12를 참조하여 오류 처리 기능과 관련하여 상세히 설명하면 다음과 같다.

⑤오류 처리 기능

유통 메시징서버 시스템의 모든 메시지 송수신 프로세스는 동기식 처리를 기본으로 한다. 따라서, 전송에 대한 모든 오류는 전송자가 확인 가능하므로 재전송하는 것을 기본으로 하며, 동일한 메시지 전송은 동일한 MessageId 값을 설정하여 다시 보내도록 함으로써 수신자가 수신 성공 후 수신확인 메시지 전송과정에서의 오류에 대해서도 중복메시지 수신을 감지할 수 있도록 한다.

유통 메시징서버 시스템은 요청메시지 송신에 실패한 경우에 도 10과 같은 처리 흐름도를 따른다. 즉, 메시지 송신자가 전송하는 과정에서 네트워크 오류 등에 의해 전송오류가 발생한 경우에 송신자는 HTTP 오류와 같은 오류 메시지를 받게 되면 동일한 메시지를 다시 재전송 요청하며, 송신자는 수신자에게 수신확인 메시지를 받은 경우에만 전송성공으로 인식한다.

유통 메시징서버 시스템은 응답메시지 수신에 실패한 경우에 도 11과 같은 처리 흐름도를 따른다. 즉, 메시지가 수신자에게 정상적으로 전달되었으나 송신자가 수신자로부터 수신확인 메시지를 받지 못한 경우에 송신자는 송신실패 오류로 인식하고 수신자게에 동일한 메시지를 동일한 MessageId로 재전송하게 되며, 수신자는 수신한 문서의 MessageId가 이전 수신 메시지와 동일한 경우에는 중복 수신으로 수신확인 메시지를 보낸 후 내부 처리를 한다.

유통 메시징서버 시스템은 오류메시지 수신에 실패한 경우에 도 12와 같은 처리 흐름도를 따른다. 즉, 송신자가 수신자에게 전송한 메시지가 정확히 전달되었으나 전송메시지 자체에 오류가 있어서 오류메시지를 응답받은 경우에 송신자는 오류 유형에 따라 메시지 처리를 달리하며, 재요청 시 전송하는 메시지의 MessageId는 동일할 필요는 없으며 업무 상황에 따라 다르게 처리할 수 있다.

상술한 바와 같은 본 발명에 따른 유통 메시징서버 시스템에 있어서 필수로 요구되는 기능인 "① 메시지 송/수신", "② 수신 메시지 사서함 관리", "③ 메시지 보안", "④ 송수신 이력 관리", "⑤ 주소 디렉터리 서버 연계", "⑥ 메시지 검증", "⑦ 내부시스템 연계 인터페이스", "⑧ 유통증명서 발급 및 관리" 기능들에 대하여 상세히 설명하면 다음과 같다.

① 메시지 송/수신

유통 메시징서버 시스템이 메시지를 송수신하는 기본 프로세스는 상술한 본 발명에 따른 [전자문서 유통 방법]의 "문서 송수신 방안"을 따른다. 메시지 송수신을 위한 기본이 되는 메시지 교환 유형은 메시지 유통 프로토콜의 동기식 응답을 기본으로 하며, 송신메시지와 수신확인 메시지, 송신 메시지와 수신오류 메시지, 송신 메시지와 비즈니스적 응답메시지(수신확인 메시지의 의미를 포함)의 구성을 이룰 수 있다.

메시지 송/수신 유형으로는 송신과 수신확인 응답 메시지의 조합과, 송신과 비즈니즈 응답메시지의 조합을 포함하는 2가지 유형이 있다.

메시지 송/수신 유형이 송신과 수신확인 응답 메시지의 조합인 경우에 처리 흐름은 도 13과 같으며, 송신 메시지와 수신확인(또는 수신오류) 메시지는 SOAP(Simple Object Access Protocol) Request-Response의 조합으로 이루어지며, 송신 메시지와 그에 대한 응답 메시지는 송신 메시지의 MessageId를 응답 메시지의 RefToMessageId에 넣어서 보냄으로써 연관관계를 맺어주는데, 이와 관련한 상세한 설명은 후술하는 [유통 프로토콜]을 참조한다.

메시지 송/수신 유형이 송신과 비즈니스 응답메시지의 조합인 경우에 처리 흐름은 도 14와 같으며, 송신 메시지와 수신확인(또는 수신오류) 메시지를 포함한 응답메시지는 SOAP Request-Response의 조합으로 이루어지며, 수신자가 메시지를 수신한 후 내부시스템에 실시간 연계하여 비즈니스 처리한 응답문서를 생성한 후에 응답문서와 수신확인 ACK 메시지를 함께 응답메시지에 실어서 송신자에게 전달하며, 송신메시지와 그에 대한 응답메시지는 송신메시지의 MessageId를 응답메시지의 RefToMessageId에 넣어서 보냄으로써 연관관계를 맺어주는데, 이와 관련한 상세한 설명은 후술하는 [유통 프로토콜]을 참조한다.

송/수신되는 메시지의 구조는 도 15에 도시한 바와 같이 MultiPart-MIME 구조를 가지며, 첫 번째 Mime 부분에는 SOAP 메시지가, 2번째 Mime부터는 전송하고자 하는 문서가 들어간다.

첫 번째 Mime은 SOAP 헤더와 SOAP Body로 구성된 SOAP Envelope이 들어가며, SOAP 헤더는 메시지 송수신을 위한 메시지 헤더 정보, 전자서명, 수신확인 메시지, 동기식 전송 표시, 오류 메시지 등이 들어간다. 그리고, 두 번째 Mime은 메시지 수신자에게 전달하는 문서(정보)가 들어가며, 담당자 수신확인 메시지를 전달하는 경우에 이 위치에 들어간다. 그리고, 세 번째 Mime은 메시지 수신자에게 전달하는 문서(정보)가 2개 이상인 경우 세 번째 Mime부터 순차적으로 들어간다.

② 수신 메시지 사서함 관리

유통 메시징서버 시스템은 메시지를 수신하면 수신 메시지를 계정 별로 사서함에 저장한다. 수신 메시지 사서함은 하나 이상의 사용자 계정 별로 구분되어 메시지를 저장 관리하며, 사용자의 요청(새 수신메시지 존재 여부, 수신메시지 열람, 수신메시지 다운로드, 수신메시지 삭제 등)에 따라 필요한 처리 후 결과를 돌려주는 인터페이스를 반드시 표준화된 방식으로 제공하여야 한다.

유통 메시징서버 시스템이 관리하는 사용자 계정이 전자문서유통에 포함되는 공인전자주소로서 자격을 갖기 위해서는 유통 메시징서버 시스템은 신뢰 사용자 계정을 갖기 위한 인증요건(차후 별도의 평가지침을 통해 요건을 정의할 것이며, 현 시점에서는 공인전자문서보관소만이 이 인증요건을 충족한 것으로 인정함)을 통과하여야 한다.

따라서, 개인 또는 기업(기관)이 전자문서유통에서 공인전자주소를 획득하기 위한 방안으로는 다음과 같은 2가지 방안이 있다. 첫 번째 방안은, 자체적으로 유통 메시징서버 시스템을 구축하고 이를 인증 받은 후 획득한 송수신 개체 id를 주소 디렉터리 서버에 등록하는 것이며, 두 번째 방안은, 인증 받은 유통 메시징서버 시스템 중 신뢰 사용자 계정을 갖는 요건을 추가적으로 충족한 송수신 개체에 사서함을 개설하여 사용자 id를 발급 받은 후 이를 주소 디렉터리 서버에 등록하는 것이다.

③ 메시지 보안

전송 메시지에 대한 보안은 무결성 보장을 위한 전자서명과 기밀성 보장을 위한 암/복호화로 나눌 수 있다. 유통 메시징서버 시스템을 통해 전송되는 메시지는 SOAP 메시지와 첨부문서로 나뉜다. 이때, 첨부문서는 유통 클라이언트 APP에서 이미 암호화되어 있는 상태이고 SOAP Envelope에는 단지 메시지 송수신을 위한 헤더 정보만 포함되므로 유통 메시징서버 시스템에서는 추가적인 암호화 과정을 거치지 않으며, 메시지 송수신 과정에서 위변조 방지를 위한 전자서명 과정은 수행한다. 전자서명 방식 및 세부 절차는 후술하는 [유통 프로토콜]을 참조한다.

④ 송수신 이력 관리

유통 메시징서버 시스템은 향후 송수신에 관련한 분쟁이 발생하거나 이슈가 제기되었을 때, 이를 확인하기 위해 송수신에 대한 이력정보를 관리하여야 한다. 이력정보는 송수신 행위에 대한 정보뿐 아니라 실제 송수신한 문서에 대한 정보도 관리하여야 하는데, 실 문서를 공인전자문서보관소에 보관한 경우에는 문서의 원본이 아닌 공인전자문서보관소로부터 받은 등록증명서만을 보관하는 것도 가능하다.

⑤ 주소 디렉터리 서버 연계

유통 메시징서버 시스템은 주소 디렉터리 서버가 제공하는 서비스 연계 인터페이스를 사용하여 주소 디렉터리 서버와 연계를 한다. 주소 디렉터리 서버는 2종류의 주소 검색 서비스와 주소 등록 서비스, 주소 변경 서비스를 제공하는데 유통 메시징서버 시스템은 주소 검색 서비스 중 “공인전자주소에 대한 물리적 주소 검색" 서비스 연계 기능은 필수적으로 제공한다.

검색 서비스 외에 주소 등록 및 주소 변경 서비스는 유통 메시징서버 시스템이 하위에 등록/관리하는 사용자 계정을 기업이나 개인의 공인전자주소로 사용할 수 있는지에 따라 사용 여부가 결정된다. 유통 메시징서버 시스템이 등록/관리하는 사용자 계정이 공인전자주소로 등록이 가능하도록 인증을 받은 경우에는 공인전자주소에 대한 등록 및 변경서비스를 대행하여야 하므로 주소 디렉터리 서버의 해당 서비스를 연계한다.

⑥ 메시지 검증

- 유통 메시징서버 시스템이 메시지를 송수신할 때 수신자는 메시지 수신시점에 메시지 유효성에 대한 검증을 수행하며, 도 16에 도시한 프로세스와 같이 수신자는 메시지 유효성 검증을 한 후 검증에 통과한 경우에만 메시지 수신확인 메시지를 송신자에게 전달하고, 그렇지 않은 경우에는 수신 메시지에 대한 오류 메시지를 전송한다.

- 검증대상: 수신 메시지의 스키마 검증(수신 메시지가 유통 프로토콜에 따라 정확히 패키징되었는지를 검증), 메시지의 무결성 검증(수신한 메시지의 전자서명 값을 검증함으로써, 메시지의 위변조가 발생하지 않고 무결한지를 검증), 메시지 송신자 검증(메시지에 전자서명을 한 송신자가 메시지에 표기된 송신자가 맞는지를 인증하기 위해 전자서명에 사용된 인증서와 메시지의 송신자가 동일한지를 검증)

⑦ 내부시스템 연계 인터페이스

유통 메시징서버 시스템은 내부 시스템이 유통 메시징서버 시스템을 통해 문서를 전송하고 수신할 수 있도록 송수신을 위한 표준화된 인터페이스를 제공하여야 한다. 이 인터페이스에 대한 상세한 내용은 후술하는 [유통 클라이언트 APP]를 참조한다.

⑧ 유통증명서 발급 및 관리

유통증명서의 기본요건은, ① 유통증명서는 발신 및 수신 유통 메시징서버 시스템이 생성한다는 것과, ② 유통증명서는 GPKI 및 NPKI 인증서를 기반으로 전자서명하여 생성된다는 것과, ③ 유통증명서는 전자문서 유통행위를 기준으로 생성(이때, 한 번의 전자문서 유통 시 하나 이상의 전자문서가 전달되는 경우 하나의 유통증명서를 생성하고, 하나의 전자문서 유통을 위해서는 반드시 해당 유통을 식별할 수 있는 ID가 부여되며 이를 기준으로 유통으로 유통증명서를 생성함)된다는 것이다.

유통증명서 발급 시점에 고려하여야 할 내용은, ① 유통증명서의 일련번호는 개별 송수신 개체가 생성하므로 유일성 부여를 위하여 기존 증명서의 규격과는 달리 20byte 난수를 사용하는 것과, ② 유통증명의 갱신 및 폐지는 정의하지 않는다는 것과, ③ 유통증명서를 생성하는 유통 메시징서버 시스템 및 유통 클라이언트 APP의 시스템 시각은 항상 현재 시각을 유지해야한다는 것과, ④ 유통증명서 정책은 기술규격에서 정의한 OID 및 명칭만을 사용한다.

유통증명서 발급 프로세스는 도 17에 도시한 바와 같으며, 유통 증명서의 유형 및 생성에 필요한 필수 정보는 아래 표2와 같으며, 유통 증명서의 필수 정보의 획득 방법은 아래 표3과 같다.

유통증명서는 송수신 개체가 생성하며 송수신 개체의 NPKI 및 GPKI 인증서를 이용하여 전자서명하며, 유통증명서의 기본 구조는 CMS 표준의 SignedData 구조를 사용하며 증명서와 동일한 콘텐츠 식별자를 사용한다.

유통증명서의 contentType 은 다음과 같다.

id-kiec-arcCertReseponse OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) kiec(200032) certificate(2) 2 }

ARCCertResponse ::= CHOICE {

arcCertInfo[0] EXPLICIT ARCCertInfo,

arcErrorNotice[1] EXPLICIT ARCErrorNotice }

유통증명서의 기본필드는 다음과 같다.

ARCCertInfo ::= SEQUENCE {

version[0] EXPLICIT ARCVersion DEFAULT v1,

serialNumberSerialNumber,

issuerGeneralNames,

dateOfIssueGeneralizedTime,

dateOfExpireDateOfExpiration,

policyARCCertificatePolicies,

requestInfoRequestInfo,

targetTargetToCertify,

extionsions[1] EXPLICIT Extensions OPTIONAL

}

상기와 같은 유통증명서의 기본필드에 대하여 상세히 설명하면 다음과 같다.

① version, 버전

- 유통증명서 구조의 버전을 나타낸다. 유통증명서를 위해서는 v2로 설정해야하며 target 필드에 dataHash를 사용한다.

ARCVersion ::= INTEGER {v1(1), v2(2)}

② serialNumber, 일련번호

- 유통증명서의 식별정보를 나타낸다. 유통증명서는 전자문서를 수신한 송수신 개체가 생성하므로 일련번호 방식의 식별번호는 의미가 없다. 또한, 송수신 개체의 유통클라이언트가 재설치되는 등의 경우에는 일련번호의 유지가 불가능하다.

따라서 유통증명서의 식별정보는 20byte 난수를 사용한다. 유통증명서를 처리하기 위해서는 20byte 난수를 처리할 수 있어야 한다.

SerialNumber ::= INTEGER

③ issuer, 증명서 발급자

- 유통증명서를 발급하는 발급자의 인증서 식별값을 넣는다. 본 필드의 값은 유통증명서를 전자서명한 서명자의 인증서 내 SubjectName 필드과 동일한 값을 가져야 한다.

④ dateOfIssue, 증명서 발급일

- 발급자가 유통증명서를 발급한 시점을 나타낸다.

⑤ dateOfExpire, 증명서 효력 만기일

- 유통증명서의 만료 시점을 나타낸다.

⑥ policy, 증명서 정책

- 유통증명서 정책을 나타낸다. 모든 유통증명서 내의 정책 OID는 증명서 종류에 따라 다르며 기술규격에서 저장한 값만을 사용하여야 한다.

- 유통증명서는 증명서 종류에 따라 일괄적으로 하나의 OID를 가진다.

- Qualifier 값으로는 UserNotice > ExplicitText > DisplyText 에 UTF8String 형식으로 나타내며 지정된 문장을 사용한다.

- 유통증명서 유형에 따라 아래의 표 4와 같은 정책 정보를 사용하여야 한다.

⑦ requestInfo, 증명서 요청 메시지 정보

- 본 필드는 null로 설정한다.

RequestInfo ::= CHOICE {

arcCertRequest ARCCertRequest,

null NULL }

⑧ target, 증명 대상

- 유통된 전체 전자문서의 해시 값을 지정한다. 본 필드는 반드시 distributionInfos 방식을 사용하여야 한다. opRecord 및 orgAndIssued, dataHash 필드에 대한 구조는 공인 전자문서 보관소의 '증명서 포맷 및 운용절차 기술규격'을 참조한다.

- 유통되는 전자문서에 대한 정보는 DistributionInfos 필드에 포함된다.

TargetToCertify ::= CHOICE {

opRecord[0] EXPLICIT OperationRecord,

orgAndIssued[1] EXPLICIT OriginalAndIssuedDocumentInfo,

dataHash[2] EXPLICIT HashedDataInfo

distributionInfos[10] EXPLICIT DistributionInfos}

DistributionInfos ::= SEQUENCE OF DistributionInfo

DistributionInfo ::= SEQUENCE {

senderAddGeneralNames,

receiverAddGeneralNames,

dateOfSendGeneralizedTime,

dateOfReceive[0] EXPLICIT GeneralizedTime OPTIONAL,

dateOfReceiveConfirm[1] EXPLICIT GeneralizedTime OPTIONAL,

distributionIdINTEGER,

numberOfFilesINTEGER,

distributedFileInfosDistributedFileInfos}

①-① senderAdd, 공인 전자주소

- 송신자의 공인 전자주소를 나타낸다.

①-② receiverAdd, 수신자 공인 전자주소

- 수신자의 공인 전자주소를 나타낸다.

①-③ dateOfSend, 송신 일시

- 송신자가 전자문서를 발송한 시점을 나타낸다.

- 송신증명서의 경우 송신자가 전자문서 유통허브에 송신 의뢰한 시각을 지정한다.

- 송신증명서는 본 필드만 포함하여야 하며 dateOfReceive 및 dateOfReceiveConfirm는 포함하지 않아야 한다.

①-④ dateOfReceive, 수신 일시

- 수신자가 전자문서를 수신한 시점을 나타낸다. 해당 시점은 증명서를 생성한 시점보다 같거나 이전이어야 한다. 수신 증명서 및 열람 증명서는 반드시 본 필드를 포함하여야 한다. 송신증명서는 본 필드를 포함하지 않아야 한다.

①-⑤ dateOfReceiveConfirm, 열람 일시

- 수신자가 전자문서를 수신하여 확인한 시점을 나타낸다. 해당 시점은 수신 일시보다 같거나 이후이어야 하며 증명서를 생성한 시점보다 같거나 이전이어야 한다. 열람 증명서는 반드시 본 필드를 포함하여야 한다. 송신 증명서 및 수신 증명서는 반드시 본 필드를 포함하지 않아야 한다.

①-⑥ distributionId, 유통식별값

- 전자문서의 유통 건에 대한 식별 값을 나타낸다. 본 필드의 생성을 위하여 20byte 난수를 생성하여 사용한다. 본 필드값은 전자문서 유통에 대하여 유통메시지에 부여되는 식별값을 의미한다.

①-⑦ numberOfFiles, 유통파일 개수

- 유통 시 하나 이상의 전자문서가 전달될 수 있으며, 본 필드는 한 번의 유통에 전달되는 파일의 개수를 나타낸다.

①-⑧ distributedFileInfos, 유통문서정보

- 유통 시 하나 이상의 전자문서가 전달될 수 있으며, 본 필드에는 전달되는 모든 문서에 대한 정보가 포함되어야 한다.

DistributedFileInfos ::= SEQUENCE OF DistributedFile

DistributedFile ::= SEQUENCE {

fileHashedDataHashedDataInfo,

fileId[0] UTF8String OPTIONAL,

fileName[1] UTF8String OPTIONAL

}

①-⑧-① fileHashedData, 파일 해쉬 정보

- 본 필드는 유통되어 전달된 전자문서에 대한 해시 값을 나타낸다.

①-⑧-② fileId, 파일 식별값

- 유통되는 전자문서에 식별 값을 부여한 경우 해당 문서에 대한 식별 값을 지정한다. 파일 식별 값은 송신자가 생성하며 전자문서를 수신자에게 전달할 때 함께 전달되어야 한다. 수신자는 전달받은 파일 식별 값을 이용하여 본 필드에 적용하여야 한다.

- 송신자는 본 필드의 생성을 위하여 uuid 방식으로 생성하여야 한다.

- 본 필드는 선택적으로 사용될 수 있으나 fileName 필드가 사용되지 않는 경우에는 반드시 사용되어야 하며 field 필드의 사용을 권고한다.

①-⑧-③ fileName, 파일명

- 유통되는 전자문서에 대한 파일명을 나타낸다. 파일명은 송신자가 지정하며 전자문서를 수신자에게 전달할 때 함께 전달되어야 한다. 수신자는 전달받은 파일 식별 값을 이용하여 본 필드에 적용하여야 한다.

- 본 필드는 선택적으로 사용될 수 있으나 fileID 필드가 사용되지 않는 경우에는 반드시 사용되어야 한다.

상술한 바와 같은 유통증명서의 시각 정보관련 정합성 기준은 아래 표5와 같다.

시각정보 순서는 발송일시 < 수신 일시 ≤ 열람 일시 ≤ 증명서 발급일 < 증명서 효력 만기일이며, 유통증명서 검증 시에 시각 정보가 상기의 순서에 맞는지 확인해야 한다.

유통증명서의 검증은 증명서 구조 검증, 증명서 전자서명 검증, 증명서 주요 필드 확인, 증명서 시각 정보 정합성 검증을 포함한다.

증명서 구조 검증은 증명서가 ASN.1 정의된 바와 동일한 지 검증하는 과정이다.

증명서 전자서명 검증은 유통증명서에 적용된 전자서명을 검증하는 과정이다.

증명서 주요 필드 확인은 version 필드 값이 v2인지 확인하는 버전필드 확인, target 필드가 hashData 인지 확인하는 target 필드 확인, 전자서명에 사용된 인증서의 DN과 증명서 기본필드의 DN이 동일한지 검증하는 발급자 정보 검증, requestInfo 필드가 Null 인지 확인하는 requestInfo 필드 확인, distributionInfos 확장필드가 존재하는지 확인하고 critical이 TRUE인지 확인하는 확장필드 확인, numberOfFiles 필드의 값과 distributionInfos 확장필드 내 DistributedFile의 개수가 동일한 지 확인하는 파일 개수 확인, target 필드의 해시 값과 distributionInfos 확장필드의 해시 값이 동일한 지 확인하는 target 필드 해시 값 확인, 유통증명서 시각 정보의 정합성 검증 기준에 따라 검증하는 시각 정보 정합성 검증을 포함한다.

증명서 시각 정보 정합성 검증은 유통증명서 시각 정보의 정합성 검증 기준에 따라 검증한다.

한편, 유통증명은 전자문서의 유통과정에서 발생한 발신, 수신, 수신확인에 대한 사실에 대하여 신뢰성 있는 방식으로 증명하는 행위를 말한다. 유통증명은 별도의 응용프로그램에서 수행하며 유통증명서 뷰어 및 유통증명API에서 수행하지 않는다. 유통증명은 유통증명서 검증에 추가적으로 수행하고자 하는 경우 다음의 내용을 수행한다.

- 유통증명서 검증: 유통증명서의 검증을 수행한다.

- 유통증명서 정책 확인: 발신, 수신, 수신확인에 대한 유통증명서 정책 OID 및 Qualifier 값을 확인한다.

- 송신자 주소 확인: 전자문서를 발송한 송수신 개체의 주소가 정확한지 확인한다.

- 수신자 주소 확인: 전자문서를 수신한 송수신 개체의 주소가 정확한지 확인한다.

- 발송 일시 확인: 송신자가 전자문서를 발송한 시각이 정확한지 확인한다.

- 수신 일시 확인: 수신자가 전자문서를 수신한 시각이 정확한지 확인한다.

- 수신확인 일시 확인: 수신자가 전자문서를 수신확인한 시각이 정확한지 확인한다.

- 유통ID 확인: 유통 개별 건에 부여된 유통ID가 정확한지 확인한다. 송신자 및 수신자가 유통ID를 별도로 보관하여 관리하는 경우 이를 비교하여 관리할 수 있다.

- 유통 파일의 식별자 또는 파일명 확인: 유통되는 파일의 ID 또는 파일명이 정확한지 확인한다. 송신자 및 수신자가 파일ID 및 파일명을 별도로 보관하여 관리하는 경우 이를 비교하여 관리할 수 있다.

- 유통 파일의 해시 값 확인: 유통 대상이 되는 파일들의 각각의 해시 값과 확장필드의 DistributedFile 필드의 값이 동일한지 확인한다. 이때 사용하는 해시 알고리듬은 유통증명서 내에 지정된 것으로 수행하여 비교한다.

한편, 유통증명서 프로파일은 아래 표 5 및 표 6과 같으며, 고려할 사항은 전자서명은 RSA 2048bit 및 SHA256 알고리즘을 적용한다는 것과, signedData 구조에서 인증서는 반드시 포함되어야 한다는 것과, signerInfos 필드에는 하나의 signerInfo 만 포함된다는 것이다.

상술한 바와 같은 유통증명서를 공인전자문서보관소와 연계하는 방안은 유통증명서를 발급함과 동시에 공인전자문서보관소에 저장(보관) 의뢰함으로써 발급된 유통증명서의 신뢰성을 보장받는 것이다.

공인전자문서보관소 사업자의 유통 메시징서버 시스템의 경우에 유통증명서 보관 프로세스는 도 18과 같으며, 유통 메시징서버 시스템에서 발급한 유통증명서를 직접 공전소 연계모듈을 통해 공인전자문서보관소 내부에 보관요청을 하며, 공전소 연계모듈은 유통증명서 보관요청모듈과 공인전자문서보관소 연계인터페이스 클라이언트 모듈로 구성되며, 기존의 공인전자문서보관소 연계인터페이스 규격에 따라 공인전자문서보관소에 보관된다.

일반 송수신 개체의 유통 메시징서버 시스템의 경우에 유통증명서 보관 프로세스는 도 19와 같으며, 발급된 유통증명서 보관을 위해 공인전자문서보관소 사업자들에게 요청을 하기 위해 공인전자문서보관소 사업자의 유통 메시징서버 시스템에 요청메시지를 전달하며, 외부에서 유통증명서 보관요청을 받은 공전소 사업자 유통 메시징서버 시스템은 공인전자문서보관소 연계모듈을 통해 공인전자문서보관소 내부에 보관 요청을 하며 공인전자문서보관소 연계모듈은 기존의 공인전자문서보관소 연계 인터페이스 규격에 따라 공인전자문서보관소에 보관 요청을 한다.

송수신 개체가 유통증명서를 공전소에 보관하는 상세 처리는 도 20에 도시한 바와 같은 절차로 이루어지며, 상세한 설명은 다음과 같다.

○ 유통증명서 등록자

- 공전소에 유통증명서를 보관할 때 공전소 사업자와 송수신 개체 간 계약에 의해 보관대행자를 지정할 수 있으며, 공전소 사업자는 보관대행자가 등록자가 되어 보관대행자의 공인인증서를 기반으로 유통증명서를 보관하게 됨

○ 공전소 보관요청 프로세스 유형

- 공전소 사업자는 동기식 또는 비동기식 처리 중 하나이상 제공하여야 하며 유통 메시징서버는 연계하고자 하는 공전소 사업자가 제공하는 방식에 따라 연계됨

- Case 1: 동기식 처리 프로세스 (송신자가 유통증명서 보관요청 시 공전소에 등록이 완료된 후 등록증명서가 발급되는 모든 프로세스가 동기식으로 이루어짐으로써 송신자의 유통 메시징서버는 동기식 응답 메시지로 등록증명서를 전달 받음. 요청에 대한 응답 메시지가 최종적인 공전소 등록결과이므로 보관요청에 대한 오류 발생 시 재처리는 송신자의 유통 메시징서버가 수행하여야 함)

- Case 2: 비동기식 처리 프로세스 (송신자가 공전소 유통 메시징서버에 유통증명서 보관요청을 하면, 공전소 유통 메시징서버가 먼저 요청메시지의 유효성을 검증한 후, 보관요청을 접수함. 공전소 사업자는 보관요청 메시지에 따라 공전소에 등록하고 발급 받은 등록증명서를 최초 보관요청자인 송신자의 유통 메시징서버에 전달하여야 함. 접수한 보관요청에 대해서 공전소에 등록하는 것은 공전소 사업자의 책임이므로, 보관오류 발생 시 재처리 역시 공전소 사업자가 수행하여야 함)

[유통 프로토콜]

이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 유통 프로토콜에 대하여 상세히 설명하도록 한다.

본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 유통 프로토콜을 설명함에 있어서, "① 메시지 패키징", "② 메시지 봉투 구성", "③ HTTP 바인딩"에 대하여 차례로 설명하도록 한다.

① 메시지 패키징

유통 프로토콜의 메시지 구조는 ebMS V2.0 규격을 준용하며, 두 개의 논리적인 MIME 파트를 가진다.

첫 번째 MIME 파트는 SOAP 메시지를 포함하며 헤더 컨테이너라고 불리고, SOAP 메시지는 Header와 Body로 구성되며, 두 번째 MIME 파트는 0개 이상의 추가적인 MIME 파트로서 페이로드 컨테이너라고 불리는데 어플리케이션 레벨의 첨부 문서를 포함한다.

이와 같은 유통 메시지의 기본적인 구조는 도 21과 같으며, Simple Object Access Protocol(SOAP) 1.1 및, SOAP Messages with Attachment와 같은 표준 규격을 준수한다.

유통 메시지 패키지의 모든 MIME Header 요소들은 SOAP Messages with Attachments 규격을 준수한다. 추가로, 메시지 패키지 내의 Content-Type MIME Header는 반드시 SOAP 메시지 문서를 포함하는 MIME Body 부분의 MIME 미디어 유형과 동일한 type 속성을 가진다. SOAP 규격에 따르면 SOAP 메시지의 MIME 미디어 유형은“text/xml” 값을 가져야 한다고 되어 있다.

루트 부분은 [RFC2045]에 준하는 구조를 가지는 Content-ID MIME 헤더를 포함하고 Multipart/Related 미디어 유형에 대한 필수적인 파라미터에 추가하여, start 파라미터([RFC2387]에서는 선택사항)가 항상 존재해야 한다. multipart/related 메시지 패키지의 MIME 헤더 예제는 다음 표 7과 같다.

이하에서 본 발명에 따른 유통 메시지에 대하여 설명함에 있어서 메시지 패키지의 루트 Body 부분을 Header(헤더) 컨테이너라고 정의한다. Header 컨테이너는 MIME 몸체 부분으로 SOAP Messages with Attachment명세에서 정의한 것과 같이 하나의 SOAP 메시지를 포함한다.

헤더 컨테이너의 MIME Content-Type header는 SOAP 규격에 따라 “text/xml” 값을 가져야 한다. Content-Type 헤더는 “charset” 속성을 포함할 수도 있으며, 예제는 다음 표 8과 같다.

MIME charset 속성은 SOAP 메시지를 생성하는데 사용되는 문자 군을 식별하기 위해 사용된다. 이 속성의 의미론은 [XMLMedia]에 명시되어 있는 text/xml 의 “charset parameter / encoding consideration”에 설명되어 있다. 유효한 값의 목록은 http://www.iana.org/에서 찾을 수 있다.

만약에 두 가지가 모두 포함되어 있다면, MIME charset 속성은 SOAP 메시지의 인코딩 선언부와 동일해야 한다. 만약에 제공되어 있다면 MIME charset 속성은 SOAP 메시지를 생성할 때 인코딩과 상충되는 값을 포함하고 있어서는 안 된다.

이 문서를 인코딩할 때는 최대한의 호환성을 위하여 반드시 [UTF-8]을 사용하여야 한다. text/xml[XMLMedia]에서 도출해 온 미디어 유형들을 위해 정의된 처리 규칙 때문에 이 MIME 속성은 기본 값을 가지지 않는다.

헤더 컨테이너의 예제는 아래 표 9와 같다.

SOAP Messages with Attachments 규격에 따라 메시지 패키지 내에는 0개 이상의 페이로드 컨테이너가 포함될 수 있다. 만약 메시지 패키지가 어플리케이션 페이로드를 포함하고 있다면, 이는 반드시 페이로드 컨테이너에 포함되어 있어야 한다.

만약, 메시지 패키지가 어플리케이션 페이로드를 포함하고 있지 않다면 페이로드 컨테이너를 표시하지 말아야 한다. 각 페이로드 컨테이너의 내용물은 SOAP Body 내의 ebXML 메시지 Manifest 요소에 의해 식별되어야만 한다.

ebXML 메시지 서비스 명세는 어플리케이션 페이로드의 구조와 내용물에 대하여 어떠한 규정도 어떤 식의 제약도 정해놓고 있지 않다. 페이로드는 simple-plain-text 객체 또는 복잡하게 중첩된 여러 부분의 객체도 될 수 있다. 페이로드 객체의 구조와 구성에 대한 명세는 ebXML 메시지 서비스를 사용하는 업무 프로세스나 정보 교환을 어떻게 정의하는지에 따라 달라질 수 있다. 페이로드 컨테이너의 예제는 다음 표 10과 같다.

본 발명에 따른 유통 메시지의 모든 MIME 부분은 [RFC2045] 규격에 준하는 추가적인 MIME 헤더들을 포함할 수 있다. 구현 시에는 이 발명에서 정의되지 않은 MIME 헤더들을 무시할 수도 있으며, 식별할 수 없는 MIME 헤더들은 반드시 무시해야 한다. 예를 들어, 구현 시에 content-length를 메시지에 포함할 수 있지만, content-length가 나타나 있는 메시지의 수령자는 이를 무시할 수도 있다.

② 메시지 봉투 구성

SOAP 규격에 준하여 모든 확장 요소 내용은 유효한 네임스페이스로 한정되어야 한다. 본 발명에서 정의된 모든 ebXML SOAP 확장 요소 내용은 ebXML SOAP Envelope 확장 네임스페이스로 한정되어야 한다. 네임스페이스 선언부들은 SOAP Envelope, Header 또는 Body 요소들에 포함되어 있거나, 각 SOAP 확장 요소들에 직접 포함되어 있을 수 있다.

SOAP Envelope은 SOAP 메시지의 Root 항목으로 SOAP 메시지 내의 각종 Namespace 들을 선언한다. 선언해야 할 Namespace는 다음 표 11과 같다.

메시지 봉투의 스키마 구조는 도 22와 같으며, 메시지 봉투의 예제는 아래 표 12와 같다.

SOAP Envelope 요소의 자식 요소인 SOAP Header 요소와 SOAP Body 요소에 대하여 차례로 상세히 설명하면 다음과 같다.

SOAP Header 요소는 SOAP Envelope 요소의 첫 번째 자식 요소이며, MessageHeader, SyncReply, Signature, ErrorList와 같은 확장 요소를 포함한다.

MessageHeader는 메시지의 라우팅 정보(To/From, 등)와 메시지에 관한 다른 문맥정보를 포함한 필수 요소이며, SyncReply는 다음 SOAP 노드로 가는 필수 전송 상태를 가리키는 요소이고, Signature는 메시지와 연관된 데이터를 서명하는 [XMLDSIG]에 준하는 전자서명을 표시하는 요소이며, ErrorList는 이전의 메시지를 대상으로 보고되어진 오류의 목록을 담은 요소이며 이전의 메시지에 대한 오류를 보고할 때에만 사용되어지는데, 이와 같은 MessageHeader의 요소들 각각에 대하여 상세히 설명하면 다음과 같다.

MessageHeader 요소는 모든 ebXML 메시지에 표현되어야 하는 필수 요소로서 반드시 SOAP Header 요소의 자식 요소로 표현되어야 한다. MessageHeader 요소는 다음과 같은 하위 요소들로 구성된 복합 요소이며, MessageHeader의 element 구조는 아래 표 13과 같으며, MessageHeader의 스키마 구조는 도 23과 같다.

SyncReply 요소는 동기식 송신을 의미하는 것으로서id 속성,version 속성, SOAP actor 속성(반드시 "http://schemas.xmlsoap.org/soap/actor/next" 값을 가져야 함), SOAP mustUnderstand 속성값을 가지며, SyncReply 요소의 예제는 다음 표14와 같다.

Signature 요소는 SOAP Header의 자식요소로 반드시 존재해야 하는데, 이는 유통 메시지는 위에서 언급한 위험 요소에 대응하기 위하여 반드시 전자적으로 서명되어야 하기 때문이다.

[XMLDSIG] 규격에 따라 전자서명을 수행하는 과정은 다음과 같다.

먼저, SOAP Envelope에 SignatureMethod, CanonicalizationMethod, Reference 요소를 가진 SignedInfo 요소와 필수 페이로드 객체를 [XMLDSIG]에 규정된 대로 생성한다.

다음으로, 정규화 한 뒤 [XMLDSIG]에 지정된 대로 SignedInfo에 지정된 알고리듬을 기준으로 SignedInfo의 SignatureValue를 산출한다.

다음으로, [XMLDSIG]에 지정된 대로 SignedInfo, KeyInfo(권고사항), SignatureValue 요소를 포함하는 Signature 요소를 생성한다.

다음으로, SOAP Header의 Signature 요소를 SOAP Header 요소에 포함한다.

상술한 바와 같은 전자서명 시에 사용되는 알고리듬 정보는 다음과 같다. 알고리듬은 W3C "XML-Signature Syntax and Processing" (RFC3275)의 알고리듬 부분(6.0 Algorithms)을 기본적으로 따른다. 또한, 국내 고유 알고리듬을 지원하기 위해 TTAS.IF-RFC3075 "확장성 생성 언어 전자서명 구문과 처리 (XML-Signature Syntax and Processing)" (한국정보통신기술협회, 2004년)에서 정의된 알고리듬을 이용한다.

본 발명에 따른 유통 프로토콜에서 이용하는 알고리듬 목록은 전자서명 NameSpace, 해시 (Digest), 전자서명(Signature), 정규화(Canonicalization), 변환(Transform)을 포함한다. 메시지 송수신 시 전자서명의 생성 및 검증 과정에서의 모호성을 최소화하기 위해서 다음 목록 이외의 알고리듬은 사용하지 않는 것이 바람직하다.

전자서명의 Namespace의 예제는 다음 표 15와 같다.

데이터를 축약하는데 이용하는 알고리듬으로 SHA1과 SHA256을 이용할 수 있으며, 예제는 다음 표 16과 같다. 단, HA1은 '공인인증서 암호체계 고도화'가 완전히 적용되는 시점인 2012년부터는 사용이 제한된다.

메시지 전자서명 시 사용되는 알고리듬은 RSAwithSHA1, RSAwithSHA256로서, 예제는 다음 표 17과 같다. 단, RSAwithSHA1을 이용하는 경우는 '공인인증서 암호체계 고도화'가 완전히 적용되는 시점인 2012년 부터는 사용이 제한된다.

논리적으로 동일한 문서에 대해 물리적으로 여러 가지 표현이 가능 방식한 XML의 특성으로 인해 같은 문서에 대해 전자서명 값이 다르게 나올 수 있으므로, 이러한 현상을 방지하기 위해 반드시 정규화(Canonicalization) 과정을 거쳐야 하며, 예제는 다음 표 18과 같다. 정규화는 주석 없는 정규 XML(Canonical XML, omits comments)을 사용한다.

전체 XML 데이터 중에서 실제 서명 대상이 되는 데이터를 가공하고 선택하는 과정을 거치는 알고리듬으로 다양한 변환 알고리듬이 존재하나 그 중에서 3가지만을 이용하도록 한다. 첫 번째는 전자서명이 서명 대상 내에 포함되는 형식을 따르므로 Enveloped Signature 변환이고, 두 번째는 상기 설명한 정규화(Canonicalization), 그리고 세 번째는 서명 대상 정보를 선택하는 XPath 필터링(XPath Filtering)이이며, 예제는 다음 표 19와 같다.

전자서명 구문의 구조는 도 24와 같으며, 상술한 방식대로 전자서명이 수행된 메시지 예제는 다음 표 20과 같다.

Errorlist 요소는 메시지를 수신하여 처리 과정을 수행할 때 오류가 발생하는 경우에만 Header 하위에 위치한다. ErrorList 요소가 생성되는 경우에는 반드시 MessageHeader 요소 내에 RefToMessageId가 존재해야 하며 RefToMessageId는 오류가 발생한 메시지의 MessageId를 지칭해야 한다. ErrorList 요소는 id 속성, OAP mustUnderstand 속성, version 속성, highestSeverity 속성, 한 개 이상의 Error 요소와 같은 속성들을 가지며, ErrorList의 구조는 도 25와 같다. 이때, 보고될 오류가 없으면 ErrorList 요소는 존재해서는 안 된다.

highestSeverity 속성은 모든 Error 요소들의 가장 심각한 상태를 표시한다. 특히, 어떤 Error 요소가 severity를 Error 라고 설정되어 있으면, highestSeverity는 Error로 설정되어야 하며, 그렇지 않은 경우에는 highestSeverity를 Warning으로 설정해야 한다.

Error 요소는 id 속성, codeContext 속성, errorCode 속성, severity 속성, location 속성, Description 속성을 가진다.

id 속성은 문서 내에서 ErrorList 요소를 유일하게 식별하는 역할을 한다.

codeContext 속성은 errorCodes의 네임스페이스 또는 스키마를 나타낸다. 이는 반드시 URI이어야 한다. 이 속성의 기본값은 urn:oasis:names:tc:ebxml-msg:service:errors이다. 이 속성에 기본 값이 없으면, 그 명세의 구현은 errorCodes를 사용한다는 것을 가리킨다.

필수 속성인 errorCode 속성은 오류를 가지고 있는 메시지의 오류가 지닌 본질을 지시한다. errorCode 의 유효한 값들과 코드의 의미는 아래에서 설명하도록 한다.

필수 속성인 severity 속성은 오류의 심각성을 나타내는 값으로서, 유효한 값들은 Warning, Error가 있는데, Warning은 오류가 존재하지만 대화 중의 다른 메시지들은 정상적으로 생성되고 있다는 것을 가리키며, Error는 복구 불가능한 오류가 메시지에 존재하고 대화 중 더이상 다른 메시지들은 생성되지 않는다는 것을 가리킨다.

location 속성은 오류가 존재하는 메시지 부분을 가리킨다. 만약에 오류가 ebXML 요소 내에 존재하고 요소가 “well-formed”라면, location 속성의 내용은 [Xpointer]이어야 한다.

Description 속성의 내용은 xml:lang 속성에서 정의된 언어로 오류의 서술적인 설명을 제공한다. 보통, 이것은 XML 파서나 메시지를 검증하는 소프트웨어가 생성한 메시지가 된다. 이 의미는 이 내용은 Error 요소를 생성했던 소프트웨어의 판매자나 개발자에 의해 정의된다는 것을 의미한다.

ErrorList의 예제는 다음 표 21과 같다.

유통 프로토콜을 기반으로 메시지를 송수신하는 과정에서 오류가 발생하면 오류를 인지한 송수신 개체는 상대방에게 오류 내용을 보고해야 하며, 보고해야 할 오류는 메시지 구조 오류, 신뢰메시징 오류, 보안 오류를 포함한다.

본 발명에서 정의하는 유통 프로토콜보다 하위 레이어에 속하는 HTTP 및 Socket과 같은 데이터 통신 프로토콜과 관련된 오류들은 데이터 통신 프로토콜에서 지원하는 표준 메커니즘에 의해 발견되고 보고되어야 하며, 본 발명에서 정의하는 오류 보고 메커니즘을 사용하지 않는다.

오류코드는 오류 대상 및 유형 별로 구분되며, 자세한 내용은 다음 표 22와 같습니다.

한편, SOAP Body 요소는 SOAP Envelope 요소의 두 번째 자식 요소이며, Manifest와 같은 확장 요소를 포함하며, Manifest는 페이로드 컨테이너 또는 웹과 같이 다른 장소에 위치한 데이터를 가리키는 요소이다.

Manifest 요소는 한 개 이상의 Reference 요소들로 구성된 복합 요소이다. 각 Reference요소는 페이로드 컨테이너에 담긴 페이로드 문서(들)의 일부로 포함되거나 URL로 접근 가능한 원거리의 자원인 메시지에 관련된 데이터를 식별한다. SOAP Body에는 페이로드 데이터를 싣지 않는 것이 바람직하며, Manifest의 목적은 XML 메시지와 관련된 특정한 페이로드를 쉽게 직접적으로 접근할 수 있게 하는 것과, 파싱 작업 없이도 어플리케이션이 페이로드를 처리할 수 있는지 판단할 수 있도록 하는 것이다.

Manifest 요소는 다음과 같은 한 개의 id 속성, 한 개의 version 속성 및 한 개 이상의 Reference 요소로 구성되어 있다.

Reference 요소는 0개 이상의 Schema 요소 및 0개 이상의 Description 요소를 포함하는 하위 요소들로 구성된 복합 요소이다. 이때, 0개 이상의 Schema 요소는 부모 Reference 요소에서 식별된 인스턴스 문서를 정의하는 스키마(들)에 대한 정보이며, 0개 이상의 Description 요소: 부모 참조 요소에 의해 Reference된 페이로드 객체에 대한 설명이다.

Reference 요소는 그 자체가 [XLINK]의 단순 링크이다. XLINK 프로세서 또는 엔진의 사용이 필수적이지는 않지만 구현 요구 사항에 따라 유용할 수 있다. Reference 요소는 위에서 제공된 요소의 내용과 더불어 id, xlink-type, xlink:href, xlink:role와 같은 속성 내용을 포함하고 있으며, 이 외에 다른 유효 네임스페이스인 속성들이 존재할 수 있으며, 수신 MSH는 위에서 정의한 것 외에 외부의 네임스페이스 속성들은 무시할 수 있다. 이때, id는 Reference 요소에 대한 XML ID이며, xlink-type은 XLINK 단순 링크로 요소를 정의하며 "simple"이라는 고정된 값을 가지며, xlink:href는 참조된 페이로드 객체의 URI 값이며 [XLINK] 명세의 단순 링크에 준하는 것이어야 한다. 그리고, xlink:role는 페이로드 객체나 그의 목적을 설명하는 자원을 식별하는 것으로서, 존재한다면 [XLINK] 명세에 준하는 유효한 URI 값을 가져야 한다.

Schema 요소는 참조하는 항목이 그 것을 기술하는 스키마(들)를 가지고 있다면 (예, XML Schema, DTD, 또는 Database Schema), 그 Schema 요소는 Reference 요소의 자식 요소로 존재해야 한다. 이는 스키마와 버전을 식별하는 방법으로 사용되며, 부모 Reference 요소에 의해 식별되는 페이로드 객체를 정의한다. Schema 요소는 location 및 version과 같은 속성을 가지고 있다. 이때, location은 스키마의 필수 URI이며, version은 스키마의 버전 식별자이다.

xlink:href 속성이 content id(URI scheme "cid")인 URI를 포함하고 있으면 그 content-id를 가지는 MIME은 메시지의 페이로드 컨테이너에 표현되어 있거나, 그렇지 않으면 errorCode를 MimeProblem으로, severity를 Error로 하는 오류를 발신당사자에게 전달해야 한다. xml:href 속성이 content id(URI scheme "cid")인 URI를 포함하고 있지 않으면 URI는 해석되지 못하고, 구현에 따라 오류를 전달해야 할지 말아야 할지 결정해야 한다. 오류가 전달되어야 한다고 결정되면 errorCode를 MimeProblem으로, severity를 Error로 하는 오류를 발신당사자에게 전달해야 한다.

아래의 표 23은 전형적인 한 개의 페이로드 MIME Body 부분을 가지는 메시지의 Manifest를 나타낸다.

③ HTTP 바인딩

HTTP를 통해 메시지를 전송하는 방안에 있어서 HTTP 바인딩 예제는 다음 표24와 같다.

본 발명에 따른 유통 프로토콜에서 HTTP 레벨의 응답 코드를 반환하기 위해서 [RFC2616]에 정의된 HTTP 응답 코드를 이용해야 하며, 주요 응답 코드는 다음표 25와 같습니다.

[전자문서 서식 등록기]

이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 전자문서 서식 등록기와 관련하여 상세히 설명하도록 한다.

전자문서 서식 등록기는 전자문서유통에서 송수신 개체가 문서를 유통하기 위해 필요한 서식을 생성, 등록, 관리할 수 있는 시스템이다.

전자문서 서식 등록기는 서식생성기, 서식등록기, 서식관리기 및 표준연계모듈로 구성된다.

서식생성기는 PDF 변환모듈과 PDF Form Designer로 이루어지며, PDF 변환모듈은 일반 서식을 PDF로 변환하는 기능(예 : 표준 PDF-A로 생성)을 제공하며, PDF Form Designer는 입력가능한 Form PDF를 생성할 수 있는 기능을 제공하고 2차원바코드 및 복사방지마크등의 문서보안기능을 제공한다.

서식등록기는 사용자가 서식(예 : 아래 한글, MS-Word등의 일반 서식)을 등록할 수 있는 기능을 제공한다.

서식관리기는 서식 관리자가 서식을 등록, 관리할 수 있는 기능을 제공하며, 카테고리별 등록, 버전별 이력관리기능 제공하고, 서식별 열람기간, 열람횟수, 인쇄횟수제어 등 설정기능 제공한다.

표준연계모듈은 유통 클라이언트 어플리케이션과 연계할 수 있는 기능을 제공하며, 서식 리스트, 검색기능 제공하고, 파일 다운로드 기능을 제공한다.

본 발명에 따른 전자문서 서식 등록기의 서식 등록 프로세스는 도 26과 같다.

표준전자문서는 Form designer를 이용하여 FormPDF로 생성하며, 필수 요건은 아래 표 26과 같다.

표준전자문서의 구조는 문서 하단에 5㎝ 정도의 공간 확보가 필요하며 바코드 크기는 데이터량에 따라 가변적이며, 복사방지마크 크기는 3 〉1.3로 하며 위치는 서식 모양에 따라 적절한 위치로 배치하며, 일 예는 도 27과 같다.

표준연계모듈(표준인터페이스)은 유통 클라이언트 어플리케이션에서 사용자가 서식을 검색하고 다운로드하여 서식을 생성할 수 있도록 하며, Web UI(User Interface)로 제공하여 유통 클라이언트 어플리케이션에서 포함될 수 있도록 하고, 카테고리별 검색, 서식 목록, 파일 다운로드 등의 기능을 제공한다.

[전자문서 패키징]

이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 전자문서 패키징과 관련하여 상세히 설명하도록 한다.

전자문서 패키징은 전자문서유통에서 송수신 개체가 문서를 유통하기 위해 필요한 메시징 시스템 규격이다.

전자문서 패키징은 표준전자문서, 첨부문서로 구성되어있으며 표준전자문서에 대한 메타데이터로 구성되어있다. 표준전자문서는 PDF-A를 기반으로 생성되며 메타데이터는 문서보안기능 등의 정보로 구성되어 있다. 첨부문서는 PDF로 변환하지 않고 원본 그대로 패키징한다.

표준전자문서는 사용자의 공인인증서로 전자서명하며 패키징 후 전자문서 패키지를 전자서명하여 패키지에 포함한다.

도 28에는 전자문서 패키지 구조를 도시하였는데, 이와 같은 도 28을 참조하면 본 발명에 따른 전자문서 패키지 구조는 패키지 헤더, 메타 데이터, 표준전자문서, 첨부문서, 전자서명 데이터를 포함하며, 각각의 세부 구성 요소는 아래 표 27 내지 표 31과 같다.

패키지 헤더는 패키지 전체 구조정보를 포함하며, 메타데이터는 표준전자문서의 문서보안기능의 정보를 포함하고 문서 열람횟수, 인쇄횟수, 2차원 바코드 정보 등의 정보를 포함하며, 표준전자문서는 표준 PDF-A 형식으로 구성되고 PDF 파일내 이미지 영역에 2D 바코드 데이터를 포함하며 표준 PDF Signed Data 영역에 전자서명데이터 포함하고, 첨부문서는 표준전자문서가 아닌 비정형문서이므로 문서보안기능 적용대상에서 제외하며 개별적 전자서명은 제외하며, 전자서명 데이터는 패키징된 데이터를 사용자의 공인인증서를 사용하여 전자서명하여 패키징에 포함한다.

전자문서 패키징을 검증하는 방안으로는 ① 전자문서 패키징 전자서명 검증 방안, ② 표준전자문서 검증 방안, ③ 인쇄된 전자문서 검증 방안이 있으며, 각 방안에 대하여 설명하면 다음과 같다.

① 전자문서 패키징 전자서명 검증 방안

- 클라이언트 App 는 전자서명 패키징을 처리할 때 전자서명을 검증하며 검증을 성공하였을 경우에만 표준전자문서를 전자문서뷰어로 전달한다.

- 또한, 수동 전자서명 검증 기능을 지원하여 분쟁 발생 시 전자서명 검증을 할 수 있도록 한다.

② 표준전자문서 검증 방안

- 전자문서뷰어는 표준전자문서를 열람할 때 전자서명검증을 수행하고 성공하였을 경우에만 전자문서뷰어에서 파일을 열람할 수 있도록 한다.

③ 인쇄된 전자문서 검증 방안

- 별도 제공되는 검증 프로그램과 평판 스캐너를 이용하여 2차원 바코드내 전자서명 데이터 검증 및 원본문서 내용과 인쇄된 문서의 내용을 육안 비교한다.

한편, 복사방지마크는 전자문서를 최종으로 받는 사용자의 프린터 패턴에 따라 생성해야하므로, 패키징에는 포함되지 않는다.

[유통 클라이언트 어플리케이션 ]

이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 유통 클라이언트 어플리케이션과 관련하여 상세히 설명하도록 한다.

기업 또는 개인들이 공인전자주소를 바탕으로 문서(정보)를 송수신하기 위해서는 이를 지원하기 위한 사용자 인터페이스(User Interface, 이하 UI라 함)를 제공하는 어플리케이션이 필요하다. 유통 메시징서버 시스템이 메시지를 주고받기 위한 메시징엔진으로서 이메일과 비교했을 때 메일서버와 같은 역할을 한다면, 유통 클라이언트 어플리케이션(이하, APP라 함)은 사용자가 이 메일서버와 연계하여 이메일을 주고받기 위해 제공되는 메일 클라이언트와 같은 사용자용 어플리케이션의 역할을 한다.

도 29에는 유통 클라이언트 APP의 구조도를 도시하였으며, 이와 같은 도 29를 참조하면 유통 클라이언트 APP는 유통 메시징서버 시스템을 이용해서 문서를 교환하고자 하는 일반 사용자를 위한 UI환경의 어플리케이션으로서 기본적으로 "① 사용자 인증", "② 메시지 작성", "③ 메시지 목록조회 및 상세내용 열람 기능", "④ 유통 메시징서버 시스템 연계"로 구성된다. 클라이언트 APP는 이와 같은 기본기능 외에 추가적으로 메시지 송수신 및 어플리케이션 관리를 위한 "⑤ 기본정보와 환경정보 관리", "⑥ 메시지 폴더 관리", "⑦ 문서 서식 관리", "⑧ 문서 작성기" 등의 기능을 제공할 수 있으나, 이는 어플리케이션 개발자에 의해 선택적으로 제공되는 기능이다.

① 사용자 인증

- 유통 클라이언트 APP이 유통 메시징서버 시스템과 연계되기 전에 유통 메시징서버 시스템은 사용자 계정을 확인한 후 로그인 세션 정보를 받아야 한다.

- 유통 클라이언트 APP가 사용자 인증을 받기 위한 방법으로는 인증서(공인 또는 사설 모두 허용)를 기반으로 한 사용자 인증 또는 ID/PW를 기반으로 한 사용자 인증 등이 있다.

② 메시지 작성 기능

- 유통 클라이언트 APP는 신규 메시지를 작성할 수 있는 사용자 인터페이스를 제공하여야 하며, 작성된 문서를 유통 메시징서버 시스템과 연계하여 수신 상대방에게 전달하여야 한다.

- 메시지 작성 기능은 메시지 전송하기 위해 유통 메시징서버 시스템의 전송인터페이스를 호출할 때, 필요한 기본정보들 중 환경정보에 의해 기 설정된 값이 아닌 항목은 입력을 할 수 있도록 제공하여야 한다.

③ 메시지 목록조회 및 상세내용 열람 기능

- 유통 메시징서버 시스템은 메시지를 송신메시지, 수신메시지로 구분하여 관리를 합니다. 유통 클라이언트 APP는 로그인된 사용자 계정을 기반으로 유통 메시징서버 시스템과 연계하여, 사용자 계정에 해당하는 각 메시지의 목록을 조회하는 기능과 메시지의 상세내용을 보고자 할 때 첨부문서를 포함하여 메시지의 상세정보를 모두 열람할 수 있는 기능을 반드시 제공하여야 합니다.

④ 유통 메시징서버 시스템 연계

- 유통 클라이언트 APP의 가장 중요한 기능이 유통 메시징서버 시스템과 연계하여 메시지를 송수신하는 기능이다. 유통 클라이언트 APP는 유통 메시징서버 시스템이 제공하는 메시지 송신기능과 수신메시지 읽음 인터페이스를 통해서 로그인한 계정을 기반으로 메시지를 전송하고 수신한다.

⑤ 기본정보와 환경정보 관리

- 클라이언트 APP는 메시지 전송 시 기본적으로 필요한 환경정보를 관리하는 기능을 제공하여야 한다. 유통 클라이언트 APP는 독립적으로 존재하는 어플리케이션이 아니므로 반드시 유통 메시징서버 시스템과의 연계를 통해 유통 기반인프라에 참여가 가능하다. 따라서 기본적으로 유통 메시징서버 시스템과의 연계를 위해 필요한 유통 메시징서버 시스템 연계정보(유통 메시징서버 시스템 주소정보)를 기본적으로 설정하고 관리하여야 한다.

- 그 외에 문서 서식 등록기와의 연계를 위한 등록기 서버 정보 관리나, 유통 클라이언트 APP의 시스템 환경에 대한 부가정보들 관리는 어플리케이션의 개발범위에 따라 정의하여 제공하면 된다.

⑥ 메시지 폴더 관리

- 유통 메시징서버 시스템이 관리하는 메시지는 송신, 수신메시지를 기본으로 분류하여 관리하며, 송수신 메시지는 각각 처리 상태에 따라 상태정보를 관리한다. 각 메시지의 상태정보로, 송신메시지는 송신 전, 송신완료, 송신실패, 담당자 수신완료의 상태를, 수신메시지는 검증오류, 수신 확인 전, 수신확인, 열람확인의 상태를 관리하며, 유통 클라이언트 APP는 유통 메시징서버 시스템이 제공하는 기본 상태정보를 바탕으로 메시지 폴더를 관리하여 사용자에게 제공한다.

- 유통 클라이언트 APP는 송수신 폴더를 기준으로 송신과 수신 메시지를 구분하여 유통 메시징서버 시스템이 제공하는 상태정보에 따라 사용자에게 각 메시지의 상태를 알려주는 것을 기본으로 제공하여야 한다. 그러나, 그 외에 임시보관함, 휴지통과 같은 지운 메시지함을 제공하거나 사용자가 직접 폴더를 정의하고 관리할 수 있도록 하는 기능을 제공하는 것은 어플리케이션 개발자의 선택사항이므로 본 발명의 설명에서는 생략한다.

⑦ 문서 서식 관리 기능

- 유통 메시징서버 시스템은 전송하는 메시지에 첨부되는 문서의 양식을 제한하지 않으므로 송수신 대상 문서로는 일반 텍스트파일부터, 오피스 파일, XML 문서, 멀티미디어 파일 등 어떠한 종류의 파일도 모두 가능하다. 그러나, 사용자들이 유통 클라이언트 APP를 업무에 활용하도록 편의를 제공하기 위해 기본적인 문서에 대해서는 서식 기반으로 문서 작성을 지원하는 기능을 부가적으로 제공하는 것이 가능하다. 유통 클라이언트 APP는 문서 서식 등록기에서 제공하는 문서서식을 등록기의 표준 인터페이스를 통해 검색하여 다운로드한 후, 다운로드한 문서서식을 기반으로 문서를 작성하고 이를 메시지에 첨부하여 보낼 수 있는 기능을 제공할 수 있다.

- 유통 클라이언트 APP는 전자문서 유통허브에서 제공하는 문서 서식 등록기와 연계하여 해당 문서 서식 등록기와 연계하여 문서서식을 관리할 수도 있으며, 독자적으로 문서 서식 관리체계를 구축하고 이 체계와 연계하여 문서 서식을 관리하는 방법이 있다. 전자문서 유통허브에서 제공하는 문서 서식 등록기와 연계하여 서식을 검색하고 다운로드 하는 방법에 대한 상세한 내용은 상술한 [전자문서 서식 등록기]에 대한 설명을 참조한다.

⑧ 문서 작성기

- 문서 작성기는 문서 서식 관리 기능을 통해 유통 클라이언트 APP가 다운로드한 서식을 기반으로 사용자들이 문서를 작성할 수 있도록 지원하는 작성기이다. 문서작성기는 전자문서 유통허브가 제공하는 문서 서식 등록기를 이용하는 경우에는 상술한 [전자문서 서식 등록기]에 대한 설명을 참조하여 설계하면 되며, 자체적으로 문서 서식 관리체계를 구축한 경우에는 해당 서식 관리체계에 따라 문서 작성기를 설계하면 된다.

상기와 같은 유통 클라이언트 APP의 가장 기본이 되는 프로세스로는 "① 문서 전송 프로세스", "② 문서 수신 프로세스"가 있으며, 부가적 프로세스로는 "③ 전자문서 서식 다운로드 프로세스"가 있다. 문서 전송 및 문서 수신을 위해 유통 클라이언트 AP는 서버가 되는 유통 메시징서버 시스템과 연계되며, 표준문서양식 등록을 위해서는 전자문서 서식 등록기 서버와 연계가 된다.

① 문서 전송 프로세스

유통 클라이언트 APP가 연계된 유통 메시징서버 시스템을 통해 타 “송수신 개체”에게 전자문서를 전송하는 단계는 도 30과 같으며, 처리 절차는 아래와 같다.

먼저, 유통 클라이언트 APP를 통해 수신자에게 전송할 메시지를 생성. 이 때 메시지는 이미 송신자가 작성한 문서를 첨부하거나, 유통 클라이언트 APP가 제공하는 문서작성기를 통해 작성한 문서를 첨부하여 수신자를 지정한 후 메시지를 생성한다.

다음으로, 수신자 주소정보를 입력한 후, 유통 메시징서버 시스템의 전송 인터페이스를 호출함으로써 메시지 전송을 요청한다.

다음으로, 전송자의 유통 메시징서버 시스템은 전송 프로세스에 따라 수신자에게 메시지를 전송한 후, 수신자로부터 수신에 대한 응답메시지(수신증명서 또는 수신오류)를 수신한다.

다음으로, 전송자의 유통 메시징서버 시스템은 수신에 대한 응답메시지를 수신한 후 유통 클라이언트 APP에 전송에 대한 응답으로 전달한다.

여기서, 첫번째~네번째 단계는 필수 절차이며, 두번째~네번째의 단계는 반드시 동기식으로 이루어져야 한다.

다음으로, 전송자의 유통 메시징서버 시스템이 수신자로부터 수신담당자의 열람을 확인 하는 열람증명서를 포함한 메시지를 받으면, 전송 유통 메시징서버 시스템은 수신에 대한 응답메시지를 돌려주고 수신 메시지를 해당 사용자의 사서함에 보관한다.

다음으로, 최초 전송자의 유통 클라이언트 APP은 연계된 유통 메시징서버 시스템에 수신문서를 요청한다.

다음으로, 전송자의 유통 메시징서버 시스템은 사서함에 보관된 수신 문서목록을 수신문서를 요청한 사용자의 유통 클라이언트 APP에 전달한다.

여기서, 다섯번째~일곱번째의 단계는 선택적 사항으로 최초 메시지 전송 시에 수신담당자의 열람 확인을 요청한 경우에만 발생되는 선택적 절차이다.

② 문서 수신 프로세스

유통 클라이언트 APP가 타 "송수신 개체"로부터 전자문서를 수신하는 프로세스는 도 31과 같으며, 처리 절차는 다음과 같다.

먼저, 수신자의 유통 메시징서버 시스템은 메시지를 수신하면, 수신한 메시지에 대한 수신 응답메시지를 수신자에게 돌려주고, 수신 메시지를 해당 사용자의 사서함에 보관한다.

다음으로, 수신자의 유통 클라이언트 APP은 연계된 유통 메시징서버 시스템에 로그인을 한 후 수신문서를 요청한다.

다음으로, 수신자의 유통 메시징서버 시스템은 수신문서를 요청한 사용자의 사서함에 보관된 수신 문서목록을 전달한다.

여기서, 두번째~세번째 단계는 동기식이다.

다음으로, 수신자가 수신메시지의 목록에서 메시지에 대한 상세정보 보기를 요청하면, 유통 클라이언트 APP는 유통 메시징서버 시스템에 해당 메시지의 첨부문서를 포함한 상세정보를 전달한다.

다음으로, 최초 전송자가 수신 담당자의 열람확인을 요청한 경우, 수신자의 유통 메시징서버 시스템은 사용자가 수신문서에 대한 상세정보요청을 한 시점에 해당 메시지의 송신자에게 열람증명서를 포함한 메시지를 전송한다.

다음으로, 수신자의 유통 메시징서버 시스템은 다섯 번째 단계에서 전송된 담당자 열람확인 메시지(열람증명서)에 대한 수신 응답메시지를 수신한다.

③ 전자문서 서식 다운로드 프로세스

유통 클라이언트 APP가 전자문서 서식을 다운로드하는 프로세스는 도 32와 같으며, 처리 절차는 다음과 같다.

먼저, 유통 클라이언트 APP는 전자문서 서식 등록기 서버에 직접 연계하여 문서서식에 대한 검색을 요청한다. 이때, 전자문서 서식 등록기 서버가 제공하는 표준 연계인터페이스 기반으로 연계한다.

다음으로, 전자문서 서식 등록기 서버는 검색된 문서 서식에 대한 정보를 결과로 돌려 준다.

이때, 첫번째~두번째 단계는 동기식이다.

다음으로, 유통 클라이언트 APP는 검색된 서식 목록을 사용자에게 보여줌으로써 사용자가 서식을 선택할 수 있도록 한다.

다음으로, 유통 클라이언트 APP는 전자문서 서식 등록기 서버에 선택된 전자문서 서식에 대한 다운로드를 요청한다.

다음으로, 전자문서 서식 등록기 서버는 요청 받은 서식을 유통 클라이언트 APP에 되돌려 준다.

다음으로, 유통 클라이언트 APP는 다운로드 받은 전자문서 서식을 등록하여 문서 작성기에서 사용할 수 있도록 Plug-In한다.

상기와 같은 유통 클라이언트 APP를 위해 유통 메시징서버 시스템이 제공하는 인터페이스 유형으로는 사용자 인증(로그인), 로그아웃, 메시지 전송요청, 수신메시지 Get, 메시지 상세정보 요청, 메시지 삭제가 있다.

유통 클라이언트 APP와 유통 메시징서버 시스템의 연계 방안(①~⑤)에 대하여 설명하면 다음과 같다.

① 유통 메시징서버 시스템의 연계 프로토콜

유통 메시징서버 시스템이 유통 클라이언트 APP를 위해 제공하는 연계 인터페이스는 유통 메시징서버 시스템의 송수신 프로토콜과 동일한 프로토콜을 기반으로 한다. 다만, 유통 메시징서버 시스템들 간에 송수신하는 경우와 달리, 유통 클라이언트 APP와 유통 메시징서버 시스템은 도 33과 같이 단방향(One-Way) 동기식 통신만을 제공하며, 둘 간에는 메시지에 대한 전자서명 인증 또는 사용자 인증 방식을 사용한다.

전송메시지는 유통 메시징서버 시스템의 메시지 구조를 그대로 활용하되, 사용자 정보 및 요청과 응답메시지는 도 34와 같은 구조로 구성되며, 상세한 설명은 다음과 같다.

- SOAP Header : 유통 클라이언트 APP 및 유통 메시징서버 시스템이 업무 유형에 따라 송신자 또는 수신자가 되어 상술한 [유통 프로토콜]에 따라 구성되며, messageHeader 및 Signature 정보로 구성된다.

- SOAP Body : 상술한 [유통 프로토콜]에서 정의한 Manifest 요소 정보 및 사용자 로그인 정보가 들어간다.

- 전송문서 컨테이너 #1 : 메시지 전송 요청, 수신 메시지 Get, 메시지 상세정보 수신의 경우 본문 문서(Contents)가 들어간다.

- 전송문서 컨테이너 #2 : 메시지 전송 요청, 메시지 상세정보 수신의 경우 첨부 문서가 #2부터 순차적으로 들어간다.

SOAP Header의 구조는 아래 표32와 같으며, MessageHeader의 구조는 아래 표33과 같고, SOAP Body의 구조는 아래 표34와 같으며, 본문 메시지의 구조는 아래 표35와 같다.

② 메시지 전송요청

메시지 전송 시에 유통 클라이언트 APP가 유통 메시징서버 시스템에 전달해야 하는 기본정보는 다음과 같다. 전송 완료된 후 사서함에 보관된 송신문서는 아래 표 36과 같이 4단계의 상태정보를 가진다.

요청 메시지의 예제는 아래 표 37과 같다.

응답 메시지의 예제는 아래 표 38과 같다.

③ 수신메시지 Get

유통 클라이언트 APP가 유통 메시징서버 시스템과 연계하여 로그인 한 사용자 계정으로 수신메시지를 읽어오는 행위와 유통 메시징서버 시스템에서 메시지를 삭제하는 행위는 분리가 되어 있다. 메시지 수신의 각 프로세스에 따라 다음과 같은 2단계의 상태정보를 관리해야 한다.

- 수신사용자가 사서함의 수신 문서 목록을 열람했는지 여부

- 수신사용자가 수신문서에 대한 상세내용을 열람했는지 여부

요청 메시지의 예제는 아래 표 39와 같다.

응답 메시지의 예제는 아래 표 40과 같다.

④ 메시지 상세정보 요청

수신한 문서목록을 기반으로 사용자가 상세내용을 열람하고자 하는 경우에 유통 클라이언트 APP는 유통 메시징서버 시스템의 메시지 상세정보를 요청한다. 상세정보를 요청 받은 유통 메시징서버 시스템은 메시지의 상세 속성정보와 해당 메시지의 첨부문서 등 모둔 메시지 내용을 유통 클라이언트 APP에 응답메시지로 전달한다.

요청 메시지의 예제는 아래 표 41과 같다.

응답 메시지의 예제는 아래 표 42과 같다

⑤ 메시지 삭제

유통 클라이언트 APP는 사용자가 삭제요청을 하는 경우에 유통 메시징서버 시스템에 해당 문서에 대한 삭제요청을 전달하고 그 결과를 사용자에게 알려주어야 한다. 사용자의 삭제 시 휴지통 개념의 임시 삭제 기능 부여 여부는 실제 서버상에서의 행위가 아니라 유통 클라이언트 APP의 부가기능이므로 유통 클라이언트 APP 개발자가 제공여부를 결정할 수 있으나, 최종적으로 유통 메시징서버 시스템에 삭제 요청을 하는 기능은 반드시 제공되어야 한다.

요청 메시지의 예제는 아래 표 43과 같다.

응답 메시지의 예제는 아래 표 44와 같다.

[기록매체]

한편, 상술한 본 발명에 따른 전자문서 유통 방법은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록 매체를 이용하여 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 컴퓨터로 읽을 수 있는 기록 매체는 마그네틱 저장 매체(예 : ROM, 플로피 디스트, 하드 디스크, 자기 테이트 등), 광학적 판독 매체(예 : CD-ROM, DVD, 광데이터 저장 장치 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장 매체를 포함한다.

101 : 송수신 개체 102 : 전자문서 유통허브
103 : 공전소 104 : 행정기관

Claims

전자문서를 유통하는 시스템에 있어서,
전자주소체계를 기반한 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체; 및
디렉터리 서버를 통해 등록 및 관리되는 고유식별자를 가진 전자주소체계를 이용하는 전자문서 유통허브;
를 포함하는 것을 특징으로 하는 전자문서 유통 시스템.
제 1 항에 있어서, 상기 송수신 개체의 유통 메시징서버는,
송수신 개체를 사용하는 사용자에게 상기 디렉터리 서버와의 연계 인터페이스를 사용하여 전자주소 검색과 등록과 변경 서비스를 제공하고,
메시지 송신 시에는 신뢰성을 가진 인증 및 보안 수단을 통해 전송 메시지에 대한 보안을 수행하고,
메시지 수신 시에는 수신한 메시지에 대하여 검증을 수행하여 검증에 통과한 경우에만 수신확인 메시지를 송신자에게 전송하고 통과하지 않은 경우에는 오류 메시지를 송신자에게 전송하며, 수신한 메시지는 사용자별로 저장 및 관리하며,
메시지 송수신에 대한 이력 정보를 보관 및 관리하는 것을 특징으로 하는 전자문서 유통 시스템.
제 1 항에 있어서, 상기 송수신 개체의 유통 메시징서버에서 발급된 유통증명서를 수신한 송수신 개체는 해당 유통증명서를 신뢰할 수 있는 제3자 보관기관을 활용하여 보관하는 것을 특징으로 하는 전자문서 유통 시스템.
제 1 항에 있어서, 상기 송수신 개체의 유통 메시징서버는 메시지 송신을 시도하였으나 실패한 경우에 전자문서 유통허브에 메시지 전송을 의뢰하며, 메시지 전송 의뢰를 받은 전자문서 유통허브는 송신증명서를 발급하여 메시지 전송을 의뢰한 송수신 개체로 전달하고 메시지 전송을 대행하는 것을 특징으로 하는 전자문서 유통 시스템.
제 1 항에 있어서, 상기 송수신 개체는 송수신 개체를 사용하는 사용자가 유통 메시징서버를 통해 메시지를 송수신할 수 있도록 하는 사용자 인터페이스인 유통 클라이언트 어플리케이션을 구비하며,
상기 유통 클라이언트 어플리케이션은 송수신 개체를 사용하는 사용자에게 사용자 인증, 메시지 작성, 메시지 목록 조회 및 상세 내용 열람을 수행할 수 있도록 하는 것을 특징으로 하는 전자문서 유통 시스템.
제 5 항에 있어서, 상기 유통 메시징서버가 유통 클라이언트 어플리케이션에게 제공하는 인터페이스 유형은, 사용자 인증, 로그 아웃, 메시지 전송 요청, 수신 메시지 겟(Get), 메시지 상세 정보 요청, 메시지 삭제를 포함하는 것을 특징으로 하는 전자문서 유통 시스템.
제 1 항에 있어서, 상기 전자문서 유통허브는 송수신 개체를 사용하는 사용자가 전자문서 생성을 용이하게 수행할 수 있도록 하는 문서 서식의 등록, 검색, 다운로드, 삭제를 포함하는 관리를 지원하는 전자문서 서식 등록기를 추가로 구비하며,
상기 전자문서 서식 등록기는, 문서 양식을 관리하는 서버 엔진; 및 송수신 개체를 사용하는 사용자가 문서 양식을 검색하고 다운로드 받아서 사용할 수 있도록 하는 표준인터페이스; 를 포함하는 것을 특징으로 하는 전자문서 유통 시스템.
제 7 항에 있어서, 상기 송수신 개체는 송수신 개체를 사용하는 사용자가 유통 메시징서버를 통해 메시지를 송수신할 수 있도록 하는 사용자 인터페이스인 유통 클라이언트 어플리케이션을 추가로 구비하며,
상기 유통 클라이언트 어플리케이션을 사용하는 사용자는 상기 전자문서 서식 등록기의 표준인터페이스를 통해 문서 서식을 검색하고 다운로드 받은 후에, 해당 문서 서식을 이용하여 전자문서를 생성하는 것을 특징으로 하는 전자문서 유통 시스템.
송신자 또는 수신자의 역할을 하는 송수신 개체와 전자문서 유통허브를 포함하는 전자문서 유통 시스템에서 전자문서를 유통하는 방법에 있어서,
(a) 송신자는 수신자의 전자주소 정보를 획득하는 단계;
(b) 송신자는 송신할 문서를 미리 정해진 메시지 구조체로 패키징한 메시지를 생성한 후에 수신자의 전자주소로 전송하는 단계;
(c) 상기 (b)단계에서 전송 실패한 경우에, 송신자는 전자문서 유통허브에 메시지 전송을 의뢰하며, 메시지 전송 의뢰를 받은 전자문서 유통허브는 송신증명서를 발급하여 송신자에게 전달한 후에 메시지 전송을 대행하는 단계;
(d) 수신자는 송신자 또는 전자문서 유통허브로부터 수신한 메시지를 검증하여 검증이 통과되면 수신한 메시지에서 문서를 추출하고 수신증명서를 발급하여 송신자에게 전달하는 단계;
(e) 송신자는 전달받은 수신증명서를 신뢰할 수 있는 제3자 보관기관을 활용하여 보관하는 단계; 및
(f) 수신자는 추출한 문서를 문서 담당자에게 전달하는 단계;
를 포함하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (a)단계 전에는,
(g) 송신자 및 수신자는 문서 유통을 위한 유통 메시징서버를 구축할지, 3자 유통이 가능한 유통 메시징서버를 보유한 송수신 개체를 이용할지에 대하여 결정하는 단계;
(h) 상기 (g)단계에서 문서 유통을 위한 유통 메시징서버를 구축할 것이라고 결정한 경우에는, 송신자 및 수신자는 문서 유통을 위한 유통 메시징서버를 구축한 후에, 인증 기관을 통해 유통 메시징서버의 인증테스트를 수행하고, 전자문서 유통허브의 주소 디렉터리 서버에 접속한 후 송수신 개체로서의 전자주소를 발급받은 후에, 내부의 실 사용자를 위해 자체적으로 내부 구분자를 등록하고 관리하는 단계;
(i) 상기 (g) 단계에서 3자 유통이 가능한 유통 메시징서버를 보유한 송수신 개체를 이용할 것이라고 결정한 경우에는, 송신자 및 수신자는 3자 유통이 가능한 유통메시징서버를 통해 전자주소 개설을 요청한 후에, 전자주소 정보를 전자문서 유통허브의 주소 디렉터리 서버에 등록하는 단계; 및
(j) 상기 (h)단계 또는 (i)단계 후에 상기 송신자는 전자문서 유통허브의 전자문서 서식 등록기에서 문서 서식을 검색하고 다운로드 받아서 등록하는 단계;
를 포함하며,
상기 (b)단계 전에는, 송신할 문서를 선택하거나 또는 상기 (j)단계에서 등록한 문서 서식을 이용하여 송신할 문서를 작성하는 하는 (k)단계가 추가로 수행되는 것을 특징으로 하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (b)단계에서 송신자는 패키징한 메시지에 대해 유통 메시징서버를 통해 보안 및 인증을 수행하며,
상기 (c)단계에서는 메시지의 패키징 구조, 전자서명에 대한 유효성, 송신자에 대한 적합성을 검증함으로써 메시지를 검증하는 것을 특징으로 하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (c)단계에서 송신증명서는 증명서 식별자, 증명서 생성시각 및 만료시각, 유통증명서 정책, 유통증명 대상 정보를 포함하며,
상기 유통증명 대상 정보는 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 문서 송신의뢰 시각을 포함하는 것을 특징으로 하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (d)단계에서 수신자가 생성한 수신증명서는 송신자에게 전달되거나, 또는 전자문서 유통허브로부터 메시지를 전송받았을 경우에는 전자문서 유통허브를 통해 송신자에게 전달되는 것을 특징으로 하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (d)단계에서 수신 증명서는 증명서 식별자, 증명서 생성시각 및 만료시각, 유통증명서 정책, 유통증명 대상 정보를 포함하며,
상기 유통증명 대상 정보는 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 문서 송신 시각, 문서 수신 시각을 포함하는 것을 특징으로 하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (d)단계에서 수신자는 수신한 메시지를 검증하여 검증이 통과되지 않으면 오류 메시지를 송신자에게 전달하는 것을 특징으로 하는 전자문서 유통 방법.
제 9 항에 있어서, 상기 (b)단계에서 송신자가 열람(=수신확인)증명서를 요청한 경우에,
상기 (f)단계 이후에는, 수신자가 해당 문서의 문서 담당자가 열람을 한 시점에 열람증명서를 발급하여 송신자에게 전달하는 단계가 추가로 수행되는 것을 특징으로 하는 전자문서 유통 방법.
제 16 항에 있어서, 상기 열람증명서는 증명서 식별자, 증명서 생성시각 및 만료시각, 유통증명서 정책, 유통증명 대상 정보를 포함하며,
상기 유통증명 대상 정보는 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 문서 송신 시각, 문서 수신 시각, 문서 수신확인 시각을 포함하는 것을 특징으로 하는 전자문서 유통 방법.
컴퓨터로 판독 가능한 기록매체에 있어서,
제 9 항 내지 제 17 항 중 어느 한 항에 따른 방법을 구현하는 프로그램이 저장되는 기록매체.