KR20060036118A - 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치 - Google Patents

다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치 Download PDF

Info

Publication number
KR20060036118A
KR20060036118A KR1020067003128A KR20067003128A KR20060036118A KR 20060036118 A KR20060036118 A KR 20060036118A KR 1020067003128 A KR1020067003128 A KR 1020067003128A KR 20067003128 A KR20067003128 A KR 20067003128A KR 20060036118 A KR20060036118 A KR 20060036118A
Authority
KR
South Korea
Prior art keywords
transactions
seller
identifying
user
transaction
Prior art date
Application number
KR1020067003128A
Other languages
English (en)
Inventor
폴 푸
에릭 벡 한센
조지 량
데보라 리우
응안-하 디 응우옌
앤드류 리 샌들러
Original Assignee
이베이 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 이베이 인크. filed Critical 이베이 인크.
Publication of KR20060036118A publication Critical patent/KR20060036118A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0605—Supply or demand aggregation

Abstract

일 실시형태에서, 복수의 바이어와 복수의 판매자 간의 거래의 확립이 네트워크-기반 시장에서 지원된다. 구매서 생성 프로세스의 일부로서, 네트워크-기반 시장의 제 1 사용자가 일 당사자인 다중의 거래가 식별된다. 또한, 조합가능한 기준을 만족시키는 이들 거래의 하나 이상의 서브세트가 식별되며, 그 거래의 식별된 서브세트 중 적어도 하나에 대해, 구매서가 생성된다.

Description

다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의 거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및 장치{METHOD AND APPARATUS TO FACILITATE GENERATION OF INVOICES COMBINING MULTIPLE TRANSACTIONS ESTABLISHED UTILIZING A MULTI-SELLER NETWORK-BASED MARKETPLACE}
관련 출원
본 출원은 2003년 8월 14일자로 출원된 미국특허 가출원 제 60/495,648 호, 및 2003년 9월 8일자로 출원된 미국특허 가출원 제 60/501,251 호를 우선권 주장한다.
발명의 기술분야
본 발명은 일반적으로 상업 자동화의 기술분야에 관한 것으로, 좀더 상세하게는, 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의 거래를 조합하는 구매서 (invoice) 의 생성을 용이하게 하는 방법 및 시스템에 관한 것이다.
발명의 배경
인터넷 기술의 광범위한 채택으로, 네트워크-기반 시장은 상품 및 서비스를 구매 및 판매하기 위한 점점 더 유행하는 장소가 되고 있다. 점점 더 많은 판매자들이 중요한 분배 채널로서 네트워크-기반 시장에 집중함에 따라, 그러한 판매자에게 구매 툴 (invoicing tool) 을 제공할 필요성이 증가하였다.
다수의 종래의 구매 툴 (예를 들어, Intuit, Inc. 에 의해 개발 및 배포된 Quickbooks) 이 판매자에게 통상 이용가능하지만, 통상적으로, 그러한 구매 툴은 판매자가 거래를 확립할 수도 있는 시장에 무관하다. 따라서, 판매자는 구매서가 생성되어야 하는 거래에 관한 정보를 수동으로 입력하도록 요구된다.
네트워크-기반 시장이 판매자에게 더 주목을 끌기 위하여, 네트워크-기반 시장의 운영자가, 그 시장과 밀접하게 통합되고 구매서 내의 거래에 관한 정보를 자동으로 검색하고 그 정보를 포함할 수 있는 구매 툴을 제공하기 위해 어떠한 인센티브가 존재한다. 그러나, 그러한 통합된 구매 툴의 설계는 다수의 기술적인 난제 (challenge), 좀더 상세하게는, 어떻게 구매서가 주문제작되어 특정 거래 및 특정 바이어 또는 판매자의 고유한 요건을 수용할 수 있을지에 관한 난제를 제공한다. 또한, 특정 거래와 관련될 수도 있는 다수의 변수가 주어지면, 그러한 구매 툴에 의한 구매서 생성의 자동화에 관한 다수의 기술적인 난제가 존재한다.
발명의 개요
본 발명의 일 양태에 의하면, 복수의 바이어와 복수의 판매자 간의 거래의 확립이 네트워크-기반 시장에서 지원된다. 구매서 생성 프로세스의 일부로서, 네트워크-기반 시장의 제 1 사용자가 당사자인 다중의 구매가 식별된다. 또한, 조합가능한 기준을 만족시키는 이들 거래의 하나 이상의 서브세트가 식별되며, 그 거래의 식별된 서브세트 중 적어도 하나에 대하여, 구매서가 생성된다.
도면의 간단한 설명
본 발명은 첨부 도면의 도에 제한되는 것이 아니라 예로써 설명되며, 도면에서, 동일한 도면부호는 유사한 구성요소를 나타낸다.
도 1 은 본 발명의 일 예시적인 실시형태에 따라, 상업 시스템을 나타낸 네트워크 다이어그램이다.
도 2 는 본 발명의 일 실시형태에 따라, 네트워크-기반 시장의 일부로서 제공되는 다중의 시장 애플리케이션을 나타낸 블록 다이어그램이다.
도 3 은 시장에 의해 이용되고 그 시장을 지원할 수도 있는 다양한 데이터베이스를 나타낸 하이-레벨 엔터티-관계 다이어그램이다.
도 4 는 데이터베이스 테이블의 다양한 필드를 나타낸 것이다.
도 5 는 네트워크-기반 시장을 이용하여 확립된 다중의 거래를 조합하는 구매서를 생성하기 위한 프로세스의 일 실시형태의 플로우 다이어그램이다.
도 6 및 도 14 는 다중의 아이템들을 통합하는 구매서를 생성하기 위한 판매자-개시 프로세스의 2 개의 또 다른 실시형태의 블록 다이어그램이다.
도 19 는 다중의 아이템들을 통합하는 구매서를 생성하기 위한 바이어-개시 프로세스의 일 실시형태의 블록 다이어그램이다.
도 29a 및 도 29b 그리고 도 30a 내지 도 30c 는 조합된 거래에 관련된 수수료에 대한 룰을 정의하기 위한 프로세스의 수개의 실시형태의 블록 다이어그램이다.
도 35 및 도 37 은 미리 정의된 수수료 룰을 이용하여 조합된 거래를 포함하는, 구매서에 대한 수수료를 계산하기 위한 프로세스의 2 개의 실시형태의 블록 다이어그램이다.
도 7 내지 도 13, 도 15 내지 도 18, 도 20 내지 도 28, 도 31 내지 도 34, 및 도 36 은 본 발명의 다양한 실시형태에 따라, 시장의 사용자에게 제공되는 예시적인 사용자 인터페이스 (UI) 를 나타낸 것이다.
도 38 은 예시적인 컴퓨터 시스템의 도식적인 표현이다.
상세한 설명
다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의 거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및 시스템이 설명되어 있다. 다음의 설명에서는, 설명의 목적으로, 본 발명의 전반적인 이해를 제공하기 위해 다수의 특정한 상세(詳細)가 제시된다. 그러나, 당업자는 이들 특정한 상세없이도 본 발명이 실시될 수도 있음을 명백히 알 수 있다.
플랫폼 구조
도 1 은 본 발명의 일 예시적인 실시형태에 따라, 클라이언트-서버 구조를 갖는 상업 시스템 (10) 을 도시한 네트워크 다이그램이다. 좀더 상세하게, 네트워크-기반 시장 (12) 의 예시적인 형태에 있어서, 트레이딩 플랫폼은 서버측 기능을 네트워크 (14; 예를 들어, 인터넷) 를 경유하여 하나 이상의 클라이언트에게 제공한다. 도 1 은, 예를 들어, 각각의 클라이언트 머신 (20 및 22) 상에서 실행하는 웹 클라이언트 (16; 예를 들어, 워싱턴 주, 레드몬드 소재의 마이크로소프트사에 의해 개발된 Internet Explorer 브라우저와 같은 브라우저), 및 프로그래머틱 클라이언트 (programmatic client; 18) 를 나타낸 것이다.
네트워크-기반 시장 (12) 을 좀더 상세하게 다시 참조하면, 애플리케이션 프로그램 인터페이스 (API) 서버 (24) 와 웹 서버 (26) 는 하나 이상의 애플리케이션 서버 (28) 에 커플링되고, 그 서버 (28) 에 각각 프로그래머틱 인터페이스 및 웹 인터페이스를 제공한다. 애플리케이션 서버 (28) 는 하나 이상의 시장 애플리케이션 (30) 및 지불 애플리케이션 (32) 을 호스팅한다. 일 실시형태에서, 애플리케이션 서버 (28) 는, 하나 이상의 시장 애플리케이션 (30) 을 호스팅하는 시장 서버 및 하나 이상의 지불 애플리케이션 (32) 을 호스팅하는 지불 서버를 포함한다.
애플리케이션 서버 (28) 는, 하나 이상의 데이터베이스 (36) 로의 액세스를 용이하게 하는 하나 이상의 데이터베이스 서버 (34) 에 커플링된다.
시장 애플리케이션 (30) 은 시장 (12) 에 액세스하는 클라이언트에게 다수의 시장 기능 및 서비스를 지원한다. 유사하게, 지불 애플리케이션 (32) 은 시장 (12) 에 액세스하는 클라이언트에게 다수의 지불 서비스 및 기능을 제공한다. 시장 및 지불 애플리케이션 (30 및 32) 이 모두 네트워크-기반 시장 (12) 의 일부를 형성하도록 도 1 에 도시되어 있지만, 본 발명의 또 다른 실시형태에서, 지불 애플리케이션 (32) 은, 시장 (12) 과는 별도 및 별개인 지불 서비스의 일부를 형성할 수도 있음을 알 수 있다.
또한, 도 1 에 도시되어 있는 상업 시스템 (10) 은 클라이언트-서버 구조를 채용하지만, 물론, 본 발명은 그러한 구조에 제한되지 않으며, 분산 구조 시스템 또는 피어-투-피어 구조 시스템에서의 애플리케이션을 동일하게 잘 발견할 수 있다. 또한, 다양한 시장 및 지불 애플리케이션 (30 및 32) 은 자립형 (standalone) 소프트웨어 프로그램으로서 구현될 수도 있으며, 이는 네트워킹 능력 을 반드시 가질 필요는 없다.
웹 클라이언트 (16) 는, 웹 서버 (26) 에 의해 지원되는 웹 인터페이스를 경유하여 다양한 시장 및 지불 애플리케이션 (30 및 32) 에 액세스함을 알 수 있다. 유사하게, 프로그래머틱 클라이언트 (18) 는, API 서버 (24) 에 의해 제공되는 프로그래머틱 인터페이스를 경유하여 시장 및 지불 애플리케이션 (30 및 32) 에 의해 제공되는 다양한 서비스 및 기능에 액세스한다. 프로그래머틱 클라이언트 (18) 는, 예를 들어, 판매자로 하여금 시장 (12) 에 대한 리스팅을 오프라인 방식으로 형성 및 관리하게 하고 프로그래머틱 클라이언트 (18) 와 네트워크-기반 시장 (12) 간의 배치-모드 (batch-mode) 통신을 수행하게 하는 판매자 애플리케이션 (예를 들어, 캘리포니아주 산호세 소재의 eBay 사에 의해 개발된 TurboLister 애플리케이션) 일 수도 있다.
또한, 도 1 은 API 서버 (24) 에 의해 제공되는 프로그래머틱 인터페이스 (40) 및 프로그래머틱 인터페이스를 경유하여 네트워크-기반 시장 (12) 으로의 프로그래머틱 액세스를 갖는 것으로서, 제 3 자 서버 머신 (40) 상에서 실행하는 제 3 자 애플리케이션 (38) 을 나타낸다. 예를 들어, 네트워크-기반 시장 (12) 으로부터 검색된 정보를 이용하여, 제 3 자 애플리케이션 (38) 은, 제 3 자에 의해 호스팅되는 웹사이트에 대한 하나 이상의 특성 또는 기능을 지원할 수도 있다. 제 3 자 웹사이트는, 예를 들어, 네트워크-기반 시장 (12) 의 적절한 애플리케이션에 의해 지원되는 하나 이상의 시장 또는 지불 기능을 제공할 수도 있다.
시장 애플리케이션
도 2 는, 본 발명의 일 예시적인 실시형태에서, 네트워크-기반 시장 (12) 의 일부로서 제공되는 다중의 시장 애플리케이션 (30) 을 나타낸 블록 다이어그램이다. 그 시장 (12) 은 다수의 리스팅 및 가격-설정 메커니즘을 제공할 수도 있음으로써, 판매자는 판매용의 상품 또는 서비스를 리스팅할 수 있으며, 바이어는 그러한 상품 또는 서비스를 구매하는데 있어서의 관심을 나타내거나 그 구매에 대한 요망을 나타낼 수 있으며, 가격은 상품 또는 서비스에 관한 거래용으로 설정될 수 있다. 이러한 목적을 위해, 시장 애플리케이션 (30) 은, 경매-포맷 리스팅 및 가격 설정 메커니즘 (예를 들어, 영어, 네덜란드어, 비크리 (Vickrey), 중국어, 더블 (Double), 역 경매 등) 을 지원하는 하나 이상의 경매 애플리케이션 (44) 을 포함하도록 도시되어 있다. 또한, 다양한 경매 애플리케이션 (44) 은 예약 가격 특성과 같은 그러한 경매-포맷 리스팅의 지원에 있어서의 다수의 특성을 제공할 수도 있음으로써, 판매자는 리스팅 및 프록시-입찰 (proxy-bidding) 특성과 관련된 최저낙찰 가격 (reserve price) 을 특정할 수도 있으며, 이에 따라, 입찰자는 자동화된 프록시 입찰을 야기할 수도 있다.
다수의 고정-가격 애플리케이션 (46) 은 고정-가격 리스팅 포맷 (예를 들어, 종래의 분류된 광고-타입 리스팅 또는 카탈로그 리스팅) 및 바이아웃-타입 (buyout-type) 리스팅을 지원한다. 좀더 상세하게, 바이아웃-타입 리스팅은 경매-포맷 리스팅과 함께 제공될 수도 있으며, 바이어로 하여금 상품 또는 서비스를 구매하게 하며, 이는, 또한, 경매의 시작 가격보다 통상적으로 더 높은 고정-가격에 대하여, 경매를 통해 판매용으로 제공되고 있다.
스토어 애플리케이션 (store application; 48) 은 판매자로 하여금, 그 판매자에 의해 그리고 판매자용으로 브랜딩 (brand) 되고 그렇지 않으면 개인화될 수도 있는 "가상" 스토어 내에서 자신의 리스팅을 그룹화하게 한다. 또한, 그러한 가상 스토어는, 적절한 판매자에게 특정되고 개인화되는 프로모션, 인센티브 및 특성을 제공할 수도 있다.
명성 애플리케이션 (reputation application; 50) 은 네트워크-기반 시장 (12) 을 이용하여 거래하는 당사자 (party) 로 하여금 명성을 확립하고 형성하고 유지하게 하며, 이는 잠재적인 트레이딩 파트너에 이용가능하고 발표될 수도 있다. 좀더 상세하게, 네트워크-기반 시장 (12) 이 개인별 (person-to-person) 트레이딩을 지원하는 경우, 거래에 대한 당사자들은 어떠한 이력이나 다른 참조 정보를 갖지 않을 수도 있으며, 이에 따라, 신뢰도 및 신용도가 확인될 수도 있다. 명성 애플리케이션 (50) 은 당사자로 하여금, 예를 들어, 다른 거래 파트너에 의해 제공되는 피드백을 통하여, 네트워크-기반 시장 (12) 내에서 시간에 따라 명성을 확립하게 한다. 그 후, 다른 잠재적인 트레이딩 파트너는 신용도 및 신뢰도를 평가할 목적으로 그러한 명성을 참조할 수도 있다.
개인화 애플리케이션 (personalization application; 52) 은 시장 (12) 의 사용자로 하여금 그 시장 (12) 과의 자신의 상호작용의 다양한 양태를 개인화하게 한다. 예를 들어, 적절한 개인화 애플리케이션 (52) 을 이용하여, 사용자는, 그 사용자가 당사자였던 거래에 관한 정보가 고찰 (view) 될 수도 있는 개인화된 참조 페이지를 생성할 수도 있다. 또한, 개인화 애플리케이션 (52) 은 사용자 로 하여금 시장 (12) 및 다른 당사자와의 자신의 상호작용의 리스팅 및 다른 양태를 개인화하게 할 수도 있다.
일 실시형태에서, 네트워크-기반 시장 (12) 은, 예를 들어, 특정 지리적인 영역에 대하여 주문제작되는 다수의 시장을 지원할 수도 있다. 시장 (12) 의 일 버전이 영국에 대하여 주문제작될 수도 있지만, 시장 (12) 의 다른 버전은 미국에 대하여 주문제작될 수도 있다. 각각의 이들 버전은 독립적인 시장으로서 동작할 수도 있거나, 공통의 하위 시장의 주문제작된 (또는 국제화된) 프리젠테이션일 수도 있다.
네트워크-기반 시장 (12) 의 네비게이션은 하나 이상의 검색 애플리케이션 (56) 에 의해 용이하게 될 수도 있다. 예를 들어, 검색 애플리케이션은 시장 (12) 을 통하여 발표되는 리스팅의 키 워드 검색을 가능케 한다. 브라우즈 애플리케이션은 사용자로 하여금 다양한 카테고리, 카탈로그 또는 데이터 구조를 브라우징하게 하며, 이에 따라, 리스팅이 시장 (12) 내에서 분류될 수도 있다. 다양한 다른 네비게이션 애플리케이션이 검색 및 브라우징 애플리케이션을 보충하기 위해 제공될 수도 있다.
가능하면 시각적으로 통지하고 관심을 끌 수 있는 것으로서, 네트워크-기반 시장 (12) 을 통하여 리스팅을 이용가능하게 하기 위하여, 시장 애플리케이션 (30) 은, 리스팅 내에 포함하기 위한 이미지를 어떠한 사용자가 업로드할 수 있는지를 이용하는 하나 이상의 이미징 애플리케이션 (58) 을 포함할 수도 있다. 또한, 이미징 애플리케이션 (58) 은 고찰된 리스팅 내에 이미지를 통합시키도록 동작한 다. 또한, 이미징 애플리케이션 (58) 은, 잠재적인 바이어에게 제공될 수도 있는 이미지 갤러리와 같은 하나 이상의 프로모셔널 특성을 지원할 수도 있다. 예를 들어, 판매자는, 프로모션된 아이템을 위한 이미지의 갤러리 내에 포함된 리스팅 중 하나 이상과 관련된 이미지를 갖도록 추가적인 요금을 지불해야 할 수도 있다.
리스팅 생성 애플리케이션 (60) 은 판매자로 하여금 시장 (12) 을 통하여 거래하길 원하는 상품 또는 서비스에 관한 리스팅을 편리하게 형성하게 하며, 리스팅 관리 애플리케이션 (62) 은 판매자로 하여금 그러한 리스팅을 관리하게 한다. 좀더 상세하게, 특정 판매자가 다수의 리스팅을 형성 및/또는 발표하였을 경우, 그러한 리스팅의 관리는 난제를 제공할 수도 있다. 리스팅 관리 애플리케이션 (62) 은 다수의 특성 (예를 들어, 자동-재리스팅 (automatic-relisting), 상품목록 레벨 모니터 등) 을 제공하여, 그러한 리스팅을 관리함에 있어서 판매자를 지원한다. 또한, 하나 이상의 사후-리스팅 관리 애플리케이션 (64) 은, 통상 사후-리스팅을 발생시키는 다수의 활성도를 갖는 판매자를 지원한다. 예를 들어, 하나 이상의 경매 애플리케이션 (44) 에 의해 용이하게 된 경매의 완료 시에, 판매자는 특정 바이어에 관한 피드백을 방치하길 원할 수도 있다. 이러한 목적을 위해, 사후-리스팅 관리 애플리케이션 (64) 은 하나 이상의 명성 애플리케이션 (50) 에 인터페이스를 제공하여, 판매자로 하여금 다중의 바이어에 관한 피드백을 명성 애플리케이션 (50) 에게 편리하게 제공하게 할 수도 있다.
분쟁 해결 애플리케이션 (66) 은, 거래 당사자들 간에 발생할 수도 있는 분 쟁을 해결할 수도 있는 메커니즘을 제공한다. 좀더 상세하게, 분쟁 해결 애플리케이션 (66) 은 가이드 절차 (guided procedures) 를 제공함으로써, 분쟁을 처리할 시도에 있어서 다수의 단계를 통하여 그 당사자들이 가이드되게 할 수도 있다. 분쟁이 가이드 절차를 통하여 처리될 수 없을 경우, 그 분쟁은 제 3 자의 중재자 또는 조정자에게 확대될 수도 있다.
다수의 사기 방지 (fraud prevention) 애플리케이션 (68) 은 다양한 사기 검출 및 방지 메커니즘을 구현하여, 시장 (12) 내에서 사기의 발생을 감소시킨다.
메시징 애플리케이션 (70) 은 네트워크-기반 시장 (12) 의 사용자로의 메시지의 생성 및 전달을 책임지며, 그러한 메시지는, 예를 들어, 그 시장 (12) 에서의 리스팅의 상태에 관하여 사용자에게 통지 (advise) 한다 (예를 들어, 경매 프로세스 동안에 입찰자에게 "비싸게 입찰된 (outbid)" 통보를 제공하거나 프로모셔널 및 머천다이징 (merchandising) 정보를 사용자에게 제공함).
머천다이징 애플리케이션 (80) 은, 판매자로 하여금 시장 (12) 을 통한 판매를 증가시키게 하도록 판매자에게 이용가능하게 하는 다양한 머천다이징 기능을 지원한다. 또한, 머천다이징 애플리케이션 (80) 은 판매자에 의해 야기될 수도 있는 다양한 머천다이징 특성을 동작시키며, 판매자에 의해 채용되는 머천다이징 전략의 성공을 모니터링 및 트래킹할 수도 있다.
네트워크-기반 시장 (12) 자체, 또는 그 시장 (12) 을 통하여 거래하는 하나 이상의 당사자는, 하나 이상의 로열티 애플리케이션 (82) 에 의해 지원되는 로열티 프로그램을 동작시킬 수도 있다. 예를 들어, 바이어는 특정 판매자로 확립되고 /되거나 체결되는 각각의 거래에 대한 로열티 포인트를 벌 수도 있으며, 누산된 로열티 포인트가 상환될 수 있는 보상을 제공받을 수도 있다.
판매자로 하여금 구매서를 효과적으로 생성하고 바이어에게 그 구매서를 전달하게 하기 위하여, 시장 애플리케이션 (30) 은 하나 이상의 구매서 애플리케이션 (84) 을 포함한다. 본 출원의 일 예시적인 실시형태에 의하면, 구매서 애플리케이션 (84) 은, 네트워크-기반 시장 (12) 의 사용자 (예를 들어, 바이어 또는 판매자) 로 하여금 구매 목적으로 단일 주문으로 다중의 거래를 편리하게 조합하게 하는 주문 애플리케이션 (86) 을 포함할 수도 있다. 또한, 구매 애플리케이션 (84) 은, 하나 이상의 주문과 관련하여 선적 및 취급 수수료의 계산을 적어도 부분적으로 자동화시키기 위한 선적 및 취급 수수료 애플리케이션 (84), 및 주문과 관련하여 보험 수수료의 계산을 적어도 자동화시키기 위한 보험 수수료 애플리케이션 (86) 을 포함할 수도 있다. 주문 애플리케이션 (86) 은, 다양한 주문 조건과 관련하여, 그리고 저장된 룰에 따라 디스카운트를 자동으로 계산 및 적용하는 주문 디스카운트 모듈 (88) 을 포함하도록 도시되어 있다. 유사하게, 선적 애플리케이션 (84) 은, 저장된 룰에 따라 선적 디스카운트를 계산 및 적용하도록 자동으로 동작하는 선적 디스카운트 모듈 (90) 을 포함하도록 도시되어 있다. 구매 애플리케이션 (84) 의 예시적인 실시형태에 관한 추가적인 상세는 아래에 제공되어 있다.
데이터 구조
도 3 은 데이터베이스 (36) 내에 유지될 수도 있고 시장 (12) 및 지불 애플 리케이션 (30 및 32) 에 의해 이용되고 그것을 지원할 수 있는 다양한 테이블 (91) 을 도시하는 하이-레벨 엔터티-관계 (high-level entity relationship) 다이어그램이다. 사용자 테이블 (92) 은 네트워크-기반 시장 (12) 의 각각의 등록된 사용자에 대한 레코드를 포함하고, 각각의 그 등록된 사용자에게 속하는 식별자, 주소 및 재정 기관 정보를 포함할 수도 있다. 사용자는, 네트워크-기반 시장 (12) 내에서 판매자, 바이어, 또는 양자 모두로서 동작할 수도 있음을 알 수 있다.
또한, 테이블 (91) 은 시장 (12) 을 통해 거래시에 이용가능한, 또는 거래된, 각각의 아이템 또는 서비스에 대한 아이템 레코드가 보존되는 아이템 테이블 (94) 을 포함한다. 또한, 아이템 테이블 (94) 내의 각각의 아이템 레코드는 판매자 및 하나 이상의 실제의 또는 잠재적인 바이어를 각각의 아이템 레코드와 관련시키기 위하여, 사용자 테이블 (92) 내의 하나 이상의 사용자 레코드에 연결될 수도 있다.
도 4 는 아이템 테이블 (94) 내의 각각의 레코드에 지원될 수도 있는 다양한 필드를 도시한 것이다. 특히 본 발명의 예시적인 실시형태에 적절하게, 각각의 아이템 레코드는 "조합 가능한 (combinable)" 필드 (96) 를 포함할 수도 있고, 이는 판매자에 의해 제공되는, 관련된 아이템에 관계되는 거래가 단일 주문을 생성하기 위한 목적으로 다른 거래와 조합가능하다는 표시를 기록할 수도 있다. 하기 설명과 같이, 매매 상태, 구매서 상태, 지불 상태 및 통화 식별자 필드 (98 내지 104) 는 주문에 부속하는 구매서의 생성 시 구매서 애플리케이션 (84) 에 의해 또한 이용될 수도 있다.
도 3 을 참조하면, 테이블 (91) 은 거래 테이블 (106) 을 또한 포함하고, 이는 아이템 테이블 (94) 내에 레코드가 존재하는 아이템에 관계되는 각각의 거래 (예를 들어, 구매 거래) 에 대한 레코드를 포함한다. 구체적으로, 특정의 아이템과 관련된 거래 레코드는 바이어와 판매자 사이에 특정한 상품 또는 서비스와 관련된 가치를 교환하고자 하는 동의의 확립과 동시에 거래 테이블 (106) 에서 생성될 수도 있다.
도 4 에 도시된 바와 같이, 거래 테이블 (106) 내의 각각의 레코드는, 아이템 테이블 (94) 내의 아이템 레코드에 연결되는 아이템 식별자 (108), 사용자 테이블 (92) 내의 사용자 레코드에 각각 연결되는 판매자 식별자 (110) 및 바이어 식별자 (112) 를 포함할 수도 있다. 거래 테이블 (106) 내의 다수의 거래 레코드는 아이템 테이블 (94) 내의 단일 아이템 레코드에 다시 링크될 수도 있고, 그 단일 아이템 레코드는 다수량 아이템을 관련시킨다.
주문 테이블 (114) 에는 주문에 관련된 주문 레코드가 입주한다. 즉, 각각의 주문은 거래 테이블 (106) 내에 그 레코드가 존재하는 하나 이상의 거래에 관계한다. 그처럼, 주문 테이블 (114) 내의 특정한 주문 레코드는 다수의 거래 식별자 (116) 를 참조할 수도 있다. 예시적인 실시형태에서, 각각의 주문 레코드는 단지 단일의 바이어-판매자 쌍만을 나타낼 수도 있고, 이 바이어-판매자 쌍은 판매자 및 바이어 식별자 (110 및 112) 에 의해 식별된다.
테이블 (91) 또한 룰 테이블 (118) 을 포함하는 것으로 도시되고, 사용자 테이블 (92) 에 연결되는 것으로 도시된다. 구체적으로, 룰 테이블 (118) 에는 룰 레코드가 입주하고, 각각의 룰 레코드는 네트워크-기반 시장 (12) 의 사용자와 관련된 다양한 수수료 룰을 식별한다. 도 4 를 상세하게 참조하면, 각각의 룰 레코드는 판매자 식별자 및 바이어 식별자 필드 (110 및 112) 를 포함한다. 따라서, 특정한 룰은 바이어 또는 판매자 역할의 사용자와 관련될 수도 있다. 예를 들어, 특정한 수수료 룰은 특정한 사용자가 시장 (12) 에서 바이어 역할로 동작할 때 그 사용자와 관련될 수도 있고, 다른 수수료 룰은 특정한 사용자가 시장 (12) 에서 판매자 역할로 동작할 때 그 사용자와 관련될 수도 있다.
룰 테이블 (118) 내의 각각의 룰 레코드는 또한 구매 수수료 룰 (120), 선적 및 취급 수수료 룰 (122), 그리고 선적 및 보험 수수료 룰 (124) 을 기록할 수도 있다. 구매서 애플리케이션 (84) 은 구매서에 반영되는 주문서에 대한 총 수수료를 산정할 때, 룰 (120 내지 124) 을 참조한다. 따라서, 룰 (120 내지 124) 은 사용자의 선호가 주문과 연계된 총 수수료의 자동 (또는 최소한 부분적으로 자동의) 산정에 반영되도록 허용한다. 구체적으로, 구매 수수료 룰 (120) 은 식별된 사용자를 포함하는 구매에 관해서 적용되는 수수료 산정을 특정할 수도 있다. 예를 들어, 사용자는, 판매자의 자격에서 행동할 때, 바이어가 다수의 아이템을 구매할 때 제공되는 디스카운트 (예를 들어, 총 구매 가격의 퍼센티지) 의 면에서 구매 수수료 룰 (120) 을 특정할 수도 있다. 이와 유사하게, 선적 및 취급 수수료 룰 (122) 은 선적 및 취급 수수료가, 판매자의 자격에서 행동할 때, 사용자로부터 구매되는 아이템과 관련하여 어떻게 산정될 것인가를 특정할 수도 있다. 본 발명의 하나의 예시적인 실시형태에서, 그러한 선적 및 취급 수수료 룰 (122) 은 실제 요율 선적 수수료 및 균일 요율 선적 수수료 룰을 포함하고, 각각의 룰 유형은 판매자에 의해 판매자의 선호를 반영하도록 최적화된다. 예시적인 선적 및 취급 수수료 룰 (122) 에 관한 더 상세한 내용은 하기에 제공된다. 선적 보험 수수료 룰 (124) 은 선적 보험 수수료의 산정과 관련하여 사용자의 선호를 유사하게 반영하고, 구매서 생성시에 그러한 수수료의 산정을 적어도 부분적으로 자동화하기 위해 구매서 애플리케이션 (84) 에 의해 적용될 수도 있다.
도 3 은 또한 입찰 테이블 (130) 을 포함하는 테이블 (91) 을 도시한다. 입찰 테이블 (130) 내의 각각의 입찰 레코드는 경매 애플리케이션 (44) 에 의해 지원되는 리스팅의 경매 형태와 관련하여 네트워크-기반 시장 (12) 에서 수용되는 입찰과 관련된다. 피드백 테이블 (132) 은, 예를 들어, 사용자에 관해서 명성 정보를 구축하고 유지하기 위해 하나 이상의 명성 애플리케이션 (50) 에 의해 이용된다. 이력 테이블 (134) 은 사용자가 당사자가 된 거래의 이력을 유지한다. 하나 이상의 속성 테이블 (136) 은 아이템 테이블 (94) 내에 그 레코드가 존재하는 아이템에 관계되는 속성 정보를 기록한다. 그러한 속성의 단일한 예만을 고려하면, 속성 테이블 (136) 은 특정 아이템과 관련된 통화 속성을 나타낼 수도 있다.
다중의 거래를 조합하는 구매서
도 5 는 네트워크-기반 시장을 이용하는 확립된 다수의 거래를 조합하는 구매서를 생성하기 위한 프로세스 (500) 의 일 실시형태의 플로우 다이어그램이다. 프로세스 (500) 는 프로세싱 로직에 의해 수행될 수도 있고, 이는 하드웨어, 소프트웨어, 또는 둘의 조합을 포함할 수도 있다. 일 실시형태에서, 프로세싱 로직 은 지불 서버 (예를 들어 도 1 의 애플리케이션 서버 (28) 의 하나) 에 상주한다.
도 5 를 참조하면, 프로세스 (500) 는 소정의 시간 주기에서 제 1 사용자를 포함하는 체결된 거래를 위치시키는 프로세싱 로직으로 시작한다 ( 프로세싱 블록 502). 거래는 두 당사자 (예를 들어, 바이어와 판매자) 사이에 아이템 (예를 들어, 상품 또는 서비스) 또는 다수량의 아이템에 관계되는 가치를 교환하기로 하는 동의가 확립될 때 체결된다. 제 1 사용자는 두 당사자의 어느 한 쪽을 대표할 수도 있다. 미리 정의된 시간 주기는 제 1 사용자에 의해 체계적으로 정의되거나 특정될 수도 있다. 일 실시형태에서, 프로세싱 로직은 도 3 의 거래 테이블 (106) 을 검색함으로써 체결된 거래를 위치시킨다.
프로세싱 블록 (504) 에서, 프로세싱 로직은 조합 가능한 기준을 만족하는 체결된 거래를 식별한다. 조합 가능한 기준은, 예를 들어, 거래가 공통 바이어 및 공통 판매자로부터, 지불되지 않도록, 동일한 통화 및/또는 동일한 시장 사이트 (동일한 지리적 영역에 최적화된 시장) 에 관련되도록 하는 등이 요구된다. 조합 가능한 기준은 특정한 시장 또는 시장 사이트에 기초하여 설정 가능할 수도 있다.
프로세싱 블록 (506) 에서, 프로세싱 로직은 제 1 사용자에게 조합 가능한 거래를 식별할 수도 있다. 예를 들어, 프로세싱 로직은, 그들을 제 1 사용자에게 조합 가능성 표시자로 (예를 들어, 아이콘) 디스플레이함으로써, 링크를 식별된 조합 가능한 거래의 각각의 또는 모든 서브세트에 제공함으로써, 제 1 사용자에게 그의 또는 그녀의 교역 파트너를 특정하도록 요청함으로써, 그리고 제 1 사용자 및 교역 파트너 사이에 모든 조합 가능한 거래를 디스플레이하는 등으로, 조합 가능한 거래를 식별할 수도 있다.
프로세싱 블록 (508) 에서, 프로세싱 로직은 조합 가능한 거래의 서브세트를 단일의 주문으로 통합하는 것에 대한 제 1 사용자의 승인을 나타내는 데이터를 수용한다. 예를 들어, 프로세싱 로직은 제 1 사용자가 조합 가능한 거래의 디스플레이된 서브세트로부터 둘 이상의 거래를 선택하고 지정된 버튼 (예를 들어, 구매서 전송 버튼, 또는 조합 아이템 버튼, 지불 버튼 등) 을 클릭했을 때, 제 1 사용자의 승인을 나타내는 데이터를 수용할 수도 있다. 또 다른 실시형태에서, 제 1 사용자 및 제 1 사용자의 다른 교역 파트너와 관련된 조합 가능한 거래의 다수 서브세트를 포함할 수도 있다. 또 다른 실시형태에서, 구매서는 제 1 사용자 및 제 1 사용자의 다른 교역 파트너와 관련된 하나 이상의 개별 거래와 하나 이상의 조합 가능한 거래의 서브세트를 포함할 수도 있다.
프로세싱 블록 (510) 에서, 프로세싱 로직은 수수료를 조합 가능한 거래의 주문에 부가한다. 수수료는, 예를 들어, 선적 비용, 선적 보험 비용 등을 포함할 수도 있다. 수수료는 조합 가능한 거래를 단일의 주문으로 통합한 것에 대한 디스카운트를 포함할 수도 있다. 일 실시형태에서, 판매자에 의해 특정된 룰에 기초하여 수수료가 적용된다. 또 다른 실시형태에서, 네트워크-기반 시장에서 확립된 룰에 기초하여 수수료가 적용된다. 또 다른 실시형태에서, 현재 주문을 위해 제 1 사용자에 의해 제공된 입력에 기초하여 수수료가 적용된다. 또 다른 실시형태에서, 현재 주문을 위해 교역 파트너에 의해 제공된 입력에 기초 하여 제 1 사용자의 이 입력에 대한 요청에 응답하여 수수료가 적용된다.
다음으로, 프로세싱 로직 은 그 주문에 대한 구매서 초안을 생성하고, 그 구매서 초안을 제 1 사용자에게 제공하며 ( 프로세싱 블록 512), 제 1 사용자에게 구매서 초안을 승인할 것인지를 묻는다. 제 1 사용자가 그 구매서를 승인하면 (결정 박스 514), 프로세싱 로직은 구매서를 저장하고 (프로세싱 블록 516), 일 실시형태에서, 교역 파트너에게 그 구매서에 관해 통지한다. 만약, 제 1 사용자가 그 구매서를 승인하지 않으면, 프로세싱 로직은 주문에 대한 구매서를 취소하고 (프로세싱 블록 516), 일 실시형태에서, 그 주문에서 각각의 거래에 대한 개별 구매서를 생성한다.
일 실시형태에서, 주문 조합형 다중 거래는 판매자 또는 바이어 중 어느 하나에 의해 생성된다. 일 실시형태에서, 주문은 특정 상태를 구비한다. 예를 들어, 주문은 활성일 수도 있고, 비활성일 수도 있고, 완료될 수도 있고, 또는 취소될 수도 있다. 활성 주문은 바이어 또는 판매자 중 어느 하나에 의해 생성되는 가장 최근의 주문이다. 거래는 임의의 소정 시간에서 단일의 활성 주문의 단지 일부분일 수도 있다. 비활성화 주문이란, (a) 판매자가 판매자 생성의 활성 주문을 조합하지 않았음, (b) 바이어가 판매자 생성의 활성 주문을 조합하지 않았음, (c) 바이어가 이전의 바이어 생성의 활성 주문을 대체하는 새로운 주문을 생성하였음 중의 어느 하나 때문에 비활성화된 주문이다. 완료된 주문이란 바이어에 의해 지불된 주문이다 (예를 들어, 바이어가 활성 또는 비활성의 주문에 대해 전자 지불 서비스를 통하여 지불하거나 체크아웃 (checkout) 하는 것을 완료할 때 ). 주문은 그것의 거래 중 어느 것이 더 이상 조합 가능한 기준을 만족시키지 못할 때 취소된다. 예를 들어, 바이어가 지불을 한 아이템을 포함하는 주문이 취소된 것으로 마킹된다.
일 실시형태에서, 바이어는 존재하는 활성 판매자 생성 주문 또는 완료된 주문의 일부가 아닌 조합 가능한 거래로 주문을 생성하는 것을 허용된다. 바이어가 거래로 이루어지는 주문을 존재하는 활성 바이어 생성 주문으로부터 생성한다면, 이 존재하는 주문은 비활성으로 마킹된다. 거래는 오직 단일의 활성 주문에만 관련될 수도 있다. 판매자는 완료된 주문의 일부가 아닌 조합 가능한 거래로 주문을 생성하도록 허용된다. 만약 판매자가 존재하는 활성의 바이어 생성 주문의 일부인 조합 가능한 거래로 주문을 생성하면, 이 바이어 생성 주문은 비활성으로 마킹되고, 그 거래는 새로운 판매자 생성 주문에 관련된다.
일 실시형태에서, 바이어는 완료된 것으로 마킹되지 않은 임의의 주문에 대해 지불할 수 있다. 임의의 활성 또는 비활성 주문은 전자 지불 서비스를 통해 바이어에 의해 지불되거나 체크아웃될 수도 있다. 바이어가 전자 지불 서비스를 통해 활성 주문에 대해 지불이나 체크아웃을 완료하면, 주문의 상태는 완료된 것으로 마킹된다. 만약 바이어가 전자 지불 서비스를 통해 비활성 주문에 대해 지불이나 체크아웃을 완료하면, 비활성 주문의 상태는 완료된 것으로 마킹된다. 예를 들어, 만약 바이어가 첫 번째로 주문을 생성하고 전자 지불 서비스에서 지불하기위해 진행하고, 그 다음 판매자가 바이어가 지불을 완료하기 전에 동일한 아이템으로 주문을 생성하면, 바이어 생성 주문은 비활성으로 마킹되고, 거래는 활성 판매자 생성 주문에 관련된다.
일 실시형태에서, 각각의 주문은 판매자와 관련된 유일한 판매 레코드 숫자에 의해 참조된다.
도 6 및 14 는 다중 아이템을 통합하는 구매서를 생성하기 위한 판매자-개시 프로세스의 2 개의 또 다른 실시형태의 블록 다이어그램이다. 프로세스는 프로세싱 로직에 의해 수행될 수도 있고, 이는 하드웨어, 소프트웨어, 또는 둘 모두의 조합을 포함할 수도 있다.
도 6 을 참조하면, 프로세스 (600) 는 도 7 내지 13 에서 도시된 예시적인 사용자 인터페이스와 함께 설명될 것이다. 일 실시형태에서, 프로세스 (600) 의 프로세싱 로직은 지불 서버 (예를 들어, 도 1 의 애플리케이션 서버 (28) 의 하나) 에 상주한다.
프로세스 (600) 는 프로세싱 블록 (602, 604, 및 606) 중 임의의 하나로 시작될 수도 있다. 프로세싱 블록 (602) 에서, 프로세싱 로직은 구매서가 생성되어야만 하는 바이어에 대한 판매자의 선택을 식별하는 데이터를 수용한다. 일 실시형태에서, 프로세싱 로직은 조합 가능성 기준에 기초하여 조합될 수 있는 판매자로부터 구매된 아이템의 서브세트를 식별하고, 판매자로부터 조합 가능한 아이템을 구매한 바이어의 리스트를 디스플레이하는 판매자의 사용자 인터페이스 (user interface; UI) 에 제공하고, 판매자가 특정한 바이어를 선택하는 것을 허용한다. 프로세싱 로직이 특정한 바이어에 대한 판매자의 선택을 수용할 때, 그것은 선택된 바이어에 의해 판매자로부터 구매된 아이템이 리스트가 디스플레이되는 프로세싱 블록 (608) 으로 진행한다. 도 7 은 판매자가 구매서가 생성되어야만 하는 바이어를 특정하는 것을 허용하는 예시적인 UI (Select a Buyer to Invoice UI) 를 도시한 것이다.
프로세싱 블록 (604) 에서, 프로세싱 로직은 판매자로부터 구매된 아이템과 관련된 조합 가능성 표시자의 판매자 선택을 수용한다. 일 실시형태에서, 프로세싱 로직은 조합 가능성 기준에 기초하여 조합될 수 있는 판매자로부터 구매된 아이템의 서브세트를 식별하고, 조합 가능성 표시자 (예를 들어, 지정된 아이콘) 를 구비하는 각각의 조합 가능한 아이템으로 (예를 들어, 판매자에 의해 특정되는) 임의의 시간 주기 내의 판매자로부터 구매되는 아이템의 리스트를 디스플레이하고, 판매자가 특정한 아이템의 조합 가능성 표시자를 선택하는 것을 허용한다. 프로세싱 로직이 특정한 아이템의 조합 가능성 표시자의 판매자 선택을 수용할 때, 특정한 아이템과 조합될 수 있는 아이템의 리스트가 디스플레이되는 프로세싱 블록 (608) 로 진행한다. 도 8 은 아이콘으로 각각의 조합 가능한 아이템을 제공하고, 특정한 아이템과 조합 가능한 아이템을 보기 위한 특정한 아이템의 아이콘을 판매자가 선택하는 것을 허용하는 예시적인 UI (Items I've Sold UI) 를 도시하고 있다.
프로세싱 블록 (606) 에서, 프로세싱 로직은 다른 아이템을 생성되는 구매서에 추가하기 위해 판매자의 요청을 수용한다. 일 실시형태에서, 프로세싱 로직은 조합 가능성 기준에 기초하여 조합될 수 있는 아이템을 구매서가 생성되어야 하는 아이템과 식별하고, 구매서 페이지에서 링크를 구매서상의 아이템과 조합될 수 있는 아이템의 리스트에 제공한다. 프로세싱 로직이 판매자의 링크 선택을 수용할 때, 구매서상의 아이템과 조합될 수 있는 아이템의 리스트가 디스플레이되는 프로세싱 블록 (608) 로 진행한다. 도 9 는 디스플레이된 아이템과 조합 가능한 아이템의 리스트에의 링크를 포함하는 예시적인 UI (Send Invoice UI) 를 도시한 것이다.
프로세싱 블록 (608) 에서, 프로세싱 로직은 조합 가능한 아이템의 리스트를 디스플레이하고, 판매자가 이 리스트를 변형하는 것을 허용한다 (예를 들어, 리스트로부터 임의의 아이템을 제거함으로써). 프로세싱 블록 (610) 에서, 프로세싱 로직은 디스플레이된 아이템에 관한 판매자의 입력을 수용하고, 일 실시형태에서, 판매자가 아이템에 대한 수수료 (예를 들어, 선적 및 취급 수수료, 선적 보험 등) 를 특정하는 것을 허용한다. 또 다른 실시형태에서, 프로세싱 로직은 판매자에 의해 특정된 룰 또는 시장 내에 유지되는 표준 룰에 기초하여, 아이템에 대한 수수료를 산정한다. 도 10a 및 10b 는 판매자가 구매서에 조합되는 아이템을 체크하고, 조합된 아이템에 대한 수수료 (선적 및 취급 수수료, 선적 보험, 및 판매 세금) 를 특정하고, 바이어에 대한 지불 설명서에 들어가고, 판매자에게 수용 가능한 지불 방법을 특정하는 것을 허용하는 예시적인 UI 들 (Combine Purchases UI 및 Send Invoice UI) 을 도시한 것이다.
다음으로, 특정한 아이템 (예를 들어, Combine Purchase UI 을 통해) 을 조합하라는 판매자의 요청을 수용함과 동시에 (프로세싱 블록 612), 프로세싱 로직은 아이템이 여전히 조합 가능하다 (즉, 조합 가능한 기준을 만족한다) 는 것을 보증 하고 (프로세싱 블록 613), 결과적인 주문을 데이터베이스에 저장한다 ( 프로세싱 블록 614). 예를 들어, 판매자의 UI 와의 상호작용 동안 바이어가 아이템에 대해 지불하거나 체크아웃을 완료하면, 또는 판매자가 다른 브라우저 윈도를 사용하여 아이템을 포함하는 또 다른 활성 주문을 생성하면, 하나 이상의 아이템은 더 이상 조합 가능한 기준을 만족할 수 없다. 그러면, 프로세싱 로직은 더 이상 조합 가능한 기준을 만족하지 않는 아이템을 주문에서 제거하고, 판매자에게 나머지 아이템을 리뷰하도록 요청한다.
데이터베이스에 저장된 주문은 주문에 대한 구매서를 바이어에 전송하라는 판매자의 요청에 응답하여 그 결과로서 데이터베이스로부터 검색된다.
다른 방법으로, 디스플레이된 아이템 및 적용 가능한 수수료에 관한 판매자의 입력을 수신할 때, 프로세싱 로직은 (예를 들어, Send Invoice UI 를 경유하여) 판매자의 구매서를 전송하라는 요청을 수용할 수도 있다 (프로세싱 블록 616). 그러면, 프로세싱 로직은 구매서의 아이템이 여전히 조합 가능하다 (즉, 조합 가능한 기준을 만족한다) 는 것을 보장하고 (프로세싱 블록 617), 구매서를 데이터베이스에 저장하고, 구매서를 디스플레이하는 페이지에의 링크를 포함하여, 바이어에게 이메일을 전송한다 (프로세싱 블록 618). 도 11 은 판매자에게 구매서에의 링크를 구비한 이메일이 바이어에게 전송되었다고 알려주는 예시적인 UI (Invoice Sent to Buyer UI) 를 도시한 것이다.
일 실시형태에서, 판매자는 저장된 주문 또는 구매서에 포함된 아이템을 분리하라는 요청을 할 수도 있다. 도 12 는 판매자가 주문 또는 구매서로부터의 아이템이 조합되지 않도록 요청하는 것을 허용하는 예시적인 UI ( Uncombine Purchases UI) 를 도시한 것이다.
또한, 구매서를 본다는 바이어의 요청 (예를 들어, 바이어의 이메일에서의 구매서에의 링크의 선택) 과 동시에 (프로세싱 블록 620), 프로세싱 로직은 판매자 생성 구매서를 바이어에게 디스플레이한다 (프로세싱 블록 622). 도 13 은 바이어에게 구매서의 콘텐츠를 디스플레이하고, 바이어가 전체 주문에 대해, 또는 각각의 아이템에 대해 개별적으로 지불을 하는 것을 허용하는 예시적인 UI (Pay Now for Multiple Items UI) 를 도시한 것이다.
도 14 는 다중 아이템을 통합하는 구매서를 생성하기 위한 판매자-개시 프로세스 (1400) 의 또 다른 실시형태의 블록 다이어그램이다. 프로세스 (1400) 는 도 15 내지 18 에 도시된 예시적인 사용자 인터페이스와 연계하여 설명될 것이다. 일 실시형태에서, 프로세스 (1400) 의 프로세싱 로직은 지불 서비스를 도 1 의 시장 (12) 을 포함한 다중 네트워크-기반 시장에 제공하는 지불 서비스 시스템에 상주한다.
도 14 를 참조하면, 프로세스 (1400) 는 소정의 시간 주기 내에 판매자에 의해 판매된 아이템을 디스플레이하는 프로세싱 로직으로 시작한다 (프로세싱 블롭 1402). 도 15 는 지난 30 일 동안 판매자에 의해 판매된 아이템과 판매자가 판매자에 의해 판매된 아이템 (예를 들어, 모든 아이템, 미지불의 아이템, 지불된 아이템, 미지불된 미구매작성의 아이템, 미지불된 조합 가능합 아이템, 미지불된 구매작성된 아이템 등) 의 다른 카테고리를 보는 것을 허용하는 필터의 세트를 제공 하는 예시적인 UI (Post Sale Manager UI) 를 도시한 것이다.
프로세싱 블록 (1404) 에서, 프로세싱 로직은 판매자에 의해 판매된 아이템의 특정한 카테고리를 디스플레이하라는 판매자의 요청을 수용한다 (예를 들어 Post Sale Manager UI 에 의해 제공되는 필터를 사용하여). 이에 응답하여, 프로세싱 로직은 특정한 카테고리의 아이템을 디스플레이한다. 논의된 실시형태에서, 프로세싱 로직은 모든 미지불된 아이템 (프로세싱 블록 1406) 또는 조합 가능한 기준을 만족하는 조합 가능한 아이템 (프로세싱 블록 1408) 을 디스플레이할 수도 있다. 조합 가능한 기준은, 예를 들어, 조합 가능한 아이템이 공통 판매자 및 공통 바이어를 구비하는 다수의 미지불 아이템의 서브세트를 포함하도록 요구할 수도 있다.
다음으로, 프로세싱 로직은 구매서에 대한 아이템의 판매자 선택을 식별하는 데이터와 구매서를 생성하라는 요청을 수용한다 (프로세싱 블록 1410). 도 16 은 판매자에 의해 판매된 미지불된 아이템을 제공하고, 판매자가 구매서에 대한 아이템 (예를 들어, 조합 가능한 아이템 및/또는 개별 아이템의 하나 이상의 서브세트) 을 선택하는 것을 허용하는 예시적인 UI (Invoice Manager UI) 를 도시한 것이다. 판매자는 상이한 아이템에 대한 단일의 바이어 또는 상이한 아이템에 대해 다수의 바이어에게 구매서를 작성하도록 요청할 수도 있다.
또한, 프로세싱 로직은 선택된 아이템이 여전히 미지불되었다고 보장하고, 판매자가 구매서를 전송하라고 요청함과 동시에 하나 이상의 바이어에게 구매서를 전송한다(프로세싱 블록 1416). 도 17 은 구매서를 판매자에게 제공하고, 판매 자가 조합 가능한 아이템 또는 각각의 개별 거래의 각각의 서브세트에 대한 수수료를 특정하는 것과 하나 이상의 바이어에게 구매서를 전송하라는 요청을 발행하는 것을 허용하는 예시적인 UI 를 도시한 것이다. 구매서가 다수의 바이어에게 전송된다면, 각각의 바이어는 이 바이어에게 관련된 구매서 부분만을 볼 수 있다.
프로세싱 블록 (1418) 에서, 프로세싱 로직은 (예를 들어, 바이어에게 전송된 이메일에서의 구매서 링크를 바이어가 선택함에 따라) 구매서를 본다는 바이어의 요청을 수용한다. 이에 응답하여, 프로세싱 로직은 구매서를 바이어에게 디스플레이한다 (프로세싱 블록 1420). 도 18a 및 18b 는 구매서를 바이어에게 제공하는 예시적인 UI 들 (Payment Details UI) 을 도시한 것이다.
프로세싱 블록 (1422) 에서, 프로세싱 로직은 (예를 들어, 도 18b 의 Payment Details UI 상의 지불 버튼을 통한) 아이템에 대해 지불한다는 바이어의 요청을 수신하고, 지불을 처리한다.
도 19 는 다수 아이템을 통합하는 구매서를 생성하기 위한 바이어-개시 프로세스 (1900) 의 일 실시형태의 블록 다이어그램이다. 프로세스는 하드웨어, 소프트웨어, 또는 이 양자의 조합을 포함할 수도 있는 프로세싱 로직에 의해 수행될 수도 있다. 일 실시형태에서, 프로세싱 로직은 지불 서버 (예를 들어, 도 1 의 애플리케이션 서버 (28) 의 하나) 에 상주한다. 프로세스 (1900) 는 도 20 내지 23 에 도시된 예시적인 사용자 인터페이스와 연계하여 설명될 것이다.
도 19 를 참조하면, 프로세스 (1900) 는 조합 가능성 표시자 (예를 들면, 지정된 아이콘) 를 갖는 각각의 조합 가능한 아이템으로 일정 시간 주기 (예를 들면, 바이어에 의해 특정됨) 내에 바이어에 의해 구매된 아이템을 디스플레이하는 프로세싱 로직으로 시작한다 (프로세싱 블록 1902). 도 20 은 아이콘과 각각 조합 가능한 아이템을 나타내고, 바이어가 특정 아이템과 조합 가능한 아이템을 보여주기 위해 특정 아이템의 아이콘을 선택하도록 허용하는 예시적인 UI (Items I've Won UI) 를 나타낸다.
프로세싱 블록 (1904) 에서, 프로세싱 로직은 조합 가능한 아이템의 리스트를 고찰하기 위해 바이어의 요청을 수용한다. 일 실시형태에서, 프로세싱 로직은 바이어가 판매자로부터 구입된 특정 아이템의 조합 가능성 표시자를 선택할 때, 조합 가능한 아이템의 리스트를 고찰하기 위한 바이어의 요청을 수용한다.
응답으로, 프로세싱 로직은 판매자로부터 구매된 조합 가능한 아이템을 디스플레이하고, 단일 주문으로 조합되어질 아이템을 식별하는 바이어의 입력을 수용하고 (프로세싱 블록 1906), 조합된 아이템에 대한 수수료를 계산한다. 일 실시형태에서, 프로세싱 로직은 시장 내에 유지된 표준 룰 또는 판매자에 의해 특정된 룰에 기초한 아이템에 대한 수수료를 계산한다. 도 21 은 바이어가 구매서에 조합되어질 아이템을 체크하는 것을 허용하고, 조합된 아이템에 대한 청구 (선적 및 취급 수수료, 선적 보험, 및 판매세) 를 디스플레이하고, 바이어가 아이템에 대해 지불하기 위한 요구를 이슈하도록 한다.
다음으로, 프로세싱 로직은 조합된 아이템에 대해 지불하도록 바이어의 요구를 수용하고 (프로세싱 블록 1908), 아이템이 여전히 조합 가능하고 (즉, 조합 가능한 기준)(프로세싱 블록 (613)), 조합된 아이템을 포함하는 주문을 생성하고, 데 이터베이스에서 주문을 저장하도록 보장한다.
주문으로부터 하나 이상의 아이템이 조합 가능한 기준을 더 이상 만족하지 않을 수도 있다. 그러면, 프로세싱 로직은 바이어에게 정보를 제공하고 바이어가 아이템에 대해 개별적으로 지불하도록 제안하거나, 주문으로부터 조합 가능한 기준을 더 이상 만족시키지 않는 아이템을 제거하고, 바이어가 남아있는 아이템을 리뷰하도록 요청한다. 도 22 는 주문으로부터 하나 이상의 아이템이 더 이상 조합가능하지 않다는 것을 판매자에게 정보 제공하는 메시지를 디스플레이하는 예시적인 UI 를 나타낸다.
또한, 프로세싱 로직은 바이어가 판매자에게 전송될 주문 정보를 리뷰하도록 요청하고 (프로세싱 블록 1912), 바이어로부터 주문 정보의 승인을 수용하면 (프로세싱 블록 1914), 판매자에게 주문 정보를 전송한다 (프로세싱 블록 1916). 도 23a 는 주문 정보를 디스플레이하고 주문 정보가 정확한 지를 바이어에게 확인 요청하는 예시적인 UI (Send Inform to Seller UI) 를 나타낸다.
그 후에, 프로세싱 로직은 바이어가 주문에 대해 지불하도록 명령한다 (프로세싱 블록 1918). 도 23b 는 지불 정보를 디스플레이하고 바이어가 지불하도록 요청하는 예시적인 UI (Send Payment to Seller UI) 를 나타낸다.
일 실시형태에서, 바이어는 아이템의 조합을 확인하고 판매자에게 전송되어질 정보의 정정을 검증하기 이전에 판매자로부터 총 구매서를 요청할 수도 있다. 도 24 는 조합된 아이템을 디스플레이하고 판매자가 이 주문에 대해 수수료를 계산하도록 허용하기 위해 바이어가 그 또는 그녀의 선적 주소를 검증 하도록 요청하는 예시적인 UI (Request Total From Seller UI) 를 도시한 것이다.
일 실시형태에서, 바이어 또는 판매자는 주문의 지불 상태를 요청할 수 있다. 도 25a 및 도 25b 는 바이어와 판매자에 대한 주문의 지불 상태와 주문 정보를 각각 디스플레이하는 예시적인 UI (Buyer's Payment Status UI and Seller's Payment Status UI) 을 나타낸다.
일 실시형태에서, 판매자는 시장 내에서 동작 중인 판매자를 돕기 위해 판매 매니저 툴을 사용하여 판매자로부터 구매된 조합 가능한 아이템들로 바이어의 리스트를 리뷰할 수 있다. 도 26a 는 판매자로부터 구매된 조합 가능한 아이템을 가진 바이어의 리스트로의 링크를 포함하는 예시적인 UI (Selling Manager Summary UI) 를 나타낸다. 도 26b 및 도 26c 는 다중 거래를 포함하는 주문을 디스플레이하는 예시적인 UI (Selling Manager Sold Listing UIs) 을 나타낸다.
일 실시형태에서, 판매자와 바이어는 전체 주문에 대한 피드백을 남겨둘 수도 있다. 다른 방법으로, 판매자와 바이어는 주문 내에 각 거래에 대한 피드백을 개별적으로 남겨둘 수도 있다. 도 27 은 판매자가 전체 주문에 대해 피드백을 남겨두도록 허용하는 예시적인 UI (Selling Manager Leave Feedback UI) 를 나타낸다.
일 실시형태에서, 선적 라벨과 구매서는 주문에 대해 자동적으로 생성되어 주문을 포함한 패키지를 위해 판매자에 의해 프린트될 수 있다. 도 28 은 예시적인 선적 라벨과 주문에 대해 생성된 구매서 조합을 나타낸다.
조합된 거래에 대한 수수료 룰
판매자는 이 판매자로부터 연속적으로 조합된 모든 구매에 대해 적용될 수 있는 조합된 거래에 대한 수수료 룰을 상세화할 수도 있다. 일 실시형태에서, 판매자는 조합된 거래와 연관된 청구에 대한 디스카운트 룰을 상세화하도록 허용하여, 바이어가 판매자로부터 보다 많은 아이템을 구매하도록 독려한다.
도 29a 내지 도 29b 및 도 30a 내지 도 30c 는 조합된 거래와 관련된 수수료에 대한 룰을 한정하기 위한 프로세스의 여러 실시형태의 블록 다이어그램이다. 프로세스는 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합을 포함할 수도 있는, 프로세싱 로직에 의해 제공될 수도 있다. 일 실시형태에서, 프로세싱 로직은 지불 서버 내에 있다 (예를 들면, 도 1의 애플리케이션 서버 (28) 중 하나임).
도 29a 를 참조하면, 프로세스 (2900) 는 제 1 사용자에 의해 이슈된 구매서에 대해 조합된 거래를 갖도록 제 1 사용자의 의지를 나타내는 데이터를 수용하는 프로세싱 로직으로 시작한다. 일 실시형태에서, 이 데이터는 다중 거래를 통합하는 구매서에 대해 제 1 사용자로부터 입력을 요청 (solicite) 하는 사용자 인터페이스를 경유하여 수용된다.
프로세싱 블록 (2904) 에서, 프로세싱 로직은 제 1 사용자에 의해 이슈된 구매서에 대해 조합된 거래에 대한 수수료를 계산하기 위한 룰의 세트를 정의한다. 일 실시형태에서, 룰의 세트는 선적 및 취급율, 그리고 선적 보험 요율에 관한 것이다. 일 실시형태에서, 룰의 세트는 프로세싱 로직에 의해 제공하는 사용자 인터페이스를 경유하여 제 1 사용자에 의해 제공된 입력에 기초하여 정의된다.
프로세싱 블록 (2906) 에서, 프로세싱 로직은 제 1 사용자에 의해 이슈 된 구매서를 가지고 연속적인 사용에 대한 데이터베이스에서 제 1 사용자에 관련된 룰의 세트를 저장한다. 일 실시형태에서, 시장 사이트에 관련된 UI 를 경유하여 제공된 사용자 입력에 기초하여 정의된 룰의 세트는 이 시장 사이트를 경유하여 구매된 아이템만을 가지고 사용될 수 있다.
도 29b 를 참조하면, 프로세스 (2900) 는 도 31a 내지 도 31f 에 도시된 예시적인 사용자 인터페이스와 연계되어 서술될 수도 있다.
프로세스 (2950) 는 판매자에게 Login to Preference UI 를 나타내는 프로세싱 로직으로 시작한다 (프로세싱 블록 2952). 도 31a 는 예시적인 Login to Preference UI 를 나타낸다.
프로세싱 블록 (2954) 에서, 프로세싱 로직은 판매자와 거래를 조합하기 위한 옵션을 제공한다. 도 31b 는 예시적인 Combine Purchases Preference UI 를 나타낸다.
프로세싱 로직이 판매자가 조합된 거래를 허용하지 않는다는 것을 나타내는 데이터를 수용하는 경우 (프로세싱 블록 2956), 프로세싱 로직은 조합 구매 UI 를 디스에이블시키고 (프로세싱 블록 2958), 시장의 사용자에게 제공된 UI 에 대해 선적 디스카운트 메시지의 디스플레이를 디스에이블시킨다 (프로세싱 블록 2960).
프로세싱 로직이 판매자가 수동 선적 디스카운트와 조합된 거래를 허용하는 것을 나타내는 데이터로 수용하는 경우 (프로세싱 블록 2962), 프로세싱 로직은 조합 구매 UI 및 판매자로부터 다중 구매를 격려하는 메시지의 디스플레이를 인에이 블시키고, 보험 요율 옵션의 판매자 입력을 권유한다 (프로세싱 블록 2970). 도 31d 는 수동 선적 디스카운트와 조합된 거래의 옵션을 선택하는 판매자에 대해 "See More Great Buys from this seller" 메시지를 디스플레이하는 예시적인 UI 를 나타낸다.
프로세싱 로직은 판매자가 자동화 선적 디스카운트와 조합된 거래를 허용하는 것을 나타내는 데이터를 수용하는 경우 (프로세싱 블록 2962), 프로세싱 로직은 조합 구매 UI 를 인에이블시키고, 조합된 구매에 대한 선적 디스카운트 룰의 사용자 입력을 권유하고 (프로세싱 블록 2966), 조합된 구매가 허용되는 일자 범위의 판매자 입력을 권유하고 (프로세싱 블록 2968), 보험율 옵션의 판매자의 입력을 권유한다. 또한, 프로세싱 로직은 판매자로부터 조합된 구매에 대한 선적 디스카운트롤 광고하는 메시지의 디스플레이를 인에이블시킨다. 도 31c, 도 31e 및 도 31f 는 판매자에 의해 특정된 디스카운트 룰에 따라 변하는 선적 디스카운트 메시지를 디스플레이하는 예시적인 UI을 나타낸다.
도 30a 를 참조하면, 프로세스 (3000) 는 조합된 거래에 대한 자동화 선적 디스카운트 룰에 대해 판매자 선호를 검출하고 (프로세싱 블록 3002), 선적 요율 옵션을 판매자에게 제공하는 (프로세싱 블록 3004) 프로세싱 로직으로 시작한다. 서술된 실시형태에서, 선적 요율 룰 옵션은 균일 요율 룰 옵션과 실제 요율 룰 옵션을 포함한다. 그러나, 다른 실시형태가 일반성을 잃지 않은 채 추가 및/또는 상이한 룰 옵션을 사용할 수도 있다.
프로세싱 로직이 균일 요율 옵션의 판매자의 선택을 나타내는 데이터를 수용 하는 경우 (프로세싱 블록 3008), 프로세싱 로직은 판매자에게 균일 요율 선적 수수료 옵션을 제공하고 (프로세싱 블록 3010), 판매자에게 균일 요율 보험 옵션을 제공하고 (프로세싱 블록 3012), 데이터베이스에서 판매자의 선적 및 보험 선호를 수용하여 저장한다 (프로세싱 블록 3020).
프로세싱 로직이 실제 요율 옵션의 판매자의 선택을 나타내는 데이터를 수용하는 경우 (프로세싱 블록 3014), 프로세싱 로직은 판매자에게 실제 요율 선적 수수료 옵션을 제공하고 (프로세싱 블록 3016), 판매자에게 보험 옵션을 제공하고 (프로세싱 블록 3018), 데이터베이스에서 판매자의 선적 및 보험 선호를 수용하여 저장한다 (프로세싱 블록 3020).
도 30b 를 참조하면, 프로세스 (3020) 는 균일 요율 선적 디스카운트의 판매자 선택을 검출하고 균일 요율 선적 디스카운트에 대한 옵션의 세트를 제공하는 프로세스 로직으로 시작한다 (프로세싱 블록 3022). 사용자 입력에 기초하여, 프로세싱 로직은 제 1 아이템에 대한 최대 선적 요율과 각각의 부가적인 아이템에 대한 고정 수량을 청구하기 위한 판매자의 선택 옵션을 식별하는 데이터 (프로세싱 블록 3024), 제 1 아이템에 대한 최대 선적 요율과 무상의 추가적인 아이템을 청구하기 위한 판매자의 선택 옵션을 식별하는 데이터 (프로세싱 블록 3026), 또는 제 1 아이템에 대한 최대 선적 요율과 각각의 부가적인 아이템에 대한 선적 비용으로부터의 고정 수량을 청구하기 위한 판매자의 선택 옵션을 식별하는 데이터 (프로세싱 블록 3026) 를 수용할 수도 있다.
또한, 일 실시형태에서, 프로세싱 로직은 주문에서 각 아이템의 선적 비용으 로부터 일정 퍼센티지를 공제하기 위한 판매자의 명령을 수용할 수도 있다 (프로세싱 블록 3030). 대안적으로, 프로세싱 로직은 최고의 선적 비용을 갖는 아이템에 대해 디스카운트를 적용하지 않도록 판매자의 명령을 수용할 수도 있다 (프로세싱 블록 3032).
일단 프로세싱 로직이 선적 요율 룰을 정의하면, 선적 보험 룰을 정의하기 시작한다. 상세하게는, 프로세싱 로직은 균일 요율 선적 보험에 대한 옵션의 세트를 디스플레이한다 (프로세싱 블록 3034). 이러한 옵션은 예를 들면, 옵션이 포함되지 않은 보험, 옵션적 보험 옵션, 필수적 보험 옵션, 그리고 선적 및 취급 옵션을 포함할 수도 있다.
프로세싱 로직이 옵션적 보험 옵션 또는 필수적 보험 옵션 중 판매자의 선택을 나타내는 데이터를 수용하고 (프로세싱 블록 3036), 프로세싱 로직은 판매자가 상이한 가격 범위에 대한 고정된 보험 수량을 상세화하도록 허용하고 (프로세싱 블록 3038), 데이터베이스에서 선적과 보험 룰을 저장한다 (프로세싱 블록 3040).
프로세싱 로직이 옵션이 포함되지 않은 보험 또는 선적 및 취급 옵션이 포함된 보험 중 판매자의 선택을 나타내는 데이터를 수용하는 경우, 프로세싱 로직은 프로세싱 블록 (3040) 으로 직접 진행한다.
도 32a 는 균일 요율 선적 및 보험 디스카운트에 대한 옵션을 디스플레이하는 예시적인 UI (조합 구매 선호 UI) 를 나타낸다.
도 30c 를 참조하면, 프로세스 (3050) 는 실제 요율 선적 디스카운트의 판매자의 선택을 검출하고 (프로세싱 블록 3052), 실제 요율 선적 디스카운트에 대한 옵션의 세트를 제공하는 프로세싱 로직으로 시작한다. 사용자 입력에 기초하여, 프로세싱 로직은 실제 선적 비용 (주문에서 아이템의 가중치에 기초함) 과 풀 패키지 및 취급 요금을 청구하기 위한 옵션의 사용자 선택을 확인하는 데이터 (프로세싱 블록 3054), 실제 선적 비용과 패키지 및 취급 비용없이 청구하기 위한 옵션의 사용자 선택을 확인하는 데이터 (프로세싱 블록 3056), 실제 선적 비용과 고정 수량 패키지 및 전체 주문의 취급 요금을 청구하기 위한 판매자 선택 옵션을 확인하는 데이터 (프로세싱 블록 3058), 또는 실제 선적 비용에서 고정 수량 패키지 및 취급 디스카운트를 뺀 비용을 각 아이템에 대해 청구하기 위한 사용자 선택 옵션을 확인하는 데이터 (프로세싱 블록 3060) 를 수용할 수도 있다.
일단 프로세싱 로직이 선적 요율 룰을 정의하면, 선적 보험 룰을 정의하여 시작한다. 상세하게는, 프로세싱 로직은 실제 요율 선적 보험에 대한 옵션의 세트를 디스플레이한다. 이러한 옵션은, 예를 들면, 옵션이 포함되지 않은 보험, 옵션적 보험 옵션, 필수적 보험 옵션, 그리고 선적 및 취급 옵션을 포함할 수도 있다. 프로세싱 로직은 보험 옵션의 판매자 선택을 검출하고 (프로세싱 블록 3062), 데이터베이스에서 선적 및 보험 룰을 저장한다 (프로세싱 블록 3040).
도 32b 는 실제 요율 선적 디스카운트에 대한 옵션을 디스플레이하는 예시적인 UI (Combine Purchases Preference UI) 를 도시한 것이다.
일 실시형태에서, 조합 구매에 대한 수수료 룰은 판매자에 의해 변형될 수 있다. 도 33a 는 수수료 룰에 수수료를 확인하는 예시적인 UI (Combined Purchases Preferences UI) 를 나타낸다.
일 실시형태에서, 변형 데이터가 저장되고, 판매자 또는 그의 트레이딩 파트너는 룰 변형 이력을 리뷰하기 위해 요청할 수 있다. 또한, 일단 룰이 변형되면, 그런 변형을 나타내는 메시지는 판매자의 트레이딩 파트너에게 디스플레이될 수도 있다. 도 33b 는 선적 디스카운트 변형 경고를 디스플레이하는 예시적인 UI (Combined Purchases UI) 를 나타낸다.
일 실시형태에서, 판매자는 네트워크-기반 시장 내에 제공되어질 새로운 아이템을 서술할 때, 조합된 구매에 대한 새로운 수수료 룰을 변형하거나 상세화할 수 있다. 도 34 는 수수료 룰이 상세화되는 Combined Purchases Preference UI 로의 링크를 포함하는 예시적인 UI (See Your Item UI) 를 도시한 것이다.
도 35 내지 도 37 은 미리 정의된 수수료 룰을 사용하는 조합된 거래를 가지고 구매서에 대한 수수료를 계산하기 위한 프로세스의 여러 실시형태에 대한 블록 다이어그램이다. 프로세스는 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합을 포함할 수도 있는 프로세싱 로직에 의해 제공될 수도 있다. 일 실시형태에서, 프로세싱 로직은 지불 서버 (예를 들면, 도 1의 애플리케이션 서버 (28) 중 하나) 내에 있다.
도 35 를 참조하면, 프로세스 (3500) 는 제 1 당사자에 의해 이슈되어질 단일 구매서에 대한 거래의 조합을 용이하게 하는 프로세싱 로직으로 시작한다 (프로세싱 블록 3502). 일 실시형태에서, 거래의 조합은 위에서 보다 상세하게 설명된 주문 생성 프로세스를 통하여 용이하게 된다.
프로세싱 블록 (3504) 에서, 프로세싱 로직은 제 1 당사자에 의해 이슈된 구 매서와 연계된 수수료의 자동 계산에 대해, 제 1 당사자에 의해 특정된 룰을 확인한다. 수수료는 선적 수수료, 패키지 및 취급 수수료, 보험 수수료 등을 포함할 수도 있다. 일 실시형태에서, 룰은 데이터베이스로부터 제 1 당사자와 연관된 룰을 검색하여 확인된다.
프로세싱 블록 (3506) 에서, 프로세싱 로직은 조합된 거래가 룰 애플리케이션 기준을 만족하는 지를 결정한다. 룰 애플리케이션 기준은 예를 들면, 각 거래가 특정된 선적 세부사항을 포함하고, 모든 거래가 동일한 타입의 선적 비용 (예를 들면, 균일 요율 또는 실제 요율) 을 포함하고, 동일한 타입의 선적 비용을 갖는 모든 거래가 동일한 선적 방법을 공유하는 것을 요구할 수도 있다.
프로세싱 블록 (3508) 에서, 프로세싱 로직은 주문에 포함된 거래에 대한 수수료를 계산하기 위한 룰을 동적으로 야기하고, 주문과 함께 계산된 수수료를 디스플레이한다. 일 실시형태에서, 프로세싱 로직은 또한 수수료 룰에 의해 제공된 디스카운트를 사용하여 계산된 수수료와 디스카운트 없이 계산된 수수료 사이의 차이를 연산하고 바이어에게 차이를 디스플레이한다. 도 36 은 바이어가 단일 주문으로 거래를 조합하여 선적할 때 얼마나 많은 비용을 줄일 수 있는지를 상세하게 설명하는 예시적인 UI (Combine Purchases UI) 를 나타낸다.
도 37a 내지 도 37c 를 참조하면, 프로세스 (3700) 는 다중-거래 주문에 대한 선적 비용을 계산하기 위한 콜을 수용하고 (프로세싱 블록 3702), 각각의 거래가 룰 애플리케이션 기준을 만족하는 지를 결정하고 (프로세싱 블록 3704), 만족하는 경우 다중-거래 주문에 적용할 수 있는 수수료 룰을 검색하는 프로세싱 로직으 로 시작한다. 룰 애플리케이션 기준은 예를 들면, 각 거래가 특정된 선적 세부사항을 포함하고, 모든 거래가 동일한 타입의 선적 비용 (예를 들면, 균일 요율 또는 실제 요율) 을 포함하고, 실제 선적 요율을 갖는 모든 거래가 조합된 가중치 측정 등을 하용한다면 동일한 선적 방법을 공유하는 것을 요구할 수도 있다.
또한, 프로세싱 로직은 수수료 룰이 실제 요율에 기초한 것인지를 결정한다 (프로세싱 블록 3706). 그렇다면, 프로세싱 로직은 룰이 조합된 가중치 또는 개별 가중치에 기초하는지의 여부를 결정한다 (프로세싱 블록 3708). 룰이 조합된 가중치에 기초하는 경우, 프로세싱 로직은 조합된 가중치가 캐리어 제한을 초과하는지를 결정한다 (프로세싱 블록 3712). 그렇지 않다면, 프로세싱 로직은 프로세싱 블록 (3714) 으로 진행한다.
조합된 가중치가 캐리어 제한을 초과하거나 룰이 개별 가중치에 기초하는 경우, 프로세싱 로직은 개별 아이템의 가중치에 기초한 실제 선적 요율을 계산하고 (프로세싱 블록 3714), 프로세싱 블록 (3714) 으로 진행한다.
프로세싱 블록 (3714) 에서, 프로세싱 로직은 판매자의 취급 요금 선호를 결정한다. 룰이 풀 패키지 및 취급 요금을 상세히 설명하고 (프로세싱 블록 3716), 룰이 조합된 가중치에 기초하는 경우 (프로세싱 블록 3718), 프로세싱 로직은 모든 아이템의 취급 요금의 합에 총 가중치에 기초한 실제 요금을 더하여 조합된 선적 비용을 계산한다 (프로세싱 블록 3720).
룰이 풀 패키지 및 취급 요금을 상세하게 설명하고 (프로세싱 블록 3716), 룰이 개별 가중치에 기초하는 경우 (프로세싱 블록 3718), 프로세싱 로직은 모든 아이템의 취급 요금의 합에 아이템 당 개별 가중치에 기초한 실제 요율의 합을 더하여 조합 선적 비용을 계산한다.
룰이 실제 선적 비용만을 상세하게 설명하는 경우 (프로세싱 블록 3724), 프로세싱 로직은 조합된 선적 비용에 임의의 취급 요금을 더하지 않는다 (프로세싱 블록 3726).
룰이 고정 패키지 및 취급 요금을 상세하게 설명하고 (프로세싱 블록 3728), 룰이 조합 가중치에 기초하는 경우 (프로세싱 블록 3730), 프로세싱 로직은 판매자-특정 취급 요금에 총 가중치에 기초한 실제 선적 요율을 더하여 조합된 선적 요율을 계산한다 (프로세싱 블록 3732).
룰이 고정 패키지 및 취급 요금을 상세하게 설명하고 (프로세싱 블록 3728), 룰이 개별 가중치에 기초하는 경우 (프로세싱 블록 3730), 프로세싱 로직은 판매자-특정 취급 요금에 아이템 당 개별 가중치에 기초한 실제 요율의 합을 더하여 조합된 선적 요율을 계산한다 (프로세싱 블록 3734).
룰이 각 아이템의 취급 요금으로부터 공제되어질 고정 수량을 요구하고 (프로세싱 블록 3736), 룰이 조합된 가중치에 기초하는 경우 (프로세싱 블록 3738), 프로세싱 로직은 이 아이템의 취급 요금과 고정 수량간의 차이를 각 아이템에 대해 계산하고, 모든 포지티브 차이의 합을 계산하고, 아이템당 개별 가중치에 기초한 실제 선적 요율의 합에 계산된 합을 더하여 조합된 선적 비용을 계산한다 (프로세싱 블록 3740).
룰이 각각의 아이템의 취급 요금으로부터 공제되어질 고정 수량을 요구하고 (프로세싱 블록 3837), 룰이 개별 가중치에 기초하는 경우 (프로세싱 블록 3736), 프로세싱 로직은 이 아이템의 취급 요금과 고정 수량 간의 차이를 각 아이템에 대해 연산하고, 모든 포지티브 차이의 합을 계산하고, 아이템 당 개별 가중치에 기초한 실제 선적 요율의 합에 계산된 합을 더하여 조합된 선적 요금을 계산한다.
수수료 룰이 균일 요율에 기초하는 경우 (프로세싱 블록 3706), 프로세싱 블록은 사용자-특정 균일 요율 선호를 결정한다 (프로세싱 블록 3748). 균일 요율 선호는 선적 비용이 최고의 단일 아이템 수수료에 각각의 부가적인 아이템에 대한 고정 수량을 더한 것에 기초되는 것을 요구하고 (프로세싱 블록 3750), 프로세싱 로직은 최고의 단일 아이템 수수료와 각각의 부가적인 아이템에 대한 고정 수량을 더하여 조합된 선적 비용을 계산한다 (프로세싱 블록 3752).
균일 요율 선호는 선적 비용이 최고의 단일 아이템 수수료에 각각의 부가적인 아이템에 대한 고정 수량과 선적 비용 간의 차이를 더한 것에 기초되는 것을 요구하고 (프로세싱 블록 3754), 프로세싱 로직은 각각의 아이템에 대한 선적 비용과 고정 수량 간의 차이를 계산하고, 모든 포지티브 차이의 합을 계산하고, 최고의 단일 아이템 선적 비용의 합을 더하여 조합된 선적 비용을 계산한다 (프로세싱 블록 3756).
균일 요율 선호가 각각의 부가적인 아이템에 대한 무상 선적을 요구하는 경우 (프로세싱 블록 3758), 조합된 선적 비용은 최고 단일 아이템 선적 수수료와 동일하다 (프로세싱 블록 3760).
균일 요율 선호는 선적 비용이 각각의 아이템에 대한 아이템 수수료에서 고 정 퍼센티지를 뺀 것에 기초되는 것을 요구하는 경우 (프로세싱 블록 3762), 프로세싱 로직이 각각의 아이템의 선적 비용과 고정된 퍼센티지 간의 차이를 연산하고, 모든 포지티브 차이의 합을 계산한다 (프로세싱 블록 3764).
예시적인 컴퓨터 시스템
도 38 은 여기에서 논의된 임의의 하나 이상의 방법을 머신이 수행하도록 하기 위한, 명령 세트가 그 안에서 실행될 수도 있는 컴퓨터 시스템 (3800) 의 예시적인 형태로 머신의 도식적인 표현을 도시한 것이다. 또 다른 실시형태에서, 머신은 독립적인 디바이스로서 동작하거나 다른 머신에 연결 (예를 들며, 네트워크) 될 수도 있다. 네트워크된 배치에서, 머신은 서버-클라이언트 네트워크 환경에서 서버 또는 클라이언트 머신의 용량 내에서 또는 P2P (또는 분배된) 네트워크 환경에서 피어 머신 (peer machine) 으로서 동작할 수도 있다. 머신은 그 머신에 의해 취해질 동작을 특정하는 (순차적인 또는 다른 방법의) 명령 세트를 실행할 수 있는, 개인용 컴퓨터 (PC), 태블릿 PC, 셋톱박스 (STB), 개인 휴대 정보 단말기 (PDA), 셀룰러 폰, 웹 가전, 네트워크 라우터, 스위치 또는 브릿지, 또는 임의의 머신일 수도 있다. 또한, 단지 하나의 머신가 설명되었지만, 용어 "머신" 은 또한 여기에서 논의한 임의의 하나 이상의 방법을 수행하기 위한 명령 세트 (또는 다중 세트) 를 개별적으로 또는 공동으로 실행하는 임의의 머신 콜렉션 (collection) 을 포함하는 것으로 취해질 것이다.
예시적인 컴퓨터 시스템 (3800) 은 프로세서 (3802; 예를 들면, 중앙 처리 장치 (CPU), 그래픽 처리 장치 (GPU), 또는 둘 다), 메인 메모리 (3804), 및 정적 메모리 (3806) 를 포함하고, 이들은 버스 (3808) 를 통해 서로 통신한다. 컴퓨터 시스템 (3800) 은 비디오 디스플레이 유닛 (3810; 예를 들면, LCD 또는 CRT) 을 더 포함할 수도 있다. 또한, 컴퓨터 시스템은 문자-수치 입력 디바이스 (3812; 예를 들면, 키보드), 커서 제어 디바이스 (3814; 예를 들면, 마우스), 디스크 드라이브 유닛 (3816), 신호 생성 디바이스 (3818; 예를 들면, 스피커), 및 네트워크 인터페이스 디바이스 (3820) 를 포함한다.
디스크 드라이브 유닛 (3816) 은 여기에서 서술된 임의의 하나 이상의 방법과 기능을 내장하는 하나 이상의 명령 세트 (예를 들면, 소프트웨어 (3824)) 를 저장한다. 소프트웨어 (3824) 는 또한, 컴퓨터 시스템 (3800) 에 의해 그 실행 동안 프로세서 (3802) 내에서 및/또는 메인 메모리 (3804) 내에 완벽하게 또는 적어도 부분적으로 있을 수도 있고, 메인 메모리 (3804) 및 프로세서 (3802) 는 또한 머신-판독가능 매체를 구성한다.
소프트웨어 (3824) 는 네트워크 인터페이스 디바이스 (3820) 를 경유하여 네트워크 (3826) 위로 추가적으로 송신되거나 수신될 수도 있다.
머신-판독 가능 매체 (3892) 는 단일 매체로 예시적인 실시형태에서 도시되는데, 용어 "머신-판독 가능 매체" 는 단일 매체 또는 복수의 매체 (예를 들면, 중앙화 또는 분포된 데이터 베이스, 및/또는 연관된 캐시 및 서버) 를 포함하는 것으로 취해지고 하나 이상의 명령 세트를 저장한다. 또한, 용어 "머신-판독 가능 매체" 는 머신에 의해 실행하기 위한 명령 세트를 저장, 인코딩 또는 운반할 수 있는 임의의 매체를 포함하기 위해 취해질 것이고, 머신이 본 발명의 임의의 하나 이 상의 방법을 수행하도록 한다. 용어 "머신-판독가능 매체" 는 고체 상태 메모리, 광 및 자기 매체, 및 캐리어 파 신호를 포함하여 취해지는 것이지만 이에 한정되지는 않는다.
따라서, 다중-판매자 네트워크-기반 시장을 이용하여 설립된 다중 거래를 조합하는 구매서 생성을 용이하게 하기 위한 방법 및 시스템이 설명되었다. 본 발명이 특정 예시적인 실시형태를 참조하여 설명되었지만, 다양한 변형과 변경이 본 발명의 더 넓은 사상과 범위로부터 벗어나지 않는 한 이러한 실시형태에 대해 이루어질 수 있다는 것은 명백하다. 따라서, 명세서와 도면은 제한적인 관점이라기 보다는 예시적으로 간주되어진다.

Claims (28)

  1. 네트워크-기반 시장을 이용하여 확립된 거래에 대한 구매를 용이하게 하는 컴퓨터화 방법으로서,
    상기 네트워크-기반 시장에서 복수의 바이어와 복수의 판매자 간의 거래의 확립을 지원하는 단계;
    구매서 생성 프로세스의 일부로서, 제 1 사용자가 일 당사자인 복수의 거래를 식별하는 단계;
    조합가능한 기준을 만족시키는 상기 복수의 거래의 하나 이상의 서브세트를 식별하는 단계; 및
    상기 조합가능한 기준을 만족시키는 상기 복수의 거래의 상기 서브세트 중 하나 이상에 대한 구매서를 생성하는 단계를 포함하는, 컴퓨터화 방법.
  2. 제 1 항에 있어서,
    제 1 당사자는 판매자이며,
    상기 복수의 거래의 식별 단계는, 상기 판매자에 의한 상기 구매서 생성 프로세스의 개시에 응답하여 수행되는, 컴퓨터화 방법.
  3. 제 1 항에 있어서,
    제 1 당사자는 바이어이며,
    상기 복수의 거래의 식별 단계는 지불 프로세스의 일부로서 수행되는, 컴퓨터화 방법.
  4. 제 3 항에 있어서,
    상기 복수의 거래의 식별 단계는, 제 1 거래와 관련하여 상기 지불 프로세스를 개시하는 상기 바이어에 응답하여 수행되며,
    상기 복수의 거래의 상기 서브세트의 식별 단계는, 상기 조합가능한 기준에 기초하여 상기 제 1 거래와 조합가능한 상기 바이어에 관한 제 2 거래를 식별하는 단계를 포함하는, 컴퓨터화 방법.
  5. 제 1 항에 있어서,
    상기 서브세트의 식별 단계는, 판매자가 상기 판매자에 관한 거래의 조합가능성에 동의하였는지를 판정하는 단계를 포함하는, 컴퓨터화 방법.
  6. 제 5 항에 있어서,
    상기 판정 단계는, 상기 판매자에 관한 거래의 상기 조합가능성에 대하여 판매자-정의 선호를 검색하는 단계를 포함하는, 컴퓨터화 방법.
  7. 제 1 항에 있어서,
    상기 서브세트의 식별 단계는, 공통 바이어와 공통 판매자 사이에 존재하는 바와 같은 상기 서브세트의 상기 거래 각각을 식별하는 단계를 포함하는, 컴퓨터화 방법.
  8. 제 1 항에 있어서,
    상기 서브세트의 식별 단계는, 공통 통화 (通貨) 의 관점에서 확립된 바와 같은 상기 서브세트의 상기 거래 각각을 식별하는 단계를 포함하는, 컴퓨터화 방법.
  9. 제 1 항에 있어서,
    상기 복수의 바이어와 상기 복수의 판매자 간의 상기 복수의 거래의 확립의 지원 단계는, 복수의 네트워크-기반 시장에서 수행되는, 컴퓨터화 방법.
  10. 제 9 항에 있어서,
    상기 복수의 네트워크-기반 시장은 복수의 지리적으로 주문제작된 네트워크-기반 시장을 포함하는, 컴퓨터화 방법.
  11. 제 1 항에 있어서,
    상기 제 1 사용자가 일 당사자인 상기 복수의 거래의 식별 단계는, 소정의 시간 주기 내에서 체결된 바와 같은 상기 복수의 거래를 식별하는 단계를 포함하는, 컴퓨터화 방법.
  12. 제 1 항에 있어서,
    상기 서브세트를 조합가능한 것으로서 상기 제 1 사용자에게 제공하는 단계; 및
    단일 구매서에서의 상기 서브세트의 포함에 관한 확인을 위해 상기 제 1 사용자를 프롬프팅 (prompt) 시키는 단계를 더 포함하는, 컴퓨터화 방법.
  13. 제 1 항에 있어서,
    상기 서브세트의 식별 단계는,
    상기 복수의 거래로부터 선택된 미지불 거래의 리스트를 상기 제 1 사용자에게 제공하는 단계; 및
    상기 제 1 사용자에 의해 상기 구매서에 대한 상기 리스트로부터의 거래의 선택을 식별하는 데이터를 수용하는 단계를 포함하는, 컴퓨터화 방법.
  14. 제 13 항에 있어서,
    미지불 거래의 상기 리스트는 조합가능한 거래의 하나 이상의 서브세트를 포함하며,
    상기 하나 이상의 서브세트 각각은 상기 제 1 사용자 및 별개의 바이어와 관련되는, 컴퓨터화 방법.
  15. 제 14 항에 있어서,
    상기 구매서는 조합가능한 거래의 하나 이상의 서브세트 및 하나 이상의 독립적인 거래를 포함하는, 컴퓨터화 방법.
  16. 네트워크-기반 시장에서 복수의 바이어와 복수의 판매자 사이에 확립된 거래에 대한 구매를 용이하게 하는 컴퓨터화 방법으로서,
    제 1 사용자가 일 당사자인 복수의 거래를 식별하는 단계;
    조합가능한 기준을 만족시키는 상기 복수의 거래의 하나 이상의 서브세트를 식별하는 단계; 및
    상기 하나 이상의 서브세트의 거래의 조합가능성의 표시를 상기 제 1 사용자에게 제공하는 단계를 포함하는, 컴퓨터화 방법.
  17. 제 16 항에 있어서,
    상기 표시의 제공 단계는,
    조합가능성의 표시자에 의해 상기 하나 이상의 서브세트의 상기 거래 각각을 디스플레이하는 단계를 포함하는, 컴퓨터화 방법.
  18. 제 17 항에 있어서,
    조합가능성의 상기 표시자는 아이콘인, 컴퓨터화 방법.
  19. 제 16 항에 있어서,
    상기 표시의 제공 단계는,
    조합가능성의 표시자에 의해 상기 하나 이상의 서브세트를 식별하는 각각의 레코드를 디스플레이하는 단계를 포함하는, 컴퓨터화 방법.
  20. 제 16 항에 있어서,
    상기 표시의 제공 단계는,
    조합가능한 거래에 대한 필터를 제공하는 단계; 및
    상기 제 1 사용자에 의한 조합가능한 거래에 대한 상기 필터의 선택에 응답하여 상기 하나 이상의 서브세트를 디스플레이하는 단계를 포함하는, 컴퓨터화 방법.
  21. 제 16 항에 있어서,
    상기 서브세트의 식별 단계는, 판매자가 상기 판매자에 관한 거래의 조합가능성에 동의하였는지를 판정하는 단계를 포함하는, 컴퓨터화 방법.
  22. 제 21 항에 있어서,
    상기 판정 단계는, 상기 판매자에 관한 거래의 상기 조합가능성에 대하여 판매자-정의 선호를 검색하는 단계를 포함하는, 컴퓨터화 방법.
  23. 제 16 항에 있어서,
    상기 서브세트의 식별 단계는, 공통 바이어와 공통 판매자 사이에 존재하는 바와 같은 상기 서브세트의 상기 거래 각각을 식별하는 단계를 포함하는, 컴퓨터화 방법.
  24. 제 16 항에 있어서,
    상기 서브세트의 식별 단계는, 상기 서브세트의 상기 거래 각각을 미지불된 것으로 식별하는 단계를 포함하는, 컴퓨터화 방법.
  25. 네트워크-기반 시장을 이용하여 확립된 거래에 대한 구매를 용이하게 하는 시스템으로서,
    복수의 바이어와 복수의 판매자 간의 거래의 확립을 지원하기 위한 시장 서버; 및
    구매서 생성 프로세스의 일부로서, 제 1 사용자가 일 당사자인 복수의 거래를 식별하고, 조합가능한 기준을 만족시키는 상기 복수의 거래의 하나 이상의 서브세트를 식별하며, 상기 조합가능한 기준을 만족시키는 상기 복수의 거래의 상기 서브세트 중 하나 이상에 대한 구매서를 생성하기 위한 지불 서버를 구비하는, 시스템.
  26. 네트워크-기반 시장을 이용하여 확립된 거래에 대한 구매를 용이하게 하는 시스템으로서,
    복수의 바이어와 복수의 판매자 간의 거래의 확립을 지원하기 위한 시장 서버; 및
    제 1 사용자가 일 당사자인 복수의 거래를 식별하고, 조합가능한 기준을 만족시키는 상기 복수의 거래의 하나 이상의 서브세트를 식별하며, 상기 하나 이상의 서브세트의 거래의 조합가능성의 표시를 상기 제 1 사용자에게 제공하기 위한 지불 서버를 구비하는, 시스템.
  27. 머신에 의해 실행될 경우, 상기 머신으로 하여금 네트워크-기반 시장을 이용하여 확립된 거래에 대한 구매를 용이하게 하는 방법을 수행하게 하는 명령 세트를 저장하는 머신-판독가능 매체로서,
    상기 방법은,
    상기 네트워크-기반 시장에서 복수의 바이어와 복수의 판매자 간의 거래의 확립을 지원하는 단계;
    구매서 생성 프로세스의 일부로서, 제 1 사용자가 일 당사자인 복수의 거래를 식별하는 단계;
    조합가능한 기준을 만족시키는 상기 복수의 거래의 하나 이상의 서브세트를 식별하는 단계; 및
    상기 조합가능한 기준을 만족시키는 상기 복수의 거래의 상기 서브세트 중 하나 이상에 대한 구매서를 생성하는 단계를 포함하는, 머신-판독가능 매체.
  28. 머신에 의해 실행될 경우, 상기 머신으로 하여금 네트워크-기반 시장을 이용하여 확립된 거래에 대한 구매를 용이하게 하는 방법을 수행하게 하는 명령 세트를 저장하는 머신-판독가능 매체로서,
    상기 방법은,
    제 1 사용자가 일 당사자인 복수의 거래를 식별하는 단계;
    조합가능한 기준을 만족시키는 상기 복수의 거래의 하나 이상의 서브세트를 식별하는 단계; 및
    상기 하나 이상의 서브세트의 거래의 조합가능성의 표시를 상기 제 1 사용자에게 제공하는 단계를 포함하는, 머신-판독가능 매체.
KR1020067003128A 2003-08-14 2004-08-13 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치 KR20060036118A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US49564803P 2003-08-14 2003-08-14
US60/495,648 2003-08-14
US50125103P 2003-09-08 2003-09-08
US60/501,251 2003-09-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020087011414A Division KR20080049146A (ko) 2003-08-14 2004-08-13 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치

Publications (1)

Publication Number Publication Date
KR20060036118A true KR20060036118A (ko) 2006-04-27

Family

ID=34198052

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020067003128A KR20060036118A (ko) 2003-08-14 2004-08-13 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치
KR1020087011414A KR20080049146A (ko) 2003-08-14 2004-08-13 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020087011414A KR20080049146A (ko) 2003-08-14 2004-08-13 다중-판매자 네트워크-기반 시장을 이용하여 확립된 다중의거래를 조합하는 구매서의 생성을 용이하게 하는 방법 및장치

Country Status (3)

Country Link
US (1) US7742947B2 (ko)
KR (2) KR20060036118A (ko)
WO (1) WO2005017704A2 (ko)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7742947B2 (en) 2003-08-14 2010-06-22 Ebay Inc. Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace
WO2005026905A2 (en) * 2003-09-08 2005-03-24 Ebay Inc. Method and apparatus to maintain rules for charges associated with combined transactions established utilizing a multi-seller network-based marketplace
US8554673B2 (en) * 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
US7904366B2 (en) * 2005-09-02 2011-03-08 General Electric Capital Corporation Method and system to determine resident qualifications
US20080033851A1 (en) * 2006-07-25 2008-02-07 Williams Joshua M Methods and application for managing invoices
WO2008045947A2 (en) * 2006-10-10 2008-04-17 Old World Industries, Inc. Systems and methods for collaborative payment strategies
US8725597B2 (en) * 2007-04-25 2014-05-13 Google Inc. Merchant scoring system and transactional database
US20090144801A1 (en) * 2007-07-13 2009-06-04 Grouf Nicholas A Methods and systems for searching for secure file transmission
CN101369333A (zh) * 2007-08-17 2009-02-18 阿里巴巴集团控股有限公司 一种适用于传统零售模式的电子商务方法、系统和装置
US20100250360A1 (en) * 2007-11-20 2010-09-30 Loyaltymatch Inc. Trading Platform for the Redemption of Promotional Currency from Multiple Loyalty Programs
US10163086B2 (en) 2008-04-25 2018-12-25 Cardinalcommerce Corporation Universal payments dashboard
US8468062B1 (en) * 2008-04-28 2013-06-18 Intuit Inc. Multiple party order coordination method and system
WO2010036933A2 (en) * 2008-09-25 2010-04-01 Harclay, Llc Borrowing and lending platform and method
US20110225076A1 (en) * 2010-03-09 2011-09-15 Google Inc. Method and system for detecting fraudulent internet merchants
US20120116822A1 (en) * 2010-11-10 2012-05-10 Ebay Inc. System and method for dynamic pricing of an insurance policy
US20120316990A1 (en) * 2011-06-09 2012-12-13 Google Inc. Evaluating Merchant Trustworthiness
US20130006673A1 (en) * 2011-06-29 2013-01-03 Continental Casualty Company Consolidating Billing Statements in an Agency Business Model
US10185917B2 (en) 2013-01-31 2019-01-22 Lf Technology Development Corporation Limited Computer-aided decision systems
US10437889B2 (en) 2013-01-31 2019-10-08 Lf Technology Development Corporation Limited Systems and methods of providing outcomes based on collective intelligence experience
US9767498B2 (en) 2013-01-31 2017-09-19 Lf Technology Development Corporation Ltd. Virtual purchasing assistant
US20140244442A1 (en) * 2013-02-25 2014-08-28 Andrea Hirsch Method for automatically filling a virtual shopping cart with items
US11087381B2 (en) * 2013-02-25 2021-08-10 Dvorah Hirsch Method for simultaneously one-step filling a virtual shopping cart with many items from one or multiple resources; all items of any type or characteristics from potential resources which have been embodied into a customized list which has been simultaneously generated and sourced in one-step then presented visually to user to select items; culminating and resulting acquisition to be simultaneosly placed in a single virtual shpping cart and all are acquired simultaneously from many source
US9811830B2 (en) 2013-07-03 2017-11-07 Google Inc. Method, medium, and system for online fraud prevention based on user physical location data
US11037131B2 (en) 2013-11-15 2021-06-15 Apple Inc. Electronic receipts for NFC-based financial transactions
US11042846B2 (en) 2013-11-15 2021-06-22 Apple Inc. Generating transaction identifiers
US11392937B2 (en) * 2013-11-15 2022-07-19 Apple Inc. Generating transaction identifiers
US20150220896A1 (en) * 2014-01-31 2015-08-06 Wal-Mart Stores, Inc. Kiosk transactions
US11513658B1 (en) * 2015-06-24 2022-11-29 Amazon Technologies, Inc. Custom query of a media universe database
US10621567B2 (en) 2015-07-01 2020-04-14 Mastercard International Incorporation Electronic grace period billing
US10311413B2 (en) 2015-07-01 2019-06-04 Mastercard International Incorporated By-item bill payments
US10535067B2 (en) 2015-07-01 2020-01-14 Mastercard International Incorporated Electronic incremental payments
US10192206B2 (en) 2016-07-26 2019-01-29 Intuit Inc. Method and system for integrating discrete invoices into a personal financial management and bill payment system and then aggregating discrete invoices having the same payor user and the same payee business into a single payment due item for processing
US20180032978A1 (en) * 2016-07-26 2018-02-01 Intuit Inc. Method and system for integrating discrete invoices into a personal financial management and bill payment system and then aggregating discrete invoices having the same payee business into a single payment transfer transaction
US10528993B2 (en) * 2016-12-07 2020-01-07 Intuit Inc. Payment and invoice systems integration
US11393046B1 (en) 2017-01-17 2022-07-19 Intuit Inc. System and method for perpetual rekeying of various data columns with a frequency and encryption strength based on the sensitivity of the data columns
US10303895B1 (en) 2017-01-19 2019-05-28 Intuit Inc. System and method for perpetual rekeying of various data columns with respective encryption keys and on alternating bases
US10825104B1 (en) 2017-02-16 2020-11-03 Intuit Inc. Method and system for integrating invoice related financial transaction data into a personal financial management and bill payment system and using the payment source to more accurately identify and categorize tax related financial transactions using the payment method
US11823156B2 (en) 2018-12-07 2023-11-21 Target Brands, Inc. Method and system for centralized checkout process
CA3035399A1 (en) * 2019-03-01 2020-09-01 Fabrice Fotso Kengne A method and system for building an honour score via a communication network

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5070463A (en) 1990-11-05 1991-12-03 Pitney Bowes Inc. Parcel processing system with end of day rating
US6615226B1 (en) * 1995-03-30 2003-09-02 Amazon.Com, Inc. Method and system for displaying and editing of information
US6643624B2 (en) * 1998-03-09 2003-11-04 Yan Philippe Method and system for integrating transaction mechanisms over multiple internet sites
US20010027471A1 (en) 2000-01-18 2001-10-04 Amy Paulose Order aggregation system for international shipments
US7272571B2 (en) 2000-07-07 2007-09-18 Mars Incorporated Method and apparatus for effective distribution and delivery of goods ordered on the World-Wide-Web
US20020046191A1 (en) * 2000-10-14 2002-04-18 Joao Raymond Anthony Apparatus and method for providing transaction cost information
US20020111876A1 (en) 2001-02-09 2002-08-15 Rudraraju Panduranga R. Transaction aggregation system and method
US20020133434A1 (en) * 2001-03-19 2002-09-19 Nevel Keith Gerald System and method for controlling the delivery of items from a seller to a buyer
US20020198787A1 (en) 2001-06-20 2002-12-26 Techno Mecca, Inc. Company and college online book ordering system, also known as cobos
US8660931B2 (en) * 2001-09-28 2014-02-25 Siebel Systems, Inc. Method and system for automatically generating invoices for contracts
US20030171998A1 (en) * 2002-03-11 2003-09-11 Omnicell, Inc. Methods and systems for consolidating purchase orders
US7324968B2 (en) * 2002-03-25 2008-01-29 Paid, Inc. Method and system for improved online auction
US7742947B2 (en) 2003-08-14 2010-06-22 Ebay Inc. Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace

Also Published As

Publication number Publication date
US7742947B2 (en) 2010-06-22
KR20080049146A (ko) 2008-06-03
US20050177448A1 (en) 2005-08-11
WO2005017704A3 (en) 2005-08-25
WO2005017704A2 (en) 2005-02-24

Similar Documents

Publication Publication Date Title
US7742947B2 (en) Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace
US11379805B2 (en) Invoicing system
US11113739B2 (en) System and method for automatic fulfillment
US10242398B2 (en) Integrating third party shopping cart applications with an online payment service
US8160928B2 (en) Network-based commerce facility offer management methods and systems
JP5656134B2 (ja) 支払基金のための方法およびシステム
US20050144071A1 (en) Method and apparatus to facilitate the electronic accumulation and redemption of a value in an account
US20070156523A1 (en) Method and system to process an incentive
US20140344113A1 (en) System and method to facilitate different item viewing based on preferred status
US20060271387A1 (en) System for providing a user with shipping information
US20150154687A1 (en) Reseller sales force
US7827103B1 (en) Method and apparatus to maintain rules for charges associated with combined transactions established utilizing a multi-seller network-based marketplace
KR20040075963A (ko) 조합된 경매가 및 정찰가 결제 시스템
JP4483109B2 (ja) 電子商取引装置、電子商取引プログラム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application
A107 Divisional application of patent
J201 Request for trial against refusal decision
J121 Written withdrawal of request for trial
WITB Written withdrawal of application