KR20090031588A - 마이크로지불 트랜잭션을 관리하는 방법 - Google Patents

마이크로지불 트랜잭션을 관리하는 방법 Download PDF

Info

Publication number
KR20090031588A
KR20090031588A KR1020097001501A KR20097001501A KR20090031588A KR 20090031588 A KR20090031588 A KR 20090031588A KR 1020097001501 A KR1020097001501 A KR 1020097001501A KR 20097001501 A KR20097001501 A KR 20097001501A KR 20090031588 A KR20090031588 A KR 20090031588A
Authority
KR
South Korea
Prior art keywords
seller
token
wallet
customer
equipment
Prior art date
Application number
KR1020097001501A
Other languages
English (en)
Inventor
알랭 뒤랑
Original Assignee
톰슨 라이센싱
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 톰슨 라이센싱 filed Critical 톰슨 라이센싱
Publication of KR20090031588A publication Critical patent/KR20090031588A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3572—Multiple accounts on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor

Abstract

본 발명은 적어도 하나의 중개인(1), 적어도 하나의 고객(2) 및 적어도 하나의 상품
서비스의 판매인(3)을 포함하는 마이크로지불 트랜젝션을 관리하는 시스템 및 방법에 관한 것이고, 여기서 상기 트랜젝션은 토큰의 교환을 구현한다.
본 발명에 따르면, 각각의 상기 고객(2)은 적어도 하나의 주 지갑 및 적어도 하나의 보조 지갑에 대응하는, 토큰을 저장하는 사용가능한 적어도 2개의 별도의 제 1 영역을 가지고, 상기 주 지갑은 상기 중개인(1)에 의해 상기 고객(2)에게 공급되는 토큰을 포함할 수 있고, 상기 보조 지갑은 상기 적어도 하나의 판매인(3)에 의해 상기 고객(2)에게 공급되는 토큰을 포함할 수 있다.

Description

마이크로지불 트랜잭션을 관리하는 방법{METHOD FOR MANAGING MICROPAYMENT TRANSACTIONS}
본 발명의 기술 분야는 마이크로지불 트랜젝션 관리 분야이다.
더 상세하게는, 본 발명은 적어도 하나의 중개인, 적어도 하나의 고객 및 적어도 하나의 상품 및/또는 서비스의 판매인을 구현하는 마이크로지불 트랜젝션을 관리하는 시스템 및 방법에 관한 것이다.
본 명세서에서 마이크로지불은 예를 들면 수 부분의 상팀(centime)부터 수십 또는 수백 프랑의 제한된 양(또는 임의의 다른 환율에서의 제한된 양)의 지불을 의미하고자 이해되어야 한다. 특히 전자 트랜젝션 통화를 구성하는 토큰(token)의 교환을 구현할 수 있다.
예를 들면 월드와이드 인터넷 네트워크 같은 통신 네트워크에 의해 구현된 마이크로지불 및/또는 매크로지불(macropayment) 트랜젝션을 위한 시스템의 출현은 이러한 트랜젝션의 과정에서 교환되는 정보의 보안에 관한 문제점 뿐만 아니라 고객과 판매인간의 트랜젝션의 보안에 관한 문제점을 야기하였다.
특히, 트랜젝션 보안의 주요한 문제점 중 하나는, 시스템의 판매인 및/또는 고객이 토큰(또는 다른 임의의 통화 단위)을 복사하여, 그것을 2개의 별도의 트랜젝션을 위해 부정하게 사용할 가능성이 있다는 것이다.
전자 트랜젝션을 관리하는 많은 시스템들이 이러한 보안 문제를 해결하기 위해 또는 적어도 이러한 트랜젝션의 보안을 개선시키기 위해 제안되었다. 이러한 시스템들은 예를 들면 Donal O'Mahony, Michael Peirce 및 Hitesh Tewari 공저의 Artech House에 의해 1997년에 발행된 논문 "전자 지불 시스템(Electronic Payment Systems)" 에 설명되어 있다.
이 논문은, 한편으로는, 예를 들면 DigiCash(등록상표) 회사에 의해 개발된 Ecash 시스템, CAFE 프로젝트(유럽을 위한 조건부 엑세스를 대표함) 또는 NetCash CyberCoin 또는 Mondex(등록 상표) 시스템 같은, 현금에 의한 전자 지불을 위한 시스템사이에서 구별짓는다.
다른 한편으로는, Millicent, SubScrip, Payword, MicroMint 같은 특정 마이크로지불 시스템 또는 추가로 iKP(등록 상표) 같은 마이크로지불 프로토콜을 언급한다.
현존하는 모든 현금-기반의 전자 지불 시스템에서는, 트랜젝션의 보안은 대칭성 및 비대칭성 모두의 암호화기법을 강력히 사용함으로써 구현된다. 따라서, 예를 들면 Ecash 시스템(등록 상표)에서, 많은 암호 해독 연산과 관련된 은행 및/또는 중개인의 많은 암호화된 서명이 구현되어, 시스템 주위를 흐르는 각 토큰이 한번 즉 오직 한번만 사용된다는 것이 증명된다. 또한 은행 및/또는 중개인은, 각각의 트랜젝션의 과정에서, 토큰의 일련 번호를 시스템에 의해 발행된 모든 토큰의 일련 번호가 포함된 풍부한 데이터베이스와 비교함으로써, 토큰의 유효성에 대한 체계적인 검증을 수행한다.
그러므로 이러한 종래 기술의 단점은, 트랜젝션의 보안이 매우 많은 연산과 암호화를 구현함으로 인해 보장되고, 이것은 시스템에 과부하가 생기게하고 비용이 들게 하므로 마이크로지불 트랜젝션에 적절하지 못하다는 것이다.
이러한 종래 기술의 또다른 단점은, 시스템에 의해 발행되는 토큰의 모든 일련 번호를 포함하는 상당한 데이터베이스를 관리할 필요가 있고 이것은 비용이 많이 들고 복잡하다는 것이다.
CAFE 프로젝트(유럽을 위한 조건부 엑세스를 대표함)에서, 예를 들면 트랜젝션의 보안은 임의의 위조에 강한 단말기의 구현에 의해 및 복잡한 암호화기법에 의해 보장된다. 은행 및/또는 중개인의 이익을 보호하는 옵저버(observer)가 각 고객의 지갑(wallet)에 통합된다. 옵저버의 역할은 고객에 의해 수행된 모든 트랜젝션의 유효성을 보장하여, 고객이 옵저버의 동의를 획득하지 않고는 트랜젝션을 구현하지 못하게 하는 것이다.
이러한 종래 기술의 단점은, NetCash, CyberCoin 또는 Mondex(등록 상표) 같은 현금에 의한 다른 전자 지불 시스템과 마찬가지로, 구현되는 암호화기법이 부담이 되고, 사용되는 단말기가 복잡하여 마이크로지불 트랜젝션에 적절하지 못하다.
논문 "전자 지불 시스템" 은 또한 마이크로지불 트랜젝션을 관리하는 시스템을 제공한다.
Millicent(등록 상표)라 불리는 시스템은 고객, 판매인, 및 중개인의 3개의 참가자를 구현한다. 한명의 주어진 판매인에 특정된 토큰은 마이크로지불 트랜젝션의 과정중에 교환된다. 고객은 주어진 유형의 토큰을 얻을 수 있고, 이 토큰에 의해 고객은 매크로지불을 위한 교환에서 중개인을 통해 특정 판매인에게 지불할 수 있다. 이러한 토큰은 그 후 고객의 지갑(purse)에 저장된다.
SubScrip(등록 상표)라 불리는 마이크로지불 트랜젝션 관리 시스템은, 이와 다르게, 어떤 은행이나 중개인도 포함하지 않는다. 고객은 주어진 판매인과 임시 사전지불된 구좌를 만드는 매크로지불 과정을 사용한다.
이러한 2가지 종래 기술의 단점은 한명의 고객과 복수의 판매인사이에 구현되는 트랜젝션에는 적절하지 않다는 것이다. 상세하게, Millicent(등록 상표)시스템에서, 고객은 그가 상품 및/또는 서비스를 구매하고자 하는 판매인의 수만큼 상이한 토큰을 획득하여야 한다. 유사하게, SubScrip(등록 상표)시스템에서, 고객은 그가 마이크로지불 트랜젝션을 수행하려고 하는 각각의 판매인과 사전지불된 구좌를 만들어야 한다.
PayWord(등록 상표)시스템은, 사후에 판매인들에 대한 지불을 보장하는, 중개인 및/또는 은행에 대해, 고객에게 입금 인증서(credit authentication)를 수여함으로써 이러한 단점을 완화시킨다.
종래 기술의 이러한 단점은 트랜젝션의 보안의 결여이고, 특히 중개인 및/또는 은행의 견지에서, 고객이 그의 은행 구좌에 필요한 자금을 가지지 않고도 많은 양의 구매가 고객에 의해 동작가능하다는 것이 명백하다.
iKP 마이크로지불 트랜젝션 관리 프로토콜에서, 트랜젝션의 보안은, 다른 트랜젝션 이전에, 특히 고객과 판매인과의 인증에 의해, PayWord(등록 상표)시스템에 비해 개선된다.
이러한 기술의 단점은 그러한 인증이 많은 메시지 교환을 필요하게 하고, 이것은 부담이 되고 프로토콜의 속도를 저하시키며 트랜젝션의 비용이 많이 들게 한다.
MicroMint 시스템의 마이크로지불 트랜젝션의 효율성은 iKP(등록 상표)프로토콜보다 더 높지만, 이러한 효율성은 마이크로지불 트랜젝션 보안의 희생으로 달성된다. 중개인 및/또는 은행은 토큰을 고객에게 공급하고, 이러한 토큰은 모든 판매인에게 사용될 수 있다. 트랜젝션의 과정중 토큰의 유효성에 대해 아무런 검증도 수행되지 않고, 이것은 동일한 토큰의 반복적인 사용을 허용한다.
그러므로, 이러한 종래 기술의 단점은, 고객에 대해서도 판매인에 대해서도 트랜젝션이 안전하지 않아서, 판매인은 지불로서 이전에 이미 사용된 유효하지 않은 토큰을 받을 수도 있다는 것이다.
그러므로 다양한 보안 레벨과 복잡도를 가지는, 많은 마이크로지불 트랜젝션 관리 시스템 및 방법이 존재하고, 여기서 고객은 전자 지갑 또는 입금 인증서 또는 판매인에 대해 만들어진 사전지불된 구좌가 제공된다. 그러나, 구현하기 간단하고, 트랜젝션의 다양한 참가자(중개인, 고객, 판매인)의 견지에서 만족스런 보안도를 가지는 시스템이나 프로토콜은 현재 알려져 있지 않다.
본 발명의 목적은 특히 이러한 종래 기술의 단점을 완화하는 것이다.
좀더 상세하게, 본 발명의 목적은 간단하고, 사용하기 쉽고, 구현하는데 비용이 많이 들지 않는 마이크로지불 트랜젝션 관리 시스템 및 방법을 제공하는 것이다.
이를 위해, 본 발명은 적어도 하나의 중개인, 적어도 하나의 고객 및 적어도 하나의 상품 및/또는 서비스의 판매인을 포함하는 마이크로지불 트랜젝션을 관리하는 시스템에 관한 것이고, 상기 트랜젝션은 토큰의 교환을 구현한다.
본 발명에 따르면, 그러한 시스템에서, 상기 각각의 고객은 토큰을 저장하기위한 사용가능한 적어도 2개의 별도의 영역을 가지고, 이러한 영역은 2개의 고객 지갑{하나는 주 지갑(main purse)이고 다른 하나는 보조 지갑(secondary purse)}에 해당하는 저장 영역이다. 주 지갑은 중개인에 의해 고객에게 공급된 토큰을 포함할 수 있고, 보조 지갑은 판매인에 의해 고객에게 공급된 토큰을 포함할 수 있다.
따라서 본 발명은 마이크로지불 트랜젝션의 관리에 대해 전적으로 신규하고 창작적인 접근법에 기초한다. 상세하게, 이에 따라 고객은, 토큰을 저장하기 위한 그리고 유효성이 확인된 토큰을 포함하는 신뢰 영역(reliable area) 및 토큰을 저장하기 위한 크레딧-유사 영역(credit-like area)이 제공되고, 이러한 크레딧(credit)은 하나이상의 판매인에 의해 고객에게 수여되고, 판매인(들)과 수행되 는 트랜젝션에 관한 정보를 추가로 포함할 수 있다.
따라서 트랜젝션 보안은 고객에 대해 향상될 수 있어서, 고객은 예를 들면 토큰이 부정하게 복사되어 판매인에 의해 두 번 사용되는 염려 없이, 유효한 토큰 자원 즉 고객의 주 지갑이 제공된다는 확신을 할 수 있다. 또한 고객은 유익하게 그가 하나이상의 판매인에게 사용할 수 있는 크레딧에 해당하는 보충적 토큰 자원 즉 그의 보조 지갑을 제공받는다.
본 발명의 유익한 특징에 따라서, 상기 각각의 판매인은 토큰을 저장하기 위한 사용가능한 적어도 2개의 상이한 영역을 가진다.
바람직하게, 판매인의 토큰을 저장하는 적어도 하나의 제 1 영역은 판매인의 지갑에 대응하고, 판매인의 토큰을 저장하는 적어도 하나의 제 2 영역은 판매인의 예금 파일(deposit file)에 대응한다. 판매인의 지갑은 중개인에 의해 판매인에게 공급되는 토큰을 포함할 수 있고, 예금 파일은 고객에 의해 판매인에게 공급되는 토큰을 포함할 수 있다.
따라서, 판매인의 지갑에서, 중개인으로부터 온 토큰은 고객(들)에 의해 공급된 토큰과 분리되어서, 판매인의 지갑의 내용물의 유효성이 보장되고 이에 따라 트랜젝션의 보안이 개선된다.
본 발명은 또한 전술한 시스템에서의 마이크로지불 트랜젝션을 관리하는 프로세스에 관한 것이다.
본 발명의 하나의 양상에 따르면, 판매인으로부터 고객에 의해 획득된 상품 및/또는 서비스에 대한 지불 과정에서, 고객은 상품 및/또는 서비스의 가격에 대응 하는 제 1 토큰의 수(P)를 판매인에게 보낸다:
- 만약 주 지갑이 P 이상의 토큰의 양을 포함한다면, 상기 제 1 토큰 수는 상기 고객의 토큰을 저장하는 제 1 영역으로부터 나오고, 상기 제 1 영역은 상기 고객의 주 지갑에 대응하고, 상기 중개인에 의해 공급되는 토큰을 포함할 수 있고;
만약 상기 주 지갑이 P 이하의 양인 X 개의 토큰을 포함한다면, 고객은 상기 주 지갑으로부터 나오는 X 개의 토큰 및 상기 고객의 토큰을 저장하는, 상기 고객의 보조 지갑에 대응하고 상기 판매인에 의해 공급되는 토큰을 포함할 수 있는, 제 2 영역으로부터 나오는 P-X 개의 토큰을 보내며,
상기 판매인은 토큰을 저장하는 상기 판매인의 제 2 영역에 보내진 제 1 개수(P)의 토큰을 저장하고, 상기 제 2 영역은 상기 예금 파일에 대응한다.
따라서 고객은 그가 중개인으로부터 획득한 토큰의 사용에 대해 우선권을 주어 판매인에게 지불하지만, 그는 또한 판매인의 지갑에서 사용할 수 있는 입금을 나타내는, 제 2 지갑에 포함된 토큰에 의해 일부 또는 전체를 지불할 수 있다. 고객에 의해 판매인에게 공급되는 토큰의 유효성이 보증되지 않으면, 판매인은 받은 그의 토큰을 그의 지갑에 저장하지 않고 예금 파일에 저장한다.
본 발명의 유익한 실시예에서, 판매인이 상기 고객에게 합산액을 상환하고자 하면, 상기 방법은 이하의 단계:
- 상기 합산액에 대응하는 제 2 개수의 토큰을 상기 판매인의 지갑에 대응하는 상기 판매인의 제 1 저장 영역으로부터 인출하는 단계;
- 상기 고객의 상기 보조 지갑의 토큰에 추가된, 상기 제 2 개수가 미리결정 된 최대값을 초과하지 않음을 검증하는 단계;
- 상기 최대값을 초과하지 않는 경우, 상기 고객의 상기 보조 지갑에 상기 제 2 개수를 저장하는 단계; 그렇지 않으면:
- 상기 프로세스를 중단하고, 매크로지불 프로세스를 구현함으로써 상기 고객에 상환하는 단계; 또는
- 재상환될 수 있도록 상기 고객에게 상기 고객의 보조 지갑 를 비우도록 요청하는 메시지를 발송하는 단계로 구성된다.
따라서, 이러한 상환 트랜젝션은, 한편으로는 판매인의 지갑으로부터 추출된 토큰의 사용을 통해(따라서 고객은 판매인으로부터 받은 토큰의 유효성을 확신한다), 다른 한편으로는 받은 토큰을 고객의 보조 지갑에 저장하는 것을 통해(주 지갑은 그 유효성이 중개인에 의해 직접 보증된 토큰에 대해 예약된 상태로 남아있다), 보안이 지켜진다.
또한, 본 발명은 유익하게 고객의 보조 지갑에 저장될 수 있는 토큰의 최대수가 제한되도록 제공함으로써, 주어진 고객에 대해 판매인(들)에 의해 인정되는 입금액을 제한한다. 그러므로, 그러한 배치는 판매인에 의해 초래되는 위험을 감소시키고 특히 부정한 지불의 위험을 감소시킬 수 있다.
유익하게, 그러한 프로세스는 고객의 보조 지갑으로부터 주 지갑으로 토큰을 전송하는 단계를 추가적으로 포함하고, 상기 토큰을 전송하는 단계는 이하의 하위 단계:
- 상기 고객이 상기 중개인에게 상기 보조 지갑에 포함된 상기 토큰을 상기 주 지갑으로 전송하도록 요청하는 단계;
- 상기 중개인은 한편으로는 상기 고객의 상기 요청의 유효성을 검증하고, 다른 한편으로는 상기 보조 지갑에 포함된 상기 토큰의 유효성을 검증하는 단계;
- 상기 유효성이 검증되면, 상기 중개인이 상기 보조 지갑으로부터 상기 주 지갑으로 상기 토큰을 전송하는 단계를 포함한다.
따라서, 본 발명에 따라서, 보조 지갑으로부터 주 지갑으로 토큰을 전송하는 그러한 단계는 항상 중개인에 의해 토큰을 확인함으로써 달성된다. 본 발명의 바람직한 실시예에 따라서, 그러한 전송 단계는 고객과 중개인사이의 각 트랜젝션 과정에 구현되고, 이는 판매인(들)에 의해 공급되는 토큰의 유효성에 대한 정기적 검증을 보증하기 때문이다.
바람직하게, 고객이 중개인으로부터 토큰을 구매하고자 할 때, 상기 프로세스는 이하의 단계:
- 상기 중개인이 상기 주 지갑으로 상기 구매된 토큰을 보내는 단계;
- 상기 보조 지갑은 토큰을 포함하고, 상기 중개인은 상기 토큰의 유효성을 검증하여, 상기 토큰이 유효하면 상기 토큰을 상기 보조 지갑으로부터 상기 주 지갑으로 전송하는 단계를 포함한다.
유익하게, 판매인이 그의 지갑에서 미리결정된 정수인 N 개의 토큰의 값만큼 차변기입(debit)하여 상기 값을 상기 판매인의 은행 구좌에 입금시키고자 할 때, 상기 방법은 이하의 단계:
- 상기 중개인은 상기 판매인의 상기 지갑이 적어도 N 개의 토큰을 포함하는 지를 검증하는 단계;
- 상기 검증 단계가 수행되고 상기 예금 파일이 미리결정된 정수인 M 개의 토큰을 포함하면, 상기 중개인은 N+M 개의 토큰의 값만큼 상기 판매인의 은행 구좌에 입금하고, 상기 예금 파일을 비우며, 상기 판매인의 상기 지갑으로부터 N 개의 토큰을 제거하는 단계를 포함한다.
따라서, 판매인에 의해 요청되는 동작에 추가하여, 중개인은 체계적으로 검증 단계 및 예금 파일을 비우는 단계를 수행하고, 이것은 판매인에 대해 특히 유익하다.
바람직하게, 고객이 주 지갑에 포함된 적어도 하나의 토큰의 값만큼 고객의 은행 구좌에 입금되고자 하고, 보조 지갑은 적어도 하나의 토큰을 포함할 때, 상기 중개인은 상기 보조 지갑에 포함된 상기 적어도 하나의 토큰의 유효성을 검증하는 단계를 수행하여, 유효하다고 검증된 경우, 상기 보조 지갑으로부터 상기 주 지갑으로 상기 적어도 하나의 토큰을 전송한다.
따라서, 고객에 의해 요청되는 동작에 추가하여, 중개인은 주 지갑에 그 돈 주머니의 내용물을 전송하기 위해 자동적으로 보조 지갑의 내용물을 검증하고, 이것은 고객에 대해 유익하다.
본 발명의 유익한 실시예에 있어서, 중개인, 판매인 및 고객은 각각 한 쌍의 비대칭 키를 가지고, 상기 키는 상기 고객 및/또는 상기 판매인의 은행 구좌를 구현하는 상기 트랜젝션에 서명하는 것을 가능하게 한다.
상세하게, 이러한 당사자(party)중 하나의 은행 구좌를 구현하는 트랜젝션은 토큰 같은 전자 통화가 아니라 "실제" 돈을 다룬다. 따라서 이러한 트랜젝션은 강한 지불거절 불가 특성을 필요로 하고, 비대칭 암호화기법의 사용에 의해 보증되는, 중개인과 다른 당사자 중 하나 사이의 분쟁(dispute)이 있어야 한다.
유익하게, 두 당사자(party)사이의 상기 트랜젝션 중 하나의 과정에서 교환되는 메시지는, 적어도 하나의 상기 두 당사자의 신분으로부터 및 마스터 키로부터 결정된, 추출된 대칭 키에 의해 인증된다.
따라서, 고객이 참가한 트랜젝션의 경우에는, 키는 고객의 신분으로부터 추출된다. 트랜젝션이 중개인과 판매인을 포함하는 경우에는, 이러한 키는 판매인의 신분으로부터 추출된다. 이러한 방식으로, 고객의 단말기에 마스터 키를 저장할 필요가 없고, 몇 개의 마스트 키만이 판매인의 장비에 저장될 필요가 있다.
바람직하게, 각각의 상기 트랜젝션은 특정 대칭 키를 구현하고, 상기 특정 키는 이하 그룹에 속하는 트랜젝션:
- 상기 중개인이 적어도 하나의 토큰을 상기 고객의 주 지갑에 보낸다;
- 상기 중개인이 적어도 하나의 토큰을 상기 판매인의 상기 지갑으로 보낸다;
- 상기 판매인이 상기 고객으로부터 상품 및/또는 서비스에 대한 지불을 요청한다;
- 상기 고객이 상품 및/또는 서비스에 대해 상기 판매인에게 지불한다;
- 상기 고객이 상기 판매인에게 구매의 증거를 제공한다;
- 상기 판매인이 상기 고객에게 상환한다;
- 상기 중개인이 상기 고객의 적어도 일부의 토큰을 재구매한다;
- 상기 중개인이 상기 판매인의 적어도 일부의 토큰을 재구매한다;
중 하나의 트랜젝션만을 위해 사용가능하다.
이러한 방식으로, 각각의 마이크로지불 트랜젝션은 상이한 키를 사용하므로, 프로세스의 보안성은 매우 개선된다: 상세하게, 오직 하나의 키의 타협(compromise)은 전체 프로세스를 타협시키는 것이 아니라, 타협된 키에 대응하는 트랜젝션만을 타협시킬 것이다.
본 발명의 유익한 기술에 따라서, 고객 및/또는 판매인이 가지는 상기 대칭 키는 이하의 동작:
- 상기 트랜젝션 중 하나의 과정에서 교환되는 메시지의 기원 및 무결성을 인증 가능하게 하기 위한 데이터의 생성;
- 상기 데이터의 지불거절 불가성(nonrepudiation)을 보증하기 위한 상기 데이터의 검증,
중 하나만을 위해 사용될 수 있다.
인증 데이터의 지불거절 불가성을 보증할 수 있게 하는, 인증 데이터{MAC, "메세지 인증 코드(message authentication code)"}의 검증 또는 생성을 위한 키의 선택적 사용은 본 발명의 바람직한 실시예에 따라 고객의 스마트 카드(판매인마다 각각)상에 고객의 키(판매인과 무관하게)를 저장함으로써 가능해진다. 스마트 카드의 실행가능한 코드를 수정하는 것이 불가능하므로, 인증 데이터의 검증 또는 생성에 대한 키를 선택적으로 대리할 수 있다.
따라서, 키가 타협되지 않는 한, MAC은 오직 하나의 스마트 카드에 의지 않고는 생성될 수 없고, 따라서 예를 들면 고객이 지불을 거절하는 것을 방지한다. 만약, 본 발명에 따라 구현된 기술과 반대로, MAC 의 검증과 생성 모두를 위해 대칭 키가 사용될 수 있다면, 적어도 2개의 스마트 카드(하나는 고객 하나는 판매인이 각각 가짐)는 주어진 MAC을 생성할 수 있고, 이것은 고객이 지불에 반박할 수 있게 한다.
본 발명은, 전술한 바와 같은 마이크로지불 트랜젝션을 관리하는 시스템에서의 고객용 단말기에 관한 것인데, 상기 트랜젝션은 적어도 하나의 중개인 및/또는 적어도 하나의 상품 및/또는 서비스 판매인 및/또는 상기 고객사이의 토큰의 교환을 구현한다. 이러한 단말기는, 적어도 하나의 주 지갑에 대응하고 적어도 하나의 보조 지갑에 대응하는, 토큰을 저장하는 적어도 2개의 상이한 영역을 포함하고, 상기 주 지갑은 상기 중개인에 의해 상기 고객에게 공급되는 토큰을 포함할 수 있고, 상기 보조 지갑은 상기 판매인에 의해 상기 고객에게 공급되는 토큰을 포함할 수 있다.
유익하게, 상기 2개의 저장 영역은, 상기 단말기에 포함된 안전한 프로세서에 위치하거나 상기 단말기에 의해 판독될 수 있는 데이터 지원부(data support)에 위치한다.
특히, 그러한 데이터 지원부는 스마트 카드 또는 다른 임의의 안전한 데이터 지원부일 수 있다.
본 발명은 또한, 전술한 바와 같은 마이크로지불 트랜젝션을 관리하는 시스 템에서의 판매인용 장비에 관한 것이고, 상기 트랜젝션은 적어도 하나의 중개인 및/또는 적어도 하나의 고객 및/또는 상기 판매인 사이의 토큰의 교환을 구현하고, 상기 장비는 토큰을 저장하는 적어도 2개의 별도의 영역을 포함한다.
바람직하게, 상기 2개의 저장 영역은 상기 판매인의 지갑 및 상기 판매인의 예금 파일이고, 상기 판매인의 상기 지갑은 상기 중개인에 의해 상기 판매인에게 공급되는 토큰을 포함할 수 있고, 상기 예금 파일은 상기 고객에 의해 상기 판매인에게 공급되는 토큰을 포함할 수 있다.
본 발명의 다른 특징 및 이점은 간략하게 예시된 그리고 제한하지 않는 실시예에 의해 주어진 바람직한 실시예 및 첨부 도면에 대한 이하의 설명을 읽음으로써 좀 더 명확해질 것이다.
본 발명에 의하면, 간단하고, 사용하기 쉽고, 구현하는데 비용이 많이 들지 않는 마이크로지불 트랜젝션 관리 방법을 제공할 수 있다.
본 발명의 일반적인 원리는, 마이크로지불 트랜젝션 관리 시스템의 각각의 고객에 대해, 토큰을 저장하는 2개의 별도의 영역을 존재시키는 것에 기초한다. 이러한 2개의 저장 영역은, 중개인에 의해 공급되는 토큰을 포함한 고객의 주 지갑 및 고객이, 예를 들면 사용가능하지 않는 상품에 대한 상환으로 또는 고객이 참가한 게임의 경품으로서, 하나이상의 판매인으로부터 받은 토큰을 저장하는 보조 지갑에 대응한다.
이러한 2개의 지갑 각각은 각 지갑이 포함할 수 있는 최대 토큰의 수에 대응하는 미리결정된 최대 합산액과 연관된다.
예를 들면 월드와이드 인터넷 네트워크를 매개로 하여 구현된, 고객(2)으로부터 판매인(3)으로의 마이크로지불 트랜젝션의 실시예가 도 1 과 연결되어 제공된다
마이크로지불 트랜젝션에 참가하기 위해서, 고객(2)은 단말기를 사용하고 이러한 단말기는 예를 들면 이하의 2개의 개체로 구성된다;
- 고객(2)의 인증 수단으로서 그리고 안전한 데이터 저장 수단으로서 사용되는 스마트 카드. 이러한 스마트 카드는 또한 텔레비전 채널의 지불 관리 같은 다른 기능들을 가지는 것을 생각하는 것도 가능하다;
- 스마트 카드 판독기(reader)를 포함하고 판매인(3) 및 중개인(1)과 통신할 수 있는 멀티미디어 디지털 디코더.
고객(2)은 또한 다른 임의의 유형의 적절한 단말기(예를 들면 스마트 카드 수단을 통합시킴)로부터 본 발명에 따른 마이크로지불 트랜젝션을 구현할 수 있다.
도 1 에서 블록(4)은 단순화를 위해 고객(2) 및/또는 판매인(3)의 은행을 나타낸다는 것을 유의하여야 한다. 판매인(3) 및 고객(2)는 동일한 은행(4) 또는 상이한 은행(4)의 고객으로 가정하는 것도 물론 가능하다.
임의의 구매 이전에, 만약 고객의 주 지갑 및 보조 지갑이 비어있다면, 고객(2)은 중개인(1)으로부터 토큰을 획득하여야 한다. 이를 위해, 고객(2)은, 단계(12)의 과정에서, 고객이 획득하고자 하는 토큰의 값과 동일한 양만큼 은행(4)에 서 고객이 소유하는 은행 구좌에 차변기입(debit)하도록 하는 권한서(authorization)를 중개인(1)에게 발송한다. 예를 들면, 고객(2)은 중개인으로의 전자 수표에 서명한다. 고객(2)에 의해 보내진 지불 권한서는 고객(2)의 은행(4)으로부터의 지불을 획득하기 위해 필요한 모든 정보를 중개인(1)에게 준다.
은행(4)에 의해 지불된 후에, 중개인(1)은 단계(13)의 과정에서 고객(2)에게 원하는 토큰을 발송한다.
도 1에는 도시되지 않은 단계의 과정에서, 고객(2)은 그가 판매인(3)으로부터 획득하고자 하는 상품 및/또는 서비스를 선택하고, 주문서 양식에 기입하고, 그것을 판매인(3)에게 발송한다. 예를 들면, 고객(2)은 판매인(3)의 웹 사이트로부터 엑세스가능한 주문서 양식에 기입한다. 그 후 판매인(3)은 고객(2)로부터 상품 및/또는 서비스에 대한 지불을 요청한다.
본 발명에 따른 마이크로지불 트랜젝션에 참가하기 위해, 판매인(3)은 이하 유형의 몇 개체 즉:
- 안전한 데이터 저장 영역 및/또는 판매인(3)의 인증 수단 및/또는 데이터 암호화 수단으로 사용되는 하나이상의 스마트 카드 및/또는 안전한 프로세서;
- 수명의 고객(2)과 동시에 구현되는 트랜젝션을 처리할 수 있는 서버
를 포함하는 장비(appliance)가 제공된다고 가정할 수 있다:
그 후 고객(2)은, 단계(14)의 과정에서, 주문된 상품 및/또는 서비스에 대한 마이크로지불을 수행한다.
이를 위해, 고객(2)은, 주 지갑이 충분한 토큰을 포함한다면 그로부터 고객 이 인출할, 획득된 상품 및/또는 서비스의 값에 대응하는 많은 수의 토큰을 판매인(3)에게 보낸다. 반대의 경우, 고객(2)은 그의 주 지갑이 비워질 때까지 그 주 지갑으로부터 토큰을 인출한다. 만약 필요하다면, 고객(2)은 마이크로지불을 수행하기 위해 그의 보조 지갑으로부터 부족한 수의 토큰을 인출한다.
지불을 받은 후에, 단계(15)의 과정에서 판매인(3)은 주문된 상품 및/또는 서비스를 고객에게 배송한다. 판매인이 고객(2)으로부터 받은 토큰은 예금 파일에 저장된다.
그 후 판매인(3)은 그가 은행(4)에 갖고 있는 은행 구좌가 고객(2)으로부터 받은 토큰의 값에 대응하는 양만큼 입금될(credit) 것을 원한다. 판매인(3)은 해당 값 만큼이 그의 은행 구좌에 입금되기 전에, 그가 미리결정된 수의 토큰을 받을 때까지 고객(2)로부터 토큰을 계속 받는 것을 또한 가정할 수 있다.
그 후 단계(16)의 과정에서, 판매인(3)은 예금 파일에 포함된 토큰 또는 이 토큰 중 일부를 중개인(1)에게 제공한다. 또한 판매인(3)은 이에 추가하여 지갑에 포함된 토큰을 줄 수도 있다. 중개인(1)은 받은 토큰의 유효성을 검증한다. 검증후에, 단계(11)의 과정에서, 중개인(1)은 받은 유효한 토큰의 값에 해당하는 합산액을 판매인(3)의 구좌에 전송하라는 위임서(mandate)를 은행(4)에게 보낸다.
단계(17)의 과정에서, 중개인(1)은 또한 은행(4)으로 향하는 전송 위임서의 사본을 판매인(3)에게 보내어, 판매인으로하여금 그의 은행 구좌가 실제로 입금될 것이라고 확인할 수 있게 한다.
판매인(3)이, 예를 들면 고객이 참가했던 판매인(3)의 게임 및/또는 복권 추 첨에 관하여 고객(2)의 경품에 해당하는 많은 수의 토큰을 고객(2)에게 보내거나 그에게 상환하고자할 때의, 본 발명에 따라 구현된 트랜젝션이 도 2 와 연계되어 이하에서 설명된다.
판매인(3)은 중개인(1)으로부터 획득한 토큰으로 그의 지갑를 채우기 시작한다. 상세하게, 그가 중개인(1)으로부터 구매한 토큰만이 고객(2)에게 상환하기 위해 사용될 수 있다. 판매인(3)은 고객(2)에게 상환하기 위해 그의 예금 파일에 저장된 어떤 토큰도 사용할 수 없고, 이것은 고객(2)에 대해 추가적인 보안성을 제공한다.
이를 위해, 판매인(3)은 단계(12)의 과정에서 중개인(1)에 대한 지불을 위한 권한서를 발송한다. 이러한 권한서는, 단계(11)의 과정에서 판매인(3)의 은행(4)으로하여금 돈을 판매인의 은행 구좌로부터 인출하라고 요구하는데 필요한 모든 정보를 중개인(1)에게 제공한다.
그 후 중개인(1)은 단계(13)의 과정에서 은행(4)으로부터 지불로서 받았던 합산액에 대응하는 많은 수의 토큰을 판매인(3)에게 발송한다. 이러한 토큰은 판매인에 의해 그의 지갑에 저장된다. 예를 들면 판매인의 이러한 지갑은 스마트 카드에 포함된다.
고객(2)은, 고객이 실제로 상환되어야 한다는 것을 판매인이 확인하기 위해 또는 예를 들면 고객이 가진 당첨된 복권 티켓을 제공하기 위해, 단계(21)의 과정에서 구매의 증거를 판매인(3)에게 제공한다.
그 후 판매인(3)은 단계(14)의 과정에서 고객(2)의 마이크로지불을 수행한 다. 그는 상환되어야 할 합산액 또는 고객(2)의 당첨금의 값에 해당하는 많은 수의 토큰을 고객(2)에게 보낸다.
이렇게 토큰을 보내기 전에, 판매인(3)은 그가 고객(2)에게 보내고자하는 토큰의 수가 고객의 보조 지갑에 저장될 수 있는 토큰의 최대수보다 적은지를 검증하거나, 이러한 토큰과 고객의 보조 지갑에 이미 포함된 임의의 토큰의 수의 합이 권한이 부여된 최대 토큰 수를 초과하지 않는지를 검증하는 것도 생각할 수 있다. 역의 경우, 예를 들면 본 발명의 주제가 아닌 매크로지불 프로세스를 구현함으로써 판매인(3)이 고객(2)에게 상환하는 것도 생각할 수 있다. 또한 판매인(3)은, 고객이 상환 받을 수 있도록 또는 그의 경품을 획득하도록 고객(2)에게 그의 보조 지갑를 비우라는 메시지를 발송하는 것도 생각할 수 있다.
이러한 토큰은 고객(2)의 보조 지갑에 저장되고, 이러한 지갑은 예를 들면 스마트 카드에 포함될 수도 있다. 이러한 토큰의 유효성은 그 후 고객(2)와 중개인(1)사이에 구현된 제 1 트랜젝션의 과정에서 검증된다. 그 후 고객(2)은 단계(16)의 과정에서 그의 보조 지갑에 포함된 토큰을 중개인(1)에게 제공한다.
토큰의 유효성을 검증한 후에, 중개인(1)은 단계(22)의 과정에서 고객(2)에게 유효한 토큰의 수를 보낸다. 이렇게 검증된 토큰은 그 후 고객(2)에 의해 그의 주 지갑에 저장된다.
다양한 실시예에 따라, 고객(2)은 그가 은행(4)에 가지는 은행 구좌에 유효한 토큰의 값에 대응하는 양만큼 입금되는 것을 더 선호할 수도 있다. 그 후 중개인은 단계(11)의 과정에서 고객(2)의 은행(4)에게 전송 위임서를 발송한다. 그 후 중개인은 이러한 전송 위임서의 사본을 고객(2)에게 보내어 고객이 그의 은행 구좌에 실제로 입금되는 것을 확인하게 한다.
고객(2)의 보조 지갑에 포함된 토큰의 유효성은 또한 고객(2)과 중개인(1)을 포함하는 각 트랜젝션의 과정에서 중개인(1)에 의해 검증될 수도 있다.
도 3과 연계하여서, 고객(2) 또는 판매인(3)이 중개인(1)이 그로부터 그의 지갑에 포함된 모든 또는 일부 토큰을 재구매하기를 원할 때를 구현한 트랜젝션이 제공된다.
단계(31)의 과정에서, 고객(2) 또는 판매인(3)은 N 개의 토큰을 재구매하려는 주문서를 중개인(1)에게 보낸다.
단계(32)의 과정에서, 그 후 중개인(1)은 고객(2) 및/또는 판매인(3)에게 N 개의 토큰의 재구매의 확인 메시지(confirmation)를 보낸다.
단계(11)의 과정에서, 또한 중개인은 고객(2) 및/또는 판매인(3)의 은행(4)에게 전송 위임서를 발송하여, 고객(2) 및/또는 판매인(3)의 은행 구좌가 재구매한 N 개의 토큰의 값에 해당하는 합산액만큼 입금되게 한다.
이러한 N 개의 토큰은 판매인(3)의 지갑 및/또는 예금 파일으로부터 뿐만아니라 고객(2)의 주 지갑 및/또는 보조 지갑으로부터 나올 수 있다. 고객(2)의 보조 지갑 및 판매인(3)의 예금 파일로부터 온 토큰은 중개인(1)에 의해 검증되어, 이러한 중개인은 그 값에 해당하는 합산액만큼 고객(2) 및/또는 판매인(3)의 은행 구좌에 입금되기 전에 그 토큰의 유효성을 결정한다.
본 발명은, 주어진 토큰에 대해서는 오직 4개의 가능한 경로만이 존재함으로 인하여, 토큰의 추적 가능성(traceability)을 돕는다는 것을 유의하여야 한다. 그러한 추적 가능성은 다양한 참가자 즉 중개인(1) 및/또는 고객(2) 및/또는 판매인(3)사이에 일어나는 트랜젝션의 보안을 개선시킬 수 있어 유익하다.
상세하게, 각 토큰은 중개인(1)에 의해 생성되고, 그 수명의 종료시에 중개인에게 되돌아가는데, 이것은 이하의 메커니즘 중 어느 하나에 따른다:
- 마이크로지불 트랜젝션 과정에서, 토큰은 중개인(1)에 의해 발행되고 고객(2)에게 보내지고, 그 후 판매인(3)에게 보내지고, 판매인은 다시 토큰을 중개인(1)에게 보낸다;
*- 상환의 과정에서, 토큰은 중개인(1)에 의해 발행되고, 판매인(3)에게 및 그 후 고객(2)에게 보내지고, 고객은 다시 토큰을 중개인(1)에게 보낸다;
- 고객(2)의 지갑의 내용물의 재구매의 경우에, 중개인(1)에 의해 생성된 토큰은 그 후 고객(2)의 주 지갑에 저장되고, 중개인(1)에게 다시 보내진다;
- 마지막으로, 중개인(1)에 의해 생성된 토큰은, 판매인(3)의 지갑에 저장되고, 이것은 중개인(1)에 의해 재구매된다.
본 발명의 바람직한 실시예에 따라, 토큰의 감사(audit)는 이하의 방식으로 구현되는 것을 생각할 수 있다:
- 중개인(1)이 주어진 참가자{고객(2) 및/또는 판매인(3)}에게 토큰을 보낼 때, 그는 이러한 참가자에게 위탁된(consigned) 전체 토큰 수를 기록하고, 해당 참가자로부터 토큰을 재구매할 때 이 수를 갱신한다;
- 중개인(1)이 토큰의 유효성을 검증하면, 중개인(1)은 그가 이 토큰을 처음에 위탁한 참가자의 신분을 알게 된다. 중개인은 이 참가자에 관하여 그가 검증한 전체 토큰의 수를 기록한다;
- 중개인(1)은 이러한 검증된 전체 토큰 수를 위탁된 전체 토큰 수와 비교한다. 만약 관련된 참가자가 판매인(3)이면, 검증된 전체 토큰 수는 위탁된 전체 토큰 수보다 적어야한다. 만약 관련된 참가자가 고객(2)이면, 검증된 전체 토큰 수는 위탁된 전체 토큰 수와 고객(2)의 보조 지갑에 저장된 최대 토큰 수의 합산액 보다 적어야 한다. 거꾸로 말하면, 본 발명은 유익하게 토큰이 관련 참가자{고객(2) 및/또는 판매인(3)}에 의해 생성되었다고 결정하게 할 수 있다.
본 발명에 따르면, 중개인(1) 및/또는 판매인(3) 및/또는 고객(2) 사이의 적어도 일부의 교환을 안전하게 하기 위해 암호화 프로세스가 추가적으로 구현될 수 있다.
예를 들면, 고객(2) 및/또는 판매인(3)의 은행 구좌를 포함하는 모든 트랜젝션은 비대칭 암호화기법으로 보호된다. 상세하게, 그러한 트랜젝션은 "진짜" 돈의 합산액(토큰수와 반대되는 것으로서임)을 구현하고, 그러므로 강력한 지불거절 불가성(nonrepudiation)을 나타낸다.
*본 발명의 바람직한 실시예에 따라, 모든 다른 트랜젝션은 대칭성 암호화 기법에 의해 보호될 수도 있다.
도 1 내지 도 3 에 의해 도시된 모든 트랜젝션에 대해, 은행 구좌, 중개 인(1) 및/또는 판매인(3) 및/또는 고객(2)을 구현하는 것은 그들이 지니고 있는 비대칭 키 쌍을 사용한다.
두 참가자{중개인(1) 및/또는 고객(2) 및/또는 판매인(3)}사이의 트랜젝션의 과정에서 교환되는 메시지를 인증하기위해, 두 참가자중 하나의 신분(identity)과 마스터 키로부터 도출되는 대칭 키가 사용되는 것이 바람직하다. 예를 들면, 고객(2)을 포함하는 트랜젝션 과정에서, 키는 고객의 신분으로부터 도출된다. 판매인(3) 및 중개인(1)을 포함하는 트랜젝션 과정에서, 키는 판매인(3)의 신분으로부터 도출된다.
본 발명의 바람직한 실시예에 따라서, 각각의 대칭 키는 상세하게는 이하의 미리결정된 유형의 트랜젝션 및/또는 검증에 대해 특정되어 사용된다;
- 중개인(1)에 의한 고객(2)의 주 지갑에의 토큰의 저장;
- 중개인(1)에 의한 판매인(3)의 지갑에의 토큰의 저장;
- 고객(2)로부터의 지불에 대한 판매인(3)의 요청;
- 고객(2)의 주 및/또는 보조 지갑으로부터의 구매에 대한 판매인(3)에 대한 마이크로지불;
- 고객(2)의 구매의 증거에 대한 확인(validation);
- 판매인(3)에 의한 고객(2)에 대한 상환;
- 중개인(1)에 의한 고객(2)의 토큰의 재구매;
- 중개인(1)에 의한 판매인(3)의 토큰의 재구매;
- 기타.
본 발명의 바람직한 실시예에 따르면, 에러 메시지를 관리하는 시스템이 또한 도 1 내지 도 3 에 도시된 모든 트랜젝션의 과정에서 구현된다.
만약 에러가 트랜젝션 과정에서 발생한다면, 이러한 에러 메시지는 고객(2) 및/또는 중개인(1) 및/또는 판매인(3)에게 발행되고, 이러한 에러 메시지로는:
- 데이터 인증 에러;
- 마이크로지불 과정에서, 고객(2)은 판매인(3)에게 지불하기에 충분한 수의 토큰을 가지지 않는다;
- 상환 트랜젝션 과정에서, 고객(2)에 의해 판매인(3)에게 제공되는 구매의 증거가 유효하지 않다;
- 중개인(1)에 의한 토큰의 확인 과정에서, 일부 토큰이 유효하지 않다;
-기타
등이 있다.
본 발명의 기술 분야는 마이크로지불 트랜젝션의 분야, 더 상세하게는, 본 발명은 적어도 하나의 중개인, 적어도 하나의 고객 및 적어도 하나의 상품 및/또는 서비스의 판매인을 구현하는 마이크로지불 트랜젝션을 관리하는 방법에 이용가능하다.
도 1 은 고객이 상품 및/또는 서비스를 판매인으로부터 구매하고자 할 때, 본 발명에 따라 구현된 트랜젝션을 개략적으로 나타내는 도면,
도 2 는 판매인이 고객에게 상환하고자 할 때 도 1 의 여러 참가자사이에 구현된 트랜젝션을 개략적으로 나타낸 도면,
도 3 은 고객 및/또는 판매인이 그의 은행 구좌로 그의 지갑의 내용물을 전송하고자 할 때 도 1 의 여러 참가자 사이에 구현된 트랜젝션을 개략적으로 나타낸 도면이다.

Claims (9)

  1. 트랜잭션 관리 시스템에서 트랜잭션을 관리하는 방법으로서, 상기 시스템은 중개인 장비(1), 고객 단말기(2) 및 상품 또는 서비스의 판매인 장비(3)를 포함하고, 상기 트랜잭션은 토큰의 교환을 구현하며,
    고객 단말기(2) 각각은 2개의 별도의 토큰 저장 영역 즉, 주 지갑에 대응하는 제1 토큰 저장 영역, 및 보조 지갑에 대응하는 제2 토큰 저장 영역을 구비하고,
    상기 주 지갑은 유효성이 상기 중개인 장비(1)에 의해 직접 보장되는 토큰을 위해 예약되고, 상기 보조 지갑은 상기 판매인 장비(3)에 의해 상기 고객 단말기(2)에 공급되는 토큰을 위해 예약되며,
    각각의 상기 판매인 장비(3)는 2개의 상이한 토큰 저장 영역 즉, 상기 판매인 장비(3)의 지갑에 대응하는 상기 판매인의 제 1 토큰 저장 영역, 및 상기 판매인 장비(3)의 예금 파일(deposit file)에 대응하는 상기 판매인의 제2 토큰 저장 영역을 포함하며,
    상기 판매인 장비(3)의 상기 지갑은 유효성이 상기 중개인 장비(1)에 의해 직접 보장되는 상기 토큰을 위해 예약되고, 상기 예금 파일은 상기 고객 단말기(2)에 의해 상기 판매인 장비(3)에 공급되는 토큰을 위해 예약되는, 트랜잭션 관리 방법에 있어서,
    상기 판매인 장비(3)로부터 상기 고객 단말기(2)를 가지고 획득되는 상품 또는 서비스에 대한 지불 과정에서, 상기 고객 단말기(2)는 상기 상품 또는 서비스의 가격에 대응하는 제 1 개수(P)의 토큰을 상기 판매인 장비(3)에 보내는데(14-도 1);
    - 만약 상기 주 지갑이 P 이상의 토큰량을 포함한다면, 상기 제 1 개수의 토큰(P)은 상기 고객 단말기(2)의 토큰을 저장하기 위한 제 1 영역으로부터 나오는데, 상기 제 1 영역은 상기 고객 단말기의 주 지갑에 대응하며 유효성이 상기 중개인 장비(1)에 의해 직접 보장되는 상기 토큰만을 포함하고;
    - 만약 상기 주 지갑이 P 이하의 토큰량(X)을 포함한다면, 상기 고객 단말기(2)는
    - 상기 주 지갑으로부터 나오는 X 개의 토큰; 및
    - 상기 고객 단말기의 보조 지갑에 대응하고 상기 판매인 장비(3)에 의해 공급되는 상기 토큰만을 포함하는 상기 고객 단말기(2)의 토큰을 저장하기 위한 제2 영역으로부터 나오는 P-X 개의 토큰을 보내며,
    상기 판매인 장비(3)는 토큰을 저장하기 위한 판매인 장비의 제 2 영역에 보내진 제 1 개수(P)의 토큰을 저장하는데, 상기 제 2 영역은 상기 예금 파일을 가리키는것을 특징으로 하는, 트랜잭션 관리 방법.
  2. 제 1 항에 있어서, 상기 고객 단말기(2)가 상기 판매인 장비(3)에 제1 개수(P)의 토큰을 보낸 후에, 상기 제품 또는 서비스에 대해 고객에 의해 판매인에게 지불된 제2 개수의 토큰을 상기 고객에게 판매인이 상환하고자 할 때(14-도2), 상기 트랜잭션 관리 방법은 이하의 단계:
    - 이러한 제 2 개수의 토큰을 판매인 장비의 지갑에 대응하는 상기 판매인 장비(3)의 상기 제 1 영역으로부터 인출하는 단계;
    - 상기 고객 단말기(2)의 상기 보조 지갑의 토큰에 추가된, 상기 제 2 개수의 토큰이 미리결정된 최대값을 초과하지 않음을 검증하는 단계;
    - 상기 최대값을 초과하지 않는 경우, 상기 고객 단말기(2)의 상기 보조 지갑에 상기 제 2 개수의 토큰을 저장하는 단계; 상기 최대값이 초과되면:
    - 상기 트랜잭션 관리 방법을 중단하고, 그밖의 지불 수단에 의해 상기 고객에 상환하는 단계; 또는
    - 상환될 수 있도록 상기 고객 단말기(2)의 보조 지갑을 비우도록 고객에게 요청하는 메시지를 발송하는 단계
    로 구성되는 것을 특징으로 하는, 트랜잭션 관리 방법
  3. 제 1 항 또는 제 2 항에 있어서, 상기 보조 지갑으로부터 상기 주 지갑으로 토큰을 전송하는 단계를 추가적으로 포함하고, 상기 토큰을 전송하는 단계는 이하의 하위 단계:
    - 상기 고객이 상기 중개인에게 상기 고객 단말기(2)의 상기 보조 지갑에 포함된 상기 토큰을 상기 주 지갑으로 전송하도록 요청하는 단계;
    - 상기 중개인 장비(1)는 한편으로는 상기 고객의 상기 요청의 유효성을 검증하고, 다른 한편으로는 상기 보조 지갑에 포함된 상기 토큰의 유효성을 검증하는 단계;
    - 상기 요청 및 상기 토큰이 유효하면, 상기 중개인 장비(1)가 상기 보조 지갑으로부터 상기 주 지갑으로 상기 토큰을 전송하는 단계
    를 포함하는 것을 특징으로 하는, 트랜잭션 관리 방법.
  4. 제 1 항 또는 제 2 항에 있어서, 상기 고객은 상기 중개인으로부터 토큰을 구매하고자 할 때, 상기 트랜잭션 관리 방법은 이하의 단계:
    - 상기 중개인 장비(1)가 상기 주 지갑으로 상기 구매된 토큰을 보내는 단계;
    - 상기 보조 지갑이 토큰을 포함하는 경우, 상기 중개인 장비(1)는 상기 토큰의 유효성을 검증하며, 이후 상기 토큰이 유효하면 상기 중개인 장비는 상기 토큰을 상기 보조 지갑으로부터 상기 주 지갑으로 전송하는 단계
    를 포함하는 것을 특징으로 하는, 트랜잭션 관리 방법.
  5. 제 1 항 또는 제 2 항에 있어서, 상기 판매인이 그의 지갑에서 미리결정된 정수인 N 개의 토큰의 값만큼 차변기입(debit)하여 N 개의 토큰의 이러한 값을 판매인의 은행 구좌에 입금시키고자 할 때, 상기 트랜잭션 관리 방법은 이하의 단계:
    - 상기 중개인 장비(1)는 상기 판매인 장비(3)의 상기 지갑이 N 개 이상의 토큰을 포함하는지를 검증하는 단계;
    - 상기 검증 단계가 수행되고 상기 예금 파일이 미리결정된 정수인 M 개의 토큰을 포함하면, 상기 중개인 장비(1)는 N+M 개의 토큰의 값만큼 상기 판매인의 은행 구좌에 입금하고(11), 상기 예금 파일을 비우며, 상기 판매인의 상기 지갑으로부터 N 개의 토큰을 제거하는 단계
    를 포함하는 것을 특징으로 하는, 트랜잭션 관리 방법.
  6. 제 1 항 또는 제 2 항에 있어서, 상기 고객(2)이 상기 주 지갑에 포함된 토큰의 값만큼 상기 고객의 은행 구좌에 입금되고자 하며, 상기 보조 지갑은 토큰을 포함할 때, 상기 중개인 장비(1)는 상기 보조 지갑에 포함된 상기 토큰의 유효성을 검증하는 단계를 수행하여, 유효하다고 검증된 경우, 상기 보조 지갑으로부터 상기 주 지갑으로 상기 토큰을 전송하는 것을 특징으로 하는, 트랜잭션 관리 방법.
  7. 제 5 항 또는 제 6 항에 있어서, 상기 중개인 장비(1), 상기 판매인 장비(3) 및 상기 고객 단말기(2)는 각각 한 쌍의 비대칭 키를 포함하고, 상기 키는 상기 고객 또는 상기 판매인의 상기 은행 구좌와 관련있는 트랜잭션을 보호하는 것을 가능하게 하는 것을 특징으로 하는, 트랜잭션 관리 방법.
  8. 제 1 항 또는 제 2 항에 있어서, 두 당사자(party)사이의 상기 트랜잭션 중 하나의 과정에서 교환되는 메시지는, 상기 두 당사자 중 하나의 식별 정보로부터 및 마스터 키로부터 결정된, 추출된 대칭 키에 의해 인증되는 것을 특징으로 하는, 트랜잭션 관리 방법.
  9. 제 1 항 또는 제 2 항에 있어서, 각각의 상기 트랜잭션은 특정 대칭 키를 구현하고, 상기 특정 키는 이하 그룹에 속하는 트랜잭션인,
    - 상기 중개인 장비(1)가 토큰을 상기 고객 단말기(2)의 주 지갑에 보낸다(13-도1, 22-도2);
    - 상기 중개인 장비(1)가 토큰을 상기 판매인 장비(3)의 상기 지갑으로 보낸다(13-도2);
    - 상기 판매인 장비(3)가 상기 고객 단말기(2)로부터 상품 또는 서비스에 대한 지불을 요청한다;
    - 상기 고객 단말기(2)가 상품 또는 서비스에 대해 상기 판매인 장비(3)에 지불한다(14-도1);
    - 상기 고객 단말기(2)가 상기 판매인 장비(3)에 구매의 증거(21)를 제공한다;
    - 상기 판매인 장비(3)가 상기 고객 단말기(2)에 상환한다(14-도2);
    - 상기 중개인 장비(1)가 상기 고객 단말기(2)의 토큰의 일부를 재구매한다;
    - 상기 중개인 장비(1)가 상기 판매인 장비(3)의 토큰의 일부를 재구매한다;
    중 하나의 트랜잭션만을 위해 사용가능한 것을 특징으로 하는, 트랜잭션 관리 방법.
KR1020097001501A 2000-07-07 2001-07-09 마이크로지불 트랜잭션을 관리하는 방법 KR20090031588A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0008867A FR2811451B1 (fr) 2000-07-07 2000-07-07 Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
FR00/08867 2000-07-07

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR10-2003-7000047A Division KR20030029607A (ko) 2000-07-07 2001-07-09 마이크로지불 트랜젝션을 관리하는 시스템 및 방법 및이에 대응하는 고객용 단말기 및 판매인용 단말기

Publications (1)

Publication Number Publication Date
KR20090031588A true KR20090031588A (ko) 2009-03-26

Family

ID=8852225

Family Applications (2)

Application Number Title Priority Date Filing Date
KR10-2003-7000047A KR20030029607A (ko) 2000-07-07 2001-07-09 마이크로지불 트랜젝션을 관리하는 시스템 및 방법 및이에 대응하는 고객용 단말기 및 판매인용 단말기
KR1020097001501A KR20090031588A (ko) 2000-07-07 2001-07-09 마이크로지불 트랜잭션을 관리하는 방법

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR10-2003-7000047A KR20030029607A (ko) 2000-07-07 2001-07-09 마이크로지불 트랜젝션을 관리하는 시스템 및 방법 및이에 대응하는 고객용 단말기 및 판매인용 단말기

Country Status (7)

Country Link
US (1) US20040034597A1 (ko)
EP (1) EP1299838A1 (ko)
JP (1) JP2004503018A (ko)
KR (2) KR20030029607A (ko)
AU (1) AU2001272633A1 (ko)
FR (1) FR2811451B1 (ko)
WO (1) WO2002005152A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019203516A1 (ko) * 2018-04-17 2019-10-24 강찬고 온라인 거래정보 보안 시스템 및 온라인 거래정보 보안방법
KR20190121263A (ko) * 2018-04-17 2019-10-25 강찬고 온라인 거래정보 보안 시스템 및 온라인 거래정보 보안방법

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8190893B2 (en) * 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
US8027918B2 (en) * 2004-08-30 2011-09-27 Google Inc. Micro-payment system architecture
US7640193B2 (en) * 2005-12-09 2009-12-29 Google Inc. Distributed electronic commerce system with centralized virtual shopping carts
US7949572B2 (en) * 2006-06-27 2011-05-24 Google Inc. Distributed electronic commerce system with independent third party virtual shopping carts
US8521650B2 (en) 2007-02-26 2013-08-27 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US9195983B2 (en) 2011-04-05 2015-11-24 Roam Data Inc. System and method for a secure cardholder load and storage device
US10580049B2 (en) 2011-04-05 2020-03-03 Ingenico, Inc. System and method for incorporating one-time tokens, coupons, and reward systems into merchant point of sale checkout systems
GB201105765D0 (en) * 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
EP2801062A4 (en) * 2011-10-31 2015-10-28 Roam Data Inc SYSTEM AND METHOD FOR INTEGRATING ONE-TIME AWARDS, COUPONS AND REWARD SYSTEMS IN SELF-SERVICE CASSING SYSTEMS OF A SALES AGENCY
US9846799B2 (en) 2012-05-18 2017-12-19 Apple Inc. Efficient texture comparison
US9135496B2 (en) * 2012-05-18 2015-09-15 Apple Inc. Efficient texture comparison
US9715616B2 (en) 2012-06-29 2017-07-25 Apple Inc. Fingerprint sensing and enrollment
US10068120B2 (en) 2013-03-15 2018-09-04 Apple Inc. High dynamic range fingerprint sensing
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US10846694B2 (en) 2014-05-21 2020-11-24 Visa International Service Association Offline authentication
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US11030588B2 (en) * 2019-09-10 2021-06-08 Gameplus Inc. Systems and methods for contest funds management
US11651354B2 (en) 2019-09-11 2023-05-16 Nxp B.V. Efficient partially spendable e-cash

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3594727A (en) * 1968-04-16 1971-07-20 Edward L Braun Credit card banking system
JPH05324998A (ja) * 1992-05-19 1993-12-10 Dainippon Printing Co Ltd Ｉｃカードを用いた代金精算システム
JP3334013B2 (ja) * 1994-05-02 2002-10-15 日本電信電話株式会社 電子現金流通方法
JP3334018B2 (ja) * 1994-09-20 2002-10-15 日本電信電話株式会社 電子現金方法及び電子現金システム
US5710887A (en) * 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
US6016484A (en) * 1996-04-26 2000-01-18 Verifone, Inc. System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment
JPH09305666A (ja) * 1996-05-16 1997-11-28 Nippon Telegr & Teleph Corp <Ntt> 電子決済方法ならびにシステム
JP3599493B2 (ja) * 1996-09-10 2004-12-08 日本銀行 発行機関分離型番号登録式電子現金方法および利用者装置
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
GB9624127D0 (en) * 1996-11-20 1997-01-08 British Telecomm Transaction system
WO1998043211A1 (en) * 1997-03-26 1998-10-01 British Telecommunications Public Limited Company Transaction system
IL120585A0 (en) * 1997-04-01 1997-08-14 Teicher Mordechai Countable electronic monetary system and method
US6128391A (en) * 1997-09-22 2000-10-03 Visa International Service Association Method and apparatus for asymetric key management in a cryptographic system
JPH11110461A (ja) * 1997-10-01 1999-04-23 Fujitsu Ltd 二重財布を有する電子財布システム、その電子財布システムに適用されるｉｃカード、二重財布を有するｉｃカード取引装置、二重財布を有するｉｃカード取引システムおよびそのｉｃカード取引システムに適用されるｉｃカード
JP3483441B2 (ja) * 1997-10-16 2004-01-06 富士通株式会社 電子マネーの管理所有装置および管理所有方法
JP3396638B2 (ja) * 1997-12-26 2003-04-14 日本電信電話株式会社 利用者署名を用いた電子現金方法、その装置及び記録媒体
CA2323500A1 (en) * 1998-03-11 1999-09-16 Cha! Technologies Services, Inc. Automatically invoked intermediation process for network purchases
EP0987642A3 (en) * 1998-09-15 2004-03-10 Citibank, N.A. Method and system for co-branding an electronic payment platform such as an electronic wallet
JP2000148936A (ja) * 1998-11-16 2000-05-30 Nippon Conlux Co Ltd 電子マネーの精算方法および装置
US7177838B1 (en) * 2000-01-26 2007-02-13 Paybyclick Corporation Method and apparatus for conducting electronic commerce transactions using electronic tokens
AU2002359757A1 (en) * 2001-12-26 2003-07-24 Vivotech, Inc. Wireless network micropayment financial transaction processing

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019203516A1 (ko) * 2018-04-17 2019-10-24 강찬고 온라인 거래정보 보안 시스템 및 온라인 거래정보 보안방법
KR20190121263A (ko) * 2018-04-17 2019-10-25 강찬고 온라인 거래정보 보안 시스템 및 온라인 거래정보 보안방법
JP2021512435A (ja) * 2018-04-17 2021-05-13 ゴ カン，チャン オンライン取引情報保護システムおよびオンライン取引情報保護方法

Also Published As

Publication number Publication date
AU2001272633A1 (en) 2002-01-21
WO2002005152A1 (fr) 2002-01-17
JP2004503018A (ja) 2004-01-29
FR2811451A1 (fr) 2002-01-11
FR2811451B1 (fr) 2002-11-29
KR20030029607A (ko) 2003-04-14
EP1299838A1 (fr) 2003-04-09
US20040034597A1 (en) 2004-02-19

Similar Documents

Publication Publication Date Title
US8712918B2 (en) Electronic currency, electronic wallet therefor and electronic payment systems employing them
US5956699A (en) System for secured credit card transactions on the internet
AU658233B2 (en) Electronic-monetary system
US6339765B1 (en) Method and apparatus for defining private currencies
KR20090031588A (ko) 마이크로지불 트랜잭션을 관리하는 방법
US20030070080A1 (en) Electronic-monetary system
US20140337206A1 (en) Electronic Currency System
HU221396B1 (en) A method for exchanging currencies
US20140143142A1 (en) Electronic Currency System
JP2004199534A (ja) Ｉｃカードを利用した決済システム
KR20000067276A (ko) 사이버 티켓을 기반으로 하는 전자상거래 시스템
GB2352861A (en) Payment transaction system
KR100371010B1 (ko) 전자화폐 교환방법
Austenfeld Jr Robert Electronic Payment Systems
Varadharajan et al. Issues in Securing Electronic Commerce over the Internet
Lucas Improvements in Probabilistic Micropayment Schemes
Paulus et al. The Key to My On-Line Security
UA50483A (uk) Спосіб здійснення платежів з використанням цифрових сертифікатів (варіанти)

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E601 Decision to refuse application