KR20210095121A - 신용 계좌를 사용한 이체 - Google Patents

신용 계좌를 사용한 이체 Download PDF

Info

Publication number
KR20210095121A
KR20210095121A KR1020217011116A KR20217011116A KR20210095121A KR 20210095121 A KR20210095121 A KR 20210095121A KR 1020217011116 A KR1020217011116 A KR 1020217011116A KR 20217011116 A KR20217011116 A KR 20217011116A KR 20210095121 A KR20210095121 A KR 20210095121A
Authority
KR
South Korea
Prior art keywords
account
funds
recipient
credit
request
Prior art date
Application number
KR1020217011116A
Other languages
English (en)
Inventor
매니쉬 델리와라
패트릭 도스탈
아닐 두아
아담 크로착
무쿤드 샨카 심하 라구
바이그네쉬 비라이얀
Original Assignee
아메리칸 익스프레스 트레블 릴레이티드 서비스즈 컴퍼니, 아이엔씨.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아메리칸 익스프레스 트레블 릴레이티드 서비스즈 컴퍼니, 아이엔씨. filed Critical 아메리칸 익스프레스 트레블 릴레이티드 서비스즈 컴퍼니, 아이엔씨.
Publication of KR20210095121A publication Critical patent/KR20210095121A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482—Interaction with lists of selectable items, e.g. menus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Hardware Design (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Medicinal Preparation (AREA)

Abstract

신용 계좌들을 사용한 이체들에 대한 다양한 실시예들이 개시된다. 특정 금액의 자금들을 특정 신용 계좌로부터 수령인에게 송신하기 위한 요청이 제1 클라이언트 디바이스로부터 수신된다. 특정 금액의 자금들을 수령인에게 송신하기 위한 요청에 대한 거래 식별자는 컴퓨팅 디바이스로부터 요청된다. 제1 통지는 제2 클라이언트 디바이스로 송신되며, 여기서 제1 통지는 거래 식별자를 포함하고 제2 클라이언트 디바이스는 수령인과 연관된다. 수령인이 특정 금액의 자금들을 수락하였다는 제2 통지는 클라이언트 디바이스로부터 수신된다. 그 다음, 자금 이체는 특정 금액의 자금들에 대해 통화 계좌로 개시된다.

Description

신용 계좌를 사용한 이체
관련 출원들에 대한 교차 참조
본 출원은 발명의 명칭이 PEER-TO-PEER INTERBANK TRANSFERS USING CREDIT ACCOUNTS이고 2018년 10월 17일자로 출원된 미국 가특허 출원 번호 제62/746,866호에 대한 우선권, 및 그 이익을 주장하며, 이는 그 전체가 본원에 진술된 바와 같이 참고로 통합된다.
많은 개인들은 아이템들 또는 서비스들에 대한 대금을 지불하기 위해 신용 카드 계좌들을 갖는다. 신용 카드 보유자가 지불할 때, 그 또는 그녀는 상인에게 그 또는 그녀의 정보를 제공한다. 상인은, 결과적으로, 신용 카드 정보를 신용 카드 거래(transaction) 네트워크에 제출하며, 이는 거래 정보를 신용 카드 보유자의 발행 은행으로 라우팅한다. 발행 은행은 거래에 대해 각각의 신용 카드를 인출(debit) 또는 청구(charge)하고 그 다음 결과적으로 상인의 은행에 지불을 제공하는 네트워크에 지불을 제공할 수 있다. 그러나, 신용 카드 보유자는 신용 카드 거래 네트워크에 대한 액세스로 임의의 상인에게 지불할 수 있지만, 지급인은 그 또는 그녀의 신용 카드로 다른 신용 카드 보유자들 또는 비-상인들에게 지불할 수 없다. 유사하게, 상인은 임의의 고객으로부터 자금을 수령할 수 있지만, 상인은 특정 거래를 환불하는 경우를 제외하고 다른 상인들 또는 고객들에게 지불할 수 없다. 더욱이, 신용 카드 거래 네트워크들의 사용은 종종 다른 결제 레일들에 비해 더 높은 수수료들과 연관된다.
본 개시의 많은 양태들은 다음의 도면들을 참조하여 더 양호하게 이해될 수 있다. 도면들의 구성요소들은 반드시 축적에 따라 도시되는 것은 아니며, 본 개시의 원리들을 명백히 예시하는 데 중점을 두고 있다. 더욱이, 도면들에서, 유사한 참조 번호들은 수 개의 뷰들 전체에 걸쳐 대응하는 부분들을 지정한다.
도 1a 내지 도 1r은 본 개시의 다양한 실시예들에 따른 클라이언트에 의해 렌더링되는 사용자 인터페이스들의 예들의 그림을 이용한 다이어그램들이다.
도 2는 본 개시의 다양한 실시예들에 따른 네트워크 환경의 도면이다.
도 3 내지 도 5는 본 개시의 다양한 실시예들에 따른 도 2의 네트워크 환경의 컴퓨팅 환경에서 실행되는 애플리케이션의 부분들로서 구현되는 기능의 예들을 예시하는 시퀀스 다이어그램들이다.
도 6a 및 도 6b는 본 개시의 다양한 실시예들에 따른 도 2의 네트워크 환경의 컴퓨팅 환경에서 실행되는 애플리케이션의 부분들로서 구현되는 기능의 예들을 예시하는 시퀀스 다이어그램들이다.
도 7a 및 도 7b는 본 개시의 다양한 실시예들에 따른 도 2의 네트워크 환경의 컴퓨팅 환경에서 실행되는 애플리케이션의 부분들로서 구현되는 기능의 예들을 예시하는 시퀀스 다이어그램들이다.
도 8 및 도 9는 본 개시의 다양한 실시예들에 따른 도 2의 네트워크 환경의 컴퓨팅 환경에서 실행되는 애플리케이션의 부분들로서 구현되는 기능의 예들을 예시하는 시퀀스 다이어그램들이다.
본 개시의 다양한 실시예들은 시스템을 포함하며, 시스템은: 프로세서 및 메모리를 포함하는 제1 컴퓨팅 디바이스; 및 메모리에 저장되는 머신-판독가능 명령들을 포함하며, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가 적어도: 제1 컴퓨팅 디바이스로부터 메시지 - 메시지는 자금 이체 및 자금 이체에 링크되는 거래 식별자의 통지를 포함함 -를 수신하고; 제3 컴퓨팅 디바이스로 자금 이체를 처리하기 위한 요청 - 요청은 자금 이체를 위한 거래 식별자, 계좌 식별자 및 기관 식별자를 포함함 -을 송신하게 한다.
시스템의 하나 이상의 실시예들에서, 메모리에 저장되는 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가 적어도: 자금 이체가 완료되었다는 표시를 수신하고; 제1 컴퓨팅 디바이스의 디스플레이 상에, 자금 이체가 완료되었다는 표시를 렌더링하게 한다. 시스템의 하나 이상의 실시예들에서, 거래 식별자는 메시지에 포함되는 URI(uniform resource indicator) 내에 포함되고, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 적어도: URI에 어드레스되는 제1 요청을 송신하고; 제1 요청에 응답하여 기관들의 리스트를 수신하고; 기관들의 리스트로부터 기관의 선택에 응답하여, 기관에 대한 인증 크리덴셜들을 위한 제2 요청을 수신하고; 인증 크리덴셜들의 제출에 응답하여, 기관들의 리스트로부터 선택되는 기관에 의해 유지되는 통화 계좌들의 리스트를 수신하게 한다. 시스템의 하나 이상의 실시예들에서, 제1 컴퓨팅 디바이스는 디스플레이 및 머신-판독가능 명령들을 포함하며, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 적어도: 디스플레이에 의해 렌더링되는 사용자 인터페이스 내에, 통화 계좌들의 리스트를 제시하고; 통화 계좌들의 리스트로부터 통화 계좌의 선택에 응답하여, 자금 이체를 처리하기 위한 요청에서 통화 계좌에 대한 계좌 식별자를 포함하게 한다. 시스템의 하나 이상의 실시예들에서, 머신-판독가능 명령들은 추가로 제1 컴퓨팅 디바이스가 적어도: 제1 컴퓨팅 디바이스의 디스플레이 상에 제시되는 사용자 인터페이스 내에, 자금 이체를 확인하기 위한 프롬프트(prompt)를 렌더링하고; 자금 이체를 처리하기 위한 요청이 자금 이체의 확인에 응답하여 송신되게 한다. 시스템의 하나 이상의 실시예들에서, 메시지는 단문 메시지 서비스(short message service; SMS) 메시지이다.
본 개시의 다양한 실시예들은 방법을 포함하며, 방법은: 제1 클라이언트 디바이스로부터, 특정 금액의 자금들을 특정 신용 계좌로부터 수령인에게 송신하기 위한 요청을 수신하는 단계; 컴퓨팅 디바이스로부터, 특정 금액의 자금들을 수취인에게 송신하기 위한 요청에 대한 거래 식별자를 요청하는 단계; 제1 통지를 제2 클라이언트 디바이스에게 송신하는 단계 - 제1 통지는 거래 식별자를 포함하고 제2 클라이언트 디바이스는 수령인과 연관됨 -; 컴퓨팅 디바이스로부터, 수령인이 특정 금액의 자금들을 수락했다는 제2 통지를 수신하는 단계 - 제2 통지는 통화 계좌를 식별함 -; 및 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계를 포함한다. 하나 이상의 실시예들에서, 방법은 추가로 특정 신용 계좌로부터 특정 금액의 자금들을 인출하는 단계를 포함한다. 본 발명의 하나 이상의 실시예들에서, 특정 금액의 자금들을 위한 통화 계좌로 자금 이체를 개시하는 단계는 실시간 총액 결제(real-time gross settlement; RTGS) 시스템을 통해 지불을 개시하는 단계를 더 포함한다. 본 발명의 하나 이상의 실시예들에서, 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계는 추가로 일괄 처리된, 순 결제 네트워크를 통해 지불을 개시하는 단계를 포함한다. 본 발명의 하나 이상의 실시예들에서, 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계는 특정 금액의 자금들에 대해 에스크로 계좌(escrow account)로부터 통화 계좌로 지불을 개시하는 단계를 더 포함한다. 본 발명의 하나 이상의 실시예들에서, 특정 금액의 자금들을 특정 신용 계좌로부터 수령인에게 송신하기 위한 요청은 수령인에 대한 연락처 정보를 더 포함하고; 제1 통지를 제2 클라이언트 디바이스에게 송신하는 단계는 제1 통지를 연락처 정보에 특정되는 목적지로 송신하는 단계를 더 포함한다. 하나 이상의 실시예들에서, 방법은 거래 식별자를 포함하는 URI(uniform resource indicator)를 생성하는 단계; 및 제1 통지에 URI를 포함하는 단계를 더 포함한다. 본 발명의 하나 이상의 실시예들에서, 제2 통지는 거래 식별자를 더 포함한다. 하나 이상의 실시예들에서, 방법은 메시지를 제1 클라이언트 디바이스에 송신하는 단계를 더 포함하며, 메시지는 수령인이 특정 금액의 자금들을 수락하였다는 것을 나타낸다.
본 개시의 다양한 실시예들은 머신-판독가능 명령들을 포함하는 비-일시적 컴퓨터-판독가능 매체를 포함하며, 머신-판독가능 명령들은, 제1 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가 적어도: 클라이언트 디바이스로부터 자금 이체를 처리하기 위한 요청 - 요청은 거래 식별자를 포함함 -을 수신하고; 기관들의 리스트를 클라이언트 디바이스에 제공하고; 클라이언트 디바이스로부터, 기관들의 리스트로부터 기관의 제1 선택을 수신하고; 클라이언트 디바이스로부터, 기관들의 리스트로부터 선택되는 기관에 대한 인증 크리덴셜을 요청하고; 인증 크리덴셜들의 수령(receipt)에 응답하여, 클라이언트 디바이스에게 기관들의 리스트로부터 선택되는 기관과 연관되는 계좌들의 리스트를 제공하고; 계좌들의 리스트로부터 계좌의 제2 선택을 수신하고; 제2 컴퓨팅 디바이스에게, 거래 식별자, 기관들의 리스트로부터 선택되는 기관에 대한 제1 식별자, 및 계좌들의 리스트로부터 선택되는 계좌에 대한 제2 식별자를 제공하게 한다. 비-일시적, 컴퓨터-판독가능 매체의 하나 이상의 실시예들에서, 자금 이체를 처리하기 위한 요청은 제2 요청이고, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가: 거래 식별자에 대한 제1 컴퓨팅 디바이스로부터의 제1 요청에 응답하여 거래 식별자를 생성하고; 거래 식별자를 제2 컴퓨팅 디바이스에 제공하게 한다. 비-일시적, 컴퓨터-판독가능 매체의 하나 이상의 실시예들에서, 거래 식별자는 자금 이체를 처리하기 위한 요청에서 클라이언트 디바이스에 의해 요청되는 URI(uniform resource identifier) 내에 포함된다. 비-일시적, 컴퓨터-판독가능 매체의 하나 이상의 실시예들에서, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 인증 크리덴셜들을 사용하여 클라이언트 디바이스를 대신하여 기관들의 리스트로부터 선택되는 기관에 의해 동작되는 피어 지불 서비스(peer payment service)로 적어도 인증하게 한다. 비-일시적, 컴퓨터-판독가능 매체의 하나 이상의 실시예들에서, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 자금 이체와 연관되는 에스크로 계좌에 대해 제2 컴퓨팅 디바이스로 제3 식별자를 제공하게 한다.
상세 설명
자금들을 송신 및 수신하기 위해, 신용 카드들과 같은, 신용 계좌들을 사용하기 위한 다양한 접근법들이 개시된다. 자금 이체(funds transfer), 예컨대 자동 어음 교환소(automated clearinghouse; ACH) 네트워크 또는 실시간 총액 결제(real-time gross settlement; RTGS) 네트워크를 통한 이체는 금융 기관들 사이에서 자금들을 이체하기 위해 사용될 수 있다. 금융 기관은 계좌에 고객 대신에 자금들을 저장하고 고객이 계좌로 자금들이 예치되게 하거나 계좌로부터 자금들이 이체되게 하는 것을 허용하는 임의의 기관 또는 엔티티(entity)를 포함할 수 있다. 따라서, 금융 기관은 은행, 신용 조합, 저축 대부 조합, 중개인, 중개업소, 송금업자, 저장-가치(stored-value) 계좌들을 제공하는 지불 제공자 등을 포함할 수 있을 것이다.
이체가 완료되기 전에 또는 후에, 신용(credit) 또는 직불(debit)은 자금들의 이체의 본성(nature)을 반영하기 위해 신용 카드 계좌에 대해 이루어질 수 있다. 따라서, 신용 계좌(예를 들어, 신용 카드)는 통화 계좌(예를 들어, 당좌 예금 계좌, 저축 계좌, 중개 계좌, 저장-가치 계좌 등) 또는 신용 계좌를 갖는 임의의 개인에게 자금들을 지불하기 위해 사용될 수 있다. 마찬가지로, 신용 계좌는 또한 통화 또는 신용 계좌를 갖는 임의의 개인으로부터 자금들을 수령할 수 있다. 그 결과, 신용 카드는 때때로 지불 레일들(payment rails)로서 언급되는, 어떤 임의의 지불 플랫폼 또는 결제 네트워크로부터 자금들을 수령하거나 이를 통해 자금들을 지불하기 위해 사용될 수 있다. 다음의 논의에서, 시스템 및 그 구성요소들의 일반적인 설명이 제공되며, 그 다음 동일한 것의 동작의 논의가 이어진다.
도 1a 내지 도 1d는 지급인(payer)이 신용 카드 계좌를 사용하여 제3자(third-party)(예를 들어, 친구, 동료, 클라이언트, 또는 상인)에게 송금하기 위해 클라이언트 디바이스(100)와 상호작용하는 방법의 예들을 예시한다. 그러나, 지급인은 다른 구현들로 신용 카드 계좌를 사용하여 제3자에게 송금하기 위해 다른 방식으로 그 또는 그녀의 클라이언트 디바이스(100)와 상호작용할 수 있을 것이다.
도 1a는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106a)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 다른 개인에 대한 직접 지불(direct payment)을 위해 사용자 인터페이스(106a) 내에 제시되는 신용 카드들의 리스트로부터 신용 카드를 선택할 수 있다. 예를 들어, 지급인이 클라이언트 디바이스(100) 상의 그 또는 그녀의 모바일 뱅킹 애플리케이션으로 로그하였고 다른 개인에게 직접 지불하는 옵션을 선택하였으면, 그 또는 그녀는 사용자 인터페이스(106a)와 같은 인터페이스를 제시받을 수 있을 것이다.
도 1b는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106b)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 사용자 인터페이스(106b)에 제시되는 수령인들의 리스트로부터 자금들의 수령인을 선택할 수 있다. 수령인들의 리스트 내의 개별 수령인들에 대해, 수령인과 연관되는 고유 식별자가 제시될 수 있을 것이다. 그러한 고유 식별자들은 수령인의 연락처 정보, 예컨대 모바일 폰 번호, 이메일 주소 등을 나타낼 수 있을 것이다. 예를 들어, 수령인이 고유 식별자로서 그 또는 그녀의 폰 번호를 사용하여 이전에 지불되었던 경우, 그 다음, 수령인의 폰 번호가 제시될 수 있을 것이다. 다수의 고유 식별자들이 동일한 수령인에 매핑되는 경우, 디폴트 식별자가 제시될 수 있을 것이다.
수령인들의 리스트는 다양한 접근법들 또는 접근법들의 조합들을 사용하여 파퓰레이트된다. 예를 들어, 사용자 인터페이스(106b) 내의 수령인들의 리스트는 클라이언트 디바이스(100)에 액세스가능한 연락처들의 리스트 또는 주소록으로부터 파퓰레이트될 수 있을 것이다. 그러한 상황에서, 주소록 또는 연락처 리스트 내의 엔트리(entry)가 공지된 수령인과 일치하는 경우, 그 다음, 엔트리는 수령인들의 리스트에 추가될 수 있을 것이다. 다른 예로서, 수령인들은 사용자에 의해 수동으로 추가되었을 수 있을 것이다.
도 1c는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106c)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 사용자 인터페이스(106b)를 사용하여 선택된 수령인에게 지불할 금액을 지정할 수 있다. 지급인이 금액을 지정한 후, 지급인은 그 다음 사용자 인터페이스(106c)를 통해 지불될 금액을 확인할 수 있을 것이다. 후속 사용자 인터페이스(106)에서, 지급인은 거래 상세들(예를 들어, 선택된 신용 카드, 선택된 수령인, 및 특정 금액의 자금들)을 확인하고 사용자의 신용 카드 계좌를 사용하여 수령인에 대한 지불을 개시할 수 있을 것이다.
도 1d는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106d)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 사용자 인터페이스(106d) 내에서 그 또는 그녀의 계좌 잔고 및 이전 거래들(prior transactions)을 관측할 수 있을 것이다. 이전 거래들의 예들은 상인과의 신용 카드 거래들 또는 사용자 인터페이스(106b)를 사용하여 선택되는 수령인과 같은 다른 개인들에 대한 직접 지불들을 포함할 수 있을 것이다. 거래의 금액은 또한 각각의 이전 거래에 옆에 디스플레이될 수 있을 것이다.
도 1e 내지 도 1h는 수령인이 다수의 개인들 사이의 거래를 분할하고 그 또는 그녀의 지분(share)에 대해 각각의 개인으로부터 지불을 요청하는 방법의 예들을 예시한다. 도 1e 내지 도 1h는 수령인이 지불을 요청할 수 있는 방법의 예를 예시하지만, 다른 유사한 접근법들이 또한 본 개시의 다양한 실시예들에 의해 망라된다. 예를 들어, 특정 또는 전체 거래를 분할하는 대신에, 수령인은 다수의 개인들 사이에 분할될 다른 금액을 지정하고 총액(total) 중 그 또는 그녀의 지분에 대해 각각의 개인으로부터 지불을 요청할 수 있을 것이다. 다른 예로서, 수령인은 단일의 개인으로부터 지불을 요청하기 위해 금액을 지정할 수 있을 것이다.
도 1e는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106e)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106e)는 사용자가 선택할 수 있는 거래들의 리스트를 포함할 수 있다. 예를 들어, 수령인이 특정 구매(예를 들어, 식당에서의 식사, 자동차용 가솔린의 탱크, 상점으로부터의 선물 등)의 비용을 분할하기를 원하는 경우, 수령인은 사용자 인터페이스(106e)에 제시되는 거래들로부터 구매를 선택할 수 있을 것이다.
도 1f는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106f)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106f)는 사용자 인터페이스(106e)에서 선택되는 거래가 분할되어야만 하는 개인들의 리스트를 포함할 수 있다. 지급인들(payers)의 리스트 내의 개별 지급인들에 대해, 지급인과 연관되는 고유 식별자가 제시될 수 있을 것이다. 그러한 고유 식별자들은 모바일 폰 번호, 이메일 주소 등과 같은, 지급인의 연락처 정보를 나타낼 수 있을 것이다. 예를 들어, 지급인이 고유 식별자로서 그 또는 그녀의 폰 번호를 사용하여 이전에 지불되었던 경우, 그 다음, 지급인의 폰 번호는 제시될 수 있을 것이다. 다수의 고유 식별자들이 동일한 지급인에 매핑되는 경우, 디폴트 식별자가 제시될 수 있을 것이다.
지급인들의 리스트는 다양한 접근법들 또는 접근법들의 조합들을 사용하여 파퓰레이트될 수 있을 것이다. 예를 들어, 사용자 인터페이스(106f) 내의 지급인들의 리스트는 클라이언트 디바이스(100)에 액세스가능한 연락처들의 리스트 또는 주소록으로부터 파퓰레이트될 수 있을 것이다. 그러한 상황에서, 주소록 또는 연락처 리스트 내의 엔트리가 공지된 지급인과 일치하는 경우, 그 다음, 엔트리는 지급인들의 리스트에 추가될 수 있을 것이다. 다른 예로서, 지급인들은 사용자에 의해 수동으로 추가될 수 있었을 것이다.
도 1g는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106g)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106g)는 수령인이 사용자 인터페이스(106f)로부터 선택되는 지급인들 중에서 사용자 인터페이스(106e)로부터 선택되는 거래의 비용을 분할하는 방법을 지정하는 것을 허용할 수 있다. 일부 경우들에서, 거래의 초기 분할이 제시될 수 있다(예를 들어, 개인들 사이의 동일한 분할). 그러나, 임의의 한 개인으로부터 요청될 금액은 사용자 인터페이스(106g) 내에서 조정될 수 있다. 금액이 결정되었으면, 수령인은 개별 지급인들로부터 자금들을 요청하기 위해 사용자 인터페이스와 상호작용할 수 있다.
도 1h는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106h)는 예를 들어 도 1e 내지 도 1g에 도시된 바와 같이, 수령인이 요청되었던 지불들의 상태를 보는 것을 허용하기 위해 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 하나 이상의 계류중인 지불들이 사용자 인터페이스(106h) 내에서 수령인에게 제시될 수 있다. 예를 들어, 수령인이 사용자 인터페이스(106g)를 통해 특정 거래에 대해 하나 이상의 개인들로부터 자금들을 요청한 후, 수령인은 사용자 인터페이스(106h) 내의 계류중인 지불들의 리스트를 관측함으로써 어떤 지급인들이 지불 또는 지불하지 않았는지 또는 어떤 지급인들이 계류중인 지불을 가지고 있는지를 관측할 수 있다.
도 1i 내지 도 1m은 사용자가 다른 사용자의 신용 카드 계좌로부터 그 또는 그녀에게 지불되는 자금들을 청구 또는 수령할 수 있는 방법의 예들을 예시한다. 예를 들어, 수령인이 도 1a 내지 도 1h에 예시되는 워크플로우의 결과로서 자금들의 지불을 수령한 경우, 그 다음, 수령인은 하나 이상의 도 1i 내지 도 1m에 도시되는 바와 같은 하나 이상의 사용자 인터페이스들(106)과 상호작용할 수 있을 것이다.
도 1i는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106i)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 수령인은 자금들이 수령인에게 송신되었고 이용가능하다는 것을 나타내는 메시지를 수신하였다. 자금들을 청구하기 위해, 수령인은 링크를 선택할 수 있을 것이다.
도 1j는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106j)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 수령인은 사용자 인터페이스(106i)에 이전에 제시된 링크를 선택하였을 수 있고 수령인이 복수의 금융 기관들로부터 금융 기관을 선택하는 것을 허용하는 사용자 인터페이스(106j)를 제시받는다. 수령인은 그 또는 그녀가 수령할 자금들을 그 또는 그녀가 예치하기를 원하는 계좌를 그 또는 그녀가 갖는 금용 기관을 선택할 수 있을 것이다.
도 1k는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106k)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 수령인은 이전에 선택된 금융 기관과 인증하기 위해 인증 인터페이스를 제시받는다. 예를 들어, 수령인은 사용자 인터페이스(106j)에 제공되는 리스트로부터 금융 기관을 이전에 선택하였을 수 있다.
도 1l은 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106l)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106l)는 수령인에게 선택된 금융 기관 내의 계좌 잔고들 및 계좌들의 리스트를 제공할 수 있다. 수령인은 사용자 인터페이스(106k)를 사용한 성공적인 인증에 응답하여 사용자 인터페이스(106l)를 제시받을 수 있다. 사용자 인터페이스(106l) 내에서, 수령인은 그 또는 그녀가 자금들을 예치하기를 원하는 계좌들 중 하나를 선택할 수 있다.
도 1m은 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106m)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106m)는 수령인이 거래를 검토하는 것을 허용하기 위해 확인 단계를 제공한다. 이것은 예를 들어, 예치될 금액, 자금들이 예치될 계좌, 및 자금들을 지불하고 있는 개인을 포함할 수 있다. 정보가 검토되면, 수령인은 거래를 확인하고 사용자 인터페이스(106m)를 사용하여 자금들을 수락(accept)할 수 있다. 그 다음, 자금들은 나중에 논의되는 바와 같이, 수령인의 계좌에 예치될 수 있다.
그러나, 일부 대안적인 구현예들에서, 수령인은 그 또는 그녀의 금융 기관과 인증하도록 프롬프트되지 않을 수도 있다. 예를 들어, 수령인은 그 또는 그녀의 계좌 번호를 입력하기 위해, 도 1j에서 그 또는 그녀의 금융 기관을 선택한 후, 프롬프트될 수 있을 것이다. 이러한 시나리오들에서, 자금들은 도 1m에 예시된 바와 같이, 수령인이 그 또는 그녀의 계좌 정보를 제공하고 예금(deposit)을 확인한 후 자동으로 예치될 수 있을 것이다.
도 1n 내지 도 1r은 사용자가 다른 사용자의 신용 카드 계좌로 자금들을 지불하기 위한 요청에 동의할 수 있는 방법의 예들을 예시한다. 예를 들어, 지급인이 도 1e 내지 도 1h에 예시되는 워크플로우의 결과로서 자금들을 지불하기 위한 요청을 수신한 경우, 그 다음, 지급인은 하나 이상의 도 1n 내지 도 1r에 도시되는 바와 같이 하나 이상의 사용자 인터페이스들(106)과 상호작용할 수 있을 것이다.
도 1n은 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106N)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 다른 개인이 지불을 요청하고 있다는 것을 나타내는 메시지를 수신하였다. 지불 요청에 동의하기 위해, 지급인은 링크를 선택할 수 있을 것이다.
도 1o는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106o)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 사용자 인터페이스(106N)에 이전에 제시된 링크를 선택했을 수 있고 지급인이 복수의 금융 기관들로부터 금융 기간을 선택하는 것을 허용하는 사용자 인터페이스(106o)를 제시받는다. 지급인은 그 또는 그녀가 지불 요청을 이행하기 위해 자금들이 인출되도록 원하는 계좌를 그 또는 그녀가 갖는 금융 기관을 선택할 수 있을 것이다.
도 1p는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106p)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 지급인은 이전에 선택된 금융 기관과 인증하기 위해 인증 인터페이스를 제시받는다. 예를 들어, 지급인은 사용자 인터페이스(106o)에 제공되는 리스트로부터 금융 기관을 이전에 선택하였을 수 있다.
도 1q는 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106q)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106q)는 지급인에게 선택된 금융 기관 내의 계좌 잔고들 및 계좌들의 리스트를 제공할 수 있다. 지급인은 사용자 인터페이스(106p)를 사용하는 성공적인 인증에 응답하여 사용자 인터페이스(106l)를 제시받을 수 있다. 사용자 인터페이스(106q) 내에서, 지급인은 그 또는 그녀가 지불 요청을 이행하기 위해 자금들이 인출되도록 원하는 계좌들 중 하나를 선택할 수 있다.
도 1r은 본 개시의 다양한 실시예들에 따른 디스플레이(103)를 갖는 클라이언트 디바이스(100)를 도시한다. 사용자 인터페이스(106r)는 클라이언트 디바이스(100)의 디스플레이(103) 상에 렌더링될 수 있다. 예시된 바와 같이, 사용자 인터페이스(106r)는 지급인이 거래를 검토하는 것을 허용하기 위해 확인 단계를 제공한다. 이것은 예를 들어, 인출될 금액, 자금들이 인출될 계좌, 및 자금들이 지불될 개인을 포함할 수 있다. 정보가 검토되면, 지급인은 거래를 확인하고 사용자 인터페이스(106r)를 사용하여 자금들 수락할 수 있다. 그 다음, 자금들은 나중에 논의되는 바와 같이, 수령인의 계좌에 예치될 수 있다.
도 2를 참조하여, 다양한 실시예들에 따른 네트워크 환경(200)이 도시된다. 네트워크 환경(200)은 발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 통합자 컴퓨팅 환경(209), 및 클라이언트 디바이스(100)를 포함할 수 있다. 발행인 컴퓨팅 환경(203)은 신용 카드 발행인 - 신용 카드 계좌들의 형태로 고객들을 대신하여 신용(credit)을 발행하는 금융 기관에 의해 또는 이를 대신하여 동작될 수 있다. 피어 컴퓨팅 환경(206)은 피어 금융 기관 - 신용 카드 발행인과 신용 카드 계좌의 보유자가 지불을 송신하거나 지불을 수령하기를 원하는 고객들을 갖는 금융 기관에 의해 또는 이를 대신하여 동작될 수 있다. 통합자 컴퓨팅 환경(209)은 금융 서비스 통합자 - 상이한 은행들을 갖는 고객들이 상이한 기관들에서의 그들의 계좌들을 단일 애플리케이션 또는 서비스로 통합하는 것을 허용하기 위해 공통 세트의 프로토콜들, 도구들, 또는 애플리케이션 프로그래밍 인터페이스를 제공하는 기관을 대신하여 동작될 수 있다. 발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 통합자 컴퓨팅 환경(209), 클라이언트 디바이스(100)는 네트워크(213)를 통해 서로 데이터 통신을 할 수 있다.
네트워크(213)는 광역 네트워크들(WANs), 로컬 영역 네트워크들(LANs), 개인 영역 네트워크들(PANs), 또는 그 조합을 포함할 수 있다. 이러한 네트워크들은 유선 또는 무선 구성요소들 또는 그 조합을 포함할 수 있다. 유선 네트워크들은 이더넷 네트워크들, 케이블 네트워크들, 광섬유 네트워크들, 전화 네트워크들 예컨대 다이얼-업(dial-up), 디지털 가입자 라인(DSL), 및 통합 서비스 디지털 네트워크(ISDN) 네트워크들을 포함할 수 있다. 무선 네트워크들은 셀룰라 네트워크들, 위성 네트워크들, IEEE(Institute of Electrical and Electronic Engineers) 802.11 무선 네트워크들(즉, WI-FI®), BLUETOOTH® 네트워크들, 마이크로파 전송 네트워크들 뿐만 아니라, 라디오 브로드캐스트들에 의존하는 다른 네트워크들을 포함할 수 있다. 네트워크(213)는 또한 2개 이상의 네트워크들(213)의 조합을 포함할 수 있다. 네트워크들(213)의 예들은 인터넷, 인트라넷들, 익스트라넷들, 가상 사설 네트워크들(VPNs), 및 유사한 네트워크들을 포함할 수 있다.
발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 및 통합자 컴퓨팅 환경(209)은 프로세서, 메모리, 및/또는 네트워크 인터페이스를 포함하는 하나 이상의 컴퓨팅 디바이스들을 포함할 수 있다. 예를 들어, 컴퓨팅 디바이스들은 다른 컴퓨팅 디바이스들 또는 애플리케이션들을 대신하여 계산들(computations)을 수행하도록 구성될 수 있다. 다른 예로서, 그러한 컴퓨팅 디바이스들은 콘텐츠에 대한 요청들에 응답하여 다른 컴퓨팅 디바이스들에 콘텐츠를 호스트하고/하거나 제공할 수 있다.
더욱이, 발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 및 통합자 컴퓨팅 환경(209)은 하나 이상의 서버 은행들 또는 컴퓨터 은행들 또는 다른 배열들로 배열될 수 있는 복수의 컴퓨팅 디바이스들을 이용할 수 있다. 그러한 컴퓨팅 디바이스들은 단일 설치로 위치될 수 있거나 많은 상이한 지리적 위치들 사이에 분산될 수 있다. 예를 들어, 발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 또는 통합자 컴퓨팅 환경(209)은 호스팅된 컴퓨팅 자원, 그리드 컴퓨팅 자원 또는 임의의 다른 분산된 컴퓨팅 배열(arrangement)을 함께 포함할 수 있는 복수의 컴퓨팅 디바이스들을 포함할 수 있다. 일부 경우들에서, 발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 또는 통합자 컴퓨팅 환경(209)은 처리, 네트워크, 저장, 또는 다른 컴퓨팅-관련 자원들의 할당된 용량(capacity)이 시간에 따라 가변될 수 있는 탄성(elastic) 컴퓨팅 자원에 대응할 수 있다.
다양한 애플리케이션들 또는 다른 기능은 다양한 실시예들에 따라 발행인 컴퓨팅 환경(203)에서 실행될 수 있다. 발행인 컴퓨팅 환경(203) 상에서 실행되는 구성요소들은 본원에서 상세히 논의되지 않는 다른 애플리케이션들, 서비스들, 프로세스들, 시스템들, 엔진들, 또는 기능 뿐만 아니라, 발행인 지불 서비스(216)를 포함할 수 있다.
발행인 지불 서비스(216)는 발행인과의 신용 카드 계좌를 갖는 고객을 대신하여 자금 이체들을 처리하도록 실행될 수 있다. 예를 들어, 발행인 지불 서비스(216)는 고객의 신용 카드 계좌로부터 다른 금융 기관에 금융 계좌를 갖는 상인 또는 고객으로 자금들의 지불을 처리할 수 있을 것이다. 다른 예로서, 발행인 지불 서비스(216)는 발행인과의 신용 카드 계좌를 갖는 고객을 대신하여 자금들을 수령하고 자금들을 고객의 신용 카드 계좌 잔고로 입금(credit)할 수 있을 것이다.
또한, 다양한 데이터는 발행인 컴퓨팅 환경(203)에 액세스가능한 발행인 데이터 저장소(219)에 저장된다. 발행인 데이터 저장소(219)는 복수의 데이터 저장소들을 나타낼 수 있으며, 이는 관계형 데이터베이스들, 객체-지향 데이터베이스들, 계층형 데이터베이스들, 해시 테이블들 또는 유사한 키-값 데이터 저장소들 뿐만 아니라, 다른 데이터 저장 애플리케이션들 또는 데이터 구조들을 포함할 수 있다. 발행인 데이터 저장소(219)에 저장되는 데이터는 아래에 설명되는 다양한 애플리케이션들 또는 기능 엔티티들의 동작과 연관된다. 이러한 데이터는 수취인(payee) 디렉토리(221a), 에스크로(escrow) 계좌(223a), 하나 이상의 신용 사용자 계좌들(226), 기관 식별자(229a), 및 잠재적 다른 데이터를 포함할 수 있다.
수취인 디렉토리(221), 예컨대 수취인 디렉토리(221a)는 자금들의 수취인들 또는 수령인들의 디렉토리를 나타낼 수 있다. 예를 들어, 폰 번호, 이메일 계정 등과 같은 개인에 대한 임의의 고유 식별자에 대해, 레코드는 이전 거래에 사용된 기관 식별자(229) 및/또는 신용 계좌 식별자(236) 또는 통화 계좌 식별자(249)를 식별하는 수취인 디렉토리(221a)에 저장될 수 있을 것이다. 그 결과, 동일한 수취인에 대한 후속 지불들은 자금들을 향하게 하는 곳을 결정하는 수취인 디렉토리(221a)를 참조하는 발행인 지불 서비스(216)에 의해 더 신속히 처리될 수 있다.
에스크로 계좌(223), 예컨대 에스크로 계좌(223a)는 신용 카드 계좌들과 다른 금융 계좌들 사이에 이체되는 자금의 임시 저장을 위해 신용 카드 발행인에 의해 동작되는 금융 계좌를 나타낼 수 있다. 예를 들어, 신용 카드 보유자가 피어 금융 기관에서 고객의 금융 계좌로부터 자금들을 수령할 때, 자금들은 에스크로 계좌(223a)에 예치될 수 있을 것이다. 그 다음, 신용(credit)은 고객의 신용 카드 계좌에 적용될 수 있을 것이다.
에스크로 계좌(223a)의 사용은 신용 카드 계좌들이 신용 카드 협회들(예를 들어, VISA®, MASTERCARD®, DISCOVER®, DINER CLUB®, CHINA UNIONPAY®, 또는 INDIAN RUPAY®)에 의해 동작되는 신용 카드 네트워크들 외에 은행간 거래 네트워크들에 참여하는 것을 허용할 수 있다. 예를 들어, 신용 카드 발행인은 신용 카드 계좌 보유자를 대신하여 에스크로 계좌(223a)로부터 다른 금융 기관의 계좌로 이체를 개시할 수 있을 것이다. 그 다음, 신용 카드 발행인은 신용 카드 계좌에 이체된 자금의 금액에 대해 청구할 수 있을 것이다. 마찬가지로, 신용 카드 발행인은 먼저 신용 카드에 청구하고 그 다음 이체를 개시할 수 있을 것이다. 그 결과, 신용 카드 계좌 보유자는 신용 카드 네트워크를 사용해야 하는 것 없이 그 또는 그녀의 신용 카드를 사용하여 다른 당사자에게 자금들을 지불할 수 있을 것이다. 유사하게, 신용 카드 발행인은 신용 카드 계좌 보유자를 대신하여 에스크로 계좌(223a)로 예금(deposit)을 수령하고 그 후에 자금들을 신용 카드 계좌의 잔고에 입금할 수 있거나, 그 역도 또한 마찬가지일 수 있다. 그 결과, 신용 카드 계좌 보유자는 다른 사람들로부터의 지불들을 수락하고 그러한 지불들이 그 또는 그녀의 신용 카드 계좌에 예치되거나 입금되게 할 수 있을 것이다.
신용 사용자 계좌들(226)은 발행인 컴퓨팅 환경(203)을 동작시키는 발행인의 고객들의 계좌 정보를 나타낼 수 있다. 예를 들어, 적어도 하나의 신용 카드 계좌, 후불 카드 계좌, 또는 유사한 자동 이체(direct-debit) 신용 계좌를 갖는 각각의 고객은 발행인과 함께 신용 사용자 계좌(226)를 가질 수 있다. 따라서, 신용 사용자 계좌(226)는 하나 이상의 인증 크리덴셜들(233a) 및 하나 이상의 신용 계좌 식별자들(236)을 포함할 수 있다. 고객에 대한 추가적인 정보, 예컨대 그 또는 그녀의 이름, 연락처 정보(예를 들어, 우편 주소, 폰 번호(들), 또는 이메일 주소) 등은 또한 신용 사용자 계좌(226)에 저장될 수 있다.
인증 크리덴셜들(233), 예컨대 인증 크리덴셜들(233a)은 계좌의 보유자의 신원을 인증하거나 검증하기 위해 사용될 수 있은 데이터의 임의의 아이템들을 포함할 수 있다. 인증 크리덴셜들(233)의 예들은 사용자명들, 암호들, 개인 식별 번호들(PINs), 일회용 암호들(OTPs), 인증 토큰들, 암호 키 쌍들 또는 인증서들 등을 포함할 수 있다. 원하는 보안의 레벨에 따라서, 사용자는 그 또는 그녀의 신원을 입증하기 위해 하나 이상의 인증 크리덴셜들(233)(예를 들어, 이중(two-factor) 인증, 다중(multi-factor) 인증 등)을 제공하도록 요구될 수 있다.
신용 계좌 식별자(236)는 발행인과 함께 고객에 의해 보유되는 신용 계좌(예를 들어, 신용 카드 계좌, 후불 카드 계좌 등)를 식별하는 임의의 고유 식별자일 수 있다. 신용 계좌 식별자들(236)의 예들은 지불 카드 번호들, 예컨대 신용 또는 후불 카드 번호들, 또는 다른 계좌들에 대해 발행인에 의해 유지되는 개별 계좌들을 고유하게 식별하는 발행인에 의해 생성되는 계좌 번호들을 포함할 수 있다. 고객이 발행인과 함께 다수의 신용 계좌들을 가질 때, 고객은 그 또는 그녀의 신용 사용자 계좌(226)와 연관되는 다수의 신용 계좌 식별자들(236)을 가질 수 있다. 예를 들어, 고객은 발행인에 의해 제공되는 후불 카드 계좌에 대한 제1 신용 계좌 식별자(236) 및 발행인에 의해 제공되는 신용 카드 계좌에 대한 제2 신용 계좌 식별자(236)를 가질 수도 있다.
기관 식별자(229), 예컨대 기관 식별자(229a)는 자금들의 이체가 금융 기관에서 비롯되거나 이에 대해 정해진 것으로서 식별되도록 허용하는 임의의 고유 식별자를 나타낼 수 있다. 따라서, 각각의 금융 기관은 그것과 연관되는 기관 식별자(229)를 가질 수 있다. 기관 식별자들(229)의 예들은 미국 은행 협회(American Bankers Association; ABA) 라우팅 등록 은행 번호들(routing transit numbers; RTNs), 세계 은행간 금융 통신 학회(Society for Worldwide Interbank Financial Telecommunication; SWIFT) 사업 식별자 코드들(business identifier codes; BICs), 또는 유사한 식별자들을 포함한다. 금융 기관이 다수의 거래 또는 결제 네트워크들에 참여하는 경우, 금융 기관은 다수의 기관 식별자들(229)을 가질 수 있다. 예를 들어, 미국의 은행은 ABA RTN 및 SWIFT BIC 둘 다를 가질 수 있다.
일부 경우들에서, 기관 식별자(229a)는 또한 신용 계좌 식별자(236)에 내장되거나 그 구성요소일 수 있다. 예를 들어, 신용 또는 후불 카드 번호의 처음 몇 자릿수들은 종종 신용 또는 후불 카드 계좌의 발행인을 고유하게 식별하는 발행인 식별 번호(Issuer Identification Number; IIN)로서의 역할을 한다.
다양한 애플리케이션들 또는 다른 기능은 다양한 실시예들에 따른 피어 컴퓨팅 환경(206)에서 실행될 수 있다. 피어 컴퓨팅 환경(206) 상에서 실행되는 구성요소들은 본원에서 상세히 논의되지 않는 애플리케이션들, 서비스들, 프로세스들, 시스템들, 엔진들, 또는 기능 뿐만 아니라, 피어 지불 서비스(239)를 포함할 수 있다.
피어 지불 서비스(239)는 피어 기관과 함께 통화 계좌를 갖는 고객을 대신하여 자금 이체들을 처리하도록 실행될 수 있다. 예를 들어, 피어 지불 서비스(239)는 목적지로서 통화 계좌를 식별한 은행간 결제 네트워크를 통해 자금 이체를 수령하고 자금들을 피어 기관에 의해 유지되는 통화 계좌에 입금할 수 있을 것이다. 다른 예로서, 피어 지불 서비스(239)는 자금 이체를 은행간 결제 네트워크를 통해 동일한 또는 다른 기관의 계좌로 개시하고 자금들을 피어 기관에 의해 유지되는 통화 계좌로부터 인출할 수 있을 것이다. 피어 기관에 의해 유지되는 통화 계좌들은 예금들 및/또는 인출들이 요구에 따라 이루어지도록 허용되는 임의의 계좌를 포함할 수 있다. 통화 계좌들의 예들은 거래 계좌들(예를 들어, 당좌 예금 계좌들, 현금 계좌들, 요구불 예금 계좌들 등), 저축 계좌들, 머니-마켓 계좌들, 중개 계좌들, 저장 가치(stored-value) 계좌들 등을 포함할 수 있다.
또한, 다양한 데이터는 피어 컴퓨팅 환경(206)에 액세스가능한 피어 데이터 저장소(243)에 저장된다. 피어 데이터 저장소(243)는 복수의 데이터 저장소들을 나타낼 수 있으며, 이는 관계형 데이터베이스들, 객체-지향 데이터베이스들, 계층형 데이터베이스들, 해시 테이블들 또는 유사한 키-값 데이터 저장소들 뿐만 아니라, 다른 데이터 저장 애플리케이션들 또는 데이터 구조들을 포함할 수 있다. 피어 데이터 저장소(243)에 저장되는 데이터는 아래에 설명되는 다양한 애플리케이션들 또는 기능 엔티티들의 동작과 연관된다. 이러한 데이터는 수취인 디렉토리(221b), 에스크로 계좌(223b), 하나 이상의 피어 사용자 계좌들(246), 피어 기관에 대한 기관 식별자(229b), 및 잠재적 다른 데이터를 포함할 수 있다.
피어 사용자 계좌(246)는 피어 컴퓨팅 환경(206)을 동작시키는 피어 금융 기관의 고객들의 계좌 정보를 나타낼 수 있다. 예를 들어, 피어 금융 기관과 함께 적어도 하나의 통화 계좌를 갖는 각각의 고객은 피어 사용자 계좌(246)를 가질 수 있다. 따라서, 피어 사용자 계좌(246)는 하나 이상의 인증 크리덴셜들(233b) 및 하나 이상의 통화 계좌 식별자들(249)을 포함할 수 있다. 각각의 통화 계좌에 대한 정보, 예컨대 계좌 잔고(253)(예를 들어, 현재 계좌 내의 자금들의 가치)는 또한 피어 사용자 계좌(246)와 연계하여 저장될 수 있다. 고객에 대한 추가적인 정보, 예컨대 그 또는 그녀의 이름, 연락처 정보(예를 들어, 우편 주소, 폰 번호(들), 또는 이메일 주소) 등이 또한 저장될 수 있다.
통화 계좌 식별자(249)는 피어 금융 기관에 의해 유지되는 임의의 통화 계좌에 대한 고유 식별자이다. 이들은 피어 금융 기관에 의해 내부적으로 생성되는 계좌 번호들, 국제 은행 계좌 번호들(international bank account numbers; IBANs), 또는 개별 통화 계좌들을 구별하기 위한 유사한 식별자들을 포함할 수 있을 것이다.
다양한 애플리케이션들 또는 다른 기능은 다양한 실시예들에 따른 통합자 컴퓨팅 환경(209)에서 실행될 수 있다. 통합자 컴퓨팅 환경(209) 상에서 실행되는 구성요소들은 통합자 서비스(256), 및 본원에 상세히 논의되지 않는 다른 애플리케이션들, 서비스들, 프로세스들, 시스템들, 엔진들, 또는 기능을 포함한다.
통합자 서비스(256)는 발행인 또는 피어 금융 기관에 의해 유지되는 신용 또는 통화 계좌들을 애플리케이션 또는 다른 기관들과 통합하거나 달리 연결하도록 실행될 수 있다. 예를 들어, 통합자 서비스(256)는 사용자가 발행인 지불 서비스(216) 또는 피어 지불 서비스(239)로 인증하는 것을 허용하는 웹 페이지, 포탈, 또는 애플리케이션을 제공할 수 있을 것이다. 인증이 발생한 후, 통합자 서비스(256)는 신용 사용자 계좌(226) 또는 피어 사용자 계좌(246)로부터 정보(예를 들어, 계좌 번호들 및 기관 식별자들(229))를 검색하고 그것을 사용자에 의해 인가되는 다른 서비스, 애플리케이션, 또는 기관에 중계할 수 있을 것이다.
발행인 지불 서비스(216) 및 피어 지불 서비스(239)로부터 별도로 그리고 독립적으로 도시되지만, 통합자 서비스(256)는 피어 지불 서비스(239) 또는 the 발행인 지불 서비스(216)와 동일한 엔티티에 의해 또는 이와 함께 동작될 수 있다. 이러한 구현예들에서, 발행인 지불 서비스(216) 또는 피어 지불 서비스(239)에 의해 수행되는 것으로서 이전에 설명되는 기능 중 일부는 통합자 서비스(256)에 의해 수행될 수 있을 것이다. 이러한 구현예들에서 마찬가지로, 통합자 서비스(256)에 의해 수행되는 것으로서 설명되는 기능들은 발행인 지불 서비스(216) 또는 피어 지불 서비스(239)에 의해 수행될 수 있을 것이다.
또한, 다양한 데이터는 통합자 컴퓨팅 환경(209)에 액세스가능한 통합자 데이터 저장소(259)에 저장된다. 통합자 데이터 저장소(259)는 복수의 데이터 저장소들을 나타낼 수 있으며, 이는 관계형 데이터베이스들, 객체-지향 데이터베이스들, 계층형 데이터베이스들, 해시 테이블들 또는 유사한 키-값 데이터 저장소들 뿐만 아니라, 다른 데이터 저장 애플리케이션들 또는 데이터 구조들을 포함할 수 있다. 통합자 데이터 저장소(259)에 저장되는 데이터는 아래에 설명되는 다양한 애플리케이션들 또는 기능 엔티티들의 동작과 연관된다. 이러한 데이터는 하나 이상의 거래 레코드들(263), 및 잠재적 다른 데이터를 포함할 수 있다.
발행인 데이터 저장소(219) 및 피어 데이터 저장소(243)로부터 별도로 그리고 독립적으로 도시되지만, 통합자 데이터 저장소(259)는 발행인 데이터 저장소(219) 및 피어 데이터 저장소(243)와 동일한 엔티티에 의해 또는 이들과 함께 동작될 수 있다. 이러한 구현예들에서, 통합자 데이터 저장소(259) 내의 데이터 저장소는 발행인 데이터 저장소(219) 또는 피어 데이터 저장소(243)에 저장될 수 있을 것이다. 마찬가지로, 발행인 데이터 저장소(219) 또는 피어 데이터 저장소(243)에 저장되는 데이터는 통합자 데이터 저장소(259)에 저장될 수 있을 것이다.
거래 레코드(263)는 통합자 서비스(256)에 의해 촉진되는 임의의 금융 거래를 나타낼 수 있다. 이것은 예를 들어, 2개의 상이한 금융 기관들에 의해 유지되는 2개의 금융 계좌들 사이의 자금들의 이체를 포함할 수 있을 것이다. 따라서, 거래 레코드(263)는 거래 식별자(266), 거래 목적지(269), 및/또는 거래 금액(273)을 포함할 수 있다. 추가적인 정보, 예컨대 거래의 소스는 또한 일부 실시예들에서 거래 레코드(263)에 저장될 수 있다. 그러나, 다른 실시예들은 데이터 침해(data breach)의 경우에서 고객들에 대한 프라이버시 위험들을 최소화하기 위해 추가적인 정보를 포함하지 않거나 수집되는 추가적인 정보의 양을 제한할 수 있다.
거래 식별자(266)는 개별 거래 레코드들(263)을 구별하기 위해 사용될 수 있는 임의의 식별자를 포함할 수 있다. 거래 식별자들(266)의 예들은 그들이 생성됨에 따라 거래들에 할당되는 순차 번호들, 거래 레코드(263)의 해시들 등을 포함할 수 있다.
거래 목적지(269)는 거래의 자금들이 예치되는 계좌 및 금융 기관을 나타낸다. 따라서, 거래 목적지(269)는 기관 식별자(229) 및 계좌 식별자(예를 들어, 신용 계좌 식별자(236) 또는 통화 계좌 식별자(249)) 둘 다를 포함할 수 있다.
거래 금액(273)은 거래 또는 이체에 수반되는 자금들의 총 금액을 나타낼 수 있다. 일부 구현예들에서, 거래 금액(273)은 하나의 계좌로부터 다른 계좌로 이체되는 자금의 금액을 나타낼 수 있다. 다른 구현예들에서, 추가적인 수수료들 또는 요금들(예를 들어, 처리 수수료들 또는 교환 수수료들)은 또한 거래 금액(273)에 포함될 수 있다.
클라이언트 디바이스(100)는 네트워크(213)에 결합될 수 있는 복수의 클라이언트 디바이스들(100)을 나타낸다. 클라이언트 디바이스(100)는 컴퓨터 시스템과 같은 프로세서-기반 시스템을 포함할 수 있다. 그러한 컴퓨터 시스템은 퍼스널 컴퓨터(예를 들어, 데스크탑 컴퓨터, 랩탑 컴퓨터, 또는 유사한 디바이스), 모바일 컴퓨팅 디바이스(예를 들어, 개인 휴대용 단말기들, 셀룰러폰들, 스마트폰들, 웹 패드들, 태블릿 컴퓨터 시스템들, 뮤직 플레이어들, 휴대용 게임 콘솔들, 전자책 리더들, 및 유사한 디바이스들), 미디어 재생 디바이스들(예를 들어, 미디어 스트리밍 디바이스들, BluRay® 플레이어들, 디지털 비디오 디스크(DVD) 플레이어들, 셋톱 박스들, 및 유사한 디바이스들), 비디오게임 콘솔, 또는 유사한 능력을 갖는 다른 디바이스들의 형태로 구현될 수 있다. 클라이언트 디바이스(100)는 하나 이상의 디스플레이들(103), 예컨대 액정 디스플레이들(LCDs), 가스 플라즈마-기반 평탄 패널 디스플레이들, 유기 발광 다이오드(OLED) 디스플레이들, 전기영동 잉크("E-ink") 디스플레이들, 프로젝터들, 또는 다른 타입들의 디스플레이 디바이스들을 포함할 수 있다. 일부 경우들에서, 디스플레이(103)는 클라이언트 디바이스(100)의 구성요소일 수 있거나 유선 또는 무선 연결(connection)을 통해 클라이언트 디바이스(100)에 연결될 수 있다.
클라이언트 디바이스(100)는 다양한 애플리케이션들 예컨대 클라이언트 애플리케이션(276) 또는 다른 애플리케이션들을 실행하도록 구성될 수 있다. 클라이언트 애플리케이션(276)은 발행인 컴퓨팅 환경(203), 피어 컴퓨팅 환경(206), 통합자 컴퓨팅 환경(209), 또는 다른 서버들에 의해 제공되는 네트워크 콘텐츠에 액세스하기 위해 클라이언트 디바이스(100)에서 실행될 수 있으며, 그것에 의해 디스플레이(103) 상에 사용자 인터페이스(106)를 렌더링한다. 이를 위해, 클라이언트 애플리케이션(276)은 브라우저, 전용 애플리케이션, 또는 다른 실행파일(executable)을 포함할 수 있고, 사용자 인터페이스(106)는 네트워크 페이지, 애플리케이션 스크린, 또는 사용자 입력을 획득하기 위한 다른 사용자 메커니즘을 포함할 수 있다. 클라이언트 디바이스(100)는 이메일 애플리케이션들, 소셜 네트워킹 애플리케이션들, 워드 프로세서들, 스프레드시트들, 또는 다른 애플리케이션들과 같은 클라이언트 애플리케이션(276)을 넘어선 애플리케이션들을 실행하도록 구성될 수 있다.
다음으로, 네트워크 환경(200)의 다양한 구성요소들의 동작의 일반적인 설명이 제공된다. 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용의 예가 다음 단락들에서 제공되지만, 다른 상호작용들 및 동작들이 가능하다. 네트워크 환경(200)의 구성요소들 사이의 다양한 상호작용들의 보다 상세화된 설명은 도 3 내지 도 8의 후속 논의에 제공된다.
우선, 지급인(payer)은 발행인 지불 서비스(216)에게 요청을 송신하기 위해 그 또는 그녀의 클라이언트 디바이스(100) 상에서 실행되는 클라이언트 애플리케이션(276)을 사용할 수 있을 것이다. 요청은 수령인에 대한 연락처 정보, 수령인에게 지불할 금액, 및 수령인에게 지불하기 위해 사용하는 신용 또는 요금(charge) 계좌를 지정할 수 있을 것이다. 따라서, 요청은 수령인에 대한 셀룰러 폰 번호 또는 이메일 주소, 거래 금액(273), 및 신용 계좌 식별자(236)를 포함할 수 있을 것이다.
그 다음, 발행인 지불 서비스(216)는 거래 식별자(266)에 대해 통합자 서비스(256)로 요청을 송신할 수 있을 것이다. 이에 응답하여, 통합자 서비스(256)는 거래 식별자(266)를 포함하는 거래 레코드(263)를 생성할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 거래 식별자(266)를 발행인 지불 서비스(216)에 반환할 수 있을 것이다.
다음으로, 발행인 지불 서비스(216)는 수령인의 클라이언트 디바이스(100)로 메시지를 송신할 수 있을 것이다. 예를 들어, 발행인 지불 서비스(216)는 지급인에 의해 제공된 수령인에 대한 연락처 정보로 단문 메시지 서비스(SMS) 메시지 또는 이-메일을 송신할 수 있을 것이다. 메시지는 지급인이 수령인에게 자금들을 송신하고 있다는 통지를 포함할 수 있을 것이다. 메시지는 또한 거래 식별자(266) 및 통합자 서비스(256)에 의해 제공되는 웹 페이지 또는 인터페이스에 대한 링크를 포함할 수 있을 것이다. 수령인이 자금들을 청구하기를 원하는 경우, 수령인은 링크를 클릭, 선택, 또는 달리 따라갈 수 있을 것이다.
수령인이 링크를 따라가면, 통합자 서비스(256)는 웹 페이지 또는 유사한 사용자 인터페이스(106)를 수령인에게 제공할 수 있을 것이다. 사용자 인터페이스(106) 내에서, 수령인은 지원 금융 기관들의 리스트로부터 그 또는 그녀의 금융 기관을 선택할 수 있을 것이다. 그 다음, 수령인은 선택된 금융 기관으로 그 또는 그녀의 피어 사용자 계좌(246)에 대한 그 또는 그녀의 인증 크리덴셜들(233b)을 제공할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 수령인을 대신하여 선택된 금융 기관으로 인증을 수행하고 통화 계좌 식별자들(249)의 리스트를 검색할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 수령인에게 수령인이 자금들을 수령하기를 원하는 통화 계좌에 대한 통화 계좌 식별자(249)를 선택하도록 프롬프트하기 위해 사용자 인터페이스(106)를 갱신할 수 있을 것이다.
수령인이 통화 계좌 식별자(249)를 선택하였으면, 통합자 서비스(256)는 통화 계좌 식별자(249) 및 기관 식별자(229b)를 발행인 지불 서비스(216)에게 제공할 수 있다. 통합자 서비스(256)는 또한 발행인 지불 서비스(216)가 통화 계좌 식별자(249) 및 기관 식별자(229b)가 연관되는 복수의 거래들로부터 어떠한 개별 거래를 식별하는 것을 돕기 위해 거래 식별자(266)를 제공할 수 있을 것이다.
통화 계좌 식별자(249) 및 기관 식별자(229b)의 수신 시에, 발행인 지불 서비스(216)는 수령인의 계좌로 자금을 배치하기 위해 은행간 거래 네트워크를 사용하여 이체를 개시할 수 있을 것이다. 일부 타입들의 이체들의 경우, 자금들은 에스크로 계좌(223a)로부터 수령인의 계좌로 이체될 수 있을 것이다. 다른 타입들의 이체들에서, 자금들은 에스크로 계좌들(223a 및 223b) 사이에서 이체될 수 있을 것이다. 그 다음, 발행인 지불 서비스(216)는 지급인의 신용 계좌에 할당되는 신용 한도를 감소시킬 수 있을 것이다. 일부 구현예들에서, 신용 한도는 지급인의 신용 계좌로부터 즉시 또는 거의 즉시 감소될 수 있을 것이다. 다른 구현예들에서, 신용 한도는 발행인 지불 서비스(216)가 이체가 완료되었다는 표시 또는 확인을 수신하면 감소될 수 있을 것이다. 신용 한도가 이체가 발생하기 전에 감소될 수 있는 구현들이 또한 있을 수 있다. 그러한 구현들은 자금들의 이체가 나중에 기관들 사이에서 결제되지 않는 경우에도, 자금들의 즉시 이체의 효과를 허용할 수 있을 것이다.
유사하게, 수령인은 다른 개인이 수령인에게 지불하도록 발행인 지불 서비스(216)로 요청을 송신하기 위해 그 또는 그녀의 클라이언트 디바이스(100) 상에서 실행되는 클라이언트 애플리케이션(276)을 사용할 수 있을 것이다. 요청은 수령인에 대한 연락처 정보, 지급인이 수령인에게 지급하도록 수령인이 요청하고 있는 금액, 및 자금들이 예치되어야 하는 수령인의 신용 계좌의 신용 계좌 식별자(236)를 지정할 수 있을 것이다. 따라서, 요청은 수령인에 대한 셀룰러 폰 번호 또는 이메일 주소, 거래 금액(273), 및 수령인의 신용 계좌 식별자(236)를 포함할 수 있을 것이다.
그 다음, 발행인 지불 서비스(216)는 거래 식별자(266)에 대해 통합자 서비스(256)로 요청을 송신할 수 있을 것이다. 이에 응답하여, 통합자 서비스(256) 거래 식별자(266)를 포함하는 거래 레코드(263)를 생성할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 거래 식별자(266)를 발행인 지불 서비스(216)로 반환할 수 있을 것이다.
다음으로, 발행인 지불 서비스(216)는 지급인의 클라이언트 디바이스(100)로 메시지를 송신할 수 있을 것이다. 예를 들어, 발행인 지불 서비스(216)는 단문 메시지 서비스(SMS) 메시지 또는 이-메일을 수령인에 의해 제공된 지급인에 대한 연락처 정보로 송신할 수 있을 것이다. 메시지는 수령인이 지급인으로부터 자금들을 요청하고 있다는 통지를 포함할 수 있을 것이다. 메시지는 또한 거래 식별자(266) 및 통합자 서비스(256)에 의해 제공되는 웹 페이지 또는 인터페이스에 대한 링크를 포함할 수 있을 것이다. 지급인이 요청된 자금들을 송신하기를 원하는 경우, 지급인은 링크를 클릭, 선택, 또는 달리 따를 수 있을 것이다.
지급인이 링크를 따르면, 통합자 서비스(256)는 웹 페이지 또는 유사한 사용자 인터페이스(106)를 지급인에게 제공할 수 있을 것이다. 사용자 인터페이스(106) 내에서, 지급인은 지원 금융 기관들의 리스트로부터 그 또는 그녀의 금융 기관을 선택할 수 있을 것이다. 그 다음, 지급인은 선택된 금융 기관으로 그 또는 그녀의 피어 사용자 계좌(246)에 대한 그 또는 그녀의 인증 크리덴셜들(233b)을 제공할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 지급인을 대신하여 선택된 금융 기관으로 인증하고 통화 계좌 식별자들(249)의 리스트를 검색할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 지급인이 요청된 자금들을 수령인에게 송신하기를 원하는 통화 계좌에 대한 통화 계좌 식별자(249)를 선택하도록 지급인에게 프롬프트하기 위해 사용자 인터페이스(106)를 갱신할 수 있을 것이다. 지급인이 통화 계좌 식별자(249)를 선택하였으면, 통합자 서비스(256)는 피어 기관에 대한 기관 식별자(229b) 및 통화 계좌 식별자(249)를 발행인 지불 서비스(216)에게 송신할 수 있다. 통합자 서비스(256)는 또한 발행인 지불 서비스(216)가 통화 계좌 식별자(249) 및 기관 식별자(229b)가 연관되는 복수의 거래들로부터 어떤 개별 거래를 식별하는 것을 돕기 위해 거래 식별자(266)를 제공할 수 있을 것이다.
통화 계좌 식별자(249) 및 기관 식별자(229b)를 수신 시에, 발행인 지불 서비스(216)는 자금들의 이체를 개시하기 위해 피어 지불 서비스(239)로 요청을 송신할 수 있을 것이다. 요청은 발행인 지불 서비스(216)와 연관되는 기관 식별자(229a) 및 에스크로 계좌(223a)에 대한 계좌 번호 또는 식별자를 포함할 수 있을 것이다. 요청은 또한 자금들이 지불될 이체 또는 통화 계좌 식별자(249)와 연관되는 거래 식별자(266)를 포함할 수 있을 것이다.
이에 응답하여, 피어 지불 서비스(239)는 기관 자금 이체를 지급인의 계좌로부터 또는 에스크로 계좌(223b)로부터 에스크로 계좌(223a)로 개시할 수 있을 것이다. 발행인 지불 서비스(216)가 자금들의 수령을 확인하면, 신용은 신용 계좌 식별자(236)에 의해 식별되는 수령인의 신용 계좌에 적용될 수 있을 것이다. 그러나, 일부 구현예들에서, 신용은 기관 자금 이체의 개시 전에 신용 계좌에적용될 수 있을 것이다. 이것은 자금들의 이체가 나중에 기관들 사이에서 결제되지 않는 경우에도, 수령인 또는 지급인이 즉시 또는 실시간 자금 이체를 경험하는 것을 허용할 수 있을 것이다.
많은 유형들의 이체들은 임의의 이러한 예들에서 발행인 지불 서비스(216) 또는 피어 지불 서비스(239)에 의해 사용될 수 있을 것이다. 예를 들어, 실시간 총액 결제(real time gross settlement; RTGS) 시스템들은 자금들의 즉시 이체를 제공하기 위해 사용될 수 있을 것이다. RTGS 시스템들의 예들은 Fedwire와 같은 송금 시스템들을 포함한다. 그러나, 일괄 처리된, 순 결제 시스템들은 자금들의 이체가 시간에 민감하지 않은 곳에서 사용될 수 있을 것이다. 일괄 처리된, 순 결제 시스템들의 예들은 자동 어음 교환소(automated clearinghouse; ACH) 네트워크들, 예컨대 FedACH 또는 전자 결제 네트워크(Electronic Payments Network; EPN)를 포함한다.
다음의 도 3을 참조하면, 신용 카드 발행인과 피어 금융 기관 사이에서 자금들을 이체하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 3의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공한다는 것이 이해된다. 대안으로서, 도 3의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(301)로부터 시작하여, 클라이언트 애플리케이션(276a)은 수령인에게 자금들을 지불하기 위해 발행인 지불 서비스(216)로 요청을 송신할 수 있다. 요청은 자금들이 지불될 신용 계좌 식별자(236), 지불될 자금들의 금액, 수령인의 신원 및 이에 대한 연락처 정보(예를 들어, 폰 번호 또는 이메일 주소), 및 잠재적 다른 정보를 포함할 수 있다.
박스(303) 상으로 이동하여, 발행인 지불 서비스(216)는 거래를 인가할 수 있다. 예를 들어, 발행인 지불 서비스(216)는 신용 계좌 식별자(236)와 연관되는 신용 한도가 수령인에 대한 자금들의 지불을 허용하기 위해 충분한 신용 금액을 가지고 있는지를 평가할 수 있을 것이다. 발행인 지불 서비스(216)가 거래를 인가할 수 없는 경우, 상호작용들의 시퀀스는 중지될 수 있다.
그 다음, 박스(306)에서, 발행인 지불 서비스(216)는 거래 식별자(266)에 대해 통합자 서비스(256)로 요청을 송신할 수 있다. 이에 응답하여, 통합자 서비스(256)는 거래 식별자(266)를 생성하고 이를 발행인 지불 서비스(216)에 제공할 수 있다. 발행인 지불 서비스(216)는 피어 금융 서비스에 의해 유지되는 통화 계좌로, 신용 계좌 식별자(236)에 의해 식별되는 바와 같이, 발행인 지불 서비스(216)가 지급인의 신용 계좌로부터 자금들을 지불하기 위한 요청을 나중에 결정하거나 매핑하는 것을 허용하기 위해 거래 식별자(266)를 일시적으로 저장할 수 있다.
다음의 박스(309)에서, 발행인 지불 서비스(216)는 지불 요청 메시지를 수령인에게 송신한다. 예를 들어, 지급인이 박스(301)에서 수령인에 대한 모바일 폰 번호를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 단문 메시지 서비스(SMS) 메시지를 수령인의 클라이언트 디바이스(100)로 송신할 수 있을 것이다. 다른 예로서, 지급인이 박스(303)에서 수령인에 대한 이메일 주소를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 이메일을 수령인에 대한 이메일 주소로 송신할 수 있을 것이다.
그러나, 일부 구현예들에서, 박스(309)의 기능은 통합자 서비스(256)에 의해 수행될 수 있을 것이다. 예를 들어, 거래 식별자(266)를 생성한 후, 통합자 서비스(256)는 지불 요청 메시지를 수령인에게 송신할 수 있을 것이다. 이러한 구현예들에서, 발행인 지불 서비스(216)는 박스(306)에서 통합자 서비스(256)에게 관련된 연락처 정보(예를 들어, 폰 번호 또는 이메일 주소)를 제공하였을 것이다.
지불 요청 메시지는 다수의 아이템들을 포함할 수 있다. 예를 들어, 지불 요청 메시지는 통합자 서비스(256) 및 거래 식별자(266)에 대한 어드레스를 포함하는 URI(uniform resource indicator)을 포함할 수 있을 것이다. 지불 요청 메시지는 지급인이 자금들을 수령인에게 송신하고 있다는 메시지 또는 표시, 자금들의 금액, 지급인의 신원 등을 더 포함할 수 있을 것이다.
후속 박스(313)에서, 클라이언트 애플리케이션(276b)은 수령인을 인증하고 수령인으로부터 자금들이 예치될 통화 계좌 식별자(249)의 식별 또는 선택을 획득할 수 있다. 예를 들어, 수령인이 지불 요청 메시지에 포함되는 링크를 선택할 때, 클라이언트 디바이스(100)는 클라이언트 애플리케이션(276b)을 개방하고 클라이언트 애플리케이션(276b)에게 요청을 통합자 서비스(256)에게 송신하도록 지시할 수 있을 것이다. 요청은 박스(309)에서 이전에 송신된 URI에 포함되는 거래 식별자(266)를 포함할 수 있을 것이다.
그 다음, 통합자 서비스(256)는 수령인에게 그 또는 그녀의 금융 기관을 식별하도록 프롬프트하기 위해 클라이언트 애플리케이션(276b)에 응답을 제공할 수 있을 것이다. 이러한 응답은 예를 들어, 수령인이 금융 기관을 선택하는 것을 허용하기 위해 클라이언트 애플리케이션(276b)이 사용자 인터페이스(106)를 렌더링하게 할 수 있을 것이다. 수령인이 금융 기관을 선택한 후, 그 다음, 통합자 서비스(256)는 수령인으로부터 인증 크리덴셜들(233b) 획득하기 위해 클라이언트 애플리케이션(276b)을 프롬프트할 수 있을 것이다.
수령인이 인증 크리덴셜들(233b)을 통합자 서비스(256)로 공급한 후, 통합자 서비스(256)는 수령인을 대신하여 피어 지불 서비스(239)로 인증할 수 있을 것이다. 인증되면, 그 다음, 통합자 서비스(256)는 수령인과 연관되는 피어 지불 서비스(239)로부터 통화 계좌 식별자들(249)의 리스트를 요청할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 수령인이 지급인으로부터의 자금들이 예치될 계좌를 선택하도록 클라이언트 애플리케이션(276b)으로 통화 계좌 식별자들(249)(예를 들어, 당좌 예금 계좌, 저축 계좌 등에 대한 계좌 번호들)의 리스트를 제공할 수 있을 것이다. 수령인이 통화 계좌 식별자(249)를 선택하면, 클라이언트 애플리케이션(276b)은 그것을 통합자 서비스(256)로 제공할 수 있다. 예를 들어, 수령인이 클라이언트 애플리케이션(276b) 내로부터 그 또는 그녀의 당좌 예금 계좌를 선택하면, 클라이언트 애플리케이션(276b)은 선택된 계좌로서 통화 계좌 식별자(249)를 통합자 서비스(256)에게 제공할 수 있을 것이다.
다음의 박스(316)에서, 통합자 서비스(256)는 선택된 통화 계좌 식별자(249)를 발행인 지불 서비스(216)에게 제공하고 통화 계좌 식별자(249)에 의해 식별되는 계좌를 유지하는 피어 금융 기관에 대해 기관 식별자(229b)를 제공할 수 있을 것이다. 예를 들어, 수령인이 박스(313)에서, 예시은행(ExampleBank)으로 인증하고 예시은행의 그 또는 그녀의 당좌 예금 계좌를 자금들이 예치되어야 하는 계좌로서 선택하였다면, 그 다음, 통합자 서비스(256)는 예시은행의 ABA 라우팅 번호 및 수령인의 당좌 예금 계좌 번호를 예시은행에 제공할 수 있을 것이다. 통합자 서비스(256)는 또한 발행인 지불 서비스(216)가 통화 계좌 식별자(249) 및 기관 식별자(229b)가 연관되어야 하는 어떤 지불을 결정하는 것을 허용하기 위해 박스(316)에서 거래 식별자(266)를 반환할 수 있을 것이다.
그 다음, 박스(319)에서, 발행인 지불 서비스(216)는 에스크로 계좌(223a)로부터 수령인의 통화 계좌로 또는 피어 금융 기관의 에스크로 계좌(223b)로 자금들의 이체를 개시할 수 있다. 예를 들어, 발행인 지불 서비스(216)는 박스(316a)에서 제공되는 통화 계좌 식별자(249) 및 기관 식별자(229b)에 의해 식별되는 바와 같이, 에스크로 계좌(223a)로부터 ACH 지불을 개시하고 수령인의 피어 금융 기관에 통화 계좌를 지정할 수 있을 것이다. 다른 예로서, 발행인 지불 서비스(216)는 에스크로 계좌(223a)로부터 전신 송금 결제(wire transfer payment)를 개시하고 수령인의 피어 금융 기관에 통화 계좌를 지정할 수 있을 것이다. 그러나, 발행인 지불 서비스(216)는 자금들을 이체하기 위해 임의의 일괄 처리된, 순 결제 또는 실시간 총액 결제 지불 시스템을 사용할 수 있다.
후속 박스(323)에서, 발행인 지불 서비스(216)는 에스크로 계좌(223a)로부터 피어 금융 기관에 의해 유지되는 수령인의 통화 계좌로 이체되는 자금의 금액과 동일한 금액을 지급인의 신용 계좌 내의 이용가능한 신용 금액으로부터 공제할 수 있다. 이것은 발행인을 대신하여 이체되는 자금의 금액에 대해 발행인에 대한 지급인의 부채(liability)를 생성할 수 있다. 그 결과, 지급인은 신용 카드 거래 네트워크를 사용해야 하는 것 없이 다른 당사자(예를 들어, 다른 개인)에게 그 또는 그녀의 신용 계좌(예를 들어, 신용 카드)로부터의 지불이 이루어지게 할 수 있다. 반면에, 박스(326)에서 피어 지불 서비스(239)는 발행인으로부터 수령되는 자금들을 수령인의 통화 계좌로 입금하거나 달리 예치할 수 있다. 박스들(323 및 326)에 도시되는 기능은 시퀀스 다이어그램에서 일찍 구현될 수 있을 것이라는 점이 주목되어야 한다. 예를 들어, 각각의 신용들(credits) 및 직불들(debits)은 박스(316)에서 계좌 정보의 이동 중 박스(319)에서 자금들의 이체 전에 발생할 수 있을 것이다.
다음의 도 4를 참조하면, 제1 신용 발행인과 제2 신용 발행인(예를 들어, 신용 카드 발행인들) 사이에서 자금들을 이체하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 4의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공하는 것으로 이해된다. 대안으로서, 도 4의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(303)와 유사한 박스(403)로부터 시작하여, 클라이언트 애플리케이션(276a)은 수령인에게 자금들을 지불하기 위해 발행인 지불 서비스(216a)로 요청을 송신할 수 있다. 요청은 자금들이 지불될 신용 계좌 식별자(236), 지불될 자금들의 금액, 수령인의 신원 및 이에 대한 연락처 정보(예를 들어, 폰 번호 또는 이메일 주소), 및 잠재적 다른 정보를 포함할 수 있다.
박스(306)와 유사한 박스(406), 발행인 지불 서비스(216a)는 거래 식별자(266)에 대해 통합자 서비스(256)에 요청을 송신할 수 있다. 이에 응답하여, 통합자 서비스(256)는 거래 식별자(266)를 생성하고 이를 발행인 지불 서비스(216)에 제공할 수 있다. 발행인 지불 서비스(216a)는 다른 발행인에 의해 유지되는 다른 통화 계좌로, 신용 계좌 식별자(236)에 의해 식별되는 바와 같이, 발행인 지불 서비스(216a)가 지급인의 신용 계좌로부터 자금들을 지불하기 위한 요청을 나중에 결정하거나 매핑하는 것을 허용하기 위해 거래 식별자(266)를 일시적으로 저장할 수 있다.
박스(309)와 유사한 다음의 박스(409)에서, 발행인 지불 서비스(216a)는 지불 요청 메시지를 수령인에게 송신한다. 예를 들어, 지급인이 박스(403)에서 수령인에 대한 모바일 폰 번호를 제공하였다면, 그 다음, 발행인 지불 서비스(216a)는 단문 메시지 서비스(SMS) 메시지를 수령인의 클라이언트 디바이스(100)로 송신할 수 있을 것이다. 다른 예로서, 지급인이 박스(403)에서 수령인에 대한 이메일 주소를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 이메일을 수령인에 대한 이메일 주소로 송신할 수 있을 것이다.
그러나, 일부 구현예들에서, 박스(409)의 기능은 통합자 서비스(256)에 의해 수행될 수 있을 것이다. 예를 들어, 거래 식별자(266)를 생성한 후, 통합자 서비스(256)는 지불 요청 메시지를 수령인에게 송신할 수 있을 것이다. 이러한 구현예들에서, 발행인 지불 서비스(216)는 박스(306)에서 통합자 서비스(256)에게 관련된 연락처 정보(예를 들어, 폰 번호 또는 이메일 주소)를 제공하였을 것이다.
그 다음, 박스(313)와 유사한 박스(413)에서, 클라이언트 애플리케이션(276b)은 수령인을 인증하고 수령인으로부터 자금들이 입금될 신용 계좌 식별자(236)의 식별 및 선택을 획득할 수 있다. 예를 들어, 수령인이 지불 요청 메시지에 포함되는 링크를 선택할 때, 클라이언트 디바이스(100)는 클라이언트 애플리케이션(276b)을 개방하고 클라이언트 애플리케이션(276b)에게 요청을 통합자 서비스(256)에게 송신하도록 지시할 수 있을 것이다. 요청은 박스(409)에서 이전에 송신된 URI에 포함되는 거래 식별자(266)를 포함할 수 있을 것이다.
그 다음, 통합자 서비스(256)는 수령인에게 그 또는 그녀의 신용 계좌(예를 들어, 신용 카드)의 발행인과 같은, 그 또는 그녀의 금융 기관을 식별하도록 프롬프트하기 위해 클라이언트 애플리케이션(276b)에게 응답을 제공할 수 있을 것이다. 이러한 응답은 예를 들어, 수령인이 금융 기관을 선택하는 것을 허용하기 위해 클라이언트 애플리케이션(276b)이 사용자 인터페이스(106)를 렌더링하게 할 수 있을 것이다. 수령인이 금융 기관을 선택한 후, 그 다음, 통합자 서비스(256)는 클라이언트 애플리케이션(276b)에게 수령인으로부터 인증 크리덴셜들(233a) 획득하도록 프롬프트할 수 있을 것이다.
수령인이 인증 크리덴셜들(233a)을 통합자 서비스(256)에게 공급한 후, 통합자 서비스(256)는 수령인을 대신하여 발행인 지불 서비스(216b)로 인증할 수 있을 것이다. 인증되면, 그 다음, 통합자 서비스(256)는 수령인과 연관되는 발행인 지불 서비스(216b)로부터 통화 계좌 식별자들(236)의 리스트를 요청할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 수령인이 지급인으로부터의 자금들이 입금될 계좌를 선택하도록 클라이언트 애플리케이션(276b)으로 신용 계좌 식별자들(236)(예를 들어, 당좌 예금 계좌, 저축 계좌 등에 대한 계좌 번호들)의 리스트를 제공할 수 있을 것이다. 수령인이 신용 계좌 식별자(236)를 선택하면, 클라이언트 애플리케이션(276b)은 그것을 통합자 서비스(256)에게 제공할 수 있으며, 이는 선택된 신용 계좌 식별자(236)를 발행인 지불 서비스(216b)로 중계할 수 있을 것이다. 예를 들어, 수령인이 클라이언트 애플리케이션(276b) 내로부터 특정 신용 카드 계좌를 선택하면, 클라이언트 애플리케이션(276b)은 선택된 계좌로서 각각의 신용 카드 번호를 통합자 서비스(256)에 제공할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 지급인과 수령인 사이의 거래의 향후 조정을 위해 이러한 신용 카드 번호를 발행인 지불 서비스(216b)에게 제공할 수 있을 것이다.
박스(316)와 유사한 박스(416)에서, 통합자 서비스(256)는 선택된 신용 계좌 식별자(236)를 발행인 지불 서비스(216)에 제공하고 신용 계좌 식별자(236)에 의해 식별되는 계좌를 유지하는 수령인의 피어 금융 기관에 대해 기관 식별자(229a)를 제공할 수 있을 것이다. 예를 들어, 수령인이 박스(413)에서, 예시은행(ExampleBank)으로 인증하였고 자금들이 입금되어야 하는 계좌로서 예시은행에서 그 또는 그녀의 당좌 예금 계좌를 선택하였다면, 그 다음, 통합자 서비스(256)는 예시은행의 ABA 라우팅 번호 및 예시은행에 의해 유지되는 에스크로 계좌(223a)의 번호를 제공할 수 있을 것이다. 통합자 서비스(256)는 또한 발행인 지불 서비스(216a)가 에스크로 계좌(223a) 및 기관 식별자(229a)의 계좌 번호가 연관되어야 하는 어떤 지불을 결정하는 것을 허용하기 위해 박스(416)에서 거래 식별자(266)를 반환할 수 있을 것이다.
박스(319)와 유사한 다음의 박스(419)에서, 발행인 지불 서비스(216a)는 지급인의 신용 발행인의 에스크로 계좌(223a)로부터 수령인의 신용 발행인의 에스크로 계좌(223a)로 자금들의 이체를 개시할 수 있다. 발행인 지불 서비스(216)가 2개의 별개의 발행인 지불 서비스들(216a 및 216b)이 자금들을 교환하고 있는, 에스크로 계좌(223a)를 갖는 것으로서 도 2에서 이전에 예시되었지만, 각각의 발행인 지불 서비스(216)는 별개의 에스크로 계좌(223a)를 갖는 것으로 이해된다. 예를 들어, 발행인 지불 서비스(216a)는 에스크로 계좌들(223a) 사이에서 ACH 지불을 개시할 수 있을 것이다. 다른 예로서, 발행인 지불 서비스(216a)는 에스크로 계좌(223a)와 수령인에 대한 계좌 사이에서 전신 송금 지불(wire transfer payment)을 개시할 수 있을 것이다. 그러나, 발행인 지불 서비스(216a)는 자금들을 이체하기 위해 임의의 일괄 처리된, 순 결제 또는 실시간 총액 결제 지불 시스템을 사용할 수 있다. 마찬가지로, 박스(421)에서, 수령인의 신용 발행인에 대한 발행인 지불 서비스(216b)는 그것의 각각의 에스크로 계좌(223a)에서 자금들을 수령할 수 있다.
그 다음, 박스(323)와 유사한 박스(423)에서, 발행인 지불 서비스(216a)는 에스크로 계좌들(223a) 사이에서 이체되는 자금의 금액과 동일한 금액을 지급인의 신용 계좌 내의 이용가능한 신용 금액으로부터 공제할 수 있다. 이것은 발행인을 대신하여 이체되는 자금의 금액에 대해 그 또는 그녀의 발행인에 대한 지급인의 부채(liability)를 생성할 수 있다. 그 결과, 지급인은 신용 카드 거래 네트워크를 사용해야 하는 것 없이 다른 당사자(예를 들어, 다른 개인)의 신용 계좌로 그 또는 그녀의 신용 계좌(예를 들어, 신용 카드)로부터의 지불이 이루어지게 할 수 있다. 박스들(423 및 426)에 도시되는 기능은 시퀀스 다이어그램에서 일찍 구현될 수 있을 것이라는 점이 주목되어야 한다. 예를 들어, 각각의 신용들(credits) 및 직불들(debits)은 박스(416)에서의 계좌 정보의 이전 중 박스(419)에서의 자금들의 이체 전에 발생할 수 있을 것이다.
한편, 박스(326)와 유사한 박스(426)에서, 발행인 지불 서비스(216b)는 발행인 지불 서비스(216a)로부터 수령되는 자금들을 수령인의 신용 계좌에 입금할 수 있다. 따라서, 박스(421)에서 에스크로 계좌(223a)에 수령되는 자금들은 그 또는 그녀의 신용 계좌 상에서 수령인의 미변제 잔고에 대한 지불 또는 신용으로서 카운트할 것이다. 그 결과, 수령인은 제3자들로부터 예금들을 수령하고 제3자들에게 지불들을 할 수 있는 거래 계좌로서 그 또는 그녀의 신용 계좌(예를 들어, 신용 카드)를 사용할 수 있다.
다음으로 도 5를 참조하면, 동일한 기관에 의해 발행되는 신용 계좌들(예를 들어, 신용 카드들) 사이에서 자금들을 이체하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 5의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공하는 것으로 이해된다. 대안으로서, 도 5의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(501)로부터 시작하여, 클라이언트 애플리케이션(276a)은 수령인에게 자금들을 지불하기 위해 발행인 지불 서비스(216)로 요청을 송신할 수 있다. 요청은 자금들이 지불될 신용 계좌 식별자(236), 지불될 자금들의 금액, 수령인의 신원을 포함할 수 있다. 지급인 및 수령인 둘 다는 이러한 예에서 동일한 발행인과 계좌들을 유지함에 따라, 발행인 지불 서비스(216)는 이미 수령인에 대한 연락처 정보를 가질 수 있다. 그러나, 지급인이 수령인의 선호 연락처 정보(예를 들어, 선호 폰 번호 또는 이메일 주소)를 알고 있는 경우, 그것은 또한 요청에 포함될 수 있다.
박스(503)로 진행하여, 발행인 지불 서비스(216)는 거래를 인가한다. 예를 들어, 발행인 지불 서비스(216)는 신용 계좌 식별자(236)와 연관되는 신용 한도가 수령인에 대한 자금들의 지불을 허용하기 위해 충분한 신용 금액을 가지고 있는지를 평가할 수 있을 것이다. 발행인 지불 서비스(216)가 거래를 인가할 수 없는 경우, 상호작용들의 시퀀스는 중지될 수 있다.
다음의 박스(506)에서, 발행인 지불 서비스(216)는 지불 요청 메시지를 수령인에게 송신할 수 있다. 예를 들어, 지급인이 박스(501)에서 수령인에 대한 모바일 폰 번호를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 단문 메시지 서비스(SMS) 메시지를 수령인의 클라이언트 디바이스(100)로 송신할 수 있을 것이다. 다른 예로서, 지급인이 박스(501)에서 수령인에 대한 이메일 주소를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 이메일을 수령인에 대한 이메일 주소로 송신할 수 있을 것이다. 메시지는 예를 들어, 발행인 지불 서비스(216)에 의해 제공되는 인증 페이지에 대한 링크를 포함할 수 있을 것이다.
그 다음, 박스(509)에서, 클라이언트 애플리케이션(276b)은 발행인 지불 서비스(216)로 인증할 수 있다. 예를 들어, 수령인은 클라이언트 애플리케이션(276b)이 발행인 지불 서비스(216)로 수령인을 인증하기 위해 사용할 수 있는, 클라이언트 애플리케이션(276b)의 사용자 인터페이스(106)로 인증 크리덴셜들(233a)을 입력할 수 있을 것이다. 인증에 응답하여, 발행인 지불 서비스(216)는 클라이언트 애플리케이션(276b)에게 수령인이 선택할 수 있는 하나 이상의 신용 계좌 식별자들(236)(예를 들어, 발행인과 수령인에 의해 보유되는 신용 카드 계좌들의 신용 카드 계좌 번호들)을 제공할 수 있을 것이다. 그 다음, 신용 계좌 식별자들(236)은 지급인으로부터 자금들을 수령하기 위한 계좌를 선택할 수 있는, 클라이언트 애플리케이션(276b)에 의해 사용자 인터페이스(106)에서 수령인에게 제시될 수 있다. 그 다음, 선택된 신용 계좌 식별자(236)는 발행인 지불 서비스(216)에게 제공될 수 있을 것이다.
그러나, 일부 구현예들에서, 박스들(506 및/또는 509)은 옵션일 수 있다. 예를 들어, 수령인이 지급인 또는 다른 당사자에 의해 이전에 지불받은 경우, 수령인의 신용 계좌에 대한 신용 계좌 식별자(236)와 같은 정보는 이미 수취인(payee) 디렉토리(221a)에 저장될 수 있다. 다른 예로서, 수령인이 발행인 지불 서비스(216)로 계좌를 이전에 생성한 경우, 수령인의 정보는 또한 수취인 디렉토리(221a)에 이미 저장될 수 있다. 그러한 경우들에서, 수령인에 대한 지불은 수취인 디렉토리(221a)에 저장되는 정보를 사용하여 박스(503)로부터 박스들(513 및 516)로 직접 처리될 수 있을 것이다.
박스들(513 및 516)에서, 지급인 및 수신인(receiver)의 신용 계좌들의 계좌 잔고들(balances)은 거래를 반영하기 위해 조정될 수 있을 것이다. 예를 들어, 단계(513)에서, 지급인의 신용 계좌는 자금들의 지불을 반영하기 위해 발행인 지불 서비스(216)에 의해 인출될 수 있을 것이다. 마찬가지로, 단계(516)에서, 수령인의 신용 계좌는 지불을 반영하기 위해 자금들의 각각의 금액만큼 입금될 수 있을 것이다. 그 결과, 2개의 신용 계좌 보유자들은 신용 카드 거래 네트워크를 사용해야 하는 것 없이 동일한 기관에서 임의의 다른 신용 계좌 보유자에게 자금들을 지불하거나 이로부터 자금들을 수령할 수 있다.
다음의 도 6a를 참조하면, 하나의 당사자가 자금들을 통화 계좌로부터 다른 당사자의 신용 계좌로 지불하는 것을 요청하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 6a의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공한다는 것이 이해된다. 대안으로서, 도 6a의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(603a)로부터 시작하여, 지불 요청은 클라이언트 애플리케이션(276a)에 의해 생성되고 발행인 지불 서비스(216)로 포워딩될 수 있다. 지불 요청은 클라이언트 애플리케이션(276a)에 의해 렌더링되는 사용자 인터페이스(106)와 상호작용하는 수령인에 의해 생성될 수 있을 것이다. 예를 들어, 신용 계좌 보유자(예를 들어, 신용 카드 보유자)는 피어 금융 기관에서의 통화 계좌 보유자(예를 들어, 은행 또는 중개 계좌 보유자)가 신용 계좌 보유자에게 특정 액수의 자금들(sum)를 지불하라는 요청을 생성할 수 있을 것이며, 이는 각각의 신용 계좌의 미변제 잔고에 대한 신용으로서 적용될 수 있을 것이다. 요청은 요청된 자금들의 금액, 지급인의 신원, 및 지급인의 연락처 정보를 포함할 수 있을 것이다. 완료되면, 지불 요청은 발행인 지불 서비스(216) 상으로 포워딩될 수 있다.
일부 구현예들에서, 다수의 지불 요청들은 박스(603a)에서 생성될 수 있을 것이다. 예를 들어, 수령인은 클라이언트 애플리케이션(276a)의 사용자 인터페이스(106) 내에 디스플레이되는 거래를 선택하고 그 또는 그녀가 다수의 개인들 사이의 거래를 분할하기를 원한다는 것을 나타낼 수 있을 것이다. 이것은 예를 들어, 수령인이 개인들의 그룹을 대신하여 구매하고 변제되도록 희망하는 경우에 발생할 수 있을 것이다. 이러한 예에서, 거래의 비용은 수령인에 의해 표시되는 바와 같이, 개인들 사이에서 분할될 수 있고, 각각의 지불 요청은 수령인에게 자금들을 빚진 각각의 개인 지급인에 대해 생성될 수 있을 것이다.
그 다음, 박스(606a)에서, 발행인 지불 서비스(216)는 거래 식별자(266)에 대해 통합자 서비스(256)로 요청을 송신할 수 있다. 이에 응답하여, 통합자 서비스(256)는 거래 식별자(266)를 생성하고 이를 발행인 지불 서비스(216)에 제공할 수 있다. 발행인 지불 서비스(216)는 수령인에 의해 유지되는 신용 계좌로, 각각의 통화 계좌 식별자(249)에 의해 식별되는 바와 같이, 발행인 지불 서비스(216)가 지급인의 신용 계좌로부터 자금들을 지불하기 위한 요청을 나중에 결정하거나 매핑하는 것을 허용하기 위해 거래 식별자(266)를 일시적으로 저장할 수 있다. 일부 경우들에서, 발행인 지불 서비스(216)는 통합자 서비스(256)에게 발행인 지불 서비스(216)와 연관되는 에스크로 계좌(223a)에 대한 계좌 번호를 제공할 수 있다.
박스(609a) 상으로 이동하여, 발행인 지불 서비스(216)는 지불 요청 메시지를 요청된 지급인에게 송신할 수 있다. 예를 들어, 신용 계좌 보유자가 박스(603a)에서 지급인에 대한 모바일 폰 번호를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 단문 메시지 서비스(SMS) 메시지를 지급인의 클라이언트 디바이스(100)로 송신할 수 있을 것이다. 다른 예로서, 신용 계좌 보유자가 박스(603a)에서 지급인에 대한 이메일 주소를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 이메일을 지급인에 대한 이메일 주소로 송신할 수 있을 것이다.
그러나, 일부 구현예들에서, 박스(609a)의 기능은 통합자 서비스(256)에 의해 수행될 수 있을 것이다. 예를 들어, 거래 식별자(266)를 생성한 후, 통합자 서비스(256)는 지불 요청 메시지를 수령인에게 송신할 수 있을 것이다. 이러한 구현예들에서, 발행인 지불 서비스(216)는 박스(606a)에서 통합자 서비스(256)에게 관련된 연락처 정보(예를 들어, 폰 번호 또는 이메일 주소)를 제공하였을 것이다.
지불 요청 메시지는 다수의 아이템들을 포함할 수 있다. 예를 들어, 지불 요청 메시지는 통합자 서비스(256) 및 거래 식별자(266)에 대한 어드레스를 포함하는 URI(uniform resource indicator)을 포함할 수 있을 것이다. 지불 요청 메시지는 신용 계좌 보유자가 지급인으로부터의 자금들, 자금들의 금액, 신용 계좌 보유자의 신원 등을 요청하고 있다는 메시지 또는 표시를 더 포함할 수 있을 것이다.
다음의 박스(613a)에서, 클라이언트 애플리케이션(276b)은 지급인을 인증하고 지급인으로부터 자금들이 지불될 통화 계좌 식별자(249)의 식별 또는 선택을 획득할 수 있다. 예를 들어, 지급인이 지불 요청 메시지에 포함되는 링크를 선택할 때, 지급인의 클라이언트 디바이스(100)는 클라이언트 애플리케이션(276b)을 개방하고 클라이언트 애플리케이션(276b)에게 요청을 통합자 서비스(256)에게 송신하도록 지시할 수 있을 것이다. 요청은 박스(609a)에서 이전에 송신된 URI에 포함되는 거래 식별자(266)를 포함할 수 있을 것이다.
그 다음, 통합자 서비스(256)는 지급인에게 그 또는 그녀의 금융 기관을 식별하도록 프롬프트하기 위해 응답을 클라이언트 애플리케이션(276b)에게 제공할 수 있을 것이다. 이러한 응답은 예를 들어, 지급인이 금융 기관을 선택하는 것을 허용하기 위해 클라이언트 애플리케이션(276b)이 사용자 인터페이스(106)를 렌더링하게 할 수 있을 것이다. 지급인이 금융 기관을 선택한 후, 그 다음, 통합자 서비스(256)는 지급인으로부터 인증 크리덴셜들(233b) 획득하기 위해 클라이언트 애플리케이션(276b)을 프롬프트할 수 있을 것이다.
지급인이 인증 크리덴셜들(233b)을 통합자 서비스(256)에 공급한 후, 통합자 서비스(256)는 지급인을 대신하여 피어 지불 서비스(239)로 인증할 수 있을 것이다. 인증되면, 그 다음, 통합자 서비스(256)는 지급인과 연관되는 피어 지불 서비스(239)로부터 통화 계좌 식별자들(249)의 리스트를 요청할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 지급인이 자금들이 지불될 계좌를 선택하도록 클라이언트 애플리케이션(276b)으로 통화 계좌 식별자들(249)(예를 들어, 당좌 예금 계좌, 저축 계좌 등에 대한 계좌 번호들)의 리스트를 제공할 수 있을 것이다. 지급인이 통화 계좌 식별자(249)를 선택하면, 클라이언트 애플리케이션(276b)은 그것을 통합자 서비스(256)에게 제공할 수 있다. 예를 들어, 지급인이 클라이언트 애플리케이션(276b) 내로부터 그 또는 그녀의 당좌 예금 계좌를 선택하면, 클라이언트 애플리케이션(276b)은 선택된 계좌로서 통화 계좌 식별자(249)를 통합자 서비스(256)에게 제공할 수 있을 것이다.
박스(616a)로 진행하여, 통합자 서비스(256)는 피어 지불 서비스(239)로, 박스(606a)에서 이전에 제공된, 각각의 발행인 지불 서비스(216)의 에스크로 계좌(223a)에 대한 계좌 식별자를 송신할 수 있다. 이것은 피어 지불 서비스(239)가 지급인을 대신하여 요청된 자금들을 이전에 식별된 통화 계좌로부터 신용 계좌 보유자에 대한 신용 발행인에게 지불하게 할 수 있다.
다음의 박스(619a)를 참고하면, 피어 지불 서비스(239)는 박스 (616)에서 식별되는 에스크로 계좌(223a)로, 선택된 통화 계좌 식별자(249)에 의해 식별되는 바와 같이, 지급인의 통화 계좌로부터의 자금들을 이체할 수 있다. 예를 들어, 피어 지불 서비스(239)는 지급인의 통화 계좌를 유지하는 피어 기관과 연관되는 에스크로 계좌(223b)로부터 에스크로 계좌(223a)로 자금들의 이체를 개시할 수 있다. 예를 들어, 피어 지불 서비스(239)는 ACH 지불을 에스크로 계좌(223b)로부터 에스크로 계좌(223a)로 개시할 수 있을 것이다. 다른 예로서, 피어 지불 서비스(239)는 전신 송금 지불(wire transfer payment)을 에스크로 계좌(223b)로부터 에스크로 계좌(223a)로 개시할 수 있을 것이다. 그러나, 피어 지불 서비스(239)는 자금들을 이체하기 위해 임의의 일괄 처리된, 순 결제 또는 실시간 총액 결제 지불 시스템을 사용할 수 있다. 일부 구현예들에서, 거래 식별자(266)는 또한 발행인 지불 서비스(216)가 에스크로 계좌(223a)로의 예금을 특정 거래와 연관시키는 것을 허용하기 위해 발행인 지불 서비스(216)로 피어 지불 서비스(239)에 의해 제공될 수 있다.
피어 지불 서비스(239)에 의한 자금들의 이체 후에, 피어 지불 서비스(239) 및 발행인 지불 서비스(216)는 각각의 계좌 잔고들을 조정할 수 있다. 예를 들어, 박스(623a)에서, 발행인 지불 서비스(216)는 에스크로 계좌(223a)로 이체되는 자금의 각각의 금액에 대한 신용(credit)을 신용 계좌 보유자의 신용 계좌의 미변제 잔고에 적용할 수 있을 것이다. 유사하게, 박스(626a)에서, 피어 지불 서비스(239)는 지급인의 통화 계좌로부터 자금들의 각각의 금액을 인출 또는 공제할 수 있을 것이다. 그 결과, 신용 계좌(예를 들어, 신용 카드 계좌)를 보유하는 개인은 임의의 개인의 통화 계좌들로부터 지불을 요청 및 수령할 수 있다. 더욱이, 거래는 기존의 신용 카드 네트워크들을 우회할 수 있다.
박스들(623a 및 626a)에 도시되는 기능은 시퀀스 다이어그램에서 일찍 구현될 수 있을 것이라는 점이 주목되어야 한다. 예를 들어, 각각의 신용들(credits) 및 직불들(debits)은 박스(616a)에서 계좌 정보의 이전 중 박스(619a)에서 자금들의 이체 전에 발생할 수 있을 것이다.
다음의 도 6a를 참조하면, 하나의 당사자가 자금들을 통화 계좌로부터 다른 당사자의 신용 계좌로 지불하는 것을 요청하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 따라서, 도 6b는 도 6a의 시퀀스 다이어그램에 대한 대안적인 예로서 관측될 수 있다. 도 6b의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공한다는 것이 이해된다. 대안으로서, 도 6b의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다. 박스들(603b 내지 609b)은 도 6a에서 이전에 설명된 박스들(603a 내지 613b)과 유사하다.
그러나, 박스(616b)에서, 통합자 서비스(256)는 피어 지불 서비스(239)의 에스크로 계좌(223b)에 대한 정보를 발행인 지불 서비스(216)에게 제공할 수 있다. 예를 들어, 박스(613b)에서 발생하는 인증 및 계좌 선택 프로세스 동안, 통합자 서비스(256)는 피어 지불 서비스(239)와 연관되는 에스크로 계좌(223b)에 대한 정보를 또한 요청하였을 수 있다. 그 다음, 통합자 서비스(256)는 이러한 데이터를 발행인 지불 서비스(216)에게 제공할 수 있을 것이다. 그러나, 이러한 동작들은, 때때로 발행인 지불 서비스(216)가 피어 지불 서비스(239)의 에스크로 계좌(223b)에 대한 관련된 정보를 이미 알 수 있음에 따라, 옵션이다. 이것은 예를 들어, 발행인과 피어 금융 기관 사이의 오래된 또는 기존 관계들의 결과로서 발생할 수 있을 것이다.
그 다음, 박스(619b)에서, 도 6a의 박스(619a)와 대조적으로, 발행인 지불 서비스(216)는 자금들의 지불을 에스크로 계좌(223b)로부터 에스크로 계좌(223a)로 개시할 수 있을 것이다. 예를 들어, 발행인 지불 서비스(216는 피어 지불(239)과 연관되는 에스크로 계좌(223b)에 대한 계좌 정보를 중재자(예를 들어, 자동 어음 교환 시스템 또는 전신 송금 서비스)에게 제공할 수 있을 것이며, 그 다음, 이는 지불 또는 결제가 박스(603b)에서 요청되는 자금들의 금액에 대해 에스크로 계좌들(223a 및 223b) 사이에서 발생하게 할 것이다.
박스들(623b 및 626b)에 도시되는 기능은 도 6a에서 이전에 설명된 바와 같은, 박스들(623a 및 626a)에 대해 설명되는 것과 유사하다. 박스들(623a 및 626a)과 같이, 박스들(623b 및 626b)에 도시되는 기능은 시퀀스 다이어그램에서 더 빨리 구현될 수 있을 것이다. 예를 들어, 각각의 신용들(credits) 및 직불들(debits)은 박스(616b)에서 계좌 정보의 이전 중 박스(619b)에서 자금들의 이체 전에 발생할 수 있을 것이다.
다음의 도 7a를 참조하면, 하나의 당사자가 자금들을 신용 계좌로부터 다른 당사자의 신용 계좌로 지불하는 것을 요청하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 7a의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 신용 카드 발행인과 피어 금융 기관 사이의 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공한다는 것이 이해된다. 대안으로서, 도 7a의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(703a)로부터 시작하여, 지불 요청은 클라이언트 애플리케이션(276a)에 의해 생성되고 발행인 지불 서비스(216)로 포워딩될 수 있다. 지불 요청은 클라이언트 애플리케이션(276a)에 의해 렌더링되는 사용자 인터페이스(106)와 상호작용하는 수령인에 의해 생성될 수 있을 것이다. 예를 들어, 신용 계좌 보유자(예를 들어, 신용 카드 보유자)는 다른 발행인에서의 신용 계좌 보유자가 신용 계좌 보유자에게 특정 액수의 자금들을 지불하라는 요청을 생성할 수 있을 것이며, 이는 각각의 신용 계좌의 미변제 잔고에 대한 신용으로서 적용될 수 있을 것이다. 요청은 요청된 자금들의 금액, 지급인의 신원, 및 지급인의 연락처 정보를 포함할 수 있을 것이다. 완료되면, 지불 요청은 발행인 지불 서비스(216) 상으로 포워딩될 수 있다.
일부 구현예들에서, 다수의 지불 요청들은 박스(703a)에서 생성될 수 있을 것이다. 예를 들어, 수령인은 클라이언트 애플리케이션(276a)의 사용자 인터페이스(106) 내에 디스플레이되는 거래를 선택하고 그 또는 그녀가 다수의 개인들 사이의 거래를 분할하기를 원한다는 것을 나타낼 수 있을 것이다. 이것은 예를 들어, 수령인이 개인들의 그룹을 대신하여 구매하고 변제되도록 희망하는 경우에 발생할 수 있을 것이다. 이러한 예에서, 거래의 비용은 수령인에 의해 표시되는 바와 같이, 개별 지급인들 사이에서 분할될 수 있고, 각각의 지불 요청은 수령인에게 자금들을 빚진 각각의 개별 지급인에 대해 생성될 수 있을 것이다.
그 다음, 박스(706a)에서, 발행인 지불 서비스(216a)는 거래 식별자(266)에 대해 통합자 서비스(256)에게 요청을 송신할 수 있다. 이에 응답하여, 통합자 서비스(256)는 거래 식별자(266)를 생성하고 이를 발행인 지불 서비스(216a)에게 제공할 수 있다. 발행인 지불 서비스(216a)는 발행인 지불 서비스(216a)가 지급인의 신용 계좌로부터 수령인의 신용 계좌로 자금들을 지불하기 위한 요청을 나중에 결정하거나 매핑하는 것을 허용하기 위해 거래 식별자(266)를 일시적으로 저장할 수 있다. 일부 경우들에서, 발행인 지불 서비스(216a)는 통합자 서비스(256)에게 발행인 지불 서비스(216)와 연관되는 에스크로 계좌(223a)에 대한 계좌 번호를 제공할 수 있다.
박스(709a) 상으로 이동하여, 발행인 지불 서비스(216a)는 지불 요청 메시지를 요청된 지급인에게 송신할 수 있다. 예를 들어, 신용 계좌 보유자가 박스(703a)에서 지급인에 대한 모바일 폰 번호를 제공하였다면, 그 다음, 발행인 지불 서비스(216a)는 단문 메시지 서비스(SMS) 메시지를 지급인의 클라이언트 디바이스(100)로 송신할 수 있을 것이다. 다른 예로서, 신용 계좌 보유자가 박스(703a)에서 지급인에 대한 이메일 주소를 제공하였다면, 그 다음, 발행인 지불 서비스(216a)는 이메일을 지급인에 대한 이메일 주소로 송신할 수 있을 것이다.
그러나, 일부 구현예들에서, 박스(709a)의 기능은 통합자 서비스(256)에 의해 수행될 수 있을 것이다. 예를 들어, 거래 식별자(266)를 생성한 후, 통합자 서비스(256)는 지불 요청 메시지를 수령인에게 송신할 수 있을 것이다. 이러한 구현예들에서, 발행인 지불 서비스(216)는 박스(706a)에서 통합자 서비스(256)에게 관련된 연락처 정보(예를 들어, 폰 번호 또는 이메일 주소)를 제공하였을 것이다.
지불 요청 메시지는 다수의 아이템들을 포함할 수 있다. 예를 들어, 지불 요청 메시지는 통합자 서비스(256) 및 거래 식별자(266)에 대한 어드레스를 포함하는 URI(uniform resource indicator)을 포함할 수 있을 것이다. 지불 요청 메시지는 신용 계좌 보유자가 지급인으로부터의 자금들, 자금들의 금액, 신용 계좌 보유자의 신원 등을 요청하고 있다는 메시지 또는 표시를 더 포함할 수 있을 것이다.
다음의 박스(713a)에서, 클라이언트 애플리케이션(276b)은 지급인을 인증하고 지급인으로부터 자금들이 지불될 통화 계좌 식별자(249)의 식별 또는 선택을 획득할 수 있다. 예를 들어, 지급인이 지불 요청 메시지에 포함되는 링크를 선택할 때, 지급인의 클라이언트 디바이스(100)는 클라이언트 애플리케이션(276b)을 개방하고 클라이언트 애플리케이션(276b)에게 요청을 통합자 서비스(256)에게 송신하도록 지시할 수 있을 것이다. 요청은 박스(709a)에서 이전에 송신된 URI에 포함되는 거래 식별자(266)를 포함할 수 있을 것이다.
그 다음, 통합자 서비스(256)는 지급인에게 그 또는 그녀의 금융 기관을 식별하도록 프롬프트하기 위해 클라이언트 애플리케이션(276b)에 응답을 제공할 수 있을 것이다. 이러한 응답은 예를 들어, 지급인이 금융 기관을 선택하는 것을 허용하기 위해 클라이언트 애플리케이션(276b)이 사용자 인터페이스(106)를 렌더링하게 할 수 있을 것이다. 지급인이 금융 기관을 선택한 후, 그 다음, 통합자 서비스(256)는 지급인으로부터 인증 크리덴셜들(233a) 획득하기 위해 클라이언트 애플리케이션(276b)을 프롬프트할 수 있을 것이다.
지급인이 인증 크리덴셜들(233a)을 통합자 서비스(256)에 공급한 후, 통합자 서비스(256)는 지급인을 대신하여 발행인 지불 서비스(216b)로 인증할 수 있을 것이다. 인증되면, 그 다음, 통합자 서비스(256)는 지급인과 연관되는 발행인 지불 서비스(216b)로부터 신용 계좌 식별자들(236)의 리스트를 요청할 수 있을 것이다. 그 다음, 통합자 서비스(256)는 지급인이 자금들이 지불될 계좌를 선택하도록 클라이언트 애플리케이션(276b)으로 신용 계좌 식별자들(236)(예를 들어, 당좌 예금 계좌, 저축 계좌 등에 대한 계좌 번호들)의 리스트를 제공할 수 있을 것이다. 지급인이 신용 계좌 식별자(236)를 선택하면, 클라이언트 애플리케이션(276b)은 그것을 통합자 서비스(256)에게 제공할 수 있다. 예를 들어, 지급인이 클라이언트 애플리케이션(276b) 내로부터 그 또는 그녀의 당좌 예금 계좌를 선택하면, 클라이언트 애플리케이션(276b)은 선택된 계좌로서 통화 계좌 식별자(249)를 통합자 서비스(256)에 제공할 수 있을 것이다.
박스(716a)로 진행하여, 통합자 서비스(256)는 발행인 지불 서비스(216b)로, 박스(706a)에서 이전에 제공되는, 각각의 발행인 지불 서비스(216)의 에스크로 계좌(223a)에 대한 계좌 식별자를 송신할 수 있다. 이것은 발행인 지불 서비스(216b)가 지급인을 대신하여 요청된 자금들을 이전에 식별된 신용 계좌로부터 신용 계좌 보유자에 대한 신용 발행인에게 지불하게 할 수 있다.
다음의 박스(719a)를 참조하면, 발행인 지불 서비스(216b)는 자금들을 발행인 지불 서비스(216b)와 연관되는 에스크로 계좌(223a)로부터 박스(716a)에서 식별되는 에스크로 계좌(223a)로 이체할 수 있다. 발행인 지불 서비스(216)가 2개의 별개의 발행인 지불 서비스들(216a 및 216b)이 자금들을 교환하고 있는, 에스크로 계좌(223a)를 갖는 것으로서 도 2에서 사전에 예시되었지만, 각각의 발행인 지불 서비스(216)는 별개의 에스크로 계좌(223a)를 갖는 것으로 이해된다. 예를 들어, 발행인 지불 서비스(216b)는 에스크로 계좌들(223a) 사이에서 ACH 지불을 개시할 수 있을 것이다. 다른 예로서, 발행인 지불 서비스(216b)는 에스크로 계좌들(223a) 사이에서 전신 송금(wire transfer)를 개시할 수 있을 것이다. 그러나, 발행인 지불 서비스(216b)는 자금들을 이체하기 위해 임의의 일괄 처리된, 순 결제 또는 실시간 총액 결제 지불 시스템을 사용할 수 있다. 일부 구현예들에서, 거래 식별자(266)는 또한 발행인 지불 서비스(216a)가 에스크로 계좌(223a)로의 예금을 특정 거래와 연관시키는 것을 허용하기 위해 발행인 지불 서비스(216a)로 발행인 지불 서비스(216b)에 의해 제공될 수 있다. 그러나, 대안적인 구현예들에서, 발행인 지불 서비스(216a)는 또한 자금들의 이체가 2개의 에스크로 계좌들(223a) 사이에서 발생하게 할 수 있을 것이다.
발행인 지불 서비스(216b)에 의한 자금들의 이체 후에, 발행인 지불 서비스(216b) 및 발행인 지불 서비스(216a)는 각각의 계좌 잔고들을 조정할 수 있다. 예를 들어, 박스(723a)에서, 발행인 지불 서비스(216a)는 에스크로 계좌(223a)로 이체되는 자금의 각각의 금액에 대한 신용(credit)을 신용 계좌 보유자의 신용 계좌의 미변제 잔고에 적용할 수 있을 것이다. 유사하게, 박스(726a)에서, 발행인 지불 서비스(216b)는 지급인의 통화 계좌로부터 자금들의 각각의 금액을 인출 또는 공제할 수 있을 것이다. 그 결과, 신용 계좌들(예를 들어, 신용 카드 계좌들)을 갖는 개인들은 임의의 개인의 신용 계좌들로부터 지불을 요청 및 수령할 수 있다. 더욱이, 거래는 기존의 신용 카드 네트워크들을 우회할 수 있다.
다음의 도 7b를 참조하면, 하나의 당사자가 자금들을 신용 계좌로부터 다른 당사자의 신용 계좌로 지불하는 것을 요청하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 따라서, 도 7b는 도 7a의 시퀀스 다이어그램에 대한 대안적인 예로서 관측될 수 있다. 도 7b의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 신용 카드 발행인과 피어 금융 기관 사이의 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공한다는 것이 이해된다. 대안으로서, 도 7b의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다. 박스들(703b 내지 709b)은 도 6a에서 이전에 설명된 바와 같은 박스들(703a 내지 713b)과 유사하다.
그러나, 박스(716b)에서, 통합자 서비스(256)는 발행인 지불 서비스(216b)의 에스크로 계좌(223a)에 대한 정보를 발행인 지불 서비스(216a)에 제공할 수 있다. 예를 들어, 박스(713b)에서 발생하는 인증 및 계좌 선택 프로세스 동안, 통합자 서비스(256)는 발행인 지불 서비스(216b)와 연관되는 에스크로 계좌(223a)에 대한 정보를 또한 요청하였을 수 있다. 그 다음, 통합자 서비스(256)는 이러한 데이터를 발행인 지불 서비스(216a)에 제공할 수 있을 것이다. 그러나, 이러한 동작들은, 때때로 발행인 지불 서비스(216a)가 발행인 지불 서비스(216b)의 에스크로 계좌(223a)에 대한 관련된 정보를 이미 알 수 있음에 따라, 옵션이다. 이것은 예를 들어, 발행인들 사이의 오래된 또는 기존 관계들의 결과로서 발생할 수 있을 것이다.
그 다음, 박스(719b)에서, 도 7a의 박스(719a)와 대조적으로, 발행인 지불 서비스(216a)는 자금들의 지불을 발행인 지불 서비스(216b)의 에스크로 계좌(223a)로부터 발행인 지불 서비스(216a)의 에스크로 계좌(223a)로 개시할 수 있을 것이다. 발행인 지불 서비스(216)는 2개의 별개의 발행인 지불 서비스들(216a 및 216b)이 자금들을 교환하고 있는, 에스크로 계좌(223a)를 갖는 것으로서 도 2에서 사전에 예시되었지만, 각각의 발행인 지불 서비스(216)는 별개의 에스크로 계좌(223a)를 갖는 것으로 이해된다. 예를 들어, 발행인 지불 서비스(216)는 발행인 지불 서비스(216b)과 연관되는 에스크로 계좌(223a)에 대한 계좌 정보를 중재자(예를 들어, 자동 결제 또는 송금 서비스)에 제공할 수 있을 것이며, 그 다음, 이는 지불 또는 결제가 박스(703b)에서 요청되는 자금들의 금액에 대해 에스크로 계좌들(223a) 사이에서 발생하게 할 것이다.
박스들(723b 및 726b)에 도시되는 기능은 도 7a에서 이전에 설명된 바와 같이, 박스들(723a 및 726a)에 대해 설명되는 것과 유사하다. 박스들(723a 및 726a)과 같이, 박스들(723b 및 726b)에 도시되는 기능은 시퀀스 다이어그램에서 더 빨리 구현될 수 있을 것이다. 예를 들어, 각각의 신용들(credits) 및 직불들(debits)은 박스(716b)에서 계좌 정보의 이전 중 박스(719b)에서 자금들의 이체 전에 발생할 수 있을 것이다.
다음의 도 8을 참조하면, 동일한 기관에 의해 발행되는 신용 계좌들(예를 들어, 신용 카드들) 사이에서 자금들을 이체하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 8의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공하는 것으로 이해된다. 대안으로서, 도 8의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(803)로부터 시작하여, 지불 요청은 클라이언트 애플리케이션(276a)에 의해 생성되고 발행인 지불 서비스(216)로 포워딩될 수 있다. 지불 요청은 클라이언트 애플리케이션(276a)에 의해 렌더링되는 사용자 인터페이스(106)와 상호작용하는 수령인에 의해 생성될 수 있을 것이다. 예를 들어, 신용 계좌 보유자(예를 들어, 신용 카드 보유자)는 동일한 기관에서의 다른 신용 계좌 보유자가 특정 액수의 금액들을 지불하라는 요청을 생성할 수 있을 것이며, 이는 각각의 신용 계좌의 미변제 잔고에 대한 신용으로서 적용될 수 있을 것이다. 요청은 요청된 자금들의 금액, 지급인의 신원, 및 지급인의 연락처 정보를 포함할 수 있을 것이다. 완료되면, 지불 요청은 발행인 지불 서비스(216) 상으로 포워딩될 수 있다.
일부 구현예들에서, 다수의 지불 요청들은 단계(803)에서 생성될 수 있을 것이다. 예를 들어, 수령인은 클라이언트 애플리케이션(276a)의 사용자 인터페이스(106) 내에 디스플레이되는 거래를 선택하고 그 또는 그녀가 다수의 개인들 사이의 거래를 분할하기를 원한다는 것을 나타낼 수 있을 것이다. 이것은 예를 들어, 수령인이 개인들의 그룹을 대신하여 구매하고 변제되도록 희망하는 경우에 발생할 수 있을 것이다. 이러한 예에서, 거래의 비용은 수령인에 의해 표시되는 바와 같이, 개인들 사이에서 분할될 수 있을 것이고, 각각의 지불 요청은 수령인에게 자금들을 빚진 각각의 개별 지급인에 대해 생성될 수 있을 것이다.
다음의 박스(806)에서, 발행인 지불 서비스(216)는 지불 요청 메시지를 지급인에게 송신할 수 있다. 예를 들어, 요청자가 박스(803)에서 수령인에 대한 모바일 폰 번호를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 단문 메시지 서비스(SMS) 메시지를 지급인의 클라이언트 디바이스(100)로 송신할 수 있을 것이다. 다른 예로서, 요청자가 박스(603a)에서 지급인에 대한 이메일 주소를 제공하였다면, 그 다음, 발행인 지불 서비스(216)는 이메일을 지급인에 대한 이메일 주소로 송신할 수 있을 것이다. 메시지는 예를 들어, 발행인 지불 서비스(216)에 의해 제공되는 인증 페이지에 대한 링크를 포함할 수 있을 것이다.
그 다음, 박스(809)에서, 클라이언트 애플리케이션(276b)은 발행인 지불 서비스(216)로 인증할 수 있다. 예를 들어, 지급인은 클라이언트 애플리케이션(276b)이 발행인 지불 서비스(216)로 지급인을 인증하기 위해 사용할 수 있는, 클라이언트 애플리케이션(276b)의 사용자 인터페이스(106)로 인증 크리덴셜들(233a)을 입력할 수 있을 것이다. 인증에 응답하여, 발행인 지불 서비스(216)는 클라이언트 애플리케이션(276b)에게 지급인이 선택할 수 있는 하나 이상의 신용 계좌 식별자들(236)(예를 들어, 발행인과 수령인에 의해 보유되는 신용 카드 계좌들의 신용 카드 계좌 번호들)을 제공할 수 있을 것이다. 그 다음, 신용 계좌 식별자들(236)은 자금들이 지불될 계좌를 선택할 수 있는, 클라이언트 애플리케이션(276b)에 의해 사용자 인터페이스(106)에서 지급인에게 제시될 수 있을 것이다. 그 다음, 선택된 신용 계좌 식별자(236)는 발행인 지불 서비스(216)에 제공될 수 있을 것이다.
박스(811) 상으로 이동하여, 발행인 지불 서비스(216)는 거래를 인가할 수 있다. 예를 들어, 발행인 지불 서비스(216)는 신용 계좌 식별자(236)와 연관되는 신용 한도가 수령인에 대한 자금들의 지불을 허용하기 위해 충분한 신용 금액을 가지고 있는지를 평가할 수 있을 것이다. 발행인 지불 서비스(216)가 거래를 인가할 수 없는 경우, 상호작용들의 시퀀스는 중지될 수 있다.
박스들(813 및 816)에서, 지급인 및 요청자(requestor)의 신용 계좌들의 계좌 잔고들은 거래를 반영하기 위해 조정될 수 있을 것이다. 예를 들어, 박스(813)에서, 지급인의 신용 계좌는 자금들의 지불을 반영하기 위해 발행인 지불 서비스(216)에 의해 인출될 수 있을 것이다. 마찬가지로, 박스(816)에서, 요청자의 신용 계좌는 지불을 반영하기 위해 자금들의 각각의 금액만큼 입금될 수 있을 것이다. 그 결과, 2개의 신용 계좌 보유자들은 신용 카드 거래 네트워크를 사용해야 하는 것 없이 동일한 기관에서 임의의 다른 신용 계좌 보유자에게 자금들을 지불하거나 이로부터 자금들을 수령할 수 있다.
다음의 도 9를 참조하면, 신용 카드 발행인과 피어 금융 기관 사이에서 자금들을 이체하기 위해 네트워크 환경(200)의 다양한 구성요소들 사이의 상호작용들의 동작의 일 예를 제공하는 시퀀스 다이어그램이 도시된다. 도 9의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 자금들의 이체를 구현하기 위해 이용될 수 있는 많은 상이한 유형들의 기능적 배열들의 예를 단순히 제공한다는 것이 이해된다. 대안으로서, 도 9의 시퀀스 다이어그램은 네트워크 환경(200) 내에서 구현되는 방법의 요소들의 예를 도시하는 것으로 관측될 수 있다.
박스(901)로부터 시작하여, 지급인은 수령인에 대한 지불을 생성하는 것과 관련되는 상세들을 선택할 수 있는 클라이언트 애플리케이션(276)과 상호작용할 수 있다. 예를 들어, 클라이언트 애플리케이션(276)을 사용하는 지급인은 클라이언트 디바이스(100)의 사용자 인터페이스(106)에 제시되는 수령인들의 리스트로부터 수령인을 선택할 수 있을 것이다. 수령인을 선택함으로써, 지급인은 또한 수령인에 대한 고유 식별자(예를 들어, 폰 번호, 이메일 주소, 또는 다른 식별자)를 선택할 수 있을 것이다. 지급인은 또한 수령인에게 지불할 자금들의 금액을 지정할 수 있을 것이다. 일부 경우들에서, 지급인은 또한 (예를 들어, 지급인이 다수의 신용 또는 후불 카드 계좌들을 갖는 경우) 지불을 위해 사용될 신용 계자에 대한 신용 계좌 식별자(236)를 지정할 수 있을 것이다.
그 다음, 박스(903)에서, 클라이언트 애플리케이션(276)은 수령인에 대한 지불을 개시할 수 있다. 예를 들어, 클라이언트 애플리케이션(276)은 발행인 지불 서비스(216)에 대한 수령인의 식별자, 지불될 자금들의 금액, 및 신용 계좌 식별자(236)를 제공할 수 있을 것이다.
다음의 박스(906)에서, 발행인 지불 서비스(216)는 거래를 인가할 수 있다. 예를 들어, 발행인 지불 서비스(216)는 신용 계좌 식별자(236)와 연관되는 신용 한도가 수령인에 대한 자금들의 지불을 허용하기 위해 충분한 신용 금액을 가지고 있는지를 평가할 수 있을 것이다. 발행인 지불 서비스(216)가 거래를 인가할 수 없는 경우, 상호작용들의 시퀀스는 중지될 수 있다.
박스(909) 상으로 이동하여, 발행인 지불 서비스(216)는 수령인에게 지불될 자금들의 금액에 대해 사용자의 신용 계좌를 인출할 수 있을 것이다. 예를 들어, 발행인 지불 서비스(216)는 신용 계좌 식별자(236)에 의해 식별되는 신용 계좌와 연관되는 신용 한도를 감소시킬 수 있을 것이다. 그러나, 이러한 동작은 시퀀스 다이어그램에서 나중에 수행될 수 있다는 점이 주목되어야 한다.
후속 박스(913)에서, 발행인 지불 서비스(216)는 지불에 대한 정보를 피어 지불 서비스(239)에 중계할 수 있다. 발행인 지불 서비스(216)는 수 개의 방법으로 적절한 피어 지불 서비스(239)를 식별할 수 있다. 예를 들어, 피어 지불 서비스(239)는 박스(901)에서 지급인에 의해 지정되었을 수 있다. 대안적으로, 발행인 지불 서비스(216)는 이전 거래에 기초하여 수령인에게 자금들을 이체할 때 상호작용하는 어떤 피어 지불 서비스(239)를 나타내는, 수령인에 대한 수취인 디렉토리(221a)에 레코드를 가질 수 있다.
그 다음, 박스(916)에서, 피어 지불 서비스(239)는 수령인과 연관되는 통화 계좌에 대응하는 자금들의 금액을 예치하거나 입금한다. 예를 들어, 수령인이 수령인에 대해 등록된 단일 통화 계좌를 갖는 경우, 피어 지불 서비스(239)는 예금 또는 신용을 그러한 계좌에 적용할 수 있을 것이다. 수령인이 다수의 통화 계좌들을 갖는 경우, 그 다음, 자금들은 수령인에 의해 지정되는 디폴트 통화 계좌에 입금되거나 예치될 수 있을 것이다.
다음의 박스들(919 및 923)에서, 자금들은 결국 발행인 지불 서비스(216) 및 피어 지불 서비스(239)와 연관되는 에스크로 계좌들(223a and 223b) 사이에서 이체된다. 이것은 주기적 간격들(예를 들어, 야간, 주간, 시간별 등)에서 발생하는 일괄 처리 순 결제 프로세스의 일부일 수 있을 것이다. 예를 들어, 피어 지불 서비스(239)는 발행인 지불 서비스(216)의 에스크로 계좌(223a)로부터 자금들을 풀링하기 위해 요청을 개시할 수 있을 것이다. 다른 예로서, 발행인 지불 서비스(216)는 피어 지불 서비스(239)의 에스크로 계좌(223b)로 자금을 푸시하거나 송신하기 위해 요청을 개시할 수 있을 것이다.
도 9에 도시된 시퀀스 다이어그램은 발행인에 의해 유지되는 신용 계좌와 피어 지불 서비스(239)에 의해 유지되는 통화 계좌 사이의 자금들을 이체하기 위한 프로세스의 예를 예시하지만, 실질적으로 유사한 프로세스가 2개의 별개의 발행인들에 의해 유지되는 신용 계좌들 사이의 자금들을 이체하기 위해 사용될 수 있을 것이라는 점이 주목되어야 한다. 그러나, 박스(916)에서 자금들을 통화 계좌에 예치하는 대신에, 신용이 수령인의 신용 계좌에 적용될 것이다.
이전에 논의된 다수의 소프트웨어 구성요소들은 각각의 컴퓨팅 디바이스들의 메모리에 저장되고 각각의 컴퓨팅 디바이스들의 프로세서에 의해 실행가능하다. 이러한 점에서, 용어 "실행가능한"은 프로세서에 의해 궁극적으로 실행될 수 있는 형태인 프로그램 파일을 의미한다. 실행가능한 프로그램들의 예들은 메모리의 랜덤 액세스 부분으로 로딩되고 프로세서에 의해 실행될 수 있는 형태의 머신 코드 또는 머신-판독가능 명령들로 변환될 수 있는 컴파일된 프로그램, 메모리의 랜덤 액세스 부분으로 로딩될 수 있고 프로세서에 의해 실행되는 객체 코드와 같은 적절한 포맷으로 표현될 수 있는 소스 코드, 또는 프로세서에 의해 실행될 메모리의 랜덤 액세스 부분에 명령들을 생성하기 위해 다른 실행가능한 프로그램에 의해 해석될 수 있는 소스 코드일 수 있다. 실행가능한 프로그램은 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 드라이브, 솔리드-스테이트 드라이브, 범용 직렬 버스(USB) 플래시 드라이브 메모리 카드, 광디스크 예컨대 컴팩트 디스크(CD) 또는 디지털 다목적 디스크(DVD), 플로피 디스크, 자기 테이프, 또는 다른 메모리 구성요소들을 포함하는, 메모리의 임의의 부분 또는 구성요소에 저장될 수 있다.
메모리는 휘발성 및 비휘발성 메모리 둘 다 그리고 데이터 저장 구성요소들을 포함한다. 휘발성 구성요소들은 전력의 손실 시에 데이터 값들을 유지하지 않는 것들이다. 비휘발성 구성요소들은 전력의 손실 시에 데이터를 유지하는 것들이다. 따라서, 메모리는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크 드라이브들, 솔리드-스테이트 드라이브들, USB 플래시 드라이브들, 메모리 카드 리더를 통해 액세스되는 메모리 카드들, 연관된 플로피 디스크 드라이브를 통해 액세스되는 플로피 디스크들, 광디스크 드라이브를 통해 액세스되는 광디스크들, 적절한 테이프 드라이브를 통해 액세스되는 자기 테이프들, 또는 다른 메모리 구성요소들, 또는 이러한 메모리 구성요소들 중 임의의 2개 이상의 조합을 포함할 수 있다. 게다가, RAM은 정적 랜덤 액세스 메모리(SRAM), 동적 랜덤 액세스 메모리(DRAM), 또는 자기 랜덤 액세스 메모리(MRAM) 및 다른 그러한 디바이스들을 포함할 수 있다. ROM은 프로그램가능 판독 전용 메모리(PROM), 소거가능 프로그램가능 판독 전용 메모리(EPROM), 전기적 소거가능 프로그램가능 판독 전용 메모리(EEPROM), 또는 다른 유사한 메모리 디바이스를 포함할 수 있다.
본원에 설명되는 애플리케이션들 및 시스템들은 위에 논의된 바와 같은 범용 하드웨어에 의해 실행되는 소프트웨어 또는 코드로 구현될 수 있지만, 대안으로서 동일한 것은 또한 전용 하드웨어 또는 소프트웨어/범용 하드웨어 및 전용 하드웨어의 조합으로 구현될 수 있다. 전용 하드웨어로 구현되는 경우, 각각은 다수의 기술들 중 하나 또는 그 조합을 이용하는 회로 또는 상태 머신으로서 구현될 수 있다. 이러한 기술들은 하나 이상의 데이터 신호들의 적용 시에 다양한 로직 기능들을 구현하기 위한 로직 게이트들을 갖는 이산 로직 회로들, 적절한 로직 게이트들을 갖는 주문형 집적 회로들(ASICs), 필드-프로그램가능 게이트 어레이들(FPGAs), 또는 다른 구성요소들 등을 포함할 수 있지만, 이에 제한되지 않는다. 그러한 기술들은 일반적으로 당업자에 의해 잘 알려져 있고, 따라서, 본원에 상세히 설명되지 않는다.
시퀀스 다이어그램들은 본 개시의 다양한 실시예들의 부분들의 구현의 기능 및 동작을 도시한다. 소프트웨어로 구현되는 경우, 각각의 블록은 지정된 로직 함수(들)을 구현하기 위한 프로그램 명령들을 포함하는 모듈, 세그먼트, 또는 코드의 부분을 나타낼 수 있다. 프로그램 명령들은 컴퓨터 시스템 내의 프로세서와 같은 적합한 실행 시스템에 의해 인식가능한 수치 명령들을 포함하는 프로그래밍 언어 또는 머신 코드로 작성되는 인간-판독가능 스테이트먼트들(statements)을 포함하는 소스 코드의 형태로 구현될 수 있다. 머신 코드는 다양한 프로세스들을 통해 소스 코드로부터 변환될 수 있다. 예를 들어, 머신 코드는 대응하는 애플리케이션의 실행 전에 컴파일러를 사용하여 소스 코드로부터 생성될 수 있다. 다른 예로서, 머신 코드는 인터프리터(interpreter)와의 실행과 동시에 소스 코드로부터 생성될 수 있다. 다른 접근법들이 또한 사용될 수 있다. 하드웨어로 구현되는 경우, 각각의 블록은 지정된 로직 함수 또는 기능들을 구현하기 위한 회로 또는 다수의 상호연결된 회로들을 나타낸다.
시퀀스 다이어그램들은 특정 실행 순서를 도시하지만, 실행 순선는 도시되는 것과 상이할 수 있다는 것이 이해된다. 예를 들어, 2개 이상의 블록들의 실행 순서는 도시된 순서에 대해 스크램블링될 수 있다. 또한, 연속으로 도시되는 2개 이상의 블록들은 동시에 또는 부분적인 동시발생으로 실행될 수 있다. 또한, 일부 실시예들에서, 시퀀스 다이어그램들에 도시되는 블록들 중 하나 이상은 스킵되거나 생략될 수 있다. 게다가, 임의의 수의 카운터들, 상태 변수들, 경고 세마포어들, 또는 메시지들은 향상된 유틸리티, 어카운팅, 성능 측정, 또는 문제해결 보조장치들을 제공하는 것 등을 위해 본원에 설명되는 논리적 흐름에 추가될 수 있을 것이다. 모든 그러한 변형들이 본 개시의 범위 내에 있다는 것이 이해된다.
또한, 소프트웨어 또는 코드를 포함하는 본원에 설명되는 임의의 로직 또는 애플리케이션은 컴퓨터 시스템 또는 다른 시스템의 프로세서와 같은 명령 실행 시스템에 의해 또는 이와 함께 사용을 위한 임의의 비-일시적 컴퓨터-판독가능 매체로서 구현될 수 있다. 이러한 의미에서, 로직(logic)은 컴퓨터-판독가능 매체로부터 인출되고 명령 실행 시스템에 의해 실행될 수 있는 명령들 및 선언들(declarations)을 포함하는 스테이트먼트들을 포함할 수 있다. 본 개시의 맥락에서, "컴퓨터-판독가능 매체"는 명령 실행 시스템에 의해 또는 이와 함께 사용하기 위해 본원에 설명되는 논리 또는 애플리케이션을 포함, 저장, 또는 유지할 수 있는 임의의 매체일 수 있다. 더욱이, 복수의 컴퓨팅 디바이스들(예를 들어,　저장 영역 네트워크들 또는 분산된 또는 클러스터링된 파일시스템들 또는 데이터베이스들)에 걸쳐 위치되는 분산된 컴퓨터-판독가능 매체의 집합은 또한 단일 비-일시적 컴퓨터-판독가능 매체로서 집합적으로 간주될 수 있다.
컴퓨터-판독가능 매체는 많은 물리적 매체 예컨대 자기, 광, 또는 반도체 매체 중 임의의 하나를 포함할 수 있다. 적합한 컴퓨터-판독가능 매체의 보다 구체적인 예들은 자기 테이프들, 자기 플로피 디스켓들, 자기 하드 드라이브들, 메모리 카드들, 솔리드-스테이트 드라이브들, USB 플래시 드라이브들, 또는 광디스크들을 포함하지만, 이에 제한되지 않는다. 또한, 컴퓨터-판독가능 매체는 정적 랜덤 액세스 메모리(SRAM) 및 동적 랜덤 액세스 메모리(DRAM)를 포함하는 랜덤 액세스 메모리(RAM), 또는 자기 랜덤 액세스 메모리(MRAM)일 수 있다. 게다가, 컴퓨터-판독가능 매체는 판독 전용 메모리(ROM), 프로그램가능 판독 전용 메모리(PROM), 소거가능 프로그램가능 판독 전용 메모리(EPROM), 전기적 소거가능 프로그램가능 판독 전용 메모리(EEPROM), 또는 임의의 타입의 메모리 디바이스일 수 있다.
또한, 본원에 설명되는 임의의 로직 또는 애플리케이션은 다양한 방식들로 구현되고 구조화될 수 있다. 예를 들어, 설명되는 하나 이상의 애플리케이션들은 단일 애플리케이션의 모듈들 또는 구성요소들로서 구현될 수 있다. 또한, 본원에 설명되는 하나 이상의 애플리케이션들은 공유된 또는 별도의 컴퓨팅 디바이스들 또는 그 조합으로 실행될 수 있다. 예를 들어, 본원에 설명되는 복수의 애플리케이션들은 동일한 컴퓨팅 디바이스에서, 또는 동일한 컴퓨팅 환경의 다수의 컴퓨팅 디바이스들에서 실행될 수 있다.
어구 "X, Y, 또는 Z 중 적어도 하나"와 같은 선언적(Disjunctive) 언어는, 달리 구체적으로 명시되지 않는 한, 항목, 용어 등이 X, Y, 또는 Z 중 적어도 하나, 또는 이들의 임의의 조합(예를 들어, X, Y, 또는 Z)일 수 있다는 것을 일반적으로 제시하기 위해 사용되는 바와 같은 맥락과 달리 이해된다. 따라서, 그러한 선언적 언어는 일반적으로 특정 실시예들이 X 중 적어도 하나, Y 중 적어도 하나, 또는 Z중 적어도 하나가 서로 존재하도록 요구한다는 것을 암시하도록 의도되지 않고, 암시하지 않아야 한다.
본 개시의 상술한 실시예들은 본 개시의 원리들의 명백한 이해를 위해 진술되는 구현들의 단지 가능한 예들이라는 것이 강조되어야 한다. 많은 변형들 및 수정들은 본 개시의 사상 및 원리들로부터 실질적으로 벗어나는 것 없이 상술한 실시예들에 대해 이루어질 수 있다. 모든 그러한 수정들 및 변형들은 본 개시의 범위 내에서 본원에 포함되고 다음의 청구항들에 의해 보호되도록 의도된다.
본 개시의 다양한 실시예들의 예시적 예들이 아래에 진술된다. 본 개시의 추가적인 실시예들은 선행 단락들에서 논의된다. 따라서, 본 개시의 범위는 다음 예시적 실시예들에 제한되는 것으로서 해석되지 않아야 한다.
실시예 1 - 시스템으로서, 프로세서 및 메모리를 포함하는 제1 컴퓨팅 디바이스; 및 메모리에 저장되는 머신-판독가능 명령들을 포함하며, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가 적어도: 제1 컴퓨팅 디바이스로부터 메시지 - 메시지는 자금 이체의 통지 및 자금 이체와 링크되는 거래 식별자를 포함함 -를 수신하고; 자금 이체를 처리하기 위한 요청 - 요청은 자금 이체를 위한 거래 식별자, 계좌 식별자 및 기관 식별자를 포함함 -을 제3 컴퓨팅 디바이스에 전송하게 하는, 시스템.
실시예 2 - 실시예 1에 있어서, 머신-판독가능 명령들은 메모리에 저장되며, 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가 적어도: 자금 이체가 완료되었다는 표시를 수신하고; 제1 컴퓨팅 디바이스의 디스플레이 상에, 자금 이체가 완료되었다는 표시를 렌더링하게 하는, 시스템.
실시예 3 - 실시예 1 또는 실시예 2에 있어서, 거래 식별자는 메시지에 포함되는 URI(uniform resource indicator) 내에 포함되고, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 적어도: URI에 어드레스되는 제1 요청을 송신하고; 제1 요청에 응답하여 기관들의 리스트를 수신하고; 기관들의 리스트로부터 기관의 선택에 응답하여, 기관에 대한 인증 크리덴셜들을 위한 제2 요청을 수신하고; 인증 크리덴셜들의 제출에 응답하여, 기관들의 리스트로부터 선택되는 기관에 의해 유지되는 통화 계좌들의 리스트를 수신하게 하는, 시스템.
실시예 4 - 실시예 3에 있어서, 제1 컴퓨팅 디바이스는 디스플레이 및 머신-판독가능 명령들을 포함하며, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 적어도: 디스플레이에 의해 렌더링되는 사용자 인터페이스 내에, 통화 계좌들의 리스트를 제시하고; 통화 계좌들의 리스트로부터 통화 계좌의 선택에 응답하여, 자금 이체를 처리하기 위한 요청에 통화 계좌에 대한 계좌 식별자를 포함하게 하는, 시스템.
실시예 5 - 실시예 1 내지 실시예 4 중 어느 것에 있어서, 머신-판독가능 명령들은 추가로 제1 컴퓨팅 디바이스가 적어도: 제1 컴퓨팅 디바이스의 디스플레이 상에 제시되는 사용자 인터페이스 내에, 자금 이체를 확이하기 위한 프롬프트를 렌더링하게 하고; 자금 이체를 처리하기 위한 요청이 자금 이체의 확인에 응답하여 송신되게 하는, 시스템.
실시예 6 - 실시예 1 내지 실시예 5 중 임의의 것에 있어서, 메시지는 단문 메시지 서비스(SMS) 메시지인, 시스템.
실시예 7 - 방법으로서, 제1 클라이언트 디바이스로부터, 특정 금액의 자금들을 특정 신용 계좌로부터 수령인에게 송신하기 위한 요청을 수신하는 단계; 컴퓨팅 디바이스로부터, 특정 금액의 자금들을 수령인에게 송신하기 위한 요청에 대한 거래 식별자를 요청하는 단계; 제1 통지를 제2 클라이언트 디바이스에 송신하는 단계 - 제1 통지는 거래 식별자를 포함하고 제2 클라이언트 디바이스는 수령인과 연관됨 -; 컴퓨팅 디바이스로부터, 수령인이 특정 금액의 자금들을 수락했다는 제2 통지를 수신하는 단계 - 제2 통지는 통화 계좌를 식별함 -; 및 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계를 포함하는, 방법.
실시예 8 - 실시예 7에 있어서, 특정 신용 계좌로부터 특정 금액의 자금들을 인출하는 단계를 더 포함하는, 방법.
실시예 9 - 실시예 7 또는 실시예 8에 있어서, 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계는 실시간 총액 결제(RTGS) 시스템을 통해 지불을 개시하는 단계를 더 포함하는, 방법.
실시예 10 - 실시예 7 또는 실시예 8에 있어서, 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계는 일괄 처리된, 순 결제 네트워크를 통해 지불을 개시하는 단계를 더 포함하는, 방법.
실시예 11 - 실시예 7 내지 실시예 10 중 임의의 것에 있어서, 특정 금액의 자금들에 대해 통화 계좌로 자금 이체를 개시하는 단계는 특정 금액의 자금들에 대해 에스크로 계좌로부터 통화 계좌로 지불을 개시하는 단계를 더 포함하는, 방법.
실시예 12 - 실시예 7 내지 실시예 11 중 임의의 것에 있어서, 특정 금액의 자금들을 특정 신용 계좌로부터 수령인에게 송신하기 위한 요청은 수취인에 대한 연락처 정보를 더 포함하고; 제1 통지를 제2 클라이언트 디바이스에 송신하는 단계는 제1 통지를 연락처 정보에 지정된 목적지로 송신하는 단계를 더 포함하는, 방법.
실시예 13 - 실시예 7 내지 실시예 12 중 임의의 것에 있어서, 거래 식별자를 포함하는 URI(uniform resource indicator)를 생성하는 단계; 및 제1 통지에 URI를 포함하는 단계를 더 포함하는, 방법.
실시예 14 - 실시예 7 내지 실시예 13 중 임의의 것에 있어서, 제2 통지는 거래 식별자를 더 포함하는, 방법.
실시예 15 - 실시예 7 내지 실시예 14 중 임의의 것에 있어서, 메시지를 제1 클라이언트 디바이스에 송신하는 단계를 더 포함하며, 메시지는 수령인이 특정 금액의 자금을 수락하였다는 것을 나타내는, 방법.
실시예 16 - 비-일시적 컴퓨터-판독가능 매체로서, 머신-판독가능 명령들을 포함하며, 머신-판독가능 명령들은, 제1 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가 적어도: 클라이언트 디바이스로부터 자금 이체를 처리하기 위한 요청을 수신하고 - 요청은 거래 식별자를 포함함 -; 기관들의 리스트를 클라이언트 디바이스에 제공하고; 클라이언트 디바이스로부터, 기관들의 리스트로부터 기관의 제1 선택을 수신하고; 클라이언트 디바이스로부터, 기관들의 리스트로부터 선택된 기관에 대한 인증 크리텐셜들을 요청하고; 인증 크리덴셜들의 수령에 응답하여, 기관들의 리스트로부터 선택되는 기관과 연관되는 계좌들의 리스트를 제공하고; 계좌들의 리스트로부터 계좌의 제2 선택을 수신하고; 제1 컴퓨팅 디바이스로, 거래 식별자, 기관들의 리스트로부터 선택되는 기관에 대한 제1 식별자, 및 계좌들의 리스트로부터 선택되는 계좌에 대한 제2 식별자를 제공하게 하는, 비-일시적 컴퓨터-판독가능 매체.
실시예 17 - 실시예 16에 있어서, 자금 이체를 처리하기 위한 요청은 제2 요청이고, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 제1 컴퓨팅 디바이스가: 거래 식별자에 대한 제1 컴퓨팅 디바이스로부터의 제1 요청에 응답하여 거래 식별자를 생성하고; 거래 식별자를 제1 컴퓨팅 디바이스에 제공하게 하는, 비-일시적 컴퓨터-판독가능 매체.
실시예 18 - 실시예 16 또는 실시예 17에 있어서, 거래 식별자는 자금 이체를 처리하기 위한 요청에서 클라이언트 디바이스에 의해 요청되는 URI(uniform resource identifier) 내에 포함되는, 비-일시적 컴퓨터-판독가능 매체.
실시예 19 - 실시예 16 내지 실시예 18 중 임의의 것에 있어서, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 인증 크리덴셜들을 사용하여 클라이언트 디바이스를 대신해서 기관들의 리스트로부터 선택되는 기관에 의해 동작되는 피어 지불 서비스로 적어도 인증하게 하는, 비-일시적 컴퓨터-판독가능 매체.
실시예 20 - 실시예들 16 내지 실시예 19 중 임의의 것에 있어서, 머신-판독가능 명령들은, 프로세서에 의해 실행될 때, 추가로 제1 컴퓨팅 디바이스가 자금 이체와 연관되는 에스크로 계좌에 대해 제1 컴퓨팅 디바이스로 제3 식별자를 적어도 제공하게 하는, 비-일시적 컴퓨터-판독가능 매체.

Claims (15)

  1. 시스템으로서,
    프로세서 및 메모리를 포함하는 제1 컴퓨팅 디바이스; 및
    상기 메모리에 저장되는 머신-판독가능 명령들을 포함하며, 상기 머신-판독가능 명령들은, 상기 프로세서에 의해 실행될 때, 상기 제1 컴퓨팅 디바이스가 적어도:
    제1 컴퓨팅 디바이스로부터 메시지를 수신하고 - 상기 메시지는 자금 이체 및 상기 자금 이체와 링크되는 거래 식별자의 통지를 포함함 -;
    상기 자금 이체를 처리하기 위한 요청 - 상기 요청은 상기 자금 이체를 위한 거래 식별자, 계좌 식별자 및 기관 식별자를 포함함 -을 제3 컴퓨팅 디바이스에게 송신하게 하는, 시스템.
  2. 제1항에 있어서,
    상기 머신-판독가능 명령들은 상기 메모리에 저장되며, 상기 프로세서에 의해 실행될 때, 상기 제1 컴퓨팅 디바이스가 적어도:
    상기 자금 이체가 완료되었다는 표시를 수신하고;
    상기 제1 컴퓨팅 디바이스의 디스플레이 상에, 상기 자금 이체가 완료되었다는 상기 표시를 렌더링하게 하는, 시스템.
  3. 제1항 또는 제2항에 있어서,
    상기 거래 식별자는 상기 메시지에 포함되는 URI(uniform resource indicator) 내에 포함되고, 상기 머신-판독가능 명령들은, 상기 프로세서에 의해 실행될 때, 추가로 상기 제1 컴퓨팅 디바이스가 적어도:
    상기 URI에 어드레스되는 제1 요청을 송신하고;
    상기 제1 요청에 응답하여 기관들의 리스트를 수신하고;
    상기 기관들의 리스트로부터 기관의 선택에 응답하여, 상기 기관에 대한 인증 크리덴셜들을 위한 제2 요청을 수신하고;
    상기 인증 크리덴셜들의 제출에 응답하여, 상기 기관들의 리스트로부터 선택되는 상기 기관에 의해 유지되는 통화 계좌들의 리스트를 수신하게 하는, 시스템.
  4. 제3항에 있어서,
    상기 제1 컴퓨팅 디바이스는 디스플레이 및 상기 머신-판독가능 명령들을 포함하며, 상기 프로세서에 의해 실행될 때, 추가로 상기 제1 컴퓨팅 디바이스가 적어도:
    상기 디스플레이에 의해 렌더링되는 사용자 인터페이스 내에, 상기 통화 계좌들의 리스트를 제시하며;
    상기 통화 계좌들의 리스트로부터 통화 계좌의 선택에 응답하여, 상기 자금 이체를 처리하기 위한 상기 요청에서 상기 통화 계좌에 대한 상기 계좌 식별자를 포함하게 하는, 시스템.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서,
    상기 머신-판독가능 명령들은 추가로 상기 제1 컴퓨팅 디바이스가 적어도:
    상기 제1 컴퓨팅 디바이스의 디스플레이 상에 제시되는 사용자 인터페이스 내에, 상기 자금 이체를 확인하기 위한 프롬프트를 렌더링하게 하고;
    상기 자금 이체를 처리하기 위한 상기 요청이 상기 자금 이체의 확인에 응답하여 송신되게 하는, 시스템.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서,
    상기 메시지는 단문 메시지 서비스(SMS) 메시지인, 시스템.
  7. 방법으로서,
    제1 클라이언트 디바이스로부터, 특정 금액의 자금들을 특정 신용 계좌로부터 수령인에게 송신하기 위한 요청을 수신하는 단계;
    컴퓨팅 디바이스로부터, 상기 특정 금액의 자금들을 상기 수령인에게 송신하기 위한 상기 요청에 대한 거래 식별자를 요청하는 단계;
    제1 통지를 제2 클라이언트 디바이스에 송신하는 단계 - 상기 제1 통지는 상기 거래 식별자를 포함하고 상기 제2 클라이언트 디바이스는 상기 수령인과 연관됨 -;
    상기 컴퓨팅 디바이스로부터, 상기 수령인이 상기 특정 금액의 자금들을 수락하였다는 제2 통지를 수신하는 단계 - 상기 제2 통지는 통화 계좌를 식별함 -; 및
    상기 특정 금액의 자금들에 대해 상기 통화 계좌로 자금 이체를 개시하는 단계를 포함하는, 방법.
  8. 제7항에 있어서,
    상기 특정 신용 계좌로부터 상기 특정 금액의 자금들을 인출하는(debiting) 단계를 더 포함하는, 방법.
  9. 제 7항 또는 제8항에 있어서,
    상기 특정 금액의 자금들에 대해 상기 통화 계좌로 상기 자금 이체를 개시하는 단계는 실시간 총액 결제(RTGS) 시스템을 통해 지불을 개시하는 단계를 더 포함하는, 방법.
  10. 제 7항 또는 제8항에 있어서,
    상기 특정 금액의 자금들에 대해 상기 통화 계좌로 상기 자금 이체를 개시하는 단계는 일괄 처리된, 순 결제 네트워크를 통해 지불을 개시하는 단계를 더 포함하는, 방법.
  11. 제7항 내지 제10항 중 어느 한 항에 있어서,
    상기 특정 금액의 자금들에 대해 상기 통화 계좌로 상기 자금 이체를 개시하는 단계는 상기 특정 금액의 자금들에 대해 에스크로 계좌로부터 상기 통화 계좌로 지불을 개시하는 단계를 더 포함하는, 방법.
  12. 제7항 내지 제11 중 어느 한 항에 있어서,
    상기 특정 금액의 자금들을 상기 특정 신용 계좌로부터 상기 수령인에게 송신하기 위한 상기 요청은 상기 수령인에 대한 연락처 정보를 더 포함하고;
    상기 제1 통지를 상기 제2 클라이언트 디바이스로 송신하는 단계는 상기 제1 통지를 상기 연락처 정보에 특정되는 목적지로 송신하는 단계를 더 포함하는, 방법.
  13. 제7항 내지 제12 중 어느 한 항에 있어서,
    상기 거래 식별자를 포함하는 URI(uniform resource indicator)를 생성하는 단계; 및
    상기 제1 통지에 상기 URI를 포함하는 단계를 더 포함하는, 방법.
  14. 제7항 내지 제13 중 어느 한 항에 있어서,
    상기 제2 통지는 상기 거래 식별자를 더 포함하는, 방법.
  15. 제7항 내지 제14 중 어느 한 항에 있어서,
    메시지를 상기 제1 클라이언트 디바이스에 송신하는 단계를 더 포함하며, 상기 메시지는 상기 수령인이 특정 금액의 자금들을 수락하였다는 것을 표시하는, 방법.
KR1020217011116A 2018-10-17 2019-10-17 신용 계좌를 사용한 이체 KR20210095121A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862746866P 2018-10-17 2018-10-17
US62/746,866 2018-10-17
PCT/US2019/056642 WO2020081758A1 (en) 2018-10-17 2019-10-17 Transfers using credit accounts

Publications (1)

Publication Number Publication Date
KR20210095121A true KR20210095121A (ko) 2021-07-30

Family

ID=70281223

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217011116A KR20210095121A (ko) 2018-10-17 2019-10-17 신용 계좌를 사용한 이체

Country Status (8)

Country Link
US (2) US20200126052A1 (ko)
EP (1) EP3867845A4 (ko)
JP (1) JP7376581B2 (ko)
KR (1) KR20210095121A (ko)
CN (1) CN113168623A (ko)
AU (2) AU2019361981A1 (ko)
SG (1) SG11202103751SA (ko)
WO (1) WO2020081758A1 (ko)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112926971B (zh) * 2021-03-23 2023-03-21 支付宝（中国）网络技术有限公司 基于储值卡的支付方法及装置
CN113222570B (zh) * 2021-04-21 2024-02-23 中国银联股份有限公司 支付方法、平台设备、系统及存储介质
WO2023196350A1 (en) * 2022-04-05 2023-10-12 Apple Inc. User interfaces for initiating transactions
US20240095694A1 (en) * 2022-09-21 2024-03-21 Step Mobile, Inc. Dynamically guiding users to request valid payments
EP4361931A1 (en) * 2022-10-28 2024-05-01 Mastercard International Incorporated System for enabling payments

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5546523A (en) * 1995-04-13 1996-08-13 Gatto; James G. Electronic fund transfer system
US20020052853A1 (en) 2000-02-10 2002-05-02 Fernando Munoz Transportation system for on-line transactions
JP2002279176A (ja) 2001-01-10 2002-09-27 Motohiko Nishida 口座照会システム
JP2003303284A (ja) 2002-04-08 2003-10-24 Hitachi Ltd 振込元口座選択支援システム、方法及び資産情報収集・管理サーバ
JP2004126907A (ja) 2002-10-02 2004-04-22 Bank Of Tokyo-Mitsubishi Ltd 決済金融機関選択装置、商取引サーバー、決済方法
US8417636B2 (en) * 2003-09-30 2013-04-09 Federal Reserve Bank Of Atlanta Approving ACH operator processing of ACH payments based on an originating depository financial institution's approved originator list
US8626626B2 (en) * 2006-01-09 2014-01-07 Interest Capturing Systems, Llc Method of and system for capturing interest earned on the monetary value of transferred monetary rights managed on an internet-based monetary rights transfer (MRT) network supported by a real-time gross settlement (RTGS) system
US8036959B2 (en) * 2006-10-23 2011-10-11 Dynatax Solutions, Ltd. System and method for automatic payment of estimated tax due
US20090265272A1 (en) * 2007-10-17 2009-10-22 The Western Union Company Money transfers utilizing a unique receiver identifier
US7720764B2 (en) 2008-02-01 2010-05-18 Kenneth James Emerson Method, device, and system for completing on-line financial transaction
US9715709B2 (en) * 2008-05-09 2017-07-25 Visa International Services Association Communication device including multi-part alias identifier
US10380573B2 (en) * 2008-09-30 2019-08-13 Apple Inc. Peer-to-peer financial transaction devices and methods
CA2739926A1 (en) 2008-10-09 2010-04-15 Dynatax Solutions, Ltd. Flexible and adaptive accrual method and apparatus for calculating and facilitating compliance with taxes and other obligations
US20110213707A1 (en) * 2010-03-01 2011-09-01 Fiserv, Inc. Systems and methods for facilitating person-to-person payments
US9336519B2 (en) * 2010-03-08 2016-05-10 Qualcom Incorporated System and method for determining appropriate redemption presentations for a virtual token associated with a stored value account
WO2012006358A2 (en) * 2010-07-06 2012-01-12 Boku, Inc. Systems and methods to receive funds via mobile devices
US8676708B1 (en) * 2010-10-29 2014-03-18 Aton Behavioral Finance, LLC Methods and apparatus for facilitating a financial transaction
JP6086900B2 (ja) 2011-04-05 2017-03-01 マイ ライフ アイティー（オーストラリア）プロプライエタリー リミテッドＭｙ Ｌｉｆｅ Ｉｔ （Ａｕｓｔ） Ｐｔｙ Ｌｔｄ 金融取引システム、金融取引方法およびコンピュータプログラム
US20130212003A1 (en) * 2012-02-10 2013-08-15 Intuit Inc. Mobile money order
US20140032399A1 (en) * 2012-07-30 2014-01-30 Ewise Systems Usa Inc. Electronic transaction system
US20140379562A1 (en) * 2013-06-19 2014-12-25 UniCache International Ltd. Intermediary payment and escrow system and method
US20160180304A1 (en) * 2014-12-17 2016-06-23 Bbva Compass Bancshares, Inc. Combined electronic payment and transfer for digital banking channels
US10104059B2 (en) * 2015-09-08 2018-10-16 Plaid Technologies, Inc. Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
US10387881B2 (en) * 2015-10-02 2019-08-20 Chicago Mercantile Exchange Inc. Virtual payment processing system
US20170364898A1 (en) * 2016-06-15 2017-12-21 SocialPay LLC Mobile payment system and method

Also Published As

Publication number Publication date
SG11202103751SA (en) 2021-05-28
EP3867845A1 (en) 2021-08-25
AU2023100031A6 (en) 2023-06-29
EP3867845A4 (en) 2022-07-06
AU2023100031A4 (en) 2023-05-04
WO2020081758A1 (en) 2020-04-23
AU2019361981A1 (en) 2021-05-13
JP7376581B2 (ja) 2023-11-08
JP2022511384A (ja) 2022-01-31
US20200126052A1 (en) 2020-04-23
US20230222463A1 (en) 2023-07-13
CN113168623A (zh) 2021-07-23

Similar Documents

Publication Publication Date Title
KR102634772B1 (ko) 비-금융 기관 시스템에서 안전 거래를 돕기 위한 시스템 및 방법
US10395247B2 (en) Systems and methods for facilitating a secure transaction at a non-financial institution system
AU2023100031A6 (en) Transfers using credit accounts
US11922414B2 (en) System and method for optimizing data writing to a blockchain
US11663564B1 (en) Creating and managing private electronic currency
US11978056B2 (en) Systems and methods for using shared databases for managing supplemental payment sources
EP2656290A1 (en) Deferred payment and selective funding and payments
US20130018778A1 (en) Virtual gift card
US20150248669A1 (en) Systems and methods for managing gift cards
US11727394B2 (en) Systems and methods for managing electronic transactions
AU2018204640A1 (en) Payment network with service provider directory function
US11847628B2 (en) User interfaces for using shared databases for managing supplemental payment sources
US10949848B2 (en) Access to ACH transaction functionality via digital wallets
US7917437B1 (en) Method for avoiding intermediated payment aggregation
US11270279B1 (en) Systems and methods for real-time biller posting services
KR102472450B1 (ko) 전자지갑을 이용한 결제대금 즉시 정산 서비스 제공 시스템
US20190325410A1 (en) Methods and system for selecting payment system for transaction routing
US20140201060A1 (en) Computer program, system, and method for providing a consumer with immediate access to funds via a hybridized secured line of credit
US20210374726A1 (en) Systems and methods for facilitating network messaging
JP7326536B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
KR20240028328A (ko) 신용 기반의 커미션 분할 전자 결제 네트워크를 위한 시스템 및 방법
Xu et al. Digital Payment Systems

Legal Events

Date Code Title Description
E601 Decision to refuse application
E601 Decision to refuse application
E801 Decision on dismissal of amendment