KR20140133909A

KR20140133909A - 전자 상거래에서 고객 인증 및 신용 평가를 위한 시스템 및 방법

Info

Publication number: KR20140133909A
Application number: KR1020147028021A
Authority: KR
Inventors: 세바스찬 시에미아트코브스키; 니클라스 아달베스; 빅터 제이콥슨; 데이비드 폭; 헨릭 패터슨
Original assignee: 클라나 에이비
Priority date: 2012-03-06
Filing date: 2013-03-06
Publication date: 2014-11-20
Also published as: US20140222616A1; JP6080133B2; JP2015513152A; KR102103612B1; EP2823447A1; WO2013131971A1

Abstract

사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에, 적어도 하나의 통신 네트워크(210)를 통한 통신으로, 거래를 가능하게 하는 네트워크화된 컴퓨터-기반 시스템(202)을 개시한다. 이 시스템(202)은 적어도 사용자 장치(208) 및 상인 시스템(206)과 통신하는 적어도 하나의 서버(214)를 포함하고, 사용자 장치(208)의 디스플레이에 사용자(204)에 대한 사용자 인터페이스를 제공하는 디스플레이 수단을 포함하고, 사용자 인터페이스는 사용자(204)가 사용자 장치(208)의 디스플레이에 제공된 신속 지불 옵션을 선택할 수 있게 해준다. 디스플레이 수단은 또한 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 사용자(204)에 제공한다. 사용자(204)가 제3자 소셜 미디어 서비스에 로그-인한 후에, 시스템은 사용자(204)에 대한 소셜 미디어 서비스의 계정을 통해서 사용자(204)를 입증하기 위해서 제3자 소셜 미디어 서비스와의 통신을 구축한다. 이 입증을 기반으로, 시스템은 사용자(204)가 거래를 검토하고 확인할 수 있게 해주며 이후 거래에 대한 지불이 수신되기 전에 거래를 완료하기 위해 상인 시스템(206)에 통지한다.

Description

전자 상거래에서 고객 인증 및 신용 평가를 위한 시스템 및 방법{SYSTEM AND METHOD FOR CUSTOMER AUTHENTICATION AND CREDIT ASSESSMENT IN ELECTRONIC COMMERCE}

이 서류는 구체적으로 관리, 상업 또는 재정 목적에 적응된 데이터 처리 시스템 또는 방법에 관한 것이며, 특히는 관련된 당사자들의 입증(verification) 및 인증(authentication)을 포함하는 전자 구매, 및 신용 처리를 지원하기 위한 절차들을 포함하는 지불 시스템에 관한 것이다.

보다 구체적으로, 이 서류는 컴퓨터 환경에서 그러한 절차들을 구현하기 위한 기술적인 해법 및 기술적인 기반에 관한 것이다.

컴퓨터들과 컴퓨터 네트워크들은 우리의 일상 삶의 일부가 됨에 따라서, 상인들, 은행들 및 소매 고객들을 포함해서, 많은 당사자가 컴퓨터 네트워크들을 통해서 소매거래를 하고 있다. 이들 거래를 처리하기 위해서 다양한 기술과 프로토콜이 개발되었다. 대부분은 한 당사자로부터 다른 당사자에게 이루어진 지불을 처리하기 위한 메커니즘과 절차들을 포함한다. 그러한 시스템들은 보통 관련된 당사자들에 대한 일종의 입증 및 인증 절차를 시행한다.

그러한 시스템(102)의 한 예가 도 1에 도시되어 있다. 이 도면에서, 온라인 쇼핑객(도시되지 않음)은 106에 표시된 물품 목록, 통상은 온라인 상인의 웹사이트에서 물품을 선택한다(단계 104). 구매할 물품을 선택한 후에, 고객은 시스템에 조인(sign into)하거나 계정을 생성한다(단계 110). 다음에, 고객은 구매할 물품(단계 114), 배송 어드레스(단계 116), 및 이용할 지불 방법(단계 118)을 포함해서 많은 선택을 확인(confirm)한다. 이후 시스템은 제3자 외부 소스들로 특정 내역을 입증한다(단계 122). 지불 내역이 확인 및 입증되면(단계 120), 구매는 승인되고(단계 124) 진행이 허용되며, 그렇지 않다면 구매는 거절된다(단계 126).

이러한 종래 시스템의 한 부정적인 특성은 구매에 사용된 자금이 확인/확보될 때까지는 구매가 확인되지 않는다는 것이다. 이는 거래 완료를 더 어렵게 만들며, 따라서 그러한 기술적인 장애로 인해 거래의 수가 적어진다.

본 발명은 전자 구매에서 거래를 용이하게 위한 시스템, 방법 및 컴퓨터 프로그램 제품의 형태로 기술적인 해법을 제공한다.

이 서류에서, 용어들 사용자 장치 또는 고객 액세스 장치(208)는 교환 사용되고 있다.

1 이상의 실시 예에 따른 시스템 및 방법이 공개되며, 이들은 사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에 적어도 하나의 통신 네트워크(210)를 통한 통신으로 거래를 용이하게 하는 것에 관련되어 있으며, 상기 시스템(202)은 적어도 상기 사용자 장치(208)와 상기 상인 시스템(206)과 통신하는 적어도 하나의 서버(214)를 포함하고, 상기 시스템은:

a. 상기 사용자 장치(208)의 디스플레이에 상기 사용자(204)에 대한 사용자 인터페이스를 제공하는 디스플레이 수단;

b. 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 상기 사용자(204)에 제공하기 위한 디스플레이 수단;

c. 상기 사용자(204)가 상기 제3자 소셜 미디어 서비스에 로그-인한 후에, 상기 사용자(204)에 대한 상기 소셜 미디어 서비스의 계정을 통해서 상기 사용자(204)를 입증하기 위해서 상기 제3자 소셜 미디어 서비스와의 통신을 구축하기 위한 입증 수단;

d. 상기 사용자(204)가 거래를 검토하고 확인할 수 있게 해주는 확인 수단; 및

e. 거래를 완료하기 위해 상기 상인 시스템(206)에 통지하기 위한 수단을 포함한다.

1 이상의 실시 예에서 시스템이 제공되며, 여기서 상기 디스플레이 수단은 신속 지불 옵션을 상기 사용자(204)가 선택한 것에 응답으로, 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 상기 사용자(204)에 제공한다.

1 이상의 실시 예에서 사용자(204)가 상기 소셜 미디어 서비스들을 통한 사용자(204)의 입증을 인가하였는지 여부를 판정하는 수단을 더 포함하는 시스템이 제공된다.

1 이상의 실시 예에서 시스템이 제공되며, 여기서 상기 사용자(204)가 상기 입증을 인가하였는지 여부를 판정하기 위한 수단은 상기 시스템(202)이 제공한 앱(app)을 통한다.

1 이상의 실시 예에서 시스템이 제공되며, 여기서 상기 시스템은 상기 사용자(204)가 상기 사용자 장치(208)의 디스플레이에 제공된 신속 지불 옵션을 선택할 수 있게 해주는 사용자 인터페이스 수단을 더 포함한다.

1 이상의 실시 예에서, 상기 사용자(204)가 거래에 대한 복수의 대안 지불 수단 중 하나를 선택할 수 있게 해주는 수단을 더 포함하는 시스템이 제공된다.

1 이상의 실시 예에서, 상기 사용자(204)에게 추가 정보를 제공하도록 요구하고 추가의 제3자 시스템들(346)에 대비하여 상기 사용자(204)를 입증하기 위한 수단을 더 포함하는 시스템이 제공된다.

1 이상의 실시 예에 따른 시스템 및 방법이 공개되며, 이들은 사용자(204)로부터 입력을 수신하도록 구성된 사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에, 적어도 하나의 통신 네트워크(210)를 통한 통신으로, 거래를 가능하게 하는데 관련되어 있고, 이 시스템 및 방법은:

a. 적어도 상기 사용자 장치(208)와 상기 상인 시스템(206)과 통신하며, 통신 네트워크(210)로 통신하도록 구성된 적어도 하나의 서버(214);

b. 상기 네트워크(210)를 통해 상기 사용자(204)가 개시한 적어도 하나의 사용자 구매 오더 - 구매 오더는 적어도 오더 가격을 포함함 - 를 수신하기 위한 수단;

c. 사용자 식별 정보의 적어도 한 아이템을 수신하기 위한 수단;

d. 적어도 하나의 데이터 저장소(354)와 통신하기 위한 수단;

e. 적어도 상기 수신된 사용자 식별 정보의 아이템을 이용하여 상기 적어도 하나의 데이터 저장소(354)로부터 고유 사용자 식별자(204)에 대한 사용자 데이터(356)를 검색하기 위한 수단;

f. 검색된 사용자 데이터를 이용하여 고유 사용자 식별자(204)를 판정하기(362) 위한 수단;

g. 거래를 이행하기에 충분한 정보가 존재하는지 여부를 판정하기 위한 수단;

h. 상기 사용자 데이터와 오더 가격을 기반으로 상기 사용자(204)에 대한 신용 판정을 행하기 위한 수단;

i. 상기 거래가 사기일 가능성을 줄이기 위해서 사기 검출을 하기 위한 수단; 및

j. 상기 거래를 완료하기 위한 수단을 포함한다.

다음의 것들 중 한 선택 또는 선택된 결합을 포함하는 1 이상의 실시 예에 따른 시스템들 및 방법들이 공개된다:

여기서 상기 거래를 이행하기에 충분한 정보는 사용자 구매 오더가 물리적인 물품에 대한 것이면 적어도 물리적 배송 어드레스에 대한 정보를 포함한다.

여기서 상기 거래를 이행하기에 충분한 정보는 사용자 구매 오더가 다운로드로 이행될 수 있다면 적어도 상기 사용자 장치 정보를 포함한다.

여기서 상기 신용 판정은 적어도 상기 고유 사용자 식별자(204) 기반의 최대 신용 한도의 판정을 포함한다.

여기서 상기 사용자 정보의 적어도 하나의 아이템은 집 코드, 이메일 어드레스, 물리적 거리 어드레스, 모바일 전화번호, 및 일반 전화번호 중에서 적어도 하나이다.

여기서 상기 사기 검출은 적어도 상기 오더 가격, 상기 사용자 식별 정보, 상기 사용자 데이터 및 상기 신용 판정 중에서 적어도 하나에 기반한 사용자 신원의 판정을 포함한다.

여기서 상기 사용자 신원이 판정될 수 없다면, 상기 서버는 추가 사용자 식별 정보를 요청하도록 더 구성되어 있다.

고유 사용자 식별자(204)가 발견될 수 없다면, 고유 사용자 식별자(204)가 발견될 수 있을 때까지 추가 사용자 식별 정보를 요청하기 위한 수단을 더 포함한다.

여기서 상기 서버(214)는 상기 신용 판정이 이루어질 때 신용 레제베이션(reservation for credit)을 생성하도록 더 구성되어 있다.

여기서 상기 서버(214)는 전자 자금 이체, 현금, 수표, 신용 카드, 직불 카드 및 은행 예금 중 적어도 하나를 통해서 상기 적어도 한 사용자(204)의 지불을 수신하도록 더 구성되어 있다.

여기서 상기 데이터 저장소(354)는 데이터베이스 및 분산 데이터베이스 중 적어도 하나이다.

여기서 상기 서버(214)는 상기 사용자(204)가 지불 유형을 선택하기 전에 거래를 완료하도록 더 구성되어 있다.

여기서 상기 저장된 사용자 정보는 제3자에 의해서 제공된다.

여기서 상기 신용 판정은 거래 상세 내역, 구매 물품, 사용자 내역, 상인, 오더 가격, 지불 계획, 사용자 수입, 지불 리마크, 사용자 지불 이력, 및 최근 사용자 구매 활동 중 적어도 하나에 기반을 두고 있다.

1 이상의 실시 예에 따른 시스템들 및 방법들이 공개되며, 이들은 컴퓨터-네트워크화된 거래에 관련되어 있으며,

컴퓨터 네트워크(210)를 통해서 사용자 장비(208)로부터 오더 가격을 포함하는 거래 요청을 수신하고;

사용자 식별 정보의 적어도 한 아이템을 수신하고;

사용자 식별 정보와 사용자 데이터를 포함하는 데이터 저장소(354)와 통신하고;

상기 데이터 저장소(354)를 통해서 상기 저장된 사용자 식별 정보를 고유 상용자 식별자(204)에 매칭하고;

매칭된 고유 사용자 식별자(204)에 대한 사용자 데이터를 상기 데이터 저장소(354)로부터 검색하고;

상기 사용자 데이터가 거래를 이행하기 위해 상기 고유 사용자 식별자(204)에 대한 충분한 정보를 포함하고 있는지 여부를 판정하고;

상기 사용자 식별 정보, 상기 오더 가격 및 상기 사용자 데이터 중 적어도 하나를 기반으로 상기 고유 사용자 식별자(204)에 대한 신용 판정을 행하고;

상기 사용자 식별 정보, 상기 사용자 데이터, 상기 오더 가격 및 상기 신용 판정 중 적어도 하나를 기반으로 상기 고유 사용자 식별자(204)에 대한 사기 판정을 행하고;

사용자 지불 정보를 수신하기 전에 상기 거래를 완료하도록 구성된 적어도 하나의 서버(214)를 포함한다.

다음 것들 중 하나의 선택 또는 선택된 조합을 포함하는 1 이상의 실시 예에 따른 시스템들 및 방법들이 공개된다:

여기서 상기 서버(214)는,

추가 사용자 식별 정보를 요청하고;

상기 추가 사용자 정보를 수신하고; 그리고

상기 거래를 완료하기에 충분한 정보가 있고,

상기 신용 판정을 완료하기에 충분한 정보가 있고,

상기 사용자 식별 정보를 고유 사용자 식별자에 매칭하기에 충분한 정보가 있고, 그리고

상기 사기 판정을 하기에 충분한 정보가 있다는 것

중 적어도 하나를 상기 서버(214)가 판정할 때까지 추가 사용자 식별 정보 요청을 반복하도록 더 구성되어 있다.

여기서 상기 사용자 식별 정보는 이메일 어드레스, 집 코드, 물리적 우편 거리 어드레스, 및 전화번호 중 적어도 하나를 포함한다.

여기서 상기 서버(214)는 제3자로부터 상기 사용자 식별 정보를 수신하도록 더 구성되어 있다.

여기서 거래를 이행하기 위한 상기 고유 사용자 식별자(204)에 대한 충분한 정보는 물리적 배송 어드레스, 상기 사용자의 이메일 어드레스 및 사용자 장비(208) 정보 중에서 적어도 하나를 포함한다.

여기서 상기 제3자로부터 수신된 상기 사용자 식별 정보는 상기 제3자에 의해서 이미 검증되었다(validated).

1 이상의 실시 예에 따른 시스템들 및 방법들이 공개되며 이들은 온라인 거래에 관련되어 있고,

데이터 저장소(354) 및 네트워크(210)와 통신하고;

적어도 오더 가격을 포함해서 상기 네트워크(210)를 통해 사용자(204)로부터 거래를 개시하라는 요청을 수신하고;

적어도 하나의 사용자 식별자 정보를 수신하고;

수신된 사용자 식별자 정보를 이용하여, 상기 데이터 저장소(354)로부터 사용자 데이터를 검색하고;

상기 사용자 데이터로부터 고유 사용자 식별자(204)를 식별하고;

거래를 이행하기에 충분한 사용자 데이터가 존재하는지 여부를 판정하고;

적어도 상기 고유 사용자 식별자(204)의 사용자 데이터를 기반으로 신용을 판정하고;

사기 판정을 행하고;

지불을 요청하기 전에 온라인 거래를 인가하도록

구성된 서버(214)를 포함한다.

여기서 상기 데이터 저장소(354)는 내부 사용자 데이터베이스이다.

여기서 상기 사용자 식별자 정보는 사용자(204) 및 제3자(346) 중 적어도 하나로부터 수신된다.

여기서 상기 서버(214)는 고유 사용자 식별자(204)가 판정될 수 없다면 적어도 하나의 추가 사용자 식별자 정보를 요청하도록 더 구성되어 있다.

여기서 거래를 완료하기에 충분한 사용자 데이터가 존재하는지 여부를 판정은 상기 사용자 데이터가 물리적 우편 어드레스, 상기 사용자의 이메일 어드레스 및 사용자 장비(208) 정보 중에서 적어도 하나를 포함하는지 여부에 기반을 두고 있다.

여기서 상기 서버(214)는 거래를 이행하기에 충분한 정보가 존재하지 않는다면 적어도 하나의 추가 사용자 식별자 정보를 요청하도록 더 구성되어 있다.

여기서 상기 신용 판정은 제3자(346)로부터의 정보를 포함하여 행해진다.

여기서 상기 사기 판정은 상기 사용자 식별자 정보, 상기 사용자 데이터, 상기 오더 가격, 및 상기 신용 판정 중 적어도 하나에 기반을 두고 있다.

여기서 상기 서버는 사기 판정을 하기에 충분한 정보가 없다면 추가 사용자 식별자 정보를 요청하도록 더 구성되어 있다.

이 시스템에 대한 기술, 혁신 및 관련 개념들은 이하 첨부 도면을 참조해서 좀더 상세히 설명되며, 이들은 예시적인 것이지 이 특허 서류의 개념을 제한하는 것이 아니다. 도면들에서 같은 참조 번호는 도면 전반에서 대응 파트를 가리킨다.
도 1은 종래 시스템에서의 통상적인 거래 흐름을 보여주는 개략적인 흐름도이다.
도 2는 이 서류에 기술된 몇몇 예의 혁신들을 구현하기 위한 시스템의 개략적인 개요 예이다.
도 3a은 몇몇 실시 예들에 따른, 도 2에 도시된 시스템의 이용 동안 처리 흐름을 보여주는 개략적인 흐름도이다.
도 3b은 몇몇 실시 예들에 따른, 도 2에 도시된 시스템의 이용 동안 처리 흐름을 보여주는 도 3a에 있는 것과 유사한, 개략적인 흐름도이다.
도 4a 내지 4h는 몇몇 실시 예에 따른, 도 3a 및 도 3b에 기술된 프로세스 동안 고객이 보고 체험하는 것을 보여주는 스크린 샷이다.
도 5a 내지 5d는 몇몇 실시 예에 따른, 긍정적인 고객 식별이 행해질 수 없을 때 시스템이 고객에게 표시하는 것을 보여주는 스크린 샷이다.
도 6a 내지 6d는 몇몇 실시 예에 따른, 인증을 위해 소셜 미디어 플랫폼을 이용할 때, 시스템과 제3자 간의 통합 결과로서 고객이 보고 체험하는 것을 보여주는 스크린 샷이다.
도 7a 내지 7f는 몇몇 실시 예에 따른, 도 3a 및 3b에 기술된 프로세스의 또 다른 버전에 대한 고객 체험을 보여주는 스크린 샷이다.
도 8a 내지 8b는 몇몇 실시 예에 따른, 도 3a 및 3b에 기술된 프로세스의 다른 버전에 대한 고객 체험을 보여주는 스크린 샷이다.
도 9a 및 9b는 다양한 상인들로부터 구매한 물품에 대한 지불을 처리하는 실시 예들의 프로세스를 개략적으로 보여주고 있다.

본 기술의 설명을 보여주는 도면들은 이 기술을 이해하는데 관련되어 있는 요소들을 보여주기 위해 간략화되어 있는 한편 명료함을 위해서 통신 시스템들 및 방법들에서 발견되는 많은 다른 요소들이 제거되어 있음을 이해하여야 한다. 이 방면에 보통의 지식을 가진 자들은 다른 요소들 및/또는 단계들이 본 기술을 구현하는데 요망 및/또는 필요함을 인식할 수 있다. 이 공개는, 그러나, 이 방면에 숙련된 자들에게 공지된 그러한 요소들 및 방법들에 대한 모든 그러한 변형 및 수정에 관계가 있다.

시스템 개요

도 2는 이 서류에 기술된 몇몇 실시 예를 구현하기 위한 시스템(202)의 메인 컴포넌트들의 개요를 제공한다. 한 실시 예에서, 사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에, 적어도 하나의 통신 네트워크(210)를 통한 통신으로 거래를 용이하게 하는 컴퓨터-기반 시스템(202)은 적어도 사용자 장치(208) 및 상인 시스템(206)과 통신하는 적어도 하나의 서버(214)를 포함하고, 상기 시스템은:

사용자 장치(208)의 디스플레이에 사용자(204)에 대한 사용자 인터페이스를 제공하기 위한 디스플레이 수단;

제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 사용자(204)에게 제공하기 위한 디스플레이 수단;

사용자(204)가 제3자 소셜 미디어 서비스에 로그-인을 한 후, 사용자(204)를 위한 소셜 미디어 서비스와의 계정을 통해서 사용자(204)를 입증하기 위해 제3자 소셜 미디어 서비스와의 통신을 구축하기 위한 입증 수단;

사용자(204)가 거래를 검토하고 확인할 수 있게 해주는 확인 수단; 및

거래를 완료하기 위해 상인 시스템(206)에 통지하기 위한 수단을 포함한다.

볼 수 있는 바와 같이, 시스템(202)은 사용자 액세스 장치 디스플레이 수단 및 웹 브라우저를 실행하는 컴퓨터(208)와 같은 확인 수단을 이용하여, 상인 서버 시스템(206)에 호스트된 웹사이트를 액세스하는 고객(204)을 포함한다. 고객(204), 상인의 웹사이트(206), 온라인 서비스 서버 시스템(214), 및 제3자 소셜 네트워크 사이트와 같은 외부 소스(310) 간의 연결은 네트워크, 통상은 도시된 바와 같이 인터넷(210)과 같은 TCP/IP-기반 원거리 통신망을 통해서 이루어진다. 또한 연결은 POTS 전화 또는 모바일 폰 네트워크와 같은 다른 네트워크를 통해 이루어질 수 있다.

고객의 액세스 장치(208)와 상인의 웹사이트에는 1 이상의 미리 정의된 데이터 구조를 통한 제어 데이터의 통신을 처리하도록 적응된 컴퓨터 프로그램 코드 부분들을 포함하는 컴퓨터 소프트웨어가 제공된다. 상인의 웹사이트(206)는 예를 들어 서버, 상인 데이터베이스(예를 들어, 도 2의 백엔드 사유) 및 소프트웨어 구현 구매 처리 기능들을 포함하는 상인 서버 시스템(206)으로서 실현된다.

도시된 바와 같이, 고객이 아이템(212)을 구매하기를 원하면, 상인 웹사이트(206)는 API 콜, 또는 인터넷에 대한 온라인 서비스 시스템의 사용자-인터페이스를 통해서 온라인 서비스 시스템(214)에 접촉할 수 있다. 온라인 서비스 시스템(214) - 종종 단지 작은 양의 데이터를 갖고 있음 - 은 고객(204)을 식별하고(이하 상세히 기술되는 바와 같이 신규 또는 재방문 고객인지 여부), 신용 평가를 행하고 그리고 특정 경우들에서는, 최대 신용 금액(credit amount)을 정하고, 신용 금액이 초과하였는지 여부를 판정하고 사기를 검사하는 등등을 한다. 그러므로, 이와 같이 데이터 량이 적을지라도, 이용된 기술들은 시스템(214)이 거래를 할 수 있게 해준다.

온라인 서비스 시스템(214)은 예를 들어, 고객에 관한 신원 정보를 구하도록 구성된 1 이상의 고객 식별 기능, 고객의 판정된 신원을 적어도 일정 정도의 확실성으로 입증하도록 구성된 1 이상의 고객 입증 기능, 완료 정보를 구하도록 구성된 1 이상의 정보 완료 기능, 특정 구매에 관련해서 고객에 대한 신용 한도액(credit line)을 정하도록 구성된 1 이상의 신용 평가 또는 신용 판정 기능, 및/또는 고객으로부터 그리고 상인에게 구매에 대한 지불을 처리하도록 구성된 지불 처리 기능의 선택을 실현하도록 적응된 컴퓨터 프로그램 코드 부분들을 포함하는 컴퓨터 소프트웨어가 제공된 구매 지원 처리 서버로서 실현된다. 온라인 서비스 시스템(214)에는 또한 사용자 장치 또는 고객 액세스 장치(208)와 함께, 상인 웹사이트/상인 서버 시스템(206)뿐만 아니라 정부 데이터베이스, 제3자 서비스 시스템들 또는 재무 기구(220)와 같은 선택적인 외부 자원들과의 통신을 위해 적응된 통신 채널들이 제공되어 있다. 예를 들어, 고객(304)이 액세스 장치(208)로 물품 아이템 목록을 표시하고 액세스 장치(208)로 물품 아이템 목록의 구매를 진행할 의향을 표시한 후에 - 여기서 액세스 장치는 상인 서버 시스템(206)에 정해진 세션을 가짐 -, 상인 서버 시스템(206)은 액세스 장치(208)를 나타내는 세션 식별자와 같은 제어 데이터를 포함하는 구매 오더 요청을 온라인 서비스 시스템(214)에 전송한다. 온라인 서비스 시스템(214)에 포함되어 있거나 그에 연결된 고객 제어 데이터 수집 기능은 고객 액세스 장치(308)에서 실행되거나 그에 제공된 입력 인터페이스 내에, 고객 제어 데이터 및/또는 고객 관련 데이터의 1 이상의 아이템을 입력하고 이들을 데이터 수집 기능에 전송하도록 고객(304)에게 요청한다. 이때 제어 데이터 아이템들은 예를 들어 선택된 신용 평가 기능 콜(call) 또는 다른 콜들을 트리거(trigger)하기 위해 온라인 서비스 시스템(214)에 이용되고 온라인 서비스 시스템(214)에서 선택된 기능들은 상기 제어 데이터 및 1 이상의 미리 정해진 규칙 세트에 따라서 트리거된다. 그러한 신용 평가 기능 콜들은 고객 제어 데이터 또는 다른 고객 관련 데이터의 선택된 파트들을 포함할 수 있고 또한 전달할 수 있다. 한 예에서 제어 데이터 기능은 상인 서버 시스템(206)에 배치되어 있고 제어 데이터는 온라인 서비스 시스템(214)에 포워드된다. 상인의 웹사이트는 일반적으로 상인 측의 상이한 서버 기능들에 대한 인터페이스이다.

후에 기술되듯이, 이 시스템은 고객이 어떤 지불 방법을 이용할지 선택하기 전이라도 구매를 완료시키려 한다. 이는 "신용 레제베이션(reservation for credit)"을 생성하고 신용을 고객에게 확장함으로써 성취된다. 이 "레제베이션"는 신용 인가 요청이 신용 카드 회사에 수신될 때 신용 카드 회사가 행한 레제베이션과 유사할 수 있다. 기본적으로, 이 시스템은, 각 알려진 고객에 대해서, 시스템(214)이 상인들에게 지불을 이행할 최대 신용 한도를 결정한다. 시스템(214)은 이 신용 한도를, 예를 들어, 특정 거래 세부 사항, 구매되는 물품, 상인, 계정, 지불 계획, 고객의 공지된 수입, 지불 리마크, 고객의 지불 이력은 물론이고 고객의 최근 구매 활동에 결부해서 고객 내역을 기반으로 결정한다. 몇몇 경우에, 그러나, 신용 한도가 0일 수 있는 가능성도 꽤 있다. 선택적으로, 이 신용 한도는 매 거래마다 계산되며, 그러므로, 거래들 간에 정액으로서 존재하지 않는다. 그래서, 고객이 청구서를 받기로(to be billed) 선택할 때, 시스템은 신용 한도액을 계산하고, 충분한 신용이 존재하면, "신용 레제베이션이 이루어진다". 이는 구매의 총액이 신용 한도액에 대비해서 "리저브"되므로("reserved") 어떤 후속 구매를 위한 이용가능 신용의 총액이 실질적으로 감소한다는 것을 의미한다. 그러나, 신용 카드 회사와는 달리, 신용 한도액이 존재한다는 사실과 신용 한도액의 총액이 고객에게 반드시 알려지지는 않는다.

1 이상의 실시 예에서, 각 고객에 대해, 예를 들어 고객 특정 데이터, 예를 들어, 고객 제어 데이터를 저장하기 위해 마련된 데이터 레코드의 형태로 데이터 구조가 온라인-서비스-시스템(214)에 제공되어 있다. 고객 특정 데이터 레코드는 위에 예시된 것, 예를 들어, 고객 식별 데이터, 신용 한도와 같은 다양한 고객 내역을 나타내는 데이터 아이템들의 선택을 위한 할당들(allocations)을 포함한다. 신용 한도는 양호하게는 거래마다 동적으로 계산되어 거래 특정 값에 정해진다. 유사하게, 온라인-서비스-시스템(214)에는 데이터 구조가 예를 들어 거래 세부 사항을 저장하기 위해 마련된 데이터 레코드의 형태로 제공되어 있다. 거래 특정 데이터 레코드는 위에 예시된 것, 즉 구매되는 물품 아이템들, 상인, 구매의 총액 등과 같은 다양한 거래 내역을 나타내는 데이터 아이템들의 선택을 위한 할당들을 포함한다.

하나 또는 한 아이템의 물품 구입을 개시하기 위해서, 고객은, 예를 들어, 구매를 나타내는 구매 제어 데이터 아이템을 생성하고 이를 상인의 웹사이트를 통해서 상인 서버 시스템에 전송함으로써 구매를 트리거하기 위한 제어 데이터를 생성한다. 이때 이 구매 제어 데이터는 다른 고객 제어 데이터와 결부해서 구매를 실행할 수 있게 해주는 기능들을 트리거하고 좀더 동적으로 고객의 현재, 혹은 추정된 물품에 대한 지불 능력에 따라서 구매된 아이템의 배송을 개시한다. 한 예에서, 고객(304)은 구매를 완료하고 늦게서야 결제/지불의 선호 방법을 선택할 수 있다. 신규의 시스템에 의해 처리된 구매 아이템들은 물리적인 아이템 예를 들어 우편 또는 택배로 배달되는 옷, 신발, 전자 장비; 전자식으로 반송되는 아이템들, 예를 들어, 데이터 통신 캐리어에 의해서 예를 들어 이메일 또는 스트리밍을 통해서 배달되는 디지털 미디어, 이북, 뮤직, 필름, 또는 서비스들 예를 들어 페이-퍼-뷰 비디오; 전화 가입 피처들, 예를 들어, 가입 계정에서 그러한 피처들을 작동시킴으로써 배달되는 모바일 폰 서비스들, 공공 전송 티켓들; 또는 물리적으로 실행되는 서비스들 예를 들어 물리적 사람에 의해서 이루어지는 청소 또는 정원 손질과 같은 다양한 종류일 수 있고 다양한 배송 방법에 의해서 배송될 수 있다.

양호하게는, 온라인 서비스 시스템(214)의 선택된 기능들 및/또는 상인 서버 시스템(206)의 선택된 기능들은 지불 절차와는 별도로 그리고 고객이 선택한 지불 방법과는 독립적으로 구매를 완료하도록 적응되어 있다. 1 이상의 실시 예에서, 이 목적을 위해, 온라인 서비스 시스템(214)의 구매 핸들러 기능은 예를 들어 기능 콜(function call)을 통해서 온라인 서비스 시스템(214)의 신용 평가 기능을 작동시킨다. 1 이상의 실시 예에서, 이 목적을 위해, 상인 서버 시스템(206)의 구매 핸들러는 고객 제어 데이터와 신용 평가 요청을 온라인 서비스 시스템(214)의 신용 평가 기능에 전달한다. 신용 평가 기능은 예를 들어 선택된 물품의 가격에 해당하는 또는 그에 의존하는 값을 한 세트의 미리 정해진 규칙에 따라 현재 고객 및 혹은 현재 구매에 할당된 신용 파라미터에 대한 레제베이션에 설정한다. 예를 들어, 이들 미리 정해진 규칙들은 구매를 위해 선택된 한 물품의 가격을 초과하는 고객의 평가된 현재 신용 한도액을 포함할 것이다. 한 실시 예에서, 구매 릴리스(release) 파라미터는 예를 들어 신용 파라미터에 대한 레제베이션의 값이 성공적으로 설정되는 것에 대한 응답으로 상인 서버 시스템(206)에 설정되어 전달되고, 그래서 구매가 상인 서버 시스템에 의해서 완료되도록 제어된다. 유사하게, 한 실시 예에서 구매 차단 파라미터는 신용 파라미터에 대한 레제베이션 값이 성공적으로 설정될 수 없는 경우에 상인 서버 시스템에 설정되어 전달된다. 대안 또는 보완으로, 구매 차단 파라미터는 예를 들어 또한 타임 아웃 기능 런닝 아웃(time out function running out)에 따라 상인 서버 시스템(206)에서 설정될 수 있다.

구매의 완료는 상인 서버 시스템이 구매된 물품의 배송을 개시하는 것은 물론이고 양호하게는 온라인 서비스 시스템(214)에 완료 구매 파라미터의 확인(confirmation)을 전달하는 것을 포함하며, 통상은 구매 물품의 배송이 개시된다. 완료 구매 파라미터의 확인이 온라인 서비스 시스템(214)에 의해 수신되는 것에 응답해서, 이 시스템은 예를 들어 선택된 거래 프로세스를 통해서 고객에게서 지불을 받아내는 것은 물론이고 예를 들어 온라인 서비스 시스템(214)으로부터 상인 서버 시스템(206)으로의 거래를 통해서 또는 상인에 연관된 다른 자금 이체 시스템을 통해서 지불을 상인에게 트리거하는 것을 포함하는 지불 프로세스를 수행한다.

배송시, 그리고 상인 서버 시스템(206)으로부터 수신된 완료 구매 파라미터에 의해 트리거될 때, 온라인 서비스 시스템(214)은, 실례로, 미리 정의된 예를 들어 고정 또는 계산된 지연 예를 들어 14일 후에 상인에게 지불이 되도록 한다. 그래서 예를 들어 송장의 지불 만기일에 또는 이전에, 고객(204)은 온라인 서비스 시스템(214)에 전자 자금 이체(EFT)가 되도록 은행 또는 다른 재무 기관(220)을 이용하여 송장의 비용을 지불한다. 대안으로, 이하 기술되듯이, 고객에게는 다른 지불 수단이 주어질 수 있다.

그러나, 고객(204)이 만기일까지 지불하지 않으면, 온라인 서비스 시스템(214)은 라마인더(reminder)(230)를 고객에게 전송하고; 그래도 고객(204)이 아직 지급하지 않으면, 송장은 강제 프로세스(도시되지 않음)를 밟게 되고 이는 빚 수금 대행업자 또는 다른 절차들로 종료될 수 있다.

여기에 기술되는 바와 같은 신규의 개념의 본보기 실시 예는 고객의 액세스 장치(208)(사용자 장치(208)), 상인 시스템(206) 및 온라인 서비스 시스템(214) 간에 다음과 같은 상호 작용 스테이지들을 포함한다.

스테이지 10: 선택된 물품 아이템에 대한 고객 구매 오더

고객은 상인 시스템(206)에 의해 호스트(host)되고 고객의 액세스 장치(208)에서 실행되는 인터넷 브라우저에 의해 제공되는 웹페이지로서 렌더링된 양식(form)과 상호 작용하여 1 이상의 구매 물품 아이템을 선택한다. 고객은 구매 의향 표시를 상인 시스템(206)에 전송하기 위해 양식에 있는 제어 버튼을 작동시켜 체크아웃 프로세스를 트리거한다.

스테이지 100: 체크아웃 초기화

수신된 구매 의향 표시에 응답해서, 상인 시스템(206)은 상인 시스템(206) 내의 체크아웃 오더를 초기화 또는 갱신하고, 온라인 서비스 시스템(214)의 대응 체크아웃 오더를 초기화 또는 갱신하기 위해 제어 데이터의 선택을 포함하는 요청을 온라인 서비스 시스템(214)에 전송하며, 그 결과 온라인 서비스 시스템은 확인 메시지를 도로 상인 시스템(206)에 전송한다.

스테이지 200: 고객과 상호 작용하여 체크아웃을 렌더링

수신된 확인 메시지에 응답해서 상인 시스템(206)은 초기화된 또는 갱신된 체크아웃 오더를 검색하고 온라인 서비스 시스템(214)의 대응 체크아웃 오더로 반응하도록 제어 데이터의 선택을 포함하는 요청을 온라인 서비스 시스템(214)에 전송하며, 그래서 온라인 서비스 시스템은 확인 메시지를 도로 상인 시스템(206)에 전송하고 이는 이때 체크아웃 오더를 액세스 장치(208)의 디스플레이에 렌더링한다. 1 이상의 대안 실시 예에서, 온라인 서비스 시스템(214)은 체크아웃 오더를 직접 액세스 장치(208)의 디스플레이에 렌더링한다.

스테이지 300: 구매 완료

거래/구매를 위한 승인 신용(330)의 판정시, 온라인 서비스 시스템(214)은 푸시 요청(push request)을 상인 서버 시스템(206)에 전송하고 이는 대응 체크아웃 오더를 검색하여 체크아웃 오더를 제어 데이터의 형태로 온라인 서비스 시스템(214)에 전송한다. 온라인 서비스 시스템(214)은 체크아웃 오더 내의 구매 릴리스 파라미터를 갱신하고 이 체크아웃 오더를 상인 서버 시스템(206)에 전송한다. 상인 서버 시스템(206)은 오더를 생성하고, 배송을 개시하고 완료 구매 파라미터를 온라인 서비스 시스템(214)에 전송함으로써 완료 구매를 확인해 준다. 온라인 서비스 시스템(214)은 생성된 체크아웃 오더 상태 파라미터를 갱신한다.

스테이지 400: 고객과 상호 작용하여 체크아웃 확인을 렌더링

지불 프로세스의 완료시, 온라인 서비스 시스템(214)은 지불 완료 요청을 상인 서버 시스템(206)에 전송한다. 수신된 지불 완료 요청에 응답해서 상인 시스템(206)은 초기화된 또는 갱신된 체크아웃 오더를 검색하고 온라인 서비스 시스템(214)에서 대응 체크아웃 오더로 응답하도록 제어 데이터의 선택을 포함하는 요청을 온라인 서비스 시스템(214)에 전송하며, 그래서 온라인 서비스 시스템은 확인 메시지를 도로 상인 시스템(206)에 전송하며, 이는 이때 액세스 장치(208)의 디스플레이에 체크아웃 오더를 렌더링한다. 1 이상의 대안 실시 예에서는, 온라인 서비스 시스템(214)은 체크아웃 오더를 액세스 장치(208)의 디스플레이에 직접 렌더링한다.

거래 흐름 예

도 3a은 위에 기술된 시스템(202)의 거래 흐름이 수반할 수 있는 다양한 단계들의 개요 예를 제공한다.

도 3a에서, 고객(도시되지 않음)이 물품 목록(306)에서 1 이상의 아이템을 선택한 후, 시스템은 308에서 고객에게 여기서 또한 고객 식별자라 불리는 고객 식별 정보의 단일 아이템을 제공하도록 요구한다. 이하 설명되는 바와 같이, 이 식별 정보는 반드시 고객으로부터의 수동 입력일 필요는 없지만 보통은 제3자 소셜 네트워크 사이트와 같은 외부 소스(310)로부터의 고객의 허가를 동반할 수 있다. 이 식별자는 또한 고객의 장치, 예를 들어, 고객 액세스 장치(208)에서 운영되는 모바일 핸드셋의 장치 식별자 또는 고객에 관련된 가입 식별자, 예를 들어, 모바일 네트워크 서비스 가입에 의해 제공될 수 있다. 이것이 단일 아이템 식별자일 필요는 없지만 이 시스템은 또한 초기 단계에서 다수의 식별자를 수용할 수 있다. 그러한 경우의 한 예는 고객이 그의 상인 계정에 조인(sign in)될 때일 것이다. 상인은 이때 체크아웃 세션이 개시될 때 이 계정에 관련된 고객 정보를 이 시스템에 제공할 수 있다. 메인 포인트는 이 시스템이 임의 고객 식별자 세트를 수용할 수 있고 때로는 거래를 완료하는데 단일 식별자로도 충분할 수 있다는 것이다.

물품 목록(306)에서 1 이상의 아이템을 사용자가 선택하는 방식을 기술하는 좀더 상세한 방법은 다음과 같다. 고객(204)은 사용자가 구매를 원하는 물품 목록 중에서 한 세트의 아이템, 고객 제어 데이터의 선택, 및 체크아웃 세션 개시를 트리거하는 표시 또는 제어 신호라고도 불리는 구매 의향의 확인을 예를 들어 구매 오더 요청의 형태로 상인 서버 시스템(206) 및 온라인 서비스 시스템(214)에 표시해주는 입력을 상인 서버 시스템(206) 및/또는 온라인 서비스 시스템(214)에 통신 식으로 연결된 액세스 장치(208)에서 실행한다. 1 이상의 실시 예에서, 상인 서버 시스템(206)은, 사용자가 물품 목록에 표시한 아이템 세트, 고객 제어 데이터 및 체크아웃 세션 표시를 기반으로, 고객 구매 오더 요청을 온라인 서비스 시스템(214)에 전송한다. 1 이상의 실시 예에서, 고객의 액세스 장치(208)는, 사용자가 물품 목록에 표시한 아이템 세트 및 고객 제어 데이터를 기반으로, 고객 구매 오더 요청을 직접 온라인 서비스 시스템(214)에 전송한다.

1 이상의 실시 예에서 온라인 서비스 시스템(214)은 상인 서버 시스템(206) 및/또는 액세스 장치(208)로부터 고객 구매 오더 요청을 수신한다. 1 이상의 실시 예에서, 온라인 서비스 시스템(214)은, 예를 들어, 고객 정보를 포함하거나 고객 정보로 구성되는 고객 제어 데이터를 더 수신한다. 온라인 서비스 시스템(214)은 고객 정보라고도 불리는 고객 제어 데이터를 수신한다.

고객 제어 데이터는 다음과 같이 수신될 수 있다:

- 사용자가 액세스 장치(208)를 통해서 온라인 서비스 시스템(214)에 표시함으로써

- 사용자가 액세스 장치(208)를 통해서 상인 웹 사이트에 표시함으로써

- 상인 서버 시스템(206)이 상인 데이터베이스를 액세스함으로써

- 보통은 고객이 표시한 허가와 함께, 제3자 소셜 네트워크 사이트와 같은 외부 소스(310)에 요청 및 그로부터의 대응 응답을 통해서 또는 이들 모두의 조합을 통해서 수신됨으로써.

고객 제어 데이터는 구매 오더 요청에 또는 온라인 서비스 시스템(214)으로의 개별 제어 신호에 포함될 수 있다.

소셜 네트워크에 속하는 데이터베이스와 같은 외부 소스(310)를 이용하는 경우에, 1 이상의 실시 예는 제3자 요청이, 제3자 요청에 포함되어 있는 고객 제어 데이터, 온라인 서비스 시스템(214)에 저장되어 있고 제3자 요청에 포함되어 있는 데이터 레코드, 또는 온라인 서비스 시스템(214)과 외부 소스(310) 간의 미리 정해진 관계를 기반으로 외부 소스(310)(제3자)에 의해 검증되는 것을 포함한다. 1 이상의 실시 예는 온라인 서비스 시스템(214)이 고객 액세스 장치(208)로부터 고객 로그인 데이터의 형태로 고객 제어 데이터를 그리고 혹은 고객 신원 데이터를 구하기 위한 목적을 위해 예를 들어 외부 소스(310)에 있는 고객의 계정에 액세스하기 위한 고객의 명시적 허가를 나타내는 액세스 허가 파라미터를 수신하는 것을 포함한다.

이러한 정보를 가지고 시스템(214)은 312에서 고객 매칭 메커니즘으로 고객 식별을 수신된 고객 식별 데이터에 따라서 알려져 있는 개인에 매칭하는 것을 시도한다. 이는 1 이상의 데이터베이스 질의 요청으로, 자신의 내부 데이터베이스(314)를 또는 어떤 경우들에서는 외부 데이터베이스(316), 예를 들어, 신용 평가 기관(credit bureau), 폰 등록소에 우선 조회함으로써 행해진다. 데이터베이스는 ,예를 들어, 클라우드 환경의 또는 분산형의 가상 데이터베이스일 수 있을 것이고 아니면 한 장소에 있는 물리적 데이터베이스일 수 있을 것이다.

고객 식별의 매칭 방식을 기술하는 좀더 자세한 방법은 수신된 제1 세트의 고객 제어 데이터를 데이터베이스에 있는 레코드에 매칭하고 매칭이 성공할 때 이 고객이 공지된 개인으로 식별된 것으로 여겨서 표시하는 것으로 기술될 수 있을 것이며, 여기서 성공적인 매칭은 미리 정의된 규칙 세트에 따른 특정 매칭 조건들이 충족된 것을 포함한다. 한 예에서, 매칭 조건들은 물리적인 물품 배달을 위한 배송 어드레스 또는 모바일 전화번호와 같은, 배달 및 지불 당사자 식별을 위한 미리정의된 거래를 실행하기에 충분한 정보로서 규칙 내에 정의되어 있다. 한 예에서, 매칭은 수신된 고객 제어 데이터를 포함하는 요청을 데이터베이스에 전송하고 매칭된 세트를 회답으로 수신함으로써 실행된다. 한 예에서, 데이터베이스는 온라인 서비스 시스템(214)의 내부 데이터베이스 또는 온라인 서비스 시스템(214)에 통신 방식으로 연결된 외부 데이터베이스이다. 한 예에서, 수신된 고객 제어 데이터는 데이터베이스 내의 레코드에 매칭하는데 이용된 외부 소스(310)로부터의(예를 들어, 제3자 소셜 네트워크에 있는 사용자 계정으로부터의) 사용자 계정 정보를 포함한다. 데이터베이스 내의 레코드에 매칭하기 위해 고객 제어 데이터를 매칭하는 것은 이 방면에 숙련된 자에게 공지된 어떤 식으로도 실행될 수 있다.

더욱이, 이 시스템은 고객이 재방문 고객일 필요도 없고 또한 고객이 시스템(214)에 사용자 계정/등록을 구축할 필요도 없게 설계 및 구성되어 있다. 사실, 고객은 외부의 어떤 벤더(vendor)와의 기존 계정을 전혀 가지지 않을 수 있다.

이는, 위에서 설명된 바와 같이, 상인 서버 시스템(206)은 구매 오더 및 구매한 물품의 배송을 처리하고 온라인 서비스 시스템(214)은 구매 릴리스 및 지불 프로세스를 처리하도록 구매 프로세스를 분리함으로써 가능해진다. 구매 릴리스 프로세스는, 예를 들어, 고객 식별, 고객 신원 입증, 신용 평가/판정 및 구매 릴리스의 표시를 포함한다. 지불 프로세스는 다양한 방식으로, 예를 들어, 구매를 위한 신용을 발행함으로써 지불 결제하는 것을 포함한다. 다양한 결제/지불 방법의 예는 이하 더 기술된다.

이러한 프로세스의 결과로서, 시스템(214)이 318에서 고객을 식별할 수 있다고 판정되도록 구성되면, 이는 320으로 이동해서 고객에 대한 "입증자"를 갖고 있는지 여부를 검사한다. 식별은 예를 들어 거래를 실행하기에 충분한 정보를 의미한다. 이는 통상 단순히 고객 식별보다 더 많은 정보를 포함한다. 예를 들어, 이는 물품의 물리적 배달을 위한 배송 어드레스 또는 버스 티켓의 SMS 텍스트 메시지 배달과 같은 것을 위한 모바일 전화번호와 같은 정보를 포함할 수 있을 것이다.

시스템(214)이 제공된 정보로 고객을 식별할 수 없다면, 시스템은 고객이 초기 정보를 제공해야 하는 단계(308에서)로 돌아가서 고객에게 추가 정보를 제공하도록 촉구(prompt)한다. 이 루프(322)는 시스템이 고객을 식별할 수 있는 충분한 정보를 가질 때까지 반복된다. 고객이 식별되면, 위에 기술된 바와 같이, 시스템(214)은 이 정보가 고객에 대한 입증자를 갖고 있는지 여부를 검사할 수 있다(320에서). 이 입증자는 이 고객이 그가 말하는 사람인지를 입증하는데 이용되는 두 번째 정보 - 이는 종종 단계 308에서 판정된 고객 식별자로부터는 불명확하거나 추론가능하지 않음 - 일 수 있으며, 이 정보는 기타 목적들 중에서 사기 검출/보안/무결성 입증을 위해 이용된다. 입증자는, 예를 들어, 고객 식별이 이-메일 어드레스일 때는 집 코드(zip code)일 수 있다. 통상 집 코드는 이-메일 어드레스로부터는 불명료하거나 추론가능하지 않다. 이하 좀더 상세히 기술되듯이, 입증자는 또한 식별이 규명됨과 동시에 수집되었을 수 있다. 이 예의 실시 예는 거래를 완료하기 위해 적은 고객 입력을 이용하는 것을 포함할 수 있다.

단계 312에서 성공적인 매치가 이루어져서 318에서 고객이 식별되었다고 판정되면, 온라인 서비스 시스템(214)은 320에서 고객에 대한 입증자 데이터 아이템이 수신된 고객 제어 데이터 내에서, 및/또는 내부 데이터베이스 및/또는 외부 데이터베이스 내에서 구해질 수 있는지 여부를 더 판정한다. 1 이상의 실시 예에서, 입증자 데이터 아이템은 수신된 고객 제어 데이터와 연계해서 보안 입증 및 무결성 입증을 위해, 사기 시도를 판정하는데 이용될 수 있다. 한 예에서 입증자 데이터 아이템은 집 코드일 수 있다. 한 예에서 사용자에 의해 표시된 입증자 데이터 아이템은 내부 또는 외부 데이터베이스/데이터베이스들에 저장된 대응 입증자 데이터 아이템에 비교되고, 이들이 매치한다면 온라인 서비스 시스템(214)은 고객 구매 오더가 사기가 아니라고 판정한다.

시스템이 입증자를 가지고 있지 않다면, 이는 고객에게 입증자를 제공하도록 촉구할 수 있다(단계 322에서). 고객에 의해 제공되든 다른 수단을 통해서 판정되든 간에, 입증자는 324에서 검사될 수 있다. 입증자가 허용되면, 시스템(214)은 모든 다른 관련 사용자 내역을 사용자에게 디스플레이된 어드레스 및 다른 필드들에 자동으로 채울 수 있다(auto-fill)(단계 326에서). 한 예의 실시 예에서 이러한 자동 채워진 정보는, 예를 들어, 배송 어드레스 및 혹은 소수의 모바일 전화번호를 포함하는 필요한 최소로 유지될 수 있다. 이용가능하다면, 이는 또한 페이스북과 같은 다른 소셜 네트워킹 웹사이트로부터 뽑아낸 사진과 같은, 다른 사용자 식별 정보를 반영할 수 있을 것이다. 입증자가 허용되지 않으면, 시스템은 시스템이 식별된 특정 고객과 상호 작용하는 것을 보장하기 위해서 고객 식별 매칭 프로세스(312)로 돌아가서 고객의 좀더 정확한 식별을 얻기 위해 사용자 정보를 보충한다. 이는 사기를 줄이는 한 방법이다.

1 이상의 실시 예에서, 318에서 고객에 대한 입증자 데이터 아이템이 수신된 고객 제어 데이터에서, 및/또는 내부 데이터 베이스 및/또는 외부 데이터베이스(들)에서 구해질 수 없다고 판정되면, 즉 고객이 식별되지 않았음을 나타낸다면, 온라인 서비스 시스템(214)은 322에서 온라인 서비스 시스템(214) 또는 상인 서버 시스템(206) 내의 고객 제어 데이터 수집 기능을 트리거하거나 입증자 데이터 아이템을 포함하는 고객 제어 데이터를 수신하도록 구성되어 있다.

고객에 대한 입증자 데이터 아이템이 수신된 고객 제어 데이터에서, 및/또는 내부 데이터 베이스 및/또는 외부 데이터베이스(들)에서 구해질 수 있다고 판정되면, 즉 고객이 식별되었음을 나타낸다면, 온라인 서비스 시스템(214)은 사용자 정보 데이터 세트(326)를 더 컴파일하고 사용자 정보 데이터 세트를 포함하는 액세스 장치 디스플레이 요청을 제공하며, 여기서 사용자 정보 데이터 세트는 고객 제어 데이터, 온라인 서비스 시스템(214)에 저장된 데이터 레코드, 내부 데이터베이스/데이터베이스들로부터 구한 데이터, 외부 데이터베이스/데이터베이스들로부터 구한 데이터, 또는 외부 소스(310)로부터의 데이터 중 임의의 것으로 이루어진 아이템들을 포함한다. 1 이상의 실시 예에서, 액세스 장치 디스플레이 요청은 온라인 서비스 시스템(214)으로부터 액세스 장치(208)로 전송된다. 1 이상의 실시 예에서 액세스 장치 디스플레이 요청은 온라인 서비스 시스템(214)으로부터 상인 서버 시스템(206)을 통해서 액세스 장치(208)에 전송된다.

입증이 발생되면, 시스템(214)은 328에서 신용/사기 정책 결정을 행할 수 있다. 이 결정은 정보가 수신되어 처리되자마자 이루어질 수 있다. 이 결정은 통상 거래 규모, 시스템이 사용자에게 사전에 할당한 임의 신용 한도, 상품의 유형, 사용자의 최근 거래 빈도 등을 포함하는 다수의 고려사항에 기반을 두고 있다. 이 결정을 기반으로, 시스템(214)은 거래 신용을 승인(330) 또는 거부(332)할 수 있다. 또한 고객에게 추가 정보를 요청하는 "비확실(Maybe)" 판정을 할 수도 있을 것이며(336에서), 시스템은 최종 "승인" 또는 "거부" 결정을 하기 위해서 추가 - 보통은 외부 - 자원들(338)에 액세스한다.

1 이상의 실시 예에서, 액세스 장치 디스플레이 요청을 제공한 후에 온라인 서비스 시스템(214)의 신용 평가 또는 신용 판정 기능은 신용/사기 정책 판정/결정을 더 실행하고(328) 그 결과는 거래/구매에 대한 승인된 신용의 판정(330), 거래/구매에 대한 거부된 신용의 판정(332), 또는 거래/구매에 대한 "비확실" 신용 판정으로 나타난다. 1 이상의 실시 예에서, 온라인 서비스 시스템(214)의 신용 평가 기능 또는 신용 판정 기능은 미리 정해진 규칙 세트에 따라서, 예를 들어, 선택된 물품의 가격에 대응하거나 그에 따른 값을 현재 고객에게 그리고 혹은 현재 구매에 할당된 신용 파라미터에 대한 레제베이션에 설정함으로써 신용/사기 정책 판정/결정을 실행한다. 한 예에서 이들 미리 정해진 규칙은 구매를 위해 선택된 물품의 가격을 초과하는 고객에 대한 평가된 현재 신용 한도액을 포함할 것이다.

한 실시 예에서, 구매 릴리스 파라미터는 거래/구매에 대해 승인된 신용의 판정(330)에 대응하는 값에 설정되고, 예를 들어, 신용 파라미터에 대한 레제베이션의 값이 성공적으로 설정되었다는 것에 응답해서 상인 서버 시스템(206)에 전달되며, 그래서 이 구매는 상인 서버 시스템(206)에 의해서 완료되도록 제어된다.

1 이상의 실시 예에서, 신용 파라미터에 대한 레제베이션의 값이 성공적으로 설정될 수 없는 경우에, 선택적으로 결제/지불의 대안 방법이 사용자(304)에게 제공되고, 성공적인 대안 결제/지불이 성취되면 구매 릴리스 파라미터가 거래/구매에 대한 승인된 신용의 판정(330)에 대응하는 값에 설정되고 상인 서버 시스템(206)에 전달되며, 그래서 이 구매는 상인 서버 시스템(206)에 의해서 완료되도록 제어된다. 대안 결제/지불이 성취되지 않으면, 구매 차단 파라미터가 거래/구매에 대한 거부된 신용의 판정(332)에 대응하는 값에 설정되고 상인 서버 시스템(206)에 전달된다.

1 이상의 실시 예에서, 신용 파라미터에 대한 레제베이션의 값이 성공적으로 설정될 수 없는 경우에, 구매 차단 파라미터는 거래/구매에 대한 거부된 신용의 판정(332)에 대응하는 값에 설정되고 상인 서버 시스템(206)에 전달된다.

유사하게, 한 실시 예에서 신용 파라미터에 대한 레제베이션의 값이 거래/구매에 대한 "비확실" 신용의 판정에 대응하는 값에 설정되는 경우, 온라인 서비스 시스템(214)은 추가의 고객 제어 데이터를 수신하기 위해서 상인 서버 시스템(206) 내의 또는 바람직하게는 온라인 서비스 시스템(214) 내의 고객 제어 데이터 수집 기능을 트리거하고(336) 위에 기술된 신용/사기 정책 판정/결정 단계(328)를 반복하도록 구성되어 있다.

대안으로 또는 보완으로서, 구매 차단 파라미터는, 예를 들어, 또한 타임 아웃 기능 런닝 아웃에 따라 상인 서버 시스템(206) 내에서 설정될 수 있다.

한 실시 예에서 구매의 완료는 상인 서버 시스템이 구매 릴리스 파라미터를 수신하고 구매된 물품의 배송을 개시하는 것은 물론이고 바람직하게는 완료 구매 파라미터의 확인이 상인 서버 시스템(206)으로부터 온라인 서비스 시스템(214)에 전달되어 통상 구매된 물품의 배송이 개시되는 것을 수반한다. 온라인 서비스 시스템(214)이 완료 구매 파라미터의 확인을 수신한 것에 대한 응답으로, 온라인 서비스 시스템(214)은 예를 들어 선택된 거래 프로세스를 통해서 고객으로부터 지불을 구하는 것은 물론이고 예를 들어 온라인 서비스 시스템(214)으로부터 상인 서버 시스템(206)으로의 거래를 통해서, 또는 상인에 관련된 다른 자금 이체 시스템을 통해서 상인에게 지불을 트리거하는 것을 포함하는 지불 프로세스를 실행한다.

이와 같이, 거래가 승인되면, 고객은 이하 기술되는 다양한 지불 방법 중 어느 것을 이용해서도 지불을 행할 수 있다. 이들은 통상은 지금 사고-나중 지불(buy now-pay later); 연장된 기간에 걸친 지불, 신용 카드로 지불, EFT(전자 자금 이체)에 의한 지불 등을 포함한다. 예를 들어, 고객이 거부된 신용이면, 이는 고객이 구매하는 것을 배제한다. 예를 들어, 이들 상황에서, 고객은 여전히 신용 카드, PayPal과 같은 온라인 지불 시스템 같은 것, 또는 다른 EFT 지불을 이용하여 원하는 물품을 구매할 수 있을 것이다. 한 예의 특징은 시스템이 고객이 이를 결제하고자 하는 방법(이를 청구서, 신용카드, PayPal 등으로 지급)을 알지 못하더라도 거래를 승인할 수 있다는 것이다. 지불은 체크아웃 프로세스에서 큰 마찰 포인트이며, 구입과 지불의 분리/개별화는 핵심 특징이다. 이는 예를 들어 신용을 발행함으로써 가능해진다. 체크아웃의 현재 구현에서는, 시스템은 고객을 14일 신용으로 채무를 유예(default)할 수 있다.

1 이상의 실시 예에서, 온라인 서비스 시스템(214)이 거래/구매에 대한 승인된 신용의 판정(330)을 한 후 결제 기능이 작동된다. 결제 기능은 지불 결제를 위한 다양한 옵션을 나타내는 한 세트의 결제 아이템을 포함하는, 결제 방법 요청을 액세스 장치(208)에 전송하고, 그럼으로써 액세스 장치는 그래픽 사용자 인터페이스를 통해서 사용자 즉 고객에게 결제 옵션들을 디스플레이해 준다. 사용자는 선택된 결제 아이템을 나타내는 입력을 액세스 장치에 행한다. 액세스 장치는 선택된 결제 아이템을 포함하는 결제 옵션 응답을 온라인 서비스 시스템(214)에 전송한다. 온라인 서비스 시스템(214)은 액세스 장치(208)로부터 결제 옵션 응답을 수신한다. 온라인 서비스 시스템(214)은 또한 예를 들어 온라인 서비스 시스템(214)으로부터 상인 서버 시스템(206)으로의 거래를 통해서 또는 상인에 관련된 다른 자금 이체 시스템을 통해서 상인에게 지불을 트리거한다.

위의 설명으로부터 알 수 있듯이, 이 시스템의 몇몇 예의 특징은 구매를 위한 자금이 리저브되기(reserved) 전에 구매 오더가 수락될 수 있고 물품(212)이 고객(204)에게 배송될 수 있다는 사실을 포함한다. 게다가, 구매 오더/거래는 물품(212) 리스트 값 및 다른 현재 구매 특성(물품 종류, 상인의 유형, 등), 및 외부 및 내부 고객-고유 스코어링 이력을 평가함으로써 평가(수락/거부)될 수 있다. 통상적으로, 지불 방법은 거래의 수락/거부를 판정하는데 이용되는 인자가 아니다. 그러나, 특정 경우들에서, 시스템(214)은 거래를 수락/거부하기 위한 결정을 하기 전에 고객에게 지불 방법을 선택할 것을 요구할 수 있다.

시스템은 또한 "동적" 계정 검색을 하는 것으로 특성화될 수 있다. 그래서 온라인 서비스 시스템(214)은 고객(204)이 제공한 증분(작은 양의) 계정 정보를 기반으로 고객(204)에게 고객 식별 정보를 강요할 수 있다. 그러므로, 고객(204)의 관점에서 볼 때, 구매(거래)하는데 사용자 이름이나 패스워드가 요구되지 않으며 배송 정보는 신원의 입증 동안 확인될 수 있는 것으로 보인다.

그래서, 온라인 서비스 시스템(214)은 구입 및 배달 후 지불을 보다 안전하고 쉽게 하기 위해서 신용도 검사를 이용한다. 이는 구입과 지불 행위를 분리해서 구입에 대한 "마찰"을 줄일 수 있다. 위에 기술된 바와 같이 그리고 이하 좀더 상세히 기술되듯이, 온라인 서비스 시스템(214)은 단지 거래에 실질적으로 필요한 정보를 입력할 것을 고객(204)에게 요구하며, 이하에서 분석되는 바와 같이 고객을 식별하고 고객과 거래 쌍의 신용 위험을 판정하기 위해 충분한 정보가 구해질 때까지 필요한 입력 정보를 점차 늘려간다. 그러나, 위에 기술된 바와 같이, 시스템은 고유하고 배타적인 사용자 ID 및 패스워드를 생성하거나 요구하지 않지만 예를 들어 이-메일 어드레스와 같이 고객에게 내재적으로 고유할 수 있는 정보를 여전히 요청한다. 이때 고유 정보는 ZIP 코드와 같은 다른 고객-제공 정보에 의해서 입증/검증될 수 있다. 이를 좀더 쉽게 하기 위해서, 온라인 서비스 시스템(214)은 고객이 충분한 입증으로 식별되자마자 체크아웃 양식으로 된 고객에 대한 정보를 미리-채울 수 있다. 식별시에, 위험-평가가 있으면 고객은 즉시 위험 평가에 따라서 이하 상세히 기술되는 다른 구매 방법들을 구할 수 있다. 또한, 이하 좀더 상세히 기술되듯이, 고객(204)은 또한 다수의 상인들에 걸친 다수의 거래를 모아서 한번에, 예를 들어, 월말에 전체 부채를 결제할 수 있다.

도 3b은 도 3a에 도시된 흐름의 거래 실시 예와는 약간 다른 실시 예의 개요를 제공한다. 기술된 단계들의 순서는 상이한 실시 예들에서는 바뀔 수 있다.

도 3b에 도시된 바와 같이, 거래 흐름은 일련의 이산 국면 또는 단계들, 즉 ID 캡처 국면(340), 데이터 검색 국면(350), "고유 식별" 단계(360), 이행fulfillment) 정보 검사(370), 위험 평가 단계(380), 및 사기 검사(390)를 포함한다.

ID 캡처 국면(340) 동안, 342에서 거래의 개시에 응답해서, 시스템은 344에서 직접 사용자(204)로부터 또는 소셜 미디어 사이트(346)와 같은 제3자 소스로부터 사용자 식별자를 구한다. 데이터 검색 국면(350) 동안, 시스템은 352에서 추가의 사용자 데이터를 검색하기 위해 단계 344로부터의 사용자 식별자를 이용한다. 통상적으로 이는 사용자 식별자(단계 344로부터의)를 내부 데이터베이스(354)에 전달함으로써 실행되고, 이는 매치가 발견될 때 시스템에 대한 이용을 위해 고객 데이터(356)를 반환한다.

후속 "고유하게 식별" 단계(360) 동안 시스템은 특정 사용자(204)가 고유하게 식별될 수 있는지 여부를 판정하기(362에서) 위해 단계 344로부터의 사용자 식별자와 단계 352로부터의 검색된 사용자 데이터를 이용한다. 시스템이 사용자(204)를 고유하게 식별하기에 충분한 정보가 제시되어 있지 않다고 판정하면, 시스템은 사용자 장치(도시되지 않음)를 이용하여 추가 정보를 입력하도록 단계 366을 통해서 사용자에게 촉구한다. 이러한 반복 프로세스 - 단계 344 내지 단계 352 및 362 - 는 특정 사용자(204)를 고유하게 식별하기 위해 충분한 정보가 사용자로부터 또는 시스템의 내부 데이터베이스(354)로부터 검색될 때까지 반복된다. 이는 1보다 많은 사용자의 사용자 식별자가 동일하거나 2명의 사람 이름이 동일한 상황에 대처하는 것이다.

이행 검사(370) 동안, 사용자(204)가 362에서 고유하게 식별되면, 시스템은 372에서, 단계 342에서 개시된 거래를 이행하기에 충분한 정보를 갖고 있는지 여부를 판정한다. 통상 이는 시스템이, 예를 들어, 물리적 물품의 배달을 위한 어드레스 또는 SMS 또는 어떤 다른 전자 콘텐츠 형태의 배달을 위한 사용자의 모바일 전화번호를 갖고 있는지 여부의 검사를 수반할 것이다. 이들은 "어드레스"의 2가지 예이다. 다른 예의 어드레스는 이-메일 어드레스나 개시된 거래(342)에 필요한 물품의 배달을 위해 적합한 임의 다른 어드레스를 포함할 수 있다. 다시 한번, 시스템이 372에서 거래를 이행하기에 충분한 정보가 없다고 판정하면, 시스템은 추가 정보를 단계 366을 통해서 사용자에게 촉구할 것이다. 이전과 같이, 이 프로세스는 342에서 개시된 거래를 이행하기 위해 충분한 정보가 존재할 때까지 반복된다.

이 후에, 위험 평가 단계(380) 동안, 시스템은 내부 알고리즘을 이용하여 특정 사용자(204) 및 개시된 거래(342)에 대한 위험을 "감수"할 수 있는지 여부를 결정한다. 단계 382에서, 예를 들어 시스템은 사용자의 신용 저장 스코어, 구매 이력, 다른 행동 메트릭, 및 심지어는 구매의 규모를 고려할 것이다. 다른 고려 사항도 적용될 수 있을 것이다. 다시 한번 382에서 위험 결정을 하기에 충분한 정보가 존재하지 않는다면, 시스템은 추가 정보를 요청하기 위해 단계 366을 통해서 사용자에게 복귀한다. 이전과 같이, 이 프로세스는 시스템이 위험 결정을 할 수 있게 충분한 정보가 구해질 때까지 반복된다.

시스템이 거래를 처리하는데 위험이 충분히 낮다고 결정을 하면, 이는 사기 검출 단계(390)로 진행한다. 이 단계(390) 동안 시스템은 사용자의 "무결성"을 확실히 "보증"할 수 있도록 392에서 검사를 행한다. 단계 392는 사용자(204)가 사용자가 주장하는 사람임을 보장하는 것이다. 어떤 상황들에서, 시스템은 사기 검사 목적을 위해 추가 정보를 제공하라고 사용자에게 요구할 것이다. 여기에 기술된 바와 같이, 그러한 추가 정보는 그 본성상 단계 344에서 제공된 사용자 식별 정보로부터 추론될 수 없을 것이다. 그래서, 예를 들어, 사용자가 단계 344에서 이메일 어드레스를 제공하였다면, 시스템은 시스템이 사람 식별의 거짓 이용을 검사할 수 있도록 우편번호나 집 코드를 요청할 수 있을 것이다. 이 거짓 검출을 실행하는 다른 방법은 사용자가 페이스북이나 어떤 다른 소셜 미디어 사이트를 통해서 로그인을 했는지 여부를 판정하는 일일 것이다. 다시 한번 시스템이 392에서 사용자 무결성을 보장할 수 없다면, 이는 추가 정보를 위해 단계 366을 통해서 사용자에게 복귀한다.

시스템이 사기 검사(390)를 수행하고 사용자(204)가 사용자가 주장하는 그 사람이라는 것이 어느 정도의 확실성에 도달하면, 시스템은 선택적으로 사용자에 의한 최종 입증을 위해 나머지 사용자 데이터를 사용자(204)에 제시할 수 있다(단계 394에서). 이 정보가 입증(선택적으로)되면, 거래는 396에서 실행될 수 있다. 여기에 기술된 바와 같이, 그러한 추가 입증 단계(394)가 필요 없거나 때로는 바람직하지 않은 특정 상황들이 있다.

고객 체험의 추가 세부 사항은 도 4 내지 8의 스크린 샷들을 참조로 아래에 설명된다.

고객 체험의 더 많은 예

온라인 서비스 시스템(214)에 관한 고객 체험의 다양한 비-제한 예는 도 4a 내지 4i는 물론이고 후속 도면들 내의 스크린 샷을 참조로 설명될 수 있다.

구체적으로, 도 4a에 도시된 스크린 샷(402)은 고객(204)(이들 도면에는 도시되지 않음)에 의한 구매를 위한 아이템들(404a, 404b, 404c)의 선택을 제의한다. 고객이 구매할 아이템(이 경우에는 404b에 도시된 펜)을 선택할 때, 이 아이템은 자동으로 고객 쇼핑 카트(406)에 추가될 수 있다. 고객(204)이 "고 투 체크아웃(go to checkout)" 버튼(408)을 선택할 때, 스크린은 도 4b에 표현된 것으로 바뀔 수 있다.

도 4b에 도시된 바와 같이, 이제 고객(204)에게 그/그녀 자신을 식별할 수 있는 기회가 주어질 수 있다. 이 프로세스를 가능한 단순하게 유지하기 위해서, 고객(204)은 고객 식별 섹션(412)의 상부에 있는 이-메일 어드레스 블록(410)에 고객 제어 데이터의 제1 아이템을 이메일 어드레스 형식으로 채우도록 유도될 수 있다. 이때 고객(204)은 도 4c에 도시된 바와 같이 식별 이-메일을 입력할 수 있다. 이 행위가 실행되면, 도 4d에 도시된 바와 같이, 고객(204)은 블록(414)에 집 코드의 형태로, 입증자라고도 불리는 고객 제어 데이터 아이템의 제2 아이템을 입력하도록 재촉받을 수 있다. 이는 도 4e에 도시되어 있다.

이-메일 어드레스와 칩 코드 쌍의 결합 이용은 사기 거래의 기회를 줄여준다. 이들 2개 필드는 통상은 관련되어 있지 않으며 쉽게 해킹/상관되지 않지만, 보통은 위에서 예시한 바와 같이 온라인 서비스 시스템(214)에 의해 접근될 수 있는 다양한 데이터 소스에 관련되어 있다. 그래서, 페어링(pairing)은 고객(204)을 고유하게 식별하는 좋은 방법일 수 있다. 이하 설명되는 바와 같이, 많은 다양한 페어링이 이용될 수 있고, 이는 단지 일례이다. 사실, 특정 상황들에서, 이 예의 페어링은 적절하지 않을 수 있고 대신에, 예를 들어, 지오-로케이션 및 IP 어드레스 검사가, 실례와 같이 다시 한번 이용될 수 있을 것이다.

고객(204)의 이-메일(410) 및 집 코드(414) 쌍의 입력에 응답해서, 시스템은, 그의 데이터베이스(도 3에 관련해서 설명된)에서, 고객(204)의 이름과 어드레스 내역을 찾을 수 있다. 도 4f에 도시된 바와 같이, 시스템은 이 정보를 어드레스 필드들(416)에 자동으로 덧붙일 수 있다. 이 자동-덧붙이기는 어떤 추가 정보를 채울 필요가 없는 고객에게도 유용하고 또한 적절한 식별이 성취되었음을 고객이 확인할 수 있게 무결성 검사로서의 역할을 하는데도 유용할 수 있다. 예를 들어, 자동-덧붙이기 프로세스는 이러한 입증이 일어날 때까지는 꼭 발생하는 것이 아니며, 그래서 제3자가 그 밖의 누군가의 어드레스 정보를 구하기 위해 이-메일 어드레스를 단순히 입력하는 것이 방지된다. 또한 이 도면에 도시된 바와 같이, 어드레스 필드들은 "그레이드 아웃(grayed out)"되어 이들이 고객에 의해서 변경될 수 없음을 나타낼 수 있고, 그래서 추가 레벨의 보안이 제공된다. 특정 상황들에서, 고객은 이 정보를 바꾸는 것이 허용될 수 있지만, 이러한 일이 발생하면, 신용이 시스템(214)에 의해 증진되기 전에 추가 보안 검사가 요구될 수 있다. 그레이드 아웃 정보가 변경될 수 있는 경우의 예들은 모바일 전화번호의 변경, 결혼에 따른 성 변경, 주거지(또는 배송) 어드레스의 변경 등을 포함한다.

도 4f는 또한 고객(204)의 모바일 전화번호(또는 그의 적어도 일부)가 고객 식별 섹션(412)의 블록(418)에 반영되어 있음을 보여주고 있다.

고객(204)의 내역이 올바르게 덧붙여지면, 고객(204)은 "지금 구입(buy now)" 버튼(420)을 선택하고 도 4g에 도시된 확인 스크린으로 진행할 수 있다. 예를 들어, 이때, 고객(204)은 시스템에 로그인하지 않았을 뿐만 아니라 지불, 배송 어드레스, 정보를 전혀 제공하지 않았다. 대신에 고객(204)은 단지 이메일 어드레스와 집 코드를 이용하여 자동으로 식별되었다. 더욱이, 시스템이, 고객(204)의 내역을 구하는 것 외에도, 고객(204)의 내역, 과거 이력, 공적으로 이용가능한 신용 정보 및 구매의 규모와 유형을 기반으로 고객(204)에 관한 신용도 검사 - 다른 곳에서 기술된 바와 같이 - 를 완료했을 수도 있다. 이러한 모든 것은 정보가 수신될 때 일어나며 고객(204) 및 고객(204)이 구매를 하고 있는 웹 사이트의 상인에게 투명하다.

게다가, 시스템이 고객(204)을 바르지 않게 식별한 경우 고객(204)에게는 고객 변경 버튼(422)을 선택할 수 있는 기회가 주어질 수 있다. 이는 고객 식별 오류에 의해 생기는 문제점을 줄여줄 수 있다. 그러나, 위에서 나타낸 바와 같이, 그러한 변경들은 추가 보안 절차를 작동시킬 수 있고 고객에게 추가 정보를 입력하게 하고/추가 신용 입증 프로세스를 거치도록 요구할 수 있다.

이제, 도 4g에 도시된 예의 구매 확인 스크린(424)으로 가 보면, 고객(204)에게는 "청구서 이미지"(426)로 표현된 청구서 지불을 이용한 지연 지불 방법을 이용하여 지불할 수 있는 기회가 자동으로 주어질 수 있다. 이 청구서는 제품과 함께 및/또는 개별적으로 고객에게 메일로 발송될 수 있다. 이는 또한 이-메일, SMS, 제3자 웹사이트 메시지 등으로 전송될 수 있다. 어떤 상황들에서, 시스템(214)은 또한 고객의 은행 계정으로부터의 자동 차변 거래(automatic debit transaction)를 작동시킬 수 있다. 위에 나타낸 바와 같이, 고객이 주문한 물품(들)은 고객이 지불하기 전에 고객에게 물리적으로 배송되거나 다운로드될 수 있다. 그러나, 시스템이 행한 신용 평가를 기반으로, 상인에게는 시스템이 지불할 수 있고 고객은 나중에 시스템에 지불할 수 있다. 그래서 상인은 고객 디폴트의 위험을 전혀 감수하지 않아도 되고, 고객은 나중에 지불하기 때문에, 고객은 상인에 의한, 배송 실패 또는 물품 손상과 같은 성능 결함의 위험을 감수하지 않아도 된다.

또한, 청구서가 고객에게 주기적으로 전송되는 경우에, 다수의 아이템에 대한 단일 청구서가 고객에게 전송될 수 있다. 어떤 경우들에서는, 이들 다수의 아이템은 다수의 벤더로부터 나올 수 있다. 그래서, 고객은 다수의 벤더에 걸친 다수 구매에 대한 미지급 지불들을 단일 지불로 결제할 수 있다.

물론, 고객이 다른 유형의 지불 방법을 이용하기를 원할 수 있다. 이러한 이유로, 지불 스크린(424)은 고객에게 다른 지불 방법들(428)을 선택할 수 있는 옵션을 제공한다. 고객이 대안 방법들(428) 중 임의 것을 선택하면, 지불 스크린(430)이, 도 4h에 도시된 바와 같이, 제시될 수 있다.

이 스크린은 다음과 같은 5개의 상이한 지불 방법 예를 보여주고 있다:

(i) 특정 구매에 대한 송장을 결제할 수 있는 기간인 14일을 고객에게 제공하는 정규 단일 구매 송장 옵션(432);

(ii) 위에서 기술된 바와 같이 고객이 일련의 구매를 단일 월(또는 다른 주기) 결제로 종합할 수 있게 해주는 결합 송장 옵션(434);

(iii) 고객이 구매를 할부로 지불할 수 있게 해주는 할부 플랜 옵션(436);

(iv) 신용 카드로 지불할 수 있는 옵션(438); 및

(v) 전자 수표 또는 다른 전자 자금 이체 메커니즘을 이용하여 지불할 수 있는 옵션(440).

도 5a 내지 5d는 고객이 온라인 서비스 시스템(214)에 의해 식별될 수 없는 경우의 예를 보여주고 있다. 이전과 같이, 고객은 옵션(502)의 메뉴로부터 쇼핑 카트(506)에 추가되는 아이템(504b)을 선택한다. "체크아웃(Checkout)" 버튼(508)을 선택할 때, 고객은 도 5b에 도시된 바와 같이 블록(510)에 이-메일 어드레스를 그리고 블록(514)에는 집 코드를 입력하도록 유도될 수 있다. 그러나, 이 예에서, 시스템은 고객을 식별할 수 없고, 그래서 이는 고객에게 추가 증분 정보, 예를 들어, 개인 정보 섹션(516) 내의 블록(515)에 입력될 이름을 촉구할 수 있다. 그래서, 도 4a 내지 4I의 예와는 달리, 이 섹션은 시스템에 의해 자동으로 채워지지 않는다.

예를 들어, 시스템이 아직도 이 고객을 식별할 수 없다면, 이는, 도 5c에 도시된 바와 같이, 고객에게 고객의 모든 개인 정보를 블록들(516)에 추가하고 모바일 번호를 블록(518)에 추가하도록 촉구한다. 이 스테이지에서, 도 5d에 도시된 바와 같이, 고객은 지불 옵션 서브-스크린(550)에서 지불 방법을 선택하도록 요청받을 수 있다. 고객이 즉시 지불 방법들 중 하나, 예를 들어, 신용 카드에 의한 지불을 선택하면, 이는 고객에게 신용 카드 내역 등을 요청함으로써 처리되며 신용 카드 거래가 진행되고 일반적인 전자 상거래 관례에 따라서 물품들이 배송된다.

특정 상황들에서, 고객이 지연 지불 방법을 선택할 때, 추가로 신용 검사들이 실시간으로 행해질 필요가 있을 수 있고, 이들 신용 검사가 클리어하게 될 때만 물품들이 고객에게 배송될 것이다. 이러한 프로세스는 고객으로부터의 추가 정보 및 제3자 데이터베이스, 신용 등급 시스템 등을 이용한 검사를 필요로 할 수 있다.

도 6은 온라인 서비스 시스템(214)이, 예를 들어, 페이스북과 같은 제3자 소셜 미디어 플랫폼과 상호 작용하고 이를 이용할 수 있는 방법을 보여주고 있다. 도 6a에서, 고객이 로그인을 하지 않고 다시 아이템(604b)을 선택하고 체크-아웃에 도 6b에 도시된 이-메일 어드레스 입력 옵션(610)이 제시된다. 그러나, 이-메일을 입력하는 대신에, 고객은 "페이스북의 로그 인(Log in with Facebook)" 버튼(613)을 선택하고, 도 6c에 도시된 바와 같은 확인이 표시된 후, 온라인 서비스 시스템(214)은 직접 페이스북, 또는 다른 유사한 소셜 네트워크로부터 고객의 이-메일 어드레스를 검색한다. 그러한 소셜 미디어 웹사이트들은 단지 유효 이-메일 어드레스로 작동하기 때문에, 시스템은 도 6d에 도시된 바와 같은 집 코드(614), 개인 어드레스(616) 및 모바일 전화번호(618) 필드들과 같은 나머지 개인 내역(612)을 찾아서 덧붙이기 위해 제3자 소셜 네트워크로부터 검색된 이미 입증된 이-메일 어드레스를 이용할 수 있다. 그래서, 제3자 소셜 미디어 웹사이트에의 로그 인은 시스템(214)에 대한 입증으로서 작용할 수 있다. 시스템은 또한 고객의 소셜 미디어 프로필 그림(619)을 끌어내어 이들을 고객에게 디스플레이할 수 있다. 이는 고객에 대한 추가 비주얼 입증자로서 역할을 할 수 있다. 이때 거래는 도 4a 내지 4i를 참조로 이미 기술된 것과 같이 진행할 수 있다. 또한, 임의 유형의 제3자 입증된 웹사이트가 작동할 수 있다. 여기에 도시된 소셜 미디어 예는 단지 예를 위한 목적이다.

실례를 들어 설명된 프로세스가 디지털 콘텐츠에 한정되지 않지만, 도 7a 내지 7f는, 예를 들어, 고객이 MP3 오디오 레코딩과 같은 디지털 콘텐츠(704a)를 선택한 다음, 도 7b에 도시된 바와 같이 제3자 소셜 네트워킹 사이트를 통해서 로그인(770)을 선택하는 구매를 보여주고 있다. 이 예에는, 사용자가 모바일 장치를 이용하는 것을 설명하고 있지만, 이는 모바일 장치가 아닌 다른 것에도 동등하게 적용될 수 있다. 이 경우에, 시스템(214)은 고객에게 단일 추가 정보, 모바일 전화번호(718)를 요청하며, 이 정보가 입력되면, 예를 들어, 도 7e에 도시된 바와 같이, "지금 구입" 버튼(776)의 컬러를 그레이드 아웃에서 풀 컬러로 변경함으로써 이 버튼이 선택되게 할 수 있다. 지금 구입 버튼(776)이 선택되면, 고객은 도 7f의 다운로드(Download) 버튼(778)을 이용하여 디지털 콘텐츠를 다운로드할 수 있다. 빌링 및 지불 옵션들은 이전과 같을 수 있고, 다시 이는 여기서 어떤 구매 거래에도 작용할 수 있을 것이고 디지털 콘텐츠는 일례일 뿐이다.

도 8a 및 8b는 다른 프로세스의 예를 도시하고 있다. 이 경우에, 고객은 제3자 소셜 미디어 웹사이트에 로그인되고 이 사이트를 통해서 상인의 웹사이트에 들어간다. 이렇게 될 때 고객 신원은 이미 확인될 수 있고 시스템(214)은 고객의 신용도를 검사할 수 있다. 도 8a에 도시된 바와 같이, 고객의 신용도가 구축되어있다면, 고객은 자동으로 그 자신을 식별하면서 "지금 구입"(850)을 할 수 있는 기회를 얻을 수 있다. 볼 수 있듯이, 예를 들어, 제3자 소셜 미디어 사이트로부터 고객의 프로필 그림(852)이 나와서 지금 구입 버튼에 디스플레이될 수 있다. 고객이 지금 구입 버튼을 선택할 때, 거래가 확인되고 앞서 기술된 바와 같이 배송 및 청구가 이루어질 수 있다. 예를 들어, 도 8b에 도시된 바와 같이, 고객에게는 디지털 콘텐츠 또는 다른 구매 아이템을 다운로드(854) 할 수 있는 기회가 주어질 수 있다.

도 8a 및 8b의 거래는 또한 고객이 물품을 구매하는 2개의 상이한 거래 흐름을 보여주는데 이용될 수 있다. 이들은 도 9a 및 9b를 참조로 실증될 수 있다. 어떤 예의 구분은 위의 많은 예에서 고객은 도 9b에서 거래 흐름이 상인의 사이트 외에서 일어나고 있지만 상인 사이트이거나 적어도 상인 사이트에 임베드되어 있는 체크아웃을 통과하는 것을 포함한다. 이때 상인은 "구입(Buy)" 버튼 그 자체를 사용할 수 있다.

도 9a에서, 고객(도시되지 않음)이, 예를 들어, 상인 A(902a)에게서 물품 A(904a) 및 물품 B(904b)를 구매한다. 이는 예를 들어 도 4a 등을 참조로 설명되어 있는 쇼핑 카트/체크아웃 모델(912a)을 이용함으로써 행해진다. 또한 실례를 들어 설명된 바와 같이, 고객은 다시 한번 체크 투/쇼핑 카트(check to/shopping cart)(912b)를 이용하여 상인 B(902b)로부터 물품 C(904c) 및 물품 D(904d)를 구입할 수 있다. 이때, 나중 스테이지에서, 고객은 온라인 서비스 시스템(214)에 의해 생성된 단일, 결합 송장(926)을 수신하고, 이후 지불한다.

도 9b에서, 그러나, 고객은 체크아웃/쇼핑 카트를 완전히 우회할 수 있다. 여기서 고객은, 예를 들어, 도 8a 및 8B에서와 같이, 지금 구입 버튼(950a)을 선택해서 상인 A(902a)로부터 물품 A(904a)를 구입할 수 있고; 이때 고객은 또한 쇼핑 카트 프로세스를 거치지 않고도 다시 한번 지금 구입 버튼(950b)을 선택함으로써 상인 A(902a)로부터 물품 B를 구입할 수 있다. 이후 이는 예를 들어 다시 한번 쇼핑 카트를 우회함으로써 상인 B(902b)로부터 구입된 물품 C(904c) 및 물품 D(904d)에도 반복된다. 모든 물품 A, B, C 및 D는 구매마다 자동으로 배송 또는 다운로드될 수 있고 이후 온라인 서비스 시스템(214)에 의해 생성된 단일 송장(926)에 합쳐지고, 이는 이전과 같이 지불된다. 그래서, 도 9a 및 9b에 도시된 거래 흐름에서, 고객은 동일한 두 상인(902a 및 902b)으로부터 동일 물품(A, B, C 및 D)을 구매할 수 있고, 같은 결합 송장(926)을 수신하며 정확히 같은 방식으로 송장(926)을 결제할 수 있다. 단지 차이는, 예를 들어, 고 9b의 예에서, 고객이 종래의 체크 아웃 프로세스를 거치지 않는다는 것이다.

결론

주제가 일련의 양호한 실시 예에 연관해서 기술되었지만, 이들 기술은 이 주제의 범위를 여기에 열거된 특정 형태들에 한정하는 것이 아니다. 대조적으로, 본 기술들은 첨부 청구항들에 의해 정의되는 주제의 정신 및 범위 내에 포함될 수 있으며 그 외에 이 방면의 보통의 숙련된 자가 이해할 수 있는 변경, 수정 및 균등물을 커버하는 것이다.

여기에 공개된 바와 같이, 본 발명들에 일치하는 피처들은 컴퓨터-하드웨어, 소프트웨어 및/또는 펌웨어로 구현될 수 있다. 예를 들어, 여기에 공개된 시스템들 및 방법들은, 예를 들어, 데이터베이스, 디지털 전자 회로, 펌웨어, 소프트웨어, 컴퓨터 네트워크, 서버, 또는 이들의 결합을 포함하는 컴퓨터와 같은 데이터 프로세서를 포함해서 다양한 형태로 구현될 수 있다. 더욱이, 공개된 구현들의 몇몇이 특정 하드웨어 컴포넌트들을 기술하고 있지만, 본 신기술에 일치하는 시스템들 및 방법들은 하드웨어, 소프트웨어 및/또는 펌웨어의 임의 결합으로 구현될 수 있다. 또한, 위에 언급한 피처들 및 다른 양태들 그리고 본 신기술의 원리들은 다양한 환경에서 구현될 수 있다. 그러한 환경들과 관련 응용들은 특히 본 발명에 따른 다양한 루틴들, 프로세스들 및/또는 동작들을 실행하기 위해 구축될 수 있고 또는 이들은 범용 컴퓨터 또는 필요한 기능을 제공하도록 코드에 의해 선택적으로 작동되거나 재구성될 수 있는 컴퓨팅 플랫폼을 포함할 수 있다. 여기에 공개된 프로세스들은 본질적으로 임의 특정 컴퓨터, 네트워크, 아키텍처, 환경 또는 다른 장치에 관련되어 있지 않으며, 하드웨어, 소프트웨어, 및/또는 펌웨어의 적합한 결합으로 구현될 수 있다. 예를 들어, 범용 머신들은 본 발명의 가르침에 따라 쓰여 있는 프로그램과 함께 이용될 수 있고, 또는 필요한 방법들 및 기법들을 실행하기 위해서는 전용 장치 또는 시스템을 구축하는 것이 더 편리할 수 있다.

로직과 같은 여기에 기술된 방법 및 시스템의 양태들은 필드 프로그램가능 게이트 어레이("FPGA"), 프로그램가능 어레이 로직("PAL") 장치, 전기 프로그램가능 로직 및 메모리 장치 및 표준 셀-기반 장치와 같은 프로그램가능 로직 장치("PLD")는 물론이고 주문형 반도체를 포함해서 다양한 회로 중 임의 것에 프로그램된 기능으로 구현될 수 있다. 양태들을 구현하기 위한 몇몇 다른 가능한 것은 메모리 장치, 메모리가 있는 마이크로콘트롤러(EEPROM과 같은), 임베디드 마이크로프로세서, 펌웨어, 소프트웨어 등을 포함한다. 더욱이, 양태들은 소프트웨어-기반 회로 에뮬레이션을 가진 마이크로프로세서, 이산 로직(순차 및 조합), 고객 장치, 퍼지(뉴트럴) 로직, 양자 장치 및 위의 장치 유형들 중 임의 것들의 하이브리드로 구현될 수 있다. 기반 장치 기술들은 다양한 컴포넌트의 유형, 예를 들어, 상보 금속-산화물 반도체("CMOS")와 같은 금속-산화물 반도체 전계 효과 트랜지스터("MOSFET") 기술, 에미터-결합 로직("ECL")과 같은 바이폴라 기술, 폴리머 기술(예를 들어, 실리콘-콘주게이티드 폴리머 및 금속-콘주게이티드 폴리머-금속 구조), 혼합 아날로그 및 디지털 등에 제공될 수 있다.

또한 여기에 공개된 다양한 로직 및/또는 기능들은 그들의 행동, 레지스터 전송, 로직 컴포넌트 및/또는 다른 특성의 관점에서 하드웨어, 펌웨어, 및/또는 다양한 머신-판독가능 또는 컴퓨터-판독가능 매체에 구현된 명령어를 이용하여 가능해질 수 있음에 유의해야 한다. 그러한 포맷된 데이터 및/또는 명령어가 구현될 수 있는 컴퓨터-판독가능 매체는 다양한 형태(예를 들어, 광학, 자기 또는 반도체 저장 매체), 및 무선, 광학 또는 유선 시그널링 매체 또는 이들의 임의 결합을 통해서 그러한 포맷된 데이터 및/또는 명령어를 전송하는데 이용될 수 있는 반송파를 포함하며, 이들에 한정되지 않는다. 반송파에 의한 그러한 포맷된 데이터 및/또는 명령어의 전송 예는 인터넷 및 1 이상의 데이터 전송 프로토콜(예로, HTTP, FTP, SMTP 등)을 경유한 다른 컴퓨터 네트워크를 통한 전송(업로드, 다운로드, 이-메일 등)을 포함하며 이에 한정되지 않는다.

본 발명의 방법, 기능 및/또는 시스템은 다양한 실시 예에서 위에 기술된 및 또는 첨부 청구항 들에 있는 기능들의 방법 단계들을 실행하도록 구성된 코드 부분들을 포함하는 1 이상의 컴퓨터 프로그램 제품에 의해 실현된다. 청구된 발명의 실시 예들은 컴퓨터-판독가능 매체, 및 적외선(IR) 이미지들의 시퀀스의 안정화를 실행하기 위한 비-일시 정보가 저장되어 있는 컴퓨터 프로그램 제품에 관한 것이다.

문맥이 달리 명료하게 요구하지 않는 한, 설명과 청구항들 전반에서, 단어 "포함한다", "포함하는" 등은 배타적 또는 완벽한 의미와 반대인 포괄적인 의미로 해석되며; 말하자면, "포함한다는 것이지 제한된다는" 의미가 아니다. 단수 또는 복수를 이용하는 단어는 각각 복수 또는 단수를 포함한다. 게다가, 단어 "여기에서", "아래에", "위에", "이하", 및 유사한 중요한 단어들은 이 출원을 이 출원의 임의 특정 부분들이 아니 전체로서 가리킨다. 단어 "또는"이 2 이상의 아이템의 목록을 참조로 이용될 때, 이 단어는 이 단어의 다음 해석들 모두를 포괄한다: 목록에 있는 아이템들의 임의 것, 목록에 있는 아이템들 모두, 및 목록에 있는 아이템들 중 임의 조합.

본 발명의 현재 양호한 특정 구현들이 여기서 구체적으로 기술되었을지라도, 여기에 도시되고 기술된 다양한 구현들의 변형 및 수정이 본 발명의 정신 및 범위를 벗어나지 않고도 행해질 수 있음은 본 발명에 속하는 방면에서 숙련된 장들에게는 자명할 것이다. 따라서, 본 발명은 적용 법의 규칙에 의해 요구되는 범위에만 한정되는 것이다.

이전의 상세한 설명은, 설명의 목적을 위해, 특정 실시 예들을 참조로 기술되었다. 그러나, 위의 예시적인 논의들은 완전한 것도 아니고 공개된 정밀한 형태들에 본 발명을 한정하는 것도 아니다. 많은 수정 및 변형은 위의 가르침에 비추어 가능하다. 실시 예들이 본 발명의 원리 및 그의 실질적인 응용을 설명하기 위해서 선택되고 기술되었으므로, 이 방면에 숙련된 자들은 본 발명 및 다양한 실시 예들을 이용하여 고려하는 특정 이용에 적합하게 다양한 수정을 할 수 있다.

본 발명의 양태들은 컴퓨팅 장치 및/또는 컴퓨터-판독가능 매체에 저장된 컴퓨터 프로그램에 의해 구현될 수 있음을 이해해야 한다. 컴퓨터-판독가능 매체는 디스크, 장치 및/또는 전파 신호를 포함할 수 있다.

반대로 명시되지 않는 한 본 발명이 다양한 대안적인 지향 및 단계 시퀀스를 취할 수 있음을 더 이해해야 한다. 또한 첨부 도면에 도시되고 이 명세서에서 기술된 특정 장치들 및 프로세스들은 첨부 청구항들에 정의된 신규 개념들의 단순한 본보기 실시 예들임을 이해해야 한다. 그러므로, 여기에 공개된 실시 예들에 관한 특정 디멘젼 및 다른 물리적인 특성들은 청구항들이 달리 명시적으로 언급하지 않는 한 제한으로 해석되지 않는다.

더욱이, 많은 수정 및 변경이 이 방면에 숙련된 자들에게 쉽게 일어날 수 있으므로, 도시되고 기술된 정확한 구성 및 동작들에 본 발명을 한정하고자 하는 것이 아니며, 따라서 모든 적합한 수정 및 균등물은 다음의 임의 청구항에 정의된 본 발명의 범위 내에 속하는 것으로 간주할 수 있다.

Claims

사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에, 적어도 하나의 통신 네트워크(210)를 통한 통신으로, 거래를 가능하게 하는 네트워크화된 컴퓨터-기반 시스템(202)에서, 상기 시스템(202)은 적어도 상기 사용자 장치(208) 및 상기 상인 시스템(206)과 통신하는 적어도 하나의 서버(214)를 포함하고, 상기 시스템은:
a. 상기 사용자 장치(208)의 디스플레이에 상기 사용자(204)에 대한 사용자 인터페이스를 제공하는 디스플레이 수단;
b. 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 상기 사용자(204)에 제공하기 위한 디스플레이 수단;
c. 상기 사용자(204)가 상기 제3자 소셜 미디어 서비스에 로그-인한 후에, 상기 사용자(204)에 대한 상기 소셜 미디어 서비스의 계정을 통해서 상기 사용자(204)를 입증(verify)하기 위해서 상기 제3자 소셜 미디어 서비스와의 통신을 구축하기 위한 입증 수단;
d. 상기 사용자(204)가 거래를 검토하고 확인(confirm)할 수 있게 해주는 확인 수단; 및
e. 상기 거래를 완료하기 위해 상기 상인 시스템(206)에 통지하기 위한 수단을 포함하는 시스템.
제1항에 있어서, 상기 디스플레이 수단은 신속 지불 옵션을 상기 사용자(204)가 선택한 것에 대한 응답으로, 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 상기 사용자(204)에 제공하는 시스템.
제1항 또는 제2항에 있어서, 상기 사용자(204)가 상기 소셜 미디어 서비스들을 통한 상기 사용자(204)의 입증을 인가하였는지 여부를 판정하기 위한 수단을 더 포함하는 시스템.
제3항에 있어서, 상기 사용자(204)가 상기 입증을 인가하였는지 여부를 판정하기 위한 수단은 상기 시스템(202)이 제공한 앱(app)을 통하는 시스템.
제1항에 있어서, 상기 시스템은 상기 사용자(204)가 상기 사용자 장치(208)의 디스플레이에 제공된 신속 지불 옵션을 선택할 수 있게 해주는 사용자 인터페이스 수단을 더 포함하는 시스템.
제1항 내지 제5항 중 어느 한 항에 있어서, 상기 사용자(204)가 상기 거래에 대한 복수의 대안 지불 수단 중 하나를 선택할 수 있게 해주는 수단을 더 포함하는 시스템.
제1항 내지 제6항 중 어느 한 항에 있어서, 상기 사용자(204)에게 추가 정보를 제공하도록 요구하고 추가의 제3자 시스템들(346)에 대하여 상기 사용자(204)를 입증하기 위한 수단을 더 포함하는 시스템.
사용자(204)를 인증(authenticating)하고 거래를 가능하게 하는 방법으로서, 상기 방법은 사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에, 적어도 하나의 통신 네트워크(210)를 통한 통신을 위한 네트워크화된 컴퓨터-기반 시스템(202)을 이용하여 실행되며, 상기 방법은:
a. 상기 사용자 장치(208)의 디스플레이에 상기 사용자(204)에 대한 사용자 인터페이스를 제공하는 단계;
b. 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 상기 사용자(204)에 제공하는 단계;
c. 상기 사용자(204)가 상기 제3자 소셜 미디어 서비스에 로그-인한 후에, 상기 사용자(204)에 대한 상기 소셜 미디어 서비스의 계정을 통해서 상기 사용자(204)를 입증하기 위해서 상기 제3자 소셜 미디어 서비스와의 통신을 구축하는 단계;
d. 상기 사용자(204)가 거래를 검토하고 확인할 수 있게 해주는 단계; 및
e. 상기 거래를 완료하기 위해 상기 상인 시스템(206)에 통지하는 단계를 포함하는 방법.
제8항에 있어서, 신속 지불 옵션을 상기 사용자(204)가 선택한 것에 응답으로, 제3자 소셜 미디어 서비스로의 로그-인의 옵션(613, 660)을 상기 사용자(204)에 제공하는 단계를 더 포함하는 방법.
제8항 또는 제9항에 있어서, 상기 사용자(204)가 상기 소셜 미디어 서비스들을 통한 상기 사용자(204)의 입증을 인가하였는지 여부를 판정하는 단계를 더 포함하는 방법.
제10항에 있어서, 상기 사용자(204)가 상기 입증을 인가하였는지 여부를 판정하는 단계는 상기 시스템(202)이 제공한 앱(app)을 통하는 방법.
제8항에 있어서, 상기 사용자(204)가 상기 사용자 장치(208)의 디스플레이에 제공된 신속 지불 옵션을 선택할 수 있게 해주는 단계를 더 포함하는 방법.
제1항 내지 제12항 중 어느 한 항에 있어서, 상기 사용자(204)가 상기 거래에 대한 복수의 대안 지불 수단 중 하나를 선택할 수 있게 해주는 단계를 더 포함하는 방법.
제1항 내지 제13항 중 어느 한 항에 있어서, 상기 사용자(204)에게 추가 정보를 제공하도록 요구하고 추가의 제3자 시스템들(346)에 대하여 상기 사용자(204)를 입증하는 단계를 더 포함하는 방법.
사용자(204)로부터의 입력을 수신하도록 구성된 사용자 장치(208)를 이용하는 원격 사용자(204)와 상인 시스템(206) 간에, 적어도 하나의 통신 네트워크(210)를 통한 통신으로, 거래를 가능하게 하는 네트워크화된 컴퓨터-기반 시스템(202)으로서, 상기 시스템은:
a. 적어도 상기 사용자 장치(208) 및 상기 상인 시스템(206)과 통신하며, 통신 네트워크(210)로 통신하도록 구성된 적어도 하나의 서버(214);
b. 상기 네트워크(210)를 통해 상기 사용자(204)가 개시한 적어도 하나의 사용자 구매 오더를 수신하기 위한 수단 - 상기 구매 오더는 적어도 오더 가격을 포함함 -;
c. 사용자 식별 정보의 적어도 한 아이템을 수신하기 위한 수단;
d. 적어도 하나의 데이터 저장소(354)와 통신하기 위한 수단;
e. 적어도 상기 수신된 사용자 식별 정보의 아이템을 이용하여 상기 적어도 하나의 데이터 저장소(354)로부터 고유 사용자 식별자(204)에 대한 사용자 데이터(356)를 검색하기 위한 수단;
f. 검색된 사용자 데이터를 이용하여 고유 사용자 식별자(204)를 판정하기(362) 위한 수단;
g. 상기 거래를 이행하기에 충분한 정보가 존재하는지 여부를 판정하기 위한 수단;
h. 상기 사용자 데이터와 오더 가격을 기반으로 상기 사용자(204)에 대한 신용 판정을 행하기 위한 수단;
i. 상기 거래가 사기일 가능성을 줄이기 위해서 사기 검출을 하기 위한 수단; 및
j. 상기 거래를 완료하기 위한 수단을 포함하는 시스템.
제15항에 있어서, 상기 거래를 이행하기에 충분한 정보는 상기 사용자 구매 오더가 물리적인 물품이면 적어도 물리적 배송 어드레스에 대한 정보를 포함하는 시스템.
제15항에 있어서, 상기 거래를 이행하기에 충분한 정보는 상기 사용자 구매 오더가 다운로드로 이행될 수 있다면 적어도 상기 사용자의 사용자 장치 정보 또는 이메일 어드레스를 포함하는 시스템.
제15항 내지 제17항 중 어느 한 항에 있어서, 상기 신용 판정은 적어도 상기 고유 사용자 식별자(204) 기반의 최대 신용 한도의 판정을 포함하는 시스템.
제15항 내지 제18항 중 어느 한 항에 있어서, 상기 사용자 정보의 적어도 하나의 아이템은 집(zip) 코드, 이메일 어드레스, 물리적 거리 어드레스, 모바일 전화번호, 및 일반 전화번호 중에서 적어도 하나인 시스템.
제15항에 있어서, 상기 사기 검출은 적어도 상기 오더 가격, 상기 사용자 식별 정보, 상기 사용자 데이터 및 상기 신용 판정 중에서 적어도 하나에 기반한 사용자 신원의 판정을 포함하는 시스템.
제20항에 있어서, 상기 사용자 신원이 판정될 수 없다면, 상기 서버는 추가 사용자 식별 정보를 요청하도록 더 구성되어 있는 시스템.
제15항에 있어서, 고유 사용자 식별자(204)가 발견될 수 없다면, 고유 사용자 식별자(204)가 발견될 수 있을 때까지 추가 사용자 식별 정보를 요청하기 위한 수단을 더 포함하는 시스템.
제15항에 있어서, 상기 서버(214)는 상기 신용 판정이 이루어질 때 신용 레제베이션(reservation for credit)을 생성하도록 더 구성되어 있는 시스템.
제15항 내지 제23항 중 어느 한 항에 있어서, 상기 서버(214)는 전자 자금 이체, 현금, 수표, 신용 카드, 직불 카드 및 은행 예금 중 적어도 하나를 통해서 상기 적어도 한 사용자(204)의 지불을 수신하도록 더 구성되어 있는 시스템.
제15항 내지 제24항 중 어느 한 항에 있어서, 상기 데이터 저장소(354)는 데이터베이스 및 분산 데이터베이스 중 적어도 하나인 시스템.
제15항 내지 제25항 중 어느 한 항에 있어서, 상기 서버(214)는 상기 사용자(204)가 지불 유형을 선택하기 전에 상기 거래를 완료하도록 더 구성되어 있는 시스템.
제15항 내지 제26항 중 어느 한 항에 있어서, 상기 저장된 사용자 정보는 제3자에 의해서 제공되는 시스템.
제15항에 있어서, 상기 신용 판정은 거래 상세 내역, 구매 물품, 사용자 내역, 상인, 오더 가격, 지불 계획, 사용자 수입, 지불 리마크, 사용자 지불 이력, 및 최근 사용자 구매 활동 중 적어도 하나를 기반으로 하는 시스템.
네트워크(210)를 통해 거래하는 방법으로서,
적어도 하나의 서버(214)를 경유해서,
네트워크(210)를 통해 통신하는 단계;
오더 가격을 포함해서 상기 네트워크(210)를 통해 사용자로부터 적어도 하나의 사용자 구매 오더를 수신하는 단계 - 상기 사용자 구매 오더는 상기 네트워크와 통신하는 사용자 장비(208)를 통해서 수신됨 - ;
사용자 식별 정보의 적어도 한 아이템을 수신하는 단계;
적어도 하나의 데이터 저장소(354)와 통신하는 단계;
상기 사용자 식별 정보를 이용하여 상기 적어도 하나의 데이터 저장소(354)로부터 고유 사용자 식별자(204)를 검색하는 단계;
상기 수신된 사용자 식별 정보의 적어도 하나의 아이템을 이용하여 상기 적어도 하나의 데이터 저장소(354)로부터 상기 고유 사용자 식별자(204)에 대한 사용자 데이터를 검색하는 단계;
상기 사용자 데이터를 기반으로 이행 판정을 하는 단계;
상기 사용자 데이터 및 상기 사용자 식별 정보를 기반으로 상기 고유 사용자 식별자(204)에 대한 신용 판정을 행하는 단계;
상기 사용자 데이터, 상기 사용자 식별 정보 및 상기 구매 가격 중 적어도 하나를 기반으로 사기 판정을 행하는 단계; 및
상기 거래를 완료하는 단계를 포함하는 방법.
제29항에 있어서, 상기 이행 판정은 상기 사용자 구매 오더가 다운로드에 대한 것이면 적어도 상기 사용자의 사용자 장치 정보 또는 이메일 어드레스에 관한 정보를 포함해서, 상기 거래를 완료하기 위한 충분한 정보가 존재하는지 여부를 판정하는 단계를 포함하는 방법.
제29항에 있어서, 상기 이행 판정은 상기 사용자 구매 오더가 물리적 물품의 배송에 대한 것이면 적어도 물리적 배송 어드레스에 대한 정보를 포함해서, 거래를 완료하기 위한 충분한 정보가 존재하는지 여부를 판정하는 단계를 포함하는 방법.
제29항 내지 제31항 중 어느 한 항에 있어서, 상기 신용 판정을 행하는 단계는 적어도 상기 고유 사용자 식별자(204)를 기반으로 최대 신용 한도를 설정하는 단계를 포함하는 방법.
제29항 내지 제32항 중 어느 한 항에 있어서, 상기 사용자 정보의 적어도 하나의 아이템은 집 코드, 이메일 어드레스, 물리적 거리 어드레스, 모바일 전화번호, 및 일반 전화번호 중에서 적어도 하나인 방법.
제29항에 있어서, 상기 사기 검출은 적어도 상기 오더 가격, 상기 사용자 식별 정보, 상기 사용자 데이터 및 상기 신용 판정 중에서 적어도 하나에 기반한 사용자 신원의 판정을 포함하는 방법.
제34항에 있어서, 상기 사용자 신원이 판정될 수 없다면, 추가 사용자 식별 정보를 요청하는 방법.
제29항에 있어서, 고유 사용자 식별자(204)가 발견될 수 없다면, 상기 방법은 고유 사용자 식별자(204)가 발견될 수 있을 때까지 추가 사용자 식별 정보를 요청하는 단계를 더 포함하는 방법.
제29항에 있어서, 상기 방법은 상기 신용 판정이 이루어질 때 신용 레제베이션을 생성하는 단계를 더 포함하는 방법.
제29항 내지 제37항 중 어느 한 항에 있어서, 상기 서버(214)를 경유해서, 전자 자금 이체, 수표, 신용 카드, 직불 카드, 은행 예금 및 현금 중 적어도 하나를 통해서 상기 적어도 한 사용자(204)의 지불을 수신하는 단계를 더 포함하는 방법.
제29항 내지 제39항 중 어느 한 항에 있어서, 상기 데이터 저장소(354)는 데이터베이스 및 분산 데이터베이스 중 적어도 하나인 방법.
제29항 내지 제40항 중 어느 한 항에 있어서, 상기 서버(214)를 경유해서, 상기 사용자(204)가 지불 유형을 선택하기 전에 상기 거래를 완료하는 단계를 더 포함하는 방법.
제29항 내지 제41항 중 어느 한 항에 있어서, 상기 사용자 식별 정보는 제3자에 의해서 제공되는 방법.
제29항에 있어서, 상기 신용 판정은 거래 상세 내역, 구매 물품, 사용자 내역, 상인, 오더 가격, 지불 계획, 사용자 수입, 지불 리마크, 사용자 지불 이력, 및 최근 사용자 구매 활동 중 적어도 하나를 기반으로 하는 방법.
컴퓨터-네트워크화된 거래들을 위한 시스템으로서,
적어도 하나의 서버(214)를 포함하고, 상기 적어도 하나의 서버(214)는
컴퓨터 네트워크(210)를 통해서 사용자 장비(208)로부터 오더 가격을 포함하는 거래 요청을 수신하고;
사용자 식별 정보의 적어도 한 아이템을 수신하고;
사용자 식별 정보와 사용자 데이터를 포함하는 데이터 저장소(354)와 통신하고;
상기 데이터 저장소(354)를 통해서 상기 저장된 사용자 식별 정보를 고유 상용자 식별자(204)에 매칭하고;
매칭된 고유 사용자 식별자(204)에 대한 사용자 데이터를 상기 데이터 저장소(354)로부터 검색하고;
상기 사용자 데이터가 상기 거래를 이행하기 위해 상기 고유 사용자 식별자(204)에 대한 충분한 정보를 포함하고 있는지 여부를 판정하고;
상기 사용자 식별 정보, 상기 오더 가격 및 상기 사용자 데이터 중 적어도 하나를 기반으로 상기 고유 사용자 식별자(204)에 대한 신용 판정을 행하고;
상기 사용자 식별 정보, 상기 사용자 데이터, 상기 오더 가격 및 상기 신용 판정 중 적어도 하나를 기반으로 상기 고유 사용자 식별자(204)에 대한 사기 판정을 행하고;
사용자 지불 정보를 수신하기 전에 상기 거래를 완료하도록
구성된 시스템.
제43항에 있어서, 상기 서버(214)는,
추가 사용자 식별 정보를 요청하고;
상기 추가 사용자 정보를 수신하고; 그리고
상기 거래를 완료하기에 충분한 정보가 있다는 것,
상기 신용 판정을 완료하기에 충분한 정보가 있다는 것,
상기 사용자 식별 정보를 고유 사용자 식별자에 매칭하기에 충분한 정보가 있다는 것, 및
상기 사기 판정을 하기에 충분한 정보가 있다는 것
중 적어도 하나를 상기 서버(214)가 판정할 때까지 추가 사용자 식별 정보 요청을 반복하도록 더 구성되어 있는 시스템.
제43항 또는 제44항에 있어서, 상기 사용자 식별 정보는 이메일 어드레스, 집 코드, 물리적 우편 거리 어드레스, 및 전화번호 중 적어도 하나를 포함하는 시스템.
제43항 내지 제45항 중 어느 한 항에 있어서, 상기 서버(214)는 제3자로부터 상기 사용자 식별 정보를 수신하도록 더 구성되어 있는 시스템.
제43항 또는 제46항에 있어서, 상기 거래를 이행하기 위한 상기 고유 사용자 식별자(204)에 대한 충분한 정보는 물리적 배송 어드레스, 상기 사용자의 이메일 어드레스 및 사용자 장비(208) 정보 중에서 적어도 하나를 포함하는 시스템.
제43항 또는 제47항에 있어서, 상기 제3자로부터 수신된 상기 사용자 식별 정보는 상기 제3자에 의해서 이미 검증된(validated) 시스템.
컴퓨터-네트워크화된 거래들을 가능하게 하는 방법으로서,
적어도 하나의 서버(214)를 통해서,
오더 가격을 포함해서 컴퓨터 네트워크(210)를 통해서 사용자 장비(208)로부터 거래 요청을 수신하는 단계;
사용자 식별 정보의 적어도 한 아이템을 수신하는 단계;
사용자 식별 정보와 사용자 데이터를 포함하는 데이터 저장소(354)와 통신하는 단계;
저장된 사용자 식별 정보를 상기 데이터 저장소(354)를 통해서 고유 사용자 식별자(204)에 매칭하는 단계;
매칭된 고유 사용자 식별자(204)에 대한 사용자 데이터를 상기 데이터 저장소(354)로부터 검색하는 단계;
상기 사용자 데이터가 상기 거래를 이행하기 위해 상기 고유 사용자 식별자(204)에 대한 충분한 정보를 포함하고 있는지 판정하는 단계;
상기 사용자 식별 정보, 상기 오더 가격 및 상기 사용자 데이터 중에서 적어도 하나를 기반으로 상기 고유 사용자 식별자(204)에 대한 신용 판정을 행하는 단계;
상기 사용자 식별 정보, 상기 사용자 데이터, 상기 오더 가격 및 상기 신용 판정 중 적어도 하나를 기반으로, 상기 고유 사용자 식별자(204)에 대한 사기 판정을 행하는 단계; 및
사용자 지불 정보를 수신하기 전에 상기 거래를 완료하는 단계를 포함하는 방법.
제49항에 있어서, 상기 서버(214)를 통해서,
추가 사용자 식별 정보를 요청하는 단계;
상기 추가 사용자 정보를 수신하는 단계; 및
상기 거래를 완료하기에 충분한 정보가 있다는 것,
상기 신용 판정을 완료하기에 충분한 정보가 있다는 것,
상기 사용자 식별 정보를 고유 사용자 식별자(204)에 매칭하기에 충분한 정보가 있다는 것, 및
상기 사기 판정을 하기에 충분한 정보가 있다는 것
중 적어도 하나를 상기 서버(214)가 판정할 때까지 추가 사용자 식별 정보 요청을 반복하는 단계를 더 포함하는 방법.
제49항 또는 제50항에 있어서, 상기 사용자 식별 정보는 이메일 어드레스, 집 코드, 물리적 우편 거리 어드레스, 및 전화번호 중 적어도 하나를 포함하는 방법.
제49항, 제50항 또는 제51항 중 어느 한 항에 있어서, 상기 서버(214)를 통해서 제3자로부터 상기 사용자 식별 정보를 수신하는 단계를 더 포함하는 방법.
제49항 또는 제50항에 있어서, 거래를 이행하기 위한 상기 고유 사용자 식별자(204)에 대한 충분한 정보는 물리적 배송 어드레스, 상기 사용자의 이메일 어드레스 및 사용자 장비(208) 정보 중에서 적어도 하나를 포함하는 방법.
제49항 또는 제52항에 있어서, 상기 제3자로부터 수신된 상기 사용자 식별 정보는 상기 제3자에 의해서 이미 검증된 방법.
온라인 거래를 인가하는 방법으로서,
데이터 저장소(354) 및 네트워크(210)와 통신하는 서버(214)를 통해서,
적어도 오더 가격을 포함해서 상기 네트워크(210)를 통해 사용자(204)로부터 상기 거래를 개시하라는 요청을 수신하는 단계;
적어도 하나의 사용자 식별자 정보를 수신하는 단계;
수신된 사용자 식별자 정보를 이용하여, 상기 데이터 저장소(354)로부터 사용자 데이터를 검색하는 단계;
상기 사용자 데이터로부터 고유 사용자 식별자(204)를 식별하는 단계;
상기 거래를 이행하기에 충분한 사용자 데이터가 존재하는지 여부를 판정하는 단계;
적어도 상기 고유 사용자 식별자(204)의 사용자 데이터를 기반으로 신용을 판정하는 단계;
사기 판정을 행하는 단계; 및
지불을 요청하기 전에 상기 온라인 거래를 인가하는 단계를 포함하는 방법.
제55항에 있어서, 상기 데이터 저장소(354)는 내부 사용자 데이터베이스인 방법.
제55항 또는 제56항에 있어서, 상기 사용자 식별자 정보는 사용자(204) 및 제3자(346) 중 적어도 하나로부터 수신되는 방법.
제55항 내지 제57항 중 어느 한 항에 있어서, 상기 서버(214)를 통해서, 고유 사용자 식별자(204)가 판정될 수 없다면 적어도 하나의 추가 사용자 식별 정보를 요청하는 단계를 더 포함하는 방법.
제55항 내지 제58항 중 어느 한 항에 있어서, 거래를 완료하기에 충분한 사용자 정보가 존재하는지 여부의 판정은 상기 사용자 데이터가 물리적 우편 어드레스, 상기 사용자의 이메일 어드레스 및 사용자 장비(208) 정보 중에서 적어도 하나를 포함하는지 여부를 기반으로 하는 방법.
제55항 내지 제59항 중 어느 한 항에 있어서, 상기 서버(214)를 통해서, 상기 거래를 이행하기에 충분한 정보가 존재하지 않는다면 적어도 하나의 추가 사용자 식별자 정보를 요청하는 단계를 더 포함하는 방법.
제55항 내지 제60항 중 어느 한 항에 있어서, 상기 신용 판정은 제3자(346)로부터의 정보를 포함하여 행해지는 방법.
제55항 내지 제61항 중 어느 한 항에 있어서, 상기 사기 판정은 상기 사용자 식별자 정보, 상기 사용자 데이터, 상기 오더 가격, 및 상기 신용 판정 중 적어도 하나에 기반을 두고 있는 방법.
제55항 내지 제62항 중 어느 한 항에 있어서, 상기 서버를 통해서, 사기 판정을 하기에 충분한 정보가 없다면 추가 사용자 식별자 정보를 요청하는 단계를 더 포함하는 방법.
온라인 거래를 인가하는 시스템으로서,
서버(214)를 포함하고, 상기 서버(214)는
데이터 저장소(354) 및 네트워크(210)와 통신하고;
적어도 오더 가격을 포함해서 상기 네트워크(210)를 통해 사용자(204)로부터 상기 거래를 개시하라는 요청을 수신하고;
적어도 하나의 사용자 식별자 정보를 수신하고;
수신된 사용자 식별자 정보를 이용하여, 상기 데이터 저장소(354)로부터 사용자 데이터를 검색하고;
상기 사용자 데이터로부터 고유 사용자 식별자(204)를 식별하고;
거래를 이행하기에 충분한 사용자 데이터가 존재하는지 여부를 판정하고;
적어도 상기 고유 사용자 식별자(204)의 사용자 데이터를 기반으로 신용을 판정하고;
사기 판정을 행하고;
지불을 요청하기 전에 상기 온라인 거래를 인가하도록
구성된 시스템.
제64항에 있어서, 상기 데이터 저장소(354)는 내부 사용자 데이터베이스인 시스템.
제64항 또는 제65항에 있어서, 상기 사용자 식별자 정보는 사용자(204) 및 제3자(346) 중 적어도 하나로부터 수신되는 시스템.
제64항 내지 제66항 중 어느 한 항에 있어서, 상기 서버(214)는 고유 사용자 식별자(204)가 판정될 수 없다면 적어도 하나의 추가 사용자 식별자 정보를 요청하도록 더 구성되어 있는 시스템.
제64항 내지 제67항 중 어느 한 항에 있어서, 상기 거래를 완료하기에 충분한 사용자 정보가 존재하는지 여부의 판정은 상기 사용자 데이터가 물리적 우편 어드레스, 상기 사용자의 이메일 어드레스 및 사용자 장비(208) 정보 중에서 적어도 하나를 포함하는지 여부에 기반을 두고 있는 시스템.
제64항 내지 제68항 중 어느 한 항에 있어서, 상기 서버(214)는 상기 거래를 이행하기에 충분한 정보가 존재하지 않는다면 적어도 하나의 추가 사용자 식별자 정보를 요청하도록 더 구성되어 있는 시스템.
제64항 내지 제69항 중 어느 한 항에 있어서, 상기 신용 판정은 제3자(346)로부터의 정보를 포함하여 행해지는 시스템.
제64항 내지 제70항 중 어느 한 항에 있어서, 상기 사기 판정은 상기 사용자 식별자 정보, 상기 사용자 데이터, 상기 오더 가격, 및 상기 신용 판정 중 적어도 하나에 기반을 두고 있는 시스템.
제64항 내지 제71항 중 어느 한 항에 있어서, 상기 서버는 사기 판정을 하기에 충분한 정보가 없다면 추가 사용자 식별자 정보를 요청하도록 더 구성되어 있는 시스템.