KR20060087614A - 복수의 당사자들 간의 소액결제의 용이화 - Google Patents

복수의 당사자들 간의 소액결제의 용이화 Download PDF

Info

Publication number
KR20060087614A
KR20060087614A KR1020067011292A KR20067011292A KR20060087614A KR 20060087614 A KR20060087614 A KR 20060087614A KR 1020067011292 A KR1020067011292 A KR 1020067011292A KR 20067011292 A KR20067011292 A KR 20067011292A KR 20060087614 A KR20060087614 A KR 20060087614A
Authority
KR
South Korea
Prior art keywords
party
payment
commitment
value
receivable
Prior art date
Application number
KR1020067011292A
Other languages
English (en)
Other versions
KR100847710B1 (ko
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 이베이 인크.
Priority to KR1020067011292A priority Critical patent/KR100847710B1/ko
Publication of KR20060087614A publication Critical patent/KR20060087614A/ko
Application granted granted Critical
Publication of KR100847710B1 publication Critical patent/KR100847710B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/29Payment schemes or models characterised by micropayments

Abstract

본 발명은 복수의 당사자들 간의 소액결제를 용이하게 하는 방법 및 시스템에 관한 것이다 (도 3). 제 1 당사자에 의해 행해지는 제 1 복수의 소액결제 커미트먼트가 등록되며 (70), 제 1 복수의 지불 커미트먼트는 제 1 당사자에 대한 총 커미트먼트 지불가능 값에 대해 기여한다. 제 2 당사자에게 행해지는 제 2 복수의 지불 커미트먼트가 등록되며 (72), 제 2 복수의 지불 커미트먼트는 제 2 당사자에 대한 총 커미트먼트 수신가능 값에 대해 기여한다. 제 2 당사자에 대한 총 커미트먼트 수신가능 값은 위험 표시 (81) 를 이용하여 계산된다 (78). 제 2 당사자에 대한 총 커미트먼트 수신가능 값은 제 1 당사자에 대한 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서 식별된다. 이 결정에 응답하여, 제 2 당사자로의, 제 1 당사자에 의한 총 커미트먼트 수신가능 값의 지불을 위한 지불 프로세스가 개시된다.
소액결제, 커미트먼트 지불가능 값, 커미트먼트 수신가능 값

Description

복수의 당사자들 간의 소액결제의 용이화{FACILITATING MICROPAYMENTS BETWEEN A PLURALITY OF PARTIES}
본 발명의 분야
본 발명은 일반적으로 상업 자동화 분야에 관한 것으로, 더 상세하게는, 벤더에게 누산된 소액결제 커미트먼트 (commitment) 의 배상으로서 지불을 할 수 있게 하는 시스템에 관한 것이다.
본 발명의 배경
거래 당사자들 간의 전자 지불은, 이러한 지불을 할 수 있게 하는 기술의 접근성이 증가되고 있기 때문에, 더욱더 일반적으로 행하여 지고 있다. 예를 들어, 오늘날, 대다수의 벤더들은 신용 카드 및/또는 직불 카드 거래를 처리할 수 있다. 통상적으로, 네트워크 기반 (또는, 온라인) 벤더는 전자 지불 서비스에 매우 많이 의존하며, 다수의 전자 지불 수단 (예를 들어, 신용 카드, 직불 카드, 및 다른 전자 지불 서비스 (예를 들어, 페이팔 (PayPal) 온라인 지불 서비스)) 을 허용할 수도 있다.
다수의 회사들은 전자 지불 (또는, 자금 이체 (funds transfer)) 서비스 (예를 들어, 비자, 마스터카드, 아메리칸 익스프레스, 페이팔, 등) 를 제공한다. 본래, 이러한 전자 지불 서비스는, 통상, 거래-당 원리 (per-transaction basis) 에 따라, 이러한 서비스의 제공에 대해 수수료를 청구한다. 또한, 이들 거래 수수료는, 통상, 상품 또는 서비스를 제공하고 있는 벤더에 대하여 부과된다. 이러한 거래 수수료가 벤더의 주목을 끌지 못하지만, 다수의 경우에, 총 거래 값과 비교해 볼 때, 거래 수수료는 작다. 또한, 벤더는, 적절한 비용을 초과하는 것이 구매자와 벤더 모드에 대해 컨비니언스한 이익 (convenience benefit) 이라고 생각한다.
다양한 전자 지불 서비스에 의해 부과되는 거래 수수료는, 상술된 바와 같이, 통상, 거래 당 수수료이며, 또한, 종종, 고정 거래 수수료를 포함한다. 총 거래 값이 감소하면, 당연히, 총 거래 값의 백분율에 따라, 거래-당 수수료가 증가하며, 이러한 전자 지불 서비스를 이용하는 벤더에게는 매력도 (attractiveness) 가 감소한다. 이 때문에, 벤더는 종종, 총 거래 값이 작으면, (예를 들어, 신용 카드를 통한) 전자 지불을 허용하려고 하지 않는다. 전자 지불 서비스의 이용은, 거래 비용이 거래와 관련된 이익률에 가까워지기 시작할 때, 특히, 주목을 끌지 못하게 된다. 예를 들어, 온라인 벤더가 $1 미만의 전자 컨텐츠 (예를 들어, MP3 파일) 를 팔 경우의 상황을 고려하자. 예를 들어, $0.10 의 거래 당 수수료를 가정하면, 총 거래 값의 10 % 가 전자 지불 서비스 수수료로 소비되기 때문에, 벤더가 전자 지불 서비스를 통해 지불을 수신하려고 하지 않을 수도 있음을 알 수 있다. 그 문제는, 아이템 당 값이 감소할수록, 심각해진다.
이른바, "소액결제" 와 관련된 거래 수수료의 문제를 해결할 목적으로, 다수의 해결책이 제안되고 있다. 하나의 이러한 해결책은, 1998년 5월, 네덜란드의 암스테르담에서 개최된 ICDS (International Conference on Distributed Computing Systems; ICDS '98) 의 회보 (proceeding) 인 "분산된 소액결재 통합 (Decentralized Micropayment Consolidation)" 에서 Jan Chomicki 등에 의해 제안된다. 상세하게는, 분산화된 네트워크 환경에서의 부채 통합의 개념에 기초한 프로토콜이 이 문헌내에서 설명된다.
본 발명의 요약
본 발명의 제 1 양태에 의하면, 복수의 당사자들 간의 소액결제를 용이하게 하는 방법이 제공된다. 제 1 당사자에 의해 행해지는 제 1 복수의 지불 커미트먼트가 등록되며, 그 제 1 복수의 지불 커미트먼트는 제 1 당사자에 대한 총 커미트먼트 지불가능 값에 대해 기여한다. 제 2 당사자에게 행해지는 제 2 복수의 지불 커미트먼트가 등록되며, 그 제 2 복수의 지불 커미트먼트는 제 2 당사자에 대한 총 커미트먼트 수신가능 값에 대해 기여한다. 제 2 당사자에 대한 총 커미트먼트 수신가능 값은 위험 표시 (risk indication) 를 이용하여 계산된다. 제 2 당사자에 대한 총 커미트먼트 수신가능 값은, 제 1 당사자에 대한 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서 식별된다. 이 결정에 응답하여, 제 2 당사자로의, 제 1 당사자에 의한 총 커미트먼트 수신가능 값의 지불에 대한 지불 프로세스가 개시된다.
본 발명의 다른 특징들은, 후속하는 첨부된 도면 및 상세한 설명으로부터 명백해질 것이다.
도면의 간단한 설명
본 발명은, 동일한 참조물이 유사한 엘리먼트를 나타내는 첨부된 도면의 도 로의 제한이 아니라 예로써 도시된다.
도 1 은, 클라이언트-서버 구조가 배치되는 본 발명의 일 예시적인 실시형태에 따라 네트워킹된 거래 환경의 도식적인 도면이다.
도 2 는, 소액결제 시스템이 피어-투-피어 시스템으로 배치되도록 도시되는 본 발명의 또 다른 실시형태에 따라 네트워킹된 거래 환경의 도식적인 도면이다.
도 3 은, 소액결제 시스템의 부분을 형성하는, 본 발명의 일 예시적인 실시형태에 따라 소액결제 애플리케이션에 관해 더 상세히 도시한 블록도이다.
도 4 는, 소액결제 시스템과 관련된 소액결제 데이터베이스내에 상주할 수도 있는, 본 발명의 일 예시적인 실시형태에 따라 다양한 테이블을 도시한 하이-레벨 엔티티-관계도이다.
도 5 는, 값을 가지고 있는 예시적인 커미트먼트 수신가능 테이블을 도시한 블록도이다.
도 6 은 본 발명의 일 예시적인 실시형태에 따른 방법의 흐름도로, 이로 인해, 수령인 사용자에게 빚진 총 커미트먼트 수신가능 값을 계산한 후, 그 총 커미트먼트 수신가능 값을 펀딩 큐 (funding queue) 에 할당할 수도 있다
도 7 은 본 발명의 일 예시적인 실시형태에 따른 방법을 도시한 흐름도로, 총계의 (aggregate) 지불 커미트먼트에 대해 당사자들 간의 지불을 용이하게 한다.
도 8 은, 특정 수령인 사용자에 대해 위험-조정된 커미트먼트 수신가능 밸런스를 계산하기 위한 일 예시적인 방법의 흐름도이다.
도 9 는, 소액결제 시스템에 의해 발생되고 제공될 수도 있는 일 예시적인 지불 커미트먼트 인터페이스를 도시한 도면이다.
도 10 은, 소액결제 시스템에 의해 발생되고 제공될 수도 있는 일 예시적인 지불가능 인터페이스를 도시한 도면이다.
도 11 은, 각각의 웹 서버를 통해 소액결제 시스템의 사용자에게 제공될 수도 있는 일 예시적인 지불 커미트먼트 수신 인터페이스를 도시한 도면이다.
도 12 는, 수령인 사용자에게 제공될 수도 있어, 커미트먼트 수신가능 밸런스가 펀딩 지불에 적합한 임계값을 초과한다는 것을 수령인 사용자에게 통지하는 일 예시적인 지불가능 인터페이스를 도시한 도면이다.
도 13 은, 머신으로 하여금 여기에 기술된 임의의 하나 이상의 방법을 수행하게 하기 위해 일 세트의 명령이 실행될 수도 있는 컴퓨터 시스템의 예시적인 형태로 머신의 도식적인 도면이다.
상세한 설명
벤더에게 소액결제의 이체를 할 수 있게 하는 방법 및 시스템이 설명된다. 다음의 설명에서, 설명을 목적으로, 본 발명의 완전한 이해를 제공하기 위하여, 다수의 특정 상세한 설명 (detail) 이 진술된다. 그러나, 본 발명이 이들 특정 상세한 설명 없이도 실행될 수도 있다는 것을 당업자는 알 수 있다.
"소액결제" 라는 용어가 이 명세서 전반에 걸쳐 사용되고 있지만, 본 발명을 특정 값 미만의 지불의 프로세싱으로 제한하는 것은 아니다. 본 발명은 임의의 값의 지불의 프로세싱의 애플리케이션을 발견할 수도 있으며, 소액결제의 프로세싱은, 본 발명이 애플리케이션을 발견하는 시나리오를 이용하는 것으로서 설명된다.
본 발명의 후술되는 예시적인 실시형태는, 지불인 사용자가 수령인 사용자에게 지불 커미트먼트를 행하게 될 수 있는 지불 시스템을 제안하며, 가능하게는, 이들 지불 커미트먼트는 소액 (예를 들어, $0.05) 에 대해 존재한다. 그 후, 지불인 사용자에 의해 행해지는 지불 커미트먼트가 지불인 사용자와 수령인 사용자 모두에 대해 등록된다. 시간에 따라, 예를 들어, 다수의 수령인 사용자로의, 지불인 사용자에 의해 행해지는 다수의 지불 커미트먼트의 총 값이 증가한다는 것을 알 수 있다. 유사하게, 가능하게는 다수의 지불인 사용자에 의해, 수령인 사용자에게 행해지는 지불 커미트먼트의 총액도 증가한다. 이들 다양한 지불 커미트먼트의 프로세싱과 관련된 거래 비용을 감소시키기 위하여, 본 발명의 일 예시적인 실시형태는, 지불인 사용자가 그 지불인 사용자에 의해 행해지는 지불 커미트먼트의 누산 총액을 포함하는 총 값과 관련하여 펀딩하도록 (예를 들어, 지불을 행하도록) 요청될 수도 있는 임계값을 제안한다. 유사하게, 수령인 사용자는, 그 수령인 사용자에게 행해지는 지불 커미트먼트의 누산 총 값이 임계값을 초과할 때, 그 누산 지불 커미트먼트의 배상으로서 지불을 수신하기에 적합하게 될 수도 있다. 본 발명의 일 예시적인 실시형태의 일 양태는, 어느 지불인 사용자가 어느 수령인 사용자에게 지불을 행해야 하는지에 대한 결정에 관한 것이고, 본 발명의 예시적인 실시형태의 다른 양태는, 이러한 지불이 언제 행해져야 하는지, 및 이러한 지불의 값이 얼마가 되어야 하는지에 대한 결정에 관한 것이다. 지불인 사용자에 의해 빚지고, 수령인 사용자에게 빚진 지불 커미트먼트를 누산하고, 다수의 누산 지불 커미트먼트의 배상으로서 단일의 지불 거래 (또는, 감소된 수의 지불 거래) 를 수행함으로써, 다중의 지불 커미트먼트의 배상과 관련된 거래 비용이 감소될 수도 있음을 알 수 있다.
또한, 본 발명의 예시적인 실시형태는, 언펀딩된 지불 커미트먼트 (예를 들어, 지불인 사용자가 그것의 배상으로서 지불을 행하지 않은 지불 커미트먼트) 와 펀딩된 커미트먼트 (예를 들어, 지불인 사용자가 지불을 행해야 하는 것과 관련된 지불 커미트먼트) 사이의 차이를 설명한다.
도 1 은, 클라이언트-서버 구조가 배치된 본 발명의 일 예시적인 실시형태에 따라 네트워킹된 거래 환경 (10) 의 도식적인 도면이다. 다수의 클라이언트-서버 머신이 네트워크 (20) 를 통해, 다수의 서버-측 머신 및 프로세스에 커플링되도록 도시된다. 예를 들어, 클라이언트 머신 (12) 은, 웹 브라우저 (14) 의 예시적인 형태로 제 1 클라이언트 애플리케이션을 호스팅하고 실행하도록 도시되며, 제 2 클라이언트 머신 (16) 은, 공개된 애플리케이션 프로그램 인터페이스 (API) 를 이용하여, 하나 이상의 서버-측 머신을 통해 통신할 수도 있는 부가적인 클라이언트 (18) 를 실행하도록 도시된다. 각각의 클라이언트 머신 (12 및 16) 은, 유선, 무선 또는 유선과 무선 기술의 일부 조합을 포함할 수도 있는 네트워크 (20; 예를 들어, 인터넷, LAN (Local Area Network), WAN (a Wide Area Network)) 에 커플링되도록 도시된다. 또한, 네트워크 (20) 는, 다수의 널리 공지된 프로토콜 (예를 들어, HTTP) 중 임의의 하나의 프로토콜을 이용하여, 서버-측과 클라이언트 머신 사이의 통신을 용이하게 할 수도 있다.
다음에, 서버-측을 참조하면, 3 개의 시스템, 즉, 세틀먼트 시스템 (settlement system; 22), 소액결제 시스템 (24) 및 트레이딩 시스템 (26) 이 네트워크 (20) 에 커플링된다. 도 1 에는, 각각의 시스템 (22, 24, 및 26) 이 분리되고 별개의 시스템으로 도시되었지만, 본 발명의 또 다른 실시형태에서는, 이들 시스템의 컴포넌트 및 기능이 하나 이상의 관련 시스템으로 통합될 수도 있다. 각각의 예시적인 시스템 (22, 24, 및 26) 은 유사한 3-계층 (three-tier) 구조를 갖도록 도시되며, 이들은, 관련 데이터베이스로의 액세스를 용이하게 하는 데이터베이스 서버 (28), 각각의 애플리케이션을 호스팅하고 실행하는 하나 이상의 애플리케이션 서버 머신 (30), 클라이언트-측으로부터 수신된 요청에 응답하는 웹 페이지 (예를 들어, HTML 페이지) 를 발생 및/또는 서빙하게 하는 하나 이상의 웹 서버 (32), 및 관련 시스템에 프로그램의 액세스를 제공하는 하나 이상의 애플리케이션 프로그램 인터페이스 (API) 서버 (34) 를 포함한다. 예를 들어, API 서버 (34) 는, 클라이언트-측으로부터 수신된 요청에 응답하여, 요청중인 머신에, 확장가능 마크업 언어 (XML) 파일을 발생시켜 서빙할 수도 있다.
다음에, 세틀먼트 시스템 (22) 에 대해 상세히 다루면, 적절한 애플리케이션 서버 머신 (30) 은, 거래 당사자들 간의 값 (예를 들어, 달러 또는 독점 통화 (proprietary currency)) 의 이체를 할 수 있게 하는 하나 이상의 세틀먼트 애플리케이션 (42) 을 호스팅한다. 또한, 세틀먼트 애플리케이션 (42) 은 데이터베이스 서버 (28) 를 통해, 세틀먼트 데이터베이스 (40) 로부터 데이터를 판독할 수 있고 세틀먼트 데이터베이스 (40) 에 데이터를 기록할 수 있다. 세틀먼트 시스템 (22) 은, 캘리포니아, 마운틴 뷰에 위치한 페이팔 주식회사에 의해 운영되는 페이 팔 지불 서비스와 같은 지불 서비스를 지원할 수도 있다.
유사하게, 소액결제 시스템 (24) 은, 애플리케이션 서버 머신 (30) 상의 하나 이상의 소액결제 애플리케이션 (38) 을 호스팅하며, 이들 소액결제 애플리케이션 (38) 은, 데이터베이스 서버 (28) 를 통해, 소액결제 데이터베이스 (36) 상에 저장된 데이터에 기록 및 판독 액세스한다. 이하, 예시적인 소액결제 애플리케이션 (38) 에 관한 부가적인 상세한 설명이 더 상세히 기술된다.
트레이딩 시스템 (26) 은, 적절한 애플리케이션 서버 머신 (30) 상의 하나 이상의 트레이딩 애플리케이션 (46) 을 호스팅하며, 그 트레이딩 애플리케이션 (46) 은, 데이터베이스 서버 (28) 를 통해, 트레이드 데이터베이스 (44) 상에 저장된 데이터에 기록 및 판독 액세스한다. 트레이딩 애플리케이션 (46) 은 하나 이상의 가격-설정 애플리케이션 (예를 들어, 경매 애플리케이션, 고정-가격 애플리케이션 등) 을 포함할 수도 있으며, 이로 인해, 당사자들 간의 동의 (agreement) 에 대한 값이 확립될 수도 있다. 다른 트레이딩 애플리케이션 (46) 은, 예를 들어, 사용자에 관한 거래의 이력 정보와 피드백을 트래킹하는 명성 애플리케이션 (reputation application) 을 포함할 수도 있다. 또한, 이러한 명성 애플리케이션은, 사용자로 하여금 트레이딩 시스템 (26) 내에서 신뢰성을 확립하도록 사용자에 관한 명성 정보를 공개하고, 특정 사용자에 대한 신뢰성, 신용 및 위험 요소를 평가하는데 있어 이들 시스템에 의해 사용하기 위한 다른 시스템 (예를 들어, 세틀먼트 시스템 (22) 또는 소액결제 시스템 (24)) 또는 잠재적인 트레이딩 파트너에 이런 명성 정보가 공개되게 할 수도 있다. 트레이딩 시스템 (26) 의 일 실 시예는, 캘리포니아, 샌 호세에 위치한 이베이 주식회사에 의해 운영되는 이베이 온-라인 시장이다.
도 2 는, 도 1 을 참조하여 상술된 서버-기반 시스템에 대조적인 것으로서, 소액결제 시스템이 피어-투-피어 시스템으로 배치되도록 도시된 본 발명의 또 다른 방법의 실시형태에 따라 네트워킹된 거래 환경 (50) 의 도식적인 도면이다. 이러한 목적으로, 도 2 는, 사용자 머신 (52 및 58) 을 포함하는 것으로서, 네트워킹된 거래 환경 (50) 을 도시하며, 사용자 머신 각각은, 각각의 피어-투-피어 소액결제 애플리케이션 (54 및 60) 을 호스팅한다. 각각의 사용자 머신 (52 및 58) 은 네트워크 (64; 예를 들어, 인터넷) 에 커플링되도록 도시되며, 그에 따라서, 소액결제 애플리케이션 (54 및 60) 이 네트워크 (64) 를 통해 통신할 수 있다. 또한, 각각의 소액결제 애플리케이션 (54 및 60) 은 각각, 로컬 소액결제 데이터베이스 (56 및 62) 에 액세스하며, 구조화되어, 이하 더 상세히 기술되는 바와 같이 다양한 기능을 제공할 수도 있다.
또한, 도 2 는, 적절한 소액결제 애플리케이션 (54 및 60) 이 네트워크 (64) 를 통해 통신할 수 있는 서버-기반 시스템인 세틀먼트 시스템 (22) 과 트레이딩 시스템 (26) 을 도시한 것이다. 또한, 본 발명의 또 다른 실시형태에서, 도 2 에 도시된 서버-기반 구조에 대조적인 것으로서, 세틀먼트 시스템 (22) 및/또는 트레이딩 시스템 (26) 은 피어-투-피어 구조를 이용하여 배치될 수도 있다. 또한, 세틀먼트 시스템 (22) 또는 트레이딩 시스템 (26) 중 어느 하나의 시스템의 다양한 컴포넌트가, 또 다른 실시형태에서는, 피어-투-피어 시스템으로서 배치될 수도 있 다. 예를 들어, 피어-투-피어 명성 시스템 또는 피어-투-피어 위험 분석 시스템은, 서버 기반이거나 그 자체로 피어-투-피어 시스템인 소액결제 시스템과 관련하여 이용될 수도 있다.
도 3 은, 본 발명의 일 예시적인 실시형태에 따라, 도 1 에 도시된 소액결제 시스템 (24) 의 하나 이상의 애플리케이션 서버 (30) 를 통해 호스팅될 수도 있는 소액결제 애플리케이션 (38) 에 관해 보다 상세한 설명을 제공한 블록도이다. 또한, 물론, 도시된 소액결제 애플리케이션 (38) 이 사용자 머신 (52) 을 통해 실행하는 피어-투-피어의 자립형 (stand-alone) 소액결제 애플리케이션 (54) 의 서브-애플리케이션 또는 모듈을 형성할 수 있다는 것을 알 수 있다.
예시적인 소액결제 애플리케이션 (38) 은, 소액결제 시스템 (24) 을 이용하여 지불인 사용자에 의해 행해질 수도 있는 지불 커미트먼트를 등록하도록 동작하는 지불가능 커미트먼트 등록 모듈 (70) 을 포함한다. 예를 들어, 소액결제 시스템 (24) 은, 지불인 사용자가 지불 커미트먼트를 행하길 바라는 수령인 사용자를 지불인 사용자가 식별할 수 있고, 그것을 이용하여, 지불인 사용자가 적절한 지불 커미트먼트에 대한 값 (예를 들어, 통화 값) 을 또한 특정할 수도 있는 하나 이상의 사용자 인터페이스를 제공할 수도 있다. 본 발명의 일 실시형태는, 지불 커미트먼트를, 언펀딩 지불 커미트먼트 (예를 들어, 적절한 지불인 사용자가 하나 이상의 지불 커미트먼트를 배상하기 위해 실제 지불을 행하지 않음) 나 펀딩된 지불 커미트먼트 (예를 들어, 지불인 사용자는 하나 이상의 지불 커미트먼트의 배상으로 지불을 행함) 중 어느 하나로서 지불 커미트먼트를 분류한다.
지불가능 커미트먼트 등록 모듈 (70) 은, (예를 들어, 마크업 언어 문서내에 포함될) 커미트먼트 정보를 송신하고, 지불인 사용자로부터 지불 커미트먼트 정보를 수신하기 위하여, 웹 서버 (32) 및/또는 API 서버 (34) 와 통신할 수도 있다. 또한, 지불 커미트먼트 정보의 수신에 따라, 지불가능 커미트먼트 등록 모듈 (70) 은, 소액결제 데이터베이스 (36) 내의 적절한 테이블 내에 이 정보를 레코딩하도록 동작한다. 이러한 테이블은, 예를 들어, 도 4 를 참조하여 이하 상세히 설명되는 커미트먼트 지불가능 테이블 (94) 및 커미트먼트 수신가능 테이블 (96) 을 포함할 수도 있다.
유사하게, 수신가능 커미트먼트 등록 모듈 (72) 은, 수령인 사용자에게 지불 커미트먼트에 관한 커미트먼트 정보를 수신하고, 소액결제 데이터베이스 (36) 내의 적절한 테이블 또는 테이블들내에 이런 지불 커미트먼트 정보를 등록하도록 동작한다. 예를 들어, 수신가능 커미트먼트 등록 모듈 (72) 은, 도 4 를 참조하여 이하 상세히 설명되는 커미트먼트 수신가능 테이블 (96) 내에 수신가능 커미트먼트 정보를 레코딩할 수도 있다.
지불가능 커미트먼트 등록 모듈 (70) 및 수신가능 커미트먼트 등록 모듈 (72) 모두는, 순환 커미트먼트 모듈 (74; recurring commitment module) 과 통신한다. 순환 커미트먼트 모듈 (74) 은, 지불인 사용자에 의해 정의된 바와 같이 순환 지불 커미트먼트를 발생할 (수령인 사용자에 의해 정의될 수도 있는 것처럼, 순환 커미트먼트 요청을 발생할) 책임이 있고, 등록 모듈 (70 및 72) 이 적절한 테이블내에 레코드들을 생성 및/또는 업데이트하는 것에 응답하여, 등록 모듈 (70 및 72) 에 적절한 커미트먼트 정보를 전달할 책임이 있다. 예를 들어, 특정 지불인 사용자가 특정 수령인 사용자에게 (예를 들어, 특정 서비스에 대한 가입에 대해) 매달 지불 커미트먼트를 행하길 바랄 수도 있음을 고려하자. 그 후, 순환 커미트먼트 모듈 (74) 은 이러한 순환 커미트먼트를 처리한다.
본 발명의 일 예시적인 실시형태에 따른 임계값 조정 모듈 (76) 은, 소액결제 시스템 (24) 내에 등록되어 있는 지불 커미트먼트의 배상으로서 펀딩 거래 (예를 들어, 지불 프로세스의 개시) 를 트리거링하는 임계값의 설명을 용이하게 하거나, 그 자체로 임계값을 특정한다. 예를 들어, 지불가능 임계값이 지불인 사용자의 지불가능 커미트먼트와 관련하여 특정될 수도 있어, 지불인 사용자에 의해 행해지는 지불 커미트먼트의 총 값이 지불가능 임계값을 초과할 경우에, 지불 프로세스가 개시되어, 지불인 사용자는 적절한 언펀딩된 지불 커미트먼트를 펀딩한다.
유사하게, 수신가능 임계값은, 임계값 조정 모듈 (76) 에 의해 특정될 수도 있으며, 그 수신가능 임계값은 수령인 사용자에게 행해지는 지불 커미트먼트의 값에 의해 초과될 경우에, 지불 커미트먼트의 배상으로서 값을 수신하기에 적합한 수령인 사용자에게 렌더링 (render) 하는 임계값 총 값이다.
본 발명의 일 실시형태에서, 임계값 조정 모듈 (76) 은, 단순히, 소액결제 시스템 (24) 의 관리자 (administrator) 로 하여금 예를 들어, 지불가능 임계값 또는 수신가능 임계값 중 하나로서 하나 이상의 임계값 (예를 들어, $5.00) 을 특정하게 하도록 동작할 수도 있다. 예를 들어, 소액결제 시스템 (24) 의 관리자는, 개별적인 지불인 사용자나 수령인 사용자, 또는 지불인/수령인 조합의 다양한 쌍에서도 적용할 수 있는 상이한 임계값을 특정할 수도 있다.
본 발명의 또 다른 실시형태에서, 임계값 조정 모듈 (76) 은, 개별 사용자로 하여금, 예를 들어, 적절한 사용자에게 적용할 수 있는 일정한 최소 값 및 최대 값의 제약내에서 지불가능 임계값 및/또는 수신가능 임계값을 특정하게 할 수도 있다.
본 발명의 또 다른 실시형태에서, 임계값 조정 모듈 (76) 은, 다양한 정보 소스를 이용하여, 지불가능 임계값 및/또는 수신가능 임계값을 자동적으로 계산할 수도 있다. 예를 들어, 일정한 세틀먼트 시스템 (22) 이 특정 펀딩 이벤트와 관련하여 이용되는 것을 소액결제 시스템 (24) 이 알고 있는 경우에, 임계값 조정 모듈 (76) 은 적절한 세틀먼트 시스템 (22) 에 의해 부과되는 거래 수수료에 의존하여 임계값을 조정할 수도 있다. 세틀먼트 시스템 (22) 이 펀딩 이벤트와 관련된 거래 수수료를 증가시키는 특정 실시예를 고려해보자. 이 경우에, 임계값 조정 모듈 (76) 은, 펀딩 값의 소정의 최대 백분율대로 거래 수수료를 유지시키기 위하여 임계값을 증가시킬 수도 있다. 또 다른 예시적인 실시형태에서, 임계값 조정 모듈 (76) 은, 특정 수령인 사용자가 지불 커미트먼트의 소정의 레이트를 달성하는데 실패했는지 여부에 기초하여 동적으로 임계값을 조정할 수도 있다. 예를 들어, 임계값 조정 모듈 (76) 은, 적절한 수령인 사용자로 하여금, 지불 커미트먼트가 펀딩되기 이전에 허용가능하지 않은 정도의 시간을 대기하지 않게 하기 위하여, 펀딩 수신가능 임계값을 자동으로 감소시킬 수도 있다. 또한, 지불인 사용자가 소정의 레이트로 지불 커미트먼트를 행하지 않는 경우에, 임계값 조정 모 듈 (76) 은, 또한, 허용가능한 시간 주기내에 펀딩을 받아내기 (extract) 위하여 사용자와 관련된 펀딩 지불가능 임계값을 감소시킬 수도 있다.
또한, 임계값 조정 모듈 (76) 은, 그 사용자와 관련된 임계값을 평가하는데 있어 지불인 사용자 또는 수령인 사용자와 관련된 특성 또는 속성 정보를 고려할 수도 있다. 예를 들어, 그 사용자와 관련된 이력 정보 또는 명성 정보가 지불인 사용자로부터의 펀딩을 획득하는 것과 관련되는 증가 위험 또는 감소 위험을 표시하는 경우에, 임계값 조정 모듈 (76) 은 그 사용자에 대한 펀딩 지불가능 임계값을 자동으로 조정할 수도 있다. 또 다른 예시적인 실시형태에서, 임계값 조정 모듈 (76) 은 시간에 따라 임계값을 증가 또는 감소시킬 수도 있다. 예를 들어, 임계값은 일정한 레벨 (예를 들어, $5.00) 에서 시작할 수도 있고, 펀딩 지불이 매우 작은 경우에도, 결국, 지불인 사용자가 펀딩 지불을 행할 책임을 지게 하기 위해, 최소의 허용가능한 거래 값에 이르도록, 매달에 소정의 양 (예를 들어, 1 개월 당 $1.00) 으로 감소될 수도 있다.
또한, 임계값 조정 모듈 (76) 은 레졸루션 (resolution) 의 변화로 임계값을 특정할 수도 있다. 예를 들어, 임계값 조정 모듈 (76) 은 소액결제 시스템 (24) 에 걸쳐서 시스템 레벨 상에 적용될 임계값을 특정할 수도 있다. 또한, 임계값 조정 모듈 (76) 은 사용자-레벨에서, 또는, 다양한 상황에 따라, 펀딩 거래 레벨에서도 특정될 임계값을 특정할 수도 있다.
도 3 은 임계값 평가 모듈 (80) 에 커플링되어 있는 임계값 조정 모듈 (76) 을 도시한 것으로, 그 임계값 평가 모듈 (80) 은, 커미트먼트 수신가능 총액에 대 한 커미트먼트 지불가능 총액이 특정 임계값을 초과하는지 여부를 평가하도록 동작한다. 이하, 임계값 평가 모듈 (80) 의 동작이 도 6 을 참조하여 더 상세히 설명된다.
또한, 일 예시적인 실시형태에서, 소액결제 애플리케이션 (38) 은, 사용자 (예를 들어, 수령인 사용자) 와 관련된 위험 프로파일을 이용하여, 수령인 사용자에 대한 총 커미트먼트 수신가능 값을 계산하도록 동작하는 수신가능 계산 모듈 (78) 을 포함하도록 도시된다. 본 발명의 다른 실시형태에서, 총 커미트먼트 수신가능 값의 계산은 다른 위험 정보를 고려할 수도 있다. 따라서, 본 발명은, 사용자와 관련된 위험 프로파일의 이용으로 제한되는 것이 아니며, 위험이 결정되거나 추론되는 임의의 정보의 이용을 포함할 수도 있다.
수신가능 계산 모듈 (78) 은, 사용자 (예를 들어, 수령인 사용자) 와 관련된 위험 프로파일을 결정하는, 위험 평가 모듈 (81) 과 통신하도록 도시된다. 예를 들어, 위험 평가 모듈 (81) 은, 이력 정보 및 명성 정보를 이용하여 사용자에 대한 위험 프로파일을 만들어 낼 수도 있다 (그렇지 않으면, 소액결제 시스템 (24) 내의 이용을 위한 위험 값을 계산할 수도 있다). 위험 평가 모듈 (81) 에 의해 이용되는 이력 정보 및/또는 명성 정보는 소액결제 시스템 (24) 으로부터 로컬적으로 획득될 수도 있고, 또는, 예를 들어, 트레이딩 시스템 (26) 으로부터 획득된 명성 정보 및 세틀먼트 시스템 (22) 으로부터 획득된 이력의 지불 정보와 같이, 다른 소스로부터 획득될 수도 있다. 또한, 위험 평가 모듈 (81) 은, 이퀴팩스 (equifax) 및 신용 스코어 기관 (credit score organization) 과 같은 제 3 당사자 정보 벤더로부터 정보를 획득할 수도 있다.
다양한 다른 정보 소스는, 소액결제 시스템 (24) 내의 이용에 대한 위험 값 (예를 들어, 사용자에 대한 위험 프로파일) 을 계산하는데 있어서 위험 평가 모듈 (81) 에 의해 이용될 수도 있다. 예를 들어, 특정 사용자에 의해 제공된 머천다이즈 (merchandise) 또는 서비스의 유형이 관련될 수도 있다. 예를 들어, 도박 (gaming) 또는 포르노그라피 (pornography) 서비스는 통상, 지불인 사용자에 의해 더 높은 디폴트 위험에 있다. 또한, 지불인 사용자 또는 수령인 사용자의 지리적 위치가 관련될 수도 있다. 임의의 유형의 사용자, 또는 특정 거래의 임의의 당사자와 관련된 정보의 임의의 조합이 위험을 평가하는데 있어서 위험 평가 모듈 (81) 에 의해 이용될 수도 있음을 알 수 있다. 또한, 평가 위험은 수령인 사용자에 대한 총 커미트먼트 수신가능 값의 계산을 넘어 이용될 수도 있고, 예를 들어, 후술되는 바와 같이, 소액결제 시스템 (24) 내의 다른 지불 값 및 다른 사용 목적을 위험-조정하기 위해 이용될 수도 있다.
또한, 위험 평가 모듈 (81) 은 임계값 조정 모듈 (76) 에 입력을 제공하도록 도시되어, 허용될 경우에, 그 모듈 (76) 로 하여금, 사용자와 관련된 임계값을 조정하는데 있어서 위험 프로파일을 이용하게 할 수 있다.
또한, 소액결제 애플리케이션 (38) 은 통신 모듈 (82) 을 포함하여, 소액결제 애플리케이션 (38) 과 다른 애플리케이션 (예를 들어, 도 1 에 도시된 세틀먼트 애플리케이션 (42) 과 트레이딩 애플리케이션 (46)) 사이의 다양한 유형의 정보의 전달, 뿐만 아니라 소액결제 시스템 (24) 의 사용자에게의 메시지 (예를 들어, 이 메일, SMS 메시지, 인스턴트 메시지 (IMs), 등) 의 전달을 할 수 있게 한다. 예를 들어, 통신 모듈 (82) 은 지불 프로세스의 부분인, 세틀먼트 애플리케이션 (42) 에 명령을 전달하여, 지불인 사용자로부터 수령인 사용자로의 자금의 이체를 개시할 수도 있다. 이러한 명령의 전달은 지불 할당 모듈 (84) 로부터 명령에 따라 자동적으로 수행될 수도 있고, 또는, 적절한 자금 이체를 위한 사용자로부터의 명령을 수신함에 따라 수행될 수도 있다.
또한, 통신 모듈 (82) 은 다른 애플리케이션으로부터 통신물을 수신할 수도 있다. 예를 들어, 세틀먼트 애플리케이션 (42) 은, 소액결제 애플리케이션 (38) 이 일정한 커미트먼트를 펀딩된 것으로서 등록할 수도 있다는 것에 응답하여, 지불인 사용자로부터 수령인 사용자로 자금이 성공적으로 이체되고 있음을 통신 모듈 (82) 로 되 전달할 수도 있다. 이러한 목적으로, 통신 모듈 (82) 은 등록 모듈 (70 및 72) 과 통신하도록 도시되어, 적절할 때 및 세틀먼트 애플리케이션 (42) 에 의해 확인될 때, 이들 모듈로 하여금 커미트먼트를 펀딩된 것으로 등록하게 할 수 있다.
또한, 통신 모듈 (82) 은 임계값 조정 모듈 (76) 과 통신하도록 도시되어, 임계값 조정 모듈 (76) 과 위험 평가 모듈 (81) 로 하여금, 세틀먼트 시스템 (22) 과 트레이딩 시스템과 같은 외부 시스템으로 통신물 (communications) 을 송신하게 하고, 그 외부 시스템으로부터 통신물을 수신하게 할 수 있다.
지불 할당 모듈 (84) 은, 본 발명의 일 예시적인 실시형태에서, 지불인 사용자로부터 수령인 사용자로 자금의 자동 이체를 명령하도록 동작한다. 예를 들 어, 지불인 사용자는, 이러한 커미트먼트의 총액이 펀딩 지불가능 임계값을 초과할 때, 지불 커미트먼트가 자동으로 펀딩된다는 점에서, 선호도를 정의할 수도 있다. 또한, 지불인 사용자는, 어느 수령인 사용자가 적절한 자금을 수신할지에 관하여 선호도를 특정할 수도 있고, 또는 자금이 할당될 수령인 사용자를 지불 할당 모듈 (84) 이 자동으로 식별할 수도 있다는 점에서 기준을 특정할 수도 있다. 예를 들어, 특정 사용자는 선호도를 정의할 수도 있으며, 그에 따라, 지불인 사용자에 대한 지불 커미트먼트의 총액이 임계값을 초과할 때, 펀딩을 수신할 자격이 있는 자선 기관에 지불을 행함으로써 이러한 커미트먼트가 펀딩된다.
이하, 더 상세히 설명되는 바와 같이, 일 예시적인 실시형태에서, 펀딩 수신가능 임계값을 초과할 경우에, 수신가능 커미트먼트는 수신가능 계산 모듈 (78) 에 의해, 및, 임계값 평가 모듈 (80) 에 의해 펀딩 큐내에 배치될 수도 있다. 이런 실시형태에서, 지불 할당 모듈 (84) 은 다양한 알고리즘을 동작시켜, 펀딩 큐내의 적합한 수령인 중 어느 수령인이 그 다음에 또는 특정 이벤트의 발생에 따라 펀딩될 것인지를 결정할 수도 있다. 예를 들어, 지불 할당 모듈 (84) 은, 단순한 선입, 선출 원리에 기초하여 펀딩 큐에 펀딩을 할당할 수도 있다. 다른 방법으로는, 지불 할당 모듈 (84) 은 더 정교한 기준을 펀딩 큐 내로부터의 수령인의 선택에 적용할 수도 있다.
도 4 는, 소액결제 데이터베이스 (36) 내에 상주할 수도 있는 본 발명의 일 예시적인 실시형태에 따라 다양한 테이블 (90) 을 도시한 하이-레벨 엔티티-관계 도표도이다. 테이블 (90) 은, 각각의 사용자에게 특정한 콘택트 (contact) 및 다른 정보가 저장된 사용자 테이블 (92) 을 포함한다. 커미트먼트 지불가능 테이블 (94) 은, 특정 사용자에게 행해지는 각각의 지불 커미트먼트의 레코드를 유지하고, 지불인 사용자, 수령인 사용자, 커미트먼트의 총액, 커미트먼트가 행해지는 날짜, 커미트먼트의 디스크립션 (description), 커미트먼트가 펀딩되었는지 여부의 표시, 및 커미트먼트가 순환하고 있는지 여부에 대한 표시를 식별하는 식별자를 포함한다.
유사하게, 커미트먼트 수신가능 테이블 (96) 은, 특정 사용자에 의해 수신가능한 각각의 지불 커미트먼트에 대한 레코드를 저장하고, 레코딩된 동일한 정보를 커미트먼트 지불가능 테이블 (94) 내에 레코딩한다.
분리된 커미트먼트 지불가능 테이블 (94) 및 커미트먼트 수신가능 테이블 (96) 을 유지함으로써, 이들 테이블이 이중-엔트리 검증 (double-entry verification) 을 수행하도록 이용될 수도 있음을 알 수 있다. 또 다른 실시형태에서, 커미트먼트 지불가능 테이블 (94) 및 커미트먼트 수신가능 테이블 (96) 은 단일의 커미트먼트 테이블로 결합될 수도 있다.
세틀먼트 테이블 (98) 은, 특정한 지불인 사용자와 특정한 수령인 사용자 간의 각각의 펀딩 거래에 대한 레코드를 가지고 있다. 세틀먼트 테이블 (98) 내의 레코드들은 세틀먼트 시스템 (22) 으로부터 검색된 정보로부터 발생될 수도 있고, 또한, 특정한 펀딩 거래에 응답하여, 펀딩된 것으로서, 테이블 (94 및 96) 내의 엔트리를 플래깅 (flag) 하기 위해, 등록 모듈 (70 및 72) 에 의해 이용될 수도 있다.
테이블 (90) 은, 레코드가 사용자 테이블 (92) 내에 존재하는 각각의 사용자에 대한 펀딩 지불가능 임계값과 펀딩 수신가능 임계값을 저장하는 사용자 임계값 테이블 (100) 을 더 포함한다. 상술된 바와 같이, 본 발명의 일 예시적인 실시형태에서, 지불가능 임계값 및 수신가능 임계값은 사용자-레벨로 특정될 수도 있다. 본 발명의 또 다른 실시형태에서, 시스템 임계값 테이블 (102) 은, 소액결제 시스템 (24) 내의 시스템 레벨에 적용할 수 있는 펀딩 지불가능 임계값 및 펀딩 수신가능 임계값을 저장할 수도 있다. 물론, 사용자 임계값 테이블 (100) 과 시스템 임계값 테이블 (102) 모두가 존재할 수도 있으며, 레코딩된 임계값은, 소정의 기준에 따라, 지불 할당 모듈 (84) 에 의해 선택적으로 적용될 수도 있다.
또한, 테이블 (90) 은 특정한 사용자에 대한 피드백 정보 및 이력 정보를 포함하는 레코드를 가지고 있는 명성 테이블 (104) 을 포함한다. 예를 들어, 명성 테이블 (104) 은, 거래 피드백 정보, 지불 피드백 정보, 멤버십 지속기간 정보, 외부 신용 또는 ID 검증 정보, 및 가입자 정보를 포함할 수도 있다. 상술된 바와 같이, 명성 테이블 (104) 내의 정보는 소액결제 시스템 (24) 내에서 내부적으로 발생될 수도 있고, 또는, 외부 소스 및 시스템 (예를 들어, 세틀먼트 시스템 (22) 및 트레이딩 시스템 (26)) 으로부터 통신 모듈 (82) 을 통해 수신될 수도 있다.
도 5 는, 값들을 가지고 있는 예시적인 커미트먼트 수신가능 테이블 (96) 을 도시한 블록도이다. 도시된 바와 같이, 다양한 커미트먼트들은, 적절한 지불인이 적절한 지불 커미트먼트를 적용하고 커버하는 펀딩 거래를 수행하였는지 여부에 따라, 펀딩되거나 언펀딩된 것으로서, 플래깅된다.
일 예시적인 실시형태에서는, 사용자 테이블 (92) 이 커미트먼트 지불가능 밸런스와 커미트먼트 수신가능 밸런스를 반영 (reflect) 할 수도 있다는 것을 알 수 있다. 커미트먼트 지불가능 테이블 (94) 및 커미트먼트 수신가능 테이블 (96) 내에 포함된 정보에 기초하여, 수신가능 계산 모듈 (78) 은 이들 밸런스들을 주기적으로 업데이트할 수도 있다.
도 6 은 본 발명의 일 예시적인 실시형태에 따른 방법 (110) 의 흐름도로, 그에 따라, 소액결제 애플리케이션 (38) 은 수령인 사용자에게 빚진 총 커미트먼트 수신가능 값을 계산한 후, 그 총 커미트먼트 수신가능 값을 펀딩 큐에 할당할 수도 있다. 상세하게는, 커미트먼트 수신가능 테이블 (96) 은, 수신가능 계산 모듈 (78) 에, 원래의 (raw) 커미트먼트 수신가능 정보의 형태로 입력을 제공한다. 수신가능 계산 모듈 (78) 은 위험-조정된 커미트먼트 수신가능 값 총액을 계산하기 위해 위험 모델 (112) 을 배치시킨다. 위험 모델 (112) 은 적절한 수령인 사용자와 관련된 위험 프로파일을 만들기 위해 명성 테이블 (104) 로부터 검색된 정보를 이용하며, 만들어진 위험 프로파일의 함수로서 위험-조정된 커미트먼트 수신가능 총액을 계산한다. 일 실시형태에서는, 커미트먼트 수신가능 총액의 언펀딩된 부분의 펀딩에 관한 불확실성을 고려하여, 원래의 커미트먼트 수신가능 총액의 언펀딩된 부분에만 위험 프로파일이 적용된다. 본 발명의 다른 실시형태에서, 원래의 커미트먼트 수신가능 총액의 언펀딩된 부분에 적용되는 위험 프로파일이 특별하게 수령인 사용자와 관련되는 것이 아니라, 전체적으로 소액결제 시스템 (24) 에 걸쳐 적용할 수 있거나, 언펀딩된 지불 커미트먼트와 관련된 지불인 사용자에 기초하여 계산될 수도 있다.
수신가능 계산 모듈 (78) 에 의해 적용된 위험 프로파일의 함수는 단순한 함수 (예를 들어, 단순한 백분율 계산) 일 수도 있으며, 또는, 다수의 인자 (factor) 를 고려한 더 복잡한 함수일 수도 있다. 예를 들어, 위험 프로파일 (또는, 다른 위험 값) 은 상술된 임의의 정보 유형을 이용하여 계산될 수도 있다. 또한, 수신가능 계산 모듈 (78) 에 의해 적용되는 위험 프로파일 (또는, 위험 값) 의 함수는, 소액결제 시스템 (24) 의 관리자에 의해서 또는 자신의 머신 학습에 의해서, 연속적인 향상 또는 조정의 대상일 수도 있다.
그 후, 위험-조정된 커미트먼트 수신가능 총액이 수신가능 계산 모듈 (78) 로부터 임계값 평가 모듈 (80) 로 전달되며, 임계값 평가 모듈 (80) 은, 위험-조정된 커미트먼트 수신가능 총액이 수신가능 총액을 펀딩할 자격이 있는 임계값을 초과하는지 여부에 대해 결정을 행한다. 이 평가를 행하여, 임계값 평가 모듈 (80) 은, 도 4 를 참조하여 상술된 임계값 테이블 (100 또는 102) 에 포함된 정보를 이용할 수도 있다. 알 수 있는 바와 같이, 시스템-레벨, 사용자-레벨, 또는 거래-레벨에 따라, 임계값이 적용될 수도 있다.
위험-조정된 커미트먼트 수신가능 총액이 펀딩을 수신할 자격이 되었음을 임계값 평가 모듈 (80) 이 결정할 때, 적절한 수신가능 총액이 펀딩 큐 (114) 로 들어가게 된다. 펀딩 큐 (114) 내의 각각의 엔트리는 위험-조정된 커미트먼트 수신가능 총액, 수령인 사용자, 수신가능 총액이 펀딩 큐내로 들어가게 된 날짜, 및 우선순위를 레코딩한다. 일 실시형태에서, 지불 할당 모듈 (84) 은 우선순위를 결정할 수도 있다. 상세하게는, 지불 할당 모듈 (84) 은 선입, 선출 우선순위 방식 또는 더 복잡한 우선순위 방식에 기초하여, 펀딩 큐 (114) 내의 각각의 엔트리를 우선 순위 매길 수도 있다. 예를 들어, 수령인이 특정 유형의 기관 (예를 들어, 자선 단체) 이거나 우선순위 수령인으로 식별된 엔트리는, 다른 엔트리 보다 앞서 우선 순위 매겨질 수도 있다. 다른 실시형태에서, 수령인이 펀딩의 수신 이전의 허용가능하지 않은 시간 주기를 대기하지 않는 것을 보장하기 위해 펀딩 큐내의 엔트리를 우선 순위 매기기 위해 우선순위 방식이 이용될 수도 있다.
도 7 은, 본 발명의 일 예시적인 실시형태에 따른 방법 (120) 을 도시한 흐름도로, 총계의 지불 커미트먼트에 대한 당사자들 간의 지불을 용이하게 한다. 방법 (120) 은, 블록 122 에서, 지불인 사용자로의 지불 커미트먼트 인터페이스의 제공부터 시작한다. 도 9 는, 블록 122 에 제공될 수도 있는 예시적인 지불 커미트먼트 인터페이스 (160) 를 도시한 것이다. 도 9 로부터 알 수 있는 바와 같이, 지불 커미트먼트 인터페이스 (160) 는, 지불인 사용자가 수령인 사용자를 식별할 수도 있는 수령인 식별 필드 (162), 및 지불인 사용자가 적절한 커미트먼트에 대해 관련된 값을 입력할 수 있는 총액 필드 (amount field; 164) 를 포함할 수도 있다. 또한, 지불 커미트먼트 인터페이스 (160) 는 순환부 (168) 를 포함하여, 지불인 사용자로 하여금, 커미트먼트가 순환 중인지를 식별 (예를 들어, 네/아니오 라디오 버튼을 이용함) 하게 하고, 순환 데이터 필드 (169) 내의 순환 날짜 및 순환 주기 필드 (170) 내의 순환 주기를 특정하게 한다. 다른 예시적인 실시형태에서, 인터페이스 (160) 는 지불의 횟수 및 빈도, 예를 들어, "각 $0.10 의 25 개 의 커미트먼트를, 하루에 하나의 커미트먼트 행함." 과 같은 순환을 표시하는 다른 메커니즘을 제공할 수도 있다.
도 7 을 다시 참조하면, 블록 124 에서, 통신 모듈 (82) 은 (예를 들어, 웹 서버 (32) 또는 API 서버 (34) 를 통해) 지불인 사용자로부터의 지불 커미트먼트 정보를 수신하며, 그 지불 커미트먼트 정보는, 수령인 사용자에 대한 식별자, 총액, 날짜 및 상술된 순환 정보를 포함한다.
블록 126 에서, 지불가능 커미트먼트 등록 모듈 (70) 은, 커미트먼트 지불가능 테이블 (94) 내의 지불인 사용자에 대해, 지불 커미트먼트 정보에 기초하여, 지불 커미트먼트를 등록한다. 유사하게, 수신가능 커미트먼트 등록 모듈 (72) 은, 커미트먼트 수신가능 테이블 (96) 의 수령인 사용자에 대해 지불 커미트먼트를 등록한다. 또한, 수신가능 계산 모듈 (78) 은, 수신된 지불 커미트먼트 정보에 기초하여, 사용자 테이블 (92) 내의 지불인 사용자와 수령인 사용자 각각에 대한 커미트먼트 지불가능 밸런스와 커미트먼트 수신가능 밸런스를 계산하고 업데이트할 수도 있다.
결정 블록 128 에서, 상술된 바와 같이, 블록 126 에서 계산되고 사용자 테이블 (92) 에 반영된 업데이트된 커미트먼트 수신가능 밸런스는, 수신가능 계산 모듈 (78) 에 의해 계산된 위험-조정된 커미트먼트 수신가능 밸런스 (또는 총액) 일 수도 있다.
결정 블록 128 에서 보면, 커미트먼트 지불가능 밸런스의 업데이트 이후에 임계값 평가 모듈 (80) 은, 지불인에 대한 커미트먼트 지불가능 밸런스가 (예를 들 어, 사용자-레벨 또는 시스템-레벨 임계값으로 특정한) 지불가능 임계값을 펀딩하는 소정의 임계값을 초과하는지 여부를 결정한다. 지불인 사용자에 대한 커미트먼트 지불가능 밸런스가 임계값을 초과하지 않을 시에, 방법 (120) 은 블록 130 에서 종료한다.
한편, 지불인 사용자에 대한 커미트먼트 지불가능 밸런스가 펀딩 지불가능 임계값을 초과하는 경우에, 결정 블록 132 에서, 지불 할당 모듈 (84) 은, 수령인 사용자 (예를 들어, 벤더) 가 지불인 사용자의 커미트먼트 지불가능 밸런스 이상인 커미트먼트 수신가능 밸런스로 존재하는지 여부의 결정을 행한다. 상술된 바와 같이, 커미트먼트 수신가능 밸런스는, 일 예시적인 실시형태에서, 위험-조정된 커미트먼트 수신가능 밸런스이다. 결정 블록 132 에서 지불 할당 모듈 (84) 에 의해 수행된 결정은 펀딩 큐 (114) 의 탐색을 수행하는 지불 할당 모듈 (84) 을 포함하여, 지불인 사용자의 커미트먼트 지불가능 밸런스에 의해 배상할 수 있는 커미트먼트 수신가능 총액을 갖는 엔트리를 식별할 수도 있다. 또한, 펀딩 큐 (114) 의 탐색을 수행하는데 있어서, 지불 할당 모듈 (84) 은, 적합한 수령인 사용자를 식별하려고 할 경우에, 각각의 엔트리와 관련된 우선순위 데이터를 고려할 수도 있다.
결정 블록 132 에서, 지불 할당 모듈 (84) 이 수령인 사용자를 식별하는데 있어서 성공적일 경우에, 방법 (120) 은, 지불 프로세스가 지불인 사용자로부터 정해진 수령인 사용자로의 펀딩 지불을 달성하도록 개시되는 블록 134 로 진행한다.
본 발명의 다양한 실시형태에서, 블록 134 에서의 지불 프로세스의 개시가 다양한 형태로 취해질 수도 있다. 예를 들어, 소액결제 시스템 (24) 은, 블록 134 에서, 도 10 에 도시된 일 예시적인 실시형태인 지불가능 인터페이스 (172) 를 지불인 사용자에게 제공할 수도 있으며, 그 지불가능 인터페이스 (172) 는, (1) 그들의 커미트먼트 지불가능 밸런스가 임계값을 초과하고, (2) 다음으로, 지불인 사용자가 정해진 수령인 사용자에게 펀딩 지불을 행하도록 요구되었음을 지불인 사용자에게 전달한다. 본 발명의 일 예시적인 실시형태에서, 지불 할당 모듈 (34) 은, 결정 블록 132 에서, 펀딩 지불을 수신하기에 적합한 다수의 수령인 사용자를 실제로 식별할 수도 있다. 이런 예시적인 실시형태에서, 지불가능 인터페이스 (172) 는, 펀딩 지불을 수신하기 위해 적합한 수령인 사용자들 중 적어도 하나를 선택하는 메커니즘 (예를 들어, 라디오 박스) 과 함께, 적절한 수령인 사용자의 리스트 (174) 를 지불인 사용자에게 제공할 수도 있다.
또한, 도 10 에 도시된 지불가능 인터페이스 (172) 는, 지불인 사용자를 세틀먼트 시스템 (22) 으로 향하게 하기 위해 사용자-선택가능한 "지불 서비스로의 진행" 버튼 (176) 을 포함한다. 편리하게, 세틀먼트 시스템은, 지불인 사용자로 하여금, 선택된 수령인 사용자로의 펀딩 지불을 행하게 한다. 따라서, 버튼 (176) 의 선택은, 통신 모듈 (82) 을 이용하여, 소액결제 시스템 (24) 으로 하여금, 지불인 사용자 식별 정보, 수령인 사용자 식별 정보, 총액 정보 및 펀딩 총액 정보를 세틀먼트 시스템 (22) 으로 전달하게 할 수도 있다. 세틀먼트 시스템 (22) 이 허용된 웹-서비스인 경우에, 이 정보가 적절한 API 서버 (34) 를 통해 수신될 수도 있다. 그 후, 세틀먼트 시스템 (22) 의 세틀먼트 애플리케이션 (42) 이 흐름을 개시할 수도 있고, 그에 따라, 펀딩 거래 지불이 완료될 수도 있다.
본 발명의 또 다른 실시형태에서, 지불 할당 모듈 (84) 은, 블록 134 에서, 지불인 사용자에 의한 수동적 승인 또는 개재 없이, 펀딩 지불을 수령인 사용자에게 지급되게 하는 명령을 자동적으로 전달할 수도 있다. 예를 들어, 통신 모듈 (82) 을 이용하는 지불 할당 모듈 (84) 은 세틀먼트 시스템 (22) 에 명령을 전달하여, 수령인 사용자의 계좌로의 펀딩 지불을 수행할 수도 있다.
블록 134 에서, 세틀먼트 시스템 (22) 이 지불을 종료하기 위해 이용되는 경우에, 세틀먼트 시스템 (22) 은 확인 정보를 소액결제 시스템으로 되 전달할 수도 있으며, 여기서, 이 정보는 통신 모듈 (82) 에 의해 수신된 후, 등록 모듈 (70 및 72) 에 제공된다. 그 후, 펀딩 지불의 확인의 수신에 응답하여, 등록 모듈 (70 및 72) 은, 커미트먼트 테이블 (94 및 96) 내의 지불 커미트먼트를 언펀딩된 것으로서 플래깅할 수도 있다.
그 후, 방법 (120) 의 블록 134 로부터 이동하여, 그 방법 (120) 은 블록 136 에서 종료한다.
결정 블록 132 를 다시 참조하면, 지불 할당 모듈 (84) 이 커미트먼트 지불가능 밸런스 이상인 커미트먼트 수신가능 값을 갖는 펀딩 큐 (114) 내의 수령인 사용자를 정할 수 없을 시에, 지불 할당 모듈 (84) 은 소정의 임계값 이상인 커미트먼트 수신가능 밸런스를 갖는 수령인 사용자를 정하기 시작한다. 펀딩 큐 (114) 를 포함하는 본 발명의 예시적인 실시형태에서, 임계값 평가 모듈 (80) 은 이미 식별되며, 적절한 펀딩 지불가능 임계값을 초과하는 모든 커미트먼트 수신가 능 밸런스를, 펀딩 큐 (114) 내에 배치시킨다. 이 경우에, 지불 할당 모듈 (84) 은, 펀딩 지불을 수신하기 위해, 펀딩 큐 (114) 로부터 및 사용된 우선순위 방식에 따라, 그 다음의 커미트먼트 수신가능 밸런스를 선택한다. 본 발명에 대한 또 다른 실시형태에서는, 결정 블록 138 에서, 임계값 평가 모듈 (80) 은, 지불 할당 모듈 (84) 후에, 적합한 수령인 사용자로부터 동적으로 선택할 수도 있는, 적합한 수령인 사용자를 식별할 목적으로 커미트먼트 수신가능 밸런스 (예를 들어, 위험-조정되는 등) 에 대해 분석을 수행한다.
블록 138 에서, 지불 할당 모듈 (84) 이 적합한 수령인 사용자를 정할 수 없는 경우에 (예를 들어, 펀딩 큐 (114) 가 빈 경우), 방법 (120) 은 블록 136 으로 진행하여 종료된다. 한편, 적어도 하나의 적합한 수령인 사용자가 식별되는 경우에, 방법 (120) 은 블록 140 으로 진행하여, 지불인 사용자가 수령인 사용자에게 펀딩 지불을 지불 (pay) 하는 프로세스가 개시된다. 그 후, 그 방법 (120) 은 블록 140 으로부터 결정 블록 128 로 되 루핑한다.
도 8 은, 도 7 의 블록 126 의 콘텍스트 (context) 내에서 수행될 수도 있는 일 예시적인 방법 (127) 의 흐름도이다. 방법 (127) 은 특정한 수령인 사용자에 대해 위험-조정된 커미트먼트 수신가능 밸런스를 계산하기 위한 것이다. 수신가능 계산 모듈 (78) 이 방법 (127) 을 수행할 수도 있다.
블록 142 에서, 그 방법은, 커미트먼트 지불가능 테이블 (94) 의 탐색을 수행함으로써 수령인에게 펀딩된 커미트먼트의 식별부터 시작한다.
블록 144 에서, 모듈 (78) 은, 수령인 사용자에 대한 식별된 펀딩 커미트먼 트를 합산하여, 펀딩된 커미트먼트 수신가능 총액을 발생시킨다.
블록 146 에서, 모듈 (78) 은, 다시, 커미트먼트 지불가능 테이블 (94) 의 탐색을 수행함으로써, 수령인에 대한 언펀딩된 지불 커미트먼트를 식별한다.
블록 148 에서, 모듈 (78) 은, 적절한 수령인 사용자에 대한 언펀딩된 지불 커미트먼트를 합산하여, 언펀딩된 커미트먼트 수신가능 총액을 발생시킨다.
블록 150 으로 이동하면, 위험 모델 (112) 을 이용하여, 수신가능 계산 모듈 (78) 은, 위험 프로파일 함수를 언펀딩된 커미트먼트 수신가능 총액에 적용하여, 위험-조정된 언펀딩된 커미트먼트 수신가능 총액을 발생시킨다.
그 후, 블록 152 에서, 수신가능 계산 모듈 (78) 은 펀딩된 커미트먼트 수신가능 총액과 위험-조정된 언펀딩 커미트먼트 수신가능 총액을 합산하여, 그 후, 사용자 테이블 (92) 로 기록되거나 또는 소액결제 시스템 (24) 내에 저장될 수도 있는 위험-조정된 커미트먼트 수신가능 값 총액을 발생시킨다. 그 후, 방법 (127) 은 블록 154 에서 종료한다.
위험 조정이 수령인 사용자에 대해 언펀딩된 커미트먼트에 관하여 수행되는 것으로 상술되었지만, 본 발명이 이렇게 제한되는 것은 아니다. 본 발명의 또 다른 실시형태에서, 위험 조정은 전체적인 커미트먼트 수신가능 총액에 관하여 수행될 수도 있고, 언펀딩된 컴포넌트에 대해서만 수행될 필요는 없다.
도 11 은, 각각의 웹 서버 (32) 를 통해 소액결제 시스템 (24) 의 사용자에게 제공될 수도 있는 예시적인 지불 커미트먼트 수신 인터페이스 (180) 를 도시한 것이다. 상세하게는, 지불인 사용자로부터의 지불 커미트먼트의 수신을 수령인 사용자에게 알리기 위하여, 인터페이스 (180) 가 수령인 사용자에게 제공될 수도 있다. 이러한 목적으로, 인터페이스 (180) 는, 지불인 필드 (182) 를 통해, 수령인 사용자에 대한 지불인 사용자를 식별할 수도 있고, 또한, 지불 커미트먼트의 총액을 총액 필드 (184) 내에 전달할 수도 있다.
또한, 인터페이스 (180) 는, 상술된 방식으로 계산된, 수신가능한 총 언펀딩된 커미트먼트 (190), 수신가능한 총 펀딩된 커미트먼트 (192), 수신가능한 총 커미트먼트 (194), 및 위험-조정된 커미트먼트 수신가능 총액 (196) 을, 수령인 사용자에게 전달하는 계산서 부 (statement portion; 188) 를 포함하도록 도시된다.
또한, 본 발명의 일 실시형태에서, 소액결제 시스템 (24) 은, 수령인 사용자로 하여금, 수령인 사용자가 펀딩 지불을 수신하길 좋아하는 적합한 지불인 사용자의 리스트로부터 선택하게 할 수도 있다. 이러한 목적으로, 도 12 는, 수령인 사용자에게 제공될 수도 있는 일 예시적인 지불가능 인터페이스 (198) 를 도시한 것으로, 이는, 커미트먼트 수신가능 밸런스가 펀딩 지불에 적합한 임계값을 초과함을 수령인 사용자에게 알리고, 또한, 그 적합한 지불인이 지불하기에 적합한 총액과 함께, 적합한 지불인의 리스트 (199) 를 제공한다. 또한, 지불가능 인터페이스 (198) 는, 상술된 방식으로, 소액결제 시스템 (24) 과 세틀먼트 시스템 (22) 간의 상호작용을 개시할 수도 있는 "지불 서비스로의 진행" 버튼 (176) 을 포함한다.
도 13 은, 머신으로 하여금, 여기에서 기술된 임의의 하나 이상의 방법을 수행하게 하기 위한 일 세트의 명령이 실행될 수도 있는 컴퓨터 시스템 (200) 의 예 시적인 형태로 머신의 도식적인 도면을 나타낸 것이다. 또 다른 실시형태에서, 머신은 자립형 장치로서 동작하거나 다른 머신에 접속 (예를 들어, 네트워킹) 될 수도 있다. 네트워킹된 배치에 있어서, 머신은 서버-클라이언트 네트워크 환경에서 서버 또는 클라이언트 머신의 용량 (capacity) 으로 동작할 수도 있고, 또는 피어-투-피어 (또는 분산) 네트워크 환경에서 피어 머신으로서 동작할 수도 있다. 그 머신은, 개인용 컴퓨터 (PC), 태블릿 (tablet) PC, 셋-톱 박스 (STB), 개인용 휴대정보 단말기 (PDA), 셀룰러 전화, 웹 애플리언스 (wep appliance), 네트워크 라우터, 스위치 또는 브리지, 또는 그 머신에 의해 취해질 액션을 특정하는 (그렇지 않으면, 순차적인) 일 세트의 명령을 실행시킬 수 있는 임의의 머신일 수도 있다. 또한, 오직 단일의 머신이 도시되었지만, "머신" 이란, 이하 기술된 임의의 하나 이상의 방법을 수행하기 위한 일 세트의 (또는 다중 세트의) 명령을, 개별적으로 또는 공동으로 실행시키는 임의의 머신의 콜렉션 (collection) 을 포함하게 될 수도 있다.
예시적인 컴퓨터 시스템 (200) 은, 버스 (208) 를 통해 서로 통신하는, 프로세서 (202; 예를 들어, 중앙 프로세싱 유닛 (CPU), 그래픽 프로세싱 유닛 (GPU) 또는 둘다), 메인 메모리 (204) 및 정적 메모리 (206) 를 포함한다. 컴퓨터 시스템 (200) 은, 비디오 디스플레이 유닛 (210; 예를 들어, 액정 디스플레이 (LCD) 또는 음극 선관 (CRT)) 을 더 포함할 수도 있다. 또한, 컴퓨터 시스템 (200) 은, 영숫자 입력 장치 (212; 예를 들어, 키보드), 사용자 인터페이스 (UI) 네비게이션 장치 (214; 예를 들어, 마우스), 디스크 구동 유닛 (216), 신호 발생 장치 (218; 예를 들어, 스피커), 및 네트워크 인터페이스 장치 (220) 를 포함한다.
디스크 구동 유닛 (216) 은, 여기에서 기술된 임의의 하나 이상의 방법 또는 기능을 수록하거나 상기 방법 또는 기능에 의해 이용되는 하나 이상의 세트의 명령 및 데이터 구조 (예를 들어, 소프트웨어 (224)) 가 저장된 머신-판독가능 매체 (222) 를 포함한다. 또한, 소프트웨어 (224) 는, 컴퓨터 시스템 (200) 에 의한 실행 동안, 메인 메모리(204) 내에 및/또는 프로세서 (202) 내에, 완전히 또는 적어도 부분적으로 상주할 수도 있으며, 또한, 그 메인 메모리 (204) 와 프로세서 (202) 는 머신-판독가능 매체를 구성한다.
또한, 소프트웨어 (224) 는, 다수의 널리 공지된 이체 프로토콜 (예를 들어, HTTP) 중 임의의 하나를 이용하여 네트워크 인터페이스 장치 (220) 를 통해, 네트워크 (226) 위로 송신 또는 수신될 수도 있다.
머신-판독가능 매체 (292) 가, 일 실시형태에서는, 단일의 매체인 것으로 도시되었지만, "머신-판독가능 매체" 란, 하나 이상의 세트의 명령을 저장하는 단일의 매체 또는 다중의 매체 (예를 들어, 집중되거나 분산된 데이터베이스, 및/또는 해당 캐시 (caches) 및 서버) 를 포함하도록 해석되어야 한다. 또한, "머신-판독가능 매체" 란, 머신에 의해 실행하기 위한 일 세트의 명령을 저장, 인코딩 또는 반송할 수 있고, 머신으로 하여금, 본 발명의 임의의 하나 이상의 방법을 수행하게 하거나, 이러한 일 세트의 명령에 의해 이용되거나 그 명령과 관련된 데이터 구조를 저장, 인코딩 또는 반송할 수 있는 임의의 매체를 포함하도록 해석되어야 한다. 따라서, "머신-판독가능 매체" 란, 제한하려는 것은 아니지만, 고체 메모리 (solid-state memories), 광학 및 자기 매체, 및 반송파 신호를 포함하도록 해석되어야 한다.
따라서, 벤더에게, 소액결제의 이체를 할 수 있게 하는 방법 및 시스템이 설명되었다. 본 발명이 특정 예시적인 실시형태를 참조하여 설명되었지만, 다양한 변형 및 변경이, 본 발명의 더 광범위한 정신 및 범위로부터 벗어나지 않고 이들 실시형태에 대해 행해질 수도 있다는 것을 알 수 있다. 따라서, 설명 및 도면은 제한적이라기보다는 예시적인 것으로 간주되어야 한다.

Claims (60)

  1. 복수의 당사자들 간의 소액결제를 용이하게 하는 시스템으로서,
    데이터베이스내의 제 1 당사자에 의해 행해지고, 상기 제 1 당사자에 대한 총 커미트먼트 지불가능 값에 대해 기여하는 제 1 복수의 지불 커미트먼트를 등록하며, 그리고, 상기 데이터베이스내의 제 2 당사자에게 행해지고, 상기 제 2 당사자에 대한 총 커미트먼트 수신가능 값에 대해 기여하는 제 2 복수의 지불 커미트먼트를 등록하는 등록 모듈;
    상기 데이터베이스로부터 위험 표시를 검색하고, 상기 위험 표시를 이용하여, 상기 제 2 당사자에 대한 총 커미트먼트 수신가능 값을 계산하는 계산 모듈; 및
    상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별하고, 그 결정에 응답하여, 상기 제 2 당사자로의, 상기 제 1 당사자에 의한 상기 총 커미트먼트 수신가능 값의 지불에 대한 지불 프로세스를 개시하는 지불 애플리케이션 모듈을 포함하는, 소액결제를 용이하게 하는 시스템.
  2. 제 1 항에 있어서,
    상기 계산 모듈은, 지불인 사용자 (payor user) 에 의해 펀딩된 것으로서, 상기 제 2 복수의 지불 커미트먼트의 펀딩된 세트를 식별하고, 지불인 사용자에 의 해 언펀딩된 것으로서, 상기 제 2 복수의 지불 커미트먼트의 언펀딩된 세트를 식별하게 하며,
    상기 계산 모듈은, 또한, 상기 총 커미트먼트 수신가능 값의 총 언펀딩된 커미트먼트 값 부분을 계산하기 위해, 상기 위험 표시를 이용하는 함수를 지불 커미트먼트의 상기 언펀딩된 세트에 적용함으로써 상기 총 커미트먼트 수신가능 값을 계산하는, 소액결제를 용이하게 하는 시스템.
  3. 제 1 항에 있어서,
    상기 위험 표시는 상기 제 1 당사자 및 상기 제 2 당사자 중 적어도 하나와 관련된 위험 프로파일을 포함하는, 소액결제를 용이하게 하는 시스템.
  4. 제 3 항에 있어서,
    상기 위험 프로파일은 임의의 하나 이상의 위험 표시자의 그룹을 이용하여 결정되며,
    상기 위험 표시자의 그룹은, 거래 이력, 지불 이력, 거래 피드백, 및 지불 피드백을 포함하는, 소액결제를 용이하게 하는 시스템.
  5. 제 1 항에 있어서,
    상기 제 1 당사자에 의해 행해지는 상기 제 1 복수의 지불 커미트먼트가 복수의 수령인 당사자 (payee parties) 들에게 행해지게 되는, 소액결제를 용이하게 하는 시스템.
  6. 제 5 항에 있어서,
    상기 복수의 수령인 당사자들은 상기 제 2 당사자를 포함하는, 소액결제를 용이하게 하는 시스템.
  7. 제 1 항에 있어서,
    상기 제 2 당사자에게 행해지는 상기 제 2 복수의 지불 커미트먼트는 복수의 지불인 당사자에 의해 행해지게 되는, 소액결제를 용이하게 하는 시스템.
  8. 제 7 항에 있어서,
    상기 복수의 지불인 당사자들은 상기 제 1 당사자를 포함하는, 소액결제를 용이하게 하는 시스템.
  9. 제 1 항에 있어서,
    상기 제 1 당사자에 의해 행해지는 상기 제 1 복수의 지불 커미트먼트는 시간 주기에 걸쳐 행해지게 되며,
    상기 총 커미트먼트 지불가능 값은, 상기 제 1 복수의 지불 커미트먼트의 각각의 지불 커미트먼트를 반영하기 위해 상기 시간 주기에 걸쳐 변하는, 소액결제를 용이하게 하는 시스템.
  10. 제 1 항에 있어서,
    상기 제 2 당사자에게 행해지는 상기 제 2 복수의 지불 커미트먼트는 시간 주기에 걸쳐 행해지게 되며,
    상기 총 커미트먼트 수신가능 값은, 상기 제 2 복수의 지불 커미트먼트의 각각의 지불 커미트먼트를 반영하기 위해 상기 시간 주기에 걸쳐 변하는, 소액결제를 용이하게 하는 시스템.
  11. 제 1 항에 있어서,
    상기 등록 모듈은, 상기 제 1 당사자와 제 2 당사자가 네트워크를 통해 동작적으로 커플링하는 서버에 상주하며,
    상기 등록 모듈은, 상기 서버에, 상기 제 1 복수의 지불 커미트먼트 및 제 2 복수의 지불 커미트먼트 각각을 등록하는, 소액결제를 용이하게 하는 시스템.
  12. 제 1 항에 있어서,
    상기 등록 모듈은, 각각, 상기 제 1 당사자 및 제 2 당사자와 관련된 제 1 머신 및 제 2 머신 중 적어도 하나에 상주하며,
    상기 등록 모듈은, 상기 제 1 머신 및 제 2 머신 중 적어도 하나에서 행해지게 되는 상기 제 1 복수의 지불 커미트먼트와 제 2 복수의 지불 커미트먼트 각각을 등록하는, 소액결제를 용이하게 하는 시스템.
  13. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 총 커미트먼트 수신가능 값이 소정의 임계값을 초과한 이후에, 상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별하는, 소액결제를 용이하게 하는 시스템.
  14. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값이 소정의 임계값을 초과하는지 여부를 결정하며, 임계값을 초과한다면, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 펀딩 큐에 할당하는, 소액결제를 용이하게 하는 시스템.
  15. 제 14 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 펀딩 큐에 할당되어진 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별함으로써, 상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별하는, 소액결제를 용이하게 하는 시스템.
  16. 제 15 항에 있어서,
    복수의 각각의 제 3 당사자에 대한 복수의 수신가능 값이 상기 펀딩 큐에 할당되며,
    상기 지불 애플리케이션 모듈은, 상기 복수의 수신가능 값을 상기 제 1 당사자에게 전달하고, 상기 수신가능 값들 중 적어도 하나의 상기 제 1 당사자에 의한 선택으로 하여금, 상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상되게 할 수 있는, 소액결제를 용이하게 하는 시스템.
  17. 제 16 항에 있어서,
    상기 제 1 당사자로의 상기 복수의 수신가능 값의 전달은, 상기 제 1 당사자에 대한 상기 각각의 제 3 당사자를 식별하는 단계를 포함하는, 소액결제를 용이하게 하는 시스템.
  18. 제 13 항에 있어서,
    상기 소정의 임계값은 제 2 사용자와 시스템의 관리자 중 적어도 하나에 의해 결정되는, 소액결제를 용이하게 하는 시스템.
  19. 제 13 항에 있어서,
    상기 소정의 임계값은 제 2 사용자와 관련된 속성에 의해 결정되는, 소액결제를 용이하게 하는 시스템.
  20. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 총 커미트먼트 지불가능 값이 소정의 지불 임계값을 초과한 이후에, 상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별하는, 소액결제를 용이하게 하는 시스템.
  21. 제 20 항에 있어서,
    상기 소정의 임계값은 제 1 사용자 및 시스템의 관리자 중 적어도 하나에 의해 결정되는, 소액결제를 용이하게 하는 시스템.
  22. 제 20 항에 있어서,
    상기 소정의 임계값은 제 1 사용자와 관련된 속성에 의해 결정되는, 소액결제를 용이하게 하는 시스템.
  23. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 네트워크에 커플링된 서버에 상주하며,
    상기 제 2 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서의, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값의 식별이 상기 서버에서 수행되는, 소액결제를 용이하게 하는 시스템.
  24. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 각각, 상기 제 1 당사자 및 제 2 당사자와 관련된 제 1 클라이언트 머신 및 제 2 클라이언트 머신 중 적어도 하나에 상주하며,
    상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서의, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값의 상기 식별이 상기 제 1 클라이언트 머신 및 제 2 클라이언트 머신 중 적어도 하나에서 수행되는, 소액결제를 용이하게 하는 시스템.
  25. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 총 커미트먼트 수신가능 값의 지불을 상기 제 2 당사자에게 행하도록 상기 제 1 당사자에게 명령을 제공함으로써, 상기 지불 프로세스를 개시하는, 소액결제를 용이하게 하는 시스템.
  26. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 제 1 당사자로부터 수신될 상기 총 커미트먼트 수신가능 값의 지불의 수신에 관해서 상기 제 2 당사자에게 통신을 제공함으로써, 상기 지불 프로세스를 개시하는, 소액결제를 용이하게 하는 시스템.
  27. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 제 1 당사자가 상기 제 2 당사자로의 상기 총 커미트먼트 수신가능 값의 지불을 행할 수 있음을 이용하여, 지불 서비스에 대해, 상기 제 1 당사자에 의한 지불 프로세스를 개시하게 하는, 소액결제를 용이하게 하는 시스템.
  28. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 제 2 당사자가 상기 총 커미트먼트 수신가능 값의 지불을 수신할 수 있음을 이용하여, 지불 시스템에 대해 상기 제 2 당사자를 정정함으로써 상기 지불 프로세스를 개시하는, 소액결제를 용이하게 하는 시스템.
  29. 제 1 항에 있어서,
    상기 지불 애플리케이션 모듈은, 상기 총 커미트먼트 수신가능 값을 상기 제 1 사용자의 계좌로부터 상기 제 2 사용자에게 자동으로 이체함으로써, 상기 지불 프로세스를 개시하는, 소액결제를 용이하게 하는 시스템.
  30. 제 1 항에 있어서,
    상기 등록 모듈은, 복수의 제 3 당사자들 중 적어도 하나에 대해, 상기 제 1 당사자에 의한 순환 지불 커미트먼트를 등록하며, 상기 순환 지불 커미트먼트에 따 라, 지불 커미트먼트를 등록하는, 소액결제를 용이하게 하는 시스템.
  31. 복수의 당사자들 간의 소액결제를 용이하게 하는 방법으로서,
    제 1 당사자에 의해 행해지고, 상기 제 1 당사자에 대한 총 커미트먼트 지불가능 값에 대해 기여하는 제 1 복수의 지불 커미트먼트를 등록하는 단계;
    제 2 당사자에게 행해지고, 상기 제 2 당사자에 대한 총 커미트먼트 수신가능 값에 대해 기여하는 제 2 복수의 지불 커미트먼트를 등록하는 단계;
    위험 표시를 이용하여, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 계산하는 단계;
    상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별하는 단계; 및
    그 결정에 응답하여, 상기 제 2 당사자로의, 상기 제 1 당사자에 의한 상기 총 커미트먼트 수신가능 값의 지불을 위한 지불 프로세스를 개시하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  32. 제 31 항에 있어서,
    지불인 사용자에 의해 펀딩된 것으로서, 상기 제 2 복수의 지불 커미트먼트의 펀딩 세트를 식별하고, 지불인 사용자에 의해 언펀딩된 것으로서, 상기 제 2 복수의 지불 커미트먼트의 언펀딩 세트를 식별하는 단계를 포함하며,
    상기 총 커미트먼트 수신가능 값의 계산 단계는, 상기 총 커미트먼트 수신가능 값의 총 언펀딩 커미트먼트 값 부분을 계산하기 위해, 상기 위험 표시를 이용하는 함수를 지불 커미트먼트의 상기 언펀딩 세트에 적용하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  33. 제 31 항에 있어서,
    상기 위험 표시는, 상기 제 1 당사자 및 제 2 당사자 중 적어도 하나와 관련된 위험 프로파일을 포함하는, 소액결제를 용이하게 하는 방법.
  34. 제 33 항에 있어서,
    상기 위험 프로파일은, 임의의 하나 이상의 위험 표시자의 그룹을 이용하여 결정되며,
    상기 위험 표시자의 그룹은, 거래 이력, 지불 이력, 거래 피드백, 및 지불 피드백을 포함하는, 소액결제를 용이하게 하는 방법.
  35. 제 31 항에 있어서,
    상기 제 1 당사자에 의해 행해지는 상기 제 1 복수의 지불 커미트먼트는 복수의 수령인 당사자에게 행해지게 되는, 소액결제를 용이하게 하는 방법.
  36. 제 35 항에 있어서,
    상기 복수의 수령인 당사자는 상기 제 2 당사자를 포함하는, 소액결제를 용이하게 하는 방법.
  37. 제 31 항에 있어서,
    상기 제 2 당사자에게 행해지는 상기 제 2 복수의 지불 커미트먼트는 복수의 지불인 당사자에 의해 행해지게 되는, 소액결제를 용이하게 하는 방법.
  38. 제 37 항에 있어서,
    상기 복수의 지불인 당사자는 상기 제 1 당사자를 포함하는, 소액결제를 용이하게 하는 방법.
  39. 제 31 항에 있어서,
    상기 제 1 당사자에 의해 행해지는 상기 제 1 복수의 지불 커미트먼트는 시간 주기에 걸쳐 행해지게 되며,
    상기 총 커미트먼트 지불가능 값은, 상기 제 1 복수의 지불 커미트먼트의 각각의 지불 커미트먼트를 반영하기 위해 상기 시간 주기에 걸쳐 변형되는, 소액결제를 용이하게 하는 방법.
  40. 제 31 항에 있어서,
    상기 제 2 당사자에게 행해지는 상기 제 2 복수의 지불 커미트먼트는 시간 주기에 걸쳐 행해지게 되며,
    상기 총 커미트먼트 수신가능 값은, 상기 제 2 복수의 지불 커미트먼트의 각각의 지불 커미트먼트를 반영하기 위해 상기 시간 주기에 걸쳐 변형되는, 소액결제를 용이하게 하는 방법.
  41. 제 31 항에 있어서,
    상기 제 1 복수의 지불 커미트먼트 및 제 2 복수의 지불 커미트먼트 각각의 등록 단계는, 상기 제 1 당사자 및 제 2 당사자가 네트워크를 통해 커플링된 서버에서 행해지게 되는, 소액결제를 용이하게 하는 방법.
  42. 제 31 항에 있어서,
    상기 제 1 복수의 지불 커미트먼트 및 제 2 복수의 지불 커미트먼트 각각의 상기 등록 단계는, 각각, 상기 제 1 당사자 및 제 2 당사자와 관련되어, 네트워크를 통해 커플링된 각각의 제 1 머신 및 제 2 머신에서 행해지게 되는, 소액결제를 용이하게 하는 방법.
  43. 제 31 항에 있어서,
    상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값의 식별은, 상기 총 커미트먼트 수신가능 값이 소정의 임계값을 초과한 이후에 수행되는, 소액결제를 용이하게 하는 방법.
  44. 제 31 항에 있어서,
    상기 총 커미트먼트 수신가능 값이 소정의 임계값을 초과하는지를 식별하고, 임계값을 초과한다면, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 펀딩 큐에 할당하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  45. 제 44 항에 있어서,
    상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상할 수 있는 것으로서의, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값의 상기 식별은, 상기 펀딩 큐에 할당된 것으로서, 상기 제 2 당사자에 대한 상기 총 커미트먼트 수신가능 값을 식별하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  46. 제 45 항에 있어서,
    복수의 각각의 제 3 당사자에 대한 복수의 수신가능 값이 상기 펀딩 큐에 할당되며,
    상기 방법은, 상기 제 1 당사자에 대한 상기 복수의 수신가능 값을 식별하고, 상기 수신가능 값들 중 적어도 하나의 상기 제 1 당사자에 의한 선택으로 하여금, 상기 제 1 당사자에 대한 상기 총 커미트먼트 지불가능 값에 의해 배상되게 할 수 있는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  47. 제 46 항에 있어서,
    상기 복수의 수신가능 값의 식별은, 상기 제 1 당사자에 대해 상기 각각의 제 3 당사자를 식별하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  48. 제 43 항에 있어서,
    상기 소정의 임계값은 제 2 사용자에 의해 결정되는, 소액결제를 용이하게 하는 방법.
  49. 제 43 항에 있어서,
    상기 소정의 임계값은 제 2 사용자와 관련된 속성에 의해 결정되는, 소액결제를 용이하게 하는 방법.
  50. 제 31 항에 있어서,
    상기 결정은, 상기 총 커미트먼트 지불가능 값이 소정의 임계값을 초과할 경우에 수행되는, 소액결제를 용이하게 하는 방법.
  51. 제 50 항에 있어서,
    상기 소정의 임계값은 제 1 사용자에 의해 결정되는, 소액결제를 용이하게 하는 방법.
  52. 제 50 항에 있어서,
    상기 소정의 임계값은 제 1 사용자와 관련된 속성에 의해 결정되는, 소액결제를 용이하게 하는 방법.
  53. 제 31 항에 있어서,
    상기 결정은 상기 서버에서 수행되는, 소액결제를 용이하게 하는 방법.
  54. 제 31 항에 있어서,
    상기 결정은, 각각, 상기 제 1 당사자 및 제 2 당사자와 관련된 제 1 머신 및 제 2 머신 중 임의의 하나의 머신에서 수행되는, 소액결제를 용이하게 하는 방법.
  55. 제 31 항에 있어서,
    상기 지불 프로세스의 개시는, 상기 총 커미트먼트 수신가능 값의 지불을 상기 제 2 당사자에게 행하도록, 상기 제 1 당사자에게 명령을 제공하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  56. 제 31 항에 있어서,
    상기 지불 프로세스의 개시는, 상기 제 1 당사자로부터 수신될 상기 총 커미 트먼트 수신가능 값의 지불의 수신에 관해서 상기 제 2 당사자에게 통신을 제공하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  57. 제 31 항에 있어서,
    상기 지불 프로세스의 개시는, 상기 제 1 당사자가 상기 총 커미트먼트 수신가능 값의 지불을 상기 제 2 당사자에게 행할 수 있음을 이용하여, 제 1 당사자를 지불 서비스로 향하게 하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  58. 제 31 항에 있어서,
    상기 지불 프로세스의 개시는, 상기 제 2 당사자가 상기 총 커미트먼트 수신가능 값의 지불을 수신할 수 있음을 이용하여, 상기 제 2 당사자를 지불 시스템으로 향하게 하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  59. 제 31 항에 있어서,
    상기 지불 프로세스의 개시는, 상기 총 커미트먼트 수신가능 값을 제 1 사용자의 계좌로부터 제 2 사용자에게 자동으로 이체하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
  60. 제 31 항에 있어서,
    제 1 복수의 제 3 당사자들 중 적어도 하나로의 상기 제 1 당사자에 의한 순 환 지불 커미트먼트를 등록하고, 상기 순환 지불 커미트먼트에 따라, 지불 커미트먼트를 등록하는 단계를 포함하는, 소액결제를 용이하게 하는 방법.
KR1020067011292A 2006-06-08 2003-11-10 복수의 당사자들 간의 소액결제의 용이화 KR100847710B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020067011292A KR100847710B1 (ko) 2006-06-08 2003-11-10 복수의 당사자들 간의 소액결제의 용이화

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020067011292A KR100847710B1 (ko) 2006-06-08 2003-11-10 복수의 당사자들 간의 소액결제의 용이화

Publications (2)

Publication Number Publication Date
KR20060087614A true KR20060087614A (ko) 2006-08-02
KR100847710B1 KR100847710B1 (ko) 2008-07-23

Family

ID=37176324

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067011292A KR100847710B1 (ko) 2006-06-08 2003-11-10 복수의 당사자들 간의 소액결제의 용이화

Country Status (1)

Country Link
KR (1) KR100847710B1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109891450A (zh) * 2016-12-13 2019-06-14 连株式会社 支付方法及系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5999919A (en) 1997-02-26 1999-12-07 At&T Efficient micropayment system
US6450407B1 (en) 1998-04-17 2002-09-17 Viztec, Inc. Chip card rebate system
KR20020004779A (ko) * 2000-07-05 2002-01-16 김봉섭 네트워크를 통한 부분 결제 시스템 및 그 방법
KR100458508B1 (ko) * 2001-04-18 2004-12-03 나인포유 주식회사 인터넷상에서의 다중 결제 시스템 및 이를 이용한 다중결제 방법

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109891450A (zh) * 2016-12-13 2019-06-14 连株式会社 支付方法及系统
CN109891450B (zh) * 2016-12-13 2023-09-22 连株式会社 支付方法及系统

Also Published As

Publication number Publication date
KR100847710B1 (ko) 2008-07-23

Similar Documents

Publication Publication Date Title
US7702584B2 (en) Method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor
US10664832B2 (en) Virtual wallet account with automatic-loading
US20190197503A1 (en) Release of funds based on criteria
US10922694B2 (en) Automatic teller machine (ATM) electronic push requests
US8682784B2 (en) Method and system to process credit card payment transactions initiated by a merchant
US20110276474A1 (en) Method for Facilitating Payment of a Computerized Transaction
US20140025564A1 (en) System for aggregating payments from multiple payers
US20120095873A1 (en) Escrow management system for marketplaces
US20090276306A1 (en) Utilizing an electronic payment system to implement rebate programs
US20230141912A1 (en) Peer-to-peer transfer of a stored value
US20190378182A1 (en) Secure electronic billing with real-time funds availability
US11727394B2 (en) Systems and methods for managing electronic transactions
US10902391B2 (en) Automated transaction system
US20090164369A1 (en) Person-to-person payments: contextual spending
JP2019212231A (ja) 情報処理装置、情報処理方法及びプログラム
KR102384946B1 (ko) 금융 서비스 제공 방법 및 이를 수행하는 전자 장치
KR100847710B1 (ko) 복수의 당사자들 간의 소액결제의 용이화
KR101892188B1 (ko) 결제 서비스 제공 장치, 방법, 기록매체 및 결제 페이지 획득 방법을 실행하기 위한 컴퓨터 프로그램
KR101914759B1 (ko) 결제 서비스 제공 장치, 방법 및 이를 실행하기 위한 컴퓨터 기록매체
US20220284414A1 (en) System and method for managing value transfer cards
JP7280060B2 (ja) 決済一括管理サーバ、決済情報生成方法及びプログラム
KR20240028328A (ko) 신용 기반의 커미션 분할 전자 결제 네트워크를 위한 시스템 및 방법
CN115564415A (zh) 一种订单支付结算的方法和装置
KR20180123996A (ko) 결제 서비스 제공 장치, 방법 및 이를 실행하기 위한 컴퓨터 기록매체
KR20180099591A (ko) 결제 서비스 제공 장치, 방법, 기록매체 및 결제 페이지 획득 방법을 실행하기 위한 컴퓨터 프로그램

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130620

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20140701

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20150618

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20160616

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20170616

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20190617

Year of fee payment: 12