KR20180026498A - 전자 지불의 보안 처리 - Google Patents

전자 지불의 보안 처리 Download PDF

Info

Publication number
KR20180026498A
KR20180026498A KR1020187003235A KR20187003235A KR20180026498A KR 20180026498 A KR20180026498 A KR 20180026498A KR 1020187003235 A KR1020187003235 A KR 1020187003235A KR 20187003235 A KR20187003235 A KR 20187003235A KR 20180026498 A KR20180026498 A KR 20180026498A
Authority
KR
South Korea
Prior art keywords
transaction
payment
seller
user
merchant
Prior art date
Application number
KR1020187003235A
Other languages
English (en)
Other versions
KR102619230B1 (ko
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
Priority claimed from US15/000,685 external-priority patent/US11080700B2/en
Application filed by 로얄 뱅크 오브 캐나다 filed Critical 로얄 뱅크 오브 캐나다
Publication of KR20180026498A publication Critical patent/KR20180026498A/ko
Application granted granted Critical
Publication of KR102619230B1 publication Critical patent/KR102619230B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403Solvency checks
    • G06Q20/4037Remote solvency checks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/227Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

전자 지불 거래 및 다른 보안 데이터 프로세스의 처리에 유용한 전자 데이터의 보안 생성, 관리, 조작, 처리 및 저장을 위한 데이터를 처리하는 시스템(100, 900), 방법 및 머신 실행 가능 데이터 구조가 개시된다. 이러한 시스템(100)의 측면들은 네트워크화된 통신 장치(100) 및 판매자 시스템(130)이 신뢰된 개체(110', 130)로서 등록될 수 있는 신뢰된 플랫폼(120)을 포함한다. 계좌 혹은 지불 토큰과 같은 특정 지불 수단과 관련된 정보는 가상 혹은 전자 월렛(112)으로서 알려진 장치 보안 데이터 세트에 혹은 보안 지불 토큰의 형태로 저장될 수 있다. 특히 본 발명은 구매 및 다른 전자 거래의 대금을 지불하는데 다수의 지불 계좌의 사용을 가능하게 하는 개선점이 있다.

Description

전자 지불의 보안 처리
권리불요구
본 출원에 개시된 자료의 측면은 지불 거래 처리에 유용한 데이터의 생성, 관리, 조작, 처리 및 저장에 관한 것이다. 이러한 생성, 관리, 조작, 처리 및 저장의 측면은 정부 기관 및 다른 기관에 의한 규제를 받을 수 있다. 본 개시는 논리적 가능성, 기능적 가능성, 경제적 가능성 및 통신 가능성의 측면에만 관한 것이며, 법적인 고려, 규제적인 고려 혹은 다른 법률적인 고려에 관한 것은 아니다. 본 명세서에서 제안 혹은 개시되는 임의의 자료 혹은 그 용례가 임의의 관할에서의 임의의 법규, 법류, 규제 혹은 다른 법적 요건에 부합하거나 부합하지 않는다는 것을 나타내는 성명이나 표현을 본 명세서에 나타내는 것은 아니다.
관련 출원의 상호 참조
본 출원은 2015년 7월 2일자로 출원된 미국 가출원 제62/188,067호 "SECURE PROCESSING OF ELECTRONIC PAYMENTS", 2015년 8월 4일자로 출원된 미국 가출원 제62/200,859호 "SECURE PROCESSING OF ELECTRONIC PAYMENTS", 2016년 1월 19일자로 출원된 미국 출원 제15/000,685호 "SECURE PROCESSING OF ELECTRONIC PAYMENTS"를, 우선권을 포함한 모든 권한 및 이점을 주장하며, 각각의 전체 내용은 본 명세서에 참조로서 포함된다.
기술 분야
본 개시는 전반적으로 전자 신호 교환의 보안 실행에 관한 것이며, 더 상세하게는 다자 및 다수 장치 데이터 처리의 보안 협상, 인가, 실행 혹은 확인을 위한 개선된 시스템, 방법 및 프로그래밍 구조에 관한 것이다.
전자 지불은 일종의 전자 신호 교환 혹은 전자 데이터 거래로, 인간에게 중요한 이점을 제공했다. 다양한 이점에 더해서, 이러한 거래는 많은 위험에 연관된다. 많은 다양한 형태의 거래가 제안되어 있지만, 예컨대, 보안, 효율 및 유용성의 측면을 포함해서 개선할 상당한 여지가 있다.
모바일 및 다른 전자 상거래 지불은 현금, 신용 카드 및 직불 카드와 같은 종래의 지불 형태와 달리, 모바일, 데스크톱 및/또는 다른 장치로부터 시작된 전자 지불의 카테고리이다. 일부 모바일 및 전자 상거래 지불 거래에서는, 하나 이상의 인가된 지불 방법에 대한 크리덴셜을 포함한 사용자의 개인 정보를 저장하고 있는 사용자의 장치에 있는 프로그램 혹은 애플리케이션인 모바일 혹은 다른 가상 월렛을 사용한다. 예컨대, 사용자는 다수의 신용 카드 번호, 은행 계좌 번호, 쿠폰, 로열티, 기프트 및 리워드 프로그램 계좌 번호 등을 입력해서 저장하고, 이 월렛에 들어있는 논리 기능을 사용해서, 다수의 지불 형태 중 지불액 및 다른 거래 세부 사항을 거래, 지정 및 확인과 관련해서 사용할 어느 하나를 선택하고, 또는 거래 및 거래에 사용되는 계좌를 관리하거나 제어한다. 모바일 및 다른 가상 월렛의 보안을 강화하고, 사용자의 지불 크리덴셜 및 저장되어 있는 다른 민감한 정보를 보호하는데 보안 소자의 사용, 암호화, 토큰화 및 다른 기술이 사용될 수 있다.
이러한 가상 월렛의 중요한 제한은 이러한 월렛이 신용 카드의 발행 금융 기관(FI), 요구불/예금 계좌의 은행 등과 같은 개인 계좌 관리자에 결부된(tied) 날짜이다. 이는 하나 이상의 FI에 의해 관리되는 계좌에서 인출함으로써 거래를 완료하도록 인가받았으며, 이를 위해서 하나의 장치에 있는 다수의 가상 월렛을 다루어야 하는 고객 혹은 다른 구매자를 상당히 불편하게 할 수 있다.
가상 월렛을 사용해서 많은 타입의 거래를 개시하기 위해서, 사용자는 판매자의 POS(point-of-sale) 단말에 다가가서 스캐닝하거나 몇가지 다른 타입의 데이터 교환을 수행하기 위해서 모바일 장치를 제시할 수 있다. 예컨대, NFC(Near Field Communication) 거래에서, NFC 판독기와 모바일 장치가 서로 근접하면, NFC 판독기는 모바일 장치로부터의 지불 크리덴셜 및/또는 다른 거래-특정 정보를 요구할 것이다. 유사하게, 판매자 POS 단말에 의해 스캐닝되도록 모바일 장치에 표시된 바코드 및 QR 코드와 같은 시각적인 코드를 사용해서 모바일 월렛 및 판매자 POS 단말 사이에서 지불 크리덴셜 및 거래 정보가 교환될 수 있다. 모바일 지불 거래는 처리되기 전에 PIN의 입력이나 생체 식별과 같은 몇가지 타입의 다른 사용자 인증을 요구할 수도 있지만, 사용자 인증이 항상 요구되는 것은 아니다.
이와 달리, 전자 거래는 판매자 전자 상거래 웹사이트 및/또는 애플리케이션에 네비게이트 혹은 액세스하기 위해서 모바일 혹은 고정형 컴퓨팅 장치에 의해 개시되고, 이후에 키보드, 키패드, 터치스크린과 같은 입력 장치를 이용해서 관련 판매자 거래 시스템과 통신 세션을 개시하기에 적절한 커맨드를 입력할 수 있다.
따라서, 모바일 장치와 판매자 POS 단말 사이에서 비접촉식 거래가 완료된 것에 더해서, 사용자가 모바일 혹은 데스크톱 장치에 있는 판매자와 관련된 웹 사이트, 애플리케이션 혹은 프로그램 내에서 판매자와 거래를 직접 개시하는 다른 타입의 모바일 혹은 테스크톱-개시 지불이 일어날 수 있다. 이러한 거래는 사용자나 사용자의 지불 카드(혹은 기능적으로 동등한 임의의 것)가 판매자의 설비 혹은 POS 단말에 물리적으로 제시되지 않기 때문에 CNP(card not present)라고도 한다. 원래 CNP 거래는 주로 전화 혹은 메일에서 시작되었지만, 현재는 인터넷, PSTN(public switched telephone system) 혹은 네트워크-가능 거래 요구 통신 장치를 이용하는 것과 같은 컴퓨터 통신 네트워크에서 이루어질 수 있다.
컴퓨터 통신 네트워크를 사용해서 거래 및 거래 데이터를 처리할 때, 카드 발행자, 신용 카드 번호, 만료일 등과 같은 사용자의 신용 카드 정보를 판매자 애플리케이션이나 다른 인터페이스에 직접 제공해서 지불을 시작하는 것은 불안할 수 있다. 민감한 정보가 원치않는 집단과 공유될 위험에 놓일 수 있다. 예컨대, 이러한 원치않는 고유로 인해서, 신용 카드 정보는 사용자의 모바일 장치, 판매자의 서버, 혹은 지불 네트워크 내의 임의의 위치에 대해 행해진 악의적인 공격을 받을 수 있다. 잠재적인 보안 문제에 더해서, 사용자가 구입을 개시하고자 할 때마다 모바일이나 데스크톱 애플리케이션, 혹은 많은 다양한 애플리케이션에서 신용 카드 정보를 반복적으로 제공해야 한다는 것은, 상당한 시간이 걸려서 불편하고 짜증날 수 있다. 신용 카드 정보를 매번 재입력할 필요없이 또한 민감한 개인 정보를 노출시킬 가능성없이 애플리케이션 내에서 거래할 수 있다면, CNP 거래의 이러한 단점을 해결 혹은 완화시킬 수 있을 것이다.
은행 혹은 금융 기관과 프로세싱, 인증 및 정산하기 위해서, 판매자 POS 단말에서 혹은 판매자와 관련된 웹사이트, 애플리케이션 혹은 다른 프로그램에 액세스하는 네트워크화된 모바일 혹은 데스크톱 사용자 요청 통신 장치로부터, 거래 데이터가 많은 다양한 지불 네트워크 중 하나를 통해서 전송될 수도 있다. 그러나, 각각의 판매자 혹은 판매자 프로그램 혹은 애플리케이션이 서로 다른 지불 네트워크와 연관될 수 있기 때문에, 사용자는 판매자 혹은 애플리케이션으로부터 이용 가능한 지불 타입 및/또는 지불 방법에 제한을 받을 수 있다. 예컨대, 한 판매자가 특정한 타입의 지불을 인정하지 않을 수도 있고 및/또는 하나 이상의 요구불 예금 계좌가 거래를 완료하는데 이용 가능한 충분한 자금(혹은 다른 지불 재원)을 갖고 있지 않을 수도 있다. 다른 예로서, 모바일 혹은 데스크톱 장치에 있는 가상 월렛에 저장된 보안 지불 토큰이 거래를 완료하는데 반드시 필요하지 않을 수도 있기 때문에, 하나의 판매자 혹은 FI와 관련된 증명서 혹은 보안 암호화가 다른 판매자 혹은 FI에 의해 인정되지 않을 수도 있다.
첨부된 도면을 참조한다.
도 1은 본 개시의 측면에 따른, 데이터 처리에 사용하기에 적합한 예시적인 시스템을 나타내는 개략도,
도 2는 본 개시의 측면에 따른, 데이터 처리에 사용하기에 적합한 예시적인 시스템을 나타내는 다른 개략도,
도 3은 본 개시의 측면에 따른, 데이터 처리에 사용하기에 적합한 예시적인 시스템을 나타내는 또 다른 개략도,
도 4는 본 개시의 측면에 따른, 데이터 처리에 사용하기에 적합한 예시적인 시스템을 나타내는 또 다른 개략도,
도 5는 본 개시의 측면에 따른, 데이터 처리에 사용하기에 적합한 예시적인 시스템을 나타내는 또 다른 개략도,
도 6은 본 개시의 측면에 따른, 데이터 처리에 사용하기에 적합한 예시적인 시스템을 나타내는 또 다른 개략도,
도 7은, 도 6에 도시된 모바일 장치의 다른 개략도,
도 8은, 도 6에 도시된 모바일 장치의 다른 개략도,
도 9는 본 발명의 다양한 측면 및 실시예에 따른, 모바일 지불을 처리하는 예시적인 시스템을 나타내는 개략도,
도 10은 본 발명의 다양한 측면 및 실시예에 따른, 모바일 지불을 처리하는 다른 예시적인 시스템을 나타내는 개략도,
도 11은 본 발명의 다양한 측면 및 실시예에 따른, 모바일 지불을 처리하는 또 다른 예시적인 시스템을 나타내는 개략도,
도 12는 본 발명의 다양한 측면 및 실시예에 따른, 모바일 지불을 처리하는 또 다른 예시적인 시스템을 나타내는 개략도,
도 13은 본 발명의 다양한 측면 및 실시예에 따른, 모바일 지불을 처리하는 방법을 나타내는 흐름도,
도 14a 내지 도 14f는 본 발명의 다양한 측면 및 실시예를 구현하는데 사용되기에 적합한 그래픽 유저 인터페이스의 실시예를 나타내는 도면,
도 15a 및 15b는 본 발명에 따른 시스템의 실시예 및 시스템 내의 데이터 흐름을 나타내는 개략도
도 16은 본 발명의 다양한 측면 및 실시예를 구현하는데 사용되기에 적합한 그래픽 유저 인터페이스의 다른 실시예,
도 17, 19, 21 및 22는 본 발명에 따른 전자 지불의 보안 처리를 위한 시스템의 컴포넌트들 사이의 신호 교환을 나타내는 개략도,
도 18 및 20은 본 개시의 측면에 따른, 데이터 처리에 사용되기에 적합한 시스템의 예를 나타내는 개략도,
도 23a 내지 23c는 본 발명에 따른 시스템의 다른 측면을 나타내는 개략도이다.
설명을 명확하고 용이하게 하기 위해서, 도면에 사용되는 같은 참조 번호는 같은 혹은 유사한 부분을 가리킨다.
본 개시의 측면은, 전자 신호 교환의 보안 실행을 위한 시스템, 방법 및 영구(즉, 비일시적), 컴퓨터 판독 가능 매체에 저장된 머신-실행 가능 프로그래밍 구조를 제공하고, 더 상세하게는 지불 거래를 포함한 다자 데이터 처리의 고속의 보안 협상, 인가, 실행 및 확인을 위한 개선된 시스템, 방법 및 프로그래밍 구조를 제공한다. 다양한 실시예에서, 본 개시는 구매 및 다른 전자 재원(자금을 포함) 이체를 협상, 인가, 실행 및 확인하기에 특히 적합한 시스템, 방법 및 프로그래밍 구조를 제공한다.
본 개시에 따른 시스템 및 장치는, 구매 및 다른 금융 거래와 같은 데이터 처리의 보안을 간소화, 신속화 및 개선하는데 사용될 예컨대 신뢰된 인증 서버 혹은 플랫폼을 포함한 폭 넓은 컴포넌트를 포함할 수 있다. 금융 거래 처리에 사용하기에 적합한 본 발명의 실시예에서, 이러한 신뢰된 플랫폼은 예컨대 은행, 신용 카드, 로열티, 기프트, 리워드 혹은 다른 계좌 관리자, 지불 처리 서비스 및/또는 다른 금융 서비스 제공자에 의해 구현될 수 있다. 모바일, 데스크톱 및/또는 소비자, 기관 투자자 등이 사용하는 다른 네트워크 통신 장치와 같은 적절하게 구성된 요청 통신 장치, 그리고 적절하게 구성된 판매 및 지불 처리 장치도 포함될 수 있다.
개선된 거래 보안; 고속의 인증, 판결 및/또는 다른 처리; 그리고 통신 장비 사용의 개선된 효율(예컨대, 데이터 전송 대역폭)에 더해서, 본 개시에 따른 시스템, 장치 및 방법의 사용은, 하나 혹은 다수의 금융 기관 및/또는 다른 금융 서비스 제공자에 의해 유지, 관리 및/또는 제어될 수 있는, 특히 다수의 거래 자금 소스 및/또는 지불 소스에서 인출되는 성능과 관련된 더 편리한 혹은 덜 부담스러운 사용자 인터페이스, 및 일부 환경에서 이들의 물리적인 및/또는 경제적인 건강성 혹은 웰빙에 중요할 수 있는, 구매자, 판매자 및 FI의 일부가 거래를 완료하는데 증가된 성능을 포함한 다수의 이점을 제공한다. 본 개시로부터의 많은 다른 이점이 관련 분야에 종사하는 당업자에게는 자명할 것이다.
본 명세서에 개시된 시스템, 방법 및 프로그래밍 구조의 구현에 의해 제공되는 이점은 특히, 판매자, FI 및 다른 서비스나 상품 제공자가 제공하는 애플리케이션 혹은 다른 프로그래밍 구조를 사용한 구매의 '인앱' 처리 및 다른 거래에서 신뢰된 플랫폼을 사용하는 것이다.
예컨대, 구매자 혹은 다른 사용자의 모바일이나 데스크톱 컴퓨터와 같은 요청 통신 장치 및/또는 예컨대, 하나 이상의 가상 월렛 및/또는 판매자 애플리케이션을 포함한 여기에 설치된 하나 이상의 애플리케이션은, 인터넷과 같은 통신 네트워클ㄹ 통해서 중앙 등록 혹은 인증 플랫폼에 의해 혹은 이를 대신하여 운영되는 서버와 같은 신뢰된 인증 플랫폼 혹은 '신뢰된 플랫폼'으로 등록될 수 있다. 등록 완료시 혹은 그 이후 임의의 시점에, 구매와 같은 다양한 형태의 전자 처리를 완료하기 위해서 사전 인가된 예컨대 '신뢰된 장치'로서 요청 통신 장치를 확인 혹은 식별하기 위해서, 이러한 장치 및/또는 애플리케이션에는 신뢰된 플랫폼 및 다른 장치가 사용가능한 하나 이상의 보안 전자 토큰이 제공될 수 있다. 이하 설명한는 바와 같이, 이러한 토큰은 모바일 지불의 처리 및 완료에 사용하기 위해서 이러한 요청 통신 장치에 제공될 수 있는 보안 토큰에 포함될 수도 있고, 이 보안 토큰과 구별될 수 있다.
이러한 신뢰된 장치는 예컨대, 신뢰된 장치에서 실행되는 판매자의 애플리케이션과 같은 직접 인터넷 접속을 통해서 상품 혹은 서비스를 구입하는('인앱 지불') 소비자 혹은 다른 사용자에 의해 사용될 수 있다. 다른 예로서, 이러한 신뢰된 장치는, 자체가 서버에 신뢰된 장치로서 등록될 수 있는, 판매자와 연관된 모바일 POS 혹은 거래 프로세서('mPOS')와 같은 판매자 시스템과 로컬하게 통신해서 사용될 수 있다. mPOS는 이러한 환경에서, - 구매 혹은 다른 금융 거래의 예로서 - VisaNet 혹은 동등한 상표 등록된 지불 네트워크와 같은 추가 거래 처리 기관과 통신할 필요없이, 신뢰된 사용자와 관련된 거래 혹은 다른 데이터 처리에 대해서 신뢰된 서버와 직접 통신하는 것도 가능하게 될 수 있다. 이는, 이러한 기관과 통신할 때 전형적으로 집단을 인증하고 및/또는 거래를 인가하기 위해서는 민감한 데이터의 교환이 필요하다는 점에서, 그리고 이러한 교환은 시간 및 처리 리소스가 소비될 수 있으며 위험하다는 점에서, 바람직할 수 있다.
본 개시 전체에 개시된 바와 같이, 본 발명의 측면 및 실시예가 모바일 플랫폼 혹은 비모바일 플랫폼에 맞춰서 구현 혹은 최적화된다는 점에서 바람직하다는 것을 이해할 것이다. 그러나, 경우에 따라서, 모바일 및 비모바일 애플리케이션 모두에 효율 및 다른 이점이 있지만, 비모바일 애플리케이션에 대한 다른 유용성을 떠나서 어떤 동작을 취하지 않고도, 이러한 가능성이 특히 모바일 장치를 사용한 지불 및 다른 거래의 개시 및 실행의 가능성을 높이기에 특히 적합하다는 것을 이해할 것이다.
본 발명에 따른 신뢰된 플랫폼 혹은 거래 처리 시스템은, 구매 혹은 지불을 포함한 다른 거래에 더해서, 많은 타입의 데이터 처리 거래를 인증하고, 처리를 사용하며, 보안을 증가시키는데 사용될 수 있다. 예컨대, 이러한 시스템은 개인, 단체 등의 신원을 검증하는데 사용될 수 있다. 예컨대, 본 발명에 따른 신뢰된 거래 처리 시스템이 은행 혹은 다른 FSP(financial services provider)에 의해 혹은 이를 위해서 구현되고, FSP가 하나 이상의 은행, 신용, 로열티, 기프트, 리워드 및/또는 다른 계좌를 사용자 대신에 관리하며 사용자가 비지니스를 행하고자 하는 판매자 혹은 다른 서비스 제공자를 신뢰하고 있다면, 간접 검증/인가가 전체 개인 신뢰 과계의 결과로서 행해질 수 있다.
하나 이상의 신뢰 플랫폼(분산형 가상 플랫폼을 포함한)이 그룹 혹은 컨소시움을 위해서 가동되는 관리에 협력하는 다수의 은행들 또는 다른 FSP들 사이의 신뢰가 유사한 방식으로 성립 및 사용될 수도 있다. 예컨대, 각각의 은행은 신뢰된 플랫폼에 의해 인가된 다른 은행에 의해 입증 및 검증될 수 있다. 본 발명에 따른 요청 통신 장치, 판매자 시스템 및 FI 및/또는 다른 FSP 중 일부 혹은 전체 사이의 신뢰 관계는, 본 명세서에 개시된 신뢰된 네트워크 통신 프로토콜을 사용해서 구현될 수 있다.
다른 실시예에서, 본 발명에 따른 신뢰된 플랫폼은, 예컨대, 사용자가 효율적으로 자신의 개인 신원으로 거래에 대한 비용을 지불할 수 있도록, 신원에 기초해서 인증 및/또는 거래 완료하는데 사용될 수 있다. 이러한 거래에서는, 이러한 사용자의 신원을 나타내는 신호 데이터가 엄격한 온보딩 처리를 통해서 수신 및 등록되거나 혹은 입증 및 검증될 수 있고, 신뢰된 플랫폼의 서버에서 관리될 수 있으며, 이후에 이에 의존해서 거래 판결의 목적으로 재인가될 수 있다. 개개의 구매자 혹은 거래 개시자(사람 혹은 법인)는 소셜 매체 플랫폼에 대해, 특정 온라인 서비스(iTunes) 등에 대해 예컨대, 다양한 판결 혹은 다양한 거래 정확에서 다양한 신원을 갖거나 이와 연관될 수 있다. 이러한 검증은, 사용자의 스마트폰, 웨어러블 장치 혹은 다른 모바일 장치, 데스크톱 장치 혹은 다른 요청 통신 장치에 있는 ID 카드에 저장하기 위해서 검증된 신원을 나타내는 데이터에 대한 토큰이나 다른 표현 혹은 그 링크를 제공해서 구현 및 사용될 수 있다. 이러한 카드/장치는 탭해서 POS 혹은 다른 모바일 장치와 통신되게 될 수 있다. 신원은 POS/장치에 의해서, ID가 지불이 신뢰되거나 혹은 다른 의무를 충족하는지 검증할 서버로 포워딩될 수 있다. 지불의 형태는 사용자와 판매자 사이에서 동의될 수 있고, POS에 의해서 은행에 통신될 수 있다. 지불 방법은 모두 은행에 등록되어서 전송에 다른 정보는 필요없다.
다양한 측면 및 실시예에서, 본 발명은 자동 데이터 처리 시스템(컴퓨터)에서 본 명세서에 개시된 다양한 기능 및 처리를 구현하는, 영구 저장된 머신 실행 가능 명령어 세트를 포함한, 방법 및 추가 컴포넌트를 제공한다.
본 개시의 다양한 추가 측면 및 실시예에 따라서, 모바일 혹은 데스크톱 장치 환경 내에서 인앱 지불을 신속하고 보안적으로 완수하는 시스템 및 방법이 제공된다. 예컨대, 일부 실시예에서, 하나 이상의 가상 월렛 애플리케이션이 모바일 혹은 데스크톱 사용자 요청 통신 장치에 설치될 수 있으며, HCE(host card emulation) 토큰과 같은 하나 이상의 지불 크리덴셜을 보안 저장하도록 구성될 수 있고, 각각의 월렛은 사용자가 장치에 제공할 때 선택한 하나 이상의 지불 방법과 관련되어 있다. 이러한 가상 월렛 내에 저장된(즉, 월렛의 제어를 받는) 토큰 및 다른 지불 크리덴셜은 일반적으로 판매자 POS 단말에 위치된 NFC 판독기, 판매자 웹사이트 등이 다양한 상이한 지불 프로토콜에 따라서 거래를 완료하는데 이용 가능하다.
당업자가 이해하는 바와 같이, 본 개시와 유사하게 만들어진다면, 본 명세서에 개시된 가상 월렛 및/또는 다른 특성의 사용에 의존한 모바일 기반 혹은 클라우드 기반 처리를 포함한, 인앱, 인브라우저 및 다른 지불 거래 처리는 본 명세서에 개시된 예컨대 신뢰된 장치 및 장치 관련성을 사용해서 신뢰된 플랫폼 아키텍쳐를 사용해서 혹은 이와 함께 바람직하게 구현될 수 있다. 그러나, 다양한 실시예에서, 사용자 요청 통신 장치, 판매자 장치 및 신뢰된 플랫폼, 지불 프로세서 및/또는 카드나 발행자 시스템과 같은 다른 장치 사이의 신뢰 관계의 성립을 포함하지 않는 장치에 부분적으로 혹은 완전히 의존하는 것을 가능하게 한다는 점에서 바람직하다. 일부 실시예에서, 예컨대, 지불을 위한 보안 액세스를 가능하게 하는 대안 수단 혹은 다른 토큰을 제공하는데 및 구매자 장치, 판매자 장치 및 지불 프로세서와 다른 집단에 의해 제어되는 장치 사이에서 이러한 토큰을 통신시키는데 충분히 바람직할 수 있다.
당업자가 이해하는 바와 같이, 본 개시와 유사하게 만들어진다면, 본 명세서에 개시된 본 발명의 다양한 측면, 컴포넌트 및 실시예는 모바일 장치에 더해서 혹은 그 대신에 데스크톱, 서버 클래스 및 다른 비모바일 네트워크 요청 통신 장치 상에 구현될 수도 있다. 거래 요청을 통신하는데 사용하기에 혹은 본 명세서에 개시된 개체 및 프로세서를 구현하기에 적합한 임의의 타입의 통신 장치가 사용될 수 있다. 예컨대, 이는 스마트폰, 태블릿 컴퓨터, 손목 전화 및 스마트 워치나 주얼리와 같은 웨어러블 장치, 랩톱 컴퓨터, 데스크톱 컴퓨터, 서버-클래스 및 메인 프레임 컴퓨터 모두 혹은 일부를 포함할 수 있다.
나아가, 모바일 월렛에 저장된 HCE 토큰 혹은 다른 지불 크리덴셜은 또한 FSP가 발행한 가상 월렛 애플리케이션에 더해서 해당 판매자가 제공한 혹은 이와 관련된 것과 같은, 요청 통신 장치에 설치된 다른 애플리케이션이 액세스 가능하게 될 수 있다. 이러한 '판매자 월렛'에 저장된 토큰 혹은 지불 크리덴셜에 액세스하기 위해서는, 판매자 애플리케이션이 풀 아키텍쳐(pull architecture)를 구현해서 가상 월렛 애플리케이션으로부터의 정보에 액세스하도록 적절한 이전 신호 교환에 의해서 인가될 수 있다. 이는 소망의 경우에, 월렛과 판매자 애플리케이션 모두에 공통인 시스템 레벨 API(application programming interface)의 사용자 통신 요청 장치에 제공함으로써 용이하게 될 수 있다. 이러한 API는 예컨대신뢰된 사용자 요청 장치가 액세스 가능하며 신뢰된 장치에 제공된 개별, 독립형 월렛 및 판매자 API와 통신하기에 적합한 개별 API 혹은 다른 프로그래밍 피쳐의 사용을 통해서 제공될 수 있다. 이러한 구현예에서 FI 기반 월렛에 이미 저장되어 있는 토큰이 판매자 애플리케이션에 의해 풀링될 수 있기 때문에, 사용자가 거래를 완료하기 위해서 임의의 신용 카드 정보를 직접 판매자 애플리케이션에 입력할 필요가 없다.
판매자의 신원 및/또는 개개의 판매자 애플리케이션은, 거래 동안에 판매자 및/또는 신뢰된 사용자 요청 통신 장치를 인증하는 인증 기관과 같은 신뢰된 플랫폼에 등록될 수 있다. 일부 경우에, 공통 중앙 인증 기관이 제공되어서, 다수의 판매자 혹은 판매자 애플리케이션이 본 명세서에 개시된 실시예에 따른 보안 인앱 거래를 완료하기 위해서 등록될 수 있다. 예컨대, 공통 중앙 인증 기관은 협업 혹은 연계 동작에서 하나 이상의 은행과 같은 하나 이상의 금융 기관에 의해서 성립 혹은 동작될 수 있다. 다수의 다양한 판매자 애플리케이션의 다수의 다양한 사용자에 의한 인앱 지불을 용이하게 하기 위해서, 판매자 및/또는 판매자 애플리케이션을 인가하는데 사용되는 증명서의 발행을 위한 산업별 표준이 동의 및 구현될 수 있다. 일부 경우에, 요청 통신 장치 상의 사용자의 요청 통신 장치 및/또는 하나 이상의 가상 월렛 애플리케이션은 인증 기관에 등록될 수도 있다.
등록된 판매자 애플리케이션으로부터 개시된 모바일 혹은 다른 지불을 완료하는 일부로서, 판매자 혹은 판매자 애플리케이션에 발행된 증명서(예컨대, 식별 토큰)를 나타내는 데이터는, 사용자의 요청 통신 장치에 있는 이러한 애플리케이션의 제어하에서 저장하고 사용자가 요청 통신 장치를 중앙 인증 기관 및/또는 다른 거래 프로세서에 후속해서 제시하기 위해서, 거래를 확인 혹은 인증할 때 사용하기 위해서 판매자 애플리케이션에 전송될 수 있다. 예컨대, 계산 혹은 지불 시퀀스의 일부로서, 판매자 애플리케이션은 요청을 판매자의 증명서가 저장된 판매자 서버나 일부 다른 네트워크화된 시스템 혹은 리소스에 송신할 수 있다. 판매자 애플리케이션은 이후에 공통 API를 통해서 판매자의 증명서를 사용해서 사용자의 모바일 월렛에 질의한다. 이러한 질의는 판매자의 증명서를 수신한 것에 응답해서 판매자 애플리케이션에 의해서 혹은 다른 방안으로 모바일 장치 상의 사용자에게 제시된 수동 확인 프롬프트에 후속해서 자동으로 개시될 수도 있다.
판매자 애플리케이션에 의한 질의에 응답해서, 일부 경우에, 가상 월렛 애플리케이션은 인가의 진행(인가의 확인을 위한 '프롬프트')을 요구하는 사용자 인터페이스의 요청 통신 장치의 출력 화면에 표현시킬 수 있다. 가상 월렛이 하나 이상의 지불 방법(즉, 거래 자금의 소스)에 대한 토큰 혹은 지불 크리덴셜을 저장하고 있는 경우에, 가상 월렛은 현재 거래에서 사용할 저장된 지불 옵션 중 하나 이상을 선택하도록 사용자를 프롬프트할 수도 있다. 한가지 지불 방법만 저장되어 있다면, 가상 월렛은 사용자에게 지불 방법의 선택을 프롬프트할 수도 있고 하지 않을 수도 있다. 일부 경우에, 사용자는 가상 월렛이 현재 거래에 사용하기 위해서 자동으로 선택할 수 있는 가상 월렛에서 디폴트 지불 방법을 명시할 수 있으며, 다수의 상이한 지불 옵션이 저장될 수 있더라도 거부 가능한(혹은 거부 불가능한) 프롬프트를 표현해서 디폴트 선택을 확인할 수 있다. 이러한 디폴트는, 모든 판매자 애플리케이션에 대해서 명시될 수도 있고 혹은 특정 판매자 애플리케이션에 대해서만 명시될 수도 있으며, 일부 경우에 불능화될 수도 있다.
하나 이상의 지불 옵션 중, 요청 장치의 사용자에 의한 혹은 가상 월렛에 의한 선택에 이어서, 가상 월렛은 선택된 사용자의 지불 방법 혹은 소스를 나타내는 토큰 혹은 크리덴셜을 사용해서 요청 장치의 통신 서브시스템을 통해서 판매자 애플리케이션에 응답할 수 있다. 판매자 애플리케이션은 수신한 토큰 혹은 크리덴셜을 거래의 완료에 필요한 다른 정보와 함께 판매자 서버에 전송할 수 있다. 일부 경우에, 판매자 서버로 송신되는 지불 정보는 판매자가 사용자의 어떠한 민감한 정보도 보거나 혹은 액세스할 수 없도록 암호화될 수도 있다. 지불 정보의 암호화는 판매자 애플리케이션에 의해서 혹은 요청 통신 장치 상의 일부 다른 애플리케이션이나 프로그램에 의해서 판매자 애플리케이션에 전송되기 전에 가상 월렛에 의해서 수행될 수 있다. 거래를 완료하고 선택된 지불을 처리하기 위해서, 판매자 서버는 가상 장치로부터 수신한 토큰 혹은 지불 크리덴셜 및 다른 요청받은 거래 정보를 지불 게이트웨이 혹은 다른 거래 프로세서로 포워딩할 수 있다.
일부 경우에, 판매자 서버로 송신되는 지불 크리덴셜은 특정 지불 방법에 따라서 모바일 월렛에 이전에 저장된 토큰의 동일한 카피가 될 수 있다. 이와 달리, 혹은 이에 더해서, 가상 월렛 애플리케이션은, 부분적으로 혹은 전체가 가상 월렛에 영구 저장된 토큰으로부터 유도된 혹은 이와 관련된 거래를 위해서 일회용 토큰을 생성하고, 영구 토큰이 아닌 일회용 토큰으로 판매자 애플리케이션에 응답할 수 있다. 경우에 따라서, (직접 혹은 일회용 토큰을 생성해서) 거래를 완수하는데 사용되는 지불 크리덴셜은 사전에 생성되어서 거래를 개시하기 전에 가상 월렛에 저장될 수도 있다. 이 경우, 가상 월렛은 거래시에 요구된 지불 토큰을 획득하기 위해서 임의의 신뢰된 서버와 통신할 필요는 없다. 경우에 따라서, 가상 월렛은 각 거래시에 다른 시스템에 의해 및/또는 애플리케이션에 의해서 생성된 지불 토큰을 획득 혹은 입증하도록 구성될 수도 있다.
일부 실시예에서, 가상 월렛 애플리케이션에 저장된 혹은 이에 의해 액세스 혹은 제어되는 토큰은 다양한 타입 혹은 소스의 지불을 나타낼 수도 있다. 예컨대, 하나 이상의 개개의 신용 카드 타입 혹은 프로토콜에 더해서, 개개의 은행 계좌 혹은 다수의 은행 계좌 및/또는 여신 한도에 링크된 지불 토큰이 생성되어서, 보안 인앱 지불을 포함한 모바일 지불에 사용하도록 모바일 월렛에 저장될 수도 있다. 일반적으로, 각각의 인가된 지불 방법은 하나 이상의 다양한 지불 토큰과 연관될 수 있다. 일부 경우에, 쿠폰 및/또는 로열티 프로그램과 같은 또 다른 자산 유형에 대한 지불 토큰이 단독으로 혹은 수요, 예금 혹은 신용 계좌 기금에 더해서 사용될 수 있다. 자금원으로서 역할을 하도록 어떤 타입의 지불이 선택되던, 판매자 애플리케이션 및 가상 월렛은 거래를 지불 게이트웨이가 적절하게 식별할 수 있도록 구성할 수 있다. 거래 유형에 따라서, 지불 게이트웨이는 일단 식별되면 토큰 혹은 지불 크리덴셜을 처리를 위해서 적절한 FSP 서버로 라우팅할 수 있다.
다양한 타입의 지불에 더해서, 본 발명의 다양한 측면 및 실시예에 따라서 가상 월렛 애플리케이션에 저장되거나 혹은 이에 의해 액세스 혹은 제어되는 토큰은, 동일한 타입의 지불(예컨대, 신용, 차변, 리워드 혹은 로열티)을 완료하기 위해서 사용 가능한 다수의 토큰을 포함할 수 있지만, 독립 FI 혹은 FSP에 의해 즉, 독립된 법적 권리 및 의무의 대상인 FI 혹은 FSP에 의해 및/또는 독립 소유자 혹은 관리자에 의해 유지, 제어 혹은 관리되는 계좌로부터 인출 혹은 제공될 수도 있다. 이러한 독립 FI 혹은 FSP은 고유의 보안 코드의 완전한 제시 및/또는 다른 보안 특성 절차에 대한 부합을 포함한 다른 타입의 별개의 요건을 부과할 수 있으며, 이는 모두 본 발명의 다양한 측면 및 실시예에 의해서 고려된다.
또 다른 측면에서, 본 명세서에 개시된 본 발명의 실시예는 전자 지불을 처리하기 위해서 신뢰된 플랫폼을 모바일 및/또는 비모바일 환경에 포함시킬 수도 있다. 예컨대, 사용자의 요청 통신 장치가 신뢰된 장치로서 인증된 이후에, 판매자와의 지불이 개시되면, 사용자의 장치는 모바일 월렛 애플리케이션 혹은 모바일 장치에 또는 보안 클라우드에 저장된, 지불 토큰, 이러한 토큰 및/또는 다른 암호화된 데이터에 대한 참조가, 지불 거래를 완료하는데 필요한 혹은 요구되는 임의의 다른 데이터와 함께 판매자 시스템에 전송되게 한다. 판매자 혹은 판매자 애플리케이션은, 판매자의 인증서 상태(인증 기관이나 신뢰된 플랫폼 등이 인식가능한 데이터 신호를 사용해서)를 나타내거나 이와 연관된 토큰 데이터에 더해서 혹은 이와 관련해서 토큰의 인가를 전자적으로 사인 혹은 입증 혹은 확인할 수 있고, 이러한 '사인된' 메시지를 지불 네트워크에 포워드할 수 있다.
판매자 및/또는 사용자의 장치가 신뢰된 것으로 인증되었기 때문에, 지불 메시지(예컨대, 거래 인가 데이터 세트)는, 구매자가 선택한 지불 형태에 무관하게, Interac™과 같은 인식된 지불 프로토콜에 따라서 혹은 임의의 적절한 타입의 지불 프로토콜에 따라서 설정된 지불 데이터와 유사하도록 모바일 장치 혹은 판매자에 의해서 구성될 수 있다. 이 경우, 지불 네트워크 내의 인수자는 Interac™인지 혹은 다른 타입의 거래인지를 나타내는 메시지를 수신하고, 이 메시지를 Interac™인지 혹은 다른 타입의 거래인지를 나타내는 발행 FI에 포워드할 수 있다. Interac™인지 혹은 다른 타입의 거래인지를 나타내는 이 메시지를 확인/해독해서, 판매자에 대한 지불을 직접 혹은 간접적으로 처리할 수 있다. 일부 경우에, 발행 FI는 메시지 내에 나타나는 선택된 지불 방법으로부터 직접 지불을 준비할 수 있다. 옵션으로서, 발행 FI는 대신에 FI 자체 자금으로부터 판매자에게 지불할 수도 있고, 발행 FI는 이후에 사용자가 신뢰된 플랫폼에 등록한 임의의 지불 방법에 의해서 사용자와 개별적으로 정산될 수도 있다. 일부 경우에, 관련 기술에 종사하는 당업자라면, '인하우스' 정산을 위해 지불 네트워크에 의한 제3 인수자 대신에, 이러한 지불 메시지가 발행 FI에 직접 포워딩되는 것이 효율적이고 보안이며 및/또는 바람직하다는 것을 이해할 수 있을 것이다. 예컨대, 거래 판결 처리 시간은 감소될 수 있고, 제3자 프로세서에 대한 지불이 제거 혹은 감소될 수 있다.
당업계에 종사하는 당업자라면, 본 명세서에서 사용되는 '토큰'은 민감한 정보를 통신하기에 적합한 보안 데이터 장치라고 이해할 수 있을 것이다. 이 장치는 민감한 정보와 같은 데이터를 포함할 수 있고, 이러한 데이터에 대한 프록시의 역할을 하기에 적합한 대체 데이터 및/또는 데이터가 저장되고 보안 액세스될 수 있는 IP 어드레스와 같은 리소스에 대한 포인터를 대체할 수 있다. 데이터의 특정 타입 혹은 아이템이 이러한 토큰 및/또는 이러한 토큰 기준에 포함될 수 있으며, 이는 민감한 데이터에 대한 액세스를 제어하는데 사용되는 거래 처리 서버(120 160)와 같은 서버와 고유하게 관련된 보안 키이다. 이러한 보안 키는 정보에 액세스하기 위해서 인가를 입증 혹은 획득하기에 충분한 임의의 식별자를 포함한 임의의 데이터를 포함할 수 있다. 이러한 보안 키는 예컨대, PKI 키 혹은 증명서 등이 될 수 있지만 이것으로 한정되는 것은 아니다.
다양한 타입의 지불 방법 혹은 자금원 타입이, 예컨대 여신 한도, 현금 계좌, 로열티, 기프트 및/또는 리워드 포인트 밸런스 등을 포함한, 적절하게 구성된 전자('가상') 월렛 애플리케이션을 사용해서 지불 혹은 다른 거래를 처리하는데 사용될 수 있다는 점에 주의한다. 개시된 바와 같이, 선택된 지불 방법은 판매자에 의해서 기존 지불 네트워크 및/또는 인프라스트럭쳐를 사용해서 인수자 혹은 다른 인가된 FSP에게 라우팅되는 방식으로 인수자 혹은 FSP가 발행 FI에 라우팅하기 위해서 메시지 내에 지정될 수 있다. 전자 월렛에서 제시된 각각의 지불 방법은 대응하는 발행 FI 및/또는 신뢰된 플랫폼에 등록된 지불 방법에 대응할 수 있다. 전형적으로, 판매자는 사용자가 거래를 위해서 어떤 지불 방법을 선택했는지를 알 필요가 없고 주의할 필요도 없으며, 지불이 충분한 양만큼 입찰되는 한, 판매자는 임의의 특정 지불 방법을 수용하도록 구성된 시스템 혹은 애플리케이션을 제공받을 필요도 없다. 발행 FI는 FI의 자금으로부터 판매자에게 지불하고, 사용자가 선택한 지불 방법으로부터의 상환을 통해서 구매자 혹은 다른 요청 사용자와 정산할 수도 있다. 그 결과, 판매자 혹은 다른 지불 프로세서 후위 엔티티를 최소한만 변경해서 본 명세서에 개시된 본 발명의 측면을 구현할 수 있으며, 이로써 추가 지불 시스템 및/또는 애플리케이션에 대한 처리 시간 및 필요성을 감소시킨다. 경우에 따라서, 판매자는 FI 혹은 신뢰된 플랫폼으로부터 설정된 증명서 데이터를 수신하기만 하면 되며, 이는 사용자나 이들의 모바일 혹은 비모바일 장치로부터 제공되는 지불 토큰을 전자적으로 서명하는데 사용될 수 있다.
일부 실시예에서, 판매자에 의해 제공되는 혹은 판매자와 관련된 애플리케이션 혹은 프로그램 이외에, 모바일 혹은 다른 장치에 설치된 다목적 네트워크 브라우저 애플리케이션에서 지불을 개시 혹은 거래하는데 시스템, 방법 및 머신 실행 가능 명령어 세트가 본 개시에 따라서 사용될 수 있다. 예컨대, 사용자가 지불을 요구하는 웹 페이지 혹은 사이트를 네비게이트할 때, 옵션이 제시되어서 사용자의 요청 통신 장치에 설치된 가상 혹은 전자 월렛을 사용해서 지불의 사용자가 선택할 수 있게 할 수도 있다. 이러한 옵션은 이용 가능한 지불의 다른 타입 및/또는 방법에 더해서 혹은 그 대신에 제시될 수 있고, 지불 옵션의 리스트 내에 혹은 선택 가능 '버튼'과 같이 그래픽적으로 혹은 기능적으로 구별되는 사용자 인터페이스 객체로서 임의의 소망의 위치 혹은 다른 적절한 위치에 나타날 수도 있다. 요청한 사용자가 가상 월렛을 통한 지불을 선택하면, 사용자의 네트워크 브라우저 애플리케이션은 대응하는 월렛 애플리케이션과 인터페이스할 수도 있고, 혹은 요청하는 장치에 의해 액세스되어서 월렛으로부터 지불 토큰을 획득할 수도 있으며, 이는 판매자 백엔드를 통해서 처리될 지불 메시지 내의 토큰을 포함한다. 지불 네트워크 혹은 다른 개체를 통한 전자 지불의 처리는 본 명세서에 개시된 응용 가능 실시예 중 어느 하나에 따라서 진행될 수 있다.
본 발명에서 제공하는 중요한 이점은 지불 거래를 구현하는 사용자 경험이 플랫폼에 관계없이 실질적으로 동일하다는 점이다. 예컨대, 각각의 경우에, 전자 월렛으로 지불을 선택한 경우에, 상술한 바와 같이 다수의 응용 가능 지불 카드/계좌의 리스트 혹은 다른 시각적인 표현이 선택을 위해서 사용자에게 제시될 수 있다. 요청 사용자는 지불 방법을 선택할 수 있고, 모바일 장치 혹은 개인용 컴퓨터가 적절하게 구성된 토큰을 판매자에게 전달할 수도 있고, 혹은 클라우드 월렛의 경우, 은행이 개개의 토큰을 판매자에게 라우팅하거나 혹은 판매자의 인수자에게 직접 라우팅할 수 있다.
상기 설명한 바와 같이, 본 발명의 다양한 측면에 따라서, 개인용 컴퓨터와 같은 비모바일 장치 상의 애플리케이션 혹은 다른 프로그래밍으로부터 전자 거래가 개시 및 완료될 수 있다. 예컨대, 일부 경우에, 사용자는 판매자로부터 상품 혹은 서비스를 구입, 리스 등을 할 수 있는 웹사이트에 대해서 네비게이트할 수 있다. 가상 월렛 지불 옵션의 로그인 혹은 다른 프롬프트 가능 선택이 판매자의 계산/지불 웹페이지에서 사용자에게 표시될 수 있다. 요청 사용자가 가상 월렛 지불 옵션을 선택하면, 예컨대, 요청 사용자가 사용자의 인가된 은행, 신용, 로열티, 리워드 및/또는 다른 지불 계좌로의 로그인을 가능하게 하기에 적합한 인터렉티브 필드를 갖고 네트티드 브라우징 컨텍스트(nested browsing context)(예컨대, iframe 혹은 다른 그래픽 중첩 혹은 삽입)에서 렌더링된, 판매자의 웹페이지는 보안 로그인을 제시할 수 있다. 로그인 혹은 다른 인가에 성공하면, 지정된 지불 계좌와 관련된 FI는 하나 이상의 지불 토큰을 판매자에게 혹은 인수자나 판매자에 의한 혹은 판매자와 관련된 다른 제3자 지불 프로세서에게 제공함으로써 응답할 수 있으며, 토큰은 사용자의 전자 월렛 내에서 식별된 하나 이상의 지불 방법을 나타내고 거래 지불을 배상하기에 적합한 것이다. 이러한 지불 토큰은 사용자의 장치 및/또는 보안 클라우드 리소스에 저장될 수 있다. 판매자 혹은 판매자 백엔드가 지불 토큰을 수신한 이후에, 거래는 본 명세서에 개시된 방법 중 어느 하나에 따라서 처리될 수 있다.
따라서, 일부 실시예에서, 사용자가 어떤 프로그램 혹은 애플리케이션을 통해서 거래(인앱, 모바일 혹은 비모바일 네트워크 브라우저)를 개시하는지에 무관하게, 사용자의 장치는 가상 월렛 애플리케이션 혹은 지불 토큰을 저장하지 않을 수도 있다. 대신, 이러한 경우에, 장치는 장치/사용자를 예컨대 신뢰된 플랫폼을 통해서, 사용자의 지불 계좌를 관리하는 FI에게 보안적으로 인증하는 수단을 제공할 수 있다. 사용자 및/또는 장치가 일단 인증되면, 사용자의 FI는 거래의 처리를 위해서 전자 지불 토큰을 판매자/인수자에게 송신할 수 있다. 본 명세서에 개시된 바와 같이 지문 혹은, 음성 혹은 얼굴 인식, 로그인/패스워드, 혹은 사용자의 장치의 특정 기능에 의해 지원되는 임의의 다른 보안 검증 수단과 같은 다른 생체 검증을 포함한 다양한 보안 인증 방법이 사용될 수 있다.
이하, 적어도 하나의 바람직한 실시예를 포함한 본 발명의 다양한 실시예의 추가적인 세부 사항에 대해서 도면을 참조로 설명한다. 제목 혹은 부제목은 독자가 더 신속하고 명확하게 이해할 수 있도록 본 개시를 청구 대상의 논리적인 그룹으로 정리하기 위한 단지 편의를 위한 것으로, 개시된 실시예의 범주로 종류를 한정하는 것은 아니다. 당업자가 이해하는 바와 같이, 본 명세서에 개시된 많은 특성은 사용자, 판매자 및/또는 FSP 선호 등과 같은 지불 네트워크 구성에 따라서, 다양한 조합 및 대안으로 이용될 수 있다.
신뢰된 플랫폼
우선 도 1을 참조하며, 이는 본 발명의 다양한 측면 및 실시예를 구현하는데 사용되기에 적합한 시스템(100)의 개략도를 나타내고 있다. 도시된 예에서, 시스템(100)은, 구매자 혹은 다른 사용자(190)(도 3, 도 14a~14f), 신뢰된 인증 플랫폼('신뢰된 플랫폼' 혹은 '거래 처리 시스템)(120) 및 판매자 POS 및/또는 다른 거래 장치(132, 134) 및 판매자 혹은 다른 FSP 서버(136)를 포함한 판매자 시스템(130)에 의해 사용되는 적어도 사용자 혹은 요청 통신 장치(110)('네트워크 거래 통신 장치' 및/또는 '네트워크 통신 장치'라고도 함)를 포함한다.
도 1에서 각각의 장치(110, 120, 130, 132, 134, 136)가 하나만 도시되어 있지만, 당업자라면 시스템(100)이 이러한 장치를 소망의 혹은 바람직한 수만큼 포함할 수 있다는 것을 이해할 것이다.
다양한 실시예에서, 사용자 혹은 요청 통신 장치(110)는 적절하게 구성된 스마트폰, 태블릿, 웨어러블, 랩톱 혹은 다른 모바일 장치; 데스크톱이나 다른 고정형 컴퓨터나 단말들을 포함하거나 이들로 구성될 수 있다. 다수의 다양한 적절한 장치가 현재 시판 중이며, 본 명세서가 마련된 이후에 다른 장치가 개발될 수도 있음은 물론이다. 요청 혹은 사용자 통신 장치(110)에 대해서는 이하에서 도 6 내지 8을 참조로 상세하게 설명한다.
신뢰된 플랫폼 및 다른 거래 처리 시스템(120, 120')은 임의의 엔터프라이즈, 서버, 데스크톱, 랩톱 혹은 다른 적절하게 구성된 타입이나 유형의 전자 데이터 처리 (컴퓨터) 시스템을 포함하거나 혹은 이들로 구성될 수 있다. 다수의 다양한 적절한 장치가 현재 시판 중이며, 본 명세서가 마련된 이후에 다른 장치가 개발될 수도 있음은 물론이다. 신뢰된 플랫폼(120)에 대해서는 이하에서 도 9 내지 11을 참조로 상세하게 설명한다.
판매자 시스템(130) 및 장치(132, 134, 136)는 적절하게 구성된 POS, mPOS 및 백엔드 데이터 처리 장치를 포함하거나 이들로 구성될 수 있다. 다수의 다양한 적절한 장치가 현재 시판 중이며, 본 명세서가 마련된 이후에 다른 장치가 개발될 수도 있음은 물론이다. 판매자 시스템(130) 및 장치(132, 134, 136)에 대해서는 이하에서 도 9 내지 11을 참조로 상세하게 설명한다.
장치(110, 120, 130, 132, 134, 136) 혹은 이들 중 일부는, 임의의 적절한 프로토콜이나 프로토콜의 조합을 사용해서 인터넷, PSTN 및/또는 다른 통신 네트워크를 통해서 통신하도록 구성된 예컨대 적절하게 구성된 신호 프로세서, 송신기 및 수신기를 사용해서, 무선(라디오, 무선 전화, 광학, RFID 및 적외선을 포함), 유선 혹은 다른 수단에 의해서 서로 통신할 수 있다. 일반적으로 이러한 장치는, 이를 위해서 하나 이상의 CPU 및/또는 다른 프로세서의 제어 하에서 동작하는 하나 이상의 전용 통신 서브시스템을 포함한다.
도 1의 ①에 도시된 바와 같이 본 명세서에서 가능한 처리의 구현의 일부로서, 사용자(190')의 모바일 장치(110)는 적절하게 구성된 신호 교환을 이용해서 통신 네트워크(200)(예컨대, 인터넷 및/또는 PSTN)를 통해 신뢰된 플랫폼 서버(120)에 등록될 수 있고, ②에 도시된 바와 같이 신뢰된 플랫폼(120)가 증명서 혹은 다른 토큰을 나타내는 보안 데이터 세트를 제공해서 장치(110)의 휘발성 혹은 비휘발성(즉, 일시적 혹은 비일시적) 메모리에 저장해서, 장치(110)를 신뢰된 장치(110')로 만든다. 이러한 증명서 혹은 토큰은 장치(110)에서 수신되어서 저장되면 장치(110) 및 신뢰된 플랫폼(120)가 장치(110)를 '신뢰된 장치'(110')로 빠르고 안전하게 식별하는데 사용될 수 있고, 이는 예컨대 하나 이상의 판매자 시스템(130)과 같은 제3자와의 사이의 구입이나 다른 금융 거래와 같은 데이터 처리를 빠르게 인가 및/또는 확인하기 위해서 예컨대, 신뢰된 플랫폼(120)에 전송되어서 해석하기 위해서 사용된다.
장치(110)를 신뢰된 플랫폼(120)에 등록해서 신뢰된 장치(110')를 만드는 것은, 본 명세서의 목적에 부합하는 적절한 확실한 보안 통신을 위한 수단을 성립시키는 임의의 수단을 포함할 수 있다. 예컨대, 장치(110)의 하나 이상의 고유한 보안 식별자 및/또는 그 하나 이상의 인가된 사용자(190)는 폭넓은 대안예 및 그 조합으로 사용될 수 있다. 이는 예컨대, 이른바 '비밀' 개인 정보, 시리얼 넘버, 랜덤 혹은 의사 랜덤 코드, 계좌 번호 등을 포함할 수 있다.
이러한 신뢰된 장치(110')는 예컨대, ③에서, 판매자, 게임 혹은 판매자/제공자(130)나 다목적 웹(즉, 네트워크) 브라우저 등을 포함한 일부 다른 개체가, 신뢰된 장치(110')의 사용자 표시 화면이나 다른 I/O 컴포넌트(610)(예컨대, 도 6 참조)에 제공되는 적절하게 구성된 하이퍼텍스트 링크 및 터치스크린, 키보드/키패드 및/또는 다른 사용자 생성 입력의 전달, 신호 송신기 및 수신기 등을 사용해서 제공하는 다른 애플리케이션('앱')과 같은, 직접 인터넷 접속을 통해서 하나 이상의 '인앱' 지불 혹은 다른 데이터 처리 거래를 협상 및 완수하는데 사용될 수 있다.
동일한 실시예 및 다른 실시예에서, ④에서, 신뢰된 장치(110')는 판매자 시스템(130, 136)에 논리적으로 관련된 모바일 POS('mPOS') 장치(132)와 로컬하게 통신할 수 있으며, 판매자 시스템(130, 136) 자체는 신뢰된 개체로서 신뢰된 플랫폼(120)에 등록될 수 있으며, 이를 직접 혹은 종래의 지불 시스템의 '탈선(off the rail)' 처리라고도 한다. 환언하면, mPOS(132) 및 관련 판매자 프로세서(136)는 ⑤에 도시된 바와 같이, 적절한 신호 교환에 의해서 VisaNet나 동등한 등록 지불 네트워크와 같은 지불 프로세서 등의 제4자 거래 프로세서(150)와 협상하지 않고도, 동일한 혹은 다른 신뢰된 플랫폼(120)과 직접 통신하는 수단 수단에 의해서 가능할 수 있다. 종래의 수단에 의한 '정상 궤도(on the rail)' 프로세싱을 위해서 지불 프로세서와 같은 제4자(150)를 포함할 필요가 없으므로, 신원, 계좌 식별자 등과 같은 민감한 거래 데이터의 고속의 보안 처리를 포함한 다수의 이점이 구현될 수 있다.
일부 실시예에서, mPOS(132) 및/또는 다른 관련 판매자 프로세서(136)는 또한 및/또는 이에 더해서 플랫폼(120)과 직접 통신하는 대신 적절한 신호 교환을 통해서 제4자 거래 프로세서(150)와 통신할 수 있으며, 이는 상술한 바와 같이 VisaNet나 다른 등록된 지불 네트워크와 같은 지불 프로세서가 될 수 있다. mPOS(132) 및/또는 관련 판매자 프로세서(136)와 제4자 거래 프로세서(150) 사이에서 정산되는 거래는 발행인 은행(160)과 및/또는 신뢰된 플랫폼(120)과 실질적으로 수행될 수 있으며, 이로써 판매자는 지불받고, 사용자는 판매자에게 지불할 때 사용되는 계좌나 다른 자금원, 혹은 프로토콜이나 타입에 관계없이 대응하는 금액을 예치한다. 이러한 구성의 한가지 가능한 이점은 mPOS(132) 및/또는 관련 판매자 프로세서(136)가 제4자 프로세서(150)와의 통신 및/또는 거래 처리를 위해서 이미 구성될 수 있다는 점이다. 따라서, 신뢰된 플랫폼(120)과 인증하는 임의의 및 또는 모든 이점은 기존 판매자 시스템 아키텍쳐를 활용하면서 모바일 거래에서 구현될 수 있다.
지불 및 다른 금융 거래에 더해서, 신뢰된 플랫폼 아키텍처(100)는 다양한 다른 목적에 사용될 수도 있다. 예컨대, 상술한 바와 같이, 신원 검증은 다른 가능한 애플리케이션이다(예컨대, 은행이 나를 신뢰하고, 당신이 은행을 신뢰하므로, 임의의 제3자인 당신은 나를 신뢰한다). 신뢰된 플랫폼(120)과 관련된 은행들 혹은 다른 계좌 관리자들이나 피신뢰자(160)들 사이의 신뢰는 유사한 방식으로 작용할 수 있다. 각각의 은행 혹은 FSP(160)는 신뢰된 플랫폼 시스템(100)에서 다른 은행 혹은 FSP(160로 확인 및 검증될 수 있다.
다양한 실시예에서, 장치(110')의 사용자는 신뢰된 플랫폼(120)을 통해서, 계좌 번호 등이 아닌, 지불을 유효하게 하는데 사용될 수 있는, 하나 이상의 계좌와 관련된 개인적인, 장치의 혹은 다른 비계좌 아이덴티티나 식별자에 기초해서, 구입을 완료하고 및/또는 다른 거래를 처리하는 것이 가능하다. 사용자의 진짜 신원을 나타내는 데이터 혹은 신뢰된 플랫폼(120)이 거래와 관련된 지불이나 다른 의무(obligation)의 완료를 위한 개런티로서 인정 가능한 다른 신원이 온보딩(onboarding) 처리나 다른 처리를 통해서 수신, 검증 및 확인될 수 있으며, 신뢰된 플랫폼 아키텍쳐(100)의 하나 이상의 서버(120)에 유지되고, 인증 식별자를 나타내는 데이터를 포함한 하나 이상의 적절한 토큰이 장치(110)와 관련된 메모리에 저장하기 위해서 사용자 장치(110)로 반환될 수 있으며, 그 결과 이후에 신뢰된 장치(110')로서 장치(110)를 설정 및/또는 재설정하는데 사용하기에 적합한 발행 신뢰된 플랫폼(120) 데이터(토큰일수도 있고 토큰을 포함할 수도 있음)로 반환하는데 사용될 수 있다.
당업자라면, 임의의 사용자 혹은 요청 장치(110)가 다수의 인가된 사람 및/또는 법적인 사용자 및/또는 이러한 사용자와 연관된 다수의 계좌와 연관될 수 있다는 것을 이해할 수 있을 것이다. 예컨대, 이러한 장치는 다양한 관할권 내의 혹은 다양한 데이터 처리 컨텍스트 내의 다양한 인가된 사용자 및/또는 개체에 의해, 예컨대, 소매 판매자 구내 혹은 특정한 온라인 서비스(예컨대, 온라인 음악 혹은 미디어 소스) 내에 대비한 다양한 소셜 미디어 플랫폼으로서 사용될 수 있다. 각각의 검증된 신원과 관련된 링크 및/또는 데이터나 명령어의 표현이 물리적인 신용카드나 직불카드와 같은 ID 카드에, 혹은 SD 카드 혹은 다른 착탈형 장치와 같은 장치(110, 110')의 별도의 혹은 일반적인 메모리에, 혹은 예컨대 하나 이상의 가상 월렛 애플리케이션(112), 전용 소프트웨어, 펌웨어 혹은 하드웨어 내의 일반적인 메모리나 장치와 연관되어 있거나 장치가 액세스 가능한 메모리나, 혹은 USB 키와 같은 유사한 기능의 별도의 장치에 저장될 수 있다. 신뢰된 식별자를 포함하는 카드 혹은 장치(110, 110')는 POS 장치(132 134) 혹은 다른 모바일 장치(110, 110') 등에 탭되거나 혹은 인터랙트되게 될 수도 있고; 처리의 임의의 적절한 지점에서 다수의 식별자 중 하나가 예컨대 장치(110, 110') 중 적절하게 구성된 I/O 장치를 사용해서 거래와 관련해서 사용되도록 선택될 수 있다. 선택된 신원과 관련된 식별자는 POS/장치(110, 110')에 의해서 서버(120)로 포워딩될 수 있고, 여기서 거래의 완료를 위해서 ID가 신뢰된 것인지 확인한다.
구매 및 지불을 포함한 다른 거래의 완료에 적합한 실시예에서, 거래를 완료하는데 사용될 하나 이상의 지불 형태가, 거래시에 및/또는 거래가 확인된 이후에, 사용자(110')와 판매자 시스템(130) 사이에서 사전에 동의될 수 있고 이는 예컨대 POS(132, 134) 또는 서버(136) 등에 의해서 은행/신뢰된 플랫폼/거래 프로세서(120, 160)로 통신된다. 이러한 지불 방법은 은행(160) 혹은 다른 신뢰된 플랫폼(120)에 등록되거나 혹은 이에 의해서 인증되며, 이러한 방법을 나타내는 정보를 전송하고 해석할 필요성이 제거되거나 혹은 감소될 수 있다. 이러한 방식으로, 예컨대, 지불 메시지 자체 내의 선택된 소스 혹은 지불 방법과 관련된 임의의 세부 사항(민감할 수 있는)을 제공할 필요없이, 동의된 지불 방법에 따라서 지불을 처리하라는 은행(160) 혹은 다른 신뢰된 플랫폼(120)에 대한 명령어를 사용해서, 지불이 완료될 수 있다.
따라서, 본 발명에 의해서 예컨대, 신규한 다양한 타입 혹은 모드의 지불 정산 처리가 가능하다. 예컨대, 거래시에, 장치(110')의 사용자와 판매자 시스템(130) 모두가 사용할 지불 프로토콜의 타입, 모드 혹은 프로토콜(예컨대, 각 타입의 지불과 관련된 하나 이상의 특정 계좌를 포함한 신용, 직불, 현금 은행 이체, 로열티 포인트 상환)에 동의할 수 있으며, 선택된 프로토콜과 관련된 식별자가 신뢰된 플랫폼 서버(120)로 송신될 수 있다. 이러한 프로토콜은 거래를 완수하는데 사용되는 지불 계좌의 타입에 무관하게 처리에서 사용하는 것으로 동의 및 지정될 수 있다. 서버(120) 자체는 선택된 프로토콜로 지불을 처리하는 성능을 가질 수 있으며, 특히 서버(120)는 은행 혹은 다른 지불 제어 FSP(60)와 연관된다. 판매자 시스템(130)의 관점에서, 거래 데이터 흐름은 그 자체의 선호나 그 지불 시스템 서비스 제공자의 선호에 따라서 지불 프로토콜과 동일하거나, 실질적으로 동일하거나, 이와 무관할 수 있다.
판매자 시스템(130)에 의한 처리에 어떠한 차이를 두지 않고도 하나 이상의 판매자 시스템(130) 및/또는 FSP(160)와 통신하거나 혹은 거래를 완수하는데 자신의 권한으로 은행이나 FSP의 역할을 하며, 폭넓은 지불 타입 혹은 프토로콜 중 하나 이상을 이용해서 이러한 거래를 완수하는 신뢰된 플랫폼(120)의 능력은, 본 발명이 제공하는 중요한 이점 중 하나이다.
옵션으로 혹은 추가적으로, 신뢰된 플랫폼(120)은 디폴트 계좌 혹은 다른 지불 프로토콜이나 방법을, 예컨대 사용자 신원, 계좌 특성(계좌와 관련된 FI의 신원을 포함) 및/또는 사용자 선호도를 포함한 다양한 기준에 기초해서, 특정 거래 요청과 관련된 사용자 장치(110')가 생성하는 거래 요청과 관련시킬 수 있다.
이러한 옵션 중 일부 혹은 전체는 사용자 장치(110')에서 동작하는 신뢰된 지불 애플리케이션에 의해서 제어될 수 있고, 및/또는 구현될 수 있다. 예컨대, 가상 월렛 애플리케이션(112)은 예컨대, 개인, 개인의 계좌 중 하나 이상, 하나 이상의 개별 FI나 FSP 및/또는 하나 이상의 사용자/판매자 애플리케이션 조합으로서 특정 사용자 신원과 관련될 수 있고, 장치(110')의 특정한 인가된 사용자는 예컨대, 적절하게 구성된 사용자 인터페이스에 의해서 거래를 수행하는데 사용될 신원/앱/계좌 혹은 이들의 조합을 선택할 수 있으며, 이 선택 중 하나 이상은 소망의 조건 하에서 무시 가능 디폴트 선택으로서 식별될 수도 있고 무시 불가능 디폴트 선택으로서 식별될 수도 있다. 디폴트에 의해서 사전 선택함으로써, 예컨대 사용자가 선택할 필요가 없고, 신뢰된 플랫폼(120) 및/또는 판매자(130)가 거래 시에 특정 지불 방법을 인정할 필요가 없다.
옵션으로, FSP(160)의 역할을 하는 혹은 이를 대신하는 신뢰된 플랫폼(120)이 사용자의 장치(110, 110')를 통해서 및/또는 mPOS(132)/POS(134)를 통해서, 지불시에 새로운 혹은 기존의 여신 한도(line of credit), 혹은 다른 새로운 자금원을 오픈, 액세스 혹은 생성하는 기회를, 적절하게 구성된 사용자 인터페이스 및 데이터 교환의 사용을 통해, 사용자에게 제공할 수 있다. 본 발명에 의해서 로열티, 리워드, 기프트 및 다른 타입의 계좌의 생성을 포함한 폭넓은 추가 기능이 가능하다.
당업자라면, 신뢰된 플랫폼(120)이 판매자 시스템(130)(이는 예컨대 판매자의 협회에 의해 혹은 이를 대신해서 동작할 수 있음)과 관련된 판매자에게, 판매자가 거래에 대한 지불에 사용된 자금원에 관계없이 본 개시에 따라서 거래 결과로서 판매자로 인한 양을 지불받을 것이라는 것을 확인하는데 사용될 수 있다는 것을 이해할 것이다. 판매자의 관점에서, 판매자가 지불받을 수만 있다면, 돈이 사용자 측의 어디에서 들어오는지는 일반적으로 중요하지 않다. 이는 본 발명이 제공하는 추가적인 이점이다. 예컨대, 장치(110')의 사용자는 지불에 대한 판매자의 선호도를 고려할 필요없이 신뢰된 플랫폼(120) 및/또는 관련 FSP(160)이 허용할 수 있는 임의의 방법으로 지불할 수 있다. 예컨대, 많은 종래 시스템에서, 판매자가 AMEX™와 같은 특정 형태의 결재를 허용하지 않으면, 사용자는 다른 허용되는 지불 방법을 찾아야 한다. 예컨대, 신뢰된 플랫폼(120)은 이러한 선호 프로토콜에 따라서 지불을 허용 및 수행하며, 이에 따라서 지불이 판매자에게 전달되게 하고, 임의의 소망의 상호 허용되는 지불 형태에 따라서 신뢰된 플랫폼(120)과 구매자 사이의 후속 정산이 행해지게 하기에 적합할 수 있다. 이는 예컨대, AMEX 혹은 임의의 다른 소망의 프로토콜로 신뢰된 플랫폼(120) 자체에 의해 제어되는 자금으로부터 판매자 시스템(130)에 대한 지불을 진행시킴으로써 및 사용자를 개별적으로 지불시켜서 상환을 모음으로써 수행될 수 있다. 판매자 시스템(130)을 신뢰된 개체로서 인증하지 않으면, 먼저 판매자와의 그리고 후속한 사용자와의 신뢰된 플랫폼(120)에 의한 정산은 더 어려울 수도 있고 혹은 완전히 불가능할 수도 있다.
신뢰된 플랫폼(120)이 판매자로부터 구매 사용자를 개별적으로 정산하는 것을 포함한 추가적인 실시예에서, 신뢰된 플랫폼(120) 혹은 다른 FSP(160)는 판매자 시스템(130)에 지정된 소스를 식별시키지 않고도 하나 이상의 사용자나 혹은 장치(110')와 관련된 자금원의 조합을 사용해서 지불을 제공할 수 있다. 예컨대, 사용자는 하나의 신용 카드 계좌로 거래의 절반을 지불하고 인출 혹은 로열티 계좌로 나머지 절반을 지불한다.
다양한 실시예에서, 판매자가 지불의 형태로서 포인트를 받고자 하는지 여부에 관계없이, 신뢰된 플랫폼(120) 및 다른 FSP(160)는, 장치(110')의 사용자가 신뢰된 플랫폼(120, 160)에 등록된 로열티 포인트를 사용해서 거래에 대해 완전히 혹은 부분적으로 지불하는 것을 가능하게 한다. 이는, 판매자 시스템(130)의 선호나 요건을 고려할 필요없이 신뢰된 플랫폼(120, 160)의 인가에 의해서 혹은 인가시에 포인트가 상환될 수 있는 임의의 환경에서 가능하다. 따라서, 신뢰된 플랫폼(120, 160)은, 적절하게 구성된 신호 및 데이터 교환을 사용해서, 판매자가 선호하는 형태(달러, 유로, 파운드, 루블 혹은 엔과 같은 통화의 선택이나, 비트코인과 같은 전자 화폐의 선택을 포함)로 판매자에게 지불하는 것을 가능하게 할 수 있다. 예컨대, 정산 이전 혹은 이후에, 장치(110')의 사용자가 %25에, 나머지 %25는 보상하기에 충분한 양인 FSP와 관련된 혹은 FSP가 확인한 포인트를 더한 것에 대해 신뢰된 플랫폼/FSP(160)와 정산했거나 정산에 동의했을 때 신뢰된 플랫폼(120, 160)은 $50의 지불을 나타내는 신호를 판매자 시스템(130)에 제공할 수 있다. 판매자 시스템은 $50를 받았다는 것만 알 것이다.
사용자가 자신의 모바일 혹은 다른 거래 통신 장치(110')를 탭하거나 혹은 장치(110')를 거래 완료를 위해서 지불하도록 구성된 동작 상태에 두면, 신뢰된 플랫폼(120)은 모바일 장치(110')와 직접 통신해서 지불 옵션을 판정할 수 있다. 쿠폰, 상환, 디스카운트, 신용 및 다른 옵션을 포함한 실시간 할인(Real-time offer)이, 옵션으로서의 예컨대, 새로운 신용, 로열티 혹은 다른 계좌를 포함한 다양한 방법에 의한 지불 기회와 함께 사용자에게 제시될 수 있다. 또한, 폭넓은 이러한 옵션 및 통신은 가상 월렛 혹은 다른 지불 앱(112, 114)을 통해서 핸들링될 수 있다.
본 발명에 따른 장치들 사이에 성립될 수 있는 신뢰된 데이터 처리 관계에 의해 제공되는 많은 이점 중에서, 신뢰된 플랫폼(120)이 은행 혹은 FSP(160)에 의해 혹은 이를 대신해서 동작되는 경우에 특히, 장치(110')의 사용자가 선택한 지불 방법을 거래의 완수에 이어서, 판매자 시스템(130)이 신뢰된 플랫폼/FSP(120, 160)으로부터 최종 지불 데이터를 수신해서 처리한 이후에도 변경하는 것을 가능하게 하는 기능이 있다. 그러나, 판매자는 신뢰된 플랫폼/FSP(120, 160)에 의해 지불받기 때문에, 신뢰된 플랫폼/FSP(은행)은 사용자가 자신의 신뢰된 장치(110')를 통해서 옵션으로서 특정한 시한 내에(예컨대, 동일한 근무일 동안, 24시간 이나 표준 거래 정리 기간 이내, 혹은 몇가지 다른 소정의 기한 이내) 새로운 혹은 갱신된 지불 폼을 선택하는 것을 가능하게 한다. 이러한 실시예에서, 신뢰된 플랫폼/FSP(120, 160)은 지불 방법을 변경하는 시한의 임박한 기한에 대해서 신뢰된 장치(110')에 리마인더를 송신하도록 구성될 수 있다. 이 컷오프 시간 이전에, 신뢰된 플랫폼/FSP(120, 160)은 신뢰된 플랫폼/FSP(120, 160)과 장치(110')의 사용자 사이의 지불 상태에 관계없이, 판매자 시스템(130)과 정산할 수 있다.
본 발명의 다양한 실시예가 제공하는 이점 중에는, 지불 시간에, 신뢰된 통신 장치(110')가 신뢰된 플랫폼/FSP(120, 160)와의 네트워크 접속을 요구하지 않을 수 있다는 것이 있으며, 이는 신뢰된 장치(110')가 특히 토큰을 갖고 구성되기 때문이며(예컨대, 도 1의 ① 참조), 토큰은 거래시에 장치(110')와 플랫폼(120) 사이의 통신을 요구하는 일없이 지불 및/또는 다른 정산을 위해서 예컨대 mPOS(132)를 포함한 판매자 시스템(130)을 통해서 신뢰된 플랫폼(120)에 전달될 수 있다.
신뢰된 플랫폼(120)은 또한 판매자 mPOS(132) 없이도 예컨대, 한 쌍 혹은 다수의 사용자 통신 장치(110') 사이를 포함한 집단 사이의 지불을 용이하게 할 수 있다. 예컨대, 집단의 쌍은 신뢰된 플랫폼(120)에 신뢰된 장치(110')로서 등록된 모바일 장치(110)를 각각 가질 수 있다. 신뢰된 플랫폼(120)이 각각의 집단의 장치(110')와의 신뢰된 데이터의 상호 교환 관계를 성립시킨 한, 신뢰된 플랫폼(120)은 각각의 장치(110')로부터 수신한 커맨드를 신뢰할 것이다. 따라서, 신뢰된 플랫폼(120)이 개개의 집단을 모두 신뢰하기 때문에 특히 두 집단이 동일한 은행(160)의 고객인 경우에 집단 사이의 빠른 송금이 가능하다.
신뢰된 플랫폼(120)은 또한 사용자 장치(110')들 사이의 사전 인가된 거래 값(예컨대, 선불 값)을 나타내는 토큰의 전달을 용이하게 한다. 네트워크 통신이 이용 가능한 경우에, 이는 상기 설명한 처리를 사용해서 핸들링될 수 있다. 네트워크 통신이 이용 불가능한 경우에는, 이는 예컨대, 선불 토큰을, 전달하는 장치(110')와 수신하는 장치(110') 각각에 고유하게 관련된 신뢰된 식별자와 연관시킴으로써 수행될 수 있다. 필요에 따라서 전달은 네트워크 통신이 복구되면 확인될 수 있다. 다른 방안으로, 지불 토큰은 제 1 장치(110')로부터 삭제되고, 새로운 금융적인 등가물이 수신 장치(110') 상에, 혹은 이에 의해서, 혹은 이를 위해서 생성될 수 있다.
도 2에는, 본 발명에 따른 시스템(100)의 일 실시예의 개략도가 도시되어 있다. 도 2에서 달라진 점은 특히 '저장된 현금' 혹은 '공유된 현금' 풀(170)로, 하나 이상의 신뢰된 플랫폼(120)에 의해 제어되는 메모리에 저장된 보안 데이터 세트(125)(도 1 참조)의 형태이다. 이러한 보안 데이터 세트(125)는 금전적 가치의 풀을, 실제 혹은 가상 통화나 가치 혹은 그 인디셔(indicia) 중 소망의 형태를 나타내는 데이터의 형태로 나타낼 수 있으며, 이는 예컨대, 도 1에 도시된 바와 같은 복수의 신뢰된 FSP(120, 160)에 분배되거나 이로부터 인출될 수 있으며, 다양한 신뢰된 FSP(120, 160)에 계좌를 유지하는 집단(110, 130)들 사이에서 수행되는 거래를 보안되고 잠재적으로는 매우 고속으로 결제하는데 사용된다. 당업자라면, FSP(120, 160)가 일단 본 개시와 유사하게 만들어지면, FSP(120, 160)는 캐나다 왕립 은행(RBC), 몬트리올 은행(BMO), 캐나다 임페리얼 상업은행(CIBC) 등과 같은 은행이나 다른 금융 기관을 포함한 다양한 개체가 될 수도 있고, 이를 포함할 수도 있고, 혹은 이에 의해 관리되거나 혹은 이와 관련될 수도 있다는 것을 이해할 것이다.
도 3 및 도 4를 참조하면, 본 발명에 따른 시스템(100)의 추가 실시예가 개략적으로 도시되어 있다. 도 3 및 4에서 달라진 점은 특히 판매자 시스템(132, 130)과 하나 이상의 FSP 시스템(160) 사이에 신뢰된 플랫폼(120, 160)을 배치함으로써 효율 및 효과가 개선된 몇가지 특정한 서비스의 예이다. 이는 제4자 시스템(120)을 통한 종래의 처리의 대안으로 혹은 이에 더해서, 예컨대, 122로 도시되어서 상기 설명한 신뢰된 플랫폼에 모두 등록되어 있는 집단들(예컨대, 사용자(110')와 판매자(130)) 사이의 '책임(on-us)' 및/또는 다른 '종래 지불 시스템으로부터의 탈선' 지불의 신속한 정산 및 결제를 포함한다. 302에 도시된 바와 같이, 거래에 대한 집단(110, 130) 중 하나 이상이 신뢰된 플랫폼(120)에 등록되지 않은 경우에, 예컨대, 모든 집단이 FSP(160)에 계좌를 갖고 있는 경우에, '책임' 거래는 다른 FSP(160)에 의해 완수될 수 있다는 점에 주의한다.
도 3 및 도 4의 124에 도시된, 시스템(100)의 신뢰된 플랫폼(120)에 의해서 효과가 향상될 수 있는 서비스의 또 다른 예시는, 쿠폰, 로열티 포인트, 디스카운트, 및 신뢰된 플랫폼(120)에 의해 처리되는 거래에 관계된 개선된 혹은 다른 수령액을 나타내는 데이터 세트의 생성의 제공 및/또는 상황과 같은 부가가치 서비스이다. 예컨대, 상술한 바와 같이, 이러한 서비스는, 사용자(110')와 판매자 시스템(130) 사이의 거래에 대한 지불을 해석하고 처리할 때, 예컨대 로열티 혹은 기프트 프로토콜과 같은 추가적인 프로토콜 및/또는 대체 프로토콜을 사용해서 제공될 수 있다.
126에 나타난 바와 같이, 신뢰된 플랫폼(120)은, 지불되지 않은 관련 애플리케이션을 통해서 제공되는 예시적인 서비스를 포함한, 소망의 보조 혹은 다른 서비스를 제공 혹은 수행할 수 있다. 이는 예컨대, 신뢰된 플랫폼(120), 판매자(130) 등이 제공하는 다른 상품 혹은 서비스에 대한 링크를 포함할 수 있다.
상술한 바와 같이, 본 발명에 따른 시스템(100)은 지불 및 다른 금융 거래에 더해서 혹은 그 대신에 다수의 애플리케이션에서 사용하기에 적합하다. 도 4의 400에 도시된 바와 같이, 이러한 애플리케이션은 예컨대 전자 건강 기록; 예컨대 패스포트 및 다른 식별자, 세금 기록, 범죄 및 다른 재판 기록, 경찰 및 정보 데이터 등을 포함한 신분 기록과 같은 정부 기록; 및 폭넓은 재산 혹은 다른 가치있는 디지털 컨텐츠의 유지보수, 사용 및 분석을 포함한, 다양한 폭넓은 민감한 혹은 다른 바람직한 보안 데이터 처리를 포함할 수 있다.
도 5를 참조하면, 본 발명에 따른 시스템(100)의 추가 실시예가 도시되어 있다. 상술한 바와 같이, 장치(110, 110')는 본 명세서에 개시된 목적을 달성하는데 사용하기에 적합한 임의의 장치 혹은 장치의 조합을 포함하거나 이로부터 이루어일 수 있다. 예컨대, 사용자 장치(110, 110')는 사용자의 데스크톱 컴퓨터를 포함할 수 있는데, 이는 경우에 따라서, 전형적으로 스마트폰, 태블릿 혹은 웨어러블 장치 등과 같은 모바일 장치에 의해 제공되는 하드웨어/통신 리소스의 결핍을 초래할 수 있다.
이러한 경우에, 사용자가 예컨대 PSTN/인터넷 및 데스크톱 판매자 애플리케이션을 통해서 판매자 시스템(130)과 구매 혹은 다른 거래를 개시하면, 다양한 데이터 및/또는 거래 확인 신호를 포함한 다른 신호가 시스템(120, 160, 130) 중 일부 혹은 전체에 의해서 생성되어서, 구매 사용자 혹은 계좌 보유자와 같은 금융 담당 집단으로부터의 확인을 획득할 때의 장치(110')에 의한 사용을 위해서 사용자의 등록된 장치(110')로 전달될 수 있다. 예컨대, 구매 혹은 다른 거래 요청이 등록된 데스크톱 장치(110')에 의해 생성되면, 거래 완료 이전에 신뢰된 플랫폼(120)은 등록된 데스크톱 장치(110')의 사용자에 의한 확인 요청을 거래에 관한 계좌와 관련된 스마트폰과 같은 신뢰된 모바일 장치(110')로 라우팅할 수 있다. 이러한 실시예는 거래의 보안을 상당히 증가시키고, 사기 및 다른 형태의 남용, 실수 등을 감소시킬 수 있다. 나아가, FI/FSP(160) 및 제4자 FSP(150)를 거래 데이터 스트림에서 제거함으로써, 서버들 사이에서 교환되는 정보의 양은 감소되고, 프라이버시는 증가될 수 있다. 예컨대, 카드 발행자는 최종 거래값만을 통지받게 되고, 다른 세부 사항은 통지받지 않는다.
도 6을 참조하며, 네트워크 거래 통신 장치(110)가, 본 발명의 실시예에 따른, 신뢰된 장치(110')로서 등록 혹은 설정될 수 있는 모바일 장치(600)의 형태로, 개략적으로 도시되어 있다. 상술한 바와 같이, 장치(110, 160)는 일반적으로 전자적인, 구조적인 및/또는 전자-기계적인 컴포넌트의 어셈블리를 적절한 하우징 내에 포함하고 있으며 사용자에게 근거리 및/또는 장거리 네트워크 접속을 포함한 다양한 음성 및/또는 데이터 기능을 제공하는 휴대형 전자 장치가 될 수 있다. 본 명세서에서 사용되는 용어 '휴대형' 혹은 '모바일'은 장치(110, 600)가 일반적으로 서로 다른 물리적인 위치 사이에서 물리적인 도움에 의지하지 않고 사용자에 의해서 이동될 수 있다는 것을 나타낸다는 것을 이해할 것이다. 특히, 장치(110, 600)는, 셀룰러 혹은 다른 무선 전화, PDA, 태블릿, 노트패드, 휴대형 컴퓨터, 스마트 워치나 주얼리 등과 같은 사용자의 신체 혹은 옷으로 이동될 수 있는 장치를 포함할 수 있다. 그러나, 본 발명의 다양한 측면 및 실시예는 랩톱이나 개인용 컴퓨터와 같은 비모바일 통신 장치(110)를 사용해서도 구현될 수 있다.
따라서, 일부 실시예에서, 모바일 혹은 다른 장치(110, 600)는 하나 이상의 CPU(602), RAM(604) 및 다른 물리적인 메모리(606)를 포함할 수 있으며, 이들 중 하나 이상은 비일시적(즉, 영구적) 데이터 및 머신 해석 가능 명령어 세트를 저장할 수 있다. 일반적으로, CPU(602)는 모바일 장치(110, 600)의 전체 동작을 제어하도록 구성된 임의의 마이크로프로세서 혹은 다른 다목적이나 특수 목적 프로세싱 유닛이 될 수 있으며, CPU(602)는 데이터, 전력 및/또는 다른 신호를 모바일 장치(110, 600)에서 전달하기에 적합한 버스나 혹은 다른 전자 링크 혹은 경로에 의해 여기에 접속될 수 있다. CPU(602)의 읽기 및 쓰기 동작은, CPU(602)와 연관되거나 CPU(602)와 일체화된 혹은 CPU(602)가 액세스하는, RAM(604) 혹은 일부 다른 집적 회로나 휘발성 메모리 저장부에 의해 가능하게 된다.
메모리(606)는 플래시 메모리나 ROM과 같은 하나 이상의 영구(즉, 비일시적) 메모리 저장부를 포함할 수 있으며, 이는 모바일 장치(110, 600) 내에 물리적으로 내장되거나 혹은 이와 달리 SIM(subscriber identity module) 카드 혹은 SD(secure digital) 메모리 카드와 같이 사용자에 의해서 모바일 장치(110, 600)에 착탈가능하게 로딩 혹은 삽입될 수 있다. 메모리(606)는 임의의 타입의 데이터 및/또는 실행 가능 머신 명령어 파일을 저장하는데 사용될 수 있으며, 비한정 예로서 미디어 파일(음악 및 사진)은 물론 모바일 장치 운영 체제(OS)(608) 및 다른 프로그램이나 애플리케이션을 본 명세서에 개시된 바와 같이 구현하는데 사용되는 소프트웨어를 들 수 있다. 메모리(606)는 또한, 연락처 정보, 네트워크 즐겨찾기, 애플리케이션 데이터 및 다른 파일과 같은, CPU(602) 혹은 모바일 OS(608)가 모바일 장치(110, 600) 상의 다양한 기능을 실행하거나 다양한 컴포넌트를 제어하는데 사용하는 하나 이상의 파일을 저장하는데도 사용될 수 있다.
다양한 실시예에서, 모바일 장치(110, 600)에는 또한 사용자가 모바일 장치(110, 600)와 인터렉트하기 위한 하나 이상의 컴포넌트가 내장될 수 있다. 본 명세서에서 610으로 표현하는 이러한 컴포넌트는, 사용자가 모바일 장치(110, 600)에 데이터 및 커맨드를 입력하는 것은 물론 모바일 장치(110, 600)에 의해 입력되는 데이터나 정보를 인식하기 위해서 제공될 수 있다. 비한정 예로서, 가능한 여러가지 입력 컴포넌트(610)는 터치패드, 다이얼, 클릭 휠, 터치스크린, 키보드 및 다른 버튼은 물론, 카메라, 마이크 및 생체 센서(예컨대, 지문 스캐너)를 포함할 수 있다. 예시적인 출력 컴포넌트(610)는 스피커, 스크린 및 시각적 디스플레이, 럼블 팩 및 이들의 조합을 포함할 수 있다. 본 명세서에 상세하게 설명하지 않은 다른 I/O 컴포넌트(610)도 다양한 실시예에 포함될 수 있다.
일부 실시예에서, 도 6에 도시된 바와 같이 모바일 장치(110, 600)는, 모바일 장치(110, 600)에 다양한 음성 및 데이터 통신 기능을 제공하는, 하나 이상의 장거리 혹은 네트워크 통신 컴포넌트(612) 및/또는 하나 이상의 단거리 네트워크 통신 컴포넌트(614)를 더 포함한다. 용어 '장거리' 및 '단거리'는 상대적인 거리를 나타내는데 사용되는 것으로, 특정한 제한이나 범위를 나타내는 것은 아니라는 것을 이해할 것이다. 따라서, 장거리 통신 컴포넌트(612) 및 단거리 통신 컴포넌트(614)는 모바일 장치(110, 600)가 다른 가깝게 위치된 혹은 멀리 위치된 대상과의 통신을 가능하게 하는 것으로, 이는 다른 유사하게 혹은 상이하게 구성된 모바일 장치, 서버, 시스템 및 다른 네트워크 가능 장치가 될 수 있다.
예컨대, 장거리 혹은 네트워크 통신 컴포넌트(612)는 모바일 장치(110, 600)가, 적절한 음성 및/또는 데이터 통신 프로토콜을 이용하여 셀룰러 혹은 다른 분산형 네트워크를 통해서, 적절한 대상과 통신하는데 사용될 수 있으며, 이 프로토콜은 비한정 예로서 TDMA(Time Division Multiple Access), CDMA(Code Division Multiple Access), GSM(Global System for Mobile Communication), WAP(Wireless Application Protocol) 등이다. 이러한 프로토콜에 이어서, 모바일 장치(110, 600)는 비한정 예로서 음성, 데이터 및 텍스트 기반 메시지를 포함한 다양한 타입의 임의의 원격 장치에 통신을 송신할 수 있다. 장거리 통신이 가능하도록, 컴포넌트(612)에는 안테나, 송신기, 수신기 및 디지털 신호 프로세서와 같은 다양한 하드웨어 및/또는 소프트웨어 컴포넌트가 포함될 수 있다. 장거리 통신 컴포넌트(612)의 특정 구성은 일반적으로 구현되는 통신 프로토콜에 따라서 달라질 수 있다.
단거리 혹은 근거리 무선 통신 컴포넌트(614)는 모바일 장치(110, 600)와 다른 비교적 가깝게 위치된 장치, 서버 혹은 시스템 사이의 통신을 가능하게 할 수 있다. 예컨대, 단거리 통신 컴포넌트(614)는 Wi-Fi(802.11 표준) 혹은 블루투스 네트워크에 대한 접속은 물론, RFID, 적외선이나 옵티컬과 같은 다른 단거리 통신 모드와 같이, 하나 이상의 단거리 송수신기를 포함할 수 있다. 일부 실시예에서, 단거리 통신 컴포넌트(614)는 이하 설명하는 바와 같이 판매자 POS 단말과의 비접촉 모바일 지불을 개시하기 위해서, 특히 다양한 목적 및 기능 중에서 NFC 판독기와 통신하는데 사용될 수 있는 NFC(near field communications) 서브시스템(616)을 포함할 수 있다.
일부 실시예에서, 모바일 장치(110, 600)는, 이하 설명하는 지불 크리덴셜 혹은 암호화 데이터 프로그래밍 구조와 같은, 민감 데이터 및 다른 정보에 대한 조작 방지, 액세스 제한 저장 환경으로서 구현된 하나 이상의 보안 소자(618)를 더 포함할 수 있다. 예컨대, 보안 소자(618)는 집적 회로(IC), 운영 체제(OS), 및 가상 월렛 애플리케이션(112, 622), 카드 에뮬레이션 애플리케이션 등을 포함한 애플리케이션이나 프로그램 모두 혹은 일부를 포함할 수 있다. 보안 소자(618)는 모바일 장치(110, 600) 내에 물리적으로 매립(일체화)될 수도 있고, 혹은 다른 방안으로 모바일 장치(110, 600)에 삽입 가능한 SIM 혹은 SD 카드와 같은 카드에 제공될 수도 있다. 도시된 바와 같이, CPU(602) 및 NFC 서브시스템(616)은 일부 경우에 보안 소자(618)의 컨텐츠에 액세스할 수 있다. 다른 방안으로, 액세스는 모바일 장치(110, 600)의 애플리케이션 혹은 구성에 따라서 CPU(602) 및 NFC 서브시스템(616) 중 하나 이상에 대한 액세스로 제한될 수 있다.
모바일 장치(110, 600)는, 전력을 생성, 수신 혹은 CPU(602)나 모바일 장치(110, 600)의 다른 컴포넌트에 전달하기에 적합한 임의의 컴포넌트 혹은 회로로 구성된 하나 이상의 급전부(620)를 더 포함할 수 있다. 예컨대, 급전부(620)는, 모바일 장치(110, 600)가 외부 전원에 플러그인 혹은 접속될 때, 전기 시설 혹은 전력망과 같은 외부 전원으로부터 수신한 전력을 처리하는 회로를 포함할 수 있다. 일부 경우에, 급전부(620)는 모바일 장치(110, 600)가 외부 전원에 접속될 수 없을 때 전원을 제공할 수 있는 니켈 금속 하이브리드, 니켈 카드뮴 및 리튬-이온 배터리와 같은, 하나 이상의 배터리를 더 포함할 수 있다. 급전부(620)가 모바일 장치(110, 600) 내의 다양한 컴포넌트에 에너지를 전달할 수 있도록, 태양광 패널이나 유도 코일과 같은 다른 전력 생성 혹은 처리 회로가 또한 포함될 수 있다. 급전부(620)와 모바일 장치(110, 600) 내의 다른 컴포넌트 사이의 개개의 접속은 도 6에 도시되어 있지 않으며, 급전부(620)는 편의상 분리된 구성 요소로서 도시되어 있다.
상술한 바와 같이, 많은 실시예에서, 요청 통신 장치(110, 110')는 '모바일' 장치가 아니다. 따라서 예컨대 사용자 장치(110, 110')는 물리적인 도움 없이도 사용자가 적지 않은 거리를 이동하는 것을 어렵게 하거나, 불편하게 하거나 혹은 비실용적이게 하는 크기, 형상 및/또는 무게를 가질 수 있다. 상세하게, 비모바일 사용자 장치(110, 110')는 사용자가 자신의 신체나 의류로 실제로 이동시킬 수 없는 것이 될 수도 있다. 비모바일 사용자 장치(110, 110')의 예는 사용자의 데스크톱 컴퓨터 및 다른 컴퓨팅 장치를 포함한다.
설명된 실시예에 따른 비모바일 장치(110, 110')는 통신 성능, 보안 메모리 등의 측면에서 도 6에 도시된 모바일 장치(600)와 다를 수도 있고 다르지 않을 수도 있다. 예컨대, 비모바일 장치(110, 110')는 도 6에 도시된 컴포넌트 중 하나 이상은 생략될 수도 있고(혹은 생략되지 않을 수도 있고), 혹은 경우에 따라서 추가적인 혹은 상이하게 구성된 컴포넌트를 포함할 수 있다. 일부 경우에, 비모바일 장치(110, 110')가 SIM 혹은 SD 카드를 수용하도록 구성되어 있지 않아서 비모바일 장치(110, 110')에서 보안 소자(618)가 생략될 수도 있다. 일부 경우에, 장거리 통신 컴포넌트(612) 및 단거리 통신 컴포넌트(614) 중 적어도 하나는 상이할 수도 있다. 예컨대, 먼 거리를 무선 통신하도록 구성된 장거리 통신 컴포넌트(612) 대신에, 사용자 장치(110, 110')는 셀룰러 안테나 대신 인터넷과 같은 분산형 네트워크에 접속하기 위한 모뎀 혹은 다른 네트워크 컴포넌트를 포함할 수 있다. 일부 경우에, 단거리 통신 컴포넌트(614)는 NFC 수신기(616)를 포함하지 않고, WI-FI 및/또는 블루투스 안테나 등을 포함할 수 있다. 본 명세서에 개시된 시스템 및 프로세스의 실시예는 비한정예로서 모바일 장치(600)나 비모바일 장치를 사용할 수 있다.
도 7을 참조하면, 모바일 장치(110, 600)는 다양한 실시예에 따라서, 본 명세서에 개시된 바와 같이 신뢰된 플랫폼(120)과 함께, 판매자 POS 단말에 대한 근접도 기반 지불 거래를 나타내는 비접촉식 신호 교환을 개시하는데 사용될 수 있다. 이러한 비접촉식 지불은 보안 소자(618) 내에 저장된 지불 크리덴셜을 사용할 수도 있고, 혹은 이와 달리 HCE 환경으로서 구성된 월렛 애플리케이션(112, 622) 내에 저장된 지불 토큰을 사용할 수도 있다. 다른 실시예에서, 지불 토큰은 모바일 장치(110, 600)가 액세스 가능한 보안 클라우드에 저장될 수도 있다.
따라서, 일부 실시예에서, NFC 서브시스템(616)은 임의의 적절한 근접도 기반 통신 컴포넌트나 혹은 대응하는 NFC 판독기(132, 134, 700) 혹은 다른 유사한 가능 타깃 장치와의 비접촉식 근접도 기반 통신을 가능하게 하는 컴포넌트의 조합을 포함할 수 있다. 예컨대, NFC 서브시스템(616)은, 13.56 MHz의 글로벌하게 이용 가능한 무허가 무선 주파수 ISM 대역(ISO/IEC 14443 및 ISO/IEC 18092와 같은 관련 표준에 명시된)으로 동작하도록 구성된 안테나 혹은 송수신기(624) 및 제어기(626)를 포함할 수 있다. 경우에 따라서, NFC 서브시스템(616)은 이와 달리 다른 통신 기술 혹은 표준에 따라서 동작할 수도 있다.
비접촉 지불을 개시하기 이전에, 사용자는 모바일 장치(110, 600)에 하나 이상의 지불 크리덴셜 혹은 지불 크리덴셜의 세트를 제공할 수 있고, 이는 보안 소자(618) 및/또는 모바일 장치(110, 600)에 저장될 수 있다. 예컨대, 경우에 따라서, 사용자는 보안 소자(618)에 저장하기 위해서 지불 크리덴셜을 월렛 애플리케이션(112, 622)에 직접 입력할 수도 있다. 이러한 지불 크리덴셜은 보안 소자(618)에 저장되면, 토큰화되지 않고 직접 입력 및 저장되는 것도 가능하다.
다른 방안으로, 모바일 장치(110, 600)는 신뢰된 플랫폼과 같은 발행 은행 혹은 다른 개체에 의해 인가된 지불 방법에 따라서 토큰화된 지불 크리덴셜을 제공받을 수도 있다. 예컨대, 모바일 장치(110, 600)에 위치되어 있지 않은 것을 포함한 월렛 애플리케이션(112, 622) 혹은 다른 프로그램이나 애플리케이션이 사용자의 발행 은행 혹은 일부 다른 개체로부터 지불 토큰을 요청하는데 사용될 수도 있다. 이러한 지불 토큰은 일회용이 될 수도 있고 다회용이 될 수도 있으며 혹은 사용에 다른 제한 혹은 한도가 있을 수도 있고, 모바일 장치(110, 600)에서 일단 수신되면, 월렛 애플리케이션(112, 622)에 저장될 수도 있고, 혹은 모바일 장치(110, 600)에 저장될 수도 있다. 경우에 따라서, 지불 토큰은 보안 소자(618)에 저장될 수 있으며, CPU(602)를 통해서 월렛 애플리케이션에 의해 액세스될 수도 있다.
비접촉식 지불을 개시하기 위해서, 모바일 장치(110, 110', 600)를, 판매자 POS 단말 혹은 시스템(130)으로 동작하거나 혹은 그 일부를 이루는 NFC 판독기(132, 134, 700)의 범위로 이동시켜야 한다. 이 범위 내에서 NFC 판독기(132, 134, 700)는, NFC 송수신기(624)에서 수신한 지불 크리덴셜의 거래 및 제공의 개시를 요청하는 신호를 모바일 장치(110, 600)에 송신할 수 있다. 모바일 장치(110, 600)에서 구현되는 프로토콜의 구성 및 타입에 따라서, NFC 제어기(626)는 비접촉식 거래를 다양한 방식으로 응답 및 처리할 수 있다.
예컨대, 일부 실시예에서, 모바일 장치(110, 110', 600)는 카드 에뮬레이션(CE) 모드로 동작하도록 구성될 수 있으며, 이로써 모바일 장치(110, 600)는 보안 소자(618) 내의 지불 크리덴셜의 저장을 통해서 비접촉식 지불 카드를 에뮬레이트한다. 이러한 처리 모드에서, NFC 제어기(626)는 NFC 송수신기(624)에 의해 수신된 거래 요청을 보안 소자(618)로 라우팅할 수 있고, 여기서 사용자의 지불 크리덴셜은 에뮬레이션 애플리케이션(628)에 저장될 수 있다. 취즉된 지불 크리덴셜은 NFC 판독기(132, 134, 700)로 송신하기 위해서 NFC 제어기(626)에 의해서 NFC 송수신기(624)로 다시 라우팅될 수 있다. 이 거래는 판매자 POS 단말기와 관련된 백엔드 혹은 지불 네트워크를 통해서 처리될 수 있다.
다른 방안으로, 모바일 장치(110, 600)는 본 명세서에 개시된 바와 같이 보안 소자(618) 대신 월렛 애플리케이션(112, 622) 내에 저장될 수 있는 지불 토큰의 제공을 통해서 HCE에 맞춰 구성될 수 있다. 따라서, 이 처리 모드에서, NFC 제어기(626)는 NFC 송수신기(624)가 수신한 거래 요청을 CPU(602)로 라우팅하고 보안 소자(618)로는 라우팅하지 않으며, 이로써 월렛 애플리케이션(112, 622)으로부터 지불 크리덴셜을 취득한다. 취득한 지불 크리덴셜은 CPU(602)에 의해서 NFC 제어기(626)으로 반환되고, NFC 판독기(132, 134, 700)로 송신하기 위해서 NFC 송수신기(624)로 다시 라우팅될 수 있다. 이 거래는 다시 판매자 POS 단말기와 관련된 백엔드 혹은 지불 네트워크를 통해서 처리될 수 있다.
도 8을 참조하며, 여기서 모바일 혹은 다른 장치(110, 110', 600)는 본 발명의 실시예에 따라서 혹은 이하 더 설명되는 바와 같이, 하나 이상의 웹 브라우저나 판매자 거래 통신 애플리케이션(114)과 같은 다른 비전용 애플리케이션 혹은 프로그램으로부터, 판매자와 관련된 애플리케이션 혹은 프로그램 내에서 모바일 지불을 직접 개시하도록 구성될 수도 있다. 따라서, 모바일 장치(110, 600)와 판매자 POS 단말 사이의 NFC 통신을 사용해서 완수되는 비접촉식 지불과 달리, 이러한 전자 지불은 판매자 POS 단말에 대한 물리적인 근접을 요구하지 않으며, 모바일, 데스크톱 혹은 다른 장치(110, 600)가 네트워크 접속하는 어디에서나 판매자 애플리케이션으로부터 개시될 수 있다.
따라서, 하나 이상의 다양한 판매자 거래 통신 애플리케이션(114, 630) 혹은 다른 프로그램은 모바일 장치(110, 110', 600)의 사용자에 의해서 모바일 혹은 다른 OS(608)로 인스톨될 수 있다. 판매자 애플리케이션(114, 630)이 편의상 도 8에 하나만 도시되어 있지만, 사용자의 기호에 따라서 다른 실시예에서는 임의의 수가 인스톨될 수도 있다. 다른 가능한 기능 중에서, 판매자 애플리케이션(114, 630)을 통해서 사용자는, 판매자 애플리케이션(114, 630)로부터 사용자에게 판매자가 디스플레이 혹은 광고하는 제품 혹은 서비스를 구매하는 것을 가능하게 한다. 다른 가능한 판매자 애플리케이션(114, 630)은, 판매자의 상품 및/또는 서비스에 전용인 것은 물론, 판매자의 상품 및/또는 서비스를 고객에게 간접적으로 제공하는 경매 사이트와 같은 제3자 애플리케이션을 포함할 수 있다.
일부 실시예에서는, 이하 설명하는 바와 같이, 판매자 거래 통신 애플리케이션(114, 630)은, 임의의 대응하는 월렛 애플리케이션(112, 622)을 오픈 혹은 론칭할 필요없이, 하나 이상의 월렛 애플리케이션(112, 622)에 저장된 지불 크리덴셜 혹은 다른 정보가 판매자 애플리케이션(114, 630)에 의해 풀링될 수 있도록 구성될 수 있다. 예컨대, 판매자 애플리케이션(114, 630) 내에서 지불 거래가 개시되면, 사용자는, 하나 이상의 월렛 애플리케이션(112, 622) 중 어느 것에 저장된 지불 크리덴셜 중 어느 것을 거래 실행에 이용하기 위해 풀링할지에 대한 선택을 사용자에게 제공하는 스크린 혹은 프롬프트를 제시받을 수 있다. 이와 달리, 판매자 애플리케이션(114, 630)은, 사용자에게 프롬프트하지 않고 월렛 애플리케이션(112, 622)으로부터 디폴트 혹은 사전 선택된 지불 크리덴셜을 자동으로 풀링할 수 있다.
장치의 폴링(polling)과 HCE 및 다른 지불 크리덴셜의 풀링은 중요한 이점이 될 수 있다. 예컨대, 이러한 처리는 거래를 완수할 때 구매자 및 다른 사용자(190)에게 오픈되는 지불 옵션의 수를 상당히 증가시킬 수 있고, 따라서 판매자 및 FI/FSP에 대한 거래 기회를 증가시킬 수 있다. 장치(110) 및 옵션으로서 FI/FSP(120, 160)의 폴링 및 지불 크리덴셜의 풀링을 용이하게 하기 위해서, 판매자 애플리케이션(114, 130, 630), 월렛 애플리케이션(112, 622) 및 FI/FSP 시스템(120, 150, 160) 중 일부 혹은 전부는, 예컨대, 공통 통신 및 데이터 기록 생성 및 프로토콜 처리를 포함한 공통 표준에 따라서 지불 및 거래 데이터를 처리하도록 구성될 수 있다. 이러한 프로토콜은 예컨대, 본 발명에 따라서, 도 12에 예로서 도시되어서 이하 설명하는 바와 같이, 공통 혹은 유니버설 API(116)를 사용한 애플리케이션 간의 데이터 교환의 구현을 용이하게 하는데 사용될 수 있다. 이러한 유니버설 API의 사용은 중요한 이점이 될 수 있으며, 예컨대, 공통 혹은 유니버설 토큰 및/또는 HCE 크리덴셜 프로토콜에 따라서 동작함으로써, 유니버설 API(116)는 거래 실행 시에 폭넓은 지불 옵션을 사용자(190)와 같은 구매자에게 제공할 수 있다. 따라서, 이러한 API(116)는 많은 경우에 지불 옵션 API이 될 수 있다. 본 발명의 이러한 측면 및 실시예의 적절한 구현예에 대해서 이하 설명한다.
거래르리 개시하기 이전에 혹은 개시하는 동안에, 판매자 애플리케이션(114, 630) 및/또는 월렛 애플리케이션(112, 622)은 셀룰러 네트워크이나 인터넷 혹은 다른 네트워크 타입의 조합과 같은 네트워크(850)를 통해서(통신 컴포넌트(632, 612) 중 적어도 하나를 통해서), 중앙 인증 기관이나 혹은 신뢰된 플랫폼와 관련된 하나 이상의 서버(800)와 같은 하나 이상의 원격 서버(800)와 통신할 수 있다. 예컨대, 판매자 애플리케이션(114, 630)은 가격 혹은 용도와 같은 판매를 위해 제공되고 있는 상품 및/또는 서비스와 관련된 정보 혹은 데이터를 판매자 서버로부터 풀링하도록 구성될 수 있다. 나아가, 이하 설명하는 바와 같이, 판매자 애플리케이션(114, 630) 및 월렛 애플리케이션(112, 622)은 또한, 현재의 거래 혹은 모바일 장치(110, 600)에서 사용자가 개시하는 미래의 거리를 위해서, 증명서 혹은 다른 암호화 데이터의 형태의 인가를 얻기 위해서 원격 서버(800)와 통신할 수도 있다.
따라서, 일부 실시예에서, 모바일 OS(608)는 장거리 통신 컴포넌트(612) 및 단거리 통신 컴포넌트(614) 중 적어도 하나에 연결되어서, 월렛 애플리케이션(112, 622) 및/또는 판매자 애플리케이션(114, 630) 또는 다른 애플리케이션(115)에 네트워크 접속을 제공할 수 있다. 장거리 통신 컴포넌트(612)는 WAP 통신 프로토콜을 구현하는 등 셀룰러 네트워크에 접속을 제공할 수 있다. 다른 방안으로, 네트워크 접속은 모바일 장치(110, 600)의 무선 네트워크 및 핫스팟으로의 접속을 가능하게 하는 WI-FI 안테나(632)를 통해서 제공될 수도 있다. 네트워크(350)에 접속을 제공하기 위해서 블루투스와 같은 다른 통신 프로토콜이 월렛 애플리케이션(112, 622) 및 판매자 애플리케이션(114, 630)에 의해서 사용될 수도 있다.
도 9에 예로서 더 도시된 바와 같이, 일부 실시예에서, 모바일 OS(608)는 또한, 게임, 다목적 웹 브라우저, 판독기 등과 같은 하나 이상의 비판매자 애플리케이션 혹은 프로그램(115)을 포한하거나 지원할 수 있으며, 이로부터 전자 거래가 개시될 수도 있다. 이러한 비판매자 애플리케이션은 하나 이상의 모바일 월렛 애플리케이션(112, 622)에 연결되어서 여기에 저장될 수 있는 지불 토큰 혹은 다른 크리덴셜을 취득할 수 있고, CPU(602)를 통해서 단거리 통신 컴포넌트(614) 혹은 장거리 통신 컴포넌트(612) 혹은 비모바일 사용자 장치(110, 110')에 인스톨된 모뎀과 같은 임의의 다른 네트워크 컴포넌트와 같은 네트워크 통신 컴포넌트에 연결될 수 있다.
전자 거래를 개시하기 위해서, 사용자는 예컨대, 본 명세서에 개시된 바와 같은 임의의 이용 가능한 I/O 장치를 사용해서 웹 페이지 혹은 웹사이트에 네비게이트할 수 있다. 예컨대 판매자 애플리케이션의 가상 쇼핑 카드에 추가할 아이템을 선택함으로써, 예컨대, 사용자가 구매하고자 하는 하나 이상의 아이템 및 아이템, 소계(subtotal) 및/또는 총 구매 가격과 함께 그 전체 설명이나 일부 설명을 나타내는 데이터를 포함하는 적절하게 구성된 거래 요청 데이터 세트(혹은 '요청된 거래 데이터 세트')를 사용자(190)가 생성하고, 지불(예컨대, '계산') 처리를 개시한 이후에, 판매자 애플리케이션(115)은 모바일 OS(608)에 인스톨된 월렛 애플리케이션(112, 622)을 이용해서 거래에 대한 지불을 행하기 위해서 사용자에게 옵션을 표시할 수 있다. 다른 방안으로, 거래에 사용하기 위해서 선택된 지불 토큰은 메모리에 위치될 수도 있고 혹은 모바일 장치(110, 110', 600)의 위치에 위치될 수도 있으며, 혹은 경우에 따라서는 보안 클라우드 리소스 내의 가상 월렛(112, 622)이나 다른 메모리 혹은 애플리케이션에 저장될 수도 있다. 사용자가 월렛 애플리케이션(112, 622)에 의한 지불을 선택하면, 브라우저는 선택된 지불 형태에 따라서 적절한 지불 토큰을 획득하기 위해서 월렛 애플리케이션(112, 622)와 인터페이스할 수 있다. 획득한 지불 토큰은 판매자 백엔드에 의한 처리를 위해서 단거리 통신 컴포넌트(614) 혹은 장거리 통신 컴포넌트(612)를 통해서 송신될 수 있다. 다른 방안으로, 사용자는 일부 형태의 식별 정보를 이용해서 모바일 장치(110, 110') 상의 애플리케이션 혹은 프로그램으로부터 은행 계좌에 보안 로그인할 수 있으며, 일단 인증되면, 사용자의 은행은 거래를 처리하기 위해서 전자 지불 토큰을 판매자/인수자에게 송신할 수 있다. 지불 네트워크나 다른 개체를 통해서 전자 지불 처리는 본 명세서에 개시된 바와 같이 처리될 수 있다.
따라서, 예컨대, 다양한 측면 및 실시예에서, 본 발명은 시스템, 프로세스, 그리고 영구 저장된 머신 액세스 가능 및 머신 판독 가능 프로그래밍 구조를 제공하며, 이들은 스마트폰, 태블릿 컴퓨터, 웨어러블 장치 혹은 다른 모바일 장치와 같은 하나 이상의 요청 장치(110)가 통신 네트워크(200)를 지나는 적절하게 구성된 신호 교환을 통해서 신뢰된 플랫폼 서버(120)에 등록되는 것을 가능하게 하고, 이러한 등록의 결과, 증명서 혹은 토큰 데이터 세트와 같은 보안 데이터 세트가 제공되어서 장치(110)의 휘발성 혹은 비휘발성 메모리에 저장되며, 이로써 장치(110)는 이후 구매 혹은 거래를 처리할 때 신뢰된 장치(110')에 의해서 신뢰된 플랫 폼서버(120)로서 인가되게 된다. 예컨대, 증명서 데이터 세트는, 장치(110') 및/또는 이러한 장치와 관련된 특정 지불 계좌 중 하나 이상과 고유하게 연관된 임의의 데이터를 포함할 수 있다. 이러한 증명/식별 데이터는 예컨대, 이름, '비밀' 개인 정보, 일련 번호, 랜덤 혹은 의사 랜덤 코드, 계좌 번호 등을 포함할 수 있다.
다양한 측면 및 실시예에서 본 발명은 또한, 시스템, 프로세스, 그리고 영구 저장된 머신 액세스 가능 및 머신 판독 가능 프로그래밍 구조를 제공하며, 이들은 예컨대 POS 및 백엔드 프로세싱 시스템을 포함한 하나 이상의 판매자 장치(132, 134, 136, 130)가 통신 네트워크(200)를 지나는 적절하게 구성된 신호 교환을 통해서 동일한 혹은 다른 신뢰된 플랫폼 서버(120)에 등록되는 것을 가능하게 하고, 이러한 등록의 결과, 증명서 혹은 토큰 데이터 세트와 같은 보안 데이터 세트가 제공되어서 장치(132, 134, 136, 130)의 휘발성 혹은 비휘발성 메모리에 저장되며, 이로써 판매자 장치는 이후 구매 혹은 거래를 처리할 때 신뢰된 플랫폼 서버(120)에 의해서 신뢰된 장치(130')로서 인가되게 된다. 예컨대, 증명서 데이터 세트는, 장치(132, 134, 136, 130) 및/또는 이러한 장치와 관련된 특정 지불 계좌 중 하나 이상과 고유하게 연관된 임의의 데이터를 포함할 수 있다. 이러한 증명/식별 데이터는 예컨대, 이름, '비밀' 개인 정보, 일련 번호, 랜덤 혹은 의사 랜덤 코드, 계좌 번호 등을 포함할 수 있다.
증명 데이터 세트의 사본이 장치(132, 134, 136, 130)에 제공될 수 있고, 장치(132, 134, 136, 130)와 관련된 추가 식별자, 장치(132, 134, 136, 130)와 관련된 하나 이상의 판매자 혹은 다른 개체, 및/또는 이러한 개체와 관련된 하나 이상의 계좌에 따라서, 신뢰된 플랫폼(120)과 관련된 보안 메모리에 저장될 수 있다. 당업계에 종사하는 사람이라면, 스프레드시트, 관련 데이터베이스, 룩업 테이블 및 다른 도표와 같은 데이터 처리 장치가 이러한 목적으로 사용될 수 있다는 것을 이해할 것이다.
이러한 증명서 혹은 토큰은 장치(110)에서 수신 및 저장되면, 예컨대 하나 이상의 판매자 시스템(130)과 같은 제3자와의 구매 혹은 다른 금융 거래와 같은 데이터 처리의 인가 및/또는 입증에 사용하기 위해서 구성된 데이터 세트를 신뢰된 플랫폼(120)가 전송 및 해석하기 위해 장치(110)를 '신뢰된' 것으로 신속하고 보안적으로 식별하기 위해서, 장치(110), 판매자 장치(132, 134, 136, 130) 및 신뢰된 플랫폼(120)에 의해 사용될 수 있다. 예컨대, 지불 토큰 데이터 세트는 신뢰된 장치(110', 130')로부터 신뢰된 플랫폼(110)에 의해 수신될 수 있으며, 토큰은지불 및 다른 거래를 처리하는데 사용하도록 관련된 사용자 및/또는 계좌 정보와 함께 데이터베이스(125)에서 검색될 수 있는 증명 데이터 세트를 포함한다.
이러한 측면 및 실시예에서, 본 발명은 신뢰된 장치(110')를 사용해서, 판매자/제공자(130) 혹은 일부 다른 개체가 제공하며, 적절하게 구성된 하이퍼텍스트 링크, 터치스트린의 전송, 키보드/키패드 및/또는 다른 사용자 생성 입력, 신호 송신기 및 수신기 등을 사용해서 신뢰된 장치(110')의 사용자 디스플레이 화면 혹은 다른 I/O 컴포넌트(610)(예컨대, 도 6 참조)에 제공되는 다목적 웹 브라우저 등을 포함하는 판매자, 게임 혹은 다른 애플리케이션('앱')과 같은, 직접 인터넷 접속을 통한 하나 이상의 인앱 지불 혹은 다른 데이터 처리 거래를 협상 및 완수한다.
따라서, 예컨대, 다양한 측면 및 실시예에서, 본 발명은 시스템, 프로세스, 그리고 머신-실행 가능 명령어를 나타내는 영구 저장된 머신 액세스 가능 및 머신 판독 가능 프로그래밍 구조를 제공하며, 이들은 신뢰된 플랫폼(120)이 하나 이상의 신뢰된 요청 혹은 사용자 장치(110') 및 하나 이상의 신뢰된 판매자 시스템(130')을 등록하는 것을 가능하게 하며, 이로써 신뢰된 장치(110') 및 판매자 시스템(130') 사이에서 지불 자금의 소스로부터 사용되는 계좌, 판매자 식별 등과 같은 민감한 계좌 정보를 통신할 필요없이, (a) 요청 장치(110') 및 (b) 판매자 시스템(130')과의 직접 통신을 통한 구매 및/또는 다른 거래를 처리하는 것을 가능하게 한다. 이러한 실시예에서, 거래와 관련된 지불은 거래가 조건부호 혹은 최종적으로 닫히는 방식으로 신뢰된 플랫폼에 의해 처리될 수 있다. 예컨대, 거래 시스템(120)과 신뢰된 요청 장치(110') 모두가 신뢰된 플랫폼(120)에 의해 관리되는 계좌와 관련되어 있다면, 거래는 즉시 최종적으로 닫혀질 수 있다. 신뢰된 장치(110', 130')가 모두 이러한 계좌와 관련되어 있지 않다면, 서로에 대한 이러한 거래의 하루치 혹은 다른 누계를 오프셋해서 제4자 플랫폼(160)과의 밸런스를 맞춤으로써, 혹은 하나 이상의 제4자 플랫폼(160)과의 간단한 작업에 의해서 하루 혹은 다른 회계 기간의 종료시에 지불을 밸런싱함으로써, 신뢰된 플랫폼(120)은 거래의 최종 확인 및 정리를 완수하기 위해서 오프라인으로 작업할 수 있다.
또 다른 예로서, 다양한 측면 및 실시예에서, 본 개시에 따른 시스템, 프로세스, 그리고 머신 액세스 가능 및 머신 판독 가능 프로그래밍 구조는, 하나 이상의 신뢰된 요청 혹은 사용자 장치(110') 및 판매자 장치(132, 134, 136, 130)가, 거래를 협상하고 판매자의 디지털 증명서를 나타내는 데이터를 포함하는 거래 실행 데이터 세트, 그리고 옵션으로서 예컨대, 판매자와 관련된 디지털 증명서 혹은 다른 식별자, 거래 배상을 위해서 적용되는 하나 이상의 계좌 및/또는 거래와 관련된 판매 혹은 다른 양을 포함하는 거래를 나타내는 추가 데이터를 작성하는 것을 가능하게 한다. 이러한 거래 데이터 세트는, '종래 기술의 탈선' 라우팅을 사용해서 직접 혹은 하나 이상의 은행, 신용 카드 프로세서 등과 같은 하나 이상의 제4자 거래 프로세서(50)를 통한 종래 지불 시스템을 거쳐서, 신뢰된 플랫폼(120)으로 라우팅될 수 있다.
거래 데이터 세트가 거래를 정산 혹은 판결하도록 인가된 신뢰된 플랫폼(120)으로 라우팅되는 실시예에서, 신뢰된 플랫폼은, 거래를 완수하기에 적합한 지불을 판매자 시스템(130)으로 다시 라우팅하고, 구매자에 의해 제어되는 계좌가 아닌 신뢰된 플랫폼 자체(예컨대, 은행의 자체 계좌)와 직접 관련된 자금을 이용하며, 신뢰된 플랫폼(120)과 신뢰된 장치(110')와 관련된 애플리케이션에 의해 하루 혹은 다른 거래 기한 종료와 같은 이후 시간에 지정되는 계좌 사이의 최종 정산을 남김으로써, 판매자 시스템(130, 130')과 정산할 수 있다. 당업자라면, 신뢰된 플랫폼(120)과 신뢰된 장치(110')와 관련된 계좌 사이의 계좌를 정산하기 위한 이후 거래는, 적절한 암호화 혹은 다른 보안 수단에 따른 신뢰된 플랫폼 자체의 네트워크 사이의 내부 통신에 적합한 거래 데이터 세트를 이용해서 정산될 수 있으며, 이는 공공 네트워크를 이용하기에 적합한 보안 수단과 상이하며, 빠르고 및/또는 효율적일 수 있다.
나아가, 이러한 거래는 신뢰된 장치(110'), 신뢰된 판매자 시스템(130') 및 신뢰된 플랫폼(120) 사이의 직접 라우팅을 통해서 혹은 VISA, MasterCard 등과 같은 임의의 소망의 지불 프로토콜에 따른 공공의 혹은 기존의 혹은 신뢰도가 낮은 지불 네트워크를 통해서 완료될 수 있다. 특정한 예로서, 종래의(신뢰도가 낮은) 지불 네트워크를 통해서 라우팅된 지불 거래는 인터렉 지불의 형태로 되어서 Interac™ 프로토콜에 따라서 처리될 수 있다.
거래가 판매자 시스템(130, 130')과 신뢰된 플랫폼(120) 사이에서 먼저 정산되고, 신뢰된 플랫폼(120)과 인가된 신뢰된 장치(110')와 관련된 애플리케이션에 의해 지정된 계좌 사이에서 이후에 정산되는 예에서, 신뢰된 장치(110')와 관련된 사용자는 거래를 정상하는데 어느 계좌가 사용될지 최종 지정하는 절대 기간, 한정된 기간 혹은 상대적인 기간을 제공받을 수 있다. 예컨대, 이러한 사용자에게는 지불 계좌를 최종 지정하는데, 하루 중 특정 시점, 하루의 종료 혹은 거래 보고 기간 혹은 한달의 종료 등까지 1시간 혹은 2시간이 제공될 수 있다. 사용자에게 사용될 계좌를 변경 혹은 확정할 시간을 제공함으로써, 사용자가 요금이 지정된 계좌를 클리어할지, 거래에 대한 상금(award) 혹은 로열티 포인트를 신청할지 여부를 판정할지, 혹은 사용될 계좌의 수 및 각각으로부터 인출될 금액을 판정할지를 확인할 시간을 제공할 수 있다. 이러한 기능을 통해서, 상당한 신뢰성, 편의성 및 다른 이점을 사용자 및 신뢰된 플랫폼에 제공할 수 있다.
본 발명에 따른 신뢰된 플랫폼, 신뢰된 장치 및 다른 시스템, 장치 및 프로세스가 제공하는 많은 이점 중에서, 개발 중인 기술에 적합하도록 제공하는 능력이 있다. 예컨대 하나 이상의 mPOS를 포함하는 하나 이상의 신뢰된 장치는 블록체인과 같은 다양한 형태의 공공 장부(public ledger)에 참여하거나 혹은 이와 관련될 수 있다. 예컨대, 일부 실시예에서, 하나 이상의 mPOS 혹은 다른 신뢰된 장치(110')는 블록체인 장부 시스템 내에 노드로서 성립될 수 있다. 이러한 구현예에서, 임의의 신뢰된 mPOS(134)를 포함한 각각의 신뢰된 장치(110')는 적용 가능한 블록체인/공공 장부 프로토콜에 부합하게 거래 데이터 세트를 판매자 시스템(130)으로부터 FSP 시스템(160, 120)으로 보안되게 라우팅할 수 있다.
관련 기술 분야에 종사하는 당업자라면, 블록체인은 거래의 가상 공공 장부로서 동작하는 분배되고 일반적으로 암호화되거나 보안되는 데이터 스토어로, 비트코인과 같은 암호 화폐를 구현하는데 특히 유용하다는 것을 이해할 것이다. 이러한 장부 방식에서, 복수의 장치가 노드로서 구현되며, 각각의 노드는 장부의 개별적인, 완전한 혹은 일부의 저장된 카피를 제어하거나 혹은 액세스하고, 장부는 거래에 대한 합법적인 혹은 다른 인정된 입찰을 나타내는 데이터 세트를 포함한다. 거래가 진행됨에 따라서, 각각의 포함된 네트워크 노드는 거래 혹은 그 일부를 검증하고, 적절한 장부 주석을 나타내는 데이터를 생성하며, 노드의 일부 혹은 장부의 카피에 주석을 입력하고, 다른 노드에 업데이트된 장부 주석을 푸시해서 이용가능하게 한다.
지불 처리
도 9를 참조하며, 본 발명에 따른 모바일 혹은 다른 지불을 처리하기 위한 예시적인 시스템(100, 900)이 도시되어 있다. 시스템(900)은 다양한 상이한 실시예에서, 적어도 도 6 내지 8에 도시된 사용자 장치(110, 600), 신뢰된 플랫폼이나 인증 기관 혹은 다른 거래 처리 시스템(120, 905), 판매자 백엔드(136, 910) 및 지불 게이트웨이(915)를 포함할 수 있다. 본 명세서에 개시된 바와 같이, 시스템(900)은 신뢰된 혹은 신뢰되지 않은 장치(110, 110', 600)가 하나 이상의 신뢰된 혹은 신뢰되지 않은 판매자 시스템(130, 130')과 상품 및/또는 서비스와 관련해서 CNP 거래를 개시하는데 사용될 수 있는 네트워크화된 환경을 제공할 수 있다. 이러한 CNP 거래는 판매자 POS 단말(도 7의 NFC 판독기(132, 134, 700)와 같은)에 의해 개시되는 비접촉 거래 대신에 혹은 이에 더해서 장치(110, 110', 600)의 사용자가 이용할 수 있다.
이하의 처리 설명 각각에서는 모바일 장치(110, 110', 600)를 종종 혹은 주로 참고하지만, 다른 실시예에서는, 환경과 명백하게 불일치되지 않는 한, 본 명세서에 개시된 모든 거래 및 다른 프로세서에서 비모바일 장치(110, 110', 600)가 사용될 수도 있다는 것을 이해할 것이다.
따라서, 일부 실시예에서, 하나 이상의 가상 월렛 애플리케이션(112, 622)이 모바일 혹은 다른 장치(110, 110', 600)에 인스톨되어서, 적어도 하나의 지불 크리덴셜을 나타내는 데이터를 제공받을 수 있다. 본 명세서에서 설명되는 바와 같이, 이러한 지불 크리덴셜은 은행, 신용 카드 회사 및 다른 FI 혹은 FSP를 포함한 다양한 개체에 의해 발행될 수 있으며, 일회용 및 복수회용 토큰과 같은 다양한 종류의 HCE 토큰을 포함할 수 있다. 가상 월렛 애플리케이션(112, 622)은 사용자의 선호도나 다른 요인에 따라서 단 하나의 인가된 지불 방법에 대한 HCE 토큰 혹은 다수의 인가된 지불 방법에 대한 HCE 토큰을 제공받을 수 있다. 경우에 따라서, HCE 토큰은 사용자 장치(110, 110', 600)의 다른 메모리나 저장 컴포넌트에 제공될 수도 있다. 대신에 경우에 따라서, 지불 토큰은 장치(110, 110', 600)가 액세스 가능한 보안 클라우드에 저장될 수도 있다.
나아가, 하나 이상의 판매자 애플리케이션(114, 630) 혹은 다른 게임, 다목적 네트워크 브라우저 등(115)이 모바일 혹은 다른 장치(110, 600)에 인스톨될 수 있다. 이러한 판매자 애플리케이션(114, 630)의 타입 및 기능은 다양하지만, 일반적으로 적어도 모바일 장치(110, 600)를, 판매자 애플리케이션(114, 630)을 통해서 판매를 위해 제공되는 일부 상품 및/또는 서비스의 구매를 위한 거래를 개시하는데 사용하는 기능을 포함할 수 있다. 도 9에는 장치(110, 600)에 하나의 판매자 애플리케이션(114, 630)만이 도시되어 있지만, 양 및 타입은 일반적으로 한정되는 것은 아니며, 다양한 실시예에서는 달라질 수 있다.
일부 실시예에서, 판매자 애플리케이션(114, 630)은 인증 기관(120, 905) 혹은 신뢰된 플랫폼에 등록되어서, 예컨대, 판매자 애플리케이션(114, 630)와 관련된 판매자 스스로가 인증 및/또는 인가되어서 월렛 애플리케이션(114, 630) 등에 저장된 사용자의 지불 크리덴셜로 CNP 거래를 완수하도록 할 수도 있다. 예컨대, 이러한 판매자는 이른 시점에 판매자 백엔트(136, 910)를 통해서 인증 기관(120, 905)와 통신해서, 장치(110, 110', 600) 상에서의 거래를 인증하기 위해서 인증 기관(120, 905)이 판매자 장치(132, 134, 136, 130, 130') 중 일부 혹은 전체를 통해서 이후 사용될 증명서를 판매자에게 발행할 것을 요청할 수 있다. 이러한 증명서는 예컨대, 인증 상태를 고유하게 식별하거나 혹은 나타내는 코드 혹은 토큰을 포함한, 본 명세서에 개시된 목적에 적합한 임의의 타입의 보안 데이터 세트에 의해 표현될 수도 있다. 이러한 판매자 증명서는 판매자 백엔드(136, 910) 혹은 판매자 애플리케이션(114, 630)이 액세스 가능한 일부 다른 네트워크화된 리소스에 저장될 수 있다.
인증 기관(120, 905)은 경우에 따라서, 판매자 시스템(130')이 인증받는 다수의 인증 개체 중 하나가 될 수 있으며, 각각의 인증 기관(120, 905)는 특히 하나 이상의 다양한 판매자 애플리케이션(114, 630) 혹은 이들의 변형 및/또는 그룹과 연관된다. 다른 방안으로, 일부 경우에 인증 기관(120, 905)은 시스템(100, 900) 내의 모든 판매자 애플리케이션(114, 630)에 공통인 하나의 중앙 등록 혹은 인증 기관이 될 수 있으며, 이로써 여러 이점 중에서, 판매자 애플리케이션(114, 630)에 발행된 증명서는 공통 혹은 표준 포맷이나 프로토콜을 따를 수 있게 되어서, 다양한 산업, 플랫폼 등에서의 전자 지불의 실행 및 처리를 용이하게 할 수 있다. 예컨대, 모든 판매자 애플리케이션(114, 630)에 공통인 인증 기관(120, 905)은, 협업해서 혹은 관련해서 기능하며 모바일 및/또는 다른 거래를 처리하는 표준 프랙티스 및 포맷에 동의한 하나 이상의 은행과 같은 FI 혹은 FSP에 의해서 성립되거나 동작될 수 있다. 그러나, 중앙 인증 기관(120, 905)은 또한 독립된 제3자 개체에 의해서 성립되어서 동작할 수도 있다.
경우에 따라서 사용자 장치(110, 600) 및/또는 장치(110, 600) 상의 월렛 애플리케이션(112, 622)은 동일한 혹은 다른 인증 기관(120, 905)에 등록될 수도 있다. 따라서, 월렛 애플리케이션(112, 622) 및/또는 장치(110, 600)는 신뢰된 장치(110')가 될 수 있다. 예컨대, 월렛 애플리케이션(112, 622)은 판매자 애플리케이션(114, 630)와 다른 모바일 장치(110, 600)에 특정한 증명서 혹은 다른 암호화 크리덴셜을 요청하기 위해서 인증 기관(120, 905)와 통신하도록 구성될 수 있다. 사용자가 이후에 판매자 애플리케이션(114, 630) 내에서 모바일 혹은 전자 상거래를 개시할 때, 이러한 장치 특정 증명서는 임의의 다른 증명서 혹은 암호화 처리에 더해서 거래의 소스를 인증하는데 사용될 수 있다. 사용자 중 일부 혹은 전부 및/또는 월렛 애플리케이션(112, 622)은 물론 판매자 시스템 혹은 애플리케이션(114, 630)을 하나의 중앙 인증 기관(120, 905)에 등록함으로써 거래 처리의 보안성 및 효율성에서 여러가지 이점을 제공할 수 있고, 이러한 배치는 특히 인증 기관(120, 905), 판매자 시스템(136, 910), 발행자((20) 및 인수자(925) 사이에서 요구되는 다수의 네트워크 통신을 감소시킬 수 있고, 따라서, 통신 리스트 및 지연을 감소 혹은 제거할 수 있다.
거래를 개시하기 위해서, 사용자는 장치(110, 600)에서 판매자 애플리케이션(114, 630)을 실행해서 구매할 아이템(상품 혹은 서비스)를 선택할 수 있다. 예컨대, 판매자 애플리케이션(114, 630)에 액세스할 때, 사용자는 임의의 적절하게 구성된 키보드, 키패드, 포인터, 터치 스크린 장치 및/또는 다른 입출력 장치(610)를 적절하게 구성된 사용자 인터페이스 디스플레이 스트린과 함께 사용해서 이러한 상품 및 서비스를 지정할 수 있다. 결제 시퀀스의 일부로서, 판매자 애플리케이션(114, 630)은, 인증 기관(120, 905)이 판매자에게 발행한 증명서를 제공하기 위한 요청을 (mPOS 혹은 POS 장치(132, 134)와 같은 임의의 다른 적절한 컴포넌트를 통해서 직접) 판매자 백엔드(136, 910)에 전송할 수 있다. 이 요청이 만족된 이후에, 판매자 애플리케이션(114, 630)은 수신한 판매자의 증명서를 사용해서, HCE 토큰과 같은 지불 크리덴셜에 대한 액세스 허가를 월렛 애플리케이션(114, 630)에 질의할 수 있다. 경우에 따라서, 판매자 애플리케이션(114, 630)은 판매자 백엔드(136, 910)으로부터 판매자의 증명서의 수신을 자동으로 후속할지를 가상 월렛 애플리케이션(112, 622)에 질의할 수 있다. 다른 방안으로, 판매자 애플리케이션(114, 630)은 사용자에게 프롬프트를 표시해서, 인가를 표현하는 요청을 월렛 애플리케이션(112, 622)에 질의한다.
다른 방안으로서, 사용자는 판매자 애플리케이션(114, 630) 이외의 임의의 다른 애플리케이션 혹은 프로그램(115) 내에서 거래를 개시할 수 있고, 이는 구매할 아이템(상품 혹은 서비스)를 선택함으로써 장치(110, 110')에 인스톨된다. 결제 시퀀스의 일부로서, 예컨대 사용자는 적절하게 구성된 I/O 장치(610)를 적절하게 구성된 사용자 인터페이스 I/O 디스플레이 스크린과 함께 사용해서, 지불을 위한 월렛 애플리케이션(114, 630)을 선택할 수 있다. 이러한 선택은 월렛 애플리케이션(114, 630)을 사용하지 않는 것을 포함한 다수의 다양한 지불 옵션의 표현에 대한 응답이 될 수 있다.
월렛 애플리케이션(112, 622)은 판매자 애플리케이션(114, 630) 혹은 일부 다른 애플리케이션이나 프로그램(114, 115)으로부터의 질의를 수신하면, 질의에 포함된 판매자의 증명서의 소스를 확인하거나 이를 인증하도록 구성될 수 있다. 예컨대, 월렛 애플리케이션(112, 622)은 판매자의 증명서가 유효한지 확인하는데 사용될 수 있는 개인 키 및/또는 다른 암호화 데이터를 제공받을 수 있다. 월렛 애플리케이션(112, 622)이 판매자의 증명서를 확인할 수 없다면, 판매자 애플리케이션(114, 630)으로부터 송신되는 질의는 거부될 수 있으며, 옵션으로서, 월렛 애플리케이션(112, 622)은 장치(110, 110', 600)의 사용자와 판매자(136, 136', 910) 중 하나를 대상으로 하는 요청을 생성해서 인가를 재시도하거나 인가의 거부를 무효화시킨다. 월렛 애플리케이션이 증명서를 확인할 수 이는 경우에, 월렛 애플리케이션(112, 622)은 판매자 애플리케이션(114, 630)이 저장된 지불 크리덴셜에 액세스하는 것을 인가받았는지를 표시 혹은 시그널링함으로써 응답할 수 있다.
월렛 애플리케이션(112, 622)의 질의에 성공하면, 판매자 애플리케이션(114, 630)은 월렛 애플리케이션(112, 622)으로부터, 월렛 애플리케이션(112, 622)에 저장된 지불 크리덴셜 및 다른 데이터에 대한 액세스 및 제어를 판매자 애플리케이션(114, 630)에 효율적으로 제공하는 월렛 인터페이스 인가를 풀링할 수 있다. 따라서, 판매자 애플리케이션(114, 630)은 월렛 애플리케이션(112, 622)에서와 같은 방식으로 사용자의 지불 크리덴셜을 다루거나 처리하는 것이 가능하다.
예컨대, 제공된 HCE 토큰 혹은 다른 지불 크리덴셜의 수 및/또는 타입에 따라서, 판매자 애플리케이션(114, 630)은 개시된 거래에 사용할 하나의지불 크리덴셜을 자동으로 선택할 수도 있고, 혹은 대신에 지불 방법의 선택을 위해서 판매자 애플리케이션(114, 630)으로부터 사용자에게 프롬프트할 수도 있다. 자동 선택은, 예컨대 한가지 지불 타입에 대한 HCE 토큰이 제공되었거나, 혹은 다수의 다양한 지불 방법에 대한 HCE 토큰이 제공되었지만 사용자가 이용 가능한 지불 방법 중 하나를 디폴트로서 사용하도록 월렛 애플리케이션(112, 622)에서 명시한 경우에, 발생될 수 있다. 한편, 디폴트가 명시되어 있지 않다면, 판매자 애플리케이션(114, 630)은 장치(110, 110', 600)의 I/O 컴포넌트를 사용해서 상술한 바와 같이 지불 방법의 선택을 사용자에게 프롬프트할 수 있다.
프롬프트 선택을 통하던 자동 선택을 통하던, 판매자 애플리케이션(114, 630)은 월렛 애플리케이션(112, 622)으로부터 거래에 사용될 지불 방법을 나타내는 지불 크리덴셜을 풀링할 수 있다. 판매자 애플리케이션(114, 630)은 HCE 토큰 혹은 다른 지불 크리덴셜을 나타내는 신호를, 거래를 완수하는데 필요한 혹은 사용될 다른 정보(날짜, 판매자 신원, 양 등)와 함께 판매자 백엔드(136, 136', 910)에 송신할 수 있다. 경우에 따라서, 판매자 백엔드(136, 136', 910)에 송신되는 지불 정보는 암호화되어서, 판매자조차도 사용자의 민감한 정보를 볼 수 없게 할 수도 있다. 여러 실시예에서, 지불 정보의 암호화는 판매자 애플리케이션(114, 630)에 의해 혹은 장치(110, 110', 600)의 몇가지 다른 애플리케이션이나 프로그램에 의해 수행될 수 있다. 판매자 백엔드(136, 136', 910)는 모바일 장치(110, 110', 600)로부터 수신한 HCE 토큰 혹은 지불 크리덴셜을 다른 거래 정보와 함께 지불 게이트웨이(150, 915)로 포워딩해서 처리되게 한다.
일부 실시예에서, 지불 토큰이 장치(110, 110', 600)에 저장되어 있지 않고 보안 클라우드에 저장되어 있더라도, 거래는 장치(110, 110', 600)로부터 개시될 수 있다. 예컨대, 사용자는 다목적 웹 브라우저와 같은 애플리케이션 혹은 프로그램을 네비게이트해서, 지불 혹은 결제 시퀀스를 개시하도록 결정할 수 있다. 이 경우, 사용자는 사용자의 은행 혹은 신뢰된 플랫폼(120, 160, 905)에 대한 보안 로그인을 제시받고, 패스워드 혹은 생체와 같은 인증 정보의 입력을 프롬프트받을 수 있다. 사용자가 성공적으로 인증할 수 있다면, 은행 혹은 신뢰된 플랫폼(120, 160, 905)은 지불 토큰을 판매자 백엔드(136, 136', 910)에 전송해서 거래 처리에 사용되게 한다.
일부 실시예에서, 판매자 증명서가 모바일 혹은 다른 월렛 애플리케이션(112, 622)에 지불 토큰을 취득하도록 요구하는데 사용되는 것 이외에, 이러한 판매자 증명서가 월렛 애플리케이션(112, 622)이나 일부 다른 메모리로부터 취득한, 혹은 장치(110, 110', 600)가 액세스 가능하거나 혹은 보안 클라우드로부터 액세스 가능한 지불 토큰을 디지털 서명하는데만 사용될 수도 있다. 따라서, 이 경우, 사용자는 판매자 애플리케이션(114, 630)이나 혹은 웹 브라우저와 같은 애플리케이션이나 프로그램(115) 내에서 조작할 수 있으며, 전자 거래를 개시할 수 있다. 이 경우, 현재 사용자가 액세스하고 있는 애플리케이션 혹은 프로그램은 지불 메시지의 일부로서 판매자 백엔드(136, 136', 910)에 전달할 지불 토큰에 직접 액세스할 수 있다. 일부 경우에, 본 명세서에 설명된 바와 같이, 지불 토큰은, 사용자 혹은 사용자의 모바일 장치(110, 600)의 신원 확인을 거친 후, 은행 혹은 신뢰된 플랫폼(120, 905)으로부터 판매자 백엔드(136, 136', 910)로 직접 제공될 수도 있다.
지불 게이트웨이(150, 915)는 일반적으로, e-비지니스, 온라인 소매점 혹은 다른 종래의 소매점 대신에 신용 카드 및 다른 거래를 인가, 판결 혹은 다른 처리를 행하는 임의의 FSP 혹은 애플리케이션 서비스 제공자가 되거나 혹은 이를 포함할 수 있다. 따라서, 지불 게이트웨이(150, 915)는 해당 판매자 혹은 판매자 그룹 대신 판매자 애플리케이션(114, 630)로부터 개시된 모바일 거래를 포함한 모든 모바일 및/또는 다른 거래를 처리하는 일부 개체가 될 수 있다. 따라서, 각각의 판매자 혹은 판매자 애플리케이션(114, 630)는 하나 이상의 다양한 지불 게이트웨이(150, 915)와 관련될 수 있지만, 각각이 편의상 하나만 도시되어 있다. 모바일 혹은 다른 거래의 처리를 용이하게 하기 위해서, 지불 게이트웨이(150, 915)는 민감한 정보의 암호화, 부정 적발 등과 같은 서비스를 수행할 수 있다.
도 9에 도시된 바와 같이, 시스템(100, 900)은 일부 실시예에서, 지불 게이트웨이(150, 915)가 거래를 위해서 선택되는 지불 방법에 따라서 및 일부 경우에 신뢰된 플랫폼(120, 905)이 거래를 인가했는지 여부에 따라서, 비모바일 사용자 통신 장치(110)를 사용해서 수행되는 거래와는 다르게 모바일 거래를 처리할 수 있도록 구성될 수 있다. 예컨대, 지불 게이트웨이(150, 915)는 수신한 HCE 토큰 또는 지불 크리덴셜에 기초해서 선택된 지불 방법을 검출하고, 이에 따라서 거래를 하나 이상의 추가 다운스트림 개체로 라우팅하도록 구성될 수 있다. HCE 토큰 혹은 다른 지불 크리덴셜을 확실히 식별할 수 있도록, 일부 경우에, 지불 게이트웨이(150, 915) 및/또는 이러한 HCE 토큰 혹은 다른 지불의 구성은 함께 착수될 수도 있고 혹은 거래를 인증할 인가를 대리한 중앙 인증 기관(120, 905)와 함께 착수될 수도 있다. 따라서 이러한 방식에서, 지불 게이트웨이(150, 915)는 사용자 혹은 판매자 시스템(130)이 거래를 개시했는지에 무관하게 광범위한 다양한 토큰을 검출하는 것이 가능하다.
예컨대, 일부 경우에, 지불 게이트웨이(150, 915)는 수신한 HCE 토큰이 Interac™ (인출) 거래를 표현하거나 나타내는 것을 검추하도록 구성될 수 있으며, 이 경우 지불 게이트웨이(150, 915)는 거래를, 사용자가 유지하는 요구 혹은 예금 계좌를 제어하는 은행과 같은, 선택된 지불 방법과 관련된 발행자(160, 920)에 직접 라우팅할 수 있다. 이러한 발행자(160, 920)는 토큰에 명시된 계좌로부터 정확한 금액을 인출함으로써 거래를 정산할 수 있다. 이러한 거래는 사실상 Interac™ 거래가 될 수도 있고, 이하 설명하는 바와 같이 인수자 은행과 같은 일부 다른 중간 혹은 제4자 프로세서와 달리, 발행 은행에 의해 직접 처리되도록, Interac™ 거래같이 보이도록 인코딩된 다른 타입의 거래가 될 수도 있다.
지불 게이트웨이(150, 915)는 수신한 HCE 토큰이 신용 카드 거래임을 나타내는지 검출할 수도 있고, 이 경우, 지불 게이트웨이(150, 915)는 거래가 어떻게 정산될지 판정하기 위해서 질의할 수 있다. 일부 발행자(160, 920)는 거래가 정산을 위해서 지불 게이트웨이(150, 915)로부터 직접 라우팅되는 것에 동의할 수 있다. 다른 방안으로, 신용 카드 지불을 나타내는 일부 모바일 혹은 다른 거래는 우선 지불 게이트웨이(150, 915)로부터 인수자(150, 925) 혹은 인수자의 프로세서로 라우팅되고, 이후에 정산을 위해서 발행자(920)로 라우팅될 수도 있다.
따라서, 일부 실시예에서 판매자 백엔드(136, 136', 910)로 전송되는 지불 토큰은 인증 기관(120, 905)이나 혹은 일부 다른 신뢰된 플랫폼에 의해 발행되어서 판매자에게 제공된 판매자의 증명서를 사용해서 서명될 수도 있다. 지불 메시지가 지불 게이트웨이(150, 915)를 통해서 포워딩되면, 일부 경우에 Interac™로서 검출될 것이며, 그 이유는 장치(110, 110', 600) 혹은 판매자 백엔드(136, 136', 910)에 의해서 이러한 모양을 취하도록 구성되었기 때문이다. 따라서, 지불 게이트웨이(150, 915)의 판정이 되었던, 지불 메시지가 인수자(150, 925) 혹은 그 프로세서로 포워딩되는 대신에 발행자(160, 920)로 직접 릴레이될 수도 있다. 판매자에 대한 지불이 처리되기 전에 지불 메시지는 이후에 검증 및/또는 해독된다. 발행자 은행(160, 920)은 일부 경우에 메시지에 표시된 지불 방법으로부터 직접 지불하도록 배열될 수도 있다. 그러나, 옵션으로서, 일부 경우에, 발행자 은행(160, 920)은 은행의 자금으로부터 판매자에게 지불하고, 이후에 본 명세서에 설명된 방법에 의해서 모바일 장치(110, 110', 600)의 사용자와 정산할 수도 있다.
일부 실시예에서, 판매자 백엔드(136, 136', 910)로 전송되는 지불 토큰이 판매자의 증명서를 사용해서 '서명'되거나 혹은 인증되면, 지불 게이트웨이(150, 915)는 모두 우회되고, 대신에 판매자 백엔드(136, 136', 910)는 발행자(160, 920)와 직접 통신해서 거래를 처리한다. 이러한 경우에, 발행자(160, 920)는 지불 메시지에 명시된 지불 타입 및/또는 자금을 사용해서 판매자와 정산할 수 있다. 다른 방안으로, 본 명세서에 개시된 바와 같이, 발행자(160, 920)는 일부 경우에 발행자가 제공하는 자금을 사용해서 판매자(136, 136')와 우선 정산하고, 이후에 동의된 정산 방법에 따라서 사용자와 정산할 수도 있다.
도 10을 참조하며, 본 발명의 실시예에 따라서 지불을 처리하는 예시적인 시스템(100, 1000)이 도시되어 있다. 도 9에 도시된 시스템(900)과 유사하게, 시스템(1000)은 다양한 상이한 실시예에서 본 명세서에 개시된 바와 같은, 적어도 모바일 혹은 다른 장치(110, 110', 600), 인증 기관(120, 905) 및 판매자 백엔드(136, 136', 910)를 포함할 수 있다. 따라서, 도시의 편의를 위해서 이들 구성 요소의 설명은 특히 강조될 수 있는 특정한 차이점을 제외하면 다소 감소될 수도 있다.
시스템(900)에서 지불 크리덴셜이 다양한 지불 방법(직불, 신용) 및/또는 방식에 걸쳐서 표준화될 수 있지만, 시스템(1000)은 지불 토큰이 표준화되지 않은 모바일 및 다른 거래를 처리하도록 구성될 수 있다. 따라서, 예컨대, 모바일 거래는 특정 지불 방법의 선택을 위해서 예컨대, 월렛 애플리케이션(112, 622)으로부터 월렛 인터페이스를 인출하는 판매자 애플리케이션(114, 630) 혹은 모바일 장치(110, 110', 600) 상의 웹 브라우저 혹은 다른 애플리케이션 내에서 거래를 개시하는 사용자에 의해서 개시될 수도 있다. 그러나, 판매자 애플리케이션(114, 630) 혹은 메모리 내의 어디에 저장된 토큰은, 중앙 인증 기관(120, 905)과 같은 단일 기관과는 반대되는 다수의 다양한 토큰 서비스 제공자(TSP)에 의해 제공받았을 수 있다.
따라서, 시스템(1000)은 또한 지불 게이트웨이(150, 915)와 발행자(160, 920) 사이에 위치된 하나 이상의 토큰 서비스 제공자(925, 160)를 포함할 수 있다. 거래가 판매자 백엔드(136, 136', 910)로부터 수신되었을 때, 지불 게이트웨이(150, 915)는 수신한 토큰을 어느 TSP(150, 925)가 발행했는지 판정하고 이에 따라서 거래를 라우팅할 수 있다. 예컨대, 각각의 TSP(150, 925)는 Interac™ (인출) 거래와 같은 다른 지불 방법은 물론 다양한 신용 카드 방식(Visa™, Mastercard™)에 따라서 동작할 수 있다. 이러한 TSP(150, 925)는 거래를 인증하고 발행자 시스템(160, 920)에 라우팅할 수 있다.
도 11을 참조하며, 본 발명에 따라서 모바일 및 다른 지불을 처리하는 예시적인 시스템(100, 1100)이 도시되어 있다. 도 9에 도시된 시스템(900)과 유사하게, 시스템(1100)은 다양한 상이한 실시예에서 본 명세서에 개시된 바와 같은, 적어도 모바일 혹은 다른 장치(110, 110', 600), 인증 기관(120, 905) 및 판매자 백엔드(136, 136', 910)를 포함할 수 있다. 따라서, 도시의 편의를 위해서 이들 구성 요소의 설명은 특히 강조될 수 있는 특정한 차이점을 제외하면 다소 감소될 수도 있다.
상술한 바와 같이, 신용 및 직불 거래에 더해서, 본 발명은 폭넓은 대안의 지불 방법의 토큰화를 가능하게 할 수 있다. 예컨대, 발행자(120, 160, 920)(은행 혹은 다른 금융 기관과 같은)는 여신 한도 혹은 다른 가치있는 자산을 소비자까지 확장할 수 있다. 정상적으로, 소비자는 이러한 자산으로 지불을 행하는 것이 불가능할 수 있다. 그러나, 본 발명에 따라서, 발행자(120, 160, 920)는 모바일 혹은 다른 장치(110, 110', 600)를 소비자의 여신 한도 혹은 다른 자산을 나타내는 토큰 혹은 하나 이상의 이와 관련된 값과 함께 제공할 수 있다. 이러한 토큰은 소망의 수 및/또는 다양한 형태로 제공되며, 모바일 지불에서 이후에 사용하기 위해서 하나 이상의 월렛 애플리케이션(112, 622)에 저장될 수 있다. 이러한 지불 토큰이 저장되는 모바일 장치(110, 600)는 일부 경우에 신뢰된 장치(110')이 될 수 있다.
따라서, 거래가 개시되면, 판매자 애플리케이션(114, 630)에 의해 풀링되는 토큰은 일부 경우에 여신 한도를 발행자(920)에게 나타낼 수 있다. 판매자 백엔드(136, 136', 910)로부터 거래가 수신되면, 지불 게이트웨이(915)는 신뢰된 모바일 장치(110, 600) 혹은 판매자 백엔드(136, 136', 910)가 이와 같이 검출된 지불 메시지를 인코딩한 결과로, 수신한 토큰이 여신 한도 혹은 다른 자산을 나타내는지 검출하고, 거래를 토큰과 관련된 발행자(920)에 직접 라우팅할 수 있다. 발행자(920)는 소비자가 이용 가능한 신용으로부터 적절한 양을 공제함으로써 거래를 정산할 수 있다.
따라서, 본 개시에 의해 가능해진 여러 개선점 중에서, 하나 이상의 디스플레이 스크린, 하나 이상의 사용자 입력 장치 및 하나 이상의 단거리 및/또는 장거리 네트워크 통신 시스템; 하나 이상의 데이터 프로세서; 및 하나 이상의 메모리 장치를 각각 포함하는 모바일 및 다른 장치가 있으며, 메모리 장치는 (a) 하나 이상의 보안 지불 토큰을 적어도 나타내는 영구 저장된 데이터를 포함하고, 각각의 지불 토큰은 인가된 지불 금액 및 인가된 지불 금액을 인가받은 금융 서비스 제공자와 관련된 데이터를 포함한다. 메모리 장치는 또한 머신 해석 가능한 혹은 실행 가능한 명령어의 하나 이상의 세트를 나타내는 영구 저장된 데이터를 포함하는 메모리를 포함하고, 데이터 프로세서는, 저장된 머신 해석 가능 명령어의 하나 이상의 세트를 실행할 때, 디스플레이 스크린에 표시된 지불 옵션에 대한 사용자 선택을 나타내는 데이터를 적어도 하나의 사용자 입력 장치로부터 수신하고, 이에 응답해서, 영구 메모리 장치에 액세스해서 선택된 지불 토클을 애플리케이션으로 풀링하고, 개시된 거래를 처리할 때 사용하기 위해서 네트워크 통신 시스템을 사용해서 선택된 지불 토큰을 애플리케이션으로부터 거래 처리 시스템으로 라우팅하도록 구성될 수 있다.
본 발명은 또한 이러한 장치를 제공하며, 여기서 지불 옵션이 예컨대, 판매자 거래 처리 시스템에 의해 제공되는 애플리케이션을 포함한 애플리케이션으로부터 표시되고, 애플리케이션은 모바일 통신 장치와 판매자 처리 시스템 사이의 통신을 용이하게 하기에 적합하다.
본 발명은 또한 대응하는 프로세서; 영구 저장된 머신 실행 가능 명령어 세트; 및 이러한 장치를 사용하기에 적합한 시스템(100, 900, 1000)을 제공한다.
도 12를 참조하면, 상술한 바와 같이 장치(110, 110')의 가상 월렛(112)에 저장된 HCE 토큰 및 다른 지불 혹은 거래 크리덴셜이 장치가 액세스 가능하게 인스톨된, 하나 이상의 판매자와 관련되어 있거나 혹은 이에 의해 제공되는 애플리케이션(114)을 포함하는, 다른 애플리케이션(114, 115)에 의해 다양한 방식으로 액세스될 수 있다. 예컨대, 판매자 애플리케이션(114)은 인가될 수도 있고 혹은 풀 아키텍쳐의 구현을 통해서 신뢰된 장치(110')의 월렛 애플리케이션(112)으로부터의 정보에 액세스하는 것이 가능하고, 이는 신뢰된 장치(110')에 월렛 애플리케이션 및 판매자 애플리케이션 모두에 공통이며 이에 의해 액세스가능한 시스템 레벨 애플리케이션 프로그래밍 인터페이스(API)(116)를 제공함으로써 실행될 수 있다. 이러한 API는 예컨대, 도 12에 도시된 바와 같이 별도의 지불 옵션 애플리케이션 API(116)("당신의 은행 SDK로 지불")의 형태로 제공될 수도 있고, 다른 방안으로 API(116) 자체는 장치(110)의 검증된, 인가된 사용자(190)가 이용 가능한 지불 리소스에 대해 애플리케이션(112, 114) 및 서버(120, 160) 등을 폴링하고, 이를 출력 장치(610)에서 적절하게 구성된 GUI에 제시함으로써 공통의 혹은 범용 월렛(112)의 역할을 할 수 있다. 이러한 특성은 중요한 이점을 특히 사용자(190), 판매자(130) 및 FI/FSP(120, 160)에게 제공할 수 있다. 예컨대, 모바일 월렛(112)에 이미 저장된 토큰 및/또는 다른 지불 크리덴셜은 이러한 구현예에서 판매자 애플리케이션(114, 630)에 의해 풀링될 수 있기 때문에, 사용자가 임의의 신용 카드 혹은 기밀 식별자와 같은 다른 민감한 정보를 판매자 애플리케이션에 직접 입력할 필요성이 완화될 수 있다. 이러한 일 실시예의 구현 및 사용의 예를 도 13의 프로세스(1300)과 함께 이하에 제공한다. 다른 이점 중에서, 별도의 보안 지불 옵션 API(116)를 사용하면 장치(110, 110')의 사용자에게 상당히 개선되고 매우 유연한 제어를 지불 옵션 및 선호도의 폭넓은 조합으로 제공할 수 있다는 점에 주의한다.
예컨대, 상술한 바와 같이, 인스톨된 애플리케이션(112, 114)을 포함한 장치(110); FI/FSP(120, 160); 판매자 장치 및 시스템(132, 134, 36, 136') 및 옵션으로 다른 리소스 중 일부 혹은 전체를 폴링하는 것 및 지불 크리덴셜을 풀링하는 것은 이러한 장치를 예컨대 공통 통신 및 데이터 기록 생성 및 프로세싱 프로토콜을 포함한 공통 표준에 따라서 지불 토큰, HCE 크리덴셜 및 다른 거래 관련 정보를 나타내는 데이터를 생성, 저장 및 처리하도록 구성함으로써 수행될 수 있다. 일반적으로, 정확한 프로토콜의 형태는 크게 중요하지 않고, 중요한 것은 지불 및/또는 예금 계좌 번호(혹은 다른 식별자), 인가된 및/또는 요청된 거래 값 및 계좌 보유자와 관련된 식별자와 같은 관련 데이터, 인가된 계좌 사용자, 계좌 관리자 및 지불자 및 지불 받는 사람이 임의의 적절하게 동의된 형태로 거래 데이터 기록 내에 내장될 수 있다는 점이다.
적절하게 조정된 토큰 및/또는 크리덴셜 형태를 사용해서, 지불 옵션 혹은 범용 월렛 API(112, 116)은 각각의 다른 판매자 시스템 및/또는 장치(130, 132, 134, 136, 136') 및/또는 FI/FSP 시스템(120, 160) 중 일부 혹은 전체에게 말하도록(talk) 구성될 수 있다.
이러한 지불 옵션 혹은 범용 월렛 API(116)을 구현할 때, 도 1~5, 9~12 및 15a~15b와 함께 설명되는 것을 포함한 아키텍쳐는 매우 바람직할 수 있다. 예컨대, 본 명세서에서 설명되는 실시예 중 어느 것과 본 명세서에 설명되는 입증/등록 처리를 사용하는 것은, 공통 혹은 범용 프로토콜의 채택의 수용, 보안 및 효율을 크게 용이하게 할 수 있다.
도 13을 참조하며, 본 발명의 다양한 측면 및 실시예에 따라서 모바일 지불 혹은 다른 거래를 처리하는 방법(1300)이 도시되어 있다. 방법(1300)은 시스템(100;도 1~도 5, 도 12, 900;도 9, 1000;도 10 및/또는 1100;도 11) 중 일부 혹은 전체에 이해 혹은 이와 관련해서 수행될 수 있고, 일반적으로, 요청 통신 장치(110, 110')의 사용자가 장치(110)에 인스톨된 판매자와 관련된 애플리케이션 혹은 프로그램으로부터 지불 거래를 개시해서 완료하는 것을 가능하게 한다. 도 13에 도시된 실시예에서, 방법(1300)이 개개의 이벤트 혹은 액션의 시퀀스로서 도시되어 있지만, 당업자라면 이러한 표현은 명료성 및 편의성만을 위한 것으로, 대안의 실시예가 가능할 수도 있다는 것을 이해할 것이다. 예컨대 다양한 실시예에서, 도시된 액션의 순서는 변경될 수도 있고, 다른 액션을 포함할 수도 있으며, 도시된 특정 액션을 생략할 수도 있고, 및/또는 하나 이상의 액션을 함께 결합하는 것이 가능할 수 있다. 도시된 특정 실시예는 가능성의 예시일 뿐이다.
따라서, 일부 경우에, 방법(300)은 모바일, 데스크톱 혹은 다른 사용자 장치(110, 110')에 하나 이상의 HCE 토큰 혹은 장치(110, 110')의 사용자에 대한 다양한 인가된 지불 옵션 중 하나 이상을 나타내는 다른 지불 크리덴셜을 제공하는 단계(1305)부터 시작될 수 있다. HCE 토큰 혹은 지불 크리덴셜은, 하나 이상의 특정 지불 방법 혹은 방식과 연관될 수 있는 토큰 서비스 제공자(160, 920)를 포함한 다양한 개체(120, 160)에 의해서 제공될 수 있지만, 일부 경우에는 다양한 상이한 지불 및/또는 방식에 표준 토큰을 제공하는 중앙 인증 기관(120, 905)에 의해서 제공될 수도 있다. 일부 다른 경우에, 지불 토큰은 사용자 장치 자체 대신 모바일 혹은 데스크톱 장치(110, 110')가 액세스가능한 보안 클라우드에 제공될 수도 있다.
제공된 HCE 토큰 혹은 다른 지불 크리덴셜을 포함한 모바일 및/또는 다른 거래가 인증될 수 있도록, 판매자 및 판매자 애플리케이션 중 적어도 하나가 예컨대, 중앙 인증 기관 혹은 신뢰된 플랫폼(120, 905)에 의해서 인증될 수 있다(1310). 예컨대, 판매자 및/또는 하나 이상의 관련 판매자 시스템(130, 910)은 판매자 애플리케이션 혹은 프로그램(114, 630)을 모바일 혹은 다른 타입의 지불이 인가될 수 있는 것으로서 인증 기관(120, 905)에 등록함으로써 인증될 수 있다(1310). 인증 기관 혹은 신뢰된 장치(120, 905)는 처리 중 일부로서 관련된 판매자 시스템(130', 910)에 판매자의 애플리케이션을 통해서 모바일 지불을 처리하는데 사용할 사용자의 증명서를 임의의 적절한 식별자 및/또는 보안 코드 등을 포함한 판매자 입증 데이터의 형태로 제공할 수 있다.
옵션으로, 일부 경우에, 사용자는 모바일 혹은 다른 장치(110)를 인증 기관 혹은 신뢰된 플랫폼(120, 905)으로 인증할 수도 있다(1310). 예컨대, 인증 기관(120, 905)은 일련 번호, 네트워크 어드레스 혹은 랜덤 혹은 임의의 식별자와 같은 사용자 장치(110, 110')와 관련된 일부 고유 식별 정보를 등록할 수 있다. 이후, 이러한 등록된 장치(110')에 제공된 HCE 토큰 혹은 지불 크리덴셜을 포함한 모든 모바일 거래는 또한 이러한 거래가 등록된 식별 정보와 매칭되거나 혹은 적절하게 관련된 장치(110')에서 기원한 것이라는 확인으로서 처리될 수도 있다.
지불 혹은 다른 거래를 개시하기 위해서, 사용자는 판매자 애플리케이션 혹은 프로그램(114, 630)을 런칭할 수 있다. 예컨대, 모바일 장치(110, 110')의 사용자는 사용자가 구매하고자 하는 하나 이상의 상품 혹은 서비스를 가진 판매자 POS(132, 134)에 어프로치해서, 판매자가 스캐닝하도록 아이템을 제시하며, 이에 따라서 자동으로 혹은 반자동으로 모바일 장치에 있는 판매자 애플리케이션(114, 630)을 개시시킬 수도 있고, 혹은 데스크톱 장치(110, 110')의 사용자는 다목적 네트워크 브라우저를 사용해서 판매자 웹 사이트로 네비게이트하며, 공지된 기술을 사용해서 가상 쇼핑 카드에 배치할 하나 이상의 아이템 혹은 서비스를 선택하며, 준비되었을 때 '결제' 절차 혹은 다른 지불 프로세스를 개시할 수 있다. 프로그래밍된 지불 혹은 결제 시퀀스의 일부로서, 판매자 애플리케이션(114, 630)은 관련된 백엔드 시스템(136, 910) 내의 네트워크화된 위치로부터의 판매자의 증명서의 제공을 요청할 수 있다. 일단 수신되면, 판매자 애플리케이션은 수신한 증명서를 사용해서 사용자의 모바일 혹은 데스크톱 장치(110, 110')에 인스톨된 월렛 애플리케이션(112, 622)에 질의할 수 있다. 질의받으면, 월렛 애플리케이션은 개인키 혹은 다른 암호화 정보를 사용해서 판매자 증명서의 진위를 확인하고, 확인 결과에 따라서 응답할 수 있다. 다른 방안으로, 판매자 애플리케이션 혹은 프로그램(114, 630)은 사용자 지불 옵션 애플리케이션(116)에 질의할 수도 있고, 혹은 판매자 시스템(630)에 증명서 정보를 제공하기 위해서 월렛 애플리케이션(112, 622)으로부터 직접 토큰을 요청할 수도 있다.
본 명세서에 개시된 바와 같이 시스템 및 애플리케이션을 사용해서 사용자의 디폴트 선택을 식별하는 것을 포함하는, 장치(110, 110')를 사용해서 판매자 애플리케이션(114, 630) 및/또는 판매자 시스템(130)에 액세스함으로서 구현하도록 제공된 방법 혹은 프로세서가 매우 폭넓은 다양한 적절한 프로그래밍 장치, 메커니즘 혹은 어프로치 중 어느 하나를 포함할 수 있다는 것을 당업자라면 바로 이해할 것이다. 예컨대, 장치(110, 110')의 사용자는 자신이 데스크톱에서 행하던 것과 유사한 방식으로 자신의 모바일 장치의 적절하게 구성된 웹 브라우저를 사용해서 판매자 시스템(130, 132)에 네비게이트할 수 있으며, 쿠키 및 다른 자동 혹은 반자동 장치가 설명되는 방식으로 디폴트 옵션 및 선택의 지정에 사용될 수 있다는 것을 이해할 것이다. 다른 특정 예로서, 모바일 장치(110, 110')에 구현되는 브라우저는, 판매자 시스템(130, 132, 136) 등에 혹은 이와 함께 사용하기 위해서 월렛으로부터 식별자 및/또는 지불 데이터 및 크리덴셜을 풀링하도록, 예컨대, 플러그 인 애플리케이션 혹은 다른 적절하게 구성된 코드의 사용을 통해서, 판매자 API(114, 630)를 통해 모바일 월렛(112, 622)과 통신하도록 구성될 수 있다. 이렇게 구현하는 것은, 예컨대, 모든 판매자가 모바일 장치에서 사용하기 위해서 상표 등록된 혹은 다른 앱(114)을 제공하도록 선택되지 않아도 되고, 다목적 브라우저, 쿠기 등을 사용함으로써 본 발명의 이러한 측면의 효율적인 구현의 중요한 기회를 제공할 수 있다는 점에서, 특정한 이점이 될 수 있다.
이러한 애플리케이션 및 시스템에 액세스하는 모든 장치, 메커니즘, 어프로치, 프로시저 및 방법은 본 발명의 대응하는 측면의 범주에 들어가는 것으로 상정된다.
판매자의 증명서 데이터의 입증 상태에 따라서, 사용자의 월렛(112, 622) 및 지불 옵션 API(116)은 판매자 애플리케이션이 월렛 애플리케이션(112, 622)으로부터 판매자 애플리케이션(114, 630)으로 월렛 인터페이스를 풀링하는 것을 가능하게 한다. 도 14a의 예에 도시된 바와 같이, 월렛 애플리케이션(112, 622)은 이러한 입증시에(혹은 거래 처리 시의 임의의 다른 적절한 포인트에서) 완전히 혹은 부분적으로 사용자 장치(110, 110')가 그래픽 유저 인터페이스를 생성해서 표시하게 하는 프로그램 명령어의 세트 혹은 사용자가 개시된 거래를 처리하는데 사용할 저장된 지불 토큰 중 하나 및/또는 복수의 지불 옵션 중 하나를 선택하게 하는 것을 가능하게 하는 사용자의 저장된 지불 크리덴셜의 다른 시각적인 디스플레이(1402)를 포함할 수 있다.
예컨대, 장치(110')의 사용자가 POS(132, 134)에서의 혹은 인터렉티브 GUI 장치의 데스크톱 시스템(110)의 웹 브라우저 내에서 장치 스크린(610)에 표시되는 '결제' 혹은 '지불 준비'를 선택함으로써, 장치(110')는, 장치(110')의 사용자가 이용가능한 지불 옵션을 나타내는 아이템(1404, 1406)을 포함하는 GUI를 생성해서 디스플레이한다. 도 14a에 도시된 예에서, 예컨대, 사용자는, 판매자-제어 '결제' 옵션(1404) 및 월렛 혹은 신뢰된 플랫폼 제어 프로세스 '당신의 은행으로 지불' 옵션(1406)의, 2개의 지불 옵션의 선택을 제공하는 GUI(1402)를 제시받는다.
도 14a의 인터렉티브 GUI '결제' 요소(1404)를 사용자가 선택하면, 장치(110')는 판매자 애플리케이션(114, 630)에 의해 제어되는 프로세스를 개시해서 사용자가 판매자 백엔드 시스템(136, 910)에 의해 인가 혹은 제어되는 지불 프로세스를 사용해서 거래 인가 요청 데이터 세트를 생성함으로써 거래를 완수하는 것을 가능하게 할 수 있다. 이러한 프로세스는 예컨대, 도 1의 예에 도시된 바와 같이, 제4자 지불 프로세서(150)의 사용을 통해서 완전히 혹은 부분적으로 가능하게 될 수 있다. 이러한 프로세스는 예컨대, 공지된 및 널리 영리화된 전자 결제 프로시저에 따라서 진행될 수 있다. 이러한 프로세스를 사용해서 생성된 거래 인가 요청 데이터 세트는, 거래가 완수되기 위해서는, 전체 구매량, 지불 리소스로서 사용될 계좌와 관련된 식별자 및/또는 지불을 수신하도록 지정된 판매자 혹은 다른 계좌를 포함하는, 그 승인이 필요한 하나 이상의 FI/FSP(120, 160)이 요청 혹은 요구하는 임의의 정보를 본 명세서에 전반적으로 설명되는 임의의 라우팅, 확인 및/또는 보안 데이터 혹은 장치와 함께 포함할 수 있다.
예컨대, 사용자가 GUI 요소 '당신의 은행으로 지불'을 선택하면 장치 월렛(112, 630) 및/또는 지불 옵션 API(116)는 월렛(114, 630), API(116) 및/또는 TP(120, 905) 중 어느 하나 혹은 모두에 의해서 제어되는 지불 프로세스를 계속하거나 개시한다. 예컨대, 터치스크린 장치(610)를 사용해서 아이템(1406)을 선택하면, 월렛(112, 622)에서 제공되는 데이터 및/또는 명령어에 따라서 지불을 완수하기 위한 리소스로서 사용자(190)가 이용 가능한 하나 이상의 옵션(1486)을 나타내는 GUI(1407)을 (예컨대, 지불 옵션 API(116)에 의해 제공되는 데이터를 사용해서) 생성하고 표시하고, 이는 도 14b 및 도 14e에 예로서 도시된 바와 같이 지불 옵션 API(116)에 의해 풀링된다. 도 14b에 도시된 예에서, 모바일 장치(110')의 사용자(190)는 1471에서 대응하는 요청된 거래 데이터 세트의 일부를, 아이템에 관한 가격과 함께, 구매될 적어도 하나의 아이템(Bosch 30" smooth top range)을 나타내는 정보를 포함하는 리스트의 형태로 나타내는 GUI(1407)를 제공받았다. 사용자는 신뢰된 FI(120, 160)에 의해 관리되는 신용 계좌 "RBC VISA AVION"로서 식별된 거래 지불 소스의 형태로, 제 1 지불 옵션을 나타내는 아이콘(1408)을 제공받았다.
도 14c 및 14d에 도시된 바와 같이, 도 14b에 제공되는 GUI(1407)는, 도 14a에 도시된 GUI(1402)에 의해 관리되는 판매자의 디폴트 결제 프로세스를 포함한 판매자 시스템(130)에 의해 실행되는 결제 세션 혹은 프로세스를 종료시키거나 중단시키는 일없이, 디스플레이가 새로운 GUI(1407)를 생성해서 이전 스크린을 완전히 덮게 함으로써 혹은 예컨대, '페이드' 혹은 '그레이아웃' 이미징 기법을 사용해서 사용자(190)가 지불 옵션(116) 및/또는 월렛(114)과 인터렉트하게 함으로써, 인터렉티브 '오버레이' 스크린(1409)의 형태로 제공될 수 있다. 이로써 예컨대, 사용자는 월렛(114), 옵션 애플리케이션(116) 및/또는 관련 FI(120, 160)를 통해서 이용가능한 추가 지불 옵션을 보기 위해서 GUI(1407)를 스크롤하는 것 및 및 옵션으로서 계좌 혹은 자금원의 조합을 사용해서 지불을 제어하는 것이 가능하게 된다.
예컨대, 범용 월렛 혹은 지불 옵션 API(116)은 모든 월렛(112), 지불 토큰 및/또는 장치에 저장된 다른 지불 크리덴셜의 세트의 전체 혹은 일부 리스트에 대해서 장치(110, 110')를 폴링할 수 있고, 사용자가 시청하고 선택하기 위해서 GUI를 통해서 제시할 수 있다. 이러한 리스트는 전체적으로 혹은 부분적으로 디폴트로 파퓰레이트될 수 있고, 사용자, 판매자, 혹은 장치(110, 110')와 관련된 FSP에 의해 장치와 관련된 임의의 지불 토큰 및/또는 거래 크리덴셜로 설정된다. 예컨대, 사용자에 의한 시청 및 선택을 위해서 브랜드 로고를 포함한 정보를 나타내는 전체 정보 혹은 일부 정보와 함께, 모든 카드, 계좌 혹은 거래에 대한 애플리케이션의 장치가 액세스 가능한 가치 소스의 리스트가 표시될 수 있다. 예컨대, 카드 혹은 계좌 상세의 리스트는 카드 번호, 계좌 보유자 명 및/또는 생략 주소 전체, 일부 혹은 대부분과 함께 제시될 수 있고, 그 결과 사용자(190)는 민감한 정보를 공개적으로 개시하지 않고 소망의 지불 소스를 선택할 수 있다.
본 발명의 이러한 측면 및 실시예에 의해 제공되는 다양한 바람직한 특징 중에서, 사용자가 다수의 지불 계좌 및/또는 다른 값 소스 중 하나 이상을 사용해서 거래에 대한 지불을 가능하게 하고, 옵셥으로서 이러한 조합 중 어느 부분을 이를 행할 때 사용할지 제어하게 하는 사용자 제어 가능 메커니즘이 있다. 예컨대, 도 14c에 도시된 바와 같이, 사용자(190)는 터치스크린, 포인팅 장치 및/또는 다른 I/O 컴포넌트(610)를 사용해서 스크롤해서 GUI(1407) 중 총 구매 금액 $40.25이 요금이라는 것을 나타내는 부분을 보고, 사용자는 "Avion Loyalty Balance" 아이템(1420)을 사용해서 로열티 포인트 혹은 달러를 사용해서 소망의 구매 금액을 지불하고, 나머지는 "RBC VISA AVION" 계좌와 같은 다른 계좌를 사용해서 지불되는 것을 가능하게 한다. 도시된 예에서, 사용자는 로열티 계좌를 사용해서 지불되는 총액 $40.25을 증가시키거나 혹은 감소시킴으로써 사용자가 총 거래 요금의 일부를 지정하는데 사용할 수 있는 터치스크린-가능 슬라이더(1422)의 형태로 인터렉티브 그래픽 장치(1420)를 제시받는다. 도시된 예에서, 사용자는 슬라이더(1422)를 조정해서, 아이템 '지불'이 선택되는 경우에, 총액 $40.25이 Avion Loyalty Balance로부터 $18 가치의 포인트를 사용해서 지불되게 하고, 잔고($22.25)는 RBC VISA AVION 신용 계좌 혹은 다른 지정된 자금원에 대해 적용된다.
본 발명은 결합된 지불-소스 거래에서의 다양한 변경을 가능하게 할 수 있다. 예컨대, 판매자 혹은 다른 애플리케이션(114, 115)에 의해 제어되는 인앱 프로세스는, 예컨대, 사용자가 요청되는 거래에 적용하기에 얼마나 많은 로열티 포인트를 이용가능한지 혹은 얼마나 많은 달러, 파운드, 프랑 혹은 다른 타입의 통화를 사용자가 거래에 이용 가능한지와 같은 현금, 리워드 혹은 사용자가 거래에 이용 가능한 다른 값에 관한 정보를 나타내는 인터페이스 스크린(1407)을 사용자(190)에게 제공할 수 있다. 사용자(190)는 예컨대, 시각적인 슬라이더(1422) 혹은 다른 인터페이스(1420)를 사용해서 제안된 거래에 상환 혹은 적용될 이용 가능한 포인트(혹은 다른 통화, 지불 계좌 등)의 수를 지정할 수 있다. 옵션으로서, 사용자가 애플리케이션(114, 115)을 통해서 거래를 완료하면, 사용되는 포인트에 대한 임의의 디스카운트를 적용하지 않고, 애플리케이션은 전체 거래량에 대한 다른 지정된 사용자 계좌를 충전할 수 있다. 앱(114, 115)은 선택된 포인트의 수를 상환할 거래와 관련된 지정된 월렛(112)을 통지하고, 상환된 포인트의 수의 달러양에 대해서 사용자가 선택한 지불 카드로 신용을 적용한다.
나아가, 사용자(190)가 사용하기 위해서 인가된 모든 월렛, 계좌, 토큰 및/또는 HCE 크리덴셜 데이터에 대해서 장치(110, 110') 및/또는 하나 이상의 FI/FSP(160)를 폴링함으로써, 본 발명에 따른 판매자 애플리케이션(114, 630)은 사용자가 거래에, 및 예컨대, 간단하지 않지만, 특정 판매자와 관련된 로열티 프로그램 혹은 판매자가 선호하는 지불 형태로 사용하는데 이용 가능한 임의의 예금, 신용, 통화 혹은 포인트 계좌를 사용자가 선택하는 것을 가능하게 한다.
POS 거래는 또한, 특히 로열티 혹은 리워드 포인트를 사용해서 전체 혹은 일부 지불이 요구되는 경우에, 다수의 사용자 계정에서의 인출을 가능하게 하는 것을 포함한 본 발명에 의해 가능한 지불 프로세스의 적용을 통해서 개선될 수 있다. 이러한 형식으로 지불하고자 하는 장치(110, 110')의 사용자(190)는 자금 계좌 및 로열티 혹은 리워드 계좌 모두와 관련된 FI/FSP(120, 160)와 관련된 월렛 애플리케이션을 로딩하고, 거래의 상환에 포이트를 이용 가능하고 받을 수 있는 경우에 지불에 사용될 HCE 부합 자금 계좌 및 자동으로 표시되는 포인트 슬라이더(1422) 혹은 유사한 장치를 선택한다. 장치(1420)를 사용해서, 사용자는 얼마나 많은 포인트를 상환할지 및/또는 포인트 상환을 통해서 지불 중 어느 부분이 배상될지, 그리고 사용자가 언제 POS 단말에서 장치를 탭해서 거래를 지불하거나 혹은 거래의 완료를 인가할지 선택할 수 있고, 월렛(112)은 거래 가격의 일부 혹은 전체를 지불하는데 판매자 시스템이 포인트가 지불에 사용된다는 것을 통지받지도 부담을 갖지도 않는 방식으로, 드러날 포인트의 수를 나타내는 '감추어진' 데이터 아이템을 포함하는 거래 지불 데이터 세트를 거래 지불 데이터 세트를 판매자 시스템(136, 136')으로 라우팅할 수 있고, 옵션으로서 얼마나 많은 포인트를 상환할지와 관련해서 사용자(190)에게만 제시되는 데이터 필드의 추가 정보에 대한 액세스를 제공한다. 이러한 기능은 예컨대, 일부 실시예에서 EMV 표준을 포함한 표준 지불 프로토콜의 일부로서 포함될 수 있다. 거래 데이터 세트가 정상 코스에서 현금 및 포인트 지불 계좌와 관련된 FI로 라우팅될 때, 히든 필드가 분석될 수 있다. 포인트를 상환하는 명령어를 포함하는 경우에, 판매자 시스템(136, 136')이 현금 기반 이외의 어느 것에 대한 지불 처리를 요구할 필요없이, FI는 내부 회계 원리에 따라서 포인트를 적용할 수 있다. 장치(110, 110')의 통시 시스템을 사용해서 FI(120, 160)는 사용자(190)에 대한 거래를 직접 확인할 수 있다.
도 14d에 도시된 바와 같이, 인터페이스 스크린(1407)에 따라서 스크롤링함으로써, 1432에서 나타난 로열티 계좌에 관한 추가 정보를 나타내는 GUI 장치(1430)가 표시될 수 있으며, 이 경우 일부 남은 포인트의 수가 거래에 적용하기 위해서 사용자에 의해 상환될 수 있기 이전에 요구되는 추가 추매의 수를 나타내는 것이다. 당업자라면, 다수의 FI 플랫폼(120, 160)에서 지불 옵션 API(116)를 사용하면, 인증 기관(120, 905) 혹은 다른 신뢰된 플랫폼은, 거래를 완료하기 위해서 사용하는데 이용 가능한, 다수의 리워드 프로그램, 신용, 예금 및 다른 지불 계좌와 관련된 계좌 잔고 등을 추적할 수 있고, 결합되고 조직된 디스플레이(1407)에서 이러한 정보를 사용자(190)에 제공할 수 있다는 것을 이해할 것이다.
본 발명이 제공하는 추가적인 바람직한 특성은, 어느 계좌가 거래를 완수하는데 사용될지 지정하는데, 이러한 계좌가 공통 개체에 의해 유지 혹은 관리되는지 여부에 무관하게, 사용자(190)가 임의의 수의 계좌 및/또는 계좌의 타입에서 선택하는 것을 가능하게 하는 능력이다. 예컨대, API(116) 혹은 월렛(112)이 적용됨으로써, 사용자는 GUI(1407)와 같은 수단에 의해서 사용자가 제어하지만 다양한 FI(160)에 의해 보유 혹은 제어되는 계좌 중에서 선택하는 것이 가능하다. 예컨대, 도 12 및 14e에 도시된 바와 같이, 지불 옵션 아이템(1406)(도 14a)의 선택은, 지불 옵션 애플리케이션(116) 혹은 제 1 월렛(112)이 인가된 사용자(190)가 이용 가능한 복수의 지불 옵션을 나타내는데 유용한 정보에 대해서 하나 이상의 (제 2) 월렛(112) 및/또는 인증 기관(120)을 폴링하게 하고, 적절하게 구성된 디스플레이(610)로 하여금 GUI(1484)의 하나 이상의 대응하는 선택 가능한 GUI 아이콘(1486)을 포함하는 GUI(1407)을 제시하게 한다. 아이템(1486')의 선택은 예컨대, 도 14c에 도시된 옵션 "RBC VISA AVION"을, 도 14f의 1489에 도시된 리베이트 계좌 "TD REBATE REWARDS"와 관련된 지불 옵션으로 대체할 수 있다. 당업자라면, 본 명세서에 개시된 발명에 의해 제공되는 이점은, 본 개시와 유사하게 만들어지면, 그래픽 아이템(1486) 등이 대응하는 계좌와 관련된 고유의 브랜딩 이미지 혹은 다른 식별자를 나타내는 썸네일 혹은 다른 이미지의 형태로 제공될 수 있다는 것이다.
지불 옵션 API(116) 및/또는 월렛(112)을 통해서 사용자(190)가 다수의 계좌 혹은 자금원 중에서 거래를 완료할 것을 선택하는 다양한 실시예에서, 사용자(190)는 지불 옵션 아이템(1406)의 선택시에 제시되는 하나 이상의 디폴트 혹은 디폴트 조합을 선택할 수 있다. 예컨대, 도 14a 및 14b에 도시되고 이와 관련해서 설명된 바와 같이, 사용자(190) 및/또는 인가된 FI(120, 160) 중 적어도 하나에 의해서 디폴트가 이전에 지정었을 때 이러한 아이템(1406)을 선택하면, 선호되는 예금, 신용, 로열티, 기프트 및/또는 리워드 계좌와 같은, 하나 이상의 치환 가능한 지불 옵션이 표시될 수 있다. 이러한 실시예에서, 상기 표시한 디폴트 선호는, 텍스트, 컬러, 세이딩 혹은 다른 그래픽 장치 등을 포함한 관련 식별자의 스크린 사용에 있어서의 상대적인 배치에 의해서, 예컨대, 도 14e에 도시된 바와 같이 아이템(1477)을 사용해서 지정될 수 있다. 도 14e에 도시된 실시예에서, 도 14a의 지불 옵션 아이콘(1406)을 선택하면, 도 14a에 도시된 바와 같이 "RBC VISA AVION" 대신에 "TD REBATE REWARDS VISA" 계좌로 지불하는 옵션을 표시할 수 있다.
디폴트 계좌 선택의 지정을 가능하게 하는 본 발명의 실시예에서, 하나 이상의 소망의 혹은 다른 적절한 메커니즘을 사용해서 디폴트가 식별될 수 있다. 예컨대, 장치(110, 110')의 사용자는 판매자 쇼핑 애플리케이션(114) 및 공통 HCE 지불 옵션(SDK/API(116)) 중 적어도 하나, (범용 월렛 애플리케이션이라고도 하는) API(112, 116)를 설정할 때 혹은 그 이후에 하나 이상의 디폴트를 지정할 수 있고, 및/또는 관련 FI(120, 160)는 다양한 디폴트 세팅을 제공하거나 요구할 수 있다. 다른 방안으로, 디폴트는, 예컨대, 거래 동안에 생성되거나 혹은 완료된 거래와 관련해서 제공되는 쿠기를 사용해서 거래 동안에, 사용자 액션 및/또는 사용자 액션의 경향에 기초해서 자동으로 혹은 반자동으로 지정될 수도 있다.
이러한 혹은 다른 실시예의 추가 변형예에서, 본 발명은 토큰 및 다른 지불 크리덴셜을 사용하는 새롭고 바람직한 방식을 제공하며, 이는 예컨대, 예컨대 디폴트 지불 소스를 지정하는 것 및 거래를 처리하는데 사용될 것을 선택하는 것을 포함한 다양한 목적으로, 하나 이상의 특정 사용자 혹은 장치에 의해 지정될 수 있고 및/또는 이와 관련될 수 있다. 예컨대, 특정 사용자를 식별하거나 혹은 인증하는 것에 의해서 이전에 입력된 혹은 이와 관련되고 유용한 데이터를 사용해서, 거래의 처리 동안에 장치(110')의 사용자(190)에 제시될 하나 이상의 디폴트 옵션을 지정하기 위해서, 판매자 앱(114)은 동일한 혹은 다른 식별자를 월렛 앱(112)에 제공할 수 있다. 예컨대, 거래시에, 판매자 앱(114)은 인가된 사용자(190)와 관련된 전화 번호 혹은 다른 정보를 나타내는 데이터를 인가된 사용자에 의해 사용되는 장치(110')와 관련된 판매자 앱(114)에 제공할 수 있다. 예컨대, 판매자 POS(132) 혹은 판매자 시스템(130)은 사용자(190)에 의해 이전에 지정된 혹은 다른 이전에 제공한 데이터로부터 획득한 전화 번호를, 거래를 처리할 때 디폴트로서 사용될 계좌를 식별할 때 월렛(112)에 의해 사용하기 위해서, 월렛(112)으로 제공할 수 있다. 나아가, 다양한 실시예에서, 사용자는 거래를 완료하기 위해서 사용자 이름/패스워드, PIN 및/또는 다른 식별자의 제공을 요구받을 수 있다.
사용자(190)가 자신의 장치(110, 110')에 인스톨된 복수의 FI/FSP(120, 160)와 관련된 월렛 애플리케이션(112)을 갖고 있지만, 구매 거래를 위해서 월렛 애플리케이션(112) 중 하나에만 주로 의존하는 실시예에서의 특정한 이점을 가진 처리(1300, 1500)의 추가 변형예가 사용될 수 있다. POS 구매 및 다른 구매를 완수하는데 사용하기 위해서, 바람직한 월렛 애플리케이션(112)은 선택 가능한 GUI 아이템(1406) "당신의 은행으로 지불'을 생성해서 표시하도록 구성될 수 있고, 사용자는 이를 통해서 유사한 기능을 가진 임의의 다른 월렛(112)을 장치에 런칭할 수 있을 것이다. 예컨대, 사용자(190)는 소매점의 결제 라인에 있으면서 선호되는 월렛 애플리케이션(112)을 호출하는데, 이는 사용자가 처음에 사용하고자 하는 자금원과 관련되어 있지만, 이후 다른 FI/FSP(120, 160)에 유지되는 계좌를 나타내는 HCE 크리덴셜을 사용해서 지불하도록 결정했기 때문이다. 사용자는 선호하는 월렛 애플리케이션(112)에서 '버튼' 아이템(1406)을 탭하는 것만으로, 선호하는 월렛 애플리케이션(112)과 SDK/API(116) 중 적어도 하나가 중앙 인가 기관(120)에 등록된 모든 FI의 리스트를 포함하는 GUI(1407)를 생성해서 표시하게 할 수 있다. 사용자는 소망의 FI와 관련된 GUI 아이템(1486)을 선택할 수 있고, 대응하는 월렛 애플리케이션(112)이 장치(110, 110')에 인스톨되어 있다면, 대응하는 월렛 애플리케이션(112)이 런칭되고, 사용자는 그 FI와 관련된 개개의 계좌(예컨대, 신용, 예금 및 로열티 계좌 중 선택)를 선택하고, 장치(110, 110')를 NFC 가능 POS 장치(132, 134)로 탭해서 지불한다. 선택된 월렛 애플리케이션(112)과 관련해서 저장된 토큰 혹은 다른 적절한 크리덴셜 데이터 세트는 POS 단말로 직접 송신될 수도 있고, 혹은 SDK/API(116) "Paywithyourbank" 통신 표준을 통해서 원래의 선호한 월렛 애플리케이션(112)으로 다시 송신(풀링)될 수도 있으며, 제 1 FI 월렛(112)은 적절하게 구성된 거래 지불 데이터 세트를 POS 단말로 라우팅할 수 있다. 유사한 처리가 판매자 혹은 다른 애플리케이션(114, 115)으로부터 개시된 인앱 지불에도 적용될 수 있다.
상술한 바와 같이, 본 발명의 많은 측면 및 실시예는 데스크톱 혹은 다른 비모바일 혹은 반모바일 장치(110)는 물론 스마트폰, 스마트 주얼리 혹은 다른 웨어러블 장치, 태블릿 컴퓨터 혹은 다른 모바일 장치(110)에 구현될 수 있다. 이러한 구현예에서, 웹 브라우저는 판매자 시스템(130), 월렛(112) 및 지불 옵션 API(116) 등과 관련해서 도 16에 도시된 GUI(1407, 1402)를 생성해서 표시하기 위해서 사용될 수 있다. 이러한 GUI는 예컨대, 도 14a~14f와 관련해서 상기 설명한 기능 중 일부 혹은 전체를 제공하기에 적합할 수 있다.
다른 경우에, 판매자 증명서의 입증시에 월렛 애플리케이션(112)은 하나의 지불 크리덴셜만을 저장하고 있거나 혹은 디폴트 지불 방법이 설정되어 있는 경우에, 판매자 애플리케이션(114)은 이러한 지불 토큰을 월렛 애플리케이션으로부터 자동으로 풀링(1320)할 수 있다. 그러나, 일부 경우에, 판매자의 증명서는 지불 토큰을 취득 및/또는 획득하기 위한 인증 처리의 일부로서 모바일 월렛 애플리케이션에 질의하는데 사용되지 않을 수도 있고, 판매자 혹은 애플리케이션은 모바일 월 애플리케이션 혹은 토큰이 저장되어 있는 다른 위치애 직접 액세스할 수도 있다.
도 13을 참조하면, 사용자(190)가 모바일 혹은 다른 지불을 완수하는데 사용할 지정한 하나 이상의 지불 토큰 및/또는 지불 리소스 크리덴셜의 선택에 후속해서, 판매자 애플리케이션(114)은 예컨대, 지정된 토큰(혹은 토큰이 위치될 수 있는 IP 어드레스에 대한 참조) 및/또는 다른 지불 소스(예컨대, 지불 계좌 식별자)를 나타내는 데이터의 형태로 지불(보안) 토큰 참조)를, 지불의 수신을 위해서 지정된 판매자 계좌를 나타내는 데이터, 임의의 라우팅 혹은 특수 명령어 등과 함께 포함하는, 거래 인가 요청 데이터 세트를 생성할 수 있으며; 1325에서, 판매자 백엔드를 통해서 다른 거래 특수 정보와 함께 지불 게이트웨이로 거래 인가 요청 데이터 세트를 전송할 수도 있다. 지불 게이트웨이는 이 거래를 포함된 토큰에 의해 표시되는 지불 방법, 및 사용자의 장치 및/또는 판매자가 신뢰된 플랫폼에 의해 인증되었는지 여부와 같은 다양한 팩터에 따라서 상이하게 처리(1330)할 수 있다. 예컨대, 차변 거래가 직접 방행자에게 라우팅되어서, 사용자의 은행과 정산될 수 있다. 다른 방안으로, 일부 신용 카드 거래는 인수자에게 먼저 라우팅되고 이후에 발행자와 정산될 수도 있다(1335). 일부 경우에는, 예컨대 이러한 인가는 신뢰된 플랫폼에 의해 인가되어 있는 경우에는 대신에 신용 카드 거래는 발행자에게 직접 라우팅되어서 정산된다(1335). 이는 신용 카드 지불을 나타내는 지불 메시지가 Interac™ 거래와 같은 대안의 지불 형태를 나타내는 지불 메시지로서 나타나도록, 예컨대 신뢰된 장치(110') 혹은 판매자에 의해서 수행될 수 있고, 이는 인수자와 같은 중간 혹은 제4자 프로세서의 발행자 은행에 직접 라우팅된다. 신뢰된 판매자가 지불 네트워크를 모두 우회해서 지불을 발행자로 직접 라우팅하는 것을 포함한, 모바일 혹은 데스크톱 거래를 처리 및 정산하는 다른 옵션은 설명된 바와 같다.
지불 거래를 가능하게 하고 수행하는 지불 처리(1500)의 다른 예는 도 15a에 도시되어 있다. 처리(1300)와 유사하게, 처리(1500)는 구매자(190)가 지불 거래를 완료할 때 다양한 지불 옵션 중 하나 이상을 선택하는 것을 가능하게 한다.
처리(1500)는 본 명세서에 개시된 바와 같이, 판매자가 판매자 시스템(136)을 하나 이상의 FSP(160) 및/또는 신뢰된 플랫폼(120)에 등록 혹은 입증해서 신뢰된 판매자 시스템(136')을 생성하는 1502에서 시작된다. 판매자 시스템(136')의 등록은 입증 FSP(160)에 의해서 임의의 유용한 혹은 다른 적절한 식별자, 공공/개인 혹은 다른 기밀 등을 포함한 입증 데이터 세트가, 판매자 시스템(136')이 등록된 혹은 신뢰된 판매자로서 상태를 인증할 때 사용하기 위해서, 판매자 시스템(136)에 제공되는 것을 포함할 수 있다.
1504에서 판매자 시스템(136')을 등록(즉, 입증)하면, 판매자는 하나 이상의 적절하게 구성된 판매자 쇼핑 애플리케이션(114) 및/또는 공통 HCE 지불 옵션 SDK/API(116)을 생성 혹은 획득할 수 있고, 이는 장치(110, 110')의 사용자(190)가 판매자의 웹사이트 혹은 소매점을 쇼핑하고, 이로써 본 명세서에 개시된 거래 요청 인가 데이터 세트를 생성하는 것을 가능하게 하도록 구성된다. 판매자 시스템(136')은 또한 1506에서 판매자 쇼핑 애플리케이션(114) 및/또는 공통 HCE 기능 API(116)이 본 발명에 개시된 바와 같은 하나 이상의 사용자 요청 통신 장치(110, 110')에 제공되게 한다. 사용자가 판매자의 물건을 쇼핑하고 거래 인가 요청 데이터 세트를 생성하는 것을 가능하게 하는 것에 더해서, 애플리케이션(114) 및/또는 SDK/API(116)는 특히 제공되는 사용자 장치(110, 110')가 본 명세서에 개시된 환경 및 조건에서 인터렉티브 'paywithyourbank' 그래픽 장치(1406)를 생성해서 표시하는 것을 가능하게 할 수 있다. 판매자 애플리케이션(114)은 범용 월렛 SDK/API(116) 및 판매자의 POS, mPOS 및 웹사이트 시스템(132, 134, 136, 136')과 함께 동작해서 본 명세서에 개시된 바와 같이 사용자의 쇼핑 처리를 용이하게 하도록 구성된다.
많은 경우에, 처리(1502, 1504)는 은행 혹은 다른 FSP와 관련된 서버(120, 160)에 액세스하고 적절한 식별자 및 데이터를 입력함으로써 수동으로 혹은 반자동 방식으로 완수될 것이다. 이 경우, 판매자 시스템(136, 136')은 공공 및/또는 개인 보안 키를 제공받을 수 있고, 이는 SDK/API(116)를 생성해서 사용자 장치(110, 110')에 제공할 때 사용된다.
상술한 바와 같이, 1508에서, 등록된/입증된 판매자 시스템(136')은, 판매자 및 판매자와 관련된 FI 및/또는 FSP, 장치(110, 110')의 사용자(190) 및/또는 신뢰된 플랫폼(120)에 제공하기 위해서, 입증/등록 플랫폼(120)에 의해서 적절하게 채택된 입증/등록 식별자를 포함한 입증 데이터 세트를 제공받을 수 있다.
1510에서, 모바일 혹은 비모바일 요청 통신 장치(110, 110')의 사용자(190)는, 판매자 애플리케이션(114)를 사용해서 판매자 웹사이트 및/또는 소매점을 쇼핑할 수 있고, 제공되는 판매자 앱(114)을 사용해서 구매되거나 리스되는 등의 하나 이상의 아이템 및/또는 서비스를 나타내는 데이터를 포함한 거래 인가 요청 데이터 세트를 조립할 수 있다. 결제가 준비되면(즉 거래를 완료), 사용자(190)는 판매자 앱(114)에 적절한 입력을 행해서 결제 처리를 개시할 수 있고, 이로써 사용자는 자신의 장치(110, 110')에 의해서 도 14a에 도시된 바와 같은 결제 GUI(1402)를 제시받게 되는데, 이는 예컨대, 구매될 아이템의 리스트, 가격, 세금, 배송/배달 정보 등 및 하나 이상의 선택 가능한 혹은 다른 인터렉티브 아이템(1404, 1406)과 같은 거래 인가 요청 데이터 세트에 의해 표현되는 정보 중 일부 혹은 전체를 포함할 수 있다.
1512에서, 사용자(190)는 본 명세서에 개시된 바와 같은 '당신의 은행으로 지불' 아이템(1406)을 선택하고, 이로써 범용 월렛 API(116)에 의한 처리를 호출 및 개시하며, 이후 본 명세서에 개시된 바와 같이 지불 자금 혹은 값의 하나 이상의 자금원으로서의 디폴트 혹은 선택된 지정이 지불('지불 소스')에 대해서 적용되게 한다. 지정된 지불원과 관련된 FI/FSP(120, 160) 각각에 대해서, SDK/API(116)는 1516에서, 제안된 거래와 관련된 정보, 예컨대, 구매 가격 혹은 그 중 지정된 지불 소스로부터 배상되는 부분, 그리고 옵션으로는 구매 가격의 소계, 적용되는 세금, 배송비 및 아이템 식별자 등(예컨대, 생성된 거래 요청 데이터 세트에 포함되는 데이터 중 일부 혹은 전체)가, 거래 인가 데이터 세트의 일부로서 대응하는 FI 혹은 FSP(120, 160)에 포워딩되게 한다. 다른 방안으로서, 신뢰된 요청 통신 장치(110')로부터 발생된 거래 인가 요청과 관련해서, 거래 인가 요청 데이터 세트를 생성할 때 사용되는 데이터 아이템 중 일부 혹은 전부가 1518에 도시된 바와 같이, 사용자(190) 및/또는 지정된 거래 자금 계좌와 관련된 저장된 데이터를 사용해서 FI 혹은 FSP(120, 160)에 의해서 제공될 수도 있다. 다른 옵션으로서, 사용자(190) 및/또는 사용자 장치(110, 110')는 이후에 사용하기 위해서 사용자와 관련된 사용자 프로파일에 저장될 정보를 제공하는 것 및/또는 특정 데이터 아이템을 업데이트하는 것이 가능하다. 1520에서, 자동화된 데이터 퍼퓰레이션 및/또는 프로파일 업데이트 처리는 본 명세서에 개시된 바와 같이 사용자 로그인, 패스워드/PIN 입력의 사용, 장치 태핑, 생체 처리 등에 의해 보호될 수 있다.
1512에서는 또한, FI(120, 160)는 1516에서 수신, 생성 및/또는 업데이트된 '쇼핑 카트'(즉, 거래 인가 요청 데이터 세트) 정보 중 일부 혹은 전체를 확인 처리 등을 위해서 대응하는 판매자와 공유할 수 있다.
1524에서, SDK/API(116)는 거래 가격 중 지정된 자금을 사용해서 배상되는 전체 혹은 일부 구매액에 대응하는 거래 인가 요청 데이터 세트가 지불 리소스 계좌를 담당하는 FI/FSP(120, 160)에 보안 방식으로 포워딩되게 한다. 충분한 자금 혹은 신용 등을 지정된 지불 계좌에서 이용할 수 있다는 담당 FI/FSP(120, 160)에 의한 확인에 따라서, FI/FSP은 (보안) 거래 인가 데이터 세트를 생성해서 SDK/API(116)로 반환할 수 있다. 이러한 거래 인가 데이터 세트는 바람직하게는 보안되며, 판매가 인가되었는지 확인하기 위해서, 판매자(136, 136') 및/또는 판매자의 수신 계좌의 관리 책임이 있는 FI/FSP가 수용할 수 있는 임의의 데이터를 포함할 수 있다. 이러한 정보는 예컨대, 보안 지불 토큰, 보안 지불 토큰 참조, 인프라 FI 지불 확인('책임(on us)' 거래를 위한) 혹은 정산 확인 중 일부 혹은 전체를 명령어로서 포함할 수 있다.
따라서, 1526에서, 예컨대, 인가된 지불액 및 옵션으로서 등록된 판매자(136, 136')와 관련된 식별자를 포함하는 확인된 거래 지불 데이터 세트가 생성될 수 있고, 1528에서는, 1524에서 생성된 확인된 거래 데이터 세트는 SDK/API(116)에 의해서 장치(110, 110')로 반환될 수 있고, SDK/API(116)에 의해서 판매자의 판매자 애플리케이션(114)으로 포워딩되며, 이후, 1530에서, 거래에 대한 애플리케이션을 포함해서 1540에서 해독 및/또는 다른 처리를 위해서 판매자 시스템(136, 136')으로 포워딩되고, 1524에서, 판매자 시스템(136, 136')은 주문 확인 데이터 세트를 장치에 저장하거나 혹은 다른 처리를 위해서 출력 디스플레이 장치(610)를 통해서 사용자에게 제시하기 위해서 판매자 앱(114)으로 반환될 수 있다.
처리(1500)의 일부 실시예에서, 1512~1514에서, 사용자(190)는 도 14e에 도시되고 상기 설명된 바와 같이 판매자 앱(114)에 의해 다양한 지불 옵션을 제시받을 수 있다.
같은 혹은 다른 실시예에서, 도 14c 및 14d에 도시되고 본 명세서에서 설명된 바와 같이, 사용자(190)는 인터렉티브 GUI(1407)를 제시받을 수 있고, 사용자는 이를 통해서 다양한 지불 소스를 사용해서 지불을 지정, 선택 및 제어할 수 있다.
도 15a에 도시된 처리(1500)의 변형예(1500')가 도 15b에 도시되어 있다. 도 15b에 도시된 실시예에서, 처리(1500, 1500')는 사용자가 이용 가능한 복수의 지불 옵션(1486)을 나타내는 GUI(1407)를 생성하고 표시하는 단계 1514A 및 1514B를 포함한 처리 1514가 판매자 앱(114) 이외의 SDK/API(116)에 의해 실행되는 것을 제외하면 전반적으로 도 15a와 유사한 방식으로 진행된다. 도 15a의 1514c에 더 도시된 바와 같이, 복수의 이용 가능 지불 옵션을 나타내는 데이터는 신뢰된 서버(120, 160)에 의해 보안 저장되고, SDK/API(116)를 통해서 장치(110, 110')로 제공될 수 있다.
상술한 바와 같이, 본 발명은 신뢰된 거래 프로세서(120, 920)가 사용자 신원, 판매자 신원, 계좌 특성(계좌와 관련된 FI의 신원을 포함) 및/또는 사용자 선호도를 포함한 다양한 기준에 기초해서 여신 한도 혹은 다른 신용 계좌와 같은 하나 이상의 디폴트 혹은 다른 사용자 지정 계좌를 사용자 장치(110')에 의해 생성된 및/또는 특정 거래 요청 타입과 관련된 거래 요청과 연관시키는 모드를 포함한 여러 신규한 타입 및 모드의 정산 지불 처리를 가능하게 한다.
예컨대, 상술한 바와 같이 발행자(160, 960)(은행 혹은 다른 금융 기관과 같은)는 연신 한도를 고객(190)까지 확장할 수 있고, 하나 이상의 판매자와 사용자 사이에서 여신 한도를 거래의 정산을 위한 자금원으로서 사용하는 것을 사용자와 동의함으로써, 발행자(160, 960)에게 재지불하도록 이후에, 사용자와 관련된 다른 계좌로부터의 자금을 적용할 수 있다. 이러한 신용 기반 거래 지불 자금원의 사용은 종종 '실시간 신용' 처리의 응용예로도 간주된다.
상술한 바와 같이, 본 발명은 사용자(190)가 다수의 거래 자금원 및/또는 다른 지불원에서 인출하는 기능도 제공하며, 이 자금원 및 지불원은 하나 혹은 다수의 금융 기관 및/또는 다른 금융 서비스 제공자에 의해 유지, 관리 및/또는 제어될 수 있고, 거래 지불을 배상하도록 구매자(190)에 의해 함께 사용될 수 있다. 다수의 거래 지불 자금원을 사용하는 것을 '분할 지불' 처리의 사용이라고도 한다.
실시간 처리 및 분할 지불 처리를 모두 구현하기 위해서 본 발명에 따른 시스템을 사용하는 예가 도 17~22에 도시되어 있다.
도 17은 본 발명에 따른 분할 지불, 실시간 신용 처리(1700)의 구현에 적합한 시스템(100, 900)의 컴포넌트(110, 110', 120, 130, 150, 160) 사이의 신호 교환의 예시적인 세트를 나타낸다. 처리(1700)는 도 18을 특히 참조하면서 설명한다. 도 18은 도시되고 본 명세서에서 설명된 시스템과 일치하는 시스템(100, 900)의 추가적인 특정한 적절한 예이다.
도시된 실시예에서, 처리(1700)는 장치(110, 110')의 사용자(190)가 자신의 가상 월렛 애플리케이션(112, 622)의 사용을 통해 하나 이상의 중간 자금원('지불 비히클(payment vehicle)'이라고도 함)을 사용해서 지불하고, 동일한 혹은 다른 자금원 중 하나 이상을 사용해서 최종 정산을 행하는 것을 가능하게 한다. 중간 자금은 예컨대, 판매자 혹은 벤더를 판매시에 실시간으로 충족시키는데 사용될 수 있는 반면, 구매자와 자신의 은행 혹은 다른 FI와의 사이의 정산 자금은 동시에 혹은 임의의 이후 시점에 발생할 수 있다. 예컨대, 중간 지불은 1회 혹은 영구 외상 계좌에 청구될 수도 있고, 하나 이상의 예금, 신용 및/또는 포인트 계좌 등으로부터 이후에 정산이 행해진다.
도 17의 처리(1700)는 예컨대, 소매점에서 쇼핑하는 사용자(190)가 판매자 POS 단말(130, 134)에 모바일 네트워크 거래 통신 장치(110, 110') 및 사용자가 구매하고자 하는 하나 이상의 아이템을 접근시키는 1701에서 시작되는 것이다. 사용자(190)는 예컨대, 상술한 바와 같이 장치(110, 110')에 인스톨되었거나 혹은 액세스 가능한 가상 월렛 애플리케이션(112, 622)에 액세스하고, 장치(110, 110')의 입출력 장치(610) 및 GUI(1407)를 사용해서 판매자 POS 시스템(134) 및/또는 판매자 시스템(130)과 구매를 협상할 수 있으며, 이 협상에서는 지불될 하나 이상의 아이템 및 가격, 및 전체 거래 구매 가격의 식별을 마무리짓는다(culminating). 사용자(190)가 배상해서 지불을 준비하면, 사용자는 인터렉티브 GUI 장치에서 장치 화면(610)에 표시되는 '결제' 혹은 '지불 준비'를 선택할 수 있고(예컨대, 도 14a 참조), 이로써 장치(110')는 판매자에게 지불 가능한 거래 금액을 충진하기에 충분한 자금을 월렛 애플리케이션을 통해서 판매자 시스템(130)에 지불하는 것을 인가하는 거래 실행 커맨드를, 생성해서 가상 월렛 애플리케이션(112, 622)으로 라우팅한다. 도시된 예에서, 사용자(190)는 POS 장치(136, 136')를 통해서 판매자가 제공하는 상품 및/또는 서비스에 대해서 $45의 지불을 인가했다.
1702에서, 월렛 애플리케이션(112, 622)은 판매자 거래 지불 인가 데이터 세트 혹은 선불 지불 토큰, 및 판매자 시스템(130)이 거래를 완전히 배상시킬 때 지불하기 위해서 FI(120, 160)에 제시하는데 사용가능한 중간 지불 자금원(혹은 '지불 비히클')에 해당 금액을 청구하는 명령어를 포함하는 다른 거래 지불 커맨드를 생성해서 POS 단말(134, 136)에 라우팅할 수 있다. 이러한 토큰은 본 명세서에 개시된 바와 같이, 하나 이상의 신용, 예금, 포인트 혹은 다른 자금원에 대한 금액 청구를 인가하는 것을 나타낼 수 있다. 여기서 판매자 시스템(134, 136, 130)은 1703에서 거래 확인 데이터 세트를 생성해서 사용자의 거래 통신 장치(110, 110')에 라우팅하거나, 종이 영수증을 발행하거나 혹은 다른 거래 완료 확인을 제공하고, 또한 사용자(190)가 상품/서비스를 갖고 가는 것을 허용한다.
1704에서, 사용자의 월렛 애플리케이션(112, 622)은 사용자(190), 거래 통신 장치(110, 110') 등과 관련되고 거래에 대한 지불을 배상하기 위해서 적용 가능한 모든 지불 옵션을 폴링하는, 그리고 가능한 옵션을 리스팅하거나 혹은 나타내는 지불 옵션 데이터 세트를 사용자의 장치(110, 110')에 반환하는 처리(1704~1708)를 시작할 수 있다. 상술한 바와 같이 예컨대 이러한 리스팅은 이용 가능한 계좌와 관련된 식별자, 및 구매에 적용 가능한 자금의 값 혹은 자금 동등물(예컨대, 리워드 포인트 값)을 포함할 수 있다.
예컨대, 1704에서, 사용자의 월렛 애플리케이션(112, 622)은, 상술한 바와 같이 사용자(190) 및/또는 장치(110, 110')가 이용 가능한 계좌와 관련된 모든 FI를 폴링하기 위해서 발행 은행 혹은 다른 FI나 FSP(1750, 120, 920, 160)로의 사용자의 월렛(112, 622)와 관련된 명령어를 나타내는 신호를 포함한, 거래 지불 자금원 질의 데이터 세트를 생성할 수 있으며, 이러한 질의를 이러한 FI나 FSP와 관련된 거래 처리 시스템(1750)에 라우팅할 수 있다. 도시된 예에서는, 관련된 FI나 FSP의 거래 처리 시스템(1750)을 '보안 클라우드'로 표시되어 있다.
1705에서, 사용자의 월렛 애플리케이션(112, 622)과 관련된 FI(1750)는, 사용자(190) 및/또는 장치(110, 110')에게 처리(1701~1703)에서 실행되는 거래의 정산을 배상할 때 적용 가능한 모든 잠재적인 자금원을 식별할 것을 요구하는 것과 관련된 장치 혹은 사용자 프로파일 데이터 세트에 액세스할 수 있다. 예컨대, 도 17에 도시된 바와 같이, 1705에서, 관련된 거래 처리 시스템(1750)은, 하나 이상의 고객 로열티, 기프트 혹은 사용자(190) 및/또는 장치(110, 110')와 관련된 다른 현금과 같은 포인트 계좌를 관리하는, 하나 이상의 거래에 대한 체크를 위해 실행 가능한 명령어로서 거래 처리 시스템(120, 160, 1752) "포인트 은행"에 의해 해석 가능한 신호를 포함한 이용 가능한 포인트 질의 데이터 세트를 라우팅할 수 있으며, 이러한 시스템으로부터, 실행되는 거래에 적용할 포인트 시스템을 통해서 이용 가능한 다수의 포인트 및/또는 현금 값을 나타내는 데이터를 포함한 포인트 이용 가능 데이터 세트를 수신할 수 있다.
유사하게, 1706에서, 관련 거래 처리 시스템(1750)은 사용자(190) 및/또는 장치(110, 110')와 관련된 대출, 여신 한도 혹은 다른 융자 제도나 계좌, 이용 가능한 신용 잔고를 체크하기 위해서 실행 가능한 명령어로서 시스템(1754)이 해석 가능한 신호를 포함하는 이용 가능 신용 질의를 관리하는 "대출 기록 원부(Loan Book of Record)"를 하나 이상의 거래 처리 시스템(1754, 120, 920)에 라우팅할 수 있으며, 이러한 시스템(1754)으로부터 이러한 융자 제도 혹은 계좌를 통해서 이용 가능한 자금 금액을 나타내는 데이터를 포함하는 신용 이용 가능 데이터 세트를 수신할 수 있다.
유사하게, 1707에서, 관련 거래 처리 시스템(1750)은, 고객 프로파일, 혹은 사용자(190) 및/또는 장치(110, 110')와 관련되어 있으며, 거래(1701~1703)에 대해서 지불 자금원으로서 적용하는데 이용 가능하며, 이러한 목적에 이용 가능한 자금의 값을 체크하기 위해서 실용 가능한 명령어로서 시스템(1756)이 해석 가능한 예금 혹은 요구불 현금 계좌와 관련된 식별자를 나타내는 데이터를 포함하는 다른 데이터 세트를 관리하는, '고객 프로파일'을 하나 이상의 거래 처리 시스템(1756, 120, 920)에 라우팅할 수 있고, 이러한 계좌를 통해서 이용 가능한 자금의 금액을 나타내는 데이터를 포함한 자금 이용 가능 데이터 세트를 이러한 세트로부터 수신할 수 있다. 이러한 고객 프로파일(1756)은 소망 레벨의 이용 가능성 및/또는 보안성을 달성하는데 사용하기에 적합한 임의의 사용자 장치(110, 110') 및/또는 다른 거래 프로세서(120, 160, 920, 150, 130)에 저장되거나 이에 의해 액세스될 수 있다.
모든 이용 가능한 잠재적인 자금원을 폴링함으로써, 1708에서 관련 거래 처리 시스템(1750)은 1705, 1706, 1707에서 수신한, 포인트 이용 가능 데이터 세트, 신용 이용 가능 데이터 세트 및 자금 이용 가능 데이터 세트를 사용해서, 거래 지불 자금원 옵션 데이터 세트를 생성하고, 이를 요청 월렛 애플리케이션(112, 622)에 반환한다.
수신시에, 요청하는 월렛 애플리케이션(112, 622)은 장치(110, 110')로 하여금, 예컨대, 도 14b, 도 14e 및 도 18b 및 도 18c에 도시된 장치(110, 110')의 사용자가 이용 가능한 지불 옵션을 나타내는 아이템(1404, 1406)을 포함하는 GUI를 생성해서 사용자(190)에게 표시하게 한다. 도 18b에서는 예컨대, UI 아이템(1486, 1810)이 도시되어 있으며, 구매에 적용하는데 262포인트 및 $104.83의 값을 가진 "AVION(R)" Visa(R) 카드 계좌 및 리워드 계좌를 이용 가능하다는 것을 나타낸다. 도 18b에 도시된 실시예에는 또한 UI 아이템(1811, 1812)이 제공되는데, 아이템(1811)은 추가 포인트가 거래에 적용 가능하게 된 경우에 사용자(190)가 포인트 정보를 재생하는 것을 가능하게 하고, 아이템(1812)은 리워드 계좌 및 포인트에 관한 추가 정보에 액세스하는데 사용될 수 있다.
1709에서, 사용자(190)는 GUI(1407)의 아이템(1404, 1406, 1486, 1810 등)을 사용해서, 1701~1703에서 거래를 정산한 거래 프로세서로 정산하는데 사용하기 위해서 하나 이상의 계좌 혹은 다른 거래 지불 자금원을 지정할 수 있고, 이로써 월렛 앱(112, 622)으로 하여금 거래 정산 데이터 세트 혹은 거래 인가 요청 데이터 세트를 생성하게 하며, 이는 적어도 거래의 배상시에 지불 가능한 거래 금액, 하나 이상의 소망의 거래 지불 자금원 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내는 데이터를 포함한다. 예컨대, 도 17에 도시된 예에서, 사용자는 입출력 장치(610)를 사용해서 사용자가 대출 계좌(도 18b의 1486에 도시된 Visa 계좌와 같은)로부터 $10를, 예금 계좌로부터 $5 및 리워드 포인트에서 $20를 적용하고자 한다는 것을 나타내는 명령어를 생성한다. 사용자는 예컨대, 인터렉티브 슬라이더 그래픽 장치(1422)를 사용해서 이를 행함으로써 자금 중 얼마를 예금 혹은 신용 '카드' 계좌로부터 인출할지 및 리워드 포인트 잔고로부터 얼마를 인출할지를 판정한다.
1710에서, 사용자는 월렛 앱(112, 622)으로 하여금 거래 정산 데이터 세트 혹은 거래 인가 요청 데이터 세트를 월렛 앱(112)과 관련된 거래 처리 시스템(1750)에 라우팅하게 하는, '지불' 아이템(1472)(도 14f)을 선택할 수 있고, 이로써 시스템(1750)으로 하여금 거래 정산 데이터 세트에 나타난 자금원으로부터 사용자(190)가 나타내는 금액의 자금을 축적해서 이를 1702~1703에서 전달되는 중간 지불에 적용하게 한다.
1711~1713에서, 예컨대, 거래 프로세서(1750)는 포인트의 상환(1711), 대출/신용 청구(1712)의 발행, 및 자금의 송금(1713)을 위한 명령어를 생성해서 라우팅할 수 있고, 1714에서는 중간 지불이 인출되는 계좌로 입금함으로써 1702~1703의 청구에 대해 축적된 자금을 적용하며, 이로써 복수의 지불 자금원을 사용해서 배상될 중간 지불 자금원을 사용해서 지불되게 된다.
1715에서, 거래 프로세서(1750)는 거래 및 지불 세부 사항과 관련된 임의의 유용한 혹은 소망의 데이터를 포함한 거래 정산 확인 데이터 세트를 생성해서 월렛 앱(112, 622)에 라우팅할 수 있다.
상술한 바와 같이, 또한 당업자가 이해하는 바와 같이, 본 개시와 유사하게 만들어진다면, 본 명세서에 개시된 임의의 실시예에서, 보안 클라우드 시스템(1750), 포인트 은행 시스템(1752), 대출 기록 원부 시스템(1754), 고객 프로파일(1756), 계좌 원부 기록(1758) 및 지불 비히클 원부 기록(1760) 중 일부 혹은 전체는 하나의 거래 프로세서(120, 160, 920)에 의해서 혹은 다수의 프로세서(120, 160, 920)에 의해서 동작 혹은 관리될 수 있다.
따라서, 다양한 측면 및 실시예에서, 본 발명은 네트워크 거래 통신 장치(110, 110')를 제공하며, 각각의 장치는 적어도 하나의 사용자 입력 장치(610), 적어도 하나의 근거리 혹은 다른 단거리 무선 통신 시스템(614, 616), 적어도 하나의 네트워크 혹은 장거리 통신 시스템(612), 적어도 하나의 데이터 프로세서(602) 및 적어도 하나의 영구 메모리 장치(604, 605, 618)를 포함하고, 적어도 하나의 영구 메모리 장치에는 적어도 하나의 데이터 프로세서로 하여금 적어도 하나의 근거리 무선 통신 시스템(614, 616)을 통해서 적어도 하나의 사용자 입력 장치가 생성한 신호 및 판매자 거래 시스템(130, 134) 등으로부터 수신한 신호를 사용해서, 적어도 판매자와 관련된 식별자 및 판매자에게 지불 가능한 거래 금액을 포함하는 요청된 거래 데이터 세트를 생성하게 하고, 적어도 하나의 사용자 입력 장치(610)가 생성한 추가 신호에 응답해서, 적어도 판매자, 판매자에게 지불 가능한 거래 금액, 적어도 2개의 거래 지불 자금원 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원을 이용해서 대금을 지불할 수 있는 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 생성하게 하며, 거래 인가 요청 데이터 세트를 적어도 하나의 네트워크 통신 시스템(612) 및 근거리 무선 통신 시스템(614, 616) 중 적어도 하나를 사용해서 거래 처리 시스템(120, 120')으로 라우팅하는 하는 머신-이해 가능 명령어가 저장되어 있다.
나아가, 다양한 측면 및 실시예에서, 본 발명은 거래 처리 시스템(120, 160, 920, 1750 등)을 제공하며, 각각의 시스템은, 적어도 하나의 네트워크 통신 시스템, 적어도 하나의 데이터 프로세서 및 적어도 하나의 영구 메모리 장치를 포함하고, 적어도 하나의 영구 메모리 장치에는 머신 해석 가능 명령어가 저장되어 있으며, 이 명령어는 적어도 하나의 데이터 프로세서로 하여금, 적어도 하나의 네트워크 통신 시스템을 이용해서 네트워크 거래 통신 장치로부터 적어도 판매자와 관련된 식별자, 판매자에게 지불 가능한 거래 금액, 복수의 거래 지불 자금원과 관련된 식별자 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 수신하게 하고, 복수의 거래 지불 자금원 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 부분과 관련된 식별자를 나타내는 데이터를 사용해서 각각의 자금원과 관련해서 각각의 대응하는 부분을 커버하기에 충분한 자금의 이용 가능성을 검증하게 하며, 동일한 혹은 다른 네트워크 통신 시스템을 사용해서, 판매자에게 지불 가능한 거래 금액의 지불의 인가를 나타내는 데이터를 포함하는 적어도 하나의 거래 지불 인가 데이터 세트를 네트워크 거래 장치 및 판매자와 관련된 판매자 거래 시스템 중 적어도 하나로 라우팅하게 한다.
도 19는 본 발명에 따른 분할 지불 실시간 신용 처리(1900)의 구현에 적합한 시스템(100, 900)의 컴포넌트(110, 110', 120, 130, 150, 160) 사이의 신호 교환의 세트를 도식적으로 나타내고 있다. 처리(1900)는 특히 도 20을 참조하면서 설명한다. 도 20은 도시되고 본 명세서에 설명된 다른 시스템과 일치하는 시스템(100, 900)의 적절한 예이다.
도시된 실시예에서 처리(1900)는 장치(110, 110')의 사용자(190)가, 동적인 카드 에뮬레이터(예컨대, 동적인 HCE)를 통해서 예금, 신용, 포인트 및/또는 다른 자금원을 사용해서 거래에 대한 지불을 정산하기 위해서 동적으로(실시간으로) 생성된 하나 이상의 '자금 토큰'을 사용해서, 거래에 대해 지불하는 것을 가능하게 한다. 이러한 처리는 구매자(190)가 판매자 시스템(130)이 인지하거나 수용하도록 구성되지 않은 예컨대, 리워드 포인트를 포함한 하나 이상의 자금원을 사용해서 거래에 대해서 판매자 시스템(130)에 지불하는 것을 가능하게 하는데 사용될 수 있다. 이러한 처리는 예컨대, 하나의 타입의 자금을 다른 타입의 자금에 대한 프록시로서 사용하는 것을 생각할 수 있다.
도 19의 처리(1900)는, 모바일 및/또는 데스크톱 장치(110, 110')에 인스톨된 판매자 애플리케이션(114, 630)과 판매자 온라인 쇼핑 시스템(130) 사이에 성립된 거래 통신 세션을 사용해서 온라인 쇼핑한 사용자(190)가, 구매된 하나 이상의 아이템, 지불된 가격, 및 대응하는 판매자 시스템(130, 136)에 지불될 전체 거래 구매 가격을 식별하는 처리를 완수하는 1901에서 시작하는 것이다. 사용자(190)가 충족되고 지불이 준비되면, 사용자는 인터렉티브 GUI 장치로 장치 화면(610)에 표시된 '결제' 혹은 '지불 준비'를 선택할 수 있고(예컨대, 도 14a 참조), 이로써 장치(110, 110')는 판매자에게 지불 가능한 거래 지불 금액을 만족하기에 충분한 자금의 판매자 시스템(130)에 대한 지불을 인가하는 거래 실행 커맨드를 생성해서 월렛 애플리케이션을 통해서 판매자 애플리케이션(114, 116)에 라우팅하는 것이 가능하다. 도시된 예에서, 사용자(190)는 판매자 애플리케이션(114, 630)을 통해서 제공된 상품 및/또는 서비스에 대해 $35의 지불을 인가했다.
1902에서, 은행 월렛 애플리케이션과 관련된 거래 프로세서(1750)에 의한 커맨드의 해석 및 이후 요청된 거래를 실행할 때 사용하기 위해 사용 가능한 임의의 추가적인 요구 정보 및/또는 처리에 더해서, 판매자 애플리케이션(114, 630)은 지불을 인가하는 거래 실행 커맨드를 은행 월렛 애플리케이션(112, 622)에 포워딩할 수 있다. 상기 설명한 바와 같이, 본 명세서에 개시된 지불 처리를 구현하는데 사용하기에 적합한 실행 커맨드는 전형적으로, 거래 수행 상대인 판매자 시스템(139), 거래를 개시한 사용자(190) 및/또는 장치(110, 110'), 지불되는 거래 지불 구매 가격 및 옵션으로 수행되는 개별 거래와 관련된 하나 이상의 식별자를 나타내는 데이터를 포함한다. 나아가, 이러한 커맨드는 전형적으로 거래의 배상에 사용되는 하나 이상의 계좌 및 다른 자금원을 식별할 수 있으며, 이는 거래시에 디폴트에 의해 혹은 사용자(190)에 의한 선택에 의해 식별될 수 있다.
1903에서, 사용자의 월렛 애플리케이션(112, 622)은 월렛 애플리케이션(112, 622)와 관련된 거래 프로세서 시스템(1750)이 사용자(190), 거래 통신 장치(110, 110') 등과 관련되어 있으며 거래에 대한 지불을 배상하는데 적용할 수 있는 모든 지불 옵션을 폴링하며, 사용자의 장치(110, 110')에게 사용가능한 옵션을 리스팅하거나 혹은 나타내는 지불 옵션 데이터를 반환하는 처리(1903~1907)를 시작할 수 있다. 상술한 바와 같이, 예컨대 리스팅은 구매에 적용할 수 있는 이용 가능한 계좌 및 자금 혹은 자금 등가물(예컨대, 리워드 포인트 값)과 관련된 식별자를 포함할 수 있다.
예컨대, 1903에서, 월렛 애플리케이션(112, 622)은 거래 지불 자금원 질의 데이터 세트를 생성할 수 있으며, 이는 상술한 바와 같이 사용자(190) 및/또는 장치(110, 110')가 이용 가능한 계좌와 관련된 모든 FI를 폴링하는 사용자의 월렛 애플리케이션(112, 622)과 관련되어 있으며 발행 은행 혹은 다른 FI 혹은 FSP(1750)에 대한 명령어를 나타내는 신호를 포함한다. 도시된 예에서, 관련된 FI 혹은 FSP의 거래 처리 시스템(1750)은 '보안 클라우드'라고 되어 있다.
1904에서, 사용자의 월렛 애플리케이션(112, 622)과 관련된 FI(1750)는 문의하는 사용자(190) 및/또는 장치(110, 110')와 관련된 장치 혹은 사용자 프로파일 데이터 세트에 액세스해서, 처리(1901~1902)에서 실행된 거래의 정산을 배상할 때 적용 가능한 모든 잠재적인 자금원을 식별할 수 있다. 도 19에 도시된 바와 같이, 예컨대, 1904에서 관련 거래 처리 시스템(1750)은, 사용자(190) 및/또는 장치(110, 110')와 관련된 하나 이상의 고객 로열티, 기프트 혹은 다른 현금 등가 포인트를 관리하는 "포인트 은행"인 거래 처리 시스템(120, 160, 1752)에 의해 해석 가능한 신호를 포함하는 이용 가능 포인트 질의 데이터 세트를, 하나 이상의 거래에 대한 체크를 위해서, 실행 가능 명령어로서 라우팅할 수 있고, 이러한 시스템(1752)로부터, 실행된 거래에 적용하기 위해서 포인트 시스템을 통해서 이용 가능한 다수의 포인트 및/또는 현금 값을 나타내는 데이터를 포함하는 포인트 이용 가능 데이터 세트를 수신할 수 있다.
유사하게, 1905에서, 관련된 거래 처리 시스템(1750)은 하나 이상의 거래 처리 시스템(1754, 120, 920)에 사용자(190) 및/또는 장치(110, 110')와 관련된 대출, 신용 카드, 여신 한도 혹은 다른 융자 제도나 계좌를 관리하는 '대출 기록 원부'를 라우팅할 수 있고, 이용 가능 신용 질의는 이용 가능한 신용 잔고를 체크하기 위해서 시스템(1754)에 의해 해석 가능한 신호를 실행 가능한 명령어로서 포함하며, 이러한 시스템(1754)으로부터 융자 제도 혹은 계좌를 통해 이용 가능한 자금의 금액을 나타내는 데이터를 포함하는 신용 이용 가능 데이터 세트를 수신할 수 있다.
유사하게, 1906에서, 관련 거래 처리 시스템(1750)은, 고객 프로파일, 혹은 사용자(190) 및/또는 장치(110, 110')와 관련되어 있으며, 거래(1701~1703)에 대해서 지불 자금원으로서 적용하는데 이용 가능하며, 이러한 목적에 이용 가능한 자금의 값을 체크하기 위해서 실용 가능한 명령어로서 시스템(1756)이 해석 가능한 예금 혹은 요구불 현금 계좌와 관련된 식별자를 나타내는 데이터를 포함하는 다른 데이터 세트를 관리하는, '고객 프로파일'을 하나 이상의 거래 처리 시스템(1756, 120, 920)에 라우팅할 수 있으며, 이러한 계좌로부터 이용 가능한 자금의 금액을 나타내는 데이터를 포함하는 자금 이용 가능 데이터 세트를 시스템(1756)으로부터 수신할 수 있다.
1907에서 모든 이용 가능한 잠재적인 자금원을 폴링함으로써, 1904, 1905, 1906에서 수신한 관련 거래 처리 시스템(1750)은 수신한 포인트 이용 가능 데이터 세트, 신용 이용 가능 데이터 세트 및 자금 이용 가능 데이터 세트를 사용해서 거래 지불 자금원 옵션 데이터 세트를 생성하고 이를 요청하는 월렛 애플리케이션(112, 622)에 반환할 수 있다.
이를 수신하면 월렛 애플리케이션(112, 622)는 예컨대, 도 14b, 도 14e 및 도 18b 및 도 18c에 도시된 바와 같이 장치(110, 110')로 하여금 장치(110')의 사용자가 이용 가능한 지불 옵션을 나타내는 아이템(1404, 1406)을 포함하는 GUI를 생성해서 사용자(190)에게 표시하게 한다. 도 18b에서, 예컨대, 262 포인트 및 $104.83의 값을 가진 "AVION(R)" Visa(R) 카드 계좌 및 리워드 계좌를 구매에 적용 가능하다는 것을 나타내는 UI 아이템(1486, 1810)이 도시되어 있다. UI 아이템(1811, 1812)이 도 18b에 도시된 실시예에 제공되고, UI 아이템(1811)은 현재 추가 포인트를 거래에 이용 가능한 경우에 사용자(190)가 포인트를 갱신하는 것을 가능하게 하고, 아이템(1812)은 리워드 계좌 및 포인트에 관한 추가 정보에 액세스하는데 사용될 수 있다.
1908에서, 사용자(190)는 GUI(1407)의 아이템(1404, 1406, 1486, 1810 등)을 사용해서, 1701~1703에서 거래를 정산한 거래 프로세서(1750, 120, 160)로 정산하는데 사용할 하나 이상의 계좌 혹은 다른 거래 지불 자금원을 지정할 수 있고, 이로써 월렛 앱(112, 622)으로 하여금 적어도 거래를 배상하는데 지불 가능한 거래 금액, 하나 하나 이상의 소망의 거래 지불 자금원 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 사용해서 대금을 지불할 부분을 나타내는 데이터를 포함하는 거래 정산 데이터 세트 혹은 거래 인가 요청 데이터 세트를 생성하게 한다. 예컨대, 도 19에 도시된 예에서, 사용자는 입출력 장치(610)를 사용해서 사용자가 대출 계좌(도 18b의 1486에 도시된 Visa 계좌 등)로부터 $10를, 예금 계좌로부터 $5를, 리워드 포인트에서 $20를 적용하고자 한다는 것을 나타내는 명령어를 생성한다. 사용자는 예컨대, 인터렉티브 슬라이더 그래픽 장치(1422)를 사용해서 예금 혹은 신용 '카드' 계좌로부터 얼마의 자금이 인출될지 및 리워드 포인즈 잔고로부터 얼마나 인출될지를 판정함으로써 행해질 수 있다.
1909에서 사용자는 1870에서 '지불' 아이템(1472: 도 14f)을 선택해서, 월렛 앱(112, 622)으로 하여금 거래 정산 데이터 세트 혹은 거래 인가 요청 데이터 세트를 월렛 앱(112)과 관련된 거래 처리 시스템(1750)으로 라우팅하게 하고, 이로써 시스템(1750)은 사용자(190)가 표시한 금액에서 거래 정산 데이터 세트에 나타난 자금원으로부터의 자금이 요청된 거래를 배상하는데 사용할 수 있다는 것을 축적 혹은 확인하게 하고, 판매자 시스템(130)에 지불할 때 장치(110, 110')가 사용할 자금 토큰을 생성하게 한다.
1910~1912에서, 예컨대, 거래 프로세서(1750)는 1908에서 사용자가 명시한 금액의 포인트의 상환(1910), 대출/신용 청구(1911) 및 자금의 송금(1912)을 위한 명령어를 생성해서 라우팅하고, 1913에서 요청된 거래를 배상하기 위해 판매자에게 지불한 자금 토큰을 생성한다. 이러한 토큰은 예컨대, 판매자에게 지불한 거래 금액에 대응하는 값과 같은 토큰 값을 나타내는 데이터 및 판매자에게 지불하는데 사용될 하나 이상의 자금원과 관련된 하나 이상의 식별자를 포함할 수 있다. 이러한 자금원 식별자는 예컨대, Visa, MasterCard, Interac 혹은 다른 지불 프로토콜에 따라서 액세스 가능한 하나 이상의 계좌와 같은, 예금, 신용 및/또는 리워드 계좌 및/또는 판매자 시스템(130)이 허용하는 프로토콜과 관련된 하나 이상의 코드을 포함한 소망의 타입이 될 수 있다. 본 발명의 이러한 측면이 제공하는 특정한 이점은, 지불 토큰이 거래 지불 자금원에 관계없이, 판매자 시스템(130)이 허용하는 임의의 지불 프로토콜에 따라서 코팅될 수 있다는 점이다. 예컨대, 사용자(190)와 관련된 하나 이상의 Visa, Interac 및 Avion 포인트 계좌로 대금을 지불하는 것은, 은행 월렛 애플리케이션(112, 622)과 관련된 시스템(1750)이 관리하는 지불 계좌와 관련된 완전히 별도의 계좌 번호를 적절하게 형식 변경해서 판매자 시스템(130)이 허용하는 MasterCard의 형식으로 될 수 있다.
본 발명의 이러한 측면의 다른 바람직한 특징은, 이러한 계좌 번호가 한번의 거래와 관련된 일회용 혹은 '다이나믹 카드' 계좌 번호가 될 수 있다는 점이다. 이는 예컨대, 후속하는 회계에서 거래를 인가하고 추적하는데 도움이 된다. 이러한 특징은 또한 실시간 신용 계좌 번호의 '리사이클'을 가능하게 해서, 매우 큰 혹은 제한된 수의 거래가 이러한 방식으로 처리될 수 있다.
1914에서, 1913에서 생성된 자금 토큰을 나타내는 다이나믹 카드를 생성하는 적절한 명령어를 나타내는 신호가 다이나믹 신용 계좌 번호의 할당 및 다이나믹 카드 (실시간 신용) 토큰의 생성 및 반환을 위해서, 선불 토큰 프로세서(1860)로 포워딩되고 이는 거래에 대한 지불을 배상하기 위해서 판매자 시스템(130)으로 라우팅된다.
1915에서, 사용자(190)와 관련된 다이나믹 신용 번호 및/또는 사용자와 관련된 하나 이상의 계좌 혹은 장치에는 거래 프로세서(1750)에 의해 관리되는 사용자의 프로파일 데이터 세트가 추가될 수 있으며, 이 번호는 향후의 거래에 사용될 수 있고, 사용자, 장치 등과 용이하게 관련될 수 있다.
1916에서, 다이나믹 카드 지불 세트는 사용자의 은행 월렛 애플리케이션으로 라우팅될 수 있고, 옵션으로 적절한 인가 코드, 다이나믹 카드 (실시간 신용) 계좌 번호 등을 포함하는 거래 정산 데이터 세트 혹은 거래 인가 데이터 세트로서 형식 변경될 수 있으며, 그 결과 판매자 애플리케이션(114, 630)가 허용 가능한 형태가 되어서 거래 지불을 처리하는데 판매자 시스템(130)에 의해 사용된다.
1917에서, 예컨대, 임의의 다이나믹 카드 계좌 번호, 거래 지불 금액 등을 포함한 적절한 계좌 식별자를 나타내는 데이터를 포함하는 거래 인가 데이터 세트는, 거래의 지불을 위해서, 고유 거래 식별자 등과 같은 거래 및 지불 세부 사항과 관련된 임의의 다른 유용한 혹은 소망의 데이터와 함께, 판매자 애플리케이션(114, 630) 및/또는 판매자 백엔드 시스템(130, 136)로 라우팅될 수 있다.
처리(1900)에 대한 설명에 개시된 바와 같이, 본 명세서에 개시된 실시간 신용 처리는 분할 지불 처리로 혹은 혹은 단일 계좌 혹은 자금원에 의해 대금이 지불되는 거래 지불 처리로 수행될 수 있다는 점에 주의한다. 따라서, 다양한 측면 및 실시예에서 본 발명은 네트워크 거래 통신 장치(110, 110')로부터 거래 인가 요청 데이터 세트를 수신하고(거래 인가 요청 데이터 세트는 각각 적어도 판매자와 관련된 식별자, 판매자에게 지불 가능한 거래 금액 및 하나 이상의 판매 거래 자금원을 나타내는 데이터를 포함함), 판매자와 관련된 식별자 및 판매자에게 지불 가능한 거래 금액을 사용해서 판매자 및 네트워크 거래 통신 장치 중 적어도 하나에 판매자 거래 지불 인가 데이터 세트를 라우팅하고(판매자 거래 지불 인가 데이터 세트는 판매자에게 지불 가능한 거래 금액에 대한 중간 지불 자금원과 관련된 식별자를 나타내는 데이터를 포함함), 구매 거래 자금원과 관련된 계좌로부터 중간 지불 자금원과 관련된 계좌로의 송금의 인가, 복수의 거래 지불 자금원에 대한 보상, 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 사용해서 대금을 지불할 부분을 나타내는 데이터를 포함하는 거래 정산 데이터 세트를 생성함으로써, 중간 지불 자금원을 사용해서 대금이 지불되는 것이 복수의 지불 자금원을 사용해서 충족되게 하기에 적합한 거래 처리 시스템(120, 160, 920, 1750 등)을 제공한다.
상술한 바와 같이, 본 발명의 다양한 측면 및 실시예가 제공하는 중요한 이점은, 사용자(190)가 구매 혹은 다른 거래에 대한 대금을 지불하기 위해서 다수의 지불 계좌(자금원)에 액세스하는데 분할 지불 처리를 사용할 수 있다는 점이다. 나아가, 다양한 측면 및 실시예에서 본 발명은 기존(예컨대, 종래의) 지불 처리에 따라서 분할 지불 처리를 사용할 수 있다는 이점을 제공하며, 이는 종종 '지불 궤도' 처리라고도 한다(예컨대, 도 4 및 대응 텍스트 참조).
다양한 실시예에서, 본 발명은, 예컨대 임시 실시간 신용 계좌 및 처리를 포함한 임시 계좌의 사용, 및 종래의 지불 프로토콜에 따른 지불 거래 데이터 세트에 제공되는 자유 필드(discretionary fields)에서 특별히 맞춰진 데이터 세트의 사용과 같은 적어도 2개의 타입의 '정상 궤도' 분할 지불 처리를 가능하게 한다.
도 21은 예컨대, 본 발명에 따른 분할 지불 처리(2100)의 구현에 적합한 시스템(100, 900)의 컴포넌트(110, 110', 120, 30, 150, 160) 사이의 신호 교환의 세트를 나타낸다. 처리(2100)는 특히 도 18을 참조로 설명된다.
도시된 실시예에서, 처리(2100)는 장치(110, 110')의 사용자(190)가 자신의 가상 월렛 애플리케이션(112, 622)을 사용해서 단일 거래 지불 자금원 식별자를 포함하는 거래 인가 요청 데이터 세트를 생성함으로써 다수의 자금원을 사용한 거래에 대한 지불을 행하는 것을 가능하게 하고, 그 결과 임의의 판매자 및/또는 FI 거래 처리 시스템(130, 120, 160, 920 등)에 의해서 임의의 종래의 단일 자금원 지불과 같은 방식으로 지불이 처리되어서 사용자의 은행 혹은 다른 FI에 의한 정산을 위해 정리될 수 있다. 예컨대, 복수의 신용, 예금, 및/또는 포인트 자금원에 기초한 거래 지불은 신용 카드 혹은 다른 신용 계좌를 나타내는 단일 지불원 식별자를 제시받고, 따라서 판매자 시스템(130)에 의한 지불을 위해 처리되며, 여기서 판매자 시스템(130)에 대한 단일 지불이 판매자에 의한 인식 없이도 다수의 계좌에 의해 대금이 지불된다.
도시된 실시예에서, 처리(2100)는 소매점에서 쇼핑한 사용자(190)가 모바일 네트워크 거래 통신 장치(110, 110') 및 구매하고자 하는 하나 이상의 아이템을 판매자 POS 단말(130, 134)에 어프로치하는 2101에서 시작된다. 사용자(190)는 예컨대, 상술한 바와 같이 장치(110, 110')에 인스톨되었거나 혹은 이에 의해 액세스 가능한 가상 월렛 애플리케이션(112, 622)에 액세스할 수 있고, 상술한 바와 같이 2012에서, 자신의 장치(110, 110')를 POS 장치(134)의 NFC 단말로 탭하거나 가상 월렛 애플리케이션(112, 622)으로 하여금 거래 통신 세션을 성립해서 2103에서 예컨대 지불된 하나 이상의 아이템 및 가격, 판매자 시스템(134, 130) 및 총 거래 구매 가격을 나타내는 제안된 거래 데이터 세트를 POS로부터 수신하게 한다. 이후에 월렛 애플리케이션(112, 622)은 상술한 바와 같은 제안된 거래의 세부 사항을 나타내는 사용자 인터페이스(1407)를 생성해서 장치(110, 110')에 표시할 수 있다.
사용자(190)가 충족되고 지불이 준비되면, 2104에서, 사용자는 인터렉티브 GUI 장치로 장치 화면(610)에 표시된 '결제' 혹은 '지불 준비'를 선택할 수 있고(예컨대, 도 14a 참조), 이로써 월렛 애플리케이션(112, 622)은 2105, 1704에서 사용자(190), 거래 통신 장치(110, 110') 등과 관련되고 거래에 대한 지불을 배상하기 위해서 적용 가능한 모든 지불 옵션을 폴링하는, 그리고 가능한 옵션을 리스팅하거나 혹은 나타내는 지불 옵션 데이터 세트를 사용자의 장치(110, 110')에 반환하는 처리(1704~1708)를 개시할 수 있다. 상술한 바와 같이 예컨대 이러한 리스팅은 이용 가능한 계좌와 관련된 식별자, 및 구매에 적용 가능한 자금의 값 혹은 자금 동등물(예컨대, 리워드 포인트 값)을 포함할 수 있다.
모든 이용 가능한 잠재적인 자금원을 폴링함으로써, 1708에서 관련 거래 처리 시스템(1750)은 1705, 1706, 1707에서 수신한, 포인트 이용 가능 데이터 세트, 신용 이용 가능 데이터 세트 및 자금 이용 가능 데이터 세트를 사용해서, 거래 지불 자금원 옵션 데이터 세트를 생성하고, 이를 요청 월렛 애플리케이션(112, 622)에 반환한다.
수신시에, 요청하는 월렛 애플리케이션(112, 622)은 장치(110, 110')로 하여금, 예컨대, 도 14b, 도 14e 및 도 18b 및 도 18c에 도시된 장치(110, 110')의 사용자가 이용 가능한 지불 옵션을 나타내는 아이템(1404, 1406)을 포함하는 GUI를 생성해서 사용자(190)에게 표시하게 한다. 도 18b에서는 예컨대, UI 아이템(1486, 1810)이 도시되어 있으며, 구매에 적용하는데 262포인트 및 $104.83의 값을 가진 "AVION(R)" Visa(R) 카드 계좌 및 리워드 계좌를 이용 가능하다는 것을 나타낸다. 도 18b에 도시된 실시예에는 또한 UI 아이템(1811, 1812)이 제공되는데, 아이템(1811)은 추가 포인트가 거래에 적용 가능하게 된 경우에 사용자(190)가 포인트 정보를 재생하는 것을 가능하게 하고, 아이템(1812)은 리워드 계좌 및 포인트에 관한 추가 정보에 액세스하는데 사용될 수 있다.
1709, 2110에서, 사용자(190)는 GUI(1407)의 아이템(1404, 1406, 1486, 1810)을 사용해서 제안된 거래에 대한 지불을 완료하는데 사용할 복수의 계좌 혹은 다른 거래 지불 자금원을 지정할 수 있으며, 이로써 월렛 앱(112, 622)으로 하여금 거래의 배상에 지불 가능한 적어도 거래 금액, 복수의 소망의 거래 지불 자금원과 관련된 식별자, 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 사용해서 대금을 지불할 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 생성하게 한다. 예컨대, 도 21에 도시된 예에서, 사용자는 입출력 장치(610)를 사용해서 사용자가 대출 계좌(도 18b의 1486에 도시된 Visa 계좌와 같은)로부터 $10를, 예금 계좌로부터 $5 및 리워드 포인트에서 $20를 적용하고자 한다는 것을 나타내는 명령어를 생성한다. 사용자는 예컨대, 인터렉티브 슬라이더 그래픽 장치(1422)를 사용해서 이를 행함으로써 자금 중 얼마를 예금 혹은 신용 '카드' 계좌로부터 인출할지 및 리워드 포인트 잔고로부터 얼마를 인출할지를 판정한다.
2110에서, 사용자는 월렛 앱(112, 622)으로 하여금 지불 토큰(이러한 경우에 분할 지불 토큰이라고 함)을 생성하게 하도록 구성된 명령어 세트를 생성하도록(1870) '지불' 아이템(1472)(도 14f)을 선택할 수 있고, 지불 토큰은 적어도 하나의 총 제안 거래 지불 및 하나 이상의 거래 지불 프로세서(120, 920, 2150, 1750 등)가 복수의 소망의 거래 자금원 및 총 거래에 대해 각각의 자금원을 사용해서 지불되는 금액 및/또는 비율을 나타내는 것으로서 해석 가능한 코드를 포함한다. 거래 프로세서(1750, 120 등)에 의한 거래 지불의 소망의 처리에 따라서, 이러한 분할 지불 토큰은 또한 판매자 거래 시스템(130), 지불 타입 정보, 라우팅 명령어, 특정 거래 식별자, 토큰이 유효한 시간/날짜 범위 등과 관련된 식별자 중 일부 혹은 전체를 더 포함할 수 있다.
처리(2100)의 일부 실시예에서, 하나 이상의 거래 지불 프로세서(120, 920, 2150, 1750 등)가 복수의 소망의 거래 자금원 및 총 거래에 대해 각각의 자금원을 사용해서 지불되는 금액 및/또는 비율을 나타내는 것으로서 해석 가능한 코드를 포함하는 '분할 지불' 토큰이, 기존 지불 프로토콜에 따라서 형식 변경된 지불 토큰 데이터 세트 내의 자유 필드를 사용해서 생성된다. 예컨대, 다수의 기존 지불 프로토콜에 따라서, 지불 토큰 데이터 세트는 다수의 필드를 포함하고, 각각의 필드는 지정된 비트 길이의 분할 데이터 아이템에 대응하며, 지정된 타입, 기능 혹은 의미를 갖고 있다. 예컨대, 지불 토큰은 이하 타입의 필드를 포함할 수 있다.
<token type><issuing FI><currency><value><time stamp>
<issuer ref><discretionary data>
여기서,
<token type> = 신용 토큰, 예금 토큰 등
<issuing FI> = 토큰을 발행했으며 필요시 값을 전달할 FI(120, 920, 2150)와 관련된 고유 코드
<currency> = US 달러, 캐나다 달러, 엔 등
<value> = 토큰 표현에 있는 발행 FI가 지불 가능한 지정된 타입의 통화의 금액
<time stamp> = 토큰 생성 날짜/시간; 옵션으로서 주어진 시간 이후 만료 시간을 결정하는데도 사용 가능함
<issuer ref> = 발행 FI가 생성한 토큰 참조 번호가 예컨대 특정 거래 및/또는 사용자 계좌 등과 연관될 수 있다.
<discretionary data> = 토큰의 생성자가 추가하고자 하는 발행 FI가 해석 가능한 임의의 자유 데이터
이러한 프로토콜에서 자유 데이터 필드는, 소망의 거래 프로세서(120, 160, 920, 1750, 2150 등)가 거래에 대금을 지불하는데 사용되는 다수의 자금원을 나타내고, 사용될 자금원을 나타내며, 자금원 각각으로부터 대금이 지불될 토큰의 값의 비율을 나타내는 것으로서 해석 가능한 임의의 코드를 자유 데이터 필드에 파퓰레이트함으로써, 분할 지불 토큰을 생성하는데 사용될 수 있다. 예컨대, 이러한 필드에 삽입하기에 적합한 코드는 다음 비트를 포함할 수 있다.
<SN/S1/P1/S2/P2/SX/PX>
여기서,
SN = 제시되는 자금원의 번호
S1 = 제 1 자금원 식별자
P1 = 자금원 1에 의해 대금이 지불되는 금액의 비율 혹은 금액
S2 = 제 2 자금원 식별자
P2 = 자금원 2에 의해 대금이 지불되는 금액의 비율 혹은 금액
SX = X번째 자금원의 식별자
PX = 자금원 X에 의해 대금이 지불되는 금액의 비율 혹은 금액
예컨대, 사용자가 대출 계좌로부터 $10, 예금 계좌로부터 $5, 리워드 포인트에서 $20로 $35인 값을 거래에 대한 대금을 지불하고자 하는 상기 예에서, 상기 예에 따라서 형식 변경된 불할 지불 토큰은 이하와 같은 형태로 형성될 수 있다.
<credit><XYZ1234><US><35.00><DDMMYYYHRMN>
<123456><03011002050320>
그 결과, 거래 프로세서(120, 1750, 2150)는 다음과 같이 토큰을 분석할 수 있다.
<token type> = 신용 토큰. 즉 프레젠터(으로부터 수집되는 것이 아닌)에 지불할 돈
<issuing FI> = 코드 번호 XYZ1234와 관련된 은행 혹은 FI
<currency> = US 달러
<value> = 프레젠터에 지불될 $35
<time stamp> = 토큰이 생성된 년도, 월, 일, 시간 및 분
<issuer ref> = 판매자 구매 일련 번호 123456
<slit pay>:
03 => 3개의 자금원이 이 토큰에 대금을 지불하는데 사용됨(자유 필드의 연장된 비트 길이를 설정할 수 있다는 점에 주의)
01 => 생성하는 사용자와 관련된 사용자 프로파일에 나타난 제 1 계좌로, 이 경우 신용 계좌
10 => 사용자의 신용 계좌로부터 $10 USD가 인출됨
02 => 생성하는 사용자와 관련된 사용자 프로파일에 나타난 제 2 계좌로, 이 경우 예금 계좌
05 => 사용자의 예금 계좌로부터 $5 USD가 인출됨
03 => 생성하는 사용자와 관련된 사용자 프로파일에 나타난 제 3 계좌로, 이 경우 리워드 포인트 계좌
20 => 사용자의 리워드 계좌로부터 $20USD의 포인트가 상환됨
당업자라면, 본 개시와 유사하게 만들어진다면, 상기 예는 지불 프로토콜에서 제공되는 자유 필드가 다수의 자금원으로부터 대금이 지불되는 분할 지불 토큰을 구현하는데 사용될 수 있는 방식의 간단한 하나의 비교적 단순한 예라는 것을 이해할 것이다. 폭 넓은 다른 형식이 가능하다.
2110에서 생성된 분할 지불 토큰으로, 2111에서는, 토큰은 2101~2103에서 협상된 거래의 완료로서 월렛 애플리케이션(112, 622)에 의해 판매자 시스템(130, 134 등)으로 라우팅될 수 있고, 판매자 시스템(130, 134 등)은 이를 판매자의 은행과 관련된 거래 프로세서(120)와 같은 지불 프로세서(2150)로 라우팅할 수 있다.
2112에서, 판매자의 은행 혹은 다른 지불 프로세서(2150)는 토큰을 임의의 다른 소망의 정보와 함께, 지불을 위한 토큰과 관련된 지불 프로세서(120, 920, 1760 등)으로 포워딩할 수 있다. 상기 예에서, 예컨대 토큰은 식별자 XYZ1234와 관련된 거래 프로세서로 라우팅될 수 있고, 이는 사용자(190)의 은행이 될 수 있다.
2113에서, 거래 프로세서(120, 1760)는 이 토큰을 분석해서 상술한 바와 같은 분할 지불 명령어를 추출하고, 2114~2117에서, 표시된 값을 충족하기 위해서 포인트를 수집하고, 신용을 연장하며, 토큰에 의해 지정된 금액을 요구불 계좌에 인출하는 처리를 개시할 수 있다. 충분한 자금, 포인트 등의 이용 가능성에 따라서, 2118에서 거래 프로세서(1750)는 예컨대, 상술한 바와 같은 일회용 실시간 신용 계좌를 생성하거나 혹은 제시시에 토큰이 지불 가능한지 확인함으로써 토큰의 지불을 인가할 수 있고, 2120에서, 사용자의 FI(1760) 혹은 다른 거래 프로세서(120)는 거래의 지불을 인가할 수 있다.
이후, 상술한 바와 같이 FI(1760, 2150) 및 판매자 시스템(130) 등을 인가함으로써, 판매자 시스템(130) 및/또는 장치(110, 110') 등은 물론 임의의 다른 소망의 수신자에게 포워딩할 적절한 통지 및 확인이 생성될 수 있다.
상술한 바와 같이, 보안 클라우드 시스템(1750), 포인트 은행 시스템(1752), 대출 기록 원부 시스템(1754), 고객 프로파일(1756), 계좌 원부 기록(1758), 지불 비히클 원부 기록(1760) 및 지불 프로세서(2150) 중 일부 혹은 전체는 하나의 거래 프로세서(120, 160, 920)에 의해서 혹은 다수의 제2자 및 제3자 프로세서(120, 160, 920)에 의해서 동작 혹은 관리될 수 있다.
자유 필드 내의 분할 지불 명령어를 분석할 때, 거래 프로세서(120, 1760)는 임의의 적절한 방법 혹은 프로토콜을 사용할 수 있다. 예컨대, 상기 설명한 예에서, 프로세서(1760)는 도 20의 예로서 도시된 바와 같이 하나 이상의 사용자 혹은 장치 프로파일(2170, 1756)에 액세스할 수 있다. 예컨대, 상술한 바와 같이, 사용자(190)는 분할 지불 거래 지불 처리를 사용하기 이전에, 가상 월렛 애플리케이션(112, 622)을 사용해서 사용자 프로파일(1756)에 액세스해서, 복수의 디폴트 및/또는 다른 선호해서 사용되는 계좌를 지정할 수 있다. 이와 같이 사용자(190) 및/또는 자신의 신뢰된 플랫폼(120)에 의해 사전에 배치함으로써, 자유 필드 내에서의 분할 지불 코드의 사용의 효율 및 기능을 상당히 향상시킬 수 있다.
도 21에 도시된 거래 흐름은 구매 및 다른 거래를 완수하는데 분할 지불 토큰에서 자유 필드가 사용될 수 있는 방식의 일례일 뿐이라는 점에 주의한다. 본 개시에 익숙한 사람들이라면, 폭 넓은 처리가 자유 필드를 사용해서 분할 지불 토큰을 사용하는 것을 가능하게 한다는 것을 이해할 것이다.
특히, 기존의 지불 프로토콜 데이터 필드 내의 자유 필드를 사용함으로써, 분할 지불 토큰이 이미 널리 시중에 사용되는 폭넓은 지불 거래 처리에 사용될 수 있다는 것을 이해할 것이다. 환언하면, 이러한 토큰은 기존 POS '궤도(rails)'에서 분할 지불 처리를 사용하는 것을 가능하게 한다(예컨대, 도 4의 150 참조).
도 22는 지불 '궤도'에서 사용하기에 적합한 다른 처리에서, 본 발명에 따른 분할 지불 실시간 신용 처리(1700)를 구현하는데 적합한 시스템(100, 900)의 컴포넌트(110, 110', 120, 130, 150, 160) 사이의 신호 교환의 세트를 나타내고 있다. 처리(2200)는 도 18을 참조로 설명한다.
도시된 실시예에서, 처리(2200)는 장치(110, 110')의 사용자(190)가 신뢰된 혹은 신뢰되지 않은 월렛 애플리케이션(112, 112')의 사용을 통해서 하나 이상의 중간 자금원('다이나믹 카드'라고도 함)을 사용해서 거래에 대해 지불하는 것을 가능하게 한다. 이러한 처리는 예컨대, 사용자(190)가 다수의 가상 월렛 애플리케이션을 자신의 모바일 혹은 데스크톱 거래 통신 장치(110, 110')에 저장하고 있는 경우에 바람직하게 사용될 수 있다.
도 22의 처리(2200)는 2201에서 시작되며, 여기서 온라인으로 혹은 소매점에서 쇼핑한 사용자(190)는 구매하고자 하는 하나 이상의 아이템을 나타내는 처리를 완수했고 이를 가상 쇼핑 카트에 담았다. 사용자(190)가 자신이 선택한 아이템을 만족하고 지불을 준비하면, 사용자는 월렛 애플리케이션(112, 622)에 액세스해서, 판매자 시스템(130)과 관련된 식별자 및 거래 지불 금액을 나타내는 데이터 및 옵션으로 본 명세서에 개시된 다른 데이터를 포함하는 거래 인가 요청 데이터 세트를 생성할 수 있다.
사용자가 판매자 지불 시스템(130)과 일치하지 않는 소스로부터 인출된 지불로 거래를 완료하고자 하는 예시적인 상황에서, 사용자(190)는 본 명세서에 개시된 방법을 사용해서 대체 혹은 프록시 지불을 포워딩하는 것을 선택할 수도 있다. 예컨대, "PAYWITHURBANK" 커맨드 아이템(1406)(도 14a)을 선택함으로써, 사용자는 제 2의 신뢰된 월렛 애플리케이션(112')을 호출하고, 판매자의 요구와 일치하는 지불 명령어 데이터 세트를 완수하지만 사용자가 원하는 계좌 중 하나 이상으로부터 자금을 인출한다.
예컨대, 2202에서, 사용자는 상술한 바와 같이 일회용 혹은 다른 실시간 여신 한도 지불 계좌와 관련된 거래 자금원 식별을 이용하여 신뢰된 월렛 애플리케이션(112')을 사용해서 '다이나믹 카드' 지불 토큰을 생성할 수 있다. 이러한 다이나믹 카드 토큰은 예컨대, EMV 및/또는 다른 통상 허용되는 지불 프로토콜에 따른 형식의 신용 및/또는 예금 계좌 식별자를 나타내는 데이터를 포함할 수 있다. 그러나, 지불이 이용 가능하고 인가되는 것을 보장하기 위해서, 판매자 시스템(130)에 다이나믹 카드 지불 토큰을 포워딩하기 전에 신뢰된 월렛 애플리케이션(112')은 다이나믹 카드 토큰의 대금을 사전에 지불하는 처리(2203~2215)를 개시할 수 있다.
2203~2207에서, 다이나믹 카드 토큰의 대금을 지불하는 처리는 이용 가능한 지불 옵션을 폴링하고 이를 소망의 분할 지불 방식을 결정하기 위해서 사용자(190)에게 제시하는 처리로 시작될 수 있다.
2203, 1704에서, 예컨대, 사용자의 월렛 애플리케이션(112', 622)은 상술한 바와 같이 사용자(190) 및/또는 장치(110, 110')가 이용 가능한 계좌와 관련된 모든 FI를 폴링하기 위해서 발행 은행 혹은 사용자의 월렛(112', 622)과 관련된 다른 FI나 FSP(1750, 120, 920, 160)에 명령어를 제시하는 신호를 포함하는 거래 지불 자금원 질의 데이터 세트를 생성할 수 있고, 이 질의를 FI 혹은 FSP와 관련된 거래 처리 시스템(1750)으로 라우팅할 수 있다. 도시된 예에서, 관련된 FI 혹은 FSP의 거래 처리 시스템(1750)은 '보안 클라우드'라고 되어 있다.
2204, 1705에서 예컨대, 도 17에 도시된 바와 같이, 1705에서, 관련된 거래 처리 시스템(1750)은, 하나 이상의 고객 로열티, 기프트 혹은 사용자(190) 및/또는 장치(110, 110')와 관련된 다른 현금과 같은 포인트 계좌를 관리하는, 하나 이상의 거래에 대한 체크를 위해 실행 가능한 명령어로서 거래 처리 시스템(120, 160, 1752) "포인트 은행"에 의해 해석 가능한 신호를 포함한 이용 가능한 포인트 질의 데이터 세트를 라우팅할 수 있으며, 이러한 시스템으로부터, 실행되는 거래에 적용할 포인트 시스템을 통해서 이용 가능한 다수의 포인트 및/또는 현금 값을 나타내는 데이터를 포함한 포인트 이용 가능 데이터 세트를 수신할 수 있다.
유사하게, 2205, 1706에서, 관련 거래 처리 시스템(1750)은 사용자(190) 및/또는 장치(110, 110')와 관련된 대출, 여신 한도 혹은 다른 융자 제도나 계좌, 이용 가능한 신용 잔고를 체크하기 위해서 실행 가능한 명령어로서 시스템(1754)이 해석 가능한 신호를 포함하는 이용 가능 신용 질의를 관리하는 "대출 기록 원부(Loan Book of Record)"를 하나 이상의 거래 처리 시스템(1754, 120, 920)에 라우팅할 수 있으며, 이러한 시스템(1754)으로부터 이러한 융자 제도 혹은 계좌를 통해서 이용 가능한 자금 금액을 나타내는 데이터를 포함하는 신용 이용 가능 데이터 세트를 수신할 수 있다.
유사하게, 2206, 1707에서, 관련 거래 처리 시스템(1750)은, 고객 프로파일, 혹은 사용자(190) 및/또는 장치(110, 110')와 관련되어 있으며, 거래(1701~1703)에 대해서 지불 자금원으로서 적용하는데 이용 가능하며, 이러한 목적에 이용 가능한 자금의 값을 체크하기 위해서 실용 가능한 명령어로서 시스템(1756)이 해석 가능한 예금 혹은 요구불 현금 계좌와 관련된 식별자를 나타내는 데이터를 포함하는 다른 데이터 세트를 관리하는, '고객 프로파일'을 하나 이상의 거래 처리 시스템(1756, 120, 920)에 라우팅할 수 있고, 이러한 계좌를 통해서 이용 가능한 자금의 금액을 나타내는 데이터를 포함한 자금 이용 가능 데이터 세트를 이러한 세트로부터 수신할 수 있다. 이러한 고객 프로파일(1756)은 소망 레벨의 이용 가능성 및/또는 보안성을 달성하는데 사용하기에 적합한 임의의 사용자 장치(110, 110') 및/또는 다른 거래 프로세서(120, 160, 920, 150, 130)에 저장되거나 이에 의해 액세스될 수 있다.
모든 이용 가능한 잠재적인 자금원을 폴링함으로써, 2207, 1708에서 관련 거래 처리 시스템(1750)은 1705, 1706, 1707에서 수신한, 포인트 이용 가능 데이터 세트, 신용 이용 가능 데이터 세트 및 자금 이용 가능 데이터 세트를 사용해서, 거래 지불 자금원 옵션 데이터 세트를 생성하고, 이를 요청 월렛 애플리케이션(112, 622)에 반환한다.
수신시에, 요청하는 월렛 애플리케이션(112, 622)은 장치(110, 110')로 하여금, 예컨대, 도 14b, 도 14e 및 도 18b 및 도 18c에 도시된 장치(110, 110')의 사용자가 이용 가능한 지불 옵션을 나타내는 아이템(1404, 1406)을 포함하는 GUI를 생성해서 사용자(190)에게 표시하게 한다. 도 18b에서는 예컨대, UI 아이템(1486, 1810)이 도시되어 있으며, 구매에 적용하는데 262포인트 및 $104.83의 값을 가진 "AVION(R)" Visa(R) 카드 계좌 및 리워드 계좌를 이용 가능하다는 것을 나타낸다. 도 18b에 도시된 실시예에는 또한 UI 아이템(1811, 1812)이 제공되는데, 아이템(1811)은 추가 포인트가 거래에 적용 가능하게 된 경우에 사용자(190)가 포인트 정보를 재생하는 것을 가능하게 하고, 아이템(1812)은 리워드 계좌 및 포인트에 관한 추가 정보에 액세스하는데 사용될 수 있다.
2208, 1709에서, 사용자(190)는 GUI(1407)의 아이템(1404, 1406, 1486, 1810 등)을 사용해서, 1701~1703에서 거래를 정산한 거래 프로세서로 정산하는데 사용하기 위해서 하나 이상의 계좌 혹은 다른 거래 지불 자금원을 지정할 수 있고, 이로써 월렛 앱(112', 622)으로 하여금 상술한 바와 같이 거래 정산 데이터 세트 혹은 거래 인가 요청 데이터 세트를 생성하게 한다.
2209에서, 사용자는 '지불' 아이템(1472: 도 14f)을 선택해서, 1870에서 월렛 앱(112', 622)으로 하여금 거래 정산 데이터 세트 혹은 거래 인가 요청 데이터 세트를 월렛 앱(112)과 관련된 거래 처리 시스템(1750)으로 라우팅하게 하고, 이로써 시스템(1750)은 사용자(190)가 표시한 금액에서 거래 정산 데이터 세트에 나타난 자금원으로부터의 자금을, 2202에서 생성된 다이나믹 카드 요청의 대금을 지불하는데 적용하기 위해 축적하는 처리 1711~1713를 개시하게 한다.
2210~2212에서 자금이 축적되고, 예컨대, 거래 프로세서(1750)는 포이트의 상환(2210, 1711), 대출/신용 청구의 발행(2211, 1712) 및 자금의 송금(2212, 1713)을 위해 명령어를 생성할 수 있고, 2213에서, 2202에서 요청된 다이나믹 카드 토큰을 생성하기 위해서 실시간 신용 계좌에 자금을 적용할 수 있다.
2215에서, 거래 프로세서(1750)는 판매자 시스템(130)에 지불하기 위해서 거래 및 지불 세부 사항과 관련되며 다이나믹 카드 토큰을 생성 및/또는 릴리즈를 인가하는 임의의 유용한 혹은 다른 바람직한 데이터를 포함한 거래 지불 인가 입증 혹은 확인 데이터 시트를 생성해서 월렛 앱(112, 622)으로 라우팅할 수 있다.
2216에서, 신뢰된 월렛 애플리케이션(112', 622)은 지불 처리 및/또는 대금 지불된 다이나믹 카드 토큰의 제어를 사용자가 액세스하는 월렛 애플리케이션(112)으로 반환해서 거래를 완료할 수 있고, 2217에서는 옵션으로 사용자(190)의 확인시에 제3자 월렛(112)은 다이나믹 카드 토큰을 판매자 시스템(134, 136, 130 등)으로 라우팅해서 요청된 거래를 완료할 수 있다.
따라서, 다양한 측면 및 실시예에서, 본 발명은 거래 처리 시스템(120, 160 1750, 2260 등)을 제공하고, 여기서 복수의 거래 지불 자금원 및 판매자에게 지불 가능한 거래 금액 중 복수의 거래 지불 자금원 각각을 이용해서 대금을 지불할 수 있는 부분과 관련된 식별자를 나타내는 데이터를 사용해서, 각각의 자금원과 관련해서 각각의 대응하는 부분을 커버하기에 충분한 자금의 이용 가능성을 검증하게 하는 것은, 거래 인가 데이터 세트에 의해 포함된 적어도 하나의 식별자와 관련된 적어도 하나의 지불 자금원과 관련된 적어도 하나의 제3자 금융 서비스 제공자 시스템(1750, 1754, 1756, 1758, 2260 등)에 판매자에게 지불 가능한 금액 중 대응하는 자금원으로부터의 자금을 사용해서 충족될 부분과 관련된 값을 나타내는 데이터를 포함하는 지불 인가 요청 데이터 세트를 라우팅하는 것과, 거래 인가 데이터 세트에 의해 포함되는 적어도 하나의 식별자와 관련된 적어도 하나의 지불 자금원과 관련된 적어도 하나의 제3자 금융 서비스 제공자 시스템(1750, 1754, 1756, 1758, 2260)으로부터 거래 인가 검증 데이터를 수신하는 것을 포함한다.
따라서, 다양한 측면 및 실시예에서, 본 발명은 사용자(190)가 거래에 대해 지불하기 위해서 선택한 자금원 혹은 자금 타입, 판매자(190)가 자신의 은행(120, 160, 920, 960)으로 정산하기 위해서 사용하는 프로토콜 등에 관계없이 판매자가 지불을 확인할 수 있는 수단을 제공한다. 판매자는 사용자(190)가 궁극적으로 정산헤 사용할 지불의 타입을 인식할 필요도 없다(현금, 신용, 포인트 등).
본 명세서에서 설명한 방법(1300)에 의해 주어질 수 있는 이점 및/또는 많은 장점 중에서, 모바일 사용자는 개시된 각각의 거래에 대한 민감한 개인 정보를 입력 혹은 재입력할 필요없이 판매자 애플리케이션으로부터 직접 거래를 개시할 수 있다는 것이 있다. 판매자 애플리케이션은 증명서 및 프로그램 인터페이스의 사용을 통해서 월렛 애플리케이션으로부터 지불 크리덴셜을 풀링할 수 있다. 나아가, 판매자 애플리케이션이 실제 계좌 번호나 다른 민감한 정보 대신 모바일 월렛으로 제공되는 HCE 토큰을 풀링하기 때문에, 지불 네트워크 내의 판매자 혹은 다른 잠재적인 불안전 개체와 이러한 민감한 정보를 공유하지 않고 모바일 거래는 처리될 수 있다. 모바일 지불에 대한 다른 방식은 설명한 실시예의 이러한 다른 특징을 공유할 수 없다.
따라서, 다양한 측면 및 실시예에서 도 23a~23c에 예로서 도시된 바와 같이, 본 발명은 HCE 부합 거래 토큰 및 크리덴셜을 처리하도록 구성된 시스템(100)을 제공한다.
도 23a에 도시된 실시예에서, 사용자 장치(즉, 거래 요청 통신 장치:110, 110') 상의 판매자 애플리케이션(114)과 함께 동작하도록 구성된 지불 옵션 애플리케이션(116A)에 의해 구현된 처리가 도시되어 있다. 장치(110, 110')는 적어도 하나의 출력 디스플레이 장치(610), 적어도 하나의 사용자 입력 장치(610), 저겅도 하나의 네트워크 통신 시스템(612, 614, 616), 적어도 하나의 데이터 프로세서(602) 및 적어도 하나의 영구 메모리 장치(604, 608, 618)를 포함한다. 적어도 하나의 영구 메모리 장치(604, 608, 618)는 인가된 지불 금액 및 인가된 지불 금액을 인가받은 금융 서비스 제공자(120, 160)와 관련된 데이터를 포함하는 적어도 하나의 보안 지불 토큰, 및 하나 이상의 머신-해석 가능 명령어의 세트를 적어도 나타내는 데이터가 저장되어 있다. 적어도 하나의 데이터 프로세서(602)는 저장되어 있는 하나 이상의 머신-해석 가능 명령어의 세트에 의해 실행될 때, 적어도 하나의 사용자 입력 장치(610)에 의해 생성된 제 1 신호 세트에 응답해서 판매자(136, 136')와 관련되며 거래 요청 통신 장치(110, 110')의 적어도 하나의 영구 메모리 장치(604, 608, 618)에 저장된 머신-해석 가능 명령어의 하나 이상의 세트를 포함하는 판매자 거래 애플리케이션(114)에 의한 처리(즉, 호출)를 개시하기에 적합하고, 판매자 거래 애플리케이션(114)에 의해 포함된 머신 해석 가능 명령어 및 적어도 하나의 사용자 입력 장치(610)에 의해 생성된 적어도 제 2 신호의 세트에 따라서, 판매자(136)와 관련된 식별자 및 판매자에게 지불 가능한 거래 금액을 포함하는 요청된 거래 데이터 세트를 생성하며, 적어도 하나의 출력 디스플레이 스크린(610)을 통해서 판매자 결제 처리 및 가상 월렛 애플리케이션 지불 처리의 사용자 선택을 간청하기에 적합한 인간-해석 가능 사용자 인터페이스(1407)를 표시하며, 하나 이상의 머신 해석 가능 명령어 세트 및 적어도 하나의 보안 지불 토큰을 포함한 가상 월렛 애플리케이션(112)과 관련된 가상 월렛 애플리케이션 처리, 적어도 하나의 사용자 입력 장치(610)로부터 수신한 가상 월렛 애플리케이션 지불 처리의 사용자 선택을 나타내는 제 2 신호 세트에 응답해서, 판매자 거래 애플리케이션(114)으로 하여금 대응하는 가상 월렛 애플리케이션을 폴링하고, 적어도 하나의 보안 지불 토큰과 관련된 지불 크리덴셜을 획득해서 적어도 지불 크리덴셜, 판매자와 관련된 식별자 및 판매자가 지불 가능한 거래 금액을 포함하는 거래 인가 요청 데이터 세트를 생성하게 하며, 적어도 하나의 네트워크 통신 시스템(612, 614, 616)을 사용해서 거래 인가 요청 데이터 세트를 지불 크리덴셜과 관련된 지불 리소스의 소스와 관련된 서버(120, 160)로 라우팅할 수 있다.
도 23b에 도시된 실시예에서, 제 2 FI/FSP(120, 160)과 관련된 가상 월렛 애플리케이션(112)과 함께 동작하도록 구성되지만, 통상적으로는 사용자 장치(즉, 거래 요청 통신 장치)(110, 110') 상의 제 2 FI/FSP(120, 160)에 의해서 제어되거나 관련되지 않는, 제 1 FI/FSP(120, 160)과 관련된 가상 월렛(112, 116B)에 의해 구현된 처리가 도시된다. 장치(110, 110')는 적어도 하나의 사용자 입력 및/또는 출력 장치(610), 적어도 하나의 네트워크 통신 시스템(612, 614, 616); 적어도 하나의 데이터 프로세서(602) 및 적어도 하나의 영구 메모리 장치(604, 608, 618)를 포함한다. 적어도 하나의 영구 메모리 장치(604, 608, 618)에는 복수의 거래 지불 리소스의 소스 중 하나와 관련된 식별자를 나타내는 데이터를 포함하는 복수의 보안 지불 토큰 레퍼런스 및 하나 이상의 머신 해석 가능 명령어 세트를 나타내는 데이터가 저장되어 있다. 적어도 하나의 데이터 프로세서(602)는 머신-해석 가능 명령어의 하나 이상의 저장된 세트의 실행에 의해서, 적어도 하나의 사용자 입력 장치(610)에 의해 생성된 제 1 신호 세트에 응답해서, 판매자와 관련된 식별자 및 판매자에게 지불 가능한 거래 금액을 적어도 포함하는 요청된 거래 데이터 세트를 생성하는 지불 거래 처리에 의한 동작의 실행을 개시하고, 적어도 하나의 사용자 입력 장치(610)에 의해 생성된 제 2 신호 세트에 응답해서, 복수의 보안 지불 토큰 레퍼런스 중 적어도 하나를 포함하고, 및 머신-해석 가능 명령어가 저장되어 있는 제 1 월렛 애플리케이션(112, 116B)를 개시하며, 머신-해석 가능 명령어는 적어도 하나의 출력 디스플레이 스크린(610)을 통해서 요청된 거래의 충족에 적용될 지불 리소스의 복수의 소스 중 하나의 사용자 선택을 간청하기에 적합한 인간-해석 가능 사용자 인터페이스(1407)를 표시하게 하며(지불 리소스의 소스 중 적어도 하나는 복수의 보안 지불 토큰 중 제 1 토큰에 의해 식별된 지불 리소스의 소스와 관련되고, 지불 리소스의 소스 중 적어도 제 2 소스는 복수의 보안 지불 토큰 중 적어도 하나에 의해 식별된 지불 리소스의 소스와 관련이 없음), 관련 거래의 충족에 적용될 지불 리소스의 복수의 소스 중 하나의 사용자 선택을 나타내는 신호를 적어도 하나의 사용자 입력 장치(610)로부터 수신하고, 지불 리소스의 복수의 소스 중 하나의 사용자 선택이 복수이 보안 지불 토큰 중 제 1 토큰에 나타나는 지불 리소스의 소스에 대응하는 경우 복수의 보안 지불 토큰 레퍼런스 중 적어도 제 1 레퍼런스를 포함하는 거래 인가 요청 데이터 세트를 생성하고, 적어도 하나의 네트워크 통신 시스템을 사용해서, 거래 인가 요청 데이터 세트를 복수의 보안 지불 토큰 중 제 1 토큰에 의해 나타내는 지불 리소스의 소스와 관련된 서버(120, 160)로 라우팅한다. 네트워크화된 요청 통신 장치(110, 110')는 또한, 지불 리소스의 복수의 소스 중 하나의 사용자 선택이 복수의 보안 지불 토큰 중 제 1 토큰에 의해 식별된 지불 리소스의 소스에 대응하지 않으면, 제 2 월레 애플리케이션(112)을 개시하되, 제 2 월레 애플리케이션(112)은 복수의 보안 지불 토큰 레퍼런스 중 적어도 제 2 레퍼런스를 포함하고, 머신-해석 가능 명령어가 저장되어 있으며, 머신-해석 가능 명령어는, 동일한 혹은 다른 데이터 프로세서(602)로 하여금 적어도 복수의 보안 지불 토큰 레퍼런스 중 제 2 레퍼런스를 포함하는 거래 인가 요청 데이터를 생성하게 하고, 적어도 하나의 네트워크 통신 시스템을 사용해서, 제 1 혹은 제 2 월렛 애플리케이션에 의해 생성된 거래 인가 요청 데이터 세트를 판매자와 관련된 거래 처리 시스템으로 라우팅하도록 구성된다.
도 23c에 도시된 실시예에서, 가상 월렛 애플리케이션(112) 및/또는 복수의 비FI/FSP 서버(120, 160)와 관련된 FI/FSP 서버(120, 160)과 함께 동작하도록 구성된 네트워크화된 요청 통신 장치(110, 110')의 범용(혹은 '통상') 가상 월렛(112, 116C)에 의해 구현되는 처리가 도시된다. 장치(110, 110')는 적어도 하나의 사용자 입력 및/또는 출력 장치(610)와, 적어도 하나의 네트워크 통신 시스템(612, 614, 616)과, 적어도 하나의 데이터 프로세서(602)와, 적어도 하나의 영구 메모리 장치(604, 608, 618)를 포함한다. 적어도 하나의 영구 메모리 장치(604, 608, 618)에는 적어도 거래 지불 리소스의 복수의 소스(120, 160) 중 하나와 관련된 식별자 및 거래 지불 리소스의 소스와 고유하게 관련된 보안 키를 나타내는 데이터를 각각 포함하는 복수의 보안 지불 토큰 레퍼런스와, 머신 해석 가능 명령어의 하나 이상의 세트를 나타내는 데이터가 저장되어 있다. 적어도 하나의 데이터 프로세서(602)는 저장된 머신 해석 가능 명령어의 하나 이상의 세트에 의해 실행될 때, 적어도 하나의 사용자 입력 장치(610)에 의해 생성된 제 1 신호 세트에 응답해서 요청된 거래 데이터 세트(요청된 거래 데이터 세트는 적어도 판매자(136, 136')와 관련된 식별자 및 판매자에게 지불 가능한 거래 금액을 포함함)를 생성하는 지불 거래 처리에 의한 실행을 개시 혹은 이를 호출하고, 적어도 하나의 사용자 입력 장치(610)에 의해 생성된 제 2 신호 세트에 응답해서 거래 인가 요청 데이터 세트(각각의 거래 인가 요청 데이터 세트는 적어도 보안 지불 토큰 레퍼런스 및 적어도 하나의 거래 지불 금액을 포함함)를 생성하도록 구성된 머신 해석 가능 명령어가 저장되어 있는 범용(혹은 '통상') 가상 월렛(112, 116C)을 개시하며, 적어도 하나의 사용자 입력 장치(610)에 의해 생성된, 거래 지불 리소스의 복수의 소스 중 하나를 나타내는 적어도 사용자 선택을 나타내는 제 2 신호 세트에 응답해서 적어도 거래 지불 리소스의 선택된 소스와 관련된 보안 지불 토큰 및 판매자(136)에게 지불 가능한 거래 금액을 포함하는 거래 인가 요청 데이터 세트를 생성하고, 생성된 거래 인가 데이터 세트를 적어도 하나의 네트워크 통신 시스템(610, 612, 614, 616)을 사용해서 지불 리소스의 식별된 소스와 관련된 서버(120, 160)에 라우팅하기에 적합하다.
도 17c에 따른 일부 실시예에서, 거래 인가 요청 데이터 세트의 생성 및 라우팅은 적어도 하나의 사용자 입력 장치에 의해 생성된 제 4 신호 세트의 적어도 하나의 데이터 프로세서에 의한 수신에 따라서 달라지며, 제 4 신호 세트는 장치의 인가된 사용자와 관련된 적어도 보안 식별자를 포함한다.
도 17c에 따른 일부 실시예에서, 데이터 프로세서(602)는, 동일한 혹은 다른 저장된 머신-실행 가능 명령어의 세트의 실행에 의해서, 동일한 혹은 다른 네트워크 통신 시스템(610, 612, 614, 616)을 사용해서, 지불 리소스의 식별된 소스와 관련된 동일한 혹은 다른 서버(120)로부터, 보안 거래 인가 데이터 세트를 수신하고, 적어도 하나의 통신 시스템(610, 612, 614, 616)의 동일한 혹은 다른 것을 사용해서 보안 거래 인가 데이터 세트를 판매자와 관련된 거래 처리 시스템(136, 136')에 라우팅하기에 적합하다.
본 명세서에 개시된 다른 실시예에 의해 처리되는 것과 같은 도 17a~17c의 실시예 중 일부에 의해 처리된 지불 리소스는, 그 중 하나 혹은 모두가 실제 통화나 가상 통화, 혹은 상환 가능 로열티, 리워드, 혹은 다른 비통화 값 포인트를 포함하는 리소스를 포함할 수 있다.
본 발명의 이러한 측면 및 실시예가 제공하는 다른 이점은, 판매자, FI, FSP 등에 의해 정의되는 광범위한 정황에서의 구매 및 다른 처리 동안에 사용자(190)에게 지불 옵션에 대한 간단한 액세스 및 모바일 및 데스크톱 장치를 포함한 다양한 플랫폼에 대한 통일된 '고객 경험'를 제공하는, 발행 FI/FSP, 판매자 등의 성능을 포함한다. 일부 실시예에서, 장치(110, 110')의 사용자(190)는 자신의 선호에 따라서 경험 중 일부 혹은 모두를 커스토마이징할 수 있다. 상술한 바와 같이, 고객 경험은 판매자 FI, FSP 등이 선호하는 지불 방법과 같은 종래 범위를 넘어서 연장될 수 있다.
상기 설명은 하나 이상의 발명의 다양한 측면 및 예시적인 실시예의 전체 설명을 제공하는 것이다. 따라서, 이러한 발명의 다양한 측면 및/또는 컴포넌트 및 그 특정한 예시적인 조합은 다수의 다양한 레벨 전체에서 설명되었다. 일부 예에서, 실시예는 특정 레벨 및 비교적 일반적인 혹은 대표적인 레벨로 설명되었으며, 예컨대, 실시예의 측면 및 컴포넌트는 상술한 특정한 구조 및/또는 동작과 모순되지 않는 방식으로 변경될 수 있다. 이 예에서, 본 명세서에 개시된 특정 실시예는 상정된 유일한 것이 아닐 수 있으며, 더 일반적인 혹은 대표적인 구성의 유일한 예가 될 수는 있다. 따라서 본 명세서에 개시된 발명의 범주는 다른 의미를 해석하기 위한 적용 가능한 원칙을 고려하면서 첨부된 청구항의 언어에 의해서만 정의된다.
나아가, 관련 기술에 종사하는 사람이라면, 본 발명에 의해서 폭넓은 지불 시스템 및 거래 처리가 가능하다는 것을 이해할 것이다. 다양한 특정 조합 및 실시예를 설명했지만, 간결성 및 명료성을 위한 실질적인 이유로 특정 조합이 설명되지 않았더라도 폭넓은 조합으로 함께 사용될 수 있다는 것을 고려할 수 있다.

Claims (31)

  1. 네트워크 거래 통신 장치로서,
    적어도 하나의 사용자 입력 장치와,
    적어도 하나의 근거리 무선(near-field) 통신 시스템과,
    적어도 하나의 네트워크 통신 시스템과,
    적어도 하나의 데이터 프로세서와,
    머신-해석 가능 명령어가 저장된 적어도 하나의 영구 메모리 장치
    를 포함하되,
    상기 머신-해석 가능 명령어는, 상기 적어도 하나의 데이터 프로세서로 하여금,
    상기 적어도 하나의 사용자 입력 장치에 의해 생성된 신호 및 상기 적어도 하나의 근거리 무선 통신 시스템을 통해서 판매자 거래 시스템으로부터 수신한 신호를 사용해서, 적어도 판매자와 관련된 식별자 및 상기 판매자에게 지불 가능한 거래 금액을 포함하는 요청된 거래 데이터 세트를 생성하게 하고,
    상기 적어도 하나의 사용자 입력 장치에 의해 생성된 추가 신호에 응답해서, 적어도 상기 판매자, 상기 판매자에게 지불 가능한 상기 거래 금액, 적어도 2개의 거래 지불 자금원 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 생성하게 하며,
    상기 적어도 하나의 네트워크 통신 시스템과 상기 근거리 무선 통신 시스템 중 적어도 하나를 사용해서, 상기 거래 인가 요청 데이터 세트를 (신뢰된) 거래 처리 시스템으로 라우팅하게
    하기에 적합하게 되어 있는
    네트워크 거래 통신 장치.
  2. 제 1 항에 있어서,
    적어도 하나의 터치 감응형 입출력 디스플레이 장치를 더 포함하고,
    상기 하나의 영구 메모리 장치에는, 상기 적어도 하나의 데이터 프로세서로 하여금
    상기 장치의 사용자가, 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 지불 자금원 중 적어도 하나를 사용해서 대금이 지불되는 소망의 부분을 지정하는 것을 가능하게 하기에 적합한 인터렉티브 슬라이더 그래픽 장치를, 상기 적어도 하나의 터치 감응형 입출력 디스플레이 장치에 표시하게 하고,
    상기 소망의 부분을 사용자가 지정하는 것에 응답해서 생성된 신호를 사용해서, 동일한 혹은 다른 상기 거래 인가 요청 데이터 세트를 생성하게 하는
    머신-해석 가능 명령어가 더 저장되어 있는,
    네트워크 거래 통신 장치.
  3. 제 1 항에 있어서,
    상기 복수의 거래 지불 자금원은, 적어도 하나의 통화 예금 계좌, 적어도 하나의 통화 신용 계좌 및 적어도 하나의 비통화 값 계좌 중 적어도 임의의 2개를 포함하는
    네트워크 거래 통신 장치.
  4. 제 3 항에 있어서,
    상기 적어도 하나의 통화 예금 계좌 및 적어도 하나의 통화 신용 계좌 중 적어도 하나는 기프트 계좌를 포함하는
    네트워크 거래 통신 장치.
  5. 제 3 항에 있어서,
    상기 적어도 하나의 비통화 값 계좌는 로열티 포인트 계좌, 리워드 포인트 계좌 및 기프트 계좌 중 적어도 하나를 포함하는
    네트워크 거래 통신 장치.
  6. 제 1 항에 있어서,
    상기 복수의 거래 지불 자금원은, 상기 판매자가 거래 지불 자금원으로 인식하지 못하고 있는, 로열티 포인트 계좌, 리워드 포인트 계좌 및 기프트 계좌 중 적어도 하나를 포함하는
    네트워크 거래 통신 장치.
  7. 제 1 항에 있어서,
    상기 생성된 거래 인가 요청 데이터 세트는, 거래 처리 플랫폼에 의해, 상기 판매자에게 지불 가능한 상기 금액이 적어도 하나의 중간 자금원을 사용해서 대금이 지불되게 하는 명령어로서 해석 가능한 데이터를 포함하는
    네트워크 거래 통신 장치.
  8. 제 7 항에 있어서,
    상기 적어도 하나의 중간 자금원은 상기 적어도 2개의 거래 지불 자금원을 나타내는 상기 데이터에 의해 표현되지 않는
    네트워크 거래 통신 장치.
  9. 제 1 항에 있어서,
    상기 거래 인가 요청 데이터 세트는 지불 프로토콜에 따라서 형식이 변경되고,
    상기 지불 프로토콜은 자유 데이터 필드(discretionary data field)를 제공하며,
    상기 자유 데이터 필드는, 상기 적어도 2개의 지불 자금원 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내도록 인코딩된 데이터를 포함하는
    네트워크 거래 통신 장치.
  10. 네트워크 거래 통신 장치로서,
    적어도 하나의 사용자 입력 장치와,
    적어도 하나의 네트워크 통신 시스템과,
    적어도 하나의 데이터 프로세서와,
    머신-해석 가능 명령어가 저장된 적어도 하나의 영구 메모리 장치
    를 포함하되,
    상기 머신-해석 가능 명령어는, 상기 적어도 하나의 데이터 프로세서로 하여금,
    상기 적어도 하나의 네트워크 통신 시스템을 사용해서, 판매자 거래 시스템과의 거래 통신 세션을 성립하게 하고,
    상기 적어도 하나의 사용자 입력 장치에 의해 생성된 신호 및 상기 거래 통신 세션을 통해서 판매자 거래 시스템으로부터 수신한 신호를 사용해서, 적어도 판매자와 관련된 식별자 및 상기 판매자에게 지불 가능한 거래 금액을 포함하는 요청된 거래 데이터 세트를 생성하게 하며,
    상기 적어도 하나의 사용자 입력 장치에 의해 생성된 추가 신호에 응답해서, 적어도 상기 판매자, 상기 판매자에게 지불 가능한 상기 거래 금액, 적어도 2개의 거래 지불 자금원 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 생성하게 하며,
    상기 적어도 하나의 네트워크 통신 시스템과 상기 적어도 하나의 데이터 프로세서 중 적어도 하나를 사용해서, 상기 거래 인가 요청 데이터 세트를 거래 처리 시스템으로 라우팅하게
    하기에 적합하게 되어 있는
    네트워크 거래 통신 장치.
  11. 제 10 항에 있어서,
    상기 거래 통신 세션은, 저장된, 판매자 거래 애플리케이션과 관련된 머신-해석 가능 명령어의 실행에 의해서 성립되는
    네트워크 거래 통신 장치.
  12. 제 10 항에 있어서,
    상기 거래 통신 세션은, 저장된, 네트워크 브라우저 애플리케이션과 관련된 머신-해석 가능 명령어의 실행에 의해서 성립되는
    네트워크 거래 통신 장치.
  13. 제 11 항에 있어서,
    상기 복수의 거래 지불 자금원은, 적어도 하나의 통화 예금 계좌, 적어도 하나의 통화 신용 계좌 및 적어도 하나의 비통화 값 계좌 중 적어도 임의의 2개를 포함하는
    네트워크 거래 통신 장치.
  14. 제 12 항에 있어서,
    상기 적어도 하나의 통화 예금 계좌 및 적어도 하나의 통화 신용 계좌 중 적어도 하나는 기프트 계좌를 포함하는
    네트워크 거래 통신 장치.
  15. 제 12 항에 있어서,
    상기 적어도 하나의 비통화 값 계좌는 로열티 포인트 계좌, 리워드 포인트 계좌 및 기프트 계좌 중 적어도 하나를 포함하는
    네트워크 거래 통신 장치.
  16. 제 10 항에 있어서,
    상기 복수의 거래 지불 자금원은, 상기 판매자가 거래 지불 자금원으로 인식하지 못하고 있는, 로열티 포인트 계좌, 리워드 포인트 계좌 및 기프트 계좌 중 적어도 하나를 포함하는
    네트워크 거래 통신 장치.
  17. 제 10 항에 있어서,
    상기 생성된 거래 인가 요청 데이터 세트는, 거래 처리 플랫폼에 의해, 상기 판매자에게 지불 가능한 상기 금액이 적어도 하나의 중간 자금원을 사용해서 대금이 지불되게 하는 명령어로서 해석 가능한 데이터를 포함하는
    네트워크 거래 통신 장치.
  18. 제 17 항에 있어서,
    상기 적어도 하나의 중간 자금원은 상기 적어도 2개의 거래 지불 자금원을 나타내는 상기 데이터에 의해 표현되지 않는
    네트워크 거래 통신 장치.
  19. 제 10 항에 있어서,
    상기 거래 인가 요청 데이터 세트는 지불 프로토콜에 따라서 형식이 변경되고,
    상기 지불 프로토콜은 자유 데이터 필드를 제공하며,
    상기 자유 데이터 필드는, 상기 적어도 2개의 지불 자금원 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내도록 인코딩된 데이터를 포함하는
    네트워크 거래 통신 장치.
  20. 거래 처리 시스템으로서,
    적어도 하나의 네트워크 통신 시스템과,
    적어도 하나의 데이터 프로세서와,
    머신-해석 가능 명령어가 저장된 적어도 하나의 영구 메모리 장치
    를 포함하되,
    상기 머신-해석 가능 명령어는, 상기 적어도 하나의 데이터 프로세서로 하여금,
    상기 적어도 하나의 네트워크 통신 시스템을 이용해서, 네트워크 거래 통신 장치로부터, 적어도 판매자와 관련된 식별자, 상기 판매자에게 지불 가능한 거래 금액, 복수의 거래 지불 자금원과 관련된 식별자 및 상기 판매자에게 지불 가능한 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 수신하게 하고,
    상기 복수의 거래 지불 자금원 및 상기 판매자에게 지불 가능한 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 상기 부분과 관련된 식별자를 나타내는 데이터를 사용해서, 상기 각각의 자금원과 관련해서 각각의 대응하는 부분을 커버하기에 충분한 자금의 이용 가능성을 검증하게 하며,
    동일한 혹은 다른 네트워크 통신 시스템을 사용해서, 상기 판매자에게 지불 가능한 거래 금액의 지불의 인가를 나타내는 데이터를 포함하는 적어도 하나의 거래 지불 인가 데이터 세트를, 상기 네트워크 거래 장치 및 상기 판매자와 관련된 판매자 거래 시스템 중 적어도 하나로 라우팅하게
    하기에 적합하게 되어 있는
    거래 처리 시스템.
  21. 제 20 항에 있어서,
    상기 복수의 거래 지불 자금원 및 상기 판매자에게 지불 가능한 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 상기 부분과 관련된 식별자를 나타내는 데이터를 사용해서, 상기 각각의 자금원과 관련해서 각각의 대응하는 부분을 커버하기에 충분한 자금의 이용 가능성을 검증하게 하는 것은,
    상기 거래 인가 데이터 세트에 의해 포함된 적어도 하나의 식별자와 관련된 적어도 하나의 지불 자금원과 관련된 적어도 하나의 제3자 금융 서비스 제공자 시스템에, 상기 판매자에게 지불 가능한 금액 중 상기 대응하는 자금원으로부터의 자금을 사용해서 충족될 부분과 관련된 값을 나타내는 데이터를 포함하는 지불 인가 요청 데이터 세트를 라우팅하는 것과,
    상기 거래 인가 데이터 세트에 의해 포함되는 적어도 하나의 식별자와 관련된 적어도 하나의 지불 자금원과 관련된 상기 적어도 하나의 제3자 금융 서비스 제공자 시스템으로부터 거래 인가 검증 데이터를 수신하는 것
    을 포함하는
    거래 처리 시스템.
  22. 제 21 항에 있어서,
    상기 적어도 하나의 제3자 금융 서비스 제공자 시스템과 관련된 상기 적어도 하나의 자금원은, 로열티 포인트 계좌, 리워드 포인트 계좌 및 기프트 계좌 중 적어도 하나를 포함하고,
    상기 적어도 하나의 자금원은, 상기 판매자가 거래 지불 자금원으로 인식하지 못하고 있는 것인
    거래 처리 시스템.
  23. 제 20 항에 있어서,
    상기 거래 인가 요청 데이터 세트는 지불 프로토콜에 따라서 형식이 변경되고,
    상기 지불 프로토콜은 자유 데이터 필드를 제공하며,
    상기 자유 데이터 필드는, 상기 적어도 2개의 지불 자금원 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내도록 인코딩된 데이터를 포함하는
    거래 처리 시스템.
  24. 거래 처리 시스템으로서,
    적어도 하나의 네트워크 통신 시스템과,
    적어도 하나의 데이터 프로세서와,
    머신-해석 가능 명령어가 저장된 적어도 하나의 영구 메모리 장치
    를 포함하되,
    상기 머신-해석 가능 명령어는, 상기 적어도 하나의 데이터 프로세서로 하여금,
    상기 적어도 하나의 네트워크 통신 시스템을 이용해서, 네트워크 거래 통신 장치로부터, 적어도 판매자와 관련된 식별자, 상기 판매자에게 지불 가능한 거래 금액, 복수의 거래 지불 자금원과 관련된 식별자 및 상기 판매자에게 지불 가능한 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 부분을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 수신하게 하고,
    상기 판매자와 관련된 식별자 및 상기 판매자에게 지불 가능한 거래 금액을 이용해서, 상기 판매자와 관련된 동일한 혹은 다른 판매자 거래 시스템으로, 중간 지불 자금원을 나타내는 데이터를 포함하는 판매자 거래 지불 인가 데이터 세트를 라우팅하게 하며,
    복수의 거래 지불 자금원과 관련된 상기 식별자 및 상기 판매자에게 지불 가능한 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 이용해서 대금이 지불되는 부분을 사용해서, 상기 중간 지불 자금원을 사용해서 대금이 지불되는 지불이 상기 복수의 지불 자금원을 사용해서 충족되게
    하기에 적합하게 되어 있는
    거래 처리 시스템.
  25. 제 24 항에 있어서,
    상기 중간 지불 자금원은 상기 판매자 거래 지불 인가 데이터 세트에 포함되는 데이터에 의해 표현되는 상기 복수의 지불 자금원 중 하나가 아닌
    거래 처리 시스템.
  26. 제 25 항에 있어서,
    상기 중간 지불 자금원은 다이나믹 자금원 식별자에 의해 표현되는
    거래 처리 시스템.
  27. 제 26 항에 있어서,
    상기 중간 지불 자금원은 여신 한도(line of credit)인
    거래 처리 시스템.
  28. 제 24 항에 있어서,
    상기 거래 인가 요청 데이터 세트는 지불 프로토콜에 따라서 형식이 변경되고,
    상기 지불 프로토콜은 자유 데이터 필드를 제공하며,
    상기 자유 데이터 필드는, 상기 적어도 2개의 지불 자금원 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내도록 인코딩된 데이터를 포함하는
    거래 처리 시스템.
  29. 거래 처리 시스템으로서,
    적어도 하나의 네트워크 통신 시스템과,
    적어도 하나의 데이터 프로세서와,
    머신-해석 가능 명령어가 저장된 적어도 하나의 영구 메모리 장치
    를 포함하되,
    상기 머신-해석 가능 명령어는, 상기 적어도 하나의 데이터 프로세서로 하여금,
    상기 적어도 하나의 네트워크 통신 시스템을 이용해서, 네트워크 거래 통신 장치로부터, 적어도 판매자와 관련된 식별자, 상기 판매자에게 지불 가능한 거래 금액 및 구매 거래 자금원을 나타내는 데이터를 포함하는 거래 인가 요청 데이터 세트를 수신하게 하고,
    상기 판매자와 관련된 식별자 및 상기 판매자에게 지불 가능한 거래 금액을 이용해서, 상기 판매자와 관련된 동일한 혹은 다른 판매자 거래 시스템으로, 중간 지불 자금원을 나타내는 데이터를 포함하는 판매자 거래 지불 인가 데이터 세트를 라우팅하게 하며,
    상기 판매자와 관련된 식별자 및 상기 판매자에게 지불 가능한 상기 거래 금액을 이용해서, 상기 판매자 및 상기 네트워크 거래 통신 장치 중 적어도 하나로, 상기 판매자에게 지불 가능한 거래 금액에 대한 중간 지불 자금원과 관련된 식별자를 나타내는 데이터를 포함하는 판매자 거래 지불 인가 데이터 세트를 라우팅하게 하며,
    상기 구매 거래 자금원과 관련된 계좌로부터 상기 중간 지불 자금원과 관련된 계좌로의 송금의 인가, 복수의 거래 지불 자금원에 대한 보상, 및 상기 판매자에게 지불 가능한 상기 거래 금액 중 상기 복수의 거래 지불 자금원 각각을 사용해서 대금이 지불되는 부분을 나타내는 데이터를 포함하는 거래 정산 데이터 세트를 생성하게 하며,
    이로써, 상기 중간 지불 자금원을 사용해서 대금이 지불되는 지불이 상기 복수의 지불 자금원을 사용해서 충족되게
    하기에 적합하게 되어 있는
    거래 처리 시스템.
  30. 제 31 항에 있어서,
    상기 중간 지불 자금원은 다이나믹 자금원 식별자에 의해 표현되는
    거래 처리 시스템.
  31. 제 32 항에 있어서,
    상기 중간 지불 자금원은 여신 한도인
    거래 처리 시스템.
KR1020187003235A 2015-07-02 2016-07-04 전자 지불의 보안 처리 KR102619230B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201562188067P 2015-07-02 2015-07-02
US62/188,067 2015-07-02
US201562200859P 2015-08-04 2015-08-04
US62/200,859 2015-08-04
US15/000,685 2016-01-19
US15/000,685 US11080700B2 (en) 2015-01-19 2016-01-19 Secure processing of electronic payments
PCT/CA2016/000186 WO2017000061A1 (en) 2015-07-02 2016-07-04 Secure processing of electronic payments

Publications (2)

Publication Number Publication Date
KR20180026498A true KR20180026498A (ko) 2018-03-12
KR102619230B1 KR102619230B1 (ko) 2023-12-28

Family

ID=57607440

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187003235A KR102619230B1 (ko) 2015-07-02 2016-07-04 전자 지불의 보안 처리

Country Status (6)

Country Link
EP (1) EP3317833A4 (ko)
KR (1) KR102619230B1 (ko)
AU (2) AU2016287789A1 (ko)
CA (1) CA2991073A1 (ko)
HK (1) HK1255245A1 (ko)
WO (1) WO2017000061A1 (ko)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10185993B2 (en) 2014-08-22 2019-01-22 Iex Group, Inc. Dynamic peg orders in an electronic trading system
US10311515B2 (en) 2014-09-17 2019-06-04 Iex Group, Inc. System and method for a semi-lit market
KR101996840B1 (ko) * 2018-12-07 2019-07-05 아콘소프트 주식회사 마이크로서비스 스토어 운영시스템
US10346910B2 (en) 2014-04-16 2019-07-09 Iex Group, Inc. Systems and methods for providing up-to-date information for transactions
US10467694B2 (en) 2012-09-12 2019-11-05 Iex Group, Inc. Transmission latency leveling apparatuses, methods and systems
US10678694B2 (en) 2016-09-02 2020-06-09 Iex Group, Inc. System and method for creating time-accurate event streams
US10706470B2 (en) 2016-12-02 2020-07-07 Iex Group, Inc. Systems and methods for processing full or partially displayed dynamic peg orders in an electronic trading system
KR20200096055A (ko) 2019-02-01 2020-08-11 김용태 블록체인 네트워크를 이용한 여신거래 서버 및 방법
US11537455B2 (en) 2021-01-11 2022-12-27 Iex Group, Inc. Schema management using an event stream
US20230230067A1 (en) * 2022-01-20 2023-07-20 VocaLink Limited Tokenized control of personal data

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10402829B1 (en) * 2016-09-09 2019-09-03 Worldpay, Llc Systems and methods for using shared databases for managing supplemental payment sources
US10423947B1 (en) * 2016-09-09 2019-09-24 Worldpay, Llc User interfaces for using shared databases for managing supplemental payment sources
BR112019008759A2 (pt) * 2016-11-01 2019-07-09 Entersekt International Ltd verificação de uma associação entre um dispositivo de comunicação e um usuário
US10769602B2 (en) 2017-01-03 2020-09-08 Soo Hyang KANG System and method for customer initiated payment transaction using customer's mobile device and card
US10769612B2 (en) 2017-01-03 2020-09-08 Soo Hyang KANG System and method for customers initiated payment transaction using customer's mobile device and card
US11625708B2 (en) 2017-01-03 2023-04-11 Soo Hyang KANG System and method for customer initiated payment transaction using customer's mobile device and card
CN110678888B (zh) * 2017-05-25 2024-01-02 姜秀享 客户发起的支付交易系统和方法
US20190066089A1 (en) * 2017-08-25 2019-02-28 Mastercard International Incorporated Secure transactions using digital barcodes
CN108241979B (zh) * 2017-12-20 2021-03-16 深圳壹账通智能科技有限公司 基于区块链的多账本转账方法、电子装置及可读存储介质
WO2019245514A1 (en) * 2018-06-22 2019-12-26 Lisin Mykyta Mykolaiovych A method for protecting access to a cryptocurrency wallet
US11636473B2 (en) * 2018-11-08 2023-04-25 International Business Machines Corporation Altering account numbers into invalid account numbers for secure transmission and storage
CN109936570B (zh) * 2019-02-21 2021-05-28 领信智链(北京)科技有限公司 一种基于以太坊区块链的去中心化标识符属性管理系统
US11605076B2 (en) * 2019-04-01 2023-03-14 The Toronto-Dominion Bank Reconciliation of indirectly executed exchanges of data using permissioned distributed ledgers
CN111061573A (zh) * 2019-11-15 2020-04-24 北京三快在线科技有限公司 资源转移方法、装置、电子设备及存储介质
CN112215588B (zh) * 2020-09-25 2024-04-30 中国建设银行股份有限公司 一种路由切换方法、银证管理系统、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120031969A1 (en) * 2009-05-15 2012-02-09 Ayman Hammad Integration of verification tokens with mobile communication devices
CA2837208A1 (en) * 2011-05-31 2012-12-06 Blackhawk Network, Inc. A system for payment via electronic wallet
US20120316992A1 (en) * 2011-06-07 2012-12-13 Oborne Timothy W Payment privacy tokenization apparatuses, methods and systems
US20130041823A1 (en) * 2011-08-08 2013-02-14 Kim Wagner Payment Card with Integrated Chip
WO2013158419A1 (en) * 2012-04-18 2013-10-24 Google Inc. Processing payment transactions without a secure element

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2767110A4 (en) * 2011-10-12 2015-01-28 C Sam Inc PLATFORM FOR MULTI-STAGE SECURE MOBILE TRANSACTIONS
US20130339188A1 (en) * 2012-06-18 2013-12-19 Ebay Inc. Gift token
US9043609B2 (en) * 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
US9082119B2 (en) * 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120031969A1 (en) * 2009-05-15 2012-02-09 Ayman Hammad Integration of verification tokens with mobile communication devices
CA2837208A1 (en) * 2011-05-31 2012-12-06 Blackhawk Network, Inc. A system for payment via electronic wallet
US20120316992A1 (en) * 2011-06-07 2012-12-13 Oborne Timothy W Payment privacy tokenization apparatuses, methods and systems
US20130041823A1 (en) * 2011-08-08 2013-02-14 Kim Wagner Payment Card with Integrated Chip
WO2013158419A1 (en) * 2012-04-18 2013-10-24 Google Inc. Processing payment transactions without a secure element

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11568485B2 (en) 2012-09-12 2023-01-31 Iex Group, Inc. Transmission latency leveling apparatuses, methods and systems
US10467694B2 (en) 2012-09-12 2019-11-05 Iex Group, Inc. Transmission latency leveling apparatuses, methods and systems
US10346910B2 (en) 2014-04-16 2019-07-09 Iex Group, Inc. Systems and methods for providing up-to-date information for transactions
US11423479B2 (en) 2014-08-22 2022-08-23 lEX Group, Inc. Dynamic peg orders in an electronic trading system
US10185993B2 (en) 2014-08-22 2019-01-22 Iex Group, Inc. Dynamic peg orders in an electronic trading system
US11030692B2 (en) 2014-09-17 2021-06-08 Iex Group, Inc. System and method for a semi-lit market
US10311515B2 (en) 2014-09-17 2019-06-04 Iex Group, Inc. System and method for a semi-lit market
US10678694B2 (en) 2016-09-02 2020-06-09 Iex Group, Inc. System and method for creating time-accurate event streams
US10706470B2 (en) 2016-12-02 2020-07-07 Iex Group, Inc. Systems and methods for processing full or partially displayed dynamic peg orders in an electronic trading system
KR101996840B1 (ko) * 2018-12-07 2019-07-05 아콘소프트 주식회사 마이크로서비스 스토어 운영시스템
KR20200096055A (ko) 2019-02-01 2020-08-11 김용태 블록체인 네트워크를 이용한 여신거래 서버 및 방법
US11537455B2 (en) 2021-01-11 2022-12-27 Iex Group, Inc. Schema management using an event stream
US20230230067A1 (en) * 2022-01-20 2023-07-20 VocaLink Limited Tokenized control of personal data

Also Published As

Publication number Publication date
AU2016287789A1 (en) 2018-02-01
EP3317833A4 (en) 2019-03-20
EP3317833A1 (en) 2018-05-09
KR102619230B1 (ko) 2023-12-28
AU2022202404A1 (en) 2022-05-05
WO2017000061A1 (en) 2017-01-05
HK1255245A1 (zh) 2019-08-09
CA2991073A1 (en) 2017-01-05

Similar Documents

Publication Publication Date Title
AU2022201325B2 (en) Secure processing of electronic payments
KR102619230B1 (ko) 전자 지불의 보안 처리
US20220391883A1 (en) System and method for location-based token transaction processing
US11080701B2 (en) Secure processing of electronic payments
US11676129B2 (en) Offline bill splitting system
US11854010B2 (en) Authorization of cardless payment transactions
US20230196355A1 (en) Processing of electronic transactions
US20180253727A1 (en) Secure funding of electronic payments
US11699152B2 (en) Secure processing of electronic payments
CA3007992A1 (en) System and method for location-based token transaction processing
CA3052074A1 (en) Secure funding of electronic payments
CA3030440A1 (en) Processing of electronic transactions
US20120233021A1 (en) Online Transaction System

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant