KR100804079B1 - 결제중개 처리장치, 결제중개처리용의 처리프로그램을 격납하는 기억매체, 결제중개용의 컴퓨터 프로그램, 온라인숍장치 및 온라인쇼핑방법과 그 시스템 - Google Patents

Abstract

등록하고 있는 온라인쇼핑몰 이외의 몰에 대해서도 간단한 수속으로, 동일의 결제처리에 의해 이용할 수 있는, 온라인 쇼핑시스템을 제공한다.

사용자(200)는, 미리 설정되어 있는 임시 ID를 이용하여, 등록하지 않은 다른 온라인숍(400)을 액세스한다. 상품을 구입하였을 경우에는, 온라인숍(400)이 머니게이트(500)에 수주데이터를 송신하고, 머니게이트(500)로부터의 요구에 따라서 사용자가 등록하고 있는 몰사업자(300)가 결제에 관계되는 크레디트번호 등의 정보를 머니게이트(500)에 송신하고, 이들이 머니게이트(500)에서 합쳐져서 최종적인 수주데이터가 생성되고, 이것에 의해 카드회사(600)에 대해서 결제처리가 행해진다.

Description

결제중개 처리장치, 결제중개처리용의 처리프로그램을 격납하는 기억매체, 결제중개용의 컴퓨터 프로그램, 온라인숍장치 및 온라인쇼핑방법과 그 시스템{Fee settlement mediation processing device, recording medium for storing a program for processing a fee settlement mediation, computer program for fee settlement mediation, online shop device and method, and system thereof}

도 1은 본 발명의 실시의 형태의 온라인 쇼핑시스템의 기본구성을 나타내는 블록도이다.

도 2는 도 1에 나타낸 온라인 쇼핑시스템의 몰사업자의 이용자마스터에 기록되어 있는, 다른 몰의 회원용의 등록내용을 나타내는 모식도이다.

도 3은 도 1에 나타낸 온라인 쇼핑시스템의 몰사업자에 있어서, 다른 몰에서 쇼핑을 행한 회원에 대해서 행하는 인증처리의 폽업화면을 나타내는 모식도이다.

도 4는 도 1에 나타낸 온라인 쇼핑시스템의 머니게이트의 사업자마스터에 기록되어 있는, 몰사업자마다의 다른 몰을 액세스하기 위한 정보를 나타내는 모식도이다.

도 5는 도 1에 나타낸 온라인 쇼핑시스템에 있어서의 사용자가 상품을 구입하였을 때의 처리의 흐름을 설명하기 위한 모식도이다.

도 6은 도 1에 나타낸 온라인 쇼핑시스템에 있어서 마감일 등에 행하는 매 출, 결제처리의 처리의 흐름을 설명하기 위한 모식도이다.

도 7은 본 실시의 형태의 온라인 쇼핑시스템의 실제의 구성을 나타내는 모식도이다.

도 8은 머니게이트가 개설하는 온라인숍검색용의 홈페이지에 액세스한 사용자에게 제공되는 검색용 페이지를 예시하는 모식도이다.

도 9는 입력된 검색키워드가 검색된 후의 화면예를 나타내는 모식도이다.

도 10은 도 7에 나타낸 온라인 쇼핑시스템에 있어서, 사용자가 다른 몰의 다른 숍에서 물품을 구입한 경우의 처리의 흐름을 나타내는 제 1모식도이다.

도 11은 도 7에 나타낸 온라인 쇼핑시스템에 있어서, 사용자가 다른 몰의 다른 숍에서 물품을 구입한 경우의 처리의 흐름을 나타내는 제 2모식도이다.

도 12는 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 1모식도이다.

도 13은 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 2모식도이다.

도 14는 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 3모식도이다.

도 15는 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 4모식도이다.

도 16은 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 5모식도이다.

도 17은 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 6모식도이다.

도 18은 도 10 및 도 11에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화상을 설명하기 위한 제 7모식도이다.

도 19는 도 7에 나타낸 온라인 쇼핑시스템에 있어서, 사용자가 다른 몰의 다른 숍에서 디지털 콘텐츠를 구입한 경우의 처리의 흐름을 나타내는 모식도이다.

도 20은 도 7에 나타낸 온라인 쇼핑시스템에 있어서, 사용자가 독립하여 결재처리 등을 행하는 다른 숍으로부터 물품을 구입한 경우의 처리의 흐름을 나타내는 모식도이다.

도 21은 도 20에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화면을 설명하기 위한 제 1모식도이다.

도 22는 도 20에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화면을 설명하기 위한 제 2모식도이다.

도 23은 도 20에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화면을 설명하기 위한 제 3모식도이다.

도 24는 도 20에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화면을 설명하기 위한 제 4모식도이다.

도 25는 도 20에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화면을 설명하기 위한 제 5모식도이다.

도 26은 도 20에 나타낸 처리에 있어서 이용되는 사용자의 단말 상의 화면을 설명하기 위한 제 6모식도이다.

도 27은 머니게이트의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 동일할 경우의 사이트간 통신의 흐름을 나타내는 플로차트이다.

도 28은 머니게이트의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신의 흐름을 나타내는 플로차트이다.

도 29는 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 동일할 경우의 사이트간 통신의 흐름을 나타내는 플로차트이다.

도 30은는 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신의 흐름을 나타내는 플로차트이다.

도 31은 사이트간 통신에 의해 사이트간을 송수신되는 전문포맷(1∼8)을 나타내는 모식도이다.

도 32는 사이트간 통신에 의해 사이트간을 송수신되는 전문포맷(9∼23)을 나타내는 모식도이다.

도 33은 사이트간 통신에 의해 사이트간을 송수신되는 전문포맷(24∼29)을 나타내는 모식도이다.

도 34는 사이트간 통신에 의해 사이트간을 송수신되는 전문포맷(30∼35)을 나타내는 모식도이다.

도 35은 사이트간 통신에 의해 사이트간을 송수신되는 전문포맷(36∼45)을 나타내는 모식도이다.

도 36은 종래의 온라인 쇼핑시스템에 있어서의 처리의 흐름을 설명하기 위한 모식도이다.

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

100. 온라인 쇼핑시스템 200. 사용자

300. 몰사업자, 제 1장치, 제 2장치, 제 1사이트, 제 2사이트

400. 온라인숍, 제 1장치, 제 2장치, 제 1사이트, 제 2사이트

500. 머니게이트 600. 카드회사

700,710,720. 통신네트워크 801∼822. 오브젝트

본 발명은, 예를 들면 온라인쇼핑 등의 인터넷을 거친 상거래에 관한 결제중개 처리장치, 결제중개처리용의 처리프로그램을 격납하는 기억매체, 결제중개용의 컴퓨터프로그램, 온라인숍장치, 온라인쇼핑방법 및 온라인 쇼핑시스템에 관한 것이다.

여기까지의 온라인쇼핑의 처리의 흐름을 도 36에 나타낸다.

어느 온라인몰에 등록하고 있는 회원(사용자)이, 그 몰의 홈페이지에 액세스하면, 통상은 거기에 네비게이션페이지가 있고, 몰에서 각 가맹점의 홈페이지에 링크되어 있다.

이 각 가맹점의 홈페이지에서 사용자가 상품의 신청을 행하면(1), 이 주문데이터는 가맹점에 다다른다(2). 가맹점에서는, 전표를 작성하고, 가상몰의 디벨 로퍼인 몰사업자에 통지한다(3).

몰사업자는, 회원에게 확인메일을 발신하고, 회원이 구입신청을 한 것의 확인을 취한다(4). 그리고, 회원이 구입의 확인의 신호를 수신하면(5), ID, 패스워드에 대응이 부가된 크레디트 카드번호가 몰사업자의 서버중에 격납되어 있어서, 그 카드번호가 결제기관의 결제시스템에 입력되고, 이 시스템을 거쳐서 카드회사에 통지되고, 카드회사에서는 신용승인제이션된다(6).

오소리제이션이 OK이면, 여신결과가 몰사업자에게 회신되고(6), 그 결과가 회원에게 여신결과로서(7) 및 가맹점에 매출신용승인연락(8)으로서, 각각 통지된다.

가맹점은, 상품을 회원에게 발송하는 동시에(9), 매출데이터를 몰사업자서버에 업로드함으로써, 매출확정처리를 행하고(10), 몰사업자는, 각 가맹점에서 입력되는 매출데이터를 정리하여, 결제기관의 결제시스템에 입력한다(11).

그리고, 결제시스템은, 이 매출데이터에 의거하여 각 카드회사마다 크레디트데이터를 건너고, 각 카드회사에서는, 이것에 의거하여 각 회원에게 상품대금을 청구하는 동시에(12), 상품대금을 결제시스템을 거쳐서 몰사업자에게 건낸다(11).

이것에 의해 각 가맹점에 대해서 매출대금이 입금되고, 자금결제가 행해진다(13).

그런데, 이와 같은 여기까지의 전자상거래 시스템에 있어서는, 각 온라인쇼핑이나 몰에 의해 결제수단이 다종 다양하고 각각 독립하고 있다. 그리고, 어느 몰에서 발행된 ID와 패스워드는, 그 몰 내에서밖에 사용할 수 없다. 그 때문에, 여러가지 온라인숍이나 몰을 이용하고 싶은 사용자는, 복수의 숍이나 몰에 몇번이고 개인정보, 카드번호 등을 입력하여 사용자등록을 하지 않으면 안된다.

그리고, 그 결과, 수속이 귀찮고, 관리하여야 할 ID나 패스워드가 증가한다는 문제가 발생하고 있다.

또, 이와 같은 수속을 몇번이고 반복함으로써, 카드정보의 누설의 위험성이 증대한다는 문제도 생기고 있다.

따라서 본 발명의 목적은, 복수의 시스템에서 상거래를 행할 경우에 있어서도, 수속이 용이하고 관리하여야 할 ID나 패스워드가 증가하지 않고 결제에 관계되는 비밀정보의 누설의 위험성이 적게되는 결제시스템을 실현하는 결제중개 처리장치를 제공하는데 있다.

또, 본 발명의 다른 목적은, 자신이 등록하고 있는 온라인쇼핑이나 몰 이외의 쇼핑이나 몰도, 간단한 수속으로 이용할 수 있고, 관리하여야 할 ID나 패스워드가 증가하지 않고 결제에 관계되는 비밀정보의 누설의 위험성도 적게되는 온라인 쇼핑시스템을 제공하기 위한 온라인숍장치를 제공하는데 있다.

또한 본 발명의 다른 목적은, 그와 같은 온라인쇼핑방법 및 온라인시스템을 제공하는데 있다.

상기 과제를 해결하기 위해, 본 발명의 결제중개 처리장치는, 사용자로부터의 네트워크를 거친 요구에 따라서 대가의 지불을 수반하는 소정의 행위를 행하는 제 1장치에서, 상기 소정의 행위의 요구에 관계되는 수주정보를 접수하는 수주정보 접수수단과, 상기 접수된 수주정보에 의거하여, 사용자가 소정의 방법에 의한 금전의 지불에 관계되는 계약을 행하고 있는 제 2장치에서, 상기 사용자가 요구한 상기 소정의 행위의 대가의 지불을 상기 사용자로부터 받기위한 지불정보를 획득하는 지불정보 획득수단과, 상기 접수한 수주정보 및 상기 획득한 지불정보에 의거하여, 상기 사용자가 요구한 상기 소정의 행위의 상기 대가의 결제를 행하는 결제처리수단을 갖는다.

적절하게는, 상기 네트워크를 거친 요구에 따라서 대가의 지불을 수반하는 소정의 행위는, 임의의 상품의 판매이고, 상기 수주정보 접수수단은, 네트워크를 거쳐서 임의의 상품을 판매하는 제 1장치에서, 상품의 주문에 관계되는 수주정보를 접수하고, 상기 지불정보 획득수단은, 상기 접수된 수주정보에 의거하여, 상기 제 2정보에서, 사용자가 주문한 상품의 대가의 지불을 상기 사용자로부터 받기 위한 지불정보를 획득하고, 상기 결제처리수단은, 접수한 수주정보 및 상기 획득한 지불정보에 의거하여 사용자가 구입한 상품의 대가의 결제를 행한다.

일 예로서, 상기 제 1장치 및 상기 제 2장치는, 각각 사용자가 소정의 방법에 의한 금전의 지불에 관계되는 계약을 포함하는 등록을 행하고 있고, 적어도 상기 등록을 행하고 있는 사용자에 대하여 네트워크를 거친 액세스를 허가하고, 상기 액세스에 의해 임의의 상품을 판매하는 복수의 상품판매수단의, 각각 어느 것이고, 상기 수주정보 접수수단은, 복수의 상기 상품판매수단의 어느 .것에 의해, 적어도 상기 상품판매수단 이외의 상기 상품판매수단에 상기 등록을 하고 있는 사용자로부터의 상품의 주문에 관계되는 수주정보를 접수하고, 상기 지불정보 획득수단은, 상기 접수된 수주정보에 의거하여, 상기 사용자가 상기 등록을 하고 있는 상기 상품판매수단에서, 상기 사용자가 주문한 상품의 대가의 지불을 상기 사용자로부터 받기 위한 지불정보를 획득한다.

별도의 일 예로서, 상기 제 1장치와 상기 제 2장치는, 각각, 상기 네트워크를 거친 액세스에 의해 상품을 판매하는 온라인숍수단과, 상기 온라인숍수단에 대한 상기 네트워크를 거친 액세스를 제어하는 온라인숍 관리수단과의 어느 한쪽이다.

별도의 면에서 본 본 발명의 결제중개 처리장치는, 제 1사이트에서 상품의 구입을 행하고자 하는 사용자로부터, 그 사용자자신이 회원등록을 하고 있는 별도의 제 2사이트에서의 그 사용자의 개인특정정보의 입력을 접수하는 수단과, 입력된 상기 개인특정정보를 상기 제 2사이트에 송신하고, 개인특정의 결과 및 결제에 필요한 정보를 그 제 2사이트에서 입수하는 수단을 구비한다.

또한 별도의 면에서 본 본 발명의 결제중개 처리장치는, 제 1사이트에서 상품의 구입을 행하고자 하는 사용자로부터, 그 사용자 자신이 회원등록을 하고 있는 별도의 제 2사이트에서의 그 사용자의 개인특정정보 및 결제에 필요한 정보의 입력을 접수하는 수단과, 입력된 상기 개인특정정보를 상기 제 2사이트에 송신하고, 개인특정의 결과를 그 제 2사이트에서 입수하는 수단을 구비한다.

또한 별도의 면에서 본 본 발명의 결제중개 처리장치는, 제 1사이트에서 품질의 구입을 행하고자 하는 사용자로부터, 그 사용자 자신이 개인특정을 행하는 제 2사이트의 선택입력을 접수하는 수단과, 선택된 상기 제 2사이트에 대하여 그 사용자의 개인특정결과의 회신을 요구하고, 회신된 개인특정결과에 의거하여 결제처리를 행하는 수단을 구비한다.

이와 같은 별도의 면에서 본 본 발명의 결제중개 처리장치에 있어서, 상기 제 2사이트는, 일 예로서, 상기 네트워크를 거친 액세스에 의해 상품을 판매하는 온라인숍의 사이트, 혹은 상기 온라인숍의 사이트에 대한 상기 네트워크를 거친 액세스를 제어하는 온라인숍의 관리사이트이다.

여기서, 본 발명의 결제중개 처리장치에 있어서, 상기 제 2장치(제 2사이트)의 운영자 및 상기 결제중개 처리장치의 운영자를 포함하는 상기 상품의 판매에 관계되는 운영자에 대하여, 수수료를 지불하는 처리를 행하는 수수료지불 처리수단을 또한 가져도 좋고, 이 경우, 일 예로서 상기 수수료지불 처리수단은, 상기 결제를 행한 상품의 대가의 일부를 상기 수수료에 충당한다.

또, 상기 제 1장치(제 1사이트)마다, 상기 제 2장치(제 2사이트)에 상기 등록을 행하고 있는 사용자에 의한 상기 제 1장치(제 1사이트)에의 액세스를 가능하게 하기 위한 실제와는 다른 사용자정보를 상기 제 2장치(제 2사이트)마다 기억하여 놓고, 그 실제와는 다른 사용자정보의 사용자입력에 따라서 상기 제 1장치(제 1사이트)에의 액세스를 가능하게 하는 액세스정보 제공수단을 또한 가져도 좋다. 이 경우, 일 예로서, 상기 실제와는 다른 사용자정보는, 상기 결제중개 처리장치의 사용자 ID를 포함한다.

또, 상기 지불정보 획득수단은, 상기 접수한 수주정보에 의거하여, 상기 제 2장치(제 2사이트)로부터 사용자가 주문한 상품의 대가의 지불을 상기 사용자의 크레디트카드에 의해 결제를 하기 위한, 크레디트 카드번호를 포함한 상기 지불정보를 획득하고, 상기 지불처리수단은, 상기 지불정보 및 상기 지불정보에 의거하여, 상기 사용자의 크레디트카드에 관계되는 크레디트 카드회사로부터, 상기 사용자가 구입한 상품의 대가의 지불을 받기 위한 처리를 실행하도록 해도 좋다.

또, 일 예로서, 상기 지불정보 획득수단(개인특정의 결과 및 결제에 필요한 정보를 그 제 2사이트에서 입수하는 수단)은, 상기 접수한 수주정보에 포함되는 수주번호와, 상기 획득한 지불정보에 포함되는 수주번호에 의거하여, 이들의 정보를 대응시킨다.

또한, 상기 제 1장치(제 1사이트)에 지불방법의 선택입력을 허용하는 지불방법 선택화면을 제공하는 지불방법 입력표시수단과, 이 지불방법 입력표시수단에 의해 상기 결제중개 처리장치에 의한 결제가 선택입력된 경우에만 상기 결제중개 처리장치의 기능을 실행시키는 결제중개 실행수단을 설치해도 좋다.

별도의 일 예로서, 상기 네트워크를 거쳐서 액세스하는 상기 사용자의 장치에 대해서, 상기 결제중개 처리장치에 의해 결제중개처리가 가능한 상기 상품판매수단(제 1사이트)의 리스트를 선택가능하게 표시시키는 리스트표시수단과, 선택된 상기 상품판매수단(제 1사이트)에 상기 사용자의 장치를 액세스시키는 자동액세스수단을 설치해도 좋다.

또한 별도의 일 예로서, 상기 결제중개 처리장치에 의해 결제중개처리가 가능한 상기 상품판매수단(제 1사이트)가 판매하는 상품에 1 또는 2 이상의 검색키워드를 대응시켜서 기억하는 검색키워드 기억수단과, 상기 네트워크를 거쳐서 액세스하는 상기 사용자의 장치에 검색키워드 입력용의 다이어로그박스를 표시시키는 검색키워드 입력수단과, 이 검색키워드 입력수단에 의해 입력된 검색키워드에 의거하여 상기 검색키워드 기억수단에서 대응하는 상기 상품판매수단(제 1사이트)을 검색하고, 검색된 상기 상품판매수단(제 1사이트)에 상기 사용자의 장치를 액세스가능하게 시키는 제 2자동 액세스수단을 설치해도 좋다.

여기서 본 발명의 결제중개 처리장치는, 실제적으로는 네트워크를 거쳐서 액세스 가능한 컴퓨터이다. 그래서, 본 발명의 결제중개 처리장치가 나타내는 기능을 실행하는 컴퓨터 프로그램을 격납하는 기억매체 또는 컴퓨터 프로그램으로서 규정할 수도 있다.

또, 본 발명의 온라인숍장치는, 네트워크를 거친 액세스에 의해 임의의 상품을 판매하는 온라인숍을 등록하여 관리하는 숍관리수단과, 사용자와의 사이에서 금전의 지불에 관계되는 계약을 포함하는 등록처리를 행하고, 상기 등록된 사용자에 대하여 상기 등록한 온라인숍에의 액세스를 허가하는 사용자 관리수단을 가지는 온라인숍장치이며, 상기 사용자 관리수단은, 다른 온라인숍 관리장치에 상기 등록을 행하고 있는 사용자가, 상기 사용자가 구입한 상품의 대가의 지불을 상기 사용자가 등록하고 있는 상기 다른 온라인숍장치에서 상기 사용자의 소정의 지불정보를 획득하여 결제를 행하는 결제중개 처리장치를 거쳐서 액세스하여온 경우에, 상기 사용자로부터의 상기 등록한 온라인숍에의 액세스를 허가한다.

또, 본 발명의 다른 온라인숍장치는, 네트워크를 거친 액세스에 의해 임의의 상품을 판매하는 온라인숍을 등록하여 관리하는 숍관리수단과, 사용자와의 사이에서 금전의 지불에 관계되는 계약을 포함하는 등록처리를 행하고, 상기 등록된 사용자에 대하여 상기 등록한 온라인숍에의 액세스를 허가하는 사용자 관리수단을 가지는 온라인숍장치이며, 상기 사용자 관리수단은, 상기 등록된 사용자가 다른 상기 온라인숍장치에 의해 관리되고 있는 온라인숍에서 상품을 구입한 경우이고, 상기 사용자가 구입한 상품의 대가의 결제를 중개하여 행하는 결제중개 처리장치에서 요구가 있었던 경우에는, 상기 사용자의 상기 금전의 지불에 관계되는 계약에 의거한 상기 사용자가 결제를 행하기 위한 소정의 지불정보를 상기 결제중개 처리장치에 제공한다.

또, 본 발명의 온라인쇼핑방법은, 네트워크 상에 설치된 임의의 온라인숍에 있어서, 네트워크를 거쳐서 액세스하여 온 임의의 사용자가 낸 상품의 주문에 의거하여, 수주정보를 생성하고, 이 생성한 수주정보를 걸제중개 처리장치에 송신하고, 상기 결제중개 처리장치에 있어서, 상기 상품의 주문을 행한 사용자가 등록하고 있는 온라인숍장치에서, 상기 사용자로부터 지불을 접수하기 위한 소정의 지불정보를 획득하고, 상기 획득한 지불정보에 의거하여 상기 사용자에 대하여 결제를 행하고, 상기 결제를 행한 상기 상품의 대가에 대한 소정의 수수료를, 적어도 상기 온라인숍 및 상기 결제중개 처리장치에 지불하고, 이 수수료를 지불한 나머지를 상기 온라인숍에 지불한다.

또, 본 발명의 온라인 쇼핑시스템은, 네트워크를 거친 액세스에 의해 임의의 상품을 판매하는 복수의 온라인숍과, 상기 온라인숍을 등록하여 관리하는 숍관리수단과, 사용자와의 사이에서 금전의 지불에 관계되는 계약을 포함하는 등록처리를 행하고, 상기 등록된 사용자에 대하여 상기 등록한 온라인숍에의 액세스를 허가하는 사용자 관리수단을 가지는 온라인숍장치이며, 다른 온라인숍 관리장치에 상기 등록을 행하고 있는 사용자가, 결제중개 처리장치를 거쳐서 액세스하여온 경우에, 상기 사용자로부터의 상기 등록한 온라인숍에의 액세스를 허가하고, 상기 등록된 사용자가 다른 상기 온라인숍장치에서 관리되어 있는 온라인숍에서 상품을 구입한 경우에 상기 사용자가 결제를 행하기 위한 소정의 지불정보를 상기 결제중개 처리장치에 제공하는, 복수의 온라인숍장치와, 임의의 상기 온라인숍장치에서 수주정보를 접수하는 수주정보 접수수단과, 상기 접수한 수주정보에 의거하여 사용자가 등록을 행하고 있는 상기 온라인숍장치에서 대가의 지불을 상기 사용자로부터 받기 위한 지불정보를 획득하는 지불정보 획득수단과, 상기 접수한 수주정보 및 상기 획득한 지불정보에 의거하여, 상기 사용자가 요구한 상기 소정의 행위의 상기 대가의 결제를 행하는 결제처리수단을 갖는 결제중개 처리장치를 갖는다.

(실시예)

본 발명의 일실시의 형태에 대해서, 도 1∼도 26을 참조하여 설명한다.

본 실시의 형태에 있어서는, 복수의 온라인쇼핑몰(이하, 단순히 몰이라고 함)이 통신네트워크 상에 전개되어 있고, 어느 몰의 회원이라도 다른 몰에 새롭게 등록하지 않아도 다른 몰에서 온라인쇼핑을 할 수 있는 온라인 쇼핑시스템에 대해서 설명한다.

최초에, 본 실시의 형태에서는, 복수의 목차마다 온라인 쇼핑시스템을 설명 한다. 그리고, 이들의 항목의 목차를 다음에 열거한다.

- 목차 -

A. 개요설명

(1) 기본적인 구성

(2) 기본적인 동작

①. 상품구입시의 동작

②. 매출·결제처리

B. 상세설명

(1) 구성예

(2) 동작, 처리의 흐름

①. 물품의 판매

②. 디지털 콘텐츠의 판매

a) 인증사이트가 사용자의 크레디트 카드번호를 인식하고 있지 않은 경우

b) 인증사이트가 사용자의 크레디트 카드번호를 인식하고 있는 경우

(3) 각 사이트간의 통신

①. 머니게이트의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 동일할 경우의 사이트간 통신

②. 머니게이트의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신

③. 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 동일할 경우의 사이트간 통신

④. 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신

(4) 요약

이상 열거한 바와 같은 항목에 따라서, 이하, 본 실시의 형태에 대해서 설명한다.

A. 개요설명

(1) 기본적인 구성

먼저, 본 실시의 형태의 온라인 쇼핑시스템의 기본적인 구성에 대해서 도 1∼도 4를 참조하여 설명한다.

도 1은, 그와 같은 온라인 쇼핑시스템의 기본적인 구성을 나타내는 도면이다.

온라인 쇼핑시스템(100)은, 사용자(200), 몰사업자(300)(제 1장치, 제 1사이트, 제 2장치, 제 2사이트, 상품판매장치, 온라인 쇼핑수단, 온라인 쇼핑관리수단), 온라인숍(400)(제 1장치, 제 1사이트, 제 2장치, 제 2사이트, 상품판매장치, 온라인숍수단, 온라인 숍관리수단), 머니게이트(500)(결제중개 처리장치), 카드회사(600) 및 통신네트워크(700, 710, 720)를 그 기본적인 구성으로서 갖는다.

여기서, 사용자(200), 몰사업자(300), 온라인숍(400), 머니게이트(500) 및 카드회사(600)는, 적어도 문언상 그 일부가 자연인이나 법인 등으로서 표현되어 있는바, 이들은 상거래의 장면에 있어서는 자연인이나 법인 등을 의미하고, 그 기능이 실행되는 장면에 있어서는, 그들의 자연인이나 법인 등이 소유하고 조작하거나 하는 컴퓨터를 의미하고 있다. 즉, 그들의 사용자(200), 몰사업자(300), 온라인숍(400), 머니게이트(500) 및 카드회사(600)는, 그 기능이 실행되는 장면에 있어서는, 기억매체로서의 기억장치에 격납된 동작프로그램 등에 의거하여 프로세서가 데이터처리를 실행하는 컴퓨터이다. 그래서, 후술하는 각종의 수단은, 기억장치에 격납된 동작프로그램 등에 의거한 프로세서에 의해 실행되는 각종의 기능에 의해 실행된다. 또한, 동작프로그램인 컴퓨터 프로그램을 격납하는 기억매체로서는, 컴퓨터의 기억장치에 한하지 않고, 예를 들면, CD-ROM을 전형적으로 하는 가반성을 가지는 기억매체에 패케이징되어 있어도 좋다.

사용자(200)는, 상거래의 장면에 있어서는, 통신네트워크(700)를 거쳐서 실제로 온라인숍(400)에 있어서 상품을 구입하는 주로 일반개인의 사용자이다.

사용자(200)는, 상거래의 장면에 있어서는, 통신네트워크(700)를 거쳐서 몰사업자(300)가 개설하고 있는 몰 혹은 온라인숍(400)이 개설하고 있는 숍을 액세스하는 것이 가능한 환경을 가지며, 복수의 몰사업자(300)의 적어도 어느 하나의 몰에 등록한 회원이며, 몰사업자(300)가 요금의 지불에 대해서 보증하고 있는 사용자이다.

통상, 사용자(200)는 그 기능이 실행되는 장면에 있어서는, 통신네트워크(700)의 임의의 노드에 접속된 퍼스널컴퓨터 등에 의해 구성된다.

몰사업자(300)는, 상거래의 장면에 있어서는, 로컬한 개개의 인터넷·서비스·프로바이더(ISP), 환언하면 개개의 온라인쇼핑몰의 개설자이며, 온라인쇼핑의 플랫폼인 몰 등을 인터넷(700) 상에 전개하고, 온라인숍의 개설희망자 및 온라인숍의 사용자 쌍방에, 온라인숍 서비스를 제공한다.

구체적으로는, 몰사업자(300)는 그 기능이 실행되는 장면에 있어서는, 개설한 몰에 출점하는 온라인숍(400)의 관리를 행한다(숍관리수단).

또, 몰사업자(300)는 그 기능이 실행되는 장면에 있어서, 회원등록한 사용자(200)를, 이용자 데이터베이스의 형태로 기억하여 관리한다(사용자 관리수단).

또, 그 기능이 실행되는 장면에 있어서, 몰사업자(300)에 의해서는, 개설하는 몰 내의 온라인숍(400)에 있어서의 수주를 관리하는 경우도 있다. 그와 같은 경우에는, 몰사업자(300)는 예를 들면 수주데이터베이스에 의한 전 수주데이터의 관리, 사용자(200)에의 주문의 확인, 결제기관에의 신용승인요구 등, 온라인쇼핑 전반에 걸친 여러 가지의 처리를 행한다.

또, 온라인 쇼핑시스템(100)에 있어서는, 각 몰에 등록하고 있는 사용자(200)는, 후술하는 머니게이트(500)를 거침으로써, 등록을 하고 있지 않은 다른 몰에 있어서도 쇼핑을 할 수 있게 되어 있고, 그와 같은 시스템을 실현하기 위해, 각 몰사업자(300)는 다음과 같은 처리를 행한다. 여기서의 처리는, 말할 것도 없이 컴퓨터에 의한 처리이다.

먼저, 머니게이트(500)를 거친 쇼핑을 인식하는 다른 몰의 회원용에, 그 회원을 자신의 몰의 회원으로서 취급하기 위한 ID등의 정보를 다른 몰마다 발행하고, 이용자 마스터에 등록하여 놓는다.

구체적으로 도 2를 참조하여 설명한다.

지금, 상호 머니게이트(500)를 거친 쇼핑을 구하는 3개의 몰 A∼몰 C가 있었다고 하면, 각 몰의 몰사업자(300)는, 자신 이외의 다른 몰에 대하여 ID, 패스워드 및 더미의 크레디트 카드번호를 설정하여 놓는다.

다시 말하면, 몰 A의 몰사업자(300a)는, 몰 B의 회원용에, 「mlb@mg2」라는 ID, 「12345768」이라고 하는 패스워드, 「111100000002」라고 하는 더미의 크레디트번호를, 또, 몰 C의 회원용에, 「mlc@mg2」라고 하는 ID, 「12345678」이라고 하는 패스워드, 「111100000003」이라고 하는 더미의 크레디트번호를 각각 발행하고, 자기의 회원 ID에 기억하여 놓는다. 이들의 ID, 패스워드 및 크레디트번호는, 임시 또는 실제와는 다른 ID, 패스워드 및 크레디트번호가 된다.

또한, 머니게이트(500)를 거친 액세스를 위한 이들의 ID를 머니게이트 ID라고 하는 것으로 한다.

또, 이들 각 몰사업자(300)에서 발행된 정보는, 후술하는 머니게이트(500)의 각 몰사업자의 속성정보로 링크를 당긴 Web화면의 등록관리를 행하기 위한 콜레트서버(510)(도 1참조)에 있어서도, 도 4에 나타내는 바와 같은 사업자마스터의 형태로 등록된다. 즉, 머니게이트(500)의 콜레트서버(510)에 있어서는, 각 서버(200)에 대해서, 몰사업자마다, 임시 또는 실제와는 다른 ID, 패스워드 및 크레디트번호를 기억하여 놓는다. 이것에 의해 각 몰사업자(300)에서 ID, 패스워드 및 크레디트번호가 콜레트서버(510)에 송신된 경우, 그들의 ID, 패스워드 및 크레디트번호라는 속성정보가 임시 또는 실제와는 다른 것이라고 하여도, 콜레트서버(510)에 있어서는 그들의 속성정보가 어느 사용자(200)의 속성정보인지를 인식할 수 있다.

또, 몰사업자(300)는 그와 같은 다른 몰 회원용의 ID를 이용한, 상기 다른 몰의 회원으로부터의 몰에의 액세스를 접수하고, 몰 내의 온라인숍(400)에서의 쇼핑을 가능하게 한다.

그리고, 그와 같은 다른 몰의 회원에서 몰 내의 숍이 수주를 받은 경우에는, 몰사업자(300)는, 사용자(200)에 대한 주문의 확인을 행한 후, 이것을 머니게이트(500)에 통지한다. 그리고, 머니게이트(500)에서 수주의 신용승인이 얻어진 경우에, 수주처리를 행하고 온라인숍(400)에 대한 출하의뢰 등을 행한다.

또한, 몰사업자(300)가 관리하는 회원이 다른 몰에서 쇼핑을 행한 경우에는, 머니게이트(500)에서 본인인증 리퀘스트가 보내지므로, 그것에 의거하여 인증을 행하고, 크레디트 카드번호 등의 결제에 관계되는 정보를 머니게이트(500)에 송신한다.

그 때문에, 몰사업자(300)는 예를 들면 도 3에 나타내는 바와 같은 팝업화면을 웨이브서버에 격납하여 놓고, 머니게이트(500)에서 리퀘스트가 보내졌을 때에는, 이 팝업화면을 사용자(200)의 화면상에 올린다.

또한, 몰사업자(300)와 머니게이트(500)와의 사이의 통신로(710)는, 세큐어한 통신이 행해질 필요가 있고, 전용선이 SSL(Secure Socket Layer)에서 데이터를 보내는 구조를 갖는 것이 필요하다.

몰사업자(300)는, 이와 같이, 숍(400)과 사용자(200) 및 머니게이트(500)의 사이에서, 온라인쇼핑이 적절하게 행해지도록 여러가지 처리를 행한다.

온라인숍(400)은, 몰사업자(300)가 제공하는 환경상에 숍을 개설하고, 통신네트워크(700)를 거쳐서, 사용자(200)에 대하여, 물품이나 디지털 콘텐츠 등의 임의의 상품을 온라인 판매한다.

그리고 온라인숍(400)은, 실질적으로 머니게이트(500)에 대하여 신용승인요구나 자금결제 등의 처리를 행한다. 이때 몰의 형태에 의해서는, 몰사업자(300)가 중개하여 일단 수주데이터를 관리한 후, 머니게이트(500)에 대해서 처리하도록 하는 경우도 있다.

또한, 이 온라인숍(400) 자체가, 하나의 몰을 형성하고 있어도 좋다.

머니게이트(500)는, 복수의 몰사업자(300)에 의한 결제를 통합하여 행하기 위한 결제처리 통합기관이다.

먼저, 머니게이트(500)는, 각 몰사업자(300)에게 할당한 사업자의 속성정보에의 링크를 당긴 Web화면(이후, 이것을 콜레트 혹은 콜레트 오브젝트라고 함)의 등록관리를 행하는 콜레트서버(510)를 가지고 있고, 사용자(200)가 자신이 등록하고 있는 몰 이외의 몰에 있어서도 용이하게 상품을 주문할 수 있도록 하고 있다. 즉, 콜레트는 사용자(200)의 컴퓨터에 있어서는, 그 사용자(200)의 속성정보를 포함하는 독자의 콜레트로서 스스로의 컴퓨터 내에 보유되어 있고, 콜레트 오브젝트로서 사용자(200)의 화면상에 출현시킬 수 있다. 이 콜레트 오브젝트에는, 액세스 가능한 몰사업자(300)나 온라인숍(400)마다 임시 또는 실제와는 다른 ID에 대한 정보가 링크되어 있다.

콜레트서버(510)에는, 상술한 바와 같이, 각 몰사업자(300)가 발행한 다른 몰에 대한 ID 등의 정보, 즉, 도 4에 나타내는 바와 같은, 각 몰의 회원마다, 이름, 더미크레디트 카드번호, 패스워드 및 몰사업자(300)마다의 사용 ID 및 URL이 기록되어 있는 사업자마스터가 기억되어 있다. 몰사업자(300)마다의 콜레트는, 이 사업자마스터를 참조하면서, 다른 몰에 있어서 주문을 행할 경우에, 소망의 정보를 소망의 필드에 기입한다.

구체적으로는, 먼저, 사용자(200)에 있어서, URL에 의거하여 사업자를 판별하고, 사용하는 ID를 결정하고, 사용자(200)에 의한 콜레트 오브젝트를 드롭하는 조작 등에 의거하여, 그 사용자(200)가 액세스하고 있는 몰사업자(300)나 온라인숍(400)에서는 ID, 패스워드 및 크레디트 카드번호 등을 기입하는 필드를 검출하여 기입한다. 이것은, 몰사업자(300)나 온라인숍(400)에 액세스하고 있는 사용자(200)의 화면상에 표시되는 인증용의 사용자속성 입력화면(도 3참조)에 대한 사용자(200)의 입력조작에 의해 실행된다. 이 경우, 컴퓨터로서의 사용자(200)는, 그 몰사업자(300)나 온라인숍(400)인 사업자의 URL을 인식하고 있는 것에서, 사업자를 특정할 수 있다. 그래서, 그와 같은 인증용의 사용자속성 입력화면 중에의 콜레트 오브젝트의 드롭조작 등에 의해, 사용자(200)가 보유하는 콜레트는, 특정된 사업자에 따라서 임시 또는 실제와는 다른 ID, 패스워드 및 크레디트 카드번호를 선택할 수 있고, 이 선택결과로서의 임시 또는 실제와는 다른 ID, 패스워드 및 크레디트 카드번호를 몰사업자(300)나 온라인숍(400)에 송신하는 것이다. 그래서, 사용자(200)가 액세스하고 있는 몰사업자(300)나 온라인숍(400)은, 그와 같은 임시 또는 실제와는 다른 ID, 패스워드 및 크레디트 카드번호를 콜레트서버(510)에 송신하게 된다. 여기서, 수주정보 접수수단의 기능이 실행된다.

콜레트서버(510)는, 다른 몰에서 쇼핑을 한 사용자(200) 개인의 ID를 얻는 처리중에서, 머니게이트(500)의 수주관리서버(520)로부터의 지시에 의거하여, 사용자(200)가 등록하고 있는 몰사업자(300)를 검출하고, 그 몰사업자(300)에 대해서, 사용자(200)에 대하여 ID·패스워드 입력화면을 제공하여 개인특정 및 결제에 필요한 데이터를 획득하여야 할 뜻의 지시를 내는 처리도 행한다. 여기서, 액세스정보 제공수단, 지불정보 획득수단의 기능이 실행된다.

더욱이, 별도의 실시의 형태로서, 사용자(200)가 액세스하는 몰사업자(300)나 온라인숍(400)이 제공하는 인증용의 사용자속성 입력화면에는, 그 사용자(200)가 등록하고 있는 몰사업자(300)나 온라인숍(400)에 있어서의 개인특정정보로서의 사용자 ID를 입력하도록 해도 좋다. 입력방법은, 콜레트 오브젝트의 드래그나 치수입력 등, 그 종류를 묻지 않는다. 이 경우, 콜레트서버(510)는, 각 사용자(200)에 대한 사용자 ID의 리스트를 참조 가능하게 되어 있다. 그 사용자 ID의 리스트에는, 적어도 사용자(200)와 그 사용자(200)가 등록하고 있는 몰사업자(300)나 온라인숍(400) 등의 사업자를 특정할 수 있는 정보가 대응시켜져서 포함되어 있다. 그래서, 사용자(200)가 액세스하고 있는 몰사업자(300)나 온라인숍(400)은, 그 사용자의 사용자 ID를 콜레트서버(510)에 송신하게 된다. 여기서, 수주정보 접수수단의 기능이 실행된다. 그리고, 사용자 ID의 송신을 받은 콜레트서버(510)는, 그 사용자(200)가 어느 몰사업자(300)나 온라인숍(400)에 등록하고 있는지를 사용자 ID의 리스트를 참조하여 검색하고, 그 몰사업자(300) 등에 대해서, ID·패스워드 입력화면을 사용자(200)에게 제공하여 개인특정 및 결제에 필요한 데이터를 획득하여야 할 뜻의 지시를 내는 처리도 행한다. 여기서, 액세스정보 제공수단, 지불정보 획득수단의 기능이 실행된다.

머니게이트(500)는, 주문정보의 관리를 행하는 수주관리서버(520)를 가지고 있고, 사용자(200), 몰사업자(300) 및 온라인숍(400)사이의 모든 결제처리를 행한다(결제처리수단).

보다 구체적으로는, 먼저 이 수주관리서버(520)에 있어서, 몰사업자(300)로부터 송신된 새로운 주문정보에서, 신규로 수주데이터를 생성하여 등록한다.

이 수주데이터에는, 그 주문이 머니게이트(500)를 거쳐서 행해진 경우, 즉, 사용자(200)가 자신이 등록하고 있는 몰 이외의 몰의 숍에서 행한 주문이었을 경우, 사용자(200)가 등록하고 있는 몰의 ID가 기재되어 있을 뿐이고, 사용자(200) 개인의 ID나 크레디트 카드번호는 기재되어 있지 않다. 그래서, 수주관리서버(520)는, 콜레트서버(510)에 대해서, 상술한 바와 같이 사용자(200) 개인의 ID를 얻도록 지시를 행한다.

혹은, 별도의 실시의 형태로서, 사용자(200)가 자신이 등록하고 있는 몰 이외의 몰의 숍에서 주문을 행한 경우의 수주데이터에, 사용자(200)가 등록하고 있는 몰 등에서의 사용자 ID가 기재되어 있을 경우를 상정한다. 이 경우에는, 수주데이터에, 사용자(200)가 등록하고 있는 몰 등에서의 사용자 ID가 등록되어 있을 뿐이고, 사용자(200) 개인의 크레디트 카드번호는 기재되지 않는다. 그래서, 이 경우에도, 수주관리서버(520)는 콜레트서버(510)에 대하여, 상술한 바와 같이 사용자(200) 개인의 크레디트 카드번호를 얻도록 지시를 행한다.

더욱이, 또 별도의 실시의 형태로서, 사용자(200)가 액세스하는 몰사업자(300)나 온라인숍(400)이 제공하는 인증용의 사용자속성 입력화면에는, 그 사용자(200)가 등록하고 있는 몰사업자(300)나 온라인숍(400)에 있어서의 사용자 ID에 가하여, 결제에 필요한 정보로서 크레디트 카드번호를 입력하도록 해도 좋다. 입력방법은, 콜레트 오브젝트의 드래그나 치수입력 등, 그 종류를 묻지 않는다. 이 경우, 콜레트서버(510)는, 상술한 바와 같은 각 사용자(200)에 대한 사용자 ID의 리스트를 참조 가능하게 되어 있다. 그래서, 사용자(200)가 액세스하고 있는 몰사업자(300)나 온라인숍(400)은, 그 사용자의 사용자 ID 및 크레디트 카드번호를 콜레트서버(510)에 송신하게 된다. 여기서, 수주정보 접수수단의 기능이 실행된다. 그리고, 사용자 ID 및 크레디트 카드번호의 송신을 받은 콜레트서버(510)는, 그 사용자(200)가 어느 몰사업자(300)나 온라인숍(400)에 등록하고 있는지를 사용자 ID의 리스트를 참조하여 검색하고, 그 몰사업자(300) 등에 대해서, ID입력화면을 사용자(200)에게 제공하여 개인특정에 필요한 데이터를 획득하여야 할 뜻의 지시를 내는 처리도 행한다. 여기서, 액세스정보 제공수단, 지불정보 획득수단의 기능이 실행된다.

수주관리서버(520)는, 최종적으로 그 사용자(200)가 회원등록을 하고 있는 몰사업자(300)에서 송신되는 사용자(200)의 ID, 크레디트 카드번호 등의 정보를, 등록하고 있는 수주데이터에 기입한다. 이와 같은 사용자(200)가 회원등록을 하고 있는 몰사업자(300)에의 문의과정에 있어서는, 사용자에게 향하여, 사용자 특정정보 및 결제필요정보의 입력을 촉구하는 다이어로그를 표시시켜도 좋다. 이 경우에는, 그 다이어로그에 있어서, 사용자(200) 스스로가 사용자 ID나 패스워드, 크레디트 카드번호 등의 정보를 입력하고, 그 정보를 그 사용자(200)가 등록하고 있는 몰사업자(300) 등에 문의하고, 그 몰사업자(300) 등에 있어서 사용자확인을 실행시키고, 이것을 수주관리서버(520)에 회신시킨다. 혹은, 각 사용자에 대응하는 크레디트 카드번호를 각 사용자가 회원등록을 하고 있는 몰사업자(300) 등에 있어서 확인하고 있는 경우에는, 사용자(200)에 대해서, 상술한 바와 같은 다이어로그에 사용자 ID나 패스워드 등과 같은 사용자 특정정보만을 입력시키고, 그 정보를 그 사용자(200)가 등록하고 있는 몰사업자(300) 등에 문의하고, 그 몰사업자(300) 등에 있어서 사용자확인의 실행과 크레디트 카드번호의 검색을 실행시키도록 해도 좋다. 그후, 그 몰사업자(300)로부터 사용자확인과 결제에 필요한 정보로서의 크레디트 카드번호와의 회신을 수주관리서버(520)에 행하도록 한다.

이와 같은 처리를 거친 후, 수주관리서버(520)는, 정규로 크레디트 카드번호 등이 기입된 수주데이터를 카드회사(600)에 송신하여, 신용승인요구를 행하는 동시에, 신용승인을 수취하고, 숍(400) 측에 주문양해, 혹은, 캔슬 등의 정보를 송신한다.

또한, 이 신용승인처리에 관해서는, 수주관리서버(520)는, 몰사업자(300)로부터 신용승인요구가 있기 전에 미리 신용승인요구를 행하고, 얻어진 신용승인결과를 축적하여 놓는다. 그리고, 후로부터 온 몰사업자(300)의 신용승인요구에 대해서는, 그 수주번호에서 대응하는 신용승인결과를 검출하고, 이것을 회신한다.

그리고, 수주관리서버(520)는, 판매한 대금의 이익회신의 처리를 행한다(수수료지불 처리수단).

예를 들면, 머니게이트(500)를 거친 판매의 경우에는, 카드회사(600)로부터 상품판매대금에서 소정의 비율의 수수료가 차감된 액수의 지불이 행해진다. 이 지불에 대해서 머니게이트(500)는, 사용자(200)가 등록하고 있는 몰사업자(300)에게, 사용자(200)의 소개수수료로서 매출의 소정의 비율을 지불하고, 다시 온라인숍(400)이 개설되어 있던 몰사업자(300)에 대하여 매출의 소정의 비율의 수수료를 지불하고, 또, 자신도 소정의 비율의 수수료를 징수하고, 나머지를 온라인숍(400)에 지불한다.

카드회사(600)는, 머니게이트(500)로부터의 정보에 의거하여, 실제로 결제처리를 행하는 것이고, 여기까지의 구성과 동일하다.

통신네트워크(700)는, 온라인 쇼핑시스템(100)의 몰이나 숍, 구입자 등의 노드가 설치되고, 온라인 쇼핑시스템(100)을 전개하는 광역한 통신네트워크 시스템이며, 본 실시의 형태에 있어서는 인터넷이다. 이후, 통신네트워크(700)는 인터넷(700)이라고 한다.

또, 통신로(710) 및 통신로(720)는, 몰사업자(300)와 머니게이트(500) 및 머니게이트(500)와 카드회사(600)와의 사이의 통신네트워크이며, 각각 세큐어한 통신을 행할 수 있는 환경정비가 필요하다.

따라서, 전용선이나, SSL(Secure Socket Layer)에서 데이터를 보내는 구조를 갖는 것이 필요하다.

상술한 바와 같이, 본 발명의 결제중개처리에 있어서는, 어느 몰사업자(300)나 온라인숍(400)에 등록하지 않은 사용자(200)에 대해서, 그 사용자(200)가 등록하고 있는 몰사업자(300) 등(제 2사이트, 인증사이트)에서 그 사용자(200)의 인증정보나 결제에 필요한 정보를 획득하고, 그 사용자(200)에 등록하지 않은 몰사업자(300) 등(제 1사이트, 판매사이트)에서의 온라인쇼핑을 가능하게 한다는 것이다. 그래서, 이와 같은 처리를 가능하게 하기 위해서는, 적어도 사용자(200) 개인을 특정하는 정보, 그 사용자(200)가 등록하고 있는 몰사업자(300) 등을 특정하는 정보 및 그 사용자(200)가 결제하는데 필요한 정보의 획득이 필수가 된다. 그래서, 실시에 있어서는, 그들의 각종의 정보를 어느 단계에서 획득하도록 구성하는가를 적의 설정하는 것이 가능하다. 상술한 본 실시의 형태의 설명에 있어서도, 그 일부의 조합을 소개하였지만, 실제에 있어서는, 그와 같은 소개한 조합에 한하지 않고, 각종의 조합이 가능하다.

여기서, 상술한 온라인쇼핑의 과정에 있어서, 결제하는데 필요한 정보, 예를들면 크레디트 카드번호의 취급에 관해서는 각종의 형태가 실현 가능하다. 일 예로서, 몰사업자(300)에 대한 사용자(200)의 등록에 있어서, 혹은 등록 후에, 그 몰사업자(300)에 대한 크레디트 카드번호 등의 통지가 필요할 경우에는, 그 몰사업 자(300)는 등록하고 있는 사용자(200)의 크레디트 카드번호 등의 결제에 필요한 정보를 미리 획득하고 있는 것으로 된다. 그래서, 이와 같은 몰사업자(300)가 제 2사이트인 인증사이트가 될 경우에는, 상술한 온라인쇼핑의 과정에 있어서 사용자(200)에 의한 크레디트 카드번호 등의 입력이 불필요하다. 이것에 대해, 등록에 있어서 혹은 그 후에도 사용자(200)로부터 크레디트 카드번호 등을 요구하지 않는 몰사업자(300)의 경우에는, 그 몰사업자(300)가 제 2사이트인 인증사이트가 된다고 하면, 상술한 온라인쇼핑의 과정에 있어서 사용자(200)에 의한 크레디트 카드번호 등의 입력이 필요하게 된다.

(2) 기본적인 동작

다음에, 이와 같은 구성의 온라인 쇼핑시스템(100)의 기본적인 동작에 대해서, 도 5 및 도 6을 참조하여 설명한다.

①. 상품구입시의 동작

먼저, 사용자(200)가 상품을 구입하였을 때의 동작에 대해서, 도 5를 참조하여 설명한다.

먼저, 사용자(200)가 온라인숍(400)이 제공하는 Web페이지 등에서 상품을 구입하고, 즉, 상품의 주문을 온라인숍(400)에 내면(1), 온라인숍(400)은, 금액 등, 카드회사(600)에 대한 신용승인에 필요한 데이터를 가지는 수주데이터를 생성하고, 그 수주데이터를 머니게이트(500)에 송신한다(2).

머니게이트(500)는, 그 수주데이터를 머니게이트(500)내의 수주서버에 유지하는 동시에, 그 수주데이터에 부가되어 있는 IP어드레스 및 몰사업자(300)의 ID에 의거하여, 사용자(200)를 특정하고, 그 사용자(200)에 대해서, ID와 패스워드를 요구한다(3).

사용자(200)가 그 요구에 따라서 ID와 패스워드를 입력함으로써, 그 입력된 ID와 패스워드는, 몰사업자(300)에 송신된다(4).

이 ID와 패스워드에 의거하여, 몰사업자(300)에 있어서 인증처리가 행해져서 적정한 사용자(200)인 것이 확인되면, 몰사업자(300)는, 그 ID와 패스워드에서 크레디트데이터를 구하고, 그 크레디트데이터를 머니게이트(500)에 송신한다(5). 이때의 몰사업자(300)로부터 머니게이트(500)에의 크레디트데이터의 송신은, 인터넷을 거치지 않고 전용선을 거쳐서 행한다.

머니게이트(500)는, 몰사업자(300)로부터 입력된 크레디트데이터를 수주서버에 기억되어 있는 온라인숍(400)에서 입력된 수주데이터에 기입하고, 카드회사(600)에 대해서 신용승인요구를 행한다(6).

카드회사(600)는, 그 요구에 의거하여 신용승인를 행하고, 신용승인결과를 머니게이트(500)에 회신한다(7).

머니게이트(500)는, 회신된 신용승인결과에 의거한 수주처리를 행할 것인지 아닌지의 결정을, 일단 온라인숍(400)에 송신하고(8), 온라인숍(400)은, 그 결과를 보고, 최종적으로 머니게이트(500)에 대해서 신용승인요구를 행한다(9). 이 신용승인요구에 대해서는, 머니게이트(500)는 이것을 카드회사(600)까지 날리지 않고, 미리 머니게이트(500)가 유지하고 있는 신용승인결과를 온라인숍(400)에 대해서 회신한다(10).

그리고, 이 신용승인결과에 의거하여, 온라인숍(400)은 사용자(200)에게 주문이 완료한 뜻의 결과를 통지하고, 상품을 발송한다(11).

②. 매출·결제처리

다음에, 마감일마다 행하는 매출·결제처리의 동작에 대해서, 도 6을 참조하여 설명한다.

먼저, 각 온라인숍(400)은, 매출데이터를 머니게이트(500)에 송신한다(1).

머니게이트(500)에 있어서는, 수주서버에 유지하고 있는 수주데이터와 송신된 매출데이터를 대조하여, 매출데이터에 크레디트번호를 입력하고, 크레디트번호를 입력한 매출데이터를 카드회사(600)에 송신하고, 대금청구를 행한다(2).

이것에 의해 카드회사(600)는, 사용자(200)에 대해서 대금을 청구하고(3), 지불을 받는다(4).

그리고, 카드회사(600)는, 소정의 수수료를 차감하고 머니게이트(500)에 대금을 지불한다(5).

머니게이트(500)는, 몰사업자(300)에 대해서 고객 소개수수료로서 소정의 비율을 지불하고(6), 또, 자신의 수수료(b%)를 다시 차감하여, 온라인숍(400)에 대해서 대금을 지불한다(7).

B. 상세설명

다음에, 이와 같이 기본적인 구성 및 동작으로서 나타낼 수 있는 온라인 쇼핑시스템의 실제의 구성예 및 그 동작, 처리의 흐름의 예에 대해서 도 7∼도 26을 참조하여 구체적으로 설명한다.

(1) 구성예

도 7은, 실제의 네트워크에 적용된 온라인 쇼핑시스템(100)의 구성을 나타내는 도면이다.

도 7에 나타내는 바와 같이, 실제의 온라인 쇼핑시스템(100)에 있어서는, 사용자(200), 몰사업자(300) 및 카드회사(600)는 어느 것도 복수 존재하고, 또한, 이들은 상시 그 구성이 다이내믹하게 변화하고 있는 것이다.

사용자(200)는, 네트워크(700)에 접속되는 임의의 노드이며, 복수의 몰사업자(300) 중의 어느 것에 등록함으로써, 온라인 쇼핑시스템(100)의 사용자(200)로 될 수 있다. 즉, 어느 몰사업자(300)에 등록함으로써, 온라인 쇼핑시스템(100)의 기타 몰에서도, 그 몰의 회원과 동일한 처리에 의해 쇼핑을 행할 수 있다.

몰사업자(300)는, 결제처리수단으로서 머니게이트(500)를 이용하는 것을 전제로 하고, 온라인 쇼핑시스템(100) 내의 다른 몰사업자가 개설한 몰에 대해서 자신의 회원사용자가 쇼핑에 액세스하는 것, 반대로, 다른 몰사업자에 등록하고 있는 사용자가 자신이 개설하고 있는 몰에, 쇼핑에 액세스하고 있는 것을 인정하면, 임의의 몰사업자가 온라인 쇼핑시스템(100)의 몰사업자(300)로서 등록 가능하다.

그리고, 후술하는 바와 같이, 그와 같은 회원사용자(200)의 상호의 액세스에 의해 상품의 매매가 성립한 경우에, 회원의 등록을 접수관리하고 있는 몰사업자(300)의 쌍방이 소정의 수수료를 수취할 수 있도록 함으로써, 이와 같은 몰사업자(300)에게도 이익이 초래된다.

머니게이트(500)는, 이와 같은 온라인 쇼핑시스템(100)에 있어서, 상술한 바와 같은 콜레트서버(501) 및 수주관리서버(520)에 의해, 사용자(200), 몰사업자(300) 및 온라인숍(400)사이의 액세스 및 결제처리를 일원 관리한다. 이것에 의해, 그들 상호의 액세스 및 쇼핑이 가능하게 된다.

(2) 동작, 처리의 흐름

이하, 도 7에 나타내는 바와 같은 실제의 온라인 쇼핑시스템(100)의 동작, 환원하면 이와 같은 온라인 쇼핑시스템(100)에 있어서의 처리의 흐름에 대해서, 구체적으로 설명한다.

또한, 이하의 설명은, 상술한 기본적인 온라인 쇼핑시스템의 동작을 실제의 시스템에 적용한 형태의 설명이다. 따라서, 상술한 흐름과는 다소의 상위가 있지만, 실질적인 데이터의 흐름, 동작이 다른 것은 아니다.

본 실시의 형태에서는, 도 7에 나타내는 바와 같은 온라인 쇼핑시스템(100)에 있어서, 몰 A, B, C를 개설하고 있는 몰사업자(300)의 어느 것에 대해서 회원등록을 행하고 있는 사용자(200)가, 회원등록을 하고 있지 않은 몰 A, B, C에 개설되어 있는 숍(400)에 있어서 온라인쇼핑을 행할 경우의 처리를 고려한다.

이 경우, 사용자(200)는, 적어도 하나의 몰사업자(300) 또는 온라인숍(400)의 회원일 필요가 있다. 그 양태로서는, 각종의 양태가 고려된다. 먼저, 사용자(200)가, 물품의 판매나 디지털 콘덴츠의 판매를 행하는 온라인숍(400)의 회원인 것이 고려된다. 이 경우, 그 온라인숍(400)의 회원인 것에 따라, 그 온라인숍(400)이 가맹하고 있는 몰사업자(300)의 회원이 되는 경우도 상정된다. 그리고, 몰사업자(300)에 착안하면, 이 몰사업자(300)는, 자신에게 등록하고 있는 온라인숍(400)에의 사용자 액세스를 관리제어하는, 예를 들면 인터넷·서비스·프로바이더(IOP)와 같은 것이라도, 그 몰사업자(300) 자체가 물품의 판매나 디지털 콘텐츠의 판매 등을 행하는 온라인숍 기능을 가지는 것이라도 좋다. 또한, 몰사업자(300)는, 도 7 중에서 보이는 것 같이, 복수의 온라인숍(400)을 관리하는 몰사업자 자체를 관리하는 구성이라도 좋다. 더구나, 몰사업자(300)의 몰운영형태로서는, 몰사업자(300) 자체가 카드회사(600)와 계약을 하고 있는 섯같은 운영형태도 허용된다(도 7 중의 몰사업자(300a)참조). 즉, 몰사업자(300a)는, 복수의 카드회사(600)와 계약을 하고 있고, 가맹점이 되는 온라인숍(400)이나 몰사업자(300)에 대해서, 그들의 온라인숍(400)이나 몰사업자(300)가 독자적으로 카드회사(600)와 계약을 맺지 않고, 계약하고 있는 카드회사(600)에 의한 결제를 가능하게 한다는 운영을 제공하는 것이다.

사용자(200)는, 인터넷인 통신네트워크(700)를 거쳐서, 모델사업자(300)에게도, 온라인숍(400)에도, 머니게이트(500)에도 접속 가능하다. 이 경우, 후술하는 바와 같이 사용자(200)는, 자신이 회원이 되어 있는 몰사업자(300)가 아닌 몰사업자(300)에 대해서도 접속 가능하다.

여기서, 사용자(200)가 머니게이트(500)에 접속하였을 경우의 처리를 설명한다. 머니게이트(500)는, 사용자 접속용의 홈페이지를 사용자(200)에게 제공한다. 이 경우의 사용자(200)는, 온라인 쇼핑시스템(100)의 어느 몰사업자(300) 또는 온라인숍(400)의 회원이다.

머니게이트(500)가 사용자(200)에게 제공하는 홈페이지는, 예를 들면 도 8 및 도 9에 예시하는 바와 같은 검색페이지(550)를 가지고 있다. 이 검색페이지(550)는, 어느 물품이나 디지털 콘텐츠의 구입예정이 있는 사용자(200)에 대해서, 그 물품이나 디지털 콘텐츠를 구입하기 위한 온라인숍(400)(이하, 몰사업자(300)도 포함하는 경우를 상정한다)을 온라인 쇼핑시스템(100) 중에서 검색하기 위한 페이지이다. 이 목적을 실현하기 위해, 머니게이트(500)는, 검색페이지(550)를 표시하기 위한 화상이미지 데이터나 표시프로그램, 검색엔진외의, 검색키워드 기억수단을 갖추고 있다. 이 검색키워드 기억수단은, 머니게이트(500)에 의해 결제중개처리가 가능한 상품판매수단, 즉, 온라인 쇼핑시스템(100) 중의 온라인숍(400)이 판매하는 상품에 1 또는 2 이상의 검색키워드를 대응시켜서 기억하는 파일구조를 갖추고 있다.

여기서, 검색페이지(550)는, 머니게이트(500)에 인스톨된 표시프로그램에 따라서, 온라인 쇼핑시스템(100) 중의 모든 온라인숍(400)에 대한 리스트를 숍표시란(551)에 표시한다(리스트 표시수단). 이 숍표시란(551)에는, 온라인숍(400)의 명칭(552)과 링크정보(553)가 표시되어 있다. 표시되는 링크정보(553)는, 소위 URL(Uniform Resource Locator)이고, 머니게이트(500)가 갖추는 검색엔진은, 이 링크정보(553)에 커서를 맞춰서 클릭함으로써, 대응하는 온라인숍(400)의 페이지에 이행할 수 있는 프로그램을 가지고 있다(자동액세스수단).

머니게이트(500)에 인스톨된 표시프로그램은, 검색페이지(550)에 그와 같은 숍표시란(551)뿐만 아니라, 검색키워드 입력용의 다이어로그 박스(554)도 표시한다(검색키워드 입력수단), 이 다이어로그 박스(554)는, 도 8 및 도 9에 나타내는 바와 같이, 검색키워드 입력용의 입력영역(555)과, 검색실행을 지정하기 위한 명령버튼(556)을 가지고 있다. 그리고, 머니게이트(500)에 인스톨된 검색엔진 프로그램은, 다이어로그 박스(554)의 입력영역(555)에 소정의 키워드가 입력된 후에 명령버튼(556)이 클릭되었을 경우에, 입력된 검색키워드에 의거하여 상술한 검색키워드 기억수단에서 대응하는 온라인숍(400)을 검색하고, 검색된 온라인숍(400)의 페이지에 사용자(200)를 링크 가능한 상태로 시킨다(제 2자동 액세스수단). 여기서, 링크 가능한 상태의 일 예로서는, 도 9에 예시하는 바와 같이, 검색된 온라인숍(400)의 리스트를 숍표시란(551)에 표시시키고, 이 숍표시란(551)에, 검색된 온라인숍(400)의 명칭(552)과 링크정보(553)를 표시한다. 링크 가능한 상태의 별도의 일 예로서는, 예를 들면, 검색된 온라인숍(400)이 하나뿐이라면, 그 온라인숍(400)의 페이지에 사용자(200)를 자동적으로 링크한다는 것도 실시 가능하다. 이 경우, 사용자(200)가 능동적 혹은 수동적으로 소정의 온라인숍(400)의 페이지에 액세스하는데 있어서, 그 온라인숍(400)은 그 사용자(200)가 등록하지 않은 몰사업자(300)일 가능성이 있다. 이 경우에는, 후술하는 콜레트서버(510)에 액세스하는 방법에 의해, 사용자(200)는 등록하지 않은 몰사업자(300)가 관리하는 온라인숍(400)의 페이지를 열람하고, 그 페이지에 있어서 쇼핑을 하는 것이 가능하게 된다. 이와 같은 처리의 상세에 대해서는 후술한다.

이하, 물품의 판매와 디지털 콘텐츠의 판매로 나눠서 설명한다.

①. 물품의 판매

예를 들면, 도 7에 나타내는 바와 같은 온라인 쇼핑시스템(100)에 있어서, 몰 B를 개설하고 있는 몰사업자(300b)에 대해서 회원등록을 행하고 있는 사용자(200bj)가, 몰 A에 개설되어 있는 숍(400ai)에 있어서 물품의 쇼핑을 행하는 경우의 흐름에 대해서, 도 7∼도 18을 참조하여 설명한다. 이 경우, 몰 B을 개설하고 있는 몰사업자(300b)는, 사용자(200bj)의 크레디트 카드번호 등의 결제에 필요한 정보를 모르는 것으로 한다.

몰 B의 회원인 사용자(200bj)가 몰 A의 온라인숍(400ai)(제 1사이트, 판매사이트)에 네트 상에 쇼핑을 가서, 구입하고 싶은 소망의 상품을 발견하였을 경우, 사용자(200bj)는, 예를 들면 도 12에 나타내는 바와 같은 쇼핑인지 오브젝트(801)를 클릭함으로써 오더시트(802)를 열고, 이것에 순차 기입을 함으로써 오더를 행한다. 이때, 사용자(200bj)는 몰 A의 회원은 아니지만, 자신이 회원이 되어 있는 몰 B에 대해서 등록되어 있는 소정의 ID를 지정함으로써, 몰 A의 회원과 동일하게, 환언하면 자신이 몰 B의 숍에서 상품을 구입하는 것과 동일하게, 몰 B의 몰사업자(300b)(제 2사이트, 인증사이트)에 대해서 등록하고 있는 크레디트카드를 이용하여 지불을 행할 수 있다.

일 예로서, 그 소정의 ID를 지정하기 위해, 사용자(200bj)는, 머니게이트(500)의 콜레트서버(510)에 액세스하고, 몰 B의 회원용의 콜레트를 이용하여 오더를 행한다(처리 P1). 구체적으로는, 예를 들면 도 12에 오브젝트(803)에서 표시되는 바와 같은 오브젝트를 상승하고, 이 오브젝트를 오브젝트(802)의 대금지불용의 몰 A의 회원 ID를 기재하는 개소에 드롭한다. 여기서, 오브젝트(803)에는, 그 사용자(bj)의 몰 ID 등에 관한 정보가 링크되어 있다. 그래서, 그 오브젝트(803)를 오더시트(802)의 대금지불용의 몰 A의 회원 ID를 기재하는 개소에 드롭한다는 조작에 의해, 그 개소에 사용자(bj)의 몰 ID를 입력되게 된다.

콜레트서버(510)에는, 도 4에 나타낸 바와 같이, 각 몰의 회원에 대응하여, 다른 몰의 URL 및 그 몰을 이용할 때의 ID(머니게이트 ID) 등의 정보가 기재되어 있으므로, 이 조작에 의해, 오더시트(802)의 대금지불자의 ID의 항목에는, 몰 B의 머니게이트 ID가 기입되게 된다.

소정의 ID를 입력하기 위한 별도의 일 예로서는, 사용자(200)가 등록하고 있는 몰사업자(300) 등의 사용자 ID를 사용자(200)에 입력시키도록 하여도 좋다. 이와 같은 구성에 의한 경우에는, 콜레트서버(510) 등에, 사용자 ID와 그 사용자 ID를 등록하고 있는 몰사업자(300) 등을 대응시킨 리스트를 기억시켜 놓을 필요가 있다.

그리고, 최후에, 예를 들면 사용자(200bj)가 주문버튼을 누름으로써, 숍(400ai)에 대해서 주문이 행해진다.

이와 같은 상품의 주문을 접수한 몰 A의 숍(400ai)은, 구입자의 ID나 메일어드레스 및 금액 등의 주문정보를 가지는 수주데이터를 생성하고, 숍을 개설하고 잇는 몰 A의 몰사업자(300a)에게 송신한다(처리 P2). 또한, 몰 B의 회원이 머니게이트(500)를 거쳐서 몰 A의 숍(400ai)에서 쇼핑을 한 본 실시의 형태에 있어서는, 이 수주데이터 중의 ID는, 도 2에 나타낸 머니게이트 이용자 등록정보로서 머니게이트(500)의 콜레트서버(510)에 설정되어 있다. 몰 B회원용의 머니게이트 ID가 된다.

숍(400ai)으로부터의 수주데이터를 수신한 몰 A의 몰사업자(300a)는, 데이터베이스에 수주정보를 등록하고, 수주번호를 채번한다(처리 P3). 그리고, 특히 물품의 판매의 경우에는, 도 13에 도시하는 바와 같은, 주문정보, 수주번호(접수번호), 확인 URL 등을 기재한 확인메일(804)을 사용자(200bj)에게 송신한다(처리 P4: 사용자 관리수단).

확인메일을 수신한 사용자(200bj)는, 지정된 확인URL에 액세스한다(처리 P5).

이 확인URL에의 액세스처리(P5)시도, 일 예로서, 사용자(200bj)는 머니게이트(500)의 콜레트서버(510)에 액세스하고, 몰 B의 회원용의 콜레트를 이용하여 오더를 행한다. 즉, 도 14에 나타내는 바와 같은 액세스 접수화면(805)에 의해 사용자 ID의 입력이 구해지고 있을 때에, 콜레트 오브젝트(806)를 상승하고, 이 오브젝트를 ID를 기재하는 개소에 드롭함으로써, 몰 B회원용의 머니게이트 ID를 기입한다. 혹은, 별도의 일 예로서, 몰 B에서의 회원용의 사용자 ID를 치수입력 등의 방법으로 입력한다.

확인URL에 액세스한 사용자(200bj)는, 또한, 예를 들면 도 15에 나타내는 바와 같은 화면(807)에서 접수번호(수주번호)를 입력하고, 도 16에 나타내는 바와 같은 화면(808)에 의해, 스스로의 주문내용을 확인한다. 그리고, 문제가 없으면 구입하는 뜻의 버튼(809)을 선택하여 확인을 행한다(처리 P6).

사용자(200bj)로부터의 주문의 확인을 얻은 몰 A의 몰사업자(300a)는, ID, 수주번호, 사용자(200bj)의 IP어드레스 및 주문정보 등의 수주데이터를 머니게이트(500)에 송신한다(처리 P7).

수주데이터를 수신한 머니게이트(500)는, 수신한 수주데이터를 수주관리서버(520)에 등록한다(처리 P8). 또한, 이 등록은, 수주데이터를 카드회사 등과 신용승인요구를 행할 때의 데이터형식으로 기록한다. 그를 위해서는 사용자(200bj)의 크레디트 카드번호가 필요하지만, 이 시점에서는 도 2에 나타낸 머니게이트이용자 등록정보에 설정되어 있는 더미의 크레디트 카드번호를 기록하여 놓는다.

수주데이터를 기록한 머니게이트(500)는, 사용자(200bj)가 회원등록을 하고 있는 몰 B의 몰사업자(300b)에게, 사용자(200bj)에 대해서 몰 B에 있어서의 ID 및 크레디트 카드번호의 입력을 얻을 수 있는 웨이브화면을 올리고, ID 및 크레디트 카드번호를 얻도록 지시한다(처리 P9). 또한, 이때 머니게이트(500)는, 얻어지는 사용자(200bj)의 정보와 수주데이터를 대응시키기 위해, 수주번호(접수번호)의 정보를 몰 B의 몰사업자(300b)에 송신하여 놓는다. 이것에 의거하여, 몰 B의 몰사업자(300b)는, 사용자(200bj)에 대해서, 도 17에 나타내는 바와 같은, ID 및 크레디트 카드번호를 요구하는 화면(810)을 올린다(처리 P10), 그 결과, 사용자(200bj)에 있어서는, 화면(808)과 화면(810)을 올리고 있는 몰사업자가 다른 것이 한번에 눈치채지 않는 상태에서, 주문내용을 확인하는 화면(808) 상에 ID 및 크레디트 카드번호의 입력을 요구하는 오브젝트(810)가 표시된다. 이와 같이 오브젝트(810)에 있어서 크레디트 카드번호의 입력을 사용자(200bj)에 구하는 이유는, 그 사용자(200bj)가 회원등록을 하고 있는 몰 B을 개설하고 있는 몰사업자(300b)는, 사용자(200bj)의 크레디트 카드번호 등의 결제에 필요한 정보를 모르기 때문이다.

사용자(200bj)가, 화면(810)을 거쳐서, ID, 패스워드 등의 입력 및 확인 등의 작업을 행하면, 그 결과가 화면(810)을 올리고 있는 몰 B의 몰사업자(300b)에게 통지된다(처리 P11).

이것에 의거하여 몰 B의 몰사업자(300b)는, 머니게이트(500)에 대하여, 사용자(200bj)의 크레디트 카드번호, 유효기한 및 입회상태 등의 카드회사와의 신용승인에 이용하는 정보, 몰 B에 있어서의 ID, IP어드레스 및 앞서 머니게이트(500)에서 송신되어온 수주번호의 정보를, 머니게이트(500)에 송신한(처리 P12).

그리고, 머니게이트(500)에 있어서는, 몰 B의 몰사업자(300b)에서 입력된 수주번호에 의거하여 앞에 수주관리서버(520)에 기록되어 있는 수주데이터를 검색하여 대응하는 수주데이터를 추출하고, 그 수주데이터에 설정되어 있는 더미의 크레디트 카드번호를 몰 B의 몰사업자(300b)에서 수신한 사용자(200bj)의 정규의 크레디트 카드번호로 고쳐 씀으로써, 몰 B의 몰사업자(300b)로부터의 데이터를 데이터베이스에 등록한다(처리 P13: 지불정보 획득수단).

다음에 머니게이트(500)는, 정규의 크레디트 카드번호가 설정된 수주데이터를 이용하여, 카드회사(600)에 대하여 신용승인요구를 행하는(처리 P14) 카드회사(600)는, 그 요구에 의거하여 신용승인를 행하고, 적정하면 신용승인을 머니게이트(500)에 회신한다(처리 P15).

머니게이트(500)는, 회신된 신용승인결과에 의거하여, 주문을 신용승인하는 뜻의 데이터를 몰 A의 몰사업자(300a)에게 송신한다(처리 P16).

이상의 처리에 의해, 결제처리수단의 기능이 실행된다.

이 수신된 정보에 의거하여, 몰 A의 몰사업자(300a)는, 머니게이트를 이용하지 않는 다른 수주와 동일한 처리가 되는 수주처리를 지금 한번 행하고(처리 P17), 그 수주처리에 의거하여, 머니게이트(500)에 대하여 재차 신용승인요구를 행한다(처리 P18).

머니게이트(500)는, 몰 A의 몰사업자(300a)로부터의 이 신용승인요구에 대하여, 미리 카드회사(600)에서 수신하고 있던 신용승인을 회신한다(처리 P19).

머니게이트(500)에서 신용승인을 받은 몰 A의 몰사업자(300a)는, 수주가 완료한 것으로서, 사용자(200BJ)에 대해서 여신결과 및 처리완료의 보고를, 예를 들면 도 18에 나타내는 바와 같은 오브젝트형태로 행하는 동시에(처리 P20), 숍(400ai)에 대해서, 매출신용승인 및 출하의뢰를 행한다(처리 P21).

이와 같이, 본 시스템에서는, 머니게이트(500)가 카드회사(600)에 대하여 신용승인요구를 하는 타이밍(처리 P14)과, 몰사업자(300b)로부터의 요구에 의거하여 신용승인을 회신하는 타이밍(처리 P19)과의 사이에 엇갈림을 생기게 하고 있다. 이것은, 머니게이트(500)를 통하지 않고 몰 A의 회원이 몰 A에 있어서 온라인쇼핑을 행하는 경우, 사용자로부터의 주문내용의 확인을 기다려서 몰 A는 카드회사(600)에 신용승인요구를 행하고 있으므로, 이것과의 정합을 취하는 의미로, 카드회사(600)로부터의 신용승인에 의거하여 주문신용승인통지를 몰 A에 행하고(처리 P16), 이 주문신용승인통지에 의거하여 몰 A에서 신용승인요구가 있고서(처리 P18) 부터신용승인을 회신하고 있다.

사용자로부터의 주문내용확인을 기다려서 신용승인요구를 하고 있는 것은, 사용자의 오조작에 의한 오발주나 지나친 주문에 의거한 오발송 대책때문이고(본 출원인에 의한 출원, 특개평 10-289267호 공보참조), 온라인쇼핑에 필수의 구성은 아니므로, 몰 A가 상술한 바와 같은 주문내용 확인시스템을 채용하지 않는 경우는, 사용자(200bj)의 크레디트 카드번호가 판명되는 대로 신용승인를 카드회사(600)에 요구하고, 몰 A로부터의 신용승인요구에 응답하여 신용승인결과를 통지하여도 좋다.

출하의뢰를 받은 숍(400ai)은, 사용자(200bj)에게 상품을 발송하고(처리 P22), 다시 몰 A의 몰사업자(300a)에 대해서 출하정보를 송신한다(처리 P23).

몰 A의 몰사업자(300a)는, 숍(400ai)에서 수신한 출하정보를 축적하여 놓고, 예를 들면 월말 등의 마감일에 맞춰서, 더미 크레디트 카드번호, 매출금액 및 신용승인번호를 가지는 매출데이터 및 수주번호, 상품명 및 금액의 정보를 가지는 매출이용 명세데이터를 생성하고(처리 P24), 각각 머니게이트(500)에 송신한다(처리 P25).

머니게이트(500)에 있어서는, 수신한 매출데이터 중의 더미 크레디트 카드번호데이터를 실제의 크레디트 카드번호데이터로 변환하고(처리 P26), 카드회사(600)에 대해서 크레디트 카드번호, 상품명 및 금액의 정보를 가지는 청구데이터를 송신한다(처리 P27).

이 청구데이터에 의거하여, 카드회사(600)는 월마다 소정의 기일에 사용자(200bj)에 대해서 일괄하여 카드사용요금의 청구를 행하고(처리 P28), 지정일의 은행인출 등의 처리에 의해 지불을 받는다(처리 P29).

사용자(200bj)로부터 지불을 받은 카드회사(600)는, 지불된 금액에사 소정의 수수료를 차감하고(처리 P30), 잔액을 머니게이트(500)에 지불한다(처리 P31).

머니게이트(500)는, 카드회사(600)로부터 지불된 금액에서 다시 자신의 수수료를 차감(처리 P32), 몰 A의 몰사업자(300a)에 대해서 몰사업자로서의 소정의 수수료를 지불하고(처리 P33), 몰 B의 몰사업자(300b)에 대해서 회원의 소개수수료로서 소정의 비율의 수수료를 지불하고(처리 P34), 남은 금액을 몰 A의 숍(400ai)에 지불한다(처리 P35).

이상과 같은 처리에 의해, 사용자(200bj)는, 자신이 등록하지 않은 몰 A의 숍(400ai)에서, 소망의 물품을 구입한다.

②. 디지털 콘텐츠의 판매

다음에, 동일하게 예를 들면 도 7에 나타내는 바와 같은 온라인 쇼핑시스템(100)에 있어서, 몰 B을 개설하고 있는 몰사업자(300b)에 대해서 회원등록을 행하고 있는 사용자(200bj)가, 몰 A에 개설되어 있는 숍(400ai)에 있어서 쇼핑을 행할 경우이며, 특히, 디지털 콘텐츠를 구입할 경우의 처리의 흐름에 대해서, 도 19를 참조하여 설명한다.

a) 인증사이트가 사용자의 크레디트 카드번호를 인식하고 있지 않은 경우

먼저, 인증사이트(제 2사이트)가 되는 몰 B을 개설하고 있는 몰사업자(300b)가, 사용자(200bj)의 크레디트 카드번호 등의 결제에 필요한 정보를 모를 경우에 대해서 설명한다.

디지털 콘덴츠를 구입할 경우도, 기본적으로, 상술한 물품을 구입하는 경우와 같은 처리이다. 그러나, 물품의 경우와 달리, 디지털 콘텐츠를 네트워크(700)를 거쳐서 배신함으로써 판매할 경우에는, 수주의 확인을 메일에 의해 행할 필요가 없게 된다. 즉, 도 13∼도 15에 나타낸 바와 같은 화면 등을 이용한, 확인메일의 사용자(200bj)에의 송신(처리 P4), 이것에 대한 사용자(200bj)로부터의 액세스(처리 P5)가 불필요하게 된다.

따라서, 도 19에 나타내는 바와 같이, 사용자(200bj)가 머니게이트(500)의 콜레트서버(510)의 몰 B의 회원용의 콜레트를 이용하여, 혹은, 몰 B의 회원용의 사용자 ID를 입력하여 숍(400ai)에 대해서 오더를 행하고(처리 P1), 상품의 주문을 접수한 몰 A의 숍(400ai)이 구입자의 ID나 메일어드레스 및 주문정보(혹은 사용자 ID)를 몰사업자(300a)에 송신하고(처리 P2), 몰 A의 몰사업자(300a)가 수주정보의등록 및 수주번호의 채번을 행하면(처리 P3), 바로 도 16에 나타내는 바와 같은 주문확인의 화면(808)이 사용자(200bj)에게 제시된다(처리 P5').

사용자(200bj)는, 이것을 보고 스스로의 주문내용을 확인하고, 문제가 없으면 구입하는 뜻의 버튼(809)을 선택하여 주문의 양해를 행한다(처리 P6').

이하의 사용자(200bj)로부터의 주문의 확인을 얻은 몰 A의 몰사업자(300a)가 주문정보 등의 수주데이터를 네트워크(500)에 송신하는(처리 P7) 처리 이후의 처리는, 도 10∼도 18을 참조하여 상술한 물품을 구입할 경우의 처리와 동일하다.

사용자(200bj)가 자신이 등록하고 있지 않은 몰 A의 숍(400ai)에서 디지털 콘텐츠를 구입할 경우에는, 이와 같은 처리가 적절하다.

b) 인증사이트가 사용자의 크레디트 카드번호를 인식하고 있는 경우

다음에, 몰 A를 개설하고 있는 몰사업자(300a)에 대하여 회원등록을 행하고 있는 사용자(200ai)가, 직접 결제처리를 행하는 숍(400ck)에 있어서 물품의 쇼핑을 행할 경우의 처리의 흐름에 대해서, 도 7 및 도 20∼도 26을 참조하여 설명한다. 이 경우, 인증사이트(제 2사이트)가 되는 몰 A를 개설하고 있는 몰사업자(300a)는, 사용자(200ai)의 크레디트 카드번호 등의 결제에 필요한 정보를 알고 있다. 또, 몰 A를 개설하고 있는 몰사업자(300a)는, 독자적으로 카드회사(600)와 결제계약을 맺고 있다.

또한, 도 7에 나타내는 바와 같이 숍(400ck)은 몰 C의 몰사업자(300c)에 숍을 개설하고 있는 것으로 하지만, 이 몰 C의 몰사업자(300c)는, 몰 내의 각 숍에 있어서의 수주나 결재에 하등 관계되지 않고, 단순히 인터넷(700) 상에 있어서의 사이트를 숍에 제공하는 것만의 사업자라고 말하게 된다.

이와 같은 형태의 온라인쇼핑에 있어서도, 기본적으로는 상술한 각 예와 동일의 수순으로 처리는 진행된다.

먼저, 몰 A의 회원인 사용자(200ai)는, 머니게이트(500)의 콜레트서버(510)의 몰 A의 회원용의 콜레트를 이용하고, 숍(400ck)의 사이트에 들어간다(처리 P1).

기본적으로는, 예를 들면 도 21에 나타내는 바와 같은 오브젝트(814)를 올리고, 이 오브젝트를 예를 들면 숍(400ck)의 홈페이지(812)에 설치되어 있는 ID 및 패스워드를 기재하는 개소(813)에 드롭한다. 콜레트서버(510)에는, 도 4에 나타낸 바와 같이, 각 몰의 회원에 대응하여, 다른 몰의 URL 및 그 몰을 이용할 때의 ID(머니게이트 ID) 등의 정보가 기재되어 있으므로, 이 조작에 의해, 홈페이지(812)의 ID 및 패스워드의 항목(813)에는, 몰 A의 머니게이트 ID 및 패스워드가 기입되고, 이것에 의해 사용자(200ai)는 숍(400ck)의 사이트에 액세스 가능하게 된다.

별도의 일 예로서, 몰 A의 회원인 사용자(200ai)는, 그 몰 A에서의 회원용의 사용자 ID를 이용하여 숍(400ck)의 사이트에 들어가도록 해도 좋다(처리 P1).

숍(400ck)의 사이트에 들어가면, 사용자(200ai)는, 홈페이지에서 소개되고 있는 상품을 순차 열람하면서, 예를 들면 도 22에 나타내는 바와 같은 소위 쇼핑바구니(815)라고 말하여 지는 것같은 기능을 이용하여 순차 쇼핑을 행한다. 그리고 최종적으로, 예를 들면 도 23에 나타내는 바와 같은 오더시트(816)를 올리고, 이것에 의해 주문을 행한다(처리 P2"). 그때, 예를 들면 도 23에 나타내는 바와 같은 주문방법 및 주문방법을 선택하는 윈도우(817)가 표시된다(지불방법 입력표시수단). 그래서, 머니게이트(500)를 거친 지불을 선택할 경우에는, 그 윈도우(817)에 있어서, 「Shopping Switch」의 항을 선택하고, 이것보다 머니게이트(500)를 거친 지불을 선택하여 놓는다. 이와 같은 머니게이트(500)의 선택에 의해, 이하의 처리가 실행된다.

숍(400ck)은, 이와 같은 수주를 접수하면, 수주데이터를 생성하고, 이것을 데이터베이스를 등록하는 동시에 수주번호를 채번한다(처리 3").

그리고, 특히 물품의 판매의 경우에는, 도 24에 나타내는 바와 같은 주문서 확인화면(818)을 바로 사용자(200ai)에게 제시하고, 주문의 확인을 구한다(처리 P5").

사용자(200ai)는, 이것을 보고 자신의 주문내용을 확인하고 문제가 없으면, 이 사이트에 들어간 것과 같게 콜레트 오브젝트(814)를 호출하고, 이것을 ID기재개소(819)에 드롭하여 ID를 입력하고, 다시 주문을 송신하는 뜻의 버튼(820)을 선택하여 주문의 양해를 행한다(처리 P6").

사용자(200ai)로부터의 주문의 확인을 얻은 숍(400ck)은, ID, 수주번호, 사용자(200ai)의 ID어드레스 및 주문정보 등의 수주데이터를 머니게이트(500)에 송신한다(처리 P7").

머니게이트(500)는, 수신한 수주데이터를 수주관리서버(520)에 등록하고(처리 P8), 사용자(200ai)가 회원등록을 하고 있는 몰 A의 몰사업자(300a)에, 사용자(200ai)에 대하여 몰 A에 있어서의 ID 및 패스워드의 입력을 얻는 웨이브화면(821)을 올리고, ID 및 패스워드를 얻도록 지시한다(처리 P9'). 또한, 이때 머니게이트(500)는, 얻어지는 사용자(200ai)의 정보와 수주데이터를 대응하기 위해, 수주번호(접수번호)의 정보를 몰 A의 몰사업자(300a)에게 송신하여 놓는다.

여기서, 사용자(200ai)에 대하여 크레디트 카드번호 등과 같은 결제에 필요 한 정보의 입력을 구하지 않는 것은, 몰 A의 몰사업자(300a)에 있어서 그 사용자(200ai)의 크레디트 카드번호 등을 인식 가능하기 때문이다.

이것에 의거하여, 몰 A의 몰사업자(300a)는, 사용자(200ai)에 대하여, 도 25에 나타내는 바와 같은, ID 및 패스워드를 요구하는 화면(821)을 올린다(처리 P10"). 그 결과, 사용자(200ai)에 있어서는, 화면(818)과 화면(821)을 올리고 있는 몰사업자가 다른 것이 한번에 눈치채지 못하는 주문내용을 확인하는 화면(818) 상에 ID 및 패스워드의 입력을 요구하는 오브젝트(821)가 표시된다.

사용자(200ai)가, 화면(821)을 거쳐서, ID, 패스워드의 입력을 행하면, 그 결과가 몰 A의 몰사업자(300a)에게 통지되고(처리 P11"), 이것에 의거하여 몰 A의 몰사업자(300a)는, 머니게이트(500)에 대하여, 사용자(200ai)의 크레디트 카드번호, 유효기한 및 입회상태 등의 카드회사와의 신용승인에 이용하는 정보, 몰 A에 있어서의 ID, IP어드레스 및 앞서 머니게이트(500)에서 송신되어 온 수주번호의 정보를, 머니게이트(500)에 송신한다(처리 P12).

그리고, 머니게이트(500)에 있어서는, 몰 A의 몰사업자(300a)로부터 입력된 수주번호에 의거하여, 앞서 수주관리서버(520)에 기록되어 있는 수주데이터를 검색하여 대응하는 수주데이터를 추출하고, 그 수주데이터에 설정되어 있는 더미의 크레디트 카드번호를 몰 A의 몰사업자(300a)로부터 수신한 사용자(200ai)의 정규의 크레디트 카드번호로 고쳐씀으로써, 몰 A의 몰사업자(300a)로부터의 데이터를 데이터베이스에 등록한다(처리 P13).

다음에 머니게이트(500)는, 카드회사(600)에 대하여 신용승인요구를 행하고(처리 P14), 이것에 의거하여 카드회사(600)는 신용승인를 행하고, 적정하면 신용승인을 머니게이트(500)에 회신한다(처리 P15).

여기서, 별도의 일 예로서, 몰 A을 개설하고 있는 몰사업자(300a)는, 독자적으로 카드회사(600)와 결제계약을 맺고 있기 때문에, 이와 같은 몰 A을 개설하고 있는 몰사업자(300a)가 계약을 맺고 있는 카드회사(600)와의 사이에서 결제를 행하도록 해도 좋다. 이 경우, 머니게이트(500)가 카드회사(600)에 대하여 신용승인요구를 행하고(처리 P14), 이것에 의거하여 카드회사(600)가 신용승인를 행하고, 적정하면 신용승인을 머니게이트(500)에 회신한다(처리 P15)라는 처리는 실행되지 않는다. 즉, 몰 A을 개설하고 있는 몰사업자(300a)의 측에서 신용승인 요구처리 및 신용승인의 수신처리를 실행한다. 일 예로서, 몰사업자(300a)는, 사용자(200ai)가 화면(821)을 거쳐서 ID, 패스워드의 입력을 행하고, 그 결과가 몰 A의 몰사업자(300a)에게 통지된 후의 타이밍에서(처리 P11"), 카드회사(600)에 대해서 신용승인요구를 행하도록 하면 좋다. 그 결과, 카드회사(600)가 신용승인을 행하고, 적정하면 신용승인을 몰사업자(300a)에게 회신하게 된다. 그래서, 몰사업자(300a)는, 머니게이트(500)에 대해서, 사용자(200ai)에 대하여 크레디트 신용승인이 얻어진 것, 즉 신용승인을 전달한다.

머니게이트(500)는, 회신된 신용승인결과에 의거하여 주문을 승인하는 뜻의 데이터를 숍(400ck)에 송신하고(처리 P16), 이 수신된 정보에 의거하여, 숍(400ck)은, 머니게이트를 이용하지 않는 다른 수주와 동일의 처리가 되는 수주처리를 지금 한번 행하고(처리 P17"), 그 수주처리에 의거하여, 머니게이트(500)에 대해서 재차 신용승인요구를 행한다(처리 P18").

머니게이트(500)는, 숍(400ck)으로부터의 이 신용승인요구에 대하여, 이미 카드회사(600)에서 수신하여온 신용승인을 회신한다(처리 P19).

이것에 의해 숍(400ck)은, 수주가 완료한 것으로서, 사용자(200ai)에 대해서 여신결과 및 처리완료의 보고를, 예를 들면 도 26에 나타내는 바와 같은 오브젝트(822)에 의해 행하는 동시에(처리 P20"), 스스로 매출승인 및 출하처리를 행한다(처리 P21").

이하, 상품발송(P22) 이후의 처리도, 몰사업자에 있어서의 처리를 숍(400ck)이 행함으로써, 도 11을 참조하여 상술한 경우와 동일하게 행해진다. 또한, 이것과 수반하여 몰 C의 몰사업자(300c)에의 수수료분배의 처리(P33)에 대응하는 처리는 불필요하게 된다.

이상과 같은 처리에 의해, 사용자(200ai)는, 몰이 아니고 직접 결제처리를 행하는 형태의 숍(400ck)에 대해서도, 등록을 하지 않아도 물품을 구입할 수 있다.

여기서, 상술의 예의 경우에 있어서, 결제를 어디서 행하는지, 즉, 숍(400ck)에서 행할 것인는지, 머니게이트(500)가 행할 것인지, 혹은 몰사업자(300a)가 행하는지에 대해서는, 사용자(200ai)에 선택성을 부여하는 것이 소망스럽다. 사용자(200ai)에게 선택권을 부여하는 방법으로서는, 일 예로서, 도 23에 나타내는 바와 같은 주문방법 및 지불방법을 선택하는 윈도우(817)에 있어서 사용자(200ai)에게 선택허용성 부여하는 것이 실현 가능하다.

(3) 각 사이트간의 통신

이어서, 각 사이트간의 통신처리에 대해서 도 7∼도 35를 이용하여 설명한다.

먼저, 각 사이트간의 인터페이스의 이용양태를 표 1에 예시한다. 그 양태는, 표 1에 설명하는 바와 같이, 머니게이트(500)의 기본형태와, 쇼핑스위치 접수서비스 이용형태와, 메일오더형태와의 3양태가 있다. 그 개요에 대해서는 표 1에서 설명하는 바와 같다.

순번	종류	개요	비고
1	MoneyGate 기본형태	MoneyGateS-SW가 추장하는 기본적인 이용형태. 기존의 수주처리에 MoneyGateS-SW API를 짜넣는 것으로 MoneyGateS_SW를 이용한다.
2	S-SW접수서비스이용형태	발주(Order)화면의 처리처를 MoneyGateS-SW접수서비스로 하는 것에서 MoneyGateS-SW이용하는 형태. 기존의 수주처리에의 영향을 적게하는 것이 가능하지만, 기존수주처리에 제어가 되돌아오는 것은 MoneyGate사이에서의 신용승인처리가 종료한 후가 된다. 이 형태를 선택한 경우라도 MoneyGateS-SW API를 일부사용하게 된다.
3	메일오더형태	수주확인을 메일로 실시하고 있는 쇼핑사이트방향의 이용형태. 기존의 수주처리에 MoneyGateS-SW API를 짜넣는 것으로 MoneyGateS-SW를 이용한다.

이들의 3양태중, 메일오더형태는, 수주확인을 메일로 실시하지만, 결제처리를 통신 상에서 실행하지 않은 형태이기 때문에, 그 설명은 생략한다. 이것에 대해, 머니게이트(500)의 기본형태와 쇼핑스위치 접수서비스 이용형태에 대해서는, 도 27 내지 도 35에 의거하여 이하에 기술한다.

이어서, 수주처리에 있어서의 사이트간 인터페이스는, 수주사이트인 몰사업자(300)나 온라인숍(400)마다 다르다. 구체적으로는, 머니게이트(500)에 등록하고 있는 등록사업자 사이트(예를 들면, 몰사업자(300)와 실제의 쇼핑을 사용자(200)에게 제공하는 판매사이트(예를 들면, 온라인숍(400))가 동일한 경우와 다를 경우가 있다. 후자의 전형적인 예로서는, 등록사업자 사이트가 인터넷·서비스·프로바이더(ISP)일 경우이다. 그래서, 머니게이트(500)의 기본형태와 쇼핑스위치 접수서비스 이용형태와의 각각에 대해서, 등록사업자 사이트와 판매사이트가 동일할 경우와 다를 경우에 대해서, 각각 설명한다. 즉, 이후의 설명은, 4양태가 된다.

여기서, 도 27은 머니게이트(500)의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 동일인 경우의 사이트간 통신의 흐름을 나타내는 플로차트, 도 28은 머니게이트(500)의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신의 흐름을 나타내는 플로차트, 도 29는 쇼핑스위치 접수서비스이용형태에 있어서 등록사업자 사이트와 판매사이트가 동일할 경우의 사이트간 통신의 흐름을 나타내는 플로차트, 도 30은 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신의 흐름을 나타내는 플로차트이다. 그리고, 도 31∼도 35에는, 사이트간 통신에 의해 사이트간을 송수신되는 전문포맷을 나타낸다.

①. 머니게이트의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 동일할 경우의 사이트간 통신

먼저, 도 27에 나타내는 바와 같이, 실제의 시스템으로서는, 함께 몰사업자(300)나 온라인숍(400)인 쇼핑사이트(제 1사이트, 판매사이트)(450)와 인증사이트(제 2사이트)(350)에는, 각각에 본래의 기능을 가지게 하기 위한 수주사이트(451)와 웨이브서버(351)가 설치될 뿐만아니라, 각각 머니게이트(500)와 연휴하는 쇼핑스위치 연휴서버(452, 352)가 설치되어 있다. 그리고, 이들의 각 양태에 있어서, 도 7에 예시한 몰사업자(300a)에 상당하는 시스템(300a)이 연휴하고 있다. 상술한 바와 같이, 이 몰사업자(300a)는, 자기 자신이 복수의 카드회사(600)와 계약을 하고 있고, 가맹점이 되는 온라인숍(400)이나 몰사업자(300)에 대해서, 그들의 온라인숍(400)이나 몰사업자(300)가 독자적으로 카드회사(600)와 계약을 맺지 않고, 계약하고 있는 카드회사(600)에 의한 결제를 가능하게 한다는 운영을 제공한다. 구체적으로는, 몰사업자(300a)는, 가맹점이 되는 온라인숍(400)이나 몰사업자(300)에 있어서 사용자(200)가 크레디트카드거래를 지정한 경우, 그 크레디트카드거래에 대한 신용승인요구를 접수하고, 카드회사(600)에 대하여 신용승인요구를 하여 그 결과를 받고, 온라인숍(400) 등에 결과를 통지하는 것 및 예를 들면 월단위의 온라인숍(400) 등의 매출을 모아서 각각 카드회사(600)에 청구하는 작업을 행한다.

이하, 사이트간 통신에 대해서 상세히 기술한다.

전제로서, 사용자(200)가 인터넷인 통신네트워크(700)를 거쳐서 쇼핑사이트(450)의 수주사이트(451)에 액세스하는데는, 그 사용자(200)가 회원등록을 하고 있는 인증사이트(350)를 특정하는 정보가 필요하게 된다. 그리고, 이와 같은 인증사이트(350)를 특정하는 정보를 입력하여 쇼핑사이트(450)의 수주사이트(451)에 액세스하고 있는 사용자(200)로부터 주문서요구가 송신되면(1), 수주사이트(451)는 그 사용자(200)에 대하여 주문서를 송신한다(2). 그때의 전문내용은 도 31에 나타내는 바와 같다. 이것에 의해, 사용자(200)에게 오더화면이 제공된다.

사용자(200)는, 그 오더화면에서 발주를 한다. 이때 콜레트입력 등을 실행하면, 콜레트서버(510)에 인증사이트 정보요구가 나온다(3). 즉, 인증사이트(350)는, 그 서버(200)가 회원등록을 하고 있는 사이트이지만, 그 사이트는 하나로는 한하지 않기 때문에, 인증사이트(350)가 복수있는 경우, 사용자(200)에게 선택의 여지가 부여되게 된다. 인증사이트 정보요구가 된 콜레트서버(510)는, 인증사이트 선택화면을 사용자(200)에게 제공하고(4), 사용자(200)에게 임의의 인증사이트(350)를 선택하는 기회를 부여한다.

그 인증사이트 선택화면에서 소망의 인증사이트(350)를 사용자(200)가 선택하면, 수주사이트(451)에 주문요구가 된다(5). 이 주문요구에는, 사용자(200)가 지정한 인증등록사업자 거래처코드가 포함되어 있다. 그러면, 쇼핑사이트(450)에서는, 그 쇼핑스위치 연휴서버(452)에 주문등록요구가 발신되고(7), 그후 쇼핑스위치 연휴서버(452)는, 머니게이트(500)의 수주관리서버(20)에 향하여 주문등록요구를 발신한다(8). 이상의 처리에 있어서의 전문내용은, 도 31에 나타내는 바와같다.

그후에 이어지는 처리로서는, 수주관리서버(520)에서 쇼핑스위치 연휴서버(452)에의 주문등록응답(9), 쇼핑스위치 연휴서버(452)에서 수주사이트(451)에서 사용자(200)에게 콜레트 리다이얼요구(수주)가 행해진다(17). 이 콜레트 리다이얼요구(수주)에는, 머니게이트 ID가 포함되어 있지만, 이 머니게이트 ID는, 거래단위로 콜레트서버(510)가 생성하는 ID이고, 이 시점에서는, 머니게이트 ID에 의해 사용자(200)의 동일성이 식별되지는 않는다.

그래서, 사용자(200)가 콜레트 리다이얼(수주)을 하면, 그때의 전문은 콜레트서버(510)에 송신된다(18). 콜레트 리다이얼(수주)의 전문을 받은 콜레트서버(510)는, 인증사이트 리다이렉트요구를 사용자(200)에게 반송한다(19). 도 32에 나타내는 바와 같이, 이 인증사이트 리다이렉트요구에는, 상술한 (5)의 처리로 사용자(200)가 지정한 인증등록사업자의 URL이 포함되어 있다. 그래서, 이 인증등록사업자 URL을 이용하고, 사용자(200)로부터, 대응하는 URL을 가지는 인증등록사업자인 인증사이트(350)의 웨이브서버(351)에 로그 온요구가 행해진다(20). 이것을 받은 인증사이트(350)의 웨이브서버(351)는, 그 사용자(200)에게 로그 온화면을 제공한다(21).

로그 온화면의 제공을 받은 사용자(200)는, 로그 온화면 중에 인증서버 ID나, 크레디트카드번호 등의 자기동일성을 식별할 수 있는 정보를 입력한 위에서, 인증사이트(350)의 웨이브서버(351)에 대하여 로그 온요구를 하고(22), 이것에 의해 그 웨이브서버(351)에서의 인증이 실행된다. 즉, 여기서 처음으로, 그 서버의 비밀성이 높은 정보인 인증 ID나 크레디트 카드번호 등의 정보가 온라인 송신되게 되는 것이다. 더욱이, 상술한 바와 같이, 인증사이트(350)에 있어서의 웨이브서버(351)에 있어서, 인증 ID 등을 키로서 그 사용자(200)의 크레디트 카드번호를 검색 가능하면, 로그 온요구시에 크레디트 카드번호의 송신이 불필요하고, 한층 안전성이 도모된다.

이렇게 하여, 인증처리를 실행한 웨이브서버(351)는, 인증사이트(350)의 쇼핑스위치 연휴서버(352)에 인증결과통지를 행하고(23), 이것에 따라서 인증사이트(350)의 쇼핑스위치 연휴서버(352)는 수주관리서버(520)에 인증결과통지를 행한다(24).

이후, 주문관리서버(520)는, 몰사업자(300a)의 시스템(e-SCOTT)에 대하여 신용승인요구를 송신한다(25). 이것에 따라서, 몰사업자(300a)는, 사용자(200)마다 결정되는 크레디트카드의 카드회사(600)에 신용승인요구를 행하고, 카드회사(600)에서 그 결과인 신용승인결과를 수신한다. 그리고, 그 신용승인결과를 수주관리서버(520)에 회신한다(25).

몰사업자(300a)의 시스템(e-SCOTT)에서 크레디트카드의 신용승인결과를 받은 수주관리서버(520)는, 쇼핑사이트(450)에 설치된 쇼핑스위치 연휴서버(452)에 대하여 신용승인결과를 포함하는 인증결과보고를 행한다(26). 이것에 의해 쇼핑스위치 연휴서버(452)는, 신용승인되었는지 어떤지를 알 수 있다. 그래서, 신용승인결과를 포함하는 인증결과보고를 받은 쇼핑사이트(450)의 쇼핑스위치 연휴서버(452)는, 수주관리서버(520)에 신용승인결과에 따른 결과에 대한 결과코드를 포함하는 인증결과보고를 송신하고(27), 매매거래성립의 유무를 수주관리서버(520)에 연락한다. 이것에 따라서, 수주관리서버(520)는 인증사이트의 쇼핑스위치 연휴서버(352)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(28)을 하고, 그 쇼핑스위치 연휴서버(352)는 인증사이트(350)의 웨이브서 버(351)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(29)을 행한다. 이것에 의해 인증사이트(350)는, 신용승인결과 및 매매거래성립의 유무를 알 수 있다.

그후, 인증사이트(350)의 웨이브서버(351)에서 사용자(200)에의 콜레트 리다이렉트요구(인증)가 행해지고(30), 이것에 따라서 사용자(200)로부터 콜레트서버(510)에의 콜레트 리다이렉트(인증)가 행해진다(31). 그리고, 이것에 따라서 콜레트서버(510)에서 사용자(200)에 수주사이트 리다이렉트요구가 행해지고(32), 사용자(200)로부터 수주사이트(450)에의 리다이렉트가 행해진다(33).

그 결과, 쇼핑사이트(450)에 있어서, 수주사이트(451)와 쇼핑스위치 연휴서버(452)와의 사이에서의 신용승인 결과요구(API)(35), 신용승인 결과응답(API)(36), 신용승인요구(API)(40)가 각각 행해지고, 신용승인요구(API)를 받은 쇼핑스위치 연휴서버(452)와 수주관리서버(520)와의 사이에서의 신용승인요구(41)와 신용승인응답(42)이 각각 행해진다. 그리고, 신용승인응답을 받은 쇼핑사이트(450)의 쇼핑스위치 연휴서버(452)는 수주사이트(451)에 신용승인응답(API)을 송신하고, 수주사이트(451)는 사용자(200)에게 완료화면을 제공한다(45).

이와 같은 일련의 처리에 의해, 쇼핑사이트(450)에서는 회원등록을 하지 않은 사용자(200)라도, 인증사이트(350)에서 회원등록을 하고 있으면, 쇼핑사이트(450)에서의 온라인쇼핑이 가능하게 된다.

②. 머니게이트의 기본형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신

먼저, 도 28에 나타내는 바와 같이, 실제의 시스템으로서는, 몰사업자(300)나 온라인숍(400)인 쇼핑사이트(제 1사이트, 판매사이트)(450)외에, 수주등록사업자 사이트(360)(제 1사이트)와 인증사이트(제 2사이트)(350)가 설치되어 있다. 수주등록사업자 사이트(360)는, 쇼핑사이트(450)인 수주사이트(451)에 대해서, 이 수주사이트(451)를 관리하는 온라인 숍관리수단으로서 기능한다. 그리고, 이들의 수주등록사업자 사이트(360)와 인증사이트(350)에는, 각각에 본래의 기능을 가지게 하기 위한 수주기존 시스템사이트(361)와 웨이브서버(351)가 설치될 뿐만 아니라, 각각, 머니게이트(500)와 연휴하는 쇼핑스위치 연휴서버(362, 352)가 설치되어 있다. 그리고, 이들의 각 양태에 있어서, 도 7에 예시한 몰사업자(300a)에 상당하는 시스템(300a)이 연휴하고 있다.

이하, 사이트간 통신에 대해서 상세히 기술한다.

전제로서, 사용자(200)가 인터넷인 통신네트워크(700)를 거쳐서 쇼핑사이트(450)의 수주사이트(451)에 액세스하는데는, 그 사용자(200)가 회원등록을 하고 있는 인증사이트(350)를 특정하는 정보가 필요하게 된다. 그래서, 이와 같은 인증사이트(350)를 특정하는 정보를 입력하여 쇼핑사이트(450)의 수주사이트(451)에 액세스하고 있는 사용자(200)로부터 주문서요구가 송신되면(1), 수주사이트(451)는 그 서버(200)에 대하여 주문서를 송신한다(2). 그때의 전문내용은 도 31에 나타내는 바와 같다. 이것에 의해 사용자(200)에게 오더화면이 제공된다.

사용자(200)는, 그 오더화면에서 발주를 한다. 이때, 콜레트입력 등을 실행하면, 콜레트서버(510)에 인증사이트 정보요구가 나온다(3). 즉, 인증사이트(350)는, 그 사용자(200)가 회원등록을 하고 있는 사이트이지만, 그 사이트는 하나라고는 한하지 않기 때문에, 인증사이트(350)가 복수있는 경우, 사용자(200)에게 선택의 여지가 부여되게 되는 것이다. 인증사이트 정보요구가 행해진 콜레트서버(510)는, 인증사이트 선택화면을 사용자(200)에 제공하고(4), 사용자(200)에 임의의 인증사이트(350)를 선택할 기회를 부여한다.

그 인증사이트 선택화면에서 소망의 인증사이트(350)를 사용자(200)가 선택하면, 수주사이트(451)에 주문요구가 행해진다(5). 이 주문요구에는, 사용자(200)가 지정한 인증등록사업자 거래처코드가 포함되어 있다. 그러면, 수주사이트(451)는 수주등록 사업자사이트(360)의 수주기존시스템(361)에 대하여 수주요구를 행하고(6), 그러면, 그 수주기존시스템(361)은 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)에 주문등록요구를 발신한다(7). 그후, 쇼핑스위치 연휴서버(362)는, 머니게이트(500)의 수주관리서버(520)에 향하여 주문등록요구를 발신한다(8). 이상의 처리에 있어서의 전문내용은, 도 31에 나타내는 바와 같다.

그후에 이어지는 처리로서는, 주문관리서버(520)에서 쇼핑스위치 연휴서버(362)에의 주문등록응답(9), 쇼핑스위치 연휴서버(362)에서 수주기존시스템(361)에의 주문등록응답이 행해지고(10), 수주기존시스템(361)에서 수주사이트(451)에의 수주응답을 거쳐서(11), 사용자(200)에게 콜레트 리다이얼요구(수주)가 행해진다(17). 이 콜레트 리다이얼요구(수주)에는, 머니게이트 ID가 포함되어 있지만, 이 머니게이트 ID는, 거래단위로 콜레트서버(510)가 생성하는 ID이고, 이 시점에서는 머니게이트 ID에 의해 사용자(200)의 동일성이 식별되지는 않는다.

그래서, 사용자(200)가 콜레트 리다이얼(수주)을 하면, 그때의 전문은 콜레트서버(510)에 송신된다(18). 콜레트 리다이얼(수주)의 전문을 받은 콜레트서버(510)는, 인증사이트 리다이렉트요구를 사용자(200)에게 반송한다(19). 도 32에 나타내는 바와 같이, 이 인증사이트 리다이렉트요구에는, 상술한 (5)의 처리에서 사용자(200)가 지정한 인증등록사업자의 URL이 포함되어 있다. 그래서, 이 인증등록사업자 URL을 이용하고, 사용자(200)로부터 대응하는 URL을 가지는 인증등록사업자인 인증사이트(350)의 웨이브서버(351)에 로그 온요구가 행해진다(20). 이것을 받은 인증사이트(350)의 웨이브서버(351)는, 그 사용자(200)에 로그 온화면을 제공한다(21).

로그 온화면의 제공을 받은 사용자(200)는, 로그 온화면 중에 인증사용자 ID나 크레디트 카드번호 등의 자기동일성을 식별할 수 있는 정보를 입력한 위에서, 인증사이트(350)의 웨이브서버(351)에 대하여 로그 온요구를 하고(22), 이것에 의해, 그 웨이브서버(351)에서의 인증이 실행된다. 즉, 여기서 처음으로, 그 사용자의 비밀성이 높은 정보인 인증 ID나 크레디트 카드번호 등의 정보가 온라인송신되게 되는 것이다, 더욱이 상술한 바와 같이, 인증사이트(350)에 있어서의 웨이 브서버(351)에 있어서, 인증 ID 등을 키로서 그 사용자(200)의 크레디트 카드번호를 검색 가능하면, 로그 온요구시에 크레디트 카드번호의 송신이 불필요하고, 한층 안전성이 도모된다.

이렇게 하여, 인증처리를 실행한 웨이브서버(351)는, 인증사이트(350)의 쇼핑스위치 연휴서버(352)에 인증결과통지를 행하고(23), 이것에 따라서 인증사이트(350)의 쇼핑스위치 연휴서버(352)는 수주관리서버(520)에 인증결과통지를 행한다(24).

이후, 주문관리서버(520)는, 몰사업자(300a)의 시스템(e-SCOTT)에 대하여 신용승인요구를 송신한다(25). 이것에 따라서, 몰사업자(300a)는, 사용자(200)마다 결정되는 크레디트카드의 카드회사(600)에 신용승인요구를 행하고, 카드회사(600)로부터 그 결과인 신용승인결과를 수신한다. 그리고, 그 신용승인결과를 수주관리서버(520)에 회신한다(25).

몰사업자(300a)의 시스템(e-SCOTT)에서 크레디트카드의 신용승인결과를 받은 수주관리서버(520)는, 수주등록사업자 사이트(360)에 설치된 쇼핑스위치 연휴서버(362)에 대하여 신용승인결과를 포함하는 인증결과보고를 행한다(26). 이것에 의해 쇼핑스위치 연휴서버(362)는, 신용승인되었는지 아닌지를 알 수 있다. 그래서, 신용승인결과를 포함하는 인증결과보고를 받은 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)는, 수주관리서버(520)에 신용승인결과에 따른 결과에 대한 결과코드를 포함하는 인증결과보고를 송신하고(27), 매매거래성립의 유무를 수주관리서버(520)에 연락한다. 이것에 따라서, 수주관리서 버(520)는, 인증사이트의 쇼핑스위치 연휴서버(352)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(28)을 하고, 그 쇼핑스위치 연휴서버(352)는 인증사이트(350)의 웨이브서버(351)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(29)을 행한다. 이것에 의해 인증사이트(350)는, 신용승인결과 및 매매거래성립의 유무를 알 수 있다.

그후, 인증사이트(350)의 웨이브서버(351)에서 사용자(200)에의 콜레트 리다이렉트요구(인증)가 행해지고(30), 이것에 따라서 사용자(200)로부터 콜레트서버(510)에의 콜레트 리다이렉트(인증)가 행해진다(31). 그리고, 이것에 따라서 콜레트서버(510)에서 사용자(200)에 수주사이트 리다이렉트요구가 행해지고(32), 사용자(200)로부터 수주사이트(450)에의 리다이렉트가 행해진다(33).

그 결과, 쇼핑사이트(450)의 수주사이트(451)에서 수주등록 사업자사이트(360)의 수주기존시스템(361)에의 신용승인요구(34), 수주등록 사업자사이트(360)에 있어서의 수주기존시스템(361)과 쇼핑스위치 연휴서버(362)와의 사이에서 신용승인 결과요구(API)(35), 신용승인 결과응답(API)(36), 신용승인요구(API)(40)가 각각 행해지고, 신용승인요구(API)를 받은 쇼핑스위치 연휴서버(452)와 수주관리서버(520)와의 사이에서의 신용승인요구(41)와 신용승인응답(42)이 각각 행해진다. 그리고, 신용승인응답을 받은 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)는 수주기존시스템(361)에 신용승인응답(API)을 송신하고, 수주기존시스템(361)은 쇼핑사이트(450)의 수주서버(451)에 신용승인응답을 송신하고, 수주사이트(451)는 사용자(200)에게 완료 완료화면을 제공한다(45).

이와 같은 일련의 처리에 의해, 쇼핑사이트(450)에서는 회원등록을 하지 않은 사용자(200)라도, 인증사이트(350)에서 회원등록을 하고 있으면, 쇼핑사이트(450)에서의 온라인쇼핑이 가능하게 된다.

③. 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 동일한 경우의 사이트간 통신

먼저, 도 29에 나타내는 바와 같이, 실제의 시스템으로서는, 함께 몰사업자(300)나 온라인숍(400)인 쇼핑사이트(제 1사이트, 판매사이트)(450)와 인증사이트(제 2사이트)(350)에는, 각각에 본래의 기능을 가지게 하기 위한 수주사이트(451)와 웨이브서버(351)가 설치될 뿐만 아니라, 각각 머니게이트(500)와 연휴하는 쇼핑스위치 연휴서버(452, 352)가 설치되어 있다. 또, 쇼핑사이트(450)에, 쇼핑스위치 접수서버(453)도 설치되어 있다. 이 쇼핑스위치 접수서버(453)는, 사용자(200)로부터의 발주처가 되는 서버이고, 쇼핑사이트(450)는, 그 쇼핑스위치 접수서버(453)를 설치하는 것으로, 머니게이트(500)의 시스템에 짜 넣어진 경우라도, 기존의 수주사이트(451)에서의 수주처리에 대한 영향을 최소한으로 멈추는 것이 가능하게 된다. 그리고, 이들의 각 양태에 있어서, 도 7에 예시한 몰사업자(300a)에 상당하는 시스템(300a)이 연휴하고 있다.

이하, 사이트간 통신에 대해서 상세히 기술한다.

전제로서, 사용자(200)가 인터넷인 통신네트워크(700)를 거쳐서 쇼핑사이트(450)의 수주사이트(451)에 액세스하는데는, 그 사용자(200)가 회원등록을 하고 있는 인증사이트(350)를 특정하는 정보가 필요하게 된다. 그래서, 이와 같은 인증사이트(350)를 특정하는 정보를 입력하여 쇼핑사이트(450)의 수주사이트(451)에 액세스하고 있는 사용자(200)로부터 주문서요구가 송신되면(1), 수주사이트(451)는 그 사용자(200)에 대하여 주문서를 송신한다(2). 그때의 전문내용은 도 31에 나타내는 바와 같다. 이것에 의해 사용자(200)에게 오더화면이 제공된다.

사용자(200)는, 그 오더화면에서 발주를 한다. 이때, 콜레트입력 등을 실행하면, 콜레트서버(510)에 인증사이트 정보요구가 나온다(3). 즉, 인증사이트(350)는, 그 사용자(200)가 회원등록을 하고 있는 사이트이지만, 그 사이트는 하나라고는 한하지 않기 때문에, 인증사이트(350)가 복수 있는 경우, 사용자(200)에게 선택의 여지가 부여되게 된다. 인증사이트 정보요구가 행해진 콜레트서버(510)는, 인증사이트 선택화면을 사용자(200)에게 제공하고(4), 사용자(200)에게 임의의 인증사이트(350)를 선택하는 기회를 부여한다.

그 인증사이트 선택화면에서 소망의 인증사이트(350)를 사용자(200)가 선택하면, 쇼핑스위치 접수서버(453)에 주문요구가 행해진다(5). 이 주문요구에는, 사용자(200)가 지정한 인증등록사업자 거래처코드가 포함되어 있다. 그러면, 쇼핑사이트(450)에서는 그 쇼핑스위치 연휴서버(452)에 주문등록요구가 발신되고(7), 그후, 쇼핑스위치 연휴서버(452)는, 머니게이트(500)의 수주관리서버(520)에 향하여 주문등록요구를 발신한다(8). 이상의 처리에 있어서의 전문내용은, 도 31에 나타내는 바와 같다.

그후에 이어지는 처리로서는, 주문관리서버(520)에서 쇼핑스위치 연휴서버(452)에의 주문등록응답(9), 쇼핑스위치 연휴서버(452)에서 수주사이트(451)에의 주문등록응답이 행해지고(10), 수주사이트(451)에서 사용자(200)에게 콜레트 리다이얼요구(수주)가 행해진다(17). 이 콜레트 리다이얼요구(수주)에는, 머니게이트 ID가 포함되어 있지만, 이 머니게이트 ID는, 거래단위로 콜레트서버(510)가 생성하는 ID이고, 이 시점에서는 머니게이트 ID에 의해 사용자(200)의 동일성이 식별되지는 않는다.

그래서, 사용자(200)가 콜레트 리다이얼(수주)을 하면, 그때의 전문은 콜레트서버(510)에 송신된다(18). 콜레트 리다이얼(수주)의 전문을 받은 콜레트서버(510)는, 인증사이트 리다이렉트요구를 사용자(200)에게 반송한다(19). 도 32에 나타내는 바와 같이, 이 인증사이트 리다이렉트요구에는, 상술한 (5)의 처리에서 사용자(200)가 지정한 인증등록사업자의 URL이 포함되어 있다. 그리고, 이 인증등록사업자 URL을 이용하고, 사용자(200)로부터, 대응하는 URL을 가지는 인증등록 사업자인 인증사이트(350)의 웨이브서버(351)에 로그 온요구가 행해진다(20). 이것을 받은 인증사이트(350)의 웨이브서버(351)는, 그 사용자(200)에 로그 온화면을 제공한다(21).

로그 온화면의 제공을 받은 사용자(200)는, 로그 온화면 중에 인증사용자 ID나 크레디트 카드번호 등의 자기동일성을 식별할 수 있는 정보를 입력한 위에서, 인증사이트(350)의 웨이브서버(351)에 대하여 로그 온요구를 하고(22), 이것에 의 해, 그 웨이브서버(351)에서의 인증이 실행된다. 즉, 여기서 처음으로, 그 사용자의 비밀성이 높은 정보인 인증 ID나 크레디트 카드번호 등의 정보가 온라인 송신되게 되는 것이다. 더욱이 상술한 바와 같이, 인증사이트(350)에 있어서의 웨이브서버(351)에 있어서, 인증 ID 등을 키로서 그 사용자(200)의 크레디트 카드번호를 검색 가능하면, 로그 온요구시에 크레디트 카드번호의 송신이 불필요하고, 한층 안전성이 도모된다.

이렇게 하여, 인증처리를 실행한 웨이브서버(351)는, 인증사이트(350)의 쇼핑스위치 연휴서버(352)에 인증결과통지를 행하고(23), 이것에 따라서 인증사이트(350)의 쇼핑스위치 연휴서버(352)는 수주관리서버(520)에 인증결과통지를 행한다(24).

이후, 주문관리서버(520)는, 몰사업자(300a)의 시스템(e-SCOTT)에 대하여 신용승인요구를 송신한다(25). 이것에 따라서, 몰사업자(300a)는, 사용자(200)마다 결정되는 크레디트카드의 카드회사(600)에 신용승인요구를 행하고, 카드회사(600)에서 그 결과인 신용승인결과를 수신한다. 그리고, 그 신용승인결과를 수주관리서버(520)에 회신한다(25).

몰사업자(300a)의 시스템(e-SCOTT)에서 크레디트카드의 신용승인결과를 받은 수주관리서버(520)는, 쇼핑사이트(450)에 설치된 쇼핑스위치 연휴서버(452)에 대하여 신용승인결과를 포함하는 인증결과보고를 행한다(26). 이것에 의해 쇼핑스위치 연휴서버(452)는, 신용승인되었는지 어떤지를 알 수 있다. 그래서, 신용승인결과를 포함하는 인증결과보고를 받은 쇼핑사이트(450)의 쇼핑스위치 연휴서버(362)는, 수주관리서버(520)에 신용승인결과에 따른 결과에 대한 결과코드를 포함하는 인증결과보고를 송신하고(27), 매매거래성립의 유무를 수주관리서버(520)에 연락한다. 이것에 따라서, 수주관리서버(520)는, 인증사이트의 쇼핑스위치 연휴서버(352)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(28)을 하고, 그 쇼핑스위치 연휴서버(352)는 인증사이트(350)의 웨이브서버(351)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(29)을 행한다. 이것에 의해 인증사이트(350)는, 신용승인결과 및 매매거래성립의 유무를 알 수 있다.

그후, 인증사이트(350)의 웨이브서버(351)에서 사용자(200)에의 콜레트 리다이렉트요구(인증)가 행해지고(30), 이것에 따라서 사용자(200)에서 콜레트서버(510)에의 콜레트 리다이렉트(인증)가 행해진다(31). 그리고, 이것에 따라서 콜레트서버(510)에서 사용자(200)에 수주사이트 리다이렉트요구가 행해지고(32), 사용자(200)로부터 쇼핑스위치 접수서버(453)에의 리다이렉트가 행해진다(33).

그 결과, 쇼핑사이트(450)에 있어서, 쇼핑스위치 접수서버(453)와 쇼핑스위치 연휴서버(452)와의 사이에서의 신용승인요구(API)(35), 신용승인 결과응답(API)(36)이 각각 행해지고, 신용승인 결과응답(API)을 받은 쇼핑스위치 접수서버(453)는, 사용자(200)에 대하여 기존 CGI 리다이렉트요구를 행하고(37), 이것을 받은 사용자(200)는 수주사이트(451)에 기존 CGI 리다이렉트를 행한다(38). 이것에 따라서 수주사이트(451)는, 쇼핑사이트(450)의 쇼핑스위치 연휴서버(452)에 향하여 신용승인요구(API)를 행하고(40), 신용승인요구(API)를 받은 쇼핑스위치 연휴서버(452)와 수주관리서버(520)와의 사이에서의 신용승인요구(41)와 신용승인응답(42)이 각각 행해진다. 그리고, 신용승인응답을 받은 쇼핑사이트(450)의 쇼핑스위치 연휴서버(452)는 수주사이트(451)에 신용승인응답(API)을 송신하고, 수주사이트(451)는 사용자(200)에게 완료화면을 제공한다(45).

이와 같은 일련의 처리에 의해, 쇼핑사이트(450)에서는 회원등록을 하지 않은 사용자(200)라도, 인증사이트(350)에서 회원등록을 하고 있으면, 쇼핑사이트(450)에서의 온라인쇼핑이 가능하게 된다.

또, 비교대상이 되는 도 27의 처리에 비해, 쇼핑스위치 접수서버(453)를 설치하는 것으로, 이 쇼핑스위치 접수서버(453)가 (7), (10), (35) 및 (36)의 처리를 실행하기 때문에, 이 점에서 수주사이트(451)의 부담이 경감된다. 또한, 머니게이트(500)의 시스템에 짜 넣어진 경우라도, 기존의 수주사이트(451)에서의 수주처리에 대한 영향을 최소한으로 멈추는 것이 가능하게 된다.

④. 쇼핑스위치 접수서비스 이용형태에 있어서 등록사업자 사이트와 판매사이트가 다를 경우의 사이트간 통신

먼저, 도 30에 나타내는 바와 같이, 실제의 시스템으로서는, 몰사업자(300)나 온라인숍(400)인 쇼핑사이트(제 1사이트, 판매사이트)(450)외에, 수주등록 사업자사이트(360)(제 1사이트)와 인증사이트(제 2사이트)(350)가 설치되어 있다. 수주등록 사업자사이트(360)는, 쇼핑사이트(450)인 수주사이트(451)에 대해서, 이 수주사이트(451)를 관리하는 온라인숍 관리수단으로서 기능한다. 그리고, 그들의 수주등록 사업자사이트(360)와 인증사이트(350)에는, 각각에 본래의 기능을 가지게 하기 위한 수주기존 시스템사이트(361)와 웨이브서버(351)가 설치될 뿐만 아니라, 각각, 머니게이트(500)와 연휴하는 쇼핑스위치 연휴서버(362, 352)가 설치되어 있다. 그리고, 이들의 각 양태에 있어서, 도 7에 예시한 몰사업자(300a)에 상당하는 시스템(300a)이 연휴하고 있다.

이하, 사이트간 통신에 대해서 상세히 기술한다.

전제로서, 사용자(200)가 인터넷인 통신네트워크(700)를 거쳐서 쇼핑사이트(450)의 수주사이트(451)에 액세스하는 데는, 그 사용자(200)가 회원등록을 하고 있는 인증사이트(350)를 특정하는 정보가 필요하게 된다. 그래서, 이와 같은 인증사이트(350)를 특정하는 정보를 입력하여 쇼핑사이트(450)의 수주사이트(451)에 액세스하고 있는 사용자(200)로부터 주문서요구가 송신되면(1), 수주사이트(451)는 그 서버(200)에 대하여 주문서를 송신한다(2). 그때의 전문내용은 도 31에 나타내는 바와 같다. 이것에 의해 사용자(200)에게 오더화면이 제공된다.

사용자(200)는, 그 오더화면에서 발주를 한다. 이때, 콜레트입력 등을 실행하면, 콜레트서버(510)에 인증사이트 정보요구가 나온다(3). 즉, 인증사이트(350)는, 그 사용자(200)가 회원등록을 하고 있는 사이트이지만, 그 사이트는 하나라고는 한하지 않기 때문에, 인증사이트(350)가 복수 있는 경우, 사용자(200)에게 선택의 여지가 부여되게 되는 것이다. 인증사이트 정보요구가 행해진 콜레트서버(510)는, 인증사이트 선택화면을 사용자(200)에게 제공하고(4), 사용 자(200)에게 임의의 인증사이트(350)를 선택하는 기회를 부여한다.

그 인증사이트 선택화면에서 소망의 인증사이트(350)를 사용자(200)가 선택하면, 수주사이트(451)에 주문요구가 행해진다(5). 이 주문요구에는, 사용자(200)가 지정한 인증등록사업자 거래처코드가 포함되어 있다. 그러면, 수주사이트(451)는 수주등록 사업자사이트(360)의 수주기존시스템(361)에 대하여 수주요구를 행하고(6), 그러면, 그 수주기존시스템(361)은 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)에 주문등록요구를 발신한다(7). 그후, 쇼핑스위치 연휴서버(362)는, 머니게이트(500)의 수주관리서버(520)에 향하여 주문등록요구를 발신한다(8). 이상의 처리에 있어서의 전문내용은, 도 31에 나타내는 바와 같다.

그후에 이어지는 처리로서는, 주문관리서버(520)에서 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)에의 주문등록응답(9), 쇼핑스위치 연휴서버(362)에서 수주기존시스템(361)에의 주문등록응답이 행해지고(10), 수주기존시스템(361)에서 쇼핑사이트(450)의 수주사이트(451)에의 수주응답을 거쳐서(11), 사용자(200)에게 오더수신 보고화면이 제공된다(12). 그리고, 그 직후에, 수주등록 사업자사이트(360)의 수주기존시스템(361)에서 사용자(200)에게 확인메일이 송신된다(13). 그래서 사용자(200)는 확인메일을 확인한 후, 수주기존시스템(361)에 수주확인서요구를 발신하고(14), 이것을 받은 수주기존시스템(361)은 사용자(200)에게 수주확인화면을 제공한다(15). 이것을 확인한 사용자(200)는 수주기존시스템(361)에 주문확인요구를 송신하고(16), 이것에 따라서 수주기존시스템(361)에서 사용자(200)에 콜레트 리다이얼요구(수주)가 행해진다(17). 이 콜레트 리다이얼요구(수주)에는, 머니게이트 ID가 포함되어 있지만, 이 머니게이트 ID는, 거래단위로 콜레트서버(510)가 생성하는 ID이고, 이 시점에서는 머니게이트 ID에 의해 사용자(200)의 동일성이 식별되지는 않는다.

그래서, 사용자(200)가 콜레트 리다이얼(수주)을 하면, 그때의 전문은 콜레트서버(510)에 송신된다(18). 콜레트 리다이얼(수주)의 전문을 받은 콜레트서버(510)는, 인증사이트 리다이렉트요구를 사용자(200)에게 반송한다(19). 도 32에 나타내는 바와 같이, 이 인증사이트 리다이렉트요구에는, 상술한 (5)의 처리에서 사용자(200)가 지정한 인증등록사업자의 URL이 포함되어 있다. 그래서, 이 인증등록사업자 URL을 이용하여, 사용자(200)로부터 대응하는 URL을 가지는 인증등록 사업자인 인증사이트(350)의 웨이브서버(351)에 로그 온요구가 행해진다(20). 이것을 받은 인증사이트(350)의 웨이브서버(351)는, 그 사용자(200)에게 로그 온화면을 제공한다(21).

로그 온화면의 제공을 받은 사용자(200)는, 로그 온화면 중에 인증사용자 ID나 크레디트 카드번호 등의 자기동일성을 식별할 수 있는 정보를 입력한 위에서, 인증사이트(350)의 웨이브서버(351)에 대하여 로그 온요구를 하고(22), 이것에 의해, 그 웨이브서버(351)에서의 인증이 실행된다. 즉, 여기서 처음으로, 그 사용자의 비밀성이 높은 정보인 인증 ID나 크레디트 카드번호 등의 정보가 온라인 송신되는 것이다, 상술한 바와 같이, 인증사이트(350)에 있어서의 웨이브서버(351)에 있어서, 인증 ID 등을 키로서 그 사용자(200)의 크레디트 카드번호를 검색 가능 하면, 로그 온요구시에 크레디트 카드번호의 송신이 불필요하고, 한층 안전성이 도모된다.

이렇게 하여, 인증처리를 실행한 웨이브서버(351)는, 인증사이트(350)의 쇼핑스위치 연휴서버(352)에 인증결과통지를 행하고(23), 이것에 따라서 인증사이트(350)의 쇼핑스위치 연휴서버(352)는 수주관리서버(520)에 인증결과통지를 행한다(24).

이후, 주문관리서버(520)는, 몰사업자(300a)의 시스템(e-SCOTT)에 대하여 신용승인요구를 송신한다(25). 이것에 따라서, 몰사업자(300a)는, 사용자(200)마다 결정되는 크레디트카드의 카드회사(600)에 신용승인요구를 행하고, 카드회사(600)에서 그 결과인 신용승인결과를 수신한다. 그리고, 그 신용승인결과를 수주관리서버(520)에 회신한다(25).

몰사업자(300a)의 시스템(e-SCOTT)에서 크레디트카드의 신용승인결과를 받은 수주관리서버(520)는, 수주등록 사업자사이트(360)에 설치된 쇼핑스위치 연휴서버(362)에 대하여 신용승인결과를 포함하는 인증결과보고를 행한다(26). 이것에 의해 쇼핑스위치 연휴서버(362)는, 신용승인되었는지 어떤지를 알 수 있다. 그래서, 신용승인결과를 포함하는 인증결과보고를 받은 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)는, 수주관리서버(520)에 신용승인결과에 따른 결과에 대한 결과코드를 포함하는 인증결과보고를 송신하고(27), 매매거래성립의 유무를 수주관리서버(520)에 연락한다. 이것에 따라서, 수주관리서버(520)는, 인증사이트의 쇼핑스위치 연휴서버(352)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(28)을 하고, 그 쇼핑스위치 연휴서버(352)는 인증사이트(350)의 웨이브서버(351)에 신용승인결과 및 결과코드를 포함하는 인증결과 통지응답(29)을 행한다. 이것에 의해 인증사이트(350)는, 신용승인결과 및 매매거래성립의 유무를 알 수 있다.

그후, 인증사이트(350)의 웨이브서버(351)에서 사용자(200)에의 콜레트 리다이렉트요구(인증)가 행해지고(30), 이것에 따라서 사용자(200)로부터 콜레트서버(510)에의 콜레트 리다이렉트(인증)가 행해진다(31). 그리고, 이것에 따라서 콜레트서버(510)에서 사용자(200)에 수주사이트 리다이렉트요구가 행해지고(32), 사용자(200)로부터 수주등록 사업자사이트(360)의 수주기존시스템(361)에의 리다이렉트가 행해진다(33).

그 결과, 수주등록 사업자사이트(360)의 수주기존시스템(361)과 쇼핑스위치 연휴서버(362)와의 사이에서의 신용승인 결과요구(API)(35), 신용승인 결과응답(API)(36), 신용승인요구(API)(40)가 각각 행해지고, 신용승인요구(API)를 받은 쇼핑스위치 연휴서버(362)와 수주관리서버(520)와의 사이에서의 신용승인요구(41)와 신용승인응답(42)이 각각 행해진다. 그리고, 신용승인응답을 받은 수주등록 사업자사이트(360)의 쇼핑스위치 연휴서버(362)는 수주기존시스템(361)에 신용승인응답(API)을 송신하고, 수주기존시스템(361)은 쇼핑사이트(450)의 수주서버(451)에 신용승인응답을 송신하고, 수주사이트(451)는 사용자(200)에게 완료화면을 제공한다(45).

이와 같은 일련의 처리에 의해, 쇼핑사이트(450)에서는 회원등록을 하지 않 은 사용자(200)라도, 인증사이트(350)에서 회원등록을 하고 있으면, 쇼핑사이트(450)에서의 온라인쇼핑이 가능하게 된다.

또, 비교대상이 되는 도 28의 처리에 비하여, 수주등록 사업자사이트(360)에 있어서의 수주기존시스템(361)과 사용자(200)와의 사이에서 데이터의 송수신처리가 증가하고 있다(예를 들면 (13)∼(16) 및 (33) 등). 이것은, 머니게이트(500)의 시스템에 짜 넣어지기 이전부터, 수주등록 사업자사이트(360)에 있어서의 수주기존시스템(361)이 통산처리로서 실행하고 있던 처리이고, 그 의미로, 머니게이트(500)의 시스템에 짜 넣어진 경우라도, 기존의 수주등록 사업자사이트(360)에 있어서의 수주기존시스템(361)에서의 수주처리에 대한 영향을 최소한으로 멈추는 것이 가능하게 된다.

(4) 결론

이와 같이, 본 실시의 형태의 온라인 쇼핑시스템에 있어서는, 어느 회원제의 몰 및 숍의 회원으로 되어 있는 사용자는, 자신이 등록하지 않은 다른 몰 및 쇼핑에서도, 어느 새로운 등록처리 등을 행할 필요가 없이 상품을 구입할 수 있다. 따라서, 사용자가 회원등록하여야 할 몰이나 숍의 수의 증가를 억제할 수 있고, 사용자가 관리하여야 할 ID나 패스워드가 증가하지 않고 결제에 관계되는 비밀정보의 누설의 위험성을 적게할 수 있다. 또 그때의 처리는, 스스로 등록하고 있는 몰이나 숍에서 쇼핑을 행하는 것과 동등의 용이한 처리로 좋다. 따라서, 사용자의 편리성이 현저하게 향상한다. 그 결과, 온라인 쇼핑시스템의 환경이 향상하고, 온라인 쇼핑시스템의 이용자의 증가나, 보다 활발한 거래를 기대할 수 있다.

또, 사용자가 회원등록을 하고 있지 않은 몰사업자, 온라인숍 등에 대해서는, 본래의 사용자 ID, 패스워드, 크레디트 카드번호라는 실제로 그 사용자를 특정하여 인증할 수 있는 정보를 건네주지 않고, 사용자 ID나 크레디트 카드번호에 대해서는 더미의 것을 건네주고 있으므로, 이면에서도 결제에 관계되는 비밀정보의 누설의 위험성을 적게할 수 있다.

또, 각 몰사업자에 있어서는, 등록회원에 대해서, 그 등록 ID를 여러가지 몰 및 숍에서 쇼핑을 할 수 있다는 회원에의 부가가치를 제공할 수 있고, 보다 회원을 널리 모집할 수 있다.

또 자신의 회원이 다른 몰에서 쇼핑을 행하였을 경우에는 수수료를 얻을 수 있으므로, 고객소개료라는 새로운 수수료수입이 기대된다.

또한, 각 숍에 있어서도, 자신이 숍을 개설하고 있는 몰의 회원 이외에서도 널리 사용자가 쇼핑에 오므로, 매출고의 증가를 기대할 수 있다.

또한, 본 발명은 본 실시의 형태에 한하는 것은 아니고, 여러가지의 개변이 가능하다.

예를 들면, 상술한 각 처리에 있어서의, 자신이 등록하고 있는 몰 및 숍 이외의 다른 몰이나 숍의 사이트에의 들어가는 방법, 거기서의 쇼핑의 형태, 거기서의 수주의 방법, 수주확인의 방법, 수주데이터의 관리방법, 신용승인방법, 수순 및 타이밍, 출하방법, 매출데이터의 집계방법, 이익분배율 및 이익분배방법 등은, 임의 적절한 여러가지의 방법으로 행하여도 좋다.

또, 숍에서의 수주정보와, 사용자가 등록하고 있는 몰사업자의 크레디트번호 등의 정보와의 대응은, 상술한 실시의 형태에서는 수주번호에 의해 행해지는 것으로 하였다. 그러나 이것은, IP어드레스에 의해 행하여도 좋고, Cookie의 기능을 이용하여 행하도록 하여도 좋다.

또, 온라인 쇼핑시스템(100)이 구성되는 네트워크는 인터넷에 한하는 것은 아니고, 임의의 네트워크시스템으로 좋다.

또한, 상술의 각 실시의 형태에서는 몰사업자가 온라인숍의 관리를 하는 구성을 채용하고 있었지만, 사용자가 회원등록을 하여 결제에 필요한 데이터를 건네고 있으면, 몰사업자 대신 온라인숍을 관리하지 않는 인터넷·서비스·프로바이더(ISP)가 온라인숍의 관리를 하는 구성이라도 좋다.

더하여, 결제의 수법으로서는, 크레디트카드에 의한 크레디트결제에 한하지 않고, 전자머니, J-Debit, e-Wallet 등과 같은, 예를 들면 각종의 전자결제에 익숙한 각종의 결제수법을 채용할 수 있다. 이 경우, 결제에 필요한 정보는, 그들의 전자결제에 필요한 정보라는 것으로 된다.

이와 같이, 본 발명에 의하면, 복수의 시스템에서 상거래를 행할 경우에 있어서도 수속이 용이하고 관리하여야 할 ID나 패스워드가 늘지 않고 결제에 관계되는 비밀정보의 누설의 위험성이 적게되는 결제시스템을 실현하는 결제중개 처리장치를 제공할 수 있다.

또, 자신이 등록하고 있는 온라인숍이나 몰 이외의 숍이나 몰에서도, 간단한 수속으로 이용할 수 있고, 관리하여야 할 ID나 패스워드가 늘지 않고 결제에 관계 되는 비밀정보의 누설의 위험성도 적게되는 온라인 쇼핑시스템을 제공하기 위한 온라인숍장치를 제공할 수 있다.

또한, 그와 같은 온라인쇼핑방법 및 온라인시스템을 제공할 수 있다.

Claims (85)

1. 결재중개 처리장치에 있어서,

   네트워크를 거쳐서 접속된 사용자로부터 보내져온 수주정보와 관련한 요청에 따라 대가의 지불을 수반하는 상품의 판매를 실행하도록 구성된 상기 수주정보를 수신하는 수주정보수신부와,

   상기 사용자가 돈의 지불과 관련한 계약을 가지는 제 2장치로부터 수신된 수주정보에 근거하여 상기 사용자에 의해 요청된 수행의 대가의 상기 사용자로부터의 지불을 수신하는데 필요한 지불정보를 취득하는 지불정보 취득부와,

   수신된 수주정보와 취득된 지불정보에 근거하여 사용자에 의해 요청된 수행의 대가의 결재를 수행하는 결재처리부와,

   다른 상품판매부에 등록된 사용자가 상품판매부에 액세스 할 때 사용되는 각각의 다른 상품판매부에 대한 임시 사용자정보를, 복수의 상품판매부에 대해 저장하고, 요청에 의해 임시 사용자정보 중 하나를 제공하는 것에 의해, 사용자가 등록된 상품판매부가 아닌 상응하는 상품판매부에 액세스가 가능한 액세스 정보제공부와,

   상기 결재가 수행된 상품의 대가에 근거하여 상기 제 2장치와 상기 결재중개 처리장치에 지불 중개를 포함하는 지불 중개의 처리를 수행하는 중개 지불처리부를 포함하고,

   상기 수주정보 수신부는 상기 네트워크를 통해 상품의 판매를 수행하는 제 1장치로부터 상품에 대한 주문과 관련한 수주정보를 수신하고,

   상기 지불정보 취득부는 수신된 수주정보로에 근거하여 상기 제 2장치로부터 사용자에 의해 주문된 상품의 대가의 지불을, 상기 사용자로부터, 수신하기 위해 필요한 지불정보를 취득하고,

   상기 결재처리부는 수신된 수주정보와 취득된 지불정보에 근거하여 상기 사용자에 의해 구입된 상품의 대가의 결재를 수행하며,

   상기 제 1장치 및 제 2장치의 각각은 사용자가 돈의 지불과 관련한 계약을 포함하는 등록을 하고 네트워크를 통해 상기 제 1장치 및 제 2장치에 액세스하기 위한 등록된 사용자를 허용하고 액세스된 경우 상품을 판매하는 많은 상품판매부 중 하나이고,

   상기 수주정보 수신부는, 상기 많은 상품판매부 중 하나로부터, 하나의 상품판매부가 아닌 적어도 상품판매부에 등록된 상기 사용자로부터 상품에 대한 주문과 관련한 수주정보를 수신하고,

   상기 지불정보 취득부는 수신된 수주정보에 근거하여 상기 사용자가 등록된 상품판매부로부터 상기 사용자에 의해 주문된 상품의 대가의 지불을, 상기 사용자로부터, 수신하는데 필요한 지불정보를 취득하는 것을 특징으로 하는 결제중개 처리장치.
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 제 1항에 있어서,

   상기 액세스 정보제공부는 각각의 다른 상품판매부에 저장된 사용자에 의해 사용되는 각각의 다른 상품판매부에 대한 정보, 임시 사용자 ID를 포함하는 정보 및 임시 지불정보를, 각각의 상품판매부 수에 대해 저장하고 제공하는 것을 특징으로 하는 결제중개 처리장치.
8. 삭제
9. 삭제
10. 제 1항에 있어서,

    상기 임시 사용자 정보는, 크레디트 번호인 것을 특징으로 하는 결제중개 처리장치.
11. 삭제
12. 제 1항에 있어서,

    상기 제 1장치로 지불방법의 선택에 대한 입력을 허용하는 지불방법 선택화면을 제공하는 지불방법 입력표시수단과,

    이 지불방법 입력표시수단에 의해서 상기 결제중개 처리부에 의한 결제가 선택입력 된 경우에만 상기 수주정보 수신부, 상기 지불정보 취득부 및 상기 결제처리부의 기능을 실행시키는 결제중개 실행부를 더 포함하여 구성된 것을 특징으로 하는 결제중개 처리장치.
13. 제 1항에 있어서,

    상기 네트워크를 거쳐서 액세스하는 상기 사용자의 장치에 대해서, 상기 결제처리부가 결제처리를 수행할 수 있는 상품판매부의 수의 리스트를 선택가능으로 표시시키는 리스트 표시수단과,

    선택된 상품판매부에 상기 사용자의 장치를 액세스시키는 자동 액세스부를 더 포함하여 구성된 것을 특징으로 하는 결제중개 처리장치.
14. 제 1항에 있어서,

    상기 결제처리부가 결제 처리를 수행할 수 있는 상품판매부의 수에 의해 판매된 각각의 상품에 1 또는 2 이상의 검사 키워드를 대응시켜 검사 키워드를 기억하는 검사 키워드 기억부와,

    상기 네트워크를 통해 액세스하는 상기 사용자의 장치에 검사 키워드 입력용의 다이얼로그 박스를 표시시키는 검사 키워드 입력부와,

    상기 검사 키워드 입력부에 의해서 입력된 검사 키워드에 근거하여 상기 검사 키워드 기억부로부터 대응하는 상품 판매부를 검사하고, 검사된 상기 상품판매부에 상기 사용자의 장치를 액세스 가능으로 시키는 제 2자동 액세스부를 더 포함하여 구성된 것을 특징으로 하는 결제중개 처리장치.
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제
51. 삭제
52. 삭제
53. 삭제
54. 삭제
55. 삭제
56. 삭제
57. 삭제
58. 삭제
59. 삭제
60. 삭제
61. 삭제
62. 삭제
63. 삭제
64. 삭제
65. 삭제
66. 삭제
67. 삭제
68. 삭제
69. 삭제
70. 삭제
71. 삭제
72. 삭제
73. 삭제
74. 삭제
75. 삭제
76. 삭제
77. 삭제
78. 삭제
79. 삭제
80. 삭제
81. 삭제
82. 삭제
83. 삭제
84. 삭제
85. 삭제

Images