JP2023068041A - ブロックチェーンベースユニバーサルトークン化システム - Google Patents

Abstract

【課題】 本発明は、ピアツーピア分散型台帳上のトークンに関連するトークンの作成、リディーム及び移転に関する方法である。【解決手段】 この方法は、リディームスクリプト中のトークンに関連するメタデータを含み、リディームスクリプトは、ピアツーピア分散型台帳上のトランザクションに関連する。本発明の１つの側面は、ビットコイン、及びリディームスクリプトのハッシュのような、量に関連するアウトプット（ＴｘＯ）を有するブロックチェーントランザクション（Ｔｘ）を生成するステップを含む、トークンの発行及び／又は移転の方法を提供する。リディームスクリプトは、同様にトークンを含むメタデータを含む。トークンは、トークン化エンティティの表現、又は参照である。リディームスクリプトは、少なくとも１つの（好ましくは２つ以上の）公開暗号鍵も含む。メタデータは、暗号鍵に対する位置として基礎をなすブロックチェーンプロトコル中に指定された位置でリディームスクリプト中に提供される。【選択図】 図１

Description

本開示は一般に、アセット（asset）の制御及び／又は移転、又はアセットの所有権（ownership）の移動に関するソリューションに関連する。特に、所有権を生み出し、移動させ、アセットを表すトークンをリディームする（redeeming：換金する、償還する）方法に関連する。本開示は、例えば、ビットコイン（Bitcoin）ブロックチェーンなどのピアツーピア分散型台帳上のトランザクション（transactions）に関連するトークンを作成する特定のアプリケーションを有する。トークンは、契約上の権利、スマートコントラクト（smart contract：スマートな契約）又はアセットの他の形式を代表することができる。

商取引（commercial transactions）は、財産権の移動を含んでも良い。そのような権利は、不動産、又は個人的財産（有形及び無権の財産の両方を含む）を含むことができる。さらに、当事者間の契約は、両当事者を拘束する契約上の権利も含んでも良い。デジタルエコノミーにおいて、タイムリーな方法で、広い範囲で、実行されるトランザクションに対する期待があり得る。この期待は実際的な制限と共に、伝統的な形態の移転財産、例えば契約を表す書類の物理的配送、有価証券など、又は価値のない有形資産自体を意味する。より現代において、ブロックチェーンは、デジタルアセットの移転（transfer）に対して使用されてきている。

ブロックチェーンは、順々にトランザクションを作り上げるブロックを作り上げる、コンピュータベースの非中央集権化、分散化、ピアツーピアシステムとして実装される、電子台帳である。各トランザクション（Ｔｘ）は、ブロックチェーンシステムにおいて参加者間のデジタルアセットの制御の移動を符号化するデータ構造である。各ブロックには、前のブロックのハッシュが含まれており、そのブロックが連鎖して、ブロックチェーンに最初から書き込まれたすべてのトランザクションの永続的な変更不可能なレコードが作成される。トランザクションは、それらの入力及び出力の中に組み込まれるスクリプト（script）として知られる小さいプログラムを含み、トランザクションの出力にどのように誰によってアクセスできるかを指定する。ビットコインプラットフォーム上で、これらのスクリプトは、スタックベーススクリプト言語で書かれる。

ブロックチェーンに対してトランザクションが書かれるためには、「検証され（validated）」なければならない。ネットワークノード（マイナ（miners））は、各トランザクションが有効で、無効なトランザクションがネットワークから拒否されることを確実にするためにワークを実行する。ノードにインストールされたソフトウェアクライントは、そのロッキング及びアンロッキングスクリプトを実行することによって未使用のトランザクション（ＵＴＸＯ）上でこの検証ワークを実行する。ロッキング及びアンロッキングスクリプトの実行が、真（TRUE）と評価された場合、トランザクションは有効で、トランザクションは、ブロックチェーンに対して書かれる。したがって、トランザクションをブロックチェーンに書き込むには、ｉ）トランザクションを受信する最初のノードによって検証されなければならない－トランザクションが検証された場合、ノードはネットワーク内の他のノードにリレーし、ii）マイナによってビルドされた新しいブロックに追加され、iii）採掘され、すなわち過去のトランザクションの公的台帳に追加される。

暗号化の実装では、ブロックチェーンテクノロジが最も広く知られているが、ビットコインの暗号化セキュリティシステムと新しいシステムを実装するためにブロックチェーンに記憶できるデータの両方の利用を検討し始めている。分野に限らず自動化タスク及びプロセスに対して、ブロックチェーンが使用することができれば、非常に有利であり得る。そのようなソリューションは、そのようなアプリケーションにおいてより用途が広いと同時に、ブロックチェーン（例えば、イベントや分散処理などの記録の永久の）の恩恵を利用することができるだろう。

現在の研究の１つの領域は、「スマートコントラクト」の実装に対してのブロックチェーンの使用である。これらは、機械読取可能コントラクト又はアグリーメントの条件実行を自動化するためにデザインされたコンピュータプログラムである。自然言語で書かれた伝統的な契約とは異なり、スマートコントラクトは、結果を生成するために入力を処理し、その結果に応じてアクションを実行させるルールを含む機械実行可能プログラムである。

ブロックチェーン関連の興味の別の領域は、ブロックチェーンを経由して実世界又は仮想のエンティティを表現する及び移動するための「トークン」（又は「色付きのコイン」）の使用である。潜在的にセンシティブ又は秘密の事項は、認識できる意味又は値を持たないトークンによって表現することができる。トークンは、したがって、アセットがブロックチェーンから参照されることを可能にする識別子として、使える。

本明細書に含まれる文書、行為、材料、装置、物品等の議論は、これらの事項のいずれか又はすべてが先行技術の基礎の一部を形成するか、又は本出願の各請求項の優先権の日前に存在していた本開示に関連する分野における共通の一般的知識であるとの自認であると捉えるべきではない。本明細書において、電子的、コンピュータベース、ピアツーピア、分散型台帳の全ての形式を含む用語、「ブロックチェーン」を使用する。これらは、制限されることなく、コンセンサスベースブロックチェーン及びトランザクションチェーン技術、許可される、非許可の台帳、共有台帳及びそれらの変形を含む。ブロックチェーン技術のもっと広く知られているアプリケーションは、ビットコイン台帳であり、一方で、他のブロックチェーン実装の提案及び開発も行われている。本明細書では、便宜と説明のためにビットコインを参照することができるが、本発明はビットコインブロックチェーンでの使用に限定されず、代わりのブロックチェーン実装及びプロトコルも本発明の範囲内に含まれることに留意すべきである。本明細書を通して、「含む（comprise）」という単語、又は「含む（comprises）」又は「含んでいる（comprising）」などの変形は、記載された要素、整数又はステップ、又は要素、整数又はステップのグループを含むことを意味すると理解され、整数又はステップ、又は要素、整数、又はステップのグループを除外するものではない。

添付請求項に定義される発明が提供される。本発明は、ブロックチェーン経由のアセット又は権利の安全な制御及び／又は移転に対するソリューションを提供することができる。追加として又代替として、アセット又は権利の所有権の制御及び／又は移動を可能とすることができる。これは、スマートコントラクト、又は実世界／物理アセットなどのデジタル又は仮想アセットでも良い。本発明は、この制御又は移動を容易にするトークン化技術を使用することができる。本発明は、暗号鍵の使用を包含する安全な方法で実行される移動を可能にすることができ、一方、基礎をなすブロックチェーンプロトコルの修正も必要としない。

本発明は、特に、電子転送のためのメモリ使用の強化された最適化、ハッシュ技術の使用によるセキュリティ及びデータの整合性の改善、信頼できる第三者の必要性の除去によるセキュリティの改善、及びデータの匿名性の向上を提供する。有利な点のこのリストは、制限はなく又は網羅的でもない。

本発明は、ブロックチェーン関連ソフトウェア及びプロトコルを実行するように構成されたコンピューティングノードを含む１つ以上のユーザ装置及び分散コンピュータシステム（ブロックチェーン）のような、異なる個別の別個のコンピュータベースのリソースの相互作用及び相互通信を必要とすることがあり得る。

本発明は、コンピュータ実装移転方法であって、
デジタルアセット（Ｂ１）に関連する出力（ＴｘＯ）とリディームスクリプトのハッシュ（Ｈ１）とを有するブロックチェーントランザクション（Ｔｘ）を生成するステップを含み、
前記リディームスクリプトは、
トークン化されたエンティティの表現、又はトークン化されたエンティティへの参照であるトークンを含むメタデータと、
少なくとも１つ（好ましくは２つ以上）の公開暗号鍵と、
を含む。
デジタル資産（Ｂ１）は、ビットコインなどの量（quantity：額）であっても良い。リディームスクリプトは、トランザクション出力ＴｘＯのロックスクリプト内に提供されても良い。メタデータは、暗号鍵の場所としてブロックチェーンプロトコルで指定された場所のリディームスクリプトに提供されても良い。この方法は、トランザクションＴｘをブロックチェーンに提示するステップをさらに含むことができる。実際には、トークンに関連して、暗号通貨（Ｂ１）がブロックチェーン上にロックされても良い。量（Ｂ１）は、出力ＴｘＯのロックスクリプトの要件を満たすロック解除スクリプトの提供時にのみ使用する（リディームする）ことができる。特に、ハッシュされると、ＴｘＯのロックスクリプトで提供されるハッシュと一致するリディームスクリプトを提示する必要がある。出力ＴｘＯのロックスクリプトは、トークン（メタデータ内）を含むリディームスクリプトのハッシュを構成するので、暗号通貨（Ｂ１）はトークンに関連付けられる。正しい解錠（リディーム）スクリプトを提示すると、暗号通貨（Ｂ１）の所有権は、リディームする当事者又はユーザに移転され、すなわち、それは費やされる。用語、「使う（spending）」、「移転する（transferring）」、「リディーミング（redeeming:換金する）」又は「所有権／制御を移転する（transferring ownership/control of）」は、本明細書中では、交換可能に使用しても良い。また、用語、「ユーザ（user）」は、人間のユーザ又は機械ベースリソースのいずれを指しても良い。公開鍵は、暗号鍵ペアを形成するために対応する秘密鍵と関連しても良い。対応する秘密鍵は、トランザクションアウトプットをロック解除するために必要であり、したがってデジタルアセット及び／又はその所有権の移転を可能にする。トークン化エンティティは、ブロックチェーン上に又はブロックチェーンから離れて記憶することができる。それは、（スマート）コントラクト又はある他の形式／タイプのアセット又はエンティティのようなデジタルアセットであり得る。トークンは、暗号鍵として、ブロックチェーンプロトコルと思われる、又はブロックチェーンプロトコルによって解釈されるようにリディームスクリプトによって提供することができる。したがって、基礎をなすブロックチェーンプロトコルは、リディームスクリプトにおいて提供されるトークン及び／又は他のメタデータの存在を知らなくても良い。しかしながら、メタデータは、本発明の処理に関係しているユーザによってトークンとして解釈され、使用され得る。したがって、本発明は、ブロックチェーンを介して暗号的に実施され安全な方法でユーザにデジタルトークンを発行することを可能にする実施形態又は態様を含むことができる。対応するシステムは、提供することができ、そのシステムは、上述の実施形態の方法を実行するように構成され、ブロックチェーンネットワーク及び関連するノードを含む。

本発明の追加の又は代替の表現、特徴又は実施形態が、これから提供される。本発明の１つ以上の態様又は実施形態に関連して説明される特徴は、１つ以上の他の態様又は実施形態に関連して使用することもできる。

本発明は、発行者（issuer）（Ｉ）によって第１のトークン（Ｔ１）を作成するコンピュータ実装方法を提供することができる。第１のトークン（Ｔ１）は、暗号化、電子的、移転可能なデジタルアセットの第１の量（Ｂ１）に関連することができる。

上述の方法の加えて又は代わりとして、方法は、以下のステップの１つ以上を含む：第１のトークン（Ｔ１）に対する第１のユーザ（Ａ）からのリクエストを、通信ネットワークを介して、受信することと、第１のユーザの公開鍵（Ｐ１Ａ）を決定することであって、前記第１のユーザの公開鍵（Ｐ１Ａ）は、第１のユーザの秘密鍵（Ｖ１Ａ）と暗号化ペアを形成する、第１のユーザの公開鍵（Ｐ１Ａ）を決定することと、前記第１のトークン（Ｔ１）に関連して暗号化され、電子的に移転可能なデジタルアセットの第１の量（Ｂ１）を割り当てることと、第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）を決定することであって、前記第１のリディームスクリプト（ＲＳ１）は、前記第１のトークン（Ｔ１）に関連付けられた情報を含む少なくとも第１のメタデータ（ＭＤ１）と、前記第１のユーザの公開鍵（Ｐ１Ａ）と、前記発行者（Ｉ）に関連付けられた第１の発行者の公開鍵（Ｐ１Ｉ）であって、前記第１の発行者の公開鍵（Ｐ１Ｉ）は、第１の発行者の秘密鍵（Ｖ１Ｉ）と暗号化ペアを形成する、第１の発行者の公開鍵（Ｐ１Ｉ）と、を含む、前記通信ネットワークを介して、第１のデータ出力（Ｏ１）をピアツーピア分散型台帳に送信することであって、前記ピアツーピア分散型台帳は、前記第１のユーザ（Ａ）への前記デジタルアセットの前記第１の量（Ｂ１）のトランザクションの表示と、前記デジタルアセット（Ｂ１）の前記第１の量に関連付けられ、前記第１のユーザ（Ａ）と前記発行者（Ｉ）とに関連付けられた前記第１のトークン（Ｔ１）を提供するための、第１のハッシュ（Ｈ１）とを含む、第１のデータ出力（Ｏ１）をピアツーピア分散型台帳に送信することとを含む。第１のリディームスクリプト（ＲＳ１）が、第１のトークン（Ｔ１）に関連する情報を含む第１のメタデータ（ＭＤ１）に少なくとも基づいている第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）を決定するステップと、前記第１のハッシュ（Ｈ１）を含む第１のデータ出力（Ｏ１）を前記通信ネットワークを介して送信することは、多くの利点を提供することを特徴とする方法である。第１に、トークンに関する情報がブロックチェーンのような公共台帳にしっかりと埋め込まれているので、信頼できる第三者の必要性を回避しながら、データ送信のセキュリティが提供される。なぜなら、取引当事者は、公に検証された方法でロックされた関連トランザクションの詳細に頼ることができるからである。また、トランザクションの匿名性が保持され、最初のリディームスクリプトがハッシュされるので、リディームスクリプトの対応するハッシュ値を変更することなくメタデータの値を変更することは実用的に困難である。利点はまた、第1のメタデータが、リディームスクリプト内の公開鍵に利用可能な1つ以上の場所に埋め込まれ、それにより、メタデータを処理するのに適さないノードが、そのプロセスをブロックすることとは対象的に、リディームスクリプトを追加のノードに単に送信することができる。これは、同様に、関連するトランザクションの計算上の効率を改善する。メタデータが契約の契約条件（terms and conditions）へのポインタを含むことにより、この情報をオフブロック・リポジトリに記憶することができるというさらなる利点が提供される。これにより、トランザクション履歴全体を送信する必要なしにトランザクションを処理できるとともに、関連するトランザクションの詳細を後で確実に検証できるため、使用される処理量とメモリリソースが削減される。さらに、制御データをメタデータに組み込むことができ、例えば、会場のチケットを表すトークンの場合のバリア（barrier）のアクセスコード、旅行チケット又はバウチャー（voucher）を入れることができる。さらに別の利点は、トークンを分割することができ、2つ以上のトランザクション出力を可能とすることであり、その各々はトークン化又は未トークン化デジタル資産に関連することができる。

第１のデータアウトプット（Ｏ１）は、スクリプトハッシュトランザクションへの支払いの記録を容易にすることができる。

この方法において、トークン（Ｔ）に対する第１のユーザ（Ａ）からのリクエストを受信するステップは、コントラクトの申込み（offer）又は承諾（acceptance）を受領することを含むことができる。トークン（Ｔ）に対する第１のユーザ（Ａ）からのリクエストを受信するステップは、コントラクトの少なくとも１つ以上の契約条件を受信することをさらに含むことができる。

方法は、第１のユーザ（Ａ）にコントラクトの少なくとも１つ以上の契約条件を送信することをさらに含むことができる。

第１のメタデータ（ＭＤ１）における情報は、コントラクトの少なくとも１つ以上の契約条件を含んでも良い。第１のメタデータ（ＭＤ１）における情報は、１つ以上のコントラクトのタイプ、１つ以上のコントラクトの契約条件、コントラクトの契約条件に対するポインタ、及びトランザクションをいかに処理するかの情報の関する情報を含む。

方法は、データストアにおける第１のリディームスクリプト（ＲＳ１）を記録することをさらに含んでも良い。

方法において、第１のリディームスクリプト（ＲＳ１）は、以下のフォーマットでも良い：
<NumSigs MD1 … P1A P1I … NumKeys OP_CHECKMULTISIG>
ここで、
NumSigsは、第１のトークン（Ｔ１）をリディームするために必要なサインの数であり、
NumKeysは、メタデータ及び公開鍵を含む、スクリプトにおける公開鍵スロットの全体であり、
OP_CHECKMULTISIGは、連番で公開鍵スロットを持つサイン－を含むオペレーションである。

本方法は、第１のユーザ（Ａ）が第１のトークン（Ｔ１）に関連するトランザクションを容易にするために発行者（Ｉ）との口座（ＡＣＡ）を有するかどうかを決定するステップを含み、第１のユーザ（Ａ）が口座を持っていない場合に、本方法は、さらに、通信ネットワークを介して、第１のユーザ（Ａ）のために口座（ＡＣＡ）を開設するリクエストを送信し、この口座（ＡＣＡ）は、第１のユーザ（Ａ）のための第１のユーザの秘密鍵（Ｖ１Ａ）と第１のユーザの公開鍵（Ｐ１Ａ）を含む暗号鍵のペアに関連する、方法である。

この方法において、第１のトークン（Ｔ１）と関連するデジタルアセットの第１の量（Ｂ１）を割り当てるステップが、第１のトークン（Ｔ１）の第１のトークンの値（ＴＶ１）を決定することと、第１のトークン（Ｔ１）に対してペギングレート（ＰＲ１）を決定することと、ペギングレート（ＰＲ１）と第１のトークンの値（ＴＶ１）に基づいてデジタルアセットの第１の量（Ｂ１）を決定することを含むことができる。

１つの代替案では、第１のトークン（Ｔ１）に関連するデジタルアセット（Ｂ１）の第１の量（Ｂ１）を割り当てるステップが、第１のトークン（Ｔ１）のデジタルアセットの最小しきい値（ＭＴ１）を決定することと、デジタルアセットの最小しきい値（ＭＴ１）以上のデジタルアセットの第１の量（Ｂ１）を決定することを含む。

上述の第１のトークン（Ｔ１）を作成する方法にしたがって、デジタルアセットの第１の量（Ｂ１）に関連付けられた第１のトークン（Ｔ１）をリディームするコンピュータ実装方法であって、前記方法は、前記発行者を含み、前記発行者は、前記第１のトークン（Ｔ１）をリディームするために、前記通信ネットワークを介して、前記第１のユーザ（Ａ）からリクエストを受信し、前記第１のトークン（Ｔ１）に関連付けられた前記第１のリディームスクリプト（ＲＳ１）を決定し、前記第１のユーザの秘密鍵（Ｖ１Ａ）を受信し、前記第１のユーザの秘密鍵（Ｖ１Ａ）及び前記第１の発行者の秘密鍵（Ｖ１Ｉ）を使って、前記第１のトークン（Ｔ１）に関連付けられた前記デジタルアセットの前記第１の量（Ｂ１）をロック解除するために前記第１のリディームスクリプト（ＲＳ１）にサインし、前記通信ネットワークを介して、前記発行者（Ｉ）への前記デジタルアセットの前記第１の量（Ｂ１）のトランザクションの表示を含む、前記ピアツーピア分散型台帳へ、第２のデータ出力（Ｏ２）を送信する。

第１のトークン（Ｔ１）をリディームする方法において、第１のトークン（Ｔ１）は、第１の部分（Ｒ１）と第２の部分（Ｒ２）のトークンの値を有し、第１のトークン（Ｔ１）をリディームするための第１のユーザ（Ａ）からのリクエストは、第１の部分（Ｒ１）の値をリディームするリクエストを含み、方法は、さらに、第１のユーザの公開鍵（Ｐ１Ａ）を決定することと、第２のトークン（Ｔ２）に関連するデジタルアセットの第２の量（Ｂ２）を割り当てることとを含み、第２のトークンは、第２の部分（Ｒ２）に基づく第２のトークンの値（Ｔｖ２）を持つ。本方法は、また、第２のリディームスクリプト（ＲＳ２）の第２のハッシュ（Ｈ２）を決定することであって、前記第２のリディームスクリプト（ＲＳ２）は、前記第１のトークン（Ｔ１）に関連付けられた前記第１のメタデータ（ＭＤ１）に少なくとも部分的に基づく少なくとも第２のメタデータ（ＭＤ２）と、前記第１のユーザの公開鍵（Ｐ１Ａ）と、前記発行者（Ｉ）に関連付けられた前記第１の発行者の公開鍵（Ｐ１Ｉ）と、に基づき、前記第２のデータ出力（Ｏ２）の前記公開台帳は、さらに、前記第１のユーザ（Ａ）への前記デジタルアセットの少なくとも前記第２の量（Ｂ２）のトランザクションの表示と、前記第１のユーザ（Ａ）と前記発行者（Ｉ）とに関連付けられた前記第２のトークン（Ｔ２）を提供するために、前記デジタルアセット（Ｂ２）の前記第２の量（Ｂ２）と関連付けられた前記第２のハッシュ（Ｈ２）とを含む。

上述の第１のトークン（Ｔ１）を作成する方法にしたがって、発行者（Ｉ）よって第３のトークン（Ｔ３）が作成されるコンピュータ実装方法であって、前記第３のトークンは、第１のトークン（Ｔ１）からの値の移転を関連付けられており、前記第３のトークン（Ｔ３）を作成するために、前記第１のユーザ（Ａ）及び／又は第２のユーザ（Ｂ）からのリクエストを、前記通信ネットワークを介して受信することと、前記第１のトークン（Ｔ１）に関連付けられた前記第１のリディームスクリプト（ＲＳ１）を決定することと、前記第１のユーザの公開鍵（Ｖ１Ａ）を受信することと、前記第１のユーザの秘密鍵（Ｖ１Ａ）及び前記第１の発行者の秘密鍵（Ｖ１Ｉ）によって、前記第１のトークン（Ｔ１）に関連付けられた前記デジタルアセットの前記第１の量（Ｂ１）をロック解除するために前記第１のリディームスクリプト（ＲＳ１）にサインすることを含む方法である。方法がさらに、第２のユーザの公開鍵（Ｐ１Ｂ）を決定することであって、前記第２のユーザの公開鍵（Ｐ１Ｂ）は、第２のユーザの秘密鍵（Ｖ１Ｂ）と暗号化ペア形成する、第２のユーザの公開鍵（Ｐ１Ｂ）を決定することと、前記第３のトークン（Ｔ３）に関連して前記デジタルアセットの第３の量（Ｂ３）を割り当てることと、第３のリディームスクリプト（ＲＳ３）の第３のハッシュ（Ｈ３）を決定することであって、前記第３のリディームスクリプト（ＲＳ３）は、前記第１のトークン（Ｔ１）に関連付けられた前記第１のメタデータ（ＭＤ１）に少なくとも部分的に基づく少なくとも第３のメタデータ（ＭＤ３）と前記第２のユーザの公開鍵（Ｐ１Ｂ）と、前記第１の発行者の公開鍵（Ｐ１Ｉ）とに基づく、割り当てることとを含む。方法がさらに、前記通信ネットワークを介して、第３のデータ出力（Ｏ３）を前記ピアツーピア分散型台帳に送信することであって、前記ピアツーピア分散型台帳は、前記第２のユーザ（Ｂ）への前記デジタルアセットの前記第３の量（Ｂ３）のトランザクションの表示と、前記デジタルアセットの前記第３の量（Ｂ３）に関連付けられ、前記第２のユーザ（Ｂ）と前記発行者（Ｉ）とに関連付けられた前記第３のトークン（Ｔ３）を提供するための、第３のハッシュ（Ｈ３）とを含む、第３のデータ出力（Ｏ３）をピアツーピア分散型台帳に送信することを含む。

第３のトークン（Ｔ３）を作成する方法において、前記第１のトークン（Ｔ１）は、第１の部分（Ｒ１）及び第２の部分（Ｒ２）のトークンの値を有し、前記第３のトークン（Ｔ３）を作成するための前記リクエストは、前記第１の部分（Ｒ１）に基づいて第３のトークンの値（ＴＶ３）を持つ前記第３のトークン（Ｔ２）を作成するリクエストを含み、前記方法は、さらに、前記第１のユーザの公開鍵（Ｐ１Ａ）を決定することと、第２のトークン（Ｔ２）に関連する前記デジタルアセットの第２の量（Ｂ２）を割り当てることであって、前記第２のトークンは、前記第２の部分（Ｒ２）に基づく第２のトークンの値（ＴＶ２）を持つ、割り当てることを含む。本方法は、さらに、第２のリディームスクリプト（ＲＳ２）の第２のハッシュ（Ｈ２）を決定することを含み、第２のリディームスクリプト（ＲＳ２）は、第１のトークン（Ｔ１）に関連する第１のメタデータ（ＭＤ１）に少なくとも部分的に基づいて第２のメタデータ（ＭＤ２）、第１のユーザの公開鍵（Ｐ１Ａ）、発行者（Ｉ）に関連する第１の発行者の公開鍵（Ｐ１Ｉ）に基づく。本方法において、ピアツーピア分散型台帳に対する第３のデータ出力（Ｏ３）は、さらに、第１のユーザ（Ａ）に対するデジタルアセットの少なくとも第２の量（Ｂ２）のトランザクションの表示と第２のハッシュ（Ｈ２）を含み、第２のハッシュ（Ｈ１）は、デジタルアセットの第２の量（Ｂ２）に関連し、第１のユーザ（Ａ）と発行者（Ｉ）に関連する第２のトークン（Ｔ２）を提供する。

第３のトークン（Ｔ２）を作成する方法において、デジタルアセット（Ｂ２）の第２の量を割り当てるステップは、第２のトークン（Ｔ２）に対してペギングレート（ＰＲ２）を決定することと、ペギングレート（Ｐｒ２）と第２のトークンの値（ＴＶ２）に基づいてデジタルアセットの第２の量（Ｂ２）を決定することを含む。

第３のトークンを作成する方法において、デジタルアセットの第２の量（Ｂ２）を割り当てるステップが、第２のトークン（Ｔ２）のデジタルアセットの最小しきい値（ＭＴ２）を決定することと、第２のトークン（Ｔ２）のデジタルアセットの最小しきい値以上のデジタルアセットの第２の量（Ｂ２）を決定することを含んでもよい。

第３のトークン（Ｔ２）を作成する方法において、デジタルアセットの第２の量（Ｂ２）及び／又はデジタルアセット（Ｂ３）の第３の量は、デジタルあっとの第１の量（Ｂ１）の少なくとも一部を含む。

第３のトークン（Ｔ３）を作成する方法は、さらに、トランザクション手数料としてデジタルアセットの第４の量（Ｂ４）を決定することを含み、ピアツーピア分散型台帳に対する第１のデータ出力（Ｏ１）、第２のデータ出力（Ｏ２）及び第３のデータ出力（Ｏ３）は、さらに、トランザクション手数料としてデジタルアセットの第４の量（Ｂ４）のトランザクションの表示を含む。

上述の方法において、ピアツーピア分散型台帳は、ビットコインブロックチェーンを含んでも良い。

上で定義されたデジタルアセットの第１の量（Ｂ１）に関連付けられた第１のトークン（Ｔ１）をリディームするコンピュータ実装方法であって、前記方法は、前記発行者を含み、前記発行者は、前記第１のトークン（Ｔ１）をリディームするために、前記通信ネットワークを介して、前記第１のユーザ（Ａ）からリクエストを受信し、前記第１のトークン（Ｔ１）に関連付けられた前記第１のリディームスクリプト（ＲＳ１）を決定し、前記第１のユーザ（Ａ）によってサインするために前記通信ネットワークを介して、前記第１のリディームスクリプト（ＲＳ１）を送信し、前記第１のユーザの秘密鍵（Ｖ１Ａ）で前記第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）を前記通信ネットワークを介して、受信し、前記第１の発行者の秘密鍵（Ｖ１Ｉ）を使って、前記第１のトークン（Ｔ１）に関連付けられた前記デジタルアセットの前記第１の量（Ｂ１）をロック解除するために、前記第１のユーザによってサインされた前記第１のリディームスクリプト（ＲＳ１Ａ）にサインし、前記通信ネットワークを介して、前記発行者（Ｉ）への前記デジタルアセットの前記第１の量（Ｂ１）のトランザクションの表示を含む、前記ピアツーピア分散型台帳へ、第２のデータ出力（Ｏ２）を送信することを含む。

上述の第１のトークンを作成する方法にしたがって、発行者（Ｉ）よって第３のトークン（Ｔ３）が作成されるコンピュータ実装方法であって、前記第３のトークンは、第１のトークン（Ｔ１）からの値の移転を関連付けられており、方法は、前記第３のトークン（Ｔ３）を作成するために、前記第１のユーザ（Ａ）及び／又は第２のユーザ（Ｂ）からのリクエストを、前記通信ネットワークを介して受信することと、前記第１のトークン（Ｔ１）に関連付けられた前記第１のリディームスクリプト（ＲＳ１）を決定することと、前記第１のユーザ（Ａ）によってサインするために、前記通信ネットワークを介して、前記第１のリディームスクリプト（ＲＳ１）を送信することと、前記通信ネットワークを介して、前記第１のユーザの秘密鍵（Ｖ１Ａ）で前記第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）を受信することと、前記第１の発行者の秘密鍵（Ｖ１Ｉ）によって、前記第１のトークン（Ｔ１）に関連付けられた前記デジタルアセットの前記第１の量（Ｂ１）をロック解除するために、前記第１のユーザによってサインされた前記第１のリディームスクリプト（ＲＳ１Ａ）にサインすることと、第２のユーザの公開鍵（Ｐ１Ｂ）を決定することであって、前記第２のユーザの公開鍵（Ｐ１Ｂ）は、第２のユーザの秘密鍵（Ｖ１Ｂ）と暗号化ペア形成する、第２のユーザの公開鍵（Ｐ１Ｂ）を決定することと、前記第３のトークン（Ｔ３）に関連して前記デジタルアセットの第３の量（Ｂ３）を割り当てることと、第３のリディームスクリプト（ＲＳ３）の第３のハッシュ（Ｈ３）を決定することであって、前記第３のリディームスクリプト（ＲＳ３）は、前記第１のトークン（Ｔ１）に関連付けられた前記第１のメタデータ（ＭＤ１）に少なくとも部分的に基づく少なくとも第３のメタデータ（ＭＤ３）と前記第２のユーザの公開鍵（Ｐ１Ｂ）と、前記第１の発行者の公開鍵（Ｐ１Ｉ）と、に基づく、割り当てることと、前記通信ネットワークを介して、第３のデータ出力（Ｏ３）を前記ピアツーピア分散型台帳に送信することであって、前記ピアツーピア分散型台帳は、前記第２のユーザ（Ｂ）への前記デジタルアセットの前記第３の量（Ｂ３）のトランザクションの表示と、前記デジタルアセットの前記第３の量（Ｂ３）に関連付けられ、前記第２のユーザ（Ｂ）と前記発行者（Ｉ）とに関連付けられた前記第３のトークン（Ｔ３）を提供するための、第３のハッシュ（Ｈ３）とを含む、第３のデータ出力（Ｏ３）をピアツーピア分散型台帳に送信することとを含む。

本発明は、トークン化方法をさらに提供することができる。それは、ブロックチェーンのような分散型ピアツーピアネットワークを使用して実装することができる。したがって、ブロックチェーン技術の知られている有利な点は、本発明によって用いることができる。本発明は、ブロックチェーンプラットフォームを経由してデータ項目の安全な移転に対する改善されたソリューションを提供することができる。例えば、ブロックチェーンのようなトークンの効率的な安全な移転に対するソリューションとして説明することができる。

本方法は、少なくとも１つのアセット及び／又はサービスの提供に対するコントラクトを表現するためのソリューションを提供することができる。コントラクトは、移転可能なコントラクトでも良い。

本発明は、コントラクトによって移転されるアセット及び／又はサービスの性質、タイプ、量などに関して制限されない。本方法は、移転可能ないかなるタイプのコントラクトもトークン化するための体系化スキームを提供することができる。

本方法は、ブロックチェーントランザクションを生成するステップを含んでも良い。トランザクションは、２つのパラメータ又はデータ項目を含む。
このデータは、以下のものを示すことができる：
ｉ）コントラクトの下で利用可能なシェア（shares）の量（これは、「NumShares」と本明細書で示すことができる）；
ｉｉ）少なくとも１人の受領者に送信者から移転される移転単位の量（これは、「ShareVal」と本明細書で示すことができる）；
ｉｉｉ）移転単位（transfer units）の量に対する値を計算するためのファクタ（これは、「pegging rate」と本明細書で示すことができる）。

本発明の有利な点は、ブロックチェーン上のトークンとしてコントラクトをカプセル化又は表現することを使用することができることである。これは、上述の３つのパラメータのみを使用して達成することができる。実際に、コントラクトは、最低限これらの３つのデータ項目を使用して指定することができる。移転可能ないかなるタイプのコントラクトに対しても使用できる解決策が本発明によって提供されるので、一般的なアルゴリズムを考え出し、適用することができる。

これらの３つのデータ項目は、トランザクション内のメタデータとして提供しても良い。有利には、メタデータの（バイトにおける）小さい量のみが、いかなるタイプのコントラクトを表現するために必要とされる。したがって、本発明は、ブロックチェーンなどのピアツーピア分散型台帳上のトークンの移転に対する効率的且つ効果的で、その上強力なメカニズムを提供する。

データは、例えば、コントラクトに下で提供される物及び／又はサービスなどのアセットの利用可能性の表示をさらに含んでも良い。加えて又は代わりに、コントラクトの下で提供されるアセット又はサービスのタイプ及び／又は量の表示を含んでも良い。

移転は、第４のパラメータ又はデータ項目を実際に含んでも良く、それは、例えば、移転に関連する家又は競走馬などの移転される特定のアセットを特定する。

方法は、少なくとも一人の受領者（又は少なくとも一人の受領者に関連したアドレス）に対する移転を送信するステップをさらに含んでも良い。

トランザクションは、コントラクト、及び／又はコントラクトにアクセスする又はコントラクトを含むファイルにアクセスするための情報を含む。これは、コントラクト又はブロックチェーンを経由してコントラクトを含むファイルの位置に対応する情報のいずれかを移転することを容易さという利点を提供する。

移転は、コントラクトのハッシュを含んでも良い。これは、コントラクトの信憑性を検証するための手段の利点を提供する。

移転は、少なくとも１つの暗号サイン（cryptographic signature）を含んでも良い。これは、移転の起源を特定するという利点を提供する。

移転は、少なくとの１つのロックスクリプト（locking script）と少なくとも１つの公開鍵を含んでも良い。これは、移転の意図された受領者以外の誰かによってリディームされることを防ぐという利点が提供される。

移転の単位は、暗号通貨と関連しても良く、ビットコインに関連するか又は関連しなくても良い。移転の単位は、ビットコインの量であっても良く、ブロックチェーンは、ビットコインブロックチェーンであっても良い。これは、方法を既存のインフラに実装することができという利点を提供する。

したがって、本発明は、ブロックチェーン上でコントラクトを安全に移転するための単純で効率的なスキームを提供する。

コンピュータプログラムは、処理装置に、上述の方法のうちの任意の１つを実行させる機械読取可能命令を含む。

装置は、上述の方法の任意の１つに従う方法を実行する処理装置を含む。

本開示の例が、以下の図面を参照して説明される：
トークンを作成し、リディームするための例となるシステムの概略図である。 第１のユーザとトークンの作成を含む発行者との間の第１のタイプのトランザクションの例を説明する概略図である。 第１のユーザとトークンのリディームを行う発行者との間の第２のタイプのトランザクションの例を説明する概略図である。 第１のユーザと第２のユーザとの間で第１のユーザからのトークンの価値の移転をもたらす発行者によって促進される、第３のタイプのトランザクションの例を示す図である。 第１のユーザとトークンの値の一部をリディームする発行者との間の第４のタイプのトランザクションの例を説明する概略図である。 第１のユーザと第２のユーザとの間で第１のユーザから第２の湯０座へのトークンの値の一部の移転をもたらす、発行者によって促進される、第５のタイプのトランザクションの例を示す図である。 トークンを作成するコンピュータ実装方法のフローチャートである。 ユーザのレジストレーションのコンピュータ実装方法のフローチャートである。 トークンの作成のコンピュータ実装方法の別の例のフローチャートである。 トークンをリディームするコンピュータ実装方法のフローチャートである。 図７のコンピュータ実装方法における追加のステップのフローチャートである。 発行者によって促進される、第１のユーザから第２のユーザへ値の移転のコンピュータ実装方法のフローチャートである。 図９のコンピュータ実装方法の追加のステップのフローチャートである。 サインするために第１のユーザにリディームスクリプトが送られることによってトークンをリディームするコンピュータ実装方法の変形例のフローチャートである。 第１のユーザから第２のユーザへ値を移転させる、発行者によって促進され、それにより、リディームスクリプトがサインのために第１のユーザに送信される、コンピュータ実装方法の変形例のフローチャートである。 処理装置の概略例を説明する。

システムの概略
トークンを作成し、リディームし、移転する方法及びシステムがこれから説明される。図１は、発行者（Ｉ）３、第１のユーザ（Ａ）５、及び第２のユーザ（Ｂ）７を含むシステムを図解する。トークンを作成する発行者（Ｉ）３は、例えば、銀行、他の金融機関、造幣局、会社などであっても良い。発行者（Ｉ）３は、方法１００、２００、３００を実行するための、第１の処理装置１３に関連し、通信ネットワーク８と通信する。第１の処理装置１３は単一のノードとして示されているが、本明細書に記載の方法１００，２００，３００は、発行者（Ｉ）３に関連する複数の処理装置１３又はノードによって実行されてもよく、又は分散して、異なるノードで実行することができる１つ以上のステップでも良い。発行者（Ｉ）は、関連するデータストア１１も持っても良い。

第１のユーザ（Ａ）５は、発行者（Ｉ）３の第１の処理装置１３と、通信ネットワーク８を介して、通信する第２の処理装置１５と関連する。第１のユーザ（Ａ）５は、発行者（Ｉ）３からのトークンの作成、発行者（Ｉ）３とのトークンのリディームをリクエストし、又はトークンの一部又は全部の値の第２のユーザ（Ｂ）７への移転させることをリクエストする。

第２のユーザ（Ｂ）７は、第１の処理装置１３と通信ネットワーク８を介して通信する第３の処理装置１７に関連する。いくつかの例では、第２の処理装置１５及び第３の処理装置１７は、それぞれ第１及び第２のユーザ５，７によって使用されるコンピュータ、移動通信装置、又は他の電子装置であっても良い。別の例では、第２の処理装置１５と第３の処理装置１７は、端末又は他のインタフェースを経由して第１のユーザと第２のユーザによってアクセス可能な仮想機械でも良い。

トランザクションを記録するピアツーピア分散型台帳９も図示されている。ピアツーピア分散型台帳９は、トランザクションを受信し、記録するための１つ以上の処理装置に関連しても良い。ピアツーピア分散型台帳の例は、ブロックチェーンを含み、ブロックチェーンは、ビットコインプロトコルに基づくトランザクションの分散データベースである。したがって、台帳に関連する処理装置１９は、「マイナ」によって使用される処理装置でも良い。

トークンを含むトランザクションの概説
制限のない例において、図２に図示されるように、トークンを含む３つの一般型のトランザクションがある。この例では、発行者（Ｉ）は、第１のユーザ（Ａ）５と第２のユーザ（Ｂ）７の電子ウォレットの管理も行う金融機関である。

図２（ａ）に示された、第１のタイプのトランザクションは、第１のユーザ（Ａ）が、不換通貨（fiat currency）（例えば、＄１，０００ＡＵＤ）を発行者３に移転する第１のトークン（Ｔ１）の生成を含む。不換通貨（fiat currency）の交換において、発行者（Ｉ）は、第１の量（Ｂ１）を「トークン化（tokenises）」することによって、それがトークンの値を持ち、この第１の量（Ｂ１）を第１のユーザ（Ａ）５に移転するようになる。第１のトークン（Ｔ１）は、コントラクトを表現することができ、例えば、指定した不換通貨量（例えば、＄１，０００ＡＵＤ）に対して第１のトークン（Ｔ１）の持参人（bearer）にリディームすることを同意するなどである。その結果、第１のトークン（Ｔ１）は、譲渡可能な証券でも良い。「暗号通貨（cryptocurrency）」は、制限なく、ビットコインなどの暗号化された、電子的な移転可能なデジタルアセットを意味する。

第２のタイプのトランザクションは、図２（ｂ）に示されるように、発行者（Ｉ）３によって第１のトークン（Ｔ１）をリディームする第１のユーザ（Ａ）５を含む。このトランザクションにおいて、第１の量（Ｂ１）は、第１のユーザ（Ａ）から発行者（Ｉ）３に移転される。次に、発行者（Ｉ）３は、不換通貨のフォームでリディームされた値を第１のユーザ（Ａ）５に送信する。発行者（Ｉ）３に移転された第１の量（Ｂ１）は、他の後のトランザクションで使っても良い。発行者（Ｉ）３によるこの第１の量（Ｂ）は、「トークン化された（tokenized）」ままであるか、「未トークン化（untokenised）」暗号通貨に変換されるかは、発行者（Ｉ）３に対する選択であっても良い。

図２（ｃ）に示されるように、トランザクションの第３のタイプは、第１のユーザ（Ａ）５が第１のトークン（Ｔ１）の値を第２のユーザ（Ｂ）７に移転することを含む。この例において、第１のトークン（Ｔ１）を表現する第１の量（Ｂ１）は、第１のユーザ（Ａ）５から第２のユーザ（Ｂ）７へ移転される。トランザクションを許可するためのリディームスクリプト（後述する）に発行者（Ｉ）がサインする必要があるので、発行者（Ｉ）３は、このトランザクションに関与する。このトランザクションの結果は、発行者（Ｉ）３とリディームすることによって（上述と同様のやり方で）「使用」されるか又は他のユーザに転送することができるトークンの値を有する第１の量（Ｂ１）を有する第２のユーザ（Ｂ）７である。

場合によっては、第１のトークン（Ｔ１）の値の一部だけが、第１のユーザ（Ａ）５によって使われても良い。これは、図３（ａ）と図３（ｂ）を参照してトランザクションの第４と第５のタイプとして説明される。これらの例では、第１のトークン（Ｔ１）は、第１の部分（Ｒ１）＋第２の部分（Ｒ２）を含むトータルトークン値を有し、第１のユーザ（Ａ）５は、第１の部分（Ｒ１）を「使用する」ことを望み、第２の部分（Ｒ２）をお釣り（change）として返す。

トランザクションの第４のタイプにおいて、図３（ａ）に示されるように、第１のユーザ（Ａ）５は、前のトランザクションから第１のトークン（Ｔ１）を表現する第１の量（Ｂ１）を持つ。次に、第１のユーザ（Ａ）は、第１の部分（Ｒ１）の値を有するトークンとしての量を移転することによってトークン（Ｔ１）の第１の部分（Ｒ１）をリディームし、同様に、お返しに、第１の部分（ＲＡ）を表現する値を持つ不換通貨を受信する。第１の部分（Ｒ１）のみがリディームされ、残りの第２の部分（Ｒ２）は、第１のユーザ（Ａ）５にとどまっている。これは、第２の部分（Ｒ２）を表す値を有するトークンとしての第２の量（Ｂ２）として示される。１つの例において、第２の量（Ｂ２）は、発行者（Ｉ）３に移転された量より少ない第１の量（Ｂ１）である。

トランザクションの第５のタイプは、図３（ｂ）に示されているように、第１のユーザは、前のトランザクションからの第１のトークン（Ｔ１）を表現する第１の量（Ｂ１）も持つ。次に、第１のユーザ（Ａ）は、第１の部分（Ｒ１）の値を持つトークンとして、第３の量（Ｂ３）を第２のユーザ（Ｂ）に移転することによって、トークン（Ｔ１）のぢあ１の部分（Ｒ１）を移転する。第１の部分（Ｒ１）の値を有するトークンとしての第３の暗号化量（Ｂ３）を第２のユーザ（Ｂ）７に転送することによって、トークン（Ｔ１）の第１の部分を移転する。第１の部分（Ｒ１）のみ移転されるので、残りの第２の部分（Ｒ２）は、第１のユーザ（Ａ）５に留まる。これは、第２の部分（Ｒ２）を表現する値を持つトークンとして第２の量（Ｂ２）として示される。１つの例において、第２の量（Ｂ２）と第３の量（Ｂ３）は、第１の量に由来する。

トランザクションの上述の詳細な例がここから説明される。

トランザクションの第１のタイプ－第１のユーザ（Ａ）に対して第１のトークン（Ｔ１）を発行者が作成する

本明細書に記載の方法の非限定的な例示的な適用例は、発行者（Ｉ）（例えば、金融機関）に不換通貨の額（例えば、＄１０００ＡＵＤ）をデポジットし、発行者（Ｉ）は、同様に、デポジットされた不換通貨の値を表す第１のトークン（Ｔ１）を第１のユーザ（Ａ）のために作成する。契約条件に依存して、第１のユーザ（Ａ）は、デポジットされた不換通貨に関連する値に対する将来の日において、第１のトークン（Ｔ１）をリディームすることができる。契約条件は、第１のユーザ（Ａ）５に、トークンの値の少なくとも１部が第２のユーザ（Ｂ）に移転されるようにすることを可能にしても良い。そのような契約条件は、このトークンに特有であっても良いし、又はユーザ５、７及び発行者（Ｉ）３の間の一般的な契約条件であっても良い。

トークンを作成する方法の概説
発行者（Ｉ）３における第１の処理装置１３による第１のトークン（Ｔ１）の作成の方法１００の例が、図２（ａ）と図４を参照してこれから説明される。方法１００は、第１のトークン（Ｔ１）に対する第１のユーザ（Ａ）５からのリクエストを、通信ネットワーク８を介して、受信する１１０。方法は、第１のユーザの秘密鍵（Ｖ１Ａ）の暗号化ペアを形成する第１のユーザの公開鍵（Ｐ１Ａ）を決定すること１２０も含む。

方法１００は、第１のトーク（Ｔ１）との関連のために第１の量（Ｂ１）を割り当てること１３０を含む。方法１００は、さらに、第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）を決定することであって、前記第１のリディームスクリプト（ＲＳ１）は、前記第１のトークン（Ｔ１）に関連付けられた情報を含む少なくとも第１のメタデータ（ＭＤ１）と、前記第１のユーザの公開鍵（Ｐ１Ａ）と、前記発行者（Ｉ）に関連付けられた第１の発行者の公開鍵（Ｐ１Ｉ）であって、前記第１の発行者の公開鍵（Ｐ１Ｉ）は、第１の発行者の秘密鍵（Ｖ１Ｉ）と暗号化ペアを形成するを含む。

方法１００は、通信ネットワーク８を介して、第１のデータ出力（Ｏ１）をピアツーピア分散型台帳へ送信すること１５０も含む。第１のデータ出力（Ｏ１）は、第１のユーザ（Ａ）５に対する第１の量（Ｂ１）のトランザクションの表示と、第１のハッシュ（Ｈ１）であって、第１のユーザ（Ａ）５と発行者に関連する第１のトークン（Ｔ１）を提供するための暗号痛感の第１の量（Ｂ１）に関連した第１のハッシュ（Ｈ１）を含む。

方法１００は、トークンの記録がピアツーピア分散型台帳９へ送信されるようにトークを生成することもできる。ピアツーピア分散型台帳９上のこのトランザクションを記録することの有利な点は、第１ユーザ（Ａ）５のような受領者がトークン（Ｔ１）の存在を検証させることである。さらに、第1のトークン（T1）に関連する情報を含む少なくとも第1のメタデータ（MD1）がハッシュされるので、トークンに関連する情報に対するトランザクション（パブリックレコード上にある）の検証が可能になる。１つの例において、第１のトークン（Ｔ１）に関連する情報は、コントラクトの契約条件であり得る。したがって、ハッシュ値が計算される第１のリディームスクリプト中の契約条件を含むことは、有利なことに、いかなる変化も第１のハッシュ（Ｈ１）を変えるので契約条件の変更することはできないという第１のユーザ（Ａ）５（又は任意の他のユーザ）に安心をもたらすことができる。最初のトークン（Ｔ１）の作成時に、第１のハッシュ（Ｈ１）がピアツーピア分散型台帳９に送信されて記録されているので、後で、同一の第１のハッシュ（Ｈ１）を提供することになる、その契約条件を変更することは不可能である（又は難しい）。第１のユーザ（Ａ）５に対してトークンを作成する発行者（Ｉ）３の詳細な例は、レジストレーション４００の初期のプロセスを含み、これから説明される。

レジストレーション４００の方法
レジストレーション４００の方法が図５を参照してこれから説明される。方法１００は、第１のユーザ（Ａ）５が発行者（Ｉ）による口座を持つか否か判定することを含んでも良い。特に、これは、第１のトークン（Ｔ１）に関連するトランザクションを容易にするのに適した口座を第１のユーザ（Ａ）５が持つかどうかを判定することを含んでも良い。

もし第１のユーザ（Ａ）５が口座を持たない場合、方法は、通信ネットワーク８を介して、第１のユーザに対する口座を開設するリクエストを送信する３１４をさらに含んでも良い。口座開設のリクエストは、第１のユーザ（Ａ）５に、発行者（Ｉ）との口座に関する契約条件の一般的な詳細と、第１のユーザ（Ａ）５への契約条件を受けいるようにというリクエストを送信することを含んでも良い。
これは、第１のユーザ（Ａ）５の詳細に対するリクエストを送信することも含んでも良い。

さらに、口座を開くリクエストを送信することは、第１のユーザ（Ａ）５に対する第１のユーザの秘密鍵（Ｖ１Ａ）及び第１のユーザの公開鍵（Ｐ１Ａ）を含む暗号化ペアの生成のリクエストを送信することも含むことができる。いくつかの例では、これは、発行者（Ｉ）に関連する別のノードに第１のユーザの秘密鍵（Ｖ１Ａ）及び第１のユーザの公開鍵（Ｐ１Ａ）を生成するリクエストを送信することを含み、それによって、順に、別のノードが生成し、第１のユーザ（Ａ）５に送信する。他の例では、これは、第１のユーザ（Ａ）５に関連する第２の処理装置１５において、第１のユーザの秘密鍵（Ｖ１Ａ）及び第１のユーザの公開鍵（Ｐ１Ａ）を生成するリクエストを第１のユーザ（Ａ）５に送信することを含んでも良い。第１のユーザ（Ａ）５に関連するこれらの鍵は、第１のユーザの秘密鍵（Ｖ１Ａ）が安全に保たれ、第１のユーザ（Ａ）５との承認にのみ使用されている限り、他の手段によって、又は他の手段において生成されても良いことを理解されたい。

第１のユーザ（Ａ）５は、口座を開設するリクエストを受信し７１４、次に、発行者（Ｉ）３に口座を開設するための情報を送信する７１６。

レジストレーション（registration）の方法４００はまた、第１のユーザ（Ａ）５の口座に関連付けられた電子ウォレットを作成し３１６、この電子ウォレット及び口座に関連する情報をデータストア１１に記憶するステップを含むことができる。

いくつかの例において、第１のユーザの秘密鍵（Ｖ１Ａ）は、電子ウォレットに記憶されても良く、理想的には、第１のユーザの秘密鍵（Ｖ１Ａ）は、第１のユーザ（Ａ）５からの承認によってのみアクセス可能となる。例えば、電子ウォレットは、第１のユーザ（Ａ）５に関連する複数の秘密鍵を有することができ、それによって、第１のユーザ（Ａ）５が、発行者（Ｉ）３と成功裏に且つ安元に、ログオンできるとき（例えば、仮想機械環境又は端末で）、第１の秘密鍵が入手可能となる。第１のユーザ（Ａ）５は、トランザクションのためにデータストア１１からこれらの秘密鍵を読み出し、使用するために、次に選択的に発行者（３）を承認することができる。いくつかの例において、ユーザの秘密鍵は、電子ウォレットに記憶されないが、それぞれのユーザからの承認によって発行者（Ｉ）３によって再作成することができる。さらに別の例では、ユーザの秘密鍵は分割鍵であってもよく、電子ウォレットは1つの部分を有し、ユーザは残りの部分を有し、それによって結合されて秘密鍵を再現することができる。

別の例において、第１のユーザの秘密鍵（Ｖ１Ａ）は、発行者（Ｉ）、第１の処理装置１３、及びデータストア１１から分離した状態を保っても良い。例えば、第１のユーザ（Ａ）５は、個人の電子装置、コンピュータ、又はストレージ装置の安全、又は確実な部分に、第１のユーザの秘密鍵（Ｖ１Ａ）のハードコピーを保つこともできる。

方法４００におけるステップは、例えば、第１のユーザ（Ａ）５から第１のトークン（Ｔ１）に対するリクエストを受信するステップ１１０の後に、方法１００の間に実行されても良いことを理解されたい。

他の例において、方法又はレジストレーション４００は、事前に実行しても良い。

トーク１００を作成する詳細な方法
第１のトークン（Ｔ１）を作成する方法１００は、これから、図２（Ａ）、図４及び図６（発行者（Ｉ）３と第１のユーザ（Ａ）５のそれぞれによって実行される方法１００と５００を示す）を参照して詳細に説明される。この例において、トークンを作成することは、第１のユーザ（Ａ）５が発行者（Ｉ）３にキャッシュをデポジットし、それと引き換えに、デポジットされたキャッシュを表現するトークンの文脈で検討される。しかしながら、これは制限のない例であり、トークンは別のトランザクションの文脈で作成することができることが理解される。例えば、トークンは、任意の他の契約、譲渡可能な証書、有形財産などを表すことができ、例えば、会場のチケット又は旅行チケット又はバウチャーを表すトークンの場合はバリアのアクセスコードを含む移転可能な資産を表すことができる

トークンに対する契約条件に対する合意
レジストレーション４００の方法の後又は前に、第１ユーザ（Ａ）５は、第１のトークン（Ｔ１）に対するリクエストを送信することができる５１０。１つの例において、第１のユーザ（Ａ）５は、例えば、＄１０００ＡＵＤの不換通貨をデポジットすることによって、トークン（Ｔ１）にこの額を持つためのリクエストによって、このリクエストを作成する。

１つの例において、第１のユーザ（Ａ）５によって送信されたリクエストは、コントラクトの提示を含んでも良い。この提示は、コントラクトの１つ以上の契約条件を含んでも良い。例えば、第１のユーザ（Ａ）５は、＄１０００ＡＵＤのデポジットに関連するトークンが、暗号化のための固定されたペギングレートを有するべきであるということをリクエストに含めることができる。例えば、ペギングレートが１０００サトシ／セント（ＡＵＤ）というリクエストである。他の契約条件は、例えば、口座管理費、トランザクション費、いかにトークンがリディームされるかなどのオファー（offer）に含めることができる。

図６に示すように、発行者（Ｉ）の第１の処理装置１３は、通信ネットワーク８を介して第１のユーザ（Ａ）５から第１のトークン（Ｔ１）及びいくつかのケースでは少なくともいくつかの契約条件に対するリクエストを受信する１１０。発行者（Ｉ）は、リクエストを受け入れるか、リクエストの契約条件を修正するカウンタオファーか、リクエストを拒絶するか否かを判定することができる１１２。方法１００は、次に、ステップ１１２で、通信ネットワーク８を介して、判定結果を送信すること１１４を含む。

第１のユーザ（Ａ）５は、次に、通信ネットワーク８を介して、ステップ１１２で、受け入れる、カウンタオファー、又はリクエストの拒絶を含む、判定結果を受信することができる。

１つの別の例は、発行者（Ｉ）に対して送られたリクエスト５１０は、第１のトーク（Ｔ１）に対するリクエストを単純に含む。この場合、発行者（Ｉ）は、契約条件を含むオファーを第１のユーザ（Ａ）５に送信することができる。第１のユーザ（Ａ）５は、同様に、オファーを受け入れる、カウンタオファーを提案する、又はオファーを拒絶するか否かを判定し、それは、次に、発行者（Ｉ）に送信される。

ステップ５１０，５２０、及び１１０，１１２，１１４は、彼らが同意するまで、発行者（Ｉ）と第１のユーザ（Ａ）５との間で送受信される複数回のオファー及びカウンタオファーを含むように修正することができることを理解されたい。

いくつかの代替案では、契約条件は、標準化され、方法１００、５００でステップを実行することによって、ユーザはその契約条件を受け入れる。１つの例において、発行者（Ｉ）は、第１のユーザ（Ａ）５を含む彼の顧客に対して、トークンに関する標準化したオファーを有しても良い。トークンに対するそのようなオファーは、公開取引として、又は発行者のウェブサイトなどで公開でリストすることもできる。スタンディングオファーは、また、電子メールによって、アプリケーションを通して、又は、安全なウェブサイトにおけるロギングによって、非公開で発行者（Ｉ）によって第１のユーザ（Ａ）５に提供されても良い。

トークンに関連する契約条件は、データストア１１に記憶され、記録のために第三者に送信され、又はトレントされる（torrented）。

第１のユーザの公開鍵の決定１２０
方法１００は、第１のユーザの公開鍵（Ｐ１Ａ）を決定するステップ１２０を含む。一例では、第１のユーザの公開鍵（Ｐ１Ａ）は、第１のユーザ（Ａ）５から、通信ネットワーク８を介して発行者（Ｉ）に送信され５３０ても良い。別の例では、第１のユーザの公開鍵（Ｐ１Ａ）は、データストア１１に関連して記憶されても良い（それは、例えば、第１のユーザ（Ａ）５のレジストレーションの間に受信され、記憶されても良い）。したがって、第１のユーザの公開鍵（Ｐ１Ａ）を決定するステップ１２０は、データストア１１から鍵を読み取ることを含む。さらに別の例では、第１のユーザの公開鍵（Ｐ１Ａ）は、通信ネットワーク８を介して、第三者から受信しても良い。第三者は、例えば、認証機関などの、公開ディレクトリとして行動する信用がある第三者を含んでも良い。

トークンと関連する第１の量の割り当て１３０
方法１００は、第１のトークン（Ｔ１）に関連する第１の量を割り当てること１３０を含む。第１のトークン（Ｔ１）を含むトランザクションのレコードをピアツーピア分散型台帳（この例ではブロックチェーン）に記録するためには、トークンをある量の暗号化に関連付ける必要がある。次に、量は、発行者（Ｉ）３から第１のユーザ（Ａ）５へのトランザクションとしてピアツーピア分散型台帳上に記録される。言い換えれば、ブロックチェーントランザクションＴｘは、台帳に含めるためにブロックチェーンネットワークに提示される。Ｔｘは、一人の当事者、例えば、発行者から他の当事者、例えば、第１のユーザへの暗号通貨（又は所有権／制御）の量を移転するために使用することができる。

第１のトークン（Ｔ１）に関する第１の量（Ｂ１）の割り当ては、トークンの値の割合に基づくこともできる。例えば、ペギングレート（ＰＲ１）を第１のトークン（Ｔ１）に対して指定することができる。したがって、第１の量（Ｂ１）を割り当てるステップ１３０は、ペギングレート（ＰＲ１）及び第１のトークンの値（ＴＶ１）に基づいて、第１の量（Ｂ１）を決定することを含むことができる。説明に役立つ例として、ペギングレート（ＲＰ１）は、１０００サトシ／セントＡＵＤでり、第１のトークンの価値（ＴＶ１）は、＄１０００ＡＵＤでも良い。したがって、第１の量（Ｂ１）は、１０，０００，０００であっても良い。

トークンに対して割り当てられる量は、以下の考慮点のいくつかに影響されることもあり得る。第１に、割り当てられた量は、理想的には、市場価値（この目的で、市場価値自体は、トークンの値を参照することなく、それ自体価値があることを前提としていることを意味する）を有し、それは、トークンの値より小さい（「トークン値（token value）」）。これは、トークンとしてよりも基礎をなす値に対する量を使用する動機がないことが望ましい。これは、硬貨の額面金額を硬貨が製造される金属よりも高くすることが望ましい現金硬貨に類似しているので、硬貨の金額を硬貨に溶かすことは望ましくない。いくつかの例において、トークンの値は、基本的な値の数倍大きい。しかしながら、いくつかのトークンは、固定の又は容易に決定できないトークンの値を持っても良い。例えば、値が日に日に変わるような仕事の実行のコントラクトを表現することもできる。別の例では、コントラクトは、リディームされる日に決定される値を持つこともできる。

別の考慮すべき点は、ピアツーピア分散型台帳に暗号通貨量のトランザクションを記録することができるので、割り当てられた量が、トークン値又はトランザクションの値に対して大きすぎてはならないことである取引手数料を負担するなどの費用を負担する。いくつかの例において、トランザクション手数料は、トランザクションにおける量に基づき、その結果、最低限のレベルでのトークンに対して量を維持することが望ましいかも知れない。

一方、トークンに関連して割り当てられる量は、無限に小さいことはできない。第１に、暗号通貨は、最低単位量、例えば、ビットコインは、１サトシの最低量を持つ（１ビットコイン（ＢＴＣ）＝１０，０００，０００サトシ）。第２に、トランザクションは、最低元のサイズに限定され、又はさもなければ、記録されない（又はトランザクションのコストは、トランザクションを実行するコストに近くなるか、又は超える）。この最低限の量は、いくつかの例において、「ダスト（dust）」リミットである。したがって、いくつかの例において、トークンのために量を割り当てることは、暗号通貨最低限のしきい値（ＭＴ１）を越えなければならない。したがって、方法１００は、第１のトークン（Ｔ１）に適した最小しきい値（ＭＴ１）を決定し、最小しきい値（ＭＴ１）以上の第１の量（Ｂ１）を決定することを含むことができる。１つの例において、最低限のしきい値（ＭＴ１）は、「ビットコイン」においては、５４６サトシである。

トークンに対する量を割り当てる別の検討事項は、後続のトークンに対する量の分割可能性（divisibility）である。例えば、第１のトークン（Ｔ１）は、＄１０００ＡＵＤのトークン値（ＴＶ１）を持っても良く、第１のユーザ（Ａ）５は、第２のユーザ（Ｂ）７にトークン値の＄８００ＡＵＤを移転することを希望し、残りの＄２００ＡＵＤトークンを維持したいと思うことができる。そのようなトランザクションは、お釣りとして第１のユーザ（Ａ）５にとどまる＄２００ＡＵＤを表す第２のトークン（Ｔ２）という結果になる第１のトークン（Ｔ１）のトランザクションに関与し、第２のユーザ（Ｂ）７に移転される＄８００ＡＵＤを表す第３のトークン（Ｔ３）を作成する。したがって、この移転の結果、第２のトークン（Ｔ２）と第３のトークン（Ｔ３）の２つのトークンになり、これらのトークンのそれぞれは、また量を割り当てる必要がある。例えば、「ダスト」限界で、第１の量（Ｂ１）が最小であった場合、次に、作成された新しいトークンのそれぞれが最小しきい値を満足するために十分な量と関連付けられるように、総量が調達される必要がある。したがって、その量がその後のトークンの予想される数に対して使用されるように分割されるのに十分であるように、第１のトークン（Ｔ１）に十分な量（Ｂ１）を割り当てることは、有利であり得る。１つの例では、契約条件は、量、又はトークンの最小値、又はトークンのデノミネーション（denomination）を特定しても良い。例えば、契約条件は、＄１０ＡＵＤをトークン値の最小デノミネーションとして設定することができる。したがって、＄１０００ＡＵＤのトークンの値（ＴＶ１）を有する第１のトークン（Ｔ１）に対する第１の量（Ｂ１）を割り当てることは、全トークンの値（ＴＶ１）が最小の単位に分割される場合、十分な暗号通貨があることを保証するように第１の量を決定することを含んえも良い。この例では、トークン値（ＴＶ１）は、１００の後続のトークンに分割することができる（＄１０００／＄１０によって計算され）。その結果、適切な第１の量（Ｂ１）は、「ダスト（dust）」限界の百倍である。

第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）の決定１４０
方法は、第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）を決定すること１４０を、さらに含む。１つの例において、リディームスクリプトのハッシュは、スクリプトハッシュトランザクションに対して払うためのスクリプトハッシュ（Ｐ２ＳＨ）アドレスへの支払いを提供するために使用することができる。例は、ビットコインにおけるＰ２ＳＨスクリプトにおいて使用されるハッシュ関数を含む。これは、その後にＲＩＰＥＭＤ１６０が続く、ＳＨＡ２５６の組み合わせを含むことができる。

第１のリディームスクリプト（ＲＳ１）は、第１のトークン（Ｔ１）をロック解除するために使用することができるスクリプトであり、後述されるように、それは、第１の量（Ｂ１）のトランザクションを含む。第１のトークン（Ｔ１）をロック解除するとき、第１のリディームスクリプト（ＲＳ１）のある条件は、トランザクションをロック解除することにミートする必要がある。特に、第１のユーザ（Ａ）５及び発行者（Ｉ）のサインが必要である。第１のリディームスクリプト（ＲＳ１）の例は、これから説明される。

第１のリディームスクリプト（ＲＳ１）
第１のリディームスクリプト（ＲＳ１）は、第１のトークン、第１のユーザの公開鍵（Ｐ１Ａ）及び第１の発行者の公開鍵（Ｐ１Ｉ）を含む、少なくとも第１のメタデータ（ＭＤ１）に基づく。

（ｉ）一般にＰ２ＳＨにおけるリディームスクリプト
背景として、スクリプトハッシュ方法に対する支払いは、以下の形式を取ることができる。
<NumSigs PubK1 PubK2 … PubK15 NumKeys OP_CHECKMULTISIG>
ここで、NumSigsは、トランザクションをロック解除するためのリディームスクリプトを満足させるために必要な有効なサインの数「ｍ」である。PubK1、PubK2…PubK15は、トランザクション（最大１５公開鍵までの）をロック解除するサインに対応する公開鍵である。NumKeysは、（１５以下の）公開鍵の数「ｎ」である。

上述のリディームスクリプトのロック解除は、公開鍵に対応する少なくとも「ｍ」個のサインを必要とする。いくつかの例において、公開鍵の順序が重要であり、サインのための「ｎ」個のサインのうちの数「ｍ」は、順序通りに行われなければならない。例えば、「ｍ」が２で、公開鍵の数「ｎ」が１５とする。使用するために２つのサインが利用可能で、Sig1（PubK1に対応する）とSig15（PubK15に対応する）とすると、リディームスクリプトは、Sig15が続くSig1によって先ずサインすべきである。

（ii）Ｐ２ＳＨを使用した第１のリディームスクリプト（ＲＳ１）
現在の例に戻ると、Ｐ２ＳＨを利用する第１のリディームスクリプト（ＲＳ１）は、リディームスクリプトにおいて少なくとも第１のメタデータ（ＭＤ１）を含んでも良い。特に、少なくとも第１のメタデータ（ＭＤ１）は、リディームスクリプトにおいて公開鍵に対して使用可能な１５の場所の１つ以上に組み込むことができる。

したがって、１つの例において、第１のリディームスクリプト（ＲＳ１）は、以下のフォームを取りうる：
<NumSigs Metadata1 Metadata2 PubK1 PubK2 NumKeys OP_CHECKMULTISIG>
ここで、NumSigsは、トランザクションをロック解除するためのリディームスクリプトを満足させるために必要な有効なサインの数「ｍ」である。
Metadata1とMetadata2は、公開鍵の場所を取るメタデータを含む。
PubK1とPubK2は、実際の公開鍵である。
１つの例において、PubK1は、第１のユーザの公開鍵（Ｐ１Ａ）であり、PubK2は、発行者の公開鍵（Ｐ１Ｉ）であっても良い。
NumKeysは、メタデータと公開鍵によって取られる位置のトータルの数である（１５以下であるべき）。

この有利な点は、メタデータが、第１のリディームスクリプト（ＲＳ１）に含まれることであり、それは、次に、ハッシュ値が計算され、その記録がピアツーピア分散型台帳９中に含まれる。したがって、第１のリディームスクリプトハッシュ（ＲＳ１）の対応するハッシュの変更という結果が無く、メタデータの値を変更することは、不可能ではないとしても、困難であるだろう。

実用上の利点は、以下の例によって説明することができる。第１のユーザ（Ａ）５と発行者（Ｉ）３は、特定の条件でコントラクトを締結することを望むことがある。コントラクトは、発行者（Ｉ）がトークンを生成することを含み、それによって、特定の契約条件がリディームスクリプトに埋め込まれたメタデータに含まれる。リディームスクリプトのハッシュは、次に、ピアツーピア分散型台帳９に記録され、それは、変更が困難か不可能なトランザクションの記録になる。仮に、発行者（Ｉ）が第１のユーザ（Ａ）５を騙そうとすると、例えば、条件を変更しようとし、元々同意したコントラクトに変更した条件を主張しようとする。第１のユーザ（Ａ）５は、リディームスクリプトのメタデータ中の変更された条項を置いて、それのハッシュ値を計算し、次に、ピアツーピア分散型台帳上に記録されたリディームスクリプトに一致しないことを示すことによって、これに異議を唱えることができる。その結果、少なくとも第１のメタデータ中のトークンに関連する情報を含むことは、トークンのインテグリティを保証するために役立つかも知れない。

リディームスクリプト中のメタデータは、それ自体が、他の情報のハッシュを含んでも良い。例えば、契約条件が非常に長い場合、契約条件のハッシュは、より短いメタデータを提供するために使用することができる。

第１のリディームスクリプト（ＲＳ１）は、記録として、第１のトークン（Ｔ１）をリディームするために、データストア１１に記録することができる。いくつかの別の例では、第１のリディームスクリプトは、第１のユーザ（Ａ）５、又は第三者に送っても良い。

メタデータ
現在の例では、第１のリディームスクリプト（ＲＳ１）は、以下の形式を取る：
<2 Metadata1 Metadata2 P1A P1I 4 OP_CHECKMULTISIG>

したがって、少なくとも第１のメタデータ（ＭＤ１）は、リディームスクリプト中の２つの場所を使用するMetadata1とMetadata2の両方を含む。これに、順番に、２つの公開鍵、第１の公開鍵（Ｐ１Ａ）と第１の発行者の公開鍵（Ｐ１Ｉ）が続く。NumSigsは、トランザクションのロック解除に２つのサインを必要とすることを意味する、２である。

メタデータは、多くの方法で、トークンに関する情報を含むことができる。上述の通り、１つの例において、契約条件は、メタデータに含むことができる。別の例において、契約条件のハッシュは、メタデータに含むことができる。さらに別の例において、メタデータは、コントラクトの契約条件を含むファイルに対するポインタを含むことができる。さらに実施形態において、上述の１つ以上を含む組み合わせは、メタデータに含むことができる。

（ｉ）契約条件に対するポインタを持つメタデータ
第１のメタデータ（ＭＤ１）の特定の例が、以下の表１に説明される。

この例は、トークンとトランザクションに関して最小量の情報を含む。この例は、コントラクトに対するポインタを提供することを含み、ポインタは、コントラクトのサイズが、メタデータ中にそのような詳細を含むことを除外する場合には、役に立つかも知れない。その上、メタデータは、公表されている、又は安全ではないネットワークを介して伝送されるので、トークンの特定の詳細は、プライバシー上の理由で覆う、又は隠蔽することが望ましいことがある。

metadata1の最初の４バイトは、コントラクトタイプを示す。例えば、コントラクトタイプは、「不換通貨」に対するものであり得る。次の１６バイトは、ＩＰｖ６アドレスを考慮に入れる、実際の電子コントラクトファイルの位置のＩＰアドレスを保持する。いくつかの実施形態において、この値は、コントラクトファイルは、中央集権化するよりもクラウドに渡って分散されるように、トーレントファイル（torrent file）のシード（seed）を指し示す。次の１２バイトは、コントラクトタイプを特有のデータを包含する。

metadata2の最初の２０バイトは、ファイルに適用されるＳＨＡ２５６に渡ってＲＩＰＥＤＭＤ－１６０を使用する実際のコントラクトファイルのハッシュである。実際のコントラクトファイルは、読み出し可能なので、これによりコントラクトに対するトランザクションの検証を可能にする。コントラクトファイル自身は、特定の実施形態の要求に依存して、完全に公開され（暗号化されず、人間が読める）ても良く、又はプライバシーのために暗号化されても良い。metadata2の残りの１２バイトのコンテンツは、コントラクトのタイプに依存して使用することができる。

（ii）トークンのキーパラメータを持つメタデータ
第１のメタデータ（ＭＤ１）の別の特定の例が、以下の表２に説明される。

この例では、トークンのいくつかのキーパラメータがメタデータに含まれる。キーパラメータによって、これは、トークン自体に関連する情報又は移転の処理をアシストすることができる情報を含むこともできる。特に、上述の表１のサブフィールド「ContractTypeData1」に割り当てられたバイトは、ファイル名、ペギングレート、及びトランザクションタイプを示すために使用されている。

重要なことは、発行者（Ｉ）３は、いくつかの場合において、移転を処理するために必要な鍵情報に対してコントラクトファイルを読み出すことなく移転におけるトークンを処理することができるので、メタデータへキーパラメータを含めることは、処理効率を大いにアシストすることができる。

上述の情報に加えて、トークン又はトークンに先行するトークンの履歴に関連する他の情報を含んでも良い。例えば、第１のユーザ（Ａ）５が第１のトークン（Ｔ１）の一部をリディームしたい場合、残りの部分の値を表すように第２のトークン（Ｔ２）が発行者（Ｉ）によって作成され、発行者は第２のトークン（Ｔ２）を第１のトークン（Ｔ１）に関連付けるためにメタデータに情報を埋め込むことができる。これは発行者（Ｉ）が銀行などの発行者（Ｉ）にとって集中的な仕事であるトランザクションの履歴を通してトレースする費用をかけることなく、トークンの消息を知り、経過を追うのを助けることができる。

表２において、メタデータは、不換通貨（FiatDenomination）を示す２バイトのフィールドとペギングレート（PeggingRate）と呼ばれる１バイトフィールドを包含する。ペギングレートは、発行者（Ｉ）によって設定される。同じ不換通貨に対していくつかの異なるレートを設定することができるが、異なるトークン（異なるコントラクトを持つ）は、各異なるレートに対して必要となる。レートの選択は、発行者（Ｉ）の裁量であっても良いが、上述の通り、発行者（Ｉ）は、トークンに対する 量の割り当てに関してペギングレートに対して同様の検討をすることができる。

１つの例において、PeggingRateは、以下の通り８ビットの暗号化値であり：
一番左のビットは、フラグとして使用され、
１＝サトシ／セントとして表されるレート（「セント」は、不換通貨の１００分の１を指し、最小の不換通貨である）
０＝セント／サトシを表すレート
一番右の７ビットは、例えば、以下のようなバイナリで１０のべき乗としてのレートを表現する：
ＵＳＤ １００００１０は、１００サトシ／セントのレートを意味する（フラグはオン）
ＰＨＰ ００００００００は、１センタボ／サトシのレートを意味する（フラグはオフ）
ＩＤＲ ０００００００１は、１０ルピア／サトシのレートを意味する（フラグはオフ）

一例では、ＴｒａｎｓａｃｔｉｏｎＴｙｐｅは、トランザクションが発行（トークンが暗号通貨から生成される）、支払い（payment）（トークン値の少なくとも一部がユーザを別のユーザに移転される）又はリディーム（トークンが発行者に移転され、通常の暗号通貨に戻すように転換される）であるか否かを示す１バイトのフィールドである。

いくつかの例において、Metadata1とMetadata2の両方における「パディング（Padding）」は、各移転に対してランダムに生成された値を含み得る。その結果、Metadata1とMetadata2のそれぞれは、移転間で変化する。利点は、暗号化ペアとしてＭｅｔａｄａｔａ１又はＭｅｔａｄａｔａ２のいずれか又は両方と一致する秘密鍵を決定しようとする悪意のある人物のリスクと動機を低下させる可能性があることである（そのような秘密鍵を使用してリディームスクリプトにサインする目的で）。これは、Metadata1又はMetadata2の残りのほとんどが同じ場合に、標準化されたトークンに対して重要となり得る。

公開鍵
第１のユーザの公開鍵（Ｐ１Ａ）と発行者の公開鍵（Ｐ１Ｉ）は、対応する第１のユーザの秘密鍵（Ｖ１Ａ）と発行者の秘密鍵（Ｐ１Ｉ）とは、それぞれ対をなす。公開鍵は、広く公衆に知られている可能性があり、一方、別の例では、必要に応じて、公開鍵を通信することが望ましい可能性がある。いずれにしても、対応する秘密鍵は、（トークンの交換時など）リディームスクリプトにサインしてロック解除するときにのみ必要となるため、公開鍵のみがリディームスクリプトに対して必要となる。

上述の通り、いくつかの代替案では、第１のユーザ５及び第２のユーザ７は、仮想機械環境又は端末を通して彼らの電子ウォレットにアクセスすることができる。電子ウォレットは、発行者（Ｉ）３（又は発行者（Ｉ）３に関連するサーバ）によってホストされてもよく、対応するユーザの秘密鍵はデータストア１１に記憶されるが、そのユーザからの承認を得て発行者（Ｉ）３によってのみアクセスされる（又は再作成される）。そのような場合、第１及び第２のユーザ５、７は、リディームスクリプトをロック解除するために発行者（Ｉ）３に彼らの秘密鍵が提供されることを許可しても良い。これは、ユーザの秘密鍵が発行者（Ｉ）３の第１の処理装置１３に送信されることを許可することを含み、第１の処理装置１３は、ユーザの秘密鍵（例えば、Ｐ１Ａ、Ｐ１Ｂ）と第１の発行者の公開鍵（Ｐ１Ｉ）を使用してリディームスクリプトをロック解除しても良い。

第１のデータ出力（Ｏ１）をピアツーピア分散型台帳へ送信する１５０
方法１００は、通信ネットワーク８を介して、第１のデータ出力（Ｏ１）をピアツーピア分散型台帳９へ送信することをさらに含む。第１のデータ出力（Ｏ１）は、第１の量（Ｂ１）のトランザクションの第１ユーザの表示を含んでも良い。すなわち、第１のトークン（Ｔ１）に関連する暗号通貨（Ｂ１）の基礎をなす量が、第１のユーザ（Ａ）５に移転されたことを記録することである。第１のデータ出力（Ｏ１）は、上述の第１のハッシュ（Ｈ１）も含む。第１のハッシュ（Ｈ１）は、第１の量（Ｂ１）に関連し、第１のユーザ（Ａ）５と発行者（Ｉ）に関連する第１のトークン（Ｔ１）を記録を提供する。

重要なことは、第１のハッシュ（Ｈ１）は、トークン（Ｔ１）の存在、発行者（Ｉ）と第１のユーザ（Ａ）５との間の関係、及び／又はトークンの契約条件を証明又は検証するために使用することができるピアツーピア分散型台帳９上にある。

方法は、後の使用のために第１のリディームスクリプト（ＲＳ１）をデータストア１１に保存すること１６０も含んでも良い。

第１のトークン（Ｔ１）を作成するトランザクションの特定の例は、これから図２（ａ）を参照して説明される。

第１のユーザ（Ａ）５は、トークン中の同価値のために発行者（Ｉ）に＄１０００ＡＵＤをデポジットする
この例において、第１のユーザ（Ａ）５は、発行者（Ｉ）に＄１０００ＡＵＤをデポジットすることを望み、引き換えに、発行者（Ｉ）は、１０，０００，０００の第１の量（Ｂ１）とこれを関連付けることによって＄１０００ＡＵＤのトークンの値（ＴＶ１）で第１のトークン（Ｔ１）を作成する。

トークンを作成するために、発行者（Ｉ）は、暗号通貨を持つ必要がある。これは、前のトランザクションから供給するか、又は第１のトークン（Ｔ１）に対する第１のユーザ（Ａ）５からのリクエストに応答して供給しても良い。これは、「（トークン化されていない）第１の量」として図２（ａ）の左側に示されている。

以下の表３は、トランザクション－ＩＤ／サトシ量／ロッキングスクリプト（transaction-ID / Satoshis amount/ locking script）の形式で、トランザクション出力を生じさせることを示す。このトランザクション出力を生じさせることは、発行者が前のトランザクションから取得した暗号通貨を表現し、少なくともいくらかは、第１のトークンのと関連して使用される。

第１行のＩＤ－２０１は、このトランザクションを特定するトランザクション識別子である。次の行は、５０，０００，０００であるこのトランザクションのサトシ数である。３行目は、このトランザクションに対するロッキングスクリプト（出力スクリプト）である。この出力、<PubK-Issuer hash>における、リディームスクリプトは、第１の発行者の公開鍵（Ｐ１Ｉ）でロックされたこの出力を示す。すなわち、このトランザクションは、発行者の対応する第１の発行者の秘密鍵（Ｖ１Ｉ）を使用してロック解除することができる。

上述の通り、方法１００は、第１のトークン（Ｔ１）に適した第１の量（Ｂ１）を割り当てることを含む。しかしながら、発行者（Ｉ）が手元に持つ量は、第１の量（Ｂ１）と正確に一致しないかもしれない。現在の例において、必要な第１の量（Ｂ１）は、１０，０００，０００であり、それは、トランザクションＩＤ－２０１の形式の５０，０００，０００よりかなり小さい。

その結果、第１のトークン（Ｔ１）を作成するトランザクションは、トークンに対して必要とされない超過量に対して発行者へ変更を戻して提供することを含む。

その上、トークン１００の作成は、発掘するためのトランザクション手数料の支払いを必要とするトランザクションである。これは、トークンの作成に対するトランザクションを示した下の表４を参照して説明される。

第１行「ＩＤ－２１０」は、このトランザクションを特定するトランザクション識別子である。２行目は、使用されるビットコインプロトコルのバージョンを宣言する「バージョン番号（Version number）」を示す。３行目は、このトランザクションに関する入力の数を示し、これは、単一入力を示す。

表４の４行目から７行目は、「入力」のこれらに関連し、すなわち、ＩＤ－２１０に資金を提供する前のトランザクション、ＩＤ－２０１である。４行目は、前のトランザクションのトランザクション識別子である。５行目の「ＩＤＸ－００」は、前のトランザクション、ＩＤ－２０１の出力のインデックスである（この場合、前のトランザクション、ＩＤ－２０１の第１の出力が使用されることが参照である）。
６行目は、前のトランザクション、ＩＤ－２０１に対するロック解除スクリプトである、「ScriptSig」である。上述の通り、前のトランザクションは、PubK-Issuerで表現される第１の発行者の公開鍵（Ｐ１Ｉ）でロックされる。その結果、前のトランザクションは、Sig-Issuerとして表現される発行者の対応する第１の発行者の秘密鍵（Ｖ１Ｉ）を使用してロック解除することができる。７行目は、入力に関連する連続番号である。

ビットコイントランザクションにおいては、それぞれが、ビットコインコアによって最早使用されない「連続番号（sequence number）」と呼ばれる４バイトフィールドを含む。発行者の実装によって、オプションは、このフィールドを出力に対するトランザクション入力を割り当てるために活用することである。シーケンス番号は、1ビットフラグのストリングを表すことができ、それにより、右端のビットから始まる各フラグの位置は、入力がフラグ付き出力への資金の一部を提供したことを示す。この例では、シーケンス番号「000000000000000000000000000000011」は、入力が後述する出力1及び出力2に支払われることを示している。

表４の行８は、このトランザクションの出力の数を示し、それは２である。行９から１１は、第１の出力を表現し、行１２から１４は、第２の出力を表現する。

第１の出力は、第１のトークン（Ｔ１）に関連する第１の量（Ｂ１）を反映する。行９は、第１の量（Ｂ１）の出力の値であり、それは、１０，０００，０００サトシである。行１０は、出力スクリプトの長さを示す。行１１は、出力スクリプト－すなわち、第１の量（Ｂ１）をロックするロッキングスクリプトである。これは、第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）を含み、以下のように表現される：
OP_HASH160 <redeem script hash> OP_EQUAL

「OP_HASH160」は、ハッシュ関数のタイプであり、入力は、ＳＨＡ－２５６とその次にＲＩＰＥＭＤ－１６０によって２度ハッシュ値が計算される。リディームスクリプトハッシュは、上述の形式で第１のリディームスクリプト（ＲＳ１）のハッシュであり、例えば、以下である：
2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

これは、上述の通り、第１のユーザの公開鍵（Ｐ１Ａ）と第１の発行者の公開鍵（Ｐ１Ｉ）を含む。metadata1とmetadata2は、これは「発行（issuance）」トランザクションであるという表示を含む、上述のメタデータを含んでも良い。
OP_EQUALは、出力を検証するためのブール結果を提供する。

第２の出録は、トランザクションに対する発行者の変更を反映する。前のトランザクションＩＤ－２０１である入力は、５０，０００，０００サトシを含んでいたので、発行者は、サトシに関して残りを期待することができる。行１２は、３９，９９９，０００である、第２の出力に対する出力の値である。行１３は、出力スクリプトの長さで、行１４は、第２の出力に対する出力スクリプトである。第２の出力は、発行者（Ｉ）に戻るお釣りであり、発行者は、自由に第２の出力を使うことができる。その結果、出力スクリプト（すなわち、ロッキングスクリプト）は、<PubK-Issuer hash>で表現される第１の発行者の公開鍵（Ｐ１Ｉ）のみを含む。

一般に、トランザクションの出力値は、入力値と等しいか又は少ないくなくてはならない。上述の例では、入力は、５０，０００，０００であり、出力は、４９，９９９，０００（第１の出力の１０，０００，０００と第２の出力の３９，９９９，０００に基づいて）である。したがって、１，０００サトシの損失がある。この例では、１，０００サトシは、トランザクション手数料（例えば、マイニング手数料）である。

トランザクションの第２のタイプ－発行者（Ｉ）による第１のユーザのリディームトークン
トークンのリディームの概要
この例において、発行者は、ユーザ５、７に対して電子ウォレットを提供するサービスプロバイダであり、ユーザの秘密鍵は、発行者（Ｉ）３に関連するデータストア１１に安全に保存される。その結果、この例において、ユーザ５、７（又はこれらのそれぞれの処理装置１５、１７）は、リディームスクリプトにサインしない。代わりに、発行者（Ｉ）３は、ユーザ５、７からの承認によって、リディームスクリプトにサインする。これは、図７に示された方法２００と６００において説明することができ、第１のユーザ（Ａ）５は、発行者（Ｉ）３に対する第１のトークンをリディームするリクエストを送信する６１０。黙示的、又は明示的のいずれでも、第１のトークンをリディームするこのリクエストは、第１のトークンをリディームするために第１のユーザの秘密鍵（Ｐ１Ａ）を使用するために発行者（Ｉ）２に対して第１のユーザ（Ａ）５による承諾を含んでも良い。

方法２００は、通信ネットワーク８を介して、第１のトークをリディームするリクエスト６１０を第１のユーザ（Ａ）５から受信する２１０。方法２００は、第１のトークン（Ｔ１）に関連する第１のリディームスクリプト（ＲＳ１）を決定する２２０を含む。

方法は、第１のユーザの秘密鍵（Ｖ１Ａ）を発行者（Ｉ）３が受信すること２３５も含む。１つの例では、これは、データストア１１から第１のユーザの秘密鍵（Ｖ１Ａ）を受信することを含む。発行者（Ｉ）によって管理される電子ウォレットに包含される、ユーザの秘密鍵は、安全に保管されなければならない。別の代替案において、発行者（Ｉ）３は、別のエンティティ又はノードから第１のユーザの秘密鍵（Ｖ１Ａ）を受信しても良い。発行者は、次に、ユーザの秘密鍵（Ｐ１Ａ）と第１の発行者の秘密鍵（Ｐ１Ｉ）によって第１のリディームスクリプトにサインする２４５。これは、第１のユーザ（Ａ）５のサービスプロバイダである発行者（Ｉ）３が第１の処理装置１３でこれらのステップを安全に実行することができ、第１のリディームスクリプト（ＲＳ１）の送信なしで、通信ネットワーク８を介してサインし、サインしない点で有利であり得る。

方法２００はまた、通信ネットワーク８を介して第２のデータ出力（Ｏ２）を、第１の量（Ｂ１）の発行者（Ｉ）へのトランザクションの表示を含むピアツーピア分散型台帳９に送信するステップ２６０を含む。

したがって、方法２００は、第１のトークン（Ｔ１）に関連する第１の量（Ｂ１）を発行者（Ｉ）に返す。一例では、第１のリディームスクリプト（ＲＳ１）は、第１のユーザ（Ａ）５と発行者（Ｉ）の両方の秘密鍵でサインされているので、このトランザクションにおける第１の量（Ｂ１）の受領者は、発行者（Ｉ）３であり、他のトランザクションに対して第１の量（Ｂ１）を次に使用することができる－単独でも又は他の関連するトークンと一緒にでもにかかわらず。発行者（Ｉ）３は、次に、他のトランザクションのために第１の量の暗号化（Ｂ１）を費やすことができる。

第１のトークン（Ｔ１）をリディームするトランザクションの特定の例がこれから説明される。

第１のユーザ（Ａ）５は、発行者（Ｉ）からの＄１０００ＡＵＤに対する第１のトークン（Ｔ１）をリディームする
この例において、第１のユーザ（Ａ）は、図２（ｂ）に示されるトークンの値に対して発行者（Ｉ）による第１のトークン（Ｔ１）をリディームすることを望む。これは、以下のトランザクションＩＤ－５１０として参照される、第１のユーザ（Ａ）５から発行者（Ｉ）への第１の量（Ｂ１）のトランザクションとう結果になる。見返りとして、発行者（Ｉ）は、不換通貨として＄１０００ＡＵＤを第１のユーザ（Ａ）５に提供する。

この例において、第１のトークンは、第１の量（Ｂ１）をロック解除することによってリディームされ、それは、発行者（Ｉ）３に移転される。第１の量（Ｂ１）の発行者への戻す移転は、将来のトランザクションに対する第１の量（Ｂ１）の次の使用を可能にする。発行者（Ｉ）３は、メタデータ（第１の量（Ｂ１）を発行者に戻したリディームトランザクションを含むことができる）を除去する１つ以上のトランザクションによって、第１の量（Ｂ１）を「逆トークン化する（detokenize）」こともできる。発行者（Ｉ）は、第１のユーザ（Ａ）５又は他のユーザからの承諾（例えば、サインのような）必要とする制約無く、この暗号通貨をさらに使用することができる。

第１のトークンＩＤ－５１０をリディームするトランザクションを説明する前に、現在のリディームトランザクション、ＩＤ－５１０への入力である（トランザクションＩＤ－２１０及びＩＤ－６１０からの）トランザクションを開始する出力を簡単に説明する。２つの入力は、一般に、第１のトークン（Ｔ１）に関連する第１の量（Ｂ１）と、トランザクション手数料（例えば、マイナの手数料）を支払うために少なくとも部分的に使用される別の量を含む。

前の例から、第１のユーザ（Ａ）５は、トランザクションＩＤ－２１０において、第１の量（Ｂ１）を受信した。
トランザクションＩＤ－２１０において第１のユーザ（Ａ）５に行く出力は、いかの通りまとめることができる：

表５の第２行は、数が１０，０００，０００サトシである第１のトークン（Ｔ１）に関連する 第１の量（Ｂ１）を表現する。第３行は、出力スクリプトを表現し、それは、上述の表４の行１１の等しい。前の例から、第１のトークン（Ｔ１）を作成したトランザクション、ＩＤ－２１０は、２つの出力を持って、第１の量（Ｂ１）に対応する第１の出力のみが、回収（redemption）トランザクションＩＤ－５１０に関連する。トランザクションＩＤ－２１０における第２の出力は、表４に示される発行者（Ｉ）に戻されるお釣りであった。

発行者は、回収トランザクション、ＩＤ－５１０に対してトランザクション手数料（例えば、マイニング手数料）も払わなければならず、それは、前のトランザクション、ＩＤ－６１０から受信した量からの一部として払われる。
この量は、以下のようにまとめられる：

表６の第２行は、９，９９９，０００である前のトランザクションからの量を示す。表６の三番目の行は、この前のトランザクションからの出力スクリプトである。このトランザクション、ＩＤ－６１０からの暗号通貨は、トークン（又はトークンの関連するユーザ）と関連していないので、リディームスクリプトハッシュは、単純に、ＰｕｂＫ－Ｉｓｓｕｅｒとして示される第１の発行者の公開鍵（Ｐ１Ｉ）のハッシュである。すなわち、トランザクションＩＤ－６１０からの出力を使うために、これは、単純に、第１の発行者の秘密鍵（Ｖ１Ｉ）でサインすることを必要とする。

第１のトークン（Ｔ１）をリディームするためのトランザクション、ＩＤ－５１０は、以下の表７を参照してこれから議論される。

表７の３行目は、このトランザクション、ＩＤ－５１０において、２つの入力があることを示し、行１４は、２つの出力があることを示す。

第１の入力は、行４から８に示され、それは、リディームされる第１の量（Ｂ１）の入力の入力であり、それは、前のトランザクション、ＩＤ－２１０からである。前のトランザクション出力インデックスである５行目は、トランザクションＩＤ－２１０の第１の出力を参照する「ＩＤＸ－００」としてマークされ、それは、第１の量（Ｂ１）である。
行７は、第１の量（Ｂ１）の使用を買おうにするScriptSigを示す。これは、第１のリディームスクリプト（ＲＳ１）が４つのサインのうちの２つを必要とすることを示し、特に、第１のユーザの秘密鍵（Ｖ１Ａ）と第１の発行者の秘密鍵（Ｖ１Ｉ）でサインする。

第２の入力が行９から１３で示され、それは、前のトランザクション、ＩＤ－６１０であり、現トランザクション、ＩＤ－５１０に資金を供給するために使用される。行１２のScriptSigは、第１の発行者の公開鍵（Ｐ１Ｉ）を含んだ前の出力スクリプトに対して第１の発行者の秘密鍵（Ｖ１Ｉ）で前の出力スクリプトにサインすることを要求する。

第１の出力は、行１５から１７に示され、それは、１０，０００，０００サトシの出力を持つ。これは、第１のトークン（Ｔ１）からの第１の量（Ｂ１）に対応する。出力スクリプトは、行１７で、対応するリディームスクリプトは、以下の通りである：
1 metadata1 metadata2 PubK-Issuer 3 OP_CHECKMULTISIG

このリディームスクリプトは、第１のトークンからのメタデータとPubK-Issuerとして示される発行者の公開鍵（Ｐ１Ｉ）を含む。このリディームスクリプトは、１０，０００，０００サトシを使うために３つのサインのうちの１つを必要とする。特に、第１の発行者の秘密鍵（Ｖ１Ｉ）は、次のトランザクションに対して暗号通貨にサインし、使うために使用することができる。第１のユーザの公開鍵（Ｐ１Ａ）がこのリディームスクリプトの中にないことは注目に値する。これは、この量は、発行者（Ｉ）によってリディームされ、その結果、第１のユーザ（Ａ）５によって使用されたと考えることができる。その結果、発行者（Ｉ）は、承諾（第１のユーザ（Ａ）５のサインを通した黙示的な承諾など）なく、この量を自由に使えるべきである。

発行者３は、次に、発行者の公開鍵（Ｐ１Ｉ）を使用して出力スクリプト（行１７の）からのリディームスクリプトをリディームするさらなるトランザクションを実施することができる。

上述の第１の出力は、リディームスクリプト内の第１のトークン（Ｔ１）からのメタデータを保持するが、いくつかの代替案において、第１のトークン（Ｔ１）がリディームされ、したがって「非トークン化されている（untokenised）」ているので、このメタデータを第１の出力に含める必要はないことが理解されるべきである。すなわち、対応する第１及び／又は第２のメタデータ（ＭＤ１／ＭＤ２）を除去することによって、第１のトークン（Ｔ１）と、リディームトランザクションの間に、第１の量（Ｂ１）を分離することができる。その上、出力スクリプトは、ユーザ（Ｉ）によって特定される別の形式でも良いことが理解される。

第２の出力は、行１８から２０で示され、それは、９，９９８，０００サトシの出力を持つ。これは、９，９９９，０００サトシを持つトランザクションＩＤ－６１０に対応する入力と対象的である。差分である１，０００サトシは、このトランザクションのマイニング手数料を反映する。

上の例において、第１のユーザ（Ａ）５は、第１のトークンの全ての値をリディームした。

トランザクションの４番目のタイプ－第１のユーザ（Ａ）は、発行者によって第１の部分をリディームする
第１のトークン（Ｔ１）の値の一部をリディームする
上述の例において、第１のユーザ（Ａ）５は、第１のトークン（Ｔ１）の全体の値をリディームした。しかしながら、いくつかの例において、第１のユーザ（Ａ）５は、第１のトークン（Ｔ１）の値の一部のリディームのみをしたいかもしれない。

図３（ａ）と図８を参照して、第１のトークン（Ｔ１）は、第１の部分（Ｒ１）と第２の部分（Ｒ２）の合計を含むことができるトークンの値を持つ。したがって、第１のユーザ（Ａ）５は、通信ネットワーク８を介して、第１のトークン（T!）の第１の部分（Ｒ１）の値をリディームするリクエストを送信することができる６１０。同様に、発行者（Ｉ）３は、通信ネットワーク８を介して、第１のトークン（Ｔ１）をリディームするリクエストを第１のユーザ（Ａ）５から受信する２１０。発行者は、次に、第１のトークン（Ｔ１）をリディームするための上述のステップ２２０、２３０、２４０及び２５０を実行することができる。

しかしながら、第１のユーザ（Ａ）５は、トータルのトークンの値（Ｔ１）の第１の部分（Ｒ１）の値をリディームするリクエストを行ったので、残りの第２の部分（Ｒ２）の値は、第１のユーザ（Ａ）５の戻す第２のトークン（Ｔ１）に割り当てる必要がある。第２のトークンは、図８を参照してこれから説明される。

第１のユーザ（Ａ）５は、通信ネットワークを介して、第２のトークン（Ｔ２）を作成するために、第１のユーザの公開鍵（Ｐ１Ａ）を発行者（Ｉ）３に送信することができる６４５。同様に、方法２００は、次に、第１のユーザ（Ａ）５からの第１のユーザの公開鍵（Ｐ１Ａ）を発行者（Ｉ）が決定すること２５５を含む。発行者（Ｉ）は、前のトランザクションから（又は電子ウォレット内）の第１のユーザの公開鍵（Ｐ１Ａ）を既に有していてもよく、そのような場合には、第１のユーザの公開鍵（Ｐ１Ａ）を第１のユーザ（Ａ）５によって再度送信する必要がないことを理解されたい。代わりに、第１のユーザの公開鍵（Ｐ１Ａ）は、データストア１１及び／又は第三者から受信しても良い。

さらに別の代替手段において、第１のユーザ（Ａ）５は、第２のトークン（Ｔ２）に対する異なる暗号化ペアを使用したいと望むかもしれない。それ故、送信するステップ６４５と第１のユーザの公開鍵を決定するステップ２５５は、第１のトークン（Ｔ１）と関連するものとは異なる第１のユーザの公開鍵を含んでも良い。

方法２００は、第２のトークン（Ｔ２）に関連する第２の量（Ｂ２）を割り当てること２６５を含み、この第２のトークンは、第２の部分（Ｒ２）に基づく、第２のトークンの値（ＴＶ２）を持つ。第２の量（Ｂ２）を割り当てるステップ２６５は、上述の第１の量（Ｂ１）を割り当てるのと類似の考慮を含んでも良い。

いくつかの例では、第２のトークン（Ｔ２）のペギングレート（ＰＲ２）は第１のトークン（Ｔ１）のペギングレート（ＰＲ１）と同じであるので、第１のトークン（Ｔ１）及び第２のトークン（Ｔ２）の条件は、トークンの値の量を除いて、同じままであることが、第１のユーザ（Ａ）５にとって望ましいかもしれない。

他の例では、第２の量（Ｂ２）は、第１のトークン（Ｔ１）のための最小しきい値（ＭＴ１）とは異なる最小しきい値（ＭＴ２）以上である必要があり得る。したがって、第２の量（Ｂ２）を割り当てることは２６５、第２のトークン（Ｔ２）の最小しきい値（ＭＴ２）を決定すること、及び第２のトークン（Ｔ“）の最小しきい値（ＭＴ２）以上の第２の量（Ｂ２）を決定することを含んでも良い。方法２００は、第２のリディームスクリプト（ＲＳ２）の第２のハッシュ（Ｈ２）を決定するステップ２７５をさらに含み、第２のリディームスクリプト（ＲＳ２）は、第１のトークン（Ｔ１）に関連付けられた第１のメタデータ（ＭＤ２）に少なくとも部分的に基づく第２のメタデータと、第１のユーザの公開鍵（Ｐ１Ａ）と、発行者（Ｉ）に関連付けられた第１の発行者の公開鍵（Ｐ１Ｉ）とに少なくとも基づく。

少なくとも第２のメタデータ（ＭＤ２）は、例えば、第１のトークン（Ｔ１）の１つ以上の契約条件との関連を含んでも良い。その結果、第２のトークン（Ｔ２）は、たとえ異なるトークンの値を持ったとしても第１のトークン（Ｔ１）と同じ又は類似の特徴を有しても良い。いくつかの特定の例において、第２のトークン（Ｔ２）の少なくとも第２のメタデータ（ＭＤ２）は、第１のトークンの少なくとも第１のメタデータ（ＭＤ１）と同じである。このような例において、第２のトークン（Ｔ２）の第２のリディームスクリプト（ＲＳ２）は、第１のトークン（Ｔ１）の第１のリディームスクリプト（ＲＳ１）を同じである。その結果、第２のトークン（Ｔ２）に関連する第２のハッシュ（Ｈ２）は、第１のトークン（Ｔ１）に関連する第１のハッシュ（Ｈ１）も同じである。これは、第１のトークン（Ｔ１）の第１のハッシュ（Ｈ１）と比較することによって第２のトークン（Ｔ２）の第２のハッシュ（Ｈ２）を容易に検証することができるという利点も持ち得る。これは、それらが同じである、第２のハッシュ（Ｈ２）（又は次のハッシュ）を記録することに関連するストレージスペースを削減することもできる。

上述したように、第２のトークン（Ｔ２）に対する第１のユーザの公開鍵（Ｐ１Ａ）は、いくつかの代替案において、第１のトークン（Ｔ１）に関連付けられた第１のユーザの公開鍵と異なるものであってもよく、同様に、第２のトークン（Ｔ２）に対する発行者（Ｉ）に関連付けられた第１の発行者の公開鍵（Ｐ１Ｉ）も異なっても良い。例えば、発行者（Ｉ）及び／又は第１のユーザ（Ａ）５は、セキュリティ上の理由で異なる暗号化対を使用することを望むかもしれない。

この例では、通信ネットワーク８を介して、第２のデータ出力（Ｏ２）をピアツーピア分散型台帳に送るステップ２６０は、第１のユーザ（Ａ）５と第２のハッシュ（Ｈ２）に対しての第２の量（Ｂ２）のトランザクションの表示をさらに含むことができ、第２のハッシュ（Ｈ２）は、第１のユーザ（Ａ）５と発行者（Ｉ）に関連付けられた第２のトークン（Ｔ２）を提供するために、第２の量（Ｂ２）に関連付けられている。したがって、第１のユーザ（Ａ）５は、第２の部分（Ｒ２）の値の基づき、いくつかの例において、第１のトークン（Ｔ１）と類似の特徴を持っている第２のトークン（Ｔ２）を提供される。

第１の部分をリディームする例が、図３（ａ）に説明されており、第１のトークン（Ｔ１）の第１の部分（Ｒ１）の値をリディームするリクエストを含む第１のユーザ（Ａ）５が発行者（Ｉ）と第１のトークン（Ｔ１）をリディームし、第１の部分は、＄５００ＡＵＤ不換通貨に等しい。同様に、発行者（Ｉ）３は、不換通貨で＄５００ＡＵＤと、第２のトークン（Ｔ２）を第１のユーザ（Ａ）５に提供するために第２の量（Ｂ２）とを提供する。第２の量（Ｂ２）は、＄５００ＡＵＤの第２の部分（Ｒ２）の値を表現することができる第２のトークンと関連している。

トランザクションの第３のタイプ－第１のユーザ（Ａ）は、値を第２のユーザ（Ｂ）に移転する
第１のユーザ（Ａ）５から第２のユーザ（Ｂ）への値の移転の概要
本開示は、図９に説明される発行者（Ｉ）３による１つ以上の追加のトークンの作成の方法３００も含む。これらの追加のトークンは、例えば、第１のユーザ（Ａ）５が第１のトークンの値又はその一部の第２のユーザ（Ｂ）への移転を望む結果として作成しても良い。これは、第２のユーザ（Ｂ）７と発行者（Ｉ）３に関連する第３のトークン（Ｔ３）の作成によって達成しても良い。

これは、第１のトークン（Ｔ１）に関連する同じ又は類似の権利を第２のユーザ（Ｂ）に実質的に移転することを第１のユーザ（Ａ）５に有利に可能にすることができる。第３のトークン（Ｔ２）の形式で新しいトークンが作成されたとしても、第３のトークン（Ｔ３）は、第１のトークン（Ｔ１）と類似の特徴を持っても良い。例えば、トークンは、同じ又は類似の関連するメタデータを持っても良い。例えば、第１のユーザ（Ａ）５と発行者（Ｉ）３との間で適用可能な同じ又は類似の契約条件が、第２のユーザ（Ｂ）７と発行者（Ｉ）３との間に適用されるべきである場合に便利であり得る。

状況次第で、図２（ｃ）に示されるように、第１のユーザ（Ａ）５は、第１のトークン（Ｔ１）の値の少なくとも一部を第２のユーザ（Ｂ）に移転することを望むかもしれない。１つの例では、これは、第１のトークン（Ｔ１）に関連する第１の量（Ｂ１）の第１のユーザ（Ａ）から第２のユーザ（Ｂ）７への移転によって達成できる。第１のトークン（Ｔ１）の値全体が第２のユーザ（Ｂ）８に移転されるトランザクションでは、これは、第１の量（Ｂ１）を有する第３のトークン（Ｔ３）の生成を含み、それは、第２のユーザ（Ｂ）７に移転される。効率的には、第３のトークン（Ｔ３）は、第１のトークン（Ｔ１）と第１のトークン（Ｔ１）に関連する権利の第２のユーザ（Ｂ）７への移転である。

この例では、第１のユーザ（Ａ）５から第２のユーザ（Ｂ）への値の移転は、移転を容易にする仲介者としての発行者（Ｉ）３を含む。これは、第１のユーザ（Ａ）５から第２のユーザ（Ｂ）７への第１の量（Ｂ１）の直接トランザクションから区別される。値のこの移転における発行者（Ｉ）の関与は、いくつかの理由で有利であり得る。第１に、発行者（Ｉ）を関与されることは、トークンとして第１の量（Ｂ１）を使用することと対象的に、通常の暗号通貨として、第１のユーザ（Ａ）５によって移転され、使用されることからの第１の量（Ｂ１）のリスクを削減することができる。第２に、発行者（Ｉ）を関与させることにより、発行者（Ｉ）３は、トークン及び特定のユーザに関連する特定の権利及び／又は負債を追跡することを可能にすることができる。これは、会計、財務報告及び／又は規制上の目的に役立つ可能性がある。方法３００，７００，８００、それぞれが、発行者（Ｉ）３、第１のユーザ（Ａ）５及び第２のユーザ（Ｂ）７によって実行される、この値の移転の一例が、図２（ｃ）と図９を参照して詳細に説明される。第１のユーザ（Ａ）５は、通信ネットワーク８を介して、第３のトークン（Ｔ３）を作成するリクエストを送信し７１０、この第３のトークン（Ｔ３）は、第１のトークン（Ｔ１）と関連する。併せて、又は代わりに、第２のユーザ（Ｂ）７は、通信ネットワーク８を介して、第３のトークン（Ｔ３）を作成するリクエストを送信する８１０ことができる。これらのリクエストが第１のユーザ（Ａ）５及び／又は第２のユーザ（Ｂ）７の一方又は両方によって送られるか否かは、第１のトークン（Ｔ１）の契約条件に依存することができる。

発行者（Ｉ）は、次に、通信ネットワーク８を介して、第３のトークン（Ｔ３）を作成するリクエストを受信する３１０。第１のユーザ（Ａ）５と第２のユーザ（Ｂ）からのリクエストは、通信ネットワーク８中で別の関係者経由で送信されても良いことを理解されたい。加えて、リクエストは、第１のユーザ（Ａ）５から来るリクエストの部分と第２のユーザ（Ｂ）７からのリクエストの別の部分を持つ部分的でも良い。

方法３００は、次に、第１のトークン（Ｔ１）に関連する第１のリディームスクリプト（ＲＳ１）を決定すること３２０を含む。

方法３００は、第１のユーザの秘密鍵（Ｖ１Ａ）を受信すること３３５も含む。１つの例において、これは、データストア１１から第１のユーザの秘密鍵（Ｖ１Ａ）を読み出すことを含む。方法は、ユーザの秘密鍵（Ｐ１Ａ）と第１の発行者の秘密鍵（Ｐ１Ｉ）によって第１のリディームスクリプトに発行者（Ｉ）３がサインすること３４５をさらに含む。ステップ３３５と３４５は、第１のトークン（Ｔ１）をリディームするための上述の方法２００におけるステップ２３５と２４５に似ており、同様の考慮も適用されても良い。

第３のトークン（Ｔ３）を作成するために、第２のユーザの公開鍵（Ｐ１Ｂ）が必要である。この第２のユーザの公開鍵（Ｐ１Ｂ）は、第２のユーザの秘密鍵（Ｖ１Ｂ）と暗号化ペアである。発行者（Ｉ）３は、いくつかの方法で、第２のユーザの公開鍵（Ｐ１Ｂ）を決定する３６０ことができる。第１に、発行者（Ｉ）３は、第２のユーザ（Ｂ）７のサービスプロバイダであり得、第２のユーザの公開鍵（Ｐ１Ｂ）は、発行者（Ｉ）のデータストア１１に記憶されても良い。代わりに、第２のユーザの公開鍵（Ｐ１Ｂ）は、以前のトランザクション中に発行者（Ｉ）によって受信されている可能性があり、したがって、第２のユーザの公開鍵（Ｐ１Ｂ）は、場合によっては、発行者（Ｉ）のデータストア１１から読み出すことができる。いくつかの代替手段では、第２のユーザの公開鍵（Ｐ１Ｂ）は、通信ネットワーク８中で第三者を経由して受信することができる。さらに別の代替案では、第２のユーザ（Ｂ）７は、通信ネットワーク８を介して、第２の公開鍵（Ｐ１Ｂ）を発行者（Ｉ）３を送ること８２０ができる。

方法３００は、第３のトークン（Ｔ３）と関連する第３の量（Ｂ３）を割り当てること３７０をさらに含む。第１のトークン（Ｔ１）の合計値が第２のユーザ（Ｂ）に転送されるいくつかの例では、第３の量（Ｂ３）が第１の量（Ｂ１）から、同じだけ割り当てられることに関して適切であり得る。第２のユーザから割り当てられ、最初の量の暗号通貨（Ｂ１）。他の選択肢（例えば、以下にさらに詳細に説明する第５のタイプのトランザクション）では、第１のトークン（Ｔ１）の合計値の一部のみが第２のユーザ（Ｂ）に移転され、対応する割合が第３の量（Ｂ３）に割り当てることができる。さらに別の例において、第３の量（Ｂ３）は、第１の量（Ｂ１）と関連しない別の暗号通貨から割り当てられても良い。第３の量（Ｂ３）を割り当てる３７０ための考慮点は、方法１００において第１の量（Ｂ１）を割り当てる１３０とき及び方法２００において第２の量（Ｂ２）を割り当てる２６５とときと同じ又は類似であり得る点を理解されるべきである。

この方法は、第３のリディームスクリプト（ＲＳ３）の第３のハッシュ（Ｈ３）を決定するステップ３８０をさらに含み、第３のリディームスクリプト（ＲＳ３）は、第１のトークンと関連する第１のメタデータ（ＭＤ１）に部分的に基づいた第３のメタデータ（ＭＤ３）と、第２のユーザの公開鍵（Ｐ１Ｂ）と、第１の発行者の公開鍵（Ｐ１Ｉ）とに少なくとも基づいている。これは、方法１００の第１のリディームスクリプト（ＲＳ１）の第１のハッシュ（Ｈ１）を決定する１４０か、又は方法２００の第２のリディームスクリプト（ＲＳ２）の第２のハッシュ（Ｈ２）を決定する２７５ことと同様又は同じ考慮を含んでもよい。方法３００は、通信ネットワークを介して、第３のデータ出力（Ｏ３）を、少なくとも第３の量（Ｂ３）トランザクションの第２のユーザ（Ｂ）へのトランザクションの表示と、第３のハッシュ（Ｈ３）を含むピアツーピア分散型台帳に送信すること３９０をさらに含み、第３のハッシュ（Ｈ３）は、第２のユーザ（Ｂ）７と発行者（Ｉ）に関連付けられた第３のトークン（Ｔ３）を提供するために暗号痛感の第３の量（Ｂ３）を関連付けられる。第２のユーザ（Ｂ）７及び発行者（Ｉ）に関連する第３のトークン（Ｔ３）を提供するために、第３のハッシュ（Ｈ３）が第３の暗号化量（Ｂ３））。これは、上述のステップ１５０と２２６０と類似しており、似たような変形や代替案が適用可能かも知れない。

第５のタイプのトランザクション－第１のユーザ（Ａ）は第１の部分を第２のユーザ（Ｂ）に移転する
別の例では、第１のトークン（Ｔ１）の総額の第１の部分（Ｒ１）のみが第２のユーザ（Ｂ）７に移転され、この場合、総額の残りの第２の部分（Ｒ２）は、第１のユーザ（Ａ）５に払い戻される第２のトークン（Ｔ２）に含むことができる。これは、方法２００で上述の値の第２の部分（Ｒ２）へ払い戻すことと類似しているかも知れない。したがって、第３のトークン（Ｔ３）を作成するリクエストは、第１の部分（Ｒ１）に基づいて第３のトークンの値（ＴＶ３）で第３のトークン（Ｔ３）を作成するリクエストを、明示的に又は暗示的に含んでも良い。

第２のトークン（Ｔ２）の形で、第１のユーザ（Ａ）５に払い戻すことは、図３（ｂ）と図１０を参照して説明される。第２のトークン（Ｔ２）を作成するために、方法３００は、第１のユーザの公開鍵（Ｐ１Ａ）を決定すること３５５を含む。これは、上述のようにいくつかの方法で達成されてもよく、第１のユーザ（Ａ）５から通信ネットワーク８を介して送信される第１のユーザの公開鍵（Ｐ１Ａ）を受信するステップ７４５を含むことができる。

この方法はさらに、第２トークン（Ｔ２）との関連付けのための第２の量（Ｂ２）を割り当てるステップ３６５を含み、第２のトークンは第２の部分（Ｒ２）に基づく第２のトークンの値（ＴＶ２）を有する。方法３００は、第１のトークン（Ｔ１）に関連付けられた第１のメタデータ（ＭＤ１）に少なくとも部分的に基づく第２のメタデータ（ＭＤ２）と、第１のユーザの公開鍵（Ｐ１Ａ）と、発行者（Ｉ）３と関連付けられた第１の発行者の公開鍵（Ｐ１Ｉ）とに基づいて、第２のリディームスクリプト（ＲＳ２）の第２のハッシュ（Ｈ２）を決定すること３７５も含む。したがって、第３のデータ出力（Ｏ３）をピアツーピア分散型台帳に送信するステップ３９０は、第１のユーザ（Ａ）５への第２の量（Ｂ２）のトランザクションの表示と、第１のユーザ（Ａ）５及び発行者（Ｉ）３に関連付けられた第２のトークン（Ｔ２）を提供するために、第２の量（Ｂ２）に関連付られた第２のハッシュ（Ｈ２）とをさらに含む。

第１のユーザ（Ａ）５から第２のユーザ（Ｂ）へ値を移転する例
トランザクション、ＩＤ－１１０の特定の例は、これから説明される。図３（ｂ）を参照して、第１のユーザ（Ａ）５は、＄１０．００ＡＵＤのトータルの値を持つトークンを持っている。第１のユーザ（Ａ）５は、＄７．３０ＡＵＤの第１の部分（Ｒ１）を第３のトークン（Ｔ３）として第２のユーザ（Ｂ）に移転し、第１のユーザ（Ａ）５に戻される第２のトークン（Ｔ２）の形でお釣りとして提供される＄２．７０の残りの第２の部分を持ちたいと望む。

この例において、第１のトークン（Ｔ１）は、＄５．００ＡＵＤの値を表現する各ブロックを持つ、２つのトークンのブロックを含む。これは、標準化された値（例えば、＄５．００ブロックで）もつトークンを代表する、又は異なるトランザクションから２つのブロックを取得した第１のユーザ（Ａ）５を代表することができる。これらのブロックのそれぞれは、５０，０００サトシを含む、それは、１００サトシ／セントのペギングレートにおいて、＄５．００ＡＵＤと等しい。これは、トランザクションＩＤ－１０１とＩＤ－１０２として表８に以下で説明され、これらは、第１のトークン（Ｔ１）を作成するトランザクションである。

ＩＤ－１０１とＩＤ－１０２の両方の行３は、それぞれのトランザクションの出力スクリプトを表現し、上述の表４における行１１と類似している。

発行者（Ｉ）は、このトランザクションに対してトランザクション手数料（マイニング手数料）を払う必要もある。このトランザクション手数料は、表８に示された、前のトランザクション、Ｉｄ－１０３から受信した量から部分的に支払われても良い。これは、１０，０００，０００サトシの前のトランザクションを示し、これはトランザクションに資金を提供するために部分的に使用される。これは、表６を参照して上述した前のトランザクションＩＤ－６１０と類似する。

値を第２のユーザ（Ｂ）へ移転するトランザクション、ＩＤ－１１０は、以下の表９を参照してこれから検討される。

表９の第３行は、３つの入力があることを示し、行１９は、３つの出力があることを示す。入力のうちの２つは、第１のトークン（Ｔ１）を表現し、第３の入力は、トランザクション手数料を払うためのものである。第１の出力は、第２のユーザ（Ｂ）７への値の移転を表し、第２の出力は、第１のユーザ（Ａ）５に戻されるトークンのお釣りを表し、第３の出力は、発行者（Ｉ）に戻されるお釣りである。

前のトランザクションＩＤ－１０１に基づく第１の入力は、行４から８に示され、それは、５０，０００，０００サトシの第１のブロックの入力であり、第１の量（Ｂ１）の半分であり、金額で＄５．００ＡＵＤを表す。行７は、この量の使用を可能にするScriptSigを示す。これは、第１のリディームスクリプト（ＲＳ１）が４つのサインのうち２つ、特に第１のユーザの秘密鍵（Ｖ１Ａ）及び第１の発行者の秘密鍵（Ｖ１Ｉ）によるサインを必要とすることを示している。行８は、この第１の入力を第１の出力と印をつける、連続番号である。

前のトランザクションＩＤ－１０２に基づく第２の入力は、行９から１３に示され、それは、５０，０００，０００サトシの第２のブロックの入力であり、第１の量（Ｂ１）の第２の半分であり、金額で＄５．００ＡＵＤを表す。行１２は、上の行７と類似のScriptSigを示す。行１２は、第２の入力を第１の出力と第２の出力に両方への出力へ印をつける、連続番号を示す。これは、５０，０００，０００サトシのこの第２のブロックが、第１の出力に２３，０００サトシと第２の出力に２７，０００サトシと分割されるからである。

第３の入力は、行１４から１８に示され、これは、現トランザクションＩＤ－１１０に資金を提供するために使用される前のトランザクションＩＤ－１０３に基づく。行１７のScriptSigは、第１の発行者の公開鍵（Ｐ１Ｉ）に含まれる前の出力スクリプトに対して第１の発行者の秘密鍵（Ｖ１Ｉ）でサインすることを必要とする。

第１の出力は、行２０から２２にで示され、それは、第３のトークン（Ｔ３）に対して第３の量（Ｂ３）である、７３，０００サトシの出力を有する。この例では、第３のトークン（Ｔ３）のペギングレートは、１００サトシ／セントであり（第１のトークン（Ｔ１）と同じペギングレートである）、したがって、第３の量（Ｂ３）は、＄７．３０ＡＵＤの第３のトークンの値（ＴＶ３）を持ち、それは、＄７．３０ＡＵＤの第１の部分（Ｒ１）に基づいている。

出力スクリプトは、行２２にあり、この例の対応するリディームスクリプトは、以下の通りである：
2 metadata1 metadata2 P1B P1I 4 OP_CHECKMULTISIG

これは、第２のユーザの公開鍵（Ｐ１Ｂ）と第１の発行者の公開鍵（Ｐ１Ｉ）を含む。重要なことは、第３のトークン（Ｔ３）は、第２のユーザ（Ｂ）７がリディームするために使用されるので、第２のユーザの公開鍵（Ｐ１Ｂ）は、使用される。metadata1とmetadata2は、これがユーザ間の「支払い（payment）」又は「移転（transfer）」トランザクションであることの表示を含む、上述のメタデータを含む。したがって、第１の出力は、発行者（Ｉ）３による＄７．３０ＡＵＤの値に対して第２のユーザ（Ｂ）７によってリディームできる第３のトークン（Ｔ３）を提供する。

第２の出力は、行２３から２４で示され、第１のユーザ（Ａ）５に戻さる第２のトークン（Ｔ２）に対して第２の量（Ｂ２）である２７，０００サトシの出力を持つ。この例において、１００サトシ／セントの同じペギングレートとその結果、第２の量（Ｂ２）は、＄２．７０ＡＵＤの第２のトークンの値（ＴＶ３）を持ち、それは、＄２．７０ＡＵＤの残りの第２の部分（Ｒ２）に基づいている。出力スクリプトは、行２５であり、この例に関する対応するリディームスクリプトは、以下の通りである：
2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

これは、第１のユーザの公開鍵（Ｐ１Ａ）と第１の発行者の公開鍵（Ｐ１Ｉ）を含む。重要なことは、第１のユーザの公開鍵（Ｐ１Ａ）は、第２のトークン（Ｔ２）が第１のユーザ（Ａ）５がリディームした後で使用されることである。メタデータは、これがユーザ間の「支払い」又は「移転」トランザクションであることの表示も含んでも良い。

第３の出力は、行２６から２８で示され、トランザクションに関するユーザのお釣りを反映する。現トランザクションにおいて、トランザクション手数料は、１，０００サトシであり、その結果、発行者（Ｉ）は、１０，０００，０００サトシの第３の入力からお釣り（change）を持つことを期待することができる。行２６は、９，９９９，０００である第３の出力に対する出力値である。第３の出力は、発行者（Ｉ）に戻されるお釣りであるので、発行者は、第３の出力を自由に使用することができる。その結果、行２８での出力スクリプトは、<PubK-Issuer hash>によって表現される第１の発行者の公開鍵（Ｐ１Ｉ）のみを含む。

上の例は、単一のトランザクションが「トークン化された」及び「トークン化されていない」 混合を持つことを可能する。１つの例では、入力トークンの値が、出力トークンの値と等しいことを検証することが重要であるかもしれない。したがって、発行者は、第１のトークン（Ｔ１）の第１のトークンの値（ＴＶ１）が第２のトークンの値（ＴＶ２）と第３のトークンの値（ＴＶ３）との合計に等しいことを検証しても良い。

上の例において、トランザクションて終了は、発行者（Ｉ）によって支払われ、発行者（Ｉ）は、他の手段によってこれらのコストを次に回しても良い。いくつかの代替手段において、トランザクション手数料は、第１のユーザ及び／又は第２のユーザによって直接支払われても良いことを理解されたい。例えば、第１のユーザは、トランザクション手数料の支払いに対して使用される暗号通貨に貢献することを求めらるかもしれない。別の例において、第１，第２又は第３の量の部分は、トランザクション手数料を支払うために各トランザクションで使用されても良い。さらに別の代替手段では、各トランザクションは、発行者（Ｉ）３とリディームするトランザクションをマイナが容易にするために追加のトークンを作成する追加の出力を含むことができる。

変形例－ユーザは、それぞれの秘密鍵でリディームスクリプトにサインする
上の例において、発行者（Ｉ）は、第１のユーザ（Ａ）５及び第２のユーザ（Ｂ）７に対するサービスプロバイダであり、それぞれの電子ウォレットを管理する。
その結果、ユーザ（Ｉ）３は、ユーザから権限付与されたそれぞれのユーザの秘密鍵にアクセスすることができる。これは、データストア１１からユーザの秘密鍵を読み出すことを含む。

いくつかの代替の例において、ユーザが自身の秘密鍵を保持するのが望ましいかも知れない。この分離は、ユーザが自身の秘密鍵に対してより強力な管理を持つことを可能にする。第１の発行者の秘密鍵（Ｖ１Ｉ）を含む、発行者（Ｉ）３のデータストア１１中のすべての情報へのアクセスを有する者は、彼らはそれぞれのユーザの秘密鍵を持たないため、リディームスクリプトをロック解除することができないので、より安全であり得る。

その結果、方法の１つの変形例は、彼らのそれぞれの秘密鍵によるサインに対して、リディームスクリプトをユーザ５、７に送信することを含むことができる。そのような例において、発行者（Ｉ）３は、ユーザの秘密鍵の所有権を持つ必要がない。

第１のトークン（Ｔ１）をリディームする方法２００’、６００’のそのような変形例は、図１１を参照してこれから説明される。

第１のユーザ（Ａ）５は、通信ネットワーク８を介して、第１のトークン（Ｔ１）をリディームするリクエストを送信する６１０ことができる。次に、発行者（Ｉ）３は、通信ネットワーク８を介して、第１のユーザ（Ａ）５から第１のトークン（Ｔ１）をリディームするリクエストを受信する２１０。方法２００は、次に、第１のトークン（Ｔ１）に関連する第１のリディームスクリプト（ＲＳ１）を決定すること２２０を含む。１つの例において、これは、データストア１１から第１のリディームスクリプト（ＲＳ１）を読みだすことを含んでも良い。別の例において、これは、１つ以上のソースからデータを持つ第１のリディームスクリプト（ＲＳ１）を再作成することを含んでも良い。例えば、これは、データストア１１から少なくとも第１のメタデータ（ＭＤ１）と第１の発行者の公開鍵（Ｐ１Ｉ）を読み出し、通信ネットワーク８を介して、第１のユーザの公開鍵（Ｐ１Ａ）を受信することを含んでも良い。このデータは、第１のリディームスクリプト（ＲＳ１）を再作成することを次に連結しても良い。

方法２００’は、通信ネットワーク８を介して、第１のユーザ（Ａ）５によってサインするために第１のリディームスクリプト（ＲＳ１）を送信すること２３０を次に含む。同様に、第１のユーザ（Ａ）５は、第１のリディームスクリプト（ＲＳ１）を受信する６２０。いくつかの代替の例において、第１のユーザ（Ａ）５に第１のリディームスクリプト（ＲＳ１）を送信するステップは、普段は実行されても良いことを理解されたい。例えば、第１のリディームスクリプト（ＲＳ１）は、発行者（Ｉ）３が第１のトークン（Ｔ１）を作成する間又は作成した後で、第１のユーザ（A）５に送信されても良い。別の代替案では、第１のリディームスクリプト（ＲＳ１）は、データストアから第１のユーザ（Ａ）５によって読み出されても良い。さらに別の代替案において、第１のユーザ（Ａ）５は、独立して第１のトークン（Ｔ１）と関連する第１のリディームスクリプト（ＲＳ１）を決定することができる。例えば、第１のユーザ（Ａ）５は、第１のリディームスクリプト（ＲＳ１）を決定するために１つ以上のソースから第１のメタデータ（ＭＤ１）、第１の発行者の公開鍵（Ｐ１Ｉ）及び第１のユーザの公開鍵（Ｐ１Ａ）を読み出すことができる。

第１のユーザ（Ａ）５は、次に、第１のユーザの秘密鍵（Ｖ１Ａ）によって、第１のユーザによってサインされる第１のリディームスクリプト（ＲＳ１Ａ）を提供するために第１のリディームスクリプト（ＲＳ１）にサインする６３０。第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）は、通信ネットワーク。

同様に、方法２００’は、通信ネットワーク８を介して、第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）を受信すること２４０を含む。方法２００は、第１の発行者の秘密鍵（Ｖ１Ｉ）により、第１のトークン（Ｔ１）に関連する第１の量（Ｂ１）をロック解除するために第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）にサインすること２５０をさらに含む。

方法２００’は、通信ネットワーク８を介して第２のデータ出力（Ｏ２）を、第１の量（Ｂ１）の発行者（Ｉ）へのトランザクションの表示を含むピアツーピア分散型台帳に送信するステップ２６０をさらに含む。一例では、第１のトークン（Ｔ１）がリディームされているので、第１の量（Ｂ１）が発行者（Ｉ）に戻され、もはや第１のトークン（Ｔ１）と関連付けられなくても良い。ある場合には、第１の量（Ｂ１）に関連するメタデータは、暗号通貨を「非トークン化（untokenise）」することを取り除いても良い。これは、同じトランザクション又は次のトランザクションにおいて行われても良く、発行者（Ｉ）３の選択であっても良い。

特に、上の方法２００’は、第１のユーザ（Ａ）５及び発行者（Ｉ）の両方が第１のリディームスクリプト（ＲＳ１）にサインすることを必要とする。これは、意図されたトークンの目的を超えて、第１のユーザ（Ａ）５による第１の量（Ｂ１）の偶発的又は故意ではない支出を防止し、又はリスクを低減するために有利であり得る。例えば、第１のユーザ（Ａ）５が第１の量（Ｂ１）を別のユーザ（発行者（Ｉ）以外の）に費やそうとした場合、第１の発行者の秘密鍵（Ｖ１Ｉ）が第１の量（Ｂ１）をロック解除するために必要であるので、そのようなトランザクションは処理されない。一方、第１のユーザ（Ａ）５が第１のリディームスクリプト（ＲＳ１）にサインすることを要求することは、第１のユーザ（Ａ）５は、第１のユーザの秘密鍵（Ｖ１Ａ）を制御し、それを承認されたトランザクションに選択的に使用するので、第１の量（Ｂ１）をリディームするためにある程度の安全性を提供する。

さらに、発行者（Ｉ）が最後にリディームスクリプトにサインすることは、安全でないかもしれない通信ネットワークを介して完全にサインされたリディームスクリプトを送信することを避けることができるので、セキュリティを向上させることができる。例えば、第１のトークン（Ｔ１）をリディームするとき、公開鍵の順序は、第１のユーザ（Ａ）５が第１のリディームスクリプト（ＲＳ１）にサインした後に、最終的なサインのために発行者（Ｉ）に送信されるように指示する。発行者（Ｉ）がロック解除の最終サインを提供するので、これにより、発行者（Ｉ）と第１のユーザ（Ａ）５との間の通信を傍受している人がトークン（Ｔ１）及び／又は第１の量（Ｂ１）に不正にアクセスするリスクを低減できる。

図１２に説明した方法３００’、７００’、８００’において示されたように、第１のユーザ（Ａ）５から第２のユーザ（７）に第１のトークン（Ｔ１）の値を移転するときにも同様のステップを使用することができる。方法３００’、７００’、８００’は、図９を参照して上述した方法３００，７００，８００で説明したものと同様のステップを含むが、以下の例外がある。発行者（Ｉ）３が第１のユーザの秘密鍵（Ｖ１Ａ）を受信する３３５代わりに、それを使って第１のリディームスクリプト（ＲＳ１）にサインし、これは第１のユーザ（Ａ）５によって行われる。したがって、方法３００’は、発行者（Ｉ）３が、通信ネットワーク８を介して、第１のユーザ（Ａ）５によってサインするために第１のリディームスクリプト（ＲＳ１）を送信すること３３０を含む。

第１のユーザ（Ａ）５は、第１のリディームスクリプトを受信し７２０、第１のリディームスクリプトを第１のユーザの秘密鍵（Ｖ１Ａ）でサインする７３０。これは、通信ネットワーク８を介して、発行者（Ｉ）３に次に送信される７４０、第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）を提供する。

方法３００’は、次に、通信ネットワーク８を介して、第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）を受信するステップ３４０を含む。これに続いて、第１の発行者の秘密鍵（Ｖ１Ｉ）で、第１のトークン（Ｔ１）に関連する第１の量（Ｂ１）をロック解除するために第１のユーザによってサインされた第１のリディームスクリプト（ＲＳ１Ａ）にサインする３５０。

方法３００’は、上述の方法３００と同様のやり方で第３のトークン（Ｔ３）の作成を完了するためのステップ３６０，３７０，３８０及び３９０をさらに含むことができる。

トークンと体系化プロセス
権利がコントラクトの保有者又は所有者によって授与されていることが定義された権利であれば、コントラクトは移転可能である。譲渡不能な契約の例としては、参加者の名前が付けられているもの、つまり権利が契約者ではなく特定の名前のエンティティに付与されているものがある。移転可能なコントラクトのみが本明細書で検討される。

コントラクトによって授与される権利を列挙又は定義している特定のコントラクトをトークンは表現する。実際のコントラクトは、分散された方法で記憶されたファイルでも良い。例えば、それはクラウドに記憶されても良い。望ましい実施形態では、トークンはビットコイントランザクションの形式でコントラクトを表現するものである。

分割可能なトークンは、複数のトークンに渡って割り当てらる小さい量にさらに細かく分けることができるトランザクション出力上の値である（すなわち、複数のトランザクションに渡って割り当てられる）。典型は、トークン化された不換通貨である。分割可能なコントラクトは、非ゼロペギングレートを指定するように定義される。分割可能なコントラクトに対して、トランザクション出力に移転されるトークン化された値は、ペギングレートを経由して基礎をなすビットコイン（ＢＴＣ）の値に関連付けられる。すなわち、コントラクトは、ペギングレートに関して保有者の権利を特定する。分割不可能なトークンについては、ＰｅｇｇｉｎｇＲａｔｅはなく、契約では固定値の所有者の権利が指定さる（例えば、無担保債券のように：「この契約は＄１０００で正確に払い戻されます」又はバウチャー「この契約は１回のヘアカットに対してリディームできる」）。非分割可能なコントラクトに対して、基礎をなすトランザクションのＢＴＣは、コントラクトの値を関係がない。表現「基礎をなすＢＴＣの値（Underlying BTC value）」は、トランザクション出力に付属するビットコインの量（ＢＴＣ）を指す。ビットコインプロトコルでは、すべてのトランザクション出力に有効であると見なされる非ゼロＢＴＣ量が必要である。実際には、ＢＴＣ量は、現在のところ、これまでは、５４６サトシに設定されている最小値（「ダスト」として知られている）よりも大きくなければならない。１ビットコインは、１億サトシと等しいと定義される。ビットコインのトランザクションはここで所有権の交換を容易にする手段としてのみ使用されるため、実際の基礎となるＢＴＣ量は任意であり、真の価値は契約仕様書にある。理論的には、すべてのトークンはダストによって運ばれる可能性がある。本発明のプロトコル、特に分割可能なトークンについては、基礎となるＢＴＣ値は意味を有する。すなわち、ＰｅｇｇｉｎｇＲａｔｅを介して契約値との関係を有する。ＰｅｇｇｉｎｇＲａｔｅはそれ自体は任意であり、基礎となるＢＴＣ量を小さく保つように選択される。ダストを持つ基礎となるトークン毎のトランザクションを単純に使わないでＰｅｇｇｉｎｇＲａｔｅを使う理由は、本発明のプロトコルは、分割可能性を促進し、トークンがより小さい量のいくつかのトランザクション出力に分割されたときに、元のコントラクトを調整する必要がないからである。むしろ、各細分化されたトークンの契約値は、ＰｅｇｇｉｎｇＲａｔｅと基礎となるＢＴＣ値の細分された量に基づいて単純に計算される。限定トークンは、ＮｕｍＳｈａｒｅｓと呼ばれる量で定義されるように、固定された非ゼロの数のシェアによって総発行値が固定される（又は「制限される」）ものである。したがって、制限された契約の下で発行されるさらなるシェアはない。例えば、競走馬の部分的な所有権の契約は、競走馬の１００％に制限される（例えば、それぞれ１％で１００シェア、それぞれ１０％で１０シェアなど）。無制限の契約は、発行者が、例えば、必要な金額の不換通貨を準備口座に追加するなどして、発行者がシェアのさらなる発行を引き受けることができることを意味する。ＮｕｍＳｈａｒｅｓは、すべての契約について明示的に述べなければならない。制限された契約はＮｕｍＳｈａｒｅｓ＞０が必要で、無制限の契約は、ＮｕｍＳｈａｒｅｓ＝０を設定することによって示される。典型的な例は、準備銀行口座に保持されている合計金額が存在する約束手形（すなわち、リディームされていないトークン）の合計金額と一致するような通貨準備（currency reserve）（正貨準備に類似）である。この概念は、在庫を含めるために通貨準備を超えて拡張される。例えば、ライセンスされた印刷されたＴシャツトークンの発行者は、在庫の１０，０００枚のＴシャツの商品から始まり、１０，０００枚のＴシャツを表すために分割可能なトークンを発行することができる（例えば、各シェア＝１枚のＴシャツ）。元のトークンを細分することができ、細分化された各トークンは、ＰｅｇｇｉｎｇＲａｔｅによって定義されるトランザクション出力の基礎となるＢＴＣ値にしたがって、いくつかのＴシャツに対してリディーム可能となる。しかし、需要が増加した場合、発行者は追加のシェアを発行することを決定することができる（すなわち、（例えば）別の１０，０００枚によって流通するシェアの数を増やす）。そのような場合、発行者は、さらなる発行を引き受けるために、彼の予備口座（すなわち、在庫倉庫）にさらに１０，０００枚のＴシャツを預ける義務がある。したがって、一度に在庫がある（在庫が「預金口座」として機能する）Tシャツの総数=リディームされていないシャツの総数である。ＰｅｇｇｉｎｇＲａｔｅｓは、シェアの値（ＳｈａｒｅＶａｌと呼ばれる量によって表される）が基礎となるＢＴＣ額に固定されている、分割可能な契約にのみ適用される。例えば、契約は、発行者が、基礎となるすべての１ ＢＴＣに対して１万ドルの割合でトークンをリディームすることを約束すると指定することがある。これは、（例えば）トークン化された基本となる出力値が１５，４００サトシを持つトランザクションが１．５４ドルでリディームされることを意味する。ＰｅｇｇｉｎｇＲａｔｅの値が０の場合、契約は分割不可能であることを示す（すなわち、無記名債券のように全体を移転することのみ可能）。ＰｅｇｇｉｎｇＲａｔｅが０に設定されている場合（分割できないトークンを意味する）、基礎となるＢＴＣ値は契約値とは関係なく、任意の金額に設定することができる。通常、この場合、運転コストを最小限に抑えるために、基礎となるＢＴＣ量を可能な限り小さく維持する（すなわち、ダストにセットする）ことが望ましい。ＮｕｍＳｈａｒｅｓは、（限定）契約の下で利用可能なシェアの総（固定）数です。限定契約の場合、ＮｕｍＳｈａｒｅｓは０より大きい整数でなければならない。無制限契約の場合、ＮｕｍＳｈａｒｅｓは固定ではなく、より多くのシェアをいつでも発行することができ（引き受けられている場合）、値は０に設定することによって表示される。シェア（ｓｈａｒｅ）は移転の単位として定義され、ＳｈａｒｅＶａｌはその単位の値です。例えば、不換通貨の場合、移転単位は１セントに設定されることがる。又は、例えば、５０セントに設定することができ、この場合、５０セントの「ロット（lots）」でのみ移転が実行される。ＳｈａｒｅＶａｌは百分率で表すこともできる。例えば、ブリーダーが競走馬を１０の等しいシェアで売りたい場合、ＳｈａｒｅＶａｌ＝１０％である。ＳｈａｒｅＶａｌは０より大きくなければならず、契約上で定義されていなければならない。ＴｏｔａｌＩｓｓｕａｎｃｅは、発行されたシェアの総額を表す。この値は限定契約にのみ関連し、無制限契約の場合、発行が固定されず、より多くのシェアが発行される可能性がある。シェアがパーセンテージで表されている場合、定義により、ＴｏｔａｌＩｓｓｕａｎｃｅ＝１００％である。限定契約の場合、ＮｕｍＳｈａｒｅｓ、ＳｈａｒｅＶａｌ、及びＴｏｔａｌＩｓｓｕａｎｃｅは次のように関連している：
NumShares x ShareVal = TotalIssuance
ＴｏｔａｌＩｓｓｕａｎｃｅの値が０の場合、無制限契約となる。無制限契約の例は、不換通貨で（ＴｏｔａｌＩｓｓｕａｎｃｅは０に設定される）、限定契約の例は次のとおりです。（ｉ）限定版記念コイン（１０００鋳造、１シェア＝１コインの場合）：ＴｏｔａｌＩｓｓｕａｎｃｅ＝１０００ｘ１＝１０００コイン；（ｉｉ）発券された会場の座席、ここでＴｏｔａｌＩｓｓｕａｎｃｅ＝利用可能な総座席数。流通は、未使用のトークンの合計値として定義される（すなわち、ＵＴＸＯ－未使用トランザクション出力中のトランザクションによって決定される）。すべての未使用トランザクションの完全なセットは、すべてのビットコインノードで使用可能なリストに保持される。例えば、発行者が最初に不換通貨タイプのトークンとして１０，０００ドルを発行し、時間の経過とともに＄５５００相当のトークンがリディームされると、流通（circulation）＝＄４５００（リディームされていないトークンの値として）である。この値は、関連する準備口座（reserve account）の残高と調整する必要がある。一部の（非典型的な）状況では、流通は準備口座残高を下回る可能性があることに注意されたい。例えば、競走馬で１０シェアを発行するブリーダーを考えてみる（ここでは、定義上はＴｏｔａｌＩｓｓｕａｎｃｅ＝１００％）。買い手は、それをブリーダーに送り返すことによってトークンをリディームすることができ、もし彼女がそれを逆トークン化するなら、貨幣は馬の９０％である９シェアのみで、一方、予備（＝安定）は、１００％馬全体である。この状況では、余剰超過額（reserve excess）（つまり、未確認の１０％所有権）は、黙示的に発行者に帰属する。この状況は良性であり、本発明の範囲内に入るが、１００％のシェアを明示的に考慮しなければならないプロトコルを施行することができる（すなわち、この例示的な状況ではブリーダーはトークンを逆トークン化することを許されない）。

例１－薪の重さでの販売。この例では、契約書には次のように書かれている「所有者は、２０キロ当たり基礎となる６００サトシの料金で薪を受け取る権利がある。」というメタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅ＝０；ＳｈａｒｅＶａｌ＝２０ｋｇ；ＰｅｇｇｉｎｇＲａｔｅ＝６００サトシ／シェア。これらのパラメータは、無制限かつ分割可能な契約を定義しており、契約のシェアは２０ｋｇの薪の価値を有し、取引内の６００サトシの各倍数は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例２－薪の袋での販売。この例では、契約書には次のように書かれている「保有者には、２０ｋｇの薪の１袋分を受け取る資格がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝１袋；ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、無制限で分割不可能な契約を定義しており、契約のシェアは２０ｋｇの薪の袋の値を持ち、トランザクション内の基本的なビットコインの量は契約の１つのシェアに相当する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例３－１０００ドル紙幣。この例では、契約書には次のように書かれている「所有者はちょうど＄１０００を受け取る権利があります」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝＄１０００；ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、無制限で分割不可能な契約を定義する。契約のシェアは＄１０００の値を持ち、トランザクション内の基本ビットコインの量は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例４－記念コイン＃１。この例では、契約書には次のように書かれている「所有者は限定版（１０００コイン）２０００年オリンピックシルバーコイン（１人あたり最大１個）の資格を持っている」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１０００；ＳｈａｒｅＶａｌ＝１コイン、ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、契約内のシェアが１コインの価値を有し、トランザクション内の基本ビットコインの任意の量が契約内の１つのシェアに対応する、１０００シェアに制限される分割不可能な契約を定義する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは１０００コインである。

例５－記念コイン＃２。この例では、契約書は次のように書かれている。「保有者は、１コイン当たり基礎となる６００サトシの料金で２０００年オリンピック銅コインを限定版（１０，０００コイン）を受け取る資格がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１０，０００；ＳｈａｒｅＶａｌ＝１コイン；ＰｅｇｇｉｎｇＲａｔｅ＝６００サトシ／シェア。これらのパラメータは、１０，０００シェアに制限される分割可能な契約を定義し、契約のシェアは１コインの価値を有し、取引内の６００サトシは契約の１つのシェアに対応する。この実施形態では、合計発行額は１０，０００コインである。

例６－不換通貨＃１。この例では、契約書には次のように書かれている。「所有者は、基礎となるビットコインごとに１０，０００ドルの料金でカナダドルを受け取る権利がある。移転単位は５０セントです」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝５０セント；ＰｅｇｇｉｎｇＲａｔｅ＝５０００サトシ／シェア。これらのパラメータは、無制限かつ分割可能な契約を定義し、契約のシェアは５０カナダセントの値を持ち、トランザクション内の５０００サトシの各倍数は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例７－不換通貨＃２。この例では、契約書には次のように書かれている。「所有者は、基礎となるビットコインごとに１０，０００ドルの料金で豪ドルＡＵＤを受け取る権利がある。移転単位は１セントです」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝１セント；ＰｅｇｇｉｎｇＲａｔｅ＝１００サトシ／シェア。これらのパラメータは、無制限かつ割り切れる契約を定義する。契約のシェアは１オーストラリアセントの値を持ち、トランザクション内の１００の土地の倍数は契約の１つのシェアに相当する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。ちなみに、この例で実際に移転できる最小ＡＵＤは６セントである。それ以下であれば、基礎となるＢＴＣ値が有効なトランザクションに必要な現在の最小値よりも低くなる。

例８－シェアハウス。この例では、契約書には、「所有者は、１０％に対して６００サトシの料金で（住所の）資産の所有権を分担する権利がある」と書いてある。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１０；ＳｈａｒｅＶａｌ＝１０％；ＰｅｇｇｉｎｇＲａｔｅ＝６００サトシ／シェア。これらのパラメータは、契約内のシェアが１０％の価値を有する１０シェアに限定された割り切れる契約を定義し、取引内の６００サトシの倍数は契約の１シェアに相当する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは家の１００％所有権である。

例９－競走馬。この例では、契約書には次のように書かれている。「所有者は、「Ｎａｋａ’ｓ Ｄｅｌｉｇｈｔ」の所有権の１％を６００サトシの料金で所有する権利がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１００；ＳｈａｒｅＶａｌ＝１％；ＰｅｇｇｉｎｇＲａｔｅ＝６００サトシ／シェア。これらのパラメータは、契約内のシェアが１％の価値を有する１００シェアに制限される分割可能な契約を定義し、取引内の６００サトシの各倍数は契約の１シェアに相当する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは馬の１００％所有権である。

例１０－割り当てられた座席のチケット。この例では、契約書には次のように書かれている。「所有者は、２０１６年２月１４日セントラル・コンサートホールで「Ｄｅａｄ Ｌｉｚａｒｄ」コンサートでＢ５４に座る権利がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１；ＳｈａｒｅＶａｌ＝１チケット、ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、１つのシェアに限定された分割不可能な契約を定義し、契約のシェアは１チケットの値を有し、トランザクション内の基本ビットコインの量は契約の１シェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは１つのチケットである。チケットは、イベント会場への進入時にバリアへのアクセスコードを含むことができ、それにより、チケットが引き換えられたというフィードバックを提供することができる。

例１１－有名人の日のためのバウチャー。この例では、契約書には「タクシーで自宅まで乗ることを含みシドニーの中心部のＳｐｉｆｆｙ ＨｏｔｅｌでＧｅｏｒｇｅ Ｋｌｕｄｇｙと２０１６年３月３１日に一人のための素晴らしいディナーを得る権利がある」と書かれている。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１；ＳｈａｒｅＶａｌ＝１つの日付、ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、１つのシェアに限定された分割不能契約を定義し、契約のシェアは１つの日付の値を有し、トランザクション内の基本ビットコインの任意の量は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは１日である。

例１２－ヘアカットのバウチャー。この例では、契約書には、「保有者には、１回のヘアカットとブローを受ける権利があり、祝日を除く平日は有効です」と書かれている。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝１バウチャー：ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、無制限かつ分割不可能な契約を定義し、契約内のシェアは１バウチャーの値を有し、トランザクション内の基本ビットコインの任意の量は契約内の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例１３－Ｔシャツ。この例では、契約書には次のように書かれている。「所有者は、２０１６年ワールドツアーのための「Ｄｅａｄ Ｌｉｚａｒｄ」の記念ＴシャツをＴシャツ一枚当たり１０００サトシの料金で受け取る権利がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０； ＳｈａｒｅＶａｌ＝１枚のＴシャツ、ＰｅｇｇｉｎｇＲａｔｅ＝１０００。これらのパラメータは、無制限かつ割り切れる契約を定義し、契約のシェアは１枚のTシャツの値を有し、トランザクション内の１０００サトシの各倍数は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例１４－割り当てられていない座席券。この例では、契約書には次のように読める：「所有者は、２０１６年４月２９日にＳａｄｉｅ’ｓ ＰｕｂでＴｈｅ Ｊａｚｚ Ｊｉｖｅｒｓコンサートに１入場券当たり１０００サトシの料金で参加する資格がある。１３７スペースしか利用できない」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１３７；ＳｈａｒｅＶａｌ＝１チケット；ＰｅｇｇｉｎｇＲａｔｅ＝１０００。これらのパラメータは、１３７シェアに限定された割り切れる契約を定義し、契約のシェアは１つのチケットの値を有し、取引内の１０００サトシの各倍数は契約の１つのシェアに対応する。この実施形態では、ＴｏｔａｌＩｓｓｕａｎｃｅは１３７のチケットである。

例１５－音楽ファイル。この例では、契約書には次のような内容が記載されている。「所有者には、Ｄｅａｄ Ｌｉｚａｒｄのアルバム「Ｃｈａｍｅｌｅｏｎ Ｒｉｓｉｎｇ」のコピーが１つ得る権利がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝１枚のアルバム；ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、無制限かつ分割不可能な契約を定義し、契約のシェアはアルバムに対応する１つのファイルの値を有し、トランザクション内の基本ビットコインの任意の量は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

例１６－カタログからの家具の項目。この例では、契約書には：「所有者は、この素晴らしいユニークなアンティークなジョージアンエスクリトワを優れた状態で受ける権利がある。」メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝１；ＳｈａｒｅＶａｌ＝１項目、ＰｅｇｇｉｎｇＲａｔｅ＝０。これらのパラメータは、１つのシェアに限定された分割不可能な契約を定義し、契約のシェアは１の値を有し、トランザクション内の基本ビットコインの任意の量は契約の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは１項目である。

例１７－ひとまとまりのゴルフボール。この例では、契約書には次のように書かれている。「所有者には、ボール１２個で６００サトシの料金でプレミアム品質のＴｉｇｇｅｒ Ｗｏｄｅｓクラス「Ａ」のゴルフボールを得る資格がある」。メタデータは、次の重要なパラメータを表すように定義されている。ＮｕｍＳｈａｒｅｓ＝０；ＳｈａｒｅＶａｌ＝１２ゴルフボール；ＰｅｇｇｉｎｇＲａｔｅ＝６００。これらのパラメータは、無制限かつ分割可能な契約を定義し、契約内のシェアは１２ゴルフボールの値を有し、トランザクション内の６００サトシの各倍数は、契約内の１つのシェアに対応する。この例では、ＴｏｔａｌＩｓｓｕａｎｃｅは固定されていない。

処理装置
上述のように、発行者（Ｉ）３、第１のユーザ（Ａ）５及び第２のユーザ（Ｂ）７は、第１の処理装置１３、第２の処理装置１５、及び第３の処理装置１７に関連することができる。ピアツーピア分散型台帳９は、複数の処理装置１９に関連付けることもできる。

そのような処理装置は、コンピュータ、タブレットコンピュータ、移動通信装置、コンピュータサーバなどの電子装置の一部であっても良い。処理装置に加えて、電子装置は、データストア１１及びユーザインタフェースを含んでも良い。

図１３は、処理装置１３，１５，１７，１９の一例を示す図である。処理装置１３，１５，１７，１９は、プロセッサ１５１０と、メモリ１５２０と、インタフェース装置１５４０とを備え、メモリ１５２０は、上述した方法１００，２００，３００，４００，５００，６００，７００，８００を実施するための命令及びデータを記憶し、プロセッサ１５１０は、メモリ１５２０からの命令を実行して方法を実行する。インタフェース装置１５４０は、通信ネットワーク５との通信、及びいくつかの例ではユーザインタフェース及びデータストア１１などの周辺機器との通信を容易にする通信モジュールを含むことができる。処理装置１５０１は独立したネットワーク処理装置は、別のネットワーク要素の一部であっても良い。さらに、処理装置によって実行されるいくつかの機能は、複数のネットワーク要素間に分散されても良い。例えば、発行者３は、発行者（Ｉ）３に関連付けられた安全なローカルエリアネットワークにおいて方法１００，２００，３００，４００を実行する複数の処理装置２３を有することができる。

本開示が、ユーザ、発行者、商人、プロバイダ又は他のエンティティが（サイン、発行、決定、計算、送信、受信、作成などを含む）特定のアクションを実行することを説明する場合、この言葉は、説明の明快さのために使用される。これらの動作は、これらのエンティティによって操作されるコンピューティング装置によって実行されることを理解されたい。

サインは、暗号機能を実行することを含むことができる。暗号機能には、クリアテキストの入力と、秘密鍵などの鍵の入力がある。プロセッサは、サインとして使用できる数又は文字列を計算するために関数を実行することができる。サインは、サインされたテキストを提供するためにクリアテキストと共に提供される。メッセージテキスト又は鍵が１ビットだけ変更された場合、サインは完全に変更される。サインを計算するのに計算能力はほとんど必要ないが、特定のサインを持つメッセージを再作成することは事実上不可能である。このように、クリアテキストは、秘密鍵が利用可能である場合にのみ、変更され、有効なサインが付随する。さらに、他のエンティティは、公的に利用可能な公開鍵を使用してサインを容易に検証することができる。

ほとんどの状況において、暗号化及び復号化は、暗号化されたメッセージ又はクリアテキストメッセージをそれぞれ表す出力文字列を計算するために暗号化関数を実行するプロセッサを含む。

鍵、トークン、メタデータ、トランザクション、オファー、コントラクト、サイン、スクリプト、メタデータ、招待状などは、データメモリに記憶された数字、テキスト又は文字列、例えば、「string」又は「int」タイプのプログラムコード中の変数又は他のタイプ又はテキストファイルである。

ピアツーピア台帳の例は、ビットコインブロックチェーンである。ビットコイン通貨で資金を移転するか、又は料金を払うことは、取引から出された資金又は手数料とともにビットコインブロックチェーン上の取引を作成することを含む。ビットコイントランザクションの一例は、入力トランザクションハッシュ、トランザクション量、１つ以上の宛先、受取人の公開鍵、及び入力トランザクションとして入力トランザクションを使用して作成されたサイン及び支払人の秘密鍵を含むサインを計算する。トランザクションは、入力トランザクションハッシュがビットコインブロックチェーンのコピーに存在することと、公開鍵を使用してサインが正しいことを確認することによって検証できる。同じ入力トランザクションハッシュがすでに他の場所で使用されていないことを保証するために、トランザクションはコンピューティングノードのネットワーク（「マイナ」）にブロードキャストされる。マイナは、入力トランザクションハッシュがまだ接続されておらず、サインが有効である場合にのみ、取引をブロックチェーンに受け入れて記録する。入力トランザクションハッシュが既に別のトランザクションにリンクされている場合、マイナはトランザクションを拒否する。

トークンに対して暗号通貨を割り当てることは、割り当てられた暗号通貨を用いてトランザクションを作成することと、トランザクションのメタデータフィールドにトークンを表現することを含む。

２つの項目が関連付けられている場合、これはこれらの項目の間に論理接続が存在することを意味する。データベースでは、例えば、２つの項目の識別子を同じレコードに記憶して、２つの項目を互いに関連付けることができる。トランザクションでは、２つの項目の識別子をトランザクション文字列に含めて、２つの項目を互いに関連付けることができる。

ビットコインプロトコルを使用して、スクリプトをリディームし、及び／又はトークンをロック解除することは、秘密鍵を使用してスクリプト及び／又はトランザクションのサイン文字列を計算することを含む。スクリプトは、異なる秘密鍵又は他の条件から派生した２つ以上のサインを必要とすることがある。このトランザクションの出力は、その後、マイナに提供される。

別のエンティティを承認することは、秘密鍵を使用してトランザクションのサイン文字列を計算すること、及びエンティティにサイン文字列を提供して、エンティティがトランザクションを検証するためにサインを使用できるようにすることを含むことができる。

別のエンティティとの口座を有するユーザは、電子メールアドレス、名前、及び潜在的に公開鍵など、ユーザに関する情報を記憶するエンティティを備えることができる。例えば、エンティティは、ＳＱＬ、ＯｒｉｅｎｔＤＢ、ＭｏｎｇｏＤＢなどのデータベースを維持することができる。いくつかの例では、エンティティは、ユーザの秘密鍵の１つ以上を記憶することもできる。

当業者であれば、本開示の広範な一般的な範囲から逸脱することなく、上述の実施形態に多くの変形及び／又は修正を行うことができることが理解されよう。したがって、本実施形態は、すべての点で例示的であり、限定的ではないとみなされるべきである。

３ 発行者
５ 第１のユーザ
７ 第２のユーザ
８ 通信ネットワーク
９ ピアツーピア分散型台帳
１１ データストア
１３ プロセッサ
１５ 処理装置
１７ 処理装置
１９ 処理装置

Claims (15)

1. コンピュータにより実施されるトークン化方法であって、
   暗号通貨の量（Ｂ１）に関連する出力（ＴｘＯ）とロックスクリプトとを含むブロックチェーントランザクション（Ｔｘ）を生成するステップを含み、
   前記ロックスクリプトは、
   トークン化されたエンティティの表現又はトークン化されたエンティティへの参照であるトークン（Ｔ１）に関連付けられた情報を含むメタデータと、
   少なくとも１つの公開暗号鍵と、
   を含む、方法。
2. 前記トークン（Ｔ１）は、トランザクション（Ｔ１）に含まれるメタデータフィールドの中で提供される、請求項１に記載の方法。
3. 前記トークン（Ｔ１）との関連付けのために、前記暗号通貨の量（Ｂ１）を割り当てるステップ、を含む請求項１又は２に記載の方法。
4. ｉ）前記トークン化されたエンティティをブロックチェーンに又はブロックチェーン外に格納するステップ、及び／又は、
   ｉｉ）前記暗号通貨の量の所有権をリディームするパーティ又はユーザに移転するために、前記出力（ＴｘＯ）に対するロックスクリプトの要件を満たすロック解除スクリプトを提供するステップ、
   を含む請求項１～３のいずれかに記載の方法。
5. 前記メタデータは、
   ｉ）前記トークンに関連付けられた情報を含む、及び／又は、
   ｉｉ）ファイルへのポインタ、制御データ、コントラクトに関連する情報、前記トークンに関連する情報、及び／又は前記ブロックチェーントランザクション（Ｔｘ）を保有する方法に関する情報、を含む、
   請求項１～４のいずれかに記載の方法。
6. 前記メタデータは、
   ｉ）ハッシュされる、及び／又は、
   ｉｉ）暗号鍵としてブロックチェーンプロトコルにより解釈されるように又は見えるように、前記出力（ＴｘＯ）のロックスクリプトの中で提供される、
   請求項１～５のいずれかに記載の方法。
7. 前記ロックスクリプトは、サインを公開鍵と比較する動作を含む、及び／又は、
   前記ブロックチェーントランザクション（Ｔｘ）は、Ｎ－ｏｆ－Ｍブロックチェーントランザクションである、
   請求項１～６のいずれかに記載の方法。
8. 前記トークンはコントラクトに関連し、前記ブロックチェーントランザクション及び／又はメタデータは、以下：
   ｉ）前記コントラクトの下で利用可能なシェアの量、
   ｉｉ）送信側から少なくとも１つの受信側へ移転される移転単位の量、
   ｉｉｉ）前記移転単位の量について値を計算するための因子、
   を示すパラメータ又はデータアイテムを含む、
   請求項１～７のいずれかに記載の方法。
9. 前記トークン（Ｔ１）との関連付けのために、前記暗号通貨の量（Ｂ１）を割り当てるステップは、
   前記トークン（Ｔ１）のトークン値（ＴＶ１）を決定するステップと、
   前記トークン（Ｔ１）のペギングレート（ＰＲ１）を決定するステップと、
   前記ペギングレート（ＰＲ１）及び前記トークン値（ＴＶ１）に基づき、前記暗号通貨の量（Ｂ１）を決定するステップと、
   を含む、請求項３～８のいずれかに記載の方法。
10. 前記トークン（Ｔ１）との関連付けのために、前記暗号通貨の量（Ｂ１）を割り当てるステップは、
    前記トークン（Ｔ１）の暗号通貨の量の最小閾値（ＭＴ１）を決定するステップと、
    前記最小閾値（ＭＴ１）以上の暗号通貨の量（Ｂ１）を決定するステップと、
    を含む、請求項３～９のいずれかに記載の方法。
11. 前記メタデータは前記ブロックチェーントランザクションの中で提供され、
    ブロックチェーンプロトコルが前記トークン（Ｔ１）の存在及び／又は前記ロックスクリプトの中の他のメタデータに依存しないようにし、前記メタデータはユーザによりトークンとして解釈又は使用することができる、及び／又は、
    前記トークン（Ｔ１）の移転が、基礎にあるブロックチェーンプロトコルを変更することなく、ブロックチェーンを介して実行されるようにする、
    請求項１～１０のいずれかに記載の方法。
12. 通信ネットワークを介して、前記トークン（Ｔ１）についてのリクエストを送信又は受信するステップ、又は、
    前記メタデータに、ランダムに生成された値を含めるステップ、及び／又は、
    第２トークン（Ｔ２）を前記トークン（Ｔ１）に関連付けるために、前記メタデータに情報を埋め込むステップ、
    を含み、及び／又は、
    暗号鍵が、秘密鍵と公開鍵を含む暗号化ペアを形成し、前記公開鍵及び／又は秘密鍵、又はその部分は、電子ウォレット又はデータストアに格納される、請求項１～１１のいずれかに記載の方法。
13. ブロックチェーンを介してトークン化されたアセットをセキュアに制御及び／又は移転するための、コンピュータにより実施されるトークン化方法であって、
    トークン（Ｔ１）との関連付けのために、暗号通貨の量（Ｂ１）を割り当てるステップであって、前記トークンは、トークン化されたエンティティの表現又はトークン化されたエンティティへの参照である、ステップと、
    前記暗号通貨の量（Ｂ１）に関連する出力（ＴｘＯ）を有するブロックチェーントランザクション（Ｔｘ）を生成するステップであって、前記トークン（Ｔ１）は、前記ブロックチェーントランザクション内のメタデータフィールドの中で表現される、ステップと、
    を含む方法。
14. 処理装置に請求項１～１３のいずれか一項に記載の方法を実施させるための機械可読命令を含むコンピュータプログラム。
15. 請求項１～１３のいずれかに記載の方法を実行する処理装置を含む装置。

Images