KR20220047876A

KR20220047876A - 상품 거래 시스템, 상품 거래 방법 및 상품 거래 프로그램

Info

Publication number: KR20220047876A
Application number: KR1020227009965A
Authority: KR
Inventors: 크리스토퍼 앤드류 테이트
Original assignee: 네라이 가부시키가이샤; 커넥트프리 가부시키가이샤; 크리스토퍼 앤드류 테이트
Priority date: 2019-08-30
Filing date: 2020-08-28
Publication date: 2022-04-19
Also published as: IL290928A; EP4024315A1; JP7004882B2; US20220292561A1; EP4024315A4; MX2022002520A; JP2021039392A; TW202115650A; CN114641789A; WO2021040000A1

Abstract

생산자와 구매자 사이에서 직접적인 상품의 거래도 가능하게 하는 플랫폼을 제공한다. 구매자와 공급자 사이의 상품 거래를 실행하기 위한 상품 거래 시스템이 제공된다. 상품 거래 시스템은, 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 제1 접수 수단과, 공급자로부터 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 제2 접수 수단과, 공급자로부터 구매자까지의 특정 상품을 배송하기 위한 배송비를 반영한 후에, 구입 요구와 판매 요구가 매칭하는지 아닌지를 판단하는 판단 수단을 포함한다.

Description

상품 거래 시스템, 상품 거래 방법 및 상품 거래 프로그램

본 개시는, 구매자와 공급자 사이의 상품 거래를 실행하기 위한 상품 거래 시스템, 상품 거래 방법 및 상품 거래 프로그램에 관한 것이다.

종래의 유통 시스템에서는, 생산자로부터 소매를 통하여 구매자에게 상품이 보내진다. 이러한 유통 시스템에 대하여, 예를 들면, 일본공개특허공보 2019-128814호(특허문헌 1)는, 마켓을 활성화할 수 있는 전자 매매 시스템을 개시한다.

특허문헌 1: 일본공개특허공보 2019-128814호

전술한 특허문헌 1에 개시되는 전자 매매 시스템은, 구입자와 판매자 사이의 상품 매매를 지원하는 것이지만, 예를 들면, 공업제품을 제조하는 생산자와 그 공업제품의 구매자와의 직접적인 거래를 실현하는 바와 같은 것은 아니다.

본 개시는, 생산자와 구매자 사이에서 직접적인 상품의 거래도 가능하게 하는 플랫폼을 제공하는 것을 목적으로 한다.

본 개시의 어느 형태에 의하면, 구매자와 공급자 사이의 상품 거래를 실행하기 위한 상품 거래 시스템이 제공된다. 상품 거래 시스템은, 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 제1 접수 수단과, 공급자로부터 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 제2 접수 수단과, 공급자로부터 구매자까지의 특정 상품을 배송하기 위한 배송비를 반영한 후에, 구입 요구와 판매 요구가 매칭하는지 아닌지를 판단하는 판단 수단을 포함한다.

상품 거래 시스템은, 1 또는 복수의 구입 요구, 및, 1 또는 복수의 판매 요구를 일시적으로 저장하기 위한 요구 큐를 추가로 포함하고 있어도 좋다. 판단 수단은, 구입 요구 또는 판매 요구가 요구 큐에 추가되었을 때, 또는, 요구 큐에 저장되어 있는 구입 요구 또는 판매 요구가 변경되었을 때에, 구입 요구와 판매 요구가 매칭하는지 아닌지를 판단하도록 하여도 좋다.

상품 거래 시스템은, 공급자 또는 특정 상품에 관련지어진 배송비 정의와, 구매자와 공급자 사이의 거리에 기초하여, 특정 상품을 배송하기 위한 배송비를 산출하는 산출 수단을 추가로 포함하고 있어도 좋다.

상품 거래 시스템은, 구매자 및 공급자의 각각이 보유하는 경제적 가치를 관리하는 계좌를 추가로 포함하고 있어도 좋다. 제1 접수 수단은, 구입 요구에 포함되는 구입 희망 가격에 기초하여 결정되는 가치를 대응하는 구매자의 계좌로부터 예약하도록 하여도 좋다.

상품 거래 시스템은, 매칭한 구입 요구와 판매 요구에 기초하는 상품 거래가 완료되면, 당해 구입 요구에 대응하는 구매자의 계좌로부터 이용료를 징수하는 수단을 추가로 포함하고 있어도 좋다.

본 개시의 다른 형태에 의하면, 구매자와 공급자 사이의 상품 거래를 컴퓨터가 실행하는 상품 거래 방법이 제공된다. 상품 거래 방법은, 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 스텝과, 공급자로부터 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 스텝과, 공급자로부터 구매자까지의 특정 상품을 배송하기 위한 배송비를 반영한 후에, 구입 요구와 판매 요구가 매칭하는지 아닌지를 판단하는 스텝을 포함한다.

본 개시의 추가로 다른 형태에 의하면, 컴퓨터에 구매자와 공급자 사이의 상품 거래를 실행시키기 위한 상품 거래 프로그램이 제공된다. 상품 거래 프로그램은, 컴퓨터에, 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 스텝과, 공급자로부터 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 스텝과, 공급자로부터 구매자까지의 특정 상품을 배송하기 위한 배송비를 반영한 후에, 구입 요구와 상기 판매 요구가 매칭하는지 아닌지를 판단하는 스텝을 실행시킨다.

본 개시에 의하면, 생산자와 구매자 사이에서 직접적인 상품의 거래도 가능하게 하는 플랫폼을 실현할 수 있다.

도 1은 본 실시 형태에 따른 상품 거래 시스템에 있어서의 처리의 개요를 설명하기 위한 도면이다.
도 2는 본 실시 형태에 따른 상품 거래 시스템에 있어서의 처리 수순의 일례를 설명하기 위한 도면이다.
도 3은 본 실시 형태에 따른 상품 거래 시스템을 구성하는 운영 서버의 구성 예를 나타내는 모식도이다.
도 4는 본 실시 형태에 따른 상품 거래 시스템에 있어서의 매칭 처리의 주요부를 나타내는 모식도이다.
도 5는 본 실시 형태에 따른 상품 거래 시스템을 구성하는 구매자의 단말상에 제공되는 사용자 인터페이스 화면의 일례를 나타내는 모식도이다.
도 6은 본 실시 형태에 따른 상품 거래 시스템을 구성하는 공급자의 단말상에 제공되는 사용자 인터페이스 화면의 일례를 나타내는 모식도이다.
도 7은 본 실시 형태에 따른 상품 거래 시스템을 구성하는 구매자의 단말상에 제공되는 사용자 인터페이스 화면의 일례를 나타내는 모식도이다.
도 8은 본 실시 형태에 따른 상품 거래 시스템의 운영 서버에 의한 구매자에 관한 정보의 관리 방법을 설명하기 위한 도면이다.
도 9는 본 실시 형태에 따른 상품 거래 시스템의 운영 서버에 의한 공급자에 관한 정보의 관리 방법을 설명하기 위한 도면이다.
도 10은 본 실시 형태에 따른 상품 거래 시스템에 있어서 이용되는 배송비 정의의 일례를 나타내는 도면이다.
도 11은 본 실시 형태에 따른 상품 거래 시스템에 있어서 이용되는 배송비 정의의 다른 일례를 나타내는 도면이다.
도 12는 본 실시 형태에 따른 상품 거래 시스템의 운영 서버에 있어서의 처리 수순을 나타내는 플로우차트이다.
도 13은 본 실시 형태에 따른 상품 거래 시스템의 운영 서버에 있어서의 처리 수순을 나타내는 플로우차트이다.
도 14는 본 실시 형태에 따른 상품 거래 시스템을 구성하는 구매자의 단말상에 제공되는 사용자 인터페이스 화면의 다른 일례를 나타내는 모식도이다.
도 15는 본 실시 형태에 따른 상품 거래 시스템을 구성하는 공급자의 단말상에 제공되는 사용자 인터페이스 화면의 다른 일례를 나타내는 모식도이다.

(발명을 실시하기 위한 구체적인 내용)

본 개시에 따른 실시 형태에 대해서, 도면을 참조하면서 상세하게 설명한다. 또한, 도면 중의 동일 또는 상당 부분에 대해서는, 동일한 부호를 붙이고 그 설명은 반복하지 않는다.

<A. 상품 거래 시스템(1)>

우선, 본 실시 형태에 따른 상품 거래 시스템(1)에 대해서 설명한다. 상품 거래 시스템(1)은, 생산자와 구매자 사이에서 직접적인 상품 거래도 가능하게 하는 플랫폼을 제공한다.

도 1은, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서의 처리의 개요를 설명하기 위한 도면이다. 도 1을 참조하여, 상품 거래 시스템(1)은, 임의의 상품 구입을 희망하는 1 또는 복수의 구매자(10)와, 임의의 상품 제공을 희망하는 1 또는 복수의 공급자(20)의 어느 쪽으로부터도 액세스 가능한 운영 서버(100)를 포함한다. 즉, 상품 거래 시스템(1)은, 구매자(10)와 공급자(20) 사이의 상품 거래를 전자적으로 실행한다.

구매자(10)의 각각은, 구입을 희망하는 임의의 상품 및 수를 특정하기 위한 정보, 그리고, 그 구입 희망 가격을 포함하는 구입 요구(12)를 운영 서버(100)로 송신한다. 또한, 공급자(20)의 각각은, 판매를 희망하는 임의의 상품 및 수를 특정하기 위한 정보, 그리고, 그 판매 희망 가격을 포함하는 판매 요구(22)를 운영 서버(100)로 송신한다.

운영 서버(100)는, 1 또는 복수의 구매자(10)로부터의 구입 요구(12)와, 1 또는 복수의 공급자(20)로부터의 판매 요구(22)를 비교하여, 구입 요구(12)와 판매 요구(22)가 합치되는지 아닌지를 판단한다(이하, 「매칭 처리」라고도 칭함.). 그리고, 구입 요구(12)와 판매 요구(22)가 합치되면, 거래 성립이라고 결정한다.

운영 서버(100)는, 거래 성립이라고 결정된 판매 요구(22)에 대응하는 공급자(20)에 대하여, 거래 성립의 취지를 통지함과 함께, 거래의 대상이 된 상품을 구매자(10)에게 배송한다. 또한, 상품의 배송에 대해서는, 공급자(20) 자신이 실행하여도 좋지만, 전형적으로는, 임의의 배송자(30)가 실행하여도 좋다.

운영 서버(100)는, 후술하는 바와 같이, 구매자(10)와 공급자(20) 사이의 결제 처리도 담당한다.

상품 거래 시스템(1)에 있어서 취급되는 상품으로서는, 특별히 제한은 없지만, 일용품이나 소모품 등의 반복 구입이 상정되어 있는 것이 적합하다.

구매자(10)는, 전형적으로는, 대상의 상품을 최종적으로 사용하는 개인이 상정되지만, 이에 한정하지 않고, 예를 들면, 계속적으로 상품을 사용하는 것이 예정되는 점포나 사업소 등이라도 좋다. 또한, 구매자(10)는, 컴퓨터나 연산 기능을 구비한 디바이스라도 좋다. 이와 같이, 구매자(10)는, 상품의 거래에 관하여 어떠한 의사 결정이 가능한 임의의 주체를 포함하는 개념이다.

공급자(20)는, 임의의 상품을 제공 가능하면 어떤 주체라도 좋지만, 전형적으로는, 임의의 상품의 생산자 혹은 수입자가 적합하다. 혹은, 공급자(20)는, 임의의 상품을 보관 또는 관리하는 물류 회사라도 좋다. 또한, 공급자(20)는, 컴퓨터나 연산 기능을 구비한 디바이스라도 좋다. 이와 같이, 공급자(20)는, 구매자(10)와 마찬가지로, 상품의 거래에 관하여 어떠한 의사 결정이 가능한 임의의 주체를 포함하는 개념이다.

이와 같이, 본 실시 형태에 따른 상품 거래 시스템(1)은, 종래의 비지니스 모델에 있어서는 존재하지 않았던, 생산자와 구매자 사이에서 직접적인 상품의 거래도 가능하게 하는 플랫폼을 제공한다.

도 2는, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서의 처리 수순의 일례를 설명하기 위한 도면이다. 도 2에는, 구매자(10)가 특정 상품을 주문하고, 임의의 공급자(20)와의 사이에서 거래가 성립되어, 당해 공급자(20)로부터 상품이 제공되는 경우의 처리예를 나타낸다.

도 2를 참조하여, 구매자(10)는, 특정 상품을 주문하기 위한 조작을 실행하면, 구입 요구(12)가 운영 서버(100)로 송신된다(스텝 S1). 운영 서버(100)는, 구매자(10)로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구(12)를 접수한다. 그리고, 운영 서버(100)는, 당해 구매자(10)의 잔고로부터, 구매자(10)로부터의 구입 요구(12)에 포함되는 구입 희망 가격 및 구입 희망 개수에 기초하여 결정되는 구입 예정액을 리저브(예약)한다(스텝 S2).

한편, 공급자(20)는, 특정 상품을 판매하기 위한 조작을 실행하면, 판매 요구가 운영 서버(100)로 송신된다(스텝 S3). 운영 서버(100)는, 공급자(20)로부터 특정 상품의 판매 희망 가격을 포함하는 판매 요구(22)를 접수한다.

운영 서버(100)는, 구매자(10)로부터의 구입 요구(12)와 공급자(20)로부터의 판매 요구(22) 사이에서 매칭 처리를 실행한다(스텝 S4). 이 매칭 처리에 있어서, 어느 구매자(10)로부터의 구입 요구(12)와 어느 공급자(20)로부터의 판매 요구(22) 사이에서 거래가 성립되면, 운영 서버(100)는, 거래 성립의 통지를 구매자(10) 및 공급자(20)에게 각각 송신한다(스텝 S5).

공급자(20)는, 거래 성립의 통지를 받고, 거래의 대상이 된 상품을 발송한다(스텝 S6). 또한, 공급자(20)는, 거래의 대상이 된 상품의 발송에 수반하여, 당해 발송된 상품을 트래킹하기 위한 트래킹 정보를 운영 서버(100)를 통하여 구매자(10)에게 송신한다. 트래킹 정보를 구매자(10) 및 공급자(20) 그리고 운영 서버(100)에서 공유함으로써, 상품이 확실하게 배송되는 것을 보증할 수 있다.

구매자(10)는, 공급자(20)로부터의 상품을 받으면(스텝 S7), 상품 수취 통지를 운영 서버(100)로 송신한다(스텝 S8). 운영 서버(100)는, 구매자(10)로부터의 상품 수취 통지를 받으면, 미리 리저브하고 있었던 구입 예정액을 공급자(20)의 계좌로 입금한다(스텝 S9).

이상과 같은 처리 수순에 의해, 상품 거래 시스템(1)에 있어서의 상품의 거래가 완료된다.

이하, 본 실시 형태에 따른 상품 거래 시스템(1)의 구성, 기능 및 처리의 상세에 대해서 설명한다.

<B. 하드웨어 구성>

다음으로, 본 실시 형태에 따른 상품 거래 시스템(1)의 하드웨어 구성의 일례에 대해서 설명한다.

(b1: 운영 서버(100))

도 3은, 본 실시 형태에 따른 상품 거래 시스템(1)을 구성하는 운영 서버(100)의 구성예를 나타내는 모식도이다. 전형적으로는, 운영 서버(100)는, 1 또는 복수의 범용 컴퓨터를 사용하여 실현된다.

도 3을 참조하여, 운영 서버(100)는, 주된 컴포넌트로서, 1 또는 복수의 프로세서(101)와, 메인 메모리(102)와, 통신 인터페이스(103)와, 입력부(104)와, 디스플레이(105)와, 스토리지(110)를 포함한다. 이들의 컴포넌트는, 내부 버스(106)를 통하여 접속되어 있다.

프로세서(101)는, 예를 들면, CPU나 GPU(Graphics Processing Unit) 등으로 구성된다. 복수의 프로세서(101)가 배치되어도 좋고, 복수의 코어를 갖는 프로세서(101)를 채용하여도 좋다.

메인 메모리(102)는, DRAM(Dynamic Random Access Memory)이나 SRAM(Static Random Access Memory) 등의 휘발성 기억 장치로 구성된다. 스토리지(110)는, 하드 디스크나 SSD(Solid State Drive) 등의 비휘발성 기억 장치로 구성되고, 프로세서(101)에서 실행되는 각종 프로그램이나 각종 데이터를 저장한다. 스토리지(110)에 격납된 프로그램 중, 지정된 프로그램 코드가 메인 메모리(102)상에 전개되고, 프로세서(101)는 메인 메모리(102)상에 전개된 프로그램 코드에 포함되는 컴퓨터 가독 명령을 순차로 실행함으로써, 후술하는 바와 같은 각종 기능을 실현한다.

전형적으로는, 스토리지(110)는 매칭 처리를 실현하기 위한 매칭 프로그램(112)과, 결제 처리를 실현하기 위한 결제 프로그램(114)과, 요구 큐(116)와, 구매자(10) 및 공급자(20)에 관한 각종 정보를 포함하는 사용자 정보(118)를 격납하고 있다. 요구 큐(116)는 1 또는 복수의 구매자(10)로부터의 1 또는 복수의 구입 요구(12) 및, 1 또는 복수 공급자(20)로부터의 1 또는 복수의 판매 요구(22)를 일시적으로 저장한다.

매칭 프로그램(112) 및 결제 프로그램(114)은, 컴퓨터에 구매자(10)와 공급자(20) 사이의 상품 거래를 실행시키기 위한 상품 거래 프로그램에 상당한다.

통신 인터페이스(103)는, 구매자(10) 및 공급자(20)의 단말 등과 데이터 교환을 담당한다. 통신 인터페이스(103)는, 예를 들면, 인터넷을 통한 통신이 가능하도록, 이더넷(등록상표) 포트를 포함하고 있어도 좋다.

입력부(104)는, 임의의 입력지시를 접수한다. 디스플레이(105)는, 프로세서(101)에서의 처리 결과 등을 표시한다.

운영 서버(100)의 전부 또는 일부는, 컴퓨터 가독 명령에 상당하는 회로가 조입된 ASIC(Application Specific Integrated Circuit) 등의 하드 와이어드 회로를 사용하여 실현해도 좋다. 추가로 또한, FPGA(field-programmable gate array)상에 컴퓨터 가독 명령에 상당하는 회로를 사용하여 실현해도 좋다. 또한, 프로세서(101) 및 메인 메모리, ASIC, FPGA 등을 적절히 조합하여 실현해도 좋다.

운영 서버(100)는, 컴퓨터 가독 명령으로 이루어지는 매칭 프로그램(112) 및 결제 프로그램(114)을 격납하는 비일과성(non-transitory)의 미디어로부터, 당해 격납하고 있는 프로그램 등을 읽어내기 위한 컴포넌트를 추가로 갖고 있어도 좋다. 미디어는, 예를 들면, DVD(Digital Versatile Disc) 등의 광학 미디어, USB메모리 등의 반도체 미디어 등이어도 좋다.

매칭 프로그램(112) 및 결제 프로그램(114)은, 미디어를 통하여 운영 서버(100)에 인스톨될 뿐만 아니라, 네트워크상의 배신 서버로부터 제공되도록 하여도 좋다.

(b2: 구매자(10) 및 공급자(20)의 단말)

구매자(10) 및 공급자(20)는, 임의의 단말을 이용하여, 상품 거래 시스템(1)을 이용할 수 있다. 구매자(10) 및 공급자(20)가 이용하는 단말은, 퍼스널컴퓨터, 스마트폰, 태블릿, 휴대전화 등의 임의의 정보처리장치를 포함한다.

후술하는 바와 같은 구매자(10) 및 공급자(20)에게 제공되는 기능은, 단말에 미리 인스톨된 애플리케이션에 의해 실현되어도 좋고, 운영 서버(100)가 제공하는 사용자 인터페이스를 단말의 브라우저를 통하여 이용하도록 하여도 좋다.

구매자(10) 및 공급자(20)에게 제공되는 사용자 인터페이스를 포함시킨 각종 기능은, 어떠한 하드웨어 구성 및 소프트웨어 구성을 사용하여 실현해도 좋다.

<C. 매칭 처리>

다음으로, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서의 매칭 처리에 대해서 설명한다.

(c1: 구입 요구(12) 및 판매 요구(22))

본 실시 형태에 따른 상품 거래 시스템(1)에 있어서, 공급자(20)로부터 구매자(10)에게 상품을 배송하기 위해 필요한 배송비를 고려하여 매칭 처리를 실행하도록 하여도 좋다. 즉, 상품 거래 시스템(1)의 운영 서버(100)는, 공급자(20)로부터 구매자(10)까지의 특정 상품을 배송하기 위한 배송비를 반영한 후에, 구입 요구(12)와 판매 요구(22)가 매칭하는지 아닌지를 판단한다. 이 배송비의 고려에 있어서는, 구매자(10)와 공급자(20) 사이의 거리를 고려하여도 좋다.

도 4는, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서의 매칭 처리의 주요부를 나타내는 모식도이다.

도 4를 참조하여, 구매자(10)로부터의 구입 요구(12)는, 구입 희망 가격(122) 및 배송비(123)를 포함하는 구입 희망 총액(121)과, 구입 희망 개수(124)와, 배송처 정보(125)를 포함한다. 구입 요구(12)는, 시스템 이용료(126)를 추가로 포함하고 있어도 좋다. 시스템 이용료(126)는, 구매자(10)가 상품 거래 시스템(1)을 이용하는 것에 있어서의 이용 요금이며, 전형적으로는, 구입 희망 가격(122) 또는 구입 희망 총액(121)에 대하여 소정률(예를 들면 1.0%)을 곱한 금액이 자동적으로 산출되어도 좋다.

즉, 운영 서버(100)는, 매칭한 구입 요구(12)와 판매 요구(22)에 기초하는 상품 거래가 완료되면, 구입 요구(12)에 대응하는 구매자(10)의 계좌로부터 시스템 이용료(126)를 징수하도록 하여도 좋다.

또한, 배송비(123)에 대해서는, 상품 1개마다 산출되어도 좋고, 복수의 상품에 대하여 일괄하여 산출되어도 좋다. 또한, 배송처 정보(125)에 대해서는, 반드시 구입 요구(12)에 포함시킬 필요는 없으며, 운영 서버(100)에 미리 격납된 사용자 정보(118)를 이용하도록 하여도 좋다.

구매자(10)는, 특정 상품의 구입을 희망하는 경우에는, 구입 희망 개수(124)에 더하여, 구입 희망 가격(122)을 지정, 혹은, 구입 희망 가격(122) 및 배송비(123)를 포함하는 구입 희망 총액(121)을 지정한다. 이에 따라, 구매자(10)의 단말이 구입 요구(12)를 생성하여, 운영 서버(100)로 송신한다.

한편, 공급자(20)로부터의 판매 요구(22)는, 판매 희망 가격(222) 및 배송비(223)를 포함하는 판매 희망 총액(221)과, 판매 희망 개수(224)와, 배송비 정의(225)를 포함한다. 판매 요구(22)에 있어서, 구매자(10)의 배송처 정보(125)에 기초하여, 배송비 정의(225)로부터 배송비(223)가 산출되어도 좋다.

공급자(20)는, 특정 상품의 판매를 희망하는 경우에는, 판매 희망 가격(222) 및 판매 희망 개수(224)를 지정한다. 이에 따라, 공급자(20)의 단말이 판매 요구(22)를 생성하여, 운영 서버(100)로 송신한다. 운영 서버(100)는, 구입처의 후보인 구매자(10)마다, 판매 요구(22)에 있어서의 배송비(223)를 산출 혹은 평가한다.

운영 서버(100)는, 1 또는 복수의 구매자(10)로부터의 구입 요구(12)의 구입 희망 총액(121)과, 1 또는 복수의 공급자(20)로부터의 판매 요구(22)의 판매 희망 총액(221)을 비교하여, 서로의 조건이 합치되는지 아닌지(매칭하는지 아닌지)를 판단한다. 혹은, 운영 서버(100)는, 1 또는 복수의 구매자(10)로부터의 구입 요구(12)의 구입 희망 가격(122)과, 1 또는 복수의 공급자(20)로부터의 판매 요구(22)의 판매 희망 가격(222)을 비교하여, 서로의 조건이 합치되는지 아닌지(매칭하는지 아닌지)를 판단한다.

또한, 매칭 처리에 있어서는, 한쪽이 불리한 조건이 되지 않는다면, 다른 한쪽이 유리한 조건에서 거래 성립이라고 결정하여도 좋다. 예를 들면, 구매자(10)가 어떤 상품의 구입 희망 가격(122)을 「100엔」으로 설정하고 있었던 바, 공급자(20)가 당해 상품의 판매 희망 가격(222)을 「90엔」으로 설정하였다고 한다. 이 경우, 구매자(10)가 희망하는 구입 희망 가격(122)을 「90엔」으로 변경한 후에, 거래 성립이라고 결정하여도 좋다. 이 경우에는, 구매자(10)는, 구입 희망 가격(122)보다 「10엔」 저렴하게 상품을 구입할 수 있으므로, 유리한 조건에서의 거래가 된다.

반대로, 공급자(20)가 희망하는 판매 희망 가격(222)을 「100엔」으로 변경한 후에, 거래 성립이라고 결정하여도 좋다. 이 경우에는, 공급자(20)는, 판매 희망 가격(222)보다 「10엔」 저렴하게 상품을 구입할 수 있으므로, 유리한 조건에서의 거래가 된다.

또한, 구매자(10)가 희망하는 구입 희망 가격(122)을 「95엔」으로 변경함과 함께, 공급자(20)가 희망하는 판매 희망 가격(222)을 「95엔」으로 변경한 후에, 거래 성립이라고 결정하여도 좋다. 이 경우에는, 구매자(10) 및 공급자(20) 양쪽에 있어서, 당초와 비교하여 유리한 조건에서의 거래가 된다.

또한 개수에 대해서는, 일부 조건만이 합치되는 바와 같은 경우라도, 거래를 성립시켜도 좋고, 모든 개수에 대한 조건이 합치되지 않으면 거래를 성립시켜도 좋다. 예를 들면, 구입 요구(12)의 구입 희망 개수(124)가 판매 요구(22)의 판매 희망 개수(224)보다 적은 경우에는, 구매자(10)는, 구입 희망 개수(124)로 지정된 개수의 일부만을 구입할 수 있게 된다. 구매자(10)가 허용하는 경우에는, 이러한 지정된 개수의 일부만에 대해서 거래가 성립되도록 하여도 좋다.

(c2: 사용자 인터페이스 화면)

다음으로, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서 제공되는 사용자 인터페이스 화면의 일례에 대해서 설명한다.

도 5는, 본 실시 형태에 따른 상품 거래 시스템(1)을 구성하는 구매자(10)의 단말상에 제공되는 사용자 인터페이스 화면(300)의 일례를 나타내는 모식도이다. 도 5를 참조하여, 사용자 인터페이스 화면(300)은, 구입 요구(12)를 생성하기 위한 구매자(10)로부터의 지시를 접수한다.

보다 구체적으로는, 사용자 인터페이스 화면(300)은, 구매자(10)가 구입을 희망하는 상품의 화상을 나타내는 상품 표시부(302)와, 구입을 희망하는 상품을 검색하기 위한 검색 버튼(304)과, 구입을 희망하는 상품을 특정하기 위한 식별 정보를 리딩하기 위한 코드 리딩 버튼(306)을 포함한다.

구매자(10)는, 검색 버튼(304)을 선택하고, 상품명 또는 상품을 특정하는 코드 등을 입력함으로써, 구입을 희망하는 상품을 검색할 수 있다. 혹은, 구매자(10)는, 코드 리딩 버튼(306)을 선택하고, 단말에 실장되어 있는 카메라 등으로 구입을 희망하는 상품에 붙여져 있는 바코드나 QR코드(등록상표)를 리딩함으로써 구입을 희망하는 상품을 지정할 수 있다.

이와 같이 검색 혹은 지정된 상품을 나타내는 화상 등이 상품 표시부(302)에 표시된다.

또한, 상품명 또는 식별 정보에 기초하는 상품의 검색, 그리고, 상품의 화상 검색 등을 실행하기 위해, 운영 서버(100)의 내부 혹은 외부에, 상품 관리용의 데이터베이스를 배치하여도 좋다.

구매자(10)는, 구입을 희망하는 상품을 지정하면, 구입 희망 가격 및 구입 희망 개수를 입력한다. 보다 구체적으로는, 사용자 인터페이스 화면(300)은, 개수 입력 박스(310) 및 가격 입력 박스(314)를 포함한다.

구매자(10)는, 구입 희망 개수를 개수 입력 박스(310)에 입력함과 함께, 구입 희망 가격을 가격 입력 박스(314)에 입력한다.

개별 단위(1개 단위) 또는 케이스 단위 중 어느 하나를 선택하기 위한 단위 선택 라디오 버튼(312)의 선택 상태에 따라, 개수 입력 박스(310)에 입력되는 구입 희망 개수는, 개별 단위 및 케이스 단위 중 어느 하나로 설정된다.

배송비 포함 또는 배송비 별도 중 어느 하나를 선택하기 위한 배송비 선택 라디오 버튼(316)의 선택 상태에 따라, 가격 입력 박스(314)에 입력되는 구입 희망 가격은, 배송비 포함의 가격 및 배송비 별도의 가격 중 어느 하나로 설정된다. 배송비 선택 라디오 버튼(316)이 배송비 포함으로 선택되어 있으면, 가격 입력 박스(314)에 입력되는 가격은 구입 희망 총액(121)을 의미하게 되고, 배송비 선택 라디오 버튼(316)이 배송비 별도로 선택되어 있으면, 가격 입력 박스(314)에 입력되는 가격은 구입 희망 가격(122)을 의미하게 된다.

또한, 사용자 인터페이스 화면(300)은, 구입 희망 개수의 일부 개수에 대해서만 조건이 합치된 경우에, 당해 조건이 합치된 개수에 대해서만 거래 성립으로 하여 처리할지 아닌지를 설정하는 체크 버튼(318)을 포함한다. 체크 버튼(318)이 선택됨으로써, 구입 희망 개수의 일부분에 대해서만 거래가 성립되는 것이 허용된다.

도 5에 나타내는 바와 같은 사용자 인터페이스 화면(300)을 통하여, 구입 요구(12)가 생성된다.

도 6은, 본 실시 형태에 따른 상품 거래 시스템(1)을 구성하는 공급자(20)의 단말상에 제공되는 사용자 인터페이스 화면의 일례를 나타내는 모식도이다. 도 6을 참조하여, 사용자 인터페이스 화면(400)은, 판매 요구(22)를 생성하기 위한 공급자(20)로부터의 지시를 접수한다.

보다 구체적으로는, 사용자 인터페이스 화면(400)은, 공급자(20)가 판매 가능한 상품의 일람을 나타내는 리스트(402)를 포함한다. 리스트(402)는, 공급자(20)가 판매 가능한 각 상품을 특정하기 위한 상품 코드를 나타내는 상품 코드란(404)과, 각 상품의 상품명을 나타내는 상품명란(406)과, 각 상품의 판매 희망 가격을 나타내는 판매 가격란(408)과, 각 상품의 판매 희망 개수를 나타내는 판매 개수란(410)과, 각 상품의 판매 희망 개수 중 거래가 아직 성립되어 있지 않은 개수를 나타내는 나머지 개수란(412)과, 구입 희망 판매의 일부의 개수에 대해서만 조건이 합치된 경우에, 당해 조건이 합치된 개수에 대해서만 거래 성립으로 하여 처리할지 아닌지를 설정하는 일부 거래란(414)을 포함한다.

공급자(20)는, 판매 가능한 상품을 리스트(402)에 등록함과 함께, 각 상품에 대해서, 판매 희망 가격(판매 가격란(408)) 및 판매 희망 가격(판매 개수란(410))을 입력한다.

공급자(20)는, 검색 버튼(416)을 선택하고, 상품명 또는 상품을 특정하는 코드 등을 입력함으로써, 판매 가능한 상품을 검색하여 리스트(402)에 등록할 수 있다. 혹은, 공급자(20)는, 코드 리딩 버튼(418)을 선택하고, 단말에 실장되어 있는 카메라 등으로 구입을 희망하는 상품에 붙여져 있는 바코드나 QR코드를 리딩함으로써, 판매 가능한 상품을 리스트(402)에 등록할 수 있다.

공급자(20)는, 내용 변경 버튼(420)을 선택하고, 리스트(402)에 등록되어 있는 판매 희망 가격(판매 가격란(408)) 및 판매 희망 가격(판매 개수란(410))을 임의로 변경할 수 있다. 공급자(20)가 변경한 내용은, 갱신 버튼(422)이 선택됨으로써 반영된다.

도 6에 나타내는 바와 같은 사용자 인터페이스 화면(400)을 통하여, 판매 요구(22)가 생성된다.

도 7은, 본 실시 형태에 따른 상품 거래 시스템(1)을 구성하는 구매자(10)의 단말상에 제공되는 사용자 인터페이스 화면(320)의 일례를 나타내는 모식도이다. 도 7을 참조하여, 사용자 인터페이스 화면(320)은, 운영 서버(100)에 접수되어 있는 구입 요구(12) 및 판매 요구(22)의 상황을 나타낸다. 보다 구체적으로는, 사용자 인터페이스 화면(320)은, 대상 상품의 화상을 나타내는 상품 표시부(322)와, 거래 상황을 나타내는 상황 표시부(330)를 포함한다.

상황 표시부(330)에는, 1 또는 복수의 구매자(10)로부터의 구입 요구(12)에 의한 구입 희망 가격 및 구입 희망 개수를 나타내는 구입 요구 상황 표시부(332)와, 1 또는 복수의 구매자(10)로부터의 판매 요구(22)에 의한 판매 희망 가격 및 판매 희망 개수를 나타내는 판매 요구 상황 표시부(334)를 포함한다. 상황 표시부(330)에 있어서는, 구입 요구(12)와 판매 요구(22)가 대비 가능한 상태로 표시되어 있고, 구매자(10) 및 공급자(20)는, 상황 표시부(330)를 참조하여, 새로운 구입 요구(12) 혹은 판매 요구(22)를 생성하는 경우나, 이미 생성되어 있는 구입 요구(12) 혹은 판매 요구(22)의 내용을 갱신한다.

사용자 인터페이스 화면(320)의 상황 표시부(330)는, 전형적으로는, 운영 서버(100)의 요구 큐(116(도 3))에 일시적으로 저장되어 있는 구입 요구(12) 및 판매 요구(22)의 내용에 기초하여 생성된다.

(c3: 사용자 관리)

다음으로, 상품 거래 시스템(1)의 운영 서버(100)에 있어서의 사용자 관리에 대해서 설명한다.

도 8은, 본 실시 형태에 따른 상품 거래 시스템(1)의 운영 서버(100)에 의한 구매자(10)에 관한 정보의 관리 방법을 설명하기 위한 도면이다. 도 8을 참조하여, 운영 서버(100)는, 구매자(10)의 각각을 관리하기 위한 관리 정보(150)를 갖고 있다.

관리 정보(150)는, 구매자(10)의 배송처(주소 혹은 위도 경도)를 나타내는 배송처 정보(152)를 포함한다. 관리 정보(150)에 포함되는 배송처 정보(152)는, 구입 요구(12)의 배송처 정보(125)로서 이용되어도 좋다. 단, 구매자(10)의 단말에 실장되는 GPS(Global Positioning System) 등으로부터의 위치 정보를 이용하여, 구입 요구(12)의 배송처 정보(125)를 그때마다 생성하도록 하여도 좋다. 이 경우에는, 반드시, 배송처 정보(152)를 관리 정보(150)에 포함시켜 둘 필요는 없다.

관리 정보(150)는, 구매자(10)의 계좌 잔고를 나타내는 잔고 정보(154)를 포함한다. 잔고 정보(154)는, 구매자(10) 및 공급자(20) 각각이 보유하는 경제적 가치를 관리하는 계좌를 구현화한 것이다. 경제적 가치로서는, 특정 통화에서의 금액이 상정되어 있지만, 가상 통화와 같은 것이어도 좋고, 상품 거래 시스템(1)에 있어서 이용되는 독자 포인트여도 좋다.

운영 서버(100)는, 구매자(10)가 구입 요구(12)를 생성하면, 대응하는 잔고 정보(154)로부터, 구입 요구(12)에 기초하여 결정되는 구입 예정액을 리저브(예약)한다. 즉, 운영 서버(100)는, 구입 요구(12)에 포함되는 구입 희망 가격에 기초하여 결정되는 가치를 대응하는 구매자(10)의 계좌로부터 예약한다.

관리 정보(150)는, 구매자(10)의 거래 정보를 나타내는 구입 이력(156)을 포함한다. 운영 서버(100)는, 거래가 성립될 때마다 구입 이력(156)의 내용을 갱신한다. 또한, 운영 서버(100)는, 구매자(10)가 구입 요구(12)를 생성할 때마다, 그 내용을 잔고 정보(154)에 반영하도록 하여도 좋다.

도 9는, 본 실시 형태에 따른 상품 거래 시스템(1)의 운영 서버(100)에 의한 공급자(20)에 관한 정보의 관리 방법을 설명하기 위한 도면이다. 도 9를 참조하여, 운영 서버(100)는, 공급자(20) 각각을 관리하기 위한 관리 정보(250)를 갖고 있다.

관리 정보(250)는, 공급자(20)의 계좌 잔고를 나타내는 잔고 정보(254)를 포함한다. 운영 서버(100)는, 어느 한쪽의 구매자(10)와 공급자(20) 사이에서 거래가 성립되면, 당해 거래에 의해 수수되는 금액이 대응하는 잔고 정보(254)에 가산된다.

관리 정보(250)는, 공급자(20)의 거래 정보를 나타내는 판매 이력(256)을 포함한다. 운영 서버(100)는, 거래가 성립될 때마다 판매 이력(256)의 내용을 갱신한다.

운영 서버(100)는, 도 8에 나타나는 관리 정보(150) 및 도 9에 나타나는 관리 정보(250)를 이용하여, 거래에 관한 구매자(10) 및 공급자(20)의 정보를 관리한다.

(c4: 배송비 산출)

다음으로, 배송비(구입 요구(12)에 포함되는 배송비(123) 및 판매 요구(22)에 포함되는 배송비(223))의 산출 방법의 일례에 대해서 설명한다.

도 10은, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서 이용되는 배송비 정의(226)의 일례를 나타내는 도면이다. 도 10에 나타내는 배송비 정의(226)는, 상품마다(도 10의 예에서는 「상품A」)의 배송비를 정의한다. 배송비 정의(226)에 있어서는, 구매자(10)와 공급자(20) 사이의 거리를 구분(구분 1∼5)하고, 구분마다 배송비가 정의된다. 구입 요구(12) 또는 판매 요구(22)에 있어서 배송비의 산출이 필요한 경우에는, 구매자(10)의 배송처 정보 및 배송비 정의(226)를 참조하여, 배송비가 결정된다.

도 10에 나타나는 배송비 정의(226)는, 판매 요구(22)의 배송비 정의(225)로서 이용되어도 좋다.

도 11은, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서 이용되는 배송비 정의(227)의 다른 일례를 나타내는 도면이다. 도 11에 나타내는 배송비 정의(227)는, 기본적으로는 모든 상품에 대하여 배송비를 정의한다. 배송비 정의(227)에 있어서는, 구매자(10)와 공급자(20) 사이의 거리를 구분(구분1∼5)하고, 구분마다 배송비가 정의된다.

어느 상품에 대해서 배송비의 산출이 필요한 경우에는, 상품마다의 중량을 나타내는 중량 테이블(228)을 참조하여, 각 상품에 대한 중량이 결정되고, 당해 결정된 중량을 배송비 정의(227)에 적용함으로써, 배송비가 결정된다.

또한, 도 10 및 도 11에는, 구매자(10)와 공급자(20) 사이의 거리를 구분하고, 각 구분에 대해서 배송비가 정의되어 있는 예를 나타냈지만, 이에 한정하지 않고, 단위 거리(예를 들면 1km)당에 배송비를 정의하도록 하여도 좋다. 또한, 국내용 및 해외용의 배송비 정의를 각각 규정하여도 좋다.

이상과 같이, 본 실시 형태에 따른 상품 거래 시스템(1)에 있어서는, 전술한 바와 같은 배송비 정의를 이용함으로써, 필요한 배송비를 산출할 수 있다. 즉, 운영 서버(100)는, 공급자(20) 또는 특정 상품에 관련지어진 배송비 정의와, 구매자(10)와 공급자(20) 사이의 거리에 기초하여, 당해 특정 상품을 배송하기 위한 배송비를 산출하도록 하여도 좋다.

(c5: 처리 수순)

다음으로, 상품 거래 시스템(1)의 운영 서버(100)에 있어서의 처리 수순의 일례에 대해서 설명한다. 도 12 및 도 13은, 본 실시 형태에 따른 상품 거래 시스템(1)의 운영 서버(100)에 있어서의 처리 수순을 나타내는 플로우차트이다. 도 12 및 도 13에는, 구매자(10)와 공급자(20) 사이의 상품 거래를 컴퓨터가 실행하는 상품 거래 방법이 나타난다.

도 12 및 도 13에 나타내는 각 스텝은, 전형적으로는, 운영 서버(100)의 프로세서(101)가 매칭 프로그램(112) 및 결제 프로그램(114)(상품 거래 프로그램에 상당)을 실행함으로써 실현된다.

도 12 및 도 13을 참조하여, 운영 서버(100)는, 구매자(10)의 단말로부터의 구입 요구(12) 또는 공급자(20)로부터의 판매 요구(22)를 수신하였는지 아닌지를 판단한다(스텝 S100). 구매자(10)의 단말로부터의 구입 요구(12) 또는 공급자(20)로부터의 판매 요구(22)를 수신하였다면(스텝 S100에 있어서 YES), 운영 서버(100)는, 수신한 구입 요구(12) 또는 판매 요구(22)를 요구 큐(116)에 격납한다(스텝 S102).

이와 같이, 운영 서버(100)는, 구매자(10)로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구(12)를 접수하는 처리, 및, 공급자(20)로부터 특정 상품의 판매 희망 가격을 포함하는 판매 요구(22)를 접수하는 처리를 실행한다.

계속해서, 운영 서버(100)는, 수신한 요구가 구입 요구(12)인지 아닌지를 판단한다(스텝 S104). 수신한 요구가 구입 요구(12)이면(스텝 S104에 있어서 YES), 운영 서버(100)는, 당해 수신한 구입 요구(12)에 포함되는 구입 희망 가격 및 구입 희망 개수에 기초하여 결정되는 구입 예정액이, 구입 요구(12)를 송신한 구매자(10)의 계좌에 존재하는지 아닌지를 판단한다(스텝 S106).

구입 예정액이 구매자(10)의 계좌에 존재하고 있으면(스텝 S106에 있어서 YES), 운영 서버(100)는, 구매자(10)의 계좌로부터 구입 예정액을 리저브(예약)한다(스텝 S108). 그리고, 스텝 S110 이하의 매칭 처리가 실행된다.

구입 예정액이 구매자(10)의 계좌에 존재하고 있지 않으면(스텝 S106에 있어서 NO), 운영 서버(100)는, 스텝 S110 이하의 매칭 처리를 실행하지 않는다. 이때, 운영 서버(100)는, 구입 요구(12)를 생성할 수 없다는 취지를 구매자(10)의 단말에 통지하여도 좋다.

수신한 요구가 판매 요구(22)이면(스텝 S104에 있어서 NO), 스텝 S106 및 S108의 처리는 스킵된다.

구매자(10)의 단말로부터의 구입 요구(12) 또는 공급자(20)로부터의 판매 요구(22)가 수신되어 있지 않으면(스텝 S100에 있어서 NO), 운영 서버(100)는, 구매자(10)의 단말로부터 구입 요구(12)의 변경 또는 공급자(20)로부터 판매 요구(22)의 변경을 수신하였는지 아닌지를 판단한다(스텝 S109). 구매자(10)의 단말로부터 구입 요구(12)의 변경 또는 공급자(20)로부터 판매 요구(22)의 변경을 수신하고 있으면(스텝 S100에 있어서 YES), 스텝 S110 이하의 매칭 처리가 실행된다.

구매자(10)의 단말로부터 구입 요구(12)의 변경 및 공급자(20)로부터 판매 요구(22)의 변경 중 어느 것도 수신되어 있지 않으면(스텝 S100에 있어서 NO), 스텝 S100 이하의 처리가 반복된다.

이와 같이, 구입 요구(12) 또는 판매 요구(22)가 요구 큐(116)에 추가되었을 때, 또는, 요구 큐(116)에 저장되어 있는 구입 요구(12) 또는 판매 요구(22)가 변경되었을 때에, 구입 요구(12)와 판매 요구(22)가 매칭하는지 아닌지를 판단하는 처리가 실행된다.

구매자(10)의 단말로부터 구입 요구(12)의 변경 및 공급자(20)로부터 판매 요구(22)의 변경이 수신되어 있지 않으면(스텝 S100에 있어서 NO), 스텝 S100 이하의 처리가 반복된다.

운영 서버(100)는, 새롭게 수신 또는 갱신된 요구가 구입 요구(12) 및 판매 요구(22)의 어느 것인지를 판단한다(스텝 S110).

새롭게 수신 또는 갱신된 요구가 구입 요구(12)이면(스텝 S110에 있어서 「구입 요구」), 운영 서버(100)는, 당해 새롭게 수신 또는 갱신된 구입 요구(12)를 매칭 대상의 구입 요구(12)로 설정하고(스텝 S112), 요구 큐(116)에 격납되어 있는 판매 요구(22) 중 1개를 매칭 후보로서 선택한다(스텝 S114).

계속해서, 운영 서버(100)는, 매칭 대상의 구입 요구(12) 또는 매칭 후보의 판매 요구(22)에 대해서 배송비의 산출이 필요한지 아닌지를 판단한다(스텝 S116). 매칭 대상의 구입 요구(12) 또는 매칭 후보의 판매 요구(22)에 대해서 배송비의 산출이 필요하면(스텝 S116에 있어서 YES), 운영 서버(100)는, 구매자(10)의 배송처를 나타내는 정보(배송처 정보(125) 또는 배송처 정보(152))와, 배송비에 관한 정보(배송비 정의(225) 또는 배송비 정의(226))에 기초하여, 필요한 배송비(배송비(123) 또는 배송비(223))를 결정한다(스텝 S118).

이와 같이, 운영 서버(100)는, 공급자(20)로부터 구매자(10)까지의 특정 상품을 배송하기 위한 배송비를 반영한 후에, 구입 요구(12)와 판매 요구(22)가 매칭하는지 아닌지를 판단한다.

한편, 매칭 대상의 구입 요구(12) 또는 매칭 후보의 판매 요구(22)에 대해서 배송비의 산출이 필요하지 않으면(스텝 S116에 있어서 NO), 스텝 S118의 처리는 스킵된다.

그리고, 운영 서버(100)는, 매칭 대상의 구입 요구(12)와 매칭 후보의 판매 요구(22)를 비교하여, 서로의 조건이 합치되는지 아닌지를 판단한다(스텝 S120).

매칭 대상의 구입 요구(12)와 매칭 후보의 판매 요구(22)와의 사이에서, 서로의 조건이 합치되면(스텝 S120에 있어서 YES), 운영 서버(100)는, 거래 성립이라고 결정하고, 대상의 구입 요구(12) 및 판매 요구(22)에 각각 대응하는 구매자(10) 및 공급자(20)에게 통지하며(스텝 S122), 대상의 구입 요구(12) 및 판매 요구(22)를, 대상 상품의 배송 완료 대기의 스테이터스로 변경한다(스텝 S124). 그리고 매칭 처리는 종료한다.

매칭 대상의 구입 요구(12)와 매칭 후보의 판매 요구(22)와의 사이에서, 서로의 조건이 합치되지 않으면(스텝 S120에 있어서 NO), 운영 서버(100)는, 요구 큐(116)에 격납되어 있는 모든 판매 요구(22)에 대해서 매칭 처리가 완료되었는지 아닌지를 판단한다(스텝 S126). 요구 큐(116)에 격납되어 있는 판매 요구(22) 중 매칭 처리가 실행되어 있지 않은 것이 있으면(스텝 S126에 있어서 NO), 운영 서버(100)는, 아직 매칭 처리가 실행되어 있지 않은 1개의 판매 요구(22)를 매칭 후보로서 선택하고(스텝 S128), 스텝 S116 이하의 처리를 반복한다.

한편, 요구 큐(116)에 격납되어 있는 모든 판매 요구(22)에 대해서 매칭 처리가 완료되어 있으면(스텝 S126에 있어서 YES), 운영 서버(100)는, 서로의 조건이 합치되는 구입 요구(12)와 판매 요구(22)가 발견되지 않았다고 판단하여, 매칭 처리를 종료한다.

한편, 새롭게 수신 또는 갱신된 요구가 판매 요구(22)이면(스텝 S110에 있어서 「판매 요구」), 운영 서버(100)는, 당해 새롭게 수신 또는 갱신된 판매 요구(22)를 매칭 대상의 판매 요구(22)로 설정하고(스텝 S132), 요구 큐(116)에 격납되어 있는 구입 요구(12) 중 1개를 매칭 후보로서 선택한다(스텝 S134).

계속해서, 운영 서버(100)는, 매칭 대상의 판매 요구(22) 또는 매칭 후보의 구입 요구(12)에 대해서 배송비의 산출이 필요한지 아닌지를 판단한다(스텝 S136). 매칭 대상의 판매 요구(22) 또는 매칭 후보의 구입 요구(12)에 대해서 배송비의 산출이 필요하면(스텝 S136에 있어서 YES), 운영 서버(100)는, 구매자(10)의 배송처를 나타내는 정보(배송처 정보(125) 또는 배송처 정보(152))와, 배송비에 관한 정보(배송비 정의(225) 또는 배송비 정의(226))에 기초하여, 필요한 배송비(배송비(123) 또는 배송비(223))를 결정한다(스텝 S138).

한편, 매칭 대상의 판매 요구(22) 또는 매칭 후보의 구입 요구(12)에 대해서 배송비의 산출이 필요하지 않으면(스텝 S136에 있어서 NO), 스텝 S138의 처리는 스킵된다.

그리고, 운영 서버(100)는, 매칭 대상의 판매 요구(22)와 매칭 후보의 구입 요구(12)를 비교하여, 서로의 조건이 합치되는지 아닌지를 판단한다(스텝 S140).

매칭 대상의 판매 요구(22)와 매칭 후보의 구입 요구(12) 사이에서, 서로의 조건이 합치되면(스텝 S140에 있어서 YES), 운영 서버(100)는, 거래 성립이라고 결정하고, 대상의 판매 요구(22) 및 구입 요구(12)에 각각 대응하는 공급자(20) 및 구매자(10)에게 통지하며(스텝 S142), 대상의 판매 요구(22) 및 구입 요구(12)를, 대상 상품의 배송 완료 대기의 스테이터스로 변경한다(스텝 S144). 그리고 매칭 처리는 종료한다.

매칭 대상의 판매 요구(22)와 매칭 후보의 구입 요구(12) 사이에서, 서로의 조건이 합치되지 않으면(스텝 S140에 있어서 NO), 운영 서버(100)는, 요구 큐(116)에 격납되어 있는 모든 구입 요구(12)에 대해서 매칭 처리가 완료되었는지 아닌지를 판단한다(스텝 S146). 요구 큐(116)에 격납되어 있는 구입 요구(12) 중 매칭 처리가 실행되어 있지 않은 것이 있으면(스텝 S146에 있어서 NO), 운영 서버(100)는, 아직 매칭 처리가 실행되어 있지 않은 1개의 구입 요구(12)를 매칭 후보로서 선택하고(스텝 S148), 스텝 S136 이하의 처리를 반복한다.

한편, 요구 큐(116)에 격납되어 있는 모든 구입 요구(12)에 대해서 매칭 처리가 완료되어 있으면(스텝 S146에 있어서 YES), 운영 서버(100)는, 서로의 조건이 합치되는 판매 요구(22)와 구입 요구(12)가 발견되지 않았다고 판단하고, 매칭 처리를 종료한다.

<D. 상품 관리>

본 실시 형태에 따른 상품 거래 시스템(1)에 있어서의 상품 관리의 일례에 대해서 설명한다.

(d1: 식별 정보)

상품 거래 시스템(1)에 있어서 취급되는 상품은, 패키지 등에 붙여지는 식별 정보를 이용하여 특정되어도 좋다. 이러한 식별 정보로서는, 예를 들면, JAN(Japanese Article Number) 코드, EAN(European Article Number) 코드, GTIN-13, GTIN-8 등의 상품 식별번호를 이용하여도 좋다. 이러한 상품 식별번호를 이용함으로써, 복수의 국가 사이에서 유통하는 상품에 대해서도 취급을 용이화할 수 있다.

또한, 집합 포장용의 식별 정보를 사용하도록 하여도 좋다. 집합 포장용의 식별 정보는, 기업 간의 거래 단위인 집합 포장(케이스, 판지, 팰릿 등)에 대하여 설정되는 상품 식별번호를 포함한다. 이러한 집합 포장용의 식별 정보로서는, GTIN-14 등의 집합 포장용 상품 코드가 알려져 있다. 집합 포장용 상품 코드는, 집합 포장된 개개의 상품에 대한 상품 식별번호를 포함하므로, 상품 거래 시스템(1)에 있어서, 개개의 상품을 취급할 수도 있음과 함께, 그것들을 집합시킨 상태에서 취급할 수도 있다.

또한, 집합 포장용 상품 코드는, ITF(Inter-Leaved two of Five) 심벌 등의 바코드 심벌로서 구현화할 수 있다.

전술한 바와 같은 개별의 상품을 나타내는 식별 정보 및 집합 포장용의 식별 정보를 병용함으로써, 상품의 특성이나 공급자(20)의 사정에 따른 보다 유연한 거래를 실현할 수 있다.

(d2: 메타 상품)

본 실시 형태에 따른 상품 거래 시스템(1)에 있어서, 동일 종류의 복수 상품을 묶어서 1개의 상품으로서 취급하도록 하여도 좋다. 이러한 상품을 「메타 상품」이라고도 칭한다.

예를 들면 「물」에 대해서는, 여러 가지의 상품이 제공되어 있지만, 구매자(10)의 일부는, 특정 생산자 및 상품을 특정하는 것까지는 실행하지 않고, 단순히 「물」을 구입하고 싶다고 희망하는 사람도 존재한다.

그래서, 예를 들면 「1리터의 PET용기에 들어간 물」과 같은 상품을 특정하지 않고, 포괄적인 상품 종별을 규정하는 메타 상품을 규정하여도 좋다.

이러한 메타 상품에 어느 상품이 포함되는지와 같은 대응 지음 정보를 운영 서버(100)에 저장하여 둠으로써, 구매자(10)는, 「1리터의 PET용기에 들어간 물」(어느 상품인지는 묻지 않음)을 주문할 수 있다.

한편, 공급자(20)는, 메타 상품이 요구하는 상품 종별에 해당만 하면, 임의의 상품을 제공할 수 있으므로, 재고 처분 등을 보다 용이하게 실행할 수 있다.

또한, 각 메타 상품에 어떤 상품을 포함시킬지에 대해서는, 운영 서버(100)측에서 관리하여도 좋고, 각 메타 상품에 포함시킬 수 있는 조건을 명시하고, 당해 조건에 따라서 공급자(20)측에서 메타 상품으로서 판매하도록 하여도 좋다. 운영 서버(100)측에서 메타 상품을 관리하는 경우에는, 메타 상품을 나타내는 상품 식별번호와, 당해 메타 상품에 포함되는 특정의 1 또는 복수의 상품 각각을 나타내는 상품 식별번호와 대응짓는 테이블을 저장하도록 하여도 좋다.

이와 같이, 메타 상품을 이용 가능하게 함으로써, 보다 유연한 상품 거래를 실현할 수 있다.

<E. 구입 요구(12) 및 판매 요구(22)의 베리에이션>

전술한 설명에 있어서는, 구입 요구(12)에 포함되는 구입 희망 총액(121)(구입 희망 가격(122) 및 배송비(123)를 포함함)과, 판매 요구(22)에 포함되는 판매 희망 총액(221)(판매 희망 가격(222) 및 배송비(223)를 포함함)을 비교하는 매칭 처리에 대해서 예시했지만, 이에 한정하지 않고, 구입 요구(12) 및 판매 요구(22)에 대해서는, 추가의 조건을 포함시키도록 하여도 좋다. 이하, 몇 개의 베리에이션에 대해서 설명한다.

(e1: 가격 지정 옵션)

도 5 및 도 6에는, 사용자가 구체적인 구입 희망 가격 또는 판매 희망 가격을 입력하는 예를 나타내지만, 이에 한정하지 않고, 거래 상황(도 7 등 참조)에 따른 가격을 지정할 수 있도록 하여도 좋다.

도 14는, 본 실시 형태에 따른 상품 거래 시스템(1)을 구성하는 구매자(10)의 단말상에 제공되는 사용자 인터페이스 화면(300)의 다른 일례를 나타내는 모식도이다. 도 14에 나타내는 사용자 인터페이스 화면(300)에 있어서는, 가격 입력 박스(314)에 「현재의 최저가」가 지정되어 있는 예를 나타낸다.

구입 요구(12)의 「현재의 최저가」는, 도 7에 나타내는 거래 상황에 있어서, 거래가 성립되어 있지 않은 판매 요구(22)에 포함되는 판매 희망 총액(221) 혹은 판매 희망 가격(222) 중 최저가를 의미한다. 이러한 구입 희망 가격으로서 「현재의 최저가」가 지정되면, 구입 희망 개수를 만족할 만큼의 판매 희망 개수가 존재하고 있으면, 바로 거래가 성립되게 된다.

반대로, 판매 요구(22)를 생성할 때에 「현재의 최고가」를 지정하도록 하여도 좋다. 이 경우에는, 도 7에 나타내는 거래 상황에 있어서, 거래가 성립되어 있지 않은 구입 요구(12)에 포함되는 구입 희망 총액(121) 혹은 구입 희망 가격(122) 중 최고가를 의미한다. 이러한 판매 희망 가격으로서 「현재의 최고가」가 지정되면, 판매 희망 개수를 만족할 만큼의 구입 희망 개수가 존재하고 있으면, 바로 거래가 성립되게 된다.

또한, 「현재의 최저가」 혹은 「현재의 최고가」라는 지정에 더하여, 「현재의 최저가로부터 5엔 상승」 혹은 「현재의 최고가로부터 5엔 하락」이라는 지정 등도 가능하다.

또한, 전술한 예에 한정하지 않고, 구입 희망 가격 및 판매 희망 가격에 대해서는, 임의의 형태로 지정할 수 있도록 하여도 좋다.

전술한 바와 같은 구입 희망 가격 및 판매 희망 가격에 대한 가격 지정 옵션을 충실화함으로써, 구매자(10) 및 공급자(20)는, 거래 상황에 따른 유연한 거래를 즐길 수 있다.

(e2: 집합 포장 옵션)

전술한 바와 같이, 공급자(20)는, 상품을 거래 단위로 묶은 집합 포장의 형태(예를 들면, 12개의 상품이 1개의 골판지에 패키지되어 있는 바와 같은 형태)로 구매자(10)에게 제공하는 경우도 많다. 이러한 경우, 집합 포장을 1단위로 하여 판매할 수도 있고, 집합 포장에 포함되는 개개의 상품을 판매할 수도 있다.

이러한 니즈에 대하여, 판매 요구(22)를 생성할 때에는, 집합 포장을 1단위로만 판매하는지, 혹은, 집합 포장에 포함되는 상품을 개별적으로 판매하는 것을 허용하는지를 선택할 수 있도록 하여도 좋다.

도 15는, 본 실시 형태에 따른 상품 거래 시스템(1)을 구성하는 공급자(20)의 단말상에 제공되는 사용자 인터페이스 화면의 다른 일례를 나타내는 모식도이다. 공급자(20)는, 도 15에 나타내는 바와 같은 사용자 인터페이스 화면(400)에 있어서, 거래 단위로 집합 포장된 상품에 대해서는, 집합 포장을 1단위로만 판매하는지, 혹은, 집합 포장에 포함되는 상품을 개별적으로 판매하는 것을 허용하는지에 대한 선택을 접수하도록 하여도 좋다(개별 판매란(424)).

운영 서버(100)는, 이러한 집합 포장에 대한 공급자(20)의 요망을 고려하여, 구입 요구(12)와 판매 요구(22) 사이의 조건의 합치를 판단한다.

또한, 집합 포장을 1단위로 하여 판매하는 경우와, 집합 포장을 개개의 상품으로 나누어 판매하는 경우 사이에서, 배송비를 상이하게 하여도 좋다. 통상, 집합 포장을 1단위로 하여 판매하는 경우에 비교하여, 집합 포장을 개개의 상품으로 나누어 판매하는 경우의 배송비는 보다 고액으로 설정된다. 이와 같은 상이한 배송비를 설정함으로써, 집합 포장을 1단위로 하여 판매하는 것의 인센티브를 높일 수 있다.

(e3: 유효기한 옵션)

구매자(10) 및 공급자(20)는, 거래가 성립될 때까지는, 구입 요구(12) 및 판매 요구(22)를 각각 임의로 취소 혹은 철회할 수 있도록 하여도 좋다. 또한, 상품의 특성에 따라서는, 특정 기한까지 구입 또는 판매하지 않으면 안 되는 경우도 있다.

이러한 니즈를 고려하여, 구입 요구(12) 및 판매 요구(22)에 대해서 유효기한을 설정하도록 하여도 좋다. 보다 구체적으로는, 구매자(10) 및 공급자(20)는, 임의의 구입 요구(12) 및 판매 요구(22)를 생성하였을 때에, 거래가 성립되지 않으면, 요구를 취소 혹은 철회하는 기한(유효기한의 조건)을 부가할 수 있도록 하여도 좋다.

운영 서버(100)는, 유효기한이 지정된 구입 요구(12) 및 판매 요구(22)에 대해서는, 지정된 유효기한이 도래하여도 거래가 성립되어 있지 않으면, 대응하는 구입 요구(12) 또는 판매 요구(22)를 강제적으로 취소한다. 이러한 유효기한의 조건을 구입 요구(12) 또는 판매 요구(22)에 부가함으로써, 시기에 늦게 거래가 성립되어 버리는 바와 같은 사태를 회피할 수 있다.

유효기한의 지정 방법으로서는, 특정 날짜, 특정 일시, 오늘 중, 이번 주 중, 이번 달 중 등의 임의의 방법을 채용하여도 좋다.

(e4: 재고 유무 옵션)

공급자(20)는 특정 상품을 상시 공급하는 것이 예정되어 있지만, 어떠한 사정으로 일시적으로 상품을 공급할 수 없는 상황으로 되어 있을 가능성도 있다. 이러한 경우, 상품이 입하하는 대로, 상품은 구매자(10)에게 배송되게 되지만, 상품 입하까지 기다리게 하게 된다.

그래서, 구매자(10)가 구입 요구(12)를 생성할 때에, 지정한 상품의 재고 유무를 조건으로서 추가하도록 하여도 좋다. 보다 구체적으로는, 공급자(20)가 재고를 가지고 있는 경우에 한해서 거래를 성립시키는지, 혹은, 공급자(20)가 재고를 가지고 있지 않아도 거래를 성립시키는지를 구매자(10)가 선택할 수 있도록 하여도 좋다.

공급자(20)가 재고를 가지고 있는 경우에 한해서 거래를 성립시키는 것이 조건으로 되어 있는 경우에는, 지정된 상품이 공급자(20)의 재고로서 존재하고 있는 경우에 한해서, 거래가 성립되게 된다.

한편, 공급자(20)가 재고를 가지고 있지 않아도 거래를 성립시키는 것이 지정되어 있는 경우에는, 공급자(20)에게 대상의 상품이 입하될 때까지의 시간 등을 구매자(10)에게 제시하도록 하여도 좋다.

(e5: 배송 개시 기한 옵션)

구매자(10)는 어떠한 상품을 가능한 한 빨리 받고 싶다고 생각하고 있는 경우도 있다. 그래서, 구매자(10)가 구입 요구(12)를 생성할 때에, 지정한 상품이 공급자(20)로부터 배송될 때까지의 기한을 조건으로서 추가하도록 하여도 좋다. 보다 구체적으로는, 구매자(10)는, 거래가 성립되고 나서 상품이 배송될 때까지의 시간(예를 들면, 거래 성립으로부터 6시간 이내 등), 혹은, 상품을 배송해야 할 기한(예를 들면, 10월 1일 15시 등)을 지정할 수 있도록 하여도 좋다.

이러한 조건이 부가된 구입 요구(12)가 생성된 경우에는, 운영 서버(100)는, 공급자(20)로부터의 배송 가능 시각 등의 정보 제공을 받고, 구입 요구(12)와 판매 요구(22) 사이에서 조건이 합치되는지 아닌지를 판단한다.

(e6: 배송 가능 범위 옵션)

공급자(20)의 사업 규모에 따라서는, 상품을 배송할 수 있는 범위가 제한되는 경우가 있다. 이러한 배송 범위의 제한을 고려하여, 공급자(20)가 판매 요구(22)를 생성할 때에, 상품을 배송 가능한 범위를 미리 지정하도록 하여도 좋다. 보다 구체적으로는, 공급자(20)는, 상품을 배송 가능한 범위(예를 들면, 일본 국내만, 500km 여부 등)를 지정할 수 있도록 하여도 좋다.

이러한 조건이 부가된 판매 요구(22)가 생성된 경우에는, 운영 서버(100)는, 구매자(10)의 배송처 정보(구매자(10)의 위치를 나타내는 정보)를 참조하여, 구입 요구(12)와 판매 요구(22) 사이에서 조건이 합치되는지 아닌지를 판단한다.

또한, 구매자(10)가 구입 요구(12)를 생성할 때에, 공급자(20)가 미리 지정하고 있는 배송 가능 범위의 조건에 합치되지 않는 것이 명확한 경우에는, 구매자(10)에 대하여, 조건에 합치되지 않는 판매 요구(22)를 숨기도록 하여도 좋다.

(e7: 자격 확인)

거래되는 상품(예를 들면, 알코올류, 담배, 약 등)에 따라서는, 구매자(10)가 소정의 자격을 가지고 있는 것을 확인할 필요가 있다. 그 때문에, 운영 서버(100)는, 구매자(10)의 속성 정보(연령 등)를 미리 저장하여 두고, 속성 정보도 참조하여, 구입 요구(12)와 판매 요구(22) 사이에서 조건이 합치되는지 아닌지를 판단하도록 하여도 좋다.

구매자(10)의 속성 정보에 대해서는, 구매자(10)가 운전면허증을 찍은 화상 등을 미리 운영 서버(100)로 송신하고, 그 송신된 화상에 기초하여, 당해 구매자(10)의 속성 정보를 생성하도록 하여도 좋다.

이러한 구매자(10)의 자격을 확인함으로써, 적성 또한 적법한 거래를 실현할 수 있다.

(e8: 볼륨 디스카운트)

상품 거래 시스템(1)에 있어서의 상품의 거래에 있어서, 소정 수를 초과하는 상품이 구입되는 경우에는, 상품의 가격을 낮추도록 하여도 좋다. 이 경우에는, 공급자(20)가 판매 요구(22)를 생성할 때에, 상품의 판매수와 할인율(디스카운트율)을 조건으로서 추가하도록 하여도 좋다.

운영 서버(100)는, 매칭 처리에 있어서, 지정된 판매수 이상의 상품 거래가 성립된 경우에는, 지정된 할인율에 따라서 상품의 가격을 결정하여도 좋다.

<F. 그 외의 형태>

(f1: 계좌)

상품 거래 시스템(1)에 있어서는, 국제적인 상품 거래도 가능하며, 이러한 경우에는, 사용자의 계좌는, 특정 통화(예를 들면, 일본 엔이나 미국 달러 등)로 통일하여도 좋고, 복수의 통화로부터 사용자가 특정 통화를 선택하도록 하여도 좋다. 상이한 통화의 계좌 사이에서 거래가 실행되는 경우에는, 거래시의 환율을 고려하여, 계좌 사이에서 대금이 수수되어도 좋다.

혹은, 임의의 가상 통화를 이용해서 각 사용자의 계좌를 관리하도록 하여도 좋다. 공통의 가상 통화를 사용함으로써, 환율에 기초하는 변환 처리 등을 생략할 수 있다.

(f2: 분산 배치)

전술한 설명에 있어서는, 운영 서버(100)가 매칭 처리 및 결제 처리를 실행하는 예를 나타내지만, 각각의 처리를 상이한 서버에 실장하여도 좋고, 복수의 운영 서버(100)를 사용하여 실장하여도 좋다. 예를 들면, 국가마다 또는 지역마다 운영 서버(100)를 준비함과 함께, 운영 서버(100)끼리를 연계함으로써, 국제적인 상품 거래를 실현할 수 있다.

<G. 이점>

본 실시 형태에 따른 상품 거래 시스템(1)에 의하면, 구매자(10) 및 공급자(20)가 각각 구입 요구(12) 및 판매 요구(22)를 생성하고, 운영 서버(100)가 구입 요구(12)와 판매 요구(22) 사이의 매칭을 판단한다. 그리고, 매칭되었다고 판단되면, 공급자(20)로부터 구매자(10)에 대하여 상품이 배송됨과 함께, 상품의 배송 완료에 따라, 대금이 공급자(20)의 계좌로 이동된다. 이러한 전자적인 매매의 시스템을 도입함으로써, 생산자와 구매자(10) 사이에서 직접적인 상품의 거래도 가능하게 된다.

이번 개시된 실시 형태는 모든 점에서 예시이며 제한적인 것은 아니라고 생각되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 청구범위에 의해 나타나고, 청구범위와 균등한 의미 및 범위 내에서의 모든 변경이 포함되는 것이 의도된다.

1 : 상품 거래 시스템
10 : 구매자
12 : 구입 요구
20 : 공급자
22 : 판매 요구
30 : 배송자
100 : 운영 서버
101 : 프로세서
102 : 메인 메모리
103 : 통신 인터페이스
104 : 입력부
105 : 디스플레이
106 : 내부 버스
110 : 스토리지
112 : 매칭 프로그램
114 : 결제 프로그램
116 : 요구 큐
118 : 사용자 정보
121 : 구입 희망 총액
122 : 구입 희망 가격
123, 223 : 배송비
124 : 구입 희망 개수
125, 152 : 배송처 정보
126 : 시스템 이용료
150, 250 : 관리 정보
154, 254 : 잔고 정보
156 : 구입 이력
221 : 판매 희망 총액
222 : 판매 희망 가격
224 : 판매 희망 개수
225, 226, 227 : 배송비 정의
228 : 중량 테이블
256 : 판매 이력
300, 320, 400 : 사용자 인터페이스 화면
302, 322 : 상품 표시부
304, 416 : 검색 버튼
306, 418 : 버튼
310 : 개수 입력 박스
312 : 단위 선택 라디오 버튼
314 : 가격 입력 박스
316 : 배송비 선택 라디오 버튼
318 : 체크 버튼
330 : 상황 표시부
332 : 구입 요구 상황 표시부
334 : 판매 요구 상황 표시부
402 : 리스트
404 : 상품 코드란
406 : 상품명란
408 : 판매 가격란
410 : 판매 개수란
412 : 나머지 개수란
414 : 일부 거래란
420 : 내용 변경 버튼
422 : 갱신 버튼
424 : 개별 판매란

Claims

구매자와 공급자 사이의 상품 거래를 실행하기 위한 상품 거래 시스템으로서,
상기 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 제1 접수 수단과,
상기 공급자로부터 상기 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 제2 접수 수단과,
상기 공급자로부터 상기 구매자까지의 상기 특정 상품을 배송하기 위한 배송비를 반영한 후에, 상기 구입 요구와 상기 판매 요구가 매칭하는지 아닌지를 판단하는 판단 수단을 구비하는, 상품 거래 시스템.
제1항에 있어서,
1 또는 복수의 상기 구입 요구, 및, 1 또는 복수의 상기 판매 요구를 일시적으로 저장하기 위한 요구 큐를 추가로 구비하며,
상기 판단 수단은, 상기 구입 요구 또는 상기 판매 요구가 상기 요구 큐에 추가되었을 때, 또는, 상기 요구 큐에 저장되어 있는 상기 구입 요구 또는 상기 판매 요구가 변경되었을 때에, 상기 구입 요구와 상기 판매 요구가 매칭하는지 아닌지를 판단하는, 상품 거래 시스템.
제1항 또는 제2항에 있어서,
상기 공급자 또는 상기 특정 상품에 관련지어진 배송비 정의와, 상기 구매자와 상기 공급자 사이의 거리에 기초하여, 상기 특정 상품을 배송하기 위한 배송비를 산출하는 산출 수단을 추가로 구비하는, 상품 거래 시스템.
제1항 내지 제3항 중 어느 한 항에 있어서,
상기 구매자 및 상기 공급자의 각각이 보유하는 경제적 가치를 관리하는 계좌를 추가로 구비하며,
상기 제1 접수 수단은, 상기 구입 요구에 포함되는 구입 희망 가격에 기초하여 결정되는 가치를 대응하는 구매자의 계좌로부터 예약하는, 상품 거래 시스템.
제4항에 있어서,
매칭한 구입 요구와 판매 요구에 기초하는 상품 거래가 완료되면, 당해 구입 요구에 대응하는 구매자의 계좌로부터 이용료를 징수하는 수단을 추가로 구비하는, 상품 거래 시스템.
구매자와 공급자 사이의 상품 거래를 컴퓨터가 실행하는 상품 거래 방법으로서,
상기 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 스텝과,
상기 공급자로부터 상기 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 스텝과,
상기 공급자로부터 상기 구매자까지의 상기 특정 상품을 배송하기 위한 배송비를 반영한 후에, 상기 구입 요구와 상기 판매 요구가 매칭하는지 아닌지를 판단하는 스텝을 구비하는, 상품 거래 방법.
컴퓨터에 구매자와 공급자 사이의 상품 거래를 실행시키기 위한 상품 거래 프로그램으로서, 상기 상품 거래 프로그램은 상기 컴퓨터에,
상기 구매자로부터 특정 상품의 구입 희망 가격을 포함하는 구입 요구를 접수하는 스텝과,
상기 공급자로부터 상기 특정 상품의 판매 희망 가격을 포함하는 판매 요구를 접수하는 스텝과,
상기 공급자로부터 상기 구매자까지의 상기 특정 상품을 배송하기 위한 배송비를 반영한 후에, 상기 구입 요구와 상기 판매 요구가 매칭하는지 아닌지를 판단하는 스텝을 실행시키는, 상품 거래 프로그램.