KR100809885B1

KR100809885B1 - 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 시스템 및 방법

Info

Publication number: KR100809885B1
Application number: KR1020040097777A
Authority: KR
Inventors: 노리스 코모도르; 폴에프. 크레센조; 마리제이. 구이몬드; 제인이. 보그트
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2003-12-26
Filing date: 2004-11-26
Publication date: 2008-03-06
Also published as: CN1637758A; JP2005196760A; US20050144126A1; KR20050066993A

Abstract

본 발명에 따른 시스템, 서비스, 컴퓨터 판독가능 기록매체 및 관련 방법은 인터넷을 통한 신용카드 구매의 용이함과 통상의 임대의 유연성을 결합한다. 본 발명에 따른 융자 주문 시스템은 신용 승인, 임대 구조 및 금리, 적용 계약 조건과 같은 고객 자격 프로세스를 안전한 전자 전달 및 e-서명과 같은 안전한 전자 배달 및 합법적으로 강화할 수 있는 문서 기록 보존(archiving)과 함께 사전에 패키지한다. 본 시스템은 내부 관리 비용을 줄이고, 현재의 비즈니스 프로세스의 속도를 높이며, 엔드 유저 및 판매자와의 비즈니스를 더욱 용이하게 하는 이점을 상인에게 제공한다. 본 시스템은 융자 회사의 요건을 만족시키는 안전한 합법적 강화 문서를 생성한다. 상인은, 예를 들어 소프트웨어 보조화폐, CD ROM, 스마트 카드 매체에 의해 융자 주문 시스템에 소프트웨어를 제공한다. 본 시스템은 고정된 신용 한도나 지불 구조를 갖지 않고, 완전히 암호화되어 안전하며, 입력/출력 내의 비 사유 오픈 표준 아키텍처(non-proprietary open standards)를 이용하여 임의의 판매자의 웹사이트에 편리하게 통합한다.

Description

네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR IMPLEMENTING FINANCING ON DEMAND SERVICE}

도 1은 본 발명의 융자 주문(financing on demand)을 구현하기 위한 시스템 및 방법이 이용될 수 있는 전형적인 동작 환경의 개략도.

도 2는 도 1의 융자 주문의 동작 방법을 도시한 프로세스 순서도.

도 3은 도 1 및 2의 시스템 및 방법의 전형적인 고레벨 계층을 도시한 도면.

도 4는 본 발명의 융자 주문 시스템 및 방법을 이용하여, 고객의 자격 및 기본계약(master agreement)의 생성 방법을 도시한 프로세스 순서도.

도 5는 고객이 본 발명의 융자 주문에 대한 주문을 하는 방식을 도시한 프로세스 순서도.

도 6은 도 6a 및 6b로 이루어지며, 상품이 주문되고 대여되는 방법을 도시한 프로세스 순서도.

도면의 주요 부분에 대한 부호의 설명

10 : 융자 주문 시스템

15 : 호스트 서버

20 : 네트워크

25, 27 : 서버

30 : 게이트웨이

215 : 사용자

225 : 온라인 계약 서버

230 : 게이트웨이

235 : 프로세싱 네트워크

240 : 융자 회사 서버

245 : 상인 은행 서버

본 발명은 일반적으로 상업 융자(commercial financing) 분야에 관한 것으로, 특히 안전하고, 커스텀화 가능하며, 컴퓨터 거래 발생 시에 주문형으로 이용가능한 인터넷을 통해 고가의 상용 판매(commercial sales)에 자금을 융자하기 위한 소프트웨어 시스템, 컴퓨터 판독가능 기록매체 , 서비스 및 관련 방법에 관한 것이다. 보다 구체적으로는 본 발명은 대출 인증, 임대 구조 및 금리, 기간 및 조건과 같은 고객에 대한 자격인증 프로세스(entitlement process)를 안전한 전자 전달 및 e-서명과 같은 합법적으로 강화할 수 있는 문서들과 함께 미리 설정(prepackage)하고, 통상의 서류-집약적인(paper-intensive) 상품 임대 프로세스를 자동화하고, 인터넷을 통해 상품을 융자하는 새로운 방법을 제공하는 e-비즈니스 방법에 관한 것이다.

WWW(World Wide Web) 또는 인터넷은 전 세계에 걸쳐 비즈니스, 정부, 그룹 및 개인이 웹페이지라고 하는 서로 링크되어 있는(inter-linked) 컴퓨터 파일을 유지하는 상호 접속된 컴퓨터의 확장 네트워크로 이루어진다. 원래 인터넷은 정보 전달을 위해 고안되었다. 보다 최근에는, 인터넷은 전자 카탈로그와 같이 사용자를 위한 쇼핑 툴로서 점점 더 많이 사용되고 있다. 인터넷을 통해 제품을 구매하는 인터넷 사용자의 수가 증가함에 따라 제품 판매 방법에 있어서 큰 변화가 발생하였는데, 즉 일반적인 비즈니스 모델로부터 전자 비즈니스 또는 e-비즈니스 모델로 전환하고 있다.

인터넷 상에서 구매 거래를 도입함에 따라 고객과 e-비즈니스 상인(merchant) 사이에 안전한 금융 거래가 필요하게 되었다. 수많은 지불 시스템이 상인의 다양한 처리 요구를 수용하도록 고안되었다. 예를 들면, 몇몇 금융 회사는 상인에게 인터넷 상인은행(merchant bank) 계정을 제공하여, 그들이 신용 카드 거래를 수용할 수 있도록 한다.

이들 회사는 신용 카드 거래를 수행하기 위한 "전자 지갑(wallet)" 방법을 이용한다. 전자 지갑을 개시할 때, 소비자는 통상 인터넷을 통해 신용 카드 정보를 금융 회사에 제공한다. 그 다음에, 소비자는 그 신용 카드를 나타내는 암호화된 코드를 수신한다. 웹 상인에게서 구매할 때, 소비자는 전자 지갑 코드를 상인에게 제공한다. 상인은 그 코드를 구매 가격에 첨부하여 이 둘 모두를 전자 지갑을 발행한 금융 회사에 보낸다. 금융 회사는 신용 카드 회사와의 거래를 인증하고, 그 다음에 상품을 발송하도록 인증과 함께 자금을 상인에게 전달한다.

인터넷을 통해 금융 거래를 할 수 있게 하는 다른 방법으로는 신용 카드 번호 대신에 "가상(virtual)" 코드를 사용하는 방법이 있다. 금융 회사는 고객(또는 소비자)에게 신용 카드 정보 대신에 "가상" 코드를 발행한다. 보안 상의 이유로, 이 교환은 인터넷 상에서 수행되지 않고 거의 항상 전화를 통해 수행된다. 임의의 구매가 인증되기 전에, 금융 회사는 고객에게 확인 요청 e-메일을 보낸다. 금융 회사가 고객의 확인을 수신하면, 신용 카드 거래가 인터넷에서 처리되고 상인은 상품 발송을 인가하도록 e-메일을 보낸다.

신용카드 기반의 구매 방안에 대한 다른 방법은 디지털 현금(digital cash) 또는 "e-캐시(e-cash)"이다. 디지털 현금은 일련의 숫자 또는 은행에 의해 발행된 보조화폐(token)이다. 그러나, e-캐시를 사용하기 위해서는, e-비즈니스 상인 및 고객이 e-캐시를 발행하는 은행의 계정을 갖고 있어야 한다. 은행은 e-캐시를 관리하고 전송하기 위한 "전자화폐(purse)" 소프트웨어를 갖는 고객 및 e-비즈니스 상인을 모두 제공한다. 고객은 금전을 그들의 은행 계정으로부터 e-캐시로 변환하고 그 다음에 그것을 암호화하는 전자화폐 소프트웨어로 전달하고 고객의 하드 드라이버 상에 저장한다.

e-캐시로 구매하는 경우, 소비자는 적절한 보조화폐를 상인에게 전달하고, 상인은 인증 및 회수를 위해 은행에 이들을 중계한다. e-캐시는 물리적인 객체가 아니기 때문에, 각각의 e-캐시 "금전"이 단 1회만 사용될 수 있도록 보장하기 위해 복잡한 일련번호가 사용된다. e-캐시는 비교적 낮은 거래 비용을 초래하며 다른 인터넷 금융 방법에서 가능한 것보다 작은 화폐단위(denomination)를 제공하며, 증권 시세 또는 뉴스 기사에 대한 지불과 같은 저가 거래에 사용하기에 적합하다. 그러나, 현재는 많지 않은 웹 상인이 e-캐시를 수락하고 있으며, 비교적 적은 은행이 그것을 발행하고 있다.

전자 수표는 e-상업(e-commerce)에 사용된 다른 가능한 지불 방법이다. 전자 수표 또는 "e-체크(e-check)"는 본래 종이 수표와 유사한 특징을 갖고 있다. 가장 간단한 구조로, 일부 시스템은 소비자에게 웹 점포상에서 온라인 서식을 기입할 것을 요구한다. 이 때 입력 데이터가 판매자에게 전송되며 공인된 프린터에서 백지수표 형식을 이용하여 종이 수표로 바뀌게 된다. 그러면, 이 수표는 일반적인 경우와 마찬가지로 지불을 위해 은행에 제출된다.

고객 및 상인에게 높은 보안 레벨을 제공하기 위해, 제 3측 회사는 보안 사이트에서 소비자에게 그들의 당좌 예금 구좌 정보를 입력하게 하고 고유한 사용자 성명 및 패스워드를 선택하게 한다. 방문 중인 웹 점포로부터 구매하고자 하는 고객은 상인의 온라인 주문 서식을 완성하기만 하면 된다. 그러면 주문 정보는 제 3 측 보안 서버로 제출되어 확인이 이루어진다. 확인 시에, 상인은 수표를 인쇄하고 그것을 은행에 제출한다. 이 전자 수표 수단은 구매자로부터 상인에게로의 메일 이송(mail trip)을 분명하게 하기 위한 검사 대기를 회피한다. 그러나, 이것은 전자지갑 또는 가상 코드를 사용하는 e-상업 지불만큼 편리하지는 않다.

e-상업 거래에 대한 이상의 모든 방법은 통상 신용카드 거래에 의해 이루어지는 비교적 작은 구매를 하는 개인을 목적으로 하고 있다. 사용자와 상인 모두를 위한 현재의 e-상업 융자에서의 초점은 최소한의 오버헤드로 안전하고 신속한 거래를 제공하는 것이다. 구매 거래는 비교적 간단하며, 금융 회사로부터 상인에게 금전 또는 대출액의 전송을 포함한다. 그러나, e-상업 비즈니스 모델이 확장됨에 따라, e-비즈니스 상인은 인터넷을 통해 보다 복잡한 거래를 처리해야 한다.

B2B 거래에서는, 훨씬 더 많은 양의 자금이 포함된다. 인터넷을 통해 고가의 아이템을 e-비즈니스로 판매하기 위해서는 그들의 고객에게 융자의 유연성을 제공할 수 있어야 한다. 현재, 고객은 상인로부터 원하는 상품을 선택한 후, 그 가격을 협상한다. 고객은 원하는 가격으로 구매하고자 하는 상품을 획득하기 위해, 상품의 구매에 대해 융자를 원할 수도 있다. 그러면, 고객은 대출 승인을 획득하기 위해 많은 문서에 서명을 할 필요가 있다. 이 모든 프로세스는 인터넷에서 구현하기가 비교적 어려우며 시간이 걸린다.

고객은 또한 자신이 임대 계약을 통해 e-비즈니스 상인에게 지불을 하려고 할 수도 있다. 그러나, 고객과 융자 회사와의 임대를 설정하는데 많은 서류 작업이 포함되기 때문에, 인터넷을 통해 소비자에게 임대 옵션을 제공하는 것도 비교적 어렵다. 구매 거래에서 인터넷의 주요한 매력은 거래의 용이성과 거래가 처리되는 속도에 있기 때문에, 임대 또는 융자에 많은 서류 작업이 포함된다면, 상인과 고객 모두에 대해 인터넷의 이점이 사라진다.

따라서, 고객과의 거래가 이루어질 때 안전하고, 커스텀화가능하며 주문형으로 이용가능한, 인터넷을 통한 고가의 상업적 판매를 융자하기 위한 시스템, 서비스 방법, 컴퓨터 판독가능 기록매체 및 관련 방법이 요구된다.

본 발명은 이 요구를 만족시키며, 융자 주문 서비스를 구현하는 시스템, 서비스, 컴퓨터 판독가능 기록매체 및 관련 방법(본 명세서에서는 이를 총괄하여 "시스템" 또는 "본 시스템"이라고 함)을 제공한다. 본 시스템은 인터넷을 통한 신용카드 구매의 용이성과 통상의 임대의 유연성을 결합하고, 융자 주문(FOD; financing on demand) 시스템을 제공한다.

본 시스템은 쇼핑 웹사이트와 같은 인터넷 애플리케이션으로부터 호출될 수 있는 모듈러 웹 서비스(modular web services)를 포함하는 융자 e-유틸리티(e-utility)를 포함한다. e-유틸리티는 대출 결정(credit decisioning), 임대 구조 및 금리, 기간 및 조건(terms and conditions)과 같은 고객의 자격인증 프로세스를 안전한 전자 전달 및 e-서명과 같은 문서의 합법적으로 강화할 수 있는 문서 기록 보존(archiving)과 함께 미리 설정한다.

본 시스템은 종래의 서류 지향적 상품 임대 프로세스를 자동화하고 인터넷을 통해 상품을 융자하는 새로운 방법을 제공한다. 본 시스템은 통상 낮은 한계의 대출을 가지며 제한된 지불 구조를 갖는 신용카드를 사용하지 않고, 또한 웹 기반의 거래에 속도 및 편리함에 있어서의 기본적인 이점을 무시하는 오프라인 융자 프로세스에 의존하지도 않는다.

본 시스템은 고객 거래(customer transaction)가 실시간으로 발생할 때, 안전하고, 전체적으로 커스텀화가능하며 주문형으로 이용가능한 인터넷을 통해 고가의 판매를 융자하는 새로운 방법을 제공한다. 본 시스템의 특징은 송장의 구매 가격을 융자된 정기 지불액(financed periodic payment)으로 차환한다(convert).

종래에는, 임대 프로세스가 구체적인 정기 지불을 발생하기 위해 제한된 기간 동안의 거래 또는 한도(tranches)에 대해 순차적으로 수행된다. 결과적으로, 본 시스템은 부피가 크고 낮은 비용의 상품에 대해 조달 프로세스를 단순화한다. 본 시스템은 내부 관리 비용을 줄이고, 현재의 비즈니스 프로세스의 속도를 높이며, 최종 사용자 및 판매자와의 비즈니스를 더욱 용이하게 하는 이점을 상인에게 제공한다.

본 시스템은 융자 회사의 계약 및 보안 요건을 만족시키는 안전한 합법적 강화 문서를 생성한다. 상인은, 예를 들어 소프트웨어 보조화폐, CD ROM, 스마트 카드 매체, 간단한 보안 패스워드 또는 자격있는 고객(entitled customer)을 온라인에서 식별하는 기타 사전 정의된 보안 수단에 의해 본 시스템에 대한 접근을 고객에게 제공한다. 본 시스템은 고정된 대출 한도나 지불 구조를 갖지 않으며, 안전하게 완전히 암호화되며, 임의의 판매자의 웹 사이트에 대한 편리한 통합을 허용하기 위해 입력/출력에 있어 독점적이지 않으며 공개된 표준 구성을 이용한다. 유틸리티로서, 이것은 신용카드 발행 은행에 의해 과금되는 상인 요금과 유사한 거래 단위로 과금될 수 있도록 사용될 수 있다.

현재, 신용카드 또는 조달 카드(procurement card)에 의해 결재되는 소액 거래를 제외한, 비즈니스 투 비즈니스 정보 기술(IT) 거래는, 주문이 이루어진 후에 오프라인으로 융자된다. 상품 융자는 제한적이며 비교적 수동 지향적인 웹 판매 프로세스 사후 단계(after-the-fact step)이다.

본 시스템은 결제 또는 송장발송 시점에 각 고객에 의해 사전에 계약된 지불 계획 및 커스텀화된 임대 구조 외에 안전한, 대출한도(credit line)의 즉각적인 자격인증을 제공한다. 고객은 그들의 암호화된 식별자를 호출하여 온라인상으로 문서를 실행한다. 모든 다른 입증 자료가 생성되어 본 시스템에 보관되어 거래 시에 요구되는 추가적인 판매자 또는 고객과의 상호작용없이 즉시 이용가능하다.

본 시스템은 현재의 융자 방법에 대해 뚜렷한 이점을 상인, 고객, 융자 회사에 제공한다. 판매자에 대해서는, 본 시스템은 각각의 고객에 대한 대출 및 융자 구조에 대한 접근이 확장되고 더욱 빨라진 송장 결제를 통해 상품 판매를 더욱 용이하게 한다. 고객에 대해서는, 본 시스템은 인터넷을 통한 자신의 요구로 이용가능한 커스텀화된 융자 및 대출 한도액의 편리함과, 안전한 문서 추적 및 보관을 제공한다. 융자 회사에 대해서는, 본 발명은 문서 작업을 줄이고, 생산성을 향상시키며, 인터넷을 통한 새로운 B2B 시장으로의 접근이 넓어지며, 융자 주문 프로세스를 관리하기 위한 부가적인 요금 수입을 제공한다.

융자 회사의 전형적인 고객은 임대 기간에 대한 기본계약(term lease master agreement:TLMA) 또는 고객기반의 기본계약(customer based master agreement:CBMA)을 갖는 고객들이다. 이러한 계약들은 기간 및 조건이 협의된 임대 계약이다. 정기적으로, 일반적으로는 분기마다(quarterly), 고객들은 융자 회사와 임대 금리 갱신을 협상한다. 융자금액이 융자되는 동안, 대출액은 거래 시에 서명한 규칙에 따라 고정된다.

임대 금리가 분기마다 설정되면, 고객 및 융자 회사는 그들의 기초 TLMA에 대해 금리 보충계약을 실행한다. 임대인(lessor)은 고객의 자격인증 조건, 일반적으로 대출액을 상인에게 통지한다. 고객은 고객에게 상품을 배송한 이후에 융자 회사에 상품에 대한 송장을 발행하는 상인과 접촉한다. 융자 회사는 상품 수령 확인 및 임대가 개시된다는 확인과 서명을 위해 배달 확인 문서를 고객에게 발행한다.

본 시스템은 "조정 관리(reconciliation up front)"의 개념에 기초한다. 고객은 상품을 구매하여 임대 설정에 법적 동의를 하기 전에 본 시스템으로 금리 보충계약(rate supplement) 및 배달 확인을 승인한다. 고객이 배달 확인을 수락하면, 장비 임대(equipment lease)가 개시되고, 임대인이 상인의 송장 결제를 실행할 수 있게 된다.

배달 확인은 고객이 사전에 동의한 이유(예를 들면, 가격 착오(mis-pricing))에 따라서 지불을 거부하는 액션을 취하지 않으면, 지정된 기간 후에 수락된 것으로 추정된다. 본 시스템은 고객에게 그들의 송장이 매달 융자되는 방법을 나타내는 상세한 보충계약(supplement)을 디스플레이한다. 본 시스템의 특징은 일단 송장이 고객에게 양도되면 융자 프로세스의 나머지는 자동적이라는 것이다. 송장은 고객과 융자 회사 사이의 임대 또는 기타 융자 협약의 시작이다.

기본계약(master agreement)은 정적인 경향이 있는 반면에 기본계약에 딸린 보충계약(supplement)은 거래에 의해 변한다(가격, 조건, 지불 구조, 효력 등과 같은 거래 특정 세목과 함께). 분기별로 간략히 체결되는 보충계약은 분기별로 동의한 금리를 지정한다. 배달 확인/상세한 보충계약은 분기 내에 배달된 상품에 대한 상인 송장으로부터 생성된다. 이들 보충계약은 송장의 구매 가격을 분기에 대해 유효한 보충계약의 이율을 이용하여 매달 임대료로 차환한다.

본 시스템은 기본 임대 계약, 보충계약 및 관련 자료(스케줄 A), 배달 확인/상세한 보충계약을 제공하며, 상인은 검토 및 보안 전자 서명을 위해 적절한 시간에 자격있는 고객에게 송장을 보낸다. 이러한 모든 문서는 합법적 문서로서 취급되며, 지방 법에 따른 보안 형식으로 양측에 의해 전자적으로 서명되고, 시스템에 의해 보관되며, 융자 회사에 의해 나중에 보안을 위해 또는 서명하는 측에 의한 온라인 검색을 위해 이용가능하게 된다.

본 발명은 융자 주문 고객 유틸리티 프로그램(financing on demand consumer utility program)과 같은 유틸리티 프로그램으로 구현될 수도 있다. 본 발명은 상품을 구매하고 임대를 설정하기 위한 법적 계약을 생성하기 전에 유틸리티 프로그램을 이용하여 대금에 대한 보충계약 및 배달 확인을 승인하기 위한 수단을 고객에게 제공한다. 배달 확인에 대한 고객의 수락은 장비 임대가 개시하고 임대인이 상인의 송장 결재를 실행할 수 있게 한다. 고객은 예를 들면, CD ROM, 스마트 카드 매체, 간단한 보안 패스워드 또는 자격있는 고객을 온라인에서 식별하는 기타 사전 정의된 보안 수단에 의해 상인에 대한 접근을 획득한다. 고객은 또한, 사전에 계약된 지불 계획 및 커스텀화된 임대 구조 외에 안전한, 대출한도(credit line)의 즉각적인 자격인증을 획득한다. 고객은 암호화된 식별자를 호출하여 문서를 온라인으로 실행한다. 모든 다른 입증 자료가 생성되어 본 시스템에 보관되며, 고객에 의해 주문형으로 이용가능하다.

본 발명은 융자 주문 상인 유틸리티 프로그램과 같은 유틸리티 프로그램으로 구현될 수도 있다. 본 발명은 상인이, 내부 관리 비용을 줄이고, 현재의 비즈니스 프로세스의 속도를 높이며, 최종 사용자 및 판매자와의 비즈니스를 더욱 용이하게 하는 수단을 제공한다. 상인은 고객의 자격 조건, 일반적으로 대출금액의 양을 통지받는다. 상인은 대출 및 융자 구조에 대한 접근이 확장되고 더욱 빨라진 송장 결제를 통해 상품 판매를 더욱 용이하게 된다.

본 발명의 다양한 특징들 및 이들을 포함하는 방법은 다음의 상세한 설명, 청구범위 및 도면을 참조하여 보다 상세히 설명될 것이다. 도면에서 유사 참조번 호는 적합한 경우, 그 항목들 사이에 상관이 있음을 나타내기 위해 재사용된다.

다음의 정의 및 설명은 본 발명의 기술적인 분야와 관련된 배경 정보를 제공하고, 본 발명의 범위를 제한하지 않으면서 본 발명의 이해를 돕고자 하는 것이다.

EDI: 전자 데이터 교환(Electronic Data Interchange). 단체들 간의 주문, 확인 및 송장와 같은 비즈니스 거래의 전자 통신.

인터넷(Internet): 광역 분산망을 형성하기 위해 표준 프로토콜의 설정에 의해 라우터와 함께 링크되는 상호접속된 공용 및 개인 컴퓨터 망의 집합.

PDF: Portable Document Format - 휴대형 컴퓨터 플랫폼이 되도록 설계된 애크로뱃 문서 교환 시스템에서 사용된 페이지 기술 언어. 이 포맷을 사용하는데 있어서 두 가지 중요한 이점은, 인터넷 상에서 이용가능한 수많은 프리웨어 PDF 리더가 있다는 것과 PDF 문서는 소스 문서 없이 변할 수 없다는 것이다.

UCC-1 파일링(UCC-1 Filing): 채무자-채권자 조합에 대응하는 공고 및 포함된 보안을 제공하도록 설계된 통일 상법전(Uniform Commercial Code) 내의 엔트리. 또한, UCC-1은 대부에 대해 채무자에 의해 제공된 담보물로 채권자의 이자를 등록하여 보호한다.

URL(Uniform Resource Locator): 인터넷 상의 컨텐츠 객체의 위치를 완전히 지정하는 고유 어드레스. URL의 일반적인 포맷은 protocol://server-address/path/filename이다.

웹사이트(Web Site): 컴퓨터 네트워크를 통해 접근이능하며, WWW와 같은 대형의 분산 정보 시스템의 일부를 형성하는, 데이터 베이스 또는 상호 링크된 하이퍼텍스트 문서("웹 문서" 또는 "웹 페이지") 및 관련 데이터 개체. 일반적으로 웹사이트는 특정 인터넷 도메인명에 대응하며, 특정 조직의 내용을 포함한다. 다른 유형의 웹사이트는 예를 들어 사내 "인트라넷(intranet)"(즉, 표준 인터넷 표준을 사용하는 내부 망)의 하이퍼텍스트 데이터베이스, 또는 WWW의 문서 검색 프로토콜과 다른 문서 검색 프로토콜을 사용하는 하이퍼텍스트 시스템의 사이트를 포함할 수도 있다.

월드 와이드 웹(WWW): 인터넷 유저-서버 하이퍼텍스트 분산 정보 검색 시스템.

XML: 확장성 생성 언어(eXtensible Markup Language). 웹 문서에 사용된 표준의 반구조적(semi-structured) 언어. 웹 문서(또는 "XML 문서")가 웹 서버에 의해 웹 브라우저로 전송될 때, 태그는 브라우저에 의해 해석되고 문서를 파싱하고 디스플레이하는데 사용된다. 웹 브라우저가 문서를 디스플레이하는 방법을 지정하는 것 외에 XML은 다른 웹 문서에 하이퍼링크를 생성하는 데 사용될 수 있다.

도 1은 본 발명에 따른 융자 주문을 구현하기 위한 시스템, 서비스, 프로그램 제품 및 관련 방법("시스템(10)")이 사용될 수 있는 전형적인 전체 환경을 도시하고 있다. 융자 주문 시스템(10)은 통상 호스트 서버(15) 내에 삽입되거나 그 상에 설치되는 컴퓨터 프로그램 제품 또는 소프트웨어 프로그래밍 코드를 포함한다. 한편, 시스템(10)은 디스켓, CD 하드 드라이버 또는 이와 유사한 장치와 같은 적절한 저장 매체에 저장될 수 있다. 시스템(10)은 WWW와 관련하여 설명되지만, 시스템(10)은 WWW 또는 다른 소스로부터 유도될 수도 있는 독립형 데이터베이스와 함께 사용될 수도 있다.

통신 네트워크(20)는 통신 라인 및 서버(25, 27)와 같은 서버를 통해 게이트웨이(30)와 같은 게이트웨이에 접속시키는 스위치로 이루어진다. 서버(25, 27)와 게이트웨이(30)는 WWW 또는 인터넷에 통신 접근을 제공한다. 원격 인터넷 사용자와 같은 사용자는 컴퓨터(35)와 같은 다양한 컴퓨터로 나타내며, 통신 네트워크(20)를 통해 원하는 정보에 대해 호스트 서버(15)에 질의할 수 있다. 컴퓨터(35, 37, 39)는 각각 사용자로 하여금 인터넷을 브라우저할 수 있도록 하며 호스트 서버(15)와 안전하게 인터페이스할 수 있도록 한다.

호스트 서버(15)는 전화기, 케이블, 또는 위성 링크와 같은 통신 링크(42)를 통해 통신 네트워크(20)에 접속된다. 서버(25, 27)는 고속 인터넷 네트워크 라인(44, 46)을 통해 다른 컴퓨터 및 게이트웨이에 접속될 수 있다. 서버(25, 27)는 일반적으로 50, 55, 60에서 표시된 웹 문서 또는 하이퍼텍스트와 같은 저장된 정보에 대한 접근을 제공한다. 문서(50, 55, 60)는 텍스트, 이미지 및 기타 객체를 포함할 수도 있다. 하이퍼텍스트 문서(50, 55, 60)는 특히 다른 지역적으로 저장된 페이지에 대한 삽입된 하이퍼텍스트 링크 및 서버(27)와 같은 다양한 웹 서버에 의해 저장되는 다른 웹사이트 또는 문서(55, 60)에 대한 하이퍼텍스트 링크(70, 72, 74, 76)를 포함한다.

도 2는 고객이 시스템(10)으로부터의 융자를 이용하여 판매자로부터 상품을 구매하는, 본 발명의 서비스 방법(200)을 도시한다. 먼저, 시스템(10)으로 고객의 자격인증(entitlement)이 구축된다.

단계 202에서, 고객은 융자 회사와 상호작용하여, 아래의 도 4의 서비스 방법(300)에서 상술되는 것과 같이, 기본계약을 확립한다. 고객의 자격인증은 아래의 도 5의 서비스 방법(400)에서 상술되는 것과 같이 생성될 수도 있다. 고객의 자격인증은 대출 한도, 융자 기간 및 조건, 지불 기간 및 구조에 대한 고객의 요구사항, 결제 추적(payment tracking), 지불 계산서 선택(payment statement preference)을 포함한다.

융자 회사와 거래할 때, 고객은 분기별과 같은 정기적인 기준에 따라서 융자 금리 및/또는 지불 구조를 재협상한다. 서비스 방법(400)은 이 정기적인 기준에 따라서 반복되어 고객의 자격을 새롭게 한다(단계 206). 이들 융자 조건 및 재융자 기간은 또한 고객의 자격인증에 포함된다. 단계 202는 호스트 서버(15)를 통해 온라인에서 제공되며 고객에 의해 받아들여지는 문서(50, 55, 60)와 같은 표준 문서를 사용하여 수행된다. 그 다음 고객의 계정이 사용가능하다.

그 다음에 단계 210에서 융자 회사는 고객의 대출 승인을 상인에게 통지한다.

도 3의 예를 참조하면, 자격있는 고객(사용자)(215)이 호스트 서버(15) 상의 상인의 웹사이트에 접근한다. 단계 220(도 2)에서 사용자(215)는 상품 구매를 결정하고, 주문을 한다. 호스트 서버(15)상의 상인의 웹사이트는 지불 방법으로서 시스템(10)에 대한 접근을 사용자(215)에게 제공한다.

사용자(215)가 자신의 쇼핑 카트를 결제할 때, 사용자(215)는 시스템(10)으로부터 호스트 서버(15) 상의 상인의 웹사이트 상에서 자신이 이용할 수 있는 융자 옵션을 선택한다. 시스템(10)은 사용자(215)를 온라인 거래 서버(225)(도 3)로 보내며, 사용자(215)의 융자 및 청구서 정보가 암호화된다. 사용자(215)는 결제하기 전에 자신의 쇼핑 카트 내의 적절한 상품에 대한 분기별 금리를 볼 수 있다.

주문이 이루어지면, 송장 정보가 사설 게이트웨이(priviate gateway)(230)를 통해 프로세싱 네트워크(235)로 전송된다. 프로세싱 네트워크(235)는 송장 정보를 융자 회사의 융자 회사 서버(240)로 발송한다. 상인은 자격있는 사용자에게 사용자(215)의 대출 한도까지의 값의 상품을 발송하고(단계 250), 융자 회사 임대 인증/그 전에 수신한 구매 주문의 조건 하에서 융자 회사에 송장을 보낸다.

상인 송장은 배달 확인 문서를 생성하는데 사용된다. 상인 송장 및 배달 확인 문서는 모두 호스트 서버(15) 상의 상인의 웹사이트 상의 사용자(215)에 의해 검토 및 수락에 이용가능하게 만들어진다(단계 255). 일실시예에서, 시스템(10)은 사용자(215)에게 송장이 보내졌음을 통지한다(260).

사용자(215)는 송장이 자동으로 승인되기 전에 송장을 검토하고 수락하는 사전 결정된 기간을 갖는다. 그 다음에 사용자(215)는 송장을 검토하고 단계 265에서 송장을 승인하거나 거부한다.

사용자(215)가 송장을 거부하면, 단계 270에서 시스템(10)은 에러 처리를 위해 그 송장을 상인에게 반환한다. 그렇지 않으면, 시스템(10)은 송장을 정기적인 지불 계산서로 변환한다. 단계 275에서, 융자 회사는 상인 송장을 결제하고 사용자(215)와 융자 회사 사이에 사전설정된 것과 같이 임대 또는 융자 계획이 예약된다. 만약 구매한 상품이 임대되면, 재산 권리(asset title)가 임대의 종료 시 사용자(215)에 의해 어떠한 결정이 이루어질 때까지 재산의 권리를 갖는 융자 회사에게 넘어간다.

시스템(10)에서 사용자(215)의 기본계약 거래를 생성하기 위한 서비스 방법(300)이 도 4의 순서도에 자세히 나타나있다. 단계 301에서 융자 회사의 직원이 시스템(10)에 로그인하여, 사용자(215)의 단체(organization)에 대한 기본계약 거래의 생성을 요구한다. 이 동작 전에, 사용자(215) 또는 그 단체는 이미 융자 회사로부터 고객 자격인증을 수신하였다(단계 202(도 2)). 이러한 고객 자격인증은 대출 한도 및 임대 시세, 기간 및 조건등을 포함하는데, 이것은 사용자 자신에 의해 사용자의 비지니스 요구에 적합하게 협상된 것일 것이다.
단계 302에서 시스템(10)은 단체 목록에 대한 기록을 검색한다. 단계 302에서 단체가 존재하면, 시스템(10)은 호스트 서버(15)에 기본계약을 저장한다. 만약 단체가 시스템(10)의 기록에 존재하지 않으면, 단계 304에서 직원은 그 단체에 대한 기록을 생성하고, 고객의 자격인증으로부터 단체의 정보를 입력한다.

삭제

그 다음에, 단계 305에서 시스템(10)은 기본계약을 호스트 서버(15)에 저장한다. 그 다음에 단계 310에서 융자 회사 직원은 단계 202에서 사용자(215)에 의해 제공된 정보에 기초하여 사용자의 계정 및 사용자 그룹을 생성한다. 단계 315에서 만약 시스템(10)이 사용자(215)가 그들의 단체에 대한 문서에 서명한것으로 인증하면, 단계 (320)에서, 융자 회사는 대출 접근 표시(token) 또는 보안된 패스워드를 사용자의 지정된 영수증 위치에 전자적으로 전달하고, 전달된 표시에 대한 영수증 반환을 요구한다. 접근 표시는 인증된 사용자(215)에게 물리적으로 보내지거나 또는 e-메일로 보내진다. 만약 사용자(215)가 문서에 서명한 것이 인증되지 않으면, 아무런 표시도 보내지지 않는다.

단계 325에서, 사용자(215)는 자신의 계정, 디폴트 패스워드 및 보안 코드를 사용하여 자신의 등록(enrollment) 웹 사이트에 접근할 수 있다. 사용자의 등록 웹사이트는 사용자의 기본계약을 디스플레이한다. 단계 330에서 사용자가 사용자 계약을 거절하면, 단계 340에서 시스템(10)은 그 세션을 종료한다. 단계 330에서 사용자(215)가 계약을 수락하면, 단계 335에서 사용자(215)의 자격인증된 계정이 시스템(10)에 의해 사용가능하게 된다. 상인은 사용자(215)의 기본계약이 이제 사용가능함을 통지받는다(단계 210). 서비스 방법(300) 및 서비스 방법(400)은 대부분의 경우에 사용자(215)의 최초 등록에서 동시에 일어난다고 예상된다.

도 2의 단계 206에서 사용자에 대한 자격인증 생성 및 이들을 주기적으로 새롭게 하는 서비스 방법(400)이 도 5의 순서도에 의해 보다 상세히 나타난다. 견적서(quote)는 특정 사용자(215)와의 임대 계약상의 세목을 포함하며, 사용자 이름, 주소, 승인된 대출 한도, 융자되기에 적합한 상품, 협정된 임대 금리 및 조건/지불 구조, 기본계약과 관련된 임의의 특약 및 제약을 포함하는 여러 부분으로 이루어진다.

단계 350에서 자격인증 프로세스는 융자 회사가 자격인증 견적서(entitling quote)를 생성할 때 개시된다. 먼저, 단계 335에서 사용자(215)에 대한 융자 주문(FOD) 계정이 XML 형식의 자격인증 견적서에 의해 제공되는 정보로 생성 또는 갱신된다(예를 들면, 분기별로 갱신). 시스템(10)에서의 거래를 갱신하기 위해, 융자 회사의 대리인이 시스템(10)에 로그인하여 새로운 거래의 견적서를 생성하고, 사용자에 대한 임대 거래를 실행하기 위해 대출한도 및 융자 회사에 의해 요구되는 다른 계약 데이터를 확인하고, 표준화된 XML 형식을 이용하여 시스템(10)에 이들을 로딩한다.

단계 375에서, 시스템(10)은 적절한 임대 문서를 생성한다. 시스템(10)은 이 견적서에 대해 적절한 장비(스케줄 A)의 목록과 관련된 정기적인 금리에 대한 보충계약을 구축한다. 금리에 대한 보충계약은 상품의 카테고리에 대한 임대 금리를 열거한다. 스케줄 A는 각 카테고리 내의 장비의 유형을 규정한다. 따라서 임대 금리 및 스케줄 A는 다가오는 분기에 대한 모든 거래에 대해 고정된다. 융자 회사의 고객 계약 대리인은 분기마다 한 번씩 스케줄 A를 입력하고, 시스템(10)은 그것을 분기 동안 모든 견적 거래에 사용하기 위해 저장한다.

단계 380에서, 시스템(10)은 요구된 e-메일을 통해 사용자(215)에게 통지한다. 통지는 시스템(10)의 웹사이트에 대한 URL과 금리 보충계약에 접근하는데 필요한 견적서 번호를 포함한다. 사용자(215)는 시스템(10)에 의해 자격인증이 구축되었고 그의 수락을 확인하기 위해 대기중이라는 통지를 받는다. 사용자(215)는 온라인에서 시스템(10)에 의해 제공되는 자신의 안전한 계정 접근 및 e-서명으로 자신의 자격인증을 수락한다.

단계 385에서, 시스템(10)은 사용자(215)가 금리 보충계약에 서명했는지 확인한다. 만약 금리 보충계약에 서명이 없으면, 단계 390에서 시스템(10)은 서명을 위해 얼마나 오래 기다렸는지 확인한다. 하루와 같이 사전에 정해진 기간이 경과하지 않았으면, 시스템(10)은 단계 385로 돌아가서 사용자(215)의 서명을 기다린다.

그러나, 만약 하루가 경과했다면(단계 390), 단계 395에서 시스템(10)은 사용자(215)에게 금리 보충계약에 서명이 요구된다고 상기시키기 위한 확인서(reminder)를 보내며, 단계 402에서 3일과 같은 연장된(또는 최대) 기간이 경과했는 지를 확인한다. 만약 경과하지 않았다면, 시스템(10)은 단계 385로 돌아가서 클라이언트의 서명을 기다린다. 단계 385 내지 402는 3일이 경과하거나 서명이 사용자(215)에 의해 제공될 때까지 반복된다. 3일 동안, 사용자(215)에게 예를 들어 하루에 한번씩 세차례에 걸쳐 주기적으로 상기시키기 위한 확인서가 전송된다.

서명 없이 3일이 경과했으면, 단계 405에서 시스템(10)은 고객 계약 대리인(CCR)에게 통지한다. 시스템(10)은 고객 계약 대리인에게 사용자(215)가 단계 402에서 결정된 대로 3일 후에 금리 보충계약에 사인하는 것을 거부함으로써 계약을 거부했음을 통지한다.

단계 380에서 금리 보충계약이 사용자(215)의 융자 주문 웹사이트에서 인증을 기다린다는 것이 통지되었을 때, 사용자(215)는 시스템(10)에 로그인하여 사용자(215)의 금리 보충계약 문서에 접근한다. 시스템(10)은 사용자(215)의 주의를 요하는 거래 견적서의 목록을 제공한다.

사용자(215)는 적절한 금리 보충계약과 금리 보충계약에 대한 스케줄 A 및 임의의 추가사항(addenda)을 검색한다. 단계 410에서, 사용자는 금리 보충계약 및 추가사항에 e-서명함으로써 금리 보충계약의 조건을 받아들일 수도 있다. 사용자(215)는 또한 금리 보충계약에 서명하지 않거나 조건을 거부하는 이유를 융자 회사에 통보함으로써 금리 보충계약의 조건을 거부할 수도 있다.

사용자(215)가 조건을 거부하면, 단계 405에서 시스템(10)은 고객 계약 대리인에게 통지하고, 단계 410에서 사용자(215)에 의해 제공된 이유를 통보한다. 그 다음에 융자 회사의 고객 계약 대리인은 시스템(10)에 접근하여 계약 견적서를 갱신한다. 고객 계약 대리인은 동일한 견적서 번호를 유지하는 갱신된 보충계약 및/또는 추가사항을 획득하고 단계 355로 돌아가서 필요하다면 프로세스를 반복한다.

사용자(215)가 견적서 및 그 조건을 받아들이면, 단계 415에서 시스템(10)은 e-메일로 사용자(215)가 금리 보충계약 및 임의의 추가사항을 수락했음을 융자 회사의 고객 업무 관리자(customer operations manager:COM)에게 통보한다. 그 다음에 융자 회사의 고객 업무 관리자는 시스템(10)으로부터의 문서를 검색하고, 문서를 검토하며, 필요한 경우 문서에 서명한다.

단계 420에서, 시스템(10)은 각 판매자에게 사용자(215)가 금리 보충계약에 서명했다는 통지를 보낸다. 그 통지는 사용자(215)의 대출 한도, 견적서 번호 및 상품의 목록을 포함한다. 시스템(10)은 견적서 및 스케줄 A 문서로부터의 정보가 판매자에 보내지도록 한다. 판매자는 시스템(10)에 접근하지 않고 이 통지를 통해 모든 그들의 정보를 수신한다. 각각의 판매자는 e-메일을 통해 동일한 임대 인증을 수신한다. 또한 단계 425에서 시스템(10)은 사용자(215)가 금리 보충계약을 수락하였음을 고객 계약 대리인(CCR)에게 보낸다.

전술한 프로세스는 주기적으로(분기별로) 반복되는데, 즉, 금리를 재평가하고, 임대될 장비의 스케줄 A 목록을 생성하고, 대출 한도 상태를 검토하고 이용가능한 대출을 판매자에게 재권고한다.

도 6(도 6a 및 6b)은 도 2의 단계 250에 후속하며, 융자 회사에 의해 수반되며 장비 임대를 개시하고 관련 상인 송장을 결제하는 서비스 방법(500)을 보다 상세하게 도시하고 있다. 판매자가 사용자(215)가 융자 주문 조건을 수락했음을 통지받는 도 5의 단계 420에 이어서, 단계 435에서, 판매자는 주문된 상품을 발송한다.

단계 440에서, 판매자는 전자 형식으로 융자 회사에 송장을 제출한다. 각각의 송장은 상품이 융자되는 임대 계약을 적절히 식별하기 위한 견적서 번호를 포함한다. 전자 송장은 현재 이용 중인 또는 적당한 융자 회사에서 동일한 시스템에 제출된다. 융자 주문에 대한 거래는 수신한 송장 거래의 일반적인 풀(pool)로부터 선택된다.

그 다음에 단계 445에서 송장은 XML 형식으로 변환되어 시스템(10)으로 전송된다. 단계 450에서, 시스템(10)은 견적서 번호, 타입 유효성, 또는 모델 번호에 있어서의 일치 여부를 검사한다. 만약, 송장 및 견적서가 일치하면, 시스템(10)은 단계 455로 진행되고, 여기서 시스템(10)은 각각의 거래에 포함된 견적서 번호에 기초하여 XML 송장 문서를 정확한 거래에 위치시킨다. 단계 455에서, 시스템(10)은 송장 문서로부터 배달 확인 문서를 생성한다.

단계 460에서, 시스템(10)은 사용자(215)의 대출 한도의 상태를 판정한다. 만약, 한도가 초과되면, 단계 465에서 시스템(10)은 판매자 및 고객 계약 대리인(CCR)에게 사용자(215)의 대출 한도가 초과되었음을 통지한다.

만약, 사용자(215)의 대출 한도가 초과되지 않으면(단계 460), 단계 470에서 시스템(10)은 사용자(215)에게 e-메일을 보내 융자 주문 웹사이트에 대한 URL 및 배달 확인에 접근을 상기시키는 확인서로서 견적서 번호를 포함하는 통지를 보낸다. 그 다음에 단계 475(도 6b)에서 시스템(10)은 사용자(215)가 배달 확인에 서명하였음을 확인한다.

만약, 배달 확인에 서명이 되지 않았으면, 단계 480에서 시스템(10)은 얼마나 오랫동안 추가로 서명을 기다렸는지를 확인한다. 만약, 제 1 기간, 즉 하루가 경과되지 않았다면, 시스템(10)은 단계 475로 돌아가서 사용자(215)의 서명을 기다린다.

만약 하루가 경과했으면(단계 480), 단계 485에서 시스템(10)은 사전 결정된 기간, 예를 들면, 10일이 경과했는지를 확인한다. 만약, 아직 경과하지 않았다면, 시스템(10)은 단계 470으로 돌아가서, 사용자(215)에게 또 다른 배달 확인 요청을 보낸다. 단계 470 내지 485는 10일이 경과할 때까지 또는 사용자(215)에 의해 서명이 제공될 때까지 반복된다. 이 10일 동안, 통지가 사용자(215)에게, 예를 들어 하루에 1회씩 10회로 주기적으로 보내진다. 각각의 후속 통지는 배달 확인에 서명하지 않으면 상품의 배달을 수락하는 것으로 간주한다는 것을 강조하는 다른 텍스트를 포함한다. 만약 사용자(215)가 10일 후에 배달 확인에 서명하지 않으면, 시스템(10)은 단계 495로 진행한다.

만약 단계 475 및 490에서, 시스템(10)이 사용자(215)가 문서에 서명하여 배달 확인을 수락했다고 판정하면, 단계 495에서 시스템(10)은 대응하는 판매자에게 통지한다. 만약 사용자(215)가 배달 확인 문서를 수락하지 않으면, 단계 499에서 시스템(10)은 대응하는 판매자에게 이를 통지한다. 단계 409에서, 시스템(10)은 또한 판매자에게 송장 내에 어떠한 모순점이 있는 지(단계 450)의 여부를 통지한다.

단계 499에서, 시스템(10)은 판매자에게 송장을 보내는데 있어서의 에러, 오발송(short shipment), 사용자(215)에 의해 배달 확인 문서의 거부를 발생시키는 잘못된 배달 등을 통지한다.

단계 495에서, 시스템(10)은 또한 단계 485에서 디폴트에 의해 또는 단계 495에서 배달 확인을 수락함으로써 사용자(215)가 배달 확인을 승인하였다는 것을 나타내는 통지를 견적서 거래 시스템에 보낸다. 시스템(10)은 융자 회사 고객 계약 대리인 및 업무 관리자에게 통지하고 이용가능한 대출을 감소시킨다. 필요하다면, 고객 업무 관리자가 확인한다.

단계 510에서, 임대는 임대 견적서 시스템 내의 실행 거래로서 예약되고, 상인에 의해 결제가 개시된다. 시스템(10)은 기록내로 UCC-1 파일링 정보를 구축하고, 이 기록을 UCC-1 파일링을 다루는 외부 서비스에 전달한다. 거래 문서는 자격있는 사용자에게 이용가능한 온라인 데이터베이스에 보관된다. 자격있는 사용자는 지방법 상의 보관 요건에 따라서 서명된 문서를 브라우즈하여 검색할 수 있다.

시스템(10)의 성능을 도시하는 예를 이제 도 2를 참조하여 설명한다. 임대 구조의 편의를 희망하는 e-상업 클라이언트는 융자 회사에 접근하여 특정 융자를 요구한다. 클라이언트는 트랙터와 같은 구매하고자 하는 상품을 가지며, 각 트랙터는 $10,000임을 안다. 이 상품은 인터넷 상에서 판매자로부터 획득할 수 있다. 클라이언트는 6 개월에 걸쳐 10 대의 트랙터를 필요로 한다.

클라이언트는 시스템(10)을 이용하여 융자 주문을 제공하는 융자 회사와 협상한다. 시스템(10)은 대출 승인, 임대 구조 및 금리, 기간 및 조건을 포함하는 클라이언트 자격 프로세스를 미리 설정한다. 단계 202에서, 융자 회사는 고객에 의해 제공된 정보에 기초하여 고객의 대출을 평가하여 융자 자격인증을 생성한다.양측 모두 융자의 금리 기간 및 조건에 동의하면 융자 회사는 고객 자격인증을 생성한다. 이제 시스템(10)은 트랙터 상인에게 고객의 자격인증을 통지한다. 신용 카드 구매 및 임대 계약의 경우와 달리, 트랙터 상인은 고객이 주문하기 전에 클라이언트의 신용도(credit worthiness)를 알게 된다. 시스템(10)에 의해, 트랙터상인은 대출 및 융자 구조에 대한 확장된 접근을 통해 보다 큰 판매의 기회를 갖는다.

단계 220에서, 클라이언트는 몇몇 트랙터의 구매를 진행하기로 결심하고, 판매자가 임대하에 있는 트랙터를 융자 회사에 발송하도록 인증한다. 트랙터는 모두 고객에게 발송되고 융자 회사에 송장이 발송된다. 융자 회사는 온라인으로 이 송장 및 배달 확인을 클라이언트에게 전달한다(단계 265). 단계 275에서 융자 회사는 트랙터에 대해 판매자에게 비용을 지불한다. 판매자는 빠른 송장 결제의 이익을 갖는다.

구매 가격은 단계 202에서의 융자 회사와 사용자(215) 간의 계약에 따라서 단계 250에서 임대로 변환된다. 예를 들면, $10,000 송장이 36개월에 걸쳐 융자될 수도 있다. 단계 255에서 융자 회사는 이 송장과 배달 확인 및 상세한 임대 정보를 클라이언트의 융자 주문 웹 페이지에 보내고 그 효과를 사용자에게 통지한다.

클라이언트가 송장 조건을 수락하면, 클라이언트는 종래의 임대에 대해서와 같이 매달 분납으로 융자 회사에 지불한다. 임대 구조는 클라이언트에게 안전한 문서 추적 및 보관을 통해 인터넷 상에서 주문형으로 이용가능한 융자 및 대출 한도를 고객이 조정하게 하는 편의를 제공한다. 구매한 상품 또는 송장에 대해 어떠한 분쟁이 있으면, 단계 270에서 융자 회사가 판매자에게 경고한다.

상술한 본 발명의 특정 실시예는 단순히 본 발명의 원리의 임의의 응용을 나타낸다. 본 발명의 사상 및 범주를 벗어나지 않고 본 명세서에 개시된 융자 주문 서비스를 구현하는 시스템 및 방법에 수많은 변형이 이루어질 수도 있다. 또한, 본 발명을 WWW와 관련하여서만 설명하였지만, 본 발명은 임의의 적절한 네트워크를 통해 접근이능한 상업적 금융 시스템에도 적용될 수 있다는 것은 명백하다.

본 발명에 따르면 종래의 페이퍼 지향적 상품 임대 프로세스를 자동화하고 인터넷을 통해 상품을 융자하는 새로운 방법이 제공되며, 또한 고객 거래(customer transaction)가 실시간으로 발생할 때, 안전하고, 전체적으로 커스텀화가능하며 주문형으로 이용가능한 인터넷을 통해 고가의 판매를 융자하는 새로운 방법이 제공된다.

Claims

대출에 대한 확장된 접근과 각 고객에 대해 사전에 정해진 융자 구조 그리고 더욱 빨라진 송장 결제(invoice settlement)를 통해 상품 판매를 더욱 용이하게 하기 위해, 네트워크를 통해 융자 주문 거래(financing on demand transaction)의 구현을 자동으로 커스텀화하기 위한 방법에 있어서,

상기 네트워크에 연결된 호스트 서버에 의해, 고객의 자격인증(customer's entitlement)을 자동으로 발생시키는 단계와,

상기 호스트 서버에 의해, 상기 고객의 자격인증에 기초하는 기본계약 거래(a master agreement transaction)를 자동으로 생성하는 단계와,

상기 호스트 서버에 의해, 융자 회사(a financing company) 및 상인(a merchant)에게 고객의 대출 승인(credit approval)을 자동으로 통지하는 단계와,

상기 호스트 서버에 의해, 고객 거래가 승인되는 경우 대응하는 송장(invoice)을 상기 네트워크상에 자동으로 보내는 단계와,

상기 호스트 서버에 의해, 고객의 승인을 위해 상기 송장이 보내졌음을 상기 고객에게 자동으로 통지하는 단계

를 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
제 1 항에 있어서,

고객의 자격인증을 자동으로 발생시키는 상기 단계는 주기적으로 기간 및 조건을 발생시키는 단계를 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
삭제
청구항 4은(는) 설정등록료 납부시 포기되었습니다.

제 1 항에 있어서,

상기 고객의 자격인증은 고객의 대출 한도를 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
청구항 5은(는) 설정등록료 납부시 포기되었습니다.

제 1 항에 있어서,

상기 고객의 자격인증은 고객의 융자 기간 및 조건을 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
청구항 6은(는) 설정등록료 납부시 포기되었습니다.

제 1 항에 있어서,

상기 고객의 자격인증은 보충적인 지불을 얻기 원하는 고객의 요구사항을 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
청구항 7은(는) 설정등록료 납부시 포기되었습니다.

제 1 항에 있어서,

상기 고객의 자격인증은 고객의 지불 추적(payment tracking)을 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
청구항 8은(는) 설정등록료 납부시 포기되었습니다.

제 1 항에 있어서,

상기 고객의 자격인증은 고객의 지불 계산서 선택(payment statement preference)을 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
제 1 항에 있어서,

상기 기본계약 거래는 융자 회사에 의해 생성되는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
삭제
삭제
제 1 항에 있어서,

상기 고객이 상품을 구매하기 전에 금리 보충계약(a rate supplement) 및 배달 확인을 승인하는 단계를 더 포함하며,

상기 고객에 의한 상기 배달 확인의 수락은 장비 임대(equipment lease)를 개시하고 상인의 송장 결제를 실행하도록 하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 방법.
삭제
대출에 대한 확장된 접근과 각 고객에 대해 사전에 정해진 융자 구조 그리고 더욱 빨라진 송장 결제(invoice settlement)를 통해 상품 판매를 더욱 용이하게 하기 위해, 제1항, 제2항, 제4항 내지 제9항, 제12항 중 어느 한 항에 따른 방법의 각 단계를 수행하는 명령어 코드를 포함하는 컴퓨터 프로그램이 기록된 컴퓨터 판독가능 기록매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
대출에 대한 확장된 접근과 각 고객에 대해 사전에 정해진 융자 구조 그리고 더욱 빨라진 송장 결제를 통해 상품 판매를 더욱 용이하게 하기 위해, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 시스템에 있어서,

제1항, 제2항, 제4항 내지 제9항, 제12항 중 어느 한 항에 따른 방법의 각 단계를 수행하기 위한 수단을 포함하는, 네트워크를 통해 융자 주문 거래의 구현을 자동으로 커스텀화하기 위한 시스템.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
대출에 대한 확장된 접근과 각 고객에 대해 사전에 정해진 융자 구조 그리고 더욱 빨라진 송장 결제를 통해 상품 판매를 더욱 용이하게 하기 위해, 네트워크를 통한 거래의 구현을 자동으로 커스텀화하기 위한 융자 주문 서비스 방법에 있어서,

상기 네트워크에 연결된 호스트 서버에 의해, 고객의 자격인증을 자동으로 발생시키는 단계와,

상기 호스트 서버에 의해, 상기 고객의 자격인증에 기초하는 기본계약 거래를 자동으로 생성하는 단계와,

상기 호스트 서버에 의해, 융자 회사 및 상인에게 고객의 대출 승인을 자동으로 통지하는 단계

를 포함하는, 네트워크를 통한 거래의 구현을 자동으로 커스텀화하기 위한 융자 주문 서비스 방법.
대출에 대한 확장된 접근과 각 고객에 대해 사전에 정해진 융자 구조 그리고 더욱 빨라진 송장 결제를 통해 상품 판매를 더욱 용이하게 하기 위해, 네트워크를 통한 거래의 구현을 자동으로 커스텀화하기 위한 융자 주문 서비스 시스템에 있어서,

상기 서비스 시스템은

고객의 자격인증을 자동으로 발생시키기 위한 수단과,

상기 고객의 자격인증에 기초하는 기본계약 거래를 자동으로 생성하기 위한 수단과,

융자 회사 및 상인에게 고객의 대출 승인을 자동으로 통지하기 위한 수단

을 포함하는, 네트워크를 통한 거래의 구현을 자동으로 커스텀화하기 위한 융자 주문 서비스 시스템.