KR20230031983A - 분할 대체 불가능 토큰의 상태를 생성, 추적 및 변경하기 위한 방법 및 시스템 - Google Patents

Abstract

본 발명은 분할 대체 불가능 토큰(Fractional Non-Fungible Tokens, FNFTs)의 상태를 생성, 추적 및 변경하기 위한 방법 및 시스템에 관한 것이다. 본 발명은 특히 시간이 지남에 따라 또는 이벤트 발생 시 상태가 변경될 수 있는 디지털 또는 실제 세계의 자산과 관련된 FNFT에 적용된다. 본 발명은 또한 메타 세계의 가상 아이템에 브랜드 또는 상표를 추가하는 데 특히 유용하다.

Description

분할 대체 불가능 토큰의 상태를 생성, 추적 및 변경하기 위한 방법 및 시스템

본 출원은 미국 2021년 6월 16일자로 출원된 미국 가출원 번호 63/211027, 2021년 12월 30일에 출원된 미국 가출원 번호 63/295090 및 2022년 1월 12일에 출원된 미국 가출원 번호 63/298903의 우선권을 주장하며, 내용 또는 전체 내용이 참조로 도입된다.

본 발명은 분할 대체 불가능 토큰(Fractional Non-Fungible Tokens, FNFTs)의 상태를 생성, 추적 및 변경하기 위한 방법 및 시스템에 관한 것이다.

본 발명은, 디지털 세계에서든지 현실 세계에서든지, 특히 자산과 관련된 FNFT에 적용되며, 이는 시간이 지남에 따라 또는 이벤트 발생 시 상태가 변경될 수 있다.

이러한 자산의 비제한적 예는 특허 또는 특허 출원과 같은 산업 재산권 소유권이다. 특허 출원은 부여되거나 거절되는 즉시 특허로 변경될 수 있으며 추가로 소멸되거나 취하될 수 있다.

본 발명의 또 다른 적용은, 특히 이 자산이 무형이거나 일시적인 경우, 원산지 보증 또는 당국에 의한 인증을 통해 가치를 얻는 자산에 관한 것이다. 이러한 자산의 예로는 자격을 갖춘 녹색 전기의 kWh와 같은 에너지 공급 단위가 있다. 이러한 자산의 또 다른 예는 메타 유니버스로 알려진 정보 기술 시스템의 가상 자산이다. 이러한 자산의 예로는 특정 브랜드를 포함할 때 가치가 높아지는 가상 객체가 있다.

본 발명의 또 다른 적용은 양도가 발생하기 위해 에스크로(escrow) 또는 신뢰할 수 있는 제3자를 필요로 하거나 이용하는 자산에 관한 것이다.

블록체인은 네트워크의 많은 컴퓨터 또는 노드에서 업데이트되고 공유되는 데이터베이스 또는 레저(ledger)로, 합의 메커니즘을 구현하는 암호화폐를 통해 피어 투 피어 트랜잭션을 허용한다. 분산형 블록체인의 잘 알려져 있지만 비제한적인 예는 Bitcoin® 또는 Ethereum®이다.

블록체인 기술은 유저들(users) 간의 거래를 기록하는 변조 방지 전자 레저를 제공한다. 전술한 트랜잭션은 관련된 유저의 지갑 사이에서 일정량의 암호화폐를 교환하는 것으로 구성되며 합의 메커니즘이라는 프로세스에 의해 인증되어야 한다.

Bitcoin® 또는 Ethereum®과 같은 일부 블록체인은 분산형이거나 공용이다. 다른 일부는 중앙 집중식이며 개인 소유 및 관리된다.

합의 메커니즘에 의해 인증된 후 트랜잭션에 대당하는 블록을 체인화하는 원리는 합의 메커니즘이 "증명 또는 작업"과 같은 채굴을 필요로 하거나 또 다른 메커니즘에서든 블록체인 간에 공유되는 원칙이다.

전체적인 관점에서 합의 메커니즘은 블록체인 내의 트랜잭션 또는 트랜잭션 블록을 인증하기 위해 하나 이상의 인증자가 일부 작업을 수행하도록 요청하고 인증자는 보상을 받는다. 따라서, 각각의 트랜잭션에는 수수료 또는 적어도 컴퓨팅 시간, 인증자의 보상에 대응하는 수수료가 적용된다. 예를 들어 인증자는 Bitcoin®의 마이너(miner)이다.

일부 블록체인은 스마트 계약의 구현을 허용한다. 스마트 계약은 블록체인의 특정 주소에 상주하며, 유저의 요청에 따라, 특정 데이터에 따라 특정 기능을 수행하는 코드, 프로그램이다. 스마트 계약은 구성 가능하다. 즉, 스마트 계약이 다른 스마트 계약의 실행을 호출할 수 있다.

스마트 계약은 분산형 블록체인과 상호 작용할 수 있는 플랫폼 또는 "Dapps"를 생성하고 레저의 안전성과 추적 가능성을 활용할 수 있도록 한다.

이러한 플랫폼은 자산을 생성하고 거래할 수 있으며, 플랫폼의 디지털 세계에서의 거래는 토큰으로 수행된다. 따라서, 토큰은 현실 세계에서 자산의 디지털 대응물이 될 수 있는 암호화 자산이다.

블록체인에 구축된 플랫폼에서 토큰을 사용하면 위조 및 이중 지출 가능성을 제거하여 암호화 자산의 진정성이 보장된다. 토큰은 대체 가능할 수 있는데, 이는 토큰이 맹목적으로 서로 교환될 수 있고, 교환 가능하고 분할 가능하며 실제로 명목 화폐(fiat currency)처럼 작동한다는 것을 의미한다. 암호화폐도 대체 가능하지만 Bitcoin® 또는 Ether®와 같은 암호화폐는 블록체인의 기본 자산인 반면 토큰은 기존 블록체인 네트워크 위에 개발된 플랫폼 또는 프로젝트의 가치 단위이다.

이들은 또한 대체 불가능할 수 있는데, 이는 이들이 분할될 수 없거나 동일한 유형의 다른 대체 불가능 토큰으로 정확히 교환될 수 없음을 의미한다. 대체 불가능한 토큰(NFT, Non Fungible Token)은 고유하며 맹목적으로 서로 교환할 수 없다.

NFT의 고유 식별자를 사용하여, NFT는 현실 세계에서 예술품, 수집품 또는 기념품과 같은 자산에 연결될 수 있으며, 이러한 NFT를 구현하는 플랫폼은, 예를 들어, 각각의 고유 ID를 실제 세계의 특정 자산과 연결하는 목록으로 구성된다. 따라서, NFT는 이러한 실제 자산 또는 이 실제 자산의 아바타를 디지털 세계로 전송하여 이 자산을 통한 거래를 가능하게 한다. 그러한 NFT의 소유권은 사유 재산의 특성을 지닌다.

"Dapp"은 분산형 애플리케이션(Decentralized application)의 약자로 스마트 계약과 프런트엔드 유저 인터페이스를 결합한 분산형 네트워크, 즉 블록체인에 구축된 애플리케이션이다.

분할 대체 불가능 토큰(Fractional Non Fungible Tokens, FNFT)은 회사의 자본이 주식으로 분할될 수 있는 것처럼 NFT가 주식으로 분할되는 NFT의 특성을 지닌다.

각각의 FNFT는 고유 식별자를 갖는 NFT이며, 대체 불가능하고 더 이상 분할될 수 없다. 분할될 수 있다라고 불리는 유일한 이유는 궁극적으로 주어진 자산의 각 분할 NFT가 바로 이 자산과 관련되기 때문이다. 따라서, 예를 들어, 이 자산이 파기되면 이와 관련된 전체 FNFT 세트가 즉시 파기되거나 "소각(burnt)"된다.

디지털 세계의 장점은 실제 자산과 관련된 모든 NFT는 실제 세계 또는 메타 유니버스에서 기본 자산의 특성에 관계없이 복수의 대체 불가능한 분할 토큰으로 분할될 수 있다는 것이다. 따라서, 이러한 분할 대체 불가능한 토큰(FNFT)은 기본 자산의 소유권 지분으로 간주될 수 있다.

또 다른 예로서, 하나의 배치의 상품에 특정 브랜드나 상표가 부착되어 있으면 유사하거나 심지어 동일한 다른 상품과 구별할 수 있게 된다. 이는 메타 유니버스 뿐만 아니라 현실 세계에서도 마찬가지이다.

이러한 메타 유니버스에서, 신발 한 켤레, 자동차 또는 티셔츠와 같은 가상 아이템에는 특정 브랜드가 포함될 수 있다. 그러한 아이템이 무한한 수로 생산되거나 생성될 수 있는 가상 세계에서, 아이템들 중 일부는 이들을 특별하게 하고 잠재적으로 더 바람직하고 더 비싸게 하는 특정 브랜드를 가질 수 있다.

가상 세계에서는, 원산지를 탐지하는 물리적인 방법이 없으며, 따라서, 상표가 될 수 있는 원산지 보증은 신뢰할 수 있는 기관에 의해 이루어져야 한다. 단순히 티셔츠와 같이 이러한 배치의 각각의 아이템이 고유하게 식별되지 않더라도 브랜드를 가지고 있기 때문에, 각각의 아이템을 고유한(가상) 것으로 만드는 NFT 접근 방식은 실제로 만족스럽지 않으며, 아이템의 배치가 실제로 원산지 보장에 영향을 미치는 실생활에서 일어나는 일을 올바르게 반영하지 않는다.

블록체인 상에 구축된 플랫폼에서, 모든 조치는 변조 방지 레저(ledger)에 기록된 트랜잭션에 의존한다. 따라서, 특정 작업을 수행하기 위해, 스마트 계약은 각각이 합의 메커니즘을 거쳐야 하는 다수의 트랜잭션을 트리거할 수 있다.

또한, 합의 메커니즘의 각각의 트리거링은 인증자에 의해 획득되는 어워드의 발행을 트리거한다.

따라서, 이 거래가 가치를 이전하거나 생성하지 않더라도 각각의 거래에는 수수료를 지불해야 한다. 결과적으로, 많은 트랜잭션이 필요한 스마트 계약은 계약 실행을 통해 전달되는 가치보다 더 높은 수수료를 생성할 수 있다.

예를 들어, NFT를 복수의 FNFT(예: 100,000FNFT일 수 있음)로 분할하고 각각의 FNFT의 속성이 다른 유저에게 영향을 미치려면 매우 높은 수수료로 이어질 수 있는 수십만 건의 거래가 필요하다.

또한, 블록체인의 안전을 위해 스마트 계약은 삭제할 수 없으며, 스마트 계약과의 상호 작용, 즉 스마트 계약 실행과 관련된 트랜잭션은 되돌릴 수 없다.

따라서, FNFT가 상태를 변경할 수 있는 기본 자산에 연결될 때, FNFT의 소유권은 광범위한 유저에게 분산되며, 이러한 상태 변경은 다시 한 번 많은 거래를 필요로 하므로 인증 수수료 관점에서 높은 비용이 발생한다.

본 발명은 종래 기술의 결점을 해결하는 것을 목적으로 하며, 이를 위해 노드를 연결하는 블록체인 네트워크를 포함하며 노드들 간의 트랜잭션을 기록하는 레저를 포함하는 시스템을 구현하는 FNFT의 상태를 생성, 추적 및 변경하는 방법에 관한 것이다.

본 발명은, 노드를 연결하는 블록체인 네트워크를 포함하며 노드들 사이의 트랜잭션(transaction)을 기록하는 레저(ledger)를 포함하는 시스템을 구현하는, 분할 대체 불가능 토큰(Fractional Non Fungible Tokens, FNFT)의 상태를 생성하고 추적하며 변경하기 위한 방법으로서, 시스템은:

블록체인 상부에 구축된 플랫폼;

플랫폼 및 블록체인 네트워크에 연결되며, 권한자(Authority), 유저 및 수탁자(Trustee)를 포함하는 복수의 컴퓨터;를 포함하고,

플랫폼은 유틸리티 토큰, 및 변환 토큰, 및 기록 토큰, 및 블록체인의 하나 이상의 노드, 및 플랫폼에 연결된 컴퓨터들 간의 토큰과 관련된 트랜잭션이 수행될 경우 관련된 동작을 트리거하도록 구성된 스마트 계약으로 알려져 있는 프로그램을 포함하며,

방법은:

- 유저가 수탁자에게 요청을 전송함으로써, 수탁자로부터 N개의 FNFT를 획득하기 위해 트랜잭션을 트리거하는 단계;

- 요청의 수신 시, 수탁자가 권한자에게 N개의 유틸리티 토큰을 전송하면서 권한자와의 트랜잭션을 시작하며, 권한자로부터 제1 변환 토큰 및 하나의 기록 토큰을 수신하는 단계;

- N개의 유틸리티 토큰 각각 및 변환 토큰 및 기록 토큰을 고유 식별자로 식별하는 단계;

- 제1 변환 토큰 및 기록 토큰의 식별자와 관련하여, N개의 유틸리티 토큰의 고유 식별자를 플랫폼의 데이터베이스에 등록하는 단계;

- 유저가 수탁자에게 지불하면, 기록 토큰을 유저에게 전달하는 단계;

- 유저-여기서 유저는 기록 토큰을 제공함-와 권한자-여기서 권한자는 N개의 식별된 유틸리티 토큰을 유저에게 전달함- 사이의 트랜잭션을 시작하는 단계;

- 트랜잭션이 완료되면 기록 토큰을 파기하는 단계;를 포함한다.

따라서, 유틸리티 토큰은 변환 토큰과 연결되면 FNFT로 변환된다. 이 변환 토큰은 수탁자에 의해 전달되고 수탁자가 보관한다. 유저는 플랫폼에서 FNFT를 거래할 수 있으며, 이들의 FNFT는 변환 토큰과 긴밀하게 연관되어 있고, 후자는 자산, 특히 실제 세계의 자산과 연결되며, 자산의 존재는 수탁자에 의해 보증되며, 유저에게 귀속될 실물 자산의 실제 재산이다.

이 초기 연관은 플랫폼에서 순환하는 유틸리티 토큰을 FNFT로 변경한다. 또한, 작업은 대응하는 FNFT의 상태를 변경하거나 동일한 제1 변환 토큰에 추가 FNFT를 추가할 수 있다.

본 발명의 방법은 개별적으로 또는 임의의 기술적으로 작동하는 조합으로 고려될 수 있는 이후에 개시되는 특정 실시예 및 변형에 따라 구현될 수 있다.

따라서, 본 발명의 방법은:

- 유저가, 동일한 제1 변환 토큰과 관련된 M개의 추가 FNFT를 획득하기 위해, 수탁자에게 요청을 보냄으로써 수탁자와 트랜잭션을 트리거하는 단계;

- 요청의 수신 시, 수탁자가 권한자-여기서 권한자는 제1 변환 토큰을 새로운 기록 토큰으로 되돌려줌-에게 제1 변환 토큰과 함께 M개의 유틸리티 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;

- 기록 토큰뿐만 아니라 M개의 유틸리티 토큰 각각을 고유 식별자로 식별하는 단계;

- 제1 변환 토큰 및 새로운 기록 토큰의 식별자와 관련하여, M개의 유틸리티 토큰의 고유 식별자를 플랫폼의 데이터베이스에 등록하는 단계;

- 수탁자가 지불할 경우, 유저에 의해, 새로운 기록 토큰을 유저에게 전달하는 단계;

- 유저-여기서 유저는 새로운 기록 토큰을 권한자에게 제공함-와 권한자-여기서 권한자는 M개의 식별된 유틸리티 토큰을 유저에 제공함- 간의 트랜잭션을 시작하는 단계;

- 트랜잭션이 완료되면 새로운 기록 토큰을 파기하는 단계;를 더 포함한다.

따라서, 제1 변환 토큰과의 연관에 의해 FNFT로 변환된 유틸리티 토큰의 수가 증가한다.

방법은:

- 수탁자가 유틸리티 토큰 없이 권한자에게 제1 변환 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;

- 권한자가 고유 식별자가 있는 제1 변환 토큰과 제2 변환 토큰을 다시 전송하는 단계;

- 제2 변환 토큰의 고유 식별자를 플랫폼의 데이터베이스에 등록하는 단계;를 더 포함할 수 있다.

이러한 방식으로, 관련된 모든 FNFT의 상태를 한 번에 변경하여, 이전 변환 토큰 위에 추가 변환 토큰을 추가하여 FNFT 기반 자산의 상태 변경을 반영할 수 있다.

요약하면:

- 수탁자가 권한자 유틸리티 토큰만 전송하여 권한자와 거래를 시작할 때, 권한자는 변환 토큰을 되돌려 보내고 대응하는 유틸리티 토큰과 이 변환 토큰의 연결을 플랫폼의 데이터베이스에 등록한다;

- 수탁자가 유틸리티 토큰과 변환 토큰을 전송하여 권한자와 거래를 시작할 때, 권한자는 변환 토큰을 되돌려 보내고 추가 유틸리티 토큰을 데이터베이스의 동일한 변환 토큰에 연결한다.

- 수탁자가 변환 토큰만을 전송하여 권한자와 거래를 시작할 때, 권한자는 처음에 전송된 변환 토큰의 "상단(going on top)" 변환 토큰을 다시 보내며 데이터베이스에서 후자에 연결되고, 따라서 초기에 전송된 변형 토큰과 관련된 유틸리티 토큰에 자동으로 영향을 미친다.

본 발명의 방법은:

- 수탁자가 유틸리티 토큰 없이 권한자에게 제2 변환 토큰을 전송하면서 권한자와 트랜잭션을 시작하는 단계;

- 권한자가 고유 식별자가 있는 제2 변환 토큰과 제3 변환 토큰을 다시 전송하는 단계;

- 제1 변환 토큰의 식별자와 함께 그리고 제2 변환 토큰의 식별자와 함께, 제3 변환 토큰의 고유 식별자를 플랫폼의 데이터베이스에 등록하는 단계;를 더 포함할 수 있으며,

마지막 변환 토큰이 이전 토큰들에 적재되며, 마지막 변환 토큰이 파일(pile)의 최상부에 있고, 제1 변환 토큰이 파일의 최하부에 있으며, 각각의 변환 토큰은 파일의 최하부의 레벨 0에서 파일의 최상부의 최상위 레벨로 증가하는, 파일 내의 레벨을 갖는다.

유틸리티 토큰과 제1 변환 토큰의 제1 연결이 수행되면, 추가 변환 토큰이 적재될 수 있으며, 따라서 변환 토큰의 스택이 생성되고, 각각의 변환 토큰은 영향을 받는 모든 FNFT의 상태 변경을 반영한다. 따라서 스택의 최상부에 있는 변환 토큰은 자산의 현재 상태를 나타낸다.

본 발명의 방법은:

- 수탁자가 N개의 트랜잭션 토큰의 세트를 권한자에게 전송하면서 권한자와의 트랜잭션을 시작하는 단계-여기서 N>2이고, 세트의 변환 토큰 각각은 파일 내에서 0 이상인 L1으로 넘버링된 하위 레벨에서부터 L2=L1+(N-1)인 상위 레벨 L2까지의 연속적인 레벨을 가짐-;

- 권한자가 킬러 토큰(Killer Token)-여기서 각각의 킬러 토큰은 레벨 L2에서 레벨 L0+1까지 하나의 변환 토큰에 영향을 받음-으로 지칭되는 특정 유형의 (N-1) 변환 토큰을 되돌려 보내는 단계;

- 각각의 킬러 토큰의 각각의 변환 토큰과의 연관(association)을 플랫폼의 데이터베이스 내에 등록하는 단계;를 더 포함할 수 있다.

이러한 방식으로, "후입선출" 체계에서 이와 같이 정의된 킬러 토큰으로 변환 토큰을 소멸시킴으로써 상태 변화를 반영하도록, 스택의 변환 토큰은 그 효과에서 소멸될 수 있다.

따라서, 유틸리티 토큰 없이 2개 이상의 연속 변환 토큰으로 권한자와의 트랜잭션을 시작하면 스택의 제1 토큰이 소멸된다.

일 실시예에 따르면, 제1 변환 토큰을 제외한 모든 변환 토큰은 데이터베이스의 킬러 토큰과 연관되며, 방법은:

- 수탁자가 권한자에게 킬러 토큰을 갖는 제1 변환 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;

- 수신 시, 권한자가 킬러 토큰의 제1 변환 토큰에 대한 연관을 데이터베이스에 등록하는 단계;를 더 포함한다.

- 유리하게, 방법은 에스크로(Escrow) 및 서비스 토큰을 더 포함하는 시스템을 구현하며, 방법은:

- 권한자가 에스크로 요청시 고유 식별자로 서비스 토큰을 생성하는 단계;

- 스택 상의 최상위 변환 토큰 및 정해진 수의 유틸리티 토큰과 연관된 서비스 토큰을 플랫폼의 데이터베이스에 등록하는 단계;를 포함한다.

유리하게, 에스크로는 서비스 토큰과 연관된 유틸리티 토큰의 임의의 트랜잭션에 대한 에스크로서의 역할을 한다.

일 실시예에 따르면, 권한자에 의한 서비스 토큰의 생성은 에스크로에 의해 준비되어 권한자에게 전송되는 목업 서비스 토큰(mockup Service Token)을 기반으로 한다.

특정 실시예에서, 시스템은 한 종류의 N개의 가상 아이템으로 구성된 메타 유니버스를 포함하며, 제1 변환 토큰은 한 종류를 N개의 유틸리티 토큰과 연관시키고, 제2 변환 토큰은 하나의 브랜드를 N개의 유틸리티 토큰과 연관시킨다.

이 실시예는 사전에 정의되지 않은 아이템의 수에 브랜드를 연관시키는 것을 허용한다.

본 발명은 도 1 내지 도 9를 참조하여 어떠한 방식으로도 제한되지 않는 바람직한 실시예로 아래에 설명된다.
도 1은 본 발명의 시스템의 정적 구성도이다.
도 2는, 본 발명의 방법에 따른, 유틸리티 토큰을 FNFT로 변경하는 트랜잭션을 도시한다.
도 3은, 도 2부터 시작하여, 동일한 자산에 추가 FNFT를 추가할 수 있는 방법을 개략적으로 도시한다.
도 4는 기본 자산의 상태 변경이 FNFT에 어떻게 반영될 수 있는지를 개략적으로 도시한다.
도 5는 킬러 토큰을 사용하여 일련의 FNFT를 하나의 상태에서 이전의 상태로 되돌릴 수 있는 방법을 도시한다.
도 6은 킬러 토큰을 사용하여 FNFT를 파기하지 않고 소멸시킬 수 있는 방법을 도시한다.
도 7은 FNFT을 기반으로 하는 자산의 상태 변화와 변환 토큰을 사용하여 이러한 변경 사항이 플랫폼에 반영되는 방법을 도시한다.
도 8은 FNFT가 손(hand)을 바꾸기 전에 서비스 토큰을 FNFT에 연결하는 예시적인 실시예를 도시한다.
도 9는 동일한 전송 시간에 서비스 토큰이 FNFT에 연관되는 또 다른 실시예를 도시한다.

도 1에서, 예시적인 실시예에 따른, 본 발명의 시스템은 본 발명의 방법을 구현하는 모든 플레이어가 연결되는 블록체인 네트워크(100)를 포함한다. 블록체인은 탈중앙화 블록체인이 바람직하지만 배타적이지는 않다.

블록체인 기술은 종래 기술로부터 알려져 있으며, 암호 화폐를 구현하는 P2P 거래를 허용하는, 네트워크의 여러 컴퓨터 또는 노드에서 업데이트되고 공유되는 레저(ledger)를 포함하며, 이러한 트랜잭션은 합의 메커니즘에 대한 응답으로 변조 방지 레저에서 검증되고 기록된다.

본 발명의 방법에 관련된 플레이어(101, 102, 103, 111, 112)는 모두 이 네트워크의 노드로서 블록체인 네트워크에 연결된다.

시스템은, 블록체인 네트워크(100)의 주소에 상주하는 프로그램인 스마트 계약을 사용하여, 상호 작용할 수 있는, 즉, 블록체인 네트워크의 노드들 간에 정의된 트랜잭션 세트를 트리거할 수 있는 블록체인 상부에 구축된 플랫폼(150)을 더 포함한다.

스마트 계약은 플랫폼(150) 상에서 순환 및 거래될 수 있는 토큰과 연관된다.

플랫폼은 플레이어가 액세스할 수 있는 네트워크이다. 전체적인 관점에서 플랫폼은 WAN이지만 애플리케이션에 따라 플랫폼은 LAN, MAN 또는 클라우드 네트워크가 될 수 있다.

모든 플레이어(101, 102, 103, 111, 112)도 플랫폼(150)에 연결된다.

플랫폼은 유틸리티 토큰(151), 변환 토큰(152) 및 기록 토큰(154)을 포함한다. 특정 실시예에서, 플랫폼은 또한 서비스 토큰(153)을 포함할 수 있다. 각각의 유형의 토큰은 스마트 계약을 실행하기 위해 각각의 토큰에서 사용될 수 있는 특정 기능으로 정의된 특정 거래 규칙 및 연관과 관련된다.

유틸리티 토큰(151)은 플랫폼의 플레이어들 간에 거래될 수 있다. 변환 토큰(152) 및 서비스 토큰(154)은 특정 플레이어들 간에 제한된 수의 트랜잭션에만 사용될 수 있는 작업 토큰이다.

기록 토큰(154)은 플랫폼에서 짧은 수명을 가지며 실제로 바우처로 사용된다.

예시적인 실시예로서, 본 발명의 방법의 구현에 관련된 플레이어는 권한자(Authority)의 역할을 하는 관리자(ADMIN)(101), 수탁자(Trustee)의 역할을 하는 하나 이상의 발행인(EMITTER)(102) 및 유저(111, 112)를 포함한다. 특정 실시예에서, 시스템은 에스크로 역할을 하는 하나 이상의 서비스 제공자(103)를 더 포함한다.

플레이어(101, 102, 103, 111, 112)는 플랫폼(150)에 직접 연결되거나 또는 인터넷(190)을 통해 연결될 수 있다.

플랫폼은 서로 다른 토큰을 함께 연관시키는 테이블을 포함하는 데이터베이스(160)를 포함한다. 나중에 표시되는 바와 같이, 따라서 유틸리티 토큰(151)의 배열은 제1 변환 토큰(152)과 연관될 수 있으며, 전술한 제1 변환 토큰은 스택에 서로 적재된 추가 변환 토큰과 연관될 수 있고, 서비스 토큰은 스택의 변환 토큰 및 유틸리티 토큰의 하위 배열과 연관될 수 있다.

이러한 모든 연관성은 데이터베이스(160)에 기록된다. 유저(111, 112)에서 볼 때, 플랫폼은 FNFT를 거래할 수 있는 시장이다. FNFT는 데이터베이스(160)에서 적어도 하나의 변환 토큰과 연관된 유틸리티 토큰이다. 이러한 유틸리티 토큰은 고유하게 식별되기 때문에, 손(hand)이 바뀌더라도 데이터베이스에서 동일한 변환 토큰과 연결된 상태로 유지된다.

즉, 시스템과 방법은 "토큰 중심"이라고 할 수 있으며, NFT를 미리 알 수 없으며 시간이 지남에 따라 변경될 수 있는 여러 FNFT로 분할하는 것을 허용한다. 선행 기술의 대부분의 시스템은 "자산 중심"이며 FNFT에서 NFT를 분할할 수 있고, 분할은 정의된 고정 수의 FNFT에서 한 번 수행된다.

도 2에서, 예시적인 실시예에 따르면, 유저(111)는 수탁자인 발행인(102)에게 요청(211)을 보냄으로써 여러 FNFT에 대한 소유권을 얻을 수 있다.

발행인은 지갑(wallet)(251)에 유틸리티 토큰(151)의 스톡(stock)을 가지고 있다.

요청(211)은 유저(111)가 주어진 양의 FNFT(예: 10)를 획득하기를 원한다고 규정한다. 요청(211)은, 예를 들어, 가격과 같은 제안을 포함할 수 있고, 따라서 유저(111)와 발행인(102) 사이의 협상 프로세스를 포함할 수 있다.

플랫폼에서 유틸리티 토큰이 초기에 생성되는 방식은 애플리케이션에 따라 다르다. 바람직한 실시예에서, 유틸리티 토큰과 실제로 플랫폼의 모든 토큰은 관리자(101)에 의해 ICO(Initial Coin Offering)의 대상이 되는 배치로 발행되거나 자동으로 리소스 생산을 반영한다.

발행인은 플랫폼에서 리소스를 관리하는 수탁자이다. 유틸리티 토큰의 스톡을 구축하기 위해, 발행인은 트랜잭션을 통해 관리자에서 이를 획득해야 한다. 이러한 트랜잭션은 애플리케이션에 따라 구매 또는 기타 공식적인 트랜잭션일 수 있다. 유틸리티 토큰이 일단 변환 토큰과 연결되면 FNFT가 된다는 사실을 고려할 때 어떤 종류의 거래이든 상관없다. 이 실시예에서, 발행인만이 유틸리티 토큰, 즉 순수 또는 블랭크 유틸리티 토큰을 획득할 수 있다.

유저는 순수 또는 블랭크 유틸리티 토큰이 아닌 FNFT만 획득하고 거래할 수 있다.

특정 실시예에서, 플랫폼이, 변환 토큰과 연관되지 않은, 다수의 발행인(102) 순수 또는 블랭크 유틸리티 토큰으로 구성되는 경우, FNFT와 동일한 마켓플레이스에서 발행인들 간에 거래될 수 있지만 플랫폼의 전용 마켓플레이스에서 거래하는 것이 바람직하다.

예를 들어, 발행인의 수신 확인을 통해, 유저(111)와 발행인(102)이 요청에 대한 합의에 도달하면, 발행인은 관리자(101)와 트랜잭션(221)을 시작하며, 여기서 발행인은 유저(111)와의 계약에 대응하는 여러 유틸리티 토큰(151)을 관리자에게 전송한다.

일 실시예에 따르면, 유틸리티 토큰은 AMDIN에 의해 처음 발행될 때 고유하게 식별될 수 있다. 또 다른 실시예에 따르면, 각각의 유틸리티 토큰은 발행인이 관리자으로부터 획득할 때 고유하게 식별된다. 제3의 바람직한 실시예에 따르면, 유틸리티 토큰을 관리자으로 전송하는 발행인과의 트랜잭션(221)이 트리거되면, 유틸리티 토큰은 고유하게 식별된다.

후자에 따르면, 유틸리티 토큰을 수신하면, 관리자는 각 유틸리티 토큰(151)에 고유 ID(예: 숫자 1 내지 10)를 부여할 것이며, 바우처(voucher)인 고유 식별자(A1) 및 기록 토큰을 사용하여 그리고 고유 식별자(X)를 사용하여 변환 토큰(152)을 생성할 것이다. 관리자는 또한 변환 토큰(A1)과 유틸리티 토큰(1 내지 10) 및 기록 토큰(X)의 연관성을 데이터베이스(191)에 기록한다.

변환 토큰(A1)은 발행인의 관리 하에 남아 있다. 애플리케이션에 따라, 이 변환 토큰(A1)이 실제 세계에서 특허 출원이나 브랜드와 같은 특정 식별 가능한 자산과 연결되어 있는 경우, 발행인은 자체 데이터베이스(260)에 이 연관을 기록한다. 유틸리티 토큰은 플랫폼 데이터베이스(160)에서 변환 토큰(A1)과 이미 연결되어 있기 때문에, 발행인은 이 자산에 연결된 모든 유틸리티 토큰을 식별할 필요가 없다.

이는 또한 원산지 보증을 제공하며, 예로써, 변환 토큰이 특정 브랜드를 특정 가상 아이템 또는 아이템 세트와 연관시키는 경우, 동일한 브랜드가 있는 것처럼 가장하지만 그렇게 등록되지 않은 다른 아이템은 합법적이지 않다.

트랜잭션(222)을 통해, 발행인은, 예를 들어, 암호화폐로 지불하는 대가로 바우처 또는 기록 토큰(X)(154)를 유저(111)에게 전달한다.

유저(111)가 이 바우처(154)를 받으면, 이제 유저의 지갑에 FNFT로 있는 1에서 10까지 번호가 지정된 유틸리티 토큰에 대한 바우처를 교환하는 관리자(101)와의 트랜잭션(223)이 시작된다. 바우처(154)가 관리자에게 반환되면 실제로 트랜잭션이 완료된 것이다. 바람직한 실시예에서 바우처(154)는 소각된다.

플랫폼에서 추가 거래가 무엇이든, 예를 들어, 유저(111)가 FNFT의 일부를 다른 유저에게 판매하는 경우, 유틸리티 토큰만 실제로 손을 바꿀 것이며, 변환 토큰(A1)은 이 변환 토큰과 특정 자산의 연결을 인증하는 발행인의 보관에 남아 있으며, 각각의 유틸리티 토큰의 고유 번호는 플랫폼 데이터베이스(160)의 변환 토큰(A1)과 연결된 상태로 유지된다.

관리자(101)는 토큰을 발행하고 소각할 수 있는 플랫폼의 유일한 플레이어이자 권한자이다. 후술하는 바와 같이, 바우처로 사용된 기록 토큰만이 소각될 수 있다. 다른 모든 토큰은 효과가 소멸될 수만 있고 파기되지는 않는다.

도 3에서, 일부 애플리케이션에서, 유저는 동일한 자산과 관련된 FNFT의 수를 더 늘려야 할 수 있다.

예를 들어, 자산은 유저가 소유한 특허 출원일 수 있으며, FNFT는 출원을 진행하기 위해 유저가 지출한 금액을 반영한다.

그러한 예에서, 발행인은 특허 출원을 담당하는 법률 회사 또는 특허 대리인이다. 이 예에 따르면, 유저가 특허 출원 진행에서 특정 서비스에 대해 발행인에 지불할 때마다 유저는 진행 비용을 조달하기 위해 시장에서 추가로 거래할 수 있는 FNFT를 얻는다.

따라서, 시간이 지남에 따라 증가하는 진행 비용의 지출에서, 예를 들어, 법무법인이 특허청의 거절에 대응할 각각의 경우에서, 유저가 획득한 FNFT의 수도 증가하지만 기본 자산, 즉 특허 출원은 여전히 동일하다.

이러한 예에 따르면, 특허 출원은 발행인의 데이터베이스(260)에서 고유하게 식별된 변환 토큰(A1)과 연관된다.

동일한 변환 토큰에 추가 유틸리티 토큰을 추가하는 것은 변환 토큰에 대한 유틸리티 토큰의 초기 연관과 유사한 방법을 따른다.

따라서, 유저(111)는, 예를 들어, 5개의 추가 FNFT가 추가되는, 요청(311)을 발행인(102)으로 전송한다. 이전과 같이, 애플리케이션에 따라, 요청(311)은 제안을 포함할 수 있고 협상 메커니즘을 개시할 수 있다.

합의가 이루어지면, 발행인(102)은 관리자(101)과 트랜잭션(321)을 시작한다. 이 때에, 발행인은 지갑(251)으로부터 관리자(5)에 이 유틸리티 토큰이 관련될 변환 토큰(A1)과 함께 유틸리티 토큰(151)을 전송한다.

수신 시, 관리자(101)은 고유 식별자(A1)가 포함된 변환 토큰(152)을 고유 식별자(Y)가 있는 바우처(154)와 함께 발행인으로 되돌려 보내며, 5개의 유틸리티 토큰 각각에 고유 식별자 25 내지 29를 부착하고, 데이터베이스(160)를 업데이트하여 5개의 유틸리티 토큰을 고유 식별자 바우처(Y) 뿐만 아니라 고유 식별자(A1)가 있는 변환 토큰에 연결한다.

트랜잭션을 통해(322), 유저(111)는 발행인으로부터 고유 식별자(Y)가 있는 바우처(154)를 수신하며, 트랜잭션 통해(323), 유저(111)는 바우처(154)를 이제 25 내지 29로 식별되고 고유하게 정의된 변환 토큰(A1)과 연관된 5개의 유틸리티 토큰에 대한 관리자(101)과 교환한다.

바우처(154)는 소각되며, 유저(111)는 이러한 새로운 FNFT를 시장에서 거래할 수 있다. 다시 한번, 변환 토큰은 EMIITTER가 관리하며, 새로운 FNFT는 발행인 데이터베이스(260)를 통해 동일한 자산에 연결된다.

일부 구성에서, FNFT의 기본 자산은 시간이 지남에 따라 또는 실제 세계에서 발생하는 특정 이벤트 발생 시 상태가 변경될 수 있다. 유틸리티 토큰 및 FNFT를 관리하는 수탁자로서, 발행인은 이러한 변경 사항을 FNFT에 반영하기 위한 조치를 취해야 한다.

이를 위해, 기본 자산이 특허 출원인 경우를 예로 들면, 어느 시점에서 특허가 부여된다. 따라서, 기본 자산은 더 이상 특허 출원이 아니라 특허이다.

이러한 변경이 FNFT에 반영되기 위해서는, 발행인(102)은, 발행인의 데이터베이스(260)에 있는 자산과 관련된 변환 토큰을 전송함으로써, 관리자(101)과 트랜잭션(421)을 시작한다.

응답으로, 관리자는 고유 식별자(B7)가 있는 추가 변환 토큰과 함께 고유 식별자(A1)가 있는 변환 토큰을 다시 보내며, 이 새로운 변환 토큰을 플랫폼 데이터베이스(160) 내의 다른 변환 토큰 상에 기록한다. 따라서, 이 예에서 B7로 식별된 변환 토큰은 이미 A1으로 식별된 변환 토큰의 영향을 받는 모든 유틸리티 토큰에 영향을 미친다.

발행인은 데이터베이스(260)에서 이 변환 토큰(B7)에 예를 들어, "특허 부여됨"이라는 새로운 상태를 연관시키는 데이터베이스를 업데이트한다.

상태의 추가 변경은 플랫폼 데이터베이스(160)의 파일 맨 위에 있는 변환 토큰으로 트랜잭션(421)을 시작하는 것과 동일한 방식으로 수행된다.

예를 들어, 기본 자산의 상태가 "부여됨"에서, 예를 들어, 추가로 "소송 중"으로 변경되는 경우, EMITER는 스택의 최상부에 변환 토큰을 전송할 것이며, 즉, B7 및 관리자는 플랫폼 데이터베이스(160)의 스택의 최상부에 기록될 고유하게 식별된 새로운 변환 토큰과 함께 이를 다시 전송한다. 따라서, 상태 변경은 항상 스택의 최상부에 있는 변환 토큰에 영향을 미친다.

모든 변환 토큰은 발행인의 관리하에 남아 있다.

도 5에서, 개의 변환 토큰(152)이 A1을 식별한 초기 상황(500)에서 시작한다. B7 및 C9은 유틸리티 토큰 배열 위에 적재된다. 각각의 변환 토큰은 FNFT 또는 기본 자산의 상태 변경에 대응하며, 전술한 변환 토큰 중 하나 이상이 소멸될 수 있고, 따라서 소멸되지 않은 스택에서 상위 변환 토큰에 대응하는 상태로 FNFT를 되돌란다.

이를 위해, 발행인(102)은 트랜잭션을 연속 변환 토큰 배열로 전송하여 관리자(101)과의 트랜잭션을 시작한다. 이러한 변환 토큰 N개가 관리자로 전송되면, 관리자는 킬러 토큰이라고 하는 N-1 특정 변환 토큰(552)을 다시 보내며, ADMN은 킬러 토큰을 스택의 최상부에서 시작하는 변환 토큰과 연관시킨다.

도 5의 예에서, 발행인(102)은 플랫폼 데이터베이스의 초기 상황(500)에 따라 B7 및 B7 상부에 있는 C9을 식별하는 2개의 변환 토큰(152)을 전송한다. 관리자는, 새로운 상황(501)에 표시된 바와 같이, 추가로 킬러 토큰(552)을, 대응하는 스테이터스를 소멸시키고 변환 토큰(B7)의 상태로 되돌리는, C9으로 식별된, 스택의 최상부에 있는 변환 토큰과 연관시킨다.

따라서, 원칙적으로, 발행인이 N개의 변환 토큰을 전송하여 관리자와 트랜잭션을 시작하면, 각각은 레벨 L에서 레벨 L+N까지 서로 스택에 있고, L+N은 스택 상부의 레벨이며, 관리자는 N-1 킬러 토큰을 다시 보내고 이 킬러 토큰을 레벨 L+N에서 포함된 레벨 L+1로의 (N-1) 변환 토큰에 연관시킨다. 따라서, 이 업데이트 후 FNFT의 상태는 레벨 L의 변환 토큰 상태로 되돌아간다.

이 실시예에서, 킬러 토큰은 고유 식별자를 갖지 않는다.

도 5의 메커니즘을 사용하여, 제1 변환 토큰을 제외한 스택의 모든 변환 토큰은 킬러 토큰에 의해 각각 소멸될 수 있다.

제1 변환 토큰은 이 제1 변환 토큰이 유틸리티 토큰을 FNFT로 전환하기 때문에 특별하다.

도 6에서, 초기 상황(600)에서 시작하면, 발행인(102)은, 킬러 토큰(552)과 함께 여기에서 A1으로 식별된 제1 변환 토큰(152)을 전송함으로써, 관리자(101)과 트랜잭션(621)을 시작한다.

수신시, 관리자는 킬러 토큰을 되돌려 보내고 킬러 토큰을 새로운 상황(601)으로 이어지는 제1 변환 토큰에 연관시킨다.

적용에 따라, 관련 유틸리티 토큰은 가치를 잃고 더 소각되거나 특정 가치를 유지하고 그대로 유지될 수 있다.

본 발명의 방법은 많은 상황에서 사용될 수 있고, FNFT를 처음 소유할 수 있는 유저의 권리는 FNFT가 원산지를 보증해야 하는 경우 제3자에 의해 확인되고 입증되어야 한다. 위의 예의 발행인에서, 수탁자로서, 자산의 출처와 자산을 소유할 수 있는 유저의 권리를 인증한다.

다양한 트랜잭션의 트리거링은 사람의 결정의 결과일 수 있지만 완전히 자동화되거나 주어진 상황에서 머신에 의해 트리거될 수도 있다.

예로서, 전기 공급업체가 지붕에 태양광 패널을 설치하는 소비자의 전기를 다시 구매하여 태양광 패널 설치를 촉진하는 것이 일반적이다.

지붕에 설치된 태양광 패널이, 인버터를 통해 그리드에 주입되는, 전기를 생산하고 있으며, 전기는 다른 소스에서 나오는 전기와 혼합된다.

미터는 설치 및 기본 방식으로 그리드에 주입되는 전기량을 측정하며, 이는 보너스를 포함하는 것과 같이 더 복잡할 수 있고, 주입된 전기는 설치에 대한 투자를 상환할 수 있는 유저의 전기요금에서 차감된다.

이러한 방식에서, 소비자는 자신이 생산하는 전기를 직접 소비하지 않으며 태양광 패널에서 실제로 생산하는 전력 및 에너지에 제한을 받지 않는다.

그러나, 이러한 시스템은 루프탑 태양광 패널에 의해 생성된 전기가 저전압 네트워크의 그리드에 주입되고 상당한 손실 없이 장거리로 운반될 수 없다는 점에서 몇 가지 결점을 갖는다.

한편으로, 평방 마일을 커버하는 것과 같은 거대한 태양광 발전소는 훨씬 더 나은 수율과 용량 요소로 엄청난 양의 전기를 생산할 수 있으며, 전기는 고전압으로 변환되어 장거리로 전달될 수도 있다.

그러나, 이러한 거대한 태양광 발전소는 막대한 투자를 필요로 한다.

발명의 시스템 및 방법은 개인이 그러한 거대한 태양광 발전소에 투자하고 마치 태양광 패널이 발전소의 지붕에 있는 것처럼 여전히 소비 감소의 이점을 취하도록 하기 위해 사용될 수 있다.

이는 개인이 그러한 거대한 설비에 자금을 조달할 수 있게 하고, 예를 들어 콘도미니엄에 살고 있는 개인이 지붕을 소유하지 않은 상태에서 태양열 전기에 투자할 수 있게 한다.

그러한 실시예에서, 태양광 발전소의 에너지 출력은 측정될 수 있으며 이러한 생산은 플랫폼의 유틸리티 토큰으로 자동 변환된다. 변형에서, 전기 공급업체는 복수의 태양광 발전소를 소유할 수 있으며 태양광 생산의 총량은 유틸리티 토큰으로 변환된다.

예를 들어, 투자한 유저 Bob이 전체 태양광 발전 시스템의 0.01%는 하루 또는 일주일 또는 한 달에 N.kWh를 소비하며, N 토큰도 생성되어 지갑으로 전송된다.

주어진 기간이 끝나면 자동으로, 예를 들어, 매일 같은 날 태양광 발전소 생산에 대응하는 유틸리티 토큰을 보유하고 있는 전기 공급업체가 제어하는 발행인과 Bob 사이에 트랜잭션이 트리거된다.

예시적이고 비제한적인 실시예로서, Bob은 오늘의 자체 전기 소비 토큰을 발행인에 전송하여 트랜잭션을 트리거한다. 이 유형의 제1 트랜잭션 동안, 발행인은 관리자이 관리자에게 M개의 유틸리티 토큰을 전송하는 트랜잭션을 트리거한다. 여기서 M은 CxNx0.01%일 수 있으며, C는 총 전기 생산량에 대한 그날의 태양광 생산량의 비율이고, N은 동일한 날 Bob의 전기 소비량이며, 0.01%는 태양열 농장에 대한 Bob의 투자 지분이다. 이러한 유틸리티 토큰은 변환 토큰과 연결될 때 FNFT가 되며, 이들 변환 토큰은 프로젝트에 대한 Bob의 투자 높이와 직접 연관된다.

본 발명의 방법을 사용하여 동일한 변환 토큰에 추가 소비가 추가될 수 있다.

전체 거래가 완료되면, Bob은 태양 에너지 개발 및 저탄소 전기 생산에 대한 참여를 반영하는 FNFT를 얻는다. 예를 들어, Bob은 이러한 FNFT를 사용하여 전기 요금을 상쇄하거나, 그러한 시장이 존재하는 경우 탄소 배출량을 상쇄하려는 회사에 이러한 FNFT를 판매할 수 있다.

이러한 FNFT는 제한된 수명(예를 들어 1년)을 가질 수 있다. 따라서, 1년 후에, 킬러 토큰은 본 발명의 방법에 따라 생성되고 Bob에 연결된 변환 토큰에 적용되어 변환 토큰 및 모든 관련 FNFT를 한 번에 소멸시킨다.

본 발명의 시스템 및 방법의 적용의 다른 예는 메타 유니버스의 가상 아이템에 원산지 보증, 즉 브랜드를 부착하는 것이다. 이러한 가상 아이템은 가상 의상일 수도 있고, 자동차와 같은 가상 객체일 수도 있지만, 메타 유니버스에서 제공되는 서비스일 수도 있다. 이러한 가상 아이템은 본 발명의 시스템에서 유틸리티 토큰에 연결될 수 있다. 본질적으로, 의상이나 물건 또는 서비스에 대한 유틸리티 토큰 사이에는 차이가 없다. 차이점은 발행인 또는 수탁자 및 특정 변환 토큰의 연결에 의해 생성된다.

따라서, 변환 토큰 내 둘 다 특정 브랜드가 있는 특정 항목으로 순수 또는 블랭크 유틸리티 토큰이 식별된다.

대안적으로, 스택 하부에 있는 제1 변환 토큰은 여러 유틸리티 토큰을 식별하거나 메타 유니버스의 특정 종류의 항목과 연관될 수 있다. 예를 들어, 이 제1 변환 토큰의 영향을 받는 각각의 유틸리티 토큰은 가상 티셔츠 배치로 식별된다.

제1 변환 토큰 상부에, 제2 변환 토큰이 기본 배치를 특정 브랜드에 연관시킬 수 있다.

따라서, 무한하고 잠재적으로 무한한 수의 블랭크 유틸리티 토큰이 주조되고 필요할 때 즉시 적절한 브랜드가 있는 적절한 항목으로 변환될 수 있다.

본 발명의 방법 및 시스템의 적용의 다른 예로서, 도 7은 특허 출원의 FNFT를 이루는 토큰 조합의 예시적인 개선을 나타낸다.

도 1로 돌아가서, 특정 실시예에 따르면, 본 발명의 시스템은 플레이어들 사이에 서비스 제공자(103)를 포함한다. 서비스 제공자는 본 발명의 방법에서 에스크로의 역할을 하고 실제로 두 유저(111, 112) 사이의 트랜잭션에서 에스크로 역할을 하며 FNFT를 포함한다.

서비스 제공자는 유저(최초 유저라고도 함)가 자신의 FNFT를 구매하는 사람에게 보다 정교한 제안을 제안할 수 있도록 한다.

최초 유저는 발행인과의 트랜잭션을 통해 초기에 FNFT를 소유한 유저이다.

결과적으로, 도 2와 3의 유저는 최초 유저이며, 최초 유저는 일반적으로 FNFT 기본 자산의 소유자이다.

예로서, 이렇게 개선된 제안은 주식이 소유자에게 배당금을 제공하는 것처럼 구매자에게 배당금을 제공한다.

도 8, 예시적인 실시예에 따르면 최초 유저인 유저(111)는 보유하고 있는 15개의 FNFT 중, 예를 들어, 3개의 FNFT와 같이 FNFT 보유자에게 초기 구매 가격의 x%에 해당하는 로열티를 지불하는 것과 같은 서비스 제안과 함께 FNFT의 일부를 판매 제안하고자 한다.

유저(111)의 FNFT에 해당하는 유틸리티 토큰(151)은 각각 1에서 10 및 25에서 29 범위의 레이블로 고유하게 식별된다.

이러한 유틸리티 토큰 각각은 플랫폼 데이터베이스(160)에서 2개의 변환 토큰(152)과 연관되며, 2개의 변환 토큰(152) 각각은, 변환 토큰 스택의 제1 변환 토큰 상에서, 제1 변환 토큰에 대한 A1 레이블과 제2 변환 토큰에 대한 B7 레이블로 각각 고유하게 식별된다.

바람직한 실시예에 따르면, 서비스 토큰은 아직 최초 유저 지갑에 있는 FNFT에만 연결될 수 있다.

본 예시적인 실시예에 따르면, 유저(111)는 서비스 제공자(103)에게 요청(811)을 보낸다. 요청은 서비스에 대한 설명, 기본 자산, 관련된 FNFT 수 및 유저가 FNFT 관리를 위해 수탁자로 사용하는 발행인으로 구성된다.

협상이 있을 수 있다. 유저와 서비스 제공자가 합의에 도달하면, 유저와 서비스 제공자 간에 트랜잭션(821)이 시작된다. 예로서, 이러한 거래는 유저가 서비스와 연결하고자 하는 FNFT(유틸리티 토큰), 서비스 개발 수수료 및 예치금으로 구성된다.

수신시, 서비스 제공자는 발행인에게 요청을 보내고, 발행인(102)는 유저(111)가 기본 자산의 올바른 소유자인지 확인한다.

발행인 및 서비스 제공자는 일련의 트랜잭션을 시작한다. 예시적인 실시예에 따르면, 서비스 제공자가 발행인에게 예치금을 보낸다. 예치금을 수령하면 발행인은 기본 자산에 대응하는 변환 토큰을 서비스 제공자에 보낸다.

바람직한 실시예에 따르면, 서비스는 최신 변환 토큰에만, 즉, 스택의 최상부에 있고 킬러 토큰에 의해 소멸되지 않는 변환 토큰에만 연결될 수 있다.

변환 토큰을 수신하면, 여기서 B7이라고 표시된 변환 토큰은 최신 버전이다. 서비스 제공자는 서비스 토큰 목업(853)을 준비하고 관리자(101)에게 변환 토큰(152) 전송하는 관리자와 트랜잭션(823)을 시작한다. 유틸리티 토큰은 서비스 및 서비스 토큰 목업과 관련이 있다.

수신 시, 관리자는 목업의 적합성을 확인하고, 플랫폼 데이터베이스(160)에서 연관된 고유 식별자(α1)가 있는 서비스 토큰(153)을 발행한다. 서비스 토큰(α1)과 변환 토큰 및 3개의 유틸리티 토큰(여기서는 27 내지 29로 레이블이 지정됨)이다.

관리자는 고유하게 식별된 서비스 토큰(153)을 기록 토큰(154) 또는 고유하게 Z로 라벨링된 바우처 및 3개의 유틸리티 토큰과 함께 서비스 제공자(103)로 전송한다.

서비스 토큰은 서비스 제공자의 관리하에 남아 있다.

서비스 제공자는 바우처(154)를 발행인에 전송한다. 발행인은 바우처를 관리자에게 전송하며, 관리자는 변환 토큰을 발행인에 반환하고, 수신 시, 발행인은 예치금과 함께 유틸리티 토큰을 유저(111)에게 돌려주는 서비스 제공자에게 예치금을 돌려준다. 관리자이 바우처(154)를 소각한다.

이제 27에서 29로 표시된 각각의 유틸리티 토큰(151)은 서비스 토큰(α1)과 연관되며, 그러한 토큰의 소유자는 서비스와 관련된 로열티를 요청할 수 있다.

이전 실시예에서, 서비스 토큰은 시장에서 이러한 토큰에 대한 트랜잭션이 발생하기 전에 유틸리티 토큰에 연결된다.

대안적으로, 서비스 토큰은 대응하는 유틸리티 토큰이 최초 유저와 다른 유저 간에 손을 바꿀 때만 유틸리티 토큰에 첨부될 수 있다.

도 9에서, 단순화된 계획에서, 최초 유저(111)와 유저(112)가 협상(911)을 통해 서비스 가격 및 조건에 동의하면, 최초 유저(111)는 유저(112)가 구매하기로 약속한 유틸리티 토큰을 전송하는 서비스 제공자와 트랜잭션(821)을 시작한다.

서비스 제공자(103)는 선택된 유틸리티 토큰(들)과 함께 관리자(101)으로 전송되는 서비스 토큰 목업(853)을 준비한다.

수신 시, 관리자는 목업에 따라 고유 식별자로 서비스 토큰을 생성하며, 대응하는 서비스 토큰, 유틸리티 토큰 및 스택 상부에 있는 대응하는 변환 토큰을 연관시킨다.

관리자는 바우처(154)와 함께 서비스 제공자의 관리에 있는 서비스 토큰(153)을 되돌려 보낸다.

이용자(112) SERVICE PROVIDER가 대금을 결제한 경우, 유저(112)가 대금을 지불하면, 서비스 제공자는 유저에게 바우처를 돌려 보낸다.

서비스 제공자는 유저(112)로부터 받은 금액에서 서비스 수수료를 뺀 금액을 최초 유저(111)에 이체하며, 유저(112)는 유틸리티 토큰과 교환하여 관리자에게 바우처를 보낸다.

서비스 토큰은 특정 FNFT 및 변환 토큰에 연결된 상태로 유지된다. 서비스 토큰은 연결된 변환 토큰이 킬러 토큰에 의해 소멸될 때까지 시행 가능하다.

서비스 토큰은 최초유저가 FNFT를 보유한 모든 유저에 대한 약속이다. 또한, 예를 들어, 기본 자산의 라이선스와 같이 서비스 제공자 및/또는 최초 유저에게 서비스 요금을 지불하겠다는 FNFT 보유자의 약속을 포함할 수 있다.

서비스 제공자는 에스크로 역할을 하고, 애플리케이션에 따라, 최초 유저가 유저에게 제공하거나 유저가 최초 유저에게 지불한 대응하는 것을 수집한 후 적법한 수신자에게 배포한다.

본 발명의 시스템 및 방법은 여러 이점을 제공한다. 신뢰할 수 있는 제3자 역할을 하는 서비스 제공자 및 발행인의 의미를 통해, 이는 존재, 현실 세계에서 FNFT를 뒷받침하는 기초 자산의 실제 상태 및 실제 소유권에 대한 확신을 가져다준다. 이는 특허, 특허 출원 또는 상표와 같은 IP 권한으로 백업된 FNFT에 특히 유용하다.

상태 및 서비스의 변경은 FNFT에 반영되며, 이러한 FNFT가 많은 수의 유저에게 배포되더라도 항상 서로 위에 토큰을 추가하고 관련된 모든 FNFT의 상태를 한 번에 변경한다. FNFT는 화폐이지만 소각되지 않으며 일시적으로 바우처처럼 작동하는 토큰만 소각될 수 있다. 이는 완전한 추적 가능성을 따른다.

Claims (10)

1. 블록체인 네트워크 연결 노드를 포함하며 노드들 사이의 트랜잭션(transaction)을 기록하는 레저(ledger)를 포함하는 시스템을 구현하는, 분할 대체 불가능 토큰(Fractional Non Fungible Tokens, FNFT)의 상태를 생성하고 추적하며 변경하기 위한 방법으로서, 상기 시스템은:
   - 상기 블록체인 상부에 구축된 플랫폼;
   - 상기 플랫폼 및 상기 블록체인 네트워크에 연결되며, 권한자(Authority), 유저(User) 및 수탁자(Trustee)를 포함하는 복수의 컴퓨터;
   를 포함하고,
   - 상기 플랫폼은 유틸리티 토큰, 및 변환 토큰, 및 기록 토큰, 및 상기 플랫폼에 연결된 컴퓨터들 간의 토큰과 관련된 트랜잭션이 수행될 경우 상기 블록체인의 하나 이상의 노드와 관련된 동작을 트리거하도록 구성되며, 스마트 계약으로 알려져 있는 프로그램을 포함하며;
   상기 방법은:
   - 유저가 수탁자에게 요청을 전송함으로써, 수탁자로부터 N개의 FNFT를 획득하기 위해 트랜잭션을 트리거하는 단계;
   - 상기 요청의 수신 시, 수탁자가 권한자에게 N개의 유틸리티 토큰을 전송하면서 권한자와의 트랜잭션을 시작하며, 권한자로부터 제1 변환 토큰 및 하나의 기록 토큰을 수신하는 단계;
   - 상기 N개의 유틸리티 토큰 각각 및 상기 제1 변환 토큰 및 상기 기록 토큰을 고유 식별자로 식별하는 단계;
   - 상기 제1 변환 토큰 및 상기 기록 토큰의 식별자와 관련하여, 상기 N개의 유틸리티 토큰의 고유 식별자를 상기 플랫폼의 데이터베이스에 등록하는 단계;
   - 수탁자가 지불할 경우, 유저에 의해, 상기 기록 토큰을 유저에게 전달하는 단계;
   - 유저-여기서 유저는 상기 기록 토큰을 제공함-와 권한자-여기서 권한자는 상기 N개의 식별된 유틸리티 토큰을 유저에게 전달함- 사이의 트랜잭션을 시작하는 단계;
   - 상기 트랜잭션이 완료되면 상기 기록 토큰을 파기하는 단계;
   를 포함하는 것을 특징으로 하는 방법.
2. 제1항에 있어서,
   - 유저가, 동일한 제1 변환 토큰과 관련된 M개의 추가 FNFT를 획득하기 위해, 수탁자에게 요청을 보냄으로써 수탁자와의 트랜잭션을 트리거하는 단계;
   - 상기 요청의 수신 시, 수탁자가 권한자-여기서 권한자는 상기 제1 변환 토큰을 새로운 기록 토큰으로 되돌려줌-에게 상기 제1 변환 토큰과 함께 M개의 유틸리티 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;
   - 상기 새로운 기록 토큰뿐만 아니라 상기 M개의 유틸리티 토큰 각각을 고유 식별자로 식별하는 단계;
   - 상기 제1 변환 토큰 및 상기 새로운 기록 토큰의 상기 식별자와 관련하여, 상기 M개의 유틸리티 토큰의 상기 고유 식별자를 상기 플랫폼의 데이터베이스에 등록하는 단계;
   - 수탁자가 지불할 경우, 유저에 의해, 상기 새로운 기록 토큰을 유저에게 전달하는 단계;
   - 유저-여기서 유저는 상기 새로운 기록 토큰을 제공함-와 권한자-여기서 권한자는 상기 M개의 식별된 유틸리티 토큰을 유저에 제공함- 간의 트랜잭션을 시작하는 단계;
   - 상기 트랜잭션이 완료되면 상기 새로운 기록 토큰을 파기하는 단계
   를 더 포함하는 것을 특징으로 하는 방법.
3. 제1항 또는 제2항에 있어서,
   - 수탁자가 유틸리티 토큰 없이 권한자에게 상기 제1 변환 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;
   - 권한자가 고유 식별자가 있는 상기 제1 변환 토큰과 제2 변환 토큰을 다시 전송하는 단계;
   - 상기 제1 변환 토큰의 식별자와 관련하여, 상기 제2 변환 토큰의 상기 고유 식별자를 상기 플랫폼의 상기 데이터베이스에 등록하는 단계;
   를 더 포함하는 것을 특징으로 하는 방법.
4. 제3항에 있어서,
   - 수탁자가 유틸리티 토큰 없이 권한자에게 상기 제2 변환 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;
   - 권한자가 고유 식별자가 있는 상기 제2 변환 토큰 및 제3 변환 토큰을 다시 전송하는 단계;
   - 상기 제2 변환 토큰의 상기 식별자와 관련하여 그리고 상기 제1 변환 토큰의 상기 식별자와 관련하여, 상기 플랫폼의 데이터베이스에 상기 제3 변환 토큰의 상기 고유 식별자를 등록하고 스택(stack)을 생성하는 단계;
   를 더 포함하고,
   마지막 변환 토큰이 이전의 토큰들에 적재되며, 상기 마지막 변환 토큰이 상기 스택의 최상부에 있고, 상기 제1 변환 토큰이 상기 스택의 최하부에 있으며, 각각의 변환 토큰은 상기 스택의 최하부의 레벨 0에서 상기 스택의 최상부의 최상위 레벨로 증가하는, 상기 스택 내의 레벨을 갖는 것을 특징으로 하는 방법.
5. 제4항에 있어서,
   - 수탁자가 N개의 트랜잭션 토큰의 세트를 권한자에게 전송하면서 권한자와의 트랜잭션을 시작하는 단계-여기서 N>2이고, 상기 세트의 상기 변환 토큰 각각은 상기 스택 내에서 0 이상인 L1으로 넘버링된 하위 레벨에서부터 L2=L1+(N-1)인 상위 레벨 L2까지의 연속적인 레벨을 가짐-;
   - 권한자가 킬러 토큰(Killer Token)-여기서 각각의 킬러 토큰은 레벨 L2에서 레벨 L0+1까지 하나의 변환 토큰에 영향을 받음-으로 지칭되는 특정 유형의 (N-1) 변환 토큰을 되돌려 전송하는 단계;
   - 각각의 킬러 토큰의 각각의 변환 토큰과의 연관(association)을 상기 플랫폼의 상기 데이터베이스 내에 등록하는 단계
   를 더 포함하는 것을 특징으로 하는 방법.
6. 제5항에 있어서, 상기 제1 변환 토큰을 제외한 모든 변환 토큰은 상기 데이터베이스 내의 킬러 토큰과 연관되며, 상기 방법은:
   - 수탁자가 권한자에게 킬러 토큰을 갖는 상기 제1 변환 토큰을 전송하면서 권한자와의 트랜잭션을 시작하는 단계;
   - 수신 시, 권한자가 상기 킬러 토큰의 상기 제1 변환 토큰에 대한 연관을 상기 데이터베이스에 등록하는 단계
   를 더 포함하는 것을 특징으로 하는 방법.
7. 제4항에 있어서, 에스크로(Escrow) 및 서비스 토큰(Service Tokens)을 더 포함하는 시스템을 구현하며, 상기 방법은:
   - 권한자가 상기 에스크로 요청 시 고유 식별자로 서비스 토큰을 생성하는 단계;
   - 상기 스택 상의 상기 최상위 변환 토큰 및 정해진 수의 유틸리티 토큰과 연관된 상기 서비스 토큰을 상기 플랫폼의 상기 데이터베이스 내에 등록하는 단계
   를 더 포함하는 것을 특징으로 하는 방법.
8. 제7항에 있어서, 에스크로는 서비스 토큰과 연관된 유틸리티 토큰의 임의의 트랜잭션에 대한 에스크로서의 역할을 하는 것을 특징으로 하는 방법.
9. 제7항에 있어서, 권한자에 의한 상기 서비스 토큰의 생성은 에스크로에 의해 준비되어 권한자에게 전송되는 목업 서비스 토큰(mockup Service Token)을 기반으로 하는 것을 특징으로 하는 방법.
10. 제3항에 있어서, 상기 시스템은 한 종류의 N개의 가상 아이템으로 구성된 메타 유니버스를 포함하며, 상기 제1 변환 토큰은 상기 한 종류를 상기 N개의 유틸리티 토큰과 연관시키고, 상기 제2 변환 토큰은 하나의 브랜드를 상기 N개의 유틸리티 토큰과 연관시키는 것을 특징으로 하는 방법.

Images