KR20220138367A - 스마트 계약 아키텍쳐를 갖는 분산형 원장 대출 시스템들 및 이를 위한 방법들 - Google Patents

스마트 계약 아키텍쳐를 갖는 분산형 원장 대출 시스템들 및 이를 위한 방법들 Download PDF

Info

Publication number
KR20220138367A
KR20220138367A KR1020227013995A KR20227013995A KR20220138367A KR 20220138367 A KR20220138367 A KR 20220138367A KR 1020227013995 A KR1020227013995 A KR 1020227013995A KR 20227013995 A KR20227013995 A KR 20227013995A KR 20220138367 A KR20220138367 A KR 20220138367A
Authority
KR
South Korea
Prior art keywords
token
item
loan
smart contract
guild
Prior art date
Application number
KR1020227013995A
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 루카츠 야쿱 슬리브카
Priority claimed from PCT/US2020/052728 external-priority patent/WO2021062160A1/en
Publication of KR20220138367A publication Critical patent/KR20220138367A/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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/004—Artificial life, i.e. computing arrangements simulating life
    • G06N3/006—Artificial life, i.e. computing arrangements simulating life based on simulated virtual individual or collective life forms, e.g. social simulations or particle swarm optimisation [PSO]
    • G06N7/005—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00—Computing arrangements based on specific mathematical models
    • G06N7/01—Probabilistic graphical models, e.g. probabilistic 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Abstract

본 개시내용의 실시예들에 따르면 탈집중형 대출 프로세스가 개시된다. 한 예시적인 방법은 담보 아이템을 나타내는 대출 프로세스를 개시하라는 요청을 수신하는 단계를 포함한다. 이 방법은 또한, 담보 아이템에 대응하는 담보 토큰을 생성하는 단계를 포함한다. 이 방법은 대출 프로세스 워크플로우에 따라 대출 프로세스를 관리하도록 구성된 대출 프로세스 스마트 계약 인스턴스를 인스턴스화하는 단계를 더 포함하고, 여기서, 대출 스마트 계약을 인스턴스화하도록 구성된 대출 프로세스 스마트 계약 인스턴스는, 대출자와 차용자가 합의한 대출의 하나 이상의 대출 조건 파라미터를 나타내는 대출 합의 통보를 수신하고 하나 이상의 대출 조건 파라미터에 기초하여 대출 상환을 관리한다. 담보 토큰은 대출이 완전히 상환되거나 채무불이행 상태가 될 때까지 분산형 원장에 저장된 에스크로 계정에서 잠금처리된다.

Description

스마트 계약 아키텍쳐를 갖는 분산형 원장 대출 시스템들 및 이를 위한 방법들
관련 출원의 상호참조
본 출원은 2019년 9월 26일 출원된 미국 가출원번호 제62/906,211호의 우선권을 주장한다. 상기 출원의 전체 개시내용은 참조에 의해 본 명세서에 포함된다.
분야
본 개시내용은, 블록체인들 등의 분산형 원장들 및 스마트 계약들을 활용하여 무신용 또는 실질적 무신용 담보 대출 생태계를 제공하는 탈집중형 대출 시스템들 및 방법들에 관한 것이다.
기존의 전자 상거래 프로세스는 불필요한 마찰을 수반한다. 이들 프로세스는 전형적으로, 원하는 것이 정확히 무엇인지, 어떻게 지불할지, 어디로 가야 하는지, 누구를 위한 것인지, 가능한 한 일찍 원한다는 사실을 알고서 구매자가 주문을 하는 이용 사례를 중심으로 설계되었다. 종래의 전자 상거래는 이들 구매 결정에서 많은 유연성을 허용하지 않는다. 예를 들어, 누군가를 위해 선물을 구매하기를 원하는 사용자는 일반적으로 웹사이트 또는 모바일 애플리케이션을 통해 구매하고, 그 의도된 수신자의 알려진 주소를 입력하고(그 알려진 주소에서 수신자가 전형적으로 팩키지를 수신하는지에 관계없이), 선물에 대해 지불한다. 그 다음, 수신자가 팩키지를 수신할 수 있는지에 관계없이 선물은 수신자에게 즉시 전송된다. 따라서, 구매 선택, 지불, 소유의 이전, 및 배달의 장소 및 타이밍을 포함한 그러나 이것으로 제한되지 않는 거래의 모든 측면에 대해 더 큰 유연성을 가진 전자 상거래 플랫폼에 대한 기술이 필요하다.
한편, 스킨, 무기, 도구, 및 많은 다른 아이템들이 구매되고 플레이어들간에 매매되는 비디오 게임 등에서, 가상 아이템은 점점 더 인기를 얻고 있다. 가상 아이템은, 다른 디지털 아이템과 마찬가지로, 물리적 아이템과 관련된 운송, 배달 및 보관에 대한 동일한 제약없이 소유, 이용 및 이전될 수 있다. 그러나, 가상 아이템의 가치는, 제작자가 잠재적으로 무한정의 사본을 생성하여 처음에는 희귀하던 아이템이 훨씬 덜 가치있게 될 수 있기 때문에 일시적일 수 있다. 가상 아이템 거래의 유연성과 편리함과 물리적 아이템 거래의 신뢰성과 가치 양쪽 모두를 제공하는 방법과 시스템을 갖춘 플랫폼에 대한 필요성이 존재한다.
대부분의 대출 시나리오에서, 차용자는 대출자로부터 대출을 받기를 원할 수 있다. 전형적으로, 대출자는 조건들에 동의하기 전에 대출을 보증하기 위해 담보를 요구할 수 있다. 전통적으로 차용자는 실제 전당포에 갈 수 있고, 전당포 소유자/대리인은, 아이템 인증, 아이템 평가, 아이템의 안전한 보관, 자금 대출을 담당하고, 대가로 차용자는 아이템을 담보로서 제공한다. 이 약정에서, 대출자와 차용자 양쪽 모두는 동시에 불리한 위치에 놓이게 된다. 대출자는 전당포 소유자/대리인이 담보 아이템에 공정한 평가 가치를 부여하고 선의로 담보 아이템을 보관할 것임을 신뢰해야 하는 반면, 전당포 대리인은 그 아이템이 진품이고 대출에 관한 차용자의 채무불이행시 전당포가 담보 아이템을 청산할 수 있다는 것을 신뢰해야 한다. 이들 딜레마로 인해, 차용자는 담보 아이템에 대해 훨씬 더 낮은 평가 가치가 주어지고 전당포 대리인은 더 많은 위험을 감수하게 되며, 그 조합의 결과 대출 금액이 낮아지고 이자율/대출 비용이 높아진다. 따라서, 전당포는 최후의 수단 대출 공급원으로서 간주되며 차용자는 종종 전당포로 가장한 기회주의적 사채업자에게 이용당한다. 따라서 무신용 또는 실질적 무신용 대출 생태계들을 제공하는 탈집중형 대출 시스템들이 필요하다.
스마트 계약 아키텍쳐로 탈집중형 대출 프로세스들을 용이화하기 위한 시스템들 및 방법들이 여기서 제공된다. 실시예들에서, 탈집중형 대출 프로세스는 담보 아이템이 인증되는 인증 스테이지, 담보 아이템이 평가되는 평가 스테이지, 아이템이 보관 시설에서 물리적으로 간수되는 보관 단계를 포함하는 일련의 스테이지들로 실행된다. 실시예에서, 담보 아이템이 안전하게 보관할 수 있지만 물리적 담보 아이템을 나타내는 디지털 담보 토큰을 이용하여 소유권이 이전될 수 있도록 담보 아이템은 "토큰화"된다. 실시예들에서, 스마트 계약 세트는 대출 프로세스 스테이지들 중 하나 이상을 포함하는 대출 프로세스를 관리한다.
본 개시내용의 일부 실시예에 따르면, 방법이 개시된다. 이 방법은, 하나 이상의 처리 디바이스에 의해, 차용자 디바이스로부터 대출 프로세스를 개시하라는 요청을 수신하는 단계를 포함하고, 이 요청은 담보 아이템을 나타내며, 담보 아이템은 유형의 아이템(tangible item)이다. 이 방법은 또한, 하나 이상의 처리 디바이스에 의해, 담보 아이템의 가상 표현을 생성하는 단계를 포함하고, 여기서 가상 표현은, 담보 아이템의 설명, 및 담보 아이템의 적어도 일부를 각각 묘사하는 하나 이상의 미디어 콘텐츠 중 적어도 하나를 포함한다. 이 방법은, 하나 이상의 처리 디바이스에 의해, 담보 아이템의 가상 표현에 기초하여 담보 아이템에 대응하는 담보 토큰을 생성하는 단계를 더 포함하고, 여기서, 담보 토큰은 한 세트의 노드 디바이스들에 걸쳐 분산된 분산형 원장에 저장된 디지털 토큰이다. 이 방법은, 하나 이상의 처리 디바이스에 의해, 대출 프로세스 워크플로우에 따라 대출 프로세스를 관리하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 대출 프로세스 스마트 계약 인스턴스를 인스턴스화하는 단계를 더 포함하고, 여기서, 대출 프로세스 스마트 계약 인스턴스는 분산형 원장을 저장하는 노드 디바이스 세트에 의해 실행된다. 대출 프로세스 스마트 계약 인스턴스는, 대출자와 차용자가 합의한 대출의 하나 이상의 대출 조건 파라미터를 나타내는 대출 합의 통보를 수신하고 하나 이상의 대출 조건 파라미터에 기초하여 대출 상환을 관리하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 대출 스마트 계약을 인스턴스화하도록 구성된다. 담보 토큰은, 대출이 전액 상환되었거나 대출이 채무불이행 상태에 있다고 대출 스마트 계약 인스턴스가 결정할 때까지 분산형 원장에 저장된 에스크로 계정에서 잠금처리된다.
실시예들에서, 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 담보 아이템을 인증하기 위해 인증자에 의해 수행되는 인증 작업을 관리하고 평가 작업이 완료되었음을 확정할 때 인증 통보를 발행하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 인증 스마트 계약 인스턴스를 인스턴스화하도록 구성된다. 이들 실시예들 중 일부에서, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스 워크플로우에 따라 인증 스마트 계약 인스턴스를 인스턴스화한다. 이들 실시예들 중 일부에서, 대출 프로세스 워크플로우는 분산형 원장에 저장된 시스템-레벨 거버넌스(system-level governance) 문서에서 정의되며, 여기서 시스템-레벨 거버넌스는 인증 작업을 개시하기 위한 조건을 정의한다. 일부 실시예에서, 대출 프로세스 스마트 계약 인스턴스는 차용자가 대출 프로세스를 개시할 것을 요청했음을 나타내는 요청 통보를 수신하는 것에 응답하여 인증 스마트 계약 인스턴스를 인스턴스화한다. 일부 실시예에서, 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 인증자의 인증자 디바이스로부터 인증 보고를 수신하도록 구성되고, 여기서, 인증 보고는, 인증자가 담보 아이템을 진품으로 간주했는지의 여부를 포함한, 인증 상태를 나타내는 인증자의 인증 의견을 포함한다. 이들 실시예들 중 일부에서, 인증 보고는 인증 의견을 뒷받침하기 위해 인증자에 의해 제공된 지원 문서를 더 포함한다. 이들 실시예들 중 일부에서, 인증 보고는 하나 이상의 각각의 2차 인증자에 의해 발행된 하나 이상의 확인(verification)을 더 포함하고, 여기서 각각의 확인은 각각의 2차 인증자가 인증 의견을 확정했음을 나타낸다. 이들 실시예들 중 일부에서, 인증 보고는, 인증 작업의 수행과 연관된 한 세트의 규칙들 및 규정들을 정의하는 인증 스테이지-레벨 거버넌스에 따라 정의되는 양식 템플릿(form template)으로부터 생성된다. 이들 실시예들 중 일부에서, 인증 스테이지-레벨 거버넌스는 인증 작업 워크플로우를 정의하고, 여기서 인증 작업 워크플로우는, 인증 작업을 완료하고 대출 프로세스가 준수하는 대출 프로세스 워크플로우의 다음 스테이지를 트리거하기 위해 충족되어야 하는 하나 이상의 조건을 포함한다. 이들 실시예들 중 일부에서, 인증 스테이지-레벨 거버넌스는 인증자가 길드 멤버인 인증 길드에 의해 적어도 부분적으로 정의된다. 이들 실시예들 중 일부에서, 인증 길드는 복수의 상이한 전문화된 인증 길드를 포함하고, 여기서 각각의 전문화된 인증 길드는 각각의 유형의 담보 아이템을 인증하는 것을 전문으로 한다. 이들 실시예들 중 일부에서, 복수의 상이한 전문화된 인증 길드는 다음을 포함하는 그룹의 적어도 서브세트를 포함한다: 시계 인증을 전문으로 하는 시계 인증 길드, 신발 인증을 전문으로 하는 신발 인증 길드, 핸드백 인증을 전문으로 하는 핸드백 인증 길드, 예술 작품 인증을 전문으로 하는 예술품 인증 길드, 스포츠 기념품 인증을 전문으로 하는 스포츠 기념품 인증 길드, 소장용 장난감 인증을 전문으로 하는 장난감 인증 길드, 보석 인증을 전문으로 하는 보석 인증 길드, 디자이너 의류 인증을 전문으로 하는 의류 인증 길드, 악기 인증을 전문으로 하는 악기 인증 길드, 희귀 또는 소장용 음반 인증을 전문으로 하는 음반 인증 길드, 와인 단위(예를 들어, 배럴 또는 병)의 인증을 전문으로 하는 와인 인증 길드, 위스키 단위(예를 들어, 배럴 또는 병)의 인증을 전문으로 하는 위스키 인증 길드, 및 한정판 자동차 인증을 전문으로 하는 자동차 인증 길드. 이들 실시예들 중 일부에서, 인증자는 상이한 전문화된 인증 길드들 중 한 전문화된 인증 길드에 속한다. 이들 실시예들 중 일부에서, 인증자에게는, 인증자가 속한 전문화된 인증 길드 및 담보 아이템의 아이템 유형에 기초하여 인증 작업이 할당된다. 일부 실시예에서, 인증 스테이지-레벨 거버넌스는 인증 스마트 계약 인스턴스가 인스턴스화된 인증 스마트 계약을 정의한다. 일부 실시예에서, 인증 스마트 계약 인스턴스는 인증자가 담보 아이템을 진품으로 간주했음을 나타내는 인증 보고에 응답하여 인증자의 계정으로부터 에스크로 계정으로의 소정 금액의 통화 토큰들 및/또는 토큰화된 토큰들의 에스크로잉(escrowing)을 개시한다. 일부 실시예에서, 에스크로잉된 금액의 적어도 일부는 대출 프로세스가 완료될 때까지 에스크로에 유지된다. 일부 실시예에서, 인증 스마트 계약 인스턴스는 인증자 디바이스로부터 인증 보고를 수신하는 것에 응답하여 인증 통보를 대출 프로세스 스마트 계약에 출력하고, 여기서 인증 통보는 대출 프로세스 스마트 계약 인스턴스가 대출 프로세스의 평가 스테이지를 개시하게 한다. 일부 실시예에서, 인증 스마트 계약 인스턴스는 또한, 인증 보고 및 인증 보고에 적어도 부분적으로 기초하여 생성되는 암호화 해시 값을 포함하는 데이터 블록을 생성하고; 데이터 블록을 분산형 원장에 기입하도록 구성된다. 일부 실시예에서, 인증자의 등급은 인증 작업과 연관된 결과에 기초하여 업데이트된다.
실시예들에서, 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 담보 아이템의 평가 가치를 결정하기 위해 평가자에 의해 수행되는 평가 작업을 관리하고 평가 작업이 완료되었음을 확정할 때 평가 통보를 발행하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 평가 스마트 계약 인스턴스를 인스턴스화하도록 구성된다. 이들 실시예들 중 일부에서, 대출 프로세스 스마트 계약은 대출 프로세스 워크플로우에 따라 평가 스마트 계약 인스턴스를 인스턴스화한다. 이들 실시예들 중 일부에서, 대출 프로세스 워크플로우는 분산형 원장에 저장된 시스템-레벨 거버넌스 문서에서 정의되며, 여기서 시스템-레벨 거버넌스는 평가 작업을 개시하기 위한 조건을 정의한다. 일부 실시예에서, 대출 프로세스 스마트 계약은, 인증자가 담보 아이템을 인증했고 담보 아이템을 진품으로 간주했음을 나타내는 인증 통보를 수신하는 것에 응답하여, 평가 스마트 계약 인스턴스를 인스턴스화한다. 일부 실시예에서, 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 평가자의 평가자 디바이스로부터 평가 보고를 수신하도록 구성되고, 여기서 평가 보고는 담보 아이템의 평가 가치와 담보 아이템의 청산 가치 중 적어도 하나를 포함하는 담보 아이템의 평가액을 포함한다. 이들 실시예들 중 일부에서, 평가 보고는, 아이템의 물리적 상태, 담보 아이템의 신규 또는 이용된 상태, 담보 아이템의 작동 상태, 유사한 아이템들의 이전 판매 가격들, 및 유사한 아이템들의 블루북 평가액(bluebook valuation) 중 하나 이상을 더 포함한다. 일부 실시예에서, 평가 보고는, 하나 이상의 각각의 2차 평가자에 의해 발행된 하나 이상의 확인을 더 포함하고, 여기서 각각의 확인은 각각의 2차 평가자가 평가 가치를 확정했음을 나타낸다. 일부 실시예에서, 평가 보고는, 평가 작업의 수행과 연관된 한 세트의 규칙들 및 규정들을 정의하는 평가 스테이지-레벨 거버넌스에 따라 정의되는 양식 템플릿으로부터 생성된다. 일부 실시예에서, 평가 스테이지-레벨 거버넌스는 평가 작업 워크플로우를 정의하고, 여기서 평가 작업 워크플로우는, 평가 작업을 완료하고 대출 프로세스 워크플로우의 다음 스테이지를 트리거하기 위해 충족되어야 하는 하나 이상의 조건을 포함한다. 이들 실시예들 중 일부에서, 평가 스테이지-레벨 거버넌스는 평가자가 길드 멤버인 평가 길드에 의해 적어도 부분적으로 정의된다. 이들 실시예들 중 일부에서, 평가 길드는 복수의 상이한 전문화된 평가 길드를 포함하고, 여기서 각각의 전문화된 평가 길드는 각각의 유형의 담보 아이템을 평가하는 것을 전문으로 한다. 일부 실시예에서, 복수의 상이한 전문화된 평가 길드는 다음을 포함하는 그룹의 적어도 서브세트를 포함한다: 시계 평가를 전문으로 하는 시계 평가 길드, 신발 평가를 전문으로 하는 신발 평가 길드, 핸드백 평가를 전문으로 하는 핸드백 평가 길드, 예술 작품 평가를 전문으로 하는 예술품 평가 길드, 스포츠 기념품 평가를 전문으로 하는 스포츠 기념품 평가 길드, 소장용 장난감 평가를 전문으로 하는 장난감 평가 길드, 보석 평가를 전문으로 하는 보석 평가 길드, 디자이너 의류 평가를 전문으로 하는 의류 평가 길드, 악기 전문 평가를 전문으로 하는 악기 평가 길드, 희귀 또는 소장용 음반 평가를 전문으로 하는 음반 평가 길드, 와인 단위(예를 들어, 배럴 또는 병)의 전문 평가를 전문으로 하는 와인 평가 길드, 위스키 단위(예를 들어, 배럴 또는 병)의 평가를 전문으로 하는 위스키 평가 길드, 및 한정판 자동차 평가를 전문으로 하는 자동차 평가 길드. 이들 실시예들 중 일부에서, 평가자는 상이한 전문화된 평가 길드들 중 한 전문화된 평가 길드에 속한다. 일부 실시예에서, 평가자에게는, 평가자가 속한 전문화된 평가 길드 및 담보 아이템의 아이템 유형에 기초하여 평가 작업을 할당받는다. 일부 실시예에서, 평가 스테이지-레벨 거버넌스는 평가 스마트 계약 인스턴스가 인스턴스화되는 평가 스마트 계약을 정의한다. 일부 실시예에서, 평가 스마트 계약 인스턴스는, 평가 보고를 수신하는 것에 응답하여 평가자의 계정으로부터 에스크로 계정으로의 소정 금액의 통화 토큰들 및/또는 토큰화된 토큰들의 에스크로잉을 개시하며, 여기서 통화 토큰들 및/또는 토큰화된 토큰들의 상기 금액은 평가 가치 이하이다. 일부 실시예에서, 에스크로잉된 금액의 적어도 일부는 대출 프로세스가 완료될 때까지 에스크로 계정에서 잠금처리된다. 일부 실시예에서, 평가 스마트 계약 인스턴스는, 평가자 디바이스로부터 평가 보고를 수신하는 것에 응답하여 평가 통보를 대출 프로세스 스마트 계약에 출력하고, 여기서 평가 통보는 대출 프로세스 스마트 계약 인스턴스가 대출 프로세스의 보관 스테이지를 개시하게 한다. 일부 실시예에서, 평가 스마트 계약 인스턴스는 또한, 평가 보고 및 평가 보고에 적어도 부분적으로 기초하여 생성되는 암호화 해시 값을 포함하는 데이터 블록을 생성하고; 데이터 블록을 분산형 원장에 기입하도록 구성된다. 일부 실시예에서, 평가자의 등급은 평가 작업과 연관된 결과에 기초하여 업데이트된다.
실시예에서, 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 대출 프로세스의 적어도 일부 동안 담보 아이템을 안전하게 보관하기 위해 보관자에 의해 수행되는 보관 작업을 관리하고 보관 작업이 완료되었음을 확인할 시에 보관 통보를 발행하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 보관 스마트 계약 인스턴스를 인스턴스화하도록 구성된다. 일부 실시예에서, 대출 프로세스 스마트 계약은 대출 프로세스 워크플로우에 따라 보관 스마트 계약 인스턴스를 인스턴스화한다. 이들 실시예들 중 일부에서, 대출 프로세스 워크플로우는 분산형 원장에 저장된 시스템-레벨 거버넌스 문서에서 정의되며, 여기서 시스템-레벨 거버넌스는 보관 작업을 개시하기 위한 조건을 정의한다. 일부 실시예에서, 대출 프로세스 스마트 계약 인스턴스는 평가자가 담보 아이템을 평가했음을 나타내는 평가 통보를 수신하는 것에 응답하여 보관 스마트 계약 인스턴스를 인스턴스화한다. 일부 실시예에서, 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 보관자의 보관자 디바이스로부터 보관 보고를 수신하도록 구성되고, 여기서, 보관 보고는, 아이템이 보관자와 연관된 시설에 보관된다는 확인을 포함하고, 담보 아이템이 수령되었을 때 보관자에 의해 관찰된 임의의 가시적인 손상의 표시를 포함한다. 일부 실시예에서, 보관 보고는 보관 작업의 완료의 증거로서 보관에 의해 제공되는 지원 문서를 더 포함한다. 일부 실시예에서, 보관 보고는, 담보 아이템이 보관자에 의해 수령되었을 때 보관자에 의해 관찰된 가시적인 손상의 사진 문서를 더 포함한다. 일부 실시예에서, 보관 보고는, 보관 작업의 수행과 연관된 한 세트의 규칙들 및 규정들을 정의하는 보관 스테이지-레벨 거버넌스에 따라 정의된 보관 양식 템플릿으로부터 생성된다. 일부 실시예에서, 보관 스테이지-레벨 거버넌스는 보관 작업 워크플로우를 정의하고, 여기서 보관 작업 워크플로우는, 보관 작업을 완료하고 대출 프로세스 워크플로우의 다음 스테이지를 트리거하기 위해 충족되어야 하는 하나 이상의 조건을 포함한다. 일부 실시예에서, 보관 스테이지-레벨 거버넌스는 보관자가 길드 멤버인 보관자 길드에 의해 적어도 부분적으로 정의된다. 일부 실시예에서, 보관 스테이지-레벨 거버넌스는 보관 스마트 계약 인스턴스가 인스턴스화된 보관 스마트 계약을 정의한다. 일부 실시예에서, 보관 스마트 계약 인스턴스는, 보관 보고를 수신하는 것에 응답하여 보관 계정으로부터 에스크로 계정으로 소정 금액의 통화 토큰들 및/또는 토큰화된 토큰들의 에스크로잉을 개시하며, 여기서 통화 토큰들 및/또는 토큰화된 토큰들의 상기 금액은 담보 아이템의 평가자에 의해 결정된 평가 가치 이하이다. 일부 실시예에서, 에스크로잉된 금액의 적어도 일부는 대출 프로세스가 완료될 때까지 에스크로 계정에서 잠금처리된다. 일부 실시예에서, 보관 스마트 계약 인스턴스는, 보관자 디바이스로부터 보관 보고를 수신하는 것에 응답하여 보관 통보를 대출 프로세스 스마트 계약에 출력하고, 여기서, 보관 통보는 대출 프로세스 스마트 계약 인스턴스가 담보 토큰의 생성을 개시하게 한다. 일부 실시예에서, 보관 스마트 계약 인스턴스는 또한, 보관 보고 및 보관 보고에 적어도 부분적으로 기초하여 생성되는 암호화 해시 값을 포함하는 데이터 블록을 생성하고; 데이터 블록을 분산형 원장에 기입하도록 구성된다. 일부 실시예에서, 보관의 등급은 보관 작업과 연관된 결과에 기초하여 업데이트된다. 일부 실시예에서, 보관자 디바이스는 담보 아이템의 가상 표현을 생성하는데 이용되는 담보 아이템의 하나 이상의 이미지를 제공한다. 일부 실시예에서, 보관 스마트 계약 인스턴스는, 담보 토큰이 에스크로 계정으로부터 잠금해제된 후 상환 워크플로우를 실행하도록 구성된다. 이들 실시예들 중 일부에서, 상환 워크플로우는 결과적으로, 담보 토큰의 상환자가 보관자로부터 담보 아이템의 소유를 가져오게 한다.
실시예들에서, 이 방법은, 대출 스마트 계약 인스턴스가 대출이 채무불이행 상태에 있다고 결정하는 것에 응답하여 청산 프로세스를 개시하도록 구성되는 것을 더 포함한다. 일부 실시예에서, 담보 토큰은 청산 이벤트 동안 담보 토큰을 구매하는 구매자에게 이전되어, 구매자가 담보 아이템을 보관을 위해 보유하는 보관자로부터 담보 아이템의 소유를 가져오기 위해 구매자가 담보 토큰을 상환한다.
실시예들에서, 대출 스마트 계약 인스턴스는, 대출이 전액 상환되었다고 결정할 때 에스크로 계정으로부터 차용자의 계정으로 담보 토큰의 이전을 개시하도록 구성된다. 이들 실시예들 중 일부에서, 담보 토큰의 현재 소유자를 정의하는 소유권 데이터를, 소유권 데이터가 분산형 원장에서 차용자의 계정의 주소를 포함하도록, 업데이트함으로써 담보 토큰이 에스크로 계정으로부터 차용자의 계정으로 이전된다.
실시예들에서, 대출 조건 파라미터는 대출 기간 및 대출 금액을 포함한다. 일부 실시예에서, 대출 스마트 계약은, 대출 기간 및 대출 금액에 기초하여 대출 상환 일정을 결정하도록 구성되고, 대출은 지불 일정에 따라 미리정의된 지불 금액이 지불되지 않을 때 채무불이행 스테이지에 있는 것으로 간주된다.
실시예들에서, 대출 프로세스 워크플로우는, 인증자에 의해 수행되는 인증 작업을 정의하는 인증 스테이지, 평가자에 의해 수행되는 평가 작업을 정의하는 평가 스테이지, 및 보관자에 의해 수행되는 보관 작업을 정의하는 보관 스테이지를 포함한다. 일부 실시예에서, 인증 스테이지, 평가 스테이지, 및 보관 스테이지는, 담보 토큰이 생성되기 전에 실행된다. 일부 실시예에서, 대출 인스턴스 스마트 계약 인스턴스는, 대출 프로세스 완료에 응답하여, 인증자, 평가자 및 보관자에게 보상을 할당하는 것을 용이화한다.
실시예들에서, 담보 토큰의 잠금해제를 트리거하는 대출의 상태 변경은 다음 중 적어도 하나이다: 대출이 전액 상환된 상태에 들어가는 것, 대출이 채무불이행 상태에 들어가고 담보 아이템이 성공적으로 청산된 상태, 및 대출 합의에 정의된 바와 같은 담보가 더 이상 요구되지 않는 상환의 상태.
실시예들에서, 담보 토큰은 담보 아이템의 가상 표현을 포장(wrap)한다.
실시예에서, 대출 스마트 계약은, 대출 조건 파라미터들에 정의된 대출의 대출 기간 및 대출 금액에 기초하여, 대출 상환 일정을 결정하도록 구성되고, 여기서, 대출은 지불 일정에 따라 미리정의된 지불 금액이 지불되지 않을 때 채무불이행 스테이지에 있는 것으로 간주된다.
실시예들에서, 대출 프로세스 워크플로우는, 인증자에 의해 수행되는 인증 작업을 정의하는 인증 스테이지, 평가자에 의해 수행되는 평가 작업을 정의하는 평가 스테이지, 보관자에 의해 수행되는 보관 작업을 정의하는 보관 스테이지를 포함하고, 여기서, 인증 스테이지, 평가 스테이지, 및 보관 스테이지는, 담보 토큰이 생성되기 전에 실행된다. 이들 실시예들 중 일부에서, 대출 인스턴스 스마트 계약 인스턴스는, 대출 프로세스 완료에 응답하여, 인증자, 평가자, 및 보관자에게 보상을 할당하는 것을 용이화한다.
실시예에서, 담보 아이템은 유형 아이템이다. 실시예들에서, 대출의 상태 변경은 다음 중 적어도 하나이다: 대출이 전액 상환된 상태에 들어가는 것, 대출이 채무불이행 상태에 들어가고 담보 아이템이 성공적으로 청산된 상태, 및 대출 합의에 정의된 바와 같은 담보가 더 이상 요구되지 않는 상환의 상태.
실시예들에서, 분산형 원장은 블록체인이다.
본 개시내용의 더 완전한 이해는 이하의 설명 및 첨부된 도면들 및 청구항들로부터 이해될 것이다.
본 개시내용의 더 나은 이해를 제공하기 위해 포함된 첨부된 도면들은, 본 개시내용의 실시예(들)를 예시하고, 설명과 함께 본 개시내용의 원리를 설명하는 역할을 한다. 도면들에서:
도 1은 본 개시내용의 일부 실시예에 따른 토큰화 플랫폼의 예시적인 환경을 예시하는 개략도이다.
도 2는 본 개시내용의 일부 실시예에 따른 예시적인 시장 시스템을 나타내는 개략도이다.
도 3은 본 개시내용의 일부 실시예에 따른 예시적인 원장 관리 시스템을 나타내는 개략도이다.
도 4는 본 개시내용의 일부 실시예에 따른 예시적인 거래 시스템을 나타내는 개략도이다.
도 5는 본 개시내용의 일부 실시예에 따른 예시적인 지능 및 자동화 시스템을 나타내는 개략도이다.
도 6은 본 개시내용의 일부 실시예에 따른 예시적인 분석 및 보고 시스템을 나타내는 개략도이다.
도 7은 본 개시내용의 일부 실시예에 따른 지갑 내의 토큰을 디스플레이하는 사용자 인터페이스이다.
도 8은 본 개시내용의 일부 실시예에 따른 토큰화 플랫폼의 예시적인 컴포넌트 세트를 나타내는 개략도이다.
도 9는 본 개시내용의 일부 실시예에 따른 아이템을 토큰화하기 위한 기술을 도시하는 플로차트이다.
도 10은 본 개시내용의 일부 실시예에 따른 디지털 시장을 이용하여 토큰들을 이전하기 위한 기술을 도시하는 플로차트이다.
도 11은 본 개시내용의 일부 실시예에 따른 키보드 상호작용을 통해 지갑들 사이에서 토큰들을 이전하기 위한 기술을 도시하는 플로차트이다.
도 12는 본 개시내용의 일부 실시예에 따른 토큰들을 상환하기 위한 기술을 도시하는 플로차트이다.
도 13은 본 개시내용의 일부 실시예에 따른 담보화 및/또는 증권화를 위한 기술을 나타내는 플로차트이다.
도 14는 본 개시내용의 일부 실시예에 따른 아이템 인증을 위한 기술을 나타내는 플로차트이다.
도 15는 본 개시내용의 일부 실시예에 따른 VR 환경을 렌더링하기 위한 기술을 도시하는 플로차트이다.
도 16은 본 개시내용의 일부 실시예에 따른 블록들의 사이드 체인을 갖는 분산형 원장을 이용하여 거래를 용이화하기 위한 기술을 도시하는 플로차트이다.
도 17은 본 개시내용의 일부 실시예에 따른 사용자 취득을 용이화하기 위한 기술을 도시하는 플로차트이다.
도 18은 본 개시내용의 일부 실시예에 따른 미스터리 박스들을 관리하기 위한 기술을 도시하는 플로차트이다.
도 19는 본 개시내용의 일부 실시예에 따른 비디오 게임 통합을 위한 기술을 도시하는 플로차트이다.
도 20은 본 개시내용의 일부 실시예에 따른 탈집중형 대출 시스템의 예시적인 생태계를 나타내는 개략도이다.
도 21은 본 개시내용의 일부 실시예에 따른 탈집중형 대출 프로세스의 다양한 스테이지를 통제하는 길드들, 하위 길드들, 및 다양한 유형의 거버넌스들의 한 예를 나타내는 개략도이다.
도 22는 본 개시내용의 일부 실시예에 따른 인증 워크플로우를 수행하기 위한 방법의 예시적인 세트의 동작들을 나타내는 플로차트이다.
도 23은 본 개시내용의 일부 실시예에 따른 평가 워크플로우를 수행하기 위한 방법의 예시적인 세트의 동작들을 나타내는 플로차트이다.
도 24는 본 개시내용의 일부 실시예에 따른 보관 워크플로우를 수행하기 위한 방법의 예시적인 세트의 동작들을 나타내는 플로차트이다.
도 25는 본 개시내용의 일부 실시예에 따른 대출 워크플로우를 수행하기 위한 방법의 예시적인 세트의 동작들을 나타내는 플로차트이다.
도 26은 본 개시내용의 일부 실시예에 따른 대출전 청산 워크플로우를 수행하기 위한 방법의 예시적인 세트의 동작들을 나타내는 플로차트이다.
도 27은 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우의 한 세트의 스테이지들을 나타내는 도면이다.
도 28은 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우의 한 세트의 스테이지들을 나타내는 도면이다.
도 29는 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우의 한 세트의 스테이지들을 나타내는 도면이다.
도 30은 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우의 한 세트의 스테이지들을 나타내는 도면이다.
블록체인 기술과 스마트 계약들의 조합은 이러한 자동화에 관한 법적 제약들을 유지하고 존중하면서 많은 거래를 자동화하는 방식으로 다양한 거래를 구현하기 위한 시스템들 및 방법들에서 이용하기 위해 제안되었다. 이러한 시스템들의 자동화에 관한 제한들 중 하나는, (i) 당사자들 사이에 법적 구속력이 있는 계약들을 생성하고 (ii) 소유권 이익, 담보 이익 또는 기타 유사한 이익을 법적 구속력이 있는 방식으로 이전하는 식으로 재산을 교환하기 위한 관할당국 규칙들 및 프로세스들의 존재이다.
제안된 시스템들 중 일부는, 부동산 기록들, Uniform Commercial Code 파일링 시스템들, 및 기타 유사한 시스템들을 포함한, 이러한 이전들에 대한 법적 기록 시스템을 위한 블록체인 기술의 미래의 구현에 의존한다. 이러한 전환은, 블록체인 기반의 기록 보관 시스템을 생성하고 채택하는 정부 기관들에 달려 있다. 예를 들어, 미국의 부동산 기록들은 전형적으로 선출된 공무원에 의해 카운티-레벨에서 유지되며, 문서들에 대해서는 기록 제출 형식 및 방법들에 관한 특정한 규칙들이 적용된다. 각각의 이러한 공무원은 자체 시스템들을 이용하여 문서들을 수락하고 기록한다. 따라서, 블록체인 기반의 기록 보관 시스템을 채택하는 것은, 각각의 관할당국이 이러한 시스템을 선택하고 구현할 것을 요구한다. 이러한 시스템들에 대한 기술이 개발되고 구현에 이용가능하더라도 이 프로세스는 몇 년이 걸릴 수 있다. 새로운 기술들을 채택하려는 관할당국의 의지도 크게 다를 수 있으므로, 모든 관할당국들이 블록체인 기반의 시스템으로 이주하는 시기를 결정하는 것은 불가능하다.
블록체인 기술들의 이점은 정부 기록 보관자들이 이 기술에 기초한 시스템 구현을 시작하기로 결정할 때까지 기다리지 않아야 하기 때문에, 블록체인 기술의 이점을 제공하면서도 기존의 기록 보관 및 기타의 법적 시스템들과 인터페이스하는 하이브리드 시스템들이 그 갭을 이어주는데 필요하다. 여기서 개시된 것들과 같은 시스템들은 시스템 사용자에게 블록체인의 이점을 제공하고, 기존의 법적 시스템들 및 방법들과 인터페이스하며, 이용가능할 경우 완전한 블록체인 기반의 시스템으로 이주하기가 더 쉬울 것이다.
여기서 설명된 분산형 원장 거래 시스템들 및 방법들은, 스마트 계약들과 조합하여 분산형 원장 기술(예를 들어, 블록체인 기술)을 이용하여 사용자들이 다양한 상이한 거래들을 협상, 문서화 및/또는 실행하는 것을 허용한다. 일부 실시예에 따르면, 상이한 거래들은 증권화된 탈집중형 대출 거래들을 포함한다. 이들 대출 거래들은, 전통적인 유형들의 담보에 의해 및/또는 디지털 자산들에 의해 안전하게 되는 대출 거래들을 포함한다.
일반적으로 분산형 원장 기술은 적용 및 채택에 있어서 빠르게 확장되고 있는 암호화폐들에 대한 기초를 형성한다. 이러한 암호화폐들은 현금 등의 기존의 지불 방법들을 보강하거나 대체할 뿐만 아니라, 암호화폐의 이전을 처리하기 위한 분산형 시스템을 또한 제공한다. 분산형 원장/블록체인 기술에 대한 기초는 데이터 블록들의 링크된 목록이다. 각각의 블록은, 체인 내의 이전 블록에 대한 링크와 암호화된 데이터를 포함한다. 분산형 원장의 일부 구현에서, 암호화된 데이터는, 디지털 통화의 교환을 문서화하는 거래 데이터, 실행가능한 디지털 계약 등의 소프트웨어, 특정한 당사자들에 의한 디지털 계약 이용과 연관된 데이터를 포함할 수 있지만, 아래에서 더 상세히 설명되는 다른 유형들의 데이터도 역시 포함할 수 있다. 분산형 원장의 각각의 블록 내의 데이터는, 분산형 원장 내의 이전 블록들을 수정하려는 시도를 식별하고 방지하는 수단으로서 체인 내의 이전 블록 해시를 포함한다.
분산형 원장 기술의 많은 구현에서, 분산형 원장의 관리 및 확장은 시스템의 컴퓨팅 능력에 기여하는 수많은 비연합 엔티티들에 의해 운영되는 컴퓨터 시스템들에 걸쳐 탈집중화되고 분산된다. 이들 분산형 기여자들은, 분산형 원장의 사본들을 저장하고 거래들을 처리하는데 필요한 알고리즘들을 수행함으로써 분산형 원장 시스템의 인프라를 제공하고, 이들을 분산형 원장의 새로운 블록에 배치하고 이들 블록들을 시스템의 다른 부분들에 분산한다. 일부 분산형 원장 구현에서, 기여자들은, 분산형 원장에서 새로운 블록을 처리하는 대가로 암호화폐로 표시된 수수료를 받아 이 서비스에 대해 보상을 받는다. 분산형 원장 보안의 한 중요한 양태는, 분산형 원장이 일시적인 경쟁 브랜치들을 갖더라도, 블록들이 분산형 원장에 추가되고 메인 브랜치 내에 수락된 후에 블록들을 수정하는 것은 어렵다는 것이다.
분산형 원장 기술은 "스마트 계약들"의 개념에 의해 강화되었다. 스마트 계약들은, 스마트 계약의 개발자들에 의해 분산형 원장의 블록 내의 데이터로 컴파일되는 실행가능한 컴퓨터 프로그램들이다. 일단 스마트 계약이 분산형 원장에 배치되고 나면, 분산형 원장의 다른 사용자들은 스마트 계약이 악의적인 제3자에 의해 수정되지 않았다는 확신을 갖고 스마트 계약을 실행할 수 있다. 이들 실행가능한 컴퓨터 프로그램들은, 이들이 디지털 통화 및 기타 유형들의 자산들의 이전과 관련하여 다양한 당사자들 사이의 합의들을 나타내고 구현하는데 이용될 수 있지만, 계약상의 약정을 나타낼 필요는 없기 때문에 "스마트 계약"이라고 지칭된다. 소프트웨어 개발자는, JavaScript, Solidity 또는 기타 스크립팅 언어 등의 스크립팅 언어, 또는 Java 등의 객체 코딩 언어, 또는 C 또는 C++ 등의 머신 코딩 언어를 이용하여 프로그램 코드를 작성함으로써 스마트 계약을 개발한다. "스마트 계약"이 분산형 원장 내에 배치되면, 프로그램 코드는 분산형 원장 상의 임의의 다른 거래와 마찬가지로 시스템 기여자들 중 하나에 의해 처리되어 블록화되고, 전형적으로는, 계약/프로그램을 컴파일한 노드 기여자에게 수수료가 지불된다. 스마트 계약을 배치하는 프로세스는, 프로그램 코드를, 바이트 코드, 객체 코드, 2진 코드, 또는 어떤 다른 실행가능한 형태로 컴파일하는 것을 포함할 수 있다. 스마트 계약이 블록체인에 성공적으로 배치되면, 임의의 다른 분산형 원장 거래와 마찬가지로 주소를 할당받는다. 이 주소는 스마트 계약에 액세스하고 여기서 제공된 기능을 실행하는데 이용된다. 전형적으로, 애플리케이션 프로그래밍 인터페이스와 유사한 ABI(Application Binary Interface) 정보가 계약의 사용자 또는 (지갑 애플리케이션 등의) 계약과 인터페이스하는 소프트웨어에 제공되어, 사용자가 스마트 계약의 다양한 기능과 상호작용할 수 있게 한다. ABI는 사용자 또는 사용자의 소프트웨어에 의해 액세스될 수 있도록 스마트 계약의 일부로서 제공되는 다양한 기능과 방법을 설명한다.
그러면, 분산형 원장 내에 배치된 계약/프로그램은 분산형 원장 상에서 계약의 주소를 갖고 있는 누구나에 의해 이용될 수 있다. 계약 또는 계약의 일부를 실행하는 것은, 계약의 그 단계의 일부로서 분산형 원장에 대한 업데이트가 요구되지 않는 한 반드시 수수료를 초래하는 것은 아니다. 계약/프로그램이 적절하게 구현된다면, 많은 상이한 사용자들이 계약/프로그램을 동시에 이용하여 그들 자신의 특정한 합의나 거래를 통제할 수 있다.
실시예들에서, 스마트 계약/프로그램은 계약의 상이한 당사자들에 의해 실행되거나 완료되는 여러 단계들을 가질 수 있다. 예를 들어, 계약/프로그램은, 소정의 계약의 사본을 인스턴스화함으로써 제2 당사자 또는 잠재적 계약 당사자들의 그룹에 제안을 하기 위해 제1 당사자에 의해 기동될 수 있다. 제2 당사자(또는 그룹 중 하나)는 계약의 그 인스턴스에 "서명"함으로써 응답할 수 있다. 계약을 "서명"하는 프로세스는, 계약의 일부로서 정의된 프로그램적 방법을 기동하는 것을 포함할 수 있다. 일부 계약은, 구매자, 판매자, 대출자, 차용자, 에스크로 에이전트, 인증자, 평가자, 및/또는 기타 등등의 여러 당사자를 제공할 수 있고, 이들 모두는 서명하기 위해 또는 특정한 유형의 스마트 계약과 연관된 다른 조치를 취하기 위해 스마트 계약의 특정한 인스턴스와 독립적으로 상호작용할 수 있다.
스마트 계약들은, 디지털 자산들을 포함하거나, 계약 당사자들, 분산형 원장, 디지털 자산들, 및 인터넷 상의 또는 계약에 디지털적으로 달리 접속된 자원들 사이의 프로그램적 상호작용들을 통해 완전히 실행될 수 있는 계약들에 매우 적합하다. 예를 들어, 스마트 계약들은, ACH 또는 기타의 전자 지불 시스템들을 통해 디지털 자산들의 제어 및 소유권을 자동으로 이전하거나 PayPal 또는 은행 계좌 사이에서 돈을 이전할 수 있다. 외부 시스템에 의해 제공되는 애플리케이션 프로그래밍 인터페이스들은, 비프로그램적 프로세스들 없이 당사자들 사이에서 자산들 또는 자금들의 실제 이전을 실행하는 디지털 계약을 위한 방법들을 제공한다.
스마트 계약들은, 부동산, 개인 자산, 및 정부 또는 민간 등록 시스템들의 통제를 받는 기타 유형들의 자산들 등의 유형 자산들을 수반하는 합의를 쉽게 완전히 구현할 수 없다. 이들 등록 시스템은 종종 서류-기반이거나, 전자적인 경우, 제3자의 프로그램적 상호작용을 위해 설계되지 않았다. 이러한 시스템들의 예로서는, 부동산 소유권 기록들, 명의로 된 자산들에 대한 개인 재산 기록들, Uniform Commercial Code 기록들, 특허 및 상표 등록 데이터베이스들 등이 포함된다. 이들 시스템들 중 많은 것들은 부분적으로 디지털일 수 있지만 완전히 자동화된 방식으로 시스템과 상호작용하기 위한 스마트 계약을 위한 프로그램적 인터페이스가 부족하거나, 본질적으로 전용적이다. 다른 시스템들은 별도의 파일링 시스템들을 이용하여 여러 관할당국들 내로 분할될 수 있으므로, 단일 스마트 계약이 모든 관련 시스템에서 기능하지는 않을 수 있다. 예를 들어, Uniform Commercial Code 파일링은 전형적으로 상이한 주 관할당국들에 걸쳐 상이한 시스템들에 의해 처리되고, 스마트 계약은 단일의 관할당국 외부의 거래들을 처리할 수 있도록 및 이러한 인터페이스들이 소정의 관할당국에게 이용가능한지에 따라 다양한 인터페이스를 구현할 필요가 있다.
스마트 계약/프로그램의 프로그램적 기능들을 통해 완전히 실행될 수 없는 한 유형의 계약은 담보 대출 거래이다. 이러한 거래들의 많은 부분이 당사자들과 스마트 계약 사이의 상호작용들을 통해 완료될 수 있지만, 거래의 다른 양태들 중에서, 명의 및 소유권의 이전, 대출자의 이익을 위한 담보권의 생성은 스마트 계약을 통한 완료에 쉽게 적합화되지 않는다. 본 개시내용의 실시예들에 따르면, 용이화를 위한 한 세트의 분산형 원장들 및 한 세트의 스마트 계약들을 통합하는 탈집중형 대출 시스템이 생성되어 하나 이상의 유형의 스마트 계약을 지원한다. 시스템의 다양한 실시예에서, 분산형 원장 세트는, 길드 거버넌스 스마트 계약들, 인증자 스마트 계약들, 평가 스마트 계약들, 대출 스마트 계약들, 및/또는 증권화된 탈집중형 대출 프로세스를 지원하도록 구현된 기타의 스마트 계약들 등의 다양한 유형의 스마트 계약을 호스팅할 수 있다. 프로그램적 스마트 계약은 분산형 원장(들) 내로 컴파일되고 분산형 원장(들)의 각각의 블록 내의 소정의 주소들에 존재한다. 사용자들은 스마트 계약과 연관된 주소 및 방법들 또는 기능들을 기동함으로써 이들 스마트 계약들을 이용할 수 있다. 예를 들어, 한 예시적인 대출 계약은, 대출 요청, 대출 승인, 담보 할당, 지불 인가, 및/또는 대출의 형성 및 실행, 보증으로서의 담보 제공 및 조건에 따른 대출의 상환에 필요한 기타의 유사한 기능들을 위한 방법들을 가질 수 있다.
대출 계약의 예를 계속하면, 사용자가 스마트 계약을 이용하고 그 계약의 방법 또는 기능을 기동할 때, 사용자는 특정한 방법 또는 기능에 의해 명시된 파라미터들 및 기타의 정보를 스마트 계약에 제출할 수 있다. 그러면, 스마트 계약은 이들 파라미터에 따라 선택된 방법 또는 기능을 프로그램적으로 실행할 수 있다. 대출 요청 기능의 경우, 대출 스마트 계약은 대출을 받고자 하는 사용자로부터 받은 파라미터들을 가져오고 그 요청 정보를 블록체인 내의 새로운 블록 내에 통합하여 잠재적 대출자들이 그 요청을 볼 수 있게 할 수 있다. 일부 실시예에서, 대출 요청은 분산형 원장 내에 통합되지 않을 수도 있지만, 웹 서비스 등을 통해 잠재적 대출자들에게 프로그램적으로 이용가능한 데이터베이스에 저장될 수 있다.
본 개시내용은 상품, 서비스 및/또는 경험 등의 아이템의 가상 표현("VIRL"이라고도 함)의 생성을 가능케하는 토큰화 플랫폼에 관한 것이다. 본 명세서에서 사용될 때, 용어 "아이템"은, 디지털 자산(예를 들어, 기프트 카드, 디지털 음악 파일, 디지털 비디오 파일, 소프트웨어, 디지털 사진 등), 물리적 상품, 디지털 서비스(예를 들어, 비디오 스트리밍 구독), 물리적 서비스(예를 들어, 운전 기사 서비스, 가정부 서비스, 드라이 클리닝 서비스), 및/또는 구매 경험(예를 들어, 호텔 팩키지, 콘서트 티켓, 항공권 등), 또는 이들의 임의의 조합을 지칭할 수 있다. 아이템은 이미 존재하거나 나중에 생산될 수 있는 상품을 지칭할 수 있다는 점에 유의한다. 예를 들어, 아이템은 만들어지지 않은 피자 또는 의류 물품일 수 있다. 이러한 아이템의 구매자는 아이템을 구매할 수 있고, 아이템은 구매 후의 시점에서 생산될 수 있다. 가상 아이템이라는 용어는 매매 아이템의 가상 표현을 지칭할 수 있다. 아이템에 대한 가상 표현의 생성시, 전통적인 전자 상거래에 요구되는 많은 구매시 결정이 연기되고 거래 자체로부터 분기됨으로써, 구매자에게 추가 가치를 생성할 수 있다. 예를 들어, 구매자가 신발 한 켤레를 주문하기를 원하지만, 신발이 언제 필요한지 또는 배달 위치가 어디가 되어야 하는지를 아직 확정하지 못할 수 있다. 구매자는 신발의 가상 표현을 구매할 수 있다. 가상 표현은, 상환자(예를 들어, 선물의 구매자 또는 수신자) 자신이 선택한 배달 시간과 배달 위치를 명시할 수 있도록 나중에 상환될 수 있다. 가상 아이템을 생성함으로써, 상환시까지 보류할 수 있는 일련의 선택으로서, 구매자 또는 임의의 수신자를 위한 새로운 가치가 생성된다.
또한, 종래의 전자 상거래 플랫폼에서는, 체크되고 신뢰될 수 있는 미지의 당사자들간에 아이템이 이전되는 기록 메커니즘이 없다. 또한 중앙집중화된 엔티티가 없이는 민감한 금융 정보를 저장할 방법도 없다. 따라서 실시예들에서, 토큰화 플랫폼은, 가상 표현이 미지의 당사자들 사이에서 아이템의 이전을 허용하면서 누구라도 임의의 시간에 토큰의 상태를 체크하고 올바르다고 신뢰하는 것을 허용하기 위한 프로세스를 제공하기 위해 암호화방식으로 보안된 원장에 저장되도록 구성된 전자 토큰들(또는 "토큰들")을 발행하도록 구성될 수 있다. 본 명세서에서 사용될 때, 문맥에 의해 달리 표시되지 않는 한, "암호화방식으로"는 해싱 알고리즘 등의 암호화 알고리즘의 이용을 나타낸다.
전자 상거래 플랫폼은 추가의 또는 대안적 생태계를 지원하도록 구성될 수 있다. 실시예들에서, 토큰화 플랫폼은, 토큰 기반의 대출 시스템을 지원하도록 구성되며, 이에 따라 대출자는 담보(예를 들어, 보석, 수집품, 예술품 등)에 대응하는 가상 아이템을 생성할 수 있다. 전자 상거래 플랫폼은 가상 아이템을 토큰화하고 토큰을 분산형 원장에 저장할 수 있다. 이러한 방식으로, 대출이 판매될 수 있으며 대출자들 사이에서 토큰만 이전될 필요가 있다. 일부 실시예에서, 스마트 계약은, 대출, 토큰 소유, 및 대출에 대응하는 기타의 거래를 관리하는데 이용될 수 있다.
일부 실시예에서, 토큰화 플랫폼은 현실 세계 아이템을 인증하도록 구성된다. 이들 실시예들 중 일부에서, 토큰화 플랫폼은 아이템의 가상 표현을 이용하여 아이템을 인증할 주제 전문가를 참여시킬 수 있다. 주제 전문가는 전문가의 기저 의견에 대한 메모를 포함하는 인증 보고를 제공할 수 있다. 인증 보고는, 아이템이 담보로 이용되거나 플랫폼에서 판매되는 것을 거부하거나 허용하는데 이용될 수 있다. 추가로, 일부 실시예에서, 인증 보고는, 플랫폼이 머신 비전, 머신 학습, 센서(예를 들어, 스케일), 및/또는 기타의 적절한 기술을 이용하여 아이템을 인증할 수 있도록 머신 학습 모델을 훈련시키는데 이용될 수 있다.
실시예들에서, 토큰화 플랫폼은 "미스터리 박스" 게임을 지원하도록 구성된다. 미스터리 박스 게임은 사용자가 미스터리 박스로부터 토큰이 획득될 수 있는 변화의 게임으로, 토큰은 아이템을 나타내고 토큰은 상환, 매매, 판매, 선물 등이 가능하다. 이들 실시예들 중 일부에서, 토큰화 플랫폼은 카지노 스타일의 게임을 지원하며, 이에 의해 미스터리 박스 게임은 카지노 및 기타의 오프라인 위치에서 플레이될 수 있다.
실시예들에서, 토큰화 플랫폼은 인비디오 게임 스트리밍(in-video game streaming)을 지원하도록 구성된다. 이들 실시예들 중 일부에서, 토큰화 플랫폼은 비디오 게임의 인스턴스에 토큰의 표시자를 제공할 수 있으며, 이에 의해 비디오 게임 제작자는 토큰을 다수의 상이한 방식으로 이용할 수 있다. 예를 들어, 토큰이 비디오 게임에서 나타나 음식 배달 서비스가 게임에서 배달가능한 음식을 판매하는 것을 허용할 수 있다. 또 다른 예에서, 토큰은 게임에서 이용될 수 있는 디지털 아이템을 나타낼 수 있지만, 나중에 디지털 아이템에 대응하는 현실 세계 아이템을 획득하기 위해 상환될 수 있다.
실시예들에서, 토큰화 플랫폼은 보상 기반의 사용자 취득 프로그램을 제공할 수 있으며, 이에 의해 사용자는 추천 코드를 등록할 수 있다. 사용자가 토큰화 플랫폼을 성공적으로 참조하면, 사용자는 토큰으로 보상받는다. 토큰은 금전적 보상 또는 아이템(예를 들어, 기프트 카드, 신발 한 켤레, 음악 앨범, DVD 등)을 나타낼 수 있다.
도 1은 본 개시내용의 일부 실시예에 따른 토큰화 플랫폼(100)(또는 "플랫폼")의 예시적인 생태계를 나타낸다. 환경은, 플랫폼(100), 노드 컴퓨팅 디바이스(160), 외부 데이터 소스(170), 콘텐츠 플랫폼(180) 및 사용자 디바이스(190)를 포함한다. 플랫폼(100), 노드 컴퓨팅 디바이스(160), 외부 데이터 소스(170), 콘텐츠 플랫폼(180) 및 사용자 디바이스(190)는 통신 네트워크(10)(예를 들어, 인터넷 및/또는 셀룰러 네트워크)를 통해 통신할 수 있다.
실시예들에서, 토큰화 플랫폼(100)은 하나 이상의 암호화 원장(또는 "분산형 원장")을 관리하고, 상품, 서비스 및/또는 상기 아이템의 이행 및 충족을 동반한 경험 등의 아이템의 가상 표현의 유연한 기능을 제공한다. 실시예들에서, 플랫폼(100)은 제3자 판매자가 토큰을 이용하여 아이템을 거래하기 위한 시장을 제공하고, 이에 의해 토큰은 특정한 아이템에서 소유권을 정의하는 디지털 마커이다. 추가적으로, 또는 대안으로서, 플랫폼(100)의 제공자는 제공자에 의해 제공되는 아이템을 판매, 임대, 증정 또는 기타의 방식으로 거래할 수 있다. 여기서 사용될 때, 용어 "거래"는, 판매/구매, 임대, 선물, 담보화, 또는 토큰의 소유권에 영향을 미치는 기타 임의의 행위를 지칭할 수 있다. 논의되는 바와 같이, 일부 실시예에서 토큰은, 토큰의 소유자가 토큰의 상환시에 아이템을 소유할 수 있도록 토큰의 소유자에 의해 상환될 수 있다.
일부 실시예에서, 아이템의 판매자(또는 기타 임의의 적절한 사용자)는 판매자가 거래를 위해 제공하고 있는 아이템의 가상 표현을 정의하기 위해 플랫폼(100)에 액세스할 수 있다. 아이템의 가상 표현은, 아이템을 식별하는 정보(예를 들어, 아이템에 대응하는 일련 번호, 아이템의 모델 번호 등), 아이템에 관련된 정보(예를 들어, 아이템의 분류, 텍스트 설명, 이미지, 오디오, 비디오, 가상 현실 데이터, 증강 현실 데이터 등), 및/또는 아이템을 수반하는 거래를 용이화하거나 확인하는데 이용될 수 있는 코드(예를 들어, 스마트 계약)를 포함할 수 있다. 일부 실시예에서, 플랫폼은, 아이템의 가상 표현에 기초하여 토큰 세트를 생성하고 암호화방식으로 보안된 분산형 원장에 토큰 및 연관된 메타데이터를 저장함으로써 아이템의 판매자를 위하여 아이템을 "토큰화"할 수 있음으로써, 토큰(및 가상 표현)을 확인가능하고 이전가능하며 추적가능하게 한다.
실시예들에서, 플랫폼(100)은 하나 이상의 외부 데이터 소스(170)로부터 데이터를 수신할 수 있다. 외부 데이터 소스(170)는 플랫폼에 데이터를 제공할 수 있는 임의의 시스템 또는 디바이스를 지칭할 수 있다. 실시예들에서, 데이터 소스들은, 가용 아이템에 관련된 데이터를 플랫폼(100)에 제공하는 판매자, 제조자, 또는 서비스 제공자 시스템들 및/또는 데이터베이스들을 포함할 수 있다. 외부 데이터 소스들은 또한, 사용자 디바이스들(190)을 포함할 수 있어서, 사용자 디바이스들(190)이 관련 데이터(예를 들어, 연락처들, 쿠키들 등)를 제공할 수 있게 한다. 외부 데이터 소스(170)의 예는, 전자 상거래 웹사이트, 조직 웹사이트, 소프트웨어 애플리케이션, 및 연락처 목록(예를 들어, 전화 연락처, 이메일 연락처, 메신저 클라이언트 연락처 등)을 포함할 수 있다. 플랫폼(100)은, 임의의 적절한 방식(예를 들어, 크롤러, 사용자 허가/API 등)으로 네트워크(10)(예를 들어, 인터넷)를 통해 외부 데이터 소스(170)에 액세스할 수 있다.
실시예들에서, 플랫폼(100)은 콘텐츠 게시 플랫폼(180)과 상호작용한다. 콘텐츠 게시 플랫폼(190)은 개인 및/또는 조직을 위하여 콘텐츠를 게시하는 임의의 시스템을 지칭할 수 있다. 콘텐츠 게시 플랫폼은, 소셜 네트워킹 플랫폼, 블로그 플랫폼, 뉴스 사이트 등을 포함할 수 있다. 실시예들에서, 소비자는 콘텐츠 게시 플랫폼(190)을 통해 아이템에 대응하는 콘텐츠를 출력할 수 있다. 예를 들어, 소비자는, 구매된 아이템에 관련된 콘텐츠를 소셜 네트워킹 플랫폼에 게시할 수 있거나 콘텐츠를 블로그 게시물에 임베딩할 수 있다. 콘텐츠는 아이템에 대한 링크(예를 들어, 아이템에 대응하는 웹 페이지 또는 애플리케이션 상태에 대한 링크)를 포함할 수 있다.
실시예들에서, 플랫폼(100)은 다양한 사용자 디바이스(190)와 인터페이스한다. 사용자 디바이스(190)는, 사용자(예를 들어, 소비자, 판매자, 제조자, 제공자 등)가 플랫폼에 액세스하기 위해 이용할 수 있는 임의의 컴퓨팅 디바이스를 지칭할 수 있다. 사용자 디바이스의 예는, 스마트폰, 태블릿 컴퓨터 디바이스, 랩탑 컴퓨팅 디바이스, 개인용 컴퓨팅 디바이스, 스마트 텔레비전, 게임 콘솔 등을 포함하지만 이것으로 제한되는 것은 아니다. 사용자 디바이스는, 웹사이트, 웹 애플리케이션, 네이티브 애플리케이션 등을 통해 플랫폼(100)에 액세스할 수 있다. 실시예들에서, 플랫폼(100)은, 판매자와 연관된 사용자 디바이스(190)에 제1 그래픽 사용자 인터페이스를 제공하고 최종 사용자와 연관된 사용자 디바이스(190)에 제2 그래픽 사용자 인터페이스를 제공할 수 있다. 제1 그래픽 사용자 인터페이스는, 판매자와 연관된 사용자가 판매용 아이템을 제공하고 판매용 아이템에 대응하는 새로운 가상 표현을 생성하는 것을 허용할 수 있다. 제2 사용자 인터페이스는, 사용자가 판매용 아이템에 대응하는 토큰을 구매하거나 토큰을 이전하거나, 및/또는 토큰을 상환하는 것을 허용할 수 있다. 일부 실시예에서, 플랫폼(100)은 사용자의 토큰을 저장하는 디지털 지갑을 지원할 수 있다. 디지털 지갑은 플랫폼(100)에 의해 제공 되고/되거나 지원되는 클라이언트 애플리케이션일 수 있다. 실시예들에서, 디지털 지갑은, 디지털 지갑과 연관된 사용자에 의해 소유된 임의의 토큰을 저장하고 사용자가 토큰을 수반하는 거래에서 상환, 이전, 판매, 교환 또는 기타의 방식으로 참여하는 것을 허용하는 인터페이스를 제공한다.
실시예들에서, 아이템의 토큰화는, 토큰에 의해 표현된 아이템에 관해 안전하게 거래하기 위한 프레임워크를 제공한다. 예를 들어, 토큰은, 신뢰할 수 있거나 신뢰할 수 없는 당사자를 수반하는 거래에서 아이템을 매매, 대여, 구매, 판매, 교환, 선물, 스왑, 또는 이전될 수 있는 메커니즘을 제공한다. 일부 실시예에서, 토큰은 거래(예를 들어, 판매, 매매, 임대, 선물 등)될 단일 유닛을 나타낸다. 예를 들어, 판매자가 10개의 위젯을 판매하는 경우, 플랫폼(100)은 10개의 토큰을 생성할 수 있고, 각각의 토큰은 상이한 위젯에 대응한다. 이 시나리오에서 10개 위젯 모두는 위젯의 동일한 가상 표현에 대응할 수 있고, 10개의 토큰은 가상 표현의 인스턴스("가상 자산"이라고도 함)를 나타낼 수 있다. 실시예들에서, 토큰은 아이템의 가상 표현의 디지털 서명된 인스턴스일 수 있고, 이에 의해 디지털 서명은 토큰의 유효성을 확인하는데 이용될 수 있다.
실시예들에서, 아이템의 각각의 가상 표현은, 예를 들어, 가상 표현에 의해 표현된 아이템에 관련된 거래를 자체 실행(예를 들어, 소유권 이전 또는 만료)하기 위해 충족되어야 하는 확인가능한 조건 세트를 제공하는 스마트 계약을 포함하거나 이와 연관될 수 있다. 실시예들에서, 가상 표현에 대응하는 각각의 토큰은 가상 표현에 대응하는 스마트 계약과 연관될 수 있다. 실시예들에서, 가상 표현에 대응하는 스마트 계약은 새로운 토큰을 생성하기 위해 확인되어야 하는 조건, 토큰 소유권을 이전하기 위해 확인되어야 하는 조건, 토큰을 상환하기 위해 확인되어야 하는 조건, 및/또는 토큰을 파괴하기 위해 충족되어야 하는 조건을 정의할 수 있다. 스마트 계약은 또한, 소정의 조건이 충족될 때 취해져야 할 조치를 정의하는 코드를 포함할 수 있다. 관여될 경우, 스마트 계약은 그 내부에 정의된 조건이 충족되는지를 결정하고, 충족되는 경우, 그 조건에 대응하는 동작을 자체 실행할 수 있다. 실시예들에서, 각각의 스마트 계약은 분산형 원장에 저장되고 액세스될 수 있다. 일부 실시예에서, 연관된 스마트 계약을 갖지 않는 토큰은 플레이스홀더 토큰(placeholder token)이라고 지칭될 수 있어서, 플레이스홀더 토큰은 거래에 관여되지 않을 수 있다. 실시예들에서, 토큰은 선물될 수 있다. 실시예들에서, 선물된 토큰의 수령인들은, 토큰을 상환하고, 상환 전에 토큰에 의해 표현된 가상 자산을 맞춤화하고, 이를 또 다른 토큰으로 교환하고, 현금 가치 균등물을 획득하는 등을 할 수 있다.
일단 플랫폼(100)이 토큰을 생성하고 나면, 플랫폼은 새로운 토큰의 존재를 표시하기 위해 분산형 원장을 업데이트할 수 있다. 여기서 사용될 때, 분산형 원장이란 거래들을 기록하는 전자적 원장을 지칭할 수 있다. 분산형 원장은 공개 또는 비공개일 수 있다. 분산형 원장이 비공개인 실시예들에서, 플랫폼(100)은 플랫폼과 연관된 컴퓨팅 디바이스 노드(160)에 전체 분산형 원장을 유지하고 저장할 수 있다. 분산형 원장이 공개인 실시예들에서, 플랫폼(100)과 연관되지 않은 하나 이상의 제3자 컴퓨팅 노드 디바이스(160)(또는 "컴퓨팅 노드")는 분산형 원장을 집합적으로 저장할 수 있다. 이들 실시예들 중 일부에서, 플랫폼(100)은 또한 분산형 원장 및/또는 그 일부를 국부적으로 저장할 수 있다. 실시예들에서, 분산형 원장은 블록체인(예를 들어, Ethereum 블록체인)이다. 대안으로서, 분산형 원장은 다른 적절한 프로토콜(예를 들어, 해시그래프, Byteball, Nano-Block Lattice, 및 IOTA)을 준수할 수 있다. 분산형 원장에 토큰을 저장함으로써, 원장을 조회하여 토큰의 상태가 언제든지 확인될 수 있고 올바르다고 신뢰할 수 있다. 구현에 대해 토큰 접근법을 이용함으로써, 토큰이 허가 없이 복사되고 상환될 수 없다.
일부 실시예에서, 플랫폼(100)은 분산형 원장의 메인 체인으로부터 분기되는 사이드 체인이 있도록 분산형 원장을 샤딩(shard)하도록 구성된다. 이들 실시예들 중 일부에서, 사이드 체인은 특정한 범주 또는 클래스를 갖는 아이템의 가상 표현을 저장할 수 있다. 실시예들에서, 특정한 클래스의 아이템에 대응하는 사이드 체인은, 특정한 클래스에 속하는 아이템에 대응하는 토큰, 이들 토큰의 현재 및 이전 소유권을 나타내는 소유권 기록을 저장할 수 있다. 토큰의 소유권이 변경될 때마다, 관여된 토큰을 포함하는 사이드 체인이 수정되어 토큰의 새로운 소유자를 표시할 수 있다. 실시예들에서, 사이드 체인은 가상 표현과 연관된 미디어 콘텐츠를 저장할 수 있다. 예를 들어, 사이드 체인은, 비디오, 사진, 오디오 클립, 및 각각의 가상 표현에 의해 참조되는 다른 적절한 미디어 콘텐츠를 저장할 수 있다.
아이템 데이터(예를 들어, 가상 표현), 토큰, 및 토큰에 관련된 거래 데이터에 추가하여, 분산형 원장은 또한 계정 정보를 저장할 수 있다. 예를 들어, 실시예들에서, 분산형 원장은 각각의 유효한 계정의 공개 주소를 저장할 수 있다. 실시예들에서, 유효한 계정은, 거래에 참여하기 위해 플랫폼에 의해 확인되고 인가된 엔티티에 속할 수 있다. 따라서, 실시예들에서, 당사자는, 그 당사자가 알려진 계정을 갖고 있는 경우에만, 토큰을 판매, 구매, 선물, 수신, 또는 달리 이전할 수 있다. 각각의 계정은, 플랫폼(100)에서 거래하는데 이용될 수 있는 공개 키 및 개인 키를 할당받을 수 있다. 실시예들에서, 계정의 주소는 계정의 공개 키에 기초할 수 있다(예를 들어, 주소는 공개 키의 해시 값일 수 있음). 이들 주소는, 거래에 관련된 주소들이 분산형 원장을 이용하여 유효한 계정에 대응하는 것으로 확인될 수 있도록 분산형 원장에 저장될 수 있다.
동작 중에, 판매자는, 각각의 가상 표현이 거래에 이용가능한 개개의 아이템을 표현하도록 하나 이상의 개개의 아이템의 가상 표현을 생성할 것을 플랫폼(100)에게 지시할 수 있다. 본 개시내용의 거래의 많은 예가, 상품, 서비스 및/또는 경험의 구매와 관련되어 있지만, 거래는, 임대, 대여, 대출, 선물, 매매, 보상 또는 증정을 포함할 수도 있다는 점에 유의한다. 실시예들에서, 판매자는, 거래에 이용할 수 있는 아이템의 수, 아이템의 가격 정보, 아이템에 대한 배달 제한, 아이템과 관련된 만료일(예를 들어, 거래가 유효한 기간), 아이템 설명, (예를 들어, 물리적 아이템의) 일련 번호, 아이템과 관련된 미디어(예를 들어, 사진, 비디오 및/또는 오디오 콘텐츠) 등의, 하나 이상의 아이템 세트와 관련된 아이템 속성을 제공할 수 있다. 판매자가 아이템 정보를 제공하는 것에 응답하여, 플랫폼(100)은 거래에 이용가능한 아이템의 수에 대응하는 토큰 세트를 생성한다. 예를 들어, 판매자가 판매에 이용가능한 Model X 위젯이 100개 있다고 표시하면, 플랫폼(100)은 Model X 위젯의 가상 표현을 생성할 수 있고 가상 표현에 대응하는 대체불가능한 토큰 100개를 생성할 수 있으며, 이에 의해, 각각의 토큰은 가상 표현의 각각의 인스턴스에 대응한다. 가상 표현은, 위젯의 설명, 위젯의 설명, 위젯의 가격, 위젯과 관련된 배송 제약, 위젯의 사진, 위젯의 비디오, 위젯과 관련된 가상 현실 데이터 등을 포함할 수 있다. 플랫폼(100)은, 그 다음, 가상 표현 및 대응하는 토큰을 분산형 원장에 저장할 수 있다. 각각의 토큰에 대해, 분산형 원장은, 토큰, 토큰과 관련된 소유권 데이터, 토큰에 대응하는 미디어 콘텐츠(또는 토큰에 대응하는 가상 표현), 및/또는 토큰과 관련된 기타의 적절한 데이터를 분산형 원장에 저장할 수 있다. 처음에는, 토큰의 소유권이 판매자에게 할당될 수 있다. 따라서, 분산형 원장은 토큰의 존재와 판매자가 토큰을 소유하고 있다는 것을 나타낼 수 있다. 일단 토큰화되고 나면, 최종 사용자(예를 들어, 구매자)는 대응하는 토큰을 이용하여 아이템에 대한 거래에 참여할 수 있다. 예를 들어, 사용자는, 플랫폼(100)의 제공자에 의해 제공되거나 지원되는 웹 인터페이스 또는 애플리케이션을 통해 판매자로부터 아이템에 대응하는 토큰을 구매할 수 있다. 거래에 응답하여, 플랫폼(100)은 사용자(예를 들어, 사용자의 계정과 연관된 지갑)로의 토큰의 할당을 표시하기 위해 분산형 원장을 업데이트할 수 있다. 실시예들에서, 토큰의 사본은 토큰의 새로운 소유자(예를 들어, 구매자)에 대응하는 디지털 지갑에 저장될 수 있다.
토큰은 임의의 적절한 방식으로 사용자들 사이에서 전송될 수 있다. 예를 들어, 토큰은, 이메일, 인스턴트 메시지, 텍스트 메시지, 디지털 이전, 소셜 미디어 플랫폼 등을 통해 전송될 수 있다. 이들 실시예들 중 일부에서, 토큰은 전송자의 사용자 디바이스(190)(예를 들어, 사용자의 디지털 지갑)로부터 의도된 수신자와 연관된 사용자 디바이스(190)(예를 들어, 스마트폰) 또는 계정(예를 들어, 이메일 계정 또는 메시징 애플리케이션)으로 직접 이전될 수 있다. 전송을 개시하면, 디지털 지갑은 플랫폼(100)에 이전 요청을 전송할 수 있고 토큰의 사본을 수신자의 사용자 디바이스(190) 또는 명시된 계정에 전송할 수 있다. 일부 실시예에서, 전송된 토큰은, 수신자가 미디어 콘텐츠를 수신하고 토큰 수락을 선택할 수 있도록, 이미지, 이모지 또는 비디오 등의 미디어 콘텐츠에 임베딩될 수 있다. 이 예에서, 토큰은, 토큰을 수신한 사용자 디바이스(190)로 하여금 수신자가 토큰을 수락할 때 수신자의 계정에 토큰을 추가하게 하는 링크 및/또는 소프트웨어 명령어를 수반할 수 있다. 토큰을 수락할 것을 선택하면, 수신자의 사용자 디바이스(190)는 토큰을 수신자의 계정에 추가하라는 요청을 플랫폼에 전송할 수 있다. 플랫폼(100)은 요청을 수신할 수 있고 소유권 이전을 나타내기 위해 분산형 원장에서 토큰의 소유권 기록을 업데이트할 수 있다.
실시예들에서, 토큰 소유자는 토큰을 상환할 수 있다. 실시예들에서, 사용자는 사용자의 디지털 지갑으로부터 상환할 토큰을 선택할 수 있다. 선택에 응답하여, 디지털 지갑은 상환 요청을 플랫폼(100)에 전송할 수 있다. 상환 요청은, 토큰(또는 그 식별자) 및 사용자의 공개 주소(또는 사용자의 임의의 다른 적절한 식별자)를 포함할 수 있다. 플랫폼(100)은 상환 요청을 수신하고 토큰의 유효성 및/또는 토큰의 소유권을 확인한다. 일단 확인되고 나면, 사용자에게는 토큰을 상환할 승인이 부여된다. 일부 시나리오에서, 사용자는 디지털 아이템(예를 들어, 기프트 카드, mp3, 영화, 디지털 사진)에 대응하는 토큰을 상환하는 중일 수 있다. 이들 시나리오에서, 플랫폼(100)은 디지털 아이템을 충족시키기 위한 워크플로우를 결정할 수 있다. 예를 들어, 플랫폼(100)은 사용자에게 이메일 주소를 요청할 수 있거나 분산형 원장에서 사용자의 이메일 주소를 조회할 수 있다. 이 예에서, 플랫폼(100)은 디지털 아이템을 사용자의 이메일 계정으로 다운로드하기 위한 링크를 이메일로 보낼 수 있거나 사용자의 이메일 계정으로 전송되는 이메일에 디지털 아이템의 사본을 첨부할 수 있다. 또 다른 시나리오에서, 사용자는 물리적 상품(예를 들어, 의류, 음식, 전자 제품 등) 또는 물리적 서비스(예를 들어, 가정부 서비스)에 대응하는 토큰을 상환하는 중일 수 있다. 물리적 상품의 경우, 플랫폼(100)은 물리적 아이템을 충족시키기 위한 워크플로우를 결정할 수 있다. 예를 들어, 플랫폼(100)은 사용자에게 배송 정보를 요청할 수 있거나 분산형 원장에서 사용자의 배송 정보를 조회할 수 있다. 플랫폼(100)은, 그 다음, 물리적 상품의 배송을 개시할 수 있다. 예를 들어, 플랫폼(100)은 배송 정보를 나타내는 상품의 배송을 취급하는 창고에 배송 요청을 전송할 수 있다. 전술된 내용은 토큰이 어떻게 상환될 수 있는지에 대한 예이다. 플랫폼(100)은 토큰의 상환을 취급하기 위해 추가의 또는 대안적인 워크플로우를 실행할 수 있다.
실시예들에서, 토큰은, 토큰이 오프라인 위치에서 상환될 수 있도록, 물리적 매체에 인쇄될 수 있다. 예를 들어, 토큰(예를 들어, 영숫자 문자열)은 QR 코드 또는 바코드로 인코딩될 수 있다. 이들 실시예에서, 토큰에 디지털 서명하는데 이용된 당사자의 공개 키(예를 들어, 플랫폼(100)과 연관된 공개 키)도 역시 물리적 매체에 제공될 수 있다. 이러한 방식으로, 토큰은, 플랫폼(100)과 연관된 클라이언트 애플리케이션을 이용하여 QR 코드 또는 바코드를 스캔함으로써 확인될 수 있다. 클라이언트 애플리케이션은 플랫폼(100)에 토큰 및 공개 키를 제공할 수 있고, 플랫폼(100)은 토큰 및 공개 키에 기초하여 토큰의 유효성을 확인할 수 있다. 토큰 및 소유권이 확인되면, 플랫폼(100)은 확인의 확정을 클라이언트 애플리케이션으로 전송할 수 있다. 그러면, 점원은 사용자가 거래를 완료하는 것(예를 들어, 아이템을 소유하는 것)을 허용할 수 있다.
일부 실시예에서, 토큰은, 미리결정된 시간에 또는 미리결정된 이벤트의 발생시에 모든 가치를 잃는다는 점에서 소멸될 수 있다. 이들 실시예들에서, 판매자는 가상 표현이 더 이상 유효하지 않은 날짜 및 시간을 나타내는 가상 표현의 만료를 제공할 수 있으므로, 만료에 도달하면 토큰이 무효로 간주될 수 있다.
토큰은 대체가능한 토큰이거나 대체불가능한 토큰일 수 있다. 대체가능한 토큰은 서로 바꾸어 사용될 수 있는 토큰을 지칭할 수 있다. 예를 들어, 대체가능한 토큰은 모두 동일한 식별자를 가질 수 있다. 대체불가능한 토큰은 고유 토큰이다. 대체불가능한 토큰은 이전될 수 있지만 서로 바꾸어 사용될 수는 없다.
실시예들에서, 플랫폼(100)은, 본 개시내용에서 모두가 더 상세히 논의되는, 시장 시스템(102), 원장 관리 시스템(104), 거래 시스템(106), API 시스템(108), 지능 및 자동화 시스템(110), 분석 및 보고 시스템(112), 및/또는 가상 세계 현장감 시스템(114) 중 하나 이상을 실행할 수 있다.
실시예들에서, 플랫폼(100)은, 아이템의 가상 표현이 정의되거나, 생성되거나, 시청되거나, 및/또는 상환되는 것을 허용하는 시장 시스템(102)을 제공한다. 실시예들에서, 시장 시스템(102)은, 판매자가 가상 표현을 정의하는 것을 허용하고, 소비자가 아이템의 가상 표현을 보고 아이템에 대응하는 토큰을 거래하는 것을 허용하고, 토큰 소유자가 토큰을 상환하는 것을 허용함으로써, 상환된 토큰에 의해 표시된 아이템에 대해 거래를 완료하는 그래픽 사용자 인터페이스를 포함할 수 있다. 시장 시스템(102)은 이들 동작을 지원하기 위한 백엔드 기능을 더 포함할 수 있다.
실시예들에서, 플랫폼(100)은, 토큰을 생성하고 생성된 토큰의 소유권을 관리하는 것을 포함한 하나 이상의 분산형 원장을 관리하는 원장 관리 시스템(104)을 제공한다. 실시예들에서, 원장 관리 시스템(104)은 또한, 분산형 원장을 관여시키는 하나 이상의 스마트 계약과 인터페이스할 수 있다.
실시예들에서, 플랫폼(100)은, 하나 이상의 관련 애플리케이션(예를 들어, 플랫폼(100) 제공자에 의해 제공되는 네이티브 및/또는 웹 애플리케이션), 플랫폼(100)에 의해 지원되거나 플랫폼(100)과 상호작용하는 제3자 시스템, 및 플랫폼(100)과 인터페이스하도록 구성된 스마트 계약에 API를 노출시키도록 플랫폼의 하나 이상의 애플리케이션 프로그래밍 인터페이스(API)를 관리하는 API 시스템(106)을 포함한다. API 시스템(106)은, API 시스템(106)이 요청 디바이스 또는 시스템으로부터 API 호출을 수신하고/하거나 가입 디바이스 또는 시스템에 데이터를 푸시할 수 있도록 하나 이상의 API를 노출할 수 있다. API 시스템(106)은, REST, SOAP 등을 포함한, 임의의 적절한 유형들의 API를 구현할 수 있다. 실시예들에서, API 시스템(106)은, 스마트 계약이 플랫폼과 인터페이스하는 것을 허용하는 스마트 계약 API, 유틸리티 API, 판매자가 아이템의 가상 표현에 대응하는 토큰을 생성하는 것을 허용하는 판매자 API, 및 기타 임의의 적절한 API를 포함할 수 있다. 실시예들에서, 플랫폼(100)은, API 및/또는 소프트웨어 개발 키트(SDK) 등의 클라이언트에 의해 서비스가 액세스될 수 있도록 마이크로 서비스 아키텍쳐를 구현할 수 있다. 이 서비스는, 블록체인 생성, 객체 취급, 소유권 이전, 데이터 통합, ID 관리 등의 복잡성을 추상화하여, 플랫폼 사용자가 플랫폼 능력을 용이하게 구축, 배달 및/또는 소비할 수 있도록 한다. 실시예들에서, SDK 유형은, Android SDK, iOS SDK, Windows SDK, JavaScript SDK, PHP SDK, Python SDK, Swift SDK, Ruby SDK 등을 포함하지만 이것으로 제한되는 것은 아니다.
실시예들에서, 플랫폼(100)은, 대응하는 아이템을 나타내는 토큰의 구매, 판매, 매매, 임대, 대여, 교환, 스왑, 이전, 및/또는 상환을 포함한, 플랫폼에 관련된 임의의 적절한 거래를 지원하는 거래 시스템(108)을 포함한다.
실시예들에서, 플랫폼(100)은, 머신 학습 및 인공 지능 작업을 수행하는 지능 및 자동화 시스템(110)을 포함한다. 예를 들어, 지능 및 자동화 시스템(110)은, 머신 학습 모델을 훈련시키거나, 머신 학습 모델에 기초하여 분류 및 예측을 수행하거나, 사용자에게 제품을 추천하거나, 특정한 사용자를 대상으로 하는 광고를 식별하거나, 서비스 제공자를 서비스 요구자와 매칭시키거나, 및/또는 사용자로의 통보를 자동화할 수 있다.
실시예들에서, 분석 및 보고 시스템(112)은 토큰화 플랫폼(100)의 다양한 양태에 관련된 분석 관련 작업을 수행하고, 결과적 분석을 이해 당사자(예를 들어, 플랫폼 제공자(100)의 직원 및/또는 플랫폼(100) 상의 판매자)에게 보고할 수 있다.
실시예들에서, 플랫폼은 가상 세계 환경에서 아이템의 가상 표현을 프리젠팅하는 가상 세계 현장감 시스템(114)을 포함하거나 지원한다. 예를 들어, 가상 세계 현장감 시스템(114)은 가상 현실 상점을 사용자에게 제공할 수 있으며, 이에 의해 아이템의 가상 표현이 상점에서 프리젠팅되고 사용자는 가상 세계 환경에서 가상 아이템을 "쇼핑"할 수 있다. 이들 실시예들에서, 가상 세계 현장감 시스템(114)은 클라이언트 애플리케이션에서 디스플레이될 수 있는 가상 세계 환경을 렌더링할 수 있다. 가상 세계 환경은 판매자 또는 판매자 그룹과 연관될 수 있고, 이에 의해, 판매자 또는 판매자에 의해 판매된 아이템이 가상 세계 환경에서 이용가능하게 된다. 이들 실시예들에서, 가상 세계 현장감 시스템(114)은 아이템의 가상 표현에 기초하여 판매자 또는 판매자로부터 이용가능한 아이템의 3D 표현을 추가로 렌더링할 수 있다. 그 다음, 3D 표현이 가상 세계 환경에서 프리젠팅되어, 사용자가 아이템의 3D 표현을 검사할 수 있다(예를 들어, 상이한 각도에서 표현 보기). 사용자가 아이템을 구매하기를 원하는 경우, 사용자는 거래를 개시할 수 있다(예를 들어, 가상 표현에서 "구매" 버튼 선택). 사용자가 거래를 개시하면, 가상 세계 현장감 시스템(114)은 거래 시스템(106)에게 사용자의 선택을 통보할 수 있고, 거래는 위에서 설명된 방식으로 진행될 수 있다.
실시예들에서, 플랫폼(100)은 사용자 관리 시스템(116)을 포함한다. 실시예들에서, 사용자 관리 시스템(116)은, 새로운 사용자 계정을 생성하고, 사용자와 연관된 위험을 평가하고, 거래에 참여할 때 사용자와 연관된 개개의 위험에 기초하여 사용자에게 조건을 제공하는 등을 수행할 수 있다.
일부 실시예에서, 사용자 관리 시스템(116)은 사용자를 위한 새로운 계정을 생성한다. 이들 실시예들에서, 새로운 사용자는 플랫폼(100)에 액세스할 수 있고 새로운 계정을 요청할 수 있다. 실시예들에서, 플랫폼(100)은 사용자가 자신의 계정을 외부 시스템(예를 들어, Google®, Facebook®, Twitter® 등)의 계정에 링크하는 것을 허용할 수 있다. 추가로, 또는 대안으로서, 사용자는 이메일 주소와 로그인을 제공할 수 있다. 실시예들에서, 사용자 관리 시스템(116)은, 집 주소 또는 사업장 주소, 여권 번호(및/또는 여권 이미지), 운전 면허 번호(및/또는 그 이미지), 주 ID 카드(및/또는 그 이미지) 등의 추가 인증 정보를 제공할 것을 사용자에게 요청할 수 있다. 사용자 관리 시스템(116)은, 신용 카드 번호, 은행 정보, 암호화폐 지갑(예를 들어, Coinbase® 계정) 등을 입력하는 것을 포함한, 사용자가 임의의 금융 정보를 플랫폼에 링크하기 위한 메커니즘을 추가로 제공할 수 있다. 요청된 정보를 수신하면, 사용자 관리 시스템(116)은 사용자에 대응하는 계정의 새로운 공개 주소를 생성하는 것을 포함한 사용자를 위한 새로운 계정을 생성한다. 일단 계정이 생성되고 나면, 사용자는 플랫폼(100)에서 거래 참여를 개시할 수 있다.
실시예들에서, 사용자 관리 시스템(116)은 사용자가 플랫폼(100)을 이용하여 거래 참여를 시도할 때마다 사용자의 위험 점수를 결정한다. 사용자의 위험 점수는 사용자를 동반한 특정한 거래를 용이화하는 것과 연관된 위험의 정도를 나타낼 수 있다. 위험의 예로는, 판매자가 또 다른 사용자에 의해 구매된 아이템을 배달하지 않을 위험, 판매자가 또 다른 사용자에게 가짜 또는 표준이하 아이템을 배달할 위험, 사용자가 대출을 채무불이행할 위험, 사용자가 사기에 말려들 위험이 포함될 수 있다. 사용자의 위험 점수와 관련될 수 있는 요소에는, 사용자가 2차 인증 정보(예를 들어, 여권 또는 운전 면허증)를 제공했는지, 사용자가 은행 정보를 제공했는지, 사용자가 은행 정보를 제공했는지, 사용자가 플랫폼(100)에서 수행한 구매 또는 판매 횟수, 이들 거래의 크기, 이전 거래들에서 사용자가 얼마나 많은 문제를 겪었는지(예를 들어, 미지불 또는 미배달, 불만 등), 사용자가 플랫폼에 의해 용이화된 대출을 채무불이행했는지 등이 포함될 수 있지만, 이것으로 제한되는 것은 아니다.
일부 실시예에서, 사용자 관리 시스템(116)은, 주어진 거래에서 사용자와 연관된 위험을 평가하도록 훈련된 위험 점수 모델을 이용하여 위험 점수를 결정할 수 있다. 사용자가 거래 참여를 시도할 때, 사용자 관리 시스템(116)은 거래의 피처(예를 들어, 거래의 유형, 거래의 크기 등) 및 사용자의 피처(사용자의 이전 거래들의 결과, 이들 거래의 유형, 사용자가 2차 인증 정보를 제공했는지, 사용자가 은행 정보를 제공했는지, 사용자가 과거에 문제를 겪었는지 등)를 결정할 수 있다. 예를 들어, 사용자가 아이템 판매를 요청하거나 담보 대출을 요청하는 등의 경우, 사용자 관리 시스템(116)은 위험 점수를 결정할 수 있다. 사용자 관리 시스템(116)은, 피처를 위험 점수 모델에 입력할 수 있는 지능 및 자동화 시스템(110)에 피처를 제공할 수 있다. 위험 점수 모델은 피처에 기초하여 위험 점수를 출력할 수 있으며, 위험 점수는 거래 피처 및 사용자 피처가 주어질 경우 거래가 성공할 확률을 나타낸다. 실시예들에서, 위험 점수 모델은, 아래에서 논의되는 바와 같이 지능 및 자동화 시스템(110)(예를 들어, 도 5의 머신 학습 시스템(502))에 의해 훈련될 수 있다.
실시예들에서, 사용자 관리 시스템(116)은 사용자와 연관된 위험에 기초하여 거래에 참여하기를 요청하는 사용자에게 조건 세트를 부과할 수 있다. 조건들의 예로서는, 플랫폼에서 판매될 아이템의 판매 가격과 동일한 자금(예를 들어, 판매자가 아이템을 제공하지 않거나 가짜 아이템을 제공하는 경우 환불되어야 하는 금액)을 에스크로 둘 것을 사용자에게 요구하는 것, 사용자가 대출에 관해 채무불이행을 할 중대한 위험이 있는 경우 대출 금액을 초과하는 담보를 제공할 것을 사용자에게 요구하는 것, 사용자가 대출을 요청하고 해당 정보를 제공하지 않은 경우 2차 인증 정보를 제공할 것을 사용자에게 요구하는 것 등이 포함될 수 있다, 예를 들어, 사용자가 플랫폼(100)에서 아이템을 판매하기를 요청하지만 사용자가 아이템 판매 이력이 없는 경우, 잠재적 거래와 연관된 위험 점수는, 판매자가 아이템을 성공적으로 배달하지 않거나 아이템이 가짜이거나 불만족스러운 상태의 거래가 될 수 있는 위험이 있음을 나타낼 수 있다. 이 예에서, 플랫폼(100)은, 사용자가 판매하기를 원하는 아이템 또는 아이템들의 판매 가격과 같거나 더 큰 금액의 자금을 사용자가 예치(또는 자신의 계정에 보유)할 것을 요구할 수 있다. 이러한 방식으로, 플랫폼(100)은 사용자(즉, 판매자)가 성공적으로 거래를 완료하지 않으면 구매자에게 환불할 수 있다. 실시예들에서, 사용자 관리 시스템(116)은 사용자가 거래에 참여하기를 원할 경우 특정한 거래에 관해 사용자에게 부과할 조건이 있는 경우 이를 결정하기 위한 규칙 세트를 구현할 수 있다. 실시예들에서, 규칙은 특정한 유형의 거래(예를 들어, 판매, 매매, 차용 등)에 대응하는 하나 이상의 조건을 정의할 수 있고 하나 이상의 조건을 트리거하는 위험 점수 임계값을 정의할 수 있다.
플랫폼(100)은 또한, 추가적인 또는 대안적인 시스템을 실행할 수 있다. 예를 들어, 실시예들에서, 플랫폼(100)은 플랫폼(100)의 양태를 게임화하는 게임화 시스템(미도시) 및/또는 소정의 활동에 참여한 사용자에게 보상하는 보상 시스템(미도시)을 포함할 수 있다. 예를 들어, 게임화 시스템은, 소셜 미디어 플랫폼에서 가장 많이 공유되는 가상 아이템을 위해 사용자들이 경쟁할 수 있는 환경을 제공할 수 있다. 이 예에서, 보상 시스템은 사용자들이 소셜 미디어 플랫폼에서 가장 많은 가상 아이템을 공유한 것으로 간주될 때 아이템을 상환하기 위한 토큰으로 사용자에게 보상할 수 있다. 또 다른 예에서, 보상 시스템은 사용자가 소정의 값 또는 양의 가상 아이템을 구매할 때 사용자에게 보상(예를 들어, 소정의 아이템에 대한 토큰)을 발행할 수 있다.
실시예들에서, 플랫폼(100)은 상품 또는 음식 등의 아이템의 물리적 배달을 가능케하는 물류 시스템(미도시)을 포함할 수 있다. 물류 시스템은, 아이템의 소스 위치(예를 들어, 창고 또는 레스토랑)로부터 토큰의 상환자(예를 들어, 집 또는 상환자의 현재 위치)까지의 물류를 관리하도록 구성될 수 있다. 실시예들에서, 물류 시스템은 배달 위치를 결정하기 위한 지리위치 시스템(미도시)을 포함할 수 있다. 예를 들어, 피자 배달 체인으로부터 토핑이 한 개 있는 피자에 대응하는 토큰 소유자가 토큰을 상환하면, 지리위치 시스템은 배달을 위해 수신자의 현재 위치를 결정할 수 있다. 지리위치 정보는, 스마트폰, 웹 브라우저(예를 들어, IP 주소) 등에 의해 취득될 수 있다. 이 예에서, 물류 시스템은 사용자의 지리위치(또는 선택된 배달 위치) 및 사용자의 주문(예를 들어, 사용자가 선택한 토핑)에 기초하여 전자 통보를 생성할 수 있고, 의도한 배달 위치에 가장 가까운 피자 배달 체인의 위치로 전자 통보를 전송할 수 있다.
도 2는 본 개시내용의 일부 실시예에 따른 시장 시스템(102)의 예를 나타낸다. 실시예들에서, 시장 시스템(102)은, 아이템 관리 시스템(202), 구매자 시장 시스템(204), 및 상환 시스템(206)을 포함할 수 있다.
아이템 관리 시스템(202)은 아이템의 판매자가 아이템의 가상 표현을 정의하는 것을 허용한다. 실시예들에서, 아이템 관리 시스템(202)은 판매자가 아이템의 속성을 정의하는 것을 허용하는 GUI를 판매자의 사용자 디바이스(190)에 프리젠팅한다. 아이템이 플랫폼(100)에서 판매된 적이 없는 경우, 판매자는 새로운 아이템을 추가하는 옵션을 선택할 수 있다. 이에 대한 응답으로, 판매자는 아이템의 유형을 나타내는 아이템 분류(예를 들어, "신발", "피자", "사진", "영화", "콘서트 티켓들", "기프트 카드" 등) 및 아이템의 이름을 제공할 수 있다. 그 다음, 판매자는 아이템의 하나 이상의 추가 속성을 정의할 수 있다. 예를 들어, 실시예들에서, 판매자는, 아이템 설명, 아이템과 연관된 미디어 콘텐츠(예를 들어, 사진, 비디오, 오디오 클립 등), 관련 링크(예를 들어, 판매자의 웹사이트 링크), 아이템의 가격, 아이템에 관련된 제약사항(예를 들어, "미국 배송만 가능" 또는 "판매자 개장 시간은 10-6"), 상환 지침(예를 들어, 매장내 상환이 허용, 허락 또는 필수인지, 디지털 자산이 다운로드되는지 또는 이메일 전송되는지, 아이템이 이전가능한지 등), 거래에 이용가능한 아이템의 수(예를 들어, 이용가능한 유닛 수), 및/또는 기타 임의의 적절한 속성을 제공할 수 있다. 판매자가 아이템 속성을 제공하는 것에 응답하여, 아이템 관리 시스템(202)은 아이템의 가상 표현을 생성할 수 있다. 실시예들에서, 가상 표현은 아이템의 속성을 포함하는 데이터 레코드일 수 있다. 가상 표현이 이전에 정의된 시나리오에서, 판매자는 이전에 정의된 아이템을 선택하고 하나 이상의 속성을 업데이트할 수 있다. 예를 들어, 판매자는, 추가 미디어 콘텐츠를 제공하거나, 가격을 변경하거나, 및/또는 이용가능한 아이템 수를 업데이트할 수 있다. 업데이트된 가상 표현이든 새로 정의된 가상 표현이든, 아이템 관리 시스템(202)은 가상 표현을 원장 관리 시스템(104)에 출력할 수 있으며, 여기서 원장 관리 시스템(104)은 가상 표현의 인스턴스를 토큰화하여 토큰 세트를 획득될 수 있다.
일부 실시예에서, 아이템 관리 시스템(202)은 판매자가 판매자 속성도 역시 제공하는 것을 허용할 수 있다. 판매자는, 물리적 아이템이 배송될 수 있는 물리적 위치, 디지털 상품이 회수될 있는 디지털 위치, 판매자의 오프라인 상점의 물리적 위치, 판매자의 영업 시간 등의 정보를 제공할 수 있다. 이들 속성은 가상 표현에 포함되거나 대안적인 날짜 레코드에 저장될 수 있다.
실시예들에서, 아이템 관리 시스템(202)은 플랫폼(100)이 새로운 유형의 자산의 판매 및 매매를 지원할 수 있게 하기 위해 새로운 유형의 아이템을 생성하고 정의하기 위한 자산 유형 관리자를 포함할 수 있다. 이들 실시예들에서, 자산 유형 관리자는 사용자가 새로운 유형의 자산을 정의하는 것을 허용하는 GUI를 제공할 수 있다. 이들 실시예들에서, 자산 유형 속성 필드는 사용자가 정의되고 있는 새로운 자산 유형 특유의 정보를 추가하는 것을 허용한다. 속성 정보는 구매 결정을 내릴 때 구매자에 대한 정보 자료로서 이해될 수 있으며 플랫폼에 디스플레이될 수 있는 자산 유형 및 정보 특유의 정보이어야 한다. 자산 유형 속성 필드는, 자산 유형 이름, 자산 유형 이미지, 자산 상환 URL, 자산 설명자(예를 들어, 물리적 또는 디지털) 등을 포함하지만 이것으로 제한되는 것은 아니다.
실시예들에서, 아이템 관리 시스템(202)은 새로운 유형의 아이템들을 정의하기 위한 아이템 유형 정의 관리자를 포함할 수 있어서 이들이 플랫폼에 나열될 수 있게 할 수 있다. 실시예들에서, 아이템 유형 정의 관리자는 사용자가 새로운 아이템의 속성을 정의하는 것을 허용하는 GUI를 제공할 수 있다. 새로운 아이템 유형을 정의하기 위해, 사용자는, 드롭다운 메뉴에서 적절한 자산 유형을 선택할 것을 촉구받을 수 있다. GUI는 사용자가 아이템 속성 필드에서 아이템 속성을 정의하는 것을 허용할 수 있다. 아이템 속성 필드에는, 아이템 이름, 아이템 설명, 아이템 메모, 아이템 이미지, 아이템 가격 데이터(예를 들어, 제안 가격, 제안 최저 가격), 즉시 판매 플래그, 아이템 구매를 위해 웹페이지에 링크되는 URL, 아이템 수량 등이 포함될 수 있지만, 이것으로 제한되는 것은 아니다. 사용자가 필수 아이템 속성을 제공할 때, 아이템 관리 시스템(202)은 새로운 아이템을 정의하는 새로운 가상 표현을 생성할 수 있다.
일부 실시예에서, 아이템 관리 시스템(202)은 토큰화 플랫폼(100)에서 판매되는 상품의 가치와 동일한 금액의 자금을 에스크로잉할 것을 충분한 이력이 없는 판매자에게 요구할 수 있다. 판매자는 아이템을 나타내는 토큰을 판매할 수 있으며, 토큰이 토큰 소유자(예를 들어, 구매자 또는 다운스트림 수신자)에 의해 상환되면, 에스크로에서 자금이 제거되고 판매자의 계정으로 반환된다. 이들 실시예들에서, 판매자는 물리적 아이템을 에스크로할 필요가 없으며, 이것은 적어도 하나의 추가적 배송이 창고 또는 기타의 저장 시설에 대해 이루어질 것을 요구한다.
실시예들에서, 구매자 시장 시스템(204)은, 소비자가, 아이템을 브라우징 또는 검색하고, 아이템의 가상 표현을 보고, 아이템에 대한 거래에 참여하는 것을 허용한다. 실시예들에서, 구매자 시장 시스템(204)은, 사용자가 하나 이상의 검색어로 구성된 검색 질의를 입력하는 것을 허용하는 검색 바를 포함하는 GUI를 프리젠팅한다. 검색 질의의 수신에 응답하여, 구매자 시장 시스템(204)은 하나 이상의 검색어를 이용하여 가상 표현을 인덱싱하는 하나 이상의 인덱스를 질의할 수 있다. 구매자 시장 시스템(204)은 검색 질의를 처리하고 임의의 적절한 검색 기술을 이용하여 후속 검색을 수행할 수 있다. 검색을 수행하는 것에 응답하여, 구매자 시장 시스템(204)은 검색에 관련된 가상 표현을 회수할 수 있고 시각적 방식으로 가상 표현을 프리젠팅할 수 있다. 예를 들어, GUI는 하나 이상의 검색 결과를 디스플레이하는 검색 엔진 결과 페이지(SERP)를 디스플레이할 수 있으며, 여기서 각각의 검색 결과는 상이한 가상 표현에 대응하고, 사용자가, 아이템 및 아이템의 가격과 연관된 임의의 미디어 콘텐츠를 포함한 아이템의 가상 표현에서 정의된 아이템의 속성을 볼 수 있고 아이템에 대응하는 토큰을 구매할 것을 선택할 수 있는 개개의 페이지에 링크된다.
실시예들에서, 구매자 시장 시스템(204)은 사용자가 플랫폼에서 제공되는 가상 아이템들을 브라우징하는 것을 허용할 수 있다. 예를 들어, 구매자 시장 시스템(204)은 소비자가 범주 또는 기타의 속성으로 아이템을 필터링하는 것을 허용하는 GUI를 제공할 수 있다. GUI는 사용자가 아이템에 대응하는 링크를 선택하는 것을 허용하고, 링크는 사용자가 아이템 및 아이템의 가격과 연관된 임의의 미디어 콘텐츠를 포함한 아이템의 가상 표현에 정의된 아이템의 속성을 볼 수 있고, 아이템에 대응하는 토큰을 구매하는 것을 선택할 수 있는 페이지로 사용자를 안내한다.
실시예들에서, 소비자가 아이템을 구매하기로 선택할 때, 구매자 시장 시스템(204)은 구매에 대해 원장 관리 시스템(104)에 통보할 수 있다. 구매자 시장 시스템(204)은 사용자의 공개 주소 및 선택된 아이템의 가상 표현의 식별자를 원장 관리 시스템(104)에 제공할 수 있다. 원장 관리 시스템(104)은 가상 표현에 대응하는 토큰 세트로부터의 한 토큰을 사용자의 공개 주소와 연관된 계정에 할당하고 사용자의 공개 주소에 할당된 토큰의 소유권 변경을 표시하도록 분산형 원장을 업데이트함으로써 거래를 실행할 수 있다. 예를 들어, 구매자 시장 시스템(204)(또는 거래 시스템(106))은 판매자에 의해 현재 소유된 토큰을 식별할 수 있고 토큰의 소유권을 구매자의 계정으로 이전할 수 있다. 일단 이것이 발생하면, 토큰 사본이 사용자의 계정에 예치될 수 있다. 예를 들어, 토큰은 사용자의 디지털 지갑에 예치될 수 있다.
실시예들에서, 구매자 시장 시스템(205)은 아이템을 개개의 썸네일 이미지로서 묘사할 수 있다. 이들 실시예들 중 일부에서, 간단한 박스 스타일의 사용자 인터페이스 요소가 아이템 상세 페이지에 추가되어, 아이템 설명 속성, 아이템 메모 속성 및 판매자 URL 속성을 포함한 아이템의 속성을 디스플레이할 수 있다. GUI 상의 아이템 설명 필드는, 플랫폼 사용자를 제품 또는 기타의 관련 페이지에 관한 자세한 정보를 갖는 페이지로 리디렉션할 수 있는 클릭가능한 URL을 지원할 수 있다. 아이템 설명 텍스트박스가 디스플레이될 수 있으며 제3자 도메인에 대한 링크를 지원한다.
실시예들에서, 구매자 시장 시스템(204)은 사용자가 주문 제작 아이템을 구매하는 것을 허용할 수 있다. 예를 들어, 사용자는, 맞춤형 피자, 가구, 꽃꽂이 등을 주문할 수 있다. 사용자는 복수의 판매자로부터의 복수의 아이템으로 구성된 아이템을 디지털 방식으로 구축하고 그 아이템을 3D 프린팅 스테이션에서 3D 프린팅할 수 있다.
도 3은 본 개시내용의 일부 구현에 따른 하나 이상의 분산형 원장(210)을 관리하는 토큰화 플랫폼(100)의 원장 관리 시스템(104)의 예를 나타낸다. 실시예들에서, 원장 관리 시스템(104)은, 토큰 생성 시스템(302), 원장 업데이트 시스템(304), 및 확인 시스템(306)을 포함한다. 토큰 생성 시스템(302)은, 거래에 이용가능하게 된 아이템에 대응하고 아이템의 개개의 가상 표현에 기초한 토큰을 생성하도록 구성될 수 있다. 원장 업데이트 시스템(304)은 분산형 원장을 업데이트(310)하라는 요청을 수신하고 그에 따라 분산형 원장을 업데이트한다(310). 확인 시스템(306)은, 토큰, 계정 등을 확인하라는 요청을 수신하고 분산형 원장에 기초하여 토큰 또는 계정 확인을 시도한다.
실시예들에서, 분산형 원장(310)은 N개의 노드 컴퓨팅 디바이스(160)가 원장(310)의 N개의 개개 사본을 저장하도록 공개 원장일 수 있으며, 여기서 각각의 사본은 분산형 원장(310)의 적어도 일부를 포함한다. 다른 실시예들에서, 분산형 원장(310)은 비공개 원장이며, 여기서 원장은 플랫폼(100)의 제어하에 노드들에 분산된다. 실시예들에서, 분산형 원장(310)은 블록체인(예를 들어, ETC 프로토콜에 대응하는 Ethereum 블록체인)이다. 대안으로서, 분산형 원장(310)은 다른 적절한 프로토콜(예를 들어, Hashgraph, Byteball, Nano-Block Lattice, 또는 IOTA)과 호환될 수 있다. 분산형 원장(310)에 토큰을 저장함으로써, 원장을 조회하여 토큰의 상태가 언제든지 확인될 수 있고 올바르다고 신뢰할 수 있다. 구현에 대해 토큰 접근법을 이용함으로써, 토큰이 허가 없이 복사되고 상환될 수 없다.
분산형 원장(310)은, 아이템, 사용자, 판매자 등과 관련된 임의의 적절한 데이터를 저장할 수 있다. 실시예들에서, 분산형 원장(310)은 아이템 관련 데이터를 저장할 수 있다. 아이템 관련 데이터는, 아이템 식별자, 아이템의 만료일, 아이템에 관한 조건 또는 제약, 아이템 설명, 아이템에 관련된 미디어 콘텐츠(예를 들어, 사진, 로고, 비디오 등), 아이템의 문서화, 맞춤화 옵션, 이용가능한 크기, 이용가능한 색상, 이용가능한 재료, 기능 옵션, 성분, 가격, 아이템과 관련된 특별 제안 또는 할인, 위치 정보(예를 들어, 아이템을 배달/제공할 수 있는 위치), 이용가능한 시간, 소유자/관리자 데이터, 리뷰, 아이템 유형 등이 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 실시예들에서, 분산형 원장(310)은 사용자 데이터를 저장할 수 있다. 사용자 데이터는, 식별 정보(예를 들어, 사용자 ID, 이메일 주소, 이름 등), 공개 주소, 금융 정보(예를 들어, 신용 카드 정보), 거래 내역, 위치 데이터(예를 들어, 사용자의 지역 또는 사용자의 국가), 선호사항, 희망사항 목록, 사용자의 가입, 사용자에 속하는 아이템, 사용자 연결 또는 연락처, 사용자에 관련된 미디어 콘텐츠(예를 들어, 사용자의 사진 또는 비디오), 사용자의 아바타 등을 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 실시예들에서, 분산형 원장(310)은 판매자 관련 데이터를 저장할 수 있다. 판매자 관련 데이터는, 식별 정보(예를 들어, 판매자 이름, 판매자 ID, 및/또는 기타 등등), 판매자의 연락처 정보, 경험 데이터, 위치 데이터, 이용가능한 시간, 리뷰, 미디어 콘텐츠(사진, 비디오 등), 및/또는 기타 임의의 적절한 판매자 관련 데이터를 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 분산형 원장(310)은 추가의 및/또는 대안적인 데이터를 저장할 수 있다.
실시예들에서, 분산형 원장(310)은 사이드 체인(314)을 포함한다. 사이드 체인(314)은 원장(310)의 메인 체인(312)의 세그먼트(예를 들어, 블록)로부터 연장되는 분산형 원장(310)의 샤드를 참조할 수 있다. 실시예들에서, 메인 체인(312)은 계정(예를 들어, 공개 주소)을 가진 판매자 및 사용자에 관련된 데이터를 저장할 수 있다. 추가로 또는 대안으로서, 메인 체인(312)은, 아이템 분류의 설명 등의 아이템 분류 데이터를 저장할 수 있다. 실시예들에서, 사이드 체인(314)은 아이템의 특정한 분류에 속할 수 있다. 이들 실시예들 중 일부에서, 사이드 체인(314)은 아이템의 개개의 종류 또는 클래스에 속하는 아이템의 가상 표현 및 이들 아이템과 관련된 데이터를 저장할 수 있다. 예를 들어, 제1 사이드 체인(314-1)은 플랫폼(100)에서 이용가능한 신발의 가상 표현 및 이들 가상 표현과 관련된 임의의 토큰 관련 데이터를 저장할 수 있다. 실시예들에서, 사이드 체인(314)은 플랫폼에서 거래에 이용가능한 아이템과 관련하여 이용되는 미디어 콘텐츠를 저장할 수 있다. 예를 들어, 제2 사이드 체인(314-2)은, 제1 사이드 체인(314-1)에서 표현된 신발을 묘사하는 사진, 제1 사이드 체인(314-1)에서 표현된 신발을 묘사하는 비디오 클립, 제1 사이드 체인(314-1)에서 표현된 신발과 관련된 오디오 클립, 제1 사이드 체인(314-1)에서 표현된 신발을 묘사하는 가상 현실 콘텐츠, 제1 사이드 체인(314-1)에서 표현된 신발을 묘사하는 증강 현실 콘텐츠 등을 저장할 수 있다. 앞서 말한 내용은 분산형 원장을 샤딩하는 한 가지 방식이다. 분산형 원장(310)은 임의의 다른 적절한 방식으로 샤딩될 수 있다.
실시예들에서, 토큰 생성 시스템(302)은 가상 표현을 수신하고 가상 표현에 대응하는 하나 이상의 토큰을 생성한다. 실시예들에서, 가상 표현은 가용 아이템의 수(제한된 경우)(즉, 거래에 이용가능한 아이템의 수)를 포함한 아이템의 속성을 포함한다. 실시예들에서, 가용 아이템의 수는 토큰 생성 시스템(302)이 특정한 가상 표현에 대해 생성하는 토큰의 수를 나타낸다. 속성은 또한, 토큰의 만료(예를 들어, 토큰이 유효할 수 있는 기간) 등의, 아이템과 관련된 기타의 제약을 포함할 수 있다. 토큰 생성 시스템(302)은 또한, 초기 소유권 데이터를 수신할 수 있다. 초기 소유권 데이터는 토큰의 초기 소유자를 정의한다. 디폴트로서, 가상 표현에 의해 표현되는 아이템을 제공하는 엔티티(예를 들어, 아이템의 판매자)가 토큰의 초기 소유자이다. 그러나, 초기 소유권은 상이한 엔티티에 할당될 수도 있다.
실시예들에서, 토큰은 가상 표현의 인스턴스를 포장하는 래퍼(wrapper)이다. 이들 실시예들 중 일부에서, 토큰 생성 시스템(302)은 토큰을 식별하는 토큰 식별자를 생성할 수 있다. 토큰이 대체불가능한 토큰인 시나리오에서, 토큰 생성 시스템(302)은 가상 표현에 대응하는 각각의 개개 토큰에 대한 고유 식별자를 생성할 수 있다. 토큰 생성 시스템(302)은 임의의 적절한 기술을 이용하여 토큰 식별자를 생성할 수 있다. 예를 들어, 토큰 생성 시스템(302)은, 토큰을 식별하는 값을 생성하기 위해, 난수 생성, 케이스 생성, 단순 생성, 및/또는 토큰 브릿지 생성을 구현할 수 있다. 실시예들에서, 토큰 생성 시스템(302)은 개인 키/공개 키 쌍을 이용하여 값에 디지털적으로 서명할 수 있다. 토큰 생성 시스템(302)은 토큰을 식별하는 값에 디지털적으로 서명하기 위해 플랫폼(100) 또는 판매자와 연관된 개인 키/공개 키 쌍을 이용할 수 있다. 토큰 생성 시스템(302)은, 국립 표준 기술 연구소(National Institute of Standards and Technology)에 의해 개발된 DSA(Digital Signature Algorithm) 등의, 토큰을 식별하는 값에 디지털적으로 서명하기 위해 임의의 적절한 디지털 서명 알고리즘을 구현할 수 있다. 실시예들에서, 결과적인 디지털 서명이 토큰 식별자로서 이용될 수 있다. 각각의 토큰에 대해, 토큰 생성 시스템(302)은 토큰 식별자 및 아이템의 가상 표현을 포함하는 토큰 래퍼를 생성할 수 있다. 실시예들에서, 토큰 생성 시스템(302)은 토큰을 디지털적으로 서명하는데 이용되는 공개 키를 토큰에 임베딩하거나 기타의 방식으로 인코딩할 수 있다. 대안으로서, 토큰 생성 시스템(302)은, 토큰이 새로운 소유자에게 이전될 때마다 공개 키가 토큰 소유자의 계정에 전달되도록 토큰과는 별도로 공개 키를 저장할 수 있다. 대체불가능한 토큰의 생성시, 토큰 생성 시스템(302)은 대체불가능한 토큰을 원장 업데이트 시스템(304)에 출력할 수 있다. 래퍼는, 대체가능한 토큰들 및 대체불가능한 토큰들을 포함한, 복수의 토큰을 포장할 수 있다.
일부 실시예에서, 토큰 생성 시스템(302)은 대체가능한 토큰을 생성할 수 있다. 이들 실시예들에서, 토큰 생성 시스템(302)은 동일한 토큰을 생성할 수 있고, 여기서 각각의 토큰은 동일한 토큰 식별자를 갖는다. 이들 실시예들에서, 토큰 생성 시스템(302)은 전술된 방식으로 단일 토큰 식별자를 생성할 수 있고, 그 토큰 식별자를 이용하여 N개의 대체가능한 토큰을 생성할 수 있으며, 여기서 N은 총 토큰의 수이다. N개의 대체가능한 토큰을 생성할 때, 토큰 생성 시스템(302)은 N개의 대체가능한 토큰을 원장 업데이트 시스템(304)에 출력할 수 있다.
실시예들에서, 원장 업데이트 시스템(304)은, 하나 이상의 분산형 원장(310)을 업데이트하고 유지하도록 구성된다. 본 명세서에서 사용될 때, 분산형 원장(310)을 업데이트하고 유지하는 것이란, 분산형 원장(310)에 데이터를 기입하는 것을 말할 수 있다. 실시예들에서, 원장 업데이트 시스템(304)은 분산형 원장이 준수하는 프로토콜에 따라 블록을 생성할 수 있으며, 여기서 블록은 분산형 원장(310)에 기입될 데이터를 포함한다. 실시예들에서, 원장 업데이트 시스템(304)은, 생성된 블록을 분산형 원장(310)을 저장하는 컴퓨팅 노드(160)에 브로드캐스트함으로써 분산형 원장(310)을 업데이트할 수 있다. 컴퓨팅 노드(160)가 수신된 블록을 분산형 원장(310)의 로컬 사본으로 수정할지를 결정하는 방식은 분산형 원장이 준수하는 프로토콜에 의해 정의될 수 있다.
실시예들에서, 원장 업데이트 시스템(304)은 토큰을 수신하고 이에 기초하여 분산형 원장(310)을 업데이트한다. 이들 실시예들 중 일부에서, 원장 업데이트 시스템(304)은 토큰 및 소유권 데이터(예를 들어, 토큰이 할당될 엔티티의 공개 주소)를 수신하고 이에 기초하여 분산형 원장(310)을 업데이트한다. 예를 들어, 원장 업데이트 시스템(304)은 토큰이 임베딩된 블록을 생성할 수 있다. 생성된 블록 또는 후속해서 생성된 블록은 토큰과 관련된 소유권 데이터를 포함할 수 있다. 원장 업데이트 시스템(304)은 생성된 블록(들)을 분산형 원장(310)에 기입할 수 있다. 예를 들어, 원장 업데이트 시스템(304)은 플랫폼(100)에서 유지되는 분산형 원장(310)의 사본으로 블록(들)을 수정하고/하거나 분산형 원장(310)의 사본을 저장하는 컴퓨팅 노드(160)에 블록(들)을 브로드캐스트할 수 있고, 컴퓨팅 노드(160)는 결국 브로드캐스트 블록(들)을 이용하여 분산형 원장의 개개의 사본을 수정한다. 분산형 원장(310)이 샤딩되는 실시예들에서, 원장 업데이트 시스템(304)은 토큰에 대응하는 사이드 체인(314)(예를 들어, 아이템 분류)을 지정할 수 있다. 이들 실시예들에서, 생성된 블록은 지정된 사이드 체인(314)으로 수정되어 토큰의 존재 및 토큰의 현재 소유권을 나타낸다.
실시예들에서, 원장 업데이트 시스템(304)은 토큰의 소유권을 또 다른 계정으로 변경할 것을 요청하는 소유권 변경 요청을 수신한다. 예를 들어, 원장 업데이트 시스템(304)은, 토큰의 구매, 토큰의 선물, 토큰의 재판매, 토큰의 매매 등에 응답하여 소유권 변경 요청을 수신할 수 있다. 일부 실시예에서, 소유권 변경 요청은, 이전될 토큰 및 토큰 양수인(예를 들어, 토큰의 수신자)의 공개 주소를 정의할 수 있다. 일부 실시예에서, 소유권 변경 요청은, 토큰의 현재 소유자의 공개 주소를 더 포함할 수 있다(토큰이 현재 소유자를 갖고 있다고 가정). 원장 업데이트 시스템(304)은 소유권 변경 요청을 수신할 수 있고 관여된 토큰의 새로운 소유자를 표시하는 블록을 생성할 수 있다. 원장 업데이트 시스템(304)은 생성된 블록(들)을 분산형 원장(310)에 기입할 수 있다. 예를 들어, 원장 업데이트 시스템(304)은 블록(들)을 분산형 원장(310)으로 수정할 수 있고/있거나 분산형 원장(310)을 저장하는 컴퓨팅 노드(160)에 블록(들)을 브로드캐스트할 수 있다. 분산형 원장(310)이 샤딩되는 실시예들에서, 원장 업데이트 시스템(304)은 토큰에 대응하는 사이드 체인(314)(예를 들어, 아이템 분류)을 지정할 수 있다. 이들 실시예들에서, 생성된 블록은 지정된 사이드 체인(314)으로 수정되어 토큰의 새로운 소유자를 나타낼 수 있다.
실시예들에서, 원장 업데이트 시스템(304)은 새로운 또는 변경된 가상 표현을 수신하고 분산형 원장(310)을 업데이트하여 새로운 또는 변경된 가상 표현을 반영한다. 예를 들어, 원장 업데이트 시스템(304)은, 판매자가 거래에 이용가능한 새로운 아이템을 정의할 때 새로운 시각적 표현을 수신할 수 있다. 원장 업데이트 시스템(304)은, 판매자가 이전에 정의된 가상 표현의 하나 이상의 속성을 변경하는 것에 응답하여 변경된 가상 표현을 수신할 수 있다. 실시예들에서, 원장 업데이트 시스템(304)은 새로운 또는 변경된 가상 표현을 수신하고 수신된 가상 표현에 기초하여 하나 이상의 블록을 생성한다. 원장 업데이트 시스템(304)은 생성된 블록(들)에 기초하여 생성된 블록(들)을 분산형 원장(310)에 기입할 수 있다. 예를 들어, 원장 업데이트 시스템(304)은 블록(들)을 분산형 원장으로 수정하고/하거나 분산형 원장을 저장하는 컴퓨팅 노드(160)에 블록(들)을 브로드캐스트할 수 있다. 분산형 원장(310)이 샤딩되는 실시예들에서, 가상 표현에 속하는 미디어 콘텐츠는 별도의 사이드 체인(314)에 저장될 수 있다. 이들 실시예들 중 일부에서, 미디어 콘텐츠는 가상 표현과는 별개의 블록에 저장될 수 있으며, 여기서 가상 표현을 포함하는 블록은 대응하는 미디어 콘텐츠를 포함하는 블록에 대한 참조를 포함할 수 있다. 원장 업데이트 시스템(304)은, 가상 표현에 대응하는 사이드 체인(314)(예를 들어, 아이템 분류) 및 미디어 콘텐츠 블록(들)에 대응해야 하는 사이드 체인(314)을 지정할 수 있다. 이들 실시예들에서, 생성된 블록은 개개의 지정된 사이드 체인(314)으로 수정되어 새로운 또는 수정된 가상 표현을 나타낸다. 원장 업데이트 시스템(304)은 생성된 블록(들)을 분산형 원장(310)에 기입할 수 있다. 예를 들어, 원장 업데이트 시스템(304)은 블록(들)을 분산형 원장(310)으로 수정하고/하거나 분산형 원장(310)을 저장하는 컴퓨팅 노드(160)에 블록(들)을 브로드캐스트할 수 있다. 분산형 원장(310)이 샤딩되는 실시예들에서, 원장 업데이트 시스템(304)은 소각된 토큰(burned token)에 대응하는 사이드 체인(314)(예를 들어, 아이템 분류)을 지정할 수 있다. 이들 실시예들에서, 생성된 블록은 지정된 사이드 체인(314)으로 수정되어 새로운 및/또는 수정된 가상 표현(들)을 나타낸다.
실시예들에서, 원장 업데이트 시스템(304)은 또한, 토큰들을 "소각"하도록 구성된다. 토큰을 소각하는 것이란, 토큰이 더 이상 상환될 수 없는 것으로 간주되는 메커니즘을 말할 수 있다. 토큰이 만료되거나 토큰이 상환될 때 토큰은 소각될 수 있다. 실시예들에서, 원장 업데이트 시스템(304)은 토큰이 현재 소유되어 있지 않음을 나타내도록(예를 들어, 소유자 = NULL) 토큰의 소유권을 업데이트할 수 있고/있거나 토큰이 더 이상 유효하지 않음을 나타내도록 토큰 상태를 업데이트할 수 있다. 이들 실시예들 중 일부에서, 원장 업데이트 시스템(304)은 토큰이 현재 소유되어 있지 않거나 토큰의 상태가 유효하지 않음을 나타내는 블록을 생성할 수 있다. 원장 업데이트 시스템(304)은 생성된 블록(들)을 분산형 원장(310)에 기입할 수 있다. 예를 들어, 원장 업데이트 시스템(304)은 블록(들)을 분산형 원장(310)으로 수정할 수 있고/있거나 분산형 원장(310)을 저장하는 컴퓨팅 노드(160)에 블록(들)을 브로드캐스트할 수 있다. 일부 실시예에서, 분산형 원장(310)은 샤딩된다. 이들 실시예들에서, 원장 업데이트 시스템(304)은 토큰에 대응하는 사이드 체인(314)(예를 들어, 아이템 분류)을 지정할 수 있다. 이들 실시예들에서, 생성된 블록은 지정된 사이드 체인(314)으로 수정되어 소각된 토큰을 나타낸다.
원장 업데이트 시스템(304)은 다른 데이터도 역시 나타내도록 분산형 원장(310)을 업데이트할 수 있다. 실시예들에서, 원장 업데이트 시스템(304)은 분산형 원장(310) 상의 판매자 데이터 및/또는 사용자 데이터를 유지하고 업데이트할 수 있다. 예를 들어, 원장 업데이트 시스템(304)은 유효한 계정의 공개 주소 목록을 유지할 수 있다. 원장 업데이트 시스템(304)은 이들 계정의 공개 주소와 함께 플랫폼(310)에 추가되는 새로운 계정을 반영하도록 암호화 원장을 업데이트할 수 있다. 원장 업데이트 시스템(304)은 추가의 또는 대안적인 판매자 및 사용자 데이터를 역시 분산형 원장에 저장할 수도 있다.
실시예들에서, 확인 시스템(306)은 분산형 원장(310)에 저장된 데이터를 확인한다. 실시예들에서, 확인 시스템(306)은 토큰의 유효성을 확인할 수 있고/있거나 토큰의 소유권을 확인할 수 있다. 확인 시스템(306)은 또한, 분산형 원장(310)에 저장된 다른 유형의 데이터를 유효성확인하도록 구성될 수 있다.
실시예들에서, 확인 시스템(306)은 토큰 확인 요청을 수신한다. 토큰 확인 요청은, 확인될 토큰 또는 그 토큰 식별자를 포함할 수 있다. 이들 실시예들에서, 확인 시스템(306)은 확인될 토큰의 토큰 식별자가 분산형 원장(310)에 저장되어 있는지를 결정할 수 있다. 분산형 원장(310)에 저장되어 있지 않은 경우, 확인 시스템(306)은 토큰이 무효한 것으로 간주할 수 있다. 일부 실시예에서, 토큰 확인 요청은 토큰을 확인하는데 이용될 공개 키를 더 포함할 수 있다. 이들 실시예들에서, 확인 모듈(306)은 수신된 공개 키를 이용하여 공개 키가 분산형 원장(310)에 저장된 토큰에 대응하는지를 결정할 수 있다. 이들 실시예들 중 일부에서, 확인 시스템(306)은 수신된 공개 키 및 디지털 서명을 인코딩하는데 이용된 개인 키를 이용하여 수신된 공개 키가 토큰에 서명하는데 이용된 공개 키인지를 결정한다. 예를 들어, 실시예들에서, 확인 시스템(306)은 개인 키 및 수신된 공개 키를 이용하여 디지털 서명을 해독하려고 시도할 수 있다. 개인 키 및 수신된 공개 키가 디지털 서명의 해독을 가능케하여 토큰을 생성하는데 이용된 값을 획득할 수 있다면, 확인 시스템(306)은 토큰을 유효하다고 간주할 수 있고 요청 시스템에 확인을 통보할 수 있다.
실시예들에서, 확인 시스템(306)은 토큰의 소유권을 확인하도록 구성될 수 있다. 이들 실시예들에서, 확인 시스템(306)은 확인될 공개 주소 및 토큰(또는 그 식별자)을 수신할 수 있다. 일부 실시예에서, 확인 시스템(306)은 공개 주소가 플랫폼(100) 상의 계정에 대응하는지를 확인할 수 있다. 예를 들어, 확인 시스템(306)은 공개 주소가 분산형 원장(310) 상의 공개 주소 목록에 저장되어 있는지를 결정할 수 있다. 만일 그렇다면, 확인 시스템(306)은 토큰에 관련된 소유권 데이터가 현재 수신된 공개 주소에 의해 표시된 계정에 의해 소유되어 있는지를 결정할 수 있다. 만일 그렇다면, 확인 시스템(306)은 토큰의 소유권을 확인할 수 있고 확인을 요청 시스템에 출력할 수 있다.
도 4는 본 개시내용의 일부 실시예에 따른 토큰화 플랫폼(100)의 거래 시스템(106)의 예를 나타낸다. 일부 실시예에서, 거래 시스템(106)은 토큰 이전 시스템(402) 및 상환 시스템(404)을 포함한다. 거래 시스템(106)은 본 개시내용의 범위를 벗어나지 않고 추가의 또는 대안적인 시스템을 포함할 수 있다. 예를 들어, 거래 시스템(106)은, 디지털 지갑 시스템(408), 신속 매매 시스템(410), 지불 통합 시스템(412), 가입 시스템(414), 및/또는 토큰 브릿징 시스템(416)을 포함할 수 있다.
실시예들에서, 토큰 이전 시스템(402)은 토큰 소유자의 계정으로부터 상이한 사용자의 계정으로의 토큰의 이전을 용이화한다. 실시예들에서, 토큰 이전 시스템(402)은 토큰이 이전될 수 있는 조건을 정의하는 스마트 계약을 포함할 수 있다. 이들 실시예들 중 일부에서, 스마트 계약은 토큰에 상주하여, 스마트 계약이 노드 컴퓨팅 디바이스에서 및/또는 디지털 지갑으로부터 실행될 수 있게 할 수 있다. 이들 실시예들 중 일부에서, 스마트 계약은 API 시스템(108)에 의해 노출되는 스마트 계약 API를 통해 토큰 이전 시스템(402)과 인터페이스할 수 있다.
실시예들에서, 토큰 이전 시스템(402)은 계정으로의 토큰 이전을 요청하는 이전 요청을 수신한다. 이전 요청은 토큰 보유자의 계정 또는 토큰의 의도된 수신자의 계정으로부터 수신될 수 있다. 실시예들에서, 이전 요청은 토큰이 이전될 계정의 공개 주소를 포함할 수 있고, 이전될 토큰을 더 포함하거나 표시할 수 있다. 예를 들어, 이전 요청은 토큰의 사본 또는 토큰을 고유하게 식별하는 값(예를 들어, 영숫자 문자열)을 포함할 수 있다. 일부 실시예에서, 이전 요청은 토큰에 디지털적으로 서명한 엔티티의 공개 키를 포함한다. 일부 실시예에서, 이전 요청은 토큰 이전을 요청하고 있는 토큰 소유자의 공개 주소를 포함할 수 있다.
토큰 보유자는 토큰 보유자의 디지털 지갑으로부터의 토큰의 이전을 개시할 수 있다. 일부 실시예에서, 토큰의 이전은 플랫폼(100)을 통해 수행될 수 있다. 이들 실시예들에서, 토큰 소유자는 (예를 들어, 디지털 지갑의 GUI를 통해) 토큰 이전 시스템(402)에 이전 요청을 전송할 것을 디지털 지갑에 지시함으로써 토큰의 이전을 개시할 수 있다. 이들 실시예들에서, 토큰 이전 시스템(402)은 이전 요청을 수신할 수 있고 토큰이 유효한 토큰인지, 및 소유자 및/또는 수신자의 공개 주소가 유효한지를 결정할 수 있다. 토큰이 유효하고 소유자 및/또는 수신자의 공개 주소가 유효한 경우, 토큰 이전 시스템(402)은 의도된 수신자와 연관된 사용자 디바이스 및/또는 계정에 토큰의 사본을 전송할 수 있다. 일단 수신자에 의해 수락되고 나면, 토큰 이전 시스템(402)은, 분산형 원장이 수신자가 토큰의 현재 소유자임을 표시하게끔, 분산형 원장이 토큰의 소유권 변경을 표시하도록 분산형 원장을 업데이트할 것을 원장 관리 시스템(104)에 지시할 수 있다.
이제 도 7a를 참조하면, 지갑(700) 디스플레이의 예시가 도시되어 있다. 지갑(700)의 디스플레이는, 토큰화된 토큰들 702a-702n(일반적으로 702), 대체불가능한 토큰들 704a-704n(일반적으로 704), 및 대체가능한 토큰들 706a-706n(일반적으로 706) 등의 복수의 토큰을 포함한다. 볼 수 있는 바와 같이, 실시예들에서, 토큰들은 토큰 유형별로 그룹화된다. 토큰화된 토큰들(702)은, 유형, 및 실시예들에서, 개개의 토큰화된 토큰(702) 내에 포함된 특정한 콘텐츠(705)의 양을 전달하는 디스플레이된 표식(703)을 포함할 수 있다. 예를 들어, 플랫폼(100) 내의 사용자의 Bitcoin은 대체가능한 토큰(706a) 잔액과 하나 이상의 토큰화된 토큰(702a) 사이에서 분할될 수 있다. 더욱이, 대체가능한 Bitcoin(706a)은 사용자의 대체가능한 비트코인(706a)의 통합된 잔액일 수 있거나, 별개의 잔액(예를 들어, 단일 거래에서 플랫폼(100) 내로 이전된 비트코인의 양과 동일한 잔액)일 수 있다.
대체불가능한 토큰들(704)은 토큰에 관련된 적절한 정보를 전달하기 위한 디스플레이 표식을 포함할 수 있다. 예를 들어, 복수의 구매가능한 스킨(704a, 704b) 및 고용을 위한 일(704)이 함께 그룹화될 수 있으며, 각각은 상품의 이미지 등의 표식을 디스플레이할 수 있다. 대체가능한 토큰들(706a-706n)은 대체가능한 상품들에 대응하는 토큰들이다. 예를 들어, 대체가능한 토큰들(706a-706n)은, 통화, 암호화폐, 상품 등을 포함할 수 있다.
실시예들에서, 디지털 지갑은 토큰을 사용자 디바이스(190) 또는 계정(예를 들어, 이메일 계정, 제3자 메시징 앱의 계정)에 직접 전송하도록 구성되며, 이에 의해 토큰의 수신자는 토큰을 수락할 수 있다. 이들 실시예들 중 일부에서, 수신자의 디지털 지갑은, 토큰의 사본을 의도된 수신자에게 이전하는 것 외에도, 수신자에게 토큰을 이전하라는 요청을 나타내는 이전 요청을 토큰 이전 시스템(402)에 전송할 수 있다. 이들 실시예들에서, 토큰 이전 시스템(402)은 토큰이 유효한 토큰인지, 및 소유자 및/또는 수신자의 공개 주소가 유효한지를 결정할 수 있다. 토큰이 유효하고 소유자 및/또는 수신자의 공개 주소가 유효한 경우, 토큰 이전 시스템(402)은 수신자가 수신자의 개개의 디지털 지갑 내로 토큰을 수락하는 것을 허용할 수 있다. 일단 수신자에 의해 수락되고 나면, 토큰 이전 시스템(402)은, 분산형 원장(310)이 수신자가 토큰의 현재 소유자임을 표시하게끔, 분산형 원장이 토큰의 소유권 변경을 표시하도록 분산형 원장을 업데이트할 것을 원장 관리 시스템(104)에 지시할 수 있다.
대안으로서, 일부 실시예에서, 토큰 소유자의 디지털 지갑은 토큰 이전 시스템(402)에 이전 요청을 전송하지 않는다. 이들 실시예들에서, 토큰 수신자의 사용자 디바이스(190)는 토큰 소유자가 토큰을 수락할 수 있는 메커니즘을 프리젠팅할 수 있다. 예를 들어, 사용자 디바이스(190)는 토큰을 수락하기 위한 링크를 프리젠팅할 수 있다. 의도된 수신자가 토큰을 수락하면, 사용자 디바이스(190)는 (예를 들어, 수신자의 디지털 지갑의 인스턴스를 통해) 토큰 이전 시스템(402)에 이전 요청을 전송할 수 있다. 이 시나리오에서, 토큰 이전 시스템(402)은, 토큰이 유효한 토큰인지, 및 소유자 및/또는 수신자의 공개 주소가 유효한지를 결정할 수 있다. 토큰이 유효하고 소유자 및/또는 수신자의 공개 주소가 유효한 경우, 토큰 이전 시스템(402)은, 분산형 원장이 수신자가 토큰의 현재 소유자임을 표시하게끔, 분산형 원장이 토큰의 소유권 변경을 표시하도록 분산형 원장을 업데이트할 것을 원장 관리 시스템(104)에 지시할 수 있다.
논의된 바와 같이, 이전 요청에 응답하여, 전송 요청, 토큰 이전 시스템(402)은 토큰이 유효한 토큰인지, 및 소유자 및/또는 수신자의 공개 주소가 유효한지를 결정할 수 있다. 실시예들에서, 토큰은 토큰과 연관된 공개 키를 이용하여 유효성확인될 수 있다. 예를 들어, 토큰 이전 시스템(402)은 토큰(또는 그 표시자) 및 이전 요청에 표시된 공개 키를 원장 관리 시스템(104)에 제공할 수 있다. 원장 관리 시스템(104)은 토큰 식별자가 분산형 원장에 저장되어 있는지를 결정할 수 있고, 만일 그렇다면, 이전 요청과 함께 제공된 공개 키가 토큰에 디지털적으로 서명하는데 이용된 공개 키인지를 확인할 수 있다. 실시예들에서, 토큰 이전 시스템(402)은 그 공개 주소를 이용하여 토큰을 이전하기를 원하는 수신자 및/또는 토큰 소유자의 신원을 유효성확인할 수 있다. 이들 실시예들 중 일부에서, 토큰 이전 시스템(402)은, 수신자의 공개 주소 및/또는 토큰 소유자의 공개 주소를 원장 관리 시스템(104)에 제공할 수 있으며, 원장 관리 시스템은 결국 개개의 공개 주소를 조회하여 공개 주소가 분산형 원장에 저장되어 있는지를 확인할 수 있다. 토큰이 유효하고 토큰 소유자 및/또는 수신자의 공개 주소가 유효하다는 결정에 응답하여, 토큰 이전 시스템(402)은 토큰의 이전을 허용할 수 있고 분산형 원장이 수신자가 토큰의 현재 소유자임을 나타내게끔 토큰의 소유권의 변경을 표시하도록 분산형 원장을 업데이트할 것을 원장 관리 시스템(104)에 지시할 수 있다.
실시예들에서, 상환 시스템(404)은 토큰의 소유자가 토큰을 상환하는 것을 허용한다. 상환 시스템(404)은 토큰을 상환하라는 요청(또는 "상환 요청")을 수신할 수 있다. 상환 요청은, 토큰 또는 토큰의 식별자(예를 들어, 영숫자 문자열)를 포함할 수 있고 토큰 상환을 시도하는 사용자의 공개 주소를 포함할 수 있다. 실시예들에서, 상환 요청은 토큰에 디지털적으로 서명하는데 이용된 공개 키를 더 포함할 수 있다. 상환 요청을 수신하는 것에 응답하여, 상환 시스템(404)은, 토큰, 토큰 상환을 시도하는 사용자의 공개 주소, 및 토큰을 디지털적으로 서명하는데 이용된 공개 키를 원장 관리 시스템(104)에 제공할 수 있다. 그 다음, 원장 관리 시스템(104)은 토큰/공개 주소 조합을 확인하거나 거부할 수 있다. 원장 관리 시스템(104)은, 토큰이 유효한 토큰이 아니고/아니거나 사용자가 목록에 있는 토큰의 소유자가 아닌 경우 조합을 거부할 수 있다. 원장 관리 시스템(104)은, 토큰이 유효한 것으로 간주되고 요청 사용자가 토큰의 소유자인 것으로 간주되는 경우 토큰/공개 주소 조합을 확인할 수 있다.
토큰/공개 주소 조합을 확인하는 것에 응답하여, 상환 시스템(206)은 상환된 토큰에 대응하는 가상 표현에 대응하는 워크플로우를 실행할 수 있다. 예를 들어, 일부 시나리오에서, 사용자는 디지털 아이템(예를 들어, 기프트 카드, mp3, 영화, 디지털 사진)에 대응하는 토큰을 상환하는 중일 수 있다. 이들 시나리오에서, 상환 시스템(404)은 디지털 아이템을 충족시키기 위한 워크플로우를 결정할 수 있다. 예를 들어, 상환 시스템(404)은 사용자에게 이메일 주소를 요청할 수 있거나 분산형 원장에서 사용자의 이메일 주소를 조회할 수 있다. 이 예에서, 상환 시스템(404)은 디지털 아이템을 사용자의 이메일 계정으로 다운로드하기 위한 링크를 이메일로 보낼 수 있거나 사용자의 이메일 계정으로 전송되는 이메일에 디지털 아이템의 사본을 첨부할 수 있다. 또 다른 시나리오에서, 사용자는 물리적 상품(예를 들어, 의류, 음식, 전자 제품 등) 또는 물리적 서비스(예를 들어, 가정부 서비스)에 대응하는 토큰을 상환하는 중일 수 있다. 물리적 상품의 경우, 상환 시스템(404)은 물리적 아이템을 충족시키기 위한 워크플로우를 결정할 수 있다. 예를 들어, 상환 시스템(404)은 사용자가 사용자의 배송 정보를 입력하는 것을 허용하는 GUI를 사용자에게 프리젠팅할 수 있다. 대안으로서, 상환 시스템(404)은 예를 들어 분산형 원장 또는 사용자 데이터베이스로부터 사용자의 배송 정보를 조회할 수 있다. 그 다음, 상환 시스템(404)은 물리적 상품의 배송을 개시할 수 있다. 예를 들어, 상환 시스템(404)(또는 물류 시스템)은, 배송 정보를 나타내는 상품의 배송을 취급하는 창고에 배송 요청을 전송할 수 있다. 전술된 내용은 토큰이 어떻게 상환될 수 있는지에 대한 예이다.
상환 시스템(404)은 토큰의 상환을 취급하기 위해 추가적 또는 대안적인 워크플로우를 실행할 수 있다. 예를 들어, 일부 시나리오에서 토큰의 초기 구매자는 거래를 충족시키는데 필요한 아이템의 소정의 파라미터를 명시하지 않았을 수 있다. 예를 들어, 아이템이 의류인 경우, 초기 구매자가 아이템의 크기 및/또는 색상을 명시하지 않았을 수 있다. 또 다른 예에서, 아이템이 음식 아이템인 경우, 초기 구매자는, 부가 주문, 토핑, 음료 선택 등을 명시하지 않았을 수 있다. 아이템이 항공권 또는 호텔 예약 등의 경험인 경우, 초기 구매자가 여행 날짜를 명시하지 않았을 수 있다. 이들 시나리오에서, 상환 시스템(404)은 토큰의 상환자가 필요한 파라미터를 명시하는 것을 허용하는 GUI를 프리젠팅할 수 있어서, 거래가 명시될 수 있게 한다. 파라미터를 수신하는 것에 응답하여, 상환 시스템(404)은 이들 파라미터를 가상 표현의 인스턴스 또는 거래(예를 들어, 배달 주문, 구매 주문 등)의 충족에 대응하는 임의의 다른 적절한 데이터 구조에 부여할 수 있어서, 거래가 충족될 수 있게 한다.
실시예들에서, 거래 시스템(106)은 디지털 지갑을 지원하는 디지털 지갑 시스템(408)을 포함한다. 디지털 지갑은, 디지털 지갑과 연관된 계정의 소유자가 소유한 토큰일 수 있으며, 사용자가 토큰을 보거나, 상환하거나, 매매하거나, 이전하거나, 선물하거나, 예치하거나, 인출하거나, 또는 기타의 방식으로 거래하는 것을 허용하는 그래픽 사용자 인터페이스를 제공할 수 있다. 실시예들에서, 디지털 지갑 시스템(408)은 즉각적 판매 능력을 제공하며, 여기서, 사용자는 아이템에 대응하는 토큰을 판매하는 것에 동의할 수 있다. 예를 들어, 즉석 판매 능력은 사용자는 최저 가격의 90% 비율로 아이템을 판매하는 것을 허용할 수 있다. 일부 실시예에서, 다른 사용자는, 사용자의 프라이버시 설정에 따라, 계정 소유자가 소유한 가상 표현 인스턴스들의 일부 또는 전부를 볼 수 있다. 사용자는 개개의 가상 표현 또는 모든 가상 표현을 은닉하거나 비공개로 하는 것을 선택할 수 있다.
일부 실시예에서, 플랫폼(100) 및/또는 사용자의 디지털 지갑은 또 다른 사람에게 이전될 때 토큰과 연관될 수 있는 시각적 표식을 제공할 수 있다. 예를 들어, 토큰과 연관될 수 있는 시각적 표식은, 이모지, 이미지, gif, 비디오 등을 포함할 수 있다. 이들 시각적 표식은, 또 다른 사용자에게 토큰을 전송할 때 사용자에 의해 이용될 수 있다. 예를 들어, 토큰이 꽃다발에 대응하고 시각적 표식이 꽃의 이모지인 경우, 사용자는 꽃 이모지를 이용하여 메시지에서 토큰을 보낼 수 있다. 이 예에서, 사용자는 (예를 들어, 사용자 디바이스(190) 상의 네이티브 애플리케이션을 통해) 디지털 지갑의 토큰에 액세스할 수 있고 토큰을 수신자에게 보내는 옵션을 선택할 수 있다. 사용자는 수신자를 식별할 수 있고(예를 들어, 연락처 목록에서 선택) 메시지를 타이핑할 기회가 제공될 수 있다. 클라이언트 애플리케이션(예를 들어, 디지털 지갑)은 꽃 이모지를 포함하는 키보드를 프리젠팅할 수 있고, 이에 의해 꽃 이모지는 토큰을 나타낸다. 꽃 이모지의 사용자 선택 및 후속된 토큰의 "전송"에 응답하여, 디지털 지갑 애플리케이션은 토큰/꽃 이모지를 포함하는 메시지의 전송을 개시할 수 있다. 이 예에서, 디지털 지갑은 또한, 이전하려는 사용자가 토큰 이전을 요청했음을 나타내는 이전 요청을 토큰 이전 시스템(402)에 전송할 수 있다. 이전 요청은 토큰의 사본과 이전하려는 사용자의 공개 주소를 포함할 수 있다. 실시예들에서, 이전 요청은, 토큰의 의도된 수신자의 공개 주소 또는 기타의 표시자(예를 들어, 이메일 주소, 전화 번호, 사용자 ID 등)를 더 포함할 수 있다.
실시예들에서, 거래 시스템(106)은 사용자가 환전하지 않고 하나 이상의 자산을 매매할 수 있는 신속 매매 시스템(410)을 포함한다. 이들 실시예들에서, 신속 매매 시스템(410)은 사용자가 안전하게 토큰을 매매할 수 있는 메커니즘을 제공하며, 여기서 각각의 토큰은 상이한 아이템을 나타낸다. 한 예시적인 동작에서, 제1 사용자는 대가로 하나 이상의 토큰을 하나 이상의 토큰으로 교환하기 위해 제2 사용자에게 스마트 계약에서 매매 제안을 할 수 있다. 제2 사용자는 요청된 가상 자산을 이전함으로써 수락할 수 있다. 그러면, 스마트 계약은 거래를 완료된 것으로서 마킹한다. 실시예들에서, 신속 매매 시스템(410)은, 사용자가 토큰의 인벤토리를 보거나, 제안을 생성하거나, 제안을 수락하거나, 및/또는 제안을 취소하는 것을 허용하는 GUI를 제공할 수 있다.
실시예들에서, 거래 시스템(106)은 지불 통합 시스템(412)을 포함한다. 지불 통합 시스템(412)은 사용자가 아이템에 대응하는 토큰을 구매하는 것을 허용한다. 지불 통합 시스템(412)은, 신용 카드, 상이한 형태들의 통화, 및/또는 암호화폐를 수락할 수 있다.
일부 실시예에서, 거래 시스템(106)은 가입 시스템(414)을 포함한다. 이들 실시예들에서, 사용자는 서비스에 가입하여 가입 시스템(414)을 통해 정기적으로 소비하는 아이템들을 수신할 수 있다.
실시예들에서, 거래 시스템(106)은 원장 브릿징 시스템(416)을 포함한다. 원장 브릿징 시스템(416)은 제1 탈집중형 원장 시스템(또는, 전통적인 은행을 포함한, 임의의 통화 보유자)에서 원래의 가상 자산을 보호하거나 잠금처리하고 제2 탈집중형 원장 시스템에서 거래가능한 사본을 생성하는 프레임워크를 제공한다. 이러한 방식으로, 사용자는 토큰화 플랫폼(100)의 자산의 계정에 상이한 통화 및 상이한 이전 수단으로 자금을 조달할 수 있으며, 그 후 상이한 통화를 이용하여 거래(예를 들어, 매매, 선물 또는 상환)에 참여할 수 있다. 일부 실시예에서, 탈집중형 원장 브릿징 시스템(416)은 탈집중형 원장 시스템(예를 들어, 플랫폼(100)의 분산형 원장(310)과는 분리되고 떨어져 있는 원장 시스템)에 걸쳐 에스크로 기능을 제공한다. 실시예들에서, 원장 브릿징 시스템(416) 또는 디지털 지갑은, 토큰 예치 GUI 및/또는 토큰 인출 GUI를 제공할 수 있다.
실시예들에서, 원장 브릿징 시스템(416)은 사용자가 하나 이상의 외부 통화로 자신의 계정에 자금을 조달하는 것을 허용한다. 예를 들어, 사용자는, Bitcoin, Ethereum 코인, 기타의 적절한 암호화폐, 및/또는 전통적인 통화(예를 들어, 미국 달러, 영국 파운드, 유로, 중국 위안, 일본 엔, 및/또는 기타 등등)로 계정에 자금을 조달할 수 있다. 암호화폐의 경우, 사용자는, 예를 들어 사용자의 암호화폐를 저장하는 비제휴 디지털 지갑을 이용하여, 외부 계정으로부터의 암호화폐 이전을 용이화할 수 있다. 전통적인 통화의 경우, 사용자는, 예를 들어, 신용 카드, 직접 송금, ACH 송금 등을 이용하여 자신의 계정으로 자금을 이전할 수 있다. 일부 실시예에서, 사용자가 토큰화 플랫폼(110)을 이용하여 자금(암호화폐 또는 전통적인 통화)을 계정에 이전할 때("자금 거래"라고 지칭될 수 있음), 원장 브릿징 시스템(416)은 자금 거래에 대응하는 기록을 생성할 수 있고 자금 거래를 반영하도록 분산형 원장을 업데이트할 수 있는 원장 관리 시스템(104)에 그 기록을 제공할 수 있다. 기록은, 자금을 이전받은 계정, 자금을 이전한 계정, 이전된 금액, 이전 날짜 및 시간, 및/또는 기타 임의의 적절한 데이터를 나타낼 수 있다.
일단 계정에 자금이 조달되고 나면, 사용자는 이전된 자금을 이용하여 토큰화 플랫폼(100) 상의 임의의 거래에 참여할 수 있다. 일부 실시예에서, 이전된 자금의 적어도 서브세트는 토큰화 플랫폼(100) 및/또는 이에 대응하는 분산형 원장(312)에 의해 지원되는 프로토콜을 준수하는 방식으로 토큰화된다. 실시예들에서, 원장 브릿징 시스템(416)은, 사용자에 대응하는 요청에 응답하여 하나 이상의 암호화 코인(예를 들어, 비트코인), 암호화 코인의 임의의 부분, 또는 임의의 양의 통화를 토큰화할 수 있다. 자금 토큰화 요청은 명시적 요청 또는 묵시적 요청일 수 있다. 명시적 요청이란 사용자가 소정 금액의 통화의 토큰화를 구체적으로 요청하는 경우를 말할 수 있다. 묵시적 요청이란, 사용자가, 사용자의 계정에 이전된 자금을, 이들 자금의 적어도 일부가 거래를 용이화하기 위해 토큰화될 필요가 있도록(예를 들어, 사용자 아이템을 구매하고 사용자 계정의 이전된 자금 중 일부를 이용하여 아이템에 대한 지불을 선택) 관여시키는 토큰화 플랫폼(100) 상의 거래에 참여하는 경우를 말할 수 있다. 요청이 묵시적이든 명시적이든 관계없이, 원장 브릿징 시스템(416)은 소정 금액의 통화를 토큰화할 수 있다.
이들 실시예들 중 일부에서, 원장 브릿징 시스템(416)은 소정 금액의 통화를 "포장"하는 토큰화된 토큰을 주조(minting)함으로써 명시된 금액의 통화를 토큰화한다. 토큰화된 토큰이란, 통화의 유형 및 코인에 의해 표현되는 통화의 양(예를 들어, 비트코인, Ethereum, 달러, 파운드 등의 양)을 정의하는 속성을 가진 대체불가능한 토큰을 말할 수 있다. 이들 실시예들 중 일부에서, 토큰화된 토큰이란, 토큰화된 토큰 및/또는 기타의 디지털 아이템(들) 내에 인클로징된 디지털 통화 잔고(들)를 나타내는 대체가능한 및/또는 대체불가능한 토큰 세트를 갖는 것에 추가하여 이러한 토큰의 특성을 정의하는 속성 세트를 갖는 대체불가능한 토큰을 말할 수 있다. 또한, 토큰화된 토큰은, 상환, 이전 및 기타의 토큰화된 토큰 라이프사이클 메커니즘을 관할하는 비즈니스 규칙을 포함할 수 있다. 일부 실시예에서, 원장 브릿징 시스템(416)은 토큰 생성 시스템(302)에 의한 새로운 토큰의 생성을 요청함으로써 새로운 토큰을 주조한다. 원장 브릿징 시스템(416)은, 통화의 유형, 통화의 금액, 및 소유권 데이터(예를 들어, 새로운 토큰화된 토큰이 속할 계정)를 토큰 생성 시스템(302)에 제공할 수 있다. 응답하여, 토큰 생성 시스템(302)은 예를 들어 전술된 방식으로 토큰화된 토큰을 생성한다. 이러한 방식으로, 토큰 생성 시스템(302)은 통화를 "아이템"으로서 취급한다. 이러한 방식으로, 토큰화된 토큰은, 교환되거나(예를 들어, 다른 토큰화된 토큰들 또는 토큰화된 아이템들에 대해), 선물되고/되거나 상환될 수 있다. 일부 실시예에서, 토큰화된 토큰이 참여할 수 있는 거래의 유형은 제약될 수 있다. 예를 들어, 불안정한 통화를 나타내는 토큰화된 토큰은 교환이 제약될 수 있지만, 상환되거나 선물될 수는 있다.
실시예들에서, 원장 브릿징 시스템(416)은 또한, 주조 프로세스의 일부로서 토큰화된 토큰에 대응하는 시각적 표식을 생성한다. 일부 실시예에서, 시각적 표식은 디지털 스티커(또는 "스티커")이다. 예를 들어, 일부 실시예에서, 스티커는 금액 및 통화를 나타내는 심볼을 묘사할 수 있다(예를 들어, 5 달러의 토큰화를 나타내는 스티커는 "$5"를 묘사할 수 있거나, 비트코인의 1/10을 나타내는 스티커는 "
Figure pct00001
"를 묘사할 수 있다). 이러한 방식으로, 스티커는 토큰화된 토큰 소유자의 지갑에 디스플레이될 수 있다. 논의된 바와 같이, 시각적 표식은 사용자가 소유한 토큰화된 토큰을 사용자에게 전달하는데 이용될 수 있다. 추가로, 일부 실시예에서, 본 개시내용의 다른 곳에서 설명된 바와 같이, 시각적 표식은, (예를 들어, 문자 메시지, 메시징 애플리케이션, 이메일 등을 통해) 토큰화된 토큰을 다른 당사자에게 이전하는데 이용될 수 있다.
일부 실시예에서, 원장 브릿징 시스템(416)은 토큰화된 토큰에 대응하는 스마트 계약을 주조 프로세스의 일부로서 인스턴스화(또는 인스턴스화를 요청)할 수 있다. 이들 실시예들에서, 스마트 계약은, 소유권 이전 및/또는 상환 로직 등의 토큰화된 토큰 라이프사이클 메커니즘을 관할하는 하나 이상의 기본 기능을 정의할 수 있다. 기본 기능은, 토큰화된 토큰의 소유권을 변경하는 능력, 토큰화된 토큰이 이용될 수 있는 거래의 유형(예를 들어, 구매, 선물, 교환, 현금을 위한 상환 등)을 포함할 수 있다. 새로운 토큰화된 토큰이 주조되면, 원장 브릿징 시스템(416)은, 새로 주조된 토큰화된 토큰에 대응하는 스마트 계약의 인스턴스를 인스턴스화할 수 있다. 스마트 계약의 인스턴스는, 토큰화된 토큰이 이전(예를 들어, 교환, 선물, 또는 상환)에 수반될 때마다 실행될 수 있다. 예를 들어, 토큰화된 토큰의 소유자가 토큰화된 토큰의 이전을 요청할 때마다, 스마트 계약의 인스턴스는 요청에 의해 관여될 수 있으며, 스마트 계약의 인스턴스는 요청의 내용 및 스마트 계약에 따라 이전을 불허하거나 용이화할 수 있다.
일단 토큰화된 토큰이 주조되고 나면, 토큰화된 토큰에 의해 표현되는 자금은 원장 브릿징 시스템(416)에 의해 "에스크로잉"될 수 있다. 이러한 방식으로, 사용자는 토큰화된 토큰이 상환될 때까지 자신의 계정으로부터 자금을 제거할 수 없다. 일부 실시예에서, 원장 브릿징 시스템(416)은 토큰화된 토큰에 대응하는 자금을 사용자의 계정으로부터 지정된 에스크로 계정으로 이전할 수 있다. 대안으로서, 원장 브릿징 시스템(416)은 토큰화된 토큰이 상환될 때까지 자금이 사용자에 의해 이전되지 않을 수 있도록 토큰화된 토큰에 대응하는 자금을 동결시킬 수 있다. 일단 토큰화된 토큰이 상환되고 나면, 토큰화된 토큰에 의해 표현되는 자금은 에스크로로부터 해제되어, 상환 사용자의 계정에 예치될 수 있으며, 토큰화된 토큰은 파괴될 수 있다("무효화"라고도 함).
실시예들에서, 원장 브릿징 시스템(416)은 분산형 원장을 업데이트하거나 업데이트를 개시한다. 분산형 원장은 다수의 상이한 사건시에 업데이트될 수 있다. 논의된 바와 같이, 실시예들에서, 분산형 원장은 사용자가 처음에 계정에 자금을 조달할 때 업데이트될 수 있다. 실시예들에서, 원장 브릿징 시스템(416)은 새로운 토큰화된 토큰이 주조될 때 분산형 원장을 업데이트(또는 업데이트 개시)한다. 이들 실시예들에서, 분산형 원장은 새로운 토큰화된 토큰의 존재 및 토큰의 소유권을 반영하도록 업데이트된다. 실시예들에서, 원장 브릿징 시스템(416)은 토큰화된 토큰에 대응하는 스마트 계약의 인스턴스로 분산형 원장을 업데이트(또는 업데이트 개시)한다. 실시예들에서, 원장 브릿징 시스템(416)은 토큰화된 토큰이 이전될 때마다 분산형 원장을 업데이트(또는 업데이트 개시)할 수 있다. 이들 실시예들에서, 분산형 원장은 토큰화된 토큰의 새로운 소유자를 반영하도록 업데이트될 수 있다. 실시예들에서, 원장 브릿징 시스템(416)은 토큰화된 토큰이 상환되고 후속해서 폐기될 때 분산형 원장을 업데이트(또는 업데이트하는 것을 개시)할 수 있다. 이들 실시예들에서, 분산형 원장은 토큰화된 토큰이 더 이상 유효하지 않거나, 토큰을 상환한 계정, 및/또는 토큰이 상환된 때를 반영하도록 업데이트될 수 있다.
도 5는 본 개시내용의 일부 실시예에 따른 지능 및 자동화 시스템(110)을 나타낸다. 실시예들에서, 플랫폼은 지능 및 자동화 시스템(110)을 포함한다. 지능 및 자동화 시스템(110)은, 머신 학습 시스템(502), 인공 지능 시스템(504), 추천 엔진(506), 서비스 매칭 엔진(508), 광고 시스템(508), 및/또는 통보 시스템(510)을 포함할 수 있다.
실시예들에서, 머신 학습 시스템(502)은 훈련 데이터에 기초하여 머신 학습 모델을 훈련시킬 수 있다. 머신 학습의 예는, 다양한 유형의 신경망, 회귀 기반의 모델, 은닉된 Markov 모델, 점수 모델 등을 포함할 수 있다. 머신 학습 시스템(502)은, 감독, 준-감독, 또는 무감독 방식으로 모델을 훈련시킬 수 있다. 훈련은, 훈련 목적으로 수집되거나 생성될 수 있는 훈련 데이터를 이용하여 이루어질 수 있다. 머신 학습 모델은 모델 데이터 저장소에 저장될 수 있다.
한 예에서, 머신 학습 시스템(502)은 선물 예측 모델을 훈련시키도록 구성될 수 있다. 선물 예측 모델(또는 예측 모델)은, 수신자 속성(예를 들어, 의도된 수신자에 관련된 프로필) 및/또는 선물로서 제공될 수 있는 하나 이상의 아이템의 아이템 속성을 수신하고 특정한 소비자에게 선물 토큰을 보내는 것과 관련된 하나 이상의 예측을 출력하는 모델일 수 있다. 예측의 예는, 그 사용자에게 선물을 보낼지, 사용자가 중시하는 선물 등이 될 수 있다. 실시예들에서, 머신 학습 시스템(502)은 훈련 데이터에 기초하여 모델을 훈련시킨다. 실시예들에서, 머신 학습 시스템(502)은, 사용자 데이터(예를 들어, 거래 내역, 선호사항, 희망사항 목록, 가상 자산 등), 가상 자산 데이터(예를 들어, 가격, 색상, 패브릭 등), 및 결과(예를 들어, 상환, 교환 등)를 포함하는 벡터를 수신할 수 있다. 각각의 벡터는, 개개의 결과와 개개의 사용자 및 개개의 아이템의 속성에 대응할 수 있다. 머신 학습 시스템(502)은 벡터를 취하고 그에 기초하여 예측 모델을 생성한다.
실시예들에서, 머신 학습 시스템(502)은 거래에 참여하는 사용자의 피처, 거래의 피처(예를 들어, 거래의 유형(예를 들어, 구매, 대출, 판매 등), 거래의 규모(예를 들어, 달러 금액) 등), 및 거래의 성공 여부를 나타내는 거래 결과(예를 들어, 구매자가 구매 후 아이템에 대해 지불했는지, 차용자가 대출을 갚았는지 또는 대출에 관해 채무불이행인지, 구매 아이템이 배달되고 충분한 상태인지 등)를 나타내는 훈련 데이터 세트를 이용하여 위험 점수 모델을 훈련시킨다. 훈련 데이터 세트는 플랫폼에 의해 용이화되고/되거나 전문가에 의해 생성된 거래에 기초할 수 있다.
실시예들에서, 머신 학습 시스템(502)은 모델 데이터 저장소에 예측 모델을 저장할 수 있다. 실시예들에서, 머신 학습 시스템(502)은 또한, 캡처된 결과에 기초하여 모델을 업데이트하도록 구성될 수 있고, 이것은 "강화 학습"이라고도 불린다. 실시예들에서, 머신 학습 시스템은, 예측(예를 들어, 아이템 속성 및 사용자 속성) 및 처리와 관련된 결과(예를 들어, 아이템의 상환, 아이템의 교환, 아이템의 환불)로 이어지는 한 세트의 상황을 수신할 수 있고, 피드백에 따라 모델을 업데이트할 수 있다. 여기서 사용될 때, 머신 학습 시스템에 의해 활용될 수 있는 머신 학습 기술은, 결정 트리, K-최근접 이웃, 선형 회귀, K-평균 클러스터링, 심층 학습 신경망, 랜덤 포레스트, 로지스틱 회귀,
Figure pct00002
, 학습 벡터 양자화, 지원 벡터 머신, 선형 판별 분석, 부스팅, 주성분 분석, 및 하이브리드 접근법을 포함하지만, 이것으로 제한되는 것은 아니다.
실시예들에서, 인공 지능(AI) 시스템(504)은 머신 학습된 모델을 활용하여 사용자 데이터 및 자산 데이터에 관하여 구매, 선물, 또는 기타의 전자 상거래 결과에 관한 예측 또는 분류를 수행한다. 예측의 예는, 사용자가 아이템을 구매할지, 사용자가 선물 아이템을 교환할지, 배달 시기 및 배달 위치 등의 상환 옵션 등을 포함한다. 예를 들어, AI 시스템(504)은 선물 예측 모델을 활용하여 특정한 아이템의 수신자가 선물을 좋아할지, 선물을 반환할지, 또는 선물을 교환할지에 대한 예측을 할 수 있다.
실시예들에서, 추천 시스템(506)은 아이템에 관한 추천을 사용자에게 제공하도록 구성될 수 있다. 추천 시스템(506)은 사용자의 속성에 기초하여 AI 시스템(504)에게 추천을 요청할 수 있다. AI 시스템(504)은 추천 세트를 출력할 수 있고 추천 시스템(506)은 추천을 사용자 또는 다른 당사자에게 제공할 수 있다. 예를 들어, 추천 시스템(506)은 사용자의 구매 내역에 기초하여 구매할 아이템의 추천을 사용자에게 제공할 수 있다.
실시예들에서, 광고 시스템(508)은 사용자에게 디스플레이할 광고를 결정하도록 구성되며, 여기서 광고는 플랫폼 상의 거래를 위해 제공되는 아이템과 관련된다. 실시예들에서, 광고 시스템(508)은 사용자에게 할인, 프로모션 등을 프리젠팅할 수 있다.
실시예들에서, 서비스 매칭 시스템(510)은, 사용자가 선택한 서비스를 위해 소비자를 서비스 제공자와 매칭하도록 구성된다. 이들 실시예에서, 사용자는 서비스를 찾고 있을 수 있고, 서비스 매칭 시스템(510)은 그 서비스를 제공하기에 가장 적합한 서비스 제공자를 식별할 수 있다. 예를 들어, 서비스 매칭 시스템(510)은, 가격, 가용성, 위치 등에 기초하여 서비스 추구자 및 서비스 제공자를 매칭할 수 있다.
도 6은 본 개시내용의 일부 실시예에 따른 지능 및 자동화 시스템(110)을 나타낸다. 실시예들에서, 분석 및 보고 시스템(112)은 전자 상거래 플랫폼(100)의 다양한 양태에 관한 분석을 캡처 및 보고하도록 구성된다. 실시예들에서, 분석 및 보고 시스템(112)은, 분석 시스템(602), 보고 시스템(604), 및/또는 규제 자산 시스템(606)을 포함할 수 있다. 실시예들에서, 분석 및 보고 시스템(112)은 사용자가 분석 및 보고 시스템(112)에 액세스하는 것을 허용하는 분석 인터페이스를 제공할 수 있다.
실시예들에서, 분석 시스템(602)은, 소비자 데이터, 아이템 데이터, 판매자, 제조업체 또는 제공자 데이터; 사용자 행동(예를 들어, 구매 행동, 원격측정 등), 및 거래 이벤트(예를 들어, 아이템 구매 시기, 아이템 구매 방법, 아이템 이전 방법 등)을 포함한 그러나 이것으로 제한되지 않은 데이터를 추적하고 분석할 수 있다.
실시예들에서, 보고 시스템(604)은 분석 시스템(602)에 의해 획득된 분석을 하나 이상의 당사자에게 보고한다. 이해 당사자는 보고 시스템(604)에 액세스하고/하거나 분석 보고를 수신하기 위해 가입할 수 있다. 보고 시스템(604)은 수집된 분석에 기초하여 보고를 생성하고 보고를 이해 당사자에게 제공하도록 구성될 수 있다. 실시예들에서, 규제 GUI는 규제자가 플랫폼(100)에 액세스하는 것을 허용할 수 있다. 예를 들어, 규제자는 플랫폼에 액세스하여 3D 인쇄된 총기 등의 규제 아이템을 추적하고 모니터링할 수 있다.
실시예들에서, 분석 및 보고 시스템(112)은 규제 자산 시스템(606)을 포함한다. 실시예들에서, 규제 자산 시스템(606)은 규제 아이템을 관리하도록 구성된다. 예를 들어, 규제 자산 시스템(606)은, 무기 또는 총기, 의약품, 알코올, 담배 제품, 식품, 이벤트/장소 입장, 항공권 등에 대한 액세스를 관리할 수 있다. 실시예들에서, 규제 자산 시스템(606)은 규제 아이템에 관한 거래를 추적하고 모니터링할 수 있으며, 거래 및 대응하는 워크플로우에 기초하여 소정의 규제 기관에 통보할 수 있다. 비제한적인 예에서, 토큰을 이용하여 3D 인쇄된 총기를 추적할 수 있으며, 여기서 구매된 아이템은 총기를 인쇄하는데 이용되는 모델이 될 것이다.
다시 도 1을 참조하면, 실시예들에서, 플랫폼(100)은 가상 세계 환경 내에서 토큰화된 물리적 세계 아이템을 표현하기 위한 가상 세계 현장감 시스템(114)을 포함한다. 일부 실시예에서, 가상 세계 환경은 가상 세계 아바타를 묘사할 수 있다. 가상 세계 아바타는 사용자(예를 들어, 잠재적 구매자)를 나타낼 수 있으며 가상 세계 환경에서 가상 아이템과 상호작용할 수 있다. 사용자는 가상 세계 상점에서 가상 세계 아바타를 제어하여 "쇼핑"할 수 있다. 예를 들어, 가상 세계 아바타는 가상 세계 탈의실에서 토큰화된 물리적 세계 모자의 가상 표현을 시도할 수 있다. 일부 실시예에서, 가상 세계 현장감 시스템은 가상 세계 환경을 디스플레이하기 위한 프레임워크를 제공하는 가상 현실 시스템을 포함할 수 있다. 실시예들에서, 가상 세계 현장감 시스템은 또한, 사용자가 소유하거나, 사용자가 보관하거나, 사용자가 원하는 아이템 등을 포함한 그러나 이것으로 제한되지 않는 사용자에 관련된 아이템을 디스플레이하는 가상 자산 디스플레이 시스템을 포함할 수 있다. 이들 아이템은 다른 사용자에게 공개적으로 디스플레이되거나 다른 사용자에게 개별적으로 또는 집합적으로 은닉될 수 있다. 일부 실시예에서, 가상 자산 디스플레이 시스템은, 사용자가 소유하거나 소지한 아이템을 결정하기 위해 사용자가 소유한 토큰 세트를 결정할 수 있다.
실시예들에서, 가상 세계 현장감 시스템(114)은, 콘텐츠 플랫폼에 대한 가상 자산에 관련된 콘텐츠의 공유를 허용하는 콘텐츠 공유 시스템을 포함할 수 있다. 콘텐츠 공유 시스템은, 사용자가 소유하거나 보관하고 있거나 사용자가 원하는 가상 자산에 관련된 콘텐츠를 사용자들이 공유하는 것을 가능케한다. 사용자는, 가상 자산, 또는 구매, 대여, 임차, 매매 등의 요청에 관한 추가 정보를 획득할 수 있다. 공유 콘텐츠는 가상 세계 현장감 시스템으로부터의 데이터를 포함할 수 있다. 예를 들어, 사용자는, 가상 피자 가게에서 가상 피자를 먹고 있는 사용자의 연관된 가상 세계 아바타의 비디오를 공유할 수 있다.
이제 도 8을 참조하면, 토큰화 플랫폼(100)은 다수의 상이한 애플리케이션을 지원하고/하거나 다수의 상이한 서비스를 제공할 수 있다. 예를 들어, 플랫폼(100)은, 담보 대출 애플리케이션, 인증 서비스, "미스터리 박스" 애플리케이션, 카지노 게임 서비스, 및 비디오 게임 스트리밍 서비스를 지원할 수 있다.
실시예들에서, 플랫폼(100)은 담보 관리 시스템(802)을 포함한다. 실시예들에서, 담보 관리 시스템(802)은 차용자가 담보를 제공하고 대출을 요청하는 것을 허용한다. 이들 실시예들 중 일부에서, 돈을 빌리려는 사용자는, 담보 아이템(예를 들어, 수집가능한 아이템, 보석류, 총기, 귀금속 등)을 플랫폼(100)에 의해 제휴되거나 기타의 방식으로 지원되는 시설로 가져갈 수 있다. 그 시설에서, 시설의 직원은 담보 관리 시스템(802)에 의해 제공되는 인터페이스를 이용하여 담보 아이템을 인벤토리화할 수 있다. 담보 아이템을 인벤토리화하는 것은, 담보 아이템에 대한 아이템 식별자 요청, 담보 아이템의 아이템 식별자를 사용자(즉, 담보 아이템의 소유자)의 계정과 연관시키는 것, 담보 아이템의 고해상도 사진 촬영, 스케일을 이용하여 담보 아이템에 가중치를 부여, 담보 아이템에 대한 설명 입력, 담보 아이템에 대한 평가 등을 포함할 수 있다. 일단 인벤토리화되고 나면, 담보 관리 시스템(802)은 담보 아이템을 나타내는 가상 아이템을 생성할 수 있으며, 그 다음, ("담보 토큰"이라고도 지칭될 수 있는) 가상 아이템에 대응하는 대체불가능한 토큰을 생성할 수 있다. 예를 들어, 담보 관리 시스템(802)은 원장 관리 시스템(104)에게 가상 아이템 및 담보 토큰의 생성을 요청할 수 있다. 담보 토큰이 생성되면, 원장 관리 시스템(104)은 새로운 담보 토큰과 차용자에 의한 담보 토큰의 소유권을 반영하도록 분산형 원장을 업데이트할 수 있다. 그러면, 담보 토큰은 차용자의 디지털 지갑에 나타날 수 있다. 일부 실시예에서, 담보 토큰은 디지털 지갑에서 시각적 표식에 의해 표현될 수 있다. 담보 토큰에 대응하는 담보 아이템은 담보 토큰이 상환될 때까지 시설에 보관될 수 있다. 일단 상환되고 나면, 상환 사용자(차용자 또는 담보 토큰의 양수인)는 시설로부터 담보 아이템을 픽업할 수 있거나 담보 아이템을 그곳으로 배송할 수 있다.
실시예들에서, 담보 관리 시스템(802)은 차용자가 담보 토큰을 이용하여 대출을 요청하는 것을 허용할 수 있다. 실시예들에서, 담보 관리 시스템(802)은, 차용자가 대출 금액을 요청하고 담보 토큰을 담보로서 제공할 수 있는 (예를 들어, 그래픽 사용자 인터페이스를 통해 액세스가능한) 시장을 제공할 수 있다. (토큰화 플랫폼(100)에 계정을 가진) 대출자는 시장을 통해 차용자에게 대출 제안을 할 수 있다. 예시적인 실시예들에서, 대출 제안은, 대출 금액, 이자율, 및 대출 기간을 명시할 수 있다. 대출 제안은, 추가 조건도 역시 포함할 수 있다. 예를 들어, 대출 제안은, 대출이 또 다른 대출자에게 판매될 수 있는지, 및 그럴 경우, 원래의 대출자에게 지불되어야 할 지불액을 나타낼 수 있다. 차용자는 대출 제안을 통해 쇼핑할 수 있고, 궁극적으로 수락할 대출 제안을 결정할 수 있다.
일단 차용자가 제안을 수락하고 나면, 담보 관리 시스템(802)은 대출의 조건을 기억하고 담보 토큰을 에스크로잉할 수 있는 대출 스마트 계약의 한 인스턴스를 인스턴스화할 수 있다(예를 들어, 스마트 계약을 준수하지 않고서는 누구도 담보 토큰을 상환하거나 담보 토큰을 이전할 수 없다). 담보 토큰을 에스크로잉할 때, 담보 관리 시스템(802)(또는 대출 스마트 계약)은 담보 토큰을 에스크로 계정에 예치하여 거래의 어느 당사자도 담보 토큰이 에스크로 계정에 있는 동안 담보 토큰에 대한 소유권을 갖지 못하게 할 수 있다. 이러한 조치는 대출이 상환되거나 기저 아이템이 청산될 때까지 담보 토큰을 잠금처리할 것이다. 실시예들에서, 대출 스마트 계약은, 대출자, 차용자, 잠금처리된 담보 토큰(및 그 주소), 대출 금액, 지불 일정, 대출이 이전가능한지의 여부, 대출이 채무불이행 상태인 것으로 간주되는 경우, 채무불이행시 담보 토큰의 소유권 등을 나타낼 수 있다. 원장 관리 시스템(104)은 대출 스마트 계약을 반영하도록 분산형 원장을 업데이트할 수 있다.
일단 스마트 계약의 인스턴스가 인스턴스화되고 나면, 차용자는 대출 일정에 따라 대출 상환을 개시해야 한다. 대출 일정은, 주어진 시간까지 단일 일시불 지불을 요구할 수 있거나, 미리결정된 간격으로 이루어져야 하는 여러 번의 지불을 요구할 수 있다는 것을 이해할 것이다. 실시예들에서, 차용자는 자신의 디지털 지갑을 통해 대출자에게 지불할 수 있다. 이들 실시예들에서, 차용자는, 은행, 신용 카드, 다른 통화를 보유한 디지털 지갑 등으로부터 자금을 이전할 수 있다. 차용자는 디지털 지갑을 통해 이들 자금을 대출자에게 이전할 수 있다. 일부 실시예에서, 원장 브릿징 시스템(416)은 차용자의 계정으로부터 대출자의 계정으로의 자금의 이전을 용이화한다.
실시예들에서, 담보 관리 시스템(802)은 대출을 관할하는 스마트 계약의 인스턴스에 대응하는 청취 스레드를 배치할 수 있다. 청취 스레드는 스마트 계약의 인스턴스에 정의된 차용자의 지불을 청취할 수 있다. 지불이 이루어질 때, 청취 스레드는 지불을 반영하도록 분산형 원장을 업데이트하는 원장 관리 시스템(104)에 통보할 수 있다. 이 업데이트 동안, 대출을 관할하는 스마트 계약의 인스턴스는 지불 이벤트를 나타내는 통보를 제공받고, 이것은 스마트 계약으로 하여금 대출이 전액 상환되었는지를 결정하게 할 수 있다. 대출이 전액 상환되면, 스마트 계약은 담보 토큰을 차용자에게 릴리스하여 스마트 계약을 종료시킨다. 대출 금액이 상환되지 않으면, 스마트 계약의 조건(예를 들어, 대출 금액 및 다음 상환)이 지불에 기초하여 업데이트될 수 있다. 청취 스레드가 지불 기한일 이전에 지불의 영수증을 검출하지 못하면, 청취 스레드는 원장 관리 시스템(104)에게 지불 누락을 통보할 수 있다. 통보에 응답하여, 원장 관리 시스템(104)은 미지불을 반영하도록 분산형 원장을 업데이트할 수 있으며, 이것은 스마트 계약이 계약 조건에 따라 대출이 채무불이행 상태인지를 결정하게 할 수 있다. 대출이 채무불이행 상태인 것으로 결정되면, 스마트 계약은 담보 토큰의 소유권을 스마트 계약에 의해 명시된 당사자(예를 들어, 대출자)에게 이전한다. 일단 이러한 상황이 발생하면, 대출자는 이제 담보 토큰의 소유자이므로, 대출자는 담보 토큰을 상환하거나, 담보 토큰을 판매하거나, 담보 토큰을 선물하거나, 담보 토큰을 교환할 수 있다.
실시예들에서, 담보 관리 시스템(802)은 구매 또는 이전될 수 있는 대출을 위한 시장을 제공할 수 있다. 시장은, 대출 만기 금액, 대출 가치(예를 들어, 완전히 갚을 때 수금해야 하는 금액), 대출 지불 내역(예를 들어, 차용자가 지불을 하고 있는지 누락하고 있는지), 대출을 담보하는 담보 아이템, 대출 구매 가격 등을 제시할 수 있다. 일부 실시예에서, 잠재적 대출자는 현재의 대출자로부터 대출을 구매하기로 선택할 수 있다. 이들 실시예들에서, 대출의 구매는 담보 관리 시스템(802)으로 하여금 현재의 스마트 계약을 종료하고 새로운 소유자를 반영하도록 새로운 스마트 계약을 인스턴스화하거나 스마트 계약을 조정하여, 지불이 새로운 대출자의 계정으로 향하게 하거나 차용자 채무불이행시 새로운 대출자를 담보 토큰의 목적지로서 지정하게 할 것이다. 추가적으로, 또는 대안으로, 차용자는 시장을 이용하여 대출에 관한 더 좋은 조건을 찾을 수 있다. 대출이 이전가능하다고 가정하면, 차용자는 시장에서 대출을 나열할 수 있고, 이에 의해 잠재적 대출자가, 차용자의 지불 내역, 대출의 나머지 잔액, 대출 상환 금액, 및 담보 아이템을 볼 수 있다. 그 다음, 잠재적인 대출자는 차용자에게 대출 제안을 할 수 있고, 각각의 대출 제안은 그 조건을 갖는다. 차용자는 대출 제안을 수락할 수 있다. 차용자가 대출 제안을 수락하는 것에 응답하여, 새로운 대출자는 대출 상환 금액을 이전 대출자에게 이전해야 하며, 이것은 담보 관리 시스템(802)으로 하여금 현재의 스마트 계약을 종료하고 대출 제안의 새로이 수락된 조건에 따라 스마트 계약의 새로운 인스턴스를 인스턴스화하게 한다.
실시예들에서, 플랫폼(100)은 인증 시스템(804)을 포함한다. 인증 시스템(804)은 플랫폼(100)을 대신하여 인증 및/또는 평가 지원 서비스들을 제공할 수 있다. 일부 실시예에서, 인증 시스템(804)은 판매용으로 제공되거나 담보용으로 제공되는 아이템을 인증하는데 이용될 수 있다. 추가적으로 또는 대안으로서, 인증 시스템(804)은 판매용으로 제공되거나 담보용으로 제공되는 아이템의 평가를 획득하는데 이용될 수 있다.
일부 실시예에서, 인증 시스템(804)은 사용자(예를 들어, 아이템을 보유하는 시설의 판매자 또는 직원)가 아이템의 가상 표현을 업로드하는 것을 허용하는 포털을 제공한다. 사용자는 아이템 분류(예를 들어, 야구 카드, 빈티지 의류, 보석류, 예술품 등), 및 가상 아이템의 하나 이상의 고해상도 사진; 아이템의 3D 표현; 아이템의 치수; 아이템의 무게; 및/또는 기타 등등 중 하나 이상을 제공할 수 있다. 인증 시스템(804)은, 분야 고유의 전문가가 자신의 전문 분야에서 분류된 아이템을 인증 및/또는 평가할 수 있도록, 분야 고유의 전문가가 인증자/평가자로서 등록하는 것을 허용할 수 있다. 예를 들어, 스포츠 기념품 전문가는 야구 카드와 기념품을 인증할 수 있지만 보석이나 예술품은 인증하는 것이 허용되지 않는다. 일부 실시예에서, 인증자는 자신의 전문 분야 및 전문 분야 내의 하위 분야에 대해 평가될 수 있다(예를 들어, 스포츠 기념품의 일반 범주 내에서, 전문가는, 야구 기념품, 농구 기념품, 축구 기념품 등에 관한 지식과 관련하여 평가될 수 있다). 새로운 아이템이 포털에 입력되면, 분야별 전문가가 평가/인증 작업에 입찰할 수 있으며, 이에 의해, 입찰은 전문가가 평가/인증 작업을 수행할 조건(예를 들어, 가격)을 나타낸다. 사용자는 전문가들 중 한 명 이상을 그들 개개의 입찰 및/또는 등급에 기초하여 선택할 수 있다. 대안으로서, 인증 시스템(804)은 전문가들 중 한 명 이상을 그들 개개의 입찰 및/또는 등급에 기초하여 선택할 수 있다. 어떤 전문가가 입찰에서 낙찰되면, 그 전문가는 사용자에 의해 업로드된 정보(예를 들어, 가상 아이템의 하나 이상의 고해상도 사진, 아이템의 3D 표현, 아이템의 치수, 아이템의 무게, 및/또는 기타 등등)에 기초하여 인증 및/또는 평가를 수행한다. 전문가는 평가 가치 및/또는 아이템의 진위성을 나타내는 결정을 제공할 수 있다. 인증 시스템(804)은 전문가의 평가 및/또는 진위 결정을 가상 아이템의 가상 표현에 포함할 수 있고, 일부 실시예에서, 인증 시스템(804)은 전문가의 평가 및/또는 진위 결정을 이용하여 분산형 원장을 업데이트할 수 있다. 이해될 수 있는 바와 같이, 평가 및/또는 진위 결정의 결과, 아이템이 플랫폼에 유지되거나 플랫폼에서 제거되거나, 아이템을 이용하여 대출을 담보화하는 능력에 영향을 미칠 수 있다.
일부 실시예에서, 인증 시스템(804)은 전문가의 결정에 대한 이유를 나타내는 평가/인증 메모를 제공할 것을 전문가에게 요구한다. 평가를 제공하고/하거나 진위의 결정을 제공할 때, 전문가는 자신의 발견에 대한 하나 이상의 이유를 제공한다. 예를 들어, 특정한 신발이 모조품이라고 의견을 말할 때, 전문가는 신발의 스티칭이 모조품임을 나타낸다는 것을 메모에서 표시할 수 있다. 인증 시스템(804)은 전문가의 평가/진위 메모를 가상 아이템의 가상 표현에 포함할 수 있고, 일부 실시예에서, 인증 시스템(804)은 전문가의 평가/진위 메모를 이용하여 분산형 원장을 업데이트할 수 있다.
실시예들에서, 인증 메모뿐만 아니라 전문가 인증 결정은, 아이템이 가짜인지를 결정할 수 있는 하나 이상의 모델을 훈련시키기 위해 머신 학습 시스템(502)(도 5)에 의해 이용될 수 있다. 이들 실시예들에서, 모델은, 가짜로 간주된 아이템의 이미지, 무게, 치수 및/또는 기타의 피처에 대해 훈련될 수 있다. 인증 시스템(804)은 (인공 지능 시스템(804)을 통해) 이들 모델을 활용하여 새로운 아이템이 가짜인지를 결정할 수 있다. 모델이 아이템을 가짜일 가능성이 있는 것으로 분류하면, 인증 시스템(804)은 결정을 가상 아이템의 가상 표현에 포함할 수 있고, 일부 실시예에서 인증 시스템(804)은 아이템이 모조품일 가능성이 높다는 결정을 이용하여 분산형 원장을 업데이트할 수 있다. 모델이 아이템을 가짜일 가능성이 높은 것으로 분류할 수 없는 경우, 인증 시스템(804)은 전문가가 아이템의 진위를 평가할 수 있도록 포털에 아이템을 나열할 수 있다. 실시예들에서, 모델은 아이템을 가짜일 가능성이 높은 것으로 분류할 수 있지만, 위조자가 위조 아이템의 품질을 적합화하고 개선하여 모델이 잘못된 인증을 발행하도록 속일 수 있으므로, 전문가만이 아이템을 인증할 수 있다는 점에 유의한다.
일부 실시예에서, 담보 관리 시스템(802), 인증 시스템(804), 및 원장 관리 시스템(104)은, 증권화된 탈집중형 대출 프로세스를 지원하도록 구성될 수 있다. 증권화된 탈집중형 대출 프로세스의 예시적인 구현들은, 도 XXX를 참조하는 것을 포함한, 본 개시내용 전반에 걸쳐 설명된다.
실시예들에서, 토큰화 플랫폼(100)은 미스터리 박스 게임을 지원하는 미스터리 박스 시스템(806)을 포함한다. 실시예들에서, "미스터리 박스"란 잠재적으로 플레이어가 당첨될 수 있는 토큰 세트를 말할 수 있으며, 여기서 각각의 토큰은 토큰을 이용하여 상환될 수 있는 상이한 아이템을 나타낸다. 실시예들에서, 각각의 토큰은 선택될 상이한 확률을 가질 수 있다. 일부 실시예에서, 각각의 토큰에는 숫자 범위가 할당될 수 있으며, 여기서 각각의 토큰에 대한 숫자 범위는 플레이어가 당첨될 확률을 반영한다. 예를 들어, 제3개의 토큰이 있고, 제1 토큰이 10%의 당첨 확률을 가지며, 제2 토큰은 20%의 당첨 확률을 가지며, 제3 토큰은 30%의 당첨 확률을 가지며, 어떠한 토큰도 40%의 당첨 확률을 갖지 않는다면, 제1 토큰에는 1-10이 할당될 수 있고, 제2 토큰에는 11-30이 할당될 수 있고, 제3 토큰에는 31-60이 할당될 수 있다. 이 예에서, 선택될 수 있는 값의 범위는 1-100이다. 플레이어는 미스터리 박스 내의 아이템에 당첨될 확률에 대해 지불할 수 있다. 일부 실시예에서, 각각의 토큰에 당첨될 확률 및 토큰에 의해 표현되는 아이템은 미스터리 박스와 관련하여 묘사된다. 이러한 방식으로, 플레이어는 다양한 아이템에 대해 당첨될 수 있는 기회에 관해 통보받을 수 있다.
플레이어로부터 지불을 받는 것에 응답하여, 미스터리 박스 시스템(806)은 박스에 대한 값들의 전체 범위(예를 들어, 1-100)에 의해 제한되는 난수를 생성할 수 있다. 그 다음, 미스터리 박스 시스템(806)은, 있다면, 어느 토큰이 플레이어에 의해 당첨되었는지를 난수에 기초하여 결정할 수 있다. 예를 들어, 미스터리 박스는 보석 테마일 수 있으며, 미스터리 박스는 다이아몬드 반지를 나타내는 제1 토큰, 큐빅 지르코늄 반지를 나타내는 제2 토큰, 및 각각이, 특정한 보석상(예를 들어, 반지를 제공한 보석 상점)에서 소비될 수 있는 $25 기프트 카드를 나타내는 8개의 토큰을 포함한다. 이 예에서, 제1 토큰은 1%의 당첨 확률을 가질 수 있고, 제2 토큰은 4.9%의 당첨 확률을 가질 수 있고, 기프트 카드는 각각 10%의 당첨 확률을 가질 수 있어서, 이에 의해 플레이어가 상을 타지 못할 확률은 15%이다. 이 예에서, 숫자의 범위는 1-1000일 수 있고, 여기서 제1 토큰은 숫자 1에 대응하고 제2 토큰은 2-50의 범위에 대응하며 제3 내지 제8 토큰은 51-850의 집합적 범위를 갖는다. 이 예에서, 플레이할 가격은, 기프트 카드가 보석 상점으로 트래픽을 유도하는 메커니즘으로 간주될 수 있도록 보석 상점에 의해 설정될 수 있다. 전술된 예에서, 토큰의 범위는 순차적이지만, 범위는 순차적일 필요가 없고 임의의 적절한 방식으로 슬롯화될 수 있다는 점에 유의한다.
실시예들에서, 미스터리 박스 시스템(806)은, 플레이어가 미스터리 박스로부터 상을 타는 것에 응답하여, 토큰을 당첨 플레이어의 계정에 이전할 수 있다. 이들 실시예들에서, 당첨된 토큰은 플레이어의 디지털 지갑에 나타날 수 있다. 대안으로서, 미스터리 박스 시스템(806)은 전자 메시지(예를 들어, 문자 메시지, 메시징 앱 메시지, 이메일 등)를 통해 사용자에게 당첨된 토큰을 배달할 수 있다. 아래에서 논의되는 바와 같이, 일부 실시예에서, 미스터리 박스 시스템(806)은, 미스터리 박스 게임이 물리적 디바이스에서 구현되도록 오프라인 카지노에 서비스를 제공한다. 이들 실시예들에서, 미스터리 박스 시스템(806)은 당첨된 티켓의 토큰 식별자(예를 들어, QR 코드)를 갖는 티켓을 인쇄할 수 있다.
실시예들에서, 미스터리 박스 시스템(806)은 플레이어가 플레이할 미스터리 박스를 복수의 이용가능한 미스터리 박스로부터 선택하는 것을 허용할 수 있으며, 여기서 각각의 미스터리 박스는 개개의 테마를 가질 수 있다. 예를 들어, 제1 미스터리 박스는 미스터리 박스가 예술 관련 아이템(예를 들어, 작품 예술, 예술 관련 제품, 예술 관련 서비스(예를 들어, 예술가의 의뢰받은 그림), 및 기타 등등)에 대응하는 토큰을 포함하도록 예술 테마일 수 있다; 제2 박스는 엔터테인먼트 테마일 수 있고, 여기서, 제2 박스는 영화 및 텔레비전 관련 아이템(예를 들어, 인기 영화 및/또는 TV 쇼의 기념품 아이템, 영화 및/또는 TV 쇼에 대한 DVD 또는 다운로드 코드, 영화관 등의 상품권, 및 기타 등등)에 대응하는 토큰을 포함할 수 있다; 제3 박스는 스포츠 테마일 수 있고, 여기서 제3 박스는 특정한 팀에 대응하는 스포츠 관련 아이템(예를 들어, 게임 착용 의류, 게임 티켓, 복제품 의류, 팀 의류, 및 기타 등등)에 대응하는 토큰을 포함할 수 있다; 제4 박스는 게임 테마일 수 있고, 여기서 제4 박스는 게임 관련 아이템(예를 들어, 비디오 게임 시스템, 비디오 게임, 상품권, 특정한 게임의 캐릭터에 대한 업그레이드, 및 기타 등등)에 대응하는 토큰을 포함할 수 있다; 제5 박스는 음악 테마일 수 있고, 여기서 박스는 특정한 밴드 또는 아티스트에 대응하는 아이템(예를 들어, 서명된 쇼 포스터, 밴드 또는 아티스트의 기념품, 쇼 티켓, 앨범 또는 노래에 대한 다운로드 코드, 및 기타 등등)과 관련된 토큰을 포함할 수 있다; 및 기타 등등. 이러한 방식으로, 플레이어는 자신을 유혹하는 상을 위해 플레이할 것을 선택할 수 있다.
실시예들에서, 미스터리 박스는 보충가능한 아이템 및/또는 보충불가능한 아이템에 대응하는 토큰을 포함할 수 있다. 보충가능한 아이템은 플레이어가 아이템을 나타내는 토큰에 당첨되었을 때 미스터리 박스에 보충될 수 있는 아이템이다. 예를 들어, 상품권, 영화 티켓, 스포츠 게임 티켓, DVD, 전자 제품, 비디오 게임, 복제 셔츠, 및 대부분의 의류 아이템은 보충가능한 반면, 손목 시계, 고급 보석, 게임 착용 스포츠 의류, 사인 기념품, 한정판 신발, 원본 예술 작품 등의 아이템은 보충불가능한 아이템의 예이다. 일부 실시예에서, 미스터리 박스를 제공하는 당사자는 미스터리 박스에서 보충불가능한 아이템에 대해 유사한 값의 대체 아이템을 지정할 수 있어서, 보충불가능한 아이템이 미스터리 박스로부터 당첨될 때 지정된 대체 아이템들 중 하나로 대체될 수 있다. 이들 실시예들 중 일부에서, 미스터리 박스는 "레시피"에 따라 배열될 수 있다. 레시피는 미스터리 박스 내의 2개 이상의 아이템 계층을 지정하고, 각각의 계층에 대해, 계층으로부터 아이템에 당첨될 확률을 지정한다. 이들 실시예들에서, 미스터리 박스의 제공자는 각각의 계층에 속하는 아이템의 목록을 제공할 수 있다. 예를 들어, 가장 높은 계층(예를 들어, 가장 낮은 확률을 가진 계층)은 고가의 보충불가능한 아이템을 포함할 수 있는 반면, 더 낮은 계층들은 다양한 레벨의 보충가능한 아이템을 포함할 수 있다. 레시피의 각각의 아이템은 토큰화될 수 있어서, 토큰이 미스터리 박스에서의 이용을 위해 예약될 수 있다. 플레이어가 계층으로부터의 아이템에 당첨될 때마다, 미스터리 박스 시스템(806)은 그 아이템을 나타내는 토큰을 당첨된 토큰과 동일한 계층의 또 다른 토큰으로 대체할 수 있다. 이러한 방식으로, 미스터리 박스를 플레이할 때의 가격과 미스터리 박스 내의 각각의 아이템과 연관된 확률은, 미스터리 박스로부터 보충불가능한 아이템이 당첨될 때 변경되지 않는다.
실시예들에서, 각각의 미스터리 박스는 스마트 계약에 의해 관할된다. 스마트 계약은 상이한 아이템들 또는 아이템 계층들을 정의할 수 있으며, 각각의 개개 아이템 또는 아이템 계층에 대해, 개개의 아이템에 당첨될 확률을 정의할 수 있다. 새로운 미스터리 박스가 생성될 때, 미스터리 박스 시스템(806)은 새로운 미스터리 박스에 대응하는 새로운 스마트 계약을 인스턴스화할 수 있다. 스마트 계약의 인스턴스는 새로운 미스터리 박스의 아이템 또는 아이템 계층, 각각의 아이템(또는 아이템 계층)의 확률, 미스터리 박스 내의 각각의 아이템(또는 미스터리 박스 내에 포함될 수 있는 대체 아이템)의 토큰 식별자, 및 미스터리 박스 플레이 가격을 정의할 수 있다. 미스터리 박스에서 아이템이 대체되지 않는 실시예들에서, 스마트 계약은 소정의 아이템이 소진되었을 때 아이템의 확률 또는 게임 가격이 조정될 수 있는 방식을 추가로 정의할 수 있다. 예를 들어, 미스터리 박스에서 최고가의 아이템이 당첨되면, 게임 플레이 가격이 낮아질 수 있고/있거나 나머지 아이템에 당첨될 확률이 조정될 수 있다.
미스터리 박스 시스템(806)은 다양한 상이한 방식으로 미스터리 박스 게임을 서비스할 수 있다. 실시예들에서, 미스터리 박스 시스템(806)은 토큰화 플랫폼(100)을 통해 미스터리 박스 게임을 서비스할 수 있고, 이에 의해 토큰화 플랫폼(100)의 사용자는 토큰화 플랫폼(100)에 의해 제공되는 웹사이트 또는 애플리케이션에서 미스터리 박스 게임을 플레이할 수 있다. 추가적으로, 또는 대안으로서, 미스터리 박스 시스템(806)은 제3자 웹사이트 또는 애플리케이션을 통해 사용자에게 미스터리 박스 게임을 서비스할 수 있다. 이들 실시예들에서, 제3자 웹사이트 또는 애플리케이션은 토큰화 플랫폼(100)의 API 시스템(108)을 통해 미스터리 박스 시스템(806)에 액세스할 수 있다.
일부 실시예에서, 미스터리 박스 시스템(806)은 카지노 스타일 머신을 지원할 수 있으며, 이에 의해 플레이어는 예를 들어 카지노 또는 임의의 다른 적절한 오프라인 위치에 놓인 물리적 머신에서 미스터리 박스 게임을 플레이할 수 있다. 이들 실시예들에서, 아이템은 물리적 디바이스가 놓인 오프라인 위치에 놓일 수 있으므로, 플레이어가 미스터리 박스로부터 아이템에 당첨될 때, 플레이어는 오프라인 위치에서 토큰을 상환할 수 있게 한다. 이들 실시예들에서, 토큰화 플랫폼(100)은, 오프라인 위치에서 플레이되는 미스터리 박스 게임을 지원하는 미스터리 박스 시스템(806)을 포함한다. 이들 실시예들에서, 미스터리 박스 시스템(806)은, 네트워크-접속된 물리적 게임 디바이스가 토큰화 플랫폼(100)과 통신하는 것을 허용하는 API를 제공할 수 있다. 미스터리 박스 시스템(806)은, API 시스템(108)을 통해 물리적 게임 디바이스에 미스터리 박스 게임을 서비스할 수 있다. 실시예들에서, 미스터리 박스 시스템(806)은, 물리적 게임 디바이스가 당첨된 토큰을 나타내는 티켓을 인쇄할 수 있도록 당첨된 티켓의 토큰 식별자를 제공할 수 있다. 일부 실시예에서, 티켓은 당첨된 토큰을 나타내는 QR 코드를 포함할 수 있다.
실시예들에서, 플레이어는 당첨된 토큰을 나타내는 티켓을 오프라인 위치에서 상환할 수 있다. 이들 실시예들에서, 오프라인 위치는, 티켓을 스캔하고 당첨된 토큰의 토큰 식별자를 카지노 게임 시스템에 전달하는 스캔 디바이스를 포함할 수 있다. 당첨된 토큰의 토큰 식별자를 수신하는 것에 응답하여, 미스터리 박스 시스템(806)은 플레이어를 대신하여 당첨된 토큰을 상환할 수 있고, 당첨된 토큰의 상환에 대한 확인을 스캔 디바이스에 전달할 수 있다. 그러면, 스캔 디바이스를 이용하는 직원은 플레이어에 의해 당첨된 아이템을 플레이어에게 제공할 수 있다. 대안으로서, 플레이어는 당첨된 토큰을 플레이어의 사용자 계정에 추가할 수 있다. 이들 실시예들에서, 플레이어는 티켓(예를 들어, QR 코드)을 스캔할 수 있다. 플레이어가 티켓을 스캔하는 것에 응답하여, 미스터리 박스 시스템(806)은 플레이어의 계정으로의 토큰의 이전을 용이화할 수 있으며, 이에 의해 티켓이 플레이어의 디지털 지갑에 나타날 수 있다. 일단 이것이 발생하고 나면, 플레이어는 토큰을 상환, 판매, 선물, 담보화 또는 기타의 방식으로 거래할 수 있다.
실시예들에서, 토큰화 플랫폼(100)은 비디오 게임 통합 시스템(808)을 포함한다. 비디오 게임 통합 시스템(808)은 비디오 게임 제작자가 비디오 게임에 토큰을 배치하는 것을 허용하여, 비디오 게임을 플레이하는 게이머가 비디오 게임 내의 토큰을 발견, 구매, 매매 또는 기타의 방식으로 상호작용 가능하게 할 수 있게 한다. 실시예들에서, 비디오 게임 제작자는 API 시스템(108)을 통해 토큰화 플랫폼(100)의 API에 액세스할 수 있어서, 비디오 게임의 인스턴스가 토큰화 플랫폼(100)에게 소정의 토큰 또는 토큰 유형을 요청할 수 있게 한다. 요청에 응답하여, 비디오 게임 통합 시스템(808)은 비디오 게임의 인스턴스에 토큰을 서비스할 수 있다. 토큰은 대체가능하거나 대체불가능할 수 있다. 후자의 경우, 토큰은 복수의 비디오 게임에 의해 획득, 구매 또는 기타의 방식으로 거래될 수 있다. 대체불가능한 토큰의 경우, 토큰을 거래하는 제1 사용자가 토큰의 소유자이다. 사용자가 토큰을 거래하는 것에 응답하여, 비디오 게임 통합 시스템(808)은 토큰의 새로운 소유권을 반영하도록 분산형 원장을 업데이트할 수 있다.
일부 예시적인 실시예에서, 비디오 게임 제작자는 제3자가 비디오 게임에서 판매할 아이템을 광고하는 것을 허용할 수 있으며, 이에 의해 사용자는 아이템에 대응하는 토큰을 나타내는 비디오 게임에 디스플레이된 아이콘(또는 다른 시각적 표식)을 선택함으로써 아이템을 구매할 수 있다. 예를 들어, 피자 배달 체인을 대표하는 광고주는 특정한 위치의 게이머에게 피자 배달을 제공하기를 원할 수 있다. 이 예에서, 비디오 게임의 인스턴스는, 비디오 게임 통합 시스템(808)에게 음식 관련 토큰을 요청할 수 있고, 이에 의해 각각의 요청은 비디오 게임의 개개의 인스턴스를 실행하는 디바이스의 위치를 나타낸다. 비디오 게임 통합 시스템(808)은, 비디오 게임의 개개의 인스턴스가 실행되고 있는 위치로 배달될 수 있는 음식 아이템에 대응하는 토큰을 식별할 수 있다. 예를 들어, 비디오 게임 통합 시스템(808)은, 요청에서 표시된 위치를 포함하는 배달 반경을 나타내는 연관된 메타데이터를 갖는 토큰을 식별할 수 있다. 요청에 응답하여, 비디오 게임 통합 시스템(808)은 식별된 토큰을 비디오 게임의 요청 인스턴스에 서비스한다. 토큰을 나타내는 시각적 표식은 비디오 게임의 인스턴스에 의해 디스플레이될 수 있으며, 이에 의해 사용자(즉, 비디오 게임 플레이어)는 토큰을 거래할 것을 선택할 수 있다. 사용자가 토큰의 소유권을 거래할 때, 비디오 게임 통합 시스템(808)은 토큰이 사용자에 의해 소유되어 있다는 것을 반영하기 위해 토큰의 소유권 데이터를 업데이트한다. 배달 정보 또는 기타의 물류 정보가 필요한 시나리오에서, 비디오 게임의 인스턴스 및/또는 사용자는 거래시 이들 상세사항을 제공할 수 있거나 사용자가 거래를 완료하는데 요구되는 정보를 제공할 수 있다. 예를 들어, 사용자가 피자 배달 체인으로부터 피자 토큰을 구매하기로 선택한 경우, 비디오 게임의 인스턴스 및/또는 사용자는 피자가 배달될 주소를 제공할 수 있다. 사용자는, 비디오 게임의 인스턴스를 통해, 피자 토핑 등의 상세사항을 제공할 수도 있다.
일부 예시적인 실시예에서, 비디오 게임 제작자는 토큰에 의해 표현된 아이템이 비디오 게임의 디지털 환경에서 이용되고 또한 "현실 세계 생활"에서 상환되는 것 양쪽 모두를 허용할 수 있다. 이들 실시예들에서, 비디오 게임 제작자는 특정한 대체가능 또는 대체불가능한 토큰을 비디오 게임에 포함할 수 있으며, 이에 의해 사용자는 비디오 게임에 나타나는 토큰을 발견, 구매, 매매, 또는 기타의 방식으로 거래할 수 있다. 일단 비디오 게임에 나타나는 토큰이 거래되면, 비디오 게임 통합 시스템(808)은 사용자가 토큰의 소유자임을 반영하도록 거래된 토큰의 소유권 데이터를 업데이트할 수 있다. 토큰의 시각적 표식은, 사용자에 대응하는 비디오 게임 인스턴스에 및/또는 사용자의 디지털 지갑에 나타날 수 있다. 일단 사용자에 의해 소유되고 나면, 사용자는 비디오 게임에서 토큰을 이용할 수 있고, 후속해서 토큰을 상환하여 토큰에 의해 표현된 물리적 아이템을 받을 수 있다. 예를 들어, 롤플레잉 게임에서, 토큰은, 비디오 게임의 플레이어에게 특별한 능력(예를 들어, 투명성)을 부여하는 한 쌍의 귀걸이를 나타낼 수 있다. 사용자는 게임에서 특별한 능력을 즐기기 위해 귀걸이를 이용할 수 있거나 귀걸이를 상환할 수 있다. 후자의 시나리오에서, 사용자가 귀걸이를 물리적으로 착용할 수 있지만 더 이상 비디오 게임에서 이용할 수 없도록, 귀걸이는 사용자에게 배송될 수 있다. 이들 실시예들 중 일부에서, 비디오 게임 제작자는 사용자가 토큰을 거래하는 것을 허용할 수 있다. 예를 들어, 토큰 소유자는, 토큰을, 또 다른 아이템에 대응하는 토큰과 매매하거나 판매할 수 있다. 소유권이 변경될 때마다, 비디오 게임 통합 시스템(808)은 소유권 변경을 반영하도록 분산형 원장을 업데이트할 수 있다. 일단 사용자가 더 이상 토큰을 소유하지 않게 되면, 사용자는 토큰에 의해 표시된 아이템을 이용 또는 상환할 수 없다. 일부 실시예에서, 비디오 게임은 사용자가 아이템을 확인된 위치(예를 들어, 저장 창고)로 반환하는 것을 허용할 수 있으며, 이에 의해 일단 아이템이 인증되고 나면 사용자는 비디오 게임에서 아이템의 디지털 표현을 다시 한 번 이용할 수 있다.
비디오 게임 통합 시스템(808)은 비디오 게임 제작자가 추가적 또는 대안적인 방식으로 토큰을 비디오 게임에 통합하는 것을 허용할 수 있다. 예를 들어, 비디오 게임 제작자는 토큰을 "이스터 에그(Easter eggs)"로서 이용하거나 플레이어가 토큰을 발견할 때 당첨될 수 있는 상으로서 이용할 수 있다. 또 다른 예에서, 비디오 게임 제작자는 하나 이상의 미스터리 박스를 비디오 게임에 통합할 수 있다. 또 다른 예에서, 사용자는, 디지털 아이템이 토큰화되고 거래(예를 들어, 매매, 선물, 판매 등)될 수 있도록 비디오 게임의 구성 내에서 디지털 아이템을 생성할 수 있다.
실시예들에서, 토큰화 플랫폼(100)은 사용자 취득 시스템(810)을 포함한다. 실시예들에서, 사용자 취득 시스템(810)은, 토큰화 플랫폼의 홍보, 특히 새로운 사용자의 등록을 용이화하는 메커니즘을 제공한다. 일부 실시예에서, 사용자 취득 시스템(810)은, 각각의 개개 사용자가 자신의 친구, 소셜 미디어 팔로워, 연락처 등과 공유할 수 있는 고유 추천 코드를 각각의 기존 사용자에게 제공한다. 또한, 사용자 취득 시스템(810)은 각각의 기존 사용자에게 인센티브를 제공할 수 있으며, 이에 의해 인센티브는 각각의 새로운 사용자 또는 계정에 등록한 사용자 수(예를 들어, 3명의 사용자)에 대한 보상을 나타낸다. 인센티브는, 통화(예를 들어, 전통적인 통화 또는 암호화폐), 기프트 카드, 물리적 아이템, 디지털 아이템 등을 포함한 임의의 형태의 지불일 수 있다. 일부 실시예에서, 보상은 토큰화된 토큰으로서 제공되며, 이에 의해 토큰화된 토큰은 설정된 금액의 통화를 나타낸다. 실시예들에서, 사용자 취득 시스템(810)은 상이한 사용자에게 상이한 인센티브를 제공할 수 있다. 일부 실시예에서, 인센티브는 각각의 개개 사용자의 잠재적 도달범위에 기초하여 결정될 수 있다. 예를 들어, 상당한 도달범위를 가진 사용자(예를 들어, 소셜 미디어 영향력자, 유명인 등)는 비교적 적은 도달범위를 가진 사용자보다 더 큰 인센티브를 받을 수 있다. 일부 실시예에서, 인센티브는 각각의 개개 사용자의 관심사에 기초하여 결정될 수 있다. 예를 들어, 골프에 관심이 있는 제1 사용자는 골프 관련 아이템 또는 상품권으로 인센티브를 받을 수 있는 반면, 예술에 관심이 있는 제2 사용자는 예술 관련 아이템 또는 상품권으로 인센티브를 받을 수 있다. 일부 실시예에서, 사용자 취득 시스템(810)은 스마트 계약의 개개의 인스턴스에서 각각의 사용자에 대한 인센티브를 성문화한다. 이들 실시예들 중 일부에서, 스마트 계약 인스턴스는 사용자의 인센티브/보상을 관할하며 사용자의 추천 코드 및/또는 사용자의 공개 주소와 연관된다. 사용자의 추천 코드가 새로운 계정을 등록하는데 성공적으로 이용되면, 스마트 계약은 보상을 나타내는 토큰을 추천 사용자의 계정으로 이전하는 것을 용이화할 수 있다.
새로운 사용자가 추천 코드를 이용하여 계정을 등록할 때마다, 사용자 취득 시스템(810)은 새로운 사용자가 정당한지를(예를 들어, 봇이 아니고, 사기 계정이 아닌지 등) 결정한다. 새로운 사용자에게 계정이 부여되었다고 가정하면(예를 들어, 사기가 검출되지 않음), 사용자 취득 시스템(810)은 추천 코드와 연관된 사용자 계정을 결정한다. 일부 실시예에서, 사용자 취득 시스템(810)은 사용자 계정 및/또는 추천 코드와 연관된 스마트 계약을 결정한다. 사용자 취득 시스템(810)은, 사용자 계정 및/또는 새로운 계정의 추천 코드와 연관된 스마트 계약에 통보를 제공할 수 있다. 그 다음, 스마트 계약은 보상을 나타내는 토큰의 사용자 계정으로의 이전을 개시할 수 있다.
실시예들에서, 사용자 취득 시스템(810)은 제3자 고객을 위해 이들 서비스를 수행할 수 있다. 이들 실시예들에서, 제3자 고객은, 신뢰할 수 있는 제3자 보유자(예를 들어, 토큰화 플랫폼 또는 또 다른 신뢰할 수 있는 보유자)에게 보상(예를 들어, 현금, 암호화폐, 기프트 카드, 물리적 아이템 등)을 제공할 수 있다. 보상은 토큰화되어 에스크로에 보유될 수 있다. 제3자는 보상을 관할하는 파라미터(예를 들어, 수여할 인센티브의 양, 누가 홍보자가 될 것인지 등)를 추가로 정의할 수 있다. 사용자 취득 시스템(810)은 제3자 고객을 대신하여 스마트 계약을 생성할 수 있다. 사용자가 추천 코드를 요청하면, 사용자 취득 시스템(810)은 고객을 대신하여 스마트 계약의 인스턴스를 생성할 수 있고 스마트 계약의 인스턴스를 사용자의 계정과 연관시킬 수 있다. 사용자가 추천 코드를 이용하여 구매자를 고객에게 성공적으로 보내면, 사용자 취득 시스템(810)(및/또는 스마트 계약의 인스턴스)은 보상을 나타내는 토큰을 추천 사용자의 계정으로 이전할 수 있다.
일부 실시예를 더 상세히 설명하기 위해, 다음으로, 전자 상거래 시스템, 예를 들어 플랫폼(100)에 의해 또는 이와 관련하여 수행될 수 있는 기술의 예를 참조한다. 이 기술은, 도 9의 기술 900, 도 10의 1000, 도 11의 1100, 도 12의 1200, 도 13의 1300, 도 14의 1400, 도 15의 1500, 도 16의 1600, 도 17의 1700, 도 18의 1800, 도 19의 1900을 포함한다. 기술 900, 기술 1000, 기술 1100, 기술 1200, 기술 1300, 기술 1400, 기술 1500, 기술 1600, 기술 1700, 기술 1800 및 기술 1900은, 여기서 설명된 시스템, 하드웨어 및 소프트웨어 등의, 컴퓨팅 디바이스를 이용하여 실행될 수 있다. 기술 900, 기술 1000, 기술 1100, 기술 1200, 기술 1300, 기술 1400, 기술 1500, 기술 1600, 기술 1700, 기술 1800 및 기술 1900은, 예를 들어, 루틴, 명령어, 프로그램 또는 기타의 코드 등의, 머신 판독가능한 프로그램 또는 기타의 컴퓨터 실행가능한 명령어를 실행함으로써 수행될 수 있다. 기술 900, 기술 1000, 기술 1100, 기술 1200, 기술 1300, 기술 1400, 기술 1500, 기술 1600, 기술 1700, 기술 1800 및 기술 1900, 또는 여기서 설명된 실시예들과 연계하여 설명된 또 다른 기술, 방법, 프로세스 또는 알고리즘의 단계들 또는 동작들은, 하드웨어, 펌웨어, 하드웨어에 의해 실행되는 소프트웨어, 회로 또는 이들의 조합에 의해 직접 구현될 수 있다. 설명의 간소화를 위해, 900, 기술 1000, 기술 1100, 기술 1200, 기술 1300, 기술 1400, 기술 1500, 기술 1600, 기술 1700, 기술 1800 및/또는 기술 1900 각각은, 일련의 단계들 또는 동작들로서 여기서 묘사되고 설명된다. 그러나, 본 개시내용에 따른 단계들 또는 동작들은 다양한 순서로 및/또는 동시에 발생할 수 있다. 추가적으로, 여기서 제시되고 설명되지 않은 다른 단계 또는 동작이 이용될 수도 있다. 또한, 개시된 주제에 따른 기술을 구현하기 위해 예시된 모든 단계 또는 동작이 요구되는 것은 아닐 수 있다.
도 9는 본 개시내용의 일부 실시예에 따른 아이템을 토큰화하기 위한 기술(900)을 보여주는 플로차트를 도시한다. 9002에서, 아이템 정보가 획득된다. 아이템 정보는, 아이템의 고유 유닛에 대한 고유 식별자 및 아이템 속성 세트를 포함할 수 있다. 실시예들에서, 토큰화 플랫폼의 처리 시스템은 정보를 획득한다.
904에서, 하나 이상의 디지털 토큰이 생성된다. 실시예들에서, 디지털 토큰은 고유 디지털 토큰이다. 각각의 고유 디지털 토큰은 아이템 속성 세트에 대응하는 디지털 속성 세트를 포함할 수 있다. 실시예들에서, N개의 디지털 토큰이 생성되고 아이템 또는 그 가상 표현에 링크된다. 실시예들에서, 토큰 생성 시스템은 하나 이상의 디지털 토큰을 생성한다.
906에서, 디지털 토큰은 아이템 정보와 결합된다. 실시예들에서, 암호화 링크는 디지털 토큰이 아이템의 표현을 제공하도록 디지털 토큰을 아이템 정보에 결합한다. 예를 들어, 디지털 토큰 및 아이템은, 아이템의 고유 유닛에 대한 고유 디지털 토큰 및 고유 식별자가 암호화방식으로 링크되어 아이템의 고유 유닛의 고유 디지털 표현을 제공할 수 있도록 고유할 수 있다. 실시예들에서, 토큰 생성 시스템(302)의 모듈 등의 링킹 시스템은 디지털 토큰을 아이템 정보에 결합한다.
실시예들에서, 토큰은 토큰화될 수 있다(예를 들어, 소정 금액의 자금을 나타내는 토큰을 생성할 때). 예를 들어, 아이템 정보는 플랫폼(100) 내의 또는 제3자 출처로부터의 자금일 수 있다. 토큰화된 토큰은 자금 수신 유효성확인에 응답하여 생성될 수 있고, 자금은 사용자의 거래로부터 보류될 수 있다. 일부 실시예에서, 자금은 공개적으로 사용자에게 귀속되고 원장은 플랫폼(100)에 의한 승인없이 토큰화된 자금의 사용자 거래를 방지하기 위해 자금에 대해 기록된 보류 또는 유치권으로 업데이트된다. 일부 실시예에서, 원장은 사용자로부터 플랫폼(100)으로의 자금의 이전을 반영하도록 업데이트된다. 유익하게도, 이전된 자금은 플랫폼(100)에 의해 (예를 들어, 제3자와의 예치 또는 투자를 위해) 매매될 수 있고, 토큰화된 토큰은 상환된 자금이 원래의 토큰화된 자금이 아니더라도 원래 자금과 동일한 금액으로 상환될 수 있어서, 토큰화된 토큰은 플랫폼(100) 내의 거래에 의해 이용될 수 있는 한편으로는, 예치된 자금은 플랫폼(100)과 제3자 사이의 경제 거래에 참여할 수 있게 한다.
도 10은 본 개시내용의 일부 실시예에 따른 디지털 시장을 이용하여 토큰을 이전하기 위한 기술(1000)을 보여주는 플로차트를 도시한다. 1002에서, 원장이 유지된다. 원장은, 복수의 공개 주소, 복수의 개개의 아이템의 복수의 가상 표현, 및 각각의 가상 표현에 대해, 토큰 세트 및 각각의 개개 토큰의 소유권 데이터를 저장한다. 토큰 세트는 가상 표현에 의해 표현되는 아이템의 각각의 인스턴스에 각각 대응한다. 또한, 각각의 공개 주소는 토큰화 플랫폼의 개개의 사용자의 개개의 계정에 대응한다.
1004에서, 디지털 시장이 제공된다. 실시예들에서, 디지털 시장은, 소비자가, 아이템의 가상 표현을 포함하는 아이템들의 가상 표현들의 시각화를 보고 N개의 디지털 토큰 중의 디지털 토큰을 구매함으로써 아이템의 인스턴스에 대해 거래하는 것을 허용하는 그래픽 사용자 인터페이스를 제공한다. 사용자가 토큰을 구매할 때, 원장은 토큰의 판매자로부터 사용자로의 토큰 소유권의 변경을 반영하도록 업데이트될 수 있다. 일단 사용자가 토큰을 소유하고 나면, 사용자는 토큰을 또 다른 사용자에게 이전하거나, 토큰을 판매하거나, 토큰을 담보로서 이용하거나, 및/또는 토큰을 상환하는 것이 허용될 수 있다.
1006에서, 사용자가 토큰 상환을 요청하는 것에 응답하여 상환이 처리된다. 실시예들에서, 상환은, 가상 표현에 대응하는 특정한 토큰을 거래 사용자의 계정과 연관시킴으로써 시작될 수 있다. 연관은, 거래 참여 요청을 확인하는 것에 응답하여 이루어질 수 있다. 양수인으로의 특정한 토큰의 이전을 요청하는 이전 요청이 수신된다. 이전 요청은, 특정한 토큰을 식별하는 디지털 토큰 식별자 및 상이한 사용자의 공개 주소를 포함한다. 또한, 특정한 토큰이 유효성확인된다. 유효성확인은, 디지털 토큰 식별자 및 원장에 기초할 수 있다. 이 프로세스에서, 플랫폼(100) 상의 양수인의 계정은 사용자 및 원장의 공개 주소에 기초하여 확인 및/또는 유효성확인될 수 있다. 추가로, 원장은 소유권 데이터를 포함하는 블록으로 업데이트되고 가상 표현에 대응하는 특정한 토큰이 거래 사용자에 의해 소유되어 있음을 나타낸다. 실시예들에서, 업데이트는, 특정한 토큰을 유효성확인하고 양수인을 확인하는 것 양쪽 모두에 응답하여 발생한다. 또한, 디지털 토큰을 상환하라는 상환 요청이 양수인의 사용자 디바이스로부터 수신되고, 토큰에 대응하는 아이템의 인스턴스에 대한 거래를 충족시키기 위해 워크플로우가 실행된다. 상환 요청을 수신하는 것에 응답하여 워크플로우가 개시될 수 있다.
도 11은 본 개시내용의 일부 실시예에 따른 키보드 상호작용을 통해 지갑들 사이에서 토큰을 이전하기 위한 기술(1100)을 보여주는 플로차트를 도시한다. 1102에서, 하나 이상의 지갑이 디스플레이된다. 하나 이상의 지갑의 디스플레이는, 예를 들어, 디지털 지갑과 연관된 사용자의 사용자 디바이스를 통해 디지털 지갑 그래픽 사용자 인터페이스를 디스플레이하는 것을 포함할 수 있다. 추가로, 사용자가 소유한 토큰 인벤토리는 디지털 지갑 그래픽 사용자 인터페이스에 의해 디스플레이될 수 있다. 실시예들에서, 각각의 토큰은 개개의 아이템에 대응하고, 개개의 아이템의 인스턴스에 대한 거래를 충족시키기 위해 사용자에 의해 상환될 수 있다.
1104에서, 이전 명령어가 수신된다. 이전 명령어는, 토큰 인벤토리 및 디지털 토큰의 수신자로부터의 하나 이상의 디지털 토큰의 표시를 포함할 수 있다. 이전 명령어는, 디지털 지갑 그래픽 사용자 인터페이스에서 수신될 수 있다.
1106에서, 디지털 토큰은 키보드 상호작용에 응답하여 이전된다. 실시예들에서, 디지털 키보드는 디지털 지갑 그래픽 사용자 인터페이스에 의해 디스플레이된다. 디지털 키보드는, 이전 요청 내에 디지털 토큰에 대응하는 아이템을 나타내는 선택가능한 미디어 콘텐츠를 포함한다. 디지털 키보드에 의한 선택가능한 미디어 콘텐츠의 선택을 포함하는 텍스트 기반의 메시지를 생성하는 사용자 입력이 수신된다. 예를 들어, 사용자는 이전을 둘러싸는 메시지(예를 들어, "나의 이 선물을 즐겨주세요")를 타이핑할 수 있고, 그 후 토큰을 나타내는 선택가능한 미디어 콘텐츠(예를 들어, 토큰에 의해 표현된 아이템의 이미지)를 선택하여 토큰 임베딩된 메시지를 생성할 수 있다. 선택가능한 미디어 콘텐츠는, 디지털 토큰/디지털 토큰의 식별자(예를 들어, 디지털 토큰을 고유하게 식별하는 해시 값)를 포함한다. 디지털 토큰(예를 들어, 그 식별자)은 디지털 키보드에 의해 텍스트 기반의 메시지 내에 임베딩되고, 디지털 지갑은 텍스트 기반의 메시지를 수신자의 메시지 계정으로 전송한다. 수신시, 디지털 토큰은, 수신자가 선택가능한 미디어 콘텐츠를 선택하는 것에 응답하여, 수신자의 개개의 디지털 지갑 내에 수락된다.
도 12는 본 개시내용의 일부 실시예에 따른 토큰을 상환하기 위한 기술(1200)을 보여주는 플로차트를 도시한다. 1202에서, 원장 데이터가 유지된다. 원장 데이터는, 복수의 공개 주소, 복수의 가상 표현, 복수의 가상 표현 각각에 대한 토큰 세트, 및 토큰 세트 각각에 대한 소유권 데이터를 포함할 수 있다. 각각의 개개 공개 주소는 토큰화 플랫폼의 개개 사용자의 개개 계정에 대응한다. 가상 표현은 개개의 아이템에 대응하고, 토큰 세트는 각각의 가상 표현에 대한 개개의 아이템의 개개의 인스턴스에 각각 대응한다.
1204에서, 상환 요청이 수신된다. 상환 요청은 사용자의 사용자 디바이스로부터의 디지털 토큰의 상환을 추구하고, 디지털 토큰은 상환될 아이템의 인스턴스에 대응한다. 1206에서, 사용자에 의한 디지털 토큰 소유권이 확인된다. 확인은, 복수의 공개 주소, 디지털 토큰 세트, 및 상환 요청에 기초하여 이루어질 수 있다. 예를 들어, 상환 요청은, 토큰 식별자에 의해 표시된 토큰을 상환하기를 원하는 사용자의 사용자 ID를 포함할 수 있다. 플랫폼(100)은, 원장 데이터가 상환 요청에서 표시된 토큰 식별자를 상환 요청에서 표시된 사용자의 공개 주소에 링크한다는 것을 체크함으로써 토큰의 소유권을 유효성확인할 수 있다. 만일 그렇다면, 디지털 토큰의 소유권이 확인된다.
1208에서, 이행 및/또는 배달을 위한 상세사항이 플랫폼(100)에 의해 관리된다. 일부 실시예에서, 플랫폼(100)은, (예를 들어, 그래픽 사용자 인터페이스를 통해) 사용자에게 배달 상세사항을 제공할 것을 촉구할 수 있다. 응답하여, 플랫폼(100)은 사용자 디바이스를 통해 사용자로부터 배달 상세사항을 수신할 수 있다. 그 다음, 배달 상세사항은 상환된 토큰의 배달을 개시하는 배달 시스템에 출력될 수 있다. 예를 들어, 사용자는 물리적 주소 및 기타 임의의 관련 배달 데이터(예를 들어, 배달에 가장 좋은 시간 또는 전화 번호)를 제공할 수 있다. 이 경우, 배달 시스템은 제공된 주소를 이용하여 상환된 토큰에 의해 표현되는 아이템의 배달을 개시할 수 있다. 또 다른 예에서, 토큰은 디지털 아이템을 나타낼 수 있다. 이러한 경우, 사용자는 디지털 아이템(또는 그 링크)이 배달될 수 있는 이메일 주소 또는 기타 계정 데이터를 제공할 수 있다. 일부 실시예에서, 플랫폼(100)은 사용자가 토큰의 소유자임을 확인하는 것에 응답하여 이행 상세사항을 요청할 수 있다. 이행 상세사항은, 토큰이 거래될 때 제공되지 않은 아이템에 대한 거래를 충족시키는데 필요한 정보를 포함한다. 예를 들어, 이행 상세사항은, 아이템 구성 재료, 크기, 색상, 이들의 조합 등을 포함할 수 있다. 이행 상세사항은, 사용자의 사용자 디바이스로부터 수신되어 이행 시스템에 출력될 수 있다. 이행 시스템은 이행 상세사항을 충족하는 아이템의 배달을 개시할 수 있다.
도 13은 본 개시내용의 일부 실시예에 따른 담보화 및/또는 증권화를 위한 기술(1300)을 보여주는 플로차트를 도시한다. 1302에서, 아이템 변환 요청이 수신된다. 실시예들에서, 아이템은 유형 아이템이다. 다른 실시예들에서, 아이템은 다른 형태의 담보이다. 1304에서, 아이템 정보가 수신된다. 아이템 정보는, 아이템의 평가액을 결정하는데 요구하거나 도움이되는 정보를 포함할 수 있다. 예를 들어, 아이템 정보는, 아이템의 하나 이상의 사진, 아이템의 설명, 아이템의 평가 가치, 및/또는 아이템의 보유 위치를 포함할 수 있다.
1306에서, 아이템 정보에 기초하여 담보 아이템의 가상 표현이 생성된다. 1308에서, 가상 표현에 기초하여 하나 이상의 토큰이 생성된다. 1310에서, 디지털 토큰의 소유권이 할당된다. 처음에, 디지털 토큰의 소유권은 디지털 토큰에 의해 표현된 담보 아이템의 소유자에게 할당된다. 1312에서, 아이템에 의해 뒷받침되는 합의가 기억된다. 실시예들에서, 아이템은, 제공자가 사용자에게 서비스를 제공하는 합의에 대한 담보로서 이용되는 자산이다. 실시예들에서, 서비스를 관할하는 스마트 계약의 인스턴스가 생성된다. 스마트 계약은 사용자가 제공자에게 제공할 금액과 디지털 토큰의 소유권이 제공자에게 이전되게 하는 하나 이상의 조건을 나타낸다. 그 다음, 처리 시스템에 의해 스마트 계약의 인스턴스가 배치될 수 있다. 실시예들에서, 아이템은 대출 담보로서 이용되는 담보가능한 아이템이다. 대출자가 사용자에게 정의된 금액의 자금을 대출하는 합의가 처리 시스템에 의해 수신된다. 대출을 관할하는 스마트 계약의 인스턴스는 처리 시스템에 의해 생성된다. 스마트 계약의 인스턴스는, 사용자가 대출자에게 상환해야 하는 금액뿐만 아니라, 토큰 소유권이 대출자에게 이전되게 하는 하나 이상의 조건 (예를 들어, 채무불이행 조건)을 나타낸다. 그 다음, 처리 시스템에 의해 스마트 계약의 인스턴스가 배치된다. 일부 실시예에서, 토큰은, 대출이 지불될 때까지 임차인이 토큰을 상환하거나 이전할 수 없도록 에스크로에 보관될 수 있다. 이들 실시예들에서, 스마트 계약은 토큰이 임차인에게 다시 이전되게 하는 조건(예를 들어, 지불이 완료될 때)을 정의할 수 있다.
도 14는 본 개시내용의 일부 실시예에 따른 아이템 인증을 위한 기술(1400)을 보여주는 플로차트를 도시한다. 1402에서, 토큰화 요청이 사용자 디바이스로부터 수신된다. 1404에서, 아이템 정보가 수신된다. 일부 실시예에서, 아이템 정보는 사용자에 의해 또는 자동화된 프로세스를 통해 제공될 수 있다. 1406에서, 아이템의 가상 표현이 생성된다.
1408에서, 아이템의 진위가 적절한 인증 프로세스를 통해 결정된다. 실시예들에서, 아이템의 인증은 주제 인증 전문가에 의해 액세스될 수 있는 포털을 통해 요청될 수 있다. 이들 실시예들에서, 포털은 또한, 아이템의 가상 표현을 디스플레이할 수 있다. 예를 들어, 주제 전문가에게는, 아이템의 이미지, 아이템의 설명(예를 들어, 무게, 치수 등), 아이템의 비디오, 및/또는 기타 등등이 프리젠팅될 수 있다. 그 다음, 인증 보고가 처리 시스템에 의해 수신될 수 있다. 인증 보고는 주제 인증 전문가에 의해 제공될 수 있고, 주제 인증 전문가가 아이템을 진품 또는 비진품이라고 간주하는지를 나타내는 의견 및 그 의견에 대한 하나 이상의 이유를 포함할 수 있다. 일부 실시예에서, 플랫폼은 아이템이 진품이라고 간주됨을 나타내는 의견에 응답하여 디지털 토큰을 생성하고, 디지털 토큰의 소유권은 아이템의 소유자에게 할당된다. 디지털 토큰은 아이템의 가상 표현에 기초할 수 있다.
도 15는 VR 환경을 렌더링하기 위한 기술(1500)을 보여주는 플로차트를 도시한다. 위에서 논의된 것들 등의 적절한 프로세스를 이용하여 1502에서 원장 데이터가 유지된다. 1504에서, 환경이 렌더링된다. 실시예들에서, 사용자가 가용 아이템의 가상 현실 시각화를 보고 가용 아이템의 인스턴스에 대해 거래하는 것을 허용하는 인터페이스를 제공하는 가상 현실 상점 환경이 렌더링된다. 가용 아이템은 거래에 이용가능한 아이템이다. 또한, 가상 표현에 의해 표현된 아이템의 가상 현실 시각화가 가상 현실 상점 환경 내에 역시 포함될 수 있다. 1506에서, 가상 환경 내의 아이템은 적절한 프로세스를 통해 거래된다. 예를 들어, 아이템의 인스턴스에 대한 거래 참여 요청이 거래 사용자의 사용자 디바이스로부터 플랫폼(100)에 의해 수신된다. 실시예들에서, 거래 참여 요청은, 거래 사용자가 가상 현실 상점 환경에서 아이템의 가상 현실 표현을 보는 것에 응답하여 수신된다. 요청과 연관된 정보가 확인될 수 있고, 가상 표현에 대응하는 특정한 토큰은 거래 참여 요청을 확인하는 것에 응답하여 거래 사용자의 계정과 연관된다.
도 16은 본 개시내용의 일부 실시예에 따른 블록들의 사이드 체인을 갖는 분산형 원장을 이용하여 거래를 용이화하기 위한 기술(1600)을 보여주는 플로차트를 나타낸다.
1602에서, 원장이 유지된다. 원장은 블록들의 메인 체인과 블록들의 사이드 체인을 포함한다. 실시예들에서, 메인 체인의 블록들은 아이템 제공자와 아이템 소비자 양쪽 모두를 포함하는 복수의 사용자와 관련된 정보를 집합적으로 저장한다. 복수의 사용자에 관한 정보는 복수의 공개 주소를 포함하고, 각각의 개개 공개 주소는 토큰화 플랫폼의 개개 사용자의 개개 계정에 대응한다. 사이드 체인의 블록들은, 복수의 개개의 아이템의 복수의 가상 표현, 각각의 가상 표현에 대한 토큰 세트, 및 각각의 개개의 토큰의 소유권 데이터를 집합적으로 저장한다. 각각의 가상 표현은 개개의 아이템의 가상 현실 시각화를 렌더링하기 위한 가상 현실 콘텐츠를 포함하고, 각각의 토큰 세트는 가상 표현에 의해 표현된 아이템의 개개의 인스턴스에 각각 대응한다.
1604에서, 위에서 설명한 것들 등의 적절한 프로세스를 통해 거래 요청이 수신된다. 1606에서, 아이템의 거래가 발생한다. 실시예들에서, 블록들의 제1 사이드 체인에서 가상 표현에 대응하는 특정한 토큰의 소유권 데이터가 거래 사용자가 특정한 토큰을 소유하고 있다는 것을 나타내도록 업데이트된다. 실시예들에서, 아이템의 거래는, 디지털 토큰 식별자 및 블록들의 제1 체인에 기초하여 특정한 토큰을 유효성확인하는 것, 상이한 사용자가 토큰화 플랫폼에서 유효한 계정을 가지고 있음을 사용자의 공개 주소 및 블록들의 메인 체인에 기초하여 확인하는 것, 및 특정한 토큰을 유효성확인하고 상이한 사용자를 확인하는 것에 응답하여, 블록들의 제2 체인을 새로운 블록으로 업데이트하는 것을 포함한다. 새로운 블록은, 가상 표현에 대응하는 특정한 토큰이 상이한 사용자에 의해 소유되어 있음을 나타내는 소유권 데이터를 포함한다.
도 17은 본 개시내용의 일부 실시예에 따른 사용자 취득을 용이화하기 위한 기술(1700)을 보여주는 플로차트를 도시한다. 1702에서, 토큰화 플랫폼의 사용자에 대응하는 추천 코드가 생성된다. 추천 코드는 토큰화 플랫폼의 처리 시스템에 의해 생성될 수 있다. 1704에서, 토큰화 플랫폼의 사용자에 대응하는 스마트 계약의 인스턴스가 생성된다. 스마트 계약의 인스턴스는 토큰화 플랫폼에 의해 생성될 수 있다. 스마트 계약의 인스턴스는 사용자가 토큰화 플랫폼을 성공적으로 참조할 때 사용자에게 제공할 인센티브를 나타낸다. 1706에서, 스마트 계약의 인스턴스는 처리 시스템에 의해 배치된다. 1708에서, 처리 시스템에 의해 새로운 사용자로부터 새로운 계정 생성 요청이 수신된다. 요청은 사용자의 추천 코드를 포함한다. 1710에서, 처리 시스템에 의해 새로운 사용자에 대한 새로운 계정이 생성된다. 1712에서, 처리 시스템은 사용자에 대응하는 스마트 계약의 인스턴스에 새로운 계정의 통보를 제공한다. 그 다음, 스마트 계약은 통보에 응답하여 인센티브를 나타내는 토큰 이전을 용이화한다.
도 18은 본 개시내용의 일부 실시예에 따른 미스터리 박스를 관리하기 위한 기술(1800)을 보여주는 플로차트를 도시한다. 1802에서, 미스터리 박스 생성 요청이 처리 시스템에 의해 수신된다. 1804에서, 미스터리 박스에 포함될 토큰 세트가 처리 시스템에 의해 수신된다. 토큰 세트 내의 각각의 토큰은 개개의 아이템을 나타내며 그에 할당된 확률을 갖는다. 확률은 개개 아이템의 획득 확률을 나타낸다.
1806에서, 미스터리 박스는 토큰 세트와 이에 할당된 확률에 기초하여 처리 시스템에 의해 생성된다. 토큰 세트 내의 각각의 토큰은, 값들의 간격에 관한 값들의 범위가 토큰에 할당된 확률에 비례하도록 값들의 간격 내의 값들의 범위를 할당받는다.
1808에서, 처리 시스템에 의해 스마트 계약의 인스턴스가 생성된다. 스마트 계약은 미스터리 박스와 연관되며, 미스터리 박스의 지원으로서 토큰 세트로부터의 토큰의 이전을 관할한다. 1810에서, 스마트 계약의 인스턴스는 처리 시스템에 의해 배치된다.
도 19는 본 개시내용의 일부 실시예에 따른 비디오 게임 통합을 위한 기술(1900)을 보여주는 플로차트를 도시한다. 1902에서, 가용 토큰의 인벤토리가 유지된다. 가용 토큰은 비디오 게임 내의 통합에 이용가능하다. 토큰 인벤토리 내의 각각의 토큰은 개개의 아이템을 나타낸다. 1904에서, 디지털 토큰에 대한 토큰 요청이 처리 시스템에 의해 수신된다. 디지털 토큰은 API를 통해 비디오 게임의 인스턴스로부터 나온다. 1906에서, 처리 시스템은 토큰 요청에 기초하여 가용 토큰들의 인벤토리로부터 디지털 토큰을 선택한다. 1908에서, 토큰의 표시자가 처리 시스템에 의해 비디오 게임의 인스턴스에 제공된다. 1910에서, 처리 시스템은 비디오 게임의 인스턴스로부터 거래 요청을 수신한다. 거래 요청은, 비디오 게임의 인스턴스에 제공된 토큰을 비디오 게임의 인스턴스의 사용자 계정으로 이전할 것을 요청하도록 구성된다. 1912에서, 원장은 사용자가 토큰의 소유자임을 반영하도록 업데이트된다.
도 20은 증권화된 탈집중형 대출 프로세스들("탈집중형 대출 프로세스", "증권화된 대출 프로세스" 또는 "대출 프로세스"라고도 지칭됨)을 용이화하기 위한 예시적인 생태계(2000)를 나타낸다. 증권화된 탈집중형 대출 프로세스란, 차용자가 무신용 또는 실질적 무신용 방식으로 하나 이상의 물리적 아이템을 담보화할 수 있고 대출자는 무신용 또는 실질적 무신용 방식으로 차용자에게 돈을 대출할 수 있게 하도록(예를 들어, 담보 아이템을 개인적으로 인증, 평가, 보관 및/또는 청산할 필요없이), 일련의 참여자들(예를 들어, 컴퓨팅 시스템들(100, 2014) 및 디바이스들(2002, 2004, 2006, 2008, 2010))과 분산형 원장 세트(2016)에서 호스팅되는 한 세트의 스마트 계약들 사이에 분산되는 프로세스를 지칭할 수 있다. 특히, 공개된 생태계 및 이를 지원하는 시스템들 및 방법들은 차용자가 물리적 아이템을 디지털 담보 토큰(2042)으로 디지털적으로 담보화하는 것을 허용하는 메커니즘을 제공하여, 디지털 담보 토큰(2042)이 스마트 계약들을 이용하여 대출자로부터 대출을 확보하는데 이용될 수 있게 한다. 실시예들에서, 탈집중형 대출 프로세스의 스테이지들은 다음 중 하나 이상을 포함할 수 있다: 차용자가 대출 프로세스를 요청하는 요청 스테이지; 담보 아이템이 하나 이상의 인증자에 의해 인증되는 인증 스테이지; 담보 아이템이 하나 이상의 평가자에 의해 평가되는 평가 스테이지; 대출 프로세스의 한 인스턴스가 종료될 때까지 담보 아이템을 보관자에게 예치하는 보관 스테이지; 담보 아이템에 대응하는 VIRL이 생성되는 가상화 스테이지; VIRL이 담보 토큰(2042)으로 토큰화되는 토큰화 스테이지; 차용자가 대출을 요청하고/하거나 대출의 조건들을 하나 이상의 잠재적 대출자와 협상할 수 있고 차용자와 대출자가 거래의 조건들에 합의하고 대출 프로세스가 완료될 때까지 담보 토큰을 에스크로 계정 내에 잠금처리하는 대출 요청 스테이지; 대출금이 차용자에 의해 상환되거나 채무불이행되는 대출 상환 스테이지; 및 대출이 성공적으로 상환된 경우 담보 토큰(2042)이 차용자에게 다시 이전되거나 차용자가 채무불이행인 경우 구매자에게 청산되거나, 담보 토큰이 보관자의 담보 아이템에 대해 상환되거나, 및/또는 임의의 대출후 분석이 수행되는 대출후 스테이지 중 하나 이상을 포함할 수 있다.
일부 예시적인 실시예에서, 토큰화 플랫폼(100)은 증권화된 탈집중형 대출 프로세스를 지원한다. 이들 예시적인 실시예에서, 시장 시스템(102), 원장 관리 시스템(104), 담보 관리 시스템(802), 인증 시스템(804), 및 분석 및 보고 시스템(112)은, 한 세트의 노드 디바이스들(2014)에 의해 호스팅되는 한 세트의 분산형 원장들(2016)에 관하여 탈집중형 대출 프로세스를 용이화하는데 있어서, 한 세트의 사용자 디바이스들(예를 들어, 차용자 디바이스들(2002), 인증자 디바이스들(2004), 평가자 디바이스들(2006), 보관자 디바이스들(2008), 및/또는 대출자 디바이스들(2010))과 인터페이스하도록 구성될 수 있다. 실시예들에서, 증권화된 탈집중형 대출 생태계(2000)는 증권화 탈집중형 대출 프로세스의 상이한 스테이지들에 참여하는 다수의 상이한 참여자들을 포함한다. 일부 실시예에서, 대출 참여자들은, 물리적 담보 아이템들을 이용하여 대출을 받으려는 차용자들, 물리적 담보 아이템들을 인증하는 인증자들, 물리적 담보 아이템들을 평가하는 평가자들, 물리적 담보 아이템들을 안전하게 보관하는 보관자들, 차용자들에게 통화를 빌려주는 대출자들뿐만 아니라, 분산형 원장 생태계를 지원하는 다른 적절한 참여자들(예를 들어, "채굴자" 및/또는 분산형 원장 노드 디바이스 2014)을 포함할 수 있다. 논의되는 바와 같이, 일부 유형의 참여자들은, 인증, 평가 및 보관 등의 특정한 스테이지에 관련된 해당 주제 전문지식을 가진 엔티티들(예를 들어, 개인들 및/또는 기업들)의 그룹들인 길드들로 조직화될 수 있다. 증권화된 분산형 생태계(2000)의 참여자들은, 랩탑 컴퓨터들, 데스크탑 컴퓨터들, 태블릿들, 비디오 게임 콘솔들, 서버 컴퓨터들, 및/또는 기타 등등의, 다양한 컴퓨팅 디바이스를 통해 서로 및 분산형 원장(들)(2106)과 상호작용할 수 있다는 것을 이해할 것이다. 설명의 목적을 위해, 차용자는 차용자 디바이스(2002)를 통해 생태계(2000)에 참여하고, 인증자는 인증자 디바이스(2004)를 통해 생태계(2000)에 참여하고, 평가자는 평가자 디바이스(2006)를 통해 생태계(2000)에 참여하고, 보관자는 보관자 디바이스(2008)를 통해 생태계(2000)에 참여하고, 대출자는 대출자 디바이스(2010)를 통해 생태계(2000)에 참여하는 등등이다.
실시예들에서, 증권화된 탈집중형 대출 프로세스는 노드 디바이스들(2014)의 네트워크에 의해 호스팅되는 한 세트의 분산형 원장들(2016)을 이용하여 적어도 부분적으로 구현될 수 있고, 여기서 노드 디바이스들(2014)은, 하나 이상의 담보 아이템의 인증, 평가 및/또는 증권화를 관리하는 하나 이상의 스마트 계약을 포함한, 증권화된 대출 프로세스와 관련하여 생성되는 스마트 계약 인스턴스들을 실행한다. 일부 실시예에서, 탈집중형 대출 프로세스의 하나 이상의 스테이지는 대응하는 세트의 스마트 계약들에 의해 관리된다. 일반적으로, 스마트 계약은, 실행될 때 하나 이상의 동작을 트리거하는 조건부 로직을 실행하는 컴퓨터 실행가능한 코드를 포함할 수 있다. 스마트 계약은 하나 이상의 데이터 소스로부터 데이터를 수신할 수 있고, 이에 따라 조건부 로직은 데이터를 분석하여 소정의 조건이 충족되는지를 결정하고, 충족되는 경우, 하나 이상의 대응하는 동작을 트리거한다. 본 개시내용 전반에 걸쳐, 조건부 로직과 동작의 트리거링의 예를 포함한, 스마트 계약들의 예들이 논의된다. 실시예들에서, 스마트 계약들은, Ethereum 프로토콜, WAX 프로토콜 등의 하나 이상의 프로토콜에 따라 정의될 수 있다. 스마트 계약들은 컴퓨터 실행가능한 코드로서 구현될 수 있고, Solidity, Golang, Java™, JavaScript™, C++ 등의 적절한 프로그래밍 언어로 작성될 수 있다. 증권화된 탈집중화의 다양한 실시예와 관련하여 이용될 수 있는 스마트 계약의 다양한 예가 본 개시내용 전체에 걸쳐 논의된다. 도 20의 예시적인 실시예들에서, 분산형 원장(2016)은 저장될 수 있고 노드 디바이스들(2014)은, 대출 프로세스 스마트 계약들(2022), 스테이지-레벨 거버넌스 스마트 계약들(2024), 길드 거버넌스 스마트 계약들(2026), 인증 스마트 계약들(2028), 평가 스마트 계약들(2030), 보관 스마트 계약들(2032), 대출 스마트 계약들(2034), 및/또는 기타의 적절한 스마트 계약들의 인스턴스들을 실행할 수 있다. 상이한 유형들의 스마트 계약들이 본 개시내용 전반에 걸쳐 논의된다.
실시예들에서, 분산형 원장들(2016)은, 탈집중형 대출 프로세스와 관련하여 생성되고 대출을 확보하기 위해 담보로서 유지되는 담보 토큰(2042), 탈집중형 대출 프로세스와 관련하여 소정의 작업을 수행하는 길드 멤버들에 의해 소유되고/되거나 이용되는(이하에서 논의되는 바와 같이, 길드 멤버들에 의해 투표에 이용될 수 있는) 길드 토큰들(2044), 탈집중형 대출 프로세스와 관련하여 이용되는 (예를 들어, 대출, 상환, 보상, 위험부담성 출자 등을 위한) 통화/토큰화된 토큰들(2046), 및 기타의 적절한 토큰들을 포함한 그러나 이것으로 제한되지 않는 토큰들을, 탈집중형 대출 프로세스와 관련하여 이용되는 토큰들을 저장할 수 있다. 실시예들에서, 담보 토큰(2042)은, 탈집중형 대출 프로세스에서 대출을 증권화하는데 이용되는 하나 이상의 개개의 담보 아이템의 물리적 아이템(VIRL)의 하나 이상의 가상 표현을 포장하는 디지털 토큰일 수 있다. 실시예들에서, VIRL은 물리적 아이템에 대응하고, 아이템의 설명들, 아이템의 사진들, 아이템의 비디오들 등을 포함할 수 있다. 물리적 아이템들의 가상 표현(VIRL)은 본 개시내용 전반에 걸쳐 논의된다. 실시예들에서, 담보 토큰(2042)은 스마트 계약 래퍼를 포함할 수 있되, 담보 토큰의 소유자(대출이 상환된 후 및/또는 청산 이벤트 후에 담보 토큰의 소유권 기록으로부터 결정됨)가 (위에서 논의된 바와 같이) 토큰을 상환할 때, 담보 토큰(2042)과 연관된 스마트 계약이 담보 아이템을 제공하는 담보 토큰(2042)에 의해 표현되는 담보 아이템의 보관자에게 통보를 제공할 수 있게 한다. 일단 담보 토큰(2042)의 보유자가 담보 아이템의 소유하고 있다는 것을 보관자가 확인하고 나면, 담보 토큰(2042)의 스마트 계약은, 전술된 바와 같이, 상환된 담보 토큰(2042)을 소각할 수 있다. 통화 토큰들이란, 통화로서 이용되는 디지털 토큰을 지칭할 수 있다. 통화 토큰들의 예들로는, Bitcoin 토큰, Ethereum 토큰, Ripple 토큰, Wax 토큰 등이 포함될 수 있다. 일부 실시예에서, 토큰화된 토큰이란, 소정 금액의 통화(예를 들어, 통화 토큰 및/또는 법정 통화)를 "포장"하는 디지털 토큰을 지칭한다. 토큰화된 토큰이 생성될 때, 소정 금액의 통화가 에스크로잉되고 토큰화된 토큰은 에스크로잉된 통화량에 대한 소유권을 나타내어, 토큰화된 토큰이 토큰화된 토큰의 확인된 소유자에 의해 상환될 때, 그 소유자가 에스크로잉된 통화량을 소유할 수 있게 한다. 통화 토큰들과 토큰화된 토큰들 양쪽 모두는 통화를 나타내므로, "통화/토큰화된" 토큰들이라는 용어의 사용은, 통화 토큰들, 토큰화된 토큰들, 또는 통화 토큰들과 토큰화된 토큰들의 조합을 나타낼 수 있다.
실시예에서, 분산형 원장들(2016)은, 이벤트 기록들(2052), 소유권 데이터(2054), 및/또는 지원 데이터(2056) 등의 추가적인 데이터를 저장할 수 있다. 이벤트 기록들(2052)은 탈집중형 대출 프로세스와 관련하여 발생하는 임의의 이벤트를 기억하는 기록들을 포함할 수 있다. 이벤트 기록들(2052)은 다음과 같은 이벤트들의 기록들을 포함할 수 있지만 이것으로 제한되는 것은 아니다: 대출 프로세스에 대한 차용자의 요청, 인증 작업 할당, 인증 작업 완료, 평가 작업 할당, 평가 작업 완료, 보관 작업 할당, 보관 작업 완료, 차용자의 대출 요청, 대출자에 의한 대출 수락, 차용자가 대출 합의에 들어가는 것에 응답하여 에스크로에 잠금처리되는 차용자의 담보 토큰의 잠금, 차용자가 대출자에게 지불한 금액, 차용자의 지불 누락, 현재 대출자로부터 보조 대출자로의 대출 계약의 이전, 차용자에 의한 채무불이행인 것으로 결정된 대출, 청산 이벤트 발생, 차용자가 전액 상환한 대출, 탈집중형 프로세스에서 참여자들에게 수여되는 보상들, 청산 이벤트 후 가짜로 간주된 아이템, 청산 이벤트 동안 평가 가치에 도달하지 못한 아이템 등. 실시예들에서, 이벤트 기록은, 토큰화 플랫폼(100), 차용자 디바이스들(2002), 인증자 디바이스들(2004), 평가자 디바이스들(2006), 보관자 디바이스들(2008), 대출자 디바이스들(2010), (예를 들어, 노드 디바이스들(2014)에 의해 실행되는 스마트 계약별의) 노드 디바이스들(2014), 또는 기타의 적절한 디바이스들 등의 생태계(2000) 내의 임의의 적절한 컴퓨팅 디바이스에 의해 생성될 수 있다. 실시예들에서, 이벤트 기록(2052)은 해시 값을 획득하기 위해 해시 함수를 이용하여 해시될 수 있다. 이벤트 기록(2052)은 데이터 블록에 기입되고 분산형 원장에 저장될 수 있으며, 여기서 데이터 블록은 해시 값을 포함할 수 있다. 이러한 방식으로, 이벤트 기록(2052) 내의 데이터는 이벤트 기록(2052)의 해시 값을 변경하지 않고서는 변경될 수 없으므로, 이벤트 기록(2052)을 변경불가로 만든다. 일단 이벤트 기록(2052)을 포함하는 블록이 분산형 원장에 저장되고 나면, 이벤트 기록(2052)은 분산형 원장(2016)에 관한 블록의 주소를 이용하여 참조될 수 있다.
실시예들에서, 지원 데이터(2056)는, 수행된 작업 또는 탈집중형 대출 프로세스 및/또는 탈집중형 대출 프로세스의 참여자들과 관련하여 발생하는 기타의 이벤트를 지원하기 위해 제공되는 문서 및 데이터일 수 있다. 논의되는 바와 같이, 지원 데이터(2056)는, 인증 보고 및 지원 사진, 비디오, 스캔 등; 평가 보고 및 지원 사진, 비디오, 스캔 등; 보관 보고 및 지원 사진, 비디오, 스캔 등; 대출 계약 협상 동안의 협상 이벤트를 나타내는 대출 협상 기록; 차용자에 대한 대출자의 지출 이벤트에 대응하는 지출 기록; 대출자에 의한 지불 이벤트를 나타내는 상환 기록; 채무불이행 이벤트를 나타내는 채무불이행 기록; 및/또는 기타의 적절한 데이터를 포함할 수 있다.
실시예들에서, 소유권 데이터(2054)는, 토큰(예를 들어, 담보 토큰들(2042), 통화/토큰화된 토큰들(2046), 및/또는 길드 토큰들(2044))을 계정과 연관시키는 데이터를 포함할 수 있다. 실시예들에서, 소유권 데이터(2054)는 데이터 블록들에 저장될 수 있고, 여기서 데이터 블록은 토큰 주소와 계정 주소 사이의 링크를 포함할 수 있다. 예를 들어, Bob이 10개의 통화 토큰(예를 들어, 비트 코인)을 소유하는 경우, 각각의 토큰의 소유권 데이터(2054)는 분산형 원장에 저장될 수 있고 각각의 토큰들을 Bob과 연관된 계정에 링크할 수 있다. Bob이 Alice로부터 아이템을 구매하기 위해 이들 토큰들(2046) 중 하나를 이용하는 경우, 토큰의 소유권 데이터(2054)는 아이템을 구매하는데 이용된 토큰(2046)을 Alice의 계정에 링크하도록 업데이트될 수 있다. 소유권이 새로운 계정으로 변경되면, 토큰을 새로운 계정과 링크하는 분산형 원장(2016)에 대해 새로운 블록이 수정될 수 있다. 실시예에서, 토큰들(예를 들어, 담보 토큰들(2042), 및/또는 통화/토큰화 토큰들(2046))은 대출 프로세스 동안 잠금처리될 수 있다. 여기서 사용될 때, 토큰을 "잠금처리하는 것"은, 에스크로 계정에 토큰을 저장하는 것을 의미할 수 있고(예를 들어, 에스크로 토큰들을 저장하는 분산형 원장 상에서), 잠금처리된 토큰은, 그 토큰과 연관된 스마트 계약이 토큰이 잠금해제되었다고 결정하지 않는 한 에스크로 계정으로부터 이전될 수 없다. 실시예들에서, 담보 토큰은, 예를 들어, 차용자와 대출자가 대출 조건에 동의할 때 "잠금처리"될 수 있다. 일부 실시예에서, 참여자들(예를 들어, 인증자들, 평가자들, 및/또는 보관자들)에 속하는 소정 금액의 통화/토큰화된 토큰들(2046)은, 참여자들이 대출을 확보하는 것과 관련하여 소정의 작업들(예를 들어, 인증 작업들, 평가 작업들, 및 보관 작업들)을 수행할 때 잠금처리될 수 있어서 참여자들이 성실하게 대출 프로세스에 참여하게끔 인센티브를 제공한다(예를 들어, 담보 아이템을 인증하지 않는 측의 오류, 평가에 대한 보상을 증가시키기 위해 담보 아이템을 과대 평가하지 않는 것, 및 담보 아이템 속성을 저장하는 것). 토큰이 "잠금처리"되면 신뢰할 수 있는 제3자(예를 들어, 토큰화 플랫폼(100))에 의해 관리되는 에스크로 계정에 토큰을 링크하는 소유권 데이터(2054)가 분산형 원장에 추가될 수 있다. 일단 에스크로 계정에 잠금처리되고 나면, 잠금해제되지 않는 한, 토큰은 상환되거나 이전될수 없다. 일단 토큰의 소유권 변경(예를 들어, 대출의 적어도 일부 상환)을 트리거하는 이벤트가 발생하고 나면, 토큰의 소유권 데이터(2054)는 소유권 데이터(2054)를 저장하는 분산형 원장(2016)에서 업데이트되어 토큰이 정당한 소유자(예를 들어, 차용자, 참여자, 토큰의 구매자 등)에 의해 소유된다는 것을 반영함으로써, 토큰을 잠금해제할 수 있다. 일부 실시예에서, 담보 토큰(2054)이 잠금처리되면, 물리적 아이템의 소유자는 가상 환경에서 아이템의 가상 표현을 이용하는 것이 금지될 수 있다. 예를 들어, VIRL을 통해 비디오 게임에 결속된 물리적 아이템의 소유자(예를 들어, 신발 소유자는, 비디오 게임에서 이용될 때, 비디오 게임에서, 더 빨리 달리거나 더 높이 뛰는 것 등의, 특별한 피처들을 소유자에게 부여하는 신발의 VIRL도 소유한다)가 여기서 설명된 기술들을 이용하여 물리적 아이템을 담보화하고 결과적인 담보 토큰(2042)을 에스크로 계정에 잠금처리하면, 담보 토큰의 잠금처리는, 결과적으로, 사용자가 비디오 게임에서 물리적 아이템의 VIRL을 이용하는 것을 금지할 것이다. 실시예들에서, 시장, 비디오 게임, 소셜 미디어 플랫폼 등의 외부 가상 환경은, VIRL의 소유권 데이터(2054)를 획득하기 위해 분산형 원장을 조회하도록 구성될 수 있다. VIRL이 에스크로에 보관된 담보 토큰(2042)에서 포장되면, 가상 환경은 대응하는 담보 토큰이 에스크로에 보관되어 있다고 결정할 수 있고, 사용자가 VIRL을 소유하고 있다는 것을 VIRL의 소유권 데이터(2054)가 나타낼 때까지 사용자가 가상 환경에서 VIRL을 이용하는 것을 금지할 수 있다.
추가로, 분산형 원장들(2016), 이벤트 기록들(2052), 소유권 데이터(2054), 지원 데이터(2056) 및 탈집중형 대출 프로세스를 지원하는 기타 적절한 데이터가, 비분산형 데이터 저장소들, 파일 시스템들, 데이터베이스들 등에 저장될 수 있다는 점에 유의한다. 예를 들어, 실시예들에서, 토큰화 플랫폼(100)은, 이벤트 기록들(2052), 소유권 데이터(2054), 지원 데이터(2056) 및 탈집중형 대출 프로세스를 지원하는 다른 적절한 데이터를 저장하는 데이터 저장소들을 유지할 수 있다.
실시예들에서, 탈집중형 대출 프로세스에서의 참여자들(예를 들어, 인증자들, 평가자들, 보관자들 등)의 소정의 그룹들은, 증권화된 탈집중형 대출 프로세스를 용이화하도록 정의된 한 세트의 거버넌스에 따라 한 영역의 공통 전문지식에 기초하여 길드들을 형성하거나 길드들로 조직화될 수 있다. 일반적으로, 길드 형성, 멤버쉽, 그 운영뿐만 아니라, 대출 프로세스 및 대출 프로세스를 용이화하기 위한 메커니즘들 동안에 수행된 거래들(및 기타의 이벤트들)은 한 세트의 거버넌스들을 준수한다. 거버넌스들이란, 대출 프로세스의 하나 이상의 양태들과 참여자들이 준수하는 각각의 세트들의 규칙들 및/또는 규정들을 지칭할 수 있다. 실시예들에서, 거버넌스는, 분산형 원장 및/또는 중앙집중형 컴퓨팅 시스템(예를 들어, 토큰화 플랫폼)에 저장된 한 세트의 파일들 및/또는 문서들(예를 들어, 거버넌스 문서들)에서 정의될 수 있다. 일부 실시예에서, 거버넌스는, 중앙집중형 컴퓨팅 시스템(예를 들어, 토큰화 플랫폼(100))에 의해 실행되는 스마트 계약들 및/또는 소프트웨어 애플리케이션들의 이용에 의해 시행될 수 있다. 실시예들에서, 거버넌스 세트는, 전체 대출 프로세스(예를 들어, 모든 거래, 및 대출 프로세스에 참여하는 모든 참여자들)에 적용되는 시스템-레벨 거버넌스, 대출 프로세스의 특정한 스테이지(또는 스테이지 세트) 및 그 특정한 스테이지(또는 스테이지 세트) 동안에 수행되는 거래들에 참여하는 참여자들에게 적용되는 스테이지-레벨 거버넌스들, 각각의 스테이지 및/또는 길드 멤버들이 참여하는 거래들에 참여하는 각각의 길드들에 적용되는 길드-레벨 거버넌스들, 및/또는 각각의 길드들로부터 형성된 각각의 하위 길드들 및 하위 길드 멤버들이 참여하는 거래들에 적용되는 하위 길드 거버넌스들을 포함할 수 있다. 실시예들에서, 거버넌스 세트는 계층적이며, 이에 따라 시스템-레벨 거버넌스는 대출 프로세스의 각각의 스테이지들에 대응하는 스테이지-레벨 거버넌스들보다 우선하고, 각각의 스테이지의 스테이지-레벨 거버넌스는 각각의 스테이지에 참여하는 각각의 길드들의 길드-레벨 거버넌스들보다 우선하며, 각각의 길드의 길드-레벨 거버넌스는 각각의 길드 내에서 형성된 하위 길드들의 하위 길드 거버넌스들보다 우선한다. 다시 말해, 하위 길드의 하위 길드 거버넌스는, 하위 길드가 형성된 길드의 길드-레벨 거버넌스에서 제시된 규칙들 및 규정들을 확장하거나 더욱 정교화할 수 있지만 상충될 수는 없다; 길드-레벨 거버넌스는 길드가 참여하는 스테이지의 스테이지-레벨 거버넌스에서 제시된 규칙들과 규정들을 확장하거나 더 정교화할 수 있지만 상충될 수는 없고, 스테이지-레벨 거버넌스는, 시스템-레벨 거버넌스에서 제시된 규칙들과 규정들을 확장하거나 더 정교화할 수 있지만 상충될 수는 없다. 상이한 유형들의 거버넌스들이 요구되지 않으며 소정의 스테이지들 및 길드들은 본 개시내용의 범위를 벗어나지 않고 더 높은 레벨의 거버넌스(예를 들어, 시스템-레벨 거버넌스 또는 스테이지-레벨 거버넌스)을 준수할 수 있다는 것을 이해할 것이다.
논의된 바와 같이, "길드"라는 용어는, 분야 특유(예를 들어, 시계 인증, 운동화 평가, 귀중품 및/또는 부패하기 쉬운 아이템의 보관)일 수 있는 정의된 유형의 전문화된 작업(예를 들어, 특정한 유형들의 담보 아이템들에 대한 인증, 평가 및/또는 보관)을 수행하는 한 세트의 엔티티들(예를 들어, 개인들 또는 회사들)을 지칭할 수 있고, 이에 따라, 길드의 멤버들은 한 세트의 거버넌스들을 준수한다. 설명의 목적을 위해, 길드 멤버는 개인으로서 설명되지만, 조직은 동일한 분야의 전문지식을 가진 개인들로 구성될 수 있으므로 길드에 포함될 수 있다는 것을 이해할 것이다. 일부 실시예에서, 길드는 시스템-레벨 거버넌스, 길드가 참여하는 스테이지에 대응하는 스테이지-레벨 거버넌스, 및/또는 길드 멤버가 속한 길드의 길드-레벨 거버넌스를 준수해야 한다. 스테이지-레벨 거버넌스는, 스테이지(예를 들어, 인증 스테이지, 평가 스테이지, 보관 스테이지, 대출 스테이지 등)에 참여할 수 있는 모든 참여자와 관련된 규칙들 및 규정들을 정의할 수 있다. 예를 들어, 인증 스테이지-레벨 거버넌스는 탈집중형 대출 프로세스와 관련하여 인증 작업들을 수행하는 임의의 인증자들에게 적용될 수 있고, 평가 스테이지 거버넌스는 탈집중형 대출 프로세스와 관련하여 평가 작업을 수행하는 임의의 평가자들에게 적용될 수 있고, 보관 스테이지 거버넌스는 탈집중형 대출 프로세스와 관련하여 보관 작업을 수행하는 임의의 보관자들에게 적용될 수 있고, 대출 스테이지 거버넌스는 탈집중형 대출 프로세스에서 돈을 빌려주는 임의의 대출자들에게 적용될 수 있는 등등이다. 길드-레벨 거버넌스들은 특정한 스테이지에 참여하는 특정한 길드의 멤버들에 대한 규칙들과 규정들을 정의할 수 있다. 예를 들어, 시계 인증 길드 거버넌스는 시계 인증 길드의 멤버들에게만 관련될 수 있고, 핸드백 인증 길드 거버넌스는 핸드백 인증 길드의 멤버들에게만 관련될 수 있으며, 보석 인증 길드 거버넌스는 보석 인증 길드의 멤버들에게만 관련될 수 있고, 시계 평가 길드 거버넌스는 시계 평가 길드의 멤버들에게만 관련될 수 있고, 핸드백 평가 길드 거버넌스는 핸드백 평가 길드의 멤버들에게만 관련될 수 있고, 운동화 평가 길드 거버넌스는 운동화 평가 길드의 멤버들에게만 관련될 수 있는 등등이다. 실시예들에서, 스테이지-레벨 길드 거버넌스는 다음 중 하나 이상을 정의할 수 있다: 길드들이 생성될 수 있는 방식, 길드 멤버들이 길드에 추가되는 방식; 길드로부터 길드 멤버가 제거되는 방식, 거버넌스를 수정하는데 관해 길드 멤버들이 투표하는 방식, 워크플로우들, 스마트 계약들, 및/또는 각각의 길드에 의해 수행되는 소정의 작업들(예를 들어, 평가들, 인증들, 보관 등)과 관련된 문서들; 투표 메커니즘 등. 논의된 바와 같이, 거버넌스 세트들은 본질적으로 계층적일 수 있으므로, 하위-레벨 거버넌스들이 상위-레벨 거버넌스들을 준수하고/하거나 상충되지 않도록 요구된다. 예를 들어, 인증 스테이지-레벨 거버넌스는 모든 인증자에게 적용되는 한 세트의 규칙들 및 규정들을 정의할 수 있고, 길드-레벨 거버넌스는 더 넓은 그룹의 인증자들(예를 들어, 모든 인증자들) 내의 각각의 길드(예를 들어, 시계 인증 길드 또는 보석 인증 길드)에게 적용되는 한 세트의 규칙들, 권장사항들, 및/또는 규정을 정의할 수 있다. 이 예에서, 길드-레벨 거버넌스는 스테이지-레벨 거버넌스를 준수하고 이와 상충되지 않도록 요구될 수 있지만, 스테이지-레벨 거버넌스에서 규칙들 및/또는 규정들을 정교화할 수 있을 뿐만 아니라 스테이지-레벨 거버넌스에서 정의되지 않았던 새로운 규칙들 및/또는 규정들을 추가할 수 있다. 예를 들어, 예시적인 인증 스테이지-레벨 거버넌스는, 인증자들이 길드 멤버에 의해 수행된 각각의 인증 작업에 대해 적어도 소정 금액의 자금들(예를 들어, 대출 금액의 절반)을 임시로 위험부담성 출자(stake)할 것을 요구할 수 있다. 이 예에서, 인증 길드(예를 들어, 시계 인증 길드)의 길드-레벨 거버넌스는, 길드 멤버들에 의해 수행되는 인증 작업들과 관련하여 적어도 인증 스테이지-레벨 거버넌스에서 정의된 자금의 양을 위험부담성 출자할 것을 길드 멤버들에게 요구해야 하지만, 길드-레벨 거버넌스는 인증 스테이지-레벨 거버넌스에서 정의된 금액보다 더 많은 금액(예를 들어, 전체 대출 금액)이 요구할 수 있다. 또 다른 예에서, 평가 스테이지-레벨 거버넌스는 평가자들이 평가에 대한 문서 지원을 제공할 것을 요구할 수 있고, 평가자들의 특정한 길드와 관련된 길드-레벨 평가자 거버넌스는 길드 멤버에 의해 수행되는 평가를 지원하기 위해 어떤 문서가 제공되어야 하는지를 더욱 정교화할 수 있다. 거버넌스 규칙들, 권장사항, 및/또는 규정들의 추가 예들이 본 개시내용 전반에 걸쳐 제공된다.
일부 실시예에서, 길드에 대한 멤버쉽은 길드의 스테이지-레벨 및/또는 길드-레벨 거버넌스에 따라 기존 길드 멤버들에 의해 적어도 부분적으로 결정된다. 예를 들어, 예시적인 실시예들에서, 길드의 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스는, 길드 멤버가 길드에 추가될 길드에 없는 개인을 지명할 수 있고 길드의 멤버들은 길드에 대한 엔티티를 허용하거나 거부하기 위해 투표할 수 있고, 길드에 새로운 멤버를 지명, 투표 및 허용하는 방법에 대한 메커니즘을 더 포함할 수 있다는 사항을 제공할 수 있다. 따라서, 길드에 신규 멤버를 추가하기 위해, 기존의 길드 멤버들은 통제 거버넌스에 따라 지명 및 투표 프로세스를 수행해야 한다. 일부 실시예에서, 투표는 길드 거버넌스 스마트 계약(2026)을 이용하여 관리될 수 있다. 길드 거버넌스 스마트 계약(2026)이란, 길드-레벨 거버넌스 및/또는 스테이지-레벨 거버넌스 수정에 관한 투표, 길드에 새로운 멤버 추가에 관한 투표, 길드로부터 멤버들의 제거에 관한 투표, 길드 멤버들에게 길드 토큰(2044)의 발행 및/또는 기타 등등 길드의 관리 작업들을 관리하도록 구성된 스마트 계약을 지칭할 수 있다(길드 거버넌스 스마트 계약(2026)이 가장 광범위한 길드에 속하는 경우). 이들 실시예들 중 일부에서, 길드에 포함시킬 새로운 멤버를 투표하는데 이용되는 길드 거버넌스 스마트 계약(2026)은, 잠재적인 길드 멤버의 지명을 수신하고 소정의 조건이 충족되는지(예를 들어, 지명자가 지명하기에 충분히 높은 등급을 갖고 있는지, 지명자가 지명할 만큼 충분히 오랫동안 길드 멤버였는지, 지명자가 새로운 길드 멤버를 지명하기 위한 최소 수의 길드 토큰(2044) 또는 기타 유사한 상태 표시자를 갖고 있는지, 적절한 프로토콜이 이용되었는지, 및/또는 기타 등등)를 결정하는 조건부 로직을 포함할 수 있다. 지명이 유효하다고 확인하는 것에 응답하여, 길드 거버넌스 스마트 계약(2026)은 현재 길드 멤버들에게 투표를 요청하고 투표를 집계하는 동작을 실행할 수 있다. 일단 멤버가 투표되고 나면, 길드 거버넌스 스마트 계약(2026)은, 후보자가 길드에 허용될 만큼 충분한 투표수를 받았는지를 결정하도록 구성될 수 있다. 만일 그렇다면, 후보자는 길드에 추가된다. 만일 그렇지 않다면, 후보자는 길드에 대한 허용이 거부된다. 그렇게 함으로써, 길드 거버넌스 스마트 계약(2026)은 투표 결과 및/또는 새로운 멤버가 길드에 추가되었는지를 식별하는 하나 이상의 이벤트 기록(2052)을 생성할 수 있다. 실시예들에서, 이벤트 기록들(2052)은 분산형 원장(2016)에 기입될 수 있다. 길드 거버넌스 계약(2026)은, 새로운 멤버 길드 토큰(2044) 부여, 새로운 길드 멤버에 대한 프로필 생성, 작업들을 수행하기 위해 선택되는 길드 멤버의 명단에 새로운 길드 멤버를 추가하는 것, 및/또는 기타 등등의, 추가적인 동작들을 수행할 수 있다. 길드 멤버들은 본 개시내용의 범위를 벗어나지 않고 다른 방식들로 길드에 추가될 수 있다.
실시예들에서, 인증 길드는 특정한 유형(또는 유형들)의 아이템(들)을 인증하는 분야 특유의 전문지식을 가진 한 세트의 개인들 또는 조직들을 포함할 수 있다. 예를 들어, 시계 인증 길드는 시계를 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 신발 인증 길드는 신발을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 핸드백 인증 길드는 핸드백을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 예술품 인증 길드는 예술 작품을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 스포츠 기념품 길드는 스포츠 기념품을 인증하는 전문화된 지식이 있는 개인으로 구성될 수 있으며 스포츠 기념품을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 장난감 인증 길드는 수집 장난감을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 보석 인증 길드는 보석을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 의류 인증 길드는 디자이너 의류를 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 악기 인증 길드는 악기를 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 음반 인증 길드는 희귀 소장용 음반을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 와인 인증 길드는 와인 병을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 위스키 인증 길드는 위스키 병을 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 자동차 인증 길드는 한정판 자동차를 인증하는 전문지식을 가진 개인들로 구성될 수 있고, 기타 임의의 적절한 인증 길드가 있다.
실시예들에서, 평가 길드는 특정한 유형(또는 유형들)의 아이템(들)을 평가하는 도메인 특유의 전문지식을 가진 한 세트의 개인들 또는 조직들을 포함할 수 있다. 예를 들어, 시계 평가 길드는 시계를 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 신발 평가 길드는 신발을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 핸드백 평가 길드는 핸드백을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 예술품 평가 길드는 예술 작품을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 스포츠 기념품 평가 길드는 스포츠 기념품을 평가하는 전문화된 지식이 있는 개인으로 구성될 수 있으며 스포츠 기념품을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 장난감 평가 길드는 수집 장난감을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 보석 평가 길드는 보석을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 의류 평가 길드는 디자이너 의류를 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 악기 평가 길드는 악기와 장비를 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 음반 평가 길드는 희귀 소장용 음반을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 와인 평가 길드는 와인 병을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 위스키 평가 길드는 위스키 병을 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 자동차 평가 길드는 한정판 자동차를 평가하는 전문지식을 가진 개인들로 구성될 수 있고, 기타 임의의 적절한 평가 길드가 있다.
일부 길드 내에는, 다른 길드보다 훨씬 더 인기가 있고/있거나 추가적인 전문지식을 요구할 수 있는 상이한 등급들의 아이템이 있을 수 있다. 예를 들어, 시계 인증 길드 내에서, 시장에 나와 있는 이러한 시계의 수와 Rolex® 시계를 사칭하는 위조 시계의 수 때문에, 일부 길드에서 Rolex® 시계를 인증하라는 많은 수의 인증 요청이 있을 수 있다. 따라서, 일부 실시예에서, 일부 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스는, 하나 이상의 하위 길드가 형성될 수 있는 메커니즘을 제공할 수 있으며, 여기서 길드의 하위 길드는 길드의 전문기술 분야의 특정한 하위 도메인을 인증하는데 있어서 전문지식을 갖는 길드의 개개인들로 구성된다. 예를 들어, 시계 길드 내에는, Rolex® 시계, Omega® 시계, Hamilton® 시계 등의 상이한 시계 브랜드 인증을 전문으로 하는 각각의 하위 길드들이 있을 수 있다. 또 다른 예에서, 신발 인증 길드의 경우, 운동화, 하이탑, 스케이트보드 신발, 힐, 드레스 신발 등의 상이한 유형들의 신발 인증을 전문으로 하는 각각의 하위 길드들, 및/또는 Nike® 신발, Jordan® 신발, Adidas® 신발, Gucci® 신발, Louboutin® 신발 등의 상이한 브랜드들의 신발 인증을 전문으로 하는 하위 길드들이 있을 수 있다. 또 다른 예로, 미술 인증 길드 내에서, 회화, 유화, 조각, 석판화, 콘서트 포스터, 도검, 꽃병, 도자기 등의 상이한 매체로 된 예술품; 인상파 회화, 추상화, 포스트 모던 아트, 팝 아트, 낙서, 일본도, 중국 꽃병, Faberge 달걀 등의 상이한 스타일의 예술품; 및/또는 상이한 예술가별 예술품 인증을 전문으로 하는 각각의 하위 길드들이 있을 수 있다. 이해할 수 있는 바와 같이, 상이한 길드들은 상이한 방식으로 하위 길드들로 분해될 수 있다. 또한, 길드의 하위 도메인에 하위 길드가 존재하기 때문에, 모든 아이템이 하위 길드 내에 속해야 한다는 의미는 아니다. 예를 들어, 시계 인증 길드가 Rolex 하위 길드를 포함하지만 다른 하위 길드는 포함하지 않는 경우, Rolex® 시계는 Rolex® 하위 길드의 한 명 이상의 인증자에 의해 인증될 수 있지만 Omega® 시계는 롤렉스 하위 길드의 멤버들을 포함한, 더 광범위한 시계 인증 길드 내의 한 명 이상의 인증자에 의해 인증될 수 있다.
실시예들에서, 각각의 길드 내에서 하위 길드를 형성하는 능력은, 각각의 길드의 길드-레벨 거버넌스 및/또는 스테이지-레벨 거버넌스에서 정의될 수 있다. 이들 실시예들 중 일부에서, 각각의 길드로부터의 새로운 하위 길드의 형성은 각각의 길드에 대응하는 길드 거버넌스 스마트 계약(2026)을 이용하여 관리되고 시행될 수 있다. 일부 실시예에서, 길드 거버넌스 스마트 계약(2026)은, 하위 길드가 요청되고(예를 들어, 자동으로 또는 길드 멤버 세트에 의해) 생성될 수 있는 메커니즘을 정의할 수 있다. 예를 들어, 특정한 인증 길드(예를 들어, 시계 인증 길드)에 의해 이용되는 길드 거버넌스 스마트 계약(2026)은, 새로운 하위 길드(예를 들어, 롤렉스 하위 길드) 생성을 요청/승인하기 위해 요구되는 길드 멤버(예를 들어, 시계 인증자)의 최소 수 및/또는 최소 백분율을 정의하는 조건부 로직을 포함할 수 있다. 이 예에서, 특정한 인증 길드의 길드-레벨 거버넌스는, 하위 길드 생성에 동의하기 위해 적어도 10명의 길드 멤버 및/또는 길드 멤버들의 적어도 50%가 투표권을 가질 것을 요구할 수 있다(여기서, 투표권은, 더 많은 길드 토큰들(2044)을 갖는 멤버들이 더 많은 투표권을 갖는 투표 토큰 방식, 또는 모든 멤버가 하나의 동등한 가중치의 투표권을 갖는 "1멤버 1투표" 방식을 이용하여 결정될 수 있다). 추가적으로 또는 대안으로서, 길드 거버넌스 스마트 계약(2026)은, 새로운 하위 길드 생성을 인가하기 위해 아이템들의 특정한 서브클래스를 포함하는 길드 멤버들에 의해 수행된 확인된 성공적인 인증 이벤트들(또는 또 다른 스테이지인 경우 다른 작업들)의 최소 수 또는 최소 백분율을 요구하는 조건부 로직을 포함할 수 있다. 예를 들어, 신발 인증 길드의 길드 거버넌스 스마트 계약(2026)은 특정한 클래스의 신발을 포함하기 위해 적어도 1,000개의 성공적인 인증 이벤트와 총 인증 이벤트의 적어도 5%의 증거를 요구할 수 있고, 신발 인증 길드는 한 켤레의 신발과 관련된 10,000개의 성공적인 인증 이벤트를 집합적으로 수행했고 이들 인증 이벤트들 중 1000개 초과의 Nike® 운동화를 포함했으며, 신발 길드는 Nike® 하위 길드(또는 "운동화" 하위 길드)를 생성하기 위해 투표할 수 있다. 이 예에서, 신발 인증 길드의 길드 거버넌스 스마트 계약은, (가짜 운동화들의 성공적인 식별 및/또는 정품 Nike® 운동화들의 성공적인 인증을 포함할 수 있는) 1000개 이상의 성공적인 인증 이벤트를 증명하기 위해 분석을 요구할 수 있다. 실시예들에서, 길드가 요구되는 성공적인 인증 필요 수에 도달했음을 증명하는 분석이, 인증 기록을 저장하는 분산형 원장의 분석에 기초하여 획득될 수 있다. 또한, 신발 인증 길드-레벨 거버넌스는 길드 멤버들이 새로운 Nike® 하위 길드의 생성에 관해 투표할 것을 요구할 수 있고, 여기서 투표 방식은 신발 길드-레벨 거버넌스 및/또는 인증 스테이지-레벨 거버넌스에서 정의된다. 신발 길드 내에서 새로운 하위 길드를 생성하기 위한 모든 조건이 충족된다고 가정하면, 길드 거버넌스 스마트 계약은 "새로운 하위 길드 생성" 동작을 트리거할 수 있다. 실시예들에서, 새로운 하위 길드 생성 동작은, 하위 길드에 대한 멤버쉽, 하위 길드에 대한 보상 및 커미션, 하위 길드에서 분류된 아이템 확인을 위한 메커니즘, 하위 길드들이 인증 이벤트를 보호하는 방법, 하위 그룹에 의해 이용되는 인증 양식 등에 대한 규칙들을 포함한, 특정한 하위 길드에 대한 규칙들을 정의하는 하위 길드에 대응하는 새로운 거버넌스의 생성을 포함할 수 있다. 실시예들에서, 하위 길드의 하위 길드 거버넌스는 처음에, (그 일부는 하위 길드에 의해 변경가능하고 일부는 하위 길드에 의해 변경될 수 없는) 더 광범위한 길드 거버넌스의 하나 이상의 양태를 상속할 수 있다는 점에 유의한다. 실시예들에서, "새로운 하위 길드 생성" 동작은, 플랫폼(100)이 새로운 하위 길드의 전문기술 하에 새로운 하위 길드로 분류되는 아이템들과 관련된 인증 작업들의 할당을 업데이트할 수 있도록, 새로운 하위 길드의 통보를 토큰화 플랫폼(100)에 발행하는 것을 포함할 수 있다.
도 21은 탈집중형 대출 생태계(2000) 내의 길드들 및 길드 멤버들 및/또는 대출 시스템의 상이한 양태들을 통제할 수 있는 상이한 유형들의 거버넌스들의 한 예를 나타낸다. 예시된 예에서, 스테이지-레벨 길드들은, 인증 작업들을 수행하는 인증자들로 구성된 인증 길드(2102), 평가 작업들을 수행하는 평가자들로 구성된 평가 길드(2104), 보관 작업들을 수행하는 보관자들로 구성된 보관자 길드(2106)를 포함할 수 있다. 상이한 예들에서 추가적 또는 대안적 유형들의 참여자들이 길드들을 형성할 수 있다는 것을 이해할 것이다. 예를 들어, 대출자들은 대출자 길드(미도시)를 형성할 수 있다. 논의된 바와 같이, 인증 길드들 내에서, 소정의 인증 전문분야를 갖거나 소정 지역들에 위치한 멤버들을 포함하는 길드들이 있을 수 있다. 예시된 예에서, 인증 길드 내에서, 시계 인증 길드(2112-1), 신발 인증 길드(2112-2), 및/또는 기타 임의의 적절한 인증 길드(예를 들어, N번째 인증 길드(2112-N))가 있을 수 있다. 일부 인증 길드 내에는, 인증 하위 길드들이 형성될 수 있다. 예를 들어, 시계 길드(2112-1) 내에는, Rolex 하위 길드가 형성될 수 있으며, 여기서 Rolex 하위 길드(2122)의 멤버들은 롤렉스® 시계 인증에 있어서 특별한 전문기술을 가진 시계 길드 멤버들일 수 있다. 이러한 방식으로, Rolex 하위 길드(2112-1)의 멤버들은 Rolex® 시계(및 잠재적으로 다른 유형들의 시계들)와 관련된 인증 작업들을 할당받는 반면, 하위 길드(2122)에 속하지 않는 시계 길드(2112-1) 멤버들은 Rolex® 시계는 인증할 수 없지만 임의의 다른 유형의 시계를 인증할 수 있다(다른 시계 하위 길드들이 없다고 가정). 유사하게, 신발 인증 길드(2112-2) 내에, 신발 인증 길드(2112-2)의 멤버들에 의해 운동화 인증 하위 길드(2124-1) 및 Gucci 인증 하위 길드(2124-1)가 형성되었다. 이 예에서 운동화 인증 하위 길드(2124-1)의 멤버들은 임의의 유형의 운동화를 인증할 수 있지만 운동화 인증 하위 길드(2124-1)에 속하지 않는 신발 인증자들은 운동화를 인증할 수 없다. 마찬가지로, Gucci 인증 하위 길드(2124-2)의 멤버들은 Gucci® 신발을 인증할 수 있지만, Gucci 인증 하위 길드(2124-2)에 속하지 않는 신발 인증자들은 Gucci® 신발을 인증할 수 없다.
평가 길드(2104) 내에는, 소정의 평가 전문분야를 갖거나 소정의 지역들에 위치한 멤버들을 대상으로 하거나 길드들이 있을 수 있다. 예시된 예에서, 평가 길드(2104) 내에서, 시계 평가 길드(2114-1), 신발 평가 길드(2114-2), 및/또는 기타 임의의 적절한 평가 길드(예를 들어, N번째 평가 길드(2114-3))가 있을 수 있다. 예시된 예에서, Rolex 평가 하위 길드(2126)는 시계 평가 길드(2114-1)로부터 형성되었고 Nike 평가 길드(2128)는 신발 평가 길드(2114-2)로부터 형성되었다. 이해할 수 있는 바와 같이, 다양한 길드 내에서 형성된 하위 길드들은 상이한 스테이지들에 참여하는 길드들로부터 형성된 하위 길드들과 일치할 필요는 없다. 예를 들어, Rolex 인증자와 Rolex 평가자는 각각의 하위 길드들(2122, 2126)을 형성했지만, 그에 대응하는 Nike 인증 하위 길드와 대응하는 운동화 평가 하위 길드 또는 Gucci 평가 하위 길드는 형성되지 않았다. 하위 길드들이 형성되는 방식은, 스테이지-레벨 거버넌스 및/또는 하위 길드가 형성될 길드의 길드 거버넌스에서 정의될 수 있다.
이 예에서는, 보관자 길드(2106)로부터 형성된 길드는 없다. 이것이 현재 예의 경우이지만, 일부 시나리오에서는 소정의 보관 전문분야를 갖거나 소정의 지역들에 위치한 보관자들을 포함하는 길드들이 있을 수 있다. 예시된 예에서, 보관자 길드 내에는 어떠한 길드도 없지만, 보관자들은, 지역(예를 들어, 주, 도시 등), 소정 유형들의 아이템들(예를 들어, 차량, 부패하기 쉬운 것, 및/또는 기타 등등), 또는 기타의 적절한 공통 피처들에 따라 조직화될 수 있다.
실시예들에서, (전체 대출 프로세스 워크플로우를 포함한) 전체 생태계(2100)는 시스템-레벨 거버넌스(2130)에 의해 통제될 수 있다. 이 예에서, 하나 이상의 스테이지는, 스테이지의 참여자들 및/또는 스테이지와 관련하여 수행되는 워크플로우들에 속하는 스테이지-레벨 거버넌스에 의해 관리될 수 있다. 예를 들어, 인증 스테이지-레벨 거버넌스(2132)는 모든 인증자(2102) 및 인증 스테이지에 관련되고, 평가 스테이지-레벨 거버넌스(2134)는 모든 평가자(2104) 및 평가 스테이지에 관련되며, 보관 스테이지-레벨 거버넌스(2136)는 모든 보관자(2106) 및 보관 스테이지에 관련되고, 대출 스테이지-레벨 거버넌스(2138)는 대출자들(미도시) 및 대출 협상 및 상환 스테이지 등에 관련된다. 논의된 바와 같이, 스테이지-레벨 거버넌스들(2132, 2134, 2136, 2138)은 시스템-레벨 거버넌스(2130)를 정교화할 수 있고 시스템-레벨 거버넌스(2130)와 상충되지 않는 규칙들 및 규정들을 추가할 수 있다. 유사하게, 시계 길드-레벨 거버넌스(2142)는 시계 인증 길드(2112-1)에 속하지만 다른 인증 길드(2112-2…2112-N)에는 속하지 않는다. 시계 길드-레벨 거버넌스(2142)는 시스템-레벨 거버넌스(2130)를 더 정교화하는 규칙들 및/또는 인증 스테이지-레벨 거버넌스(2132)에 규칙들 및 규정들을 추가하는 규칙들을 포함할 수 있다. 예에서, Rolex 하위 길드 거버넌스(2144)는 Rolex 인증 하위 길드(2122)의 멤버들에 의해 생성될 수 있다. Rolex 하위 길드 거버넌스(2144)는, Rolex® 시계의 인증을 수행할 때 Rolex 하위 길드(2122)의 멤버들에게 적용되지만 시계 인증 길드(2112-1)의 다른 멤버에게는 적용되지 않는 추가적인 규칙들 및 규정들을 정의한다. 참고로, 하위 길드들은 하위 길드 거버넌스를 필요로 하지 않으며, 하위 길드가 형성된 길드의 길드-레벨 거버넌스를 이용할 수 있다. 길드들과 거버넌스들에 대한 상세한 논의는 아래에서 설명된다.
도 20을 다시 참조하면, 거버넌스는 증권화된 탈집중형 대출 프로세스의 상이한 양태들에 관련된 규칙들과 규정들을 정의할 수 있다. 실시예들에서, 시스템-레벨 거버넌스는 전체 대출 프로세스에 관련된 규칙들 및 규정들을 정의한다. 시스템-레벨 거버넌스의 예로서는, 대출 프로세스 워크플로우 정의들(예를 들어, 어느 스테이지들이 수행되어야 하는지 및 어떤 순서로); 허용된 유형들의 담보 아이템들; 길드 형성 및 멤버쉽에 대한 규칙들(예를 들어, 길드를 형성할 수 있는지, 길드들이 규칙을 변경할 수 있는지, 길드들이 규칙을 변경하는 방법, 및/또는 기타 등등); 스테이지들간 대출 프로세스 워크플로우를 관리하기 위한 규칙들(예를 들어, 담보 아이템을 인증한 인증자가 동일한 담보 아이템을 평가하고/하거나 담보 아이템을 보관할 수 있는지, 대출 프로세스가 어떤 다음 스테이지로 진행될 수 있는지); 담보 아이템과 관련된 인증 작업들, 평가 작업들, 및/또는 보관 작업들과 관련하여 길드 멤버들이 통화(예를 들어, 암호화폐 및/또는 토큰화된 토큰으로 포장된 법정 화폐)를 위험부담성 출자할 것을 요구하는 규칙들; 작업들을 수행하기 위한 규칙들(예를 들어, 합의를 보여줄 것이 요구되는 지원 문서의 유형); 거버넌스 변경에 대한 규칙들(예를 들어, 거버넌스 변경에 투표할 수 있는 사람, 거버넌스 변경에 대한 투표 방법 등); 참여자 보상에 대한 규칙들(예를 들어, 특정한 작업을 수행할 때 이루어질 수 있는 지불들의 금액들 또는 백분률들과 관련된 임의의 요건들 및/또는 제약들, 상이한 관할구역들에 대한 규제 요건들); 및/또는 기타의 적절한 규칙들 및 규정들이 포함된다.
실시예들에서, 시스템-레벨 거버넌스는 분산형 원장(2016)에 저장된 하나 이상의 각각의 대출 프로세스 스마트 계약(2022)에 대한 참조들을 포함할 수 있다. 대출 프로세스 스마트 계약(2022)은, 예를 들어 시스템-레벨 거버넌스에 정의된 대출 프로세스 워크플로우에 따라 이전 스테이지가 완료될 때 대출 프로세스의 각각의 스테이지를 개시하는 것을 포함한, 탈집중형 대출 프로세스의 인스턴스들에 대한 시스템-레벨 거버넌스의 하나 이상의 양태를 시행할 수 있다. 실시예들에서, 대출 프로세스 스마트 계약(2022)은, 일단 인스턴스화되고 나면, 스테이지가 성공적으로 완료되었음을 나타내는 스테이지-레벨 스마트 계약으로부터의 통보를 (예를 들어, 이벤트 청취자 스레드를 이용하여) 청취하는 조건부 로직을 포함한다. 스테이지가 완료되는 것에 응답하여, 대출 프로세스 스마트 계약(2022)은 대출 워크플로우 프로세스의 다음 스테이지를 개시할 수 있다. 예를 들어, 예시적인 대출 프로세스 워크플로우는, 차용자가 하나 이상의 아이템을 담보화할 것을 요청하는 요청 스테이지, 이에 후속하는 하나 이상의 인증자가 하나 이상의 아이템을 인증하는 인증 스테이지, 이에 후속하는, 인증된 아이템이 평가되는 평가 스테이지, 이에 후속하는, 평가된 아이템이 신뢰할 수 있는 보관자의 에스크로에 보관되는 보관 스테이지, 원장 관리 시스템(104)(또는 다른 적절한 컴포넌트)이 하나 이상의 에스크로잉된 아이템의 VIRL들을 생성하고 에스크로잉된 아이템의 VIRL들을 토큰화함으로써 담보 토큰을 생성하고 (예를 들어, 분산형 원장(2016)의 에스크로 계정에) 담보 토큰을 잠금처리하는 토큰화 스테이지, 대출이 차용자와 대출자에 의해 협상되고 수락되는 대출 스테이지, 차용자에 의해 대출이 상환되는 스테이지, 및 담보 토큰이 잠금해제되어 차용자에게 반환되거나 차용자가 대출에 관해 채무불이행하는 경우에는 청산되는 대출후 스테이지를 포함하는 것으로서 정의될 수 있다. 이 예시적인 대출 프로세스 워크플로우를 용이화하는데 있어서, 대출 프로세스 스마트 계약(2022)은 현재 스테이지가 성공적으로 완료되었는지 여부를 결정하고 만일 그렇다면 대출 프로세스 워크플로우의 다음 스테이지를 개시하는 조건부 로직으로 구성될 수 있다. 실시예들에서, 대출 프로세스 워크플로우의 다음 스테이지를 개시하는 것은, 스테이지-레벨 스마트 계약(예를 들어, 인증 스마트 계약(2028), 평가 스마트 계약(2030), 보관 스마트 계약(2032) 또는 대출 스마트 계약(2034))의 한 인스턴스를 인스턴스화하는 것을 포함할 수 있고, 이에 따라 스테이지-레벨 스마트 계약의 인스턴스화된 인스턴스는 스테이지별 워크플로우를 수행하고 스테이지별 워크플로우가 성공적으로 또는 성공적으로 완료되지 않을 때 대출 프로세스 워크플로우에 의해 수신되는 통보를 발행한다. 실시예들에서, 대출 프로세스 스마트 계약(2022)은 다른 유형들의 스마트 계약들에 의해 수행되는 것으로서 설명되는 하나 이상의 작업을 수행할 수 있다. 예를 들어, 대출 프로세스 스마트 계약(2022)은, 대출 협상 및 대출 서명, 대출 상환 모니터링, 채무불이행 이벤트 결정, 청산 이벤트 트리거, 참여자들에게 보상 수여, 및/또는 기타 등등을 용이화하도록 구성될 수 있다.
시스템-레벨 프로세스 거버넌스는 추가적인 규칙들 및 요건들을 포함할 수 있고, 그 예들이 본 개시내용 전반에 걸쳐 제공된다. 예를 들어, 시스템-레벨 프로세스 거버넌스는, 인증자 및 평가자로서 역할하는 단일 엔티티를 배제하며, 인증자들, 평가자들, 및/또는 보관자들이 대출 금액의 적어도 일정 백분률을 위험부담성 출자할 것을 요구하는(예를 들어, 시스템의 조작을 방지하기 위해) 규칙들, 및/또는 대출 프로세스의 탈집중화, 사기 가능성 감소, 신뢰 증진, 참여자들에 대한 가치 극대화, 토큰 주조, 및/또는 기타 등등과 관련된 기타의 규칙들을 포함할 수 있다. 실시예들에서, 시스템-레벨 프로세스 거버넌스의 적어도 일부는 대출 프로세스 스마트 계약(2022)에 의해 구현된다. 실시예들에서, 대출 프로세스 거버넌스 스마트 계약은, 각각의 상응하는 스테이지가 성공적으로 완료되었는지를 결정하고, 만일 그렇다면 대출 프로세스에서 다음 동작을 트리거하는 조건부 로직을 포함할 수 있다.
실시예들에서, 스테이지-레벨 거버넌스는, 대출 프로세스의 각각의 스테이지가 하나 이상의 상응하는 스테이지-레벨 거버넌스에 따라 실행될 수 있도록, 대출 프로세스의 상응하는 스테이지에 속하는 규칙들 및 규정들을 정의한다. 일부 실시예에서, 스테이지-레벨 거버넌스는 2개의 스테이지에 적용될 수 있다는 것을 이해할 것이다. 예를 들어, 인증 스테이지는 탈집중형 대출 프로세스와 관련하여 수행되는 임의의 인증 작업에 대한 규칙들을 정의하는 스테이지-레벨 인증 거버넌스를 따를 수 있고, 평가 스테이지는 탈집중형 대출 프로세스와 관련하여 수행되는 임의의 평가 작업에 대한 규칙들을 정의하는 스테이지-레벨 평가 거버넌스를 따를 수 있고, 보관 스테이지는 탈집중형 대출 프로세스와 관련하여 수행되는 임의의 보관 작업에 대한 규칙들을 정의하는 스테이지-레벨 보관 거버넌스, 담보 아이템의 VIRL을 생성하기 위한 규칙들을 정의하는 VIRL 스테이지-레벨 거버넌스, 담보 아이템의 VIRL 토큰 생성을 위한 규칙들을 정의하는 토큰화 스테이지-레벨 거버넌스(일부 실시예에서 VIRL 스테이지 및 토큰화 스테이지는 단일 스테이지로 취급될 수 있음), 대출을 요청하고 협상하기 위한 규칙들을 정의하는 대출 거버넌스 대출, 및/또는 기타 임의의 적절한 스테이지-레벨 거버넌스를 따를 수 있다.
실시예들에서, 스테이지-레벨 거버넌스는 시스템-레벨 거버넌스에 개시된 규칙들을 더 정교화할 수 있고/있거나 스테이지에 관련된 추가적인 규칙들을 포함할 수 있다. 예를 들어, 스테이지-레벨 거버넌스는, 길드 멤버 추가 및/또는 제거와 같은 추가적인 정교화, 길드별 작업(예를 들어, 인증 작업, 평가 작업 또는 보관 작업)과 관련하여 길드 멤버들이 통화를 위험부담성 출자하는 방법에 관한 추가적인 정교화; 인증 작업을 지원하는데 필요한 증거 유형에 관한 추가적인 정교화 등의 시스템-레벨 거버넌스로부터의 규칙들 및/또는 규정들을 더 정교화할 수 있다. 예를 들어, 시스템-레벨 거버넌스는, 임의의 길드 가입에 대한 새로운 멤버들은 반드시 투표되어야 하고 적어도 60% 다수결로 제거될 수 있다고 명시할 수 있지만, 임의의 다른 상세사항은 정의하지 않을 수 있다. 이 예에서, 인증 스테이지-레벨 거버넌스 규칙들은 인증 길드들에 대한 멤버 가입과 제거를 위한 제1 투표 방식을 정의할 수 있는 반면, 평가 스테이지-레벨 거버넌스는 평가 길드들에 대한 멤버 가입과 제거를 위한 제2 방식을 정의할 수 있다. 예를 들어, 인증자들은, 단순한 과반수 투표로 길드에 새로운 멤버가 추가되고 60% 다수결 투표로 멤버들이 제거될 수 있는 1멤버 1투표 투표 방식을 가질 수 있고, 여기서 평가자들은 토큰 기반의 투표를 가질 수 있고, 토큰 기반의 투표에서는, 각각의 길드 멤버가 소정량의 길드 토큰(2044)을 갖고, 이에 따라 각각의 길드 멤버의 투표권은 길드 멤버가 소유한 길드 토큰(2044)의 양에 비례한다. 제2 방식에서, 연장자 또는 활동적인 멤버들이, 덜 연장자이거나 활동이 적은 길드 멤버들보다 더 많은 투표권을 갖는다. 실시예들에서, 스테이지-레벨 거버넌스는 또한, 대응하는 스테이지에서 길드들에 의해 요구되는 문서 및 지원 데이터의 유형들을 정의할 수 있다. 이 예에서, 인증 스테이지-레벨 거버넌스는, 인증자가 인증 보고를 작성하고 그 보고를 뒷받침하는 사진 증거를 제공할 것을 요구하게끔 이 규칙을 더욱 정교화할 수 있다. 유사하게, 평가 스테이지-레벨 거버넌스는 평가자가 평가 가치를 나타내는 평가 보고를 파일링하고 평가 가치를 뒷받침하기 위해 유사한 아이템들의 과거 판매에 대한 문서 증거를 제공할 것을 요구하게끔 이 규칙을 더욱 정교화할 수 있다. 이 예에서, 보관자 스테이지-레벨 거버넌스는, 보관자가 안전하게 보관 중인 아이템의 사진 증거를 제공하고 아이템이 예치될 때 소유자(예를 들어, 차용자)가 볼 수 있었던 손상 및 상기 눈에 보이는 손상에 대한 아이템의 소유자의 확인을 나타내는 보관 보고를 작성할 것을 요구하도록 이 규칙을 더욱 정교화할 수 있다. 또한, 평가 스테이지-레벨 거버넌스는, 평가 보고가 담보 아이템의 평가 가치 외에도 담보 아이템의 청산 가치를 포함한다고 추가로 정의할 수 있고, 여기서, 청산 가치는 매각될 것으로 예상되는 담보 아이템의 최저 가격(예를 들어, 단기 청산 이벤트에서 또는 빠른 청산 판매를 달성하기 위해 정해진 가격 판매)을 나타낸다.
언급된 바와 같이, 스테이지-레벨 거버넌스는 또한, 이들 새로운 규칙들 및 규정들이 시스템-레벨 거버넌스와 상충되거나 기타의 방식으로 무효화하지 않는 범위 내에서 새로운 규칙들 및 규정들을 정의할 수 있다. 예를 들어, 시스템-레벨 거버넌스에 이러한 규칙들이 정의되어 있지 않다고 가정하면, 스테이지-레벨 거버넌스는 스테이지별 작업이 수행되는 방법에 관한 규칙들을 정의할 수 있다. 예를 들어, 인증 스테이지와 관련하여, 인증 스테이지-레벨 거버넌스는 1차 인증자가 담보 아이템의 진위성을 결정하고 적어도 하나의 다른 인증자("2차 인증자"로서 역할)가 아이템의 진위성에 대한 1차 인증자의 결정을 검증할 것을 요구할 수 있다. 이 예에서, 스테이지-레벨 거버넌스는, 1차 인증자가 인증 수수료/보상 중 소정 백분률(예를 들어, 60% 또는 70%)을 받고 나머지 금액이 하나 이상의 2차 인증자들에게 분배되는 것으로 추가로 정의할 수 있다. 또한, 이 예에서, 인증 스테이지-레벨 거버넌스는, 1차 인증자와 다른 2차 인증자들에 대한 위험의 할당을 정의함으로써(예를 들어, (대출이 합의되었다고 가정하여) 1차 인증자가 대출 금액의 60% 또는 70%를 위험부담성 출자하고 2차 인증자들은 대출 금액의 나머지 부분을 균등하게 나눈다) 인증자들이 통화 토큰들을 위험부담성 출자하기 위한 시스템-레벨 요건을 정교화할 수 있다. 또 다른 예에서, 평가 스테이지-레벨 거버넌스는 평가의 메커니즘 및 워크플로우들을 정의할 수 있다. 예를 들어, 거버넌스는 평가 작업들이 평가자들에게 할당되고 임의의 평가가 한 명 이상의 추가 평가자에 의해 검증되어야 하는 방식을 정의할 수 있다. 이 예에서, 평가 스테이지-레벨 거버넌스는, 1차 및 2차 평가자들이 보상을 받는 방식 및/또는 1차 및 2차 평가자들이 그들의 평가를 확보하기 위해 위험부담성 출자해야 하는 통화 금액을 더욱 정교화할 수 있다. 또 다른 예에서, 보관자 스테이지-레벨 거버넌스는 소정 유형들의 담보 아이템들을 보관하기 위한 추가 규칙들을 정의할 수 있다. 예를 들어, 아이템들이 온도 제어 보관을 요구하는 경우, 보관 스테이지-레벨 거버넌스는 보관자가 이러한 온도 제어 보관의 증거를 제공할 것을 요구하는 규칙을 정의할 수 있다. 또 다른 예에서, 담보 아이템이 차량인 경우, 보관 스테이지-레벨 거버넌스는 보관자가 차량을 처음 수령한 날과 정당한 소유자(예를 들어, 차용자 또는 청산을 통한 구매자)가 차량을 다시 소유한 날에서 차량의 주행 거리에 대한 증거를 제공할 것을 요구하는 규칙들을 정의할 수 있다. 스테이지-레벨 거버넌스들은, 시스템-레벨 규칙들 및 규정들의 추가적인 또는 대안적인 정교화 및/또는 시스템-레벨 거버넌스에 표시되지 않은 규칙들 및/또는 요건들의 추가적인 또는 대안적인 정의들을 포함할 수 있다.
실시예에서, 일부 스테이지-레벨 거버넌스들은, 스테이지와 관련하여 이용되는 양식 템플릿들 또는 그에 대한 참조들(예를 들어, 양식 템플릿들이 획득될 수 있는 주소)을 포함할 수 있다. 일부 예시적인 실시예에서, 인증 스테이지-레벨 거버넌스는 인증 작업을 수행할 때 인증자들에 의해 이용될 수 있는 인증 양식 템플릿에 대한 참조를 포함할 수 있다. 양식 템플릿은, 담보 아이템의 인증을 처리하는 인증자에 의해 채워질 한 세트의 필드들을 포함할 수 있어서, 인증자가 양식을 완성하고 그 양식을 인증 시스템(804), 인증자 스마트 계약(2028) 및/또는 대출 프로세스 스마트 계약(2022)에 제출할 수 있게 할 수 있다. 양식을 채우는데 있어서, 인증자들은 아이템의 진위성에 대한 의견을 제공할 수 있고 의견을 뒷받침하는 분석을 제공할 수 있다. 양식은, 사진, 일련 번호, 비디오 등의 뒷받침 자료를 제공하는 지침들을 포함할 수 있다. 일부 예시적인 실시예에서, 평가 스테이지-레벨 거버넌스는 평가자 작업을 수행할 때 평가자들에 의해 이용될 수 있는 평가 양식 템플릿에 대한 참조를 포함할 수 있다. 평가 전에 인증이 수행된다고 가정하면, 평가자는 아이템이 진품임을 신뢰할 수 있지만 적절한 평가를 제공하기 위해 아이템 자체 또는 아이템의 사진 및/또는 비디오의 검사를 요구할 수 있다. 평가자 양식은, 담보 아이템의 평가를 처리하는 평가자에 의해 채워질 한 세트의 필드들을 포함할 수 있어서, 평가자가 양식을 완성하고 완성된 양식을 인증 시스템(804) 및/또는 평가 스마트 계약에 제출할 수 있게 한다. 양식을 채우는데 있어서, 평가자는 평가 가치를 제공할 수 있고 평가 가치를 뒷받침하는 분석을 제공할 수 있다. 양식은, 유사한 아이템들의 과거 판매 증거, 블루북 가치, 경매 데이터 등의 뒷받침 증거를 제공하기 위한 지침들을 포함할 수 있다. 일부 예시적인 실시예에서, 보관 스테이지-레벨 거버넌스는 보관 작업을 수행할 때 보관자들에 의해 이용될 수 있는 보관 양식 템플릿에 대한 참조를 포함할 수 있다. 일부 실시예에서, 양식은 평가자가 평가 가치 외에도 담보 아이템의 청산 가치를 제공할 것을 요구할 수 있다. 청산 가치는, 담보 아이템을 신속하게 청산해야 하는 경우와 같이 담보 아이템의 최저 평가액일 수 있다. 평가 가치와 결합된 청산 가치는, 담보 아이템의 평가 가치와 청산 가치를 감안하여 잠재적인 대출자가 돈을 빌려주는 것과 연관된 위험에 대한 평가 기회를 제공할 수 있다. 양식은, 담보 아이템의 보관을 처리하는 보관자에 의해 채워질 한 세트의 필드들을 포함할 수 있어서, 인증자가 양식을 완성하고 그것을 (예를 들어, 담보 관리 시스템(802) 및/또는 보관 스마트 계약에) 제출할 수 있게 한다. 양식을 채우는데 있어서, 보관자는 담보 아이템을 수령했을 때의 상태를 제공하고 담보 아이템을 안전하게 보호할 수 있는 적절한 예방 조치가 있는 물리적 위치에 담보 아이템이 보관되고 있는지를 확인할 수 있다. 양식은, (눈에 보이는 손상을 포함한) 담보 아이템의 사진 등의 뒷받침 자료를 제공하기 위한 지침들을 포함할 수 있다. 예를 들어 양식 템플릿들이 제공되고 탈집중형 대출 프로세스의 다양한 스테이지 동안에 추가적인 또는 대안적인 양식 템플릿들이 이용될 수 있다는 것을 이해할 것이다. 또한, 일부 길드는 특정한 유형의 담보 아이템에 대한 양식 템플릿을 더 정교화할 수 있다. 이들 시나리오에서, 스테이지-레벨 거버넌스에 정의된 양식 템플릿들 대신에 길드-정교화된 양식 템플릿들이 각각의 작업과 관련하여 이용될 수 있다. 다른 스테이지-레벨 거버넌스들은 다른 양식 템플릿들을 포함할 수 있다는 점에 유의한다. 또한, 일부 길드-레벨 거버넌스 및/또는 하위 길드-레벨 거버넌스는, 스테이지-레벨 거버넌스에 정의된 양식 템플릿들 대신에 또는 스테이지-레벨 거버넌스가 더 광범위한 양식 템플릿을 포함하거나 참조하지 않는 경우에 길드 또는 하위 길드의 멤버들에 의해 이용될 양식 템플릿들을 포함하거나 참조할 수 있다는 것을 이해해야 한다.
일부 실시예에서, 스테이지-레벨 거버넌스들은 스테이지-레벨 작업들 및/또는 스테이지에 참여하는 길드 관리와 관련하여 이용되는 하나 이상의 스마트 계약에 대한 참조를 포함할 수 있다. 이들 스마트 계약은 시스템-레벨 거버넌스에 정의된 관련 규칙들 및 규정들뿐만 아니라 각각의 스테이지의 스테이지-레벨 거버넌스를 시행하는 각각의 스테이지들의 참여자 관리에 대응하는 스테이지-레벨 거버넌스 스마트 계약(2024)을 포함할 수 있다. 실시예들에서, 스테이지-레벨 거버넌스 스마트 계약(2024)은 특정한 스테이지의 메커니즘을 시행하도록 구성될 수 있다. 예를 들어, 특정한 스테이지의 스테이지-레벨 거버넌스는, 거버넌스에 대한 변경은 스테이지의 모든 참여자에 의해 투표될 것을 요구할 수 있고 투표 프로세스를 시행하기 위해 스테이지-레벨 거버넌스 스마트 계약(2024)을 이용할 수 있다. 이 예에서, (모든 길드에 걸쳐) 인증자들은, 아이템이 위조인 것으로 결정되거나 차용자가 대출 합의에 들어가지 않기로 결정한 경우(이것은, 인증자가 대출 거래 참여에 대해 보상을 지불받는 것을 방지할 것이다) 인증자가 여전히 지불을 받을 수 있도록 하기 위해, (대출 프로세스가 성공적으로 완료되었을 때 인증자에게 지불되는 보상 외에) 차용자가 인증자에게 지불하는 인증 수수료를 요구하도록 인증 스테이지 거버넌스를 변경하기를 원할 수도 있다. 스테이지-레벨 거버넌스(2024)는, 인증자들이 스테이지-레벨 거버넌스를 수정하기 위해 대다수가 투표하고(예를 들어, 2/3 다수결) 이러한 수정을 하려면 중앙 기관과 제휴한 의사 결정자의 승인을 추가로 받아야 할 것을 요구할 수 있다. 이 예에서, 스테이지-레벨 거버넌스 스마트 계약(2024)은, 인증자들로부터 투표들을 수신하고 대다수가 인증 스테이지-레벨 거버넌스 수정에 투표했는지를 결정하는 청취 스레드를 포함할 수 있다. 만일 그렇다면, 스마트 계약은, 인증 스테이지-레벨 거버넌스를 수정하는 동작을 수행할 수 있고 대응하는 분산형 원장(2014)에 기입되는 투표 결과를 나타내는 블록을 생성할 수 있다. 이 예가 인증 스테이지 및 투표와 관련하여 설명되었지만, 스테이지-레벨 거버넌스 스마트 계약(2024)은 다양한 스테이지-레벨 거버넌스의 다른 양태들을 시행하도록 구성될 수 있다.
또한, 예시적인 실시예들에서, 스테이지-레벨 거버넌스들은 스테이지-레벨 이벤트들 및 거래들을 관리하는데 이용되는 각각의 스마트 계약에 대한 참조를 포함할 수 있다. 예를 들어, 인증 스테이지-레벨 거버넌스는 대출 프로세스와 관련하여 수행되는 인증 작업을 용이화하는데 이용되는 인증 스마트 계약(2028)에 대한 참조를 포함할 수 있다; 평가 스테이지-레벨 거버넌스는 대출 프로세스와 관련하여 수행되는 평가 작업을 용이화하는데 이용되는 평가 스마트 계약(2030)에 대한 참조를 포함할 수 있다; 보관 스테이지-레벨 거버넌스는 대출 프로세스와 관련하여 수행되는 대출 프로세스 보관 작업과 관련하여 수행되는 평가 작업을 용이화하는데 이용되는 보관 스마트 계약(2032)에 대한 참조를 포함할 수 있다; 대출 스테이지-레벨 거버넌스는 대출 합의 및 대출 상환 스테이지를 관리하는데 이용되는 대출 스마트 계약(2034)에 대한 참조를 포함할 수 있다; 및 기타 등등. 일부 실시예에서, 대출 워크플로우는 대출전 청산 스테이지-레벨 거버넌스에 의해 관리되는 대출전 청산 스테이지(아래에서 논의됨)를 포함할 수 있다. 이들 실시예에서, 대출전 청산 스테이지-레벨 거버넌스는, 아래에서 더 상세히 논의되는, 대출전 청산 스마트 계약에 대한 참조를 포함할 수 있다.
예시적인 실시예들에서, 인증 스테이지-레벨 거버넌스는 인증 작업들에 이용될 수 있는 인증 스마트 계약(2028)의 참조(예를 들어, 주소)를 포함할 수 있다. 참조는 (예를 들어, 분산형 원장(2016)으로부터) 인증 스마트 계약(2028)을 회수하는데 이용될 수 있는 주소를 정의할 수 있다. 이들 실시예에서, 대출 프로세스 스마트 계약(2022), 인증자 디바이스(2004), 및/또는 토큰화 플랫폼(100)은, 인증자가 새로운 인증 작업을 할당받고/받거나 인증자가 인증자 디바이스(2004)를 통해 새로운 인증 작업을 수락하는 것에 응답하여 인증 스마트 계약(2028)의 한 인스턴스를 인스턴스화할 수 있다. 일단 인스턴스화되고 나면, 인증 스마트 계약(2028)의 인스턴스는 분산형 원장(2016)에 기입될 수 있고, 여기서 인증 스마트 계약 인스턴스는 인증 작업을 관리하기 위해 실행된다. 실시예들에서, 인증 스마트 계약(2028)은, 인증자 디바이스(2004), 차용자 디바이스(2002), 및/또는 담보 관리 시스템(804)으로부터 입력을 수신하도록 구성될 수 있고, 수신된 입력에 기초하여 인증 작업과 관련한 모든 요구되는 단계들이 수행되었는지를 결정하는 조건부 로직을 포함할 수 있다.
도 22는 인증 워크플로우를 수행하기 위해 실행될 수 있는 한 예시적인 방법(2200)의 동작 세트를 나타낸다. 이 방법(2200)은, 인증 스마트 계약(2028) 또는 대출 프로세스 스마트 계약(2022) 등의 스마트 계약에 의해 실행될 수 있다. 설명의 목적을 위해, 방법(2200)은 인증 스마트 계약에 의해 수행되는 것으로 설명된다.
2202에서, 인증 스마트 계약(2028)의 한 인스턴스는 인증자 디바이스로부터 담보 아이템의 수령인의 확인을 수신할 수 있다. 일부 시나리오에서, 담보 아이템은 작업을 수행하기 위해 1차 인증자에게 물리적으로 전송된다. 이러한 시나리오에서, 1차 인증자는 인증자 디바이스(2004)를 이용하여 담보 아이템의 수령을 확인할 수 있다. 이들 실시예에서, 인증자는 담보 아이템의 이미지들을 제공할 수 있고 아이템의 가시적인 손상을 기록할 수 있다. 대안으로서, 1차 인증자에게 담보 아이템의 VIRL이 전송될 수 있다. 이들 실시예에서, VIRL은 인증 작업을 수행하는데 있어서 인증자를 보조할 수 있는 담보 아이템 및/또는 다른 미디어의 초고해상도 이미지들을 포함할 수 있다.
2204에서, 인증 스마트 계약 인스턴스는 1차 인증자로부터 인증 보고 및 지원 문서를 수신할 수 있다. 이들 실시예에서, 1차 인증자는, 인증자가 속한 인증 길드의 인증 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스에 따라 인증 보고를 생성할 것을 요구받을 수 있다. 일부 실시예에서, 1차 인증자는, 스테이지 인증 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스에 포함된 양식 템플릿을 이용하여 보고를 생성할 수 있다. 보고에서, 1차 인증자의 결론(예를 들어, 아이템이 진품인지 가짜인지)과 그 결론에 대한 이유가 표시될 수 있다. 지원 문서에는, 인증자의 결론을 뒷받침하는 사진들, 일련 번호들, 테스트 결과들 등이 포함될 수 있다. 일단 인증자가 인증 보고를 제공하고 나면, 보고 및 지원 문서는 한 명 이상의 2차 인증자에게 제공될 수 있다(스테이지-레벨 거버넌스에 의해 요구되는 경우).
2206에서, 인증 스마트 계약 인스턴스는 하나 이상의 2차 인증자로부터 확인을 수신한다. 일부 실시예에서, 인증 스마트 계약(2028)은, 1차 인증자의 보고를 수신하는 것에 응답하여 2차 인증자의 의견을 요청하는 조건부 로직을 포함할 수 있다. 일부 실시예에서, 스마트 계약 인스턴스(또는 1차 인증자)는 1차 인증자의 보고 및 뒷받침 증거를 2차 인증자에게 제공할 수 있고(그들에게 작업이 할당된 후) 2차 인증자들의 응답을 청취할 수 있다. 일단 수신되고 나면, 인증 스마트 계약(2028)은 필요한 수의 2차 인증자가 지원 의견을 제공했는지를 결정할 수 있고, 만일 그렇다면, 인증 스마트 계약 인스턴스는, 담보 아이템의 진위성에 관한 1차 인증자의 의견을 2차 인증자가 검증했는지를 결정하는 로직을 실행한다.
2208에서, 인증 보고, 지원 문서, 및 2차 인증자의 의견에 기초한 데이터 블록이 생성되고, 데이터 블록이 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 인증 스마트 계약은 데이터 블록을 생성하고 데이터 블록을 분산형 원장에 기입할 수 있다. 대안으로서, 인증 스마트 계약은, 인증 보고, 지원 문서, 및 2차 인증자의 의견을 원장 관리 시스템(202)(또는 다른 적절한 시스템)에 전송할 수 있으며, 원장 관리 시스템(202)(또는 다른 적절한 시스템)은, 차례로, 데이터 블록을 생성하고 그 데이터 블록을 분산형 원장에 기입할 수 있다.
2210에서, 인증 스마트 계약 인스턴스는 인증 작업의 결과를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 특히, 인증 스마트 계약은 아이템이 1차 인증자 및 2차 인증자(들)에 의해 진품으로 간주되었는지를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 만일 그렇다면, 인증 스마트 계약 인스턴스는, 인증 프로세스에 참여한 인증자(들)가 (예를 들어, 상환 자금 및/또는 청산 이벤트 수익금으로부터) 보상받을 때까지, 인증 워크플로우를 계속 진행할 수 있다. 그렇지 않은 경우, 인증 스마트 계약 인스턴스는 인증 작업을 종료할 수 있다.
2212에서, 인증 스마트 계약 인스턴스는 아이템이 진품이 아닌 것으로 간주되는 경우 인증을 안전하게 보호하기 위해 인증자들로부터의 통화 금액을 잠금처리할 수 있다. 일부 실시예에서, 인증 스마트 계약 인스턴스는 인증자의 인증 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스에 개시된 요건을 시행하여 인증자(들)가 아이템을 진품으로 간주할 때 소정 금액의 통화(예를 들어, 통화/토큰화 토큰들)를 잠금처리하여 대출자에게 더 많은 담보를 제공할 수 있다. 이러한 방식으로, 인증자는 가짜일 수도 있는 아이템들을 인증할 인센티브가 줄어든다. 실시예들에서, 잠금처리된 금액은, 대출 금액, 총 상환 금액, 평가 가치 또는 다른 적절한 가치와 같거나 그 소정의 백분율일 수 있으며, 여기서, 잠금처리될 금액은 평가 스테이지 거버넌스에 따라 정의된다. 일부 실시예에서, 인증된 아이템이 나중에 가짜인 것으로 밝혀지더라도 잠금처리된 통화로서 대출의 나머지 잔액을 초과하지 않는 인증자들로부터의 잠금처리된 통화가 미필적 상황을 제공하도록, 잠금처리된 통화 토큰들은 상환 과정 동안 인증자들에게 반환된다.
2214에서, 인증 스마트 계약 인스턴스는 대출의 상환시 인증 작업에 참여한 인증자들에게 보상 금액을 이전할 수 있다. 일단 대출 프로세스가 완료되고 나면(예를 들어, 대출금 상환 및 담보 아이템이 차용자에게 반환된 후; 담보 아이템을 검사하기 위해 담보 아이템의 구매자에게 매각된 후 미리규정된 양의 시간을 갖는 청산 이벤트 후) 및/또는 구매자가 대출에 참여하지 않기로 결정하고 담보 아이템의 소유권을 되찾고자 하는 경우) 인증 작업에 참여한 1차 인증자와 2차 인증자들에게 보상이 주어질 수 있다. 예를 들어, 인증자들은, 대출 또는 상환 금액의 백분율, 미리정의된 수수료, 및/또는 기타 등등으로 보상받을 수 있다. 일단 대출 프로세스가 완료되고 나면, 인증 스마트 계약의 인스턴스가 해체될 수 있다.
도 22의 예는 예시적인 인증 워크플로우로서 제공된다. 인증 작업들과 관련하여 다른 인증 워크플로우가 실행될 수도 있다. 또한, 각각의 인증 길드들 내에서, 각각의 인증 길드들의 멤버들은 인증 워크플로우 및/또는 인증 스마트 계약을 정교화하여 소정의 작업들의 인증을 개선할 수 있는데, 이러한 정교화들이 인증 스테이지-레벨 거버넌스를 따른다는 가정하에서다.
도 20을 다시 참조하면, 평가 스테이지-레벨 거버넌스는 평가 작업들에 이용될 수 있는 평가 스마트 계약(2030)의 참조(예를 들어, 주소)를 포함할 수 있다. 참조는 (예를 들어, 분산형 원장(2016)으로부터) 평가 스마트 계약(2030)을 회수하는데 이용될 수 있는 주소를 정의할 수 있다. 이들 실시예에서, 대출 프로세스 스마트 계약(2022), 평가자 디바이스(2006), 및/또는 토큰화 플랫폼(100)은, 평가자가 새로운 평가 작업을 할당받고/받거나 평가자가 평가자 디바이스(2006)를 통해 새로운 평가 작업을 수락하는 것에 응답하여 평가 스마트 계약(2030)의 한 인스턴스를 인스턴스화할 수 있다. 일단 인스턴스화되고 나면, 평가 스마트 계약(2030)의 인스턴스는 분산형 원장(2016)에 기입될 수 있고, 여기서 평가 스마트 계약 인스턴스는 평가 작업을 관리하기 위해 실행된다. 실시예들에서, 평가 스마트 계약(2030)은, 평가자 디바이스(2006), 차용자 디바이스(2002), 및/또는 토큰화 플랫폼(100)으로부터 입력을 수신하도록 구성될 수 있고, 수신된 입력에 기초하여 평가 작업과 관련한 모든 요구되는 단계들이 수행되었는지를 결정하는 조건부 로직을 포함할 수 있다.
도 23은 평가 워크플로우를 수행하기 위해 실행될 수 있는 방법(2300)의 예시적인 동작 세트를 나타낸다. 이 방법(2300)은, 평가 스마트 계약(2030) 또는 대출 프로세스 스마트 계약(2022) 등의 스마트 계약에 의해 실행될 수 있다. 설명의 목적을 위해, 방법(2300)은 평가 스마트 계약에 의해 수행되는 것으로 설명된다.
2302에서, 평가 스마트 계약(2030)의 한 인스턴스는 평가자 디바이스(2006)로부터 담보 아이템의 수령인의 확인을 수신할 수 있다. 일부 시나리오에서, 담보 아이템은 작업을 수행하기 위해 1차 평가자에게 물리적으로 전송된다. 이러한 시나리오에서, 1차 평가자는 평가자 디바이스(2006)를 이용하여 담보 아이템의 수령을 확인할 수 있다. 이들 실시예에서, 평가자는 담보 아이템의 이미지들을 제공할 수 있고 아이템의 가시적인 손상을 기록할 수 있다. 대안으로서, 1차 평가자에게 담보 아이템의 VIRL이 전송될 수 있다. 이들 실시예에서, VIRL은 평가 작업을 수행하는데 있어서 인증자를 보조할 수 있는 담보 아이템 및/또는 다른 미디어의 초고해상도 이미지들을 포함할 수 있다. 일부 실시예에서, 평가자는, 한 세트의 인증자들이 담보 아이템을 인증했다는 확인 등의, 추가 정보를 수신할 수 있다.
2304에서, 평가 스마트 계약 인스턴스는 1차 평가자의 평가자 디바이스(2006)로부터 평가 보고 및 지원 문서를 수신할 수 있다. 이들 실시예에서, 1차 평가자는, 평가자가 속한 평가 길드의 평가 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스에 따라 평가 보고를 생성할 것을 요구받을 수 있다. 일부 실시예에서, 1차 평가자는 평가 스테이지-레벨 거버넌스 및/또는 평가자의 평가 길드의 길드-레벨 거버넌스에 포함된 양식 템플릿을 이용하여 보고를 생성할 수 있다. 보고에서, 평가자에 의해 결정된 평가 가치와 평가 가치를 뒷받침하는 문서가 표시될 수 있다. 지원 문서에는, 유사한 아이템의 블루북 가치에 대한 링크, 유사한 아이템의 판매 스크린샷, 유사한 아이템의 판매와 관련된 이력 데이터, 및/또는 평가자의 평가 가치를 뒷받침하는 기타의 적절한 정보가 포함될 수 있다. 일단 평가자가 평가 보고를 제공하고 나면, 보고 및 지원 문서가 한 명 이상의 2차 평가자(들)에게 제공될 수 있다(평가 스테이지-레벨 거버넌스에 의해 요구되는 경우). 일부 실시예에서, 평가자의 평가 스테이지-레벨 거버넌스 또는 길드-레벨 거버넌스는 평가자가 평가 가치에 추가하여 평가 보고에 청산 가치를 제출할 것을 요구할 수 있다.
2306에서, 평가 스마트 계약 인스턴스는 하나 이상의 2차 평가자로부터 확인을 수신한다. 일부 실시예에서, 평가 스마트 계약(2030)은 1차 평가자의 보고를 수신하는 것에 응답하여 2차 평가자의 의견을 요청하는 조건부 로직을 포함할 수 있다. 일부 실시예에서, 평가 스마트 계약(2030)(또는 1차 평가자)은 1차 평가자 평가자의 보고 및 지원 증거를 2차 평가자들에게 제공할 수 있고(그들에게 작업이 할당된 후) 2차 평가자들로부터 응답들을 청취할 수 있다. 일단 수신되고 나면, 평가 스마트 계약(2030)은 필요한 수의 2차 평가자들이 1차 평가자의 평가액을 확인했는지를 결정할 수 있다.
2308에서, 평가 보고, 지원 문서, 및 2차 평가자의 의견에 기초한 데이터 블록이 생성되고, 데이터 블록이 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 평가 스마트 계약은 데이터 블록을 생성하고 데이터 블록을 분산형 원장(206)에 기입할 수 있다. 대안으로서, 평가 스마트 계약은, 평가 보고, 지원 문서, 및 2차 평가자의 의견을 원장 관리 시스템(202)(또는 다른 적절한 시스템)에 전송할 수 있으며, 원장 관리 시스템(202)(또는 다른 적절한 시스템)은, 차례로, 데이터 블록을 생성하고 그 데이터 블록을 분산형 원장(2016)에 기입할 수 있다. 일부 실시예에서, 데이터 블록은 평가자에 의해 결정된 담보 아이템의 청산 가치를 더 포함할 수 있다.
2310에서, 평가 스마트 계약은 평가 작업의 결과를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 특히, 평가 스마트 계약은 평가 가치를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 차용자가 대출 합의에 동의한다고 가정하면, 평가 프로세스에 참여한 평가자(들)가 보상을 받을 때까지(예를 들어, 상환 자금 및/또는 청산 이벤트의 진행으로부터) 평가 스마트 계약이 평가 워크플로우를 통해 계속 진행될 수 있다. 차용자가 대출 계약을 형성하지 않고 대출 프로세스를 종료하기로 결정한 경우, 평가 스마트 계약은 평가 작업을 종료할 수 있다.
2312에서, 평가 스마트 계약은, 아이템이 평가자에 의해 제공한 평가 가치 이상으로 청산되지 않는 경우, 평가를 안전하게 보호하기 위해 평가자들로부터 소정 금액의 통화를 잠금처리할 수 있다. 일부 실시예에서, 평가 스마트 계약(2030)은, 평가 스테이지-레벨 거버넌스 및/또는 평가자의 길드의 길드-레벨 거버넌스에 나와 있는 요건을 시행하여 평가자(들)가 평가 가치를 제공할 때 소정 금액의 통화(예를 들어, 통화/토큰화된 토큰들)를 잠금처리하여 대출자에게 더 많은 담보를 제공할 수 있다. 이러한 방식으로, 평가자는 대출 합의가 체결될 가능성을 높이기 위해 더 높은 가격으로 아이템을 평가할 동기부여가 줄어든다. 실시예들에서, 잠금처리된 금액은, 대출 금액, 총 상환 금액, 평가 가치 또는 다른 적절한 가치와 같거나 그 소정의 백분율일 수 있으며, 여기서, 잠금처리될 금액은 평가 스테이지 거버넌스에 따라 정의된다. 일부 실시예에서, 평가된 아이템이 청산 이벤트에서 평가 가치보다 낮은 값으로 판매되더라도 잠금처리된 통화로서 대출의 나머지 잔액을 초과하지 않는 평가자들로부터의 잠금처리된 통화가 미필적 상황을 제공하도록, 잠금처리된 통화 토큰들은 상환 과정 동안 평가자들에게 반환된다.
2314에서, 평가 스마트 계약은 대출의 상환시 평가 작업에 참여한 평가자들에게 보상 금액을 이전할 수 있다. 일단 대출 프로세스가 완료되고 나면(예를 들어, 대출의 상환 및 담보 아이템이 차용자에게 반환된 후 또는 청산 이벤트 후) 평가 작업에 참여한 1차 평가자 및 2차 평가자들에게 보상을 지급할 수 있다. 예를 들어, 평가자들은, 대출 또는 상환 금액의 백분율, 미리정의된 수수료, 및/또는 기타 등등으로 보상받을 수 있다. 일단 대출 프로세스가 완료되고 나면, 평가 스마트 계약의 인스턴스가 해체될 수 있다.
도 23의 예는 예시적인 평가 워크플로우로서 제공된다. 평가 작업들과 관련하여 다른 평가 워크플로우들이 실행될 수도 있다. 또한, 각각의 평가 길드들 내에서, 각각의 평가 길드들의 멤버들은 평가 워크플로우들 및/또는 평가 스마트 계약들을 정교화하여 소정의 작업들의 평가를 개선할 수 있는데, 이러한 정교화들이 평가 스테이지-레벨 거버넌스를 따른다는 가정하에서다.
도 20을 다시 참조하면, 보관 스테이지-레벨 거버넌스는 평가 작업들에 이용될 수 있는 보관 스마트 계약(2032)의 참조(예를 들어, 주소)를 포함할 수 있다. 참조는 (예를 들어, 분산형 원장(2016)으로부터) 보관 스마트 계약(2032)을 회수하는데 이용될 수 있는 주소를 정의할 수 있다. 이들 실시예에서, 대출 프로세스 스마트 계약(2022), 평가자 디바이스(2006), 및/또는 토큰화 플랫폼(100)은, 보관자가 새로운 평가 작업을 할당받고/받거나 보관자가 보관 디바이스(2008)를 통해 새로운 보관 작업을 수락하는 것에 응답하여 보관 스마트 계약(2030)의 한 인스턴스를 인스턴스화할 수 있다. 일단 인스턴스화되고 나면, 평가 스마트 계약(2030)의 인스턴스는 분산형 원장(2016)에 기입될 수 있고, 여기서 보관 스마트 계약 인스턴스는 보관 작업을 관리하기 위해 실행된다. 실시예들에서, 보관 스마트 계약(2032)은, 보관자 디바이스(2008), 차용자 디바이스(2002), 및/또는 토큰화 플랫폼(100)으로부터 입력을 수신하도록 구성될 수 있고, 수신된 입력에 기초하여 보관 작업과 관련한 모든 요구되는 단계들이 수행되었는지를 결정하는 조건부 로직을 포함할 수 있다.
도 24는 보관 워크플로우를 수행하기 위해 실행될 수 있는 방법(2400)의 예시적인 동작 세트를 나타낸다. 이 방법(2400)은, 보관 스마트 계약(2032) 또는 대출 프로세스 스마트 계약(2022) 등의 스마트 계약에 의해 실행될 수 있다. 설명의 목적을 위해, 방법(2400)은 보관 스마트 계약의 한 인스턴스에 의해 수행되는 것으로 설명된다.
2402에서, 보관 스마트 계약(2032)의 한 인스턴스는 보관자 디바이스(2008)로부터 담보 아이템의 수령인의 확인을 수신할 수 있다. 일부 시나리오에서, 담보 아이템은 대출의 보류 동안 보관을 위해 보관자에게 전송된다. 대안으로서, 아이템은 차용자 등의 또 다른 당사자에 의해 보관자에게 예치될 수 있다. 어느 시나리오에서나, 보관자는 평가자 디바이스(2006)를 이용하여 담보 아이템의 수령을 확인할 수 있다. 이들 실시예에서, 보관자는 담보 아이템의 이미지들을 촬영하고 아이템에서 볼 수 있는 임의의 손상을 기록하는 등의, 수령시 담보 아이템을 문서화할 수 있다.
2404에서, 보관 스마트 계약 인스턴스는 보관자의 보관자 디바이스(2008)로부터 보관 보고 및 지원 문서를 수신할 수 있다. 이들 실시예에서, 보관자는, 보관 스테이지-레벨 거버넌스 및/또는 보관자가 속한 보관자 길드(이러한 길드가 존재하는 범위 내에서)의 길드-레벨 거버넌스에 따라 보관 보고를 생성할 것을 요구받을 수 있다. 일부 실시예에서, 보관자는 보관자 스테이지-레벨 거버넌스 및/또는 보관자 길드의 길드-레벨 거버넌스에 포함된 양식 템플릿을 이용하여 보고를 생성할 수 있다. 보고에서, 보관자는, 아이템이 수령되었다는 것, 아이템이 수령된 상태, 담보 아이템에서 눈에 보이는 임의의 손상, 아이템이 보관되어 있는 위치, 아이템이 안전하게 보관되었는지 여부, 및/또는 기타의 관련 정보를 나타낼 수 있다. 실시예들에서, 보관자는, 눈에 띄는 손상에 대한 임의의 문서, 보관 중인 아이템의 이미지 등을 포함한, 담보 아이템의 이미지 등의 지원 문서를 제공할 수 있다. 일단 보관자가 보관 보고를 제공하고 나면, 보관자 보고 및 지원 문서가 분산형 원장(2016)에 기입될 수 있다.
2406에서, 보관 보고 및 지원 문서에 기초한 데이터 블록과 2차 평가자의 의견이 생성되고, 데이터 블록이 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 보관 스마트 계약은 데이터 블록을 생성하고 데이터 블록을 분산형 원장(206)에 기입할 수 있다. 대안으로서, 보관 스마트 계약은, 보관 보고, 지원 문서, 및 2차 평가자의 의견을 원장 관리 시스템(202)(또는 다른 적절한 시스템)에 전송할 수 있으며, 원장 관리 시스템(202)(또는 다른 적절한 시스템)은, 차례로, 데이터 블록을 생성하고 그 데이터 블록을 분산형 원장(2016)에 기입할 수 있다.
2408에서, 보관 스마트 계약 인스턴스는 보관 동안 자산 손실 또는 손상과 연관된 위험을 완화하기 위해 보관자로부터 소정 금액의 통화를 잠금처리할 수 있다. 일부 실시예에서, 보관 스마트 계약(2030)은 보관 스테이지-레벨 거버넌스 및/또는 길드-레벨 거버넌스에 개시된 요건을 시행하여 아이템이 보관될 때 소정 금액의 통화(예를 들어, 통화/토큰화 토큰들)를 잠금처리하여 대출자에게 더 많은 담보를 제공할 수 있다. 실시예들에서, 잠금처리된 금액은, 대출 금액, 총 상환 금액, 평가 가치 또는 다른 적절한 가치와 같거나 그 소정의 백분율일 수 있으며, 여기서, 잠금처리될 금액은 보관 스테이지 거버넌스에 따라 정의된다. 일부 실시예에서, 보관된 담보 아이템이 손상되었거나 분실되더라도 잠금처리된 통화로서 대출의 나머지 잔액을 초과하지 않는 보관자로부터의 잠금처리된 통화가 미필적 상황을 제공하도록, 잠금처리된 통화 토큰들은 상환 과정 동안 보관자에게 반환된다. 2410에서, 보관 스마트 계약 인스턴스는, 담보 아이템이 안전하게 보호되었고 보관 작업과 관련된 이벤트 기록들(2052)이 분산형 원장(2016)에 기입되었음을 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다.
2412에서, 보관 스마트 계약 인스턴스는 상환 이벤트시 담보 아이템에 대응하는 담보 토큰(2042)의 소유자에게로의 담보 아이템의 소유권 이전을 용이화할 수 있다. 실시예들에서, 담보 토큰(2042)의 상환은 오프체인으로(예를 들어, 토큰화 플랫폼(100) 등의 신뢰할 수 있는 제3자의 컴퓨팅 시스템에 의해) 및/또는 온체인으로(예를 들어, 하나 이상의 스마트 계약의 인스턴스에 의해) 실행될 수 있는 담보 상환 워크플로우에 따라 수행될 수 있다. 실시예들에서, 담보 상환 워크플로우는 다음과 같은 동작들을 포함할 수 있지만 이것으로 제한되는 것은 아니다: 담보 토큰(2042)에 의해 표시된 담보 아이템을 상환하라는 요청을 사용자 디바이스로부터 수신하는 단계; 담보 토큰(2042)의 상환을 시도하고 있는 사용자가 담보 토큰(2042)의 정당한 소유자인지를 분산형 원장(2016)에 저장된 소유권 데이터(2052)에 기초하여 확인하는 단계; 분산형 원장(2016) 및/또는 대출 프로세스 스마트 계약(2022)으로부터 담보 토큰(2042)에 의해 표시된 담보 아이템의 보관자를 식별하는 단계; 정당한 소유자가 담보 토큰(2042)을 상환했다는 상환 통보를 식별된 보관자의 보관자 디바이스(2008)에 전송하는 단계; 담보 토큰의 정당한 소유자가 담보 아이템의 소유권을 취득했음을 나타내는 확인 통보를 식별된 보관자의 보관자 디바이스(2008)로부터 수신하는 단계; 및 (전술된 바와 같이) 보관자로부터 통보를 수신한 것에 응답하여 담보 토큰(2042)을 소각하는 단계. 실시예들에서, 상환 워크플로우는 담보 아이템이 만족스러운 상태로 반환되었음을 나타내는 피드백을 담보 아이템의 상환 소유자로부터 수신하고/하거나 (분석 및/또는 보관자의 등급을 업데이트하는데 이용할 수 있는) 이러한 피드백 이벤트들의 발생 및 내용을 나타내기 위해 분산형 원장(2016)을 업데이트하는 것 등의, 추가적인 또는 대안적인 단계들을 포함할 수 있다.
2414에서, 보관 스마트 계약은 대출의 상환 및/또는 담보 아이템의 상환시 보관자에게 보상 금액을 이전할 수 있다. 예를 들어, 보관자는, 대출 또는 상환 금액의 백분율, 미리정의된 수수료, 및/또는 기타 등등으로 보상받을 수 있다. 일단 대출 프로세스가 완료되고 나면, 보관 스마트 계약의 인스턴스가 해체될 수 있다.
도 24의 예는 예시적인 보관 워크플로우로서 제공된다. 보관 작업들과 관련하여 다른 보관 워크플로우들이 실행될 수도 있다. 또한, 각각의 보관자 길드 내에서, 각각의 길드의 멤버들은 보관 워크플로우들 및/또는 보관자 스마트 계약들을 정교화하여 소정의 아이템들의 보관을 개선할 수 있는데, 이러한 정교화들이 보관 스테이지-레벨 거버넌스를 따른다는 가정하에서다.
도 20을 다시 참조하면, 대출 스테이지-레벨 거버넌스는, 대출의 상환을 모니터링하는데 이용될 수 있는 대출 스마트 계약(2034)의 참조(예를 들어, 주소)를 포함할 수 있다. 참조는 (예를 들어, 분산형 원장(2016)으로부터) 대출 스마트 계약(2034)을 회수하는데 이용될 수 있는 주소를 정의할 수 있다. 이들 실시예에서, 대출 프로세스 스마트 계약(2022), 차용자 디바이스(2002), 대출자 디바이스(2010) 및/또는 토큰화 플랫폼(100)은, 대출 합의에 도달하는 것에 응답하여 대출 스마트 계약(2034)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출의 협상은 오프체인으로(예를 들어, 토큰화 플랫폼(100)을 통해) 차용자 및 대출차에 의해 수행된다. 이들 실시예에서, 대출 스마트 계약 인스턴스는 대출 합의의 조건에 대한 당사자들의 동의에 응답하여 인스턴스화될 수 있다. 일단 인스턴스화되고 나면, 대출 스마트 계약 인스턴스는 분산형 원장(2016)에 기입될 수 있고, 여기서 대출 스마트 계약 인스턴스는 대출 상환 스테이지를 관리하기 위해 실행된다. 실시예들에서, 대출 스마트 계약(2034)은, 차용자 디바이스(2002), 대출 디바이스(2010), 및/또는 토큰화 플랫폼(100)으로부터 입력을 수신하도록 구성될 수 있다.
도 25는 대출 상환 워크플로우를 수행하기 위해 실행될 수 있는 방법(2500)의 예시적인 동작 세트를 나타낸다. 이 방법(2500)은, 대출 스마트 계약(2034) 또는 대출 프로세스 스마트 계약(2022) 등의 스마트 계약에 의해 실행될 수 있다. 설명의 목적을 위해, 방법(2500)은 대출 스마트 계약의 한 인스턴스에 의해 수행되는 것으로 설명된다. 도시된 예에서, 대출 스마트 계약(2034)은 차용자와 대출자가 오프체인 대출 합의에 동의할 때 인스턴스화될 수 있다. 그러나, 일부 실시예에서, 대출 계약(2032)은 역시 대출의 협상을 용이화하도록 구성될 수 있다.
2502에서, 대출 스마트 계약(2034)의 한 인스턴스는 대출 합의 조건을 수신할 수 있고 대출 합의 조건에 따라 상환 일정을 확립할 수 있다. 일부 시나리오에서, 대출 스마트 계약(2034)은 대출 합의의 협상을 용이화한 컴퓨팅 시스템(예를 들어, 토큰화 플랫폼)으로부터 대출 합의 조건을 수신할 수 있다. 대출 합의 조건은, 대출 금액, 대출 조건, 대출 상환 금액, 이자율, 연체료 벌금, 채무불이행 조건 정의 등을 포함할 수 있다. 실시예들에서, 대출 스마트 계약 인스턴스는, 상환 금액 및 대출 조건에 기초하여 상환 일정을 결정할 수 있다. 대출 스마트 계약 인스턴스는, 대출 기간에 관해 지불들이 균등하게 분산되도록 상환 일정을 결정할 수 있다. 대출 스마트 계약 인스턴스는 기타 임의의 적절한 방식으로 상환 일정을 결정할 수 있다.
2504에서, 대출 스마트 계약 인스턴스는 에스크로 계정에 담보 토큰을 잠금처리하고 대출자의 계정으로부터 차용자로의 자금 이전을 용이화한다. 실시예들에서, 일단 대출 합의가 준비되고 나면, 대출 스마트 계약 인스턴스는 대출 상환 기간 동안 에스크로 계정에 담보 토큰을 잠금처리할 수 있다. 일단 담보 토큰이 잠금처리되고 나면, 차용자가 담보 토큰을 상환하는 것을 방지할 수 있으며, 대출 스마트 계약 인스턴스는 대출자의 계정으로부터 구매자의 계정으로의 대출 금액과 동일한 자금의 이전을 용이화할 수 있다. 일부 실시예에서, 대출 스마트 계약 인스턴스는 차용자의 계정을 반영하도록 대출자가 소유한 한 세트의 통화/토큰화된 토큰들(2044)의 소유권 데이터(2054)를 업데이트함으로써 자금을 이전할 수 있다.
2506에서, 대출 스마트 계약 인스턴스는 지불 이벤트 통보를 청취한다. 실시예들에서, 대출 스마트 계약(2034)은 지불 이벤트 통보를 청취하는 이벤트 청취자로 구성될 수 있다. 일부 실시예에서, 지불 이벤트 통보는, 차용자 디바이스(2002), 대출자 디바이스(2004), 또는 대출의 상환을 용이화하는 신뢰할 수 있는 제3자 컴퓨팅 시스템(예를 들어, 토큰화 플랫폼(100))으로부터 수신될 수 있다. 실시예들에서, 지불 이벤트 통보는 지불된 금액 및 지불이 수신된 날짜 및/또는 시간을 나타낼 수 있다.
2508에서, 대출 스마트 계약 인스턴스는 일정에 있는 지불이 수신되었는지를 결정할 수 있다. 지불을 수신하지 못한 경우, 대출 스마트 계약 인스턴스는 대출 합의에 따라 대출이 채무불이행 상태인지를 결정할 수 있다. 대출이 채무불이행 상태가 들어가기 전에 얼마나 많은 지불이 누락될 수 있는지를 대출 합의가 정의할 수 있도록, 차용자가 하나 이상의 지불을 누락한 경우, 대출은 채무불이행 상태가 될 수 있다. 대출이 채무불이행 상태가 아닌 경우, 대출 스마트 계약 인스턴스는 임의의 벌금 및/또는 수수료를 원금 잔액에 적용할 수 있으며 계속해서 지불 이벤트 통보를 청취할 수 있다.
대출이 채무불이행 상태에 있는 경우, 대출 스마트 계약 인스턴스는, 2512에 도시된 바와 같이, 담보 아이템의 청산을 개시할 수 있다. 일부 실시예에서, 대출 스마트 계약 인스턴스는, 담보 토큰(2042) 및/또는 그 안에 래핑된 VIRL을 나타내는 청산 요청을 시장(예를 들어, 시장 시스템(102))에 제공할 수 있다. 청산 요청은, 평가 금액, 평가 기록, 인증 기록, 보관 기록, 및/또는 대출 상환 금액의 나머지 잔액 등의, 추가 데이터를 포함할 수 있다. 이에 응답하여, 시장은 청산 판매를 수행할 수 있다. 실시예들에서, 청산 판매는 (예를 들어, 평가 가치로 설정된) 고정 가격 판매 또는 (예를 들어, 대출 상환 금액의 나머지 잔액에서 개시하는) 경매일 수 있다. 일단 아이템이 청산되고 구매자가 담보 아이템에 대해 지불하고 나면, 대출 스마트 계약 인스턴스는 아이템이 청산되었음을 나타내는 청산 통보를 수신할 수 있다. 이에 응답하여, 대출 스마트 계약 인스턴스는, 채무불이행시 대출을 안전하게 보호하는데 이용된 담보 토큰(2042)의, 보유된 에스크로 계정으로부터 담보 아이템의 구매자의 계정으로의 이전을 개시할 수 있다. 일단 담보 토큰(2042)이 구매자에 의해 소유되어 있다는 것을 담보 토큰의 소유권 데이터(2054)가 나타내도록 업데이트되고 나면, 구매자는 담보 토큰(2042)을 상환할 수 있다(예를 들어, 본 개시내용 전체에 걸쳐 설명된 바와 같이). 실시예들에서, 대출의 나머지 잔액은 판매 수익으로부터 대출자에 지불될뿐만 아니라 보상이 대출 프로세스의 참여자들(예를 들어, 인증자들, 평가자들, 및/또는 보관자들)에게 지불된다. 2514에서, 대출 스마트 계약 인스턴스는 채무불이행 이벤트를 나타내는 데이터 블록을 생성할 수 있고 데이터 블록을 분산형 원장에 기입함으로써, 채무불이행 이벤트의 기록을 생성할 수 있다.
2508에서 지불이 수신된 경우, 대출 스마트 계약 인스턴스는, 2516에 도시된 바와 같이, 대출이 전액 지불되었는지를 결정할 수 있다. 대출이 전액 지불되지 않은 경우, 대출 스마트 계약 인스턴스는 대출 상환 금액에 대한 나머지 잔액을 결정할 수 있다. 일부 실시예에서, 대출 스마트 계약 인스턴스는, 그들 각각의 인증, 평가, 및 보관 작업들의 수행과 관련하여 토큰들을 위험부담성 출자한 길드 멤버들의 통화/토큰화된 토큰들(2044)을 잠금해제할 수 있다. 실시예들에서, 대출 스마트 계약 인스턴스는, 2518에 도시된 바와 같이, 수신된 지불에 비례하는 토큰의 양을 잠금해제할 수 있다. 이들 실시예에서, 임의의 길드 멤버의 나머지 잠금처리된 토큰들은 대출 상환 금액의 나머지 잔액을 초과하지 않는다.
2516에서, 대출 스마트 계약 인스턴스가 대출이 전액 지불되었다고 결정하면, 대출 스마트 계약 인스턴스는 상환 이벤트를 나타내는 데이터 블록을 생성할 수 있고, 1520에 도시된 바와 같이, 데이터 블록을 분산형 원장에 기입할 수 있다. 이러한 방식으로, 대출 스마트 계약 인스턴스는 대출이 전액 지불되었음을 나타내는 상환 이벤트의 기록을 생성한다. 일단 대출이 전액 상환되고 나면, 대출 스마트 계약 인스턴스는 대출을 통제하는 대출 프로세스 스마트 계약 인스턴스 및/또는 토큰화 플랫폼(100)에 상환 통보를 발행할 수 있되, 통보가 대출 프로세스의 참여자들(예를 들어, 인증자들, 평가자들, 및/또는 보관자들)에게 보상 지급을 개시하게 한다.
2522에서, 대출 스마트 계약 인스턴스는 에스크로 계정으로부터 담보 토큰(2042)을 잠금해제할 수 있고 소유권을 차용자에게 복원시킬 수 있다. 실시예들에서, 대출 스마트 계약 인스턴스는, 차용자가 다시 한번 담보 토큰의 소유자임을 반영하도록 담보 토큰(2042)의 소유권 데이터(2054)를 업데이트할 수 있다. 일단 대출 프로세스가 완료되고 나면, 보관 스마트 계약의 인스턴스가 해체될 수 있다.
도 25의 예는 대출 상환 워크플로우의 한 예로서 제공된다. 본 개시내용의 범위를 벗어나지 않고 대출 및 대출 상환과 관련하여 다른 대출 상환 워크플로우들이 실행될 수 있다.
도 20을 다시 참조하면, 일부 실시예에서, 탈집중형 대출 프로세스의 상이한 변형들이 대출전 청산 이벤트를 포함할 수 있다. 대출전 청산 이벤트는 대출이 협상되기 전에 수행되는 조건부 청산 판매일 수 있다. 판매는, 판매에 앞서 가격이 설정되는 정가 판매, 또는 담보 아이템이 경매되는 경매 판매일 수 있다는 점에 유의한다. 일부 실시예에서, 예시적인 대출 프로세스 워크플로우는, 요청 스테이지, 이에 후속되는 인증 스테이지, 안전 보관 스테이지, 토큰화 스테이지(임의의 적절한 순서로), 이에 후속되는 대출전 청산 스테이지를 포함할 수 있고, 청산 스테이지에 후속하여, 대출 스테이지와 상환 스테이지가 뒤따른다. 이들 예시적인 실시예에서, 일단 담보 아이템들이 인증되고, 에스크로잉되고, 토큰화되고 나면, (예를 들어, 시장 시스템(102)을 통해) 담보 아이템에 대해 경매 또는 정가 판매 가격에서 수행되고, 이에 의해 담보 아이템의 구매자는, 차용자의 채무불이행시에(또는 차용자가 대출을 포기하고 아이템에 대한 소유권을 포기하기로 결정한 경우) 트리거되는 소유권 옵션을 획득한다. 이러한 방식으로, 차용자와 대출자는 대출이 협상되기 전에 담보 아이템의 실제 가치를 알고, 이것은 차용자가 차용할 수 있는 금액을 결정하고 평가자에 대한 필요성을 제거한다. 또한, 일부 실시예에서, 미필적 구매자(contingent buyer)는 구매한 아이템(또는 그 일부)의 금액과 동일한 금액의 통화/토큰화된 토큰(2046)을 에스크로잉하고/하거나 그 판매를 충당하기에 충분한 자금이 있다는 것을 증명할 것이 요구될 수도 있다(예를 들어, 구매자의 계좌 주소를 제공하거나 은행 정보를 제공함으로써). 그 대가로, 미필적 구매자는 차용자가 대출을 성공적으로 상환할 경우 상환 금액의 일부를 보상을 받을 수 있고, 여기서, 보상 금액은, 고정 수수료, 판매 가격의 소정 백분률, 또는 이자 기반 보상일 수 있다.
예시적인 실시예들에서, 대출전 청산 스테이지를 둘러싼 규칙들 및 규정들은 대출전 청산 스테이지-레벨 거버넌스에서 정의된다. 이들 실시예에서, 대출전 청산 스테이지-레벨 거버넌스는 다음과 같이 규칙들을 정교화하고/하거나 정의할 수 있다: 미필적 구매자가 미필적 판매를 확보하기 위해 예치해야 하는 통화의 양; 대출이 성공적으로 상환되면 미필적 구매자에게 제공되는 금전적 보상 금액; 대출전 청산 이벤트의 허용된 메커니즘(예를 들어, 경매, 정가 판매 등); 및 기타의 적절한 규칙들 및 규정들.
일부 실시예에서, 대출전 청산 스테이지-레벨 거버넌스는 대출전 청산 이벤트를 용이화하는데 이용될 수 있는 대출전 청산 스마트 계약(미도시)의 참조(예를 들어, 주소)를 포함할 수 있다. 참조는 (예를 들어, 분산형 원장(2016)으로부터) 대출전 청산 스마트 계약을 회수하는데 이용될 수 있는 주소를 정의할 수 있다. 이들 실시예에서, 대출 프로세스 스마트 계약(2022) 및/또는 토큰화 플랫폼(100)은, 대출 프로세스가 대출전 청산 스테이지로 진행하는 것에 응답하여 대출전 청산 스마트 계약의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출전 청산 스마트 계약은, 차용자 디바이스(2002), 미필적 구매자 디바이스, 대출 프로세스 스마트 계약(2022), 대출 프로세스 스마트 계약(2028), 및/또는 토큰화 플랫폼(100)(예를 들어, 시장 시스템(102))으로부터 입력을 수신하도록 구성될 수 있다. 일단 인스턴스화되고 나면, 대출전 청산 스마트 계약의 인스턴스는 분산형 원장(2016)에 기입될 수 있으며, 여기서, 대출전 청산 스마트 계약 인스턴스는, 대출전 청산 판매 스테이지, 거래 확인 스테이지, 및 미필적 상황 해결 스테이지를 포함할 수 있는 대출전 청산 워크플로우를 실행한다. 예시적인 실시예들에서, 대출전 청산 스마트 계약은, 담보 아이템에 대응하는 담보 토큰에 기초하여 대출전 청산 이벤트를 개시하는, 대출전 청산 판매 스테이지 동안 담보 아이템의 판매를 개시할 수 있다. (미필적 상황에 따라) 담보 아이템이 판매되었다고 가정하면, 대출전 청산 스마트 계약은 거래 확인 스테이지를 실행할 수 있고, 여기서, 차용자에게는 다음과 같은 기회가 제공된다: a) 판매 가격을 거부하고 대출 프로세스를 종료; b) 담보 아이템을 미필적 구매자에게 판매 가격에 판매하는데 동의하고 대출 프로세스를 종료; 또는 c) 주어진 판매 가격에서 대출 프로세스를 진행. 미필적 상황 해결 스테이지 동안, 대출전 청산 스마트 계약 인스턴스는 후속 대출 상태와 관련된 통보를 수신할 수 있으므로, 대출이 전액 상환되면, 대출전 청산 스마트 계약은 에스크로 계정으로부터 차용자에게로의 담보 토큰(2042)의 이전을 개시할 수 있고 정의된 보상 금액으로 미필적 구매자에게 보상할 수 있다. 반대로, 판매자가 채무불이행하면, 대출전 청산 스마트 계약은 담보 토큰(2042)을 에스크로 계정으로부터 구매자에게 이전할 수 있으며, 합의된 구매 가격을 대출자와 참여자들(예를 들어, 인증자들 및 보관자들)에게 이전하여, 임의의 나머지 잔액이 차용자에게 반환되게 할 수 있다.
도 26은 본 개시내용의 일부 실시예에 따른 대출전 청산 워크플로우를 수행하기 위한 방법(2600)의 예시적인 동작 세트를 나타낸다. 이 방법(2600)은, 대출전 청산 스마트 계약 또는 대출 프로세스 스마트 계약(2022) 등의, 스마트 계약에 의해 실행될 수 있다. 설명의 목적을 위해, 방법(2600)은 대출전 청산 스마트 계약의 한 인스턴스에 의해 수행되는 것으로 설명된다.
2602에서, 대출전 청산 스마트 계약 인스턴스는 담보 토큰(2052)(또는 담보 토큰의 블록 주소 등의, 표시자)을 수신한다. 2604에서, 대출전 청산 스마트 계약 인스턴스는 담보 토큰(2052)에 대응하는 VIRL을 결정한다. 일부 실시예에서, 대출전 청산 스마트 계약 인스턴스는, 담보 토큰(2042) 및/또는 분산형 원장(2016)으로부터 VIRL의 VIRL 식별자를 결정할 수 있다. 후자의 시나리오에서, 대출전 청산 스마트 계약 인스턴스는 토큰(2042)을 저장하는 분산형 원장(2016)으로부터 담보 토큰(2042)을 포함하는 데이터 블록을 판독할 수 있고 그로부터 VIRL 식별자를 획득될 수 있다.
2606에서, 대출전 청산 스마트 계약 인스턴스는 시장(예를 들어, 시장 시스템(102))에 담보 아이템의 미필적 판매 요청을 제공할 수 있다. 실시예들에서, 요청은 VIRL(또는 VIRL ID의 표시자 등) 및/또는 담보 아이템을 설명 및/또는 보여주는 기타 문서를 포함할 수 있다. 실시예들에서, 미필적 판매 요청은, 미필적 판매 유형(예를 들어, 경매 또는 정가 판매), 담보 아이템의 위치, 담보 아이템에 대한 추구 가격(정가 판매인 경우), 담보 아이템에 대한 최소 가격(경매인 경우), 미필적 상황의 기간(예를 들어, 차용자가 대출을 확보하고 상환하는데 필요한 시간), 보상 제안(예를 들어, 미리정의된 보상 금액 또는 구매 가격의 백분률, 원하는 대출 금액 또는 상환 금액), 및/또는 기타 등등의 다른 적절한 정보를 포함할 수 있다. 이에 응답하여, 시장은 미필적 판매를 용이화할 수 있으며, 이것은, 한 세트의 미필적 판매 또는 판매 없이 담보 아이템이 판매되는 결과를 초래할 수 있다(예를 들어, 미필적 구매자가 담보 아이템을 정가에 구매하거나 경매에서 낙찰됨).
2608에서, 대출전 청산 스마트 계약은 시장으로부터 미필적 판매의 결과를 수신할 수 있다. 일단 미필적 판매가 완료되고 나면, 시장은 대출전 청산 이벤트의 결과를 나타내는 판매 통보를 청산 스마트 계약 인스턴스에 전송할 수 있다. 실시예들에서, 대출전 청산 이벤트의 결과는, 아이템이 판매되었는지, 및 판매된 경우 아이템이 판매된 가격(판매를 호스팅하기 위해 시장에서 취한 수수료를 뺀 가격)을 나타낸다.
2610에서, 대출전 청산 스마트 계약은(담보 아이템의 대출전 판매가 발생했다고 가정) 미필적 판매 통보를 차용자의 차용자 디바이스(2002)에 제공할 수 있다. 미필적 판매 통보를 수신하는 것에 응답하여, 차용자는 대출 프로세스를 진행하기 위해 미필적 판매에 합의하거나, 미필적 판매를 거부하거나(예를 들어, 판매가 경매이고 합의된 청산 가격이 대출을 보호하기에 너무 낮은 경우), 또는 미필적 판매를 완료할(예를 들어, 판매가 경매이고, 가격이 구매자에게 담보 아이템을 이용하여 대출을 추구하는 것이 아니라 담보 아이템을 판매하도록 설득할 만큼 높은 경우) 옵션을 갖는다. 차용자가 판매를 거부하면, 2612에 도시된 바와 같이, 담보 토큰(2042)의 소유권을 유지한다. 차용자가 미필적 판매를 완료하는데 동의하면, 대출전 청산 스마트 계약은, 2614에 도시된 바와 같이, 미필적 구매자에게로의 담보 토큰(2042)의 이전과 구매자에게로의 판매 수익금(예를 들어, 통화/토큰화된 토큰 또는 법정 화폐로 된 구매 금액에서 시장 수수료를 뺀 값)의 이전을 개시할 수 있다. 차용자가 미필적 판매에 동의하는 경우, 대출전 청산 스마트 계약은, 2616에 도시된 바와 같이, 에스크로 계정의 담보 아이템을 잠금처리할 수 있다.
2618에서, 대출전 청산 스마트 계약 인스턴스는 미필적 판매 금액에 기초하여 미필적 구매자로부터 정의된 금액의 통화를 에스크로잉할 수 있다. 거래 확인 스테이지 동안, 대출이 채무불이행될 경우 미필적 구매자가 판매 가격을 지불할 수 있도록 보장하게끔 대출전 청산 스마트 계약이 구성될 수 있다. 일부 실시예에서, 대출전 청산 스마트 계약은, 에스크로 계정에 있는 미필적 구매자 계정으로부터 정의된 양의 통화/토큰화 토큰(2046)을 잠금처리함으로써 달성될 수 있는 전체 판매 금액 또는 전체 판매 금액의 일부(예를 들어, 50%)와 동일한 통화/토큰화된 토큰(2046)을 미필적 구매자에게 에스크로잉할 것을 요구할 수 있다. 대안으로서, 미필적 구매자는 유동성 임계값이 충족되었음을 증명하는 증거 문서(예를 들어, 은행 거래 내역서, 세금 명세서 등)를 제공할 수 있으며, 이로써 미필적 구매자는, 차용자의 채무불이행시, 판매를 완료할 수 있다는 확신을 제공할 수 있다. 이들 실시예에서, 대출전 청산 스마트 계약 인스턴스는 증거 문서를 분산형 원장(2016)에 기입할 수 있다.
2620에서, 대출전 청산 스마트 계약 인스턴스는 미필적 상황 판매를 해결할 수 있다. 일단 차용자가 조건에 동의하고 구매자가 판매 가격을 지불할 수 있다는 것을 확인하고 나면, 대출전 청산 스마트 계약 인스턴스가 미필적 상황 해결 스테이지를 실행할 수 있다. 미필적 상황 해결 스테이지 동안, 대출전 청산 스마트 계약 인스턴스는 대출 프로세스를 모니터링하여 차용자가 대출을 확보할 수 있었는지를 확인할 수 있다. 차용자가 대출을 안전하게 보호할 수 없고 대출 프로세스를 종료하기로 결정한 경우, 대출전 청산 스마트 계약은 미필적 구매자에게로의 엥스크로잉된 자금(및 잠재적으로 보상 수수료)의 환불을 개시할 수 있고 에스크로 계정으로부터 차용자의 계정으로의 담보 토큰(2042)의 이전을 개시할 수 있다. 차용자가 대출 합의를 들어간다고 가정하면, 대출전 청산 스마트 계약은 대출의 상환을 모니터링할 수 있다. 일부 실시예에서, 대출전 청산 스마트 계약은, (예를 들어, 대출을 통제하는 대출 프로세스 스마트 계약(2022) 또는 대출 스마트 계약(2034)으로부터) 차용자가 대출 합의의 조건에 따른 대출 상환에 관해 채무불이행한 것으로 간주되는 경우 채무불이행 통보를 수신할 수 있다. 이에 응답하여, 대출전 청산 스마트 계약은 미필적 구매자에게 담보 아이템의 나머지 잔액을 지불하라는 통보를 제공할 수 있다(구매자가 전체 금액을 에스크로에 넣지 않았다고 가정). 미필적 구매자가 가격의 전액을 지불했음을 확인할 때 또는 미필적 판매시 구매자가 전체 판매 가격을 에스크로잉한 경우, 대출전 청산 스마트 계약은 판매 금액이 확보되었다는 통보를 (예를 들어, 대출 프로세스 스마트 계약 인스턴스(2022) 및/또는 대출 스마트 계약(2034)에) 발행할 수 있고, 미필적 구매자에게로의 담보 토큰(2052)의 이전을 개시할 수 있다. 대출자에 대한 자금의 상환 및/또는 미필적 판매의 수익금으로부터의 보관자 및 인증자(들)에 대한 보상의 발행은 상이한 워크플로우를 통해 처리될 수 있다. 일부 실시예에서, 대출전 청산 스마트 계약은, 차용자가 대출의 전체 상환 금액(대출 금액 및 임의의 이자 및 수수료)을 성공적으로 상환할 때 상환 이벤트의 통보를 수신할 수 있다. 상환 통보의 수신시, 대출전 청산 스마트 계약 인스턴스는 다시 미필적 구매자에게로의 위험부담성 출자된 자금의 이전을 개시할 수 있고, 구매자가 미필적 상황 판매에 참여함으로써 대출을 안전하게 보호하는데 도움이 되도록 자금을 위험부담성 출자하는 것에 대한 보상으로서 미필적 구매자의 계정으로의 보상(예를 들어, 통화/토큰화 토큰 2046)의 이전을 개시할 수 있다. 실시예들에서, 보상 금액은 대출자에 의해 지불되고/되거나 대출의 상환 스테이지 동안 차용자에 의해 대출자에 이루어진 지불로부터 에스크로에 보관될 수 있다. 대출전 청산 워크플로우는 본 개시내용의 범위를 벗어나지 않고 추가적인 또는 대안적인 스테이지를 포함할 수 있다.
도 26의 예는 대출전 청산 워크플로우의 예로서 제공된다. 대출전 청산 이벤트와 관련하여 다른 대출전 청산 워크플로우들이 실행될 수 있다.
다시 도 20을 참조하면, 본 개시내용의 일부 실시예에 따르면, 탈집중형 대출 프로세스의 각각의 스테이지와 연관된 스마트 계약은, 특정한 작업을 수행하는 길드 멤버가 특정한 길드에 의해 설정된 길드-레벨 거버넌스뿐만 아니라 스테이지-레벨 거버넌스를 준수한다는 것을 보장하도록 구성된 다양한 유형의 길드-레벨 스마트 계약(또는 하위 길드-레벨 스마트 계약)을 포함할 수 있다. 예를 들어, 탈집중형 대출 프로세스와 연관된 스마트 계약은, 특히, 인증 프로세스의 한 인스턴스가 특정한 인증 길드-레벨 거버넌스(예를 들어, 시계 인증 길드-레벨 거버넌스)에 의해 정의된 인증 워크플로우를 준수한다는 것을 보장하도록 구성된 길드-레벨 인증 스마트 계약을 포함할 수 있다.
실시예들에서, 토큰화 플랫폼(100)의 하나 이상의 컴포넌트는, 증권화된, 탈집중형 대출 프로세스를 지원한다. 일부 실시예에서, 토큰화 플랫폼(100)은 대출 프로세스의 한 인스턴스를 개시하기 위해 차용자들(또는 다른 당사자들)로부터 요청들을 수신할 수 있다. 예시적인 실시예들에서, 담보 관리 시스템(804)은 사용자(예를 들어, 차용자)에게 GUI를 프리젠팅하여, 이에 의해 사용자는 GUI를 통해 새로운 대출 프로세스의 개시를 요청할 수 있다. 예를 들어, 사용자는, 위치 또는 대체적인 지역, 담보 아이템의 유형(예를 들어, 시계, 한 켤레의 운동화, 자동차, 위스키 콜렉션, 보석 등), 및 차용자가 확보하기를 원하는 대략적인 대출 금액을 제공할 수 있다. 일부 실시예에서, 담보 관리 시스템(804)은 요청을 수신할 수 있고 원장 관리 시스템(104)(또는 다른 적절한 시스템)에게 새로운 대출 프로세스 스마트 계약(2022)을 인스턴스화할 것을 지시할 수 있다. 실시예들에서, 대출 프로세스 스마트 계약(2022)은 탈집중형 대출 프로세스의 다양한 스테이지를 통해 대출 프로세스를 진행함으로써 대출 프로세스 워크플로우를 관리한다. 대안으로서, 담보 관리 시스템(2022)은, 대출 프로세스가 탈집중형 대출 프로세스의 스테이지들을 통해 진행됨에 따라 대출 프로세스 워크플로우를 관리할 수 있다. 논의된 바와 같이, 대출 프로세스 워크플로우는 탈집중형 대출 프로세스의 한 인스턴스와 관련하여 수행되는 한 세트의 스테이지들을 정의할 수 있고, 여기서, 스테이지들은 미리정의된 순서로 수행된다. 탈집중형 대출 프로세스들의 상이한 변형들은 상이한 대출 프로세스 워크플로우들을 구현할 수 있다. 대출 프로세스 워크플로우의 일련의 스테이지들의 한 예는 다음과 같을 수 있다 : 사용자가 새로운 대출 프로세스를 요청하는 요청 스테이지, 이에 후속하는, 차용자가 한 명 이상의 인증자에 의해 인증될 담보 아이템을 제공하는 인증 스테이지, 이에 후속하는, 한 명 이상의 평가자가 아이템을 평가하는 평가 스테이지(아이템이 진품인 것으로 간주되는 경우), 이에 후속하는, 보관자가 담보 아이템을 에스크로에 보관하는 보관 스테이지, 이에 후속하는, 담보 아이템을 나타내는 VIRL이 생성되고 VIRL이 토큰화되고 토큰화 스테이지, 이에 후속하는, 차용자가 한 명 이상의 대출자와 대출을 협상하는 대출 스테이지, 대출자가 대출금을 상환하거나 대출에 관한 채무불이행을 하는 상환 스테이지, 및 판매자가 상환 금액의 적어도 일부를 채무불이행한 경우 담보 아이템이 청산될 수 있고, 대출 프로세스의 다양한 참여자에게 보상이 지급되고/되거나 대출 프로세스의 결과에 기초하여 분석이 업데이트되는 대출후 스테이지. 상기의 대출 프로세스 워크플로우는 한 예시적인 대출 프로세스 워크플로우이며, 다른 대출 프로세스 워크플로우들이 공개되고 본 개시내용의 범위 내에 있다. 상이한 대출 프로세스 워크플로우들은 상이한 효율들을 달성할 수 있고 상이한 유형들의 담보 및/또는 대출 규모에 더 적합할 수 있다. 위에서 논의된 예시적인 대출 프로세스 워크플로우는, 아이템이 인증자에 의해 가짜인 것으로 간주되는 경우에 수행되는 스테이지의 수를 최소화하기 위한 것이다. 다른 워크플로우들은, 참여자들 사이에서 담보 아이템이 이전될 필요가 있는 횟수를 줄이는 것, 당사자들 사이에서 담보 아이템을 이전할 필요성을 완화하는 것, 대출 금액을 최대화하는 것, 및/또는 기타의 바람직한 효율 등의, 상이한 효율성을 달성할 수 있다.
일부 실시예에서, 담보 관리 시스템(804)은 사용자로부터 요청을 수신할 때 한 세트의 대출 프로세스 워크플로우들로부터 특정한 대출 프로세스 워크플로우를 선택할 수 있다. 이들 실시예들 중 일부에서, 담보 관리 시스템(804)은, 차용자의 위치, 담보의 유형, 및/또는 차용자가 대출에서 확보하고자 하는 금액에 기초하여, 한 세트의 상이한 대출 프로세스 워크플로우들로부터 특정한 대출 프로세스 워크플로우를 선택할 수 있다. 예를 들어, 담보 아이템이 크고/크거나 상이한 참여자들 사이에서 운반하기 어렵거나 비용이 많이 드는 경우(예를 들어, 차량, 대형 와인 또는 위스키 콜렉션, 희귀 회화, 크리스탈 샹들리에), 담보 관리 시스템(804)은, 보관 스테이지(요청 스테이지 이후)로 시작하여 토큰화 스테이지가 뒤따르는 대출 프로세스 워크플로우를 선택하여, 보관자가, 위치들 사이에서 담보 아이템을 배송하는 것이 아니라, 인증자와 평가자에게 제공될 수 있는 VIRL을 생성하는데 이용되는 사진들, 비디오들, 및/또는 기타의 지원 데이터를 촬영할 수 있게 할 수 있다. 또 다른 예에서, 아이템이 종종 위조되는 아이템 유형(예를 들어, 시계, 핸드백 또는 운동화)인 경우, 담보 관리 시스템(804)은 평가 및/또는 보관 전에 인증이 발생하는 대출 프로세스를 선택할 수 있어서, 인증자(들)는 임의의 다른 스테이지로 진행하기 전에 아이템이 가짜인지를 결정할 수 있다. 대출 프로세스 워크플로우들의 일부 변형은 추가적인 또는 대안적인 스테이지를 포함될 수 있다는 점에 유의한다. 예를 들어, 일부 실시예에서, 대출 프로세스 워크플로우는, 본 개시내용에서 논의된 바와 같이, 대출전 청산 이벤트가 수행되는 대출전 청산 스테이지를 포함할 수 있다.
실시예들에서, 담보 관리 시스템(802) 및 인증 시스템(804)은 원장 관리 시스템(104)과 연계하여 동작해, 및/또는 아이템 인증(예를 들어, 인증 스마트 계약(2028)), 아이템 평가(예를 들어, 평가 스마트 계약(2030)), 미필적 상황 청산 이벤트(예를 들어, 청산 스마트 계약), 아이템 보관(예를 들어, 스마트 계약 보관(2032)) 및/또는 대출 생성/상환(예를 들어, 대출 스마트 계약(2034)) 등의, 탈집중형 대출 프로세스의 각각의 스테이지 및/또는 탈집중형 대출 프로세스를 일반적으로 관리하는데 이용되는 일련의 스마트 계약 인스턴스(예를 들어, 대출 프로세스 스마트 계약(2022))를 인스턴스화하거나 인스턴스화를 개시한다. 일부 실시예에서, 담보 관리 시스템(802)은 대출 프로세스 스마트 계약(2022)을 인스턴스화할 수 있고, 대출 프로세스 스마트 계약(2022)은, 차례로, 대출 프로세스 스마트 계약(2022)이 소정의 정의된 조건이 충족되었고 대출 프로세스 워크플로우를 통해 대출 프로세스가 진행된다고 결정할 때 대출 프로세스의 하나 이상의 스테이지를 관리하는 스마트 계약을 인스턴스화할 수 있다.
일부 실시예에서, 인증 시스템(804)은 대출 프로세스가 상이한 스테이지들로 진행함에 따라 상이한 참여자들에게 작업들을 할당하도록 구성될 수 있다. 실시예들에서, 인증 시스템(804)은 대출 프로세스 동안 참여자들에게 작업들을 할당하도록 구성될 수 있다. 특히, 인증 시스템(804)은, 인증자들에게 인증 작업들을 할당하고, 평가자들에게 평가 작업들을 할당하거나, 및/또는 보관자들에게 보관 작업들을 할당하도록 구성될 수 있다. 실시예들에서, 인증 시스템(804)은 요청의 내용에 기초하여 인증자들, 평가자들, 및 보관자들을 선택할 수 있다. 예를 들어, 인증자들 및 평가자들이 특정한 유형들의 아이템을 인증하거나 평가하는 것을 전문으로 하는 길드들로 조직화되는 실시예들에서, 인증 시스템(804)은 인증 및 평가되는 아이템의 유형에 기초하여 각각의 인증 길드 또는 평가 길드를 결정할 수 있다. 예를 들어, 시계가 인증 및 평가되고 있는 중이라면, 인증 시스템(804)은 시계 인증 길드 및 시계 평가 길드를 관련 길드들로서 식별할 수 있다. 식별된 길드들로부터, 인증 시스템(804)은 인증 작업 및 평가 작업을 수행하기 위해 식별된 길드들로부터 각각의 길드 멤버를 선택할 수 있다. 보관자들이, 모두가 적격 보관자들로 구성된 단일 길드와는 대조적으로, 전문화되었고/되었거나 지역 길드들을 갖는 범위까지, 인증 시스템(804)은, 길드의 유형(예를 들어, 자동차 보관자들, 부패하기 쉬운 아이템들의 보관자들 등)에 기초하여 및/또는 담보물에 대한 특정한 길드의 근접성에 기초하여 소정의 보관자 길드를 선택할 수 있다(예를 들어, 담보 아이템이 Nevada주 또는 그 근처에 위치할 때 Nevada-기반의 보관자 길드가 선택됨). 일단 작업을 수행할 길드가 식별되고 나면(작업이 길드 멤버에게 할당되기 전에 길드가 식별될 필요가 있다고 가정), 인증 시스템(804)은 작업을 수행할 길드의 하나 이상의 멤버를 할당할 수 있다.
실시예들에서, 인증 시스템(804)은 작업을 수행하기 위해 길드 멤버를 식별하기 위한 다수의 상이한 접근법들을 구현할 수 있다. 예시적인 실시예들에서, 인증 시스템(804)은 길드 멤버들이 대기열(queue)에 의해 결정된 순서로 각각의 작업들에 할당되는 선입선출 대기열을 이용할 수 있다. 예시적인 실시예들에서, 인증 시스템(804)은 참여자를 선택하기 위해 라운드 로빈 선택 방식(round-robin selection scheme)을 이용할 수 있다. 실시예들에서, 인증 시스템(804)은 인증 및 평가 작업들을 길드 멤버에게 무작위로 할당한다. 예시적인 실시예에서, 인증 시스템(804)은, 작업을 수행할 수 있는 참여자들(예를 들어, 길드 멤버들)의 각각의 대역폭, 담보 아이템의 브랜드 또는 아종, 각각의 참여자의 등급, 각각의 참여자의 담보 아이템에 대한 근접성, 가장 최근 작업이 각각의 참여자에게 할당된 이후의 각각의 시간, 각각의 상응하는 참여자에 의해 수행된 성공적인 작업 수, 각각의 상응하는 참여자에 의해 수행된 실패한 작업의 수, 각각의 상응하는 참여자에 의해 수행된 성공적인 또는 실패한 작업의 백분율, 및/또는 기타 등등의, 한 세트의 선택 기준에 기초하여 길드 멤버들이 각각의 작업들에 할당되는 가중 선택 프로세스를 이용할 수 있다. 실시예들에서, 인증 시스템(804)은, 길드 멤버들이 작업에 입찰할 수 있고 입찰(및/또는 다른 선택 기준)에 기초하여 길드 멤버가 선택되는 입찰 시스템을 채용할 수 있다. 실시예들에서, 입찰가는 길드 멤버가 작업을 수행하기 위한 가격을 나타낼 수 있다. 이들 실시예에서, 인증 시스템(804)은, 입찰 금액 및/또는 선택 기준에 기초하여 길드 멤버를 선택할 수 있거나(예를 들어, 입찰 금액뿐만 아니라 임의의 다른 적절한 선택 기준을 인자들로서 취하는 선택 모델을 이용하여), 차용자는 인증자를 선택할 수 있다(예를 들어, 차용자는 차용자가 각각의 입찰자에게 지불해야 하는 각각의 수수료로서 입찰 금액을 제시받을 수 있고, 또한 그들의 위치 및 등급이 표시될 수 있으며, 차용자는 자신에게 가장 합리적인 입찰을 선택한다). 대안으로서, 입찰가는 길드 멤버가 각각의 작업을 획득하기 위해 지불할 의향이 있는 가격을 나타낼 수 있다. 이들 실시예에서, 인증 시스템(804)은 최고 입찰가에 기초하여 길드 멤버를 선택하도록 구성될 수 있다. 1차 및 2차 참여자들(예를 들어, 1차 및 2차 인증자들 및 1차/2차 평가자들)이 작업을 수행하는 시나리오들에서, 이용가능한 참여자들은 1차 참여자가 되기 위한 입찰 및/또는 2차 참여자가 되기 위한 입찰을 제공하되, 1차 참여자들 및 1명 이상의 2차 참여자는 각각의 입찰에 기초하여 선택되고 1차 작업 수행 권한의 승자가 2차 작업 수행 권한의 승자가 될 수 없게 한다. 인증 시스템(804)은 인증 또는 평가 작업들을 수행할 길드 멤버를 선택하기 위해 임의의 다른 적절한 기술을 채용할 수 있다. 일단 인증 시스템(804)이 개인에 대한 작업을 갖게 되면, 인증 시스템(804)은 선택된 개인 및/또는 문제의 대출 프로세스를 통제하는 대출 프로세스 스마트 계약(2022)의 인스턴스에 통보를 제공할 수 있다.
설명의 목적을 위해, 인증 시스템(804)은 참여자들에게 작업들을 할당하는 것으로서 설명되지만, 토큰화 플랫폼(100)의 다른 적절한 컴포넌트들은 참여자들에게 작업들을 할당할 수 있다. 대안으로서, 작업 할당들은 "온체인"으로 처리되되, 하나 이상의 스마트 계약이 참여자들에게 작업들을 할당하도록 구성될 수 있게 할 수 있다. 예를 들어, 대출 프로세스 스마트 계약(2022)의 한 인스턴스는 대출 프로세스의 한 인스턴스의 실행 동안 참여자들에게 작업들을 할당하도록 구성될 수 있다. 추가로 또는 대안으로서, 스테이지-레벨 스마트 계약들의 인스턴스들은 대출 프로세스 동안 인스턴스화될시에 참여자들에게 작업들을 할당하도록 구성될 수 있다. 후자의 구현에서, 스테이지-레벨 스마트 계약들은 작업들을 할당하기 위해 선택 기준 및/또는 선택 방식들의 조합을 이용할 수 있다. 예를 들어, 스테이지-레벨 스마트 계약(예를 들어, 인증 스마트 계약(2028), 평가 스마트 계약(2030) 및/또는 보관 스마트 계약(2032)) 또는 길드-레벨 스마트 계약(길드가 길드-레벨 스마트 계약을 갖는 계약)은 대기열에 따라, 입찰 프로세스를 통해, 라운드 로빈 방식으로, 및/또는 한 세트의 선택 기준 세트에 따라, 각각의 작업을 하나 이상의 참여자에게 무작위로 할당하도록 구성될 수 있다. 선택 기준의 예로서는, 작업을 수행할 수 있는 참여자들(예를 들어, 길드 멤버들)의 각각의 대역폭, 각각의 참여자의 등급, 각각의 참여자의 담보 아이템에 대한 근접성, 가장 최근 작업이 각각의 참여자에게 할당된 이후의 각각의 시간, 각각의 상응하는 참여자에 의해 수행된 성공적인 작업 수, 각각의 상응하는 참여자에 의해 수행된 실패한 작업의 수, 각각의 상응하는 참여자에 의해 수행된 성공적인 또는 실패한 작업의 백분율, 및/또는 기타 등등이 포함될 수 있다.
일부 실시예에서, 시장 시스템(202)(예를 들어, 아이템 관리 시스템(202)(도 2))은 담보 아이템들의 가상 표현(VIRL)들을 생성하도록 구성되고 원장 관리 시스템(104)(예를 들어, 토큰 생성 시스템(302))은 하나 이상의 VIRL을 담보 토큰으로 토큰화하도록 구성될 수 있다. 차용자가 단일 대출을 확보하기 위해 하나보다 많은 아이템을 담보화하기를 원하는 경우, 아이템 관리 시스템(202)은 상이한 담보 아이템들에 각각 대응하는 한 세트의 VIRL들을 생성할 수 있는 반면, 원장 관리 시스템(102)은 VIRL들을 각각의 담보 토큰들(2042)로 개별적으로 토큰화하거나 VIRL 세트를 포장하는 단일 담보 토큰(2042)으로 VIRL 세트를 토큰화할 수 있다는 것을 이해할 것이다. VIRL들 및 토큰들을 생성하기 위한 예시적인 방법들 및 시스템들은 도 1 내지 도 4와 본 개시내용 전체에 걸쳐 다른 곳과 관련하여 더 상세히 논의된다. 초기에, 원장 관리 시스템(104)은, 담보 토큰(2042)에 대한 소유권 데이터(2054)를 분산형 원장(2019)에 기입하고/하거나 담보 토큰(2042)을 차용자의 계정에 예치함으로써, 담보 토큰(2042)의 소유권을 차용자에게 할당할 수 있다. 차용자가 대응하는 담보 아이템을 보관자에게 제공한 후에도, 차용자는 담보 토큰(2042)에 대한 소유권을 유지할 수 있다. 차용자와 하나 이상의 대출자가 대출에 동의하고 대출을 실행하면, 담보 토큰(2042)은, 담보 토큰(2042)을 에스크로 계정으로 이전하고 담보 토큰(2042)이 현재 에스크로에 보관되어 있음을 나타내도록 담보 토큰(2042)의 소유권 데이터(2054)를 업데이트함으로써 "잠금처리"될 수 있다. 일단 대출이 상환되고 나면(예를 들어, 차용자에 의해 또는 채무불이행 후 청산 이벤트의 수익금으로부터), 담보 토큰은 차용자(대출이 전액 상환된 경우) 또는 담보 토큰(2042)의 구매자(담보 아이템이 청산된 경우) 중 어느 하나의 계정으로 담보 토큰(2042)을 이전함으로써 잠금해제된다. 담보 토큰을 잠금해제할 때, 원장 관리 시스템(104) 또는 스마트 계약(예를 들어, 스마트 대출 프로세스 스마트 계약(2022) 또는 대출 스마트 계약(3034)의 한 인스턴스)은, 분산형 원장(2054)의 담보 토큰(2042)에 대응하는 소유권 데이터(2054)를 담보 토큰(2042) 소유자의 계정을 나타내는 데이터 블록으로 업데이트함으로써 상환후 정당한 소유자에게로의 담보 토큰(2042)의 이전을 용이화할 수 있다.
일부 실시예에서, 담보 관리 시스템(802)(또는 토큰화 플랫폼의 임의의 다른 적절한 컴포넌트)은 차용자와 대출자 사이의 대출 합의의 협상을 용이화한다. 담보 관리 시스템(802)은 임의의 적절한 방식으로 대출 합의의 협상을 용이화하도록 구성될 수 있다. 일부 실시예에서, 담보 관리 시스템(802)은 차용자가 대출을 요청하는 것을 허용하는 GUI를 차용자에게 제공할 수 있다. 담보 아이템이 인증 및 평가(또는 미필적 상황시의 구매)되었다고 가정하면, 담보 관리 시스템(802)은 사용자가 평가 가치를 초과하지 않는 대출 금액을 요청하고 대출을 상환할 시간을 요청하는 것을 허용할 수 있다. 이들 실시예들 중 일부에서, 담보 관리 시스템(802)은 GUI를 통해 잠재적인 대출자에 프리젠팅되는 대출 요청을 생성할 수 있으며, 이에 따라, 대출 요청은, 요청 금액, 대출 기간, 및 차용자에 의해 제공된 담보 아이템에 관련된 정보를 나타낸다. 담보 아이템과 관련된 정보는, 담보 아이템의 VIRL(이미지, 설명, 비디오 및 기타 적절한 정보를 포함할 수 있음), 인증 보고, 평가 보고, 보관 보고, 인증, 평가 및 보관자들이 (전술된 바와 같이) 각자의 작업들을 확보했다는 확인, 및/또는 기타 등등을 포함할 수 있다. 실시예들에서, 담보 관리 시스템(802)은 대출에 대한 대출 상환 금액 및/또는 이자율을 (예를 들어, 현재 시장 상황에 기초하여) 제안할 수 있다. 대안으로서, 잠재적인 대출자는 GUI를 통해 차용자가 상환해야 하는 이자율 또는 총 상환 금액을 제공할 수 있다. 추가적으로, 잠재적 대출자는, 대출 금액 및/또는 상환 기간 등의, 대출 조건들 중 하나 이상에 대응할 수 있다. 그 다음, 대출 제안은 GUI를 통해 차용자에게 전달될 수 있으며, 여기서 차용자는 차용자 디바이스(2002)를 통해 대출 제안을 볼 수 있다. 이에 응답하여, 차용자는 대출 제안을 수락하거나, 대출 제안을 거부하거나, 반대 제안을 제공할 수 있다. 당사자는 합의에 도달하거나 한쪽 또는 양쪽 당사자가 대출 제안을 거부할 때까지 이러한 방식을 반복할 수 있다. 일단 대출에 도달하고 나면, 당사자는 대출 합의를 실행할 수 있고, 담보 관리 시스템(802)은 대출 합의가 차용자에 의해 동의되었음을 나타내는 통보를 대출 프로세스 스마트 계약에 제공할 수 있고 대출자는 대출 합의의 상세사항을 스마트 계약에 제공할 수 있다(예를 들어, .JSON 파일로). 이에 응답하여, 대출 프로세스 스마트 계약(2022)(또는 담보 관리 시스템(802))은 전술된 방식으로 대출 상환 워크플로우를 실행하는 대출 스마트 계약 인스턴스를 인스턴스화할 수 있다. 일부 실시예에서, 스마트 계약 인스턴스(예를 들어, 대출 프로세스 스마트 계약(2022)의 인스턴스 또는 대출 스마트 계약의 인스턴스)가 전술된 방식으로 대출 합의의 협상을 용이화하도록, 대출 협상이 온체인으로 처리될 수 있다는 것을 이해할 것이다. 일단 대출이 협상되고 나면, 담보 토큰(2042)은 에스크로 계정에서 잠금처리될 수 있고, 대출의 상환은 대출 스마트 계약 인스턴스에 의해 처리될 수 있다. 대출이 전액 상환되는 경우, 담보 토큰(2042)이 잠금해제되어 차용자에게 반환될 수 있으며, 이에 따라 토큰(2042)의 소유권 데이터(2052)는, 차용자가 담보 토큰(2052)의 소유자이고 차용자가 담보 아이템의 소유권을 되찾기 위해 토큰(2052)을 상환할 수 있다는 것을 반영하도록 업데이트된다. 차용자가 대출 합의의 조건들에 따라 대출을 성공적으로 상환하지 않는 경우, 대출 계약 인스턴스는 대출을 채무불이행으로 간주할 수 있다.
일부 실시예에서, 대출의 채무불이행은 청산 스테이지를 트리거할 수 있으며, 여기서 담보 토큰(2042)은 대출의 나머지 잔액을 충당하기 위해 청산된다. 실시예들에서, 차용자가 대출 합의에 따른 대출에 관해 채무불이행할 때 청산 스테이지가 자동으로 트리거될 수 있다. 실시예들에서, 스마트 계약 인스턴스(예를 들어, 대출 프로세스 스마트 계약(2022)의 한 인스턴스 또는 대출 스마트 계약(2036)의 한 인스턴스)는 대출의 상환을 위해 차용자가 행한 지불들을 나타내는 지불 이벤트 통보들을 수신할 수 있다. 지불 기한이 될 때마다, 스마트 계약 인스턴스는 지불을 받았는지를 결정할 수 있다. 일정에 있는 지불이 누락된 경우, 스마트 계약 인스턴스는 차용자가 채무불이행 상태인지를 결정할 수 있다. 채무불이행 상태는 반드시 단일 지불의 누락인 것은 아니지만 대출 합의에서 여러 번의 연속적 지불이 누락되거나 대출 상환 금액에 비해 소정 지불 금액이 모자르는 것으로 정의될 수 있다. 차용자가 채무불이행 상태에 있는 경우, 스마트 계약 인스턴스는 청산 이벤트를 트리거할 수 있다. 일부 실시예에서, 스마트 계약은 담보 토큰(2042) 및/또는 그 안에 포장된 VIRL을 나타내는 청산 요청을 시장(예를 들어, 시장 시스템(102))에 발행할 수 있다. 청산 요청은, 평가 금액, 평가 기록, 인증 기록, 보관 기록, 및/또는 대출 상환 금액의 나머지 잔액 등의, 추가 데이터를 포함할 수 있다. 이에 응답하여, 시장은 청산 판매를 수행할 수 있다. 실시예들에서, 청산 판매는 (예를 들어, 평가 가치로 설정된) 고정 가격 판매 또는 (예를 들어, 대출 상환 금액의 나머지 잔액에서 개시하는) 경매일 수 있다. 일단 아이템이 청산되고 나면, 스마트 계약 인스턴스는 아이템이 청산되었음을 나타내는 청산 통보를 수신할 수 있다. 이에 응답하여, 스마트 계약 인스턴스는 채무불이행된 대출을 안전하게 보호하는데 이용된 담보 토큰(2042)의, 보유된 에스크로 계정으로부터 담보 아이템의 구매자의 계정으로의 이전을 개시할 수 있다. 일단 담보 토큰(2042)이 구매자에 의해 소유되어 있다는 것을 담보 토큰의 소유권 데이터(2054)가 나타내도록 업데이트되고 나면, 구매자는 담보 토큰(2042)을 상환할 수 있다(예를 들어, 본 개시내용 전체에 걸쳐 설명된 바와 같이).
담보 토큰(2042)의 소유권 취득시, 담보 토큰(2042)의 소유자는 토큰을 상환할 수 있다(예를 들어, 토큰의 상환을 개시하는 메커니즘을 제공하는 GUI를 이용하여). 담보 토큰의 상환은 토큰화 플랫폼(100)의 상환 시스템(404) 등의 신뢰할 수 있는 제3자에 의해 오프체인으로, 및/또는 대출 거래를 관리한 대출 프로세스 스마트 계약(2022)의 인스턴스 및/또는 보관자 자신이 담보 아이템을 정당한 소유자에게 반환하고 있다고 보관자가 확신할 수 있도록 담보 아이템이 무신용 방식으로 정당한 소유자에게 반환되도록 보장하기 위해 담보 아이템의 보관자에게 담보 아이템이 예치될 때 생성된 보관 스마트 계약(2032)의 인스턴스 등의, 완료된 대출 거래에 대응하는 스마트 계약의 인스턴스에 의해 온체인으로 처리될 수 있다.
실시예들에서, 담보 토큰(2042)의 상환은 오프체인으로(예를 들어, 신뢰할 수 있는 제3자의 컴퓨팅 시스템에 의해) 또는 온체인으로(예를 들어, 하나 이상의 스마트 계약의 인스턴스에 의해) 실행될 수 있는 담보 상환 워크플로우에 따라 수행될 수 있다. 실시예들에서, 담보 상환 워크플로우는 다음과 같은 동작들을 포함할 수 있지만 이것으로 제한되는 것은 아니다: 담보 토큰(2042)에 의해 표시된 담보 아이템을 상환하라는 요청을 사용자 디바이스로부터 수신하는 단계; 담보 토큰(2042)의 상환을 시도하고 있는 사용자가 담보 토큰(2042)의 정당한 소유자인지를 분산형 원장(2016)에 저장된 소유권 데이터(2052)에 기초하여 확인하는 단계; 분산형 원장(2016) 및/또는 대출 프로세스 스마트 계약(2022)으로부터 담보 토큰(2042)에 의해 표시된 담보 아이템의 보관자를 식별하는 단계; 정당한 소유자가 담보 토큰(2042)을 상환했다는 상환 통보를 식별된 보관자의 보관자 디바이스(2008)에 전송하는 단계; 담보 토큰의 정당한 소유자가 담보 아이템의 소유권을 취득했음을 나타내는 확인 통보를 식별된 보관자의 보관자 디바이스(2008)로부터 수신하는 단계; 및 (전술된 바와 같이) 보관자로부터 통보를 수신한 것에 응답하여 담보 토큰(2042)을 소각하는 단계. 실시예들에서, 상환 워크플로우는 담보 아이템이 만족스러운 상태로 반환되었음을 나타내는 피드백을 담보 아이템의 상환 소유자로부터 수신하고/하거나 (분석 및/또는 보관자의 등급을 업데이트하는데 이용할 수 있는) 이러한 피드백 이벤트들의 발생 및 내용을 나타내기 위해 분산형 원장(2016)을 업데이트하는 것 등의, 추가적인 또는 대안적인 단계들을 포함할 수 있다.
실시예들에서, 토큰화 플랫폼(100)은 수행된 대출 프로세스들의 다양한 스테이지들에 관한 분석을 수행하도록 구성된다. 이들 실시예들 중 일부에서, 분석 및 보고 시스템(112)은, 잘못된 긍정 인증(예를 들어, 아이템이 진품으로 간주되었으나 나중에 위조로 판명된 경우), 잘못된 부정 인증(예를 들어, 아이템이 위조품으로 간주되었으나 나중에 진품으로 판명된 경우), 과대평가, 과소평가, 보관 동안의 담보 아이템 파손 또는 분실, 대출 채무불이행 등의 부정적인 결과를 포함한 대출 프로세스와 관련된 결과를 결정하기 위해 분산형 원장(2016) 세트로부터 이벤트 기록들(2052) 및/또는 지원 데이터(2056)를 획득하도록 구성될 수 있다. 예를 들어, 분석 및 보고 시스템(112)은 각각의 길드 및/또는 길드 멤버들에 의해 발행된 잘못된 긍정 인증의 백분률 등의 인증 관련 통계를 결정하도록 구성될 수 있다. 이 예에서, 분석 및 보고 시스템(112)은, 길드 또는 길드 멤버에 의해 진품으로 간주되었고 나중에 구매자에 의해 위조된 것으로(이것을 "잘못된 긍정"이라고 지칭할 수 있음) 보고된 청산된 아이템들과 연관된 임의의 이벤트 기록들(2052)을, 길드 또는 길드 멤버에 의해 수행된 총 인증 횟수와 대조하여 판독할 수 있다. 또 다른 예에서, 분석 및 보고 시스템(112)은 인증 작업들이 과소평가되거나 과대평가된 가치들을 초래한 경우들을 식별할 수 있다. 이 예에서, 분석 및 보고 시스템(112)은, 모든 평가 및/또는 성공적인 평가(예를 들어, 청산 가치의 소정 백분률 내)의 수와 관련하여 평가자에 의해 제공된 평가 가치보다 아래에서(청산 가치로부터 소정의 백분률만큼 과대평가됨) 또는 위에서(청산 가치로부터 소정의 백분률만큼 과소평가됨) 판매된 청산된 아이템들과 연관된 이벤트 기록들(2052)의 수를 결정할 수 있다. 그 다음, 이들 유형들의 통계적 통찰을 이용하여, 부정적인 결과들을 초래할 수 있는 작업들의 공통 피처들을 식별할 수 있고, 이들 부정적인 결과들(예를 들어, 잘못된 긍정 사례, 잘못된 부정 사례, 과소평가액 사례, 과대평가액 사례, 및/또는 손실 또는 손상된 담보 사례)은 성공적인 사례들과 공유되지 않고 일부 경우에는 이들 피처들을 완화하기 위해 스테이지-레벨 거버넌스를 조정할 수도 있다.
또 다른 예에서, 분석 및 보고 시스템(112)은 작업 수행자들(예를 들어, 인증자들 및/또는 평가자들)에 의한 고용 시간(turnover time)을 결정할 수 있다. 이 예에서, 분석 및 보고 시스템(112)은, 대출 프로세스에서 특정한 참여자들에게 작업들이 할당된 때를 나타내는 이벤트 기록들(2052) 및 이들 참여자들이 작업을 완료한 때를 나타내는 이벤트 기록들(2052) 등의, 대출 프로세스의 소정 부분들과 연관된 다양한 이벤트 기록(2052)을 획득할 수 있다. 그 다음, 분석 및 보고 시스템(112)은 작업의 각각의 인스턴스를 완료하는 시간을 결정할 수 있고, 개별 길드 멤버에 대한 평균 고용 시간, 전체 길드 또는 하위 길드에 대한 특정한 작업을 위한 평균 회송 시간(turnaround time), 모든 스테이지 참여자에 대한 평균 회송 시간, 특정한 유형들의 담보 아이템들 또는 담보 아이템들의 아종들에 대한 평균 회송 시간 등의 다양한 분석 통찰을 결정할 수 있다. 이들 통찰은, 시간 제약들이 충족되지 않으면 참여자 보상이 줄어들 수 있도록, 미래 거버넌스에서 작업들에 관한 시간 제약들을 설정하는데 이용될 수 있다.
실시예들에서, 분석 및 보고 시스템(112)은, 차용자들, 인증자들, 평가자들, 보관자들, 및/또는 대출자들 등의, 대출 프로세스 생태계(2000)의 상이한 참여자들에 등급들을 제공하도록 구성될 수 있다. 실시예들에서, 분석 및 보고 시스템(112)은, 차용자별 성공적인 상환 대 채무불이행 이벤트, 인증자별 잘못된 부정/잘못된 긍정 대 성공적인 인증, 평가자별 과소평가액 및/또는 과대평가액 대 성공적인 평가, 보관자별 손상되거나 분실된 담보 아이템 사례 대 성공적인 보관 작업 등의, 다양한 상이한 참여자들과 연관된 부정적 및 긍정적 결과들을 결정할 수 있다. 분석 및 보고 시스템(112)은, 다른 참여자들의 피드백 등의, 참여자들과 관련된 추가적인 또는 대안적인 데이터를 수집할 수 있다. 그 다음, 분석 및 보고 시스템(112)은 점수를 참여자들에게 할당하기 위해 참여자들과 관련된 결과 및 기타의 피드백 데이터에 채점 기능을 적용할 수 있다. 이들 점수들은, 작업 할당, 길드 토큰 수여, 참여자 보상, 및/또는 기타 등등과 관련될 수 있다.
실시예들에서, 분석 및 보고 시스템(112)은 분산형 원장들로부터 데이터를 획득될 수 있다. 이들 실시예들 중 일부에서, 노드 디바이스(2014)는 분산형 원장(2016)에 기입되는 모든 데이터 블록을 모니터링하는 "이력 노드(history node)"로서 구성될 수 있다. 이력 노드 디바이스는 원장(2016)에 기입되는 각각의 블록을 처리하고 인덱싱할 수 있으며, 이 정보를 분석 및 보고 시스템(112)에 제공할 수 있다. 그 다음, 분석 및 보고 시스템(112)은 이력 노드에 의해 수집된 데이터에 관한 분석을 수행할 수 있다. 분석 및 보고 시스템(112)은 본 개시내용의 범위를 벗어나지 않고 다른 적절한 방식으로 분산형 원장(2016)으로부터 데이터를 수집할 수 있다.
도 27은 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우(2700)의 한 예를 나타낸다. 도 27의 예에서, 대출 프로세스 워크플로우는, 시계, 보석, 핸드백, 운동화 등의, 쉽게 위조되는 담보 아이템들에 대해 수행될 수 있다. 도 27의 예에서, 대출 프로세스 워크플로우(2700)는 : 차용자가 대출 프로세스를 개시할 것을 요청하는 요청 스테이지(2702); 이에 후속하는, 하나 이상의 인증자가 하나 이상의 아이템을 인증하는 인증 스테이지(2704), 이에 후속하는, 인증된 아이템들이 평가되는 평가 스테이지(2706); 이에 후속하는, 평가된 아이템들이 신뢰할 수 있는 보관자의 에스크로에 보관되는 보관 스테이지(2708), 원장 관리 시스템(104)(또는 다른 적절한 컴포넌트)이 하나 이상의 에스크로잉된 아이템의 VIRL들을 생성하고 에스크로잉된 아이템들의 VIRL들을 토큰화함으로써 담보 토큰을 생성하는 토큰화 스테이지(2710); 이에 후속하는, 대출이 차용자와 대출자에 의해 협상되고 수락되는 대출 스테이지(2712); 이에 후속하는, 차용자에 의해 대출이 상환되는 상환 스테이지(2714); 및 이에 후속하는, 담보 토큰이 잠금해제되어 차용자에게 반환되거나 차용자가 대출에 관해 채무불이행하는 경우에는 청산되고 대출 프로세스의 참여자들에게 임의의 보상이 발행되는 대출후 스테이지(2716)를 포함할 수 있다.
요청 스테이지(2702) 동안, 차용자는, 차용자에 의해 소유된 아이템을 담보화하는 것을 포함하는 새로운 대출 프로세스를 개시할 것을 요청할 수 있다. 실시예들에서, 차용자는 토큰화 플랫폼(100)과 인터페이스하는 차용자 디바이스(2002)를 통해 대출을 요청할 수 있다. 이들 실시예에서, 토큰화 플랫폼(100)(또는 다른 적절한 시스템)은, 차용자가, 담보화될 담보 아이템, 담보 아이템의 위치, 요청 대출 금액, 및/또는 제안된 대출 조건 등의 정보를 제공할 수 있는 GUI를 제공할 수 있다. 차용자 요청에 응답하여, 토큰화 플랫폼(100)은 대출 프로세스 스마트 계약 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출 프로세스 스마트 계약 인스턴스는 (예를 들어, 차용자에 의해 제공된 요청으로부터) 담보 아이템의 유형을 결정할 수 있고, 담보 아이템을 인증할 것을 인증자(및 잠재적으로 2차 인증자들)에게 요청할 수 있음으로써, 대출 프로세스를 인증 스테이지(2704)로 진행시킬 수 있다.
인증 스테이지(2704) 동안, 대출 프로세스 스마트 계약 인스턴스는 인증 스마트 계약(2028)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 전술된 바와 같이, 담보 아이템 등의 아이템들을 인증하는 것을 전문으로 하는 인증 길드로부터의 1차 인증자(및 잠재적으로 2차 인증자들)에게 인증 작업을 할당할 수 있다. 실시예들에서, 1차 인증자는 인증자 디바이스(2004)를 통해 인증될 아이템의 수령을 확인해 줄 수 있다. 실시예들에서, 인증자는 담보 아이템의 진위성에 대한 결정을 나타내는 인증 보고뿐만 아니라, 임의의 지원 문서를 생성할 수 있다. 실시예들에서, 인증 보고 및 지원 증거가 하나 이상의 2차 인증자에게 제공될 수 있으며, 이들은 차례로 인증 보고를 검증할 수 있고 추가 지원 문서를 제공할 수 있다. 실시예들에서, 인증 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예들에서, 인증 작업에 참여한 인증자들은, 아이템이 청산되고 나중에 가짜로 간주되는 경우 보호 수단으로서 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 예시적인 실시예들에서, 대출 프로세스 스마트 계약(2022)은 아이템이 인증자(들)에 의해 진품인지 또는 가짜로 간주되었는지를 나타내는 인스턴스화된 인증 스마트 계약(2028)에 의해 발행된 인증 통보를 청취하는 청취 스레드를 포함할 수 있고, 여기서, 인증 스마트 계약(2028)으로부터의 통보는, 인증자들의 의견(예를 들어, 가짜 또는 정품), 인증 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 인증 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 대출 프로세스 스마트 계약 인스턴스가 아이템이 진품으로 간주되었다고 결정하면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 평가 스테이지(2706)로 진행시킬 수 있다.
평가 스테이지(2706) 동안, 대출 프로세스 스마트 계약 인스턴스는 인증된 아이템을 평가할 것을 하나 이상의 평가자에게 요청할 수 있고 평가 스마트 계약(2030)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 위에서 논의된 바와 같이, 담보 아이템의 유형에 기초하여 작업을 수행하는 하나 이상의 평가자를 식별할 수 있다. 실시예들에서, 1차 평가자는, (예를 들어, 우편 또는 기타의 배송을 통해) 담보 아이템을 수령하고/하거나 담보 아이템의 VIRL을 수신할 수 있다. 아이템이 인증자들에 의해 진품으로 간주되었음을 알면, 평가자는 담보 아이템의 평가 가치를 결정할 수 있고 평가 가치를 나타내는 평가 보고와 평가 가치를 뒷받침하는 임의의 지원 문서를 생성할 수 있다. 일부 실시예에서, 하나 이상의 2차 평가자가 평가 보고를 검증할 수 있고 각자의 검증에 대한 지원 문서를 제공할 수 있다. 실시예들에서, 평가 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 평가 작업에 참여한 평가자들은, 아이템이 상환 금액의 나머지 잔액 및/또는 평가 가치보다 상당히 낮은 가격으로 청산되는 경우 보호 수단으로서 담보 아이템의 평가 가치와 같거나 비례하는 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 실시예들에서, 평가 스마트 계약(2030)은 평가 워크플로우가 성공적으로 완료되었음을 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 전송할 수 있고, 여기서, 통보는, 평가 가치, 평가 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 평가 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 평가 스테이지가 완료되었다고 결정하면, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 보관 스테이지(2708)로 진행시킬 수 있다.
보관 스테이지(2708) 동안, 대출 프로세스 스마트 계약 인스턴스는 보관자에게 평가된 아이템을 보관할 것을 요청할 수 있고 보관 워크플로우를 실행하는 보관 스마트 계약(2032)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 예를 들어 담보 아이템의 유형 및/또는 담보 아이템에 대한 보관자의 근접성에 기초하여, 보관자를 보관 작업에 할당할 수 있다. 일단 보관자가 아이템 수령을 확인하고 나면, 보관자는 아이템이 보관되었음을 나타내는 보관 보고를 생성하고, 수령 및 검사 당시 담보 아이템의 임의의 손상뿐만 아니라, 보관 보고를 뒷받침하는 임의의 지원 문서를 기록할 수 있다. 실시예들에서, 보관 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 보관자는 보관 동안 아이템이 분실되거나 손상된 경우 보호 수단으로서 담보 아이템의 평가 가치와 같거나 비례하는 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다(또는 보험의 증빙을 제공할 수 있다). 실시예들에서, 보관 스마트 계약 인스턴스는, 그 다음, 아이템이 에스크로에 안전하게 보관되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에 제공할 수 있으며, 여기서, 통보는, 보관 보고 및 기타 임의의 지원 증거의 해시 값 및/또는 보관 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 통보에 응답하여, 대출 프로세스 스마트 계약은 대출 프로세스를 토큰화 스테이지(2710)로 진행시킬 수 있다.
토큰화 스테이지(2710) 동안, 토큰화 플랫폼(100)(또는 다른 적절한 컴포넌트)은 담보 아이템을 토큰화하여 생성할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 담보 아이템의 설명, 이미지, 비디오, 2D 스캔, 및/또는 3D 스캔 등의, 담보 아이템을 설명하고/하거나 묘사하는 데이터에 기초하여 담보 아이템의 VIRL을 생성할 수 있다. 실시예들에서, 차용자, 보관자, 및/또는 인증자는 VIRL을 생성하는데 이용되는 데이터를 제공할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은 담보 아이템의 VIRL에 기초하여 아이템의 담보 토큰을 생성한다. 일단 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은 토큰을 분산형 원장(2016)에 기입할 수 있고, 초기에 담보 토큰에 대한 소유권을 차용자에게 할당할 수 있다(대출 합의에 도달할 때까지). 일단 담보 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은, 토큰화 이벤트 및/또는 담보 토큰의 주소를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 토큰화 이벤트의 통보 수신시, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 대출 스테이지(2712)로 진행시킬 수 있다.
대출 스테이지(2712) 동안, 차용자는 대출을 요청하고/하거나 하나 이상의 대출자와 대출을 협상할 수 있다. 대출자와 차용자가 대출 조건들에 동의했다는 확인을 수신하면, 대출 프로세스 스마트 계약(2022)은 합의된 대출 조건들에 따라 대출 스마트 계약(2034)을 인스턴스화할 수 있다. 일부 실시예에서, 토큰화 플랫폼(100)은, 차용자가 하나 이상의 잠재적 대출자에게 대출을 요청하고/하거나 하나 이상의 대출자와 대출 합의를 협상하는 것을 허용하는 GUI를 차용자에게 제공할 수 있다. 일부 실시예에서, 대출 협상은 토큰화 플랫폼(100) 등의 중앙집중형 서비스를 통하지 않고 온체인으로 처리될 수 있다는 것을 이해할 것이다. 실시예들에서, 차용자는 평가 가치를 초과하지 않는 대출 금액 및 대출 상환 시간량을 나타내는 제안된 대출 조건을 요청할 수 있다. 이들 실시예들 중 일부에서, 토큰화 플랫폼(100)은 GUI를 통해 잠재적인 대출자들에 프리젠팅되는 대출 요청을 생성할 수 있고, 이에 따라, 대출 요청은, 요청 금액, 대출의 기간, 및 차용자에 의해 제공되는 담보 아이템에 관한 정보(예를 들어, 담보 아이템의 VIRL, 인증 보고, 평가 보고, 보관 보고, 인증, 평가 및 보관자들이 각자의 작업을 (전술된 바와 같이) 확보했다는 확인 및/또는 기타 등등)를 나타낸다. 실시예들에서, 토큰화 시스템(100)은 대출에 대한 대출 상환 금액 및/또는 이자율을 (예를 들어, 현재 시장 상황에 기초하여) 제안할 수 있다. 대안으로서, 잠재적인 대출자는 GUI를 통해 차용자가 상환해야 하는 이자율 또는 총 상환 금액을 제공할 수 있다. 추가적으로, 잠재적 대출자는, 대출 금액 및/또는 상환 기간 등의, 요청된 대출 조건들 중 하나 이상에 대응할 수 있다. 그 다음, 대출 제안은 GUI를 통해 차용자에게 전달될 수 있으며, 여기서 차용자는 차용자 디바이스(2002)를 통해 대출 제안을 볼 수 있다. 이에 응답하여, 차용자는 대출 제안을 수락하거나, 대출 제안을 거부하거나, 반대 제안을 제공할 수 있다. 당사자는 합의에 도달하거나 한쪽 또는 양쪽 당사자가 대출 제안을 거부할 때까지 이러한 방식을 반복할 수 있다. 일단 대출에 도달하고 나면, 당사자들은 대출 합의를 실행할 수 있고, 토큰화 플랫폼(100)은 대출 합의가 차용자와 대출자에 의해 동의되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에게 제공할 수 있다. 실시예들에서, 통보는 대출 합의의 조건들을 포함하는 대출 합의의 상세사항을 포함할 수 있다. 이에 응답하여, 대출 프로세스 스마트 계약 인스턴스는 대출 상환 워크플로우를 실행하는 대출 스마트 계약 인스턴스를 인스턴스화할 수 있다. 일단 대출 합의가 실행되고 나면, 대출 스마트 계약은 에스크로 계정에 담보 토큰을 잠금처리할 수 있으며, 대출자의 계정으로부터 차용자의 계정으로의 자금 이전을 용이화할 수 있다. 실시예들에서, 대출 합의, 임의의 제안/반대 제안의 기록들, 담보 토큰의 에스크로잉 및 차용자에게로의 자금 이전과 관련된 기록들은 분산형 원장(2016)에 기입될 수 있다. 일단 대출 프로세스 스마트 계약 인스턴스가, 담보 토큰이 잠금처리되었고 자금이 이전되었다는 통보를 수신하고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 상환 스테이지(2714)로 진행시킬 수 있다.
상환 스테이지(2714) 동안, 대출 스마트 계약 인스턴스는, 대출 일정에 따라 차용자에 의해 대출자(또는 대출자에게 지불을 분배하는 계정)에게 지불이 이루어졌는지 및 대출이 채무불이행 상태에 있지 않음을 보장하기 위해 차용자 지불 이력을 모니터링할 수 있다. 대출 상환 스테이지 동안, 차용자는 지불을 송금할 수 있다. 지불이 이루어질 때마다, 대출 프로세스 스마트 계약 인스턴스는 지불이 이루어졌음을 나타내는 지불 통보 및 지불 금액을 수신할 수 있다. 그 다음, 대출 스마트 계약 인스턴스는 대출이 전액 상환되었는지를 결정할 수 있다. 대출이 전액 지불되지 않은 경우, 대출 스마트 계약 인스턴스는 대출 상환 금액을 조정할 수 있고, 인증자들, 평가자들, 및/또는 보관자들로부터의 일부 위험부담성 출자된 자금을 반환하여 새로운 대출 상환 금액을 반영하는 등의, 추가적인 동작들을 수행할 수 있다. 대출 스마트 계약 인스턴스가 대출 상환 금액이 전액 지불되었다고 결정하면, 대출 스마트 계약 인스턴스는 대출이 전액 지불되었음을 나타내는 상환 통보를 대출 프로세스 스마트 계약 인스턴스에 전송할 수 있고 대출 프로세스를 대출후 스테이지(2716)로 진행시킬 수 있다. 실시예들에서, 상환 통보는, 지불들이 이루어졌음을 나타내는 지불 이벤트 기록들의 해시 값들, 및 지불들의 금액 및/또는 분산형 원장(2016) 상의 지불 기록들의 주소들을 포함할 수 있다. 반대로, 대출 스마트 계약 인스턴스가 차용자가 채무불이행이라고 결정하면, 대출 스마트 계약 인스턴스는 청산 이벤트를 트리거할 수 있고/있거나 대출 조건들에 따라 대출이 채무불이행 상태임을 나타내는 채무불이행 통보를 대출 프로세스 스마트 계약에 전송할 수 있다. 실시예들에서, 채무불이행 통보는, 어떤 지불들이 누락되었는지를 나타내는 채무불이행 이벤트 기록의 해시 값들, 및 대출에 관한 나머지 잔액 및/또는 분산형 원장(2016) 상의 채무불이행 이벤트 기록의 주소들을 포함할 수 있다. 채무불이행 통보를 수신한 것에 응답하여, 대출 스마트 계약 인스턴스는 청산 이벤트를 개시할 수 있고 대출 프로세스를 대출후 스테이지(2716)로 진행시킬 수 있다.
대출후 스테이지(2716) 동안, 대출이 전액 지불되었거나 청산 이벤트가 수행된 경우 담보 토큰은 소유자에게 반환된다. 대출이 전액 상환되었다는 상환 통보를 수신하는 것에 응답하여, 대출 스마트 계약 인스턴스는 에스크로 계정으로부터 차용자의 계정으로의 담보 토큰의 이전을 개시할 수 있고, 차용자는 담보 아이템의 소유를 획득하기 위해 담보 토큰을 상환할 수 있다. 일단 대출이 성공적으로 상환되고 나면, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 평가 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 (예를 들어, 대출자에게 상환된 자금으로부터) 인증자, 평가자 및 보관자의 계정들로의 보상 지급을 개시할 수 있다.
청산 이벤트를 개시하는데 있어서, 대출 스마트 계약 인스턴스는 담보 토큰의 주소를, (예를 들어, 경매로) 담보 아이템을 청산할 수 있는 적절한 시장(예를 들어, 시장 시스템(102))에 전송할 수 있다. 청산 이벤트 동안, 구매자는 담보 토큰을 구매할 수 있고, 그 결과 담보 토큰의 소유권 데이터(2054)가 구매자에게 할당되고, 그 다음, 구매자는 담보 토큰을 상환하여 담보 아이템의 소유를 획득될 수 있다. 일단 청산되고 나면, 대출 프로세스 스마트 계약 인스턴스는 청산 이벤트의 수익금으로부터 대출자(또는 대출이 2차 대출자에게 판매된 경우 2차 대출자)에게 미결제 잔액의 나머지를 분배할 수 있다. 청산 이벤트 후, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 평가 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 청산 이벤트의 수익금으로부터 인증자들, 평가자들, 및 보관자의 계정들로의 보상 지급을 개시할 수 있다. 잔액이 남아 있는 한도까지, 나머지는 차용자의 계좌로 입금될 수 있다.
일단 대출 프로세스가 완료되고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스가 완료되었음을 토큰화 플랫폼(100)에게 통보할 수 있고, 토큰화 플랫폼(100)은 완료된 대출 프로세스에 기초하여 분석 프로세스를 실행할 수 있다. 일부 실시예에서, 대출 프로세스의 결과는, 인증자들, 평가자들, 보관자, 대출자, 및/또는 차용자 중 하나 이상의 등급을 업데이트하는데 이용될 수 있다.
전술한 내용은 탈집중형 대출 프로세스 워크플로우(2700)의 한 예이며 대안적인 워크플로우들이 실행될 수 있다는 것을 이해할 것이다. 또한, 탈집중형 대출 프로세스 워크플로우(2700)는, 명시적으로 논의되지 않은 추가적인 또는 대안적인 단계들을 포함할 수 있다.
도 28은 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우(2800)의 한 예를 나타낸다. 도 28의 예에서, 대출 프로세스 워크플로우(2800)는, 차량, 예술 작품, 깨지기 쉬운 물건(예를 들어, 꽃병 또는 샹들리에), 와인 또는 위스키 콜렉션 등의, 배송이 용이하지 않고/않거나 매우 큰 담보 아이템들에 대해 수행될 수 있다. 도 28의 워크플로우(2800)에서, 담보 아이템은 보관자에게 예치되고, 보관자는, 차례로, 담보 토큰으로 토큰화된 VIRL을 생성할 수 있다. 그러면, 담보 아이템의 VIRL이 당사자들 사이에서 물리적 담보 아이템을 이송할 필요없이 인증자들과 평가자들에게 제공될 수 있다. 도 28의 예에서, 대출 프로세스 워크플로우(2800)는 : 차용자가 대출 프로세스를 개시할 것을 요청하는 요청 스테이지(2802); 이에 후속하는, 담보 아이템의 소유가 보관자에 의해 취해지는 보관 스테이지(2804); 이에 후속하는, 보관자가 필요 문서를 제공하여 담보 토큰으로 토큰화될 담보 아이템의 VIRL을 생성할 수 있는 토큰화 스테이지(2806); 이에 후속하는, 하나 이상의 인증자가 하나 이상의 아이템을 인증하는 인증 스테이지(2808); 이에 후속하는, 인증된 아이템들이 평가되는 평가 스테이지(2810); 대출이 차용자와 대출자에 의해 협상되고 수락되는 대출 스테이지(2812); 이에 후속하는, 대출이 차용자에 의해 상환되는 상환 스테이지(2814); 이에 후속하는, 담보 토큰이 잠금해제되어 차용자에게 반환되거나 차용자가 대출에 관해 채무불이행한 경우 청산되고, 임의의 보상이 대출 프로세스의 참여자들에게 발행되는 대출후 스테이지(2816)를 포함할 수 있다.
요청 스테이지(2802) 동안, 차용자는, 차용자에 의해 소유된 아이템을 담보화하는 것을 포함하는 새로운 대출 프로세스를 개시할 것을 요청할 수 있다. 실시예들에서, 차용자는 토큰화 플랫폼(100)과 인터페이스하는 차용자 디바이스(2002)를 통해 대출을 요청할 수 있다. 이들 실시예에서, 토큰화 플랫폼(100)(또는 다른 적절한 시스템)은, 차용자가, 담보화될 담보 아이템, 담보 아이템의 위치, 요청 대출 금액, 및/또는 제안된 대출 조건 등의 정보를 제공할 수 있는 GUI를 제공할 수 있다. 차용자 요청에 응답하여, 토큰화 플랫폼(100)은 대출 프로세스 스마트 계약 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출 프로세스 스마트 계약 인스턴스는, (예를 들어, 차용자에 의해 제공된 요청으로부터) 담보 아이템의 유형을 결정할 수 있고, 대출 프로세스 동안 담보 아이템을 에스크로에 보관할 것을 보관자에게 요청할 수 있음으로써, 대출 프로세스를 보관 스테이지(2804)로 진행시킬 수 있다.
보관 스테이지(2804) 동안, 대출 프로세스 스마트 계약 인스턴스는 보관자에게 담보 아이템을 보관할 것을 요청할 수 있고 보관 워크플로우를 실행하는 보관 스마트 계약(2032)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 예를 들어 담보 아이템의 유형 및/또는 담보 아이템에 대한 보관자의 근접성에 기초하여, 보관자를 보관 작업에 할당할 수 있다. 일단 보관자가 아이템 수령을 확인하고 나면, 보관자는 아이템이 보관되었음을 나타내는 보관 보고를 생성하고, 수령 및 검사 당시 담보 아이템의 임의의 손상뿐만 아니라, 보관 보고를 뒷받침하는 임의의 지원 문서를 기록할 수 있다. 실시예들에서, 보관 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 보관자는 보관 동안 아이템이 분실되거나 손상된 경우 보호 수단으로서 담보 아이템의 대략적 가치와 같거나 비례하는 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다(또는 보험의 증빙을 제공할 수 있다). 실시예들에서, 보관 스마트 계약 인스턴스는, 그 다음, 아이템이 에스크로에 안전하게 보관되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에 제공할 수 있으며, 여기서, 통보는, 보관 보고 및 기타 임의의 지원 증거의 해시 값 및/또는 보관 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 통보에 응답하여, 대출 프로세스 스마트 계약은 대출 프로세스를 토큰화 스테이지(2806)로 진행시킬 수 있다.
토큰화 스테이지(2806) 동안, 토큰화 플랫폼(100)(또는 다른 적절한 컴포넌트)은 담보 아이템을 토큰화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 담보 아이템의 설명, 이미지, 비디오, 2D 스캔, 및/또는 3D 스캔 등의, 담보 아이템을 설명하고/하거나 묘사하는 데이터에 기초하여 담보 아이템의 VIRL을 생성할 수 있다. 실시예들에서, 차용자 또는 보관자는 VIRL을 생성하는데 이용되는 데이터를 제공할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은 담보 아이템의 VIRL에 기초하여 아이템의 담보 토큰을 생성한다. 일단 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은 토큰을 분산형 원장(2016)에 기입할 수 있고, 초기에 담보 토큰에 대한 소유권을 차용자에게 할당할 수 있다(대출 합의에 도달할 때까지). 일단 담보 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은, 토큰화 이벤트 및/또는 담보 토큰의 주소를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 토큰화 이벤트의 통보 수신시, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 인증 스테이지(2808)로 진행시킬 수 있다.
인증 스테이지(2808) 동안, 대출 프로세스 스마트 계약 인스턴스는 인증 스마트 계약(2028)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 전술된 바와 같이, 담보 아이템 등의 아이템들을 인증하는 것을 전문으로 하는 인증 길드로부터의 1차 인증자(및 잠재적으로 2차 인증자들)에게 인증 작업을 할당할 수 있다. 실시예들에서, 1차 인증자에게는 인증될 아이템의 VIRL이 전송될 수 있고, 인증자는 담보 아이템의 진위성에 대한 결정을 나타내는 인증 보고뿐만 아니라, 임의의 지원 문서를 생성할 수 있다. 실시예들에서, 인증 보고 및 지원 증거가 하나 이상의 2차 인증자에게 제공될 수 있으며, 이들은 차례로 인증 보고를 검증할 수 있고 추가 지원 문서를 제공할 수 있다. 실시예들에서, 인증 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예들에서, 인증 작업에 참여한 인증자들은, 아이템이 청산되고 나중에 가짜로 간주되는 경우 보호 수단으로서 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 예시적인 실시예들에서, 대출 프로세스 스마트 계약(2022)은 아이템이 인증자(들)에 의해 진품인지 또는 가짜로 간주되었는지를 나타내는 인스턴스화된 인증 스마트 계약(2028)에 의해 발행된 인증 통보를 청취하는 청취 스레드를 포함할 수 있고, 여기서, 인증 스마트 계약(2028)으로부터의 인증 통보는, 인증자들의 의견(예를 들어, 가짜 또는 정품), 인증 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 인증 보고 및 지원 문서에 대한 블록 주소를 포함할 수 있다. 대출 프로세스 스마트 계약 인스턴스가 아이템이 진품으로 간주되었다고 결정하면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 평가 스테이지(2810)로 진행시킬 수 있다.
평가 스테이지(2810) 동안, 대출 프로세스 스마트 계약 인스턴스는 인증된 아이템을 평가할 것을 하나 이상의 평가자에게 요청할 수 있고 평가 스마트 계약(2030)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 위에서 논의된 바와 같이, 담보 아이템의 유형에 기초하여 작업을 수행하는 하나 이상의 평가자를 식별할 수 있다. 실시예들에서, 1차 평가자에게 담보 아이템의 VIRL이 전송될 수 있다. 아이템이 진품으로 간주되었음을 알면, 평가자는 담보 아이템의 평가 가치를 결정할 수 있고 평가 가치를 나타내는 평가 보고와 평가 가치를 뒷받침하는 임의의 지원 문서를 생성할 수 있다. 일부 실시예에서, 하나 이상의 2차 평가자가 평가 보고를 검증할 수 있고 각자의 검증에 대한 지원 문서를 제공할 수 있다. 실시예들에서, 평가 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 평가 작업에 참여한 평가자들은, 아이템이 상환 금액의 나머지 잔액 및/또는 평가 가치보다 상당히 낮은 가격으로 청산되는 경우 보호 수단으로서 담보 아이템의 평가 가치와 같거나 비례하는 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 실시예들에서, 평가 스마트 계약(2030)은 평가 워크플로우가 성공적으로 완료되었음을 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 전송할 수 있고, 여기서, 통보는, 평가 가치, 평가 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 평가 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 평가 스테이지가 완료되었다고 결정하면, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 대출 스테이지(2812)로 진행시킬 수 있다.
대출 스테이지(2812) 동안, 차용자는 대출을 요청하고/하거나 하나 이상의 대출자와 대출을 협상할 수 있다. 대출자와 차용자가 대출 조건들에 동의했다는 확인을 수신하면, 대출 프로세스 스마트 계약(2022)은 합의된 대출 조건들에 따라 대출 스마트 계약(2034)을 인스턴스화할 수 있다. 일부 실시예에서, 토큰화 플랫폼(100)은, 차용자가 하나 이상의 잠재적 대출자에게 대출을 요청하고/하거나 하나 이상의 대출자와 대출 합의를 협상하는 것을 허용하는 GUI를 차용자에게 제공할 수 있다. 일부 실시예에서, 대출 협상은 토큰화 플랫폼(100) 등의 중앙집중형 서비스를 통하지 않고 온체인으로 처리될 수 있다는 것을 이해할 것이다. 실시예들에서, 차용자는 평가 가치를 초과하지 않는 대출 금액 및 대출 상환 시간량을 나타내는 제안된 대출 조건을 요청할 수 있다. 이들 실시예들 중 일부에서, 토큰화 플랫폼(100)은 GUI를 통해 잠재적인 대출자들에 프리젠팅되는 대출 요청을 생성할 수 있고, 이에 따라, 대출 요청은, 요청 금액, 대출의 기간, 및 차용자에 의해 제공되는 담보 아이템에 관한 정보(예를 들어, 담보 아이템의 VIRL, 인증 보고, 평가 보고, 보관 보고, 인증, 평가 및 보관자들이 각자의 작업(전술된 바와 같이)을 확보했다는 확인, 및/또는 기타 등등을 나타낸다. 실시예들에서, 토큰화 시스템(100)은 대출에 대한 대출 상환 금액 및/또는 이자율을 (예를 들어, 현재 시장 상황에 기초하여) 제안할 수 있다. 대안으로서, 잠재적인 대출자는 GUI를 통해 차용자가 상환해야 하는 이자율 또는 총 상환 금액을 제공할 수 있다. 추가적으로, 잠재적 대출자는, 대출 금액 및/또는 상환 기간 등의, 요청된 대출 조건들 중 하나 이상에 대응할 수 있다. 그 다음, 대출 제안은 GUI를 통해 차용자에게 전달될 수 있으며, 여기서 차용자는 차용자 디바이스(2002)를 통해 대출 제안을 볼 수 있다. 이에 응답하여, 차용자는 대출 제안을 수락하거나, 대출 제안을 거부하거나, 반대 제안을 제공할 수 있다. 당사자는 합의에 도달하거나 한쪽 또는 양쪽 당사자가 대출 제안을 거부할 때까지 이러한 방식을 반복할 수 있다. 일단 대출에 도달하고 나면, 당사자들은 대출 합의를 실행할 수 있고, 토큰화 플랫폼(100)은 대출 합의가 차용자와 대출자에 의해 동의되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에게 제공할 수 있다. 실시예들에서, 통보는 대출 합의의 조건들을 포함하는 대출 합의의 상세사항을 포함할 수 있다. 이에 응답하여, 대출 프로세스 스마트 계약 인스턴스는 대출 상환 워크플로우를 실행하는 대출 스마트 계약 인스턴스를 인스턴스화할 수 있다. 일단 대출 합의가 실행되고 나면, 대출 스마트 계약은 에스크로 계정에 담보 토큰을 잠금처리할 수 있으며, 대출자의 계정으로부터 차용자의 계정으로의 자금 이전을 용이화할 수 있다. 실시예들에서, 대출 합의, 임의의 제안/반대 제안의 기록들, 담보 토큰의 에스크로잉 및 차용자에게로의 자금 이전과 관련된 기록들은 분산형 원장(2016)에 기입될 수 있다. 일단 대출 프로세스 스마트 계약 인스턴스가, 담보 토큰이 잠금처리되었고 자금이 이전되었다는 통보를 수신하고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 상환 스테이지(2814)로 진행시킬 수 있다.
상환 스테이지(2814) 동안, 대출 스마트 계약 인스턴스는, 대출 일정에 따라 차용자에 의해 대출자(또는 대출자에게 지불을 분배하는 계정)에게 지불이 이루어졌는지 및 대출이 채무불이행 상태에 있지 않음을 보장하기 위해 차용자 지불 이력을 모니터링할 수 있다. 대출 상환 스테이지 동안, 차용자는 지불을 송금할 수 있다. 지불이 이루어질 때마다, 대출 프로세스 스마트 계약 인스턴스는 지불이 이루어졌음을 나타내는 지불 통보 및 지불 금액을 수신할 수 있다. 그 다음, 대출 스마트 계약 인스턴스는 대출이 전액 상환되었는지를 결정할 수 있다. 대출이 전액 지불되지 않은 경우, 대출 스마트 계약 인스턴스는 대출 상환 금액을 조정하고, 인증자들, 평가자들, 및/또는 보관자들로부터의 일부 위험부담성 출자된 자금을 반환하여 새로운 대출 상환 금액을 반영하는 등의, 추가적인 동작들을 수행할 수 있다. 대출 스마트 계약 인스턴스가 대출 상환 금액이 전액 지불되었다고 결정하면, 대출 스마트 계약 인스턴스는 대출이 전액 지불되었음을 나타내는 상환 통보를 대출 프로세스 스마트 계약 인스턴스에 전송하고 대출 프로세스를 대출후 스테이지(2816)로 진행시킬 수 있다. 실시예들에서, 상환 통보는, 지불들이 이루어졌음을 나타내는 지불 이벤트 기록들의 해시 값들, 및 지불들의 금액 및/또는 분산형 원장(2016) 상의 지불 기록들의 주소들을 포함할 수 있다. 반대로, 대출 스마트 계약 인스턴스가 차용자가 채무불이행이라고 결정하면, 대출 스마트 계약 인스턴스는 청산 이벤트를 트리거하고/하거나 대출 조건들에 따라 대출이 채무불이행 상태임을 나타내는 채무불이행 통보를 대출 프로세스 스마트 계약에 전송할 수 있다. 실시예들에서, 채무불이행 통보는, 어떤 지불들이 누락되었는지를 나타내는 채무불이행 이벤트 기록의 해시 값들, 및 대출에 관한 나머지 잔액 및/또는 분산형 원장(2016) 상의 채무불이행 이벤트 기록의 주소들을 포함할 수 있다. 채무불이행 통보를 수신한 것에 응답하여, 대출 스마트 계약 인스턴스는 청산 이벤트를 개시할 수 있고 대출 프로세스를 대출후 스테이지(2816)로 진행시킬 수 있다.
대출후 스테이지(2816) 동안, 대출이 전액 지불되었거나 청산 이벤트가 수행된 경우 담보 토큰은 소유자에게 반환된다. 대출이 전액 상환되었다는 상환 통보를 수신하는 것에 응답하여, 대출 스마트 계약 인스턴스는 에스크로 계정으로부터 차용자의 계정으로의 담보 토큰의 이전을 개시할 수 있고, 차용자는 담보 아이템의 소유를 획득하기 위해 담보 토큰을 상환할 수 있다. 일단 대출이 성공적으로 상환되고 나면, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 평가 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 (예를 들어, 대출자에게 상환된 자금으로부터) 인증자, 평가자 및 보관자의 계정들로의 보상 지급을 개시할 수 있다.
청산 이벤트를 개시하는데 있어서, 대출 스마트 계약 인스턴스는 담보 토큰의 주소를, (예를 들어, 경매로) 담보 아이템을 청산할 수 있는 적절한 시장(예를 들어, 시장 시스템(102))에 전송할 수 있다. 청산 이벤트 동안, 구매자는 담보 토큰을 구매할 수 있고, 그 결과 담보 토큰의 소유권 데이터(2054)가 구매자에게 할당되고, 그 다음, 구매자는 담보 토큰을 상환하여 담보 아이템의 소유를 획득될 수 있다. 일단 청산되고 나면, 대출 프로세스 스마트 계약 인스턴스는 청산 이벤트의 수익금으로부터 대출자(또는 대출이 2차 대출자에게 판매된 경우 2차 대출자)에게 미결제 잔액의 나머지를 분배할 수 있다. 청산 이벤트 후, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 평가 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 청산 이벤트의 수익금으로부터 인증자들, 평가자들, 및 보관자의 계정들로의 보상 지급을 개시할 수 있다. 잔액이 남아 있는 한도까지, 나머지는 차용자의 계좌로 입금될 수 있다.
일단 대출 프로세스가 완료되고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스가 완료되었음을 토큰화 플랫폼(100)에게 통보할 수 있고, 토큰화 플랫폼(100)은 완료된 대출 프로세스에 기초하여 분석 프로세스를 실행할 수 있다. 일부 실시예에서, 대출 프로세스의 결과는, 인증자들, 평가자들, 보관자, 대출자, 및/또는 차용자 중 하나 이상의 등급을 업데이트하는데 이용될 수 있다.
전술한 내용은 탈집중형 대출 프로세스 워크플로우(2800)의 한 예이며 대안적인 워크플로우들이 실행될 수 있다는 것을 이해할 것이다. 또한, 탈집중형 대출 프로세스 워크플로우(2800)는, 명시적으로 논의되지 않은 추가적인 또는 대안적인 단계들을 포함할 수 있다.
도 29는 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우(2900)의 한 예를 나타낸다. 도 29의 예에서, 대출 프로세스 워크플로우(2900)는 차용자가 담보 아이템을 과대평가할 가능성이 있을 때 수행될 수 있다. 예를 들어, 차용자는 $10,000의 대출 금액을 확보하기를 원하고 한 켤레의 디자이너 운동화로 대출을 확보하기를 원할 수 있다. 이러한 상황에서, 도 29의 대출 프로세스 워크플로우(2900)가 실행될 수 있고, 평가 스테이지는 인증 스테이지 및 보관 스테이지 이전에 수행된다. 이러한 방식으로, 평가 가치가 원하는 대출 금액보다 훨씬 적은 경우, 차용자는 인증 수수료 및/또는 보관 수수료를 지불할 필요 없이 대출 프로세스를 포기할 수 있다. 도 29의 예에서, 대출 프로세스 워크플로우(2900)는 : 차용자가 대출 프로세스를 개시할 것을 요청하는 요청 스테이지(2902); 이에 후속하는, 하나 이상의 평가자가 하나 이상의 아이템을 평가하는 평가 스테이지(2904), 이에 후속하는, 평가된 아이템들이 인증되는 인증 스테이지(2906); 이에 후속하는, 인증된 아이템들이 신뢰할 수 있는 보관자의 에스크로에 보관되는 보관 스테이지(2908), 원장 관리 시스템(104)(또는 다른 적절한 컴포넌트)이 하나 이상의 에스크로잉된 아이템의 VIRL들을 생성하고 에스크로잉된 아이템들의 VIRL들을 토큰화함으로써 담보 토큰을 생성하는 토큰화 스테이지(2910); 이에 후속하는, 대출이 차용자와 대출자에 의해 협상되고 수락되는 대출 스테이지(2912); 이에 후속하는, 차용자에 의해 대출이 상환되는 상환 스테이지(2914); 및 이에 후속하는, 담보 토큰이 잠금해제되어 차용자에게 반환되거나 차용자가 대출에 관해 채무불이행하는 경우에는 청산되고 대출 프로세스의 참여자들에게 임의의 보상이 발생되는 대출후 스테이지(2916)를 포함할 수 있다.
요청 스테이지(2902) 동안, 차용자는, 차용자에 의해 소유된 아이템을 담보화하는 것을 포함하는 새로운 대출 프로세스를 개시할 것을 요청할 수 있다. 실시예들에서, 차용자는 토큰화 플랫폼(100)과 인터페이스하는 차용자 디바이스(2002)를 통해 대출을 요청할 수 있다. 이들 실시예에서, 토큰화 플랫폼(100)(또는 다른 적절한 시스템)은, 차용자가, 담보화될 담보 아이템, 담보 아이템의 위치, 요청 대출 금액, 및/또는 제안된 대출 조건 등의 정보를 제공할 수 있는 GUI를 제공할 수 있다. 차용자 요청에 응답하여, 토큰화 플랫폼(100)은 대출 프로세스 스마트 계약 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출 프로세스 스마트 계약 인스턴스는 (예를 들어, 차용자에 의해 제공된 요청으로부터) 담보 아이템의 유형을 결정할 수 있고, 담보 아이템을 평가할 것을 평가자(및 잠재적으로 2차 평가자들)에게 요청할 수 있음으로써, 대출 프로세스를 평가 스테이지(2904)로 진행시킬 수 있다.
평가 스테이지(2904) 동안, 대출 프로세스 스마트 계약 인스턴스는 평가 스마트 계약(2030)의 인스턴스를 인스턴스화할 수 있고 인증된 아이템을 평가할 것을 하나 이상의 평가자에게 요청할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 위에서 논의된 바와 같이, 담보 아이템의 유형, 아이템의 위치, 및/또는 기타 등등에 기초하여 작업을 수행할 하나 이상의 평가자를 식별할 수 있다. 실시예들에서, 1차 평가자는 (예를 들어, 우편 또는 기타의 배송을 통해) 담보 아이템을 수령할 수 있고 담보 아이템의 평가 가치를 결정할 수 있다. 이 워크플로우(2900)에서, 평가자는 아이템이 인증자들에 의해 진품으로 간주되었음을 알고 있는 것에 대한 이점을 갖지 못한다. 그럼에도 불구하고, 평가자는 아이템이 인증자들에 의해 진품으로 간주될 것이라고 가정할 수 있다. 실시예들에서, 1차 평가자는 결정된 평가 가치를 나타내는 평가 보고 및 평가 가치를 뒷받침하는 임의의 지원 문서를 생성할 수 있다. 일부 실시예에서, 하나 이상의 2차 평가자가 평가 보고를 검증할 수 있고 각자의 검증에 대한 지원 문서를 제공할 수 있다. 실시예들에서, 평가 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 평가 작업에 참여한 평가자들은, 아이템이 상환 금액의 나머지 잔액 및/또는 평가 가치보다 상당히 낮은 가격으로 청산되는 경우 보호 수단으로서 담보 아이템의 평가 가치와 같거나 비례하는 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 실시예들에서, 평가 스마트 계약(2030)은 평가 워크플로우가 성공적으로 완료되었음을 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 전송할 수 있고, 여기서, 통보는, 평가 가치, 평가 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 평가 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 일부 시나리오에서, 평가 가치가 요청된 대출 금액보다 훨씬 적으며, 이 경우, 차용자는 대출 프로세스를 종료하기로 선택할 수 있다. 평가 가치가 주어지면 차용자가 대출 프로세스를 계속하기로 결정한다고 가정하면, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 평가 스테이지(2906)로 진행시킬 수 있다.
인증 스테이지(2906) 동안, 대출 프로세스 스마트 계약 인스턴스는 인증 스마트 계약(2028)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 전술된 바와 같이, 담보 아이템 등의 아이템들을 인증하는 것을 전문으로 하는 인증 길드로부터의 1차 인증자(및 잠재적으로 2차 인증자들)에게 인증 작업을 할당할 수 있다. 실시예들에서, 담보 아이템이 물리적으로 1차 인증자들에게(예를 들어, 평가자로부터) 전송되거나 담보 아이템의 VIRL이 인증자에게 디지털 방식으로 전송된다. 실시예들에서, 1차 인증자는 인증자 디바이스(2004)를 통해 인증될 담보 아이템(또는 그 VIRL)의 수령을 확인할 수 있다. 실시예들에서, 인증자는 담보 아이템의 진위성에 대한 결정을 나타내는 인증 보고뿐만 아니라, 임의의 지원 문서를 생성할 수 있다. 실시예들에서, 인증 보고 및 지원 증거가 하나 이상의 2차 인증자에게 제공될 수 있으며, 이들은 차례로 인증 보고를 검증할 수 있고 추가 지원 문서를 제공할 수 있다. 실시예들에서, 인증 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예들에서, 인증 작업에 참여한 인증자들은, 아이템이 청산되고 나중에 가짜로 간주되는 경우 보호 수단으로서 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 예시적인 실시예들에서, 대출 프로세스 스마트 계약(2022)은 아이템이 인증자(들)에 의해 진품인지 또는 가짜로 간주되었는지를 나타내는 인스턴스화된 인증 스마트 계약(2028)에 의해 발행된 인증 통보를 청취하는 청취 스레드를 포함할 수 있고, 여기서, 인증 스마트 계약(2028)으로부터의 통보는, 인증자들의 의견(예를 들어, 가짜 또는 정품), 인증 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 인증 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 대출 프로세스 스마트 계약 인스턴스가 아이템이 진품으로 간주되었다고 결정하면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 보관 스테이지(2908)로 진행시킬 수 있다.
보관 스테이지(2908) 동안, 대출 프로세스 스마트 계약 인스턴스는 보관자에게 담보 아이템을 보관할 것을 요청할 수 있고 보관 워크플로우를 실행하는 보관 스마트 계약(2032)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 예를 들어 담보 아이템의 유형 및/또는 담보 아이템에 대한 보관자의 근접성에 기초하여, 보관자를 보관 작업에 할당할 수 있다. 일단 보관자가 아이템 수령을 확인하고 나면, 보관자는 아이템이 보관되었음을 나타내는 보관 보고를 생성하고, 수령 및 검사 당시 담보 아이템의 임의의 손상뿐만 아니라, 보관 보고를 뒷받침하는 임의의 지원 문서를 기록할 수 있다. 실시예들에서, 보관 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 보관자는 보관 동안 아이템이 분실되거나 손상된 경우 보호 수단으로서 담보 아이템의 평가 가치와 같거나 비례하는 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다(또는 보험의 증빙을 제공할 수 있다). 실시예들에서, 보관 스마트 계약 인스턴스는, 그 다음, 아이템이 에스크로에 안전하게 보관되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에 제공할 수 있으며, 여기서, 통보는, 보관 보고 및 기타 임의의 지원 증거의 해시 값 및/또는 보관 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 통보에 응답하여, 대출 프로세스 스마트 계약은 대출 프로세스를 토큰화 스테이지(2910)로 진행시킬 수 있다.
토큰화 스테이지(2910) 동안, 토큰화 플랫폼(100)(또는 다른 적절한 컴포넌트)은 담보 아이템을 토큰화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 담보 아이템의 설명, 이미지, 비디오, 2D 스캔, 및/또는 3D 스캔 등의, 담보 아이템을 설명하고/하거나 묘사하는 데이터에 기초하여 담보 아이템의 VIRL을 생성할 수 있다. 실시예들에서, 차용자, 보관자, 및/또는 인증자는 VIRL을 생성하는데 이용되는 데이터를 제공할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은 담보 아이템의 VIRL에 기초하여 아이템의 담보 토큰을 생성한다. 일단 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은 토큰을 분산형 원장(2016)에 기입할 수 있고, 초기에 담보 토큰에 대한 소유권을 차용자에게 할당할 수 있다(대출 합의에 도달할 때까지). 일단 담보 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은, 토큰화 이벤트 및/또는 담보 토큰의 주소를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 토큰화 이벤트의 통보 수신시, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 대출 스테이지(2912)로 진행시킬 수 있다.
대출 스테이지(2912) 동안, 차용자는 대출을 요청하고/하거나 하나 이상의 대출자와 대출을 협상할 수 있다. 대출자와 차용자가 대출 조건들에 동의했다는 확인을 수신하면, 대출 프로세스 스마트 계약(2022)은 합의된 대출 조건들에 따라 대출 스마트 계약(2034)을 인스턴스화할 수 있다. 일부 실시예에서, 토큰화 플랫폼(100)은, 차용자가 하나 이상의 잠재적 대출자에게 대출을 요청하고/하거나 하나 이상의 대출자와 대출 합의를 협상하는 것을 허용하는 GUI를 차용자에게 제공할 수 있다. 일부 실시예에서, 대출 협상은 토큰화 플랫폼(100) 등의 중앙집중형 서비스를 통하지 않고 온체인으로 처리될 수 있다는 것을 이해할 것이다. 실시예들에서, 차용자는 평가 가치를 초과하지 않는 대출 금액 및 대출 상환 시간량을 나타내는 제안된 대출 조건을 요청할 수 있다. 이들 실시예들 중 일부에서, 토큰화 플랫폼(100)은 GUI를 통해 잠재적인 대출자들에 프리젠팅되는 대출 요청을 생성할 수 있고, 이에 따라, 대출 요청은, 요청 금액, 대출의 기간, 및 차용자에 의해 제공되는 담보 아이템에 관한 정보(예를 들어, 담보 아이템의 VIRL, 인증 보고, 평가 보고, 보관 보고, 인증, 평가 및 보관자들이 각자의 작업(전술된 바와 같이)을 확보했다는 확인 및/또는 기타 등등)를 나타낸다. 실시예들에서, 토큰화 시스템(100)은 대출에 대한 대출 상환 금액 및/또는 이자율을 (예를 들어, 현재 시장 상황에 기초하여) 제안할 수 있다. 대안으로서, 잠재적인 대출자는 GUI를 통해 차용자가 상환해야 하는 이자율 또는 총 상환 금액을 제공할 수 있다. 추가적으로, 잠재적 대출자는, 대출 금액 및/또는 상환 기간 등의, 요청된 대출 조건들 중 하나 이상에 대응할 수 있다. 그 다음, 대출 제안은 GUI를 통해 차용자에게 전달될 수 있으며, 여기서 차용자는 차용자 디바이스(2002)를 통해 대출 제안을 볼 수 있다. 이에 응답하여, 차용자는 대출 제안을 수락하거나, 대출 제안을 거부하거나, 반대 제안을 제공할 수 있다. 당사자는 합의에 도달하거나 한쪽 또는 양쪽 당사자가 대출 제안을 거부할 때까지 이러한 방식을 반복할 수 있다. 일단 대출에 도달하고 나면, 당사자들은 대출 합의를 실행할 수 있고, 토큰화 플랫폼(100)은 대출 합의가 차용자와 대출자에 의해 동의되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에게 제공할 수 있다. 실시예들에서, 통보는 대출 합의의 조건들을 포함하는 대출 합의의 상세사항을 포함할 수 있다. 이에 응답하여, 대출 프로세스 스마트 계약 인스턴스는 대출 상환 워크플로우를 실행하는 대출 스마트 계약 인스턴스를 인스턴스화할 수 있다. 일단 대출 합의가 실행되고 나면, 대출 스마트 계약은 에스크로 계정에 담보 토큰을 잠금처리할 수 있으며, 대출자의 계정으로부터 차용자의 계정으로의 자금 이전을 용이화할 수 있다. 실시예들에서, 대출 합의, 임의의 제안/반대 제안의 기록들, 담보 토큰의 에스크로잉 및 차용자에게로의 자금 이전과 관련된 기록들은 분산형 원장(2016)에 기입될 수 있다. 일단 대출 프로세스 스마트 계약 인스턴스가, 담보 토큰이 잠금처리되었고 자금이 이전되었다는 통보를 수신하고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 상환 스테이지(2914)로 진행시킬 수 있다.
상환 스테이지(2914) 동안, 대출 스마트 계약 인스턴스는, 대출 일정에 따라 차용자에 의해 대출자(또는 대출자에게 지불을 분배하는 계정)에게 지불이 이루어졌는지 및 대출이 채무불이행 상태에 있지 않음을 보장하기 위해 차용자 지불 이력을 모니터링할 수 있다. 대출 상환 스테이지 동안, 차용자는 지불을 송금할 수 있다. 지불이 이루어질 때마다, 대출 프로세스 스마트 계약 인스턴스는 지불이 이루어졌음을 나타내는 지불 통보 및 지불 금액을 수신할 수 있다. 그 다음, 대출 스마트 계약 인스턴스는 대출이 전액 상환되었는지를 결정할 수 있다. 대출이 전액 지불되지 않은 경우, 대출 스마트 계약 인스턴스는 대출 상환 금액을 조정하고, 인증자들, 평가자들, 및/또는 보관자들로부터의 일부 위험부담성 출자된 자금을 반환하여 새로운 대출 상환 금액을 반영하는 등의, 추가적인 동작들을 수행할 수 있다. 대출 스마트 계약 인스턴스가 대출 상환 금액이 전액 지불되었다고 결정하면, 대출 스마트 계약 인스턴스는 대출이 전액 지불되었음을 나타내는 상환 통보를 대출 프로세스 스마트 계약 인스턴스에 전송하고 대출 프로세스를 대출후 스테이지(2916)로 진행시킬 수 있다. 실시예들에서, 상환 통보는, 지불들이 이루어졌음을 나타내는 지불 이벤트 기록들의 해시 값들, 및 지불들의 금액 및/또는 분산형 원장(2016) 상의 지불 기록들의 주소들을 포함할 수 있다. 반대로, 대출 스마트 계약 인스턴스가 차용자가 채무불이행이라고 결정하면, 대출 스마트 계약 인스턴스는 청산 이벤트를 트리거하고/하거나 대출 조건들에 따라 대출이 채무불이행 상태임을 나타내는 채무불이행 통보를 대출 프로세스 스마트 계약에 전송할 수 있다. 실시예들에서, 채무불이행 통보는, 어떤 지불들이 누락되었는지를 나타내는 채무불이행 이벤트 기록의 해시 값들, 및 대출에 관한 나머지 잔액 및/또는 분산형 원장(2016) 상의 채무불이행 이벤트 기록의 주소들을 포함할 수 있다. 채무불이행 통보를 수신한 것에 응답하여, 대출 스마트 계약 인스턴스는 청산 이벤트를 개시할 수 있고 대출 프로세스를 대출후 스테이지(2916)로 진행시킬 수 있다.
대출후 스테이지(2916) 동안, 대출이 전액 지불되었거나 청산 이벤트가 수행된 경우 담보 토큰은 소유자에게 반환된다. 대출이 전액 상환되었다는 상환 통보를 수신하는 것에 응답하여, 대출 스마트 계약 인스턴스는 에스크로 계정으로부터 차용자의 계정으로의 담보 토큰의 이전을 개시할 수 있고, 차용자는 담보 아이템의 소유를 획득하기 위해 담보 토큰을 상환할 수 있다. 일단 대출이 성공적으로 상환되고 나면, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 평가 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 (예를 들어, 대출자에게 상환된 자금으로부터) 인증자, 평가자 및 보관자의 계정들로의 보상 지급을 개시할 수 있다.
청산 이벤트를 개시하는데 있어서, 대출 스마트 계약 인스턴스는 담보 토큰의 주소를, (예를 들어, 경매로) 담보 아이템을 청산할 수 있는 적절한 시장(예를 들어, 시장 시스템(102))에 전송할 수 있다. 청산 이벤트 동안, 구매자는 담보 토큰을 구매할 수 있고, 그 결과 담보 토큰의 소유권 데이터(2054)가 구매자에게 할당되고, 그 다음, 구매자는 담보 토큰을 상환하여 담보 아이템의 소유를 획득될 수 있다. 일단 청산되고 나면, 대출 프로세스 스마트 계약 인스턴스는 청산 이벤트의 수익금으로부터 대출자(또는 대출이 2차 대출자에게 판매된 경우 2차 대출자)에게 미결제 잔액의 나머지를 분배할 수 있다. 청산 이벤트 후, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 평가 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 청산 이벤트의 수익금으로부터 인증자들, 평가자들, 및 보관자의 계정들로의 보상 지급을 개시할 수 있다. 잔액이 남아 있는 한도까지, 나머지는 차용자의 계좌로 입금될 수 있다.
일단 대출 프로세스가 완료되고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스가 완료되었음을 토큰화 플랫폼(100)에게 통보할 수 있고, 토큰화 플랫폼(100)은 완료된 대출 프로세스에 기초하여 분석 프로세스를 실행할 수 있다. 일부 실시예에서, 대출 프로세스의 결과는, 인증자들, 평가자들, 보관자, 대출자, 및/또는 차용자 중 하나 이상의 등급을 업데이트하는데 이용될 수 있다.
전술한 내용은 탈집중형 대출 프로세스 워크플로우(2900)의 한 예이며 대안적인 워크플로우들이 실행될 수 있다는 것을 이해할 것이다. 또한, 탈집중형 대출 프로세스 워크플로우(2900)는, 명시적으로 논의되지 않은 추가적인 또는 대안적인 단계들을 포함할 수 있다.
도 30은 본 개시내용의 일부 실시예에 따른 대출 프로세스 워크플로우(3000)의 한 예를 나타낸다. 예시적인 대출 프로세스 워크플로우(3000)에서, 대출 조건들에 동의하기 전에 대출전 청산 이벤트가 수행된다. 예시적인 대출전 청산 스테이지 동안, 시장(예를 들어, 토큰화 플랫폼(100)의 시장 시스템(102)에 의해 호스팅되거나 이와 통신하는 시장)은, 미필적 상황 세트를 수반한 담보 아이템을 동반하는 대출의 협상 및/또는 실행 전에 담보 아이템을 정가로 미필적 구매자에게 판매하거나 담보 아이템을 미필적 구매자에게 경매 처분할 수 있다. 실시예들에서, 미필적 상황 세트는 소유 미필적 상황 및 보상 미필적 상황을 포함할 수 있다. 실시예들에서, 소유 미필적 상황은, 담보 아이템에 의해 담보된 차용자에 의해 체결된 대출 합의와 관련하여 확정된 채무불이행 이벤트시에 담보 아이템에 대한 미필적 구매자의 소유권을 조건으로 한다. 달리 말하면, 미필적 구매자는, 차용자가 담보 아이템을 담보로서 이용하여 대출을 확보할 수 있었고 차용자가 나중에 그 대출에 관해 채무불이행을 한 경우에만 (예를 들어, 대응하는 담보 아이템을 상환함으로써) 담보 아이템의 소유권을 취할 수 있을 것이다. 실시예들에서, 보상 미필적 상황은, 차용자가 대출을 성공적으로 상환하는 경우 (예를 들어, 보상을 그 전자 계정에 입금함으로써) 미필적 구매자에게 보상(예를 들어, 소정 금액의 통화/토큰화된 토큰 또는 법정 화폐)을 지급하는 것을 조건으로 할 수 있다. 이러한 방식으로, 미필적 구매자는, 대출이 성공적으로 상환될 경우 보상을 받을 수 있으므로, 미필적 상황시에 담보 아이템 아이템을 구매하도록 동기부여된다. 다시 말해, 미필적 구매자는, 담보 아이템의 현재 소유자(즉, 차용자)가 대출에 들어가기 전에 담보 아이템의 청산 가격을 설정하는 것에 동의하는 대가로 금전적 보상을 받을 수 있다. 일부 실시예에서, 차용자는 미필적 구매자에게 담보 아이템을 판매하는 것에 동의하고 대출전 청산 스테이지 후에 대출을 찾아 낼 기회를 포기할 수 있다는 점에 유의한다. 대출전 청산 스테이지는 평가 스테이지 대신에 수행될 수 있거나 평가 스테이지 후에 요청할 수 있다(예를 들어, 차용자 및/또는 대출자 중 한쪽 이상 양쪽 당사자가 담보 아이템의 평가 가치에 동의하지 않는 경우).
도 30의 예에서, 대출 프로세스 워크플로우(3000)는 : 차용자가 대출 프로세스를 개시할 것을 요청하는 요청 스테이지(3002); 이에 후속하는, 하나 이상의 인증자가 담보 아이템을 인증하는 인증 스테이지(3004); 이에 후속하는, 인증된 아이템이 신뢰할 수 있는 보관자의 에스크로에 저장되는 보관 스테이지(3006); 이에 후속하는, 담보 아이템에 대응하는 VIRL이 생성되고 담보 토큰으로 토큰화되는 토큰화 스테이지(3010); 이에 후속하는, 대출 조건들이 협상되기 전에 담보 아이템의 청산 가치를 설정하기 위해 시장을 통해 인증된 아이템이 주건부로 판매되는 대출전 청산 스테이지(3006); 이에 후속하는, 차용자와 대출자에 의해 대출이 협상되고 수락되는 대출 스테이지(3012); 이에 후속하는, 대출이 차용자에 의해 상환되는 상환 스테이지(3014); 이에 후속하는, 담보 토큰이 잠금해제되어 차용자에게 반환되거나 차용자가 대출에 관해 채무불이행한 경우 청산되고, 임의의 보상이 대출 프로세스의 참여자들에게 발행되는 대출후 스테이지(3016)를 포함할 수 있다.
요청 스테이지(3002) 동안, 차용자는, 차용자에 의해 소유된 아이템을 담보화하는 것을 포함하는 새로운 대출 프로세스를 개시할 것을 요청할 수 있다. 실시예들에서, 차용자는 토큰화 플랫폼(100)과 인터페이스하는 차용자 디바이스(2002)를 통해 대출을 요청할 수 있다. 이들 실시예에서, 토큰화 플랫폼(100)(또는 다른 적절한 시스템)은, 차용자가, 담보화될 담보 아이템, 담보 아이템의 위치, 요청 대출 금액, 및/또는 제안된 대출 조건 등의 정보를 제공할 수 있는 GUI를 제공할 수 있다. 차용자 요청에 응답하여, 토큰화 플랫폼(100)은 대출 프로세스 스마트 계약 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출 프로세스 스마트 계약 인스턴스는 (예를 들어, 차용자에 의해 제공된 요청으로부터) 담보 아이템의 유형을 결정할 수 있고, 담보 아이템을 인증할 것을 인증자(및 잠재적으로 2차 인증자들)에게 요청할 수 있음으로써, 대출 프로세스를 인증 스테이지(3004)로 진행시킬 수 있다.
인증 스테이지(3004) 동안, 대출 프로세스 스마트 계약 인스턴스는 인증 스마트 계약(2028)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 전술된 바와 같이, 담보 아이템 등의 아이템들을 인증하는 것을 전문으로 하는 인증 길드로부터의 1차 인증자(및 잠재적으로 2차 인증자들)에게 인증 작업을 할당할 수 있다. 실시예들에서, 1차 인증자는 인증자 디바이스(2004)를 통해 인증될 아이템의 수령을 확인해 줄 수 있다. 실시예들에서, 인증자는 담보 아이템의 진위성에 대한 결정을 나타내는 인증 보고뿐만 아니라, 임의의 지원 문서를 생성할 수 있다. 실시예들에서, 인증 보고 및 지원 증거가 하나 이상의 2차 인증자에게 제공될 수 있으며, 이들은 차례로 인증 보고를 검증할 수 있고 추가 지원 문서를 제공할 수 있다. 실시예들에서, 인증 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예들에서, 인증 작업에 참여한 인증자들은, 아이템이 청산되고 나중에 가짜로 간주되는 경우 보호 수단으로서 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다. 예시적인 실시예들에서, 대출 프로세스 스마트 계약(2022)은 아이템이 인증자(들)에 의해 진품인지 또는 가짜로 간주되었는지를 나타내는 인스턴스화된 인증 스마트 계약(2028)에 의해 발행된 인증 통보를 청취하는 청취 스레드를 포함할 수 있고, 여기서, 인증 스마트 계약(2028)으로부터의 통보는, 인증자들의 의견(예를 들어, 가짜 또는 정품), 인증 보고 및 기타 임의의 지원 증거의 해시 값, 및/또는 인증 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 대출 프로세스 스마트 계약 인스턴스가 아이템이 진품으로 간주되었다고 결정하면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 보관 스테이지(3006)로 진행시킬 수 있다.
보관 스테이지(3006) 동안, 대출 프로세스 스마트 계약 인스턴스는 보관자에게 담보 아이템을 보관할 것을 요청할 수 있고 보관 워크플로우를 실행하는 보관 스마트 계약(2032)의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 예를 들어 담보 아이템의 유형 및/또는 담보 아이템에 대한 보관자의 근접성에 기초하여, 보관자를 보관 작업에 할당할 수 있다. 일단 보관자가 아이템 수령을 확인하고 나면, 보관자는 아이템이 보관되었음을 나타내는 보관 보고를 생성하고, 수령 및 검사 당시 담보 아이템의 임의의 손상뿐만 아니라, 보관 보고를 뒷받침하는 임의의 지원 문서를 기록할 수 있다. 실시예들에서, 보관 보고 및 임의의 지원 문서는 분산형 원장(2016)에 기입될 수 있다. 일부 실시예에서, 보관자는 보관 동안 아이템이 분실되거나 손상된 경우 보호 수단으로서 담보 아이템의 대략적 가치와 같거나 비례하는 소정 금액의 통화/토큰화된 토큰을 위험부담성 출자할 것을 요구받을 수 있다(또는 보험의 증빙을 제공할 수 있다). 실시예들에서, 보관 스마트 계약 인스턴스는, 그 다음, 아이템이 에스크로에 안전하게 보관되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에 제공할 수 있으며, 여기서, 통보는, 보관 보고 및 기타 임의의 지원 증거의 해시 값 및/또는 보관 보고 및 지원 증거에 대한 블록 주소를 포함할 수 있다. 통보에 응답하여, 대출 프로세스 스마트 계약은 대출 프로세스를 토큰화 스테이지(3008)로 진행시킬 수 있다.
토큰화 스테이지(3008) 동안, 토큰화 플랫폼(100)(또는 다른 적절한 컴포넌트)은 담보 아이템을 토큰화할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은, 담보 아이템의 설명, 이미지, 비디오, 2D 스캔, 및/또는 3D 스캔 등의, 담보 아이템을 설명하고/하거나 묘사하는 데이터에 기초하여 담보 아이템의 VIRL을 생성할 수 있다. 실시예들에서, 차용자, 보관자, 및/또는 인증자는 VIRL을 생성하는데 이용되는 데이터를 제공할 수 있다. 실시예들에서, 토큰화 플랫폼(100)은 담보 아이템의 VIRL에 기초하여 아이템의 담보 토큰을 생성한다. 일단 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은 토큰을 분산형 원장(2016)에 기입할 수 있고, 초기에 담보 토큰에 대한 소유권을 차용자에게 할당할 수 있다(대출 합의에 도달할 때까지). 일단 담보 아이템이 토큰화되고 나면, 토큰화 플랫폼(100)은, 토큰화 이벤트 및/또는 담보 토큰의 주소를 나타내는 통보를 대출 프로세스 스마트 계약(2022)에 제공할 수 있다. 토큰화 이벤트의 통보 수신시, 대출 프로세스 스마트 계약(2022)은 대출 프로세스를 대출전 청산 스테이지(3010)로 진행시킬 수 있다.
대출전 청산 스테이지(3010) 동안, 대출 프로세스 스마트 계약 인스턴스는 대출전 청산 스마트 계약의 한 인스턴스를 인스턴스화할 수 있다. 실시예들에서, 대출전 청산 스마트 계약 인스턴스는 대출전 청산 요청을 시장(예를 들어, 시장 시스템(102))에 제공할 수 있다. 실시예들에서, 요청은 VIRL(또는 VIRL ID의 표시자 등) 및/또는 담보 아이템을 설명 및/또는 보여주는 기타 문서를 포함할 수 있다. 실시예들에서, 미필적 판매 요청은, 미필적 판매 유형(예를 들어, 경매 또는 정가 판매), 담보 아이템의 위치, 담보 아이템에 대한 추구 가격(정가 판매인 경우), 담보 아이템에 대한 최소 가격(경매인 경우), 미필적 상황의 기간(예를 들어, 차용자가 대출을 확보하고 상환하는데 필요한 시간), 보상 제안(예를 들어, 미리정의된 보상 금액 또는 구매 가격의 백분률, 원하는 대출 금액 또는 상환 금액), 및/또는 기타 등등의 다른 적절한 정보를 포함할 수 있다. 이에 응답하여, 시장은 미필적 판매를 용이화할 수 있으며, 이것은, 한 세트의 미필적 판매 또는 판매 없이 담보 아이템이 판매되는 결과를 초래할 수 있다(예를 들어, 미필적 구매자가 담보 아이템을 정가에 구매하거나 경매에서 낙찰됨). 실시예들에서, 대출전 청산 스마트 계약은 시장으로부터 미필적 판매의 결과를 수신할 수 있다. 일단 미필적 판매가 완료되고 나면, 시장은 대출전 청산 이벤트의 결과를 나타내는 판매 통보를 청산 스마트 계약 인스턴스에 전송할 수 있다. 실시예들에서, 대출전 청산 이벤트의 결과는, 아이템이 판매되었는지, 및 판매된 경우 아이템이 판매된 가격(판매를 호스팅하기 위해 시장에서 취한 수수료를 뺀 가격)을 나타낸다. 이 시점에서, 대출전 청산 스마트 계약은 미필적 판매 통보를 차용자의 차용자 디바이스(2002)에 제공할 수 있고(담보 아이템의 대출전 판매가 발생했다고 가정), 차용자는, a) 대출 프로세스를 진행시키도록 미필적 판매에 동의하거나, b) 미필적 판매를 거부하고 대출 프로세스를 종료하거나(예를 들어, 판매가 경매이고 합의된 청산 가격이 대출을 확보하기에 너무 낮은 경우), 또는 c) 미필적 판매를 완료하기로 결정하고 대출 프로세스를 종료할 수 있다. 차용자가 미필적 판매를 완료하는데 동의하면, 대출전 청산 스마트 계약은, 미필적 구매자에게로의 담보 토큰(2042)의 이전과 구매자에게로의 판매 수익금(예를 들어, 통화/토큰화된 토큰 또는 법정 화폐로 된 구매 금액)에서 시장 수수료를 뺀 값)의 이전을 개시할 수 있다. 차용자가 미필적 판매에 동의하는 경우, 대출전 청산 스마트 계약 인스턴스는, 에스크로 계정의 담보 아이템을 잠금처리할 수 있다. 추가로, 대출전 청산 스마트 계약 인스턴스는, 미필적 구매자로부터의 판매 수익금(또는 그 일부)을 에스크로 계정에 에스크로잉하여 대출이 채무불이행 상태가 될 경우 미필적 구매자가 판매 가격을 지불할 수 있도록 보장할 수 있다. 대출전 청산 스마트 계약 인스턴스는 대출전 청산 이벤트 기록을 분산형 원장에 기입할 수 있고 담보 아이템의 대출전 청산 가격에서 미필적 판매가 완료되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에 발행할 수 있다. 이에 응답하여, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 대출 스테이지(3012)로 진행시킬 수 있다.
대출 스테이지(3012) 동안, 차용자는 대출을 요청할 수 있고/있거나 하나 이상의 대출자와 대출을 협상할 수 있다. 대출자와 차용자가 대출 조건들에 동의했다는 확인을 수신하면, 대출 프로세스 스마트 계약(2022)은 합의된 대출 조건들에 따라 대출 스마트 계약(2034)을 인스턴스화할 수 있다. 일부 실시예에서, 토큰화 플랫폼(100)은, 차용자가 하나 이상의 잠재적 대출자에게 대출을 요청하고/하거나 하나 이상의 대출자와 대출 합의를 협상하는 것을 허용하는 GUI를 차용자에게 제공할 수 있다. 일부 실시예에서, 대출 협상은 토큰화 플랫폼(100) 등의 중앙집중형 서비스를 통하지 않고 온체인으로 처리될 수 있다는 것을 이해할 것이다. 실시예들에서, 차용자는 대출전 청산 판매 가치를 초과하지 않는 대출 금액 및 대출 상환 시간량을 나타내는 제안된 대출 조건을 요청할 수 있다. 이들 실시예들 중 일부에서, 토큰화 플랫폼(100)은 GUI를 통해 잠재적인 대출자들에 프리젠팅되는 대출 요청을 생성할 수 있고, 이에 따라, 대출 요청은, 요청 금액, 대출의 기간, 및 차용자에 의해 제공되는 담보 아이템에 관한 정보(예를 들어, 담보 아이템의 VIRL, 인증 보고, 판매전 청산 보고, 보관 보고, 인증, 평가 및 보관자들이 각자의 작업을 (전술된 바와 같이) 확보했다는 확인 및/또는 기타 등등)를 나타낸다. 실시예들에서, 토큰화 시스템(100)은 대출에 대한 대출 상환 금액 및/또는 이자율을 (예를 들어, 현재 시장 상황에 기초하여) 제안할 수 있다. 대안으로서, 잠재적인 대출자는 GUI를 통해 차용자가 상환해야 하는 이자율 또는 총 상환 금액을 제공할 수 있다. 추가적으로, 잠재적 대출자는, 대출 금액 및/또는 상환 기간 등의, 요청된 대출 조건들 중 하나 이상에 대응할 수 있다. 그 다음, 대출 제안은 GUI를 통해 차용자에게 전달될 수 있으며, 여기서 차용자는 차용자 디바이스(2002)를 통해 대출 제안을 볼 수 있다. 이에 응답하여, 차용자는 대출 제안을 수락하거나, 대출 제안을 거부하거나, 반대 제안을 제공할 수 있다. 당사자는 합의에 도달하거나 한쪽 또는 양쪽 당사자가 대출 제안을 거부할 때까지 이러한 방식을 반복할 수 있다. 일단 대출에 도달하고 나면, 당사자들은 대출 합의를 실행할 수 있고, 토큰화 플랫폼(100)은 대출 합의가 차용자와 대출자에 의해 동의되었음을 나타내는 통보를 대출 프로세스 스마트 계약 인스턴스에게 제공할 수 있다. 실시예들에서, 통보는 대출 합의의 조건들을 포함하는 대출 합의의 상세사항을 포함할 수 있다. 이에 응답하여, 대출 프로세스 스마트 계약 인스턴스는 대출 상환 워크플로우를 실행하는 대출 스마트 계약 인스턴스를 인스턴스화할 수 있다. 일단 대출 합의가 실행되고 나면, 대출 스마트 계약은 에스크로 계정에 담보 토큰을 잠금처리할 수 있으며, 대출자의 계정으로부터 차용자의 계정으로의 자금 이전을 용이화할 수 있다. 실시예들에서, 대출 합의, 임의의 제안/반대 제안의 기록들, 담보 토큰의 에스크로잉 및 차용자에게로의 자금 이전과 관련된 기록들은 분산형 원장(2016)에 기입될 수 있다. 일단 대출 프로세스 스마트 계약 인스턴스가, 담보 토큰이 잠금처리되었고 자금이 이전되었다는 통보를 수신하고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스를 상환 스테이지(3014)로 진행시킬 수 있다.
상환 스테이지(3014) 동안, 대출 스마트 계약 인스턴스는, 대출 일정에 따라 차용자에 의해 대출자(또는 대출자에게 지불을 분배하는 계정)에게 지불이 이루어졌는지 및 대출이 채무불이행 상태에 있지 않음을 보장하기 위해 차용자 지불 이력을 모니터링할 수 있다. 대출 상환 스테이지 동안, 차용자는 지불을 송금할 수 있다. 지불이 이루어질 때마다, 대출 프로세스 스마트 계약 인스턴스는 지불이 이루어졌음을 나타내는 지불 통보 및 지불 금액을 수신할 수 있다. 그 다음, 대출 스마트 계약 인스턴스는 대출이 전액 상환되었는지를 결정할 수 있다. 대출이 전액 지불되지 않은 경우, 대출 스마트 계약 인스턴스는 대출 상환 금액을 조정할 수 있고, 인증자들 및/또는 보관자로부터의 일부 위험부담성 출자된 자금을 반환하여 새로운 대출 상환 금액을 반영하는 등의, 추가적인 동작들을 수행할 수 있다. 대출 스마트 계약 인스턴스가 대출 상환 금액이 전액 지불되었다고 결정하면, 대출 스마트 계약 인스턴스는 대출이 전액 지불되었음을 나타내는 상환 통보를 대출 프로세스 스마트 계약 인스턴스에 전송할 수 있고 대출 프로세스를 대출후 스테이지(2716)로 진행시킬 수 있다. 실시예들에서, 상환 통보는, 지불들이 이루어졌음을 나타내는 지불 이벤트 기록들의 해시 값들, 및 지불들의 금액 및/또는 분산형 원장(2016) 상의 지불 기록들의 주소들을 포함할 수 있다. 반대로, 대출 스마트 계약 인스턴스가 차용자가 채무불이행이라고 결정하면, 대출 스마트 계약은 대출 조건들에 따라 대출이 채무불이행 상태임을 나타내는 채무불이행 통보를 대출 프로세스 스마트 계약에 전송할 수 있다. 실시예들에서, 채무불이행 통보는, 어떤 지불들이 누락되었는지를 나타내는 채무불이행 이벤트 기록의 해시 값들, 및 대출에 관한 나머지 잔액 및/또는 분산형 원장(2016) 상의 채무불이행 이벤트 기록의 주소들을 포함할 수 있다. 채무불이행 통보를 수신하는 것에 응답하여, 대출 스마트 계약 인스턴스는 채무불이행 통보를 대출 프로세스 스마트 계약 인스턴스 및/또는 대출전 청산 이벤트 스마트 계약에 제공하여 미필적 구매자에게로의 담보 토큰(2042)의 이전을 개시할 수 있다. 채무불이행 상태가 결정되면, 대출 프로세스는 대출후 스테이지(3016)로 진행할 수 있다.
대출후 스테이지(3016) 동안, 담보 토큰(2042)은, 대출이 전액 지불되었거나 담보 토큰(2042)이 소유 미필적 상황에 따라 미필적 구매자에게 이전된 경우, 소유자에게 반환된다. 대출이 전액 상환되었다는 상환 통보를 수신하는 것에 응답하여, 대출 스마트 계약 인스턴스는 에스크로 계정으로부터 차용자의 계정으로의 담보 토큰의 이전을 개시할 수 있고, 차용자는 담보 아이템의 소유를 획득하기 위해 담보 토큰을 상환할 수 있다. 일단 대출이 성공적으로 상환되고 나면, 대출 프로세스 스마트 계약 인스턴스는, 인증 스마트 계약, 대출전 청산 스마트 계약, 및 보관 계약에 나와 있는 조건들에 따라 (예를 들어, 대출자에게 상환된 자금으로부터) 인증자, 보상 미필적 상황에 따른 미필적 구매자, 및 보관자의 계정들로의 보상 지급을 개시할 수 있다.
채무불이행 상태의 경우, 대출 계약 인스턴스는 채무불이행 통보를 대출 프로세스 스마트 계약 및 대출전 청산 스마트 계약에 제공할 수 있다. 채무불이행 상태를 수신하는 것에 응답하여, 대출전 청산 스마트 계약은 대출전 청산 이벤트 동안 미필적 구매자로부터 에스크로잉된 자금을 잠금해제할 수 있다. 대출 프로세스 스마트 계약 인스턴스는, 대출전 청산 이벤트의 수익금(예를 들어, 미필적 구매자로부터의 잠금해제된 자금뿐만 아니라 미필적 구매자에 의한 소유된 임의의 나머지 잔액)으로부터, 대출 상환 금액에 관한 미결제 잔액을 대출자(또는 대출이 2차 대출자에게 판매된 경우 2차 대출자)에게 분배할 수 있다. 미필적 구매자가 청산전 판매로부터 어떠한 미결제 잔액도 갖고 있지 않음을 확인하면, 대출전 청산 스마트 계약 인스턴스는 에스크로로부터 담보 토큰(2042)을 잠금해제하고, 담보 토큰(2042)을 미필적 구매자의 계정으로 이전할 수 있으며, 미필적 구매자는, 그 다음, 담보 토큰을 상환하여 담보 아이템의 소유권을 취할 수 있다. 추가로, 대출 프로세스 스마트 계약 인스턴스는 인증 스마트 계약 및 보관 계약에 나와 있는 조건들에 따라 대출전 청산 이벤트의 수익금으로부터 인증자들과 보관자의 계정들로의 보상 지급을 개시할 수 있다. 잔액이 남아 있는 한도까지, 나머지는 차용자의 계좌로 입금될 수 있다.
일단 대출 프로세스가 완료되고 나면, 대출 프로세스 스마트 계약 인스턴스는 대출 프로세스가 완료되었음을 토큰화 플랫폼(100)에게 통보할 수 있고, 토큰화 플랫폼(100)은 완료된 대출 프로세스에 기초하여 분석 프로세스를 실행할 수 있다. 일부 실시예에서, 대출 프로세스의 결과는, 인증자들, 보관자, 미필적 구매자, 대출자, 및/또는 차용자 중 하나 이상의 등급을 업데이트하는데 이용될 수 있다.
전술한 내용은 탈집중형 대출 프로세스 워크플로우(3000)의 한 예이며 대안적인 워크플로우들이 실행될 수 있다는 것을 이해할 것이다. 또한, 탈집중형 대출 프로세스 워크플로우(3000)는, 명시적으로 논의되지 않은 추가적인 또는 대안적인 단계들을 포함할 수 있다. 대출 프로세스 워크플로우(3000)의 스테이지들의 일부의 순서는 소정의 효율성을 달성하기 위해 변경될 수 있다는 점에 유의한다. 예를 들어, 담보 아이템이 배송하기 어렵고/어렵거나 부패하기 쉬운 경우, 인증 스테이지 이전에 보관 스테이지 및 토큰화 스테이지가 수행될 수 있다.
본 개시내용의 단지 몇 가지 실시예들이 도시되고 설명되었지만, 이하의 청구항들에 기술된 본 개시내용의 사상 및 범위를 벗어나지 않고 많은 변경 및 수정이 이루어질 수 있다는 것이 본 기술분야의 통상의 기술자에게 명백할 것이다. 국내 출원이든 외국 출원이든, 모든 특허 출원 및 특허와 여기서 참조되는 기타의 모든 간행물은 법이 허용하는 한도 내에서 그 전체 내용이 본 명세서에 통합된다.
본 명세서에서 설명된 방법 및 시스템은, 부분적으로 또는 전체적으로, 컴퓨터 소프트웨어, 프로그램 코드 및/또는 명령어들을 프로세서 상에서 실행하는 머신을 통해 배치될 수 있다. 본 개시내용은, 머신 상의 방법으로서, 머신의 일부로서의 또는 머신과 관련한 시스템 또는 장치로서, 또는 머신들 중 하나 이상에서 실행되는 컴퓨터 판독가능한 매체에 구현된 컴퓨터 프로그램 제품으로서 구현될 수 있다. 실시예들에서, 프로세서는, 서버, 클라우드 서버, 클라이언트, 네트워크 인프라스트럭쳐, 모바일 컴퓨팅 플랫폼, 정지 컴퓨팅 플랫폼, 또는 기타의 컴퓨팅 플랫폼의 일부일 수 있다. 프로세서는, 중앙 처리 유닛(CPU), 일반 처리 유닛(GPU), 로직 보드, 칩(예를 들어, 그래픽 칩, 비디오 처리 칩, 데이터 압축 칩 등), 칩셋, 제어기, 시스템 온 칩(예를 들어, RF 시스템 온 칩, AI 시스템 온 칩, 비디오 처리 시스템 온 칩 등), 집적 회로, 주문형 집적 회로(ASIC; Application Specific Integrated Circuit), 필드 프로그래머블 게이트 어레이(FPGA; Field Programmable Gate Array), 근사 컴퓨팅 프로세서, 양자 컴퓨팅 프로세서, 병렬 컴퓨팅 프로세서, 신경망 프로세서, 또는 다른 유형의 프로세서를 포함한, 프로그램 명령어들, 코드들, 2진 명령어들 등을 실행할 수 있는 임의 종류의 계산 또는 처리 디바이스일 수 있다. 프로세서는, 저장된 프로그램 코드 또는 프로그램 명령어들의 실행을 직접적으로 또는 간접적으로 용이화할 수 있는, 신호 프로세서, 디지털 프로세서, 데이터 프로세서, 임베디드 프로세서, 마이크로프로세서, 또는 코프로세서(수학 코프로세서, 그래픽 코프로세서, 통신 코프로세서, 비디오 코프로세서, AI 코프로세서 등) 등의 임의의 변형일 수 있거나 이를 포함할 수 있다. 또한, 프로세서는, 복수의 프로그램, 스레드, 및 코드의 실행을 가능케할 수 있다. 스레드들은 프로세서의 성능을 향상시키고 애플리케이션의 동시 동작을 용이화하기 위해 동시에 실행될 수 있다. 구현 예로서, 본 명세서에서 설명된 방법, 프로그램 코드, 프로그램 명령어들 등은 하나 이상의 스레드로 구현될 수 있다. 스레드는 연관된 우선순위들을 할당받았을 수 있는 다른 스레드들을 생성할 수 있다; 프로세서는 우선순위 또는 프로그램 코드에서 제공된 명령어들에 기초한 기타 임의의 순서에 기초하여 이들 스레드들을 실행할 수 있다. 프로세서, 또는 이를 이용하는 임의의 머신은, 여기서 및 다른 곳에서 설명된 방법, 코드, 명령어 및 프로그램을 저장하는 비일시적인 메모리를 포함할 수 있다. 프로세서는, 여기서 및 다른 곳에서 설명된 방법, 코드 및 명령어를 저장할 수 있는 비일시적인 저장 매체에 인터페이스를 통해 액세스할 수 있다. 방법들, 프로그램들, 코드들, 프로그램 명령어들, 또는 컴퓨팅 디바이스 또는 처리 디바이스에 의해 실행될 수 있는 기타 유형의 명령어들을 저장하기 위한 프로세서와 연관된 저장 매체는, CD-ROM, DVD, 메모리, 하드 디스크, 플래시 드라이브, RAM, ROM, 캐시, 네트워크-부착형 스토리지, 서버-기반의 스토리지 등 중에서 하나 이상을 포함할 수 있지만, 이것으로 제한되지 않을 수 있다.
프로세서는, 멀티프로세서의 속도 및 성능을 향상시킬 수 있는 하나 이상의 코어를 포함할 수 있다. 실시예들에서, 프로세스는 2개 이상의 독립된 (때때로 다이라고 불리는) 코어를 결합하는 듀얼 코어 프로세서, 쿼드 코어 프로세서, 다른 칩-레벨 멀티프로세서 등일 수 있다.
여기서 설명된 방법 및 시스템은, 부분적으로 또는 전체적으로, 서버, 클라이언트, 방화벽, 게이트웨이, 허브, 라우터, 스위치, 서비스로서의 인프라스트럭쳐, 서비스로서의 플랫폼, 또는 기타의 이러한 컴퓨터 및/또는 네트워킹 하드웨어 또는 시스템 상에서 컴퓨터 소프트웨어를 실행하는 머신을 통해 배치될 수 있다. 소프트웨어는, 파일 서버, 프린트 서버, 도메인 서버, 인터넷 서버, 인트라넷 서버, 클라우드 서버, 서비스로서의 인프라스트럭쳐 서버, 서비스로서의 플랫폼 서버, 웹 서버, 및 보조 서버, 호스트 서버, 분산형 서버, 장애조치 서버, 백업 서버, 서버 팜 등과 같은 기타의 변형들을 포함할 수 있는 서버와 연관될 수 있다. 서버는, 메모리, 프로세서, 컴퓨터 판독가능한 매체, 저장 매체, 포트(물리적 및 가상적), 통신 디바이스, 및 유선 또는 무선 매체 등을 통해 다른 서버, 클라이언트, 머신, 및 디바이스에 액세스할 수 있는 인터페이스 중 하나 이상을 포함할 수 있다. 여기서 및 다른 곳에서 설명된 방법, 프로그램, 또는 코드는, 서버에 의해 실행될 수 있다. 또한, 본 출원에서 설명된 방법들의 실행에 요구되는 기타의 디바이스는 서버와 연관된 인프라스트럭쳐의 일부로서 간주될 수 있다.
서버는, 제한없이, 클라이언트, 다른 서버, 프린터, 데이터베이스 서버, 프린트 서버, 파일 서버, 통신 서버, 분산형 서버, 소셜 네트워크 등을 포함한 다른 디바이스들에 대한 인터페이스를 제공할 수 있다. 또한, 이러한 결합 및/또는 접속은 네트워크를 통한 프로그램들의 원격 실행을 용이화할 수 있다. 이들 디바이스 중 일부 또는 전부의 네트워킹은, 본 개시내용의 범위를 벗어나지 않으면서 하나 이상의 위치에서 프로그램 또는 방법의 병렬 처리를 용이화할 수 있다. 또한, 인터페이스를 통해 서버에 부착된 임의의 디바이스는, 방법, 프로그램, 코드 및/또는 명령어를 저장할 수 있는 적어도 하나의 저장 매체를 포함할 수 있다. 중앙 저장소는 상이한 디바이스들 상에서 실행될 프로그램 명령어를 제공할 수 있다. 이 구현에서, 원격 저장소는, 프로그램 코드, 명령어, 및 프로그램을 위한 저장 매체로서 작용할 수 있다.
소프트웨어 프로그램은, 파일 클라이언트, 프린트 클라이언트, 도메인 클라이언트, 인터넷 클라이언트, 인트라넷 클라이언트, 및 보조 클라이언트, 호스트 클라이언트, 분산형 클라이언트 등의 다른 변형예를 포함할 수 있는 클라이언트와 연관될 수 있다. 클라이언트는, 메모리, 프로세서, 컴퓨터 판독가능한 일시적 및/또는 비일시적 매체, 저장 매체, 포트(물리적 및 가상적), 통신 디바이스, 및 유선 또는 무선 매체 등을 통해 다른 클라이언트, 서버, 머신, 및 디바이스에 액세스할 수 있는 인터페이스 중 하나 이상을 포함할 수 있다. 여기서 및 다른 곳에서 설명된 방법, 프로그램, 또는 코드는, 클라이언트에 의해 실행될 수 있다. 또한, 본 출원에서 설명된 방법들의 실행에 요구되는 기타의 디바이스는 클라이언트와 연관된 인프라스트럭쳐의 일부로서 간주될 수 있다.
클라이언트는, 제한없이, 서버, 다른 클라이언트, 프린터, 데이터베이스 서버, 프린트 서버, 파일 서버, 통신 서버, 분산형 서버 등을 포함한 다른 디바이스들에 대한 인터페이스를 제공할 수 있다. 또한, 이러한 결합 및/또는 접속은 네트워크를 통한 프로그램들의 원격 실행을 용이화할 수 있다. 이들 디바이스 중 일부 또는 전부의 네트워킹은, 본 개시내용의 범위를 벗어나지 않으면서 하나 이상의 위치에서 프로그램 또는 방법의 병렬 처리를 용이화할 수 있다. 또한, 인터페이스를 통해 클라이언트에 부착된 임의의 디바이스는, 방법, 프로그램, 애플리케이션, 코드 및/또는 명령어를 저장할 수 있는 적어도 하나의 저장 매체를 포함할 수 있다. 중앙 저장소는 상이한 디바이스들 상에서 실행될 프로그램 명령어를 제공할 수 있다. 이 구현에서, 원격 저장소는, 프로그램 코드, 명령어, 및 프로그램을 위한 저장 매체로서 작용할 수 있다.
여기서 설명된 방법들 및 시스템들은 부분적으로 또는 전체적으로 네트워크 인프라스트럭쳐를 통해 배치될 수 있다. 네트워크 인프라스트럭쳐는, 본 기술분야에 공지된 컴퓨팅 디바이스, 서버, 라우터, 허브, 방화벽, 클라이언트, 개인용 컴퓨터, 통신 디바이스, 라우팅 디바이스 및 기타의 능동 및 수동 디바이스, 모듈 및/또는 컴포넌트 등의 요소들을 포함할 수 있다. 네트워크 인프라스트럭쳐와 연관된 컴퓨팅 및/또는 비컴퓨팅 디바이스(들) 다른 컴포넌트들과는 별도로, 플래시 메모리, 버퍼, 스택, RAM, ROM 등의 저장 매체를 포함할 수 있다. 여기서 및 다른 곳에서 설명된 프로세스, 방법, 프로그램 코드, 명령어는, 네트워크 인프라스트럭쳐 요소들 중 하나 이상에 의해 실행될 수 있다. 여기서 설명된 방법 및 시스템은, 서비스로서의 소프트웨어(SaaS), 서비스로서의 플랫폼("PaaS"), 및/또는 서비스로서의 인프라스트럭쳐("IaaS")의 피처들을 포함한 것들을 비롯한, 임의 종류의 사설, 커뮤니티 또는 하이브리드 클라우드 컴퓨팅 네트워크 또는 클라우드 컴퓨팅 환경에서 이용하기에 적합화될 수 있다.
여기서 및 다른 곳에서 설명된 방법들, 프로그램 코드들, 및 명령어들은, 복수의 셀을 갖는 셀룰러 네트워크 상에서 구현될 수 있다. 셀룰러 네트워크는, 주파수 분할 다중 액세스(FDMA) 네트워크 또는 코드 분할 다중 액세스(CDMA) 네트워크일 수 있다. 셀룰러 네트워크는, 모바일 디바이스, 셀 사이트, 기지국, 리피터, 안테나, 타워 등을 포함할 수 있다. 셀 네트워크는, GSM, GPRS, 3G, 4G, 5G, LTE, EVDO, 메시 또는 기타의 네트워크 유형들일 수 있다.
여기서 및 다른 곳에서 설명된 방법, 프로그램 코드, 및 명령어는 모바일 디바이스 상에서 또는 모바일 디바이스를 통해 구현될 수 있다. 모바일 디바이스는, 네비게이션 디바이스, 셀 전화, 모바일 전화, 모바일 개인 휴대 정보 단말기, 랩탑, 팜탑, 넷북, 페이저, 전자 서적 리더, 음악 재생기 등을 포함할 수 있다. 이들 디바이스는, 다른 컴포넌트들과는 별도로, 플래시 메모리, 버퍼, RAM, ROM 등의 저장 매체 및 하나 이상의 컴퓨팅 디바이스를 포함할 수 있다. 모바일 디바이스와 연관된 컴퓨팅 디바이스는, 저장된 프로그램 코드, 방법 및 명령어를 실행하도록 인에이블될 수 있다. 대안으로서, 모바일 디바이스는 다른 디바이스들과 협력하여 명령어들을 실행하도록 구성될 수 있다. 모바일 디바이스는, 서버와 인터페이스되고 프로그램 코드를 실행하도록 구성된 기지국과 통신할 수 있다. 모바일 디바이스는, 피어-투-피어 네트워크, 메시 네트워크, 또는 다른 통신 네트워크 상에서 통신할 수 있다. 프로그램 코드는 서버와 연관된 저장 매체 상에 저장될 수 있고 서버 내에 임베딩된 컴퓨팅 디바이스에 의해 실행될 수 있다. 기지국은 컴퓨팅 디바이스 및 저장 매체를 포함할 수 있다. 저장 디바이스는 기지국과 연관된 컴퓨팅 디바이스에 의해 실행되는 프로그램 코드 및 명령어를 저장할 수 있다.
컴퓨터 소프트웨어, 프로그램 코드, 및/또는 명령어는 : 컴퓨터 컴포넌트, 디바이스, 및 소정 기간 동안 컴퓨팅에 이용되는 디지털 데이터를 보유하는 기록 매체; 랜덤 액세스 메모리("RAM")라고 알려진 반도체 스토리지; 광 디스크, 하드 디스크, 테이프, 드럼, 카드 및 기타 유형 등의 자기 스토리지 형태 등의 전형적으로는 영구 저장을 위한 대용량 스토리지; 프로세서 레지스터, 캐시 메모리, 휘발성 메모리, 비휘발성 메모리; CD, DVD 등의 광학 스토리지; 플래시 메모리(예를 들어, USB 스틱 또는 키), 플로피 디스크, 자기 테이프, 종이 테이프, 펀치 카드, 독립형 RAM 디스크, ZIP 드라이브, 착탈식 대용량 스토리지, 오프라인 등의 착탈식 매체; 동적 메모리, 정적 메모리, 판독/기입 스토리지, 가변 스토리지, 판독 전용, 랜덤 액세스, 순차적 액세스, 위치 어드레싱형, 파일 어드레싱형, 콘텐츠 어드레싱형, 네트워크 접속 스토리지, 스토리지 영역 네트워크, 바코드, 자기 잉크, 네트워크-부착형 스토리지, 네트워크 스토리지, NVME-액세스가능형 스토리지, PCIE 접속형 스토리지, 분산형 스토리지 등의 기타의 컴퓨터 메모리를 포함할 수 있는, 머신 판독가능한 매체 상에 저장되고/되거나 매체 상에서 액세스될 수 있다.
본 명세서에서 설명된 방법 및 시스템은 물리적 및/또는 무형의 항목을 하나의 상태로부터 또 다른 상태로 변환할 수 있다. 본 명세서에서 설명된 방법 및 시스템은 또한, 물리적 및/또는 무형의 항목을 나타내는 데이터를 하나의 상태로부터 또 다른 상태로 변환할 수 있다.
도면 전체에 걸친 플로차트들 및 블록도들을 포함한, 본 명세서에서 설명되고 도시된 요소들은 요소들 사이의 논리적 경계를 암시한다. 그러나, 소프트웨어 또는 하드웨어 엔지니어링 실무에 따라, 도시된 요소들 및 그 기능들은, 모놀리식 소프트웨어 구조로서, 독립형 소프트웨어 모듈로서, 또는 외부 루틴, 코드, 서비스 등을 이용하는 모듈로서, 또는 이들의 임의의 조합으로 구현될 수 있는 저장된 프로그램 명령어들을 실행할 수 있는 프로세서를 갖는 컴퓨터 실행가능한 코드를 통해 머신들 상에서 구현될 수 있고, 이러한 모든 구현은 본 개시내용의 범위 내에 있을 수 있다. 이러한 머신의 예로서는, 개인용 정보 단말기, 랩탑, 개인용 컴퓨터, 모바일 전화, 기타 핸드헬드 컴퓨팅 디바이스, 의료 장비, 유선 또는 무선 통신 디바이스, 트랜스듀서, 칩, 계산기, 위성, 태블릿 PC, 전자 서적, 가제트, 전자 디바이스, 디바이스, 인공 지능, 컴퓨팅 디바이스, 네트워킹 장비, 서버, 라우터 등이 포함될 수 있지만, 이것으로 제한되는 것은 아니다. 또한, 플로차트들 및 블록도들 또는 기타 임의의 논리적 컴포넌트에 도시된 요소들은 프로그램 명령어들을 실행할 수 있는 머신 상에서 구현될 수 있다. 따라서, 전술된 도면 및 설명은 개시된 시스템의 기능적 양태를 나타내지만, 이들 기능적 양태를 구현하기 위한 소프트웨어의 특정한 구성은 문맥으로부터 명시적으로 언급되거나 기타의 방식으로 명백하지 않는 한 이들 설명들로부터 추론되어서는 안된다. 유사하게, 위에서 식별되고 설명된 다양한 단계들은 달라질 수 있고, 단계들의 순서는 본 명세서에서 개시된 기술들의 특정한 응용에 적합하게 개조될 수 있다는 것을 이해할 것이다. 이러한 모든 변형 및 수정은 본 개시내용의 범위 내에 속한다. 따라서, 다양한 단계들의 순서의 도시 및/또는 설명은, 특정한 응용에 의해 요구되지 않는 한, 또는 문맥으로부터 명시적으로 진술되거나 기타의 방식으로 명확하지 않은 한, 이들 단계들에 대한 특정한 실행 순서를 요구하는 것으로 이해되어서는 안된다.
전술된 방법 및/또는 프로세스, 및 이와 연관된 단계들은, 특정한 응용에 적합한 하드웨어, 소프트웨어, 또는 하드웨어 및 소프트웨어의 임의의 조합으로 실현될 수 있다. 하드웨어는, 범용 컴퓨터 및/또는 전용 컴퓨팅 디바이스 또는 특정한 컴퓨팅 디바이스 또는 특정한 컴퓨팅 디바이스의 특정한 양태 또는 컴포넌트를 포함할 수 있다. 프로세스는, 내부 및/또는 외부 메모리와 함께, 하나 이상의 마이크로프로세서, 마이크로제어기, 임베디드 마이크로제어기, 프로그램가능한 디지털 신호 프로세서 또는 기타의 프로그램가능한 디바이스에서 실현될 수 있다. 프로세스는, 또한, 또는 대신에, 주문형 집적 회로, 프로그램가능한 게이트 어레이, 프로그램가능한 어레이 로직, 또는 전자 신호를 처리하도록 구성될 수 있는 기타 임의의 디바이스 또는 디바이스들의 조합으로 구현될 수 있다. 또한, 하나 이상의 프로세스가 머신-판독가능한 매체 상에서 실행될 수 있는 컴퓨터 실행가능한 코드로서 실현될 수 있다는 것을 이해할 것이다.
컴퓨터 실행가능한 코드는, C 등의 구조화된 프로그래밍 언어, C++ 등의 객체 지향 프로그래밍 언어, 또는 상기 디바이스들뿐만 아니라, 프로세서들, 프로세서 아키텍쳐들의 이종 조합, 또는 상이한 하드웨어 및 소프트웨어의 조합, 또는 프로그램 명령어를 실행할 수 있는 기타 임의의 머신 중 하나 상에서 실행되도록 저장, 컴파일, 또는 인터프리트될 수 있는 (어셈블리어, 하드웨어 기술 언어, 및 데이터베이스 프로그래밍 언어 및 기술들을 포함한) 기타 임의의 하이-레벨 또는 로우-레벨 프로그래밍 언어를 이용하여 생성될 수 있다. 컴퓨터 소프트웨어는, 가상화, 가상 머신들, 컨테이너들, 도크 설비들, 포테이너(portainer)들 및 기타의 능력들을 채용할 수 있다.
따라서, 한 양태에서, 전술된 방법들 및 이들의 조합은, 하나 이상의 컴퓨팅 디바이스에서 실행될 때, 그 단계들을 수행하는 컴퓨터 실행가능한 코드로 구현될 수 있다. 또 다른 양태에서, 방법들은 그 단계들을 수행하는 시스템들에서 구현될 수 있고, 다수의 방식으로 디바이스들에 걸쳐 분산될 수 있거나, 기능들 모두는 전용의 독립형 디바이스 또는 기타의 하드웨어에 통합될 수 있다. 또 다른 양태에서, 전술된 프로세스와 연관된 단계들을 수행하기 위한 수단은 전술된 하드웨어 및/또는 소프트웨어 중 임의의 것을 포함할 수 있다. 이러한 모든 치환들 및 조합들은 본 개시내용의 범위 내에 속하는 것으로 의도된다.
본 개시내용이 도시되고 상세한 설명된 바람직한 실시예들과 관련하여 개시되었지만, 본 기술분야의 통상의 기술자에게는 다양한 수정이 및 개선이 용이하게 명백해질 것이다. 따라서, 본 개시내용의 사상 및 범위는 전술된 예들에 의해 제한되지 않으며, 법률에 의해 허용가능한 가장 넓은 의미로 이해되어야 한다.
본 개시내용을 설명하는 정황에서(특히, 이하의 청구항들의 정황에서) 사용되는 관사("a", "an" 및 "the") 및 유사한 지시어는, 본 명세서에서, 달리 표시하거나 문맥상 명확하게 상충되지 않는 한, 단수 및 복수 양쪽 모두를 포괄하는 것으로 해석되어야 한다. 용어 "포함하는", "갖는", "내포하는", 및 "담고 있는"은, 달리 언급되지 않는 한 제약을 두지 않는 용어(즉, "포함한 그러나 이것으로 제한되지 않는"을 의미함)로 해석되어야 한다. 본 명세서에서 값들의 범위를 열거한 것은, 본 명세서에서 달리 표시되지 않는 한, 그 범위 내에 속하는 각각의 별개의 값을 개별적으로 언급하는 약식 방법으로서 역할하며, 각각의 별개의 값은 본 명세서에서 개별적으로 나열된 것처럼 본 명세서에 통합된다. 본 명세서에서 설명된 모든 방법은 본 명세서에서 달리 표시되지 않는 한 또는 문맥상 명확하게 상충되지 않는 한 임의의 적절한 순서로 수행될 수 있다. 본 개시내용에서 제공된 임의의 예 및 모든 예들, 또는 예시적인 용어(예를 들어, "~ 등의")의 사용은, 단지 본 개시내용을 더 명료하게 하기 위한 것일 뿐이며, 달리 청구되지 않는 한 본 명세서의 범위에 어떠한 제한을 두는 것은 아니다. 용어 "세트"는 단일 멤버를 갖는 세트를 포함할 수 있다. 본 명세서의 어떠한 용어도 본 개시내용의 실시에 필수적인 임의의 청구되지 않은 요소를 가리키는 것으로 해석되어서는 안 된다.
전술된 설명은 본 기술분야의 통상의 기술자가 현재 최상의 모드인 것으로 간주되는 것을 제작하고 이용할 수 있게 하지만, 본 기술분야의 통상의 기술자라면, 특정한 실시예, 방법, 및 예들의 변형, 조합 및 균등물의 존재를 이해하고 인식할 것이다. 따라서, 본 개시내용은, 전술된 실시예, 방법 및 예에 의해 제한되지 않으며, 본 개시내용의 범위 및 사상 내의 모든 실시예 및 방법에 의해 제한되어야 한다.
본 명세서에서 참조된 모든 문서는, 마치 그 전체 내용이 여기에 개시된 것처럼 참조에 의해 본 명세서에 통합된다.

Claims (70)

  1. 방법으로서,
    하나 이상의 처리 디바이스에 의해, 대출 프로세스를 개시하라는 요청 ―상기 요청은 차용자의 담보 아이템을 표시함― 을 사용자 디바이스로부터 수신하는 단계;
    상기 하나 이상의 처리 디바이스에 의해, 담보 아이템의 가상 표현을 생성하는 단계, ―상기 가상 표현은, 상기 담보 아이템의 설명, 및 담보 아이템의 적어도 일부를 각각 묘사하는 하나 이상의 미디어 콘텐츠 중 적어도 하나를 포함함―;
    상기 하나 이상의 처리 디바이스에 의해, 상기 담보 아이템에 대응하는 담보 토큰을 생성하는 단계, ―상기 담보 토큰은 한 세트의 노드 디바이스들에 걸쳐 분산된 분산형 원장에 저장된 디지털 토큰임―; 및
    상기 하나 이상의 처리 디바이스에 의해, 대출 프로세스 워크플로우에 따라 대출 프로세스를 관리하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 대출 프로세스 스마트 계약 인스턴스를 인스턴스화하는 단계, ―상기 대출 프로세스 스마트 계약 인스턴스는 상기 분산형 원장을 저장하는 상기 노드 디바이스 세트에 의해 적어도 부분적으로 실행됨―
    를 포함하고, 상기 대출 프로세스 스마트 계약 인스턴스는,
    대출자와 상기 차용자에 의해 합의된 대출의 하나 이상의 대출 조건 파라미터를 나타내는 대출 합의 통보를 수신하고 상기 하나 이상의 대출 조건 파라미터에 기초하여 대출의 상환을 관리하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 대출 스마트 계약을 인스턴스화하도록 구성되며,
    상기 담보 토큰은, 상기 대출 스마트 계약 인스턴스가 상기 담보의 에스크로잉에 적용되는 상기 대출의 파라미터와 관련된 상기 대출의 상태 변경을 결정할 때까지, 상기 분산형 원장에 저장된 에스크로 계정에서 잠금처리되는, 방법.
  2. 제1항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 상기 담보 아이템을 인증하기 위해 인증자에 의해 수행되는 인증 작업을 관리하고 평가 작업이 완료되었음을 확정할 때 인증 통보를 발행하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 인증 스마트 계약 인스턴스를 인스턴스화하도록 구성된, 방법
  3. 제2항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스는 상기 대출 프로세스 워크플로우에 따라 상기 인증 스마트 계약 인스턴스를 인스턴스화하는, 방법.
  4. 제3항에 있어서, 상기 대출 프로세스 워크플로우는 상기 분산형 원장에 저장된 시스템-레벨 거버넌스(system-level governance) 문서에서 정의되며, 상기 시스템-레벨 거버넌스는 상기 인증 작업을 개시하기 위한 조건을 정의하는, 방법.
  5. 제2항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스는 상기 차용자가 상기 대출 프로세스를 개시할 것을 요청했음을 나타내는 요청 통보를 수신하는 것에 응답하여 상기 인증 스마트 계약 인스턴스를 인스턴스화하는, 방법.
  6. 제2항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 상기 인증자의 인증자 디바이스로부터 인증 보고를 수신하도록 구성되고, 상기 인증 보고는, 상기 인증자가 담보 아이템을 진품으로 간주했는지의 여부를 포함한, 인증 상태를 나타내는 상기 인증자의 인증 의견을 포함하는, 방법.
  7. 제6항에 있어서, 상기 인증 보고는 상기 인증 의견을 뒷받침하기 위해 상기 인증자에 의해 제공된 지원 문서를 더 포함하는, 방법.
  8. 제7항에 있어서, 상기 인증 보고는 하나 이상의 각각의 2차 인증자에 의해 발행된 하나 이상의 확인(verification)을 더 포함하고, 각각의 확인은 각각의 2차 인증자가 상기 인증 의견을 확정했음을 나타내는, 방법.
  9. 제6항에 있어서, 상기 인증 보고는, 상기 인증 작업의 수행과 연관된 한 세트의 규칙들 및 규정들을 정의하는 인증 스테이지-레벨 거버넌스에 따라 정의되는 양식 템플릿(form template)으로부터 생성되는, 방법.
  10. 제9항에 있어서, 상기 인증 스테이지-레벨 거버넌스는 인증 작업 워크플로우를 정의하고, 상기 인증 작업 워크플로우는, 상기 인증 작업을 완료하고 상기 대출 프로세스가 준수하는 상기 대출 프로세스 워크플로우의 다음 스테이지를 트리거하기 위해 충족되어야 하는 하나 이상의 조건을 포함하는, 방법.
  11. 제10항에 있어서, 상기 인증 스테이지-레벨 거버넌스는 상기 인증자가 길드 멤버인 인증 길드에 의해 적어도 부분적으로 정의되는, 방법.
  12. 제11항에 있어서, 상기 인증 길드는 복수의 상이한 전문화된 인증 길드를 포함하고, 각각의 전문화된 인증 길드는 각각의 유형의 담보 아이템을 인증하는 것을 전문으로 하는, 방법.
  13. 제12항에 있어서, 상기 복수의 상이한 전문화된 인증 길드는 : 시계 인증을 전문으로 하는 시계 인증 길드, 신발 인증을 전문으로 하는 신발 인증 길드, 핸드백 인증을 전문으로 하는 핸드백 인증 길드, 예술 작품 인증을 전문으로 하는 예술품 인증 길드, 스포츠 기념품 인증을 전문으로 하는 스포츠 기념품 인증 길드, 소장용 장난감 인증을 전문으로 하는 장난감 인증 길드, 보석 인증을 전문으로 하는 보석 인증 길드, 디자이너 의류 인증을 전문으로 하는 의류 인증 길드, 악기 전문 인증을 전문으로 하는 악기 인증 길드, 희귀 또는 소장용 음반 인증을 전문으로 하는 음반 인증 길드, 와인 단위의 전문 인증을 전문으로 하는 와인 인증 길드, 위스키 단위의 인증을 전문으로 하는 위스키 인증 길드, 및 한정판 자동차 인증을 전문으로 하는 자동차 인증 길드를 포함하는 그룹의 적어도 서브세트를 포함하는, 방법.
  14. 제13항에 있어서, 상기 인증자는 상기 상이한 전문화된 인증 길드들 중 한 전문화된 인증 길드에 속하는, 방법.
  15. 제14항에 있어서, 상기 인증자에게는, 상기 인증자가 속한 전문화된 인증 길드 및 상기 담보 아이템의 아이템 유형에 기초하여 상기 인증 작업이 할당되는, 방법.
  16. 제9항에 있어서, 상기 인증 스테이지-레벨 거버넌스는 상기 인증 스마트 계약 인스턴스가 인스턴스화된 인증 스마트 계약을 정의하는, 방법.
  17. 제9항에 있어서, 상기 인증 스마트 계약 인스턴스는 상기 인증자가 상기 담보 아이템을 진품으로 간주했음을 나타내는 상기 인증 보고에 응답하여 상기 인증자의 계정으로부터 상기 에스크로 계정으로의 금액의 통화 토큰들 및/또는 토큰화된 토큰들의 에스크로잉(escrowing)을 개시하는, 방법.
  18. 제17항에 있어서, 상기 에스크로잉된 금액의 적어도 일부는 상기 대출 프로세스가 완료될 때까지 에스크로에 유지되는, 방법.
  19. 제6항에 있어서, 상기 인증 스마트 계약 인스턴스는 상기 인증자 디바이스로부터 상기 인증 보고를 수신하는 것에 응답하여 상기 인증 통보를 상기 대출 프로세스 스마트 계약 인스턴스에 출력하고, 상기 인증 통보는 상기 대출 프로세스 스마트 계약 인스턴스가 상기 대출 프로세스의 평가 스테이지를 개시하게 하는, 방법.
  20. 제6항에 있어서, 상기 인증 스마트 계약 인스턴스는 또한:
    상기 인증 보고 및 상기 인증 보고에 적어도 부분적으로 기초하여 생성되는 암호화 해시 값을 포함하는 데이터 블록을 생성하고;
    상기 데이터 블록을 상기 분산형 원장에 기입하도록 구성된, 방법.
  21. 제2항에 있어서, 상기 인증자의 등급은 상기 인증 작업과 연관된 결과에 기초하여 업데이트되는, 방법.
  22. 제1항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 상기 담보 아이템의 평가 가치를 결정하기 위해 평가자에 의해 수행되는 평가 작업을 관리하고 상기 평가 작업이 완료되었음을 확정할 때 평가 통보를 발행하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 평가 스마트 계약 인스턴스를 인스턴스화하도록 구성된, 방법.
  23. 제22항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스는 상기 대출 프로세스 워크플로우에 따라 상기 평가 스마트 계약 인스턴스를 인스턴스화하는, 방법.
  24. 제23항에 있어서, 상기 대출 프로세스 워크플로우는 상기 분산형 원장에 저장된 시스템-레벨 거버넌스 문서에서 정의되며, 상기 시스템-레벨 거버넌스는 상기 평가 작업을 개시하기 위한 조건을 정의하는, 방법.
  25. 제22항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스는, 인증자가 상기 담보 아이템을 인증했고 상기 담보 아이템을 진품으로 간주했음을 나타내는 인증 통보를 수신하는 것에 응답하여, 상기 평가 스마트 계약 인스턴스를 인스턴스화하는, 방법.
  26. 제22항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 상기 평가자의 평가자 디바이스로부터 평가 보고를 수신하도록 구성되고, 상기 평가 보고는 상기 담보 아이템의 평가 가치와 상기 담보 아이템의 청산 가치 중 적어도 하나를 포함하는 담보 아이템의 평가액을 포함하는, 방법.
  27. 제26항에 있어서, 상기 평가 보고는, 상기 아이템의 물리적 상태, 상기 담보 아이템의 신규 또는 이용된 상태, 상기 담보 아이템의 작동 상태, 유사한 아이템들의 이전 판매 가격들, 및 유사한 아이템들의 블루북 평가액(bluebook valuation) 중 하나 이상을 더 포함하는, 방법.
  28. 제27항에 있어서, 상기 평가 보고는 하나 이상의 각각의 2차 평가자에 의해 발행된 하나 이상의 확인을 더 포함하고, 각각의 확인은 각각의 2차 평가자가 상기 평가 가치를 확정했음을 나타내는, 방법.
  29. 제26항에 있어서, 상기 평가 보고는, 상기 평가 작업의 수행과 연관된 한 세트의 규칙들 및 규정들을 정의하는 평가 스테이지-레벨 거버넌스에 따라 정의되는 양식 템플릿으로부터 생성되는, 방법.
  30. 제29항에 있어서, 상기 평가 스테이지-레벨 거버넌스는 평가 작업 워크플로우를 정의하고, 상기 평가 작업 워크플로우는, 상기 평가 작업을 완료하고 상기 대출 프로세스 워크플로우의 다음 스테이지를 트리거하기 위해 충족되어야 하는 하나 이상의 조건을 포함하는, 방법.
  31. 제30항에 있어서, 상기 평가 스테이지-레벨 거버넌스는 상기 평가자가 길드 멤버인 평가 길드에 의해 적어도 부분적으로 정의되는, 방법.
  32. 제31항에 있어서, 상기 평가 길드는 복수의 상이한 전문화된 평가 길드를 포함하고, 각각의 전문화된 평가 길드는 각각의 유형의 담보 아이템을 평가하는 것을 전문으로 하는, 방법.
  33. 제32항에 있어서, 상기 복수의 상이한 전문화된 평가 길드는 : 시계 평가를 전문으로 하는 시계 평가 길드, 신발 평가를 전문으로 하는 신발 평가 길드, 핸드백 평가를 전문으로 하는 핸드백 평가 길드, 예술 작품 평가를 전문으로 하는 예술품 평가 길드, 스포츠 기념품 평가를 전문으로 하는 스포츠 기념품 평가 길드, 소장용 장난감 평가를 전문으로 하는 장난감 평가 길드, 보석 평가를 전문으로 하는 보석 평가 길드, 디자이너 의류 평가를 전문으로 하는 의류 평가 길드, 악기 전문 평가를 전문으로 하는 악기 평가 길드, 희귀 또는 소장용 음반 평가를 전문으로 하는 음반 평가 길드, 와인 단위(예를 들어, 배럴 또는 병)의 전문 평가를 전문으로 하는 와인 평가 길드, 위스키 단위(예를 들어, 배럴 또는 병)의 평가를 전문으로 하는 위스키 평가 길드, 및 한정판 자동차 평가를 전문으로 하는 자동차 평가 길드를 포함하는 그룹의 적어도 서브세트를 포함하는, 방법.
  34. 제33항에 있어서, 상기 평가자는 상기 상이한 전문화된 평가 길드들 중 한 전문화된 평가 길드에 속하는, 방법.
  35. 제34항에 있어서, 상기 평가자에게는, 상기 평가자가 속한 전문화된 평가 길드 및 상기 담보 아이템의 아이템 유형에 기초하여 상기 평가 작업이 할당되는, 방법.
  36. 제35항에 있어서, 상기 평가 스테이지-레벨 거버넌스는 상기 평가 스마트 계약 인스턴스가 인스턴스화된 평가 스마트 계약을 정의하는, 방법.
  37. 제36항에 있어서, 여기서, 평가 스마트 계약 인스턴스는, 상기 평가 보고를 수신하는 것에 응답하여 상기 평가자의 계정으로부터 상기 에스크로 계정으로의 금액의 통화 토큰들 및/또는 토큰화된 토큰들의 에스크로잉을 개시하며, 상기 통화 토큰들 및/또는 토큰화된 토큰들의 상기 금액은 상기 평가 가치 이하인, 방법.
  38. 제37항에 있어서, 상기 에스크로잉된 금액의 적어도 일부는 상기 대출 프로세스가 완료될 때까지 상기 에스크로 계정에서 잠금처리되는, 방법.
  39. 제26항에 있어서, 상기 평가 스마트 계약 인스턴스는, 상기 평가자 디바이스로부터 상기 평가 보고를 수신하는 것에 응답하여 상기 평가 통보를 상기 대출 프로세스 스마트 계약에 출력하고, 상기 평가 통보는 상기 대출 프로세스 스마트 계약 인스턴스가 상기 대출 프로세스의 보관 스테이지를 개시하게 하는, 방법.
  40. 제26항에 있어서, 상기 평가 스마트 계약 인스턴스는 또한:
    상기 평가 보고 및 상기 평가 보고에 적어도 부분적으로 기초하여 생성되는 암호화 해시 값을 포함하는 데이터 블록을 생성하고;
    상기 데이터 블록을 상기 분산형 원장에 기입하도록 구성된, 방법.
  41. 제22항에 있어서, 상기 평가자의 등급은 상기 평가 작업과 연관된 결과에 기초하여 업데이트되는, 방법.
  42. 제1항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 상기 대출 프로세스의 적어도 일부 동안 상기 담보 아이템을 안전하게 보관하기 위해 보관자에 의해 수행되는 보관 작업을 관리하고 상기 보관 작업이 완료되었음을 확정할 시에 보관 통보를 발행하도록 구성된 컴퓨터 판독가능한 명령어들을 포함하는 보관 스마트 계약 인스턴스를 인스턴스화하도록 구성된, 방법.
  43. 제42항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스는 상기 대출 프로세스 워크플로우에 따라 상기 보관 스마트 계약 인스턴스를 인스턴스화하는, 방법.
  44. 제43항에 있어서, 상기 대출 프로세스 워크플로우는 상기 분산형 원장에 저장된 시스템-레벨 거버넌스 문서에서 정의되며, 상기 시스템-레벨 거버넌스는 상기 보관 작업을 개시하기 위한 조건을 정의하는, 방법.
  45. 제42항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스는 평가자가 상기 담보 아이템을 평가했음을 나타내는 평가 통보를 수신하는 것에 응답하여 상기 보관 스마트 계약 인스턴스를 인스턴스화하는, 방법.
  46. 제42항에 있어서, 상기 대출 프로세스 스마트 계약 인스턴스의 컴퓨터 판독가능한 명령어들은 또한, 상기 보관자의 보관자 디바이스로부터 보관 보고를 수신하도록 구성되고, 상기 보관 보고는, 상기 아이템이 보관자와 연관된 시설에 보관된다는 확인을 포함하고, 상기 담보 아이템이 수령되었을 때 상기 보관자에 의해 관찰된 임의의 가시적인 손상의 표시를 포함하는, 방법.
  47. 제46항에 있어서, 상기 보관 보고는 상기 보관 작업의 완료의 증거로서 상기 보관에 의해 제공되는 지원 문서를 더 포함하는, 방법.
  48. 제47항에 있어서, 상기 보관 보고는, 상기 담보 아이템이 상기 보관자에 의해 수령되었을 때 상기 보관자에 의해 관찰된 가시적인 손상의 사진 문서를 더 포함하는, 방법.
  49. 제46항에 있어서, 상기 보관 보고는, 상기 보관 작업의 수행과 연관된 한 세트의 규칙들 및 규정들을 정의하는 보관 스테이지-레벨 거버넌스에 따라 정의되는 보관 양식 템플릿으로부터 생성되는, 방법.
  50. 제49항에 있어서, 상기 보관 스테이지-레벨 거버넌스는 보관 작업 워크플로우를 정의하고, 상기 보관 작업 워크플로우는, 상기 보관 작업을 완료하고 상기 대출 프로세스 워크플로우의 다음 스테이지를 트리거하기 위해 충족되어야 하는 하나 이상의 조건을 포함하는, 방법.
  51. 제50항에 있어서, 상기 보관 스테이지-레벨 거버넌스는 상기 보관자가 길드 멤버인 보관자 길드에 의해 적어도 부분적으로 정의되는, 방법.
  52. 제49항에 있어서, 상기 보관 스테이지-레벨 거버넌스는 상기 보관 스마트 계약 인스턴스가 인스턴스화된 보관 스마트 계약을 정의하는, 방법.
  53. 제52항에 있어서, 상기 보관 스마트 계약 인스턴스는, 상기 보관 보고를 수신하는 것에 응답하여 상기 보관의 계정으로부터 상기 에스크로 계정으로 금액의 통화 토큰들 및/또는 토큰화된 토큰들의 에스크로잉을 개시하며, 상기 통화 토큰들 및/또는 토큰화된 토큰들의 상기 금액은 담보 아이템의 평가자에 의해 결정된 평가 가치 이하인, 방법.
  54. 제53항에 있어서, 상기 에스크로잉된 금액의 적어도 일부는 상기 대출 프로세스가 완료될 때까지 상기 에스크로 계정에서 잠금처리되는, 방법.
  55. 제46항에 있어서, 상기 보관 스마트 계약 인스턴스는, 상기 보관자 디바이스로부터 상기 보관 보고를 수신하는 것에 응답하여 상기 보관 통보를 상기 대출 프로세스 스마트 계약에 출력하고, 상기 보관 통보는 상기 대출 프로세스 스마트 계약 인스턴스가 상기 담보 토큰의 생성을 개시하게 하는, 방법.
  56. 제46항에 있어서, 상기 보관 스마트 계약 인스턴스는 또한:
    상기 보관 보고 및 상기 보관 보고에 적어도 부분적으로 기초하여 생성되는 암호화 해시 값을 포함하는 데이터 블록을 생성하고;
    상기 데이터 블록을 상기 분산형 원장에 기입하도록 구성된, 방법.
  57. 제42항에 있어서, 상기 보관의 등급은 상기 보관 작업과 연관된 결과에 기초하여 업데이트되는, 방법.
  58. 제42항에 있어서, 상기 보관자 디바이스는 상기 담보 아이템의 가상 표현을 생성하는데 이용되는 상기 담보 아이템의 하나 이상의 이미지를 제공하는, 방법.
  59. 제42항에 있어서, 상기 보관 스마트 계약 인스턴스는, 상기 담보 토큰이 상기 에스크로 계정으로부터 잠금해제된 후 상환 워크플로우를 실행하도록 구성된, 방법.
  60. 제59항에 있어서, 상기 상환 워크플로우는 결과적으로, 상기 담보 토큰의 상환자가 상기 보관자로부터 상기 담보 아이템의 소유를 가져오게 하는, 방법.
  61. 제1항에 있어서, 상기 대출 스마트 계약 인스턴스는 상기 대출이 채무불이행 상태에 있다고 결정하는 것에 응답하여 청산 프로세스를 개시하도록 구성된, 방법.
  62. 제61항에 있어서, 상기 담보 토큰은 청산 이벤트 동안 상기 담보 토큰을 구매하는 구매자에게 이전되어, 상기 구매자가 상기 담보 아이템을 보관을 위해 보유하는 보관자로부터 상기 담보 아이템의 소유를 가져오기 위해 상기 담보 토큰을 상환하는, 방법.
  63. 제1항에 있어서, 상기 대출 스마트 계약 인스턴스는, 상기 대출이 전액 상환되었다고 결정할 때 상기 에스크로 계정으로부터 상기 차용자의 계정으로의 상기 담보 토큰의 이전을 개시하도록 구성된, 방법.
  64. 제63항에 있어서, 상기 담보 토큰의 현재 소유자를 정의하는 소유권 데이터를, 상기 소유권 데이터가 상기 분산형 원장에서 상기 차용자의 계정의 주소를 포함하도록, 업데이트함으로써 상기 담보 토큰이 상기 에스크로 계정으로부터 상기 차용자의 계정으로 이전되는, 방법.
  65. 제1항에 있어서, 상기 담보 토큰은 상기 담보 아이템의 가상 표현을 포장(wrap)하는, 방법.
  66. 제1항에 있어서, 상기 대출 스마트 계약은, 상기 대출 조건 파라미터들에 정의된 대출의 대출 기간 및 대출 금액에 기초하여 대출 상환 일정을 결정하도록 구성되고, 상기 대출은 지불 일정에 따라 미리정의된 지불 금액이 지불되지 않을 때 채무불이행 스테이지에 있는 것으로 간주되는, 방법.
  67. 제1항에 있어서, 상기 대출 프로세스 워크플로우는, 인증자에 의해 수행되는 인증 작업을 정의하는 인증 스테이지, 평가자에 의해 수행되는 평가 작업을 정의하는 평가 스테이지, 보관자에 의해 수행되는 보관 작업을 정의하는 보관 스테이지를 포함하고, 상기 인증 스테이지, 상기 평가 스테이지, 및 상기 보관 스테이지는, 상기 담보 토큰이 생성되기 전에 실행되는, 방법.
  68. 제63항에 있어서, 상기 대출 인스턴스 스마트 계약 인스턴스는, 상기 대출 프로세스 완료에 응답하여, 상기 인증자, 상기 평가자, 및 상기 보관자에게 보상을 할당하는 것을 용이화하는, 방법.
  69. 제1항에 있어서, 상기 담보 아이템은 유형의 아이템인, 방법.
  70. 제1항에 있어서, 상기 대출의 상태 변경은 : 상기 대출이 전액 상환된 상태에 들어가는 것, 상기 대출이 채무불이행 상태에 들어가고 상기 담보 아이템이 성공적으로 청산된 상태, 및 대출 합의에 정의된 바와 같은 담보가 더 이상 요구되지 않는 상환의 상태 중 적어도 하나인, 방법.
KR1020227013995A 2019-09-26 2020-09-25 스마트 계약 아키텍쳐를 갖는 분산형 원장 대출 시스템들 및 이를 위한 방법들 KR20220138367A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962906211P 2019-09-26 2019-09-26
US62/906,211 2019-09-26
PCT/US2020/052728 WO2021062160A1 (en) 2019-09-26 2020-09-25 Distributed ledger lending systems having a smart contract architecture and methods therefor

Publications (1)

Publication Number Publication Date
KR20220138367A true KR20220138367A (ko) 2022-10-12

Family

ID=81210279

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227013995A KR20220138367A (ko) 2019-09-26 2020-09-25 스마트 계약 아키텍쳐를 갖는 분산형 원장 대출 시스템들 및 이를 위한 방법들

Country Status (8)

Country Link
US (14) US20220230240A1 (ko)
EP (1) EP4035115A4 (ko)
JP (1) JP2022549951A (ko)
KR (1) KR20220138367A (ko)
CN (1) CN114616582A (ko)
AU (1) AU2020351764A1 (ko)
CA (1) CA3155654A1 (ko)
IL (1) IL291680A (ko)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10140392B1 (en) 2017-06-29 2018-11-27 Best Apps, Llc Computer aided systems and methods for creating custom products
US20230124040A1 (en) * 2018-11-02 2023-04-20 Verona Holdings Sezc Event stream generation and analytics for cryptographic tokens that link to real world objects
JP2022549951A (ja) * 2019-09-26 2022-11-29 ヤクブ シリフカ，ルカシュ スマートコントラクトアーキテクチャを有する分散台帳貸し付けシステム並びにその方法
US11798073B2 (en) * 2020-04-16 2023-10-24 Maurice Vanegas Blockchain digital cryptocurrency loan system
CA3124502A1 (en) * 2020-07-13 2022-01-13 Royal Bank Of Canada Secure identity data tokenization and processing
US20220284008A1 (en) * 2021-03-02 2022-09-08 Mastercard International Incorporated Method and system of implementing partitioned blockchain
US20230043731A1 (en) 2021-08-06 2023-02-09 Salesforce.Com, Inc. Database system public trust ledger architecture
US20230085481A1 (en) * 2021-09-13 2023-03-16 Salesforce.Com, Inc. Database system public trust token redeem architecture using wallets
US11770445B2 (en) 2022-01-25 2023-09-26 Salesforce, Inc. Decentralized information management database system
US11651093B1 (en) * 2022-02-24 2023-05-16 LendingClub Bank, National Association Automated fraudulent document detection
WO2023212204A1 (en) * 2022-04-28 2023-11-02 Twigital LLC Object digitization utilizing tokens
US11880372B2 (en) 2022-05-10 2024-01-23 Salesforce, Inc. Distributed metadata definition and storage in a database system for public trust ledger smart contracts
US20240005354A1 (en) * 2022-07-01 2024-01-04 Redeem Technologies Inc. System and method of providing mobile number linked to redeemable and shareable promotions and a checkout process
JP7359481B1 (ja) 2022-12-12 2023-10-11 スラッシュ フィンテック リミテッド 情報処理装置、方法、プログラム、およびシステムの生産方法
CN115878832B (zh) * 2023-02-15 2023-05-16 武汉理工大学三亚科教创新园 基于精细对齐判别哈希的海洋遥感图像音频检索方法

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5794207A (en) * 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
AU2003295787A1 (en) * 2002-12-30 2004-07-29 Fannie Mae System and method for facilitating delivery of a loan to a secondary mortgage market purchaser
US20050065871A1 (en) * 2003-09-23 2005-03-24 Nucenz Technologies, Inc. Collateralized loan market systems and methods
US8224725B2 (en) * 2004-10-14 2012-07-17 Google Inc. Escrowing digital property in a secure information vault
US7716125B2 (en) * 2005-08-10 2010-05-11 Axcessnet Innovations Llc Networked loan market and lending management system
US20070203852A1 (en) * 2006-02-24 2007-08-30 Microsoft Corporation Identity information including reputation information
AU2009249272B2 (en) * 2008-05-18 2014-11-20 Google Llc Secured electronic transaction system
US20120290467A1 (en) * 2011-05-09 2012-11-15 Bank Of America Corporation Networking platform for lending
US20160071206A1 (en) * 2014-09-04 2016-03-10 Alexander Danieli Implementation of a Service Platform for an Online Peer-to-Peer (P2P) Lending Transaction
US11704733B2 (en) * 2015-05-01 2023-07-18 Tzero Ip, Llc Crypto multiple security asset creation and redemption platform
US11488147B2 (en) * 2015-07-14 2022-11-01 Fmr Llc Computationally efficient transfer processing and auditing apparatuses, methods and systems
US20170109735A1 (en) * 2015-07-14 2017-04-20 Fmr Llc Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems
US10339523B2 (en) * 2015-07-14 2019-07-02 Fmr Llc Point-to-point transaction guidance apparatuses, methods and systems
US20180191503A1 (en) * 2015-07-14 2018-07-05 Fmr Llc Asynchronous Crypto Asset Transfer and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20210266167A1 (en) * 2015-07-14 2021-08-26 Fmr Llc Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170085555A1 (en) * 2015-07-14 2017-03-23 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US20170091756A1 (en) * 2015-07-14 2017-03-30 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US11130042B2 (en) * 2016-02-02 2021-09-28 Bao Tran Smart device
US10915969B2 (en) * 2016-08-11 2021-02-09 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced organizational transparency using a credit chain
US20180322597A1 (en) * 2016-08-31 2018-11-08 Robert Sher Decentralized cryptographic real estate transaction assistance system and method
WO2018140913A1 (en) * 2017-01-30 2018-08-02 SALT Lending Holdings, Inc. System and method of creating an asset based automated secure agreement
US20200394652A1 (en) * 2017-03-08 2020-12-17 Ip Oversight Corporation A method for creating commodity assets from unrefined commodity reserves utilizing blockchain and distributed ledger technology
US10243743B1 (en) * 2017-09-13 2019-03-26 Vijay K. Madisetti Tokens or crypto currency using smart contracts and blockchains
US20180365764A1 (en) * 2017-06-15 2018-12-20 Sweetbridge Solo-party collateralized liquidity
US10460283B2 (en) * 2017-09-13 2019-10-29 Vijay Madisetti Smart contract optimization for multiparty service or product ordering system
US20190228409A1 (en) * 2017-09-13 2019-07-25 Vijay Madisetti Transaction Pools Using Smart Contracts and Blockchains
WO2019094797A1 (en) * 2017-11-10 2019-05-16 Digital Asset (Switzerland) GmbH Method and apparatus for execution of atomic transactions
JP2021504859A (ja) * 2017-11-22 2021-02-15 ソルト・ブロックチェーン・インコーポレイテッドＳａｌｔ Ｂｌｏｃｋｃｈａｉｎ Ｉｎｃ． 段階的に完全化されるデジタル資産担保ウォレット
US11200569B1 (en) * 2018-02-12 2021-12-14 Winklevoss Ip, Llc System, method and program product for making payments using fiat-backed digital assets
US11522700B1 (en) * 2018-02-12 2022-12-06 Gemini Ip, Llc Systems, methods, and program products for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US10373158B1 (en) * 2018-02-12 2019-08-06 Winklevoss Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US11139955B1 (en) * 2018-02-12 2021-10-05 Winklevoss Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US10540654B1 (en) * 2018-02-12 2020-01-21 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US20200219150A1 (en) * 2018-02-13 2020-07-09 Dallas Johnston Method and system for a value based attestation of counterparty credibility
CN108416675A (zh) * 2018-02-14 2018-08-17 阿里巴巴集团控股有限公司 资产管理方法及装置、电子设备
CN108335206B (zh) * 2018-02-14 2020-12-22 创新先进技术有限公司 资产管理方法及装置、电子设备
WO2019169374A1 (en) * 2018-03-02 2019-09-06 Ranieri Solutions, Llc Methods and apparatus for servicing an obligation utilizing a blockchain
US11334883B1 (en) * 2018-03-05 2022-05-17 Gemini Ip, Llc Systems, methods, and program products for modifying the supply, depositing, holding and/or distributing collateral as a stable value token in the form of digital assets
US11720888B2 (en) * 2018-03-08 2023-08-08 Borsetta Labs, Llc Decentralized title transfer and validation of assets
US11416931B2 (en) * 2018-03-16 2022-08-16 Salt Blockchain Inc. Investment fund token ownership
CA3098150A1 (en) * 2018-03-30 2019-10-03 Exposition Park Holdings SEZC Blockchain loan transaction systems and methods
US20210082044A1 (en) * 2018-03-30 2021-03-18 Lukasz Jakub SLIWKA Distributed ledger lending systems having a smart contract architecture and methods therefor
US11068978B1 (en) * 2018-04-02 2021-07-20 Liquid Mortgage Inc. Decentralized systems and methods for managing loans and securities
US20210126794A1 (en) * 2018-04-30 2021-04-29 Shyft Network Inc. Methods, apparatus and system for identification verification
US20190333030A1 (en) * 2018-04-30 2019-10-31 Bank Of America Corporation Blockchain-based digital token utilization
SG11202010731VA (en) * 2018-05-06 2020-11-27 Strong Force Tx Portfolio 2018 Llc Methods and systems for improving machines and systems that automate execution of distributed ledger and other transactions in spot and forward markets for energy, compute, storage and other resources
US20210342836A1 (en) * 2018-05-06 2021-11-04 Strong Force TX Portfolio 2018, LLC Systems and methods for controlling rights related to digital knowledge
US11816664B2 (en) * 2018-05-07 2023-11-14 Broadridge Financial Solutions, Inc. Computer network systems administering cryptographically-secured, token-based substitution management and methods of use thereof
US20190392536A1 (en) * 2018-06-26 2019-12-26 bootstrap legal Inc. Method and System for Creating and Managing a Smart Contract on a Distributed Ledger
US20200013053A1 (en) * 2018-07-06 2020-01-09 Chaitanya Tushar AMIN Controlling asset access based on payments via a distributed ledger
US10880074B2 (en) * 2018-10-15 2020-12-29 Adobe Inc. Smart contract platform for generating and customizing smart contracts
JP2020068010A (ja) * 2018-10-18 2020-04-30 スタートバーン株式会社 プログラム
CA3118593A1 (en) * 2018-11-02 2020-05-07 Verona Holdings Sezc A tokenization platform
CA3038090A1 (en) * 2019-03-25 2020-09-25 PetroChain Holdings, Inc. Distributed ledger investment governance platform
US11288736B1 (en) * 2019-04-02 2022-03-29 Homium, LLC Blockchain-based shared appreciation note
TWI772654B (zh) * 2019-06-21 2022-08-01 天宿智能科技股份有限公司 跨區塊鏈第三方仲裁履約保證系統及其方法
US20210065293A1 (en) * 2019-08-29 2021-03-04 The Lendingcoin, Inc. Distributed ledger lending
JP2022549951A (ja) * 2019-09-26 2022-11-29 ヤクブ シリフカ，ルカシュ スマートコントラクトアーキテクチャを有する分散台帳貸し付けシステム並びにその方法
US20220327529A1 (en) * 2021-03-31 2022-10-13 Williams Richard K Advanced Transactional Protocols And Ecosystem For Smart Contract Authoring And Deployment

Also Published As

Publication number Publication date
US20220374982A1 (en) 2022-11-24
US20220374979A1 (en) 2022-11-24
CA3155654A1 (en) 2021-04-01
EP4035115A1 (en) 2022-08-03
EP4035115A4 (en) 2023-07-26
US20220230240A1 (en) 2022-07-21
US20220358577A1 (en) 2022-11-10
US20220374981A1 (en) 2022-11-24
AU2020351764A1 (en) 2022-04-21
US20220358583A1 (en) 2022-11-10
US20220358578A1 (en) 2022-11-10
US20220358580A1 (en) 2022-11-10
US20220358584A1 (en) 2022-11-10
IL291680A (en) 2022-05-01
US20220358579A1 (en) 2022-11-10
US20220351286A1 (en) 2022-11-03
CN114616582A (zh) 2022-06-10
US20220374980A1 (en) 2022-11-24
US20220358582A1 (en) 2022-11-10
JP2022549951A (ja) 2022-11-29
US20220358581A1 (en) 2022-11-10

Similar Documents

Publication Publication Date Title
US20210082044A1 (en) Distributed ledger lending systems having a smart contract architecture and methods therefor
US11334875B2 (en) Techniques for authenticating and tokenizing real-world items
US20220351195A1 (en) Crafting of non-fungible tokens using pre-minted tokens
US20220358583A1 (en) Smart contract-managed decentralized lending processes using collateral tokens
WO2021062160A1 (en) Distributed ledger lending systems having a smart contract architecture and methods therefor
US20230131603A1 (en) Initiating a workflow in a digital token transaction system based on a recognized activity in a food delivery system
US20230196341A1 (en) Digital tokens that are redeemable for baskets of items
US20230117725A1 (en) Performance analytics for cryptographic tokens that link to real world objects
US20230118213A1 (en) Behavioral analytics for cryptographic tokens that link to real world objects
CA3177552A1 (en) Token-facilitated ticketing, token-facilitated pre-sale campaigns, and digital rights management for digital tokens
US20230130594A1 (en) Initiating a workflow in a customer relationship management system based on a recognized activity in a digital token transaction system
US20230117135A1 (en) Configuring a set of digital tokens with a temporal attribute that determines a timing of redemption of the set of digital tokens for a corresponding set of items
US20230118717A1 (en) Configuring a set of digital tokens with a temporal attribute that determines conditions for the set of digital tokens becoming redeemable for a corresponding set of items
US20230119584A1 (en) Pricing analytics for cryptographic tokens that link to real world objects
US20230121779A1 (en) Digital tokens that are redeemable for baskets of items
US20230123346A1 (en) Initiating a workflow in a virtual reality system based on a recognized activity in a digital token transaction system
US20230117430A1 (en) Initiating a workflow in a food delivery system based on a recognized activity in a digital token transaction system